Cycles de Vie et Modèles de Développement de Systèmes

Cycle de Vie Classique du Développement Systèmes

Le modèle de cycle de vie du développement des systèmes (SDLC) est l'ensemble des activités que les analystes, les concepteurs et les utilisateurs entreprennent pour développer et mettre en œuvre un système d'information. L'approche cycle de vie du développement des systèmes se compose de 6 phases :

1. Recherche préliminaire : La demande d'aide d'un système d'information peut survenir pour plusieurs raisons. Quelles qu'elles soient, le processus commence toujours par la demande d'une personne.
2. Détermination des besoins du système : L'aspect clé de l'analyse des systèmes est de comprendre toutes les facettes importantes de l'entreprise qui est à l'étude.
3. Conception du système : La conception d'un système d'information produit des détails qui établissent la façon dont le système répondra aux besoins identifiés au cours de la phase d'analyse. Les spécialistes en systèmes se réfèrent souvent à la phase de conception logique, par opposition au développement de logiciels, qui est appelé conception physique.
4. Développement du logiciel : Le logiciel chargé d'élaborer le logiciel peut être installé en vérifiant auprès de tiers ou en écrivant des programmes adaptés au demandeur. Le choix dépend du coût de chaque solution, du temps disponible pour écrire le logiciel et de la disponibilité de programmeurs.

En général, les développeurs qui travaillent dans les grandes organisations appartiennent à un groupe de statut professionnel.

5. Test : Lors du test du système, le système est utilisé à titre expérimental afin de s'assurer que le logiciel n'a pas de défauts, c'est-à-dire qu'il fonctionne conformément aux spécifications et de la manière attendue par les utilisateurs.

Les données d'essai sont introduites pour traitement et les résultats sont ensuite examinés.

6. Mise en œuvre et évaluation : La mise en œuvre est le processus consistant à vérifier et installer de nouveaux équipements, former les utilisateurs, installer l'application et construire tous les fichiers nécessaires à l'utilisation des données. Une fois installées, les applications sont utilisées pendant de nombreuses années. Toutefois, les organisations et les utilisateurs changent au fil du temps, et même le milieu est différent avec le passage des semaines et des mois.

Par conséquent, il est clair que les applications doivent être maintenues. L'évaluation d'un système est effectuée afin d'identifier les forces et les faiblesses. L'évaluation a lieu selon l'une des dimensions suivantes :

• Évaluation opérationnelle : Évaluation de la façon dont fonctionne le système, y compris sa facilité d'utilisation, le temps de réponse, l'adéquation des formats d'information, la fiabilité globale et le niveau d'utilisation.
• Impact organisationnel : Identification et mesure des avantages pour l'organisation dans des domaines tels que les finances, l'efficacité opérationnelle et l'impact concurrentiel. Cela inclut également l'impact sur les flux externes et internes.
• Examen par les administrateurs : Évaluation des activités des gestionnaires et des administrateurs au sein de l'organisation et des utilisateurs finaux.
• Performance du développement : Processus d'évaluation du développement fondé sur des critères comme le temps et l'effort de développement, la conformité avec les budgets et les normes, et d'autres critères pour l'administration des projets. Cela inclut également l'évaluation des méthodes et outils utilisés dans le développement.

Modèle de Prototypage

Les prototypes sont des versions préliminaires du futur système à mettre en œuvre.

Le prototypage d'un système d'information est une technique intéressante pour la collecte rapide d'informations précises sur les besoins en information des utilisateurs.

Les prototypes devraient être développés plus tôt dans le cycle de vie du développement des systèmes, au cours de la phase de détermination des besoins.

De cette façon, l'analyste obtient les premières réactions des utilisateurs et de l'administration sur le prototype. Les suggestions de modifications ou d'améliorations du système pour la construction d'un prototype, les innovations potentielles et les plans détaillés pour revoir cette partie du système doivent être élaborés en premier.

Types de Prototypes

• Prototype jetable (Patchwork) : Un système qui a toutes les fonctionnalités proposées, mais qui est en fait un modèle de base qui sera éventuellement amélioré. Ce type de prototype fonctionne, mais n'est ni efficace ni élégant.
• Prototype non fonctionnel : La deuxième conception d'un prototype est un modèle réduit ou non fonctionnel dans le but de tester certains aspects de la conception. Cela peut être fait lorsque le codage requis par les applications est assez large pour être prototypé, et pourtant vous pouvez vous faire une idée utile du système en développant des prototypes de l'entrée et de la sortie seulement.

Vous pouvez recueillir les commentaires des utilisateurs sur les interfaces (entrée et sortie). En raison du coût excessif, tout ne peut pas être fait, cependant vous pouvez inclure quelques utilitaires du système basés sur l'entrée et la sortie dans le prototype.

• Premier prototype d'une série (Pilote) : Un troisième concept de prototypage implique la création d'un premier modèle à grande échelle ou d'un système, également appelé pilote.

Ce type de prototype est utile lorsque vous avez planifié de nombreuses installations d'un même système. Le modèle à grande échelle ou fonctionnel permet une interaction réaliste avec le nouveau système, tout en minimisant le coût lié à la résolution des problèmes qu'il présente.

• Prototype de fonctions sélectionnées : Un prototype de fonctions sélectionnées permet de mettre en place le système tandis que d'autres fonctionnalités peuvent être ajoutées ultérieurement.

Il s'agit de construire un modèle opérationnel qui inclut certaines, mais pas toutes, des caractéristiques du système final.

Lors de la construction de ce type de prototype, le système est construit en modules. Si les caractéristiques sont jugées satisfaisantes, elles peuvent être incorporées dans le système final sans nécessiter un travail énorme sur les interfaces. Les prototypes réalisés dans ce cadre s'intègrent dans le système actuel et ne sont pas seulement un modèle.

Développement d'un Prototype

Au moment de décider s'il convient d'inclure le développement de prototypes dans le cadre du cycle de vie du développement des systèmes, l'analyste doit tenir compte du type de problème à résoudre et de la manière dont le système apporte la solution.

Lignes directrices pour le développement d'un prototype

1. Modules gérables : Il est bon que l'analyste mette en pratique le prototypage en modélisant certaines caractéristiques d'un système pour obtenir un modèle fonctionnel. Un modèle souple permet l'interaction avec ses principales caractéristiques, mais d'autres modules peuvent encore être construits en dehors du système. Les fonctionnalités considérées comme moins importantes sont intentionnellement omises du prototype initial.
2. Construction rapide du prototype : La vitesse est essentielle au succès du développement d'un prototype. Le prototype permet de raccourcir le temps d'interaction de l'utilisateur avec le système afin qu'il puisse commencer à l'expérimenter.

Les techniques de collecte d'informations traditionnelles telles que les entretiens, les observations et la recherche de données dans les fichiers sont utilisées.

Le développement d'un prototype devrait être réalisé en une semaine. Pour construire un prototype aussi rapidement, il faut utiliser des outils spéciaux tels que des systèmes d'administration de bases de données et des logiciels permettant une entrée et une sortie généralisées.

À ce stade du cycle de vie, l'analyste continue de recueillir des informations sur ce dont les utilisateurs du système ont besoin et ce qu'ils souhaitent.

Mettre en place rapidement un prototype opérationnel aux premiers stades du cycle de vie du développement du système permet d'obtenir des commentaires précieux sur la manière dont le reste du projet devrait être mené. Ainsi, cela montre à l'utilisateur comment fonctionnent certaines parties du système.

3. Amendements au prototype : Une troisième ligne directrice pour le développement du prototype est d'être flexible face aux changements futurs. Cela signifie que la création de modules ne doit pas les rendre fortement interdépendants.

En général, le prototype est modifié à plusieurs reprises en passant par plusieurs itérations. Les modifications apportées au prototype devraient rapprocher le système de ce que les utilisateurs jugent important.

Chaque amendement nécessite une évaluation plus poussée par les utilisateurs. Ces modifications doivent être apportées rapidement, en un jour ou deux, cela dépend aussi de la vitesse à laquelle l'utilisateur effectue l'évaluation.

4. Accent sur l'interface utilisateur : L'interface utilisateur du prototype (et éventuellement du système) est très importante car l'objectif principal du prototype est de permettre aux utilisateurs de visualiser leurs besoins croissants. L'information devrait être structurée de manière à permettre une interaction facile avec le prototype du système.

L'objectif de l'analyste est de concevoir une interface qui permet à l'utilisateur d'interagir avec le système avec une formation minimale et permet un contrôle maximum de l'utilisateur sur les fonctions représentées.

Inconvénients du prototypage

• Il est difficile de gérer le développement de prototypes comme un projet pour les grands systèmes.
• Les utilisateurs et les analystes peuvent considérer un prototype comme un système fini alors qu'il ne l'est pas.

Avantages du prototypage

• Il est possible d'apporter des changements au système dans les premiers stades de développement.
• Il est possible d'arrêter le développement d'un système qui n'est pas fonctionnel.
• Il permet de mieux cerner les besoins et attentes des utilisateurs.

Le Modèle RAD

Le Rapid Application Development (RAD) est un modèle de processus de développement de logiciels séquentiel linéaire qui met l'accent sur un cycle de développement très court.

Il s'agit d'une approche de construction basée sur les composants.

Le RAD comprend les étapes suivantes :

• Modélisation de la gestion : Le flux d'informations entre les fonctions de l'entreprise est modélisé d'une manière qui répond aux questions suivantes :
  • Quelles informations sont le moteur du processus d'affaires ?
  • Quelles informations sont générées ?
  • Qui les génère ?
  • Où se trouve l'information ?
  • Qui la traite ?
• Modélisation des données : La circulation de l'information définie dans le cadre de la phase de modélisation de la gestion est affinée en un ensemble d'objets de données nécessaires pour soutenir l'entreprise. Cela inclut la définition des caractéristiques (appelées attributs) de chacun des objets et les relations entre ces objets.
• Modélisation des processus : Les objets de données définis dans la phase de modélisation des données sont transformés pour créer le flux d'informations nécessaire à la mise en œuvre d'une fonction de gestion. Des descriptions de processus sont créées pour :
  • Ajouter
  • Modifier
  • Supprimer
  • Ou récupérer un objet de données.
• Génération d'applications : Le RAD suppose l'utilisation de techniques de quatrième génération. Au lieu de créer des logiciels à l'aide de langages de programmation de troisième génération, le processus RAD consiste à réutiliser des composants de programme existants (si possible) ou à créer des composants réutilisables (si nécessaire). Dans tous les cas, des outils automatisés sont utilisés pour faciliter la construction de logiciels.
• Test et livraison : Comme le processus RAD met l'accent sur la réutilisation, plusieurs composants des programmes ont déjà été testés. Cela réduit le temps de test. Cependant, tous les nouveaux composants doivent être testés et toutes les interfaces doivent être soigneusement vérifiées.

• Le RAD décompose le système en composants. Chacun d'eux peut être développé par une équipe différente, puis intégré dans l'application finale.

Modèles de Processus Logiciels Évolutifs

Le logiciel, comme tout système complexe, évolue au fil du temps.

Les modèles évolutifs sont itératifs.

Ils se caractérisent par la manière dont ils permettent aux ingénieurs logiciels de développer des versions de plus en plus complètes du logiciel.

Modèle Incrémental

• Le modèle incrémental combine des éléments du modèle séquentiel linéaire (appliqué de façon répétitive) avec la philosophie interactive du prototypage.
• Chaque séquence linéaire produit un "incrément" du logiciel.
• Lorsque vous utilisez un modèle incrémental, le premier incrément est souvent un élément essentiel (de base), répondant aux exigences fondamentales. De nombreuses fonctions supplémentaires (dont certaines sont connues, d'autres non) ne sont pas incluses initialement.
• Ce processus est répété après la livraison de chaque incrément, jusqu'à ce que le produit complet soit développé.
• Contrairement au prototypage, le modèle incrémental se concentre sur la livraison d'un produit opérationnel avec chaque incrément.
• Les premiers incréments sont "nettoyés" pour le produit final, mais offrent la possibilité de servir l'utilisateur et fournissent également une plate-forme pour l'évaluation par l'utilisateur.

Modèle Incrémental (Suite)

Dans une approche générique, le processus est divisé en 4 parties : analyse, conception, codage et test. Pour la production de logiciels, le principe du travail en ligne est utilisé, comme dans de nombreuses autres formes de programmation. Le client est maintenu en contact constant avec les résultats de chaque incrément. C'est le client lui-même qui valide les éléments à la fin de chaque incrément, de sorte que le logiciel est mieux adapté à ses besoins réels. Le processus est répété jusqu'à ce que le produit complet soit développé.

Ainsi, le délai d'exécution est considérablement réduit.

Comme d'autres méthodes de modélisation, le modèle incrémental est de nature itérative, mais diffère de celles où la fin de chaque incrément fournit un produit entièrement opérationnel.

Le modèle incrémental est particulièrement utile lorsqu'il n'y a pas suffisamment de personnel. Les premières étapes peuvent être réalisées par un petit groupe de personnes, et du personnel peut être ajouté à chaque incrément si nécessaire. D'autre part, les incréments peuvent être planifiés pour gérer les risques techniques.

Caractéristiques du Modèle Incrémental

• Évite les grands projets et fournit "quelque chose de valeur" aux utilisateurs avec une certaine fréquence.
• L'interaction utilisateur peut être plus complexe à gérer.
• Difficile d'évaluer le coût total.
• Difficile à appliquer aux systèmes transactionnels qui ont tendance à être intégrés et fonctionnent comme un tout.
• Nécessite des gestionnaires expérimentés.
• Les erreurs dans les exigences peuvent être détectées tardivement.
• Le résultat peut être très positif.

Avantages du Modèle Incrémental

• Réduit le temps de développement initial car la fonctionnalité est mise en œuvre en partie.
• Fournit un impact bénéfique pour le client grâce à la livraison rapide de parties opérationnelles du logiciel.
• Le modèle offre les avantages de la rétroaction du modèle en cascade tout en réduisant ses inconvénients à chaque incrément.
• Permet de fournir un produit au client plus rapidement par rapport au modèle en cascade.
• Il est plus facile de s'adapter aux changements en limitant la taille des incréments.
• Sa polyvalence nécessite une planification rigoureuse au niveau administratif et technique.

Inconvénients du Modèle Incrémental

• Le modèle incrémental n'est pas recommandé pour les systèmes temps réel, les systèmes à haut niveau de sécurité, le traitement distribué et/ou les projets à indice de risque élevé.
• Nécessite beaucoup de planification, tant administrative que technique.
• Exige des objectifs clairs pour l'avancement du projet.

Modèle d'Assemblage de Composants

• Le modèle d'assemblage de composants incorpore plusieurs caractéristiques du modèle en spirale.
• Il a un caractère évolutif et nécessite une approche itérative pour la création de logiciels.
• Cependant, ce modèle assemble des applications à partir de composants logiciels préparés (parfois appelés classes).
• Il commence par l'identification des classes candidates.
• Il examine les données qui seront traitées et applique un algorithme de traitement.
• Ensuite, les données sont encapsulées dans une classe.
• Les classes (composants) créées sont enregistrées dans les bibliothèques de classes.
• Après avoir identifié les classes candidates, la bibliothèque de classes est examinée pour voir si ces classes existent déjà.
• Études sur la réutilisation :
• Il est rapporté que l'assemblage de composants conduit à une réduction de 70 % du temps de cycle de développement.
• 84 % des coûts du projet.
• Un indice de productivité de 26,2 %.
• Par rapport à la norme de l'industrie de 16,9 %.
• Il ne fait aucun doute que l'assemblage de composants offre des avantages significatifs pour les ingénieurs logiciels.

Modèle de Développement Simultané

• Le modèle de développement simultané, parfois également appelé ingénierie simultanée.
• Il est basé sur le principe que de nombreuses phases du développement de logiciels sont exécutées simultanément.
• L'idée est de modéliser ce processus de manière concurrente.
• Il tente de modéliser ce processus sous forme d'esquisse comme une série d'activités importantes, de tâches et de conditions qui leur sont associées.

Le modèle de développement concurrent, également connu sous le nom d'ingénierie simultanée, proposé par Davis Sitaram, peut être représenté sous forme d'esquisse comme une série d'activités, de tâches et de conditions importantes qui leur sont associées.

Ce modèle est souvent utilisé comme paradigme pour le développement d'applications client/serveur. Il fournit une méta-description des processus logiciels. Le modèle concurrent est capable de décrire les nombreuses activités qui se produisent simultanément dans le développement logiciel.

La plupart des modèles de processus de développement logiciel sont axés sur le temps, plus vous avancez dans le processus de développement. Un modèle de processus concurrent est axé sur les besoins des utilisateurs, les décisions de gestion et les résultats des examens. Le modèle de processus concurrent définit une série d'événements qui déclenchent les transitions d'un état à un autre pour chacune des activités du génie logiciel. Pendant les premiers stades de la conception, une incohérence n'est pas considérée comme une erreur du modèle d'analyse. Ce modèle génère l'analyse d'événements correcte, ce qui déclenche l'analyse de l'activité des modifications apportées à l'état de veille. Il s'agit d'un type de modèle de réseau où toutes les personnes agissent simultanément ou en parallèle.

Un système client/serveur se compose d'un ensemble de composants fonctionnels. Lorsqu'il est appliqué au client/serveur, le modèle de processus définit les activités concurrentes selon deux dimensions :

• Taille des systèmes
• Dimension des composants

Les aspects au niveau du système sont abordés en trois phases : conception, assemblage et utilisation. En fait, le modèle de processus concurrent est applicable à tous les types de développement de logiciels et fournit une image précise de l'état d'un projet.

La concurrence est réalisée de deux façons :

1. Les activités au niveau des systèmes et des composants se produisent simultanément et peuvent être modélisées avec une approche orientée objet.
2. Une application client/serveur est généralement mise en œuvre avec de nombreux composants, dont chacun peut être conçu et réalisé en même temps.

Avantages du Modèle Simultané

• Idéal pour les projets qui impliquent des groupes de travail distincts.
• Fournit une image précise de l'état d'un projet.

Inconvénients du Modèle Simultané

• Si les conditions ci-dessus ne s'appliquent pas.
• S'il n'y a pas de groupes de travail, cette méthode ne peut pas fonctionner.

Modèle Unifié (UML)

Introduction au Modèle Unifié (UML)

UML a émergé dans les années 90 suite à la recherche d'un langage de modélisation pour unifier une industrie en croissance qui a suivi la "guerre des méthodes" des années 70 et 80. Bien que principalement développé à partir de plusieurs méthodes orientées objet de deuxième génération (au niveau de la notation), UML n'est pas seulement un langage de modélisation orienté objet de troisième génération. Sa portée s'étend au-delà de l'utilisation de ses prédécesseurs. C'est l'expérience, l'expérimentation et l'adoption progressive de la norme qui révéleront son vrai potentiel et permettront aux organisations de réaliser ses bénéfices.

Qu'est-ce que UML ?

C'est un langage de modélisation pour spécifier, visualiser, construire et documenter les artefacts d'un processus de système intensif.

Dans le processus d'un système intensif, une méthode est appliquée pour aboutir ou évoluer vers un système.

En tant que LANGAGE, il est utilisé pour la communication. C'est une façon de capter le savoir (sémantique) sur un sujet et d'exprimer (syntaxe) cette connaissance dans le but de communiquer. Le sujet est le système à l'étude.

En tant que langage de modélisation, il se concentre sur la compréhension d'un sujet à travers la formulation d'un modèle de l'objet (et de son contexte respectif). Le modèle inclut la connaissance du sujet, et l'application appropriée de cette connaissance est l'intelligence.

Il prend en charge l'unification, intégrant les meilleures pratiques de l'industrie de l'ingénierie et des systèmes d'information à travers tous les types de systèmes (logiciels et non logiciels), les domaines (affaires ou logiciel) et les processus du cycle de vie.

Tel qu'il est appliqué pour spécifier comment les systèmes peuvent être utilisés pour communiquer "ce qui" est nécessaire d'un système et "comment" un système peut être réalisé.

Quant à savoir comment il s'applique aux systèmes d'affichage, il peut être utilisé pour décrire visuellement un système avant qu'il ne soit exécuté.

Quant à savoir comment il s'applique aux systèmes de construction, il peut être utilisé pour guider la mise en œuvre d'un système, similaire à un "plan".

Quant à savoir comment il s'applique à la documentation des systèmes, il peut être utilisé pour capturer les connaissances sur un système tout au long du cycle de vie du processus.

UML n'est pas :

• Un langage de programmation visuel, mais un langage de modélisation visuelle.
• Un outil ou une spécification de stockage, mais un langage de spécification pour la modélisation.
• Un processus, mais il active les processus.

Fondamentalement, UML est lié à la capture, la communication et la structuration (en niveaux) de la connaissance.

Utilité d'UML

UML est un langage de modélisation évolutif à usage général, largement applicable, qui peut être soutenu par des outils standardisés et industriels. Il s'applique à une multitude de types de systèmes, de domaines, de méthodes et de processus différents.

En tant que langage d'usage général, il se concentre sur un ensemble de concepts fondamentaux pour l'acquisition, le partage et l'utilisation des connaissances, couplé à des mécanismes d'extension.

En tant que langage de modélisation largement applicable, il peut être appliqué à différents types de systèmes (logiciels et non logiciels), domaines (affaires ou logiciel) et méthodes et processus.

En tant que langage pris en charge par les outils, des outils sont disponibles pour soutenir la mise en œuvre du langage afin de spécifier, visualiser, construire et documenter les systèmes.

En tant que norme industrielle pour la modélisation, le langage n'est pas fermé ou propriétaire, mais plutôt un langage extensible et entièrement ouvert reconnu par l'industrie.

UML permet la capture, la communication et la structuration des connaissances aux niveaux stratégique, tactique et opérationnel afin de faciliter l'augmentation de la valeur, l'amélioration de la qualité, la réduction des coûts et des délais de mise sur le marché, la gestion des risques et d'être proactif face à l'augmentation potentielle de la complexité et au changement.

Modèle d'Assemblage de Composants et Méthodes Formelles

Le modèle de développement basé sur les composants intègre de nombreuses caractéristiques du modèle en spirale. Il a un caractère évolutif et nécessite une approche itérative pour la création de logiciels. Ce modèle assemble des applications à partir de composants logiciels préparés (classes).

C'est ainsi que, s'ils sont correctement conçus et mis en œuvre, les composants basés sur les classes d'objets sont réutilisables pour différentes applications et architectures de systèmes informatiques.

Tout d'abord, il faut identifier les classes candidates en examinant les données qui seront traitées par l'application et l'algorithme qui sera créé pour le traitement. Si ces classes ont été créées par des programmes antérieurs, elles sont stockées dans une bibliothèque de classes ou un dépôt. Ensuite, on détermine lesquelles existent déjà afin de les réutiliser.

Le modèle de développement basé sur les composants met l'accent principal sur la réutilisation du logiciel, et la réutilisation offre des avantages aux ingénieurs logiciels. Des études sur la réutilisation, comme celles de QSM Associates, Inc., rapportent que l'assemblage de composants conduit à une réduction de 70 % du cycle de développement, 84 % des coûts du projet et un indice de productivité de 26,2 %. Il ne fait aucun doute que l'assemblage de composants offre des avantages significatifs pour les ingénieurs logiciels.

Avantages du Modèle d'Assemblage de Composants

L'utilisation de ce paradigme présente certains avantages :

1. Réutilisation du logiciel.
2. Simplifie les tests.
3. Simplifie la maintenance du système.
4. Amélioration de la qualité.

Concepts liés aux Composants

• Notation des composants
• Diagramme de composants
• Interfaces
• Composants et nœuds (diagramme de déploiement)
• Restrictions
• Analyse des risques
• Avantages et inconvénients

Conclusion sur le Modèle d'Assemblage de Composants

Ce modèle est basé sur la construction d'une bibliothèque de composants (classes/objets) pour chaque système. Pour construire un nouveau système, le processus consiste à définir les objets nécessaires, rechercher les objets existants dans la bibliothèque, construire ceux qui n'existent pas, les ajouter à la bibliothèque, puis assembler les objets. La méthode cherche à évoluer à travers des phases de planification, d'analyse des risques, d'ingénierie, de construction et d'adaptation, et d'évaluation par les clients. Ces étapes sont répétées de sorte que les premières itérations développent des concepts, continuent à développer de nouveaux composants, puis cherchent à améliorer et enfin assurer la maintenance.

Modèle en Spirale

Le modèle en spirale pour le génie logiciel a été développé pour mieux répondre aux caractéristiques du cycle de vie classique et de la création de prototypes, tout en ajoutant un nouvel élément : l'analyse des risques.

Les processus qui se déroulent au sein d'un modèle en spirale sont :

• Communication avec les clients : Rationaliser l'interaction développeur - client.
• Planification : Définition des ressources, du temps et d'autres informations liées au projet.
• Analyse des risques : Évaluation et gestion des risques techniques.
• Ingénierie : Construction d'une ou plusieurs représentations de l'application.
• Construction et adaptation : Travaux de construction, tests et installation de l'application.
• Évaluation par le client : Réaction des clients face à l'application obtenue à partir des phases d'ingénierie et de construction.

Cycles du Modèle en Spirale

• Développement de concepts
• Développement de nouveaux produits
• Amélioration de produits existants
• Maintenance du produit

Lors du premier cycle, les objectifs, les alternatives et les contraintes sont définis, et les risques sont analysés et identifiés.

Le client évalue le travail d'ingénierie (quadrant d'évaluation du client) et propose des modifications. Sur la base des commentaires du client, la phase suivante de planification et d'analyse des risques a lieu. Dans chaque boucle de la spirale, les résultats de l'analyse des risques aboutissent à une décision "continuer ou arrêter".

À chaque itération autour de la spirale (en commençant par le centre et en allant vers l'extérieur), les versions successives du logiciel deviennent de plus en plus complètes et, en définitive, constituent le système opérationnel lui-même.

Caractéristiques du Modèle en Spirale

• C'est un modèle évolutif qui combine le modèle classique et le prototypage.
• Inclut une étape d'analyse des risques.
• Il est idéal pour créer de meilleurs produits avec différentes versions, notamment pour les logiciels modernes sur micro-ordinateurs.
• L'ingénierie peut être développée selon le cycle de vie classique ou le prototypage.
• C'est l'approche la plus réaliste aujourd'hui.

Avantages du Modèle en Spirale

• Réduit les risques du projet.
• Incorpore des objectifs de qualité.
• Intègre le développement, la maintenance, etc.

Inconvénients du Modèle en Spirale

• Peut être long à développer.
• Modèle coûteux.
• Requiert de l'expérience dans l'identification des risques.