Rational Unified Process rational

Tomasz Wardziak 1

Rational Unified Process

www-306.ibm.com/software/rational/

w pigułce…

2Tomasz Wardziak

RUP? Ale po co?

3Tomasz Wardziak

O czym będzie?

Główne koncepcje metodyki RUP 6 zalecanych praktyk

Rozwój przyrostowy Zarządzanie wymaganiami Architektura komponentowa Modelowanie wizualne Ciągłe monitorowanie jakości Oprogramowanie dostosowujące się do zmian

Fazy rozwoju oprogramowania zgodnie z RUP Aktywności projektowe

4Tomasz Wardziak

Czym jest RUP?

RUP jest procesem tworzenia oprogramowania

RUP dostarcza zestaw WSKAZÓWEK mówiących jak przydzielać ludzi do zadań i czego od nich oczekiwać

Głównym celem metodyki RUP jest zagwarantowanie dostarczenia produktu o wysokiej jakości, który spełnia oczekiwania zleceniodawcy i jest wykonany w planowanym czasie i budżecie

Metodykę RUP można dopasowywać do potrzeb

RUP nie narzuca jedynej słusznej drogi do celu ale przedstawia szereg sprawdzonych metod, które są skuteczne w zależności od kontekstu organizacji

5Tomasz Wardziak

6 zalecanych praktyk (best practices)

RUP zaleca stosowanie się do niżej wymienionych zasad: Rozwój przyrostowy Zarządzanie wymaganiami Architektura komponentowa Modelowanie wizualne Ciągłe monitorowanie jakości Oprogramowanie dostosowujące się do zmian

Słowo „zalecana praktyka” oznacza czynności, które okazały się niezwykle skuteczne w organizacjach, których doświadczenia stanowiły bazę dla RUP

6Tomasz Wardziak

1 - Rozwój przyrostowy

W praktyce nie jest możliwe odgadnięcie jakie funkcje będzie miało tworzone oprogramowanie, gdy zostanie ukończone

RUP zaleca sukcesywny przegląd postawionych wymagań i ich realizowanie w sposób iteracyjny

Początkowo realizujemy najważniejsze z punktu widzenia użytkownika wymagania, dostarczając możliwie najwcześniej działające najważniejsze funkcje systemu

Modyfikacja wymagań, ograniczeń, planowanego czasu wykonania projektu oraz jego budżetu jest dużo łatwiejsza przy stosowaniu podejścia przyrostowego

Klient może oceniać produkt przed jego ukończeniem

7Tomasz Wardziak

1 - Rozwój przyrostowy cd.

8Tomasz Wardziak

2 – Zarządzanie wymaganiami

RUP opisuje: Sposób zapisu, przechowywania oraz pozyskiwania wymagań

funkcjonalnych oraz niefunkcjonalnych Relacje pomiędzy dokumentem wizji klienta a dokumentami fazy

analizy

Jako środek wyrazu wymagań użytkownika metodyka RUP zaleca stosowanie diagramów przypadków użycia (use case) w notacji UML oraz scenariuszy. Korzystanie z tych form stanowi ułatwienie dla zespołu projektowego ale także umożliwia konsultacje wyników fazy analizy z klientem

9Tomasz Wardziak

3 - Architektura komponentowa

Architektura komponentowa dobrze pasuje do koncepcji iteracyjnego wytwarzania oprogramowania

Podsystemy i pakiety stanowią podstawową jednostkę przy analizie i projektowaniu systemu

Sposoby testowania zalecane przez RUP stawiają duży nacisk na testowanie każdego kawałka z osobna i systemu po integracji jako całości

Łatwość wprowadzania zmian – zgodność z ideą zarządzania wymaganiami

10Tomasz Wardziak

4 - Modelowanie wizualne

Modele stanowią uproszczoną reprezentację rzeczywistości przez co stają się możliwe do realizacji

Większość metodyki RUP dotyczy: tworzenia i zarządzania modeli określenia ról, które są odpowiedzialne za produkcje modeli zależności pomiędzy modelami

Jako środek wyrazu do modelowanie RUP używa UML

11Tomasz Wardziak

5 - Ciągłe monitorowanie jakości

Za jakość odpowiedzialna jest cała organizacja i właśnie jakość powinna stanowić główne kryterium projektowe

Realizowanie polityki jakości nie jest jednym z etapów tworzenia oprogramowania – jest „sposobem życia zespołu projektowego”

RUP identyfikuje dwa pojęcia jakości: Jakość produktu – jak produkt dopasowuje się do potrzeb

klienta Jakość procesu – poziom „dojrzałości” organizacji czyli stopień

dopasowania aktywności projektowych do wytycznych procesowych

12Tomasz Wardziak

6 - Oprogramowanie dostosowujące się do zmian

Metodyka RUP nie unika bolesnego faktu, że oprogramowanie podlega ciągłym zmianom oraz rozbudowie

RUP proponuje, żeby artefakty tworzone podczas całego procesu były tworzone z pewnym „marginesem”, pozwalającym na wprowadzanie zmian

Zarządzanie Zmianą jest jedną z aktywności definiowanych przez RUP – zawiera szereg wytycznych, szablonów dokumentów oraz opis koniecznych aktywności

13Tomasz Wardziak

Fazy RUP

Metodyka RUP dzieli produkcje oprogramowania na cztery następujące po sobie fazy:

Faza rozpoczęcia (inception) Faza opracowania (elaboration) Faza konstrukcji (construction) Faza przekazania (transition)

14Tomasz Wardziak

Fazy RUP cd.

Cztery fazy proponowane przez RUP można zapisać na dwóch osiach. Model iteracyjny zaprezentowany na następnym slajdzie pokazuje jak proces jest zorganizowany

Dynamiczny aspekt procesu pokazany jest na osi poziomej i wyrażany jest poprzez cykle, iteracje, kamienie milowe.

Statyczny aspekt procesu pokazany jest na osi pionowej i wyrażany jest poprzez aktywności, artefakty, role oraz diagramy aktywności.

15Tomasz Wardziak

Fazy RUP cd.

16Tomasz Wardziak

Fazy RUP cd.

Cechy cyklu życiowego oprogramowania według RUP: Cztery następujące po sobie fazy Każda faza zakończona kamieniami milowymi Na końcu każdej fazy następuje analiza jej produktów celem

sprawdzenia czy jej założenia zostały osiągnięte Pozytywna ocena produktów fazy powoduje przejście do

następnej

17Tomasz Wardziak

Fazy RUP cd.

Rozkład zasobów w czasie prezentuje powyższy diagram

18Tomasz Wardziak

Faza 1 – rozpoczęcie (inception)

Podczas fazy rozpoczęcia należy określić zakres projektu oraz przypadki użycia z punktu widzenia wizji klienta.

Należy zidentyfikować wszystkie zewnętrzne byty, z którymi system powinien współpracować. Trzeba także opisać charakter tej współpracy.

Na koniec tego etapu wszystkie przypadki użycia muszą być wykryte i zapisane a najbardziej kluczowe powinny mieć już dokładną specyfikację.

Do opisu każdego przypadku użycia należy dołączyć: kryterium powodzenia, ocenę ryzyka, szacowany koszt

wytworzenia, plan wytworzenia z zaznaczeniem kamieni milowych

19Tomasz Wardziak

Artefakty fazy rozpoczęcia (inception)

Główne wymagania na projekt, funkcjonalność oraz ograniczenia

Początkowy diagram przypadków użycia (10%-20%) Analiza ryzyka w projekcie Plan projektu (ukazujący fazy i iteracje w czasie) Jeden lub więcej prototypów pozwalających na

wychwycenie tak zwanego „ryzyka technicznego” oraz pozostałych wymagań na system

Dokument wizji biznesowej

20Tomasz Wardziak

Faza 2 – opracowanie (elaboration)

Głównymi elementami fazy opracowania są: Analiza dziedziny problemowej Opracowanie architektury zgodnej z charakterem produktu Wypracowanie planu projektu Usunięcie największych czynników ryzyka

Aby zrealizować powyższe czynności należy przyjąć bardzo szeroką perspektywę przy analizowaniu systemu (a mile wide and inch deep)

Często ta faza nazywana jest najtrudniejszą i najważniejszą w projekcie. Od jej wyników zależy dalszy przebieg projektu i jego sukces lub porażka.

21Tomasz Wardziak

Faza 2 – opracowanie (elaboration) cd.

W większości przypadków faza opracowania ujawnia, że początkowy prosty i niskobudżetowy projekt zamienia się w bardzo złożony i kosztowny system

Podczas fazy opracowania należy upewnić się, że: Architektura, wymagania oraz wszystkie plany zostały

wytworzone w sposób precyzyjny i nie budzący zastrzeżeń Ryzyko w projekcie zostało zminimalizowane

Dopiero na końcu fazy opracowania możemy poznać dokładne szacunki kosztu oraz czasu projektu.

22Tomasz Wardziak

Artefakty fazy opracowania (elaboration)

Diagram przypadków użycia z dokładnym opisem oraz przypisaniem aktorów (powinien być ukończony w 80%)

Zestaw wymagań niefunkcjonalnych Opis architektury systemu Dokładna analiza ryzyka Zaktualizowany dokument wizji biznesowej Wszystkie niezbędne plany projektowe w tym plan

implementacji dla całego projektu

23Tomasz Wardziak

Faza 3 – konstrukcja (construction)

W tej fazie następuje implementacja zaplanowane oprogramowania z uwzględnieniem wszystkich wcześniej wytworzonych dokumentów

Podczas fazy konstrukcji pozostałe wymagania funkcjonalne są wykrywane i wcielane do dokumentacji i implementacji

Wszystkie funkcje systemu są dokładnie testowane

Zarządzanie zasobami oraz kontrola działań jest kluczowa podczas tej fazy w celu optymalizacji planów, kosztów oraz jakości projektu.

24Tomasz Wardziak

Artefakty fazy konstrukcji (construction)

Głównym efektem tej fazy jest gotowy produkt, który można przekazać do wdrożenia u klienta.

25Tomasz Wardziak

Faza 4 – przekazanie (transition)

W fazie przekazania następuje wdrożenie produktu u użytkownika końcowego.

Razem z samym oprogramowaniem należy przekazać całą dokumentację projektową, która została zamówiona przez klienta w umowie zlecającej budowę systemu.

Użytkownicy często zgłaszają błędy, które nie zostały wychwycone na testach oraz prośby o modyfikacje. Faza przekazania przeplata się więc z poprzednimi dwiema fazami.

26Tomasz Wardziak

Faza 4 – przekazanie (transition) cd.

Sporą ilość czasu tuż po rozpoczęciu przekazania należy poświecić na szkolenia użytkowników końcowych z zasad działania produktu. Należy zapewnić im wsparcie techniczne oraz odebrać feedback.

Pod koniec fazy przekazania należy zastanowić się, czy wszystkie cele projektowe zostały osiągnięte, czy też może należy zrobić jeszcze jedną iterację cyklu.

27Tomasz Wardziak

Iteracje faz RUP

Iteracja jest pętlą projektową, która kończy się wypuszczeniem działających plików projektowych, stanowiących podzbiór kompletnego produktu. Podzbiór ten z każdą zakończoną iteracją będzie się zbliżał rozmiarami do finalnych oczekiwań.

Zaletami podejścia iteracyjnego są: Ryzyka mogą być szybciej wychwycone Łatwiej można wprowadzać modyfikacje Zespół projektowy można szkolić już po rozpoczęciu projektu Całkowita jakość produktu jest znacznie wyższa niż przy

realizacji analogicznego produktu metodą wodospadową

28Tomasz Wardziak

Iteracje faz RUP a jakość

29Tomasz Wardziak

Przerywnik

30Tomasz Wardziak

Aktywności w metodyce RUP

Modelowanie biznesowe Zarządzanie wymaganiami Analiza i projektowanie Implementacja Testowanie Wdrażanie Zarządzanie zmianą i konfiguracją Zarządzanie projektem Zarządzanie środowiskiem

Diagram

31Tomasz Wardziak

Aktywność: Modelowanie biznesowe

Zakres: Zrozumienie specyfiki i dynamiki organizacji klienta Zrozumienie problemów klienta i wykrycie możliwych

usprawnień Upewnienie się, że klienci, użytkownicy i zespół projektowy w

ten sam sposób postrzegają organizację kliencką i jej cechy Wypracowanie wymagań systemowych, które będą wspierały

organizację kliencką

32Tomasz Wardziak

Aktywność: Zarządzanie wymaganiami

Zakres: Osiągnięcie porozumienia z klientem i udziałowcami odnośnie

tego, co projektowany system powinien oferować Zapewnienie projektantom systemu lepszego zrozumienia

realizowanych wymagań Definiowanie granic systemu Dostarczenie podstawy do szacowania kosztów i czasu

potrzebnych na realizację systemu Definicja cech GUI pod kątem potrzeb użytkowników

33Tomasz Wardziak

Aktywność: Analiza i projektowanie

Zakres: Zamiana wymagań w projekt przyszłego systemu Wypracowanie dokładnej architektury dla systemu Modyfikacja modelowego projektu pod kątem wydajności

(denormalizacja)

34Tomasz Wardziak

Aktywność: Implementacja

Zakres: Zapewnienie poprawnej organizacji kodu w formie podsystemów

poukładanych w warstwy Implementacja klas obiektów w formie komponentów (kody

źródłowe, binaria i inne) Testowanie wyprodukowanych podsystemów i komponentów Integracja wyprodukowanych kawałków w działający system

35Tomasz Wardziak

Aktywność: Wdrażanie

Zakres: Stworzenie instalatora dla systemu Zapewnienie łatwego sposobu na aktualizację

36Tomasz Wardziak

Aktywność: Zarządzanie zmianą i konf.

Zakres: Identyfikacje rzeczy podlegających konfiguracji Ograniczanie „dzikich zmian” w wyżej wymienionych Audyt zmian wprowadzonych w wyżej wymienionych Zapewnienie kompletności i poprawności systemu jako zestawu

współgrających elementów podlegających zarządzaniu konfiguracją

Dostarczenie sposobu na śledzenie dlaczego, kiedy i przez kogo artefakt został zmodyfikowany.

37Tomasz Wardziak

Aktywność: Zarządzanie projektem

Zakres: Dostarczenie metodyki do zarządzania projektem

informatycznym Dostarczenie praktycznych wskazówek odnośnie planowania,

zatrudnienia, wykonywania oraz monitorowania projektów Dostarczenie metodyki do zarządzania ryzykiem Zarządzanie ryzykiem Planowanie ilości iteracji oraz każdej z nich osobno Monitorowanie postępu projektu poprzez dobrze zdefiniowane

metryki

38Tomasz Wardziak

Aktywność: Zarządzanie środowiskiem

Zakres: Konfiguracja procesu dla konkretnego projektu Dostarczenie organizacji projektowej wytycznych odnośnie

procesu oraz narzędzi go wspierających

39Tomasz Wardziak

Już prawie koniec ;)

40Tomasz Wardziak

Zamiast podsumowania – zalety RUP ;)

Rational Unified Process zapewnia: Integrację działań całego zespołu projektowego Wsparcie projektowe narzędziami firmy IBM (dawniej Rational) Dostarczenie produktu w założonym czasie przy realizacji

przyjętego budżetu Jakość… jakość… jakość… a co za tym idzie produkt zgodny z

wymaganiami. Za tym idzie zadowolony klient a za nim kolejne zlecenia i szansa na zysk

Kto tego używa? IBM informuje, że RUP jest metodyką projektową w ponad 2 tysiącach firm (od kilkuosobowych po korporacje) z branż: telekomunikacja, produkcja, sektor finansowy, usługi IT, etc.

41Tomasz Wardziak

Czy to już w zasadzie koniec…? ;)

Pytania?

Źródło:http://www-306.ibm.com/software/rational/Wersja trial Rational Unified Process jest do

pobrania pod wyżej wymienionym adresem

42Tomasz Wardziak

Tak, to już KONIEC

Dziękuję za uwagę!