Rational Unified Process

Rational Unified Process
Inż. Michał Kruk Inż. Bartłomiej Pióro

Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro
Agenda RUP wprowadzenie Metodyka RUP’a Przedstawienie etapów metodyki RUP Przedstawienie procesów metodyki RUP Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

RUP wprowadzenie Rational Unified Process jest : Iteracyjną i przyrostowa metodyka W pełni konfigurowalną platformą do obsługi procesu tworzenia oprogramowania Jest to iteracyjna i przyrostowa metodyka przedstawiona przez firmę Rational. (Teraz IBM) Rational Unified Process, czyli RUP, jest konfigurowalną platformą do obsługi procesu tworzenia oprogramowania, która zapewnia najlepsze praktyki i jest oparta na konfigurowalnej architekturze, dzięki której można wybierać i wdrażać tylko te składniki procesu, które są potrzebne na danym etapie projektu. Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Metodyka RUP Jest oparta na doświadczeniach największych firm w branży informatycznej Opiera się na zestawie praktyk: iteracyjny rozwój, zarządzanie wymaganiami, architektura komponentowa, modelowanie wizualne, weryfikacja jakości, zarządzanie zmianami Metodyka Rational Unified Process jest oparta na pomysłach i doświadczeniu najlepszych firm w branży informatycznej, partnerów i tysięcy rzeczywistych projektów, doskonale połączonych w efektywny zestaw najlepszych praktyk, schematów przepływu pracy i artefaktów umożliwiających iteracyjne tworzenie oprogramowania. Do praktyk tych należą: - Iteracyjny rozwój - Zarządzanie wymaganiami - Architektura oparta o komponenty - Wizualne modelowanie - Systematyczna weryfikacja jakości - Zarządzanie zmianami Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Cykle Wytwarzanie oprogramowania następuje w cyklach: Cykl początkowy Cykle ewolucyjne Cykl życia oprogramowania : Rozpoczęcie (Inception) Opracowanie (Elaboration) Konstruowanie (Construction) Przekazanie (Transition) Zakłada, że oprogramowanie będzie tworzone w cyklach -- każdy z tych cykli dostarcza kolejną wersję oprogramowania. Pierwszy cykl to cykl początkowy, kolejne zaś noszą nazwę ewolucyjnych. Cykl życia oprogramowania można podzielić na następujące etapy: - Rozpoczęcie (Inception) - Opracowanie(Elaboration) - Konstruowanie (Constuction) - Przekazanie (Transition) Każdy z etapów kończy się wytworzeniem odpowiedniego artefaktu Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Faza Rozpoczęcia (Inception)
Ustalenie zakresu projektu i warunków granicznych : Zakres Projektu Kryteria sukcesu Ocenę ryzyka i zasobów (znaną także jako studium osiągalności - flexibility study) Określenie kamieni milowych i dat Ma na celu ustaleniu zakresu projektu i warunków granicznych. Podczas fazy rozpoczęcia zakładamy biznesowy przypadek dla systemu i ustalamy zakres projektowy. Aby tego dokonać trzeba zidentyfikować wszystkie zewnętrzne byty, z którymi system będzie współpracować (aktorzy) i zdefiniować naturę tego współdziałania na wysokim poziomie. To wymaga identyfikacji wszystkich przypadków użycia i opisanie ich w szczegółowy sposób. Biznesowy przypadek zawiera kryteria sukcesu, ocenę ryzyka oraz ocenę potrzebnych zasobów. Faza planowania pokazuje daty głównych kamieni milowych. !!!!! Koniecznie powiedziec o flexibility study. Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Faza Rozpoczęcia c.d. Wynikiem tej fazy są : Dokument wizji (Vision) Model przypadków użycia (10%-20%) Początkowy zestaw definicji Przypadek Biznesowy Dokument podsumowujący studium osiągalności Plan projektowy (fazy i iteracje) Model Biznesowy (o ile wymagany) Prototyp (-typy) Wynikiem fazy rozpoczęcia jest: -Dokument wizji: ogólna wizja wymagań rdzenia projektu, kluczowych cech i głównych ograniczeń - Początkowy model przypadków użycia (10% -20% całości). - Początkowy zestaw definicji. - Początkowy przypadek biznesu, który zawiera kontekst biznesu, kryteria sukcesu (dochód, rozpoznanie rynku, itd.) i finansowe prognozy. - Początkowa ocena ryzyka. - Plan projektowy prezentujący fazy i iteracje. - Biznesowy model (o ile jest wymagany). Jeden albo kilka prototypów. Wizja : 1. Wstęp 1 1.1 Cel 1 1.2 Zakres 1 1.3 Definicje, Akronimy i Skróty 1 1.4 Referencje 1 1.5 Przegląd 1 2. Umiejscowienie Rozwijanego Systemu 2 2.1 Możliwości Biznesowe 2 2.2 Dziedzina Problemowa 2 2.3 Status Pozycji Produktu 3 3. Charakterystyka Udziałowców I Użytkowników Systemu 4 3.1 Demografia Rynku. 4 3.2 Charakterystyka Udziałowców Systemu 4 3.3 Charakterystyka Użytkowników Systemu 5 3.4 Środowisko Użytkowników 5 3.5 Kluczowe Potrzeby Użytkowników Systemu 7 3.6 Alternatywy i Konkurencja 7 4. Przegląd Produktu 8 4.1 Perspektywa Produktu 8 4.2 Architektura Systemu 8 4.3 Założenia i Zależności 10 5. Wymagania Funkcjonalne 11 5.1 Logowanie Do Systemu 11 5.2 Przydzielenie Poziomu Dostępu Dla Użytkownika i Pozycji Konfiguracji 11 5.3 Tworzenie Kopii Zapasowych 11 5.4 Rejestracja Testów 11 5.5 Rejestracja Wdrożenia Zmiany 11 5.6 Wprowadzanie Raportów Okresowych 11 5.7 Zgłoszenie, Zapoznanie Się i Zakwalifikowanie Problemu 11 5.8 Administracja 12 5.9 Zarządzanie Pozycjami Konfiguracji 12 5.10 Zarządzanie Użytkownikami 12 5.11 Zarządzanie Projektami 12 6. Ograniczenia 13 Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Faza Opracowania Szczegółowa analiza problemu Rozwinięcie planu projektowego Minimalizacja ryzyka Budowa Prototypów Celem fazy opracowania jest bardziej szczegółowa analiza domeny problemu, oraz wypracowanie fundamentów dla architektury. Należy wyeliminować te elementy, które są obarczone nieakceptowanym poziomem ryzyka, jak również zająć się rozwinięciem szczegółowego planu projektowego. Decyzje architektoniczne muszą bazować na zrozumieniu całości systemu: jego funkcjonalności i ograniczeń. Faza opracowania jest jedną z najbardziej krytycznych faz i cechuje się wysokimi kosztami i ryzykiem. Wymagania, architektura i plany powinny osiągnąć stabilną postać, tak aby ryzyko zostało zminimalizowane, co pozwoli na określenie kosztów i czasu potrzebnego na ukończenie projektu. Bada się tutaj różne rozwiązania, budując prototypy - w jednej lub kilku iteracjach. Budowa prototypów ułatwia eliminacje ryzyka oraz ustanawianie kompromisów między wymaganiami a możliwościami środowiska implementacji. Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Faza Opracowania c.d. Wynikiem tej fazy są : Kompletny model przypadków użycia (min %) Dodatkowe wymagania Opis architektury Prototyp Końcowy plan projektu Specyfikacja procesów Wstępna wersja podręcznika użytkownika (opcja) Wynikiem fazy opracowania jest: - Model przypadków użycia (kompletny, w 80%), który powinien zawierać wstępne opracowanie wszystkich przypadków użycia wraz z zidentyfikowanymi aktorami, oraz szczegółowymi specyfikacjami dla większości z tych przypadków. - Dodatkowe wymagania (funkcjonalne i niefunkcjonalne nie ujęte w żadnym z przypadków użycia) - Opis architektury - Prototyp - Plan dla całości projektu (z uwzględnieniem iteracji i kryteriów przechodzenia między nimi) - Specyfikacje procesów, które będą wykorzystywane Wstępną wersję podręcznika dla użytkownika (opcjonalnie) Tutuaj także końcowy dokument SAD, wspomnieć o PRI i o BYT Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Faza Konstruowania Budowa Rozwój Integracja Testowanie Podstawowym zadaniem tej fazy jest budowa i rozwój komponentów oraz ich integracja i testowanie. Faza konstrukcji jest poświęcona procesom wytwarzania. Kładzie ona duży nacisk na zarządzanie zasobami, optymalizację kosztów i planu oraz poprawę jakości. Dla dużych projektów, można zrównoleglić procesy, co przyspiesza realizację, aczkolwiek takie rozwiązanie komplikuje zarządzanie poprzez konieczność synchronizacji przepływów prac. Stabilna architektura i dobry plan znacząco wspierają zadania fazy konstrukcji. Dlatego tak ważne jest to, co wypracowano w fazach poprzedzających. Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Faza Konstruowania c.d. Wynikiem tej fazy są : Produkt zintegrowany z platformą docelową Podręcznik użytkownika Opis bieżącego wydania Faza Konstruowania c.d. Wynikiem fazy Konstruowania jest: - Produkt zintegrowany z docelową platformą - Podręcznik użytkownika - Opis bieżącego wydania Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Faza Wdrażania Przekazanie produktu do użytkownika (-ów) końcowego (-ych) : Korekta błędów Wynikiem tej fazy jest działający system Podstawowym zadaniem tej fazy jest przekazanie produktu do użytkowników końcowych. Z reguły pociąga to za sobą korektę błędów, dokończenie elementów odłożonych, ulepszanie niektórych własności, itp. W praktyce oznacza to z reguły, iż pewien użyteczny - o akceptowalnej jakości - podzbiór własności systemu został ukończony. Wynikiem Fazy Wdrażania jest działający system Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Etapy RUP specyfikacja wymagań (ang. requirements capture), analiza wymagań (ang. requirements analysis), projektowanie (ang. design), implementacja (ang. implementation) testowanie (ang. test), konserwacja (ang. deployment). Etapy RUP Z każdą z powyżej opisanych faz związane są grupy czynności, które wykonuje się podczas każdej z iteracji. Są to: - specyfikacja wymagań (ang. requirements capture), - analiza wymagań (ang. requirements analysis), - projektowanie (ang. design), - implementacja (ang. implementation), - testowanie (ang. test), - konserwacja (ang. deployment). Natężenie prac związane z różnymi czynnościami zależy od fazy, w której znajduje się rozwój projektu. W początkowych fazach istotne są czynności związane ze zbieraniem wymagań i analizą, natomiast w końcowych istotniejsza staje się implementacja i konserwacja wytworzonego systemu. Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Fazy Modelowanie biznesowe Wymagania Analiza i projektowanie Implementacja Testowanie Wdrażanie Konfiguracja i zarządzanie zmianami Zarządzanie projektem Określenie środowiska Metodyka RUP wyróżnia następujące fazy wytwarzania oprogramowania: - Modelowanie biznesowe - Wymagania - Analiza i projektowanie - Implementacja - Testowanie - Wdrażanie - Konfiguracja i zarządzanie zmianami - Zarządzanie projektem - Określenie środowiska Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Modelowanie biznesowe
Analiza struktury i dynamiki organizacji Identyfikacja problemów Identyfikacja procesów biznesowych Modelowanie biznesowe Modelowanie biznesowe jest pierwszym z przepływów prac i powinno poprzedzać proces specyfikowania wymagań na oprogramowanie. W tym modelu, miedzy innymi zajmujemy się przeanalizowaniem struktury i dynamiki organizacji, w której oprogramowanie ma być wdrażane (tzw. “organizacji docelowej”). Następuje tu również zrozumienie aktualnych problemów organizacji, które identyfikują miejsca dla potencjalnych ulepszeń. Model ten powinien obejmować na tyle obszerny opis procesów biznesowych zachodą5cych u klienta, aby był jednakowo zrozumiały przez wszystkich uczestników projektu (klienta i zespół projektowy). Tak, aby postrzegali docelową organizację w jednakowy sposób (jej strukturę, dynamikę i problemy). Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Wymagania Specyfikują wizję systemu, czyli : Przypadki użycia Granice systemu Koszty i Czas wytworzenia Interfejs użytkownika Wymagania Wymagania są drugim etapem prac i z reguły poprzedzone są procesem modelowania biznesowego. Specyfikują, jak zbudować wizję systemu oraz jak przenieść wizję na model przypadków użycia, który (wraz ze specyfikacją uzupełniającą) szczegółowo zdefiniuje zbiór wymagań. Celem tego działania jest: - Osiągnięcie konsensusu wśród uczestników projektu: „co i dlaczego powinien robić projektowany system”. - Uzyskanie lepszego zrozumienia wymagań dla systemu przez członków zespołu projektowego. - Określenie granic systemu. - Ustanowienie bazy dla planowania iteracji przy pracach projektowych. - Ustanowienia bazy dla szacowania kosztów i czasu niezbędnego dla realizacji projektu. -Zdefiniowanie interfejsu użytkownika w oparciu o cele i potrzeby użytkowników. Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Analiza i Projektowanie
Zamiana wymagań w specyfikację implementacji systemu : Ustanowienie stabilnej architektury Przystosowanie projektu do środowiska implementacji Uwzględnienie własności systemu Analiza i Projektowanie Podstawowym celem fazy prac Analiza i projektowanie jest zamiana wymagań w specyfikację sposobu implementowania systemu: „określenia najlepszej strategii dla jego implementacji”. Osiąga się to poprzez: - ustanowienie stabilnej architektury - bazy dla budowy systemu łatwego do zrozumienia i rozwijania, - przystosowanie projektu do środowiska implementacji, - uwzględnienie własności systemu, takich jak: wydajność, skalowalność, itp. Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Analiza Transformacja wymagań do postaci zbiorów klas i podsystemów w oparciu o: Przypadki użycia Wymagania funkcjonalne Wynikiem jest „idealny” system bez uwzględnienia ograniczeń środowiska implementacji i wymagań niefunkcjonalnych Analiza Zadaniem analizy jest transformacja wymagań na system w postać, która jest dobrze mapowana do obszaru zainteresowań projektantów, czyli do zbioru klas i podsystemów. Ta transformacja oparta jest w RUP o przypadki użycia i wymagania funkcjonalne. Analiza skupia się na funkcjonalności systemu i ignoruje zarówno wymagania niefunkcjonalne, jak i ograniczenia środowiska implementacji. Można powiedzieć, że analiza prowadzi do uzyskania „prawie idealnego” obrazu systemu. Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Projektowanie Przystosowanie wyników analizy do wymagań niefunkcjonalnych i ograniczeń środowiska implementacji Optymalizacja systemu Pełne uwzględnienie funkcjonalności Projektowanie Zadaniem projektowania jest przystosowanie wyników analizy do wymagań niefunkcjonalnych i ograniczeń środowiska implementacji. Projektowanie jest uszczegółowieniem analizy. Aktywności skupione są na optymalizacji projektu systemu, w konkretnym środowisku implementacji, z jednoczesnym zapewnieniem pełnego pokrycia dla funkcjonalności. Wspomnieć o MASACH.. Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Artefakty Główne artefakty fazy Analizy i Projektowania : Model Projektowy Model Analityczny Interfejsy Główne artefakty wytworzone podczas fazy analizy i projektowania to: Model projektowy Składa się on z klas, pakietów i podsystemów. Pakiety i podsystemy traktowane są jako rodzaj środka organizacyjnego pozwalającego na zmniejszenie złożoności modelu wynikowego. Model analityczny Jest to artefakt będący efektem aktywności związanych z fazą analizy. Będąc rodzajem abstrakcji (generalizacji modelu projektowego), skupia się wyłącznie na funkcjonalności systemu. Dalsze uszczegóławianie modelu jest przeprowadzane w trakcie projektowania. Interfejsy Specyfikują zbiór operacji możliwych do wykonania na elemencie modelu. Interfejsy specyfikowane są poprzez sygnatury operacji dostępnych dla danego elementu modelu. Sygnatura każdej operacji jest opisywana przez liczbę i rodzaj argumentów oraz typ wartości zwracanej. Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Implementacja Wytworzenie działającej aplikacji na podstawie modelu z fazy projektowania. Implementacja Celem fazy implementacji jest wytworzenie działającej aplikacji. Faza ta opiera się modelu stworzonym podczas fazy projektowania. Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Testy Sprawdzenie zgodności z wymaganiami Sprawdzenie stabilności działania aplikacji „Wyłapanie” błędów Podczas testów sprawdzana jest zarówno zgodność z wymaganiami przygotowanymi podczas wcześniejszych etapów jak również stabilność działania aplikacji. Na testowanie składają się następujące aktywności: - przygotowanie planu testów - projektowanie i implementacja testów - wykonanie testów integracyjnych oraz testów systemowych - analiza wyników Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Wdrożenie Wytworzenie i dostarczenie oprogramowania do użytkowników końcowych Celem wdrażania jest udane wytworzenie końcowego produktu i dostarczenie programowania dla końcowych użytkowników. To wiąże się z szerokim zakresem dodatkowej działalności, m. in.: - fizyczne wytworzenie wersji instalacyjnej oprogramowania. - opakowania oprogramowania - dystrybucja oprogramowania. - instalacja oprogramowania. - utworzenie dokumentacji i pomocy dla użytkowników. W wielu przypadkach, faza wdrożenia zawiera też działalności takie jak: - planowanie i przeprowadzenie testów beta - migracja istniejącego oprogramowania albo danych. - ogólna akceptacja. Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Konfiguracja i zarządzanie zmianami
Opis procesu kontroli artefaktów wytworzonych przez zespół projektowy Występujące problemy : Symultaniczne uaktualnienia Limitowane zawiadomienia Duża ilość wersji W tej fazie opisujemy jak skontrolować liczne artefakty produkowane przez dużą ilość osób pracujących nad wspólnym projektem. Kontrola pomaga uniknąć nadmiernych kosztów i zapewnia, że wynikłe artefakty nie są w konflikcie z powodu wymienionych niżej problemów: - Symultaniczne uaktualnienia - kiedy dwóch albo więcej pracowników pracuje oddzielnie na tym samym artefakcie, ostatni dokonuje zmiany i niszczy pracę poprzedniego. - Limitowane zawiadomienia - Kiedy problem w artefaktach jest podzielony na wielu producentów i kilku z nich nie informuje o zmianach. - Wiele wersji - niektóre największe programy są rozwinięte w ewolucyjnych wersjach. Jedna wersja mogłaby być w użyciu klienta, kiedy inna jest w próbie a trzecia jest nadal w rozwoju. Jeśli problemy są znalezione w każdej wersji, zmiany muszą zostać rozpropagowane pomiędzy nimi. W fazie tej określamy jak można zarządzać równoległym rozwojem oraz jak zautomatyzować proces tworzenia. Jest to szczególnie ważne w iteracyjnym procesie. Określamy tu również jak można prowadzić dziennik kontroli. Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Zarządzanie projektem
Główne cele : Dostarczenie wskazówek wspomagających planowanie prac Organizowanie zespołów Dostarczenie szablonów W RUP nie ma pełnego przykrycia procesu zarządzania Zarządzanie projektem wymaga umiejętności lawirowania pomiędzy konkurującymi często wymaganiami, ograniczeniami i ryzykami, po to by zaspokoić potrzeby klienta i użytkowników końcowych. Trzy główne cele przepływu prac zarządzanie projektem to: - Dostarczenie praktycznych wskazówek wspomagających planowanie prac, organizowanie zespołu (przydział zadań do grup, osób i ustalanie odpowiedzialności), kontrolą realizacji projektu i monitorowanie postępów - Dostarczenie szablonów dla zarządzania ryzykiem. - Dostarczenie szablonów dla zarządzania procesem budowy złożonego oprogramowania. W RUP, nie podjęto prób przykrycia wszystkich aspektów procesu zarządzania. Nacisk położono głównie na: -Planowanie obejmujące szerszy zakres projektu (z uwzględnieniem cykli, faz i iteracji) oraz planowanie szczegółowe dla poszczególnych iteracji. - Zarządzanie ryzykiem (wykrywanie potencjalnych problemów). - Pomiary (metryki) i monitorowanie postępów (odpowiednio do założonych planów). Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Określenie środowiska
Wybór i dostarczenie narzędzi Określenie środowiska systemowego Określenie środowiska Celem etapu „Określenie środowiska” jest wybranie i dostarczenie narzędzi, które będą użyte w procesie tworzenia aplikacji. Podczas tego etapu następuje również określenie środowiska systemowego. Seminarium Magisterskie 2004/05. Michał Kruk, Bartłomiej Pióro

Rational Unified Process

Podobne prezentacje

Prezentacja na temat: "Rational Unified Process"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres

Wejść

Zaloguj się poprzez sieć społeczną:

Rational Unified Process

Podobne prezentacje

Prezentacja na temat: "Rational Unified Process"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres