 |
 |
 |
|
| 2. Einführung in das V-Modell |
2 Einführung in das V-Modell
Das V-Modell regelt die Gesamtheit aller
Aktivitäten und Produkten
sowie
Produktzustände und logischen Abhängigkeiten zwischen Aktivitäten und Produkten
during the IT system development process and the maintenance and modification of IT systems.
Das V-Modell ist in vier Submodelle gegliedert.
Das V-Modell beschreibt den Entwicklungsprozeß aus funktionaler Sicht. Es geht nicht auf spezielle Organisationsformen ein, da es in unterschiedlichsten Einrichtungen/Firmen zum Einsatz kommen soll. Für die Durchführung eines Projekts müssen daher für die im V-Modell dargestellten Aufgaben ("Aktivitäten") Bearbeiter bzw. Organisationseinheiten festgelegt werden.
Diese Einführung in das V-Modell stellt dar, welche Grundkonzepte und Beschreibungsmittel für das V-Modell verwendet werden.
2.1 Erzeugnisstruktur und Einbettung in das organisatorische Umfeld
Das V-Modell beschreibt die Entwicklung von IT-Systemen, deren Aufgabenerfüllung vorwiegend durch den Einsatz von IT realisiert wird. Das "System" ist in diesem Sinne eine Funktionseinheit der obersten Ebene aus der Sicht des V-Modells.
Die Erzeugnisstruktur des V-Modells definiert, aus welchen generischen Bausteinen ein zu entwickelndes System grundsätzlich besteht.
Die Systemarchitektur beschreibt den statischen Aufbau eines Systems als vernetzte Struktur mit den Elementen der generischen Erzeugnisstruktur. Dynamische Aspekte des Systems werden über die Beschreibung der Funktionsweise und dem Zusammenwirken der Elemente der Erzeugnisstruktur über deren Schnittstellen dargestellt.
Im folgenden wird beschrieben, aus welchen Bestandteilen sich ein "System" im Sinne des V-Modells zusammensetzt (siehe Abbildung 2.1: Erzeugnisstruktur und Anwendungsbereich des V-Modells).
Ein System gliedert sich in Segmente, die unterschieden werden in solche mit IT-Anteilen (Segmente mit IT-Anteil) und solche ohne IT-Anteile (Segmente ohne IT-Anteil). Segmente können ihrerseits wieder aus mehreren Segmenten zusammengesetzt sein.
Segmente werden weiter in SW-Einheiten und HW-Einheiten gegliedert.
Systeme können sich auch direkt in SW-Einheiten und HW-Einheiten gliedern. Es ist auch der Fall möglich, daß sich ein System sowohl in Segmente als auch direkt in SW-Einheiten/HW-Einheiten gliedert.
SW-Einheiten (z. B. Lademodule) und HW-Einheiten (z. B. Baugruppen oder kleinere Geräte) stellen aus der Sicht der Systemarchitektur elementare Objekte dar. Die Entwicklung von SW-Einheiten wird durch den Regelungsteil des V-Modells abgedeckt; die Entwicklung der HW-Einheiten wird in Hardwareerstellung von Teil 3 - Handbuchsammlung behandelt.
SW-Einheiten bestehen aus SW-Komponenten, wobei SW-Komponenten entweder selbst wieder aus SW-Komponenten niedrigerer Ordnung, SW-Modulen und/oder Datenbanken zusammengesetzt sein können. SW-Komponenten sind abgeschlossene Softwareeinheiten einer höheren Ebene. SW-Module sind die kleinsten zu programmierenden Softwarebausteine einer SW-Einheit. Datenbanken dienen der Beschreibung, Speicherung und Wiedergewinnung von Daten.
HW-Einheiten bestehen aus HW-Komponenten, wobei HW-Komponenten entweder selbst wieder aus HW-Komponenten und/oder HW-Modulen zusammengesetzt sein können. HW-Module sind die kleinsten Bausteine einer HW-Einheit.
Abbildung 2.1 zeigt die hierarchisch gegliederte Erzeugnisstruktur des Systems. Außerdem ist gekennzeichnet, welche Entwicklungstätigkeiten durch das V-Modell geregelt sind.
Abbildung 2.1: Erzeugnisstruktur und Anwendungsbereich des V-Modells
2.2 Randbedingungen zur IT-Systemerstellung
Abbildung 2.2: Randbedingungen zur IT-Systemerstellung zeigt schematisch die (Haupt-) Aktivitäten bei einer IT-Systemerstellung.
Abbildung 2.2 zeigt schematisch die (Haupt-) Aktivitäten bei einer IT-Systemerstellung. Falls die Entwicklung von Hardware-Anteilen berücksichtigt werden muß, muß die Softwareentwicklung in enger Verzahnung mit der Hardwareentwicklung vorgenommen werden(1), bzw. die Software muß unter ständiger Berücksichtigung der ausgewählten Hardware und ihrer Eigenschaften realisiert werden. Nur unter dieser Voraussetzung kann die Erfüllbarkeit der Anwenderforderungen über den gesamten Entwicklungsprozeß hinweg kontrolliert und gewährleistet werden. Abbildung 2.2 deutet die Bezüge zu den Nicht-IT-Anteilen des Systems während des IT-Systemerstellungsprozesses an.
Aber auch wenn die Entwicklung spezifischer Hardware nicht Gegenstand des Projektes ist, so müssen doch in jedem Fall Hardware und Software den vorgegebenen technischen Rahmenbedingungen entsprechen und in das organisatorische Umfeld eingepaßt werden. Das V-Modell hat somit alle Anteile eines zu entwickelnden Systems, soweit sie einen Einfluß auf den IT-Systemerstellungsprozeß haben, zu berücksichtigen. Es kann unter allen in der Bundesverwaltung vorhandenen technischen Rahmenbedingungen und in jedem organisatorischen Umfeld angewendet werden.(2)
Die Reihenfolge der Aktivitäten in Abbildung 2.2 erscheint sequentiell. Dies entspricht der Vorstellung vom IT-Systemerstellungsprozeß als einem strengen Top-down-Vorgehen. In der Regel sind jedoch Iterationen im Erstellungsprozeß üblich (siehe Abschnitt 3: Algemeine Regelungen). Abbildung 2.2 zeigt eine schematisierte linearisierte Darstellung des logischen Ablaufs der IT-Systemerstellung und deren Einbettung in das organisatorische Umfeld.
Abbildung 2.2: Randbedingungen zur IT-Systemerstellung
2.3 Inhalt und Darstellungsmittel
Die Grundelemente des V-Modells sind die Aktivitäten und Produkte, die während des IT-Systementwicklungsprozesses durchgeführt bzw. bearbeitet werden.
2.3.1 Aktivitäten und Produkte
Als Aktivität wird eine Tätigkeit im Rahmen des IT-Systementwicklungsprozesses bezeichnet, die hinsichtlich ihres Ergebnisses und ihrer Durchführung genau beschrieben werden kann. Aktivitäten können aus einer Reihe festgelegter "Teilaktivitäten" bestehen, wenn jede dieser Teilaktivitäten ihrerseits definierte "Zwischenergebnisse" aufweist. Die Aktivitäten der obersten Detaillierungsebene werden "Hauptaktivitäten" genannt.Als Produkt wird der Bearbeitungsgegenstand bzw. das Ergebnis einer Aktivität bezeichnet. Analog der Zerlegung von Aktivitäten in Teilaktivitäten kann sich die Zerlegung von Produkten in "Teilprodukte" (z. B. einzelne Kapitel eines Dokuments) ergeben.
Eine Aktivität kann
- die Erstellung eines Produkts,
- eine Zustandsänderung eines Produkts oder
- die inhaltliche Änderung eines Produkts
Diese Grundelemente "Aktivität" und "Produkt" werden durch spezielle Symbole repräsentiert (siehe Abbildung 2.3: Symbole für Aktivitäten und Produkte).
Abbildung 2.3: Symbole für Aktivitäten und Produkte
Zu jeder Aktivität existiert eine Aktivitätenbeschreibung als Arbeitsanleitung, der bei der Ausführung der Aktivität zu folgen ist. Die Aktivitätenbeschreibung erfolgt nach einem festen Muster, dem Aktivitätenschema (siehe Abschnitt 2.3.3 Aktivitätenschema). Falls eine Aktivität in Teilaktivitäten zerlegt wird und logische Abhängigkeiten zwischen Teilaktivitäten und Produkten herausgestellt werden müssen, enthält das Aktivitätenschema zusätzlich eine grafische Darstellung der Teilaktivitäten.
Zu jedem Produkt existiert eine Produktbeschreibung, welche die Inhalte des Produkts definiert. Die Produktbeschreibung erfolgt nach einem festen Muster, dem Produktmuster (siehe Abschnitt 2.3.4 Product Schema).
2.3.2 Produktzustände
Bei der Behandlung von (Teil-) Produkten im V-Modell ist zu berücksichtigen, daß gewisse Produkte im Entwicklungsprozeß verschiedene Zustände durchlaufen.Der Wechsel von einem Zustand in einen anderen wird grundsätzlich durch eine Aktivität ausgelöst. Alle Zustandsübergänge werden bei den entsprechenden Aktivitäten selbst angegeben (siehe Abschnitt 2.3.3 Aktivitätenschema).
Products may take on the following states:
- "geplant"
Das Produkt ist in der Planung vorgesehen. Dies ist der Eingangszustand für alle Produkte. - "in Bearb."
Das Produkt wird bearbeitet. Es befindet sich entweder im "privaten" Entwicklungsbereich des Entwicklers oder unter Kontrolle des Entwicklers innerhalb der Produktbibliothek. - "vorgelegt"
Das Produkt ist aus der Sicht des Erstellers fertig und wird unter Konfigurationsverwaltung genommen. Es wird einer QS-Prüfung unterzogen. Wird das Produkt in QS abgelehnt, so geht es wieder in den Zustand "in Bearb." zurück, andernfalls rückt es in den Zustand "akzeptiert" vor. Vom Zustand "vorgelegt" ab kann der Ersteller nur unter Fortschreibung der Versionsangabe Modifikationen durchführen. - "akzeptiert"
Das Produkt wurde in QS überprüft und freigegeben und darf nur mehr innerhalb einer neuen Version geändert werden.
Abbildung 2.4: Zulässige Zustandsübergänge von Produkten
2.3.3 Aktivitätenschema
Eine Aktivität wird nach folgendem Muster beschrieben:Name of the activity
Product Flow
Handling
2.3.3.1 Abschnitt "Produktfluß"
Hier werden alle Produkte oder Teilprodukte, die in die (Teil-) Aktivität eingehen oder von ihr modifiziert oder neu erstellt werden, aufgelistet und ihre Behandlung beschrieben. Das geschieht in Form einer Tabelle (siehe (see Tabelle 2.1: Muster eines Produktflusses (Aktivität SE2.4 - Anwenderforderungen zuordnen), die entsprechend ausgefüllt wird. Teilprodukte werden in Punktnotation dargestellt. So bedeutet z. B., "Systemarchitektur.Anforderungszuordnung" daß Anforderungszuordnung ein Teilprodukt des Produkts Systemarchitektur" ist.| Von | Produkt | nach | |||
|---|---|---|---|---|---|
| Aktivität | Zustand | Kapitel | Titel | Activität | Zustand |
| SE 1 | akzeptiert | Existierend | Anwenderforderungen | - | - |
| SE 2.1 | in Bearb. | Existierend | Systemarchitektur | - | - |
| - | - | 2.1.3 | Systemarchitektur. Anforderungszuordnung |
SE 1 (1) SE 2.5 SE 2.6 SE 3 SE 4-SW PM 4 PM 5 |
vorgelegt |
Zu jedem (Teil-) Produkt (Spalte 3), das durch die zu beschreibende Aktivität betroffen ist, wird der Zustand zu Beginn der Aktivität (Spalte 2) und der Zustand nach Beendigung der Aktivität (Spalte 5) angegeben. Hat die Aktivität keinen Einfluß auf den Produktzustand oder existiert kein Produktzustand, so ist dies in der Tabelle durch einen Strich angegeben. Eingangsprodukte einer Aktivität sind dadurch kenntlich gemacht, daß die Spalten "von Aktivität" und "von Zustand" ausgefüllt sind, die "nach Aktivität" und der "nach Zustand" sind mit Strich versehen. Bei Ausgangsprodukten entfallen die "von"-Einträge. Es sind nur die "nach Aktivität" und der "nach Zustand" vermerkt. Hat ein Produkt sowohl "von"- als auch "nach"-Einträge, so bedeutet das, daß es in der betreffenden Aktivität modifiziert wird.
Alle in der Aktivität neu erstellten Ausgangsprodukte, deren Ausgangszustand "in Bearb." ist, müßten modellgemäß den Eingangszustand "geplant" haben. Um jedoch Ein- und Ausgangsprodukte optisch besser unterscheiden zu können, ist der Eingangszustand durch "-" ersetzt. Dies ist in diesen Fällen als Zustand "geplant" zu interpretieren. (3)
Weiter wird zu jedem (Teil-) Produkt vermerkt, von welcher Aktivität das Produkt kommt (Spalte 1) und an welche Aktivität das Produkt weitergegeben wird (Spalte 4). Gibt es zu einem (Teil-) Produkt keine "von"- oder "nach"-Aktivität, so ist dies in der Tabelle durch einen Strich angegeben.
Entstehen Teilprodukte eines Produkts in unterschiedlichen (Teil-) Aktivitäten (siehe z. B. Aktivität QS 2.2 "Prüfumgebung definieren"), ergibt sich die Notwendigkeit, das Produkt durch Integration der Teilprodukte zusammenzustellen. Dies erfolgt in der Aktivität, in der das zuletzt entstehende Teilprodukt eines Produkts erstellt wird. Im Produktfluß wird dies dadurch zum Ausdruck gebracht, daß in der Spalte "nach Aktivität" auf nachfolgende Hauptaktivitäten verwiesen wird. Bei Produkten, die nicht weiter fortgeschrieben werden, wird in der Spalte "nach Zustand" der Zustand "vorgelegt" zugeordnet.
Das Beispiel in Tabelle 2.1 ist so zu verstehen, daß die Anwenderforderungen und die Systemarchitektur von den Aktivitäten SE 1 bzw. SE 2.1 kommen und Eingangsprodukte darstellen. Die Anwenderforderungen liegen im Zustand "akzeptiert" und die Systemarchitektur im Zustand "in Bearb." vor. Neu erstellt wird das Teilprodukt "Anforderungszuordnung" des Produkts "Systemarchitektur". Das Produkt verläßt die Aktivität im Zustand "vorgelegt" und ist Eingangsprodukt für die Aktivitäten SE 1, SE 2.5, SE 2.6, SE 3, SE 4-SW, PM 4 und PM 5.
Maßnahmen zur Qualitätssicherung und zum Konfigurationsmanagement werden indirekt durch die Zustandsänderungen angedeutet.
2.3.3.2 Abschnitt "Abwicklung"
Hier ist verbindlich festgelegt, wie bei der Durchführung der Aktivität vorzugehen ist.Bei einer Hauptaktivität sind zu Beginn des Abwicklungstextes ihre Teilaktivitäten, deren Abhängigkeiten untereinander sowie deren Ergebnisse grafisch dargestellt.
Dabei gilt folgende Festlegung: Ist zu Teilaktivitäten kein Ergebnisprodukt angegeben, so bedeutet dies, daß in mehreren in der Abbildung aufeinanderfolgenden Teilaktivitäten an Teilen eines gemeinsamen Produktes gearbeitet wird.
2.3.3.3 Empfehlungen und Erläuterungen
In Ergänzung zu den Abwicklungstexten können Unterabschnitte "Empfehlung" und "Erläuterung" gegeben werden. Im Gegensatz zur oben angeführten verbindlichen Festlegung sind die ausgesprochenen Empfehlungen nicht bindend. Die Erläuterungen sollen die Aufgabenstellung und die Abwicklung der Aktivität verdeutlichen.2.3.4 Produktmuster
Im Rahmen des Produktmusters wird für jedes Produkt eine kurze Zusammenfassung des Produktinhaltes und im allgemeinen eine Auflistung der inhaltlichen Gliederungspunkte des Produktes angegeben. Anforderungen an das Layout werden im Rahmen des V-Modells nicht gestellt.Eine genaue Beachtung der Feingliederung läßt sich bei Verwendung von Werkzeugen zur Produktgenerierung nicht immer garantieren. In diesem Fall muß die Feinstrukturierung der betroffenen Dokumente von Fall zu Fall ausdrücklich vereinbart werden. Dabei ist die Abdeckung der erforderlichen Inhalte nachzuweisen.
2.3.5 Submodelle
Innerhalb des V-Modells werden gewisse Aktivitäten zusammengefaßt, weil sie jeweils aus einer bestimmten Sicht ein in sich abgeschlossenes Modell repräsentieren. Ein derartiges "Modell" wird als Submodell bezeichnet.Folgende vier Submodelle bilden das V-Modell:
Abbildung 2.5: Zusammenspiel der Submodelle zeigt das Zusammenspiel der Submodelle. Abbildung 2.6: Produkte des V-Modells (Produktbaum) zeigt, wie die Produkte der vier Submodelle SE, QS, KM und PM in die hierarchische Erzeugnisstruktur einzuordnen sind.Eine zusammenfassende Auflistung aller Aktivitäten eines Submodells findet sich jeweils am Ende des Abschnitts, in dem das Submodell beschrieben wird (d. h. Abschnitt 4 bis 7).
Abbildung 2.5: Abbildung 2.5: Zusammenspiel der Submodelle
Abbildung 2.6: Abbildung 2.6: Produkte des V-Modells (Produktbaum)
Notes: (1) Siehe Abschnitt 3.4 und Teil 3 - Handbuchsammlung, Handbuch Hardwareerstellung.
(2) Anleitung zur Berücksichtigung des organisatorischen Umfeldes bei der Planung von IT-Systemen in der Bundesverwaltung finden sich in der /IT-Org/ and /IT-RaKonz/. Eine gesonderte Betrachtung dieser Gesichtspunkte finder daher im folgenden nicht mehr statt.
(3) In einigen Fällen wird in Submodell KM von dieser Regel abgewichen, wenn das betroffene Produkt inhaltlich nicht bearbeitet wird.
|
|
|
GDPA Online
Last Updated 01.Jan.2002
Updated by Webmaster
Last Revised 01.Jan.2002
Revised by Webmaster
|