Rapport Final

Ddicaces A
mes parents : Qui nont jamais cess de maider, massister et mencourager,
ceux qui ont sacri leurs plus belles annes pour embellir les miennes, je vous dois ma russite, aucun mot ne serait assez pour tmoigner de ltendue des sentiments que jprouve leur gard,
A ma sur et mes frres : Qui mont pargn le moindre eort pour me soutenir
tout au long de mon cursus dtudes,
A ma ance que jaime, A tous ceux qui mont soutenu et taient prsents pour moi, A tous ceux qui veulent partager ma joie,
Je vous ddie ce travail, le fruit de mes eorts et de longues annes dtudes, Que vous y trouvez le couronnement de votre assistance et lexpression profonde de ma gratitude. Ahmed
Remerciements
Ce projet de n dtudes a t ralis au sein de la socit SunGard. Nous tenons exprimer toute notre reconnaissance SunGard pour nous avoir permis de mener bien ce travail. Nous exprimons notre reconnaissance et notre gratitude lgard de notre encadreur Madame Mouna Makni, professeure Esprit, pour nous avoir permis de bncier de son grand savoir en la matire, pour sa pdagogie, ses comptences et son aide prcieuse tout au long de ce projet. Notre sincre reconnaissance mon encadreur Monsieur Foued El Guembri et Mademoiselle Hager El Mahjoub notre Team Leader de lquipe SCS (Sungard Consulting Services), de nous avoir form et davoir suivi rgulirement lvolution de ce travail.Cest grce leurs conseils judicieux et leur aide constante que nous avons pu mener ce projet terme. Nous remercions galement Mademoiselle Sana Lahouiel de lquipe SCS pour son soutien continu tout au long de notre stage. Finalement, nous ne laisserons pas cette occasion passer sans exprimer notre reconnaissance envers lquipe Front Arena pour leur hospitalit et leurs encouragements, et envers nos professeurs Esprit pour la qualit de la formation quils nous ont assure.
ii
Table des matires

Introduction gnrale 1 Prsentation gnrale 1.1 1.2 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prsentation de lentreprise daccueil . . . . . . . . . . . . . . . . . . . . . 1.2.1 1.2.2 1.3 1.4 1.5 Prsentation de SUNGARD . . . . . . . . . . . . . . . . . . . . . . Prsentation de SCS (Sungard Consulting Services) . . . . . . . . . 1 3 3 4 4 4 4 5 6 6 7 8 10 10 10 11 13 13 13 14 15 15 16 16
Problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prsentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mthodologie de conception . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 1.5.2 1.5.3 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . eXtreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . Mthodologie de SCS . . . . . . . . . . . . . . . . . . . . . . . . . .
2 tude pralable 2.1 Concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.1.3 2.2 2.2.1 2.2.2 Le consulting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La gestion des consultants . . . . . . . . . . . . . . . . . . . . . . . Apports de la gestion de consultants . . . . . . . . . . . . . . . . . Description du systme existant . . . . . . . . . . . . . . . . . . . . Limites et solutions proposes . . . . . . . . . . . . . . . . . . . . .
tude de lexistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Analyse et spcication des besoins 3.1 3.2 Identication des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . Spcication fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Cas dutilisation gnral . . . . . . . . . . . . . . . . . . . . . . . .
iii
iv 3.2.2 3.2.3 3.2.4 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6 3.3.7 Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sprint 2 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sprint 3 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internationalisation . . . . . . . . . . . . . . . . . . . . . . . . . . Contraintes dutilisation . . . . . . . . . . . . . . . . . . . . . . . . Contraintes dergonomie . . . . . . . . . . . . . . . . . . . . . . . . Contraintes de performance . . . . . . . . . . . . . . . . . . . . . . Contraintes techniques . . . . . . . . . . . . . . . . . . . . . . . . . Contraintes de maintenance . . . . . . . . . . . . . . . . . . . . . . 17 21 24 25 25 26 26 26 26 26 26 28 28 30 33 34 35 35 38 39 39 39 41 42 42 42 44 45 46 46 47 48 48
Spcication non fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . .
4 Conception 4.1 4.2 4.3 4.4 4.5 Conception prliminaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture de lapplication . . . . . . . . . . . . . . . . . . . . . . . . . . Diagramme de composants . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagramme de dploiement . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.1 4.5.2 4.5.3 Diagramme de squence . . . . . . . . . . . . . . . . . . . . . . . . Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . Diagramme dactivit . . . . . . . . . . . . . . . . . . . . . . . . . . Diagramme de squence . . . . . . . . . . . . . . . . . . . . . . . . Diagrammes de classes . . . . . . . . . . . . . . . . . . . . . . . . . Diagramme dactivit . . . . . . . . . . . . . . . . . . . . . . . . . . Diagramme de squence . . . . . . . . . . . . . . . . . . . . . . . . Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . Diagramme dactivit . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6
Sprint 2 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.1 4.6.2 4.6.3
4.7
Sprint 3 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.1 4.7.2 4.7.3
5 Ralisation 5.1 Framework JEE et technologies utilises . . . . . . . . . . . . . . . . . . . 5.1.1 5.1.2 5.1.3 Spring 2.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . JPA (Java Persistence API) . . . . . . . . . . . . . . . . . . . . . . JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 5.3 5.4 5.5
5.1.4 GWT (Google Web Toolkit) . . . . . . . . . . . 5.1.5 Maven 2.0 . . . . . . . . . . . . . . . . . . . . . 5.1.6 BIRT Business Intelligence and Reporting Tool 5.1.7 Logiciel de gestion de version . . . . . . . . . . 5.1.8 Hudson . . . . . . . . . . . . . . . . . . . . . . 5.1.9 JIRA . . . . . . . . . . . . . . . . . . . . . . . . Les design patterns utiliss . . . . . . . . . . . . . . . . Environnement de dveloppement . . . . . . . . . . . . Interfaces Homme Machine . . . . . . . . . . . . . . . . Chronogramme . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
48 49 50 50 51 53 56 58 59 65 66 68 71 72 73
Conclusion gnrale Glossaire Netographie Bibliographie Annexe
Table des gures

1.5.1 Utilit des mthodologies agiles . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 Mthodologie Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.3 eXtreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Mthodologie SunGard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Cas dutilisation gnral . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Cas dutilisation relatif au 1er sprint . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Cas dutilisation relatif au 2me sprint . . . . . . . . . . . . . . . . . . . . . 3.2.4 Cas dutilisation relatif au 3
me
6 7 8 12 16 20 23 24 29 29 30 31 33 34 35 36 37 38 39 40 41 42 43 44
sprint . . . . . . . . . . . . . . . . . . . . .
4.1.1 Panel Consultant-vnement . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Panel de cration/dition vnement et action . . . . . . . . . . . . . . . . 4.1.3 Panel historique des contrats dun consultant . . . . . . . . . . . . . . . . . 4.2.1 Architecture n-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Diagramme de composants . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Dpendances du projet FollowUp . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Diagramme de dploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Scnario cration du liste panel consultant-vnement . . . . . . . . . . 4.5.2 Scnario cration dun vnement . . . . . . . . . . . . . . . . . . . . . 4.5.3 Diagramme de classe sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.4 Diagramme dactivit Ajout dvnement avec action . . . . . . . . . . . 4.6.1 Scnario achage de lhistorique de contrats dun consultant . . . . . . 4.6.2 Diagramme de classe sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.3 Diagramme dactivit Activit Exporter Panel consultant . . . . . . . . . 4.7.1 Scnario ajout dun directeur de dpartement . . . . . . . . . . . . . . 4.7.2 Diagramme de classe sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . .
vi
vii
4.7.3 Diagramme dactivit Activit edition dun directeur dactivit . . . . . . 5.1.1 Spring MVC dans la couche prsentation . . . . . . . . . . . . . 5.1.2 Structure dun projet Maven . . . . . . . . . . . . . . . . . . . . 5.1.3 Les phases du cycle de vie dun projet maven . . . . . . . . . . . 5.1.4 Suivi de la stabilit du projet avec Hudson . . . . . . . . . . . . 5.1.5 Workow JIRA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.6 Dashboards JIRA . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.7 Tche 1- 1er Sprint : Panel consultant . . . . . . . . . . . . . . 5.1.8 BurnDown Chart du 3eme Sprint . . . . . . . . . . . . . . . . . 5.4.1 Portail cabestan . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.2 Interface du panel Consultant - vnement . . . . . . . . . . . . 5.4.3 Exemple dextract Excel . . . . . . . . . . . . . . . . . . . . . . 5.4.4 Interface de cration dun vnement . . . . . . . . . . . . . . . 5.4.5 Interface dajout daction . . . . . . . . . . . . . . . . . . . . . . 5.4.6 Interface de modication des informations des consultants . . . 5.4.7 Graphique de la variation des tarifs des contrats dun consultant 5.5.1 Chronogramme du projet FollowUp . . . . . . . . . . . . . . . . 5.5.2 Etirations de la mthodologie Scrum . . . . . . . . . . . . . . . 5.5.3 Burn-down chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45 47 49 50 52 53 54 55 56 59 60 60 61 62 63 64 65 76 77
Liste des tableaux

3.2 3.4 3.6 3.8 3.10 3.12 3.14 3.16 3.18 User Story 1 UserStory 2 UserStory 3 UserStory 4 UserStory 5 UserStory 6 UserStory 7 UserStory 8 UserStory 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 18 19 19 21 21 22 22 24
viii
Introduction gnrale
Dans une conomie qui se mondialise, o la concurrence saccrot, les organisations cherchent orir davantage de service leurs clients. Lamlioration de lecacit et de lecience est devenue incontestablement la proccupation permanente des dirigeants. En eet, linformation est devenue un patrimoine stratgique et essentiel qui joue un rle fondamental dans le processus de dcision. Face la croissance des connaissances et la rduction de lincertitude, cest le systme dinformation (SI) qui permet lentreprise de rpondre aux besoins concurrentiels du march. Grce toutes ses composantes et ses liaisons avec les autres moyens oprationnels, le SI permet de fournir des biens et des services personnaliss une clientle avertie et exigeante dans les dlais spcis et des cots raisonnables. Quel que soit son secteur dactivit, les entreprises sont amene mettre en uvre un ensemble de moyens pour garantir en permanence lentreprise une adquation entre ses ressources et ses besoins en personnel, tant sur le plan quantitatif que qualitatif. Dailleurs, la gestion des consultants est depuis quelques annes, lun des principaux chantiers des socits de service. Se passer de nos jours dun outil de visualisation et de suivi savre pnalisant pour la comptitivit de lentreprise. La gestion des consultants est ainsi utile tous les niveaux daction des socits de service. Cest dans ce cadre que se situe notre projet de n dtudes, eectu au sein de la socit SunGard Consultings Services (SCS), lire de la multinationale SUNGARD. La thmatique principale de ce projet sarticule autour de la conception et du dveloppement dune application informatique de gestion des consultants de SUNGARD avec le Framework Spring et les technologies JEE. Cette application, ralise pour le compte de SCS, permettra dinformatiser le processus relatif la gestion des consultants, ainsi que la gestion de leurs
Introduction gnrale
vnements et actions. Le rapport est organis comme suit : Le premier chapitre sera consacr la prsentation du cadre, de la problmatique et des objectifs du projet. Le deuxime chapitre introduira les dirents concepts de base du sujet. Le troisime chapitre prsentera la description dtaille des besoins recenss et des fonctionnalits que lapplication doit satisfaire ainsi que les diagrammes des cas dutilisation. Le quatrime chapitre sera consacr la modlisation conceptuelle. Le cinquime chapitre dcrira laspect technique du projet aboutissant au dveloppement de lapplication, les technologies utilises et quelques vues des interfaces graphiques ralises.
Chapitre 1 Prsentation gnrale

Introduction
Nous prsentons dans ce chapitre une tude prliminaire du projet. Dans un premier temps, nous prsentons lenvironnement du stage. Par la suite, nous dcrivons la problmatique, ainsi que les principaux objectifs du projet. En dernier lieu, nous allons prsenter la mthodologie Agile adopte par lquipe SCS pour le dveloppement des projets.
1.1
Contexte du projet
Dans le cadre de la formation dingnieurs informaticiens lcole Suprieure Prive dingnierie et de Technologies de Tunis (ESPRIT), nous avons eu loccasion deectuer notre projet de n dtudes au sein de Sungard Consulting Services (SCS), une liale de la multinationale SUNGARD. Il vient complter notre formation universitaire acquise au sein de cet tablissement. En eet, il sagit dessayer de nous introduire dans la vie professionnelle grce une mise en pratique de nos connaissances et lutilisation de logiciels de dveloppement en informatique. Ce projet vise lobtention du diplme dingnieur en Informatique. Le sujet de notre projet porte sur la gestion des consultants.
Prsentation gnrale
1.2
1.2.1
Prsentation de lentreprise daccueil

Prsentation de SUNGARD
Avec des revenus annuels de prs de 5 milliards de dollars, SUNGARD est lun des leaders mondiaux de solutions informatiques intgres pour les institutions nancires, le secteur ducatif et le secteur public. Base Wayne, Pennsylvanie, elle a t cre en 1983, en tant que drive de la division des services informatiques de Sun Oil Company. SunGard permet aux entreprises manipulant un important volume de donnes dassurer la continuit de leurs activits. En eet elle rpond aux besoins de 25,000 clients dans plus de 70 pays et se palce comme troisime fournisseur de logiciel dapplications daaire (gestion) aprs oracle et SAP. Actuellement, elle a plus que 20000 employs dans plus de 200 villes et 30 pays. SunGard comporte quatre direntes activits : service de disponibilit, enseignement suprieur, secteur public et systmes nanciers. SunGard Global Services SGSest lun des acteurs majeurs et incontournables du service et du conseil, en France, dans les secteurs de la nance de march, la banque et lassurance. Il allie un savoir-faire technique et mtier : intgration de logiciel, matrise douvrage, conception et dveloppement, management de projet, avec des interventions en assistance technique, au forfait, en centre de services, en tierce maintenance applicative et en tierce recette applicative. Lun des segments de SunGard Global Services lquipe SCS.
1.2.2
Prsentation de SCS (Sungard Consulting Services)
Sungard Consulting Services, liale du groupe SUNGARD et anciennement connu sous le nom de SUNGARD CADEXTAN, est actuellement leader parmi les socits de service et de conseil. Depuis lacquisition dARMONYS et rcemment de GTI, SCS comporte plus de 500 personnes spcialises dans la nance. tant lun des principaux segments de SUNGARD, les activits de SCS reposent sur la double comptence, informatique et nance.
1.3
Problmatique
Actuellement, il y a 5 directeurs responsables sur plus de 500 consultants, ainsi avec la grande quantit de recrutement, ces derniers narrivent plus suivre tous les consultants. Le suivi se fait actuellement via des mails et des chiers Excel. Etant donn ce nest pas le meilleur moyen puisquil y a une perte de temps considrable, lun des premiers avantages
Prsentation gnrale
de lapplication quils nous a t demand de concevoir, intitul FollowUp est de dgager du temps pour les directeurs et de faciliter le suivi des consultants, car ils ont aussi des responsabilits autre que la gestion des suivi des consultants, savoir la gestion des projets.
1.4
Prsentation du projet
Le projet consiste concevoir et raliser une application Web de gestion des consultants de SCS sous larchitecture JEE. Il comporte les principales parties suivantes :
Retrouver les prols des consultants qui satisfont un ensemble de critres (nom du consultant, directeur dactivit , dpartement , etc.) . Lister et mettre jour les vnements. Lister et mettre jour les actions des vnements . Lister lhistorique des contrats associs aux consultants. Grer les directeurs de dpartement. Gnrer des reports des listes de consultants selon les citres de recherche (sous forme de graphe ou excel). Envoyer des notications pralablement programmes.
Le module FollowUp a pour objectif de faciliter le suivi des consultants de SCS, de leurs vnements et actions. Do la ncessit davoir une vue densemble des consultants, de leur disponibilit et des contracts qui leurs sont aects. Ce qui permettra la rduction des dlais dattente des directeurs.
Lobjectif, certes, est de concevoir et mettre en uvre une plate-forme permettant de simplier et dacclrer ces procdures : Accessibilit en mode WEB aux clients de FollowUp. Gestion et maintenance de toutes les donnes. Solution ouverte (interfaage applicatif des dirents mtiers). Gnration automatique des rapports. Notication des crateurs des vnements par mail.
Integration dans le portail dja existant.
Prsentation gnrale
1.5
Mthodologie de conception
Les mthodes Agile sont des mthodes de dveloppement de projets informatiques qui visent rduire le cycle de vie du logiciel (donc acclrer son dveloppement) en dveloppant une version minimale, puis en intgrant les fonctionnalits par un processus itratif bas sur une coute client et des tests tout au long du cycle de dveloppement. Lorigine des mthodes Agile est li linstabilit de lenvironnement technologique et au fait que le client est souvent dans lincapacit de dnir ses besoins de manire exhaustive ds le dbut du projet. Dans la suite, nous prsentons Scrum et XP pour aboutir la mthodologie adopte par SCS. En eet, sans une mthodologie bien tudi et adapt aux besoins de lquipe de dveloppement et rpondant aux exigences du client, la ralisation dun projet peut avoir des consquences dsastreuses et tragiques. La gure 1.5.1 explique lutilit de ces mthodes.
Figure 1.5.1 Utilit des mthodologies agiles
1.5.1
Scrum
La mthodologie Scrum a t conue pour amliorer grandement la productivit dans les quipes auparavant paralyses par des mthodologies plus lourdes. Le principe de base de Scrum est de focaliser lquipe de faon itrative sur un ensemble de fonctionnalits
Prsentation gnrale
raliser, dans des itrations de dure xe de une quatre semaines, appeles sprints. Chaque sprint possde un but atteindre, dni par le directeur de produit, partir duquel sont choisies les fonctionnalits implmenter dans ce sprint. Un sprint aboutit toujours sur la livraison dun produit partiel fonctionnel. Pendant ce temps, le Scrum Master a la charge de rduire au maximum les perturbations extrieures et de rsoudre les problmes non techniques de lquipe. Ce processus est illustr par la gure 1.5.2
Figure 1.5.2 Mthodologie Scrum
1.5.2
eXtreme Programming
eXtreme Programming [1] est lune des mthodes Agile les plus utilises de nos jours. Elle pousse lextrme des principes simples (gure 1.5.3). Lexploration : dterminer les scnarios clients qui seront fournis pendant une itration. Lquipe transforme les scnarios en tches raliser et en tests fonctionnels. Les quipes de dveloppement travaillent directement avec le client sur des cycles itratifs trs courts dune deux semaines maximum. Les livraisons de versions du logiciel interviennent trs tt et une frquence leve pour maximiser limpact des retours utilisateurs. Lintgration continue : lorsquune tche est termine, les modications sont immdiatement intgres dans le produit complet. On vite ainsi la surcharge de travail
Prsentation gnrale
lie lintgration de tous les lments avant la livraison. Le code est test et nettoy tout au long du processus de dveloppement.
Figure 1.5.3 eXtreme Programming
1.5.3
Mthodologie de SCS
La mthodologie Scrum combine avec XP est adapte aux quipes rduites avec des besoins changeants comme celle dans laquelle nous avons eectu notre stage. Le choix de ces mthodes est due aux dirents avantages quelle apporte : Scrum La capacit dadaptation aux changements de contexte et aux modications de spcications intervenant pendant le processus de dveloppement, do la rduction des cots de changement La livraison frquente et aux dlais des logiciels XP Le client jouit dune trs grande visibilit sur lavancement du dveloppement Le client utilise le logiciel lui-mme comme support de rexion pour le choix des fonctionnalits implmenter. Il peut en particulier intgrer trs tt les retours des utilisateurs pour orienter le dveloppement en consquence La premire mise en production du logiciel intervient trs tt dans le projet, ce qui avance dautant le moment partir duquel le client peut en tirer des bnces
Prsentation gnrale
Lordre dimplmentation des fonctionnalits nest pas guid par des contraintes techniques, mais par les demandes du client. Celui-ci peut donc focaliser les eorts de lquipe sur les fonctionnalits les plus importantes ds le dbut du projet, et ainsi optimiser lutilisation de son budget.
Conclusion
Dans ce premier chapitre, nous avons prsent le statut sur lequel est organis SUNGARD, les services quelle ore et ces principales activits. Par la suite nous nous sommes focaliss sur la prsentation du projet, de notre problmatique et des objectifs viss. La dernire partie de ce chapitre a t consacre la prsentation de la mthodologie de travail suivie par SCS. Une tude des dirents concepts de notre travail et du systme existant nous mne une meilleure comprhension des concepts de consulting et de la bonne gestion des consultants.
Chapitre 2 tude pralable

Introduction
Dans cette section, nous identions les concepts cls du projet Gestion des consultants, des vnements et de leurs actions. Ltude de ces derniers nous permet de dresser un bilan de la solution existante ainsi que ses limites. Par la suite, nous prsentons notre solution pour remdier aux manques relevs dans lexistant.
2.1
2.1.1
Concepts de base
Le consulting
Les entreprises sont exposes de nombreux risques qui peuvent mettre en pril leurs activits voire menacer leur prennit. Ces risques peuvent tre parfois jugs rares ou identis comme plus probables. Si grer la continuit dactivit au sein de son entreprise est une ncessit rpondant aux enjeux majeurs que sont la survie de lentreprise lors dune crise grave ou encore la conformit aux obligations lgales et rglementaires, elle permet galement daborder ses activits sous un prisme dirent. Et ainsi, elle cre de la valeur tous les niveaux du cycle de vie des processus de production internes. En lintgrant dans les organisations, elle permet de : Renforcer la cohsion densemble en crant un nouvel axe fdrateur Matriser collectivement les activits et les processus de gestion Faire de la rsilience un sujet trait en amont pour accrotre lecacit et viter les
10
Etude pralable
11
surcots des adaptations ultrieures. La direction conseil de SunGard intervient exclusivement sur lensemble des problmatiques de la continuit dactivit. Les consultants de SunGard accompagnent les entreprises et les aident construire les solutions adaptes leur contexte (secteur, rglementation) et leurs besoins. Ils interviennent au sein des directions mtiers pour analyser lexistant, proposer et mettre en place les plans de continuit et les processus de gestion. Les consultants, architectes et chefs de projet apportent leur valeur ajoute auprs des directions informatiques pour btir les architectures adaptes, construire les plans projet et mener les travaux de mise en uvre.[2]
2.1.2
La gestion des consultants
La gestion des consultants est une mthode, un outil qui vise optimiser le suivi des consultants dune entreprise en orant aux directeurs de dpartements une meilleure vision possible sur le prol des consultants, leur disponibilit et la suivi de leurs vnements et actions, laccs rapide leurs informations et le report des donnes dsires an de permettre le bon fonctionnement et lvolution de lentreprise par rapport aux ressources disponibles . Ces derniers jours, lun des principaux chantiers des managers ainsi que des directeurs de dpartements est la gestion des consultants compte tenu de limportance de leurs nombre qui ne cesse daugmenter et de la non abilit de loutil disponible pour suivre leurs activit (encombrement de chiers Excel et perte importante de temps). Compte tenu de limportance dun tel aspect dans loptimisation de la comptitivit et de la qualit de service dune entreprise, do la ncessit de se procurer un outil de visualisation et danalyse permettant de grer tous les consultants. Parmi les principaux ds auxquels une entreprise peut se heurter est dacqurir, des consultants de haute qualit an de fournir des prestations de services convenables et comptitifs par rapport ce qui se fait dans leur secteur de march. Les profondes mutations du monde conomique et informatique, la constante volution et limprvisibilit de ce dernier, autant de facteurs qui exigent de la part des entreprises une raction rapide ainsi quune continuelle adaptation. Ceci nest possible que si le manager, les directeurs dactivit et les consultants soient en parfaite harmonie. Nous remarquons alors quil y a bien une relation troite entre la ralisation de ces ds et la gestion des
Etude pralable
12
consultants dune entreprise. Pour se faire, chaque entreprise, doit alors, grer ses consultants de manire stratgique et oprationnelle. Dans ce cadre, SunGard a envisag toute une stratgie pour le service de conseil et a dploy une mthodologie prsente par la gure 2.1.1. En eet, les consultants SunGard sont spcialistes des problmatiques de continuit dactivit des organisations et des projets qui en dcoulent. Ils oeuvrent : Identier et rduire les risques de survenance dincidents par des mesures de prvention et de protection Amliorer la raction et les prises de dcisions lors de la dclaration dun incident par des mcanismes de dtection et des procdures ecaces de notication Limiter les impacts, par des mesures de correction, de substitution, de contournement et de secours Amliorer la scurit et la conformit des entreprises lensemble des rglementations rgissant les dirents domaines conomiques Dnir, construire et optimiser les infrastructures informatiques ecaces et rentables rpondant aux enjeux de continuit dactivit de chaque entreprise.[3]
Figure 2.1.1 Mthodologie SunGard
Etude pralable
13
2.1.3
Apports de la gestion de consultants
Parmi les nombreux avantages dune dmarche oriente vers la gestion des consultants, nous avons relev : Lvaluation de la performance des collaborateurs, la reconnaissance de la contribution de chaque lment ainsi que la correction des carts Lengagement des dmarches de formation et de dveloppement pertinentes Ltablissement de liens prcis entre les services, prestations fournies par lentreprise et les comptences ncessaires leurs ralisations Le reprage des talents et des potentiels an de les dvelopper au sein de lorganisation La prparation ecace face aux ds futurs, les uctuations du march du travail et de la dmographie
2.2
2.2.1
tude de lexistant
Description du systme existant
Cabestan-ERP est une application qui sert grer les consultants de SCS, assurer leur suivis et fournir a leur dispositions un outil simple dusage et obissant leurs besoins ainsi quaux ceux des directeurs ou des managers qui les supervisent. Cabestan-ERP comprend 6 rubriques : Menu Congs : ce menu permet aux consultants de remplir des demandes de congs, de raliser des suivis des congs et de leurs soldes et de permettre aux superviseurs de suivre toute les activits des consultants et dtre noti a chaque nouvelle modication. Menu Rapport dactivit (RA) : ce menu permet aux consultants de visualiser et de complter leurs rapports dactivits mensuel et permet aux directeurs de valider et de superviser ces rapports et les extrapoler si ils ont en besoin. Menu Contrats : cette rubrique permet aux directeurs et aux managers de superviser les contrats des consultants et de grer les comptes clients.
Etude pralable
14
Menu Ressources Humaines : ce menu fournit aux administrateurs et aux DRH la possibilit de suivre les vnements des consultants (les missions qui lui sont assignes), de grer les consultants et de raliser des extraits des donnes souhaits. Menu Comptences : cette rubrique assure le suivi des comptences dun consultant (diplmes , expriences, comptences et CV) pour avoir une vision compltes sur les ressources de lentreprise en terme de consultants pour maximiser lexploitation des compttances de ces derniers et leurs aecter les missions que leurs sont adquates selon leurs prols. Menu Administration : ce menu permet aux administrateurs de lapplication de grer les utilisateurs de lapplication et les employes de SCS.
2.2.2
Limites et solutions proposes
Bien que le systme existant fournit plusieurs services aux consultants ainsi qu leurs superviseurs ou personnel administratif, nous avons not que les clients de lapplication notament les managers et les directeurs dactivits manquent dune vision plus claire sur les activits des consultants ainsi que la progression de ltat de leurs contracts (historique des contrats dun consultant, volution des tarifs des contrats...). De plus, il est noter que de nouveaux besoins ont t exprim par les utilisateurs tel que lajout des vnements (Point mission, Point client, djeuner...) et des actions (Augumentation de salaire, Formation spcique...) de chaque consultant, dassurer leur suivi et de gnrer des reports. Nous avons dcid de concevoir un systme complet prenant en charge les direntes fonctionalits cites prcdemment.
Conclusion
Ce chapitre nous a permis de prsenter les principales notions de consulting. Nous avons par la suite analys le systme existant et mis en vidence les limites quil accuse et prsent la solution que nous envisageons de raliser. Suite cette tude, nous dtaillerons dans le chapitre suivant les besoins fonctionnels et non fonctionnels de notre systme.
Chapitre 3 Analyse et spcication des besoins

Introduction
Etant la premire dans le cycle de dveloppement du projet, la spcication est la phase la plus importante. En eet, cest au cours de celle-ci que les besoins de lutilisateur sont identis et prciss. Ces besoins reprsentent aussi les fonctionnalits raliser dans lapplication. Dans ce chapitre, nous commenons dabord par voquer les besoins fonctionnels et non fonctionnels de lapplication qui seront prsents sous forme de sprints conformment la mthodologie SCS.
3.1
Identication des acteurs

Les acteurs de notre application sont : Les directeurs de dpartement ou encore appels directeurs dactivits Les manager
Chaque consultant peut avoir un manager qui supervise ces activit, ce manager est lui mme un consultant. Tout les consultants sont des employs, ils appartiennent donc aux dpartements de lentreprise. A chaque dpartement est aect un directeur de dpartement qui supervise les consultants et les manager dont il est responsable. En rsum, les acteurs de notre application sont les managers et les directeurs de dpartement.
15
Analyse et spcication des besoins
16
3.2
Spcication fonctionnelle
Etant donn que la mthodologie suivie au cours de notre processus de travail est un amalgame des deux mthodes Agile Scrum et Xp, cette partie sera organise comme suit : Nous commenons par psenter le use case gnral de notre application, Ensuite, nous prsentons chaque sprint, en spciant les Users Stories correspondant ainsi que le diagramme de cas dutilisation dtaill.
3.2.1
Cas dutilisation gnral
Pour avoir une vue globale sur les grandes lignes de notre systme, la gure 3.2.1 prsente le cas dutilisation gnral.
Figure 3.2.1 Cas dutilisation gnral
17
Le manager a le droit de : Grer les consultants : Visualiser la liste des consultants Modier les consultants (seulement les informations ajoutes par le module followUp) Grer les vnements : Visualiser la liste des vnements Visualiser les vnements non termins Ajouter un vnement Modier un vnement
Grer les actions : Visualiser les actions Ajouter une action Modier une action Supprimer une action
Le directeur de dpartement a le droit daccder toutes les rubriques du manager mais en outre il peut aussi : Visualiser lhistorique de contrats dun consultant Exporter le panel des consultants selon les ltres Grer les directeurs de dpartement : Visualiser la liste des directeurs Ajouter un directeur Modier un directeur
3.2.2
Sprint 1
Le sprint 1 est compos de 4 User Stories dcrits ci-dessous. Selon le besoin du client, nous laborons les user stories adquates. Gnralement, le premier sprint comprend
18
toujours les besoins du client de criticit leve. Tableau rcapitulatif du premier User Story Panel des consultants :
Id Nom Valeur/criticit Acteurs Sujet
Pourquoi
User Story 1 1 Projet Follow-up Panel des consultants 1 Criticit leve Les utilisateurs cible sont les directeurs de dpartement et les managers 1) Connexion Cabestan-ERP 2) Ouverture du module Follow-up 3) Recherche dun consultant selon les critres "Dpartement", "Filiale", "Directeur", "Aect", "Consultant" 4) Achage de la liste des personnes correspondant aux critres de recherche spcis. Les donnes acher sont "Consultant", "Dpartement", "Position", "Date dbut", "Manageur", "Directeur", "Groupe", "Filiale", "Contrat", "Date dbut Contrat", "Date n Contrat", "Tarif journalier", "Aect" Identier rapidement la personne dont on veut faire le suivi de carrire
Table 3.2 User Story 1 Tableau rcapitulatif du deuxime User Story Visualisation des vnements dun consultant :
User Story 2 4 Projet Follow-up Visualisation des vnements dun consultant 2 Criticit leve Les utilisateurs cible sont les directeurs de dpartement et les managers 1) Connexion Cabestan-ERP 2) Ouverture du module Follow-up 3) Slection dun consultant 4) Achage de la liste des vnements du consultant slectionn. Les donnes aches sont "Type dvnement", "Date eet", "Description", "Is done". Suivre lvolution des vnements surgissant dans la carrire dun consultant.
Pourquoi
Table 3.4 UserStory 2
19
Tableau rcapitulatif du troisime User Story Gestion dun vnement :
Pourquoi
User Story 3 5 Projet Follow-up Gestion dun vnement 3 Criticit leve Les utilisateurs cible sont les directeurs de dpartement et les managers 1) Connexion Cabestan-ERP 2) Ouverture du module Follow-up 3) Recherche dun consultant selon les critres "Dpartement", "Filiale", "Directeur", "Aect", "Consultant" 4) Cration dun nouvel vnement en y attachant un document. Les donnes saisir sont "Type", "Description", "Date eet", "Reminder", "IsDone". Seuls le "Type" et la "Value Date" doivent tre obligatoirement saisies. N.B. : il faut grer aussi la suppression, la modication et la lecture dun vnement (attention, pas de suppression de lvnement en base de donnes) Suivre les vnements dun consultant donn
Table 3.6 UserStory 3 Tableau rcapitulatif du quatrime User Story Gestion des actions dun vnement :
User Story 4 Id 3 Projet Follow-up Nom Gestion des actions dun vnement Valeur/criticit 4 Criticit leve Acteurs Les utilisateurs cible sont les directeurs de dpartement et les managers Sujet 1) Connexion Cabestan-ERP 2) Ouverture du module Follow-up 3) Recherche dun consultant selon les critres "Dpartement", "Filiale", "Directeur", "Aect", "Consultant" 4) Achage de la liste des vnements du consultant slectionn. 5) Achage de liste des actions dun vnement slectionn. 6) Ajout dune nouvelle action. Les donnes saisir sont "Date eet", "Description", "Actor", "Is Done" Pourquoi Suivre les actions mener suite un vnement.
20
La gure 3.2.2 illustre le cas dutilisation relatif au Sprint 1.
Figure 3.2.2 Cas dutilisation relatif au 1er sprint Vue le nombre important des besoins, nous avons choisi de raner quelques scnarios. Cependant, les principales fonctionnalits apportes par le premier sprint (gure 3.2.2) permettent aux managers et aux directeurs de departements de : Visualiser la liste des consultants selon des ltres. Grer les vnements dun consultant. Grer les actions dun vnement. Acteurs : Managaeur et directeurs de dpartement.
21
3.2.3
Sprint 2 :
Le sprint 2 est compos de 4 User Stories dcrits ci-dessous. Tableau rcapitulatif des dirents apports du cinquime User Story Alertes dun vnement :
User Story 5 6 Projet Follow-up Alertes dun vnement 5 Criticit moyenne Les utilisateurs cible sont les directeurs de dpartement et les managers A la cration dun vnement, si un rappel a t dni, une runion est gnre automatiquement sur un outil de messagerie aux adresses email SunGard du consultant et du manager. Ajouter dans le contenu de la runion les actions dnies dont la Value Date nest pas encore passe et dont le statut nest pas encore "Termin". Rappeler les dirents intervenants quun vnement va avoir lieu et que des actions sont mener.
Pourquoi
Table 3.10 UserStory 5 Tableau rcapitulatif des dirents apports du sixime User Story Export du panel des consultants :
User Story 6 2 Projet Follow-up Export du panel des consultants 6 criticit moyenne Les utilisateurs cible sont les directeurs de dpartement. 1) Connexion Cabestan -ERP 2) Ouverture du module Follow-up 3) Recherche dun consultant selon les critres "Dpartement", "Filiale", "Directeur", "Aect", "Consultant" 4) Exporter dans une feuille Excel contenant les informations suivantes de la liste des consultants prcdente : "Consultant", "Dpartement", "Position", "Date dbut", "Manageur", "Directeur", "Groupe", "Filiale", "Contrat", "Date dbut Contrat", "Date n Contrat", "Tarif journalier", "Aect" Analyser les donnes de Follow-up pour produire des indicateurs sur Excel
Pourquoi
22
Tableau rcapitulatif des dirents apports du septime User Story Historique des contrats dun consultant :
Pourquoi
User Story 7 7 Projet Follow-up Historique des contrats dun consultant 7 Criticit moyenne Les utilisateurs cible sont les directeurs de dpartement. 1) Connexion Cabestan-ERP 2) Ouverture du module Follow-up 3) Slection dun consultant 4) Achage de la liste des contrats du consultant slectionn en fournissant les informations suivantes : "Groupe", "Filiale", "Contract", "Date dbut Contrat", "Date n Contrat", "Salaire", "Commercial" Visionner les contrats des consultants slectionns.
Tableau rcapitulatif des dirents apports du huitime User Story Suivi des vnements en cours :
Pourquoi
User Story 8 8 Projet Follow-up Suivi des vnements en cours 8 Criticit moyenne Les utilisateurs cible sont les directeurs de dpartement et les managers 1) Connexion Cabestan-ERP 2) Ouverture du module Follow-up 3) Acher la liste des prochaines vnements ayant des actions non termines. 4) Achage de la liste des vnements non termins ayant au moin une action non valid en fournissant les informations suivantes : "Nom Consultant", "Prenom Consultant", "Type", "Description", "Date eet" Visionner rapidement les vnements non termins
23
La gure 3.2.3 prsente le digramme de cas dutilisation rsultant du Sprint 2. Les modications apportes par rapport au Sprint 1 sont mentionnes en rouge.
Figure 3.2.3 Cas dutilisation relatif au 2me sprint Les fonctionnalites apportes par le deuxime sprint (gure 3.2.3) permetent aux acteurs du systme de : Visualiser lhistorique des contrats dun consultant Exporter le panel des consultants selon les ltres choisis Suivi des vnements non termins
24
3.2.4
Sprint 3 :
Le sprint 3 est compos dun seul User Storie dcrit ci-dessous et des tches secondaires tels que la revue et le ranement de quelques tches des sprints prcdents. Tableau rcapitulatif du neuvime User Story Gestion des directeurs de dpartement :
User Story 9 Id Nom Valeur/criticit Acteurs Sujet 9 Projet Follow-up Gestion des directeurs de dpartement 9 Criticit moyenne Les utilisateurs cible sont les directeurs de dpartement 1) Connexion Cabestan-ERP 2) Ouverture du module Follow-up 3) Recherche dun directeur selon les critres "Dpartement", "Filiale", "Directeur" 4) Achage de la liste des directeurs de dpartement correspondant aux critres de recherche spcis. Les donnes acher sont "Directeur", "Dpartement","Filiale" N.B. : Ne pas oublier de grer la suppression des directeurs (attention, pas de suppression en base de donnes). Avoir un accs rapide aux informations des directeurs ainsi quune ventuelle modication.
Pourquoi
Table 3.18 UserStory 9 La gure 3.2.4 prsente le digramme de cas dutilisation rsultant du Sprint 3
Figure 3.2.4 Cas dutilisation relatif au 3me sprint
25
Les fonctionnalits apportes par le 3me sprint (gure 3.2.4) permetent aux directeurs de dpartement seulement dans ce cas de : Visualiser la liste des directeurs Ajouter un directeur Editer un directeur Autres fonctionnalits apports dans ce sprint : Ajout de fonctionnalits mtier et ranement de lachage Ajout de la colonne crateur de lvnement et lacher dans le panel Ajout dun job de notication des vnements par mail
3.3
3.3.1
Spcication non fonctionnelle

Scurit
Daprs les User Story fournis par le client, les deux acteurs de lapplication manager et directeurs de dpartement. Chaque acteur doit avoir laccs seulement aux rubriques qui lui sont ddies. La gestion des droits daccs seectue travers la cration des rles. Tout autre client de lapplication nayant aucun de ces rles naura pas accs au module FollowUp. Rle manager : Le manager est responsable de la gestion des consultants, de lensemble de leur vnements et actions, du suivit des vnements non termines.Il a accs aux fonctionnalits de recherche des donnes des consultants selon dirents critres : consultant, dpartement ,liale, directeur, assign. Rle directeur : Le directeur de dpartement a accs tout les rubriques du mangeur en outres ceux qui lui sont dsign ; la gestion des directeurs, les fonctionnalits de recherche, suivit de lhistorique des contrats ainsi que lexport des donnes des consultants selon dirents critres : consultant, dpartement ,liale, directeur, assign.
26
3.3.2
Internationalisation
Toutes les informations gres par le systme doivent tres disponibles en franais et en anglais. Linternationalisation de lapplication permet de visualiser et de grer les prols des consultants, les vnements et actions et de gnrer des extraits dans les deux langues.
3.3.3
Contraintes dutilisation
Linterface utilisateur doit tre simple et facile comprendre pour que lutilisateur puisse bncier des fonctionnalits du systme. Lachage des listes de consultants, vnements, actions et directeurs dactivits doit se faire dans des tableaux disposant des fonctionnalits de tri ascendantes et descendantes sur tous les attributs. Tous les tableaux doivent tre accompagns de ltres sur les attributs pour pouvoir eectuer des oprations de recherche.
3.3.4
Contraintes dergonomie
Linterface utilisateur doit tre conviviale, ergonomique et bien organise. Linterface utilisateur doit implmenter le mcanisme "Look and Feel" : lapparence de ces interfaces est principalement caractrise par des paramtres de base comme les polices, les formes, les couleurs et la disposition des lments. La perception et le ressenti sont quant eux plus inuenables par linteraction qui est caractrise par dautres paramtres comme les boutons et les menus.
3.3.5
Contraintes de performance
Le temps de rponse doit tre acceptable. Le systme doit tre stable et sr quelque soit le nombre dutilisateurs qui le manipulent.
3.3.6
Contraintes techniques
Le systme doit tre portable, interoprable et fonctionnel sur nimporte quel type de systmes dexploitation.
3.3.7
Contraintes de maintenance
Les dirents modules de lapplication doivent tre faciles maintenir. Pour cela, le code doit tre lisible et bien structur. Do lutilisation des standards proposs par la socit savre utile. Ces standards concernent par exemple les noms des attributs et des
27
variables, les noms des mthodes ainsi que la disposition des commentaires, la JavaDoc qui doit tre aussi bien claire quexpressive est indisponsable pour chaque mthode implment.
Conclusion
La spcication des besoins nous a permis davoir une vision plus claire du sujet et une comprhension plus profonde des tches raliser. Elle mne galement prvoir les problmes rencontrer et chercher les solutions permettant de les contourner. Nous avons essay tout au long de ce chapitre de bien prsenter les besoins fonctionnels et non fonctionnels du sujet. Ces besoins vont tre la base sur laquelle nous allons raliser la conception du systme. Cette conception est lobjet du chapitre 4.
Chapitre 4 Conception
Introduction
Dans ce chapitre nous laborons une tude conceptuelle dtaille de notre application. Nous commenons dabord par prsenter notre premier travail conceptuel travers quelques mockups [4]. La suite sera consacre la conception architecturale de lapplication. La dernire partie comprendra quelques diagrammes UML notament les diagrammes de squence, de classe, dactivit pour chaque sprint.
4.1
Conception prliminaire
Dans cette partie, nous allons exposer quelques Mockups ralis avec loutil de modlisation Balsamiq rsumant les grandes fonctionnalit du module vue leurs nombre important. Ces mockup reprsentent des maquettes qui dsignent un prototype dinterface utilisateur. Elles prsentent les ides sur lutilisation et les fonctionalits du module et ceci dans le cadre dune premire conception interfaciale aprs la rcupration des besoins fonctionnels de lapplication. Ces mockups seront approuves en premier lieu par les clients qui retourneront ensuite leurs remarques pour mieux mettre en vidence leurs besoins fonctionnels dnis pralablement. La gure 4.1.1 prsente la conception de la premire interface du module followUp, le premier panel regroupe les informations des consultants ainsi que leur dernier contrat, une recherche rapide selon les ltres dpartement, liale, directeur dactivit, aect et consultant peut tre tablie. Lorsquun consultant est slectionn, une autre grille sera ache, celle du dessous, contenant les informations relatives aux vnements de ce dernier.
28
Conception
29
Figure 4.1.1 Panel Consultant-vnement Le mockup illustr par la gure 4.1.2 prsente laspect du formulaire de lajout ou de ldition dun vnement. Dans la gure prcdente si lutilisateur clique sur le button entre les deux grilles ou encore sur un vnement de la liste de dessous, il accde cette vue. Ce mockup est divis en trois partie, la premire contenant les informations du consultant slectionn, une seconde partie contenant les information de lvnement et une troisime contenant une grilles des actions de cet vnement. Le clique sur le boutton Ajouter sous la grille des actions achera une popup contenant un formulaire dajout ou de modication dune action.
Figure 4.1.2 Panel de cration/dition vnement et action
Conception
30
Dans le premier mockup, si on clique avec la touche droite sur la grille des consultants, un menu sera ach, laction sur ce menu achera cette fentre contenant les informations du consultant slectionn en premire partie et une grille regroupant les contrats de ce dernier. Remarque : laction sur lentte de chaque colonne nous donne la possibilit de le trier en ordre croissant ou dcroissant et ceci pour chaque grille notamment celle des consultants, des vnement et des actions.
Figure 4.1.3 Panel historique des contrats dun consultant
4.2
Architecture de lapplication
Dans cette section, nous prsentons larchitecture n-tiers de notre systme. Le systme propos repose sur une architecture n-tiers (gure 4.2.1). Cest un modle logique darchitecture applicative qui vise sparer nettement n couches logicielles au sein dun mme systme (gnralement 3 ou 4 couches). Elle sert modliser et prsenter ce systme comme un empilement de "n" couches dont le rle de chacune est clairement dni comme suit : La prsentation des donnes : contient les dirents types de clients, lger (Web, GWT, GXT, JSP, etc.) ou lourd (Swing, SWT, AWT, etc.). En plus, elle peut correspondre la restitution de donnes en un format standard capable dtre interprt par direntes machines en occurrence XML.
Conception
31
La couche des services : contient les traitements (Contrleurs de Use Case UML) reprsentant les rgles mtiers (crer un modle de processus, instancier un processus, etc.). Le traitement mtier des donnes : correspond la mise en place de lensemble des rgles de gestion de la logique applicative. Laccs aux donnes persistantes : correspond aux donnes qui vont tre gardes pour une longue dure, voire de manire persvrante. Cette architecture respecte le design pattern Model-View-Controller (MVC). Elle vise sparer la couche prsentation, de la couche logique applicative et de la couche persistance des donnes. La sparation des responsabilits par couche permet de maximiser la rutilisation du code et de concentrer les ressources sur leur spcialit.
Figure 4.2.1 Architecture n-tiers Dans cette approche, les couches communiquent entre elles travers un "modle dchange" et chacune dentre elles propose un ensemble de services rendus. Les services dune couche sont mis la disposition de la couche suprieure. On sinterdit, par consquent, quune couche invoque les services dune couche plus basse que la couche immdiatement
Conception
32
infrieure ou plus haute que la couche immdiatement suprieure (chaque niveau ne communique quavec ses voisins immdiats). Le rle de chacune des couches et leur interface de communication tant bien dni, les fonctionnalits de chacune dentre elles peuvent voluer sans induire de changements dans les autres. Ce modle darchitecture n-tiers a pour objectif de rpondre aux proccupations suivantes : La exibilit : les systmes sont sujets des changements structurels frquents cause de la mutation rapide des technologies, cest pourquoi lajout de nouveaux modules est primordiale pour la prennit du systme. La scalabilit : la capacit qua larchitecture pour voluer en cas de monte en charge si ncessaire. En eet, chaque module peut tre dploy indpendamment des autres sur une machine, ou un cluster de machines. Ce qui permet dajouter des ressources si besoin est. La modularit : une approche structurante qui spare un logiciel en petites units qui, rassembles, composeront lensemble dun logiciel. Cette approche permet non seulement une certaine rutilisation de certaines units de traitements, mais aussi une trs grande souplesse dans la modication puisque le changement dun module nimplique pas le changement de tous les autres.
Conception
33
4.3
Diagramme de composants
Lapplication Cabestan-ERP ore plusieurs fonctionalits tels que la gestion des congs, des rapports dactivits des consultants, de leur comptances... Ces direntes fonctionalits sont regroupes sous forme de modules, chaque module comporte une partie core qui contient les classes modles, mtiers et services oertes et une partie GWT pour la prsentation. Maven, notre outil de gestion du cycle de vie du projet, gre trs bien cette architecture moduliare. La gure 4.3.1 chmatise les dirents modules de lapplication et leurs dpendances. Le module common est commun pour tous les modules, il contient les classes est les services utiliss par tous les autres modules. Le module FollowUp hrite de common ainsi que celui de contrat, les classes modles, mtier, service et gwt des modules common et contrat seront utilisable par le module FollowUp.
Figure 4.3.1 Diagramme de composants
Conception
34
La gure 4.3.2 explique davantage la dpendance du module FollowUp envers les autres modules common et contrat. Cette gure regroupe les classes de chaque module qui constituront le diagramme de classes que nous dtaillerons dans les prochains sprint.
Figure 4.3.2 Dpendances du projet FollowUp
4.4
Diagramme de dploiement
Un diagramme de dploiement est une vue statique qui sert reprsenter lutilisation de linfrastructure physique par le systme et la manire dont les composants du systme sont rpartis ainsi que leurs relations entre eux.[17]. La gure 4.4.1 reprsente les composants les plus important entrant dans larchitecture physique de notre systme.
Conception
35
Figure 4.4.1 Diagramme de dploiement
4.5
Sprint 1
La phase de conception ncessite des mthodes permettant de mettre en place un modle sur lequel on va sappuyer. La modlisation consiste crer une reprsentation virtuelle dune ralit de faon faire ressortir les points auxquels on sintresse. On a choisit dans ce cadre dutiliser quelques diagrammes tels que les diagrammes de squence, de classe, et dactivit.
4.5.1
Diagramme de squence
Cration du panel Consultant-Evnement La gure 4.5.1 dcrit le scnario du cas dutilisation "cration du panel de la liste des consultant et des vnement" : En cliquant sur Consultant dans le menu horizontal, et puis sur "Voir la liste des consultants" dans le menu droulant, pour que la grille des consultants soit ache, tout un mcanisme derire cette action sera excut. Ce diagramme explique en premier lieu le mcanisme dachage de la liste des consultants, et en second lieu, le squensement de lachage de la grille des vnements du consultant slectionn de la grille.
Conception
36
Figure 4.5.1 Scnario cration du liste panel consultant-vnement
Conception
37
Figure 4.5.2 Scnario cration dun vnement
Conception
38
Cration dun vnement La gure 4.5.2 dcrit le scnario du cas dutilisation "Cration dun vnement". En cliquant sur le boutton ajouter un vnement sous la liste des consultants ou en cliquant avec le boutton droit sur la grille des vnement puis sur ajouter du menu, un mcanisme sera excut pour eectuer cette opration. Ce diagramme explique les dmarches de cration dun vnement.
4.5.2
Diagramme de classes
Nous prsentons dans cette section le diagramme de classe pour ce premier sprint. Les classes ajoutes dans ce cadre sont en rouge. Les autres classes sont relatives aux autres modules dja existant dans lapplication cabestan-erp tels que les modules Common et Contract.
Figure 4.5.3 Diagramme de classe sprint 1
Conception
39
4.5.3
Diagramme dactivit
Les diagrammes dactivits ont un large champ dutilisation. Au plus haut niveau, ils peuvent servir capturer les points de dcisions et de contrle dans un processus.
Figure 4.5.4 Diagramme dactivit Ajout dvnement avec action
4.6
4.6.1
Sprint 2 : Diagramme de squence
Achage de lhistorique de contrats dun consultant
Conception
40
Figure 4.6.1 Scnario achage de lhistorique de contrats dun consultant
Conception
41
La gure 4.6.1 dcrit le scnario du cas dutilisation "achage de lhistorique de contrats dun consultant" : En slectionnant le menu Voir historique des contrats en cliquant avec la touche droite sur un consultant de la grille , le panel contenant les inrmations du consultant pralablement slectionn est la grille contenant la liste des ces contrats sera ach.
4.6.2
Diagrammes de classes
Nous prsentons dans cette section les modications du diagramme de classe pour ce deuxime sprint. Ces modication se prsnetent dans la classe Employee en rouge, il ny a pas dajout de nouvelles classes dans ce sprint.
Conception
42
4.6.3
Diagramme dactivit
Le diagramme suivant prsente le processus de lexportation du panel consultant sous format Excel.
Figure 4.6.3 Diagramme dactivit Activit Exporter Panel consultant
4.7
4.7.1
Sprint 3 : Diagramme de squence
Ajout dun directeur de dpartement
Conception
43
Figure 4.7.1 Scnario ajout dun directeur de dpartement
Conception
44
La gure 4.7.1 dcrit le scnario du cas dutilisation "ajout dun directeur de dpartement" : En cliquant sur Administration dans le menu horizontale, et puis sur "Voir la liste des directeurs" dans le menu droulant, la grille des directeurs une fois ach, en cliquant avec la touche droite sur la grille un menu sache, une fois quon clique sur le boutton ajouter, un panel contenant des combobox dpartement, liale et directeur sera ach.
4.7.2
Diagramme de classes
Nous prsentons dans cette section le diagramme de classe pour ce troisime sprint. On remarque quon a ajout les classes DepartmentHead et DepartmentHeadPK et le crateur de lvnement au cours de ce sprint.
Conception
45
4.7.3
Diagramme dactivit
Le diagramme suivant prsente le processus de ldition dun directeur dactivit.
Figure 4.7.3 Diagramme dactivit Activit edition dun directeur dactivit
Conclusion
Dans ce chapitre, nous avons prsent la conception de notre application. Nous avons expliqu, dans un premier lieu, une conception prliminaire sous forme de mockups, ensuite, nous avons prsent larchitecture de lapplication et en n une conception dtaille de lapplication travers les diagrammes de classes, de squences et dactivits. A prsent, nous sommes capable dentamer la partie ralisation.
Chapitre 5 Ralisation
Introduction
Dans cette partie, il est question de dcrire laspect implmentation du systme. Nous commenons par prsenter, les design patterns et les choix technologique utiliss. Par la suite, nous spcions lenvironnement du travail pour nir avec la prsentationde quelques inetrfaces ralises.
5.1
Framework JEE et technologies utilises
JEE, acronyme de Java Entreprise Edition, est ddi la ralisation dapplications n-tiers pour entreprises. JEE est bas sur JSE (Java Standard Edition) qui contient les API de base de Java. JEE est une plateforme fortement oriente serveur pour le dveloppement et lexcution dapplications distribues. Elle fait appel un ensemble dAPI et de composants qui interviennent dans les direntes couches des applications JEE. Lutilisation de JEE pour dvelopper et excuter une application propose plusieurs avantages : Une architecture dapplication base sur les composants qui permet un dcoupage de lapplication et donc une sparation des rles lors du dveloppement et la facilit de maintenance. La possibilit de communiquer avec le systme dinformation existant grce de
46
Ralisation
47
nombreux framework de persistance : Hibernate par exemple. La possibilit de choisir les outils de dveloppement et les serveurs dapplications utiliss quils soient commerciaux ou libres JEE permet une grande exibilit dans le choix de larchitecture de lapplication en combinant les dirents composants. Ce choix dpend des besoins auxquels doit rpondre lapplication mais aussi des comptences dans les direntes API de JEE. Larchitecture dune application se dcoupe idalement en au moins trois tiers : La partie cliente permet le dialogue avec lutilisateur. La partie mtier encapsule toute lintelligence de lapplication, les traitements mtier et EJB (Entreprise Java Bean) pour la manipulation des donnes. Nous prsentons dans ce qui suit, les direntes technologies JEE utilises pour le dveloppement de notre application.
5.1.1
Spring 2.5
Spring [15] est un framework open source pour le dveloppement des applications Java 3-tiers [5]. Il prend en charge la cration dobjets et la mise en relation dobjets par lintermdiaire dun chier de conguration ou des annotations java qui dcrivent les objets fabriquer et les relations de dpendances entre ces objets.
Figure 5.1.1 Spring MVC dans la couche prsentation Spring sappuie principalement sur les concepts suivants : 1. IoC (Inversion Of Control) inversion de contrle galement appele injection de dpendance 2. Spring MVC qui intgre larchitecture 3-tiers (voir gure 5.1.1) 3. La programmation orient aspect AOP
Ralisation
48
4. Le suivie du cycle de vie des objets 5. La gestion des transactions.
5.1.2
JPA (Java Persistence API)
JPA est une API Java utilise pour la persistance dun mapping relationnel/objet [6]. Elle ore un niveau dabstraction plus lev que la simple utilisation de JDBC. Ce mapping permet linteraction des objets java avec la base de donnes (cration, modication et suppression) et ce grce un langage dinterrogation similaire SQL mais utilisant des objets plutt que des entits relationnelles de la base de donnes. JPA repose sur des entits qui sont de simples POJO (Plain Old Java Object) annots et sur un gestionnaire de ces entits (EntityManager) qui propose des fonctionnalits pour les manipuler (ajout, modication suppression, recherche). Ce gestionnaire est responsable de la gestion de ltat des entits et de leur persistance dans la base de donnes.
5.1.3
JUnit
JUnit est une API open source pour le dveloppement et lexcution de tests unitaires automatisables. Le principal intrt est de sassurer que le code rpond toujours aux besoins mme aprs dventuelles modications. Plus gnralement, ce type de tests est appel tests unitaires de non rgression. JUnit est particulirement adapt pour tre utilis avec la mthode eXtreme Programming (dj dtaille) puisque cette mthode prconise entre autre lautomatisation des tches de tests unitaires qui ont t dnis avant lcriture du code [7]. Ecrire des tests unitaires est peut-tre lune des tches les plus diciles du dveloppement mettre en action. Cependant, nous devrons crire un test pour chaque mthode dveloppe aussi bien pour les trois couches. Ces tests ne sont quune simulation dutilisation des modules dvelopps o les modules doivent passer les scnarios de test 100%.
5.1.4
GWT (Google Web Toolkit)
GWT [17] est un ensemble doutils logiciels dvelopp par Google, permettant de crer et maintenir des applications web dynamiques mettant en uvre JavaScript, en utilisant le langage et les outils Java. Cest un logiciel libre distribu selon les termes de la licence Apache 2.0. GWT met laccent sur des solutions ecaces et rutilisables aux
Ralisation
49
problmes rencontrs habituellement par le dveloppement AJAX : dicult du dbogage JavaScript, gestion des appels asynchrones, problmes de compatibilit entre navigateurs, gestion de lhistorique et des favoris, etc. Il sagit donc dune bote outils qui ore des solutions permettant de dvelopper plus facilement des solutions web/AJAX de dernire gnration, en protant des outils et comptences Java existants.
5.1.5
Maven 2.0
Maven [16] est un outil open-source de gestion du cycle de vie et dintgration continue pour les projets Java, conu pour supprimer les tches diciles du processus de build. Maven utilise une approche dclarative, o le contenu et la structure du projet sont standardiss comme le montre la gure 5.1.2
Figure 5.1.2 Structure dun projet Maven
Les cycles de vie des projets sont un concept central de Maven 2. En eet cet outil permet de standardiser les direntes phases du build comme compile, test et deploy. La gure 5.1.3 nous le prsente
Ralisation
50
Figure 5.1.3 Les phases du cycle de vie dun projet maven Maven ore les fonctionnalits suivantes : Gestion du cycle de vie du projet Construction, compilation Documentation (java doc) Rapport Gestion des dpendances Gestion des sources Mise jour de projet Dploiement
5.1.6
BIRT Business Intelligence and Reporting Tool
Le projet BIRT, Business Intelligence and Reporting Tools, propose un systme de cration de rapports pour les applications Web avec plusieurs formats : pdf, word, excel, etc. BIRT est un produit open-source et libre dutilisation.
5.1.7
Logiciel de gestion de version
Un logiciel de gestion de versions (ou VCS en anglais, pour Version Control System) est un logiciel de gestion de conguration permettant de stocker des informations pour une ou plusieurs ressources informatiques permettant de rcuprer toutes les versions intermdiaires des ressources, ainsi que les dirences entre les versions. Il existe une diversit de logiciels
Ralisation
51
sur le march tel que : CVS, Suberversion, Visual SourceSafe, Perforce, ClearCase, PVCS . . . etc.
Subversion SVN : est un systme de gestion de versions qui permet :

garder un historique des direntes versions des chiers dun projet permettre le retour une version antrieure quelconque garder un historique des modications avec leur nature, leur date, leur auteur... permettre un accs souple ces chiers, en local ou via un rseau permettre des utilisateurs distincts de travailler ensemble sur les mmes chiers
Tortoise SVN : est un logiciel client de SVN. Il enrichi lexplorateur Windows avec les
fonctionnalits suivantes : Superposition dicne aux rpertoires et chiers permettant de visualiser instantanment ltat ( jour, modi, en conit...) Menu contextuel permettant de re le commite ou lupdate, lchelle dun chier, dune slection de chiers ou encore dun rpertoire Possibilit dajouter en mode dtails de lexplorateur des colonnes de type numro de rvision, tat. . . .
5.1.8
Hudson
Hudson est un outil open source dintgration continue crit en Java, fonctionnant dans un conteneur de servlets tel que Apache Tomcat, ou en mode autonome avec son propre serveur Web embarqu. Il sinterface avec des systmes de gestion de versions tels que CVS et Subversion, et excute des projets bass sur Apache Ant et Apache Maven aussi bien que des scripts arbitraire en shell unix ou batch Windows. Les gnrations de projets peuvent tre inities par dirents moyens, tels que des mcanismes de planication similaires au cron, des systmes de dpendances entre gnrations, ou par des requtes sur certaines URL spciques. Dernirement, Hudson est devenue une alternative populaire1 loutil de rfrence CruiseControl. Le 11 janvier 2011, une proposition pour renommer Hudson a t annonce an dviter des problmes avec un ventuel enregistrement (marque dpose) du nom par
Ralisation
52
Oracle2. Aprs lchec des ngociations avec Oracle34, un vote en faveur du renommage pour Jenkins a t entrin le 29 janvier 20115.[8]
Figure 5.1.4 Suivi de la stabilit du projet avec Hudson
Aprs chaque commit sur le serveur, Hudson excute automatiquement une compilation du projet dploy. Congur avec Maven, Hudson lance lensemble de test unitaire de chaque module chaque modication de code. Si la compilation stablie sans erreur, le build sera ach en bleu, si il y a une erreur dans le code, le build sera en rouge. Nous pouvons visualiser la cause du problme, la mthode responsable de lerreur et lauteur du code associ. La gure 5.1.4 reprsentent linterface de lhistorique de build de Hudson.
Ralisation
53
5.1.9
JIRA
JIRA est un systme de suivi de bugs, un systme de gestion des incidents, et un systme de gestion de projets dvelopp par Atlassian Software Systems. JIRA nest pas un acronyme mais une contraction de Gojira (le nom japonais de Godzilla).[9] JIRA permet dassurer le suivi des problmes et le suivi des projets de dveloppement de logiciels des quipes pour amliorer la qualit du code et la vitesse de dveloppement. Il fournit une interface claire et rapide permettant de capturer et dorganiser des problmes avec workows personnalisables, les tableaux de bord OpenSocial et une intgration enchables cadre. JIRA est parmi les solutions les plus adquates aux quipes de dveloppement sur tout quelle est en parfaite harmonie avec la mthodologie Scrum suivie dans notre projet.
Figure 5.1.5 Workow JIRA
Ralisation
54
Figure 5.1.6 Dashboards JIRA Au cours de lvolution du processus de dveloppement de lapplication, et comme dcrit pralablement propos de la mthodologie suivi (Scrum + Xp), lutilisation dun outil de gestion de cycle de vie du dveloppement du projet est indispensable. Voici quelques interface de loutil quutilise SCS pour le suivie du projet Cabestan-Erp (JIRA). la Figure 5.1.6 prsente le tableau de bord de linterface de JIRA qui permet de visualiser le ux dactivit des membres de lquipe, personnaliser linterface suivant des ltres selon le besoin ; exemple ltre des tches qui me sont aect...
Ralisation
55
Figure 5.1.7 Tche 1- 1er Sprint : Panel consultant La gure 5.1.7 prsente la premire tche du premier sprint, nous remarquons quil y a toutes les donnes du droulement de la tche : tat de la demande(en progression, rsolue, ferme...), le temps pass pour accomplir chaque sous tche ainsi que leurs descriptions et commentaire.
Ralisation
56
Figure 5.1.8 BurnDown Chart du 3eme Sprint Au cours du droulement de chaque sprint, nous pouvons suivre la progression des tches, le temps journalier pass sur chaque tche grce au graphe de la gure 5.1.8. La ligne rouge est la progression moyenne en heure chaque jour pour accomplir lensemble des tches du sprint temps sans dpassement. La ligne verte est la progression des inputs journalier des heurs passs sur les tches du sprint. Cette ligne doit tre en dessous de la ligne rouge pour sassurer que nous ne dpasserons pas les dlais.
5.2
Les design patterns utiliss
En informatique, un modle de conception ou motif de conception est un concept de gnie logiciel destin rsoudre les problmes rcurrents suivant le paradigme objet. Ils
Ralisation
57
dcrivent des organisations pratiques de classes objets [10]. Les design pattern permettent de : Faciliter la maintenance du code Minimiser les interactions quil peut y avoir entre les direntes classes et modules appliquant des solutions dj existantes des problmes courants de conception Faciliter lextension de lapplication
Le design pattern MVC Le design pattern Modle-Vue-Contrleur (MVC) est un pattern architectural qui spare les donnes (le modle), linterface homme-machine (la vue) et la logique mtier (le contrleur). Le design pattern DAO Le pattern DAO (Data Access Object) permet de faire le lien entre la couche mtier et la couche persistante, ceci an de centraliser les mcanismes de mapping entre notre systme de stockage et nos objets Java. Il permet aussi de prvenir un changement ventuel de systme de stockage de donnes (de MySQL vers Oracle par exemple). Le design pattern IoC Linversion de contrle est un motif de conception logicielle commun tous les frameworks, devenu populaire avec ladoption des conteneurs dits "lgers". Cette notion fait partie des principes de la programmation oriente aspect [11]. Lun des principaux avantages de cette mthode de conception est de rendre indpendants les modules dune application et de dcoupler les dpendances entre elles, par injection de dpendances, DI (Dependency Injection). Elle consiste injecter les composants dans linstanciation des classes. Le design pattern Singleton Le singleton fait partie des design patterns de cration car il cre et retourne une instance dun objet. Le but de ce design pattern est dassurer quune seule instance dun objet donn sera rfrence pendant toute la dure de lapplication, cest--dire : Certitude de lunicit de linstance un moment donn dans lespace reprsent par la mmoire.
Ralisation
58
Le design pattern Factory Une fabrique de cration (ou Factory) est une classe qui na pour rle que de construire des objets. Cette classe utilise des interfaces ou des classes abstraites pour masquer lorigine des objets.
5.3

Environnement de dveloppement
Eclipse Helios Service Release 2 avec un JDK 1.6, Systme de gestion de base de donnes : MySQL 5.1, Outil de gestion de base de donnes : TOAD for MySQL, Outil de conception de base de donnes : MySQL Workbech 5.1, Outil de traitement de textes : Latex/Lyx, Outil de gestion de versioning : Subversion SVN, TortoiseSVN, Outil de gestion de projet : JIRA, Outil de conception de mockups : Balzamiq, Outil dintgration continue : Hudson, Outil de modlisation UML : Jdevelopper, Outil de gestion de cycle de vie du projet : Maven, Outil de cration de rapport : BIRT, Serveur dapplication : Apache Tomcat 6.
Ralisation
59
5.4
Interfaces Homme Machine
Vue le nombre important dinterfaces graphiques, nous en avons slectionn les plus importantes.
Figure 5.4.1 Portail cabestan Une fois connect au systme, lutilisateur aura accs linterface suivante (gure 5.4.1). Le portail de Cabestan-Erp regroupe tout les modules de lapplication, cependant, ces menus seront achs selon les droits de lutilisateur connect. Si un module est slectionn, son contenu sera charg dans le panel du milieu automatiquement.
Ralisation
60
Figure 5.4.2 Interface du panel Consultant - vnement La gure 5.4.2 reprsente linterface dacceuil du module FollowUp. En slectionnant le menu FollowUp, le client (manageur ou directeur) peut visualiser la population des consultants existante dans la grille des consultants ainsi que leurs contrats. Il peut eectuer des recherches rapides selon les ltres disponibles. Une fois que lutilisateur slectionne un consultant de la liste, une nouvelle grille sera ach en bas (au dessous de la grille des consultants), cette grille achera les informations des vnements assigns au consultant slectionn. En cliquant sur le boutton droit de la grille des vnements, un menu sera ach, lutilisateur peut ainsi ajouter ou diter un vnement mais pas le supprimer.
Figure 5.4.3 Exemple dextract Excel
Ralisation
61
En cliquant sur le boutton Extraire Excel comme indiqu dans la gure 5.4.2, lutilistaeur a la possiblit dextraire ainsi les informations contenu dans la grille des consultants selon la congurations des ltres choisie sous format excel comme lindique la gure 5.4.3.
Figure 5.4.4 Interface de cration dun vnement La gure 5.4.4 reprsente linterface de cration dun vnement. Il y a des contrles sur les champs requis de lvnement, si ces champs sont vides lutilisateur ne peut ni ajouter une action au formulaire ni ajouter lvnement. Il peut aussi attacher un chier cet vnement si len a besoin. Les actions sont relatives aux vnements, donc pour grer les actions, il est impratif de passer par cette interface.
Ralisation
62
Figure 5.4.5 Interface dajout daction En cliquant sur le boutton Ajouter une action une fentre sera ache contenant le formulaire de laction, les donnes introduites partir de cette fentre seront ajoutes dans la grille des Actions dans le formulaire des vnements comme lindqiue la gure 5.4.5. Un listener fait lcoute sur lensemble des actions. Si toutes les actions sont termines, lvnement sera marqu automatiquement comme termin. Si il y a une seule action qui nest pas termine, alors lvnement sera non termin et lutilisateur ne pourra pas modier sont tat (le checkbox sera non ditable).
Ralisation
63
Figure 5.4.6 Interface de modication des informations des consultants
A travers le formulaire de la gure 5.4.6, lutilisateur a la possibilit de modier les informations du consultant qui sont en relation avec le module followUp (le mois EAE, le numro de tlphone, aect un manager). Un contrle de saisie se basant sur des expressions rgulires sont ajouts tels le cas pour le champ numro de tlphone.
Ralisation
64
Figure 5.4.7 Graphique de la variation des tarifs des contrats dun consultant Le module FollowUp ore son utilisateur la possibilit de visualiser chaque instant lhistorique des contrats dun consultant et la variation du tarif journalier des contrats en fonction de ca date dexcution. Le graphe de la gure 5.4.7 fournit une vision plus expressive et concluante sur ltat de progression des activits de chaque consultant.
Ralisation
65
5.5
Chronogramme
Figure 5.5.1 Chronogramme du projet FollowUp Le chronogramme illustr par la Figure 5.5.1 dcrit les direntes phases par lesquelles nous sommes pass an de mener terme ce travail.
Conclusion
Au cours de ce chapitre, nous avons dcrit les plates-formes logicielles sur lesquelles nous avons construit notre application. Nous avons, ensuite, prsent les interfaces les plus importantes de notre application.
Conclusion gnrale
Avoir une vision claire et permanente de lensemble des activits de ses consultants est une proccupation continue des entreprises notamment dans le domaine des services informatiques ou encore du consulting. Tourne vers lavenir, la lire SCS a dcid dinnover en mettant en place un systme dinformation de gestion des consultants. Ce systme permet dinformatiser le processus de recherche rapide et selon des ltres des informations des consultants, de suivre leurs disponibilit et leurs activits, de reporting. Tout au long de ce projet, nous avons dtaill les direntes tapes danalyse, de conception et de ralisation de ce systme. Le premier chapitre a t consacr au cadre gnral du projet. Il a mis en relief la problmatique qui a engendr le besoin dune solution permettant un suivi dtaill et ecace des activits des consultants par une gestion ecase des vnements et des actions. Le second chapitre propose une dnition des concepts thoriques savoir la notion de consulting et de limportance de la gestion des consultants des SSII 1 . Le troisime chapitre a dtaill la spcication des dirents besoins fonctionnels et non fonctionnels auxquels doit rpondre notre travail. Le quatrime chapitre est consacr ltude conceptuelle o nous avons mis en vidence larchitecture gnrale de notre systme. Le dernier chapitre a t ddi laspect implmentation o nous avons mis en uvre lintgralit de ltude dj labore. Notre travail est dune importance considrable dans la mesure o il nous a oert une ouverture sur le monde professionnel et la vie en entreprise. Dun point de vue technique, il nous a permis de mettre en uvre les acquis thoriques que nous avons appris tout le long de notre cursus universitaire et de les enrichir par la dcouverte de nouvelles technologies,
1. La SSII est une entreprise de service : faiblement capitalise, elle tire du travail intellectuel de ses employs lessentiel de la valeur quelle apporte ses clients.
66
Ralisation
67
notamment larchitecture JEE avec ses divers frameworks tels que Spring MVC et loutil Google Web Toolkit GWT. Cependant, lapplication peut tre considrablement tendue par lajout de nouvelles fonctionnalits. En eet les consultants des SSII prsentent parfois des problmes daectation chez le client : consultant ne rpondant pas aux besoins dun client, raectation dun consultant vers un autre client. . . Ces problmes se manifestent gnralement lorsque ces consultants travaillent dune faon individuelle. Cependant SunGard a dcid dintroduire la notion de centre de service ; un centre de service est form dun Team leader et dune quipe de dveloppeurs. Suite un appel dore SunGard propose des centres de services et non plus des consultants dtachs (selon le besoin) aux clients. Ainsi la gestion des consultants sera alors nettement meilleure. Les perspectives de FollowUp porteront sur le suivi de ces centres de services.
Glossaire A
AOP Aspect Oriented Programming : Un paradigme de programmation qui permet de sparer les considrations techniques (aspect en anglais) des descriptions mtier dans une application. Par exemple, le principe de linversion de contrle (en anglais, inversion of control, IOC) peut tre implmente par cette mthode de programmation. Application Programming Interface : un ensemble de fonctions, procdures ou classes mises disposition des programmes informatiques par une bibliothque logicielle, un systme dexploitation ou un service.
API
D
DAO Data Access Object : un patron de conception DAO propose la cration dune classe DAO par classe mtier. Chaque classe DAO contient les mthodes de liaison avec la base de donnes, parfois appeles CRUD (pour Create, Request, Update, Delete).
E
EJB Enterprise JavaBeans : une architecture de composants logiciels ct serveur pour la plateforme de dveloppement JEE.
68
Glossaire
69
G
GWT Google Web Toolkit : un ensemble doutils logiciels dvelopp par Google, permettant de crer et maintenir des applications web dynamiques mettant en uvre JavaScript. GXT eXtended Gooble Web Toolkit : une librairie Java pour la cration dinterfaces graphiques des applications Web.
I
IoC Inversion Of Control : un patron de conception qui permet de rendre indpendants les modules dune application et de dcoupler les dpendances entre elles.
J
JSE Java Standard Edition : le framework Java destin aux applications pour poste de travail. Ce framework contient toutes les API de base, mais galement toutes les API spcialises dans le poste client (JFC et donc Swing, AWT et Java2D).
P
POJO Plain Old Java Object : cet acronyme est principalement utilis pour faire rfrence la simplicit dutilisation dun Objet Java en comparaison avec la lourdeur dutilisation dun composant EJB.
S
SCS Sungard Consulting Services : une liale de la multinationale SUNGARD.
Glossaire
70
U
UML Unied Modeling Language : un langage de modlisation de 3e gnration orient objet dni par lOMG (Object Management Group).
X
XP eXtreme Programming : une mthode agile de gestion de projet informatique adapte aux quipes rduites avec des besoins changeants. Elle pousse lextrme des principes simples et repose sur des cycles rapides de dveloppement.
Netographie
[1] http ://www.commentcamarche.net/contents/genie-logiciel/methodes-agiles.php3, 16/05/2011 [2] http ://www.sungardas.fr/Services/ServicesdeConseil/Introduction/Pages/ ServicesdeConseilIntroduction.aspx, 11/05/2011 [3] http ://www.sungardas.fr/Services/ServicesdeConseil/ConseiletContinuitedActivite/ MethodologieSunGard/Pages/MethdologieSunGard.aspx, 11/05/2011 [4] http ://fr.wikipedia.org/wiki/Mock-up, 03/03/2011 [5] http ://ego.developpez.com/spring/, 26/05/2011 [6] http ://www.jmdoudoux.fr/java/dej/chap043.htm, 13/05/2011 http://tahe.developpez.com/java/jpa/, 13/05/2011 [7] http://junit.org, 25/02/2011 [8] http://fr.wikipedia.org/wiki/Hudson_(informatique), 24/02/2011 [9] http://fr.wikipedia.org/wiki/Jira, 24/02/2011 [10] http://cyrille-herby.developpez.com/tutoriels/java/mapper-sa-base-donnees-avecpattern-dao/, 21/02/2011 [11] http://fr.wikipedia.org/wiki/Inversion_de_contrle, 21/02/2011 [12] http://fr.wikipedia.org/wiki/Extreme_programming, 13/05/2011 [13] http://www.thierry-pigot.fr/blog/gestion-de-projet/2010/09/27/scrum-en-moinsde-10-minutes.html, 13/05/2011 [17] http ://fr.wikipedia.org/wiki/Diagramme_de_d%C3%A9ploiement], 08/06/2011
71
Bibliographie
[14] Sami Jaber, Prorammation GWT 2, Eyrolles, 2010 [15] Nicolas de Loof, Arnaud Hritier, Apache Maven, Perason, 2009 [16] Arnaud Cogolugnes, Thierry Templier, Julien Dubois, et Jean-Philippe Retaill Spring par la pratique, Eyrolles, 2009
72
Annexe
A - GWT
Google Web Toolkit (GWT) [14] est un ensemble doutils logiciels dvelopp par Google, permettant de crer et maintenir des applications web dynamiques mettant en oeuvre JavaScript, en utilisant le langage et les outils Java. Cest un logiciel libre distribu selon les termes de la licence Apache 2.0. GWT met laccent sur des solutions ecaces et rutilisables aux problmes rencontrs habituellement par le dveloppement AJAX : dicult du dbogage JavaScript, gestion des appels asynchrones, problmes de compatibilit entre navigateurs, gestion de lhistorique et des favoris, etc. GWT est articul autour dun concept original : lors de la phase de dveloppement, lapplication est crite en Java de faon classique, dans un environnement de dveloppement intgr Java, et peut tre dbogue avec les outils Java habituels. Une fois lapplication prte tre dploye, le compilateur GWT la traduit en pur Javascript, avec support automatique et transparent pour les principaux navigateurs (Internet Explorer, Firefox, Mozilla, Safari, Opera). Le code JavaScript gnr utilise des techniques dHTML dynamique et de manipulation du DOM (Document Object Model) pour les aspects dynamiques de linterface. Ce principe est rendu possible par les dirents composants de GWT : Le compilateur Java vers JavaScript Un navigateur spcialement modi pour permettre lexcution (et le dbogage) de code Java natif sans ncessiter la compilation JavaScript Une bibliothque dmulation JRE : il sagit dune implmentation en JavaScript dun sous-ensemble de la bibliothque de classes Java standard (en particulier quasiment tout le package java.lang et une partie de java.util)
73
Annexe
74
Une bibliothque de composants graphiques contenant des widgets de base permettant la construction dune interface graphique GWT est souvent appel abusivement un framework, mais nen est pas vritablement un car il impose peu de choses au dveloppeur ; comme son nom lindique, il sagit dune bote outils qui ore des solutions permettant de dvelopper plus facilement des solutions web/AJAX de dernire gnration, en protant des outils et comptences Java existants, et en faisant abstraction de la complexit habituellement lie ce genre de technologies.
B - eXtreme Programming XP :
Historique On doit XP particulirement Kent Beck, un consultant et un vtran de programmation avec le langage SmalTalk. Elle a t instaure lors dun projet nomm le Chrysler Comprehensive Compensation ou C3 pour le compte du groupe amricain Daimler Chrysler. Aprs, LXP est n ociellement en octobre 2000 avec le livre Extreme Programming Explained. LeXtreme Programming est une mthode rvolutionnaire pour la gestion de projets informatiques. Base sur des principes simples, elle permet de venir enn bout des dpassements de dlais et donc de budget, tout en utilisant des pratiques agiles et adaptables face aux changements frquents des spcications initiales. Parmi ces pratiques, La dmarche itrative de leXtreme Programming savre tre le principal atout surtout du point de vue de la matrise douvrage. XP face aux mthodes traditionnelles Par rapport aux autres mthodes plus traditionnelles comme RAD et Unied Process (qui sappuie sur UML), les professionnels rptent quil serait une erreur de les opposer aux mthodes agiles. XP peut tre vu plutt comme une dclinaison de Unied Process (UP), en ayant bien en tte cependant que cest le client qui rdige les spcications en XP contrairement UP o les spcications sont une interprtation de ce qui a t compris par linformaticien. Aussi, les itrations qui sont un des principes des deux mthodes sont environ 6 fois plus frquentes en XP. Ainsi, les mthodes classiques et les mthodes agiles sont complmentaires. UML qui est une mthode de modlisation nest pas aussi comparable
Annexe
75
XP qui est une mthode de ralisation et dorganisation. Dailleurs, XP utilise le langage universel quest UML pour communiquer. Toutefois, par sa volont de rapidit, XP reste prudent sur lutilisation dUML. Pour cause, les diagrammes UML sont trop longs raliser alors que la conception en XP tant trs courte et ralise au fur et mesure. Cycle de dveloppement XP vise une rduction signicative de la dure du cycle de dveloppement, cest--dire du temps qui scoule entre le moment o lon dcide dimplmenter une fonctionnalit et celui o lon met en production une nouvelle version du logiciel qui intgre la fonctionnalit en question. Lorganisation en itrations frquentes valides chaque fois par le client constitue linnovation de XP en matire de rduction du temps de dveloppement. Lquipe peut casser parfois la structure en place lorsque lajout de nouvelles fonctionnalits lexige, ou bien lorsquelle dcouvre des dfauts dans la mcanique existante, mais elle ne peut jamais avoir limpression de revenir en arrire ou de perdre du temps inutilement. XP apporte des solutions concrtes ces problmatiques, avec un ensemble de pratiques qui forme un systme cohrent et ecace. [12]
C - Scrum :
Pour rappel Scrum est une mthode agile ddie la gestion de projet. Cette mthode de gestion pour objectif damliorer la productivit de son quipe.
Rpartitions des rles dans Scrum

Le Scrum Master Sassure que les principes et les valeurs de Scrum sont respects Facilite la communication au sein de lquipe Cherche amliorer la productivit et le savoir faire de son quipe Lquipe Pas de rle bien dtermin : architecte, dveloppeur, testeur Tous les membres de lquipe apportent leur savoir faire pour accomplir les tches Taille de 6 10 personnes en gnral et pouvant aller jusqu 200 personnes Le Product Owner Expert mtier, dnit les spcications fonctionnelles
Annexe
76
Etablit la priorit des fonctionnalits dvelopper ou corriger Valide les fonctionnalits dveloppes Joue le rle du client
Figure 5.5.2 Etirations de la mthodologie Scrum Les sprints Le cycle de vie Scrum est rythm par des itrations de quelques semaines, les sprints. Le product backlog Le rfrentiel des exigences initiales est dress et hirarchis avec le client. Il constitue ce que lon nomme le product backlog. Il ne doit pas ncessairement contenir toutes les fonctionnalits attendues ds le dbut du projet, il va voluer durant le projet en parallle des besoins du client. User Story Les fonctionnalits dcrites portent le nom de User Stories et sont dcrites en employant la terminologie utilise par le client. Une User Story ou Story contient gnralement les informations suivantes : ID un identiant unique Nom un nom court (entre 2 et 10 mots), descriptif de la fonctionnalit attendue par le client (ex. Export / Import Standard Sales Item). Le nom doit tre susamment clair pour que les membres de lquipe et le Product Owner comprennent de quelle fonction il sagit. Le nom ne doit pas introduire dambiguts. Importance un entier qui xe la priorit des Stories. La priorit dune story peut tre change en cours de ralisation du projet.
Annexe
77
Estimation La quantit de travail ncessaire pour dvelopper, tester, et valider cette fonctionnalit. Lunit de mesure peut tre un nombre de jours idaux (jours 100% ddis la fonctionnalit) ou un nombre de points. Les estimations se font en relatif en comparant les estimations des stories termines avec la story estimer. Demo Un test relativement simple (ex : exporter un objet en XML puis leacer de la base, limporter depuis le XML, la n lobjet doit tre dans la base). Ce test constitue un test de validation. Notes toute autre information : clarications, rfrences documentaires. . . le sprint planning meeting On organise, avant chaque sprint, une runion de planication, le sprint planning meeting. Ce planning slectionne dans le product backlog les exigences les plus prioritaires pour le client. Elles seront dveloppes, testes et livres au client la n du sprint. Elles constituent le sprint backlog, un sous ensemble du product backlog. La mle Au cours du sprint, il est organis, chaque jour, une runion davancement (environ 15 min) avec tous les membres de lquipe an de sassurer que les objectifs du sprint seront tenus, cest le Scrum ou mle. Chaque jour, aprs la runion Scrum, le Scrum Master maintient un graphique appel sprint burndown chart. Ce graphique donne une trs bonne vision de ce qui a t fait et du rythme de travail de lquipe. Il permet galement danticiper si toutes les stories du Sprint Backlog seront termines la n de litration ou non.
Figure 5.5.3 Burn-down chart
Annexe
78
Cette runion na pas seulement un but purement informatif, mais aussi de stimuler lesprit de travail en quipe et le niveau dengagement de chaque membre de lquipe dans le projet. Durant la runion chaque membre de lquipe doit prendre la parole et prsenter principalement les choses suivantes : Ce que jai fait hier et les ventuels problmes rencontrs Ce que je vais faire aujourdhui Est ce que jai des dicults pour continuer mon travail. En faisant cet exercice quotidiennement chaque membre de lquipe est au courant de ce que font ses collgues et il peut coordonner son travail et aider ou se faire aider en cas de dicults.
Le Scrum Meeting nest pas une runion pendant laquelle on cherche rsoudre les problmes, mais uniquement les identier et les exprimer. Le Scrum Master a pour rle dapporter des solutions ou de dlguer un autre membre de lquipe la rsolution des problmes soulevs durant le Scrum Meeting. A la suite de cette runion le Scrum Master met jour le burndown chart. A la n dun sprint, on fait une dmonstration au client des derniers dveloppements, le Sprint Review Meeting. Cest aussi loccasion de faire un un bilan, sur le fonctionnement de lquipe et de trouver des points damlioration. De part ses valeurs, Scrum prne ladaptabilit, sous leet de lexprience acquise et des spcicits du projet ce qui le rapproche de la mthode de production de Toyota. La visibilit, pour valuer les rsultats du processus. Linspection, qui consiste vrier les carts par rapport lobjectif initial.[13]

Rapport Final

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Rapport Final

Hochgeladen von

Copyright:

Verfügbare Formate

Ddicaces A

mes parents : Qui nont jamais cess de maider, massister et mencourager,

Table des matires

Spcication non fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . .

5.2 5.3 5.4 5.5

Conclusion gnrale Glossaire Netographie Bibliographie Annexe

Table des gures

Liste des tableaux

Chapitre 1 Prsentation gnrale

Prsentation de lentreprise daccueil

Prsentation de SCS (Sungard Consulting Services)

Integration dans le portail dja existant.

Figure 1.5.1 Utilit des mthodologies agiles

Figure 1.5.2 Mthodologie Scrum

Figure 1.5.3 eXtreme Programming

Chapitre 2 tude pralable

La gestion des consultants

Figure 2.1.1 Mthodologie SunGard

Apports de la gestion de consultants

Limites et solutions proposes

Chapitre 3 Analyse et spcication des besoins

Identication des acteurs

Analyse et spcication des besoins

Cas dutilisation gnral

Figure 3.2.1 Cas dutilisation gnral

Analyse et spcication des besoins

Analyse et spcication des besoins

Id Nom Valeur/criticit Acteurs Sujet

Id Nom Valeur/criticit Acteurs Sujet

Table 3.4 UserStory 2

Analyse et spcication des besoins

Tableau rcapitulatif du troisime User Story Gestion dun vnement :

Id Nom Valeur/criticit Acteurs Sujet

Table 3.8 UserStory 4

Analyse et spcication des besoins

La gure 3.2.2 illustre le cas dutilisation relatif au Sprint 1.

Analyse et spcication des besoins

Id Nom Valeur/criticit Acteurs Sujet

Id Nom Valeur/criticit Acteurs Sujet

Table 3.12 UserStory 6

Analyse et spcication des besoins

Id Nom Valeur/criticit Acteurs Sujet

Table 3.14 UserStory 7

Id Nom Valeur/criticit Acteurs Sujet

Table 3.16 UserStory 8

Analyse et spcication des besoins

Analyse et spcication des besoins

Figure 3.2.4 Cas dutilisation relatif au 3me sprint

Analyse et spcication des besoins

Spcication non fonctionnelle

Analyse et spcication des besoins

Analyse et spcication des besoins

Figure 4.1.2 Panel de cration/dition vnement et action

Figure 4.1.3 Panel historique des contrats dun consultant

Figure 4.3.1 Diagramme de composants

Figure 4.3.2 Dpendances du projet FollowUp

Figure 4.4.1 Diagramme de dploiement

Figure 4.5.1 Scnario cration du liste panel consultant-vnement

Figure 4.5.2 Scnario cration dun vnement

Figure 4.5.3 Diagramme de classe sprint 1

Figure 4.5.4 Diagramme dactivit Ajout dvnement avec action

Sprint 2 : Diagramme de squence

Achage de lhistorique de contrats dun consultant

Figure 4.6.1 Scnario achage de lhistorique de contrats dun consultant