ensiasVeryGood PDF

Mmoire de Projet de Fin dtudes
Pour lObtention du Titre

DIngnieur dtat en Informatique
Option
Gnie logiciel
Sujet
Automatisation du reporting et la planification des
ressources pour le projet TMA-Maroc Telecom.

Soutenu par : Sous la direction de :
M. Anas AFIF Mme. Bouchra BERRADA(ENSIAS)
M. Souhayl ABDOUNI M. Abdellah SAOUDI (Atos Origin)

Anne Universitaire 2009-2010

Ecole Nationale Suprieure dInformatique
et dAnalyse des Systmes

Projet de Fin dtudes 2009-2010
III
Ddicaces

A mes parents qui m'ont fait au berceau le don, le plus prcieux, celui de la foi.
A mes surs.
A mes grands parents.
A ma famille.
A tous mes amis.
Je ddie ce travail.

ANAS AFIF

IV
Ddicaces

A mes trs chers parents,
Aucun mot ne pourra exprimer mon amour envers vous.

A mon frre et mes surs,
Je vous remercie pour votre amour inconditionnel.

A tous mes collgues de lENSIAS,
Merci pour ces trois annes inoubliables.

Pour tout le soutien que vous mavez offert, vous occuperez pour toujours une
partie dans mon cur.

Souhayl ABDOUNI

V

Remerciements

Cest pour nous un plaisir autant quun devoir de remercier toutes les personnes qui ont
pu contribuer de prs ou de loin llaboration de ce projet, qui nous ont aid, nous ont
soutenu et ont fait en sorte que ce travail ait lieu.
Ainsi, nous tenons exprimer nos sentiments de remerciement notre encadrante
lENSIAS Mme. Bouchra BERRADA, pour les conseils quelle nous a prodigus, son
judicieux encadrement et son assistance pour la rdaction de ce rapport.
Nos remerciements les plus sincres vont M. Abdellah SAOUDI et Mlle. Latifa
FADADI de la filiale marocaine dAtos Origin, pour leurs conseils directifs et formations qui
nous ont t dun grand aide laboutissement de ce projet.
Que tous les membres du jury retrouvent ici lexpression de notre reconnaissance pour
avoir accepter dvaluer notre travail.
Enfin, nos remerciements vont au corps professoral de lENSIAS pour la formation
unique et solide quil nous a prodigue.

6

Rsum
Dans le cadre de notre projet de fin dtudes lcole Nationale Suprieure dInformatique
et dAnalyse des Systmes (ENSIAS) pour lobtention du diplme dIngnieur dtat en
Informatique, nous avons effectu notre stage au sein de la socit Atos Origin.
Ainsi, le prsent document constitue la synthse de notre travail dans le cadre de ce projet
qui a pour objectif de concevoir et de raliser un outil dcisionnel qui permettra
lautomatisation du reporting et la planification des ressources pour le projet TMA-Maroc
Telecom.
Pour bien mener notre projet, nous avons adopt une des mthodes agiles, savoir XP
(eXtreme Programming), dmarche qui a fait ses preuves dans le domaine des projets
informatiques et qui est plus adapte aux quipes rduites avec des besoins changeants.
Nous avons tudi en premier lieu le systme existant ainsi que la base de donnes
existante. En second lieu, nous avons captur les nouveaux besoins et rdig le cahier des
charges. Nous avons ensuite conu le nouveau systme avant de passer la phase de
dveloppement.
En ce qui concerne la mise en uvre de lapplication qui respecte larchitecture J2EE, nous
avons utilis des frameworks libres : Flex pour la couche prsentation, Hibernate pour le
mapping objet/relationnel et Spring pour linjection des dpendances. Par ailleurs, nous avons
utilis la base de donnes relationnelle Oracle 10g.
A travers ce document, nous allons dcrire plus en dtail chaque partie de la ralisation de
ce projet.
Mots-cls : Reporting, Systme dcisionnel, TMA, eXtreme Programming, J2EE.

7

Abstract

As part of our end-study project at the cole Nationale Suprieure d'Informatique et
d'Analyse des Systmes (ENSIAS) for the Diploma in Computer Engineering, we conducted
our training within the ATOS ORIGIN company.
This document is a summary of the work conducted during this project which objective is
to design and implement a decision support system for the TMA-Maroc Telecom project.
To carry out our project, we opted for one of agile software development types, namely XP
(eXtreme Programming), a process that has proven its efficiency in the field of computing
projects and which suits better to small teams with changing needs.
For that purpose, the first step was to study the existing system. The second one was to
capture the needs and to identify the functionalities to improve. The last step was to establish
the specifications before passing to the development.
In order to develop this application, we used several frameworks under the JEE platform:
Flex for the presentation layer, Hibernate for the Object/Relational mapping and Spring for
the dependency injection. We used an Oracle10g relational database.
In this document, we will explain more in detail each step we passed in order to
accomplish this project.

Key words : Reporting, Decision support system, TMA, eXtreme Programming, J2EE.

8

Liste des abrviations
Abrviation Dsignation
AO Atos Origin
API Application Programming Interface
BD Base de donnes
CA Chiffre daffaires
CDC Cahier de charge
CDS Centre de service
CRA Compte rendu dactivits
DEV Dveloppement
DI Demande dintervention
DSI Direction des systmes dinformation
EB Expression de besoin
EF Expression fonctionnelle
EJB Enterprise JavaBeans
FSP Functionnel specifications
IHM Interface homme-machine
J2EE Java 2 Entreprise Edition
JCA Java connector architecture
JDBC Java DataBase Connectivity
JH Jours homme
JMS Java Message Service
JNDI Java Naming and Directory Interface
MEP Mise en production
MOA Matrise douvrage
MT Maroc Telecom
QC Quality Center
RAF Reste faire
SI Systme dinformation
TIG Tests dintgration
TMA Tierce Maintenance Applicative
XML Extensible Markup Language

9

Table des figures
Figure I-1: Historique d'Atos Origin ........................................................................................ 17
Figure I-2: Organigramme Atos Origin.................................................................................... 18
Figure I-3 : Domaines dexpertise ............................................................................................ 19
Figure I-4 : Part de March et Concurrents .............................................................................. 20
Figure I-5: Organigramme du CDS-Rabat ............................................................................... 21
Figure I-6: Dcomposition du systme commercial Maroc Telecom ...................................... 22
Figure I-7: Echange Atos Origin-Maroc Telecom ................................................................... 22
Figure I-8: Mthode de dveloppement XP ............................................................................. 25
Figure I-9: Planning global du projet ....................................................................................... 27
Figure II-1: Contexte dutilisation de QC ................................................................................ 30
Figure II-2: Cycle de vie dune volution ................................................................................ 32
Figure II-3: Cycle de vie dune demande dintervention ......................................................... 34
Figure II-4: Cycle de vie dune anomalie ................................................................................. 36
Figure III-1: Les sources de donnes ....................................................................................... 42
Figure III-2: Diagramme de contexte du module Extraction du chiffre daffaires ............ 46
Figure III-3: Diagramme dactivit de lextraction de la liste des demandes de services cible48
Figure III-4: Diagramme de cas d'utilisation global ................................................................. 52
Figure III-5: Diagramme de cas dutilisation Indicateurs de consommations .................... 53
Figure III-6: Scnario Rapport dextraction ....................................................................... 58
Figure III-7: Scnario Calculer les indicateurs .................................................................. 58
Figure III-8: diagramme de classes : Module Indicateurs de consommation ..................... 60
Figure III-9: diagramme de classes : Module Chiffre daffaires ......................................... 61
Figure IV-1: Architecture Multi tiers ....................................................................................... 65
Figure IV-2: Architecture J2EE ............................................................................................... 67
Figure IV-3: Couches logicielles du systme ........................................................................... 68
Figure V-1: Authentification .................................................................................................... 74
Figure V-2: Pages daccueil ..................................................................................................... 75
Figure V-3: Gestion des employs ........................................................................................... 77
Figure V-4: Ajouter un employ .............................................................................................. 79
Figure V-5: Modifier un employ ............................................................................................ 80
Figure V-6: Extraction des TimeSheets ................................................................................... 80

10

Figure V-7: Rapport de l'extraction des TimeSheets ............................................................... 81
Figure V-8: Les erreurs des TimeSheets .................................................................................. 82
Figure V-9: Les volutions ralises ........................................................................................ 84
Figure V-10: Indicateurs de consommation ............................................................................. 85
Figure V-11: Indicateurs de consommation dtaille .............................................................. 86
Figure V-12: Liste des tches ................................................................................................... 87
Figure V-13: Lextraction du chiffre daffaires ....................................................................... 88
Figure V-14: La liste des volutions dune extraction ............................................................. 90
Figure V-15: Lvolution de chiffre daffaires ........................................................................ 91
Figure V-16: Paramtrage ........................................................................................................ 91
Figure VI-1: Rpartition des responsabilits sur les intervenants dans le projet ..................... 96
Figure VI-2: Planning de la premire itration de livraison ................................................... 105
Figure VI-3: Planning de la deuxime itration de livraison ................................................. 106
Figure VII-1: Cas d'utilisation Administration du systme ............................................... 109
Figure VII-2: Cas d'utilisation Extraction du chiffre daffaires ....................................... 111
Figure VII-3: Scnario Gestion des extractions ................................................................. 113
Figure VII-4: Scnario Gestion des demandes de service .................................................. 113
Figure VIII-1: Exemple dun fichier TimeSheet ................................................................ 114
Figure VIII-2: Cycle de vie d'une volution ........................................................................... 115

11

Liste des tableaux
Tableau I-1: Les avantages du dveloppement itratif et incrmental ..................................... 24
Tableau II-1: Caractristiques dune volution ........................................................................ 32
Tableau II-2: Caractristiques dune DI ................................................................................... 34
Tableau II-3: Caractristiques dune anomalie ........................................................................ 35
Tableau II-4:La composition dune ligne dun fichier TimeSheet ....................................... 37
Tableau II-5:Informations complmentaires dun fichier TimeSheet .................................. 37
Tableau II-6: Dcomposition du projet en modules ................................................................. 40
Tableau III-1: Rgles de remplissage des fichiers TimeSheets ............................................ 43
Tableau III-2: Position du chiffrage sur la BD QC .................................................................. 44
Tableau III-3: Valeurs des champs des statuts ......................................................................... 50
Tableau III-4: Cas dutilisation Extraire la consommation partir des TimeSheets ........... 54
Tableau III-5: Cas dutilisation Afficher les volutions concernes .................................... 56
Tableau III-6: Cas d'utilisation Gestion des tches ............................................................ 57
Tableau III-7: Cas dutilisation Consultation des TimeSheets ............................................. 57
Tableau III-8: Liste des classes du module Indicateur de consommation .......................... 59
Tableau III-9: Liste des classes du module Chiffres daffaires .......................................... 61
Tableau VI-1: Les abrviations utilises dans le PAQ ............................................................. 96
Tableau VI-2: Les objectives qualits applicables au projet .................................................... 97
Tableau VI-3: Les activits qualit .......................................................................................... 98
Tableau VI-4: Les intervenants ct Atos Origin .................................................................... 98
Tableau VI-5: Les intervenants ct ENSIAS ......................................................................... 98
Tableau VI-6: Le comit de pilotage ........................................................................................ 99
Tableau VI-7: Le comit de projet ........................................................................................... 99
Tableau VI-8: Les avantages du dveloppement itratif et incrmentale .............................. 101
Tableau VI-9: Tableau comparatif des mthodes agiles ........................................................ 102
Tableau VII-1: Cas dutilisation Gestion des quipes ...................................................... 110
Tableau VII-2: Cas dutilisation Gestion des employs ................................................... 110
Tableau VII-3: Cas dutilisation Gestion des extractions ................................................ 112
Tableau VII-4: Cas dutilisation Gestion des demandes de service .................................. 112

12

Table des matires
Liste des abrviations ................................................................................................................. 8
Table des figures ........................................................................................................................ 9
Liste des tableaux ..................................................................................................................... 11
Table des matires .................................................................................................................... 12
Introduction gnrale ................................................................................................................ 14
Chapitre I : Contexte gnral du projet ............................................................................... 16
I. Contexte gnral du projet .................................................................................................... 17
I.1 Prsentation dAtos Origin ............................................................................................. 17
I.1.1 Statut et mtiers dAtos Origin ................................................................................ 17
I.1.2 Atos Origin Maroc et CDS-Rabat ............................................................................ 20
I.2 Contexte du projet ........................................................................................................... 22
I.2.1 Cadre gnral du projet ............................................................................................ 22
I.2.2 Objectifs du projet .................................................................................................... 23
I.2.3 Conduite du projet .................................................................................................... 23
Chapitre II : Etude prliminaire ........................................................................................... 29
II. Etude prliminaire ............................................................................................................... 30
II.1 HP Quality Center dans lchange entre Atos Origin et Maroc Telecom .................... 30
II.2 Demandes de services .................................................................................................... 31
II.3 Suivi des demandes de service ...................................................................................... 36
II.3.1 Rle de QC dans le suivi des demandes de services .............................................. 36
II.3.2 Rle des TimeSheets dans le suivi des demandes de service ............................ 36
II.4 Indicateurs de management ........................................................................................... 37
II.4.1 Calcul des indicateurs de consommation ................................................................ 37
II.4.2 Calcul des chiffres daffaires .................................................................................. 38
II.5 Planification et acheminement des tches ..................................................................... 40
II.6 Synthse de ltude prliminaire ................................................................................... 40
Chapitre III : Analyse et conception .................................................................................... 41
III. Analyse et conception ...................................................................................................... 42
III.1 Analyse ......................................................................................................................... 42
III.1.1 Sources de donnes ............................................................................................... 42

13

III.1.2 Gestion des TimeSheets .................................................................................... 42
III.1.3 Indicateurs de consommation ................................................................................ 44
III.1.4 Extraction du chiffre daffaires ............................................................................. 45
III.2 Conception ................................................................................................................... 51
III.2.1 Choix du formalisme UML ................................................................................... 51
III.2.2 Diagrammes UML ................................................................................................. 51
Chapitre IV : Etude technique du projet ............................................................................. 63
IV. Etude technique du projet ................................................................................................. 64
IV.1 Plateforme J2EE ........................................................................................................... 64
IV.1.1 Pourquoi la technologie J2EE ? ............................................................................ 64
IV.1.2 Architecture multi tiers ......................................................................................... 64
IV.1.3 Larchitecture J2EE ............................................................................................... 65
IV.2 Architecture logicielle du systme ............................................................................... 67
IV.2.1 Outils utiliss ......................................................................................................... 69
Chapitre V : Ralisation et mise en uvre .......................................................................... 72
V. Ralisation et mise en uvre ............................................................................................ 73
V.1 Dmarche de dveloppement ........................................................................................ 73
V.2 Interfaces graphiques ..................................................................................................... 74
Conclusion et perspectives ....................................................................................................... 92
Bibliographie ............................................................................................................................ 93
Annexe 1 - Plan assurance qualit ............................................................................................ 95
Annexe 2 - UML .................................................................................................................... 107
Annexe 3 - Description des cas dutilisation .......................................................................... 109
Annexe 4 - Documents et figures ........................................................................................... 114
Annexe 5 - Dossier de Livraison ............................................................................................ 116

Introduction gnrale

14

Introduction gnrale
Dernirement, lentreprise moderne connat de nouveaux dfis notamment mthodologiques
afin de faire les bons choix. Cest pour cette raison que lentreprise essaie de construire son
systme dcisionnel afin damliorer sa performance, sa robustesse et sa productivit. Ainsi
lentreprise doit dcider et anticiper en fonction de linformation disponible et capitaliser sur
ses expriences pour prendre des dcisions certaines et efficaces.
Dans ce sens, plusieurs outils ont vu le jour pour aider lentreprise tirer partie des donnes
stockes sur diffrents supports dinformations.
Cest dans cette vision que sinscrit notre projet de fin dtudes. Il vise mettre en place un
systme dcisionnel permettant Atos Origin de suivre lvolution de lefficacit de ses
prestations de services.
Spcialement, ses prestations de services par rapport au contrat TMA (Tierce maintenance
applicative) qui la lie Maroc Telecom. En effet, pour rendre son systme dinformation
commercial adaptable une volution continue du march tlcom au Maroc, Maroc Telecom
a mis en place un projet de maintenance applicative pour ce SI vital.
Pour la bonne marche de ce projet, Atos Origin rserve un nombre consquent de
collaborateurs qui travaillent sur les diffrents projets lis ce contrat de maintenance
applicative. Ainsi, pour garantir ces projets les meilleures conditions de russite, les
responsables Atos Origin produisent mensuellement des rapports mentionnant toutes les
informations utiles, concernant les travaux qui ont t effectus au cours du mois par les
diffrents collaborateurs, tels que : la qualit des livraisons, la productivit, les dlais de
rsolution, les dlais de prise en charge des demandes de service, le respect des engagements
et le respect des charges. Toutes ces informations seront trs utiles lors des runions des
diffrents comits de pilotage pour une prise de dcision stratgique et efficiente.
Notre projet de fin dtudes sarticule autour de la mise en place et le dploiement dun
systme dcisionnel pour lautomatisation des calculs dindicateurs et du reporting. Il offre
galement aux chefs de projets un outil pour faciliter laffectation des tches et ainsi respecter
les dlais contractuels de traitement des demandes du client.
Introduction gnrale

15

Le prsent rapport dcrit lessentiel du travail ralis lors de ce projet. Il comporte cinq
chapitres :
Le premier prsente le contexte gnral du projet, o nous prsentons lorganisme
daccueil, le cadre gnral du projet, ses objectifs ainsi que le processus de
dveloppement adopt
Le deuxime aborde ltude prliminaire, o il sera question de donner une vue sur
lexistant
Le troisime traite les parties analyse et conception
Le quatrime traite ltude technique du projet o les concepts techniques cls du
projet sont exposs
Le dernier chapitre contient une explication de la dmarche suivie dans le
dveloppement et une prsentation de quelques interfaces.
Le plan dassurance qualit et dautres informations indispensables la bonne comprhension
de notre projet sont prsents en annexe.

Chapitre 1 Contexte gnral du projet

16

Chapitre I
Contexte gnral du projet

Dans ce premier chapitre nous prsentons lorganisme daccueil, le cadre gnral du projet, ses objectifs
ainsi que la conduite de travail adopte pour ce projet.


17

I. Contexte gnral du projet
I.1 Prsentation dAtos Origin
I.1.1 Statut et mtiers dAtos Origin
a. Statut
Atos Origin est la fusion entre les socits Atos (cre en 1997 entre deux socits franaises
de services informatiques, Axime et Sligos) et Origin (cre en 1996, filiale de Royal Philips
Electronics) en Octobre 2000. Elle figure parmi les chefs de file des socits internationales
de services informatiques. Depuis, le Groupe a acquis KPMG Consulting au Royaume Uni et
aux Pays-Bas en 2002 et le Groupe Sema en 2004.

Figure I-1: Historique d'Atos Origin
[Atos Origin, 2009]
Actuellement, Atos Origin est lun des principaux acteurs internationaux du secteur des
services informatiques. Sa mission est de traduire la vision stratgique de ses clients en
rsultats, grce lutilisation des solutions de conseil, dintgration des Systmes et
dinfogrance les plus connu.
[Atos Origin, 2009].

Atos Origin est une Socit Anonyme, Directoire et Conseil de Surveillance. Elle sorganise
selon lorganigramme suivant :

18

Figure I-2: Organigramme Atos Origin
[Atos Origin, 2009]

b. Mtiers dAtos Origin
Les principales activits dAtos Origin sont :
Le Conseil
Atos Origin offre des services et solutions de bout en bout , allant du dveloppement de
stratgies jusquau choix de solutions et de technologies appropries en passant par la refonte
des processus fonctionnels.
Ses clients sont ainsi en mesure damliorer leur productivit et de gnrer davantage de
valeur grce une approche innovante des processus mtiers, conjugue une intgration
performante des technologies, ainsi que par des investissements stratgiques en ressources
humaines. Ainsi, Atos Origin par sa branche consulting (Atos Consulting) sassure que tous
les aspects dune organisation ressources humaines, processus et technologie sont
entirement aligns sur la stratgie de lentreprise.
[Atos Origin, 2009]
Lintgration des systmes
Atos Origin a une vaste exprience en matire dintgration des personnes, des processus et
des technologies, ce qui lui permet de concevoir, de btir et dexploiter des solutions pratiques
et robustes. Ainsi, ses spcialistes travaillent avec les clients sur le dveloppement, le
dploiement et la maintenance de leurs systmes.
[Atos Origin, 2009]


19

Linfogrance
Atos Origin offre des services de prise en charge de la gestion des infrastructures
informatiques cls des clients : centres de donnes, assistance micro-informatique, parcs de
serveurs et rseaux de communication.
La socit fournit, travers son rseau mondial, des services accessibles 24h/24 et 7j/7, et
dispose dune exprience ingale en matire de dploiement des solutions complexes multi-
sites.
c. Domaine dexpertises
Atos Origin a une vraie exprience dans les systmes dinformations, et elle est prsente dans
plusieurs domaines :

Figure I-3 : Domaines dexpertise
[Atos Origin, 2009]

d. Part de March et Concurrents
Selon lentreprise amricaine Gartner, Atos Origin tait la cinquime socit de services
informatiques en Europe en 2007. Ce classement prend en compte leffet de la fusion entre
HP et EDS.
Le classement dAtos Origin en termes de parts de march dans les services informatiques en
Europe occidentale stablissait alors comme suit :

20

Figure I-4 : Part de March et Concurrents
[Atos Origin, 2009]

I.1.2 Atos Origin Maroc et CDS-Rabat
a. Atos Origin Maroc
Prsente depuis 2003 au Maroc, Atos Origin a su tablir des relations de partenariat durable
avec des acteurs locaux en sappuyant sur des comptences locales. Les centres de services de
Casablanca et Rabat, en pleine expansion, fournissent des prestations de services en
intgration de systmes et infogrance.
Atos Origin Maroc renforce la capacit dAtos Origin pour servir la clientle francophone
(France, Belgique, Suisse) appartenant aux secteurs financiers, des tlcommunications, du
secteur public, de lindustrie, de lautomobile et de la distribution.
Atos Origin est leader sur le march Marocain et compte aujourdhui 450 personnes et
sinscrit dans une forte dynamique de croissance, avec un objectif datteindre un effectif de
1000 collaborateurs en 2010.
[Atos Origin, 2009]

b. CDS-Rabat
Notre projet de fin dtudes sest droul au sein du centre de services Atos Origin Rabat. Ce
centre est ddi aux missions dintgration de systmes. Ainsi les quipes travaillant au
niveau de ce centre de services ont pour rle de concevoir, dvelopper et maintenir les
systmes dinformations des clients. Parmi les clients de ce CDS, nous pouvons citer : Maroc
Telecom, BNP PARIBAS, la TGR, la Direction gnrale des impts, lAgence spciale
Tanger Mditerrane(TMSA) et lOCP.

21

Pour une meilleure gestion de ses ressources, une meilleure rponse aux besoins des clients et
vu la longueur des contrats qui le lie ses clients, le CDS-Rabat adapte son organisation par
rapport aux projets en cours.
La figure ci-dessous montre lorganisation actuelle du CDS-Rabat.
Figure I-5: Organigramme du CDS-Rabat
[Atos Origin, 2009]
DG
Denis Clnet
Projets TMA

Chef de projet :
Philipe Ducrocq

Projets hors TMA

Chef de projet :
Bouchra Bouzoubea
Equipe
Activation
Equipe
Ticketing
Equipe
Design
Equipe tests
dintgration

Projets hors
MT

Projets
MT
Projet
TMSA
Projet
OCP
Projet
TGR
Projet
Migration
Oracle 10g
Projet
Mutualisation
Equipe
Build

22

I.2 Contexte du projet
I.2.1 Cadre gnral du projet

Actuellement, Atos Origin est lie Maroc Telecom par un contrat de TMA. Selon ce contrat,
Atos Origin sengage assurer un suivi permanant du SI commercial de Maroc Telecom. Ce
systme est subdivis en deux sous systmes (figure I-6) ; le premier traitant la tlphonie fixe
et lautre la tlphonie mobile.

Figure I-6: Dcomposition du systme commercial Maroc Telecom
Dans les chapitres qui suivent, nous utiliserons frquemment les mots mobile et fixe. Ils
font rfrence cette dcomposition du SI commercial Maroc Telecom, prsente ci-dessus.
Lchange entre Atos Origin et Maroc Telecom dans le cadre de ce contrat est dcrit dans la
figure I-7.

Figure I-7: Echange Atos Origin-Maroc Telecom
Demandes de
service
Envoy par MT
- Planification et engagement
- Ralisation
- Suivi
- Livraison
- Qualification

- Test dintgration
- Validation
Mise en
production
facturation
Envoy MT
SI COMMERCIAL MT
SI
COMMERCIAL
FIXE

SI
COMMERCIAL
Mobile


23

Les demandes de services peuvent tre de 3 types:
Une volution
Une demande dintervention (DI )
Une correction.
Ces diffrents types vont tre amplement expliqus dans les chapitres venir.
I.2.2 Objectifs du projet
Ainsi, notre projet de fin dtudes vise mettre en place un systme dcisionnel pour le projet
TMA-Maroc Telecom afin dautomatiser le calcul des indicateurs de suivi pour les diffrentes
interventions (volution, correction,..) dAtos Origin sur le SI commercial Maroc Telecom. Il
devra prendre en compte plusieurs aspects tels que:
La qualit des livraisons (lie au nombre des anomalies dtectes sur une livraison)
La productivit des quipes et des dveloppeurs
Les dlais de rsolution
La ractivit dAtos Origin par rapport la prise en charge des demandes du client
Le respect des engagements contractuel
Le respect des charges.
Ce systme sera trs utile aux responsables Atos Origin. Il offre dune part une vue globale
sur lavancement des projets leur permettant une meilleure prise de dcision, et dautre part,
une meilleure gestion de projet.
I.2.3 Conduite du projet
a. Dmarche de dveloppement
Avant de choisir une dmarche de dveloppement, nous avons jug utile de mener une tude
sur lapproche itrative et incrmentale.
Cette tendance peut tre justifie par les avantages quoffre un dveloppement itratif et
incrmental et qui seront rsums dans le tableau de la page suivante :


24

Avantage
La communication est de
meilleure qualit.
Les malentendus, les incomprhensions et les incohrences sont
rapidement mis en vidence; il est donc encore possible de les
corriger.
Lutilisateur a la possibilit de clarifier ses demandes de services au
fur et mesure.
Le client reoit des preuves tangibles de lavancement du
projet.
La visibilit est meilleure.

Le client peut ainsi visualiser les travaux plus rgulirement, au fil
de leau, sans attendre la fin du projet, puisqu la fin de chaque
itration, les fonctionnalits retenues sont dveloppes, testes,
documentes et valides.
La qualit est value en
continu.
Les tests sont effectus chaque itration, les anomalies dtectes
sont corriges au fur et mesure.
Les risques sont dtects
trs tt.
Grce aux activits de dveloppement prcoces, les risques sont
dtects tt et rsolus rapidement.
Lquipe prend confiance.
Litration donne une occasion dapprendre, donc de capitaliser ou
dadapter les pratiques pour la suite du projet.
Le changement nest plus une menace, mais au contraire, cest une
opportunit de mieux faire et de mieux satisfaire le client.
Les cots sont contrls.
Les cots sont limits, en termes de risques, au primtre de
litration.
Sil faut reprendre une itration, on ne perd que les efforts de cette
itration et non la valeur du produit dans sa globalit.
Tableau I-1: Les avantages du dveloppement itratif et incrmental [Roques et al, 2007]
Ensuite, nous nous sommes intresss un certain type de dmarches itratives et
incrmentales, regroupes sous le nom de mthodes agiles.
Afin davoir une ide plus complte sur les mthodes agiles existantes, nous avons dress un
tableau comparatif des mthodes les plus rpandues actuellement (voir Tableau V-9).
En considration du cahier des charges retenu et de sa subdivision en modules relativement
indpendants, ces mmes modules tant subdiviss en plusieurs tches de courte moyenne
dure, la mthode XP nous a paru le choix le plus adapt la nature de notre projet.

25

Faisant partie des mthodes agiles, XP vise rduire le cycle de vie du logiciel, tout en
acclrant son dveloppement par la mise en place dune version minimale. Cette version est
ensuite enrichie itrativement, chaque fois que de nouvelles fonctionnalits apparaissent.
La mthode XP fournit aussi des pratiques permettant de dvelopper dans des conditions
optimales. Elle est base sur les principes suivants :
Le cycle de travail est court
Les livraisons des versions sont une frquence leve
Lquipe de dveloppement travaille sur la base de binmes
Le dveloppement est divis en itrations de livraison
Litration de livraison se dcompose en quatre phases : phase dexploration, phase
dengagement, phase de pilotage et phase de livraison (une prsentation plus dtaille
de ces phases figure sur lAnnexe 1).
Pour plus de clart, la dmarche XP est prsente sur la figure suivante.

Figure I-8: Mthode de dveloppement XP
Scnario
Planification
de livraison
Intgration
Phase
dexploration
Phase
dengagement
Phase de pilotage Livraison
Nouvelle itration de livraison
Itration
Conception
Tests
Codage
Analyse
Tests de
recette
Plan
ditration
Feedback
Bugs
Client
Itration de livraison

26

b. Application de la mthode
Chaque itration de livraison prend en compte un seul module dans lensemble des modules
que nous devons accomplir. Pour ce module, nous proposons diverses solutions qui sont
valides par le chef de projet, avant dentamer le codage de la solution retenue. Les tests de
fonctionnement global sont raliss une fois que la mise en uvre est termine.
c. Planification du projet
La planification du projet est parmi les phases davant projet. Elle consiste prvoir le
droulement du projet tout au long des phases constituant le cycle de dveloppement.
Conformment au processus de dveloppement adopt, nous avons pu dterminer les
diffrentes tapes du projet, qui peuvent tre rsumes en deux itrations de livraison.
La figure suivante (figure I-9) prsente le planning prvisionnel global des diffrentes
itrations de livraison. Pour plus de dtails sur les plannings de ces itrations, veuillez
consulter lAnnexe 1.

27

Figure I-9: Planning global du projet


28

Conclusion
Dans sa globalit, le sujet consiste mettre en place un systme dcisionnel pour le projet
TMA-Maroc Telecom. Pour la bonne conduite du projet, la mthode de dveloppement
adopte est la mthode XP. Cette mthode permet un dveloppement incrmental par la mise
en place dune version minimale, puis en intgrant les fonctionnalits par un processus itratif
bas sur lavnement de nouvelles fonctionnalits.
Le contexte global du projet tant expos, le deuxime chapitre traitera ltude prliminaire de
ce projet, composante essentielle lanalyse du systme.
Chapitre 2 Etude prliminaire

29

Chapitre II
Etude prliminaire

Dans ce chapitre, nous prsentons une tude prliminaire du projet compose de ltude de lexistant, des
problmatiques et enfin de la synthse.


30

II. Etude prliminaire
II.1 HP Quality Center dans lchange entre Atos Origin et Maroc
Telecom
Les prestations de services dAtos Origin sur le projet TMA-Maroc Telecom sont bases sur
les demandes que Maroc Telecom publie sur un support web mis en place pour grer sa
communication avec lensemble de ses sous-traitants. Ce support web se base sur un produit
HP intitul Quality Center (QC) destin normalement lautomatisation des tests logiciels,
actuellement adapt par Maroc Telecom afin de rpondre ce nouveau besoin.
HP Quality Center joue un rle primordial dans le bon fonctionnement du projet TMA-Maroc
Telecom, vu que lensemble des changes entre Maroc Telecom et Atos Origin se font via cet
outil. Ainsi, Maroc Telecom lutilise pour grer ses demandes de services destines Atos
Origin.
Un rcapitulatif du rle de QC dans cet change dinformations entre Atos Origin et Maroc
Telecom est prsent dans le schma de la figure II-1.

Consultation
des demandes
Chiffrage et suivi
des demandes
Cration dune
demande de services
(volution, DI,
corrections)
Suivi des demandes
de services.
HP QUALITY CENTER
Figure II-1: Contexte dutilisation de QC

31

Il est noter que les demandes de services Maroc Telecom pour les deux SI mobile et fixe
sont traites sur deux instances de HP QC diffrentes.
II.2 Demandes de services
Les demandes de services, adresses Atos Origin via HP QC, sont sauvegardes sur une
table portant le nom REQ de la BD QC. Une prsentation plus dtaille de cette table sera
dveloppe dans les chapitres venir. Ces demandes de services peuvent tre de trois types :
volution, demande dintervention ou anomalie.
a. Evolution
Soumission des volutions Atos
Chaque fin de mois, la DSI Maroc Telecom recense lensemble des demandes de
modification exprimes par les utilisateurs de son SI commercial.
Elle soumet lquipe Design (voir figure I-5) dAtos Origin par le biais de QC cet
ensemble de demandes sous forme dexpressions de besoins concernant un changement, un
ajout ou une suppression dune fonctionnalit sur le systme existant.
Aprs tude, un palier mensuel appel palier de ralisation est tabli conjointement avec
Maroc Telecom contenant un ensemble dvolutions planifier pour un mois donn.
Le palier est soumis au chef de lquipe Build (voir figure I-5) qui le distribue aux chefs
quipes. Ces derniers subdivisent chaque volution en tches et les affectent aux employs.
Aprs cette tape, toutes les volutions dun palier ont un statut Valid.
Le dveloppeur reoit dans un mail la liste des tches qui lui sont affectes. Il com
mence prendre en charge la tche, ayant la priorit la plus grande et change le statut de la
demande de services laquelle cette tche est lie En dveloppement .
Caractristiques dune volution
Caractristiques Description
Identifiant Identifie une volution
Palier de
ralisation
Regroupe un ensemble dvolutions planifies pour un mois donn.
Statut Spcifie ltat davancement dune volution, reprend les tats de la figure II-2.
Chiffrage est exprim en J*H, il reprsente le nombre de jours de travail estim pour
quun dveloppeur achve le dveloppement de lvolution. Ce chiffrage ne
prend pas en compte le temps consomm lors des autres phases de
dveloppement savoir le design et TI G (tests dintgration).
Description Exprime le rsultat attendu de lvolution.
reste faire Le nombre de jours estim pour finir lvolution.
Commentaire Optionnel.
Responsable Le responsable du suivi de lvolution ct Maroc Telecom

32

Maroc Telecom
Responsable
design
Le responsable de la conception de la solution ct Atos Origin.
Responsable TI G Le responsable des tests dintgration ct Atos Origin.
Dveloppeur Le dveloppeur responsable de lvolution ct Atos Origin.
Date de livraison La date limite pour livrer Maroc Telecom lvolution.
Tableau II-1: Caractristiques dune volution
Cycle de vie dune volution
Une volution passe par un ensemble de statuts tout au long de sa vie. Normalement, sous un
statut donn, une volution est sous la responsabilit dune seule entit sauf dans certains cas
o elle est sous la responsabilit conjointe de deux entits.
Un rcapitulatif de lensemble des statuts du cycle de vie dune volution est prsent sur le
schma de la figure II-2( voir aussi sur Annexe 4).

Figure II-2: Cycle de vie dune volution
b. Demande dintervention (DI)
Soumission des DI Atos Origin
Maroc Telecom peut nimporte quel moment demander lintervention rapide et instantane
(Astreinte, modification technique, modification dune interface) dAtos Origin sur un
sujet bien prcis. Cette demande tant diffrente des volutions, elle ne ncessite ni tude, ni

33

TI G et passe directement au dveloppement pour tre ensuite livre. Ce genre de demandes de
services est appel DI : demande dintervention.

34

Caractristiques dune DI

Caractristique Description
Identifiant Identifie une DI
Statut
Spcifie ltat davancement dune DI , reprend les tats de la
figure II-3.
Chiffrage est exprim en JH et reprsente le nombre de jours de
dveloppement estim pour quune ressource achve la
DI .
Reste faire
Le nombre de jours estim pour finir la DI .
Description
Exprime le rsultat attendu de lvolution.
Ressource La ressource responsable du dveloppement de la DI .
Date de livraison
La date limite pour livrer Maroc Telecom la DI .
Tableau II-2: Caractristiques dune DI
Cycle de vie dune demande dintervention

Le cycle de vie dune DI est prsent sur le schma de la figure II-3.

Figure II-3: Cycle de vie dune demande dintervention

DI initi DI en analyse

DI valider

DI valide

DI en DEV

DI livre

DI dispo pour
MEP

DI clture
DSI Atos

35

c. Anomalie :
Soumission des anomalies Atos Origin
Chaque jour un ensemble danomalies est ouvert sous QC dcrivant un disfonctionnement
dune partie du systme. Ces anomalies sont destines tre traites par lquipe de
dveloppement pour y apporter correction.
Cet ensemble est achemin et distribu par le responsable correctif Atos Origin selon le
domaine et la disponibilit de la ressource. Tout en ajoutant chaque anomalie la date
prvue de livraison.
Caractristiques dune anomalie

Caractristiques Description
Identifiant Identifie une anomalie
Chiffrage Le nombre de jours hommes estim ncessaire pour corriger
lanomalie.
Date de livraison Date limite pour livrer la correction Maroc Telecom.
Date dacceptation La date o ATOS ORI GI N a accept lanomalie pour tre
corrige.
Date de fin relle Parfois une anomalie ne respecte pas la date de livraison
souhaite. Dans ce cas elle a une de la date de fin relle.
Reste faire Le nombre de jours estim pour finir la tche en cours.
Commentaire Optionnel.
Gravit Mineure, moyenne, critique, majeure
Statut
Exprime ltat davancement dune anomalie, reprend les tats de la
figure II-4.
Tableau II-3: Caractristiques dune anomalie

Cycle de vie dune anomalie

36

Une anomalie a un cycle de vie trs simple comme le montre la figure II-4.

Figure II-4: Cycle de vie dune anomalie
II.3 Suivi des demandes de services
Une fois quune tche est affecte au dveloppeur, il doit rendre un feed-back aux
responsables dAtos Origin pour les maintenir au courant de son avancement. Cela est fait
par le biais de deux supports dinformation. Le premier tant le QC et le second est un
fichier, sur lequel sont traces les activits journalires dune ressource, appel
TimeSheet ou CRA (compte rendu dactivits).
II.3.1 Rle de QC dans le suivi des demandes de services
Chaque ressource, affecte au projet TMA-Maroc Telecom au niveau dAtos Origin, a un
accs QC afin dapporter les changements ncessaires (des changements de statuts en
gnral) sur les diffrentes demandes de services sur lesquelles celle-ci travaille.
Cela permet aux responsables Atos Origin davoir une ide gnrale sur lavancement
globale des diffrentes demandes de services en cours. Mais aussi de pouvoir remonter le
nombre exact des diffrentes demandes de services en cours de dveloppement, en phase
de TI G ou celles qui doivent tre livres Maroc Telecom.
II.3.2 Rle des TimeSheets dans le suivi des demandes de service
Actuellement, les diffrentes ressources Atos Origin saisissent sur des fichiers Excel
lensemble des activits quelles ont ralises durant une journe. Chaque TimeSheet
est relatif aux activits ralises pendant un mois donn.
a. Structure du fichier TimeSheet
Un fichier TimeSheet est compos de plusieurs lignes. Chaque ligne reprsente une
tche et indique sa distribution dans le temps. Une tche concerne une seule phase de
dveloppement qui peut tre ltude, le dveloppement ou les TI G.
Une ligne dun TimeSheet reprsente une tche et doit comporter les informations
suivantes (tableau II-4) :

Anomalie
initie
Anomalie
affecte
Anomalie
En DEV
Anomalie
livre
DSI Atos

37

Information Description
Projet Dans notre cas, nous nous intressons aux tches lies au projet TMA-
Maroc Telecom
Type de la
tche
Etude, dveloppement, TI G, etc.
Statut en cours , termine .
RAF Le nombre de jours estim pour finir la tche en cours
REQ_QC Lidentifiant QC de la demande de services laquelle cette tche est
lie.
Tableau II-4:La composition dune ligne dun fichier TimeSheet
En plus des informations mentionnes plus haut, la ressource doit apporter au fichier les
informations suivantes (tableau II-5) :
Information Description
Nom et prnom Nom et prnom du propritaire du fichier
Trigramme Un ensemble de trois lettres identifiant un employ de manire
unique.
Mois et anne Mois et anne cibles
Tableau II-5:Informations complmentaires dun fichier TimeSheet
Il est noter quun exemple de fichier TimeSheet est prsent sur lAnnexe 4.
II.4 Indicateurs de management
II.4.1 Calcul des indicateurs de consommation
a. Objectifs du calcul des indicateurs de consommation
Le chiffrage dune demande de services est enregistr sur la BD QC. Il reprsente le
nombre de J H sur lequel Maroc Telecom et Atos Origin se sont mis daccord pour traiter
cette demande. Cependant, le temps rel consacr cette dernire et la rpartition de ce
temps sur les diffrentes phases de dveloppement, ne peuvent tre extraits de la base QC.
Ce qui serait intressant pour les responsables Atos Origin. Do le rle principal des
TimeSheets .

38

Ainsi, en regroupant lensemble de linformation contenue dans ces fichiers, il serait
possible de calculer le consomm rel dune demande de services et de reconstruire sa
rpartition sur lensemble des phases de dveloppement.
Ces informations permettront aux responsables Atos Origin, non seulement de dtecter les
demandes de services qui ont drap par rapport leurs chiffrages, mais aussi de connaitre
la phase exacte du drapage, ainsi que le ou les employs qui en sont responsables.
Il est noter que le chiffrage contenu dans la base QC ne concerne que la phase du
dveloppement (codage). Le chiffrage rel est calcul en ajoutant le temps des phases
dtude et de TI G.
b. Inconvnients et risques de la mthode actuelle
Ce calcul des indicateurs de consommation est fait actuellement la main. Mais, plusieurs
complications peuvent fausser ce calcul :
Linformation par rapport une seule demande de services est parpille sur
plusieurs fichiers
Un nombre important de fichiers consulter pour extraire linformation
Une information non consolide sur les TimeSheets
Un temps considrable pour extraire linformation.
Pour toutes les raisons cites plus haut, Atos Origin a dcid dautomatiser la partie
concernant le calcul des indicateurs de consommation. Ainsi, notre mission est de fournir
aux responsables Atos Origin un systme leur permettant davoir :
Une vision globale et dtaille sur toute la dur de vie des demandes de services
Des indicateurs de rentabilit qui vont aider la gestion des diffrents projets.
II.4.2 Calcul des chiffres daffaires
a. Notion dextraction
Chaque fin de semaine, les responsables Atos Origin procdent lextraction de
lensemble des demandes de services (volutions et DI ) qui ont t dveloppes durant la
semaine. Cette extraction va tre explique de manire dtaille dans le chapitre III.
b. Objectif de lextraction
En se basant sur les chiffrages et les statuts de ces diffrentes demandes de services
extraites, il serait possible de calculer pour chaque type de demande:
Le nombre de J H qui a t chiffr aux diffrentes demandes de services

39

Le nombre de J H consacr aux demandes de services quAtos Origin sest
engages dvelopper. Ce nombre est calcul en multipliant le chiffrage de chaque
demande par une valeur boolenne qui indique si Atos sest engag dvelopper la
demande ou non.
Le nombre de J H consacr aux demandes de services quAtos Origin a livres
Maroc Telecom. Ce nombre est calcul en multipliant le chiffrage de chaque
demande par une valeur boolenne qui indique si Atos a livr la demande ou non.
Vision Maroc Telecom : ce nombre est calcul partir des chiffrages des demandes
de services et dpend aussi des statuts.
Tous ces indicateurs seront dtaills dans les chapitres qui suivent.
c. Lvolution des chiffres daffaires
En se basant sur les chiffres daffaires calculs dans une suite dextractions, les
responsables Atos Origin peuvent construire la courbe dvolution des chiffres daffaires
pour une priode donne.
d. Inconvnients de la mthode dextraction actuelle
Actuellement, les extractions sont faites la main. Ce qui induit sans aucun doute la
lenteur de la gnration des rsultats. De plus, vu la complexit des calculs et le grand
nombre de demandes de services concernes par une extraction, il serait facile dtre
induit en erreur ce qui peut fausser les calculs et ainsi causer des dcisions errones. Et le
plus important, cest le temps que consomme cette tche aux responsables Atos Origin ; un
temps qui doit tre investi dans linterprtation des rsultats.
Pour toutes les raisons cites plus haut, Atos Origin a dcid dautomatiser la partie
concernant le calcul des chiffres daffaires ainsi que le reporting pour afficher lvolution
de ces chiffres.

40

II.5 Planification et acheminement des tches
Au niveau dAtos Origin, lensemble des changes entre les dveloppeurs et les chefs de
projet se font par le biais de mail.
Les responsables Atos Origin veulent changer cette situation en ajoutant notre projet de
fin dtudes un module pour aider les chefs de projet avoir une meilleure fluidit pour la
programmation des nouvelles tches et offrir aux dveloppeurs une source centralise pour
consulter les tches qui leur sont affectes.
II.6 Synthse de ltude prliminaire
Pour remdier aux problmes cits ci-dessus et pour amliorer le systme de prise de
dcisions pour le TMA-Maroc Telecom, Atos Origin a dcid de mettre en place une
solution qui assurera les fonctionnalits suivantes:
Le calcul et le reporting des chiffres daffaires
Le calcul des indicateurs de consommation, en prenant en compte la productivit
des quipes, le respect des engagements et le respect des charges
La mise en place dune solution pour la planification et lacheminement des
tches.
Ainsi, nous avons dcompos notre projet en trois modules :
Module Objectifs
Module calcul des chiffres daffaires Calcul et reporting des chiffres daffaires
Module indicateurs de consommation Calcul et reporting des indicateurs de
consommation
Module planification Planification et acheminement des tches
Tableau II-6: Dcomposition du projet en modules
Conclusion
Cette tude prliminaire nous a permis de bien cerner le sujet et de dgager les principales
fonctionnalits utiles pour la mise en place de notre projet. Nous entamons dans le chapitre
suivant les phases danalyse et de conception.
Chapitre 3 Analyse et conception

41

Chapitre III
Analyse et conception

Le prsent chapitre est consacr la description de laspect fonctionnel travers une analyse, des
diagrammes des cas dutilisation et des diagrammes de squences. Nous terminerons ce chapitre par les
diagrammes de classes qui dfinissent la structure interne de notre systme.


42

III. Analyse et conception
III.1 Analyse
III.1.1 Sources de donnes
Le systme dvelopper se base sur deux sources de donnes :
La BD QC : plus prcisment les deux tables REQ (celle du projet Fixe et
celle du projet Mobile) sur lesquelles sont enregistres les demandes de
services ainsi que les tables AUDIT_LOG et AUDIT_PROPERTIES qui
contiennent lhistorique de la base
Les TimeSheets
La base QC est une proprit Maroc Telecom sur laquelle nous navions pas de droits de
modification et il fallait apporter des changements au niveau du schma de cette base, afin
dy ajouter les diffrentes informations provenant des TimeSheets. De ce fait, nous
avons opt pour la cration dune base locale, qui va regrouper lensemble des donnes
provenant de la base QC et servira comme support de stockage des informations contenues
dans les TimeSheets.

III.1.2 Gestion des TimeSheets
Etant donn que les TimeSheets regroupent lensemble de linformation sur laquelle
nous nous basons pour extraire les diffrents indicateurs de consommation, la saisie de ces
fichiers doit respecter des rgles strictes.
a. Consolidation de linformation sur les fichiers TimeSheets
Actuellement, chaque quipe remplit les TimeSheets en respectant des rgles internes.
Mais puisque le systme dvelopp va grer lensemble des quipes, nous nous sommes
mis daccord avec les responsables Atos Origin de mettre en place des rgles globales
respecter. Le tableau ci-dessous rsume lensemble de ces rgles :
Base
locale
Mobile
TimeSheets
Fixe
QC
Figure III-1: les sources de donnes

43

Champ Type de
demande
de
services
Modle respecter Commentaire
Phase Evolution FC
Pour diffrencier les volutions des
autres demandes de service. Toute
activit lie une volution doit porter
sur le champ Phase la valeur FC.
Libell
de la
tche
Evolution
QCXXXX:Phase[intitul de la tche] XXXX : Lid identifiant
lvolution sur la table REQ,
Phase: actuellement Etude, DEV
ou TI G. Mais, le systme doit tre
capable de grer de nouvelles
phases,
[intitul de la tche] : Optionnel.
Phase DI
DI
Pour diffrencier les DI des autres
demandes de service. Toute activit
lie une DI doit porter sur le champ
Phase la valeur DI.
Libell
de la
tche
DI
DIXXXX:Phase[intitul de la tche]

XXXX : Lid identifiant
phases,
Phase Anomalie
ANO Pour diffrencier les anomalies des
autres demandes de service. Toute
activit lie une anomalie doit porter
sur le champ Phase la valeur
ANO.
Libell
de la
tche
Anomalie
- Si anomalie de recette (lie une
volution) :
QCXXXX/ANOYYYY:Phase[intitul
de la tche].
-Sinon :
ANOYYYY[intitul de la tche]
XXXX : Lid identifiant
YYYY : Lid identifiant
l'anomalie sur la table REQ
phases,
Tableau III-1: Rgles de remplissage des fichiers TimeSheets


44

b. Erreurs remontes par le systme
Le systme doit remonter deux types derreurs savoir :
Erreurs de non respect des rgles de remplissage des fichiers TimeSheets : Le
systme doit remonter pour chaque employ, les erreurs commises sur son
TimeSheet.
Erreurs dabsence des TimeSheets : le systme doit dtecter les employs qui
nont pas dpos leurs fichiers.
III.1.3 Indicateurs de consommation
a. Rappel des objectifs
Le module Indicateurs de consommation a pour objectif :
Le calcul du consomm rel des demandes de services
Remonter la rpartition de ce consomm sur les phases de dveloppement
Le calcul du consomm global dune priode donne, ainsi que sa rpartition
par rapport aux phases de dveloppement
La dtection des demandes de services ayant drap (consomm rel >
chiffrage rel)
La dtection des phases qui ont caus le drapage
Le calcul du coefficient de productivit (consomm rel / chiffrage), pour tout
le cycle du dveloppement ainsi que pour chaque phase
La consolidation de linformation contenue sur les fichiers TimeSheets.
b. Chiffrage initial dune demande de service
Le chiffrage initial (en J H) est affect une demande de services par un consensus entre
Maroc Telecom et Atos Origin. Ce chiffrage est enregistr sur la table REQ de la BD de
QC (voir le tableau ci-dessous).
Instance de QC Colonne chiffrage Type de la colonne
Fixe RQ_USER_21 VarChar(40)
Mobile RQ_USER_03 VarChar(40)
Tableau III-2: Position du chiffrage sur la BD QC
Le chiffrage sur la BD QC ne reprsente que le chiffrage de la phase de dveloppement
(codage) quon va appeler un chiffrage initial. Le chiffrage rel (incluant les autres
phases restantes) est calcul actuellement par la rgle suivante :

45

Chiffrage rel = chiffrage initial * 1,43.
Le 43% reprsente le pourcentage de ltude et des tests. Ainsi une demande de services
aura respect les dlais si les rapports (consomm DEV /chiffrage initial) et (consomm
(TI G et tude)/chiffrage initial*0,43) sont gaux 100%.
c. Calcul du consomm rel
Consomm global
Le consomm rel dune demande de services est la somme de la dure des diffrentes
tches qui lui sont affectes. Les informations dtailles sur ces dernires se trouvent sur
les TimeSheets .
Rpartition du consomm rel par phase
Puisque la phase de chaque tche est prcise au niveau des TimeSheets et en
regroupant les tches ralises par demande de service, le systme pourra ressortir le
consomm dune demande par rapport une phase prcise.
d. Calcul des diffrents indicateurs de consommation par
rapport une priode
En regroupant toutes les donnes des TimeSheets , le responsable a une vision globale
sur une priode donne et peut remonter les informations suivantes :
Le consomm global de cette priode
Le consomm par phase de dveloppement
La consommation moyenne de chaque phase
Le pourcentage de consommation de chaque phase pour cette priode
Le coefficient de productivit de chaque phase.
e. Formules de calcul des drapages du consomm
La formule gnrale pour calculer le drapage global dune demande est :
Drapage global = consomm de la demande de services chiffrage rel.
La formule gnrale pour calculer le drapage dune demande dans une phase prcise:
Drapage dune phase = (chiffrage initial * % de la phase par rapport au cycle de
dveloppement global) consomm rel de la phase.
III.1.4 Extraction du chiffre daffaires
Chaque fin de semaine, Atos Origin procde lextraction de lensemble des demandes de
services (volutions et DI ) commandes par Maroc Telecom sur les deux projets (mobile

46

et fixe). Cette extraction se fait suivant des rgles prcises que nous expliciterons
ultrieurement. Le rsultat de cette extraction va servir calculer plusieurs types de
chiffres daffaires :
Le chiffre daffaires total
Le chiffre daffaires engag
Le chiffre daffaires livr
Le chiffre daffaires de la vision Maroc Telecom.
Tous ces types vont tre exhaustivement expliqus dans les paragraphes qui suivent.
Le diagramme de contexte suivant illustre les principales tapes de lextraction du chiffre
daffaires.

a. Procdure dextraction des demandes de services
On appellera intervalle-cible le temps entre la date de la dernire extraction et la date
systme.
Responsable production
Mise jour
BD locale
Calcul chiffre
daffaires pour
la priode
courante
Crer, modifier
statuts
Evolution des
chiffres daffaires
Systme
1
2
3
2.1
Figure III-2: Diagramme de contexte du module Extraction du chiffre daffaires

47

Lextraction du chiffre daffaires consiste dans un premier lieu dgager les demandes de
services qui ont connu des modifications par rapport lintervalle-cible. Pour le faire, nous
procdons tout dabord la mise jour de la base de donnes locale partir de la base QC.
Ensuite, nous nous basons sur lhistorique gr au niveau QC par deux tables
(AUDIT_LOG et AUDIT_PROPERTIES) afin dextraire les demandes de services
concernes.
Cette opration doit respecter plusieurs rgles et passer par plusieurs tapes afin dobtenir
la liste des demandes de services qui vont figurer dans lextraction:
Etape 1 :
Extraction des demandes de services ayant la date de modification dans lintervalle-
cible :
Champ date de modification appartient lintervalle-cible
Champ fournisseur gal Atos ou vide.
Etape 2 :
Sassurer que chaque demande de services appartient la TMA de lanne courante :
Si cest le cas, nous la recherchons dans la dernire extraction du chiffre
daffaires
- si elle nexiste pas, elle sera rajoute la liste
- si elle existe, nous remontons son chiffrage dans la dernire extraction
pour le comparer au chiffrage actuel:
sil est diffrent, cette demande est mise jour dans toutes les
extractions de lanne courante et rajoute la liste
si non, elle est rajoute la liste.
Si non, nous vrifions si son chiffrage a t modifi
- Si cest le cas, elle est enleve de la liste et le systme remonte une
alerte
- si non, elle est enleve de la liste.

Le diagramme dactivits ci-dessous illustre les rgles dextraction de la liste des
demandes de services:

48

Figure III-3: Diagramme dactivits de lextraction de la liste des demandes de services cibles

49

b. Calcul du chiffre daffaires
Le chiffre daffaires est calcul suivant les statuts des demandes de service. Chaque statut
est dfini par :
Un nom: le libell du statut
Un PSF (pourcentage sur phase): il dfinit ltat davancement de la demande de
services en commenant par le statut initi qui a un PSF gal 0% jusqu
En production avec un PSF gal 100%
Une valeur boolenne qui indique si Atos Origin sest engage dvelopper cette
demande de services
Une valeur boolenne qui indique si cette demande de services est livre ou non
Vision MT : cest un pourcentage similaire au PSF sauf que cest du point de vue
Maroc Telecom.
Le tableau ci-dessous illustre les valeurs des diffrents champs des statuts :
Statut
Engag Livr PSF
%
DSG en cours
0 0 0
EB MOA valide
0 0 0
Attente EB MOA
0 0 0
A envoyer au fournisseur
0 0 0
A tudier par DSI
0 0 0
En dev MT
0 0 0
CDC valid
0 0 0
Attente Chiffrage Fournisseur
0 0 0
FSP valider par DSI
0 0 0
A valider par MT
0 0 0
EF valider par MOA
0 0 0
A valider par DSC
0 0 0
EF valide par MOA
0 0 0
FSP Valide
1 0 24
Valide
1 0 24
En Dev
1 0 24
En TIG
1 0 24
Dispo pour pr-recette
1 0 24
Livre
1 1 85
En recette
1 1 85
Livre/annule
1 1 85
Dispo pour MEP
1 1 85
En production
1 1 100
Annule
en
partie
en
partie
en
partie

50

Attente prcision DSC
en
partie
0 en
partie
Attente prcision DSI
en
partie
0 en
partie
Attente prcision MOA
en
partie
0 en
partie
Attente prcisions MT
en
partie
0 en
partie
Gele
en
partie
en
partie
en
partie
Stand by
en
partie
en
partie
en
partie
Valide Interne
1 en
partie
en
partie
Valide interne SI
1 en
partie
en
partie
DI valider
1 1 100
DI clture
1 1 100
DI dispo pour MEP
1 1 100
DI en analyse
1 1 100
DI en dv
1 1 100
DI initie
0 0 0
DI livre
1 1 100
DI valide
1 1 100
Tableau III-3: Valeurs des champs des statuts
Il existe trois types de chiffre daffaires :
Le chiffre daffaires total = ( (chiffrage de la demande de service)*PSF)*1.43
Le chiffre daffaires engag = ( (chiffrage de la demande de
service)*PSF*Engag)*1.43
Le chiffre daffaires livr = ( (chiffrage de la demande de
service)*PSF*Livr)*1.43
Vision client = ( (chiffrage de la demande de service)*(Vision MT)).
Si la demande de services est une DI , le chiffrage est multipli par 1 au lieu de 1,43 car
cest une simple modification qui ne ncessite que la phase de dveloppement (codage).
Maintenant que nous avons dgag les diffrents besoins fonctionnel, nous entamerons la
phase de conception.

51

III.2 Conception
III.2.1 Choix du formalisme UML
Du moment que notre application est base sur une architecture Web oriente objet, nous
avons opt pour le langage de modlisation UML, acronyme de Unified Modeling
language ou en franais Langage de modlisation unifi (voir Annexe 2). En effet,
UML est le langage graphique de modlisation des donnes et des traitements le plus
adapt aux applications orientes objet. Par ailleurs, UML prsente bien dautres atouts
notamment :
UML est un langage formel et normalis
Gain en prcision
Gage de stabilit
UML est un support de communication performant
Il cadre l'analyse
Il facilite la comprhension de reprsentations abstraites complexes
Son caractre polyvalent et sa souplesse en font un langage universel.
Notre tude comprend le diagramme de cas dutilisation, les diagrammes de squences,
ceux dactivits et le diagramme de classes.
III.2.2 Diagrammes UML
a. Diagrammes de cas dutilisation
Puisque le systme traitera les deux volets du contrat TMA fixe et mobile et que chaque
volet est grer par un responsable part, les acteurs humains agissant sur le systme sont :
Responsable de la production
Responsable de la production du projet Fixe.
Responsable de la production du projet Mobile.
Pour prsenter les relations entre les diffrents modules de notre application, nous avons
tabli le digramme de cas dutilisation global suivant (figure III-4) :

52

Figure III-4: Diagramme de cas d'utilisation global

53

Ce diagramme dcrit brivement les fonctionnalits du systme ainsi que lassociation des
acteurs et des modules.
Afin dclaircir le diagramme ci-dessus, nous avons dtaill chaque module part dans
des diagrammes de cas dutilisation. Nous prsentons dans cette section un exemple
Indicateurs de consommation , les autres figurent en Annexe 3.
Diagramme de cas dutilisation: Indicateurs de consommation
Le diagramme de cas dutilisation ci-dessous illustre lorganisation des fonctionnalits du
module Indicateurs de consommation :

Figure III-5: Diagramme de cas dutilisation Indicateurs de consommations
Afin dclaircir le diagramme ci-dessus, nous avons dtaill chaque cas dutilisation part
dans des tableaux explicatifs. Nous prsentons dans la section suivante les cas
dutilisations les plus importants.


54

i. Dtails du cas dutilisation Extraction des TimeSheets

Cas dutilisation : Extraction des TimeSheets
But : Extraire les donnes relatives la consommation partir des TimeSheets.
Acteur : Responsable de la production.
Pr-condition :
- Lacteur est authentifi
- Au moins un TimeSheet est dpos au niveau du serveur.
Post-condition :
- Toute modification sera stocke dans la base de donnes.
Scnarii principaux
1. Extraction des TimeSheets
a. Le responsable accde au menu Extraction des TimeSheets.
b. Le systme lui demande de saisir le mois pour lequel il souhaite faire lextraction.
2. Rapport de lextraction
a. Le systme parcourt les fichiers Excel afin dextraire les tches effectues par les employs
ainsi que leur consommation et les diffrentes informations qui leurs sont relatives.
b. Le systme affiche ensuite le rsultat de la validation des TimeSheets qui contient trois
listes :
Les TimeSheets absents : les employs qui nont pas dpos leurs TimeSheets
Les TimeSheets valides : les employs ayant des TimeSheets corrects
Les TimeSheets errons : les employs nayant pas respect les rgles de
remplissage des TimeSheets.
3. Communiquer les rsultats aux employs
a. Le responsable peut ensuite alerter les employs qui nont pas dpos leurs TimeSheets.
b. Il peut afficher les emplacements prcis des erreurs dun employ pour ensuite extraire ces
donnes dans un fichier Excel afin de lui envoyer le rapport de la validation de son
TimeSheet.
Tableau III-4: Cas dutilisation Extraire la consommation partir des TimeSheets


55

ii. Dtails du cas dutilisation Gestion des demandes de service

Cas dutilisation : Gestion des demandes de service
But : Afficher les diffrentes demandes de services sur lesquelles les employs ont travaill, ainsi
que les diffrents indicateurs de consommation et enfin les tches qui ont t effectues sur chaque
demandes de service.
Acteur :
Responsable de la production Fixe
Responsable de la production Mobile.
Pr-condition :
- Le Responsable est authentifi
- Lextraction des TimeSheets est dj effectue.
Scnarii principaux
1. Lister les demandes de service
a. Le responsable accde au menu Demandes de service.
b. Par dfaut, le systme affiche les demandes de services relatives aux tches qui ont t
excut durant une priode dun mois (le mois courant).
c. Le responsable peut spcifier une priode cible, pour afficher les demandes de services
qui ont t dvelopp durant cette priode.
d. Il aura cette liste de demandes de services avec des informations telles que : Le nom, la
priorit, le statut et le chiffrage.
e. Il a aussi un filtre paramtrable par colonne qui va lui permettre de filtrer la liste et
ainsi changer dynamiquement les valeurs des indicateurs quon va dcrire ci-dessous.
2. Calculer les indicateurs
a. Le responsable choisit dafficher les indicateurs globaux, il aura ensuite un tableau
contenant la liste des indicateurs suivant :
Le chiffrage total des demandes de services affiches
La consommation totale des demandes de services affiches
La consommation par phase de dveloppement (par dfaut, les phases de
dveloppement sont ltude, le dveloppement (codage) et les tests, mais ces
phases sont gres dynamiquement suivant les phases ajoutes par le
responsable)
La consommation moyenne par phase
Le pourcentage de consommation de chaque phase.

56

b. Sil choisit dafficher les indicateurs dtaills, il aura ensuite un tableau qui contient la
liste des demandes de services ainsi que les indicateurs de consommation dtaills pour
chacune savoir :
Le chiffrage
la consommation de chaque phase de dveloppement
la consommation totale
le reste faire
le chiffrage rel
le drapage total et le drapage de chaque phase
le coefficient entre le consomm et le chiffrage.
Il aura aussi une notification sur les demandes de services qui ont un drapage, ainsi
que la possibilit dextraire tout le tableau vers un fichier Excel.
Tableau III-5: Cas dutilisation Afficher les volutions concernes
iii. Dtails du cas dutilisation Gestion des tches

Cas dutilisation : Gestion des tches
But : Afficher les diffrentes tches dune demande de service, ainsi que les diffrents indicateurs
de consommation.
Acteur :
Responsable de la production Fixe
Responsable de la production Mobile.
Pr-condition :
- Le Responsable est authentifi
- Lextraction des TimeSheets est dj effectue.
Scnarii principaux
1. Lister les tches
a. Le responsable choisit dafficher les tches dune demande de service. Il aura une liste
des tches relies cette demande avec les informations suivantes: Le nom de la tche,
lemploy qui la effectu, le reste faire, ltat (termin ou bien en cours), la phase de
dveloppement et la consommation.
2. Calculer les indicateurs de consommation
a. Le responsable a aussi un tableau, dindicateur pour la demande de services en cours de

57

consultation, contenant les informations suivantes :
Consommation globale de cette demande de services
Consommation par phase
Pourcentage de consommation de chaque phase.
Tableau III-6: Cas d'utilisation Gestion des tches
iv. Dtails du cas dutilisation Gestion des TimeSheets

Cas dutilisation : Consulter les TimeSheets
But : Consulter les TimeSheets.
Acteur : Responsable de la production
Pr-condition :
- Loprateur est authentifi
- Au moins une extraction des TimeSheets a t faite.
Scnarii principaux
3. Consulter les TimeSheets
a. Le responsable accde au menu Consultation des TimeSheets , le systme lui
demandera de choisir le mois pour lequel il souhaite consulter les TimeSheets.
b. Il aura ensuite trois listes similaires celle qui suit lextraction des TimeSheets avec
les mmes fonctionnalits (voir le dtail du cas dutilisation Extraire la consommation
partir des TimeSheets ):
Les TimeSheets valides
Les TimeSheets errons
Les TimeSheets absents.
Tableau III-7: Cas dutilisation Consultation des TimeSheets
b. Diagrammes de squences
La description textuelle elle seule ne suffit pas puisquil est difficile dy montrer
comment les enchanements se succdent. De plus, la maintenance des volutions savre
souvent fastidieuse. Cest pour cette raison quil est recommand de complter la
description textuelle par des diagrammes de squences systme.
Nous prsenterons ci-dessous quelques diagrammes de squence, les diffrents autres
diagrammes de squences labors sont en Annexe 3.

58

i. Scnario Rapport dextraction

Figure III-6: Scnario Rapport dextraction
Le Scnario Rapport dextraction est le scnario principal du cas dutilisation
Extraction des TimeSheets , car le rsultat de lextraction va se rpercuter sur
lauthenticit des indicateurs. De ce fait, le responsable doit sassurer que tous les
employs ont dpos des TimeSheets valides.
ii. Scnario Calculer les indicateurs

Figure III-7: Scnario Calculer les indicateurs

59

Le Scnario Calculer les indicateurs est le scnario principal du module Indicateurs
de consommation . En effet, ce scnario dcrit les diffrents indicateurs sur lesquels le
responsable se base afin de solliciter les diffrentes quipes de dveloppement.
c. Diagrammes de classes
Le diagramme de classes montre la structure interne du systme. Il permet de fournir une
reprsentation abstraite des objets du systme, qui vont interagir ensemble pour raliser les
cas dutilisation.
i. Module : Indicateurs de consommation
Daprs lanalyse faite prcdemment, le systme doit possder une classe Employ .
Chaque employ peut tre affect une quipe reprsente par la classe Equipe. Les
TimeSheets dun employ sont reprsents par la classe TimeSheet qui est lie une
liste dobjets Erreurs qui reprsente les erreurs du TimeSheet dun employ.
Dun autre ct, les demandes de services seront reprsentes par deux classes
DemandeServiceMobile et DemandeServiceFixe . Chaque demande de services est
lie un objet Projet et compose dune plusieurs dobjets Tche . Chaque tche est
son tour lie une liste de tches quotidiennes DailyTask et une phase de
dveloppement Phase ainsi qu lemploy qui a excut cette tche. Enfin, il y a la
classe Historique qui va contenir tous les modifications effectues sur les demandes de
service.
A ce stade, nous pouvons dterminer les classes candidates du diagramme de classe:
Classe Description
Employ Reprsente un employ dAtos Origin
Equipe Elle permet la gestion des quipes
DemandeServiceMobile Reprsente les demandes de services du projet Mobile
DemandeServiceFixe Reprsente les demandes de services du projet Fixe
Projet Reprsente les projets auxquels sont lies les demandes de
services
Tche Reprsente les tches effectues par un employ sur une
demande de service
DailyTask Reprsente les sous-tches dune tche
Phase Reprsente les phases de dveloppement
Historique Permet de grer lhistorique des demandes de services
TimeSheets Reprsente le TimeSheet dun employ
Erreurs Reprsente les erreurs dun TimeSheet
Tableau III-8: Liste des classes du module Indicateur de consommation
La figure de la page suivante reprsente le diagramme de classes que nous avons pu
laborer aprs une tude dtaille des fonctionnalits du systme.

60

Figure III-8: diagramme de classes : Module Indicateurs de consommation

61

Le traitement des deux types de demandes de services est diffrent, de plus que les deux
classes se composent de plus de 90 attributs qui ne sont pas similaires, alors nous avons
jug prfrable de travailler avec deux classes spares.
ii. Module : Chiffre daffaires
Le systme doit possder une classe Extraction qui reprsente une extraction une
date donne. Cette extraction concerne une liste de demandes de services reprsentes par
la classe DemandeService . Chaque demande de services sera relie un statut
reprsent par la classe Statut et enfin la classe Erreurs qui reprsente les erreurs
dune extraction.
A ce stade, nous pouvons dterminer les classes candidates du diagramme de classe:
Classe Description
Extraction Reprsente une extraction
DemandeService Reprsente les demandes de services incluses dans une extraction
Statut Reprsente les diffrents statuts dune demande de services
Erreurs Reprsente les erreurs dune extraction
Tableau III-9: Liste des classes du module Chiffres daffaires
La figure suivante prsente le diagramme de classes que nous avons pu laborer aprs une
tude dtaille des fonctionnalits du systme.

Figure III-9: diagramme de classes : Module Chiffre daffaires
Conclusion
Dans ce chapitre, nous avons prsent les diffrents diagrammes labors qui nous ont
permis de cerner les diffrentes fonctionnalits du futur systme avant de passer la phase

62

de ralisation. Dans le chapitre suivant, nous abordons larchitecture du systme et nous
prsentons les diffrents outils utiliss.
Chapitre 4 Etude technique du projet

63

Chapitre IV
Etude technique du projet

Ce chapitre met la lumire sur la plateforme utilise et les outils de dveloppement adopts fin de
mettre en uvre lapplication

64

IV. Etude technique du projet
IV.1 Plateforme J2EE
IV.1.1 Pourquoi la technologie J2EE ?
Les entreprises recherchent, de plus en plus, des solutions qui permettent la diminution des
cots et la rduction du temps de rponse, tout en respectant les standards de qualit
logicielle.
Typiquement, les applications qui rpondent ces besoins doivent combiner entre les
systmes dinformation existants et les nouvelles fonctions mtiers, qui apportent des
services un large intervalle des utilisateurs. Ces services doivent tre :
Fortement disponibles, pour rpondre aux besoins actuels de lenvironnement
mtier
Scuriss, pour protger les utilisateurs et lintgrit des donnes dentreprise
Fiables et extensibles, pour sassurer que les transactions sont excutes dune
manire exacte et prompte.
Pour des raisons diverses, ces services sont conus bases dapplications distribues
reposant sur plusieurs niveaux savoir la couche client, la couche donnes et une ou
plusieurs couches intermdiaires.
[Idrissi et al, 2008]

IV.1.2 Architecture multi tiers
Le concept de larchitecture multi tiers vient pour remdier aux problmes de la
maintenance, de la rutilisation et de la monte en charge : ce quon appelle scalabilit ,
dune application. Les applications bases sur ce type darchitecture sont divises en
plusieurs niveaux logiques. Chacun deux comporte un ensemble dinterfaces bien dfini,
savoir la couche client, la couche donnes et une ou plusieurs couches intermdiaires.
Le niveau intermdiaire (logique applicative) est simplement constitu du code appel par
lutilisateur (via le niveau prsentation) pour extraire les donnes utiles. Le niveau
prsentation reoit ensuite les donnes et les met en pages, en vue de leurs affichages.
Cette sparation de la logique applicative de linterface utilisateur accentue
considrablement la souplesse de conception dune application. En effet, il est dsormais
possible de crer et de diffuser plusieurs interfaces utilisateurs sans modifier la logique
applicative, condition toutefois, que cette dernire soit dote dune interface strictement
dfinie avec le niveau intermdiaire.
Enfin, le troisime niveau contient les donnes ncessaires lapplication. Il peut sagir de
toute source dinformations prsente sous nimporte quelle forme : base de donnes
relationnelle, ensemble de documents XML ou encore service de rpertoires tel quun
serveur LDAP.
[Boutayeb et al, 2009]


65

Figure IV-1: Architecture Multi tiers
IV.1.3 Larchitecture J2EE
J2EE, acronyme de Java 2 Enterprise Edition, est une norme propose par la socit
Sun, porte par un consortium de socits internationales, visant dfinir un standard de
dveloppement d'applications d'entreprises multi-niveaux.
[Oracle Corporation, 2010]

Cette plate-forme est fortement oriente serveur et ddie au dveloppement et
l'excution d'applications distribues. Elle permet la simplification du processus de
dveloppement. En effet, J2EE simplifie le contrle et la gestion des ressources systme
en fournissant des mthodes permettant de grer les transactions et la mise en commun des
ressources. Ainsi, l'utilisation de J2EE pour dvelopper et excuter une application
propose plusieurs avantages :
Une architecture d'application base sur les composants qui permet un dcoupage
de l'application et donc une sparation des rles lors du dveloppement
La possibilit de s'interfacer avec le systme d'information existant grce de
nombreuses API : JDBC, JNDI, JMS, JCA, etc.
La possibilit de choisir les outils de dveloppement et le ou les serveurs
d'applications utiliss qu'ils soient commerciaux ou libres
Couche Prsentation
Couche mtier
Couche accs aux
donnes
Source de
donnes

66

Une solution optimale pour dvelopper des applications robustes, scurises et
volutives.
Dans la mesure o J2EE s'appuie entirement sur Java, il bnficie des avantages et
inconvnients de ce langage, en particulier une bonne portabilit et une maintenabilit du
code. De plus, l'architecture J2EE repose sur des composants distincts, interchangeables et
distribus, ce qui signifie notamment que :
Il est simple d'tendre l'architecture
Un systme reposant sur J2EE peut possder des mcanismes de haute
disponibilit, afin de garantir une bonne qualit de service
La maintenabilit des applications est facilite
Il est possible de factoriser le code et utiliser des frameworks ou composants
gnriques (gain de temps et de performances).
En effet, choisir cette technologie, cest suivre un certain nombre de rgles. Le but est en
effet de sparer au maximum lapplication en couches.
J2EE permet une grande flexibilit dans le choix de l'architecture de l'application en
combinant les diffrents composants. Ce choix dpend des besoins auxquels doit rpondre
l'application mais aussi des comptences dans les diffrentes API de J2EE. L'architecture
d'une application se dcoupe idalement en au moins trois tiers (voir figure IV-1):
La partie cliente : il sagit de la couche prsentation correspondante l'interface
homme machine (IHM), c'est la partie qui permet le dialogue avec l'utilisateur. Elle
peut tre compose d'une application standalone, d'une application web ou
d'applets
La partie mtier : c'est la partie qui encapsule les traitements (dans des EJB ou des
JavaBeans)
La partie donnes : c'est la partie qui stocke les donnes dans des fichiers, dans des
bases de donnes relationnelles ou XML, dans des annuaires d'entreprise ou encore
dans des systmes d'information complexes.


67

Figure IV-2: Architecture J2EE
IV.2 Architecture logicielle du systme
Une architecture logicielle exprime un schma dorganisation structurel fondamental pour
les systmes logiciels. Elle savre indispensable pour la bonne comprhension, la gestion
et loptimisation de tout systme.
Pour structurer notre systme, nous avons opt pour un dcoupage en couches. Ceci est
galement justifi par larchitecture J2EE adopte. En Outre, une architecture en couches
Couche de prsentation
Composant dinterface utilisateur
Composant de comportement
Couche mtier
Interface de services
Ordonnancement mtier
Composant mtier
Couche daccs aux donnes
Composant daccs aux donnes
Stockage de donnes
Bases de donnes
Application


68

favorise la maintenabilit de lapplication et la rutilisation en adoptant les solutions
trouves aux problmes ayant un fonctionnement similaire.

La figure suivante prsente larchitecture logicielle adopte :

Figure IV-3: Couches logicielles du systme
Couche prsentation
Cette couche correspond la partie de l'application visible et interactive avec les
utilisateurs. On parle d'Interface Homme-Machine. Dans la plupart des cas, il sagit dune
interface client riche ou dune interface web. La couche prsentation relaie les requtes de
lutilisateur destination de la couche mtier, et en retour prsente lutilisateur les
informations renvoyes par les traitements de la couche mtier. Il sagit donc ici dun
assemblage de services mtier et applicatifs offerts par la couche infrieure.
En ce qui concerne notre application, nous avons ralis cette couche laide du
framework Flex.
Couche mtier
Elle constitue la couche principale de toute application. Elle correspond sa partie
fonctionnelle, celle qui implmente la logique et qui dcrit les oprations que
l'application opre sur les donnes en fonction des requtes des utilisateurs effectues au
travers de la couche prsentation. Les diffrentes rgles de gestion et de contrle du
systme sont mises en uvre dans cette couche. La couche mtier offre des services
applicatifs et mtier la couche prsentation. Pour fournir ces services, elle s'appuie, le
cas chant, sur les donnes du systme, en retour, elle renvoie la couche prsentation

69

les rsultats qu'elle a calculs. Dans notre cas, limplmentation de la logique mtier est
ralise grce des objets mtier et des objets DAO (Data Access Object) ou Objets
daccs aux donnes. Un DAO est un design pattern (patron de conception) utilis dans les
architectures logicielles objet visant isoler la logique de persistance dans des classes
daccs aux donnes. Il s'agit surtout de ne pas crire ces accs dans les classes "mtier",
qui ne seront modifies que si les rgles de gestion mtier changent.
L'utilisation de la couche DAO permet de s'abstraire de la faon dont les donnes sont
stockes au niveau des objets mtier.
Couche accs aux donnes
Elle consiste en la partie grant l'accs aux donnes du systme. La couche mtier n'a pas
s'adapter avec la manire de gestion des donnes, celle-ci est transparente pour la couche
mtier qui accde aux donnes de manire uniforme grce la couche daccs aux
donnes, galement appele couche de persistance. Cest ce niveau que lon trouve les
fonctionnalits de base qui permettent de crer, rechercher et supprimer des entits mtier
dans le respect des proprits transactionnelles. Cest galement dans cette couche que les
mcanismes de conversion objet/relationnel peuvent prendre place. Le rle de cette couche
est dfini comme suit :
Assurer les services basiques de cration, lecture, mise jour et suppression
Permettre la conversion Objet/Relationnel.
Pour limplmentation de cette couche, nous avons utilis le framework Hibernate qui
permet de raliser le mapping des donnes et garantir leur persistance.
Couche donnes
La dernire couche est celle des donnes. Celles-ci sont destines durer dans le temps, de
manire plus ou moins longue, voire dfinitive. Les donnes peuvent tre stockes
indiffremment dans de simples fichiers texte, des fichiers XML, ou encore dans une base
de donnes. Elle est gre dans notre cas par le SGBDR Oracle.
IV.2.1 Outils utiliss
Afin de mettre en uvre notre systme en suivant larchitecture explique dans la section
prcdente, nous avons utilis les outils suivants :
Base de donnes Oracle 10g
IDE : Eclipse Europa
Frameworks: Flex builder 2, Hibernate, Spring et Xfire.
a. Oracle
Oracle est un SGBD (systme de gestion de bases de donnes) dit par la socit du
mme nom (Oracle Corporation), leader mondial des bases de donnes.

70

La socit Oracle Corporation a t cre en 1977. Elle s'appelle alors Relational Software
Incorporated (RSI) et commercialise un Systme de Gestion de Bases de donnes
relationnelles (SGBDR ou RDBMS pour Relational Database Management System)
nomm Oracle.
Comparativement ses concurrents, Oracle est extrmement gourmand en ressources
(mmoire et disque), il permet dassurer la manipulation, la confidentialit, lintgrit et la
cohrence des donnes. Il gre aussi les accs concurrents ainsi que la sauvegarde et la
restauration des donnes.
b. Framework Spring
Spring est un puissant framework Open Source, qui simplifie considrablement la
programmation J2EE. La premire version de Spring a t publie en 2004 par Rod
Johnson et Juergen Holler. En trs peu de temps, Spring simposa comme un framework
incontournable. Il rsout les problmes rcurrents prsents sur toutes les couches dune
application (prsentation, logique mtier, accs aux donnes) et facilite lintgration des
frameworks Java les plus utiliss (Struts, Hibernate, iBatis).
[Dubois et al, 2004]

Outre la rduction impressionnante du volume de code technique, Spring Framework
implique lutilisation des bonnes pratiques de programmation ce qui favorise lcriture des
applications structures et volutives.
c. Framework Hibernate
Hibernate est un framework open source grant la persistance des objets en base de
donnes relationnelles. Cest un outil de mapping objet/relationnel pour le monde Java. Le
terme mapping objet/relationnel (ORM) dcrit la technique consistant faire le lien entre
la reprsentation objet des donnes et sa reprsentation relationnelle base sur un schma
SQL.
[JBoss Entreprise, 2010]

Hibernate se compose de plusieurs modules dvelopps par des quipes diffrentes : Core,
Annotations, Tools, Entity manager, Shards, Validator. Hibernate permet de manipuler les
donnes d'une base de donnes relationnelles sous forme d'objet. Pour ce faire, il utilise
des fichiers pour relier la base aux objets. Le fait de manipuler directement les donnes
d'une base sous forme d'objets est beaucoup plus pratique, cela permet au dveloppeur de
dfaire de toute la couche SQL. De plus, il permet de dfinir clairement la limite entre la
persistance et la couche mtier, ce qui se rvle trs utile dans le cas d'une application
trois-tiers. Hibernate est trs populaire notamment cause de ses bonnes performances et
de son ouverture avec de nombreuses bases de donnes.
d. Framework Flex
Flex est un framework Open Source gratuit qui permet de crer des applications web ultra-
interactives et expressives se dployant de manire identique sur la plupart des
navigateurs, postes de travail et systmes d'exploitation.

71

Flex offre un modle de programmation volu qui repose sur des langages standard et
gre les modles de conception courants. MXML, langage dclaratif bas sur XML, sert
dcrire l'agencement et le comportement de l'interface utilisateur tandis que le langage de
programmation orient objet ActionScript 3.0 est employ pour la cration de fonctions de
traitement ct client. Flex inclut en outre une riche bibliothque de composants
comprenant plus d'une centaine d'lments d'interface utilisateur volutifs rservs la
cration d'applications Internet riches (RIA) ainsi qu'un dbogueur interactif d'applications
Flex.
Les RIA cres avec Flex s'excutent dans le navigateur l'aide d'Adobe Flash Player ou
en dehors de celui-ci via l'environnement d'excution multiplate-forme Adobe AIR,
garantissant une relle homognit sur la plupart des navigateurs et postes de travail.
Install sur plus de 98 % des ordinateurs connects Internet, Flash Player est un moteur
d'excution client de qualit professionnelle, comprenant des fonctionnalits vectorielles
avances, capable de grer les plus exigeantes applications fort pourcentage de donnes
sans ralentir la cadence.
e. Xfire
Web services
Un service web est un programme informatique permettant la communication et l'change
de donnes entre applications et systmes htrognes dans des environnements distribus.
Il s'agit donc d'un ensemble de fonctionnalits exposes sur internet ou sur un intranet, par
et pour des applications ou machines, sans intervention humaine et en temps rel.
Xfire
Xfire est un framework Java SOAP libre qui peut exporter un simple objet Java en tant
que service web. XFire sintgre facilement avec Spring et permet un dploiement trs
simple des web services.
[Mak, 2008]

Conclusion
Aprs avoir dcrit larchitecture technique du systme et cit les diffrents outils avec
lesquels nous lavons implment, le chapitre suivant sera consacr la mise en uvre.
Chapitre 5 Ralisation et mise en uvre

72

Chapitre V
Ralisation et mise en
uvre

Ce chapitre est consacr la description de la phase de mise en uvre de lapplication. Nous y
dcrivons la dmarche suivie pendant la ralisation et nous illustrons certaines fonctionnalits assures
travers quelques interfaces.


73

V. Ralisation et mise en uvre
V.1 Dmarche de dveloppement
Afin de mieux organiser la phase de mise en uvre, nous avons veill procder par
tapes.
Ainsi, nous avons procd de la manire suivante pendant la phase de dveloppement:
Cration des beans et des fichiers de mapping
partir du modle conu, nous avons dvelopp en premier lieu les beans du systme
ainsi que leurs fichiers de mapping, qui vont tre la rfrence dHibernate pour le
mapping Objet-relationnel.
Cration du schma de la base
Le schma de la base de donnes est gnr automatiquement par Hibernate partir des
fichiers de mapping.
Cration du package DAO
La couche DAO est indpendante des beans. Nous avons une seul Classe DAO qui va
grer laccs de toutes les entits la base de donnes, en utilisant les sessions
contextuelles dHibernate qui permettent de grer les transactions dune faon autonome.
Implmentation de la couche mtier
Durant cette tape, nous avons traduit les fonctionnalits du systme en mthodes java.
Celles-ci ont t testes au fur et mesure afin de nous assurer de leur bon
fonctionnement.
Ralisation des interfaces
Dans cette tape, nous avons dvelopp les interfaces graphiques suivant le modle quon
a tabli dans la partie conception, en tenant compte des besoins de ladministrateur.
Intgration des interfaces avec la couche mtier
Nous avons ensuite intgr les deux couches prsentation et mtier par le biais des web
Services.


74

V.2 Interfaces graphiques
Durant cette section, nous prsentons un scnario dutilisation de lapplication par
quelques interfaces.
Authentification
Quand lutilisateur se connecte, la page suivante de lauthentification apparat :

Figure V-1: Authentification
Cette figure correspond linterface dauthentification qui permet au responsable douvrir
une session et daccder au systme.
Pages daccueil
Linterface de la page suivante est la page daccueil qui apparait directement aprs
lauthentification

75

Figure V-2: Pages daccueil

76

Cette figure est la page principale de lapplication. Elle contient trois menus :
Administration : il est destin ladministration gnrale de lapplication. Il
contient trois sous-menus savoir la gestion des employs, des quipes, des
domaines et des phases de dveloppement
Indicateurs de consommation : il est destin lextraction et la gestion des
TimeSheets, ainsi que la consulter les diffrents indicateurs de consommations
Chiffre daffaires : Pour lextraction et le suivi du chiffre daffaires et la gestion
des statuts.
Gestion des employs
La gestion des employs permet ladministrateur de dfinir les diffrentes informations
sur les diffrents employs existant

77

Figure V-3: Gestion des employs

78

Cette interface permet ladministrateur de voir la liste des employs, de les modifier et
de les affecter des quipes.
Ajouter un employ
Linterface de la page suivante permet dajouter un nouvel employ. Ladministrateur doit
saisir le Nom, le Trigramme, le Matricule et lquipe.

79

Figure V-4: Ajouter un employ

80

Modifier un employ
Cette interface permet de modifier un employ. Ladministrateur peut modifier le Nom, le
Trigramme, le matricule ou bien lquipe.

Figure V-5: Modifier un employ
Extraction des TimeSheets
Linterface de la page suivante permet ladministrateur de saisir le mois pour lequel il
souhaite faire lextraction. Le bouton option permet de spcifier le dossier qui contient les
TimeSheets des employs.

Figure V-6: Extraction des TimeSheets
Rsultat de lextraction
Linterface de la page suivante suit lextraction. Elle contient le rsultat de cette dernire,
permettant ladministrateur de connaitre la liste des employs qui nont pas dpos leurs
TimeSheets, ceux avec des TimeSheets correctes et enfin les employs ayant des erreurs
de saisie dans leurs TimeSheets.

81

Figure V-7: Rapport de l'extraction des TimeSheets

Projet de Fin dEtudes 2009-2010
82

Les erreurs des TimeSheets
Cette page contient la liste des erreurs dun TimeSheets dun employ donn.
Ladministrateur peut extraire ces donnes vers un fichier Excel afin de lenvoyer la
personne concerne.

Figure V-8: Les erreurs des TimeSheets
Les demandes services ralises
Une fois lextraction faite, ladministrateur peut accder cette interface contenant la liste
des demandes services qui ont connu des ajouts. Par dfaut, la liste contient les demandes
services du mois courant, mais ladministrateur peut choisir la plage horaire pour laquelle
il souhaite afficher les demandes.
Cette interface est divise en deux onglets : un pour les demandes de services du projet
Mobile et lautre pour celles du projet Fixe.
Le lien Afficher les indicateurs globaux permet dafficher les diffrents indicateurs de
consommation quon va dcrire ci-dessous.

83


84

Figure V-9: Les volutions ralises

85

Indicateurs de consommation
En cliquant sur le lien Afficher les indicateurs globaux , la liste des indicateurs de
consommation apparait en dessous des demandes service. Cette liste contient :
le chiffrage global
la consommation totale
la consommation par phase (par dfaut les phases sont : ltude, le dveloppement
et les tests)
le pourcentage de consommation par phase
la consommation moyenne.
Ces indicateurs concernent toutes les demandes services affiches dans la liste dcrite au
paragraphe liste des volutions ralises . Si ladministrateur souhaite connaitre les
dtails de consommation dune seul demande de service, il accde linterface des tches
quon va dcrire aprs.

Figure V-10: Indicateurs de consommation
Indicateurs de consommation dtaille
Linterface de la page suivante contient des indicateurs dtaills pour chaque volution
savoir :
Le chiffrage
La consommation de chaque phase
La consommation de lvolution
Le reste faire de chaque phase et le reste faire total
Le drapage de chaque phase et le drapage total
Le coefficient du consomm par rapport au chiffrage de chaque phase.

86

Figure V-11: Indicateurs de consommation dtaille
Liste des tches
Linterface de la page suivante contient la liste des tches effectues sur une demande de
services donne. Elle contient les informations suivantes :
le libell de la tche qui contient le code QC ainsi que la phase du dveloppement
lemploy qui a excut la tche
le reste faire
ltat de la tche
la phase du dveloppement
la consommation
la date de dbut et la date de la fin de cette tche.
En dessous de la liste des tches, le responsable peut voir les indicateurs de consommation
de cette demande service, savoir la consommation globale, la consommation par phase et
le pourcentage de consommation.

87

Figure V-12: Liste des tches
Lextraction du chiffre daffaires
Linterface de la page suivante contient la liste des extractions du chiffre daffaires de
lanne courante. Cette liste contient pour chaque extraction :
Le chiffre daffaires
Le chiffre daffaires engag
Le chiffre daffaires livr
La vision du client.

88

Figure V-13: Lextraction du chiffre daffaires

89

La liste des demandes services dune extraction
Linterface de la page suivante contient la liste des demandes de services qui ont t prise
en compte dans lextraction en coure de consultation. Elle contient pour chaque volution :
le chiffrage, le chiffrage rel, le chiffrage engag, le chiffrage livr et la vision Maroc
Telecom.

90

Figure V-14: La liste des volutions dune extraction

91

Lvolution de chiffre daffaires
Cette interface dcrit lvolution du chiffre daffaires par rapport aux extractions
effectues

Figure V-15: Lvolution de chiffre daffaires
Paramtrage
Chaque liste peut tre configure par cette interface, qui permet de slectionner les
colonnes que ladministrateur souhaite afficher, ainsi que le paramtrage du filtre.

Figure V-16: Paramtrage
Conclusion
Au terme de ce chapitre, nous avons dfini la dmarche de mise en uvre ainsi que la
prsentation de quelques interfaces de lapplication.
Conclusion et perspectives

92

Conclusion et perspectives
Aujourdhui, la prise de dcision est considre de manire quasi unanime comme une
ncessit, voire une priorit. Un systme dcisionnel est devenu incontournable dans toute
entreprise qui veut sorganiser et tre munie dune stratgie efficace, visant sa promotion
et son dveloppement.
Nanmoins, une prise de dcision efficace ncessite la supervision et le suivi des diffrents
indicateurs des projets. Cest dans cette perspective que sinscrit notre projet de fin
dtudes, qui sarticule autour de la mise en place et le dploiement dun systme
dcisionnel pour le projet TMA- Maroc Telecom. Ce systme permettra lautomatisation
des procdures de calcul des indicateurs et la mise en place dune solution de reporting
pour faciliter le processus de prise de dcision.
Pendant le droulement de notre stage, nous avons eu lopportunit de travailler sur les
diffrents aspects dun projet logiciel. Le travail ralis sest avr trs enrichissant pour
notre exprience professionnelle aussi bien en ce qui concerne le domaine technique que
laspect humain.
Au cours de la priode de notre projet de fin dtudes, nous avons eu lopportunit de
mettre en application diffrentes connaissances acquises durant notre formation lEcole
Nationale Suprieure dInformatique et dAnalyse des systmes. De plus, nous avons eu
loccasion de consolider nos connaissances en matire de nouvelles technologies.
Ce projet nous a apport une grande crativit, car il nous a amen trouver des solutions
plusieurs problmes. Lun des plus importants tant la gestion de la mmoire, caus par
le grand flux dinformations traiter.
En perspective pour ce projet, et du fait quil est fortement li au produit QC, nous
pouvons le gnraliser sur toutes les socits utilisant ce produit. Nous prvoyons mme
de le rendre indpendant de ce logiciel en lui intgrant un module pour la gestion des
changes entre MOA et prestataires.

Bibliographie

93

Bibliographie
Ouvrages
[Dubois et al, 2004] Julien Dubois, Jean Philippe Retaille et Thierry Templier, Spring par la
pratique, Eyrolles, 541 p.
[Mak, 2008] Gary Mak, Spring Recipes A Problem Solution Approach, Apress, 753 p.
[Messager Rota, 2008] Vronique Messager Rota, Gestion de projet vers les mthodes agiles, Paris,
Eyrolles, 268 p.
[Minter et al, 2006] Dave Minter et Jeff Linwood,Beginning Hibernate From Novice to
Professional, Apress, 359 p.
[Roques et al, 2007] Pascal Roques et Franck Valle, UML 2 en action, Paris, Eyrolles, 394 p.
Projets de Fin dEtudes
[Abderrahmani Idrissi et al, 2008] Abderrahmani Idrissi Fadoua et Chaer Nihal,
Conception et dveloppement dun systme de paramtrage et consultation de tableaux de
bord, ENSIAS, 120 p.
[Alami et al, 2009] Salim Alami et Hassan El Moumen, Mise en place et dploiement dun
systme dcisionnel pour le projet PESOS-PILOTE, ENSAT, 84 p.
[Bagdouri et al, 2007] Mossaab Bagdouri et Mehdi Tanga, Dmatrialisation de la
procdure des appels d'offres des marchs publics, ENSIAS, 154 p.
[Boutayeb et al, 2009] Ilyass BOUTAYEB et Mohamed HRIRD, Conception et ralisation
dun systme de gestion de traabilit avec code barre, ENSIAS, 2009, 120 p.
[Khtira et al, 2008] Amal KHTIRA et Ihssan EL MESBAHI, Etude du framework ATG et
prototypage travers la conception et la ralisation dune plateformee-commerce pour la
vente des produits France Telecom, ENSIAS, 96 p.
[Idrissi et al, 2008] Fadoua ABDERRAHMANI IDRISSI et Nihal CHAER, Conception et
dveloppement dun systme de paramtrage et consultation de tableaux de bord,
ENSIAS, 120 p.
Documents
[Atos Origin, 2009] Atos Origin, Prsentation daccueil, 25 p.
[Saoudi, 2010] Abdellah Saoudi, Suivi de la production, 10 p.
Bibliographie

94

[Cycle de vie QC] Cycle de vie QC V3, 3 p.

Webographie
[DSI-CNRS, 2001] DSI-CNRS, Conduite de projet, Fvrier 2001, [En ligne],
Date de dernire mise jour : 04/04/2007
Disponible sur : http://www.dsi.cnrs.fr/methodes/gestion-projet/, 20/04/2010
[JBoss Entreprise, 2010] JBoss Entreprise, Documentation de rfrence d'Hibernate,
[Hors ligne], Disponible sur : http://www.hibernate.org/hib_docs/v3/reference/fr/html/
[Oracle Corporation, 2010] Oracle Corporation, Simplified Guide to the J2EE, [En ligne]
Disponible sur : http://java.sun.com/J2EE , 01/06/2010

Annexe 1

95

Annexe 1 - Plan assurance qualit
1. Objectif et caractristiques du PAQ
Le plan d'assurance qualit est un document qui prcise les lments permettant la matrise
duvre de s'assurer de la mise en uvre et de l'efficacit des activits prvues pour obtenir la
qualit requise.
Le prsent document a t ralis en se basant sur le plan type propos par la DSI du CNRS
sur son site
[DSI-CNRS, 2010]
.
1.1. Objectifs du plan
Le prsent plan vise exposer les dispositions prises par lquipe du projet pour rpondre aux
besoins de la matrise douvrage (organisme daccueil) selon les critres numrs sur le CdC
du projet Automatisation du reporting et de la planification des ressources pour le projet
TMA-Maroc Telecom .
Lutilisation de ce PAQ doit permettre datteindre les objectifs suivants :
Constituer une rfrence commune tous les membres de lquipe du projet.
Il permettra dassurer une bonne cohrence et une homognit dans les mthodes de
travail.
Garantir la qualit du produit final. Cette qualit qui sexprime par des objectifs de
qualit respecter dans le cadre de ce projet et qui seront noncs ultrieurement sur
ce document.
Dfinir la mthodologie de dveloppement du produit.
1.2. Domaine dapplication
Les dispositions et activits dcrites sur ce plan dassurance qualit couvrent le processus de
ralisation de notre projet (depuis ltude de lexistant jusqu la livraison du produit final)
aussi bien que les livrables (documentation interne au projet, documentation utilisateur et
produit final).
1.3. Responsabilit de ralisation et de suivi du plan
L'tablissement et les mises jour du plan sont de la responsabilit des stagiaires. La
coordination des actions entreprendre pour la bonne excution du plan relve de la
responsabilit de lencadrant ATOS Origin. Par contre le suivi de lapplication du plan est
sous la responsabilit mutuelle des stagiaires et de lencadrant.
Annexe 1

96

Le tableau suivant rsume ces responsabilits :
Intervenants Rdaction Validation Suivi du plan Edition
Mr. ABDOUNI Souhayl X x X
Mr. AFIF Anas X x x
Mr. SAOUDI Abdellah x x
Figure V-17: Rpartition des responsabilits sur les intervenants dans le projet
1.4. Critres et procdures dvolution du plan
Les mises jour du plan doivent tre justifies par une amlioration des conditions de
droulement du projet. Lencadrant ATOS Origin doit tre tenu au courant des volutions.
Aprs validation des changements apporter avec lencadrant ATOS Origin, les stagiaires
sont chargs des mises jour du plan.
2. Terminologie
2.1. Abrviations
Lensemble des abrviations dans ce PAQ est prsent dans le tableau ci-dessous :
CdC Cahier des charges
CNRS

Centre national de la recherche scientifique
DSI Direction du systme dinformation
MT Maroc Telecom
PAQ Plan assurance qualit
TMA Tierce maintenance applicative
Tableau V-1: Les abrviations utilises dans le PAQ
3. Objectifs et engagements du projet
3.1. Objectifs gnriques du projet

Etude et assimilation de lexistant.
Conception dune solution qui rpond aux besoins dAtos Origin.
Annexe 1

97

Ralisation dune application permettant de :
Calculer les chiffres daffaires engag et livr par ATOS Origin pour les
demandes de services du SI de facturation Maroc Telecom.
Calculer des statistiques de consommation par dveloppeur, quipe, phase de
dveloppement et volution.
Mise en place dun applicatif pour laffectation des ressources (dveloppeurs)
aux diffrentes tches dcoulantes des volutions.
Gestion de la scurit base sur les rles.
Mise en place des tests unitaires.
Produire une documentation.
3.2. Objectifs qualit du projet
Les objectives qualits applicables au projet sont :
Objectifs Engagement qualit Proprits
Fiabilit
Garantir la fiabilit du systme

Disponibilit : Le systme doit tre en permanence
la disposition des utilisateurs.
Excution des fonctions attendues
avec la prcision requise
Scurit : gestion des accs par rles, cryptage
(MD5) des mots de passe.
Evolutivit
Possibilit dtendre le systme Modularit
Qualit de la documentation
Rutilisabilit
Tableau V-2: Les objectives qualits applicables au projet
3.3. Activits d'assurance et de contrle de la qualit
Chaque membre de l'quipe projet est tenu de respecter les dispositions dcrites dans le PAQ
et de vrifier l'adquation du livrable (document ou code) au CdC tabli (Autocontrle).
Dautre part, le responsable du projet (notre encadrant Atos) doit veiller ce que ces
dispositions soient comprises et correctement appliques. En cas de non-conformits relles
ou potentielles, il a le droit de proposer des actions correctives ou prventives.
Ci-dessous un rcapitulatif des activits qualit :

Annexe 1

98

Activits qualit

Type dactivits Descriptif de lactivit
Assurance qualit Elaboration du PAQ
Contrle qualit
Relecture et validation des documents du projet
Veiller la bonne application des procdures
Tableau V-3: Les activits qualit
4. Conduite du projet
4.1. Organisation du projet
L'organisation de notre projet respecte celle dcrite dans les tableaux suivants :
Cot ATOS Origin :
Personne Rle
Mr. SAOUDI Abdellah Chef de projet
Tableau V-4: Les intervenants ct Atos Origin
Cot ENSIAS :
Personne Rle
Mme. BERRADA Bouchra Professeur encadrant
Mr. ABDOUNI Souhayl Stagiaire lve ingnieur
Mr. AFIF Anas Stagiaire lve ingnieur
Tableau V-5: Les intervenants ct ENSIAS
Par contre les diffrents comits mis en place pour le suivi du projet sont :
Un comit de pilotage : dont la mission est le suivi de la progression du projet par rapport au
planning tabli. Ainsi il a pour rle de proposer des actions correctives ou de mettre en place
des ajustements. Ce comit est compos des personnes suivantes :

Annexe 1

99

ENSIAS
Mr. ABDOUNI Souhayl
Mr. AFIF Anas
ATOS Origin
Mr. SAOUDI Abdellah
Tableau V-6: Le comit de pilotage
Un comit de projet : il a pour mission de suivre de prs lavancement du projet et de
concevoir, dvelopper et dployer le projet. Ce comit aura galement pour rle de prparer
les runions de pilotage et sera compos des personnes suivantes :
ENSIAS
Mr. ABDOUNI Souhayl
Mr. AFIF Anas
Tableau V-7: Le comit de projet
4.2. Organisation des runions
Tout au long du projet, des runions seront programmes pour synthtiser ltat davancement
du projet et la prise des dcisions pour les problmes rencontrs.
Priodicit : Les runions seront gnralement effectues la fin de chaque phase du
dveloppement. Il y aura aussi des runions hebdomadaires pour un suivi plus rapproch du
projet.
Objectifs :
Dfinir les objectifs raliser pour la prochaine phase.
Procder lvaluation du niveau de ralisation des objectifs prdfinis.
Identifier les problmes rencontrs et apporter des solutions.
Rajuster la planification en cas de ncessit.
4.3. Communication hors runion
Vu que le chef de projet et les stagiaires ne se trouvent pas sur le mme lieu de travail, le chef
de projet a mis en place un systme de communication o seront archives les diffrentes
communications chef de projet/stagiaires sous forme de question/rponse. Ce systme est sous
forme dun fichier Excel qui sera chang par mail.
Linitiateur de la communication avant denvoyer sa question ou remarque il doit apporter les
modifications suivantes au fichier:
Annexe 1

100

Ajouter une nouvelle ligne au fichier o il doit apporter les informations suivantes :
Son identifiant
Sa question ou remarque
Indiquer le responsable de la rponse
Degr de criticit
La date cible de rponse
Augmenter la version du fichier
Mettre les autres membres du projet en copie sur le mail envoy
5. Dmarche de dveloppement
Etant conscient de limportance du choix dune dmarche de dveloppement et le rle quelle
joue dans la russite de notre projet, nous avons opt pour ladoption une mthode agile, vu
quelle suit une approche itrative et incrmentale.
Notre choix peut tre justifi par les avantages quoffre le dveloppement itratif et
incrmentale et qui peuvent tre rsums dans le tableau suivant :
Avantage Les +
La communication est de
meilleure qualit.
Les malentendus, incomprhensions, incohrences sont mis en vidence tt dans le
projet ; il est donc encore possible de les corriger.
Lutilisateur a la possibilit de clarifier ses demandes de services au fur et
mesure.
Le client reoit des preuves tangibles de lavancement du projet.
La visibilit est
meilleure.
Le client peut ainsi visualiser les travaux plus rgulirement, sans attendre la fin du
projet, puisqu la fin de chaque itration, les fonctionnalits retenues sont
dveloppes, testes, documentes et valides.
La qualit est value en
continu.
Les tests sont effectus chaque itration, les anomalies dtectes sont corriges au
fur et mesure.
Les risques sont dtects
trs tt.
Grce aux activits de dveloppement prcoces, les risques sont dtects tt et
rsolus rapidement.
Lquipe prend
confiance.
Litration donne une occasion dapprendre, donc de capitaliser ou dadapter les
pratiques pour la suite du projet.
Le changement nest plus une menace, mais au contraire, lopportunit de mieux
faire et de mieux satisfaire le client.
Annexe 1

101

Les cots sont contrls. Les cots sont limits, en termes de risques, au primtre de litration ; sil faut
reprendre une itration, on ne perd que les efforts de cette itration et non la valeur
du produit dans sa globalit.
Tableau V-8: Les avantages du dveloppement itratif et incrmentale
5.1. Choix dune mthode de dveloppement
Afin davoir une ide assez complte des mthodes agiles existantes nous avons dress un
tableau comparatif des mthodes les plus rpandues en ce moment
Mthode Rsum en
un mot cl
Points forts Points faibles
XP
eXtreme
Programming
Simplicit - Itrative.
- Solides pratiques techniques.
- Simple mettre en uvre.
- Frquent feedback grce la
brivet des itrations.
- Amlioration constante,
adaptation aux
modifications.
- Le pair-programming nest pas
toujours bien ressenti par les
dveloppeurs.
- On se focalise sur laspect individuel
du dveloppement, au dtriment
dune vue globale et des pratiques
de management ou de
formalisation.
Scrum Valeur
ajoute pour
le client
- Itrative.
- Les priorits sont gres en
fonction de la valeur
ajoute.
- Favorise la communication et
la collaboration.
- Limite les changements avec des
itrations de trente jours et un
contenu fig durant ce sprint.
- Ne propose aucune pratique
technique.
UP
Unified Process
Gestion des
risques
- Itrative.
- Trs bien documente.
- Est devenue un standard dans
de nombreuses
organisations.
- Rles bien dfinis,
modlisation.
- Coteux personnaliser.
- Trs ax processus, au dtriment du
dveloppement.
- Lourd, largement tendu, il peut tre
difficile mettre en uvre de
faon spcifique.
- Convient pour les gros projets qui
gnrent beaucoup de
documentation.
Crystal Criticit -Itrative
- La diversit des mthodes
- Pas bien adapte des quipes
distantes.
- le passage, en cours de projet, dune
Annexe 1

102

selon le type de projet.
- La seule mthode qui admet la
variation avec la criticit
du projet.
mthode une autre au sein de la
famille est difficile.
DSD
Dynamic Software
Development
Method
Valeur
ajoute pour
le client
-Itrative
- Elabore par des fonctionnels,
la valeur ajoute est donc
au centre du processus de
priorisation.
- Fait clairement savoir au
client que les
fonctionnalits ne sont
jamais toutes incluses dans
le produit final.
- Lourde mettre en uvre.
- Trop dautonomie est donne
lquipe et aux utilisateurs, par
rapport au payeur .
Tableau V-9: Tableau comparatif des mthodes agiles
Suite au cahier de charges retenu pour le projet et vu sa subdivision en modules plus au moins
indpendants (ces mmes modules sont subdiviss en plusieurs tches dune dure courte
moyenne), nous avons opt pour la mthode XP. Les conditions pour utiliser cette mthode
[Don Wells, 2009]
ne sont pas toutes runies, mais la majorit (celles dcrites plus haut) nous ont
fait pencher vers ce choix.
Faisant partie des mthodes agiles, XP vise rduire le cycle de vie du logiciel tout en
acclrant son dveloppement par la mise en place dune version minimale puis en intgrant
les fonctionnalits par un processus itratif bas sur lavnement de nouvelles fonctionnalits.
La mthode XP fournit des pratiques permettant de dvelopper dans des conditions optimales.
Elle est base sur les principes suivants :
Le cycle de travail est court.
Les livraisons des versions sont une frquence leve.
Lquipe de dveloppement travaille sur la base de binmes.
Le dveloppement est divis en itrations de livraison.
Chaque itration de livraison se dcompose en quatre phases :
Phase dexploration : durant laquelle les utilisateurs expriment leurs besoins au
travers des scnarios.
Annexe 1

103

Phase dengagement : au cours de laquelle le client et dveloppeurs saccordent
sur le nombre des scnarios raliser durant litration. Le livrable de cette
phase est un document Plan ditration
Phase de pilotage : au cours de laquelle dbute les itrations dimplmentation
dont chacune va traiter un sous ensemble des fonctionnalits qui ont t
prcises sur le plan ditration. Ces itrations dimplmentation reprennent les
tapes dun dveloppement classique savoir:
- Analyse dtaille
- Conception
- Codage
- Tests unitaires
Une fois une itration dimplmentation acheve, elle peut induire des
modifications sur la planification des prochaines itrations dimplmentation,
dans le cas o litration dimplmentation actuelle na pas trait lensemble
des scnarios qui lui ont t affects.
Phase de livraison : Une fois la phase de pilotage acheve, la dernire tape de
livraison peut dbuter. Le produit passe par des tests de recette. Si des bugs
sont dtects aux cours de ces tests, des itrations peuvent tre programmes
pour rsoudre ces bugs. Une fois les tests de recette sont positifs, ce nouveau
dveloppement peut tre intgrer aux anciens.
Un rcapitulatif de la mthode XP est reprsent sur le schma suivant :
Annexe 1

104

5.2. Application de la mthode
Chaque itration ici prend en compte un seul module dans lensemble des modules que nous
devons accomplir. Pour ce module, nous proposons diverses solutions qui sont valides par le
chef de projet. Ensuite nous passons une conception dtaille puis au codage de la solution
retenue. Les tests sont raliss une fois que la mise en uvre est termine. Enfin nous passons
un nouveau module.
5.3. Planification du projet
La planification du projet est parmi les phases d'avant projet. Elle consiste prvoir le
droulement du projet tout au long des phases constituant le cycle de dveloppement.
Conformment au processus de dveloppement adopt, nous avons pu dterminer les
diffrentes tapes du projet ainsi que leur squence. Cela consistait en deux itrations de
livraison.
Vous trouverez sur les figures suivantes les plannings prvisionnels dtaills des deux
itrations de livraison.

Scnario
Planification
de livraison
Intgration
Phase
dexploration
Phase
dengagement
Phase de pilotage Livraison
Nouvelle itration de livraison
Itration
Conception
Tests
Codag
e
Analyse
Tests de
recette
Plan
ditration
Feedback
Bugs
Client
Itration de livraison
Annexe 1

105

Figure V-18: Planning de la premire itration de livraison
Annexe 1

106

Figure V-19: Planning de la deuxime itration de livraison
Annexe 2

107

Annexe 2 UML
UML est un langage qui dfinit un ensemble de notations graphiques et leurs smantiques. N
en 1994 de la fusion des mthodes objets dominantes (OMT cre par James Rambaugh et
Booch cre par Grady Booch et OOSE cre par Ivar Jacobson), puis normalis par lOMG en
1997. Il est devenu un standard incontournable.
UML est un langage de modlisation unifi favorisant :
Une meilleure communication entre les intervenants dans un projet, puisque UML
offre des moyens de captures des connaissances sur un sujet travers divers points de
vues (ces points de vues sont fournis par les diffrents diagrammes de UML).
Une bonne comprhension du problme, en fait le systme tudier sera trait suivant
diffrents angles et les diffrents cas dutilisation de ce systme.
UML incorpore les meilleures pratiques dingnierie dans les diffrents domaines qui
ont abouti son apparition. Ce qui lui permet dtre adapt aux diffrents types de
systmes.
UML permet aussi de suivre un projet dans ses diffrentes tapes :
Spcifier : UML sadresse la spcification du systme, il peut tre utilis pour
modliser les besoins (le quoi) et larchitecture (le comment).
Visualiser : les diffrents diagrammes donnent aux concepteurs une vue prcise sur le
systme avant sa ralisation.
Construire : les diffrents diagrammes et modles tablis durant la phase de
spcification et de conception, servent de base pour la ralisation.
Documenter : les diagrammes utiliss durant les diffrentes phases pour communiquer
les connaissances entre les membres du projet, de la spcification des besoins jusqu
la ralisation, prsentent un document dtaill sur les diverses phases et modules du
projet.
Diagrammes UML
UML dfinit neuf diagrammes :
Diagrammes dactivits : reprsentent le comportement dune opration en termes
dactions
Diagrammes des cas dutilisation : reprsentent les fonctions du systme de point de
vue de lutilisateur
Annexe 2

108

Diagrammes de classes : reprsentent la structure statique en termes de classes et de
relations
Diagrammes de collaboration qui sont une reprsentation spatiale des objets, des liens
et des interactions
Diagrammes de composants : reprsentent les composants physiques de lapplication
Diagrammes de dploiement : reprsentent le dploiement des composants sur les
dispositifs matriels
Diagrammes d'tats transitions : reprsentent le comportement dune classe en terme
dtats
Diagrammes d'objets : reprsentent les objets et leurs relations. Ils correspondent des
diagrammes de collaborations simplifis, sans reprsentation des envois de messages
Diagrammes de squences qui sont une reprsentation temporelle des objets et de leurs
interactions

Annexe 3

109

Annexe 3 - Description des cas dutilisation
VI. Description des cas dutilisation
1. Module Administration
module : Administration

Figure VI-1: Cas d'utilisation Administration du systme
i. Description du cas dutilisation Gestion des quipes

Cas dutilisation : Gestion des quipes
But : Ajouter et modifier une quipe.
Pr-condition :
- Le responsable est authentifi
Annexe 3

110

Scnarii principaux
1. Lister les quipes
a. Le responsable accde au menu Gestion des quipes, le systme affiche la liste des
quipes enregistres dans le systme.
2. Ajouter une quipe
a. Le responsable choisit dajouter une quipe
b. Il saisit ensuite le nom de lquipe et valide lopration
c. La liste des quipes se rafraichit et affiche lquipe enregistre.
Tableau VI-1: Cas dutilisation Gestion des quipes
ii. Description du cas dutilisation Gestion des employs

Cas dutilisation : Gestion des employs
But : Ajouter, modifier et affecter les employs aux quipes.
Acteur : Responsable de la production.
Pr-condition :
- Le responsable est authentifi.
Scnarii principaux
1. Lister les employs
a. Le responsable accde au menu Gestion des employs, le systme affiche la liste des
employs enregistrs.
2. Ajouter un employ
a. Le responsable choisit dajouter une quipe.
b. Il saisit ensuite le nom de lemploy, son trigramme, son matricule ainsi que lquipe
laquelle il appartient puis valide lopration.
c. La liste des employs se rafraichit et affiche lemploy enregistr.
Tableau VI-2: Cas dutilisation Gestion des employs

Annexe 3

111

3. Module Extraction du chiffre daffaires
module : Extraction du chiffre daffaires.

Figure VI-2: Cas d'utilisation Extraction du chiffre daffaires
i. Cas dutilisation Gestion des extractions

Cas dutilisation : Gestion des extractions
But : Lancer une nouvelle extraction et lister les extractions de lanne courante.
Pr-condition :
Scnarii principaux
1. Lister les extractions
a. Le responsable accde au menu Extraction, le systme affiche la liste des extractions
effectues durant lanne courante.
2. Lancer une nouvelle extraction
a. Le responsable choisit de lancer une nouvelle extraction
Annexe 3

112

b. Le systme procde la mise jours de la base locale afin didentifier les demandes de
services qui vont figurer dans lextraction.
c. La liste des extractions se rafraichit et affiche lextraction effectue avec les diffrents
chiffres daffaires : Chiffre daffaires total, Chiffre daffaires engag, Chiffre daffaires
livr et Vision MT.
Tableau VI-3: Cas dutilisation Gestion des extractions
ii. Cas dutilisation Gestion des demandes de service

Cas dutilisation : Gestion des demandes de service
But : Grer les demandes de services dune extraction.
Pr-condition :
Scnarii principaux
3. Lister les demandes de services
a. Le responsable choisit une extraction et affiche les demandes de services qui lui
sont relies.
b. Le systme affiche la liste des demandes de services relies cette extraction avec
les diffrents chiffres daffaires pour chaque demande: Chiffre daffaires total,
Chiffre daffaires engag, Chiffre daffaires livr et Vision MT.
Tableau VI-4: Cas dutilisation Gestion des demandes de service
Annexe 3

113

Nous prsenterons ci-dessous quelques diagrammes de squence :

Figure VI-3: Scnario Gestion des extractions

Figure VI-4: Scnario Gestion des demandes de service
Annexe 4

114

Annexe 4 - Documents et figures
VII. Documents et figures

Figure VII-1: Exemple dun fichier TimeSheet

Annexe 4

115

Attente EB MOA
EB MOA valid
CDC attach
CDC valid

Attente chiffrage
fournisseur
FSP valider par
DSI
EF valider par
MOA

EF valide par
MOA

Attente prcision
MOA
Attente prcision
DSI

En re-livraison
SFD Valide

SFD Valide

En production
Dispo pour MEP
En recette
Livre
Pr-recette ok
Dispo pour pr-
recette
En TIG En DEV FSP Valide
Valide interne
SI
MOA
DSI
Atos
DSI/MOA
Figure VII-2: Cycle de vie d'une volution
Annexe 5

116

Annexe 5 - Dossier de Livraison

Sujet Systme dautomatisation du repporting ATOS : Livraison initiale
Livraison V1.0
Version 1.0
Auteur AFIF Anas & ABDOUNI Souhayl
Date 22-04-2010

Organisme Destinataires
Atos Origin Abdellah Saoudi

Disclaimer: This Document is sole property of Atos Origin, Any modification or alteration to the delivered copy is
prohibited under any circumstances. Atos Origin however does not hold any responsibility what so ever incase of any
problem encountered due tampering of this document and its contents.

Annexe 5

117

1. Identification de la Livraison
Ce document prsente la livraison de la version V1.0 du systme dautomatisation du
reporting Atos Origin.
2. Livraison
2.1. Type de Livraison
Description External Rfrence:
Mise en place dun module applicatif qui permettra:
- De calculer le chiffrage rel dune volution
- Contenir linformation parpille sue les fichiers Excel
- Le calcul du pourcentage de consommation des diffrentes phases afin de dtecter
les drapages.
- Extraction de linformation partir des fichiers Excel.
Description de la Livraison : V1.0
Cette livraison comporte :
- Un fichier SQL comportant le script pour la cration du shema.
- Deux fichiers SQL comportant des requtes dinsertion relatives aux employs et
aux exigences.
- Un fichier war comportant la partie serveur de lapplication
- Un fichier tar comportant la partie client.
2.2. Dtail de la Livraison
Pice Size Sum InstallationPar
(DBA/SPP)
M/A/S*
./web/war et tar/Module1.zip SEM A
./web/ war et tar/Module1.tar SEM A
./web/ war et tar/Module1.war SEM A
./one-shot/ script_sql/Script_shema.sql

DBA A
./one-shot/ script_sql/Script_employe.sql

DBA A
./one-shot/ script_sql/req_mob.sql et fix

DBA A
M : Modifi, A : Ajout, S : Supprim
Annexe 5

118

3. Mode Opratoire
3.1. Pr requis
Aprs Fermeture des agences.
Aprs installation de Livraison
Autres:
- Excuter dans lordre les ations ci-dessous du point 3.2
3.2. Installation
1. Vous ouvrez sql plus dOracle, vous vous connectez en tant quadministrateur, et
vous excutez la commande [@(chemin du fichier Script_shema.sql)]
Exemple : SQL> @E:\script_sql\ Script_shema.sql.(attention le chemin ne doit pas
contenir des espaces)
Si tout se passe bien vous aurez : validation effectue.
2. Dans une machine serveur windows vous installez Web Sphere Comunity Edition
version 1.1.0.1.
3. Vous allez dans dmarrer->tous les programmes->IBM WebSphere-> Application
Server Community Edition->start the server.
Si tout se passe bien vous aurez server started
4. Vous allez dans dmarrer->tous les programmes->IBM WebSphere-> Application
Server Community Edition->Administration console
Vous entrez [system] come nom dutilisateur et [manager] come mot de passe.
Dans longlet [Console Navigation] vous allez dans [Applications->Deploy New].
Dans la fentre [Installe new applications] vous cochez [start application after
install], vous cliquez sur le bouton [Archive : choisissez un fichier] et vous
choisissez le fichier Module1.war.
5. Se placer dans le rpertoire de WSCE
\IBM\WebSphere\AppServerCommunityEdition\repository\default\Module1\1.0\
Module1-1.0.car\WEB-INF\classes\Application-context.xml
Dans la ligne:
value="jdbc:oracle:thin:@localhost:1521:orcl" />
Vous remplacez localhost par ladresse IP du serveur ORACLE
1521 par le port correspondant.
Dans la ligne:
Annexe 5

119

<constructor-arg type="java.lang.String" value="D:\\cra" />
Vous remplacez D:\\cra par le chemin du dossier qui contient les CRAs, si ce
dossier est dans un serveur distant, il faut avoir un accs directe sans devoir
sauthentifier, pour linstant ce dossier doit contenir des sous dossier indiquant le
mois TS-201002 ses sous dossiers doivent contenir tous les CRAs de ce mois
dans la racine.
6. Arrtez et relancez lapplication (dans le serveur).
7. Vous ouvrez sql plus dOracle, vous vous connectez en tant que module1_shema
avec le mot de passe stagiere, vrifiez si les tables se sont cres (select *from tab ;)
et vous excutez les commandes :
[@(chemin du fichier Script_employe.sql)]
[@(chemin du fichier req_mob.sql)]
[@(chemin du fichier req_fix.sql)]
8. Dans le rpertoire root du serveur appache vous dezipez le contenu du fichier
module1.zip dans un rpertoire (moduel1 par exemple).
9. Se placer dans le rpertoire de lapplication dans le serveur, le sous rpertoire
config et diter le fichier webservices-config.xml
Remplacez tous les
localhost :8080
par ladresse IP et le port du serveur dapplication (celui ou vous avez dploy
le WAR)
10. Dans le navigateur vous ouvrez http://[localhost]:[9090]/module1/
En changeant localhost et 9090 par ladresse et le port du serveur web.

ensiasVeryGood PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ensiasVeryGood PDF

Uploaded by

Copyright:

Available Formats

Mmoire de Projet de Fin dtudes

Pour lObtention du Titre

You might also like