Überblick über den Softwareentwicklungslebenszyklus (SDLC)

Der Softwareentwicklungslebenszyklus bietet Unternehmen einen systematischen, schrittweisen Ansatz zur Entwicklung erfolgreicher Software, indem erste Anforderungen für neue Produkte gesammelt werden. Es ist ein systematischer Prozess der Erstellung von Software, um die Qualität und Korrektheit der erstellten Software sicherzustellen und die Erwartungen der Kunden zu erfüllen.

Zu den wichtigsten Entwicklungsmodellen gehören Wasserfallmodell, inkrementelles Modell, Spiralmodell, Fontänenmodell, intelligentes Modell, V-Modell, RAD-Modell, CBSD-Modell, Prototypmethode, XP-Methode, RUP-Methode usw.

Wasserfall-Modell

Das Wasserfallmodell, auch Lebenszyklusmethode genannt, ist das am häufigsten verwendete Entwicklungsmodell in der Lebenszyklusmethode. Es unterteilt den Softwareentwicklungsprozess in sechs Phasen: Softwareplanung, Anforderungsanalyse, Softwaredesign, Programmcodierung, Softwaretest sowie Betrieb und Wartung. Um ihre feste Ordnung von oben nach unten zu erreichen, fallen sie wie ein Wasserfall Stufe um Stufe.

• Softwareplan : Bestimmen Sie hauptsächlich die Entwicklungsziele und Machbarkeit der Software.
• Anforderungsanalyse : Nachdem Sie bestätigt haben, dass die Softwareentwicklung durchführbar ist, führen Sie eine detaillierte Analyse der verschiedenen Funktionen durch, die die Software erfüllen muss. Die Phase der Anforderungsanalyse ist eine sehr wichtige Phase. Eine gute Arbeit in dieser Phase legt eine gute Grundlage für den Erfolg des gesamten Softwareentwicklungsprojekts.
• Softwaredesign : Entwerfen Sie das gesamte Softwaresystem, z. B. Systemrahmendesign, Datenbankdesign usw., basierend auf den Ergebnissen der Bedarfsanalyse. Softwaredesign wird allgemein in Gesamtdesign (Gliederungsdesign) und Feindesign unterteilt.
• Programmcode : Konvertieren Sie das Ergebnis des Softwaredesigns in Programmcode, der von einem Computer ausgeführt werden kann. Bei der Programmierung muss eine einheitliche und standardkonforme Programmierspezifikation formuliert werden, um die Lesbarkeit des Programms, die einfache Wartung und die Verbesserung der Betriebseffizienz des Programms zu gewährleisten.
• Softwaretests : Nachdem das Softwaredesign abgeschlossen ist, muss es strengen Tests unterzogen werden, um die Probleme in der Software während des gesamten Designprozesses zu finden und zu beheben. Im Testprozess ist es notwendig, einen detaillierten Testplan zu erstellen und Tests in strikter Übereinstimmung mit dem Testplan durchzuführen, um die Willkür des Tests zu reduzieren. Software-Wartung:
• Die Softwarewartung  ist die längste Zeit im Softwarelebenszyklus. Nachdem die Software entwickelt und in Gebrauch genommen wurde, kann die Software aus verschiedenen Gründen die Anforderungen der Benutzer nicht mehr erfüllen. Um die Lebensdauer der Software zu verlängern, muss die Software gewartet werden.

Transformationsmodell

Das Transformationsmodell (Evolutionsmodell) basiert auf der schnellen Entwicklung eines Prototyps. Gemäß dem Feedback und den Vorschlägen, die von Benutzern beim Aufrufen des Prototyps vorgebracht werden, wird der Prototyp verbessert, um eine neue Version des Prototyps zu erhalten, und dieser Prozess wird wiederholt, bis er sich zum endgültigen Softwareprodukt entwickelt.

Spiralmodell

Das Spiralmodell kombiniert das Wasserfallmodell und das Transformationsmodell. Es kombiniert die Vorteile der beiden und fügt eine Risikoanalyse hinzu. Er ist dem Vorbild nachempfunden und dreht sich entlang der Spirale von innen nach außen. Jede Rotation erfordert Planung, Risikoanalyse, Implementierungstechnik, Kundenbewertung und andere Aktivitäten, und es wird eine neue Version des Prototyps entwickelt. Nach mehreren Spiralen wird das endgültige System erhalten.

Brunnenmodell

Das Fontänenmodell bietet Unterstützung für die Wiederverwendung von Software und die Integration mehrerer Entwicklungsaktivitäten im Lebenszyklus und unterstützt hauptsächlich objektorientierte Entwicklungsmethoden. Der Begriff „Brunnen“ selbst verkörpert die Eigenschaften von Iteration und Gaplessness. Ein bestimmter Teil des Systems wiederholt die Arbeit häufig viele Male, und bei jeder Iteration werden dem entwickelten System verwandte Funktionen hinzugefügt. Das sogenannte Gapless bedeutet, dass es bei Entwicklungsaktivitäten keine offensichtliche Grenze zwischen Analyse, Design und Codierung gibt.

V-Modell

Im Entwicklungsmodell wird das Testen oft nachträglich eingesetzt, um Abhilfe zu schaffen, aber es gibt auch ein testzentriertes Entwicklungsmodell, das V-Modell. Das V-Modell wurde in der Softwareindustrie nur vage erkannt. Das V-Modell behauptet, dass Testen kein nachträglicher Einfall ist, sondern ein ebenso wichtiger Prozess wie der Entwicklungsprozess.

Das V-Modell beschreibt einige verschiedene Teststufen und erklärt die verschiedenen Phasen im Lebenszyklus, die diesen Stufen entsprechen. In der Abbildung sind die Abstiege links die verschiedenen Stadien des Entwicklungsprozesses und die entsprechenden Abschnitte rechts die ansteigenden Teile, d. h. die verschiedenen Stadien des Testprozesses.

Bitte beachten Sie, dass die Benennung der Testphase in verschiedenen Organisationen unterschiedlich sein kann. Der Wert des V-Modells besteht darin, dass es die verschiedenen Ebenen des Testprozesses deutlich zeigt und die Entsprechung zwischen diesen Testphasen und den verschiedenen Phasen während des Entwicklungsprozesses klar beschreibt:

• Der Hauptzweck von Unit-Tests besteht darin, verschiedene Fehler zu beheben, die im Codierungsprozess auftreten können. Beispiel: Der Benutzer gibt während des Überprüfungsprozesses einen Fehler in den Grenzwert ein.
• Der Hauptzweck des Integrationstests besteht darin, mögliche Probleme im Detaildesign anzugehen, insbesondere mögliche Fehler in der Schnittstelle zwischen jeder Einheit und anderen Programmteilen zu überprüfen.
• Systemtests dienen hauptsächlich der Entwurfsplanung und prüfen, ob das System als Ganzes effektiv funktioniert. Zum Beispiel: Ob die erwartete hohe Leistung in den Produkteinstellungen erreicht wird.
• Akzeptanztests werden normalerweise von Geschäftsexperten oder Benutzern durchgeführt, um zu bestätigen, dass das Produkt die Geschäftsanforderungen des Benutzers wirklich erfüllen kann.

Inkrementelles Modell

Inkrementelle Modelle sind wie Prototypimplementierungsmodelle und andere evolutionäre Methoden im Wesentlichen iterativ. Aber im Gegensatz zur Prototypimplementierung betont das inkrementelle Modell, dass jedes Inkrement ein lauffähiges Produkt freigibt. Die frühen Inkremente sind die „abnehmbare“ Version des Endprodukts, aber sie bieten Benutzerservicefunktionen und eine Plattform für Benutzer zur Bewertung.

Das Merkmal des inkrementellen Modells ist die Einführung des Konzepts der inkrementellen Pakete. Sie müssen nicht warten, bis alle Anforderungen herauskommen, solange die inkrementellen Pakete einer bestimmten Anforderung herauskommen, können Sie mit der Entwicklung beginnen. Obwohl ein bestimmtes inkrementelles Paket möglicherweise weiter an die Bedürfnisse der Kunden angepasst und geändert werden muss, können seine Auswirkungen für das gesamte Projekt erträglich sein, solange das inkrementelle Paket klein genug ist.

RAD-Modell Das Rapid Application Development (RAD)-Modell ist ein inkrementelles Softwareentwicklungsprozessmodell, das einen sehr kurzen Entwicklungszyklus betont.

Das RAD-Modell ist eine „Hochgeschwindigkeits“-Variante des Wasserfallmodells, das durch weitgehende Verwendung wiederverwendbarer Komponenten und einer komponentenbasierten Bauweise eine schnelle Entwicklung gewinnt. Wenn die Anforderungen gut verstanden und der Umfang des Projekts begrenzt sind, kann dieses Modell verwendet werden, um schnell ein voll funktionsfähiges „Informationssystem“ zu erstellen.

Der Prozess beginnt mit der Geschäftsmodellierung, gefolgt von Datenmodellierung, Prozessmodellierung, Anwendungsgenerierung, Tests und Iteration. Der Softwareprozess, der das RAD-Modell verwendet, ist in der folgenden Abbildung dargestellt.

Die in jeder Aktivitätsperiode des RAD-Modells zu erledigenden Aufgaben lauten wie folgt.

Geschäftsmodellierung: Welche Informationen steuern den Betrieb des Geschäftsprozesses? Welche Informationen sollen generiert werden? Wer hat es generiert? Wohin geht der Informationsfluss? Wer wird es handhaben? Kann durch Datenflussdiagramme ergänzt werden.

Datenmodellierung: Um den Datenfluss des Geschäftsprozesses zu unterstützen, finden Sie die Sammlung von Datenobjekten, definieren Sie die Attribute der Datenobjekte und bilden Sie das Datenmodell mit der Beziehung zu anderen Datenobjekten, die durch ER-Diagramme ergänzt werden können .

Prozessmodellierung: Ermöglicht es Datenobjekten, verschiedene Geschäftsfunktionen im Informationsfluss zu erfüllen. Der Erstellungsprozess beschreibt das Hinzufügen, Ändern, Löschen und Suchen von Datenobjekten, also die Verfeinerung des Verarbeitungskastens im Datenflussdiagramm.

Anwendungsprogrammgenerierung: Verwenden Sie die Sprache der vierten Generation (4GL), um das Verarbeitungsprogramm zu schreiben, verwenden Sie vorhandene Komponenten wieder oder erstellen Sie neue wiederverwendbare Komponenten und verwenden Sie die von der Umgebung bereitgestellten Tools, um das gesamte Anwendungssystem automatisch zu generieren und zu erstellen.

Testen und Ausliefern führen aufgrund der vielen Wiederverwendungen in der Regel nur zu Gesamttests, aber die neu erstellten Komponenten müssen noch getestet werden.

Komponentenbasiertes Modell

Komponente (Component) ist eine Softwareeinheit mit wiederverwendbarem Wert und relativ unabhängigen Funktionen. Das komponentenbasierte Softwareentwicklungsmodell (CBSD) besteht darin, einen modularen Ansatz zu verwenden, um das gesamte System zu modularisieren und mit der Unterstützung eines bestimmten Komponentenmodells eine oder mehrere Softwarekomponenten in der Komponentenbibliothek durch Kombination wiederzuverwenden Der Prozess der Erstellung von Anwendungssoftware Systeme mit hoher Effizienz und hoher Qualität.

Das komponentenbasierte Entwicklungsmodell enthält viele Merkmale des Spiralmodells und ist im Wesentlichen evolutionär, und der Entwicklungsprozess ist iterativ. Das komponentenbasierte Entwicklungsmodell besteht aus fünf Phasen: Softwareanforderungsanalyse und -definition, Architekturdesign, Erstellung einer Komponentenbibliothek, Erstellung von Anwendungssoftware, Test und Freigabe.

Prototyp-Methode

Der Software-Prototyp ist die Teilrealisierung des vorgeschlagenen neuen Produkts. Der Hauptzweck der Erstellung des Prototyps besteht darin, das Problem der unsicheren Nachfrage in der frühen Phase der Produktentwicklung zu lösen. Sein Zweck ist es, die Anforderungen zu klären und zu verbessern, Designoptionen zu erkunden und zum Endprodukt zu entwickeln.

Es gibt viele Möglichkeiten, Prototypen zu klassifizieren. Aus der Perspektive, ob der Prototyp seine Funktionen realisiert, lassen sich Software-Prototypen in zwei Typen unterteilen: horizontale Prototypen und vertikale Prototypen.

Horizontale Prototypen werden auch als Verhaltensprototypen bezeichnet, die verwendet werden, um einige spezifische Verhaltensweisen des erwarteten Systems zu untersuchen und den Zweck der Verfeinerung von Anforderungen zu erreichen. Horizontale Prototypen sind normalerweise nur die Navigation von Funktionen, aber sie implementieren keine Funktionen. Der horizontale Prototyp wird hauptsächlich auf der Schnittstelle verwendet.

Vertikale Prototypen werden auch strukturierte Prototypen genannt, die einen Teil ihrer Funktionen implementieren. Vertikale Prototypen werden hauptsächlich bei der Realisierung komplexer Algorithmen verwendet.

XP-Methode

XP ist eine leichte (agile), effiziente, risikoarme, flexible, vorhersehbare, wissenschaftliche und unterhaltsame Softwareentwicklungsmethode. Im Vergleich zu anderen Methoden besteht der größte Unterschied in:

• Geben Sie spezifisches und kontinuierliches Feedback früher in kürzerer Zeit.
• Iteratives Planen, zu Beginn zunächst schnell einen Masterplan erstellen und diesen dann im gesamten Projektentwicklungsprozess kontinuierlich weiterentwickeln.
• Setzen Sie auf automatisierte Testverfahren, um den Entwicklungsfortschritt zu überwachen und Fehler frühzeitig zu erkennen.
• Verlassen Sie sich auf verbale Kommunikation, Tests und Quellprogrammkommunikation.
• Befürworten Sie kontinuierliches evolutionäres Design.
• Verlassen Sie sich auf eine enge Zusammenarbeit innerhalb des Entwicklungsteams.
• Versuchen Sie, die kurzfristigen Interessen des Programmierers und die langfristigen Interessen des Projekts so weit wie möglich in Einklang zu bringen.

Unified Process (UP)-Methode

Unified Process ist ein allgemeines Prozess-Framework, das mit einer Vielzahl von Softwaresystemen, unterschiedlichen Anwendungsfeldern, unterschiedlichen Organisationstypen, unterschiedlichen Leistungsniveaus und unterschiedlichen Projektgrößen zurechtkommt. UP ist komponentenbasiert, was bedeutet, dass das von ihm entwickelte Softwaresystem aus Komponenten zusammengesetzt ist und die Komponenten über wohldefinierte Schnittstellen miteinander verbunden sind. Bei der Erstellung aller Entwürfe des Softwaresystems verwendet UP die einheitliche Modellierungssprache UML.

Im Vergleich zu anderen Softwareprozessen weist UP drei bemerkenswerte Merkmale auf: anwendungsfallorientiert, zentriert auf die grundlegende Architektur, Iteration und Inkrement. Der Softwareprozess in Rational Unified Process ist in vier zeitlich aufeinanderfolgende Phasen unterteilt, nämlich die Anfangsphase, die Verfeinerungsphase, die Konstruktionsphase und die Bereitstellungsphase. Am Ende jeder Phase muss eine technische Überprüfung durchgeführt werden, um festzustellen, ob die Ziele dieser Phase erreicht wurden. Wenn die Ergebnisse der Überprüfung zufriedenstellend sind, kann das Projekt in die nächste Phase übergehen.

Erfahren Sie mehr

• Was ist ein Software-Prozessmodell?
• Adaptive vs. Predictive Planning: Wann agil? Wann Wasserfall?
• Was ist der Lebenszyklus der Softwareentwicklung?
• Scrum-Lernleitfäden
• Lernleitfäden für Projektmanagement
• Was ist UML?
• Was ist agile Softwareentwicklung?
• User Story vs. Use Case für agile Softwareentwicklung