Diplomarbeit. F E R N U N I V E R S I T Ä T Gesamthochschule in Hagen Fachbereich Wirtschaftswissenschaft

Transkript

1 F E R N U N I V E R S I T Ä T Gesamthochschule in Hagen Fachbereich Wirtschaftswissenschaft Diplomarbeit im wirtschaftswissenschaftlichen Zusatzstudiengang für Ingenieure und Naturwissenschaftler Bearbeitungszeit 9 Wochen (Teilzeitstudent) im Fach : Wirtschaftsinformatik über das Thema : Analyse des V-Modells als Entwicklungsstandard für IT-Systeme des Bundes - ein Konzept zur inkrementellen Softwareentwicklung Betreut durch : Prof. Dr. R. Gabriel, Ruhr-Universität Bochum Verfasser : Dipl.-Ing. Christoph Wolfram Kettenbach Matrikel-Nr. : Anschrift : Mittelstraße Bremerhaven Telefon : 0471 / Fax : 0471 / Christoph.Kettenbach@nordkom.netsurf.de Abgabedatum : 14. August 1998

2 Frau Petronella Steigert gewidmet.

3 Abstract Die vorliegende Diplomarbeit im Fach Wirtschaftsinformatik befaßt sich mit der Anwendung des Entwicklungsstandards für IT-Systeme des Bundes (V-Modell) für die Inkrementelle Entwicklung im Rahmen des Software Engineering. Nach einer kurzen Einführung in das V-Modell, die als Basis für die nachfolgenden Untersuchungen dient, wird untersucht, was unter Inkrementeller Entwicklung zu verstehen ist. Inkrementelle Entwicklung bedeutet: Entwicklung eines IT-Systems in Ausbaustufen innerhalb eines vorher festgelegten Gesamtrahmens der Anforderungen an das System. Die Inkrementelle Entwicklung soll einem grundsätzlichen Problem bei der IT-System-Entwicklung Abhilfe schaffen. Es ist das Problem, ein IT-System von vornherein so genau und treffend zu spezifizieren, daß die Entwicklung in nachfolgenden sequentiellen Phasen ablaufen kann. Die Erfahrungen mit den ausgelieferten Inkrementen ermöglichen es, die Anforderungen im Laufe einer Entwicklung stetig zu präzisieren. Inkrementelle Entwicklung hat fast immer auch evolutionären Charakter. Während der Entwicklung erfolgt ein permanenter Lernprozeß. Aufgrund des Lernprozesses verändern sich die Anforderungen, die ursprünglich einmal hinsichtlich des Systems formuliert wurden. Der Entwicklungsstandard für IT-Systeme des Bundes Vorgehensmodell (V-Modell) liegt in der neuen Ausgabe von Juni 1997 vor. Das V-Modell ist ein Standard, der als Arbeitsanleitung, Kommunikationsbasis und Vertragsgrundlage dienen kann. Innerhalb des Standards V- Modell gilt die Anwendung der Strategie der Inkrementellen Entwicklung von IT-Systemen als Regelfall. Es stellt sich die Frage, ob der Standard V-Modell den Anforderungen der Inkrementellen Entwicklung gerecht wird. Die Untersuchung zeigt: Die Anwendung des Entwicklungsstandards V-Modell für Inkrementelle Entwicklung ist sehr gut möglich. Das V-Modell ist kein Phasenmodell, welches ein streng sequentielles Abarbeiten von Phasen erforderlich macht. Die Regelungen des Standards sind auch nicht darauf fixiert, innerhalb von Phasenmodellen angewendet zu werden. Sie sind flexibel genug, um auch den Anforderungen der Inkrementellen und auch Evolutionären Entwicklung gerecht zu werden. Dies wird anhand des von Hesse vorgestellten Verfahrens zur Evolutionären Objektorientierten Softwareentwicklung (EOS) nachgewiesen. Der Standard V- Modell bietet wirkungsvolle Maßnahmen zur Unterstützung der Inkrementellen und Evolutionären Entwicklung. Er ermöglicht ein sachdienliches Management von Projekten mit Inkrementeller Entwicklungsstrategie.

4 INHALTSVERZEICHNIS 1 Einleitung Erläuterung der Aufgabenstellung Erläuterung der Vorgehensweise Organisatorische Rahmenbedingungen der Arbeit Danksagung V-Modell (Entwicklungsstandard für IT-Systeme des Bundes) Vorbemerkungen Entstehung des V-Modells Aufbau des Standards Definition des Begriffes Standard Standardisierungskonzept Tailoring Submodelle Projektmanagement Systemerstellung Qualitätssicherung Konfigurationsmanagement Dreistufige Standardisierung Gliederung eines IT-Systems nach V-Modell Einsatz des V-Modells in verschiedenen Organisationen Weiterentwicklung und Pflege des Standards Zweck des Standards...17 I

5 2.8.1 Vertragsgrundlage Arbeitsanleitung Kommunikationsbasis Verbreitung und wirtschaftliche Bedeutung des V-Modells Erörterung der Kritik am V-Modell Entwicklungsstrategien beim Software Engineering Software-Engineering Historisches (Softwarekrise) Begriffsdefinition Software Engineering Software Engineering als Ingenieurdisziplin System Engineering Definition des Begriffes Entwicklungsstrategie Wasserfallmodell (Phasenmodell) als ursprüngliche Strategie Nachteile der Strategie Problem der genauen Spezifikation von IT-Systemen Einteilung von Software nach ihrer Spezifizierbarkeit Ansätze zur Behebung des Spezifikationsproblems Das Problem der Wartung von IT-Systemen Beispiel für ein Wasserfallmodell (NASA) Wasserfallmodelle sind nicht sequentiell Vorstellung von Inkrementeller und Evolutionärer Entwicklungsstrategie Vorteile der Inkrementellen Entwicklungsstrategie Stetige Präzisierung der Spezifikation des IT-Systems Vermeidung der Entwicklung unnötiger Details Integration von Wartung und Weiterentwicklung Gründe für die Abgrenzung von inkrementell und evolutionär Inkrementelle Entwicklung und Cleanroom Software Engineering Entwicklungsstrategie Prototyping...47 II

6 3.6 Alternative Abgrenzung der Entwicklungsstrategien Entwicklungsstrategie Objektorientierte Entwicklung Analyse der Unterstützung der Strategie der Inkrementellen Entwicklung durch das V-Modell Relevanz der Fragestellung Analyse: Abgrenzung der Begriffe Phase und Aktivität im V-Modell Unterschied Entwicklungsstandard V-Modell und Phasenmodell Unzureichende Dynamik starrer Phasenmodelle Projektmanagement für Inkrementelle Softwareentwicklung Untersuchung der Unterstützung von Evolutionärer Objektorientierter Softwareentwicklung (EOS) durch das V-Modell Anforderungen an das Projektmanagement Analyse: Erfüllung der Anforderungen durch das V-Modell Evolutionäre Objektorientierte Softwareentwicklung (EOS) Analyse: Eignung des V-Modells als Standard für EOS Ergebnis Zusammenfassung der förderlichen Elemente des Standards Zusammenfassung der hinderlichen Elemente des Standards Zusammenfassung Literaturverzeichnis...75 Anhang...82 III

7 ABBILDUNGS- und TABELLENVERZEICHNIS Bild 1 Einteilung der Projekte (Vorhaben) in Typen beim Standardisierten Vortailoring...8 Bild 2 Vergleich der beiden Tailoringverfahren...9 Bild 3 Zusammenspiel der Submodelle...10 Bild 4 Ablauf der Systemerstellung (Submodell SE)...12 Bild 5 Mögliche Zustände eines Produktes nach V-Modell...14 Bild 6 Dreistufige Standardisierung im V-Modell...14 Bild 7 Gliederung eines IT-Systems nach V-Modell...16 Bild 8 Wasserfallmodell nach B. Boehm Bild 9 Phasenmodell der NASA...38 Bild 10 Verteilung des Personalaufwandes während der Phasen...39 Tabelle 1 Charakteristika der NASA -Softwareprojekte...40 Bild 11 Abgrenzung der Entwicklungsstrategien nach V-Modell...49 Bild 12 Abgrenzung der Entwicklungsstrategien nach Hesse...50 Bild 12 Mögliche zeitliche Anordnung der Aktivitäten...54 Bild 13 Ablauf der Inkrementellen Entwicklung nach V-Modell...55 Bild 14 Tätigkeiten in einem Entwicklungszyklus...63 Bild 15 Zeitlich verzahnte Entwicklungszyklen...64 Bild 16 Evolutionäre und Inkrementelle Entwicklung mit V-Modell...66 Bild 17 EOS mit V-Modell...68 IV

8 ABKÜRZUNGSVERZEICHNIS AU BMI BMVg BWB CASE DIN DoD EOS IPAS IT KM PM QS SE SEL V-Modell Allgemeiner Umdruck Bundesministerium des Innern Bundesministerium der Verteidigung Bundesamt für Wehrtechnik und Beschaffung Computer Aided Software Engineering Deutsches Institut für Normung Department of Defense (USA) Evolutionäre Objektorientierte Systementwicklung Interdisziplinäres Projekt zur Arbeitssituation in der Software-Entwicklung Informationstechnik Konfigurationsmanagement Projektmanagement Qualitätssicherung Systemerstellung Software Engineering Laboratory der NASA Entwicklungsstandard für IT-Systeme des Bundes (Vorgehensmodell) V

9 1 Einleitung 1.1 Erläuterung der Aufgabenstellung Das V-Modell ist der verbindliche Entwicklungsstandard für Informationstechnik-Systeme (IT-Systeme) im Bereich der Bundeswehr und im Bereich der öffentlichen Verwaltung. Es regelt die Vorgehensweise bei der Entwicklung von IT-Systemen. Die Bezeichnung V- Modell wird allgemein als Abkürzung des Begriffes Vorgehensmodell gebraucht. Ein Vorgehensmodell ist eine modellhafte Darstellung des idealtypischen Entstehungsprozesses von IT-Systemen. Weiterhin findet etwas spezieller die Bezeichnung V-Modell für Vorgehensmodelle Verwendung, bei denen die bildliche Darstellung der Abfolge von Entwicklungsaktivitäten dem Buchstaben V entspricht. Der linke Arm des Buchstabens besteht aus den Aktivitäten des Entwurfsprozesses von IT-Systemen, der rechte Arm aus den Aktivitäten der Integration und Überprüfung. Wurde in der ersten Version (1992) das V-Modell noch mit dem Titel Planung und Durchführung von IT-Vorhaben: Vorgehensmodell bezeichnet, so lautet der offizielle Titel der jetzt aktuellen Version (1997) Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell (V-Modell). Dieser Titel macht deutlich, daß das V-Modell als Standard aufgefaßt werden soll, der die Entwicklung von Systemen und Software regelt. Wird von dem V-Modell gesprochen, so ist häufig der Entwicklungsstandard für IT-Systeme des Bundes gemeint. In der vorliegenden Arbeit wird der Einfachheit halber statt der Bezeichnung Entwicklungsstandard für IT-Systeme des Bundes der Begriff V-Modell verwendet. Bei der Verwendung des V-Modells als Standard können verschiedene Entwicklungsstrategien zur Anwendung kommen. Solche Entwicklungsstrategien sind z. B. das Wasserfallmodell, Prototyping, Inkrementelle Entwicklung, Evolutionäre Entwicklung, Objektorientierte Entwicklung etc. Das Ziel dieser Arbeit ist, festzustellen, auf welche Weise und in welchem Umfang die Entwicklungsstrategie Inkrementelle Entwicklung durch den Standard V-Modell unterstützt wird. Das folgende Kapitel erläutert den Gang der Untersuchung zum Erreichen dieses Zieles. 1

10 1.2 Erläuterung der Vorgehensweise Die Untersuchung verläuft in drei Schritten. Der erste Schritt beinhaltet die überblicksartige Vorstellung des Entwicklungsstandards V-Modell. Nach einer Definition des Begriffes Standard erfolgt die Darstellung und Erläuterung von Inhalt und Zweck des V-Modells. Eine Erörterung der Kritik am V-Modell rundet das Bild ab. Der zweite Schritt beinhaltet die Untersuchung der Entwicklungsstrategie der Inkrementellen Entwicklung von IT-Systemen. Nach einer kurzen Erläuterung des Software Engineering richtet sich das Augenmerk der Untersuchung auf die unterschiedlichen Entwicklungsstrategien. Die Definition des Begriffes Entwicklungsstrategie bildet den Ausgangspunkt. Ein Vergleich mit anderen Entwicklungsstrategien verdeutlicht die Strategie der Inkrementellen Entwicklung und grenzt sie ab. Hierbei erfolgt insbesondere die Abgrenzung der Begriffe inkrementell und evolutionär durch die Darstellung verschiedener Sichtweisen dieser Begriffe. Der dritte Schritt analysiert, wie die Inkrementelle Entwicklung von IT-Systemen durch die Regelungen und Vorgaben des V-Modells unterstützt wird. Das geschieht u. a. anhand der Untersuchung, ob das V-Modell als Entwicklungsstandard für das von Hesse vorgestellte Verfahren der Evolutionären Objektorientierten Softwareentwicklung (EOS) 1 geeignet ist. Ein weiteres Ergebnis ist das Herausstellen der für die Inkrementelle Entwicklung förderlichen und hinderlichen Elemente des V-Modells. Die Zusammenfassung der Ergebnisse bildet den Abschluß der Arbeit. 1.3 Organisatorische Rahmenbedingungen der Arbeit Nach dem Abschluß meines Maschinenbaustudiums an der Universität der Bundeswehr Hamburg 1993, schrieb ich mich als Teilzeitstudent im Wirtschaftswissenschaftlichen Zusatzstudiengang für Ingenieure und Naturwissenschaftler an der FernUniversität Hagen ein. Als Bearbeitungsdauer für die vorliegende Diplomarbeit sind neun Wochen vorgesehen. Sie wurde direkt von Herrn Professor Dr. Gabriel, Ruhr-Universität Bochum betreut. Die Arbeit entstand neben meiner beruflichen Tätigkeit als Programmieroffizier der Marine. 1 vgl. Hesse, W. (1995), Evolutionäre objektorientierte Systementwicklung und Projektmanagement, in: Huber- Wäschle, F. et al. (Hrsg.), GISI 95 - Herausforderungen eines globalen Informationsverbundes für die Informatik, Informatik aktuell, Berlin Heidelberg New York 1995, S. 35 bis 42 2

11 1.4 Danksagung Bei Herrn Professor Dr. Gabriel bedanke ich mich für die Übernahme der Betreuung der Arbeit. Weiterhin bedanke ich mich bei Herrn Professor Dr. Gehring für die Zuteilung einer Diplomarbeit. Herrn Professor Dr. Hesse gilt mein Dank für die Bereitschaft, mir als ihm unbekannten Studenten aufgrund eines -kontaktes bereitwillig Kopien seiner Veröffentlichungen über EOS (Evolutionäre Objektorientierte Softwareentwicklung) zukommen zu lassen. Weiterhin möchte ich mich bei den zahlreichen Korrekturlesern dieser Arbeit für das Aufspüren von Rechtschreib- und Kommafehlern und für die fruchtbare Kritik bedanken. 3

12 2 V-Modell (Entwicklungsstandard für IT-Systeme des Bundes) 2.1 Vorbemerkungen Das V-Modell ist ein umfangreiches, mehrere hundert Seiten umfassendes Werk. Es besteht aus mehreren Teilen und es gibt eine Vielzahl von Zusätzen zu den eigentlichen Regelungen des Standards. Das V-Modell ist in gedruckter Form und als CD erhältlich. Auf der CD zum V-Modell ist eine Kurzbeschreibung enthalten. Sie ist der vorliegenden Arbeit als Anhang beigefügt. Die Kurzbeschreibung kann zusätzlich zu den in diesem Kapitel gemachten Ausführungen hilfreich sein, eine Übersicht über das V-Modell zu gewinnen. Die folgenden Ausführungen zum V-Modell sollen eine Überblick über den Standard schaffen. Zur detaillierteren Darstellung sei auf das V-Modell selbst verwiesen. Besonders betont werden die Aspekte des V-Modells, die für die nachfolgenden Untersuchungen zur Unterstützung der Strategie der Inkrementellen Entwicklung durch das V-Modell von Bedeutung sind. 2.2 Entstehung des V-Modells Das V-Modell wurde vom Bundesamt für Wehrtechnik und Beschaffung (BWB) in Zusammenarbeit mit der Beraterfirma IABG mbh erstellt. Das BWB ist für die materielle Ausrüstung der Streitkräfte zuständig. Es ist somit auch für die Entwicklung von Systemen und Software für die Bundeswehr und die Bundeswehrverwaltung verantwortlich. Bei der Vielzahl der zu betreuenden Entwicklungs- und Beschaffungsprojekte, die mit unterschiedlichsten Vertragspartnern abgewickelt werden, lag es nahe, eine verbindlichen Standard für IT-Projekte herauszugeben. Einen solchen hauseigenen Standard für die Beschaffung von IT-Systemen durchzusetzen, war aufgrund der nicht unerheblichen Nachfragemacht des BWB nicht schwer. Zumal andere NATO-Partner, allen voran das DoD (Department of Defense, USA) mit seinem MIL-STD- 4

13 498 2, Ähnliches taten. Bei der Erstellung des V-Modells orientierte man sich an den neusten Erkenntnissen zum Software Engineering und an den Standards der NATO-Partner. Es wurde eine verbindliche Richtlinie geschaffen, die vom Bundesministerium des Innern (BMI) für dessen Geschäftsbereich übernommen wurde. 2.3 Aufbau des Standards Das V-Modell besteht aus drei Teilen Teil 1 Regelungsteil Teil 2 Behördenspezifische Erweiterungen Bereich Bundesministerium der Verteidigung (BMVg) und Bereich Bundesministerium des Innern (BMI) Teil 3 Handbuchsammlung. Der Standard ist im Bereich des Bundesministeriums der Verteidigung als sog. Allgemeiner Umdruck (AU) veröffentlicht. AU 250 (Teil 1-3) ist des V-Modell. Weiterhin gehören zum Standard die Methodenzuordnung und die Funktionalen Werkzeuganforderungen, sie sind aber separat veröffentlicht. AU 251 ist die Methodenzuordnung, AU 252 die Funktionale Werkzeuganforderungen. Kern des Standards (AU 250) ist der Regelungsteil (Teil 1). Die beiden anderen Teile können als Erläuterung zum Regelungsteil aufgefaßt werden. Der Teil 2 enthält für den Bereich BMI und den Bereich BMVg unterschiedliche Ergänzungen und Erläuterungen. In Teil 3 wird u. a. die Anwendung des V-Modells für verschiedene Anwendungsfälle näher beschrieben. Auf diese Weise soll das Verständnis für die korrekte Anwendung des V-Modells gefördert werden. Auf der CD zum V-Modell sind zusätzlich Beispiele für seine konkrete Anwendung in Entwicklungsprojekten und Produktmuster (Muster für die Ergebnisse von Entwicklungsaktivitäten) enthalten, die nicht zum eigentlichen Umfang des Standards gehören. 2 o. V. (1994), MIL-STD-498: Military Standard: Software Development and Documentation, Department of Defense USA 5 December Dieser Standard wurde am 27. Mai 1998 zurückgezogen und ist jetzt im Standard IEEE/EIA 12207, "Information technology - Software life cycle process" enthalten. 5

14 2.4 Definition des Begriffes Standard Das DIN faßt den Begriff Standard als englische Übersetzung des Begriffes Norm auf. 3 Die Definition des Begriffes Norm nach DIN lautet: Dokument, das mit Konsens erstellt und von einer anerkannten Institution angenommen wurde und das für die allgemeine und wiederkehrende Anwendung Regeln, Leitlinien oder Merkmale für Tätigkeiten oder deren Ergebnisse festlegt, wobei ein optimaler Ordnungsgrad in einem gegebenen Zusammenhang angestrebt wird. 4 Allgemein wird ein Standard als eine Vereinheitlichung betrachtet, die nicht von einer Normungsinstitution herausgegeben wird, sondern sich auf andere Weise am Markt durchgesetzt hat. Die Definition des Begriffes Standard durch den Duden unterstützt diese Sichtweise:... etw., was als mustergültig, modellhaft angesehen wird u. nach dem sich anderes richtet; Richtschnur, Maßstab, Norm... 5 Besonders hervorzuheben ist, daß ein Standard gemäß der Definition des DIN Regeln, Leitlinien oder Merkmale für Tätigkeiten oder deren Ergebnisse festlegt. Genau dies leistet das V- Modell. Es legt, wie im Folgenden noch gezeigt wird, Regeln für die durchzuführenden Tätigkeiten während der Entwicklung von IT-Systemen fest. Diese Tätigkeiten werden im Rahmen des V-Modells als Aktivitäten bezeichnet. Weiterhin legt das V-Modell die Merkmale der Ergebnisse dieser Aktivitäten fest. Das V-Modell entspricht somit der Definition eines Standards. Im folgenden wird die Konzeption des Standards erläutert. 2.5 Standardisierungskonzept Tailoring Das Ziel des V-Modells ist es, für alle Entwicklungen von IT-Systemen eingesetzt werden zu können. Das V-Modell erhebt den Anspruch, allgemeingültig zu sein. Gleich ob eine kleine Büroanwendung mit eigenen Mitteln oder die Steuerung eines Kraftwerkes durch die Vergabe an Dritte entwickelt wird, das V-Modell soll bei beiden wirksam und sinnvoll verwendet werden können. Der Aufwand an Dokumentation und Verwaltung soll genau den jeweiligen Er- 3 o. V. (1994), DIN EN 4502 Allgemeine Fachausdrücke und deren Definition betreffend Normung und damit zusammenhängende Tätigkeiten, Berlin April 1994, S. 12 bis 13 4 ebenda, S o. V. (1989), Duden Deutsches Universalwörterbuch A-Z, 2. Auflage, Wien Zürich 1989, S

15 fordernissen angemessen sein. Eine überflüssige Papierflut soll genauso vermieden werden, wie das Fehlen wichtiger Dokumente. In allen Fällen soll eine lückenlose Dokumentation des Entwicklungsprozesses vorliegen. Diese sich widersprechenden Ansprüche wurden wie folgt gelöst: 1. Das V-Modell enthält einen Maximalansatz an allgemeingültigen Regelungen, die zusammen eine sinnvolle Beschreibung des Entwicklungsprozesses bilden und eine durchgängige Dokumentationskette sicherstellen. 2. Aus diesem Maximalansatz werden die für das jeweilige Projekt sinnvollen Regelungen herausgesucht. Dies geschieht nach Regeln, die im V-Modell selbst enthalten sind. Auf diese Weise wird für jede Art von Projekt eine sinnvolle Vorgehensbeschreibung und durchgängige Dokumentation gewährleistet. Wegen der Eigenschaft, allgemeingültig zu sein und durch ein festgelegtes Verfahren auf jede Projektsituation angepaßt werden zu müssen, wird das V-Modell auch als generisches Modell bezeichnet. Das V-Modell ist ein Standard für alle Fälle, zwingt aber dazu, es stets auf die konkrete Projektsituationen anzupassen. Das Anpassen geschieht weitestgehend bevor der eigentliche Entwicklungsprozeß des Systems beginnt, bei der Planung des Projektes. Das Ergebnis dieses Anpaßvorganges wird, neben der ausgewählten Entwicklungsstrategie, in einem für das jeweilige Projekt spezifischen Projekthandbuch beschrieben. Das Maßschneidern des V-Modells auf ein Projekt wird Tailoring genannt. Es gibt zwei verschiedene Arten, die für ein Projekt sinnvollen Regelungen zu bestimmen. Standardisiertes Vortailoring Beim sog. Standardisierten Vortailoring wird anhand von spezifischen Projektmerkmalen (z. B. Aufwand in Personenjahren u. a.) eine Einteilung von Projekten in Projekttypen vorgenommen (Bild 1). Projekte werden im Sprachgebrauch des V-Modells auch als Vorhaben bezeichnet. Für jeden Typus von Projekt existiert eine musterhafte Ausprägung des V-Modells. Es werden die notwendigen Arbeitsabläufe (Aktivitäten) und Dokumente (Produkte der Aktivitäten) für einen Projekttypus vorgeschlagen. Auf Basis dieses Vorschlages können dann Veränderungen, die für das konkrete Projekt sinnvoll sind, vorgenommen werden. Auf diese Weise wird das projektspezifische Vorgehensmodell erstellt. 7

16 Vorhabenklassen administrative IT-Vorhaben technisch-wissenschaftliche IT-Vorhaben Auswahl, Beschaffung und Anpassung von Fertigprodukten klein mittel groß klein/mittel groß Bild 1 Einteilung der Projekte (Vorhaben) in Typen beim Standardisierten Vortailoring Quelle: o. V. (1997), AU 250/3 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 3 Handbuchsammlung, Juni 1997, S. T-6 Tailoring nach Streichbedingungen Beim Tailoring nach Streichbedingungen durchsucht man das gesamte generische V-Modell nach für das konkrete Projekt sinnvollen Regelungen. Nicht sinnvolle Regelungen werden gestrichen. Dies geschieht nach Streichbedingungen, deren Festlegung im V-Modell beschrieben ist und die hier nicht weiter erläutert werden. Beim Streichen wird unterschieden zwischen solchen Streichungen, die schon zum Zeitpunkt der Projektplanung sicher bestimmt werden können, und potentiellen Streichungen, die sich erst im Projektverlauf ergeben. Dies geschieht durch ein Markieren von Aktivitäten und Produkten dieser Aktivitäten, deren Streichung sich im Projektverlauf ergeben könnte. Bild 2 verdeutlicht die beiden Tailoringverfahren. Es macht deutlich, wie von zwei unterschiedlichen Seiten ein Erzeugen des für das jeweilige Projekt spezifischen Vorgehensmodells aus dem generischen V-Modell bewerkstelligt werden kann. 8

17 Gesamtmenge der Regelungen des V-Modells Tailoring mit Streichbedingungen Streichen von Aktivitäten und Produkten anhand vorgegebener Streichbedingungen Standardisiertes Vortailoring Identifikation der relevanten Aktivitäten und Produkte durch Ermittlung des Vorhabentyps und der charakteristischen Ergänzungen Zusatzanforderungen Basisanforderungen verbliebene Regelungsmenge des Projekthandbuchs Bild 2 Vergleich der beiden Tailoringverfahren Quelle: o. V., AU 250/3 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 3 Handbuchsammlung, Juni 1997, S. T Submodelle Das V-Modell ist aufgeteilt in mehrere Untermodelle, Submodelle genannt (Bild 3). Das V- Modell beschränkt sich somit nicht nur auf die Beschreibung der Software- bzw. Systemerstellung (Submodell SE), sondern betrachtet auch die Bereiche, die neben der Systemerstellung in einem Projekt beachtet werden müssen. Diese Bereiche sind das Projektmanagement (Submodell PM), die Qualitätssicherung (Submodell QS) und das Konfigurationsmanagement (Submodell KM). Auf diese Weise wird eine ganzheitliche, integrierte Betrachtungsweise gewährleistet. Die Systemerstellung wird nicht isoliert betrachtet, sondern mit weiteren organisatorische Festlegungen zur Durchführung des Entwicklungsprojektes verknüpft. Die einzelnen Submodelle werden nachfolgend erläutert. 9

18 Projekt planen und kontrollieren PM Voraussetzungen schaffen und Softwareentwicklungsumgebung (SEU) bereitstellen Plandaten Istdaten SEU Istdaten SEU SEU Plandaten Plandaten Plandaten Istdaten Istdaten SEU QS- Anforderungen vorgeben SE Produkt entwickeln Produktstruktur planen Konfigurationsstruktur QS- Ergebnis Produkte prüfen QS QS-Anforderung Produkt Rechte Produkt Produkte/ Rechte verwalten KM Bild 3 Zusammenspiel der Submodelle Quelle: o. V. (1997), AU 250/1 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 1 Regelungsteil, Juni 1997, S Projektmanagement Das Submodell Projektmanagement beschreibt die Aktivitäten zur Planung, Durchführung und Kontrolle von Entwicklungsprojekten. Dies geschieht durch das Erzeugen eines projektspezifischen Vorgehensmodells (Tailoring). Weiterhin erfolgt auch die Festlegung der Entwicklungsstrategie, z. B. Inkrementelle Entwicklung oder Einsatz/Anpassung von Fertigprodukten. Dies umfaßt eine erste Planung der zeitlichen Abfolge der Aktivitäten für die verschiedenen Teile eines Systems. Die Gliederung eines IT-Systems nach V-Modell in verschiedene Teile, die sog. Segmente, wird später erörtert. Die Zeitliche Einteilung der Aktivitäten steht nicht von vornherein fest, da durch den Standard nur die logische Verknüpfungen der Aktivitäten erläutert werden. So ist es durchaus möglich, zu einem Zeitpunkt im Projekt für verschiedene Segmente des zu entwickelnden IT- Systems unterschiedliche Aktivitäten durchzuführen. Weiterhin regelt das Submodell PM die Festlegung von Werkzeugen (z. B. CASE-Tools) und Methoden der Entwicklung (z. B. Entitiy-Relationship-Modellierung für den Entwurf von relationalen Datenbanken). 10

19 Das Projektmanagement ist ausschließlich technisch orientiert. Das V-Modell enthält keinerlei aufbauorganisatorische Festlegungen zur Durchführung eines Projektes. Auf diese Weise ist das V-Modell unabhängig von der Unternehmensorganisation, in der es eingesetzt wird Systemerstellung Das Submodell Systemerstellung ist der Kern des V-Modells. Hier wird der Verlauf eines Entwicklungsprojektes bei der Erstellung des Systems bzw. der Software beschrieben. Bild 4 zeigt den Ablauf der Systemerstellung. Deutlich ist das V zu erkennen, welches symbolhaft für das V-Modell ist. Die Systemerstellung läuft in mehreren sog. Aktivitäten ab. Die Anzahl dieser Aktivitäten ist von der projektspezifischen Ausprägung des V-Modells abhängig. Die Aktivitäten werden in Bild 4 rechteckig dargestellt. Die Ergebnisse der Aktivitäten, die Produkte, werden in Ellipsen dargestellt. Die logischen Verbindungen der Aktivitäten sind durch die geraden Pfeile dargestellt. Bild 4 zeigt beispielsweise, daß die Produkte der Aktivität SE3 SW-/HW- Anforderungsanalyse, die Technischen Anforderungen und Betriebsinformationen, die Eingangsprodukte für die nächste Aktivität SE 4-SW SW-Grobentwurf sind. Auf diese Weise wird die logische Verknüpfung zwischen den Aktivitäten hergestellt. Die Aktivität der SE 7-SW SW-Integration wiederum prüft (gebogene Pfeile) die Durchführung und Ergebnisse der beiden o. g. Aktivitäten. Die bildliche Darstellung sämtlicher logischer Verknüpfungen führt zu der nicht gerade übersichtlichen Darstellung in Bild 4. Auf diese Weise wird gezeigt, daß die Zusammenhänge der Systemerstellung sehr komplex sind. Bild 4 stellt den Maximalansatz von Aktivitäten, Produkten und logischen Verknüpfungen dar, der sich durch das Tailoring verringert. Der Ablauf der Entwicklung besteht (im Maximalfall) aus den Aktivitäten System-Anforderungsanalyse System-Entwurf SW-/HW - Anforderungsanalyse SW - Grobentwurf SW - Feinentwurf SW - Implementierung 11

20 Externe Vorgaben (AG) Rahmenbedingungen (für SE 1.7) Protokoll System (installiert und in Betrieb) SE 1 System-Anforderungsanalyse SE 1.1 bis SE 1.8 SWPÄ-Konzept SE 9 Überleitung in die Nutzung SE 9.1 bis 9.3 Produktinformationen Kosten-/Nutzenanalyse Angebotsbewertung Anwenderforderungen Betriebsinformationen System (installierbar) SE 2 System-Entwurf SE 2.1 bis SE 2.6 Integrationsplan SE 8 System-Integration SE 8.1 bis SE 8.3 System- Ebene Schnittstellenübersicht Systemarchitektur Schnittstellenbeschreibung Betriebsinformationen Technische Anforderungen SW-Einheit Implementierungsdokumente (SW-Einheit) HW-Einheit Nicht-IT-Anteile SE 3 SW-/HW-Anforderungsanalyse SE 3.1 bis SE 3.5 Betriebsinformationen Technische Anforderungen SE 4-SW SW-Grobentwurf SE 4.1-SW bis SE 4.3-SW SE 7-SW SW-Integration SE 7.1-SW bis SE 7.4-SW Implementierungsdokumente (SW-Komponente) SW-Komponente SW-Einheits-/ HW-Einheits- Ebene SW-Kompo- nenten- Ebene Schnittstellenübersicht Schnittstellenbeschreibung Betriebsinformationen SW-Architektur Datenbank SW-Modul Implementierungsdokumente (SW-Modul, Datenbank) SE 5-SW SW-Feinentwurf SE 5.1-SW und SE 5.2-SW Datenkatalog SW-Entwurf Betriebsinformationen Modul-/Datenbank- Ebene Legende: SE 6-SW SW-Implementierung SE 6.1-SW bis SE 6.3-SW Prüfaktivitäten (siehe QS) Bild 4 Ablauf der Systemerstellung (Submodell SE) Quelle: o. V. (1997), AU 250/1 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 1 Regelungsteil, Juni 1997, S SW - Integration System - Integration Überleitung in die Nutzung 12

21 Diese Hauptaktivitäten sind wiederum in Teilaktivitäten unterteilt. Sowohl von den Haupt- als auch von den Teilaktivitäten können aufgrund des Tailorings verschiedene entfallen. Die Beschreibung der Tätigkeiten in den einzelnen Aktivitäten kann dem V-Modell Teil 1 (Regelungsteil) oder der Kurzbeschreibung des V-Modells (siehe Anhang) entnommen werden Qualitätssicherung Das Submodell QS beschreibt die Qualitätssicherung im Projekt. Die QS geschieht im Rahmen einer (möglichst objektiven) Nachweisführung. Es wird die Erfüllung der in den Anforderungsdokumenten geforderten Eigenschaften des Systems überprüft. Die Anforderungsdokumente sind z. B. das Ergebnis der Systemanforderungsanalyse Konfigurationsmanagement Das Submodell Konfigurationsmanagement (KM) stellt sicher, daß die Produkte, die im Entwicklungsprozeß entstehen (Programmcode und Dokumentation) in ihrem Zustand und in ihrem Zusammenhang stets eindeutig identifizierbar sind. Dies umfaßt insbesondere eine Verwaltung der verschiedenen Versionen der Produkte. Es stellt sicher, daß Änderungen an den Produkten nur kontrolliert vorgenommen werden können (Änderungsmanagement). Um dies umzusetzen, können Produkte in einer Aktivität nur die in Bild 5 dargestellten Zustände geplant, in Bearbeitung, vorgelegt und akzeptiert einnehmen. 6 6 vgl. o. V. (1997), AU 250/1 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 1 Regelungsteil, Juni 1997, S

22 geplant in Bearb. vorgelegt akzeptiert * * Dieser Zustandsübergang wird durch Aktivität KM 3 Änderungsmanagement (Konfigurationssteuerung) verursacht. Dabei entsteht eine neue Produktversion. Bild 5 Mögliche Zustände eines Produktes nach V-Modell Quelle: o. V. (1997), AU 250/1 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 1 Regelungsteil, Juni 1997, S Dreistufige Standardisierung Auf der Basis der oben vorgestellten vier Submodelle wurde eine Standardisierung in drei Stufen vorgenommen.! " # $ % & ' " " ( ) * Bild 6 Dreistufige Standardisierung im V-Modell Quelle: o. V. (1997), V-Modell: Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Kurzbeschreibung, S. 4 Für jedes der vier Submodelle sind Vorgehensweisen, Methoden und Werkzeuganforderungen festgelegt. 14

23 Vorgehensweise ( Was ist zu tun? ) Es erfolgt eine Festlegung der Tätigkeiten im Verlauf der Projektabwicklung. Methoden ( Methodenzuordnung ) 7 ( Wie ist etwas zu tun? ) Hier werden Vorschläge für die Verwendung von Methoden für die festgelegten Aktivitäten gemacht. Das V-Modell enthält für alle Aktivitäten im Entwicklungsprozeß eine Darstellung sämtlicher bekannter Methoden zur Durchführung der verschiedenen Tätigkeiten. Hierbei wird die Methode lediglich beschrieben. Eine Ausbildung in der Anwendung der Methode enthält das V-Modell nicht. Das V-Modell legt keine Entwicklungsmethode verbindlich fest. Insbesondere wird keine Methode der Programmierung oder gar eine Programmiersprache festgelegt. Das V-Modell ist methodenneutral. Werkzeuganforderungen ( Funktionale Werkzeuganforderungen ) 8 ( Womit ist etwas zu tun? ) Es wird festgelegt, welche funktionalen Eigenschaften die Werkzeuge haben müssen, die bei der Projektabwicklung eingesetzt werden. Es werden jedoch keine konkreten Werkzeuge festgelegt. Das V-Modell ist auch in dieser Hinsicht neutral. Die Methodenzuordnung und die Funktionalen Werkzeuganforderungen sind für den Bereich BMI nicht verbindlich Gliederung eines IT-Systems nach V-Modell Ein IT-System gliedert sich aus der Sicht des V-Modells in Segmente, wobei solche mit IT- Anteilen und solche ohne IT-Anteile unterschieden werden. Segmente mit IT-Anteilen bestehen wiederum aus Software-Einheiten und Hardware-Einheiten. Diese Einheiten sind elementare Objekte der Systemarchitektur. 7 vgl. o. V. (1997), AU 251 Entwicklungsstandard für IT-Systeme des Bundes: Methodenzuordnung, Neudruck Juni vgl. o. V. (1997), AU 252 Entwicklungsstandard für IT-Systeme des Bundes: Funktionale Werkzeuganforderungen, Neudruck Juni vgl. Bundesministerium des Innern (1997), Entwicklungsstandard für IT-Systeme des Bundes Vorgehensmodell (V-Modell), Teil 2 Behördenspezifische Ergänzungen, Stand Juni 1997, S

24 Software-Einheiten bestehen aus Modulen und Datenbanken. Hardware-Einheiten bestehen aus Hardware-Komponenten und Hardware-Modulen. Die Aufgliederung eines Systems ist hierarchisch. Hierbei müssen nicht zwingend alle Ebenen der Hierarchie vorhanden sein. Bild 7 stellt diesen Sachverhalt dar. Außerdem wird dargestellt, welche Entwicklungstätigkeiten durch das V-Modell beschrieben werden. IT-System System-Ebene Segment mit IT-Anteil Segment ohne IT-Anteil.. kann entfallen Segment- Ebene Segment mit IT-Anteil Segment ohne IT-Anteil SW-Einheit HW-Einheit SW-Einheits-/ HW-Einheits- Ebene SW-Komponente. kann entfallen HW-Komponente. kann entfallen Komponenten- Ebene SW-Komponente HW-Komponente SW-Modul Datenbank HW-Modul Modul-/ Datenbank- Ebene Entwicklung vollständig durch das V-Modell geregelt Entwicklung in Teil 3 Handbuchsammlung beschrieben (Handbuch Hardwareerstellung ) Bild 7 Gliederung eines IT-Systems nach V-Modell Quelle: o. V. (1997), AU 250/1 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 1 Regelungsteil, Juni 1997, S Einsatz des V-Modells in verschiedenen Organisationen Wie bereits dargestellt, sind die Regelungen im V-Modell unabhängig von der Organisation, in der es eingesetzt wird. Um dennoch eine Zuordnung der Aktivitäten und Aufgaben zu den 16

25 ausführenden Personen herzustellen, wurde das Rollenkonzept entworfen. Die durchzuführenden Aufgaben werden bestimmten Rolleninhabern zugeordnet. Die Qualifikation und das Aufgabenspektrum eines Rolleninhabers sind in der Beschreibung der Rollen festgelegt Weiterentwicklung und Pflege des Standards Eine erste Ausgabe des Standards V-Modell wurde 1992 veröffentlicht. Es liegt jetzt in seiner überarbeiteten Version von Juni 1997 vor. Die Weiterentwicklung des V-Modells wird öffentlich kontrolliert. Sie erfolgt durch eine jährlich tagende Änderungskonferenz mit Behörden und Industrievertretern. Auf diese Weise wird gewährleistet, daß die Anwender des V- Modells bei dessen Weiterentwicklung beteiligt werden. 2.8 Zweck des Standards Im Folgenden werden drei wichtige Aspekte der Verwendung des Standards dargestellt, um die Funktion des Standards zu verdeutlichen Vertragsgrundlage Als einer der größten Abnehmer von Softwareentwicklungen im gesamten Bundeshaushalt ist für das BWB (Bundesamt für Wehrtechnik und Beschaffung) eine einheitliche technische Regelung des Entwicklungsganges bei der Auftragsvergabe wichtig. Dies fällt um so mehr ins Gewicht, da es sich häufig um Spezialsoftware handelt, die konkret auf einen bisweilen einzigartigen Anwendungsbereich zugeschnitten ist. Deshalb wurde vom BWB das V-Modell entwickelt, um eine Vertragsgrundlage zu bilden. Das V-Modell fixiert eindeutig den Entwicklungsprozeß und den Lieferumfang des auszuliefernden Produktes. Insbesondere sorgt es dafür, daß die Dokumentation vollständig ist. Auf diesen Aspekt wird besonders viel Wert gelegt, da auf diese Weise Wartungsmaßnahmen an der Software unterstützt werden. Die Software soll sich lange einsetzen und stets den neuen Erfordernissen anpassen lassen. 10 vgl. o. V. (1997), AU 250/1 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 1 Regelungsteil; Juni 1997, S

26 Außerdem trägt die Anwendung des V-Modells dazu bei, die sichere Funktion der erstellten IT-Systeme zu gewährleisten. Dies ist besonders für die IT-Systeme wichtig, von deren fehlerfreien Funktion Menschenleben abhängen (z. B. Avionik-System eines Flugzeuges) Arbeitsanleitung Das Regelwerk des V-Modells dient als Arbeitsanleitung. Dies ist ein Vorzug, der auch bei Eigenentwicklungen von Vorteil ist. Vor der Durchführung des Projektes wird bei der Planung des Projektes aus dem generischen V-Modell ein projektspezifisches erstellt. Dies bedeutet u. a., daß, wie oben beschrieben, aus den im Regelwerk genannten möglichen Arbeitsschritten, die konkret für das Projekt benötigten Arbeitsschritte ausgewählt werden. Das V-Modell enthält eine detaillierte Beschreibung der Arbeitsschritte (Aktivitäten) und ihrer Ergebnisse, den Produkten. Diese Beschreibung ist möglichst universell gehalten, so daß sie von den konkreten Gegebenheiten eines spezifischen Projektes unabhängig ist und möglichst für alle Arten von Projekten sinnvoll verwendet werden kann. Es ist jedoch möglich und durchaus im Sinne des V-Modells bei der Planung des Projektes auf Basis dieser universellen Beschreibung der Aktivitäten eine spezielle Beschreibung der Aktivitäten für das konkrete Projekt zu erstellen. Die universelle Beschreibung stellt jedoch unabhängig von der Erstellung einer speziellen Beschreibung das Vorhandensein einer Anleitung sicher. Das V-Modell kann wie eine Checkliste für die Systemerstellung verwendet werden, um sicherzustellen, keine Aktivität vergessen oder unvollständig ausgeführt zu haben Kommunikationsbasis Ein nicht zu unterschätzender Vorzug des V-Modells ist die Festlegung einer einheitlichen Terminologie. Auf diese Weise wird die Kommunikation im Rahmen eines Entwicklungsprojektes erheblich verbessert. Die einzelnen Begriffe sind in ihrer Bedeutung (z. B. Anwenderforderung, Systemarchitektur, Softwareeinheit, Hardwareeinheit) festgelegt. Alle Beteiligten haben, so sie Kenntnisse über das V-Modell besitzen, eine gleiche Vorstellung vom Inhalt und Sinn der Begriffe. Neben dieser Wirkung als Kommunikationsbasis durch die Terminologiefestlegung erleichtert das V-Modell auch die Suche nach Informationen über ein konkretes IT-System. Es gibt ver- 18

27 bindlich vor, welche Information über das IT-System wo zu finden ist. Dies geschieht in erster Linie über die sog. Produktmuster. Produkte sind die Ergebnisse von Aktivitäten. Es sind häufig Dokumente. Durch Produktmuster wird festgelegt, wie die einzelnen Dokumente der Entwicklungsdokumentation zu gliedern sind. Dieser Vorzug macht sich vor allen Dingen bei der Wartung des Systems nach Abschluß dessen Entwicklung positiv bemerkbar. Mit Kenntnis des V-Modells können an der Entwicklung Unbeteiligte die für die Wartung notwendigen Informationen leicht auffinden. 2.9 Verbreitung und wirtschaftliche Bedeutung des V-Modells Das V-Modell wurde, wie oben dargestellt, zwar für die Belange der Bundeswehr bzw. Bundesverwaltung erstellt, ist aber nicht auf diesen Anwendungsbereich fixiert. Es ist völlig unabhängig von der Organisationsstruktur, in der es eingesetzt wird (z. B. durch das Rollenkonzept). Das V-Modell kann überall eingesetzt werden, wo Software bzw. IT-Systeme entwickelt werden. Seine Herkunft als Entwicklungsstandard für Projekte zur Entwicklung von Spezialsoftware ist allerdings unverkennbar. Die Anwendung des V-Modells unterliegt keinerlei Nutzungsrechten. Der Standard ist ohne Lizenzgebühr erhältlich. Es ist offenbar im Sinne des BWB, wenn das V-Modell weite Verbreitung findet, da somit bei der Auswahl von Vertragspartnern auf ein weit verbreitetes Know How zurückgegriffen werden kann. Es stehen auf diese Weise mehr potentielle Vertragspartner zur Verfügung, als wenn nur wenige Spezialanbieter die notwendigen Erfahrungen mit dem V-Modell hätten. Die einfache Verfügbarkeit wird auch durch die Tatsache unterstützt, daß das V-Modell auf CD erhältlich ist. Alle Teile des Standards sind auf dieser CD im WINWORD-Format vorhanden. Dies erleichtert die Arbeit mit dem V-Modell im Rahmen eines IT-Projektes enorm. Die notwendigen Bestandteile lassen sich leicht kopieren. Mit Hilfe der enthaltenen Beispiele und Muster wird die Erstellung eigener Dokumente erleichtert. Zusätzlich enthält die CD eine Vielzahl von Informationen über das V-Modell, sein Umfeld und über dessen Einsatz. Sie enthält außerdem eine multimediale Anleitung in der Anwendung des V-Modells. Industrieunternehmen sind im Rahmen der Zertifizierung nach ISO 900x gezwungen, eine Ablaufbeschreibung ihrer Entwicklungsprozesse zu erstellen. Das V-Modell ist eine solche Ablaufbeschreibung. Somit trägt die Anwendung des V-Modells als Werkstandard zur Zertifizierung nach ISO 900x bei. 19

28 Auf Grund der genannten Vorteile wird das V-Modell inzwischen in vielen Bereichen der Industrie, bei Banken und Versicherungen verwendet, bzw. dient als Vorlage für die Erstellung eigener Werksstandards zur IT-Systementwicklung Erörterung der Kritik am V-Modell Seit seiner Herausgabe wurde das V-Modell in der Fachliteratur und von Anwendern kritisch begutachtet. Dieses Kapitel enthält die Erörterung häufig genannter Kritikpunkte am V-Modell. Das Hauptaugenmerk der Kritik richtet sich auf den Umfang der durch den Standard geforderten Dokumentation eines Systems. Auch die Durchführung eines kleinen Projekts erfordert eine Auseinandersetzung mit einer auf den ersten Blick sehr großen Anzahl von Dokumenten. Somit liegt der Vorwurf auf der Hand, das V-Modell führe zu einer unnötigen Produktvielfalt und zu einer Software-Bürokratie. 12 Außerdem wird die große Vielzahl der Regelungen bemängelt. Dem V-Modell wird deshalb seine Eignung nur für Großprojekte zugesprochen. Der Kritik kann nur teilweise zugestimmt werden. Es ist zutreffend, daß der gewaltige Umfang des Standards und die Komplexität der Regelungen zunächst einmal abschrecken. Der Umfang ergibt sich offensichtlich auch daraus, daß die Ersteller des V-Modells umfangreiche Erläuterungen gewählt haben, um auch in der IT-Systementwicklung Unerfahrenen eine Anwendung des Standards zu ermöglichen. Die Erläuterungen finden sich vor allem in der Handbuchsammlung (Teil 3). Sie sind für Fachleute nicht in jedem Fall unbedingt erforderlich. Als eigentliche Standardisierung ist der Teil 1 des Standards (Regelungsteil) ausreichend. Ein Einbeziehen von Teil 2 (Behördenspezifische Ergänzungen) und Teil 3 (Handbuchsammlung) fördert jedoch das Verständnis für die richtige Anwendung des V-Modells. Außerdem neigen Mitarbeiter von Behörden dazu, das V-Modell als Vorschrift derart aufzufassen, daß alles gemacht werden muß, was im V-Modell steht. Es wird kein sachdienliches 11 vgl. Kaindl, H. et al. (1998), Methodik der Softwareentwicklung, Vorgehensmodell und State-of-the-Art der professionellen Praxis, Braunschweig Wiesbaden Balzert, H. (1998), Lehrbuch der Software-Technik: Software-Management Software-Qualitätssicherung Unternehmensmodellierung, Heidelberg Berlin 1998, S

29 Tailoring durchgeführt. Dies stellt auch Dröschel vom Bundesamt für Wehrtechnik und Beschaffung (BWB) fest: Durch eine zu formale Anwendung des Standards wurden leidvolle und kostenträchtige Wege eingeschlagen, die einen Lernprozeß beim Anwender des Standards bewirkt haben. 13 Ein solcher Mißbrauch des V-Modells führt aufgrund der Überdosis von Regelungen genauso zum Mißerfolg wie planloses, unstrukturiertes Vorgehen. Bei der Durchführung der Projektplanung nach den Vorgaben des V-Modells entsteht zu Beginn der Eindruck, daß die Regelungen des V-Modells zu komplex sind und zu viele Dokumente in Verlauf der Entwicklung erstellt werden müssen. Der Eindruck wird dadurch erweckt, daß vor Beginn der eigentlichen Systemerstellung am grünen Tisch eine Auseinandersetzung mit den allgemeingültigen, komplexen Regelungen des V-Modells stattfindet. Außerdem muß der Umfang der Dokumentation festgelegt werden. Bei der Betrachtung im nachhinein stellt sich oft heraus, daß alle Dokumente (die sog. Produkte) wohl begründet waren. Die Möglichkeit, die Projektplanung während der Durchführung des Projektes zu ändern, wird durch den Standard nicht eingeschränkt. Insofern ist ein Verzicht auf die Durchführung einer Aktivität und die Erstellung eines Produktes während des Verlaufes der IT-Systemerstellung jederzeit möglich. Ein weiterer damit zusammenhängender Aspekt ist die Behauptung, wegen der Komplexität sei das V-Modell nur mit CASE-Unterstützung zu handhaben 14. Zu dieser Kritik ist festzustellen, daß es jedoch gerade die Leistung des V-Modells ist, gezwungen zu werden, gleich am Anfang eines Projektes sinnvolle Festlegungen zu treffen und umfangreiche Überlegungen über den Projektverlauf anstellen zu müssen. Nur dies sichert eine Chance auf einen Projekterfolg. Das Tailoring des generischen V-Modells auf das spezifische Vorgehensmodell des Projektes, welches die Komplexität der Regelungen reduziert, ist sicherlich nicht in jedem Fall einfach durchzuführen. Ob dafür in jedem Falle ein CASE-Tool erforderlich ist, sei dahingestellt. 13 Dröschel, W. (1998), Die Gestaltung von IT-Systemen mit V-Modell 97: Zielsetzung und Kernpunkt der Änderungen, in: Dröschel, W. et al. (Hrsg.), Inkrementelle und objektorientierte Vorgehensweise mit dem V- Modell 97, München Wien 1998, S vgl. Balzert, H. (1998), Lehrbuch der Software-Technik: Software-Management Software-Qualitätssicherung Unternehmensmodellierung, Heidelberg Berlin 1998, S

30 Als weiterer Nachteil wird empfunden, daß für jedes Projekt immer eine eigenes V-Modell aus dem generischen maßgeschneidert werden muß, diese Arbeit also immer wieder anfällt. 15 Hinsichtlich solcher Kritik kann auf das Standardisierte Vortailoring für verschiedene Projekttypen und die im V-Modell enthaltenen Musterprojektbeschreibungen und -handbücher verwiesen werden. Es ist jedoch auch möglich, diesen Sachverhalt positiv zu bewerten: Es wird vermieden, daß die spezifischen Eigenheiten einzelner Projekte nicht hinreichend berücksichtigt werden. Ein weiterer Kritikpunkt ist der nationale Charakter des V-Modells. Bei Systementwicklungsprojekten auf multinationaler Ebene sind deshalb Vorbehalte gegen den Einsatz des V- Modells möglich. Dies betrifft z. B. Projekte auf europäischer Ebene. Die Beziehungen zu anderen Standards und der Vergleich mit diesen ist im V-Modell selbst beschrieben. 16 Dennoch wäre es wünschenswert, wenn das V-Modell auch ein Standard zumindest auf europäischer Ebene wäre. Der erste Schritt der Diplomarbeit, die überblicksartige Vorstellung des V-Modells ist mit dieser Erörterung der Kritik abgeschlossen. Im nun folgenden zweiten Schritt werden die verschiedenen Entwicklungsstrategien im Rahmen des Software Engineering untersucht. 15 vgl. Kaindl, H. et al. (1998), Methodik der Softwareentwicklung, Vorgehensmodell und State-of-the-Art der professionellen Praxis, Braunschweig Wiesbaden 1998, S vgl. o. V. (1997), AU 250/2 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell: Teil 2 Behördenspezifische Ergänzungen, Juni 1997, S. 6-1 bis

31 3 Entwicklungsstrategien beim Software Engineering 3.1 Software-Engineering Bevor eine Auseinandersetzung mit den Entwicklungsstrategien beim Software Engineering stattfinden kann, muß der Begriff Software Engineering erläutert werden Historisches (Softwarekrise) Als Softwarekrise wird die Situation bezeichnet, die sich Ende der sechziger bis Anfang der siebziger Jahre ergab. Die inzwischen gestiegenen Ansprüche an die Leistungsfähigkeit der Software konnten mit den bis dahin gebräuchlichen Programmiertechniken nicht mehr realisiert werden. Häufig wird das bis dahin praktizierte Vorgehen bei der Erstellung von Software als Code and Fix bezeichnet. 17 Ohne nähere Spezifikation des zu erwartenden Ergebnisses wird Programmcode geschrieben. Danach wird versucht, die Fehler zu beseitigen. Die Krise wurde dadurch ausgelöst, daß die Leistungsfähigkeit der Hardware in rasantem Maße zunahm. Diese Leistungsfähigkeit sollte durch die Programmierer natürlich ausgenutzt werden - es wurden Software-Lösungen für immer komplexer werdende Systeme verlangt. In der Programmierung herrschte jedoch bis dahin eine laufzeiteffiziente und speicherplatzsparende Vorgehensweise vor. Noch bis zum heutigen Tage fließen in die Beurteilung von Algorithmen und Software diese beiden Kriterien mit ein. Sie waren durch die Hauptbeschränkungen der damaligen Zeit, nämlich knappen CPU- und Speicherplatzkapazitäten, auch gerechtfertigt. Das führte zu der sog. maschinennahen Programmierung. Sie war darauf ausgerichtet war, die knappen Maschinenressourcen optimal auszunutzen. Die Folge war eine trickreiche Programmierung, die nur für den Ersteller des Programmes zu durchschauen war. Häufig waren die Anforderungen an die Leistungen der Software auch so gering, daß die Programmierung der Lösung von einigen wenigen Personen in relativ kurzer Zeit vorgenommen werden konnte. Die gestiegenen Hardware-Möglichkeiten eröffneten den Weg zur Unterstützung von komplexeren Problemen durch Software. An der softwaretechnischen Lösung dieser Probleme wa- 17 vgl. Boehm, B. (1988), A Sprial Modell of Software Development and Enhancement, IEEE Computer May 1988, S. 61 und 62 23