Download - Rapport Stage V2

Transcript
Page 1: Rapport Stage V2

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

Page 2: Rapport Stage V2

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

Page 3: Rapport Stage V2

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

Page 4: Rapport Stage V2

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

Page 5: Rapport Stage V2

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

Page 6: Rapport Stage V2

Présentation de la société

1 PRÉSENTATION

6

Page 7: Rapport Stage V2

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

Page 8: Rapport Stage V2

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

Page 9: Rapport Stage V2

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

Page 10: Rapport Stage V2

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

Page 11: Rapport Stage V2

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

Page 12: Rapport Stage V2

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

Page 13: Rapport Stage V2

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

Page 14: Rapport Stage V2

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

Page 15: Rapport Stage V2

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

Page 16: Rapport Stage V2

Gestion du projet

2 LA MISSION

16

Page 17: Rapport Stage V2

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

Page 18: Rapport Stage V2

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

Page 19: Rapport Stage V2

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

Page 20: Rapport Stage V2

Gestion du projet

3 GESTION DU PROJET

20

Page 21: Rapport Stage V2

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

Page 22: Rapport Stage V2

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

Page 23: Rapport Stage V2

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

Page 24: Rapport Stage V2

Gestion du projet

Figure 5 : Cheminement de l’évaluation des risques

24

Page 25: Rapport Stage V2

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

Page 26: Rapport Stage V2

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

Page 27: Rapport Stage V2

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

Page 28: Rapport Stage V2

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

Page 29: Rapport Stage V2

Gestion du projet

29

Page 30: Rapport Stage V2

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

Page 31: Rapport Stage V2

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

Page 32: Rapport Stage V2

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

Page 33: Rapport Stage V2

Gestion du projet

Conception globale.

Conception détaillée.

Documentations liées au code source.

Documentations liées aux tests

33

Page 34: Rapport Stage V2

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

Page 35: Rapport Stage V2

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

Page 36: Rapport Stage V2

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

Page 37: Rapport Stage V2

Gestion du projet

4 ANALYSE

37

Page 38: Rapport Stage V2

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

Page 39: Rapport Stage V2

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

Page 40: Rapport Stage V2

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

Page 41: Rapport Stage V2

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

Page 42: Rapport Stage V2

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

Page 43: Rapport Stage V2

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

Page 44: Rapport Stage V2

Gestion du projet

5 SPÉCIFICATION

44

Page 45: Rapport Stage V2

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

Page 46: Rapport Stage V2

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

Page 47: Rapport Stage V2

Gestion du projet

5.2 DIAGRAMME DE CAS D’UTILISATIONS (HAUT NIVEAU)

47

Page 48: Rapport Stage V2

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

Page 49: Rapport Stage V2

Gestion du projet

6 CONCEPTION

49

Page 50: Rapport Stage V2

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

Page 51: Rapport Stage V2

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

Page 52: Rapport Stage V2

Gestion du projet

52

Page 53: Rapport Stage V2

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

Page 54: Rapport Stage V2

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

Page 55: Rapport Stage V2

Gestion du projet

55

Page 56: Rapport Stage V2

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

Page 57: Rapport Stage V2

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

Page 58: Rapport Stage V2

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

Page 59: Rapport Stage V2

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

Page 60: Rapport Stage V2

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

Page 61: Rapport Stage V2

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

Page 62: Rapport Stage V2

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

Page 63: Rapport Stage V2

Gestion du projet

6.4 DIAGRAMMES

6.4.1 Diagramme de Classes

63

Page 64: Rapport Stage V2

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

Page 65: Rapport Stage V2

Gestion du projet

Ce package contient les différentes classes qui représentent les fichiers XML manipules par le service « Account ».

65

Page 66: Rapport Stage V2

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

Page 67: Rapport Stage V2

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

Page 68: Rapport Stage V2

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

Page 69: Rapport Stage V2

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

Page 70: Rapport Stage V2

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

Page 71: Rapport Stage V2

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

Page 72: Rapport Stage V2

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

Page 73: Rapport Stage V2

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

Page 74: Rapport Stage V2

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

Page 75: Rapport Stage V2

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

Page 76: Rapport Stage V2

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

Page 77: Rapport Stage V2

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

Page 78: Rapport Stage V2

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

Page 79: Rapport Stage V2

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

Page 80: Rapport Stage V2

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

Page 81: Rapport Stage V2

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

Page 82: Rapport Stage V2

Gestion du projet

Figure 23: partie d’ajout, de modification et de suppression de commentaires et de

Fichiers attachés

82

Page 83: Rapport Stage V2

Gestion du projet

Figure 24: partie d’ajout ou de suppression de dépendances

83

Page 84: Rapport Stage V2

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

Page 85: Rapport Stage V2

Gestion du projet

6.6 ETAT D’AVANCEMENT (GANTT)

85

Page 86: Rapport Stage V2

Gestion du projet

86

Page 87: Rapport Stage V2

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

Page 88: Rapport Stage V2

Gestion du projet

7 TESTS ET CODAGES

88

Page 89: Rapport Stage V2

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

Page 90: Rapport Stage V2

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

Page 91: Rapport Stage V2

Gestion du projet

8 EVALUATION « ASSESSMENT »

91

Page 92: Rapport Stage V2

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

Page 93: Rapport Stage V2

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

Page 94: Rapport Stage V2

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

Page 95: Rapport Stage V2

Gestion du projet

9 CONCLUSION

95

Page 96: Rapport Stage V2

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

Page 97: Rapport Stage V2

Annexes

ANNEXES

97

Page 98: Rapport Stage V2

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

Page 99: Rapport Stage V2

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

Page 100: Rapport Stage V2

Annexes

A.2 LE PLANNING

100

Page 101: Rapport Stage V2

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

Page 102: Rapport Stage V2

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

Page 103: Rapport Stage V2

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

Page 104: Rapport Stage V2

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

Page 105: Rapport Stage V2

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

Page 106: Rapport Stage V2

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

Page 107: Rapport Stage V2

Annexes

A.4 SUIVI D’AVANCEMENT

107

Page 108: Rapport Stage V2

Annexes

R.1 BIBLIOGRAPHIE

108

Page 109: Rapport Stage V2

Annexes

R.2 WEBOGRAPHIE

109