Funktionsorientierte Entwicklung - Feature-driven development

Feature-driven Development ( FDD ) ist ein iterativer und inkrementeller Softwareentwicklungsprozess . Es ist eine leichtgewichtige oder agile Methode zur Entwicklung von Software . FDD verbindet eine Reihe von branchenweit anerkannten Best Practices zu einem zusammenhängenden Ganzen. Diese Praktiken werden aus einer vom Kunden bewerteten Funktionalitätsperspektive ( Feature ) gesteuert . Sein Hauptzweck besteht darin, greifbare, funktionierende Software in Übereinstimmung mit den Prinzipien des Agile Manifests zeitnah und wiederholt zu liefern .

Geschichte

FDD wurde ursprünglich von Jeff De Luca entwickelt , um die spezifischen Anforderungen eines 15-monatigen, 50-köpfigen Softwareentwicklungsprojekts bei einer großen Bank in Singapur im Jahr 1997 zu erfüllen . Dies führte zu einem Satz von fünf Prozessen, die die Entwicklung eines Gesamtmodells und das Auflisten, Planen, Entwerfen und Erstellen von Funktionen. Der erste Prozess ist stark von Peter Coads Ansatz zur Objektmodellierung beeinflusst . Der zweite Prozess beinhaltet die Ideen von Coad, eine Feature-Liste zu verwenden, um funktionale Anforderungen und Entwicklungsaufgaben zu verwalten. Die anderen Prozesse sind das Ergebnis der Erfahrung von Jeff De Luca. Seit seinem erfolgreichen Einsatz im Singapur-Projekt hat es mehrere Implementierungen von FDD gegeben.

Die Beschreibung von FDD wurde der Welt erstmals in Kapitel 6 des Buches Java modeling in Color with UML von Peter Coad, Eric Lefebvre und Jeff De Luca im Jahr 1999 vorgestellt. Später in Stephen Palmer und Mac Felsings Buch A Practical Guide zu Feature-Driven Development (veröffentlicht 2002) wurde eine allgemeinere Beschreibung von FDD, abgekoppelt von der Java-Modellierung, gegeben.

Überblick

FDD ist ein modellgetriebener Kurziterationsprozess, der aus fünf grundlegenden Aktivitäten besteht. Für genaue Statusberichte und die Verfolgung des Softwareentwicklungsprojekts werden Meilensteine ​​definiert , die den Fortschritt bei jedem Feature markieren. Dieser Abschnitt gibt einen allgemeinen Überblick über die Aktivitäten. In der Abbildung rechts ist das Metaprozessmodell für diese Aktivitäten dargestellt. Während der ersten beiden sequentiellen Aktivitäten wird eine Gesamtmodellform erstellt . Die letzten drei Aktivitäten werden für jedes Feature wiederholt .

Vorgehensmodell für FDD

Gesamtmodell entwickeln

Das FDD-Projekt beginnt mit einem umfassenden Überblick über den Umfang des Systems und seinen Kontext. Anschließend werden für jeden Modellierungsbereich in kleinen Gruppen detaillierte Domänenmodelle erstellt und zur Begutachtung vorgelegt . Ein oder mehrere der vorgeschlagenen Modelle werden ausgewählt, um das Modell für jeden Domänenbereich zu werden. Domänenbereichsmodelle werden nach und nach zu einem Gesamtmodell zusammengeführt.

Funktionsliste erstellen

Das während der anfänglichen Modellierung gesammelte Wissen wird verwendet, um eine Liste von Merkmalen zu identifizieren, indem die Domäne funktional in Themenbereiche zerlegt wird. Themenbereiche enthalten jeweils Geschäftsaktivitäten, und die Schritte innerhalb jeder Geschäftsaktivität bilden die Grundlage für eine kategorisierte Featureliste. Merkmale in dieser Hinsicht sind kleine Teile von kundenbewerteten Funktionen, die in der Form "<Aktion> <Ergebnis> <Objekt>" ausgedrückt werden, zum Beispiel: 'Berechnen Sie die Summe eines Verkaufs' oder 'Validieren Sie das Passwort eines Benutzers'. Die Fertigstellung von Features sollte nicht länger als zwei Wochen dauern, andernfalls sollten sie in kleinere Teile zerlegt werden.

Nach Funktion planen

Nachdem die Feature - Liste abgeschlossen ist, ist der nächste Schritt den Entwicklungsplan und assign Eigentum von Funktionen (oder Feature - Sets) zu produzieren Klassen zu Programmierern .

Design nach Funktion

Für jedes Feature wird ein Designpaket erstellt. Ein Chefprogrammierer wählt eine kleine Gruppe von Features aus, die innerhalb von zwei Wochen entwickelt werden sollen. Gemeinsam mit den entsprechenden Klassenbesitzern erarbeitet der Chefprogrammierer detaillierte Sequenzdiagramme für jedes Feature und verfeinert das Gesamtmodell. Als nächstes werden die Klassen- und Methodenprologe geschrieben und schließlich wird eine Designinspektion durchgeführt .

Nach Funktion bauen

Nachdem eine erfolgreiche Designprüfung für jede Aktivität zur Erstellung eines Features geplant ist, entwickeln die Klasseneigentümer Code für ihre Klassen. Nach Unit-Tests und erfolgreicher Code-Inspektion wird das fertige Feature zum Hauptbuild hochgestuft.

Meilensteine

Da Features klein sind, ist die Fertigstellung eines Features eine relativ kleine Aufgabe. Um genaue Statusberichte zu erstellen und den Überblick über das Softwareentwicklungsprojekt zu behalten, ist es wichtig, den Fortschritt bei jedem Feature zu markieren. FDD definiert daher pro Feature sechs Meilensteine, die nacheinander abgeschlossen werden sollen. Die ersten drei Meilensteine ​​werden während der Aktivität Design nach Feature abgeschlossen und die letzten drei werden während der Aktivität Build By Feature abgeschlossen . Um den Fortschritt zu verfolgen, wird jedem Meilenstein ein Prozentsatz der Fertigstellung zugewiesen. In der folgenden Tabelle sind die Meilensteine ​​und ihr Fertigstellungsgrad aufgeführt. Zu Beginn der Codierung ist ein Feature bereits zu 44 % fertig (Domain Walkthrough 1 %, Design 40 % und Design Inspection 3 % = 44 %).

Tabelle 1: Meilensteine
Domänen-Walkthrough Entwurf Designprüfung Code Code-Inspektion Zum Bauen werben
1% 40% 3% 45% 10% 1%

Empfohlene Vorgehensweise

Die funktionsorientierte Entwicklung basiert auf einem Kernsatz von Best Practices im Software-Engineering , die auf eine vom Kunden geschätzte Feature-Perspektive abzielen.

  • Modellierung von Domänenobjekten . Die Modellierung von Domänenobjekten besteht darin, die Domäne des zu lösenden Problems zu untersuchen und zu erklären. Das resultierende Domänenobjektmodell bietet einen Gesamtrahmen zum Hinzufügen von Funktionen.
  • Entwicklung nach Funktion . Jede Funktion, die zu komplex ist, um innerhalb von zwei Wochen implementiert zu werden, wird weiter in kleinere Funktionen zerlegt, bis jedes Teilproblem klein genug ist, um als Feature bezeichnet zu werden. Dies macht es einfacher, korrekte Funktionen zu liefern und das System zu erweitern oder zu modifizieren.
  • Individuelle Klasse (Code) Eigentum . Individuelle Klasseneigentümerschaft bedeutet, dass unterschiedliche Teile oder Gruppierungen von Code einem einzelnen Eigentümer zugewiesen werden. Der Eigentümer ist für die Konsistenz, Leistung und konzeptionelle Integrität der Klasse verantwortlich.
  • Feature-Teams . Ein Feature-Team ist ein kleines, dynamisch gebildetes Team, das eine kleine Aktivität entwickelt. Bei jeder Designentscheidung werden immer mehrere Denkweisen angewendet, und mehrere Designoptionen werden bewertet, bevor eine ausgewählt wird.
  • Inspektionen . Inspektionen werden durchgeführt, um eine gute Design- und Codequalität sicherzustellen, in erster Linie durch die Erkennung von Fehlern.
  • Konfigurationsmanagement . Das Konfigurationsmanagement hilft bei der Identifizierung des Quellcodes für alle bisher fertiggestellten Features und bei der Pflege eines Änderungsverlaufs an Klassen, wenn Feature-Teams diese verbessern.
  • Regelmäßige Builds . Regelmäßige Builds stellen sicher, dass immer ein aktuelles System zur Verfügung steht, das dem Kunden demonstriert werden kann und hilft, Integrationsfehler des Quellcodes für die Funktionen frühzeitig aufzudecken.
  • Sichtbarkeit von Fortschritt und Ergebnissen . Manager steuern ein Projekt durch häufige, angemessene und genaue Fortschrittsberichte auf allen Ebenen innerhalb und außerhalb des Projekts basierend auf abgeschlossener Arbeit.

Metamodell (Metamodellierung)

Prozessdatenmodell für FDD

Metamodellierung hilft sowohl die Prozesse als auch die Daten einer Methode zu visualisieren . Dadurch können Methoden verglichen und Methodenfragmente im Methodenentwicklungsprozess einfach wiederverwendet werden. Die Verwendung dieser Technik entspricht den UML- Standards.

Die linke Seite des Metadatenmodells zeigt die fünf grundlegenden Aktivitäten eines Softwareentwicklungsprojekts mit FDD. Die Aktivitäten enthalten alle Unteraktivitäten, die den Unteraktivitäten in der FDD-Prozessbeschreibung entsprechen. Die rechte Seite des Modells zeigt die beteiligten Konzepte. Diese Konzepte stammen aus den Aktivitäten, die auf der linken Seite des Diagramms dargestellt sind.

Benutztes Werkzeug

  • Doc Sheets . Doc Sheets ist ein kommerzielles Unternehmenstool für die funktionsorientierte Entwicklung.
  • TechExcel DevSuite . TechExcel DevSuite ist eine kommerzielle Suite von Anwendungen, die eine funktionsgesteuerte Entwicklung ermöglichen.
  • FDD-Tools . Das Projekt FDD Tools zielt darauf ab, ein plattformübergreifendes Open-Source-Toolkit zu entwickeln, das die Feature Driven Development-Methodik unterstützt.
  • FDD-Viewer . FDD Viewer ist ein Dienstprogramm zum Anzeigen und Drucken von Parkplätzen.

Siehe auch

Verweise

  • 1. ^ Coad, P. , Lefebvre, E. & De Luca, J. (1999). Java-Modellierung in Farbe mit UML: Enterprise Components and Process . Prentice Hall International. ( ISBN  0-13-011510-X )
  • 2. ^ Palmer, SR, & Felsing, JM (2002). Ein praktischer Leitfaden für die funktionsorientierte Entwicklung . Lehrlingssaal. ( ISBN  0-13-067615-2 )

Externe Links