MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA
RECHERCHE SCIENTIFIQUE
UNIVERSITE TUNIS EL MANAR
INSTITUT SUPERIEUR D’INFOR...
h é¡d¦i ™¡— ™¡e
t¡e  d é¡d¦i e  ™¡e ¦t§r —1E v¢—¦i£l À m —1
m è§r e x —£˜¨ih —1 „¦u1 m19 —©s  d onn é £l¡—1 v¨i eD £l¡—1 ¦...
Remerciement
Avant d’entamer ce rapport de projet de fin d’études, je tiens à exprimer ma sincère gratitude
envers tous ceu...
Table des matières
Introduction générale 1
1 Cadre général du projet 3
Introduction . . . . . . . . . . . . . . . . . . . ...
Table des matières
2.2.1 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2....
Table des matières
4.1.2 Architecture matérielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4....
Table des matières
6.2.1 Raffinement des cas d’utilisations du responsable technique . . . . . . . . . . . 56
6.3 Conceptio...
Table des matières
8.2.1 Raffinement des cas d’utilisations du responsable financier . . . . . . . . . . . . 77
8.3 Concepti...
Table des matières
Bibliographie ix
vi
Table des figures
1.1 L’organigramme de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1....
Table des figures
5.11 Interface de validation d’une demande d’offre . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1...
Table des figures
7.7 Interface de la prépartion des réalisations . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8....
Liste des tableaux
2.1 Comparatif entre les differents moteurs d’exécution existants. . . . . . . . . . . . . . . 16
3.1 B...
Liste des abréviations
UML Unified Modeling Language
IBM International Business Machines
BPMN Business Process Model and No...
Introduction générale
De nos jours, toute entreprise est prête à investir des sommes considérables dans l’implanta-
tion d...
Introduction générale
• Le reste des chapitres décrit la conception et la réalisation des sprints 1, 2, 3 et 4. Nous
comme...
1 Cadre général du projet
Introduction
Dans le présent chapitre, nous présentons la société PicoSoft pour laquelle ce trav...
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 Inte...
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 con...
Chapitre 1. Cadre général du projet
par tous les utilisateurs. Durant l’avancement du dossier de prestation les acteurs on...
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 ...
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él...
Chapitre 1. Cadre général du projet
maximum de ses capacités en éliminant les obstacles et en protégeant l’équipe des pert...
2 Etat de l’art
Introduction
Afin de mieux comprendre notre projet, nous avons dû étudier certaines notions primordiales
po...
Chapitre 2. Etat de l’art
FIGURE 2.1 – Définition du document
2.1.3 Gestion des documents
Les documents ont souvent vocatio...
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)...
Chapitre 2. Etat de l’art
• Workflow Administratif : Correspond à tout ce qui est routage de formulaires. Elle est basée
pr...
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 do...
Chapitre 2. Etat de l’art
• L’authentification de l’autorité des utilisateurs : Le moteur de Workflow doit vérifier si l’util...
Chapitre 2. Etat de l’art
TABLEAU 2.1 – Comparatif entre les differents moteurs d’exécution existants.
Produit Environemme...
3 Planification
Introduction
Ce chapitre est consacré à l’analyse et la spécification des besoins. Nous commençons par
l’ide...
Chapitre 3. Planification
Responsable technique :
C’est la personne qui affecte les travaux aux agents techniques selon leu...
Chapitre 3. Planification
• Classer l’offre technique.
• Classer les offres commerciales.
• Consulter les données résultant...
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 di...
Chapitre 3. Planification
FIGURE 3.3 – Diagramme du cas d’utilisation global de l’agent technique
FIGURE 3.4 – Diagramme du...
Chapitre 3. Planification
TABLEAU 3.1 – Backlog du produit
Type Reponsable User Story Priorité
Story
Technique
Administrate...
Chapitre 3. Planification
Conclusion
Nous avons présenté le backlog du produit en spécifiant les différents fonctionnalités ...
4 Sprint 0
Introduction
La mise en place de notre projet nécessite plusieurs connaissances en termes de technologies
et du...
Chapitre 4. Sprint 0
Diagramme de déploiement
Le diagramme de déploiement permet de représenter l’architecture physique su...
Chapitre 4. Sprint 0
FIGURE 4.2 – Le Design Pattern MVC
La vue
C’est une Interface Homme Machine (IHM) fournit la présenta...
Chapitre 4. Sprint 0
Le modèle
Représente l’état de l’application et définit les actions d’entreprises qui modifient (donnée...
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 des...
Chapitre 4. Sprint 0
1. Alfresco est Open Source
• Respecte les standards
• Evite d’être enfermé dans une technologie prop...
Chapitre 4. Sprint 0
4.2.2 Outil de conception
Enterprise Architect
Est un logiciel de modélisation et de conception UML, ...
Chapitre 4. Sprint 0
Conclusion
Ce chapitre a été consacré à la présentation de l’environnement logiciel et matériel dans ...
5 Sprint 1 : Responsable commercial
Introduction
Après avoir étudié les différentes technologies qui vont être utiliser da...
Chapitre 5. Sprint 1 : Responsable commercial
TABLEAU5.1–BacklogduSprint1
TypeUserStoryTaskEstimation
Story
Technique
Mise...
Chapitre 5. Sprint 1 : Responsable commercial
Créerletypedemodèledevalidationd’une
demanded’offresousalfrescowftest:
Valid...
Chapitre 5. Sprint 1 : Responsable commercial
Créerletypedemodèledetraitementdubonde
commandesousalfresco
wftest:Traiterle...
Chapitre 5. Sprint 1 : Responsable commercial
5.2.1 «Authentification»
Tout au long de ce travail, tous les utilisateurs da...
Chapitre 5. Sprint 1 : Responsable commercial
5.2.2 Raffinement des cas d’utilisations du responsable commercial
La Figure ...
Chapitre 5. Sprint 1 : Responsable commercial
«Valider une demande d’offre»
Description textuelle :
• Acteurs : Responsabl...
Chapitre 5. Sprint 1 : Responsable commercial
«Traiter le bon de commande»
Description textuelle :
• Acteurs : Responsable...
Chapitre 5. Sprint 1 : Responsable commercial
«Classer l’offre»
Description textuelle :
• Acteurs : Responsable commercial...
Chapitre 5. Sprint 1 : Responsable commercial
Nous nous sommes concentrés sur la définition des différentes classes nécessa...
Chapitre 5. Sprint 1 : Responsable commercial
TABLEAU 5.2 – Descriptif des classes du sprint 1
Classe Description
Document...
Chapitre 5. Sprint 1 : Responsable commercial
FIGURE 5.4 – Diagramme de séquence «Authentification»
«Valider une demande d’...
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...
Chapitre 5. Sprint 1 : Responsable commercial
• Le contrôleur accède à l’offre et sélectionne la liste des fichiers importé...
Chapitre 5. Sprint 1 : Responsable commercial
Description textuelle :
• Le responsable commercial demande l’affichage de l’...
Chapitre 5. Sprint 1 : Responsable commercial
FIGURE 5.8 – Diagramme de séquence du cas d’utilisation «Traiter le bon de c...
Chapitre 5. Sprint 1 : Responsable commercial
FIGURE 5.9 – Processus du responsable commercial
Description détaillée des t...
Chapitre 5. Sprint 1 : Responsable commercial
5.5 Réalisation
Dans cette partie, nous allons exposer quelques scénarios d’...
Chapitre 5. Sprint 1 : Responsable commercial
FIGURE 5.12 – Interface de la décision du client
FIGURE 5.13 – Interface de ...
Chapitre 5. Sprint 1 : Responsable commercial
FIGURE 5.14 – Interface d’ajouter du plan de classement
FIGURE 5.15 – Interf...
Chapitre 5. Sprint 1 : Responsable commercial
FIGURE 5.16 – Interface de la préparation de l’offre
FIGURE 5.17 – Interface...
Chapitre 5. Sprint 1 : Responsable commercial
FIGURE 5.18 – Interface de classement de la commande
Conclusion
Au cours de ...
6 Sprint 2 : Responsable technique
Introduction
Aprés la réalisation du sprint 1, nous attaquant maintenant le sprint 2. C...
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Conception et développement d'une application de gestion des dossiers d'affaire sous alfrescoo
Prochain SlideShare
Chargement dans…5
×

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

3 144 vues

Publié le

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

Publié dans : Technologie
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 144
Sur SlideShare
0
Issues des intégrations
0
Intégrations
11
Actions
Partages
0
Téléchargements
224
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

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

  1. 1. 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
  2. 2. h é¡d¦i ™¡— ™¡e t¡e  d é¡d¦i e  ™¡e ¦t§r —1E v¢—¦i£l À m —1 m è§r e x —£˜¨ih —1 „¦u1 m19 —©s  d onn é £l¡—1 v¨i eD £l¡—1 ¦t¡en d¦r es(©s( e  e§t £l¡e  ™¡o¨u¦r — g¡e ©p o¨u¦r1 ¦r é§u©s(©s(¦i¦r1F „ o¨u¦t  ™¡e  q(¦u e ©j¡e ©p e§ux ¦t9 o¥f¤f§r¦i¦r1 n e ©p o¨u¦r¦r —1  exp¦r¦im e§r1 £l —m o¨u¦r1  e§t £l¡—1 ¦r e¡™¡onn —¦i©s(©s( —n ™¡e  q(¦u e ©j¡e ¦t¡e ©p o¨r¦t¡eF i n1 ¦t¡ém o¨i gn — g¡eD ©j¡e ¦t9 o¥f¤f§r e  ™¡e m o¢d es(¦t¡e ¦t§r —v¢—¦i£l ©p o¨u¦r1 ¦t¡e ¦r em e§r ™§i e§r1 ©p o¨u¦r1 ¦t¡es ©s( — ™§r¦i£f§i ™¡es  e§t ©p o¨u¦r1 £l —£f¤f¡e¡™§t§i on1  d on¦t ¦t§u1 m19 —©s ¦t¡o¨u©j¡o¨u¦r©s  en¦t¡o¨u¦r éF À m on1 ©p è§r e p — dh e¤l v9 ép —¦u£l¡e ©s( o¥l§i d eD £l o)e§i£l  —¦t§t¡en¦t§i£f  ™¡om©p¦r éh en1E ©s(¦i£f  e§t £l¡—1 ©p e§r©s( onn e £l¡—1 ©p£l§u©s  d¦i gn e  d e m on1  es(¦t§im e  e§t  d e m on1 ¦r es(©p e¡™§tF e¦u ™§un e  d é¡d¦i ™¡— ™¡e n e ©p o¨u¦r¦r —¦i¦t  exp¦r¦im e§r1 m es ©s( en¦t§im en¦tsD  q(¦u e h¦i e§u1 ¦t¡e ©p¦r és( e§rv)e  e§t ¦t¡e ©p¦r o¢™§u¦r e ƒ —n¦t¡é  e§t £l¡on g§u e v¨i eF À m —1 ¦t§r ès  ™h è§r e £f¡—m¦i£l¤l¡e  q(¦u¦i1 m e ©s( o¨u¦t§i en¦tD m19 en ™¡o¨u¦r — g¡e  e§t m19 o¥f¤f§r e ¦t¡o¨u©j¡o¨u¦r©s ¦un1 m¦i£l§i e§u1 £f¡—v¢o¨r —£˜¥l¡eD ¦un e  —m£˜¨i —n ™¡e ©j¡oy¡e§u©s( e  e§t ¦un e  —¦tm os(©ph è§r e ©j¡ov¨i —£l¡eF À m on1 £f§r è§r e ‡ —©s(©s(¦im1 € o¨u¦r1 ©s( —1  ™¡om©p¦r éh en©s(¦i on1D ©s( on1 ©s( o¨u¦t§i en1D ©s( on1 ¦t¡en d¦r es(©s( e F F F¦u19¦i£l ¦t§r o¨uv)e ¦i ™§i1 £l exp¦r es(©s(¦i on1  d e m —1 ¦r e¡™¡onn —¦i©s(©s( —n ™¡eF À w es  ™h e§r©s e m¦i©s hh o¨uh —1D e¦z§i¦z  e§t w —©j¡d¦i1D ©j¡e v¢o¨u©s  d é¡d¦i e  ™¡e ¦t§r —v¢—¦i£l  en1 ¦t¡ém o¨i gn — g¡e  d e £l —m¦i¦t§i é ©s(¦in1E  ™¡è§r e  q(¦u¦i1 n o¨u©s £l§i e  e§t  d es £˜¢on©s m om en¦ts ©p —©s(©s( és  en©s( em£˜¥l¡e  e§t  à1  q(¦u¦i1 ©j¡e ©s( o¨uh —¦i¦t¡e ¦un1  —v)en¦i¦r1 ¦r — d¦i e§ux  e§t ©p£l¡e§in1  d e £˜¢onn es ©p¦r om es(©s( esF À ¦t¡o¨u¦t¡es £l¡es ©p e§r©s( onn es  q(¦u¦i1 m19 on¦t  —¦i d é  à1 ¦r é¡—£l§i©s( e§r1  ™¡e ¦t§r —v¢—¦i£lD ©j¡e ©p¦r és( en¦t¡e m es v¨i£fs ¦r em e§r ™§i eE m en¦ts  e§t £l¡es  exp¦r es(©s(¦i on©s ¦r es(©p e¡™E ¦t§u e§u©s( es  d e m —1 ©p¦r o¥f¡on d e  g§r —¦t§i¦t§u d eF ♥ ‚ —nn o¨u ™h1
  3. 3. 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.
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. Table des matières Bibliographie ix vi
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. Liste des abréviations UML 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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 les développeurs, les universités et les consultants 12
  27. 27. 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
  28. 28. 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
  29. 29. 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
  30. 30. Chapitre 2. Etat de l’art TABLEAU 2.1 – Comparatif entre les differents moteurs d’exécution existants. Produit Environemment Langage Licence Orientation Activiti Java BPMN2 Apache v2 Développement Bonita Java EE / Jonas XPDL LGPDL v2 Utilisation Intalio Web Services WS-BPEL Communauté / 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
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. Chapitre 3. Planification FIGURE 3.1 – Diagramme du cas d’utilisation global du responsable commercial 20
  35. 35. 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
  36. 36. 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
  37. 37. Chapitre 3. Planification TABLEAU 3.1 – Backlog du produit Type Reponsable User Story Priorité Story Technique Administrateur Mise en place de la plateforme Elevée Modélisation du workflow Elevée Intégration du workflow sous alfresco Elevée Mise en place du client PicoSoft avec alfresco Elevée Création des groupes correspondants à chaque profil Elevée Story Utilisateur Responsable commercial En tant que responsable commercial je souhaite valider une demande d’offre Elevée En tant que responsable commercial je souhaite affecter la demande aux responsables techniques Moyenne En tant que responsable commercial je souhaite valider les offres commercaux Moyenne En tant que responsable commercial je souhaite préparer l’offre Moyenne En tant que responsable commercial je souhaite traiter le bon de commande Moyenne En tant que responsable commercial je souhaite consulter le dossier d’affaire «Dossier de prestation» Moyenne En tant que responsable commercial je souhaite uploader la commande Moyenne Responsable technique En tant que responsable technique je veux affecter les revues du contrat aux équipes techniques pour préaparer les offres techniques en calculant les estimations Elevée En tant que responsable technique je veux valider les offres techniques Elevée En tant que responsable technique je veux affecter les travaux mentionnées dans le bon de commande Moyenne En tant que responsable technique je veux valider les revues techniques(offres techniques) Moyenne En tant que responsable technique je veux valider la réalisation Elevée Agent technique En tant que agent technique je veux préparer une offre technique Moyenne En tant que agent technique je veux préparer la réalisation Moyenne Responsable financier En tant que responsable financier je veux préparer une facture. Moyenne En tant que responsable financier je veux classer la facture. Moyenne 23
  38. 38. 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
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. 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
  43. 43. 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
  44. 44. 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
  45. 45. 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
  46. 46. 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
  47. 47. 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
  48. 48. Chapitre 5. Sprint 1 : Responsable commercial TABLEAU5.1–BacklogduSprint1 TypeUserStoryTaskEstimation Story Technique Miseenplacedelaplateforme InstallationdelaplateformeAlfresco6heures InstallationduBecPG 2heures Testerlebonfonctionnementdelaplateforme 2heures Modélisationduworkflow Créationdesprofilsdesresponsables 8heures Modélisationdestâchesàchaqueprofil4heures Gestiondestransitionsentrelestâches16heures Gestiondescircuitsdevalidation12heures Gestiondesdonnéesmétiers12heures Intégrationduworkflowsousalfresco Déploiement8heures Testerl’enchaînementdescircuits4heures Intégrationdel’environnementPicoSoft avecalfreco Configurerl’environnementPicoSoft(Exemple: Connexionàlabasededonnées...) 8heures CréationdelaclasseTaskDetailProcess.javapour invokerleswebscript 8heures Créationdesgroupescorrespondantsà chaqueprofil Ajoutdesmembres 5heures Affectationdesprivilèges 3heures Entantqueresponsablecommercial, jesouhaitevaliderunedemanded’offre Créeruneinterfacedevalidationd’une demanded’offreValidateDemandPico.jsp 4heures Créeruneservletdevalidationd’une demanded’offreValidateDemand.java 8heures Testerlebonfonctionnementdel’interface 3.5heure 34
  49. 49. Chapitre 5. Sprint 1 : Responsable commercial Créerletypedemodèledevalidationd’une demanded’offresousalfrescowftest: Validerunedemanded’offre 4heure Entantqueresponsablecommercial, jesouhaiteaffecterlademandeaux responsablestechniques Créeruneinterfaced’affectationd’une demanded’offreAffecteDemandPico.jsp 4heures Créeruneservletd’affectation d’unedemanded’offreAffecteDemand.java 9heures Testerlebonfonctionnementdel’interface3heures Créerletypedemodèled’affectation d’unedemanded’offresousalfresco wftest:Affecterlademande 3,5heure Story Utilisateur Entantqueresponsablecommercial, jesouhaitevaliderlesoffrescommerciaux Créeruneinterfacedevalidationlesoffres commerciauxValidateOffrePico.jsp 3heures Créeruneservletdevalidation lesoffrescommerciauxValidateOffrecomm.java 5heures Testerlebonfonctionnementdel’interface0,5heure Créerletypedemodèledevalidation lesoffrescommerciauxsousalfresco wftest:Validerlesoffrescommerciaux 3,5heure Entantqueresponsablecommercial, jesouhaitepréparerl’offre Créeruneinterfacedepréparationdel’offre PrepareOffrePico.jsp 3heures Créeruneservletdepréparationde l’offrePrepareOffre.java 5heures Testerlebonfonctionnementdel’interface1,5heure Créerletypedemodèledepréparationde l’offresousalfresco wftest:Préparerl’offre 0,5heure Entantqueresponsablecommercial, jesouhaitetraiterlebondecommande Créeruneinterfacedetraitementdubon decommandeTraiteOrderPico.jsp 3heures Créeruneservletdetraitementdubonde commande,TraiteOrderOffre.java 8heures Testerlebonfonctionnementdel’interface1,5heure 35
  50. 50. Chapitre 5. Sprint 1 : Responsable commercial Créerletypedemodèledetraitementdubonde commandesousalfresco wftest:Traiterlebondecommande 3,5heure Entantqueresponsablecommercial, jesouhaiteconsulterledossierd’affaire «Dossierdeprestation» Créeruneinterfacedeconsultationdu dossierd’affaireConsultDirPico.jsp 3heures Créeruneservletdeconsultationdu dossierd’affaireConsultDirOffre.java 8heures Testerlebonfonctionnementdel’interface1,5heure Entantqueresponsablecommercial, jesouhaitetransmettrelacommande Créeruneinterfacepourtransmettrela commandeUploadOrderPico.jsp 3heures Créeruneservletpourtransmettrela commandeUploadOrder.java 8heures Testerlebonfonctionnementdel’interface1,5heure 36
  51. 51. 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
  52. 52. 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
  53. 53. 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
  54. 54. 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
  55. 55. 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
  56. 56. 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
  57. 57. Chapitre 5. Sprint 1 : Responsable commercial TABLEAU 5.2 – Descriptif des classes du sprint 1 Classe Description Document C’est l’ensemble des documents ajoutés et traités en cours du processus de prestation. Affaire C’est la racine d’une arborescence des dossiers crées au moment de la validation d’une demande d’offre. Chaque demande d’offre validée par le responsable commercial est une affaire. Offre C’est un dossier ajouté au moment de la création d’une affaire il peut contenir un ensemble des documents. Commande C’est un dossier ajouté au moment de la création d’une affaire, il peut contenir un ensemble des documents relative à une commande. Revue commer- cial C’est un dossier ajouté au moment de la création d’une affaire, il peut contenir un ensemble des documents relatives au revue commercial. Responsable commer- 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. Revue C’est un dossier qui peut contenir la liste des revues commerciaux et les revues techniques, il est 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
  58. 58. 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
  59. 59. Chapitre 5. Sprint 1 : Responsable commercial FIGURE 5.5 – Diagramme de séquence «Valider une demande d’offre» 45
  60. 60. 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
  61. 61. 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
  62. 62. 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
  63. 63. 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
  64. 64. 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
  65. 65. 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
  66. 66. 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
  67. 67. 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
  68. 68. 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
  69. 69. 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
  70. 70. 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

×