Historique des révisions

Date	Version	Description	Auteur
15/11/2001	1.0	Création	ISI3_BE1
07/01/2002	1.1	Description des disciplines Implémentation et Tests	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 globale du processus 4

2.1 Description 4

2.2 Disciplines 4

2.3 Configuration des disciplines 5

2.3.1 Produits de travail 5

2.3.2 Notes sur les produits de travail 6

3. Disciplines 6

3.1 Expression des exigences 6

3.1.1 Objectif de la discipline 6

3.1.2 Produits de travail 6

3.1.3 Notes sur les produits de travail 6

3.2 Analyse & conception 7

3.2.1 Objectif de la discipline 7

3.2.2 Produits de travail 7

3.2.3 Notes sur les produits de travail 7

3.3 Implémentation 8

3.3.1 Objectif de la discipline 8

3.3.2 Produits de Travail 8

3.3.3 Notes sur les produits de travail 8

3.4 Tests 8

3.4.1 Objectif de la discipline 8

3.4.2 Produits de travail 8

3.4.3 Notes sur les produits de travail 8

3.5 Gestion de projet 8

3.5.1 Objectif de la discipline 8

3.5.2 Produits de travail 9

3.5.3 Notes sur les produits de travail 9

3.6 Gestion de processus 10

3.6.1 Objectif de la discipline 10

3.6.2 Produits de travail 10

3.6.3 Notes sur les produits de travail 10

Plan du cycle de vie

1. Introduction

Le plan du cycle de vie décrit le processus de développement adopté pour conduire le projet GUI Modeler – module SNIper.

1.1 Objectif

L'objectif du plan de cycle de vie est de définir la configuration du processus pour le projet GUI Modeler – module SNIper. Ce processus est inspiré du processus PILPOIL. Ce document présente les parties du processus PILPOIL qui sont prises en compte pour le projet, les parties qui ne le sont pas, et les parties adaptées.

1.2 Portée

Le processus décrit dans ce document est spécifiquement adapté au projet GUI Modeler – module SNIper et concerne l’ensemble des membres du projet. En revanche, il peut servir de modèle pour les modules développés dans le futur (notamment pour SEFcontrol).

Le plan de cycle de vie est créé très tôt au début de la phase de lancement. Il est remis à jour au cours du projet si nécessaire.

1.3 Références

Processus PILPOIL d’ingénierie du logiciel, version adaptée du Rational Unified Process (RUP), C. Aubry

2. Vue globale du processus

2.1 Description

La vue globale du processus présente les disciplines gérées par le plan de cycle de vie, ainsi que les techniques employés pour décrire chaque discipline du processus dans la section 3.

2.2 Disciplines

Dans cette version du plan de cycle de vie, seules quatre disciplines du processus PILPOIL sont représentées. Les disciplines prévues mais non encore gérées apparaissent en grisées dans le tableau ci-dessous.

*Configuration de la discipline* (du plan de cycle de vie)	*Discipline de base* (ce qui est prévu dans le PILPOIL)	Commentaires
Expression des exigences	Discipline PILPOIL : Expression des exigences	Comme défini dans le PILPOIL
Analyse et conception	Discipline PILPOIL : Analyse et conception	Production d'un sous-ensemble
Implémentation	pas dans le PILPOIL
Test	pas dans le PILPOIL
Déploiement	pas dans le PILPOIL	Pas encore traité dans ce document
Gestion de projet	Discipline PILPOIL : Gestion de projet	Production d'un sous-ensemble
Gestion de processus	Discipline PILPOIL : Gestion de processus	L'adaptation fait l'objet de ce plan de cycle de vie.

2.3 Configuration des disciplines

La section 3 présente les produits de travail utilisés dans chaque discipline du processus.

2.3.1 Produits de travail

Chaque produit est représenté par une ligne du tableau suivant :

*Produit*	*Comment l’utiliser ?*				*Statut*	*Outils employés*	*Plans types / Exemples*
*Produit*	*Lancem^t*	*Elaborat°*	*Construct°*	*Transit°*	*Statut*	*Outils employés*	*Plans types / Exemples*

2.3.1.1 Explications sur le tableau précédent

*Nom de la colonne*	*Objectif*	*Contenu / Commentaires*
Produit	Le nom du produit de travail.	Une référence au produit de travail dans le processus PILPOIL
Comment l’utiliser ?	Décrire comment le produit est utilisé tout au long du cycle de vie.	Décider de l’utilisation du produit au cours de la phase : · Doit (impérativement être utilisé) · Peut (éventuellement être utilisé) · Case vide (ne sera pas utilisé) Un astérisque associé au mot clé 'Doit' ou 'Peut' signifie que le produit est créé ou mis à jour (selon s’il s’agit du premier astérisque qui apparaît pour ce produit ou non); s’il n'y a pas d'astérisque, le produit est seulement en consultation.
Statut	Décider du statut du produit de travail.	· Formel-Externe · Formel-Interne · Informel · Aucun
Outils employés	Définition de l’outil utilisé pour créer le produit.	Références aux détails des outils utilisés pour créer et maintenir les produits de travail.
Plans types/ Exemples	Les plans types à utiliser et les exemples de produits construits à partir de ces plans types.	Références aux plans types et exemples. On peut faire référence à des plans types ou des exemples du PILPOIL ou bien des plans types et des exemples locaux. Cette colonne peut également contenir des références à des produits de travail courant qui peuvent fournir une aide complémentaire aux membres du projet.

Statut du produit	Explication	*Commentaires*
Formel – externe	Le produit arrivé à un jalon spécifique est une partie de la distribution finale et nécessite l’approbation du client.	Par exemple, le document Vision est un produit formel – externe, car il doit être présenté et approuvé par le client lors de la revue de fin de phase d’élaboration.
Formel –Interne	Le produit est approuvé par les membres du projet lors d’une revue interne.	Par exemple, le modèle de conception est un produit formel – externe.
Informel	Le produit est utilisé lors de revues internes, mais n’a pas besoin d’être approuvé formellement par les membres du projet.	Le produit est créé puis mis à jour tout au long du projet. Il s’agit le plus souvent d’un produit inclus dans un produit formel plus important. Le sous-système de conception est un exemple typique d’un produit qui n’est pas approuvé formellement.
Aucun	Le produit n’est pas forcément utilisé lors de revues, et il n’a pas besoin d’être approuvé.	Le produit est utilisé comme support de travail. Il est souvent temporaire et aide à une meilleure compréhension par les membres du projet de certains autres produits.

2.3.2 Notes sur les produits de travail

Le tableau ci-dessous est disponible pour chaque discipline. Il contient d’une part la liste de tous les produits proposés par le processus PILPOIL et non utilisés dans le cycle de vie, d’autre part des modifications ou des renseignements supplémentaires sur des produits utilisés. Tous les choix doivent être justifiés dans la colonne Raison.

*Produit*	*Notes*	*Raison*

3. Disciplines

3.1 Expression des exigences

3.1.1 Objectif de la discipline

· se mettre d'accord avec le client et les membres du projet sur ce que doit faire le logiciel,

· fournir aux développeurs une bonne compréhension des besoins du logiciel,

· définir les limites du logiciel,

· fournir une base pour la planification du contenu technique des itérations,

· fournir une base à l'estimation des coûts et délais pour le développement du logiciel,

· définir l'interface utilisateur, en se concentrant sur les besoins utilisateurs.

3.1.2 Produits de travail

*Produit*	*Comment l’utiliser ?*				*Statut*	*Outils nécessaires*	*Plans types /* *Exemples*
*Produit*	*Lancem^t*	*Elaborat°*	*Construct°*	*Transit°*	*Statut*	*Outils nécessaires*	*Plans types /* *Exemples*
Vision	Doit *	Doit	Doit	Doit	Formel-Externe	Word	rup_vision.dot
Modèle de cas d’utilisation	Doit *	Peut *			Formel-Externe	Rose + Word
Spécification de cas d’utilisation	Peut *	Doit *	Peut *		Formel-Externe	Word	rup_ucspec.dot
Glossaire	Doit *	Doit	Doit	Doit	Formel-Interne	Word	rup_gloss.dot
Acteur	Doit *	Peut *	Doit	Doit	Informel	Rose
Modèle objet du domaine	Doit *	Doit *			Informel	Rose
Spécifications supplémentaires	Peut *	Doit *	Peut *	Doit	Formel-Externe	Word	rup_sspec.dot
Classe d’interface	Peut	Doit	Peut	Peut	Informel	Rose
Prototype de l’interface utilisateur		Doit *	Doit		Formel-Externe	Powerpoint, JAVA

3.1.3 Notes sur les produits de travail

*Produit*	*Notes*	*Raison*
Modèle de cas d’utilisation	Le produit doit être disponible au format HTML généré par l'outil WebPublisher de Rose.	Diffusion simplifiée
Paquetage de cas d’utilisation	Inclus dans le produit « Modèle de cas d’utilisation »	Allégement du processus
Scénarios des cas d'utilisation	Inclus dans le produit « Spécification de cas d’utilisation »	Allégement du processus
Prototype de l’IHM	L’interface est implémentée par le prototype

3.2 Analyse & conception

3.2.1 Objectif de la discipline

· Transformer les exigences exprimées en conception du système à réaliser.

· Elaborer une architecture robuste.

· Adapter la conception pour tenir compte de l'environnement d'implémentation.

3.2.2 Produits de travail

*Produit*	*Comment l’utiliser ?*				*Statut*	*Outils nécessaires*	*Plans types /* *Exemples*
*Produit*	*Lancem^t*	*Elaborat°*	*Construct°*	*Transit°*	*Statut*	*Outils nécessaires*	*Plans types /* *Exemples*
Réalisation de cas d’utilisation		Peut *	Doit *	Doit	informel	Rose
Document d’architecture logicielle	Doit *	Doit *	Doit *	Doit	Formel-Externe	Word	rup_sad .dot
Modèle de conception		Doit *	Doit *	Doit	Formel-Interne	Rose
Sous-système de conception		Peut *	Doit *	Doit	Informel	Rose
Paquetage de conception		Doit *	Doit *	Doit	Informel	Rose
Classe d’Interface	Peut *	Doit *	Doit	Doit	Informel	Rose
Classe de conception	Peut *	Doit *	Doit *	Doit	Informel	Rose

3.2.3 Notes sur les produits de travail

*Produit*	*Notes*	*Raison*
Modèle d’analyse	Inclus dans le produit « Modèle de conception »	Allégement du processus
Modèle de conception	Le produit doit être disponible au format HTML généré par l'outil WebPublisher de Rose.	Diffusion simplifiée
Classe d’analyse	Inclus dans le produit « Classe de conception »	Allégement du processus
Modèle de données	Non utilisé. L’organisation des données persistantes est gérée dans le produit « Document d’architecture logicielle »	Pas de structure de données lourde (base de données)
Modèle de déploiement	Non utilisé	Le système est simple, et sans distribution des traitements

3.3 Implémentation

3.3.1 Objectif de la discipline

· Mettre en œuvre ce qui a été conçu dans les autres disciplines

· Disposer d’une version du produit à la fin de chaque itération (sauf la première)

3.3.2 Produits de Travail

*Produit*	*Comment l’utiliser ?*				*Statut*	*Outils nécessaires*	*Plans types /* *Exemples*
*Produit*	*Lancem^t*	*Elaborat°*	*Construct°*	*Transit°*	*Statut*	*Outils nécessaires*	*Plans types /* *Exemples*
Prototype		Doit *			Formel-Externe	Rose+Java
SNIper version 0			Doit		Formel-Externe	Rose+Java
SNIper version 1 beta			Doit		Formel-Externe	Rose+Java
SNIper version 1				Doit	Formel-Externe	Rose+Java

3.3.3 Notes sur les produits de travail

· Les différentes versions de SNIper doivent être développées à partir du code du prototype ou de la version précédente.

· L’outil Rational Rose doit être utilisé pour générer le squelette des classes depuis le Modèle de Conception.

3.4 Tests

3.4.1 Objectif de la discipline

· Fournir un cadre pour les tests des différentes versions de l’application

· Fournir les jeux d’essais à appliquer pour que les tests soient considérés comme complets et valides

3.4.2 Produits de travail

*Produit*	*Comment l’utiliser ?*				*Statut*	*Outils nécessaires*	*Plans types /* *Exemples*
*Produit*	*Lancem^t*	*Elaborat°*	*Construct°*	*Transit°*	*Statut*	*Outils nécessaires*	*Plans types /* *Exemples*
Plan de Tests		Doit *	Doit	Doit	Formel-Externe	Word

3.4.3 Notes sur les produits de travail

Le Plan de Tests comprend tous les jeux d’essais à suivre pour chaque cas d’utilisation, et les résultats obtenus.

3.5 Gestion de projet

3.5.1 Objectif de la discipline

· Fournir un cadre pour la gestion de projets à prédominance logiciel.

· Fournir des guides pratiques pour planifier, former les équipes, exécuter et contrôler les projets.

· Fournir un cadre pour gérer les risques.

3.5.2 Produits de travail

*Produit*	*Comment l’utiliser ?*				*Statut*	*Outils nécessaires*	*Plans types /* *Exemples*
*Produit*	*Lancem^t*	*Elaborat°*	*Construct°*	*Transit°*	*Statut*	*Outils nécessaires*	*Plans types /* *Exemples*
Liste des risques	Doit *	Doit *	Peut *	Peut *	Formel-Interne	Word	rup_rsklst.dot
Plan de Développement Logiciel	Doit *	Doit *	Doit *	Doit *	Formel-Externe	Word	rup_sdpln.dot
Plan d’itération	Doit *	Doit *	Doit *	Doit *	Formel-Interne	Word	rup_itpln.dot it0.pdf
Compte rendu de revue	Doit *	Doit *	Doit *	Doit *	Formel-Interne	Word
Evaluation de l’itération	Doit *	Doit *	Doit *	Doit *	Informel	Word	rup_itass.dot
Liste des problèmes	Peut *	Peut *	Peut *	Peut *	Formel-Interne	Word

3.5.3 Notes sur les produits de travail

*Produit*	*Comment l’utiliser ?*	*Raison*
Liste des problèmes	Ce produit ne doit être créé qu’en cas d’apparition de problèmes importants, d’ordre humains ou techniques	Allégement du processus
Plan d’itération	Créer un nouveau produit pour chaque itération	Ce produit ne concerne qu’une itération
Compte rendu de revue	Idem	Idem
Evaluation de l’itération	Idem	Idem

3.6 Gestion de processus

3.6.1 Objectif de la discipline

Cette discipline définit comment le processus est utilisé sur un projet. Elle comprend la mise en place de l'environnement de développement pour les participants au projet. Elle incorpore également l'évaluation du processus en vue de son amélioration.

3.6.2 Produits de travail

*Produit*	*Comment l’utiliser ?*				*Statut*	*Outils nécessaires*	*Plans types /* *Exemples*
*Produit*	*Lancem^t*	*Elaborat°*	*Construct°*	*Transit°*	*Statut*	*Outils nécessaires*	*Plans types /* *Exemples*
Plan du cycle de vie	Doit *	Doit *	Doit *	Doit *	Formel-Externe	Word	rup_devcs.dot
Plans types spécifiques au projet	Peut *	Peut *	Peut *	Peut	Informel	Word
Guides de programmation		Doit *	Doit *		Informel	Word	rup_prggd.dot

3.6.3 Notes sur les produits de travail

*Produit*	*Comment l’utiliser ?*	*Raison*
Plans types spécifiques au projet	S’inspirer des plans types proposés pour le projet « EasyStage », des plans types du RUP, et des plan types du PILPOIL	Réutilisation de l’existant