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.3 Définitions, acronymes et abréviations
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.1 Critères d'exigences des produits
3.2.2 Critères d'exigences des cas d'utilisation
3.3.1 Attributs des exigences des cas d'utilisations
3.3.2 Attributs des cas de test
3.5 Gestion des modifications des exigences
Plan de gestion des exigences
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.
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.
Nous utilisons les termes définis dans la documentation RUP et Rational RequisitePro.
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
Couvertes par le plan de développement du logiciel du projet.
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.
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. |
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.
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.
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.
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.
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. |
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. |
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).
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 |
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.
Identifie le cas du modèle associé à l'exigence du cas d'utilisation.
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. |
Enregistre la compilation système dans laquelle le cas de test sera vérifié.
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 prévue ou effective du test.
Notes associées à la planification ou à l'exécution du test.
A définir
Veuillez consulter le plan de gestion de configuration du Wylie College.
Veuillez consulter le cas de développement du Wylie College.
Ils sont décrits dans le plan de développement du logiciel de chaque projet.
Ils sont décrits dans le plan de développement logiciel de chaque projet.