Feature Driven Development – lekka metodyka tworzenia oprogramowania

Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami analiz, projektowania i konstrukcji oprogramowania. Główną cechą FDD jest realizacja projektu w krótkich iteracjach wynikających z wymagań użytkownika. FDD została opracowana w 1998 roku przez Jeffa De Luca i Petera Coada. Krótki opis metodyki został opublikowany w książce „Java Modeling in Color with UML”, której współautorami są De Luca i Coad [CLDL1999]. FDD jest, obok eXtreme Programming, Scrum, Agile Modeling, przedstawicielem tzw. lekkich metodyk tworzenia oprogramowania, które w ostatnich latach zdobywają coraz większą popularność. Metody te, kładące nacisk na komunikację między członkami zespołu i klientami oraz elastyczność w doborze technik, pozwalają na szybsze dostarczanie zamówionego produktu przy zachowaniu odpowiedniej jakości.

Głównym elementem FDD jest pojęcie cechy (ang. feature) produktu. Cecha to mały fragment funkcjonalności produktu, mający wartość z punktu widzenia klienta, tzn. dostarczający interesujących dla niego wyników. Cecha powinna być na tyle „mała”, aby czas jej realizacji nie przekraczał 2 tygodni. Cechy są sposobem opisu wymagań funkcjonalnych klienta. Są one specyfikowane zgodnie ze schematem:

<action> the <result> <by|of|to|from|for> a(n) <object>

total the value of the sale
calculate the interest for the bank account
total the hours worked for the pilot

Biznesowo powiązane ze sobą cechy są grupowane w zbiory cech (ang. features set). Taki zbiór cech może być zrealizowany w postaci jednego komponentu. Zbiór cech jest specyfikowany zgodnie ze schematem:

<action>-ing <business deliverable> <by|of|to|from|for> a(n) <object>

creating an account for a customer
making a bank loan to a customer
assessing the inventory levels for a warehouse

Zbiór cech może być implementowany iteracyjne i ma dla klienta realną wartość biznesową.W bardziej skomplikowanych projektach wyróżnia się podsystemy, zwane w FDD obszarami przedmiotowymi (ang. subject area). Obszary przedmiotowe są nazywane zgodnie z następującą konwencją:

<object> management

customer management
account management
product management
resource management

Proces tworzenia oprogramowania w FDD składa się z pięciu opisanych niżej faz. Każda faza jest krótko zdefiniowana (1-3 strony) przez określenie:

• kryteriów wejściowych,

• zbioru zadań ze wskazaniem, kto jest odpowiedzialny za wykonanie oraz znacznika czy zadanie jest obligatoryjne,

• kryteriów wyjściowych.

W definicji FDD występują następujące kluczowe role:

• menadżer projektu,

• eksperci dziedzinowi,

• główny architekt,

• menadżer programistów,

• główni programiści,

• właściciele klas.

Menadżer projektu jest odpowiedzialny za całość projektu. Zarządza zakresem, harmonogramem oraz zasobami.

Ekspertami dziedzinowymi są użytkownicy, klienci, sponsorzy, analitycy biznesowy lub dowolne ich połączenie. Ich zadaniem jest przekazanie programistom wiedzy na temat wymaganej funkcjonalności systemu.

Główny architekt jest odpowiedzialny za ogólny projekt systemu. Jest to techniczna funkcja wymagająca doskonałych umiejętności technicznych i analitycznych, jak również zdolności komunikacyjnych z ekspertami i pozostałymi członkami zespołu projektowego.

Menadżer programistów jest odpowiedzialny za zarządzanie całym zespołem programistów. Jego głównym zadaniem rozwiązywanie konfliktów o zasoby między pracującymi współbieżnie podzespołami.

Główny programista jest doświadczonym programistą, który jest odpowiedzialny za implementację przydzielonego mu zbioru cech produktu. Bierze aktywny udział w analizie wymagań oraz projektowaniu architektury rozwiązania. Kieruje podzespołem złożonym z 3-6 programistów przypisanych do realizacji danego zbioru cech.

Właściciele klas to programiści, którzy pracują pod kierownictwem głównego programisty. Ich zadaniem jest projektowanie szczegółowe, kodowanie, testowanie i dokumentowanie cech produktu.

FDD składa się z pięciu podstawowych procesów przydstawionych na rysunku 1.

Zadaniem tego etapu jest stworzenie ogólnego modelu funkcji biznesowych realizowanego produktu (ang. an overall model). Ogólny model powinien dostarczać wiedzy o wszystkich wymaganych funkcjach bez specjalnego zagłębiania się w szczegóły. Jest on wspólnym dziełem analityków i programistów oraz przyszłych użytkowników, którzy są najlepszymi ekspertami z dziedziny produktu. Zaangażowanie użytkownika ma kluczowe znaczenie dla sukcesu projektu. Pozwala na wspólne rozumienie problemów przez użytkowników i programistów oraz minimalizuje „niejawne” założenia czynione prze jedną lub drugą stronę.

Na realizację tej fazy składają się następujące zadania:

• Stworzenie zespołu projektowego pod kierownictwem Głównego Architekta.

• Przeprowadzenie przeglądu dziedziny problemu.

• Studiowanie dokumentów z wymaganiami i z dziedziny problemu.

• Przygotowanie alternatywnych modeli w oddzielnych małych prupach projektowych.

• Wypracowanie wspólnego modelu.

• Zatwierdzenie ogólnego modelu.

• Zdokumentowanie istotnych założeń dotyczących projektu i alternatywnych rozwiązań.

W oparciu o model opracowany w fazie 1 tworzona jest lista cech produktu (ang. feature list), które zapewnią dostarczenie wymaganej przez klienta funkcjonalności. W pierwszym kroku wyodrębnia się obszary przedmiotowe odpowiadające głównym fragmentom funkcjonalnym. Następnie każdy obszar przedmiotowy jest dzielony na poszczególne aktywności, czyli zbiory cech. Każdy krok w aktywności jest identyfikowany jako cecha. W wyniku tego kroku powstaje hierarchicznie uporządkowana lista cech produktu.

Faza 3 ma na celu przygotowanie planu określającego w jakiej kolejności cechy będą implementowane (ang. plan by feature). W tym procesie brane są pod uwagę takie czynniki jak priorytet danej cechy, zależności między cechami, złożoność implementacyjna oraz stopień obciążenia zespołu programistów. Ważnym kryterium jest również podział całego projektu na „zewnętrznie” obserwowalne etapy, czyli kroki milowe (ang.milestones) w projekcie. Efektem tej fazy jest plan implementacji, który określa datę (miesiąc, rok) realizacji każdego zbioru cech. Za każdy zbiór cech jest odpowiedzialny wyznaczony Główny Programista. Znany jest również przydział poszczególnych klas programistom, którzy będą je realizowali. Realizacja zadań w tej fazie składa się z:

• Sformowania zespołu planującego.

• Określenia kolejności implementacji.

• Przypisania zbioru cech do Głównych Programistów.

• Przypisania klas do programistów.

Istotą FDD jest dostarczanie kolejnych, „działających” wersji produktu w krótkich iteracjach składających się z projektowania szczegółowego (ang. design by feature) oraz implementacji (ang. build by feature) wybranego zbioru cech produktu. Cechy zakwalifikowane do realizacji w danej iteracji są przydzielane do realizacji dynamicznie tworzonym zespołom programistów (ang. feature team). Taki mały zespół typowo składa się z 2-3 programistów. Zadaniem zespołu jest implementacja małego zbioru cech. Kod danej cechy jest pisany przez członka zespołu, któremu została przypisana klasa biznesowa związana z funkcjonalnością danej cechy. Napisany kod podlega przeglądowi przez pozostałych członków zespołu. Po pomyślnym wykonaniu testów jednostkowych nowy kod nadaje się do integracji z resztą produktu, który staje się bogatszy o kolejną cechę.Proces projektowania szczegółowego składa się z następujących zadań:

• Sformowania zespołu programistów pod kierunkiem Głównego Programisty.

• Opcjonalnego przeglądu dziedziny problemu i studiowania dokumentów referencyjnych.

• Stworzenia diagramów sekwencji (ang. sequence diagram)

• Uszczegółowienia modelu obiektowego.

• Zapisania nagłówków klas i metod.

• Inspekcji projektu.

Natomiast w fazie implementacji programiści wykonują takie zadania jak:

• Implementacja kodu klas.

• Przeprowadzenie inspekcji kodu.

• Testowanie jednostkowe.

• Integracja nowego kodu z produktem.

FDD podobnie jak inne lekkie metody bazuje na zbiorze najlepszych praktyk (ang. best practices), których stosowanie w połączeniu ze zdefiniowanym procesem tworzenia oprogramowania zapewnia efektywne wykonanie projektu [PAFE2002]. Kluczowe dla FDD są następujące praktyki:

• Oparcie procesu o wymagania klienta.

• Architektura systemu.

• Krótkie iteracje.

• Indywidualna odpowiedzialność za kod.

• Inspekcje.

• Regularne budowanie produktu.

• Zarządzanie konfiguracją.

• Raportowanie i widoczność wyników.

Cały proces tworzenia oprogramowania w FDD koncentruje się wokół wymagań klienta. Architektura obiektowa systemu jest projektowana w oparciu o analizę wymagań użytkownika, które specyfikowane są jako cechy. Planowanie całego projektu bazuje na liście wymaganych cech produktu. Istotą inkrementalnej implementacji produktu jest dostarczanie wersji produktu zawierających wybrane cechy produktu. Zaletą FDD jest prezentacja postępów w projekcie poprzez raportowanie, które zamówione cechy zostały już wykonane (ang. track by feature). Jest to sposób obiektywny i łatwo zrozumiały dla klienta.

W FDD, podobnie jak w Rational Unified Process, akcentowane jest znaczenie opracowania ogólnego modelu obiektowego projektowanego systemu. Zarysowana w ten sposób architektura rozwiązania stanowi podstawę podejmowania dalszych decyzji technicznych w projekcie. Wczesne opracowanie ogólnego modelu ma szereg zalet:

• Umożliwia lepsze zrozumienie całości systemu, gdyż pozwala na szybką weryfikację pomysłów i założeń programistów w kontaktach z ekspertami z dziedziny problemu.

• Jest istotnym czynnikiem w opracowywaniu inkrementalnego planu implementacji, ponieważ uwidacznia zależności między głównymi składnikami systemu.

• Definiując szerszy kontekst dla projektowania szczegółowego klas implementowanych w danej iteracji powoduje, że są one lepiej przygotowane do użycia w kolejnych iteracjach.

• Ułatwia wprowadzanie modyfikacji do systemu wynikających ze zmian wymagań użytkownika.

Implementacja systemu powinna się odbywać w sposób iteracyjny. W kolejnych iteracjach jest realizowana wybrana porcja wymaganej funkcjonalności o najwyższym priorytetcie. Zapewnia to zdecydowanie lepszą sterowalność projektem.Dostarczając klientowi działającą wersję produktu z jednej strony informujemy klienta o postępie w projekcie, z drugiej strony ewaluacja ze strony klienta upewnia nas, że realizujemu właściwą funkcjonalność zgodnie z jego oczekiwaniami. Istotną zaletą takiego podejścia jest to, że w razie konieczności po każdej iteracji klient może podjąć decyzję o wdrożeniu danej wersji do produkcji. Planowanie iteracji w FDD jest oparte na tym, że implementacja opisanej w wymaganiach cechy produktu nie może przekraczać dwóch tygodni.

Każda klasa wynikająca z projektu jest przypisywana programiście, który jest odpowiedzialny za jej implementację i rozwój. Głowną zaletą takiego podejścia jest to, że „właściciel” klasy może szybciej wykonać jej modyfikacje niż inna osoba nie znająca tego fragmentu kodu. Duże znaczenie ma również identyfikacja programisty z fragmentem systemu, który może być dumny z dobrze wykonanego modułu.

FDD opiera się na inspekcjach, które są sposobem na zapewnienie wysokiej jakości projektów i kodu. Inspekcje są nie tylko mechanizmem wczesnego wykrywania błędów, ale również przepływ wiedzy o produkcie między członkami zespołu oraz zapewniają przestrzeganie standardów kodowania w firmie.Inspekcje są propagowane od lat 70. jako bardziej efektywny mechanizm usuwanie usterek niż testowanie. Głównym problemem w ich stosowaniu są trudności z przełamaniem „naturalnego” oporu programistów przed poddawaniem się ocenie. W FDD idealnym miejscem do inspekcji jest zespół powołany do implementacji danej cechy (ang.feature team). Główny programista kontroluje stopień formalizacji inspekcji dostosowując go do składu zespołu oraz złożoności i znaczenia implementowanych cech.

Regularne budowanie produktu pomaga wcześniej wykrywać błędy integracyjne. Praktyka ta jest szczególnie efektywna, jeśli możliwe jest automatyczne wykonywanie testów regresywnych opartych o testy przygotowane przez zespoły realizujące konkretne cechy. Zaletą tego podejścia jest również, że zawsze możemy pokazać klientowi działający produkt zawierający całą zrealizowaną dotychczas funkcjonalność.Częstotliwość budowania produktu jest uzależniona od złożoności tego procesu w konkretnym projekcie.

FDD postuluje, aby w systemie zarządzania konfiguracją przechowywać nie tylko kod źródłowy produktu, ale również inne efekty pracy projektantów i programistów powstające w trakcie prac nad projektem. Najważniejsze jest przechowywanie dokumentacji wymagań użytkownika, gdyż w ten sposób przechowujemy historię zmian wymagań. Ma to szczególne znaczenie jeśli wymagania określają wzjemne zobowiązania kontraktowe między klientem a wykonawcą. Podobnie wyniki analizy i projektów powinny być przechowywane w systemie kontroli wersji, ponieważ ułatwia to śledzenie ich modyfikacji.

Skuteczne zarządzanie projektem wymaga odpowiedniej informacji o aktualnym stanie jego realizacji. FDD zapewnia prostą i nie wymagającą specjalnego wysiłku metodę zbierania danych o stanie zadań. Monitorowanie stanu projektu jest oparte o cechy produktu. Metodyka sugeruje również formaty raportów zbiorczych dla klienta i na użytek wewnętrzny zaspołu.

Od kilku lat dużym zainteresowaniem cieszą się lekkie metodyki tworzenia oprogramowania, określane angielskim terminem „agile methods”. Najbardziej znanym przedstawicielem tego trendu jest eXtreme Programming, więc inne metodyki są zwykle z nią porównywane. XP, podobnie jak inne lekkie metodyki, jest oparte o zbiór najlepszych praktyk. W części praktyki są oczywiście podobne, ale w istotnym zakresie XP i FDD prezentują istotnie różne podejścia.Podobieństwa między obu metodykami rozpoczynają się od celu jaki sobie one stawiają. Tym celem jest umożliwienie szybszego dostarczania działających wersji produktu przy zapewnieniu odpowiedniej jakości. W odróżnieniu od tradycyjnych metodyk kładących nacisk na zgodność ze ściśle zdefiniowanym procesem i jego wymaganiami dokumentacyjnymi obie omawiane metodyki są zorientowane na ludzi biorących udział w projekcie i efektywność ich wzajemnej komunikacji. Zamiast tradycyjnego odseparowania analityków, programistów, ekspertów dziedzinowych i samych użytkowników promowana jest ich wspólna praca w jednym miejscu. Istotną cechą wszystkich lekkich metodyk jest inkrementalne podejście do implementacji produktu. Implementacja produktu powinna być realizowana w krótkich iteracjach, których efektem jest działająca wersja produktu. Takie podejście pozwala na wczesne udostępnianie działających wersji użytkownikom do ewaluacji i minimalizuje niebezpieczeństwo rozminięcia się z ich oczekiwaniami.

Omówmy krótko podstawowe różnice między FDD i XP.

W XP analiza wymagań funkcjonalnych opiera się na opisach zastosowania (ang. users stories), które definiują co system powinien robić. XP określa metaforę (ang. metaphor) jako całościowy opis działania systemu. Do każdej kolejnej iteracji wybierany jest podzbiór opisów zastosowania, który jest następnie dzielony na zadania. Sposób postępowania jest tu więc podobny do FDD, gdzie również wykonywana jest analiza dziedziny problemu i formułowana jest lista cech systemu do implementacji. Jednakże FDD idzie o krok dalej i postuluje stworzenie ogólnego modelu obiektowego projektowanego systemu. Ma to poważną zaletę, gdyż przygotowanie ogólnego modelu pełniącego funkcję zarysu obiektowej architektury systemu umożliwia wczesne skonfrontowanie idei projektantów i programistów z ekspertami dziedzinowymi i użytkownikami. Zarys architektury całego systemu pozwala na lepsze projektowanie szczegółowe zbioru cech do implementacji w kolejnej iteracji, ponieważ jest wykonywane z szerszej perspektywy niż w przypadku XP. Pozwala to zmniejszyć liczbę zmian w kodzie wynikających z konieczności dostosowania istniejących już klas do wymagań aktualnie implementowanych cech produktu. XP koncentrując się na wybranym do implementacji zbiorze cech można nie przewidzieć wszystkich zależności od klas, które będą dodawane w następnych iteracjach. Ogólny model obiektowy w FDD daje szanse na uniknięcie tego typu niedoskonałości.

XP promuje kolektywną odpowiedzialność (ang. collective ownership) za kod produktu. Każdy programista może dodać lub usunąć dowolny fragment kodu w zależności od potrzeb. Podejście FDD jest odmienne, gdyż każda klasa jest przydzielana do realizacji konkretnemu programiście, który jest za nią odpowiedzialny. Według XP w małych zespołach można zakładać, że wszyscy jednakowo znają cały kod produktu i w zasadzie jest wszystko jedno kto dokonuje modyfikacji. To, że każdy może to swobodnie robić ma poprawić efektywność pracy, gdyż nie trzeba czekać, aż inny pracownik wprowadzi postulowane zmiany do kodu. FDD preferuje przypisywanie odpowiedzialności za klasy konkretnym programistom. Natomiast problemy adresowane kolektywną odpowiedzialnością w XP są w FDD rozwiązywane w inny sposób. Inspekcje projektów i kodu minimalizują potrzeby zmian w kodzie, gdyż dają szanse wpływu na postać kodu danej klasy innym programistom. Jednocześnie wiedza na temat danego modułu jest współdzielona z innymi członkami zespołu, którzy w razie potrzeby mogą dokonać koniecznych zmian. Dodatkowo w większych zespołach trudno oczekiwać, że wszyscy programiści będą mieli szczegółową wiedzę umożliwiającą efektywne modyfikowanie kodu dowolnej klasy w systemie. Z doświadczenia autora wynika również, że przypisanie odpowiedzialności za fragmenty programu polepsza jakość systemu. Programiści po prostu dbają o „swój” kod.

Powszechnie wiadomo, że przeglądy projektów i kodu są bardziej efektywne w usuwaniu defektów niż testowanie. Istotna jest również rola edukacyjna przeglądów, gdyż programiści uczą się wzajemnie oraz poznają kod innych klas w systemie. Dodatkowo można w ten sposób zapewnić przestrzeganie standardów kodowania obowiązujących w firmie.XP postuluje programowanie w parach (ang. pair programming) jako sposób na inspekcje kodu i projektów. Bardziej tradycyjne podejście do przeglądów promowane przez FDD, w świetle doświadczeń autora, wydaje się lepiej pasować do preferencji programistów, gdyż daje im szansę na wywarcie indywidualnego piętna na przydzielonym im fragmencie produktu.

Dużą uwagę w metodyce XP przywiązuje się do testowania jednostkowego (ang. unit testing). Technika najpierw pisz testy (ang. write tests first) w połączeniu ze środowiskiem automatyzującym uruchamiania testów powoduje, że ten element XP jest niezwykle popularny. FDD również nie zapomina o testach jednostkowych, jednakże postulat ten pozostaje na poziomie ogólnym i konkretny sposób realizacji tego typu testów pozostaje do uznania Głównego Programisty. Podejście XP do tej praktyki jest zdecydowanie lepsze. Realizacja testów wsparta środowiskiem automatyzującym wykonywanie testów jednostkowych daje ogromne zalety, głównie w zakresie testów regresywnych budowanego systemu.

Największą słabością XP jest praktyczne pominięcie zagadnień związanych z zarządzaniem projektem. Natomiast FDD docenia konieczność gromadzenia danych o postępach w projekcie oraz udostępniania odpowiednich raportów dla udziałowców projektu. Oczywiście podstawową jednostką gromadzenia danych i raportowania są cechy produktu. Lista cech z aktualną informacją o stanie zaawansowania implementacji stanowi efektywne narzędzie monitorowania projektu i pozwala na odpowiednie korygowanie dalszych planów.

W pracy przedstawiono Feature Driven Development oraz jej porównanie z eXtreme Programming. FDD bazuje na uznanym zbiorze najlepszych praktyk promowanych jako panaceum na problemy z efektywną realizacją projektów informatycznych. Dobrze zdefiniowany proces bardzo mocno zorientowany na implementację oczekiwanej przez klienta funkcjonalności, precyzyjnie opisane role i odpowiedzialności członków zespołu oraz wsparcie dla zarządzania projektem czyni FDD godnym polecenia dla firm chcących usprawnić swój proces tworzenia oprogramowania. Przydatność FDD potwierdziła się w wielu projektach realizowanych również przez autorów metodyki, które zakończyły się sukcesem. Skalowalności metodyki FDD dowodzą dość duże projekty, w których realizację zaangażowane były zespoły liczące nawet do 250 osób [HIGH2002].