{"id":4211,"date":"2023-05-23T15:39:08","date_gmt":"2023-05-23T13:39:08","guid":{"rendered":"http:\/\/www.johner-institut.de\/blog\/?p=4211"},"modified":"2024-11-03T13:27:59","modified_gmt":"2024-11-03T12:27:59","slug":"v-modell","status":"publish","type":"post","link":"https:\/\/www.johner-institut.de\/blog\/iec-62304-medizinische-software\/v-modell\/","title":{"rendered":"V-Modell: Die 5 h\u00e4ufigsten Probleme vermeiden"},"content":{"rendered":"\n

Das V-Modell<\/strong> ist ein Entwicklungsprozessmodell, das urspr\u00fcnglich bei staatlichen Projekten (u. a. R\u00fcstung) zur Anwendung kam. Bis heute ist es bei Projekten im regulierten Umfeld (z. B. Medizintechnik, Banken) in vielen K\u00f6pfen und Normen verankert. Das f\u00fchrt zu Konflikten in Teams, die agile Entwicklungsprozesse bevorzugen.<\/p>\n\n\n\n

Dieser Artikel hilft, diesen Widerspruch aufzul\u00f6sen. Sie erfahren, wie Sie die f\u00fcnf h\u00e4ufigsten Probleme vermeiden und das V-Modell richtig einsetzen.<\/p>\n\n\n\n\n\n\n\n

1. V-Modell: Die Grundlagen<\/h2>\n\n\n\n

a) Ziele des V-Modells<\/h3>\n\n\n\n

Ziel 1: Entwicklungsziele erreichen<\/h4>\n\n\n\n

Wie alle Entwicklungsprozessmodelle soll auch das V-Modell dazu beitragen, dass Entwicklungsprojekte in der geplanten Zeit und mit den geplanten Ressourcen die Ergebnisse (Produkte, Software) in der geplanten Qualit\u00e4t erreichen.<\/p>\n\n\n\n

Ziel 2: Klarheit schaffen<\/h4>\n\n\n\n

Dazu ist es notwendig, dass jede Rolle im Entwicklungsprojekt wei\u00df, welchen Input sie zu welchem Zeitpunkt mit welchen Methoden in welchen Output \u00fcberf\u00fchren muss.<\/p>\n\n\n\n

Ziel 3: Regulatorische Anforderungen erf\u00fcllen<\/h4>\n\n\n\n

In regulierten Branchen wie der Medizintechnik, im Bankenumfeld oder der Luftfahrindustrie m\u00fcssen Gesetze, Normen<\/a> und Leitlinien befolgt werden, die das Arbeiten nach dem V-Modell nahelegen.<\/p>\n\n\n\n

b) Besonderheiten des V-Modells<\/h3>\n\n\n\n

Die verschiedenen Phasen<\/h4>\n\n\n\n

Das V-Modell unterscheidet viele Entwicklungsphasen, die sich in drei Gruppen unterteilen lassen:<\/p>\n\n\n\n

    \n
  1. Planung und Spezifikation (s. Abb. 1 in blau)<\/li>\n\n\n\n
  2. Implementierung (in gr\u00fcn)<\/li>\n\n\n\n
  3. Verifizierung und Validierung<\/a> (in violett)<\/li>\n<\/ol>\n\n\n\n
    \"Die<\/a>
    Abb. 1: Die Phasen des V-Modells lassen sich in die Gruppen Planung, Implementierung und Verifizierung\/Validierung unterteilen. HW\/SW steht f\u00fcr Hardware bzw. Software.<\/figcaption><\/figure>\n\n\n\n

    Spezifikation von Tests w\u00e4hrend der Planungsphasen<\/h4>\n\n\n\n

    Das V-Modell zeichnet sich dadurch aus, dass die Verifizierung und Validierung bereits w\u00e4hrend der Planungsphasen spezifiziert werden. Anhand welcher \u201eTests\u201c entschieden wird, ob die in der Planungsphase gestellten Anforderungen erf\u00fcllt sind oder nicht, wird bereits bei der Planung festgelegt.<\/p>\n\n\n\n

    Die roten Pfeile in der Abbildung 1 repr\u00e4sentieren diese Zuordnung.<\/p>\n\n\n\n

    Die Tester pr\u00fcfen dann in den Testphasen gegen die Spezifikationen aus den Spezifikations-\/Planungsphasen.<\/p>\n\n\n\n

    c) Abgrenzung zu anderen Prozessmodellen<\/h3>\n\n\n\n

    Wasserfall-Modell<\/h4>\n\n\n\n

    Genau diese Zuordnung unterscheidet das V-Modell vom Wasserfall-Modell. Das V-Modell ist kein Wasserfall-Modell, bei dem die Verifizierungs- und Validierungsaktivit\u00e4ten in der grafischen Darstellung nur „hochgeklappt werden“.<\/p>\n\n\n\n

    In beiden Modellen ist es m\u00f6glich, bei Fehlern, die in einer Phase erkannt werden, wieder in vorherige Phasen zur\u00fcckzuspringen, um dort die Fehler zu beheben. Aber die Aktivit\u00e4ten erfolgen linear.<\/p>\n\n\n\n

    Agile Prozessmodelle<\/h4>\n\n\n\n

    Trotz aller R\u00fcckspr\u00fcnge wird das V im Rahmen des Entwicklungsprojekts nur einmal durchlaufen. Man nimmt dabei an, dass die Anforderungen zu Beginn des Projekts ausreichend, vollst\u00e4ndig und korrekt bestimmt wurden.<\/p>\n\n\n\n

    Agile Prozessmodelle machen diese Annahme nicht. Vielmehr nutzen sie ein iteratives, inkrementelles Vorgehen, um die Anforderungen schrittweise zu erheben und erf\u00fcllen. <\/p>\n\n\n\n

    <\/path><\/g><\/svg><\/div>Weiterf\u00fchrende Hinweise<\/span><\/div>\n

    Lesen Sie hier mehr zu agilen Prozessmodellen<\/a>.<\/p>\n\n\n\n

    Ein weiterer Fachartikel f\u00fchrt in das Thema Entwicklung und Entwicklungsprozessmodelle<\/a> ein.<\/p>\n<\/div>\n\n\n\n

    2. Phasen und Verantwortlichkeiten<\/h2>\n\n\n\n

    a) \u00dcberblick \u00fcber die Phasen und Aktivit\u00e4ten<\/h3>\n\n\n\n

    Diese \u00dcbersicht geht davon aus, dass das zu entwickelnde System\/Produkt aus mehreren Systemkomponenten besteht, die jeweils Hardware und Software beinhalten, welche selbst wiederum in Komponenten (z. B. Software-Komponenten<\/a>) unterteilt sind (s. Abb. 2).<\/p>\n\n\n\n

    \"Schematische<\/a>
    Abb. 2: Schematische Zeichnung eines Produkts zum Erkl\u00e4ren des V-Modells (zum Vergr\u00f6\u00dfern klicken)<\/figcaption><\/figure>\n\n\n\n
    <\/path><\/svg><\/div>Hinweis<\/span><\/div>\n

    Bei reinen Software-Produkten fallen (nach Nummerierung in Abbildung 1) die Aktivit\u00e4ten 2 und 4 sowie 9 und 13 zusammen. Zudem entfallen die Aktivit\u00e4ten 3, 4, 10 bis 12.<\/p>\n<\/div>\n\n\n\n

    b) Beschreibung der Aktivit\u00e4ten\/Phasen<\/h3>\n\n\n\n
    Nummer
    <\/strong>nach Abb. 1, 2<\/td>    		Phase(n)
    <\/strong>inklusive Links auf vertiefende Fachartikel<\/td>    		Aktivit\u00e4ten<\/strong><\/td><\/tr>
    1<\/td>Stakeholder-Anforderungen<\/a><\/td>Stakeholder-Anforderungen (z. B. Nutzungsanforderungen) erheben<\/td><\/tr>
    2<\/td>Systemanforderungen<\/a><\/td>Systemanforderungen aus den Stakeholder-Anforderungen ableiten und das System als Blackbox spezifizieren<\/td><\/tr>
    3<\/td>Systemarchitektur<\/a> und Anforderungen an Komponenten<\/td>Ableiten, welche Komponenten ben\u00f6tigt werden und welche Anforderungen diese erf\u00fcllen m\u00fcssen, um die Systemanforderungen zu erf\u00fcllen<\/td><\/tr>
    4<\/td>Komponentenarchitektur und HW- bzw. SW-Anforderungen<\/a><\/td>Die Systemkomponenten in die Gewerke (z. B. Hardware (HW) und Software-System (SW)) zerlegen und die jeweiligen Anforderungen spezifizieren, damit die Systemkomponente ihre Anforderungen erf\u00fcllt<\/td><\/tr>
    5<\/td>HW- bzw. SW-Architektur<\/a> und HW- bzw. SW-Anforderungen<\/td>Festlegen, aus welchen Komponenten (z. B. SW-Komponenten) das jeweilige Gewerk (z. B. SW-System) bestehen muss und die Anforderungen spezifizieren<\/td><\/tr>
    6<\/td>Implementierung<\/td>Die Hard- und Software-Komponenten gem\u00e4\u00df Spezifikation entwickeln<\/td><\/tr>
    7<\/td>HW\/SW-Komponententests<\/a><\/td>\u00dcberpr\u00fcfen, ob die Hardware- und Software-Komponenten gem\u00e4\u00df Spezifikation entwickelt wurden<\/td><\/tr>
    8<\/td>HW\/SW-Integrationstests<\/a><\/td>Hardware bzw. Software-Komponenten st\u00fcckweise zusammensetzen und dabei ihr korrektes Zusammenspiel pr\u00fcfen<\/td><\/tr>
    9<\/td>HW-\/SW-Subsystemtests<\/td>Das komplette Hardware- bzw. Software-System gegen die Spezifikation pr\u00fcfen
    Achtung<\/strong>: Es kann mehr als ein Hardware- bzw. Software-System pro Gesamtsystem geben (s. Abb. 2).<\/td><\/tr>
    10<\/td>Komponenten\u00adintegrationstests<\/td>Die Komponenten aus ihren Gewerken (HW, SW) st\u00fcckweise zusammensetzen und dabei ihr korrektes Zusammenspiel pr\u00fcfen<\/td><\/tr>
    11<\/td>Komponententests<\/td>Die vollst\u00e4ndigen Systemkomponenten gegen ihre Spezifikation testen<\/td><\/tr>
    12<\/td>Systemintegrationstests<\/td>Die Systemkomponenten st\u00fcckweise zusammensetzen und dabei ihr korrektes Zusammenspiel pr\u00fcfen<\/td><\/tr>
    13<\/td>Systemtests<\/td>Das vollst\u00e4ndige System gegen seine Spezifikation (Systemanforderungen) testen<\/td><\/tr>
    14<\/td>Systemvalidierung<\/a><\/td>Pr\u00fcfen, ob das System die Stakeholder-Anforderungen und die Zweckbestimmung erreicht. Usability-Tests<\/a> sind ein Beispiel f\u00fcr diese Tests.<\/td><\/tr><\/tbody><\/table>
    Tabelle 1: Phasen und Aktivit\u00e4ten im V-Modell<\/figcaption><\/figure>\n\n\n\n
    <\/path><\/g><\/svg><\/div>Weiterf\u00fchrende Informationen<\/span><\/div>\n

    Weitere Details zu den Aktivit\u00e4ten, Methoden und Konzepten erl\u00e4utern diese Fachartikel:<\/p>\n\n\n\n