Rapport Stage V2

Présentation de la société
SOMMAIRE
SOMMAIRE 1
FIGURE 1 : LES CENTRES DE RECHERCHE DE XEROX À TRAVERS LE MONDE 9 4
1 PRÉSENTATION 6
1.1 L’ENTREPRISE XEROX....................................................................................................8
1.1.1 Présentation de Xerox Corporation.....................................................................................8
1.1.2 Organisation interne.........................................................................................................10
1.1.3 Segmentation du marché.................................................................................................10
1.2 XEROX RESEARCH CENTER EUROPE.....................................................................................12
1.1.4 La SPD et l’équipe CodeX...............................................................................................13
1.2.1.1 Données clés...............................................................................................................14
1.2.1.2 Missions.......................................................................................................................14
1.1.5 La méthodologie SIGMA-PLUS et le système Scrum.....................................................15
2 LA MISSION
17
2.1 ORGANISATION...............................................................................................................18
2.2 LA FEUILLE DE ROUTE DE LA MISSION..................................................................................19
1.1.6 Les objectifs généraux ....................................................................................................19

1.1.7 Les étapes.........................................................................................................................19
3 GESTION DU PROJET
21
3.1 L’ENGAGEMENT DE QUALITÉ...............................................................................................22
1.1.8 La Capacité fonctionnelle des applications .......................................................................22
1.1.9 La Fiabilité (intégrité).........................................................................................................22
1.1.10 La facilité d’utilisation.......................................................................................................22
1.1.11 Le rendement et la disponibilité.......................................................................................22
1.1.12 La maintenabilité et la portabilité.....................................................................................23
3.2 LE CONTRÔLE DES RISQUES...............................................................................................24
1.1.13 Le processus de contrôle des risques.............................................................................24
1.1.14 Le mode de prévision des risques...................................................................................26
3.3 CONTRAINTES DE DÉVELOPPEMENT ET DE LIVRABLE...................................................................28
1.1.15 Les macro tâches...........................................................................................................28
1.1.16 Les jalons et livrables......................................................................................................31
Concernant les jalons et livrables associés, ont été retenus 4 niveaux de jalons:.....................31
3.4 PROCESSUS SUPPORT DE LA MISSION...................................................................................32
1.1.17 La gestion des modifications...........................................................................................32
1.1.18 La gestion de configuration.............................................................................................32
Il s’agit, ici, de reprendre la démarche de cette discipline de la gestion technique et
administrative destinée à :........................................................................................................................32
1.1.19 La gestion des risques.....................................................................................................32
1.1.20 La gestion des documents de suivi..................................................................................33
1
1.1.21 Les documents de procédure..........................................................................................33

Les documents techniques.....................................................................................................33
3.5 LIMITES DU PROJET..........................................................................................................35
1.1.22 Les interfaces..................................................................................................................35
1.1.23 Les contraintes techniques de l’application.....................................................................36
1.1.24 Les contraintes temporelles et de charge........................................................................36
1.1.25 Les contraintes organisationnelles..................................................................................37
4 ANALYSE
38
4.1 LES OBJECTIFS DE LA SOLUTION CODEX.................................................................................40
4.2 FONCTIONNALITÉS ET LIMITES DE LA PLATEFORME CODEX......................................................43
5 SPÉCIFICATION
46
5.1 ETUDE DES BESOINS........................................................................................................47
5.2 DIAGRAMME DE CAS D’UTILISATIONS (HAUT NIVEAU)..................................................................49
6 CONCEPTION
51
6.1 PROBLEMATIQUE....................................................................................................52
6.2 LES SOLUTIONS ETUDIEES..................................................................................................55
6.3 LA SOLUTION RETENUE......................................................................................................57
6.4 DIAGRAMMES.................................................................................................................64
1.1.26 Diagramme de Classes .............................................................................................64
1.1.27 Diagrammes de séquences.............................................................................................70
1.1.28 Diagramme de déploiement............................................................................................73
6.5 LES MAQUETTES..............................................................................................................74
......................................................................................................................................84
6.6 ETAT D’AVANCEMENT (GANTT)...........................................................................................86
6.7 COURBE D’AVANCEMENT....................................................................................................88
7 TESTS ET CODAGES
89
7.1 TRAVAUX RÉALISÉS..........................................................................................................90
Jalon 1.......................................................................................................................................90
Jalon 2.......................................................................................................................................90
Jalon 3.......................................................................................................................................91
Jalon 4.......................................................................................................................................91
8 EVALUATION « ASSESSMENT »
92
Outils.........................................................................................................................................93
Analyse Causale.......................................................................................................................93
Enseignement...........................................................................................................................93
Décisions...................................................................................................................................94
Actions.......................................................................................................................................94
2
9 CONCLUSION
96
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 RENDU DE REUNION.....................................................................................104
A.3.4 FICHE DE VALIDATION DU PLAN DE QUALITÉ ...............................................................105

A.3.5 FICHE SUIVEUSE DE L’ÉVOLUTION DU PROJET ......................................................106
A.3.6 FICHE D’ANOMALIE DES TESTS D’INTÉGRATION .............................................................107
A.4 SUIVI D’AVANCEMENT...................................................................................................108
R.1 BIBLIOGRAPHIE............................................................................................................109
R.2 WEBOGRAPHIE............................................................................................................110
3
TABLE DES FIGURES
FIGURE 1 : LES CENTRES DE RECHERCHE DE XEROX À TRAVERS LE MONDE 9

Figure 2 : Répartition géographique des revenus de Xerox (données 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 l’évaluation des risques………………………………………………...23
Figure 6 : Diagramme de PERT (Cheminement des macros tâches)……………………………….27
Figure 7 : Contrainte de vérification des droits……………………………………………………...31
Figure 8 : les 2 dimensions indispensables à une stratégie réussie de réutilisation………………….35
Figure 9 : Schémade la plateforme CodeX …………………………………………………………38
Figure 10 : Principe de Fonctionnement du mode hors ligne de CodeX…………………………….46
Figure 11 : Schéma de communication entre Client Java et Server CodeX…………………………50
Figure 12 : Les différentes étapes du fonctionnement de CodeX en mode hors ligne………………53
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 compétences……………………………………………………………..66
Figure 19: Page d’accueil de l’outil de suivi……………………………………………………….67
Figure 20: écran de fonctionnalités d’un outil de suivi « Bugs »…………………………………..68
Figure 22: un exemple d’écran de soumission d’artefact(ici de type « task »……………………...69
Figure 23: partie d’ajout, de modification et de suppression de commentaires et de
Fichiers attachés…………………………………………………………………………70
Figure 24: partie d’ajout ou de suppression de dépendances ……………………………………………..71
Figure 25: écran de récupération d’outils de suivi du projet choisi………………………………….73
4
Introduction
Pour mettre leurs produits et services sur le marché, de nombreux secteurs industriels
dépendent aujourd'hui de leurs activités internes et externes de développement logiciel.
Pourtant, de nombreuses entreprises reconnaissent que leurs activités de développement

logiciel sont fragmentées et dispersées sur les plans géographique et organisationnel. Les
équipes de projet sont souvent isolées les unes des autres et ignorent les synergies potentielles
à l'intérieur même de leur entreprise. La disparité des outils, des méthodes et des
infrastructures utilisées pénalisent aussi la productivité et engendre de nombreux coûts cachés.
Avec la forte pression pour fournir des produits innovants à un rythme toujours plus rapide, il
devient critique de résoudre ce type de problèmes. La plateforme CodeX du Centre de
recherche de Xerox de Meylan doit justement permettre de vaincre les obstacles qui empêchent
une utilisation efficace des logiciels et des ressources dans l'entreprise.
Cette plate-forme centralisée propose un grand nombre de services utiles au développement

d'un projet informatique: outils de suivi, systèmes de contrôle 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 d’y accéder sans
passer par le serveur central du XRCE.
C’est dans le cadre de la préparation du projet de deuxième année de spécialisation que

l’équipe de trois élèves ingénieurs stagiaires de l’Institut EERIE composée a été retenue par le
XRCE pour l’étude 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 préparation du présent rapport, le terme « projet » fait référence au cadre du projet
CodeX dans son ensemble tandis que le terme mission porte sur le travail à réaliser par l’équipe
EERIE, étant entendu que chacun des trois élèves ingénieurs en assume une partie ou tâche.
Cette approche globale justifie le choix de la présentation du rapport en huit parties

correspondant sensiblement au phasage de la mission d’étude qui sont:
1 -Présentation de l’organisation support du projet

2 -Gestion du projet
3 -Analyse de l’existant et spécification des besoins techniques
4 -Conception des solutions retenues, tests et codages
5 -Evaluation ou « assessment »
5
1 PRÉSENTATION
6
7
1.1 L’ENTREPRISE XEROX

1.1.1 Présentation de Xerox Corporation
Xerox, un des leaders mondiaux de la bureautique, offre, en plus de sa gamme de

produits et services classiques, des solutions destinées à améliorer la gestion des processus
documentaires utilisés quotidiennement par les entreprises et les organisations.
Xerox Corporation Fondée en 1948, Xerox Corporation, initialement marque déposée du groupe
Haloid Company spécialisé dans la xérographie, Xerox est devenu, après de nombreuses fusions
et acquisitions, un groupe international présent dans le monde entier avec un chiffre d‘affaires
de 20 milliards $ et 61000 employés répartis sur les cinq continents.
L’approche 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 coût et chaque entreprise cherche à augmenter son chiffre d'affaires
tout en réduisant les coûts et en améliorant la productivité. Or, d'après des expertises de
spécialistes du secteur, les coûts documentaires sont peu maîtrisés et encore moins mesurés.
Et globalement, ils estiment que ces coûts peuvent représenter, en moyenne, entre 5 et 15% du
chiffre d’affaires d'une entreprise. Ils estiment également qu’entre 17 et 25% de ces coûts
documentaires sont directement liés à la production documentaire.
On comprend qu’il soit difficile pour un grand nombre d’organisations de réunir des millions de
documents, de les numériser, de les regrouper, de les indexer pour permettre la recherche par
mots-clés, puis de les transférer en même temps vers différents emplacements et bases de
données pour qu'ils soient réorientés vers d'autres supports. Ainsi, entre autres solutions, Xerox
propose, pour le seul environnement de bureau, des réductions des coûts de gestion
documentaire d'au moins 25.
L’envergure de l’entreprise lui a permis de développer 5 centres de recherches et de

technologie s à travers le monde. 1500 personnes maintenant sont actuellement impliquées
dans le domaine de la recherche.
8
Figure 1 : Les centres de recherche de Xerox à travers le monde
Il s'agit d'une société internationale spécialisée 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 à
améliorer leurs processus de gestion; abaisser leurs coûts; écourter les délais d'exécution et
partager les informations à caractère critique.
Ces produits et services facilitent la transformation des informations imprimées en informations

numériques et vice versa. Ils rendent également plus aisés la visualisation, l'agencement et le
partage des informations en les présentant sous forme de documents numériques. Ils facilitent
aussi l'envoi intra réseau 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 facilités.
9
1.1.2 Organisation interne
Xerox comprend trois grands départements :
• le PSG (Production System Group) travaille sur l’impression des documents à grande
échelle et sur la conception des machines et des systèmes d’impression.
• le XOG (Xerox Office Groupe) est chargé des applications en réseau et des services
offerts aux bureaux et organisations administratives en matière de photocopieurs,
d’imprimantes, etc.
• le XGS (Xerox Global Services) fournit des services informatiques spécialisés aux
entreprises.
C’est de ce dernier département que relèvent les centres de recherche et laboratoires

Xerox, à l’origine d’innovations majeures comme les imprimantes laser couleur numériques
multifonctions, les copieurs et télécopieur et les workflow documentaires. Situés aux Etats-
Unis (3 centres), au Canada (1 centre) et en Europe (le XRCE de Meylan), les cinq centres de
recherche et développement connus de Xerox, emploient à eux seuls 1500 personnes dont de
nombreux doctorants et stagiaires.
C’est depuis ses débuts sous le nom de Haloid Company, que Xerox a fait le choix d’investir
en permanence une part substantielle de ses recettes dans la recherche fondamentale et
appliquée et beaucoup de technologies considérées aujourd'hui comme évidentes ont été
conçues ou améliorées 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 marché
Les principaux clients de Xerox sont des professionnels comme l’indique son fameux
slogan "Printing for Professional" mais les ménages occupent une place de plus en plus
importante dans le créneau des imprimantes et notamment des imprimantes multi-fonctions
(scanner, fax photocopieur). Sur le plan géographique, l’indique la figure 2 suivante, les
principales sources de revenus de Xerox sont l’Amérique (60%) et l’Europe (33%).
10
Figure 2 : Répartition géographique des revenus de Xerox (données 2005)
Position de Xerox sur le marché :
Avec plus de 5000 brevets déposés dans le monde, le groupe Xerox a acquis une
position dominante sur les marchés mondiaux en fournissant des produits et des services de
haute technologie, qui se distinguent non seulement par leur qualité, fiabilité, productivité,
robustesse et simplicité d’utilisation, mais aussi par leur respect de l’environnement.
11
1.2 XEROX RESEARCH CENTER EUROPE
Xerox Research Centre Europe mène les activités de recherche propres à Xerox en
Europe, en coordonnant recherche, ingénierie et le « Technologie Showroom », une
démonstration « vitrine » de la recherche Xerox pour les clients et forum d’échange.
Le centre développe aussi des relations avec la communauté scientifique Européenne, à travers
des projets collaboratifs et des partenariats. XRCE crée des technologies de gestion
documentaire innovantes pour soutenir la croissance dans les services concernés. La recherche
concerne le traitement de l’image et du texte, les structures de documents, l’étude et la
compréhension des pratiques en matière de travail.
12
1.1.4 La SPD et l’équipe CodeX
Les applications concrètes qui en découlent permettent de faciliter grandement la

gestion de l’information dans de multiples langues, l’apprentissage automatique, le traitement
d’images, l’ingénierie documentaire, la sociologie et l’ethnographie.
Le XRCE abrite également l’une des plus importantes entités du groupe, la SDP (Smart
Document Platform) qui, comme indiqué dans les figures 4 et 5 suivantes, dépend de la filiale
américaine du groupe et qui comprend trois composantes, la Plateforme d’accueil de
technologies (2 ingénieurs), le Categorizer (4 informaticiens) et le CodeX (7 ingénieurs).
Figure 3 : Organigramme de Xerox et positionnement du XRCE et de la SDP
13
1.2.1.1 Données clés
Effectifs : 4 membres permanents (3 ingénieurs Codex + 1 Chef d’équipe)
1.2.1.2 Missions
Au sein de la SPD, le projet CodeX (projet à part entière et cadre la mission de l’équipe
MTM) a pour principales missions :
• d’optimiser l’investissement logiciel des entreprises

• d’apporter le support nécessaire pour assurer le bon déploiement des services
au sein des projets de développement
• d’apporter une visibilité globale et une harmonisation des activités de
développement logiciel à l'échelle de l'entreprise, permettant ainsi d'éviter la
redondance des efforts et de capitaliser sur les investissements déjà réalisés
• de supprimer les coûts cachés importants liés à la maintenance de nombreux
outils et petits serveurs de groupes disparates
• de faciliter la constitution d'équipes de projet composées de membres
appartenant à des organisations voire à des sociétés différentes que ce soit en
sous-traitance ou en off-shore
• de développer la communication et le niveau d'information des équipes de
développement logiciel
• de réduire les coûts les délais de commercialisation des produits
Figure 4 : Composantes de la SDP
14
1.1.5 La méthodologie SIGMA-PLUS et le système Scrum
La méthodologie SIGMA-PLUS (Six Sigma et Lean Six Sigma) est utilisée par XRCE
comme méthode d’amélioration de la qualité reposant sur la maîtrise statistique des procédés
de traitement de l’information.
C’est aussi un mode de management qui repose sur une organisation très encadrée dédiée à la
conduite de projet. Cette méthode est aujourd'hui utilisée par de nombreuses entreprises, en
complément ou en remplacement des systèmes de management de la qualité suivant la norme
ISO9000.
En effet et plus particulièrement en ce qui concerne Six Sigma, la méthode est à même de
satisfaire les clients en réduisant la variabilité des processus de l’entreprise, ses coûts et ses
parts de marchés.
Par contre, le système Lean-Six-Sigma associe les méthodes qualitatives du Lean
Management et du Six Sigma pour améliorer de manière substantielle la performance
logistique de l'entreprise.
L'idée qui a donné son nom à la méthode est de répondre aux possibilités de non conformité de
part et d'autres de la moyenne de 3 écarts-types (les fameux 6 sigma) en maîtrisant ces causes
grâce à l'utilisation de tableau de bord tels que les KPI logistiques.
L'offre de SIGMA-PLUS se répartit selon trois branches:
• les études : dans les domaines de la simulation (phénomènes physiques, conception

système, analyse et contrôle de processus) et du traitement de l'information
• la diffusion de logiciels : les produits au catalogue de SIGMA PLUS relèvent du
datamining, de l’analyse statistique et de données, des réseaux de neurones, etc.
• la formation et le conseil. deux concepts étroitement liés du fait de la demande du
marché confronté à la puissance croissante des logiciels à leur disposition
Pour compléter les méthodes de développement proposées par SIX-SIGMA, Scrum, l’une des
sept méthodes agiles a été privilégiée. En rappelant qu’une méthode agile (cf. Annexe XX
relative aux Méthodes Agiles) est une méthode de développement informatique permettant de
concevoir des logiciels en impliquant au maximum le demandeur, il faut noter qu’il s’agit de
techniques plus pragmatiques que les techniques traditionnelles puisqu’elles visent la
satisfaction du besoin du client plus que la réalisation du contrat établi préalablement.
Ainsi, la Méthode Scrum, terme emprunté au rugby signifiant la mêlée, est orientée vers le
domaine du développement informatique de la gestion du travail.
15
Scrum est une méthode Agile pour la gestion de projets. Elle a été conçue pour améliorer
grandement la productivité dans les équipes souvent paralysées par des méthodologies 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-Fév 1986).
Son utilisation est prévue initialement pour la gestion de projets de développement, et

elle a été utilisée avec succès pour englober Extreme Programming et d'autres méthodes de
développement. Cependant, elle peut théoriquement s'appliquer à n'importe quel contexte où
un groupe de personnes ont besoin de travailler ensemble pour atteindre un but commun -
comme gérer une petite école, des projets de recherche scientifique ou planifier un mariage.
Bien que Scrum ait été conçue pour la gestion de projets de développement de logiciels,
elle peut être utilisée 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 ORGANISATION
Pour une meilleure visibilité du travail à effectuer, qui s’insère logiquement dans le projet
CodeX, les responsables de XRCE ont élaboré un cahier de charge dont le contenu permet
d’établir aussi bien les tâches à accomplir que les limites de la mission.
L’objectif de la mission est d’étudier les perspectives de mise en place d’un mode "hors-ligne"
(offline) qui permette d'utiliser un certain nombre de services de CodeX sans être connecté au
serveur. Comme cela sera détaillé dans la partie « Réalisation », l’exécution de la mission devait
logiquement passer par les étapes d’étude de la faisabilité du mode hors-ligne par service, de
mise en place des interfaces API nécessaires et de développement de l’application cliente
fonctionnant de manière autonome.
Aussi la démarche de développement des applications retenue a intégré, d’une part, la feuille de
route de la mission de l’équipe EERIE (objectifs et du projet et planning de travail), d’autre part,
l’engagement de qualité et, enfin, l’évaluation des risques.
18
Gestion du projet
2.2 LA FEUILLE DE ROUTE DE LA MISSION
On peut résumer la feuille de route de la mission confiée à l’équipe MTM à ses deux
aspects « objectifs généraux» et « étapes principales ».
1.1.6 Les objectifs généraux
Les objectifs généraux ont été répartis en six points :
• Etude globale du cahier des charges

• Etude des fonctions de CodeX online
• Définition des critères de choix des services à implémenter en offline
• Etude de solution pour la sauvegarde des données (fichiers, base de
données)..
• Conception des interfaces de manipulations pour CodeX offline
• Mise en place d’un système d’authentification des utilisateurs.
1.1.7 Les étapes
Les principales étapes prévues initialement ont été :
• La collecte et la validation des besoins : Une étape de préparation destinée

à:
- se familiariser avec l’environnement de CodeX
- étudier des documents et éléments disponibles pour préparer la
phase de formation avec un ingénieur CodeX
- analyser l’ensemble des services offerts par Codex on-line
- planifier le déroulement des interviews
• L’élaboration et la présentation du plan d’activité : Parallèlement à la

mission de détermination des besoins, un plan détaillé a été établi en vue de
l’élaboration et de la conception de l’application, une tâche complexe
particulièrement au niveau de la détermination des dates de livrable.
• L’implémentation de nouvelles API : Dans cette phase était proposée la

création de nouvelle API (Web services) pour permettre l’accès du client CodeX aux
données du Server CodeX.
19
Gestion du projet
• L’implémentation du client : Il s’agit de la réalisation d’un client portable en

java permettant l’utilisation de l’interface de CodeX en mode « déconnecte ».
• L’élaboration des supports de formation : A chaque étapes de réalisation,

des supports techniques doivent être livrés incluant certaines formations aux
utilisateurs selon leurs besoins
20
Gestion du projet
3 GESTION DU PROJET
21
Gestion du projet
3.1 L’ENGAGEMENT DE QUALITÉ

L’engagement de qualité porte sur la capacité de fonctionnement des
applications leur fiabilité, leur facilité d’utilisation, leur rendement et leurs maintenabilité
et portabilité.
1.1.8 La Capacité fonctionnelle des applications
- Leur Interopérabilité : CodeX client hors ligne utilise le protocole Soap pour
l’échange des données avec le serveur CodeX, et
- Leur Confidentialité : l’interface de connexion permettra que seuls les utilisateurs

codex aient le droit d’accès aux services de CodeX. A chaque appel d’APIs Soap par
le client, ce dernier envoie une clé de session qui doit être validé par le serveur
sinon un message d’erreur est envoyé au client.
1.1.9 La Fiabilité (intégrité)
- Leur Maturité et leur tolérance aux fautes : l'application développée étant privée, des
exigences en maturité et en tolérance aux fautes sont donc réclamées
- Les Possibilités de leur récupération : l’application à développer doit procéder à

une duplication de données à chaque récupération d’informations du serveur
- la Mesure de la qualité : mise en place d’un test surveillant l’enregistrement des

modifications et la récupération des données initiales en cas d’échec, avec une
détection automatique de manipulation incorrecte avant exécution.
1.1.10La facilité d’utilisation
- pour toutes interfaces : la facilité d’utilisation est exigée.

- pour CodeX en ligne : garder absolument les types de manipulation existants.
1.1.11Le rendement et la disponibilité
- Comportement vis-à-vis du temps : la récupération des données du serveur

CodeX est optimisée de telle sorte qu’il est possible d’afficher 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 données locale, les ressources doivent être partagées pour chaque service
sollicité par le client
1.1.12La maintenabilité et la portabilité
- Maintenabilité : le produit étant destiné à être commercialisé, les facilités

d'analyse, de modification, et de test sont essentielles pour qu'il puisse être utilisé
et amélioré 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 CONTRÔLE DES RISQUES

1.1.13Le processus de contrôle des risques
Le processus de contrôle des risques exige à la fois leur auto détection préalable, leur
réévaluation permanente et la prévision des nouveaux risques (figure 5 ci-après).
24
Gestion du projet
Figure 5 : Cheminement de l’évaluation des risques
25
Gestion du projet
1.1.14Le mode de prévision des risques
Tableau 1 : Mode de prévision des risques
Types de Causes Impacts Proba Niveau Actions Date Et

risques possibles Prévisibles bilité criticité envisagées cible at
1ères évaluations
1 Optimiste +
Evaluation Manque Retard, non respect 2 4 2 Normales + T
des d’expérience des délais (2) 1 Pessimiste Immédiat
délais
Validation avec A
le Responsable
du stage
Manque
Evaluation de d’expérience et Retard ou tâches Réévaluations et A partir du
la charge des spécifications inachevées (1) 2 4 adaptations en 01/03 T
tâches non encore cours de projet
commencées
Evaluation Manque Obligation de subir Validation avec A partir du A

des risques d’expérience ou les conséquences 2 6 le Responsable 01/03
imprévus risques oubliés sans les avoir du stage et des
prévues (3) réévaluations EC
régulières
Risques Insuffisance de Formation sur 16/02

techniques dus connaissances Retard ou produit les nouveaux et sur T
au non ou mauvaise inachevé (2) 2 4 outils toute
maîtrise des répartition des Répartition plus la durée du
outils tâches souple des projet EC
tâches
Communications
internes
importantes
Risque de Mauvaise Incompatibilité Structuration de Sur

mauvaise communication entre les 2 6 l’équipe, toute
coordination ou non applications distribution des la durée du T
entre formalisation développées par rôles, entraide, projet
membres l’équipe EMA- motivation et
l’équipe EERIE(3) responsabilisatio
n
26
Gestion du projet
Les critères et les ratios retenus pour leur évaluation sont :
- Impact : nul = 0, faible = 1, fort = 2, catastrophique = 3

- Probabilité : nulle = 0, < 10% = 1, > 10% = 2
- Criticité : Impact * Probabilité
- Etat : A (Attente), NC (Non Commencé), EC (En Cours), T (Terminé), V (Validée)
27
Gestion du projet
3.3 CONTRAINTES DE DÉVELOPPEMENT ET DE LIVRABLE
Les développements envisagés allaient tenir compte à la fois des macro tâches et
des jalons et livrables qui leur sont associés.
1.1.15 Les macro tâches
Compte tenu de l’indépendance qui existe entre les interfaces de publication et les APIs
(qui ont en seul point commun l’utilisation des WEB-Services), les deux processus de
développements peuvent être engagés, en parallèle, dans le cadre d’un « cycle de vie en V »
avec possibilité de parallélisme. Les macros tâches qui en résultent ainsi que leur cheminement
(figure 8) sont indiquées ci-après :
T01 : Réunion de lancement

T02 : Compréhension du sujet
T03 : Auto-formation technique (PHP, SOAP, WSDL, ……)
T04 : Rédaction de plan de qualité
T05 : Gestion de projet et suivi qualité
T06 : Spécification et conception des APIs du service « My Account »
T07 : Spécification et conception des IHMs du service « My Account »
T08 : Spécification et conception des APIs du service « Trackers »
T10 : Spécification et conception des IHMs du service « Trackers »
T11 : Réalisation de la fonctionnalité « Récupération des données »
T12 : Réalisation du service « My Account»
T13 : Réalisation du service « Trackers»
T14 : Réalisation de la fonctionnalité « Synchronisation des données »
T15 : Tests d'interaction interne et externe des fonctionnalités de CodeX Offline
T16 : Revue Finale
28
Gestion du projet
Auto-formation
Réunion de lancement Compréhension du sujet
technique
Début : 06/02/06 Début : 08/02/06
Début : 09/02/06
Fin : 07/02/06 Fin : 09/02/06
Fin : 20/02/06
Rédaction de plan de Spécification et conception des

Analyse du projet
qualité APIs du service « My Account »
Début : 14/02/06
Début : 15/02/06 Début : 21/03/06
Fin : 21/03/06
Fin : 24/02/06 Fin : 01/04/06
Spécification et conception Spécification et conception

des IHMs du service « My Spécification et conception des
des IHMs du service
Account » APIs du service « Trackers »
Début : 23/03/06 « Trackers »
Début : 01/04/06 Début : 18/04/06
Fin : 14/04/06 Fin : 21/04/06
Fin : 06/05/06
Réalisation du service « My
Account» Gestion de projet et suivi
Quantité Spécification et conception
Début : 20/02/06 des IHMs du service
Fin : 21/02/06 Début : 20/02/06
« Trackers »
Fin : 25/08/06
Début : 18/04/06
Fin : 06/05/06
Réalisation de la
fonctionnalité « Récupération
Réalisation du service «
des données »
Trackers»
Début : 08/05/06
Fin : 07/02/06 Début : 20/02/06
Fin : 21/02/06
Réalisation de la
fonctionnalité Tests d'interaction interne et
« Synchronisation des externe des fonctionnalités Revue Finale
de CodeX Offline
données » Début : 20/02/06
Début : 20/02/06 Fin : 21/02/06
Début : 20/02/06 Fin : 21/02/06
Fin : 21/02/06
Figure 6 : Diagramme de PERT (Cheminement des macros tâches)

29
Gestion du projet
30
Gestion du projet
1.1.16Les jalons et livrables
 Concernant les jalons et livrables

associés, ont été retenus 4 niveaux de jalons:
Jalon 1 : APIs Soap du service « Mon Compte ».
Jalon 2 : Développement Service Client « Mon Compte ».
Jalon 3 : API Soap du service « Trackers ».
Jalon 4 : Développement Service Client « Trackers ».
31
Gestion du projet
3.4 PROCESSUS SUPPORT DE LA MISSION

Le processus support du projet intègre la gestion des modifications éventuelles, des
configurations envisageables, des risques encourus, du support documentaire et des
délais.
1.1.17La gestion des modifications
On suppose, pour la gestion des modifications, que tout acteur du projet peut à tout
moment effectuer une demande de modification sous la forme d’une fiche modification
transmise au chef de projet qui effectue avec son auteur une étude d’impact 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 l’objet d’une fiche modification et
sont validées par le comité opérationnel ou le comité de pilotage.
Destinée à consigner les modifications apportées à un produit logiciel (code source, test,
document, etc.) et liée à un numéro attribué séquentiellement, la fiche de modification (cf.
modèle en Annexe XX) est destinée à collecter l’échange d’informations entre un demandeur et
un réalisateur, sur les actions à entreprendre à la suite d’un problème détecté. Cette fiche
informe, en outre, sur l’impact, le coût et les délais de réalisation.
1.1.18La gestion de configuration
Il s’agit, ici, de reprendre la démarche de cette discipline de la gestion technique et

administrative destinée à :
• Identifier et documenter les caractéristiques fonctionnelles et physiques d'un

article de configuration.
• Maîtriser les modifications de ces caractéristiques.
• Enregistrer et rendre compte du processus et de l'état des modifications.
• Procéder à des contrôles sur les articles de configuration afin de vérifier la
conformité aux exigences spécifiées.
1.1.19La gestion des risques
S’agissant de la gestion des risques, la méthodologie retenue consiste à examiner l'état du

projet, à identifier les risques qui menacent son bon déroulement et à entreprendre les actions
nécessaires pour leur réduction. Son processus se décompose en deux étapes :
32
Gestion du projet
• l'évaluation des risques : un processus qui permet d'identifier et de mesurer les

risques inhérents à un projet en s’accompagnant d’une identification basée sur
des faits connus et approuvés par tous.
• La maîtrise des risques : un processus qui permet la prise de conscience des

parties intéressées et la mise en œuvre des actions appropriées.
1.1.20La gestion des documents de suivi
La gestion des documents techniques et de procédure de suivi de la mission revêt une

importance capitale puisqu’elle conditionne sa réussite, en amont et en aval de la mission.
1.1.21Les documents de procédure
On distingue parmi les documents de procédure :

 le plan de qualité.
 le diagramme de Gantt.
 les courbes d’avancement
On suppose ici que pour chaque tâche, suivie à l’aide d’une fiche de tâche composée de
plusieurs champs d’informations (intitulé de la tâche, sa date de début et de fin prévues), on est
censée connaître à tout moment son état d’avancement. Cette fiche de tâche renseigne
également sur les dates de début et de fin réelles ainsi que les charges prévues, consommées
et restantes à engager. Ce type de suivi des tâches permet ainsi d’éviter les écarts par rapport
aux dates prévues réalisées.
Lorsqu’une tâche doit être modifiée, elle doit être renseignée par une fiche de modification de
tâche afin que ses principaux responsables comme tous les acteurs du projet soient au courant.
C‘est ainsi qu’une courbe d’avancement est établie régulièrement afin de mesurer
l’avancement global du projet.
Par ailleurs, un suivi au niveau du plan de qualité a été mis en place, lié à l’obligation de
validation de chaque document par le chef du projet après un cycle auteur/lecteur réalisé par
l’équipe de maîtrise d’œuvre. Celle-ci tient une réunion hebdomadaire avec les membres de
l’équipe afin de mesurer l’avancement global du projet mais aussi le niveau de réalisation des
tâches en cours de chacun des membres de l’équipe. Les comptes rendus de ces réunions sont
conservés en tant qu’enregistrement qualité.
Les documents techniques
33
Gestion du projet
Les documents techniques de réalisation sont de plusieurs niveaux de :
 Conception globale.
 Conception détaillée.
 Documentations liées au code source.
 Documentations liées aux tests
34
Gestion du projet
3.5 LIMITES DU PROJET

L’ensemble des documents techniques de la mission confiée à l’équipe MTM
s’insèrent dans le cadre d’une application globale « Portabilité de CodeX », aussi faut-t-il
garder à l’esprit 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 représente à la fois le point d’entrée depuis l’extérieur
vers la base de données de CodeX et le point de sortie vers l’extérieur.
1.1.22Les interfaces
Il faut aussi retenir que l’équipe est amenée à réaliser des interfaces donnant la
même visibilité à CodeX depuis l’extérieur, autrement dit, à prévoir les mêmes interfaces
que CodeX on-line, permettant aux utilisateurs autorisés l’affichage complet de ses projets
et les services qui y sont associés en mode hors ligne. Comme le montre la figure 9
suivante, on peut distinguer alors deux types d’utilisateurs potentiels :
• des utilisateurs non connectés au système qui peuvent visualiser les contenus
• des utilisateurs connectés au système qui, selon les droits attribués, peuvent ou
non éditer des contenus.
Vérification
des Droits
Codex
Figure 7 : Contrainte de vérification des droits
35
Gestion du projet
1.1.23Les contraintes techniques de l’application
On notera également que la mise au point des documents techniques est

subordonnée aux contraintes et exigences techniques précisées par le cahier de charges,
dont celles liées à :
• L’utilisation de l’environnement JDK 1.5.0

• L’environnement de développement intégré Eclipse 3.0.
• La Plateforme LAMP (Linux, Apache, MySQL, PHP) de Codex
• L’environnement de développement intégré Eclipse 3.0
• L’utilisation d’Axis 1.2 Apache comme moteur et API d’appel de Web Services
• Du JDOM en tant que parseur XML
• La bibliothèque Nusoap pour la mise en œuvre des API Soap
• L’outil de développement Collaboratif Codex
• L’outil de versionning « Subversion »
1.1.24Les contraintes temporelles et de charge
L’ensemble de la mission étalée sur une durée de sept mois (début février à fin août
2006) devait tenir compte, suite à l’étude des tâches et à la planification, à la fois de la charge
de travail estimée à 210 jours/homme pour l’ensemble du projet, autrement dit, 137 jours par
individu et des contraintes temporelles liées aux points de projet et aux revues.
Etant convenu qu’au cours du déroulement du projet, les responsabilités de chaque membres
de l’équipe pouvaient changer au cours de l’avancement des travaux, les plannings des
réunions « points de projet » et des revues ont été établis suite à plusieurs réunions de travail
formelles ou informelles.
En définitive, le planning suivant a été retenu.
36
Gestion du projet
Tableau 2 : Planning des points de projet et des revues
Points de projet Revues
- 15 Février 2006 - 15 Mars 2006 : Revue Qualité.

- 28 Février 2006
- 15 Mars 2006
- 30 Mars 2006 - 01 Avril 2006 : Spécification/Conception.
- 15 Avril 2006
- 30 Avril 2006
- 15 Mai 2006
- 30 Mai 2006
- 15 Juin 2006
- 15 Juillet 2006
- 30 Juillet 2006 - 01 Août 2006 : Revue Finale.
- 15 Août 2006
- 26 Août 2006
1.1.25Les contraintes organisationnelles
Enfin, l’organisation de la mission a inclus le volet de la communication qui a été

maintenue tout au long de la réalisation du projet sous deux formes :
 une communication interne entre les membres de l’équipe réalisée via

les mails, les réunions et leurs comptes rendus ainsi que les fiches suiveuses internes.
Pour une meilleure organisation interne, les comptes rendus des réunions devaient
suivre une procédure précise relative notamment à l’établissement de l’ordre du jour, la
date, le lieu, l’heure ainsi qu’à la désignation du président et du secrétaire, facilitant
ainsi la bonne planification des tâches respectives de chaque membre de l’équipe.
 une communication externe concernant principalement l’échange des flux

d’informations avec le représentant du maître d’ouvrage et responsable du stage. Cette
communication devait être réalisée par le biais des mails (portant essentiellement sur les
comptes rendus des réunions, sur les demandes d’informations, etc.), les réunions
(intergroupes, avec ou sans le représentant du maître d’ouvrage), les fiches suiveuses, les
fiches de modifications, les fiches des risques, les fiches planning réunion, les fiche de
validation du plan qualité, les fiche d’anomalies des tests d’intégrations 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 CODEX

La vocation première de la plateforme CodeX de développement collaboratif résidant
dans la réduction des coûts de l'entreprise, on comprend qu’il s’agit de sa compétitivité, voire
de sa survie dans un cadre mondial des échanges de plus en plus libérales.
En s'appuyant sur les succès obtenus grâce aux outils et aux méthodes de travail du domaine
Open Source, CodeX a privilégié deux dimensions indispensables au succès de la réutilisation de
logiciel, à savoir :
• Une infrastructure globale qui permet un partage et une réutilisation sans effort,
• Un changement dans les valeurs et la culture d'entreprise.
Figure 8 : les 2 dimensions indispensables à une stratégie réussie de réutilisation
Codex offre une large panoplie d'outils et de services destinés à améliorer la productivité et
d'écourter le délai de mise sur le marché des produits. Il permet également de:
• Apporter une visibilité globale et une harmonisation des activités de développement

logiciel à l'échelle de l'entreprise, permettant ainsi d'éviter la redondance des efforts
et de capitaliser sur les investissements déjà réalisés,
• Supprimer les coûts cachés importants liés à la maintenance de nombreux outils et
petits serveurs de groupes disparates,
40
Gestion du projet
• Faciliter la constitution d'équipes de projet composées de membres appartenant à

des organisations voir à des sociétés différentes que ce soit en sous-traitance ou en
off-shore,
• Améliorer la communication et le niveau d'information des équipes de
développement logiciel.
Rappelons qu’à l’origine, le site de Source Forge permettait aux utilisateurs du monde entier
d’éditer et d’utiliser des codes Open Source du fait de la licence GPL libre que l’entreprise
détenait. A partir de l’année 2000, CodeX a pu voir le jour en se basant sur SourceForge auquel
ont été apportés plusieurs améliorations et modifications, notamment aux niveaux de la
gestion des Trackers.
En 2001, quand SourceForge a décidé la fermeture de son site, un de ses développeurs reprit le
dernier code et l’appela Gforge tandis que SourceForge lança SFEE (en java) à destination des
entreprises.
Tableau 3 : Comparaison entre CodeX et Gforge
CodeX GForge
Bon outils de suivi Plus ouvert
Code invisible pour l’extérieur Code visible à l’extérieur
Les seuls contributeurs au code sont Grande contribution au code

l’équipe CodeX et ses clients
41
Gestion du projet
Parmi les clients de CodeX 1

(dont ST MicroElectronics et FranceTelecom ) figurent
des entreprises de différents secteurs de l'industrie mais en particulier de l’électronique et des
télécommunications qui apprécient l'expertise de Xerox dans le domaine de la réutilisation de
logiciel en entreprise (cf. url : http:\\CodeX.xerox.com).
Les clients payent souvent le prix fort pour pouvoir accéder aux services proposés par CodeX,
comme la correction des bugs, les possibilités offertes en matière d’ajout permanent de
nouvelles fonctions et la mise à dispositions de logiciels et de codes sources.
42
Gestion du projet
4.2 FONCTIONNALITÉS ET LIMITES DE LA PLATEFORME CODEX

L’éventail d'outils et de services dont les équipes de développement ont besoin
quotidiennement sont généralement :
• Les outils de gestion et de développement : système de contrôle de version,
publication de nouvelles versions, outil universel de suivi des défauts, des tâches,
des besoins, gestion des corrections et des contributions externes, intégration
avec vos environnements de développement favoris.
• L’espace projet à mettre en place et qui est totalement configurable : création
d’un nouvel environnement projet, choix des services à activer, gestion des
permissions d'accès aux membres des équipes (tous les services CodeX sont
disponibles à tout instant sur l'intranet de votre entreprise sans aucun coût de
déploiement).
• Les outils de communication et de gestion des connaissances : gestion de
documents, forums de discussion, listes de distribution et gestionnaire
d'annonces permettant aux équipes de développement de communiquer
efficacement sur leurs activités.
• Administration du projet : contrôle d'accès, audit des changements, accès au
projet, capacité avancée d’établissement de rapport à l'aide de fonctionnalités
d'exportation de données.
43
Gestion du projet
Figure 9 : Schéma de la plateforme CodeX
Aussi, pour répondre à ce type spécifique de besoins, CodeX a préféré s'appuyer sur des outils
et des technologies Open Source dont des millions d'utilisateurs ont apprécié les services
fiables.
Sur le plan technique, il faut préciser que :
• D’une part, CodeX reste une solution basée 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 délivrées par la plateforme Linux/Apache, leader actuel du
marché du web avec 62% de part de marché contre 30% seulement pour Microsoft.
• D’autre part, les données des projets sont prises en charge par le système de
gestion de bases de données MySQL connu pour ses performances et sa grande
stabilité.
• Enfin, CodeX s'installe sur toute machine équipée du système Red Hat Entreprise
Linux Server 3.0, un système d'exploitation totalement supporté, sûr et adapté aux
applications critiques.
Ainsi, si aujourd’hui 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 mêmes qualités font que la plateforme CodeX
convient aussi bien aux petites, moyennes ou grandes entreprises, d’autant plus qu’elle peut
servir aussi bien 10 que 10000 utilisateurs avec la même efficacité en termes de coût.
44
Gestion du projet
Cependant, la principale critique faite à la plate forme CodeX concerne à la fois l’impossibilité
d’accès au serveur depuis l’extérieur et l’absence de documentation sur les spécifications
techniques du projet, ce qui peut s’expliquer par des motifs de sécurité propres au groupe
Xerox, qui, par ailleurs, sont tout à fait compréhensibles.
45
Gestion du projet
5 SPÉCIFICATION
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 délai alloué au projet ne permet pas de traiter les besoins qui ne sont
pas essentiels :
Besoin fonctionnel 1 : L’utilisateur pourra se connecter au client CodeX en mode

« connecté » après authentification.
Besoin fonctionnel 2 : L’utilisateur pourra choisir de creer une nouvelle Session ou
d’ouvrir une Session existante.
Besoin fonctionnel 3 : Lorsqu’il ouvrira une Session, l’utilisateur devra choisir les
projets et pour chacun les Trackers qu’il souhaite récupérer.
Besoin fonctionnel 4 : Les Services Trackers et « My Account » de CodeX seront
utilisables par l’utilisateur en mode « déconnecté ».
Besoin fonctionnel 5 : L’interface de CodeX permettra a l’utilisateur d’éditer ou
d’ajouter des Méta – Données spécifiques a la conception de CodeX et qui sont :
Pour le service « Tracker » :
- Artéfacts
- Commentaires
- Fichiers attachés
- Dépendances
Pour le service « My Account» :
- Informations Utilisateur
- Compétences
- Profils
Besoin fonctionnel 6 : L’utilisateur peut, en mode « déconnecté » choisir de Supprimer
ou de Réinitialiser les données d’une Session existante.
Besoin fonctionnel 7 : L’utilisateur pourra, uniquement en mode « connecté », choisir
de Synchroniser les données d’une Session existante.
Besoin fonctionnel 8 : L’utilisateur pourra choisir les actions a accomplir pour la mise a
jour des données via l’interface de Gestion de Conflits.
47
Gestion du projet
• Besoins non fonctionnels :
Besoin non fonctionnel 1: Eviter qu’une panne du processeur n’affecte le

fonctionnement du Client CodeX.
Besoin non fonctionnel 2 : Protocole de transport http.
Besoin non fonctionnel 3 : Protocole d’échange SOAP.
Besoin non fonctionnel 4 : Vérifier la connectivité avec le Server.
Besoin non fonctionnel 5 : Structure XML de stockage de donnée.
48
Gestion du projet
5.2 DIAGRAMME DE CAS D’UTILISATIONS (HAUT NIVEAU)
System
«uses»
choisir les
services CodeX
«uses»
CodeX User
Authentification et
«uses»
gerer les sessions
«uses»
XML DB
«uses»
maintenir le compte «uses»

(Service Account
Maintenance )
«uses»
consulter et soumettre les

SOAP API
artefacts (Service Outil
de suivi )
«uses»
«uses»
invoquer les web services

et Creer la structure de «uses»
donnees «uses»
repliquer les donnees

et resoudre les conflits
49
Gestion du projet
Ce cas d’utilisation présente l’interaction entre les acteurs internes (XML BD & Soap APIs) et
externes (CodeX user) du système. Au moment de la création d’une nouvelle session,
l’utilisateur choisit les projets et les services associés, le système importe les données grâce à
des appels Soap et stocke les informations dans Base de données XML.
50
Gestion du projet
6 CONCEPTION
51
Gestion du projet
6.1 PROBLEMATIQUE
Les services offerts par CodeX dépendent de l’infrastructure globale sur laquelle
s'appuie la totalité de la communauté du développement logiciel de Xerox. Des services
comme My Account, Wiki, Subversion, CVS, Trackers, etc., font partie intégrante de cette
infrastructure.
Par ailleurs, le cahier de charge, établi pour la mission de développement de l’application

« Hors Ligne », a imposé à l’équipe de projet la nécessité d’utilisation du service le plus
important offert par CodeX, en l’occurrence, le Service Trackers.
Les trackers (ou outils de suivi au sens CodeX) désignent des structures complexes
représentées dans la base de données telles que les champs à utiliser et leurs valeurs
autorisées. Ils permettent d’assurer le suivi d’artifacts variées tels que des bugs, des tâches,
des fiches d’assistance, etc.
Un projet peut créer autant de trackers que nécessaire.
Ces structures de données dépendent nécessairement les unes des autres car chaque
artifacts est généré à partir d’un tracker qui, de son côté, permet de créer plusieurs
artifacts.
Par le biais de la plate-forme CodeX dite « en ligne », les utilisateurs ont la possibilité de
gérer leurs artifacts, leurs trackers, leurs projets et données personnelles, leurs outils de
suivi et systèmes de contrôle 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 matière de sécurité

puisqu’il incluait la contrainte impérative de n’autoriser 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.
Après analyse, l’équipe a constaté que la mise en place d’une application hors ligne n’avait
pas lieu d’être pour certains services proposés par CodeX, comme Wiki, Doc Man, CVS, et a
conclu avec le maître d’ouvrage à la nécessité de consacrer l’application 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 d’une application CodeX en mode hors ligne passe par la nécessite 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 requêtes http utilisées par les sites web
classiques.
En mode « en ligne », les utilisateurs peuvent visualiser par leurs navigateurs les pages web de
CodeX et ainsi accéder a ses différents services.
CodeX est aussi composé d’un Server Web Apache, d’un Server MySQL et d’une base de
données. Cependant, l’utilisation de la version « hors ligne » de CodeX se fera par biais de
requêtes SOAP rendues possible par le développement de web services cote serveur (API SOAP)
et de certains apis côté client (API AXIS).
53
Gestion du projet
54
Gestion du projet
6.2 LES SOLUTIONS ETUDIEES
Aujourd’hui, le Server CodeX est constitué d’un ensemble d’interfaces (APIs) définissant
des fonctions permettant d’accéder à la base de données. Aussi, l’une des phases importantes
de la mission a été celle de la création de web services permettant au client java de manipuler
les données de la base. Pour ce faire, un examen comparatif (cf tableau 4 suivant) de trois
différents types de Web services (REST, XML-RPC et SOAP) a été réalisée permettant de tirer les
constatations suivantes :
• REST : est une architecture de services Web, à la manière de SOAP et de XML-RPC.

Mais il s’agit seulement d’un style d'architecture, pas d’un standard et il n'existe
donc pas de spécifications de REST. Il faut d’abord 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 d’échange de messages

XML ayant pour vocation d’appeler des méthodes à distance, à travers un réseau.
C’est un protocole simple qui fonctionne par appel de procédures paramétrées au
formalisme XML mais qu’il n’est utilisable que pour un nombre limité de types de
données.
• SOAP : offre, malgré le fait qu’il soit plus complexe à implémenter, la possibilité
d’utiliser un grand nombre de types de données ainsi que des API RPC, ce qui a
orienté le maître d’ouvrage vers le choix de ce protocole qui permet de faire appel,
à distance, à des procédures Remote Procédure Call et de transporter sur des
réseaux une logique applicative.
Comme ce choix a facilité la définition notamment des services web qui offrent la possibilité de
relier, via le web, des composants logiciels hétérogènes. SOAP s’appuie sur un protocole de
transport (principalement le protocole HTTP mais aussi SMTP ou POP) ainsi que sur un langage
de structuration des données envoyées sous forme de messages, le langage XML.
Mais SOAP qui représente la méthode de communication privilégiée pour les services web, n’est
pas géré par PHP, aussi, l’équipe a dû recourir à un outil tiers pour ajouter la fonctionnalité
SOAP.
55
Gestion du projet
Tableau 4 : Comparaison REST, XML-RPC et SOAP
XML-RPC SOAP REST
- Nombre limité de type - Grand nombre de type - Communication par

de données de données requêtes Get services
- Plus simple à - Plus complexe à - Très simples à
implémenter implémenter interroger
- Utilise des API RPC - Utilise des API RPC - Repose uniquement sur
- http + couche - http + couche l’utilisation d’http, des
d’abstraction d’abstraction URIs et d’XML
- Se base sur des - Se base sur des - Se base sur les
méthodes méthodes ressources existantes.
- Manque de précisions
- Confusions sur certains
aspects
(support unicode
notamment)
- Mots de passe
transmis en clair
Pour résoudre le problème de la gestion de SOAP, trois outils permettent d'ajouter la

fonctionnalité SOAP à PHP. Il s’agit 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 réellement le service,
il référencie le fichier WSDL en appelant la méthode à 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 réellement le service :
1 il crée le client SOAP,

2 il spécifie les options pertinentes,
3 il appelle la méthode à distance.
Ces trois outils offrent tous un codage extrêmement simple.
56
Gestion du projet
6.3 LA SOLUTION RETENUE
L’écriture du client CodeX hors-ligne nous ayant été imposée en langage Java, l’équipe
MTM a néanmoins imposé son point de vue sur le choix de la librairie SOAP à utiliser. Il a alors
été décidé de tirer la meilleur partie de la bibliothèque NuSOAP car il s’agit d’un groupe de
classes (distribuée sous licence LGPL) conçu pour gérer des services Web en SOAP mai aussi
pour créer en PHP de web service (basés sur SOAP).
L’équipe a également choisi ce groupe de classes pour deux autres raisons :
• Tous les langages modernes disposent de fonctionnalités 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 succès vis-à-vis de REST : les outils sont disponibles,
tandis que REST nécessite de mettre en place ses propres méthodes (même si
le protocole existe déjà).
• Contrairement à XML-RPC, SOAP est utilisable pour tous types de données
L’accès aux services web passe nécessairement par l’utilisation des fichiers WSDL (Web
Services Description Language), un langage de description de Web Services, au format XML. Et
WSDL permet de séparer la description des fonctionnalités abstraites, offertes par un service, et
les détails concrets de cette description de service. De plus, des fonctionnalités telles que
"comment" et "où" y sont proposées.
Décrivant les fonctionnalités abstraites d'un service ainsi que son architecture, WSDL définit, de
manière indépendante du langage, l'ensemble des opérations et des messages qui peuvent être
transmis vers et depuis un service web. Le WSDL décrit, en outre, quatre ensembles de données
importants:
• information d'interface décrivant toutes les fonctions disponibles

publiquement
• information de type de donnée pour toutes les requêtes de message et
requêtes de réponse
• information de liaison sur le protocole de transport utilisé
• information d'adresse pour localiser le service spécifié
57
Gestion du projet
WSDL est donc retenu pour constituer la pierre angulaire de l'édifice Web Services, avec un
langage commun pour décrire les services et une plateforme pour intégrer automatiquement ces
services.
Mais pour que les fonctions des services web puissent être utilisable au niveau du client, l’équipe
a fait appel à l'utilitaire WSDL2Java. Ce choix devait faciliter (à partir de la description WSDL d'un
service) la génération des différentes classes et interfaces clientes nécessaires à l'appel des
services côté client et ainsi l’interopérabilité entre des fonctions créées en langage PHP et le
client JAVA.
La figure ci-dessous montre les différentes interactions entre l’application clientes et le Server
CodeX qui communiquent grâce aux APIs SOAP (côté Server) et aux Axis (côté Client) et par
l’intermédiaire des requêtes SOAP permettant l’interaction entre Client CodeX et Server CodeX.
Figure 11 : Schéma de communication entre Client Java et Server CodeX
58
Gestion du projet
Après étude et validation par le responsable du projet, il a été décidé que le principe de
fonctionnement de l’application hors ligne devait intégrer trois niveaux : récupération des
données, utilisation des services Trackers et My Account en local et synchronisation des données
avec le Server y compris la gestion des conflits éventuels.
59
Gestion du projet
1. La Récupération des données
Il s’agit de permettre aux utilisateurs CodeX de se connecter via une interface qui reprend
le même style que les pages du site web de CodeX. Ce « client Java » doit permettre aux
utilisateurs une fois authentifiées de choisir, d’une part, les projets et leurs différents Trackers, et
d’autre part, les services de CodeX qui leurs sont liés.
Ainsi, cette récupération doit faciliter la récupération des données liées aux trackers et aux
projets choisis par l’utilisateur pour être utilisés en local.
Cependant, le souci de réaliser un client java qui soit à la fois portable et nécessitant le moins
d’installation latérale possible, imposait à l’équipe de renoncer à l’installation d’un moteur SGBD
avec chaque client CodeX hors ligne. Par contre, il été décidé, par concensus, que les données
récupérées en locale seraient stockées dans des fichiers de type XML. Et chacun des fichiers
récupérés devait alors représenter les données d’une table de la base de données nécessaire
pour l’utilisation des services « Trackers » et « My Account ».
De cette manière, après authentification, l’utilisateur CodeX, peut par le biais du client CodeX
hors ligne, procéder aux choix des trackers et des projets qu’il souhaite récupérer en local. Ceci
engendrera la création d’une base de données locale incluant les seules données qui seront
manipulées par le client java. Et il est bien entendu que cette tâche, qui ne peut être effectué
qu’en mode en ligne, se fera par le biais d’APIs SOAP, comme nous le détaillerons en deuxième
partie du présent rapport.
2. L’utilisation des services Trackers et My Account en local
Le client java permet donc d’utiliser les services de CodeX sur une machine non
connectée au Server de Xerox et les utilisateurs ont ainsi la possibilité d’éditer des données liées
à leur informations personnelles mais aussi à leur projets, à leur trackers et a leurs artifacts.
Cependant il faut rappeler qu’un utilisateur a la possibilité de récupérer les données liées aux
services Tracker appartenant aux membres de son groupe tout en respectant scrupuleusement
les droits liés aux données confidentielles. Pour cette raison, l’interface du client java propose un
client écrit en java, portable sur toutes les machines du réseau et reprenant les interfaces web
de CodeX. Au terme de cette étape, l’application CodeX hors ligne doit être utilisable sans
aucune connexion nécessaire ni au Server CodeX ni à internet.
Ce cas d’utilisation présente l’interaction entre les acteurs internes (XML BD & Soap APIs) et
externes (CodeX user) du système. Au moment de la création d’une nouvelle session,
60
Gestion du projet
l’utilisateur choisit les projets et les services associés, le système importe les données grâce à
des appels Soap et stocke les informations dans XML BD.
61
Gestion du projet
3. Synchronisation des données avec le Server et gestion des

conflits
Comme la phase « récupération des données », cette partie nécessite également que le
client CodeX hors ligne soit connecté au server. En effet cette étape essentielle de l’application
permet de procéder à la mise a jour des données récupérées avec les données du Server.
Ainsi les données récupérées liées aux services « Trackers » ou « My Account » seront
synchronisées lors de cette étape avec les données locales récupérées et éventuellement
modifiées. C’est dans cette optique qu’il a fallu mettre en place une interface de gestion de
conflits qui offre la possibilité, à l’utilisateur désirant synchroniser ses données, de visualiser les
éventuels conflits de données et de choisir les opérations à effectuer.
Trois types d’opérations (Merge, Mise çà jour forcée et Déni de mise à jour) peuvent être choisis
pour chacun des types de données (artifact, fichiers attachés, dépendances, commentaires,
informations utilisateurs, compétences, profil, etc.). Pour simplifier, dans le cas de données de
type artifact, les trois opérations successives sont décrites ci-après.
- Le Merge permet, par exemple, de fusionner pour un artifact, les valeurs des
champs modifiés côté Server avec les modifications sur les champs côté Client tout en
respectant la règle qui veut qu’un artifact dont le même champs a été modifié à la fois
côté client et côté Server ne peut subir de Merge.
- La Mise a jour Forcée autorise notamment l’utilisateur à remplacer les valeurs des
artifacts stockées sur la base de donnée du Server par les artifacts modifiées côté
client.
- Le Déni de Mise à jour offre le choix de ne pas prendre en compte les

modifications effectuées sur un artifact (ou un autre type de données) lors de la mise
à jour.
On note que si la synchronisation des données est ainsi effectuée sur un certain nombre de
données modifiées et non pas sur l’ensemble des données récupérées, c’est dans le souci
d’accroître la rapidité de la synchronisation car seules les données ayant été modifiées devront
pouvoir être synchronisées avec les données du Server.
Cela a été rendu possible grâce à la mise en place d’un fichier de log destiné à enregistrer les
différentes mises à jour effectuées pour chacune des sessions ouvertes sur CodeX.
62
Gestion du projet
Ainsi, un même client java peut être utilisé par plusieurs clients différents et même plusieurs fois
par le même utilisateur en fonctions du nombre de sessions qu’il aura ouvertes sur CodeX Server
au moment de la récupération des données.
A chacune des sessions de cet utilisateur correspondra une sorte de base de données locale
(sans SGBD) composée de fichiers XML destinées à stocker les données récupérées dans des
structures XML.
Figure 12 : Les différentes étapes du fonctionnement de CodeX en mode hors

ligne
63
Gestion du projet
6.4 DIAGRAMMES
1.1.26Diagramme de Classes
Database
+PROJECT_FILE : static final String = projects.xml
-path : String
-userName : String
-session : Session
-db : Database
-listServices : List<Integer >
+getInstance () : Database
+initDatabase (in _path : String, in _userName : String, in _session : Session , in _listServices : List <Integer>) : 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
«import» +CreateStructureMyAccount ()
«import» +run() : void
package genere avec WSDL 2Java classes for mapping tracker tables to xml
«import» «import»
Account Account
Tracker SOAP Client Tracker Database
Database 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 SynchronizeMyAccount
-DIFF_FILE : static final String = diff.xml -user : User
-LOG_FILE : static final String = log.xml -userSkillInventory : UserSkill
-artifactGroupList : ArtifactType [] +SynchronizeMyAccount ()
-artifacts : Artifact[] +run() : void
-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 [] 64
-artifactFiles : ArtifactFile []
-artifactDependencies : ArtifactDependence []
+CreateStructureTrackers (in listOfArtifactTypes : List <ArtifactType >)
+run() : void
Gestion du projet
Ce diagramme de classes se compose de 5 classes principales :
 Classe « CreateStructureAccount » : cette classe appel les différents APIs associés

au service My Account (Account Soap Client) et stocke les données récupérées dans des
structures XML (Account Database).
 Classe « CreateStructureTrackers » : cette classe appel les différents APIs associés

au service Trackers (Trackers Soap Client) et stocke les données récupérées dans des
structures XML (Trackers Database).
 Classes « SynchronizeMyAccount » et « SynchronizeTrackers » : elles appellent

les APIs Soap pour synchroniser les données locales avec ceux du serveur.
 Classe « Database » : permet de créer la base de données, en lançant le thread

« createStructureTrackers » pour le service Trackers et/ou le thread « createStructureAccount »
pour le service My Account.
Et des packages associés définis çi dessous.
• Package « Account Database »
65
Gestion du projet
Ce package contient les différentes classes qui représentent les fichiers XML manipules par le
service « Account ».
66
Gestion du projet
• Package « Account Soap Client »
Ce package est génère avec l’utilitaire WSDL2Java d’ Axis qui contient les différentes classes et
interfaces clientes nécessaires à l'appel du service « MyAccount ».
67
Gestion du projet
• Package « Tracker Database »
Ce package contient les différentes classes qui représentent les fichiers XML manipules par le
service « Tracker ».
68
Gestion du projet
• Package « Tracker Soap Client»
Ce package est génère avec l’utilitaire WSDL2Java d’ Axis qui contient les différentes classes et
interfaces clientes nécessaires à l'appel du service « Trackers ».
• La classe « ArtifactType » représente l’outil de suivi, qui gère
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 séquences
 Créer Une session
La création d’une session nécessite l’appel de l’API SOAP « login » qui crée une
session dans le serveur CodeX et retourne sa clé de session ainsi que l’identifiant
de l’utilisateur, s’il existe sinon un message d’erreur est envoyé.
Si l'utilisateur veut créer une session, le système lui demande de s’authentifier ainsi s’il s’agit
d’un utilisateur inconnu au système, le système se connecte au serveur et vérifie que le compte
est valide ensuite il enregistre ces paramètres pour une authentification future.
70
Gestion du projet
Le système demande à l’utilisateur de confirmer son mot de passe lors de la connexion au

serveur cette confirmation est nécessaire dans le cas ou l’utilisateur a changé son mot de
passe en utilisant l’interface de CodeX (mode en ligne)
L’interface de création de session (ChoixTrackersProject) permet à l’utilisateur de
choisir les projets auxquels il a droit et les outils de suivi associés, la récupération
des données passe par l’intermédiaire de la méthode « createStructure » de
l’objet « Database » qui fait appel aux web services et stocke les données dans
des fichiers XML.
71
Gestion du projet
 Ouvrir Une session
Pour ouvrir une session, il est nécessaire que l’utilisateur soit authentifié, si l’utilisateur a
plusieurs sessions le système vérifie l’intégrité des sessions et liste celles qui sont valides
(OpenSession), ensuite elle se charge d’instancier l’objet « Database » qui établit la
communication entre le système et les données (similaire à JDBC Connection Pool Manager).
72
Gestion du projet
1.1.28Diagramme de déploiement
Partie cliente :
Le système 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 données.
• stocker les données dans des structures XML
Partie Serveur constitue principalement d’un Serveur SOAP qui offre une gamme d’API SOAP qui
accèdent aux données grâce aux API CodeX.
73
Gestion du projet
6.5 LES MAQUETTES
Figure 13 : Configuration du
serveur Soap
A l’utilisateur de spécifier le Hôte

du serveur ainsi que le port.
Figure 14 : Connexion Locale
Cet écran permet à un utilisateur

codex de s’identifier à l’application.
74
Gestion du projet
Figure 15 : Connexion
au serveur CodeX
Cet écran permet à un

utilisateur codex de s’identifier
auprès du serveur Codex.
Figure 16: Ouvrir une

session
Cet écran liste toutes les

session existantes valides
pour l’utilisateur authentifié
75
Gestion du projet
Figure 17: Mon Compte
Lors de la phase d’enregistrement, un certain nombre d’informations personnelles sont fournies.

Le nom complet ainsi que le fuseau horaire peuvent être modifiées à tous moment en accédant à la
l’interface
« Mon compte ».
Comme on peut aussi modifier la langue de navigation dans l’application.
76
Gestion du projet
Figure 18: Mon profil de compétences
A partir de cette IHM « User Skills », l’utilisateur peut publier son CV sur CODEX et le modifier en cas
de besoin.
.
77
Gestion du projet
Figure 19: Page d’accueil de l’outil de suivi
Cette interface représente la page d’accueil de l’outil de suivi, récapitulant l’ensemble des
trackers disponibles pour le projet choisi au début, cad au moment de la récupération des données
du serveur CodeX.
Dans l’exemple ci dessus, le projet chargé est « Loremplsum».
78
Gestion du projet
Figure 20: écran de fonctionnalités d’un outil de suivi « Bugs »
Après avoir sélectionner l’outil de suivi qui vous intéresse (voir Figure 19 [page 67]), un certain
nombre de fonctionnalités 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 fonctionnalités d’un outil de suivi « Bugs »
Dans cette interface, l’utilisateur peut rayonner vers d’autres espaces de travail et d’information
de codex tel que les artefacts(bugs, taches…)qui lui sont assignés ou qui a soumis. Vous pouvez ainsi
très facilement suivre l’évolution des artefacts dont vous êtes en charge dans vos projets ou ceux que
vous avez soumis à d’autres projets.
80
Gestion du projet
Figure 22: un exemple d’écran de soumission d’artefact(ici de

type « task »
Cet écran comporte toutes les informations concernant L’artefact « task #7081 », qu’on peut
modifier, ajouter ou supprimer :
• Soumettre des commentaires (voir Figure 23 [page 71]),
81
Gestion du projet
• Ajouter ou supprimer des dépendances (voir Figure 24 [page 72]),

• Ajouter ou supprimer des fichiers attachés (voir Figure 23 [page 71]),
82
Gestion du projet
Figure 23: partie d’ajout, de modification et de suppression de

commentaires et de
Fichiers attachés
83
Gestion du projet
Figure 24: partie d’ajout ou de suppression de dépendances
84
Gestion du projet
Figure 25: écran de récupération d’outils de suivi du projet choisi
Cette interface permet à l’utilisateur de récupérer les outils de suivis choisis, pour consulter,
modifier, ajouter ou supprimer ses données.
85
Gestion du projet
6.6 ETAT D’AVANCEMENT (GANTT)
86
Gestion du projet
87
Gestion du projet
6.7 COURBE D’AVANCEMENT
La courbe d’avancement ci dessus montre les écarts entre la courbe d’avancement

prévisionnelle et la courbe d ‘avancement.
En effet, l’écart le plus important à été enregistré dans la période du 16/04 au 02/07.
Il s’explique par le fait que, étant donné le peu de documentation et de spécifications sur
CodeX, la mise en place des APIs a duré plus longtemps que prévu.
Cependant, on constate que le regard a été rattrapé dés le début du moi de juillet au
moment ou débute la partie « réalisation » des services « My Account » et « Trackers ».
88
Gestion du projet
7 TESTS ET CODAGES
89
Gestion du projet
7.1 TRAVAUX RÉALISÉS
 Jalon 1
Ce 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 implémentant, coté serveur, les APIs SOAP. Une fois les fonctions de
récupération et de mise a jour des données mises en places, nous avons procédé aux
différents tests de vérification de la cohérences des données d’une part et de la
performance de la récupération d’autre part.
Nous avons toutefois constaté que l’appel aux différentes fonctions des web services ainsi
que la création de la base de données locale pouvaient prendre un temps relativement long
et que le Server MySQL de CodeX avait tendance a se bloquer notamment lorsqu’on
invoque une requête pour la récupération de plus de 5000 Artifacts.
 Jalon 2
Une fois les APIs du service « My Account » mise en place, il a fallut procéder a la création
des interfaces du dit service.
L’une des contraintes consistait à devoir reproduire sur le client les mêmes interfaces qui
existent déjà sur codeX.
La récupération des données entraîne leur stockage dans des structures XML, pour chaque
session ouverte sur CodeX.
Ce service induit la récupération et le stockage de donnée tels que les informations
utilisateurs, le profil et les compétences.
On note toutefois que, pour le service « My Account », les données récupérées ne sont
fonction que de l’utilisateur et ne dépendent donc pas du projet et des trackers sélectionnés
pour la récupération.
90
Gestion du projet
 Jalon 3
La mise en place du Web service correspondant au service « tracker » de CodeX s’est

révélé être la plus difficile à mettre en place.
Cette API a permis la récupération et la mise à jour de toutes les données inhérentes au
service « Trackers » de Codex en l’occurrence :
Les « Artiacts »,
Les fichiers attachés à un artiact,
Les commentaires sur un artiact,
Les dépendances entre artifacts.
Les données récupérées sont celles en relation avec les « Trackers » tels que
Les « Artifact Types » (les trackers),
Les « Artiact Report » (visualisation des Artifact d’un tracker en fonction d’une
requête sur un ou plusieurs de ses champs),
Les « Artifact Canned Response ».(reponses types à un commentaire)
Cependant, dans le cas du service « Tracker » les données récupérées dépendent des projets et
des trackers sélectionnés par l’utilisateur avant la récupération.
 Jalon 4
Le service « Tracker » deviens disponible sur le client CodeX et permet d ‘afficher des reports (l’affichage des
artefact), d’éditer et de créer des artefacts en y ajoutant des fichiers, des commentaires ou des dépendances
tout en respectant scrupuleusement les interfaces de CodeX.
Il permet également l affichage d’artefact en fonction de requête 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 d’éditer ou non les champs concernés.
91
Gestion du projet
8 EVALUATION « ASSESSMENT »
92
Gestion du projet
8.1 EVALUATION DE LA GESTION DE PROJET
En cours d’exécution du plan, Nous avons du examiner l’existant et vérifier que les objectifs du plan étaient
tenus, de même que les échéances….
Nous avons également procédé a une vérification des risques identifiés afin de savoir si ils représentent des
problème potentiels ou si ils ont été finalement surestimés.
On appelle ça « Rex » pour retour d’expérience, ou tout simplement suivi d’avancement.
 Outils
Pour savoir si on tient nos objectifs, on a eu besoin d’informations quantifiées et d’analyses de problèmes
rencontrés (pour en tirer les leçons).
 Analyse Causale
- Au niveau technique :
- Support non disponible (réfèrent technique).

- Sources d’informations disponibles.
- Evolution de l’application par rapport au changement apportés à Codex
- Problème de capacité à faire :
- Aucun problème.
 Enseignement
- Technique :
- La forme et les composant d’un bon « Packaging » des livrables.

- Se mettre à la place de l’utilisateur final pour mieux comprendre ces
exigences actuelles
- Prévoir d’autres exigences qui pourront être mises en cause au cours
de la réalisation du projet.
93
Gestion du projet
- Relationnel :
- Savoir « Convaincre » son équipe de ses points de vue quand c’est

nécessaire.
- Etre à l’écoute des autres propositions.
- Gestion de projet:
- Ne pas perdre de vu l’objectif final pour ne pas se laisser perturber par

des activités intermédiaires.
- Se remettre toujours en cause par rapport à ce qui existe et ce qui a
été prévu.
 Décisions
- Côté « Client »:
- Pas de changement au niveau de ces exigences.
- D1 : Continuer sur l’amélioration de l’application.

- D2 : Abandonner quelques choix techniques qui n’ennui pas à la
qualité du produit.
 Actions
- Meeting, pour se mettre d’accord sur les décisions prises.
94
Gestion du projet
8.2 APPORTS DE L’EQUIPE
La diversité des travaux qu’on a pu mener (participation à part entière dans la vie du projet Codex), le
nombre de personnes qu’on a côtoyé ainsi que l’autonomie qui nous été donnée ont contribué à faire de ce
stage une expérience enrichissante d’un point de vue humain, mais aussi sur le plan professionnel.
Il nous a fallut planifier efficacement notre travail (réalisation de plans) et faire un suivi des tâches à réaliser
(feuille Excel de Tracking). Les petits écarts par rapport aux prévisions ont pu être rapidement identifiés, pour
pouvoir y apporter des justifications et ainsi y remédier.
La communication et le travail en équipe ont également été des éléments décisifs à la réussite de ce projet. Il
est indispensable de savoir intéresser son interlocuteur tout en étant à son écoute. Chacun a ses propres
préoccupations et les collaborateurs n’ont pas forcément beaucoup de temps à nous consacrer. C’est pourquoi
il faut toujours veiller à être clair et concis dans ce que l’on dit .
D’autre part, nous avons pu collaborer et discuter avec bon nombre d’ingénieurs logiciel (« des professionnels
du développement, de sémantique) afin d’accumuler de nombreuses informations issues des secteurs avec
lesquels on n’était pas particulièrement familiarisés.
Bref, l’accomplissement de ce stage nous a résolument ouvert les yeux sur le métier d’ingénieurs
Informaticiens, qu’il soit ingénieur de qualité, de développement ou n’importe qu’elle autre spécialité.
95
Gestion du projet
9 CONCLUSION
96
Gestion du projet
9 CONCLUSION
C’est depuis ses débuts sous le nom de Haloid Company, que Xerox a fait le choix d’investir
en permanence une part substantielle de ses recettes dans la recherche fondamentale et
appliquée et beaucoup de technologies considérées aujourd'hui comme évidentes ont été
conçues ou améliorées 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 découvrir le fonctionnement du projet CodeX
de l’entreprise Xerox dans sa globalité tout en menant à bien les différents travaux qui nous
entaient confié. Ce fut pour nous une expérience très formatrice et particulièrement enrichissante
autour de plusieurs pôles.
Nous avons eu l’occasion de visualiser différents aspects de la fonction d’ingénieur logiciel, de

réaliser divers travaux axés vers la gestion de projet et ainsi contribuer à la vie de l’entreprise.
A travers notre initiation au mode de relation issu d’un projet de développement, nous avons été
amenés à affronter des problèmes concrets, en nous remettant en question quand cela était
nécessaire, et en faisant preuve de diplomatie.
Ecouter les autres, faire profiter de son savoir-faire sans l’imposer, entrent dans une
démarche de progrès. Tous ces aspects nous confortent dans l’idée de construire notre vie
professionnelle autour du monde de l’informatique et la qualité logicielle où des progrès reste à
faire pour changer les mentalités et ainsi améliorer continuellement les processus de
développement logiciel,
97
Annexes
ANNEXES
98
Annexes
SOMMAIRE DES ANNEXES
ANNEXE 1 : Définition
ANNEXE 2 : Le Planning
ANNEXE 3 : Les fiches de la gestion de projet
 Fiche de modification
 Fiche de tâches
 Compte rendu de réunion
 Fiche de validation du plan de qualité
 Fiche suiveuse de l’évolution du Projet
 Fiche d’anomalie des tests d’intégration
ANNEXE 4 : Suivi d’avancement
ANNEXE 5 : Références
 R1 : Bibliographies
 R2 : Webographies
99
Annexes
A.1 DEFINITIONS
• Artefacts Tout type d’items faisant l’objet d’un suivi, il peut s’agir de bugs, tâches, fiches
D’assistances, d’anomalies…
• Livrable Elément ou résultat mesurable, tangible et vérifiable, qui doit

Être fournit pour achever un projet ou une partie de projet.
• Jalon Evénement majeur du projet.
• Jalon Evénement majeur du projet.
• Planning Dates prévues pour la réalisation d’activité et l’atteinte de jalons
• Processus Ensemble d’activités corrélées ou interactives qui transforme des

Eléments d’entrée en éléments de sortie.[ISO 9000 : 2000]
• Template La forme que doit respecter un délivrable donné.
• Tracker outil de suivi d’artefacts.
• Work Breakdown Regroupement de tâches qui organise et définit le périmètre du Structure

(WBS) projet. Chaque niveau de décomposition définit de plus en plus
Précisément une partie du projet.
100
Annexes
A.2 LE PLANNING
101
Annexes
A.3.1 FICHE DE MODIFICATION
N° FM : 5
Fiche de Modification
- Modification proposé par : - Date du : 15/07/2006
ED-daou Majdouline
- Description de la modification proposée :
Changement de L’IHM du client :

- Mettre un menu visible dans toutes les interfaces.
- Motivations de la proposition et importance :

- Les IHMs deviendrons plus ergonomiques.
- la manipulation de l’application se facilitera d’avantage.
- Analyse du chef de projet (faisabilité, coût, délai) :

- Modifications importantes sur les IHMs existantes.
- pas cher pour le profit apporté à l’application
- délai < à 5 jours
- Décision du chef de projet:

 Oui Non Apportée
Signature chef de projet demandeur : Signature chef de projet

réalisateur :
102
Annexes
A.3.2 FICHE DE TACHES
Fiche suiveuse de l’évolution des tâches
N
° Résultat Responsab Date Date
Description Origine ou cause Et
Tâc attendu le cible réelle
at
he
Spécification Application définition des équipe 01/04/06 01/04/06

T
1 et conception CodeX APIs MTM
des APIs « Mon compte »
Spécification Application définition des équipe 14/04/06 14/04/06

T
2 et conception CodeX IHMs MTM
des IHMs
« Mon Compte »
Etat : NC => non commencé.

EC => en cours.
T => Terminé.
V => Validé.
Signature chef de projet réalisateur :
Equipe MTM
103
Annexes
A.3.3 COMPTE RENDU DE REUNION
Réunion du : 07/02/06
Durée : 45 min
Lieu : salle « Mont Rose »
Compte rendu de
réunion
« Réunion de lancement »
Etaient présent : Président de la réunion : Etabli par :

Les membres : - Le secrétaire de l’équipe.
- Ed-daou Majdouline Ed-daou Majdouline
- Oubouhou Majd Oubouhou Majd
- Abbadi Tarik
Ordre du jour :
- Mise au point sur la mission qui nous a été confié, l’environnement de travail…..etc.
- Définition des étapes à suivre pour la réalisation de ce projet.
- Spécification des Tâches à réaliser dans une quinzaine de jours
- Affectation des Tâches au membre de l’équipe MTM
Détails :
- Discussion sur l’environnement Codex et analyse de l’existant.

- Discussion sur la faisabilité des services de codex en offline.
Décisions prises :
- Oubouhou Majd.s’occupera de la partie serveur (APIs)

- Ed-daou Majdouline et Abbadi Tarik s’occuperont de la partie cliente et de la gestion
du projet.
- En cas de difficultés rencontrées dans une partie, l’équipe MTM s’en occupera.
Prochaine réunion : Convoqué(e)s :

Les membres :
Date : 15/03/06 - Mr.Nicolas Guérin
Heure : 14h - Ed-daou Majdouline
Lieu : salle « Mont Rose » - Oubouhou Majd
- Abbadi Tarik
104
Annexes
A.3.4 FICHE DE VALIDATION DU PLAN DE QUALITÉ
Date : 25/02/06
Fiche de validation du plan de qualité
Je soussigné Mr Nicolas Guérin, maître d’ouvrage du projet « Codex »,

réalisé en partie par l’équipe « MTM », que le présent plan qualité est complet du
point de vue technique, et répond à tous les critères figurant dans le cahier de
charges.
Et sur ce je qualifie le Plan Qualité valide.
Signature chef de projet demandeur : Signature chef de projet réalisateur :
Mr. Nicolas Guérin Equipe MTM
105
Annexes
A.3.5 FICHE SUIVEUSE DE L’ÉVOLUTION DU PROJET
Fiche suiveuse de l’évolution du Projet

Document ou N° de Eta
Date Lieu de stockage
logiciel Fiche t
Plan Qualité 2 30/02/06 T

http://codex.xerox.com/svn....
Spécification 1 10/05/06 EC
Fonctionnel
Conception 1 10/05/06 EC
Préliminaire
Réalisation 1 10/05/06 EC
Etat : NC => non commencé.

EC => en cours.
T => Terminé.
V => Validé.
Signature chef de projet

demandeur :
106
Annexes
A.3.6 FICHE D’ANOMALIE DES TESTS D’INTÉGRATION
Test N° :
Fiche d’anomalie des tests

d’intégration
Déroulement type :
…………………………………………………………………………………………………
…………………………………………………………………………………………………
…………………………………………………………………………………………………
…………………………………………………………………………………………………
Exécution des tests :

…………………………………………………………………………………………………
…………………………………………………………………………………………………
…………………………………………………………………………………………………
…………………………………………………………………………………………………
…………………………………………………………………………………………………
…………………………………………………………………………………………………
Analyses des résultats :

…………………………………………………………………………………………………
…………………………………………………………………………………………………
…………………………………………………………………………………………………
…………………………………………………………………………………………………
…………………………………………………………………………………………………
Cause de l’anomalie :
…………………………………………………………………………………………………
…………………………………………………………………………………………………
…………………………………………………………………………………………………
…………………………………………………………………………………………………
…………………………………………………………………………………………………
Proposition de la correction de l’erreur :

…………………………………………………………………………………………………
…………………………………………………………………………………………………
…………………………………………………………………………………………………
…………………………………………………………………………………………………
…………………………………………………………………………………………………
107
Annexes
A.4 SUIVI D’AVANCEMENT
108
Annexes
R.1 BIBLIOGRAPHIE
109
Annexes
R.2 WEBOGRAPHIE
110

Rapport Stage V2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Rapport Stage V2

Uploaded by

Copyright:

Available Formats

Présentation de la société

1.1.6 Les objectifs généraux ....................................................................................................19

1.1.21 Les documents de procédure..........................................................................................33

A.3.4 FICHE DE VALIDATION DU PLAN DE QUALITÉ ...............................................................105

TABLE DES FIGURES

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

Pourtant, de nombreuses entreprises reconnaissent que leurs activités de développement

Cette plate-forme centralisée propose un grand nombre de services utiles au développement

C’est dans le cadre de la préparation du projet de deuxième année de spécialisation que

Cette approche globale justifie le choix de la présentation du rapport en huit parties

1 -Présentation de l’organisation support du projet

1.1 L’ENTREPRISE XEROX

Xerox, un des leaders mondiaux de la bureautique, offre, en plus de sa gamme de

L’envergure de l’entreprise lui a permis de développer 5 centres de recherches et de

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

Ces produits et services facilitent la transformation des informations imprimées en informations

1.1.2 Organisation interne

Xerox comprend trois grands départements :

C’est de ce dernier département que relèvent les centres de recherche et laboratoires

1.1.3 Segmentation du marché

Figure 2 : Répartition géographique des revenus de Xerox (données 2005)

Position de Xerox sur le marché :

1.2 XEROX RESEARCH CENTER EUROPE

1.1.4 La SPD et l’équipe CodeX

Les applications concrètes qui en découlent permettent de faciliter grandement la

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

1.2.1.1 Données clés

Effectifs : 4 membres permanents (3 ingénieurs Codex + 1 Chef d’équipe)

• d’optimiser l’investissement logiciel des entreprises

Figure 4 : Composantes de la SDP

1.1.5 La méthodologie SIGMA-PLUS et le système Scrum

L'offre de SIGMA-PLUS se répartit selon trois branches:

• les études : dans les domaines de la simulation (phénomènes physiques, conception

Son utilisation est prévue initialement pour la gestion de projets de développement, et

2.2 LA FEUILLE DE ROUTE DE LA MISSION

1.1.6 Les objectifs généraux

Les objectifs généraux ont été répartis en six points :

• Etude globale du cahier des charges

1.1.7 Les étapes

Les principales étapes prévues initialement ont été :

• La collecte et la validation des besoins : Une étape de préparation destinée

- analyser l’ensemble des services offerts par Codex on-line

- planifier le déroulement des interviews

• L’élaboration et la présentation du plan d’activité : Parallèlement à la

• L’implémentation de nouvelles API : Dans cette phase était proposée la

• L’implémentation du client : Il s’agit de la réalisation d’un client portable en

• L’élaboration des supports de formation : A chaque étapes de réalisation,

3.1 L’ENGAGEMENT DE QUALITÉ

1.1.8 La Capacité fonctionnelle des applications

- Leur Confidentialité : l’interface de connexion permettra que seuls les utilisateurs

1.1.9 La Fiabilité (intégrité)

- Les Possibilités de leur récupération : l’application à développer doit procéder à

- la Mesure de la qualité : mise en place d’un test surveillant l’enregistrement des

1.1.10La facilité d’utilisation

- pour toutes interfaces : la facilité d’utilisation est exigée.

1.1.11Le rendement et la disponibilité

- Comportement vis-à-vis du temps : la récupération des données du serveur

- Comportement vis-à-vis des ressources : au moment de la construction de la base

1.1.12La maintenabilité et la portabilité

- Maintenabilité : le produit étant destiné à être commercialisé, les facilités

3.2 LE CONTRÔLE DES RISQUES

Figure 5 : Cheminement de l’évaluation des risques

1.1.14Le mode de prévision des risques

Tableau 1 : Mode de prévision des risques