UNE modèle de cascade , le modèle à six phases est un modèle en cascade. En d’autres termes, les étapes se déroulent de manière séquentielle. De même que nager en amont contre une cascade est impossible, la technique de la cascade pure interdit de revenir à une phase une fois celle-ci terminée.
Il n’est pas idéal de décider de modifier la conception pendant la phase de mise en œuvre, arrêtant ainsi la mise en œuvre. L’approche en cascade est souvent moins adaptée aux projets de développement de logiciels pour diverses raisons.
- Le développement de logiciels est une entreprise artistique; il est pratiquement difficile d’anticiper tous les besoins (fonctionnalités).
- Estimer le temps nécessaire pour développer une fonctionnalité est très difficile.
- Tout au long du cycle de vie du projet, les utilisateurs doivent être en mesure de tester tous les résultats intermédiaires.
Le développement de logiciels est une entreprise artistique #
Pour les non-initiés, le développement de logiciels semble être davantage une question d’ingénierie que d’invention. Elle se rapporte cependant de plusieurs manières à l’invention. Dans le processus de création, on ne sait jamais exactement ce qui va se passer.
Les concepteurs et programmeurs chargés de développer de nouveaux logiciels doivent apporter des réponses aux problèmes qui leur sont posés. Indépendamment des nombreuses techniques et prescriptions de travail, la création de code informatique est encore largement méconnue et donc imprévisible. Les programmeurs peuvent choisir parmi des millions de solutions écrites dans des dizaines de langages de programmation et fonctionnant sur des milliers de combinaisons matérielles et de plates-formes logicielles différentes. Bien que cette flexibilité présente de nombreux avantages, elle rend également le projet plus difficile à gérer que les projets plus conventionnels. gestion de projet (comme des projets de construction ou de construction).
Configuration de la mise en œuvre #
L’approche en cascade exige que les exigences soient définies en conséquence de la phase de définition du projet . Idéalement, un écart supplémentaire minimal par rapport à ces critères devrait se produire pour le reste du projet. L’approche en cascade du développement logiciel nécessite un engagement initial d’efforts importants dans l’analyse de la fonctionnalité requise (exigences). Il en résulte une conception fonctionnelle (voir I pour plus d’informations sur les conceptions fonctionnelles). L’architecte logiciel crée une conception technique tout au long du processus de conception, en utilisant la conception fonctionnelle comme référence. De plus, la conception technique fournit des instructions sur la façon d’exécuter la fonctionnalité requise.
Bien que cela puisse sembler être un problème simple, envisagez le scénario suivant. Un nouveau véhicule est en cours de développement dans le cadre d’un projet. En tant que conducteur automobile actif, vous êtes chargé de développer les besoins automobiles. Vous vous concertez avec d’autres automobilistes et dressez une liste exhaustive :
- La voiture doit accueillir quatre personnes;
- L’automobile doit avoir un volant à l’avant du côté gauche du conducteur; • L’automobile doit avoir une pédale de frein, une pédale d’accélérateur et un frein à main.
- Les phares de l’automobile doivent être blancs et les feux arrière doivent être rouges. (évidemment, la vraie liste serait énorme)
Conception & Modélisation #
Les concepteurs créent un nouveau design en utilisant votre liste comme guide, qui est ensuite construit plusieurs mois plus tard. En descendant la rue, vous voyez qu’un véhicule s’est immobilisé. Vous vous rendez compte que vous avez omis les feux stop de votre liste ! Vous contactez rapidement l’ingénieur du constructeur automobile, qui a failli éclater en réponse à votre appel. Vous prétendez qu’il s’agit d’un ajustement mineur. Cependant, c’est une catastrophe pour les constructeurs automobiles. Les automobiles déjà fabriquées doivent être entièrement démontées, les câbles des pédales de frein à l’arrière doivent être rallongés, l’arrière du véhicule doit être totalement repensé pour s’adapter aux feux de freinage, et les trappes de coffre déjà fabriquées doivent être mises au rebut, et la liste est longue.
Bien que le scénario ci-dessus semble ridicule, il représente un événement quasi quotidien dans le développement de logiciels. Les programmeurs supposent à tort que les clients, les clients ou les utilisateurs du produit en cours de création comprennent exactement ce qu’ils veulent. Les clients croient à tort que les développeurs de logiciels peuvent créer (et modifier) n’importe quoi en un minimum de temps. C’est la principale cause de discorde entre les consommateurs et les développeurs de logiciels.
