Kasprzyk Andrzej - Feature driven development - страница 1

Страницы:
1 

Feature Driven Development

lekka metodyka tworzenia oprogramowania

 

 

 

 

 

 

 

 

Kasprzyk Andrzej IS II

Wstep

 

 

Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, ktora wspomaga zarz^dzanie fazami analiz, projektowania i konstrukcji oprogramowania. Gl6wn<| cech<| FDD jest realizacja projektu w krotkich iteracjach wynikaj^cych z wymagan uzytkownika. FDD zostala opracowana w 1998 roku przez Jeffa De Luca i Petera Coada. FDD jest, obok eXtreme Programming, Scrum, Agile Modeling, przedstawicielem tzw. lekkich metodyk tworzenia oprogramowania, ktore w ostatnich latach zdobywaj^ coraz wi^ksz<| popularnosc. Metody te, klad^ce nacisk na komunikacje? mi^dzy czlonkami zespolu i klientami oraz elastycznosc w doborze technik, pozwalaj^ na szybsze dostarczanie zamowionego produktu przy zachowaniu odpowiedniej jakosci.

Istota FDD

 

 

Glownym elementem FDD jest poj^cie cechy (ang. feature) produktu. Cecha to maly fragment funkcjonalnosci produktu, maj^cy wartosc z punktu widzenia klienta, tzn. dostarczaj^cy interesuj^cych dla niego wynikow. Cecha powinna byc na tyle „mala", aby czas jej realizacji nie przekraczal 2 tygodni. Cechy sj£ sposobem opisu wymagan funkcjonalnych klienta.

Kluczowe role w FDD

         menadzer projektu,

         eksperci dziedzinowi,

         glowny architekt,

         menadzer programistow,

         glowni programisci,

         wlasciciele klas.

Menadzer projektu

 

 

jest odpowiedzialny za calosc projektu. Zarz^dza zakresem, harmonogramem oraz zasobami.

Eksperci dziedzinowi

 

 

nimi uzytkownicy, klienci, sponsorzy, analitycy biznesowi lub dowolne ich pol^czenie. Ich zadaniem jest przekazanie programistom wiedzy na temat wymaganej funkcjonalnosci systemu.

Gtowny architekt

 

 

jest odpowiedzialny za ogolny projekt systemu. Jest to techniczna funkcja wymagaj^ca doskonalych umiej^tnosci technicznych i analitycznych, jak rowniez zdolnosci komunikacy'nych z ekspertami i pozostalymi czlonkami zespolu projektowego.

Menadzer programistow

 

 

jest odpowiedzialny za zarz^dzanie calym zespolem programistow. Jego glownym zadaniem jest rozwi^zywanie konfliktow o zasoby mi^dzy pracuj^cymi wspolbieznie podzespolami.

Gtowny programista

 

 

jest doswiadczonym programist^, ktory jest odpowiedzialny za implementacj^ przydzielonego mu zbioru cech produktu. Bierze aktywny udzial w analizie wymagan oraz projektowaniu architektury rozwi^zania. Kieruje podzespolem zlozonym z 3-6 programistow przypisanych do realizacji danego zbioru cech.

Wtasciciele klas

 

 

to programisci, ktorzy pracujj* pod kierownictwem glownego programisty. Ich zadaniem jest projektowanie szczegolowe, kodowanie, testowanie i dokumentowanie cech

Fazy procesu FDD

 

Kliknij, aby edytowac style 1 wzorca tekstu ° Drugi poziom


poziom

rty poziom '.. Л Piqty poziom


4 Projekt

implementacji cechy


 

*—►


SRealizacja

cechy

 

Model obieklowy meformalna lista cech nozwiazania alternatywna

Uporza.dkowana lista cech

Plan implementacji

Pnojekl

szczegfllcwy

Dziatajqca ftjnkqonalnosc ufyikownika

Fazy procesu FDD

         tworzenie ogolnego modelu,

         budowanie listy cech,

         planowanie implementacji cech,

         projektowanie,

         implementacja.

Faza 1- Tworzenie ogolnego modelu

 

 

Zadaniem tego etapu jest stworzenie ogolnego modelu funkcji biznesowych realizowanego produktu (ang. an overall model). Ogolny model powinien dostarczac wiedz? o wszystkich wymaganych funkcjach bez specjalnego zagl?biania si? w szczegoly. Jest on wspolnym dzielem analitykow i programistow oraz przyszlych uzytkownikow, ktorzy    najlepszymi ekspertami z dziedziny produktu. Zaangazowanie uzytkownika ma kluczowe znaczenie dla sukcesu projektu. Pozwala na wspolne rozumienie problemow przez uzytkownikow i programistow oraz minimalizuje „niejawne" zalozenia czynione prze jedn^ lub drugij stron?.

Tworzenie ogolnego modelu cd.

      stworzenie zespolu projektowego pod kierownictwem Glownego Architekta,

      przeprowadzenie przegl^du dziedziny problemu,

      studiowanie dokumentow z wymaganiami i z dziedziny

problemu,

      przygotowanie alternatywnych modeli w oddzielnych malych grupach projektowych,

      wypracowanie wspolnego modelu,

      zatwierdzenie ogolnego modelu,

      zadokumentowanie istotnych zalozen dotycz^cych projektu i alternatywnych rozwi^zan.

Faza 2 - Budowanie listy cech

 

 

W oparciu o model opracowany w fazie 1 tworzona jest lista cech produktu (ang. feature list), ktore zapewnia. dostarczenie wymaganej przez klienta funkcjonalnosci. W pierwszym kroku wyodr?bnia si? obszary przedmiotowe odpowiadajace glownym fragmentom funkcjonalnym. Nast?pnie kazdy obszar przedmiotowy jest dzielony na poszczegolne aktywnosci, czyli zbiory cech. Kazdy krok w aktywnosci jest identyfikowany jako cecha. W wyniku tego kroku powstaje hierarchicznie uporzadkowana lista cech

Faza 3 - Planowanie implementacji cech

 

 

Ma na celu przygotowanie planu okreslajacego w jakiej kolejnosci cechy b?da implementowane (ang. plan by feature). W tym procesie brane sa pod uwag? takie czynniki jak priorytet danej cechy, zaleznosci mi?dzy cechami, zlozonosc implementacyjna oraz stopien obciazenia zespolu programistow. Waznym kryterium jest rowniez podzial calego projektu na „zewn?trznie" obserwowalne etapy, czyli kroki milowe (ang. milestones) w projekcie. Efektem tej fazy jest plan implementacji, ktory okresla dat? (miesiac, rok) realizacji kazdego zbioru cech. Za kazdy zbior cech jest odpowiedzialny wyznaczony Glowny Programista. Znany jest rowniez przydzial poszczegolnych klas programistom, ktorzy b?da je realizowali. Realizacja zadan w tej fazie sklada si? z:

Planowanie implementacji cech cd.

          sformowania zespolu planujacego,

          okreslenia kolejnosci implementacji,

          przypisania zbioru cech do Glownych Programistow,

          przypisania klas do programistow.

Faza 4 i 5 - Projektowanie i implementacja

 

 

Istota FDD jest dostarczanie kolejnych, „dzialajacych" wersji produktu w krotkich iteracjach skladajacych si? z projektowania szczegolowego (ang. design by feature) oraz implementacji (ang. build by feature) wybranego zbioru cech produktu. Cechy zakwalifikowane do realizacji w danej iteracji sa przydzielane do realizacji dynamicznie tworzonym zespolom programistow (ang. feature team). Taki maly zespol typowo sklada si? z 2-3 programistow. Zadaniem zespolu jest implementacja malego zbioru cech. Kod danej cechy jest pisany przez czlonka zespolu, ktoremu zostala przypisana klasa biznesowa zwiazana z funkcjonalnoscia danej cechy. Napisany kod podlega przegladowi przez pozostalych czlonkow zespolu. Po pomyslnym wykonaniu testow jednostkowych nowy kod nadaje si? do integracji z reszta produktu, ktory staje si? bogatszy o kolejna cech?.

Projektowanie

         sformowanie zespolu programistow pod kierunkiem Glownego Programisty,

         opcjonalny przeglad dziedziny problemu i studiowanie dokumentow referencyjnych,

         stworzenie diagramow sekwencji (ang. sequence diagram),

         uszczegolowienie modelu obiektowego,

         zapisanie naglowkow klas i metod,

         inspekcja projektu.

Implementacja

          implementacja kodu klas,

          przeprowadzenie inspekcji kodu,

          testowanie jednostkowe,

          integracja nowego kodu z produktem.

Najlepsze praktyki

 

 

FDD podobnie jak inne lekkie metody bazuje na zbiorze najlepszych praktyk (ang. best practices), ktorych stosowanie w polaczeniu ze zdefiniowanym

procesem tworzenia oprogramowania zapewnia

efektywne wykonanie projektu. Kluczowe dla FDD sa nast^pujace praktyki:

Najlepsze praktyki cd.

         oparcie procesu o wymagania klienta,

         architektura systemu,

         krotkie iteracje,

         indywidualna odpowiedzialnosc za kod,

         inspekcje,

         regularne budowanie produktu,

         zarzadzanie konfiguracja,

         raportowanie i widocznosc wynikow.

Podsumowanie

 

W pracy przedstawiono Feature Driven Development. FDD bazuje na uznanym zbiorze najlepszych praktyk promowanych jako panaceum na problemy z efektywna realizacja projektow informatycznych. Dobrze zdefiniowany proces bardzo mocno zorientowany na implementacja oczekiwanej przez klienta funkcjonalnosci, precyzyjnie opisane role i odpowiedzialnosci czlonkow zespolu oraz wsparcie dla zarzadzania projektem czyni FDD godnym polecenia dla firm chcacych usprawnic swoj proces tworzenia oprogramowania. Przydatnosc FDD potwierdzila si? w wielu projektach realizowanych rowniez przez autorow metodyki, ktore zakonczyly si? sukcesem.

Dzigkujg za uwagg

Страницы:
1 


Похожие статьи

Kasprzyk Andrzej - Feature driven development