Il s'agit d'intégrer le travail des différents flux d'implémentation. C'est donc une étape importante et en quelque
sorte un "seuil qualité" constitué de revues et d'approbations, qu'il est nécessaire de franchir pour que le projet
puisse passer à la phase intermédiaire suivante.
Il est recommandé de demander aux développeurs de refonder leurs espaces de travail de développement en fonction de la
version de référence actuelle du projet, avant d'accepter leur travail dans l'espace de travail d'intégration du
projet. L'objectif de cette règle est de s'assurer que les développeurs conçoivent et testent leurs composants dans
leur espace de développement par rapport aux versions de référence les plus récentes et stables, avant de les livrer à
l'espace de travail d'intégration. Cela permet de réduire les opérations de fusion nécessaires.
De la même manière, il est conseillé de s'assurer que tous les fichiers sont bien archivés avant d'entamer la
livraison. Cela évite d'avoir des fichiers orphelins qui ne sont pas inclus dans la construction créée, et qui feront
défaut lors des mises à jour ultérieures.
La livraison est une étape importante, dans la mesure où le développeur estime alors que son travail est d'une qualité
suffisante pour être incorporé au produit.
Les règles du projet doivent indiquer qui est chargé de revoir les produits donnés, ainsi que le niveau de qualité que
le travail doit avoir atteint pour qu'il puisse être partagé avec le reste de l'équipe du projet. Vous trouverez un
certain nombre de conseils sur les revues dans Technique : revues. Pour
la plupart des produits utilisés dans le Rational Unified Process, vous disposez d'une 'liste de contrôle' qui
peut être utilisée pour évaluer la qualité du produit considéré. Par exemple, si un produit ne répond pas à certains
critères de la liste de contrôle, il doit être retravaillé et ne peut être 'promu' en l'état.
|