Présentation de la société
SOMMAIRE
SOMMAIRE 1
INTRODUCTION 5
1 PRÉSENTATION 6
1.1 L’ENTREPRISE XEROX 7
1.1.1 Présentation de Xerox Corporation 7
1.1.2 Organisation interne 9
1.1.3 Segmentation du marché 9
1.2 XEROX RESEARCH CENTER EUROPE 11
1.2.1 La SPD et l’équipe CodeX 12
1.2.1.1 Données clés 131.2.1.2 Missions 13
1.2.2 La méthodologie SIGMA-PLUS et le système Scrum 14
2 LA MISSION 16
2.1 ORGANISATION 17
2.2 LA FEUILLE DE ROUTE DE LA MISSION 18
2.2.1 Les objectifs généraux 18
2.2.2 Les étapes 18
3 GESTION DU PROJET 20
3.1 L’ENGAGEMENT DE QUALITÉ 21
3.1.1 La Capacité fonctionnelle des applications 21
3.1.2 La Fiabilité (intégrité) 21
3.1.3 La facilité d’utilisation 21
3.1.4 Le rendement et la disponibilité 21
3.1.5 La maintenabilité et la portabilité 22
3.2 LE CONTRÔLE DES RISQUES 23
3.2.1 Le processus de contrôle des risques 23
3.2.2 Le mode de prévision des risques 24
3.3 CONTRAINTES DE DÉVELOPPEMENT ET DE LIVRABLE 26
3.3.1 Les macro tâches 26
3.3.2 Les jalons et livrables 28
Concernant les jalons et livrables associés, ont été retenus 4 niveaux de jalons: 28
3.4 PROCESSUS SUPPORT DE LA MISSION 29
3.4.1 La gestion des modifications 29
3.4.2 La gestion de configuration 29
3.4.3 La gestion des risques 29
3.4.4 La gestion des documents de suivi 30
3.4.5 Les documents de procédure 30
3.4.5.1 Les documents techniques 30
3.5 LIMITES DU PROJET 31
1
Présentation de la société
3.5.1 Les interfaces 31
3.5.2 Les contraintes techniques de l’application 32
3.5.3 Les contraintes temporelles et de charge 32
3.5.4 Les contraintes organisationnelles 33
4 ANALYSE 34
4.1 LES OBJECTIFS DE LA SOLUTION CODEX 35
4.2 FONCTIONNALITÉS ET LIMITES DE LA PLATEFORME CODEX 38
5 SPÉCIFICATION 40
5.1 ETUDE DES BESOINS 41
5.2 DIAGRAMME DE CAS D’UTILISATIONS (HAUT NIVEAU) 42
6 CONCEPTION 44
6.1 PROBLEMATIQUE 45
6.2 LES SOLUTIONS ETUDIEES 47
6.3 LA SOLUTION RETENUE 49
6.4 DIAGRAMMES 54
6.1.1 Diagramme de Classes 54
6.1.2 Diagrammes de séquences 59
6.1.3 Diagramme de déploiement 62
6.5 LES MAQUETTES 63
6.6 ETAT D’AVANCEMENT (GANTT) 74
6.7 COURBE D’AVANCEMENT 75
7 TESTS ET CODAGES 76
7.1 TRAVAUX RÉALISÉS 77
Jalon 1 77
Jalon 2 77
Jalon 3 77
Jalon 4 77
Jalon 5 77
Jalon 6 77
7.2 TESTS 78
Jalon 1 78
Jalon 2 78
Jalon 3 78
Jalon 4 78
Jalon 5 78
Jalon 6 78
8 EVALUATION « ASSESSMENT » 79
8.1 GESTION DE PROJET 80
Outils 80
Analyse Causale 80
Enseignement 80
2
Présentation de la société
Décisions 81
Actions 81
8.2 APPORTS DE L’ÉQUIPE MTM 82
9 CONCLUSION ET PERSPECTIVES 83
9.1 CONCLUSION 84
9.2 PERSPECTIVES 85
ANNEXES 86
SOMMAIRE DES ANNEXES 87
A.1 DEFINITIONS 88
A.2 LE PLANNING 89
A.3.1 FICHE DE MODIFICATION 90
A.3.2 FICHE DE TACHES 91
A.4 SUIVI D’AVANCEMENT 92
R.1 BIBLIOGRAPHIE 93
R.2 Webographie 94
3
Présentation de la société
Table des figures
Figure 1 : Les centres de recherche de Xerox à travers le monde.........................................................8Figure 2 : Répartition géographique des revenus de Xerox (données 2005)………………………….9Figure 3 : Organigramme de Xerox et positionnement du XRCE et de la SDP……………………..12Figure 4 : Composantes de la SDP......................................................................................................13Figure 5 : Cheminement de l’évaluation des risques………………………………………………...23Figure 6 : Diagramme de PERT (Cheminement des macros tâches)……………………………….27Figure 7 : Contrainte de vérification des droits……………………………………………………...31Figure 8 : les 2 dimensions indispensables à une stratégie réussie de réutilisation………………….35Figure 9 : Schémade la plateforme CodeX …………………………………………………………38Figure 10 : Principe de Fonctionnement du mode hors ligne de CodeX…………………………….46Figure 11 : Schéma de communication entre Client Java et Server CodeX…………………………50Figure 12 : Les différentes étapes du fonctionnement de CodeX en mode hors ligne………………53Figure 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 »……………………...69Figure 23: partie d’ajout, de modification et de suppression de commentaires et de Fichiers attachés…………………………………………………………………………70Figure 24: partie d’ajout ou de suppression de dépendances ……………………………………………..71Figure 25: écran de récupération d’outils de suivi du projet choisi………………………………….73
4
Présentation de la société
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
Présentation de la société
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.
7
Présentation de la société
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.
8
Présentation de la société
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%).
9
Présentation de la société
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.
10
Présentation de la société
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.
11
Présentation de la société
1.2.1 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
12
Présentation de la société
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
13
Présentation de la société
1.2.2 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.
14
Présentation de la société
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.
15
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.
17
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 ».
2.2.1 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.
2.2.2 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.
18
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
19
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é.
3.1.1 La Capacité fonctionnelle des applications
- Leur Inter opé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.
3.1.2 La Fiabilité (intégrité)
- Leur M aturité 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 P ossibilité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.
3.1.3 La facilité d’utilisation
- pour toutes interfaces : la facilité d’utilisation est exigée.
- pour CodeX en ligne : garder absolument les types de manipulation existants.
3.1.4 Le 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
21
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
3.1.5 La 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.
22
Gestion du projet
3.2 LE CONTRÔLE DES RISQUES
3.2.1 Le 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).
23
Gestion du projet
Figure 5 : Cheminement de l’évaluation des risques
24
Gestion du projet
3.2.2 Le mode de prévision des risques
Tableau 1 : Mode de prévision des risques
Types derisques
Causespossibles
ImpactsPrévisibles
Probabilité
Niveau criticité
Actionsenvisagées
Datecible
Etat
Evaluation desdélais
Manque d’expérience
Retard, non respect des délais (2)
2 4
1ères évaluations 1 Optimiste +2 Normales +1 Pessimiste
Validation avec le Responsable du stage
ImmédiatT
A
Evaluation de la charge des tâches
Manque d’expérience et spécifications non encore commencées
Retard ou tâches inachevées (1) 2 4
Réévaluations et adaptations en cours de projet
A partir du 01/03
T
Evaluation des risques imprévus
Manque d’expérience ou risques oubliés
Obligation de subir les conséquences sans les avoir prévues (3)
2 6Validation avec le Responsable du stage et des réévaluations régulières
A partir du 01/03
A
EC
Risques techniques dus au non maîtrise des outils
Insuffisance de connaissances ou mauvaise répartition des tâches
Retard ou produit inachevé (2) 2 4
Formation sur les nouveaux outilsRépartition plus souple des tâches Communications internes importantes
16/02et surtoutela durée du projet
T
EC
Risque de mauvaise coordination entre membres l’équipe
Mauvaise communication ou non formalisation
Incompatibilité entre les applications développées par l’équipe EMA-EERIE(3)
2 6Structuration de l’équipe, distribution des rôles, entraide, motivation et responsabilisation
Surtoutela durée du projet
T
Les critères et les ratios retenus pour leur évaluation sont :
25
Gestion du projet
- 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)
26
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.
3.3.1 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
27
Gestion du projet
Figure 6 : Diagramme de PERT (Cheminement des macros tâches)
Réunion de lancement
Début : 06/02/06Fin : 07/02/06
Compréhension du sujet
Début : 08/02/06Fin : 09/02/06
Auto-formation technique
Début : 09/02/06Fin : 20/02/06
Rédaction de plan de qualité
Début : 15/02/06Fin : 24/02/06
Gestion de projet et suivi Quantité
Début : 20/02/06Fin : 25/08/06
Spécification et conception des APIs du service « My Account »
Début : 21/03/06Fin : 01/04/06
Spécification et conception
des IHMs du service « My
Account »Début : 01/04/06Fin : 14/04/06
Spécification et conception des
APIs du service « Trackers »Début : 23/03/06Fin : 21/04/06
Spécification et conception
des IHMs du service
« Trackers »Début : 18/04/06Fin : 06/05/06
Réalisation de la fonctionnalité « Récupération des données »
Début : 08/05/06Fin : 07/02/06
Réalisation du service « My Account»
Début : 20/02/06Fin : 21/02/06
Réalisation du service «
Trackers»
Début : 20/02/06Fin : 21/02/06
Réalisation de la
fonctionnalité
« Synchronisation des
données »
Début : 20/02/06Fin : 21/02/06
Tests d'interaction interne et externe des fonctionnalités de CodeX Offline
Début : 20/02/06Fin : 21/02/06
Revue Finale
Début : 20/02/06Fin : 21/02/06
Analyse du projet
Début : 14/02/06Fin : 21/03/06
Spécification et conception
des IHMs du service
« Trackers »Début : 18/04/06Fin : 06/05/06
28
Gestion du projet
3.3.2 Les 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 ».
30
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.
3.4.1 La 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.
3.4.2 La 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.
3.4.3 La 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 :
31
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.
3.4.4 La 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.
3.4.5 Les 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é.
3.4.5.1 Les documents techniques
Les documents techniques de réalisation sont de plusieurs niveaux de :32
Gestion du projet
Conception globale.
Conception détaillée.
Documentations liées au code source.
Documentations liées aux tests
33
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.
3.5.1 Les 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.
Figure 7 : Contrainte de vérification des droits
Vérification des Droits
Codex
34
Gestion du projet
3.5.2 Les 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 »
3.5.3 Les 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.
35
Gestion du projet
Tableau 2 : Planning des points de projet et des revues
3.5.4 Les 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.
Points de projet Revues
- 15 Février 2006- 28 Février 2006- 15 Mars 2006- 30 Mars 2006- 15 Avril 2006- 30 Avril 2006- 15 Mai 2006- 30 Mai 2006- 15 Juin 2006- 15 Juillet 2006- 30 Juillet 2006- 15 Août 2006- 26 Août 2006
- 15 Mars 2006 : Revue Qualité.
- 01 Avril 2006 : Spécification/Conception.
- 01 Août 2006 : Revue Finale.
36
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,
38
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
l’équipe CodeX et ses clients
Grande contribution au code
39
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.
1
40
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.
41
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
42
Gestion du projet
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.
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.
43
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.
45
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.
46
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.
48
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.
50
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).
51
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.
53
Gestion du projet
Tableau 4 : Comparaison REST, XML-RPC et SOAP
XML-RPC
SOAP
REST
- Nombre limité de type
de données
- Plus simple à
implémenter
- Utilise des API RPC
- http + couche
d’abstraction
- Se base sur des
méthodes
- Manque de précisions
- Confusions sur certains
aspects
(support unicode
notamment)
- Mots de passe
transmis en clair
- Grand nombre de type
de données
- Plus complexe à
implémenter
- Utilise des API RPC
- http + couche
d’abstraction
- Se base sur des
méthodes
- Communication par
requêtes Get services
- Très simples à
interroger
- Repose uniquement sur
l’utilisation d’http, des
URIs et d’XML
- Se base sur les
ressources existantes.
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.
54
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é
56
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
57
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.
58
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, 59
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.
60
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.
61
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
62
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 »
64
Gestion du projet
Ce package contient les différentes classes qui représentent les fichiers XML manipules par le service « Account ».
65
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 ».
66
Gestion du projet
Package « Tracker Database »
Ce package contient les différentes classes qui représentent les fichiers XML manipules par le service « Tracker ».
67
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.
68
Gestion du projet
La classe « Artifact » contient les champs standards et les champs
dynamiques selon chaque type de tracker.
6.4.2 Diagrammes 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.
69
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.
70
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).
71
Gestion du projet
6.4.3 Diagramme 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.
72
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.
73
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é
74
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.
75
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.
76
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».
77
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.
78
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.
79
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 :
80
Gestion du projet
Soumettre des commentaires (voir Figure 23 [page 71]), Ajouter ou supprimer des dépendances (voir Figure 24 [page 72]), Ajouter ou supprimer des fichiers attachés (voir Figure 23 [page 71]),
81
Gestion du projet
Figure 23: partie d’ajout, de modification et de suppression de commentaires et de
Fichiers attachés
82
Gestion du projet
Figure 24: partie d’ajout ou de suppression de dépendances
83
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.
84
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 ».
87
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.
89
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.
90
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.
- Relationnel :
92
Gestion du projet
- 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.
93
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é.
94
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,
96
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
98
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 desElé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.
99
Annexes
A.3.1 FICHE DE MODIFICATION
Fiche de Modification
N° FM : 5
- Modification proposé par : ED-daou Majdouline
- Date du : 15/07/2006
- 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 :
101
Annexes
A.3.2 FICHE DE TACHES
Fiche suiveuse de l’évolution des tâches
N° Tâche
Description Origine ou cause Résultat attendu
Responsable
Date cible
Date réelle
Etat
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
102
Annexes
A.3.3 COMPTE RENDU DE REUNION
Compte rendu de réunion
« Réunion de lancement »
Réunion du : 07/02/06 Durée : 45 min Lieu : salle « Mont Rose »
Etaient présent : Les membres :
- Ed-daou Majdouline - Oubouhou Majd - Abbadi Tarik
Président de la réunion :
Oubouhou Majd
Etabli par : - Le secrétaire de l’équipe. Ed-daou Majdouline
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 :
Date : 15/03/06Heure : 14hLieu : salle « Mont Rose »
Convoqué(e)s : Les membres :
- Mr.Nicolas Guérin - Ed-daou Majdouline - Oubouhou Majd - Abbadi Tarik
103
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
104
Annexes
A.3.5 FICHE SUIVEUSE DE L’ÉVOLUTION DU PROJET
Fiche suiveuse de l’évolution du Projet
Document ou logiciel
N° de Fiche
Date Etat
Lieu de stockage
Plan Qualité 2 30/02/06 T http://codex.xerox.com/svn....
Spécification 1 10/05/06 EC http://codex.xerox.com/svn.... Fonctionnel
Conception 1 10/05/06 EC http://codex.xerox.com/svn.... Préliminaire
Réalisation 1 10/05/06 EC http://codex.xerox.com/svn....
Etat : NC => non commencé. EC => en cours. T => Terminé. V => Validé.
Signature chef de projet demandeur :
105
Annexes
A.3.6 FICHE D’ANOMALIE DES TESTS D’INTÉGRATION
Fiche d’anomalie des tests d’intégration
Test N° :
Déroulement type : ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… …………………………………………………………………………………………………
Exécution des tests : ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… …………………………………………………………………………………………………
Analyses des résultats : ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… …………………………………………………………………………………………………
Cause de l’anomalie : ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… …………………………………………………………………………………………………
Proposition de la correction de l’erreur : ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… …………………………………………………………………………………………………
106
Top Related