Requirements Engineering mit der UML als wesentlicher Erfolgsfaktor in der Software-Entwicklung

Inhaltsverzeichnis

1 Einführende Darstellung
1.1 Problemstellung
1.2 Ziel und Schwerpunkt
1.3 Aufbau
1.4 Zeitplan

2 Grundlagen und Probleme der Software – Entwicklung

3 Requirements Engineering
3.1 Definition
3.2 Historie
3.3 Hauptaufgaben
3.4 Anforderungsermittlung
3.5 Techniken zur Ermittlung von Anforderungen

4 Modellierung der fachlichen Lösung
4.1 Grundlagen
4.2 Strukturierte Analyse
4.3 Real-Time Analyse
4.4 Bewertung funktionsorientierter Methoden
4.5 Objektorientierte Konzepte
4.6 Objektorientierte Analyse

5 Unified Modeling Language
5.1 Historische Entwicklung der UML
5.2 Grundlagen der UML
5.3 UML-Tools

6 Modell- und Diagrammarten der UML
6.1 Grundlagen
6.2 Use-Case-Diagramm
6.2.1 Notation
6.2.2 Beziehungen
6.2.3 Praxisbeispiel
6.2.4 Bewertung
6.3 Aktivitätsdiagramm
6.3.1 Aktivität
6.3.2 Objekt
6.3.3 Beziehung
6.3.4 Praxisbeispiel
6.3.5 Bewertung
6.4 Klassendiagramm
6.4.1 Klasse
6.4.2 Abstrakte Klassen
6.4.3 Attribut
6.4.4 Operation
6.4.5 Beziehung
6.4.6 Multiplizität
6.4.7 Sichtbarkeit
6.4.8 Praxisbeispiel
6.4.9 Bewertung

7 Fazit und Ausblick

Anhangsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

Literaturverzeichnis

Erklärung

1 Einführende Darstellung

1.1 Problemstellung

Durch den ständig wachsenden internationalen Konkurrenzdruck und zunehmender Komplexität der zu entwickelnden Produkte, Dienstleistungen und Systeme sind Unternehmen gezwungen, immer kürzer werdende Entwicklungszeiten zu realisieren, um Marktanteile zu gewinnen, zu sichern und auszubauen.

Desto verwunderlicher ist es, dass in Wirtschaft und Verwaltung die Liste der Software-Entwicklungsprojekte, die entweder ganz aufgeben bzw. erst mit erheblicher Verspätung sowie enormer Überziehung des geplanten Budgets eingeführt werden können, immer länger wird. Nach Einführung der Software stellt der Auftraggeber ebenso verwundert fest, dass seine eigentlichen Anforderungen (Requirements) an die Software entweder nur zum Teil bzw. an der fachlichen Problemstellung vorbei programmiert wurden.

Aus eigener beruflicher Erfahrung kann der Autor bestätigen, dass diese Probleme fehlender bzw. an der Problemstellung vorbei entwickelter Funktionalitäten, auf nicht vorhandene bzw. ungenaue und kurz vor der Einführung erkannte Anforderungen basieren.

Nach einer Untersuchung der Standish Group aus dem Jahre 2004 werden durchschnittlich gerade mal 54% der ursprünglich definierten Funktionen eines Software-Projektes ausgeliefert. Von diesen 54% wiederum werden noch nicht mal die Hälfte (45%) von den Anwendern entweder gar nicht oder nur zum Teil genutzt.

Bei den wesentlichen Erfolgsfaktoren eines Software-Enwicklungsprojektes spielen mittlerweile die verwendeten Methoden und Tools (Datenstrukturen, verwendete Programmiersprache) in den Phasen Entwurf und Implementierung eine vergleichsweise geringe Rolle. Bereits in den 60er Jahren wurde von IBM, Control Data und anderen Unternehmen der für die Kodierung und Fehlerbereinigung notwendige Aufwand empirisch auf 1/6 festgelegt.

Die schwerwiegenden Fehler die heute in der Software-Entwicklung gemacht werden, sind semantischer anstatt syntaktischer Natur. Diese Fehler werden bereits am Anfang der Software-Entwicklung in der Phase „Analyse und Definition“ in Form von schlechten, instabilen und unvollständigen Anforderungen gemacht und ziehen sich durch das gesamte Phasenmodell der Software-Entwicklung (siehe hierzu Abbildung 1). Sie sind die Hauptursache warum Software-Entwicklungsprojekte mit erheblicher Verspätung, enormer Überziehung des geplanten Budgets sowie mit einer verminderten Qualität der erstellten Software abgeschlossen werden.

Abbildung 1: Klassisches Phasenmodell der Software-Entwicklung

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Partsch, H., Requirements Engineering systematisch, Heidelberg, Berlin 1998, S. 2

Die beteiligten Personen und Bereiche: Auftraggeber, Stakeholder, Projektleiter, Fachbereiche, Systemanalytiker, Systemarchitekten, Software-Designer, Programmierer und letztendlich die Anwender sprechen nicht die gleiche Sprache. Wie in Abbildung 2 auf folgenden Seite dargestellt, ergeben sich auf Grund der natürlichen Sprache zwangsläufig Mißverständnisse, da eine unbegrenzte Sprachmenge Mehrdeutigkeiten enthält und somit eine formale Prüfung nur begrenzt zuläßt.

Unterschiedlichste Aussagen können eigentlich einen gleichen Sachverhalt oder eine gleiche Aussage unterschiedliche Sachverhalte meinen. Vor diesem Hintergrund ist das Requirements Engineering immer noch eine der schwierigsten Aufgaben bei der Entwicklung von Software und somit ein wesentlicher Faktor über Erfolg oder Mißerfolg eines Software-Entwicklungsprojektes.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Warum Requirements Engineering?

Quelle: Schienmann, B., Kontinuierliches Anforderungsmanagement, München 2002, S. 13

1.2 Ziel und Schwerpunkt

Ziel dieser Arbeit ist es, zu untersuchen inwieweit die UML (Unified Modeling Language) zur Beschreibung von Anforderungen ein einheitliches Denkmodell bzw. gemeinsame graphische Sprache und eine Grundlage für den Informationsaustausch zwischen allen Beteiligten bei der Entwicklung von Software und damit als möglicher Lösungsansatz für die beschriebenen Hauptprobleme innerhalb des Requirements Engineering dienen kann. Dabei liegt der Schwerpunkt in der Untersuchung der OOA (Objektorientierten Analyse) zur Modellierung von Anforderungen. Hierzu werden ausgewählte UML-Modellelemente untersucht, bewertet und anhand praktischer Beispiele vorgestellt.

1.3 Aufbau

Die Arbeit besteht aus insgesamt sieben Kapiteln. Im nachfolgenden Kapitel werden die Grundlagen der Software-Entwicklung kurz vorgestellt. Das dritte Kapitel gibt eine Übersicht über die historische Entwicklung des Requirements Engineering, definiert den Begriff und stellt die Hauptaufgaben innerhalb der Ermittlung von Anforderungen vor.

Die Modellierung der fachlichen Lösung der ermittelten Anforderungen wird im vierten Kapitel theoretisch behandelt. Dabei liegt der Schwerpunkt in den objektorientierten Konzepten der Modellierung mit der OOA. Das fünfte Kapitel behandelt die Grundlagen und Tools der UML und stellt in Verbindung mit der OOA einen kurzen historischen Abriß der Entwicklung vor.

Im Hinblick auf die Zielsetzung der Arbeit werden im sechsten Kapitel als Lösungsansatz ausgewählte Modell- und Diagrammtypen der UML, die für die Visualisierung von Anforderungen besonders geeignet sind, sowohl theoretisch als auch anhand eines aufbauenden praktischen Beispieles vorgestellt und bewertet. Das letzte und siebte Kapitel zieht ein Fazit aus den gewonnenen Erkenntnissen und gibt einen Ausblick.

1.4 Zeitplan

Abbildung in dieser Leseprobe nicht enthalten

2 Grundlagen und Probleme der Software – Entwicklung

Software ist in den vergangenen Jahrzehnten in der Wirtschaft zu einem unablässigen zentralen Wettbewerbsfaktor geworden. Die Software-Entwicklung umfaßt alle Tätigkeiten und Ressourcen, die zur Herstellung von Software notwendig sind. Dazu gehört die Umsetzung der Bedürfnisse von Benutzern in Software und umfaßt die Spezifikation der Anforderungen, Konzept der Lösung, Entwurf und Programmierung der Komponenten, Zusammensetzung der Komponenten und ihre Einbindung in vorhandene Software, Inbetriebnahme der Software und die Prüfung der entwickelten Komponenten nach jedem Schritt bzw. Phase.^[1]

Im Wesentlichen sind vier Faktoren für die Problematik und die Komplexität bei der Entwicklung von Software ausschlaggebend:

1. Je größer und komplexer das zu lösende Problem ist, desto aufwendiger und schwieriger ist der Entwicklungsprozess für die Erstellung der benötigten Software.
2. Die Immaterialität des Ergebnisses macht die Entwicklung schwieriger und komplexer als die Entwicklung eines materiellen technischen Produktes vergleichbarer Komplexität. Somit sind die Risiken schwieriger zu erkennen und ad hoc Vorgehensweisen führen schnell in ein finanzielles Desaster.
3. Auf Grund der Evolution bei der Entwicklung von Software können sich Zielsetzungen innerhalb des Software-Entwicklungsprozesses permanent verändern.
4. Die Software-Entwicklung wird auf Grund der Immaterialität des produzierten Ergebnisses unbewußt emotional in der Regel viel einfacher eingeschätzt, als sie tatsächlich ist. Dies führt zu unrealistischen Erwartungen und Fehleinschätzungen in derKosten- und Terminplanung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Fehler in der Aufwandsschätzung in Abhängigkeit zur Komplexität der Software

Quelle: eigene Darstellung

Vor dem Hintergrund der vier o.g Faktoren zeigt die Abbildung 3 häufige Fehler in der Aufwandsschätzung in Abhängigkeit zur Komplexität der zu entwickelnden Software. Hauptgrund für die Diskrepanz zwischen geschätzten und tatsächlichen Aufwand ist wie bereits aufgeführt die Immaterialität des produzierten Ergebnisses im Zusammenhang mit der Komplexität und den damit verbundenen Problem einer unmißverständlichen Anforderungsdefinition.

Diese Aspekte der Immaterialität und Komplexität des produzierten Ergebnisses in Form von Software erschweren die Definition von unmißverständlichen Anforderungen. Fehlerhafte Anforderungsdefinitionen sind die häufigste Ursache für Defizite und Defekte in Softwareprodukten. Die Behebung dieser Fehler verursacht mit Abstand weit mehr Kosten als die Behebung von Fehlern in der eigentlichen Programmierung oder bei einer fehlerhaften Auswahl von Hardwarekomponenten, da ihre Korrektur Folgekosten in den späteren Entwicklungsphasen verursachen. Darüber hinaus können diese Fehler auch Auswirkungen auf bereits getroffene Entscheidungen haben, wo wiederum weitere Folgekosten entstehen können. Desto früher solche Fehler entdeckt und behoben werden, desto kostengünstiger ist der weitere Entwicklungsprozess. Die Abbildung 4 auf der folgenden Seite zeigt, dass die relativen Kosten für die Korrektur von Fehlern in den Anforderungen in den frühen Phasen der Software-Entwicklung weitaus geringer sind und mit jeder weiteren Phase exponentiell ansteigen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Relative Kosten für die Korrektur von Anforderungen

Quelle: eigene Darstellung in Anlehnung an: Davis, A. M., Software Requirements: Objects, Functions and States, Englewood Cliffs 1993

Die Entdeckung und Behebung eines Fehler in der Phase der Implementierung verursacht das zwanzigfache an Kosten gegenüber einer Korrektur in den frühen Phasen der Definition oder des Entwurfes.^[2]

In den frühen Zeiten der Software-Entwicklung waren die bestehenden Probleme eher einfacher Natur und schnell zu lösen, da die zu entwickelnde Software aus einzelnen weitgehend voneinander unabhängigen Programmen bestand, die jedes für sich eine überschaubare Größe hatten. Die Schwierigkeiten der Software-Entwicklung manifestierten sich erst in den 60er Jahren, als immer umfangreichere Software entwickelt wurde und die bis dahin verwendeten ad hoc Vorgehensweisen zunehmend versagten.

Dieses Versagen führte zu folgenden zwei grundsätzlichen Fragestellungen: „In welcher Reihenfolge sind welche Aktivitäten auszuführen?“ und „Wer soll welche Aktivitäten wann ausführen?“.^[3] Bezüglich der zweiten Fragestellung, beschäftigt sich das Projektmanagement hauptsächlich mit der Planung und dem Controlling dieser Aktivitäten. Zur ersten Fragestellung wurde aus o.g. Problemen in den 60er Jahre von den Bell Laboratories das Konzept des System Engineering als eine Methode zur Strukturierung der Reihenfolge und der Ausführung der Aktivitäten entwickelt.

Dabei werden folgende vier Grundphasen unterschieden: Systemanalyse, Systementwicklung, Systemeinführung und Systempflege. Ausgehend von dieser Einteilung sind in der Zwischenzeit eine Fülle von Abwandlungen in Form von Phasenkonzepten entwickelt worden, die unter dem Begriff „Vorgehensmodell“ Einzug in die Software Entwicklung gefunden haben. Der größte Teil dieser heutigen Vorgehensmodelle basiert auf den o.g. Grundphasen, die wie folgt bezeichnet werden: Analyse, Entwurf, Realisierung und Einführung. Die Erweiterung um die Phasen „Planung“ und „Wartung und Pflege“ vervollständigt das aktuelle heute in der Praxis verbreitetste Phasenmodell:^[4]

- Planung
- Definition
- Entwurf
- Implementierung
- Abnahme und Einführung
- Wartung und Pflege

Die zweite Phase „Definition“ hat als Hauptaufgaben zu beschreiben, was die Software leisten soll, also die umfassende Analyse und Modellierung der fachlichen Lösung. Die darauffolgende Phase „Entwurf“ gibt vor, wie die Software umgesetzt werden soll, also die softwaretechnische Lösung der Architektur zu entwerfen.

Dabei sind diese zwei Phasen in der Praxis nicht immer klar voneinander abzugrenzen und überschneiden sich, da der Prozess der Analyse bzw. Definition im Wechselspiel mit der Systemmodellierung bzw. Entwurf steht.^[5] In der Definitionsphase werden die qualitativen und quantitativen Merkmale einer Software aus Sicht des Auftraggebers festgelegt. Somit bilden diese Requirements die Grundlage für die Modellierung der fachlichen Lösung. Die systematische Ermittlung dieser Requirements, in einem iterativen Prozess, wird als Requirements Engineering bezeichnet.

3 Requirements Engineering

Dieses Kapitel definiert den Begriff „Requirements Engineering“, gibt eine Übersicht über die historische Entwicklung und stellt die Hauptaufgaben innerhalb der Ermittlung von Anforderungen vor.

3.1 Definition

Bevor auf eine Definition von Requirements Engineering eingegangen werden kann, muß der Begriff „Requirements“ geklärt werden. In dieser Arbeit wird der Begriff Requirement und Anforderung synonym verwendet. Ein Requirement ist ein „fachliches oder technisches Leistungsmerkmal, welche die zu entwickelnde Anwendung aufweisen soll“.^[6] Eine etwas erweiterte Sicht unter Einbeziehung der Prozesse als auch der am Prozess beteiligten Personen findet sich in Chris Rupps Definition: „Eine Anforderung ist eine Aussage über eine zu erfüllende Eigenschaft oder zu erbringende Leistung eines Produktes, eines Prozesses oder der am Prozess beteiligten Personen“. ^[7]

Auf dieser Grundlage werden nicht nur Anforderungen, die an das Produkt gestellt werden, berücksichtigt, sondern auch Anforderungen des Auftraggebers, die an den eigentlichen Entwicklungsprozess bzw. Vorgehensmodell gestellt werden. Durch diese erweiterte Anforderungssicht, werden mehrere Klassen von Anforderungen unterschieden:^[8]

1. Funktionale Anforderungen: „Was soll das System leisten? Welche Daten sollen verarbeitet, welche Dienste bereitgestellt und welche Abläufe unterstützt werden.“
2. Nichtfunktionale Anforderungen: „In welcher Qualität sollen diese Leistungen bereitgestellt werden? Wie ausfallsicher oder perfomant soll die Anwendung sein?“
3. Rahmenbedingungen: „Welchen Restriktionen soll die Lösung genügen? Gibt es rechtliche oder organisatorische Einschränkungen, die betrachtet werden müssen?“
4. Entwicklungs- und Produktionsanforderungen: „Welche Anforderungen soll die Entwicklung und Produktion genügen? Gibt es beispielsweise besondere Anforderungen an die Wartung des Produktes?“

Die Begriffe Requirements Engineering und Requirements Management variieren von Autor zu Autor in der Literatur und werden nicht einheitlich verwendet. So verwenden einige Autoren den Begriff Requirements Management als Oberbegriff für alle Aktivitäten zur Ermittlung, Spezifikation als auch Steuerung und Administration von Anforderungen. Andere wiederum verwenden den Begriff Requirements Engineering als Oberbegriff und subsumieren die Systemanalyse als auch die Managementaufgaben rund um das Thema Anforderungen. Folgende Definition im Sinne einer Anforderungsanalyse verwenden Hansen und Neumann: „Unter Requirements Engineering versteht man die möglichst vollständige Gewinnung und Aufzeichnung der Anforderungen an ein zu erstellendes System. Als Resultat dieser Tätigkeit wird die Anforderungsspezifikation erstellt“.^[9] Helmut Balzert verwendet folgende erweiterte Definition für den Begriff Requirements Engineering: „Die systematische Ermittlung, Beschreibung, Modellierung und Analyse der Anforderungen unter Einsatz geeigneter Methoden und Werkzeuge bezeichnet man als Systemanalyse (requirements engineering)“.^[10]

Dabei werden innerhalb der Systemanalyse folgende Aktivitäten ausgeführt:

- Anforderungen ermitteln und beschreiben
- Anforderungen als fachliche Lösung modellieren
- Anforderungen analysieren
- Anforderungen animieren, simulieren und ausführen
- Anforderungen verabschieden

Boehm beschreibt das Requirements Engineering als eine Disziplin zur systematischen Entwicklung zur Ermittlung von Anforderungen die vollständig, konsistent und eindeutig spezifiziert werden müssen. Dabei wird beschrieben was eine Software tun soll, aber nicht wie sie es tun soll. Diese Beschreibung bzw. Spezifikation stellt die Grundlage für eine Vereinbarung zwischen den beteiligten Personen dar. Im Hinblick auf eine wesentliche Verbesserung der Softwarequalität als auch der rechtzeitigen Fertigstellungen der zu entwickelnden Software versucht das Requirements Engineering geeignete Methoden, Beschreibungsmittel und Werkzeuge für die Validation und Überprüfung von Spezifikationen zu finden.^[11] Nach Chris Rupp hat das Requirements Engineering zum Ziel möglichst „qualitativ gute Anforderungen“ zu ermitteln, wohingegen sich das Requirements Management mit der Verwaltung inkl. der Verfolgbarkeit und Nachvollziehbarkeit von Anforderungen beschäftigt^[12].

Den gleichen Ansatz verfolgt auch Bernhard Deifel in seiner Dissertation „Requirements Engineering komplexer Standardsoftware“.^[13] Neben der Ermittlung und Beschreibung von Anforderungen an ein zu erstellendes System, im Sinne des Requirements Engineering, müssen diese Anforderungen konsistent und lückenlos in der letztendlichen Realisierung durch alle Phasen der Software-Entwicklung nachvollziehbar sein. Gerade bei Änderungen von Anforderungen müssen die Auswirkungen auf alle anderen Phasen der Entwicklung einfach zu ermitteln sein. Dabei beschreibt Deifel im Sinne einer Verfolgbarkeit von Anforderungen, das Requirements Engineering als horizontale Sicht das sich mit der Evolution von Dokumenten und das Requirements Management mit der vertikalen Sicht das sich mit der Nachvollziehbarkeit der Übergängen der einzelnen Phasen beschäftigt.

In dieser Arbeit wird das Requirements Engineering im Sinne von Balzert als eine systematische Ermittlung, Beschreibung sowie der Analyse und Modellierung der Anforderungen verstanden und verwendet.

3.2 Historie

Requirements Engineering ist eine Teildisziplin der Software-Entwicklung, die erst Ende der 70er Jahre aus dem Prozess der Software-Entwicklung ausgegliedert wurde und seit dem unter eigenem Namen fungiert. Grund dieser Ausgliederung war die damals herrschende Softwarekrise.^[14] Es wurde festgestellt, dass das Wichtigste bei der Herstellung von Software zu Teilen nicht berücksichtigt wurde und zwar die wesentliche Frage: „was ist die eigentliche Problemstellung des Kunden?“. Während der gesamten Zeit wurde versucht durch Techniken aus dem Gebiet der Informatik als auch eigens dafür erfundene Techniken einzusetzen um den Requirements Engineering Prozess zu vereinfachen.

[...]

^[1] vgl. DeMarco, T.; Lister, T., Wien wartet auf Dich - Der Faktor Mensch im DV-Management, München, Wien 1991, S. 14

^[2] Davis, A. M., Software Requirements, Englewood Cliffs 1993, S. 25

^[3] vgl. Stahlknecht, P.; Hasenkamp U., Einführung in die Wirtschaftsinformatik, Berlin 2002, S. 213

^[4] vgl. Balzert, H., Lehrbuch der Software - Technik, Heidelberg, Berlin 2000, S.51

^[5] vgl. Meseberg, U., Mit Modellen zu stabilen Anforderungen, in: IT Fokus, 09/10 (2005), S. 17

^[6] IEEE Std 610.12-1991: Standard Glossary of Software Engineering Terminology. IEEE 1991 zitiert in: Schienmann, B., Kontinuierliches Anforderungsmanagement, München 2002, S. 31

^[7] Rupp, C., Requirements-Engineering und –Management, München, Wien 2002, S. 159

^[8] vgl. Schienmann, B., Kontinuierliches Anforderungsmanagement, München 2002, S. 50

^[9] Hansen, H. R.; Neumann, G., Wirtschaftsinformatik I, Stuttgart 2002, S. 247

^[10] Balzert, H., Lehrbuch der Software - Technik, Heidelberg, Berlin 2000, S. 118

^[11] vgl. Boehm, B. W.,: Guidelines for Verifying and Validating Software Requirements and Design Specification, In: Proceedings of Euro IFIP 1979, S. 711-719

^[12] vgl. Rupp, C., Requirements-Engineering und –Management, München, Wien 2002, S. 423

^[13] vgl. Deifel, B., Requirements Engineering komplexer Standardsoftware, TU-München 2002, S. 10

^[14] vgl. o. V., Schülerduden Informatik, Mannheim, Leipzig, 2003, S. 463