Feature-driven development

Z Wikipedii, wolnej encyklopedii
(Przekierowano z Feature Driven Development)
Przejdź do nawigacji Przejdź do wyszukiwania

Feature-driven development (FDD) – metodyka programowania należąca do grupy metodyk zwinnych inżynierii oprogramowania (z których najbardziej znaną jest programowanie ekstremalne). 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 do wszystkich jego uczestników, z minimalnym narzutem na pracę programistyczną.

Historia[edytuj | edytuj kod]

Metodyka FDD została opracowana przez Jeffa De Luca w roku 1977, na potrzeby projektu realizowanego w dużym, singapurskim banku[1]. Rezultatem był zestaw pięciu procesów, pokrywających ogólny model, wyliczenie, planowanie, modelowanie oraz tworzenie funkcji systemu. Od czasu pierwszego udanego wykorzystania, pojawiło się kilka implementacji FDD.

Pierwszy opis FDD pojawił się w szóstym rozdziale książki Java modeling in color with UML[2] autorstwa Petera Coada, Erica Lefebvre i Jeffa De Luca, wydanej w roku 1999. Kolejny, bardziej ogólny opis tej metodyki, został opublikowany w książce A practical guide to feature-driven development[1] autorstwa Stephena Palmera i Maca Flesinga.

Założenia[edytuj | edytuj kod]

  • FDD jest zwinną metodyką oprogramowania
  • Zapewnia dostateczną strukturę dla prac większych zespołów
  • Kładzie nacisk na jakość wytwarzanego oprogramowania
  • Kolejne wersje oprogramowania powstają często i zawierają nowe użyteczne funkcje
  • Zapewnia mechanizmy do wiarygodnego śledzenia postępu prac
  • W FDD są używane testy jednostkowe
  • FDD zakłada przypisanie kodu (klas) do właścicieli (programistów)
  • Podczas implementacji wykonywane są inspekcje kodu

Role osób w projekcie[edytuj | edytuj kod]

FDD definiuje sześć ról kluczowych oraz szereg ról wspierających i dodatkowych[1].

Role kluczowe[edytuj | edytuj kod]

  • Project manager (kierownik projektu). Główny zarządca projektu, którego zadaniem jest kreowanie i zarządzanie środowiskiem w taki sposób, aby system działał jak najlepiej, a zespół mógł być produktywny i wydajny.
  • Chief architect (główny architekt). Jest odpowiedzialny za całościowy projekt systemu. Podejmuje ostateczne decyzje w przypadku wszystkich problemów związanych z architekturą systemu i jest odpowiedzialny za przeprowadzenie zespołu przez wszelkie trudności techniczne.
  • Development manager (kierownik rozwoju). Odpowiedzialny za nadzorowanie codziennych czynności związanych z rozwojem systemu. Rozwiązuje problemy związane z zasobami. Czasami rola ta łączona jest z rolą kierownika projektu lub głównego architekta.
  • Chief programmers (główni programiści). Doświadczeni programiści, którzy przynajmniej kilka razy przeszli przez cały cykl rozwoju oprogramowania. Biorą udział w analizie wymagań oraz projektowaniu architektury oraz są odpowiedzialni za zarządzanie małymi zespołami, składającymi się z od trzech do sześciu programistów.
  • Class owners (właściciele klas). Programiści, którzy pracują w zespołach zarządzanych przez głównych programistów. Ich rola polega na projektowaniu, programowaniu, tworzeniu testów oraz pisaniu dokumentacji do tworzonych funkcji.
  • Domain experts (eksperci dziedzinowi) – Użytkownicy, klienci, sponsorzy i analitycy biznesowi. Ich zadanie polega na wykorzystaniu dogłębnej znajomości biznesu w celu wytłumaczenia programistom, jakie funkcje są wymagane od tworzonego systemu. Ich wsparcie pozwala upewnić się, że tworzony jest właściwy system.

Role wspierające[edytuj | edytuj kod]

  • Release Manger (manager wdrożeń). Pilnuje, by główni programiści raportowali postępy zgodnie z założeniami FDD, a założone terminy były dotrzymywane. Odpowiada bezpośrednio przed kierownikiem projektu.
  • Language guru (guru języka). Osoba, która posiada dogłębną znajomość wykorzystywanego języka programowania lub technologii. Jest szczególnie istotna, kiedy język programowania lub technologia jest wykorzystywana przez zespół po raz pierwszy.
  • Build engineer. Odpowiedzialny za proces budowania projektu. Zarządza systemem kontroli wersji, publikuje raporty i dokumentację oraz tworzy skrypty związane z wdrożeniami.
  • Toolsmith (twórca programów narzędziowych). Tworzy małe narzędzia dla deweloperów, testerów i zespołu odpowiedzialnego za zarządzanie danymi. Tworzone narzędzia są dedykowane dla konkretnego projektu.
  • System Administrator (administrator systemu). Konfiguruje, zarządza i rozwiązuje problemy związane z zasobami (siecią, serwerami, stacjami roboczymi) wykorzystywanymi w projekcie.

Role dodatkowe[edytuj | edytuj kod]

  • Testers (testerzy). Niezależni od programistów testerzy oprogramowania. Zespół testowy może stanowić część zespołu projektowego lub zostać oddelegowany z działu kontroli jakości niezwiązanego z konkretnym projektem.
  • Deployers. Zajmują się konwersją istniejących danych do nowych formatów, wymaganych przez tworzony system, oraz kwestiami związanymi z wdrażaniem nowych wersji oprogramowania.
  • Technical Writers (twórcy dokumentacji technicznej). Odpowiedzialni za pisanie i redagowanie dokumentacji użytkownika.

Fazy projektu[edytuj | edytuj kod]

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

Budowa ogólnego modelu[edytuj | edytuj kod]

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.

Budowa listy cech[edytuj | edytuj kod]

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)

Cechy są grupowane w grupy i obszary funkcjonalne.

Planowanie według cech[edytuj | edytuj kod]

W uzgodnieniu z klientem układany jest plan tworzenia oprogramowania według udokumentowanych cech. Cechom przypisywany jest priorytet, określana jest ich pracochłonność i związane z nimi ryzyko, a następnie cechy są układane w kolejności w jakiej będą implementowane.

Projekt według cech i Implementacja według cech[edytuj | edytuj kod]

Dwie ostatnie fazy powtarzają się iteracyjnie do końca projektu. Na czas każdej iteracji tworzony jest zespół składający się z właścicieli klas zmienianych w ramach implementacji danej grupy cech. Zespół wykonuje szczegółowy projekt (być może modyfikując główny projekt stworzony w pierwszej fazie), a następnie implementuje zaplanowane cechy. Po każdej iteracji klientowi dostarczana jest kolejna wersja oprogramowania.

Śledzenie postępu projektu[edytuj | edytuj kod]

Śledzenie postępu projektu w FDD dotyczy dwóch ostatnich faz (Projektowania i implementacji według cech). Procent wykonania projektu wynika z liczby zrealizowanych cech w stosunku do ogólnej ich liczby. FDD dostarcza wzorce schematów pozwalających graficznie przedstawiać postęp prac dla różnych uczestników projektu.

Przypisy[edytuj | edytuj kod]

  1. a b c Palmer, S. R., & Felsing, M. (2001). A practical guide to feature-driven development. Pearson Education.
  2. Coad, P., Luca, J. D., & Lefebvre, E. (1999). Java modeling color with UML: Enterprise components and process with Cdrom. Prentice Hall PTR.

Linki zewnętrzne[edytuj | edytuj kod]