MODÈLE DE CYCLE DE DÉVELOPPEMENT

Dans le précédent article, nous avons vu un cycle de façon générale qui ne s'apparente pas réellement à un modèle en particulier. Chaque phase des cycles doivent être soumis à des tests afin d'assurer une certaine qualité qui est déterminante pour le génie logiciel. De nombreux modèles existent, nous allons discuter des plus populaires.

Modèle en cascade

C'est un des premiers modèles qui a été proposé. Il date des années 70. Ce modèle est strict et lourd. Chaque phase doit être approuvée avant de pouvoir commencer l'autre.

Tel que le suggère l'image, chaque étape doit être terminée avant dans entamé une autre. Plus on avance dans les étapes, moins il devrait avoir de risque. On avance donc par pas.

L'avantage de ce modèle est que chaque phase est finie, elle est donc gérable tant au niveau du temps que des ressources. Le code est créé assez tardivement, il y a donc une bonne compréhension du système. Au niveau des inconvénients, on peut noter que ce modèle ne représente pas la réalité. Il est possible de revenir en arrière, car des erreurs ont été découvertes, car on doit créer des tests ce qui implique du code. Il y a des risques de découvrir des erreurs qu'a la fin et qui nécessiteront de refaire toutes les étapes. L'ajout de nouvelle exigence implique qu'il faille refaire toutes les étapes. Plus un problème ou un changement doit être fait tard, plus il coûtera cher.

Ce modèle est encore très utilisé, mais a été revu dans sa version initiale. Dans la nouvelle version, il est possible de revenir en arrière et des prototypes sont créé à chaque phase. Il est ainsi dans cette nouvelle version, plus près de la réalité.

Modèle en V

Le principe de ce modèle, est que chaque étape de décomposition du système possède une phase de test. Chaque phase du projet à une phase de test qui lui est associé. Beaucoup de tests sont ainsi créés, ce qui implique une réflexion. On sait progressivement si on s'approche de ce que le client désire.

Ce modèle est convenable pour les projets complexes. C'est un modèle dérivé du modèle en cascade.

Modèle par incrément

Dans ce modèle, un seul composant est développé à la fois. On débute par définir les exigences et on les décompose en sous-système. À chaque version du logiciel, de nouvelles fonctionnalités venant combler les exigences sont ajoutées. On continue de la sorte jusqu'à ce que toutes les fonctionnalités demandées soient comblées par le système. Chaque incrément peut utiliser un autre modèle (v, en cascade...).

L'image n'affiche que deux incrémentations, mais il peut y en avoir plusieurs.
Le développement sont ainsi moins complexe, l'intégration est moins brutal et le client a plus rapidement un système même s'il n'est pas complet. Par contre, le coeur du système peut être à revoir lorsqu'on passe à une autre incrémentation du système. Il peut ainsi s'avérer complexe d'ajouter certaines fonctionnalités.
Ce modèle convient au projet de grande envergure. L'architecture doit être bien pensée dès le départ afin de réduire les risques par la suite.

Modèle en spirale

Ce modèle est plus récent, il date du milieu des années 80. L'emphase de ce modèle et mise sur la réduction des risques. Ce modèle est adapté pour les gros projets complexes. Les risques sont sans cesse évalués à chaque cycle. Un cycle est décomposé en étapes.

• Analyse préliminaire pour le premier cycle, pour les autres cycles, on détermine les objectifs, contrainte à partir du résultat du cycle antérieur.
• Analyse des risques, création de prototype
• Développement et test
• Planification du cycle suivant

Les prototypes créés à chaque cycle permettent de réduire les risques et de guider la conception pour obtenir un système qui répond au besoin du client. Chaque cycle de la spirale fait en sorte que le système est de plus en plus complet.

Modèle UP

Unified Process est une méthode générique de développement. C'est une méthode qui permet l'évolution telle que le fait le modèle en spirale. Cette méthode impose la création de beaucoup de documentations. Cette méthode est beaucoup liée au produit que propose cette compagnie Rational Rose (appartenant maintenant à IBM). L'automatisation fait partie de UP. Cette méthode tente de mettre en oeuvre différentes pratiques afin d'obtenir un produit de qualité

• Modèle de développement itératif

  Fréquemment, une version du logiciel est présentée au client. Une telle approche permet de réduire les risques de ne pas répondre aux à ses besoins. La qualité peut être ainsi vérifiée à chaque fois.
  

• Gestion des exigences

  Énormément d'importance est mise au niveau des exigences afin qu'elle soit prise en compte complètement.
  

• Utilisation de composant

  La création du système en assemblant des composants est privilégié. L'achat de composant permet une certaine garantie de test.
  

• Diagramme des exigences

  Beaucoup de diagrammes sont disponibles, le client peut ainsi plus aisément comprendre. La grande quantité de diagrammes permettent de voir le système sous différentes facettes.
  

• Vérification de la qualité

  La qualité est constamment vérifiée à chaque version du logiciel. On s'approche progressivement des besoins du client. Le risque d'erreur est moindre.
  

• Gestion des changements

  Les demandes de changement sont enregistrées ensuite on passe par une phase d'acceptation. Les changements sont ainsi mieux maîtrisé.
  

Quelques disciplines font parties de UP, ce sont les éléments à gauche de l'image.

• Besoin
• Analyse
• Conception
• Implémentation
• Test

Besoin

Cette activité permet de connaître le domaine du système qui doit être construit. Ces informations permettront de créer des cas d'utilisation. Une liste d'entité et d'objets-métier sont saisit.

Analyse

Les besoins et exigences du client doivent être minutieusement compris afin de pouvoir arriver à faire une conception du système. On raffine ces informations afin d'arriver à une analyse plus précise. Cette analyse permet de faciliter davantage les étapes suivantes.

Conception

Cette activité permet de comprendre de façon plus approfondie le système. Les contraintes du système doivent être définies : langage de programmation, système d'exploitation, technologie utilisée. Des interfaces entre les sous-sytèmes doivent être déterminées. C'est l'endroit où tout le système est pensé et analysé en vue de son implémentation. Une excellente planification du système doit être faite.

Implémentation

Cette activité utilise les étapes précédentes afin de construire un système au niveau du code. À chaque itération, une intégration est faite. Des tests unitaires sont faits. Les classes identifiées à la phase conception sont implémentées.

Test

Cette activité permet de vérifier les résultats de la phase précédente. Les tests doivent spécifier ce qui doit être testé, les résultats attendu et obtenu.
Quatre phases composent UP:

• Création
• Élaboration
• Construction
• Transition

Création

Une idée du système est donnée. On identifie ce que le système va faire, on établit l'architecture, on définit l'échéancier, les coûts et ressources nécessaires. Une liste des risques est identifiée. Les limites du système sont définies : ce que le système fait et ce qu'il ne fait pas.

Élaboration

Cette phase permet de concevoir et valider l'architecture du système. Les cas d'utilisations sont précisés.

Construction

La construction du système est faite. Les exigences définies doivent être comblées.

Transition

Cette étape vérifie ce qui a été fait. Le produit est installé chez le client. Les anomalies de dernières minutes sont corrigées. Le système est configuré.

UP est un modèle itératif et incrémental. Une itération est un sous-projet dérivé du projet informatique. Le découpage du projet en plus petite entité réduit la complexité et les risques. Un incrément est une version du système.

Ce modèle, comme tous les autres présentent quelques défauts. Il est coûteux à mettre en oeuvre et à personnaliser. L'emphase est mise au processus, peu de place est accordée au développement. Le codage ainsi que la technologie n'occupent pas assez de place. Les systèmes ayant majoritairement que des algorithmes, peu d'interaction avec des utilisateurs ne conviennent pas à ce modèle.