E. Stemposz. Rational Unified Process, Wykład 11, Slajd 1 wrzesień 2002 Powrót Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 11 Typowe plany iteracji Wykładowca: dr inż. Ewa Stemposz Polsko-Japońska Wyższa Szkoła Technik Komputerowych Warszawa

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 2 wrzesień 2002 Powrót 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.

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 3 wrzesień 2002 Powrót 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.

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 4 wrzesień 2002 Powrót Iteracja w fazie początkowej (1) Fazy PoczątkowaOpracowywanie Modelowanie biznesowe Wymagania Analiza i projektowanie Implementacja Testowanie Konfiguracja i zarządzanie wymaganiami KonstrukcjaWdrożenie Zarządzanie projektem Środowisko Przepływy prac Wdrożenie wczesna iteracja Iter.#1, Iter.#2Iter.#1, Iter.#2, Iter.#nIter.#1, Iter.#2 Iteracje

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 5 wrzesień 2002 Powrót 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 (np. opowiadanie historii (ang. story board), 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).

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 6 wrzesień 2002 Powrót 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).

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 7 wrzesień 2002 Powrót Iteracja w fazie początkowej (4) Zarządzanie projektem: 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?

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 8 wrzesień 2002 Powrót 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.

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 9 wrzesień 2002 Powrót Iteracja w fazie opracowywania (1) Fazy PoczątkowaOpracowywanie Modelowanie biznesowe Wymagania Analiza i projektowanie Implementacja Testowanie Konfiguracja i zarządzanie wymaganiami KonstrukcjaWdrożenie Zarządzanie projektem Środowisko Przepływy prac Wdrożenie Iter#1Iter.#1, Iter.#2Iter.#1, Iter.#2, Iter.#nIter.#1, Iter.#2 Iteracje

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 10 wrzesień 2002 Powrót 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.

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 11 wrzesień 2002 Powrót Iteracja w fazie opracowywania (3) Wymagania: Zadecyduj, które przypadki użycia i które scenariusze dla tych przypadków, 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 na powiązanych z tymi przypadkami 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 dla wybranych scenariuszy. Analityk systemowy, w oparciu o wypracowane opisy, może dokonać restrukturyzacji modelu przypadków użycia (artefakt: Model przypadków użycia i Specyfikacja uzupełniająca). Zmiany muszą być zatwierdzone przez odpowiednie ciało.

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 12 wrzesień 2002 Powrót 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).

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 13 wrzesień 2002 Powrót 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 przypisaniem odpowiedzialności do klas i wybraniem odpowiednich mechanizmów analitycznych. Analiza i projektowanie: 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.

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 14 wrzesień 2002 Powrót 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). Analiza i projektowanie: 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. Analiza i projektowanie: 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

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 15 wrzesień 2002 Powrót Iteracja w fazie opracowywania (7) scenariusze są realizowane w terminach współpracujących obiektów. Takie postępowanie pozwala na weryfikację wykorzystywanych klas, na 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. Analiza i projektowanie: 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).

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 16 wrzesień 2002 Powrót Iteracja w fazie opracowywania (8) Analiza i projektowanie: 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

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 17 wrzesień 2002 Powrót 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.

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 18 wrzesień 2002 Powrót 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).

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 19 wrzesień 2002 Powrót 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.

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 20 wrzesień 2002 Powrót Iteracja w fazie konstrukcji (1) Fazy PoczątkowaOpracowywanie Modelowanie biznesowe Wymagania Analiza i projektowanie Implementacja Testowanie Konfiguracja i zarządzanie wymaganiami KonstrukcjaWdrożenie Zarządzanie projektem Środowisko Przepływy prac Wdrożenie Iter. #1Iter.#1, Iter.#2Iter.#1, Iter.#2, Iter.#nIter.#1, Iter.#2 Iteracje

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 21 wrzesień 2002 Powrót 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. Zarządzanie projektem: 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).

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 22 wrzesień 2002 Powrót 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.

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 23 wrzesień 2002 Powrót 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).

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 24 wrzesień 2002 Powrót 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.

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 25 wrzesień 2002 Powrót 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.

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 26 wrzesień 2002 Powrót 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.

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 27 wrzesień 2002 Powrót 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. Zarządzanie projektem: 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)

E. Stemposz. Rational Unified Process, Wykład 11, Slajd 28 wrzesień 2002 Powrót 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.