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

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 9126

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]

1 Einleitung

Das Projektmanagement ist in Unternehmen eine wichtige Aufgabe, um Neuerungen einzuführen und im Wettbewerb mit anderen Unternehmen am Markt zu bestehen. Durch ihre Natur sind Projekte eine zeitlich begrenzte und interdisziplinäre Aufgabe, die sehr viele Ressourcen verbraucht und herausragende soziale Fähigkeiten aller Beteiligten fordert. Nicht ohne Grund scheitern 35 % aller Softwareprojekte an einem dieser Punkte oder 75 % erfahren einen größeren Ressourcen- und Zeitverbrauch als kalkuliert.^[2]

Das hierbei untersuchte Projekt hatte massive Kostenüberschreitungen sowie Terminverschiebungen, 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 Empfehlungen 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 machines“ (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 FORTRAN-Programmen 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 un-dokumentiert hinzugefügt, ein Erlernen des Systems ist daher nur über lange Ein-arbeitungszeiten 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.^[3]

Der Begriff Software Engineering soll ausdrücken, dass für eine Softwareentwicklung nicht nur Programmierkenntnisse von Nöten sind, sondern auch allgemeines Ingenieurwissen und Projektmanagementqualitäten eine wichtige Rolle spielen.^[4]

Die Komponenten des Engineerings lassen sich ein drei Sichtweisen unterteilen:

Prozessorientiert, in die Organisation von Software-Projekten, dazu gehören ver-schiedenste 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:^[5]

- 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).^[6]

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).^[7]

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.^[8]

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.^[9]

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.^[10]

2.2.1 Die Qualitätsschaffung

An jeder Softwareentwicklung sind verschiedene Personen beteiligt, die unter-schiedlichste 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.^[11]

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).^[12]

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 eingeordnet (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.^[13] 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

Abbildung 2: Klassische und iterative Entwicklung

Abbildung in dieser Leseprobe nicht enthalten

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.^[14] 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):^[15]

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.

2.3.1.2 Das Spiralmodell

Eins der ersten theoretischen Modelle, das Iterationen vorsieht, ist das im Jahre 1988 von Barry Boehm entwickelte Spiralmodell.^[16]

Das Spiralmodell besteht aus einem explorativen Prototyping und Iterationen, die Entwicklung wird in Teilziele heruntergebrochen und wie eine Spirale immer wieder neu durchlaufen, um das Projektrisiko zu minimieren.^[17]

In vier Spiralphasen wird dabei die jeweilige erfolgversprechendste Lösungsvariante risikominimiert entwickelt, validiert und darauf aufbauend, die Planung für die nächste Stufe erstellt.

Das Besondere an dem Spiralmodell ist darüber hinaus, dass Komponenten der Software über unterschiedlichste Modelle stattfinden (das Spiralmodell selbst gilt als Metamodell) können, die von den Phasen des Spiralmodells ummantelt werden.^[18]

2.3.1.3 Vorgehensmodell (XT)

Das Vorgehens-Modell (V-Modell) ist im Februar 1991 im Auftrag der Bundeswehr entwickelt worden. Die ursprüngliche Version wurde dann im Juni 1997 zu einem neuen V’97 Modell weiterentwickelt, das auch rudimentär die iterative und objektorientierte Herangehensweise zulässt. In der aktuellen Version, die nun ein Open-Source Projekt ist, wird das V-Modell um ein „Extreme Tailoring (XT)“ erweitert. Alle Versionen des V-Modells werden von der Bundeswehr, als auch in zivilen Behörden in Deutschland eingesetzt.^[19]

Zum V-Modell gehört eine umfassende Handbuchsammlung, die Entwicklungs- und Methodenstandards sowie Werkzeuganforderungen enthält, um standardisiert zu regeln, wer welche Aufgaben womit erledigt.^[20]

Das Modell setzt sich aus vier Submodellen zusammen, deren Produkte (AG/AN Schnittstellen) die anderen Submodelle an definierten Schnittstellen entgegennehmen (siehe Abbildung 4):^[21]

1) SE: System- / Softwareerstellung
2) QS: Qualitätssicherung
3) PM: Projektmanagement
4) KM: Konfigurationsmanagement

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: V-Modell Übersicht (Quelle: [KBS06])

Für jedes Submodell wird dabei angegeben, welche Schritte befolgt, welche Methoden genutzt und welche Werkzeuge eingesetzt werden sollen.

Die große Erweiterung im späteren V-XT ist die Möglichkeit der Wahl einer Grundmenge von Vorgehensbausteinen. Durch dieses Tailoring (Anpassen) werden die möglichen von den notwendigen Bausteinen getrennt und der Dokumentenumfang geschmälert.^[22]

Einen Versuch neue, agile Entwicklungsmethoden zu nutzen und dennoch für öffentliche Auftraggeber entwickeln zu können, beschreibt B. Oestereich unter [Oes07], S. 281 f., sehr ausführlich, wobei er sich hierbei auf sein entwickeltes OEP-oose Model bezieht.

2.3.1.4 Rational Unified Process

Das Rational Unified Process (RUP) Modell ist 1998 von der Firma Rational (heute IBM) entwickelt worden.^[23]

RUP ist ein dreiteiliges Phasenmodell, das innerhalb einer Phase Iterationen zulässt und Anwendungsfallbeschreibungen des UML nutzt, um die Anforderungs- und Leistungsmerkmale des Softwaresystems zu bestimmen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Rational Unified Process (Quelle: [Rat04])

Im RUP Modell gibt es (siehe Abbildung 5):^[24]

1) Sechs Entwicklungsschritte (siehe Abbildung 5, vertikale Beschriftung)
2) Drei Unterstützungsprozesse: Konfiguration- und Änderungsmanagement, Implementierung und Umgebungsmanagement

3) Vier Phasen (siehe Abbildung 5, horizontale Beschriftung)
4) Die verschiedenen Entwicklungsschritte und Unterstützungsprozesse stehen in einem engen Zusammenhang, wie in der Abbildung 5 aufgezeigt. Dabei sind die in unterschiedlichen Grautönen horizontal angeordneten Balken ein Maß für den jeweiligen Aufwand in der Phase.

Jede Phase endet mit einem Meilenstein, dazwischen liegen verschiedene Iterationen, deren Anzahl abhängig von der Produktkomplexität ist. Das Iterieren ist beendet, wenn die erforderliche Qualität insgesamt vorliegt und das Softwareprodukt ausgeliefert werden kann.^[25]

2.3.2 Agile Vorgehensmodelle

Mit der objektorientierten Entwicklung neuer Programmiersprachen und der Abbildung von Geschäftsobjekten im Programmcode änderten sich die Herangehensweisen der Entwickler, die nun in der Lage waren, eine hohe Produktivität und leistungsfähige Architektur aufzubauen, die zusätzlich pflegbar war. Der Preis dafür waren neue Entwurfsmuster, die mit weiteren Dokumenten einhergingen und insgesamt die agilen, dokumentationsärmeren Methoden wieder ins Gespräch brachten.^[26]

Die agilen Modelle versuchen, so wenige Dokumente wie nötig zu erstellen und Anforderungen, über einen iterativen Prozess hinaus, in die Software einfließen zu lassen. Dabei können massiv Kosten in der Design- und Analysephase gespart werden und theoretisch ein früheres Roll-out (Softwareeinführung) erreicht werden.

Zur Familie der agilen Softwareentwicklungsmethoden gehörten die Crystal-Methodenfamilie, das adaptive Software Development, Scum und das Lean Development. Stellvertretend für den agilen Ansatz sei das bekannteste Vorgehensmodell, das „extreme Programming“ (XP) von Ken Beck, Ward Cunningham und Ron Jeffries beschrieben.^[27]

Im XP wird die Softwareerstellung in kleine Releases unterteilt, deren Planungszeitraum nicht größer als drei Monate sein sollte und eine bestimmte Funktionalität des Produktes abbildet. In jedem Release gibt es Iterationen, die drei Planwochen nicht überschreiten und definierte Arbeitspakete enthalten, die wiederum in unter drei Manntagen abzuarbeiten sind (evolutionäres Prototyping).

Für jede Iteration wird ein Storyboard erstellt, das in Aufgaben zerlegt werden kann. Zusätzlich entstehen aus der Story Tests, die später die im Arbeitspaket erstellen Klassen testen. Tests sollen eine Klassenbeschreibung unnötig machen.

Jeder erstellte Code wird in Paaren („Paaring“) programmiert. Jeder Entwickler kann jederzeit an jedem Code arbeiten und ein Wissenstransfer zwischen den Entwicklern wird gefördert.

Zusätzlich wird der Code regelmäßig vereinfacht (Refaktorisierung), ohne sein Verhalten in den Tests zu verändern.^[28]

2.3.3 Fazit der Vorgehensmodelle

Zusammenfassend sei herausgestellt, dass, je agiler, also evolutionärer ein Modell bzw. die Entwicklungsmethode einer Software ist, umso höher ist der Aufwand für das Projektmanagement, da die Schnittstellen der Arbeitspakete gut beschriebene und versionierte Dokumente voraussetzen. Darüber hinaus muss eine aktive Kommunikation zwischen den Entwicklern herrschen und die gewonnene Entwicklungsfreiheit der Mitarbeiter mit erhöhter Disziplin bezahlt werden.

Die agile Entwicklung verringert allerdings den Planungsaufwand (siehe Abbildung 1), da weniger Bürokratie in der Entwicklung zu finden ist. Zusätzlich zwingt die regelmäßige Ist-Erfassung, genauere Plandaten zu erstellen, die Budgetverschiebungen genauer erkennen lassen.

Die statischen Modelle haben einen erhöhten Dokumentationsaufwand, da sie jedoch davon ausgehen, dass einmal erstellte Dokumente nicht verändert werden, sind mit ihnen Entwicklungsverteilungen sowie ein Outsourcing der Entwicklung möglich. Dem erhöhten Aufwand in der Dokumentation steht auch eine höhere Normennähe und Nachweisbarkeit zur Seite.

Abbildung in dieser Leseprobe nicht enthalten

^{[29][30][31][32][33][34][35][36][37][38][39][40][41][42][43][44][45]}

Tabelle 1: Gegenüberstellung der Vorgehensmodelle

In Abbildung 1 wird versucht, die Entwicklungsmodelle des Software Engineerings nach dem zu erstellenden Dokumentationsaufwand, der Projektkomplexität und der Projektgröße, für die sich das Modell am besten eignet, gegenüberzustellen. Jedes Modell sollte bei einer Auswahl genauer betrachtet werden, da dies verschiedene Zielgruppen und Besonderheiten besitzt und die Umwelt die avisierte Methodik zulässt (siehe Tabelle 1).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Vergleich von Entwicklungsmodellen

Ein neuer Trend des Software Engineerings ist die Nutzung von UML-Modellen und Metasprachen zur Erstellung von Software. UML-Modelle werden bereits jetzt schon in der Kommunikation zwischen Kunden und Entwickler genutzt, um Problemstellungen, Aktivitäten und Interaktionen graphisch darzustellen, daraufhin folgt jedoch ein Bruch zwischen diesen Modellen und dem Programmcode.

Dieser Bruch soll in der Verbindung mit einer Metasprache und den daraus entstehenden UML-Modellen verhindert werden. Vereint in der Technik des MDA (Modell-Driven Architektur) sollen diese Ansätze darüber hinaus ein Roundtrip-Engineering ermöglichen (die automatische Entwicklung von Programmcodes aus den UML-Diagrammen und zurück).^[46] Da die Disziplin der MDA aber noch sehr stark in der Erprobung ist, sei sie hier nur erwähnt, ohne genauer darauf einzugehen.

2.4 Definition und Methoden des Reengineerings

Eine weitere neuzeitlich immer aktuellere Problematik und wirtschaftliche Chance der Softwareentwicklung ist das Umbilden eines bereits bestehenden Anwendungssystems in eine andere Sprache oder Software. Bedingt durch hohen Kostendruck und die Komplexität jahrzehntelang genutzter Betriebssoftware wird versucht, Module, Fachlogiken oder Softwareteile wiederzuverwerten, um im besten Fall nur die Benutzerführung und die Schnittstellen austauschen zu müssen.

Dabei werden alle vorhandenen Dokumente, Quellcodes und Schnittstellendefinitionen genutzt, um mögliche Wiederverwendungen herauszubilden.

Ein großes Problem bei der Neuentwicklung von Softwaresystemen ist der hohe Unsicherheitsfaktor der Kosten. Bei Schwankungen bis zu 80 % sowie einen dadurch unsicheren „Return of Investment“ (ROI), ist eine Kostenabschätzung auf der Grundlage eines bereits bestehenden Systems leichter zu überschauen.^[47]

Dadurch, dass in der bestehenden Software bereits die Fachlogik, Datenbankmodelle sowie Berechnungsgrundlagen vorhanden sind, kann eine Wiederverwendung eine kostengünstige und risikoarme Alternative zur kompletten Neuentwicklung sein.

Hauptvorteile des Reengineerings sind^[48]:

- die Berechenbarkeit,
- die niedrigen Kosten,
- erhöhte Softwarequalität durch Nutzung erprobter Komponenten,
- die kürzere Projektdauer.

Grundbedingung einer erfolgreichen Wiederverwendung von Systemcodes ist deren objektorientierte Teilung in Klassenbibliotheken, Geschäftsobjekte und Frameworks (siehe Grundlagen des Software Engineerings) sowie eine gute Dokumentation in den Schnittstellen.

Abhängig vom bestehenden System und der Anforderung für das Neusystem gibt es drei Arten des Reengineerings (siehe Abbildung 7).

Abbildung in dieser Leseprobe nicht enthalten

Das Reverse Engineering besteht aus Verfahren, die ermöglichen sollen, die Struktur und das Verhalten des vorhandenen Softwaresystems zu analysieren. Dabei werden vorhandene Dokumentationen durchgegangen und ggf. erweitert. Nicht vorhandene Dokumente werden zusätzlich in den notwendigen Abstraktionsebenen erstellt. Das Reverse Engineering ist daher ein wichtiger Vorläufer der anderen Reengineering Arten.

[...]

---

^[1] [Per68], S. 78.

^[2] Vgl. [Pom04], S. 3.

^[3] Vgl. [Bau69], S. 79.

^[4] Vgl. [Pom04], S. 4.

^[5] Vgl. [Pom04], S. 4f.

^[6] Weitere Informationen und Veranstaltungshinweise unter: http://www.rapidprototyping.fraunhofer.de

^[7] Vgl. [Sta05], S. 219f.

^[8] Vgl. [Sta05], S. 219f.

^[9] Vgl. [DIN], 55350.

^[10] Vgl. [Buh04], S. 136f.

^[11] Vgl. [Man04], S. 16.

^[12] Vgl. [Frü07], S. 22f.

^[13] Vgl. [Boe81], S. 3 ff.

^[14] Vgl. [Act07], S.19.

^[15] Vgl. [Act07], S.19f. sowie [Pom04], S. 11f. (Phasenmodell).

^[16] Vgl. [Boe88], S. 61f.

^[17] Vgl. [Buh04], S. 15.

^[18] Vgl. [Sar03], S. 10.

^[19] Vgl. [KBS06] sowie [Oes07], S. 281.

^[20] Vgl. [Buh04], S. 15.

^[21] Vgl. [Pom04], S. 19 sowie [KBS06].

^[22] Vgl. [Kuh07], S. 134, [KBS06], [Pom04], S. 24 und [Ham07], S. 142f.

^[23] Vgl. [Kru01].

^[24] Vgl. [Pom04], S. 39 sowie [Kru01], S. 4.

^[25] Vgl. [Pom04], S. 40.

^[26] Vgl. [Col03], S. 49ff.

^[27] Zu den anderen Modellen Vgl. [Col03], S. 49 – 54, [Buh04], S. 18 sowie [Bun02], S 46ff.

^[28] Weiter Informationen unter : http://www.xprogramming.com.

^[29] Vgl. [Oes07], S. 281.

^[30] Vgl. [Sar03], S. 19 sowie Software unter http://www-306.ibm.com/software/rational.

^[31] Vgl. [Pom04], S. 16, dagegen nach [Buh04] nur bei kurzen und wenig komplexen Projekten.

^[32] Vgl. [Buh04], S. 15 sowie [Sar03], S. 14.

^[33] Es sollen nur die Artefakte genutzt werden, die einen Wert beisteuern. Vgl. [Buh04], S. 17.

^[34] Vgl. [Pom04], S. 16, der Bezug zum Phasenmodell ist durch die Modellnähe auch anwendbar.

^[35] Vgl. [Kuh07], S. 134, [KBS06], [Pom04], S. 24 und [Ham07], S. 142 f.

^[36] Vgl. [Buh04], S. 17.

^[37] Anforderungsspezifikation während der Entwicklung

^[38] Vgl. [Pom04], S.17.

^[39] Vgl. [Sar03], S. 20.

^[40] Vgl. [Bun02], S.6.

^[41] Vgl. [Sar03],S. 14.

^[42] Vgl. [Sar03], S. 20.

^[43] Vgl. [Pom04], S.17, nach [Oes07], S.15, war es nicht die Absicht von W. Royce das Modell zu propagieren, da auch er das Fehlen der Iterationsschnitte sah.

^[44] Vgl. [Buh04], S. 15.

^[45] Vgl. [Sar03], S. 20.

^[46] Vgl. [Stu03], S.231f. sowie [Obj07].

^[47] Vgl. [Sne03], S 599 zum Thema ROI siehe Kapitel 3.2.1.2.

^[48] Vgl. [Sta05], S. 322 sowie [Sne03], S. 599.