Rubriques

Pourquoi itérer ?

Généralement, les projets ont été organisés pour examiner chaque discipline de manière séquentielle, une seule fois. On obtient le cycle de vie en cascade :

Le diagramme montre une itération qui passe de la modélisation métier au déploiement

Cela entraîne souvent une "accumulation" de l'intégration 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 cycle de résolution des bogues commence.

Une approche plus flexible (et moins risquée) consiste à examiner 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 à effectuer finalement une série d'implémentations de plus en plus complètes. On appelle cela un cycle de vie itératif. Chaque examen de la séquence de disciplines de processus est appelé une itération.

Le diagramme montre 3 itérations successives, chacune allant de la modélisation métier au développement.

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 version 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 version est accompagnée par des artefacts de support : description de la version, documentation utilisateur, plans, etc., et des modèles mis à jour du système.

La principale conséquence de cette approche itération réside dans le fait que les ensembles d'artefacts, décrits ci-dessus évoluent et progressent dans le temps, comme le montre le diagramme suivant.

Evolution des ensembles d'informations pendant les phases de développement.

Qu'est-ce qu'une itération ? Haut de la page

Une itération englobe les activités de développement menant à une version d'un produit -une version stable, exécutable du produit ainsi que tout élément périphérique nécessaire pour utiliser cette version. Une itération de développement est donc d'une certaine façon un examen complet 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 prévue. La version 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 d'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 intégrés, 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 d'effectuer des constructions quotidiennement, mais il ne s'agirait pas d'itération 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 construisant 10 000 lignes de code), il serait très difficile de réussir à faire durer l'itération moins d'une semaine.

Version

Une version peut être interne ou externe. Une version interne est utilisée uniquement par l'organisation de développement, comme une partie d'un événement jalon, ou pour une démonstration à destination des utilisateurs ou des clients. Une version externe (ou livraison) est livrée aux utilisateurs finaux. Une version n'est pas nécessairement un produit complet, mais peut n'être qu'une étape vers ce produit, son utilité n'étant mesurée que du point de vue de l'ingénierie. Les versions jouent le rôle de fonction de forçage qui pousse l'équipe de développement à terminer le projet à des intervalles réguliers, ce qui évite le syndrome du "90% terminé, 90% à faire".

Les itérations et les versions permettent d'utiliser de mieux en mieux les différentes spécialités de l'équipe : concepteurs, testeurs, rédacteurs, etc. Des versions régulières vous permettent de ventiler les problèmes d'intégration et de test et de les répartir tout le long du cycle de développement. Ces problèmes ont souvent mis en péril des projets de grande taille car tous les problèmes ont été découverts en même temps pendant l'unique étape massive d'intégration, qui s'est déroulée très tard dans le cycle, et dans laquelle un seul problème interrompt l'ensemble de l'équipe.

A chaque itération, des artefacts sont mis à jour. On dit que cela revient un peu à faire de l'"élevage" de logiciels. Plutôt que de développer des artefacts l'un après l'autre, en "pipeline", ils évoluent pendant le cycle, à des niveaux différents.

Evénement jalon mineur

Chaque itération se conclut par un événement 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.

Itération et phasesHaut de la page

Chaque itération à l'intérieur d'une phase produit une version exécutable du système.

Chaque phase du RUP peut être séparée en itérations. Une itération est une boucle de développement complète qui produit une version (interne ou externe) d'un produit exécutable, un sous-ensemble du produit final en développement, qui évolue de façon incrémentielle d'une itération à l'autre jusqu'à devenir le système final.

Modèle d'itération : Cycle de vie incrémentielHaut de la page

"La stratégie incrémentielle détermine les besoins des utilisateurs et définit les exigences du système, puis effectue le reste du développement en une série de constructions. La première construction intègre des parties des capacités prévues, la seconde construction ajoute d'autres capacités, etc, jusqu'à ce que le système soit terminé." [DOD94]

Les itérations suivantes sont caractéristiques :

  • une itération courte de Création afin d'établir la portée et la vision, et de définir l'étude de rentabilité
  • une seule itération d'Elaboration, pendant laquelle les exigences sont définies, et l'architecture établie
  • plusieurs itérations de Construction pendant lesquelles les cas d'utilisation sont réalisés et l'architecture développée en détails
  • plusieurs itérations de transition pour faire migrer le produit dans la communauté d'utilisateurs

Diagramme décrit dans le texte d'accompagnement.

Cette stratégie est appropriée quand :

  • Le domaine du problème est familier.
  • Les risques sont bien compris.
  • L'équipe du projet est expérimentée.

Modèle d'itération : Cycle de vie évolutifHaut de la page

"La stratégie évolutive diffère de la stratégie incrémentielle car elle reconnaît que les besoins des utilisateurs ne sont pas complètement compris et que toutes les exigences ne peuvent être définies dès le départ, mais qu'elles sont affinées lors de chaque construction successive." [DOD94]

Les itérations suivantes sont caractéristiques :

  • une itération courte de création afin d'établir la portée et la vision, et de définir l'étude de rentabilité
  • plusieurs itérations d'élaboration pendant lesquelles les exigences sont affinées à chaque itération
  • une seule itération de construction, pendant laquelle les cas d'utilisation sont réalisés et l'architecture est étendue
  • plusieurs itérations de transition pour faire migrer le produit dans la communauté d'utilisateurs

Diagramme décrit dans le texte d'accompagnement.

Cette stratégie est appropriée quand :

  • Le domaine du problème est nouveau ou non familier.
  • L'équipe est inexpérimentée.

Modèle d'itération : Cycle de vie de livraison incrémentielleHaut de la page

Certains auteurs introduisent également les livraisons graduelles de fonctionnalités incrémentielles au client[GIL88]. Cela peut être nécessaire lorsque le délai de mise sur le marché est serré et lorsque la livraison de certaines fonctions clé peut entraîner des avantages commerciaux significatifs.

Selon l'approche phase-itération, la phase de transition commence tôt et possède le plus d'itérations. Cette stratégie nécessite une architecture très stable, ce qui est difficile à obtenir dans un cycle de développement initial, pour un système "nouveau".

Les itérations suivantes sont caractéristiques :

  • une itération de création courte afin d'établir la portée et la vision, et de définir l'étude de rentabilité
  • une seule itération d'élaboration, pendant laquelle une architecture stable est configurée
  • une seule itération de construction pendant lesquelles les cas d'utilisation sont réalisés et l'architecture développée en détails
  • plusieurs itérations de transition pour faire migrer le produit dans la communauté d'utilisateurs

Diagramme décrit dans le texte d'accompagnement.

Cette stratégie est appropriée quand :

  • Le domaine du problème est familier :
    • l'architecture et les exigences peuvent être stabilisés tôt dans le cycle de développement
    • le problème ne représente qu'un faible degré de nouveauté
  • L'équipe est expérimentée.
  • Les versions incrémentielles de fonctionnalité ont une grande valeur pour le client.

Modèle d'itération : "Cycle de vie "grande conceptionHaut de la page

L'approche traditionnelle en cascade peut être vue comme un cas dégénéré dans lequel il n'existe qu'une itération dans la phase de construction. On l'appelle "grande conception" dans [DOD94]. En pratique, il est difficile d'éviter les itérations additionnelles dans la phase de transition.

Les itérations suivantes sont caractéristiques :

  • une itération courte de création afin d'établir la portée et la vision, et de définir l'étude de rentabilité
  • une seule itération de construction très longue pendant lesquelles les cas d'utilisation sont réalisés et l'architecture développée en détails
  • plusieurs itérations de transition pour faire migrer le produit dans la communauté d'utilisateurs

Diagramme décrit dans le texte d'accompagnement.

Cette stratégie est appropriée quand :

  • une petite incrémentation d'une fonctionnalité bien définie est ajoutée à un produit très stable
  • la nouvelle fonctionnalité est bien définie et bien comprise
  • L'équipe est expérimentée, dans le domaine du problème et par rapport au produit existant

Modèle d'itération : Stratégies hybrides Haut de la page

En pratique peu de projets suivent strictement une seule stratégie. Vous obtenez souvent un hybride, une évolution au départ, une construction incrémentielle et des livraisons multiples. Parmi les avantages du modèle phase-itération, celui-ci vous permet notamment d'adopter une approche hybride simplement en augmentant la longueur et le nombre d'itérations dans des phases spécifiques :

  • Pour des domaines de problème complexes ou non familiers, où il y a un degré élevé d'exploration : augmentez le nombre d'itérations dans la phase d'élaboration et sa longueur.
  • Pour des domaines de développement plus complexes, dans lesquels la traduction de la conception au code est complexe : augmentez le nombre d'itérations dans la phase de construction et sa longueur.
  • Pour livrer des logiciels en une série de versions incrémentielles : augmentez le nombre d'itérations dans la phase de transition et sa longueur.


RUP (Rational Unified Process)   2003.06.15