Beschreibung und Analyse von Feature Driven Development

Aus Winfwiki

Fallstudienarbeit
Hochschule:	Hochschule für Oekonomie & Management
Standort:	Düsseldorf
Studiengang:	Bachelor Wirtschaftsinformatik
Veranstaltung:	Fallstudie / Wissenschaftliches Arbeiten
Betreuer:	Prof._Dr._Uwe_Kern
Typ:	Fallstudienarbeit
Themengebiet:	Agile Softwareentwicklung
Autor(en):	Andre Esser, Sven Achtelik, Nikolai Ernst
Studienzeitmodell:	Tagesstudium
Semesterbezeichnung:	SS11
Studiensemester:	2
Bearbeitungsstatus:	begutachtet
Prüfungstermin:
Abgabetermin:

Inhaltsverzeichnis 1 Abkürzungsverzeichnis 2 Abbildungsverzeichnis 3 Tabellenverzeichnis 4 Einleitung 4.1 Aufgabenstellung 4.2 Zielsetzung 4.3 Aufbau 5 Grundlagen 5.1 Entstehung 5.2 Feature 6 Beschreibung 6.1 Rollen 6.1.1 Project Manager 6.1.2 Chief Architect 6.1.3 Development Manager 6.1.4 Chief Programmers 6.1.5 Class Owners 6.1.6 Domain Experts 6.2 Prozesse 6.2.1 Develop an Overall Model 6.2.2 Build a Features List 6.2.3 Plan By Feature 6.2.4 Design By Feature 6.2.5 Build By Feature 6.3 Best Practices 6.3.1 Domain Object Modeling 6.3.1.1 Modeling in Color 6.3.1.2 Developing by Feature 6.3.2 Class (Code) Ownership 6.3.3 Inspections 6.3.4 Feature Team 6.3.5 Regular Build Schedule 6.4 Milestones und Planfortschrittskontrollen 6.4.1 Milestones 6.4.2 Parking Lot Charts 6.4.3 Reporting 7 Analyse 7.1 Bewertungskriterien 7.1.1 Personalaufwand 7.1.2 Kommunikationsaufwand 7.1.3 Regelwerk 7.1.4 Kosten 7.1.5 Erfolgschancen 7.1.6 Kundenzufriedenheit 7.2 Bewertung 7.2.1 Personalaufwand 7.2.2 Kommunikationsaufwand 7.2.3 Regelwerk 7.2.4 Kosten 7.2.5 Erfolgschancen 7.2.6 Kundenzufriedenheit 7.3 Gesamtergebnis 8 Schlussbetrachtung 9 Anhang 9.1 Fußnoten 9.2 Quellen

1 Abkürzungsverzeichnis

Abkürzung	Bedeutung
FDD	Feature Driven Development
XP	eXtreme Programming
MiC	Modelling in Colour

2 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
1	Rollenhierarchie in FDD
2	Prozessablauf in FDD
3	Parking Lot Chart

3 Tabellenverzeichnis

Tab.-Nr.	Tabelle
1	Gesamtergebnis

4 Einleitung

4.1 Aufgabenstellung

In den vergangen Jahren hat die agile Softwareentwicklung immer mehr an Bedeutung gewonnen. Die Entwicklung nach dem konservativen Wasserfall-Modell wurde in vielen Unternehmen durch die agile Softwareentwicklung abgelöst. Dies ist darauf zurückzuführen, dass das die Entwicklung nach dem Wasserfall-Model große Risiken mit sich bringt ^[1]. Die Entwicklung wird hier in sieben Phasen unterteilt, wobei eine streng sequentielle Abarbeitung vorgesehen ist. In der Praxis ist es jedoch häufig so, dass Anforderungen zu Beginn des Projektes noch unklar sind und sich somit im späteren Verlauf noch ändern. Ein Rücksprung in vorherige Phasen ist zwar möglich, hierbei bleibt der Rücksprung jedoch auf die zuletzt vorangegangene Phase beschränkt ^[2]. Die agile Softwareentwicklung versucht dieses Problem durch Iterative Prozesse zu lösen, die jeweils weitestgehend alle Phasen des Wasserfall-Modells enthalten. Eine dieser agilen Methoden ist FDD (Feature Driven Development). Das Konzept dieser Methode soll im Rahmen dieser Arbeit beschrieben und anschließend hinsichtlich verschiedener Bewertungskriterien analysiert werden.

4.2 Zielsetzung

Neben agilen Softwareentwicklungsmethoden, wie SCRUM und XP (eXtreme Programming), ist FDD in der Praxis relativ gering verbreitet. Diese Arbeit wird FDD unter den Aspekten Personalaufwand, Kommunikationsaufwand, Regelwerk, Kosten, Erfolgschancen und Kundenzufriedenheit betrachten, um zu ermitteln, wo Stärken und eventuelle Schwächen der Methode liegen, die gegebenenfalls für die geringe Verbreitung in der Praxis verantwortlich sind. Zusätzlich soll die Frage, für welche Art von Projekten sich FDD am besten eignet, beantwortet werden.

4.3 Aufbau

Der erste Teil dieser Arbeit beschäftigt sich mit den Grundlagen von FDD. Dies beinhaltet die Entstehung, sowie der für das Verständnis der weiteren Arbeit relevanten Definition des Begriffs „Feature“. Darauf folgt eine Beschreibung des Konzepts von FDD. Hier wird zunächst das Hierarchiesystem präsentiert, sowie die Aufgaben der einzelnen Rollen innerhalb eines FDD-Projektes erläutert. Anschließend wird die Prozessstruktur dargelegt, worauf eine detaillierte Beschreibung der einzelnen Prozesse und ihrer beinhaltenden Tasks folgt. Nachfolgend werden die „Best Practices“, die sich in der Anwendung von FDD bewährt haben aufgezeigt. Zum Abschluss der Beschreibung des Konzepts werden das Reporting, sowie die im Rahmen eines Projektes definierten Milestones betrachtet. Der nächste Teil der Arbeit beschäftigt sich mit der Analyse hinsichtlich sieben unterschiedlicher Bewertungskriterien. Dazu werden zunächst die sieben Kriterien definiert und anschließend findet die Bewertung statt. Daraufhin werden die Gesamtergebnisse der sieben Analysen präsentiert. Abschließend folgt die Schlussbetrachtung der Arbeit.

5 Grundlagen

5.1 Entstehung

Feature Driven Development entstand in den Jahren 1997 und 1998 im Rahmen eines großen Software-Entwicklungsprojektes für eine Singapurer Bank. Die Leitung des Projektes unterstand Jeff DeLuca (Projektleiter) und die Leitung der Modellierung hatte Peter Coad (Chefarchitekt) übernommen.^[3]

Aufgrund des knappen zeitlichen Rahmens und der begrenzten Ressourcen schien das Projekt mit keiner der bisher bekannten Methoden zur Softwarentwicklung realisierbar. Daher entwickelte Jeff DeLuca mit Hilfe von Peter Coad eine neue Methode, unter deren Anwendung es möglich wurde, ein System mit 2000 Features mit 50 Entwicklern innerhalb von 15 Monaten termin- und budgtetgerecht fertigzustellen: Feature Driven Development. In diesem Zuge entstand auch die heute häufig genutzte Modellierungstechnik "Modelling in Color". Beide Methoden wurden erstmals in dem 1999 erschienenen Buch "Java Modeling in Color with UML: Enterprise Components and Process" von Peter Coad, Eric Lefebvre und Jeff DeLuca veröffentlicht. ^[4]

5.2 Feature

Features sind fein granulare (Programm-)Funktionen, die soweit zerlegt wurden, dass sie innerhalb von maximal zwei Wochen realisierbar sind (Planung des Designs und Erstellung des Codes ^[5] ). In der Praxis sind Features meist soweit zerlegt worden, dass sie innerhalb weniger Tage realisiert werden können und der maximale Zeitrahmen nur sehr selten ausgeschöpft werden muss. Allerdings ist zu beachten, dass die Zerlegung nicht bis auf das Niveau der Getter- und Setter reichen soll. Alle Features folgen einer einheitlichen, dem Kunden verständlichen Namenskonvention nach dem Schema <Aktion> <Ergebnis> <Objekt>, beispielsweise <Berechne>(das)<Gesamtergebnis>(eines)<Verkauf>(s).^[6]

Das Buch "A Practical Guide to Feature-Driven Development" aus dem Jahre 2002 von Stephen R. Palmer und John M. Felsing beschreibt Features als die einzelnen Schritte, die zum Erreichen der Geschäftsaktivität (Feature Set) in einem Geschäftsbereich (Major Feature Set) erforderlich sind.^[7] Diese Art der Staffelung orientiert sich an den dem Kunden vertrauten Begrifflichkeiten und ermöglicht ihm so, priorisierend auf den Entwicklungsprozess Einfluss zu nehmen.^[8] Außerdem kann der Kunde anhand der geplanten Features frühzeitig überprüfen, ob diese den Anforderungen gerecht werden.^[9]

Der Fortschritt des Projektes kann anhand der fertiggestellten Features bemessen werden.^[10] Da einzelne Features spätestens innerhalb von zwei Wochen fertiggestellt werden, ist so ein kontinuierlicher Fortschritt des Projektes zu beobachten.^[11]

6 Beschreibung

6.1 Rollen

6.1.1 Project Manager

Der Projektleiter (Project Manager) ist der Hauptverantwortliche für das gesamte Projekt. In dieser Rolle verfügt er innerhalb des Projektes über die absolute Entscheidungsgewalt bezüglich Gestaltung, Ablaufplanung und Einsatz der finanziellen, personellen oder sachlichen Ressourcen.

Die Aufgabe des Projektleiters ist in erster Linie die Schaffung und Aufrechterhaltung einer funktionierenden Logistik für das oder die Projektteams. Er soll unterstützend wirken, Störungen der Projektteams verhindern und administrative oder finanzielle Hindernisse beseitigen. Darüber hinaus obliegt ihm das Reporting über die Projektfortschritte.^[12]

6.1.2 Chief Architect

Der Chefarchitekt (Chief Architect) ist innerhalb des Projektes die oberste Instanz in allen Fragen des Designs, nimmt bei diesbezüglichen Konflikten der Chefprogrammierer untereinander jedoch bevorzugt eine Schlichterrolle ein.

Die Rolle des Chefarchitekten erfordert ein tiefes technisches Verständnis, umfassende Erfahrungen und sehr hohe Kompetenz in der Prozessmodellierung. Er veranstaltet und führt die Workshops, in denen das Team das Design entwirft und kümmert sich um technische Probleme oder Hindernisse.

Bei Projekten mit komplexer technischer Struktur und komplexen Problemstellungen kann die Rolle in Domain Architect und Technical Architect aufgeteilt werden. ^[12]

6.1.3 Development Manager

Die Rolle des Entwicklungsleiters (Development Manager) umfasst die Leitung und Koordination der Entwicklungsaktivitäten. Dies beinhaltet auch die Verwaltung der verfügbaren technischen Ressourcen, beispielsweise die Verfügung über Spezial-Hardware oder die Zuteilung von Rechenzeit. Sein Aufgabenschwerpunkt ist die Vermeidung von Engpässen und die Schlichtung von Konflikten bezüglich der technischen Ressourcen.

In Projekten mit passenden Rahmenbedingungen können der Projektleiter oder der Chefarchitekt diese Rolle in Personalunion übernehmen.^[13]

6.1.4 Chief Programmers

Die Rolle von Chefprogrammierern (Chief Programmers) bekleiden sehr erfahrene Entwickler, die alle Stufen des Entwicklungsprozesses gut kennen. Chefprogrammierer leiten Entwicklerteams mit einer Personenstärke von drei bis sechs Entwicklern und steuern dabei die Analyse-, Design-, und Entwicklungsprozesse. Sie tragen die Verantwortung für die termingerechte Fertigstellung der beauftragten Features und deren Qualität.^[13]

Chefprogrammierer kooperieren mit anderen Chefprogrammierern in technischen Angelegenheiten oder bei der Lösung von Ressourcen-Konflikten. Sie sollten über die nötigen Soft-Skills verfügen, um ein vertrauens- und respektvolles Verhältnis zu Managern und Entwicklungskollegen zu pflegen, sowie das Team zu unterstützen und motivieren, erfolgreich zu sein.^[13]

6.1.5 Class Owners

Als Class Owner werden die eigentlichen Entwickler bezeichnet. Sie arbeiten in drei bis sechs Personen starken Teams unter der Leitung eines Chief Programmers. Ihre Aufgaben umfassen das Design, Coding und Testen der Features, sowie die Erstellung der zugehörigen Dokumentationen.

Die Rolle wird mit talentierten Entwicklern besetzt, für welche neben Leistungswillen auch eine gewisse Aufstiegsorientierung vorteilhaft ist. Erfahrung ist erwünscht, aber bei einem vielversprechenden Talent nicht zwingend notwendig.^[13]

6.1.6 Domain Experts

Als Fachexperten (Domain Experts) werden die Spezialisten der Fachbereiche auf Kundenseite bezeichnet. Sie sind selbst künftige (End-)Anwender des entstehenden Systems, gehören dem Management an und verfügen über präzise Kenntnisse der betroffenen Prozessabläufe. Ihre erfolgreiche Mitarbeit und ihr Wissen sind entscheidend für die Qualität des zu entwickelnden Systems und damit für den Projekterfolg als solchen. Sie beschreiben und erklären den Teams und Entwicklern die Anforderungen des künftigen Systems auf allen Ebenen bis ins Detail. Daher sollten sie über gute Fähigkeiten der Wissensvermittlung verfügen und sich möglichst persönlich für das Projekt begeistern.^[14]

6.2 Prozesse

Ein FDD-Projekt beginnt mit der Erstellung eines Gesamtmodells der Domäne. Dieses Gesamtmodell besteht in der Regel aus Klassendiagrammen für jeden Fachbereich der Domäne. Nach der Erstellung dieses Modells geht das Projekt in den zweiten Prozess über, hier wird die Domäne soweit zerlegt bis einzelne Features zu identifizieren sind. Diese werden anschließend in einer Liste festgehalten und es wird mit dem letzten Prozess der Planungsphase begonnen. In diesem Prozess werden die Entwicklungsreihenfolge der Features und die Verantwortlichkeiten innerhalb des Projektes festgelegt. Mit dem Abschluss dieses Prozesses ist die Planungsphase absolviert, darauf folgt die Entwicklungsphase. In dieser Phase werden die Prozesse #4 und #5 für jedes Feature iterativ wiederholt. Prozess #4 beinhaltet die Erstellung des Designs für das aktuelle Feature, Prozess #5 die Erstellung der notwendigen Klasseninhalte und die Integration in das System.

6.2.1 Develop an Overall Model

Eingangskriterium: Die Rollen der Fachexperten, Chefprogrammierer und des Chefarchitekten wurden besetzt.

Ziel dieses Prozesses ist ein Gesamtmodell zu entwickeln , welches ein Modell jeden Fachbereiches enthält. Dazu werden die Entwickler zuerst mit den Anforderungen und Eigenarten der einzelnen Fachbereiche vertraut gemacht, aus denen sich das Gesamtmodell zusammensetzt. Die Leitung übernimmt der Chefarchitekt.^[15]

Tasks:

Nr	Taskname	Beteiligte	Optionalität

1	Form the Modelling Team	Projektleiter	Erforderlich

Der Projektleiter stellt das Modellierungsteam zusammen, welches sich aus Entwicklern und Experten der betroffenen Fachbereiche zusammensetzt. Hauptakteure sind Fachexperten und Chefprogrammierer, jedoch werden nach einem Rotationsprinzip auch andere Mitglieder der Entwicklungsstäbe zu den Teamsitzungen hinzugezogen, damit jeder an dem Prozess partizipieren kann.^[15]

2	Domain Walk-through	Modellierungsteam	Erforderlich

Fachexperten stellen ihr Fachgebiet dem Modellierungsteam vor.^[15]

3	Study Documents	Modellierungsteam	Optional

Hier werden eventuell vorhandene Dokumente analysiert, z.B. Anforderungs- und Referenzdokumente, Objektmodelle, Benutzer-Richtlinien, funktionale Anforderungen.^[15]

4	Develop the Model	Modellierungsteam in kleinen Gruppen	Erforderlich

Das Modellierungsteam teilt sich in kleine Gruppen von 2-3 Personen auf, welche jeweils ein Modell des Fachbereichs in Form eines Klassen- bzw. Sequenzdiagramms erarbeiten. Diese Modelle werden dem gesamten Modellierungsteam vorgestellt, welches entweder ein Modell akzeptiert oder auf Basis der bisherigen ein neues Modell entwickelt.^[15]

5	Refine the Overall Object Model	Chefarchitekt, Modellierungsteam	Erforderlich

Die bisher erzielten Fortschritte des Modellierungsteams werden im Gesamtmodell abgebildet.^[16]

6	Write the Model Notes	Chefarchitekt, Chefprogammierer	Erforderlich

Es werden Notizen zu schwer verständlichen Modellteilen gemacht und signifikante Modellierungsalternativen dokumentiert, um die Nachvollziehbarkeit bestimmter Designentscheidungen auch in der Zukunft zu gewährleisten.^[17]

Verification:

V	In- and External Assessment	Modellierungsteam, Business	Erforderlich

Das Modellierungsteam bewertet die Fortschritte von Modellen und Designs hinsichtlich der Zielerfüllung (Internal Assessment). Zusätzlich kann eine entsprechende Bewertung durch die zukünftigen Benutzer eingefordert werden (External Assessment).^[18]

Ausgangskriterium: Es existiert ein vollständiges Objektmodell für die Zieldomäne.

Das Objektmodell umfasst dabei Diagramme aller Klassen der einzelnen Fachgebiete und die Beziehungen dieser Klassen untereinander. Die Klassen selbst beinhalten die bis zu diesem Zeitpunkt identifizierten Methoden und deren Attribute. Eventuell vorhandene Sequenzdiagramme sind ebenso hinzuzufügen wie die unter Task 6 entstandenen Dokumentationen.^[19]

6.2.2 Build a Features List

Eingangskriterium: Die Rollen der Fachexperten, Chefprogrammierer und des Chefarchitekten wurden besetzt.

Ziel des Prozesses ist, eine fein granulare Liste der benötigten Features zur Erfüllung der Anforderungen des Endproduktes zu erhalten. ^[6]

Tasks:

Nr	Taskname	Beteiligte	Optionalität

1	Form the Feature List Team	Projektleiter, Entwicklungsleiter	Erforderlich

Das Feature List Team wird in der Regel aus den Chefprogrammierern gebildet.^[6]

2	Build the Feature List	Feature List Team	Erforderlich

Ausgehend von einer Aufteilung der Problemdomäne in Anwendungsbereiche, werden diese nun weiter zerlegt in Geschäftsbereiche (Major Feature Sets), Geschäftsaktivitäten (Feature Sets) und die zur Erfüllung der Geschäftsaktivitäten benötigten einzelnen Funktionen (Features). Entsprechend der Namenskonvention sollten die Features als Liste in der Form <action> <result> <object> vorliegen.^[6]

Verification:

V	In- and External Assessment	Feature List Team, Business	Erforderlich

Die interne Bewertung (Internal Assessment) erfolgt schon während der Erfüllung von Task 2 durch die aktive Teilnahme von Mitgliedern des Modellierungsteams. Falls erforderlich, kann eine zusätzliche Beurteilung der Fachexperten des Modellierungsteams oder der zukünftigen Benutzer ersucht werden (External Assessment).^[20]

Ausgangskriterium: Es existiert eine fertige Featureliste.

Eine fertige Featureliste beinhaltet die Major Feature Sets, Feature Sets und alle darin enthaltenen Features, die hierarchisch kategorisiert aufgeführt werden.^[20]

6.2.3 Plan By Feature

Eingangskriterium: Es existiert eine fertige Featureliste.

Ziel des Prozesses ist die Erstellung eines vollständigen Entwicklungsplans, in dem Fälligkeiten (Fertigstellungstermine) und Verantwortlichkeiten (Ownerships) festgelegt sind.^[21]

Tasks:

Nr	Taskname	Beteiligte	Optionalität

1	Form the Planning Team	Projektleiter	Erforderlich

Dieses Team setzt sich aus dem Projektleiter, dem Entwicklungsleiter und den Chefprogrammierern zusammen.^[22]

2	Determine the Development Sequence	Planning Team	Erforderlich

Es wird für jedes Feature Set ein Fertigstellungstermin nach dem Schema Monat/Jahr vergeben. Kriterien hierfür sind eine ausgewogene Arbeitsbelastung der einzelnen Entwicklerteams, die Abhängigkeiten der Features (resultierend aus den Abhängigkeiten der beteiligten Klassen untereinander), die Komplexität der Features und externe Milestones wie Beta Releases oder Previews.^[22]

3	Assign Business Activities to Chief Programmers	Planning Team	Erforderlich

Ähnlich der Class Ownership werden die Feature Sets einzelnen Chefprogrammierern zugeteilt. Zugrundeliegende Kriterien sind die Entwicklungsreihenfolge, Abhängigkeiten und Komplexität der Features sowie eine ausgewogene Arbeitsbelastung der Class Owner.^[22]

4	Assign Classes to Developers	Planning Team	Erforderlich

Einzelnen Entwicklern wird die Class Ownership für die einzelnen Klassen zugewiesen. Kriterien hierfür sind die Arbeitsbelastung der Entwickler, die Komplexität und Verwendungshäufigkeit der Klassen und die Entwicklungsreihenfolge. ^[23]

Verification:

V	Self Assessment	Planning Team	Erforderlich

Da Planung eine teambasierte Tätigkeit ist, wird die Selbstkontrolle durch eine aktive Teilnahme von Chefprogrammierern, Entwicklungsleiter und Projektleiter erreicht.^[23]

Ausgangskriterium: Es existiert ein vollständiger Entwicklungsplan.

Ein vollständiger Entwicklungsplan muss folgende Inhalte aufweisen:^[23]

1. Feature Sets mit Fälligkeit (Monat/Jahr) und verantwortlichen Chefprogrammierern.
2. Major Feature Sets mit Fälligkeit (Abhängig von der Fälligkeit der enthaltenen Feature Sets).
3. Liste aller Klassen und ihrer Besitzer (Class Owner List).

6.2.4 Design By Feature

Eingangskriterium: Erfolgreicher Abschluß der Planungsphase (Prozesse 5.2.1 bis 5.2.3).^[24]

Ziel des Prozesses ist die Erstellung eines vollständigen und geprüften Designpaketes.^[25]

Tasks:

Nr	Taskname	Beteiligte	Optionalität

1	Form Feature Team	Chefprogrammierer	Erforderlich

Die Chefprogrammierer bilden je ein Feature Team unter Berücksichtigung der voraussichtlich an den Features beteiligten Klassen und deren Besitzer.^[24]

2	Domain Walk-through	Fachexperten	Optional

Dieser Task kann optional ausgeführt werden, wenn ein Feature interaktiv oder sehr komplex ist. Bei Bedarf erläutern die Fachexperten dem Feature Team detailliert die für das Feature relevanten Teile des Fachbereichs.^[24]

3	Study the Referenced Documents	Feature Team	Optional

Dieser Task kann optional ausgeführt werden, wenn ein Feature interaktiv oder sehr komplex ist. Bei Bedarf studiert das Feature Team alle für das Feature relevanten und verfügbaren Dokumente.^[24]

4	Develop the Sequence Diagram(s)	Feature Team	Required

Das Feature Team entwickelt das bzw. die benötigte(n) Sequenzdiagramm(e).^[24]

5	Refine the Object Model	Chefprogrammierer	Erforderlich

Das Domain Object Model wird durch den Chefprogrammierer bezüglich der Ergebnisse von Task 4 (zusätzliche oder veränderte Klassen, Methoden, Attribute) aktualisiert.^[24]

6	Write Class and Method Prologues	Feature Team	Erforderlich

Die Class Owner schreiben die Klassen- und Methodenprologe (Parametertypen, Returnvaluetypen, Exceptions und Messages).^[25]

Verification:

V	Design Inspection	Feature Team	Erforderlich

Das Feature Team unterzieht das gesamte Designpaket unter Beteiligung des Chefprogrammierers einer Inspektion. Bei hoher Komplexität kann der Chefprogrammierer auch andere Projektmitglieder beteiligen.^[25]

Ausgangskriterium: Es existiert ein vollständiges und überprüftes Designpaket, bestehend aus folgenden Positionen:^[25]

1. Dokumentation (für Dritte verständlich)
2. Verfügbare Anforderungsberichte
3. Sequenzdiagramm(e)
4. Aktualisiertes Domain Object Model
5. Eventuell verfügbare Alternative Designs
6. Klassen- und Methodenprologe

6.2.5 Build By Feature

Eingangskriterium: Erfolgreicher Abschluss des Prozesses Design by Feature. ^[26]

Tasks:

Nr	Taskname	Beteiligte	Optionalität

1	Implement Classes and Methods	Feature Team	Erforderlich

Die Class Owner implementieren die zur Erfüllung der Anforderungen des Features erforderlichen Inhalte der Klassen.^[26]

2	Code Inspection	Feature Team	Erforderlich

Das Feature Team prüft den entwickelten Code. Abhängig von der Komplexität kann der Chefprogrammierer zusätzliche Projektmitarbeiter hinzuziehen. ^[26]

3	Unit Test	Feature Team	Erforderlich

Die Class Owner testen den entwickelten Code auf Fehler und auf Erfüllung der Anforderungen.^[26]

4	Promote to the Build	Chefprogrammierer, Feature Team	Erforderlich

Nach bestandener Codeinspektion und erfolgreichen Unittests dürfen die Klassen in den Build implementiert werden. Als Integrationspunkt der erstellten Klassen dient der Chefprogrammierer.^[26] Das Feature ist nach dem nächsten Durchlauf des Build-Prozesses in der aktuellen Version des Produktes verfügbar.^[27]

Verification:

V	Code Inspection and Unit Test	Chefprogrammierer, Feature Team	Required

Der Prozess gilt durch den erfolgreichen Abschluss der Tasks 2 und 3 als überprüft.^[26]

Ausgangskriterium: Ein geplantes Feature wurde erfolgreich fertiggestellt.^[28]

6.3 Best Practices

6.3.1 Domain Object Modeling

Im Zuge des "Domain Object Modeling" werden Klassendiagramme für alle Bereiche der Domäne erstellt, welche alle maßgeblichen Typen von Objekten und deren Beziehungen untereinander darstellen.^[29] In der Regel werden diese durch Sequenzdiagramme ergänzt, die eine Beschreibung der Interaktion der Objekte untereinander beinhalten.^[30]. Palmer und Felsing ziehen den Vergleich mit einer Straßenkarte: "[...]a domain object model is like a road map that guides the journey;"^[31] Damit ist gemeint, dass sich der gesamte Entwicklungsprozess an dem Domain Object Model orientiert und ausrichtet, da es einen Gesamtüberblick über die Domäne ermöglicht und alle Vorgaben bezüglich der zu implementierenden Klassen, Methoden und Relationen enthält.^[29]

6.3.1.1 Modeling in Color

Mit MiC (Modeling in Color) wird eine Methode zur Modellierung bezeichnet, die üblicherweise UML (Unified Markup Language) als Modellierungssprache verwendet und im Rahmen des Domain Object Modelings zur Anwendung kommt. Man unterscheidet hier vier unterschiedliche, von der Domäne unabhängige Objekttypen (Archeypen), die jeweils in unterschiedlichen Farben dargestellt werden:

• (Pink) Moment-Interval - Zeitraum oder Zeitpunkt.
• (Gelb) Role - Rolle, die von einem PartyPlaceThing-Objekt eingenommen wird.
• (Blau) Description - Beschreibung, ähnlich einem Katalogeintrag.
• (Grün) PartyPlaceThing - Partei, Ort oder Ding.

MiC enthält auch Vorgaben für die Relationen von Archetypen untereinander, sowie typische Attribute und Methoden für jeden Archetypen (beispielsweise das Date-Attribut für Moment-Interval-Objekte). ^[32]

Üblicherweise kommen hierbei keine softwaregestützten Modellierungstools zum Einsatz, sondern es werden farbige Post-It's und Flipcharts verwendet. ^[33]

6.3.1.2 Developing by Feature

"Developing by Feature" bezeichnet die Zerlegung einer Domäne in feingranulare Features und hat in Hinsicht auf den Entwurf eines Domain Object Models den großen Vorteil, dass die identifizierten Features sehr genauen Aufschluss darüber geben, welche Klassen benötigt werden und welche Attribute und Methoden diese enthalten müssen. Diese Vorgehensweise ist im Vergeleich zu Top-Down-Methoden sehr effizient, weil so keine unbenutzten Klassen und Methoden entstehen können.^[34] Die Namenskonvention für Features trägt dazu bei, dass sich die zu implementierenden Methoden leicht erkennen lassen: Das Feature "Berechne das Gesamtergebnis eines Verkaufs" weist z.B. auf eine benötigte Methode berechneGesamtergebnis() in der Verkaufsklasse hin.^[35] Die bei der Planung, Entwicklung und Implementierung gewonnenen Erkenntnisse über Features und die Beziehungen der zugehörigen Klassen untereinander fließen wiederum in das Domain Object Model ein, welches auf diese Weise ständig iterativ erweitert und angepasst wird.^[24]

6.3.2 Class (Code) Ownership

Die Code Ownership beschreibt die Zuweisung der Verantwortung für bestimmte Codegruppierungen an einzelne Entwickler. Das Klassen-Konzept wird heute von allen gängigen objektorientierten Programmiersprachen zur Realisierung von Kapselung verwendet, daher wird meist von Class Ownership gesprochen. Einzelne Entwickler können die Class Ownership für mehrere Klassen besitzen, aber jede Klasse besitzt nur genau einen Class Owner. ^[36]

6.3.3 Inspections

Es werden regelmäßige Inspektionen (Prüfungen, Untersuchungen) durchgeführt, um die Qualität von Code und Design zu gewährleisten. ^[37] Diese sind ein fester (benötigter) Bestandteil der Taskvorgaben von FDD ^[38] und sollen in erster Linie der Vermeidung bzw. frühzeitigen Korrektur von Fehlern dienen. Allerdings tritt hierbei auch der erwünschte Seiteneffekt auf, dass die Entwickler Einblicke in den Code der jeweiligen Class Owner erhalten und auf diese Weise ein Wissenstransfer der Entwickler untereinander stattfindet. Besonders unerfahrene Entwickler können so Techniken erfahrener Entwickler erlernen, was einen Mehrwert für das gesamte Projekt darstellt. Des Weiteren werden bei Inspektionen Problembereiche identifizierbar, die anschließend einzelnen Prozesseabläufen oder Entwicklern zugeordnet weren können.^[39]

6.3.4 Feature Team

Ein Feature Team ist ein für jedes Feature dynamisch gebildetes Team, bestehend aus den Class Ownern der beteiligten Klassen. Feature Teams haben meist drei bis sechs Mitglieder und werden von einem Chefprogrammierer geleitet. Chefprogrammierer sind in der Regel selbst Class Owner und können als solche auch Mitglieder in anderen Feature Teams und damit einem anderen Chefprogrammierern unterstellt sein. Abhängig vom Grad ihrer Auslastung können Entwickler auch Mitglied in mehreren Feature Teams sein.^[40]

6.3.5 Regular Build Schedule

Der Build-Prozess wird in regelmäßigen Abständen durchlaufen und erzeugt dabei ein System, d.h. eine vorläufige Version des Endproduktes mit allen bis dahin fertiggestellten Features. In welchen Intervallen eine neue Version des Systems generiert wird, entscheidet jedes Projektteam für sich selbst, allerdings sind die Intervalle maßgeblich von der Laufzeit des eigentlichen Build-Prozesses abhängig. Durch einen formalen Build-Prozess wird die Konsistenz des Systems gewährleistet und Fehler, die aus der Implementierung bestimmter Klasseninhalte resultieren, können frühzeitig erkannt und beseitigt werden. Weiterhin steht nach dem Durchlauf eines Build-Prozesses ein aktuelles System für Demonstrations- und Präsentationszwecke zur Verfügung.^[41]

6.4 Milestones und Planfortschrittskontrollen

6.4.1 Milestones

Im FDD existieren sechs Meilensteine (Milestones) je Feature, wobei die ersten drei im Prozess "Design by Feature" die letzten drei im Prozess "Build by Feature" angesiedelt sind.^[42]

Design by Feature

1. Domain Walk-through

Der Meilenstein ist erreicht, wenn der Task "Domain Walk-through" und bei Bedarf der Task "Study the referenced Documents" erfolgreich abgeschlossen wurden.

2. Design

Der Meilenstein ist erreicht, wenn die Tasks "Develop the Sequence Diagram(s)", "Refine the Object Model" und "Write Class and Method Prologues" erfolgreich abgeschlossen wurden.

3. Design Inspection

Der Meilenstein ist erreicht, wenn der Verification-Task "Design Inspection" erfolgreich abgeschlossen wurde.

Build by Feature

1. Code

Der Meilenstein ist erreicht, wenn die Tasks "Implement Classes and Methods" und "Unit Test" erfolgreich abgeschlossen wurden.

2. Code Inspection

Der Meilenstein ist erreicht, wenn die Tasks "Code Inspection" und "Unit Test" erfolgreich abgeschlossen wurden.

3. Promote to Build

Der Meilenstein ist erreicht, wenn der Task "Promote to the Build" erfolgreich abgeschlossen wurde.

Die Gewichtung der einzelnen Meilensteine wird von der tatsächlichen Dauer im Einzelfall abhängig gemacht. Als Richtwert wird folgende Gewichtung vorgeschlagen:

• Domain Walk-through: 01%
• Design: 40%
• Design Inspection: 03%
• Code: 45%
• Code Inspection: 10%
• Promote to Build: 01%

Die Gewichtungen sollten in Absprache mit Kunden, Sponsoren und Management vorgenommen und während der laufenden Entwicklung nicht mehr verändert werden, da hierbei das gesamte Reporting beeinflusst wird. ^[43]

6.4.2 Parking Lot Charts

Die sogenannten "Parking Lot Charts" werden für das Reporting an das Obere Management und den Kunden verwendet. Hierbei handelt es sich um einen Chart, der alle relevanten Informationen über den Status der Fertigstellung einzelner Geschäftsaktivitäten beinhaltet und leicht erkennbar visualisiert.

Rechts über dem Chart stehen die Initialen des Chefprogrammierers. Der obere Teil enthält den Namen des Feature Sets, darunter in Klammern die Anzahl der Features und die Angabe des Status der Fertigstellung in Prozent.

Der Gesamtstatus wird in folgenden Farben dargestellt:

• Gelb: In Arbeit
• Rot: Achtung (z.B. verspätete Fertigstellung)
• Grün: Fertiggestellt
• Weiß: Noch nicht bearbeitet.

Das untere Drittel enthält einen Fortschrittsbalken, der den aktuellen Fortschritt visualisiert, sowie den Monat und das Jahr der geplanten Fertigstellung. Die einzelnen Feature Sets oder Geschäftsaktivitäten werden dann in großen Rechtecken zu Geschäftsbereichen zusammengefasst, so dass sich ein Gesamtbild aller Geschäftsbereiche mit ihren Geschäftsaktivitäten und deren Status ergibt. ^[44]

6.4.3 Reporting

Das Reporting oder Berichtswesen bei FDD-Projekten ist an drei Adressatengruppen gerichtet:

Entwickler Team

• Das Entwickler Team erhält eine Liste der einzelnen Features, die die Namen der Features, der zuständigen Chefprogrammierer und die Fälligkeitsdaten der Meilensteine enthält. Der Status der Features wird dabei durch Farben kenntlich gemacht: Weiss steht für "Noch nicht begonnen", Gelb für "In Bearbeitung" und Grün für "Fertiggestellt".^[45]

Chefprogrammierer und Projektleiter

• Die Chefprogrammierer und der Projektleiter erhalten eine tabellarische Darstellung der Feature Areas mit ihren Feature Sets, die die Namen der Feature Sets, die Anzahl der enthaltenen Features und Informationen über deren Fertigstellung in Prozent enthält. Für die Darstellung des Status werden ebenfalls die Farben Weiss, Gelb und Grün verwendet. Die letzte Zeile der Tabelle enthält die Gesamtzahl der Features und den Gesamtstatus der Fertigstellung in Prozent. Diese Daten werden bei Bedarf auch als Graph dargestellt, um die Entwicklung der Fortschritte über einen längeren Zeitraum zu visualisieren.^[46]

Kunde und Oberes Management

• Die Kunden und das Obere Management erhalten ihre Berichte in Form von Parking Lot Charts. Diese sind zum Zwecke der Vergleichbarkeit immer exakt gleich aufgebaut und werden weniger häufig generiert als die beiden vorherigen Reporttypen.^[47]

7 Analyse

7.1 Bewertungskriterien

7.1.1 Personalaufwand

Die Analyse hinsichtlich des Kriteriums Personalaufwand soll, hingegen der betriebswirtschaftlichen Definition keinen Aufschluss über anfallende Personalkosten bieten, dies wird u.a. im Punkt Kosten abgehandelt. Vielmehr soll die Frage der minimal erforderlichen und maximal einsetzbaren Projektmitarbeiter beantwortet werden. Zusätzlich sollen die nötigen Qualifikationen der einzelnen Rollen ermittelt werden.

7.1.2 Kommunikationsaufwand

Der Kommunikationsbedarf ist bei Projekten zur Softwareentwicklung naturgemäß extrem hoch, so dass die Quantität kein sinnvoller Aspekt für diese Analyse ist. Die Analyse wird daher untersuchen, wie es bei FDD gelingt, die Kommunikation der Beteiligten optimal zu steuern und Informationsverluste zu vermeiden.

7.1.3 Regelwerk

Das Regelwerk von FDD wird hinsichtlich seiner Eignung für die Durchführung von Projekten unterschiedlicher Größenordnung und Komplexität betrachtet.

7.1.4 Kosten

In diesem Bereich der Analyse wird die vorher beschriebene Methode unter dem betriebswirtschaftlichen Aspekt der Kosten betrachtet. Es soll ermittelt werden wieso sich ein solches Projekt für Festpreise eignet, wo die Kosten entstehen und wie die unterschiedlichen Projektabschnitte Einfluss auf die Kosten nehmen.

7.1.5 Erfolgschancen

Innerhalb der Analyse unter Betrachtung der Erfolgschancen soll festgestellt werden unter welchen Bedingungen ein FDD-Projekt erfolgreich sein kann und welche Faktoren Einfluss darauf haben. Weiterhin soll die Erfolgschance eines solchen Projekts unter Einhaltung der Bedingungen und Berücksichtigung der Faktoren beurteilt werden.

7.1.6 Kundenzufriedenheit

Die Analyse unter der Betrachtung des Aspektes Kundenzufriedenheit soll offenlegen, welche Maßnahmen zur Sicherstellung der Qualität getroffen werden und inwiefern der Kunde selbst die Möglichkeit hat darauf einzuwirken. Des Weiteren soll geklärt werden, ob und wie mit Änderungen der Anforderungen während des Projektes umgegangen wird bzw. welche Möglichkeiten bestehen. Abschließend wird die Sichtbarkeit der Fortschritte auf Kundenseite behandelt.

7.2 Bewertung

7.2.1 Personalaufwand

Die notwendige Qualifizierung des Personals nimmt in der Struktur des Rollenmodells nach unten hin immer weiter ab, dies liegt zum einen daran, dass die höheren Ebenen als Ansprechpartner für Problemstellungen unterer Ebenen gelten, zum anderen daran, dass die Aufgabenbereiche der Ebenen nach unten hin immer operativer werden.

Die oberste Instanz jeden FDD Projektes ist der Projektleiter, dieser muss über umfassende Wirtschaftskenntnisse, sowie gute Führungsqualitäten verfügen, da sein Aufgabenbereich rein administrativ ist. Die nächste Instanz der Hierarchie ist der Chefarchitekt bzw. der Entwicklungsleiter. Der Chefarchitekt muss tiefgehende Modellierungserfahrungen vorweisen können, da er die gesamte Modellierung leitet und Ansprechpartner für alle Problemstellung bezüglich der Modellierung ist. Des Weiteren muss er über ein weitreichendes technisches Verständnis, sowie, da er die Modellierungsworkshops leitet, über gute Moderationsfähigkeiten verfügen. Konflikte zwischen Chefprogrammierern zu lösen ist eine Aufgabe des Entwicklungsleiters, weshalb dieser ebenfalls über gute Moderationsfähigkeiten verfügen muss. Eine weitere seiner Aufgaben ist die Verwaltung und Zuteilung von technischen Ressourcen, infolgedessen sind für diese Rolle gute technische Kenntnisse erforderlich. Die Struktur des Rollenmodells sieht es vor, dass die Chefprogrammierer direkte Ansprechpartner für die ihnen unterstellten Entwickler, in Bezug auf technische Fragen sind. Dies setzt umfassende Erfahrungen in der Programmierung voraus. Ebenfalls Modellierungserfahrung ist für diese Rolle zwingend erforderlich, zwar leitet der Chefarchitekt die Modellierung, aber wie in Task Eins des ersten Prozesses beschrieben, sind die Chefprogrammierer bei der Entwicklung des Gesamtmodells mit als Hauptakteure beteiligt.

Die unterste Ebene des Organigramms ist mit den Entwicklern besetzt, hier bietet FDD den Vorteil auch mit weniger erfahrenen Entwicklern ein Projekt zeitgerecht und ohne große Komplikationen fertigzustellen. Ausschlaggeben hierfür ist der Aufbau des Rollenmodells, da dieser jedem Entwickler einen direkten, erfahrenen Ansprechpartner für Problemstellungen überordnet (Chefprogrammierer). Ebenfalls das „Developing by Feature“-Prinzip trägt dazu bei, dass Entwickler auch problemlos über weniger Erfahrung verfügen können. Das „Developing by Feature“ zerlegt die Domäne in kleine Funktionen, wodurch die Komplexität der Domäne um ein vielfaches gesenkt wird und die Features selbst von weniger erfahrenen Entwicklern realisiert werden können.

Jedoch sind nicht alle dieser Rollen zwangsläufig in jedem FDD Projekt erforderlich, denn die Rolle des Entwicklungsleiters kann, je nach Rahmenbedingungen des Projektes auch vom Projektleiter oder Chefarchitekten übernommen werden. Im Wesentlichen ist dies von der Größe des Projektes und somit der Arbeitsbelastung der beiden Rollen abhängig. Der Projektleiter und der Chefarchitekt sind, aufgrund ihrer projektweiten Tätigkeiten für jedes Team erforderlich. Ein Chefprogrammierer sowie mindestens fünf unterstellte Entwickler sind ebenfalls voraussetzend für ein erfolgreiches Projekt. Mit dieser Anzahl an Entwicklern lassen sich, da ein Feature Team aus drei bis sechs Mitgliedern besteht, ca. zwei Feature Teams gleichzeitig bilden, unter der Prämisse, dass sich der Chefprogrammierer in seiner Leitungsposition in beiden Feature Teams wiederfindet. Es sollte immer die Möglichkeit der Bildung von mindestens zwei Feature Teams bestehen, da die Prozessstruktur es ermöglicht die beiden Prozesse Vier und Fünf parallel von mehreren Feature Teams bearbeiten zu lassen. Des Weiteren werden zwei Fachexperten für eine ausführliche Erläuterung der Fachbereiche, sowie für Rückfragen der Entwickler benötigt. Da die Fachexperten die Schnittstelle zum Kunden darstellen, sollten mindestens zwei im Team vorhanden sein, damit die Anforderungen korrekt interpretiert werden, die Zielführung gewährleistet ist und den Entwicklern jederzeit ein Ansprechpartner für fachliche Fragen zur Verfügung steht.

Dass bedeutet, es werden insgesamt mindestens zehn Mitarbeiter für ein Projekt benötigt. Jedoch wäre ein zweites Entwicklerteam (Chefprogrammierer mit ca. zwei bis fünf unterstellten Entwicklern) empfehlenswert, damit die Anzahl gleichzeitig an den Prozessen Vier und Fünf arbeitenden Feature Teams erhöht wird. Allgemein wirkt sich die Erhöhung der Mitarbeiteranzahl, falls dies der Umfang des Projektes zulässt, enorm auf die quantitativ erzielte Leistung aus. Dies ist darauf zurückzuführen, dass die Planungsphase (Prozesse Eins bis Drei) nur einen geringen Teil der Gesamtlaufzeit des Projektes einnimmt^[48], und somit die Entwickler während eines Großteils der Projektlaufzeit parallel arbeiten können. Allgemein sollte der Entscheidung über die Anzahl der Projektmitglieder eine solide Planung/Kalkulation zugrunde liegen, da die Erhöhung der Mitarbeiterkapazitäten während des Projektes Risiken birgt. Denn sollten die Kapazitäten während des Projektes nicht ausreichen, können aufgrund der Struktur des Rollenmodells keine einzelnen Entwickler, sondern nur ganze Entwicklerteams hinzugefügt werden. Dies führt zu Fehlern und Inkonsistenzen im Projekt, da den neuen Projektmitgliedern die Domäne vorerst fremd ist und sie die grundlegende Planungsphase nicht mitverfolgen konnten. ^[49]

Die maximale Anzahl der Mitarbeiter ist stark von der Größe des Projekts abhängig, da die Erhöhung der Entwickleranzahl nur dann möglich ist, wenn voraussichtlich genügend verschiedene Klassen zur Verfügung stehen, um jedem Entwickler mindestens eine Klasse im Rahmen der Class Ownership zuzuordnen. Die Anzahl notwendiger Fachexperten, sowie Chefprogrammierer variiert je nach Anzahl an Entwicklern. FDD ermöglicht es auch große Projekte zu bewältigen, ein Beispiel hierfür wäre das Projekt, in dem FDD entstanden ist, 1998 waren alleine 50 Entwickler in das Projekt von Jeff de Luca in Singapur involviert und es wurde zeit- und budgetgerecht abgeschlossen. Die Möglichkeit derart große Projekte mit FDD abzuwickeln, resultiert aus den klar definierten Rollen und deren Aufgaben, so kann das Projekt trotzt einer großen Anzahl von Mitarbeitern strukturiert und diszipliniert verlaufen. Aber auch die Festlegung von klaren Verantwortlichkeiten in Bezug auf die involvierten Klassen ermöglicht erst die Realisierung derartig großer Projekte.

7.2.2 Kommunikationsaufwand

Die Voraussetzung für die erfolgreiche Durchführung eines Softwareprojektes ist eine funktionierende Kommunikation aller beteiligten Parteien. Bei kleinen Projekten mit nur wenigen Mitgliedern ist die Abstimmung untereinander in der Regel kein Problem, aber mit jeder Person, die hinzukommt, steigt der Grad der möglichen Kommunikationswege rapide an. Zwischen vier Personen gibt es sechs mögliche Kommunikationswege, zwischen 10 Personen sind es schon 45 und bei 100 Personen existieren 4950 mögliche Kommunikationswege. ^[50] Abgesehen von dem hohen Komplexitätsgrad der Kommunikationswege gilt es zu verhindern, dass beispielsweise bei der Kommunikation zwischen Fachexperten und Entwicklern aufgrund der unterschiedlichen Fachtermini Missverständnisse entstehen, die nachher dazu führen, dass Anforderungen falsch interpretiert und umgesetzt werden. Daran wird deutlich, dass die Kommunikation in Softwareentwicklungs-Projekten zumindest ab einer gewissen Größenordnung der bewussten Steuerung bedarf, so dass Palmer & Felsing zu dem Schluss kommen: Ein [geeigneter] Softwareentwicklungs-Prozess beschreibt, was kommuniziert wird, wann es kommuniziert wird, wie kommuniziert wird und mit wem kommuniziert wird. ^[51] Davon ausgehend würde man erwarten, dass man in FDD ein sehr komplexes Regelwerk an Kommunikationsvorschriften findet, was jedoch nicht der Fall ist. Die einzigen Regelungen zur Kommunikation, die explizit diesem „Was-Wann-Wie-(an) Wen“-Ansatz folgen, beziehen sich auf das Reporting.

Beim FDD kann man zwei Arten der Kommunikation unterscheiden: Interne Kommunikation (innerhalb der einzelnen Projektteams) und die externe Kommunikation (Kommunikation zwischen den Hierarchieebenen und an die Kunden). Den weitaus größeren Anteil und die potenziell größte Komplexität der Kommunikationswege hat dabei die interne Kommunikation, da hier sämtliche den Entwicklungsprozess betreffende Anforderungen und Details geklärt werden müssen. Hier liegt auch das größte Potenzial für fehlerhafte Kommunikation, da hier Entwickler und Fachexperten miteinander kommunizieren, die unterschiedliche Fachtermini benutzen, die der anderen Seite jeweils unvertraut sind. Diesen Bruch in der Sprache fängt FDD dadurch auf, dass die Anforderungen in Features zerlegt werden, die in eine simple, einheitliche Form gebracht werden, die beiden Seiten verständlich ist (<action> <result> <object>). Hierdurch können auch mögliche Kommunikationsprobleme muttersprachlicher Natur vermieden werden, da die Übersetzung einfachster Begriffe in dieser Form nur wenig Potenzial für Fehlinterpretationen bietet. Um zu erreichen, dass während Planung und Entwicklung zu jeder Zeit die richtigen Personen miteinander kommunizieren, wird bei FDD sicher gestellt, dass bei jeder Aufgabenstellung jeweils alle Personen einbezogen sind, die daran direkten Anteil haben: So beginnt die Planungsphase damit, dass die Chefprogrammierer und Fachexperten ein Modellierungsteam bilden, das beim Entwurf des Domain Object Model auch die zukünftigen Class Owner nach einem Rotationsprinzip teilhaben lässt. Zur Qualitätssicherung dieses Prozesses können dem Modellierungsteam zusätzlich künftige Benutzer beigeordnet werden, die dann die Arbeitsergebnisse gemeinsam mit dem Team bewerten. Durch diese Art der geschickten Teambildung wird die Komplexität der Kommunikationswege relativ gering gehalten, da immer alle Beteiligten in überschaubaren Teams direkt miteinander Kommunizieren können. Es gibt keine Umwege über schriftliche Mittel, jeder ist direkt involviert.

Da außer des Reportings innerhalb von FDD-Projekten keine formalisierte Kommunikation stattfinden muss, sondern sämtliche entwicklungsbezogene Kommunikation aufgrund der geschickten Teambildung direkt unter den Beteiligten stattfínden kann, ist der Kommunikationsaufwand als relativ gering zu bezeichnen. Der einzige formale Aufwand besteht im Reporting, jedoch liegt auch hier ein sehr eingängiges und simples Schema zugrunde, so dass auch dieser Kommunikationsaufwand als gering bezeichnet werden kann.

7.2.3 Regelwerk

Das Regelwerk von FDD setzt sich aus den zwei Teilbereichen Rollen und Prozesse zusammen. Das Rollenmodell beinhaltet sechs Schlüsselrollen, wobei die Rollen des Projektleiters, des Chefarchitekts und des Entwicklungsleiters einen administrativen Schwerpunkt besitzen. Die Rollen der Chefprogrammierer, der Class Owner und der Fachexperten sind hingegen direkt am Entwicklungsprozess beteiligt. Bei den administrativen Rollen sind die Rollen des Projektleiters und des Chefarchitekten erforderlich, die Rolle des Entwicklungsleiters kann abhängig von der Größenordnung des Projektes „eingespart“ werden, indem sie von einem der beiden anderen in Personalunion übernommen wird, was in der Praxis auch häufig vorkommt. Andererseits kann bei sehr großen Projekten jede dieser Rollen auch noch mal aufgeteilt werden (Master-/Apprenticeship pairing). Auf der Entwicklungsebene werden die Rollen entsprechend den Anforderungen einfach nur noch vervielfacht, dass heißt je nach Größenordnung und Komplexitätsgrad steigt die Anzahl von Chefprogrammierern, Class Owners und Fachexperten linear an. Die Leitungsebene besteht somit bei sehr kleinen Projekten aus mindestens zwei Personen (Projektleiter und Chefarchitekt), während sie bei großen Projekten selten mehr als sechs Personen umfasst. Auf der Entwicklungsebene hingegen sind ausgehend von einem Minimum von fünf Personen (Chefprogrammierer, drei Entwickler und ein Fachexperte) nach oben keine Grenzen gesetzt. Diese Struktur des Rollenmodells ermöglicht eine sehr gute Skalierbarkeit und spricht für eine hohe Effektivität des Personaleinsatzes, da insbesondere die Output generierenden Rollen stark anwachsen. Allerdings ist zu beachten, dass die denkbare Mindestbesetzung der Entwicklungsebene mit nur einem Feature Team als suboptimal angesehen werden muss, da die Stärke von FDD gerade in der parallelen Bearbeitung von Aufgaben liegt. Somit sollten bei Projekten, deren Größe und Budget dies zulassen, immer mindestens zwei Feature Teams gebildet werden können.

Das Prozessmodell von FDD beinhaltet fünf Prozesse, die in Planungs- und Entwicklungsphase unterteilt werden. Die Planungsphase besteht aus den Prozessen „Develop an Overall Model“, „Build a Features List“ und „Plan by Feature“ und wird einmalig durchlaufen, während die Entwicklungsphase die beiden Prozesse „Design by Feature“ und „Build by Feature“ enthält, welche iterativ durchlaufen werden. In der Planungsphase entsteht ein Gesamtmodell (Prozess #1), aus dem Major Feature Sets abgeleitet werden, die weiter zerlegt werden in Feature Sets und letztendlich eine feingranulare Liste der einzelnen Features ergeben (Prozess #2). Im Anschluss wird ein Entwicklungsplan erstellt, der eine Liste aller Klassen und ihrer Besitzer enthält, die Verantwortlichkeit für die Feature Sets verbindlich einzelnen Chefprogrammierern zuweist und Fertigstellungstermine für Major Feature Sets und Feature Sets enthält (Prozess #3). Damit ist die Planungsphase endgültig abgeschlossen und die beiden Prozesse der Entwicklungsphase werden, ausgehend vom Entwicklungsplan, für jedes einzelne Feature mindestens einmal durchlaufen. Entsprechend den Anforderungen an ein Qualitätsmanagement enthält jeder Prozess am Ende ein Assessment, in dem die Ergebnisse der einzelnen Tasks noch einmal überprüft werden. Eine Besonderheit des FDD ist, dass sich sämtliche interne Meilensteine ausschließlich auf die Entwicklungsphase beziehen und in Form einzelner oder mehrerer Tasks feste Bestandteile der Prozesse sind. Hierdurch wird erreicht, dass der Fokus klar auf die Erzeugung von Output gerichtet ist und sich die Teams nicht übermäßig mit Planung und Dokumentation aufhalten. Durch den Ansatz, komplexe Funktionalitäten in eine Anzahl einfachster Funktionen zu zerlegen, welche dann parallel in einem iterativen Prozess abgearbeitet werden können, ist FDD höchst flexibel, wenn es darum geht, Änderungen oder Korrekturen vorzunehmen: Während bei klassischen Verfahren für jede neue Funktion oder jede Änderung bestehender Funktionen ein sehr komplexer Planungs- und Abstimmungsprozess durchlaufen werden muss, können bei FDD in kürzester Zeit auch weitreichende Änderungen oder komplexe neue Funktionen implementiert werden, da die Anpassungen des Domain Object Models standardmäßig bei jedem Durchlauf des Design-by-Feature-Prozesses vorgenommen werden und kein erneuter Durchlauf einer Planungsphase nötig ist.

7.2.4 Kosten

Ein FDD Projekt läuft auf Grund der festgelegten Prozesse immer in einem ähnlichen Rahmen ab: Zu Anfang steht, immer die Planungsphase welche sich über die ersten drei Prozesse verteilt. In dieser Projektphase kommt es zur Anwendung des Domain Objekt Modellings . Dabei wird die zu behandelnde Domäne analysiert und in Form von Klassen-, Sequenzdiagrammen und Objektbeziehungen aufbereitet. Bei dieser Arbeit wird hauptsächlich hoch qualifiziertes Personal, wie z.B. der Chefarchitekt oder die Chefprogrammierer, benötigt, wo hingegen bei den letzten beiden Prozessen normale Entwickler eingesetzt werden. In der anfänglichen Planungsphase können somit, bei einer sehr komplexen Domäne, bereits hohe Kosten entstehen. Je komplexer die Domäne ist, desto mehr Manntage werden für die Erstellung des Domain Object Model und der Featureliste benötigt. Diese sind jedoch durch die Tatsache, dass die Planungsdauer in einem Projekt einen Zeitraum von 2-3 Wochen nicht überschreiten sollte^[48] und das Modeling Team nicht unbegrenzt viele Mitglieder hat, limitiert.

Das dadurch entstandene Domain Object Model, dient für den weiteren Ablauf als Vorlage und ermöglich das Einsetzen von weniger qualifizierten Personal, in den Design by Feature und Build by Feature Prozessen. Da durch die vorherige Planung die Problembereiche bereits soweit vereinfacht wurden, dass keine herrausragenden Programmierfähigkeiten erforderlich sind, sind die entstehenden Kosten durch das geringer qualifizierte Personal hier deutlich niedriger. Zusätzlich fallen hier jedoch Kosten im technischen Bereich an, da die Entwickler technische Ressourcen, in Form von Speicherplatz auf einem Server, Rechenzeit und Hardware, benötigen. In welchem Umfang sich diese Bewegen hängt davon ab welche technische Architektur für das Projekt benötigt wird. Hier können Personalkosten durch die Programmierung von Emulationssoftware^[52] der Zielarchitektur entstehen oder Hardwarekosten, durch den Einkauf spezieller Hardware, bei der Verwendung einer Architektur die nicht emuliert werden kann.

Die größten und unberechenbarsten Kosten entstehen durch Fehler in der Software und werden im FDD durch eine vielzahl explizit hierfür vorgesehener Vorgaben und Tasks frühzeitig erkannt. zählt das „Regular Build Schedule“, bei dem in regelmäßigen Abständen ein System mit den derzeit fertigen Features erstellt wird. Weitere Maßnahmen zur frühzeitigen Fehlererkennung, die in FDD getroffen werden sind die Inspections, die Unit-Tests und die Vertifications am Ende der Prozesse. Durch dieses System der Fehlererkennung können die aufgetretenen Fehler noch im Feature Team selbst behoben werden. Weiterhin werden Fehler und Inkonsistenzen die, nach einem Build am Ende des Projekts, zu einer ausgeprägten Fehlersuche führen könnten, durch die Selbstüberprüfung am Ende der Design und Build by Feature Prozesse, vermieden. Dadurch haben die Kosten die, die für die Fehlererkennung und Behebung entstehen nur Einfluss auf die Kosten des fehlerhaften Features, nicht aber auf das gesamte Projekt. Die durch den Regular Build entstehenden Mehrkosten im Personellen sowie technischen Bereich, sind im Gegensatz zu einer ausgeprägten Fehlersuche bei der im schlimmsten Fall mehrere Feature Teams beteiligt sind als unproblematisch an zu sehen und können durch das vorher bekannte Build Schedule gut berechnet werden.

Betrachtet man die entstehenden Kosten in den einzelnen Bereich, Planung, Umsetzung und Technik, so fällt auf, dass die Kosten durch die sehr strengen Prozess von FDD sehr gut zu bestimmen sind und es wenig Abweichungen gibt. Die Kosten, die während der Planung entstehen sind durch eine maximale Planungsdauer von 2-3 Wochen, für ein Projekt, allein durch die in dieser Zeit maximal zu leistenden Manntage absehbar. Da die Entwicklung des Systems in den Design und Build by Feature Prozessen entlang von Featuren stattfindet, können an dieser Stelle normale Entwickler eingesetzt werden. Die gute Fehlererkennung durch die Regular Builds und die Unit-Test, sowie die selbst Überprüfung in den Design und Build by Feature Prozessen, minimiert die Gefahr das unvorhergesehen Kosten durch Fehler entstehen.Beide Effekte führen dazu das es möglich ist eine sehr genau Bestimmung der benötigen Manntage durch zu führen. Dadurch lässt sich sehr gut bestimmen welche Kosten in einem solchen Projekt entstehen und ermöglicht so das Anbieten des Projekts zu einem Festpreis.

7.2.5 Erfolgschancen

Um ein Projekt nach der beschriebenen Methode erfolgreich durch zu führen ist es von großer Bedeutung, dass einige Grundlegende Bedingungen erfüllt werden.

Das erfolgreiche Durchlaufen der Planungsphase, welche sich über die ersten drei Prozesse erstreckt ist eine Grundvoraussetzung um das Projekt mit allen benötigten Informationen zu versorgen. Es ist von großer Bedeutung, dass während des Domain Object Modeling sehr genau gearbeitet wird, da sich der spätere Entwicklungsprozess an den Ergebnissen dieses Vorgangs orientiert. Im weiteren Verlauf wird die Featureliste gebildete, welche unbedingt notwendig ist, da Sie die Anforderungen des Kunden wiederspiegelt und auch für das Reporting gegenüber dem Kunden und Management Verwendung findet. Des Weiteren ist sie die Grundlage für die Design und Build by Feature Prozesse. Ein schlecht ausgearbeitetes Domain Object Model und die daraus resultierende Featureliste haben daher großen Einfluss auf den Erfolg des Projekts, da fehlerhafte oder sogar fehlende Features die Entwicklungsdauer im späteren Verlauf deutlich erhöhen. Die Qualität des Domain Object Model und der Featureliste ist also von dem dafür eingesetzten Personal und dessen Qualifizierung abhängig. Hier ist es wichtig ausgewiesene Fachexperten mit tiefgreifendem Verständnis der Zieldomäne, sowie einen äußerst erfahrenen Chefarchitekten im Modelling-Team zu haben. Eine deutliche Erhöhung der Entwicklungsdauer kann dazu führen das der Zeitplan und/oder das Projektbudget nicht eingehalten werden können, was bei zu großer Überschreitung zum Misserfolg des Projekts führen kann.

Die Verfügbarkeit der richtigen technischen Architektur ist eine weitere Bedingung für den Erfolg des Projekts. Sie wird benötigt, um die in der Planungsphase ermittelten Features, auf der entsprechenden Zielarchitektur zu Entwickeln. Die Auswahl der Architektur ist den Development Teams selbst überlassen, da es hier zu viele Möglichkeiten gibt um eine für alle Projekte gültige Architektur zu definieren. Wann diese definiert und ausgewählt wird hängt von den Gegebenheiten im Projekt Team ab. Dies kann vor oder nach der Plangsphase erfolgen, bei ausreichend Personellen Ressourcen auch parallel dazu oder zwischen den Prozessen Plan by Feature und Design by Feature^[53]. Sie muss jedoch vor dem Start der eigentlichen Entwicklungsphase in den Design und Build by Feature Prozessen vorhanden sein, damit die in den Prozessen vorgesehenen Abläufe im Bereich des Unit-Testings eingehalten werden können.

Das Einhalten der strengen Vorgaben für die Prozesse ist nicht zuletzt in dem Bereich der Design und Build by Feature Iteration von größter Bedeutung. Zur Vermeidung von Fehlern und Inkonsistenzen ist in jedem der beiden Prozesse ein Abschnitt vorgesehen. Im Design-by-Feature-Prozess wird ein Design Review durchgeführt, im Build-by-Feature-Prozess ein Unit Test. Weiterhin werden in regelmäßigen Abständen die Regular Builds durchgeführt. Die genaue Einhaltung dieser Prozessvorgaben ist also für die Erkennung und Behebung von Fehlern und das erzeugen eines guten Endprodukts von größter Wichtigkeit. Zwar sieht FDD ein Regular Build Schedule vor, jedoch ist es dem Projekt Team überlassen in welchen Abständen der Regular Build ausgeführt wird. Sollte sich das Team nun entschieden haben, über die gesamte Laufzeit des Projekts nur zwei Builds, gegen Ende des Projekts durchzuführen, können Inkonsistenzen erst spät erkannt werden. Sollten nun die Feature Teams zusätzlich die Prozesse zur Fehlererkennung und -behebung missachtet haben kann es zu einer sehr aufwändigen Fehlersuche kommen. Daraus resultiert in der Regel eine Starke Verzögerung des Fertigstellungstermins welche meistens mit einer Überschreitung des Budgets einhergeht. Beides kann zum Einstufen des Projekts als Misserfolg führen.

Unter Einhaltung der notwendigen Bedingungen und Beachtung aller Einflussfaktoren ist die Erfolgschance eines solchen Projekts sehr hoch. Durch eine genau Planungsphase ist es möglich, wie aus der Analyse zum Thema Kosten hervorgeht, einen Festpreis anzubieten, es bietet ein gutes Fehlermanagement und ist trotz der strengen Prozesse teilweise in der Lage auf Änderungen zu reagieren.

7.2.6 Kundenzufriedenheit

Ein maßgeblicher Aspekt für die Kundenzufriedenheit in FDD-Projekten ist das Konzept des „Developing by Feature“. Das Zerlegen der Domäne in feingranulare Features deckt Unklarheiten in den Anforderungen schon zu Beginn des Projektes auf ^[54], sodass diese sich nicht auf die Entwicklungsprozesse auswirken können.

Alle Features folgen einer einheitlichen, dem Kunden verständlichen Namenskonvention und werden in Geschäftsaktivitäten (Feature Sets) und Geschäftsbereichen (Major Feature Sets) zusammengefasst. Dieses Konzept orientiert sich stark an der Arbeit des Kunden und den ihm bekannten Begrifflichkeiten, wodurch er den einzelnen Features in Abhängigkeit von der Relevanz für seine Anwendung Priorisierungen zuweisen kann. Des Weiteren kann der Kunde anhand der erstellten Featureliste überprüfen, ob die Software seinen Anforderungen gerecht wird. Zusätzlich sind zur Gewährleistung der Anforderungserfüllung Fachexperten (potentielle Endanwender der Software) in jedes FDD-Projekt involviert. Neben der Sicherstellung der Anforderungserfüllung sorgen diese auch für die fachliche Korrektheit der Features.

Änderungen der Anforderungen während des Projektes können bis zu einem gewissen Level berücksichtig werden, ohne, dass sich diese für den Kunden sichtbar auf das Projekt Auswirken (z.B. Verschiebung von Fertigstellungsterminen). Stephen R. Palmer und John M. Felsing schreiben in ihrem Buch „A Practical Guide to Feature Driven Development“, dass sich diese Grenze auf 10% der bisherigen Features beläuft, dies nennen sie die „10% Slippage Rule“ („10% Abweichungsregel“) ^[55]. Belaufen sich die Änderungen auf über 10% des Gesamtprojektes bzw. der Features muss eine entsprechende Änderung in einem anderen Bereich vorgenommen werden. Dazu stehen drei Möglichkeiten zur Verfügung ^[56]. Der Umfang des Projektes kann reduziert werden indem Features mit geringer Priorisierung verworfen werden ^[57]. Meist kann der Umfang des Projektes mit dieser Methode jedoch nicht ausreichend gemindert werden, da nur Features verworfen werden können, die keinen Einfluss auf die Geschäftsabläufe haben (sogenannte „nice-to-have“ Features ^[57]). Des Weiteren ist diese Möglichkeit zur Erzielung einer hohen Kundenzufriedenheit weitestgehend unbrauchbar. Eine Alternative wäre die Fertigstellungstermine weiter in die Zukunft zu verlegen ^[58], jedoch wird dies weder vom Kunden, noch vom oberen Management gerne gesehen. Der Kunde hat meist selbst schon Planungen getroffen, die sich an den Fertigstellungsterminen orientieren, die er bei einer Verschiebung nicht einhalten könnte. Das obere Management hingegen lehnt diese Möglichkeit meist aus Reputationsgründen ab ^[57]. Die dritte Alternative wäre, während des Projektes die Kapazitäten zu erhöhen ^[49], wie jedoch die Analyse hinsichtlich des Personalaufwands schon gezeigt hat, ist dies während des Projektes mit Risiken verbunden. Zur Erzielung einer hohen Kundenzufriedenheit sollte diese Möglichkeit jedoch trotzdem in Betracht gezogen werden.

Das „Developing by Feature“-Konzept bietet dem Kunden spätestens alle zwei Wochen sichtbare Fortschritte. Anhand der Fortschrittsberichte (Parking Lot Charts), die in einer simplen, dem Kunden verständlichen Form gestaltet sind, kann der Kunde den Fortschritt problemlos mitverfolgen. Dem Kunden ist es anhand der Fortschrittsberichte auch möglich, da diese immer in einer einheitlichen Form übergeben werden, die Schnelligkeit und Laufzeit des Projektes zu beurteilen. Hierzu betrachtet der Kunde die Differenzen der beiden Parking Lot Charts, diese Differenzen stellen die erzielte Leistung seit dem letzten Fortschrittsbericht dar. Da gewöhnlicher Weise das System in regelmäßigen Abständen neu generiert wird, steht dem Kunden immer eine relativ aktuelle Vorabversion der Software zu Verfügung. Diese kann er selbst noch einmal auf die Erfüllung seiner Anforderungen hin prüfen oder sie für Testzwecke nutzen.

FDD bietet in der anfänglichen Planungsphase zahlreiche Möglichkeiten und Tasks zur Gewährleistung der Anforderungserfüllung. Es wird versucht Unklarheiten und Inkonsistenzen in den Anforderungen vor Beginn der Entwicklungsprozesse weitestgehend zu beseitigen, da Anforderungsänderungen während der Entwicklungsprozesse nur begrenzt berücksichtigt werden können, ohne, dass die Kundenzufriedenheit darunter leidet oder Risiken in Betracht gezogen werden müssen.

7.3 Gesamtergebnis

Kriterium	Ergebnis
Personalaufwand	Hoch qualifiziertes Personal in der Führungsebene notwendig. Arbeiten mit weniger erfahrenen Entwicklern möglich. Minimaler Personalbedarf mit 10 Mitarbeitern relativ gering. Erhöhung der Mitarbeiteranzahl zu Beginn des Projektes, aufgrund der Prozessstruktur, die paralleles Arbeiten ermöglicht empfehlenswert. Der Mitarbeiteranzahl sollte eine solide Planung zugrunde liegen, da eine Kapazitätserhöhung während des Projektes Risiken birgt. Maximale Mitarbeiteranzahl stark vom Projekt abhängig.
Kommunikationsaufwand	Zwei Arten der Kommunikation: Interne Kommunikation (innerhalb der Projektgruppen) und externe Kommunikation (zwischen den Hierarchieebenen und mit dem Kunden). Nur externe Kommunikation ist formal beschrieben. Interne Kommunikation findet automatisch statt, da durch geschickte Teambildung immer alle benötigten Personen direkt kommunizieren. Vermeidung von Kommunikationsproblemen zwischen Fachleuten mit unterschiedlicher Fachsprache durch Zerlegung in Features und Nutzen einer simplen und einheitlichen Form: <action> <result> <object>. Kommunikationsaufwand insgesamt eher gering.
Regelwerk	Regelwerk zusammengesetzt aus Rollen- und Prozessbeschreibung. Rollenmodell sehr flexibel, da Hierarchie relativ flach und gut skalierbar. Bei großen Projekten skalieren Entwicklerrollen wesentlich stärker als Leitungsrollen, bei kleinen Projekten gegenteiliger Effekt. Prozesse unterteilt in einmalig zu durchlaufende Planungs- und ggf. iterativ zu durchlaufende Entwicklungsphase. Alle Meilensteine Bestandteil der Entwicklungsphase, dadurch starke Ausrichtung auf Generierung von Output. Wenig Planungs- und Dokumentationsaufwand bei Korrekturen und Änderungen. Hohe Qualitätsorientierung durch Assessments am Ende jedes Prozesses und starke Einbeziehung des Kunden an Schlüsselstellen des Entwicklungsprozesses.
Kosten	Planungsphase relativ kostenintensiv, da hoch qualifiziertes Personal eingesetzt wird. Kosten der Planungsphase sind stark von der Komplexität der Domäne abhängig, jedoch limitiert. Entwicklungsphase verursacht relativ geringe Personalkosten, da unerfahrene Entwickler eingesetzt werden. Kaum unvorhersehbare Kosten durch Fokus auf Fehlervermeidung. Festpreisgeeignet.
Erfolgschancen	Unter Einhaltung folgender Bedingungen ist die Chance auf ein erfolgreiches Projekt sehr hoch: Detailliertes Arbeiten in der Planungsphase. Hoch qualifizierte Führungsebene. Beachtung aller Taskvorgaben, insbesondere Überprüfungen, Inspections und Unit Tests. Geeignete Abstände für Regular Builds.
Kundenzufriedenheit	„Developing by Feature“-Konzept deckt Unklarheiten und Inkonsistenzen in den Anforderungen schon in der Planungsphase auf. Kunde kann anhand der Features Priorisierungen vornehmen. Kunde kann Anforderungserfüllung anhand der Featureliste prüfen. Fachexperten gewährleisten Anforderungserfüllung und fachliche Korrektheit. Anforderungsänderungen bis zu 10% der Features, ohne sichtbare Auswirkungen für den Kunden tragbar. Spätestens alle zwei Wochen sichtbare Resultate. Regular Build ermöglicht dem Kunden die Software vorab auf Anforderungserfüllung zu prüfen bzw. sie zu Testzwecken zu verwenden.

8 Schlussbetrachtung

Wie aus den Ergebnissen der Analysen hervorgeht, birgt der Einsatz von FDD keine gravierenden Nachteile, die die Methode für die Praxis unbrauchbar machen. Die mangelnde Verbreitung in der Praxis ist somit ehr darauf zurückzuführen, dass FDD sehr viele und sehr strikte Vorgaben zu allen Teilbereichen der Planung und Entwicklung macht, die von vielen Unternehmen als Einschränkungen betrachtet werden. Hinzu kommt, dass diese Vorgaben für ein erfolgreiches Projekt, das auf eine hohe Kundenzufriedenheit abzielt, weitestgehend alle einzuhalten sind.

Dennoch bietet FDD trotz dieser strikten Vorgaben eine enorm hohe Flexibilität bezüglich Anforderungsänderungen und Korrekturen. Der minimale Personalbedarf ist mit 10 Mitarbeitern als relativ gering zu beurteilen, die Skalierbarkeit nach oben hingegen ist weitestgehend unbegrenzt. Auch bei großen Skalierungen des Projektes, bleibt die Führungsebene recht überschaubar, was die Komplexität der gesamten Projektstruktur gering hält. In den unteren Ebenen der Hierarchie kann weniger qualifiziertes Personal eingesetzt werden, welches die Projektkosten stark reduziert.

Unvorhersehbare Kosten können kaum auftreten, da FDD einen klaren Fokus auf Fehlervermeidung legt, dies wird an den Assessments am Ende der Prozesse, den Inspections, den Unit Tests und den Regular Builds deutlich.

Die allem vorangehende Planungsphase ermöglicht eine genaue Kalkulation der Projektkosten, wodurch der Vorteil von Festpreisangeboten entsteht.

Das Ergebnis der Planungsphase ist maßgeblich für den weiteren Verlauf und Erfolg des Projektes, daher besteht hier ein großes Risiko, durch Fehler und Ungenauigkeiten einen Misserfolg herbeizuführen. Dies orientiert sich stark an konservativen Entwicklungsmethoden, daher fällt es auch gerade Unternehmen, die noch mit konservativen Methoden der Softwareentwicklung arbeiten, leichter FDD zu implementieren.

FDD eignet sich somit für eine Vielzahl von Projekten, sowohl für kleinere Entwicklungsprojekte, als auch für Projekte, die mehrere hundert Entwickler umfassen. Viele Vorgaben zur Art der Projekte in denen FDD eingesetzt werden kann werden nicht definiert, daher eignet sich FDD weitestgehend für alle Softwareentwicklungsprojekt, die die zuvor ermittelten Rahmenbedingungen erfüllen. Vor allem Projekte, bei denen ein sehr geringes Zeitkontingent zur Verfügung steht, sind mit FDD ohne große Komplikationen zu bewältigen.

9 Anhang

9.1 Fußnoten

1. ↑ vgl. Hoffmann (2008), Seite 495f
2. ↑ vgl. Hoffmann (2008), Seite 494
3. ↑ vgl. it-agile GmbH.(2011), http://www.it-agile.de/fileadmin/docs/FDD-Interview_en_final.pdf (15.05.2011 14:40)
4. ↑ vgl. Nebulon Pty. Ltd. (2011), http://www.nebulon.com/pr/bio.html (15.05.2011 14:48)
5. ↑ vgl. Nebulon Pty. Ltd. (2011), http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf, Seite 7ff (30.05.2011 15:32)
6. ↑ ^{6,0 6,1 6,2 6,3} vgl. Nebulon Pty. Ltd. (2011), http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf, Seite 3 (30.05.2011 15:33)
7. ↑ vgl. Palmer & Felsing (2002), Seite 65
8. ↑ vgl. Palmer & Felsing (2002), Seite 39
9. ↑ vgl. Palmer & Felsing (2002), Seite 57
10. ↑ vgl. Palmer & Felsing (2002), Seite 39
11. ↑ vgl. Palmer & Felsing (2002), Seite 41
12. ↑ ^{12,0 12,1} vgl. Palmer & Felsing (2002), Seite 28
13. ↑ ^{13,0 13,1 13,2 13,3} vgl. Palmer & Felsing (2002), Seite 29
14. ↑ vgl. Palmer & Felsing (2002), Seite 30
15. ↑ ^{15,0 15,1 15,2 15,3 15,4} vgl. Nebulon Pty. Ltd. (2011), http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf, Seite 1 (15.05.2011 14:12)
16. ↑ vgl. Palmer & Felsing (2002), Seite 126
17. ↑ vgl. Nebulon Pty. Ltd. (2011), http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf, Seite 2 (19.05.2011 09:18)
18. ↑ vgl. Palmer & Felsing (2002), Seite 132
19. ↑ vgl. Palmer & Felsing (2002), Seite 133
20. ↑ ^{20,0 20,1} vgl. Palmer & Felsing (2002), Seite 143
21. ↑ vgl. Nebulon Pty. Ltd. (2011), http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf, Seite 5f. (29.05.2011 16:05)
22. ↑ ^{22,0 22,1 22,2} vgl. Nebulon Pty. Ltd. (2011), http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf, Seite 5 (29.05.2011 16:07)
23. ↑ ^{23,0 23,1 23,2} vgl. Nebulon Pty. Ltd. (2011), http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf, Seite 6 (30.05.2011 16:48)
24. ↑ ^{24,0 24,1 24,2 24,3 24,4 24,5 24,6} vgl. Nebulon Pty. Ltd. (2011), http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf, Seite 7 (30.05.2011 16:50)
25. ↑ ^{25,0 25,1 25,2 25,3} vgl. Nebulon Pty. Ltd. (2011), http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf, Seite 8 (23.05.2011 13:55)
26. ↑ ^{26,0 26,1 26,2 26,3 26,4 26,5} vgl. Nebulon Pty. Ltd. (2011), http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf, Seite 9 (18.05.2011 11:47)
27. ↑ vgl. Palmer & Felsing (2002), Seite 191
28. ↑ vgl. Nebulon Pty. Ltd. (2011), http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf, Seite 10 (30.05.2011 16:55)
29. ↑ ^{29,0 29,1} vgl. Palmer & Felsing (2002), Seite 37
30. ↑ vgl. Palmer & Felsing (2002), Seite 36
31. ↑ siehe Palmer & Felsing (2002), Seite 37
32. ↑ vgl. Coad, Lefebvre und DeLuca (1999), Seite 2ff
33. ↑ vgl. Palmer & Felsing (2002), Seite 110 und Coad, Lefebvre und DeLuca (1999), Seite 28
34. ↑ vgl. Palmer & Felsing (2002), Seite 38f
35. ↑ vgl. Palmer & Felsing (2002), Seite 41f
36. ↑ vgl. Palmer & Felsing (2002), Seite 42
37. ↑ vgl. Palmer & Felsing (2002), Seite 49
38. ↑ vgl. Nebulon Pty. Ltd. (2011), http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf, Seite 8f. (16.05.2011 10:57)
39. ↑ vgl. Palmer & Felsing (2002), Seite 50
40. ↑ vgl. Palmer & Felsing (2002), Seiten 46-49
41. ↑ vgl. Palmer & Felsing (2002), Seite 51
42. ↑ vgl. Palmer & Felsing (2002), Seite 77
43. ↑ vgl. Palmer & Felsing (2002), Seite 81f.
44. ↑ vgl. Coad, Lefebvre und DeLuca (1999), Seite 199
45. ↑ vgl. Palmer & Felsing (2002), Seite 78
46. ↑ vgl. Palmer & Felsing (2002), Seite 80 bis 83
47. ↑ vgl. Palmer & Felsing (2002), Seite 84f.
48. ↑ ^{48,0 48,1} vgl. it-agile GmbH.(2011), http://www.it-agile.de/fileadmin/docs/FDD-Vorstellung-OF-Karlsruhe-2008-HenningWolf.pdf, Seite 12 (02.06.2011 17:09)
49. ↑ ^{49,0 49,1} vgl. Palmer & Felsing (2002), Seite 237
50. ↑ vgl. Palmer & Felsing (2002), Seite 9
51. ↑ vgl. Palmer & Felsing (2002), Seite 11
52. ↑ vgl. Palmer & Felsing (2002), Seite 200
53. ↑ vgl. Palmer & Felsing (2002), Seite 204
54. ↑ vgl. Palmer & Felsing (2002), Seite 234
55. ↑ vgl. Palmer & Felsing (2002), Seite 235
56. ↑ vgl. Palmer & Felsing (2002), Seite 235f
57. ↑ ^{57,0 57,1 57,2} vgl. Palmer & Felsing (2002), Seite 236
58. ↑ vgl. Palmer & Felsing (2002), Seite 236f

9.2 Quellen

Verweis	Quelle
Hoffmann (2008)	Hoffmann, Dirk W.: Software-Qualität, Springer Verlag, München, Heidelberg 2008
it-agile GmbH (2011)	it-agile GmbH, Beratungsunternehmen für agile Softwareentwicklung: http://www.it-agile.de/
Nebulon Pty. Ltd. (2011)	Nebulon Pty. Ltd., offizielle Seite zu FDD von Jeff De Lucas Beratungsunternehmen: http://www.nebulon.com/
Palmer & Felsing (2002)	Palmer, Stephen R.; Felsing, John M.: A Practical Guide to Feature-Driven Development (Coad Series), Prentice Hall International, 2002
Coad, Lefebvre und DeLuca (1999)	Coad, Peter; Lefebvre, Eric, De Luca, Jeff: Java Modeling in Color with UML, Prentice Hall International, 1999