Wylie College

Plan de gestion des exigences

 

Version 2.0

 

 

Historique des révisions

Date

Version

Description

Auteur

08/01/1999

1.0

Edition initiale

Simon Jones

10/02/1999

2.0 

Extension du plan 

 Simon Jones

 
 
 
 
 
 
 
 

 


Sommaire

1.     Introduction  

1.1      Objectif  

1.2      Portée  

1.3      Définitions, acronymes et abréviations  

1.4      Références  

2.     Gestion des exigences

2.1      Organisation, responsabilités et interfaces  

2.2      Outils, environnement et infrastructure  

3.     Le programme de gestion des exigences   

3.1      Identification des exigences  

3.2      Traçabilité  

3.2.1     Critères d'exigences des produits

3.2.2     Critères d'exigences des cas d'utilisation

3.2.3     Critères de cas de test

3.3      Attributs  

3.3.1      Attributs des exigences des cas d'utilisations

3.3.2     Attributs des cas de test

3.4      Rapports et mesures  

3.5      Gestion des modifications des exigences

3.6      Disciplines et tâches  

4.     Jalons  

5.     Formations et ressources  


Plan de gestion des exigences

1.                  Introduction

1.1               Objectif

Les instructions des attributs d'exigence identifient et décrivent les attributs à utiliser pour gérer les exigences des tous les projets logiciels du Wylie College. De plus, ce document décrit la traçabilité des exigences à maintenir lors du développement des projets.

Les attributs assignés à chaque exigence permettent de gérer le développement du logiciel et de prioriser les fonctions de chaque édition.

L'objectif de la traçabilité des exigences et de réduire le nombre de problèmes découverts en fin de cycle de développement. Capturer toutes les exigences de produit dans les exigences logicielles, les cas de conception et de test améliore la qualité du produit.

1.2            Portée

Les instructions d'attributs et de traçabilité de ce document s'appliquent aux exigences de produit, aux exigences logicielles et aux exigences de test de tous les projets logiciel du Wylie College.

1.3                Définitions, acronymes et abréviations

Nous utilisons les termes définis dans la documentation RUP et Rational RequisitePro.

1.4                Références

Les références suivantes peuvent se trouve sur le site web de processus logiciel du Wylie College ou peuvent être atteintes depuis le site.

1. Plan de gestion de configuration du Wylie College.
2. Rational Unified Process.
3. Cas de développement Wylie College

2.                  Gestion des exigences

2.1                Organisation, responsabilités et interfaces

Couvertes par le plan de développement du logiciel du projet.

2.2                Outils, environnement et infrastructure

Rational RequisitePro sera utilisé pour gérer les attributs et la traçabilité des exigence.  Les autres détails d'infrastructure sont détaillés sur le site de processus logiciel du Wylie College.

3.                  Le programme de gestion des exigences

3.1                Identification des exigences

Chaque projet identifie et gère les types d'exigences suivants :

 

Produits

 

Type d'exigence

Description

Vision

Exigence du produit

Fonctions de produit, contraintes, gammes de qualité et autres exigences de produit.

Modèle de cas d'utilisation

Cas d'utilisation

Cas d'utilisation, documentés dans Rational Rose

Plan de test

Cas de test

Cas décrivant comment vérifier que le système se comporte correctement.

 

3.2                Traçabilité

3.2.1     Critère d'exigence de produit

Les exigences de produit définies dans le document de vision seront liées aux cas d'utilisation ou aux exigences supplémentaires correspondants dans les spécifications de cas d'utilisation ou la spécification supplémentaire.

Chaque exigence de produit est liée à un ou plusieurs exigences de cas d'utilisation et d'exigences supplémentaires.

Chaque exigence de produit est liée à un ou plusieurs exigences de cas d'utilisation et d'exigences supplémentaires.

3.2.2     Critères d'exigence des cas d'utilisation

Les exigences des cas d'utilisation définies dans les spécifications des cas d'utilisation et la spécification supplémentaire seront liées aux cas de test correspondants du plan de test.

Chaque exigence de cas d'utilisation est liée à un ou plusieurs cas de test du système.

3.2.3     Critères des cas de test

Les cas de test spécifiés dans le plan de test sont liés aux exigences du produit (dans la vision) et aux exigences des cas d'utilisation vérifiés par le cas de test.

Un cas de test peut être lié à une ou plusieurs exigences de produit ou de cas d'utilisation. Lorsqu'un cas de test vérifie une exigence dérivée ou la conception, il ne dispose pas toujours de traçabilité vers l'exigence de produit initiale ou vers les exigences de cas d'utilisation.

3.3                Attributs

3.3.1      Attributs des exigences de cas d'utilisation

Les exigences des cas d'utilisation et la spécification supplémentaire seront gérées à l'aide des attributs définis dans cette section. Ces attributs permettent de gérer l'effort de développement, de déterminer le contenu des itérations et d'associer les cas d'utilisation à leur modèle Rose.

Statut

Défini lorsque l'analyse a créé les cas d'utilisation. Suit les progrès de développement du cas d'utilisation depuis le brouillon initial jusqu'à la validation finale.

Proposé

Cas d'utilisation qui ont été identifiés mais pas encore revus ou approuvés.

Approuvé

Cas d'utilisation approuvés pour conception et implémentation.

Validé

Cas d'utilisation qui ont été validé dans un test du système.

Priorité

Définie par le responsable de projet. Détermine la priorité du cas d'utilisation, l'importance d'assigner suffisamment de ressources et de surveiller les progrès du développement. La priorité est généralement basée sur l'avantage pour l'utilisateur, l'édition prévue, l'itération prévue, la complexité du cas d'utilisation (risque) et l'effort requis pour l'implémentation.

Elevée

L'implémentation d'un cas d'utilisation de haute priorité est surveillée de près et suffisamment de ressources doivent être assignées à la tâche.

Moyenne

Le cas d'utilisation est d'une priorité moyenne par rapport aux autres.

Faible

Le cas d'utilisation est de faible priorité. L'implémentation de ce cas d'utilisation n'est pas critique et peut être déplacée vers une autre itération ou édition.

Evaluation de l'effort

Défini par l'équipe de développement. Comme certains cas d'utilisation requièrent plus de temps et de ressources que d'autres, estimer le nombre de personne/semaine, d'équipe/semaine ou de lignes de codes requises ou de points de fonction permet d'évaluer la complexité et de définir ce qui peut être réalisé sur un laps de temps donné. Utilisé pour gérer la portée et déterminer les priorités de développement. Le responsable de projet utilise ces estimations pour déterminer le calendrier du projet et pour planifier les ressources assignées aux tâches.

Estimer l'effort en jour/personne (prévoir 7,5 heures par jour ouvrable).

Risque technique

Défini par l'équipe de développement et basé sur la probabilité pour le cas d'utilisation de rencontrer des événements indésirables comme surcharge d'effort, défauts de conception, nombre de bogues élevé, faible qualité, performances inadéquates, etc. Ces événements indésirables proviennent souvent d'exigences incorrectement définies ou comprises, d'une connaissance insuffisante, d'un manque de ressources, de la complexité technique, d'une nouvelle technologie, de nouveaux outils ou d'un nouvel équipement.

Les projets du Wylie College catégorisent les risques techniques de chaque cas d'utilisation comme élevé, moyen ou faible.

Elevé

L'impact du risque combiné à la probabilité de rencontrer le risque est élevé.

Moyen

L'impact du risque est moins grave et/ou il est moins probable de le rencontrer.

Faible

L'impact du risque est minime et il est peu probable de le rencontrer.

Itération de développement cible

Définit l'itération de développement dans laquelle le cas d'utilisation sera implémenté. On considère que le développement de chaque édition se déroulera sur plusieurs itérations lors de la phase de construction du projet.

Le numéro d'itération assigné à chaque cas d'utilisation permet au responsable de projet de planifier les activités de l'équipe de projet.

Les valeurs possibles prennent la forme <lettre>-<numéro d'itération> où la lettre est I, E, C, T pour création (inception), élaboration, construction et transition.  Par exemple :

 E-1

Prévu pour la phase d'élaboration, première itération

C-1

Prévu pour la phase de construction, première itération

C-2

Prévu pour la phase de construction, seconde itération

C-3

Prévu pour la phase de construction, troisième itération

Assigné à

Les cas d'utilisation sont assignés à des individus ou des équipes pour analyse supplémentaire, conception et implémentation. Une liste déroulante simple aide tous les participants au projet à comprendre les responsabilités.

Modèle Rational Rose

Identifie le cas du modèle associé à l'exigence du cas d'utilisation.

3.3.2     Attributs des cas de test

Statut de test

Défini par le chef de test. Suit le statut de chaque cas de test.

Non testé

Le cas de test n'a pas été exécuté.

Echoué

Le test a été effectué et a échoué.

Réussite sous condition

Le test a été effectué avec certains problèmes. Le test a réussi si certaines actions sont effectuées.

Réussi

Le test a été effectué avec succès.

Numéro de compilation

Enregistre la compilation système dans laquelle le cas de test sera vérifié.

Testé par

Personne qui doit effectuer et vérifier le cas de test. Cette liste déroulante simple aide tous les participants au projet à comprendre les responsabilités.

Date de test

Date prévue ou effective du test.

Notes de test

Notes associées à la planification ou à l'exécution du test.

3.4                Rapports et mesures

A définir

3.5                Gestion des modifications des exigences

Veuillez consulter le plan de gestion de configuration du Wylie College.

3.6               Disciplines et tâches

Veuillez consulter le cas de développement du Wylie College.

4.                  Jalons

Ils sont décrits dans le plan de développement du logiciel de chaque projet.

5.                  Formation et ressources

Ils sont décrits dans le plan de développement logiciel de chaque projet.