Cycle de développement logiciel en cascade

Le modèle en cascade est une approche classique, courante et linéaire du cycle de développement logiciel. Il définit une suite de phases, chacune avec des objectifs clairs. Comme l’eau qui descend une pente, ce modèle strict avance sans revenir en arrière.

Le modèle en cascade est strict et laisse peu de place aux révisions. Les tests constituent une phase distincte et ne se déroulent pas en continu pendant le développement. Le modèle ne permet donc pas de détecter les défauts tôt dans le développement.

Ouvrir le schéma en taille réelle ↗

Cycle de développement logiciel en cascade

Les phases se déroulent dans cet ordre :

1. Recueil des exigences. Recueillez les exigences du client et préparez la documentation nécessaire.
2. Conception du système. Appuyez-vous sur les exigences pour définir l’architecture ainsi que les besoins matériels et logiciels du système.
3. Implémentation. Commencez à coder à partir de la conception. Divisez le programme en petites unités indépendantes, testez chacune selon ses spécifications, puis intégrez-les pour former le système complet.
4. Tests d’intégration. Assemblez les unités testées et testez l’ensemble du système pour détecter les défauts.
5. Déploiement. Corrigez les défauts découverts pendant les tests d’intégration, puis testez de nouveau pour confirmer les corrections. Le système est alors prêt à être commercialisé et déployé dans l’environnement du client.
6. Maintenance. Publiez des correctifs ou de nouvelles versions pour résoudre les défauts et problèmes détectés après la livraison.

Les phases s’enchaînent en cascade. Chaque phase ne commence qu’après l’achèvement réussi de la précédente.

Utilisez ce modèle lorsque les exigences sont claires, que le produit est stable et que chaque phase dispose de ressources suffisantes. En pratique, réservez-le aux petits projets faciles à gérer. Évitez-le lorsque les exigences comportent un risque modéré ou élevé.

Spécification et analyse des exigences

Le développement logiciel dépend de la qualité du recueil et de la documentation des exigences. Le travail qui consiste à les identifier et à les documenter s’appelle la spécification et l’analyse des exigences.

Le client, l’équipe de direction et l’assistance technique examinent les exigences ensemble et en détail. Ils les analysent, les révisent et les documentent jusqu’à ce qu’elles soient claires et complètes.

Ouvrir le schéma en taille réelle ↗

Spécification des exigences utilisateur

Utilisez le format demandé par l’entreprise, par exemple des documents Word, des organigrammes ou des dessins. Le résultat décrit en détail les attentes du client et aide l’équipe à bien les comprendre. Un défaut est tout écart par rapport aux exigences du client. Un recueil erroné des exigences fait partir le projet sur de mauvaises bases.

Spécification des exigences utilisateur

Ce document non technique décrit les attentes des utilisateurs et leurs besoins métier. Les utilisateurs finaux le rédigent. Les exigences sont vérifiées lors des tests d’acceptation utilisateur. Ce document sert de base à la suite du travail sur les exigences et à la conception du système.

Spécification des exigences logicielles

La spécification des exigences logicielles (SRS) définit la manière dont le logiciel doit fonctionner pour répondre aux attentes de l’utilisateur. Elle sert à :

• Consigner l’accord entre le client et le fournisseur sur les fonctionnalités détaillées du logiciel.
• Établir la base de la conception du logiciel.
• Faciliter le développement et les tests grâce à des exigences claires.
• Aider à planifier les activités et à estimer les coûts.
• Fournir une base pour la vérification et la validation.

Ouvrir le schéma en taille réelle ↗

Spécification des exigences logicielles

Conception du logiciel

La conception du logiciel comprend deux niveaux :

• Conception générale du logiciel
• Conception détaillée du logiciel

Ouvrir le schéma en taille réelle ↗

Conception du logiciel

Conception générale du logiciel

La conception générale (HLD) décrit la conception de la base de données et l’architecture fonctionnelle. Elle guide les développeurs et répond à leurs questions sur la structure de la conception. Il faut disposer d’une SRS claire avant de pouvoir préparer la HLD.

Conception détaillée du logiciel

La conception détaillée (LLD) décompose la HLD en éléments plus petits et consigne la logique qui constitue la spécification du programme. Elle détaille le système et suppose que la HLD soit achevée.

Démarches de conception du logiciel

La conception peut suivre l’une des deux démarches suivantes :

• Conception descendante
• Conception ascendante

Démarche de conception descendante

La conception descendante commence par une vue d’ensemble du système. Les détails des sous-systèmes viennent ensuite. Décrivez chaque sous-système de plus en plus précisément jusqu’à atteindre les éléments de base.

Démarche de conception ascendante

La conception ascendante commence par des éléments de base entièrement définis. Assemblez-les en sous-systèmes, puis combinez ces sous-systèmes jusqu’à former le système complet. Imaginez une graine que vous plantez et qui devient peu à peu un arbre.