GUIModeler - SNIper
Plan de développement
logiciel
Version <1.3>
Historique des révisions
|
Date |
Version |
Description |
Auteur |
|
19/10/2001 |
1.0 |
Création |
ISI3_BE1 |
|
04/12/2001 |
1.1 |
Attribution des rôles
des 2° années |
ISI3_BE1 |
|
30/01/2002 |
1.2 |
Description du
fonctionnement de SourceForge, et de son utilisation dans le cadre de SNIper |
ISI3_BE1 |
|
18/02/2002 |
1.3 |
Mise à jour des
plannings et des objectifs en fonction des retards accumulés, et du travail
effectué. |
ISI3_BE1 |
Table des matières
1. Introduction 4
1.1 Objectif 4
1.2 Portée 4
1.3 Références 4
2. Vue d’ensemble du projet 4
2.1 But du projet, portée, et objectifs 4
2.2 Hypothèses et contraintes 4
2.3 Evolution du plan de développement logiciel 4
3. Organisation de projet 4
3.1 Structure de l’organisation 4
3.2 Rôles et Responsabilités 5
4. Processus de gestion 5
4.1 Estimations de projet 5
4.2 Plan de projet 5
4.2.1 Plan de Phase 5
4.2.2 Objectifs des itérations 6
4.2.3 Livraisons 6
4.2.4 Calendrier de projet 7
4.3 Plans d’itérations 7
5. Plans Techniques du
processus 7
5.1 Plan du cycle de vie 7
5.2 Méthodes, Outils, et Techniques 7
5.2.1 Utilisation des services SourceForge 7
Plan de développement logiciel
L'objectif du
plan de développement logiciel est de réunir les informations nécessaires au
contrôle du projet. Il décrit l'approche du développement du logiciel et est un
plan haut-niveau généré et utilisé par les gestionnaires pour diriger l'effort
de développement.
Ce
document s’adresse à tous les intervenants du projet, ainsi qu’au client.
·
Le Plan de cycle de
vie v1.0
·
Le processus PILPOIL
(www.aubryconseil.com/pilpoil)
·
Document Vision v1.0
·
Le Glossaire v.1.0
peut être utile pour la compréhension de certains termes propres au domaine
métier.
Le projet
GUI Modeler (Graphic User Interface Modeler = modéliseur d’interface graphique)
vise à créer une suite d’outils de conception et de génération
d’interfaces graphiques basées sur la méthode SNI/SEF. L’utilisateur doit ainsi
pouvoir créer des diagrammes SNI, des diagrammes SEF, et obtenir le code de
l’interface correspondant aux schémas.
Le projet sera réalisé en plusieurs années, avec différentes équipes de conception et de développement. La première partie du projet, celle qui nous concerne ici, consiste à réaliser SNIper, l’éditeur SNI, ainsi que les fonctions d’impression papier et d’exportation des diagrammes produits.
Remarque :
pour une meilleure description du produit, se référer au document Vision.
Le projet doit être réalisé dans le temps imparti par l’IUP ISI, à savoir qu’il doit être terminé à la fin du mois de mars. De plus, le logiciel doit fonctionner et être développé avec le matériel disponible à l’Université : aucun coût supplémentaire n’est envisageable.
Les équipes sont constituées et fixées une fois pour toutes en tout début de projet.
Il évolue tout au long
du projet. Il est notamment mis à jour après chaque jalon de fin de phase.
L’équipe est composée de 4 étudiants en Licence et 4 étudiants en Maîtrise
à l’IUP ISI.
Il y a un responsable enseignant dans ce projet, et son suppléant.
|
Personne |
Rôle |
Mail |
|
Joël ALAUX |
Spécialiste IHM |
|
|
Spécialiste Outil |
||
|
Analyste / Concepteur |
||
|
François BLOQUE |
Chef de projet |
|
|
Analyste / Concepteur |
||
|
Sébastien GARY |
Architecte |
|
|
Analyste / Concepteur |
||
|
Antoine REGLAT |
Ingénieur processus |
|
|
Analyste / Concepteur |
||
|
Sébastien
MAZADE |
Analyste |
|
|
Concepteur |
||
|
Mathieu MEZIL |
Analyste |
|
|
Concepteur |
||
|
Marie-Julie PECOULT |
Analyste |
|
|
Concepteur |
||
|
Aurélie POUECH |
Analyste |
|
|
Concepteur |
||
|
Xavier TELLO |
Analyste |
|
|
Concepteur |
Les
enseignants responsables M.Cherbonneau et M.Aubry participent au projet en tant
que superviseurs mais leur charge n’est pas comptabilisée.
La charge de travail est estimée à 6 heures par personne et par semaine. La
date limite étant fixée au 15 mars (18 semaines de travail), la charge totale
est de 670 heures, sachant que tous les intervenants n’arrivent pas en même
temps sur le projet.
Le projet suit un développement itératif : à chaque fin d’itération est produite une version fonctionnelle du logiciel (sauf à la fin de la première itération). Cette méthode a pour but d’éliminer les risques le plus tôt possible. A chaque phase du processus de développement peuvent correspondre une ou plusieurs itérations. Ces choix sont présentés dans le tableau ci-dessous et justifiés dans le paragraphe 4.2.2.
|
Phase |
Itérations |
Début |
Fin |
Durée |
|
Lancement |
IT0 |
19/10/2001 |
28/11/2001 |
5 semaines |
|
Elaboration |
IT1 |
29/11/2001 |
11/01/2002 |
5 semaines |
|
Construction |
IT2 |
14/01/2002 |
22/02/2002 |
5 semaines |
|
IT3 |
25/02/2002 |
08/03/2002 |
2 semaines |
|
|
Transition |
IT4 |
11/03/2001 |
15/03/2002 |
1 semaine |
·
itération n°0: l’objectif est de définir les caractéristiques
du produit en fonction des besoins et exigences du client et des utilisateurs.
Les intervenants doivent se mettre d’accord sur la vision globale du produit,
tous les cas d’utilisation doivent être identifiées et une première étude de
l’architecture doit être réalisée, qui répondra au problème de représentation
des diagrammes sous forme de fichier. Cette itération recouvre toute la phase
de Lancement.
·
itération n°1: l’objectif de cette itération est de détailler
les spécifications de SNIper, mais plus précisément d’affiner et de stabiliser
l’architecture. Ainsi dans un premier temps, seuls sont spécifiés et réalisés les cas d’utilisation critiques
pour l’architecture : il s’agit de la création, de la sauvegarde, de
l’édition, de l’impression d’un diagramme et de la création d’une UD de type
« saisie ». Parallèlement, le spécialiste IHM doit définir
l’interface de SNIper. Les classes génériques et interfaces utilisées seront
décrites lors de cette itération, puisque
elles contribuent à définir l’architecture. Cette itération recouvre
toute la phase d’Elaboration.
·
itération n°2: les analystes doivent spécifier tous les cas
d’utilisation restants. Mais seuls les cas d’utilisation se référant à la
manipulation d’éléments simples du diagramme sont réalisés ici, à savoir la
création de tous les autres types d’UD simples, la modification ou la
suppression d’une UD (tous types), et la création, modification ou suppression
d’une liaison entre deux UD (tous types). La
première véritable étude des performances du logiciel se fait lors de
cette itération.
·
itération n°3: le but est de rajouter au logiciel toutes les
fonctions manquantes au niveau du dessin d’un diagramme SNI, c’est à dire
incorporer les UD de type « Sous-SNI », les compositions ou décompositions d’UD (tous types), et enfin l’utilisation des objets de type
Etiquette.
Les itérations 2 et 3 recouvrent le
phase de Construction.
·
itération n°4: il s’agit d’effectuer les tests de validation de
l’application et la livraison du logiciel.
Cette itération recouvre la phase de Transition.
Il a été choisi d’appliquer un développement de type itératif : par conséquent à chaque fin d’itération est produite une version fonctionnelle du logiciel, sauf à la fin de l’IT0 qui correspond à la phase de lancement.
|
Description |
Livraison du produit ? |
|
|
12 novembre 2001 |
Revue d’approbation |
Non |
|
28
novembre 2001 |
Jalon de fin de phase de lancement |
Non |
|
11
janvier 2002 |
Jalon de fin de phase d’élaboration |
Oui :
prototype de l’application |
|
22
février 2002 |
Revue de fin de l’itération 2 |
Oui :
première version fonctionnelle |
|
8 mars
2002 |
Jalon de fin de phase de Construction |
Oui :
version bêta de l’application (non recettée) |
|
15 mars
2001 |
Jalon de fin de phase de Transition, et revue de
fin de projet |
Oui :
version finale du logiciel |
Les équipes seront les équipes formées en début de projet et définies plus haut : deux équipes de 4 personnes. Aucune compétence supplémentaire n’est nécessaire, et les équipes ne peuvent être agrandies.
Il est possible que l’équipe de développement
n’est pas toutes les compétences nécessaires, notamment au niveau de la
maîtrise des outils et des langages de programmation : une rapide mise à
niveau sera alors envisageable avant la réalisation de la première mouture du
logiciel.
voir le Plan
d’Itération de chaque itération.
voir Plan de Cycle de Vie
du processus.
Le standard appliqué pour le codage de l’application est le guide de
programmation tel que défini par l’architecte.
Le site http://www.sourceforge.net/ offre librement et gratuitement tout un ensemble d’outils et de services aux développeurs sous réserve de s’inscrire et de créer un projet OpenSource, ne nécessitant aucune licence logicielle. Un compte a ainsi été crée sur ce site pour le projet SNIper et tous les étudiants participant y ont été ajouté. Voici le détail des services à utiliser :
SourceForge met à notre disposition un espace sur
ses serveurs Web. Celui-ci est accessible à l’adresse : http://isisniper.sourceforge.net.
Il contient les dernières versions des documents du projet téléchargeables (au
format Zip) ou directement
visualisables (pour certains) au format HTML.
·
Objectif : Compte-tenu de la difficulté de gérer les
fichiers sources au sein d’un groupe de 9 personnes, il apparaît nécessaire de
disposer d’un outil de gestion de version, c’est à dire un moyen de centraliser
les fichiers, et de pouvoir disposer des dernières versions à tout moment.
L’outil CVS rempli ces besoins.
·
Caractéristiques : Il se présente sous la forme d’une application
Client-Serveur (en ligne de commandes ou par le biais d’un client
graphique), permettant de déposer ou de
retirer des fichiers sur un serveur distant (hébergé par SourceForge), permet
de verrouiller un fichier pour ne le rendre modifiable que par un seul
développeur, etc. Il intègre aussi un vérificateur d’intégrité des fichiers qui
prévient l’utilisateur dans le cas où plusieurs personnes ont effectué des
modifications contradictoires sur un même fichier.
·
Application au
projet SNIper : A la fin de
chaque session de codage, le programmeur doit déposer ses nouveaux fichiers
sources sur le serveur CVS. Et de la même façon, au début de chaque nouvelle
session de codage, il doit avant toute chose récupérer les dernières versions
des sources.
L’utilisation de CVS et les différentes commandes sont décrites dans le document technique « Guide d'installation et d'utilisation de WinCVS v1.0 » du projet GUI Modeler-SNIper.
·
Objectif : réduire le nombre d’emails circulant entre les
participants au projet.
·
Caractéristiques : un module du site SourceForge est dédié à
l’identification et la publication des bogues rencontrés sur les différentes
versions du logiciel, par le biais d’un formulaire HTML.
·
Application au
projet SNIper : dès qu’un
des participants au projet relève et identifie un bogue dans lune des versions
de SNIper (prototype ou versions fonctionnelles) , il doit en faire part à
toute l’équipe sur le site SourceForge.
·
Objectif : faciliter et simplifier la communication entre
membres du projet, ainsi que permettre une traçabilité des tâches effectuées.
·
Caractéristiques : un module du site SourceForge permet à
l’administrateur d’affecter une activité particulière à un membre de l’équipe
projet, par le biais d’un formulaire HTML. Le système envoi alors
automatiquement un email à la ou les personnes concernées, qui doit à son tour
tenir au courant l’administrateur en
mettant à jour l’état de l’activité sur le site.
·
Application au
projet SNIper : en début de
semaine, le chef de projet affecte les tâches aux membres de l’équipe. Puis ceux-ci,
au fur et à mesure de leur travail, mettent à jour l’état de la tâche, tenant
ainsi informé le chef de projet sur
l’état d’avancement de SNIper.
·
Mailing-List : elle a été créée au cas où, mais rien ne justifie
son utilisation pour l’instant, le nombre de participants étant connu et figé.
·
Gestion de la
documentation : ce module du
site ne sera pas utilisé, parce que il n’est pas adapté au format des documents
produits pour le projet (Word, et Rose).
·
Forum : les membres du projet sont libres d’utiliser les
emails comme le forum pour leurs questions et remarques (sauf quand celles-ci
concernent les bogues : dans ce cas on utilise le service approprié).