Le coût et les efforts sont faibles au début, culminent pendant l'exécution des travaux et retombent rapidement vers la fin du projet.

Le risque et l'incertitude sont plus importants au début du projet et diminuent progressivement tout au long du cycle de vie du projet à mesure que les décisions sont prises et que les livrables sont acceptés.

Impact des variables qui changent au fil du temps du projet

Le modèle en cascade est un modèle classique de cycle de vie des logiciels

Le modèle en cascade divise le développement logiciel en plusieurs étapes : analyse de faisabilité (planification), analyse des exigences, conception du logiciel (conception générale, conception détaillée), codage (y compris les tests unitaires), tests, exploitation et maintenance, etc.

Il existe une séquence et une dépendance entre les étapes : l'entrée de l'étape suivante ne peut être démarrée qu'une fois le travail de l'étape précédente terminé.

En utilisant cette entrée, que faut-il faire pour mettre en œuvre l'activité

Le succès du travail de cette activité est donné et transmis comme résultat à l'activité de développement suivante.

Examiner les résultats de la mise en œuvre de cette activité

Développer des logiciels à un coût relativement faible

La qualité est garantie à chaque étape du développement, réduisant ainsi les retouches

Une documentation méticuleuse réduit les coûts de communication et facilite la détection précoce des problèmes

Incapacité à résoudre les problèmes lorsque les exigences logicielles sont floues ou inexactes

Les risques ne sont souvent révélés que plus tard dans la phase de développement, et les opportunités de correction précoce sont perdues.

Puisqu’il s’agit d’un processus unique, les leçons apprises au cours du développement ne peuvent pas être réinjectées dans le processus d’application de ce produit.

Généralement des projets avec des besoins très clairs des utilisateurs

Petite échelle, exigences simples, projet à fonction unique

Projets de développement de logiciels avec des exigences claires et des délais assouplis

L'utilisateur possède certaines capacités et l'expression des besoins est précise

Le modèle en spirale est un modèle de processus logiciel évolutif qui combine les caractéristiques itératives de la mise en œuvre d'un prototype avec les aspects contrôlés et systématiques des modèles séquentiels linéaires (cascade).

Permet le développement rapide de versions incrémentielles de logiciels

Dans le modèle en spirale, le développement logiciel est une série de versions incrémentielles

Le processus de développement a une forme de spirale récurrente

Formuler des plans : définir des objectifs logiciels, sélectionner des plans de mise en œuvre et clarifier les contraintes de développement du projet ;

Analyse des risques : analyser les options sélectionnées et réfléchir à la manière d'identifier et d'éliminer les risques ;

Ingénierie de mise en œuvre : mettre en œuvre le développement de logiciels (les exigences, la conception, le codage, les tests, etc. sont promus dans un cycle en spirale)

Évaluation client : évaluer les résultats de développement de ce cycle, proposer des corrections et planifier le prochain cycle de travail.

L'accent mis sur les alternatives et les contraintes favorise la réutilisation des logiciels existants et aide également à considérer la qualité des logiciels comme un objectif important du développement de logiciels.

Réduction des sur-tests ou sous-tests

Il n’y a pas de différence essentielle entre maintenance et développement

Le coût de la gestion des risques est trop élevé. Dans l'analyse des risques, des exigences élevées sont imposées aux membres de l'équipe de projet.

Axé sur les risques, prêter attention aux risques, décider de poursuivre ou non le projet après analyse des risques

Le modèle en spirale met l'accent sur l'analyse des risques et est particulièrement adapté aux systèmes vastes et complexes avec des exigences peu claires et des risques élevés.

Le flux de travail principal décrit les composants statiques du modèle itératif d'un point de vue technique, notamment : la modélisation commerciale, l'élicitation des exigences, l'analyse et la conception, la mise en œuvre, les tests et le déploiement.

Dans un processus itératif, chaque phase comprend une proportion différente de toutes les activités

modèle itératif

Le modèle itératif du diagramme, avec la dimension temporelle dans le sens horizontal, décrit l'ensemble du cycle de vie du développement logiciel du point de vue de la gestion organisationnelle.

Il est divisé en quatre étapes : initialisation, raffinement, construction et transfert, qui peuvent être décrites plus en détail comme cycle, phase et itération.

Le flux de travail principal décrit les composants statiques du modèle itératif d'un point de vue technique, notamment : la modélisation commerciale, l'élicitation des exigences, l'analyse et la conception, la mise en œuvre, les tests et le déploiement.

La zone ombrée de la figure représente différents workflows avec différentes charges de travail sur différentes périodes. Presque tous les workflows ont des charges de travail sur toutes les périodes, mais leur taille est différente.

Phase initiale : élaborer systématiquement la portée du projet, sélectionner une architecture système réalisable, planifier et préparer l'analyse de rentabilisation

Étape d'élaboration : affiner l'idée, affiner le processus et l'infrastructure, affiner l'architecture et sélectionner les composants

Phase de construction : gestion des ressources, contrôle et optimisation des processus, terminer le développement des composants et les tester selon les critères d'évaluation, et évaluer la sortie du produit selon les critères d'acceptation du concept

Phase de transfert : synchroniser et intégrer les incréments de construction simultanés dans une base de mise en œuvre cohérente, les activités d'ingénierie liées à la mise en œuvre (emballage et production commerciaux, formation du personnel, etc.), évaluer la base de mise en œuvre par rapport aux critères d'acceptation de la vision complète et des exigences définies.

Convient au développement de logiciels avec des exigences peu claires et une difficulté relativement élevée

Modèle V

Le modèle V se compose de côtés gauche et droit. Il s'agit d'une structure symétrique qui indique clairement les différents niveaux qui existent dans le processus de test.

et décrit très clairement la correspondance entre ces phases de tests et les phases de développement.

Tests unitaires : vérifie si l'unité logicielle s'exécute correctement conformément aux spécifications de l'unité (instructions de conception détaillées) pour garantir que chaque plus petite unité peut fonctionner normalement, généralement effectuée par les développeurs.

Test d'intégration : vérifie si plusieurs unités fonctionnent ensemble comme décrit dans la conception générale du système. L'objectif principal des tests d'intégration est que le système puisse être compilé avec succès, que les principales fonctions commerciales puissent être réalisées et que les données entre les différents modules du système puissent communiquer normalement, etc.

Tests du système : vérifiez que l'ensemble du système répond aux spécifications des exigences

Tests d'acceptation : vérifier si le système répond aux exigences définies dans le contrat ou aux besoins de l'utilisateur du point de vue de l'utilisateur.

L'idée principale incarnée dans le modèle V est que le développement et les tests sont d'égale importance. Le côté gauche représente les activités de développement, tandis que le côté droit représente les activités de test.

Le modèle V possède un niveau de test correspondant à chaque étape de développement.

Les tests constituent toujours une étape du cycle de vie du développement. Contrairement au modèle en cascade, il existe plusieurs niveaux de tests correspondant aux étapes de développement.

Le modèle V est utilisé lorsque les exigences sont claires et que les exigences changent rarement.

Incapacité à résoudre les problèmes lorsque les exigences logicielles sont floues ou inexactes

Manque de flexibilité, s'appuyant sur des enquêtes précoces sur la demande et incapable de s'adapter aux changements de la demande

Les exigences et les technologies sont entièrement identifiées et comprises

modèle de prototypage

La première étape du prototypage du modèle consiste à créer un prototype rapide qui satisfasse les parties prenantes du projet et les futurs utilisateurs pour interagir avec le prototype.

Ensuite, grâce à des discussions et analyses approfondies avec les parties prenantes concernées, nous déterminons enfin les besoins du système actuel. Après une compréhension complète, nous développons un produit qui satisfait les utilisateurs sur la base du prototype.

Dans le processus de projet lui-même, avec l'aide des actifs de processus organisationnels et d'un logiciel de modélisation rapide, quelques prototypes simples peuvent généralement être établis lors de l'analyse de la demande.

Elle ne nécessite pas une enquête et une analyse complètes et détaillées du système, mais repose sur la compréhension préliminaire par le développeur des besoins des utilisateurs.

Développez d'abord rapidement un système prototype, puis implémentez les exigences système finales de l'utilisateur grâce à des modifications répétées.

Pratique et réalisable

Possède les caractéristiques de base du système final

Construction pratique, rapide et peu coûteuse

La caractéristique de la méthode prototype est que la méthode prototype répond de manière dynamique aux besoins des utilisateurs et les intègre progressivement. L'analyse, la conception et la mise en œuvre du système sont toutes réalisées simultanément avec la modification continue d'un modèle de travail. Il n'y a pas de frontières évidentes entre elles. répartition du travail

Le plan de développement du système est un processus de modifications répétées

prototype jetable

Prototype évolutif

Les clients peuvent proposer des objectifs généraux, mais ne peuvent pas spécifier des exigences détaillées en matière d'entrée, de traitement et de sortie ; ou les développeurs ne peuvent pas déterminer l'efficacité des algorithmes, l'adaptabilité des systèmes d'exploitation et la forme d'interaction homme-machine.

L'utilisateur définit un ensemble d'objectifs généraux mais ne peut pas identifier les exigences détaillées en matière d'entrée, de traitement et de sortie ;

Les développeurs peuvent ne pas être sûrs de l’efficacité des algorithmes, de l’adéquation des systèmes d’exploitation ou de la forme d’interaction homme-machine.

Il combine les composants de base du modèle en cascade avec les caractéristiques itératives des prototypes. Utilisez une séquence linéaire qui s’échelonne à mesure que le temps progresse.

Analyser, concevoir, coder, tester et publier des produits logiciels sous la forme d'une série de blocs de construction incrémentiels.

L'incrément de première étape est souvent le produit principal

Chaque incrément de phase est une version publiable, et les premiers incréments sont des versions « détachables » du produit final.

Puisque l’augmentation initiale constitue la base des augmentations ultérieures, si les exigences de l’augmentation initiale doivent être modifiées, cela peut affecter les augmentations ultérieures.

Trop d’incréments entraîneront des dépassements de coûts de gestion et affecteront les progrès.

L'allocation du personnel est flexible, il n'est donc pas nécessaire d'investir beaucoup de ressources humaines au début. Lorsque le produit de base est très populaire, davantage de main d'œuvre peut être ajoutée pour atteindre l'étape suivante d'augmentation. Les gens peuvent travailler en parallèle en même temps.

Les pièces avec des exigences claires peuvent être mises en œuvre par étapes, en optimisant progressivement les exigences du système et en intégrant progressivement les éléments du système.

La livraison progressive permet de lancer le produit de base en premier lorsque le personnel ne peut pas terminer le produit dans le délai fixé ou lorsque les exigences du client/du marché sont urgentes. De cette manière, des fonctions partielles sont livrées aux clients par étapes, ce qui agit comme un sédatif. rôle des clients.

Convient aux projets logiciels avec des exigences progressivement claires

Le produit peut être divisé en différentes étapes et complété séparément.