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.

6. Modèle de fontaine (modèle de fontaine)

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.

7. Modèle intelligent (technologie de quatrième génération (4GL))

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.

8. Modèle hybride

Le modèle de développement de processus de modèle hybride (modèle hybride) est également appelé modèle hybride (modèle hybride), ou méta-modèle (méta-modèle), qui combine plusieurs modèles différents en un seul. , qui permet à un projet de se développer selon la voie la plus efficace, est le modèle de développement de processus (ou modèle hybride). En fait, certaines organisations de développement de logiciels utilisent plusieurs méthodes de développement différentes pour créer leurs propres modèles hybrides. Comparaison de différents modèles. Chaque organisation de développement de logiciels doit choisir un modèle de développement de logiciels adapté à l'organisation et doit évoluer en fonction des fonctionnalités spécifiques du produit en cours de développement pour réduire les lacunes du modèle sélectionné et tirer pleinement parti de ses avantages. Le tableau répertorie les avantages et les inconvénients de plusieurs modèles courants. Avantages et inconvénients des différents modèles : Avantages du modèle Inconvénients Modèle en cascade Le système basé sur les documents peut ne pas répondre aux besoins du client Modèle de prototypage rapide Se concentrer sur la satisfaction des besoins du client peut entraîner une mauvaise conception du système, une inefficacité et des difficultés de maintenance Développement incrémentiel du modèle Les premiers retours d'information sont opportuns et facile à maintenir Une architecture ouverte est nécessaire et peut être mal conçue et inefficace. Les analystes des risques axés sur les risques du modèle spiral doivent être expérimentés et pleinement formés

9. Modèle RUP (modèle itératif)

Le RUP (Rational Unified Process). ) le modèle est rationnel Un ensemble de modèles de processus de développement proposés par l'entreprise, qui est un processus métier courant pour l'ingénierie logicielle orientée objet. Il décrit une série de processus de génie logiciel associés qui ont la même structure, c'est-à-dire la même architecture de processus. RUP fournit une méthode standardisée pour répartir les tâches et les responsabilités au sein d'une organisation de développement, dans le but de garantir qu'un logiciel de haute qualité répondant aux besoins de l'utilisateur final soit développé dans un calendrier et un budget prévisibles. RUP a deux axes, l'un est la chronologie, qui est dynamique. L'autre axe est l'axe du workflow, qui est statique. Sur la chronologie, RUP est divisé en quatre étapes : la phase initiale, la phase de raffinement, la phase de construction et la phase de publication. La notion d'itération est utilisée à chaque étape. Sur l'axe du flux de travail, RUP a conçu six flux de travail principaux et trois flux de travail de support principaux. L'axe de flux de travail principal comprend : le flux de travail de modélisation commerciale, le flux de travail des exigences, le flux de travail d'analyse et de conception, le flux de travail de mise en œuvre et le flux de travail de test et le flux de publication. Les flux de travail de base comprennent : le flux de travail d'environnement, le flux de travail de gestion de projet et le flux de travail de configuration et de gestion des modifications. RUP rassemble les meilleures pratiques en matière de développement de logiciels modernes et propose un format flexible pour répondre aux besoins de divers projets et organisations. En tant que modèle commercial, il comporte des conseils et des modèles de processus très détaillés. Cependant, le modèle étant relativement complexe, sa maîtrise nécessite un coût relativement important. En particulier, cela impose des exigences relativement élevées aux chefs de projet. Il présente les caractéristiques suivantes :

(1) Itération incrémentale, chaque itération suit le modèle en cascade pour contrôler et résoudre les risques dès le début

(2) La complexité du modèle nécessite que les chefs de projet aient de fortes capacités de gestion ;

10. Modèle IPD

Le processus IPD (Integrated Product Development) est un ensemble de processus de développement de produits intégrés proposés par IBM. Il est très adapté aux projets de développement complexes à grande échelle, en particulier aux projets impliquant la combinaison de logiciels et de matériel. . L'IPD commence du point de vue du produit dans son ensemble et le processus prend en compte de manière globale tous les processus depuis l'ingénierie système, la recherche et le développement (matériel, logiciels, conception industrielle structurelle, tests, développement de données, etc.), la fabrication, la finance, le marketing, les achats, assistance technique, etc. Il s'agit d'un processus de bout en bout. Le processus IPD est divisé en six étapes (étape de conception, étape de planification, étape de développement, étape de vérification, étape de publication et étape du cycle de vie) et quatre points d'examen des décisions (point d'examen de la décision de l'étape de conception, point d'examen de la décision de l'étape de planification, examen de la décision de disponibilité). et points de revue des décisions de fin de vie) et six points de revue techniques. Le processus IPD est un modèle par étapes avec des ombres du modèle en cascade. Ce modèle décompose un système vaste et complexe et réduit les risques en utilisant des processus complets et complexes. Dans une certaine mesure, ce modèle utilise les coûts de processus pour améliorer la qualité de l'ensemble du produit et gagner des parts de marché. Étant donné que ce processus ne définit pas de mécanisme de restauration du processus, il ne convient pas aux projets dont les exigences changent fréquemment. Et pour certains petits projets, ce procédé n’est pas très adapté.

Apprentissage recommandé : Site Web PHP chinois

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!