Bewertung der objektorientierten Analyse im Vergleich zu konventionellen Ansätzen

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Ziele der Arbeit und Vorgehensweise
1.3 Abgrenzungen

2 Theoretische Grundlagen
2.1 Begriffsbestimmungen
2.1.1 System
2.1.2 Systemanalyse
2.1.3 Modell
2.1.4 Software
2.2 Vorgehensmodelle
2.2.1 Sequentielle Vorgehensmodelle
2.2.2 Wiederholende Vorgehensmodelle
2.2.2.1 Inkrementelles Vorgehen
2.2.2.2 Iteratives Vorgehen
2.2.2.3 Agiles Vorgehen
2.2.3 Prototypische Vorgehensmodelle
2.3 Systemanalyse
2.3.1 Beherrschung der Komplexität
2.3.2 Zerlegungsstrategien der Systemanalyse
2.3.3 Methodengestütztes Vorgehen

3 Methoden und ganzheitliche Vorgehensweisen
3.1 Geschichte
3.2 Konventionelle Methoden
3.2.1 ER-Modell
3.2.2 Die Strukturierte Analyse
3.3 Objektorientierte Methoden
3.3.1 Basiskonzepte
3.3.2 Statische Konzepte
3.3.3 Dynamisches Modell
3.4 Ganzheitliche Vorgehensweisen
3.4.1 Konventionelle Vorgehensweise
3.4.2 Objektorientierte Vorgehensweisen

4 Bewertung der Methoden und ganzheitlichen Vorgehensweisen

5 Anwendung einer synthetischen Vorgehensweise: Analyse einer Anwendung im Unternehmen
5.1 Das Unternehmen Generali Pensor Pensionsfonds
5.2 Die Inkasso-Liste als Excel-Anwendung
5.3 Datenflussdiagramm
5.4 ER-Diagramm
5.5 Anwendungsfallbeschreibung
5.6 Klassendiagramm
5.7 Prototyp

6 Kritische Betrachtung

Abbildungsverzeichnis

Abbildung 1 Mögliche Unterteilung von Software

Abbildung 2 Bekanntheitsgrad von Vorgehensmodellen

Abbildung 3 Iterations-Wolke

Abbildung 4 Methodengestütztes Vorgehen

Abbildung 5 Entwicklung Programmiersprachen

Abbildung 6 Der Methodendschungel

Abbildung 7 Entität

Abbildung 8 1:N-Beziehung

Abbildung 9 Vorgehen ER-Modellierung

Abbildung 10 Methodisches Vorgehen der Strukturierte Analyse

Abbildung 11 Statische und dynamisches Modell nach Balzert

Abbildung 12 Das Rechteck als Klasse

Abbildung 13 Aggregation und Komposition

Abbildung 14 Generalisierungsstruktur

Abbildung 15 Beispiel UML Use-Case

Abbildung 16 UML Use-Case Realisierung

Abbildung 17 Klassisches Wasserfallmodell

Abbildung 18 Phasenübergänge konventioneller Vorgehensweisen

Abbildung 19 Abgrenzung OOA, OOD, OOP

Abbildung 20 Datenflussdiagramm

Abbildung 21 ER-Diagramm

Abbildung 22 Use-Case Beitragszerlegung

Abbildung 23 vereinfachtes Use-Case Beitragszerlegung

Abbildung 24 Klassendiagramm

Abbildung 25 Prototyp, Maske: Vertrag

Abbildung 26 Prototyp, Maske: Angebotsdaten importieren

Tabellenverzeichnis

Tabelle 1 Standish Group CHAOS Report

Tabelle 2 Zerlegungsstrategien nach Herwig Mayr

Tabelle 3 Konventionelle Methoden der Systemanalyse

1 Einleitung

Die Analyse ist im Kontext der Software-Architektur ein Prozess, in dem ein System im Ganzen oder ein bestimmter Problembereich zerlegt, geordnet und untersucht wird^[1]. Gegenstand der Analyse kann ein bereits vorhandenes (Ist-Analyse) oder ein noch zu entwickelndes System (Soll-Analyse) sein. Die eingesetzten Analyse-Methoden sind in beiden Ausgangssituationen allerdings identisch.

Neben den konventionellen Analysemethoden, z. B. wie der Strukturierten Analyse erfreut sich das objektorientierte Paradigma^[2] mit der Objektorientierten Analyse (OOA) einer sehr großen Verbreitung. Bei den immer komplexer werdenden Anwen­dungen und den unberechenbaren Impulsen aus der Umwelt hat die konventionelle Strukturierte Analyse immer mehr an Relevanz verloren.

Wie definiert sich nun aber die Komplexität einer Anwendung und wo sind die Grenzen von einer einfachen zu einer komplexen Anwendung? Für die Messung der Software-Komplexität stehen unterschiedliche Verfahren zur Verfügung: Für die konventionelle Softwareentwicklung beispielsweise Lines of Code^[3] (LOC) und für die objektorientierte Anwendungen beispielsweise die Struktur- oder Komponenten­metriken.^[4] Für die Arbeit im Rahmen der Bachelor-Thesis wird allerdings eine pragmatischere Vorgehensweise vorgezogen. Eine einfache Anwen­dung wird als eine Anwendung interpretiert, welche im Rahmen der Zeitvorgabe für die Bachelor-Arbeit von einer Person umgesetzt werden kann.

1.1 Motivation

Viele IT-Projekte scheitern daran, dass die ge­planten Kosten überschritten, vor­bestimmte Termine nicht eingehalten oder die gewünschte Qualität nicht erreicht wird. Die Ursachen sind primär in der System­analyse zu sehen.^[5] Die Standish Group International ist eine beliebte Quelle für Statistiken. So verweisen zahlreiche Publikationen^[6] auf die regelmäßig erschei­nen­den CHAOS Forschungsprojekte der Standish Group.

„Nach verschiedenen Erhebungen werden nur 16-26% aller IT-Projekte erfolgreich beendet (Standish Group International 2004, Oxford University). Fast 50% aller Projekte sind über dem Kosten- und/oder Zeitplan, ca. 25% aller Projekte werden abgebrochen oder nie beendet. Allein in den USA werden so jedes Jahr 150 Mi­l­­liar­den Dollar vergeudet, EU-weit kommen nochmals 140 Milliarden Euro dazu. Ein systematisches und methodisches Projektvorgehen macht den Unterschied z­wi­­sch­en einem Projekterfolg und einem gescheiterten Projekt aus.“^[7]

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1 Standish Group CHAOS Report^[8]

Die bisherige Motivationsbeschreibung beinhaltet zwei Kernaussagen:

- Ein systematisches^[9] und methodisches^[10] Vorgehen ist entscheidend für den Projekterfolg.
- Projekte scheitern bereits in der Analysephase.

Das Thema der vorliegenden Arbeit legt den Schwerpunkt daher in die methoden­gestützte Analyse von Software-Systemen.

Die Analyse mit konventionellen Methoden hat den Autor dieser Ausarbeitung seit Beginn der Ausbildung im Jahr 1997 begleitet. Das objektorientierte Verfahren^[11] zur System-Analyse hatte in den bisherigen Unternehmen keine praxisrelevante Be­deut­ung. Dieses ist allerdings auch den Branchen geschuldet. In der Schifffahrts-, der Versandhaus- und zuletzt der Versicherungsbranche sind die Systeme seit den 70er Jahren über konventionelle Programmiersprachen zu komplexen Systemen heran­gewachsen.^[12] Um den immer schneller wachsenden Anforderungen gerecht zu werden, ist es allerdings unabdingbar, die veralteten Systeme durch neue zu ersetzen. Der Trend geht dabei seit längerem mehr in Richtung objektorientierter Methoden.^[13] Die Analyse von veralteten Systemen wird in Zukunft daher immer mehr an Bedeutung zunehmen. In dieser Ausarbeitung werden daher die konven­tionellen Methoden den objektorientierten Methoden gegenübergestellt. Der Ver­gleich beider Verfahren wird insbesondere von folgenden Fragestellungen ge­trieben:

1. Hat das Wissen über konventionelle Methoden neben den objektorientierten Methoden noch Bestand?
2. Welche Analysemethoden sind für eine einfache Anwendung relevant?
3. Sind die (moderneren^[14] ) objektorientierten Methoden für eine vollständige Systemanalyse ausreichend?
4. Können die Ergebnisse der Analyse verlustfrei in die Folgephase über­nom­men werden?

Aus diesen Fragenstellungen sind unter anderem die Ziele abgeleitet, welche im nächsten Kapitel erläutert werden.

1.2 Ziele der Arbeit und Vorgehensweise

Ziel dieser Arbeit ist die Bewertung, Synthese^[15] und Anwendung von Methoden zur Analyse einer einfachen betrieblichen Applikationen. Die Analyse ist definiert als die Untersuchung eines Problemes und der Anforderungen, nicht die vollständige Herleitung einer Lösung.^[16] Die Design- als auch die Implementierungsphase werden demnach in dieser Ausarbeitung ausgeklammert.

Um die wesentlichen Methoden zur Systemanalyse einer einfachen Anwendung bewerten zu können, ist es notwendig diese zu identifizieren und zu beschreiben. Gemäß der Titelbeschreibung werden in der vorliegenden Arbeit zwei unter­schiedliche Analyseverfahren zur Geltung kommen: Die objektorientierte Analyse (OOA) sowie konventionelle Methoden zur Systemanalyse. Dieses soll durch das erste Teilziel dieser Arbeit erreicht werden.

Teilziel 1: Vorstellung und Bewertung der praxisrelevanten Methoden im Hinblick einer einfachen Applikation.

Die Bewertung der Methoden sollte nicht isoliert betrachtet werden. Der gesamte Software­-Entwicklungsprozess ist vor allem durch die Phasen Analyse, Design und Implementierung geprägt. Für eine Bewertung der Methoden ist es daher relevant die Schnittstellen zu den anderen Phasen ebenfalls zu berücksichtigen. Eine
Analyse­-­Methode, die einen direkten Übergang von der Analyse-Phase zur Design-Phase unterstützt, ist anders zu bewerten als eine Analyse-Methode, bei dem der Übergang nicht ohne weiteres möglich ist. Das zweite Teilziel betrachtet daher die ganzheitliche Vorgehensweisen.

Teilziel 2: Vorstellung und Bewertung der ganzheitlichen Vorgehensweisen.

Das dritte Teilziel widmet sich dem Untertitel dieser Arbeit. Die erzielten Erkennt­nisse werden anhand einer einfachen Applikation umgesetzt.

Teilziel 3: Anwendung der Methoden und einer ganzheitlichen Vorgehensweise auf eine einfache betriebliche Applikation.

Neben diesen messbaren Zielen fließen außerdem auch übergeordnete Ziele der Systemanalyse in die Ausarbeitung ein. „Es ist das generelle, übergeordnete Ziel der Systemanalyse, dem Menschen ein umfassendes Verständnis für komplexe Systeme zu ermöglichen und damit die Voraussetzung für eine gezielte Gestaltung der Systeme zu schaffen.“^[17] Das Verständnis soll insbesondere durch die ganzheit­liche Vorgehensweise und den allgemein verständlichen Diagrammtypen gefördert werden.^[18]

Vorgehensweise:

Die vorliegende Arbeit beinhaltet neben dieser Einleitung fünf weitere Kapitel:

1. Einleitung (Dieses Kapitel)
2. Theoretische Grundlagen
3. Methoden und ganzheitlichen Vorgehensweisen
4. Bewertung der Methoden und ganzheitlichen Vorgehensweisen
5. Anwendung einer synthetischen Vorgehensweise: Analyse einer Anwendung im Unternehmen
6. Kritische Betrachtung

In dem zweiten Kapitel werden wesentliche Begriffe definiert und Grundlagen zu den Vorgehensmodellen und der Systemanalyse vermittelt. Die Beherrschung der Komplexität und die Zerlegungsstrategien stellen dabei wesentliche Aspekte der Systemanalyse dar.

Basierend auf den Zerlegungsstrategien werden in dem dritten Kapitel „Konzepte und ganzheitliche Vorgehensweisen“ die Analysemethoden und Vorgehensweisen beschrieben. Entsprechend der Zielsetzung handelt es sich dabei um kon­ven­tionelle- und objektorientierte Methoden. Dabei werden diejenigen Konzepte her­vor­gehoben, die in der Praxis – im Hinblick auf eine einfache Applikation – relevant sind. Im 4. Kapitel werden die Methoden und Vorgehensweisen mit einer Bewertung abgeschlossen.

Im 5. Kapitel werden die wesentlichen Methoden zur Systemanalyse exem­p­la­­risch umgesetzt. Im letzten Kapitel wird die Ausarbeitung einer kritischen Würdigung unterzogen.

1.3 Abgrenzungen

Die einzelnen Abgrenzungen sind numerisch aufgelistet. Innerhalb der Arbeit finden Querverweise auf die Abgrenzungen statt. Wird beispielsweise auf die Abgrenzung Nr. 2 verwiesen, so findet sich folgender Hinweis im Text: (Abgrenzungen, Nr. 2)

1. Die Analysephase ist unabhängig von einer konkreten Programmiersprache. Auf einzelne Sprachen wird daher nicht eingegangen.
2. In der ganzheitlichen Betrachtung der einzelnen Phasen der Software-Entwicklung werden nur die Schnittstellen zwischen den Phasen hervor­gehoben. Konzepte zur Design- als auch Implementierungsphase sind nicht Bestandteil dieser Arbeit.
3. Im Unternehmen werden grundsätzlich relationale Datenbanken für die
Daten­­­haltung eingesetzt. objektorientierte- oder objektrelationale Daten­­banken sind daher als mögliche Alternativen für die Datenhaltung aus­geschlossen.
4. Die eingesetzten Methoden dieser Arbeit haben nicht den Anspruch auf Vollständigkeit. Es wird lediglich auf Methoden eingegangen werden, die für den Vergleich beider Ansätze relevant sind. Die relevanten Methoden sind in dem dritten Kapitel aufgeführt.
5. Die methodische Vorgehensweise zur Umsetzung der einzelnen Konzepte ist in dem Maße ausgeführt, die für das Verständnis der Methode ausreich­end sind. Für den Vergleich beider Ansätze stehen die Konzepte und Notationen im Vordergrund. Umfassend beschriebene methodische Vor­gehensweisen würden den Rahmen dieser Arbeit sprengen und praxisfern sein. Denn „[…] beim praktischen Einsatz zeigt sich, dass ein solch grobes Methodenraster nicht ausreicht. Andererseits ist ein sehr detailliertes Vor­gehensmodell oft nur für bestimmte Anwendungen geeignet und kann nicht problemlos auf andere Bereiche übertragen werden. Der erfahrene Entwickler wendet – meist mehr oder weniger intuitiv – hunderte von Regeln an, die er situationsspezifisch einsetzt.“.^[19]
6. Die UML ist sehr komplex und beinhaltet zur Systemspezifikation insgesamt 13 Diagramm-Typen. Selbst erfahrene Entwickler haben Probleme damit den vollständigen Umfang zu verinnerlichen.^[20] Für die Systemanalyse wird daher eine Auswahl der UML-Methoden getroffen, die für eine praktikable Vorgehensweise am besten geeignet sind.
7. In der Literatur wird gelegentlich OOA als Synonym für OOA und objekt­orientiertes Design (OOD) genutzt. In dieser Ausarbeitung wird die OOA also die objektorientierte Analyse eines Systems verstanden.
8. Es werden nur die wesentlichen Konzepte einer Methode, die für das Verständnis der Methode relevant sind, beschrieben. In der Regel werden die vernachlässigten Konzepte genannt und ggfls. auf externe Literatur ver­wiesen.
9. Entwurfsmuster werden für den Entwurf von Klassen ausgegrenzt. Die Berück­sichtigung von Entwurfsmustern würde den Rahmen dieser Arbeit sprengen.
10. Als Vertreter der konventionellen Methoden wird in dieser Arbeit nur auf die ER-Modellierung und dem Datenflussdiagramm der Strukturierten Analyse eingegangen. Die Begründung hierzu ist in dem Kapitel „3.2 Konventionelle Methoden“ aufgeführt.
11. Eine Software-Lösung ist immer nur als eine Zwischenlösung anzusehen, denn Software-Anwendungen sind mit dem Problem behaftet nicht beständig sein zu können. Wir leben in einer sich ständig verändernden Umwelt, bei denen sich die Anforderungen ändern und neue Techniken wesentlich bessere Lösungen ermöglichen.^[21] Ein vergleichbares Problem ist auch in der Analysephase gegenwertig: „’If you wait for a complete and perfect concept to germinate in your mind, you are likely to wait forever’ DeMarco.”^[22] Die Analyse hat also nicht den Anspruch auf Vollständigkeit, denn diese ist bei Software-Architekturen nicht gegeben.

2 Theoretische Grundlagen

In dem Abschnitt der theoretischen Grundlagen werden zunächst die wesentlichen Begriffe dieser Arbeit definiert. Im Anschluss werden Grundlagen zu den Vor­gehensmodellen vermittelt. Die Vorgehensmodelle sind bedeutsam für das system­atische Projektvorgehen, vgl. Kapitel „1.1 Motivation“. Als letztes Bestandteil der theoretischen Grundlagen wird im Abschnitt „Systemanalyse“ auf grundlegende Techniken zur Beherrschung der Komplexität, Zerlegungsstrategien und das
methoden­gestützte Vorgehen eingegangen.

2.1 Begriffsbestimmungen

Um den Lesefluss nicht zu beeinträchtigen, werden wesentliche Begriffe unter den Begriffsbestimmungen geführt: System, Systemanalyse, Modell und Software. Die abstraktere Beschreibung für die objektorientierte Analyse als auch die Analyse mit konventionellen Methoden ist die Systemanalyse. Die Definition der Begriffe
System und Systemanalyse sind daher grundlegend für das Verständnis beider Analyseverfahren.

Das Ergebnis einer Analyse ist ein Modell (Vgl. Kapitel „3.3 Objektorientierte
Methoden“). Daher wurde dieser Begriff ebenfalls unten den Begriffsbestimmungen aufgenommen.

Aus dem Untertitel ist zu entnehmen, dass das Analyseverfahren anhand einer einfachen Applikation praktiziert wird. Die Applikation entspricht in dieser Ausarbeitung einer Anwendungssoftware. Die Software und die Klassifikation dessen bilden somit die letzte Begriffsbestimmung. Unter den Begriffs­bestimmungen werden folglich Begriffe definiert, die direkt aus der Titelbezeichnung stammen oder mit diesen in enger Beziehung stehen.

Weitere Begriffsdefinitionen, wie z. B. Systemdenken und Methoden werden im
Zuge ihrer Anwendung, je nach Umfang, entweder direkt im Text oder als Fußnote definiert.

2.1.1 System

Der Begriff stammt aus dem Griechischen und bedeutet „ein aus mehreren Teilen zusammengesetztes Ganzes“.^[23] Im Folgenden werden zwei Definitionen eines
Systems im Kontext der Informationstechnologie genannt:

Erste Definition:

„Ein System ist eine Einheit, die aus miteinander interagierenden Software- und Hardware-Bausteinen besteht sowie zur Erfüllung eines fachlichen Ziels existiert. Es kommuniziert zur Erreichung seines Ziels mit seiner Umwelt und muss den umweltvorgegebenen Rahmenbedingungen Rechnung tragen.“^[24]

Zweite Definition:

„Ein System zeichnet sich […] durch die ganzheitliche Betrachtungsweise aus, aufbauend auf dem Grundsatz, dass das Ganze mehr ist, als die Summe seiner Einzelteile.“^[25] Die Mehrleistung ist durch die Zusammenarbeit von Komponenten über deren Schnittstellen begründet. Erst die Kooperation befähigt ein System, die gewünschten Funktionen zu erfüllen.^[26]

In dieser Ausarbeitung wird das System gemäß der ersten Definition verstanden. Der Grundsatz, dass das Ganze mehr ist, als die Summe seiner Einzelteile ist kein Widerspruch zu der ersten Definition. Die zweite Definition ist daher als Ergänzung zu betrachten.

2.1.2 Systemanalyse

Nach Dietmar Abts und Wilhelm Mülder wird die Systemanalyse wie folgt definiert:

Erste Definition:

„Unter Systemanalyse verstehen wir hier das systematische Vorgehen,

- um Anforderungen an ein zu erstellendes oder zu erweiterndes System
möglichst vollständig und konsistent zu identifizieren und zu­ dokumentieren sowie
- ein Modell des Systems zu erstellen, mit dem sich alle Anforderungen erfüllen lassen.

Das Ergebnis dieser Tätigkeit ist die Spezifikation oder das Fachkonzept.“^[27]

Zweite Definition:

Die Definition nach Ulrich Gonschorrek und Wolfgang Hoffmeister für die System­analyse lautet wie folgt: „Unter Systemanalyse wird die Zerlegung, Ordnung und Unter­suchung ermittelter – Aber noch ungeordneter – Informationen eines (abge­grenzten) Systems nach bestimmten Kriterien und dessen Verhalten in der System­umwelt verstanden.“^[28]

In dieser Ausarbeitung wird für die Systemanalyse die Definition von Ulrich Gonschorrek und Wolfgang Hoffmeister übernommen. Die Definition von Dietmar Abts und Wilhelm Mülder drückt sich mit dem Begriff „identifizieren“ noch zu ungenau aus. Die zweite Definition ist mit der Begriffswahl „Zerlegung, Ordnung und Unter­suchung“ wesentlich genauer. Zudem wird nach der zweiten Definition auch das Verhalten des Systems mit der Systemumwelt in die Betrachtung mit ein­bezogen.

2.1.3 Modell

„Ein Modell ist ‘… ein Objekt, das auf der Grundlage einer Struktur, Funktions- oder Verhaltensanalogie zu einem entsprechenden Original von einem Subjekt ein­gesetzt und genutzt wird, um eine bestimmte Aufgabe lösen zu können, deren Durch­führung mittels direkter Operationen am Original zunächst oder überhaupt nicht möglich bzw. unter gegebenen Bedingungen zu aufwendig ist.‘“^[29]

2.1.4 Software

Aufgrund der Bedeutung von Software für diese Arbeit, umfasst die Begriffs­­bestimmung neben der Definition auch eine Liste von Eigenschaften und eine mögliche Klassifizierung.

Erste Definition:

Nach der Brockhaus Enzyklopädie 2003 wird die Software wie folgt definiert: „[dt. »weiche Ware«], nach DIN 44300 die »Gesamtheit oder Teil der Programme für Rechensysteme, wobei die Programme zusammen mit den Eigenschaften der
Rechensysteme den Betrieb der Rechensysteme, die Nutzung der Rechensysteme zur Lösung gestellter Aufgaben oder zusätzlicher Betriebs- und Anwendungsarten der Rechensysteme ermöglichen«“^[30]

Zweite Definition:

Eine weitere Definition von Wolfgang Hesse: „Software (kurz SW): Menge von
Programmen oder Daten zusammen mit begleitenden Dokumenten, die für ihre
Anwen­dung notwendig oder hilfreich sind“^[31]

Die zweite Definition umfasst neben den Programmen auf den Rechensystemen auch die zugehörigen Daten und Dokumentationen. Über diese Definition wird das Verständnis von Software in dieser Ausarbeitung eher getroffen.

Um den Begriff „Software“ näher beschreiben zu können, werden im Folgenden ele­men­tare Eigenschaften einer Software genannt und eine Klassifizierung vor­genommen:^[32]

- Software ist ein immaterielles Produkt
- Software unterliegt keinem Verschleiß
- Software altert
- Software ist schneller änderbar als ein materielles Produkt
- Eigenschaften von Software können nicht in einfacher Weise quantifiziert werden.
- Software ist schwer zu vermessen

Die Software kann in Anwendungssoftware und in Systemsoftware unterteilt werden. Die Applikation aus dem Untertitel entspricht demnach einer Anwendungs­software.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 Mögliche Unterteilung von Software^[33]

Die Aufteilung der Betriebswirtschaftlichen Anwendungssoftware nach „Technische Anwendungssoftware“ und „Kommerziellen Anwendungssoftware“ kann nicht nach­vollzogen werden. Denn die Anwendungssoftware in dieser Ausarbeitung entspricht auch einer Branchensoftware. Die Branchensoftware ist allerdings direkt der Kom­merziellen Anwendungssoftware zugeordnet, was für diese Anwendungs­software nicht zutrifft. Die Ursache für das Problem in der Unterteilung liegt darin, dass der Autor in der Unterteilung verschiedene Perspektiven (Einsatzgebiet + Lizensierung) gemischt hat.

2.2 Vorgehensmodelle

Einen guten Einstieg, wenn auch nicht vollständige Übersicht, bietet das Buch „Vorgehensmodelle kompakt“ von den Autoren Christian Bunse und Antje von Knethen. Zu den Vorgehensmodellen der ersten Generation aus den 90er Jahren zählen demnach unter anderem:

- OMT (Object Modeling Technique) von James Rumbaugh,
- Booch von Grady Booch und
- Objectory von Ivar Jacobson.

Alle drei Modelle wurden im Jahr 1999 zu dem Unified Process^[34] vereint, welches sich zu einem populären iterativen^[35] Softwareentwicklungsprozess etabliert hat. Zahlreiche weitere Modelle der zweiten Generation haben diese als Grundlage
ge­nommen, wie die unternehmensgetriebene Vorgehensmodelle OOSE Engineering Process^[36] (OEP) oder Rational Unified Process (RUP) von IBM.

Die Vorgehensmodelle sind in der Regel abstrakt gehalten, um ein möglichst breites Spektrum an Software-Architekturen abdecken zu können. Dieses ermöglicht den Anwender ein Interpretationsspielraum, jedoch mit enormen Zeitverlust in der Konkretisierungsphase der abstrakten Beschreibungen. Ein detailliertes Vorgehens­modell hingegen gibt bereits fertige Lösungen vor, welche nur noch eingesetzt werden müssen. Der Nachteil dabei ist, dass diese nicht die Realität in den Unternehmen abbilden. „Die Auswahl der richtigen me­thodischen Vorgehensweise ist eine Gratwanderung zwischen Formalismus und Formlosigkeit.“^[37]

Vorgehensmodelle bieten einen standardisierten Entwicklungsprozess, welche wie folgt definiert ist:^[38]

- Ein Vorgehensmodell legt fest, wie Projekte gleicher Art ablaufen.
- Ein Vorgehensmodell benennt die an den Projekten Beteiligten und be­schreibt ihre Aufgaben
- Ein Vorgehensmodell stellt Methoden zu Verfügung, die bei der Bewältigung der Aufgaben genutzt werden.

Die Vorgehensmodelle sollen nur einen Rahmen bilden und erfordern nicht eine starre Einhaltung aller Regeln. In einem Software-Projekt zählt letztendlich nur das Ergebnis. Selten wird die Einhaltung starrer Vorgehensmodelle hinterfragt.^[39]

Eine Umfrage der Computer Zeitung aus dem Jahr 2005 hat den Bekanntheitsgrad von Vorgehensmodellen in deutschen Unternehmen ermittelt. Werden die einzelnen Prozentangaben summiert, so erhält man mehr als 100 Prozent. Dieses resultiert daher, dass in Unternehmen mehrere Vorgehensmodelle eingesetzt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 Bekanntheitsgrad von Vorgehensmodellen^[40]

Eine ultimative Vorgehensweise gibt es demnach nicht, Stand 2005.

Die Vorgehensmodelle können in vier Familien unterteilt werden:^[41]

- sequentielle Vorgehensmodelle
- wiederholende Vorgehensmodelle
- prototypische Vorgehensmodelle
- wiederverwendungsorientierte Vorgehensmodelle

Die sequentiellen, wiederholenden und prototypischen Vorgehensmodelle werden weiter erläutert. Die Wiederverwendungsorientierten basieren auf wiederholende Vorgehensmodelle, wobei bestimmte Komponenten auf Wiederverwendung über­prüft und in einer Bibliothek abgelegt werden. Auf dieses Vorgehensmodell wird daher nicht weiter eingegangen.

2.2.1 Sequentielle Vorgehensmodelle

Typische Vertreter der sequentiellen Vorgehensweise sind das Phasen-, Wasser-, oder Schleifenmodell. Die einzelnen Aktivitäten werden sequentiell hintereinander durchgeführt. Die Aktivitäten umfassen in der Regel Analyse, Design, Implemen­tierung, Test und Wartung.

Sequentielle Vorgehensweisen haben das Bestreben, das System in der Analyse-Phase möglichst vollständig zu analysieren. Erst zum Ende des Projektes entsteht ein sichtbares Ergebnis – sofern das Projekt zu dem Zeitpunkt nicht schon bereits gescheitert ist. Denn Erfolgs- und Misserfolgsstudien haben immer wieder gezeigt, dass eine enge Korrelation zwischen der Verwendung des Wasserfallmodells (stell­vertretend für die sequentielle Vorgehensweise) und den höchsten Miss­erfolgsraten bei Softwareprojekten besteht.^[42] Dieses wird damit begründet, dass eine voll­ständige Spezifikation in der Analysephase nicht möglich ist. Eine Studie von Boehm und Papaccio zeigt, dass bei einem typischen Softwareprojekt 25% der Anforderungen geändert werden^[43]. Eine weitere Studie^[44] geht sogar von Änderungs­raten von 35% - 50% aus.^[45]

Das Wasserfallmodell, eines der populärsten Vertreter^[46] der sequentiellen Vorgehens­weise, wurde eigentlich missverstanden. 1970 schlug Winston Royce die Vorgehens­weise zur Entwicklung von Software vor, welches in der ursprünglichen Version zwei Iterationen durchlaufen sollte – um die Erkenntnisse der ersten Iter­ation in die zweite übernehmen zu können. Der Vorschlag mit der zweiten Iter­ation ist allerdings unglücklicherweise verloren gegangen, sodass sich das heutige Wasserfallmodell auf fehlerhafte Informationen stützt. Winston Royce ist immer ein Befürworter der iterativen, inkrementellen^[47] und evolutionären Ent­wicklung gewesen.^[48] Etwas später publizierte Barry Boehm das sogenannte Spiral­modell^[49]. Obwohl es einen iterativ-inkrementellen Ansatz verfolgte fand es in der Praxis wenig Zuspruch. Das Wasserfallmodell galt damals als bodenständiger.^[50]

2.2.2 Wiederholende Vorgehensmodelle

Bei wiederholenden Vorgehensmodellen werden die einzelnen Phasen nicht se­­quen­­­tiell, sondern wiederholend durchgelaufen. Zu den wiederholenden Vor­gehens­­­­modellen zählen u.a. folgende Vorgehensweisen:^[51]

- Inkrementelles Vorgehen
- Iteratives Vorgehen.

Beide Vorgehensweisen werden nun näher beschrieben.

2.2.2.1 Inkrementelles Vorgehen

Die Analyse des Gesamtsystems erfolgt in Teilen bzw. einzelnen Inkrementen. Erst wenn das letzte Inkrement analysiert ist, herrscht ein Gesamtbild des Systems. Als ein Spezialfall des inkrementellen Vorgehens kann das anwendungsfallgetriebene Vorgehen angesehen werden.^[52] Dabei werden die einzelnen Anwendungsfälle als Inkremente angesehen. Das Agile Vorgehen stellt einen weiteren Extremfall des in­kre­men­tellen Vorgehens dar. Die einzelnen Inkremente werden dabei erst dann ermittelt und validiert, sobald ein unmittelbarer Bedarf ausgesprochen wird.^[53] Das agile Vorgehen hat mittlerweile einen großen Stellenwert in der Software-Entwicklung. In dem Kapitel „2.2.2.3 Agiles Vorgehen“ wird das Thema daher nochmals aufgegriffen.

2.2.2.2 Iteratives Vorgehen

Als Iteration wird allgemein das wiederholte Ausführen von Anweisungen oder Funktionen verstanden. Bei der iterativen Software-Entwicklung handelt es sich um einen Lebenszyklusansatz, bei dem die Entwicklung in Folge von kurzen, zeitlich begrenzten Mini-Projekten zerlegt wird, welche als Iterationen bezeichnet werden. Das Ergebnis einer jeden Iteration ist ein getestetes, integriertes und ausführbares partielles System und umfasst somit alle elementaren Entwicklungsaktivitäten.^[54] Das iterative Vorgehen wurde Anfang der 2000er- Jahre immer populärer mit belegbaren Erfolgen (Chaos-Report der Standish Group) dieses Ansatzes.^[55]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 Iterations-Wolke^[56]

Bei der Vielzahl zunehmender Anforderungen und Einflussfaktoren ist es häufig schwierig schon zu Anfang alle Faktoren zu berücksichtigen. Die Grafik veran­schaulicht deutlich die abnehmende Unschärfe bei zunehmenden Iterationen. Je weiter das Projekt voranschreitet, desto kleiner wird die Wolke der Unschärfe und desto konkreter die Anforderungen der tatsächlichen Lösung.

2.2.2.3 Agiles Vorgehen

Die agile Softwareentwicklung entstand Ende der 90er-Jahre als Gegenbewegung zu den überreglementierten und starren plangetriebenen Ansätzen. Das agile
Verfahren ist von enormer Dynamik geprägt, da erkannt wurde, dass stabile Rand­bedingungen sowie beständige Marktsituationen so gut wie nicht vorhanden sind.^[57]

Der Begriff Agilität wird von Highsmith wie folgt definiert: „Agilität ist demnach die Fähig­keit, sogar in einer turbulenten Marktumgebung noch durch gestalterische Tätig­­keiten sowie durch die Reaktionsfähigkeit auf Änderungen einen Vorteil ziehen zu können bzw. die Fähigkeit, Flexibilität und Stabilität in ein Gleichgewicht zu
bringen“^[58]

Das agile Manifest aus dem Jahr 2001 enthält die Grundsätze des agilen Ver­fahrens. Das Manifest wurde wie folgt festgehalten: „Wir entdecken bessere Wege zur Entwicklung von Software, indem wir Software entwickeln und anderen bei der Entwicklung helfen. Durch diese Tätigkeiten haben wir gelernt:

- Individuen und Interaktion sind wichtiger als Prozesse und Werkzeuge.
- Funktionierende Software ist wichtiger als umfangreiche Dokumentation.
- Kooperation mit Projektbetroffenen ist wichtiger als Vertragsverhandlungen.
- Reaktion auf Änderungen ist wichtiger als Festhalten an einem starren Plan.

Natürlich sind auch die Dinge rechts wichtig, aber im Zweifelsfall schätzen wir die linken höher ein.“^[59]

In der Anlage sind zudem die wichtigsten Prinzipien der agilen Programmierung hinterlegt.

2.2.3 Prototypische Vorgehensmodelle

Bei prototypischen Vorgehensmodellen werden bestimmte Zeitpunkte definiert, in der die Prototypen inkrementell entwickelt werden. Es wird unterschieden in einen Analyseprototypen und in einen Entwurfsprototypen.^[60]

Ziel des Analyseprototypen ist es, bereits zu einem frühen Zeitpunkt, Erkenntnisse über schwierige oder unklare Anforderungen zu erlangen. Die Ergebnisse fließen anschließend in die Software-Lösung mit ein.

Ziel des Entwurfsprototypen ist es, unklare oder schwierige Entwurfsaspekte zu überprüfen. Beispielsweise kann überprüft werden, ob die Architektur den Per­formance­-Anforderungen genügt.

Beide Prototypen können entweder als Wegwerfprototypen oder als evolutionäre Prototypen entwickelt werden. Wegwerfprototypen sind in der Erstellung kosten­günstig und werden nach ihrem Einsatz wieder deinstalliert. Evolutionäre Prototypen hingegen werden stetig weiterentwickelt, bis entweder ein fertiges SW-Produkt entsteht oder diese als Teillösungen in ein komplexes Software-System integriert wird. Evolutionäre Prototypen sind von Anfang an mit höherem Aufwand verbunden und verursachen daher höhere Kosten. Diese sind ohne einen Gesamtüberblick über die zu erstellende Anwendung erstellt und bergen daher die Gefahr, dass bei Design-Fehlern der evolutionäre Prototyp sich doch noch zu einem Wegwerf­prototypen entwickelt.^[61]

[...]

^[1] Ulrich Gonschorrek, Wolfgang Hoffmeister: Ganzheitliches Management Strukturierungs- und Informationsprozesse,1. Auflage 2006 Berlin, S.94. Siehe dazu auch Kapitel „2.1.2 Systemanalyse“

^[2] "Beschreibt eine Menge von Theorien, Standards und Methoden, die gemeinsam einen Weg repräsentieren, Wissen zu organisieren. „Thomas Kuhn 1970: The Structure of Scientific Zitat nach E. Schikuta: Objektorientiertes Paradigma - Grundlegende Algorithmen und Datenstrukturen, http://www.pri.univie.ac.at/~schiki/unterlagen/GAlgoDat/KAPITEL4.pdf, Abruf: 05.05.2011

^[3] Der Begriff stammt aus der Zeit der Lochkarten. Da die Länge der Zeilen auf 80 begrenzt war, haben Programmierer in der Regel nur eine Anweisung pro Zeile geschrieben. Vgl. Harry M. Sneed, Richard Seidl, Manfred Baumgartner: Software in Zahlen – Die Vermessung von Applikationen, 1. Ausgabe 2010 München

^[4] Mit Komponentenmetriken werden einzelne Bestandteile eines Software-Systems separat bewertet: z. B. Anzahl Klassen, Anzahl Methoden, Anzahl Attribute. Strukturmetriken hingegen analysieren die Komplexität des gesamten Klassenverbundes, wie beispielsweise Vererbungsstrukturen. Vgl. Dirk W. Hoffmann: Software Qualität, 1. Auflage 2008 Heidelberg, S. 263 ff.

^[5] Vgl. Hans Brandt-Pook, Rainer Kollmeier: Softwareentwicklung kompakt und verständlich - Wie Softwaresysteme entstehen, 1. Auflage 2008 Wiesbaden, S. 9

^[6] Z. B. Karl-Heinz Rau: Objektorientierte Systementwicklung - Vom Geschäftsprozess zum Java-Programm, 1. Auflage 2007 Wiesbaden, S. 6

^[7] o.V.: Traffix Network Partner GmbH, http://www.traffix.de/projektmanagement.html, Abruf: 01.05.2011

^[8] Vgl. Jorge Dominguez: The curious case of the chaos report, http://www.projectsmart.co.uk/the-curious-case-of-the-chaos-report-2009.html, Abruf: 01.05.2011

^[9] „Adj. systematisch; so, dass etwas sorgfältig, nach einem bestimmten Plan organisiert ist, einem bestimmten Prinzip folgt.“ http://de.thefreedictionary.com/systematisch , Abruf 02.07.2011

^[10] Auf methodische Vorgehensweisen wird in dem dritten Kapitel ausführlich eingegangen.

^[11] „Verfahren sind ausführbare Vorschriften oder Anweisungen zur gezielten Einsatz von Methoden“, o.V:http://www.informatikbegriffsnetz.de/arbeitskreise/vorgehensmodelle/themenbereiche/prinzipMethodeWerkzeug.html, Abruf: 15.06.2011

^[12] Vgl. W. Beinhauer, M. Herr, A. Schmitt: SOA für agile Unternehmen - Serviceorientierte Architekturen verstehen, einführen und nutzen, 1. Auflage 2008 Düsseldorf, S.28 und Baeumle-Courth, Nieland Schröder: Wirtschaftsinformatik,1. Auflage 2004 Oldenburg, S. 127

^[13] Vgl. Peter Forbirg: Objektorientierte Softwareentwicklung mit UML, 3. Auflage 2009 München, S. 5

^[14] Die Objektorientierte Analyse ist mittlerweile über 20 Jahre alt, siehe Kapitel „3.1 Geschichte“

^[15] „Die Synthese ist die sinnvolle Zusammenfassung der analytisch gewonnenen Faktoren, Ziele, Elemente und Beziehungen“ Ulrich Gonschorrek, Wolfgang Hoffmeister: Ganzheitliches Management - Strukturierungs- und Informationsprozesse,1. Auflage 2006 Berlin, S. 95

^[16] Vgl. Craig Larman: UML2 und Patterns angewendet - Objektorientierte Softwareentwicklung, 1. Auflage 2005 Heidelberg, S. 42

^[17] Andreas Häuslein: Systemanalyse - Grundlagen – Techniken – Notierungen, 1. Auflage 2004 Berlin / Offenbach, S. 18

^[18] Diese werden in den Kapiteln 3 und 4 behandelt und in Kapitel 5 angewendet.

^[19] Heide Balzert: Lehrbuch der Objektmodellierung - Analyse uns Entwurf mit UML2, 2. Auflage 2005 München, S. 7

^[20] Vgl. Mario Winter: Modellgetriebene Entwicklung objektorientierter Software, 1. Auflage 2005 Heidelberg, S. 73

^[21] Vgl. Peter Schweizer: Systematisch Lösungen finden - Eine Denkschule für Praktiker, 3 Auflage 2008 Zürich, S. 30

^[22] DeMarco Zitat nach Heide Balzert: Lehrbuch der Objektmodellierung - Analyse uns Entwurf mit UML2, 2. Auflage 2005 München, S. 136

^[23] Herwig Mayr: Projekt Engineering - Ingenieurmäßige Softwareentwicklung in Projektgruppen, 2. Auflage 2005 München / Wien, S. 25

^[24] Oliver Vogel, Ingo Arnold, Arif Chughtai, Edmund Ihler, Timo Kehrer, Uwe Mehlig, Uwe Zdun: Software Architektur - Grundlagen – Konzepte – Praxis, 2. Auflage 2009 Heidelberg, S. 46

^[25] Herwig Mayr: Projekt Engineering - Ingenieurmäßige Softwareentwicklung in Projektgruppen, 2. Auflage 2005 München / Wien, S. 26

^[26] Vgl. Gernot Starke: Effektive Software-Architekturen - Ein praktischer Leitfaden, 4. Auflage 2009 München, S. 22

^[27] Dietmar Abts, Wilhelm Mülder: Masterkurs Wirtschaftsinformatik – Kompakt, praxisnah, verständlich, 1. Auflage 2010 Wiesbaden, S. 567

^[28] Ulrich Gonschorrek, Wolfgang Hoffmeister: Ganzheitliches Management Strukturierungs- und Informationsprozesse,1. Auflage 2006 Berlin, S. 94

^[29] Georg Klaus, Manfred Buhr, Philosophisches Wörterbuch, Berling, 1971, 8.Auflage Zitat nach Jörg Raasch: Systementwicklung mit Strukturierten Methoden - Ein Leitfaden für die Praxis und Studium, 3. Auflage 1993 München / Wien, S. 65

^[30] Gustav Pomberger, Wolfgang Pree: Software Engineering - Architektur-Design und Prozess­orientierung, 3. Auflage 2004 München / Wien, S. 1

^[31] Wolfgang Hesse: Terminologie der Softwaretechnik Zitat nach Helmut Balzert: Lehrbuch der Softwaretechnik - Basiskonzepte und Requirements Engineering, 3. Auflage 2009, Heidelberg

^[32] Vgl. Björn Wolle: Grundlagen des Software-Marketing – Von der Softwareentwicklung zum nachhaltigen Markterfolg, 1. Auflage 2005 Wiesbaden, S.15 und vgl. Helmut Balzert: Lehrbuch der Softwaretechnik - Basiskonzepte und Requirements Engineering, 3. Auflage 2009 Heidelberg, S. 9f

^[33] In Anlehnung an: Hildebrand 1990, S. 18 Zitat nach Tessen Freund: Software Engineering durch Modellierung wissensintensiver Entwicklungsprozesse, 1. Auflage 2007 Berlin, S. 34

^[34] Der Unified Process, welcher als Meilenstein in der Entwicklung der Vorgehensweisen gilt, taucht in der Literatur relativ selten vor. In dem Werk von Heide Balzert ist es noch nicht einmal im Stichwortverzeichnis vertreten. Vielmehr steht die spezielle Ausprägung Rational Unified Process im Focus der SW-Entwickler.

^[35] Kurz: Das wiederholte Ausführen von Anweisungen; in dem Kapitel 2.2.2.2 wird auf das iterative Vorgehen näher eingegangen.

^[36] Auf der Internetseite der OOSE Innovative Informatik GmbH können einige Muster als PDF-Dokumente bezogen werden. Die Nutzung des Vorgehensmodells unterliegt allerdings einer Lizenz. Einer der Geschäftsführer ist Bernd Oestereich, welcher mit zahlreichen Publikationen über die Objektorientierte Programmierung und UML bereits einen wertvollen Beitrag zu dem OO-Paradigma geleistet hat.

^[37] Heide Balzert: Lehrbuch der Objektmodellierung - Analyse uns Entwurf mit UML2, 2. Auflage 2005 München, S. 130

^[38] Hans Brandt-Pook, Rainer Kollmeier: Softwareentwicklung kompakt und verständlich - Wie Software­s­ysteme entstehen, 1. Auflage 2008 Wiesbaden, S. 3

^[39] Vgl. Gernot Starke: Effektive Software-Architekturen - Ein praktischer Leitfaden, 4. Auflage 2009 München, S. 7

^[40] In Anlehnung an O.V.: Softwareentwicklung läuft nicht nach Zuruf, Computer Zeitung Nr. 46/05 Zitat nach Stephan Kleuker: Grundkurs Softwareengineering mit UML - Der pragmatische Weg zu erfolgreichen Softwareprojekten,1. Auflage 2009 Wiesbaden, S. 24

^[41] Vgl. Christian Bunse, Antje von Knethen: Vorgehensmodelle kompakt, 2. Auflage 2008 Heidelberg, S. 3

^[42] Vgl. Craig Larman: UML2 und Patterns angewendet - Objektorientierte Softwareentwicklung, 1. Auflage 2005 Heidelberg, S. 54

^[43] Understanding and Controlling Software Costs. IEEE – Transactions on Software Engineering, B. Boehm und P. Papaccio, Oct 1988 Zitat nach Craig Larman: UML2 und Patterns angewendet - Objektorientierte Softwareentwicklung, 1. Auflage 2005 Heidelberg, S. 60

^[44] Applied Software Measurement. C. Jones, NY, NY.: McGraw-Hill, 1997 Zitat nach Craig Larman: UML2 und Patterns angewendet - Objektorientierte Softwareentwicklung, 1. Auflage 2005 Heidelberg, S. 60

^[45] Vgl. Craig Larman: UML2 und Patterns angewendet - Objektorientierte Softwareentwicklung, 1. Auflage 2005 Heidelberg, S. 60

^[46] Vgl. Kapitel „2.2 Vorgehensmodelle“

^[47] Kurz: Die Aufteilung eines Gesamtsystems in seine einzelnen Teile; in dem Kapitel 2.2.2.1 wird auf das inkrementelle Vorgehen näher eingegangen.

^[48] Vgl. Ralf Gessler, Thomas Mahr: Hardware- Software- Codesign - Entwicklung flexibler Mikroprozessor-FPGA-Hochleistungssysteme, 1. Auflage 2007 Wiesbaden, S. 160 oder Bernd Oestereich, Christian Weiss: APM Agiles Projekt Management - Erfolgreich Timeboxing für IT-Projekte, 1. Auflage 2008 Heidelberg, S. 12

^[49] Das Spiralmodell ist dieser Arbeit als Anlage beigefügt

^[50] Vgl. Bernd Oestereich, Christian Weiss: APM Agiles Projekt Management - Erfolgreich Timeboxing für IT-Projekte, 1. Auflage 2008 Heidelberg, S. 13

^[51] Vgl. Christian Bunse, Antje von Knethen: Vorgehensmodelle kompakt, 2. Auflage 2008 Heidelberg, S. 11 f

^[52] Vgl. Chris Rupp: Systemanalyse kompakt, 2. Auflage 2009 Berlin / Heidelberg, S. 23

^[53] Vgl. Chris Rupp: Systemanalyse kompakt, 2. Auflage 2009 Berlin / Heidelberg, S. 23

^[54] Vgl. Craig Larman: UML2 und Patterns angewendet - Objektorientierte Softwareentwicklung, 1. Auflage 2005 Heidelberg, S.55 und vgl. Bernd Oestereich, Christian Weiss: APM Agiles Projekt Management - Erfolgreich Timeboxing für IT-Projekte, 1. Auflage 2008 Heidelberg, S. 4

^[55] Vgl. Bernd Oestereich, Christian Weiss: APM Agiles Projekt Management - Erfolgreich Timeboxing für IT-Projekte, 1. Auflage 2008 Heidelberg, S. 13

^[56] Quelle: o.V: www.oose.de/apm/download, Abruf: 10.06.2011

^[57] Vgl. Dirk Koch: Neue Ansätze und Entwicklungen im Projektmanagement - Die Bewältigung von Unbestimmtheiten und Grenzen der Planung, 1. Auflage 2008 Hamburg, S. 71

^[58] Highsmith 2004, S. 16 Zitat nach Dirk Koch: Neue Ansätze und Entwicklungen im Projektmanagement - Die Bewältigung von Unbestimmtheiten und Grenzen der Planung, 1. Auflage 2008 Hamburg, S. 71

^[59] Dirk Koch: Neue Ansätze und Entwicklungen im Projektmanagement - Die Bewältigung von Unbestimmtheiten und Grenzen der Planung, 1. Auflage 2008 Hamburg, S. 78

^[60] Vgl. Christian Bunse, Antje von Knethen: Vorgehensmodelle kompakt, 2. Auflage 2008 Heidelberg, S. 9

^[61] Vgl. Gerhard Versteegen, Knut Salomon, Rainer Heinold: Change Management bei Software-Projekten, 1. Auflage 2001 Berlin/Heidelberg, S. 11