WikiDer > V-Modell

V-model

Es V-Modell ist eine lineare Softwareentwicklungsmethode und wurde 1986 von Paul E. Rook entworfen.[1] Das V-Modell wurde ursprünglich von der Wasserfallmethode.

Einrichtungsmethode

Es V-Modell verbringt anders als es Wasserfall-Modell ausgewogene Aufmerksamkeit für Entwicklung und development Überprüfung. Es Software-Design einschließlich der Verifizierung gliedert sich in mehrere Phasen, von denen jede eine Reihe von vordefinierten Produkten liefert. Wenn die Produkte einer Phase geliefert werden, bilden sie die Grundlage für die nächste Phase, so dass eine neue Phase nicht gestartet werden kann, wenn die Produkte der vorherigen Phase nicht geliefert (und freigegeben) wurden. Dies wiederholt sich für alle Phasen, und mit jeder Neugründung wächst das Vertrauen in das System.

Phasenverschiebung

Beispiel für ein V-Modell. (Niederländische Sprache)
Beispiel für ein häufigeres (englisches) V-Modell.

Die Phasen und Produkte werden in einem V-Modell dargestellt (Abbildung 1). Für jede Spezifikations- oder Designstufe links vom „V“ gibt es eine entsprechende Integrationsstufe rechts vom „V“. In Abbildung 1 repräsentieren die rechteckigen Blöcke die Phasen und die ovalen Blöcke die Produkte. Das V-Modell ist ein lineares Verfahren und wird immer in der in Abbildung 1 gezeigten Reihenfolge durchgeführt.

Im Allgemeinen sieht der Entwicklungsprozess so aus, also ist dies die linke Seite des Modells:

Geschäftsfall

Das Geschäftsfall ist der erste Entwicklungsschritt, in dem der Kunde beschreibt, was von dem neuen System erwartet wird. Muss ein ganz neues System entwickelt werden? Oder ist eine Erweiterung zu einem bereits im Einsatz befindlichen System beabsichtigt? Was sind die erwarteten Vorteile, die das System dem Kunden nach Fertigstellung bringen wird, und wie hoch sind die geschätzten Kosten für die Entwicklung und Bereitstellung dieses Systems? Der Business Case ist die wirtschaftliche Grundlage für das Projekt. Wie hoch ist die Investition und wie hoch sind die erwarteten Renditen?

Bedarf

Biene Anforderungen beschreibt die vom Kunden abzunehmenden Anforderungen an das System. Dies ist eine Beschreibung sowohl der funktionalen als auch der nichtfunktionalen Anforderungen.

Informationsanalyse

Anforderungen werden dann an die Entwickler weitergegeben. Diese machen dann a System Spezifikation. Dies ändert die Fokus von dem, was das System können soll, bis hin zur Art und Weise, wie dies erreicht werden soll, d Methode, Software, Hardware- ist erforderlich, um die Anforderungen zu erfüllen.

System-Design

Andere Entwickler arbeiten dann mit dem System-Design, diese wird auf Basis der bereits erstellten Systemspezifikation erstellt. Es listet die verschiedenen Komponenten auf, die das System enthalten wird, um die Anforderungen zu erfüllen Anforderungen miteinander einhalten zu können und die Beziehung zwischen den Komponenten wird beschrieben.

Komponentendesign

Jede Komponente hat auch ein eigenes Design, das detailliert beschreibt, wie sie ihre Prozesse abwickelt.

Programmierung

Die Komponenten werden gebaut, das System ist dann bereit für den Testprozess.

Testprozess

Der mit der oben beschriebenen Methode verbundene Testprozess sieht wie folgt aus, also ist dies die rechte Seite des Modells:

Gerätetest

Bei der Gerätetest werden die einzelnen komponenten geprüft: erfüllen sie die in der komponentenauslegung beschriebenen bedingungen? Theoretisch sollte dies ein unabhängiger Tester tun, in der Praxis wird dies jedoch in der Regel vom Entwickler selbst durchgeführt. Ein Problem beim Unit-Test besteht darin, dass die Komponente den Test "einzeln" bestehen kann, aber irgendwann in einem Gesamtsystem funktionieren muss. Daher wird oft Software verwendet, die die Komponente dazu bringt, in einem Gesamtsystem zu arbeiten, während dies so ist, dass überhaupt nicht der Fall.

Integrationstest

Wenn Komponenten einzeln getestet wurden, ist die Integrationstest, hier wird nämlich geprüft, ob die miteinander verknüpften Komponenten noch wie gewünscht funktionieren. Dieser Test kann vom Entwickler oder von Spezialisten durchgeführt werden.

Systemtest

Wenn das komplette System gebaut ist, ist es Zeit für die voor Systemtest. Dabei wird geprüft, ob alle Anforderungen erfüllt werden können. Dabei werden nicht verschiedene Komponenten getestet, sondern das gesamte System. Dazu gehört unter anderem das Testen:

  • Performance - Wurden die vorab festgelegten Ziele für diesen Punkt erreicht?
  • Volumen - Kann das System große Informationsmengen verarbeiten?
  • Stress - Kann das System zu einem bestimmten Zeitpunkt große Informationsmengen verarbeiten? (Stoßzeiten)
  • Dokumentation - Ist die mitgelieferte Dokumentation für das endgültige System verwendbar?
  • Robustheit - Bleibt das System unter außergewöhnlichen Umständen stabil?

Abnahmeprüfung

Das Abnahmeprüfung teste das tatsächlich Geschäftsfall: Liefert das System das, was der Kunde erwartet, um ihm in seinem Arbeitsbereich einen Vorteil zu verschaffen? Mit anderen Worten, alle Anforderungen wurden erfüllt. Dieser Test muss natürlich vom Kunde / Benutzer. Man spricht auch vom UAT (User Acceptance Test) oder auf gutem Niederländisch, den Nederlands Benutzerakzeptanztest.

Freigabetest

Der Release-Test testet, wie das System letztendlich in der Organisation läuft. Wirkt es sich beispielsweise auf andere Systeme aus? Ist der kompatibel mit den anderen Systemen? Wie hoch ist die tatsächliche Leistung des Systems innerhalb der Organisation?

Techniken

Das V-Modell schlägt keine speziellen Techniken für die verschiedenen Phasen vor. Techniken, die für die rechte Seite (die Testseite) verwendet werden können, sind:

Leistungen

  • Jede Integrationsstufe wird getestet.

Nachteile

  • Das V-Modell geht davon aus, dass sich die Anforderungen nicht ändern.
  • Das Design ist nicht verifiziert.
  • Anforderungen werden nicht überprüft.
  • In jeder Phase besteht das Risiko von Fehlern. Fehler am besten so früh wie möglich im Prozess finden und beheben, das ist immer günstiger. Im V-Modell findet nach dem Design der Module die erste Verifikationsphase statt. Bei anderen Methoden erfolgt die Verifikation bereits in der Spezifikationsphase.

Quellen

Siehe die Kategorie V-Modelle von Wikimedia Commons für Mediendateien zu diesem Thema.