Une itération englobe les activités de développement menant à une édition d'un produit - une version stable,
exécutable du produit ainsi que tout élément périphérique nécessaire pour utiliser cette édition. Une itération de
développement est donc d'une certaine façon une exécution complète de toutes les disciplines (exigences, analyse et
conception, implémentation, et test), au minimum. C'est une sorte de petit projet en cascade en lui-même. Notez que les
critères d'évaluation sont établis quand chaque itération est planifiée. L'édition possédera des capacités prévues et
démontrables. La durée d'une itération variera selon la taille et la nature du projet, mais de multiples constructions seront sans doute effectuées dans chaque
itération, comme le décrit le Plan de construction et intégration de l'itération. C'est une
conséquence de l'approche d'intégration en continu recommandée dans le Rational Unified Process (RUP) : au fur et à
mesure que des composants testés à l'unité sont disponibles, ils sont intégrés et une construction est produite et
soumise au test d'intégration. Ainsi, les capacités du logiciel intégré s'accroissent au fur et à mesure de l'itération
jusqu'à ce qu'elles atteignent les objectifs définis lors de la planification de l'itération. On peut penser que chaque
construction elle-même représente une mini-itération, la différence résidant dans la planification requise et la
formalité de l'analyse effectuée. Dans certains projets, il peut être approprié et pratique de créer des constructions
quotidiennement, mais il ne s'agirait pas d'itérations comme les définit le RUP - excepté peut-être pour un projet très
petit et ne concernant qu'une personne. Même dans le cas de petits projets concernant plusieurs personnes (par exemple,
cinq personnes développant 10 000 lignes de code), il serait très difficile d'achever l'itération en moins d'une
semaine. Pour savoir pourquoi, voir Instructions : Plan de développement logiciel.
Généralement, les projets sont organisés pour exécuter chaque discipline de manière séquentielle, une seule fois. On
obtient alors un cycle de vie en cascade :
Cela entraîne souvent une "accumulation" d'intégrations tard dans l'implémentation, lorsque le produit est construit
pour la première fois et que les tests commencent. Les problèmes qui sont restés cachés pendant l'analyse, la
conception et l'implémentation remontent à la surface, le projet est immobilisé et un long cycle de résolution des
bogues commence.
Une approche plus flexible (et moins risquée) consiste à exécuter plusieurs fois les différentes disciplines de
développement, à développer une meilleure compréhension des exigences, à concevoir une architecture solide, à faire
évoluer l'organisation de développement et à fournir finalement une série d'implémentations de plus en plus complètes.
On appelle cela un cycle de vie itératif. Chaque exécution de la séquence de disciplines de processus est
appelée itération.
Par conséquent, du point de vue du développement, le cycle de vie du logiciel est une succession d'itérations
par le biais desquelles le logiciel se développe de façon incrémentielle. Chaque itération se termine par une
édition d'un produit exécutable. Ce produit peut être le sous-ensemble d'une vision complète, mais est utile du
point de vue de l'ingénierie ou pour une autre raison. Chaque édition est accompagnée de produits de support
(description de l'édition, documentation utilisateur, plans, etc.) et de modèles mis à jour du système.
La principale conséquence de cette approche itérative réside dans le fait que les produits, décrits plus haut, évoluent et progressent au fil du temps, comme illustré
dans le diagramme ci-dessous.
Evolution des ensembles d'informations pendant les phases de développement.
Jalon mineur
Chaque itération se termine par un jalon mineur, dans lequel le résultat de l'itération est évalué selon les critères
de réussite objectifs de cette itération spécifique.
|