Ø créer une UD de type «Affichage», de type « Impression », de type « Impression Liste », de type « Message », de type « Message d’Erreur », de type « Affichage » , de type « Affichage Liste », de type « Sous-SNI »,

Ø modifier une UD de type «Affichage», de type « Impression », de type « Impression Liste », de type « Message », de type « Message d’Erreur », de type « Affichage » , de type « Affichage Liste », de type « Sous-SNI »,

Ø « créer une Liaison», « modifier une Liaison », «supprimer une Liaison »,

ont été scénarisés et réalisés. (voir scénarios et diagrammes d’interactions correspondants).

· Les fonctionnalités supplémentaires « sélection d’un élément du SNI», « Drag & Drop (Glisser / Déposer) d’un élément du SNI », « interface multi-documents », « défilement du graphe » (scroll bars), ont été implémentées. Une attention toute particulière a été portée à la généricité de sélection ou u Glisser /Déposer notamment, afin d’être utilisable indifféremment pour tous les types d’UD ou pour les Liaisons (voir la première version fonctionnelle de SNIper).

· Le modèle de conception et l’architecture ont été mis à jour avec les nouveaux composants déduits de ces nouveaux cas d’utilisation et fonctionnalités supplémentaires. (voir le Document d’Architecture Logicielle v1.1 et le modèle de Conception v1.0).

· La première version fonctionnelle de SNIper, implémentant les nouveaux cas d’utilisation et les fonctionnalités supplémentaires définies plus haut, a été développée puis testée sur plate-forme Windows et sur les machines Unix du CICT (Telline et Salines). Les temps de réponse et les performances générales sont tout a fait correctes, même si on peut constater quelques ralentissements lors des manipulations des objets. Le logiciel est néanmoins parfaitement utilisable sur ces plate-formes.

(voir plan de tests IT2)

· Le codage de cette version de SNIper, basée sur l’architecture définie lors de l’itération précédente, n’a nécessité que peu ou pas de modification du code existant. Cela signifie que les choix d’utilisation d’interfaces et classes abstraites, de code générique, etc., ont été judicieux.

· Enfin, l’utilisation des services offerts par le site Internet SourceForge, et ceux de gestion de configuration en particulier (CVS), ont été une réussite, malgré une mise en route plus longue que prévue, due en particulier aux difficultés d’appropriation de l’outil par les licences ISI.

3. Concordance au plan d’itération

3.1 Objectifs non atteints

Le projet a pris du retard par rapport aux plannings. Dès lors il a fallu revoir les objectifs de l’itération :

· L’UD de type « Menu » est peut être l’UD la plus complexe à modéliser. Pour ne pas perdre trop de temps, il a été décidé de reporter à la prochaine itération la réalisation des cas d’utilisation concernant cette UD (créer / modifier / supprimer une UD de type « Menu »).

· Les fonctionnalités supplémentaires : « undo/redo » (annuler/refaire), fonctions de zoom sur graphe ou Copier/Couper/Coller des éléments du SNI n’ont pas été conçues. Des recherches ont tout de même été faites sur les différentes possibilités d’implémentation possibles.

· Le cas d’utilisation « imprimer un SNI », bien qu’étant un objectif prioritaire depuis l’IT1, n’a toujours pas été implémenté. La plate-forme Java ne propose pas en effet de système simple pour l’impression, et malgré des recherches approfondies sur Internet et auprès des enseignants de l’IUP, les résultats de nos essais d’impression sont très aléatoires et en général ne sont pas d’une qualité acceptable. Dès le début de la prochaine itération, une équipe de développeurs devra se consacrer entièrement à ce problème.

3.2 Retards par rapport aux plannings

Cette itération a duré deux semaines de plus que ce qui était prévu. Ces retards peuvent s’expliquer par plusieurs facteurs :

· Le temps d’adaptation et d’appropriation du projet par les nouveaux intervenants (les étudiants de licence) a été grandement sous-estimé.

· Le manque de créneaux horaires communs aux licences et maîtrises ISI n’a pas permis un véritable encadrement des nouveaux intervenants et a donc contribué au démarrage poussif de l’itération.

· Les activités ont peut être été mal réparties entre les différents acteurs : le travail a réaliser a paru un peu flou aux étudiants de licence.

3.3 Concordance charges évaluées / charges effectives

Remarques : les charges correspondent à la somme des charges des 9 participants. Et dans le cas où deux personnes ont travaillé sur la même tâche ensemble, le charge de cette activité est multipliée par deux

Groupe d’Activités	Total Réel	Total Estimé (dans le Plan d’IT1)
Spécifier le logiciel	4h30	20h
Affiner architecture	0h	1h
Analyser le comportement	15h	20h
Concevoir les composants	19h30	15h
Coder la 1^ère version fonctionnelle	60h30	50h
Tester la 1^ère version fonctionnelle		8h
Gérer le projet / Gérer l’itération 2	(44h30)	-
Définir objectifs itération suivante	1h	2h
Finir l’itération 2	1h	2h
Gérer le processus	35h	1h
	136h30	119h

Remarques :

· Toutes les charges concernant la gestion de projet, notamment les réunions, n’avaient pas été évaluées. C’est la raison pour laquelle elles apparaissent entre parenthèses et ne sont pas comptabilisées.

· La configuration des outils CVS et JBuilder pour les membres du projet n’avait, à tort, pas été estimée.

Conclusion sur les charges :

Compte tenu des fautes d’estimations du plan d’itération et de la réévaluation des objectifs en cours de l’itération, il est difficile de tirer des enseignements de cette itération. Néanmoins, on peut remarquer que le temps passé à l’appropriation d’outils comme CVS (gestion de processus) permettra un gain de temps dans les prochaines itérations, tant au niveau de la gestion de configuration qu’au niveau de la communication interne, et apportera à l’ensemble de l’équipe un bénéfice pédagogique.