Review eines Software Reengineering Projektes

Inhaltsverzeichnis

1 Einleitung

2 Software Engineering
2.1 Grundlagen des Software Engineerings
2.2 Qualitätsmanagement
2.2.1 Die Qualitätsschaffung
2.2.2 Die Qualitätssicherung
2.3 Vorgehensmodelle
2.3.1 Klassische Vorgehensmodelle
2.3.2 Agile Vorgehensmodelle
2.3.3 Fazit der Vorgehensmodelle
2.4 Definition und Methoden des Reengineerings
2.5 Definition des Webengineerings

3 Projektmanagement
3.1 Grundlagen des Projektmanagements
3.2 Projektcontrolling
3.2.1 Auftraggeber Kalkulationen
3.2.2 Auftragnehmer Kalkulationen
3.2.3 Risikomanagement
3.2.4 Fazit des Projektcontrollings
3.3 Phasen eines Projektes
3.3.1 Projektstart
3.3.2 Projektplanung
3.3.3 Projektdurchführung
3.3.4 Projektabschluss
3.4 Anforderung an das Projektmanagement

4 Projektanalyse AVAS-Redesign
4.1 Projektvorphase
4.2 Projektstart und Planung
4.3 Projektdurchführung
4.4 Projektabschluss

5 Fazit und Lösungsalternativen AVAS-Redesign

6 Schlussbemerkungen und Ausblick

Anhang X

Abstract

Diese Abhandlung diskutiert vorhandene Methoden des Software Engineerings und des Projektmanagements anhand eines Praxisbeispiels.

Seit den letzten Jahrzehnten sind Computersysteme immer tiefer in die Industrie vorgedrungen. Auch außerhalb der Fertigung sind Softwareprogramme immer grö- ßer werdende Instrumente zur Umsetzung von betriebswirtschaftlichen Interessen.

Dem Trend zur höheren Komplexität parallel folgend, steigt auch die Zahl von Programmier- und Abbildungsfehlern in Softwareprodukten.

Um die Fehleranzahl bestmöglich zu verringern und die Anforderungen an die Software wunschgetreu umsetzen zu können, gibt es das Software Engineering. Un- ter dem Begriff „Software Engineering“ sollen seit seiner Prägung im Jahre 1969, Vorgehensweisen und Softwarearchitekturen gesammelt werden. Mit deren Hilfe soll es gleich anderen Ingenieurszweigen möglich werden, methodisch und struktu- riert, Softwareprodukte entstehen zu lassen. Da das Software Engineering als Inge- nieursdisziplin, analog zu den Computern selbst, noch sehr jung ist, unterliegen beide ständigen Veränderungen und Erweiterungen. Daher kommt es in der Indust- rie immer häufiger vor, dass bereits bestehende Systeme abgelöst oder an eine neue Umwelt angepasst werden müssen. Die notwendigen Methoden, bereits geschriebe- ne Softwarecodes oder Programmlogiken wiederzuverwenden, gehören zum Soft- ware Reengineering.

Im Zuge der Ausbreitung von Unternehmen über Ländergrenzen hinweg wächst die Notwendigkeit, ortsungebunden auf Programme und Dateien zugreifen zu können. Im Webeengineering werden Architekturen und Techniken angewandt, diese Orts- ungebundenheit einer Software über das Übertragungsmedium Intra- oder Internet zu bewerkstelligen.

Da die Erstellung oder Einführung eines neuen Softwareproduktes in einem Unter- nehmen immer eine Investition darstellt, muss diese auch im Vorfeld auf ihre Kos- ten im Vergleich zum erwarteten Nutzen analysiert werden. Jede Investition ist gleichzeitig auch ein Projekt, das in einem Auftraggeber- und Auftragnehmerver- hältnis für einen bestimmten Funktionsumfang einen entsprechenden Zeit- und Kostenrahmen verbraucht.

Um diese Rahmen einzuhalten gibt es die Methoden des Projektmanagements. Die Art und Weise wie und ob ein Risikomanagement durchgeführt wird, das Control- ling innerhalb der Projektphasen, das gewählte Team und die Umweltbedingungen eines Projektes sind ausschlaggebende harte und weiche Faktoren im Projektmanagement. Diese beeinflussen, neben dem richtigen Software Engineering, die Qualität und Kosten eines Softwareproduktes.

Anhand eines Reviews eines Software Engineering Projektes, das unter hohem Zeit- verzug und Budgetüberschreitungen litt, werden beispielhaft die dort genutzten Werkzeuge des Software Engineerings und der Projektleitung analysiert. Im schrittweisen Durchlauf durch die Projektphasen werden, zusammengefasst, die gemachten Fehler oder falsch angewendeten Methoden herausgestellt sowie mögli- che Lösungswege oder Verhinderungsstrategien aufgezeigt. Dabei offenbart sich, dass die größten Fehler des Projektes nur bedingt in der genutzten Architektur lie- gen, sondern in einer fehlenden Projektstruktur und dem Mangel an Erfahrungen zu suchen sind.

Darauf eingehend werden am Ende der Abhandlung Punkte abstrahiert, die zukünftigen Projekten helfen sollen, ähnliche Fehler zu vermeiden.

Abbildungsverzeichnis

Abbildung 1: Softwareentwicklungsmodelle

Abbildung 2: Klassische und iterative Entwicklung

Abbildung 3: Wasserfallmodell

Abbildung 4: V-Modell Übersicht

Abbildung 5: Rational Unified Process

Abbildung 6: Vergleich von Entwicklungsmodellen

Abbildung 7: Reengineeringverfahren

Abbildung 8 Ablauf eines Reengineeringsprojektes

Abbildung 9: Client, Server Architektur

Abbildung 10: Goldenes Dreieck des Projektmanagements

Abbildung 11: Einsatz von systematischem Risikomanagement

Abbildung 12: Phasen des Projektmanagement

Abbildung 13: Inhalte eines Projektangebotes

Abbildung 14: Software Lebenszyklus

Abbildung 15 Projektmanagement ARIS Haus

Abbildung 16: Berechnungsprogramme in Codezeilen

Abbildung 17: Projektdreiecke AVAS-Redesign

Abbildung 18: Meilensteinplan SMART-LD

Abbildung 19: Projektfortschritt AVAS-Redesign

Abbildung 20: Codezeilen AVAS und SMART-LD ohne Libraries

Abbildung 21: Testplan

Abbildung 22: Software Requirements Specification

Abbildung 23: RIMS Standardrisiken

Abbildung 26: Systemeinbindung SMART-LD

Abbildung 25: Systembeschreibung SMART-LD

Abbildung 24: Meilensteinanalyse

Tabellenverzeichnis

Tabelle 1: Gegenüberstellung der Vorgehensmodelle

Tabelle 2: Meilenstein Checkliste

Tabelle 3: Reengineering-Objekte AVAS

Tabelle 4: Schwachstellenanalyse AVAS in Anlehnung an DIN

Tabelle 5: Risikomanagement Mitarbeiterauslastung AVAS- Redesign

Tabelle 6 Projektfehler und Lösungsmöglichkeiten

Tabelle 7 Software Qualitätsmerkmale nach DIN 9126

Tabelle 8: COCOMO II Projektgröße AVAS-Redesign

Tabelle 9: COCOMO II Projekteigenschaften AVAS-Redesign

Tabelle 10: Meilenstein Aktivitäten in Personenmonaten nach COCOMO II

Tabelle 11: Vergleich COCOMO II Analyse und Ist-Daten AVAS-Redesign

Tabelle 12: AVAS Systemstruktur

Tabelle 13: AVAS-Redesign Stakeholder

Tabelle 14: TCO-Vergleich AVAS und SMART-LD

Tabelle 15: Dokumentmanagement AVAS-Redesign

Formelverzeichnis

Formel 1: einfacher „Return on Investment“

Formel 2: Kapitalwertmethode

Formel 3: COCOMO II

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

„The consequences of poor performance, poor design, instability and mismatching promise and performance are not going to be limited to the computing fraternity, or even their nearest neighbors, but will affect considerable sections of our society whose ability to forgive is inversely proportional to their ignorance of the difficulties we face.”¹

1 Einleitung

Das Projektmanagement ist in Unternehmen eine wichtige Aufgabe, um Neuerun- gen einzuführen und im Wettbewerb mit anderen Unternehmen am Markt zu be- stehen. Durch ihre Natur sind Projekte eine zeitlich begrenzte und interdisziplinäre Aufgabe, die sehr viele Ressourcen verbraucht und herausragende soziale Fähigkei- ten aller Beteiligten fordert. Nicht ohne Grund scheitern 35 % aller Softwareprojekte an einem dieser Punkte oder 75 % erfahren einen größeren Ressourcen- und Zeit- verbrauch als kalkuliert.²

Das hierbei untersuchte Projekt hatte massive Kostenüberschreitungen sowie Ter- minverschiebungen, dennoch wurde es schlussendlich, nach einem zusätzlichen halben Jahr, erfolgreich eingeführt. Die Ursachen für die Abweichungen von den Plandaten soll als Grundlage genutzt werden, um für weitere Projekte Empfehlun- gen zu geben, die gemachten Fehler im Vorfeld zu erkennen und sinnvolle Ansätze zu adaptieren.

In dem Projekt „AVAS Redesign“ ging es um die Ablösung einer seit 30 Jahren produktiv und werksübergreifend genutzten Software („AVAS“) im Dynamowerk Berlin, der Firma Siemens AG.

In dem Dynamowerk werden in Einzelanfertigung Motoren und Stromgeneratoren für einen internationalen Markt hergestellt. Das Werk selbst gehört zum Zweig Siemens „Automation and Drives“ (A & D), darunter „Large Drives and Special ma- chines“ (L D S). Aufgrund der Tatsache, dass der Hauptzweig nicht gleich dem Werkssitz ist, müssen auch internationale Bestrebungen des Konzerns, speziell die Werksausweitung in die osteuropäischen Länder oder nach China, in der IT- Landschaftsgestaltung beachtet und Budgetplanungen abgestimmt werden.

AVAS stellt abteilungsübergreifend Rechentools in Form von hunderten FORTRANProgrammen zu Verfügung, die die gesamte Wertekette werksweit unterstützen. Dabei beeinflussen die Rechenprogramme sich durch Veränderungen in der Datenbank gegenseitig und bilden von hochkomplizierten Berechnungen bis zur Stücklistengenerierung eine Vielzahl von Programmen ab.

Durch die spezielle Anforderung, die an AVAS gestellt worden ist, handelt es sich um eine Eigenentwicklung des Dynamowerkes, wobei das Framework von der IT- Abteilung erstellt und gewartet wurde und inhaltlich von den Fachabteilungen mit Hilfe von Debuggern und Maskeneditoren, um weitere Programme erweitert oder ein bereits bestehendes Programm verändert werden konnte.

Diese dreißig Jahre alte Software leidet daran, dass das Framework, das zur Erstellung genutzt worden ist, seit Jahrzehnten nicht mehr weiterentwickelt wurde. Obwohl die Codeherrschaft bei einer Siemensabteilung lag, ist auch der Quellcode unauffindbar. Bereits vor der Projektinitialisierung lief das System teilweise auf Servern, für die es nicht zugelassen war. Da bestimmte Funktionsbibliotheken jedoch prozessorabhängig sind, wurde eine massive Veränderung im Quellcode notwendig, um die Systemstabilität erhalten zu können.

Darüber hinaus ist AVAS über die Jahre hin gewuchert. Funktionen wurden undokumentiert hinzugefügt, ein Erlernen des Systems ist daher nur über lange Einarbeitungszeiten möglich, wobei immer darauf geachtet werden muss, dass es nur ein Produktivsystem gibt, jede Änderung sich daher an einer anderen Stelle unbemerkt und sofort auswirken kann.

In den nächsten Kapiteln wird der Verlauf der Softwareentwicklung vom Altsystem AVAS über die Werkzeuge und Methoden des Reengineerings, Webengineerings und des Projektmanagements zum neuen „SMART-LD“ aufgezeigt.

Zu Beginn wird das Software Engineering in seiner derzeitigen Entwicklungsstufe vorgestellt. Dabei werden die Vorgehensmodelle der Softwareentwicklung mit ihren Vor- und Nachteilen herausgestellt, eng verwoben, die Grundlagen des Projektmanagements definiert.

Auf dieser Basis aufsetzend, werden die durchlaufenen Phasen des Projektes „SMART-LD“ von der Vorphase bis zur Einführung durchschritten und ihre dabei genutzten Werkzeuge, Methoden und Dokumente analysiert. Zusammengefasst wird eine Diagnose zum Verlauf des Projektes gestellt, die die Gründe für die eingetroffenen Budgetüberschreitungen herausbildet.

Anhand der gemachten Fehler werden dann Verbesserungsvorschläge gegeben, die mögliche, zukünftige Fehler ähnlicher Art verhindern sollen.

Am Schluss werden diese Lösungen und die Durchführung des Projektes verglichen und kritisch Entscheidungen gewürdigt.

2 Software Engineering

Software Engineering als Bezeichnung wurde das erste Mal 1968 in einer von der „NATO Science Committee“ einberufenen Entwicklerkonferenz geprägt. Es sollte damit die ökonomische Bedeutung von Softwareprodukten gezeigt werden, deren Ausmaße bis dato auf Grund der Computerleistungen eher marginal waren und deren Erstellung, Methoden und Strategien fehlten.³

Der Begriff Software Engineering soll ausdrücken, dass für eine Softwareentwick- lung nicht nur Programmierkenntnisse von Nöten sind, sondern auch allgemeines Ingenieurwissen und Projektmanagementqualitäten eine wichtige Rolle spielen.⁴

Die Komponenten des Engineerings lassen sich ein drei Sichtweisen unterteilen:

Prozessorientiert, in die Organisation von Software-Projekten, dazu gehören verschiedenste Modelle, die das Projekt in differenzierte Phasen unterteilt, zusätzlich das Qualitätsmanagement der Software mit seinen Aufgaben und Prinzipien.

In die konstruktions- und architekturorientierte Sicht sind die verschiedenen methodischen und konzeptionellen Arten einer Software zu zählen, diese besteht aus der Konstruktion anpassbarer Software, die Modularisierung und die Architektur von der zu entwickelnden Software.

Die letzte Komponente und interdisziplinäre Schicht des Engineerings besteht aus dem Projektmanagement, worunter die klassischen Projektphasen, der Projektstart, die Projektplanung, die Durchführung und der Projektabschluss fallen.

In diesem Kapitel werden, aufbauend auf den Grundlagen, Kernkompetenzen des Software Engineerings genauer untersucht sowie ihre derzeit wissenschaftlich anerkannten Methoden zusammengetragen und die Besonderheiten des in diesem Projekt genutzten Webengineerings und Reengineerings vorgestellt.

2.1 Grundlagen des Software Engineerings

Die Hauptaufgaben des Software Engineerings und die Problemstellungen in ihren Komponenten sind:⁵

Prozesse

- Anforderungsspezifikation an die Software
- Problemstellung auf Teilaufgaben herunterbrechen
- Qualitätsmanagement

Architektur

- Systemkomplexität bewältigen
- Schnittstellen spezifizieren
- Softwareergonomie

Projektmanagement

- Projektorganisation
- Dokumentationen

Um die Probleme der einzelnen Hauptaufgaben des Software Engineerings zu lösen, gibt es das Informations Engineering, verschiedenste Prinzipien, Techniken und Methoden, Verfahren und Werkzeuge, die im Zusammenhang mit einem passenden Vorgehensmodell dem Projektleiter eine größere Sicherheit und Überschaubarkeit bei der Softwareerstellung bieten sollen.

Ein modernes Softwaresystem besteht aus drei Teilen:

1. Klassenbibliotheken sind Sammlungen von Klassen, die in einer einzigen Programmiersprache verfasst und problembereichsunabhängige logisch zusammenhängende Funktionen bieten.
2. Geschäftsobjekte sind programmierte Objekte, die stellvertretend für Geschäftsbegriffe stehen, z.B. Kunde oder Konto.
3. Frameworks sind anwendungsbezogene zusammengefasste Klassen, die untereinander in Beziehung stehen und daher auch nur in geschlossener Form wiederverwendet werden können.

Ein häufig eingesetztes Mittel in der Softwareentwicklung ist das Prototyping.

Im Prototyping soll in kurzer Zeit ein Muster der Software erstellte werden, auf das bestenfalls in der nachgelagerten Softwareentwicklung aufgebaut werden kann.

Die wohl am häufigsten genutzte Form dieser Entwicklungstechnik ist das explorative Prototyping. Hierbei werden noch vor dem eigentlich Beginn der Entwicklung technische oder designorientierte Wegwerfprototypen erstellt, die dem Software- Kunden die ausgewählte Technik in einem vorzeigbaren Produkt visualisieren kann.

Die Idee des Wegwerfprototypings wird außerhalb des funktionalen Erklärens eines Anwendungssystems noch beim Sammeln von technologischen Erfahrungen genutzt(Rapid Prototyping).⁶

Wiederverwertbare Prototypen, die in Teilsystemen weiterhin eingesetzt werden, gehören zum evolutionären Prototyping, wobei funktional vollständige Teilsysteme unter den Begriff vollständige Prototypen fallen und nicht mehr weiterentwickelt werden müssen (horizontales Prototyping).⁷

Die unvollständigen Prototypen des evolutionären Prototypings bilden vertikal (vertikales Prototyping) Funktionen (z.B. eine Benutzerschnittstelle) ab, deren Methodiken zuerst simuliert und in späteren Entwicklungsphasen erstellt werden.⁸

Das Prototyping ist eine wichtige Methodik um sicherzustellen, dass der Kunde und der Entwickler über „dasselbe“ sprechen und daher schon lange vor dessen Namensprägung in der Softwareentwicklung auch als Mittel der Qualitätssicherung eingesetzt werden.

2.2 Qualitätsmanagement

Qualität im Sinne der DIN 55350 ist die Gesamtheit alle Eigenschaften eines Produktes,die sich auf die Eignung beziehen, ein Erfordernis zu erfüllen.⁹

Das Qualitätsmanagement des Software Engineerings unterstützt methodisch die qualitative Codeerstellung und gibt Hinweise, Qualitätsmängel zu analysieren und deren Verhinderungsmaßnahmen durchzuführen.

Dabei orientiert sich das Qualitätsmanagement an konstruktiven und analytischen Qualitätsmaßnahmen, die in ihren Grundlagen eine Qualitätsplanung und eine interne sowie unabhängige, externe Prüfung beinhalten und in den verschiedenen Vorgangsmodellen zur Softwareentwicklung einen festen Platz besitzen.

Um qualitativ hochwertige Software herzustellen, gibt es zwei große Maßnahmengruppen, die zum einen eine Qualität schaffen und zum anderen helfen, diese zu sichern.¹⁰

2.2.1 Die Qualitätsschaffung

An jeder Softwareentwicklung sind verschiedene Personen beteiligt, die unterschiedlichste Interessen haben. Diese Anforderungen müssen koordiniert werden, um Qualität im Sinne der Interessengruppen (Stakeholder) schaffen zu können.

Um Qualität zu schaffen, müssen entwicklungsvorbereitend konstruktiv organisatorische, strukturelle und personelle sowie analytische Maßnahmen ergriffen werden, damit das Umfeld, in dem die Qualität entstehen soll, existiert.

Organisatorische und strukturelle Maßnahmen umfassen dabei die Bildung von Richtlinien, das Institutionalisieren von Qualitätsmanagement, das iterative oder prototypische Vorgehen (siehe Vorgehensmodelle ) und die Nutzung der richtigen Methoden des Risikomanagements (siehe Projekt).

Personelle Maßnahmen betreffen eine Auswahl der richtigen Personen sowie das Schulen, Koordinieren und Kontrollieren des Entwicklungsfortschrittes.¹¹

Analytische Maßnahmen beinhalten dynamische Prüfungen (Tests, Simulationen, etc.) und statische Prüfungen (Reviews, Code-Inspektionen, etc.), die eine Qualitätsschaffung überprüfen (siehe Phasen eines Projektes).¹²

Im Software Engineering ist jedes Produkt ein eigenständiges Projekt, die Qualität einer Software ist daher interdisziplinär mit dem Projektmanagement als Qualitätsgrundlage (siehe Kapitel 3) mit den Vorgehensmodellen als Ablauforganisation und Methoden der Qualitätssicherung verwoben.

2.2.2 Die Qualitätssicherung

Um die geschaffene Qualität sichern zu können, gibt zusätzlich zu den individuellen Vorstellungen die DIN ISO 9000 ff. ausführliche Hinweise und Richtlinien.

Softwarequalität, wie sie die DIN ISO 9126 vorschlägt, wird in sechs Kategorien ein- geordnet (siehe Software Qualitätsmerkmale nach DIN 9126), die beschriebene und von Beratern geprüfte Qualitätsmerkmale sichern können.

Darüber hinaus gibt das verwendete Vorgehensmodell Werkzeuge, Notationen und Methoden an. Diese richtig befolgt und gewählt, formalisieren Analyse- und Entwicklungsabläufe, bilden Phasen und deren Übergänge ab und dämmen somit Qualitätsschwankungen einer Software ein.

2.3 Vorgehensmodelle

Seit den Anfängen des Software Engineerings gibt es verschiedenste Modelle, um Software zu entwickeln. In ihren Grundzügen enthalten sie alle eine allgemeine Anforderung an die Software, die sich aus dem Geschäftsprozess ableitet, den sie unterstützen soll. Dafür ist es nötig, den Geschäftsprozess zu analysieren und in geeigneten Abstraktionsebenen zu dokumentieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Softwareentwicklungsmodelle

Aus diesen Dokumenten werden die informationstechnischen Unterstützungsmöglichkeiten kristallisiert, die mit der Software abgebildet werden sollen.

Da es bei der Geschäftsprozessanalyse sowie bei den nachfolgenden Schritten immer wieder zu Fehlinterpretationen und Fehlentscheidungen kommen kann, sind Modelle entwickelt worden, die diese Arbeit methodisch und konzeptionell unterstützen sollen.

Die Entwicklungsmodelle lassen sich in zwei große Gruppen einteilen, die klassischen Entwicklungsprozesse und die agile Softwareentwicklung (Abbildung 1).

2.3.1 Klassische Vorgehensmodelle

Bei den klassischen Modellen wird versucht, die Entwicklung möglichst nah an der allgemeinen Ingenieursdisziplin zu halten. Als Argumentationsgrundlage dient eine von Barry Boehm in den siebziger Jahren durchgeführte Studie die belegt, dass die Kosten von Änderungen an Softwaresystemen exponentiell mit der Zeit wachsen, die bis zum Erkennen des Problems vergeht. Alle agilen Versuche, die im Jahre 1981 untersucht wurden, produzierten doppelt bis dreimal so hohe Nachbearbeitungskosten sowie einen Spagetticode, der nur schwer wartbar war.¹³ Um dem vorzubeugen wird versucht, in der Analyse und Designphase alle erstellten Dokumente möglichst detailliert zu halten, damit Fehler nicht auftreten können. Eine Erweiterung des klassischen Weges sind die iterativen Modelle, dabei wird versucht, in regelmäßigen Abständen eine lauffähige Software zu erstellen, die einen Teil der Anforderungen erfüllt und eine Überprüfung der Entwicklungsgangart ermöglicht (siehe Abbildung 2).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Klassische und iterative Entwicklung

2.3.1.1 Das Wasserfallmodell

Zu den wohl bekanntesten und ältesten Modellen der Softwareentwicklung gehört das von Winston Royce 1970 entwickelte Wasserfallmodell, das in den amerikanischen DOD-STD-2167 einfloss.¹⁴ Dieses Modell kann durch seine phasenorientierte Herangehensweise als Grundlage aller Vorgangsmodelle gesehen werden. Dabei sind fünf klassische Phasen aufgezeigt, die linear abgearbeitet werden (siehe Abbildung 3):¹⁵

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Wasserfallmodell

1. Spezifikation

Ausgehend von einer Ist-Analyse wird ein Anforderungskatalog mit allen notwendigen Funktionen erstellt (Lastenheft), der als Basis für einen Vertrag mit einer gewählten Softwareentwicklungsfirma (oder internen Abteilung) besteht.

2. Entwurf

In der Entwurfsphase entsteht das Pflichtenheft beim Softwareentwickler. Es werden Angaben über den System- und Softwareentwurf gemacht und vom Auftraggeber überprüft und unterzeichnet.

3. Programmierung

In dieser Phase werden die Anforderungen aus dem Lastenheft über die definierten Methoden des Pflichtenheftes in ein Softwaresystem implementiert.

4. Test

Nach der Implementierung werden alle Softwaremodule getestet, um so wenig wie möglich Implementierungsfehler im System zu haben.

5. Integration / Wartung

Der letzte Schritt ist die Integration, der Betrieb und die Wartung der Software beim Auftraggeber.

In modernen Versionen des Wasserfallmodells können die einzelnen Phasen ihrer jeweils vorgelagerten Phase Rückmeldungen geben und notfalls in einer Schleife wiederholt werden.

[...]

---

¹ [Per68], S. 78.

² Vgl. [Pom04], S. 3.

³ Vgl. [Bau69], S. 79.

⁴ Vgl. [Pom04], S. 4.

⁵ Vgl. [Pom04], S. 4f.

⁶ Weitere Informationen und Veranstaltungshinweise unter: http://www.rapidprototyping.fraunhofer.de

⁷ Vgl. [Sta05], S. 219f.

⁸ Vgl. [Sta05], S. 219f.

⁹ Vgl. [DIN], 55350.

¹⁰ Vgl. [Buh04], S. 136f.

¹¹ Vgl. [Man04], S. 16.

¹² Vgl. [Frü07], S. 22f.

¹³ Vgl. [Boe81], S. 3 ff.

¹⁴ Vgl. [Act07], S.19.

¹⁵ Vgl. [Act07], S.19f. sowie [Pom04], S. 11f. (Phasenmodell).