CONDUITE DE PROJET
GROUPE JAVAVIDED
|
A
l’attention de : |
|
|
Etudiants : |
|
|
Juliette COLMANT |
|
|
Denis ELBAZ |
|
|
Patrice LAMARQUE |
|
|
Marilyne MERCIER |
|
|
Rana TADAYONI |
|
Le but de ce projet est l’application de méthodes
de conduite de projet et de conception de systèmes pour spécifier et organiser
la réalisation d’une application.
L’application concerne la réalisation d’un
logiciel permettant de simuler les fonctions de base d’un logiciel de montage.
Le but principal de ce projet était l’organisation des équipes. Nous avons
donc adopté des méthodes de travail ainsi que pris des décisions concernant la
réalisation de l’application.
A la réception de ce projet, nous nous sommes tous réunis afin de prendre
les décisions en matière d’organisation, aussi bien au niveau de l’équipe que
des diverses méthodes que nous allions adopter ou encore des documents de
travail que nous allions créer.
A la suite de nos diverses réunions, différents choix ont été faits.
Nous avions à choisir une méthode de travail. Pour cela nous avons donc
décidé d’élire un chef de projet, la tâche de celui-ci étant de diriger voire
d’orienter les différentes personnes intervenant sur le projet. Le chef de
projet n’a en aucun cas la responsabilité de décider seul du travail à
effectuer par les différents intervenants du projet. En effet, le chef de
projet a pour rôle l’organisation et la coordination des personnes intervenant
sur le projet. La personne qui a été élue pour assurer cette tâche est :
Arnaud Balay.
En plus de ce chef de projet, des responsables ont été élus pour assurer
l’organisation des différentes sous-tâches définies dans l’échéancier. Dans le
reste du document, nous utiliserons le terme de work space pour définir ces
sous-tâches. En plus des fonctions de chef de projet sur ces sous-tâches, ces
personnes étaient responsables de l’intégration avec le reste du projet, ils
étaient les interlocuteurs privilégiés pour ces sous-tâches.
En ce qui concerne le choix du cycle de vie, nous avons opté pour un cycle
de vie en V. En effet, le fait de “paralléliser” le développement en
sous-tâches ne nous permettait pas d’avoir une application tournante avant la
première version du logiciel qui était déjà presque abouti.
A ce moment, nous aurions pu commencer un cycle de vie en spirale avec un
apport de modifications demandées par le client, test... puis de nouvelles
soumissions. Malheureusement, le temps dont nous disposions ne nous pas permis
de mettre ce type de cycle de vie en route.
En ce qui concerne la conception, nous avons décidé d’utiliser la méthode
UML. En effet, le langage de modélisation UML utilise différents diagrammes
clairs permettant de modéliser facilement une application.
La conduite de projet comprend, en plus de la gestion des différentes
personnes intervenant sur le projet, une partie documentation et une partie transfert
de compétences au sein de l’équipe.
En effet, tout projet doit être documenté pour être réutilisable et compris
par le reste de l’équipe. Tous les documents émis comme les comptes-rendus de
réunions, les documentations, les études de faisabilité, etc. constituent
l’historique du projet.
Nous devions donc définir des documents types permettant de mettre à la
disposition de tous les intervenants du projet, les informations concernant
l’évolution de celui-ci. La mise en place de documents types permet d’accéder
rapidement à l’information recherchée au sein d’un long document.
En plus d’être standards, ces documents devaient être facilement
accessibles. Nous avons donc opté pour la création d’un site Internet. En
effet, cette méthode nous a paru être le meilleur moyen de mettre à disposition
de tous les intervenants les différentes informations récoltées au cours de la
création de l’application.
Les informations sont donc accessibles via le site
javavided.sourceforge.net à tout le monde, sous forme d’une liste de documents
et de comptes-rendus de réunions mais aussi d’un arbre de work spaces. (Chaque
work space peut être décliné en sous-work spaces.)
En ce qui concerne le développement, nous avons opté pour l’utilisation
d’un serveur CVS. En effet, ce projet faisant intervenir six développeurs, nous
avons décidé d’utiliser CVS qui permet de mettre à jour l’application au fur et
à mesure de l’intervention des différents développeurs. Cet outil permet aussi
la gestion des versions concurrentes. Travailler avec cet outil permet de voir
l’évolution du développement en temps réel. En effet, à chaque fois qu’un
développeur va modifier ou créer une nouvelle classe, les autres intervenants
pourront avoir accès à cette classe sans avoir demandé qu’on leur envoie les
nouvelles sources. Cet outil permet d’avoir des sources communes à tous les
développeurs. De ce fait, CVS facilite beaucoup le développement.
Après avoir mis en place les standards en matière de documentation et de
développement, nous avons mis en place un échéancier. Celui-ci comprenait la
liste des différentes tâches à accomplir, les personnes intervenant sur ces
tâches ainsi que les dates auxquelles ces dernières devaient être terminées.
Le projet a donc été découpé en plusieurs sous-tâches qui étaient les
suivantes :
ØLa mise en place des méthodes de travail,
ØLes différentes études de faisabilité nécessaires
à la prise de décision concernant les choix à prendre pour l’élaboration de
l’application,
ØLa rédaction du cahier des charges, permettant de
proposer et de faire valider par le client la solution que nous désirions
adopter,
ØLa définition des objets, permettant le découpage
en packages du développement de l’application,
ØLe développement des différents packages de l’application,
ØL’intégration des packages en une application
unique,
ØLa validation du client,
ØLes différents tests pour tester l’application et
corriger d’éventuels bugs,
ØL’installation,
ØLa rédaction des documentations utilisateurs et
techniques effectuée au fur et à mesure de l’avancement des différents
packages.
Pour la création du cahier des charges, nous avons tout d’abord fait des
propositions de concepts et de solutions techniques. Ensuite, nous avons étudié
la faisabilité de ces différents concepts ou solutions et avons enfin opté pour
différentes solutions que nous allions présenter au client. Le cahier des
charges est donc le document qui a été rédigé en vue de cette présentation au
client. Ce cahier des charges comprend la description des différents choix
techniques qui ont été faits par l’équipe de conception.
Une fois le cahier des charges terminé, il est soumis à validation du
client. Si le client valide, le développement peut alors commencer.
Avant de valider un package, c’est-à-dire de déterminer qu’un lot est
finalisé et donc qu’il ne nécessite plus de modification, ce package doit être
soumis à différents tests. Ces tests ont pour but de vérifier que le
développement répond bien à la demande du client spécifiée dans le cahier des
charges et éventuellement corriger certains bugs encore existants. Ces tests
sont mis en places par les intervenants du projet de manière incrémentale. A
chaque fois qu'une nouvelle fonctionnalité est ajoutée, l'ensemble du lot est à
nouveau testé ainsi que les lots connexes, c'est-à-dire ceux qui en dépendent
ou qui l'utilisent.
Une fois cette étape de tests terminée, on peut dire que le package répond
bien à la demande formulée dans le cahier des charges et donc qu’il peut être
finalisé.
En ce qui concerne l’interface utilisateur, nous avons fait une proposition
d’interface au client dans le cahier des charges, cette interface a été validée
en même temps que le cahier des charges.
Au fur et à mesure de l’avancement sur le projet nous avons rencontré
divers problèmes. Les principaux problèmes étaient liés à l’organisation et en
particulier aux disponibilités de chacun. En effet, le but de ce projet était
en quelque sorte de nous confronter à des situations que nous allons tous
rencontrer quand nous serons dans le monde du travail. Ce projet nous demandait
donc de travailler en groupe, groupe formé aléatoirement et donc pas composé de
personne avec qui on a l’habitude de travailler. Nous avons donc dû nous
adapter aux différentes méthodes de chacun, apprendre à travailler ensemble, à
être à l’écoute des autres personnes du groupe.
Cette partie ne nous a pas posé de problème, l’entente dans le groupe a
dans l’ensemble été plutôt bonne et tout le monde a su écouter et prendre en
compte les remarques et les opinions de chacun.
Cependant, le groupe étant constitué de personnes issues des différentes
filières du DESS, nous avons été confrontés à des problèmes d’organisations. En
effet, l’aménagement de plages de travail en groupe ou en sous-groupes a été
difficile, et particulièrement sur la fin du projet, les personnes du groupe
ayant de nombreux autres projets à gérer dans les matières de leurs sections
respectives. Dans une entreprise, les employés sont très souvent amenés à
travailler sur différents projets en même temps. Le nombre de projets est
toutefois limité et si les équipes ne peuvent gérer tous les projets, alors
l’entreprise embauche ou refuse de travailler sur de nouveaux projets.
Ce problème d’organisation s’est vite fait ressentir. En effet, les
différents packages du projet étant relativement liés, lorsqu’une personne
prenait du retard dans sa partie, les autres personnes du groupe ne pouvaient
plus avancer. Ce problème peut se constater facilement sur l’échéancier ainsi
que sur le cahier des charges. En effet, un premier échéancier a été fait,
lorsqu’on étudie celui-ci, on se rend compte que les délais n’ont absolument
pas été respectés. En ce qui concerne le premier échéancier, l’erreur que nous
avons commise a été de ne pas prendre réellement en compte les autres projets
que chacun devait gérer en parallèle. Nous avons ressenti la difficulté de
construire un échéancier à moyen voire long terme. Nous avons donc été amenés à
reprendre notre échéancier et à en créer un nouveau plus réaliste et que nous
nous sommes efforcés de suivre.
Au niveau du cahier des charges, nous avons également eu des problèmes. En
effet, nous avons été relativement ambitieux lors de la définition de celui-ci.
Nous avions prévu d’utiliser certaines technologies que nous avons dû
abandonner par la suite pour des raisons de temps. Nous pouvons par exemple
citer le cas de Corba. Nous comptions effectivement utiliser Corba, or cela
s’est avéré plus compliqué que prévu. Bien que nous ayons fait des études de
faisabilité, nous avons été obligés de revoir notre jugement et donc de trouver
une solution de rechange afin de pouvoir tenir les délais.