Vergleichsmethoden für Vorgehensmodelle

Transkript

1 Diplomarbeit Vergleichsmethoden für Vorgehensmodelle bearbeitet von Christian Filß Matrikelnummer: 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.

2 Aufgabenstellung II

3 III

4 Inhaltsverzeichnis Aufgabenstellung... II Inhaltsverzeichnis... IV Abkürzungsverzeichnis... VII Abbildungsverzeichnis... IX Tabellenverzeichnis...X 1 Einleitung Begriffsklärung und Abgrenzung Grundlagen wichtiger Vorgehensmodelle Rational Unified Process Überblick Phasenstruktur Prozessbestandteile Werkzeugunterstützung V - Modell XT Überblick Phasenstruktur Prozessbestandteile Werkzeugunterstützung SAP Product Innovation Lifecycle Überblick Phasenstruktur Bestehende Vergleichsansätze Einordnung nach Dr. Gerhard Chroust Überblick Vergleichskriterien Bewertung GERAM Überblick Vergleichskriterien Bewertung Zachmann Framework Überblick Vergleichskriterien Bewertung Weitere Vergleichsansätze Vergleichskriterien / Dimensionen Überblick Definierende Dimensionen Nichtdefinierende Dimensionen Zusammenfassung Vergleichsrahmen Definierende Dimensionen...47 IV

5 6.1.1 Ausprägungen Phasenabdeckung Prozessabdeckung Formalisierung Abstraktionsstufe Branchenfokus Objektdomäne Vorgehensweise Prozesssteuerung Graphische Darstellung Allgemeine Eigenschaften von Vorgehensmodellen Softwarespezifische Eigenschaften von Vorgehensmodellen Nichtdefinierende Dimensionen Ausprägungen VM-Präsentation Werkzeugbindung Toolsupport Automatisierungsgrad QS-Beitrag Systemhierarchie Graphische Darstellung Weitere Vergleichskriterien Terminologie Prozessarchitektur Quantifizierung Allgemeine Quantifizierung Definierende Dimensionen Quantifizierung Graphisches Modell Nichtdefinierende Dimensionen Quantifizierung Graphisches Modell Individuelle Quantifizierung Anwendung Terminologie Rational Unified Process Definierende Dimensionen Untersuchung Graphische Darstellung Allgemeine Quantifizierung Individuelle Quantifizierung Nichtdefinierende Dimensionen Untersuchung Graphische Darstellung Quantifizierung V - Modell XT Definierende Dimensionen Untersuchung Graphische Darstellung V

6 Allgemeine Quantifizierung Individuelle Quantifizierung Nichtdefinierende Dimensionen Untersuchung Graphische Darstellung Quantifizierung Product Innovation Lifecycle Definierende Dimensionen Untersuchung Graphische Darstellung Bewertung und Ausblick Anhang A Anhang B Anhang C Anhang D Anhang E Literaturverzeichnis Selbstständigkeitserklärung VI

7 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

8 UI VM WI Zachmann Framework User Interface Vorgehensmodell Wirtschaftsinformatik Zachmann Framework for Enterprise Architecture VIII

9 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] Abbildung 3-5: Gesamtstruktur des V - Modell XT, Quelle: [KBSt04] Abbildung 3-6: Entscheidungspunkte des V - Modell XT, Quelle: [KBSt04] Abbildung 3-7: Vorgehensbausteine für Systementwicklung eines AN, Quelle: [KBSt04] Abbildung 3-8: Inkrementelle Systementwicklung mit dem V - Modell XT, Quelle: [KBSt04] Abbildung 3-9: Bestandteile eines V - Modell-Vorgehensbaustein, Quelle: [KBSt04] Abbildung 3-10: Phasenstruktur des PIL, Quelle: [Ecke03] Abbildung 3-11: Risikomanagement im PIL, Quelle: [Ecke03] Abbildung 4-1: Das Zachmann Framework, Quelle: [Vill03] Abbildung 6-1: Graphisches Modell des AK-VM, definierende Dimensionen, Quelle: [AKVM05] Abbildung 6-2: Allgemeine, definierende Eigenschaften von Vorgehensmodellen Abbildung 6-3: Beispiel für die allgemeinen, definierenden Eigenschaften von Vorgehensmodellen Abbildung 6-4: Softwarespezifische, definierende Eigenschaften von Vorgehensmodellen Abbildung 6-5: Beispiel für die softwarespezifischen, definierenden Eigenschaften von Vorgehensmodellen Abbildung 6-6: Graphisches Modell des AK-VM, nichtdefinierende Dimensionen, Quelle: [AKVM05] 70 Abbildung 6-7: Nichtdefinierende Eigenschaften von Vorgehensmodellen Abbildung 6-8: Beispiel für die nichtdefinierenden Eigenschaften von Vorgehensmodellen Abbildung 7-1: Beispiel eines Kiviat-Graphs, Quelle: [PGFL05] Abbildung 7-2: Kiviat-Graph der allgemeinen Quantifizierung, definierende Dimensionen Abbildung 7-3: Beispiel für eine allgemeine Quantifizierung, definierende Dimensionen Abbildung 7-4: Kiviat-Graph der allgemeinen Quantifizierung, nichtdefinierende Dimensionen Abbildung 7-5: Beispiel für eine allgemeine Quantifizierung, nichtdefinierende Dimensionen Abbildung 7-6: Kiviat-Graph der individuellen Quantifizierung Abbildung 7-7: Beispiel für eine individuelle Quantifizierung Abbildung 8-1: Allgemeine, definierende Eigenschaften des RUP Abbildung 8-2: Softwarespezifische, definierende Eigenschaften des RUP Abbildung 8-3: Allgemeine Quantifizierung der definierenden Eigenschaften des RUP Abbildung 8-4: Individuelle Quantifizierung des RUP gemäß Tabelle Abbildung 8-5: Nichtdefinierende Eigenschaften des RUP Abbildung 8-6: Quantifizierung der nichtdefinierenden Eigenschaften des RUP Abbildung 8-7: Allgemeine definierende Eigenschaften des V - Modell XT Abbildung 8-8: Softwarespezifische definierende Eigenschaften des V - Modell XT Abbildung 8-9: Allgemeine Quantifizierung der definierenden Eigenschaften des V - Modell XT Abbildung 8-10: Individuelle Quantifizierung des V - Modell XT gemäß Tabelle Abbildung 8-11: Nichtdefinierende Eigenschaften des V - Modell XT Abbildung 8-12: Quantifizierung der nichtdefinierenden Eigenschaften des V - Modell XT Abbildung 8-13: Allgemeine definierende Eigenschaften des PIL Abbildung 8-14: Softwarespezifische definierende Eigenschaften des PIL IX

10 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 Tabelle 3-4: IBM Rational Software Produkte, nach: [Gorn01] Tabelle 4-1: Reifestadien des Softwareentwicklungsprozesses, nach: [Chro92] Tabelle 4-2: Niveaus von Vorgehensmodellen, nach: [Chro92] Tabelle 4-3: Realisationsstufen, nach: [Chro92] Tabelle 4-4: Beschreibungsformen, nach: [Chro92] Tabelle 4-5: Entwicklungsniveaus, nach: [Chro92] Tabelle 4-6: GERAM - Phasen des Lebenszyklus Tabelle 4-7: Model Content View, nach: [IFIP99] Tabelle 4-8: Purpose View, nach [IFIP99] Tabelle 4-9: Implementation View, nach: [IFIP99] Tabelle 4-10: Physical Manifestation View, nach: [IFIP99] Tabelle 4-11: Perspektiven des Zachmann Framework, nach: [Vill03] Tabelle 4-12: Fokusse des Zachmann Framework, nach: [Vill03] Tabelle 4-13: Vergleichskriterien, nach: [NoSc99] Tabelle 5-1: Im Folgenden zu untersuchende Dimensionen Tabelle 6-1: Ausprägungen der Phasenabdeckung Tabelle 6-2: Ausprägungen der Prozessabdeckung Tabelle 6-3: Ausprägungen der Formalisierung Tabelle 6-4: Ausprägungen der allgemeinen Abstraktionsstufe Tabelle 6-5: Ausprägungen des Formalisierungsgrades...52 Tabelle 6-6: Ausprägungen des Branchenfokus Tabelle 6-7: Ausprägungen der allgemeinen Objektdomäne Tabelle 6-8: Ausprägungen der softwarespezifischen Objektdomäne Tabelle 6-9: Ausprägungen der Prozessvorgehensweise Tabelle 6-10: Ausprägungen der Programmiervorgehensweise Tabelle 6-11: Ausprägungen der Prozesssteuerung Tabelle 6-12: Beispiel einer graphischen Darstellung mit Tabellen, Quelle: [AKVM05] Tabelle 6-13: Ausprägungen der VM-Präsentation Tabelle 6-14: Ausprägungen der Werkzeugbindung...65 Tabelle 6-15: Ausprägungen des Toolsupport Tabelle 6-16: Ausprägungen des Automatisierungsgrades Tabelle 6-17: Ausprägungen des QS-Beitrags Tabelle 6-18: Ausprägungen der Systemhierarchie Tabelle 6-19: Wesentliche Beschreibungselemente, nach [NoSc99] Tabelle 7-1: Quantifizierung der Sprachformalisierung Tabelle 7-2: Quantifizierung der Darstellungsform Tabelle 7-3: Quantifizierung des Formalisierungsgrades Tabelle 7-4: Quantifizierung des Branchenfokus Tabelle 7-5: Wertebereiche der allgemein quantifizierbaren, definierenden Dimensionen Tabelle 7-6: Anwendungsbeispiel allgemeine Quantifizierung, definierende Dimensionen Tabelle 7-7: Quantifizierung der VM-Präsentation Tabelle 7-8: Quantifizierung der Werkzeugbindung Tabelle 7-9: Quantifizierung des Toolsupports Tabelle 7-10: Quantifizierung des Automatisierungsgrads Tabelle 7-11: Quantifizierung des QS-Beitrags Tabelle 7-12: Quantifizierung der Systemhierarchie Tabelle 7-13: Wertebereiche der allgemein quantifizierbaren, nichtdefinierenden Dimensionen Tabelle 7-14: Anwendungsbeispiel allgemeine Quantifizierung, nichtdefinierende Dimensionen Tabelle 7-15: Prioritätentabelle der individuellen Quantifizierung, inklusive Beispiel Tabelle 7-16: Beschreibende Tabelle der individuellen Quantifizierung Tabelle 7-17: Anwendungsbeispiel individuelle Quantifizierung Tabelle 8-1: Terminologievergleich der Vorgehensmodelle Tabelle 8-2: Definierende Eigenschaften des RUP Tabelle 8-3: Allgemeine Quantifizierung der definierenden Eigenschaften des RUP Tabelle 8-4: Individuelle Quantifizierung des RUP gemäß Tabelle X

11 Tabelle 8-5: Nichtdefinierende Eigenschaften des RUP Tabelle 8-6: Quantifizierung der nichtdefinierenden Eigenschaften des RUP Tabelle 8-7: Definierende Eigenschaften des V - Modell XT Tabelle 8-8: Allgemeine Quantifizierung der definierenden Eigenschaften des V - Modell XT Tabelle 8-9: Individuelle Quantifizierung des V - Modell XT gemäß Tabelle Tabelle 8-10: Nichtdefinierende Eigenschaften des V - Modell XT Tabelle 8-11: Quantifizierung der nichtdefinierenden Eigenschaften des V - Modell XT Tabelle 8-12: Definierende Eigenschaften des PIL XI

12 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

13 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

14 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

15 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 Ü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

16 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

17 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

18 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 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

19 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

20 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

21 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 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

22 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

23 Abbildung 3-4: Zusammenspiel der RUP Kernelemente, Quelle: [Rati03] 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

24 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 Überblick Die Entwicklung des V - Modells begann im Jahr 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

25 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

26 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

27 Abbildung 3-5: Gesamtstruktur des V - Modell XT, Quelle: [KBSt04] 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

28 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

29 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

30 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

31 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) 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

32 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] 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

33 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 Ü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 , 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

34 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 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

35 Managementmechanismen positiv beantwortet werden, so geht der Entwicklungsprozess in die nächste Phase über. Eine weitere, den vollständigen Ablauf begleitende Aktivität stellt das Risikomanagement dar. Es werden nach verschiedenen Kriterien der Risikoanalyse und der Risikobehandlung Wichtungen vorgenommen, die in regelmäßigen Abständen kontrolliert werden. Eine Unterscheidung erfolgt in monatliche Beurteilungen (monthly risk monitoring, kurz RM) und Risikobeurteilungen (dedicated risk assesment, kurz RA). Risikobeurteilungen sind obligatorisch und führen nach einer Fertigstellungskontrolle (readiness control, kurz RC) durch ein so genanntes Quality-Gate (kurz Q-Gate) in die neue Phase. Abbildung 3-11: Risikomanagement im PIL, Quelle: [Ecke03] 24

36 4 Bestehende Vergleichsansätze 4.1 Einordnung nach Dr. Gerhard Chroust Überblick Dr. Gerhard Chroust stellt in seinem Buch Modelle der Software - Entwicklung ([Chro92]) seine Erfahrungen mit Vorgehensmodellen aus der Arbeit im IBM-Software- Entwicklungslaboratorium Wien und seiner Vorlesungs- und Seminartätigkeit zusammen. Er selbst bezeichnet dieses Buch als Nachschlagewerk zum Lesen. Es besteht aus verschiedenen Textmodulen, die sich mit den unterschiedlichen Aspekten der Vorgehensmodelle auseinandersetzen. Die erklärte Zielgruppe sind dabei Projektleiter, Methodenspezialisten sowie Entwickler und Qualitätssicherer. Ausgehend von der Softwarekrise werden die verschiedensten Aspekte moderner Softwareentwicklung erläutert. Die Feststellung, dass die Qualität eines Softwareprodukts nicht nachträglich hinzufügbar ist bzw. dass sich ein Produkt nach seiner Fertigstellung nur schwer verbessern lässt, führt zu dem Schluss der Notwendigkeit eines qualitativ hochwertig gestalteten Softwareentwicklungsprozesses. Aus diesem Grund müssen Prozesse durch arbeitsteilige, einheitliche und wiederholbare Abläufe definiert werden. Die Bezeichnungen Vorgehensmodell und Prozessmodell verwendet Chroust synonym. Ein Vorgehensmodell, als idealisierter Prozess, besitzt zwei grundlegende Aufgaben: - Abstraktion (Nachbildung) durchgeführter Prozesse - Vorbild und Definition des idealisierten Prozesses. Anders formuliert entsteht ein Vorgehensmodell aus der Beurteilung und dem Herausfiltern von Gemeinsamkeiten real durchgeführter Projekte. Aus einem speziellen Ablauf werden die Details ausgeblendet und der allgemeingültige Anteil extrahiert. Somit kommt es zur Trennung zwischen Prozess und Produkt. Die so gewonnen Erkenntnisse führen in idealisierter Weise zu einem Muster bzw. Vorbild für Projekte, dem Vorgehensmodell, das als eine Darstellung, die weitgehend den Software - Entwicklungsprozess beschreibt und auch Analysen des Prozesses gestattet (Quelle: [Chro92]), definiert wird. Eine erste Einordnung der Softwareentwicklungsprozesse erfolgt entsprechend ihrer Reifestadien. Grundlage hierfür bildet das Reifediagramm nach Crosby, das ebenfalls 25

37 der Ausgangspunkt für das CMM bzw. dessen Weiterentwicklung CMMI ist. Unterschieden werden fünf Reifestufen: Reifegrad Beginnend (initial) Reproduzierbar (repeatable) Definiert (defined) Kontrolliert (managed) Optimierend (optimizing) Beschreibung Verlauf ist vorhersagbar Prozess stabil, Verlauf reproduzierbar Prozess definiert, Verlauf konsistent Messungen und Analysen eingerichtet Kontinuierliche Verbesserung und Optimierung des Prozesses Tabelle 4-1: Reifestadien des Softwareentwicklungsprozesses, nach: [Chro92] Basierend auf diesen grundlegenden Betrachtungen von Chroust, werden im Weiteren die verschiedenen Aspekte von Vorgehensmodellen unter mehreren Blickwinkeln beleuchtet Vergleichskriterien Durch die Anwendung verschiedenster Blickwinkel finden sich bei Chroust ([Chro92]) eine Vielzahl verschiedener Ansätze zur Betrachtung bzw. zur Einordnung von Vorgehensmodellen. Da deren Darstellung den Rahmen dieser Arbeit sprengen würde, soll hier eine Auswahl der vorhandenen Ansätze vorgestellt werden: - Niveaus von Vorgehensmodellen - Realisationsstufen - Beschreibungsform - Entwicklungsniveau 26

38 Niveaus von Vorgehensmodellen Das Niveau eines Vorgehensmodells repräsentiert die Detaillierung (Granularität) einer Vorgehensmodell-Darstellung. Eine Unterscheidung erfolgt in drei Stufen: Niveau Universelles VM Weltliches VM Atomares VM Merkmale Beschrieben werden prinzipielle Schritte und allgemeine Richtlinien (globale Ablaufstruktur). Oft bestehen sie nur aus einer Aufzählung von Richtlinien. Die Abfolge der Schritte und die Voraussetzungen für die Durchführung von Aktivitäten sind ausreichend detailliert beschrieben und ein praktischer Einsatz ist direkt möglich. Diese Modelle sind sehr detailliert und enthalten präzise Definitionen aller Daten und Prozessschritte. Sie sind für die automatisierte Ausführung bestimmter Tätigkeiten geeignet. Tabelle 4-2: Niveaus von Vorgehensmodellen, nach: [Chro92] Ein evolutionär fortgeschriebenes Vorgehensmodell kann im Laufe seiner Entwicklung alle diese drei Niveaus durchlaufen. Von einem anfänglichen groben Ablaufplan kann ein Vorgehensmodell durch zunehmende Detaillierung bis hin zum atomaren Model fortgeführt werden. Neben der Unterscheidung von Niveaus von Vorgehensmodellen bietet Chroust eine Unterteilung in Grundtypen ausgelieferter Vorgehensmodelle. Hierbei unterscheidet er je nach Umfang des umgesetzten Detaillierungsgrades in Dach-Modell, Kern-Modell und modulares Bausteinmodell. Im Vergleich zu der angebotenen Einteilung nach Niveaus scheint dies jedoch keine neuen Erkenntnisse zu bringen. Realisationsstufen Jeder Entwicklungsprozess setzt eine gewisse Methodik voraus. Jedoch ist es in der Praxis schwierig zu unterscheiden, in welchem Maß bestimmte Methoden anwendbar oder in welcher Breite sie definiert sind. Eine Trennung zwischen Prinzipien, Methoden, Verfahren und Werkzeugen stellte sich als praktikabel heraus. Jedoch bieten sich noch weitere Verfeinerungen der Realisationsstufen an. 27

39 Realisationsstufe Prinzip Methode Methodik Verfahren Methodenbündel / Methodologie Werkzeug Technologisches Verfahren Technik Merkmale Ein Prinzip als ein allgemeingültiger Grundsatz, abgeleitet aus Gesetzen und Eigenschaften der Realität, dient als Leitfaden. Eine Methode ist eine systematische Handlungsvorschrift, um Aufgaben einer bestimmten Klasse zu lösen. Sie beruht auf einem oder mehreren Prinzipien. Sie ist eine Anweisung zur methodischen und zweckmäßigen Lösung einer wissenschaftlichen Aufgabe. Ein Verfahren beschreibt einen konkreten Weg zur Lösung bestimmter Probleme oder Problemklassen und ist somit stärker einsatzbezogen. Es besteht aus einer Sammlung von zusammenpassenden Methoden. Werkzeuge setzten Methoden um. Sie dienen dem automatisierten Bearbeiten von Informationsmengen. Verstanden wird hierunter die Verbindung einer Methode oder eines Verfahrens mit einer Menge von Mitteln (Werkzeugen). Die Technik stellt die Kenntnis bzw. die Beherrschung der Mittel dar. Tabelle 4-3: Realisationsstufen, nach: [Chro92] Abgeleitet wird aus diesen Realisationsstufen, dass ein Vorgehensmodell nicht ohne Prinzipien oder Methoden existieren kann, jedoch ebenso, dass nicht alle Methoden in einem Modell umgesetzt werden können. Aufgrund der mangelnden Unterstützung der zu der Zeit bekannten Methoden für den gesamten Entwicklungsprozess besteht die Notwendigkeit der Umsetzung mindestens eines Methodenbündels für ein Vorgehensmodell. Eine Übersicht der Anwendungsbereiche verschiedener Methoden ist im Anhang A zu finden. 28

40 Beschreibungsform Unter der Beschreibungsform bzw. den Beschreibungsmitteln soll eine Untergliederung der Vorgehensmodelle anhand ihrer Notation erfolgen. Ein Modell kann dabei verschiedene Darstellungen anbieten und somit in mehrere Gruppen eingeordnet werden. Beschreibungsform Text Tabellarisch Graphisch Algorithmisch Axiomatisch Merkmale Der Entwicklungsprozess wird in natürlicher, oft leicht formalisierter Sprache in Form eines Projekthandbuchs beschrieben. Die Darstellung erfolgt mit Hilfe von Tabellen und Matrizen, welche die mehrdimensionalen Beziehungen zwischen den Aktivitäten und den Resultaten darstellen. Eine anschauliche und benutzerfreundliche Darstellung, realisiert durch den Einsatz von PCs und CASE-Werkzeugen. Dargestellt durch eine der dritten Generation der Programmiersprachen nachempfundene Prozesssprache. Jeder Aktivitätstyp wird durch ein Axiom beschrieben, das die Ausführungsbedingungen und den Effekt der Transformationen festlegt. Tabelle 4-4: Beschreibungsformen, nach: [Chro92] Entwicklungsniveaus Unter einem Entwicklungsniveau versteht Chroust eine Stufe im Übergang von der Problemstellung zu einem lauffähigen, installierten Produkt. Die grundlegende Einteilung in Fachkonzept, Entwurf und Implementierung ist durch die zeitliche Entwicklung zu einer neunstufigen Klassifizierung herangewachsen. Es kommen hier neben den klassischen Entwicklungsaufgaben auch in gewissem Maße begleitende Aktivitäten wie z.b. die Installation oder die Wartung zum Tragen. Entwicklungsniveau Merkmale Unternehmensmodell Basis für die zu entwickelnde Software bildet ein Modell der Daten- und Funktionsstruktur des Unternehmens. 29

41 Anforderungen Fachkonzept Grob-Entwurf Detail-Entwurf Implementierung Integration Installation Wartung Die zunehmende Komplexität und die Schwierigkeit des Findens des Fachmodells machen eine vorgelagerte Anforderungsanalyse notwendig. Im Fachkonzept wird das benutzerseitig sichtbare Verhalten des Systems definiert. Die technische Lösung wird in groben Zügen festgelegt. Dazu zählen z.b. Modulaufteilungen, jedoch keine Details, wie zu verwendende Algorithmen. Details werden fixiert und z.b. durch Pseudocode formalisiert. Das System wird in Code umgesetzt. Die Module des Projekts bzw. die Versionen und Konfigurationen werden zusammengeführt. Die Software wird beim Kunden installiert und gegebenenfalls werden Feineinstellungen vorgenommen. Das System wird gewartet. Tabelle 4-5: Entwicklungsniveaus, nach: [Chro92] Bewertung Im Buch Modelle der Software - Entwicklung von Gerhard Chroust ([Chro92]) wird das Thema der Vorgehensmodelle aus vielen verschiedenen Blickwinkeln betrachtet. Die für diese Zeit (1992) gängigen Paradigmen der Softwareentwicklung und ihre entsprechenden Umsetzungen in Vorgehensmodellen sind sehr detailliert beschrieben. Die hier vorgestellten Vergleichskriterien sind eine Auswahl der angebotenen Sichtweisen. Die Auswahl begründet sich in der Möglichkeit einer späteren Verwendung in einem neueren Vergleichsrahmen. Kriterien wie Niveaus von Vorgehensmodellen, Realisationsstufen, Beschreibungsformen und Entwicklungsniveaus könnten nach einer Anpassung an die heutigen Gegebenheiten eine Grundlage eines solchen Vergleichsrahmens bilden. 30

42 4.2 GERAM Überblick Die Generalised Enterprise Reference Architecture and Methodology, kurz GERAM, ist im Rahmen eines Anhangs in der ISO-Norm WD 15704: Requirements for enterprise - reference architectures and methodologies veröffentlicht wurden. Die Erarbeitung von GERAM erfolgte durch die International Federation for Information Processing (kurz: IFIP) und die International Federation of Automatic Control (kurz: IFAC) im Rahmen einer Task-Force. Im März 1999 stellte diese Arbeitsgruppe die Version des GERAM vor. Ziel des GERAM ist die Definition eines allgemeinen Frameworks für die Architektur eines Unternehmens. Unterschieden wird die Betrachtung der Unternehmensstruktur aus den Blickwinkeln der prozess- und produktorientierten Modellierung. Die wichtigste Komponente bildet die Generic Enterprise Reference Architecture (kurz: GERA). Aus dem Abschnitt GERA soll im Weiteren die prozessorientierte Sichtweise untersucht werden. Da GERAM die Unternehmensstruktur im Ganzen betrachtet, ist es nicht direkt für den Vergleich von Vorgehensmodellen geeignet bzw. vorgesehen. Die vorgeschlagene Referenzarchitektur beleuchtet jedoch einige Gesichtspunkte, die, übertragen auf die Thematik der Vorgehensmodelle, von Interesse für einen Vergleich sein könnten Vergleichskriterien GERAM definiert die prozessorientierte Sicht mit einem in acht Phasen unterteilten Lebenszyklus. Orthogonal zu diesen Phasen werden die verschiedenen Sichtweisen angeordnet. Die fünf verschiedenen Sichten bzw. Dimensionen sind: - Life Cycle Phases (Phasen des Lebenszyklus) - Model Content View (Modell-Inhaltssicht) - Purpose View (Zielsicht) - Implementation View (Umsetzungssicht) - Physical Manifestation View (physische Manifestationssicht) 31

43 Life Cycle Phases Ein GERA Lebenszyklus beschreibt in acht Phasen die möglichen Zustände eines Unternehmens oder eines Teilbereiches. Vergleichbar ist ein Teilbereich zum Beispiel mit der Softwareentwicklung in einem bestimmten Unternehmen. Entsprechend ähnelt die allgemeine Unterteilung des GERAM auch der Phasenstruktur eines Softwareentwicklungsprozesses. Aus diesem Grund wird an dieser Stelle auf eine Beschreibung verzichtet und die Phasen werden bei entsprechender Übereinstimmung mit den Definitionen nach Chroust (siehe Kapitel 4.1) gegenübergestellt: Life Cycle Phase Identification (Identifikation) Concept (Konzept) Requirements (Anforderungen) Prelimerary Design (vorläufiges Design) Detailed Design (detailliertes Design) Implementation (Implementierung) Operation (Betrieb) Decommission (Abbau) Entwicklungsniveau nach Chroust Keine Übereinstimmung Unternehmensmodell Anforderungen Grob-Entwurf Detail-Entwurf Implementierung Integration / Installation / Wartung Keine Übereinstimmung Tabelle 4-6: GERAM - Phasen des Lebenszyklus Model Content View Der Model Content View (Modell-Inhaltssicht) bietet vier verschiedene Sichtweisen zur Darstellung des Prozesses aus dem Blickwinkel des Nutzers. Unterschieden wird zwischen Function-, Information-, Organisation- und Resource-View, die wie folgt definiert sind: Model Content View Function View Beschreibung Repräsentiert werden die Funktionalität und das Verhalten des Geschäftsprozesses. 32

44 Information View Resource View Organisation View Dient als Sammlung von Informationen über die verschiedenen Objekte im Unternehmen und ihrer Nutzung. Betrachtet werden die menschlichen und technischen Ressourcen und ihre Verwendung. Legt die Verantwortlichkeiten und Befugnisse aller Beteiligten Entitäten fest. Tabelle 4-7: Model Content View, nach: [IFIP99] Purpose View Der Purpose View (Zielsicht) dient der Aufteilung des Gesichtsfeldes einer Unternehmensstruktur. Unterschieden wird in die Sicht der eigentlichen Umsetzung eines Vorhabens ( mission fullfillment part ) und dem Management. Purpose View Customer Service & Product View Management & Control View Beschreibung Beschrieben werden die für die eigentliche Unternehmenstätigkeit wichtigen Objekte sowie deren Handhabung und die entstehenden Ergebnisse. Inhalte, die für die Unternehmensführung wichtig sind, und deren Kontrollfunktionen werden für die Handhabung der Produkte und Dienstleistung betrachtet. Tabelle 4-8: Purpose View, nach [IFIP99] Implementation View Durch den Implementation View (Umsetzungssicht) wird eine Unterscheidung der auszuführenden Tätigkeiten nach Automatisierbarkeit getroffen. Implementation View Human Activities View Beschreibung In dieser Sicht sind alle Informationen beschrieben, die im Zusammenhang mit durch Menschen auszuführende Tätigkeiten stehen. 33

45 Automated Activities View Dieser Blickwinkel repräsentiert alle Aufgaben, die mit Hilfe von Maschinen automatisierbar sind. Tabelle 4-9: Implementation View, nach: [IFIP99] Physical Manifestation View Der Physical Manifestation View (physische Manifestations- oder Umsetzungssicht) unterscheidet die im Unternehmen vorliegenden Entitäten nach Software und Hardware. Physical Manifestation View Software View Hardware View Beschreibung Software bezeichnet Informationen und Wissen sowie Ablaufstrategien. Repräsentiert alle physischen Ressourcen des Unternehmens. Tabelle 4-10: Physical Manifestation View, nach: [IFIP99] Bewertung GERAM als eine Referenzarchitektur für Unternehmensmodelle ist in seiner ursprünglichen Form nicht als Vergleichsrahmen gedacht. Ebenso ist die Betrachtung eines Vorgehensmodells aus den vorgegebenen Gesichtspunkten nicht Sinn der Entwicklung gewesen. Betrachtet man ein Vorgehensmodell in gewissem Sinn als Unternehmensmodell, so können die verschiedenen Blickwinkel eine höhere Sicht auf das Modell geben und somit die Einordnung in die Unternehmensstruktur ermöglichen. 4.3 Zachmann Framework Überblick Das Zachmann Framework for Enterprise Architecture (kurz: Zachmann Framework) basiert auf einem 1987 von John Zachmann veröffentlichten Paper mit dem Titel A 34

46 Framework for Information Systems Architecture ([Zach87]). Seine Arbeit stützt sich auf eine langjährige Erfahrung im Bereich der Informationssystemplanung und der Geschäftssystemmodellierung bei IBM. Nach Zachmann besteht eine enge Verknüpfung zwischen guten Informationssystemen, ihren Strategien und der gesamten Geschäftsstrategie. Aus diesem Grund muss das dem Unternehmen zu Grunde liegende IT-System möglichst alle Businessobjekte unterstützen. Mit Hilfe des vorgeschlagenen Frameworks bietet sich die Möglichkeit der Beurteilung des Softwareentwicklungsmodells nach den Gesichtspunkten der benötigten Organisationsstruktur Vergleichskriterien Das Zachmann Framework basiert auf einer zweidimensionalen Struktur, unterschieden in Perspektiven und Fokusse. Perspektive Die Perspektiven analysieren die verschiedenen Blickwinkel auf das umzusetzende System. Zachmann unterstellt dabei, dass die sechs angebotenen Sichten voneinander unabhängig sind und jede ihren eigenen Zweck erfüllt. Die Bezeichnung der Sichten ist in der Literatur nicht einheitlich verwendet, weshalb die folgende Tabelle beide gebräuchlichen Bezeichnungen der Perspektiven enthält. Perspektive Scope / Planner s View Business Model / Owner s View System Model / Designer s View Technology Model / Builder s View Beschreibung Beschrieben wird die Businessstrategie. Die Sicht dient der Unterteilung und dem Management der anderen Sichten. Beschreibung des Systems aus Sicht des Unternehmens, in das es eingebracht werden soll. Bildet die Sicht des Designers. Ein grobes Modell, frei von Details, wird erstellt. Die Sicht des Builders beschreibt den Feinentwurf und die spezielle Nutzung von Technologien. 35

47 Detailed Representations / Detailed View Functioning Enterprise / Operational View Diese Perspektive betrachtet das System aus dem Blickwinkel des Programmierers. Eine Betrachtung des realisierten Systems im Unternehmensumfeld erfolgt. Tabelle 4-11: Perspektiven des Zachmann Framework, nach: [Vill03] Fokus Die zweite Dimension im Zachmann Framework ist der Fokus. Er dient der Klassifikation der Charakteristika und dem Herausstellen von verschiedenen Aspekten des Systems. Jeder der sechs Fokusse bietet einen von den anderen isolierten Blickwinkel auf das System. Fokus Data / What Function / How Network / Where People / Who Time / When Motivation / Why Beschreibung Betrachtet werden Daten, Businessobjekte und Prozesse. Es erfolgt die Betrachtung der Handhabung und der Funktionalität des Systems. Ziel ist die Darstellung der Systemverteilung und die Präsentation der bestehenden Abhängigkeiten der Elemente. Die Interaktion mit dem System durch Personen oder Organisationseinheiten wird untersucht. Stellt den zeitlichen Ablauf für die Prozesse und Workflows des How-Fokus her. Motivationen für die Systemerstellung wie Zielsetzungen und Businesspläne werden beschrieben. Tabelle 4-12: Fokusse des Zachmann Framework, nach: [Vill03] Durch die Kombination dieser zwei Dimensionen in einer Matrix entsteht ein Analyse- Framework für die Untersuchung von Softwareentwicklungsprozessen. Durch die Unabhängigkeit der einzelnen Achselemente kann der Zweck eines jeden Elements genau definiert werden. Mit Hilfe dieser Matrix soll es möglich sein, die Vollständigkeit eines 36

48 Vorgehensmodells hinsichtlich der Geschäfts- und der IT-Strategie zu überprüfen. Die folgende Abbildung zeigt die Matrix mit den Definitionen für die einzelnen Felder: Abbildung 4-1: Das Zachmann Framework, Quelle: [Vill03] Um die Anwendung des Framework zu verdeutlichen, enthält der Anhang B eine Einordnung des Rational Unified Process in die Zachmann-Matrix Bewertung Das Zachmann Framework dient der Beurteilung der Vollständigkeit eines Modells oder eines Entwicklungsprozesses. Aus diesem Gesichtspunkt sind auch die Anordnung der Dimensionen und die Definitionen der einzelnen Feldinhalte zu sehen. Über das zu beurteilende Modell werden aus dem Zachmann Framework keine Informationen über Vorgehen oder Abhängigkeiten deutlich. Zwei Vorgehensmodelle können 37

49 somit eine ähnliche Besetzung der Felder der Zachmann-Matrix haben, obwohl ihnen völlig unterschiedliche Entwicklungsvorgehen zu Grunde liegen. 4.4 Weitere Vergleichsansätze Aufgrund der Existenz vieler verschiedener Vorgehensmodelle und den unterschiedlichsten Interessen an ihnen besteht eine große Anzahl von Arbeiten, die eine spezielle Sicht auf dieses Thema werfen. An dieser Stelle sollen zwei ausgewählte Exemplare und ihre Vergleichskriterien kurz dargestellt werden. Die Arbeit von Jörg Noack und Bruno Schienmann beschäftigt sich mit dem Vergleich objektorientierter Vorgehensmodelle und der Anwendung ihrer Vergleichskriterien auf diverse Modelle. Als Zweites wird die Ausarbeitung Genealogie von Entwicklungsschemata von Georg Bremer betrachtet. Objektorientierte Vorgehensmodelle im Vergleich, [NoSc99] Der in der Informatik Spektrum erschienene Artikel von Jörg Noack und Bruno Schienmann definiert für seinen Vergleich einiger objektorientierter Vorgehensmodelle einen eigenen Vergleichsrahmen. Verwendung findet dieser Rahmen auch in dem speziell für komponentenbasierte Vorgehensmodelle angepassten Vergleich in [FeIL02]. Die in diesem Rahmen verwendeten Vergleichskriterien bzw. Dimensionen soll folgende Tabelle näher erläutern: Vergleichskriterium Terminologie Phasen- und Prozessabdeckung Beschreibung Zum besseren Verständnis der betrachteten Modelle werden die jeweils verwendeten Terminologien gegenübergestellt. Phasenabdeckung bezeichnet das Kriterium der Vollständigkeit der Entwicklungsphasen, wie Analyse, Design usw.. Unter Prozessabdeckung wird die Untersuchung der den eigentlichen Entwicklungsprozess unterstützenden Aufgaben, wie z.b. dem Konfigurationsmanagement, vorgenommen. Prozessarchitektur Diese Dimension untersucht die Anordnung der Prozesselemente. 38

50 Prozesssteuerung Adaption Werkzeuge Eine Unterscheidung zwischen aktivitätsorientierter, ergebnisorientierter und vertragsorientierter Steuerung der Entwicklungsschritte erfolgt. Betrachtet wird die Möglichkeit der Anpassung des Modells auf verschiedene Anwendungsbereiche. Die Frage nach dem für das Vorgehensmodell am Besten geeignete Werkzeug wird beleuchtet. Tabelle 4-13: Vergleichskriterien, nach: [NoSc99] Genealogie von Entwicklungsschemata, [Brem98] Unter Genealogie wird bei Bremer die historische Charakterisierung von Entwicklungsschemata verstanden. Das Hauptanliegen der Betrachtung ist die Darstellung der geschichtlichen Entwicklung der Softwareentwicklungsprozesse. Zur Abrundung des Artikels wird eine Einordnung nach Vorgehensweise und Einsatzbereich vorgenommen. Die unterschiedenen Vorgehensweisen sind sequentiell, inkrementell, iterativ, partizipativ und evolutionär. Die Einsatzbereiche werden in bekanntes und unbekanntes Problem sowie in altes und neues Anwendungsfeld untergliedert. Der Anhang C zeigt Bremers Einordnung der betrachteten Vorgehensweisen gemäß diesen zwei Kriterien. 39

51 5 Vergleichskriterien / Dimensionen 5.1 Überblick Die dargestellten Ansätze für Vergleiche von Vorgehens- oder Unternehmensmodellen bedienen sich einer Vielzahl von verschiedenen Vergleichskriterien. Ziel dieses Kapitels ist es, aus diesen Kriterien einige auszuwählen und entsprechend durch Ergänzung weiterer zu einer Dimensionierung eines Vergleichsrahmens zu führen. Die bisher vorgestellten Unterscheidungsmerkmale sind: Nach Chroust: - Niveaus von Vorgehensmodellen - Realisationsstufen - Beschreibungsform - Entwicklungsniveau Nach GERAM: - Life Cycle Phases - Model Content View - Purpose View - Implementation View - Physical Manifestation View Nach Zachmann: - Perspektive - Fokus Nach Noack und Schienmann: - Terminologie - Phasenabdeckung 40

52 - Prozessabdeckung - Prozesssteuerung - Adaption - Werkzeuge Nach Bremer: - Vorgehensweise - Einsatzbereiche Neben diesen Vergleichskriterien werden hier die Dimensionen der Einordnung nach dem Arbeitskreis Vorgehensmodelle - Übersicht und Vergleich der GI Fachgruppe WI-VM (kurz: AK-VM) diskutiert. Das Augenmerk liegt dabei auf dem Gesichtspunkt der Vollständigkeit für die angestrebten Ziele dieser Arbeit. Die AK-VM Dimensionen unterteilen sich in zwei Gruppen. Die Unterscheidung in definierende und nichtdefinierende Dimensionen dient der Zuordnung von Eigenschaften je nach Nähe zum Modell. Aussagen über eventuelle Werkzeugunterstützung etc. bilden keine direkte Aussage über das Modell an sich und sind somit für dieses nicht bestimmend. Diese Unterteilung wird hier übernommen. Die folgende Tabelle stellt die im Rahmen dieser Arbeit ausgewählten Dimensionen mit den Vorgaben des AK-VM Modells gegenüber: Zu untersuchende Dimension Dimension des AK-VM Definierende Dimensionen Phasenabdeckung Prozessabdeckung Formalisierung Abstraktionsstufe Branchenfokus Objektdomäne Phasen Submodelle Formalisierung Generizität Branchen-Fokus Objekt-Domäne 41

53 Vorgehensweise Prozesssteuerung Keine Entsprechung Keine Entsprechung Nichtdefinierende Dimensionen VM-Präsentation Werkzeugbindung Toolsupport Automatisierungsgrad QS-Beitrag Systemhierarchie Keine Entsprechung Keine Entsprechung Tool-Support Automatisierungsgrad QS-Beitrag System-Zerlegung Tabelle 5-1: Im Folgenden zu untersuchende Dimensionen Das weitere Vorgehen gibt für die in diesem Rahmen ausgewählten Dimensionen einen Überblick und erläutert die Herkunft und den Zweck des jeweiligen Blickwinkels. 5.2 Definierende Dimensionen Die im Weiteren zu verwendenden definierenden Dimensionen sind wie folgt ausgewählt. Eine Darstellung erfolgt mit ihren Quellen und den Zielen, die die einzelnen Dimensionen erfüllen sollen. Phasenabdeckung Die Phasenabdeckung sieht eine Untersuchung des Vorgehensmodells aus dem Blickwinkel der Vollständigkeit hinsichtlich der verschiedenen Phasen vor. Die Betrachtung dieses Gesichtspunktes ist in den meisten betrachteten Ansätzen vorhanden, im Vergleichsrahmen des AK-VM bezeichnet als Phasen, bei Chroust als Entwicklungsniveaus und in GERAM als Life Cycle Phases. In der Arbeit von Noack und Schienmann erfolgt die Bezeichnung als Phasenabdeckung, die hier übernommen wird. 42

54 Prozessabdeckung Die Prozessabdeckung dient der Analyse ob neben dem eigentlichen Entwicklungsprozess weitere ergänzende Prozesse im Vorgehensmodell vorgestellt werden. Die verschiedenen Bezeichnungen für die Phasenabdeckung sind nach dem AK-VM Submodelle und, in gewisser Abstraktion für Vorgehensmodelle, der Model Content View des GERAM. Die Bezeichnung Prozessabdeckung leitet sich von Noack und Schienmann ab. Formalisierung Unter dem Aspekt der Formalisierung soll betrachtet werden, welche Notationen oder Sprachen bei der Darstellung der Prozesse und ihren Abhängigkeiten zur Anwendung kommen. Verwendung findet diese Dimension bei Chroust unter der Bezeichnung Beschreibungsform und beim AK-VM unter dem Namen Formalisierung, der hier übernommen wurde. Abstraktionsstufe Die Abstraktionsstufe unterscheidet nach dem Kriterium, wie konkret ein betrachtetes Vorgehensmodell ausdefiniert ist. Vorlage bilden hier die Einordnungen von Chroust in Realisationsstufen und Niveaus von Vorgehensmodellen. Im AK-VM erfolgte die Bezeichnung dieser Dimension als Generizität. Branchenfokus Der Branchenfokus drückt aus, ob ein Modell für bestimmte Branchen speziell entwickelt wurde oder ob es allgemein über alle Bereiche einsetzbar ist. Der Branchenfokus ist mit seiner Bezeichnung aus dem AK-VM Vergleichsrahmen übernommen. Eine Betrachtung erfolgte ebenfalls im GERAM mit Hilfe des Purpose View. Objektdomäne Unter dem Gesichtspunkt der Objektdomäne erfolgt die Untersuchung des Entwicklungsgegenstandes des Vorgehensmodells. Abgeleitet ist diese Dimension aus dem Vergleichsrahmen des AK-VM. In gewisser Weise prägt auch die Abstraktion des Physical Manifestation View aus GERAM die Gestaltung dieser Dimension. Vorgehensweise Die Vorgehensweise ist aus der Einordnung von Bremer übernommen. Die vorgeschlagenen Ausprägungen betrachten das Gebiet der Softwareentwicklung. Eine Unterteilung 43

55 sollte jedoch noch weiter verfeinert werden, da Vorgehensmodelle auch auf anderen Ebenen unterschiedliche Vorgehensstrategien umsetzen. Eine entsprechende Einteilung ist in den anderen analysierten Vergleichsrahmen nicht aufgefunden wurden. Prozesssteuerung Die Untersuchung der Prozesssteuerung wird in der Arbeit von Noack und Schienmann vorgeschlagen. Die definierende Frage ist, in welcher Form bzw. Art die Entwicklungsschritte des Vorgehens gesteuert sind. 5.3 Nichtdefinierende Dimensionen Die nichtdefinierenden Dimensionen betrachten die dem Vorgehensmodell zugeordneten Werkzeuge genauer. Da die Mehrzahl der Vorgehensmodelle nicht von Softwareherstellern veröffentlicht wurde, sind sie nicht direkt unterstützt. Die hier betrachteten Unterscheidungsmerkmale sind dadurch teilweise schwierig zu untersuchen. Durch Drittanbieter angebotene Werkzeuge existieren für die meisten Modelle. Eine Untersuchung dieser Tools würde jedoch den Rahmen dieser Arbeit sprengen, da hier die Betrachtung von Vorgehensmodellen im Mittelpunkt steht und nicht die Untersuchung von unterstützenden Werkzeugen. Eine ausführliche Kategorisierung von Werkzeugen bietet [ChGr98]. Die vorgestellten Dimensionen dienen der Kategorisierung von Vorgehensmodellen und betrachten den Gesichtspunkt der im Modell angegebenen Werkzeugunterstützungen. Die Untersuchung kategorisiert z.b. die Werkzeugbindung oder den erreichbaren Automatisierungsgrad. VM-Präsentation Die Vorgehensmodell-Präsentation betrachtet die verschiedenen Formen der Auslieferung bzw. der Verteilung des Modells. Ausgehend vom Artikel von Noack und Schienmann wird z.b. in Papier oder elektronische Dokumente unterschieden. Werkzeugbindung Das zu untersuchende Vorgehensmodell kann in verschiedenen Formen an bestimmte Softwareprodukte gebunden sein. Um diese Eigenschaften zu kategorisieren, dient der Aspekt der Werkzeugbindung. Beispielsweise können Vorgehensmodelle direkt bestimmte Produkte empfehlen oder Referenzmodelle definieren. 44

56 Toolsupport Der Toolsupport hat das Ziel, das Vorgehensmodell entsprechend des Umfangs der angebotenen oder empfohlenen Werkzeuge einzuordnen. Zu untersuchen gilt, ob ein Modell beispielsweise nur für einzelne Aktivitäten oder für ganze Prozesse Werkzeugempfehlungen gibt. Diese Dimension basiert auf dem AK-VM Modell. Automatisierungsgrad Sind in einem Vorgehensmodell Werkzeuge für die Umsetzung der Aktivitäten vorgeschlagen, so stellt sich die Frage, in wie weit deren Verwendung zur Automatisierung beitragen kann. Ziel dieser aus dem Modell des AK-VM entnommenen Dimension ist eine Einteilung dieses Automatisierungsgrads. QS-Beitrag Gemäß des AK-VM analysiert der QS-Beitrag, in wie weit die Werkzeugunterstützung des Vorgehensmodells zur Steigerung der Qualität des Entwicklungsgegenstandes beiträgt. Systemhierarchie Die Systemhierarchie bezieht sich nicht direkt auf die Werkzeugunterstützung. Das Ziel besteht in der Betrachtung der hierarchischen Aufteilung des Gesamtmodells und gibt somit indirekt Auskunft über die Anforderungen, die an einen möglichen Toolsupport bestehen würden. Die Bezeichnung dieser Dimension erfolgte im AK-VM als Systemzerlegung. 5.4 Zusammenfassung Die bisher herausgefilterten Dimensionen können mit Ausprägungen versehen werden und somit einen Vergleichsrahmen bilden. Neben diesen Dimensionen existieren weitere Vergleichskriterien, die jedoch nicht mit Ausprägungen versehen werden können. Aus diesem Grund erfolgt eine Bezeichnung als Vergleichskriterien und nicht als Dimensionen. Die weiteren Vergleichskriterien sind die Terminologie und die Prozessarchitektur. Sie werden von Noack und Schienmann vorgeschlagen. Die Terminologie untersucht dabei die verwendeten Bezeichnungen in den Vorgehensmodellen. Eine allgemeine Kategorisierung ist nicht möglich und es muss für einen Vergleich von Modellen eine individuelle Gegenüberstellung der verwendeten Terminologien erfolgen. Die Prozessarchitek- 45

57 tur geht bei der Betrachtung tiefer in die zu analysierenden Vorgehensmodelle ein und kann ebenfalls nicht mit Ausprägungen versehen werden. Eine individuelle Betrachtung der verschiedenen Architekturen ist somit notwendig. Das Ziel der weiteren Untersuchung ist das Finden von Ausprägungen für die gewählten Dimensionen und das Gestalten eines Vorgehens für die Verwendung der Vergleichskriterien Terminologie und Prozessarchitektur. 46

58 6 Vergleichsrahmen Die bisher gefundenen Dimensionen und Vergleichskriterien sollen innerhalb dieses Kapitels genauer untersucht werden. Ziel ist das Finden entsprechender Ausprägungen und dazugehöriger Unterscheidungskriterien. Die Betrachtung wird hierbei in die definierenden und die nichtdefinierenden Dimensionen sowie in die weiteren Vergleichskriterien unterteilt. Sind die Ausprägungen gefunden, so erfolgt die Vorstellung einer möglichen grafischen Darstellung. 6.1 Definierende Dimensionen Ausprägungen Phasenabdeckung Vorgehensmodelle können verschiedene Phasen der Systementwicklung unterstützen, wobei spezielle Modelle nur für bestimmte Anwendungen gedacht sind. Die Ausprägungen von Noack und Schienmann sind Voruntersuchung, Systemanalyse, Entwurf, Erzeugung und Einführung. Sie beziehen sich hauptsächlich auf die Systemerstellung und betrachten keine umgebenden Tätigkeiten. Die Untergliederung von Chroust geht an dieser Stelle weiter. Der Ansatz von Chroust bildet die Grundlage für die im AK-VM verwendeten Ausprägungen, die hier Anwendung finden. Die Bandbreite der definierten Ausprägungen bezieht dabei die Unternehmensstrategie bis hin zum Abbau eines Systems ein. Definierende Frage: Welche Entwicklungsphasen werden durch das Vorgehensmodell unterstützt? Phasenabdeckung Unternehmensstrategie IT-Strategie Beschreibung Das VM bietet Unterstützung für die Gestaltung der Unternehmensstrategie mit Hilfe einer entsprechenden Politik und damit verbundenen Maßnahmen. Vorgesehen sind im VM verschiedene Aspekte zur 47

59 Gestaltung der IT-Strategie, wie z.b. Management des Projektportfolios und allgemeine Budgetplanung. Projektierung Konzeption Technischer Entwurf Realisation Betrieb Abbau Die für die Planung eines durchzuführenden Projekts nötigen Hilfsmittel werden bereitgestellt. Umgesetzt ist diese Phase meist durch das Projektmanagement und bietet z.b. Einsatzpläne, Balkendiagramme, etc., um die Hauptaufgaben der Projektorganisation abzudecken. Es werden die Grundlagen für die folgende Projektdurchführung gelegt. Unter Konzeption fallen die typischen Tätigkeiten der Anforderungsanalyse. Das VM unterstützt den Anwender z.b. bei der Erstellung des Pflichtenhefts und dem darauf aufbauenden Grobkonzept. Das vorliegende Grobkonzept wird zu einem Feinkonzept weiterentwickelt. Die technische Spezifikation sowie ein technisches Konzept werden definiert. Es erfolgt die Umsetzung des zu realisierenden Systems. Hierzu zählen Tätigkeiten wie die Programmierung, die Integration bis hin zur Installation. Das VM sieht begleitende Aktivitäten für den Betrieb des Systems wie Systemmonitoring, Verfügbarkeitsanalysen, etc. vor. Es ist eine Unterstützung für den Abbau des Systems, beispielsweise durch Anleitungen zur Demontage, zur Datenarchivierung oder zur Migration auf neue Anwendungen, vorhanden. Tabelle 6-1: Ausprägungen der Phasenabdeckung Prozessabdeckung Die Prozessabdeckung betrachtet die den Entwicklungsprozess begleitenden Tätigkeiten bzw. Modelle. Da diese Modelle ohne die Primärergebnisse der Entwicklung nicht sinnvoll anwendbar sind, muss entsprechend ein Submodell Systemerstellung existieren. Bei Noack und Schienmann ist diese Dimension in Entwicklung, Test, Projektma- 48

60 nagement, Qualitätssicherung, Change- und Configuration-Management sowie in Betrieb und Nutzung untergliedert. Die Einordnung des AK-VM bezeichnet diese Dimension als Submodelle und fügt weitere Ausprägungen, wie z.b. Benchmarking oder Wissensmodell, hinzu. Die Bezeichnung wurde hier als Prozessabdeckung und nicht als Submodelle gewählt, da die beschriebenen Tätigkeiten nicht explizit als Modelle umgesetzt sein müssen, sondern auch implizit aus dem gesamten Vorgehensmodell hervorgehen können. Definierende Frage: Welche Tätigkeiten oder Prozesse unterstützen die Systemerstellung? Prozessabdeckung Systemerstellung Projektmanagement Beschreibung Die eigentliche Systementwicklung ist im VM integriert. Hierzu zählen die Strukturierung der Produktionsschrittfolge und der Produktionsergebnisse sowie die Mittel und Methoden, mit denen sie produziert werden. Das Projektmanagement dient dem Planen, dem Initiieren und dem Kontrollieren von Projekten. Typische Aufgabenfelder sind Budget-, Termin- und Ressourcenplanung. Konfigurationsmanagement Das Konfigurationsmanagement stellt die Verwaltung der einzelnen Produkte dar. Hierzu zählen die Identifikation von Produkten und Änderungen sowie deren Kontrolle. Qualitätssicherung Leistungsmodell Benchmarking Die Qualitätssicherung gibt Qualitätsanforderungen, Prüffälle und Kriterien vor und unterstützt die Produkte bzw. den Prozess hinsichtlich der Einhaltung von Qualitätsanforderungen und Standards. Das VM verfügt über die Leistungsanalyse unterstützende Aufgabenfelder. Hauptsächlich betriebswirtschaftlich motiviert stehen Budgetanalysen und Kostenermittlungen im Vordergrund. Teile des Modells ermöglichen die Beurteilung der erreichten Ergebnisse anhand allgemeiner Zielgrößen und dem Grad ihrer Erfüllung. 49

61 Wissensmanagement Die aus den mit Hilfe des VM durchgeführten Projekten erhaltenen Erkenntnisse werden zur Wissensgewinnung und Wissenserhaltung archiviert. Die so gewonnenen Erfahrungen fließen in neue Projekte ein. Tabelle 6-2: Ausprägungen der Prozessabdeckung Formalisierung In einem Vorgehensmodell existiert eine Vielzahl von Beschreibungen der verschiedensten Formen. Die vorhandenen Vorschriften, Abhängigkeiten und Aktivitäten sind in einer bestimmten Art dargestellt. Die Formalisierung untersucht diesen Aspekt genauer und unterscheidet fünf Ausprägungen. Definierende Frage: Wie ist das Vorgehensmodell formalisiert? Formalisierung Verbal Semiformal Formal Symbolisch Beschreibung Die Elemente des VM sind verbal beschrieben. Die verwendeten Texte können sowohl in Normal- als auch in Fachsprache formuliert sein. Unter einer semiformalen Darstellung versteht sich die Beschreibung mit Hilfe einer eingeschränkten, teils natürlichen Sprache mit syntaktischen und semantischen Erweiterungen. Die Beschreibung erfolgt durch eine formale Sprache, beispielsweise eine Spezialsprache für die Definition von Vorgehensmodellen. Die im VM zu verdeutlichenden Sachverhalte werden durch zwei- oder auch dreidimensionale Grafiken dargestellt. Diese Beschreibung wird meist ergänzend genutzt, selten in alleiniger Anwendung. 50

62 Animiert Die Darstellung erfolgt mit Hilfe von Animationen. Diese Ausprägung besitzt für das VM rein ergänzenden Charakter. Tabelle 6-3: Ausprägungen der Formalisierung Abstraktionsstufe Der Begriff Vorgehensmodell wird für die verschiedensten, unterschiedlich konkreten Modelle angewendet. Zur Klassifizierung dieser Modelle dient der Aspekt der Abstraktionsstufe. Aus diesem Grund sind eine allgemeine und eine spezielle Untersuchung von Nöten. In der allgemeinen Betrachtung wird der Begriff des Vorgehensmodells weiter gefasst, um auch nicht der Definition entsprechende Modelle einordnen zu können. Die vier Ausprägungen sind eine Vereinfachung der acht Klassen, die im AK-VM verwendet werden. Neben dieser allgemeinen Untersuchung dient die spezialisierte Version dem Zweck, Vorgehensmodelle gemäß ihrer eigentlichen Definition zu untersuchen. Betrachtet wird durch diesen Blickwinkel der Detaillierungsgrad eines Vorgehensmodells, basierend auf den Niveaus von Vorgehensmodellen von Dr. Gerhard Chroust. Diese spezialisierte Sicht wird im Weiteren als Formalisierungsgrad bezeichnet. Definierende Frage (allgemein): In welcher Form ist das vorliegende Modell definiert? Abstraktionsstufe Metamodell Methodensammlung Framework Beschreibung Das Metamodell bietet eine Beschreibung von Syntax und Semantik eines zu entwerfenden Modells. Ein bestimmtes VM ist somit Instanz seines Metamodells. Das Modell besteht aus einer Sammlung von zueinander passenden Methoden. Der Umfang kann dabei zwischen einem vollständigen Methodenvorrat bis zu einzelnen, unvollständigen Methoden variieren. Ein Framework umfasst teilweise Definitionen des Vorgehens, unterstützt durch vorgegebene Bestandteile. Das Framework stellt einen Ordnungsrahmen her, der in den unterschiedlichsten Formen unterstützt werden kann. 51

63 Vorgehensmodell Das betrachtete Modell entspricht der Definition für VM. Die Unterstützung für die Systementwicklung ist umfassend definiert und kann bei bestimmten Modellen an die projektspezifischen Gegebenheiten angepasst werden. Tabelle 6-4: Ausprägungen der allgemeinen Abstraktionsstufe Definierende Frage (Formalisierungsgrad): Welchen Detaillierungsgrad besitzt das betrachtete Vorgehensmodell? Formalisierungsgrad Universell Weltlich Atomar Beschreibung Die Definition des VM beschränkt sich auf eine Beschreibung von prinzipiellen Schritten und gibt allgemeine Richtlinien vor. Das VM ist ausreichend stark detailliert beschrieben. Die Durchführung von Aktivitäten sowie deren Vorraussetzungen sind benannt und ermöglichen den direkten praktischen Einsatz dieses Vorgehens. Ein atomar realisiertes VM beschreibt die Prozessschritte sehr detailliert und legt genaue Bedingungen für deren Abfolge fest. Tabelle 6-5: Ausprägungen des Formalisierungsgrades Branchenfokus Der Branchenfokus untersucht die Bindung des Vorgehensmodells an bestimmte Bereiche der Systementwicklung. Für den Bereich der Software bestehen kaum Unterschiede zwischen einer Entwicklung für die Industrie oder für eine Behörde. Trotz dieser Ähnlichkeiten existieren Modelle, die speziell für die Erstellung von branchenspezifischen Systemen vorgesehen sind. Definierende Frage: Ist das Vorgehensmodell für eine bestimmte Branche ausgerichtet? 52

64 Branchenfokus Speziell Allgemein Beschreibung Das VM ist für eine spezielle Branche ausgerichtet und dementsprechend angepasst. Das VM ist auf keine spezielle Branche ausgerichtet und kann allgemein zur Systementwicklung zum Einsatz kommen. Tabelle 6-6: Ausprägungen des Branchenfokus Objektdomäne Die Objektdomäne betrachtet die Entwicklungsgegenstände des Vorgehensmodells näher. Aufgrund der Existenz von Modellen für die verschiedensten Systemtypen kann diese Dimension sehr viele Ausprägungen enthalten. Um eine gewisse Übersichtlichkeit zu bewahren, werden hier zwei Gruppen von Ausprägungen vorgestellt. Die allgemeinen Kriterien versuchen eine Einordnungsmöglichkeit für Vorgehensmodelle allgemein zu geben und unterscheiden z.b. in Software und Hardware. Die speziellen Eigenschaften charakterisieren die Objektdomäne für den Bereich der Softwareentwicklung und untersuchen die erzeugbaren Systeme. Die verwendete Unterteilung basiert auf den in [Fuch05] vorgestellten Softwaretypen. Definierende Frage (allgemeine Objektdomäne): Für welchen Entwicklungsgegenstand ist das Vorgehensmodell konzipiert? Objektdomäne Software Hardware Technische Systeme Beschreibung Das im Modell definierte Vorgehen ist speziell für die Entwicklung von Software vorgesehen und ist schlecht auf andere Entwicklungsgegenstände zu übertragen. Das Ziel der Entwicklung sind Hardwaresysteme wie z.b. PCs in den verschiedensten Formen oder auch einzelne Komponenten. Unter technischen Systemen werden z.b. Maschinenanlagen oder verkehrstechnische Systeme verstanden. Das VM unterstützt die notwendigen Entwicklungskriterien für die speziellen Anforderungen. 53

65 Betriebswirtschaftliche Systeme Volkswirtschaftliche Systeme Ein VM für betriebswirtschaftliche Systeme dient als Gestaltungsrahmen für ganze Unternehmen und betrachtet entsprechende Gesichtspunkte. Als Beispiel könnte GERAM in diese Kategorie eingeordnet werden. VM für volkswirtschaftliche Systeme betrachten die Zusammenhänge aus einem größeren volkswirtschaftlichen Blickwinkel. Tabelle 6-7: Ausprägungen der allgemeinen Objektdomäne Definierende Frage (softwarespezifische Objektdomäne): Ist das Vorgehensmodell für spezielle Softwaresysteme ausgerichtet und wenn ja, für welche? Objektdomäne Allgemein Standardsoftware Beschreibung Das VM legt sich nicht auf einen bestimmten Softwaretyp fest. Die angegebenen Entwicklungsvorschriften sind allgemein anwendbar und müssen gegebenenfalls für spezielle Systeme angepasst werden. Unter Standardsoftware verstehen sich z.b. Textverarbeitungs- oder Tabellenkalkulationssysteme. Das VM enthält speziell angepasste Vorgehensstrategien für die Entwicklung derartiger Produkte. Verteilte Anwendungen Das VM ist auf die Entwicklung verteilter Anwendungen oder Webanwendungen abgestimmt. Beispielhaft für diese Kategorie sind e-commerce Systeme oder Middleware. Datenbankapplikationen Die speziellen Anforderungen für Entwicklung von Datenbankapplikationen sind in das VM integriert und das Vorgehen ist entsprechend angepasst. Echtzeitsysteme Das VM unterstützt die Besonderheiten für die Entwicklung von Echtzeitsystemen, wie beispielsweise realtimeorientierte Modellierungssprachen. 54

66 Spezialsoftware Unter Spezialsoftware werden hier z.b. neuronale Netze oder Systeme der künstlichen Intelligenz verstanden, deren Entwicklungsanforderungen im VM berücksichtigt sind. Tabelle 6-8: Ausprägungen der softwarespezifischen Objektdomäne Vorgehensweise Der Aspekt der Vorgehensweise betrachtet die Gestaltung des Vorgehens. Als wichtigster Gesichtspunkt ist die Vorgehensweise des Prozessmodells zu untersuchen. Die verwendeten Ausprägungen lehnen sich an die Begriffsammlung des Arbeitskreises Begriffe und Konzepte der Vorgehensmodellierung der GI Fachgruppe 5.11 ([AKBK05]) an. Eine andere Ebene der Betrachtung stellt die Untersuchung des Vorgehens in der Programmierung vor. Diese Ebene muss in einem Vorgehensmodell nicht vorhanden sein, da die Umsetzung der zu erstellenden Produkte und Ergebnisse mitunter nicht im Umfang des Modells vorgesehen ist. Der Anwender kann in diesem Fall die Art der Implementierung selbst wählen. Speziell werden die verschiedenen Strukturparadigmen nach [Huss02] untersucht. Definierende Frage (Prozessvorgehensweise): Welche Vorgehensstrategie unterstützt das Vorgehensmodell? Vorgehensweise Evolutionär Inkrementell Iterativ Beschreibung Durch das betriebene System werden neue Anforderungen deutlich, die einen neuen Ausgangspunkt für einen weiteren Entwicklungszyklus darstellen. Meist findet dieses Vorgehen Anwendung bei Systemen, deren Anforderungen nicht genau von Anfang an bestimmt werden können. Die Software wird stückweise realisiert. Wichtig ist die Implementierung der grundlegenden Systemteile am Anfang der Entwicklung, um einen lauffähigen Systemkern umzusetzen. Die Softwareentwicklung entsteht aus einer Abfolge von verschiedenen Entwicklungszyklen. Ein Beispiel ist das von Boehm 1988 vorgestellte Spiralmodell. 55

67 Partizipativ Sequentiell Das partizipative Vorgehen basiert auf einer engen Kooperation zwischen Auftraggeber und Auftragnehmer. Die starke Einbeziehung des Nutzers in den Entwicklungsprozess verlangt ein Management zum Finden von Kompromissen. Die Entwicklung erfolgt nach dem klassischen Wasserfallmodell rein sequentiell und wird top-down vom Groben zur Verfeinerung und Implementierung geführt. Tabelle 6-9: Ausprägungen der Prozessvorgehensweise Definierende Frage (Programmiervorgehensweise): Schreibt das Vorgehensmodell Strukturparadigmen für die Programmierung vor? Wenn ja welche? Vorgehensweise Keine Vorgabe Strukturiert Modular Objektorientiert Beschreibung Das VM gibt für die Umsetzung des Entwicklungsgegenstandes keine Vorgaben. Ebenso fallen in diese Kategorie VM, die eine unstrukturierte Programmierung implizieren. Die Umsetzung des Systems wird mit Hilfe strukturierter Programmierung vorgeschlagen. Der Programmierer benutzt Blöcke, Prozeduren und Schleifen für die Implementierung des Problems. Die modulare Programmierung sieht eine Kapselung gewisser Blöcke mit einer genauen Abgrenzung durch die Definition von Schnittstellen vor. Gemäß dem objektorientierten Programmierparadigma werden die zu einem Baustein gehörigen Daten und Operationen in einer Klasse zusammengefasst. Klassen können ihre Eigenschaften vererben. 56

68 Komponentenorientiert Die zu realisierende Software wird in Komponenten gegliedert, die in entsprechender Kombination das System bilden. Durch Verwendung des komponentenorientierten Ansatzes wird ein hoher Grad der Wiederverwendung ermöglicht. Tabelle 6-10: Ausprägungen der Programmiervorgehensweise Prozesssteuerung Die Prozessteuerung klassifiziert Vorgehensmodelle nach dem Kriterium der Kontrolle der Abfolge von Entwicklungsschritten. Die verschiedenen Kontrollmechanismen werden in drei Klassen unterteilt. Die auf dem Artikel von Noack und Schienmann basierenden Ausprägungen bilden eine wichtige Grundlage für Gesichtspunkte wie die eventuelle Umsetzung des Systems, z.b. mit einem Workflow-Managementsystem. Definierende Frage: Wie werden die Entwicklungsschritte des Vorgehensmodells gesteuert? Prozesssteuerung Aktivitätsorientiert Ergebnisorientiert Vertragsorientiert Beschreibung Die auszuführenden Entwicklungsschritte im VM sind in Form verknüpfter Arbeitspläne beschrieben. Die Lösungen für bestimmte Aufgaben sind in einzelnen Schritten detailliert dargestellt. Ergebnisorientierte VM legen die durch bestimmte Aktivitäten zu erzeugenden Ergebnisse fest. Eine detaillierte Abfolge der Arbeitsschritte wird nicht definiert. Die Betrachtung des Entwicklungsprozesses erfolgt als Transformation und Evolution von Ergebnissen bzw. Dokumenten. Die Vorgehensweise wird durch situationsbedingte Entscheidungsmuster gebildet. Die Entwicklungstätigkeiten werden durch definierte Vor- und Nachbedingungen ausgewählt und bestimmen so die Auswahl und Durchführung von Aufgaben. Tabelle 6-11: Ausprägungen der Prozesssteuerung 57

69 6.1.2 Graphische Darstellung Die bisher definierten Dimensionen sind sehr vielschichtig und eine verbale Beschreibung aller gefundenen Eigenschaften eines Vorgehensmodells wäre sehr unübersichtlich. Es müsste für jede Übereinstimmung mit einer Ausprägung eine Bemerkung erfolgen und die daraus resultierenden Listen würden das Vergleichsergebnis darstellen. Bei der Untersuchung eines Vorgehensmodells müssen alle Dimensionen und Ausprägungen betrachtet werden. Eine überschaubare Variante der Darstellung dieser Ergebnisse bietet die Verwendung eines grafischen Modells. Um zu einer solchen Darstellung zu gelangen, sind die Dimensionen in Form von Achsen um einen zentralen Mittelpunkt zu legen. Auf diesen Achsen werden entsprechend der Anzahl der Ausprägungen der betrachteten Dimension Felder festgelegt. Die Felder sind bei nicht zutreffenden Eigenschaften weiß gefüllt. Bei vollkommener Übereinstimmung mit der Ausprägung sind sie schwarz auszufüllen. Kann für ein Feld kein vollkommenes Zutreffen bescheinigt werden, so ist es unter Angabe einer Erläuterung grau zu markieren. Neben dieser Art der graphischen Darstellung wurde eine Präsentation der erhaltenen Informationen mit Hilfe von Tabellen versucht. Die entstehenden Tabellen stellten sich jedoch als sehr unübersichtlich und nicht aussagekräftig heraus. Die folgende Tabelle zeigt beispielhaft, wie ein Analyseergebnis in dieser Darstellungsform erscheinen würde: Kriterium Generizität Phasenabdeckung Sub-Komponenten Objekt-Domäne Branchenfokus Formalisierung Tabelle 6-12: Beispiel einer graphischen Darstellung mit Tabellen, Quelle: [AKVM05] Diese Tabelle stammt aus einem temporären Arbeitspapier des AK-VM und sollte die sechs definierenden Dimensionen repräsentieren. Dieser Darstellungsansatz wurde aufgrund seiner nichtpraktikablen Anwendbarkeit verworfen. 58

70 Die folgende Abbildung zeigt das graphische Modell des AK-VM für die definierenden Dimensionen, welches die Grundlage für das hier erarbeitete Modell darstellt: Abbildung 6-1: Graphisches Modell des AK-VM, definierende Dimensionen, Quelle: [AKVM05] Die im Rahmen dieser Arbeit erstellten Dimensionen lehnen sich an dieses Modell an, sind jedoch in bestimmten Punkten verfeinert, vereinfacht oder ergänzt worden. Aufgrund der jetzt vorliegenden elf Dimensionen ist eine Darstellung in einem graphischen Modell schlecht möglich. Die Übersichtlichkeit der entstehenden Abbildung wäre nicht mehr gewährleistet. Somit besteht die Notwendigkeit der Aufteilung in zwei Teilmodelle. Als Kriterium soll die Nähe der untersuchten Eigenschaften zur Softwareentwick- 59

71 lung dienen. Die allgemeine Betrachtung kann für die Analyse von beliebigen Vorgehensmodellen verwendet werden. Das zweite Modell widmet sich den speziellen Vorgehensmodellen für die Softwareentwicklung Allgemeine Eigenschaften von Vorgehensmodellen Unter den allgemeinen Eigenschaften werden diejenigen verstanden, die für die meisten Vorgehensmodelle anwendbar sind. Die vorliegenden Definitionen bieten die nötige Flexibilität, um z.b. auch Vorgehensmodelle für die Hardwareentwicklung einzuordnen. In dieses Teilmodell fließen die Dimensionen Prozessabdeckung, Formalisierung, Branchenfokus sowie die allgemeinen Ausprägungen der Abstraktionsstufe und der Objektdomäne ein. Abbildung 6-2: Allgemeine, definierende Eigenschaften von Vorgehensmodellen Um die Anwendung dieses graphischen Modells zu verdeutlichen, soll folgendes Beispiel dienen. Es handelt sich dabei um ein fiktives Modell für die Erstellung von Prozessoren. 60

72 Anwendungsbeispiel: - Branchenfokus: Es wird keine Hardware im Allgemeinen entwickelt, sondern speziell Prozessoren. - Abstraktionsstufe: Das Modell bietet eine Auswahl an verschiedenen Methoden und wird somit als Methodensammlung kategorisiert. - Prozessabdeckung: Die angebotenen Methoden unterstützen die Systemerstellung und das Projektmanagement. Das Konfigurationsmanagement ist nur ansatzweise unterstützt und deshalb grau markiert. - Objektdomäne: Prozessoren sind Hardware. - Formalisierung: Die Teile des Modells sind verbal beschrieben und an passenden Stellen durch Graphiken ergänzt. Abbildung 6-3: Beispiel für die allgemeinen, definierenden Eigenschaften von Vorgehensmodellen 61

73 Softwarespezifische Eigenschaften von Vorgehensmodellen Die Eigenschaften softwarespezifischer Vorgehensmodelle untersuchen Modelle, die speziell für die Entwicklung von Software vorgesehen sind. Die darzustellenden Dimensionen sind die Spezialisierungen der Abstraktionsstufe (der Formalisierungsgrad) und der Objektdomäne. Weiterhin werden die Prozesssteuerung, die Phasenabdeckung und die Vorgehensweisen betrachtet. Die Vorgehensweisen untergliedern sich dabei in die vorgeschlagene Programmiervorgehensweise und die Prozessvorgehensweise. Objektdomäne Abbildung 6-4: Softwarespezifische, definierende Eigenschaften von Vorgehensmodellen Die Verwendung dieses graphischen Modells wird mit folgendem hypothetischen Vorgehensmodell verdeutlicht: 62

74 Anwendungsbeispiel: - Formalisierungsgrad: Die einzelnen Schritte sind detailliert beschrieben, jedoch nicht atomar. - Objektdomäne: Es werden keine speziellen Softwaresysteme fokussiert. - Phasenabdeckung: Das Modell unterstützt die Entwicklung von der Projektierung bis zur Realisation. Es werden teilweise Vorgaben für den Betrieb gegeben, jedoch keine vollständige Betriebsüberwachung. - Prozessvorgehensweise: Die Software wird iterativ erstellt. - Programmiervorgehensweise: Vorgeschlagen wird die komponentenorientierte Implementierung. - Prozesssteuerung: Der Prozess wird durch Ergebnisse gesteuert. Abbildung 6-5: Beispiel für die softwarespezifischen, definierenden Eigenschaften von Vorgehensmodellen 63

75 6.2 Nichtdefinierende Dimensionen Ausprägungen VM-Präsentation Ein Vorgehensmodell kann in verschiedenen Formen veröffentlicht bzw. verteilt werden. Beispielsweise existieren für den RUP HTML-basierte Ausgaben sowie verschiedene Bücher, um das Modell zu beschreiben. Ziel dieser Dimension ist, diese möglichen Präsentationsformen in einige Kategorien einzuordnen. Eine Unterscheidung erfolgt in Papier, E-Book, hypertextbasiert und browserbasiert. Definierende Frage: In welcher Form wird das Vorgehensmodell verbreitet? VM-Präsentation Papier E-Book Hypertextbasiert Browserbasiert Beschreibung Das VM wird in Form von Büchern publiziert. Auch kleinere Modelle, die z.b. im Rahmen von Tagungsbeiträgen oder in Form von Papers veröffentlicht werden, fallen in diese Kategorie. Ein veröffentlichtes E-Book stellt die elektronische Version der Papierkategorie dar. Das Modell liegt beispielsweise als PDF-Datei vor, jedoch werden die Möglichkeiten der Informationstechnik nicht genutzt. Die Darstellung erfolgt mit Hilfe von Hypertext, z.b. durch ein Dokument im Internet. Die auf Hypertext basierende Präsentation nutzt den Browser als integralen Bestandteil der Darstellung und auch der Anwendung des Modells. Tabelle 6-13: Ausprägungen der VM-Präsentation 64

76 Werkzeugbindung Die Werkzeugbindung analysiert, wie die Werkzeuge im Vorgehensmodell betrachtet werden und in welcher Form eine eventuelle Empfehlung erfolgt. Ein Modell kann z.b. aus einer reinen Definition des Vorgehens bestehen und dem Anwender bei der Wahl der Werkzeuge völlig freie Hand lassen. Andererseits kann ein Modell auch an eigene Produkte des Herstellers gebunden sein. Um hier eine Unterteilung zu ermöglichen, besitzt die Werkzeugbindung vier Ausprägungen. Definierende Frage: Welche Form der Werkzeugempfehlung liegt im Vorgehensmodell vor? Werkzeugbindung Unabhängig Referenzmodell Marktnah Eigene Tools Beschreibung Das VM gibt für die Nutzung von Werkzeugen keine Vorgaben. Die Werkzeugunterstützung wird im VM mit Hilfe eines Referenzmodells ausgedrückt. Das Spektrum kann sich hierbei von einem vollständigen Referenzmodell für die zu verwendenden Tools bis zur einfachen Beschreibung der Anforderungen an die Werkzeuge erstrecken. Für die Unterstützung des VM durch Werkzeuge werden für bestimmte Tätigkeiten am Markt befindliche Produkte vorgeschlagen. Die Tools können dabei sowohl Eigenprodukte als auch Werkzeuge von Drittanbietern sein. Die angegebenen Werkzeugreferenzen beziehen sich ausschließlich auf Produkte des Herstellers des VM. Im Extremfall kann ein solches Modell lediglich mit diesen Produkten umgesetzt werden. Tabelle 6-14: Ausprägungen der Werkzeugbindung Toolsupport Die für die Umsetzung des Vorgehensmodells vorgesehenen Werkzeuge müssen den Entwicklungsprozess nicht vollständig unterstützten. Ziel des Toolsupports ist die Be- 65

77 trachtung dieses Gesichtspunkts und die Kategorisierung gemäß der gebotenen Abdeckung der auszuführenden Tätigkeiten durch Werkzeuge. Definierende Frage: Wie umfassend sind die Teile des Vorgehensmodells mit Werkzeugen abgedeckt? Toolsupport Kein Support Datenablage Partialsupport Phasensupport Totalsupport Beschreibung Das VM wird durch keinerlei Werkzeuge unterstützt. Die Werkzeugunterstützung ist durch eine unter Umständen gemeinsame Nutzung einer Datenablage für die Ergebnisse der Aktivitäten, beispielsweise durch eine Datenbank, minimal gewährleistet. Das VM sieht ein oder mehrere Werkzeuge für eine teilweise Unterstützung der Entwicklungsschritte vor. Die Tools decken jedoch nicht alle Aktivitäten ab. Die angebotenen Werkzeuge unterstützen den Entwickler über alle Phasen und in allen Tätigkeiten. Die Produkte unterstützen den Entwickler über den Phasensupport hinaus durch die Gestaltung von Navigationsdialogen. Der Nutzer wird durch die einzelnen Phasen und Aktivitäten geführt und instruiert. Tabelle 6-15: Ausprägungen des Toolsupport Automatisierungsgrad Die bisher analysierten Dimensionen betrachten das Maß der Werkzeugunterstützung und deren Umfang. Der Automatisierungsgrad dient der Klassifikation nach dem Gesichtspunkt, welchen Beitrag die Tools zur Automatisierung des Vorgehensmodells bieten. Der Blickwinkel liegt dabei vor allem auf der Produktivitätssteigerung, die durch den Einsatz erreichbar ist. Definierende Frage: Wie wirkt sich die Werkzeugunterstützung des Vorgehensmodells aus? 66

78 Automatisierungsgrad Manuell Formatierend Konsistenzprüfend Interproduktiv Generierend Beschreibung Die Automatisierung des VM muss manuell erfolgen, da es keine Vorgaben für Werkzeuge enthält. Das VM bietet dem Entwickler zur Unterstützung verschiedene Vorlagen, beispielsweise Wordvorlagen mit Formatierungen und Makros. Die vorgeschlagenen Werkzeuge unterstützen den Entwickler durch die Prüfung der Konsistenz der einzelnen Ergebnisse. Warnungen und Prüfprozeduren müssen somit integriert sein. Die Tools ermöglichen dem Nutzer die Übergabe von Entwicklungsergebnissen von einem Entwicklungsschritt zum nächsten. Eine Prozessteuerung ist in einem gewissen Umfang vorhanden. Der Entwickler wird weit reichend bei der Entwicklung unterstützt. Die Entwurfsobjekte werden teilweise durch die Tools generiert. Beispielsweise erzeugt ein Werkzeug aus Analyseergebnissen ein Datenmodell. Tabelle 6-16: Ausprägungen des Automatisierungsgrades QS-Beitrag Der Einsatz eines Vorgehensmodells sollte prinzipiell eine Steigerung der Qualität der entwickelten Produkte nach sich ziehen. Eine Aussage über deren Tragweite soll hier jedoch nicht betrachtet werden. Die Dimension des QS-Beitrags untersucht die Auswirkungen bzw. die Art der Sicherstellung der Qualität in Verbindung mit der Verwendung von Werkzeugen. In welchem Rahmen die Qualitätsprüfung erfolgt, steht dabei im Mittelpunkt der Analyse. Definierende Frage: Wie bzw. in welchem Rahmen erfolgt die Qualitätsprüfung? 67

79 QS-Beitrag Intrakonsistenz Interkonsistenz Auditsupport Zertifikatssupport Beschreibung Es werden einzelne Ergebnisse auf ihre Konsistenz überprüft. Warnungen erfolgen bei Mehrfachdefinitionen und Widersprüchen. Der Entwickler erhält Warnungen bei Konsistenzverstößen zwischen den verschiedenen Ergebnissen bzw. Produkten. Das Vorliegen von Intrakonsistenz wird vorausgesetzt. Neben den Ergebnissen werden auch die Aktivitäten automatisch überprüft und mit den für die Audits festgelegten Kriterien abgeglichen. Die Ergebnisse und Aktivitäten werden gemäß den Anforderungen an eine Zertifizierung automatisiert ausgeführt. Tabelle 6-17: Ausprägungen des QS-Beitrags Systemhierarchie Die Systemhierarchie betrachtet die Untergliederung der Entwicklungsergebnisse des Vorgehensmodells. Die in den Entwicklungsphasen entstehenden Ergebnisse bestehen wiederum aus diversen Teilergebnissen. Gesamt bildet dies eine hierarchische Struktur. Deren Untersuchung bietet eine Aussage über die Anforderungen, die an eine mögliche unterstützende Entwicklungsumgebung bestehen. Die Unterscheidung erfolgt in flache, tiefe und vernetzte Hierarchie. Aus Gründen der Einfachheit und Überschaubarkeit wird diese Dimension nur mit diesen drei Ausprägungen versehen. Eine exakte Bestimmung des Komplexitätsgrades der Ergebnishierarchie ließe sich beispielsweise durch die so genannte zyklomatische Zahl bzw. die McCabe-Metrik erstellen. Die McCabe-Metrik zielt in ihrer eigentlichen Definition auf Kontrollflussgraphen von Programmen ab. Sie ist jedoch durchaus auf das Problemfeld der Vorgehensmodelle und den Abhängigkeiten zwischen ihren Ergebnissen übertragbar. Weitere Informationen zu McCabe-Metriken finden sich in [Fähn02], [Gräb04] und [WaMc96]. Definierende Frage: Wie ist die Ergebnishierarchie organisiert? 68

80 Systemhierarchie Flach Tief Vernetzt Beschreibung Die Ergebnisse sind kaum oder gar nicht hierarchisch organisiert. Das System bewegt sich auf ein oder zwei Ebenen. Es liegt eine tiefe Hierarchie vor, die sich über mehrere Ebenen erstreckt. Die Teilergebnisse werden innerhalb nur eines Produktes benötigt. Die einzelnen Teile sind tief hierarchisch angeordnet. Zusätzlich bestehen Verknüpfungen zwischen den einzelnen Teilergebnissen verschiedener Produkte. Tabelle 6-18: Ausprägungen der Systemhierarchie Graphische Darstellung Die graphische Darstellung dieser sechs Dimensionen erfolgt analog zu den Eigenschaften der definierenden Dimensionen. Die vorgeschlagenen Ausprägungen werden in Form von leeren Feldern auf den die Dimensionen repräsentierenden Achsen dargestellt und bei Übereinstimmung entsprechend markiert bzw. gefüllt. Die Grundlage für diese Graphik liegt ebenfalls im AK-VM, dessen Modell in der folgenden Abbildung dargestellt wird: 69

81 Abbildung 6-6: Graphisches Modell des AK-VM, nichtdefinierende Dimensionen, Quelle: [AKVM05] Das hier vorgestellte Modell verfügt über zwei weitere Dimensionen und ist somit umfangreicher. Die aus dem AK-VM übernommen Dimensionen, die teilweise verändert wurden, sind in einer anderen Ordnung dargestellt, um eine eventuelle Quantifizierung zu vereinfachen. 70

82 Werkzeugbindung QS Beitrag Abbildung 6-7: Nichtdefinierende Eigenschaften von Vorgehensmodellen Das folgende Beispiel dient zur Verdeutlichung der Anwendung dieses graphischen Modells. Die Grundlage für die Darstellung bilden folgende hypothetischen Analyseergebnisse. Anwendungsbeispiel: - VM-Präsentation: Das Modell wird in Form von Büchern, E-Books und HTML vertrieben. 71

83 - Werkzeugbindung: Es werden allgemeine Anforderungen an Werkzeuge beschrieben. Somit erfolgt die Einordnung als Referenzmodell. - Toolsupport: Die Referenzen decken nur Teile der Phasen ab. - Automatisierungsgrad: Die werkzeugunterstützten Phasen des Modells können ein interproduktives Arbeiten ermöglichen. - QS-Beitrag: Die Qualitätsprüfung bezieht sich nur auf einzelne Ergebnisse. - Systemhierarchie: Die Systemhierarchie ist tief gegliedert. Abbildung 6-8: Beispiel für die nichtdefinierenden Eigenschaften von Vorgehensmodellen 72

84 6.3 Weitere Vergleichskriterien Die weiteren Vergleichskriterien untersuchen die Gesichtspunkte näher, die nicht mit Ausprägungen versehen werden können. Die bisher vorgestellten Dimensionen ermöglichten jeweils eine bestimmte Anzahl von Unterteilungen. Bei den Vergleichskriterien Terminologie und Prozessarchitektur ist dies nicht möglich. Aus diesem Grund muss für sie eine individuelle Vergleichsbetrachtung erfolgen. Ziel dieses Kapitels ist die Vorstellung einer Vorgehensmöglichkeit für die Betrachtung dieser Vergleichskriterien. Weiterhin ist zu beachten, dass hier, im Gegensatz zu den Dimensionen, keine allgemeine Einordnung des betrachteten Vorgehensmodells möglich ist. Die Terminologie und die Prozessarchitektur können nur zwischen mindestens zwei Modellen verglichen werden. Im Weiteren wird eine Gestaltungsmöglichkeit für einen solchen Vergleich vorgeschlagen Terminologie Vorgehensmodelle benutzten für die Darstellung ihrer Inhalte verschiedene Ausdrucksweisen. Um einen Vergleich zu erleichtern, bietet sich deshalb eine Untersuchung der verwendeten Begriffe zu Beginn der Betrachtung an. Meist bestehen zwischen den Bezeichnungen innerhalb der Vorgehensmodelle Ähnlichkeiten, und es existiert eine sinngemäße Übereinstimmung zwischen den Terminologien. Das empfohlene Vorgehen für eine solche Gegenüberstellung ist eine tabellarische Erfassung für die wichtigsten Begriffe. Weiterhin bietet sich eine Gegenüberstellung mit einem definierten, von dem Vorgehensmodell unabhängigen, Begriffsschema an. Diese Art der Untersuchung wird ebenfalls von Noack und Schienmann vorgeschlagen. Die definierten Begriffe zur Unterscheidung der wesentlichen Beschreibungselemente sind bei [NoSc99] Phase, Aktivität, Ergebnis, Rolle, Technik, Richtlinie und Standard sowie Notation. Deren Definitionen zeigt folgende Tabelle: Terminus Beschreibung Phase Eine Phase gruppiert die Aktivitäten eines VM zu einer planund kontrollierbaren Einheit. Weiterhin dienen Phasen meist der Einteilung des Entwicklungsprozesses nach zeitlichen Gesichtspunkten. 73

85 Aktivität Ergebnis Rolle Technik Richtlinie / Standard Notation Eine Aktivität legt die durchzuführenden Aufgaben in gewissem Sinn in Form einer Arbeitsanleitung fest. Eine Aktivitätseinheit besteht meist aus teilweise über mehrere Ebenen verfeinerten Teilaktivitäten. Ein Ergebnis entsteht durch die Ausführung einer Aktivität. Sie können ebenfalls aus diversen Teilergebnissen bestehen. Durch Rollen werden abstrakte Personen mit ihren benötigten Fähigkeiten, Kenntnissen und Erfahrungen beschrieben. Techniken definieren, wie bestimmte Aktivitäten auszuführen sind. Eine Aktivität kann zu ihrer Realisierung mehrere Techniken einsetzten. Richtlinien und Standards dienen der Überprüfung der Entwicklungsergebnisse und der Gestaltung von Konventionen zum Austausch zwischen den Projekten. Sie sind Inhalt der Aktivitäten. Hier unterscheidet man die verwendeten Notationen oder Sprachen für die Darstellung der Ergebnisse des Entwicklungsprozesses. Tabelle 6-19: Wesentliche Beschreibungselemente, nach [NoSc99] Ein wesentliches Beschreibungselement, das dem Vorschlag von Noack und Schienmann fehlt, ist der Begriff des Prozesses. Diese Definition soll an dieser Stelle erfolgen und in die gegebene Unterscheidung mit eingefügt werden. Prozess (nach [NoSc99]) Ein Prozess fasst komplementäre, rollenspezifische Aufgabenbereiche zusammen, die kontinuierlich wahrzunehmen sind. Beispiele sind neben dem eigentlichen Entwicklungsprozess das Projektmanagement oder das Konfigurationsmanagement. Die Betrachtung der Terminologie ist schwer eingrenzbar, da eine Untersuchung auf beliebiger Ebene erfolgen kann. Die Analyse auf diesem relativ hoch angesiedelten Niveau geht dabei nicht zu tief in das Vorgehensmodell hinein. Die Gestaltung dieses Vergleichs ist somit dem Anwender der Methodik überlassen, der selbst bestimmend die 74

86 Tiefe seiner Betrachtung auswählt. Beispielsweise kann dies bis zur Untersuchung der eventuell durch Übersetzung auftretenden Begriffsvariationen verfeinert werden. Empfehlenswert für die Verwendung des gegebenen Vergleichsrahmens ist die Untersuchung der in diesem Rahmen benötigten Termini. Für die Betrachtung der Prozessabdeckung ist beispielsweise eine Übersicht über die einzelnen Bezeichnungen der Ausprägungen hilfreich Prozessarchitektur Mit Hilfe der Prozessarchitektur soll die Gestaltung der dem Vorgehensmodell zu Grunde liegenden zeitlichen und sachlogischen Anordnung der Prozesselemente untersucht werden. Vorgesehen ist hierbei eine die Analyse gemäß dem Vergleichsrahmen ergänzende bzw. unterstützende Betrachtung. Die meisten Vorgehensmodelle verfügen über eine graphische Darstellung, die die wichtigsten Bestandteile und Phasen des Gesamtmodells verdeutlicht. Empfohlen wird aus diesem Grund eine Gegenüberstellung und begleitende Beschreibung basierend auf diesen Graphiken. Dieses Vorgehen soll ein zu detailliertes Eingehen auf eventuell irrelevante Gesichtspunkte verhindern. Die Ausgestaltung dieses Vergleichs bleibt jedoch dem Nutzer dieses Vergleichsrahmens überlassen. Somit kann der für den benötigten Einsatzzweck passende Detaillierungsgrad frei gewählt werden. 75

87 7 Quantifizierung Die bisher beschriebenen Dimensionen und deren graphische Darstellung dienen der Verdeutlichung verschiedenster Eigenschaften von Vorgehensmodellen. Die gewählte Darstellungsform ist keine wissenschaftliche Repräsentation im eigentlichen Sinne. Die verschiedenen Ausprägungen sind teilweise voneinander unabhängig oder besitzen Überschneidungen. Ziel dieses Kapitels ist die Untersuchung hinsichtlich des Findens von geeigneten Dimensionen für die Darstellung mit Hilfe von Kiviat-Graphen. Kiviat-Graphen dienen der visuellen Darstellung verschiedenster Kennzahlen. Grundlage für die Anwendung ist die Gestaltung der Dimensionen in einer aufsteigenden Ordnung. Das heißt, eine höhere Ausprägung ist qualitativ oder quantitativ höher gestellt als eine andere bzw. enthält die niedrigeren. Die Dimensionen werden auf Achsen abgebildet und deren Ausprägungen durch Punkte markiert. Je weiter ein Punkt vom Mittelpunkt entfernt ist, umso besser ist seine Ausgestaltung, quantitativ oder qualitativ. Eine Aussage über alle betrachteten Dimensionen und somit über das Gesamtmodell ermöglicht sich durch die Verbindung der einzelnen Punkte und Errechnung des Flächeninhalts des entstehenden Polygons. Zur Verdeutlichung der Anwendung dient folgende Abbildung: Abbildung 7-1: Beispiel eines Kiviat-Graphs, Quelle: [PGFL05] Das Problem im weiteren Vorgehen besteht in der Gestaltung der gefundenen Dimensionen gemäß diesen Vorschriften. Eine derartige Ordnung ist in der jetzt vorliegenden Form nicht möglich und wird auch für einige Vergleichskriterien nicht möglich sein. Metriken, die in dieser Art darstellbar sind, beziehen sich bisher auf die quantitative Analyse von Vorgehensmodellen. Die beispielsweise in [GaRP04] angebotenen Metriken bzw. Untersuchungskriterien analysieren Softwareprozessmodelle nach Anzahl der angebotenen Aktivitäten, Produkten, Rollen und weiteren. Diese Form der Analyse gibt 76

88 jedoch keinerlei Auskunft über die Ausgestaltung des Modells und ermöglicht keine Aussagen über einen eventuellen Einsatzzweck oder die angewendeten Methoden. Der hier vorgestellte Rahmen bezieht diese Gesichtspunkte mit ein und geht somit weit über eine Quantifizierung des Vorgehensmodells hinaus. Aus diesem Grund wird der Begriff der Quantifizierung hier weiter gefasst und steht allgemein für die Definition einer Ordnung für die ausgewählten Dimensionen, um eine Darstellung mit Hilfe von Kiviat-Graphen zu ermöglichen. Somit steht Quantifizierung auch für die Ordnung von qualitativen Eigenschaften. Das weitere Vorgehen unterscheidet eine allgemeine und eine individuelle Quantifizierung. Die allgemeine Quantifizierung untersucht alle gefundenen Dimensionen nach ihrer Darstellungsmöglichkeit, ohne eine Wertung bestimmter Kriterien vorzunehmen. Die individuelle Quantifizierung bietet dem Nutzer die Möglichkeit einer Bewertung der verschiedenen Eigenschaften und somit auch der Analyse von Kriterien, die in der allgemeinen Betrachtung nicht bewertet werden können. 7.1 Allgemeine Quantifizierung Die allgemeine Quantifizierung untersucht die vorgestellten Dimensionen gemäß der Quantifizierungsmöglichkeit aus allgemeinen Gesichtspunkten und definiert gegebenenfalls Ausprägungen. Die auf diese Weise ausgewählten Kriterien werden anschließend in einem graphischen Modell zusammengefasst. Die Unterscheidung in definierende und nichtdefinierende Dimensionen wird beibehalten Definierende Dimensionen Quantifizierung Betrachtet werden im Folgenden alle gefundenen Dimensionen. Besteht die Möglichkeit einer Quantifizierung, so wird diese dargestellt. Der Blickwinkel wird dabei auf die Untersuchung von Vorgehensmodellen für die Softwareentwicklung eingeschränkt, um das Modell möglichst einfach zu halten. 77

89 Phasenabdeckung Die in der Phasenabdeckung untersuchte Unterstützung der Entwicklungsphasen eines Vorgehensmodells ist mit Hilfe einer numerischen Abbildung quantifizierbar. Die Ausprägungen Unternehmensstrategie und IT-Strategie werden dabei von der Betrachtung ausgeschlossen. Typische Vorgehensmodelle für die Softwareentwicklung bieten meist keine derartige Unterstützung. Die somit verbleibenden Ausprägungen sind Projektierung, Konzeption, Technischer Entwurf, Realisation, Betrieb und Abbau. Die Quantifizierung erfolgt durch eine Auszählung der unterstützten Phasen. Das Spektrum reicht somit von eins bis sechs, da mindestens eine Phase und maximal sechs Phasen umgesetzt sein können. Unter Angabe einer Erläuterung sind auch Werte wie 4,5 möglich, wenn beispielsweise der Betrieb des Systems nur teilweise berücksichtigt wird. Quantifizierungsspektrum: [1.. 6]: erhalten durch Auszählung der unterstützten Phasen Prozessabdeckung Die Abdeckung der den Entwicklungsvorgang begleitenden Prozesse kann ebenfalls mit Hilfe einer Auszählung quantifiziert werden. Grundlegend ist die Umsetzung des Systementwicklungsprozesses. Weiterhin erfolgt die Betrachtung des Projektmanagements, des Konfigurationsmanagements und der Qualitätssicherung. Die vorgestellten Ausprägungen Leistungsmodell, Benchmarking und Wissensmanagement werden in dieser Betrachtung nicht untersucht. Die Quantifizierung erfolgt analog zur Phasenabdeckung. Das Spektrum reicht somit von eins bis vier. Unter Angabe einer Begründung sind ebenfalls nichtnatürliche Zahlen zulässig. Quantifizierungsspektrum: [1..4]: erhalten durch Auszählung der angebotenen Prozesse Formalisierung Die Formalisierung verbindet in ihrer jetzigen Gestaltung zwei verschiedene Blickwinkel. Einerseits wird die verwendete Sprache bzw. deren Formalisierung untersucht. An- 78

90 dererseits wird deren Darstellung charakterisiert. Eine Quantifizierung ist somit in dieser Form nicht möglich. Es muss eine Aufteilung erfolgen. Unter der Sprachformalisierung wird die Gestaltung der verwendeten Sprache verstanden. Eine Unterteilung erfolgt in drei Stufen gemäß folgender Definition. Quantifizierungsspektrum: [1..3]: gemäß folgender Tabelle: Sprachformalisierung Entsprechung 1 Informal 2 Semiformal 3 Formal Tabelle 7-1: Quantifizierung der Sprachformalisierung Der zweite zu betrachtende Gesichtspunkt ist die gewählte Darstellungsform des Vorgehensmodells. Es werden ebenfalls drei Stufen unterschieden. Quantifizierungsspektrum: [1..3]: gemäß folgender Tabelle: Darstellungsform Entsprechung 1 Verbal 2 Symbolisch 3 Animiert Tabelle 7-2: Quantifizierung der Darstellungsform Abstraktionsstufe Die in der Dimension der Realisationsstufe vorgestellten Ausprägungen verfügen über eine Ordnung. Somit ermöglicht sich eine Abbildung auf Zahlenwerte sowohl für die allgemeine als auch für die spezielle Abstraktionsstufe (der Formalisierungsgrad). 79

91 Aufgrund der Festlegung auf softwarespezifische Vorgehensmodelle findet hier nur der, auf Chroust basierende, Formalisierungsgrad Verwendung. Die Detaillierungsgrade werden auf die Werte eins bis drei abgebildet. Das universelle Modell erhält die Realisationsstufe eins, da es am wenigsten ausführlich definiert ist. Quantifizierungsspektrum: [1..3]: gemäß folgender Tabelle: Formalisierungsgrad Entsprechung 1 Universell 2 Weltlich 3 Atomar Tabelle 7-3: Quantifizierung des Formalisierungsgrades Branchenfokus Der Branchenfokus besitzt die Ausprägungen allgemein und speziell. Deren Abbildung auf numerische Werte ist recht einfach zu realisieren. Das allgemeine Vorgehensmodell soll in diesem Fall mit dem höheren Wert belegt werden, da es sicherlich mächtiger definiert ist als die entsprechende spezialisierte Version. Quantifizierungsspektrum: [1..2]: gemäß folgender Tabelle: Branchenfokus Entsprechung 1 Speziell 2 Allgemein Tabelle 7-4: Quantifizierung des Branchenfokus 80

92 Objektdomäne Die Objektdomäne ist weder in ihrer allgemeinen noch in der spezialisierten Variante quantifizierbar. Die allgemeine Form mit den Ausprägungen Software, Hardware, technische, betriebswirtschaftliche und volkswirtschaftliche Systeme kann auf kein Ordnungsschema abgebildet werden. Die spezialisierte Version der Objektdomäne untersucht die mit Hilfe des Vorgehensmodells erzeugbaren Softwaresysteme. Eine Abbildung der Ausprägungen könnte lediglich auf die Werte allgemein und speziell erfolgen. Der daraus resultierende Informationsgehalt bietet im Vergleich zum Branchenfokus jedoch keine neue Qualität Vorgehensweise Die Vorgehensweise ist in die Prozess- und in die Programmiervorgehensweise untergliedert, die beide nicht auf ein Ordnungsschema abgebildet werden können. Die Prozessvorgehensweise unterscheidet in evolutionär, inkrementell, iterativ, partizipativ und sequentiell. Um eine Ordnung zu finden, müssten bestimmte Ausprägungen als qualitativ hochwertiger als andere definiert werden. Dies ist jedoch nicht möglich, da bestimmte Vorgehensweisen für manche Projekte sinnvoll sind und für andere wiederum nicht. Für die Programmiervorgehensweise gilt dies analog. So ist z.b. in manchen Projekten die modulare Programmierung der objektorientierten vorzuziehen, in anderen jedoch nicht Prozesssteuerung Die Prozesssteuerung bietet eine Klassifizierung von Vorgehensmodellen nach dem Gesichtspunkt der Steuerung der Entwicklungsschritte. Die definierten Ausprägungen sind aktivitäts-, ergebnis- und vertragsorientiert. Welche dieser Steuerungsformen zu bevorzugen ist, kann in der allgemeinen Betrachtung nicht festgelegt werden, da diese Entscheidung nur projektspezifisch getroffen werden kann. Somit ist in der allgemeinen Betrachtung keine Quantifizierung möglich Graphisches Modell Aus den diskutierten Dimensionen ist ein der Definition entsprechender Kiviat-Graph zu entwickeln. Die allgemein darstellbaren Dimensionen und ihre Wertebereiche sind: 81

93 Dimension Wertebereich Phasenabdeckung [1..6] Prozessabdeckung [1..4] Sprachformalisierung [1..3] Darstellungsform [1..3] Formalisierungsgrad [1..3] Branchenfokus [1..2] Tabelle 7-5: Wertebereiche der allgemein quantifizierbaren, definierenden Dimensionen Die Gestaltung des Kiviat-Graphs erfolgt gemäß der Anleitung in [Kozu05] und [PGFL05]. Die Minima und Maxima sind definiert durch die oben angegebenen Wertebereiche. Der Graph verwendet zur Darstellung der Dimensionen sechs Achsen. Der minimale Wert, in allen Fällen eins, bildet den inneren Kreis. Das Maximum wird durch den äußersten Kreis definiert und ist je nach Dimension als sechs, vier, drei oder zwei festgelegt. Um die Darstellung möglichst übersichtlich zu gestalten, wird zu dem Minimum von eins ein Offset einer hypothetischen Längeneinheit hinzugefügt. Somit beginnen die Achsen bei der Längeneinheit zwei. Die mit sechs Ausprägungen versehene Dimension der Phasenabdeckung dient als Orientierungsvorlage und veranlasst die Zeichnung von sechs Kreisen um den Mittelpunkt. Die für die einzelnen Dimensionen möglichen Ausprägungen sind durch rote Markierungen dargestellt. Auf eine Beschriftung dieser wird aus Gründen der Übersichtlichkeit verzichtet. Eine wertmäßige Festsetzung der Eigenschaften einer Dimension kann unter Angabe einer Erläuterung auch zwischen den definierten Werten erfolgen. Die folgende Abbildung zeigt eine leere Vorlage eines Kiviat-Graphen für die hier ausgewählten quantifizierbaren Eigenschaften: 82

94 Phasenabdeckung Darstellungsform Prozessabdeckung Sprachformalisierung Formalisierungsgrad Branchenfokus Abbildung 7-2: Kiviat-Graph der allgemeinen Quantifizierung, definierende Dimensionen Zur Veranschaulichung der Verwendung dieser Darstellung dienen folgende fiktive Analyseergebnisse eines Vorgehensmodells. Anwendungsbeispiel: - Phasenabdeckung: Das Vorgehensmodell unterstützt vier Phasen. - Prozessabdeckung: Es werden Systemerstellung, Qualitätssicherung, Projektmanagement und teilweise Konfigurationsmanagement unterstützt. Die resultierende Kennzahl ist 3,5. - Formalisierungsgrad: Das Modell ist weltlich ausdefiniert und somit mit zwei zu bewerten. - Branchenfokus: Der Branchenfokus ist allgemein, somit zwei. - Sprachformalisierung: Die verwendeten Sprachen sind semiformal definiert und somit mit zwei zu bewerten. - Darstellungsform: Die Darstellung erfolgt verbal, was die Einstufung eins veranlasst. Dimension Wert Phasenabdeckung 4 83

95 Prozessabdeckung 3,5 Sprachformalisierung 2 Darstellungsform 1 Formalisierungsgrad 2 Branchenfokus 2 Tabelle 7-6: Anwendungsbeispiel allgemeine Quantifizierung, definierende Dimensionen Phasenabdeckung Darstellungsform Prozessabdeckung Sprachformalisierung Formalisierungsgrad Branchenfokus Abbildung 7-3: Beispiel für eine allgemeine Quantifizierung, definierende Dimensionen 84

96 7.1.2 Nichtdefinierende Dimensionen Quantifizierung Grundlage für die weitere Untersuchung bilden alle als nichdefinierend eingestuften Dimensionen. Ist eine Quantifizierung für die betrachtete Dimension möglich, so wird sie ausdefiniert VM-Präsentation Die Untersuchung der Verbreitungsform des Vorgehensmodells wird durch die VM- Präsentation gewährleistet. Die unterschiedenen Ausprägungen besitzen in gewisser Weise bereits eine Ordnung. Da das Hauptanliegen der analysierten Vorgehensmodelle die Softwareentwicklung ist, sollte ein derartiges Modell auch nahe der zu verwendenden Technologie verbreitet werden. Die daraus folgende numerische Abbildung definiert die Verbreitung als Papier oder Buch als Minimum und somit als eins. Die höchste Stufe stellt die browserbasierte Repräsentation dar und definiert so das Maximum als vier. Quantifizierungsspektrum: [1..4]: gemäß folgender Tabelle: VM- Präsentation Entsprechung 1 Papier 2 E-Book 3 Hypertextbasiert 4 Browserbasiert Tabelle 7-7: Quantifizierung der VM-Präsentation Werkzeugbindung Für die Abbildung der Werkzeugbindung wird eine der den Ausprägungen ähnlich gestaltete Quantifizierung verwendet. Die Eigenschaft Eigene Tools wird aus der Be- 85

97 trachtung ausgeschlossen, da sie je nach ihrer Umsetzung im Vorgehensmodell positiv oder negativ interpretiert werden kann. Eine Einordnung in die anderen Ausprägungen ist dadurch nicht möglich. Für die Ordnung der verbleibenden drei Ausprägungen wird eine Ordnung gemäß der Frage, welches Vorgehensmodell am leichtesten bzw. am schnellsten mit Hilfe von Werkzeugen umzusetzen ist, gewählt. Die größte Schwierigkeit besteht in der Umsetzung eines unabhängigen Modells. Die Angabe eines Referenzmodells erleichtert die Auswahl, kann jedoch nicht so schnell wie die Umsetzung, unterstützt durch marktnahe Empfehlungen, erfolgen. Quantifizierungsspektrum: [1..3]: gemäß folgender Tabelle: Werkzeugbindung Entsprechung 1 Unabhängig 2 Referenzmodell 3 Marktnah Tabelle 7-8: Quantifizierung der Werkzeugbindung Toolsupport Die fünf Ausprägungen des Toolsupports charakterisieren die Unterstützung des Vorgehensmodells mit Hilfe von Werkzeugen. Die definierten fünf Eigenschaften liegen bereits in einer Ordnung vor und können somit durch eine einfache Abbildung auf die Zahlen eins bis fünf projiziert werden. Quantifizierungsspektrum: [1..5]: gemäß folgender Tabelle: Toolsupport Entsprechung 1 Kein Support 2 Datenablage 86

98 3 Partialsupport 4 Phasensupport 5 Totalsupport Tabelle 7-9: Quantifizierung des Toolsupports Automatisierungsgrad Der Aspekt des Automatisierungsgrads analysiert den Beitrag der Werkzeuge des Vorgehensmodells zur Automatisierung. Die gegebenen fünf Ausprägungen verfügen über eine Ordnung und können somit durch folgendes Schema quantifiziert werden. Quantifizierungsspektrum: [1..5]: gemäß folgender Tabelle: Automatisierungsgrad Entsprechung 1 Manuell 2 Formatierend 3 Konsistenzprüfend 4 Interproduktiv 5 Generierend Tabelle 7-10: Quantifizierung des Automatisierungsgrads QS-Beitrag Der durch den Werkzeugeinsatz erreichte Beitrag zur Qualitätssicherung gliedert sich in die vier Ausprägungen Intrakonsistenz, Interkonsistenz, Auditsupport und Zertifikatssupport. Für Intrakonsistenz bestehen dabei die niedrigsten Anforderungen an den QS- Beitrag. Die weiteren Anforderungen steigern sich über den Auditsupport von Interkonsistenz bis zum Zertifikatssupport, der die höchste Form der Unterstützung darstellt. 87

99 Quantifizierungsspektrum: [1..4]: gemäß folgender Tabelle: QS-Beitrag Entsprechung 1 Intrakonsistenz 2 Interkonsistenz 3 Auditsupport 4 Zertifikatssupport Tabelle 7-11: Quantifizierung des QS-Beitrags Systemhierarchie Die Organisation der Ergebnishierarchie ist das Untersuchungsziel der Systemhierarchie. Die charakteristischen Ausprägungen sind flach, tief und vernetzt. Diese Ordnung soll für die weitere Quantifizierung als Grundlage dienen, da unterstellt wird, dass eine tief vernetzte Ergebnishierarchie eine ausführlichere Darstellung der Ergebnisse bietet als eine flache Anordnung. Quantifizierungsspektrum: [1..3]: gemäß folgender Tabelle: Systemhierarchie Entsprechung 1 Flach 2 Tief 3 Vernetzt Tabelle 7-12: Quantifizierung der Systemhierarchie 88

100 Graphisches Modell Das graphische Modell entsteht analog zu der Betrachtung der definierenden Eigenschaften. Alle Dimensionen der nichtdefinierenden Eigenschaften sind quantifiziert worden und besitzen folgende Wertebereiche: Dimension Wertebereich VM-Präsentation [1..4] Werkzeugbindung [1..3] Toolsupport [1..5] Automatisierungsgrad [1..5] QS-Beitrag [1..4] Systemhierarchie [1..3] Tabelle 7-13: Wertebereiche der allgemein quantifizierbaren, nichtdefinierenden Dimensionen Die Übertragung dieser Werte führt zu folgender leeren Vorlage eines Kiviat-Graphen. Abbildung 7-4: Kiviat-Graph der allgemeinen Quantifizierung, nichtdefinierende Dimensionen 89

101 Die Verwendung dieses Modells soll folgendes Anwendungsbeispiel verdeutlichen. Die hypothetischen Analyseergebnisse wurden gemäß der Tabelle bereits auf die entsprechenden Zahlenwerte übertragen. Anwendungsbeispiel: Dimension Wert VM-Präsentation 3 Werkzeugbindung 2 Toolsupport 4 Automatisierungsgrad 3 QS-Beitrag 2 Systemhierarchie 2 Tabelle 7-14: Anwendungsbeispiel allgemeine Quantifizierung, nichtdefinierende Dimensionen Abbildung 7-5: Beispiel für eine allgemeine Quantifizierung, nichtdefinierende Dimensionen 90

102 7.2 Individuelle Quantifizierung Die individuelle Quantifizierung verfolgt das Ziel, die verbliebenen Dimensionen einer Ordnung zu unterziehen und eine Darstellung mit Hilfe von Kiviat-Graphen zu ermöglichen. Die nichtdefinierenden Dimensionen sind vollständig quantifiziert worden. Somit verbleiben für die weitere Betrachtung folgende definierende Dimensionen: - Objektdomäne: o Allgemeine o Softwarespezifische - Vorgehensweise: o Prozessvorgehensweise o Programmiervorgehensweise - Prozesssteuerung Aufgrund der für die Quantifizierung festgelegten Spezialisierung auf softwarespezifische Vorgehensmodelle wird die allgemeine Objektdomäne nicht weiter betrachtet. Die restlichen Dimensionen verfügen jeweils über mindestens drei Ausprägungen. Wie bereits diskutiert wurde, ist für diese Gesichtspunkte eine allgemeine Quantifizierung nicht möglich. Eine Ordnung der Elemente kann nur durch eine subjektive Gestaltung einer numerischen Abbildung erfolgen. Das hier empfohlene Vorgehen ist die Abbildung der Ausprägungen der Dimensionen auf jeweils drei numerische Werte. Der mit der Vorgehensmodellentscheidung beauftragte Entscheidungsträger wählt aus den angebotenen Ausprägungen drei für ihn mögliche Ausprägungen aus. Die höchste Priorität wird dabei mit dem Maximum, also der drei, belegt. Anders ausgedrückt, wird für die ideale Ausprägung die drei vergeben. Die nächstmögliche Alternative erhält den Wert zwei. Die dritte Variante wird mit dem Wert eins versehen. Zur Unterstützung des Anwenders dient folgende Tabelle. Sie stellt die vier Dimensionen mit ihren Ausprägungen dar und ermöglicht in der zweiten Spalte die Zuordnung von individuellen Prioritäten gemäß der Vorschrift. Die definierten Werte sind beispielhaft. 91

103 Ausprägung Wert Softwarespezifische Objektdomäne Allgemein 1 Standardsoftware Verteilte Anwendungen 2 Datenbankapplikationen 3 Echtzeitsysteme Spezialsoftware Prozessvorgehensweise Evolutionär 1 Inkrementell 3 Iterativ 2 Partizipativ Sequentiell Programmiervorgehensweise Keine Vorgabe 1 Strukturiert Modular Objektorientiert 2 Komponentenorientiert 3 Prozesssteuerung Aktivitätsorientiert 1 92

104 Ergebnisorientiert 3 Vertragsorientiert 2 Tabelle 7-15: Prioritätentabelle der individuellen Quantifizierung, inklusive Beispiel Die aus dieser Festlegung resultierende Quantifizierung kann die verschiedensten Formen annehmen. Die Darstellung der vier Dimensionen erfolgt in einem Kiviat-Graphen mit einer Skalierung der Achsen jeweils von eins bis drei. Die leere Vorlage der Abbildung ist somit für alle Anwendungen dieselbe. Eine Interpretation des Graphs kann nur in Verbindung mit einer definierenden Tabelle erfolgen, die festlegt, was der Zahlenwert in diesem speziellen Fall ausdrückt. Das folgende Modell besteht aus einer leeren Kiviat-Graphvorlage und der beschreibenden Tabelle gemäß des obigen Beispiels. Abbildung 7-6: Kiviat-Graph der individuellen Quantifizierung Ausprägung Entsprechung Softwarespezifische Objektdomäne 1 Allgemein 93

105 2 Verteilte Anwendungen 3 Datenbankapplikationen Prozessvorgehensweise 1 Evolutionär 2 Iterativ 3 Inkrementell Programmiervorgehensweise 1 Keine Vorgabe 2 Objektorientiert 3 Komponentenorientiert Prozesssteuerung 1 Aktivitätsorientiert 2 Vertragsorientiert 3 Ergebnisorientiert Tabelle 7-16: Beschreibende Tabelle der individuellen Quantifizierung Neu an dieser Darstellung ist, dass für die Dimensionen der Nullwert auftreten kann. Dieser Fall tritt ein, wenn das untersuchte Vorgehensmodell keine der ausgewählten Ausprägungen unterstützt. Das folgende Anwendungsbeispiel konstruiert einen derartigen Fall unter Verwendung des obigen Graphen und der zugehörigen Beschreibungstabelle. Anwendungsbeispiel: - Objektdomäne: Das Vorgehensmodell ist auf die Entwicklung von Echtzeitsystemen ausgerichtet. Somit ist der Dimensionswert gleich null. - Prozessvorgehensweise: Durch inkrementelle Entwicklung erfolgt die Einstufung als drei. 94

106 - Programmiervorgehensweise: Für die Umsetzung erfolgt keine Vorgabe, sie ist als eins zu definieren. - Prozesssteuerung: Die Steuerung erfolgt vertragsorientiert, die mit Ordnungszahl zwei definierte Ausprägung. Dimension Wert Objektdomäne 0 Prozessvorgehensweise 3 Programmiervorgehensweise 1 Prozesssteuerung 2 Tabelle 7-17: Anwendungsbeispiel individuelle Quantifizierung Abbildung 7-7: Beispiel für eine individuelle Quantifizierung 95

107 8 Anwendung Das bisher gestaltete Rahmenwerk soll innerhalb dieses Kapitels Anwendung finden. Die Untersuchung bezieht sich dabei auf die anfangs vorgestellten Vorgehensmodelle Rational Unified Process, V - Modell XT und Product Innovation Lifecycle. Die Betrachtung des Product Innovation Lifecycle wird aufgrund mangelnder Informationen leider nicht in allen Punkten des Vergleichsmodells möglich sein. Das weitere Vorgehen geht von einer anfänglichen Betrachtung der in den Modellen verwendeten Terminologien aus. Anschließend werden die Vorgehensmodelle der Untersuchung gemäß diesem Vergleichsrahmen unterzogen. Für jedes dieser Modelle erfolgen die Analyse der definierenden und der nichtdefinierenden Dimensionen sowie deren graphische Darstellung und Quantifizierung. Auf ein näheres Eingehen der Eigenschaften der Prozessarchitektur wird verzichtet, da eine wertungsfreie Darstellung der enthaltenen Elemente der Vorgehensmodelle bereits in Kapitel 3 gegeben wurde. Dieser Vergleichspunkt ist zur Anwendung zu bringen, wenn eine vergleichende Arbeit nicht über derartige grundlegende Ausführungen verfügt. Ebenso wird auf eine Gegenüberstellung der Vergleichsergebnisse verzichtet. Die gefundenen Resultate können nicht objektiv miteinander verglichen werden, da jeder Anwender eines Modells andere Prioritäten setzt. 8.1 Terminologie Die Gegenüberstellung erfolgt gemäß der Empfehlung in Form einer Tabelle. Die untersuchten Begriffe sind gemäß der oben vorgeschlagenen gewählt. Für den PIL ist leider meist keine Entsprechung gefunden worden. Die Termini des RUP basieren auf den Übersetzungen gemäß [Kruc99]. RUP V - Modell XT PIL Phase Phase Phase Phase Aktivität Aktivität Aktivität 96

108 Ergebnis Artefakt Produkt / Teilprodukt Produkt Rolle Rolle (früher Worker) Rolle Technik Schritt Elementarmethode Richtlinie / Standard Handbuch Handbuchsammlung Notation Sprache Sprache Prozess / Submodell Workflow Vorgehensbaustein Prozess Tabelle 8-1: Terminologievergleich der Vorgehensmodelle 8.2 Rational Unified Process Definierende Dimensionen Untersuchung Phasenabdeckung Der RUP unterstützt den Softwareentwicklungsprozess im Rahmen der wesentlichen Prozess-Workflows von der Modellierung bis zum Einsatz, der so genannten Verteilung. Unter Verteilung wird im RUP die Installation des Endprodukts beim Kunden und ggf. die Durchführung entsprechender Schulungen verstanden. Es sind keinerlei Elemente wie Systemmonitoring oder Betriebsauswertungen vorhanden. Aus diesem Grund kann die Phasenabdeckung für den Betrieb nicht mit 100 Prozent angenommen werden. Einer der wesentlichen Unterstützungs-Workflows ist das Projektmanagement, das entsprechende Aufgaben und Aktivitäten für die Planung und Projektierung vorsieht. 97

109 Prozessabdeckung Die Core-Workflows des Engineering bilden die Systementwicklung ab. Der Test- Workflow ist die entsprechende Komponente für die Qualitätssicherung. Es sind diverse Qualitätsaspekte sowie verschiedene Testarten zu unterschiedlichsten Zeiten und auf den verschiedensten Ebenen vorgesehen. Weitere Unterstützungs-Workflows decken die Aufgaben des Konfigurationsmanagements und des Projektmanagements ab. Formalisierung Sowohl in den Handbüchern als auch in der Online Version ist der RUP hauptsächlich in verbaler Form beschrieben. Zur Verdeutlichung bestimmter Zusammenhänge und Sachverhalte sind Grafiken (2D) mit eingeflossen. Die im RUP mit Hilfe der UML verwendeten Darstellungen, beispielsweise von Datenstrukturen, sind als semiformal einzuschätzen. Abstraktionsstufe Im Sinne der allgemeinen Abstraktionsstufe ist der RUP als Vorgehensmodell einzuordnen, da eine der Definition entsprechende Ausgestaltung des Modells vorliegt. Der Formalisierungsrad ist als atomar einzuschätzen. Die vorgegebenen Schritte der einzelnen Rollen sind sehr detailliert unter Angabe der auszuführenden Teilschritte beschrieben. Branchenfokus Der RUP fokussiert keine speziellen Softwaresysteme und ist somit als allgemein zu klassifizieren. Objektdomäne Die allgemeine Objektdomäne sieht eine Entwicklung von Software vor. Die zu entwickelnde Software wird im RUP nicht näher spezifiziert. Er besitzt somit eine allgemeine softwarespezifische Objektdomäne. 98

110 Vorgehensweise Die Vorgehensweisen werden im RUP direkt durch die Best Practices der Softwareentwicklung formuliert. Die Prozessvorgehensweise ist iterativ. Die angestrebte Architektur als komponentenorientiert impliziert eine derartige Vorgehensweise der Programmierung. Prozesssteuerung Die im RUP auszuführenden Tätigkeiten sind definiert durch ausführliche Arbeitspläne und somit aktivitätsorientiert dargestellt. Zusammenfassung Die gefundenen Eigenschaften sind in folgender Tabelle zusammengefasst. Dimension Ausprägungen Phasenabdeckung Projektierung Konzeption Technischer Entwurf Realisation Betrieb (grau) Prozessabdeckung Systemerstellung Projektmanagement Konfigurationsmanagement Qualitätssicherung Formalisierung Verbal Symbolisch Semiformal Abstraktionsstufe Vorgehensmodell 99

111 Formalisierungsgrad Branchenfokus Objektdomäne allgemein Objektdomäne softwarespezifisch Prozessvorgehensweise Programmiervorgehensweise Prozesssteuerung Atomar Allgemein Software Allgemein Iterativ Komponentenorientiert Aktivitätsorientiert Tabelle 8-2: Definierende Eigenschaften des RUP Graphische Darstellung Allgemeine Eigenschaften des RUP Abbildung 8-1: Allgemeine, definierende Eigenschaften des RUP 100

112 Softwarespezifische Eigenschaften des RUP Objektdomäne Abbildung 8-2: Softwarespezifische, definierende Eigenschaften des RUP Allgemeine Quantifizierung Die allgemeine Quantifizierung wurde auf Grundlage der oben ermittelten Untersuchungsergebnisse vorgenommen. Zur Vereinfachung der Interpretation der gefundenen Ergebnisse dient die im Anhang D zur Verfügung gestellte Tabelle. Sie stellt die allgemeinen quantifizierten Werte ihren Entsprechungen gegenüber. Dimension Wert Phasenabdeckung 4,5 101

113 Prozessabdeckung 4 Sprachformalisierung 2 Darstellungsform 2 Formalisierungsgrad 3 Branchenfokus 2 Tabelle 8-3: Allgemeine Quantifizierung der definierenden Eigenschaften des RUP Abbildung 8-3: Allgemeine Quantifizierung der definierenden Eigenschaften des RUP Individuelle Quantifizierung Die individuelle Quantifizierung erfolgt beispielhaft mit Hilfe der in Tabelle 7-17 beschriebenen Definition der Ausprägungen. 102

114 Dimension Wert Objektdomäne 1 Prozessvorgehensweise 2 Programmiervorgehensweise 3 Prozesssteuerung 1 Tabelle 8-4: Individuelle Quantifizierung des RUP gemäß Tabelle 7-17 Objektdomäne Prozesssteuerung Prozessvorgehensweise Programmiervorgehensweise Abbildung 8-4: Individuelle Quantifizierung des RUP gemäß Tabelle Nichtdefinierende Dimensionen Untersuchung VM-Präsentation Frühere Versionen des RUP sind auch in Form von Büchern veröffentlicht worden. Die aktuelle und hier untersuchte Version liegt als HTML-Dokument vor. Die Nutzung von 103

115 HMTL geht jedoch über eine einfache Darstellung hinaus und rechtfertigt eine Einordnung als browserbasierte Repräsentation. Werkzeugbindung Der RUP bezieht in seine Dokumentation und Tool-Mentoren ausschließlich die Produkte von IBM Rational Software ein. Toolsupport Unter Verwendung aller den Prozess begleitenden Werkzeuge und der zugehörigen Tool-Mentoren, kann der Entwickler über alle Phasen unterstützt werden. Darüber hinaus wird der Nutzer interaktiv durch die Ausführung der Aktivitäten geführt. Automatisierungsgrad Die Automatisierung kann durch die eigenen Tools bis zur generierenden Unterstützung ausgebaut werden. QS-Beitrag Die Qualitätsprüfung zwischen verschiedenen Teilprodukten wird durch Rollen und Werkzeuge gewährleistet. Der erreichbare Qualitätsgrad ist die Interkonsistenz. Systemhierarchie Die Beschreibung der einzelnen Teilergebnisse erfolgt sehr detailliert über eine vernetzte hierarchische Struktur. Zusammenfassung Dimension Ausprägung VM-Präsentation Werkzeugbindung Toolsupport Automatisierungsgrad QS-Beitrag Browserbasiert Eigene Tools Totalsupport Generierend Interkonsistenz 104

116 Systemhierarchie Vernetzt Tabelle 8-5: Nichtdefinierende Eigenschaften des RUP Graphische Darstellung Werkzeugbindung QS Beitrag Abbildung 8-5: Nichtdefinierende Eigenschaften des RUP 105

117 Quantifizierung Für die Interpretation der Quantifizierung der nichtdefinierenden Eigenschaften dient die Tabelle im Anhang E. Dimension Ausprägung VM-Präsentation 4 Werkzeugbindung 3 Toolsupport 5 Automatisierungsgrad 5 QS-Beitrag 2 Systemhierarchie 3 Tabelle 8-6: Quantifizierung der nichtdefinierenden Eigenschaften des RUP Toolsupport VM Präsentation Automatisierungsgrad Systemhierachie Werkzeugbindung QS Beitrag Abbildung 8-6: Quantifizierung der nichtdefinierenden Eigenschaften des RUP 106

118 8.3 V - Modell XT Definierende Dimensionen Untersuchung Phasenabdeckung Das V - Modell XT bietet eine Unterstützung für die klassischen Phasen der Systemerstellung von der Projektierung bis zur Realisation. Des Weiteren sind Entscheidungspunkte für die Gestaltung der Projektannahme und deren unternehmensinterne Budgetkalkulation vorhanden, was die Unterstützung für die IT-Strategie anzeigt. Der Betrieb des Systems ist nur teilweise durch die Anleitung zur Installation und Einführung des Produkts beim Kunden unterstützt. Prozessabdeckung Die unterstützenden Prozesse des V - Modell XT sind in Form der Vorgehensbausteine für die Systemerstellung, das Projektmanagement, das Konfigurationsmanagement und die Qualitätssicherung vorhanden. Weiterhin sind durch die Vorgehensbausteine kaufmännisches Projektmanagement sowie Messung und Analyse die Vorgaben eines Leistungsmodells erfüllt. Das Benchmarking und Wissensmanagement sind ebenfalls teilweise unterstützt, das Benchmarking durch eine Abbildung des Gesamtmodells auf CMMI oder SPICE, das Wissensmanagement durch die Bausteine Evaluierung von Fertigprodukten sowie Einführung und Pflege eines organisationsspezifischen Vorgehensmodells. Formalisierung Das V - Modell XT ist hauptsächlich verbal beschrieben. Zur ergänzenden Verdeutlichung der Zusammenhänge dienen semiformale, symbolische Darstellungen. Abstraktionsstufe Die allgemeine Realisationsstufe ist auf dem Niveau eines Vorgehensmodells umgesetzt. Aus Sicht des Formalisierungsgrades ist das V - Modell XT auf weltlicher Basis definiert. Die Prozessschritte sind in ihrer Abfolge genau bestimmt, jedoch ist die Ausges- 107

119 taltung der Aktivitäten nicht ausführlich genug, um eine atomare Einstufung zu rechtfertigen. Branchenfokus Es wird die allgemeine Systemerstellung fokussiert. Objektdomäne Das V - Modell XT sieht in der allgemeinen Objektdomäne beliebige Systeme als Entwicklungsgegenstand vor. Das bezieht Software- und Hardwaresysteme mit ein. Die softwarespezifische Objektdomäne geht nicht weiter auf bestimmte Eigenheiten von Systemen ein und zielt somit auf allgemeine Software. Vorgehensweise Innerhalb der Projektdurchführungsstrategien sind für die Prozessvorgehensweise die inkrementelle und die agile Entwicklung vorgeschlagen. Die Programmiervorgehensweise ist auf komponentenorientierter Basis umgesetzt. Prozesssteuerung Der Entwicklungsprozess besteht auch aus Beschreibungen der auszuführenden Aktivitäten. Die Steuerung der Schrittabfolge erfolgt jedoch durch die Ergebnisse. Zusammenfassung Dimension Ausprägungen Phasenabdeckung IT-Strategie Projektierung Konzeption Technischer Entwurf Realisation Betrieb (grau) 108

120 Prozessabdeckung Systemerstellung Projektmanagement Konfigurationsmanagement Qualitätssicherung Leistungsmodell Benchmarkingmodell (grau) Wissensmanagement (grau) Formalisierung Verbal Symbolisch Semiformal Abstraktionsstufe Formalisierungsgrad Branchenfokus Objektdomäne allgemein Vorgehensmodell Weltlich Allgemein Software Hardware Objektdomäne softwarespezifisch Prozessvorgehensweise Programmiervorgehensweise Prozesssteuerung Allgemein Imperativ Komponentenorientiert Ergebnisorientiert Tabelle 8-7: Definierende Eigenschaften des V - Modell XT 109

121 Graphische Darstellung Allgemeine Eigenschaften des V - Modell XT Abbildung 8-7: Allgemeine definierende Eigenschaften des V - Modell XT 110

122 Softwarespezifische Eigenschaften des V - Modell XT Objektdomäne Abbildung 8-8: Softwarespezifische definierende Eigenschaften des V - Modell XT Allgemeine Quantifizierung Dimension Wert Phasenabdeckung 4,5 Prozessabdeckung 4 Sprachformalisierung 2 Darstellungsform 2 Formalisierungsgrad 2 111

123 Branchenfokus 2 Tabelle 8-8: Allgemeine Quantifizierung der definierenden Eigenschaften des V - Modell XT Abbildung 8-9: Allgemeine Quantifizierung der definierenden Eigenschaften des V - Modell XT Individuelle Quantifizierung Dimension Wert Objektdomäne 1 Prozessvorgehensweise 3 Programmiervorgehensweise 3 Prozesssteuerung 3 Tabelle 8-9: Individuelle Quantifizierung des V - Modell XT gemäß Tabelle

124 Abbildung 8-10: Individuelle Quantifizierung des V - Modell XT gemäß Tabelle Nichtdefinierende Dimensionen Untersuchung VM-Präsentation Das V - Modell XT wird in Form von Büchern publiziert. Dies beinhaltet Papierdokumente, E-Books und entsprechende Versionen in Form von Hypertext. Werkzeugbindung Es werden keine am Markt befindlichen Produkte empfohlen. Die Werkzeugreferenz legt für die Tools bestimmte Eigenschaften fest. Toolsupport Die durch das Modell angegebenen Werkzeuge sind lediglich in Form von Referenzen definiert und ermöglichen eine teilweise Unterstützung der Phasen und Aktivitäten. 113

125 Automatisierungsgrad Die Automatisierung des Vorgehensmodells muss manuell erfolgen, da die angegebenen Werkzeugreferenzen keinen Ausdruck über ihren übergreifenden Einsatz geben. QS-Beitrag Durch die Beschreibung von Werkzeugreferenzen im Allgemeinen kann Intrakonsistenz erreicht werden. Die Definition des Testwerkzeuges sieht jedoch auch übergreifende Tests vor und ermöglicht somit Interkonsistenz. Systemhierarchie Die Teilergebnisse gliedern sich in hierarchisch und vernetzt. Zusammenfassung Dimension VM-Präsentation Werkzeugbindung Toolsupport Automatisierungsgrad QS-Beitrag Systemhierarchie Ausprägung Hypertextbasiert Referenzmodell Partialsupport Manuell Interkonsistenz Vernetzt Tabelle 8-10: Nichtdefinierende Eigenschaften des V - Modell XT 114

126 Graphische Darstellung Werkzeugbindung QS Beitrag Abbildung 8-11: Nichtdefinierende Eigenschaften des V - Modell XT Quantifizierung Dimension Ausprägung VM-Präsentation 3 115

127 Werkzeugbindung 2 Toolsupport 3 Automatisierungsgrad 1 QS-Beitrag 2 Systemhierarchie 3 Tabelle 8-11: Quantifizierung der nichtdefinierenden Eigenschaften des V - Modell XT Toolsupport VM Präsentation Automatisierungsgrad Systemhierachie Werkzeugbindung QS Beitrag Abbildung 8-12: Quantifizierung der nichtdefinierenden Eigenschaften des V - Modell XT 8.4 Product Innovation Lifecycle Aufgrund der wenigen über den Product Innovation Lifecycle bekannten Informationen wird dessen Untersuchung hier verkürzt. Auf eine Analyse der nichtdefinierenden Eigenschaften sowie die Quantifizierung wird verzichtet. Weiterhin müssen die meisten Eigenschaften der definierenden Dimensionen aus dem vorhandenen Material erahnt werden. Aus diesem Grund erfolgt keine verbale Untersu- 116

128 chung, sondern es wird eine tabellarische Zusammenfassung der vermuteten Eigenschaften angegeben Definierende Dimensionen Untersuchung Dimension Ausprägungen Phasenabdeckung IT-Strategie Projektierung Konzeption Technischer Entwurf Realisation Betrieb (grau) Prozessabdeckung Systemerstellung Projektmanagement Konfigurationsmanagement Qualitätssicherung Formalisierung Verbal Symbolisch Semiformal Abstraktionsstufe Formalisierungsgrad Branchenfokus Objektdomäne allgemein Vorgehensmodell Nicht bekannt Speziell (SAP Produkte) Software 117

129 Objektdomäne softwarespezifisch Prozessvorgehensweise Programmiervorgehensweise Prozesssteuerung Standardsoftware Sequentiell Komponentenorientiert Nicht bekannt Tabelle 8-12: Definierende Eigenschaften des PIL Graphische Darstellung Allgemeine Eigenschaften des PIL Abbildung 8-13: Allgemeine definierende Eigenschaften des PIL 118

130 Softwarespezifische Eigenschaften des PIL Abbildung 8-14: Softwarespezifische definierende Eigenschaften des PIL 119

131 9 Bewertung und Ausblick Die im Rahmen dieser Arbeit vorgestellten Vergleichskriterien bieten einen Überblick über das untersuchte Vorgehensmodell. Der Versuch der Gestaltung eines Vergleichsrahmens hatte das Ziel, für ausgewählte Eigenschaften eine Aussage zu treffen und somit einen Vergleich mit anderen Modellen zu ermöglichen. Das resultierende Rahmenwerk bietet einen Vergleich mit der Aufteilung in definierende und nichtdefinierende Dimensionen bzw. Eigenschaften. Die definierenden Dimensionen spiegeln dabei die das Vorgehensmodell direkt beschreibenden Eigenschaften wider. Die nichtdefinierenden Dimensionen dienen der weiteren Untersuchung und widmen sich hauptsächlich der Werkzeugunterstützung. Die aus diesen Untersuchungen gewonnenen Darstellungen bieten einen schnellen graphischen Überblick über das analysierte Vorgehensmodell. Sie unterteilen sich in die allgemeinen und die softwarespezifischen definierenden Eigenschaften sowie in eine Darstellung für die nichtdefinierenden Dimensionen. Deren Interpretation kann individuell durch den jeweiligen Betrachter erfolgen. Die Anwendung dieses Vergleichsmodells ist nicht strikt vorgegeben. Es versteht sich als Rahmenwerk, dessen anzuwendende Teilgebiete durch den Nutzer frei ausgewählt werden können. Um einen ausführlichen Überblick über das gesamte Vorgehensmodell zu gewährleisten, bietet sich jedoch die vollständige Anwendung aller vorgeschlagener Vergleichskriterien an. Eine vollständige Untersuchung nach allen Kriterien inklusive der Quantifizierung ist für das V - Modell XT und den Rational Unified Process vorgenommen worden. Dabei stellten sich die vorgeschlagenen Darstellungen der definierenden und der nichtdefinierenden Eigenschaften als sehr übersichtlich und aussagekräftig heraus. Probleme bestehen jedoch in den quantifizierten Graphiken. Vor allem die allgemeine Quantifizierung der definierenden Eigenschaften ist für eine eventuell zu fällende Vorgehensmodellentscheidung nicht in ihrem eigentlichen Sinne aussagekräftig. Das Ziel von Kiviat-Graphen besteht in einer Gestaltung der Dimensionen in der Art, dass ein entstehendes Polygon gemäß seines Flächeninhalts Auskunft über die Qualität oder Quantität des Untersuchungsgegenstands ermöglicht. In gewisser Weise trifft dies auf die allgemeine definierende Quantifizierung zu, da die zu analysierenden Dimensionen eine Aussage über die Ausgestaltung, den Abdeckungsgrad von Aktivitäten und die Formalisierung des Vorgehensmodells gibt. Diese Kriterien werden jedoch je nach Entscheidungsfall eigens festgelegt. Beispielsweise ist in bestimmten Fällen ein weltlich ausdefiniertes Modell einem atomaren vorzuziehen. 120

132 Um ein Vorgehensmodell nach den Eigenschaften der Formalisierung, dem Maß der Ausgestaltung und der Abdeckung zu untersuchen, ist die Darstellung der allgemeinen definierenden Quantifizierung durchaus anwendbar. Das weiterhin bestehende Problem liegt in der Einbringung von eigenen Prioritäten. Eine Lösung für dieses Problem wurde anhand der nicht allgemein quantifizierbaren Eigenschaften durch die individuelle Quantifizierung vorgeschlagen. Die durch einen Entscheidungsträger festzulegenden Prioritäten bieten die Möglichkeit der Interpretation des entstehenden Graphen entsprechend der gewünschten Eigenschaften. Sind auf diese Art und Weise mehrere Vorgehensmodelle verglichen worden, so bildet das Modell, dessen Kiviat-Graph den größten Flächeninhalt aufweist, für den Entscheidungsträger die ideale Wahl. Die Eigenschaften der nichtdefinierenden Dimensionen bieten Aussagen über die Werkzeugunterstützung des Vorgehensmodells. Deren Quantifizierung erwies sich als nützlich, da sie ausdrückt, in wie weit das Vorgehensmodell durch Tools unterstützt wird bzw. unterstützt werden kann. Ein größerer Flächeninhalt eines solchen Kiviat- Graphen lässt somit den Schluss zu, dass das untersuchte Modell über eine bessere direkte Werkzeugunterstützung verfügt. Die durch diesen Vergleichsrahmen definierten Eigenschaften ermöglichen einen Überblick über das untersuchte Vorgehensmodell und können in dieser Form elektronisch gespeichert bzw. verarbeitet werden. Eine so erstellte oder mit diesen Daten gefüllte Datenbank könnte den Aufwand für die Auswahl eines Vorgehensmodells in einem bestimmten Projekt oder Unternehmen stark vereinfachen. Die definierenden und nichtdefinierenden Eigenschaften bieten hierfür eine übersichtliche graphische Darstellung. Deren Interpretation muss jedoch weiterhin manuell erfolgen. Um dieses Problem zu beheben, würde sich ein Werkzeug auf Basis einer individuellen Quantifizierung anbieten. Die hier vorgeschlagene individuelle Quantifizierung bildet dafür eine gute Grundlage. Eine derartige Umsetzung müsste jedoch zunächst noch für die allgemeine definierende Quantifizierung erfolgen. Das resultierende Werkzeug würde den Benutzer interaktiv zu dem gewünschten Vorgehensmodell befragen, beispielsweise durch die Vergabe von Prioritäten gemäß der individuellen Quantifizierung. Das Werkzeug bedient sich intern der Vorgaben der Quantifizierung und ermittelt so den theoretischen Wert des Flächeninhalts des entstehenden Kiviat-Graphen. Das gemäß den Eingaben des Nutzers ideale Vorgehensmodell könnte durch den größten Flächeninhalt bestimmt und ausgegeben werden. 121

133 Anhang A Anwendungsbereiche von Methoden, nach [Chro92] E/R JSD SA SADT ISAC ADT ANIMOS SD CD HIPO LITOS JSP LCP PC StP Anforderungsanalyse X X X X X X Fachkonzeption X X X X X X X X Grobentwurf X X X X X X X X X X X Feinentwurf X X X X X X X X X X Implementierung X X X X X X X Testen X Methodenverzeichnis, nach [Chro92] Methode E/R JSD SA SADT ISAC ADT ANIMOS SD CD HIPO LITOS JSP LCP PC StP Name Entity / Relation Darstellung Jackson Structured Design Structured Analysis Structured Analysis and Design Technique Information System work and Analysis of Change Abstrakte Datentypen An Integrated Method of Software Design Structured Design Composite Design Hierarchy of Input Process Output Linzer Technique of Software Design Jackson Structured Programming Life Cycle Protocols Pseudocode Strukturierte Programmierung 122

134 Anhang B Analyse des RUP mit dem Zachmann Framework, Quelle: [Vill03] 123

135 Anhang C Einordnung nach Vorgehensweise, Quelle: [Brem98] Sequentiell Inkrementell Iterativ Partizipativ Evolutionär Phasen/Wasserfallmodell U-Modell X X Tätigkeitsmo- Phasen-/ dell X Komponentenmodell X X Spiralmodell (X) X (X) Modell des sukzessiven Auslieferns X X (X) Clustermodell X X (X) Aspekte-/ Schichtenmodell X X X X X X Einordnung nach Einsatzbereich, Quelle: [Brem98] Altes Anwendungsfeld Neues Anwendungsfeld Problem bekannt Phasen-/Wasserfallmodell U-Modell Phasen-/Tätigkeitsmodell Komponentenmodell Spiralmodell Problem unbekannt Spiralmodell Modell des sukzessiven Auslieferns Clustermodell Aspekte-/Sichtenmodell Modell des sukzessiven Auslieferns Clustermodell Referenzli- Versionen-/ nienmodell Versionen-/ Referenzlinienmodell 124

136 Anhang D Allgemeine Quantifizierung der definierenden Eigenschaften Ausprägung Entsprechung Phasenabdeckung [1..6] Anzahl der unterstützten Phasen. Prozessabdeckung [1..4] Anzahl der unterstützten Prozesse. Sprachformalisierung 1 Informal 2 Semiformal 3 Formal Darstellungsform 1 Verbal 2 Symbolisch 3 Animiert Formalisierungsgrad 1 Universell 2 Weltlich 3 Atomar Branchenfokus 1 Speziell 2 Allgemein 125

137 Anhang E Quantifizierung der nichtdefinierenden Eigenschaften Ausprägung Entsprechung VM-Präsentation 1 Papier 2 E-Book 3 Hypertextbasiert 4 Browserbasiert Werkzeugbindung 1 Unabhängig 2 Referenzmodell 3 Marktnah Toolsupport 1 Kein Support 2 Datenablage 3 Partialsupport 4 Phasensupport 5 Totalsupport Automatisierungsgrad 1 Manuell 2 Formatierend 3 Konsistenzprüfend 126

138 4 Interproduktiv 5 Generierend QS-Beitrag 1 Intrakonsistenz 2 Interkonsistenz 3 Auditsupport 4 Zertifikatsupport Systemhierarchie 1 Flach 2 Tief 3 Vernetzt 127

139 Literaturverzeichnis [Ache04] [AKBK05] Achenbach, Hendrik: UI First Der Anwender im Mittelpunkt. In SAP Info 122, 2004, URL: edition8/print_up_overview.asp. Arbeitskreis Begriffe und Konzepte der Vorgehensmodellierung der GI Fachgruppe 5.11: Begriffsammlung Vorgehensstrategie. Abruf Februar 2005, URL: [AKVM05] Höhn, R.; Höppner, S.; Kelm, A.; Schumacher, M.; Wetzel, H.; Filß, C.: Arbeitspapier des Arbeitskreis Vorgehensmodelle Übersicht und Vergleich der GI Fachgruppe WI-VM, [BaKl01] [Balz98] [BaWe99] [Bent91] [BoIi04] [Brem98] [BuFä97] Bartsch-Beuerlein, Sandra; Klee, Oliver: Projektmanagement mit dem Internet Konzepte und Lösungen für virtuelle Teams. München, Wien: Carl Hanser Verlag, Balzert, Helmut: Lehrbuch der Softwaretechnik : Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Heidelberg, Berlin: Spektrum, Akademischer Verlag, Bannert, Gabriele; Weitzel, Martin: Objektorientierter Softwareentwurf mit der UML. München: Addison Wesley Longman, Bentley, Colin: Practical PRINCE A Guide to Structured Project Management. Oxford: NCC Blackwell Limited, Bomarius, Frank; Iida, Hajimu: Product Focused Software Process Improvement 5th International Conference Proceedings. Berlin, Heidelberg, New York: Springer Verlag, Bremer, Georg: Genealogie von Entwicklungsschemata. In: [KnMO98], Bullinger, Hans-Jörg; Fähnrich, Klaus-Peter: Betriebliche Informationssysteme Grundlagen und Werkzeuge der methodischen Softwareentwicklung. Berlin, Heidelberg: Springer Verlag,

140 [Chro92] Chroust, Dr. Gerhard: Modelle der Software Entwicklung. München: R. Oldenbourg Verlag, [ChGr98] [Dilg95] [DrHM98] [Ecke03] [Fähn02] [FeIL02] [FiHe02] [Fuch05] [GaMP04] [GaRP04] Chroust, Dr. Gerhard; Grünbacher, Paul: Werkzeugunterstützung beim Einsatz von Vorgehensmodellen. In: [KnMO98], Dilg, Peter: Praktisches Qualitätsmanagement in der Informationstechnologie : von der ISO 9000 zum TQM. München, Wien: Carl Hanser Verlag, Dröschel, Wolfgang; Heuser, Walter; Midderhoff, Rainer: Inkrementelle und objektorientierte Vorgehensweisen mit dem V - Modell 97. München: Oldenbourg Verlag, Eckert, Dr. Harald: Risikomanagement im Umgang mit Software. Vortragsunterlagen, 2003, URL: 02_HECKERT LUTIS_ PDF. Fähnrich, Prof. Dr. Klaus Peter: Software-Qualitätsmanagement. Vorlesung an der Universität Leipzig, Sommersemester Fettke, Peter; Intorsureanu, Iulian; Loos, Peter: Komponentenorientierte Vorgehensmodelle im Vergleich. Tagungsbericht erarbeitet an der TU Chemnitz, Fakultät Wirtschaftsinformatik, 2002, URL: Firesmith, Donald G., Henderson-Sellers, Brian: The Open Process Framework. Harlow: Pearson Education Ltd., Fuchsberger, Christian: Softwaretypen. Abruf Februar 2005, URL: Galic, Michele; Macisaac, Bruce; Popescu, Dan: Using a single Pattern with the Rational Unified Process (RUP). IBM Red Books, 2004, URL: Garcia, Felix; Ruiz, Francisco; Piattini, Mario: Definition and Empirical Validation of Metrics for Software Process Models. In: [BoIi04],

141 [Geip03] [Gorn01] [Gräb04] [Gutz94] [Huss02] [IABG04] [IFIP99] [Illg04] [JaBR98] [KBSt04] [Klin04] Geipel, Petra: Der IT Projektmanager. München: Addison-Wesley Verlag, Gornik, Davor: IBM Rational Unified Process: Best Practices for Software Development Teams. IBM Whitepapers, 2001, URL: Gräbe, Prof. Dr. Hans Gert: Software-Qualitätsmanagement. Vorlesung an der Universität Leipzig, Sommersemester Gutzweiler, Thomas A.: Das CC-RIM Referenzmodell für den Entwurf von betrieblichen, transaktionsorientierten Informationssystemen. Heidelberg: Physica-Verlag, Hußmann, Heinrich: Softwaretechnologie. Vorlesung an der TU Dresden, Wintersemester 2001/2002. IABG: Werkzeuge, die an das V Modell angepasst wurden. 2004, URL: IFIP IFAC Task Force: GERAM: Generalised Enterprise Reference Architecture and Methodology. Version 1.6.3, 1999, URL: 3/v1.6.3.html. Illgner, Herbert: Wie kommt das Neue in die Welt Product Innovation Lifecycle. In SAP INFO 119, 2004, URL: Author c65bd961e7e5/de. Jacobson, Ivar; Booch, Grady; Rumbaugh, James: The Unified Software Development Process. Reading, MA: Addison Wesley Longman, Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung (kurz: KBSt): V - Modell XT Vorabversion , URL: Klinger, Ronny: Untersuchung von Prozessen des Konfigurationsmanagements für einen effektiven und sicheren Software Entwicklungsprozess. Diplomarbeit an der Technischen Universität Dresden,

142 [Kneu03] Kneuper, Dr. Ralf: CMMI Verbesserung von Softwareprozessen mit dem Capability Maturity Model Integration. Heidelberg: dpunkt.verlag GmbH, [KnMO98] Kneuper, Ralf; Müller-Luschnat, Günther; Oberweis, Andreas: Vorgehensmodelle für die betriebliche Anwendungsentwicklung. Stuttgart, Leipzig: Teubner Verlag, [Kort01] [Kozu05] [Kruc99] [Lisk04a] [Lisk04b] [NoSc99] [PGFL05] [Rati03] [Reim04] Korthaus, Axel: Entwicklung computergestützter betrieblicher Informationssysteme. Frankfurt am Main: Peter Lang GmbH, Europäischer Verlag der Wissenschaften, Kozuka, Takanori: Kiviat Diagram Visualisation Technique. Abruf Februar 2005, URL: at.ppt. Kruchten, Philippe: Der Rational Unified Process - Eine Einführung. München: Addison Wesley Longman, Liskowsky, Prof. Dr. Rüdiger: Software Entwicklungswerkzeuge. Vorlesung an der TU Dresden, Wintersemester 2003/2004. Liskowsky, Prof. Dr. Rüdiger: Computergestützte Gruppenarbeit. Vorlesung an der TU Dresden, Wintersemester 2003/2004. Noak, Jörg; Schienmann, Bruno: Objektorientierte Vorgehensmodelle im Vergleich. In: Informatik Spektrum, Band 22, Seite , Heidelberg: Springer Verlag, Pinzger, Martin; Gall, Harald; Fischer, Michael; Lanza, Michele: Visualizing Mutiple Evolution Metrics. Abruf Februar 2005, URL: relvis.pdf IBM Rational Software Corp.: Rational Unified Process Evaluation Version IBM Rational Software Corp., 2003, URL: Reimann, Falk: Werkzeugunterstützung bei Vorgehensmodellen. Diplomarbeit an der Technischen Universität Dresden,

143 [RoKr03] Robillard, Pierre N., Kruchten, Philippe: Software Engineering Process with the UPEDU. Boston: Pearson Education Inc., [Scot02] Scott, Kendall: The Unified Process Explained. Pearson Education, [Vill03] [WaMc96] [Zach87] Villiers, DJ de: Using the Zachmann Framework to assess the Rational Unified Process. IBM DeveloderWorks, 2003, URL: Watson, Arthur H.; McCabe, Thomas J.: Structured Testing: A Testing Methodology using cyclomatic complexity metric. NIST Special Publication , Zachmann, John: The Zachmann Framework for Enterprise Architecture. 1987, URL: 132

144 Selbstständigkeitserklärung Erklärung Hiermit versichere ich, dass die vorliegende Arbeit von mir selbständig verfasst wurde und ich alle verwendeten Quellen, auch Internetquellen, ordnungsgemäß angegeben habe. Dresden, den (Christian Filß) 133