Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA

RECHERCHE SCIENTIFIQUE

UNIVERSITE TUNIS EL MANAR

INSTITUT SUPERIEUR D’INFORMATIQUE

RAPPORT DE STAGE DE FIN D’ETUDES

Présenté en vue de l’obtention du

Diplôme National de Licence Appliquée en Sciences et Technologies

Mention : Informatique

Spécialité : Systèmes Informatiques et Logiciels

Par

Rania SOLTANI

Encadrant académique Monsieur Ghaith MANITA

Encadrant professionnel Monsieur Foued AMEUR

Réalisé au sein de PicoSoft

Année Universitaire 2014/2015

Développement d’une application de gestion

des dossiers d’affaires sous Alfresco share

D�é�d�i�c�a�c�e

J�e �d�é�d�i�e �c�e �t�r�a�- �v�a�i�l À �m�a��m�è�r�e N�a�b�i�h�a� T�u� �m�'�as �d�o�n�n�é �l�a� �v�i�e, �l�a� �t�e�n�d�r�es�s��e

�e�t �l�e �c�o�u�r�a�g�e p�o�u�r� �r�é�us�s��i�r�. T�o�u�t �c�e �q��u�e j�e p�e�u�x �t'�o�f�f�r�i�r� �n�e p�o�u�r�r�a��e�xp�r�i�m�e�r� �l��a�m�o�u�r� �e�t �l�a� �r�e�c�o�n�n�a�is�s��a�n�c�e �q��u�e j�e �t�e p�o�r�t�e. E�n� �t�é�m�o�i�g�n�a�g�e, j�e �t'�o�f�f�r�e

�c�e �m�o�d�es��t�e �t�r�a�v�a�i�l p�o�u�r� �t�e �r�e�m�e�r�c�i�e�r� p�o�u�r� �t�es s��a�c�r�i�f�i�c�es �e�t p�o�u�r� �l��a�f�f�e�c�t�i�o�n� �d�o�n�t �t�u��m�'�as �t�o�uj�o�u�rs �e�n�t�o�u�r�é. À �m�o�n� p�è�r�e F�a�d�h�e�l L'�ép�a�u�l�e s��o�l�i�d�e, �l��o�e�i�l �a�t�t�e�n�t�i�f �c�o�mp�r�é h�e�n�-s��i�f �e�t �l�a� p�e�rs��o�n�n�e �l�a� p�l�us �d�i�g�n�e �d�e �m�o�n� �es��t�i�m�e �e�t �d�e �m�o�n� �r�es�p�e�c�t. A�u�c�u�n�e �d�é�d�i�c�a�c�e�n�e p�o�u�r�r�a�i�t �e�xp�r�i�m�e�r� �m�es s��e�n�t�i�m�e�n�ts, �q��u�e D�i�e�u� �t�e p�r�és��e�r�v�e �e�t �t�e p�r�o�c�u�r�e S�a�n�t�é �e�t�l�o�n�g�u�e �v�i�e. À �m�a� �t�r�ès �c h�è�r�e �f�a�m�i�l�l�e �q��u�i� �m�e s��o�u�t�i�e�n�t, �m�'�e�n�c�o�u�r�a�g�e �e�t �m�'�o�f�f�r�e �t�o�uj�o�u�rs�u�n� �m�i�l�i�e�u� �f�a�v�o�r�a�b�l�e, �u�n�e �a�m�b�i�a�n�c�e j�o�y�e�us��e �e�t �u�n�e �a�t�m�o�s�p�h�è�r�e j�o�v�i�a�l�e. À �m�o�n��f�r�è�r�e W�as�s��i�m� P�o�u�r� s��a� �c�o�mp�r�é h�e�ns��i�o�n�, s��o�n� s��o�u�t�i�e�n�, s��o�n� �t�e�n�d�r�es�s��e . . .Q�u�'�i�l

�t�r�o�u�v�e �i�c�i� �l��e�xp�r�es�s��i�o�n� �d�e �m�a� �r�e�c�o�n�n�a�is�s��a�n�c�e. À M�es �c h�e�rs A�m�is D h�o�u�h�a�,A�z�i�z �e�t M�aj�d�i�, j�e �v�o�us �d�é�d�i�e �c�e �t�r�a�v�a�i�l �e�n� �t�é�m�o�i�g�n�a�g�e �d�e �l��a�m�i�t�i�é s��i�n�-

�c�è�r�e �q��u�i� �n�o�us �l�i�e �e�t �d�es �b�o�ns �m�o�m�e�n�ts p�as�s��és �e�ns��e�m�b�l�e �e�t �à� �q��u�i� j�es��o�u�h�a�i�t�e �u�n� �a�v�e�n�i�r� �r�a�d�i�e�u�x �e�t p�l�e�i�n� �d�e �b�o�n�n�es p�r�o�m�es�s��es.

À �t�o�u�t�es �l�es p�e�rs��o�n�n�es �q��u�i� �m�'�o�n�t �a�i�d�é �à� �r�é�a�l�is��e�r��c�e �t�r�a�v�a�i�l, j�e p�r�és��e�n�t�e �m�es �v�i�fs �r�e�m�e�r�c�i�e-

�m�e�n�ts �e�t �l�es �e�xp�r�es�s��i�o�ns �r�es�p�e�c-�t�u�e�us��es �d�e �m�a� p�r�o�f�o�n�d�e

�g�r�a�t�i�t�u�d�e.♥

R�a�n�n�o�u�c h�

Remerciement

Avant d’entamer ce rapport de projet de fin d’études, je tiens à exprimer ma sincère gratitude

envers tous ceux qui m’ont aidé ou ont participé au bon déroulement de ce projet me permettant

d’acquérir une expérience professionnelle. Je tiens tout d’abord à exprimer toute ma gratitude

mon respect le plus sincère à mon encadrant à l’ISI Monsieur Ghaith MANITA. J’ai eu le privilège

de travailler sous votre direction et d’apprécier vos qualités et vos directives, votre sérieux, votre

patience, votre sens du devoir qui m’a énormément marqué et vos expressions d’encouragement

que vous n’avez cessé de me communiquer. Pour toutes vos qualités professionnelles et humaines,

veuillez trouver ici l’expression de ma respectueuse considération et ma profonde admiration. Pour

les personnels de la société PICOSOFT : Je saisie également cette occasion pour remercier l’entreprise

PICOSOFT qui m’a accueillie. En effet, j’ai eu le plaisir de travailler dans une entreprise de grande

valeur, reconnue à l’échelle mondiale. Par la même occasion, j’adresse mes vifs remerciements à

Monsieur Imed HACHICHA le Directeur Général qui m’a donné l’occasion d’effectuer ce stage. Je

tiens à exprimer mes sentiments de respect et de gratitude à mon encadrant Monsieur Foued BEN

AMEUR le Directeur technique, pour sa collaboration spontanée, sa générosité, sa compréhension,

ses importants conseils et son aide inestimable. Un grand merci également à Monsieur Abdelaziz

FITOURI ingénieur au sein de l’équipe de développement, pour ses conseils, son soutien et pour

l’aide qu’il a pu m’apporter. J’exprime également ma reconnaissance et ma gratitude à Monsieur

Aymen JAYECH ingénieur au sein de l’équipe de développement, tant pour son implication que pour

son suivi régulier lors de la période du stage.

Table des matières

Introduction générale 1

1 Cadre général du projet 3

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.2 Produits proposés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.3 Organigramme de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4.1 Choix de la méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4.2 Présentation de la méthodologie SCRUM . . . . . . . . . . . . . . . . . . . . . . . 7

1.5 Langage de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Etat de l’art 10

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1 Concept de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1 Notion de l’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.2 Notion du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.3 Gestion des documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.4 Notion d’archives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Processus métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

i

Table des matières

2.2.1 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.2 Catégories des Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.3 Vue d’ensemble du Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.4 Moteurs de Workflow existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Etude comparative entre les moteurs d’exécution existants . . . . . . . . . . . . . . . . 15

2.4 Choix du moteur du Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Planification 17

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Identification et structuration des cas d’utilisations . . . . . . . . . . . . . . . . . . . . . 19

3.2.1 Diagramme du cas d’utilisation global du responsable commercial . . . . . . . 19

3.2.2 Diagramme du cas d’utilisation global du responsable technique . . . . . . . . 21

3.2.3 Diagramme du cas d’utilisation global de l’agent technique . . . . . . . . . . . . 21

3.2.4 Diagramme du cas d’utilisation global du responsable financier . . . . . . . . . 21

3.3 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Sprint 0 25

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.1 Outils matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

ii

Table des matières

4.1.2 Architecture matérielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.3 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.1 Outil de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.2 Outil de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2.3 Langages de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Sprint 1 : Responsable commercial 33

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2 Diagrammes des cas d’utilisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2.1 «Authentification» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.2.2 Raffinement des cas d’utilisations du responsable commercial . . . . . . . . . . 38

5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.3.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.3.2 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.4 Modélisation du processus métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.4.1 Procesus du responsable commercial . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6 Sprint 2 : Responsable technique 56

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56



iii

Table des matières

6.2.1 Raffinement des cas d’utilisations du responsable technique . . . . . . . . . . . 56

6.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60



6.4 Modélisation d’un processus métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.4.1 Processus du responsable technique . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7 Sprint 3 : Agent technique 69

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69



7.2.1 Raffinement des cas d’utilisations de l’agent technique . . . . . . . . . . . . . . 69

7.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71


7.3.2 Diagrammes de sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.4 Modelisation du processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.4.1 Processus de l’agent technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

8 Sprint 4 : Responsable financier 77

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77



iv

Table des matières

8.2.1 Raffinement des cas d’utilisations du responsable financier . . . . . . . . . . . . 77

8.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78



8.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

8.5 Phase de clôture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Conclusion générale 86

A Spécification BPMN 2.0 i

A.1 Définition du BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

B Alfresco iv

B.1 Description des principaux notion du alfresco . . . . . . . . . . . . . . . . . . . . . . . . iv

B.1.1 Notion d’espace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv

B.1.2 Notion de contenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv

B.1.3 Suivi de version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv

B.1.4 Recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv

B.1.5 Droits d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

B.1.6 Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

B.2 Espaces disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

B.3 Etude comparative entre Alfresco et Nuxeo . . . . . . . . . . . . . . . . . . . . . . . . . . v

C Activiti vii

C.1 Différents composants d’Activiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

C.2 Activiti API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

v

Table des matières

Bibliographie ix

vi

Table des figures

1.1 L’organigramme de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Cycle de vie de la méthodologie SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 Définition du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Décomposition d’un système GED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Vue d’ensemble du workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Cycle de vie du workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1 Diagramme du cas d’utilisation global du responsable commercial . . . . . . . . . . . 20

3.2 Diagramme du cas d’utilisation global du responsable technique . . . . . . . . . . . . 21

3.3 Diagramme du cas d’utilisation global de l’agent technique . . . . . . . . . . . . . . . . 22

3.4 Diagramme du cas d’utilisation global du responsable financier . . . . . . . . . . . . . 22

4.1 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Le Design Pattern MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3 Concept du ECM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 Diagramme de cas d’utilisation «Authentification» . . . . . . . . . . . . . . . . . . . . . 37

5.2 Raffinement des cas d’utilisations du responsable commercial . . . . . . . . . . . . . . 38

5.3 Diagramme de classes du responsable commercial . . . . . . . . . . . . . . . . . . . . . 42

5.4 Diagramme de séquence «Authentification» . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.5 Diagramme de séquence «Valider une demande d’offre» . . . . . . . . . . . . . . . . . . 45

5.6 Diagramme de séquence «Classer l’offre» . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.7 Diagramme de séquence du cas d’utilisation «Classer l’offre commercial» . . . . . . . 47

5.8 Diagramme de séquence du cas d’utilisation «Traiter le bon de commande» . . . . . . 49

5.9 Processus du responsable commercial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.10 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

vii

Table des figures

5.11 Interface de validation d’une demande d’offre . . . . . . . . . . . . . . . . . . . . . . . . 51

5.12 Interface de la décision du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.13 Interface de l’envoie d’un e-mail au client . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.14 Interface d’ajouter du plan de classement . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.15 Interface de création du plan de classement . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.16 Interface de la préparation de l’offre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.17 Interface de traitement du bon de commande . . . . . . . . . . . . . . . . . . . . . . . . 54

5.18 Interface de classement de la commande . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.1 Diagramme des cas d’utilisations du responsable technique . . . . . . . . . . . . . . . 58

6.2 Diagramme de classes du responsable technique . . . . . . . . . . . . . . . . . . . . . . 61

6.3 Diagramme de séquence «Classer les offres techniques» . . . . . . . . . . . . . . . . . . 62

6.4 Diagramme de séquence «Valider les offres techniques» . . . . . . . . . . . . . . . . . . 64

6.5 Diagramme de séquence «Valider la réalisation» . . . . . . . . . . . . . . . . . . . . . . . 65

6.6 Processus du responsable technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.7 Interface d’affectation des travaux mentionnés dans la demande d’offre . . . . . . . . 67

6.8 Interface de la validation des offres techniques . . . . . . . . . . . . . . . . . . . . . . . 67

6.9 Interface du classement des offres techniques . . . . . . . . . . . . . . . . . . . . . . . . 68

6.10 Interface de la validation des travaux mentionnés dans le bon de commande . . . . . 68

7.1 Diagramme du cas d’utilisation de l’agent technique . . . . . . . . . . . . . . . . . . . . 70

7.2 Diagramme de classes de l’agent technique . . . . . . . . . . . . . . . . . . . . . . . . . 72

7.3 Diagramme de séquence «Préparer réalisation» . . . . . . . . . . . . . . . . . . . . . . . 73

7.4 Diagramme de séquence «Préparer l’offre» . . . . . . . . . . . . . . . . . . . . . . . . . . 74

7.5 Processus de l’agent technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.6 Interface de prépartion les offres techniques . . . . . . . . . . . . . . . . . . . . . . . . . 76

viii

Table des figures

7.7 Interface de la prépartion des réalisations . . . . . . . . . . . . . . . . . . . . . . . . . . 76

8.1 Diagramme des cas d’utilisations du responsable financier . . . . . . . . . . . . . . . . 78

8.2 Diagramme de classes du responsable financier . . . . . . . . . . . . . . . . . . . . . . . 79

8.3 Diagramme de séquence «Préparer facture» . . . . . . . . . . . . . . . . . . . . . . . . . 80

8.4 Diagramme de séquence «Classer facture» . . . . . . . . . . . . . . . . . . . . . . . . . . 81

8.5 Interface de la préparation d’une facture . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

8.6 Interface de classement d’une facture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

8.7 Diagramme de GANTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

C.1 Différents composants d’Activiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

C.2 Activiti API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

ix

Liste des tableaux

2.1 Comparatif entre les differents moteurs d’exécution existants. . . . . . . . . . . . . . . 16

3.1 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1 Backlog du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2 Descriptif des classes du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.1 Backlog du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57


7.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69


8.1 Backlog du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77


A.1 Eléments de base de la spécification BPMN 2.0 . . . . . . . . . . . . . . . . . . . . . . . i

A.2 Description de quelques éléments de la spécification BPMN 2.0 . . . . . . . . . . . . . ii

B.1 Etude Comparatif entre Alfresco et Nuxeo. . . . . . . . . . . . . . . . . . . . . . . . . . . vi

x

Liste des abréviationsUML Unified Modeling Language

IBM International Business Machines

BPMN Business Process Model and Notation

IDE Integrated Development Environment

WfMC Workflow Management Coalition

BPM Buisness Process Management

BPEL Business Process Execution Language

MVC Modèle-Vue-Contrôleur

IHM Interface Homme Machine

ECM Enterprise Content Management

GED Gestion électronique des documents

JONAS Java Open Application Server

xi

Introduction générale

De nos jours, toute entreprise est prête à investir des sommes considérables dans l’implanta-

tion des technologies logicielles afin d’améliorer ses services internes, d’accroitre son agilité et sa

flexibilité, de réduire les coûts et d’augmenter la production. En effet, vu la croissance des activités

au sein des entreprises et les tâches à gérer, toutes ces fonctions s’avèrent de plus en plus complexe

et difficile.

Pour surpasser ces difficultés, une entreprise doit utiliser des outils optimisés et adaptés, en

facilitant les tâches et offrant des fonctionnalités riches et utiles. Parmi ces outils nous trouvons

les systèmes intégrés de gestion de workflow, qui représentent des outils de gestion et de suivie

de l’exécution d’un processus métier à travers la description du circuit de validation ainsi que

l’identification des différents acteurs impliqués, les actions à réaliser, les délais, l’historique et les

documents associés à chaque tâche. Un tel mécanisme permet donc d’améliorer les processus de

gestion et d’automatiser les tâches ce qui augmente énormément la réactivité des entreprises et

leurs agilités.

C’est dans ce contexte que s’intègre notre projet de fin d’études, qui a pour objectif la conception

et le développement d’une application de gestion d’un dossier d’affaire qui est dans notre cas un

processus de gestion de prestation suite à une demande d’offre.

Le présent rapport synthétise tout le travail que nous avons effectué dans cette perspective, il

est constitué de plusieurs chapitres :

• Le premier chapitre présente le «Cadre général du projet» avec une présentation de la société

et de ses secteurs d’activités et nous allons présenter la méthodologie agile Scrum.

• Le deuxième chapitre intitulé «Etat de l’art», étudie le concept du Workflow et du processus

métier. Nous comparerons également quelques moteurs de Workflow connus afin d’opter

pour le meilleur.

• Le troisième chapitre «Planification», sera consacré à l’analyse des besoins et la planification

du travail à effectuer ainsi que le backlog du produit.

• Le quatrième chapitre est réservé au «Sprint 0» qui représente l’environnement matériel et

logiciel du projet. Nous étudierons la solution à utiliser et nous exposons l’architecture du

système qui lui correspond.

1

Introduction générale

• Le reste des chapitres décrit la conception et la réalisation des sprints 1, 2, 3 et 4. Nous

commençons tout d’abord par le « Sprint Backlog » qui décrit les tâches à faire et ensuite

nous présentons les diagrammes pour la conception et finalement nous mettons quelques

interfaces de l’application.

Le rapport s’achève par une conclusion générale rappelant les réalisations essentielles de notre

travail et présentant les perspectives de développement de l’application.

2

1 Cadre général du projet

Introduction

Dans le présent chapitre, nous présentons la société PicoSoft pour laquelle ce travail a été réalisé.

Par la suite, nous exposons le sujet du travail qui nous a été demandé ainsi que l’environnement qui

a servi à son achèvement. Après l’exposition de la problématique qui a engendré ce travail, nous

abordons l’étude de l’existant et nous présentons ensuite la solution proposée. Enfin, nous entamons

ce chapitre par la présentation de la méthodologie adopté durant la conception et le développement

de notre projet.

1.1 Présentation de l’organisme d’accueil

PicoSoft [1] est une société d’ingénierie et de conseil en informatique aux services des organisa-

tions engagées dans une démarche d’échanges dynamiques d’informations en favorisant le travail

de groupe et la mobilité géographique. Les solutions proposées par PicoSoft sont spécialisées dans le

travail collaboratif et les collecticiels, le e-business et les technologies Intranet / Internet / Extranet.

PicoSoft réalise une grande partie de ses recettes sur les produits et services exportés vers l’union

européenne et principalement l’Allemagne.

1.1.1 Services

Les services offerts par PicoSoft sont le consulting, le développement spécifique et la formation

[2]. La mission de PicoSoft est d’assurer alors une prise en charge globale du cycle de vie des projets

de sa clientèle. En effet, elle offre à ses clients une étude approfondie leurs permettant de mettre en

place l’architecture la plus adéquate à leurs entreprises.

Cette étude comprend, entre autres, l’architecture physique, la topologie d’implantation et la

structure logique des serveurs, ainsi que l’organisation et la répartition des rôles et des responsa-

bilités de l’administration du système. D’un autre côté, PicoSoft met à la disposition de ses clients

des solutions répondant à leurs besoins et assiste leurs personnels lors du développement des

applications de Workflow et de travail collaboratif. Finalement, et pour son savoir-faire auprès de ses

clients, PicoSoft offre des formations adaptées dans différents domaines, citons à titre d’exemples le

développement Web et le travail collaboratif.

3

Chapitre 1. Cadre général du projet

1.1.2 Produits proposés

La société PicoSoft est spécialisée dans les technologies International Business Machines

(IBM) Lotus au titre d’Advanced IBM Business Partner. Son expertise dans ces technologies est

largement reconnue [3]. Elle développe avec Lotus Notes Domino des solutions génériques telles

que :

• Mail Manager : Solution web pour la gestion et le suivi du courrier et des formulaires en

Intranet / Extranet. S’appuyant sur une base de données documentaire, Mail Manager permet

l’enregistrement, l’affectation, la diffusion et le suivi du courrier des correspondants externes

de l’organisation, et le classement des documents échangés de façon logique (par exemple

éditeur, par date, par référence, par dossier ,etc.). Mail Manager s’adresse aux administrations

publiques, et en général, à toute organisation pour laquelle la gestion du courrier est une

fonction stratégique

• Quality Manager : Solution complète pour la documentaire de la qualité et la planification

des actions qualité. Il constitue une base de connaissances indispensable à tout processus

d’amélioration continue de la qualité grâce à ses fonctions avancées en matière de gestion

documentaire et de planification des actions qualité. Parmi ses fonctions, nous pouvons

citer la planification, le traitement et le suivi des audits et des non-conformités, la gestion

et le suivi des actions correctives et préventives, la gestion des versions des documents et le

référencement paramétrable.

• Leave Manager : Solution complète pour la gestion des congés, des autorisations de sortie et

des ordres de mission. Ainsi que plusieurs autres solutions tels que : gestion et suivi du parc

informatique, du parc auto, gestion de pointage, des appels téléphoniques . . .En complément

de cette gamme de produits , PicoSoft met à la disposition du client une variété de services qui

lui accompagnent dans sa quête d’évolution :

– Consulting (conception, mise en place et audit des systèmes d’information).

– Développement spécifique(Domino , .Net, PHP, J2EE).

– Formation(sur les produits PicoSoft, Lotus Notes / Domino, . . .).

1.1.3 Organigramme de la société

La Figure 1.1 montre l’organigramme de la société.

4


FIGURE 1.1 – L’organigramme de la société

1.2 Présentation du projet

La gestion du contenu de l’entreprise consiste à transposer l’information avec des supports

traditionnels (comme le papier, ou les microfiches), ce qui peut leur causer une perte de temps et

une difficulté d’organisation. De nos jours, les entreprises devront faire face à un fond de plus en plus

volumineux de documents à archiver et à stocker. En effet, elles émettent, reçoivent et accumulent

une masse importante de documents donc il est nécessaire que les entreprises suivent l’état de

l’avancement de leur dossiers en temps réel pour savoir l’état courant de chaque dossier et pour

garantir une forte présence sur le marché. Ce besoin est apparu dès qu’il y a eu prise de conscience de

la situation des entreprises à cause du mauvais traitement des dossiers de prestation. Cela engendre

des graves conséquences, entre autres, la non-conformité aux termes et aux conditions prédéfinis et

le non-respect des délais. C’est dans ce cadre que la société PicoSoft a constaté qu’il est nécessaire

de développer une application de gestion des dossiers de prestation suite à une demande d’offre

pour répondre à son besoin et de commercialiser ce produit à d’autres entreprises.

1.3 Etude de l’existant

L’étude de l’existant est une étape préliminaire qui nous a permis de dégager les problématiques

et de ressortir les vrais besoins des entreprises en tenant compte que la gestion des informations est

assistée par des ordinateurs d’une manière non centralisée en utilisant des outils classiques comme

Microsoft Word et Excel. Ainsi que, la recherche et la mise à jour des données sont faites manuelle-

ment. D’autre part, le volet de la sécurité n’est pas pris en compte et les données sont accessibles

5


par tous les utilisateurs. Durant l’avancement du dossier de prestation les acteurs ont besoin de se

reporter à un programme commun pour centraliser les demandes d’offres. Grâce à des réunions

faites au sein de l’entreprise, nous avons conclu que la majorité des organisations ont rencontré

des difficultés surtout lors de l’administration des dossiers d’affaire. Cela a pour conséquence la

disparition des documents relatifs à une demande d’offre dans les différents départements d’une

société. De plus, certains des acteurs de la société n’ont pas accès ou ne sont pas au courant, de

certains documents qui les concernent directement ou indirectement. Cela est dû à l’absence d’une

traçabilité qui s’avère importante pour la réussite d’une organisation. C’est pour cette raison que

nous avons intégré l’équipe de développement au sein de l’entreprise PicoSoft pour accomplir le

travail qui nous a été demandé. Ce travail consiste à réaliser une application permettant d’avoir une

visibilité sur l’état de l’avancement du dossier de prestation suite à une demande d’offre.

1.3.1 Solution proposée

Suite aux inconvénients cités dans le paragraphe précédent, nous proposons la mise en place

d’une application Web de gestion des dossiers d’affaires sous Alfresco share (voir Annexe B) qui

automatise la suivie de l’état d’avancement des dossiers de prestation, dans cette solution nous

augmentons la possibilité de gérer et contrôler le processus de prestation dés le début à la fin et elle

favorise par la même occasion la collaboration au sein de l’entreprise dans un environnement qui

offre un gain de temps et permet d’éviter le conflit entres les collègues.

1.4 Méthodologie adoptée

Avec les progrès en technologies de l’information et les investissements dans les infrastructures,

beaucoup de méthodes de gestion de projets ont vu le jour. Certes, ces méthodes jouent un rôle

primordial dans la réussite ou l’échec d’un projet, d’où le choix, représente une décision importante

pour les entreprises. Dans cette partie, nous allons expliquer notre choix de méthode.

1.4.1 Choix de la méthodologie

Le choix entre une méthode et une autre dépend de la nature du projet et de sa taille. Pour

des projets de petite taille et dont le domaine est maitrisé, par exemple, un cycle de vie en cascade

s’avère largement suffisant. Lorsqu’il s’agit d’un projet où les données ne sont pas réunies dès le

départ, ou les besoins sont incomplets, il faut s’orienter vers une méthode itérative ou orientées

prototypes. Parmi les méthodes itératives, nous pouvons distinguer les méthodes AGILE largement

6


utilisées de nos jours à travers le monde. Une méthode AGILE est menée dans un esprit collaboratif

et s’adapte aux approches incrémentales, elle engendre des produits de haute qualité tout en tenant

compte de l’évolution des besoins du client.

Une méthode AGILE assure une meilleure communication avec le client et une meilleure

visibilité du produit livrable. Elle permet aussi de gérer la qualité en continu et de détecter des

problèmes le plus tôt au fur et à mesure, permettant ainsi d’entreprendre des actions correctives

sans trop de pénalités dans les couts et les délais. Il y a plusieurs méthodes AGILE et il ne s’agit pas

de choisir la meilleure méthode parmi celles existantes. Il s’agit plutôt de sélectionner la méthode la

plus adaptée à notre projet.

Notre projet est évolutif et ses besoins n’ont pas pu être totalement identifiés dés le début donc

nous nous sommes orientées vers une méthode de type AGILE et plus particulièrement SCRUM.

Le choix de Scrum comme une méthodologie de pilotage pour notre projet s’est basé sur les

atouts de ce dernier. Il se résumé comme suit :

• La souplesse et la réactivité.

• La grande capacité d’adaptation au changement grâce à des itérations courtes.

• La chose la plus importante, c’est que Scrum rassemble les deux cotés théorique et pratique et

se rapproche beaucoup de la réalité.

1.4.2 Présentation de la méthodologie SCRUM

Le principe de la méthodologie SCRUM [4] est de développer un logiciel de manière incré-

mentale. Avec des livraisons très fréquentes, toutes les 4 semaines en moyenne, le client reçoit

un logiciel fonctionnel à chaque itération. Plus nous avançons dans le projet, plus le logiciel est

complet et possède toujours de plus en plus de fonctionnalités. Pour cela, la méthode s’appuie sur

des développements itératifs à un rythme constant.

Pour mettre en place la méthodologie SCRUM, il faut tout d’abord définir les différentes fonc-

tionnalités de notre application qui forment le backlog du produit. Ensuite, nous procédons à la

planification du sprint pour définir le plan détaillée d’une itération. Durant un sprint, il y a toujours

des réunions quotidiennes entre les différents collaborateurs du projet afin de présenter l’état d’avan-

cement des différentes tâches en cours, les difficultés rencontrées ainsi que les tâches restantes à

réaliser. Une fois le produit partiel est prêt, nous vérifions la conformité de ce qui a été fait durant le

7


FIGURE 1.2 – Cycle de vie de la méthodologie SCRUM

sprint et nous pouvons alors l’améliorer en procédant à l’étape de rétrospective. La Figure 1.2 illustre

le cycle de vie de la méthode SCRUM [5].

Principes essentiels de la méthode

Nous pouvons remarquer quatre valeurs principales dans les méthodes agiles :

• L’équipe : Nous nous concentrons sur les personnes et leurs interactions plutôt que sur les

processus et les outils.

• L’application : Le plus important c’est d’avoir un logiciel fonctionnel plutôt que d’avoir une

documentation complète.

• La collaboration : Cette méthode se base sur la collaboration avec le client plutôt que sur la

négociation de contrat.

• L’acceptation du changement : Nous ne suivons pas un plan mais nous réagissons à chaque

nouveau changement.

Organisation

La méthodologie SCRUM fait intervenir 4 rôles principaux qui sont :

• Product owner : Dans la majorité des projets, le responsable produit (product owner) est le

responsable de l’équipe Scrum. C’est lui qui va devenir et prioriser la liste des fonctionnalités

du produit et choisir la date et le contenu de chaque sprint sur la base des valeurs (charges)

qui lui sont communiquées par l’équipe.

• Scrum Master : Véritable facilitateur sur le projet, il veille à ce que chacun puisse travailler au

8


maximum de ses capacités en éliminant les obstacles et en protégeant l’équipe des pertur-

bations extérieures. Il porte également une attention particulière au respect des différentes

phases de SCRUM.

• Equipe : L’équipe s’organise elle-même et elle reste inchangée pendant toute la durée d’un

sprint. Elle doit tout faire pour délivrer le produit.

• Intervenants : Ils donnent des conseils à l’équipe.

Dans notre projet, nous pouvons distinguer les rôles suivants :

• Product owner : Mr. Foued Ben Ameur.

• Scrum Master : Mr. Foued Ben Ameur.

• Intervenants : Mr. Abdelaziz Fitouri, Mr. Aymen Jayech, Mr. Nader Kessentini.

• Développeur : Rania Soltani.

1.5 Langage de modélisation

Après le choix de la méthodologie, nous avons besoin d’un langage de modélisation unifiée pour

la modélisation de notre projet. Pour concevoir notre système, nous avons choisi Unified Modeling

Language (UML) comme un langage de modélisation.

Définition. L’UML [6] est un langage de modélisation objet. Il permet donc de modéliser vos objets et

ainsi représenter votre application sous forme de diagramme.

Notre choix s’est basé sur les points forts de ce langage notamment sa standardisation et

les divers diagrammes qu’il propose. Aussi UML présente le meilleur outil pour schématiser des

systèmes complexes sous un format graphique et textuel simplifié et normalisé.

Conclusion

Tout au long de ce chapitre, nous avons évoqué le cadre général du projet. Nous avons com-

mencé tout d’abord par une présentation de l’organisme d’accueil qui a été suivie par une étude de

l’existant. Ceci nous a permis de comprendre les besoins et d’envisager la solution la plus adéquate

aux attentes du client. Le prochain chapitre est consacré à la présentation d’une étude comparative

des différentes solutions existantes sur le marché. Cette étude nous a été très bénéfique car elle nous

a permis entre autres non seulement de comprendre le problème mais aussi de dégager toutes les

fonctionnalités essentielles sans oublier certaines et sans en développer d’autres inutiles.

9

2 Etat de l’art

Introduction

Afin de mieux comprendre notre projet, nous avons dû étudier certaines notions primordiales

pour aborder le thème des Workflows. Dans le présent projet, nous sommes appelé à bien déterminer

les concepts sur lesquels on va travailler à travers des définitions précises et concises. Une attention

particulière devrait être accordée aux concepts relatifs à l’archivistique en prenant en compte

les notions de l’information, du document, d’archives, et du document électronique. Ainsi nous

consacrons donc ce chapitre à l’étude du principe des processus métiers, ainsi que les moteurs

d’exécution qui interviennent dans sa mise en place.

2.1 Concept de base

Dans cette partie nous allons étudier la notion de l’information, du document et de l’archive.

2.1.1 Notion de l’information

L’information est un élément de base, on doit le définir et étudier ses sources, ses types et

les supports de cette information. L’information est une donnée, transformée et structurée sous

une forme conventionnelle et intelligible pour être insérer dans une dynamique de diffusion et/ou

d’échange (pour être communiquer).

2.1.2 Notion du document

Un document est un ensemble formé par un support et une information, généralement enregis-

tré de façon permanente et tel qu’il puisse être lu par l’homme et la machine. Les documents sont

représentés sous plusieurs formes :

• Electronique : lisible sur un écran. Soit créé initialement sous une forme numérique ou résulte

d’un processus de numérisation à partir d’un document papier.

• Multimédia : regroupe plusieurs type de média tels que : son, image, texte, vidéo.

La Figure 2.1 présente la composition d’un document.

10

Chapitre 2. Etat de l’art

FIGURE 2.1 – Définition du document

2.1.3 Gestion des documents

Les documents ont souvent vocation à être diffuser, sous forme électronique ou après impres-

sion. Il faut dans certains cas les transformer et les faire valider avant cette diffusion. La diffusion

des documents recouvre plusieurs technologies, pouvant être combinés selon le besoin. Elles com-

prennent l’affichage écran, l’impression et les différentes formes de communication sur réseau,

comme la messagerie ou le Workflow. La Figure 2.2 illustre la décomposition d’un système de Gestion

électronique des documents (GED) [7].

2.1.4 Notion d’archives

Les archives constituent la mémoire de l’entreprise, elles représentent les activités réalisées

dans le cadre d’une affaire ou d’un ensemble d’affaires. Les définitions données par la littérature

insistent sur la nécessité de la conservation des archives pour la justification des droits, la recherche

scientifique et historique et pour la sauvegarde du patrimoine.

2.2 Processus métier

Un processus métier est un enchainement d’activités qui se produisent au sein d’une entreprise

dans un cadre coopératif, impliquant un nombre limité de personnes, un temps limité et des tâches

spécifiques articulées autour d’une procédure définie pour le but de produire un service ou un

produit spécifique.

11


FIGURE 2.2 – Décomposition d’un système GED

2.2.1 Workflow

Le Workflow Management Coalition (WfMC)1 [8] définit le Workflow comme étant une automa-

tisation totale ou partielle d’un processus métier, durant lequel des informations, des documents, ou

même des tâches sont transférés d’un acteur à un autre pour des besoins et objectifs bien spécifiques.

D’une façon concrète, un Workflow décrit le circuit de validation du processus, les tâches à accomplir

entre les différents acteurs, les délais à respecter et les modes de validation. Le terme Workflow peut

être traduit en français par la gestion électronique des processus métier.

2.2.2 Catégories des Workflows

On peut distinguer quatre catégories principales des Workflow à savoir :

• Workflow de production : Correspond à la gestion des processus de base de l’entreprise. Ces

procédures supportent peu de changements dans le temps et les transactions sont répétitives.

1WfMC : organisation à but lucratif qui développe des standards dans le domaine de Workflow en collaboration avec lesdéveloppeurs, les universités et les consultants

12


• Workflow Administratif : Correspond à tout ce qui est routage de formulaires. Elle est basée

principalement sur l’infrastructure de messagerie.

• Workflow Ad-Hoc : S’intéresse à la gestion des procédures non déterminées mouvantes.

• Workflow Coopératif : Gère les procédures évoluantes assez fréquemment et liées à un groupe

de travail restreint de l’entreprise. Cette catégorie concerne l’élaboration des documents plus

complexes, faisant intervenir différents acteurs. Le débit du système est moins important que

la flexibilité.

2.2.3 Vue d’ensemble du Workflow

Comme l’expose la Figure 2.3, le Workflow englobe l’ensemble d’outils et de fonctionnalités

nécessaires pour l’analyse, la modélisation et l’automatisation des flux de travail dans l’entreprise,

ainsi que l’interfaçage avec les différents participants à ces processus.

FIGURE 2.3 – Vue d’ensemble du workflow.

13


FIGURE 2.4 – Cycle de vie du workflow

Mise en place d’un Workflow

La mise en place d’un Workflow doit passer obligatoirement par quatre phases primordiales, ce

qui est indiqué dans la Figure 2.4

• Phase d’analyse : Gérer les données techniques nécessaires à la production.

• Phase de modélisation : Gérer les mouvements de stock.

• Phase d’implémentation : Déclencher et suivre les ordres d’approvisionnements et d’achats.

• Phase d’exécution : Déclencher et suivre les ordres de production.

Gestion des processus metiers

Le Buisness Process Management (BPM)2 [9] est une discipline qui s’intéresse, comme son

nom l’indique, à la gestion des processus métier. Ceci implique une combinaison de la modélisation,

l’automatisation, l’exécution, le contrôle, la mesure, l’optimisation des flux d’activité de l’entreprise

et à l’appui des objectifs de l’entreprise. Le BPM est le fruit d’une collaboration entre les profession-

nels du métier et les informaticiens ; il donne la main aux professionnels de modéliser les processus

métiers et aux informaticiens d’automatiser ces processus3.

Moteurs de Workflow

Le WfMC définit un moteur de Workflow comme étant un dispositif logiciel qui fournit un

environnement d’exécution pour les instances des processus. Il se charge principalement de :

• L’interprétation de la définition des processus métier.

• La gestion des instances des processus, y compris leur création, exécution (activation et

suspension) et terminaison, etc.

• La navigation entre les activités et la prise de décision c’est-à-dire la branche à suivre en

fonction du contexte et des données pertinentes.

2BPM : gestion des processus métiers.3Un processus est un ensemble d’activités liées qui transforme des éléments d’entrée en éléments de sortie. Ainsi

quasiment toute action, projet, programme . . .peut être vu comme un processus

14


• L’authentification de l’autorité des utilisateurs : Le moteur de Workflow doit vérifier si l’utilisa-

teur actuel est autorisé à exécuter la tâche.

• L’administration et la supervision du système à travers des outils de monitoring4.

2.2.4 Moteurs de Workflow existants

Lors de notre étude concernant les moteurs de Workflows existants, nous avons remarqué une

multitude de produits qui existent sur le marché, qui diffèrent par leurs caractéristiques et leurs

domaines d’utilisation. Parmi les moteurs les plus utilisés [9], nous pouvons citer

• Activiti : Activiti (Voir annexe C) est un moteur de Workflow open source. Il s’agit d’une

plateforme qui s’adresse aux professionnels, aux développeurs et aux administrateurs système.

Il est extrêmement léger et basé sur des concepts simples. Il a été écrit en java.

• BonitaSoft : C’est une solution BPM, basée sur la spécification de la WfMC, développée par

Bullet à présent proposé par la société BonitaSoft. Ce produit est distribué sous la forme d’une

application Java EE déployée sur son propre serveur Java Open Application Server(JONAS) .

Il est très adapté pour des processus génériques, il suffit juste de dessiner les processus en

utilisant une palette Business Process Model and Notation(BPMN). Il peut s’intégrer avec

d’autres systèmes d’informations (MySQL, LDAP, Facebook, etc.).

• Intalio BPMS : Intalio est une suite BPM utilisant la notion de BPMN 2.0 pour générer une

orchestration Business Process Execution Language (BPEL)5. Il s’adapte bien dans l’environ-

nement des services Web. Seulement certains de ces composants sont mis en open source.

• Jboss jBPM : C’est un moteur de Workflow écrit en Java et proposé par la communauté JBoss.

Il s’agit d’une solution BPM complète accompagnée d’un éditeur graphique des processus et

Monitoring : Système ou appareil de mesure / supervision / surveillance.

2.3 Etude comparative entre les moteurs d’exécution existants

Le tableau 2.1 présente la comparaison faite entre les différents moteurs de workflow existants

pour bien choisir le moteur le mieux adapté à notre besoin.

Nous avons distingué deux approches parmi les moteurs de Workflow :

• Celles orientés développeur, avec un accès privilégié aux fonctionnalités du moteur BPM.

4Monitoring : Système ou appareil de mesure / supervision / surveillance.5BPEL : langage d’exécution des processus métier

15


TABLEAU 2.1 – Comparatif entre les differents moteurs d’exécution existants.

Produit Environemment Langage Licence OrientationActiviti Java BPMN2 Apache v2 DéveloppementBonita Java EE / Jonas XPDL LGPDL v2 Utilisation

Intalio Web Services WS-BPELCommunauté/ commercial

Utilisation

jBPM Java jPDL / BPMN2 LGPL Développement

• Celles orientés utilisateur, avec un accès limité aux fonctionnalités du moteur BPM et l’utilisa-

tion d’éditeurs propriétaires pour la définition et la gestion des processus.

2.4 Choix du moteur du Workflow

Concernant notre projet, nous allons travailler sous le plateforme alfresco (voir annexe B)

donc nous allons choisir comme un moteur du workflow activiti. Activiti a été publié par l’éditeur

d’ECM Alfresco, qui souhaitait développer une alternative à JBPM pour ses propres besoins. En

choisissant d’en faire un composant indépendant, Alfresco parie sur le dynamisme de l’open source

(le produit a été reversé à la communauté Spring) et souhaite en faire l’outil de référence du BPM

open source. Activiti est ainsi techniquement à l’état de l’Art et bénéficie d’un très bon dynamisme

grâce à la grande popularité de son porteur. Activiti est aujourd’hui un moteur BPM léger et robuste.

Sa jeunesse le destine plutôt à une fonction de brique BPM intégrée à des projets plus complexes,

comme il l’est à Alfresco par exemple. Activiti présente néanmoins des interfaces agréables pour les

utilisateurs finaux (dessin de processus) qui permettront aux équipes fonctionnelles et techniques

de travailler conjointement sur la modélisation des processus. Sa mise en œuvre à proprement parler

nécessitera toutefois impérativement de réelles compétences techniques. Activiti est publié sous

licence Apache et est développé en Java.

Conclusion

Dans ce chapitre, nous avons étudié les principaux concepts, tel que le Workflow et la gestion

des processus métiers. Nous avons également introduit le principe des moteurs d’exécution, cité

les moteurs les plus utilisés et choisi finalement le meilleur. Le prochain chapitre est consacré

à la définition du backlog du produit ainsi qu’à la présentation des besoins fonctionnels et non

fonctionnels. Et nous terminons par une analyse de ces besoins en se basant sur les diagrammes de

cas d’utilisation d’UML.

16

3 Planification

Introduction

Ce chapitre est consacré à l’analyse et la spécification des besoins. Nous commençons par

l’identification des acteurs, des besoins fonctionnels et non fonctionnels. Ainsi, nous présentons les

diagrammes de cas d’utilisation relatifs à chaque acteur et nous finissons par produire le backlog du

produit.

3.1 Capture des besoins

Dans cette partie nous allons définir les différents acteurs qui touchent notre système et les

besoins fonctionnels et non fonctionnels.

3.1.1 Identification des acteurs

Les acteurs et les cas d’utilisations sont les concepts UML fondamentaux pour la spécification

des exigences. Un acteur représente le rôle d’une entité externe interagissant avec le système. Il

est représenté par un bonhomme en fil de fer (en anglais stick man). Un acteur peut aussi être un

système externe avec lequel le cas d’utilisation va interagir.

Définition. Un cas d’utilisation [6] : correspond à un certain nombre d’actions que le système devra

exécuter en réponse à un besoin d’un acteur. Un cas d’utilisation doit produire un résultat observable

pour un ou plusieurs acteurs ou parties prenantes du système.

Définition. Une interaction [6] : permet de décrire les échanges entre un acteur et un cas d’utilisation.

Un cas d’utilisation se représente par un ovale dans lequel figure son intitulé. L’interaction entre un

acteur et un cas d’utilisation se représente comme une association.

Les acteurs intervenants qui interagissent dans notre application sont :

Responsable commercial :

C’est la personne qui a une action directe sur une demande d’offre et il a le rôle d’accepter cette

demande ou de l’ignorer.

• Il valide ou refuse une demande d’offre envoyée par le client.

• Il prépare l’offre en cas où elle est validée.

• Il traite le bon de commande.

17

Chapitre 3. Planification

Responsable technique :

C’est la personne qui affecte les travaux aux agents techniques selon leurs fonctionnalités

• Le responsable technique affecte les travaux aux techniciens du sous département technique.

• Il valide les offres techniques.

• Il valide la réalisation.

Agent technique :

C’est la personne qui réalise la demande d’offre, en préparant les offres techniques.

• Il signale la fin du traitement de son travail.

Responsable financier :

• Il prépare la facture après que le travail est terminé par les agents techniques et valider par le

responsable technique.

3.1.2 Besoins fonctionnels

Notre projet consiste à développer une solution générique de gestion de prestation, le système

doit permettre aux utilisateurs de gérer d’une manière planifiée et sécurisée les étapes d’un dossier

de prestation suite à une demande d’offre. Les besoins fonctionnels et les attentes vis-à-vis de notre

application dépendent d’un acteur à autre. Pour cela, nous avons décrit pour chaque acteur les

besoins fonctionnels qui lui sont associés :

• Valider une demande d’offre.

• Affecter le demande aux Responsables techniques

• Traiter le bon de commande.

• Affecter les revues du contrat aux équipes techniques

• Préparer les offres techniques.

• Affecter les travaux mentionnée dans le bon de commande.

• Préparer la facture

• Préparer la commande.

• Classer la commande dans le plan de classement.

• Consulter le dossier de prestation.

• Classer la facture.

18


• Classer l’offre technique.

• Classer les offres commerciales.

• Consulter les données résultantes de l’exécution des processus à travers une fiche détaillée

comportant toutes les informations métiers à savoir les informations du bon de commande(Code

du bon de commande, date d’échéance, type de payement, attachement, état), de la facture

(Code commande, Code facture, Date facture, Net à payer . . .).

• Archiver les documents utilisés : interfacer l’application avec un système de Gestion Electro-

nique de Documents.

3.1.3 Besoins non fonctionnels

Nous décrirons dans cette partie, les besoins fonctionnels, ou autrement dit, les exigences et les

contraintes décrivant le système de point de vue technique.

• Ergonomie de l’interface : L’interface de l’application doit être ergonomique et conviviale.

Aussi, elle doit être simple et facilement exploitable ce qui facilite le dialogue Homme Machine

et permet aux utilisateurs entre notre application de comprendre rapidement son fonctionne-

ment.

• Sécurité et intégrité des données : L’accès à l’application n’est permis qu’après une phase

d’authentification sécurisée. Les informations d’authentification doivent être confidentielles.

L’application doit garantir l’intégrité, la cohérence et la persistance des données.

• Généricité : Notre application devra être la plus générique possible et ne devra pas dépendre

des processus que nous allons les mettre en place.

• Rapidité : L’application doit garantir un accès rapide aux données et d’une manière transpa-

rente

3.2 Identification et structuration des cas d’utilisations

Dans cette partie, nous présentons les diagrammes des cas d’utilisations globaux. Nous modéli-

sons notre application par acteur. Dans les parties suivantes, nous allons définir les différents cas

d’utilisation relatifs à chaque acteur.

3.2.1 Diagramme du cas d’utilisation global du responsable commercial

La Figure 3.1 présente le diagramme de cas d’utilisation global du responsable commercial.

19


FIGURE 3.1 – Diagramme du cas d’utilisation global du responsable commercial

20


3.2.2 Diagramme du cas d’utilisation global du responsable technique

La Figure 3.2 illustre le diagramme de cas d’utilisation global du responsable technique.

FIGURE 3.2 – Diagramme du cas d’utilisation global du responsable technique

3.2.3 Diagramme du cas d’utilisation global de l’agent technique

La Figure 3.3 montre le diagramme de cas d’utilisation global de l’agent technique.

3.2.4 Diagramme du cas d’utilisation global du responsable financier

La Figure 3.4 illustre le diagramme de cas d’utilisation global du responsable financier.

21


FIGURE 3.3 – Diagramme du cas d’utilisation global de l’agent technique

FIGURE 3.4 – Diagramme du cas d’utilisation global du responsable financier

3.3 Backlog du produit

Le Backlog du produit est une liste ordonnée de tout ce qui pourrait être requis dans le produit.

Les items du Backlog du produit incluent une description, un ordre, une estimation de l’effort et de

la valeur. Un seul Product Backlog est utilisé pour décrire le travail à faire sur ce produit. On peut

alors ajouter une propriété aux items du Product Backlog pour les regrouper. Le Tableau 3.1 présente

le backlog produit de notre application. Dans ce tableau chaque User Story (histoire utilisateur) est

caractérisée par une priorité, un type et un responsable.

22


TABLEAU 3.1 – Backlog du produit

Type Reponsable User Story Priorité

StoryTechnique

Administrateur

Mise en place de la plateforme ElevéeModélisation du workflow ElevéeIntégration du workflow sous alfresco ElevéeMise en place du client PicoSoft avec alfresco ElevéeCréation des groupes correspondants à chaque profil Elevée

StoryUtilisateur

Responsablecommercial

En tant que responsable commercial je souhaitevalider une demande d’offre

Elevée

En tant que responsable commercial je souhaiteaffecter la demande aux responsables techniques

Moyenne

En tant que responsable commercial je souhaitevalider les offres commercaux

Moyenne

En tant que responsable commercial je souhaitepréparer l’offre

Moyenne

En tant que responsable commercial je souhaitetraiter le bon de commande

Moyenne

En tant que responsable commercial je souhaiteconsulter le dossier d’affaire«Dossier de prestation»

Moyenne

En tant que responsable commercial je souhaiteuploader la commande

Moyenne

Responsabletechnique

En tant que responsable technique je veuxaffecter les revues du contrat auxéquipes techniques pour préaparer les offrestechniques en calculant les estimations

Elevée

En tant que responsable technique je veuxvalider les offres techniques

Elevée

En tant que responsable technique je veux affecter lestravaux mentionnées dans le bon de commande

Moyenne

En tant que responsable technique je veuxvalider les revues techniques(offres techniques)

Moyenne

En tant que responsable technique je veuxvalider la réalisation

Elevée

Agenttechnique

En tant que agent technique je veux préparerune offre technique

Moyenne

En tant que agent technique je veux préparerla réalisation

Moyenne

Responsablefinancier

En tant que responsable financier je veux préparerune facture.

Moyenne

En tant que responsable financier je veux classerla facture.

Moyenne

23


Conclusion

Nous avons présenté le backlog du produit en spécifiant les différents fonctionnalités qui le

composent. Nous avons aussi détaillé les besoins fonctionnels et non fonctionnels et nous les avons

illustrés par des diagrammes de cas d’utilisation. Le prochain chapitre est consacré pour lister les

différentes technologies utilisées.

24

4 Sprint 0

Introduction

La mise en place de notre projet nécessite plusieurs connaissances en termes de technologies

et du langages de développement, ce chapitre est consacré à la présentation de l’environnement

matériel et logiciel utilisés pour le développement de la solution proposée, nous expliquerons

éventuellement nos choix techniques relatif aux langages de programmation et des outils utilisés.

4.1 Environnement de développement

L’environnement de développement est un terme qui désigne l’ensemble des outils et de

langages utilisés pour l’implémentation d’une solution informatique.

4.1.1 Outils matériel

Tout au long de notre projet nous avons utilisé un ordinateur avec les caractéristiques suivants :

• Marque : Hewlett-Packard (HP ®)

• Processeur : AMD A6-4400 with Radeon(tm)HD Graphics 2.70 GHz

• Mémoire : 6,00 Go

• Système d’exploitation : Windows 7 64 bits

4.1.2 Architecture matérielle

Notre application se présente sous la forme d’une architecture 3-tiers. Une architecture trois

tiers est un modèle logique d’architecture applicative qui vise à modéliser une application comme

un empilement de trois couches logicielles dont le rôle est clairement définit.

• Couche présentation (premier niveau) : Elle correspond à la partie de l’application visible et

interactive avec les utilisateurs. On parle d’interface homme machine.

• Couche métier ou business (second niveau) : Elle correspond à la partie fonctionnelle de

l’application, celle qui implémente la logique, et qui décrit les opérations que l’application

opère sur les données en fonction de requêtes des utilisateurs effectuées au travers de la

couche présentation.

• Couche accès aux données (troisième niveau) : Elle consiste à gérer l’accès aux données du

système. Ces données peuvent être propres au système, ou gérées par un autre système. La

couche métier n’a pas à s’adapter à ces deux cas, ils sont transparents pour elle, et elle accède

aux données de manière uniforme.

25

Chapitre 4. Sprint 0

Diagramme de déploiement

Le diagramme de déploiement permet de représenter l’architecture physique supportant l’ex-

ploitation du système. Cette architecture comprend des nœuds. Les noeuds peuvent être inter-

connectés pour former un réseau d’éléments physiques correspondant aux supports physiques

(serveurs, routeurs. . . ) ainsi que la répartition des artefacts logiciels (bibliothèques, exécutables . . .)

sur ces nœuds. C’est un véritable réseau constitué de noeuds et de connexions entre ces nœuds qui

modélise cette architecture. La Figure 4.1 montre le diagramme de déploiement de notre application.

FIGURE 4.1 – Diagramme de déploiement

4.1.3 Architecture de l’application

L’architecture de notre application est une architecture orienté vers le Modèle-Vue-Contrôleur

(MVC) [10]. MVC est un modèle de conception qui sépare l’interface utilisateur d’une application à

partir de sa logique métier. Il le fait en superposant l’architecture de l’application en trois parties :

Modèle, Vue et Contrôleur. La Figure 4.2 montre l’architecture MVC telle qu’elle est appliquée à des

applications Web.

26


FIGURE 4.2 – Le Design Pattern MVC

La vue

C’est une Interface Homme Machine (IHM) fournit la présentation du modèle. Il représente

l’apparence de l’application. Elle est responsable à présentation et à la collecte de données aux

utilisateurs. La vue peut obtenir l’état du modèle, mais ne peut pas le modifier. Les vue dans notre

application ce sont les pages jsp.

• Les pages jsp : Les pages JSP sont une des technologies de la plate-forme Java EE les plus

puissantes, simples à utiliser et à mettre en place. Elle permettent aux utilisateurs de créer des

vue dynamiques

Le contrôleur

Le contrôleur réagit à l’entrée utilisateur et informe le modèle pour changer son état en consé-

quence. Plus précisément, il traite les demandes entrantes des utilisateurs en leur envoyant des

fonctions logiques d’affaires appropriés (dans le modèle) et en sélectionnant la réponse à l’utilisateur

(la Vue) sur la base du résultat. Les contrôleurs dans notre application sont les servlets.

• Les servlets : Les servlets correspondent à des programmes Java qui utilisent des modules

supplémentaires (ainsi que les classes et les méthodes associées) figurant dans l’API des

Servlets Java.

27


Le modèle

Représente l’état de l’application et définit les actions d’entreprises qui modifient (données

persistantes et la logique métier). Il peut être posé des questions sur son état (habituellement par la

vue) et être invité à changer (généralement par le contrôleur). Il ne sait rien de la vue ou de contrôleur.

Le model dans notre application est alfresco. Les données sont récupérés à travers les web scripts

fournit par Alfresco.

4.2 Environnement logiciel

Dans cette partie nous allons définir les différents outils utilisés dans la phase du développe-

ment.

4.2.1 Outil de développement

Alfresco

Avant de commencer la présentation de la plateforme Alfresco, nous abordons le concept ECM.

• Le concept ECM : L’ Enterprise Content Management(ECM) désigne les solutions permettant

de gérer d’une manière transversale l’ensemble des besoins d’une organisation en matière de

gestion de documents et de processus. Il s’agit donc de prendre en compte les informations

électroniques pour les gérer (stockage, Edition, diffusion) en répondant aux exigences des

utilisateurs (ergonomie, fonctionnalité) et aux processus de l’organisation (sécurité, fiabilité,

processus). La Figure 4.3 présente le concept de l’ECM [11]. Nous définissons maintenant les

éléments clés de l’ECM :

– La collaboration : Travail réalisé en commun par plusieurs personnes aboutissant à une

œuvre commune. Différents outils sont à leur disposition (groupe de travail, wiki, blog,

forum, . . .).

– La gestion de processus métiers BPM : Représente un ensemble d’outils et de moyens

pour représenter la capacité à décrire, modéliser, automatiser, structurer, suivre, analyser

et informatiser les processus d’une entreprise.

– La Gestion électronique des documents(GED) : Désigne un procédé informatisé visant

à organiser et gérer des informations et des documents électroniques au sein d’une

organisation. Son objectif est de centraliser l’ensemble des documents sous format

28


FIGURE 4.3 – Concept du ECM

électronique, et d’en gérer le cycle de vie de la création jusqu’à la destruction. Les étapes

du cycle de vie d’un document sont les suivantes : l’acquisition, le classement, le stockage

et l’archivage.

– Le portail : La porte d’entrée vers les données du système d’information d’une entreprise

pour l’ensemble du personnel et éventuellement les partenaires. Le portail est à la croisée

de trois tendances : les applications métier, la base de connaissance et la collaboration.

• Présentation alfresco : Alfresco (voir Annexe C) est l’alternative libre pour la gestion de

contenu d’entreprise ECM. Il offre de nombreuses fonctionnalités telles que la gestion docu-

mentaire, la gestion de contenu Web, la gestion des versions et l’archivage des documents.

Alfresco combine l’innovation du monde open source avec la stabilité et les performances

d’une plateforme dédié à l’entreprise. Le modèle open source permet à Alfresco d’utiliser

les composants de référence existants et d’obtenir des contributions de la communauté afin

d’obtenir un logiciel de plus grande qualité, plus rapidement, et à moindre cout. Un des points

forts d’Alfresco est qu’il est compatible avec un grand nombre de logiciels entre autres SAP

(Systems, Applications and Products for data processing), IBM Lotus et Microsoft SharePoint.

Alfresco est doté à toutes les autres plateformes par ses caractéristiques dont nous pouvons

citer :

29


1. Alfresco est Open Source

• Respecte les standards

• Evite d’être enfermé dans une technologie propriétaire,

• A un modèle de licence simple.

2. Alfresco permet plusieurs choix

• S’intègre aux autres logiciels sans connecteurs.

• S’adapte avec de multiples environnements

• Est compatible avec les outils existants

3. Alfresco facilite la personnalisation

• A de nombreuses APIs,

• Connu par ses définitions qui sont basées sur le modèle XML,

• Profite des compétences internes en Javascript et REST

4. Alfresco a une architecture supportant la montée en charge

• Utiliser l’infrastructure de l’entreprise,

• Ne connait pas de limite de taille de fichiers.

Activiti

Activiti [12] est un flux de travail léger et BPMN Plate-forme destinée aux

gens d’affaires, les développeurs et les administrateurs système. Son noyau est

un moteur ultra-rapide et solide comme le roc processus.BPMN (voir annexe A) pour Java. Il est

open-source et distribué sous la licence Apache. Activiti fonctionne dans toute application Java

sur un serveur, sur un cluster ou dans le nuage. Il intègre parfaitement avec le printemps, il est

extrêmement léger et basé sur des concepts simples.

Eclipse

Est un Integrated Development Environment (IDE),c’est-à-dire un logiciel

qui simplifie la programmation en proposant un certain nombre de raccourcis et

d’aide à la programmation. Il est développé par IBM, est gratuit et disponible pour

la plupart des systèmes d’exploitation [13].

30


4.2.2 Outil de conception

Enterprise Architect

Est un logiciel de modélisation et de conception UML, édité par la société

australienne Sparx Systems, couvrant, par ses fonctionnalités, l’ensemble des

étapes du cycle de conception d’application, il est l’un des logiciel de conception

et de modélisation les plus reconnus [14].

4.2.3 Langages de programmation

Dojo

Est un framework open source en JavaScript. Il propose de nombreux Widgets

étant des composants d’interface graphique ou encore des applications communi-

cantes et des bibliothèques Ajax pour développer une application interactive.

C’est un excellent cadre pour développer des applications basées sur Ajax. Depuis la version 0.9,

Dojo [15] est divise en trois parties : Dojo, Dijit et Dojox.

• Dojo Core, cette librairie inclut des fonctions pour la détection de navigateurs, encodage/dé-

codage JSON, un support de la technologie AJAX, un support d’animation, un support de style

CSS et un support pour la programmation orientée objet.

• Dijit, contient les différents Widgets fournis par Dojo.

• Dojox, fournit des Widgets expérimentales à la réalisation de graphiques 2D et 3D, l’accès aux

données multi-sources, de cryptographie, et beaucoup d’autres aspects.

Java

Est un langage de programmation orienté objet natif, il vient avec un en-

semble de classes de base qui permettent d’étendre le langage en créant de nou-

veaux types d’objets (interface graphique, accès au réseau, gestion des entrées/-

sorties...). Java [16] apporte une solution unique et efficace au développement et à la mise en suivre

d’applications Web et surtout en utilisant l’API Servlet qui fournit les éléments de base permettant la

conception de composants web dynamiques en Java.

31


Conclusion

Ce chapitre a été consacré à la présentation de l’environnement logiciel et matériel dans lequel

le projet a été élaboré ; nous passerons après ce chapitre à la phase de réalisation des sprints en

commençant par le sprint 1 qui sera dédié aux fonctionnalités du responsable commercial.

32

5 Sprint 1 : Responsable commercial

Introduction

Après avoir étudié les différentes technologies qui vont être utiliser dans le Sprint 0, nous allons

nous diriger vers les sprints qui décrivent les principaux objectifs et les fonctionnalités de notre futur

système. Plus précisément, nous allons définir notre sprint backlog puis nous allons raffiner les cas

d’utilisation présents dans le diagramme de cas d’utilisation global. Ensuite, nous allons établir la

vue statique à travers le diagramme de classes et la vue dynamique qui se manifeste par les différents

diagrammes de séquences illustré, finissons par la modélisation du processus métier.

5.1 Backlog du sprint

Le sprint est le cœur de Scrum. Il s’agit d’un bloc de temps durant lequel un incrément du

produit sera réalisé. Avant de se lancer dans un sprint, l’équipe Scrum doit obligatoirement définir

le but de ce dernier qui doit être un tableau descriptif qui précise la charge du travail pour chaque

tâche en nombre de jours, donc nous nous sommes intéressé à établir et définir notre sprint backlog

qui est décrit dans le Tableau 5.1.

5.2 Diagrammes des cas d’utilisations

Les besoins à réaliser dans le Sprint 1, ont été spécifiés et pour mieux expliquer nous allons vous

présenter les diagrammes de cas d’utilisation de l’authentification, la validation d’une demande

d’offre, affectation d’une demande d’offre, validation des offres commerciaux, préparation de l’offre,

traitement du bon de commande, consultation du dossier d’affaire, classement de l’offre commercial

et le classement du commande avec les descriptions textuelles.

33

Chapitre 5. Sprint 1 : Responsable commercial

TAB

LEA

U5.

1–

Bac

klo

gd

uSp

rin

t1

Typ

eU

ser

Sto

ryTa

skE

stim

atio

n

Sto

ryTe

chn

iqu

e

Mis

een

pla

ced

ela

pla

tefo

rme

Inst

alla

tio

nd

ela

pla

tefo

rme

Alf

resc

o6

heu

res

Inst

alla

tio

nd

uB

ecP

G2

heu

res

Test

erle

bo

nfo

nct

ion

nem

entd

ela

pla

tefo

rme

2h

eure

s

Mo

dél

isat

ion

du

wo

rkfl

ow

Cré

atio

nd

esp

rofi

lsd

esre

spo

nsa

ble

s8

heu

res

Mo

dél

isat

ion

des

tâch

esà

chaq

ue

pro

fil

4h

eure

sG

esti

on

des

tran

siti

on

sen

tre

les

tâch

es16

heu

res

Ges

tio

nd

esci

rcu

its

de

vali

dat

ion

12h

eure

sG

esti

on

des

do

nn

ées

mét

iers

12h

eure

s

Inté

grat

ion

du

wo

rkfl

owso

us

alfr

esco

Dép

loie

men

t8

heu

res

Test

erl’e

nch

aîn

emen

tdes

circ

uit

s4

heu

res

Inté

grat

ion

de

l’en

viro

nn

emen

tPic

oSo

ftav

ecal

frec

o

Co

nfi

gure

rl’e

nvi

ron

nem

entP

ico

Soft

(Exe

mp

le:

Co

nn

exio

nà

lab

ase

de

do

nn

ées.

..)8

heu

res

Cré

atio

nd

ela

clas

se"T

askD

etai

lPro

cess

.java

"p

ou

rin

voke

rle

sw

ebsc

rip

t8

heu

res

Cré

atio

nd

esgr

ou

pes

corr

esp

on

dan

tsà

chaq

ue

pro

fil

Ajo

utd

esm

emb

res

5h

eure

s

Aff

ecta

tio

nd

esp

rivi

lège

s3

heu

res

En

tan

tqu

ere

spo

nsa

ble

com

mer

cial

,je

sou

hai

teva

lid

eru

ne

dem

and

ed

’off

re

Cré

eru

ne

inte

rfac

ed

eva

lidat

ion

d’u

ne

dem

and

ed

’off

re"V

alid

ateD

eman

dP

ico.

jsp

"4

heu

res

Cré

eru

ne

serv

letd

eva

lid

atio

nd

’un

ed

eman

de

d’o

ffre

"Val

idat

eDem

and

.java

"8

heu

res

Test

erle

bo

nfo

nct

ion

nem

entd

el’i

nte

rfac

e3.

5h

eure

34


Cré

erle

typ

ed

em

od

èle

de

valid

atio

nd

’un

ed

eman

de

d’o

ffre

sou

sal

fres

co"w

ftes

t:V

alid

eru

ne

dem

and

ed

’off

re"

4h

eure

En

tan

tqu

ere

spo

nsa

ble

com

mer

cial

,je

sou

hai

teaf

fect

erla

dem

and

eau

xre

spo

nsa

ble

ste

chn

iqu

es

Cré

eru

ne

inte

rfac

ed

’aff

ecta

tio

nd

’un

ed

eman

de

d’o

ffre

"Aff

ecte

Dem

and

Pic

o.js

p"

4h

eure

s

Cré

eru

ne

serv

letd

’aff

ecta

tio

nd

’un

ed

eman

de

d’o

ffre

"Aff

ecte

Dem

and

.java

"9

heu

res

Test

erle

bo

nfo

nct

ion

nem

entd

el’i

nte

rfac

e3

heu

res

Cré

erle

typ

ed

em

od

èle

d’a

ffec

tati

on

d’u

ne

dem

and

ed

’off

reso

us

alfr

esco

"wft

est:

Aff

ecte

rla

dem

and

e"3,

5h

eure

Sto

ryU

tili

sate

ur

En

tan

tqu

ere

spo

nsa

ble

com

mer

cial

,je

sou

hai

teva

lid

erle

so

ffre

sco

mm

erci

aux

Cré

eru

ne

inte

rfac

ed

eva

lidat

ion

les

off

res

com

mer

ciau

x"V

alid

ateO

ffre

Pic

o.js

p"

3h

eure

s

Cré

eru

ne

serv

letd

eva

lid

atio

nle

so

ffre

sco

mm

erci

aux

"Val

idat

eOff

reco

mm

.java

"5

heu

res

Test

erle

bo

nfo

nct

ion

nem

entd

el’i

nte

rfac

e0,

5h

eure

Cré

erle

typ

ed

em

od

èle

de

valid

atio

nle

so

ffre

sco

mm

erci

aux

sou

sal

fres

co"w

ftes

t:V

alid

erle

so

ffre

sco

mm

erci

aux"

3,5

heu

re

En

tan

tqu

ere

spo

nsa

ble

com

mer

cial

,je

sou

hai

tep

rép

arer

l’off

re

Cré

eru

ne

inte

rfac

ed

ep

rép

arat

ion

de

l’off

re"P

rep

areO

ffre

Pic

o.js

p"

3h

eure

s

Cré

eru

ne

serv

letd

ep

rép

arat

ion

de

l’off

re"P

rep

areO

ffre

.java

"5

heu

res

Test

erle

bo

nfo

nct

ion

nem

entd

el’i

nte

rfac

e1,

5h

eure

Cré

erle

typ

ed

em

od

èle

de

pré

par

atio

nd

el’o

ffre

sou

sal

fres

co"w

ftes

t:P

rép

arer

l’off

re"

0,5

heu

re

En

tan

tqu

ere

spo

nsa

ble

com

mer

cial

,je

sou

hai

tetr

aite

rle

bo

nd

eco

mm

and

e

Cré

eru

ne

inte

rfac

ed

etr

aite

men

tdu

bo

nd

eco

mm

and

e"T

rait

eOrd

erP

ico.

jsp

"3

heu

res

Cré

eru

ne

serv

letd

etr

aite

men

tdu

bo

nd

eco

mm

and

e,"T

rait

eOrd

erO

ffre

.java

"8

heu

res

Test

erle

bo

nfo

nct

ion

nem

entd

el’i

nte

rfac

e1,

5h

eure

35


Cré

erle

typ

ed

em

od

èle

de

trai

tem

entd

ub

on

de

com

man

de

sou

sal

fres

co"w

ftes

t:Tr

aite

rle

bo

nd

eco

mm

and

e"3,

5h

eure

En

tan

tqu

ere

spo

nsa

ble

com

mer

cial

,je

sou

hai

teco

nsu

lter

led

oss

ier

d’a

ffai

re«

Do

ssie

rd

ep

rest

atio

n»

Cré

eru

ne

inte

rfac

ed

eco

nsu

ltat

ion

du

do

ssie

rd

’aff

aire

"Co

nsu

ltD

irP

ico.

jsp

"3

heu

res

Cré

eru

ne

serv

letd

eco

nsu

ltat

ion

du

do

ssie

rd

’aff

aire

"Co

nsu

ltD

irO

ffre

.java

"8

heu

res

Test

erle

bo

nfo

nct

ion

nem

entd

el’i

nte

rfac

e1,

5h

eure

En

tan

tqu

ere

spo

nsa

ble

com

mer

cial

,je

sou

hai

tetr

ansm

ettr

ela

com

man

de

Cré

eru

ne

inte

rfac

ep

ou

rtr

ansm

ettr

ela

com

man

de

"Up

load

Ord

erP

ico.

jsp

"3

heu

res

Cré

eru

ne

serv

letp

ou

rtr

ansm

ettr

ela

com

man

de

"Up

load

Ord

er.ja

va"

8h

eure

s

Test

erle

bo

nfo

nct

ion

nem

entd

el’i

nte

rfac

e1,

5h

eure

36


5.2.1 «Authentification»

Tout au long de ce travail, tous les utilisateurs dans notre système sont invités obligatoirement à

se connecter via une interface de connexion. La Figure 5.1 présente le diagramme de cas d’utilisation

de l’authentification.

FIGURE 5.1 – Diagramme de cas d’utilisation «Authentification»

Description textuelle :

• Acteurs : Administrateur, Responsable technique, Responsable financier, Responsable com-

mercial, Agent technique.

• Pré-condition : Aucune

• Post-condition : Utilisateurs authentifiés

• Description du scénario : L’utilisateur s’authentifie en saisissant son identifiant et son mot de

passe.

1. Le nom d’utilisateur et le mot de passe sont valides, l’utilisateur est connecté au système

et il peut par la suite accéder aux différentes fonctionnalités qu’offre notre application.

2. Le nom d’utilisateur et le mot de passe sont invalides, une interdiction d’accès est signalée

37


5.2.2 Raffinement des cas d’utilisations du responsable commercial

La Figure 5.2 décrit le raffinement des cas d’utilisations du responsable commercial.

FIGURE 5.2 – Raffinement des cas d’utilisations du responsable commercial

38


«Valider une demande d’offre»


• Acteurs : Responsable commercial.

• Pré-condition : Utilisateur authentifié.

• Post-condition : La validation ou l’invalidation de la demande d’offre.

• Description du scénario : L’utilisateur étant authentifié, il peut valider ou refuser une

demande d’offre.

«Affecter une demande d’offre»



• Pré-condition : Utilisateur authentifié

• Post-condition : La demande d’offre est affectée.

• Description du scénario : L’utilisateur étant authentifié, il demande d’afficher l’interface

de l’instance de l’affectation d’une demande d’offre. Le responsable remplit le formulaire

et le système affecte la demande d’offre.

«Valider les offres commerciaux»




• Post-condition : Offres commerciaux valides ou invalides.

• Description du scénario : L’utilisateur étant authentifié, il demande d’afficher l’inter-

face de validation des offres commerciaux. Un formulaire ayant les données de l’offre

commerciale s’affiche et le responsable commercial valide l’offre.

«Préparer l’offre»



• Pré-condition :Utilisateur authentifié.

• Post-condition : L’offre est préparé.

• Description du scénario :L’utilisateur, étant authentifié, il demande d’afficher l’interface

de préparation de l’offre. Le responsable commercial remplit le formulairee.

39


«Traiter le bon de commande»




• Post-condition : le bon de commande est traité.

• Description du scénario : L’utilisateur, étant authentifié, il demande d’afficher l’interface

de traitement du bon de commande. Un formulaire ayant des champs vides sera affiché

et le responsable commercial traite le bon de commande.

«Consulter le dossier d’affaire»


• Acteurs :Responsable commercial.


• Post-condition : Dossier d’affaire consulté.

• Description du scénario : L’utilisateur, étant authentifié, demande l’affichage de l’arbo-

rescence du dossier d’affaire et le système affiche les fichiers associés à chaque dossier.

«Classer l’offre commercial»




• Post-condition : Offre classé et transmis.

• Description du scénario : L’utilisateur, étant authentifié, demande l’affichage de l’arbo-

rescence du dossier d’affaire en cliquant sur le grid «Gestion des dossiers», le système

affiche l’arborescence du dossier d’affaire, ensuite le responsable commercial clique sur

bouton uploade pour importer le document.

40


«Classer l’offre»




• Post-condition : Offre classé et transmis.

• Description du scénario : L’utilisateur, étant authentifié. il affiche l’arborescence du

dossier d’affaire. En cliquant sur le grid «Gestion des dossiers», le système affiche l’arbo-

rescence du dossier d’affaire, ensuite le responsable commercial clique sur uploade pour

transmettre le document.

«Classer la commande»




• Post-condition : Commande classé et transmis.

• Description du scénario : L’utilisateur, étant authentifié. il affiche l’arborescence du

dossier d’affaire. En cliquant sur le grid «Gestion des dossiers», le système affiche l’ar-

borescence du dossier d’affaire. Le responsable transmet le document sous le dossier

commande.

5.3 Conception

Cette partie a pour objectif de définir la solution conceptuelle de notre projet. Nous allons

présenter en premier lieu une vue statique à travers les diagrammes de classes des différents packages

de l’application et par la suite une vue dynamique à travers les diagrammes de séquences pour les

scénarios d’exécution les plus importants.

5.3.1 Diagramme de classes

Un élément central de conception d’un logiciel est le diagramme de classes, c’est un modèle

représentant la structure du système à concevoir. Le diagramme de classes est un schéma utilisé pour

présenter les classes et les interfaces d’un système ainsi que les différentes relations, ce diagramme

appartient à la partie statique d’ UML car il fait abstraction des aspects temporels et dynamiques.

41


Nous nous sommes concentrés sur la définition des différentes classes nécessaires pour notre

application en se basant sur le diagramme de classes présenté par la Figure 5.3

FIGURE 5.3 – Diagramme de classes du responsable commercial

La Tableau 5.2 présente une description du diagramme du classe présenté dans ce Sprint.

42


TABLEAU 5.2 – Descriptif des classes du sprint 1

Classe DescriptionDocument C’est l’ensemble des documents ajoutés et traités en cours du processus de prestation.

AffaireC’est la racine d’une arborescence des dossiers crées au moment de la validation d’unedemande d’offre. Chaque demande d’offre validée par le responsable commercial est uneaffaire.

OffreC’est un dossier ajouté au moment de la création d’une affaire il peut contenir un ensembledes documents.

CommandeC’est un dossier ajouté au moment de la création d’une affaire, il peut contenir un ensembledes documents relative à une commande.

Revuecommer-cial

C’est un dossier ajouté au moment de la création d’une affaire, il peut contenir un ensembledes documents relatives au revue commercial.

Responsablecommer-cial

C’est le responsable commercial dont son rôle est d’affecter une demande d’offre au respon-sables technique.

Client C’est le client qui est associé à une demande d’offre.

RevueC’est un dossier qui peut contenir la liste des revues commerciaux et les revues techniques, ilest ajouté au moment de la création d’une affaire.

5.3.2 Diagrammes de séquences

Pour schématiser la vue comportementale de notre système informatique, nous faisons recours

au diagramme de séquence d’UML. Ce diagramme permet de présenter les interactions entre

l’acteur et le système avec des messages présentés dans un ordre chronologique. Le comportement

du système est décrit vu de l’extérieur sans avoir d’idée sur comment il le réalisera.

Définition. Diagramme de séquence : Ce diagramme permet de décrire les scénarios de chaque cas

d’utilisation en mettant l’accent sur la chronologie des opérations en interaction avec les objets.

Nous représentons dans cette section, les diagrammes de séquences relatives à quelques scénarios

d’utilisation de notre système.

Nous représentons dans cette section, les diagrammes de séquences relatives à quelques scéna-

rios d’utilisation de notre système relatifs au responsable commercial.

«Authentification»

Le diagramme de séquence de la Figure 5.4 décrit les étapes détaillées de la phase d’authen-

tification d’un utilisateur. Pour ce faire, l’utilisateur doit saisir son identifiant et son mot de passe.

Le système vérifie par la suite ces informations et permettra l’accès à l’utilisateur en cas de réus-

site(correspondance trouvée).

43


FIGURE 5.4 – Diagramme de séquence «Authentification»

«Valider une demande d’offre»

La Figure 5.5 décrit le diagramme de séquence du cas d’utilisation «Valider une demande d’offre»


• Une fois authentifié, le responsable commercial accède à l’interface de validation d’une

demande d’offre et saisit les informations associés à une demande d’offre bien définit.

• L’interface vérifie la validité des données

• Si les champs obligatoires sont invalides, une alerte indiqunt que les champs doivent

être vérifiés, sera affiché.

• Si les champs obligatoires sont remplit correctement, les données seront envoyées au

contrôleur qui lui même vérifie la décision de validation de l’offre.

• si l’offre est validé, une nouvelle affaire est ajoutée ce qui implique la création d’une offre,

d’une commande, d’une revue et d’une revue commercial.

• Finalement, un message de succès sera affiché

44


FIGURE 5.5 – Diagramme de séquence «Valider une demande d’offre»

45


• Si l’offre n’est pas validé, un mail sera envoyé au client en indiquant la raison du rejet.

«Classer l’offre»

La Figure 5.6 décrit le diagramme de séquence du cas d’utilisation «Classer l’offre»

FIGURE 5.6 – Diagramme de séquence «Classer l’offre»


• Le responsable commercial demande l’affichage de l’interface de gestion des offres et

récupère l’offre du contrôleur de classification des offres.

46


• Le contrôleur accède à l’offre et sélectionne la liste des fichiers importés qui sera affiché

par la suite à l’interface de gestion des dossiers.

• Par la suite, le responsable commercial, importe le fichier souhaité et l’envoie au contrô-

leur.

• Aprés l’enregistrement du fichier, la nouvelle liste des fichiers sera affichée.

«Classer l’offre commercial»

La Figure 5.7 décrit le diagramme de séquence du cas d’utilisation «Classer l’offre commercial»

FIGURE 5.7 – Diagramme de séquence du cas d’utilisation «Classer l’offre commercial»

47



• Le responsable commercial demande l’affichage de l’interface de gestion des dossiers et

récupère la revue du contrôleur de classification des offres commerciales.

• Le contrôleur accède à la revue commerciale et sélectionne la liste des fichiers importés

qui sera affiché par la suite à l’interface de gestion des dossiers.

• Par la suite, le responsable commercial, importe le fichier souhaité et l’envoie au contrô-

leur.


«Traiter le bon de commande»

La Figure 5.8 décrit le diagramme de séquence du cas d’utilisation «Traiter le bon de commande»


• Le responsable commercial accède à l’interface du traitement du bon de commande

pour saisir un bon de commande.

• L’interface vérifie la validité des champs saisit.

• Si les champs obligatoires sont saisies correctement, les données seront envoyées au

contrôleur qui à son tour enregistre la commande.

• Un message qui indique que le bon de commande est traité avec succès sera affiché.

• Si les champs obligatoires sont invalides, un message d’alert sera affiché.

48


FIGURE 5.8 – Diagramme de séquence du cas d’utilisation «Traiter le bon de commande»

5.4 Modélisation du processus métier

La modélisation est une phase primordiale dans la gestion des processus métier, car elle permet

de définir et spécifier l’activité métier de l’entreprise. Nous utilisons pour cette étape la spécification

BPMN 2.0 qui nous offre une compréhensibilité de la part de tous les acteurs principaux.

5.4.1 Procesus du responsable commercial

Le processus illustré dans la Figure 5.9 a pour but d’automatiser la saisie, la validation d’une

demande d’offre, ainsi que la validation de l’offre commercial, en finissant par la saisie du commande.

49


FIGURE 5.9 – Processus du responsable commercial

Description détaillée des tâches du responsable commercial

L’entreprise reçoit une demande d’offre, le responsable commercial la traite selon leur secteur

d’activité, si la demande est invalide le système envoie une notification au client en indiquant le

raison de rejet sinon, le responsable commercial va créer le plan du classement des documents.

ensuite la tâche est assignée aux autres acteurs intervenant dans l’application. Suite à la réalisation

du travail par les autres collaborateurs, le responsable commercial valide les offres commerciaux, si

le travail est invalide, le système réassigne le travail aux autres acteurs pour être réaliser une autre

fois sinon il va préparer l’offre et l’envoie au client. Si la réponse du client est positive il va traiter le

bon de commande envoyé par le client sinon la demande d’offre est annulée.

50


5.5 Réalisation

Dans cette partie, nous allons exposer quelques scénarios d’exécution à travers des captures

d’écran.

FIGURE 5.10 – Interface d’authentification

FIGURE 5.11 – Interface de validation d’une demande d’offre

51


FIGURE 5.12 – Interface de la décision du client

FIGURE 5.13 – Interface de l’envoie d’un e-mail au client

52


FIGURE 5.14 – Interface d’ajouter du plan de classement

FIGURE 5.15 – Interface de création du plan de classement

53


FIGURE 5.16 – Interface de la préparation de l’offre

FIGURE 5.17 – Interface de traitement du bon de commande

54


FIGURE 5.18 – Interface de classement de la commande

Conclusion

Au cours de ce chapitre nous tenons à réaliser les tâches demandées par le «Product Owner».

Pour ce faire nous avons passé par la conception et la réalisation. Nous passerons maintenant vers le

chapitre consacré au Sprint 2.

55

6 Sprint 2 : Responsable technique

Introduction

Aprés la réalisation du sprint 1, nous attaquant maintenant le sprint 2. Ce chapitre définit en

premier lieu le sprint backlog du responsable technique, et par la suite nous allons définir la partie

conceptuelle en commençant par le diagramme de classes puis les diagrammes de séquences et en

finissant par la phase de réalisation.


Le Tableau 6.1 définit le backlog du sprint 2 qui précise les tâches à réaliser.


Dans cette section nous allons montrer les différents cas d’utilisation relatifs au responsable

technique.

6.2.1 Raffinement des cas d’utilisations du responsable technique

«Affecter les travaux mentionnées dans le bon de commande»

La Figure 6.1 montre le raffinement du diagramme des cas d’utilisations du responsable tech-

nique.


• Acteurs : Responsable technique.


• Post-condition :Les travaux sont affectés.

• Description des scénarios : Le responsable technique demande d’afficher l’interface d’affec-

tation des travaux mentionnées dans le bon de commande. Le système affiche un formulaire

avec des champs vides. Le responsable technique remplit les champs nécessaires qui seront

vérifier par le système, un message indiquant que les travaux sont affectés avec succès sera

affiché.

56

Chapitre 6. Sprint 2 : Responsable technique

TAB

LEA

U6.

1–

Bac

klo

gd

uSp

rin

t2

Use

rSt

ory

Task

Est

imat

ion

En

tan

tqu

ere

spo

nsa

ble

tech

niq

ue

jeve

ux

affe

cter

les

revu

esd

uco

ntr

atau

xéq

uip

este

chn

iqu

esp

ou

rca

lcu

ler

leu

res

tim

atio

n.

Cré

eru

ne

inte

rfac

ed

’aff

ecta

tio

nd

ela

revu

ed

uco

ntr

atau

xéq

uip

este

chn

iqu

es"A

ffec

teR

evie

wP

ico.

jsp

"5

heu

res

Cré

eru

ne

serv

let

de

d’a

ffec

tati

on

du

revu

ed

uco

ntr

atau

xéq

uip

este

chn

iqu

es"A

ffec

teR

evie

w.ja

va"

8h

eure

s

Test

erle

bo

nfo

nct

ion

nem

entd

el’i

nte

rfac

e1,

5h

eure

sC

réer

lety

pe

de

mo

dèl

eso

us

alfr

esco

"wft

est

:Aff

ecte

rle

sre

vues

du

con

trat

aux

équ

ipes

tech

niq

ues

"5

heu

res

En

tan

tqu

ere

spo

nsa

ble

tech

niq

ue

jeve

ux

vali

der

les

off

res

tech

niq

ues

.

Cré

eru

ne

inte

rfac

ed

eva

lid

atio

nd

el’o

ffre

tech

niq

ue

"Val

idat

eTec

hO

ffre

Pic

o.js

p"

5h

eure

sC

réer

un

ese

rvle

tde

vali

dat

ion

de

l’off

rete

chn

iqu

e"V

alid

ateT

ech

Off

re.ja

va"

8h

eure

sTe

ster

leb

on

fon

ctio

nn

emen

tde

l’in

terf

ace

2h

eure

sC

réer

lety

pe

de

mo

dèl

eso

us

alfr

esco

"wft

est:

Val

ider

les

off

res

tech

niq

ues

"5

heu

res

En

tan

tqu

ere

spo

nsa

ble

tech

niq

ue

jeve

ux

affe

cter

les

trav

aux

men

tio

nn

ées

dan

sle

bo

nd

eco

mm

and

e.

Cré

eru

ne

inte

rfac

ed

’aff

ecta

tio

nd

estr

avau

xm

enti

on

née

sd

ans

leb

on

de

com

-m

and

e"A

ffec

teW

ork

Pic

o.js

p"

5h

eure

s

Cré

eru

ne

serv

letd

’aff

ecta

tion

des

trav

aux

men

tion

née

sd

ans

leb

ond

eco

mm

and

e"A

ffec

teW

ork

.java

"8

heu

res

Test

erle

bo

nfo

nct

ion

nem

entd

el’i

nte

rfac

e1

heu

reC

réer

lety

pe

de

mo

dèl

eso

us

alfr

esco

"wft

est

:Aff

ecte

rle

str

avau

xm

enti

on

née

sd

ans

leb

on

de

com

man

de"

5h

eure

s

En

tan

tqu

ere

spo

nsa

ble

tech

niq

ue

jeve

ux

vali

der

laré

alis

atio

n

Cré

eru

ne

inte

rfac

ed

eva

lid

atio

nd

ela

réal

isat

ion

"Val

idat

eRea

lisa

tio

nP

ico.

jsp

"5

heu

res

Cré

eru

ne

serv

letd

eva

lid

atio

nd

ela

réal

isat

ion

"Val

idat

eRea

lisa

tio

n.ja

va"

8h

eure

sTe

ster

leb

on

fon

ctio

nn

emen

tde

l’in

terf

ace

1,5

heu

res

Cré

erle

typ

ed

em

od

èle

sou

sal

fres

co"w

ftes

t:V

alid

erla

réal

isat

ion

"5

heu

res

57


FIGURE 6.1 – Diagramme des cas d’utilisations du responsable technique

«Valider les offres techniques»




• Post-condition : Offre technique soit valide soit invalide.

58


• Description des scénarios : Le responsable demande d’afficher l’interface de validation des

offres techniques. Le système affiche un formulaire vides. Le responsable technique remplit

les champs nécessaires et les valides, le système vérifie les champs déja saisit et enregistre

l’état des offres.

«Valider la réalisation»




• Post-condition : Réalisation valide ou non valide.

• Description des scénarios : Le responsable demande d’afficher l’interface de validation de

la réalisation. Le système affiche un formulaire vides. Le responsable technique remplit les

champs nécessaires et les valides.

«Consulter le dossier d’affaire»




• Post-condition : Dossier d’affaire consulté.

• Description des scénarios : Le responsable demande l’affichage de la liste des dossiers créés

en cliquant sur la grid « Gestion des dossiers», le système affiche une arborescence des dossiers

et les documents associés à chaque dossier.

«Classer les offres techniques»




• Post-condition : Offres techniques classés.

• Description des scénarios : Le responsable demande la liste des dossiers crées en cliquant

sur la grid « Gestion des dossiers», le système affiche une arborescence des dossiers et ses

documents, puis il clique sur « Revue technique » et uploade les offres.

59


6.3 Conception


présenter en premier lieu une vue statique à travers les diagrammes de classe des différents packages


scénarios d’exécution les plus importants pour le responsable technique.


Dans cette partie nous allons présenter le diagramme de classes du responsable technique.

La Figure 8.1 illustre le diagramme de classes.

Le Tableau 6.2 représente une description du diagramme de classes.


Classe DescriptionResponsable tech-nique

C’est la classe qui présente les responsable techniques dont leurs rôlesest de d’affecter la demande aux agents techniques.

Revue techniqueC’est un dossier créer au moment de la création d’un affaire il peutcontenir un ensemble des documents relative au revue technique.

Realisation C’est une description des travaux du bon de commande.


Nous présentons dans cette partie les diagrammes de séquence relatives à quelques scénarios

des cas d’utilisations de notre application.

«Classer les offres techniques»


• Le responsable technique demande l’affichage de l’interface de gestion des dossiers et récupère

la revue technique du contrôleur de classification des offres techniques.

• Le contrôleur accède à la revue technique et sélectionne la liste des fichiers importés qui sera

affiché par la suite à l’interface de gestion des dossiers.

• Par la suite, le responsable technique, importe le fichier souhaité et l’envoie au contrôleur.


La Figure 6.3 montre le diagramme de séquence "Classer les offres techniques".

60


FIGURE 6.2 – Diagramme de classes du responsable technique

61


FIGURE 6.3 – Diagramme de séquence «Classer les offres techniques»

62


«Valider les offres techniques»


• Le responsable technique demande l’affichage de l’interface de validation des offres tech-

niques et saisit les informations associés à une offre technique bien définit.

• L’interface vérifie la validité des données.

• Si les champs obligatoires sont invalides, une alerte indiqunt que les champs doivent être

vérifiés, sera affiché.

• Si les champs obligatoires sont remplit correctement, les données seront envoyées au contrô-

leur qui lui même vérifie la décision de validation de l’offre technique.

• si l’offre technique est validé, un message de succès sera affiché

• Si l’offre technique n’est pas validé, une redirection vers la tâche précédente sera faite.

La Figure 6.4 montre le diagramme de séquence «Valider les offres techniques».

«Valider la réalisation»


• Le responsable technique demande l’affichage de l’interface de validation de la réalisation et

saisit les informations associés à la réalisation.

• L’interface vérifie la validité des données


vérifiés sera affiché.


leur qui lui même vérifie la décision de validation de la réalisation.

• si la réalisation est validé, un message de succès sera affiché

• Si la réalisation n’est pas validé, une redirection vers la tâche précédente sera faite.

La Figure 6.5 montre le diagramme de séquence «Valider la réalisation».

63


FIGURE 6.4 – Diagramme de séquence «Valider les offres techniques»

64


FIGURE 6.5 – Diagramme de séquence «Valider la réalisation»

65


6.4 Modélisation d’un processus métier

6.4.1 Processus du responsable technique

La Figure 6.6 résume les différentes tâche effectuées par le responsable technique suite à une

demande d’offre. Elle présente le circuit de l’affectation les revues du contrat aux equipes techniques

et la validation des offres techniques, aussi bien l’affectation des travaux mentionnées dans le bon

de commande et la validation de la réalisation.


Suite à une demande d’offre arrivée et validée par le responsable commercial. Le responsable

technique affecte la demande au sous départements techniques pour l’étudier en préparant les

estimations et les offres techniques. Une fois que les offres sont préparés, il les traites, s’ils sont

invalidés, le responsable redistribue les revues du contrat aux autres équipes techniques sinon il

passe le processus à des autres collaborateurs. La commande doit être préparer par les équipes

techniques donc le responsable va affecter les travaux mentionnées dans le bon de commande aux

équipes techniques qui vont travailler et réaliser le travail puis il le valide.

FIGURE 6.6 – Processus du responsable technique

66


6.5 Réalisation

Dans cette partie nous allons lister les différents interfaces réaliser dans ce Sprint.

FIGURE 6.7 – Interface d’affectation des travaux mentionnés dans la demande d’offre

FIGURE 6.8 – Interface de la validation des offres techniques

67


FIGURE 6.9 – Interface du classement des offres techniques

FIGURE 6.10 – Interface de la validation des travaux mentionnés dans le bon de commande

Conclusion

Dans cette partie nous avons présenté le backlog du sprint ainsi que les diagrammes UML

nécessaires et la réalisation. Nous passerons par la suite au Sprint 3 qui décrit les besoins de l’agent

technique.

68

7 Sprint 3 : Agent technique

Introduction

Après avoir traiter la partie du responsable technique, et du responsable commercial, nous

intéressons dans ce chapitre à définir le backlog qui détaillera le module de l’agent technique et

exposer l’étape de la conception et nous finissons par la partie de la réalisation.


Le Tableau 7.1 présente le backlog du sprint 3.

TABLEAU 7.1 – Backlog du sprint 3

User Story Task EstimationEn tant que agent tech-nique je veux préparerl’offre technique

Créer une interface de préparation de l’offre technique"PrepareOffreTechPico.jsp"

8 heures

Créer une servlet de préparation de l’offre technique "Pre-pareOffreTech.java"

7 heures

Tester le bon fonctionnement de l’interface1,5heures

Créer le type de modèle de préparation de l’offre tech-nique sous alfresco "wftest : Préparer une offre tech-nique"

3,5heures

En tant que Agent Tech-nique je veux préparer laréalisation

Créer une interface de préparation de la réalisation del’offre technique "PrepareRealisPico.jsp"

8 heure

Créer une servlet de préparation de la réalisation de l’offretechnique "PrepareRealis.java"

7 heures

Tester le bon fonctionnement de l’interface1,5heures

Créer le type de modèle de préparation de la réalisationde l’offre technique sous alfresco "wftest : Préparer laréalisation"

3,5heures


Dans cette partie, nous présentons le diagramme des cas d’utilisations relatif au agent technique.

Nous détaillons ensuite chaque cas d’utilisation par une description textuelle.

7.2.1 Raffinement des cas d’utilisations de l’agent technique

la Figure 7.1 présente le diagramme de cas d’utilisation de l’agent technique.

69

Chapitre 7. Sprint 3 : Agent technique

FIGURE 7.1 – Diagramme du cas d’utilisation de l’agent technique

«Préparer l’offre technique»

• Acteurs : Agent technique.


• Post-condition : Offre technique préparé.

• Description des scénarios : L’utilisateur, étant authentifié, il demande d’afficher l’interface

de préparation des offres techniques. Le système affiche un formulaire vide. L’agent technique

remplit les champs nécessaires et les vérifie, un message indiquant que l’offre technique est

préparé sera affiché.

«Préparer réalisation»

• Acteurs : Agent technique.


• Post-condition : Réalisation préparé.

70


• Description des scénarios : L’utilisateur, étant authentifié, il demande d’afficher l’interface

«Préparer réalisation». Le système affiche un formulaire ayant des champs vides. L’agent

technique remplit les champs nécessaires et les valides. Le système affiche un message de

succès de préparation de la réalisation.

7.3 Conception


présenter en premier lieu une vue statique à travers les diagrammes de classes des différents packages


scénarios d’exécution les plus importants de l’agent technique.


La Figure 7.2 présente le diagramme du classe de l’agent technique.


Classe Description

Agent tech-

nique

Présente l’agent technique dont son rôle est de préparer les offres techinques

en calculant les estimations de chaque demande offre la demande aux agents

techniques, ainsi il prépare la réalisation.

71


FIGURE 7.2 – Diagramme de classes de l’agent technique

72


7.3.2 Diagrammes de sequences

«Préparer réalisation»

La Figure7.3 décrit le diagramme de séquence du cas d’utilisation «Préparer réalisation».

FIGURE 7.3 – Diagramme de séquence «Préparer réalisation»


• L’agent technique demande l’affichage de l’interface de la préparation de la réalisation et saisit

les informations associés à la réalisation.

73






leur qui lui même enregistre la réalisation et un message de succès sera affiché

• Sinon un message d’alerte sera affiché.

«Préparer l’offre technique»


La Figure 7.4 décrit le diagramme de séquence du cas d’utilisation «Préparer l’offre technique».

FIGURE 7.4 – Diagramme de séquence «Préparer l’offre»

74



• L’agent technique demande l’affichage de l’interface de la préparation des offres techniques et

saisit les informations associés à une offre technique bien définit.





leur qui lui même enregistre l’offre technique et un message de succès sera affiché


7.4 Modelisation du processus

7.4.1 Processus de l’agent technique

La Figure7.5 met en évidence le processus de l’agent technique.

FIGURE 7.5 – Processus de l’agent technique

Le responsable technique affecte la demande aux agents techniques pour préparer les offres

techniques en calulant les estimation. Suite à la validation de l’offre et le traitement du bon de

commande par le responsable commercial, les agents techniques vont préparer la commande : c’est

la phase de la préparation de la réalisation.

75


7.5 Réalisation

Dans cette partie nous allons lister les différent interfaces réalisées dans ce Sprint.

FIGURE 7.6 – Interface de prépartion les offres techniques

FIGURE 7.7 – Interface de la prépartion des réalisations

Conclusion

Nous avons clôturé ce chapitre en donnant un aperçu sur les fonctionnalités réalisées à travers

la phase du conception et les différentes interfaces de notre application.

76

8 Sprint 4 : Responsable financier

Introduction

Ce chapitre décrit les differents fonctionalités du responsable financier, nous commençons

par la présentation du sprint backlog de ce dernier et par la suite nous allons étudié sa partie

conceptuelle et en finissant par la phase de réalisation.


Le Tableau 8.1 illustre le backlog du sprint 4.

TABLEAU 8.1 – Backlog du sprint 4

User Story Task EstimationEn tant que ResponsableFinancier je veux préparerune facture.

Créer une interface de facturation "PrepareFactur-Pico.jsp"

8 heures

Créer une servlet de préparation facture "PrepareFac-tur.java"

7 heures

Tester le bon fonctionnement de l’interface 2 heuresCréer le type du modèle de préparation facture sousalfresco "wftest : Préparer une facture"

3,5 heures

En tant que ResponsableFinancier je veux classerune facture.

Créer une interface de classement d’une facture "Clas-seFacturPico.jsp"

8 heures

Créer une servlet de classement de facture "ClasseFac-tur.java"

8 heures

Tester le bon fonctionnement de l’interface 2 heures


Nous présentons le diagramme des cas d’utilisations relatif aux responsables financiers ainsi

qu’une description textuelle des cas présentent.

8.2.1 Raffinement des cas d’utilisations du responsable financier

La Figure 8.1 présente le diagramme du cas d’utilisation du responsable financier.

«Préparer facture»

• Acteurs : Responsable financier.


• Post-condition : Facture préparée.

77

Chapitre 8. Sprint 4 : Responsable financier

• Description du scénario : L’utilisateur, étant authentifié, il demande d’afficher l’interface

«Préparer facture». Le système affiche un formulaire vide. Le responsable financier remplit les

champs nécessaires qui seront vérifiés par le système, un message de succès est affiché.

«Classer facture»

• Acteurs :Agent technique.

• Pré-condition :Utilisateur authentifié

• Post-condition :Facture classée.

• Description des scénarios :En cliquant sur la grid « Gestion des dossiers», le système affiche

l’arborescence du dossier d’affaire, ensuite le responsable financier clique sur uploade pour

ajouter le document sous le dossier facture.

FIGURE 8.1 – Diagramme des cas d’utilisations du responsable financier

8.3 Conception


présenter en premier lieu une vue statique à travers les diagrammes de classe des différents packages


scénarios d’exécution les plus importants du responsable financier.

78



La Figure8.2 montre le diagramme du classe du responsable financier.


Classe Description

Responsable financierPrésente le responsable financier dont son rôle est de préparerla facture et la classer sous le dossier facture

Facture Présente le dossier facture dont il peut etre contenir des document

FIGURE 8.2 – Diagramme de classes du responsable financier

79



«préparer facture»

La Figure 8.3 décrit le diagramme de séquence «Préparer facture»

FIGURE 8.3 – Diagramme de séquence «Préparer facture»


• Le responsable financier demande l’affichage de l’interface de la préparation de la facture et

saisit les informations associés à une facture.



80




leur qui lui même enregistre la facture et un message de succès sera affiché


«Classer facture»

La Figure 8.4 décrit le diagramme de séquence «Classer facture»

FIGURE 8.4 – Diagramme de séquence «Classer facture»

81



• Le responsable financier demande l’affichage de l’interface de classification des factures et

récupère la facture du contrôleur de classification des factures.

• Le contrôleur accède à la facture et sélectionne la liste des fichiers importés qui sera affiché

par la suite à l’interface de classification des factures.

• Par la suite, le responsable financier, importe le fichier souhaité et l’envoie au contrôleur.


8.4 Réalisation

Dans cette partie, nous allons exposer quelques scénarios d’exécution à travers des captures

d’écran.

FIGURE 8.5 – Interface de la préparation d’une facture

82


FIGURE 8.6 – Interface de classement d’une facture

8.5 Phase de clôture

Souvent négligée, la phase clôture d’un projet est essentiellement à la fin de sa phase de

réalisation. La clôture relève de la responsabilité de l’équipe ; c’est le constat de l’achèvement de

l’ensemble des tâches pour mettre fin à l’entente contractuelle. La clôture du projet comprend la

fermeture des dossiers relatifs au projet et consiste à évaluer tous ce qui est réaliser tout au long du

projet.

La Figure 8.7 illustre le diagramme de GANTT présentant le déroulement des Sprint.

83


FIGURE 8.7 – Diagramme de GANTT

84


Conclusion

Dans ce chapitre nous avons terminé les tâches données par le product owner et nous avons

réussie à développer la totalité de l’application après une conception des tâches présentées dans le

backlog du sprint afin d’aborder à livrer un produit complet et fonctionnel. Il nous reste seulement

une dernière étape qui consiste à tester l’application auprès du client final.

85

Conclusion généraleDurant notre stage, nous avons travaillé sur l’automatisation de la gestion du processus de

prestation au sein d’une entreprise. Cela consistait à concevoir une application d’entreprise, com-

plètement paramétrable, gérant le Workflow suite à une demande d’offre. Ce projet a exigé un effort

aussi bien au niveau de l’étude théorique qu’au niveau de la conception pour aboutir finalement à

une solution ergonomique, flexible et répondant à notre besoin.

Nous avons commencé par présenter le contexte général de notre projet à savoir l’entreprise

dans laquelle notre stage a été déroulé. Nous avons commencé par l’étude des pricipaux concept

relatifs à l’archivistique et par la suite nous avons étudié les principaux thèmes relatifs à la gestion

des processus métiers et les Workflow en particulier. Nous avons vu en plus les moteurs de Workflows

les plus connus en dressant une comparaison multicritère entre eux, ce qui nous a mené au choix

d’Activiti pour notre application. Après, nous avons planifié notre projet par l’analyse et spécifica-

tion des différents besoins qui devraient satisfaire notre application et les fonctionnalités qu’elles

devraient offrir aux acteurs et par decrir notre backlog de produit.

Par la suite nous avons présenté, l’environnement de notre travail et les outils et les technologies

utilisés tout au long de notre stage. Nous nous sommes intéressés à l’étude conceptuelle de notre

projet dans laquelle nous avons dégagé dans une première partie l’architecture trois tiers de notre

application. Nous avons détaillé dans une deuxième partie notre conception à travers les diagrammes

de séquences, et le dagramme de classe. Finalement, et bien sûr nous avons exposé notre application

par quelques scénarios d’exécution et une simulation d’exécution d’un processus à travers des

captures d’écran.

Ce stage effectué nous a permis d’acquérir une expérience enrichissante tant au niveau pro-

fessionnel qu’au niveau personnel. En effet, l’usage de tous ces outils nous a permis de mettre en

pratique certaines connaissances acquises tout au long de notre cursus d’études. Nous avons eu la

chance de maitriser en plus de nouvelles technologies plus qu’intéressantes.

Durant l’évolution de notre projet, nous avons maitrisé la notion de gestion des dossier sous

alfresco share. Ce stage a été en outre une bonne occasion pour bien découvrir le monde du travail

dans le secteur Informatique et pour enrichir la notion du travail en groupe, la communication et

surtout la prise de responsabilité. Dans ce stade, nous avons achevé notre projet, mais ça n’implique

pas évidemment que le travail fait soit parfait ou inchangeable, au contraire, il restera ouvert à toute

proposition d’amélioration. D’ailleurs son caractère générique et évolutif nous offrira une infinité de

86

Conclusion générale

possibilités d’extension.

Finalement, notre travail ne s’arrête pas à ce niveau, en effet plusieurs fonctionnalités peuvent

être ajoutées à notre application notamment la validation automatique des affaires pour diminuer

l’interaction humaine avec le système et la génération automatique des rapport concernant les

dossier acceptés et les dossiers refusées ainsi que les causes de refus, la partie mobile est très

importante dans notre cas donc il est possible de développer une application mobile pour la gestion

des dossiers.

87

A Spécification BPMN 2.0

A.1 Définition du BPMN

Business Process Modeling Notation est un standard qui a été développé par BPMI.1 Sa première

version BPMN 1.0 a été libérée au public en mai 2004. L’objectif principal de cette spécification est

de fournir une notation standardisée qui est facilement compréhensible par tous les professionnels,

les analystes et les développeurs. Pour commencer, nous présentons le tableau A.1 qui définit les

éléments de base de cette spécification.

TABLEAU A.1 – Eléments de base de la spécification BPMN 2.0

Elément de base Notation

Evénement

Activité

Branchement/Décision

Flux

1BPMI : Business Process Management Initiative, organisation à but non lucratif qui existe pour promouvoir la norma-lisation de et la définition commune des processus métier. Elle supporte aussi le développement B2B et le commerceéléctronique.

i

Annexe A. Spécification BPMN 2.0

TABLEAU A.2 – Description de quelques éléments de la spécification BPMN 2.0

Elément Description Notation

Activité/tâche Type d’activité selon la nature de l’action réalisée.

Marqueurs

d’activitéLes marqueurs indiquent la nature de l’activité.

Les couloirs

d’activités

Les couloirs permettent d’associer les activités aux

intervenants.

Flux de sé-

quenceIl relie une activité à son successeur.

Flux Condi-

tionnel

Il relie une activité à son successeur. Cette liaison

ne sera franchise que si la condition associée est

vérifiée.

Branchement

exclusif

Le flux de séquence que sa condition est évaluée à

vraie sera sélectionné pour la poursuite du proces-

sus.

Branchement

parallèle

Modéliser la simultanéité dans un processus. Afin

de finaliser une convergence (join), toutes les

branches doivent être complétées. Lors d’une divi-

sion (fork), toutes les branches sont activées simul-

tanément.

ii

Annexe A. Spécification BPMN 2.0

Branchement

inclusif

Lors d’un branchement inclusif, une ou plusieurs

liaisons sont franchises. Afin de finaliser une

convergence, toutes les branches doivent être com-

plétées.

Evènement

de débutIndique où un processus démarre.

Evènement

de finIndique la fin du processus.

Evènement

de temps

Les évènements de temps sont des évènements qui

sont déclenchés par une date, durée ou un cycle de

temps défini. Il peut être utilisé comme un évène-

ment de démarrage, intermédiaire ou de fin.

iii

B AlfrescoAlfresco est un système de gestion de contenu open source d’Enterprise. Il est principalement

implémenté en Java, adaptée à un certain nombre d’environnements, y compris J2EE et rassemble le

meilleur des autres projets open source afin de fournir un ensemble complet de solutions de gestion

de contenu. Il est pas lié à un navigateur particulier, système d’exploitation, serveur d’application ou

base de données.

B.1 Description des principaux notion du alfresco

Dans cette partie nous allons lister les différents fonctionalités relative au alfresco.

B.1.1 Notion d’espace

Un espace est un dossier, Il peut contenir tout type d’élément, On peut y associer une description

et un icône, On peut y créer des sous espaces. Il apparaît comme un dossier partagé dans le voisinage

réseau.

B.1.2 Notion de contenu

Un contenu est un fichier ou un document, il est composé de plusieurs éléments ,le contenu

proprement dit, Les informations à propos du contenu (meta-données), Type (document, vidéo,

audio, images, XML, HTML, ...), Propriétés (langue, créateur, date, catégorisé, Liens vers des contenus

associés . . .), partage de copie, discussion, . . .

B.1.3 Suivi de version

• Permet la conservation des versions précédentes d’un élément

• Par défaut, une nouvelle version est créée quand un document est créé ou sauvegardé.

• L’historique est consultable, et il est possible de visualiser des versions anciennes ou de revenir

à une version antérieure.

B.1.4 Recherche

Recherche d’un document par mots clés : Pour chercher un document, il est possible d’utiliser

la zone de la recherche située dans le coin supérieur droit de l’interface.

Recherche avancée : La recherche avancée permet de rechercher un document avec l’utilisation

de plusieurs critères.

iv

Annexe B. Alfresco

B.1.5 Droits d’accès

• Lecteur : Lire.

• Contributeur : Lire et ajouter.

• Collaborateur : Lire, ajouter, copier, supprimer, archiver, extraire et télécharger.

• Gestionnaire : tous les droits d’accès, créer des sites, inviter d’autres utilisateurs, lire, copier,

supprimer, archiver, extraire, télécharger et mettre à jour/modifier le contenu créé par d’autres

utilisateurs.

B.1.6 Aspect

un aspect est un ensemble de métadonnées spécifiques à Alfresco, associées à un comportement

particulier. Par exemple, il existe dans Alfresco un aspect s’appelant «Validité ». Il permet d’ajouter

une date de début et de fin de validité à un contenu.

B.2 Espaces disponibles

L’onglet Mon tableau de bord : est l’endroit où l’utilisateur peut trouver toutes les informations

le concernant L’onglet Sites : permet l’accès à a.Recherche des sites.

b.Créer un site. L’onglet Personne : permet de trouver des personnes L’onglet Entrepôt : permet

l’accès au plan de classement, c’est l’espace où sont stockés tout les documents. L’accès est défini

par les droits d’accès. Mes tâches :les taches de l’utilisateur. Workflows que j’ai initiés : les taches et

les documents qui l’utilisateur a demandé de les réviser.

B.3 Etude comparative entre Alfresco et Nuxeo

Nous allons présenter une étude comparative entre les deux solution de gestion des dossiers

Alfresci et Nuxeo décrit dans le tableau B.1

Les deux solutions Alfresco et Nuxeo se sont distingués, car ils répondent aux besoins des

entreprises. Pour la concrétisation de nos objectifs, nous avons retenu la solution Alfresco comme

solution la plus adéquate et ce à cause de plusieurs critère

• Alfresco est plus grand avec plus de sujet couvert,

• Il se caractérise par une communauté internationale assez importante,

• Alfresco à un module de Recorde Management dédié à l’archivage qu’il n’existe pas à Nuxeo

• l’un des critères qui nous à poussé à choisir Alfresco est que Nuxeo n’intègre pas par défaut

v

Annexe B. Alfresco

TABLEAU B.1 – Etude Comparatif entre Alfresco et Nuxeo.

caractéristiques fonctionnel Alfresco NuxeoLes points forts Rapidité et Robustesse FlexibilitéLes points faibles Complexe à configurer Complexe à configurerInterface Simple SimpleSauvegarder de recherche (+) (+)Module de Record mange-ment

(+) (-)

Gestion des droits (+) (+)Archivage l’égal (+) (-)Workflow par defaut (+) (-)Communauté Grands Communauté Petite Communauté

certaine fonctionnalité importantes, par exemple le moteur de recherche, pour la recherche

en texte intégrale et que Alfresco donne la possibilité d’accéder aux documents de différentes

façons, a savoir l’interfaces CIFS, le webdav (avec les fonctionnalités de versionning et le

check-in/check-out) et le FTP. Par contre Nuxeo ne support que WebDav.

• Alfresco est un véritable outil de travail collaboratif qui offre non seulement la possibilité de

partager des documents, mais aussi de gérer les versions de documents et la mise en place de

circuits de validation grâce au système de workflow intégré.

Pour tous ces avantages Alfresco constituent le meilleur choix pour la gestion électronique de

documents. Les deux solutions « Alfresco » et « Nuxeo » servent de systèmes de gestion de documents.

Chaque solution a ses propres avantages et inconvénients. Mais d’après notre étude comparative,

nous avons conclu que la solution « Alfresco » est le meilleur système de gestion de documents

électroniques avec ses fonctionnalités puissantes de gestion de documents. Aussi, « Alfresco »

possède une interface utilisateur conviviale et une communauté d’utilisateurs dynamiques.

vi

C ActivitiActiviti est un moteur de Workflow souple et extensible, qui permet de créer des processus

métiers), qui cordonnent les personnes, les applications et les services. Il a été développé par

des anciens développeurs de la communauté Jboss. Il est distribué sous la forme d’une simple

bibliothèque Java, qui peut être utilisé d’une façon indépendante dans une application Java ou dans

un serveur d’applications pour des applications d’entreprise hautement extensibles.

C.1 Différents composants d’Activiti

La figure C.1 illustre une vue d’ensemble des différents composants d’Activiti.

FIGURE C.1 – Différents composants d’Activiti

• Activiti Engine : le coeur d’Activiti, qui exécute les fonctions du moteur du Workflow, telles

que l’exécution des processus métier BPMN 2.0 et la création des tâches.

• Activiti Modeler : un environnement de modélisation basé sur le Web permettant la création

des diagrammes BPMN 2.0. Il a été mise en place par Signavio qui offre des outils de modélisa-

tions commerciales comme Signavio Process Editor.

• Activiti Designer : un plugin Eclipse permettant la modélisation des processus BPMN 2.0 en

plus d’autres extensions d’Activiti pour les tâches de service et les écouteurs d’exécution.

• Activiti Explorer : une application Web qui peut être utilisée pour une large gamme de fonc-

tions en conjonction avec le moteur d’Activiti. Parmi ses fonctionnalités offertes, la consulta-

vii

Annexe C. Activiti

FIGURE C.2 – Activiti API

tion des tâches disponibles, l’effectuation des tâches et le déploiement des processus métier.

• Activiti REST : une application Web offrant une interface REST au-dessus d’Activiti Engine.

C.2 Activiti API

L’API du moteur est la façon la plus courante d’interagir avec Activiti. Le point départ de ces

services est ProcessEngine. Ces services sont multithread donc peuvent être invoqués simultanément.

La figure C.2 illustre les différents services de base offerts

• RepositoryService : offre des opérations de gestion et de déploiement des processus.

• RuntimeService : gère les instances en cours et les processus exécutés.

• TaskService : gère les tâches humaines (création, assignement, effectuation, etc.).

• HistoryService : expose toutes les données historiques recueillies par le moteur Activiti (ins-

tances, tâches accomplis, chemin suivi par une instance, etc.).

• FormService : gère les formulaires associés à une tâche humaine et les formulaires de début

de processus.

• IdentityService :permet la gestion (création, mise à jour, suppression, interrogation) des

utilisateurs et des groupes.

• ManagementService : pour un codage personnalisé. Il permet de récupérer des informations

sur les tables de bases de données et des métadonnées de table.

viii

Bibliographie[1] PicoSoft. Présentation. http ://www.picosoft.biz/picosoft.htm. Consulté le 05-02-2015.

[2] PicoSoft. Services. http ://www.picosoft.biz/services.htm. Consulté le 05-02-2015.

[3] PicoSoft. Produits. http ://www.picosoft.biz/produits.htm. Consulté le 05-02-2015.

[4] Cornel Fatulescu. Méthodologie agile - scrum. http ://www.pentalog.fr/. Consulté le 13-02-

2015.

[5] Sretiere. Scrum. https ://sretiere.wordpress.com/. Consulté le 09-02-2015.

[6] Pascal R. Franck V. UML2 en action de l’analyse des besoins à la conception. Consulté le

13-02-2015.

[7] La gestion électronique de GED. Consulté le 25-02-2015.

[8] Taylor. Terminology and Glossary. Consulté le 25-02-2015.

[9] improve technologies. Panorama des moteurs bpm/workflow open source.

http ://www.improve-technologies.com/2012/06/27/panorama-des-moteurs-bpmworkflow-

open-source/. Consulté le 25-02-2015.

[10] François Lasselin. Architecture : Le design pattern mvc en php. http ://-

blog.nalis.fr/index.php ?post/2009/10/19/Architecture-Consulté le 01-03-2015.

[11] Le concept d’ecm. http ://collaborative.smile.eu/Tout-savoir-sur/Gestion-documentaire/De-

la-ged-a-l-ecm/Le-concept-d-ecm. Consulté le 01-03-2015.

[12] Activiti bpm platform. http ://activiti.org/. Consulté le 02-03-2015.

[13] Eclipse (projet). http ://fr.wikipedia.org/wiki/Eclipse_%28projet%29. Consulté le 15-03-2015.

[14] Enterprise architect. http ://fr.wikipedia.org/wiki/Enterprise_Architect. Consulté le 15-03-2015.

[15] Amazing projects at the dojo foundation. http ://dojofoundation.org/projects/. Consulté le

15-03-2015.

[16] java. Qu’est-ce que la technologie java et pourquoi en ai-je besoin ?

https ://www.java.com/fr/download/faq/whatis_java.xml. Consulté le 12-03-2015.

ix

Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo

Technology

Transcript of Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo