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.
|
|