Diplomarbeit Vergleichsmethoden für Vorgehensmodelle bearbeitet von Christian Filß Matrikelnummer: 278 12 76 geboren am 16. Mai 1981 in Gotha Fakultät Informatik Institut für Software und Multimediatechnik Lehrstuhl Programmierumgebungen & Werkzeuge Betreuer: Verantw. Hochschullehrer: Dr. Jan Zöllner Prof. Dr. - Ing. habil. Rüdiger Liskowsky Eingereicht am 23. März 2005.
Aufgabenstellung II
III
Inhaltsverzeichnis Aufgabenstellung... II Inhaltsverzeichnis... IV Abkürzungsverzeichnis... VII Abbildungsverzeichnis... IX Tabellenverzeichnis...X 1 Einleitung...1 2 Begriffsklärung und Abgrenzung...2 3 Grundlagen wichtiger Vorgehensmodelle...4 3.1 Rational Unified Process...4 3.1.1 Überblick...4 3.1.2 Phasenstruktur...7 3.1.3 Prozessbestandteile...10 3.1.4 Werkzeugunterstützung...12 3.2 V - Modell XT...13 3.2.1 Überblick...13 3.2.2 Phasenstruktur...16 3.2.3 Prozessbestandteile...20 3.2.4 Werkzeugunterstützung...21 3.3 SAP Product Innovation Lifecycle...22 3.3.1 Überblick...22 3.3.2 Phasenstruktur...23 4 Bestehende Vergleichsansätze...25 4.1 Einordnung nach Dr. Gerhard Chroust...25 4.1.1 Überblick...25 4.1.2 Vergleichskriterien...26 4.1.3 Bewertung...30 4.2 GERAM...31 4.2.1 Überblick...31 4.2.2 Vergleichskriterien...31 4.2.3 Bewertung...34 4.3 Zachmann Framework...34 4.3.1 Überblick...34 4.3.2 Vergleichskriterien...35 4.3.3 Bewertung...37 4.4 Weitere Vergleichsansätze...38 5 Vergleichskriterien / Dimensionen...40 5.1 Überblick...40 5.2 Definierende Dimensionen...42 5.3 Nichtdefinierende Dimensionen...44 5.4 Zusammenfassung...45 6 Vergleichsrahmen...47 6.1 Definierende Dimensionen...47 IV
6.1.1 Ausprägungen...47 6.1.1.1 Phasenabdeckung...47 6.1.1.2 Prozessabdeckung...48 6.1.1.3 Formalisierung...50 6.1.1.4 Abstraktionsstufe...51 6.1.1.5 Branchenfokus...52 6.1.1.6 Objektdomäne...53 6.1.1.7 Vorgehensweise...55 6.1.1.8 Prozesssteuerung...57 6.1.2 Graphische Darstellung...58 6.1.2.1 Allgemeine Eigenschaften von Vorgehensmodellen...60 6.1.2.2 Softwarespezifische Eigenschaften von Vorgehensmodellen...62 6.2 Nichtdefinierende Dimensionen...64 6.2.1 Ausprägungen...64 6.2.1.1 VM-Präsentation...64 6.2.1.2 Werkzeugbindung...65 6.2.1.3 Toolsupport...65 6.2.1.4 Automatisierungsgrad...66 6.2.1.5 QS-Beitrag...67 6.2.1.6 Systemhierarchie...68 6.2.2 Graphische Darstellung...69 6.3 Weitere Vergleichskriterien...73 6.3.1 Terminologie...73 6.3.2 Prozessarchitektur...75 7 Quantifizierung...76 7.1 Allgemeine Quantifizierung...77 7.1.1 Definierende Dimensionen...77 7.1.1.1 Quantifizierung...77 7.1.1.2 Graphisches Modell...81 7.1.2 Nichtdefinierende Dimensionen...85 7.1.2.1 Quantifizierung...85 7.1.2.2 Graphisches Modell...89 7.2 Individuelle Quantifizierung...91 8 Anwendung...96 8.1 Terminologie...96 8.2 Rational Unified Process...97 8.2.1 Definierende Dimensionen...97 8.2.1.1 Untersuchung...97 8.2.1.2 Graphische Darstellung...100 8.2.1.3 Allgemeine Quantifizierung...101 8.2.1.4 Individuelle Quantifizierung...102 8.2.2 Nichtdefinierende Dimensionen...103 8.2.2.1 Untersuchung...103 8.2.2.2 Graphische Darstellung...105 8.2.2.3 Quantifizierung...106 8.3 V - Modell XT...107 8.3.1 Definierende Dimensionen...107 8.3.1.1 Untersuchung...107 8.3.1.2 Graphische Darstellung...110 V
8.3.1.3 Allgemeine Quantifizierung...111 8.3.1.4 Individuelle Quantifizierung...112 8.3.2 Nichtdefinierende Dimensionen...113 8.3.2.1 Untersuchung...113 8.3.2.2 Graphische Darstellung...115 8.3.2.3 Quantifizierung...115 8.4 Product Innovation Lifecycle...116 8.4.1 Definierende Dimensionen...117 8.4.1.1 Untersuchung...117 8.4.1.2 Graphische Darstellung...118 9 Bewertung und Ausblick...120 Anhang A...122 Anhang B...123 Anhang C...124 Anhang D...125 Anhang E...126 Literaturverzeichnis...128 Selbstständigkeitserklärung...133 VI
Abkürzungsverzeichnis AK-VM AN BMI BMVg CMM CMMI EP GERA GERAM GI IFAC IFIP ISO KBSt PIL Q-Gate QS RA RC RM RUP Arbeitskreis Vorgehensmodelle - Übersicht und Vergleich der GI Fachgruppe WI-VM Arbeitnehmer Bundesministerium des Innern Bundesministerium für Verteidigung Capability Maturity Model Capability Maturity Model Integration Entscheidungspunkt Generic Enterprise Reference Architecture Generalised Enterprise Reference Architecture and Methodology Gesellschaft für Informatik e.v. International Federation of Automatic Control International Federation for Information Processing International Standards Organisation Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung Product Innovation Lifecycle (SAP Vorgehensmodell) Quality-Gate Qualitätssicherung Risk Assesment Readiness Control Risk Monitoring Rational Unified Process VII
UI VM WI Zachmann Framework User Interface Vorgehensmodell Wirtschaftsinformatik Zachmann Framework for Enterprise Architecture VIII
Abbildungsverzeichnis Abbildung 3-1: Iterative Softwareentwicklung, Quelle: [Rati03]... 6 Abbildung 3-2: Phasenstruktur des RUP, Quelle: [GaMP04]... 7 Abbildung 3-3: Phasen und Meilensteine, Quelle: [Rati03]... 8 Abbildung 3-4: Zusammenspiel der RUP Kernelemente, Quelle: [Rati03]... 12 Abbildung 3-5: Gesamtstruktur des V - Modell XT, Quelle: [KBSt04]... 16 Abbildung 3-6: Entscheidungspunkte des V - Modell XT, Quelle: [KBSt04]... 17 Abbildung 3-7: Vorgehensbausteine für Systementwicklung eines AN, Quelle: [KBSt04]... 17 Abbildung 3-8: Inkrementelle Systementwicklung mit dem V - Modell XT, Quelle: [KBSt04]... 19 Abbildung 3-9: Bestandteile eines V - Modell-Vorgehensbaustein, Quelle: [KBSt04]... 21 Abbildung 3-10: Phasenstruktur des PIL, Quelle: [Ecke03]... 23 Abbildung 3-11: Risikomanagement im PIL, Quelle: [Ecke03]... 24 Abbildung 4-1: Das Zachmann Framework, Quelle: [Vill03]... 37 Abbildung 6-1: Graphisches Modell des AK-VM, definierende Dimensionen, Quelle: [AKVM05]... 59 Abbildung 6-2: Allgemeine, definierende Eigenschaften von Vorgehensmodellen... 60 Abbildung 6-3: Beispiel für die allgemeinen, definierenden Eigenschaften von Vorgehensmodellen... 61 Abbildung 6-4: Softwarespezifische, definierende Eigenschaften von Vorgehensmodellen... 62 Abbildung 6-5: Beispiel für die softwarespezifischen, definierenden Eigenschaften von Vorgehensmodellen... 63 Abbildung 6-6: Graphisches Modell des AK-VM, nichtdefinierende Dimensionen, Quelle: [AKVM05] 70 Abbildung 6-7: Nichtdefinierende Eigenschaften von Vorgehensmodellen... 71 Abbildung 6-8: Beispiel für die nichtdefinierenden Eigenschaften von Vorgehensmodellen... 72 Abbildung 7-1: Beispiel eines Kiviat-Graphs, Quelle: [PGFL05]... 76 Abbildung 7-2: Kiviat-Graph der allgemeinen Quantifizierung, definierende Dimensionen... 83 Abbildung 7-3: Beispiel für eine allgemeine Quantifizierung, definierende Dimensionen... 84 Abbildung 7-4: Kiviat-Graph der allgemeinen Quantifizierung, nichtdefinierende Dimensionen... 89 Abbildung 7-5: Beispiel für eine allgemeine Quantifizierung, nichtdefinierende Dimensionen... 90 Abbildung 7-6: Kiviat-Graph der individuellen Quantifizierung... 93 Abbildung 7-7: Beispiel für eine individuelle Quantifizierung... 95 Abbildung 8-1: Allgemeine, definierende Eigenschaften des RUP... 100 Abbildung 8-2: Softwarespezifische, definierende Eigenschaften des RUP... 101 Abbildung 8-3: Allgemeine Quantifizierung der definierenden Eigenschaften des RUP... 102 Abbildung 8-4: Individuelle Quantifizierung des RUP gemäß Tabelle 7-17... 103 Abbildung 8-5: Nichtdefinierende Eigenschaften des RUP... 105 Abbildung 8-6: Quantifizierung der nichtdefinierenden Eigenschaften des RUP... 106 Abbildung 8-7: Allgemeine definierende Eigenschaften des V - Modell XT... 110 Abbildung 8-8: Softwarespezifische definierende Eigenschaften des V - Modell XT... 111 Abbildung 8-9: Allgemeine Quantifizierung der definierenden Eigenschaften des V - Modell XT... 112 Abbildung 8-10: Individuelle Quantifizierung des V - Modell XT gemäß Tabelle 7-17... 113 Abbildung 8-11: Nichtdefinierende Eigenschaften des V - Modell XT... 115 Abbildung 8-12: Quantifizierung der nichtdefinierenden Eigenschaften des V - Modell XT... 116 Abbildung 8-13: Allgemeine definierende Eigenschaften des PIL... 118 Abbildung 8-14: Softwarespezifische definierende Eigenschaften des PIL... 119 IX
Tabellenverzeichnis Tabelle 3-1: Deutsche Übersetzung der Best Practices... 5 Tabelle 3-2: Deutsche Übersetzung der Phaseneinteilung... 8 Tabelle 3-3: Deutsche Übersetzung der neun Core-Workflows... 10 Tabelle 3-4: IBM Rational Software Produkte, nach: [Gorn01]... 13 Tabelle 4-1: Reifestadien des Softwareentwicklungsprozesses, nach: [Chro92]... 26 Tabelle 4-2: Niveaus von Vorgehensmodellen, nach: [Chro92]... 27 Tabelle 4-3: Realisationsstufen, nach: [Chro92]... 28 Tabelle 4-4: Beschreibungsformen, nach: [Chro92]... 29 Tabelle 4-5: Entwicklungsniveaus, nach: [Chro92]... 30 Tabelle 4-6: GERAM - Phasen des Lebenszyklus... 32 Tabelle 4-7: Model Content View, nach: [IFIP99]... 33 Tabelle 4-8: Purpose View, nach [IFIP99]... 33 Tabelle 4-9: Implementation View, nach: [IFIP99]... 34 Tabelle 4-10: Physical Manifestation View, nach: [IFIP99]... 34 Tabelle 4-11: Perspektiven des Zachmann Framework, nach: [Vill03]... 36 Tabelle 4-12: Fokusse des Zachmann Framework, nach: [Vill03]... 36 Tabelle 4-13: Vergleichskriterien, nach: [NoSc99]... 39 Tabelle 5-1: Im Folgenden zu untersuchende Dimensionen... 42 Tabelle 6-1: Ausprägungen der Phasenabdeckung... 48 Tabelle 6-2: Ausprägungen der Prozessabdeckung... 50 Tabelle 6-3: Ausprägungen der Formalisierung... 51 Tabelle 6-4: Ausprägungen der allgemeinen Abstraktionsstufe... 52 Tabelle 6-5: Ausprägungen des Formalisierungsgrades...52 Tabelle 6-6: Ausprägungen des Branchenfokus... 53 Tabelle 6-7: Ausprägungen der allgemeinen Objektdomäne... 54 Tabelle 6-8: Ausprägungen der softwarespezifischen Objektdomäne... 55 Tabelle 6-9: Ausprägungen der Prozessvorgehensweise... 56 Tabelle 6-10: Ausprägungen der Programmiervorgehensweise... 57 Tabelle 6-11: Ausprägungen der Prozesssteuerung... 57 Tabelle 6-12: Beispiel einer graphischen Darstellung mit Tabellen, Quelle: [AKVM05]... 58 Tabelle 6-13: Ausprägungen der VM-Präsentation... 64 Tabelle 6-14: Ausprägungen der Werkzeugbindung...65 Tabelle 6-15: Ausprägungen des Toolsupport... 66 Tabelle 6-16: Ausprägungen des Automatisierungsgrades... 67 Tabelle 6-17: Ausprägungen des QS-Beitrags... 68 Tabelle 6-18: Ausprägungen der Systemhierarchie... 69 Tabelle 6-19: Wesentliche Beschreibungselemente, nach [NoSc99]... 74 Tabelle 7-1: Quantifizierung der Sprachformalisierung... 79 Tabelle 7-2: Quantifizierung der Darstellungsform... 79 Tabelle 7-3: Quantifizierung des Formalisierungsgrades... 80 Tabelle 7-4: Quantifizierung des Branchenfokus... 80 Tabelle 7-5: Wertebereiche der allgemein quantifizierbaren, definierenden Dimensionen... 82 Tabelle 7-6: Anwendungsbeispiel allgemeine Quantifizierung, definierende Dimensionen... 84 Tabelle 7-7: Quantifizierung der VM-Präsentation... 85 Tabelle 7-8: Quantifizierung der Werkzeugbindung... 86 Tabelle 7-9: Quantifizierung des Toolsupports... 87 Tabelle 7-10: Quantifizierung des Automatisierungsgrads... 87 Tabelle 7-11: Quantifizierung des QS-Beitrags... 88 Tabelle 7-12: Quantifizierung der Systemhierarchie... 88 Tabelle 7-13: Wertebereiche der allgemein quantifizierbaren, nichtdefinierenden Dimensionen... 89 Tabelle 7-14: Anwendungsbeispiel allgemeine Quantifizierung, nichtdefinierende Dimensionen... 90 Tabelle 7-15: Prioritätentabelle der individuellen Quantifizierung, inklusive Beispiel... 93 Tabelle 7-16: Beschreibende Tabelle der individuellen Quantifizierung... 94 Tabelle 7-17: Anwendungsbeispiel individuelle Quantifizierung... 95 Tabelle 8-1: Terminologievergleich der Vorgehensmodelle... 97 Tabelle 8-2: Definierende Eigenschaften des RUP... 100 Tabelle 8-3: Allgemeine Quantifizierung der definierenden Eigenschaften des RUP... 102 Tabelle 8-4: Individuelle Quantifizierung des RUP gemäß Tabelle 7-17... 103 X
Tabelle 8-5: Nichtdefinierende Eigenschaften des RUP... 105 Tabelle 8-6: Quantifizierung der nichtdefinierenden Eigenschaften des RUP... 106 Tabelle 8-7: Definierende Eigenschaften des V - Modell XT... 109 Tabelle 8-8: Allgemeine Quantifizierung der definierenden Eigenschaften des V - Modell XT... 112 Tabelle 8-9: Individuelle Quantifizierung des V - Modell XT gemäß Tabelle 7-17... 112 Tabelle 8-10: Nichtdefinierende Eigenschaften des V - Modell XT... 114 Tabelle 8-11: Quantifizierung der nichtdefinierenden Eigenschaften des V - Modell XT... 116 Tabelle 8-12: Definierende Eigenschaften des PIL... 118 XI
1 Einleitung Wir bauen Software wie Kathedralen: Zuerst bauen wir Dann beten wir. (Quelle: [Chro92]) Dieses Zitat von 1992 spiegelt auch heute noch die Probleme moderner Softwareentwicklung wider. Die zunehmende Komplexität der Projekte und die Notwendigkeit der Umsetzung von Qualitätsmerkmalen sind kennzeichnend für die Softwarebranche. Zur Handhabung derart komplexer Softwareentwicklungsprojekte dienen Vorgehensmodelle. Sie gliedern die Entwicklung in überschaubare Einheiten und zielen durch Mechanismen der effektiven Projektsteuerung und -planung auf eine qualitativ hochwertige Umsetzung des Projekts. Die Vielzahl der existierenden Vorgehensmodelle wirft jedoch ein neues Problem auf, die Frage, welches Modell für welchen Einsatzzweck anzuwenden ist. Eine Notwendigkeit zur Lösung dieses Problems ist eine effektive Vergleichsmöglichkeit für Vorgehensmodelle. Das Ziel dieser Arbeit besteht in der Ausarbeitung eines solchen Vergleichsrahmens, der eine Möglichkeit der Klassifizierung von Vorgehensmodellen gibt und somit eine Auswahlentscheidung ermöglicht. Die Aktualität dieses Themas zeigt sich ebenfalls in der Wirtschaft. Innerhalb der Gesellschaft für Informatik wurde ein Arbeitskreis mit dem Titel Vorgehensmodelle - Übersicht und Vergleich (kurz: AK-VM) gebildet, in dem der Autor dieser Arbeit als aktives Mitglied beteiligt ist. Das durch den AK-VM erarbeitete Modell bildet teilweise die Grundlage dieser Arbeit. Im weiteren Vorgehen werden anfangs die grundlegenden Begrifflichkeiten bzw. die verschiedenen Bezeichnungen für Vorgehensmodelle erläutert. Darauf aufbauend erfolgt die Darstellung einiger wichtiger Repräsentanten. Bevor anschließend der eigentliche Vergleichsrahmen gebildet wird, erfolgt eine Zusammenfassung der bisher gefundenen Ansätze. Darauf aufbauend wird der Versuch einer Quantifizierung unternommen. Abschließend erfolgt die Anwendung des Rahmens auf die vorgestellten Vorgehensmodelle und eine zusammenfassende Bewertung. Alle im Rahmen dieser Arbeit verwendeten Markennamen sind eingetragene Warenzeichen der vertreibenden Institutionen oder Unternehmen. 1
2 Begriffsklärung und Abgrenzung Ziel der Anwendung von Vorgehensmodellen ist die Steigerung der Qualität der Software und der Effektivität der Entwicklung. Der Begriff des Vorgehensmodells wird dabei jedoch meist unterschiedlich verwendet. Weiterhin existiert eine Vielzahl weiterer, mit Vorgehensmodellen verknüpften, Bezeichnungen, wie beispielsweise Prozessmodell und Phasenmodell. Ziel dieses Kapitels ist es, einige ausgewählte Termini zu definieren und entsprechend voneinander abzugrenzen. Vorgehensmodell Nach [Lisk04a] dient ein Vorgehensmodell der Vorgabe von zu unterscheidenden Tätigkeiten und den von ihnen erzeugten Ergebnissen sowie deren Zusammenspiel. Prozessmodell / Softwareprozessmodell (nach [Lisk04b]) Ein Prozessmodell definiert den Ablauf der Softwareentwicklung als idealisierten Prozess unter Anwendung formaler Beschreibungsmittel. Ein konkreter Softwareentwicklungsprozess ist Instanz eines Prozessmodells. Phasenmodell Ein Phasenmodell definiert, nach [Lisk04a], Tätigkeiten und ihre Verknüpfungen beim Ablauf großer Softwareentwicklungsvorhaben. Prozessreifemodell / Reifegradmodell / Benchmarkingmodell Ein Reifegradmodell stellt eine Auswahl von Kriterien mit Ziel der Beurteilung der Qualität des Softwareentwicklungsprozesses zusammen. Best Practices Unter Best Practices werden bestimmte Tätigkeiten oder Paradigmen verstanden, die sich in der Softwareentwicklung als praktikabel herausgestellt haben. Gemäß diesen Definitionen scheint die Abgrenzung der Begrifflichkeiten recht einfach, jedoch ist die Verwendung in der Praxis wesentlich schwieriger. Vor allem die Unterscheidung zwischen Vorgehensmodell und Softwareprozessmodell gestaltet sich problematisch. Dies rührt aus der Übersetzung des englischen Begriffes software process model, welcher synonym für seine eigentliche Übersetzung, Softwareprozessmodell 2
und Vorgehensmodell, verwendet wird. Beispielsweise ist der Rational Unified Process im Deutschen als Vorgehensmodell und in der originalen englischen Bezeichnung als Softwareprozessmodell bezeichnet. Im Weiteren soll das Zusammenspiel dieser Begriffe so verstanden werden, dass ein Vorgehensmodell neben dem eigentlichen Softwareentwicklungsprozess noch weitere Aktivitäten unterstützt. Das Softwareprozessmodell ist somit ein Teil des Vorgehensmodells, dessen Anwendung den eigentlichen Softwareentwicklungsprozess bildet. Die Ausgestaltung des Prozessmodells kann dabei variieren, wodurch auch weitere Verletzungen der Definition entstehen können, da es nicht immer formal definiert sein muss. Ein Phasenmodell, als Definition der Aneinanderreihung von Tätigkeiten bzw. Phasen, ist ebenfalls ein Submodell eines Vorgehensmodells. Es muss nicht explizit in dieser Form ausdefiniert sein. Durch die Festlegung von bestimmten Aktivitäten und deren Abfolge in einem Vorgehensmodell liegt jedoch stets ein implizites Phasenmodell zu Grunde. Ein Reifegradmodell dient der Untersuchung der Qualität, die durch den Einsatz eines bestimmten Softwareentwicklungsprozesses erreicht werden kann. Mitunter gehen diese Modelle jedoch auch weiter. Beispielsweise werden im Rahmen von CMMI, das hauptsächlich ein Reifegradmodell ist, auch diverse, so genannte Best Practices vorgeschlagen, um die gewünschte Qualität zu erreichen. Diese Sammlungen von Best Practices gehen mitunter so weit, dass sie in ihrer Gesamtheit durchaus ein Vorgehen definieren. 3
3 Grundlagen wichtiger Vorgehensmodelle Am Markt existiert eine Vielzahl von Vorgehensmodellen, die aus den verschiedensten Gründen hier Erwähnung finden könnten. Die hier untersuchten Modelle sind der Rational Unified Process, das V - Modell XT und der Product Innovation Lifecycle. Der Rational Unified Process der Firma IBM Rational Software ist ein Modell, das weltweit bekannt und verbreitet ist. Das V - Modell XT als Nachfolger des V - Modell 97 ist für deutsche Behörden und alle Zulieferer bzw. Dienstleister der bindende Standard. Der Product Innovation Lifecycle ist das interne Vorgehensmodell der SAP AG. Er wurde ausgewählt, da SAP das größte deutsche Softwareunternehmen und eines der größten weltweit ist. 3.1 Rational Unified Process 3.1.1 Überblick Grundlegend fließen im Rational Unified Process (kurz: RUP) zwei verschiedene Entwicklungen zusammen. Einerseits die von der Firma Rational praktizierte Erarbeitung eines iterativen und inkrementellen Softwareprozesses mit architekturzentrierter Vorgehensweise und andererseits der von Ivar Jacobson entwickelte Objectory Process. Der von der gleichnamigen Firma vertriebene Prozess Objectory basiert auf Erfahrungen bei der Entwicklung von Kommunikationssystemen bei Ericsson. Zentrales Konzept bildet die Kommunikation des in Blöcke aufgeteilten Systems. Zur Darstellung dienen Use- Case-Diagramme (deutsch: Anwendungsfalldiagramme) und weitere, das objektorientierte Design unterstützende Darstellungen, die zur heutigen UML große Ähnlichkeit aufweisen. Im Jahre 1995 wurde Objectory von Rational Software übernommen und es entstand durch die Zusammenarbeit von Grady Booch, James Rumbaugh und Ivar Jacobson der Rational Objectory Process (1996). Unter Einbeziehung der Vereinheitlichungsbestrebungen der UML und unter dem Einfluss weiterer Firmen veröffentlichten die oben genannten Autoren den Unified Process (1998). Es handelt sich dabei um einen eher generischen Prozess, von dem der RUP eine spezielle und detaillierte Instanz ist. Der RUP wird ebenfalls im Jahr 1998 erstmalig unter diesem Namen veröffentlicht. Seit 2003 gehört Rational zum IBM Konzern, der den Rational Unified Process unter diesem Namen weiterentwickelt und vertreibt. 4
Innerhalb dieser mehrjährigen Entwicklung stellten sich sechs Best Practices als Grundlage für qualitative Softwareentwicklung heraus, die entsprechend im RUP umgesetzt wurden. Die folgende Tabelle stellt deren originale Bezeichnung mit der deutschen Übersetzung des Buches [Kruc99] gegenüber. Originalbezeichnung aus [Rati03] Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Übersetzung nach [Kruc99] Iterative Softwareentwicklung Anforderungsmanagement Verwendung komponentenbasierter Architekturen Visuelle Softwaremodellierung Prüfung der Softwarequalität Kontrolliertes Änderungsmanagement Tabelle 3-1: Deutsche Übersetzung der Best Practices Iterative Softwareentwicklung Mit Hilfe der iterativen Softwareentwicklung soll das Problem der immer größer und komplexer werdenden Softwareprojekte gelöst werden. Oft ist zu Anfang eines Projektes der gesamte Umfang nicht zu überblicken. Ein rein sequentielles Vorgehen der Entwicklung von der Analyse über die Implementierung bis zum abschließenden Test des Gesamtsystems verhindert meist ein vollständiges Verstehen des Problems und kann somit nicht zu ausgereifter Software führen. Aus diesem Grund wird im RUP ein iterativer Ansatz verwendet, der nach jeder Iteration ein lauffähiges Softwareprodukt als Ergebnis hat. Werden weitere Risiken, Änderungen oder Wünsche des Nutzers identifiziert, so beginnt eine neue Iteration mit Anforderungsanalyse, Analyse & Design, Implementierung und Evaluierung. 5
Abbildung 3-1: Iterative Softwareentwicklung, Quelle: [Rati03] Anforderungsmanagement Durch das Anforderungsmanagement soll im RUP eine konsistente und möglichst vollständige Erfassung der Anforderungen erreicht werden. Einen wichtigen Bestandteil bildet hierbei die durchgängige Dokumentation. Der Weg zur Findung der Anforderungen wird im RUP durch Use-Case-Diagramme gesteuert, die, auch aus Sicht des zukünftigen Endnutzers, die Zusammenhänge und Funktionalitäten in verständlicher und übersichtlicher Weise darstellen können. Verwendung komponentenbasierter Architekturen Die Verwendung komponentenbasierter Architekturen dient dem schnellen, aber robusten Implementieren gemäß dem iterativen Entwicklungsvorgehen. Weitere Vorteile liegen in der flexiblen Architektur, der möglichen Wiederverwendung, dem intuitiven Verständnis und einer leichten Modifizierbarkeit der Komponenten. Ebenso können durch das komponentenorientierte Vorgehen mit Hilfe des RUP neue Architekturen wie z.b. Internetapplikationen, unter Einbeziehung von CORBA- und COM-Technologien, implementiert werden. Visuelle Softwaremodellierung Unter visueller Softwaremodellierung wird im RUP die Zuhilfenahme von grafischen Darstellungen zur Beschreibung von Strukturen bzw. Verhalten des zu entwickelnden Systems verstanden. Zum Einsatz kommt hier der Industriestandard UML, der anfänglich wie der RUP von der Firma Rational entwickelt wurde. 6
Prüfung der Softwarequalität Softwarequalität ist im Sinne des RUP die Funktionalität, die Zuverlässigkeit und die Performance der Anwendung. Die Umsetzung dieser Best Practice bietet Unterstützung für die Planung, das Design, die Implementierung, die Ausführung und die Bewertung der verschiedensten Testtypen. Die Prüfung der Softwarequalität fließt im RUP in alle Aktivitäten und in alle Rollen ein. Kontrolliertes Änderungsmanagement Ziel des Änderungsmanagements ist die Verwaltung der unterschiedlichsten Modifikationen, die während der gesamten Projektlaufzeit auftreten können. Zu den Funktionen zählen Kontrolle und Aufzeichnung der Änderungen ebenso wie die Einrichtung sicherer Arbeitsplätze. Zu überwachen sind jegliche Softwarebestandteile, wie z.b. Modelle, Quellcodes, Dokumentationen und weitere. 3.1.2 Phasenstruktur Die beschriebenen grundlegenden Best Practices werden im RUP auf eine zweidimensionale Phasenstruktur abgebildet. Auf der horizontalen Achse wird der zeitliche Aspekt abgetragen. Es werden hier die dynamischen Aspekte des Modells, wie die verschiedenen Zyklen, Phasen, Iterationen und Meilensteine, dargestellt. Die vertikale Achse repräsentiert die statischen Gesichtspunkte. Hierzu zählen die Workflows und deren Aktivitäten, Artefakte und Rollen. Abbildung 3-2: Phasenstruktur des RUP, Quelle: [GaMP04] 7
Der dynamische Aspekt bzw. die Zeitachse ist in vier Phasen unterteilt. Jede stellt dabei eine neue Generation des Produktes dar. Originalbezeichnung nach [Rati03] Inception Elaboration Construction Transition Übersetzung nach [Kruc99] Konzeptualisierung Entwurf Konstruktion Übergang Tabelle 3-2: Deutsche Übersetzung der Phaseneinteilung Diese vier Phasen enden jeweils mit einem genau definierten Meilenstein, an dem kritische Entscheidungen gefällt werden und somit entsprechend vorgegebene Ziele erreicht sein müssen. Abbildung 3-3: Phasen und Meilensteine, Quelle: [Rati03] Konzeptualisierung Innerhalb der Konzeptionalisierungsphase wird das Problemfeld des Projektes analysiert. Es werden die Geschäftsfälle mit ihren externen Abhängigkeiten und die verschiedenen Interaktionen mit dem System auf einem hohen Abstraktionsniveau erfasst. Ebenso gehört zu dieser Phase das Finden aller Use-Cases (Anwendungsfälle). Das Ende dieser Phase ist der Meilenstein Lifecycle Objectives (deutsch nach [Kruc99]: Ziel des Lebenszyklus). An dieser Stelle muss ein Phasen- bzw. Zeitplan, eine Ressourcenplanung, ein Use-Case-Modell (zu 10% 20 % fertig gestellt) und ein oder mehrere Prototypen des zu erstellenden Systems vorliegen. 8
Entwurf Ziel des Entwurfes ist die Fertigstellung der Problemanalyse. Die funktionalen und auch die nichtfunktionalen Anforderungen, wie z.b. die Performance, werden spezifiziert. Der Projektplan wird vervollständigt und die größten Risiken des Projektes werden bestimmt. In einer oder mehreren Iterationen wird der Prototyp zu einem ausführbaren System mit allen Architektureigenschaften weiterentwickelt. Den Abschluss dieser Phase bildet der Lifecycle Architecture Meilenstein (deutsch nach [Kruc99]: Architektur des Lebenszyklus). Am Ende dieser Phase liegt die Architektur, die Risikoanalyse, der fertig gestellte Projektplan und ein Use-Case-Modell, zu ca. 80 % komplett, vor. Konstruktion Während der Konstruktion werden alle übrigen Komponenten und Funktionen der Applikation umgesetzt und ausgetestet. Darin sind auch das endgültige Ausdefinieren des Use-Case-Modells und der Anforderung in verschiedenen Iterationen enthalten. Der Abschluss dieser Phase ist der Initial Operational Capability Meilenstein (deutsch nach [Kruc99]: Erste Funktionsfähigkeit). Das Produkt muss hierfür auf den verschiedenen Plattformen integriert und lauffähig sein. Ein Benutzerhandbuch und eine Beschreibung des aktuellen Release sind erstellt worden. Oft wird dies als Beta Release bezeichnet. Übergang Der Übergang ist die abschließende Phase der Softwareentwicklung. Das Produkt wird beim Kunden eingeführt und unter dessen Gegebenheiten getestet. Neben der Produktübergabe besteht weiterhin die Notwendigkeit des Trainings der Nutzer und der Planung der Wartung. Der Übergang kann je nach Projekt von sehr einfach bis sehr komplex ausfallen. Im Gegensatz zu einer vollständigen Neueinführung einer Software ist dies bei einem neuen Release eines Produktes sicherlich sehr einfach. Der abschließende Meilenstein wird als Product Release Milestone bezeichnet. Die statischen Aspekte des RUP sind durch Workflows definiert. Es werden im RUP die drei Workflow-Typen Core(Kern)-Workflows, Iterations-Workflows und Workflow-Details unterschieden. Core-Workflows sind die elementaren Bestandteile des Prozesses. Iterations-Workflows bieten einen anderen Blickwinkel auf die Entwicklung, in dem sie sich mehr auf die Aspekte einzelner Iterationen beziehen. Hierfür sind im RUP typische Beispiele vorhanden. Jedoch ist ihr Einsatz eher aus pädagogischen Gründen von Interesse. Input und Output einer Aktivität sowie weitere Informationen werden in den Workflow-Details betrachtet. 9
Die statische bzw. vertikale Dimension der Prozessstruktur wird durch neun Core- Workflows gebildet. Diese unterscheidet man nochmals nach Engineering- und Supporting-Workflows. Unter den Engineering-Workflows werden die klassischen Disziplinen der Softwareentwicklung verstanden. Die Supporting-Workflows stellen die unterstützenden Tätigkeiten dar. Originalbezeichnung aus [Gorn01] Übersetzung nach [Kruc99] Engineering-Workflows Business Modeling Requirements Analysis & Design Implementation Test Deployment Geschäftsprozessmodellierung Anforderungsanalyse Analyse & Design Implementierung Test Verteilung Supporting-Workflows Project Management Configuration & Change Management Environment Projektmanagement Änderungsmanagement Umgebungsdisziplin Tabelle 3-3: Deutsche Übersetzung der neun Core-Workflows Die Engineering-Workflows entsprechen einem Entwicklungsvorgehen nach dem klassischen Wasserfallmodell. Es ist hier jedoch zu beachten, dass diese im Laufe der iterativen Softwareentwicklung in den verschiedenen dynamischen Phasen insgesamt immer mehrmals durchlaufen werden. Die Supporting-Workflows stellen das Software- Projektmanagement mit seinen unterstützenden Aktivitäten dar. 3.1.3 Prozessbestandteile In einem Prozess wird nach [Kruc99] beschrieben Wer Was Wann und Wie tut. Die oben beschriebenen Workflows stellen dabei das Wann dar. Innerhalb eines 10
Workflows bzw. eines Prozesses kommen drei verschiedene Beschreibungselemente zum Einsatz. Unterschieden wird zwischen Rollen (Role), Aktivitäten (Activities) und Artefakten (Artifacts). Rolle (Role) Rollen repräsentieren das Wer des Prozesses. Sie beschreiben, wie sich Personen verhalten sollen und welche Verantwortlichkeiten sie besitzen. In früheren Versionen des RUP wurde dieser Bestandteil als Arbeiter (Worker) bezeichnet. Es wurde auf die Bezeichnung Rolle übergegangen, da ein Arbeiter bzw. eine Person im Laufe des Projektes mehrere verschiedene Rollen innehaben kann. Aktivität (Activity) Aktivitäten sind die von einer Rolle auszuführenden Tätigkeiten. Ihre grundlegende Aufgabe ist die Beschreibung, Wie Artefakte zu erstellen oder zu bearbeiten sind. Artefakt (Artifact) Artefakte werden durch die Ausführung einer Aktivität durch eine bestimmte Rolle erstellt, geändert oder genutzt. Als Informationsteile des Gesamtprozesses stellen sie das Was eines Workflows dar. Artefakte dienen einerseits als Input, andererseits als Output einer Aktivität, und sie können die verschiedensten Formen annehmen, wie z.b. Reports, Quellcodes, Vorlagen und andere. Die folgende Abbildung zeigt das Zusammenspiel aller Kernelemente des RUP. Unter Disziplinen versteht man die Zusammenfassung von in Verbindung stehenden Tätigkeiten. Sie sollen das Verständnis des gesamten Prozessmodells verbessern. 11
Abbildung 3-4: Zusammenspiel der RUP Kernelemente, Quelle: [Rati03] 3.1.4 Werkzeugunterstützung Der RUP wird durch eine breite Palette von Softwarewerkzeugen unterstützt. Diese ebenfalls von der Firma IBM Rational Software vertriebenen Produkte bieten den Vorteil, dass die mit dem RUP mitgelieferten Tool-Mentoren und Plug-Ins unverändert zum Einsatz kommen können. Die folgende Tabelle stellt gemäß [Gorn01] einige IBM Rational Software Produkte und ihre Einsatzmöglichkeiten gegenüber: IBM Rational Softwareprodukt IBM Rational Requisite Pro IBM Rational Clearquest IBM Rational Rose IBM Rational SoDA Einsatzmöglichkeiten Anforderungsanalyse Änderungsmanagement Geschäftsprozessmodellierung Anforderungsanalyse Architektur Dokumentation 12
IBM Rational Purify IBM Rational Visual Quantity IBM Rational Visual PureCoverage IBM Rational TeamTest IBM Rational Performance Studio IBM Rational ClearCase Entwickler Tests für Laufzeitfehler Softwareentwicklung Entwickler Tests Automatisiertes Testen Performanceanalyse Konfigurationsmanagement Tabelle 3-4: IBM Rational Software Produkte, nach: [Gorn01] 3.2 V - Modell XT 3.2.1 Überblick Die Entwicklung des V - Modells begann im Jahr 1986. Es wurde vom Bundesministerium für Verteidigung (BMVg) in Auftrag gegeben, um die Probleme der Softwareentwicklung und die hohen Entwicklungszeiten zu reduzieren. Weiterhin sollte es die Nachvollziehbarkeit der entwickelten Systeme mit Hilfe von Dokumenten erhöhen, um so eine geringere Abhängigkeit vom Hersteller zu erreichen. Die erste Version des V - Modells wurde im Jahr 1992 veröffentlicht. Im Rahmen von verschiedenen Treffen des Anwendervereins ANSSTAND e.v. wurden jedoch diverse Verbesserungsmöglichkeiten festgestellt. Nach [DrHM98] waren die gefundenen Mängel eine zu starke Beschränkung auf Softwareprojekte, eine zu geringe Unterstützung für neue technologische Ansätze, eine nicht ausreichende Abdeckung aller Projektmanagementaspekte, eine unzureichende Trennung von technischer und fachlicher Sicht sowie eine zu hohe Komplexität und entsprechende Unhandlichkeit des Gesamtmodells. Diese und weitere Änderungsanträge führten im Juli 1997 zur Veröffentlichung der Überarbeitung des Modells, bekannt als V - Modell 97. Das V - Modell 97 wurde in dieser Form nicht weiter fortgeschrieben und spiegelt deshalb im Jahr 2004 nicht mehr den neuesten Stand der Informationstechnologie wider. Z.B. finden im V - Modell 97 komponentenbasierte Entwicklung oder der Test-First-Ansatz keine oder kaum Unterstützung. Aus diesen Gründen wurde durch die Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung (kurz: KBSt) des Bundesministeriums des Innern (kurz: BMI) die Weiterentwicklung des V - Modell 97 veranlasst. Die Be- 13
strebungen mündeten in dem V - Modell XT, das im Februar 2005 veröffentlicht wurde. Grundlage dieser Arbeit bildet die Vorabversion 0.9, die im November 2004 veröffentlicht wurde. Ausgehend vom V - Modell 97 wurden folgende Anforderungen umgesetzt (aus [KBSt04]): - Verbesserung folgender Qualitätseigenschaften: Möglichkeit zur Anpassung an verschiedene Projekte und Organisationen, Anwendbarkeit im Projekt, Skalierbarkeit auf unterschiedliche Projektgrößen sowie Änder- und Erweiterbarkeit des V Modells selbst - Berücksichtigung des neuesten Stands der Technologie und Anpassung an aktuelle Vorschriften und Normen - Erweiterung des Anwendungsbereiches auf die Betrachtung des gesamten Systemlebenszyklus bereits während der Entwicklung - Einführung eines organisationsspezifischen Verbesserungsprozesses für Vorgehensmodelle Das V - Modell XT basiert auf vier grundlegenden Zielen, die die Planung und Durchführung eines Projekts unterstützen. Minimierung der Projektrisiken Durch ein standardisiertes Vorgehen und genaue Vorschriften über verantwortliche Rollen und zugehörige Ergebnisse soll die Projekttransparenz und die Planbarkeit verbessert werden. Eine frühe Erkennung von Abweichungen und Risiken ist somit möglich. Prozesse lassen sich besser steuern und führen zu einer Risikominimierung. Verbesserung und Gewährleistung der Qualität Das V - Modell soll sicherstellen, dass die gelieferten Ergebnisse vollständig und von gewünschter Qualität sind. Durch die im Modell definierten Zwischenergebnisse und die vereinheitlichten Produktinhalte ermöglicht sich eine frühere und einfachere Überprüfung der besser lesbaren Ergebnisse. 14
Eindämmung der Gesamtkosten über den gesamten Projekt- und Systemlebenszyklus Mit Hilfe des V - Modells kann der Aufwand für die einzelnen Projektphasen, wie die Entwicklung, die Herstellung, den Betrieb, die Pflege und die Wartung eines Systems, besser kalkuliert bzw. abgeschätzt werden. Die Gesamtkosten sind so transparenter und leichter zu steuern. Verbesserung der Kommunikation zwischen allen Beteiligten Die Kommunikation der Projektbeteiligten wird durch eine einheitliche Beschreibung aller relevanten Modellbestandteile und Begrifflichkeiten gewährleistet. So genannte Reibungsverluste zwischen Nutzern, Auftragnehmern, Auftraggebern und Entwicklern werden so minimiert. Die Umsetzung dieser vier grundlegenden Ziele ist ein recht umfangreiches Vorgehensmodell, das ohne großen Aufwand an die verschiedensten Projekttypen angepasst werden kann. Einige Elemente des Gesamtmodells müssen zur Anwendung kommen, andere können. Eine Unterscheidung erfolgt in Vorgehensbausteine, Entscheidungspunkte und Projekttypen. Ein Vorgehensbaustein deckt eine konkrete Aufgabenstellung, die im Rahmen eines Projektes auftreten kann, ab. Festgelegt werden dabei die zu erarbeitenden Produkte, die an ihm arbeitenden Rollen und die Aktivitäten, die zu diesen Produkten führen. Ein Entscheidungspunkt ist ein Punkt innerhalb eines Projekts, an dem der aktuelle Stand des Projektes bewertet und gemäß dieser Evaluation die Entscheidung über den weiteren Verlauf gefällt wird. Durch die Kombination von verschiedenen Vorgehensbausteinen und Entscheidungspunkten ist das V - Modell für die verschiedensten Projekttypen anwendbar. Einige Vorgehensbausteine sind für ein V - Modell konformes Vorgehen zwingend notwendig. Sie werden als V - Modell-Kern bezeichnet. Die folgende Abbildung gibt einen Überblick über alle Elemente des Modells: 15
Abbildung 3-5: Gesamtstruktur des V - Modell XT, Quelle: [KBSt04] 3.2.2 Phasenstruktur Die Struktur eines Vorgehens nach dem V - Modell ist durch 18 Entscheidungspunkte charakterisiert. Die Verwendung der jeweiligen Entscheidungspunkte wird durch die Wahl eines bestimmten Projekttyps bestimmt. Unterschieden wird zwischen Systementwicklungsprojekt eines Auftraggebers, Systementwicklungsprojekt eines Auftragnehmers oder Einführung und Pflege eines organisationsspezifischen Vorgehensmodells. Die folgende Abbildung verdeutlicht den Einsatz der verschiedenen Entscheidungspunkte in den unterschiedlichen Projekttypen: 16
Abbildung 3-6: Entscheidungspunkte des V - Modell XT, Quelle: [KBSt04] Betrachtet wird in diesem Rahmen der Projekttyp Systementwicklung eines Auftragnehmers. Der Umfang eines solchen Projektes erstreckt sich dabei von der Angebotserstellung und im Falle eines Vertragsabschlusses über die Projektdurchführung bis zur Auslieferung und einer entsprechenden Abnahme durch den Auftraggeber. Abbildung 3-7: Vorgehensbausteine für Systementwicklung eines AN, Quelle: [KBSt04] 17
Zwingend notwendig für die Durchführung ist, wie in jedem V - Modell-konformen Projekt, die Umsetzung der Vorgehensbausteine des V - Modell-Kerns. Dazu zählen das Projektmanagement, das Problem- und Änderungsmanagement, das Konfigurationsmanagement und die Qualitätssicherung. Ebenso ist der Einsatz von Angebotserstellung und Vertragserfüllung sowie Systemerstellung für diesen Projekttyp nötig. Je nach Art bzw. Anforderungen des Problems müssen weitere Vorgehensbestandteile gemäß obiger Abbildung mit einbezogen werden. Durch die Zusammenstellung der Vorgehensbestandteile ist jedoch die Vorgehensweise für die Systemerstellung noch nicht festgelegt. Unterschieden werden je nach Anforderungen des zu entwerfenden Systems verschiedene Vorgehensweisen. Beschrieben sind diese als Projektdurchführungsstrategien im dritten Teil des V - Modells, V - Modell- Referenz Tailoring. Es existieren verschiedene Phasenstrukturen z.b. für die inkrementelle Systementwicklung, für die komponentenbasierte Systementwicklung und für die agile Systementwicklung. Unter Systemen bzw. Systementwicklung werden im V - Modell nicht nur Software- sondern auch Hardware-Projekte und andere verstanden. Als ein Beispiel für die empfohlenen Prozessstrukturen soll im Weiteren die Vorgabe für die inkrementelle Systementwicklung dienen. Die Grundidee im Rahmen des V - Modells besteht in einer zu Beginn des Projektes relativ fest abgesteckten Anforderungsanalyse, die nachträglich nur durch das Problem- und Änderungsmanagement modifizierbar ist. An bestimmten Entscheidungspunkten sind Auftraggeber und Auftragnehmer somit gezwungen, die neu entstandenen Anforderungen über Zusatzverträge zu regeln. Der Auftragnehmer entwirft, realisiert und liefert das System in einzelnen Stufen, die man als Inkremente bezeichnet. Änderungen innerhalb einer Entwicklungsstufe sind nicht vorgesehen. Sie werden über das Änderungsmanagement erfasst und dann zu einem späteren Zyklus realisiert. Sie können somit frühestens im nachfolgenden Inkrement implementiert sein. Der Vorteil dieses Vorgehens für den Auftraggeber liegt im frühen Besitz einer Vorstufe des Gesamtsystems, in der die wichtigsten Grundfunktionalitäten bereits umgesetzt sind. Empfohlen wird dieses Vorgehen jedoch nur für Projekte mit geringen technologischen Risiken und einer stabilen Einschätzung der zu erwartenden Anforderungen. Den Ablauf der inkrementellen Entwicklung beschreibt folgende Abbildung mit Hilfe der V - Modell-typischen Darstellung der betroffenen Entscheidungspunkte und ihrer zeitlichen Abfolge. 18
Abbildung 3-8: Inkrementelle Systementwicklung mit dem V - Modell XT, Quelle: [KBSt04] Die dem eigentlichen Entwicklungsprojekt vorausgehenden Entscheidungspunkte dienen dem genauen Festlegen der Vertragsbestandteile zwischen dem Auftraggeber und dem Auftragnehmer. Hierzu zählen die Entscheidungspunkte (kurz EP) 1 bis 4, gemäß obiger Abbildung. Zuerst muss ein Auftragnehmer überprüfen, ob ein Angebot für ihn sinnvoll ist. Ist dies der Fall und das Projekt wird intern genehmigt (EP 1), erfolgt anschließend die Projektdefinition, die Erstellung des Projekthandbuchs sowie des QS- Handbuchs (EP 2). Wird das daraufhin vorgelegte Angebot (EP 3) vom Auftraggeber akzeptiert, folgt eine vertragliche Fixierung der Anforderungen an das System sowie der Rahmenbedingungen für das Projekt (EP 4). In den folgenden Schritten wird das System entwickelt. Die Entscheidungspunkte 5 bis 9 stellen dabei ein Vorgehen nach dem Wasserfallmodell dar. Ein Unterschied besteht jedoch in dem Gewährleisten von Qualitätsansprüchen an das System, im Wasserfallmodell realisiert durch einen abschließenden Test, im V - Modell durch eine ständige Qualitätsprüfung in jeder Phase der Entwicklung. Eine Evaluation der Ergebnisse zu jedem Entscheidungspunkt zeigt, ob eine Fortführung, eine Nachbesserung oder ein Abbruch notwendig bzw. möglich ist. Nach Abschluss der Anforderungsanalyse und Erstellung des Pflichtenhefts (EP 5) folgt der Entwurf (EP 6), der in den folgenden Schritten zum Feinentwurf weiterentwickelt wird (EP 7). Auf dessen Grundlage findet die Umsetzung der Systemteile statt. Sind die entwickelten Systemelemente als qualitativ und fehlerfrei begutachtet (EP 8), werden sie zum Gesamtsystem zusammengefügt und den abschließenden Tests unterzogen (EP 9). Zu einem eventuellen Abschluss des Projekts kommt es in den Einscheidungspunkten 10 bis 13. Nach Zusammenstellung des Systems sowie gegebenenfalls von Unterstützungssystemen und der Dokumentation erfolgt die Auslieferung an den Kunden (EP 10). Der Auftraggeber überprüft das gelieferte System hinsichtlich der Erfüllung der Anforderungen (EP 11). Sind an diesem Punkt noch Nachbesserungen bzw. Änderun- 19
gen am System von Nöten, so wird ein Änderungsplan erstellt. Dieser legt nach Prüfung aller Änderungsanträge fest, was in die Änderungsspezifikation des neuen Inkrements eingeht (EP 12) und ein neuer Zyklus der Entwicklung wird gestartet. Hat das System den Anforderungen des Auftraggebers genügt und es wurden alle Anforderungen erfüllt, so führt Punkt 11 zum Abschluss des Projekts (EP 13). 3.2.3 Prozessbestandteile Im V - Modell wird nach [KBSt04] beschrieben, Wer, Wann, Was in einem Projekt zu tun hat. Bestimmte Aufgaben sind in einem in sich geschlossenem Vorgehensbaustein zusammengefasst. Ein Vorgehensbaustein definiert die zu erzeugenden Produkte, die Aktivitäten, durch die sie erzeugt werden, und die an den einzelnen Produkten mitwirkenden Rollen. Produkt Unter Produkten werden die zu erarbeitenden Ergebnisse oder auch Zwischenergebnisse verstanden. Die Gesamtheit aller Produkte wird hierarchisch strukturiert, indem inhaltlich eng zusammengehörende Produkte zu Produktgruppen zusammengefasst werden. Darüber hinaus kann ein komplexes Produkt in mehrere Themen gegliedert sein. Bestehen zwischen mehreren Produkten Abhängigkeiten, so werden deren Konsistenzbedingungen in den Produktabhängigkeiten formuliert. Produkte werden mit abgerundeten Ecken dargestellt. Aktivität Aktivitäten beschreiben Wie und somit die Art und Weise der vorgegebenen Bearbeitung für ein Produkt. Entscheidend im V - Modell ist, dass ein Produkt von genau einer Aktivität fertig gestellt wird. Die Aktivitäten sind ebenfalls hierarchisch strukturiert. Inhaltlich oder vorgehenstechnisch zusammenpassende Aktivitäten werden zu Aktivitätsgruppen zusammengefasst. Sind ein oder mehrere Themen im Sinne einer Arbeitsanleitung durchgängig zu bearbeiten, so spricht man von Teilaktivitäten. Aktivitäten werden in ihrer Darstellung durch Rechtecke repräsentiert. Rolle In einer Rolle wird eine Menge von Aufgaben und Verantwortlichkeiten definiert. Es wird somit ein abstraktes Wer umgesetzt, um unabhängig von organisatorischen Rahmenbedingungen und Personen zu bleiben. Erst zu Beginn eines Projekts erfolgt die 20
Besetzung bestimmter Rollen durch Personen oder Organisationseinheiten. Durch die Zuordnung der Rolle zu einem Produkt werden für jedes Produkt ein Verantwortlicher und mehrere mitwirkende Rollen festgelegt. Verdeutlichen soll diese Zusammenhänge zwischen Produkten, Aktivitäten und Rollen innerhalb eines Vorgehensbaustein folgende Abbildung: Abbildung 3-9: Bestandteile eines V - Modell-Vorgehensbaustein, Quelle: [KBSt04] 3.2.4 Werkzeugunterstützung Das V - Modell XT wird von einer Bundesbehörde und, im Gegensatz zum RUP, nicht von einem Softwarehersteller entwickelt. Diese Tatsache macht sich bei der Werkzeugunterstützung bemerkbar. Die Betrachtung erfolgt deshalb dreigeteilt in die Werkzeugreferenzen des Modells, den Tools des KBSt und die Werkzeuge externer Hersteller. Werkzeugreferenzen des V - Modell XT Im Anhang des V - Modells befindet sich ein Kapitel über die zu verwendenden Werkzeugkategorien. Beschrieben wird der Sinn und Zweck jeder dieser Tool-Arten. Es werden teils direkt, teils indirekt die benötigten Anforderungen über die gewünschten Eigenschaften der Werkzeuge beschrieben. Eine explizite Nennung bestimmter Tools erfolgt nicht. Folgende Kategorien sind beschrieben: - Anforderungsmanagement - Compiler - Fehler- / Änderungsmanagement - GUI-Werkzeug - Integrierte Entwicklungsumgebung - KM-Werkzeug (Konfigurationsmanagement) - Konstruktion / Simulation - Modellierungswerkzeug - Projektplanung - Testwerkzeug 21
Tools des KBSt Das KBSt bietet zwei kleine Werkzeuge zur Unterstützung der V - Modell-Anwender. Hierbei handelt es sich jedoch nicht um komplexe Softwareentwicklungs- oder Managementtools. Angeboten werden ein Projektassistent und ein Editor. Der Projektassistent ist eine Referenzimplementierung des im V - Modell vorgegebenen Tailoring- Mechanismus. Ziel seines Einsatzes ist die Anpassung des Modells an die projektspezifischen Anforderungen. Der Editor bietet dem Benutzer die Möglichkeit der Anpassung bzw. Erweiterung des Modells aufgrund unternehmensspezifischer Bedürfnisse. Durch den in Eclipse als Plug-In realisierten Editor können z.b. Vorgehensbausteine hinzugefügt oder Strukturen von Projektvorlagen geändert werden. Werkzeuge externer Hersteller Vom KBSt werden keine externen Werkzeuge für die Umsetzung eines V - Modell- Projekts vorgeschlagen. Alle Tools, die den Anforderungen genügen, können zum Einsatz kommen. In [IABG04] werden Werkzeuge, die an das V - Modell 97 angepasst wurden, vorgestellt. Z.B. werden für das Submodell Softwareentwicklung Innovator von Oracle und case/4/0 von MicroTool genannt. Im Bereich des Projektmanagements erfolgt unter anderem eine Nennung des Tools in-step von MicroTool, das auch jetzt schon in einer Version für das V - Modell XT verfügbar ist. 3.3 SAP Product Innovation Lifecycle 3.3.1 Überblick SAP entwickelte den Product Innovation Lifecycle (kurz: PIL), um eine höhere Ebene für die Qualität der produzierten Software zu erhalten. Die bei SAP im Einsatz befindlichen Mechanismen zur Qualitätssicherung genügten den eigens gesetzten Anforderungen nicht mehr. Die üblichen Werkzeuge, wie ein Qualitätsmanagement gemäß ISO 9001-2000, Qualitätsmanagement in den einzelnen Entwicklungsbereichen sowie Qualitätsaudits zur Verbesserung des Systems, boten nicht die gewünschte Qualitätsebene. Abhilfe sollte der entwickelte PIL schaffen, der nach seiner Fertigstellung im Sommer 2003 im Herbst desselben Jahres eingeführt wurde. Der PIL ist das Vorgehensmodell der Lösungsentwicklung bei SAP und wird als unternehmensinterner Standard eingesetzt. Die grundlegende Idee liegt in einem ganzheitli- 22
chen Prozessmodell, das die gesamte Lebenszeit eines Produktes von der Erfindung bis zur Verbesserung bzw. Weiterentwicklung unterstützt. Weitere Prinzipien sind die Wiederverwendung von Komponenten und die Nähe der Entwickler zu den Anwendern. Die Entwicklung nach der Idee der Wiederverwendung wird durch neue Komponenten nach dem Baukastenprinzip realisiert. Neue Elemente können somit mehrfach Verwendung finden und kommen daher immer wieder in unterschiedlichen Lösungen zum Einsatz. Auf diese Weise erreicht man eine schnellere Realisierung eines Produkts von der Idee bis zur Umsetzung sowie eine höhere Qualität des Designs und der Umsetzung. SAP zählt zu seinen Stärken die Nähe zu seinen Anwendern. Auch deren Umsetzung wurde im PIL versucht. Eine Einbeziehung der Anwender erfolgt zu jeder Zeit der Projektentwicklung. Einen grundlegenden Ansatz bildet dabei die gemeinsame Gestaltung der Bedienungsoberfläche, dem User Interface (kurz: UI). Umgesetzt ist dies im UI- First Teilprozess, der einen wichtigen Teil des PIL darstellt. 3.3.2 Phasenstruktur Als ganzheitliches Vorgehensmodell unterstützt der PIL den gesamten Lebenszyklus eines Produktes. Gegliedert ist der PIL dabei in mehrere Phasen: Invent (erfinden), Define (definieren), Develop (entwickeln), Deploy (einführen) und Optimize (verbessern). Jede dieser fünf Phasen gliedert sich, gemäß folgender Abbildung, wiederum in mehrere Prozesse. Abbildung 3-10: Phasenstruktur des PIL, Quelle: [Ecke03] Nach Durchlaufen der verschiedenen Prozesse stellt sich zum Abschluss jeder Phase immer die Frage nach einer möglichen Weiterentwicklung. Kann dies durch die internen 23