Tâche: Vérifier les changements dans la construction
Cette tâche explique comment vérifier qu'une demande de changement a bien été effectuée.
Objet
  • Cette tâche confirme qu'une demande de changement a bien été effectuée, habituellement en effectuant un sous-ensemble de tests sur une ou plusieurs créations.
Relations
RôlesPrincipal: Complémentaire: Auxiliaire:
EntréesObligatoire: Facultatif: Externe:
  • Aucun
Sorties
Etapes
Résoudre la demande de changement

Le membre désigné de l'équipe effectue l'ensemble des tâches définies dans la section appropriée du processus de livraison, comme les exigences, l'analyse & la conception, l'implémentation, la production des supports d'aide à l'utilisateur et le test de conception. Ces tâches incluront toutes les tâches normales de révision et de test unitaire tel que décrit dans le processus de livraison normal. La demande de changement sera ensuite marquée comme résolue. Ceci signifie que la résolution de cette demande de changement est achevée et que celle-ci est prête pour la vérification.

Vérifier les changements dans la version de test

Une fois les changements résolus par le rôle affecté (analyste, développeur, testeur, rédacteur technique, etc.), ils seront placés dans une file d'attente de test à affecter à un testeur et vérifiés dans une construction de test du produit. Une demande de changement qui a été vérifiée dans une construction de test est prête à être incorporée dans une version. Une demande de changement qui échoue au test, que ce soit dans une construction de test ou une construction de version, sera placée dans l'état Test échoué. Le propriétaire devient automatiquement le membre de l'équipe qui a résolu la demande de changement.

Vérifier les changements dans la version de diffusion

Une fois que les changements résolus ont été vérifiés dans une construction de test du produit, la demande de changement est placée dans une file d'attente de version pour être vérifiée par rapport à une création de version du produit, pour produire des notes d'édition, etc. et fermer la demande de changement.

Une demande de changement fermée ne nécessite plus aucune intervention. C'est l'état final pouvant être affecté à une demande de changement. Seul l'administrateur de revue du CCB a autorité pour fermer une demande de changement. Lorsqu'une demande de changement est Cfermée, l'émetteur recevra une notification par e-mail l'informant de la décision finale sur la demande de changement. Une demande de changement peut être fermée : 1) une fois que sa résolution vérifiée est validée dans une création de version, 2) lorsque son état Rejeté est confirmé, ou 3) lorsqu'il est confirmé qu'il s'agit d'un doublon d'une demande de changement existante. Dans ce dernier cas, l'émetteur sera informé du doublon et sera ajouté à cette demande de changement pour les notifications ultérieures (voir les définitions des états "rejeté" et "doublon" pour plus d'informations). Si l'émetteur souhaite contester la fermeture, la demande de changement doit être mise à jour et soumise à nouveau à la revue du CCB.

Les différents états applicables à une demande de changement sont répertoriés dans Gestion des demandes de changement.

Evaluer et vérifier vos résultats
Objectif :  Vérifier que la tâche a été correctement réalisée et que les produits en résultant sont acceptables. 

Maintenant que vous avez achevé le travail, il serait utile de vérifier que ce travail a suffisamment de valeur et que vous n'avez pas simplement consommé de grandes quantités de papier. Vous devez évaluer si votre travail est d'une qualité correcte et qu'il est assez complet pour être utile aux membres de l'équipe qui en feront un usage ultérieur comme donnée d'entrée pour leur propre travail. Si possible, utilisez les listes de contrôle fournies dans RUP pour vérifier que la qualité et l'exhaustivité sont "satisfaisantes".

Faites en sorte que les personnes qui effectuent les tâches en aval, et qui se basent sur votre travail comme donnée d'entrée, prennent part à la revue de votre travail intermédiaire. Effectuez cette revue pendant que vous avez encore du temps disponible pour prendre les mesures qui répondent à leurs préoccupations. Vous devez également évaluer votre travail par rapport aux produits d'entrée clés pour vous assurer que vous les avez précisément et suffisamment représentés. Il peut être utile que l'auteur du produit d'entrée révise votre travail sur cette base.

Essayez de vous rappeler que le RUP est un processus de livraison itératif et que dans de nombreux cas, les produits évoluent au fil du temps. A ce titre, il n'est généralement pas nécessaire - et c'est même souvent contre-productif - de développer complètement un produit qui ne sera que partiellement utilisé ou ne sera pas du tout utilisé dans l'immédiat. Cela est dû au fait qu'il existe une grande probabilité pour que la situation qui entoure le produit change - et que les hypothèses émises lors de la création du produit s'avèrent incorrectes - avant même l'utilisation du produit, occasionnant ainsi une perte d'efforts et un remaniement coûteux. Evitez également le piège consistant à utiliser trop de cycles pour la présentation au détriment de la valeur du contenu. Dans les environnements de projet où la présentation a une importance et une valeur économique en tant que résultat d'un projet, vous pouvez envisager d'utiliser une ressource administrative pour réaliser les tâches de présentation.



Propriétés
Plusieurs occurrences
Commandé par les événements
En cours
Facultatif
Planifié
Réitérable
Plus d'informations