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™

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

Model iteracyjny przyrostowy

Model iteracyjny przyrostowy

Porównanie z cyklem kaskadowym tradycyjny 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

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

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

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

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

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

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

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

Modelowanie procesów biznesowych Głó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

Formułowanie wymagań Główne cele prac w ramach etapu Osią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

Analiza i projektowanie Głó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

Implementacja Główne cele prac w ramach etapu Okreś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

Testy Główne cele prac w ramach etapu Weryfikacja 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

Rozpowszechnianie Główne cele prac w ramach etapu Instalacja 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

Czynności przekrojowe 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

Proces architekturocentryczny RUP™ 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.

Proces bazujący na przypadkach użycia Przypadki 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

Metodyka jako produkt Wersja komercyjna - Rational Suite (metodyka + narzędzia) Wersja otwarta metodyki – „Open UP” Interaktywna przeglądarka metodyki: http://epf.eclipse.org/wikis/openup/

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

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)

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

Czynności Każdej roli odpowiada pewien ściśle ustalony zbiór czynności Czynnoś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

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

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

Diagramy podstawowe i szczegółowe Do 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

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

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

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

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

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