· Le spécialiste outils a analysé la version du JDK disponible à l’UPS. C’est la version 1.3 qui convient parfaitement au développement de l’application, puisqu’elle offre les paquetages Swing, et Java2D.

· Les cas d’utilisation « créer une UD de type Saisie », « créer un diagramme SNI », « ouvrir un diagramme SNI », « sauvegarder un diagramme SNI », « fermer un diagramme SNI », ont été scénarisés et réalisés. (voir scénarios et diagrammes d’interactions correspondants).

· Les composants correspondants à ces cas d’utilisation ont été définis et une architecture a été fixée. Celle-ci décrit notamment les relations (services) entre ces composants, et avec les composants réutilisés (infra-structure). La solution adoptée concernant la gestion des fichiers est expliquée en détail (voir le Document d’Architecture Logicielle v1.1 et le modèle de Conception v1.0).

· L’interface utilisateur (IHM) a été spécifiée sous la forme d’une maquette statique (schéma PowerPoint).

· Enfin, un prototype, basé sur l’IHM et les composants définis plus tôt, a été développé, puis testé sur plate-forme Windows, ainsi que les machines Tgv et Telline de l’UPS. Les temps de réponse sont très satisfaisants sur Telline, mais inacceptables sur Tgv, rendant le logiciel définitivement inutilisable sur ce serveur. Les jeux de test et leurs résultats sont visibles dans le plan de tests IT1 v1.0.

· L’intégration des nouvelles ressources que sont les étudiants de licence s’est avérée positive. En effet ils se sont très rapidement familiariser avec le projet puisqu’ils ont pu lire les documents clés et participer à l’élaboration de l’IHM du produit dès le mois de décembre. Ils sont prêts pour débuter l’analyse des prochains cas d’utilisation.

3. Concordance au plan d’itération

3.1 Objectifs non atteints

Bien qu’étant un des objectifs de l’IT1, le cas d’utilisation « imprimer un SNI » n’a pas été spécifié, et n’a donc pas été réalisé ni implémenté, à cause du manque d’expertise sur la gestion de l’impression en Java au sein du groupe, et du manque de temps pour l’acquérir.

Il était prévu d’utiliser un outil de gestion de version (CVS) mais malgré plusieurs tentatives de configuration, il n’est toujours pas utilisable.

3.2 Concordance charges évaluées / charges effectives

Groupe d’Activité	ALAUX	BLOQUE	GARY	REGLAT	Total Réel	Total Estimé
Spécifier le logiciel	5h	4h	4h	3h	16h	10h
Définir l’IHM	3h			1h	4h	8h
Analyser le comportement	1h	2h30	1h	1h	5h30	8h
Concevoir les composants	6h	7h	4h30	3h	20h30	8h
Affiner l’architecture			2h		2h	4h
Coder le prototype	10h	10h	11h30	6h30	38h	20h
Tester le prototype	1h		1h	1h	3h	4h
Gérer le projet / Gérer l’itération 1	2h	3h	2h	2h	11h	-
Définir objectifs itération suivante		1h30			1h30	2h
Finir l’itération / Finir la phase		2h			2h	4h
Gérer le processus		30min	8h	4h	12h30	4h
				Total IT1 :	116h	72h

Remarque : si le groupe d’activité « Gérer le processus » occupe un grand nombre d’heures, c’est dû aux essais de configuration de l’outil de gestion de version CVS (Concurrent Version System).

Conclusion sur les charges :

Le temps de travail en groupe a été sous-évalué. Il a amené à une surcharge au niveau des plannings établis en début d’itération. Ce point sera à prendre en compte et à améliorer lors des plannings des prochaines itérations.