Die Anforderungen an IT-Systeme steigen stetig. Die Entwickler solcher Systeme
sehen sich immer komplexeren Aufgaben gegenübergestellt. Solche Systeme bedürfen
ausreichender Dokumentation, um sie warten, erweitern oder ggf. wiederverwenden
zu können. Da jedoch das Endprodukt im Mittelpunkt des Strebens eines
Projektteams steht, wird folglich ein Großteil der Energie in dieses gesteckt
und die Dokumentation häufig vernachlässigt. Unvollständige oder gar fehlerhafte
Handbücher sind die Folge. Daraus resultieren wiederum nicht zu unterschätzende
Probleme für die Auftraggeber von IT-Systemen, da sie bspw. durch unvollständige
Dokumentation in eine Abhängigkeit mit dem Softwarehaus (o. ä.) geraten. Oder
auch für die Softwarehäuser selber, die durch zu kurzfristige Zielsetzungen
anderen Aktivitäten als der Dokumentation eine höhere Priorität beimessen und
somit das aufgebaute Know-How in den Köpfen der Entwickler verbleibt. Die
Notwendigkeit und Bedeutung von Modellen und Vorgehensweisen, die im
Software-Entwicklungsprozeß explizit die Dokumentation enthalten und Zeitpunkte
(Projektphasen) definieren, zu denen Dokumentation fertiggestellt sein muß, wird
immer größer.
Das Informatik-Oberseminar mit dem Titel "Software Dokumentation mit Mustern
(SoDoM)" beschäftigt sich mit dieser Thematik und es gilt, zu untersuchen, ob
Patterns nicht auch bei der Dokumentation auftauchen und zu finden sind.
Diese Ausarbeitung entstand im Rahmen dieser Veranstaltung und behandelt
die dokumentenbasierte Software-Entwicklung am Beispiel des V-Modells.
Es findet an der Universität - Gesamthochschule - Siegen in der
Fachgruppe Technische Informatik (TI) im Sommersemester 1998 statt.
Nähere Informationen über das Seminar und dessen Inhalte erhalten Sie auf der
eigens eingerichteten
Homepage. Bei Fragen, Anregungen, Kritik oder
Diskussionswunsch wenden Sie sich an die Leiter des Seminars
Herrn Dr. Ing. Klaus Quibeldey-Cirkel und
Herrn Dipl. Ing. Georg Odenthal.
Anmerkung: Die folgende Ausarbeitung wurde für den Netscape Communicator V4.05
optimiert bei einer Bildschirmauflösung von 800x600 Pixeln. Es kam dabei die vom
Communicator unterstützte Technik der Cascading Style Sheets (CSS) zum Einsatz,
damit der Text anspruchsvoll gesetzt werden konnte. Abbildungen werden mittels
JavaScript erst bei Bedarf in einem seperaten Fenster angezeigt.
In diesem Kapitel wird das V-Modell einführend betrachtet. Es erläutert, was das V-Modell ist und geht kurz auf dessen Entwicklungsgeschichte ein. Danach wird die grundlegende Struktur dargestellt, die wesentlich für das Verständnis der darauffolgenden Kapitel ist.
Das V-Modell ist der Entwicklungsstandard für IT-Systeme des Bundes (EStdIT). Es bietet ein standardisiertes und klar strukturiertes Regelwerk zur Entwicklung, sowie der Pflege und Änderung von Systemen, deren Aufgabenerfüllung vorwiegend durch den Einsatz von Informationstechnik realisiert wird. Der Entwicklungsstandard besteht aus drei Bänden: Dem Vorgehensmodell, den Methodenzuordnungen und den funktionalen Werkzeuganforderungen. In der praktischen Umsetzung wird im V-Modell während des gesamten Entwicklungszyklus auf diesen drei Ebenen gearbeitet, die aufeinander aufbauen und sich ergänzen (siehe Abbildung 2.1).
Das Vorgehensmodell legt den inhaltlichen Ablauf eines Entwicklungsvorhabens
fest. Es wird bestimmt, was im Verlauf eines Projekts zu tun ist. Die
Methodenzuordnungen zeigen auf, wie die im Vorgehensmodell definierten
Aktivitäten durchgeführt werden können. Auf Basis der funktionalen
Werkzeuganforderungen wird die Frage beantwortet, welche Anforderungen an
Werkzeuge gestellt werden müssen, um die gewählten Entwicklungs- und
Managementmethoden optimal zu unterstützen. Sie definieren die im Projekt
einzusetzenden Werkzeuge.
Die Entwicklung des Standards wurde motiviert durch die Suche nach einem Ansatz,
der über die gängigen Pflichtenhefte hinaus, nicht das Produkt selbst
spezifiziert, sondern vielmehr den Weg dorthin festlegt. Es fehlte an einer
verbindlichen und allgemeingültigen Vorgehensweise bei der Projekterstellung,
Begleitung, Pflege und Änderung von Software für alle Arten von IT-Systemen, die
zugleich als Vertragsgrundlage zwischen Behörden und industriellen
Auftragnehmern dienen konnte.
Bei der Entwicklung standen die Steigerung der Softwarequalität, die Eindämmung
der Kosten des Lifecycles, die Verbesserung der Kommunikation zwischen Nutzer,
behördlichem Auftraggeber und industriellem Auftragnehmer und die Verringerung
der Abhängigkeit vom Auftragnehmer im Vordergrund. Da außerdem ein hoher Grad an
Flexibilität gefordert wurde, um beispielsweise eine Abbildung auf die in den
verschiedenen Behörden vorhandenen Ablauforganisationen zu ermöglichen, wurde
auf Allgemeingültigkeit großen Wert gelegt.
Zusammenfassend kann festgehalten werden, daß das V-Modell ein Prozeßmodell ist,
mit dessen Hilfe Projekte abgewickelt werden können. Es ist allgemeingültig und
muß aus diesem Grund durch Tailoring an die konkrete Projektsituation
adaptiert werden. Der Entwickler hat folglich noch alle Wahlfreiheiten und muß
ausschließlich im Vorfeld seine Wahl festlegen. Weiterhin erfüllt es - bei
ordnungsmäßiger Anwendung - die technischen Anforderungen nach ISO 900x und
AQAP-110 oder AQAP-150, wodurch die Prozeßqualität des Systems gewährleistet
wird.
Die Entwicklung des V-Modells begann 1986, als das Bundesministerium für Verteidigung (BMVg) in Zusammenarbeit mit dem Bundesamt für Wehrtechnik und Beschaffung (BWB) den Auftrag der Industrieanlagen- Betriebsgesellschaft mbH (IABG) in Ottobrunn bei München erteilten. Projektleiter bei der IABG war Rüdiger Kunstmann, der maßgeblichen Anteil an der Ausarbeitung der Inhalte hatte. 1990 wurde das V-Modell erstmals in Pilotprojekten erprobt, bis es dann im Februar 1991 vom BMVg für den wehrtechnischen Bereich als verbindlich vorgeschrieben wurde. 1992 übernahm das Bundesministerium des Inneren (BMI) das Vorgehensmodell für den zivilen Verwaltungsbereich und auch die Industrie begann, es verstärkt zu nutzen. Ein Beispiel dafür ist Siemens, die im Bereich der Sicherheitstechnik das V-Modell als Hausstandard einsetzen.
Das V-Modell legt den Ablauf vom Start eines Projektes, über den gesamten Projektverlauf bis hin zum Projektende fest. Es beschreibt die IT- Systementwicklung als einen Prozeß aus der technisch-funktionalen Sicht. Das „System“ wird hier als eine Funktionseinheit der obersten Ebene angesehen und es wird festgelegt aus welchen generischen Bausteinen es sich grundsätzlich zusammensetzt. Diese Einheiten werden Segmente genannt, wobei das V-Modell zwischen Segmenten mit IT-Anteil und zwischen denen ohne IT-Anteil unterscheidet. Die Segmente mit IT-Anteil werden wiederum in Software-Einheiten und Hardware-Einheiten gegliedert. So wird das System bis auf die Modulebene immer feinkörniger unterteilt. Abbildung 2.2 verdeutlicht diese hierarchische Struktur, die im V-Modell die Erzeugnisstruktur genannt wird.
Für alle Bausteine legt das V-Modell eine kontrollierte Entwicklungsweise fest. Dies tut es, indem Aktivitäten (Aufgaben) spezifiziert werden, die Produkte erzeugen oder bearbeiten. Die Aktivitäten und Produkte sind die Grundelemente des V-Modells. Tätigkeiten, die auf Grund ihrer Ergebnisse und Durchführung genau beschrieben werden können, werden als Aktivitäten bezeichnet. Mit Produkt meint man den Bearbeitungsgegenstand bzw. das Ergebnis einer Aktivität, was Software bzw. Hardware oder Dokumentation gleichermaßen sein kann. Es gilt hierbei zu beachten, daß Produkte im Entwicklungsprozeß verschiedene Zustände durchlaufen (siehe Abbildung 2.3). Da Produkte die während einer Aktivität erzeugt wurden ggf. in anderen Aktivitäten als Eingangsprodukt die Arbeitsgrundlage bilden, müssen diese in den Zustand „akzeptiert“ übergehen, bevor die darauf aufbauende Aktivität mit ihrer Arbeit beginnen kann.
Der Software-Entwicklungsprozeß wird im V-Modell durch Aktivitäten beschrieben. Einige dieser Aktivitäten lassen sich nach ihren Gemeinsamkeiten zusammenfassen und können somit in einem eigenen abgeschlossenen Modell dargestellt werden. Ein solches wird im V-Modell Submodell genannt. Folgende vier Submodelle bilden das V-Modell (siehe Abbildung 2.4):
|
Die vier Submodelle des V-Modells sind eng miteinander vernetzt und beeinflussen sich gegenseitig (vgl. Abbildung 2.5). Das Projektmanagement (kurz PM) plant, steuert und kontrolliert ein Entwicklungsvorhaben (Projekt). Dies tut es, indem es über die anderen Submodellen wacht. Die Systemerstellung (kurz SE) spielt die zentrale Rolle im Entwicklungsprozeß von IT-Systemen. Hier findet die Erstellung der Soft- und Hardware statt und die notwendige Dokumentation wird erstellt. Das Qualitätsmanagement (kurz QM) bestimmt Qualitätsanforderungen und Prüfmethoden, die die Produkte einhalten sollen und mit denen die Ergebnisse geprüft werden. Die entstandenen Produkte werden durch das Konfigurationsmanagement (kurz KM) verwaltet und bei Bedarf kontrolliert in den Entwicklungsprozeß zurückgeführt.
Abbildung 2.6 zeigt abschließend, wie die Produkte der vier Submodelle in die hierarchische Erzeugnisstruktur einzuordnen sind.
Im vorangegangenem Kapitel wurde die Struktur des V-Modells verdeutlicht.
Dabei spielte die Erzeugnisstruktur eine wichtige Rolle, die das IT-System in
generische, hierarchisch aufeinander aufbauende Einheiten zerteilt, und damit
die Komplexität des Gesamtsystems verringert. Auf diese Struktur wirken die
integralen Bestandteile des V-Modells ein, die vier Submodelle. Die in ihnen
zusammengefaßten Aktivitäten definieren in jedem einzelnen Baustein die zu
leistenden Aufgaben. Dafür wird in den Submodellen wiederum auf den drei Ebenen
des V-Modells gearbeitet, um beispielsweise die funktionalen
Werkzeuganforderungen zu bestimmen.
Im folgenden wird nun auf die einzelnen Submodelle detaillierter eingegangen,
was aber nicht heißen kann, daß sie erschöpfend und in allen Einzelheiten
abgehandelt werden. Dies würde den Rahmen dieser Seminararbeit sprengen. Es soll
vielmehr ein Gefühl für die Aufgaben und verfolgten Ziele einer jeden Submodells
vermittelt werden.
Am Ende jedes Unterkapitels eine Auflistung der
Aktivitäten und Produkte sowie ein graphischer Funktionsüberblick des
jeweiligen Submodells angefügt. Die graphische Notation die dafür im V-Modell
für die Aktivitäten und Produkte gewählt wurde, wird aus Abbildung 3.1
ersichtlich.
Das V-Modell legt nicht fest, wie die Aktivitäten im Projektmanagement durchzuführen bzw. welchen Organisationseinheiten (Personen) sie zugeordnet sind. Trotzdem kann gesagt werden, daß in den meisten Fällen die zentrale Rolle im PM ein Projektleiter einnimmt. Dieser initialisiert das Projekt mit der ersten gleichnamigen Aktivität, in der die projektinterne Zusammenarbeit und ggf. die Schnittstellen zu externen Beteiligungen im ersten Produkt, dem Projekthandbuch, festgehalten werden. Hierfür werden die Projektkriterien und –randbedingungen zusammengetragen, wodurch das Tailoring am V-Modells erfolgen kann. Das so entstehende projektspezifische V-Modell (PM 1.3) ist ebenfalls Inhalt des Projekthandbuchs. Darauf aufbauend wird der grobe Projektplan erstellt (PM 1.4), wobei die Historie ähnlich gearteter Projekte einfließen kann. Der Grobplan legt die Aufwands-, Termin- und Personalplanung zunächst näherungsweise bis zum Projektende dar. Ferner erfolgt die Auswahl einer für das Projekt geeigneten bzw. zugeschnittenen Entwicklungsumgebung, die den Projektmitarbeitern verfügbar gemacht werden muß. Falls das System oder Teile davon durch externe Leistungen realisiert werden sollen, bilden die Aktivitäten Vergabe/Beschaffung (PM 2) und Auftragnehmer-Management (PM 3) das Gerüst zum Vertragsabschluß bzw. zur Beschaffung und zur Überwachung der Arbeitsfortschritte innerhalb der vereinbarten Termine. Werden keine externen Leistungen in Anspruch genommen, entfallen diese zwei Aktivitäten. In der Feinplanung (PM 4) werden auf Basis der bestehenden Grobplanung und unter Hinzunahme des Projekthandbuchs in verschiedenen Teilschritten Verfeinerungen am Projektplan durchgeführt. Hinter den Teilschritten verbergen sich unter anderem das technische Tailoring und die Aufwands- und Terminplanung. Um die Rentabilität von geplanten Lösungen feststellen zu können, werden in der Kosten-/Nutzenanalyse (PM 5) für die verschiedenen Lösungsvorschläge die Kosten abgeschätzt und dem Nutzen gegenübergestellt. Dabei werden die Kosten und der Nutzen des gesamten Lebenszyklus – und nicht nur der Entwicklung – der Lösung betrachtet. Entscheidungen, die im Projektverlauf den Zwecken des Abschlußes von Verträgen oder der Bestätigung der im Projektplan definierten Baselines dienen, sind in der Durchführungsentscheidung(PM 6) zu treffen und werden in ein Protokoll verfaßt. Die Erkennung möglicher Risiken im Projekt, die Einleitung geeigneter, vorbeugender Maßnahmen und die Überwachung der Maßnahmen sind Aufgaben des Risikomanagements (PM 7). Im PM wird natürlich auch der Projektfortschritt verfolgt und kontrolliert und bei Abweichungen wird steuernd eingegriffen. Diese Aktivität trägt den Namen Projektkontrolle und –steuerung (PM 8). Für die notwendige Kommunikation zwischen der Projektleitung, den Mitarbeitern, externen Auftragnehmern und Anwendern sorgt die Aktivität Informationsdienst/Berichtswesen (PM 9). Sie informiert über den aktuellen Stand des Vorhabens und ist periodisch durchzuführen. Aus ihr abfallende Dokumente ist bspw. der Sachstandsbericht und der Sachbericht. Werden vom Projektmanagement Defizite im Ausbildungsstand des Personals bemerkt, so sind im Rahmen der Schulung/Einarbeitung (PM10) entsprechende Aus- und Fortbildsmaßnahmen zu veranlassen. Für die Durchführung der Arbeitsschritte muß das Management die dafür vorausgesetzten Mittel wie Arbeits- und Betriebsmittel, Rechenanlagen und die festgelegte Software-Entwicklungsumgebung (SEU) bereitstellen. Die dafür definierte Aktivität im PM trägt den Namen Bereitstellung der Ressourcen (PM 11). Soll ein Arbeitsschritt durch externe Leistungen verwirklicht werden, so wird durch die Vergabe von Arbeitsaufträgen (PM 12) beschrieben, welche Angaben im Arbeitsauftrag gemacht werden müssen. Dazu zählen die Arbeitsanleitung sowie Soll-Werte und Erläuterungen und der gleichen mehr. Das PM sieht schließlich die Einweisung der Mitarbeiter vor. Hier werden die Mitarbeiter mit dem Arbeitsabschnitt vetraut gemacht und die Aufgabenstellung wird ihnen erläutert. Die folgende Abbildung 3.2 stellt nochmals alle Aktivitäten und die in ihnen bearbeiteten bzw. erzeugten Produkte dar und Abbildung 3.3 zeigt ihr zusammenspiel.
Die drei Submodelle Qualitätsmanagement, Projektmanagement und Konfigurationsmanagement beschreiben die begleitenden Aktivitäten in einem Entwicklungsvorhaben. Die eigentliche Entwicklung findet im Submodell Systemerstellung statt. Es unterteilt sich in zwei Ebenen, die durch bestimmte Aktivitäten geprägt sind:
|
Innerhalb dieser Ebenen wird zunächst die Anforderungsanalyse
erstellt und darauffolgend der Entwurf des Systems bzw. der Einheiten
spezifiziert. Sie dienen dazu in zeitlich frühen Phasen von abstrakten
Beschreibungen zu Software- oder Hardwareeinheiten zu gelangen und in
späteren Phasen zum Gesamtsystem zu kommen.
Die Aktivität System-Anforderungsanalyse (SE 1) setzt sich aus den
Teilaktivitäten SE 1.1 bis SE 1.8 zusammen. Sie erhält als Eingangsprodukte die
externen Vorgaben, die Rahmenbedingungen, die Systemarchitektur und Protokolle.
Auf Basis dieser Produkte erzeugt bzw. bearbeitet SE 1 die Anwenderanforderungen,
die eine grobe Systembeschreibung darstellen und auf der in weiteren
Entwicklungszyklen aufgebaut wird und dort weiter verfeinert werden. Die
Anwenderanforderungen fließen dann in den System-Entwurf (SE 2) ein, der zunächst
aufgrund der Eingangsprodukte eine möglichst technische Systemarchitektur
erarbeitet. Hierbei wird bereits auf den geeigneten Einsatz von Fertigprodukten
geachtet. Der Lösungsvorschlag wird nachfolgend bewertet und ist bei einer
Ablehnung zu überarbeiten. Wurde er akzeptiert, wird die Systemarchitektur verfeinert
und endet mit der Identifikaton der Schnittstellen, die in der Schnittstellenübersicht
angeführt werden und in der Schnittstellenbeschreibung näher erläutert werden. Die
SW-Architektur und die Schnittstellenbeschreibungen stellen im folgenden die
Informationsquellen für den SW-Feinentwurf (SE 5-SW) dar. Hier werden die Details
für die Realisierung jedes Moduls, jeder Komponente und jeder Datenbank festgelegt
und der Betriebsmittel- und Zeitbedarf der einzelnen Elemente ermittelt. Niedergeschrieben
werden die Ergebnisse im Datenkatalog und SW-Entwurf. Im Rahmen der
SW-Implementierung (SE 6-SW) sind nun die Module und Datenbanken zu verwirklichen
bevor sie während der SW-Integration (SE 7-SW) unter Einhaltung des Integrationsplans
und unter Hinzunahme – falls vorhanden – der HW-Einheiten und Nicht-IT-Anteile zu einem
System zusammengeführt (System-Integration, SE 8). Ist das System fertiggestellt, sorgt die
Aktivität Überleitung in die Nutzung (SE 9) für die Installation und Inbetriebnahme an der
vorgesehenen Einsatzstelle.
Auch am Ende dieses Kapitels folgen zwei Abbildung, die diese Fakten nochmals genauer darstellen.
Auch in diesem Submodell - wie schon im Projektmanagement - berühren die Regelungen in keiner Weise organisatorische oder personelle Festlegungen. Eine Abbildung auf die konkret vorhandene Ablauforganisation muß zunächst stattfinden, bevor die Arbeit in der QS beginnen kann. Wie bereits erläutert wurde, werden die aufgestellten Anforderungen an das zu entwickelnde System im Laufe eines Projekts durch die Aktivitäten in den Submodellen PM und SE verfeinert und in den Produkten "Anwenderforderungen" und "Technische Anforderungen" festgehalten. Die in der QS zusammengefaßten Aktivitäten dienen nun dem Nachweis der Erfüllung der gegebenen Anforderungen, der Vermeidung von Mängeln und der Sicherstellung einer Prozeßqualität. Bei der QS-Initialisierung (QS 1) - der ersten eigenständigen QS-Aktivität - wird im QS-Plan der organisatorische Rahmen niedergeschrieben. Er enthält die für das gesamte Projekt gültigen Festlegungen bzgl. der Erreichung der Qualitätsziele, die Vermeidung von Qualitätsrisiken und der Nachweisführung der tatsächlichen Erreichung der Qualitätsforderungen. Im Prüfplan werden unter Abstimmung mit der Projektleitung und dem zugrundeliegendem QS-Plan die zu prüfenden Produkte und Aktivitäten mit den jeweiligen Qualifikationserfordernissen der Prüfer bestimmt und die zeitliche Synchronisation mit dem Projektfortschritt dargestellt. Befinden sich die Produkte "QS-Plan" und "Prüfplan" im Akzeptiert-Zustand, extrahiert die Aktivität Prüfungsvorbereitung (QS 2) aus ihnen die Prüfspezifikation und –prozedur, die der "QS-Verantwortliche" nach erfolgreicher Kontrolle freigibt. Die Prozeßprüfung von Aktivitäten (QS 3) stellt fest, ob gewählte Vorgehensweisen und Produktstandards bei der Durchführung von Aktivitäten in allen vier Submodellen eingehalten wurden. Produkt dieser Aktivität ist das Prüfprotokoll. Auch die Produktprüfung (QS 4) erzeugt bzw. bearbeitet ein Prüfprotokoll. Dieses beinhaltet, ob die formalen Vorgaben eingehalten worden sind und ob das Produkt inhaltlich prüfbar ist. Ist dies der Fall wird es gemäß der Prüfspezifikation untersucht. Wenn nicht, geht es in das zugehörige Submodell (Aktivität) zur Überarbeitung zurück. In beiden Fällen findet ein Zustandswechsel gemäß des Zustandsdiagramms statt. Die Prüfprotokolle der Aktivitäten Prozeß- und Produktprüfung gehen in das QS-Berichtswesen (QS 5) ein, in dessen Rahmen sie auf die Anzahl, die Schwere, die Klassifikation und die Ursache der Probleme hin ausgewertet werden. Die hieraus entstehenden Produkte sind die sogenannten Berichtsdokumente.
Das Ziel des Konfigurationsmanagements ist es, Produkte bezüglich
ihrer funktionellen Merkmale sowie ihrer zugehörigen Bestandteile
(bspw. Dokumentation) jederzeit eindeutig identifizierbar zu machen, um
sie systematisch und kontrolliert ändern bzw. erweitern zu können und die
Integrität zu gewährleisten. Dazu überwacht und dokumentiert das KM die
Konfigurationen, so daß die Zusammenhänge und Unterschiede zwischen
früheren und aktuellen Konfigurationen nachvollziehbar sind. Jedes Produkt
erhält auf diesem Weg eine Historie, auf dessen Grund die bis dato entwickelten
Konfigurationen selektierbar sind.
Die erste KM-bezogene Aktivität legt den organisatorischen Rahmen im KM-Plan
fest und stellt Einsatzmittel wie die Produktbibliothek und ihr zugehörige Werkzeuge
bereit. Um ein absichtliches oder unabsichtliches Zerstören von Konfigurationen zu
vermeiden, werden durch die Produkt- und Konfigurationsverwaltung (KM 2) alle
Produkte einer Konfiguration in der Produktbibliothek archiviert. Dazu wird zunächst
jedes Produkt in der Produkt Initialisierung (KM 2.1) namentlich erfaßt und in der
Produktbibliothek eingetragen. Falls es sich bei dem Produkt um ein System, eine
SW- oder HW-Einheit handelt wird im nächsten Schritt ein System KID, ein SW-KID
bzw. ein HW-KID angelegt, um sicherzustellen, daß eine solche Konfigurationseinheit
eindeutig und zu jeder Zeit aus ihren Elementen konfiguriert bzw. rekonfiguriert werden kann.
Im KM-Plan werden im Zuge der Zugriffsrechteverwaltung (KM 2.5) Zugriffsrechte auf die
Produkte in der Produktbibliothek bestimmt, die beschränkten oder unbeschränkten Zugriff
durch die Projektbeteiligten erlaubt. Treten im Laufe des Projekts Probleme auf, die
Änderungen zur Folge haben, werden Änderungsanträge gestellt oder Problemmeldungen
eingerichtet, die in der Aktivität Änderungsmanagement (KM 3) erfaßt und verwaltet werden.
Es findet dort eine Bewertung der Meldungen statt und entsprechende Maßnahmen werden
eingeleitet. Die letzte Aktivität des KM nennt sich KM-Dienste (KM 4) und sie enthält alle
diejenigen Aktivitäten, die nach Bedarf, in Intervallen oder auf Veranlassung durchzuführen sind.
Dazu gehört die Daten administration (KM 4.1), mit dem Ziel alle Datenkataloge
unternehemensweit konsistent zu halten. Die Wiederverwendbarkeit der Produkte zu
ermöglichen verfolgt die SW-HW-Produkte Katalogisierung (KM 4.2), um die Vereinheitlichung
der Schnittstellen bemüht sich die Schnittstellen Koordination (KM 4.3). Die Sicherung des
Projektstands übernimmt die Aktivität KM 4.4 Ergebnisse sichern. KM-bezogene Dokumetation
wird in der KM-Dokumentation führen (KM 4.5) erledigt und die Aktivitäten
Release-Management durchführen (KM 4.6) und Projekthistorie führen (KM 4.7) sind ebenfalls
noch Bestandteil der KM-Dienste.
Wie man deutlich gesehen hat, stellt der Entwicklungsstandard des Bundes
ein mächtiges Werkzeug dar, mit dessen Hilfe die Abwicklung von
Entwicklungsvorhaben geplant und kontrolliert durchzuführen ist. Seine
Allgemeingültigkeit erlaubt den Einsatz unter allen denkbaren Organisationsformen.
Die Anpassung erfolgt durch Tailoring und die Abbildung der Rollen, die in einem
Projekt zu bekleiden sind, auf vorhandenes Arbeitspotential. Durch die Qualitätssicherung
sind die Produkte ISO 900x konform. Das Konfigurationsmanagement ermöglicht die
Verwaltung und genaue Identifikation der verschiedenen Konfigurationen eines Systems.
Damit bietet das V-Modell ein komplettes und strukturiertes Regelwerk, nachdem ein
Projekt, wie an einem Leitfaden, durchgeführt werden kann.
Außerdem ist die Entwicklung von komplexen und großen Systemen ohne ein solches
Vorgehensmodell undenkbar. Da heutige Systeme durch die von ihnen zu erfüllenden
Aufgaben immer komplexer werden, sind Modelle dieser Art von wachsender Bedeutung.
Das V-Modell gehört sicherlich zu den Modellen, auf die auch in Zukunft als Rahmen zur
Systemerstellung die Wahl fallen wird, da es sich in den 7 Jahren, in denen es schon zum
Einsatz kommt, in vielen Projekten bewährt hat.
Aber auch das V-Modell ist nicht das Maß aller Dinge. Es wird immer wieder Kritik laut von
Personen, die das V-Modell als Regelwerk eingesetzt haben. So befand Dr. W. Mansel
(Daimler-Benz Aerospace) das V-Modell als schwierig in konkreten Projekten umzusetzen,
bedingt durch die hohe Komplexität des Standards. Weiterhin werde der Aufwand bei Erstanwendungen
generell unterschätzt und das Tailoring stelle eine nicht triviale Aufgabe dar. Auch Dr. H. Hummel (IABG)
stellte in einem Vortrag mit dem Titel "Stand und Weiterentwicklung des V-Modells" fest, daß ein hoher
Einarbeitungsaufwand bestünde und die voluminösen Vorschriften ein Unbehagen und sogar Angst im
Umgang mit dem Standard aufkommen lassen. Herr Woletz berichtete von ähnlichen Problemen beim
Einsatz in der sicherheitstechischen Abteilung von Siemens.
Und auch ich muß an dieser Stelle bemerken, daß ich das V-Modell insgesamt zu erschlagend finde. Bei
der Fülle von Aktivitäten und der dazugehörigen Eingangs- und Ausgangsprodukten fühlt man sich
– gerade als V-Modell-Neuling – völlig überfordert. Außerdem bin ich der Meinung, daß bei der
Systemerstellung anhand des Entwicklungsstandards des Guten zu viel Dokumentation produziert
wird. Dies kann, in Hinblick auf die Beauftragung eines systemunkundigen Unternehmens zur
Weiterentwicklung, eher hemmen als voran bringen. Ein schlankeres und eingängerisches V-Modell
wäre sicher von Vorteil, soweit das mit gleichbleibender Qualität und Allgemeingültigkeit realisierbar ist.
Trotzdem all dieser Nachteile muß man festhalten, daß die Entwicklung ohne ein Vorgehensmodell ab
einem bestimmten Komlexitätsgrad nicht erfolgsversprechend wäre. Man sollte es allerdings tunlichst
vermeiden das V-Modell als Allheilmittel anzusehen und die Komplexität dessen nicht unterschätzen.
Großes Augenmerk sollte man auf eine geeignete Toolunterstützung legen, da es im Umgang und der
Arbeit mit dem Modell hilft und somit evtl. aufkommenden Frust entgegenwirkt und die Produktivität
steigert.
Im Anhang finden Sie, neben dem Literaturverzeichnis und einer Zusammenstellung
relevanter Hyperlinks zum Thema V-Modell, die Ausarbeitung in diversen Datei-Formaten
und die MS PowerPoint Präsentation des Vortrags.