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
6.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2 Diagrammes des cas d’utilisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
iii
Table des matières
6.2.1 Raffinement des cas d’utilisations du responsable technique . . . . . . . . . . . 56
6.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.3.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.3.2 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.2 Diagrammes des cas d’utilisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.2.1 Raffinement des cas d’utilisations de l’agent technique . . . . . . . . . . . . . . 69
7.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.3.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
8.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
8.2 Diagrammes des cas d’utilisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
iv
Table des matières
8.2.1 Raffinement des cas d’utilisations du responsable financier . . . . . . . . . . . . 77
8.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
8.3.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.3.2 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
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
6.2 Descriptif des classes du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.2 Descriptif des classes du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.1 Backlog du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
8.2 Descriptif des classes du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
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
Chapitre 1. Cadre général du projet
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
Chapitre 1. Cadre général du projet
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
Chapitre 1. Cadre général du projet
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
Chapitre 1. Cadre général du projet
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
Chapitre 1. Cadre général du projet
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
Chapitre 2. Etat de l’art
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
Chapitre 2. Etat de l’art
• 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
Chapitre 2. Etat de l’art
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
Chapitre 2. Etat de l’art
• 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
Chapitre 2. Etat de l’art
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
Chapitre 3. Planification
• 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
Chapitre 3. Planification
FIGURE 3.1 – Diagramme du cas d’utilisation global du responsable commercial
20
Chapitre 3. Planification
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
Chapitre 3. Planification
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
Chapitre 3. Planification
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
Chapitre 3. Planification
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
Chapitre 4. Sprint 0
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
Chapitre 4. Sprint 0
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
Chapitre 4. Sprint 0
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
Chapitre 4. Sprint 0
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
Chapitre 4. Sprint 0
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
Chapitre 4. Sprint 0
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
Chapitre 5. Sprint 1 : Responsable commercial
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
Chapitre 5. Sprint 1 : Responsable commercial
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
Chapitre 5. Sprint 1 : Responsable commercial
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
Chapitre 5. Sprint 1 : Responsable commercial
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
Chapitre 5. Sprint 1 : Responsable commercial
«Valider une demande d’offre»
Description textuelle :
• 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»
Description textuelle :
• Acteurs : Responsable commercial.
• 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»
Description textuelle :
• Acteurs : Responsable commercial.
• Pré-condition : Utilisateur authentifié.
• 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»
Description textuelle :
• Acteurs : Responsable commercial.
• 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
Chapitre 5. Sprint 1 : Responsable commercial
«Traiter le bon de commande»
Description textuelle :
• Acteurs : Responsable commercial.
• Pré-condition : Utilisateur authentifié
• 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»
Description textuelle :
• Acteurs :Responsable commercial.
• Pré-condition : Utilisateur authentifié.
• 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»
Description textuelle :
• Acteurs : Responsable commercial.
• Pré-condition : Utilisateur authentifié.
• 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
Chapitre 5. Sprint 1 : Responsable commercial
«Classer l’offre»
Description textuelle :
• Acteurs : Responsable commercial.
• Pré-condition : Utilisateur authentifié.
• 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»
Description textuelle :
• Acteurs : Responsable commercial.
• Pré-condition : Utilisateur authentifié
• 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
Chapitre 5. Sprint 1 : Responsable commercial
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
Chapitre 5. Sprint 1 : Responsable commercial
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
Chapitre 5. Sprint 1 : Responsable commercial
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»
Description textuelle :
• 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
Chapitre 5. Sprint 1 : Responsable commercial
FIGURE 5.5 – Diagramme de séquence «Valider une demande d’offre»
45
Chapitre 5. Sprint 1 : Responsable commercial
• 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»
Description textuelle :
• 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
Chapitre 5. Sprint 1 : Responsable commercial
• 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
Chapitre 5. Sprint 1 : Responsable commercial
Description textuelle :
• 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.
• Aprés l’enregistrement du fichier, la nouvelle liste des fichiers sera affichée.
«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»
Description textuelle :
• 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
Chapitre 5. Sprint 1 : Responsable commercial
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
Chapitre 5. Sprint 1 : Responsable commercial
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
Chapitre 5. Sprint 1 : Responsable commercial
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
Chapitre 5. Sprint 1 : Responsable commercial
FIGURE 5.12 – Interface de la décision du client
FIGURE 5.13 – Interface de l’envoie d’un e-mail au client
52
Chapitre 5. Sprint 1 : Responsable commercial
FIGURE 5.14 – Interface d’ajouter du plan de classement
FIGURE 5.15 – Interface de création du plan de classement
53
Chapitre 5. Sprint 1 : Responsable commercial
FIGURE 5.16 – Interface de la préparation de l’offre
FIGURE 5.17 – Interface de traitement du bon de commande
54
Chapitre 5. Sprint 1 : Responsable commercial
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.
6.1 Backlog du sprint
Le Tableau 6.1 définit le backlog du sprint 2 qui précise les tâches à réaliser.
6.2 Diagrammes des cas d’utilisations
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.
Description textuelle :
• Acteurs : Responsable technique.
• Pré-condition : Utilisateur authentifié.
• 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
Chapitre 6. Sprint 2 : Responsable technique
FIGURE 6.1 – Diagramme des cas d’utilisations du responsable technique
«Valider les offres techniques»
Description textuelle :
• Acteurs : Responsable technique.
• Pré-condition : Utilisateur authentifié
• Post-condition : Offre technique soit valide soit invalide.
58
Chapitre 6. Sprint 2 : Responsable technique
• 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»
Description textuelle :
• Acteurs : Responsable technique.
• Pré-condition : Utilisateur authentifié.
• 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»
Description textuelle :
• Acteurs : Responsable technique.
• Pré-condition : Utilisateur authentifié
• 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»
Description textuelle :
• Acteurs : Responsable technique.
• Pré-condition : Utilisateur authentifié
• 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
Chapitre 6. Sprint 2 : Responsable technique
6.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 classe 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 pour le responsable technique.
6.3.1 Diagramme de classes
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.
TABLEAU 6.2 – Descriptif des classes du sprint 2
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.
6.3.2 Diagrammes de séquences
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»
Description textuelle :
• 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.
• Aprés l’enregistrement du fichier, la nouvelle liste des fichiers sera affichée.
La Figure 6.3 montre le diagramme de séquence "Classer les offres techniques".
60
Chapitre 6. Sprint 2 : Responsable technique
FIGURE 6.2 – Diagramme de classes du responsable technique
61
Chapitre 6. Sprint 2 : Responsable technique
FIGURE 6.3 – Diagramme de séquence «Classer les offres techniques»
62
Chapitre 6. Sprint 2 : Responsable technique
«Valider les offres techniques»
Description textuelle :
• 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»
Description textuelle :
• 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
• 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 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
Chapitre 6. Sprint 2 : Responsable technique
FIGURE 6.4 – Diagramme de séquence «Valider les offres techniques»
64
Chapitre 6. Sprint 2 : Responsable technique
FIGURE 6.5 – Diagramme de séquence «Valider la réalisation»
65
Chapitre 6. Sprint 2 : Responsable technique
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.
Description textuelle :
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
Chapitre 6. Sprint 2 : Responsable technique
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
Chapitre 6. Sprint 2 : Responsable technique
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.
7.1 Backlog du sprint
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
7.2 Diagrammes des cas d’utilisations
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.
• Pré-condition : Utilisateur authentifié.
• 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.
• Pré-condition : Utilisateur authentifié.
• Post-condition : Réalisation préparé.
70
Chapitre 7. Sprint 3 : Agent technique
• 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
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 de l’agent technique.
7.3.1 Diagramme de classes
La Figure 7.2 présente le diagramme du classe de l’agent technique.
TABLEAU 7.2 – Descriptif des classes du sprint 3
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
Chapitre 7. Sprint 3 : Agent technique
FIGURE 7.2 – Diagramme de classes de l’agent technique
72
Chapitre 7. Sprint 3 : Agent technique
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»
Description textuelle :
• 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
Chapitre 7. Sprint 3 : Agent technique
• 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 enregistre la réalisation et un message de succès sera affiché
• Sinon un message d’alerte sera affiché.
«Préparer l’offre technique»
Description textuelle :
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
Chapitre 7. Sprint 3 : Agent technique
Description textuelle :
• 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.
• 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 enregistre l’offre technique et un message de succès sera affiché
• Sinon un message d’alerte 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
Chapitre 7. Sprint 3 : Agent technique
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.
8.1 Backlog du sprint
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
8.2 Diagrammes des cas d’utilisations
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.
• Pré-condition : Utilisateur authentifié.
• 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
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 classe 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 du responsable financier.
78
Chapitre 8. Sprint 4 : Responsable financier
8.3.1 Diagramme de classes
La Figure8.2 montre le diagramme du classe du responsable financier.
TABLEAU 8.2 – Descriptif des classes du sprint 3
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
Chapitre 8. Sprint 4 : Responsable financier
8.3.2 Diagrammes de séquences
«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»
Description textuelle :
• Le responsable financier demande l’affichage de l’interface de la préparation de la facture et
saisit les informations associés à une facture.
• L’interface vérifie la validité des données.
• Si les champs obligatoires sont invalides, une alerte indiqunt que les champs doivent être
80
Chapitre 8. Sprint 4 : Responsable financier
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 enregistre la facture et un message de succès sera affiché
• Sinon un message d’alerte 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
Chapitre 8. Sprint 4 : Responsable financier
Description textuelle :
• 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.
• Aprés l’enregistrement du fichier, la nouvelle liste des fichiers sera affichée.
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
Chapitre 8. Sprint 4 : Responsable financier
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
Chapitre 8. Sprint 4 : Responsable financier
FIGURE 8.7 – Diagramme de GANTT
84
Chapitre 8. Sprint 4 : Responsable financier
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
Top Related