() – 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 Metodyka FDD została opracowana przez w roku 1997, na potrzeby projektu realizowanego w dużym, singapurskim bankuPalmer, S. R., & Felsing, M. (2001). A practical guide to feature-driven development. Pearson Education.. 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 UMLCoad, P., Luca, J. D., & Lefebvre, E. (1999). Java modeling color with UML: Enterprise components and process with Cdrom. Prentice Hall PTR. autorstwa , Erica Lefebvre i Jeffa De Luci, wydanej w roku 1999. Kolejny, bardziej ogólny opis tej metodyki, został opublikowany w książce A practical guide to feature-driven development autorstwa Stephena Palmera i Maca Flesinga.
Założenia 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 FDD definiuje sześć ról kluczowych oraz szereg ról wspierających i dodatkowych.
Role kluczowe (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. (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. (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. (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. (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. (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 (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. (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. . Odpowiedzialny za proces budowania projektu. Zarządza systemem kontroli wersji, publikuje raporty i dokumentację oraz tworzy skrypty związane z wdrożeniami. (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. (administrator systemu). Konfiguruje, zarządza i rozwiązuje problemy związane z zasobami (siecią, serwerami, stacjami roboczymi) wykorzystywanymi w projekcie.
Role dodatkowe (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. . Zajmują się konwersją istniejących danych do nowych formatów, wymaganych przez tworzony system, oraz kwestiami związanymi z wdrażaniem nowych wersji oprogramowania. (twórcy dokumentacji technicznej). Odpowiedzialni za pisanie i redagowanie dokumentacji użytkownika.
Fazy projektu W FDD wyróżniono pięć faz projektu, z których dwie ostatnie są powtarzane wielokrotnie podczas projektu.
Budowa ogólnego modelu 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 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 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 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 Śledzenie postępu projektu w 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. dostarcza wzorce schematów pozwalających graficznie przedstawiać postęp prac dla różnych uczestników projektu.
Przypisy
Linki zewnętrzne http://www.featuredrivendevelopment.com/
Kategoria:Procesy tworzenia oprogramowania