Requirements Engineering

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung und Systematik der Arbeit

2 Anforderungsdefinition in der Softwareentwicklung
2.1 Begriffsdefinition und Grundlagen
2.1.1 Anforderungsdefinition
2.1.2 Unified Modeling Language (UML)
2.1.3 Enterprise Resource Planning (ERP) Software
2.2 Einsatz von UML bei der ERP-Softwareentwicklung
2.2.1 Dokumentation von Anforderungen
2.2.2 Reduzierung der Komplexität
2.2.3 Grenzen beim Einsatz von UML-Werkzeugen
2.2.4 Grundsätzliche Probleme

3 Fallbeispiel: UML im Praxiseinsatz bei der Entwicklung einer ERP-Software
3.1 Kurzporträt der ERP-Software
3.1.1 Einsatzziel der Software
3.1.2 Funktionale Breite und Tiefe der Software
3.1.3 Einschätzung der Komplexität
3.2 Vorgehen bei der Anforderungsdefinition
3.2.1 Hintergrund des Praxisbeispiels
3.2.2 Ermittlung und Formulierung der Anforderungen
3.2.3 Formulierung der Anforderungsdefinition mit Hilfe von UML
3.2.4 Weiteres Vorgehen zur Implementierung
3.3 Abschließende Beurteilung der Vorgehens
3.3.1 Aufgezeigte Probleme
3.3.2 Optimierungsvorschläge

4 Fazit und Ausblick

Literaturverzeichnis

Anhang 1

Anhang 2

Anhang 3

Anhang 4

Anhang 5

Anhang 6

Anhang 7

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Verschiedene Arten der Komplexität (Beispiel)

Abbildung 2: UML-Tools: Verhältnis abgedeckter Funktionalität zu Kosten

Tabellenverzeichnis

Tabelle 1: Praxisbeispiel, Anforderungen im Vergleich

1 Einleitung und Systematik der Arbeit

In dieser Arbeit soll aus dem Bereich des Requirements Engineerings der Einsatz der Unified Modeling Language (UML) bei der Anforderungsdefinition in der Softwareentwicklung betrachtet werden.

Ziel der Arbeit ist, die Möglichkeiten und Grenzen des Einsatzes von UML bei der Anforderungsdefinition in der betrieblichen Praxis zu untersuchen.

Um das Ziel zu erreichen, werden zunächst die begrifflichen Grundlagen dieser Arbeit geklärt (vgl. Kap. 2.1). Anschließend wird auf mögliche Vorteile, Probleme sowie Grenzen des UML Einsatzes eingegangen (vgl. Kap. 2.2). Dabei wird speziell die Entwicklung einer branchenneutralen, kaufmännischen Standardsoftware für mittelständische Unternehmen berücksichtigt.

Als Untersuchungsobjekt dient eine Enterprise Resource Planning (ERP) Software, die von einem mittelständischen Softwareproduzenten mit 20 Mitarbeitern hergestellt, vertrieben und kundenspezifisch angepasst wird (vgl. Kap. 3.1). Sie befindet sich bereits bei ca. 200 kleinen und mittelständischen Unternehmen im Einsatz, bei einigen der Unternehmen seit fast 20 Jahren. Der Autor dieser Arbeit ist seit mehreren Jahren als Leiter der Entwicklungsabteilung für den Aufbau und die Erweiterung der o.g. Software verantwortlich.

Als Untersuchungsmethode wird vom Autor das Vorgehen bei der Anforderungsdefinition der o.g. Software beschrieben und beurteilt. Da das Produkt bereits im Markt eingeführt ist, werden im Fallbeispiel insbesondere die Komplexität des Produktes, sowie sich daraus ergebende Probleme beschrieben (vgl. Kap 3.1). Im Folgenden Kapitel werden an Hand eines konkreten Beispiels Gründe für den Einsatz von bzw. der auf Verzicht von UML bei der Definition von Änderungsanforderungen gezeigt (vgl. Kap. 3.2).

Im Ergebnis werden die untersuchten Probleme und Vorteile beim Einsatz von UML bei der Anforderungsdefinition an Hand des Fallbeispiels zusammenfassend dargestellt (vgl. Kap. 3.3).

2 Anforderungsdefinition in der Softwareentwicklung

2.1 Begriffsdefinition und Grundlagen

Grundsätzlich beschäftigt sich diese Arbeit mit einem Teilbereich des Requirement Engineerings (RE): Der Anforderungsdefinition (vgl. Kap. 2.1.1).

Das RE „beschreibt den Weg von der Projektidee über die Ziele zu einem vollständigen Satz von Anforderungen“ (vgl. Rupp 2004, 11). Der Autor dieser Arbeit hat sich zum Ziel gesetzt, ein Teilstück dieses Weges näher zu betrachten. Genauer gesagt die Konkretisierung einer bereits dokumentierten, ursprünglichen Anforderung (vgl. Kap. 2.1.1) mit Hilfe der UML (vgl. Kap. 2.1.2) in Kontext einer ERP Software (vgl. Kap. 2.1.3).

2.1.1 Anforderungsdefinition

In dieser Arbeit werden zwei Arten von Anforderungen auf Grund Ihrer Herkunft und Ihrer Aufgabe unterschieden: Ursprungsanforderungen und Anforderungsdefinitionen.

Grundsätzlich können Anforderungen sowohl als allgemeine Wünsche von Benutzern an ein zu entwickelndes System, als auch als notwendige, zu erfüllende Eigenschaften, welche sich aus gesetzlichen Vorgaben oder Normen ergeben, definiert werden (vgl. Pohl 2007, 13; in Anlehnung an IEEE Std. 610.12-1990). Im Folgenden wird für diese Art der ursprünglichen Anforderung der Begriff der Ursprungsanforderung verwendet.

Eine Anforderungsdefinition wird im Kontext dieser Arbeit als dokumentierte, technische Konkretisierung einer existierenden Ursprungsanforderung an das Softwaresystem verstanden. Die Anforderungsdefinition ist somit ein Dokument (auch als „Artefakt“ bezeichnet, vgl. Pohl 2007, 14; Meyer zu Bexten 2007; etc.), welches eine vorliegende Ursprungsanforderung als technisches Konzept oder lösungsbasierte Anforderung näher beschreibt. Dabei wird insbesondere auf die softwareseitige Art der Implementierung eingegangen. Mit der Anforderungsdefinition soll ein Softwareentwickler oder Softwarearchitekt grundsätzlich in die Lage versetzt werden, die ursprüngliche Anforderung fachgerecht zu implementieren (vgl. Pohl 2007, 49, 181ff.).

Wissenschaftlich gesehen stellt die Anforderungsdefinition den Teilbereich des RE dar, in dem bestimmte Dokumentationstechniken angewendet werden, um die ursprüngliche, meist natürlichsprachliche Anforderung in formale Notationen umzuwandeln, zu konkretisieren und zu detaillieren (vgl. Rupp 2004, 156).

2.1.2 Unified Modeling Language (UML)

Die Unified Modeling Language (UML) ist eine graphische, standardisierte Sprache für die Modellierung von Software. Die UML beschreibt einen Satz von Modellelementen, mit deren Hilfe verschiedene Sichten auf ein Softwaresystem oder auch Teile des Systems konstruiert werden können (vgl. Wikipedia, AlnoktaBOT 2007; Neumann 2002, 116; etc.).

Die UML wurde von der 1989 gegründeten Object Management Group als Nachfolger verschiedener objektorientierter Beschreibungs- und Vorgehensmodelle entwickelt (vgl. OMG 2007). Die Sprache wurde 1995 in ihrer ersten Version 0.8 als Nachfolger von Modellen wie die von OOSE, Booch, OMT verabschiedet und liegt aktuell in der Version 2.0 vor (vgl. Wikipedia, AlnoktaBOT 2007).

Die UML hat sowohl in der Literatur, als auch in der Praxis eine weite Verbreitung gefunden und stellt inzwischen den Industriestandard für objektorientierte Softwareentwicklung dar (vgl. Pohl 2007, 200). Sie scheint geeignet, um den Problemen, die zwischen der Transformation von der Modellbildung bis zur der späteren Modellinterpretierung auftreten können, effizient zu begegnen (vgl. Pohl 2007, 293ff.).

2.1.3 Enterprise Resource Planning (ERP) Software

Enterprise Resource Planning (ERP) Software steht in einer engen Definition für eine „integrierte Software-Lösung für die Steuerung der Auftragsabwicklung, des Vertriebs und der Abrechnung in einem Unternehmen“ (vgl. Brockhaus 2005).

In einer weiten Definition, wie sie in dieser Arbeit, insbesondere in der Fallstudie, verwendet wird, werden die Aufgaben einer ERP Software deutlich weiter gefasst (vgl. Wikipedia, S.K. 2007): Eine ERP Software dient generell dem Verwalten sämtlicher Unternehmensressourcen, wie z.B. Kapital, Betriebsmittel und Personal. Die Software ist somit in der Lage betriebliche Prozesse umfassend abzubilden und zu unterstützen. Zu den Unternehmensbereichen, die unterstützt werden, zählen u.a.:

- Materialwirtschaft
- Produktion
- Finanz- und Rechnungswesen
- Controlling
- Personalwirtschaft
- Verkauf und Marketing
- Stammdatenverwaltung.

2.2 Einsatz von UML bei der ERP-Softwareentwicklung

Anforderungen bilden die Grundlage des Änderungsmanagements und sollten relevant, eindeutig, vollständig, nachverfolgbar und prüfbar definiert werden (vgl. Blaubach 2002, 8).

In diesem Kapitel wird daher der Einsatz von UML bei Entwicklung einer ERP Software auf einer allgemeinen Ebene betrachtet. Insbesondere soll darauf eingegangen werden, dass das Modellieren komplexer Softwareprodukte und auch deren Änderung die Unterstützung moderner Modellierungswerkzeuge und Sprachen benötigt (vgl. Brandes 2006).

2.2.1 Dokumentation von Anforderungen

Eine wichtige Voraussetzung, die eingangs genannten Grundlagen des Änderungsmanagements zu gewährleisten, ist die konsequente Dokumentation von Anforderungen. Diese sichert nicht nur die Nachverfolgbarkeit, sondern auch die spätere Prüfbarkeit auf Vollständigkeit. Voraussetzung dafür ist jedoch die laufende Aktualisierung der Dokumentation. Dokumente, die nicht den aktuellen Entwicklungs- und Anforderungstand beschreiben, sind im Grunde nicht brauchbar. Sie verursachen im Nachhinein deutlich mehr Kosten, als der Aufwand der notwendig ist, die Dokumente laufend auf dem neusten Stand zu halten (vgl. Wiegers 2005, 270).

Das Problem entsteht hier nicht durch die relativ kompakte Ursprungsanforderung des Kunden oder Auftragsgebers. Diese beschreibt insbesondere in einem ERP-System oft lediglich die kaufmännisch-fachlichen Ziele oder Szenarien. Entweder in einer einfachen, natürlichsprachlichen oder modellbasierten Form (vgl. Pohl 2007, 47, 87ff. und 117ff.). Insbesondere bei typischen Ursprungs-Änderungs­anforderun­gen, ist eine Veränderung dieser Anforderung im Laufe der Implementierung auf Grund der geringen Komplexität eher selten zu erwarten.

Im Gegensatz dazu kann das lösungsorientierte, technische Konzept einer Anforderungsdefinition relativ umfangreich und komplex werden. Somit kann erwartet werden, dass eine Änderung des Konzeptes im Laufe der Implementierung relativ häufig auftritt. Dieser Aspekt verstärkt sich bei einem iterativen Vorgehen in der Entwicklung. Die spätere Implementierung wird i.d.R. nicht mehr mit der ursprünglichen (ersten) Anforderungsdefinition übereinstimmen - wohl aber noch mit Ursprungsanforderung!

Die Dokumentation sollte jedoch immer dem neuesten Entwicklungsstand entsprechen.

Die Verwendung von UML kann die Problematik an dieser Stelle entschärfen: Sie kann in einem objektorientierten Softwareentwicklungsprozess im ersten Schritt eingesetzt werden, um die objektorientierten Anforderungsdefinitionen als direkte Grundlage für die zu implementierenden Lösung zu verwenden (vgl. Neumann 2002, 62ff.). In den folgenden Schritten, während der Implementierung, ist es relativ leicht möglich, direkt die UML-Anforderungsdefinition zu verwenden und zu aktualisieren. Alternativ kann versucht werden, bei der Beachtung objektorientierter Entwicklungsprinzipien, die UML-Anforderungsdefinition mit Hilfe des sog. „Reverse Engineering“ wieder auf einen aktuellen Stand zu bringen (vgl. Neumann 2002, 84ff.).

Vorraussetzung für den o.g. UML-Einsatz sind jedoch UML-Softwaretools und Entwicklungsumgebungen, die diesen Prozess effizient unterstützen - nicht zuletzt, um die Akzeptanz bei den beteiligten Entwicklern zu sichern.

2.2.2 Reduzierung der Komplexität

Anforderungsdefinitionen können eine relativ hohe, programmiertechnische Komplexität aufweisen, da sie nicht nur untereinander, sondern auch mit anderen Anforderungen und gegebenen Randbedingungen durch Beziehungen, Abhängigkeiten und Konflikte in Relation stehen (vgl. Blaubach 2002, 19 und Kap. 2.2.1).

Komplexität entsteht in diesem Zusammenhang, wenn die Umsetzung einer Anforderungsdefinition sehr viele Programmteile betrifft (Komplexität in der Breite) oder wenn ein einzelner Programmteil oder das gesamte Programm zur Erfüllung der Anforderungsdefinition grundsätzlich überarbeitet werden müssen (Komplexität in der Tiefe) (vgl. Abbildung 1).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Verschiedene Arten der Komplexität (Beispiel)

In einem ERP-System tritt tendenziell der erste Fall (Komplexität in der Breite), häufiger auf. Grund ist die objektorientierte Verwendung von gemeinsamen Klassen und Funktionen in verschiedenen Programmteilen (im o.g. Beispiel, die des Belegdruckmoduls).

Eine bewährte Strategie, komplexen Problemen (oder Anforderungen) zu begegnen, ist das Zerlegen des Gesamtproblems in einzelne Teilprobleme, die weniger komplex sind (vgl. Fricke 1998, 10).

UML kann bei dieser Strategie in mehrfacher Hinsicht zur Komplexitätsreduktion beitragen:

Verwendung eines UML-Tools bei Komplexität in der Breite

1. Identifizierung der von der Änderung betroffenen Programmteile bzw. Klassen und Komponenten.
2. Aufteilen der Gesamtanforderungsdefinition in einzelne Teilanforderungs­definitionen.
3. Design, Implementierung, Test der einzelnen Teilbereiche.
4. Dokumentation der Änderungen im Gesamtmodell.

Verwendung eines UML-Tools bei Komplexität in der Tiefe

1. Analyse des existierenden Programmteils bzw. der betroffenen Komponente.
2. Änderung des alten Designs und/oder Entwurf eines neuen Designs in UML.
3. Implementierung, Test und Dokumentation der Änderungen.

Diese einfachen Grundprinzipien bilden im Grunde die Basis vieler Vorgehensmodelle und Softwareentwicklungsprozesse. Diese haben vorrangig das Ziel, wie oben beschrieben, komplexe Probleme durch Einzelschritte, Zerlegung und Validierung zu lösen. Beispiele hierfür sind die iterative Entwicklung mit dem „Extreme Programming“ (vgl. Wolf u.a. 2005), das Vorgehensmodell des Bundes „V-Modell XT“ (vgl. KBSt 2004), der „Object Engineering Process“ (vgl. Oestereich 2001, 87ff.) oder auch eher klassische Vorgehensmodelle wie das Wasserfallmodell und das Spiralmodell (vgl. Wikipedia, 193.80.131.90 2006).

Die Verwendung von UML zusammen mit einem entsprechenden Vorgehen kann dabei helfen, typische Fehler, wie sie bei einem weniger disziplinierten Vorgehen bei komplexen Problemen entstehen, zu vermeiden.

Zu diesen Fehlern zählen u.a. (vgl. Oestereich 2001, 25):

- Zu frühes/spätes codieren
- Schlechte Planung
- Fehlendes Vorgehensmodell
- Unzureichende Validierung der Ergebnisse
- Unkontrollierte Entwicklung des Anwendungsarchitektur
- Entwicklungsrichtlinien fehlen
- Unzureichende Dokumentation

2.2.3 Grenzen beim Einsatz von UML-Werkzeugen

Bei der Anforderungsdefinition und der Softwareentwicklung kann UML ein hilfreiches Werkzeug darstellen, wie in Kap. 2.2.1und 2.2.2 beschrieben. Man muss in diesem Zusammenhang jedoch beachten, dass der Einsatz von UML erst beim Einsatz eines effizienten UML-Software-Tools seine Stärken, wie automatische Dokumentation, Komplexitätsreduktion und automatische Generierung von Quellcode, etc., ausspielt (vgl. Rupp 2004, 191).

Diesem Einsatz sind in der Praxis jedoch technische und wirtschaftliche Grenzen gesetzt, die im Folgenden untersucht werden.

Technische Grenzen

Die meisten guten UML Tools unterstützen alle gängigen UML-Diagrammarten. Auf Grund dessen sind zunächst die meisten Tools für die Anforderungsdefinition grundsätzlich geeignet. Problematisch ist jedoch die teils fehlende Unterstützung verschiedener Entwicklungsumgebungen und Programmiersprachen (vgl. Jeckle 2004). So kommt es zu Reibungsverlusten, falls kein Tool zur Verfügung steht, welches Dokumentation, Implementation und Tests über den gesamten Entwicklungsprozess durchgängig unterstützt.

Während viele Tools die Programmiersprachen Java und C++ unterstützen ist die Auswahl bei Sprachen wie C#, Delphi oder XML deutlich eingeschränkt (vgl. Jeckle 2004) – auch wenn der Zeit ein gegenläufiger Trend zu beobachten ist. Grundsätzlich muss beachtet werden, dass nicht jedes Tool jede Sprache im gleichen Umfang unterstützt. Unterschiede gibt es vor allem bei der Unterstützung einzelner Diagrammtypen und beim Reverse Engineering (vgl. Kap. 2.2.1). Exemplarisch sei hier der „Enterprise Architect“ von Sparx Systems (2007) genannt. Dieses Tool unterstützt UML vollständig, die meisten Programmiersprachen jedoch nur in Bezug auf statische Diagrammtypen (z.B. Klassendiagramme). Auch das Reverse Engineering funktioniert bei komplexeren Klassen-Strukturen nicht mehr einwandfrei oder ist nicht mehr lesbar (vgl. Anhang 6).

Wirtschaftliche Grenzen

Die wirtschaftliche Grenze der Anschaffung und Verwendung eines UML-Werkzeugs lässt sich aus den o.g. technischen Grenzen ableiten: Benötigt wird ein umfangreiches UML-Werkzeug, das den gesamten Prozess von der Anforderungsanalyse über die Entwicklung bis hin zum Testen mit einer durchgängigen Dokumentation unterstützt (vgl. Rupp 2004, 191). Insbesondere bei kleinen und mittleren Softwareproduzenten sind jedoch die Mittel, die für ein solches Werkzeug aufgewendet werden können, begrenzt. Zum einen entstehen u.U. hohe Anschaffungskosten für die Lizenzen und ggf. benötigte Hardware. Zum anderen kann für die benötigte Installations-, Einführungs- und Schulungszeit eines solchen Werkzeugs in die Prozesse eines Unternehmens ein hoher Aufwand an Software- und Personalkosten entstehen.

Abbildung in dieser Leseprobe nicht enthalten

Der Zusammenhang zwischen der von einem Unternehmen benötigten Funktionalität und den entstehenden Kosten, verhält sich wie eine klassische Kosten-Nutzen Funktion: Es fällt auf jeden Fall ein Minimum an Kosten an und diese erhöhen sich mit steigendem Nutzen exponentiell. Somit ist der der Verlauf nicht linear und lässt sich wie folgt darstellen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: UML-Tools: Verhältnis abgedeckter Funktionalität zu Kosten

Letztendlich muss ein Unternehmen selbst entscheiden, welche Funktionalität benötigt wird und welche Ressourcen hierfür aufgewendet werden können. Diese Entscheidung lässt sich nicht pauschalisieren, da das Optimum nur individuell ermittelt werden kann.

2.2.4 Grundsätzliche Probleme

Neben den in Kap. 2.2.3 aufgezeigten Grenzen, sind im Zusammenhang mit dem Einsatz von UML noch weitere grundsätzliche Probleme zu beachten (vgl. Rupp 2004, 190ff.):

Akzeptanz

Die beteiligen Entwickler müssen die Verwendung von UML zur Anforderungsdefinition akzeptieren und verstehen. Da die Anforderungsdefinition als Vorlage zur Implementierung verwendet werden soll (vgl. Kap. 2.1.1), müssen die Entwickler von der Verwendung von UML überzeugt sein. Dabei geht es nicht nur um die Verwendung der Diagramme als einmalige Vorlage, sondern auch um die Erweiterung und Pflege der Diagramme, da diese die Grundlage einer aktuellen Dokumentation bilden (vgl. Kap. 2.2.1).

[...]