OWEP Bilan de projet

IUP ISI 2004-2005 V1.0

 Table des matières
HISTORIQUE DES RÉVISIONS.........................................................................................................................3
TABLE DES MATIÈRES......................................................................................................................................4
1 INTRODUCTION................................................................................................................................................5
1.1 OBJECTIF.........................................................................................................................................................5
1.2 PORTÉE...........................................................................................................................................................5
1.3 RÉFÉRENCES...................................................................................................................................................5
2 FONCTIONNALITÉS DU LOGICIEL.............................................................................................................6
2.1 OBJECTIF DU PROJET.......................................................................................................................................6
2.2 INTERVENANTS...............................................................................................................................................6
2.3 COUVERTURE DES EXIGENCES........................................................................................................................6
2.4 LISTE DES BUGS CONNUS................................................................................................................................6
2.5 EVOLUTIONS FUTURES....................................................................................................................................7
3 GESTION DU PROJET......................................................................................................................................8
3.1 PLANNING DU PROJET.....................................................................................................................................8
3.2 EXPLICATION DES ÉCARTS..............................................................................................................................8
4 BILAN TECHNIQUE..........................................................................................................................................9
4.1 ARCHITECTURE MVC.....................................................................................................................................9
4.2 J2EE................................................................................................................................................................9
4.3 CASTOR...........................................................................................................................................................9
4.4 INTÉGRATION DES 2ÈME ANNÉE........................................................................................................................9
5 BILAN HUMAIN...............................................................................................................................................11
5.1 COMMUNICATION AVEC LES CLIENTS...........................................................................................................11
5.2 COMMUNICATION AVEC LES AUTRES GROUPES............................................................................................11
5.3 COMMUNICATION AU SEIN DE L’ÉQUIPE.......................................................................................................12
6 BILAN DU PROJET..........................................................................................................................................13
6.1 GESTION DU PROJET......................................................................................................................................13
6.2 EVALUATION DES CHARGES..........................................................................................................................13
7 Conclusion............................................................................................................................................................14
 1. Introduction Bilan de projet5

1 Introduction

1.1 Objectif
Ce document a pour but de dresser un bilan général du projet OWEP, d’un point de
vue technique et humain. Il présente une analyse succincte des différents problèmes
rencontrés et une réflexion sur la manière dont ils auraient pu être résolus.

1.2 Portée
Ce document est destiné à tous les intervenants du projet (membres de l’équipe de
développement, superviseurs, clients).

1.3 Références
Document Vision
Plan de développement Logiciel
Plan des itérations 1 à 7
Evaluation des itérations 1 à 7

IUP ISI 2004-2005 OWEP Page 3 / 12

 2. Fonctionnalités du logiciel Bilan de projet5

2 Fonctionnalités du logiciel

2.1 Objectif du projet

L’objectif du logiciel OWEP était de développer un système distribué de gestion de
workflow pour une équipe de projet (cf. Document Vision). Il devait fournir à une équipe
et son chef de projet un moyen d’accéder aux informations relatives à l’exécution d’un
processus de projet et de suivre son avancement.

Le projet OWEP devait offrir à tous les membres d’une équipe un accès
personnalisé aux informations d’un processus. Il devait indiquer les activités à réaliser
et fournir les guides ou tout autre document nécessaire à l’avancement d’un projet.
OWEP devait également permettre de suivre la progression d’un projet grâce au
chronométrage, pour chaque collaborateur, de ses tâches.

OWEP devait constituer un système distribué accessible par un réseau Intranet,

afin de faciliter l’accès à l’information et améliorer l’efficacité du suivi de projet.

2.2 Intervenants
L’équipe de développement était constituée de 5 étudiants de Master1 de l’IUP ISI
(Yann Albac, Laure Bosse, Victor Nancy, Rémi Joffre, Sylvain Ratabouil) et de 4
étudiants de Licence 3 (Etienne Allogo, Gohar Avestisyan, Pélagie Léoué, Olivier Tankoano).

Les clients étaient représentés par les enseignants et intervenants Mr Massie, et

Mr Cherbonneau.

2.3 Couverture des exigences

Le logiciel OWEP implémente la grande majorité des exigences qui étaient
demandées dans le document vision et le référentiel des exigences, à l’exception des
deux exigences suivantes :

Gérer l’historique des artefacts

Messagerie

Certaines exigences non fonctionnelles n’ont pu être réalisées ou vérifiées :

Possibilité de connexions de la part de 20 utilisateurs

Temps de réponse devra être inférieur à 500 millisecondes
Manuel Utilisateur

2.4 Liste des bugs connus

La technologie Castor présente le défaut de charger beaucoup d’objets en
mémoire. Si la mémoire allouée n’est pas assez importante (cf. Guide d’installation), des
erreurs peuvent survenir (Exception Heap Out of Memory).

IUP ISI 2004-2005 OWEP Page 4 / 12

 2. Fonctionnalités du logiciel Bilan de projet5

2.5 Evolutions futures

Peu de retours utilisateurs ont pu être réalisés au moment de la rédaction de ce
document. Cette liste n’est donc pas complète mais on peu d’ores et déjà proposer
plusieurs évolutions possibles :

Implémenter la messagerie de sorte à permettre une communication

centralisée et aisée de tous les membres de l’équipe
Gérer l’historique des artefacts
Intégration des sites générés par les autres outils de la suite APES

IUP ISI 2004-2005 OWEP Page 5 / 12

 3. Gestion du projet Bilan de projet

3 Gestion du projet

3.1 Planning du projet

Le projet a démarré le 29 septembre 2004 et s’est terminé le 25 Mars 2005. Les
Licence 3 ISI ont été intégrées à partir de l’itération 5. Voici un récapitulatif des dates
et des charges pour chaque itération :

Phase Itérations Début réel Fin réelle Durée Heures Heures

semaine* prévues réelles
Lancement IT1 08/10/2004 29/10/2004 3 94 107.5
Elaboration IT2 30/10/2004 24/11/2004 3 143.5 137.5
IT3 25/11/2004 10/12/2004 2 105 128
Construction IT4 11/12/2004 18/01/2005 3 145 181
IT5 19/01/2005 11/02/2005 3 119 134.5
IT6 12/02/2005 28/02/2005 3 133 140
Transition IT7 04/03/2005 25/03/2005 3 120 127
Total 08/10/2004 25/03/2005 20 859.5 955.5

Les durées en semaines sont les durées effectives (c'est-à-dire travaillées) de l’itération. Les heures prévues et
réelles correspondent à la somme des heures de tous les membres de l’équipe OWEP.

3.2 Explication des écarts

Le travail moyen par personne et par semaine est de 9h en moyenne (179h par
personne sur tout le projet). On peut cependant penser que ce temps est légèrement
minoré par rapport à la réalité du fait de la difficulté à calculer précisément les durées
de formation, ou à régler des problèmes techniques pointus.

Le dépassement d’heure n’est pas un reflet très pertinent du projet. En effet

certaines tâches ont du être reportées vers des itérations ultérieures. La plupart des
écarts (même s’il ne sont donc pas toujours visible), sont provoqués par la
méconnaissance des technologies (par exemple la technologie Castor) qui a impliqué un
temps de développement plus long (notamment IT4 et 5).

IUP ISI 2004-2005 OWEP Page 6 / 12

 4. Bilan technique Bilan de projet

4 Bilan technique

Le projet OWEP a été l’occasion d’étudier de nouvelles technologies que nous ne

connaissions pas au début de l’année. Ceci fut à la fois un des aspects les plus
intéressant et les plus délicat de notre BE.

4.1 Architecture MVC

Ce BE a été l’occasion d’acquérir une meilleure maîtrise de l’architecture logicielle
et plus particulièrement de l’architecture MVC. Nous avons du concevoir, du début à la
fin, une application complexe et conséquente puis valider son architecture. Nous avons
pu découvrir l’impact (difficilement réversible) que peut avoir une décision prise en
début de projet sur une architecture ou une conception (comme le choix de la
technologie Castor permettant d’insérer et de récupérer des données de la base de
données).

4.2 J2EE
La technologie J2EE, qui nous était inconnue en début d’année scolaire, a été
étudiée en parallèle des premières itérations du projet. Cela nous a permis d’approfondir
et de mieux maîtriser cette technologie fort complexe. Cependant, cela a eu un
retentissement sur la mise au point de l’architecture. Nous avons eu le choix entre
plusieurs technologies pour réaliser ce projet (entre autre Struts, JSF ou les JSP de
base). Du fait de la forte complexité et de la longue courbe d’apprentissage
(supplémentaire) des deux technologies que sont Struts et JSF, le choix précautionneux
a été fait de prendre la technologie de base JSP. Ce choix nous a obligé à concevoir et à
programmer des éléments supplémentaires qui auraient pu être évités avec d’autres
technologies (validation, entrées sorties de données, etc.), et a donc nécessité du temps
de développement supplémentaire. Mais ce choix a permis de limiter les risques liés à
une technologie mal maîtrisée, et nous semble donc avoir été judicieux.

4.3 Castor
Ces difficultés de maîtrise apparaissent plus évident au regard de la difficulté que
nous avons eu à maîtriser la technologie Castor, pour la persistance Modèle/Base de
données. Castor est en effet peu documenté, avec peu de référence sur Internet. De
nombreuses difficultés, dues en partie à une mauvaise utilisation de Castor, sont
survenues et leurs corrections n’ont été que tardives (IT5 et IT6). Des solutions
temporaires ont du être employées (utilisation de JDBC) rendant plus difficile la
création d’une version facilement déployable d’OWEP.

4.4 Intégration des 2ème année

Une des difficultés rencontrées au cours du projet a été l’intégration des Licence
3 du fait de leur faible maîtrise des outils (qui leur étaient totalement inconnus
initialement). Une solution à ce problème aurait pu être, par exemple, de travailler

IUP ISI 2004-2005 OWEP Page 7 / 12

 4. Bilan technique Bilan de projet

directement en binôme avec eux. Cependant, au vu des emplois du temps discordant, cela
était difficile à réaliser. De plus nous ne pouvions travailler ensemble le Vendredi après-
midi durant les créneaux prévues à cet effet du fait de l’absence de comptes de travail
et d’outils sur les postes PC (compte Tomcat et MySQL).

IUP ISI 2004-2005 OWEP Page 8 / 12

 5. Bilan humain Bilan de projet

5 Bilan humain

Ce projet fut extrêmement intéressant pour plusieurs raisons : premièrement il

s’est déroulé sur une longue période (allant de la phase d’élaboration jusqu’à la recette)
et nous a donc permis de découvrir les difficultés liées à la communication au sein de
l’équipe et avec les clients.

5.1 Communication avec les clients

Un des points qui a été délicat à gérer a été le nombre important d’itérations. Ceci
a pour avantage d’avoir un retour plus fréquent de la part du client. En effet, faire de
nombreuses itérations implique de préparer les revues et toutes les documentations
nécessaires (PDL, Bilan, etc.). De plus, cela implique d’envoyer les documents à l’avance
(environ 4 jours avant la revue) sur des itérations plutôt courtes (3 semaines). En phase
de lancement et d’élaboration, ce choix nous semblait justifié. En revanche, en phase de
construction, cette approche impliquait de mettre en place une « logistique » parfois
trop lourde (préparation des documents, etc.) alors que de simples « points clés », plus
légers mais plus nombreux auraient peut être été plus adaptés (notamment pour avoir
plus fréquemment des retours sur l’application de la part des clients et aller plus à
l’essentiel).

Concernant les retours d’informations en provenance des clients, un système de

gestion de demande de modifications (Nouveau document ou logiciel du type
Bugzilla/Mantis) aurait pu être utile. En effet la traçabilité des modifications
demandées ou des points en suspend était limité car présente uniquement dans les bilan
de revues. Par ailleurs, peu de retours clients ont pu avoir lieu. Ceci est dû aux
problèmes d’environnements (compte CICT, …) et techniques (Castor, …) qui ont rendu
difficile l’installation et le déploiement de l’outil chez le client de l’outil.

5.2 Communication avec les autres groupes

La communication avec les autres groupes, pour gérer les interfaces, a été
également un point très délicat. On peut notamment regretter la difficulté des deux
groupes SOUPEX et OWEP à trouver un modèle commun et cohérent. « Mutualiser » les
modèles (sur tous les projets) aurait d’ailleurs été une excellente solution.
Malheureusement elle était trop difficile à mettre en place après que les choix
architecturaux aient été définis.

La communication avec les autres groupes sur le format XML en export d’OWEP a
été également un point difficile. L’information concernant les modifications ayant eu du
mal à remonter. Sur l’ensemble des projets en général, on peut regretter qu’il n’y ait pas
eu de centralisation de ces informations et de leur gestion (autour d’une personne ou
groupe qui s’en occuperait).

IUP ISI 2004-2005 OWEP Page 9 / 12

 5. Bilan humain Bilan de projet

5.3 Communication au sein de l’équipe

Nous avons réalisé à quel point la communication est importante sur un projet, en
particulier lorsque le développement est « réparti » entre plusieurs personnes qui
travaillent en des endroits différents. La communication par mailing-list, régulière, nous
a semblé très satisfaisante de ce point de vue.

Les outils de gestion de configuration (CVS et SVN), nous sont apparus comme des
outils de « Communication » critique sur un projet. Ils nous ont permis d’intégrer les
modifications avec plus de facilité et surtout de rapidité. La facilité à intégrer est
d’ailleurs proportionnelle à la régularité des validations. Les personnes qui ne disposaient
pas d’Internet et ne pouvaient mettre à jour leur version mettaient plus de temps à
intégrer (notamment à cause de modifications dans des classes communes).

IUP ISI 2004-2005 OWEP Page 10 / 12

 6. Bilan du projet Bilan de projet

6 Bilan du projet

6.1 Gestion du projet

Ce BE a été pour nous une occasion unique de mettre en œuvre un grand nombre de
méthodes de gestion de projets apprises en cours. Nous avons également pu apprécier à
quel point la rigueur et la concision sont importantes, notamment lors de la rédaction de
documents.

Les phases de tests ont été plus limitées que prévue (pas de tests unitaires par
exemple). Ceci s’explique par le fait que OWEP est une application conséquente,
exploitant une technologie délicate, qui a nécessité du temps et a été difficile à mettre
au point (en particulier avec Castor). Des tests concrets de cas d’utilisation complet
n’ont pu être réalisé que tardivement dans le cycle de vie du projet.

L’ensemble des membres du projet estime, cependant, que la charge de travail était
relativement conséquente du fait de la taille du projet et de la difficile maîtrise des
technologies utilisées.

6.2 Evaluation des charges

Le suivi d’avancement a été (surtout en raison de notre sujet) un point important
dans le domaine de la gestion de projet. Nous avons découvert la grande utilité de ces
informations pour un chef de projet. L’envoi régulier des heures de chaque membre
(chaque semaine) a permis de connaître avec une relative précision de l’avancement l’état
du projet. C’est d’ailleurs à cette occasion que nous avons compris l’intérêt d’un outil
comme OWEP (qui permet d’automatiser ce processus).

Les évaluations se sont d’ailleurs révélées, au fur et à mesure, plus précises bien
que parfois difficile du fait du manque de connaissance des technologies employées
(contrairement aux projets qui utilisaient une technologie Swing plus « classique »).

IUP ISI 2004-2005 OWEP Page 11 / 12

 7. Conclusion Bilan de projet

7 Conclusion

Ce bureau d’étude a été une excellente expérience pour tous les membres de
l’équipe OWEP. Nous avons chacun énormément appris sur « l’art du développement
industriel ».

Nous sommes satisfait d’avoir pu couvrir la majeure partie des exigences malgré le
temps limité dont nous disposions, qui nous a paru très court. L’architecture est restée
relativement stable tout au long du projet (malgré quelques difficultés de maîtrise des
technologies).

Un point important qui doit être tiré sur ce projet est l’absolue nécessité de
mettre en œuvre des créneaux et des espaces de travail commun pour les groupes de BE
(2ème et 3ème années).

IUP ISI 2004-2005 OWEP Page 12 / 12