Previous Next V-Model Official Homepage by IABG  
3 Allgemeine Regelungen  

  3 General Regulations

Contents  
  • 3.1 Projektspezifisches V-Modell und Tailoring
  • 3.2 Projektorganisation und Rollen
  • 3.3 Anwendung der Szenarien
  • 3.4 Operative Module
  • 3.5 Behandlung fortzuschreibender Produkte
  • 3.1 Projektspezifisches V-Modell und Tailoring

    Die in den Submodellen beschriebenen Aktivitäten und Produkte sind für die Verwendung sowohl in kleinen als auch großen IT-Systementwicklungsprojekten bzw. Pflege- und Änderungsprojekten vorgesehen. Entsprechend dem Entwicklungsgegenstand, dessen Anforderungen an Funktionalität, an Komplexität der Funktionen und Daten und an die Qualitätsmerkmale, wie z. B. Wartbarkeit, sind im konkreten Projekt das Vorhandensein eines (Teil-) Produkts und die Durchführung einer (Teil-) Aktivität festzulegen. Produkte und Aktivitäten können in einem bestimmten Projekt gegenüber dem generischen V-Modell wegfallen. Das Ergebnis dieses Planungsschritts wird "projektspezifisches V-Modell" genannt.

    Die Festlegung des projektspezifischen V-Modells wird durch zwei Anpassungsschritte unterstützt:

    Die Funktionsweise des Ausschreibungsrelevanten und Technischen Tailoring ist näher in Teil 3 - Handbuchsammlung (Handbuch Tailoring und projektspezifisches V-Modell) beschrieben. Weiterhin sind dort Beispiele für mögliche Streichbedingungen sowie verschiedene zugeschnittene Vorhabentypen angegeben.

    3.2 Projektorganisation und Rollen

    Die Einsatzplanung von Projektmitarbeitern, d. h. die Zuordnung von Aufgaben zu den einzelnen Mitarbeitern des Projekts, erfolgt über Rollen. Das V-Modell nennt für jedes Submodell eine Menge von Rollen, deren Rolleninhaber entsprechend fest definierter Rollen/Aktivitäten-Zuordnungen Aktivitäten bearbeiten. Es werden verschiedene Bearbeitungstypen unterschieden: "verantwortlich (im Sinne der Ausführung)", "mitwirkend" und "beratend". Zu jeder Rolle sind Kenntnisse und Fähigkeiten genannt, die für die Bearbeitung der zugeordneten Aktivitäten gefordert werden.

    Bei der Einsatzplanung erfolgt nun die Festlegung der Mitarbeiter oder anderer Organisationseinheiten zu den Aktivitäten über die Rollendefinitionen. Eine Rolle kann von einem oder mehreren Mitarbeitern eingenommen werden. Der Mitarbeiter hat die Kenntnisse und Fähigkeiten der Rolle zu besitzen und kann dann für die Bearbeitung der Aktivitäten, die der Rolle zugeordnet sind, entsprechend den Beteiligungstypen eingeplant werden. Eine Person kann z. B. bei kleineren Projekten mehrere Rollen innehaben, wobei jedoch gewisse Regeln einzuhalten sind. So darf kein Entwickler seine Ergebnisse im Rahmen der QS selbst prüfen.

    Durch dieses Rollenkonzept bleibt das V-Modell organisationsneutral. Eine generelle Zuordnung der in einer Organisation existierenden Stellen zu Rollen erleichtert zwar die Organisation in jedem Einzelprojekt und wird daher empfohlen. Sie wird jedoch durch das V-Modell nicht vorgeschrieben.

    Eine erfolgreiche Entwicklung verlangt, daß die nachstehenden Abstimmprozesse geregelt ablaufen:

    Die V-Modell-Rollen sowie ihre Beteiligungen an Aktivitäten sind in Teil 3 - Handbuchsammlung (Handbuch Rollenkonzept im V-Modell) beschrieben.

    3.3 Anwendung der Szenarien

    Das V-Modell beschreibt die Systementwicklung im Regelungsteil (Abschnitt 4 ff.) als logisch verknüpftes Netz von Aktivitäten und Produkten. Die Abhängigkeiten sind dabei dadurch gegeben, daß für die Ausführung einer bestimmten Aktivität genau definierte Eingangsprodukte in einem ebenfalls definierten Zustand vorliegen müssen. In der konkreten Projektabwicklung müssen nun alle Entwicklungsaktivitäten auf ein Lebenszyklusmodell abgebildet und damit in einen zeitlichen Ablauf eingebunden werden. Basis der Ablaufplanung sind dabei die gewählte Entwicklungsstrategie und die sich daraus ergebenden statischen Abhängigkeiten, d. h. die Abhängigkeit jeder Aktivität von der Verfügbarkeit der erforderlichen Eingangsprodukte.

    In der Praxis erfolgt eine Systementwicklung in Ausbaustufen. Dabei wird ein System in seiner Gesamtheit geplant, aber in Teilen realisiert. Die Funktionalität wächst ständig. Im Regelfall soll an den Nutzer frühzeitig eine erste Systemversion ausgeliefert werden, die die Basisfunktionalität unter Einhaltung der grundlegenden Qualitätsanforderungen besitzt. Spätere Systemteile erweitern im wesentlichen diese Funktionalität.

    Diese stufenweise Vorgehensweise wird als "Inkrementelle Entwicklung" bezeichnet. Sie stellt den Regelfall der Anwendung des V-Modells dar.

    Für die Anwendung des V-Modells bedarf es der Planung der Ausbaustufen. Für jede Ausbaustufe ist die zu realisierende Funktionalität samt ihrer Qualitätsforderungen festzulegen. Die Aktivitäten und Produkte einer Ausbaustufe sind entsprechend den in den Produktflüssen definierten logischen Bedingungen zeitlich zu planen. Bereits existierende Produkte werden den Entwicklungsstufen entsprechend fortgeschrieben. Für die Produkte, die infolge der stufenweisen Entwicklung einem dynamischen Bearbeitungsprozeß unterliegen (z. B. Anwenderforderungen), ist insbesondere der geplante Bearbeitungsstand der entsprechenden Produkte für jede Ausbaustufe festzuschreiben.

    In Teil 3 - Handbuchsammlung (Handbuch Szenarien) ist die Anwendung des V-Modells für verschiedene Vorgehensweisen bei der Systementwicklung anhand der folgenden Szenarien beispielhaft dargestellt:

    Die Szenarien "Einsatz von Fertigprodukten", "Objektorientierte Entwicklung" und "Entwicklung wissensbasierter Systeme" basieren auf der inkrementellen Entwicklungsstrategie. Die traditionelle Vorgehensweise der linearen, phasenorientierten Systementwicklung (Grand Design) ist ein Spezialfall der inkrementellen Entwicklung (Realisierung in einer Ausbaustufe).

    Abbildung 3.1
    (daVinci Graph Visualization Tool v2.0)

    Abbildung 3.1: Planung einer Systementwicklung

    Abbildung 3.1: Planung einer Systementwicklung skizziert die Planung einer IT-Systementwicklung. Die Planung der Aktivitäten und ihrer Produkte erfolgt anhand der im Projekthandbuch festgelegten Entwicklungsstrategie und dem projektspezifischen V-Modell. Die Szenarien der Handbuchsammlung bieten Hilfestellung bei der Festlegung der Entwicklungsstrategie durch die Vorgabe von Auswahlkriterien.

    Für unterschiedliche Systemanteile können unterschiedliche Strategien ausgewählt werden, was zur Folge haben kann, daß auch unterschiedliche Ausprägungen des projektspezifischen V-Modells notwendig werden.

    3.4 Operative Module

    Neben den im Regelungsteil des V-Modells (Teil 1, Abschnitt 4 ff.) genannten Submodellen enthält Teil 3 - Handbuchsammlung verschiedene Ergänzungen bzw. Ersetzungen der Submodelle, die als "operative Module" bezeichnet werden. Ihr Einsatz hängt vom Entwicklungsgegenstand ab.

    Fordert die Entwicklung des geplanten IT-Systems neben der Entwicklung von SW-Einheiten auch die Entwicklung von HW-Einheiten, so wird die Ergänzung des Submodells SE um die Hardwareerstellung notwendig. Das operative Modul "Hardwareerstellung" behandelt die Entwicklung von HW-Einheiten (Aktivitäten SE4-HW - HW-Grobentwurf bis SE7-HW - HW-Integration).

    Handelt es sich um ein Reverse-Engineering-Projekt, so kann das gesamte Submodell SE durch das operative Modul Reverse Engineering ausgetauscht werden.

    3.5 Behandlung fortzuschreibender Produkte

    Das V-Modell behandelt die Bearbeitung von Produkten im Regelfall in folgender Art und Weise: Dieses Vorgehen trifft für die meisten der im V-Modell geregelten Produkte, insbesondere für SE- und QS-Produkte zu.

    Dennoch erfordern die Besonderheiten einer IT-Systementwicklung für einige Produkte ein hiervon abweichendes Vorgehen: Versionen können (u. a. im Rahmen einer inkrementellen Vorgehensweise) in den Zustand "vorgelegt" gehen, obwohl sie nur vollständig in bezug auf die geplante Version sind.

    Zu den Produkten, für die diese modifizierte Vorgehensweise zur Fortschreibung erforderlich sein kann, gehören:

    1. Anwenderforderungen,
    2. Systemarchitektur,
    3. Technische Anforderungen,
    4. Betriebsinformationen
    5. Schnittstellenübersicht and Schnittstellenbeschreibung,
    6. Datenkatalog,
    7. Konfigurations-Identifikationsdokument,
    8. Änderungsstatusliste and Projekthistorie,
    9. Projektplan and
    10. Integrationsplan.
    1. "Anwenderforderungen"

      Die Fortschreibung des Produkts Anwenderforderungen erfährt unter dem Gesichtspunkt einer inkrementellen Vorgehensweise eine besondere Behandlung.

      Die grobe Systembeschreibung enthält den Kern und den Gesamthorizont für die Funktionalität des Systems. Aufgrund einer Priorisierung werden Bereiche identifiziert, die zeitlich versetzt realisiert werden. Dazu muß klar sein, in welchen (bereichsspezifischen) Ausbaustufen das System aufwachsen soll und welche Gesamtfunktionalität im Endausbau abgedeckt werden soll. Dazu müssen Meilensteine (gegebenfalls als Baseline mit Zeitpunkt und Funktionsumfang) angegeben werden. Dies fordert weiterhin, daß alle relevanten fachlichen Bereiche benannt und in ihrem Funktionsumfang gegeneinander abgegrenzt sein müssen. Mit der vollständigen Beschreibung mindestens eines Bereichs kann die erste Version der Anwenderforderungen abgeschlossen werden. Diese unterliegt der QS.

      Die weitere Fortschreibung der Anwenderforderungen basiert auf der Detaillierung der identifizierten Bereiche. Bevor ein neuer Bereich weiter entwickelt wird, sind die Anwenderforderungen für diesen Bereich festzuschreiben und qualitätszusichern. Die QS hat besonders darauf zu achten, daß die Fortschreibung keinen bestehenden Anwenderforderungen widerspricht. Änderungen des vereinbarten Gesamthorizonts für die Funktionalität während der Entwicklung sind über Aktivität KM3 - Änderungsmanagement (Konfigurationssteuerung) abzuwicklen. Teilentwicklungen sind gegebenfalls davon betroffen, was aus vertragsrechtlichen Gründen zu Problemen führen kann.

    2. "Systemarchitektur"

      Die Systemarchitektur beschreibt die Zerlegung des Systems bis zur Ebene der SW-Einheiten und HW-Einheiten. Sie befindet sich daher während ihrer Erstellung in Aktivität SE2 - System-Entwurf im Zustand "in Bearb.". Ungeachtet dessen ist es sinnvoll, nach jedem Entwurfsschritt die neu hinzugekommenen Teile von QS prüfen zu lassen.

    3. "Technische Anforderungen"

      Das Produkt Technische Anforderungen enthält technische Anforderungen an das Gesamtsystem, an Segmente und an SW-Einheiten/HW-Einheiten. Das Produkt befindet sich daher während seiner Erstellung in den Aktivitäten SE2 - System-Entwurf und SE3 - SW-/HW-Anforderungsanalyse im Zustand "in Bearb.". Ungeachtet dessen ist es sinnvoll, nach jeder Ergänzung technischer Anforderungen bezüglich einzelner Elemente der Systemarchitektur die neu hinzugekommenen Teile von QS prüfen zu lassen.

      Aufgrund des Umfangs dieses Produkts (Bezugsobjekt: System) ist gegebenenfalls eine physikalische Aufteilung in mehrere Produktkomponenten z. B. nach SW-Einheiten oder Segmenten vorzunehmen.

    4. "Betriebsinformationen"

      Bei den hierunter zusammengefaßten Produkten "Informationen zum Anwendungshandbuch", "Informationen zum Diagnosehandbuch", "Informationen zum Betriebshandbuch" und "Sonstige Einsatzinformationen" handelt es sich um Informationen zur Anwenderdokumentation, die im Laufe der Systemerstellung aus den SE-Produkten abgeleitet und erarbeitet, sukzessive gesammelt und in Aktivität SE 8 "System-Integration" vervollständigt werden. Eine QS-Prüfung findet daher erst beim Abschluß der Entwicklungsarbeiten, d. h. nach Aktivität SE8 - System-Integration, statt. Aufgrund des Umfangs dieser Produkte (Bezugsobjekt: System) ist gegebenenfalls eine physikalische Aufteilung in mehrere Produktkomponenten z. B. nach SW-Einheit oder Segmenten vorzunehmen, die dann auch einzeln und gegebenenfalls auch früher einer QS-Prüfung unterzogen werden können.

    5. "Schnittstellenübersicht" and "Schnittstellenbeschreibung"

      Bei der Schnittstellenübersicht handelt es sich um ein Produkt, welches aus den Überlegungen und Entscheidungen bzgl. der Systemarchitektur und SW-Architektur resultiert. Es befindet sich daher während seiner Erstellung in den Aktivitäten SE2 - System-Entwurf und SE4-SW - SW-Grobentwurf im Zustand "in Bearb.", daran anschließend wird es an QS übergeben. Ungeachtet dessen kann es bei Systemen mit einer hohen Schnittstellenkomplexität sinnvoll sein, nach jedem Entwurfsschritt die neu hinzugekommenen Teile von QS prüfen zu lassen. Prinzipiell liegt bei der Schnittstellenbeschreibung der gleiche Sachverhalt vor. Da es sich hier jedoch um ein Produkt handelt, das nachfolgende Entwurfsschritte in entscheidendem Maß beeinflußt, wird für die Schnittstellenbeschreibung eine QS-Prüfung nach jeder Bearbeitungsaktivität (Aktivitäten SE2 - System-Entwurf, SE4-SW - SW-Grobentwurf) empfohlen. Die neu hinzugekommenen bzw. veränderten Teile sind dabei zu prüfen.

    6. "Datenkatalog"

      Der projektspezifische Datenkatalog wird über die projektübergreifende Datenadministration des KM (falls vorhanden) auf der Basis eines projektübergreifenden Datenkatalogs (falls vorhanden) initialisiert. Als projektumfassendes Dokument wird der Datenkatalog mit Aktivität SE5.1-SW - SW-Komponente/-Modul/Datenbank beschreiben sukzessive um Inhalte erweitert, welche von der projektübergreifenden Datenadministration zu genehmigen sind. Die an Aktivität SE5-SW - SW-Feinentwurf anschließende QS-Prüfung behandelt diese Ergänzungen.

    7. "Konfigurations-Identifikationsdokument" (KID)

      Das KID ist ein über die Aktivität KM2 - Produkt- und Konfigurationsverwaltung geführtes Produkt. Aktivität KM 2 ist eine projektbegleitende Aktivität, d. h. sie ist parallel zu den SE-Aktivitäten permanent "aktiv". Auslöser der Aktivität sind die im Projekt erstellten Produkte. Ein KID bezieht sich auf ein System, eine SW-Einheit bzw. eine HW-Einheit. In Abhängigkeit von dem jeweiligen Bezugsobjekt muß das KID solange im Zustand "in Bearb." bleiben, solange sich auch das Bezugsobjekt in diesem Zustand befindet.

    8. "Änderungsstatusliste" and "Projekthistorie" Hier handelt es sich um Produkte, die über die gesamte Projektlaufzeit und gegebenenfalls über Folgeprojekte hinweg fortgeschrieben werden müssen. Da sie in erster Linie der projektinternen Dokumentation dienen, wird für sie keine QS-Prüfung vorgeschrieben.
    9. "Projektplan"

      Der Projektplan befindet sich während des gesamten Projektes "in Bearb.". Eine zu bestimmten Zeitpunkten im Projektfortschritt verbindlich vorgeschriebene QS-Prüfung würde die Planung und Steuerung des Projektmanagements behindern. Dennoch ist auch der Projektplan zu prüfen, was beispielsweise im Rahmen von Durchführungsentscheidungen erfolgen kann. (Siehe dazu auch den Produktfluß von Aktivität PM4 - Feinplanung.)

    10. "Integrationsplan"

      Der Integrationsplan beschreibt die Integration des Systems ausgehend von SW-Modulen, SW-Komponenten, SW-Einheiten/HW-Einheiten und Segmenten. Er befindet sich während der Erstellung in Aktivität SE2 - System-Entwurf und Aktivität SE4-SW - SW-Grobentwurf im Zustand "in Bearb.". Ungeachtet dessen ist es sinnvoll, nach jedem Verfeinerungsschritt die Ergänzungen von QS prüfen zu lassen.

    Der Vollständigkeit halber seien hier noch weitere Sonderfälle von Produkten aufgeführt:

    Empfehlung:

    Zur Absicherung der Ergebnisse der Entwicklungsarbeiten sollten Produkte gegebenenfalls schon vor der im V-Modell vorgeschriebenen abschließenden Produktprüfung einer (Teil-) Prüfung durch QS unterzogen werden. Dieser Weg sollte mindestens dann eingeschlagen werden, wenn Um eine solche Zwischenprüfung oder Teilproduktprüfung bzgl. QS und KM verwaltungstechnisch zu handhaben, muß das betreffende Produkt physikalisch in Teilprodukte aufgespalten werden, die jedoch aus Sicht von QS und KM wie eigenständige Produkte zu behandeln sind, d. h. mit separaten Produktprüfungen, damit verbundenen getrennten Produktzuständen und -attributen und eigenen Verweisen im KID.

    Diese Maßnahme bietet sich beispielsweise an für eine Schnittstellenbeschreibung je Schnittstelle oder für Handbücher je Segment oder SW-Einheit bzw. HW-Einheit.

    Previous Next GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster