V-Modell
Entwicklungsstandard für IT-Systeme des Bundes
Unternehmensberatung Know-how-Transfer zu Vorgehensmodellen - Methoden - Werkzeugen
|
| V-ModellEntwicklungsstandard für IT-Systeme des Bundes | Unternehmensberatung Know-how-Transfer zu Vorgehensmodellen - Methoden - Werkzeugen |
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 | 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 |
|
SIP - Strategische Informationssystemplanung GPM - Geschäftsprozess-Modellierung Anforderungsanalyse Anforderungsmanagement Problemanalyse / Schwachstellenanalyse Durchführbarkeitsanalyse / Wirtschaftlichkeitsanalyse Werkzeuge Requirements Engineering V-Modell Evolutionäre / inkrementelle Vorgehen RUP - Rational Unified Process 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 Kapazitätsplanung / Ressourcenplanung Methode NuWA - Nutzwertanalyse Auswahl Requirements Engineering (CARE) Tool Auswahl Software Engineering (CASE) Tool Auswahl Projekt-Management (PM) Tool Informationssystem-Planung Kommunikationsanalyse Versicherung Organisation Prozessmodellierung und Ablauf-Organisation Rating Know-how-Transfer Software-Entwicklung Vorgehensmodell Analyse Vorgehensmodell mit Word-Dokumentation Simulation Tour de France (mit Download) |
Unsere KompetenzV-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.
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
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 | |||
| ||||
Auf allen Ebenen im Vorgehensmodell werden die Regelungen nach den Tätigkeitsbereichen gegliedert. Die im V-Modell 97 als "Submodell" bezeichneten Einheiten sind:
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. | ||||
 | ||||
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.
| ||||
| ||||
|
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. | ||||
 | ||||
Metastruktur Vorgehensbaustein mit Rolle, Produktstruktur und Aktivitätenstruktur 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. 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.
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. | ||||
|
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 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. | ||||
Copyright © 2005 - 2018 | 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. | |||