Quels sont les modèles courants de développement de logiciels ?

Les modèles de développement de logiciels courants incluent : 1. Modifier pendant la réalisation du modèle ; 2. Modèle de cascade ; 3. Modèle de prototypage rapide ; 4. Modèle en spirale ; 6. Modèle de fontaine ; ; 9. Modèle RUP ; 10. Modèle IPD.

L'environnement d'exploitation de ce tutoriel : système Windows 10, ordinateur Dell G3.

Les modèles courants de développement de logiciels sont :

1. Modèle Build-and-Fix

Malheureusement, de nombreux produits sont développés à l'aide du modèle "Build-and-Fix". Dans ce modèle, il n'y a ni spécifications ni conceptions, et le logiciel est constamment modifié encore et encore selon les besoins des clients. Dans ce modèle, les développeurs récupèrent le projet et écrivent immédiatement le programme selon les exigences. Après le débogage, la première version du logiciel est générée. Après avoir été fourni aux utilisateurs, si une erreur se produit dans le programme ou si l'utilisateur fait de nouvelles exigences, le développeur modifiera à nouveau le code jusqu'à ce que l'utilisateur soit satisfait. Il s'agit d'une méthode de développement de type atelier, qui convient pour écrire de petits programmes de quelques centaines de lignes, mais cette méthode n'est pas satisfaisante pour le développement à toute échelle. Le problème principal est :

( 1) Manque de liens de planification et de conception, la structure du logiciel se détériore avec des modifications continues, rendant impossible toute modification continue ;

(2) Ignorer le lien de demande comporte de grands risques pour le développement de logiciels 

(3) Sans tenir compte de la maintenabilité des tests et des programmes, et sans aucune documentation, la maintenance du logiciel est très difficile.

2. Modèle Waterfall

En 1970, Winston Royce a proposé le fameux « Modèle Waterfall ». Jusqu'au début des années 1980, c'était le seul modèle de développement logiciel largement adopté. Dans le modèle en cascade, comme le montre la figure, le cycle de vie du logiciel est divisé en six activités de base telles que la planification, l'analyse des besoins, la conception du logiciel, l'écriture du programme, les tests, l'exploitation et la maintenance du logiciel, et leurs activités descendantes et interconnectées sont stipulé. Une séquence fixe, comme une cascade, tombant pas à pas. Dans le modèle en cascade, diverses activités de développement logiciel sont réalisées de manière strictement linéaire. L'activité en cours accepte les résultats de l'activité précédente et met en œuvre le contenu de travail requis. Les résultats du travail de l'activité en cours doivent être vérifiés. Si la vérification réussit, le résultat sera utilisé comme entrée de l'activité suivante et l'activité suivante sera poursuivie. Sinon, il sera renvoyé pour modification. Le modèle en cascade met l'accent sur le rôle de la documentation et nécessite une vérification minutieuse à chaque étape. Cependant, le processus linéaire de ce modèle est trop idéal et ne convient plus aux modèles modernes de développement de logiciels. Il a presque été abandonné par l'industrie. Ses principaux problèmes sont :

(1) La division de chaque étape est complètement fixe, et un grand nombre de problèmes surviennent entre les étapes de documentation, augmentant considérablement la charge de travail

(2) Le modèle de développement étant linéaire, les utilisateurs ne peuvent voir les résultats du développement que jusqu'à la fin du processus complet, augmentant ainsi le risque de développement ; ;

(3) Des erreurs précoces sont possibles. Elles ne peuvent être découvertes qu'au cours de la phase de test à un stade ultérieur du développement, ce qui peut avoir de graves conséquences.

Nous devons réaliser que « linéaire » est la façon de penser la plus simple à maîtriser et à appliquer habilement. Lorsque les gens sont confrontés à un problème « non linéaire » complexe, ils font toujours de leur mieux pour le décomposer ou le transformer en une série de problèmes linéaires simples, puis les résoudre un par un. Un système logiciel dans son ensemble peut être complexe, mais un seul sous-programme est toujours simple et peut être mis en œuvre de manière linéaire, sinon le travail sera trop fatiguant. La linéarité est une sorte de simplicité, et la simplicité est la beauté. Lorsque nous comprenons l’esprit de linéarité, nous ne devons plus appliquer de manière rigide l’apparence du modèle linéaire, mais nous devons l’utiliser. Par exemple, le modèle incrémentiel est essentiellement un modèle linéaire segmenté et le modèle en spirale est un modèle linéaire courbe continu. Les ombres du modèle linéaire peuvent également être trouvées dans d'autres modèles.

3. Modèle de prototype rapide

La première étape du modèle de prototypage rapide consiste à construire un prototype rapide pour permettre aux clients ou aux futurs utilisateurs d'interagir avec le système. L'utilisateur ou le client évalue le prototype et le détaille davantage. pour le logiciel à développer. En ajustant progressivement le prototype pour répondre aux exigences du client, les développeurs peuvent déterminer quels sont les besoins réels du client ; la deuxième étape s'appuie sur la première étape pour développer un produit logiciel qui satisfait le client. De toute évidence, la méthode de prototypage rapide peut surmonter les lacunes du modèle en cascade et réduire les risques de développement causés par des exigences logicielles peu claires, et a des effets significatifs. La clé du prototypage rapide est de créer des prototypes logiciels le plus rapidement possible, puis de les abandonner une fois que les véritables besoins du client sont déterminés. Par conséquent, la structure interne du système prototype n'est pas importante. Ce qui compte, c'est que le prototype doit être rapidement construit puis modifié rapidement pour refléter les besoins du client.

4. Modèle incrémental

Le modèle incrémental est également appelé modèle évolutif. Tout comme la construction d’un bâtiment, un logiciel se construit étape par étape. Dans le modèle incrémental, le logiciel est conçu, implémenté, intégré et testé comme une série de composants incrémentiels. Chaque composant est composé de fragments de code qui fournissent des fonctions spécifiques formées par plusieurs modules en interaction. Le modèle incrémental ne fournit pas un produit exécutable complet à chaque étape, mais un sous-ensemble du produit exécutable qui répond aux besoins du client. L'ensemble du produit est décomposé en plusieurs composants et les développeurs livrent le produit composant par composant. L'avantage est que le développement logiciel peut mieux s'adapter aux changements et que les clients peuvent voir en permanence le logiciel développé, réduisant ainsi les risques de développement. Cependant, le modèle incrémental présente également les défauts suivants :

(1) Puisque chaque composant est progressivement intégré à l'architecture logicielle existante, l'ajout de composants ne doit pas détruire les parties du système déjà construites, ce qui nécessite que le logiciel soit une architecture ouverte.

(2) Au cours du processus de développement, les changements d'exigences sont inévitables. La flexibilité du modèle incrémental peut rendre sa capacité à s'adapter à de tels changements bien meilleure que le modèle en cascade et le modèle de prototypage rapide, mais il peut aussi facilement dégénérer en un modèle qui est modifié en cours d'exécution, de sorte que le contrôle du processus logiciel perd son intégrité. Lorsque vous utilisez un modèle incrémentiel, le premier incrément est souvent le produit de base qui répond au besoin fondamental. Une fois le produit principal livré aux utilisateurs, le prochain plan de développement incrémentiel est formé après évaluation, qui comprend des modifications du produit principal et la publication de nouvelles fonctionnalités. Ce processus est répété après chaque version incrémentielle jusqu'à ce que le produit final poli soit produit. Par exemple, utilisez le modèle incrémental pour développer un logiciel de traitement de texte. On peut considérer que le premier incrément libère des fonctions de base de gestion de fichiers, d'édition et de génération de documents, le deuxième incrément libère des fonctions d'édition et de génération de documents plus complètes, le troisième incrément implémente des fonctions de vérification orthographique et grammaticale et le quatrième incrément implémente la vérification orthographique et grammaticale. fonctions. Complétez progressivement les fonctions avancées de mise en page.

5. Modèle en spirale

En 1988, Barry Boehm a officiellement publié le « Modèle en spirale » de développement de systèmes logiciels, qui combinait le modèle en cascade et le modèle de prototypage rapide, mettant l'accent sur les risques ignorés par d'autres modèles. systèmes vastes et complexes. Comme le montre la figure, le modèle en spirale subit plusieurs itérations le long de la spirale. Les quatre quadrants de la figure représentent les activités suivantes :

(1) Élaborer un plan : déterminer les objectifs du logiciel, sélectionner le plan de mise en œuvre et clarifier les limites. des conditions de développement du projet ;

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

(3) Ingénierie de mise en œuvre : mettre en œuvre le développement et la vérification du logiciel ; évaluer le travail de développement, proposer des suggestions de révision et formuler les prochaines étapes. Le modèle en spirale est axé sur les risques, met l'accent sur les alternatives et les contraintes pour soutenir la réutilisation des logiciels, et aide à intégrer la qualité des logiciels en tant qu'objectif particulier dans le développement de produits. Cependant, le modèle en spirale présente également certaines limites, comme suit :

(1) Le modèle en spirale met l'accent sur l'analyse des risques, mais il n'est pas facile pour de nombreux clients d'accepter et de croire cette analyse et de formuler des réponses pertinentes. Par conséquent, ce modèle est souvent adapté. au développement de logiciels internes à grande échelle.

(2) Si effectuer une analyse des risques affectera grandement le profit du projet, alors effectuer une analyse des risques n'a aucun sens. Par conséquent, le modèle en spirale ne convient qu'aux projets logiciels à grande échelle.

(3) Les développeurs de logiciels doivent être doués pour trouver les risques possibles et analyser avec précision les risques, sinon cela entraînera des risques plus importants. Une étape détermine d'abord les objectifs de l'étape, les options pour atteindre ces objectifs et leurs contraintes, puis analyse la stratégie de développement du programme du point de vue des risques, en essayant d'éliminer divers risques potentiels, parfois en construisant des prototypes. Si certains risques ne peuvent être éliminés, le programme est immédiatement interrompu, sinon l'étape de développement suivante est lancée. Enfin, évaluez les résultats de cette phase et concevez la phase suivante.

Modèle de fontaine (également appelé modèle de vie orienté objet, modèle OO) Par rapport à la durée de vie structurée traditionnelle, le modèle de fontaine a plus d'incréments et de nature itérative, les différentes étapes du Le cycle de vie peut se chevaucher et se répéter plusieurs fois, et les périodes de sous-vie peuvent également être intégrées tout au long du cycle de vie du projet. Tout comme l'eau qui jaillit et retombe, elle peut tomber au milieu ou au fond.

Le modèle intelligent dispose d'un ensemble d'outils (tels que la requête de données, la génération de rapports, le traitement des données, la définition d'écran, la génération de code, les fonctions graphiques et feuilles de calcul de haut niveau, etc.). Chaque outil permet aux développeurs de définir certains aspects du logiciel. à un niveau élevé de fonctionnalités, et générer automatiquement le code source de ces logiciels définis par les développeurs. Cette approche nécessite la prise en charge du langage de quatrième génération (4GL). 4GL est différent de la troisième génération de langages. Sa principale caractéristique est que l'interface utilisateur est extrêmement conviviale, même les programmeurs non professionnels non formés peuvent l'utiliser pour écrire des programmes ; 4GL propose également un code de programme efficace, des hypothèses par défaut intelligentes, une base de données complète et un générateur d'applications. Les 4GL populaires actuellement sur le marché (tels que Foxpro, etc.) présentent tous les caractéristiques ci-dessus à des degrés divers. Cependant, la L4G se limite aujourd’hui principalement au développement d’applications de petite et moyenne taille pour les systèmes d’information transactionnels.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!