Requirements Engineering in Extreme Programming

Inhaltsverzeichnis

Stichwortverzeichnis

Abbildungsverzeichnis

1 Einleitung
1.1 Die Hauptbegriffe
1.1.1 Requirement / Anforderung
1.1.2 Requirements Engineering
1.1.3 Extreme Programming
1.1.4 User Story / Storycard
1.2 Problemstellung und Zielsetzung

2 Was ist Extreme Programming (XP)?
2.1 Rollen
2.1.1 Der Programmierer
2.1.2 Der Kunde
2.1.3 Die Nebenrollen
2.2 Methoden
2.2.1 Pair Programming
2.2.2 Einfaches Design durch Refactoring
2.2.3 Testen
2.2.4 Kurze Release – Zyklen
2.2.5 Planungsspiel
2.3 Vorgehensmodell
2.4 Werte und Prinzipien
2.5 Das „Besondere“ an Extreme Programming

3 Requirements-Engineering (RE)
3.1 Requirements Sammeln
3.2 Requirements Analyse
3.3 Requirements Dokumentation

4 RE in XP
4.1 Der RE Prozess bei XP
4.1.1 Änderungen
4.1.2 Dokumentation
4.2 Unterschiede zu klassischen Ansätzen
4.2.1 Vorteile
4.2.2 Nachteile
4.3 Einsatz von XP bei großen Projekten
4.3.1 XP Projektgrößen
4.3.2 Probleme
4.3.3 Strukturelle Verbesserungen
4.4 Verbesserungsvorschläge

5 Fazit

A Literaturverzeichnis

B Glossar

C Anhang

Erklärung

Stichwortverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abb.1: XP Vorgehensmodell

Abb.2: Kosten für Änderungen im Verlaufe eines Projektes

Abb.3: XP Projektgrößen

Abb.4: XP Projektteams mit koordinierender Instanz

Abb.5: Am RE Prozess beteiligte Rollen

1 Einleitung

In diesem Kapitel wird ein kurzer Überblick über die Studienarbeit gegeben. Nach der Klärung der Begrifflichkeiten werden Inhalt und Motivation kurz erläutert, um dem Leser einen groben Überblick zu verschaffen.

1.1 Die Hauptbegriffe

1.1.1 Requirement / Anforderung

Die Begriffe Requirement und Anforderung werden in dieser Studienarbeit synonym verwendet. Ein Requirement ist ein Merkmal, dass bei der Entwicklung eines Soft­ware­sys­tems umgesetzt werden soll, um die Funktionalität oder den Nutzen zu erhöhen. Die­ses Merkmal wird meist durch den Benutzer definiert. Helmut Balzert beschreibt den Be­griff in seinem Lehrbuch der Softwaretechnik wie folgt: „Anforderungen (Re­qu­irements) legen die qualitativen und quantitativen Eigenschaften eines Produktes aus der Sicht des Auftraggebers fest.“ [BALZ00, S.98]. Ähnlich definiert wird der Begriff “Re­quir­ement” von D. Kulak und E.Guiney in dem Buch „Use Cases – Requirements in Con­text“: „It (a Requirement) is a specific function, feature, quality, or principle that the system must provide in order for it to merit its existence.“ [KULA03, S.5]. Ein Re­qui­rement ist folglich entweder eine Eigenschaft oder eine Funktionalität eines Systems. Es muss umgesetzt werden, um den vom Kunden oder Auftraggeber geforderten Nutzen zu erfüllen oder die geforderte Qualität zu gewährleisten. Daher werden Anforderungen in zwei Gruppen unterteilt (vgl. [Robe99, S.7]):

- Functional Requirements … sind Anforderungen, welche die Funktionalität für ein System beschreiben. Sie sind die Requirements, die man sich typischerweise unter dem allgemeinen Begriff vorstellt.
- Non-functional Requirements … fordern bestimmte Eigenschaften von dem zu entwickelnden System. Diese Requirements beschreiben keine Funktionalität, sondern für bestimmte Be­nutz­er­gruppen oder für den Auftraggeber wichtige Vorraussetzungen, wie z.B. Sicherheitskriterien, die Reaktionsgeschwindigkeit des Systems oder Be­nutz­er­oberflächendesign und Benutzerfreundlichkeit.

1.1.2 Requirements Engineering

Das Requirements Engineering umfasst alle Aktivitäten, die im Zusammenhang mit der Suche, Analyse und Auswahl von Anforderungen (Requirements) an Softwareneu- oder Wei­ter­ent­wick­lun­gen stehen (vgl. [BALZ00, S.98]). In diesem iterativen Prozess werden die Anforderungen an das Sys­tem unter Absprache mit allen Beteiligten normiert festgehalten. Sie bilden so die Grund­­lage für eine Systementwicklung. Beteiligte bei der Suche nach geeigneten Re­qui­­­rem­ents sind hierbei sowohl Analysten und Experten, aber auch der letztendliche Benutzer des Softwareprogramms sowie der Auftrag- oder Geldgeber. Zusätzlich müssen noch Experten herangezogen wer­den, um beispielsweise technische oder gesetzliche Anforderungen in diesen Prozess mit einfließen zu lassen.

1.1.3 Extreme Programming

Extreme Programming ist ein leichtgewichtiges, also gering dokumentiertes und gemanagtes Vorgehensmodell für kleinere Projekte, das auf einem iterativen Prozess basiert. Somit gehört Extreme Programming in die Gruppe der Agilen Softwareentwicklungsmethoden (vgl. [MART03, Kap.1]). Es definiert die einzelnen Vor­ge­hens­schritte der Software­entwicklung. Extreme Programming beschränkt sich aber nicht nur auf diesen Aspekt der Entwicklung, sondern umfasst zusätzlich eine Anzahl aus­ge­wähl­ter Methoden, Werte und Rollen, die den Prozess unterstützen. Diese Werte sind Maxi­men, an denen sich die Entwickler ausrichten sollen, um zum Erfolg des Projektes bei­zu­tragen. Durch Rollen werden Ver­ant­wortlichkeiten, Aufgaben, Recht und Pflichten den Personen einer Ent­wick­ler­grup­pe zu­geteilt. Diese Gruppen haben idealer Weise ei­ne Größe zwischen 10 und 20 Personen. Ein weiteres Merkmal von Extreme Programming ist der Umgang mit Anforderungen. Extreme Programming wird oft in Pro­jekten eingesetzt, bei denen die Re­quirements eher vage sind und oft nachträglich ge­ändert werden. Das Verfahren des Requirements Engineering wird in dieser Arbeit un­ter­sucht und in Kapitel vier ausführlicher behandelt.

1.1.4 User Story / Storycard

Ein Hauptbegriff, der bei XP in Verbindung mit Requirements verwendet wird, ist die User Story. „Jede User Story stellt eine Beschreibung des Systemverhaltens dar, aus der Sicht des Systembenutzers. Beim XP wird das komplette System über User Stories definiert.“ [JEFF01, S.41]. Die Stories werden auf Karteikarten, den sog. Storycards festgehalten und der Entwicklung vorgelegt.

1.2 Problemstellung und Zielsetzung

Wissenschaftliche Untersuchungen wie der Chaos Report der Standish Group zeigen auf, dass viele Softwareprojekte häufig den gesetzten Kostenrahmen überschreiten. Zudem wird oftmals der gesetzte Übergabetermin nicht eingehalten (vgl. [CHAOS99]). Ein weiteres Problem der Softwareentwicklung liegt darin, dass häufig das fertige Produkt nicht den Anforderungen des Kunden entspricht. Den Untersuchungen zufolge sind nicht etwa technische Mängel der Grund für diese Probleme, sondern mangelnde Kun­den­einbindung, methodische Defizite und vor allem Unzulänglichkeiten im Pro­jekt­ma­na­ge­ment sowie schlechtes Requirements Engineering. „ The three major reasons that a pro­ject will succeed are user involvement, executive management support, and a clear state­ment of requirements.“ [CHAOS94 S.4]. Um diese Probleme zu lösen, wurden Vor­ge­hens­modelle sowohl für den gesamten Entwicklungsprozess als auch für den Pro­zess der Anforderungsanalyse entwickelt. Extreme Programming ist, wie schon kurz unter Punkt 1.1.3 beschrieben, ein neuartiges Vorgehensmodell, welches die gesamte Ent­­wick­lung von Software betrachtet. XP orientiert sich an der Frage wie man Soft­ware von hoher Qualität entwickelt, wenn sich die Anforderungen ständig ändern, ohne den Termin- und Kostenrahmen zu überschreiten. Damit zeigt dieses Vor­geh­ens­mo­dell häufige Probleme der Software­entwicklung auf. Um die­ses Ziel zu erreichen, geht XP in vielen Bereichen, wie auch bei der An­for­de­rungs­an­a­­lyse, neue Wege.

Diese Studienarbeit untersucht die Überschneidungen und Unterschiede zwischen Re-quir­ements Engineering bei Extreme Programming und anderen aktuellen Methoden zur Findung und Handhabung von Anforderungen. Ziel dieser Arbeit ist eine kritische Be­tracht­ung der Unterschiede des Requirements En­gi­nee­ring Prozesses zwischen XP und klassischen Ansätzen. Die Vorstellung der Ideen und Methoden des Extreme Pro­gram­mings erfolgt anhand veröffentlichter Literatur. Vor- und Nachteile des Re­qui­rements Engineering Prozesses werden gegenübergestellt. Ziel dieser Gegenüberstellung ist die Beantwortung der Frage, inwieweit XP die Probleme der Anforderungsanalyse lösen kann. Zusätzlich soll untersucht werden wie sich die Ansätze des RE bei XP durch den Einsatz klassischer Methoden verbessern lässt, um XP auch für größere Projekte ver­wen­den zu können.

2 Was ist Extreme Programming (XP)?

„Extreme Programming ist eine kompakte Methode zur Entwicklung von Software in kleinen bis mittelgroßen Teams, deren Arbeit vagen oder raschen Änderungen unterliegt. “ [BECK00, S.xv]

Mit diesem Satz charakterisiert Kent Beck, der Erfinder des Extreme Programmings, seine Disziplin Software zu entwickeln. XP ist also nicht, wie man von der Bezeichnung her vermuten würde, eine besondere Programmierungstechnik. Es beschreibt ein Vorgehensmodell, dass durch verschiedene Methoden und Herangehensweisen unterstützt wird. Doch wo liegen die Besonderheiten? Wie unterscheidet sich dieses neue Vorgehensmodell von all den anderen Modellen? Diese und weitere Fragen werden in diesem Kapitel aus verschiedenen Blickwinkeln beleuchtet.

2.1 Rollen

Kent Beck weist in seinem Buch die verschiedenen Aufgaben, Rechte und Pflichten, welche bei einem Softwareentwicklungsprojekt anfallen, verschiedenen Rollen zu (vgl. [BECK00, Kap22]). Jede Rolle hat unter­schiedliche Aufgaben zu erfüllen, muss aber nicht zwingend von unterschiedlichen Personen besetzt werden. Eine Person kann also zwei eng verknüpfte Rollen übernehmen, wohingegen andere Rollen von unterschiedlichen Mitarbeitern wahrgenommen werden müssen, um die Effektivität des Entwicklerteams nicht zu beeinträchtigen. Im folgenden Abschnitt werden die verschiedenen Rollen kurz erläutert.

2.1.1 Der Programmierer

Der Programmierer übernimmt neben dem Kunden die Hauptrolle von XP. Analysieren, entwerfen, testen, programmieren und integrieren des Codes in das System sind die Hauptaufgaben des Pro­gram­mierers. Er schätzt den Schwierigkeitsgrad der An­for­der­un­gen des Kunden ein und kontrolliert die fachliche und terminliche Umsetzung der User Stories. XP zeichnet sich durch umfang­reiches Testen, klares und mög­lichst einfaches Design aus. Um jederzeit vorzeigbare Versionen für den Kun­den zu ha­ben, wird getesteter Code direkt in das System integriert, d.h. mit dem anderen schon ge­testeten Code zusammengefügt. Automatisierte Tests stellen sicher, dass das in­te­grier­te System zu jedem Zeitpunkt voll funktionsfähig ist. So kann der Kunde ent­schei­den, ob Teile des Systems schon produktiv eingesetzt werden können. XP-Programmierer ar­bei­ten paarweise an einem Computer. Diese Zusam­menarbeit verringert die Fehlerquote und erhöht zusätzlich die Designqualität des Programmcodes.

Für diese Aufgaben und Pflichten und muss der Programmierer bestimmte Eigenschaften mitbringen und Verantwortlichkeiten übernehmen:

- Um Anforderungen und Aufwandsschätzungen mit Kunden und anderen Programmierern abstimmen zu können, muss der Programmierer kommunikativ und teamfähig sein.
- Programmierer schätzen den Aufwand für übernommene Aufgaben selbst ein und sind für die Einhaltung des Terminplanes oder Aktualisierung des Projektplanes verantwortlich.
- Alle Programmierer tragen die Verantwortung für den gesamten Code, da jeder das Recht besitzt, jeden Code zu verändern.
- Programmierer Paare testen ihren Code selbstständig und integrieren fertige Programmteile in das Gesamtsystem nur, wenn es zu 100% fehlerfrei läuft.

2.1.2 Der Kunde

Der Kunde übernimmt die zweite Hauptrolle bei XP. Er bestimmt das zu erstellende Produkt und legt fest, welche Anforderungen für ihn Geschäftswerte darstellen. Ein Geschäftswert ist der Nutzen, den der Kunde aus der angeforderten Funktionalität zieht. Der Kunde priorisiert die Anforderungen, die auf so­ ge­nannten Story Cards festgehalten werden und bestimmt so, zu welchem Zeitpunkt welche Be­stand­teile erstellt werden. Die Anforderungen mit der höchsten Priorität werden dabei zuerst von den Program­mierern umgesetzt. Story Cards mit geringem Geschäftswert werden an das Ende des Prozesses verschoben. Jede Story Card beschreibt eine Einzelfunktion, die das System zu erfüllen hat. Die Stories müssen vom Kunden leicht verständlich beschrieben werden, so dass die Program­mierer die damit verbundenen Schwierigkeiten einschätzen können.

Die Aufgaben und Rechte des Kunden sind demnach:

- Der Kunde schreibt Anforderungen auf Story Cards und priorisiert diese. Dafür muss er ständig Rücksprache mit den Programmierern nehmen, um jeweils den Aufwand pro Anforderung mit zu berücksichtigen.
- Der Kunde soll möglichst im Team mit eingebunden werden, um den Programmierern für Rückfragen zur Verfügung zu stehen.
- Der Kunde hat das Recht auf ein jederzeit lauffähiges System, an dem er fortwährend testen kann, ob das richtige Produkt entwickelt wird.

2.1.3 Die Nebenrollen

Die folgenden Rollen sind vom eigentlichen Verständnis des Extreme Programmings her gesehen keine Nebenrollen. Sie werden aber in dieser Arbeit zurückgestuft behandelt, da Sie für den Requirements Engineering Prozess weniger Bedeutung besitzen.

- Die Rolle des Testers unterstützt den Kunden bei der Entwicklung und Erstellung von Funktionstests. Er selbst testet selten, weil der Test des Codes in der Verantwortung der Programmierer liegt und die Funktionstests vom Kunden fachlich durchgeführt werden, da dieser den Hintergrund der Anwendung besser versteht. Diese Rolle beschränkt sich also auf Hilfestellung dem Kunden gegenüber und einer regelmäßigen Durchführung der automatisierten Tests am inte­grierten System.
- Der Terminmanager hat weniger mit der Terminplanung des Projektes zu tun als man vermuten würde. Diese Rolle übernimmt das Terminmanagement des Projektes, führt aber selbst keine Aufwandsschätzungen für Anforderungen durch, denn das obliegt der Rolle des Programmierers. Der Terminmanager analysiert vielmehr die Aufwandsschätzungen der Entwickler, gibt diesen ein Feedback und plant ihre Schätzungen ein. Er hat das Recht auf eine ehrliche Einschätzung der Programmier. Der erstellte Plan beinhaltet alle Anforderungen und Zeiten des nächsten Zyklusdurchlaufs. Eine weitere Aufgabe dieser Rolle ist die Protokollführung fehlgeschlagener Tests und veränderter Requirements. Diese müssen in den Zeitplan eingearbeitet werden und ggf. muss der Release – Plan neu mit dem Kunden abgestimmt werden.
- Die Rolle des Coachs ist ähnlich der eines normalen Gruppenleiters. Er ist für den gesamten Prozess verantwortlich. Seine Aufgaben liegen in den Bereichen Problemlösung, wie das Beheben von Fehlern in Zusammenarbeit mit den Entwicklern und Ausrichtung der Gruppe auf das Ziel des Projektes. Zusätzlich gibt er Hilfestellung bei Programmier- oder Designfragen.
- XP Projekte benötigen Berater, um Schwächen des Teams auszugleichen. Der Berater ist nicht ins eigentliche Projekt involviert, sondern ein externer Mitarbeiter. Er unterstützt die Grup­pe in technischen Details.
- Der „ Big Boss “ ist der Führer des Projektes. Diese Rolle hält der Ent­wick­ler­grup­pe einerseits den Rücken frei, andererseits muss Ausrichtung und Motivation der Grup­pe von Zeit zu Zeit überprüft werden. Der „Big Boss“ trägt die Ver­ant­wor­tung für das Gesamtprojekt.

2.2 Methoden

XP beinhaltet eine Sammlung von Methoden und Verfahren, die den Ent­wick­lungs­pro­zess unterstützen und ohne die XP nicht funktionieren würde. Jede Methode hat ihre Vor- und Nachteile, doch durch geschickten Einsatz dieser Verfahren können Synergien genutzt werden. In den folgenden Abschnitten werden die wichtigsten Charakteristiken kurz vorgestellt.

2.2.1 Pair Programming

Das Programmieren in Paaren ist eine Grundlage von XP. Entwickelt wird immer (!) in Zweiergruppen. Ein Programmierer übernimmt dabei die Codierung, d.h. das Tippen des Programmcodes. Die zweite Person schaut dem Programmierer über die Schulter und unterstützt beim Design. Sie behält den Überblick und gibt Vorschläge für Testfälle und Refactoring – Ansätze. Der Begriff Refactoring wird im nächsten Abschnitt erläutert.

2.2.2 Einfaches Design durch Refactoring

Refactoring ist ein formaler Prozess zur Verbesserung des Programmcodes. „Refactoring is the practise of making a series of tiny transformations that improve the structure of the system without affecting its behaviour.“ [MART03, S.16]. Man versucht einen Codeabschnitt (beispielsweise ein Objekt der objekt­orientierten Programmierung) neu zu entwerfen, um ihn einfacher zu gestalten ohne seine Funktionalität zu verändern. Refactoring wird bei XP verwendet, um Code und Design möglichst einfach, testbar und verständlich und somit kostengünstig korrigierbar zu halten. Dies ist notwendig, da jeder Entwickler jeden Programmcode des Systems anpassen darf.

2.2.3 Testen

In XP werden verschiedene Testverfahren verwendet. Die wichtigsten sind au­to­ma­tisierte Unit – Tests und Akzeptanztest. Unit – Tests werden von den Entwicklern programmiert, um den fertigen Programmcode automatisiert testen zu können.

„Such testing, known as ( … ) unit testing verifies, that the component functions properly with the types of types of input expected from studying the component’s design.“ [PFLE98, S.284]. Wie hier durch Dr. Pfleger beschrieben, werden die programmierten Funktionen oder Objekte bei einem bestimmten Input auf den erwarteten Output hin getestet. Diese Tests werden meist in Verbindungen mit Datenbanken automatisiert, so dass bei Änderungen im Code die Funktionstüchtigkeit trotzdem schnell überprüft werden kann. Kent Beck verlangt in seinem Manifest, dass für jede Funktionalität entsprechende Unit-Tests geschrieben werden sollen, wenn möglich bevor die eigentliche Funktionalität implementiert wird. „Eine Programmiereigenschaft, für die es keinen automatisierten Test gibt, existiert einfach nicht.“ [BECK00, S.57]. So sind die Entwickler stets für das Testen ihres eigenen Codes verantwortlich. Erst wenn die Tests zu 100% fehlerfrei durchlaufen, darf ein Programmteil ins Gesamtsystem integriert werden.

Um die korrekte Umsetzung der User-Stories zu überprüfen, werden zusätzlich Akzeptanztests eingesetzt, die vom Kunden geschrieben werden. Sie sollen überprüfen, ob das System jeweils der Anforderung des Kunden genügt. Ein Programmierer unterstützt den Kunden bei der Erstellung von automatischen Tests. Beide Testverfahren stellen zusammen in Verbindung mit anderen Tests, wie z.B. Performance – Tests, eine hohe Qualität der Software sicher.

2.2.4 Kurze Release – Zyklen

Um das Produkt schnell einsetzen zu können, bevorzugt XP kleine Release – Zyklen. Das bringt mehrere Vorteile mit sich. Erstens ist das Projekt durch den kurzen Zyklus einfacher plan- und kalkulierbar und zweitens wird durch den frühen Einsatz der Software ein schnelles Feedback durch die Benutzer ermöglicht. Dadurch wird ein anderer Umgang mit den Requirements notwendig, der in Kapitel vier weiter erörtert wird.

2.2.5 Planungsspiel

Die Planung eines Releases in XP unterscheidet sich stark von der allgemeinen Auffassung einer Projektplanung. Geplant wird aufgrund der kurzen Zyklen nur in einem sehr begrenzten Horizont. Zudem wird die Planung durch einen Dialog zwischen dem Kunden und den Programmierern erarbeitet. Es gibt keinen „von oben“ diktierten Plan. Der Kunde legt für das Release nur drei (!) der folgenden vier Variablen fest: Die Priorität der Anforderungen, den Umfang der Problemlösung, den Liefertermin des Releases und die Zusammensetzung der Version aus verschiedenen Anforderungen. Allerdings darf diese Entscheidung nur unter Berücksichtigung der Aufwandsschätzungen der Programmierer gefällt werden. So wird die Entwicklerseite nicht unter Druck gesetzt und kann sich voll auf die Arbeit konzentrieren. Für die Termin – Feinplanung sind die Entwickler selbst verantwortlich.

2.3 Vorgehensmodell

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: XP Vorgehensmodell

Das XP Modell beschreibt ein iteratives Vorgehen. Zu Beginn eines Zyklus, der idealerweise wenige Monate beträgt (vgl. [BECK00 S.62]), werden innerhalb des in 2.2.5 beschriebenen Planungsspiels die Entwicklungsziele festgelegt. Um auf kurzfristige Änderungen schnell reagieren zu können, wird der Zyklus noch in mehrere kürzere Iterationszyklen unterteilt, die jeweils eine Dauer von wenigen Wochen haben sollten. In den Iterationen planen, programmieren, testen und integrieren die Entwickler die User – Stories, sind aber immer für neue oder veränderte Anforderungen offen. Änderungen werden wieder in Zusammenarbeit mit dem Kunden in das Release eingeplant, so dass folglich andere User Stories entfallen können. Parallel zur Entwicklung schreibt der Kunde mit Hilfe des Testers Funktionstests, die am Integrationssystem durchgeführt werden. Mit dem Abschluss aller Iterationen und unter der Vorraussetzung, dass alle Tests bestanden wurden, ist das neue Software Release fertig. Der Durchlauf des Prozesses beginnt erneut, wobei das Feedback aus der produktiven Umgebung berücksichtigt wird. Der genaue Ablauf des RE Prozesses und die hierbei beteiligten Rollen werden ausführlicher in Kap. 4.1 beschrieben.

2.4 Werte und Prinzipien

Damit XP erfolgreich sein kann, nennt Kent Beck vier Grundwerte, die sich das XP – Team einprägen muss:

- Kommunikation – XP basiert auf schneller und unkomplizierter Kommunikation. Nur wenn Kunde und Entwickler an einem Ort sind, können Anforderungen schnell geklärt werden und weitgehend auf Dokumentation verzichtet werden. Dieses Prinzip beeinflusst maßgeblich das Requirements Engineering von XP.
- Einfachheit – Es wird für jedes Problem bzw. Requirement prinzipiell nur die einfachste Lösung umgesetzt, da von Änderungen ausgegangen wird. Alles, was darüber hinaus implementiert wird, ist bei Änderungen verschwendeter Aufwand.
- Feedback – Anforderungen können nur durch schnelles gegenseitiges Feedback von Entwicklern und Kunde diskutiert und eingeschätzt werden. Dadurch werden die o.g. Grundwerte unterstützt.
- Mut – Was nutzt eine Aufwandschätzung für eine Anforderung, wenn diese nicht ehrlich ist? Es kommt zu fehlerhafter Priorisierung und Terminierung und letztendlich wieder zu den klassischen Fronten zwischen Kunde und Entwickler. Daher ist Mut zur Wahrheit unabdingbar, Wahrheit gegenüber dem Kunden, Manager und Geldgeber. Auch Offenheit für Änderungen ist notwendig, was bedeuten kann, das Arbeit von mehreren Tagen wertlos ist. Mut ist die Basis von XP.

2.5 Das „Besondere“ an Extreme Programming

Software wird mit dem Ziel entwickelt, die Wünsche des Kunden in möglichst kurzer Zeit mit hoher Qualität zu geringen Kosten zu realisieren. Nach klassischer Ansicht steigen die Kosten für Änderungen im Verlauf eines Software – Lebenszyklus mit der Zeit exponentiell (vgl. [BECK00 S.21]). Daher wird versucht, Fehler so früh wie möglich zu beheben und zu vermeiden. Folglich wird im Idealfall durch ausführliche Anforderungsanalyse und Design die Wahrscheinlichkeit von Änderungen und Fehlern zu einem späteren Zeitpunkt reduziert. Hier geht XP „extrem“ andere Wege. Kent Beck versucht durch sein Vorgehensmodell in Verbindung mit den beschriebenen Methoden, Techniken und Werten die Kostenkurve abzuflachen und folglich Anforderungen und Änderungen zum spätmöglichsten Zeitpunkt zu finden bzw. umzusetzen. Dies bedeutet einen Kostenvorteil gegenüber der klassischen Vorgehensweise, da Investitionen später getätigt werden und das Projekt optimaler verzinst wird (vgl. [BECK00, Kap.3]).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Kosten für Änderungen im Verlaufe eines Projektes

Durch schnelle Kommunikation, Feedback, einfachen Code und automatisiertes Testen werden Änderungen im Verlaufe des Projektes nicht exponentiell teurer, sondern der Aufwand nähert sich einer Asymptote an. Daher ist XP einerseits für Änderungen offen, versucht andererseits aber immer nur die einfachste Lösung zu implementieren, da Änderungen folgen werden. Weitere Besonderheiten von XP ergeben sich durch schnelle Codierung und kurze Release – Zyklen. So kann sehr früh ein funktionsfähiges System in Produktion gehen. Dies verbessert enorm den Return on Investment (ROI) eines Projektes und führt zu schnellem Feedback aus der Produktionsumgebung. Neben dem ungewöhnlichen Umgang mit Änderungen liegen weitere Besonderheiten von XP im Bereich der Führung und des Management (vgl. [BECK00]). Hier lässt XP der Gruppe weitgehend die Verantwortung für Planung, Organisation und Um­setzung. Das Management ist nur begleitend tätig. Zudem kann die Ent­wick­ler­grup­pe nicht von Kunden oder Management unter Druck gesetzt werden (vgl. 2.2.5). XP beschreibt also nicht nur ein Vorgehensmodell für Softwareentwicklung, sondern bietet einen neuen Lösungsansatz für die Durchführung von Softwareprojekten.

3 Requirements-Engineering (RE)

In der Literatur gibt es zahlreiche Modelle, die den Requirements Engineering (RE) Prozess beschreiben. Je nach Autor durchläuft der RE Prozess verschiedene Phasen. Pohl beschränkt den Prozess auf die vier Phasen Erfassen, Verhandeln, Spezifizieren/ Dokumentieren und Validieren/Verifizieren (vgl. [POHL96, S. 17]). Balzert beschreibt die Schritte Ermitteln / Beschreiben, Modellieren, Analysieren, Verabschieden (vgl. [BALZ00, S.98]). Andere Autoren, wie Suzanne und James Robertson bieten hingegen komplexe RE-Prozessmodelle (vgl. [ROBE99]). Hieraus kann geschlossen werden, dass kein allgemein gültiges Modell existiert. Die Tatsache, dass verschiedene Vorgehensmodelle unterschiedliche Prozess-Modelle bedürfen, macht deutlich, dass es nicht den einen RE-Prozess geben kann. Grundsätzlich werden aber bestimmte Tätigkeiten und Vorgänge von allen Autoren, wenn auch mit gewissen Unterschieden, aufgeführt. Unterschiede liegen in der Vorgehensweise und den angewandten Techniken. Diese werden in den folgenden Unterpunkten kurz vor­ge­stellt.

3.1 Requirements Sammeln

Anforderungen werden in Gesprächen und Workshops ermittelt oder von anderen Projekten wieder verwendet. Hierbei liegt der Fokus auf einer möglichst vollständigen Erfassung von Functional und Non-functional Requirements (siehe 1.1.1). „At this stage you should be concentrating on finding all the Requirements and not missing any.“ [ROBE99, S.79]. Teilnehmer der Gespräche sind System­analysten und die Geschäfts­seite. Hierzu zählen mit (potentiellen) Endbenutzern, Kunden und Sach­ver­stän­digen alle diejenigen, die Anforderungen an das System stellen oder erläutern können. Neben Gesprächen können die Analysten beispielsweise durch Mitarbeit im Kundenumfeld den Hintergrund und die Geschäftsvorfälle des Systems erlernen, um selber die Anforderungen der Kunden zu überprüfen und ver­voll­ständigen. „Deshalb bedeutet die Ermittlung der Anforderungen auch stets die Beschäf­ti­gung mit dem Ver­wen­dungs­zweck der Software (geschäfts­prozessorientierte Kun­den­an­forderungsanalyse).“ [MELL98, S.166]. Ein hohes Fehlerpotential in dieser Phase des RE Prozesses liegt in der Aufnahme von Designelementen in Requirements (vgl. [LAWR01, S.2]) und fehler­hafter Kommunikation. Um dieses zu verringern, können Techniken wie das Erstellen von Prototypen oder die Verwendung von Use Cases und anderen Diagrammen zur Unterstützung benutzt werden. „ The Intention of the prototype is to present the user with a simulation of the Requirements. “ [ROBE99, S.16], (vgl. [PFLE98, S.169]). Mit diesen Techniken kann das Verständnis von Requirements zwischen Analysten und Kunden angeglichen werden. In der Literatur werden viele weitere Techniken und Risiken der Sammlungsphase beschrieben, die hier aber aufgrund des Umfangs der Arbeit nicht erwähnt werden.

3.2 Requirements Analyse

Die Analysephase überprüft die potentiellen Anforderungen auf Notwendigkeit, Machbarkeit, Vollständigkeit, Überschneidungen und Konflikte (vgl. [PART91, S.48], [ROBE99, Kap.13]). Aus Kostengründen werden nicht sinnvolle Requirements abgelehnt und „nice to have“ Anforderungen werden niedriger priorisiert. Die Vollständigkeit der gesammelten Anforderungen wird meist durch einen Review von RE – Spezialisten erzielt. Zusätzlich kann der Umfang der Anforderungen durch Literatur und Requirements- Patterns überprüft werden. Überschneidungen und Konflikte müssen verhandelt werden, um sie zu lösen. Ein weiteres wichtiges Merkmal der Analysephase ist die Überprüfung auf Eindeutigkeit. Requirements müssen für alle (!) Beteiligten eindeutig formuliert und Non-functional Requirements messbar sein, um Fehlerquellen auszuschließen und sie überprüfbar zu machen.

3.3 Requirements Dokumentation

In der letzten Phase müssen die überprüften Anforderungen nach klassischer Ansicht in eine normierte Form gebracht werden. Dies kann beispielsweise durch den Einsatz von Templates erreicht werden. Aktuelle Ansätze bilden Anforderungen durch Use Cases oder weitere Diagramme ab (vgl. [KULA03, Kap.2]). Die agilen Vorgehensmodelle wie XP formalisieren Requirements eher nicht und erfassen sie ebenfalls nicht über längere Zeiträume (vgl. [MART00, S.12], [JEFF00, Kap.4]). Output dieser Phase sind in einer Spezifikation formalisierte Anforderungen, welche die Basis für die weitere Entwicklung des Produktes bieten.

4 RE in XP

Der RE – Prozess bei Extreme Programming unterscheidet sich stark von den in Kapitel drei aufgezeigten klassischen Ansätzen. Ziel dieses Kapitels ist es, die Unterschiede durch Gegenüberstellung der Ansätze zu erarbeiten sowie Vor- und Nachteile von XP, insbesondere bei umfangreicheren Projekten, zu diskutieren.

4.1 Der RE Prozess bei XP

Das Requirements Engineering bei Extreme Programming ist keine in sich abgeschlossene Phase, sondern wird parallel zur Entwicklung durchgeführt. Die Hauptrolle in diesem Prozess übernimmt der Kunde. Mit dem ersten Release Plan Meeting beginnt der Prozess. Teilnehmer sind Personen der Geschäfts- und Entwicklungsseite. Hier werden von der Geschäftsseite, d.h. dem Kunden und anderen Verantwortlichen, neue Storycards (vgl. 1.1.4) geschrieben oder von der letzten Iteration wieder verwendet. Die geschriebenen User Stories werden von der gesamten Gruppe hinsichtlich Qualität, Machbarkeit, Vollständigkeit diskutiert. Der Kunde bzw. die Geschäftsseite legen den Geschäftswert der Anforderungen fest. Nach Durchführung einer Aufwandschätzung für jede User Story können diese folglich durch eine Kosten / Nutzen Analyse priorisiert werden. Die Aufwandsschätzung wird von den Entwicklern in Abstimmung mit dem Kunden übernommen. „Als Kunde beschäftigen Sie sich bei der Release Planung (, …,) mit dem Geschäftswert jeder Story, wogegen die Programmierer eine auf Punkten basierende Schätzung (…) beitragen.“ [JEFF01, S.84]. Nach dem Abschluss der Iterationsplanung durch das Einplanen der vom Kunden ausgewählten Storycards ist der RE Prozess noch nicht abgeschlossen sondern verläuft parallel zur Entwicklung weiter. Dadurch, dass der Kunde bei der Entwicklung vor Ort ist, kann er den Entwicklern Fragen zu den Anforderungen schnell beantworten. Nach Abschluss einer Iteration beginnt der Prozess von neuem. Abgeschlossen wird der RE Prozess bei XP erst mit dem Ende des Projektes. Dies ist erreicht, wenn die Geschäftsseite das Projekt für beendet erklärt, oder keine neuen Anforderungen mehr gefunden werden. „Wenn dem Kunden keine neuen Storycards mehr einfallen, dann ist es an der Zeit, das Projekt einzumotten.“ [BECK00, S.137].

4.1.1 Änderungen

Änderungen der Requirements werden bei XP erwartet. Wenn der Kunde seine Aufgaben, wie das Schreiben von Akzeptanztests und Testen am Integrationsrechner wahrnimmt, wird er schnell Verbesserungsvorschläge finden. In späteren Stadien des Projektes wenn schon erste Versionen des Systems in Produktion gegangen sind, werden hier weitere Anforderungen und Änderungsvorschläge entstehen. Aufgrund des regelmäßigen Feedbacks der Geschäftsseite entstehen so qualitativ hochwertige Anforderungen an das System, indem die Requirements immer wieder im realen Produktionseinsatz geprüft und danach überarbeitet werden. Regelmäßiges Feedback wird auch in der Fachliteratur als Erfolgsfaktor angesehen: „Successfull projects involve customer feedback on a regular and frequent basis.“ [MART03, S.5]. Erarbeitete Änderungsvorschläge können entweder sofort in den aktuellen Release Plan auf­genom­men oder für das nächste Planungsmeeting aufgehoben werden. Um den Umfang des Releases nicht zu verändern, muss dafür allerdings entweder eine andere User Story zurückgestellt oder der Termin für die Fertigstellung des Releases verschoben werden (vgl. 2.1.2).

4.1.2 Dokumentation

Der RE Prozesses bzw. die Requirements werden bei XP nur in geringem Maße dokumentiert. Die Dokumentation beschränkt sich auf die Storycards mit angehefteten Informationen. „Die Unterhaltungen und Diskussionen werden während des Projektes als zusätzliche Informationen aufgezeichnet und in der den Storykarten angehefteten Dokumentationen festgehalten.“ [JEFF01, S.45]. Daher gibt es bei XP auch keine klassische Spezifikation oder andere dokumentierende Dokumente, wie auch Richard Duncan in seiner Arbeit zum Thema „The Quality of Requirements in Extreme Programming“ beschreibt: „The specification is not a single monolithic document; instead, it is a collection of user stories, the acceptance tests written by the customer, and the unit tests written for each module.“ [DUNC01, S.2]

4.2 Unterschiede zu klassischen Ansätzen

Die größten Differenzen zwischen dem RE Prozesses in XP und den klassischen Ansätzen liegen in dem Fehlen einer eigenen RE Phase sowie der unformalen Vorgehensweise. Sowohl bei den linearen Vorgehensmodellen (Wasserfallmodell u.ä.) als auch bei den In­kre­men­tel­len (Spiralmodell) wird das Requirements Engineering als eigene Aktivität behandelt. Der Output dieser Aktivität ist normalerweise ein formales Dokument, das als Input in die Entwicklung einfließt. Im Gegensatz dazu verwendet XP die völlig informellen Storycards. Diese werden weder elektronisch noch langfristig festgehalten. Der RE Prozess bei XP wird bis zum Projektschluss nie abgeschlossen. Während der Entwicklung ist der Kunde weiterhin mit Suche, Erfassung, Verifizierung und Priorisierung von Anforderungen beschäftigt. Weitere Unterschiede sind:

- Anforderungen werden nur von einem Kunden mit Hilfe von Entwicklern externen Beratern und nicht von Analysten aufgenommen. Nach klassischer Ansicht werden im Gegensatz dazu alle Kunden-, Benutzer- und Interessengruppen befragt.
- Non-functional Requirements werden bei XP nicht explizit erfasst, sondern fließen direkt oder indirekt in die User Stories ein. Direkte nicht funktionale Anforderungen wie z.B. Oberflächen – Design oder rechtliche Anforderungen werden vom Kunden mit in die User Stories integriert, wohingegen andere Anforderungen erst nach Akzeptanz – Tests oder Produktiveinsatz gefunden werden (Bsp. Performance des Systems) und durch Refactoring umgesetzt werden.
- Ein Review der Anforderungen hinsichtlich Vollständigkeit und Konflikten, wie von klassischen Vorgehensmodellen gefordert, ist bei XP nicht vorhanden. Akzeptanztests des Kunden prüfen die Umsetzung der Requirements und stellen somit eine andere Art der Qualitätssicherung für diese dar.
- Das Problem der Vollständigkeit der Requirements existiert bei XP nicht. Alle gefundenen Anforderungen werden in Releases eingeplant. Fehlende Requirements werden in Produktion und Tests entdeckt und nachträglich in die aktuelle oder folgende Release-Planung integriert.
- Konflikte zwischen Anforderungen treten selten auf, da nur ein Kunde diese erfasst. Treten sie dennoch auf, muss der Kunde sie lösen.
- Die Kommunikation im RE Prozess bei XP ist schneller, da die Schnittstelle Kunde / Analyst fehlt und der Kunde für die Priorisierung der Requirements schnelle Aufwands­schätz­ungen von den Entwicklern erhält.
- XP verwendet für den RE Prozess keine Tools oder Notationen wie die UML. Klassische Ansätze hingegen befürworten Use Cases, Datenflussdiagramme o.ä. (vgl. 3.2).
- Der Kunde ist direkter Ansprechpartner für die Programmierer und verhindert so Fehlentwicklungen aufgrund von missverständlichen Anforderungen.
- Kurze Releases ermöglichen frühes Feedback aus der Produktionsumgebung. Dies führt zu neuen und geänderten Anforderungen.

Insgesamt betrachtet verläuft der RE Prozess bei XP weniger formal, dafür intensiver und mit direkterer Kommunikation als nach klassischen Modellen ab.

4.2.1 Vorteile

XP erfüllt viele Kriterien, die in aktueller Literatur für einen guten RE Prozess genannt werden. Als Hauptrisiken werden im Allgemeinen fehlende oder Design- abhängige Anforderungen und geringe Endbenutzer Beteiligung am RE Prozess genannt. „Perhaps the greatest risk in RE is missing a critical functional or attribute requirement.“ [LAWR01, S.1].

- Benutzerbeteiligung wird vom Chaos Report der Standish Group als Haupt-Faktor für erfolgreiche Projekte genannt (vgl. [CHAOS94, S.4]). Dieses Kriterium wird bei XP durch die intensive Beteiligung des Kunden am RE Prozess erfüllt wenn nicht sogar übertroffen. Vorraussetzung ist allerdings, dass die Endbenutzer des Systems in allen Belangen und kompetent durch den Kunden vertreten werden.
- Weitere Vorteile ergeben sich aus der effektiven Kommunikation, die XP durch kleine Teams in Verbindung mit dem einzelnen Kunden vor Ort erreicht. Sie bietet die Grundlage für frühes Feedback, schnelle Änderungen und damit für vollständige und praxisbewährte Requirements. Der Chaos Report sieht jedoch Änderungen der Anforderungen als einen hohen Projektmisserfolgsfaktor (vgl. [CHAOS94 S.5]). Bei klassischer Software-Entwicklung sind Änderungen sehr teuer, da sie zum Teil umfangreiche Designänderungen nach sich ziehen. Diesen Kritikpunkt widerlegt Kent Beck jedoch mit seiner These, dass die Kosten für Änderungen bei XP durch bestimmte Vorgehensweisen und Techniken nicht mit dem Fortschritt des Projektes exponentiell wachsen (vgl. [BECK00, Kap.3]).
- Schwachpunkte der Kommunikation werden bei XP verringert. Dies wird ermöglicht durch eine geringe Anzahl von Kommunikationsschnittstellen (klassisch: Analyst, Kunde, Entwickler), da bei XP der Kunde direkt mit den Entwicklern zusammenarbeitet.
- Sinnvolle Priorisierung der Requirements wird bei XP durch verschiedene Punkte ermöglicht. Der Kunde bestimmt den Geschäftswert für eine User Story und bekommt schnell eine realistische Aufwandsschätzung von den Programmierern zurück. Zutreffende Schätzungen werden dadurch ermöglicht, dass die Entwickler selbstständig ihre kleinen Teilaufgaben einschätzen und mit ähnlichen Storycards vergleichen können. Das Verhältnis von Geschäftswert zu Aufwand bestimmt die Priorität (vgl. [JEFF01, Kap.8]).
- Neue Anforderungen und Änderungen entstehen durch Funktionstests des Kunden am Integrationsrechner und den frühen produktiven Einsatz des Systems. Hier werden die User Stories frühzeitig qualitativ überprüft und ggf. überarbeitet. Dies verhindert eine Entwicklung, die an den Kundenwünschen vorbeigeht.

Ein weiterer Hauptvorteil des RE Prozesses von XP sind Kosteneinsparungen durch einen sehr geringen Dokumentationsumfang. Requirements werden nur in Form von User Stories auf Karteikarten und teilweise im Code dokumentiert. Der geringe Dokumentationsumfang ist Grundlage für geringe Kosten und die Offenheit gegenüber Änderungen. Dieser Punkt wird allerdings oft an XP, besonders bei Einsatz in umfangreichen Projekten, kritisiert und daher in dem Abschnitt 4.3 „Einsatz von XP bei großen Projekten“ näher betrachtet.

4.2.2 Nachteile

“The agile community claims that they do tackle requirements, but we think that this is poorly performed requirements requiring more validation cycles than necessary and relying too much on individuals.” [EBER01, S.1].

Dieses Zitat von Armin Eberlein zeigt, dass der RE-Prozess von XP in der öffentlichen Diskussion durchaus kritisch betrachtet wird und nicht nur Zustimmung findet. Oft kritisiert wird die Tatsache, dass die Requirements bei XP von oft wenig kompetenten Personen, den Kunden, definiert werden. Sie besitzen keine Erfahrung in dem Prozess und können so wichtige Anforderungen wie Non-Functional Requirements übersehen oder falsch definieren (vgl. [EBER01, S.3]). Dies betrifft Anforderungen, die für den alltäglichen Gebrauch nicht relevant sind oder Hintergrundfunktionen bzw. Vorraussetzungen beschreiben (Beispiel: Sicher­heits- oder rechtliche Anforderungen). Ein weiterer Kritikpunkt lautet, dass alle Systembeteiligten nur von einer Person repräsentiert werden (vgl. [WALL02]). Diese kann bei kom­plexeren Systemen nur selten alle Benutzer- und Interessengruppen vertreten und vollständige, umfassende Anforderungen definieren. Weitere Nachteile sind:

- XP Projekte bekommen hinsichtlich des RE Prozesses Probleme, wenn der Kunde nicht vor Ort präsent sein kann (Bsp.: Kunde ist Manager) und so die Kommunikation stark beeinträchtigt wird. E-Mail und Telefon bieten nicht dieselbe Effektivität wie das direkte Gespräch.
- Teamgeist und Motivation sind sowohl für das Requirements Engineering als auch für das gesamte XP Projekt unabdinglich. Wenn zwischenmenschliche Probleme auftreten, ist die effektive und ehrliche Kommunikation und damit ein Stützpfeiler von XP gefährdet (vgl. [BECK00 Kap.25]) und auch das RE wird darunter leiden.
- Geringe Dokumentation der Anforderungen bedeutet kurzfristig einen kostengünstigen RE Prozess, da der Dokumentationsaufwand entfällt und die Kommunikation basierend auf informalen Story Cards gefördert wird. Langfristig, insbesondere bei umfangreichen Projekten, können aber Probleme auftreten. Nur einfach vorhandene Dokumentationen wie hier die Story Cards können verloren gehen oder wichtige Mitarbeiter verlassen das Projekt. In beiden Fällen ist die Wiederherstellung der Anforderungen aufgrund fehlender elektronischer Speicherung und Dokumentation nur schwer möglich. Somit steigen die Kosten für Änderungen an und können den Vorteil des leichtgewichtigen RE Prozesses wieder aufheben. Ein weiterer Nachteil entsteht bei Aufnahme neuer Mit­glieder in das XP Team. Ohne Dokumentation wird die Einarbeitung schwerer fallen.
- Dem Prozess des RE bei XP fehlt, nach Ansicht einiger Kritiker, eine Gesamtübersicht oder ein Gesamtbild des Systems (vgl. [SCHA01, Kap.2]). Je komplexer das System, desto größer wird die Gefahr, dass der Überblick über alle Story Cards, deren Zusammenhänge, Abhängigkeiten und Über­schnei­dun­gen untereinander, verloren geht. Dies kann zu Fehlentscheidungen, Problemen und letztendlich Fehlentwicklungen führen. Aufgrund von schnellen Feedbacks und Akzeptanztests werden diese bei XP zwar schnell aufgedeckt, jedoch beeinflussen sie Agilität und Kostenvorteil des RE Prozesses negativ.
- XP verzichtet auf die Verwendung von Use Cases, UML und anderen Notationen zur Darstellung der Requirements aufgrund des Pflegeaufwandes. Auch hieraus können sich Nachteile für neue Mitarbeiter und externe Berater besonders nach Abschluss des Projektes ergeben, da Graphiken eine gut erfassbare Übersicht über das System bieten, anhand derer Dokumentationen geschrieben werden könnten.

4.3 Einsatz von XP bei großen Projekten

Wie man bei näherer Betrachtung der Vor- und Nachteile sehen kann, bedeuten einige Eigenschaften von XP bei geringer Projektgröße einen Vorteil für den RE Prozess, entwickeln sich aber zu einem Nachteil, wenn Umfang und Komplexität des Projektes steigen. Insbesondere die Tatsache, dass die Anforderungen von nur einer Person in der Rolle des Kunden definiert und nicht dokumentiert werden, führt zu der Frage nach einer Grenze hinsichtlich Projektgröße oder Verbesserungen der Methodik von XP.

4.3.1 XP Projektgrößen

„Es gibt aber einige Bedingungen, die mit absoluter Gewissheit das Funktionieren von XP verhindern – große Teams, misstrauische Kunden, eine Technologie, die Veränderungen nicht unterstützt.“ [BECK00, S.155].

Dieses Zitat von Kent Beck, dem Erfinder von XP verdeutlicht, dass XP nicht für umfangreiche sondern eher kleine Projekte und Teams konzipiert wurde. Doch ab welcher Teamgröße wird die Grenze überschritten, bei der nach Ansicht von Herrn Beck die Nachteile überwiegen? In dem Buch „Extreme Programming Installed“ werden Teams mit max. 12 Mitarbeitern empfohlen: „XP zielt primär auf objektorientierte Projekte ab, die in überschaubaren Teams mit maximal einem Dutzend Leuten an einem Ort organisiert sind.“ [JEFF01, S.14]. Andere Autoren sprechen von ähnlichen Teamgrößen in einem Bereich von 5 bis 15 Mitarbeitern in einem Zeitraum von bis zu einem Jahr als optimale Projektgröße für XP Projekte (vgl. [CLON03, S.14]). Jedoch wird XP nach ersten statistischen Untersuchungen (Basis: 47 XP Projekte) auch für Projekte weit jenseits dieser optimalen Größe benutzt:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: XP Projektgrößen (vgl. [RUMP02])

Das Balkendiagramm zeigt, dass ein Anteil von 4,4 % der erfassten Projekte bei einer Projektgröße zwischen 15 und 40 Personen XP verwendet hat und diese auch als erfolgreich bewertet wurden. „ The size of the teams, however, was somewhat surprising, as larger XP projects do exist and are considered as Successful.” [RUMP02, S.3]

4.3.2 Probleme

Bei großen XP Projekten treten, wie schon angedeutet, weitere Problemfelder auf. Die zu entwickelnden Systeme werden komplexer und Anforderungen werden von mehreren Benutzergruppen und sonstigen Beteiligten gestellt. Sowohl die Anzahl der Requirements als auch die Wahrscheinlichkeit, dass diese sich widersprechen oder überschneiden, nimmt zu. Größe bedeutet auch meist ein Wachstum des Teams, um die Entwicklungszeit in Grenzen zu halten. Hieraus resultieren besonders für XP eine komplexere Kommunikation und die Notwendigkeit, Management und Struktur des Projektes anzupassen.

4.3.3 Strukturelle Verbesserungen

Um die Probleme und Konflikte aus größeren Projekten zu entschärfen, sollte die Projektstruktur von XP verändert werden. Abhängig vom Projektumfang wächst meist die Komplexität und die Anzahl der Kundengruppen und Actors (à Use Cases) eines Systems. Daher werden neben einer neuen Projektstruktur auch mehrere Vertreter in der Kundenrolle notwendig. “A project with a small number of important clients dramatically changes many of the processes in XP. The development organization (as opposed to development team) must become more involved in defining business value and priorities.” [WALL02, S.1]. Weitere Verbesserungen werden seitens Aufgabenverteilung und Management notwendig. Allerdings gibt es zu dieser Thematik noch keine allgemeine literarische Meinung, da XP in diesen Größenordnungen noch nicht ausreichend verwendet wurde. Daher werden hier nur kurz einzelne Verbesserungsvorschläge verschiedener Autoren vorgestellt (vgl. [RUMP02], [WALL02], [NAWR03], [SCHA01]):

- In das Projektteam sollten mehrere Kunden und Interessentengruppen aufgenommen werden und eventuell das Umfeld des Systems sowie die Anforderungen grob beschrieben werden.
- Das Projektteam sollte nach dem „Teile und Herrsche“ - Prinzip aufgeteilt werden. Unterteilungen können beispielsweise anhand der verschiedenen Kunden oder Funktionalitäten vorgenommen werden. Regelmäßige gruppenübergreifende Meetings, insbesondere Absprache der Kunden, sind notwendig.
- Um die verschiedenen Teams kontrollieren zu können, muss eine Kontrollinstanz mit Koordinationsaufgaben ins Leben gerufen werden, damit die einzelnen Teams nicht kontraproduktiv arbeiten oder Funktionalität doppelt erstellt wird. Zusätzlich wird gruppenübergreifendes Refactoring notwendig.
- Nach Fertigstellung einer Teilaufgabe können Subteams aufgelöst und neu formiert werden, um Wissen zu verteilen.

Insgesamt leidet durch die vorgestellten Maßnahmen die Agilität des XP Ansatzes. Trotzdem bleibt die Grundtendenz bei einer veränderten Projektstruktur erhalten und bietet in gewissem Rahmen gegenüber klassischen Vorgehensmodellen immer noch Vorteile, wie die Offenheit für Änderungen, Kundennähe und Finanzierbarkeit des Projektes.

4.4 Verbesserungsvorschläge

Verbesserungspotentiale für den RE Prozess bei großen Projekten liegen in verschiedenen Bereichen. Der wahrscheinlich sinnvollste Schritt ist die Abwendung von einer einzelnen Person zur Wahrnehmung der Kundenrolle, wie er von verschiedenen Autoren gefordert wird (vgl. [NAWR03, S.4], [WALL02]). Die Rolle des Kunden sollte von mehreren Vertretern der Benutzer, Fachleuten und Experten auf dem jeweiligen Themengebiet besetzt werden. Diese Mehrfachbesetzung bringt verschiedene Vorteile. Die Anforderungen werden aus verschiedenen Gesichtspunkten betrachtet, der Kunde muss kein „allwissendes Genie“ sein und die Aufteilung des Projektes anhand der verschiedenen Kunden wird einfacher. Allerdings müssen die unterschiedlichen Gruppen und Kunden sinnvoll koordiniert werden.

Ein weiterer Vorschlag zur Verbesserung ist die Erweiterung der XP Rollen um die Rolle des Analysten, der zusammen mit dem oder den Kunden die Requirements erfasst, diskutiert und unterstützt. „The customer’s team on this project provided considerable guidance in defining what was built, but they needed assistance from business experts with a broader perspective and traditional software analysts in order to articulate clearly and completely in a set of functional tests what the system needed to do.” [SCHA01, S.4]. Die Autoren der Schrift „Extreme Programming Modified: Embrace Requirements Engineering Practices” erweitern hingegen die Rolle des XP Testers um Aufgaben eines Analysten, da Tester und Kunde aufgrund gemeinsamer Tests oft zusammenarbeiten und der Tester/Analyst den Kunden auch seitens der Requirements und User Stories unterstützen kann (vgl. [NAWR03, S.4]). Vorteile dieser neuen Rolle sind, dass der Analyst seine Erfahrungen aus anderen Projekten mit einbringen kann. Folglich können Fehler schneller behoben und unvollständige Anforderungen ergänzt werden, als der ursprüngliche RE Prozess von XP dies seitens Akzeptanztests und durch produktiven Einsatz ermöglichen würde.

Zusätzlich zu den erweiterten Rollen ist eine Ausweitung der ersten Release Planungsphase hin zu einer einführenden Analyse Phase denkbar, in der Anforderungen ähnlich klassischen Vorgehensmodellen grob aufgenommen und in den folgenden Release Planungen nur noch genauer spezifiziert und verfeinert werden. Dies befürwortet Dr. Grogory Schalliol in Abschnitt Sieben seiner Schrift „Challenges for Analysts on a Large XP Project“ : „Were we to initiate a similar project of this size in the future, I suspect we would devote even more manpower to the production of more traditional artefacts of analysis so that the XP practices we found productive could be employed once again successfully at this scale. “ [SCHA01, S.4]. Allerdings wird durch diesen Schritt die Agilität des RE Prozesses von XP weiter eingeschränkt und das Prinzip der Investitionen zum letztmöglichen Zeitpunkt (vgl. 2.5) untergraben.

Als weiterer Verbesserungsansatz werden die Einführung von (UML- ) Diagrammen und Tools zur Unterstützung des RE Prozesses genannt (vgl. [NAWR03, S.4]). Durch die zusätzliche Verwendung von Diagrammen (Bsp.: ER-, Sequenz- und Aktivitätsdiagramm, u.ä.) lässt sich leichter der Überblick über ein komplexes System halten. RE Tools in Verbindung mit der elektronischen Erfassung und Speicherung von Requirement (Bsp.: Versionsverwaltungssysteme) bzw. User Stories unterstützen den Prozess insbesondere, wenn die in 4.3.3 beschriebenen XP Subteams auf verschiedene Orte verteilt sind oder wenn durch Fluktuation bedingt, sich neue Mitarbeiter in das Projekt einarbeiten müssen.

Die Aufteilung des XP Teams und die Anforderungsdefinition durch mehrere Kunden, Experten und Analysten in unterschiedlichen Teams an verschiedenen Orten erfordert eine koordinierende Instanz.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: XP Projektteams mit koordinierender Instanz (vgl. [RUMP02, S.2])

Sie muss den RE Prozess der verschiedenen Gruppen überwachen und bei Überschneidungen und Konflikten zwischen Requirements einschreiten sowie gewisse Standards einfordern. Durch Reengineering und Koordination von Anforderungen kann der RE Prozess eines großen Projektes hinsichtlich der Effizienz verbessert werden.

Insgesamt verringern die vorgeschlagenen Maßnahmen die Agilität von XP durch erhöhten Koordinationsaufwand und Dokumentation, sind aber notwendig, um gestiegene Komplexität und Gruppenstärke managen zu können. Die hierbei entstehende Dokumentation bietet zusätzliche Vorteile, da sie Grundlage für Wartungsarbeiten, Weiterentwicklungen und das Schreiben einer Benutzerdokumentation liefert.

5 Fazit

Durch die Gegenüberstellung des RE Prozesses von XP mit klassischen Ansätzen sind mehrere Unterschiede und Probleme deutlich geworden. XP wurde für eher kleine Projekte (< 10 Personenjahre) konzipiert und bietet neuartige Ansätze in vielen Bereichen, wie auch dem Umgang mit Requirements. Die Vorteile beim Requirements Engineering liegen hier besonders in der hohen Kundennähe und einem effektiven, durch geringe Dokumentation sehr leichtgewichtigen Prozess. Dieser kann einige grundlegende Probleme, wie im Chaos Report der Standish Group (vgl. [CHAOS99]) genannt, des RE lösen. Hierfür müssen allerdings Projektteam, Kunde und Management gut zusammen arbeiten und harmonieren, da besonders das Requirements Engineering unter zwischenmenschlichen Problemen und Misstrauen leiden kann.

Durch die Vorteile des agilen Prozesses bedingt, entstehen jedoch auch Nachteile, die sich besonders bei großen Projekten auswirken. Ein fehlendes Gesamtbild, geringe Dokumentation und fehlende Darstellung der Anforderungen durch Diagramme, sowie die Abhängigkeit von nur einem Kunden erfordern Anpassungen sowohl an den RE Prozess, als auch an XP selber. Zur Verbesserung werden von verschiedenen Seiten unterschiedliche Möglichkeiten der Strukturierung, Bildung von Subteams, Einführung von Kontrollinstanzen, erhöhte Dokumentation und die Beteiligung mehrerer Kunden genannt.

Der gezielte Einsatz von RE Tools und Use Cases kann den Prozess verbessern und so die Grundlage bilden für sich ändernde Projektteams und die Endbenutzer-, Übergabe- und Wartungsdokumentation für den Kunden.

Für kleine Projekte bietet der XP/RE Prozess beachtenswerte Vorteile hinsichtlich Flexibilität und Kosten, wohingegen die in Kapitel Vier genannten Nachteile kaum ins Gewicht fallen. Ob XP und die Ideen des Requirements Engineering sich insbesondere bei großen Projekten gegen klassische Vorgehensmodelle durchsetzen kann, bleibt fraglich. Die hierbei verringerte Agilität gleicht XP anderen Vorgehensmodellen an, die für umfangreiche Projekte konzipiert wurden. Auf jeden Fall bietet XP eine neue Sicht und alternative Ansätze zum Requirements Engineering Prozess, die diesen auch allgemein beeinflussen werden.

A Literaturverzeichnis

[BALZ00] Balzert, Helmut: Lehrbuch der Software – Technik; 2. Auflage; Spektrum – Akademischer Verlag; 2000

[BECK00] Beck, Kent: Extreme Programming – Das Manifest, Addison Wesley; Deutsche Übersetzung von: Extreme Programming Explained, Embrace Change; 2000

[CHAOS99] The Standish Group International INC.: Chaos – A Recipe for Success; 1999

[CLON03] Clontz, Shane & DeSalle, Dan & Fleck, Dan & Ramsey, Madonna: Extreme Programming: Is it an effective approach to software development?; PDF; 2003

[COCK00] Cockburn, Alistair: Selecting a Project’s Methodology; PDF; 2000

[DUNK01] Duncan, Richard: The Quality of Requirements in Extreme Pro­gram­ming; PDF; 2001

[EBER01] Eberlein, Armin: Agile Requirements Definition: A View from Requirements Engineering; PDF;2001

[JEFF01] Jeffries, John & Anderson, Ann & Hendrickson, Chet: Extreme Programming – Installed; Addison Wesley; 2001

[KULA03] Kulak, Daryl & Guiney, Eamonn: Use Cases – Requirements in Context; Second Edition; Addison Wesley; 2003

[LAWR01] Lawrence, Brian & Wiegers, Karl & Ebert, Christof: The Top Risks of Requirements Engineering; IEEE Software; 2001

[MART00] Martin, Robert C.: Extreme Programming – Development through Dialog; IEEE Software; 2000

[MELL98] Mellis, Werner & Herzwurm, Georg & Stelzer, Dirk: TQM der softwareentwicklung – Mit Prozessbewertung, Kundenorientierung und Change Management zu erfolgreicher Software; Vieweg; 2. Auflage; 1998

[NIKU00] Nikula, Uolevi & Sajaniemi, Joma & Kälviäinen, Heikki: Management View on Current Requirements Engineering Practices in Small and Medium Enterprises; PDF; 2000

[NAWR03] Nawrocki, Jerzy & Jasiński , Michał & Bartosz, Walter & Wojciechowski, Adam: Extreme Programming Modified: Embrace Requirements Engineering Practices; Word – Dokument; 2003

[PART91] Partsch, Helmut: Requirements Engineering; Oldenburg; 1991

[PFLE98] Pleeger, Shari Lawrence: Software Engineering – Theorie and Practice; Prentice Hall; 1998

[POHL 96] Pohl, K.: Process-Centred Requirements Engineering; Research Studies Press; 1996

[ROBE99] Robertson, Susanne & Robertson, James: Mastering the Requirements Process; Addison Wesley; 1999

[RUMP02] Rumpe, Bernard & Schröder, Astrid: Quantitative Survey on Extreme Programming Projects; PDF; 2002

[SCHA01] Dr. Schalliol, Gregory: Challenges for Analysts on a Large XP Project; PDF; 2001

[TOMA02] Tomayko, James E.: Engineering of Unstable Requirements Using Agile Methods; PDF; 2002

B Glossar

Notation Definierter Zeichensatz zur Darstellung eines Konzeptes. Beispiel: UML

Pattern Ein Pattern ist ein „Lösungsmuster“ ,d.h. eine Sammlung von Klassen und deren Verantwortlichkeiten zur Lösung eines Problems, welches sich in der Praxis bewährt hat.

Requirement Anforderung (à siehe Kap. 1.1.1)

Story Card Siehe à User Story

User Story Die User Story ist eine vom Kunden definierte und auf einer Storycard festgehaltene Anforderung, die nach Diskussion und Bewertung der Programmierer umgesetzt wird.

Use Case Use Cases beschreiben Interaktionen zwischen Benutzern und Softwaresystem, wodurch ein bestimmtes Ziel erreicht werden soll.

C Anhang

Abbildung in dieser Leseprobe nicht enthalten

Abb. 5: Am RE Prozess beteiligte Rollen

Erklärung

Ich versichere hiermit, dass ich meine Studienarbeit mit dem Thema

Requirements Engineering bei Extreme Programming

selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Alle wörtlichen Zitate in der Arbeit wurden durch Anführungszeichen eindeutig gekennzeichnet.

Abbildung in dieser Leseprobe nicht enthalten