TIME Private Higher School: Republique Tunisienne Ministere de L'Enseignement Superieur Et de La Recherche Scientifique

REPUBLIQUE TUNISIENNE
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR

ET DE LA RECHERCHE SCIENTIFIQUE
Ecole Supérieure Privée des Technologies de l’Information et de Management de l’Entreprise

Agrément n° 1/2002
TIME Private Higher School
Projet de Fin d’Etudes

Pour l’obtention d’un Diplôme National d’Ingénieur en Génie Logiciel
Développement et intégration d’un module de gestion de délégations dans

un progiciel de BPM et ECM
Encadré par : - M. Slim Mesfar Réalisé par : Oussama Werfelli
- M. Oussama Saidi
Année universitaire : 2016/2017.

Dédicaces
En cette fin d’année je dédie ce projet
A toute personne m’ayant accompagné
Par une parole, un geste ou même une pensée,
A tous ceux ayant contribué
De prêt ou de loin à cette finalité ;
Merci pour tout
Ceci étant pour le général, vient maintenant le particulier
Avec une distinction bien méritée
Pour mon père préféré
Sans qui, je n’y serai jamais arrivé,
A ma chére mère, mes frères Mohamed Amine et Moataz, et ma soeur Tayssir
A mes amis qui m’ont accompagné dans un long parcours Bilel et Arkam
A Jvan, Nasraouia, Nouri, Jabeur, Yassine, Issam, Gazzoum, et tous les autres
Et finalement et tout particulièrement à Katr Ennada, la personne qui a été toujours

présente pour me soutenir et supporter.
Oussama Werfelli
Remerciements
En premier lieu, je remercie Dieu, le tout-puissant pour ses faveurs et ses grâces, de
m’avoir donné le courage et la patience de mener ce travail.
Après dieu et avant toute autre personne, je me remercie pour l’effort que j’ai fourni et
temps que j’ai passer dans ce travail.
Je tiens à présenter mes reconnaissances et mes vifs remerciements à mon professeur

Monsieur Slim Mesfar, pour le temps consacré aux réunions qui ont rythmé les différentes
étapes de mon projet.
J’adresse mes sincères remerciements à Monsieur Oussama Saidi, mon encadrant à la

société IP-TECH, pour la qualité de l’encadrement qu’il m’a assuré, sa disponibilité, ses
conseils et remarques judicieuses.
Je tiens à remercier également toute l’équipe de l’entreprise qui a essayé de créer une
ambiance favorable au bon déroulement de ce stage.
J’exprime finalement mes sincères remerciements aux membres du jury à l’honneur qu’ils
m’ont accordé en acceptant d’évaluer ce travail.
i
Table des matières
Introduction générale 1
Chapitre 1 Contexte Général du projet 3

1 L’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Missions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapitre 2 Étude préalable 8

1 Alfresco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1 Alfresco de point de vue fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Alfresco de point de vue technique . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 Développement sur Alfresco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 Averroès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1 Averroès de point de vue fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Développement sur Averroès . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Méthode de gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Choix de la méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Le Framework Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Le langage de modélisation UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5 Les outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1 PowerAMC Designer : Outils de modélisation . . . . . . . . . . . . . . . . . . . 21
5.2 Eclipse : Environnement de développement intégré . . . . . . . . . . . . . . . . 21
5.3 JIRA : Outils de gestion de projet agile . . . . . . . . . . . . . . . . . . . . . . 21
ii
Table des matières
5.4 Git et Bitbucket : Outils de versioning . . . . . . . . . . . . . . . . . . . . . . . 22

5.5 LaTex : Outils de rédaction du rapport . . . . . . . . . . . . . . . . . . . . . . 23
Chapitre 3 Analyse et spécification des besoins 24

1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.2 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Chapitre 4 La réalisation 33
1 Sprint 1 : Gestion des délégations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.1 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.2 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.3 Diagrammes de séquence système . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.4 Diagramme d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.5 La réalisation du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.6 Revue du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1.7 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2 Sprint 2 : Mise en oeuvre des délégations . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.1 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.4 Diagrammes de séquence détaillés . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.6 Revue du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.7 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3 Sprint 3 : Droit d’accès et traçabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.1 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.3 Diagrammes de séquence système . . . . . . . . . . . . . . . . . . . . . . . . . 55
iii
3.6 Revue du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.7 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Conclusion générale 63
Bibliographie 65
iv
Table des figures
1.1 Logo IP-Tech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Logo ArchiveYourDocs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Architecture Alfresco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Architecture Alfresco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Designer des processus métiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Fonctionnement de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 PowerAMC Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 Eclipse IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7 JIRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8 Git et Bitbucket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9 Des commits sur Bitbucket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.10 Latex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1 Product Backlog dans JIRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1 Diagramme de cas d’utilisation Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Diagramme de séquence système Ajouter délégation . . . . . . . . . . . . . . . . . . . 37
4.3 Diagramme de séquence système Modifier délégation . . . . . . . . . . . . . . . . . . 38
4.4 Diagramme de séquence système Suppression multiple . . . . . . . . . . . . . . . . . . 39
4.5 Diagramme d’activité Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.6 Diagramme de classe Délégation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.7 Modèle de page Surf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.8 Accès de la gestion des délégations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.9 Page de consultation des délégations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.10 Les actions multiple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.11 Dialogue d’ajout d’une délégation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
v
4.12 Burndown Chart Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.15 Diagramme de séquence détaillé Lister ses délégations courante . . . . . . . . . . . . . 49
4.16 Diagramme de séquence détaillé Remplacer utilisateur . . . . . . . . . . . . . . . . . . 50
4.17 Liste des délégations courante d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . 52
4.18 Session déléguée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.19 Burndown Chart Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.21 Diagrammes de séquence système Ajouter utilisateur à la gestion des permissions . . 56
4.22 Diagrammes de séquence système Interdire utilisateur . . . . . . . . . . . . . . . . . . 56
4.23 Diagrammes de séquence système Audit utilisateur . . . . . . . . . . . . . . . . . . . 57
4.25 Historique d’une tâche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.26 Ajout d’un utilisateur à la gestion des permissions . . . . . . . . . . . . . . . . . . . . 61
4.27 Interface de gestion des délégations ouverte par un utilisateur . . . . . . . . . . . . . 61
4.28 Burndown Chart Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
vi
Liste des tableaux
3.1 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1 Sprint Backlog : Gestion des délégations . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 Sprint Backlog : Mise en oeuvre des délégations . . . . . . . . . . . . . . . . . . . . . 46
4.3 Sprint Backlog : Droit d’accès et traçabilité . . . . . . . . . . . . . . . . . . . . . . . . 53
vii
Glossaire
AMP Alfresco Module Package. 15
AOP Aspect-oriented programming. 11
API Application Programming Interface. 15
BPM Business Process Management. 6, 16
BPO Business process outsourcing. 4
ECM Entreprise Content Management. 4–6, 16
IoC Inversion of Control. 11
ITO Information Technology Outsourcing. 4
ORM Object Relational Mapping. 11
SDK Software Development Kit. 15
viii
Introduction générale
Aujourd’hui, l’automatisation des processus d’entreprise est un défi important. Avant tout
développement et mise en œuvre d’un système d’information, il est fondamental de bien maîtriser
les enchaînements des opérations de ces processus.
De ce fait, on constate alors une importante croissance de la masse des documents et la quantité
de l’information partagée ce qui pousse les organismes de faire des efforts conséquents pour gérer
au mieux les différents contenus qu’elles produisent, achètent ou utilisent quotidiennement. Des
efforts généralement concrétisés par la mise en œuvre et l’utilisation de solutions de gestion des
contenus de plus en plus performantes, faisant émerger une nouvelle discipline, dans ce contexte le
ECM (Enterprise Content Management) est fondé. Ces solutions permettent la gestion électronique
de documents (GED), la gestion collaborative des connaissances, l’archivage de l’information et
certaines offrent la possibilité de travailler avec les Workflows.
Les entreprises informatiques sont en plein concurrence pour offrir des solutions satisfaisantes à
leurs clients, du point de vue coût, elles investissent dans l’amélioration des systèmes qu’elles offrent
avec la réponse aux besoins du jour.
ArchiveYourDocs, filiale du groupe IP-Tech cherche à améliorer sa solution de BPM et ECM.

C’est dans ce cadre que nous abordons, dans ce travail, le problème de remplacement d’un utilisateur
absent au sein d’une entreprise sans dévoiler les informations propriétaires de ce dernier. L’objectif
principal par ce projet de fin d’études est de proposer une solution pour concevoir un module dans
Averroès qui fournit des diverses fonctionnalités spécifiées à chaque utilisateur que ce soit sa poste.
Le reste de ce rapport est structuré par quatre chapitres où ils sont organisés comme suit :
Le premier chapitre est essentiellement dédié à l’introduction du contexte de base de ce travail par
la description de l’entreprise où se déroule la réalisation de notre projet. En effet, nous présentons
dans la première partie, l’organisme d’accueil. Ensuite, la problématique de notre projet et nous
clôturons ce chapitre par les objectifs à atteindre.
Dans le deuxième chapitre, nous abordons les différents concepts de la plateforme utilisée pour
réaliser notre travail en introduisant tout d’abord quelques notions de base ; Nous présentons, en
premier lieu, Alfresco et Averroès. En deuxième lieu, la méthode de gestion de projet, UML et les
1
Introduction générale
outils techniques choisis.
Le troisième chapitre est consacré à l’analyse et la spécification les besoins fonctionnels ; Nous
présentons au premier lieu la capture des différents besoins, l’identification des rôles des utilisateurs
et enfin la préparation du backlog de produit.
Le dernier chapitre est consacré à la mise en œuvre de notre projet en réalisant l’implémentation
du module en respectant les exigances de la méthodologie choisi.
Finalement, nous clôturons ce travail réalisé pendant ce projet par une conclusion générale, tout
en décrivant quelques perspectives.
2
Chapitre 1
Contexte Général du projet
1 L’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapitre 1. Contexte Général du projet
Introduction
Le contexte général du projet est une étape primordiale pour la connaissance de l’environnement
dans lequel s’est déroulé le projet, ainsi que la présentation du projet. Ce chapitre sera consacré tout
d’abord à la présentation de l’entreprise au sein du quel le projet est effectué ainsi que sa vision et
ses principaux projets, par la suite la présentation de la problématique et l’objectif de notre projet.
1 L’organisme d’accueil
1.1 Présentation
IP-Tech
Figure 1.1: Logo IP-Tech
IP-Tech est un groupe d’entreprises Tunisien spécialisées dans les services informatiques qui
a été fondé en 2007 par deux ingénieurs diplômés de l’École Polytechnique de Tunisie. Le groupe
IP-Tech s’organise en trois activités :
• Une activité ITO assurée par quatre pôles de développement : Microsoft, PHP, C++, JAVA
et un pôle comportant des activités d’assurance qualité, de packaging, de design graphique et
de support bancaire.
• Une activité BPO assurée par un pôle d’externalisation des processus métiers.
• Une activité ECM assurée par un pôle de conseil en Dématérialisation et en Gestion Électronique
de Documents (GED).
Au tour de cette dernière activité l’entreprise ArchiveYourDocs est crée.
4
Figure 1.2: Logo ArchiveYourDocs
ArchiveYourDocs
ArchiveYourDocs a été créé en 2009, en tant que filiale du groupe IP-Tech, pour cibler le marché
tunisien, maghrébin et africain. Elle intervient dans les projets d’intégration et de développement
spécifique autour des différentes solutions ECM du marché propriétaires et libres.
ArchiveYourDocs est spécialisée dans l’édition et l’intégration des systèmes de gestion de contenu
d’entreprise, des flux de documents et des processus métiers basés sur les échanges documentaires.
1.2 Vision
L’évolution des activités des entreprises et de leur clientèle les contraint à accumuler un volume
important de contenu non structuré composé de documents physiques et d’autres numériques.
Cette masse importante de contenu documentaire non géré représente une oppression pour les
entreprises ne leur permettant pas d’exploiter pleinement les ressources qui sont à leur disposition
pour mieux partager les connaissances, améliorer les communications internes et externes et optimiser
les processus.
C’est dans cette vision qu’ArchiveYourDocs développe ses activités. D’une part, la gestion du
contenu d’entreprise (Entreprise Content Management, ECM) est un composant clé de l’infrastructure
d’une organisation et peut l’aider à relever ces défis. D’autre part, les fonctionnalités de collaboration
intégrées, comme l’automatisation des processus métier, favorisent la collaboration entre les membres
de l’équipe et permettent de créer, de réviser et d’approuver des documents de manière plus structurée.
1.3 Missions
Les produits et les solutions de l’entreprise couvrent toute la chaîne de gestion documentaire
dès la numérisation et jusqu’à l’automatisation des processus métiers.
5
Voici les principaux projets développés par l’entreprise dans les différentes phases de la gestion
des documents.
— Indexo : est un système d’indexation des documents numérisés.
— Compresso : est un outil de compression de documents PDF.
— Le Records Management : ArchiveYourDocs propose à ses clients l’adoption d’un Système

de Records Management, qui se greffe à leur Système de Gestion Electronique de Documents
— Averroès : est un système de gestion documentaire et d’automatisation de processus métier

(ECM/BPM),et c’est le plus grand projet d’ArchiveYourDocs.
Le travail présenté dans ce projet est au tour de ce dernier, Notre projet est une extension
fonctionnelle dans cette solution, c’est pour cela que nous allons la bien étudier.
2 Problématique
Dans les systèmes de BPM, dont Averroès y appartient, la gestion des processus métier se fait
par l’exécution des différents types de tâche, telle que des tâches système, des tâches qui font appel
à des web-services ou des tâches qui sont affectées à des utilisateurs humains.
Ces utilisateurs peuvent provoquer des problèmes dans certains cas au niveau de déroulement
des processus métier au sein de l’organisme à cause de leurs absences.
D’ailleurs, il existe différentes entreprises telles que les entreprises financières et de sécurité
sociale utilisant la solution Averroès, ces entreprises ne sont pas tolérantes avec le retard.
En conséquence, les collaborateurs dans l’entreprise affrontent un nouveau problème lors de la

récupération de la tâche propre à la personne absente qui se fait par l’échange du mot de passe. D’où
le remplaçant qui s’occupe à résoudre le problème de blocage dans le déroulement d’un processus
métier, va avoir un accès total sur le compte de l’absent, en outre, il peut même changer le mot de
passe courant puisqu’il a l’ancien.
En revanche, ces problèmes ont donné naissance à l’idée de penser à une solution qui répond à
la question suivante : "Comment peut-on ajouter à Averroès un module qui permet à un utilisateur
d’effectuer les tâches de l’autre sans échange du mot de passe et tout en restreignant les droits d’accès
du délégué ?".
6
3 Objectifs du projet
Notre but dans ce projet est de concevoir un module dans Averroès qui fournit principalement
les fonctionnalités suivantes :
— L’administrateur peut définir une délégation d’une personne à une autre en fixant la durée de
cette délégation.
— L’utilisateur doit avoir la possibilité de voir les personnes qu’il va remplacer.
— Le délégué peut accéder aux tâches de l’utilisateur remplacé et les effectuer durant la période
de la délégation.
— Le délégué peut lancer des processus métiers au nom de l’utilisateur qu’il remplace
— Si une tâche est effectuée à partir un délégation, le système doit garder le nom d’utilisateur
qui l’a effectué.
— L’administrateur peut donner le droit de la définition des délégations aux autres utilisateurs.
Conclusion
Dans ce chapitre, nous avons décrit le contexte général dans lequel s’inscrit notre projet. Au
début, nous avons présenté l’entreprise d’accueil, ensuite, nous avons déterminé la problématique en
déduisant l’objectif de notre projet. Afin d’atteindre les objectifs fixés dans ce chapitre, il serait utile
de commencer par une étude préalable nous permettant d’effectuer des choix judicieux.
7
Chapitre 2
Étude préalable
1 Alfresco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Averroès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Méthode de gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Le langage de modélisation UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5 Les outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Chapitre 2. Étude préalable
Introduction
Le travail à réaliser dans ce projet est l’implémentation d’un module qui gère les délégations
dans Averroès qui est lui-même basé sur Alfresco, et pour comprendre le premier, il faut bien étudier
le dernier. Dans la première partie de ce chapitre, nous allons étudier Alfresco de différent points de
vue en premier temps, puis nous allons passer à l’étude de la solution Averroès et ses spécificités.
Après cette étude, nous allons étudier la méthode de gestion du projet adoptée et les outils à utiliser
dans la réalisation de ce projet.
1 Alfresco
La pate-form Alfresco à deux distributions, une distribution intitulé Alfresco Enterprise qui est
payante, et l’autre s’intitule Alfresco Community et distribué sous la licence libre LGPLv3, elle peut
être téléchargée, modifiée, et redistribuée gratuitement, elle s’adresse en particulier aux développeurs
et techniciens capables d’assurer eux-mêmes la maintenance et le support et qui n’ont pas besoin
des fonctionnalités d’Alfresco destinées aux entreprises.
1.1 Alfresco de point de vue fonctionnelle
Alfresco se situe au point de convergence entre ECM et BPM, il permet de mettre en place des
processus performants et de gérer le contenu d’une entreprise de manière efficace.
1.1.1 ECM
La gestion de contenu d’entreprise (en anglais Enterprise Content Management : ECM) est la
collecte et l’organisation systématiques de l’information qui doit être utilisée par un public désigné.
Ni une seule technologie, ni une méthodologie, ni un processus, c’est une combinaison dynamique
de stratégies, de méthodes et Outils utilisés pour capturer, gérer, stocker, préserver et fournir des
informations prenant en charge les processus organisationnels clés tout au long de leur cycle de vie.[1]
9
1.1.2 BPM
Le Business Process Management (BPM), ou Gestion des Processus Métiers, permet d’avoir une
vue d’ensemble de processus métiers de l’organisation et de leurs interactions pour les optimiser et
les automatiser autant que possible.[2]
Le processus métier est défini comme un ensemble d’activités corrélées ou en interaction qui,
une fois effectuées, rempliront l’un des objectifs de l’entreprise. La modélisation des processus métier
se fait souvent avec le BPMN.[3]
BPMN Business Process Model and Notation, c’est-à-dire « modèle de procédé d’affaire et notation
», est une méthode de modélisation de processus d’affaires pour décrire les flux d’activités et les
procédures d’une organisation sous forme d’une représentation graphique standardisée.[4]
Activiti est la solution de gestion des processus métiers (BPM) spécialement conçue pour les
utilisateurs métier et les développeurs. Elle s’appuie sur un moteur de processus haute performance
dont la flexibilité et l’évolutivité permettent de gérer une multiplicité de processus métiers critiques
modélisé en BPMN.[5]
1.2 Alfresco de point de vue technique
1.2.1 Composants logiciels
Alfresco est une solution robuste développée selon les standards de la génie logiciel en se basant
sur des langages et des outils open-sources. Voici les principaux éléments utilisés dans la création
d’Alfresco :
— Java : Langage de programmation (coté serveur)
— JavaScript : Langage de programmation (coté client et coté serveur)
— Lucene : est une bibliothèque utilisé pour l’indexation et la recherche
— Freemarker : est un moteur de template
— Activiti : est un moteur de workflow
— PostgreSQL : Système de gestion de base de données relationnelle
10
— Hibernate : ORM pour la correspondance entre les objets Java et la base de données
relationnelle
— Spring Framework : est un socle pour le développement d’applications avec un conteneur

léger d’IoC, il propose une diversité de fonctionnalité tel que l’AOP, l’injection des dépendances,
etc...
En tant qu’application entièrement Java, Alfresco fonctionne sur tous les systèmes pouvant
exécuter Java Enterprise Edition. Spring est au coeur de la solution permettant la possibilité de
modulariser les fonctionnalité telles que la getions des données, la sécurité, et les règles.
1.2.2 Architecture
Il existe plusieurs façons de découper et de déployer Alfresco, mais la plupart des déploiements
suivent un schéma général qui offre les fonctionnalités d’un ECM et BPM.
Les solutions sont généralement divisées entre les clients et le serveur, où les clients offrent aux
utilisateurs une interface utilisateur à la solution et le serveur fournit des services de gestion de
contenu et de stockage. Les solutions offrent généralement plusieurs clients à un serveur partagé,
chaque client étant adapté à l’environnement dans lequel il est utilisé.
La figure 2.1 présente les différents composants architecturaux.
11
Figure 2.1: Architecture Alfresco
a. Les clients
Alfresco offre principalement deux clients web :
— Alfresco Share : Implimenté avec Spring Surf et peut être déployé dans son propre tier,
séparement du serveur de contenu d’Alfresco, Il se concentre sur les aspects collaboratifs de la
gestion de contenu et la rationalisation de l’expérience utilisateur.
— Alfresco Explorer : est dépolyé dans le serveur de contenu d’Alfresco. C’est un client utilisateur
hautement personnalisable qui expose toutes les fonctionnalités du serveur d’application de
contenu Alfresco.
Les clients existent également pour les portails (via les portlets JSR-168), les plates-formes
mobiles, Microsoft Office et des applications de bureau.
12
b. Le serveur
Le serveur d’application de contenu d’Alfresco (Alfresco content application server) comprend

un entrepôt de contenu (content repository) et des services à valeur ajoutée pour créer des solutions
ECM.
Deux normes définissent le content repository : CMIS (Content Management Interoperability

Services) et JCR (Java Content Repository / JSR-170/286). Ces normes fournissent une spécification
pour la définition et le stockage du contenu, la récupération de contenu, la version et les autorisations.
Le respect de ces normes permet une mise en œuvre fiable, évolutive et efficace.[6]
Le serveur d’application les catégories de services suivante crées au tour du content repository :
— Services de contenu (transformation, marquage(tag), extraction de métadonnées)
— Services de contrôle (workflow, records management, ensembles de modifications)
— Services de collaboration (activités, wiki)
Les clients communiquent avec le serveur d’application et ses services à travers plusieurs protocoles.
HTTP et SOAP offrent un accès programmatique tandis que les protocoles CIFS, FTP, WebDAV,
IMAP et Microsoft SharePoint offrent un accès applicatif.
1.3 Développement sur Alfresco
1.3.1 Déploiement d’Alfresco
La figure 2.2 donne une vue de l’architecture d’Alfresco du point de vue du développeur.
13
Figure 2.2: Architecture Alfresco
Le composant principal avec toutes les fonctionnalités ECM principales est appelé Platform, et
est implémenté dans l’application web alfresco.war. Il fournit l’entrepôt où le contenu est stocké plus
tous les services de contenu associés. Alfresco Share fournit une interface client Web (c’est-à-dire
une interface utilisateur) pour l’entrepôt, et est implémentée comme application Web share.war.
La fonctionnalité de recherche est implémentée sur Apache Solr 4 et fournit l’indexation de tout le
contenu, ce qui permet une fonctionnalité de recherche puissante. [6]
La communication entre l’entrepôt et les autres composants tel que Alfresco Share et le client
mobile, ce fait avec des web services REST implémenté avec le framework "web script".
1.3.2 Le framework webscript
Le framework web script permet de suivre facilement le modèle de contrôleur de modèle (MVC),
bien qu’il ne soit pas nécessaireLe contrôleur est un JavaScript côté serveur, une classe Java, ou les
deux. Le contrôleur gère la demande, exécute toute logique métier nécessaire, remplit le modèle avec
des données, puis transmet la demande à la vue. La vue est un modèle FreeMarker responsable de
14
la construction d’une réponse au format approprié. Le modèle est une structure de données passée
entre le contrôleur et la vue. [7]
Les web services implémentés avec ce framework sont appelés des web scripts.
1.3.3 Alfresco SDK
Il existe plusieurs approches pour développer sur Alfresco en fonction de besoin, par exemple si
on veut créer une application séparée qui communique avec Alfresco on va utiliser l’API Alfresco
REST. D’autre part, si on veut crée une extension dans cette API, ou ajouter des fonctionnalités
dans Alfresco on a la possibilité de modifier directement son code source ou d’utiliser Alfresco SDK.
La modification du code source n’est pas recommandée pour deux raisons
• On ne peut pas migrer les modifications faites sur une version à une autre version d’Alfresco,
donc on est obligé réécrire tout les modifications sur la nouvelle version.
• Pour modifier dans le code source il faut le comprendre
Ces problème sont résolus avec Alfresco SDK.
Alfresco SDK est un kit de développement basé sur Maven qui offre une approche facile à utiliser
pour commencer le développement des applications et des extensions pour Alfresco.
Il se compose d’un modèle de projet (un «archétype» dans le langage Maven) et des traitements
intégrées qui permettent à Maven de comprendre comment créer des packages de module Alfresco(AMP)
et de les déployer dans Alfresco.
Il existe trois archétypes Maven qui peuvent être utilisés pour générer des projets d’extension
Alfresco.
• Alfresco Repository AMP : Cet archétype est utilisé pour créer des extensions pour l’application
web Alfresco Repository (alfresco.war) sous forme de AMP.
• Alfresco Share AMP : Cet archétype est utilisé pour créer des extensions pour l’application
web Alfresco Share (share.war) sous forme d’AMP.
• Alfresco all-in-one (AIO) : Cet archétype est un projet multi-module qui s’appuie sur les
capacités puissantes du SDK Alfresco pour personnaliser et exécuter la plate-forme Alfresco
complète intégrée à tous ses composants
15
2 Averroès
Dans le cadre de sa vision, ArchiveYourDocs a développé une solution puissante d’ECM et de

BPM sous le nom d’Averroès. La plate-forme développée par l’organisation est basée sur Alfresco
mais avec de nouvelles fonctionnalités et des spécificités techniques que nous allons les présenter
dans cette section.
2.1 Averroès de point de vue fonctionnelle
Puisqu’il est fondé sur Alfresco, Averroès offre toutes les fonctionnalités offertes par le premier,
mais il ajoute plusieurs fonctionnalités de BPM et d’ECM que nous présentons par la suite.
Designer des processus métiers Grâce à un designer développé par l’équipe d’ArchiveYourDocs,
Averroès offre à utilisateur sans connaissances techniques la possibilité de modéliser, créer et déployer
des processus métiers, et définir des formulaires associés aux tâches métiers. La figure 2.3 présente
le designer des processus métiers d’Averroès.
Figure 2.3: Designer des processus métiers
Les types de données Averroès fournit par défaut un ensemble de types de contenus qui permettent
de gérer les données de l’entreprise. Cependant, il offre la possibilité d’étendre ces types et de créer
trois éléments de modèle qui sont : les types, les contraintes et les collections de propriétés.
16
Statistiques Le module de statistique offert par Averroès permet à l’utilisateur de générer des
statistiques sur la gestion des processus tel que le temps moyen de traitement des tâches et les
instances en retard, et des statistiques sur les éléments créés dans la bibliothèque de documents.
2.2 Développement sur Averroès
Puisqu’il est basé sur Alfresco, Averroès respecte la même architecture présentée dans la figure
2.2. L’entrepôt est implémenté dans l’application web alfresco.war, l’interface utilisateur est implémentée
dans l’application share.war et les services de recherche sont implémentés dans solr.war.
Le fonctionnalités ajoutées dans l’entrepôt sont développées avec archétype Alfresco Repository
AMP fournie par Alfresco SDK.
L’application web qui fournie l’interface utilisateur (Share) d’Averroès est basée sur le Share de
la version 4.2.c d’Alfresco, et pour des raisons technique, les modifications sur cette partie sont faites
directement dans le code source.
3 Méthode de gestion de projet
3.1 Choix de la méthodologie
Dans le domaine de gestion de projets il existe principalement deux types de méthodologie,

classique et agile. Selon les approches traditionnelles, dites en cascade ou «waterfall», tout est planifié
avant le début du projet. Une fois le cahier des charges créé et le contrat signé, les développeurs ont
la responsabilité de livrer ce qui est prévu.
À l’opposé des approches traditionnelles, la gestion de projets Agile propose de vérifier au fur et
à mesure que le projet évolue dans la bonne direction. Son principe est simple : il s’agit de découper
le projet en plusieurs étapes ou petits projets. Chacune de ces étapes doit aboutir à la création d’un
élément fonctionnel de l’ensemble, qui s’inscrit dans les objectifs du projet.
Les méthodes agiles se basent sur 4 valeurs fondamentales [8] :
— Les individus et interactions plutôt que processus et outils
— Développement logiciel plutôt que documentation exhaustive
— Collaboration avec le client plutôt que négociation contractuelle
17
— Ouverture au changement plutôt que suivi d’un plan rigide
Après une étude comparative entre les méthodes agiles les plus répandues, nous avons décidé d’utiliser
Scrum pour la gestion du processus du développement.
3.2 Le Framework Scrum
Scrum est un cadre de travail pour le développement et la maintenance de produits complexes.

Il se compose de plusieurs éléments que sont l’Équipe Scrum et ses rôles associés, les événements,
les artéfacts et les règles. Chaque élément a une raison d’être spécifique qui le rend indispensable à
la réussite de l’application de Scrum. [9]
3.2.1 Les artefacts de Scrum
Les artefacts de Scrum sont spécialement conçus pour maximiser la transparence d’informations
essentielles afin que tous en aient la même compréhension. Les artefacts de Scrum sont :
• Le Product Backlog : Il liste toutes les fonctionnalités, besoins, améliorations et correctifs

correspondant aux changements devant être appliqués au produit lors de livraisons futures. Les
items du Product Backlog incluent une description, un ordre, une estimation de la complexité
et de la valeur. Le Product Owner est responsable du Product Backlog dans son contenu, sa
disponibilité et son ordonnancement. Le Product Backlog évolue au fur et à mesure que le
produit et le contexte dans lequel il sera utilisé évoluent.
• Le Sprint Backlog : Il est l’ensemble des items sélectionnés pour le Sprint plus un plan
pour livrer l’incrément du produit et réaliser l’objectif du Sprint. Le Sprint Backlog est une
prévision que l’Équipe de Développement fait de la fonctionnalité qui sera présente dans le
prochain incrément et le travail nécessaire pour livrer cette fonctionnalité dans un incrément
« terminé »
3.2.2 L’équipe de Scrum
Scrum définit un modèle d’équipe optimisant la flexibilité, la créativité et la productivité.

L’équipe Scrum se compose de :
— Product Owner : est responsable de maximiser la valeur du produit et du travail de l’Équipe

de Développement. Il est la seule personne responsable de gérer le Product Backlog.
18
— Équipe de Développement : est constituée de professionnels qui produisent à chaque Sprint

un incrément « terminé » et potentiellement livrable du produit. Ils ont toutes les compétences
nécessaires pour effectuer le travail sans dépendre de personnes n’appartenant pas à l’équipe.
— Scrum Master : est responsable de s’assurer que Scrum est compris et mis en œuvre. Les
Scrum Masters remplissent leur rôle en s’assurant que l’Équipe Scrum adhère à la théorie, aux
pratiques et aux règles de Scrum.
3.2.3 Les événements de Scrum
Les événements prescrits par Scrum créent de la régularité et minimisent la nécessité d’autres
réunions non prévues. Tous les événements sont limités dans le temps, de telle sorte que chaque
événement ait une durée maximale.[9]
— Sprint : est une période (constante) d’un mois au maximum, au bout de laquelle l’équipe
délivre un incrément du produit, potentiellement livrable. Chaque Sprint doit avoir un objectif
qui est un but fixé et peut être réalisé par l’implémentation d’une partie du Product Backlog
— Daily Scrum : C’est une réunion de planification qui dure 15 minutes et permet aux développeurs
de faire un point de coordination sur les tâches en cours et sur les difficultés rencontrées.
— Sprint planning Meeting : Toute l’équipe Scrum est présente à cette réunion qui se fait
avant chaque Sprint, qui ne dure plus de 4 heures, pour planifier les user stories du backlog du
produit qu’elle a décidé de traiter pendant la prochaine itération et comment elle s’organisera
pour y parvenir.
— Sprint review : Pendant la réunion de revue de Sprint, l’Équipe Scrum et les parties prenantes
échangent sur ce qui a été fait durant le Sprint. La revue de Sprint est tenue à la fin du Sprint
pour inspecter l’incrément réalisé et adapter le Product Backlog si nécessaire.
— Sprint Retrospective : La rétrospective de Sprint survient après la revue de Sprint et avant

la prochaine réunion de planification de Sprint. C’est une occasion pour l’Équipe Scrum de
s’inspecter et de créer un plan d’amélioration qui sera mis en place au cours du Sprint suivant.
3.2.4 Fonctionnement de Scrum
L’équipe Scrum poursuit les étapes décrites précédemment jusqu’à ce que les objectifs soient
atteints, les opportunités soient maximisées, le retour sur investissement soit atteint ou un obstacle
19
insurmontable soit rencontré.
La figure 2.4 met en oeuvre tous les éléments afin de montrer le déroulement de travail au sein
de Scrum. [10]
Figure 2.4: Fonctionnement de Scrum
4 Le langage de modélisation UML
Afin de modéliser nos idées et les mettre sur papier, nous avons choisi UML. UML (Unified
Modeling Language) est un langage standard pour spécifier, visualiser, construire et documenter les
artefacts des systèmes logiciels
5 Les outils
Dans cette section, nous présentons les principaux outils utilisés pour la conception, le développement,
le versioning, et la rédaction de ce rapport.
20
5.1 PowerAMC Designer : Outils de modélisation
Figure 2.5: PowerAMC Designer
PowerAMC est un logiciel de conception créé par la société SDP, qui permet de modéliser les
traitements informatiques et leurs bases de données associées. Il a été créé par SDP sous le nom
AMC*Designor, racheté par Powersoft qui lui-même a été racheté par Sybase en 1995. Depuis 2010
Sybase appartient à l’éditeur allemand SAP.
5.2 Eclipse : Environnement de développement intégré
Figure 2.6: Eclipse IDE
Eclipse IDE est un environnement de développement intégré libre(le terme Eclipse désigne
également le projet correspondant, lancé par IBM) extensible, universel et polyvalent, permettant
potentiellement de créer des projets de développement mettant en œuvre n’importe quel langage de
programmation.
5.3 JIRA : Outils de gestion de projet agile
Figure 2.7: JIRA
JIRA Software est un outil de gestion de projet agile qui prend en charge toute méthodologie
agile, que ce soit scrum, kanban ou une au méthodologie spécifique. Des panneaux agiles aux rapports,
21
JIRA permet la planification, le suivi et la gestion de tous les projets de développement de logiciels
agiles à partir d’un seul outil.
5.4 Git et Bitbucket : Outils de versioning
Figure 2.8: Git et Bitbucket
Git est un logiciel de gestion de versions décentralisé. Il est conçu pour être efficace tant avec les
petits projets, que les plus importants. Contrairement à des outils comme svn ou cvs, Git fonctionne
de façon décentralisée, c’est-à-dire que le développement ne se fait pas sur un serveur centralisé,
mais chaque personne peut développer sur son propre dépôt. Git facilite ensuite la fusion (merge)
des différents dépôts.
Puisqu’on a pas le droit de partager le code au publique, nous avons choisi Bitbucket car il offre
des hébergements privée.
Bitbucket est un service web d’hébergement et de gestion de développement logiciel utilisant les
logiciels de gestion de versions Git. Le figure 2.9 présente un extrait de commits de notre projet sur
Bitbucket
Figure 2.9: Des commits sur Bitbucket
22
5.5 LaTex : Outils de rédaction du rapport
Figure 2.10: Latex
Nous avons utilisé LaTeX pour la rédaction du rapport, LaTex est un système de composition
de haute qualité. Il comprend des fonctionnalités conçues pour la production de documentation
technique et scientifique. LaTeX est la norme de facto pour la communication et la publication de
documents scientifiques.[11]
Conclusion
Dans ce chapitre, nous avons étudié les deux plates-formes Alfresco et Averroès de point de
vue fonctionnelle,architecturale, et technique, et nous avons vu comment développer et ajouter
des fonctionnalités dans Alfresco et quelles méthodes ArchiveYourDocs suit dans le développement
d’Averroès. Par la suite, nous avons présenté la méthodologie Scrum et les différents outils utilisés
afin d’accomplir le travail.
23
Chapitre 3
Analyse et spécification des besoins
1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Chapitre 3. Analyse et spécification des besoins
Introduction
L’analyse et la spécification des besoins représentent une étape fondamentale dans un cycle
de vie de développement d’une solution, elle conduit à construire une bonne vision du produit, à
identifier les rôles des utilisateurs et à dégager les fonctionnalités principales afin de produire le
backlog initial. Cette phase fera donc l’objet de ce chapitre où nous commençons par la capture des
différents besoins, l’identification des rôles des utilisateurs et la préparation du backlog de produit.
1 Analyse des besoins
L’analyse des besoins est l’une des premières étapes du déroulement d’un projet. La complexité
de l’analyse des besoins est aussi due à leurs nombreuses facettes. Il existe des besoins exprimés
naturellement, des besoins implicites, des besoins inavoués et tout simplement des besoins dont les
utilisateurs n’ont même pas conscience, elle est alors une démarche qui consiste à rechercher et à
caractériser les fonctions offertes par un projet pour satisfaire les besoins de son utilisateur.
1.1 Identification des acteurs
Un acteur représente l’abstraction d’un rôle joué par des entités externes (utilisateur, dispositif
matériel ou autre système) qui interagissent directement avec le système étudié.[12]
Tous simplement un acteur est une entité physique (personne) ou abstraite (logiciel) capable
d’utiliser le système afin de répondre à un besoin bien défini. Il peut consulter ou modifier l’état du
système, en émettant ou recevant des messages susceptibles d’être porteurs de données.
Nous pouvons distinguer, dans notre système, 2 acteurs principaux :
— Administrateur : il a le droit d’accéder à tous.
— Employé : sont droit d’accès et définie par le groupe utilisateur qu’il l’appartient.
1.2 Les besoins fonctionnels
Les besoins fonctionnels correspondent aux fonctionnalités que notre module doit offrir. Après
des discussions avec les consultants et les responsables du produit d’ArchiveYourDocs nous avons
25
dégagé les besoins fonctionnels suivants classés par acteurs :
• Administrateur
— Définir, modifier supprimer, et consulter une délégation qui se caractérise par le délégué,
le remplacé, les dates de début et de fin de la délégation.
— La possibilité de donner à un autre utilisateur le droit d’accéder à l’interface de gestion

des délégations.
• Employé
— Lister les utilisateurs qu’il remplaces
— Accéder facilement aux tâches des personnes qu’il remplaces
— Effectuer les tâches des personnes qu’il remplaces
— Lancer des processus au nom des personnes qu’il remplaces
1.3 Les besoins non fonctionnels
Les besoins non fonctionnels ont un aspect visible pour l’utilisateur, mais ne sont pas en rapport
direct avec le comportement du système. Ce sont les contraintes techniques du système et les besoins
qui le caractérisent. Les exigences qu’on doit les satisfaire sont :
— La sécurité : l’utilisateur délégué ne doit pas avoir accès ni par lecture ni écriture sur des
informations confidentielles de l’utilisateur remplacé.
— Traçabilité : La possibilité de savoir les actions réalisés par les utilisateurs.
— L’utilisabilité : les interfaces du module à ajouter doivent être simples, conviviales et faciles
à utiliser. Elle renseigne l’utilisateur sur le contexte dans lequel il se trouve.
— La compatibilité : Les interfaces du module à ajouter doivent respecter le même thème,

charte graphique, et la forme d’Averroès.
— Responsive : pour une utilisation optimale, les interfaces doivent être adaptées à toutes les
résolutions.
— La performance : le temps de réponse et le chargement des données doivent être minimaux.

La navigation d’une interface à une autre ne doit pas gêner l’utilisateur.
— La fiabilité : le système devra avoir un fonctionnement fiable et sécurisé assurant l’intégrité

des données.
26
— Robustesse : en présence de données invalides, le système doit gérer les exceptions pour
garantir un fonctionnement stable.
2 Product Backlog
Comme il est décrit précédemment, le Product Backlog est l’ensemble des caractéristiques
fonctionnelles qui constituent le produit souhaité. Les caractéristiques fonctionnelles sont appelées
des histoires utilisateurs (user story). Les user stories sont caractérisés par :
— Identifiant Il détermine un identifiant unique pour l’histoire en question.
— Description Elle décrit le besoin d’un acteur.
— Critères d’acceptation À chaque user story sont associés des critères permettant au client
de tester l’histoire. Ces critères d’acceptation peuvent être formalisés, pour aller un peu plus
loin dans l’aide fournie à l’équipe que l’énoncé de ces critères.
— Estimation Est une estimation de la complexité, elle est une valeur entière qui appartient à
la suite de Fibonacci.
— Priorité Les priorités sont utilisées pour définir l’ordre de réalisation, elles permettent de
constituer le flux de stories qui va alimenter l’équipe. Pour prioriser nos user stories, nous
avons pris en compte les critères suivant :
• La valeur apportée (Business Value)
• La fréquence d’utilisation
• La réduction des risques
• L’incertitude sur des besoins des utilisateurs qu’un user story permettra de diminuer
• La contribution à la qualité. Les travaux visant à garantir la qualité du produit devraient

être prioritaires
• Les dépendances entre stories
Lors de la création de notre Backlog, nous avons essayé de produire des user stories qui respectent
les critères réunies dans le mot INVEST, c’est à dire
— Independant : Ne dépend de rien (réduire les liens entre items)
— Negociable : Je n’ai pas une solution technique figée
— Valuable : pour le client (a une valeur Business)
27
— Estimable : Estimation en complexité
— Small / Sized Appropriately : De petite taille (A définir en interne de l’entreprise)
— Testable : Pour la validation de l’item
Le tableau 4.1 présente le Product Backlog de notre module.
Tableau 3.1: Product Backlog
ID User story Critère d’acceptation Priorié Est
AD-6 En tant qu’administrateur, L’accès doit être à partir de la barre de 1 3

je veux avoir un accès à la menu (header)
gestion des délégations L’accès doit être sous le menu
console-admin
AD-7 En tant qu’administrateur, La page doit être séparée des autres 2 2

je veux avoir une page de pages d’administration, La page doit
gestion des délégations respecter le thème d’Averroès
AD-1 En tant qu’administrateur, je Le formulaire doit contenir 3 5

veux ajouter des règles de • Choix du délégué et la personne
délégation absente
• Choix de la date de début et la

date de fin de la délégation
• 3 cases à cocher (droit sur

les tâches, les processus, et la
bibliothèque des documents
Tous les champs du formulaire sont

obligatoires.
Le formulaire doit être dans une boite
de dialogue
AD-2 En tant qu’administrateur, le formulaire doit avoir les mêmes 4 3

je veux modifier les règles caractéristiques du formulaire de l’ajout
existantes
28
AD-3 En tant qu’administrateur, chaque élément doit avoir un bouton 5 2

je veux supprimer les règles supprimer
existantes une boite de dialogue de confirmation
doit apparaître avant la suppression
AD-4 En tant qu’administrateur, La liste doit contenir tous les champs de 6 5

je veux lister les règles de la délégation
délégation
AD-5 En tant qu’administrateur, Chaque élément doit avoir une case à 7 3

je veux avoir des actions cocher pour la sélection
multiples sur des éléments Les actions sur la sélection multiple
sélectionnés doivent être : dupliquer, supprimer
AD-9 En tant qu’utilisateur Une liste déroulante dans la barre 8 8

délégué, je veux lister les des menus qui contienne les noms des
utilisateurs que je remplace utilisateurs
AD-10 En tant qu’utilisateur L’utilisateur connecté d’une session 9 8

délégué, je veux choisir un déléguée ne doit pas avoir accès aux
utilisateur pour effectuer ses paramètres du profil et aux délégations
tâches de cet utilisateur
AD-12 En tant qu’utilisateur Le déroulement de l’exécution des tâches 10 5

délégué, je veux avoir accès doit s’effectuer normalement (même
sur les tâches courantes de interface, même déroulement des tâches
l’utilisateur que je remplace d’Averroès)
Les tâches doivent être exécutées au
nom de l’utilisateur délégué
AD-13 En tant qu’utilisateur L’utilisateur délégué doit avoir tous les 11 5

délégué, je veux avoir droits d’accès sur les documents
accès sur les documents de du délégateur (lecture, écriture,
l’utilisateur substitué modification . . . )
Cette action ne peut pas être effectué
sauf si le délégué est permis
29
AD-14 En tant qu’utilisateur Le déroulement de lancement de 12 5

délégué, je veux lancer processus doit s’effectuer normalement
des processus au nom de (même interface, même déroulement
l’utilisateur substitué des tâches d’Alfresco)
Les tâches doivent être exécutées au
nom de l’utilisateur délégué
Cette action ne peut pas être effectué
sauf si le délégué est permis
AD-17 En tant qu’utilisateur, La colonne contient le nom de 13 8

je veux avoir une l’utilisateur qui a effectué la tâche
colonne "délégation" dans si elle est effectuée à partir d’une
l’historique des tâches délégation
La colonne doit être vide si la tâche est
effectuée normalement
AD-15 En tant qu’administrateur, Après donner le droit à l’utilisateur, 14 5

je veux donner le droit il doit avoir un accès à l’interface de
à un utilisateur (non gestion des délégations à partir de la
administrateur) de gérer barre de menus
les délégations la permission (don du droit) doit être de
la même interface de gestion des rôles
AD-16 En tant qu’administrateur, je Lorsque l’utilisateur est supprimé de la 15 5

veux interdire un utilisateur liste, il ne doit plus avoir l’accès à partir
d’accéder à l’interface de de la barre de menu
gestion des délégations
AD-18 En tant qu’administrateur je L’accès à l’interface d’audit doit être 16 5

veux avoir des audits sur ajouté aux accès d’audits existants
les connexions à partir d’une Les colonnes de l’audit sont : Utilisateur,
délégation Action, Date, Valeurs (information
supplémentaire), Résultat (succès,
échec)
30
AD-56 En tant qu’administrateur, je L’interface de la liste doit être sous « 17 8

veux ajouter des personnes à gestion des rôles d’administration » de
la liste de gestion des rôles la console d’administration
L’interface de gestion des droits doit
contenir une zone de texte avec
auto complétion pour la recherche des
utilisateurs
Lorsque l’utilisateur est choisi, il doit
être ajouté à la liste
AD-8 En tant qu’administrateur, Filtre par personne déléguée, absent, 18 5

je veux filtrer les règles de date de début, date de retour.
délégation Filtre des délégations ajoutées
récemment
La figure 3.1 présente notre Backlog de produit trié par priorité et déployé dans l’outil JIRA.
31
Figure 3.1: Product Backlog dans JIRA
Conclusion
L’analyse des besoins nous a permis d’avoir une vision plus claire sur le sujet et une compréhension
plus profonde des tâches à réaliser. Elle a mené aussi à la définition du Product Backlog qui va être
la base de la réalisation de notre module.
32
Chapitre 4
La réalisation
1 Sprint 1 : Gestion des délégations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2 Sprint 2 : Mise en oeuvre des délégations . . . . . . . . . . . . . . . . . . . . . . . . 45
3 Sprint 3 : Droit d’accès et traçabilité . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Chapitre 4. La réalisation
Introduction
Puisque Scrum est choisi comme méthode de gestion de projets, ce chapitre va être réparti selon
les exigences de Scrum, en effet, le travail est divisé en Sprints, chacun d’eux a lieu de définir le but
et le Sprint Backlog dans un premier temps, ensuite nous présentons la conception et la réalisation.
Enfin, nous clôturons chaque Sprint par sa revue et une rétrospective.
1 Sprint 1 : Gestion des délégations
La réunion de planification de Sprint (Sprint Planning Meeting) se passe en deux temps. Dans le
premier temps, l’équipe de développement établit le contenu du prochain sprint. Elle s’appuie sur le
Backlog du produit priorisé, sur les informations des sprints passés et sur la capacité de production
prévue pour la prochaine itération. La conclusion de ce premier temps est la formulation du but du
sprint. Dans un second temps, l’équipe se focalise sur la manière dont ses membres atteindront le
but du sprint. Ils prévoient alors ce qui sera fait pendant le sprint en identifiant les tâches à réaliser
avec une estimation. Cette estimation tient compte de la vélocité de l’équipe et peut intégrer une
provision pour absorber les imprévus de la période.[13]
Suite à une étude sur la division du projet basée sur ce que nous avons présenté dans le Backlog
du produit, nous avons décidé le but suivant "gestion des délégations", c’est-à-dire, nous allons
essayer dans ce sprint de créer tous les éléments intervenants dans la définition et la gestion des
délégations.
1.1 Sprint Backlog
Une fois le but est défini, il est temps de désigner quelles user stories incluant dans ce sprint
afin d’atteindre ce but. Le tableau suivant présente le Sprint Backlog contenant les items choisis à
partir du Product Backlog ainsi que les tâches à faire pour les accomplir.
34
Tableau 4.1: Sprint Backlog : Gestion des délégations
ID User Story Tâches
AD-7 En tant qu’administrateur, je veux avoir - Ajout de template-instance

une page de gestion des délégations - Développement de page (ftl)
- Configuration de la page dans le contexte
spring-surf
AD-6 En tant qu’administrateur, je veux avoir - Ajout du lien au menu (header) avec tous les
un accès à la gestion des délégations tests de droit d’accès
- Création du patch pour créer la liste
AD-1 En tant qu’administrateur, je veux - Ajout du model

ajouter des règles de délégation - Configuration du contexte Spring
- Configuration share-custom
- Code de création de la liste
AD-2 En tant qu’administrateur, je veux - Configuration share

modifier les règles existantes - Configuration repo
AD-3 En tant qu’administrateur, je veux - Configuration share

supprimer les règles existantes - Configuration repo
AD-4 En tant qu’administrateur, je veux lister - Intégration du DataGrid Webscript dans la

les règles de délégation page de gestion des délégations
- Configuration du template-instance
AD-5 En tant qu’administrateur, je veux avoir - Intégration du Toolbar Webscript dans la

des actions multiples sur des éléments page de gestion des délégations
sélectionnés - Configuration du template-instance
- Ajout de tool-bar dans la page ftl
AD-8 En tant qu’administrateur, je veux - Intégration du Filter Webscript dans la page

filtrer les règles de délégation de gestion des délégations
- Configuration du template-instance
- Ajout du filtre dans la page ftl
Pour avoir une vision globale du comportement fonctionnel des user stories de ce sprint, nous
avons choisi le diagramme de cas d’utilisation.
35
1.2 Diagramme de cas d’utilisation
Les diagrammes de cas d’utilisation sont des diagrammes UML utilisés pour donner une vision
statique et globale du comportement fonctionnel d’un système logiciel. La figure suivante présente
le diagramme de cas d’utilisation du premier sprint.
Figure 4.1: Diagramme de cas d’utilisation Sprint 1
Le diagramme ci-dessus résume les fonctionnalités que l’utilisateur peut les avoir après ce sprint.
Pour avoir une vision plus claire et dynamique sur chaque cas d’utilisation nous allons utiliser le
diagramme de séquence système.
1.3 Diagrammes de séquence système
Les diagrammes de séquences sont la représentation graphique des interactions entre les acteurs
et le système selon un ordre chronologique dans la formulation UML. Nous présentons par la suite
les diagrammes de séquence système des cas d’utilisation classés plus importants.
Le diagramme illustré par la figure 4.2 correspond au cas d’utilisation "Ajouter délégation".
36
l’utilisateur doit choisir le délégué, l’utilisateur à remplacer, et remplir tous les éléments du formulaire.
Figure 4.2: Diagramme de séquence système Ajouter délégation
La figure 4.3 présente le digramme de séquence système "Modifier délégation". L’utilisateur peut
modifier les valeurs voulus sans obligation.
37
Figure 4.3: Diagramme de séquence système Modifier délégation
La figure 4.4 présente le digramme de séquence système "Suppression multiple".
38
Figure 4.4: Diagramme de séquence système Suppression multiple
Une fois que nous avons décrit les principaux cas d’utilisation, nous avons besoin de voir les
enchaînements possibles entre ces différents cas d’utilisation.
1.4 Diagramme d’activité
Le diagramme d’activité est un diagramme comportemental d’UML, il est utilisé pour modéliser
un flux de travail dans un cas d’utilisation ou entre plusieurs cas d’utilisation, ou encore pour décrire
la logique d’une opération.
La figure 4.5 présente le diagramme d’activité du premier Sprint qui décrit un enchaînement
de déroulement des cas d’utilisation présentés dans la figure 4.1. Dans notre cas, chaque activité
correspond à un cas d’utilisation.
39
Figure 4.5: Diagramme d’activité Sprint 1
L’utilisateur commence par consulter la liste des délégations, par la suite, il peut faire n’importe
quelle activité, même il peut terminer l’enchaînement sans faire aucune activité.
1.5 La réalisation du sprint
Alfresco est une plate-forme puissante et riche en matière de fonctionnalité. Nous avons essayé
de profiter de cette richesse en utilisant ses composants et ses méthodes d’extension. Tout au long de
ce Sprint, nous avons travaillé principalement sur trois parties, l’ajout d’un élément dans le menu,
l’ajout de la page, et la gestion des délégations, nous présentons dans la suite nos solutions adoptés
pour chacune d’elles.
40
1.5.1 Gestion des délégations
La plupart des composants offerts par Alfresco servent à la gestion des documents et leur
classement, mais pour la gestion de données, il offre les Data-Lists.
Les Data-Lists sont des composants qui permettent aux utilisateurs de gérer des listes de données.
Ils sont des enregistrements de données stockées dans l’entrepôt Alfresco comme des nœuds. Il existe
un certain nombre de types des listes de données disponibles tel que la Contact List, Event List, et
autres, mais les listes personnalisées peuvent également être implémentées.
Pour ajouter son propre DataList, il faut ajouter un type qui hérite du type "dl :dataListItem" et
Alfresco va la reconnaître automatiquement. La figure 4.6 présente notre nouveau type "ipt :delegation"
et ses attributs et ses relations avec les types d’Alfresco.
Figure 4.6: Diagramme de classe Délégation
Maintenant, Alfresco gère notre Data-List de la façon suivante : Les éléments de délégation sont
stockés dans l’entrepôt comme étant des noeuds de type "ipt :delegation", et ont une agrégation
avec un noeud de type "dl :datalist" qui présente la liste des délégations, ce noeud reconnaît le type
de ses éléments avec l’attribut "dl :dataListItemType".
De point de vue graphique, Alfresco fonctionne avec des webscript qu’on peut les utiliser dans
notre page, ceci la liste des composants utilisé dans la page de gestion des délégations
41
— Data Grid : pour visualiser les items d’une liste avec les actions sur chaque item.
— Toolbar : pour faire des actions multiples
— Filter : pour appliquer des recherches
1.5.2 La page de gestion des délégations
L’application web Share est constituée d’un menu principal à partir duquel on peut naviguer
vers plusieurs pages. Ces pages sont implémentées avec le framework Spring Surf, et nommées des
pages Surf.
Mettre ensemble une page Surf implique beaucoup d’objets , tels que page, template-instance,
composant etc. . . La figure 4.7 présente les différents éléments intervenants dans la création d’une
page Surf.
Figure 4.7: Modèle de page Surf
Lors de la définition de la page Surf, il faut indiquer le template-instance associé à cette page. Le
template-instance contient les composants à utiliser dans cette page,généralement ces composants
font appel à des webscript et appartiennent à une région. Le template est une page (.ftl) qui contient
du code html et des annotations propres à Spring Surf, serves à produire l’interface utilisateur voulu.
Après l’implémentation de notre page de gestion des délégations avec Spring Surf, nous pouvons
maintenant utiliser les composants de Data-List fournis par Alfresco comme étant des webscripts.
42
1.6 Revue du Sprint
Le but de la revue est de montrer ce qui a été réalisé pendant le sprint afin d’en tirer les
conséquences pour la suite du projet. Cette partie présente les interfaces utilisateur produites dans
ce Sprint. La figure 4.8 présente le lien d’accès ajouté au sous menu de la console d’administration
Figure 4.8: Accès de la gestion des délégations
Les figures 4.9, 4.10, et 4.11 présentent respectivement la page de consultation des délégations,
le menu des actions multiples, et le dialogue de l’ajout d’un enregistrement.
Figure 4.9: Page de consultation des délégations
43
Figure 4.10: Les actions multiple
Figure 4.11: Dialogue d’ajout d’une délégation
Après la revue nous n’avons pas trouvé utile de laisser les filtres, donc nous avons décidé de les
enlever de l’interface de gestion.
44
1.7 Rétrospective
La rétrospective étudie ce qui a bien marché et ce qui a mal marché dans le sprint passé. Nous
commençons par l’étude du Burndown Chart généré par JIRA.
Le Burndown Chart est une représentation graphique de l’évolution de quantité de travail

restante par rapport au temps sur une période de temps donnée. Le travail restant se situe sur
l’axe vertical, alors que le temps est sur l’axe horizontal.
Figure 4.12: Burndown Chart Sprint 1
Le graphe présenté montre qu’on a pas trouvé des problèmes de mauvaises estimations du temps
par rapport aux user stories prévus.
En général, tout est bien marché dans ce premier Sprint sauf l’intégration des filtres qui a été
développée à la fin du Sprint avec un peux de retard.
2 Sprint 2 : Mise en oeuvre des délégations
En partant sur le même principe que le sprint précédent, nous commençons par définir le but de
notre second sprint. Suite à une étude sur les priorités des user stories restantes, nous avons décidé
de travailler sur le coeur de notre module qui est la Mise en oeuvre des délégations, c’est à dire
qu’après ce sprint le délégué peut avoir la possibilité faire des actions au nom d’un autre utilisateur,
45
tout en respectant les restrictions définies par ce qui est fait dans le premier sprint.
2.1 Sprint Backlog
Le tableau 4.2 présente le Sprint Backlog de la mise en oeuvre des délégations.
Tableau 4.2: Sprint Backlog : Mise en oeuvre des délégations
AD-9 En tant qu’utilisateur - Mise en place de la couche DAO des délégations

délégué, je veux lister les - Implémentation du web script qui liste les délégations
utilisateurs que je remplace de l’utilisateur courant, coté repo
- Consommation du webscript créé à partir du header
(coté share)
- Ajout de la liste déroulante dans le header
AD-10 En tant qu’utilisateur - Implémentation du service d’authentification

délégué, je veux choisir un personnalisé
utilisateur pour le remplacer - Ajout de la chaine d’authentification
- Implémentation du webscript d’authentification
spécifique coté repo
- Implémentation du webscript qui détermine si la
session courante est déléguée ou non
- Implémentation du webscript d’authentification
spécifique coté share
- Restriction de visualisation du profile si la session est
délégué
AD-12 En tant qu’utilisateur - Implémentation du webscript de droit d’accès sur les

délégué, je veux avoir un accès tâches coté repo
sur les tâches courantes de - Ajout de traitement de récupération du droit dans le
l’utilisateur que je remplace webscript du header
46
AD-13 En tant qu’utilisateur délégué - Implémentation du webscript de droit d’accès sur les
je veux lancer des processus processus coté repo
au nom de l’utilisateur - Ajout de traitement de récupération du droit dans le
substitué webscript du header
AD-14 En tant qu’utilisateur délégué - Implémentation du webscript de droit d’accès sur la

je veux avoir un accès sur bibliothèque des documents coté repo
les documents de l’utilisateur - Ajout de traitement de récupération du droit dans le
substitué webscript du header
La figure 4.13 présente de le diagramme de cas d’utilisation du Sprint courant.
47
Chaque cas d’utilisation de ce diagramme présente une user story, le Product Backlog contient
une description détaillée de ces user stories.
La figure 4.14 présente le diagramme d’activité de notre module.
Nous pouvons remarquer que le diagramme d’activité a évolué par rapport au premier Sprint,
cette évolution est due grâce aux nouvelles fonctionnalités ajoutés dans ce Sprint.
Après qu’il liste ses délégations courante, l’utilisateur peut effectuer des tâches ou lancer des
processus ou gérer les documents de l’utilisateur qu’il remplace.
48
2.4 Diagrammes de séquence détaillés
Le diagramme de séquence détaillé montre l’interaction entre l’utilisateur est les différentes
parties du système. Puisque notre système est composé des deux parties Share (client) Repo (l’entrepôt),
nous avons décidé de montrer dans ces diagrammes les échanges entre eux.
La figure 4.15 présente le diagramme de séquence détaillé du cas d’utilisation Lister ses délégations
courante.
Figure 4.15: Diagramme de séquence détaillé Lister ses délégations courante
La figure 4.16 présente le diagramme de séquence détaillé qui correspond au cas d’utilisation
Remplacer utilisateur.
49
Figure 4.16: Diagramme de séquence détaillé Remplacer utilisateur
Il est à remarquer que ce denier diagramme contient une référence au diagramme qui le précède.
Les échanges entre le Share et le Repo sont avec les webscripts présentée dans la section 1.3.2.
Parmi les tâches réalisées dans ce sprint, il y en a quelques tâches qu’il ne faut pas passer sans
mettre l’accent sur eux. Par la suite, nous présentons les solution adoptées pour accomplir ces tâches.
L’authentification
La délégation ou la Mise en oeuvre des délégations est le fait qu’un utilisateur remplace un autre
pour éviter les blocages dans les processus métier. Au début, nous avons opté à la réassignation des
tâches de la personne substituée à la personne déléguée pendant la période de délégation, mais il
existe des processus où l’utilisateur doit attacher ou modifier un document de processus, du coût,
nous avons trouvé des problèmes de droit d’accès.
Après beaucoup de recherche, nous avons trouvé qu’Alfresco donne la possibilité d’implémenter
un service d’authentification personnalisé, cela est utilisé souvent pour permettre aux autres systèmes
50
externes d’accéder au contenu d’Alfresco. Donc, nous avons opté à l’implémentation de notre service
d’authentification qui va nous permettre de donner la main à un utilisateur de se connecter au
compte de son partenaire sans la saisie du mot de passe.
Le service d’authentification dans Alfresco, sont implémenté en tant que sous-système (subsystem).
Les sous-systèmes sont des modules configurables responsables d’une fonctionnalité dans Alfresco
Content Services. Il est possible de mettre en œuvre une extension en tant que sous-système personnalisé,
et c’est ce que nous avons fait pour implémenter notre service d’authentification.
Le fonctionnement de notre service dépend des délégations définies à partir de leur interface de
gestion, lorsqu’il reçoit le nom de l’utilisateur, il vérifie s’il y a une délégation entre cet utilisateur
et l’utilisateur courant, si oui, il ouvre une session avec le nom envoyé et il renvoie un ticket.
Le ticket est une chaîne de caractères générée par Alfresco pour chaque session et utilisée par le
Share pour appeler les services du Repo sans avoir besoin de s’authentifier dans chaque appel.
Après l’authentification avec notre nouveau service, la partie Share récupère le ticket et l’utilise
pour les prochains appels des webscripts.
Type de session
Lorsqu’un utilisateur a une session déléguée, c’est à dire qu’il est connecté du service d’authentification
que nous avons implémenté, il ne doit pas avoir accès a quelques rubriques telle que le changement
de mot de passe et la modification du profil, donc, dans chaque instant il faut savoir si la session
courante est déléguée, nous avons trouvé un problème dans ce point car lorsqu’une session est ouverte,
Alfresco ne peut plus savoir de quel service d’authentification elle est venue.
Pour résoudre ce problème, nous avons cherché sur l’élément que sa durée de vie est liée à la
durée de vie d’une session, et nous l’avons trouvé, c’est le ticket.
Donc, lors de l’ouverture d’une session déléguée, on garde le ticket, et lorsqu’on a besoin de
savoir si la session courante est déléguée ou non, on compare son ticket avec le ticket gardé, s’ils sont
égaux, alors la session est déléguée. Ce traitement est implémenté dans un webscript appelé lors du
besoin de savoir le type de la session.
51
2.6 Revue du Sprint
La figure 4.17 présente la liste des délégations courante d’un utilisateur Dans ce cas l’utilisateur
"mohamed" a la possibilité de se connecter au nom de "owerfelli".
Figure 4.17: Liste des délégations courante d’un utilisateur
La figure 4.18 présente l’interface d’accueil d’une session déléguée sur le compte de "owerfelli",
on peut remarquer qu’il n’y a plus d’accès au profil utilisateur et au changement de mot de passe,
aussi, l’élément "Tâche" n’est plus disponible dans le menu principal, car le droit sur les tâches n’est
pas donné dans la définition de cette délégation.
Figure 4.18: Session déléguée
2.7 Rétrospective
Après avoir étudier le Burndown Chart du deuxième Sprint illustré par la figure 4.19, nous
pouvons remarquer que l’avancement du travail a été comme prévu et tout a bien passé.
52
3 Sprint 3 : Droit d’accès et traçabilité
En partant sur le même principe que les sprints précédents, nous commençons par définir le but
de notre dernier sprint. Le but de ce sprint est "Droit d’accès et traçabilité", c’est-à-dire la gestion
des droits d’accès sur la page de gestion des délégations et la traçabilité des actions faites par le
délégué.
3.1 Sprint Backlog
Le tableau 4.3 présente le Sprint Backlog du sprint courant.
Tableau 4.3: Sprint Backlog : Droit d’accès et traçabilité
AD-17 En tant qu’utilisateur, je veux - Ajout du script dans le taskListener

avoir une colonne "delegation" dans - Service de récupération de nom utilisateur
l’historique des tâches délégué
- Ajout de la colonne dans le composant Yahoo UI
53
AD-56 En tant qu’administrateur, je veux - Ajout du composant Yahoo UI

lister les personnes qui ont le droit - Ajout delegationModuleconfig.ftl
de gérer les délégations - Configuration du contexte Spring
AD-15 En tant qu’administrateur, je veux - Configuration du composant Yahoo UI pour

donner le droit à un utilisateur, de l’ajout
gérer les délégations - Développement coté Share
- Développement coté Repo
AD-13 En tant qu’administrateur, je veux - Configuration du composant Yahoo UI pour

interdire un utilisateur d’accéder à l’ajout
l’interface de gestion des délégations - Développement coté Share
- Développement coté Repo
AD-14 En tant qu’administrateur je veux - Ajout de composant Yahoo UI

avoir des audits sur les connexions à - Implémentation de l’ajout des audits lors de la
partir d’une délégation connexion d’un délégué
- Ajout de la colonne dans le composant Yahoo UI
54
Chaque cas d’utilisation de ce diagramme présente une user story, le Product Backlog contient
un description détaillée ces user stories.
3.3 Diagrammes de séquence système
Le diagramme illustré par la figure 4.21 correspond à l’ajout d’un utilisateur à la gestion des
permissions.
55
Figure 4.21: Diagrammes de séquence système Ajouter utilisateur à la gestion des permissions
Après l’ajout, l’utilisateur est permis à consulter la page de gestion des délégation, la figure 4.22
illustre le diagramme de séquence système "Interdire utilisateur".
Figure 4.22: Diagrammes de séquence système Interdire utilisateur
56
Il est à remarquer que ce denier diagramme contient une référence au diagramme qui le précède.
Figure 4.23: Diagrammes de séquence système Audit utilisateur
La figure 4.24 présente le diagramme d’activité final de notre module.
57
Maintenant, l’utilisateur peut visualiser le nom du délégué qui a effectué sa tâche. L’administrateur
peut ajouter un utilisateur à la gestion des permissions, après cet ajout, l’utilisateur est permis à
consulter la page de gestion des délégations, l’administrateur peut l’interdire de la voir comme il
58
peut passer à effectuer un audit sur les connexions d’une délégation.
3.5.1 Gestion des permissions
La gestion des permissions n’est pas une fonctionnalité native dans Alfresco, l’équipe d’ArchiveYourDocs
a développé ce module dans Averroès afin de gérer les permissions d’accès aux pages. Le module
contient la gestion des permissions d’accès à l’audit, le statistique, le designer des types de données,
le designer de workflows, et à l’outil d’administration. Dans ce sprint, nous avons ajouté la page de
délégation à gestion des permissions.
Comme tous les modules d’Averroès, la gestion des permissions est implémentée dans la partie
Repo et Share, le Repo contient la définition et la création des permissions, et le Share contient la
couche de présentation. Donc, lors de l’ajout de la gestion des permissions des délégations dans ce
module, nous avons ajouté les définitions, le code de création et de récupération des permissions
dans la partie Repo, ainsi que l’ajout d’un composant YUI dans le Share pour la consommation des
données retournées par le Repo et pour et la présentation.
YUI Yahoo User Interface est une bibliothèque JavaScript et CSS développée par Yahoo pour
créer des applications Web richement interactives. Alfresco utilise YUI dans la couche présentation
en combinaison avec d’autres frameworks.
3.5.2 Historique des tâches
L’interface utilisateur des historiques des tâches dans Averroès est créée avec YUI, les informations
qu’elle présente sont extraites des variables liées aux tâches, dites des variables de tâche. Pour ajouter
notre colonne, il faut ajouter le composant YUI ainsi que l’extraction de la valeur de la variable de
tâche, mais avant le faire, il faut ajouter cette variable ainsi que sa valeur dans toutes les tâches
utilisateur.
La modélisation des processus métier ce fait grâce au designer développé par l’entreprise, avant
de déployer un processus pour qu’il soit prêt à l’exécution, il passe par une étape qui s’intitule la
génération, dans cette étape Averroès génère le fichier (.bpmn) et d’autres fichiers qui vont être
59
utiliser par le moteur de workflow Actviti lors de l’exécution de ce processus.
Notre intervention est dans l’étape de génération, nous avons ajouté à un appel d’un script qui
détermine si la session courante est déléguée, si oui, et retourne le nom du délégué qui sera charger
dans la variable de tâche propre à la colonne de délégation dans l’historique.
3.6 Revue du Sprint
La figure 4.25 présente l’historique des tâches de "Oussama Werfelli" exécuté par "mohamed".
Figure 4.25: Historique d’une tâche
La figure 4.26 présente l’utilisateur "owerfelli" ajouté la gestion des permissions et est permis à
consulter la page de gestion des délégations.
60
Figure 4.26: Ajout d’un utilisateur à la gestion des permissions
La figure 4.27 présente la page de gestion des délégations ouverte par un utilisateur non-administrateur.
Figure 4.27: Interface de gestion des délégations ouverte par un utilisateur
3.7 Rétrospective
En partant sur le même principe des rétrospectives précédents, nous commençons par le Burndown
Chart du Sprint courant.
61
Comme le montre le graphe illustré par la figure 4.28, le travail planifié pour ce Sprint n’est pas
terminé, ces à cause de l’élimination du dernier user story " En tant qu’administrateur je veux avoir
des audits sur les connexions à partir d’une délégation ".
Conclusion
Nous avons présenté dans ce chapitre le déroulement de la réalisation du projet au sein de Scrum,
le projet a été réparti en trois Sprints, le premier est consacré pour la définition et la gestion de
délégation, le deuxième pour la mise en oeuvre des délégations, et le troisième pour la gestion de
droit d’accès et la traçabilité.
62
Conclusion générale
Au terme de ce rapport, nous pouvons conclure que ce stage de fin d’études nous a donné une
occasion opportune nous permettant de confronter l’acquis théorique à l’environnement pratique.
En effet, le stage nous a permis de mettre en pratique nos connaissances acquises tout au long
de notre formation et de les enrichir grâce à la réalisation d’un projet qui consiste en la conception
et la réalisation d’un module de délégation au sien du progiciel Averroès, ce module a répondu à la
question "Comment peut-on ajouter à Averroès un module qui permet à un utilisateur d’effectuer les
tâches de l’autre sans échange du mot de passe et tout en restreignant les droits d’accès du délégué ?"
Nous avons essayé tout au long de notre travail de construire notre module incrément par
incrément en utilisant la méthodologie Scrum.
Nous avons commencé dans un premier lieu par comprendre le contexte général de notre projet
et pourquoi ce projet doit-il réaliser, ensuite nous avons fait une étude préalable afin de découvrir
les technologies et les outils à utiliser, et choisir la méthodologie à suivre.
Nous avons passé par la suite à analyser les besoins en déduisant le Product Backlog, la
priorisation de ce dernier nous a mené à une première planification.
Nous avons, par ailleurs, étudié les différents Sprints de notre backlog, pour obtenir une conception
qui met l’accent sur l’aspect statique et dynamique du système décrivant minutieusement l’aspect
métier de la solution. Ensuite, pour chaque sprint, nous avons abordé l’étape du développement au
cours de laquelle nous avons expliqué les principales tâches effectuées, et nous le finissons par une
revue et rétrospective.
En parvenant à la mise en place de ce projet nous avons acquis
— Une maîtrise des notions de ECM, BPM, BPMN
— Une maîtrise des concepts d’Alfresco tels que Content Model, DataList, Webscript etc. . .
— Une maitrise de la méthodologie Scrum.
— Une maîtrise de l’utilisation des outils de gestion de projets et versioning
Sur le plan humain, ce stage nous a offert la possibilité d’améliorer nos capacités d’adaptation,
de communication et d’acquérir des facultés de collaboration avec l’environnement professionnel.
63
Conclusion générale
Certaines fonctionnalités peuvent être envisagées pour l’amélioration de notre module. L’ajout
d’un autre module qui gère les absences dans Averroès va nous permettre d’éliminer la phase de
la définition des délégations et de rendre l’opération plus intelligente en utilisant des algorithmes
d’apprentissage automatique.
64
Bibliographie
[1] What is enterprise content management (ecm) ? [En ligne]

Disponible sur : http://www.aiim.org/What-is-ECM-Enterprise-Content-Management
[Consulté le 18-04-2017].
[2] Business process management. [En ligne]

Disponible sur : http://www.e-vitalis.com/index.php/business-process-management [Consulté
le 18-04-2017].
[3] Définition des processus métier. [En ligne]

Disponible sur : http://fr.appian.com/about-bpm/definition-of-a-business-process/ [Consulté
le 18-04-2017].
[4] Bpmn 2.0. [En ligne]

Disponible sur : http://www.bpmb.de/images/BPMN2_0_Poster_FR.pdf [Consulté le
18-04-2017].
[5] Alfresco activiti. [En ligne]

Disponible sur : https://www.alfresco.com/fr/products/business-process-management/
alfresco-activiti [Consulté le 18-04-2017].
[6] Alfresco docs. [En ligne]

Disponible sur : http://docs.alfresco.com [Consulté le 20-03-2017].
[7] J. Potts. Introduction to the web script framework. [En ligne]

Disponible sur : http://ecmarchitect.com [Consulté le 08-05-2017].
[8] Manifeste pour le développement agile de logiciels. [En ligne]

Disponible sur : http://agilemanifesto.org/iso/fr/manifesto.html [Consulté le 05-05-2017].
[9] K. Schwaber et J. Sutherland, SCRUM Guide, February 2010.
[10] What is scrum ? [En ligne]

Disponible sur : https://www.scrum.org/resources/what-is-scrum [Consulté le 25-04-2017].
[11] Latex – a document preparation system. [En ligne]

Disponible sur : https://www.latex-project.org/ [Consulté le 13-05-2017].
[12] P. Roques et F. Vallee, UML 2 en action.. De l’analyse des besoins à la conception. Eyrolles,
2007.
65
Bibliographie
[13] La réunion de planification de sprint. [En ligne]

Disponible sur : http://www.e-marketing.fr/Thematique/academie-1078/fiche-outils-10154/
reunion-planification-sprint-308273.htm [Consulté le 04-05-2017].
66
ّ
‫ﻣﻠﺨﺺ‬
‫ﯾﻨﺪرج ھﺬا اﻟﻌﻤﻞ ﺿﻤﻦ ﻣﺸﺮوع ﺧﺘﻢ اﻟﺪراﺳﺎت ﻟﻠﺤﺼﻮل ﻋﻠﻰ ﺷﮭﺎدة ﻣﮭﻨﺪس ﻓﻲ ھﻨﺪﺳﺔ اﻟﺒﺮﻣﺠﯿﺎت ﻣﻦ اﻟﺠﺎﻣﻌﺔ اﻟﺨﺎﺻّﺔ‬
‫ واﻟﺬي ﯾﮭﺪف‬IP-TECH Group‫ اﻟﺘﺎﺑﻌﺔ ﻟـ‬ArchiveYourDocs ‫ﻟﺘﻜﻨﻮﻟﻮﺟﯿﺎ اﻟﻤﻌﻠﻮﻣﺎت وإدارة اﻷﻋﻤﺎل داﺧﻞ اﻟﺸﺮﻛﺔ‬
‫ وھﻮ‬Averroès ‫ ﯾﺘﻤﺜﻞ ھﺬا اﻟﻤﺸﺮوع ﻓﻲ ﺗﺼﻤﯿﻢ وﺑﺮﻣﺠﺔ ﻣﺤﻮر ﻹدارة اﻟﺘﻔﻮﯾﻀﺎت ﻓﻲ‬.Averroès ‫إﻟﻰ ﺗﻄﻮﯾﺮ اﻟﺒﺮﻧﺎﻣﺞ‬
.Scrum‫ وﻗﺪ ﺗﻤﺖ إدارة ھﺬا اﻟﻤﺸﺮوع ب‬،Progiciel de BPM et ECM
Alfresco ،BPM ،ECM ،Java EE ،Scrum :‫ﻛﻠﻣﺎت ﻣﻔﺗﺎح‬
Résumé
Le présent travail, effectué au sein de l’entreprise ArchiveYourDocs filiale du groupe IP-TECH,
s’inscrit dans le cadre du stage de fin d’études pour l’obtention du diplôme d’ingénieur Génie
Logiciel de l’université privée de Technologies de l’Information et Management des
Entreprises et qui vise à améliorer la solution Averroès. Ce projet consiste à la conception et le
développement d’un module de gestion des délégations dans le progiciel de BPM et ECM
Averroès, la gestion de ce projet a été avec Scrum.
Mots clé : Scrum, Java EE, ECM, BPM, Alfresco
Abstract
The present work, performed within the company ArchiveYourDocs, a subsidiary of the IP-
TECH group, is part of the internship for the graduation of Software Engineering degree from
the private university of Technologies Information and Management of Enterprises and which
aims to improve the solution Averroes. This project consists of the design and development of
a delegation management module in the BPM and ECM Averroes software package, the
management of this project was with Scrum.
Key world: Scrum, Java EE, ECM, BPM, Alfresco

TIME Private Higher School: Republique Tunisienne Ministere de L'Enseignement Superieur Et de La Recherche Scientifique

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TIME Private Higher School: Republique Tunisienne Ministere de L'Enseignement Superieur Et de La Recherche Scientifique

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE TUNISIENNE

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR

Ecole Supérieure Privée des Technologies de l’Information et de Management de l’Entreprise

TIME Private Higher School

Projet de Fin d’Etudes

Développement et intégration d’un module de gestion de délégations dans

Encadré par : - M. Slim Mesfar Réalisé par : Oussama Werfelli

Année universitaire : 2016/2017.

En cette fin d’année je dédie ce projet

A toute personne m’ayant accompagné

Par une parole, un geste ou même une pensée,

A tous ceux ayant contribué

De prêt ou de loin à cette finalité ;

Merci pour tout

Ceci étant pour le général, vient maintenant le particulier

Avec une distinction bien méritée

Pour mon père préféré

Sans qui, je n’y serai jamais arrivé,

A ma chére mère, mes frères Mohamed Amine et Moataz, et ma soeur Tayssir

Et finalement et tout particulièrement à Katr Ennada, la personne qui a été toujours

Je tiens à présenter mes reconnaissances et mes vifs remerciements à mon professeur

J’adresse mes sincères remerciements à Monsieur Oussama Saidi, mon encadrant à la

Chapitre 1 Contexte Général du projet 3

Chapitre 2 Étude préalable 8

5.4 Git et Bitbucket : Outils de versioning . . . . . . . . . . . . . . . . . . . . . . . 22

Chapitre 3 Analyse et spécification des besoins 24

1.1 Logo IP-Tech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Architecture Alfresco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Product Backlog dans JIRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Diagramme de cas d’utilisation Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.1 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1 Sprint Backlog : Gestion des délégations . . . . . . . . . . . . . . . . . . . . . . . . . 35

AMP Alfresco Module Package. 15

AOP Aspect-oriented programming. 11

API Application Programming Interface. 15

BPM Business Process Management. 6, 16

BPO Business process outsourcing. 4

ECM Entreprise Content Management. 4–6, 16

IoC Inversion of Control. 11

ITO Information Technology Outsourcing. 4

ORM Object Relational Mapping. 11

SDK Software Development Kit. 15

ArchiveYourDocs, filiale du groupe IP-Tech cherche à améliorer sa solution de BPM et ECM.

outils techniques choisis.

Contexte Général du projet

Figure 1.1: Logo IP-Tech

Au tour de cette dernière activité l’entreprise ArchiveYourDocs est crée.

Figure 1.2: Logo ArchiveYourDocs

— Indexo : est un système d’indexation des documents numérisés.

— Compresso : est un outil de compression de documents PDF.

— Le Records Management : ArchiveYourDocs propose à ses clients l’adoption d’un Système

— Averroès : est un système de gestion documentaire et d’automatisation de processus métier

En conséquence, les collaborateurs dans l’entreprise affrontent un nouveau problème lors de la

— L’utilisateur doit avoir la possibilité de voir les personnes qu’il va remplacer.

3 Méthode de gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Le langage de modélisation UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.1 Alfresco de point de vue fonctionnelle

1.2 Alfresco de point de vue technique

1.2.1 Composants logiciels

— Java : Langage de programmation (coté serveur)

— JavaScript : Langage de programmation (coté client et coté serveur)

— Lucene : est une bibliothèque utilisé pour l’indexation et la recherche

— Freemarker : est un moteur de template