Wykład 11Typowe plany iteracji Rational Unified Process Studia Podyplomowe IT w Biznesie

(1)

Studia Podyplomowe IT w Biznesie

Rational Unified Process

Wykład 11

Typowe plany iteracji

Wykładowca:

dr inż. Ewa Stemposz ewag@ipipan.waw.pl

Polsko-Japońska Wyższa Szkoła Technik Komputerowych

Warszawa

(2)

Zagadnienia Zagadnienia Zagadnienia

Cel prezentacji typowych planów iteracji Iteracja w fazie początkowej

Iteracja w fazie opracowywania Iteracja w fazie konstrukcji

Prezentowany materiał został przygotowany w oparciu o publikację: Philippe Kruchten, The Rational Unified Process An Introduction, Addison-Wesley, 1999.

(3)

Cel prezentacji typowych planów iteracji

Sposób podziału przepływów podstawowych (omówionych przy okazji prezentowania statycznej struktury RUP) może wywierać fałszywe wrażenie, że w RUP mówi się wyłącznie o modelu wodospadowym. W rzeczywistości, RUP wykorzystuje przepływy podstawowe jedynie jako wzorce dla aktywności, które są powtarzane w kolejnych iteracjach. Rodzaj pracy wykonywanej w danym momencie (nacisk położony na konkretne aktywności), zależy zawsze od natury projektu i od kolejności, jaką iteracja zajmuje w przyjętym harmonogramie.

Aby uwidocznić zmiany nacisku na aktywności w zależności od położenia iteracji, przedstawiono trzy typowe plany iteracji - każdy dla iteracji z innej fazy:

 1-szy dotyczy iteracji w fazie początkowej; cel iteracji - specyfikacja wizji i przypadku biznesowego.

 2-gi związany jest z iteracją w fazie opracowywania; cel iteracji - zbudowanie prototypu architektonicznego.

 3-ci dotyczy iteracji w fazie konstrukcji; cel iteracji - implementacja systemu.

Uwaga: Przykłady są niepełne, nie zawierają kompletu aktywności dla omawianych dalej przepływów prac.

(4)

Iteracja w fazie początkowej (1)

Fazy

Początkowa Opracowywanie Modelowanie biznesowe

Wymagania Analiza i projektowanie Implementacja Testowanie

Konfiguracja i zarządzanie wymaganiami

Konstrukcja Wdrożenie

Zarządzanie projektem Środowisko

Przepływy prac

Wdrożenie

wczesna iteracja Iter.#1, Iter.#2 Iter.#1, Iter.#2, Iter.#n Iter.#1, Iter.#2

Iteracje

(5)

Iteracja w fazie początkowej (2)

Kontekst: wstępna iteracja w początkowym cyklu realizacji małego systemu.

Start: Nakreśl plan iteracji, specyfikuj cele i ryzyka dla projektowanego

systemu.

Uczestnicy projektu pracują pod kierownictwem analityka systemowego nad definicją wizji i zakresu projektu (artefakt: Dokument wizji). Nacisk jest położony na rozpoznanie potrzeb i oczekiwań uczestników (artefakt: Potrzeby uczestników projektu).

Ponadto analizowane są ograniczenia, np.: platformy i zewnętrzne interfejsy, które muszą być wspierane przez projekt. Bazując na naszkicowanej wizji systemu, grupa przygotowywuje listę ryzyk specyfikując ponadto możliwe hazardy (artefakty: Przypadek biznesowy i Lista ryzyk).

Wymagania: Specyfikuj i objaśniaj funkcjonalność systemu (w ogólnym

zarysie).

Analityk systemowy, wykorzystując różnego rodzaju techniki (opowiadanie historii, burza mózgów), w trakcie wspólnych sesji z uczestnikami projektu, ustala co powinien robić system. Wspólnie tworzą zarys modelu przypadków użycia (artefakt: Model przypadków użycia).

(6)

Iteracja w fazie początkowej (3)

Ponadto, by ułatwić zarządzanie modelem i zapewnić spójność, powstaje słownik pojęć (artefakt: Słownik pojęć).

Główne rezultaty wspólnych sesji to: utworzenie dokumentu specyfikującego potrzeby uczestników projektu i szkic modelu przypadków użycia (w postaci przeglądu przypadków użycia).

Zarządzanie projektem:

Rozważ wykonalność i nakreśl plan projektu.

Wyniki uzyskane w trakcie modelowania przypadków użycia są wykorzystywane do wyrażenia wizji m. in. w terminach ekonomicznych, przez rozważenie: kosztów inwestycji projektu, potrzebnych zasobów, środowiska rozwijania, kryteriów sukcesu (projekcji zysków, rozpoznania rynku), itp. tak, by można było zainicjalizować przypadek biznesowy. Lista ryzyk jest aktualizowana o ryzyka biznesowe. Kierownik projektu buduje plan faz podając wstępne daty dla głównych kamieni milowych.

Plan rozwoju oprogramowania nakreśla sposób rozwoju środowiska (platforma(y), narzędzia, metody, itp.) i specyfikuje proces (wystąpienie RUP), który będzie potrzebny (artefakt: Plan projektu).

(7)

Iteracja w fazie początkowej (4)

Uszczegóławiaj plan projektu.

Na tym etapie, uczestnicy projektu powinni posiadać dobre zrozumienie wizji produktu i możliwości zrealizowania zadania (wykonalności projektu). Znana jest już hierarchia pożądanych własności systemu i naszkicowane są przypadki użycia. Kierownik projektu może rozpocząć uszczegóławianie planu projektu w oparciu o ustalone priorytety przypadków użycia i skojarzone z nimi ryzyka. Definiowany jest wstępny zbiór iteracji, łącznie z określeniem celów dla każdej iteracji. Osiągnięty wynik będzie uszczegóławiany dalej, w kolejnej iteracji i fazie.

Wynik

Rezultat, jaki osiągany jest po zakończeniu wstępnej iteracji w fazie początkowej, to pierwsze przybliżenie dla: wizji systemu, przypadku biznesowego, zakresu i planu projektu. Uczestnicy projektu (organizacja) inicjując projekt muszą mieć postawę do oszacowania stopnia zwrotu wymaganych nakładów (ROI): muszą wiedzieć co można uzyskać i jakim wysiłkiem? Stanowi to podstwę do podjęcia decyzji: iść czy nie iść dalej?

(8)

Iteracja w fazie początkowej (5)

Harmonogram projektu nie jest sztywny, jest oczywiste, że będzie podlegał dalszym zmianom - zgrubne szacunki będą stawały się coraz bardziej realistyczne w oparciu o metryki, które będą powstawały w trakcie rozwijania projektu.

Kolejne iteracje w fazie początkowej

Na tym etapie, można zainicjować kolejne iteracje w celu poprawienia stopnia zrozumienia zakresu odpowiedzialności systemu. Takie działanie może pociągać za sobą dalszy rozwój modelu przypadków użycia, zmiany planów, składu zespołu, wzrost znajomości ryzyk, itp. Potrzeba dodatkowej pracy może wynikać np: z dużej złożoności systemu, dużej liczby ryzyk, braku doświadczenia w dziedzinie problemowej, itd.

(9)

Iteracja w fazie opracowywania (1)

Fazy

Wdrożenie

Iter#1 Iter.#1, Iter.#2 Iter.#1, Iter.#2, Iter.#n Iter.#1, Iter.#2

Iteracje

(10)

Iteracja w fazie opracowywania (2)

Rysunek na poprzedniej folii stanowi ilustrację dla następnego przykładu:

wczesnej iteracji w fazie opracowywania. Kontekst: faza początkowa została zakończona, osiągnięto kamień milowy LCO, naszkicowano aktorów i przypadki użycia oraz utworzono pierwszy (zgrubny) plan dla projektu.

Start: Naszkicuj plan

iteracji, identyfikuj ryzyka i określ cele

architektoniczne.

Bazując na posiadanym planie projektu, kierownik projektu rozpoczyna prace nad specyfikowaniem planu dla bieżącej iteracji (artefakt: Plan iteracji). W trakcie analizowania z architektem sposobu mitygowania ryzyk zostają wyłonione kryteria, w oparciu o które będzie przeprowadzane szacowanie rezultatów dalszych prac (artefakt: Lista ryzyk). Należy pamiętać, że głównym celem fazy opracowywania jest zbudowanie stabilnej architektury (również w postaci prototypu, a nie wyłącznie dokumentów). Zadanie to przypisane jest do wczesnych iteracji fazy opracowywania.

(11)

Iteracja w fazie opracowywania (3)

Wymagania: Zadecyduj, które przypadki użycia i które scenariusze, będą stanowiły bazę dla

tworzenia stabilnej architektury.

Architekt - wspólnie z kierownikiem projektu - w oparciu o architektoniczną perspektywę związaną z przypadkami użycia, określa zbiór przypadków stanowiących potencjalną bazę dla uzyskania stabilnej architektury systemu. Należą do nich przypadki o najwyższym priorytecie dla klienta, z dużą liczbą ryzyk i przypadki szczególnie złożone. Na tych przypadkach (i powiązanych z nimi scenariuszach) będzie skoncentrowana uwaga w bieżącej iteracji.

Uwaga! Identyfikacja architektonicznie istotnych przypadków użycia może wpłynąć na zmianę planu iteracji, określonego w poprzednim kroku.

Wymagania: Staraj się uzyskać dobre zrozumienie wybranych przypadków.

Dokonaj inspekcji

osiągniętych rezultatów.

Specyfikatorzy przypadków użycia przygotowywują szczegółowe opisy dla wybranych przypadków użycia i scenariuszy. Analityk systemowy, w oparciu o wypracowane opisy, może dokonać restrukturyzacji modelu przypadków użycia, jako całości (artefakt: Model przypadków użycia i Specyfikacja uzupełniająca). Zmiany muszą być zatwierdzone przez odpowiednie ciało.

(12)

Iteracja w fazie opracowywania (4)

Wymagania: Rozważ

ponownie zidentyfikowane ryzyka i wybrane

przypadki użycia.

Architekt, w oparciu o nowe opisy dla przypadków użycia (i być może nową organizację modelu przypadków użycia), poddaje ponownie pod rozwagę wybrany zbiór przypadków. Decyzje: Co zostawić? Co usunąć? są ważne ponieważ od nich zależy, co będzie analizowane, projektowane i implementowane w bieżącej iteracji. Dla przypomnienia, wybrane przypadki będą stanowić bazę dla architektury całego systemu. Kierownik projektu, stosownie do zmienionego zbioru wybranych przypadków, modyfikuje plan dla bieżącej iteracji (artefakt: Plan iteracji) i może też zaktualizować listę ryzyk, ponieważ wprowadzenie nowej informacji mogło dać w efekcie pojawienie się nowych ryzyk (artefakt: Lista ryzyk).

Wymagania: Buduj prototyp interfejsu użytkownika.

W oparciu o wybrany zbiór przypadków użycia, projektant interfejsu użytkownika rozszerza je (do postaci tzw. historii przypadków użycia, use-case story board) oraz buduje prototyp interfejsu użytkownika, tak by możliwe było uzyskanie informacji zwrotnej od uczestników projektu (artefakt: Prototyp interfejsu użytkownika).

(13)

Iteracja w fazie opracowywania (5)

Analiza i projektowanie:

Znajdź „oczywiste” klasy, zrób wstępny podział na podsystemy i przejrzyj

dokładnie przypadki użycia.

Aby uzyskać pewność, które klasy są „oczywiste”, architekt przegląda wymagania na system, słownik i perspektywę przypadków użycia (nie model przypadków użycia). Wspierając się wiedzą z dziedziny problemowej - będącą w posiadaniu zespołu - architekt dokonuje wstępnego podziału na podsystemy oraz identyfikuje mechanizmy analityczne (określające rozwiązania wspólne dla podobnych problemów). Inicjalizowany jest dokument zawierający opis architektury systemu (artefakt:

Dokument architektury systemu). Równolegle z powyższymi czynnościami, projektanci (być może wspólnie z architektem) znajdują obiekty (klasy), które są potrzebne do realizacji wybranych przypadków użycia - co skutkuje przypisanie odpowiedzialności do klas i mechanizmów analitycznych.

Uszczegóławiaj i ujednolicaj klasy.

Projektanci uszczegóławiają klasy zidentyfikowane w poprzednim kroku, przypisując im odpowiedzialności i modyfikując atrybuty i związki między klasami.

(14)

Iteracja w fazie opracowywania (6)

Identyfikuj klasy „istotne architektonicznie”.

Dokonaj inspekcji

osiągniętych rezultatów.

Następnie, architekt wybiera pewną liczbę klas (tzw. klas

„istotnych architektonicznie”) i włącza je do perspektywy logicznej (artefakt: Dokument architektury systemu).

Zastanów się nad

podziałem na pakiety.

Rozważając aspekt usługowy architektury, architekt umieszcza klasy w pakietach projektowych, te z kolei łącząc w podsystemy. Podział na podsystemy nie jest ostateczny i może podlegać dalszym zmianom.

Przystosuj do środowiska implementacji, projektuj główne scenariusze, definiuj interfejsy dla klas, dokonaj inspekcji osiągniętych

rezultatów.

Architekt uszczegóławia architekturę specyfikując mechanizmy projektowe, które są niezbędne do realizacji zidentyfikowanych wcześniej mechanizmów analitycznych. Mechanizmy projektowe są ograniczane przez środowisko implementacji (dostępne mechanizmy implementacyjne, takie jak np.: system operacyjny, warstwa middleware, baza danych, itp.). Projektanci - w oparciu o wystąpienia klas - posługując się diagramami interakcji opisują, jak wybrane przypadki użycia i

(15)

Iteracja w fazie opracowywania (7)

scenariusze są realizowane w terminach współpracujących obiektów. Takie postępowanie pozwala na weryfikację wykorzystywanych klas, nakładanie ograniczeń na mechanizmy projektowe oraz umożliwia korektę wcześniej utworzonych diagramów interakcji. Dzięki temu możliwa jest spójna specyfikacja interfejsów dla klas. Architekt - w oparciu o ograniczenia nakładane na mechanizmy projektowe - aktualizuje perspektywę logiczną. Artefakty, wytworzone w trakcie powyższych aktywności, są poddawane inspekcjom.

Rozważ problemy związane ze współbieżnością i

rozproszeniem architektury.

Następnym krokiem, do wykonania przez architekta, jest rozważenie problemów związanych ze współbieżnością i rozproszeniem, o ile mają miejsce w tworzonym systemie.

Architekt bada zadania, procesy i sieć powiązań zarówno między nimi, jak i między fizycznymi urządzeniami.

Badania opierane są o realizacje wybranych przypadków użycia czy scenariuszy (diagramy interakcji) (artefakt:

Dokument architektury systemu).

(16)

Iteracja w fazie opracowywania (8)

Dokonaj przeglądu architektury.

Architektura jest poddawana przeglądowi.

Implementacja: Rozważ fizyczną alokację

architektury (podział na pakiety implementacyjne).

Architekt rozważa przejście z projektu architektury do modelu implementacyjnego i definiuje perspektywę implementacyjną.

Implementacja: Planuj integrację.

Integrator systemowy - w oparciu o zestaw przypadków użycia implementowanych w bieżącej iteracji - ustala kolejność implementowania poszczególnych podsystemów: zintegrowane podsystemy utworzą prototyp architektoniczny. Rezultaty tej aktywności powinny być umieszczone w planie projektu (artefakt: Plan projektu).

Testowanie: Planuj testy integracyjne i testy

systemowe.

Projektant testów planuje testy integracyjne i testy systemowe, specyfikując mierzalne cele niezbędne dla oszacowania architektury. Cele mogą być wyrażane w terminach wykonania scenariuszy przypadków użycia w pewnym wymaganym czasie odpowiedzi i pod pewnym

(17)

Iteracja w fazie opracowywania (9)

obciążeniem. Ponadto, projektant testów identyfikuje i implementuje przypadki testowe oraz procedury testowe (artefakt: Plan testów).

Implementacja:

Implementuj i integruj klasy.

Grupa implementatorów implementuje (oraz testuje zaimplementowane przez siebie) klasy zidentyfikowane w trakcie projektowania architektury. Przetestowane klasy są umieszczane w odpowiednich komponentach modelu implementacyjnego - komponent w modelu implementacyjnym w praktyce z reguły stanowi odpowiednik podsystemu na poziomie logicznym.

Następnie do pracy przystępują testerzy integracyjni, którzy testując zaimplementowane podsystemy, przygotowywują je do integracji z innymi podsystemami.

Integruj zaimplementowane części.

Testerzy integracyjni integrują zaimplementowane i przetestowane podsystemy - w ten sposób budowany jest prototyp architektoniczny. Każda kolejna konstrukcja (ang. build) jest testowana.

(18)

Iteracja w fazie opracowywania (10)

Testowanie: Oceń implementację architektury.

Po integracji systemu, do postaci określonej przez cele bieżącej iteracji, system jest poddawany testowaniu przez testera systemowego. Wyniki szacuje projektant testów. Jego zadaniem jest ocena, czy założone cele zostały osiągnięte.

Następnie, do oceniania przystępuje architekt, porównując otrzymane wyniki z zidentyfikowanymi na początku ryzykami.

Oceń iterację. Kierownik projektu porównuje harmonogram i aktualne koszty bieżącej iteracji z tym, co zaplanowano wcześniej.

Musi zadecydować, czy będą potrzebne przeróbki - jeśli tak, trzeba będzie przypisać je do przyszłych iteracji. Ponadto, kierownik projektu aktualizuje listę ryzyk (artefakt: Lista ryzyk) i plan projektu (artefakt: Plan projektu) i przygotowywuje zarys planu dla następnej iteracji (artefakt:

Plan iteracji). Na tym etapie warte rozważenia są także i inne korzyści osiągnięte dzięki przeprowadzonym dotychczas pracom, jak np: poprawa wydajności pracy czy nauka narzędzi (połączona z treningiem).

(19)

Iteracja w fazie opracowywania (11)

Wynik

Rezultat, jaki osiągany jest po zakończeniu wczesnej iteracji w fazie opracowywania, to pierwsze przybliżenie dla architektury systemu. Pierwsze przybliżenie składa się z wystarczająco dobrze opisanych perspektyw architektonicznych (przypadków użycia, logicznej i implementacyjnej) oraz z pracującego prototypu architektonicznego.

Kolejne iteracje w fazie opracowywania

Kolejne iteracje służą polepszeniu zrozumienia wymagań i architektury systemu, co może skutkować ulepszeniem modelu projektowego i/lub implementacyjnego.

(20)

Iteracja w fazie konstrukcji (1)

Fazy

Wdrożenie

Iter. #1 Iter.#1, Iter.#2 Iter.#1, Iter.#2, Iter.#n Iter.#1, Iter.#2

Iteracje

(21)

Iteracja w fazie konstrukcji (2)

Rysunek na poprzedniej folii stanowi ilustrację dla następnego przykładu: późnej iteracji w fazie konstrukcji. Kontekst: faza opracowywania została zakończona, wymagania są stabilne, duża część funkcjonalności została już zaimplementowana, zintegrowana i przygotowana do testowania. Projekt zbliża się do osiągnięcia kamienia milowego Początkowa zdolność operacyjna i wypuszczenia pierwszego beta.

Planuj iterację.

Kierownik projektu aktualizuje plan iteracji, tak by uwzględnić zarówno funkcjonalność, która ma być dodana w bieżącej iteracji, jak i doświadczenia wyniesione z poprzednich etapów oraz wszelkie ryzyka, które aktualnie mają podlegać mitygacji (artefakty: Plan iteracji i Lista ryzyk).

(22)

Iteracja w fazie konstrukcji (3)

Implementacja: Planuj integrację na poziomie systemowym.

Planowanie integracji musi bazować na kolejności w jakiej powinny być łączone podsystemy, tak by utworzyć pracującą i testowalną całość. Wybór odpowiedniej kolejności jest uzależniony od funkcjonalności, która już została zaimplementowana i tych aspektów systemu, które muszą istnieć, by wspierać zarówno proces integracji, jak i proces testowania. Prace te wykonuje integrator systemowy, a jej wyniki są przechowywane w planie integracji (artefakt: Plan integracji, ang. Integration Build Plan). Plan integracji definiuje częstotliwość kolejnych integracji.

(23)

Iteracja w fazie konstrukcji (4)

Analiza i Projektowanie:

Uszczegóławiaj realizacje przypadków użycia.

Projektanci uszczegóławiają klasy zidentyfikowane w poprzednich iteracjach poprzez przypisywanie im odpowiedzialności i aktualizację atrybutów i związków.

Być może trzeba będzie dodać nowe klasy, aby wypełnić ograniczenia projektowe czy implementacyjne.

Zmiany w klasach mogą wymagać zmian w aktualnym podziale na podsystemy.

Testowanie: Planuj i

projektuj testy systemowe.

Projektant testów musi zapewnić (zidentyfikować, zaprojektować i opisać w modelu testów) odpowiednią liczbę przypadków testowych i procedur testowych. W ogólności, każdy przypadek testowy musi mieć przypisaną przynajmniej jedną procedurę testową.

Ponadto, projektant testów musi zweryfikować testy z poprzedniej iteracji, tak by można je było wykorzystać w testowaniu regresyjnym zarówno dla aktualnej integracji, jak i dla przyszłych integracji z tej iteracji (artefakty: Skrypty i Procedury testowe).

(24)

Iteracja w fazie konstrukcji (5)

Testowanie: Planuj i projektuj integrację na poziomie podsystemów i systemu.

Projektant testów buduje plan dla testów integracyjnych w oparciu o Plan testów, który opisuje całościową strategię dla testów, wymagane zasoby, harmonogram i kryteria sukcesu. Funkcjonalność, która ma być testowana razem musi zostać zidentyfikowana, ponadto należy należy też zidentyfikować wszystkie „pniaki”

(ang. stubs) i driver’y, które są niezbędne, aby można było przeprowadzić testowanie integracyjne.

Implementator musi przygotować kod dla pniaków i driverów zgodnie z danymi otrzymanymi od projektanta testów.

Implementacja: Twórz testuj kod.

Stosownie do wytycznych dla programowania, implementatorzy tworzą kod implementujący klasy w Modelu implementacyjnym. Znalezione w trakcie implementowania kodu błędy mogą - na zasadzie sprzężenia zwrotnego - spowodować zmiany w projekcie.

(25)

Iteracja w fazie konstrukcji (6)

Implementacja: Planuj i implementuj testy

jednostkowe.

Implementator projektuje testy jednostkowe, które mają za zadanie zweryfikowanie kodu zarówno z punktu widzenia czarnej skrzynki (rozważana jest wtedy wyłącznie funkcjonalność kodu), jak i białej skrzynki (tu brana jest pod uwagę budowa kodu). W pierwszym przypadku, musi być uzyskana pewność, że jednostka kodu przyjmuje i wyprowadza poprawne i niepoprawne dane (w pewnym zakresie) - zgodnie ze swoją specyfikacją. W drugim przypadku, musi być możliwe przejście każdą ze ścieżek decyzyjnych w kodzie.

Implementacja: Testuj jednostki kodu w ramach podsystemu.

W tej aktywności, testowanie skupia się na sprawdzaniu jednostek kodu w ramach podsytemu. Jednostka kodu jest traktowana jako najmniejsza „porcja” kodu, która podlega weryfikacji. Weryfikacją jednostki kodu zajmuje się ten, kto ją implementował, to on projektuje testy dla jednostki, implementuje je i wykonuje. Celem weryfikacji jest uzyskanie pewności, że kod został napisany zgodnie ze standardami przyjętymi w organizacji i na akceptowalnym poziomie jakości.

(26)

Iteracja w fazie konstrukcji (7)

Implementacja i testowanie: Integruj podsystem.

Celem tej aktywności jest zintegrowanie wszystkich fragmentów kodu (wytworzonych przez różnych implementatorów), w sposób przyrostowy, zgodnie z ustalonym wcześniej planem integracji.

Implementacja: Testuj podsystem.

Testerzy wykonują zaplanowane wcześniej procedury testowe. W przypadku otrzymania wyników niezgodnych z oczekiwanymi, trzeba ustalić, jaki fragment kodu jest za nie odpowiedzialny i gdzie trzeba będzie poprawiać błędy.

Implementacja: Wypuść podsystem.

Gdy podsystem jest już wystarczająco dobrze przetestowany, zostaje przeniesiony (w postaci oznaczonej wersji) do obszaru, gdzie będzie widoczny i wykorzystany do integracji na poziomie systemowym.

Implementacja: Integruj system.

Integrator systemowy w sposób przyrostowy scala podsystemy w jedną całość, która będzie podlegała testowaniu integracyjnemu.

(27)

Iteracja w fazie konstrukcji (8)

Testowanie: Testuj integrację.

Testerzy integracji wykonują procedury testowe, zaplanowane wcześniej. Podobnie, jak przy testowaniu podsystemów, dla rezultatów niezgodnych z oczekiwanymi, przechowywane są logi, umożliwiające rozstrzygnięcie, gdzie są błędy.

Testowanie: Testuj system. Po zintegrowaniu całości systemu (w zakresie zgodnym z planem dla danej iteracji), do pracy przystępują testerzy systemowi. Projektanci testów analizują wyniki, aby stwierdzić czy osiągnięto założone cele.

Oszacuj iterację.

Kierownik projektu porównuje aktualne koszty iteracji, harmonogram i wyniki z Planem iteracji oraz podejmuje decyzję, czy będzie potrzebna dodatkowa praca do wykonania tego, co było planowane - jeśli tak, ta praca powinna zostać przypisana do przyszłych iteracji.

Ponadto, kierownik aktualizuje: listę ryzyk (artefakt:

Lista ryzyk), plan projektu (artefakt: Plan projektu) i przygotowywuje zarys planu dla następnej iteracji (artefakt: Plan iteracji)

(28)

Iteracja w fazie konstrukcji (9)

Wynik

Rezultat, jaki osiągany jest po zakończeniu późnej iteracji w fazie konstrukcji, to uzyskanie bardziej kompletnego i lepiej przetestowanego zbioru funkcjonalności systemu - system jako całość jest coraz bardziej spójny. Osiągnięte rezultaty, jak zwykle, stanowią bazę dla przeprowadzania następnych iteracji.