Piotr Kowalski
advertisement
Incremental development (model przyrostowy, realizacja przyrostowa) Kowalski Piotr Programowanie i bazy danych PWSZ PŁOCK Podejście przyrostowe (incremental development) – [Mills i in., 1980] sposób na ograniczenie powtarzania całości prac w procesie tworzenia • możliwość odkładania decyzji –szczegółowe wymagania, do czasu zdobycia doświadczenia w pracy z systemem • tworzenie przyrostowe – pośrednie; łączy zalety podejścia kaskadowego i ewolucyjnego • stosuje się do przypadków, gdy dopuszczalna jest okrojona funkcjonalność systemu Model ten opiera się na podobnych założeniach jak model wodospadu jednak zasadnicza różnica jest taka, że projekt jest rozłożony na wiele małych faz/zadań, iteracji. Każda z nich zakończona jest powstaniem nowego modułu lub usprawnieniem/rozbudowaniem istniejącego. Poszczególne moduły zostają ułożone w większą strukturę i ta jako całość poddana jest testom. W modelu wielokrotnym istnieje podział na iteracje. Projekt może zostać podzielony na kilka osobnych iteracji trwających od jednego do czterech tygodni w zależności od specyfiki projektu. Tworzone oprogramowanie z zasady jest testowane na zakończenie każdej iteracji, rezultaty testów są wykorzystywane na koniec każdego cyklu testowego. Czas każdorazowej iteracji może być różny, ale nie powinien być dłuższy niż przyjęty na nią limit – z każdą iteracją wzrasta doświadczenie grupy projektowej więc czas potrzebny na wykonanie iteracji powinien być coraz krótszy. W każdej iteracji implementowane są nowe funkcjonalności jednak ich liczba w każdej z nich jest stosunkowo mała co powoduje, że wraz z przyrostem funkcjonalności aplikacji przyrasta również ilość wykonanych analiz testów do jej weryfikacji. To powoduje umiejętne rozłożenie „sił” w czasie zamiast testowania jednego dużego „organizmu” jednocześnie. W porównaniu z klasycznym modelem wodospadu faza projektowania, zbierania wymagań, dewelopmentu pojawia się jednokrotnie w całym czasie życia projektu, w modelu wielokrotnym pojawia się praktycznie w każdej iteracji co zwiększa doświadczenie i sprawność zespołu projektowego która to wiedza zaowocuje w kolejnych projektach. Model przyrostowy mimo niezaprzeczalnych zalet posiada jednak 3 dość duże wady o których mowa poniżej : bardzo rozbudowana i częsta komunikacja – każda iteracja wymaga podania feedbacku o rezultatach testów, dostarczonych rozwiązaniach, ilości wykonanej pracy na zadanie itp. – proces komunikacji konsumuje sporo czasu w odróżnienia od klasycznego modelu waterfall w praktyce nie ma możliwości zamrożenia wymagań funkcjonalnych gdyż w miarę tworzenia oprogramowania wzrastają wymogi klienta ; to powoduje opóźnienia i przekroczenie budżetu realizacja projektu wymaga posiadania bardzo sprawnego systemu zarządzania i monitorowania wprowadzanych zmian w każdej z iteracji Idea: • w procesie przyrostowym klienci identyfikują w zarysie usługi, które system ma oferować • wskazują hierarchię ważności usług • definiuje się pewną liczbę przyrostów, które mają być dostarczone • przyrost – część funkcjonalności systemu • przyporządkowanie usług do przyrostów, zależy od priorytetu tych usług • usługi najważniejsze dostarczane pierwsze gdy zdefiniuje się przyrosty, szczegółowo definiuje się wymagania stawiane usługom dostarczanym w pierwszym przyroście • przyrost jest tworzony za pomocą najbardziej odpowiedniego procesu, wybór modelu • w trakcie prowadzi się dalszą analizę wymagań dla następnych przyrostów • gdy przyrost gotowy – klienci uruchamiają: szybko – część funkcjonalności, ekperymenty • =>ustalanie nast.: wymagań i wersji przyrostu Fazy: • rozpoczyna się od: określenia całości wymagań, wykonania wstępnego, ogólnego projektu całości systemu; potem: • wybór pewnego podzbioru funkcji systemu, • następnie: szczegółowy projekt (wg modelu kaskadowego) oraz implementacja części systemu realizującej wybrane funkcje • testowanie zrealizowanego fragmentu i dostarczenie go klientowi • powtarzanie procesu Uwagi: • po zakończeniu prac nad kolejnymi wymaganiami, integracja z istniejącymi przyrostami • funkcjonalność systemu poprawia się z każdym dostarczonym przyrostem • najczęściej używane usługi – najwcześniej lub implementowane przyrostowo w miarę realizacji wymagań kolejnych przyrostów (first-things-first) • tworzenie przyrostu – najbardziej odpowiedni proces: wybór; specyfikacja usług staranna w pewnym przyroście => model kaskadowy; niejasna => lepiej zastosować tworzenie ewolucyjne Zalety: • częste kontakty z klientem (skrócenie przerw por. model kaskadowy),używanie: dośw., szkolenia • brak konieczności zdef. z góry całości wymagań • wczesne wykorzystanie przez klienta fragmentów systemu (testowanie funkcjonal.), mniejsze ryzyko • pierwszy przyrost spełnia najważniejsze wymagania, można używać systemu (prototyp ?) • potencjalne opóźnienia: możliwość elastycznego reagowania – opóźnienie realizacji fragmentu – przyspieszenie prac nad inną/innymi częściami (sumarycznie – bez opóźnienia całości przedsięwzięcia projektowego) Wady: • przyrosty powinny być małe (nie więcej niż 20000 wierszy kodu) • każdy przyrost powinien dostarczać pewną funkcjonalność systemu=>może być trudno przypisać wymagania klienta do przyrostów, potencjalne trudności z wycinaniem podzbioru funkcji w pełni niezależnych • trudno zdefiniować wspólne udogodnienia potrzebne wszystkim przyrostom dodatkowy koszt konieczność implementacji szkieletów (interfejs zgodny z docelowym systemem) ryzyko nie wykrycia błędów w fazie testowania Konsekwencje: • Ewolucja podejścia przyrostowego doprowadziła do powstania „programowania ekstremalnego” [Beck, 1999] => tworzenie i dostarczanie bardzo małych przyrostów funkcjonalności włączenie klienta w cały proces ustawiczne poprawianie kodu programowanie pozbawione indywidualizmu (2-10) wymagania: słabo sprecyzowane lub szybko się zmieniające
