Was sind die gängigen Softwareentwicklungsmodelle?

Zu den gängigen Softwareentwicklungsmodellen gehören: 1. Modell „Modifizieren“; 3. Modell „Rapid Prototyping“; ; 9. RUP-Modell; 10. IPD-Modell.

Die Betriebsumgebung dieses Tutorials: Windows 10-System, Dell G3-Computer.

Gängige Softwareentwicklungsmodelle sind:

1. Build-and-Fix-Modell

Leider werden viele Produkte nach dem „Build-and-Fix“-Modell entwickelt. Bei diesem Modell gibt es weder Spezifikationen noch Designs, und die Software wird immer wieder an die Bedürfnisse der Kunden angepasst. Bei diesem Modell erhalten Entwickler das Projekt und schreiben sofort das Programm entsprechend den Anforderungen. Nach dem Debuggen wird die erste Version der Software generiert. Wenn nach der Bereitstellung an Benutzer ein Fehler im Programm auftritt oder der Benutzer neue Anforderungen stellt, ändert der Entwickler den Code erneut, bis der Benutzer zufrieden ist. Dabei handelt es sich um eine Workshop-ähnliche Entwicklungsmethode, die zum Schreiben kleiner Programme mit einigen hundert Zeilen geeignet ist, für die Entwicklung jeglicher Größenordnung jedoch unbefriedigend ist. Das Hauptproblem ist:

( 1) Mangelnde Planungs- und Designverbindungen. Die Struktur der Software verschlechtert sich bei ständigen Änderungen, sodass es unmöglich ist, sie weiter zu ändern Ohne jegliche Dokumentation ist die Wartung der Software sehr schwierig.

2. Wasserfallmodell

1970 schlug Winston Royce das berühmte „Wasserfallmodell“ vor. Bis in die frühen 1980er Jahre war es das einzige weit verbreitete Softwareentwicklungsmodell. Im Wasserfallmodell ist der Softwarelebenszyklus, wie in der Abbildung dargestellt, in sechs grundlegende Aktivitäten unterteilt, z. B. Planung, Anforderungsanalyse, Softwaredesign, Programmerstellung, Softwaretests sowie Betrieb und Wartung, und ihre von oben nach unten gerichteten und miteinander verbundenen Aktivitäten sind Eine feste Abfolge, wie ein Wasserfall, der Schritt für Schritt abfällt. Im Wasserfallmodell werden verschiedene Aktivitäten der Softwareentwicklung streng linear durchgeführt. Die aktuelle Aktivität übernimmt die Arbeitsergebnisse der vorherigen Aktivität und setzt die erforderlichen Arbeitsinhalte um. Die Arbeitsergebnisse der aktuellen Aktivität müssen überprüft werden. Wenn die Überprüfung erfolgreich ist, wird das Ergebnis als Eingabe für die nächste Aktivität verwendet und andernfalls wird es zur Änderung zurückgegeben. Das Wasserfallmodell betont die Rolle der Dokumentation und erfordert eine sorgfältige Überprüfung in jeder Phase. Der lineare Prozess dieses Modells ist jedoch zu ideal und für moderne Softwareentwicklungsmodelle nicht mehr geeignet. Seine Hauptprobleme sind: (1) Die Aufteilung jeder Stufe ist vollständig festgelegt. und zwischen den Phasen der Dokumentation treten zahlreiche Probleme auf, was den Arbeitsaufwand erheblich erhöht.

(2) Da das Entwicklungsmodell linear ist, können Benutzer die Entwicklungsergebnisse nur bis zum Ende des gesamten Prozesses sehen, was das Entwicklungsrisiko erhöht ;

(3) Frühe Fehler sind möglich. Sie können erst in der Testphase in einem späteren Entwicklungsstadium entdeckt werden, was schwerwiegende Folgen haben kann.

Wir sollten erkennen, dass „linear“ die Denkweise ist, die Menschen am einfachsten beherrschen und geschickt anwenden können. Wenn Menschen auf ein komplexes „nichtlineares“ Problem stoßen, versuchen sie immer ihr Bestes, es in eine Reihe einfacher linearer Probleme zu zerlegen oder umzuwandeln und sie dann einzeln zu lösen. Ein Softwaresystem als Ganzes mag komplex sein, aber ein einzelnes Unterprogramm ist immer einfach und kann linear implementiert werden, sonst wird die Arbeit zu ermüdend. Linearität ist eine Art Einfachheit und Einfachheit ist Schönheit. Wenn wir den Geist der Linearität verstehen, sollten wir das Erscheinungsbild des linearen Modells nicht länger starr anwenden, sondern es nutzen. Beispielsweise ist das inkrementelle Modell im Wesentlichen ein segmentiertes lineares Modell, und das Spiralmodell ist ein kontinuierlich gekrümmtes lineares Modell. Schatten des linearen Modells sind auch in anderen Modellen zu finden.

3. Rapid-Prototyping-Modell

Der erste Schritt des Rapid-Prototyping-Modells besteht darin, einen Rapid-Prototyp zu erstellen, damit Kunden oder zukünftige Benutzer mit dem System interagieren können der zu entwickelnden Software. Durch die schrittweise Anpassung des Prototyps an die Anforderungen des Kunden können Entwickler ermitteln, was die tatsächlichen Bedürfnisse des Kunden sind. Der zweite Schritt baut auf dem ersten Schritt auf, um ein Softwareprodukt zu entwickeln, das den Kunden zufriedenstellt. Offensichtlich kann die Rapid-Prototyping-Methode die Mängel des Wasserfallmodells überwinden und Entwicklungsrisiken reduzieren, die durch unklare Softwareanforderungen verursacht werden, und hat erhebliche Auswirkungen. Der Schlüssel zum Rapid Prototyping besteht darin, Software-Prototypen so schnell wie möglich zu erstellen und die Prototypen dann zu verwerfen, sobald die wahren Bedürfnisse des Kunden ermittelt sind. Daher ist die interne Struktur des Prototypsystems nicht wichtig. Wichtig ist, dass der Prototyp schnell erstellt und dann schnell geändert werden muss, um die Bedürfnisse des Kunden widerzuspiegeln.

4. Inkrementelles Modell

Inkrementelles Modell wird auch Evolutionsmodell genannt. Wie beim Bau eines Gebäudes wird auch Software Schritt für Schritt erstellt. Im inkrementellen Modell wird Software als eine Reihe inkrementeller Komponenten entworfen, implementiert, integriert und getestet. Jede Komponente besteht aus Codefragmenten, die spezifische Funktionen bereitstellen, die durch mehrere interagierende Module gebildet werden. Das inkrementelle Modell liefert nicht in jeder Phase ein vollständig ausführbares Produkt, sondern eine Teilmenge des ausführbaren Produkts, die den Kundenanforderungen entspricht. Das gesamte Produkt wird in mehrere Komponenten zerlegt und Entwickler liefern das Produkt Komponente für Komponente aus. Dies hat den Vorteil, dass sich die Softwareentwicklung besser an Änderungen anpassen kann und Kunden die entwickelte Software kontinuierlich sehen können, wodurch Entwicklungsrisiken verringert werden. Allerdings weist das inkrementelle Modell auch folgende Mängel auf:

(1) Da jede Komponente schrittweise in die bestehende Softwarearchitektur integriert wird, darf das Hinzufügen von Komponenten nicht die bereits erstellten Systemteile zerstören, was eine offene Architektur der Software erfordert.

(2) Während des Entwicklungsprozesses sind Änderungen der Anforderungen unvermeidlich. Die Flexibilität des inkrementellen Modells kann dazu führen, dass es sich viel besser an solche Änderungen anpassen kann als das Wasserfallmodell und das Rapid-Prototyping-Modell, aber es kann auch leicht in ein Modell degenerieren, das dabei geändert wird, sodass die Steuerung des Softwareprozesses nicht mehr möglich ist verliert seine Integrität. Bei der Verwendung eines inkrementellen Modells ist das erste Inkrement oft das Kernprodukt, das den Grundbedarf erfüllt. Nachdem das Kernprodukt an die Benutzer geliefert wurde, wird nach der Evaluierung der nächste inkrementelle Entwicklungsplan erstellt, der Änderungen am Kernprodukt und die Veröffentlichung einiger neuer Funktionen umfasst. Dieser Vorgang wird nach jeder schrittweisen Freigabe wiederholt, bis das endgültige, polierte Produkt entsteht. Verwenden Sie beispielsweise das inkrementelle Modell, um Textverarbeitungssoftware zu entwickeln. Man kann davon ausgehen, dass das erste Inkrement grundlegende Dateiverwaltungs-, Bearbeitungs- und Dokumentgenerierungsfunktionen freigibt, das zweite Inkrement umfassendere Bearbeitungs- und Dokumentgenerierungsfunktionen freigibt, das dritte Inkrement Rechtschreib- und Grammatikprüfungsfunktionen implementiert und das vierte Inkrement Rechtschreib- und Grammatikprüfung implementiert Funktionen. Vervollständigen Sie schrittweise erweiterte Seitenlayoutfunktionen. 5. Spiralmodell große und komplexe Systeme. Wie in der Abbildung dargestellt, durchläuft das Spiralmodell mehrere Iterationen entlang der Spirale. Die vier Quadranten in der Abbildung stellen die folgenden Aktivitäten dar:

(1) Erstellen Sie einen Plan: Bestimmen Sie die Softwareziele, wählen Sie den Implementierungsplan aus und klären Sie die Einschränkungen der Projektentwicklungsbedingungen; (2) Risikoanalyse: Analyse und Bewertung der ausgewählten Optionen, Überlegungen zur Identifizierung und Beseitigung von Risiken

(3) Implementierungstechnik: Implementierung der Softwareentwicklung und -verifizierung; Bewerten Sie die Entwicklungsarbeit, schlagen Sie Überarbeitungsvorschläge vor und formulieren Sie die nächsten Schritte. Das Spiralmodell ist risikoorientiert, betont Alternativen und Einschränkungen zur Unterstützung der Software-Wiederverwendung und trägt dazu bei, Softwarequalität als besonderes Ziel in die Produktentwicklung zu integrieren. Das Spiralmodell weist jedoch auch bestimmte Einschränkungen auf, wie folgt:

(1) Das Spiralmodell legt den Schwerpunkt auf die Risikoanalyse, aber es ist für viele Kunden nicht einfach, diese Analyse zu akzeptieren und zu glauben und relevante Antworten zu geben. Daher wird dieses Modell häufig angepasst bis hin zur internen Softwareentwicklung im großen Maßstab.

(2) Wenn die Durchführung einer Risikoanalyse den Gewinn des Projekts stark beeinflusst, ist die Durchführung einer Risikoanalyse bedeutungslos. Daher ist das Spiralmodell nur für große Softwareprojekte geeignet.

(3) Softwareentwickler sollten gut darin sein, mögliche Risiken zu finden und Risiken genau zu analysieren, sonst bringt es größere Risiken mit sich. Eine Phase bestimmt zunächst die Ziele der Phase, die Optionen zur Verwirklichung dieser Ziele und ihre Einschränkungen und analysiert dann die Entwicklungsstrategie des Programms aus Risikoperspektive, wobei versucht wird, verschiedene potenzielle Risiken zu beseitigen, manchmal durch den Bau von Prototypen. Können bestimmte Risiken nicht beseitigt werden, wird das Programm sofort beendet, andernfalls wird der nächste Entwicklungsschritt eingeleitet. Bewerten Sie abschließend die Ergebnisse dieser Phase und entwerfen Sie die nächste Phase.

6. Fountain-Modell

Fountain-Modell (auch objektorientiertes Lebensdauermodell, OO-Modell genannt) Im Vergleich zur traditionellen strukturierten Lebensdauer weist das Fountain-Modell mehr Inkremente und einen iterativen Charakter auf, die verschiedenen Phasen des Lebenszyklus können sich überschneiden und mehrere Male iterieren, und Unterlebensperioden können auch in den gesamten Lebenszyklus des Projekts eingebettet werden. Genauso wie Wasser, das hochspritzt und wieder herunterfällt, kann es in der Mitte oder auf dem Grund fallen.

7. Intelligentes Modell (Technologie der vierten Generation (4GL))

Das intelligente Modell verfügt über eine Reihe von Tools (z. B. Datenabfrage, Berichtserstellung, Datenverarbeitung, Bildschirmdefinition, Codegenerierung, High-Level-Grafikfunktionen und Tabellenkalkulationen usw.). Jedes Tool ermöglicht es Entwicklern, bestimmte Aspekte der Software zu definieren auf hohem Niveau und generiert automatisch Quellcode für diese von Entwicklern definierte Software. Dieser Ansatz erfordert Unterstützung für Sprachen der vierten Generation (4GL). 4GL unterscheidet sich von der dritten Generation von Sprachen. Sein Hauptmerkmal ist, dass die Benutzeroberfläche äußerst benutzerfreundlich ist. Auch ungeübte, nicht professionelle Programmierer können damit Programme schreiben. 4GL bietet außerdem effizienten Programmcode, intelligente Standardannahmen, eine vollständige Datenbank und einen Anwendungsgenerator. Die derzeit auf dem Markt erhältlichen beliebten 4GLs (z. B. Foxpro usw.) weisen alle in unterschiedlichem Maße die oben genannten Eigenschaften auf. Allerdings beschränkt sich 4GL derzeit hauptsächlich auf die Entwicklung kleiner und mittlerer Anwendungen für Transaktionsinformationssysteme.

8. Hybridmodell

Das Prozessentwicklungsmodell des Hybridmodells (Hybridmodell) wird auch Hybridmodell (Hybridmodell) oder Metamodell (Metamodell) genannt, das mehrere verschiedene Modelle zu einem Hybridmodell kombiniert , das es einem Projekt ermöglicht, sich auf dem effizientesten Weg zu entwickeln, ist das Prozessentwicklungsmodell (oder Hybridmodell). Tatsächlich verwenden einige Softwareentwicklungsorganisationen mehrere unterschiedliche Entwicklungsmethoden, um ihre eigenen Hybridmodelle zu erstellen. Vergleich verschiedener Modelle: Jede Softwareentwicklungsorganisation sollte ein Softwareentwicklungsmodell wählen, das für die Organisation geeignet ist und sich an die spezifischen Produktfunktionen anpassen sollte, die derzeit entwickelt werden, um die Mängel des ausgewählten Modells zu verringern und dessen Vorteile voll auszuschöpfen Die Tabelle listet die Vor- und Nachteile einiger gängiger Modelle auf. Vor- und Nachteile verschiedener Modelle: Modellvorteile Nachteile Wasserfallmodell Dokumentgesteuertes System erfüllt möglicherweise nicht die Kundenanforderungen Rapid-Prototyping-Modell Der Fokus auf die Erfüllung der Kundenanforderungen kann zu schlechtem Systemdesign, Ineffizienz und Schwierigkeiten bei der Wartung führen. Inkrementelle Modellentwicklung. Frühes Feedback erfolgt rechtzeitig und Einfach zu warten Eine offene Architektur ist erforderlich und möglicherweise schlecht konzipiert und ineffizient. Risikoanalytiker mit Spiralmodell müssen erfahren und umfassend geschult sein

9. Das RUP (Rational Unified Process). ) Modell ist Rational Eine Reihe von vom Unternehmen vorgeschlagenen Entwicklungsprozessmodellen, bei denen es sich um einen allgemeinen Geschäftsprozess für die objektorientierte Softwareentwicklung handelt. Es beschreibt eine Reihe verwandter Software-Engineering-Prozesse, die die gleiche Struktur, also die gleiche Prozessarchitektur, aufweisen. RUP bietet eine standardisierte Methode zur Zuweisung von Aufgaben und Verantwortlichkeiten innerhalb einer Entwicklungsorganisation mit dem Ziel, sicherzustellen, dass hochwertige Software, die den Anforderungen der Endbenutzer entspricht, innerhalb eines vorhersehbaren Zeitplans und Budgets entwickelt wird. RUP hat zwei Achsen, eine davon ist die dynamische Zeitleiste. Die andere Achse ist die Workflow-Achse, die statisch ist. Auf der Zeitachse ist RUP in vier Phasen unterteilt: Anfangsphase, Verfeinerungsphase, Konstruktionsphase und Freigabephase. Das Konzept der Iteration wird in jeder Phase verwendet. Auf der Workflow-Achse hat RUP sechs Kern-Workflows und drei unterstützende Kern-Workflows entworfen. Die Kern-Workflow-Achse umfasst: Geschäftsmodellierungs-Workflow, Anforderungs-Workflow, Analyse- und Design-Workflow, Implementierungs-Workflow und Test-Workflow und Veröffentlichungs-Workflow. Zu den wichtigsten unterstützenden Workflows gehören: Umgebungsworkflow, Projektmanagement-Workflow sowie Konfigurations- und Änderungsmanagement-Workflow. RUP vereint die Best Practices der modernen Softwareentwicklung und bietet ein flexibles Format, um den Anforderungen verschiedener Projekte und Organisationen gerecht zu werden. Als Geschäftsmodell verfügt es über sehr detaillierte Prozessanleitungen und Vorlagen. Da das Modell jedoch relativ komplex ist, sind relativ hohe Kosten für die Beherrschung des Modells erforderlich. Insbesondere an Projektmanager werden relativ hohe Anforderungen gestellt. Es weist die folgenden Merkmale auf:

(1) Inkrementelle Iteration, jede Iteration folgt dem Wasserfallmodell, um Risiken im Frühstadium zu kontrollieren und zu lösen.

(2) Die Komplexität des Modells erfordert, dass Projektmanager über starke Managementfähigkeiten verfügen.

10. Der IPD-Prozess (Integrated Product Development) ist eine Reihe integrierter Produktentwicklungsprozesse, die von IBM vorgeschlagen werden. Er eignet sich sehr gut für komplexe Großentwicklungsprojekte, insbesondere für Projekte, die die Kombination von Software und Hardware beinhalten . IPD geht von der Perspektive des gesamten Produkts aus und der Prozess berücksichtigt umfassend alle Prozesse von der Systemtechnik, Forschung und Entwicklung (Hardware, Software, strukturelles Industriedesign, Tests, Datenentwicklung usw.), Fertigung, Finanzen bis hin zu Marketing, Beschaffung, technischer Support usw. Es handelt sich um einen End-to-End-Prozess. Der IPD-Prozess ist in sechs Phasen (Konzeptphase, Planungsphase, Entwicklungsphase, Verifizierungsphase, Freigabephase und Lebenszyklusphase) und vier Entscheidungsüberprüfungspunkte (Entscheidungsüberprüfungspunkt in der Konzeptphase, Entscheidungsüberprüfungspunkt in der Planungsphase, Entscheidungsüberprüfung in der Verfügbarkeit) unterteilt Punkte und Entscheidungsüberprüfungspunkte am Ende des Lebenszyklus) und sechs technische Überprüfungspunkte. Der IPD-Prozess ist ein Stufenmodell mit Schatten des Wasserfallmodells. Dieses Modell zerlegt ein großes und komplexes System und reduziert Risiken durch den Einsatz umfassender und komplexer Prozesse. Dieses Modell nutzt Prozesskosten gewissermaßen aus, um die Qualität des gesamten Produkts zu verbessern und Marktanteile zu gewinnen. Da dieser Prozess keinen Mechanismus zum Prozess-Rollback definiert, ist dieser Prozess nicht für Projekte mit sich häufig ändernden Anforderungen geeignet. Und für einige kleine Projekte ist dieser Prozess nicht sehr geeignet.

Empfohlenes Lernen: Chinesische PHP-Website

Das obige ist der detaillierte Inhalt vonWas sind die gängigen Softwareentwicklungsmodelle?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!