SDLC - Kurzanleitung
Der Software Development Life Cycle (SDLC) ist ein Prozess, mit dem die Softwareindustrie hochwertige Software entwirft, entwickelt und testet. Der SDLC zielt darauf ab, eine qualitativ hochwertige Software zu entwickeln, die die Erwartungen der Kunden erfüllt oder übertrifft, innerhalb von Zeiten und Kostenvoranschlägen fertiggestellt wird.
SDLC ist die Abkürzung für Software Development Life Cycle.
Es wird auch als Software Development Process bezeichnet.
SDLC ist ein Framework, das Aufgaben definiert, die in jedem Schritt des Softwareentwicklungsprozesses ausgeführt werden.
ISO / IEC 12207 ist ein internationaler Standard für Software-Lebenszyklusprozesse. Es soll der Standard sein, der alle Aufgaben definiert, die für die Entwicklung und Wartung von Software erforderlich sind.
Was ist SDLC?
SDLC ist ein Prozess, der für ein Softwareprojekt innerhalb einer Softwareorganisation ausgeführt wird. Es besteht aus einem detaillierten Plan, der beschreibt, wie bestimmte Software entwickelt, gewartet, ersetzt und geändert oder verbessert wird. Der Lebenszyklus definiert eine Methode zur Verbesserung der Softwarequalität und des gesamten Entwicklungsprozesses.
Die folgende Abbildung zeigt grafisch die verschiedenen Phasen einer typischen SDLC.
Ein typischer Softwareentwicklungs-Lebenszyklus besteht aus den folgenden Phasen:
Stufe 1: Planung und Anforderungsanalyse
Die Anforderungsanalyse ist die wichtigste und grundlegendste Phase in der SDLC. Es wird von den hochrangigen Mitgliedern des Teams mit Beiträgen des Kunden, der Verkaufsabteilung, Marktumfragen und Domain-Experten der Branche durchgeführt. Diese Informationen werden dann verwendet, um den grundlegenden Projektansatz zu planen und eine Machbarkeitsstudie für Produkte in den Bereichen Wirtschaft, Betrieb und Technik durchzuführen.
Die Planung der Qualitätssicherungsanforderungen und die Identifizierung der mit dem Projekt verbundenen Risiken erfolgt ebenfalls in der Planungsphase. Das Ergebnis der technischen Machbarkeitsstudie ist die Definition der verschiedenen technischen Ansätze, mit denen das Projekt mit minimalen Risiken erfolgreich umgesetzt werden kann.
Stufe 2: Anforderungen definieren
Sobald die Anforderungsanalyse abgeschlossen ist, besteht der nächste Schritt darin, die Produktanforderungen klar zu definieren, zu dokumentieren und vom Kunden oder den Marktanalysten genehmigen zu lassen. Dies geschieht durch eineSRS (Software Requirement Specification) Dokument, das alle Produktanforderungen enthält, die während des Projektlebenszyklus entworfen und entwickelt werden müssen.
Stufe 3: Entwerfen der Produktarchitektur
SRS ist die Referenz für Produktarchitekten, um die beste Architektur für das zu entwickelnde Produkt zu entwickeln. Basierend auf den in SRS festgelegten Anforderungen wird normalerweise mehr als ein Entwurfsansatz für die Produktarchitektur vorgeschlagen und in einer DDS - Design Document Specification dokumentiert.
Dieses DDS wird von allen wichtigen Stakeholdern überprüft und basiert auf verschiedenen Parametern wie Risikobewertung, Produktrobustheit, Designmodularität, Budget- und Zeitbeschränkungen. Der beste Designansatz wird für das Produkt ausgewählt.
Ein Entwurfsansatz definiert alle Architekturmodule des Produkts sowie seine Kommunikations- und Datenflussdarstellung mit den externen Modulen und Modulen von Drittanbietern (falls vorhanden) klar. Das interne Design aller Module der vorgeschlagenen Architektur sollte mit den kleinsten Details in DDS klar definiert werden.
Stufe 4: Aufbau oder Entwicklung des Produkts
In dieser Phase von SDLC beginnt die eigentliche Entwicklung und das Produkt wird erstellt. In dieser Phase wird der Programmcode gemäß DDS generiert. Wenn das Design detailliert und organisiert ausgeführt wird, kann die Codegenerierung ohne großen Aufwand durchgeführt werden.
Entwickler müssen die von ihrer Organisation festgelegten Codierungsrichtlinien befolgen und Programmierwerkzeuge wie Compiler, Interpreter, Debugger usw. werden zum Generieren des Codes verwendet. Für die Codierung werden verschiedene Programmiersprachen auf hoher Ebene wie C, C ++, Pascal, Java und PHP verwendet. Die Programmiersprache wird in Bezug auf die Art der zu entwickelnden Software ausgewählt.
Stufe 5: Testen des Produkts
Diese Phase ist normalerweise eine Teilmenge aller Phasen, da in den modernen SDLC-Modellen die Testaktivitäten hauptsächlich in allen Phasen der SDLC enthalten sind. Diese Phase bezieht sich jedoch auf die Testphase des Produkts, in der Produktfehler gemeldet, verfolgt, behoben und erneut getestet werden, bis das Produkt die im SRS definierten Qualitätsstandards erreicht.
Stufe 6: Bereitstellung auf dem Markt und Wartung
Sobald das Produkt getestet und einsatzbereit ist, wird es offiziell auf dem entsprechenden Markt veröffentlicht. Manchmal erfolgt die Produktbereitstellung schrittweise gemäß der Geschäftsstrategie dieser Organisation. Das Produkt kann zunächst in einem begrenzten Segment veröffentlicht und in der realen Geschäftsumgebung getestet werden (UAT-User Acceptance Testing).
Basierend auf dem Feedback kann das Produkt dann unverändert oder mit vorgeschlagenen Verbesserungen im Zielmarktsegment veröffentlicht werden. Nachdem das Produkt auf den Markt gebracht wurde, erfolgt die Wartung für den bestehenden Kundenstamm.
SDLC-Modelle
Es werden verschiedene Lebenszyklusmodelle für die Softwareentwicklung definiert und entworfen, die während des Softwareentwicklungsprozesses befolgt werden. Diese Modelle werden auch als Softwareentwicklungsprozessmodelle bezeichnet. "Jedes Prozessmodell folgt einer Reihe von Schritten, die für seinen Typ einzigartig sind, um den Erfolg im Prozess der Softwareentwicklung sicherzustellen.
Im Folgenden sind die wichtigsten und beliebtesten SDLC-Modelle der Branche aufgeführt:
- Wasserfall-Modell
- Iteratives Modell
- Spiralmodell
- V-Model
- Urknallmodell
Andere verwandte Methoden sind Agile Model, RAD Model, Rapid Application Development und Prototyping Models.
Das Wasserfallmodell war das erste eingeführte Prozessmodell. Es wird auch als bezeichnetlinear-sequential life cycle model. Es ist sehr einfach zu verstehen und zu verwenden. In einem Wasserfallmodell muss jede Phase abgeschlossen sein, bevor die nächste Phase beginnen kann, und es gibt keine Überlappung in den Phasen.
Das Wasserfallmodell ist der früheste SDLC-Ansatz, der für die Softwareentwicklung verwendet wurde.
Das Wasserfallmodell veranschaulicht den Softwareentwicklungsprozess in einem linearen sequentiellen Fluss. Dies bedeutet, dass jede Phase des Entwicklungsprozesses erst beginnt, wenn die vorherige Phase abgeschlossen ist. In diesem Wasserfallmodell überlappen sich die Phasen nicht.
Wasserfallmodell - Design
Der Wasserfall-Ansatz war das erste SDLC-Modell, das in der Softwareentwicklung weit verbreitet war, um den Erfolg des Projekts sicherzustellen. Beim Ansatz "The Waterfall" ist der gesamte Prozess der Softwareentwicklung in separate Phasen unterteilt. In diesem Wasserfallmodell fungiert das Ergebnis einer Phase typischerweise nacheinander als Eingabe für die nächste Phase.
Die folgende Abbildung zeigt die verschiedenen Phasen des Wasserfallmodells.
Die aufeinander folgenden Phasen im Wasserfallmodell sind -
Requirement Gathering and analysis - In dieser Phase werden alle möglichen Anforderungen des zu entwickelnden Systems erfasst und in einem Anforderungsspezifikationsdokument dokumentiert.
System Design- In dieser Phase werden die Anforderungsspezifikationen aus der ersten Phase untersucht und das Systemdesign vorbereitet. Dieses Systemdesign hilft bei der Festlegung der Hardware- und Systemanforderungen und bei der Definition der gesamten Systemarchitektur.
Implementation- Mit Eingaben aus dem Systemdesign wird das System zunächst in kleinen Programmen entwickelt, die als Einheiten bezeichnet werden und in der nächsten Phase integriert werden. Jede Einheit wird auf ihre Funktionalität hin entwickelt und getestet, was als Unit Testing bezeichnet wird.
Integration and Testing- Alle in der Implementierungsphase entwickelten Einheiten werden nach dem Testen jeder Einheit in ein System integriert. Nach der Integration wird das gesamte System auf Fehler und Ausfälle getestet.
Deployment of system- Sobald die Funktions- und Nichtfunktionstests abgeschlossen sind; Das Produkt wird in der Kundenumgebung bereitgestellt oder auf den Markt gebracht.
Maintenance- In der Client-Umgebung treten einige Probleme auf. Um diese Probleme zu beheben, werden Patches veröffentlicht. Um das Produkt zu verbessern, werden einige bessere Versionen veröffentlicht. Die Wartung wird durchgeführt, um diese Änderungen in der Kundenumgebung zu liefern.
Alle diese Phasen sind zueinander kaskadiert, wobei der Fortschritt als stetig abwärts fließend (wie ein Wasserfall) durch die Phasen angesehen wird. Die nächste Phase wird erst gestartet, nachdem die definierten Ziele für die vorherige Phase erreicht und abgemeldet wurden, daher der Name "Wasserfallmodell". In diesem Modell überlappen sich die Phasen nicht.
Wasserfallmodell - Anwendung
Jede entwickelte Software ist anders und erfordert einen geeigneten SDLC-Ansatz, der auf den internen und externen Faktoren basiert. Einige Situationen, in denen die Verwendung des Wasserfallmodells am besten geeignet ist, sind:
Die Anforderungen sind sehr gut dokumentiert, klar und festgelegt.
Die Produktdefinition ist stabil.
Technologie wird verstanden und ist nicht dynamisch.
Es gibt keine mehrdeutigen Anforderungen.
Zur Unterstützung des Produkts stehen ausreichend Ressourcen mit dem erforderlichen Fachwissen zur Verfügung.
Das Projekt ist kurz.
Wasserfallmodell - Vorteile
Die Vorteile der Wasserfallentwicklung bestehen darin, dass sie eine Aufteilung und Kontrolle ermöglicht. Für jede Entwicklungsphase kann ein Zeitplan mit Fristen festgelegt werden, und ein Produkt kann die Phasen des Entwicklungsprozessmodells nacheinander durchlaufen.
Die Entwicklung geht vom Konzept über Design, Implementierung, Test, Installation und Fehlerbehebung bis hin zu Betrieb und Wartung. Jede Entwicklungsphase verläuft in strikter Reihenfolge.
Einige der Hauptvorteile des Wasserfallmodells sind folgende:
Einfach und leicht zu verstehen und zu verwenden
Aufgrund der Steifigkeit des Modells einfach zu handhaben. Jede Phase hat spezifische Ergebnisse und einen Überprüfungsprozess.
Die Phasen werden einzeln verarbeitet und abgeschlossen.
Funktioniert gut für kleinere Projekte, bei denen die Anforderungen sehr gut verstanden werden.
Klar definierte Stufen.
Gut verstandene Meilensteine.
Einfach zu arrangierende Aufgaben.
Prozess und Ergebnisse sind gut dokumentiert.
Wasserfallmodell - Nachteile
Der Nachteil der Wasserfallentwicklung besteht darin, dass sie nicht viel Nachdenken oder Überarbeitung zulässt. Sobald sich eine Anwendung in der Testphase befindet, ist es sehr schwierig, etwas zu ändern, das in der Konzeptphase nicht gut dokumentiert oder überlegt war.
Die Hauptnachteile des Wasserfallmodells sind folgende:
Bis spät im Lebenszyklus wird keine funktionierende Software erstellt.
Hohe Risiken und Unsicherheiten.
Kein gutes Modell für komplexe und objektorientierte Projekte.
Schlechtes Modell für lange und laufende Projekte.
Nicht geeignet für Projekte, bei denen die Anforderungen einem mittleren bis hohen Änderungsrisiko unterliegen. Das Risiko und die Unsicherheit bei diesem Prozessmodell sind also hoch.
Es ist schwierig, den Fortschritt schrittweise zu messen.
Kann sich ändernden Anforderungen nicht anpassen.
Das Anpassen des Umfangs während des Lebenszyklus kann ein Projekt beenden.
Die Integration erfolgt ganz am Ende als "Urknall", der es nicht ermöglicht, technologische oder geschäftliche Engpässe oder Herausforderungen frühzeitig zu erkennen.
Im iterativen Modell beginnt der iterative Prozess mit einer einfachen Implementierung eines kleinen Satzes der Softwareanforderungen und verbessert iterativ die sich entwickelnden Versionen, bis das gesamte System implementiert und bereit zur Bereitstellung ist.
Ein iteratives Lebenszyklusmodell versucht nicht, mit einer vollständigen Spezifikation der Anforderungen zu beginnen. Stattdessen beginnt die Entwicklung mit der Spezifikation und Implementierung nur eines Teils der Software, die dann überprüft wird, um weitere Anforderungen zu ermitteln. Dieser Vorgang wird dann wiederholt, wobei am Ende jeder Iteration des Modells eine neue Version der Software erstellt wird.
Iteratives Modell - Design
Der iterative Prozess beginnt mit einer einfachen Implementierung einer Teilmenge der Softwareanforderungen und verbessert iterativ die sich entwickelnden Versionen, bis das gesamte System implementiert ist. Bei jeder Iteration werden Designänderungen vorgenommen und neue Funktionsfunktionen hinzugefügt. Die Grundidee dieser Methode besteht darin, ein System durch wiederholte Zyklen (iterativ) und in kleineren Abschnitten gleichzeitig (inkrementell) zu entwickeln.
Die folgende Abbildung ist eine Darstellung des iterativen und inkrementellen Modells -
Die iterative und inkrementelle Entwicklung ist eine Kombination aus iterativem Design oder iterativer Methode und inkrementellem Build-Modell für die Entwicklung. "Während der Softwareentwicklung kann mehr als eine Iteration des Softwareentwicklungszyklus gleichzeitig ausgeführt werden." Dieser Prozess kann als "evolutionärer Erwerb" - oder "inkrementeller Build" -Ansatz beschrieben werden.
In diesem inkrementellen Modell ist die gesamte Anforderung in verschiedene Builds unterteilt. Während jeder Iteration durchläuft das Entwicklungsmodul die Phasen Anforderungen, Design, Implementierung und Test. Jede nachfolgende Version des Moduls fügt der vorherigen Version eine Funktion hinzu. Der Prozess wird fortgesetzt, bis das gesamte System gemäß den Anforderungen bereit ist.
Der Schlüssel für eine erfolgreiche Nutzung eines iterativen Softwareentwicklungszyklus ist die strenge Validierung der Anforderungen sowie die Überprüfung und Prüfung jeder Version der Software anhand dieser Anforderungen in jedem Zyklus des Modells. Während sich die Software in aufeinanderfolgenden Zyklen weiterentwickelt, müssen die Tests wiederholt und erweitert werden, um jede Version der Software zu überprüfen.
Iteratives Modell - Anwendung
Wie andere SDLC-Modelle hat die iterative und inkrementelle Entwicklung einige spezifische Anwendungen in der Softwareindustrie. Dieses Modell wird am häufigsten in den folgenden Szenarien verwendet:
Die Anforderungen des Gesamtsystems sind klar definiert und verstanden.
Hauptanforderungen müssen definiert werden; Einige Funktionen oder angeforderte Verbesserungen können sich jedoch mit der Zeit weiterentwickeln.
Es gibt eine Zeit für die Markteinschränkung.
Während der Arbeit am Projekt wird eine neue Technologie verwendet, die vom Entwicklungsteam erlernt wird.
Ressourcen mit den erforderlichen Fähigkeiten sind nicht verfügbar und sollen auf Vertragsbasis für bestimmte Iterationen verwendet werden.
Es gibt einige risikoreiche Funktionen und Ziele, die sich in Zukunft ändern können.
Iteratives Modell - Vor- und Nachteile
Der Vorteil dieses Modells besteht darin, dass es in einem sehr frühen Entwicklungsstadium ein funktionierendes Modell des Systems gibt, das das Auffinden von Funktions- oder Designfehlern erleichtert. Das frühzeitige Finden von Problemen ermöglicht es, Korrekturmaßnahmen in einem begrenzten Budget zu ergreifen.
Der Nachteil dieses SDLC-Modells besteht darin, dass es nur für große und umfangreiche Softwareentwicklungsprojekte anwendbar ist. Dies liegt daran, dass es schwierig ist, ein kleines Softwaresystem in weitere kleine wartungsfähige Inkremente / Module zu unterteilen.
Die Vorteile des iterativen und inkrementellen SDLC-Modells sind folgende:
Einige Arbeitsfunktionen können schnell und früh im Lebenszyklus entwickelt werden.
Die Ergebnisse werden früh und regelmäßig erhalten.
Parallele Entwicklung kann geplant werden.
Fortschritt kann gemessen werden.
Weniger kostspielig, um den Umfang / die Anforderungen zu ändern.
Das Testen und Debuggen während kleinerer Iterationen ist einfach.
Risiken werden während der Iteration identifiziert und behoben. und jede Iteration ist ein einfach zu verwaltender Meilenstein.
Einfacheres Risikomanagement - Der Teil mit hohem Risiko wird zuerst ausgeführt.
Mit jedem Schritt wird das Betriebsprodukt geliefert.
Probleme, Herausforderungen und Risiken, die aus jedem Inkrement identifiziert wurden, können auf das nächste Inkrement angewendet werden.
Risikoanalyse ist besser.
Es unterstützt sich ändernde Anforderungen.
Die anfängliche Betriebszeit ist kürzer.
Besser geeignet für große und unternehmenskritische Projekte.
Während des Lebenszyklus wird frühzeitig Software erstellt, die die Kundenbewertung und das Feedback erleichtert.
Die Nachteile des iterativen und inkrementellen SDLC-Modells sind wie folgt:
Möglicherweise sind weitere Ressourcen erforderlich.
Die Änderungskosten sind zwar geringer, aber für sich ändernde Anforderungen nicht sehr geeignet.
Es ist mehr Aufmerksamkeit des Managements erforderlich.
Systemarchitektur- oder Designprobleme können auftreten, da nicht alle Anforderungen zu Beginn des gesamten Lebenszyklus erfasst werden.
Das Definieren von Inkrementen erfordert möglicherweise die Definition des gesamten Systems.
Nicht für kleinere Projekte geeignet.
Die Komplexität des Managements ist größer.
Das Ende des Projekts ist möglicherweise nicht bekannt, was ein Risiko darstellt.
Für die Risikoanalyse sind hochqualifizierte Ressourcen erforderlich.
Der Projektfortschritt hängt stark von der Risikoanalyse ab.
Das Spiralmodell kombiniert die Idee der iterativen Entwicklung mit den systematischen, kontrollierten Aspekten des Wasserfallmodells. Dieses Spiralmodell ist eine Kombination aus iterativem Entwicklungsprozessmodell und sequentiellem linearem Entwicklungsmodell, dh dem Wasserfallmodell mit einem sehr hohen Schwerpunkt auf Risikoanalyse. Es ermöglicht inkrementelle Freigaben des Produkts oder inkrementelle Verfeinerung durch jede Iteration um die Spirale.
Spiralmodell - Design
Das Spiralmodell besteht aus vier Phasen. Ein Softwareprojekt durchläuft diese Phasen wiederholt in Iterationen, die als Spiralen bezeichnet werden.
Identifizierung
Diese Phase beginnt mit der Erfassung der Geschäftsanforderungen in der Basisspirale. In den nachfolgenden Spiralen, in denen das Produkt reift, werden in dieser Phase die Systemanforderungen, Subsystemanforderungen und Einheitenanforderungen identifiziert.
Diese Phase umfasst auch das Verständnis der Systemanforderungen durch kontinuierliche Kommunikation zwischen dem Kunden und dem Systemanalysten. Am Ende der Spirale wird das Produkt auf dem identifizierten Markt eingesetzt.
Design
Die Entwurfsphase beginnt mit dem Konzeptdesign in der Basisspirale und umfasst das Architekturdesign, das logische Design von Modulen, das physische Produktdesign und das endgültige Design in den nachfolgenden Spiralen.
Konstruieren oder bauen
Die Konstruktionsphase bezieht sich auf die Produktion des eigentlichen Softwareprodukts in jeder Spirale. In der Basisspirale wird in dieser Phase ein POC (Proof of Concept) entwickelt, um Kundenfeedback zu erhalten, wenn nur an das Produkt gedacht und das Design entwickelt wird.
In den folgenden Spiralen mit höherer Klarheit in Bezug auf Anforderungen und Designdetails wird dann ein Arbeitsmodell der Software namens Build mit einer Versionsnummer erstellt. Diese Builds werden zur Rückmeldung an den Kunden gesendet.
Bewertung und Risikoanalyse
Die Risikoanalyse umfasst das Identifizieren, Schätzen und Überwachen der technischen Machbarkeits- und Managementrisiken, wie z. B. Terminverschiebung und Kostenüberschreitung. Nach dem Testen des Builds bewertet der Kunde am Ende der ersten Iteration die Software und gibt Feedback.
Die folgende Abbildung zeigt das Spiralmodell und listet die Aktivitäten in jeder Phase auf.
Basierend auf der Kundenbewertung tritt der Softwareentwicklungsprozess in die nächste Iteration ein und folgt anschließend dem linearen Ansatz, um das vom Kunden vorgeschlagene Feedback zu implementieren. Der Prozess der Iterationen entlang der Spirale setzt sich während der gesamten Lebensdauer der Software fort.
Spiralmodellanwendung
Das Spiralmodell ist in der Softwareindustrie weit verbreitet, da es mit dem natürlichen Entwicklungsprozess eines Produkts synchronisiert ist, dh mit dem Lernen mit Reife, das ein minimales Risiko für den Kunden und die Entwicklungsfirmen beinhaltet.
Die folgenden Hinweise erläutern die typischen Verwendungszwecke eines Spiralmodells -
Wenn es eine Budgetbeschränkung gibt und die Risikobewertung wichtig ist.
Für Projekte mit mittlerem bis hohem Risiko.
Langfristiges Projektengagement aufgrund möglicher Änderungen der wirtschaftlichen Prioritäten, da sich die Anforderungen mit der Zeit ändern.
Der Kunde ist sich seiner Anforderungen nicht sicher, was normalerweise der Fall ist.
Die Anforderungen sind komplex und müssen bewertet werden, um Klarheit zu erhalten.
Neue Produktlinie, die schrittweise veröffentlicht werden sollte, um genügend Kundenfeedback zu erhalten.
Während des Entwicklungszyklus werden erhebliche Änderungen am Produkt erwartet.
Spiralmodell - Vor- und Nachteile
Der Vorteil des Spirallebenszyklusmodells besteht darin, dass Elemente des Produkts hinzugefügt werden können, sobald sie verfügbar oder bekannt sind. Dies stellt sicher, dass kein Konflikt mit früheren Anforderungen und Design besteht.
Diese Methode steht im Einklang mit Ansätzen mit mehreren Software-Builds und -Versionen, die einen ordnungsgemäßen Übergang zu einer Wartungsaktivität ermöglichen. Ein weiterer positiver Aspekt dieser Methode ist, dass das Spiralmodell eine frühzeitige Einbeziehung des Benutzers in die Systementwicklung erzwingt.
Auf der anderen Seite ist eine sehr strenge Verwaltung erforderlich, um solche Produkte fertigzustellen, und es besteht die Gefahr, dass die Spirale in einer unbestimmten Schleife verläuft. Daher ist die Disziplin des Wandels und das Ausmaß der Annahme von Änderungsanforderungen sehr wichtig, um das Produkt erfolgreich zu entwickeln und einzusetzen.
Die Vorteile des Spiral SDLC-Modells sind folgende:
Sich ändernde Anforderungen können berücksichtigt werden.
Ermöglicht die umfassende Verwendung von Prototypen.
Anforderungen können genauer erfasst werden.
Benutzer sehen das System frühzeitig.
Die Entwicklung kann in kleinere Teile unterteilt werden, und die riskanten Teile können früher entwickelt werden, was zu einem besseren Risikomanagement beiträgt.
Die Nachteile des Spiral SDLC-Modells sind wie folgt:
Management ist komplexer.
Das Ende des Projekts ist möglicherweise nicht vorzeitig bekannt.
Nicht für kleine oder risikoarme Projekte geeignet und kann für kleine Projekte teuer sein.
Der Prozess ist komplex
Die Spirale kann unbegrenzt weitergehen.
Eine große Anzahl von Zwischenstufen erfordert eine übermäßige Dokumentation.
Das V-Modell ist ein SDLC-Modell, bei dem die Ausführung von Prozessen in V-Form sequentiell erfolgt. Es ist auch bekannt alsVerification and Validation model.
Das V-Modell ist eine Erweiterung des Wasserfallmodells und basiert auf der Zuordnung einer Testphase für jede entsprechende Entwicklungsstufe. Dies bedeutet, dass für jede einzelne Phase im Entwicklungszyklus eine direkt zugeordnete Testphase vorhanden ist. Dies ist ein hochdiszipliniertes Modell und die nächste Phase beginnt erst nach Abschluss der vorherigen Phase.
V-Modell - Design
Im Rahmen des V-Modells ist parallel die entsprechende Testphase der Entwicklungsphase geplant. Es gibt also Verifizierungsphasen auf der einen Seite der 'V'- und Validierungsphasen auf der anderen Seite. Die Codierungsphase verbindet die beiden Seiten des V-Modells.
Die folgende Abbildung zeigt die verschiedenen Phasen in einem V-Modell des SDLC.
V-Modell - Verifizierungsphasen
Das V-Modell enthält mehrere Überprüfungsphasen, von denen jede im Folgenden ausführlich erläutert wird.
Analyse der Geschäftsanforderungen
Dies ist die erste Phase im Entwicklungszyklus, in der die Produktanforderungen aus Kundensicht verstanden werden. Diese Phase beinhaltet eine detaillierte Kommunikation mit dem Kunden, um seine Erwartungen und genauen Anforderungen zu verstehen. Dies ist eine sehr wichtige Aktivität und muss gut verwaltet werden, da die meisten Kunden nicht sicher sind, was genau sie benötigen. Dasacceptance test design planning wird in dieser Phase durchgeführt, da Geschäftsanforderungen als Eingabe für Abnahmetests verwendet werden können.
System-Design
Sobald Sie die klaren und detaillierten Produktanforderungen haben, ist es Zeit, das gesamte System zu entwerfen. Das Systemdesign vermittelt das Verständnis und die Detaillierung des gesamten Hardware- und Kommunikations-Setups für das in der Entwicklung befindliche Produkt. Der Systemtestplan wird basierend auf dem Systemdesign entwickelt. Wenn Sie dies zu einem früheren Zeitpunkt tun, bleibt später mehr Zeit für die eigentliche Testausführung.
Architekturdesign
In dieser Phase werden architektonische Spezifikationen verstanden und entworfen. In der Regel wird mehr als ein technischer Ansatz vorgeschlagen, und auf der Grundlage der technischen und finanziellen Durchführbarkeit wird die endgültige Entscheidung getroffen. Das Systemdesign ist weiter in Module unterteilt, die unterschiedliche Funktionen annehmen. Dies wird auch als bezeichnetHigh Level Design (HLD).
Die Datenübertragung und Kommunikation zwischen den internen Modulen und mit der Außenwelt (anderen Systemen) wird in dieser Phase klar verstanden und definiert. Mit diesen Informationen können in dieser Phase Integrationstests entworfen und dokumentiert werden.
Moduldesign
In dieser Phase wird das detaillierte interne Design für alle Systemmodule festgelegt, das als bezeichnet wird Low Level Design (LLD). Es ist wichtig, dass das Design mit den anderen Modulen in der Systemarchitektur und den anderen externen Systemen kompatibel ist. Die Unit-Tests sind ein wesentlicher Bestandteil jedes Entwicklungsprozesses und tragen dazu bei, die maximalen Fehler und Irrtümer frühzeitig zu beseitigen. Diese Komponententests können zu diesem Zeitpunkt basierend auf den internen Moduldesigns entworfen werden.
Codierungsphase
Die eigentliche Codierung der in der Entwurfsphase entworfenen Systemmodule wird in der Codierungsphase übernommen. Die am besten geeignete Programmiersprache wird basierend auf den System- und Architekturanforderungen festgelegt.
Die Codierung erfolgt basierend auf den Codierungsrichtlinien und -standards. Der Code durchläuft zahlreiche Codeüberprüfungen und wird für die beste Leistung optimiert, bevor der endgültige Build in das Repository eingecheckt wird.
Validierungsphasen
Die verschiedenen Validierungsphasen in einem V-Modell werden nachstehend ausführlich erläutert.
Unit Testing
In der Modulentwurfsphase entworfene Komponententests werden während dieser Validierungsphase für den Code ausgeführt. Unit-Tests sind Tests auf Code-Ebene und helfen, Fehler frühzeitig zu beseitigen, obwohl nicht alle Fehler durch Unit-Tests aufgedeckt werden können.
Integrationstests
Integrationstests sind mit der Phase des Architekturentwurfs verbunden. Integrationstests werden durchgeführt, um die Koexistenz und Kommunikation der internen Module innerhalb des Systems zu testen.
Systemtests
Systemtests sind direkt mit der Systementwurfsphase verbunden. Systemtests überprüfen die gesamte Systemfunktionalität und die Kommunikation des in Entwicklung befindlichen Systems mit externen Systemen. Die meisten Probleme mit der Software- und Hardwarekompatibilität können während dieser Systemtestausführung aufgedeckt werden.
Abnahmetests
Akzeptanztests sind mit der Phase der Analyse von Geschäftsanforderungen verbunden und umfassen das Testen des Produkts in einer Benutzerumgebung. Akzeptanztests decken die Kompatibilitätsprobleme mit den anderen in der Benutzerumgebung verfügbaren Systemen auf. Außerdem werden nicht funktionierende Probleme wie Last- und Leistungsmängel in der tatsächlichen Benutzerumgebung erkannt.
V-Modell ─ Anwendung
Die Anwendung des V-Modells entspricht fast der des Wasserfallmodells, da beide Modelle vom sequentiellen Typ sind. Die Anforderungen müssen vor Projektbeginn sehr klar sein, da es normalerweise teuer ist, zurück zu gehen und Änderungen vorzunehmen. Dieses Modell wird im Bereich der medizinischen Entwicklung verwendet, da es streng diszipliniert ist.
Die folgenden Hinweise sind einige der am besten geeigneten Szenarien für die Verwendung der V-Model-Anwendung.
Die Anforderungen sind klar definiert, klar dokumentiert und festgelegt.
Die Produktdefinition ist stabil.
Technologie ist nicht dynamisch und wird vom Projektteam gut verstanden.
Es gibt keine mehrdeutigen oder undefinierten Anforderungen.
Das Projekt ist kurz.
V-Modell - Vor- und Nachteile
Der Vorteil der V-Modell-Methode besteht darin, dass sie sehr einfach zu verstehen und anzuwenden ist. Die Einfachheit dieses Modells erleichtert auch die Verwaltung. Der Nachteil ist, dass das Modell nicht flexibel auf Änderungen reagiert und nur für den Fall, dass es zu einer Anforderungsänderung kommt, die in der heutigen dynamischen Welt sehr häufig ist, die Änderung sehr teuer wird.
Die Vorteile der V-Modell-Methode sind folgende:
Dies ist ein hochdiszipliniertes Modell, und die Phasen werden einzeln abgeschlossen.
Funktioniert gut für kleinere Projekte, bei denen die Anforderungen sehr gut verstanden werden.
Einfach und leicht zu verstehen und zu verwenden.
Aufgrund der Steifigkeit des Modells einfach zu handhaben. Jede Phase hat spezifische Ergebnisse und einen Überprüfungsprozess.
Die Nachteile der V-Modell-Methode sind wie folgt:
Hohes Risiko und Unsicherheit.
Kein gutes Modell für komplexe und objektorientierte Projekte.
Schlechtes Modell für lange und laufende Projekte.
Nicht geeignet für Projekte, bei denen die Anforderungen einem mittleren bis hohen Änderungsrisiko unterliegen.
Sobald sich eine Anwendung in der Testphase befindet, ist es schwierig, eine Funktionalität zu ändern.
Bis spät im Lebenszyklus wird keine funktionierende Software erstellt.
Das Urknallmodell ist ein SDLC-Modell, bei dem wir keinem bestimmten Prozess folgen. Die Entwicklung beginnt nur mit dem erforderlichen Geld und Aufwand als Eingabe, und die Ausgabe ist die Software, die gemäß den Kundenanforderungen entwickelt wurde oder nicht. Dieses Urknallmodell folgt keinem Prozess / Verfahren und es ist nur sehr wenig Planung erforderlich. Selbst der Kunde ist sich nicht sicher, was genau er will, und die Anforderungen werden ohne viel Analyse im laufenden Betrieb umgesetzt.
Normalerweise wird dieses Modell für kleine Projekte verwendet, bei denen die Entwicklungsteams sehr klein sind.
Urknallmodell ─ Design und Anwendung
Das Urknallmodell besteht darin, alle möglichen Ressourcen in der Softwareentwicklung und -codierung mit sehr wenig oder keiner Planung zu fokussieren. Die Anforderungen werden so verstanden und umgesetzt, wie sie kommen. Alle erforderlichen Änderungen müssen möglicherweise die gesamte Software überarbeiten oder nicht.
Dieses Modell ist ideal für kleine Projekte, bei denen ein oder zwei Entwickler zusammenarbeiten, und eignet sich auch für akademische oder praktische Projekte. Es ist ein ideales Modell für das Produkt, bei dem die Anforderungen nicht genau verstanden werden und das endgültige Veröffentlichungsdatum nicht angegeben ist.
Urknallmodell - Vor- und Nachteile
Der Vorteil dieses Urknallmodells ist, dass es sehr einfach ist und nur sehr wenig oder gar keine Planung erfordert. Einfach zu verwalten und kein formelles Verfahren erforderlich.
Das Urknallmodell ist jedoch ein Modell mit sehr hohem Risiko, und Änderungen der Anforderungen oder missverstandene Anforderungen können sogar zu einer vollständigen Umkehrung oder Abschaffung des Projekts führen. Es ist ideal für sich wiederholende oder kleine Projekte mit minimalen Risiken.
Die Vorteile des Urknallmodells sind wie folgt:
Dies ist ein sehr einfaches Modell
Wenig oder keine Planung erforderlich
Einfach zu verwalten
Sehr wenige Ressourcen erforderlich
Gibt Entwicklern Flexibilität
Es ist eine gute Lernhilfe für Neuankömmlinge oder Studenten.
Die Nachteile des Urknallmodells sind wie folgt:
Sehr hohes Risiko und Unsicherheit.
Kein gutes Modell für komplexe und objektorientierte Projekte.
Schlechtes Modell für lange und laufende Projekte.
Kann sich als sehr teuer herausstellen, wenn Anforderungen missverstanden werden.
Das agile SDLC-Modell ist eine Kombination aus iterativen und inkrementellen Prozessmodellen mit Schwerpunkt auf Prozessanpassungsfähigkeit und Kundenzufriedenheit durch schnelle Lieferung eines funktionierenden Softwareprodukts. Agile Methoden unterteilen das Produkt in kleine inkrementelle Builds. Diese Builds werden in Iterationen bereitgestellt. Jede Iteration dauert normalerweise etwa ein bis drei Wochen. Bei jeder Iteration arbeiten funktionsübergreifende Teams gleichzeitig an verschiedenen Bereichen wie:
- Planning
- Anforderungsanalyse
- Design
- Coding
- Unit Testing und
- Abnahmetests.
Am Ende der Iteration wird dem Kunden und wichtigen Stakeholdern ein funktionierendes Produkt angezeigt.
Was ist agil?
Das agile Modell ist der Ansicht, dass jedes Projekt anders gehandhabt werden muss und die vorhandenen Methoden auf die Projektanforderungen zugeschnitten werden müssen. In Agile sind die Aufgaben in Zeitfelder (kleine Zeitrahmen) unterteilt, um bestimmte Funktionen für eine Version bereitzustellen.
Nach jeder Iteration wird ein iterativer Ansatz gewählt und ein funktionierender Software-Build bereitgestellt. Jeder Build ist in Bezug auf Funktionen inkrementell. Der endgültige Build enthält alle vom Kunden benötigten Funktionen.
Hier ist eine grafische Darstellung des agilen Modells -
Der agile Denkprozess hatte früh in der Softwareentwicklung begonnen und wurde aufgrund seiner Flexibilität und Anpassungsfähigkeit mit der Zeit immer beliebter.
Zu den beliebtesten agilen Methoden gehören Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development und Dynamic Systems Development Method (DSDM) (1995). Diese werden nun gemeinsam als bezeichnetAgile Methodologies, nachdem das Agile Manifest im Jahr 2001 veröffentlicht wurde.
Es folgen die Prinzipien des Agilen Manifests -
Individuals and interactions - In der agilen Entwicklung sind Selbstorganisation und Motivation wichtig, ebenso wie Interaktionen wie Co-Location und Paarprogrammierung.
Working software - Demo-Arbeitssoftware wird als das beste Kommunikationsmittel mit den Kunden angesehen, um deren Anforderungen zu verstehen, anstatt nur von der Dokumentation abhängig zu sein.
Customer collaboration - Da die Anforderungen zu Beginn des Projekts aufgrund verschiedener Faktoren nicht vollständig erfasst werden können, ist eine kontinuierliche Kundeninteraktion sehr wichtig, um die richtigen Produktanforderungen zu erhalten.
Responding to change - Agile Development konzentriert sich auf schnelle Reaktionen auf Veränderungen und kontinuierliche Entwicklung.
Agile Vs traditionelle SDLC-Modelle
Agile basiert auf dem adaptive software development methodsWährend die traditionellen SDLC-Modelle wie das Wasserfallmodell auf einem prädiktiven Ansatz basieren. Vorausschauende Teams in den traditionellen SDLC-Modellen arbeiten normalerweise mit detaillierter Planung und haben eine vollständige Prognose der genauen Aufgaben und Funktionen, die in den nächsten Monaten oder während des Produktlebenszyklus geliefert werden sollen.
Vorhersagemethoden hängen vollständig von der requirement analysis and planningzu Beginn des Zyklus durchgeführt. Alle Änderungen, die übernommen werden sollen, unterliegen einer strengen Änderungskontrolle und Priorisierung.
Agile verwendet eine adaptive approachWo es keine detaillierte Planung gibt und Klarheit über zukünftige Aufgaben nur in Bezug darauf besteht, welche Funktionen entwickelt werden müssen. Es gibt eine funktionsgesteuerte Entwicklung und das Team passt sich dynamisch an die sich ändernden Produktanforderungen an. Das Produkt wird sehr häufig durch die Release-Iterationen getestet, um das Risiko größerer Fehler in Zukunft zu minimieren.
Customer Interactionist das Rückgrat dieser agilen Methodik, und offene Kommunikation mit minimaler Dokumentation sind die typischen Merkmale der agilen Entwicklungsumgebung. Die agilen Teams arbeiten eng zusammen und befinden sich meist am selben geografischen Standort.
Agiles Modell - Vor- und Nachteile
Agile Methoden sind in der Software-Welt in letzter Zeit weit verbreitet. Diese Methode ist jedoch möglicherweise nicht immer für alle Produkte geeignet. Hier sind einige Vor- und Nachteile des Agile-Modells.
Die Vorteile des agilen Modells sind folgende:
Ist ein sehr realistischer Ansatz für die Softwareentwicklung.
Fördert Teamwork und Cross Training.
Funktionalität kann schnell entwickelt und demonstriert werden.
Ressourcenanforderungen sind minimal.
Geeignet für feste oder sich ändernde Anforderungen
Liefert frühzeitige Teilarbeitslösungen.
Gutes Modell für Umgebungen, die sich ständig ändern.
Minimale Regeln, Dokumentation einfach anzuwenden.
Ermöglicht die gleichzeitige Entwicklung und Bereitstellung in einem insgesamt geplanten Kontext.
Wenig oder keine Planung erforderlich.
Einfach zu verwalten.
Gibt Entwicklern Flexibilität.
Die Nachteile des agilen Modells sind wie folgt:
Nicht geeignet für den Umgang mit komplexen Abhängigkeiten.
Mehr Risiko für Nachhaltigkeit, Wartbarkeit und Erweiterbarkeit.
Ein Gesamtplan, ein agiler Leiter und eine agile PM-Praxis sind ein Muss, ohne das es nicht funktioniert.
Das strikte Liefermanagement bestimmt den Umfang, die zu liefernde Funktionalität und die Anpassungen, um die Fristen einzuhalten.
Hängt stark von der Kundeninteraktion ab. Wenn der Kunde nicht klar ist, kann das Team in die falsche Richtung geführt werden.
Es besteht eine sehr hohe individuelle Abhängigkeit, da nur eine minimale Dokumentation generiert wird.
Der Technologietransfer an neue Teammitglieder kann aufgrund fehlender Dokumentation eine große Herausforderung darstellen.
Das RAD (Rapid Application Development)Das Modell basiert auf Prototyping und iterativer Entwicklung ohne spezifische Planung. Das Schreiben der Software selbst beinhaltet die Planung, die für die Entwicklung des Produkts erforderlich ist.
Die schnelle Anwendungsentwicklung konzentriert sich auf die Erfassung der Kundenanforderungen durch Workshops oder Fokusgruppen, das frühzeitige Testen der Prototypen durch den Kunden mithilfe eines iterativen Konzepts, die Wiederverwendung der vorhandenen Prototypen (Komponenten), die kontinuierliche Integration und die schnelle Lieferung.
Was ist RAD?
Die schnelle Anwendungsentwicklung ist eine Softwareentwicklungsmethode, bei der nur eine minimale Planung zugunsten des Rapid Prototyping erforderlich ist. Ein Prototyp ist ein Arbeitsmodell, das einer Komponente des Produkts funktional entspricht.
Im RAD-Modell werden die Funktionsmodule parallel als Prototypen entwickelt und integriert, um das Gesamtprodukt für eine schnellere Produktlieferung zu erstellen. Da es keine detaillierte Vorplanung gibt, ist es einfacher, die Änderungen in den Entwicklungsprozess einzubeziehen.
RAD-Projekte folgen einem iterativen und inkrementellen Modell und haben kleine Teams, bestehend aus Entwicklern, Domain-Experten, Kundenvertretern und anderen IT-Ressourcen, die schrittweise an ihrer Komponente oder ihrem Prototyp arbeiten.
Der wichtigste Aspekt für den Erfolg dieses Modells ist die Sicherstellung, dass die entwickelten Prototypen wiederverwendbar sind.
RAD-Modelldesign
Das RAD-Modell verteilt die Analyse-, Entwurfs-, Erstellungs- und Testphasen in eine Reihe kurzer, iterativer Entwicklungszyklen.
Es folgen die verschiedenen Phasen des RAD-Modells -
Geschäftsmodellierung
Das Geschäftsmodell für das in der Entwicklung befindliche Produkt basiert auf dem Informationsfluss und der Verteilung von Informationen zwischen verschiedenen Geschäftskanälen. Eine vollständige Geschäftsanalyse wird durchgeführt, um die für das Geschäft wichtigen Informationen zu finden, wie sie erhalten werden können, wie und wann die Informationen verarbeitet werden und welche Faktoren für einen erfolgreichen Informationsfluss verantwortlich sind.
Datenmodellierung
Die in der Phase der Geschäftsmodellierung gesammelten Informationen werden überprüft und analysiert, um Sätze von Datenobjekten zu bilden, die für das Geschäft von entscheidender Bedeutung sind. Die Attribute aller Datensätze werden identifiziert und definiert. Die Beziehung zwischen diesen Datenobjekten wird in Bezug auf das Geschäftsmodell detailliert festgelegt und definiert.
Prozessmodellierung
Die in der Datenmodellierungsphase definierten Datenobjektsätze werden konvertiert, um den Geschäftsinformationsfluss festzulegen, der zur Erreichung bestimmter Geschäftsziele gemäß dem Geschäftsmodell erforderlich ist. In dieser Phase wird das Prozessmodell für Änderungen oder Erweiterungen der Datenobjektsätze definiert. Prozessbeschreibungen zum Hinzufügen, Löschen, Abrufen oder Ändern eines Datenobjekts werden angegeben.
Anwendungsgenerierung
Das eigentliche System wird erstellt und die Codierung erfolgt mithilfe von Automatisierungstools, um Prozess- und Datenmodelle in tatsächliche Prototypen umzuwandeln.
Testen und Umsatz
Die Gesamttestzeit wird im RAD-Modell reduziert, da die Prototypen bei jeder Iteration unabhängig getestet werden. Der Datenfluss und die Schnittstellen zwischen allen Komponenten müssen jedoch gründlich mit vollständiger Testabdeckung getestet werden. Da die meisten Programmierkomponenten bereits getestet wurden, wird das Risiko größerer Probleme verringert.
Die folgende Abbildung beschreibt das RAD-Modell im Detail.
RAD-Modell gegen traditionelles SDLC
Der traditionelle SDLC folgt einem starren Prozessmodell mit einem hohen Schwerpunkt auf Anforderungsanalyse und -erfassung, bevor die Codierung beginnt. Es setzt den Kunden unter Druck, die Anforderungen vor Projektbeginn zu unterzeichnen, und der Kunde bekommt kein Gefühl für das Produkt, da lange Zeit kein funktionierender Build verfügbar ist.
Der Kunde muss möglicherweise einige Änderungen vornehmen, nachdem er die Software gesehen hat. Der Änderungsprozess ist jedoch ziemlich starr und es ist möglicherweise nicht möglich, größere Änderungen am Produkt in die traditionelle SDLC aufzunehmen.
Das RAD-Modell konzentriert sich auf die iterative und inkrementelle Bereitstellung von Arbeitsmodellen an den Kunden. Dies führt zu einer schnellen Lieferung an den Kunden und einer Kundenbeteiligung während des gesamten Entwicklungszyklus des Produkts, wodurch das Risiko einer Nichteinhaltung der tatsächlichen Benutzeranforderungen verringert wird.
RAD-Modell - Anwendung
Das RAD-Modell kann erfolgreich auf Projekte angewendet werden, bei denen eine klare Modularisierung möglich ist. Wenn das Projekt nicht in Module unterteilt werden kann, schlägt RAD möglicherweise fehl.
Die folgenden Hinweise beschreiben die typischen Szenarien, in denen RAD verwendet werden kann:
RAD sollte nur verwendet werden, wenn ein System modularisiert werden kann, um inkrementell geliefert zu werden.
Es sollte verwendet werden, wenn eine hohe Verfügbarkeit von Designern für die Modellierung besteht.
Es sollte nur verwendet werden, wenn das Budget die Verwendung automatisierter Tools zur Codegenerierung zulässt.
Das RAD SDLC-Modell sollte nur gewählt werden, wenn Domain-Experten mit relevanten Geschäftskenntnissen verfügbar sind.
Sollte verwendet werden, wenn sich die Anforderungen während des Projekts ändern und funktionierende Prototypen dem Kunden in kleinen Iterationen von 2-3 Monaten präsentiert werden sollen.
RAD-Modell - Vor- und Nachteile
Das RAD-Modell ermöglicht eine schnelle Lieferung, da es die Gesamtentwicklungszeit aufgrund der Wiederverwendbarkeit der Komponenten und der parallelen Entwicklung verkürzt. RAD funktioniert nur dann gut, wenn hochqualifizierte Ingenieure verfügbar sind und der Kunde sich auch verpflichtet, den angestrebten Prototyp innerhalb des vorgegebenen Zeitrahmens zu erreichen. Wenn auf beiden Seiten keine Verpflichtung besteht, kann das Modell versagen.
Die Vorteile des RAD-Modells sind folgende:
Sich ändernde Anforderungen können berücksichtigt werden.
Fortschritt kann gemessen werden.
Die Iterationszeit kann bei Verwendung leistungsstarker RAD-Tools kurz sein.
Produktivität mit weniger Menschen in kurzer Zeit.
Reduzierte Entwicklungszeit.
Erhöht die Wiederverwendbarkeit von Komponenten.
Es finden schnelle erste Überprüfungen statt.
Ermutigt Kunden zu Feedback.
Die Integration von Anfang an löst viele Integrationsprobleme.
Die Nachteile des RAD-Modells sind wie folgt:
Abhängigkeit von technisch starken Teammitgliedern zur Ermittlung der Geschäftsanforderungen.
Nur ein System, das modularisiert werden kann, kann mit RAD erstellt werden.
Benötigt hochqualifizierte Entwickler / Designer.
Hohe Abhängigkeit von Modellierungsfähigkeiten.
Nicht anwendbar auf billigere Projekte, da die Kosten für die Modellierung und die automatisierte Codegenerierung sehr hoch sind.
Die Komplexität des Managements ist größer.
Geeignet für Systeme, die komponentenbasiert und skalierbar sind.
Erfordert die Einbeziehung des Benutzers während des gesamten Lebenszyklus.
Geeignet für Projekte, die kürzere Entwicklungszeiten erfordern.
Das Software-Prototyping bezieht sich auf das Erstellen von Prototypen für Softwareanwendungen, die die Funktionalität des in der Entwicklung befindlichen Produkts anzeigen, jedoch möglicherweise nicht die genaue Logik der ursprünglichen Software enthalten.
Software-Prototyping wird als Softwareentwicklungsmodell immer beliebter, da es ermöglicht, die Kundenanforderungen in einem frühen Stadium der Entwicklung zu verstehen. Es hilft dabei, wertvolles Feedback vom Kunden zu erhalten, und hilft Software-Designern und -Entwicklern zu verstehen, was genau von dem in der Entwicklung befindlichen Produkt erwartet wird.
Was ist Software Prototyping?
Der Prototyp ist ein funktionierendes Softwaremodell mit eingeschränkter Funktionalität. Der Prototyp enthält nicht immer die genaue Logik, die in der tatsächlichen Softwareanwendung verwendet wird, und ist ein zusätzlicher Aufwand, der bei der Aufwandsschätzung berücksichtigt werden muss.
Mithilfe des Prototyping können die Benutzer Entwicklervorschläge bewerten und vor der Implementierung ausprobieren. Es hilft auch dabei, die Anforderungen zu verstehen, die benutzerspezifisch sind und vom Entwickler beim Produktdesign möglicherweise nicht berücksichtigt wurden.
Es folgt ein schrittweiser Ansatz zum Entwerfen eines Software-Prototyps.
Identifizierung der Grundanforderungen
Dieser Schritt beinhaltet das Verständnis der grundlegenden Produktanforderungen, insbesondere in Bezug auf die Benutzeroberfläche. Die komplizierteren Details des internen Designs und externe Aspekte wie Leistung und Sicherheit können in dieser Phase ignoriert werden.
Entwicklung des ersten Prototyps
In dieser Phase wird der erste Prototyp entwickelt, in dem die grundlegenden Anforderungen vorgestellt und Benutzeroberflächen bereitgestellt werden. Diese Funktionen funktionieren möglicherweise intern in der tatsächlich entwickelten Software nicht genau auf die gleiche Weise. Die Problemumgehungen werden verwendet, um dem Kunden im entwickelten Prototyp das gleiche Erscheinungsbild zu verleihen.
Überprüfung des Prototyps
Der entwickelte Prototyp wird dann dem Kunden und den anderen wichtigen Projektbeteiligten vorgestellt. Das Feedback wird auf organisierte Weise gesammelt und für weitere Verbesserungen des in der Entwicklung befindlichen Produkts verwendet.
Überarbeiten und verbessern Sie den Prototyp
Das Feedback und die Überprüfungskommentare werden in dieser Phase diskutiert, und einige Verhandlungen mit dem Kunden finden auf der Grundlage von Faktoren wie Zeit- und Budgetbeschränkungen und der technischen Machbarkeit der tatsächlichen Implementierung statt. Die akzeptierten Änderungen werden erneut in den neu entwickelten Prototyp übernommen und der Zyklus wiederholt sich, bis die Kundenerwartungen erfüllt sind.
Prototypen können horizontale oder vertikale Abmessungen haben. Ein horizontaler Prototyp zeigt die Benutzeroberfläche des Produkts an und bietet einen breiteren Überblick über das gesamte System, ohne sich auf interne Funktionen zu konzentrieren. Ein vertikaler Prototyp auf der anderen Seite ist eine detaillierte Ausarbeitung einer bestimmten Funktion oder eines Teilsystems im Produkt.
Der Zweck des horizontalen und vertikalen Prototyps ist unterschiedlich. Horizontale Prototypen werden verwendet, um weitere Informationen zur Benutzeroberfläche und zu den Geschäftsanforderungen zu erhalten. Es kann sogar in den Verkaufsdemos vorgestellt werden, um das Geschäft auf den Markt zu bringen. Vertikale Prototypen sind technischer Natur und werden verwendet, um Details über die genaue Funktionsweise der Subsysteme zu erhalten. Zum Beispiel Datenbankanforderungen, Interaktion und Datenverarbeitungslasten in einem bestimmten Subsystem.
Software Prototyping - Typen
In der Branche werden verschiedene Arten von Software-Prototypen verwendet. Im Folgenden sind die wichtigsten weit verbreiteten Software-Prototyping-Typen aufgeführt:
Wegwerf- / Rapid-Prototyping
Einweg-Prototyping wird auch als Rapid- oder Close-Ended-Prototyping bezeichnet. Diese Art des Prototyping erfordert nur sehr wenig Aufwand mit einer Analyse der Mindestanforderungen, um einen Prototyp zu erstellen. Sobald die tatsächlichen Anforderungen verstanden sind, wird der Prototyp verworfen und das eigentliche System mit einem klaren Verständnis der Benutzeranforderungen entwickelt.
Evolutionäres Prototyping
Evolutionäres Prototyping, auch als Breadboard-Prototyping bezeichnet, basiert auf der Erstellung tatsächlicher funktionaler Prototypen mit minimaler Funktionalität am Anfang. Der entwickelte Prototyp bildet das Herzstück der zukünftigen Prototypen, auf denen das gesamte System aufgebaut ist. Durch die Verwendung von evolutionärem Prototyping werden die gut verstandenen Anforderungen in den Prototyp aufgenommen und die Anforderungen werden hinzugefügt, sobald sie verstanden werden.
Inkrementelles Prototyping
Inkrementelles Prototyping bezieht sich auf die Erstellung mehrerer funktionaler Prototypen der verschiedenen Subsysteme und die anschließende Integration aller verfügbaren Prototypen zu einem vollständigen System.
Extremes Prototyping
Extreme Prototyping wird in der Webentwicklungsdomäne verwendet. Es besteht aus drei aufeinander folgenden Phasen. Zunächst wird ein grundlegender Prototyp mit allen vorhandenen Seiten im HTML-Format dargestellt. Anschließend wird die Datenverarbeitung mithilfe einer Prototyp-Serviceschicht simuliert. Schließlich werden die Services implementiert und in den endgültigen Prototyp integriert. Dieser Prozess wird als Extreme Prototyping bezeichnet und dient dazu, die Aufmerksamkeit auf die zweite Phase des Prozesses zu lenken, in der eine voll funktionsfähige Benutzeroberfläche entwickelt wird, bei der die tatsächlichen Dienste kaum berücksichtigt werden.
Software Prototyping - Anwendung
Software Prototyping ist am nützlichsten bei der Entwicklung von Systemen mit einem hohen Maß an Benutzerinteraktionen, wie z. B. Online-Systemen. Systeme, bei denen Benutzer Formulare ausfüllen oder verschiedene Bildschirme durchlaufen müssen, bevor Daten verarbeitet werden, können Prototyping sehr effektiv einsetzen, um das genaue Erscheinungsbild zu erhalten, noch bevor die eigentliche Software entwickelt wird.
Software, die zu viel Datenverarbeitung erfordert und die meisten Funktionen intern mit sehr wenig Benutzeroberfläche ist, profitiert normalerweise nicht vom Prototyping. Die Entwicklung von Prototypen kann bei solchen Projekten einen zusätzlichen Aufwand bedeuten und erfordert möglicherweise zusätzliche Anstrengungen.
Software Prototyping - Vor- und Nachteile
In typischen Fällen wird Software-Prototyping verwendet, und die Entscheidung sollte sehr sorgfältig getroffen werden, damit der Aufwand für die Erstellung des Prototyps einen erheblichen Mehrwert für die endgültig entwickelte Software darstellt. Das Modell hat seine eigenen Vor- und Nachteile, die wie folgt diskutiert werden.
Die Vorteile des Prototyping-Modells sind folgende:
Verstärkte Beteiligung der Benutzer am Produkt bereits vor seiner Implementierung.
Da ein Arbeitsmodell des Systems angezeigt wird, erhalten die Benutzer ein besseres Verständnis des zu entwickelnden Systems.
Reduziert Zeit und Kosten, da die Fehler viel früher erkannt werden können.
Es ist ein schnelleres Benutzerfeedback verfügbar, das zu besseren Lösungen führt.
Fehlende Funktionen können leicht identifiziert werden.
Verwirrende oder schwierige Funktionen können identifiziert werden.
Die Nachteile des Prototyping-Modells sind wie folgt:
Risiko einer unzureichenden Anforderungsanalyse aufgrund zu starker Abhängigkeit vom Prototyp.
Benutzer können in den Prototypen und tatsächlichen Systemen verwirrt sein.
In der Praxis kann diese Methodik die Komplexität des Systems erhöhen, da der Umfang des Systems über die ursprünglichen Pläne hinausgehen kann.
Entwickler können versuchen, die vorhandenen Prototypen wiederzuverwenden, um das eigentliche System zu erstellen, auch wenn dies technisch nicht machbar ist.
Der Aufwand für den Bau von Prototypen kann zu hoch sein, wenn er nicht ordnungsgemäß überwacht wird.