Rapport Stage V2

of 131/131
Présentation de la société SOMMAIRE SOMMAIRE 1 INTRODUCTION 5 1 PRÉSENTATION 6 1.1 L’ENTREPRISE XEROX 7 1.1.1 Présentation de Xerox Corporation 7 1.1.2 Organisation interne 9 1.1.3 Segmentation du marché 9 1.2 XEROX RESEARCH CENTER EUROPE 11 1.2.1 La SPD et l’équipe CodeX 12 1.2.1.1Données clés 13 1.2.1.2Missions 13 1.2.2 La méthodologie SIGMA-PLUS et le système Scrum 14 2 LA MISSION 16 2.1 ORGANISATION 17 2.2 LA FEUILLE DE ROUTE DE LA MISSION 18 2.2.1 Les objectifs généraux 18 2.2.2 Les étapes 18 3 GESTION DU PROJET 20 3.1 L’ENGAGEMENT DE QUALITÉ 21 3.1.1 La Capacité fonctionnelle des applications 21 3.1.2 La Fiabilité (intégrité) 21 3.1.3 La facilité d’utilisation 21 3.1.4 Le rendement et la disponibilité 21 3.1.5 La maintenabilité et la portabilité 22 3.2 LE CONTRÔLE DES RISQUES 23 3.2.1 Le processus de contrôle des risques 23 3.2.2 Le mode de prévision des risques 24 3.3 CONTRAINTES DE DÉVELOPPEMENT ET DE LIVRABLE 26 3.3.1 Les macro tâches 26 3.3.2 Les jalons et livrables 28 Concernant les jalons et livrables associés, ont été retenus 4 niveaux de jalons: 28 1
  • date post

    26-Jun-2015
  • Category

    Documents

  • view

    189
  • download

    0

Embed Size (px)

Transcript of Rapport Stage V2

Prsentation de la socit

SOMMAIRESOMMAIRE 1 PRSENTATION 1 6

FIGURE 1 : LES CENTRES DE RECHERCHE DE XEROX TRAVERS LE MONDE 9 4 1.1 LENTREPRISE XEROX....................................................................................................81.1.1 Prsentation de Xerox Corporation.....................................................................................8 1.1.2 Organisation interne.........................................................................................................10 1.1.3 Segmentation du march.................................................................................................10

1.2 XEROX RESEARCH CENTER EUROPE.....................................................................................121.1.4 La SPD et lquipe CodeX...............................................................................................13 1.2.1.1 Donnes cls...............................................................................................................14 1.2.1.2 Missions.......................................................................................................................14 1.1.5 La mthodologie SIGMA-PLUS et le systme Scrum.....................................................15

2 17

LA

MISSION

2.1 ORGANISATION...............................................................................................................18 2.2 LAFEUILLE DE ROUTE DE LA MISSION..................................................................................19

1.1.6 Les objectifs gnraux ....................................................................................................19 1.1.7 Les tapes.........................................................................................................................19

3 21

GESTION

DU

PROJET

3.1 LENGAGEMENT DE QUALIT...............................................................................................221.1.8 La Capacit fonctionnelle des applications .......................................................................22 1.1.9 La Fiabilit (intgrit).........................................................................................................22 1.1.10 La facilit dutilisation.......................................................................................................22 1.1.11 Le rendement et la disponibilit.......................................................................................22 1.1.12 La maintenabilit et la portabilit.....................................................................................23

3.2 LE CONTRLE DES RISQUES...............................................................................................241.1.13 Le processus de contrle des risques.............................................................................24 1.1.14 Le mode de prvision des risques...................................................................................26

3.3 CONTRAINTES DE DVELOPPEMENT ET DE LIVRABLE...................................................................281.1.15 Les macro tches...........................................................................................................28 1.1.16 Les jalons et livrables......................................................................................................31 Concernant les jalons et livrables associs, ont t retenus 4 niveaux de jalons:.....................31

3.4 PROCESSUS SUPPORT DE LA MISSION...................................................................................321.1.17 La gestion des modifications...........................................................................................32 1.1.18 La gestion de configuration.............................................................................................32 Il sagit, ici, de reprendre la dmarche de cette discipline de la gestion technique et administrative destine :........................................................................................................................32 1.1.19 La gestion des risques.....................................................................................................32 1.1.20 La gestion des documents de suivi..................................................................................33 1

Prsentation de la socit

1.1.21 Les documents de procdure..........................................................................................33 Les documents techniques.....................................................................................................33

3.5 LIMITES DU PROJET..........................................................................................................351.1.22 1.1.23 1.1.24 1.1.25 Les interfaces..................................................................................................................35 Les contraintes techniques de lapplication.....................................................................36 Les contraintes temporelles et de charge........................................................................36 Les contraintes organisationnelles..................................................................................37

4 38

ANALYSE 4.1 LES OBJECTIFS DE LA SOLUTION CODEX.................................................................................40 4.2 FONCTIONNALITS ET LIMITES DE LA PLATEFORME CODEX......................................................43

5 46

SPCIFICATION 5.1 ETUDE DES BESOINS........................................................................................................47 5.2 DIAGRAMME DE CAS DUTILISATIONS (HAUT NIVEAU)..................................................................49

6 51

CONCEPTION 6.1 PROBLEMATIQUE....................................................................................................52 6.2 LES SOLUTIONS ETUDIEES..................................................................................................55 6.3 LA SOLUTION RETENUE......................................................................................................57 6.4 DIAGRAMMES.................................................................................................................641.1.26 Diagramme de Classes .............................................................................................64 1.1.27 Diagrammes de squences.............................................................................................70 1.1.28 Diagramme de dploiement............................................................................................73

6.5 LES MAQUETTES..............................................................................................................74 ......................................................................................................................................84 6.6 ETAT DAVANCEMENT (GANTT)...........................................................................................86 6.7 COURBE DAVANCEMENT....................................................................................................88 7 89 7.1 TRAVAUX RALISS..........................................................................................................90Jalon 1.......................................................................................................................................90 Jalon 2.......................................................................................................................................90 Jalon 3.......................................................................................................................................91 Jalon 4.......................................................................................................................................91

TESTS

ET

CODAGES

8 92

EVALUATION

ASSESSMENT

Outils.........................................................................................................................................93 Analyse Causale.......................................................................................................................93 Enseignement...........................................................................................................................93 Dcisions...................................................................................................................................94 Actions.......................................................................................................................................94 2

Prsentation de la socit

9 96

CONCLUSION ANNEXES 98 SOMMAIRE DES ANNEXES....................................................................................99 A.1 DEFINITIONS........................................................................................................100 A.2 LE PLANNING..............................................................................................................101 A.3.1 FICHE DE MODIFICATION..............................................................................................102 A.3.2 FICHE DE TACHES.....................................................................................................103 A.3.3 COMPTE A.3.4 FICHE A.3.5 FICHE A.3.6 FICHE A.4 SUIVIRENDU DE REUNION.....................................................................................104 DE VALIDATION DU PLAN DE QUALIT SUIVEUSE DE LVOLUTION DU

...............................................................105 ......................................................106 .............................................................107

PROJET

DANOMALIE DES TESTS DINTGRATION

DAVANCEMENT...................................................................................................108

R.1 BIBLIOGRAPHIE............................................................................................................109 R.2 WEBOGRAPHIE............................................................................................................110

3

Prsentation de la socit

TABLE

DES FIGURES

FIGURE 1 : LES CENTRES DE RECHERCHE DE XEROX TRAVERS LE MONDE

9

Figure 2 : Rpartition gographique des revenus de Xerox (donnes 2005).9 Figure 3 : Organigramme de Xerox et positionnement du XRCE et de la SDP..12 Figure 4 : Composantes de la SDP......................................................................................................13 Figure 5 : Cheminement de lvaluation des risques...23 Figure 6 : Diagramme de PERT (Cheminement des macros tches).27 Figure 7 : Contrainte de vrification des droits...31 Figure 8 : les 2 dimensions indispensables une stratgie russie de rutilisation.35 Figure 9 : Schmade la plateforme CodeX 38 Figure 10 : Principe de Fonctionnement du mode hors ligne de CodeX.46 Figure 11 : Schma de communication entre Client Java et Server CodeX50 Figure 12 : Les diffrentes tapes du fonctionnement de CodeX en mode hors ligne53 Figure 13 : Configuration du serveur Soap.63 Figure 14 : Connexion Locale.63 Figure 15 : Connexion au serveur CodeX...64 Figure 16: Ouvrir une session.64 Figure 17: Mon Compte.65 Figure 18: Mon profil de comptences..66 Figure 19: Page daccueil de loutil de suivi.67 Figure 20: cran de fonctionnalits dun outil de suivi Bugs ..68 Figure 22: un exemple dcran de soumission dartefact(ici de type task ...69 Figure 23: partie dajout, de modification et de suppression de commentaires et de Fichiers attachs70 Figure 24: partie dajout ou de suppression de dpendances ..71 Figure 25: cran de rcupration doutils de suivi du projet choisi.73

4

Prsentation de la socit

IntroductionPour mettre leurs produits et services sur le march, de nombreux secteurs industriels dpendent aujourd'hui de leurs activits internes et externes de dveloppement logiciel. Pourtant, de nombreuses entreprises reconnaissent que leurs activits de dveloppement logiciel sont fragmentes et disperses sur les plans gographique et organisationnel. Les quipes de projet sont souvent isoles les unes des autres et ignorent les synergies potentielles l'intrieur mme de leur entreprise. La disparit des outils, des mthodes et des infrastructures utilises pnalisent aussi la productivit et engendre de nombreux cots cachs. Avec la forte pression pour fournir des produits innovants un rythme toujours plus rapide, il devient critique de rsoudre ce type de problmes. La plateforme CodeX du Centre de recherche de Xerox de Meylan doit justement permettre de vaincre les obstacles qui empchent une utilisation efficace des logiciels et des ressources dans l'entreprise. Cette plate-forme centralise propose un grand nombre de services utiles au dveloppement d'un projet informatique: outils de suivi, systmes de contrle de version du code source, listes de distribution, gestionnaires de fichiers et de documents, etc. Mais si, aujourd'hui, l'ensemble de ces services est accessible via une interface web, il n'est pas possible dy accder sans passer par le serveur central du XRCE. Cest dans le cadre de la prparation du projet de deuxime anne de spcialisation que lquipe de trois lves ingnieurs stagiaires de lInstitut EERIE compose a t retenue par le XRCE pour ltude de faisabilit de cette connexion en mode Hors ligne dans le cadre du projet Code Exchange supervis par la Smart Document Platform de Xerox. Pour la prparation du prsent rapport, le terme projet fait rfrence au cadre du projet CodeX dans son ensemble tandis que le terme mission porte sur le travail raliser par lquipe EERIE, tant entendu que chacun des trois lves ingnieurs en assume une partie ou tche. Cette approche globale justifie le choix de la prsentation du rapport en huit parties correspondant sensiblement au phasage de la mission dtude qui sont: 1 -Prsentation de lorganisation support du projet 2 -Gestion du projet 3 -Analyse de lexistant et spcification des besoins techniques 4 -Conception des solutions retenues, tests et codages 5 -Evaluation ou assessment 5

Prsentation de la socit

1

PRSENTATION

6

Prsentation de la socit

7

Prsentation de la socit

1.1 LENTREPRISE XEROX1.1.1 Prsentation de Xerox CorporationXerox, un des leaders mondiaux de la bureautique, offre, en plus de sa gamme de produits et services classiques, des solutions destines amliorer la gestion des processus documentaires utiliss quotidiennement par les entreprises et les organisations. Xerox Corporation Fonde en 1948, Xerox Corporation, initialement marque dpose du groupe Haloid Company spcialis dans la xrographie, Xerox est devenu, aprs de nombreuses fusions et acquisitions, un groupe international prsent dans le monde entier avec un chiffre daffaires de 20 milliards $ et 61000 employs rpartis sur les cinq continents. Lapproche du march de Xerox part du principe que les documents sont essentiels pour de nombreux processus d'entreprise, depuis la facturation jusqu' la communication client, en incluant la formation et la gestion des fichiers et archives, que ce soit sous forme papier ou lectronique. Mais tout document a un cot et chaque entreprise cherche augmenter son chiffre d'affaires tout en rduisant les cots et en amliorant la productivit. Or, d'aprs des expertises de spcialistes du secteur, les cots documentaires sont peu matriss et encore moins mesurs. Et globalement, ils estiment que ces cots peuvent reprsenter, en moyenne, entre 5 et 15% du chiffre daffaires d'une entreprise. Ils estiment galement quentre 17 et 25% de ces cots documentaires sont directement lis la production documentaire. On comprend quil soit difficile pour un grand nombre dorganisations de runir des millions de documents, de les numriser, de les regrouper, de les indexer pour permettre la recherche par mots-cls, puis de les transfrer en mme temps vers diffrents emplacements et bases de donnes pour qu'ils soient rorients vers d'autres supports. Ainsi, entre autres solutions, Xerox propose, pour le seul environnement de bureau, des rductions des cots de gestion documentaire d'au moins 25. Lenvergure de lentreprise lui a permis de dvelopper 5 centres de recherches et de technologie s travers le monde. 1500 personnes maintenant sont actuellement impliques dans le domaine de la recherche.

8

Prsentation de la socit

Figure 1 : Les centres de recherche de Xerox travers le monde

Il s'agit d'une socit internationale spcialise dans les solutions visant simplifier le travail et rendre les entreprises plus productives. Que ce soit pour une petite entreprise ou pour une multinationale, Xerox offre des produits et des services susceptibles de les aider amliorer leurs processus de gestion; abaisser leurs cots; courter les dlais d'excution et partager les informations caractre critique. Ces produits et services facilitent la transformation des informations imprimes en informations numriques et vice versa. Ils rendent galement plus aiss la visualisation, l'agencement et le partage des informations en les prsentant sous forme de documents numriques. Ils facilitent aussi l'envoi intra rseau des documents pour les faire circuler d'un point un autre de l'entreprise ou du globe. L'impression, la publication et la copie sur papier de ces documents s'en trouvent galement facilits.

9

Prsentation de la socit

1.1.2 Organisation interneXerox comprend trois grands dpartements : le PSG (Production System Group) travaille sur limpression des documents grande chelle et sur la conception des machines et des systmes dimpression. le XOG (Xerox Office Groupe) est charg des applications en rseau et des services offerts aux bureaux et organisations administratives en matire de photocopieurs, dimprimantes, etc. le XGS (Xerox Global Services) fournit des services informatiques spcialiss aux entreprises. Cest de ce dernier dpartement que relvent les centres de recherche et laboratoires Xerox, lorigine dinnovations majeures comme les imprimantes laser couleur numriques multifonctions, les copieurs et tlcopieur et les workflow documentaires. Situs aux EtatsUnis (3 centres), au Canada (1 centre) et en Europe (le XRCE de Meylan), les cinq centres de recherche et dveloppement connus de Xerox, emploient eux seuls 1500 personnes dont de nombreux doctorants et stagiaires. Cest depuis ses dbuts sous le nom de Haloid Company, que Xerox a fait le choix dinvestir en permanence une part substantielle de ses recettes dans la recherche fondamentale et applique et beaucoup de technologies considres aujourd'hui comme videntes ont t conues ou amliores dans les centres Xerox. On comprend alors pourquoi aujourd'hui encore, Xerox est encore plus attach son investissement dans la recherche.

1.1.3 Segmentation du marchLes principaux clients de Xerox sont des professionnels comme lindique son fameux slogan "Printing for Professional" mais les mnages occupent une place de plus en plus importante dans le crneau des imprimantes et notamment des imprimantes multi-fonctions (scanner, fax photocopieur). Sur le plan gographique, lindique la figure 2 suivante, les principales sources de revenus de Xerox sont lAmrique (60%) et lEurope (33%).

10

Prsentation de la socit

Figure 2 : Rpartition gographique des revenus de Xerox (donnes 2005) Position de Xerox sur le march : Avec plus de 5000 brevets dposs dans le monde, le groupe Xerox a acquis une position dominante sur les marchs mondiaux en fournissant des produits et des services de haute technologie, qui se distinguent non seulement par leur qualit, fiabilit, productivit, robustesse et simplicit dutilisation, mais aussi par leur respect de lenvironnement.

11

Prsentation de la socit

1.2 XEROX RESEARCH CENTER EUROPE

Xerox Research Centre Europe mne les activits de recherche propres Xerox en Europe, en coordonnant recherche, ingnierie et le Technologie Showroom , une dmonstration vitrine de la recherche Xerox pour les clients et forum dchange. Le centre dveloppe aussi des relations avec la communaut scientifique Europenne, travers des projets collaboratifs et des partenariats. XRCE cre des technologies de gestion documentaire innovantes pour soutenir la croissance dans les services concerns. La recherche concerne le traitement de limage et du texte, les structures de documents, ltude et la comprhension des pratiques en matire de travail.

12

Prsentation de la socit

1.1.4

La SPD et lquipe CodeX

Les applications concrtes qui en dcoulent permettent de faciliter grandement la gestion de linformation dans de multiples langues, lapprentissage automatique, le traitement dimages, lingnierie documentaire, la sociologie et lethnographie. Le XRCE abrite galement lune des plus importantes entits du groupe, la SDP (Smart Document Platform) qui, comme indiqu dans les figures 4 et 5 suivantes, dpend de la filiale amricaine du groupe et qui comprend trois composantes, la Plateforme daccueil de technologies (2 ingnieurs), le Categorizer (4 informaticiens) et le CodeX (7 ingnieurs).

Figure 3 : Organigramme de Xerox et positionnement du XRCE et de la SDP

13

Prsentation de la socit

1.2.1.1

Donnes cls

Effectifs : 4 membres permanents (3 ingnieurs Codex + 1 Chef dquipe)

1.2.1.2

Missions

Au sein de la SPD, le projet CodeX (projet part entire et cadre la mission de lquipe MTM) a pour principales missions : doptimiser linvestissement logiciel des entreprises dapporter le support ncessaire pour assurer le bon dploiement des services au sein des projets de dveloppement dapporter une visibilit globale et une harmonisation des activits de dveloppement logiciel l'chelle de l'entreprise, permettant ainsi d'viter la redondance des efforts et de capitaliser sur les investissements dj raliss de supprimer les cots cachs importants lis la maintenance de nombreux outils et petits serveurs de groupes disparates de faciliter la constitution d'quipes de projet composes de membres appartenant des organisations voire des socits diffrentes que ce soit en sous-traitance ou en off-shore de dvelopper la communication et le niveau d'information des quipes de dveloppement logiciel de rduire les cots les dlais de commercialisation des produits

Figure 4 : Composantes de la SDP

14

Prsentation de la socit

1.1.5

La mthodologie SIGMA-PLUS et le systme Scrum

La mthodologie SIGMA-PLUS (Six Sigma et Lean Six Sigma) est utilise par XRCE comme mthode damlioration de la qualit reposant sur la matrise statistique des procds de traitement de linformation. Cest aussi un mode de management qui repose sur une organisation trs encadre ddie la conduite de projet. Cette mthode est aujourd'hui utilise par de nombreuses entreprises, en complment ou en remplacement des systmes de management de la qualit suivant la norme ISO9000. En effet et plus particulirement en ce qui concerne Six Sigma, la mthode est mme de satisfaire les clients en rduisant la variabilit des processus de lentreprise, ses cots et ses parts de marchs. Par contre, le systme Lean-Six-Sigma associe les mthodes qualitatives du Lean Management et du Six Sigma logistique de l'entreprise. L'ide qui a donn son nom la mthode est de rpondre aux possibilits de non conformit de part et d'autres de la moyenne de 3 carts-types (les fameux 6 sigma) en matrisant ces causes grce l'utilisation de tableau de bord tels que les KPI logistiques. L'offre de SIGMA-PLUS se rpartit selon trois branches: les tudes : dans les domaines de la simulation (phnomnes physiques, conception systme, analyse et contrle de processus) et du traitement de l'information la diffusion de logiciels : les produits au catalogue de SIGMA PLUS relvent du datamining, de lanalyse statistique et de donnes, des rseaux de neurones, etc. la formation et le conseil. deux concepts troitement lis du fait de la demande du march confront la puissance croissante des logiciels leur disposition Pour complter les mthodes de dveloppement proposes par SIX-SIGMA, Scrum, lune des sept mthodes agiles a t privilgie. En rappelant quune mthode agile (cf. Annexe XX relative aux Mthodes Agiles) est une mthode de dveloppement informatique permettant de concevoir des logiciels en impliquant au maximum le demandeur, il faut noter quil sagit de techniques plus pragmatiques que les techniques traditionnelles puisquelles visent la satisfaction du besoin du client plus que la ralisation du contrat tabli pralablement. Ainsi, la Mthode Scrum, terme emprunt au rugby signifiant la mle, est oriente vers le domaine du dveloppement informatique de la gestion du travail. 15 pour amliorer de manire substantielle la performance

Prsentation de la socit

Scrum est une mthode Agile pour la gestion de projets. Elle a t conue pour amliorer grandement la productivit dans les quipes souvent paralyses par des mthodologies plus lourdes. Les racines de Scrum se retrouvent dans la publication de Takeuchi et Nonaka dans "The New Product Development Game" (Havard Business Review, Jan-Fv 1986). Son utilisation est prvue initialement pour la gestion de projets de dveloppement, et elle a t utilise avec succs pour englober Extreme Programming et d'autres mthodes de dveloppement. Cependant, elle peut thoriquement s'appliquer n'importe quel contexte o un groupe de personnes ont besoin de travailler ensemble pour atteindre un but commun comme grer une petite cole, des projets de recherche scientifique ou planifier un mariage. Bien que Scrum ait t conue pour la gestion de projets de dveloppement de logiciels, elle peut tre utilise dans des quipes en cours de maintenance, ou comme une approche de gestion de programmes quipe CodeX.

16

Gestion du projet

2

LA MISSION

17

Gestion du projet

2.1 ORGANISATIONPour une meilleure visibilit du travail effectuer, qui sinsre logiquement dans le projet CodeX, les responsables de XRCE ont labor un cahier de charge dont le contenu permet dtablir aussi bien les tches accomplir que les limites de la mission. Lobjectif de la mission est dtudier les perspectives de mise en place dun mode "hors-ligne" (offline) qui permette d'utiliser un certain nombre de services de CodeX sans tre connect au serveur. Comme cela sera dtaill dans la partie Ralisation , lexcution de la mission devait logiquement passer par les tapes dtude de la faisabilit du mode hors-ligne par service, de mise en place des interfaces API ncessaires et de dveloppement de lapplication cliente fonctionnant de manire autonome. Aussi la dmarche de dveloppement des applications retenue a intgr, dune part, la feuille de route de la mission de lquipe EERIE (objectifs et du projet et planning de travail), dautre part, lengagement de qualit et, enfin, lvaluation des risques.

18

Gestion du projet

2.2

LA

FEUILLE DE ROUTE DE LA MISSION

On peut rsumer la feuille de route de la mission confie lquipe MTM ses deux aspects objectifs gnraux et tapes principales .

1.1.6

Les objectifs gnraux

Les objectifs gnraux ont t rpartis en six points : Etude globale du cahier des charges Etude des fonctions de CodeX online Dfinition des critres de choix des services implmenter en offline Etude de solution pour la sauvegarde des donnes (fichiers, base de Conception des interfaces de manipulations pour CodeX offline Mise en place dun systme dauthentification des utilisateurs.

donnes)..

1.1.7 Les tapesLes principales tapes prvues initialement ont t : : - se familiariser avec lenvironnement de CodeX - tudier des documents et lments disponibles pour prparer la phase de formation avec un ingnieur CodeX - analyser lensemble des services offerts par Codex on-line - planifier le droulement des interviews Llaboration et la prsentation du plan dactivit : Paralllement la et de la conception de lapplication, une tche complexe La collecte et la validation des besoins : Une tape de prparation destine

mission de dtermination des besoins, un plan dtaill a t tabli en vue de llaboration particulirement au niveau de la dtermination des dates de livrable. Limplmentation de nouvelles API : Dans cette phase tait propose la

cration de nouvelle API (Web services) pour permettre laccs du client CodeX aux donnes du Server CodeX. 19

Gestion du projet

Limplmentation du client : Il sagit de la ralisation dun client portable en

java permettant lutilisation de linterface de CodeX en mode dconnecte . Llaboration des supports de formation : A chaque tapes de ralisation,

des supports techniques doivent tre livrs incluant certaines formations aux utilisateurs selon leurs besoins

20

Gestion du projet

3

GESTION DU PROJET

21

Gestion du projet

3.1 LENGAGEMENT DE QUALITLengagement de qualit porte sur et portabilit. la capacit de fonctionnement des applications leur fiabilit, leur facilit dutilisation, leur rendement et leurs maintenabilit

1.1.8 La Capacit fonctionnelle des applications- Leur Interoprabilit : CodeX client hors ligne utilise le protocole Soap pour lchange des donnes avec le serveur CodeX, et - Leur Confidentialit : linterface de connexion permettra que seuls les utilisateurs codex aient le droit daccs aux services de CodeX. A chaque appel dAPIs Soap par le client, ce dernier envoie une cl de session qui doit tre valid par le serveur sinon un message derreur est envoy au client.

1.1.9 La Fiabilit (intgrit)- Leur Maturit et leur tolrance aux fautes : l'application dveloppe tant prive, des exigences en maturit et en tolrance aux fautes sont donc rclames - Les Possibilits de leur rcupration : lapplication dvelopper doit procder une duplication de donnes chaque rcupration dinformations du serveur - la Mesure de la qualit : mise en place dun test surveillant lenregistrement des modifications et la rcupration des donnes initiales en cas dchec, avec une dtection automatique de manipulation incorrecte avant excution.

1.1.10La facilit dutilisation- pour toutes interfaces : la facilit dutilisation est exige. - pour CodeX en ligne : garder absolument les types de manipulation existants.

1.1.11Le rendement et la disponibilit- Comportement vis--vis du temps : la rcupration des donnes du serveur CodeX est optimise de telle sorte quil est possible dafficher 20000 artefacts en quelques dizaines de minutes 22

Gestion du projet

- Comportement vis--vis des ressources : au moment de la construction de la base de donnes locale, les ressources doivent tre partages pour chaque service sollicit par le client

1.1.12La maintenabilit et la portabilit- Maintenabilit : le produit tant destin tre commercialis, les facilits d'analyse, de modification, et de test sont essentielles pour qu'il puisse tre utilis et amlior par la suite. - Portabilit : pour l'application, le niveau de portabilit sera celui des technologies supports qui constituent les principales contraintes techniques.

23

Gestion du projet

3.2 LE CONTRLE DES RISQUES1.1.13Le processus de contrle des risquesLe processus de contrle des risques exige la fois leur auto dtection pralable, leur rvaluation permanente et la prvision des nouveaux risques (figure 5 ci-aprs).

24

Gestion du projet

Figure 5 : Cheminement de lvaluation des risques

25

Gestion du projet

1.1.14Le mode de prvision des risquesTableau 1 : Mode de prvision des risques

Types de risques

Causes possibles

Impacts Prvisibles

Proba bilit

Niveau criticit

Actions envisages1res valuations 1 Optimiste + 2 Normales + 1 Pessimiste Validation avec le Responsable du stage

Date cible

Et at

Evaluation des dlais

Manque dexprience

Retard, non respect des dlais (2)

2

4

T Immdiat A

Evaluation de la charge des tches

Manque dexprience et spcifications non encore commences Manque dexprience ou risques oublis

Retard ou tches inacheves (1)

2

4

Rvaluations et adaptations en cours de projet

A partir du 01/03

T

Evaluation des risques imprvus

Obligation de subir les consquences sans les avoir prvues (3)

2

6

Validation avec le Responsable du stage et des rvaluations rgulires

A partir du 01/03

A

EC

Risques techniques dus au non matrise des outils

Insuffisance de connaissances ou mauvaise rpartition des tches

Retard ou produit inachev (2)

2

4

Formation sur les nouveaux outils Rpartition plus souple des tches Communications internes importantes Structuration de lquipe, distribution des rles, entraide, motivation et responsabilisatio n

16/02 et sur toute la dure du projet

T

EC

Risque de mauvaise coordination entre membres lquipe

Mauvaise communication ou non formalisation

Incompatibilit entre les applications dveloppes par lquipe EMAEERIE(3)

2

6

Sur toute la dure du projet

T

26

Gestion du projet

Les critres et les ratios retenus pour leur valuation sont : - Impact - Criticit - Etat : nul = 0, faible = 1, < 10% = 1, fort = 2, > 10% = 2 catastrophique = 3

- Probabilit : nulle = 0,

: Impact * Probabilit

: A (Attente), NC (Non Commenc), EC (En Cours), T (Termin), V (Valide)

27

Gestion du projet

3.3

CONTRAINTES DE DVELOPPEMENT ET DE LIVRABLELes dveloppements envisags allaient tenir compte la fois des macro tches et

des jalons et livrables qui leur sont associs.

1.1.15 Les macro tchesCompte tenu de lindpendance qui existe entre les interfaces de publication et les APIs (qui ont en seul point commun lutilisation des WEB-Services), les deux processus de dveloppements peuvent tre engags, en parallle, dans le cadre dun cycle de vie en V avec possibilit de paralllisme. Les macros tches qui en rsultent ainsi que leur cheminement (figure 8) sont indiques ci-aprs : T01 : T02 : T03 : T04 : T05 : T06 : T07 : T08 : T10 : T11 : T12 : T13 : T14 : T15 : T16 : Runion de lancement Comprhension du sujet Auto-formation technique (PHP, SOAP, WSDL, ) Rdaction de plan de qualit Gestion de projet et suivi qualit Spcification et conception des APIs du service My Account Spcification et conception des IHMs du service My Account Spcification et conception des APIs du service Trackers Spcification et conception des IHMs du service Trackers Ralisation de la fonctionnalit Rcupration des donnes Ralisation du service My Account Ralisation du service Trackers Ralisation de la fonctionnalit Synchronisation des donnes Tests d'interaction interne et externe des fonctionnalits de CodeX Offline Revue Finale

28

Gestion du projet

Runion de lancement Dbut : 06/02/06 Fin : 07/02/06

Comprhension du sujet Dbut : 08/02/06 Fin : 09/02/06

Auto-formation technique Dbut : 09/02/06 Fin : 20/02/06

Rdaction qualit

de

plan

de

Analyse du projet Dbut : 14/02/06 Fin : 21/03/06

Spcification et conception des APIs du service My Account Dbut : 21/03/06 Fin : 01/04/06

Dbut : 15/02/06 Fin : 24/02/06

Spcification et conception des IHMs du service My Account Dbut : 01/04/06 Fin : 14/04/06 Spcification et conception des APIs du service Trackers Dbut : 23/03/06 Fin : 21/04/06

Spcification et conception des IHMs du service Trackers Dbut : 18/04/06 Fin : 06/05/06

Ralisation Account

du

service

My

Gestion de projet et suivi Quantit Dbut : 20/02/06 Fin : 25/08/06

Spcification et conception des IHMs du service Trackers Dbut : 18/04/06 Fin : 06/05/06

Dbut : 20/02/06 Fin : 21/02/06

Ralisation de la fonctionnalit Rcupration des donnes Dbut : 08/05/06 Fin : 07/02/06

Ralisation Trackers

du

service

Dbut : 20/02/06 Fin : 21/02/06

Ralisation fonctionnalit Synchronisation donnes Dbut : 20/02/06 Fin : 21/02/06

de

la des Tests d'interaction interne et externe des fonctionnalits de CodeX Offline Dbut : 20/02/06 Fin : 21/02/06 Revue Finale Dbut : 20/02/06 Fin : 21/02/06

Figure 6 : Diagramme de PERT (Cheminement des macros tches) 29

Gestion du projet

30

Gestion du projet

1.1.16Les jalons et livrables Concernant les jalons et livrables

associs, ont t retenus 4 niveaux de jalons:Jalon 1 : APIs Soap du service Mon Compte . Jalon 2 Jalon 3 Jalon 4 : Dveloppement Service Client Mon Compte . : API Soap du service Trackers . : Dveloppement Service Client Trackers .

31

Gestion du projet

3.4 PROCESSUS SUPPORT DE LA MISSIONLe processus support du projet intgre la gestion des modifications ventuelles, des configurations envisageables, des risques encourus, du support documentaire et des dlais.

1.1.17La gestion des modificationsOn suppose, pour la gestion des modifications, que tout acteur du projet peut tout moment effectuer une demande de modification sous la forme dune fiche modification transmise au chef de projet qui effectue avec son auteur une tude dimpact de la modification sur les charges et planning. Il peut s'agir d'une mise niveau, d'une volution, d'une anomalie, d'une extension ou d'une correction. Les modifications font lobjet dune fiche modification et sont valides par le comit oprationnel ou le comit de pilotage. Destine consigner les modifications apportes un produit logiciel (code source, test, document, etc.) et lie un numro attribu squentiellement, la fiche de modification (cf. modle en Annexe XX) est destine collecter lchange dinformations entre un demandeur et un ralisateur, sur les actions entreprendre la suite dun problme dtect. Cette fiche informe, en outre, sur limpact, le cot et les dlais de ralisation.

1.1.18La gestion de configurationIl sagit, ici, de reprendre la dmarche de cette discipline de la gestion technique et administrative destine : Identifier et documenter les caractristiques fonctionnelles et physiques d'un article de configuration. Matriser les modifications de ces caractristiques. Enregistrer et rendre compte du processus et de l'tat des modifications. Procder des contrles sur les articles de configuration afin de vrifier la conformit aux exigences spcifies.

1.1.19La gestion des risquesSagissant de la gestion des risques, la mthodologie retenue consiste examiner l'tat du projet, identifier les risques qui menacent son bon droulement et entreprendre les actions ncessaires pour leur rduction. Son processus se dcompose en deux tapes :

32

Gestion du projet

l'valuation des risques : un processus qui permet d'identifier et de mesurer les risques inhrents un projet en saccompagnant dune identification base sur des faits connus et approuvs par tous.

La matrise des risques : un processus qui permet la prise de conscience des parties intresses et la mise en uvre des actions appropries.

1.1.20La gestion des documents de suiviLa gestion des documents techniques et de procdure de suivi de la mission revt une importance capitale puisquelle conditionne sa russite, en amont et en aval de la mission.

1.1.21Les documents de procdure

On distingue parmi les documents de procdure : le plan de qualit. le diagramme de Gantt. les courbes davancement On suppose ici que pour chaque tche, suivie laide dune fiche de tche compose de plusieurs champs dinformations (intitul de la tche, sa date de dbut et de fin prvues), on est cense connatre tout moment son tat davancement. Cette fiche de tche renseigne galement sur les dates de dbut et de fin relles ainsi que les charges prvues, consommes et restantes engager. Ce type de suivi des tches permet ainsi dviter les carts par rapport aux dates prvues ralises. Lorsquune tche doit tre modifie, elle doit tre renseigne par une fiche de modification de tche afin que ses principaux responsables comme tous les acteurs du projet soient au courant. Cest ainsi quune courbe davancement est tablie rgulirement afin de mesurer lavancement global du projet. Par ailleurs, un suivi au niveau du plan de qualit a t mis en place, li lobligation de validation de chaque document par le chef du projet aprs un cycle auteur/lecteur ralis par lquipe de matrise duvre. Celle-ci tient une runion hebdomadaire avec les membres de lquipe afin de mesurer lavancement global du projet mais aussi le niveau de ralisation des tches en cours de chacun des membres de lquipe. Les comptes rendus de ces runions sont conservs en tant quenregistrement qualit.

Les documents techniques33

Gestion du projet

Les documents techniques de ralisation sont de plusieurs niveaux de : Conception globale. Conception dtaille. Documentations lies au code source. Documentations lies aux tests

34

Gestion du projet

3.5 LIMITES DU PROJETLensemble des documents techniques de la mission confie lquipe MTM sinsrent dans le cadre dune application globale Portabilit de CodeX , aussi faut-t-il garder lesprit que cette mission CodeX hors ligne (qui consiste mettre en place des APIs et une application cliente autonome valable sans connexion au serveur codex) constitue la porte CodeX qui reprsente la fois le point dentre depuis lextrieur vers la base de donnes de CodeX et le point de sortie vers lextrieur.

1.1.22Les interfacesIl faut aussi retenir que lquipe est amene raliser des interfaces donnant la mme visibilit CodeX depuis lextrieur, autrement dit, prvoir les mmes interfaces que CodeX on-line, permettant aux utilisateurs autoriss laffichage complet de ses projets et les services qui y sont associs en mode hors ligne. Comme le montre la figure 9 suivante, on peut distinguer alors deux types dutilisateurs potentiels : des utilisateurs non connects au systme qui peuvent visualiser les contenus des utilisateurs connects au systme qui, selon les droits attribus, peuvent ou non diter des contenus.

Vrification des Droits

Codex

Figure 7 : Contrainte de vrification des droits

35

Gestion du projet

1.1.23Les contraintes techniques de lapplicationOn notera galement que la mise au point des documents techniques est subordonne aux contraintes et exigences techniques prcises par le cahier de charges, dont celles lies : Lutilisation de lenvironnement JDK 1.5.0 Lenvironnement de dveloppement intgr Eclipse 3.0. La Plateforme LAMP (Linux, Apache, MySQL, PHP) de Codex Lenvironnement de dveloppement intgr Eclipse 3.0 Lutilisation dAxis 1.2 Apache comme moteur et API dappel de Web Services Du JDOM en tant que parseur XML La bibliothque Nusoap pour la mise en uvre des API Soap Loutil de dveloppement Collaboratif Codex Loutil de versionning Subversion

1.1.24Les contraintes temporelles et de chargeLensemble de la mission tale sur une dure de sept mois (dbut fvrier fin aot 2006) devait tenir compte, suite ltude des tches et la planification, la fois de la charge de travail estime 210 jours/homme pour lensemble du projet, autrement dit, 137 jours par individu et des contraintes temporelles lies aux points de projet et aux revues. Etant convenu quau cours du droulement du projet, les responsabilits de chaque membres de lquipe pouvaient changer au cours de lavancement des travaux, les plannings des runions points de projet et des revues ont t tablis suite plusieurs runions de travail formelles ou informelles. En dfinitive, le planning suivant a t retenu.

36

Gestion du projet

Tableau 2 : Planning des points de projet et des revues

Points de projet 15 28 15 30 15 30 15 30 15 15 30 15 26 Fvrier 2006 Fvrier 2006 Mars 2006 Mars 2006 Avril 2006 Avril 2006 Mai 2006 Mai 2006 Juin 2006 Juillet 2006 Juillet 2006 Aot 2006 Aot 2006

Revues - 15 Mars 2006 : Revue Qualit. - 01 Avril 2006 : Spcification/Conception.

- 01 Aot 2006 : Revue Finale.

1.1.25Les contraintes organisationnellesEnfin, lorganisation de la mission a inclus le volet de la communication qui a t maintenue tout au long de la ralisation du projet sous deux formes : une communication interne entre les membres de lquipe ralise via

les mails, les runions et leurs comptes rendus ainsi que les fiches suiveuses internes. Pour une meilleure organisation interne, les comptes rendus des runions devaient suivre une procdure prcise relative notamment ltablissement de lordre du jour, la date, le lieu, lheure ainsi qu la dsignation du prsident et du secrtaire, facilitant ainsi la bonne planification des tches respectives de chaque membre de lquipe. une communication externe concernant principalement lchange des flux dinformations avec le reprsentant du matre douvrage et responsable du stage. Cette communication devait tre ralise par le biais des mails (portant essentiellement sur les comptes rendus des runions, sur les demandes dinformations, etc.), les runions (intergroupes, avec ou sans le reprsentant du matre douvrage), les fiches suiveuses, les fiches de modifications, les fiches des risques, les fiches planning runion, les fiche de validation du plan qualit, les fiche danomalies des tests dintgrations et les fiches de suivie de version.

37

Gestion du projet

4

ANALYSE

38

Gestion du projet

39

Gestion du projet

4.1 LES OBJECTIFS DE LA SOLUTION CODEXLa vocation premire de la plateforme CodeX de dveloppement collaboratif rsidant dans la rduction des cots de l'entreprise, on comprend quil sagit de sa comptitivit, voire de sa survie dans un cadre mondial des changes de plus en plus librales. En s'appuyant sur les succs obtenus grce aux outils et aux mthodes de travail du domaine Open Source, CodeX a privilgi deux dimensions indispensables au succs de la rutilisation de logiciel, savoir : Une infrastructure globale qui permet un partage et une rutilisation sans effort, Un changement dans les valeurs et la culture d'entreprise.

Figure 8 : les 2 dimensions indispensables une stratgie russie de rutilisation

Codex offre une large panoplie d'outils et de services destins amliorer la productivit et d'courter le dlai de mise sur le march des produits. Il permet galement de: Apporter une visibilit globale et une harmonisation des activits de dveloppement logiciel l'chelle de l'entreprise, permettant ainsi d'viter la redondance des efforts et de capitaliser sur les investissements dj raliss, Supprimer les cots cachs importants lis la maintenance de nombreux outils et petits serveurs de groupes disparates,

40

Gestion du projet

Faciliter la constitution d'quipes de projet composes de membres appartenant des organisations voir des socits diffrentes que ce soit en sous-traitance ou en off-shore,

Amliorer

la

communication

et

le

niveau

d'information

des

quipes

de

dveloppement logiciel. Rappelons qu lorigine, le site de Source Forge permettait aux utilisateurs du monde entier dditer et dutiliser des codes Open Source du fait de la licence GPL libre que lentreprise dtenait. A partir de lanne 2000, CodeX a pu voir le jour en se basant sur SourceForge auquel ont t apports plusieurs amliorations et modifications, notamment aux niveaux de gestion des Trackers. En 2001, quand SourceForge a dcid la fermeture de son site, un de ses dveloppeurs reprit le dernier code et lappela Gforge tandis que SourceForge lana SFEE (en java) destination des entreprises. la

Tableau 3 : Comparaison entre CodeX et Gforge

CodeX

GForge

Bon outils de suivi

Plus ouvert

Code invisible pour lextrieur

Code visible lextrieur

Les seuls contributeurs au code sont lquipe CodeX et ses clients

Grande contribution au code

41

Gestion du projet

Parmi les clients de CodeX

1

(dont ST MicroElectronics

et FranceTelecom

) figurent

des entreprises de diffrents secteurs de l'industrie mais en particulier de llectronique et des tlcommunications qui apprcient l'expertise de Xerox dans le domaine de la rutilisation de logiciel en entreprise (cf. url : http:\\CodeX.xerox.com). Les clients payent souvent le prix fort pour pouvoir accder aux services proposs par CodeX, comme la correction des bugs, les possibilits offertes en matire dajout permanent de nouvelles fonctions et la mise dispositions de logiciels et de codes sources.

1

42

Gestion du projet

4.2 FONCTIONNALITS ET LIMITES DE LA PLATEFORME CODEXLventail d'outils et de services dont les quipes de dveloppement ont besoin quotidiennement sont gnralement : Les outils de gestion et de dveloppement : systme de contrle de version, publication de nouvelles versions, outil universel de suivi des dfauts, des tches, des besoins, gestion des corrections et des contributions externes, intgration avec vos environnements de dveloppement favoris. Lespace projet mettre en place et qui est totalement configurable : cration dun nouvel environnement projet, choix des services activer, gestion des permissions d'accs aux membres des quipes (tous les services CodeX sont disponibles tout instant sur l'intranet de votre entreprise sans aucun cot de dploiement). Les outils de communication et de gestion des connaissances : gestion de documents, d'annonces forums de discussion, aux quipes listes de distribution et gestionnaire permettant de dveloppement de communiquer

efficacement sur leurs activits. Administration du projet : contrle d'accs, audit des changements, accs au projet, capacit avance dtablissement de rapport l'aide de fonctionnalits d'exportation de donnes.

43

Gestion du projet

Figure 9 : Schma de la plateforme CodeX Aussi, pour rpondre ce type spcifique de besoins, CodeX a prfr s'appuyer sur des outils et des technologies Open Source dont des millions d'utilisateurs ont apprci les services fiables. Sur le plan technique, il faut prciser que : Dune part, CodeX reste une solution base sur une interface Web qui s'appuie sur PHP, un langage puissant, rapide et optimis pour les applications Web. Les pages du serveur CodeX sont dlivres par la plateforme Linux/Apache, leader actuel du march du web avec 62% de part de march contre 30% seulement pour Microsoft. Dautre part, les donnes des projets sont prises en charge par le systme de gestion de bases de donnes MySQL connu pour ses performances et sa grande stabilit.

Enfin, CodeX s'installe sur toute machine quipe du systme Red Hat Entreprise Linux Server 3.0, un systme d'exploitation totalement support, sr et adapt aux applications critiques.

Ainsi, si aujourdhui le quatuor Linux Apache MySQL PHP (connu sous l'acronyme 'LAMP') est utilis par des centaines de milliers de serveurs Web travers le monde parce que sa flexibilit, sa fiabilit et son efficacit sont reconnues. Les mmes qualits font que la plateforme CodeX convient aussi bien aux petites, moyennes ou grandes entreprises, dautant plus quelle peut servir aussi bien 10 que 10000 utilisateurs avec la mme efficacit en termes de cot. 44

Gestion du projet

Cependant, la principale critique faite la plate forme CodeX concerne la fois limpossibilit daccs au serveur depuis lextrieur et labsence de documentation sur les spcifications techniques du projet, ce qui peut sexpliquer par des motifs de scurit propres au groupe Xerox, qui, par ailleurs, sont tout fait comprhensibles.

45

Gestion du projet

5

SPCIFICATION

46

Gestion du projet

5.1 ETUDE DES BESOINS Besoins fonctionnels :

Pour les besoins fonctionnels, ont t retenus uniquement les besoins suivants qui ont une priorit haute car le dlai allou au projet ne permet pas de traiter les besoins qui ne sont pas essentiels : Besoin fonctionnel 1 : Lutilisateur pourra se connecter au client CodeX en mode connect aprs authentification. Besoin fonctionnel 2 : Lutilisateur pourra choisir de creer une nouvelle Session ou douvrir une Session existante. Besoin fonctionnel 3 : Lorsquil ouvrira une Session, lutilisateur devra choisir les projets et pour chacun les Trackers quil souhaite rcuprer. Besoin fonctionnel 4 : Les Services Trackers et My Account de CodeX seront utilisables par lutilisateur en mode dconnect . Besoin fonctionnel 5 : Linterface de CodeX permettra a lutilisateur dditer ou dajouter des Mta Donnes spcifiques a la conception de CodeX et qui sont : Pour le service Tracker : Artfacts Commentaires Fichiers attachs Dpendances Informations Utilisateur Comptences Profils

Pour le service My Account :

Besoin fonctionnel 6 : Lutilisateur peut, en mode dconnect choisir de Supprimer ou de Rinitialiser les donnes dune Session existante. Besoin fonctionnel 7 : Lutilisateur pourra, uniquement en mode connect , choisir de Synchroniser les donnes dune Session existante. Besoin fonctionnel 8 : Lutilisateur pourra choisir les actions a accomplir pour la mise a jour des donnes via linterface de Gestion de Conflits.

47

Gestion du projet

Besoins non fonctionnels : non fonctionnel 1: Eviter quune panne du processeur naffecte le

Besoin

fonctionnement du Client CodeX. Besoin non fonctionnel 2 : Protocole de transport http. Besoin non fonctionnel 3 : Protocole dchange SOAP. Besoin non fonctionnel 4 : Vrifier la connectivit avec le Server. Besoin non fonctionnel 5 : Structure XML de stockage de donne.

48

Gestion du projet

5.2 DIAGRAMME DE CAS DUTILISATIONS (HAUT NIVEAU)

Systemuses choisir les services CodeX

uses

CodeX User

uses

Authentification et gerer les sessions

uses

XML DB uses m aintenir le compte (Service Account Maintenance ) uses

uses

SOAP API uses

consulter et soumettre les artefacts (Service Outil de suivi )

uses

invoquer les web services et Creer la structure de donnees

uses uses

repliquer les donnees et resoudre les conflits

49

Gestion du projet

Ce cas dutilisation prsente linteraction entre les acteurs internes (XML BD & Soap APIs) et externes (CodeX user) du systme. Au moment de la cration dune nouvelle session, lutilisateur choisit les projets et les services associs, le systme importe les donnes grce des appels Soap et stocke les informations dans Base de donnes XML.

50

Gestion du projet

6

CONCEPTION

51

Gestion du projet

6.1 PROBLEMATIQUELes services offerts par CodeX dpendent de linfrastructure globale sur laquelle s'appuie la totalit de la communaut du dveloppement logiciel de Xerox. Des services comme My Account, Wiki, Subversion, CVS, Trackers, etc., font partie intgrante de cette infrastructure. Par ailleurs, le cahier de charge, tabli pour la mission de dveloppement de lapplication Hors Ligne , a impos lquipe de projet la ncessit dutilisation du service le plus important offert par CodeX, en loccurrence, le Service Trackers. Les trackers (ou outils de suivi au sens CodeX) dsignent des structures complexes reprsentes dans la base de donnes telles que les champs utiliser et leurs valeurs autorises. Ils permettent dassurer le suivi dartifacts varies tels que des bugs, des tches, des fiches dassistance, etc. Un projet peut crer autant de trackers que ncessaire. Ces structures de donnes dpendent ncessairement les unes des autres car chaque artifacts est gnr partir dun tracker qui, de son ct, permet de crer plusieurs artifacts. Par le biais de la plate-forme CodeX dite en ligne , les utilisateurs ont la possibilit de grer leurs artifacts, leurs trackers, leurs projets et donnes personnelles, leurs outils de suivi et systmes de contrle de version du code source, leurs listes de distribution, leurs gestionnaires de fichiers et de documents, etc. A ce niveau, le cahier de charge tabli tait galement exigeant en matire de scurit puisquil incluait la contrainte imprative de nautoriser en mode hors ligne que la seule gestion des artifacts. La partie administration des trackers ne devait en aucun cas tre accessible en mode hors ligne. Aprs analyse, lquipe a constat que la mise en place dune application hors ligne navait pas lieu dtre pour certains services proposs par CodeX, comme Wiki, Doc Man, CVS, et a conclu avec le matre douvrage la ncessit de consacrer lapplication en priorit aux services Trackers et My Account. 52

Gestion du projet

Figure 10 : Principe de Fonctionnement du mode hors ligne de CodeX

La mise en place dune application CodeX en mode hors ligne passe par la ncessite de bien distinguer le mode de communication et le mode de fonctionnement des applications de CodeX. Le mode qui existe actuellement tant le mode dit en ligne , la communication entre les clients CodeX et le Server passe par le biais de requtes http utilises par les sites web classiques. En mode en ligne , les utilisateurs peuvent visualiser par leurs navigateurs les pages web de CodeX et ainsi accder a ses diffrents services. CodeX est aussi compos dun Server Web Apache, dun Server MySQL et dune base de donnes. Cependant, lutilisation de la version hors ligne de CodeX se fera par biais de requtes SOAP rendues possible par le dveloppement de web services cote serveur (API SOAP) et de certains apis ct client (API AXIS).

53

Gestion du projet

54

Gestion du projet

6.2

LES SOLUTIONS ETUDIEES

Aujourdhui, le Server CodeX est constitu dun ensemble dinterfaces (APIs) dfinissant des fonctions permettant daccder la base de donnes. Aussi, lune des phases importantes de la mission a t celle de la cration de web services permettant au client java de manipuler les donnes de la base. Pour ce faire, un examen comparatif (cf tableau 4 suivant) de trois diffrents types de Web services (REST, XML-RPC et SOAP) a t ralise permettant de tirer les constatations suivantes :

REST : est une architecture de services Web, la manire de SOAP et de XML-RPC. Mais il sagit seulement dun style d'architecture, pas dun standard et il n'existe donc pas de spcifications de REST. Il faut dabord comprendre et assimiler le style REST pour ensuite concevoir des applications ou des services Web selon ce style.

XML-RPC : (XML Remote Procedure Call) est un protocole dchange de messages XML ayant pour vocation dappeler des mthodes distance, travers un rseau. Cest un protocole simple qui fonctionne par appel de procdures paramtres au formalisme XML mais quil nest utilisable que pour un nombre limit de types de donnes.

SOAP : offre, malgr le fait quil soit plus complexe implmenter, la possibilit dutiliser un grand nombre de types de donnes ainsi que des API RPC, ce qui a orient le matre douvrage vers le choix de ce protocole qui permet de faire appel, distance, des procdures Remote Procdure Call et de transporter sur des rseaux une logique applicative.

Comme ce choix a facilit la dfinition notamment des services web qui offrent la possibilit de relier, via le web, des composants logiciels htrognes. SOAP sappuie sur un protocole de transport (principalement le protocole HTTP mais aussi SMTP ou POP) ainsi que sur un langage de structuration des donnes envoyes sous forme de messages, le langage XML. Mais SOAP qui reprsente la mthode de communication privilgie pour les services web, nest pas gr par PHP, aussi, lquipe a d recourir un outil tiers pour ajouter la fonctionnalit SOAP.

55

Gestion du projet

Tableau 4 : Comparaison REST, XML-RPC et SOAP

XML-RPCNombre limit de type de donnes Plus simple implmenter Utilise des API RPC http + couche dabstraction Se base sur des mthodes Manque de prcisions Confusions sur certains aspects (support unicode notamment) Mots de passe transmis en clair -

SOAPGrand nombre de type de donnes Plus complexe implmenter Utilise des API RPC http + couche dabstraction Se base sur des mthodes -

RESTCommunication par requtes Get services Trs simples interroger Repose uniquement sur lutilisation dhttp, des URIs et dXML Se base sur les ressources existantes.

Pour rsoudre le problme de la gestion de SOAP, trois outils permettent d'ajouter la fonctionnalit SOAP PHP. Il sagit de NuSOAP, Pear SOAP et eZSoap NuSOAP : Avec nuSOAP, un codeur peut autoriser l'exploitation d'un service web existant en incluant le fichier webservice.php. Ensuite, pour utiliser rellement le service, il rfrencie le fichier WSDL en appelant la mthode distance. Pear SOAP : Avec Pear SOAP, un codeur peut autoriser l'exploitation d'un service web existant en incluant le fichier Client.php. Ensuite, pour utiliser rellement le service : 1 2 3 il cre le client SOAP, il spcifie les options pertinentes, il appelle la mthode distance.

Ces trois outils offrent tous un codage extrmement simple.

56

Gestion du projet

6.3

LA SOLUTION RETENUELcriture du client CodeX hors-ligne nous ayant t impose en langage Java, lquipe

MTM a nanmoins impos son point de vue sur le choix de la librairie SOAP utiliser. Il a alors t dcid de tirer la meilleur partie de la bibliothque NuSOAP car il sagit dun groupe de classes (distribue sous licence LGPL) conu pour grer des services Web en SOAP mai aussi pour crer en PHP de web service (bass sur SOAP). Lquipe a galement choisi ce groupe de classes pour deux autres raisons : Tous les langages modernes disposent de fonctionnalits leur permettant d'exploiter des services Web de type SOAP sans se soucier de la verbosit de leurs messages sortants et entrants. C'est d'ailleurs la raison pour laquelle cette technique a tant de succs vis--vis de REST : les outils sont disponibles, tandis que REST ncessite de mettre en place ses propres mthodes (mme si le protocole existe dj). Contrairement XML-RPC, SOAP est utilisable pour tous types de donnes

Laccs aux services web passe ncessairement par lutilisation des fichiers WSDL (Web Services Description Language), un langage de description de Web Services, au format XML. Et WSDL permet de sparer la description des fonctionnalits abstraites, offertes par un service, et les dtails concrets de cette description de service. De plus, des fonctionnalits telles que "comment" et "o" y sont proposes. Dcrivant les fonctionnalits abstraites d'un service ainsi que son architecture, WSDL dfinit, de manire indpendante du langage, l'ensemble des oprations et des messages qui peuvent tre transmis vers et depuis un service web. Le WSDL dcrit, en outre, quatre ensembles de donnes importants: information publiquement information de type de donne pour toutes les requtes de message et requtes de rponse information de liaison sur le protocole de transport utilis information d'adresse pour localiser le service spcifi d'interface dcrivant toutes les fonctions disponibles

57

Gestion du projet

WSDL est donc retenu pour constituer la pierre angulaire de l'difice Web Services, avec un langage commun pour dcrire les services et une plateforme pour intgrer automatiquement ces services. Mais pour que les fonctions des services web puissent tre utilisable au niveau du client, lquipe a fait appel l'utilitaire WSDL2Java. Ce choix devait faciliter ( partir de la description WSDL d'un service) la gnration des diffrentes classes et interfaces clientes ncessaires l'appel des services ct client et ainsi linteroprabilit entre des fonctions cres en langage PHP et le client JAVA. La figure ci-dessous montre les diffrentes interactions entre lapplication clientes et le Server CodeX qui communiquent grce aux APIs SOAP (ct Server) et aux Axis (ct Client) et par lintermdiaire des requtes SOAP permettant linteraction entre Client CodeX et Server CodeX.

Figure 11 : Schma de communication entre Client Java et Server CodeX

58

Gestion du projet

Aprs tude et validation par le responsable du projet, il a t dcid que le principe de fonctionnement de lapplication hors ligne devait intgrer trois niveaux : rcupration des donnes, utilisation des services Trackers et My Account en local et synchronisation des donnes avec le Server y compris la gestion des conflits ventuels.

59

Gestion du projet

1. La Rcupration des donnesIl sagit de permettre aux utilisateurs CodeX de se connecter via une interface qui reprend le mme style que les pages du site web de CodeX. Ce client Java doit permettre aux utilisateurs une fois authentifies de choisir, dune part, les projets et leurs diffrents Trackers, et dautre part, les services de CodeX qui leurs sont lis. Ainsi, cette rcupration doit faciliter la rcupration des donnes lies aux trackers et aux projets choisis par lutilisateur pour tre utiliss en local. Cependant, le souci de raliser un client java qui soit la fois portable et ncessitant le moins dinstallation latrale possible, imposait lquipe de renoncer linstallation dun moteur SGBD avec chaque client CodeX hors ligne. Par contre, il t dcid, par concensus, que les donnes rcupres en locale seraient stockes dans des fichiers de type XML. Et chacun des fichiers rcuprs devait alors reprsenter les donnes dune table de la base de donnes ncessaire pour lutilisation des services Trackers et My Account . De cette manire, aprs authentification, lutilisateur CodeX, peut par le biais du client CodeX hors ligne, procder aux choix des trackers et des projets quil souhaite rcuprer en local. Ceci engendrera la cration dune base de donnes locale incluant les seules donnes qui seront manipules par le client java. Et il est bien entendu que cette tche, qui ne peut tre effectu quen mode en ligne, se fera par le biais dAPIs SOAP, comme nous le dtaillerons en deuxime partie du prsent rapport.

2. Lutilisation des services Trackers et My Account en localLe client java permet donc dutiliser les services de CodeX sur une machine non connecte au Server de Xerox et les utilisateurs ont ainsi la possibilit dditer des donnes lies leur informations personnelles mais aussi leur projets, leur trackers et a leurs artifacts. Cependant il faut rappeler quun utilisateur a la possibilit de rcuprer les donnes lies aux services Tracker appartenant aux membres de son groupe tout en respectant scrupuleusement les droits lis aux donnes confidentielles. Pour cette raison, linterface du client java propose un client crit en java, portable sur toutes les machines du rseau et reprenant les interfaces web de CodeX. Au terme de cette tape, lapplication CodeX hors ligne doit tre utilisable sans aucune connexion ncessaire ni au Server CodeX ni internet. Ce cas dutilisation prsente linteraction entre les acteurs internes (XML BD & Soap APIs) et externes (CodeX user) du systme. Au moment de la cration dune nouvelle session, 60

Gestion du projet

lutilisateur choisit les projets et les services associs, le systme importe les donnes grce des appels Soap et stocke les informations dans XML BD.

61

Gestion du projet

3. Synchronisation des donnes avec le Server et gestion des conflitsComme la phase rcupration des donnes , cette partie ncessite galement que le client CodeX hors ligne soit connect au server. En effet cette tape essentielle de lapplication permet de procder la mise a jour des donnes rcupres avec les donnes du Server. Ainsi les donnes rcupres lies aux services Trackers ou My Account seront synchronises lors de cette tape avec les donnes locales rcupres et ventuellement modifies. Cest dans cette optique quil a fallu mettre en place une interface de gestion de conflits qui offre la possibilit, lutilisateur dsirant synchroniser ses donnes, de visualiser les ventuels conflits de donnes et de choisir les oprations effectuer. Trois types doprations (Merge, Mise jour force et Dni de mise jour) peuvent tre choisis pour chacun des types de donnes (artifact, fichiers attachs, dpendances, commentaires, informations utilisateurs, comptences, profil, etc.). Pour simplifier, dans le cas de donnes de type artifact, les trois oprations successives sont dcrites ci-aprs. - Le Merge permet, par exemple, de fusionner pour un artifact, les valeurs des champs modifis ct Server avec les modifications sur les champs ct Client tout en respectant la rgle qui veut quun artifact dont le mme champs a t modifi la fois ct client et ct Server ne peut subir de Merge. - La Mise a jour Force autorise notamment lutilisateur remplacer les valeurs des artifacts stockes sur la base de donne du Server par les artifacts modifies ct client. - Le Dni de Mise jour offre le choix de ne pas prendre en compte les modifications effectues sur un artifact (ou un autre type de donnes) lors de la mise jour. On note que si la synchronisation des donnes est ainsi effectue sur un certain nombre de donnes modifies et non pas sur lensemble des donnes rcupres, cest dans le souci daccrotre la rapidit de la synchronisation car seules les donnes ayant t modifies devront pouvoir tre synchronises avec les donnes du Server. Cela a t rendu possible grce la mise en place dun fichier de log destin enregistrer les diffrentes mises jour effectues pour chacune des sessions ouvertes sur CodeX. 62

Gestion du projet

Ainsi, un mme client java peut tre utilis par plusieurs clients diffrents et mme plusieurs fois par le mme utilisateur en fonctions du nombre de sessions quil aura ouvertes sur CodeX Server au moment de la rcupration des donnes. A chacune des sessions de cet utilisateur correspondra une sorte de base de donnes locale (sans SGBD) compose de fichiers XML destines stocker les donnes rcupres dans des structures XML.

Figure 12 : Les diffrentes tapes du fonctionnement de CodeX en mode hors ligne

63

Gestion du projet

6.4 DIAGRAMMES1.1.26Diagramme de Classes

Database +PROJECT_FILE : static final String = projects.xml -path : String -userName : String -session : Session -db : Database -listServices : List +getInstance () : Database +initDatabase (in _path : String, in _userName : String, in _session : Session , in _listServices : List ) : void +createStructure() : void +synchronize () : void import

CreateStructureMyAccount SynchronizeTrackers +USER_FILE : static final String = user.xml +PEOPLE _SKILL_INVENTORY_FILE : static final String = people_skill _inventory.xml +PEOPLE _SKILL_FILE : static final String = people_skill .xml +PEOPLE _SKILL_LEVEL_FILE : static final String +PEOPLE _SKILL_YEAR_FILE : static final String +TIMEZONES _FILE : static final String -user : User -userSkillInventory : UserSkill [] -peopleSkillBox : PeopleSkill [] -peopleSkillLevelBox : PeopleSkillLevel [] -peopleSkillYearBox : PeopleSkillYear [] import -timezoneBox : String[] -db : Database +CreateStructureMyAccount () +run() : void

import import

package genere avec WSDL 2Java

classes for mapping tracker tables to xml import

import

Tracker SOAP Client

Tracker Database

Account Database

Account SOAP Client

import classes for mapping account tables to xml package genere avec WSDL 2Java import

CreateStructureTrackers -MAX_ARTIFACT_IMPORT : static final int = 100 -ARTIFACT_GROUP_LIST_FILE : static final String = artifact_group_list .xml -ARTIFACT_REPORT_FILE : String = artifact_report.xml -DIFF_FILE : static final String = diff.xml -LOG_FILE : static final String = log.xml -artifactGroupList : ArtifactType [] -artifacts : Artifact[] -artifactReports : ArtifactReport[] -artifactCanneds : ArtifactCanned [] -db : Database -ARTIFACT_CANNED_RESPONSES _FILE : static final String = canned_responses.xml -ARTIFACT_FOLLOWUP _FILE : static finalString -ARTIFACT_FILE_FILE : static final String = artifact_file .xml -ARTIFACT_DEPENDENCIES _FILE : static final String = artifact_dependencies .xml -artifactFollowups : ArtifactFollowup [] -artifactFiles : ArtifactFile [] -artifactDependencies : ArtifactDependence [] +CreateStructureTrackers (in listOfArtifactTypes : List ) +run() : void SynchronizeMyAccount -user : User -userSkillInventory : UserSkill +SynchronizeMyAccount () +run() : void

64

Gestion du projet

Ce diagramme de classes se compose de 5 classes principales : Classe CreateStructureAccount : cette classe appel les diffrents APIs associs

au service My Account (Account Soap Client) et stocke les donnes rcupres dans des structures XML (Account Database). Classe CreateStructureTrackers : cette classe appel les diffrents APIs associs Trackers (Trackers Soap Client) et stocke les donnes rcupres dans des

au service

structures XML (Trackers Database). Classes SynchronizeMyAccount et SynchronizeTrackers : elles appellent

les APIs Soap pour synchroniser les donnes locales avec ceux du serveur. Classe Database : permet de crer la base de donnes, en lanant le thread

createStructureTrackers pour le service Trackers et/ou le thread createStructureAccount pour le service My Account.

Et des packages associs dfinis i dessous.

Package Account Database

65

Gestion du projet

Ce package contient les diffrentes classes qui reprsentent les fichiers XML manipules par le service Account .

66

Gestion du projet

Package Account Soap Client

Ce package est gnre avec lutilitaire WSDL2Java d Axis qui contient les diffrentes classes et interfaces clientes ncessaires l'appel du service MyAccount .

67

Gestion du projet

Package Tracker Database

Ce package contient les diffrentes classes qui reprsentent les fichiers XML manipules par le service Tracker .

68

Gestion du projet

Package Tracker Soap Client

Ce package est gnre avec lutilitaire WSDL2Java d Axis qui contient les diffrentes classes et interfaces clientes ncessaires l'appel du service Trackers . La classe ArtifactType reprsente loutil de suivi, qui gre plusieurs artifacts. 69

Gestion du projet

La classe Artifact contient les champs standards et les champs

dynamiques selon chaque type de tracker.

1.1.27Diagrammes de squences Crer Une session

La cration dune session ncessite lappel de lAPI SOAP login qui cre une session dans le serveur CodeX et retourne sa cl de session ainsi que lidentifiant de lutilisateur, sil existe sinon un message derreur est envoy. Si l'utilisateur veut crer une session, le systme lui demande de sauthentifier ainsi sil sagit dun utilisateur inconnu au systme, le systme se connecte au serveur et vrifie que le compte est valide ensuite il enregistre ces paramtres pour une authentification future. 70

Gestion du projet

Le systme demande lutilisateur de confirmer son mot de passe lors de la connexion au serveur cette confirmation est ncessaire dans le cas ou lutilisateur a chang son passe en utilisant linterface de CodeX (mode en ligne) Linterface de cration de session (ChoixTrackersProject) permet lutilisateur de choisir les projets auxquels il a droit et les outils de suivi associs, la rcupration des donnes passe par lintermdiaire de la mthode createStructure de lobjet Database qui fait appel aux web services et stocke les donnes dans des fichiers XML. mot de

71

Gestion du projet

Ouvrir Une session

Pour ouvrir une session, il est ncessaire que lutilisateur soit authentifi, si lutilisateur a plusieurs sessions le systme vrifie lintgrit des sessions et liste celles qui sont valides (OpenSession), ensuite elle se charge dinstancier lobjet Database qui tablit la communication entre le systme et les donnes (similaire JDBC Connection Pool Manager).

72

Gestion du projet

1.1.28Diagramme de dploiement

Partie cliente : Le systme utilise la librairie axis pour la communication SOAP avec le serveur CodeX Le module Database se charge de : Invoquer les web services pour importer et synchroniser les donnes. stocker les donnes dans des structures XML

Partie Serveur constitue principalement dun Serveur SOAP qui offre une gamme dAPI SOAP qui accdent aux donnes grce aux API CodeX.

73

Gestion du projet

6.5 LES MAQUETTES

Figure 13 : Configuration du serveur Soap A lutilisateur de spcifier le Hte du serveur ainsi que le port.

Figure 14 : Connexion Locale Cet cran permet un utilisateur

codex de sidentifier lapplication.

74

Gestion du projet

Figure 15 : Connexion au serveur CodeX

Cet cran permet un utilisateur codex de sidentifier auprs du serveur Codex.

Figure 16: Ouvrir une session Cet cran liste toutes les session existantes valides pour lutilisateur authentifi

75

Gestion du projet

Figure 17:

Mon Compte

Lors de la phase denregistrement, un certain nombre dinformations personnelles sont fournies. Le nom complet ainsi que le fuseau horaire peuvent tre modifies tous moment en accdant la linterface Mon compte . Comme on peut aussi modifier la langue de navigation dans lapplication.

76

Gestion du projet

Figure 18:

Mon profil de comptences

A partir de cette IHM User Skills , lutilisateur peut publier son CV sur CODEX et le modifier en cas de besoin. . 77

Gestion du projet

Figure 19:

Page daccueil de loutil de suivi

Cette interface reprsente la page daccueil de loutil de suivi, rcapitulant lensemble des trackers disponibles pour le projet choisi au dbut, cad au moment de la rcupration des donnes du serveur CodeX. Dans lexemple ci dessus, le projet charg est Loremplsum.

78

Gestion du projet

Figure 20:

cran de fonctionnalits dun outil de suivi Bugs

Aprs avoir slectionner loutil de suivi qui vous intresse (voir Figure 19 [page 67]), un certain nombre de fonctionnalits vous sont accessibles. Vous pouvez soumettre de nouveaux artefacts, les modifier, effectuer des recherches et naviguer dans la base artefacts. 79

Gestion du projet

Figure 21:

cran de fonctionnalits dun outil de suivi Bugs

Dans cette interface, lutilisateur peut rayonner vers dautres espaces de travail et dinformation de codex tel que les artefacts(bugs, taches)qui lui sont assigns ou qui a soumis. Vous pouvez ainsi trs facilement suivre lvolution des artefacts dont vous tes en charge dans vos projets ou ceux que vous avez soumis dautres projets. 80

Gestion du projet

type task

Figure 22:

un exemple dcran de soumission dartefact(ici de

Cet cran comporte toutes les informations concernant Lartefact task #7081 , quon peut modifier, ajouter ou supprimer : Soumettre des commentaires (voir Figure 23 [page 71]), 81

Gestion du projet

Ajouter ou supprimer des dpendances (voir Figure 24 [page 72]), Ajouter ou supprimer des fichiers attachs (voir Figure 23 [page 71]),

82

Gestion du projet

Figure 23: commentaires et de Fichiers attachs

partie dajout, de modification et de suppression de

83

Gestion du projet

Figure 24:

partie dajout ou de suppression de dpendances

84

Gestion du projet

Figure 25: cran de rcupration doutils de suivi du projet choisi Cette interface permet lutilisateur de rcuprer les outils de suivis choisis, pour modifier, ajouter ou supprimer ses donnes. consulter,

85

Gestion du projet

6.6 ETAT DAVANCEMENT (GANTT)

86

Gestion du projet

87

Gestion du projet

6.7 COURBE DAVANCEMENT

La courbe davancement ci dessus montre les carts entre la courbe davancement prvisionnelle et la courbe d avancement. En effet, lcart le plus important t enregistr dans la priode du 16/04 au 02/07. Il sexplique par le fait que, tant donn le peu de documentation et de spcifications sur CodeX, la mise en place des APIs a dur plus longtemps que prvu. Cependant, on constate que le regard a t rattrap ds le dbut du moi de juillet au moment ou dbute la partie ralisation des services My Account et Trackers .

88

Gestion du projet

7

TESTS ET CODAGES

89

Gestion du projet

7.1 TRAVAUX RALISS Jalon 1Ce jalon a consist mettre en place le Web Service correspondant au Service My Account de CodeX. Nous avons commenc par mettre en place le web service correspondant au Service My Account de CodeX en implmentant, cot serveur, les APIs SOAP. Une fois les fonctions de rcupration et de mise a jour des donnes mises en places, nous avons procd aux diffrents tests de vrification de la cohrences des donnes dune part et de la performance de la rcupration dautre part. Nous avons toutefois constat que lappel aux diffrentes fonctions des web services ainsi que la cration de la base de donnes locale pouvaient prendre un temps relativement long et que le Server MySQL de CodeX avait tendance a se bloquer notamment lorsquon invoque une requte pour la rcupration de plus de 5000 Artifacts.

Jalon 2Une fois les APIs du service My Account mise en place, il a fallut procder a la cration des interfaces du dit service. Lune des contraintes consistait devoir reproduire sur le client les mmes interfaces qui existent dj sur codeX. La rcupration des donnes entrane leur stockage dans des structures XML, pour chaque session ouverte sur CodeX. Ce service induit la rcupration et le stockage de donne tels que les informations utilisateurs, le profil et les comptences. On note toutefois que, pour le service My Account , les donnes rcupres ne sont fonction que de lutilisateur et ne dpendent donc pas du projet et des trackers slectionns pour la rcupration.

90

Gestion du projet

Jalon 3La mise en place du Web service correspondant au service tracker de CodeX sest rvl tre la plus difficile mettre en place. Cette API a permis la rcupration et la mise jour de toutes les donnes inhrentes au service Trackers de Codex en loccurrence : Les Artiacts , Les fichiers attachs un artiact, Les commentaires sur un artiact, Les dpendances entre artifacts. Les donnes rcupres sont celles en relation avec les Trackers tels que Les Artifact Types (les trackers), Les Artiact Report (visualisation des Artifact dun requte sur un ou plusieurs de ses champs), Les Artifact Canned Response .(reponses types un commentaire) tracker en fonction dune

Cependant, dans le cas du service Tracker les donnes rcupres dpendent des projets et des trackers slectionns par lutilisateur avant la rcupration.

Jalon 4

Le service Tracker deviens disponible sur le client CodeX et permet d afficher des reports (laffichage des artefact), dditer et de crer des artefacts en y ajoutant des fichiers, des commentaires ou des dpendances tout en respectant scrupuleusement les interfaces de CodeX. Il permet galement l affichage dartefact en fonction de requte d affichage sur les champs des artefacts. Le service Tracker permet galement une prise en charge des droits sur les champs des artefacts permettant d'afficher et/ou dditer ou non les champs concerns.

91

Gestion du projet

8

EVALUATION ASSESSMENT

92

Gestion du projet

8.1 EVALUATION DE LA GESTION DE PROJET

En cours dexcution du plan, Nous avons du examiner lexistant et vrifier que les objectifs du plan taient tenus, de mme que les chances. Nous avons galement procd a une vrification des risques identifis afin de savoir si ils reprsentent des problme potentiels ou si ils ont t finalement surestims. On appelle a Rex pour retour dexprience, ou tout simplement suivi davancement.

Outils

Pour savoir si on tient nos objectifs, on a eu besoin dinformations quantifies et danalyses de problmes rencontrs (pour en tirer les leons).

Analyse Causale- Au niveau technique : Support non disponible (rfrent technique). Sources dinformations disponibles. Evolution de lapplication par rapport au changement apports Codex

-

- Problme de capacit faire : Aucun problme.

-

Enseignement

- Technique : La forme et les composant dun bon Packaging des livrables. Se mettre la place de lutilisateur final pour mieux comprendre ces Prvoir dautres exigences qui pourront tre mises en cause au cours

-

exigences actuelles de la ralisation du projet. 93

Gestion du projet

- Relationnel : Savoir Convaincre son quipe de ses points de vue quand cest Etre lcoute des autres propositions.

-

ncessaire. - Gestion de projet: Ne pas perdre de vu lobjectif final pour ne pas se laisser perturber par Se remettre toujours en cause par rapport ce qui existe et ce qui a

-

des activits intermdiaires. t prvu.

Dcisions- Ct Client : Pas de changement au niveau de ces exigences. D1 : Continuer sur lamlioration de lapplication. D2 : Abandonner quelques choix techniques qui nennui pas la

-

qualit du produit.

Actions- Meeting, pour se mettre daccord sur les dcisions prises.

94

Gestion du projet

8.2 APPORTS DE LEQUIPELa diversit des travaux quon a pu mener (participation part entire dans la vie du projet Codex), le nombre de personnes quon a ctoy ainsi que lautonomie qui nous t donne ont contribu faire de ce stage une exprience enrichissante dun point de vue humain, mais aussi sur le plan professionnel. Il nous a fallut planifier efficacement notre travail (ralisation de plans) et faire un suivi des tches raliser (feuille Excel de Tracking). Les petits carts par rapport aux prvisions ont pu tre rapidement identifis, pour pouvoir y apporter des justifications et ainsi y remdier. La communication et le travail en quipe ont galement t des lments dcisifs la russite de ce projet. Il est indispensable de savoir intresser son interlocuteur tout en tant son coute. Chacun a ses propres proccupations et les collaborateurs nont pas forcment beaucoup de temps nous consacrer. Cest pourquoi il faut toujours veiller tre clair et concis dans ce que lon dit . Dautre part, nous avons pu collaborer et discuter avec bon nombre dingnieurs logiciel ( des professionnels du dveloppement, de smantique) afin daccumuler de nombreuses informations issues des secteurs avec lesquels on ntait pas particulirement familiariss. Bref, laccomplissement de ce stage nous a rsolument ouvert les yeux sur le mtier dingnieurs Informaticiens, quil soit ingnieur de qualit, de dveloppement ou nimporte quelle autre spcialit.

95

Gestion du projet

9

CONCLUSION

96

Gestion du projet

9 CONCLUSIONCest depuis ses dbuts sous le nom de Haloid Company, que Xerox a fait le choix dinvestir en permanence une part substantielle de ses recettes dans la recherche fondamentale et applique et beaucoup de technologies considres aujourd'hui comme videntes ont t conues ou amliores dans les centres Xerox. On comprend alors pourquoi aujourd'hui encore, Xerox est encore plus attach son investissement dans la recherche. Ces sept mois de stage nous ont permis de dcouvrir le fonctionnement du projet CodeX de lentreprise Xerox dans sa globalit tout en menant bien les diffrents travaux qui nous entaient confi. Ce fut pour nous une exprience trs formatrice et particulirement enrichissante autour de plusieurs ples. Nous avons eu loccasion de visualiser diffrents aspects de la fonction dingnieur logiciel, de raliser divers travaux axs vers la gestion de projet et ainsi contribuer la vie de lentreprise. A travers notre initiation au mode de relation issu dun projet de dveloppement, nous avons t amens affronter des problmes concrets, en nous remettant en question quand cela tait ncessaire, et en faisant preuve de diplomatie. Ecouter les autres, faire profiter de son savoir-faire sans limposer, entrent dans une dmarche de progrs. Tous ces aspects nous confortent dans lide de construire notre vie professionnelle autour du monde de linformatique et la qualit logicielle o des progrs reste faire pour changer les mentalits et ainsi amliorer continuellement les processus de dveloppement logiciel,

97

Annexes

ANNEXES

98

Annexes

SOMMAIRE DES ANNEXES

ANNEXE 1 : Dfinition ANNEXE 2 : Le Planning ANNEXE 3 : Les fiches de la gestion de projet Fiche de modification Fiche de tches Compte rendu de runion Fiche de validation du plan de qualit Fiche suiveuse de lvolution du Projet Fiche danomalie des tests dintgration ANNEXE 4 : Suivi davancement ANNEXE 5 : Rfrences R1 : Bibliographies R2 : Webographies

99

Annexes

A.1

DEFINITIONS Tout type ditems faisant lobjet dun suivi, il peut sagir de bugs, tches, fiches Dassistances, danomalies Elment ou rsultat mesurable, tangible et vrifiable, qui doit tre fournit pour achever un projet ou une partie de projet. Evnement majeur du projet. Evnement majeur du projet. Dates prvues pour la ralisation dactivit et latteinte de jalons Ensemble dactivits corrles ou interactives qui transforme des Elments dentre en lments de sortie.[ISO 9000 : 2000] La forme que doit respecter un dlivrable donn. outil de suivi dartefacts.

Artefacts Livrable Jalon Jalon Planning Processus Template Tracker

Work Breakdown Regroupement de tches qui organise et dfinit le primtre du Structure (WBS) projet. Chaque niveau de dcomposition dfinit de plus en plus Prcisment une partie du projet.

100

Annexes

A.2

LE PLANNING

101

Annexes

A.3.1 FICHE DE MODIFICATIONN FM : 5

Fiche de Modification- Modification propos par : - Description de la modification propose : Changement de LIHM du client : - Mettre un menu visible dans toutes les interfaces. - Motivations de la proposition et importance : - Les IHMs deviendrons plus ergonomiques. - la ma