infforum

V-Modell

Entwicklungsstandard für IT-Systeme des Bundes

Unternehmensberatung Know-how-Transfer zu Vorgehensmodellen - Methoden - Werkzeugen


Startseite Informatik Forum

Anforderungsanalyse

Prozess-Modellierung

Anwendungsentwicklung

Projektmanagement

V-Modell XT Diagramm Beispiele extreme tailoring Programm 97 Anforderung Schritte Verifizierung requirements engineering Übersicht Konstruktion Projektstrukturplan Entwicklungsmodell IT Schulung Prozessentwicklung Projektkennzahl Projekttyp Entwurf Produkte Ziele Plan Projektentwicklung Voruntersuchung Modelle Anforderungsanalyse inkrementell Erklärung Anleitung Anwendungsentwickler Projektmanagement Anforderungsmanagement Unterschiede V-Prozess Erfahrung Entwicklung Phasenmodelle IT Projekttypen iterative Softwareentwicklung Optimierung review Funktion Wissen Anforderungsdefinition Analyse-Phase Objekt Anwendung workflow Ablauf Projektarbeit embedded Software Validierung Projektvorgehen Funktionsmodellierung Projektdurchführungsstrategie Abbildung Life-Cycle CASE Computer Aided Software Engineering Prozessmodellierung Software-System Organisationskonzept Geschäftsprozess Ist-Zustand Pflichtenheft Phasen Entwicklungsprozess Vorgang parallel Abfolge Schaubild activity Test Consulting Information v-model software development Systemanforderung Arbeitsschritte Nutzen Lastenheft Informationssystem Erläuterung Systementwicklung Ist-Analyse Zielsetzung Risiko-Management Arbeitspaket Projektablaufplan Funktionsmodell Systemintegration Tester Ablaufplanung Situationsanalyse guide Funktionsanalyse Testkonzept diagram Leitfaden Prozessmodell IT BPM Prozessablaufdiagramm Produktentwicklung Struktur-Diagramm doku Änderungsantrag Soll-Konzept DV Fachkonzept Zusammenfassung Grobkonzept Ablaufplan IT-Projekt Rollenkonzept Bedeutung requirement management Projektmodelle

INffORUM Leistungen

Projekt-Beispiele

Kontakt zu INffORUM

Schulung Tailoring Phasenmodell Software CASE-Tool Anwendung V-Modell XT 97 lernen Diagramme Prozesse Dialog best practices Softwareentwicklung SE external Ziel Software-Entwurf Test Validierung transition requirements engineering Doku Grafik Produktentwicklung skill Risikoanalyse Konzeption Aufteilung Phase Kompetenz Berater Projektmodell development Umsetzung Experte Vorgehensweise itel model xt Aufbau systems engineering Erklärung

Ziele

Themen

SIP - Strategische Informationssystemplanung

GPM - Geschäftsprozess-Modellierung

Anforderungsanalyse Anforderungsmanagement

Vorgehensmodell

Methoden

Systemabgrenzung

PZR-Analyse

Problemanalyse / Schwachstellenanalyse

Zielanalyse

Restriktionsanalyse

Affinitätsanalyse

Durchführbarkeitsanalyse / Wirtschaftlichkeitsanalyse

Werkzeuge Requirements Engineering

objectiF RPM

Anwendungsentwicklung

Vorgehensmodelle

Wasserfall-Modell

Spiral-Modell

V-Modell

Evolutionäre / inkrementelle Vorgehen

RUP - Rational Unified Process

Agile Softwareentwicklung

Agile Softwareentwicklung

Methoden

Methode SA - Strukturierte Analyse

Methode ESA - Essentielle System-Analyse

Methode SD - Strukturiertes Design

Methode ERM - Entity-Relationship-Modellierung

Methode RM - Relationen-Modellierung

Methode UML - Unified Modeling Language

Werkzeuge Software Engineering

case/4/0

Innovator

objectiF

Projekt-Management

Vorgehensmodell

Projektstrukturplanung

Aktivitätenplanung

Arbeitsplanung

Kapazitätsplanung / Ressourcenplanung

Change-Management

Konfigurations-Management

Methoden/Techniken

Netzplan-Technik

Balkenplan-Technik

Meilenstein-Trend-Analyse

Methoden Aufwandsschätzung

Methode NuWA - Nutzwertanalyse

Werkzeuge Projekt-Management

in-STEP BLUE

Primavera

Übersicht Leistungen

Organisationskonzepte

Studien, Gutachten

Auswahl Requirements Engineering (CARE) Tool

Auswahl Software Engineering (CASE) Tool

Auswahl Projekt-Management (PM) Tool

Projektleitung

Coaching IT-Projektleiter

Know-how-Transfer Projekte

Beratung und Unterstützung

Software Einsatz case/4/0

Software Einsatz Innovator

Software Einsatz ObjectiF

Projektbeispiele

Informationssystem-Planung

IV-Rahmenplanung Museum

Kommunikationsanalyse Versicherung

Organisation

ORG-BW-Gesamtmodell

Prozessmodellierung und Ablauf-Organisation Rating

Versionierung in der Logistik

Know-how-Transfer Software-Entwicklung

Vorgehensmodell Analyse
mit Einsatz case/4/0

Vorgehensmodell mit Word-Dokumentation

Werkzeug-Einführung Innovator

Simulation Tour de France (mit Download)

Cockpit - Steuerung der Simulation

Mitarbeiter-Profil

Kontakt

Impressum

Unsere Kompetenz

V-Modell

Das V-Modell ist ein in vielen Bereichen verbindlicher Standard für Informatik-Projekte, dessen Definition und Weiterentwicklung das BMVg und das BMI forcieren (Entwicklungs-Standard für IT-Systeme des Bundes - EStdIT). Das Vorgehen hat als Zielsetzung, ein Höchstmaß an Qualität beim zu erstellenden Produkt zu erreichen. Basis für das V-Modell sind Entwicklungen von Barry Boehm aus dem Jahr 1979.

Das V-Modell (auch V-Model) regelt die Gesamtheit aller Aktivitäten und Produkte für IT-Systementwicklungsprozesse. Das V-Modell bietet neben dem Arbeitsplan auch eine Definition der Produktzustände und zeigt die logischen Abhängigkeiten zwischen Aktivitäten und Produkten.
 

Aktivität ist eine Tätigkeit, die hinsichtlich ihrer Durchführung und ihres Ergebnisses genau beschrieben werden kann. Aktivitäten werden zu Hauptaktivitäten zusammengefasst und in Teilaktivitäten zergliedert.

Produkt ist die Bearbeitungseinheit bzw. das Ergebnis einer Aktivität. Das Produkt kann in Teilprodukte strukturiert werden.


Eine Aktivität im Vorgehensmodell kann sich auf die Erstellung eines Produkts, die Änderung des Zustands eines Produkts oder die inhaltliche Änderung eines Produkts beziehen.
Zu jeder Aktivität im Aktivitätenplan und zu jedem Produkt in der Produktstruktur existieren im V-Modell die Definition einer Aktivitäten-Beschreibung bzw. die Definition einer Produkt-Beschreibung.
Die Aktivitätenbeschreibung dient als Arbeitsanleitung für das Projekt-Vorgehen;
die Produktbeschreibung skizziert ein Muster (Template) für das zu erstellende Ergebnis und damit auch die Dokumentation.

Produkte können im Prozess, zum Beispiel der Softwareentwicklung, verschiedene Bearbeitungszustände durchlaufen. Ein Zustandsübergang wird durch eine Aktivität im Vorgehensmodell ausgelöst. Ein Produkt kann in einem der folgenden Zustände sein

  • geplant,
    Startzustand für alle Produkte;

  • in Bearbeitung,
    das Produkt befindet sich unter der Kontrolle der Entwickler;

  • vorgelegt,
    das Produkt ist aus der Sicht des Entwicklers fertig und wird in die Konfigurationsverwaltung eingestellt;

  • akzeptiert,
    das Produkt wurde durch die Qualitätssicherung im Projekt geprüft und freigegeben.

Für jede Aktivität wird der Produktfluss aller beteiligten Produkte im V-Modell mit ihren Eingangs- und Ausgangszuständen definiert.

Im V-Modell sind drei Ebenen festgelegt:

weiterführende
externe Links

KBSt - Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung

  • Die Ebene der Vorgehensweise bestimmt, welche Aufgaben während der Phasen der Systementwicklung durchzuführen sind und welche Ergebnistypen mit welchem Inhalt dabei produziert werden.

  • Die Ebene der Methode legt fest, mit welchen Verfahren die auf der Ebene der Vorgehensweise festgelegten Aktivitäten durchzuführen sind und welche Mittel der Darstellung für die Ergebnistypen verwendet werden.

  • Die Ebene der Anforderungen beschreibt, welche funktionalen Eigenschaften die Werkzeuge aufweisen müssen, die bei der Anwendungsentwicklung eingesetzt werden sollen.


Auf allen Ebenen im Vorgehensmodell werden die Regelungen nach den Tätigkeitsbereichen gegliedert. Die im V-Modell 97 als "Submodell" bezeichneten Einheiten sind:

  • Projektmanagement (PM),

  • Systemerstellung (SE),

  • Qualitätssicherung (QS) und

  • Konfigurationsmanagement (KM)

In jedem Submodell sind Beziehungen zwischen Aktivitäten und Produkten wie oben beschrieben geregelt. Zusätzlich ist im V-Modell auch die Definition der Zuordnung von Rollen für ein Projekt vorgegeben.

Das V-Modell unterscheidet sich von den zuvor beschriebenen klassischen Ausprägungen der Phasenmodelle der Anwendungsentwicklung (Wasserfallmodell, Spiralmodell) durch die Einbeziehung der Qualitätssicherung. Die Sicherung der Qualität erfolgt über die Zuordnung von Aktivitäten der Validierung und der Verifikation zu den Aktivitäten der Konstruktion im Prozess. Die Validierung stellt die Überprüfung der Nützlichkeit dar; mit der Verifikation wird eine Überprüfung der Übereinstimmung mit den Vorgaben vorgenommen.
Durch die starke Betonung der Sicherstellung von Qualität als eigenes Submodell werden Fehler (durch Verifikation) und überflüssige Eigenschaften (durch Validierung) im V-Modell meist frühzeitiger als im Arbeitsablauf nach dem Wasserfallmodell oder dem Spiralmodell aufgedeckt und damit Kosten im Projekt minimiert. Auch die Abnahme durch einen Auftraggeber wird vereinfacht.


Produktfluss im V-Modell 97

Ablauf der Phasen und Produktfluss im V-Modell 97
 

In der neuen V-Modell Version XT wird im Unterschied zum V-Modell 97 das Produkt noch weiter in eine zentrale Position gerückt. Dies zeigt sich am deutlichsten in der Zuordnung der Rolle zum Produkt und nicht mehr zur Aktivität.
Weitere Veränderungen der Version XT liegen in der verbesserten Skalierbarkeit sowie der Unterstützung der Änderbarkeit und der Erweiterbarkeit im Vergleich zum V-Modell 97.



KBSt: V-Modell Version XT Release 1.3

Gesamtstruktur V-Modell XT  

Grafik Gesamtstruktur des V-Modell XT
 

Neu eingeführt sind Vorgehensbausteine (siehe nachfolgende Grafik), die einen modularen Aufbau für das V-Model XT bedeuten. Ein Vorgehensbaustein kapselt Rollen, Aktivitäten und Produkte zu einer Einheit, die weitgehend eigenständig verwendbar ist und unabhängig von Beziehungen zu anderen Einheiten verändert werden kann.

V-Modell XT Metastruktur Vorgehensbaustein

Metastruktur Vorgehensbaustein mit Rolle, Produktstruktur und Aktivitätenstruktur

Vorgehensbausteine setzen teilweise aufeinander auf. So ist zum Beispiel bei der "Evaluierung von Fertigprodukten" auch der Baustein "Anforderungsfestlegung" erforderlich. Die Vorgehensbausteine "Projektmanagement", "Problem- und Änderungsmanagement", "Konfigurationsmanagement" und "Qualitätssicherung" sind bei jeder Form der Nutzung unverzichtbar.

Ebenfalls neu sind Projekt-Durchführungsstrategien (zum Beispiel "Inkrementelle Systementwicklung", "Wartung und Pflege", ...), die Entscheidungspunkte (= Meilenstein in der Projektabwicklung) im Projektvorgehen und die zum Entscheidungspunkt fertig zustellenden Produkte zusammenfassen. Die Projektdurchführungsstrategie und die Entscheidungspunkte (zum Beispiel: "Projekt genehmigt", "Projekt definiert", "Iteration geplant") bestimmen die Struktur und den Ablauf der Projekte.

In der Version V-Modell XT 1.2 werden in den Durchführungsstrategien Iterationen möglich gemacht, die auch zwischen dem Auftraggeber- und dem Auftragnehmer-Projekt abgestimmt werden können. Weiterhin ist im Auftraggeber-Projekt Schritte für die Vergabe von Unteraufträgen vorgesehen.

Das V-Modell XT ist für Auftragnehmer-Projekte ebenso geeignet wie für Auftraggeber-Projekte sowie rein organisatorische Projekte. Neu hinzugekommen ist in der Version V-Modell XT 1.2 der Projekttyp "Systementwicklung AG/AN", der die Vorgehensbausteine von Auftraggeber und Auftragnehmer in einer Organisation, unter einem gemeinsamen Projektleiter zusammenfasst.
Für Auftraggeber-Projekte ist eine Komponente "Multiprojekt-Management" vorgesehen.

Die Auswahl eines dieser Projekttypen stellt den ersten wesentlichen Schritt im Tailoring, der Anpassung des allgemeingültigen Vorgehens an ein konkretes Projekt dar. Abhängig von den nachfolgenden Projektmerkmalen werden eine Projektdurchführungsstrategie und damit die Vorgehensbausteine (Produkte, Rollen, Aktivitäten) zusammengestellt.

  • Projektgegenstand (Software-, Hardware-, Embedded System, ...),

  • Projektrolle (Auftraggeber, Auftragnehmer, beide Rollen),

  • Systemlebenszyklus-Ausschnitt (Entwicklung, Pflege und Wartung, ...),

  • Kaufmännisches Projektmanagement (Planung/Verfolgung: ja/nein),

  • Quantitative Projektkennzahlen (Ermittlung: ja/nein),

  • Fertigprodukte (Evaluierung/Einsatz: ja/nein),

  • Benutzerschnittstelle (Erfolgskriterium: ja/nein),

  • Safety und Security (Kritikalität: ja/nein),

  • Hohe technologische Risiken (Realisierungsrisiken: ja/nein).

Somit können Entwicklungsstrategien, wie inkrementelle Entwicklung, komponentenbasierte Entwicklung oder prototypische Entwicklung, nach jedem Entscheidungspunkt neu festgelegt werden.

Auf diese Weise werden viele Aktivitäten, Rollen und Produkte im Tailoring ausgefiltert und können so auch zu einem schlanken Vorgehen für ein Projekt führen.

Das Tailoring kann auch bedeuten, dass Projekt-spezifische Aktivitäten oder Meilensteine (Entscheidungspunkte) hinzugefügt werden. Das "XT" in der Bezeichnung "V-Model XT" steht hier zu Recht für Extreme Tailoring.

Die Komplexität des Gesamt-Modells macht ein Unternehmens- und ein Projekt-spezifisches Tailoring erforderlich. Das Tailoring in der Prozessentwicklung wird mit der neuen V-Modell XT Version über die Erstellung der Anwendungsprofile gesteuert und ist auch dynamisch während der Projektlaufzeit möglich.

Der erste Schritt im Tailoring des V-Modell XT ist die Entscheidung zwischen Auftraggeber-Projekt und Auftragnehmer-Projekt. Im Weiteren hat die Bestimmung der Projektmerkmale wesentlichen Einfluss auf die Zahl der zu erstellenden Produkttypen. Dabei ergeben die verpflichtenden Vorgehensbausteine zusammen 22 Produkttypen.

Vorgehen Tailoring am Beispiel: AN-Projekt mit Entwicklung

Abhängig vom Anwendungsprofil und von der gewählten Durchführungsstrategie werden ca. 25 bis 75 Produkttypen ausgewählt und im Prozess unter Nutzung der Muster (Templates) zu erstellen sein.
Das Tailoring des V-Modell XT wird durch ein geeignetes Werkzeug (als Beispiele: Projektassistent, in-STEP BLUE) weiter vereinfacht. Die Werkzeuge bieten auch geeignete Vorlagen für die Produkte.

Das V-Modell XT kann wesentlich zur Steigerung der Produkt-Qualität, zur Einhaltung der Termine und zur Senkung der Kosten beitragen. Dabei ist es sowohl für kleine und mittlere, als auch für große Projekte geeignet.



Download V-Modell XT Projektassistent

Download microTOOL in-STEP BLUE

INffORUM unterstützt die Einführung, Anpassung und Nutzung des V-Modell als Vorgehensmodell für die Anwendungsentwicklung im Unternehmen sowie den zugehörigen Know-how-Transfer für das Arbeiten mit dem Vorgehensmodell in Form von Schulung (Seminar, Workshop, Tutorial) und Coaching. Das Training zum V-Model XT, sowohl Seminar als auch Workshop und Tutorial kann dabei auf den speziellen Bedarf einer Projekt-Gruppe zugeschnittenen werden.

Profitieren Sie in Ihrem IT-Projekt von den langjährigen Erfahrungen der INffORUM Berater.