Présentation du cycle de vie du développement logiciel (SDLC)

Table of Contents hide

1 Modèle cascade

2 Modèle de transformation

2.1 Modèle en spirale

2.2 Modèle de fontaine

2.3 Modèle V

2.4 Modèle incrémental

2.5 Modèle basé sur les composants

2.6 Méthode prototype

2.7 Méthode XP

2.8 Méthode de processus unifié (UP)

2.9 Apprendre encore plus

Le cycle de vie du développement logiciel fournit aux organisations une approche systématique, étape par étape, pour développer un logiciel réussi en collectant les exigences initiales pour les nouveaux produits. Il s’agit d’un processus systématique de construction de logiciels pour assurer la qualité et l’exactitude du logiciel construit et pour répondre aux attentes des clients.

Les principaux modèles de développement comprennent le modèle en cascade, le modèle incrémental, le modèle en spirale, le modèle en fontaine, le modèle intelligent, le modèle en V, le modèle RAD, le modèle CBSD, la méthode prototype, la méthode XP, la méthode RUP, etc.

Modèle cascade

Le modèle en cascade, également connu sous le nom de méthode du cycle de vie, est le modèle de développement le plus couramment utilisé dans la méthode du cycle de vie. Il divise le processus de développement logiciel en six étapes : planification du logiciel, analyse des exigences, conception du logiciel, codage du programme, test du logiciel, et exploitation et maintenance. Afin de réaliser leur ordre fixe de haut en bas, comme une cascade, ils tombent pas à pas.

Plan logiciel : Déterminer principalement les objectifs de développement et la faisabilité du logiciel.
Analyse des besoins : Après avoir confirmé que le développement du logiciel est faisable, effectuez une analyse détaillée des différentes fonctions que le logiciel doit réaliser. L’étape d’analyse des besoins est une étape très importante. Un bon travail à ce stade jettera une bonne base pour le succès de l’ensemble du projet de développement logiciel.
Conception logicielle : Concevoir l’ensemble du système logiciel, comme la conception du cadre du système, la conception de la base de données, etc., sur la base des résultats de l’analyse de la demande. La conception de logiciels est généralement divisée en conception globale (conception d’ensemble) et conception détaillée.
Code de programme : Convertit le résultat de la conception d’un logiciel en code de programme pouvant être exécuté par un ordinateur. Dans le processus de programmation, une spécification de programmation unifiée et conforme aux normes doit être formulée pour assurer la lisibilité du programme, une maintenance facile et améliorer l’efficacité de fonctionnement du programme.
Tests logiciels : Une fois la conception du logiciel terminée, elle doit subir des tests rigoureux pour trouver et corriger les problèmes du logiciel tout au long du processus de conception. Dans le processus de test, il est nécessaire d’établir un plan de test détaillé et d’effectuer des tests en stricte conformité avec le plan de test pour réduire le caractère arbitraire du test. Maintenance logiciel:
La maintenance logicielle est la période la plus longue du cycle de vie du logiciel. Une fois le logiciel développé et mis en service, pour diverses raisons, le logiciel ne peut plus répondre aux exigences des utilisateurs. Pour prolonger la durée de vie du logiciel, le logiciel doit être maintenu.

Modèle de transformation

Le modèle de transformation (modèle d’évolution) est basé sur le développement rapide d’un prototype. Selon les commentaires et les suggestions des utilisateurs lors du processus d’appel du prototype, le prototype est amélioré pour obtenir une nouvelle version du prototype, et ce processus est répété jusqu’à ce qu’il évolue vers le produit logiciel final.

Modèle en spirale

Le modèle en spirale combine le modèle en cascade et le modèle de transformation. Il combine les avantages des deux et ajoute une analyse des risques. Il est basé sur le prototype et tourne de l’intérieur vers l’extérieur le long de la spirale. Chaque rotation nécessite une planification, une analyse des risques, une ingénierie de mise en œuvre, une évaluation des clients et d’autres activités, et une nouvelle version du prototype est développée. Après plusieurs spirales, le système final est obtenu.

Modèle de fontaine

Le modèle de fontaine prend en charge la réutilisation des logiciels et l’intégration de plusieurs activités de développement dans le cycle de vie, et prend principalement en charge les méthodes de développement orientées objet. Le terme « fontaine » lui-même incarne les caractéristiques de l’itération et de l’absence d’espace. Une certaine partie du système répète souvent le travail plusieurs fois, et des fonctions connexes sont ajoutées au système évolué à chaque itération. Le soi-disant gapless signifie qu’il n’y a pas de frontière évidente entre l’analyse, la conception et le codage dans les activités de développement.

Modèle V

Dans le modèle de développement, les tests sont souvent utilisés après coup pour remédier à la situation, mais il existe également un modèle de développement centré sur les tests, c’est-à-dire le modèle en V. Le modèle V n’a été que vaguement reconnu dans l’industrie du logiciel. Le modèle en V affirme que les tests ne sont pas une réflexion après coup, mais un processus aussi important que le processus de développement.

Le modèle en V décrit différents niveaux de test et explique les différentes étapes du cycle de vie correspondant à ces niveaux. Dans la figure, la descente à gauche correspond aux différentes étapes du processus de développement, et les correspondantes sont les parties montantes à droite, c’est-à-dire les différentes étapes du processus de test.

Veuillez noter que la dénomination de la phase de test peut être différente selon les organisations. L’intérêt du modèle en V est qu’il montre clairement les différents niveaux qui existent dans le processus de test, et décrit clairement la correspondance entre ces phases de test et les différentes phases du processus de développement :

L’objectif principal des tests unitaires est de traiter diverses erreurs pouvant exister dans le processus de codage. Par exemple : l’utilisateur saisit une erreur dans la valeur limite lors du processus de vérification.
L’objectif principal des tests d’intégration est d’aborder les problèmes possibles dans la conception détaillée, en particulier pour vérifier les erreurs possibles dans l’interface entre chaque unité et d’autres parties du programme.
Les tests du système sont principalement destinés à la conception des grandes lignes, en vérifiant si le système dans son ensemble fonctionne efficacement. Par exemple : si les hautes performances attendues sont atteintes dans les paramètres du produit.
Les tests d’acceptation sont généralement effectués par des experts métier ou des utilisateurs pour confirmer que le produit peut réellement répondre aux besoins métier de l’utilisateur.

Modèle incrémental

Les modèles incrémentaux, comme les modèles de mise en œuvre de prototypes et d’autres méthodes évolutives, sont essentiellement itératifs. Mais contrairement à la mise en œuvre du prototype, le modèle incrémental met l’accent sur le fait que chaque incrément libère un produit utilisable. Les premiers incréments sont la version « détachable » du produit final, mais ils fournissent des fonctions de service utilisateur et fournissent une plate-forme d’évaluation pour les utilisateurs.

La particularité du modèle incrémental est l’introduction du concept de packages incrémentaux. Vous n’avez pas besoin d’attendre que toutes les exigences soient publiées, tant que les packages incrémentiels d’une certaine exigence sortent, vous pouvez commencer le développement. Bien qu’un certain package incrémental doive être adapté davantage aux besoins des clients et doive être modifié, tant que le package incrémental est suffisamment petit, son impact peut être supportable pour l’ensemble du projet.

Modèle RAD Le modèle de développement rapide d’applications (RAD) est un modèle de processus de développement logiciel incrémental qui met l’accent sur un cycle de développement très court.

Le modèle RAD est une variante « haute vitesse » du modèle en cascade, qui gagne un développement rapide grâce à l’utilisation intensive de composants réutilisables et à une méthode de construction basée sur les composants. Si les exigences sont bien comprises et que la portée du projet est limitée, ce modèle peut être utilisé pour créer rapidement un « système d’information » entièrement fonctionnel.

Le processus commence par la modélisation métier, suivie de la modélisation des données, de la modélisation des processus, de la génération d’applications, des tests et de l’itération. Le processus logiciel utilisant le modèle RAD est illustré dans la figure ci-dessous.

Les tâches à accomplir dans chaque période d’activité du modèle RAD sont les suivantes.

Modélisation métier : quelles informations pilotent le fonctionnement du processus métier ? Quelles informations générer ? Qui l’a généré ? Où va le flux d’informations ? Qui s’en chargera ? Peut être complété par des diagrammes de flux de données.

Modélisation des données : afin de prendre en charge le flux de données du processus métier, recherchez la collection d’objets de données, définissez les attributs des objets de données et formez le modèle de données avec la relation avec d’autres objets de données, qui peuvent être complétés par des diagrammes ER .

Modélisation de processus : permet aux objets de données de remplir diverses fonctions commerciales dans le flux d’informations. Le processus de création décrit l’ajout, la modification, la suppression et la recherche d’objets de données, c’est-à-dire le raffinement de la boîte de traitement dans le diagramme de flux de données.

Génération du programme d’application : utilisez le langage de quatrième génération (4GL) pour écrire le programme de traitement, réutiliser les composants existants ou créer de nouveaux composants réutilisables, et utilisez les outils fournis par l’environnement pour générer et construire automatiquement l’ensemble du système d’application.

Les tests et la livraison, en raison d’une grande quantité de réutilisation, ne font généralement que des tests globaux, mais les composants nouvellement créés doivent encore être testés.

Modèle basé sur les composants

Composant (Component) est une unité logicielle à valeur réutilisable et aux fonctions relativement indépendantes. Le modèle de développement logiciel basé sur les composants (CBSD) consiste à utiliser une approche modulaire pour modulariser l’ensemble du système et, avec le soutien d’un certain modèle de composant, réutiliser un ou plusieurs composants logiciels dans la bibliothèque de composants, par combinaison Le processus de construction d’un logiciel d’application systèmes à haut rendement et de haute qualité.

Le modèle de développement basé sur les composants intègre de nombreuses caractéristiques du modèle en spirale, et est essentiellement évolutif, et le processus de développement est itératif. Le modèle de développement basé sur les composants comprend cinq étapes : analyse et définition des exigences logicielles, conception de l’architecture, établissement de la bibliothèque de composants, construction du logiciel d’application, test et publication.

Méthode prototype

Le prototype logiciel est la réalisation partielle du nouveau produit proposé. L’objectif principal de l’établissement du prototype est de résoudre le problème de la demande incertaine au stade précoce du développement du produit. Son objectif est de clarifier et d’améliorer les exigences, d’explorer les options de conception et de développer le produit final.

Il existe de nombreuses façons de classer les prototypes. Du point de vue de savoir si le prototype réalise ses fonctions, les prototypes logiciels peuvent être divisés en deux types : les prototypes horizontaux et les prototypes verticaux.

Les prototypes horizontaux sont également appelés prototypes de comportement, qui sont utilisés pour explorer certains comportements spécifiques du système attendu et atteindre l’objectif d’affiner les exigences. Les prototypes horizontaux ne sont généralement que la navigation des fonctions, mais ils n’implémentent pas réellement les fonctions. Le prototype horizontal est principalement utilisé sur l’interface.

Les prototypes verticaux sont aussi appelés prototypes structurés, qui implémentent une partie de leurs fonctions. Les prototypes verticaux sont principalement utilisés dans la réalisation d’algorithmes complexes.

Méthode XP

XP est une méthode de développement logiciel légère (agile), efficace, à faible risque, flexible, prévisible, scientifique et amusante. Par rapport aux autres méthodologies, la plus grande différence réside dans :

Fournir des commentaires spécifiques et continus plus tôt dans une période plus courte.
Planification itérative, générant d’abord un plan directeur rapidement au tout début, puis le développant continuellement tout au long du processus de développement du projet.
Appuyez-vous sur des procédures de test automatisées pour surveiller la progression du développement et détecter les défauts au plus tôt.
Fiez-vous à la communication verbale, aux tests et à la communication du programme source.
Préconiser une conception évolutive continue.
S’appuyer sur une collaboration étroite au sein de l’équipe de développement.
Essayez d’équilibrer autant que possible les intérêts à court terme du programmeur et les intérêts à long terme du projet.

Méthode de processus unifié (UP)

Le processus unifié est un cadre de processus général qui peut faire face à un large éventail de systèmes logiciels, différents domaines d’application, différents types d’organisation, différents niveaux de performance et différentes échelles de projet. UP est basé sur des composants, ce qui signifie que le système logiciel qu’il a développé est composé de composants et que les composants sont connectés les uns aux autres via des interfaces bien définies. Lors de la préparation de tous les plans du système logiciel, UP utilise le langage de modélisation unifié UML.

Par rapport à d’autres processus logiciels, UP présente trois caractéristiques notables : use case-driven, centré sur l’architecture de base, itération et incrémentation. Le processus logiciel dans Rational Unified Process se décompose en quatre phases séquentielles dans le temps, à savoir la phase initiale, la phase de raffinement, la phase de construction et la phase de livraison. A la fin de chaque étape, une revue technique doit être organisée pour déterminer si les objectifs de cette étape ont été atteints. Si les résultats de l’examen sont satisfaisants, le projet peut être autorisé à passer à l’étape suivante.