Rapp

N 99 Juin 2013
Prpar par : Mlle. Sanae EL AZHARI

Mlle. Imane BENAJIBA

Sous la direction de : M. Adil KABBAJ ( )

M. Khalid MOSLIH ( )

M. Loc APLOGAN ( )

Soutenu publiquement comme exigence partielle en vue de lobtention du

Diplme dIngnieur dEtat

Option : INFORMATQUE

Devant le jury compos de :

M. Adil KABBAJ ( )

M. Mohammed NABIL QASIMI ( )

M. Khalid MOSLEH ( )

M. Loc APLOGAN ( )

Projet de Fin dEtudes

Evolution ProBoard :
Gestion de ressources et des
activits
ROYAUME DU MAROC

*-*-*-*-*

HAUT COMMISSARIAT AU PLAN

*-*-*-*-*-*-*-*

INSTITUT NATIONAL

DE STATISTIQUE ET DECONOMIE APPLIQUEE

PAGE 4
PROJET DE FIN DETUDES
DEDICACAES

DEDICACES

Je tiens exprimer ma grande reconnaissance envers mes chers parents,
dont aucun mot nest susceptible de leur exprimer ma profonde affection et
mon immense gratitude pour les sacrifices quils ont consenti pour mes
tudes, je remercie aussi mes deux frres Anas et Salim pour leur soutien et
leur encouragements durant cette priode du stage. Je remercie aussi ma
chre binme Imane ainsi que tous mes amis, en particulier ma chre amie
Fadwa, Sachez que vous tes trs chers mon cur et que je suis trs
reconnaissante pour votre amour et votre soutien.
Du fond du cur je vous dis MERCI .

Sanae ELAZHARI

PAGE 5
DEDICACAES

Je ddie ce travail titre de reconnaissance :

A mes chers parents, qui ont t toujours prsents pour me soutenir dans mes
dfaites et suces :
Aucun mot ne pourra vous exprimer mon amour et ma
gratitude. Que Dieu vous garde et vous prtes bonne sant et
longue vie.

A la mmoire de ma chre sur dfunte Najoua :
Il y a bien plus de trois ans que tu me manques, mais sache que
tes conseils et ton sourire sont toujours prsents pour illuminer
mon chemin.

A mes frres Naoufal et Achraf, ma sur Tidkar,
A ma chre binme et amie Sanae,
A tous mes amis et tous ceux qui me sont chers :
Un grand Merci Pour tout le soutien dont vous avez navez
cess de me prodiguer.

Imane BENAJIBA

PAGE 6
REMERCIEMENTS

REMERCIEMENTS

Il nous est agrable de nous acquitter dune dette de reconnaissance auprs
de toutes les personnes qui de prs ou de loin, ont contribu la russite de ce
travail.
Nous tenons remercier dans un premier lieu notre minent encadrant
acadmique, M. Adil KABBAJ, docteur et enseignant lINSEA, qui na mnag
aucun effort pour la russite de ce stage. Ses conseils pertinents, sa sympathie et
sa constante disponibilit ont constitu autant datouts dans notre formation
quun facteur dterminant dans le bon droulement de notre stage.
Nous remercions M. Bruno BOUITIER, Directeur de STERIAMEDSHORE,
lentreprise daccueil, nous donnant ainsi lopportunit de mettre en pratique nos
connaissances tout en voluant dans un milieu professionnel stimulant.
Nous tenons remercier tout particulirement et tmoigner toute notre
gratitude notre parrain de stage et encadrant M. Khalid MOSLEH, larchitecte
technique de la socit qui nous a fait profiter de son savoir et de sa grande
exprience. Nous le remercions pour son soutien, sa confiance, sa patience, son
orientation minutieuse et pdagogique, ses qualits humaines et pour le temps
quil nous a consacres en dpit de ses occupations.
Par la mme occasion nous exprimons notre reconnaissance M. Loc
APLOGAN chef du Projet TMA et matre douvrage de notre projet pour son aide,
sa disponibilit, ses conseils, sa gentillesse extrme. Sans oublier lensemble du
personnel de la socit pour leur accueil sympathique et leur coopration
professionnelle.
Nos remerciements vont notre chre INSEA Institut National de
Statistique et dEconomie Applique, qui de par sa renomme, son enseignement
et ses professeurs, permet ses tudiants de relever les dfis qui leur sont
confis.
Nous avons aussi le devoir de remercier nos familles, nos amis, pour leurs
sacrifices, soutien et encouragements inestimables nos gards.
Que messieurs les membres de jury trouvent ici lexpression de nos
reconnaissances pour nous avoir fait lhonneur de juger et dvaluer ce prsent
travail.
Que tous ceux que nous avons cits trouvent ici lexpression de notre
profonde gratitude.

PAGE 7
RESUME

RESUME

Le prsent rapport constitue une synthse du travail ralis durant la
priode du stage effectu au sein de la socit STERIA MEDSHORE, dans le cadre
de notre projet de fin dtudes pour lobtention du diplme dingnieur dEtat en
informatique.
Lobjectif de ce stage tait de concevoir et de raliser une deuxime
version de ProBoard. Il sagit dune application web intranet pour la gestion et le
suivi des ressources, des projets et des risques.
La premire tape de notre mission consistait tudier profondment le
besoin et valuer le systme existant afin den extraire les fonctionnalits, les
anomalies et les dfaillances, et de savoir ce quil faut amliorer et ce quil faut
ventuellement ajouter, tout en tenant compte des exigences du matre
douvrage.
Ensuite on a labor une tude fonctionnelle et conceptuelle ayant t
lorigine dune suite de propositions de solutions envisageables qui ont fait lobjet
de discussion et damlioration plusieurs reprises avec les parties prenantes du
projet.
Quant laspect technique, il sest bas sur une approche oriente objet
dont limplmentation de la solution a fait appel des technologies de pointe qui
respectent le socle applicatif du Framework MOBE -le Framework de
STERIAMEDSHORE- et le cahier des charges retenu pour lapplication, ainsi que
les contraintes techniques imposes.
Bonne lecture.

Mots cls: JEE, STERIA , UML, SCRUM, SPRING.

PAGE 8
ABSTRACT

ABSTRACT

This memory is a synthesis of the though work we managed to put on
during our end of studies internship in STERIA MEDSHORE. This hard work
comes to ornament our journey at the National Institute of statistics and applied
economy, INSEA.
Our project was about to implement an internal solution of management
and monitoring projects, resources and risks, by developing a second version of
the yet existing application ProBoard.
In order to accomplish our mission successfuly, we started by a profound
study of features and weaknesses of the current situation while trying to get the
maximum of data about the eventual needs. Then, we have proposed models of
possible solutions.
Once the functional part is partially and modularly valid, a
translation of the latter in a use case, sequence class diagrams was developed that
were subject of debate and improvements on several occasions with the project
stakeholders.
As for the technical aspect, the achievement of the project ProBoard is
carried out with advanced technologies conforms to the applicative architecture
MOBE of STERIAMEDSHORE and the specifications held for the application.
This phase includes the choice of technology, programming, testing and
deployment of the application.

Happy reading

Key words: JEE, STERIA , UML, SCRUM, SPRING.

PAGE 9

ProBoard

irstsdesairets irstsd atdets .

.
.

,
.
.

, ,
EBOM ,
.

: JEE, STERIA , UML, SCRUM, SPRING .

PAGE 10
LISTE DES ABREVIATIONS

LISTE DES ABREVIATIONS

AJAX ASYNCHRONOUS JAVASCRIPT AND XML
BD BASE DE DONNEES
DAO DATA ACCESS OBJECT
DT DATA TRANSFORMER
EJB ENTREPRISE JAVA BEANS
HTTP HYPERO TEXT TRANSFER PROTOCOL
IOC INVERSION OF CONTROL
JEE JAVA ENTREPRISE EDITION
JSF JAVA SERVER FACES
MOA MAITRE DOUVRAGE
MVC MODEL-VIEW-CONTROLLER
POJO PLAIN OLD JAVA OBJECT
PROBOARD PROFESSIONAL BOARD
SVN SUBVERSION
UML UNIFIED MODELING LANGUAGE
UP UNIFIED PROCESSUS
VO VALUE OBJECT
XHTML EXTENSIBLE HYPER TEXTMARUP LANGUAGE

PAGE 11
LISTE DES FIGURES

LISTE DES FIGURES

Figure 1 : Cartographie du groupe Steria ..................................................................................................... 20
Figure 2 :Rpartition du CA par activit ....................................................................................................... 21
Figure 3 : Rpartition du CA par march ...................................................................................................... 21
Figure 4 : organigramme interne du centre de services de production de Casablanca ...................... 24
Figure 5: Fonctionnement et cycle de vie de lExtreme Programming ................................................... 27
Figure 6: Fonctionnement de la mthode Crystal Clear ............................................................................. 28
Figure 7: Fonctionnement et cycle de vie de la mthodologie Scrum ..................................................... 29
Figure 8 : Diagramme de GANTT previsionnel .................................................................................................. 32
Figure 9 : Diagramme de GANTT reel ................................................................................................................ 33
Figure 10: Architecture fonctionnelle de ProBoard .......................................................................................... 36
Figure 11: Diagramme du Cas d'Utilisation Gnral .................................................................................. 52
Figure 12: Diagramme du Cas d'Utilisation du module "Suivi des Projets" .................................................... 53
Figure 13: Diagramme du Cas d'Utilisation du Composant "Initier un Projet"............................................... 53
Figure 14: Diagramme du Cas d'Utilisation du composant"Grer Projet" ...................................................... 55
Figure 15: Diagramme de squences pour la designation dune quipe de projet ......................................... 56
Figure 16: Diagramme de squences pour la consultation de la liste des tches ........................................... 57
Figure 17: Diagramme d'Etat transition pour un risque ........................................................................... 58
Figure 18: Diagramme use-case du module "Suivi du risque" ................................................................. 59
Figure 19: Diagramme du cas d'utilisation de "Gestion du risque" ......................................................... 59
Figure 20: Diagramme de squence du cas "Cration d'un nouveau risque" ........................................ 61
Figure 21 : Diagramme du cas d'utilisation " Gestion du plan d'actions" .............................................. 62
Figure 22 : Diagramme de squence du cas "Dfinition d'un nouveau plan d'action" ........................ 63
Figure 23 : Diagramme de squence du cas " Dfinition du plan d'action depuis le catalogue" ........ 63
Figure 24 : Diagramme des cas d'utilisations "Gestion des imputations" .............................................. 64
Figure 25 : DIAGRAMME DE PACKAGE DE LAPPLICATION ....................................................................... 65
Figure 26 : Diagramme de classe general .......................................................................................................... 66
Figure 27: Architecture technique du ProBoard ............................................................................................... 69
Figure 28 : Diagramme de classe du module "Maintenance".................................................................... 78
Figure 29 : Diagramme de classe du package "Suivi des risques ............................................................. 80
Figure 30 : Diagramme de classe du package "Suivi projet" ..................................................................... 82
Figure 31 : Diagramme de classe du package " Gestion des imputations" ............................................. 83
Figure 32 : Ecran "Page d'authentification" .......................................................................................................... 87
Figure 33 : Ecran "Page d'accueil" ........................................................................................................................ 88
Figure 34 : Ecran " Dclaration d'un risque global " ............................................................................................. 88
Figure 35 : Ecran " Dfinition du plan d'actions "................................................................................................. 89
Figure 36 : Ecran " Excution du plan d'action" ................................................................................................... 90
Figure 37 : Architecture gnrale simplifie ......................................................................................................... 98
Figure 38 : Appel entre composants .................................................................................................................... 100
Figure 39 : Diagramme de classes de l'architecture ............................................................................................ 102

PAGE 12
LISTE DES TABLEAUX

LISTE DES TABLEAUX

Tableau 1 :Ples de comptences spcifiques STERIAMEDSHORE .......................................................... 23
Tableau 2 : Tableau des interactions acteurs-systeme .............................................................................. 49
Tableau 3: Tableau descriptif du composant " Initier un projet" ............................................................ 54
Tableau 4: Tableau descriptif du composant "Grer Projet" du module " Suivi des projets" ............ 55
Tableau 3: Description du cas d'utilisation "Gestion des risques" .......................................................... 60
Tableau 6: Description du cas d'utilisation "Dfinition du plan d'actions" ........................................... 62
Tableau 5 : Description du cas d'utilisation "Gestion des imputations" ................................................ 64

PAGE 13
TABLE DES MATIERES

TABLE DES MATIERES

DEDICACES ............................................................................................................................................... 4
REMERCIEMENTS .................................................................................................................................... 6
RESUME ................................................................................................................................................... 7
ABSTRACT ................................................................................................................................................ 8
......................................................................................................................................................... 9
LISTE DES FIGURES ................................................................................................................................. 11
LISTE DES TABLEAUX ............................................................................................................................. 12
TABLE DES MATIERES ............................................................................................................................ 13
INTRODUCTION ..................................................................................................................................... 17
PARTIE 1................................................................................................................................................. 18
CONTEXTE GENERAL DU PROJET ...................................................................................................... 18
CHAPITRE I : ........................................................................................................................................... 19
PRESENTATION DE LORGANISME DACCUEIL ....................................................................................... 19
I. Prsentation du groupe STERIA .................................................................................................. 19
I.1. Prsentation gnrale ....................................................................................................... 19
I.2. Evolution historique : ........................................................................................................ 20
I.3. Activits : ........................................................................................................................... 21
I.4. Partenaires : ...................................................................................................................... 21
I.5. Organisation oprationnelle :............................................................................................ 22
II. Prsentation de lentreprise SteriaMedShore :..................................................................... 22
II.1. Ple de comptences spcifiques Steria MedShore: ........................................................ 23
II.2. Structure du CSP : .............................................................................................................. 24
CHAPITRE II : .......................................................................................................................................... 25
PRESENTATION DU PROJET ................................................................................................................... 25
III. Prsentation de ProBoard ..................................................................................................... 25
III.1. Primtre du projet : ......................................................................................................... 25
III.2. Description du projet : ....................................................................................................... 25
III.3. Objectifs du projet : ........................................................................................................... 26
IV. Conduite du projet ................................................................................................................ 26
IV.1. Benchmarking des mthodes : .......................................................................................... 26

PAGE 14
TABLE DES MATIERES
IV.2. Conduite du projet ............................................................................................................ 30
IV.3. Planning du projet : ........................................................................................................... 31
PARTIE 2................................................................................................................................................. 34
ANALYSE ET CONCEPTION ................................................................................................................. 34
CHAPITRE III : ......................................................................................................................................... 35
ETUDE DE L'EXISTANT ET ANALYSE PRELIMINAIRE ............................................................................... 35
V. Analyse et critique du systme existant : .............................................................................. 35
V.1. Fonctionnalits du systme existant ProBoard : ........................................................ 35
V.2. Schmas actuels : .............................................................................................................. 37
V.2.1. Processus mtier Gestion des absences : ................................................................................ 37
V.2.2. Processus mtier Gestion des comptences : ......................................................................... 37
V.2.3. Processus mtier Suivi de projet : ......................................................................................... 38
V.2.4. Processus mtier Suivi des risques :....................................................................................... 38
V.3. Critique de lexistant ......................................................................................................... 38
VI. Exigences fonctionnelles : ..................................................................................................... 39
VII. Solution propose : ............................................................................................................... 42
V.4. Suivi de risques : ................................................................................................................ 42
V.4.1. Sous-Module 1 : Gestion des risques .......................................................................................... 42
V.4.2. Sous-Module 2 : Plan dactions ................................................................................................. 44
V.5. Suivi de projet : .................................................................................................................. 44
V.6. Gestion des imputations :.................................................................................................. 45
VIII. Exigences techniques : .......................................................................................................... 45
IX. Analyse prliminaire .............................................................................................................. 47
CHAPITRE IV : ........................................................................................................................................ 50
ANALYSE FONCTIONNELLE ................................................................................................................... 50
X. Formalisme adopt (UML) ..................................................................................................... 50
XI. Architecture gnrale de lapplication : ................................................................................ 51
XII. Modules de lapplication ....................................................................................................... 52
XII.1. Module Suivi des projets ......................................................................................... 52
XII.2. Module Suivi du risque ............................................................................................ 58
XIII. Package de larchitecture globale ......................................................................................... 65
XIV. Diagramme de classes ........................................................................................................... 66
CHAPITRE VI : ........................................................................................................................................ 67
CONCEPTION GENERIQUE ..................................................................................................................... 67
XV. Architecture Logique ............................................................................................................. 67
1) Couche de prsentation .................................................................................................................. 68

PAGE 15
TABLE DES MATIERES
2) Couche mtier ................................................................................................................................. 68
3) Couche daccs aux donnes ......................................................................................................... 68
4) Couche de stockage de donnes ..................................................................................................... 68
XVI. Modle de conception .......................................................................................................... 68
XVII. Architecture technique.......................................................................................................... 69
1) Couche prsentation ....................................................................................................................... 70
2) Couche service................................................................................................................................ 70
3) Couche daccs aux donnes ......................................................................................................... 71
4) Serveurs dapplication .................................................................................................................... 71
5) SGBD : ............................................................................................................................................ 71
XVIII. Gestion des dpendances des librairies ............................................................................ 72
CHAPITRE VII : ....................................................................................................................................... 73
CONCEPTION DETTAILLEE...................................................................................................................... 73
1- Diagrammes de squences dtailles .................................................................................. 73
1) Diagramme de squence Consulter liste des tches dun projet ............................................. 73
2) Diagramme de squence Dclarer un nouveau risque globale ................................................ 73
3) Diagramme de squence Affecter une action un collaborateur ........................................... 74
XIX. Diagrammes de classes de larchitecture globale ................................................................. 78
1) Module de Maintenance et paramtrage....................................................................................... 78
2) Module Suivi du risque.................................................................................................................. 79
3) Module Suivi du projet ............................................................................................................. 81
4) Module Gestion des imputations .............................................................................................. 83
PARTIE 3................................................................................................................................................. 84
MISE EN UVRE DU PROJET .............................................................................................................. 84
CHAPITRE VII : ....................................................................................................................................... 85
ENVIRONNEMENT DE DEVELOPPEMENT .............................................................................................. 85
XX. 1. Environnement de dveloppement .................................................................................. 85
XX.1. Eclipse ............................................................................................................................ 85
XX.2. SVN (Subversion) ........................................................................................................... 85
XX.3. JUNIT .............................................................................................................................. 85
XX.4. HPQC .............................................................................................................................. 86
XX.5. Hudson........................................................................................................................... 86
CHAPITRE VII : ....................................................................................................................................... 87
ECRANS DE REALISATION ..................................................................................................................... 87
XXI. Page dauthentification ......................................................................................................... 87
XXII. Page daccueil ........................................................................................................................ 87
XXIII. Page de dclaration dun risque globale ........................................................................... 88
XXIV. Dfinition du plan daction ................................................................................................ 88

PAGE 16
TABLE DES MATIERES
XXV. Excution du plan daction .................................................................................................... 89
XXVI. Gestion des imputations ................................................................................................... 90
CONCLUSION ......................................................................................................................................... 91
Bibliographie.......................................................................................................................................... 92
Webographie ......................................................................................................................................... 93
ANNEXES ................................................................................................................................................ 94
Annexe A : Intgration Continue ..................................................................................................... 94
Annexe B : L'architecture MOBE ...................................................................................................... 98
a. Principes techniques directeurs ............................................................................................ 98
b. Caractrisation de larchitecture logicielle ............................................................................ 99
XX.5.1. Architecture N-tiers ....................................................................................................... 99
c. Modles de conception et programmatiques ............................................................................ 99
3- Socle technique (Framework) MOBE ........................................................................................ 99
Communication entre les composants ........................................................................................ 100

PAGE 17
INTRODUCTION

INTRODUCTION

De nos jours, toute entreprise doit savoir faire preuve de flexibilit pour sadapter aux
exigences croissantes des consommateurs. Une entreprise ne peut plus fonctionner
simplement par laspect technique et financier, mais dvelopper laspect stratgique, porteur
damlioration continue et dinnovation quest dsormais lune des cls de la comptitivit et
qui va de pair avec une gestion efficace des ressources, des projets et des risques.
En effet, des tudes publies soulignent que ce sont la mauvaise gestion de projet et le
manque de visibilit sur les indicateurs cls qui sont lorigine du dpassement des cots et
du non-respect des dlais et des exigences de qualit. En gnral, cette gestion implique le
contrle des dlais, le contrle du budget et le contrle du travail des ressources humaines sur
les tches du projet. Il est donc impratif que les informations sur lavancement des projets
soient disponibles en permanence, pour que lon puisse faire face aux imprvus.
Ainsi, linstar des grandes socits de services en ingnierie informatiques (SSII), et
pour se dmarquer sur les marchs de plus en plus concurrentiels, la socit Steria MedShore
met en uvre un plan daction pour la gestion et le suivi de lvolution des activits et des
risques au sein de lentreprise.
Notre projet de fin dtudes sinscrit dans ce contexte et vise la mise en place dune
stratgie simple et efficace de gestion de projet, adapte lenvironnement et la mission de
Steria, dans le but de formaliser la gestion des ressources, dassurer la coordination des
collaborateurs et des tches, de planifier et de contrler les risques dans un souci de respect
de dlai, defficacit et de rentabilit
Le prsent rapport dcrit en trois parties lessentiel du travail ralis lors de ce projet.
La premire partie compose de deux chapitres. Elle introduit lorganisme daccueil
Steria MedShore et prsente le contexte gnral du projet ainsi que sa conduite.
La deuxime partie comporte quatre chapitres. Elle porte sur ltude de lexistant et
lanalyse prliminaire en premier lieu, puis se consacre lanalyse fonctionnelle, la
conception gnrique et celle dtaille de l'application.
La troisime partie est rserve la mise en uvre du Projet. Elle dcrit les outils de
ralisation et prsente quelques captures dcran.
A la fin du rapport, nous prsenterons, en complment, des annexes prsentant la
plateforme de l'intgration continue et l'architecture du Framework interne MOBE.

PAGE 18
CONTEXTE GENERAL DU PROJET

PARTIE 1

Cette partie prsente le contexte
gnral du projet. Elle donne en premier lieu un
aperu sur lorganisme daccueil, Steria
MedShore. Ensuite, elle dcrit lensemble du
projet: primtre, objectif, mthode de conduite
et planification.

PAGE 19
PRESENTATION DE LORGANISME DACCEUIL

CHAPITRE I :
PRESENTATION DE LORGANISME DACCUEIL

Notre stage se droule au sein de la SSI I STERI A MedShore, dont le
fonctionnement repose sur des systmes dinformation matures et linnovation
constitue le levier de performance par excellence.

I. Prsentation du groupe STERIA

I.1. Prsentation gnrale

Fonde en 1969, STERIA est la troisime SSII franaise et actuellement la sixime
SSII europenne avec un chiffre daffaires de 1.83 milliard deuros et environ
20 000 collaborateurs en 2012.
STERIA a pour objectif daccompagner ses clients dans la cration et lexploitation de
nouveaux services pour renforcer leurs avantages concurrentiels et leur leadership. Elle
sengage dans le cadre de partenariats de long terme, fonds sur la cration mesurable de
valeur, la capitalisation des meilleures pratiques, lexcellence de la qualit de service cot
optimis.
STERIA dlivre des services IT ddis aux entreprises et se positionne comme le
partenaire de confiance de la transformation d'un grand nombre d'organisations prives
comme d'administrations travers le monde. STERIA dlivre des services qui s'appuient sur
les nouvelles technologies et qui permettent aux administrations et aux entreprises d'amliorer
leur efficacit et leur rentabilit. Grce une excellente connaissance des activits de ses
clients et son expertise des technologies de l'information et de l'externalisation des processus
mtiers de l'entreprise, STERIA fait siens les dfis de ses clients et les aide dvelopper des
solutions innovantes pour y faire face. De par son approche collaborative du conseil, STERIA
travaille avec ses clients pour transformer leur organisation et leur permettre de se focaliser
sur ce qu'ils font le mieux. Les 20 000 collaborateurs de Steria, rpartis dans 16 pays,
prennent en charge les systmes, les services et les processus qui facilitent la vie quotidienne
de millions de personnes chaque jour.

PAGE 20
La figure suivante prsente la cartographie du groupe Steria travers le monde.

Figure 1 : Cartographie du groupe Steria
I.2. Evolution historique :

Le 2 septembre 1969, JeanCarteron crait Steria (Socit dtude et de Ralisationen
Informatique etAutomatisme), avec commecaractristiques la crativit, lactionnariat
salari,lindpendance et lambition internationale. Le premier contrat de Steria a t sign en
octobre 1969avec leministre de lconomie et des Finances franais,afin daccompagner ce
dernier dans sa politique deRationalisation des Choix Budgtaires.
La croissance de Steria repose sur une croissance organique et des acquisitions stratgiques
dont les 3 plus rcentes ont assis la dimension internationale de Steria : Integris en 2001,
Mummert en 2005 et Xansa en 2007.
En 40 ans, Steria est passe du statut de PME celui de Groupe international avec 19 000
collaborateurs dans 16 pays.Elle est devenue un acteur incontournable de la simplification et
de lamlioration de nombreux usages de la vie quotidienne. En innovant chaque jour
davantage, lentreprise a su appuyer et acclrer les changements dun monde en perptuelle
mutation et jouer un rle cldans la transformation des entreprises et administrations et, au-
del, de la socit.

PAGE 21
I.3. Activits :

Le groupe Steria figure parmi les principales socits de services informatiques franaises.
Elle a structur son activit autour de secteurs de marchs cibls : secteur public et sant,
banque et assurance, tlcommunications, nergie-transport-industrie.
Son activit englobe : les prestations de conseil et dintgration de systmes, les prestations
dinfogrance (supervision, administration et exploitation des infrastructures informatiques,
prestations d'assistance technique, etc..) et les exploitations des processus mtiers
(exploitation des fonctions finance, administration, ressources humaines, etc.).

Figure 2 :Rpartition du CA par activit

Figure 3 : Rpartition du CA par march
I.4. Partenaires :
Steria a des relations troites avec des leaders technologiques, comme Microsoft, Oracle,
IBM, SAP et HP lui permettent de garantir ses clients des solutions fiables pour des rsultats
durables. Ensemble, ils faonnent le fonctionnement quotidien des organisations, optimisant
les performances de leurs solutions et processus. Ces partenaires respectent l'importance
quelle et ses clients accordent l'indpendance de ses solutions envers leurs plates-formes.
62%
30%
8%
Rpartition du CA par activit
Prestations de conseil et
d'intgration de systmes
Prestations d'infogrance
Exploitation des processus
mtiers
38 %
27 %
24 %
4 %
7 %
Rpartition du CA par march
Secteur public
Finance
Energie-Tlcoms-Transport
Commerce de dtail
Autres

PAGE 22
I.5. Organisation oprationnelle :

Lorganisation oprationnelle du Groupe mise en uvre vise supporter les principes cls
suivants :
Une proximit forte avec les clients visant favoriser flexibilit, ractivit et
esprit dinitiative ; ce principe a conduit le Groupe privilgier la dimension
gographique comme dominante dans son organisation ;
Une organisation industrielle globale, gage defficacit, de qualit et de comptitivit ;
Une capacit promouvoir la transversalit des offres et des domaines dexcellence
entre les diffrentes zones gographiques ;
Une mutualisation optimale des ressources et moyens engags ;
Une intgration forte entre les fonctions supports et les quipes oprationnelles
favorisant une gestion efficace des risques.
Lorganisation oprationnelle en place sarticule autour des quatre dimensions : le comit
excutif du groupe, les entits gographiques, les organisations transversales groupe de
support au business et les directions fonctionnelles

II. Prsentation de lentreprise SteriaMedShore :

Lors de sa cration STERIAMEDSHORE tait le fruit dune jointe venture dtenue parts
gales par FINANCECOM et STERIA jusqu la fin 2011 o le groupe STERIA a prit le
contrle de STERIAMEDSHORE. Les principaux objectifs de sa cration sont :

Doter le groupe STERIA dune entit forte NEARSHORING francophone.
Disposer terme dun rservoir de 500 ingnieurs en moins de 5 ans.
Faire de cette entit une usine rentable, industrialise et fournissant un service de
qualit.
Faire de cette entit une source de valeur ajoute pour le Groupe et pour le March
Local avec pour ambition dimplmenter, les projets locaux en liaison avec les
secteurs mtiers du Groupe STERIA.
Lignes de force de la stratgie sectorielle.
Positionnement de leadership sur le nearshoring francophone / hispanophone.
March potentiel trs important : 8 -10 Mrd Euros.

PAGE 23
Stratgie de dveloppement long-terme quilibre sur 4 axes (formation, cadre
sectoriel, infrastructures, promotion).
Stratgie dmergence rapide sur les trois prochaines annes.
Dveloppement de zones spciales ddies loffshoring prsentant tous les facteurs
cls de succs (CasaShore / RabatShore / TangerShore)
II.1. Ple de comptences spcifiques Steria MedShore:

La nouvelle entit STERIAMEDSHORE profite pleinement de lexpertise du Groupe STERIA
en matire de processus mtiers, de technologies et de processus industriels. Au sein de cette
structure industrielle, STERIAMEDSHORE sera focalise autour des activits de tierce
maintenance applicative, dintgration de systmes dans les nouvelles technologies et dans
lintgration de la suite applicative Oracle et SAP. Ci-dessous un tableau rcapitulatif des
principaux ples de comptences STERIAMEDSHORE.
Tableau 1 :Ples de comptences spcifiques STERIAMEDSHORE

PAGE 24
II.2. Structure du CSP :

Le centre de services de production de Casablanca, est un centre industriel organis et align
avec les CSPs France.
Cette figure prsente lorganisation interne du CSP :

Dans le prsent chapitre, nous avons prsent lorganisme daccueil en termes dactivits et
dorganisation. Le chapitre suivant prsente le primtre du projet, sa description et ses objectifs
Figure 4 : organigramme interne du centre de services de production de Casablanca

PAGE 25
PRESENTATION DU PROJET

CHAPITRE II :

Ce chapitre dcrit dans son ensemble, les circonstances du projet, son primtre
et ses objectifs. Par la suite, il fera lobjet de la prsentation de la dmarche de
conduite du projet et le planning du travail tablis.

III. Prsentation de ProBoard

III.1. Primtre du projet :

Steria conoit un ensemble de solutions informatiques, des projets de type standards
ainsi que des projets de Tierce Maintenance Applicative (TMA), qui ne sont quun ensemble
de prestations ou dvolutions de projets. Pour chaque activit, il faut raliser un Reporting ou
un tableau de bord pour faciliter la tche de la gestion du projet au Manager et aux Chefs de
Projets (CPs). Ceci se fait travers le suivi rgulier de lvolution des tches affectes aux
collaborateurs et leurs imputations.
III.2. Description du projet :

Le projet ProBoard s'inscrit dans le cadre des efforts dploys par
STERIAMEDSHORE pour se doter doutils susceptibles de renforcer son efficacit et sa
rentabilit. Il consiste intgrer une application de suivi des projets et ressources de la socit
(gestion des activits, imputations et risques) et vise organiser de bout en bout le bon
droulement des projets et activits au sein de STERIAMEDSHORE.

Le projet auquel nous allons contribuer, consiste en la refonte dune application
intranet qui permet le suivi des ressources et des activits au sein de Steria Med Shore. Cette
refonte prsente la mise en place dun nouveau processus de suivi et gestion des projets , de
suivi, contrle et traitement des risques et de la gestion des imputations quotidiennes des
collaborateurs en vue de garantir la transparence, la visibilit globale et rgulire sur les
activits, ainsi que de faciliter la tche de la conduite et la gestion du projet aux chefs de
projets et au manager au sein de la socit.
Nous avons donc choisi comme nom de lapplication ProBoard EV.2 qui se rfre
lapplication existante.

PAGE 26
III.3. Objectifs du projet :

Le projet ProBoard EV.2 vise raliser les objectifs suivants:

- Optimiser la gestion des activits oprationnelles de STERIAMEDSHORE :
Disposer dun outil technologique rpondant aux besoins oprationnels qui va
amliorer le rendement interne en garantissant un gain de temps et de ressources remarquable.
De plus, ce systme permettra aux collaborateurs de rechercher linformation pertinente dont
ils ont besoin en un temps rduit.
- Automatiser les supports de suivi des projets et ralisations :
La gnration de fiches descriptives des projets contenant les informations cls, la
gnration des diagrammes de Gantt des projets, permettra STERIAMEDSHORE de rduire
ses cots en termes de temps et ressources. De plus, ceci contribuera une gestion centralise
et optimise des ressources.
- Disposer dune base de donnes pour tous les projets STERIAMEDSHORE.
- Disposer d'une rfrence solide des risques dclars et traits au sein de la socit.
- Disposer dun tableau de bord synthtisant ltat davancement de tous les projets et
un autre prsentant les disponibilits des collaborateurs.
- Disposer dun systme de Reporting pour la gnration des tats de sorties et la prise
de dcision.
- Disposer dun systme de gestion des imputations des collaborateurs afin de suivre
l'volution des tches et des actions qui leur sont affectes.
IV. Conduite du projet

La conduite de projet aussi appele gestion de projet est une dmarche visant
structurer, assurer et optimiser le bon droulement d'un projet suffisamment complexe.
IV.1. Benchmarking des mthodes :

Afin dassurer le bon droulement des diffrentes phases de la ralisation et mise en
place de notre projet, il sest avr ncessaire de sorganiser et donc de choisir une dmarche
de travail. Pour ce faire, nous avons effectu une tude comparative des diffrentes mthodes
agiles afin de pouvoir effectuer notre choix.

PAGE 27
Extreme Programming ( XP) :

Extreme Programming est une mthode agile plus particulirement oriente sur
l'aspect ralisation d'une application, sans pour autant ngliger l'aspect gestion de projet. XP
est adapt aux quipes rduites avec des besoins changeants.
Cette mthode repose sur des cycles rapides de dveloppement (des itrations de
quelques semaines) dont les tapes sont les suivantes :
Une phase d'exploration dtermine les scnarios client qui seront fournis pendant cette
itration ;
L'quipe transforme les scnarios en tches raliser et en tests fonctionnels ;
Chaque dveloppeur s'attribue des tches et les ralise avec un binme ;
Lorsque tous les tests fonctionnels passent, le produit est livr.
Le cycle se rpte tant que le client peut fournir des scnarios livrer. Gnralement le
cycle de la premire livraison se caractrise par sa dure et le volume important de
fonctionnalits embarques. Aprs la premire mise en production, les itrations peuvent
devenir plus courtes (une semaine par exemple).

Figure 5: Fonctionnement et cycle de vie de lExtreme Programming

PAGE 28

Crystal clear :

Crystal Clear est un cadre mthodologique trs fortement adaptable aux spcifications
de chaque projet. Ces mthodes ont t dveloppes par Alister Cockburn.Crystal reste trs
souple tant au niveau des procdures suivre que des normes utiliser.
Elle possde une procdure dcoupe en diffrentes tapes :
La spcialisation consiste observer les utilisateurs dans leur travail pour mieux
connatre leurs besoins et leur environnement. Ensuite, les diffrents cas d'utilisation
sont classs par ordre de priorit en collaboration avec les utilisateurs, ce qui permet
de savoir quelles fonctionnalits ont le plus de valeur et doivent tre dveloppes en
premier.
Une bauche de conception est ralise au tout dbut du projet, cela inclut les choix
des technologies utiliser et implique une bauche d'architecture.Le planning consiste
prvoir vers quelles dates les itrations vont se suivre, il est recommand de dfinir
des itrations d'une longueur de 2 3 mois, chacune produisant un produit livrer
fonctionnel.
Les itrations, c'est au cours de cette phase que se fait la ralisation proprement dite de
l'application, en suivant un ordre de hase.

Figure 6: Fonctionnement de la mthode Crystal Clear

PAGE 29

Scrum :

Scrum est une mthode agile ddie la gestion de projets. Elle est issue des mthodes
incrmentales (telles que le modle en spirale) qui permettent de matriser une production
planifie.
La mthode s'appuie sur le dcoupage d'un projet en incrments, nomms sprint , ainsi
que l'auto-organisation de l'quipe de dveloppement. Les sprints peuvent durer entre
quelques heures et un mois (avec une prfrence pour deux semaines). Chaque sprint
commence par une estimation suivie d'une planification oprationnelle. Le sprint se termine
par une dmonstration de ce qui a t achev, et contribue augmenter la valeur d'affaires du
produit. Avant de dmarrer un nouveau sprint, l'quipe ralise une rtrospective : elle analyse
ce qui s'est pass durant ce sprint, afin de s'amliorer pour le prochain.

Scrum dfinit trois rles :
Product Owner : Il est le Propritaire du produit (Product Owner) est le reprsentant
des clients et des utilisateurs. Son objectif est de maximiser la valeur du produit
dvelopp.
ScrumMaster : Le ScrumMaster est responsable de la mthode. Il doit s'assurer que
celle-ci est comprise, et bien mise en application. Ce n'est pas un chef de projet, ni un
intermdiaire de communication avec les clients.
Dvelopper : L'quipe ne comporte pas de rles prdfinis, elle est auto-
organise et pluridisciplinaire.

Figure 7: Fonctionnement et cycle de vie de la mthodologie Scrum

PAGE 30
IV.2. Conduite du projet
Un processus de dveloppement dfinit une squence dtapes, en partie ordonne, qui
concoure lobtention dun systme logiciel nouveau ou lvolution dun systme existant.
Ce processus a pour objectifs de produire des solutions informatiques de qualit rpondant
aux besoins des utilisateurs dans des priodes et des cots prvisibles.
De ce fait, ladquation du projet au processus de dveloppement peut largement affecter
le sort dun projet informatique.
Pour viter tout risque, nous avons suivi le processus propos par STERIAMEDSHORE
qui sadapte le mieux notre projet, il est inspire en quelque sorte du cycle en b du processus
UP et de la mthodologie agile de SCRUM, que nous y trouvons en loccurrence la notion de
release, et du Product Owner qui est le MOA de lapplication cible.
La particularit de B par rapport aux autres mthodes formelles c'est qu 'elle couvre tout
le cycle de vie du logiciel dvelopper dans un cadre formel uniforme. L'apport de la preuve
dans B prsente l'avantage que le logiciel produit respecte la spcification puisque il en
dcoule totalement .Elle a toutefois linconvnient de ne pas fournir de guide de ralisation
aussi prcis et mr que certaines mthodes du march et cest dans ce but que les tudes de
cas peuvent tre dun grand intrt dans lutilisation de la mthode.
En effet, notre projet prsente une difficult technique et fonctionnelle leve. La
difficult technique rside dans lutilisation des technologies pointues. Quant la difficult
fonctionnelle, elle se manifeste essentiellement dans ltude de lexistant et la description des
fonctionnalits riches du systme, ainsi que les changements frquents des exigences du
client. Cette description devra porter sur les multiples fonctionnalits offertes par le systme
de gestion et suivi des projets.
Pour faire face cette complexit, et afin de faciliter le dveloppement et rduire le taux
danomalies que lapplication peut connaitre nous avons choisi le processus cit ci-dessus.

PAGE 31
IV.3. Planning du projet :
La planification de projet est lune des tapes primordiales qui consiste dterminer et
ordonner les tches, et estimer leurs charges pour sassurer que le projet va atteindre ses
objectifs. Elle consiste tablir un planning pour les phases constituant le cycle de
dveloppement de projet et de respecter ainsi la contrainte du dlai.
Des runions avec les responsables du projet ont t programmes hebdomadairement.
Elles constituent des jalons de contrle du projet et permettent dvaluer ltat davancement,
dy suggrer des ides ou des modifications, et dajuster les drives.

Le diagramme de Gantt reflte la planification des tches de notre projet, o lon a
rpertori les phases majeures. Ci-aprs nous avons mis le planning final suivi au cours de
notre projet de fin dtude.

PAGE 32
Gantt prvisionnel

Figure 8 : Diagramme de GANTT previsionnel

PAGE 33
Gantt Rel

Figure 9 : Diagramme de GANTT reel

ANALYSE ET CONCEPTION
PAGE 34

PARTIE 2

Cette partie traite les
deux phases les plus importantes et les
plus critiques du cycle de dveloppement
logiciel : lanalyse et la conception.

PAGE 35

ETUDE DE L'EXISTANT ET ANALYSE PRELIMINAIRE

CHAPITRE III :

Dans le prsent chapitre sont exposs lanalyse du systme existant, une critique
base sur cette analyse, les propositions juges oprationnelles pour remonter
en performance cet existant, ainsi quune analyse preliminairevisant a la
conception.

V. Analyse et critique du systme existant :

Les enjeux de la mise en uvre d'un audit de l'existant sont multiples et rpondent
des problmatiques de mise en conformit et de prvention des risques. En effet, le diagnostic
de l'existant nous a permis de bien dceler les dficiences, comprendre les contraintes de
ralisation et dimplmentation et de dvelopper par la suite une proposition de solution.

V.1. Fonctionnalits du systme existant ProBoard :

Pour assurer la qualit du travail et le bon droulement des projets, Steria Medshore a
dcid de mettre en place le projet PROBOARD pour une solution informatique de gestion et
de suivi de projets, une solution qui a pour finalit loptimisation et lautomatisation des
activits de suivi des projets et ressources de la socit.
ProBoard est un outil interne Steria MedShore. Il se prsente comme une
application Web accessible sur le rseau interne de Steria MedShore, laquelle il faut
s'authentifier pour accder la gestion de son activit.
ProBoard est ax autour de cinq modules, savoir : la Maintenance, la Gestion des
absences, la Gestion et Suivi des Projets, la Gestion et Suivi des risques, et la Gestion des
Comptences des collaborateurs de Steria MedShore.
Le schma suivant dtaille les composants de chaque module :

PAGE 36


Figure 10: Architecture fonctionnelle de ProBoard

Module Maintenance: permet le paramtrage de lapplication. En dautres termes, la
gestion des utilisateurs, la gestion des jours fris et la dfinition des types de tches
standards lis tout type de projets.

Module Gestion des absences : Ce module permet au Manager de saisir et d'archiver les
absences des collaborateurs et visualiser leurs disponibilits via un diagramme de Gant.
Cette dernire fonctionnalit reste toujours indisponible.

Module Gestion des comptences : permet de dfinir un ensemble de comptence que
Steria Medshore requiert pour la mise en place et pour la ralisation de ses projets, ainsi
Gestion des utilisateurs
Gestion des types de tches
Gestion des jours fris
Maintenance
Rapport Absence/Maladie
Disponibilit des collaborateurs
Gestion des absences
Gestion des comptences
Affectation des comptences aux collaborateurs
Suivi des comptences
Gestion des Projets
Dfinition des tches
Dfinition des comptences
Affectation des tches aux collaborateurs
Tableau de Bord des projets
Suivi des Projets
Gestion des risques
Qualifications des risques
Plans d'action
Suivi des risques
Suivi des Risques

PAGE 37

le manager ou le RP peut affecter chaque collaborateur les comptences quil en a avec
un niveau de maitrise.

Module Gestion des Projets : ce module, est considr le cur de l'application, de par sa
permission de grer tous les projets et de suivre de bout en bout lavancement et
lvolution de ces derniers de la cration jusqu la clture.
Un tableau de bord est conu pour afficher la progression des projets et de leurs tches.
Cependant, cette fonctionnalit na pas t implmente dans lapplication.

Module Suivi des risques : ce module est mis en place, pour grer dabord les risques
globaux de la socit et les risques lis un ou plusieurs projets, puis dfinir des plans
dactions afin de pouvoir traiter et contrler les risques qualifis.

V.2. Schmas actuels :

V.2.1. Processus mtier Gestion des absences :

La demande de cong au sein de Steria MedShore se droule comme suit : Le
collaborateur imprime et remplit le formulaire ddi, pour le dposer auprs du secrtariat
aprs dtre sign par son chef du projet, conformment la hirarchie tablie. Le secrtariat
prend en charge le traitement et le suivi de la demande. La rponse est retransmise
lintress une fois la demande est tudie par le manager et la responsable des ressources
humaines
En cas dagrment, le manager passe saisir le cong du collaborateur au niveau du
systme existant pourvue de larchiver en renseignant les informations suivantes :
Date dbut,
date fin
date retour au bureau,
Nature de labsence.

V.2.2. Processus mtier Gestion des comptences :

La gestion des comptences consiste alimenter la base des donnes par les
comptences requises pour la mise en place des projets au sein de Steria MedShore. La
procdure est assure par le manager et le chef de projet, afin de disposer d'une base de

PAGE 38

rfrences solide pour faciliter la dsignation de lquipe du projet et laffectation des
comptences aux collaborateurs.

V.2.3. Processus mtier Suivi de projet :

Le processus suivi de projet est entam par la cration dun projet. Pour se faire le
manager dsigne en premier lieu un chef et une quipe de projet, ensuite il dfini les tches et
les comptences requises par ce dernier.
Le chef de projet ainsi choisi, affecte les tches dfinies aux membres de lquipe et
contrle rgulirement le droulement du projet et lexcution des tches.

V.2.4. Processus mtier Suivi des risques :

Les fonctionnalits du processus "suivi des risques" dans son ensemble sont
restreintes; Elles ne permettent que la dclaration des risques en liaison avec des projets bien
spcifiques. Cette action consiste renseigner toutes les informations concernant le risque en
question. Une fois le risque est cr, le manager est notifi pour le qualifier ou le rejeter, S'il
est qualifi, alors, le CP passe la dfinition de son plan dactions et l'affectation de chaque
action aux personnes comptentes.
Quant aux collaborateurs, ils traitent et clturent les actions dont ils sont responsables,
et ceci aprs validation de leur CP.

V.3. Critique de lexistant

Aprs lanalyse effectue, le systme existant prsente plusieurs dfaillances :
En terme de gestion des ressources, linterface rapport absences /maladies/ congs
ne prsente quune liste affichant les collaborateurs absents et la nature de leurs
absences, les demandes de ces absences sont dclares et saisies manuellement par le
Manager/CP, sans donner la possibilit aux collaborateurs daccder cette page
pour saisir leurs propres absences ou deffectuer la simple consultation. En revanche,
la demande des congs nest pas automatique, elle doit suivre un processus
purement manuel commenant par une demande manuscrite et passant par un
workflow de validation selon tous les niveaux hirarchiques.

PAGE 39

Linterface disponibilits des collaborateurs na pas encore vu le jour, empchant par
la suite lexploitation des disponibilits des collaborateurs lors de laffectation des
tches ou la dsignation des membres dquipe dun projet.

Au niveau du pilotage, la trace de lvolution des projets, ainsi que le suivi des
risques par ses actions correctives et prventives ne fait pas lobjet de ce qui tait
spcifi dans les besoins fonctionnelles de la premire version de lapplication, la
ralisation des interfaces permettant de faire la visualisation de lvolution ou de la
gestion des projets et des risques, est quasi absente dans la totalit de ce qui a t
conu et ralis, et la manuvre se fait toujours via des feuilles Excel. Une telle
tche reste fastidieuse, et demande un taux non ngligeable de temps et defforts
pour un Manager/CP pour concevoir le tableau de bord et le reporting sur
lensemble des projets et risques.
Lintgration du tableau de bord aux systmes de gestion de lorganisation et la
mise en place initiale des indicateurs demeure indispensable pour assurer le bon suivi des
projets et permet de concrtiser la mesure de lvolution des projets, ces notions sont
absentes dans lexistant en question, do la ncessit de les concevoir et les raliser.
En effet, un tableau de bord de gestion est un chantillon rduit dindicateurs
permettant aux gestionnaires de suivre lvolution des rsultats, suivre les carts par rapport
des valeurs de rfrence (objectifs fixs, normes interne ou externes, rfrences statistiques),
le plus possible en temps rel, en se concentrant sur ceux quil considre comme les plus
significatifs. Un indicateur est un paramtre ou une combinaison de paramtres qui reprsente
ltat ou lvolution dun systme, il est choisi en fonction des leviers daction qui seront
utiliss pour prendre dventuelles mesures correctives et donc en fonction de dcisions
prendre dans le futur.
VI. Exigences fonctionnelles :

Le scnario de mise en uvre adopt consiste mettre niveau le systme actuel en
ajoutant de nouvelles fonctionnalits. Ce systme doit rpondre aux besoins des clients Steria
MedShore en termes de transparence et de visibilit, et aussi aux besoins des responsables
hirarchiques en termes de pilotage et management de lquipe.
Nous avons donc choisi comme nom de lapplication ProBoard EV.2 qui se
rfre lapplication existante.

PAGE 40

Module Suivi de Projet

Le suivi et la gestion de projet est une dmarche qui vise structurer, assurer et
optimiser le bon droulement d'un projet simple ou suffisamment complexe.
Au sein de Steria MedShore on gre deux types de projets :
Projets Standard : ensemble des tches entreprendre avec un dbut et une
fin afin de rpondre un besoin dfini dans les dlais fixs.
Projet Complexe: dcompos en lots ou en sous-projets ou encore en
volution afin d'obtenir des sous-ensembles dont la complexit est plus
facilement matrisable.
Le dcoupage d'un tel projet en sous-ensembles maitrisables est essentiel la
conduite du projet et donc son aboutissement et sa russite.
Pour cela, ce module doit :
permettre au manager au moment de linitialisation dun projet davoir un
ensemble de modles (templates) pour crer diffrentes vues : projet standard,
projets complexe en dfinissant les niveaux de complexit (sous projet,
volutions, tches).
Intgrer les quipes CRUD: Create, Read, Update, Delete pour tout type cr et
des fonctions de recherche multicritres pour l'affectation des tches et des
comptences.

Prsenter aux CPs un tableau de bord de lavancement du projet par rapport
la charge jours/homme fixe pour ce dernier, et de la visibilit des travaux et
tches de chaque collaborateur.

Permettre au manager de piloter l'activit et vrifier aisment le respect des
engagements pris pour tous les projets de la socit via un tableau de bord.
Module suivi de risque:

Lanalyse des risques constitue le cur de la dmarche de gestion et suivi des
risques. Elle a pour finalit lidentification, la formalisation et lestimation de chaque

PAGE 41

composante du risque (origine/probabilit d'occurrence/impact), afin dvaluer le risque et
dapprcier son niveau, dans le but de prendre des mesures adquates.
Vu son importance, ce module est divis en deux sous-modules :
1) Gestion des risques
Consiste :
Mettre en place un workflow de gestion des risques bas sur la dmarche adopte par
la socit.
Concevoir et mettre en place un catalogue de risques et propositions des actions
prventives et correctives.
Elaborer un tableau de bord pour assurer le suivi de lvolution des risques qualifis.
Prsenter au manager un Reporting consolidant tous les indicateurs de pilotage.
Intgrer les quipes CRUD et les fonctions d'exportations des rsultats vers plusieurs
formats notamment des fiches Excel.
2) Plan dactions
Cette partie du module consiste :

Dvelopper une interface de dfinition des plans d'actions lis aux risques qualifis.
Mettre en place un tableau de bord de suivi des actions.
Module Gestion des imputations :

Afin de suivre l'volution des projets, et grer l'avancement des tches et des actions
agissant sur les risques en cours de traitement, la gestion des charges consommes des
collaborateurs sur leurs travaux est primordiale. C'est pour cela que nous avons propos aprs
l'tude de l'existant d'intgrer le module de gestion des imputations qui va assurer:

La saisie des imputations hebdomadaires,
La saisie des estimations de charge,
Le contrle des charges et le respect du planning.

PAGE 42

VII. Solution propose :

V.4. Suivi de risques :

V.4.1. Sous-Module 1 : Gestion des risques

La consultation du catalogue:

Le catalogue est une sorte de base de donnes dcisionnelle qui jouera le rle d'une
rfrence solide pour l'ensemble des chefs de projets pour identifier et contrler les diffrents
risques et leurs rsolutions dj traites. Il peut tre aliment par le risque et son plan
dactions, proposs en candidat catalogue, aprs validation du manager.
La consultation du catalogue permet au CP de slectionner le risque sil y figure, de
passer en revue les actions prsentes ou de proposer de nouvelles actions aprs avoir ajout
les informations complmentaires concernant le risque.

La dclaration d'un risque:

Deux types de risque dclarer :
Risque global : Dclar par le manager et il est par dfaut ltat qualifi.
Risque li un projet : Dclar par le C.P qui choisit le projet concern parmi
lensemble des projets quil chapeaute.

Le processus de dclaration dun risque li un projet prsente la possibilit de
consulter le catalogue des risques afin de faciliter lidentification ou la formalisation du
risque, ou de procder directement par lajout dun nouveau risque.
La consultation du catalogue permet au CP de slectionner le risque sil y figure, de
passer en revue les actions prsentes ou de proposer de nouvelles actions aprs avoir ajout
les informations complmentaires concernant le risque.
Si le catalogue ne contient pas le risque en question, le CP se redirige vers le
formulaire dajout qui doit tre rempli.
Lorsqu'on ajoute un risque depuis le catalogue, chaque C.P aura la main pour ajouter
des propositions de prventifs, correctifs et de surveillance.
Cette dmarche est lorigine des propositions du CP mettant en vidence les actions
prventives, correctives ou de surveillance dans le but dagir sur le risque.

PAGE 43

Aprs avoir termin la procdure de dclaration, le CP peut proposer lalimentation du
catalogue par le risque dclar qui sera valide ou non par le manager.
On se retrouve au terme de cette phase avec un risque en tat ouvert. Par ailleurs une
notification est envoye au manager pour qualifier ou rejeter le risque dclar.
Le manager, procde dabord par une estimation des cots des actions proposes.
Deux cas de figures se prsentent :

Les actions juges ralisables sont valides, avec lventuelle possibilit de
proposer dautres actions, le cas chant, le risque est qualifi et une
notification est envoye ce propos au CP qui par la suite passe laffectation
des actions aux collaborateurs.
Le risque est rejet dans sa globalit.

Chaque collaborateur traite son action, et impute rgulirement pour permettre au CP
dassurer le suivi et de clturer le risque lorsque toutes les actions sont traites et valides.
Les risques globaux sont dclars et contrls selon le mme processus expliqu ci-
dessus par le manager.

Qualification des risques:

A travers un tableau dtaill des risques dclars, le manager a la possibilit de
visualiser tous les risques dclars en vue de pouvoir les qualifier ou les rejeter.
Au cours de la qualification, il peut slectionner les actions qu'il voit importantes ou
les modifier.

Tableau de bord :

Il va permettre aux CPs de suivre l'volution des actions, de les valuer et de les
valider pour clturer le risque en cours afin de permettre un suivi rgulier.
Il va servir le manager pour voir l'volution du traitement des risques.

PAGE 44

V.4.2. Sous-Module 2 : Plan dactions
Plan d'action:

La dfinition des plans dactions vient aprs la qualification des risques. Cette tche
concernera le dveloppement dune interface dajout dactions prventives/correctives en
sparant deux cas de figure :
Si le risque est dclar en se rfrant au catalogue, les CP vont visualiser laide de
linterface dveloppe les actions proposes et auront la main dajouter dautres et les affecter
aux collaborateurs.
Dans lautre cas, les C.P auront ajouter des nouvelles actions via un formulaire
dajout et les affecter aux collaborateurs.
Tableau de suivi des actions :

Ce tableau va permettre aux collaborateurs dune part de visualiser les actions qui
leurs sont affectes et, dautre part de renseigner la charge quotidienne en jour/ homme en
prcisant le reste faire des actions.
Le suivi des actions sera li au suivi des risques pour assurer le contrle global du
risque.

V.5. Suivi de projet :

Cration du projet

Seul le manager a le privilge de crer un projet au sein de la socit. Cette dmarche
dbute par la slection du type du projet crer.Si le type slectionn est un projet standard.
Le manager se redirige vers un formulaire dajout contenant un ensemble dinformations
renseigner. Si le type slectionn est un projet complexe:Le manager se redirige vers la mme
page du formulaire dajout.
Aprs la saisie des informations et la validation dajout, le manager se redirige vers la
page concernant lajout de ses projets et remplit les informations ncessaires, il dfinit aussi
les quipes de travail et dfinit des volutions.
MAJ du projet

Le manager et le chef de projet peuvent grer un projet aprs sa cration, accder aux
options: lister, modifier, supprimer et archiver.

PAGE 45

Le manager gre tous les projets existants alors quun CP ne peut grer que les projets
dont il est responsable.
Affectation

Aprs la cration dun projet, dun sous projet ou dune volution, le manager passe
affecter lquipe du projet lensemble des tches et actions, pour ce faire:
Il peut faire une recherche des collaborateurs disponibles dont le profil rpond aux
comptences requises pour ce projet. En outre, Il peut forcer laffectation de certains
collaborateurs nayant pas le profil exige si un besoin sexprime ce niveau.
Tableau de bord

Le tableau de bord permet une visibilit globale sur lvolution de toutes les activits
au sein de la socit.

V.6. Gestion des imputations :

CRA hebdomadaire

Ce tableau est ddi aux collaborateurs afin de renseigner leurs charges
hebdomadaires, et mentionner le reste faire.
Cest un compte rendu dactivits qui permet aux CPs de contrler les charges
consommes et de respecter les dlais fixs.

VIII. Exigences techniques :

Pour rpondre aux besoins du client et satisfaire les spcifications fonctionnelles,
lapplication doit remplir des exigences techniques que nous dtaillons par la suite.
Charte graphique :

Puisque la mise en scne et lhabillage marketing participent au succs de n'importe
quel projet, nous avons cr une charte graphique de convention pour rpondre aux besoins et
pour satisfaire les exigences du client.

PAGE 46

Architecture et technologies utilises :

Utiliser le Framework darchitecture et les technologies interne de la socit qui
reprsente une capitalisation du savoir-faire de lentreprise dans le but de contribuer son
dveloppement dun ct, dautre cot de pouvoir exploiter les fonctionnalits dj existante
afin de ragir rapidement aux besoins des clients, d'o la ncessit d'utiliser larchitecture et
les technologies internes de la socit.
Exigences de qualit :

- Rapidit et efficacit : minimiser lutilisation des ressources avec une consommation
optimale de la mmoire, et une rapidit lors des interactions homme machine.
- Robustesse : exactitude des rsultats obtenus avec une maitrise des fautes de
lutilisateur.
- Maintenabilit, rutilisabilit et volutivit : possibilit dajouter ou de dvelopper
facilement des fonctionnalits existantes, ainsi quune rutilisation du module de
paramtrage.
Traabilit

La gestion de la traabilit est le fait de donner lutilisateur la possibilit de savoir,
nimporte quel moment de la transaction, qui a fait quoi ? Et quand ? Cest--dire, connatre le
dernier utilisateur ayant modifi des informations sur nimporte quelle entit mtier ainsi bien
que lutilisateur qui la ajout au systme.
Navigabilit

Lapplication doit disposer tout dabord dun menu simple, respectant la rgle de
laccs linformation en trois cliques, engendrant lensemble des oprations qui peuvent
servir lutilisateur pour mieux interagir avec lapplication, notamment avec la base de
donnes.
Historisation

La mise en place dun systme dhistorisation des donnes est souvent la premire
tape incontournable pour mettre en place des systmes capables dexploiter et de transformer
ces donnes en informations interprtables.
Lhistorisation se fait de la manire suivante :
- Historisation de toute information avec une priode de validit.

PAGE 47

- Historisation des oprations effectues par un utilisateur sur lensemble des entits qui
lui sont directement lies.
Scurit

La scurit sappuie sur deux notions principales, lauthentification des utilisateurs et
la gestion de leurs autorisations, auxquelles se greffe un vocabulaire spcialis :
- Authentification : vrification quun utilisateur est bien la personne quil prtend tre.
Cette vrification seffectue laide dun couple identifiant/mot de passe.
- Autorisation : vrification quun utilisateur authentifi a la permission de raliser une
action. Un utilisateur possde gnralement un ensemble dautorisations, qui peuvent tre
gres par profil pour plus de facilit.
Afin de matriser les risques lis la scurit de l'application, la mise en place dune
solution scurise avec les technologies rcentes est obligatoire, do la ncessit de faire une
migration du Framework ACEGI utilis dans larchitecture existante de la socit vers la
version la plus rcente SPRING SECURITY 3.1.0.

IX. Analyse prliminaire

La phase d'analyse prliminaire a pour objectifs de bien cerner le sujet d'une part et de
dlimiter le primtre du projet d'autre part. Cest une tape dlicate puisque ce nest quune
manire de tracer la cartographie des composants du systme dvelopper.
Identification des profils des acteurs

Un acteur, reprsente le rle dune entit externe (utilisateur humain ou non) et qui
interagit avec le systme, par le biais des messages et donnes changes.
Dans ce systme interviennent les acteurs suivants :

Le Manager : est le responsable du fonctionnement global de toutes les activits au sein de
la socit, il gre les ressources aussi bien humaines que matrielles.
Le collaborateur : est dfini comme lentit la plus profonde de la hirarchie.
Il existe plusieurs profils de collaborateurs :
Le Chef dun projet : cest le responsable du bon droulement dun projet lui est affect, il
doit grer les tches de son quipe et les planifier. Il doit dclarer et grer les risques lis

PAGE 48

ses projets. Etant proche des membres de son quipe, il doit surveiller leur charge de
travail, et lvolution de son projet et risque.
Larchitecte technique: il possde des connaissances sur de nombreuses technologies, il
dfinit larchitecture du projet. Il est expert dans lanalyse et la conception des systmes
informatique. Il peut tre affect plusieurs projets, dassister les dveloppeurs ou mme
deffectuer des formations en internes.
Lanalyste-dveloppeur : son rle est de dfinir les spcifications fonctionnelles(SFD)
partir des besoins du client, pour les implmenter par la suite. Il est expert en langages de
programmation.
Le Testeur : il a pour mission de dfinir les plans de tests. Son rle est primordial, et
consiste lancer un ensemble de tests sur le projet ralis avant toute livraison au client.
Identification des droits daccs des acteurs

Afin de garantir la scurit des informations changes entre les acteurs, et le respect
de la hirarchie du projet et risque, un compte est dfini pour chaque membre utilisant
lapplication. Cest travers ce compte didentification, et les droits daccs, que les
fonctionnalits du systme seront accessibles.
Le Collaborateur : il consulte les actions et tches lui est affect, et renseigne la charge de
travail par le biais des imputations.
Le chef du projet : Il gre ses projets, et les risques qualifis quil a dclar, il affecte les
tches et les actions aux collaborateurs et surveille les charges de travail de ses
collaborateurs. Il valide les imputations des membres de son quipe, et consulte le tableau
de bord du suivi de risque.
Le Manager : il cre les projets et gre les risques globaux, il qualifie les risques dclars
par les chefs de projet, etconsulte les imputations des collaborateurs et les tableaux de
bord du suivi de projet et du risque.
Ladministrateur : il soccupe de la maintenance et le paramtrage de lapplication.

Identification des diffrents messages

Le but tant didentifier lensemble des interactions acteurs-systme, on a eu recours
dfinir lensemble des messages mis et reus par le systme ou les acteurs.

Les messages identifis sont prsents dans le tableau suivant :

PAGE 49


Acteur Profil Messages mis Messages reus
Collaborateur
Analyste-dveloppeur
Testeur

Demande pour :
Crer et modifier les imputations
Modifier les actions
Consulter la liste de ses actions et de ses imputations
Demande dauthentification
Alertes par notifications
Action traiter
Chef du projet
Demande pour :
Crer, modifier, un risque et son plan daction
Consulter le catalogue
Consulter la liste des risques dclars et visibles
Suivre les charges des actions
Consulter le tableau de bord
Imputations des collaborateurs
Recevoir les notifications

Manager
Demande pour :
Dclarer risque global et son plan daction
Modifier ou rejeter un risque et que son plan daction
Qualifier un risque dclar par un CP
Suivre lvolution et le traitement du risque
Consulter les imputations.
Imputations des collaborateurs
Recevoir les notifications

Administrateur

Demande pour
Configurer le systme
Dfinir les utilisateurs systmes
Grer les habilitations
Alertes par notifications

Tableau 2 : Tableau des interactions acteurs-systeme


ANALYSE FONCTIONNELLE
PAGE 50

CHAPITRE IV :

LAnalyse Fonctionnelle du Besoin est une dmarche relativement longue, qui
conditionne grandement la russite du projet et demande donc beaucoup de
rigueur et de soin. Pour cela, nous avons jug trs utile la dcomposition des
modules de lapplication en sous modules ou composants pour faciliter leur
modlisation.

X. Formalisme adopt (UML)

La conception de lapplication ProBoard a t effectue laide de lUML
(UnifiedModelingLanguage), langage de modlisation graphique et textuelle destin
comprendre et dcrire des besoins, spcifier et documenter des systmes, esquisser des
architectures logicielles, concevoir des solutions et communiquer des points de vue.
UML unifie la fois les notations et les concepts orients objet. Il ne sagit pas dune
simple notation graphique, car les concepts transmis par un diagramme ont une smantique
prcise et sont porteurs du sens au mme titre que les mots dun langage.
UML (dans sa version 2.0) sarticule autour de treize types diagrammes, chacun deux
tant ddi la reprsentation des concepts particuliers dun systme logiciel. Ces
diagrammes sont dpendants hirarchiquement et se compltent, de faon permettre la
modlisation d'un projet tout au long de son cycle de vie. UML est un standard industriel de
modlisation, il est sous lentire responsabilit de lOMG (Object Management Group).
Dans cette phase, nous avons eu recours quelques types de diagrammes, pour mieux
dcrire le systme, savoir :
Diagramme de cas dutilisation :

Dfinis initialement par Ivar Jacobson en 1992 dans sa mthode OOSE. Les cas
dutilisation constituent un moyen de recueillir et de dcrire les besoins des acteurs du
systme. Ils permettent de dcrire les interactions entre les acteurs (les utilisateurs du
systme) et le systme.


PAGE 51
Diagramme de Squences

Son objectif est de reprsenter les interactions entre objets en indiquant la chronologie des
changes. Cette reprsentation peut se raliser par cas dutilisation en considrant les
diffrents scnarios qui lui sont associs.
Diagramme dEtat transition

Il dcrit lenchainement des tats caractristiques dun objet durant sa vie et en rponse
aux vnements qui lui arrivent.
Diagramme de classe

Ce diagramme est considr comme le plus important de la modlisation oriente objet.
Alors que le diagramme de cas dutilisation montre un systme du point de vue des acteurs, le
diagramme de classes en montre la structure interne. Il contient principalement des classes.
Une classe contient des attributs et des oprations. Le diagramme de classes nindique pas
comment utiliser les oprations : cest une description purement statique dun systme
Diagramme de package

Cest un diagramme UML qui fournit une reprsentation graphique de haut niveau de
l'organisation de lapplication, et aide identifier les liens de gnralisation et de dpendance
entre les packages.

XI. Architecture gnrale de lapplication :

Avant de dcrire les diffrents modules constituant le systme dvelopper, et les acteurs
y accdant, une prsentation de la cartographie gnrale de lapplication est ncessaire pour
donner une vue entire et synthtise sur les fonctionnalits principales de chaque module.


PAGE 52

Figure 11: Diagramme du Cas d'Utilisation Gnral
XII. Modules de lapplication

XII.1. Module Suivi des projets

Ce module permet aux utilisateurs de grer et suivre lvolution des projets au sein de la
socit, pour cela, le manager initie le projet et dsigne un chef du projet, et laisse la relve au
chef du projet pour constituer lquipe de projet, grer et planifier lensemble des sous projets,
des volutions et des tches.
Le diagramme suivant illustre les diffrentes fonctionnalits de ce module.


PAGE 53

Figure 12: Diagramme du Cas d'Utilisation du module "Suivi des Projets"
Afin de faciliter la description du module, nous avons trouv adquat de dtailler certains
de ses composants.
Composant du module : Initier Projet

Le diagramme du cas dutilisation suivant permet de dtailler le cas dutilisation Initier
un projet :

Figure 13: Diagramme du Cas d'Utilisation du Composant "Initier un Projet"


PAGE 54
Ci-dessous, un tableau descriptif du cas dutilisation Initier un projet :
Titre Initier projet
Rsum
Lacteur peut crer deux types de projets : projet standard ou projet
complexe et dsigne pour chacun un responsable parmi les collaborateurs.
Acteurs Manager
Prconditions
- Session ouverte
- Avoir le rle correct.
Enchanements
- Scnario1 :
Choisir le menu Crer un nouveau projet standard
Renseigner les informations du projet.
Dsign un chef de projet.
- Scnario2 :
Choisir le menu Crer un nouveau projet complexe .
Renseigner les informations du projet.
Dsigner un chef de projet.
Dfinir les sous-projets.
Renseigner les informations des sous-projets
Dfinir les volutions.
Renseigner les informations des volutions.
Exceptions
Message derreur dans le cas dun traitement non autoris ou donne(s) non
valide(s).
Post-conditions Les oprations demandes et permises sont enregistres dans la BD.
Tableau 3: Tableau descriptif du composant " Initier un projet"
Les diagrammes de squence suivant exposent lensemble des interactions entre
lutilisateur (le manager) et le systme considr comme boite noire.
Composant du module : Grer Projet

Ce composant permet aux utilisateurs habilits de grer leurs projets en choisissant
plusieurs oprations.
Le diagramme du cas dutilisation suivant dveloppe les diffrentes fonctionnalits
offertes par ce composant.


PAGE 55

Figure 14: Diagramme du Cas d'Utilisation du composant"Grer Projet"

Le tableau ci-dessous dcrit les cas dutilisation modifier un projet et affecter
quipe de projet du composant prsent :
Titre Grer Projet
Rsum
Permet deffectuer plusieurs oprations : Modification des informations,
archivage de projet, clture de projet, Suppression, affectation dquipe aprs
cration de projet
Acteurs - Collaborateur dsign comme Chef de projet
Prconditions
- Session ouverte.
Enchanement
- Scnario1 :
Choisir loption Modifier projet .
Renseigner les informations autorises du projet.
Valider la modification en cliquant sur le bouton Modifier .
Le systme vrifie les informations saisies et affiche un message de validation.
- Scnario 2 :
Choisir loption Affecter Equipe de projet
Slectionner le projet concern.
La liste des collaborateurs disponibles est affiche.
Une deuxime liste de tous les collaborateurs est affiche.
Lacteur slectionne le collaborateur choisi et clique sur le bouton
affecter . Les collaborateurs choisis figurent dans la liste dquipe de projet.
Une fois lquipe dsigne, on clique sur le bouton valider pour valider
lajout dquipe de projet.
Exception
- Message derreur dans le cas dun traitement non autoris ou donne(s)
non valide(s).
Post-conditions - Les oprations demandes et effectues sont enregistres dans la BD.
Tableau 4: Tableau descriptif du composant "Grer Projet" du module " Suivi des projets"


PAGE 56
Ce diagramme de squence dcrit les diffrentes interactions avec le systme lors de la
dsignation de lquipe du projet. Cest aprs linitiation du projet et laffectation du CP que
ce dernier passe dfinir les membres de son quipe pour leur affecter par la suite les tches
dfinies.

Figure 15: Diagramme de squences pour la designation dune quipe de projet

Aprs la dfinition des tches et leur affectation, le CP peut tout moment les consulter
afin de garantir le bon droulement du projet. Ce diagramme de squence permet de dcrire
les diffrentes interactions de cette opration.


PAGE 57

Figure 16: Diagramme de squences pour la consultation de la liste des tches


PAGE 58
XII.2. Module Suivi du risque

La gestion du risque passe par plusieurs procdures de dclaration, de qualification, et
dexcution. Ainsi, lorsque lutilisateur termine la saisie du risque, il peut le soumettre ou
abandonner laction. Un risque soumis est ltat Cr ou Ouvert si le risque dclar
est li un projet, le responsable peut faire basculer ltat du risque vers annule ou
supprime en accdant la page de consultation des risques en attente de qualification.
Aprs, le risque commence sa phase danalyse, et le manager aprs tude et chiffrage du
risque et son plan daction, peut valider la dclaration du risque et donc passe ltat
Qualifi , ou bien le rejeter, et son tat passe Rejet .
Un risque qualifi aprs traitement et excution de son plan daction, son cycle de vie
prend fin par la validation de lensemble de ses actions et passe par la suite ltat
Cltur .
Le diagramme du risque ci-dessus, donne une visibilit gnrale sur les diffrents tats
dun risque, ce qui nous a aid laborer les diagrammes de squence de ce module.
Figure 17: Diagramme d'Etat transition pour un risque


PAGE 59
Dans la partie qui suit, nous prsentons le diagramme du cas dutilisation du module.
Nous avons dtaill ce module par composants afin de permettre une lisibilit plus claire des
diagrammes.

Figure 18: Diagramme use-case du module "Suivi du risque"

Composant du module : Gestion des risques
Figure 19: Diagramme du cas d'utilisation de "Gestion du risque"
Description du cas dutilisation Gestion du risque


PAGE 60

Titre Gestion des risques
Rsum Permettre les diffrents oprations (Ajout, modification,
suppression, qualification, synthse, clture, ) sur le risque
Acteurs Manager, Collaborateur dsign comme CP.
Prconditions - Session ouverte
Enchanements - Scnario1 :
Choisir le menu Ajouter un nouveau risque sans
consulter le catalogue
Renseigner les informations du risque.
- Scnario2 :
Choisir le menu Consulter le catalogue .
Rechercher le risque.
Visualiser ses informations.
Renseigner des informations complmentaires.
- Scnario3 :
Choix du menu Liste des risques
Choix du projet, tat du risque et nature.
Afficher la synthse de la recherche.
Exceptions Message derreur dans le cas dun traitement non autoris ou
donne(s) non valide(s).
Post-conditions Les oprations demandes et permises sont enregistres dans
la BD.
Tableau 5: Description du cas d'utilisation "Gestion des risques"
Le diagramme de squence suivant, dcrit les interactions entre lutilisateur et le systme
pour les cas dutilisation d ajouter un nouveau risque .


PAGE 61

Figure 20: Diagramme de squence du cas "Cration d'un nouveau risque"


PAGE 62
Composant Gestion des plans daction
commentaire

Figure 21 : Diagramme du cas d'utilisation " Gestion du plan d'actions"
Description du cas dutilisation Dfinition du plan daction

Titre Dfinition du plan daction
Rsum Permettre les diffrents oprations (Ajout, modification,
suppression, qualification, synthse, clture, ) sur les
actions.
Acteurs Manager, Collaborateur dsign comme CP.
Prconditions - Session ouverte
Enchanements - Scnario1 :
Choisir le menu Dfinir plan daction
Choisir le risque ajout.
Afficher une synthse sur le risque.
Choisir lopration effectuer.
Traiter lopration.
Exceptions Message derreur dans le cas dun traitement non autoris
ou donne(s) non valide(s).
Post-conditions Les oprations demandes et permises sont enregistres
dans la BDD.
Tableau 6: Description du cas d'utilisation "Dfinition du plan d'actions"


PAGE 63

Figure 22 : Diagramme de squence du cas "Dfinition d'un nouveau plan d'action"

Figure 23 : Diagramme de squence du cas " Dfinition du plan d'action depuis le
catalogue"


PAGE 64
Module Gestion des imputations

Figure 24 : Diagramme des cas d'utilisations "Gestion des imputations"
Titre Gestion des imputations
Rsum
Permettre les diffrentes oprations (ajout, suppression,
synthse..) sur les imputations.
Acteurs
Manager, Collaborateur
Prconditions
Session ouverte.
Avoir le rle correcte.
Enchanements
Scnario 1 :
. Choisir le menu gestion de mes imputations.
. Choisir lopration effectuer.
. Traiter lopration demande.
Scnario 2 :
. Choix du menu synthse des imputations
. Choix de la ressource (collaborateur).
. Afficher la synthse, sur les imputations, hebdomadaire
ou journalire.
Exceptions
Message derreur dans le cas dun traitement bloquant.
Post-conditions
Les oprations permises et demandes sont enregistres
dans la BDD.
Tableau 7 : Description du cas d'utilisation "Gestion des imputations"


PAGE 65
XIII. Package de larchitecture globale

Nous prsentons ci-dessous les packages mtiers que nous avons pu dgager tout en
veillant ce que ces packages ne soient pas mutuellement lis pour des besoins de
rutilisation et dvolutivit caractristiques de notre systme.

Figure 25 : DIAGRAMME DE PACKAGE DE LAPPLICATION


PAGE 66
XIV. Diagramme de classes
Figure 26 : Diagramme de classe general


PAGE 67
CHAPITRE VI :
CONCEPTION GENERIQUE

La conception gnrique consiste construire une solution darchitectures logique et
technique qui rpond aux spcifications mais indpendamment des besoins fonctionnels.
Ainsi, la suite prsentera larchitecture logique et technique adoptes en prcisant les
diffrentes technologies utilises. Les paragraphes suivant sont le rsultat de la phase de
formation que nous avons pass au dbut de notre stage et dans laquelle nous avons
configur la structure technique cible de notre application.
XV. Architecture Logique

Les applications d'entreprises modernes sont communment bases sur l'utilisation de
plusieurs composantes, chacune fournissant une fonctionnalit particulire. Les composantes
qui fournissent des services similaires sont gnralement regroupes en couches, elles-mmes
organises en une pile dans laquelle les composantes d'une couche donne utilisent les
services des composantes de la couche en-dessous (ou ceux des composantes de la mme
couche). Le diagramme ci-dessous illustre une structure en couches trs utilise pour une
application d'entreprise et que nous avons adopte dans notre projet.


PAGE 68
1) Couche de prsentation
Elle contient les composantes qui doivent interagir avec l'utilisateur de l'application,
comme les pages Web, les formulaires, ainsi que tout ce qui rgit le comportement de
l'interface utilisateur.
2) Couche mtier
Elle intgre les fonctionnalits et les traitements propres l'application. Les
fonctionnalits simples peuvent tre implmentes avec des composants sans tats, alors que
les transactions complexes et longues peuvent utiliser des composants d'ordonnancement avec
tats. Les composants mtier sont gnralement dissimuls derrire une sous-couche
d'interface de service qui agit comme une faade afin de dissimuler la complexit de
l'implmentation.
3) Couche daccs aux donnes
Elle fournit une interface simple pour accder aux donnes et les manipuler. Les
composantes de cette couche abstraient la smantique de la couche de donnes sous-jacente,
permettant ainsi la couche mtier de se concentrer sur la logique applicative. Chaque
composante fournit typiquement des mthodes pour crer, lire, mettre jour et effacer des
entits de donnes.
4) Couche de stockage de donnes
Elle comprend l'ensemble des sources de donnes de l'application d'entreprise. Les
deux types les plus communs de sources de donnes sont les bases de donnes et les systmes
de fichiers.
XVI. Modle de conception

Larchitecture Model-View-Controller vise organiser une application interactive en
sparant les donnes, leur reprsentation et le comportement de lapplication. Le modle
reprsente la structure des donnes dans l application et les oprations spcifiques sur ces
donnes. Quant la Vue, elle prsente les donnes sous une certaine forme lutilisateur,
suivant un contexte d exploitation. Le Controller traduit les interactions utilisateur par des
appels de mthodes (comportement) sur le modle et slectionne la vue approprie base sur
ltat du modle.


PAGE 69
Le modle MVC2 est une extension du MVC1. Il reprend les concepts de base avec
une seule diffrence rsidant dans la couche contrleur . Il ny aura plus quun seul point
dentre dans le programme : Le contrleur principal, contrairement MVC 1, il fallait
implmenter autant de contrleurs que ncessaire et que la requte fasse appel directement au
bon contrleur. Dans MVC2, le point dentre ne servira plus traiter directement la requte
mais dlguer cette tche un autre contrleur spcialis

XVII. Architecture technique

Figure 27: Architecture technique du ProBoard


PAGE 70
1) Couche prsentation
RichFaces
RichFaces est un Framework de composants web avances, il offre toute une
bibliothque de fonctionnalits AJAX facilement intgrables dans des applications
commerciales utilisant JSF.
RichFaces amliore galement d'autres domaines de JSF 2, y compris l'optimisation
des performances, facilit d'utilisation, les ressources dynamiques, le dpouillement et le
dveloppement des composants.
Cela permet aux utilisateurs de profiter pleinement de toutes les amliorations de la
productivit quoffre JSF 2.0
2) Couche service
Spring :

SPRING est un conteneur dit lger , c'est--dire une infrastructure similaire un
serveur d'application J2EE. Il prend donc en charge la cration d'objets et la mise en relation
d'objets par l'intermdiaire d'un fichier de configuration qui dcrit les objets fabriquer et les
relations de dpendances entre ces objets. Spring offre plusieurs services qui facilitent le
dveloppement et les tests des applications J2EE.
Dans le cadre de notre projet, Spring nous a permis de diminuer la quantit de code, de
mettre en uvre facilement la programmation oriente aspect (AOP) et dassurer le
dcouplage des composants de lapplication lors de l'utilisation de l'injection de dpendance
(IOC).
Ce Framework est organis en modules, reposant tous sur le module SpringCore et
sintgrant avec dautres Frameworks.
Spring Security :

Spring Security permet de grer l'accs aux ressources d'une application Java. Ces
ressources peuvent tre des pages web, mais aussi des objets de services mtier. Toute
ressource sollicite par un appelant est rendue accessible si, d'une part, l'appelant s'est
identifi, et si d'autre part, il possde les droits ncessaires (des rles dans le vocabulaire
Spring Security)


PAGE 71
3) Couche daccs aux donnes
Hibernate

Hibernate est un Framework qui permet le mapping objet/relationnel et la persistance
objet des donnes. Lintgration de ce Framework permet la couche applicative de voir les
donnes comme des classes dont le contenu reste en mmoire mme aprs la fin d'excution
du programme. De plus, le lien entre lesclasses exposes et la source physique des donnes est
dfinie par un fichier XML.
Hibernate s'occupe du transfert des classes Java dans les tables de la base de donnes
(et des types de donnes Java dans les types de donnes SQL). Il permet galement de
requter les donnes et propose des moyens de les rcuprer.
4) Serveurs dapplication
Apache Tomcat

Apache Tomcat est un conteneur libre de servlet J2EE. Issu du projet Jakarta, Tomcat
est un projet principal de la fondation Apache. Il implmente les spcifications des servlets et
des JSP du Java CommunityProcess. Il est paramtrable par des fichiers XML et par des
proprits, et inclut des outils pour la configuration et la gestion. Il comporte galement un
serveur HTTP.
5) SGBD :
Le systme de gestion de base de donnes adopt pour ProBoard est :
MySQL
MySQL est un systme de gestion de base de donnes. Selon le type d'application, sa
licence est libre au propritaire. Il fait partie des logiciels de gestion de base de donnes les
plus utiliss au monde, autant par le grand public (applications web principalement) que par
des professionnels, en concurrence avec Oracle et Microsoft SQL Server.
MySQL a t achet le 16 janvier 2008 par Sun Microsystems pour un milliard de
dollars amricains. En 2009, Sun Microsystems a t acquis par Oracle Corporation, mettant
entre les mains d'une mme socit les deux produits concurrents que sont Oracle Database et
MySQL. Ce rachat a t autoris par l'Union europenne le 21 janvier 2010.


PAGE 72
Depuis mai 2009, son crateur Michael Widenius a cr MariaDB pour continuer son
dveloppement en tant que projet Open Source.
XVIII. Gestion des dpendances des librairies

Maven est un outil open-source de build pour les projets Java trs populaire, conu
pour supprimer les tches difficiles du processus de build. Maven utilise une approche
dclarative- un paradigme connu sous le nom de POM afin de dcrire un projet logiciel, ses
dpendances avec des modules externes et l'ordre suivre pour sa production. Il est livr avec
un grand nombre de tches prdfinies, comme la compilation de code Java.-, o le contenu et
la structure du projet sont dcrits, plutt qu'une approche par tche utilise par exemple par
Ant ou les fichiers make traditionnels. Cela aide mettre en place des standards de
dveloppements au niveau d'une socit et rduit le temps ncessaire pour crire et maintenir
les scripts de build.

Ltude mene dans ce chapitre met lvidence larchitecture technique savoir les diffrents
serveurs et composants logiciels, ainsi que les flux quils schangent. Le choix de lensemble des
frameworks prconiss nest gure alatoire. Il est titre dalignement avec les nouveauts
mergeantes de la plateforme J 2EE. Dans le chapitre suivant nous allons faire une projection des
technologies choisies sur la conception propose.


CONCEPTION DETAILLEE
PAGE 73
CHAPITRE VII :
CONCEPTION DETTAILLEE

La conception du systme consiste reprendre le modle d'analyse la lumire des
choix technologiques et de le refaire dune faon plus raffine pour prparer la phase de
ralisation.
1- Diagrammes de squences dtailles
Ladaptation des diagrammes de squences dtailles la technologie utilise est une
tche primordiale pour la bonne organisation du projet. Les figures suivantes reprennent alors
les diagrammes de squences de certains scnarios en projection sur la technologie utilise.
1) Diagramme de squence Consulter liste des tches dun projet
2) Diagramme de squence Dclarer un nouveau risque globale
Le cas dutilisation Dclaration dun nouveau risque fait partie du module Gestion
des risques, il permet la dclaration dun nouveau risque.
Lorsque le systme charge la page dajout dun nouveau risque, il va dabord charger la liste
des projets dont le collaborateur authentifi est responsable.
Quand lutilisateur, valide la saisie du formulaire et aprs vrification des champs remplis, les
actions suivantes sont excutes :
1. Le risque devient un fils du projet choisi.
2. Le systme met jour la table de la base de donnes qui reprsente lhistorique des risques
ajouts.
3. Un message est affich lutilisateur linforme que la dclaration a t ralise avec
succs .
Les actions 1, 2 et 3 sont excutes toutes ensemble. Si au moins une action nest pas
excute, dans ce cas un message derreur est affich.


PAGE 74
3) Diagramme de squence Affecter une action un collaborateur

Ce cas dutilisation fait partie du module Gestion des plans dactions, il permet
dexcuter le plan daction et donc daffecter les actions aux collaborateurs.
Avant que le systme charge la page dexcution du plan daction, il charge la liste
des risques et leurs plans dactions, un filtre de recherche du risque est prsent lutilisateur
pour la slection.
Lorsque lutilisateur choisit laction affecter, le systme charge la liste des
collaborateurs non encore affects des actions.
Aprs validation de laffectation (choix de laction et le collaborateur), les actions ci-
dessous sont effectues :
1. Laction devient un fils du collaborateur choisi.
2. Le systme met jour la table de la base de donnes qui reprsente lhistorique des
affectations ralises.
3. Un message est affich lutilisateur linforme que laffectation a t ralise
avec succs .
4. Une notification est envoye au collaborateur affect lui informant de sa nouvelle
activit.

PAGE 75


PAGE 76


PAGE 77



PAGE 78
XIX. Diagrammes de classes de larchitecture globale

Les parties suivantes illustrent les diagrammes de classes du projet selon les packages
dfinis prcdemment (pour ne pas surcharger le diagramme, nous avons opt prsenter les
classes sans mthodes).
1) Module de Maintenance et paramtrage
Ce diagramme de classe contient principalement la classe Collaborateur qui contient toutes
les informations concernant lutilisateur de lapplication.

Figure 28 : Diagramme de classe du module "Maintenance"
Le diagramme contient galement une classe pour contrler laccs lapplication. La classe
Profil contient les diffrents profils qui peuvent sauthentifier dans lapplication et qui est
utilise par SPRING SECURITY afin de rediriger lutilisateur authentifi son espace
personnalis aprs vrification des droits daccs. Nous trouvons aussi les deux classes
Ples et Localisation pour bien situer le collaborateur, ces classes vont tre rfrences
par dautre module.
La classe JoursFeriers vise paramtrer les jours fris par localisation qui va tre utilise
pour aider une meilleure optimisation de gestion et planifications des projets.


PAGE 79
Nous avons deux types de jours fris, savoir : les jours fris fixes, stables dune anne
une autre, et puis les jours fris prvisionnels lis une anne prcise.
Pour les classes TypeTache et Categorie , elles sont utilises pour dfinir les types de
tches grs par le module Maintenance .
2) Module Suivi du risque
Concernant le module Suivi des risques , nous avons trouv les classes suivantes :
Risque : Dfinit les proprits globales du risque.
TypeRisque : La liste les types des risques existants
Categorie : La liste les catgories des risques
ProbaOccurrence : Permet de choisir la probabilit doccurrence du risque
Gravite : Permet de dterminer la gravit du risque dclar
Status : Correspond ltat davancement du risque.
AffectationCollab :
RisqueProjet : Dtermine les risques lis aux projets
Action : Dfinit les proprits dune action
Activite : Dfinit lActivit globale : action ou tche
TypeAction : permet de dfinir le type daction ajoute.


PAGE 80

Figure 29 : Diagramme de classe du package "Suivi des risques


PAGE 81
3) Module Suivi du projet

Ce diagramme prsente les diffrentes interactions entre lentit Projet qui contient
lensemble des informations pour dfinir un projet (cf. Figure3.10) et les autres entits qui
sont :
- Localisation qui donne une information sur la localisation exacte du projet
(STERIA Nantes, STERIAMEDSHORE Casablanca, etc.)
- Pole pour avoir une ide sur les domaines de comptence de chaque projet. En
effet, chaque ple ou dpartement peut avoir des comptences spcifiques un
mtier donn (exemple : Ple Montique ) afin daider les dcideurs faire les
bonnes affectations collaborateurs/projets en vrifiant si le collaborateur concern
possde les comptences requises pour chaque projet sujet dtude.
- Tache , TypeTache pour dfinir lensemble des tches dun projet.
- Imputation contient des informations sur les consommations de chaque
collaborateur par rapport au temps allou la tche. Cette entit est capitale dans la
mesure o elle permet davoir une traabilit sur ce que le collaborateur fait et aussi
pour bien maitriser et avoir une visibilit sur les risques qui peuvent apparatre suite
aux blocages rencontrs.

PAGE 82

Figure 30 : Diagramme de classe du package "Suivi projet"


PAGE 83
4) Module Gestion des imputations
Lanalyse prliminaire du module Imputation a permis de de ressortir les classes
suivantes :
Imputation : contient la date prcise de limputation.
ImputationActivite : Permet la liaison de limputation et lactivit affecte.

Figure 31 : Diagramme de classe du package " Gestion des imputations"
Dans ce chapitre, nous avons prsent la phase de conception de notre projet, o nous
avons adapt le modle danalyse, que nous avons produit prcdemment, aux Frameworks
techniques et larchitecture choisie. Ensuite, nous avons dcrit quelques digrammes de
squences dtaills. Enfin, nous avons prsent les diagrammes de classes finaux de la
conception selon chaque package.
Dans la partie suivante, nous allons dtailler la phase de ralisation de notre projet.

PAGE 84


PARTIE 3
MISE EN UVRE DU PROJET

Lobjectif de cette partie est de prsenter
les diffrents environnements et outils de
dveloppement avant de prsenter quelques
interfaces de lapplication ProBoard.

PAGE 85

CHAPITRE VII :
ENVIRONNEMENT DE DEVELOPPEMENT

XX. 1. Environnement de dveloppement

Les outils principaux utiliss dans la phase de ralisation sont les suivants :
XX.1. Eclipse

Eclipse est lIDE de dveloppement le plus utilis par les dveloppeurs Java. Il est
libre, extensible et permettant de crer des projets de dveloppement optimiss pour
Java/J2EE, PHP, C et C++.
Eclipse IDE est principalement crit en Java, et ce langage, grce des bibliothques
spcifiques, et des plug-ins supports, permet de faciliter les tches de dveloppement.
La spcificit de cet IDE est du fait que son architecture est totalement dveloppe autour de
la notion de plugin ; toutes les fonctionnalits sont dveloppes en tant que plug-in. Nous
avons utiliss lIDE Indigo 3.5.
XX.2. SVN (Subversion)

SVN est un serveur utilis pour centraliser le projet pour un travail en quipe plus
facile et donc permettre le dveloppement en parallle, vu que plusieurs acteurs interviennent
dans le projet. Il est principalement un systme de gestion des versions et il offre des
commandes permettant lajout de nouvelles ressources et la rcupration des anciennes
versions.
XX.3. JUNIT

Cet outil est dvelopp par Kent Beck et Erich Gamma, entirement en Java. Cest un
Framework pour rdiger et excuter des tests unitaires. Lobjectif de JUNIT est d'offrir au
dveloppeur Java un environnement simple, qui ncessite un travail minime pour rdiger les
tests et les excuter.

PAGE 86

XX.4. HPQC

HP Quality Center est une plateforme de test centralise qui structure le processus
d'assurance qualit et fdre les ressources de test l'chelle de tous les projets de l'entreprise.
Cette plateforme garantit la traabilit de tout le processus - gestion des exigences,
planification des tests, construction des tests, excution des tests, gestion des anomalies - au
sein d'un seul rfrentiel avec analyse en temps rel du statut de chacun des projets.

XX.5. Hudson

Cest un outil dintgration continue pour le langage Java.
Lintgration continue est un ensemble de pratiques utilises en gnie logiciel
consistant vrifier chaque modification de code source que le rsultat des modifications ne
produit pas de rgression dans l'application dveloppe.
Pour appliquer cette technique, il faut d'abord que :
le code source soit partag (en utilisant des logiciels de gestion de versions tels que
Subversion que nous allons prsenter par la suite.)
les dveloppeurs intgrent (commit) quotidiennement (au moins) leurs modifications
des tests d'intgration soient dvelopps pour valider l'application (avec JUnit par
exemple).
Les principaux avantages d'une telle technique de dveloppement sont :
les problmes d'intgration sont dtects et rpars de faon continue, vitant les
problmes de dernire minute ;
prvient rapidement en cas de code incompatible ou manquant ;
test immdiat des units modifies ;
une version est toujours disponible pour un test, une dmonstration ou une
distribution.

PAGE 87

CHAPITRE VII :
ECRANS DE REALISATION

Aprs avoir fait le tour des outils utiliss pour la ralisation du prsent projet, la
section suivante illustre une partie des interfaces ralises.

XXI. Page dauthentification

Figure 32 : Ecran "Page d'authentification"

XXII. Page daccueil

PAGE 88


Figure 33 : Ecran "Page d'accueil"

XXIII. Page de dclaration dun risque globale

Figure 34 : Ecran " Dclaration d'un risque global "
XXIV. Dfinition du plan daction

PAGE 89


Figure 35 : Ecran " Dfinition du plan d'actions "
XXV. Excution du plan daction

PAGE 90


Figure 36 : Ecran " Excution du plan d'action"
XXVI. Gestion des imputations

PAGE 91


CONCLUSION

Il est indniable que la ralisation dun projet constitue une exprience enrichissante,
dans la mesure o elle prsente une occasion pour concrtiser et complter les connaissances
thorique acquises.
La mission qui nous a t confie dans notre projet de fin dtudes consistait mettre
en place une plateforme de gestion et suivi des activits et des ressources de Steria. Cette
plateforme est cense permettre aux gestionnaires de socit de formaliser la gestion des
activits et la matrise des risques.
Pour mettre en uvre ce projet, nous tions amenes, dans un premier lieu, tablir
une tude de spcifications et des exigences afin de pouvoir dlimiter le primtre fonctionnel
de lapplication ainsi quune tude des outils et technologies susceptibles de convenir sa
ralisation. Dans un second lieu, lanalyse, la conception du projet et la modlisation des
processus ont t effectues en se basant sur le formalisme UML ainsi que larchitecture
MOBE pour qui nous a permis de rduire la charge en terme de ralisation en exploitant les
diffrents services offerts.
Nous avons russi raliser un module gnrique de scurit MOBE-SECURITY
et lintgrer au Framework de lentreprise, et puis scuriser lapplication PROBOARD
(gestion des rles et des autorisations) et implmenter une grande partie du module suivi de
projets dont nous poursuivrons toujours la ralisation.
Ce projet de fin dtudes a t pour nous une exprience trs instructive tous les
niveaux.
Au niveau technique, nous avons pu dvelopper nos comptences et notre savoir grce aux
bonnes pratiques adoptes tout au long de la priode de ralisation du projet et durant toutes
ces phases. En effet, nous avons pu comprendre et sentir de plus prs la philosophie davoir
un esprit de capitalisation des solutions et des bonnes pratiques. Nous avons beaucoup appris
galement sur la gestion dun projet offshore au sein dune SSII, et les diffrentes phases de
son processus dindustrialisation.
Sur le plan relationnel, nous avons ralis quel point une bonne communication et un bon
sens de responsabilit sont indispensables dans un travail dquipe, ainsi que lautonomie et la
patience au niveau personnel.
En perspective Une extension de ce travail serait la ralisation des tests de robustesse
et le dploiement de lapplication. Aussi lapplication peut tre volue fonctionnellement en
rpondant des nouveaux besoins grce son architecture flexible soigneusement labore et
lintroduction des bonnes pratiques de programmation pour favoriser la rutilisation
.Dailleurs, la perspective en nous confiant ce projet, tait de construire un projet de rfrence
qui pourra tre par la suite gnralis sur lensemble des prestations grs par dautres filiales
du groupe STERIA.

PAGE 92

Bibliographie

PAGE 93

Webographie

PAGE 94

ANNEXES

Annexe A : Intgration Continue

On appelle "intgration" tout ce qu'il reste faire une quipe projet, quand le travail de
dveloppement proprement parler est termin, pour obtenir un produit exploitable, "prt
l'emploi".
Par exemple, si deux dveloppeurs ont travaill en parallle sur deux composants A et B, et
considrent leur travail comme termin, vrifier que A et B sont cohrents et corriger
d'ventuelles incohrences relve de l'intgration. Ou encore, si le produit final est fourni sous
la forme d'un fichier compress, regroupant un excutable, des donnes, une documentation,
les tapes consistant produire ces fichiers et les rassembler relvent aussi de l'intgration.

Une quipe qui pratique l'intgration continue vise deux objectifs:
rduire presque zro la dure et l'effort ncessaire chaque pisode d'intgration
pouvoir tout moment fournir un produit exploitable
Dans la pratique, cet objectif exige de faire de l'intgration une procdure reproductible et
dans la plus large mesure automatise.
La figure suivante prsente les diffrentes composantes dune plateforme dintgration
continue :

PAGE 95


1- Gestion de versions :
La gestion de versions consiste maintenir l'ensemble des versions d'un ou plusieurs fichiers
(gnralement en texte). Essentiellement utilise dans le domaine de la cration de logiciels,
elle concerne surtout la gestion des codes source.
cet effet, il existe diffrents logiciels de gestion de versions qui, bien qu'ayant des concepts
communs, apportent chacun leur propre vocabulaire et leurs propres usages.
Subversion : SVN
Cest lun des logiciels de gestion de sources et de contrle de versions. Ce type de
programmes a plusieurs fonctions, notamment :
garder un historique des diffrentes versions des fichiers dun projet dans un
dpt central;
permettre le retour une version antrieure quelconque ;
garder un historique des modifications avec leur nature, leur date, leur
auteur...;
permettre un accs souple ces fichiers, en local ou via un rseau
permettre des utilisateurs distincts et souvent distants de travailler ensemble
sur les mmes fichiers.
Le choix du SVN se justifie par les arguments suivants :
il est multiplateforme ;

PAGE 96

il sagit dun logiciel libre ;
il fonctionne de manire centralise ;
son utilisation et son administration sont plus faciles que CVS ;
il supporte plusieurs modes daccs distants, dont SSH et WebDAV via
Apache.
La figure ci-dessous montre larchitecture du fonctionnement de SVN :

2- Serveur dintgration continue : Hudson
Hudson est un logiciel crit en JAVA. Il s'agit d'une application WEB accessible et
utilisable avec un simple navigateur que ce soit pour l'administration ou l'utilisation. Hudson
permet de mettre en uvre tous les mcanismes du concept d'intgration continue savoir :
le polling depuis un SCM (Source Code Management) pour dtecter les
mises jour faites au niveau du code source
Le build du code source rcupr dans le SCM soit ds qu'un
changement est dtect au niveau des sources (Nouveau Commit
effectu) soit intervalles rguliers sans se soucier de la prsence de
nouveaux commits ou non.
Lalerte dun contact unique et/ou les committers concerns dans le cas
d'un build instable ou incorrect
Mise disposition du rsultat des builds corrects pour utilisation
(Notion d'artifact).

3- Rfrentiel Binaire : Artifactory
Cest un rfrentiel binaire de classes entreprises qui centralise tous les aspects de la gestion
des fichiers binaires du logiciel.

PAGE 97

Son fonctionnement est bas sur loutil Maven qui est un outil logiciel libre pour la gestion et
lautomatisation de production des projets logiciels java. Et le logiciel Sonar

4- Sonar :
Un outil qui centralise toute une gamme de mesures de qualit de code.
Il utilise un certain nombre de plugins Maven (Checkstyle, PMD, Cobertura ou Clover)
pour analyser des projets Maven et gnrer un ensemble complet de rapports sur la qualit
du code.

PAGE 98

Annexe B : L'architecture MOBE

a. Principes techniques directeurs
Ce paragraphe rappelle les principes techniques directeurs fondamentaux. Pour la liste exhaustive des principes
techniques directeurs, cest spcifique au projet.

Figure 37 : Architecture gnrale simplifie

Lapplication est dveloppe sous une architecture J2EE n-tiers avec :
Un client lger (DHTML-Ajax);
Un Serveur dApplication paramtr avec Spring comprenant :
La couche de Prsentation base sur JSF + Ajax (MyFaces, RichFaces,
IceFaces);
La couche Mtier en pur Java (POJO) comprenant les Services Mtier et les
Objets Mtier;
La couche de Persistance base sur Spring-Hibernate.
Un serveur de Base de Donnes (Oracle, SQL Server, MySQL et autre).
Lapplication est compose dun Socle Technique gnrique sur lequel viennent sintgrer des modules
fonctionnels.
Lintgration des dveloppements est effectue sur une plateforme dintgration continue mise en uvre avec un
serveur Maven 2 (avec loutil Artifactory) fonctionnant avec Hudson, coupl loutil de gestion de configuration
Subversion (SVN).

Serveur dapplication
Prsentation
Mtier
Intgration DAO
F
r
a
m
e
w
o
r
k

I
n
t
e
r
n
e

PAGE 99

b. Caractrisation de larchitecture logicielle
XX.5.1. Architecture N-tiers
Comme prsent dans les principes directeurs de ce document, larchitecture adopte est une architecture n-tiers
classique , avec une couche de services mtier (POJO).
En ce qui concerne la couche de prsentation, le modle MVC2 est mis en uvre avec JSF :
les ManagedBeans jouant le rle de contrleurs ;
les JSP pour la prsentation ;
les BackingBeans et les attributs (encapsuls dans le Helper du ManagedBean) pour le
modle.
Dans larchitecture actuelle, la couche de prsentation accde aux Services Mtier de la couche mtier en mode
POJO plutt que via services web et/ou dEJB. Ce choix a t fait principalement pour des raisons de
performances, de simplicit de mise en uvre et de maintenance de lapplication :
La couche de prsentation (au travers des ManagedBeans) ne connat que les interfaces
des services mtier. Elle accde aux services mtier par injection de dpendance
(configuration Spring) :
Les Services Mtier sont des beans Spring instancis par les Factory
Spring.
Les ManagedBeans sont sont des beans manag par JSF instancis et
initialis (relis aux services mtier) par la configuration JSF.
La couche de prsentation est excute dans le mme contexte Java que la couche mtier :
le parcours des relations entre objets mtier (lors de la transformation en objets de
prsentation) peut ainsi fonctionner en mode lazy car le contexte hibernate est encore
accessible : ceci vite de charger systmatiquement les relations au niveau mtier ce qui
permet de gagner beaucoup en performance.
Les Objets Mtiers circulent de la couche de persistance jusqu la couche de prsentation
(recopis dans des Objets de Prsentation). Ces objets ne sont pas srialiss entre les
couches, seules les rfrences de ces objets sont transfres pour un gain de performance.
De plus un cache dobjets mtier (de premier et de second niveau) est gr par la couche
de persistance (Hibernate). Ce mcanisme, transparent pour la couche de prsentation,
permet dviter des requtes systmatiques en base.
c. Modles de conception et programmatiques
La liste des modles de conception utilise est la suivante :
Patterns de la couche Prsentation :
Pattern MVC2 - Model View Controller (implment par le Framework JSF)
Pattern Front Controller (implment par le Framework JSF)
Pattern View Helper (implment dans la couche prsentation)
Pattern Composite View (utilisation de Struts-Tiles ou Facelets pour les vues)
Patterns de la couche Mtier et Accs aux donnes:
Pattern Business Delegate utilis pour limplmentation des Services mtier avec Spring.
Pattern Service Faade (utilis dans la couche DAO, Mtier, Services Mtier)
Pattern Data Access Object (DAO) utilis pour limplmentation des Dao
3- Socle technique (Framework) MOBE
Le Socle correspond un cadre technique destin intgrer les composants fonctionnels du systme cible.
Ce socle est indpendant de ces composants fonctionnels : Il pourrait tre rutilis dans un autre contexte et ne
serait pas impact par lajout dune nouvelle partition fonctionnelle.
Il contient galement les services technico-fonctionnels de l'application.
Ce socle technique est constitu :
Du Framework qui contient les classes de base dans chacune des couches techniques :
Couche Mtier :
Service Mtier Gnrique

PAGE
100

DataTransformers gnriques
Couche persistance :
Dao Gnrique
Classes techniques encapsulant la librairie Hibernate
Couche de prsentation :
Classes de base pour les ManagedBeans
Des composants JSF dveloppe par lquipe darchitectes (visualisation
XSLT, composant dinitialisation etc.).
Classes dencapsulation de loutil jXls de gnration de rapport XLS.
Dun ensemble de Framework externes encapsuls ou assembls (JSF, Hibernate, Spring, ACEGI
etc.) + de classes de base pour la couche prsentation
Doutils communs (classes utilitaires pour les logs, gestion des dates, XML, e-mails etc.)
Communication entre les composants
Le schma ci-dessous dcrit le mode de communication entre les divers composants.
Lutilisateur accde lapplication via une URL. Cette application est rpartie entre le client (le navigateur avec
les lments HTML/CSS/JS/AJAX) et une partie serveur (JSF).

Figure 38 : Appel entre composants

Le scnario dchange type (cot serveur) entre les composants est le suivant :
1. Injection de dpendance via la configuration Spring :
a. Les ManagedBeans JSF qui ne connaissent que les interfaces des Services Mtier sont
relies aux Services Mtier (configurs sous forme de beans Spring).
b. Les Services Mtier qui ne connaissent que les interfaces des DAO sont relis aux DAO
Cette injection de dpendance par Spring permet un couplage faible entre les composants et
une volutivit maximale :
Un changement dimplmentation de la couche de persistance (nouvelles classes
de DAO) naurait pas dimpact sur les Services Mtier tant que ces nouveaux
DAO implmentent les mmes interfaces.
De mme une implmentation alternative des Services Mtier (SM) ne ncessite
pas de modifier la couche de prsentation tant que ces classes implmentent les
interfaces des mtier (ISM). Cest dailleurs ce mcanisme qui est utilis en

PAGE
101

mode bouchonn : des bouchons de SM peuvent tre implments pour
simuler les vritables SM (implmentant les ISM) pour les tests et pour
permettre une utilisation en mode maquette de lapplication ainsi que le
paralllisme des dveloppements (ralisation des IHM sans services mtier ni
DAO, ni base de donnes).
2. Les ManagedBeans (MB) sont des objets manags par JSF. Lutilisation de ces beans permet :
laffichage des donnes provenant de la couche mtier ;
le stockage des donnes dun formulaire ;
la validation des valeurs ;
lmission de messages pour la navigation.
Pour tout ce qui concerne les traitements mtier, les ManagedBeans utilisent les Services Mtier
(via leurs interfaces).
3. Les Services Mtier (SM) sont appels (directement) soit par dautres SM soit par les
ManagedBeans (couche prsentation). Leur rle est de proposer un ensemble de services de
manipulation des objets mtier (implmentation des rgles de gestion des objets). Ils peuvent
sappeler les un les autres selon les rgles mtier et la complexit fonctionnelle. Pour tout ce qui
concerne la persistance des objets (recherche, enregistrement, suppression), les Services Mtier
utilisent les DAO (via leurs interfaces).
4. Le DataTransfomer (DT) effectue les traitements de transformation lis lcran (cas
dutilisation). Il peut utiliser un ou plusieurs DAO (en mode lecture) pour rechercher les Objets
Mtier complmentaires au traitement. Il rcupre les objets mtier et les transforme en objet de
prsentation (VO) qui sont retourns la couche prsentation.
5. Les Objets de Prsentation (VO) sont des objets basiques correspondant des listes de
proprits recopies des objets mtier (ils ont ainsi un rle de VO ou Value Object). Ils sont
destins tre transports entre la couche mtier et la couche de prsentation. Aucune
intelligence nest implmente dans ces objets de prsentation : ils neffectuent pas de
contrle fonctionnel.
6. Les Gestionnaires de Persistance (DAO) des objets enregistrent, recherchent ou suppriment les
objets mtier (persistants) en utilisant Hibernate (dans limplmentation actuelle). Ils ne grent
pas les rgles fonctionnelles.
Le diagramme de classes ci-dessous reprend ces diffrents composants, et dcrit leurs dpendances :

PAGE
102


Figure 39 : Diagramme de classes de l'architecture

Rapp

Transféré par

Droits d'auteur :

Formats disponibles

Rapp

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapp

Transféré par

Droits d'auteur :

Formats disponibles

N 99 Juin 2013

Prpar par : Mlle. Sanae EL AZHARI

Vous aimerez peut-être aussi