Cycle hautement paramétrable
    Voici les 4 étapes détaillées dans une présentation qui rappelle le cycle en V classique, avec ses effets "tunnels" dangereux et ses Waterfall inévitables...
    Et pourtant, ce qui suit ne se veut en rien un cycle strictement en V :



    En réalité, le vrai "cycle en V" que vous rencontrez le plus souvent se situe au niveau du "Codage". Il n'est pas rare de commencer directement par une conception préliminaire (on pose tout de suite des classes de code, que l'on raffine en conception détaillé via des pattern de conception, avec de coder l'implémentation, de faire des tests unitaire... quand on a le temps, et d'assembler entre eux les morceaux.
Un outil qui supporte typiquement cette approche est l'AGL Together.
    Cette approche n'est en rien incompatible avec :
- un cycle itératif plus formel : les flèches entre les différentes étapes de ce cycle de développement montre justement les opération de "promote" / "demote" (promotion/rétrogradation au sein de la même version d'un logiciel) d'un ensemble de livrable (il peut s'agit de code, de spécifications textuelles, de ressources diverses - images, fichiers de configuration, etc -). On notera d'ailleurs qu'une fois en phase d'homologation, à partir de la phase de validation fonctionnelle, il est rare de revenir en arrière : l'itération ne se fait plus au sein de la version courante du logiciel, mais lors de la version "n+1".
- d'autres approches plus "dynamiques" : la méthodologie XP peut s'appliquer à tout cycle court (comme celui de la phase de codage), et peut même s'étendre aux phases de livraison transverses pour de petits projets (XP suppose en effet une "livraison plusieurs fois par jour", ce qui impliquerait une homologation formelle comprenant une validation fonctionnelle plusieurs fois par jour... ce qui n'est pas réaliste pour de gros projets).

    Le but de ce schéma est de montrer qu'au delà des simples "étapes" à la Waterfall, un tel cycle peut se lire selon deux axes : 
- un axe qui oppose des sphères architecturales transverses aux projets d'un côté, des projets de l'autres ;
- un axe qui oppose la conception-réalisation d'un côté à la production (donc au fonctionnement réel du logiciel sur le terrain).

    Le premier niveau de paramétrisation est donc constitué par les sphères architecturales :
- La partie transverse concerne plus les Architectures Métier et Architectures Fonctionnelle ; elle implique un ou plusieurs projets (si vous travaillez sur un seul gros projet, il y a des chances pour que vous deviez analyser le métier et les fonctions, afin de décomposer ce projet en plusieurs sous-projets);
- la partie "codage" se retrouve de projet en projet : chacun doit mettre en œuvre les activités qui y sont spécifiées. On retrouve alors l'implémentation de services décrits dans une Architecture Applicative, supportée par une Architecture Technique.

    Le deuxième niveau de paramétrisation reste la production :
- en gros, la première partie du cycle en V (Modélisation et Codage) ne concerne pas la production ;
- la deuxième partie s'occupe de la :
    * pré-production, avec toutes les phases de validation (avec différents niveaux de tests d'intégration, puis d'homologation)
    * de mise en production, qui à lui seul peut représenter un cycle excessivement complexe, d'autant qu'il se poursuit au delà du déploiement, par les activités de maintenance.


Bonus en anglais
    Voici une proposition de traduction :


    On remarquera qu'il existe, en anglais comme en français, une confusion entre :
- assemblage
- intégration.
    En principe, un développeur réalise couramment de l'assemblage entre ses différents codes et ceux de ses collègues au sein d'un même périmètre fonctionnel : si vous êtes plusieurs à développer une IHM complète, vous réaliserez vos tests unitaires en compilant l'ensemble du code de cette IHM, ce qui revient à en assembler les morceaux.
    En revanche, dès que vous sortez de votre périmètre fonctionnel (et que vous reliez, par exemple, votre IHM aux autres fonctionnalités - calcul métier, persistence, ...-), vous faites de l'intégration, qui précède une validation fonctionnelle portant sur l'application toute entière.