1 Część 2 OiZPI Iteracyjny przyrostowy model cyklu życiowego Rational Unified Process™ w materiałach wykorzystano: K.Subieta: Budowa i integracja systemów informatycznych A.Kobieliński: Inżynieria Oprogramowania I.Sommerville: Software Engineering IBM Rational: RUP™

2 Model iteracyjny przyrostowyMetodyka RUP – nakład pracy w ramach poszczególnych etapów. © IBM-Rational Software

3 Model iteracyjny przyrostowy

4 Model iteracyjny przyrostowy

5 Porównanie z cyklem kaskadowymtradycyjny model kaskadowy Przykłady skopiowane z metodyki RUP – jak widać model iteracyjny, w którym w każdym cyklu większość nakładów dotyczy jednego z etapów model iteracyjny przyrostowy © IBM-Rational Software

6 Etapy i fazy cyklu Etapy (oś pionowa) Fazy (oś pozioma)są powtarzane w kolejnych iteracjach odzwierciedlają grupy czynności Fazy (oś pozioma) następują kolejno po sobie odzwierciedlają stan zaawansowania projektu © IBM-Rational Software w dalszej części mowa będzie o planowaniu, harmonogramowaniu i doborze osób. Inne aspekty przy okazji innych zagadnień na dalszych wykładach

7 Etapy i fazy cyklu Fazy Inception (faza wstępna)Elaboration (faza opracowania) Contruction (faza budowy systemu) Transition (faza przekazania) w dalszej części mowa będzie o planowaniu, harmonogramowaniu i doborze osób. Inne aspekty przy okazji innych zagadnień na dalszych wykładach © IBM-Rational Software

8 Faza wstępna (inception)Cele fazy wstępnej Ustalenie kontekstu projektu oraz granic systemu Wydzielenie podstawowych przypadków użycia (sytuacji, w których używany będzie system) Oszacowanie kosztu przedsięwzięcia oraz wstępnego harmonogramu realizacji* Analiza ryzyka* Przygotowanie środowiska projektu * - czynności strategiczne Znamy odpowiedź na pytanie: Jaka jest skala przedsięwzięcia ? w dalszej części mowa będzie o planowaniu, harmonogramowaniu i doborze osób. Inne aspekty przy okazji innych zagadnień na dalszych wykładach

9 Faza opracowania (elaboration)Cele fazy opracowania Zapewnienie wystarczającej stabilności wymagań, architektury oraz planu budowy Opracowanie zarysu architektury oraz zapewnienie, że będzie ona w stanie zrealizować ustalone wymagania Ostateczne zamknięcie prac nad przygotowaniem środowiska realizacji projektu Znamy odpowiedź na pytanie: Wiemy co robić ? w dalszej części mowa będzie o planowaniu, harmonogramowaniu i doborze osób. Inne aspekty przy okazji innych zagadnień na dalszych wykładach

10 Faza budowy systemu (construction)Cele fazy budowy Minimalizacja kosztów implementacji Osiągnięcie określonej jakości Opracowanie testowych wersji systemu (Alpha, Beta, i innych) Ustalenie momentu przekazania systemu do użytku System działa poprawnie Jest prawdą, że: przy założeniu określonego poziomu jakości. w dalszej części mowa będzie o planowaniu, harmonogramowaniu i doborze osób. Inne aspekty przy okazji innych zagadnień na dalszych wykładach

11 Faza przekazania (transition)Cele fazy przekazania Przeprowadzenie testów beta Szkolenie użytkowników Wykonanie wszelkich czynności związanych z rozprowadzaniem oprogramowania Osiągnięcie samowystarczalności użytkowników Osiągnięcie porozumienia z udziałowcami, co do faktu wywiązania się z przyjętych zobowiązań Użytkownik jest samodzielny Jest prawdą, że: przy założeniu określonego poziomu wsparcia. w dalszej części mowa będzie o planowaniu, harmonogramowaniu i doborze osób. Inne aspekty przy okazji innych zagadnień na dalszych wykładach

12 Etapy Etapy/Dyscypliny (pracy)Business Modeling (modelowanie procesów biznesowych) Requirements (etap formułowania wymagań) Analysis & Design (analiza i projektowanie) Implementation (implementacja) Test (testy) Deployment (rozpowszechnianie) Configuration & Change (zarządzanie zmianami i konfiguracją) Project Management (zarządzanie projektem) Environment (zarządzanie środowiskiem projektu) w dalszej części mowa będzie o planowaniu, harmonogramowaniu i doborze osób. Inne aspekty przy okazji innych zagadnień na dalszych wykładach

13 Modelowanie procesów biznesowychGłówne cele prac w ramach etapu Poznanie struktury i działania organizacji Upewnienie się, czy uczestnicy projektu (klienci, użytkownicy, projektanci) wiedzą co będzie przedmiotem projektu Wstępne ustalenie wymagań (w sensie wymagań organizacji) w dalszej części mowa będzie o planowaniu, harmonogramowaniu i doborze osób. Inne aspekty przy okazji innych zagadnień na dalszych wykładach

14 Formułowanie wymagań Główne cele prac w ramach etapuOsiągnięcie porozumienia pomiędzy zamawiającym i innymi udziałowcami, odnośne tego, co system powinien robić Edukacja projektantów w zakresie wymagań Ustalenie granic systemu Dostarczenie materiału pozwalającego zaplanować projekt i oszacować jego koszty

15 Analiza i projektowanieGłówne cele prac w ramach etapu Transformacja wymagań w projekt systemu Rozwinięcie architektury Dopasowanie projektu do środowiska implementacyjnego w dalszej części mowa będzie o planowaniu, harmonogramowaniu i doborze osób. Inne aspekty przy okazji innych zagadnień na dalszych wykładach

16 Implementacja Główne cele prac w ramach etapuOkreślenie konfiguracji kodu i innych komponentów Implementacja i testowanie klas Integracja pracy poszczególnych osób tworzących kod źródłowy w dalszej części mowa będzie o planowaniu, harmonogramowaniu i doborze osób. Inne aspekty przy okazji innych zagadnień na dalszych wykładach

17 Testy Główne cele prac w ramach etapuWeryfikacja interakcji pomiędzy obiektami Weryfikacja interakcji komponentów Sprawdzenie, czy zaimplementowano wszystkie funkcje wynikające z wymagań w dalszej części mowa będzie o planowaniu, harmonogramowaniu i doborze osób. Inne aspekty przy okazji innych zagadnień na dalszych wykładach

18 Rozpowszechnianie Główne cele prac w ramach etapuInstalacja systemu (oprogramowania) w dalszej części mowa będzie o planowaniu, harmonogramowaniu i doborze osób. Inne aspekty przy okazji innych zagadnień na dalszych wykładach

19 Czynności przekrojowew dalszej części mowa będzie o planowaniu, harmonogramowaniu i doborze osób. Inne aspekty przy okazji innych zagadnień na dalszych wykładach © IBM-Rational Software

20 Proces architekturocentrycznyRUP™ jest procesem architekturocentrycznym Rola architektury Zrozumieć to co system robi Zrozumieć jak działa Móc pracować z fragmentem systemu Móc rozszerzać system Móc wykorzystać części systemu w innym projekcie Co to jest architektura: „Opis systemu, z którego nie można już nic usunąć, gdyż nie będzie możliwe jego zrozumienie i wyjaśnienie jego działania.” [P.Kruchten] Minimalna specyfikacja wystarczająca do zrozumienia systemu i wyjaśnienia zasad jego działania. Element projektu mający znaczenie dla architektury – element mający szeroki wpływ na strukturę systemu i na jego istotne cechy.

21 Proces bazujący na przypadkach użyciaPrzypadki użycia są bazą dla wszystkich czynności realizowanych w ramach procesu Przypadek użycia jest wyjściową jednostką dekompozycji Ścieżka metodyczna Przypadek użycia organizacji Obiektowy model organizacji Przypadek użycia Model projektowy, Model wdrożenia, Scenariusz testów

22 Metodyka jako produkt Wersja komercyjna - Rational Suite (metodyka + narzędzia) Wersja otwarta metodyki – „Open UP” Interaktywna przeglądarka metodyki:

23 Diagramy przebiegu pracy (Workflows)Objaśnienie podstawowych pojęć Symbole Role uczestników projektu przewidziane w RUP™

24 Pojęcia Rola – definicja zachowania i zakresu odpowiedzialności określonego uczestnika projektu lub grupy takich uczestników Czynność – część prac nad projektem do której wykonania zobowiązana jest określona rola Artefakt – część informacji jaka powstaje, jest modyfikowana lub wykorzystywana w określonym procesie (zespole ról i czynności)

25 Rola Rola jest abstrakcyjnym pojęciem definiującym pewien zbiór czynności i posiadanych artefaktów Rola jest przeważnie realizowana przez określonego uczestnika projektu lub grupę takich uczestników współpracujących w ramach zespołu Każdy członek zespołu najczęściej spełnia wiele różnych ról Rola nie wskazuje określonego uczestnika projektu, rola określa sposób zachowania się osoby występującej w tej roli Role określa się również dla osób spoza jednostki realizującej projekt

26 Czynności Każdej roli odpowiada pewien ściśle ustalony zbiór czynnościCzynności te są związane z daną rolą Jedna czynność może być związana z większą liczbą ról, wówczas czynność ta jest realizowana wspólnie przez kilka osób występujących w różnych rolach Czynności są powiązane z artefaktami, które są przedmiotem tychże czynności

27 Artefakty Artefakty są ostatecznymi lub pośrednimi "owocami" pracyArtefakt może być: dokumentem – np. Dokument Wymagań, Dokument Wizji modelem – Model Procesów Biznesowych, Biznesowy Model Obiektowy elementem systemu – np. Klasa, Podsystem

28 Symbole graficzne (notacja)Symbole artefaktów różnego rodzaju

29 Diagramy podstawowe i szczegółoweDo ogólnego przedstawienia przebiegu pracy służą diagramy podstawowe (core workflows) Diagramy podstawowe zapisuje się w notacji diagramów czynności UML Na diagramach tych występują strzałki, bloki decyzyjne, elementy synchronizujące oraz symbole grupujące Z każdy symbolem grupującym związany jest jeden lub wiele diagramów szczegółowych Jeśli diagramów szczegółowych jest więcej, stosuje się hierarchię diagramów szczegółowych

30 Diagram podstawowy (notacja)Symbol grupujący (stan) Początek Blok decyzyjny Element synchronizujący Koniec

31 Diagram podstawowy i szczegółowy (przykład)

32 Role uczestników RUP™ W Rational Unified Process™ uczestnicy projektu występują następujące grupy ról: Analitycy Projektanci (developers) Testerzy Managerowie Inni W grupie analityków wyróżnia się takie role jak: Analityk procesów biznesowych Projektant biznesowy Weryfikator (reviewer) modelu biznesowego Weryfikator wymagań Analityk systemowy Specyfikator wymagań Projektant interfejsu

33 Role uczestników RUP™ W grupie projektantów występują takie role jak:Architekt oprogramowania Weryfikator architektury Weryfikator kodu Projektant baz danych Weryfikator projektów Projektant Implementator Integrator Do grupy testerów zalicza się następujące role: Projektant testów Tester W grupie managerów występują: Manager zmian Manager konfiguracji Manager wdrożenia Inżynier procesów Manager projektu Weryfikator projektu

34 Role uczestników RUP™ Oprócz tego wyróżnia się pewne dodatkowe role, takie jak: Użytkownik końcowy Grafik Udziałowiec Administrator systemu Specjalista do spraw narzędzi