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.
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
Zielsetzung & Themen
Das Hauptziel dieser Arbeit ist es zu untersuchen, inwieweit die Unified Modeling Language (UML) als grafische Sprache und einheitliches Denkmodell für den Informationsaustausch in Software-Entwicklungsprojekten fungieren kann, um die zentralen Herausforderungen des Requirements Engineering zu bewältigen. Im Fokus steht dabei die Anwendung objektorientierter Analysemethoden (OOA) zur präzisen Anforderungsmodellierung.
- Grundlagen des Requirements Engineering und kritische Erfolgsfaktoren.
- Vergleich von funktionsorientierten Methoden (SA/RT) mit objektorientierten Konzepten.
- Historische Entwicklung und Grundlagen der Unified Modeling Language.
- Detaillierte Analyse von UML-Diagrammtypen (Use-Case, Aktivitäts- und Klassendiagramm).
- Praktische Umsetzung und Bewertung von Modellierungstechniken am Beispiel eines Online-Shops.
Auszug aus dem Buch
1.1 Problemstellung
Durch den ständig wachsenden internationalen Konkurrenzdruck und zunehmen der 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.
Zusammenfassung der Kapitel
1 Einführende Darstellung: Erläutert die Problematik in Software-Entwicklungsprojekten, insbesondere das Scheitern aufgrund ungenauer Anforderungen, und definiert das Ziel, die UML als Lösungsansatz zu untersuchen.
2 Grundlagen und Probleme der Software – Entwicklung: Beschreibt die Komplexität und die zentrale Rolle der Software sowie die vier wesentlichen Faktoren, die zu finanziellen Risiken und Terminproblemen führen.
3 Requirements Engineering: Definiert den Begriff des Requirements Engineering, skizziert dessen Historie und strukturiert die Hauptaufgaben in strategische und operative Ebenen.
4 Modellierung der fachlichen Lösung: Gegenüberstellung von funktionsorientierten Analyseansätzen (SA/RT) und den objektorientierten Konzepten, wobei letztere für eine stabilere Architektur hervorgehoben werden.
5 Unified Modeling Language: Bietet einen historischen Abriss zur Entstehung der UML und erläutert ihren Nutzen als Standardsprache für Modellierung und Spezifikation.
6 Modell- und Diagrammarten der UML: Detaillierte theoretische und praktische Analyse der wichtigsten UML-Diagrammtypen (Use-Case, Aktivitäts- und Klassendiagramm) zur Anforderungsvisualisierung.
7 Fazit und Ausblick: Resümiert den Nutzen der UML zur Reduzierung von Fehlern durch ein einheitliches Denkmodell und betont die Notwendigkeit, das Requirements Engineering stärker in der Praxis zu verankern.
Schlüsselwörter
Requirements Engineering, Software-Entwicklung, UML, Unified Modeling Language, OOA, Objektorientierte Analyse, Anforderungsmodellierung, Use-Case-Diagramm, Aktivitätsdiagramm, Klassendiagramm, Softwarekrise, Systemanalyse, Softwarequalität, Modellierung, Projektmanagement.
Häufig gestellte Fragen
Worum geht es in dieser Arbeit grundsätzlich?
Die Diplomarbeit untersucht die Rolle des Requirements Engineering als kritischen Erfolgsfaktor in der Software-Entwicklung und analysiert, wie die Unified Modeling Language (UML) zur Verbesserung der Anforderungsdefinition eingesetzt werden kann.
Was sind die zentralen Themenfelder?
Zu den Schwerpunkten gehören das Verständnis von Anforderungsarten, die methodische Modellierung der fachlichen Lösung sowie die Anwendung von UML-Diagrammen als standardisiertes Kommunikationswerkzeug zwischen Projektbeteiligten.
Was ist das primäre Ziel oder die Forschungsfrage?
Das Ziel ist zu prüfen, ob die UML ein einheitliches Denkmodell bieten kann, das durch grafische Spezifikation die typischen Mängel und Mehrdeutigkeiten in der Anforderungsphase von Softwareprojekten reduziert.
Welche wissenschaftliche Methode wird verwendet?
Die Arbeit basiert auf einer theoretischen Literaturanalyse und wird durch praktische Anwendungsbeispiele (Modellierung eines fiktiven Online-Shops) mittels des CASE-Tools Rational Rose veranschaulicht.
Was wird im Hauptteil behandelt?
Im Hauptteil werden zunächst die Probleme der Software-Entwicklung beleuchtet, anschließend die Grundlagen des Requirements Engineering definiert und schließlich die UML-Diagrammtypen (Use-Case, Aktivität, Klasse) detailliert vorgestellt und bewertet.
Welche Schlüsselwörter charakterisieren die Arbeit?
Die Arbeit ist zentral durch Begriffe wie Requirements Engineering, Unified Modeling Language (UML), Objektorientierte Analyse (OOA), Anforderungsmodellierung und Software-Architektur geprägt.
Warum ist das "Use-Case-Diagramm" für die Kommunikation wichtig?
Es dient als "High-Level-Sicht", die es ermöglicht, Systemanforderungen aus Benutzersicht intuitiv zu beschreiben, ohne dass die beteiligten Fachbereiche tiefgehende Kenntnisse der UML besitzen müssen.
Welchen Vorteil bietet die Modellierung mit "Klassendiagrammen"?
Klassendiagramme bilden die statische Struktur ab und ermöglichen eine direkte Überleitung zur Implementierung, da sie als Vorlage für Code-Skelette in objektorientierten Programmiersprachen genutzt werden können.
- Quote paper
- Thomas Panothiokas (Author), 2006, Requirements Engineering mit der UML als wesentlicher Erfolgsfaktor in der Software-Entwicklung, Munich, GRIN Verlag, https://www.grin.com/document/62857
