Activité :
|
Objet
|
|
Rôle : Intégrateur | |
Fréquence : Une fois par construction au minimum. | |
Etapes | |
Artefacts d'entrée : | Artefacts de sortie : |
Guides d'utilisation de l'outil : | |
Plus d'informations : |
Détails sur l'enchaînement d'activités : |
Au début de cette activité, les sous-systèmes d'implémentation ont été livrés dans le but de satisfaire les exigences de la construction suivante (également appelée cible), décrite dans l'artefact de plan de construction et intégration, ce qui souligne le fait que ce plan peut définir un besoin à hauteur de plusieurs constructions par itération. En fonction de la complexité et du nombre de sous-systèmes à intégrer, il est souvent plus efficace de générer la construction cible en suivant un certain nombre d'étapes (en ajoutant des sous-systèmes à chaque étape et en élaborant une série de mini constructions intermédiaires) : ainsi, chaque construction planifiée pour une itération peut à son tour avoir sa propre séquence de constructions intermédiaires. Ces dernières sont soumises à un test d'intégration minimal (généralement composé d'un sous-ensemble des tests décrits dans le plan de construction et intégration pour cette cible) afin de s'assurer que les éléments ajoutés sont compatibles avec les éléments qui existent déjà dans l'espace de travail d'intégration système. Lorsque cette approche est utilisée, il doit être plus facile d'isoler et de diagnostiquer les problèmes.
L'intégrateur accepte les sous-systèmes livrés de façon incrémentielle dans l'espace de travail d'intégration système lors du processus permettant de résoudre les conflits de fusion. Il est recommandé d'effectuer cette opération du bas vers le haut par rapport à la structure en couches, en vérifiant que les versions des sous-systèmes sont cohérentes (tenez compte des importations). L'incrément de sous-systèmes est compilé et lié au sein d'une construction intermédiaire, qui est ensuite présentée au testeur à des fins d'exécution d'un test d'intégration système minimal.
Ce diagramme illustre l'élaboration d'une construction en trois incréments. Certains sous-systèmes ne sont nécessaires que comme modules permettant de compiler et lier les autres sous-systèmes ; ils fournissent le comportement d'exécution minimal.
L'incrément final d'une séquence génère la construction cible, conformément au plan de construction et intégration. Une fois le test minimal passé, une version de référence initiale ou provisoire est créée pour cette construction. La construction est désormais confiée au testeur à des fins d'exécution de tests système complets. La nature et le niveau de détail de ces tests doivent être conformes au plan de construction et intégration, et la construction finale d'une itération doit être soumise à tous les tests définis dans le plan de test de l'itération.
Les versions de référence font l'objet d'une promotion au fur et à mesure qu'une construction réussit différents niveaux de test. La promotion permet d'indiquer si les versions de référence ont réussi ou échoué à un niveau de test déterminé. Les noms des niveaux de promotion sont définis par le rôle de gestionnaire de configuration dans le cadre de la définition des règles de configuration applicables au projet. . Les niveaux de promotion sont importants aux yeux des consommateurs de la version de référence : par exemple, un implémenteur souhaitera savoir si une version de référence est stable et testée avant de mettre à jour un espace de travail de développement privé à des fins de cohérence avec une version de référence de l'espace d'intégration système.
RUP (Rational Unified Process)
|