Agie

Ecole Nationale Suprieure dInformatique et dAnalyse des Systmes
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 :
M. Anas AFIF M. Souhayl ABDOUNI
Sous la direction de :
Mme. Bouchra BERRADA(ENSIAS) M. Abdellah SAOUDI (Atos Origin)
Anne Universitaire 2009-2010
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
Projet de Fin dtudes
2009-2010
III
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
2009-2010
IV
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.
2009-2010
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.
Projet de Fin dtudes 6
2009-2010
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.
2009-2010
Liste des abrviations

Abrviation AO API BD CA CDC CDS CRA DEV DI DSI EB EF EJB FSP IHM J2EE JCA JDBC JH JMS JNDI MEP MOA MT QC RAF SI TIG TMA XML
Dsignation Atos Origin Application Programming Interface Base de donnes Chiffre daffaires Cahier de charge Centre de service Compte rendu dactivits Dveloppement Demande dintervention Direction des systmes dinformation Expression de besoin Expression fonctionnelle Enterprise JavaBeans Functionnel specifications Interface homme-machine Java 2 Entreprise Edition Java connector architecture Java DataBase Connectivity Jours homme Java Message Service Java Naming and Directory Interface Mise en production Matrise douvrage Maroc Telecom Quality Center Reste faire Systme dinformation Tests dintgration Tierce Maintenance Applicative Extensible Markup Language
2009-2010
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
Projet de Fin dtudes 9 2009-2010
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
2009-2010
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
2009-2010
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
2009-2010
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
2009-2010
Introduction gnrale
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.
2009-2010
Introduction gnrale 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 lorgani sme 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.
2009-2010
Chapitre 1
Contexte gnral du projet
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.
2009-2010
Chapitre 1
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 :
2009-2010
Chapitre 1
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]
2009-2010
Chapitre 1 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 multisites. 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 :
2009-2010
Chapitre 1
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.
Chapitre 1
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.
DG
Denis Clnet
Projets MT
Projets hors MT
Projet TMSA Projets hors TMA Projets TMA Projet OCP
Chef de projet : Bouchra Bouzoubea
Chef de projet : Philipe Ducrocq

Equipe Activation
Projet Mutualisation
Projet TGR
Projet Migration Oracle 10g
Equipe Ticketing
Equipe Design
Equipe tests dintgration
Equipe Build Figure I-5: Organigramme du CDS-Rabat [Atos Origin, 2009] Projet de Fin dtudes 21 2009-2010
Chapitre 1
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.
SI COMMERCIAL MT
SI COMMERCIAL FIXE
SI COMMERCIAL 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.
Demandes de service
Envoy par MT
Planification et engagement Ralisation Suivi Livraison Qualification
Mise en production facturation

Envoy MT
Test dintgration Validation
Figure I-7: Echange Atos Origin-Maroc Telecom 2009-2010 22
Chapitre 1 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 :
2009-2010
Chapitre 1 Avantage
La communication est de Les malentendus, les incomprhensions et les incohrences sont rapidement mis en vidence; il est donc encore possible de les meilleure qualit.
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 Les tests sont effectus chaque itration, les anomalies dtectes sont corriges au fur et mesure. continu. Les risques sont dtects Grce aux activits de dveloppement prcoces, les risques sont dtects tt et rsolus rapidement. trs tt. 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.
2009-2010
Chapitre 1
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. Itration de livraison
Phase dexploration
Client
Phase dengagement
Phase de pilotage
Livraison
Tests
Tests de recette Bugs
Feedback
Itration Codage Analyse
Scnario
Planification de livraison
Plan ditration
Conception
Intgration
Nouvelle itration de livraison

Figure I-8: Mthode de dveloppement XP
2009-2010
Chapitre 1 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.
2009-2010
Chapitre 1
Figure I-9: Planning global du projet
2009-2010
Chapitre 1
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.
2009-2010
Chapitre 2
Etude prliminaire
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.
2009-2010
Chapitre 2
Etude prliminaire
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.
Cration dune demande de services (volution, DI, corrections) Suivi des demandes de
Consultation des demandes
services.
Chiffrage et suivi des demandes
HP QUALITY CENTER
Figure II-1: Contexte dutilisation de QC
2009-2010
Chapitre 2
Etude prliminaire
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
Description Identifie une volution Regroupe un ensemble dvolutions planifies pour un mois donn. Spcifie ltat davancement dune volution, reprend les tats de la figure II-2. 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 TIG (tests dintgration). Exprime le rsultat attendu de lvolution. Le nombre de jours estim pour finir lvolution. Optionnel. Le responsable du suivi de lvolution ct Maroc Telecom
2009-2010 31
Caractristiques Identifiant Palier de ralisation Statut Chiffrage
Description reste faire Commentaire Responsable

Chapitre 2
Maroc Telecom Responsable design Responsable TIG Dveloppeur Date de livraison
Etude prliminaire
Le responsable de la conception de la solution ct Atos Origin. Le responsable des tests dintgration ct Atos Origin. Le dveloppeur responsable de lvolution ct Atos Origin. 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
2009-2010
Chapitre 2
Etude prliminaire
TIG et passe directement au dveloppement pour tre ensuite livre. Ce genre de demandes de services est appel DI : demande dintervention.
2009-2010
Chapitre 2 Caractristiques dune DI Description Identifie une DI
Etude prliminaire
Caractristique Identifiant Statut Chiffrage
Spcifie ltat davancement dune DI, reprend les tats de la figure II-3.
est exprim en JH et reprsente le nombre de jours de dveloppement estim pour quune ressource achve la DI.
Le nombre de jours estim pour finir la DI. Exprime le rsultat attendu de lvolution.
Reste faire Description Ressource Date de livraison
La ressource responsable du dveloppement de la DI.

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.
DI initi
DI en analyse
DI valider
DI valide
DSI
Atos
DI en DEV
DI clture
DI dispo pour MEP
DI livre
Figure II-3: Cycle de vie dune demande dintervention
2009-2010
Chapitre 2 c. Anomalie : Soumission des anomalies Atos Origin
Etude prliminaire
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 Description Identifie une anomalie Le nombre de jours hommes estim ncessaire pour corriger lanomalie. Date limite pour livrer la correction Maroc Telecom. La date o ATOS ORIGIN a accept lanomalie pour tre corrige. Parfois une anomalie ne respecte pas la date de livraison souhaite. Dans ce cas elle a une de la date de fin relle. Le nombre de jours estim pour finir la tche en cours. Optionnel. Mineure, moyenne, critique, majeure
Exprime ltat davancement dune anomalie, reprend les tats de la figure II-4.
Tableau II-3: Caractristiques dune anomalie
Caractristiques Identifiant Chiffrage
Date de livraison Date dacceptation
Date de fin relle
Reste faire Commentaire Gravit Statut
Cycle de vie dune anomalie

2009-2010 35
Chapitre 2
Etude prliminaire
Une anomalie a un cycle de vie trs simple comme le montre la figure II-4.
Anomalie initie
Anomalie affecte
Anomalie En DEV
Anomalie livre
DSI
Atos
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 TIG 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 TIG. Une ligne dun TimeSheet reprsente une tche et doit comporter les informations suivantes (tableau II-4) :
2009-2010
Chapitre 2 Information Projet Description
Etude prliminaire
Dans notre cas, nous nous intressons aux tches lies au projet TMAMaroc Telecom de la Etude, dveloppement, TIG, etc.
Type tche Statut RAF
en cours , termine . Le nombre de jours estim pour finir la tche en cours Lidentifiant QC de la demande de services laquelle cette tche est lie.
Tableau II-4:La composition dune ligne dun fichier TimeSheet
REQ_QC
En plus des informations mentionnes plus haut, la ressource doit apporter au fichier les informations suivantes (tableau II-5) : Information Nom et prnom Trigramme Description Nom et prnom du propritaire du fichier Un ensemble de trois lettres identifiant un employ de manire unique. Mois et anne cibles
Mois et anne
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 JH 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 .
2009-2010
Chapitre 2
Etude prliminaire
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 TIG. 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 JH qui a t chiffr aux diffrentes demandes de services
2009-2010
Chapitre 2
Etude prliminaire
Le nombre de JH 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 JH 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.
2009-2010
Chapitre 2
Etude prliminaire
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 Module calcul des chiffres daffaires Objectifs 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.
2009-2010
Chapitre 3
Analyse et conception
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.
2009-2010
Chapitre 3
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.
QC
Mobile Fixe
TimeSheets
Base locale
Figure III-1: les sources de donnes
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 :
2009-2010
Chapitre 3
Champ
Phase
Type de demande de services Evolution FC
Modle respecter
Commentaire
Pour diffrencier les volutions des autres demandes de service. Toute activit lie une volution doit porter sur le champ Phase la valeur FC. XXXX : Lid identifiant lvolution sur la table REQ, Phase: actuellement Etude, DEV ou TIG. Mais, le systme doit tre capable de grer de nouvelles phases, [intitul de la tche] : Optionnel. Pour diffrencier les DI des autres demandes de service. Toute activit lie une DI doit porter sur le champ Phase la valeur DI. XXXX : Lid identifiant lvolution sur la table REQ, Phase: actuellement Etude, DEV ou TIG. Mais, le systme doit tre capable de grer de nouvelles phases, [intitul de la tche] : Optionnel. Pour diffrencier les anomalies des autres demandes de service. Toute activit lie une anomalie doit porter sur le champ Phase la valeur ANO.
Libell Evolution QCXXXX:Phase[intitul de la tche] de la tche
Phase
DI
DI
Libell DI de la tche
DIXXXX:Phase[intitul de la tche]
Phase
Anomalie ANO
Libell Anomalie - Si anomalie de recette (lie une volution) : de la QCXXXX/ANOYYYY:Phase[intitul tche de la tche].
XXXX : Lid identifiant lvolution sur la table REQ, YYYY : Lid identifiant l'anomalie sur la table REQ -Sinon : Phase: actuellement Etude, DEV ANOYYYY[intitul de la tche] ou TIG. Mais, le systme doit tre capable de grer de nouvelles phases, [intitul de la tche] : Optionnel. Tableau III-1: Rgles de remplissage des fichiers TimeSheets
2009-2010
Chapitre 3 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 JH) 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 Mobile RQ_USER_21 RQ_USER_03 VarChar(40) 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 :
2009-2010
Chapitre 3 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 (TIG 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
Chapitre 3
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.
Responsable production Mise jour BD locale
Calcul chiffre daffaires pour la priode courante Crer, modifier statuts
Evolution des chiffres daffaires 2.1 Systme

Figure III-2: Diagramme de contexte du module Extraction 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.
Chapitre 3
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 lintervallecible : 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:
2009-2010
Chapitre 3
Figure III-3: Diagramme dactivits de lextraction de la liste des demandes de services cibles Projet de Fin dtudes 48 2009-2010
Chapitre 3 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 DSG en cours EB MOA valide Attente EB MOA A envoyer au fournisseur A tudier par DSI En dev MT CDC valid Attente Chiffrage Fournisseur FSP valider par DSI A valider par MT EF valider par MOA A valider par DSC EF valide par MOA FSP Valide Valide En Dev En TIG Dispo pour pr-recette Livre En recette Livre/annule Dispo pour MEP En production Annule
Engag 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 en partie
Livr 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 en partie
PSF % 0 0 0 0 0 0 0 0 0 0 0 0 0 24 24 24 24 24 85 85 85 85 100 en partie 2009-2010
Chapitre 3
Attente prcision DSC Attente prcision DSI Attente prcision MOA Attente prcisions MT Gele Stand by Valide Interne Valide interne SI DI valider DI clture DI dispo pour MEP DI en analyse DI en dv DI initie DI livre DI valide
en partie en partie en partie en partie en partie en partie 1 1 1 1 1 1 1 0 1 1 0 0 0 0 en partie en partie en partie en partie 1 1 1 1 1 0 1 1 en partie en partie en partie en partie en partie en partie en partie en partie 100 100 100 100 100 0 100 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.
2009-2010
Chapitre 3
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) :
2009-2010
Chapitre 3
Figure III-4: Diagramme de cas d'utilisation global Projet de Fin dtudes 52 2009-2010
Chapitre 3
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.
2009-2010
Chapitre 3 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
2009-2010
Chapitre 3 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 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 u n 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.
2009-2010
Chapitre 3
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 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

Chapitre 3
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.
2009-2010
Chapitre 3 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 Projet de Fin dtudes 58 2009-2010
Chapitre 3
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 Employ Equipe DemandeServiceMobile DemandeServiceFixe Projet Tche DailyTask Phase Historique TimeSheets Erreurs Description Reprsente un employ dAtos Origin Elle permet la gestion des quipes Reprsente les demandes de services du projet Mobile Reprsente les demandes de services du projet Fixe Reprsente les projets auxquels sont lies les demandes de services Reprsente les tches effectues par un employ sur une demande de service Reprsente les sous-tches dune tche Reprsente les phases de dveloppement Permet de grer lhistorique des demandes de services Reprsente le TimeSheet dun employ 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.
Chapitre 3
Figure III-8: diagramme de classes : Module Indicateurs de consommation Projet de Fin dtudes 60
2009-2010
Chapitre 3
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 Extraction DemandeService Statut Erreurs Reprsente une extraction Reprsente les demandes de services incluses dans une extraction Reprsente les diffrents statuts dune demande de services Reprsente les erreurs dune extraction
Tableau III-9: Liste des classes du module Chiffres daffaires
Description
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
Chapitre 3
de ralisation. Dans le chapitre suivant, nous abordons larchitecture du systme et nous prsentons les diffrents outils utiliss.
2009-2010
Chapitre 4
Etude technique du projet
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
2009-2010
Chapitre 4
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]
Chapitre 4
Couche Prsentation
Couche mtier
Couche accs aux donnes
Source de donnes
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 possibilit de s'interfacer avec le systme d'information existant grce de nombreuses API : JDBC, JNDI, JMS, JCA, etc. possibilit de choisir les outils de dveloppement et le ou les serveurs d'applications utiliss qu'ils soient commerciaux ou libres
2009-2010 65
La
La
Chapitre 4
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 correspondant e 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. [Idrissi et al, 2008]
2009-2010
Chapitre 4
Application
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
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
2009-2010
Chapitre 4
favorise la maintenabilit de lapplication et la rutilisation en adoptant les solutions trouves aux problmes ayant un fonctionnement similaire. [Idrissi et al, 2008] 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
Chapitre 4
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.
Chapitre 4
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 ultrainteractives et expressives se dployant de manire identique sur la plupart des navigateurs, postes de travail et systmes d'exploitation.
2009-2010
Chapitre 4
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.
2009-2010
Chapitre 5
Ralisation et mise en uvre
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.
2009-2010
Chapitre 5
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.
2009-2010
Chapitre 5
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
2009-2010
Chapitre 5
Figure V-2: Pages daccueil Projet de Fin dtudes 75 2009-2010
Chapitre 5
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
2009-2010
Chapitre 5
Figure V-3: Gestion des employs
2009-2010
Chapitre 5
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.
2009-2010
Chapitre 5
Figure V-4: Ajouter un employ
2009-2010
Chapitre 5
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.
Chapitre 5
Figure V-7: Rapport de l'extraction des TimeSheets
2009-2010
Chapitre 5 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.
Projet de Fin dEtudes 82
2009-2010
Chapitre 5
2009-2010
Chapitre 5
Figure V-9: Les volutions ralises Projet de Fin dEtudes 84 2009-2010
Chapitre 5 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.
2009-2010
Chapitre 5
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.
2009-2010
Chapitre 5
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.
2009-2010
Chapitre 5
Figure V-13: Lextraction du chiffre daffaires Projet de Fin dEtudes 88 2009-2010
Chapitre 5 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.
2009-2010
Chapitre 5
Figure V-14: La liste des volutions dune extraction
2009-2010
Chapitre 5
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.
Projet de Fin dEtudes 91 2009-2010
Conclusion et perspectives
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 enrichiss ant 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.
2009-2010
Bibliographie
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.
2009-2010
Bibliographie [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
2009-2010
Annexe 1
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 Le tableau suivant rsume ces responsabilits : Intervenants Mr. ABDOUNI Souhayl Mr. AFIF Anas Mr. SAOUDI Abdellah Rdaction Validation Suivi du plan Edition X X x x x x 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 MT PAQ TMA
Direction du systme dinformation Maroc Telecom Plan assurance qualit 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 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 Fiabilit Engagement qualit
Garantir la fiabilit du systme
Proprits
Disponibilit : Le systme doit tre en permanence la disposition des utilisateurs. Scurit : gestion des accs par rles, cryptage (MD5) des mots de passe. Modularit Qualit de la documentation Rutilisabilit
Evolutivit
Excution des fonctions attendues avec la prcision requise Possibilit dtendre le systme
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 :
2009-2010
Annexe 1
Activits qualit
Type dactivits Assurance qualit Contrle qualit
Descriptif de lactivit Elaboration du PAQ

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 Mr. AFIF Anas Stagiaire lve ingnieur 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 :
2009-2010
Annexe 1 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 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
La communication est de meilleure qualit.
Les +
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 meilleure.
est
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. Les tests sont effectus chaque itration, les anomalies dtectes sont corriges au fur et mesure. Grce aux activits de dveloppement prcoces, les risques sont dtects tt et rsolus rapidement. 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.
La qualit est value en continu. Les risques sont dtects trs tt. Lquipe confiance. prend
2009-2010
Annexe 1
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 Simplicit Points forts Points faibles
XP eXtreme Programming
- Itrative. - Solides pratiques techniques. - Simple mettre en uvre. - Frquent feedback grce la brivet des itrations. - Amlioration adaptation modifications. constante, aux
- 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 technique. aucune pratique
UP Unified Process
Gestion des risques
- Itrative. - Trs bien documente. - Est devenue un standard dans de nombreuses organisations. - Rles bien modlisation. dfinis,
- 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. - Pas bien adapte des quipes distantes. - le passage, en cours de projet, dune
Crystal
Criticit
-Itrative - La diversit des mthodes
2009-2010
Annexe 1
selon le type de projet. - La seule mthode qui admet la variation avec la criticit du projet. 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 . mthode une autre au sein de la famille est difficile.
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.
2009-2010
Annexe 1 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 :
2009-2010
Annexe 1
Itration de livraison
Phase dexploration
Client
Phase dengagement
Phase de pilotage
Livraison
Tests
Bugs Feedback
Itration Codag e Analyse
Tests de recette
Scnario
Planification de livraison
Plan ditration
Conception
Intgration
Nouvelle itration de livraison 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.
2009-2010
Annexe 1
Figure V-18: Planning de la premire itration de livraison
2009-2010
Annexe 1
Figure V-19: Planning de la deuxime itration de livraison
2009-2010
Annexe 2
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
2009-2010
Annexe 2 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
2009-2010
Annexe 3
Annexe 3 - Description des cas dutilisation

VI. Description des cas dutilisation
1. Module Administration Le diagramme de cas dutilisation ci-dessous illustre lorganisation des fonctionnalits du 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. Acteur : Responsable de la production Pr-condition :
- Le responsable est authentifi
2009-2010
Annexe 3
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
2009-2010
Annexe 3 3. Module Extraction du chiffre daffaires Le diagramme de cas dutilisation ci-dessous illustre lorganisation des fonctionnalits du 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. Acteur : Responsable de la production 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
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. Acteur : Responsable de la production 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
2009-2010
Annexe 3
Nous prsenterons ci-dessous quelques diagrammes de squence :
Figure VI-3: Scnario Gestion des extractions
Figure VI-4: Scnario Gestion des demandes de service Projet de Fin dtudes 113 2009-2010
Annexe 4
Annexe 4 - Documents et figures

VII. Documents et figures
Figure VII-1: Exemple dun fichier TimeSheet
2009-2010
Annexe 4
Attente EB MOA Attente prcision MOA
MOA
EB MOA valid
DSI CDC attach Atos CDC valid Attente prcision DSI DSI/MOA Attente chiffrage fournisseur
En production
Dispo pour MEP
En recette
En re-livraison
Livre
FSP valider par DSI
Pr-recette ok
EF valider par MOA EF valide par MOA Valide interne SI
Dispo pour prrecette
FSP Valide
En DEV
En TIG
SFD Valide
SFD Valide
Figure VII-2: Cycle de vie d'une volution Projet de Fin dtudes 115 2009-2010
Annexe 5
Annexe 5 - Dossier de Livraison
Sujet Livraison Version Auteur Date
Systme dautomatisation du repporting ATOS : Livraison initiale V1.0 1.0 AFIF Anas & ABDOUNI Souhayl 22-04-2010
Organisme
Atos Origin
Destinataires
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.
2009-2010
Annexe 5
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) SEM SEM SEM DBA DBA DBA M/A/S*
./web/war et tar/Module1.zip ./web/ war et tar/Module1.tar ./web/ war et tar/Module1.war ./one-shot/ ./one-shot/ ./one-shot/
A A A A A A
script_sql/Script_shema.sql script_sql/Script_employe.sql script_sql/req_mob.sql et fix
M : Modifi, A : Ajout, S : Supprim 2009-2010 117
Annexe 5
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 <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.
2009-2010

Agie

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Agie

Încărcat de

Drepturi de autor:

Formate disponibile

Ecole Nationale Suprieure dInformatique et dAnalyse des Systmes

Mmoire de Projet de Fin dtudes

Automatisation du reporting et la planification des ressources pour le projet TMA-Maroc Telecom.

Anne Universitaire 2009-2010

Projet de Fin dtudes

Projet de Fin dtudes

Projet de Fin dtudes

Projet de Fin dtudes 6

Projet de Fin dtudes 7

Liste des abrviations

Table des figures

Projet de Fin dtudes 10

Liste des tableaux

Projet de Fin dtudes 11

Table des matires

Projet de Fin dtudes 12

Projet de Fin dtudes 13

Projet de Fin dtudes 14

Projet de Fin dtudes 15

Contexte gnral du projet

Chapitre I Contexte gnral du projet

Projet de Fin dtudes 16

Contexte gnral du projet

Contexte gnral du projet I.1 Prsentation dAtos Origin

Figure I-1: Historique d'Atos Origin [Atos Origin, 2009]

Projet de Fin dtudes 17

Contexte gnral du projet

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

Projet de Fin dtudes 18

Contexte gnral du projet

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

Projet de Fin dtudes 19

Contexte gnral du projet

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

Contexte gnral du projet

Projet TMSA Projets hors TMA Projets TMA Projet OCP

Chef de projet : Bouchra Bouzoubea

Chef de projet : Philipe Ducrocq

Projet Migration Oracle 10g

Equipe tests dintgration

Contexte gnral du projet

I.2 Contexte du projet

Figure I-6: Dcomposition du systme commercial Maroc Telecom

Planification et engagement Ralisation Suivi Livraison Qualification

Mise en production facturation

Test dintgration Validation

Figure I-7: Echange Atos Origin-Maroc Telecom 2009-2010 22

Contexte gnral du projet

Projet de Fin dtudes 23

Contexte gnral du projet

La visibilit est meilleure.

Les cots sont contrls.

Projet de Fin dtudes 24

Contexte gnral du projet

Tests de recette Bugs

Nouvelle itration de livraison

Projet de Fin dtudes 25

Chapitre 1 b. Application de la mthode

Contexte gnral du projet

Projet de Fin dtudes 26

Contexte gnral du projet

Figure I-9: Planning global du projet

Projet de Fin dtudes 27