Feature Driven Development

Feature Driven Development (FDD) - metodyka programowania należąca do grupy metodyk zwinnych inżynierii oprogramowania. Jej głównymi celami jest umożliwienie wytwarzania użytecznego oprogramowania w powtarzalny i efektywny sposób, zapewniając wiarygodne informacje o stanie projektu informatycznego dla wszystkich jego uczestników, z minimalnym narzutem na pracę programistyczną. Metodyka FDD wspomaga zarządzanie fazami analiz, projektowania i konstrukcji oprogramowania. Główną jej cechą jest realizacja projektu w krótkich iteracjach wynikających z wymagań użytkownika.

Spis treści

Rozwój standardu

FDD została opracowana w 1998 roku przez Jeffa De Luca i Petera Coada. Krótki opis metodyki został opublikowany w książce z 1999 r. Java Modeling in Color with UML, której współautorami są De Luca i Coad. Parę lat później, w 2002 r. Stephen Palmer i Mac Felsing w książce A Practical Guide to Feature-Driven Development dali czytelnikom znacznie bardziej rozbudowany opis metodyki FDD.

Zastosowanie

FDD jest, obok XP i Scrum 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.

Role w projekcie

Główne role wyróżnione w FDD to:
  • Kierownik projektu - jest odpowiedzialny za całość projektu. Zarządza zakresem, harmonogramem oraz zasobami.
  • 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.
  • Eksperci dziedzinowi - są to użytkownicy, klienci, sponsorzy, analitycy biznesowy lub dowolne ich połączenie. Ich zadaniem jest przekazanie programistom wiedzy na temat wymaganej funkcjonalności systemu.
  • Menedżer programistów - jest odpowiedzialny za zarządzanie całym zespołem programistów. Jego głównym zadaniem jest rozwiązywanie konfliktów o zasoby między pracującymi współbieżnie podzespołami.
  • Główny programista - doświadczony programista, 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 - programiści, którzy pracują pod kierownictwem głównego programisty. Ich zadaniem jest projektowanie szczegółowe, kodowanie, testowanie i dokumentowanie cech produktu.


Kluczowe praktyki

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. Kluczowe dla FDD są następujące praktyki:
  • Oparcie procesu o wymagania klienta - 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.
  • Architektura systemu - 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.
  • Krótkie iteracje - implementacja systemu powinna się odbywać w sposób iteracyjny. W kolejnych iteracjach jest realizowana wybrana porcja wymaganej funkcjonalności o najwyższym priorytecie. Zapewnia to zdecydowanie lepszą sterowalność projektem.
  • Indywidualna odpowiedzialność za kod - każda klasa wynikająca z projektu jest przypisywana programiście, który jest odpowiedzialny za jej implementację i rozwój. Główną 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.
  • Inspekcje - 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ż zapewniają przepływ wiedzy o produkcie między członkami zespołu oraz gwarantują przestrzeganie standardów kodowania w firmie.
  • Regularne budowanie produktu - 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.
  • Zarządzanie konfiguracją - 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 przechowuje się historię zmian wymagań.
  • Raportowanie i widoczność wyników - 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 zespołu.


Znaczenie

FDD opiera się na uznanym zbiorze najlepszych praktyk promowanych jako lekarstwo na problemy z efektywną realizacją projektów informatycznych. Odpowiednio zdefiniowany proces bardzo mocno nastawiony na implementację oczekiwanej przez klienta funkcjonalności, precyzyjnie opisane role i odpowiedzialności członków zespołu oraz wsparcie dla zarządzania projektem sprawiają, że FDD jest 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 tej 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.

Opis

W FDD wyróżniono pięć faz projektu, z których dwie ostatnie są powtarzane wielokrotnie podczas projektu.



  • Budowa ogólnego modelu (ang. an overall model) - na początku projektu zespół projektowy opracowuje model systemu, zapewniający wspólne rozumienie jego architektury i stanowiący przewodnik do jego budowy podczas następnych faz. 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 grupach projektowych
    • wypracowanie wspólnego modelu
    • zatwierdzenie ogólnego modelu
    • zarchiwizowanie istotnych założeń dotyczących projektu i alternatywnych rozwiązań
  • Budowa listy cech (ang. feature list) - wymagania użytkowe do systemu są gromadzone w postaci listy cech. Cechy są funkcjami systemu, które:
    • są niewielkie,
    • pełnią użyteczną funkcję,
    • dają się zdefiniować przy pomocy pojedynczego zdania (np. w systemie dla hotelu może to być Rezerwacja pokoju dla klienta)
  • Planowanie implementacji cech (ang. plan by feature). - faza ta 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.
  • Projektowanie i implementacja (ang. design and build by feature) - istotą FDD jest dostarczanie kolejnych, „działających” wersji produktu w krótkich iteracjach składających się z projektowania szczegółowego oraz implementacji wybranego zbioru cech produktu. Cechy zakwalifikowane do realizacji w danej iteracji są przydzielane do realizacji dynamicznie tworzonym zespołom programistów (ang. feature team). Proces projektowania szczegółowego składa się m.in. z sformowania zespołu programistów pod kierunkiem Głównego Programisty, opcjonalnego przeglądu dziedziny problemu i studiowania dokumentów referencyjnych czy uszczegółowienia modelu obiektowego. Natomiast w fazie implementacji programiści wykonują takie zadania jak:
    • implementacja kodu klas
    • przeprowadzenie inspekcji kodu.
    • testowanie jednostkowe
    • integracja nowego kodu z produktem


Zobacz też

Linki zewnętrzne

Bibliografia

ostatnia modyfikacja 20 sierpnia 2016 r.