• Nie Znaleziono Wyników

Wykład 2Krótka charakterystyka RUP Rational Unified Process Studia Podyplomowe IT w Biznesie

N/A
N/A
Protected

Academic year: 2021

Share "Wykład 2Krótka charakterystyka RUP Rational Unified Process Studia Podyplomowe IT w Biznesie"

Copied!
14
0
0

Pełen tekst

(1)

Studia Podyplomowe IT w Biznesie

Rational Unified Process Wykład 2

Krótka charakterystyka RUP

Wykładowca:

dr inż. Ewa Stemposz ewag@ipipan.waw.pl

Polsko-Japońska Wyższa Szkoła Technik Komputerowych

Warszawa

(2)

Zagadnienia

Co to jest RUP?

Kto i jak używa RUP?

Dwa wymiary RUP

Najlepsze praktyki a RUP Podsumowanie

Prezentowany materiał został przygotowany w oparciu o publikację: Philippe Kruchten, The

Rational Unified Process An Introduction, Addison-Wesley, 1999.

(3)

Co to jest Rational Unified Process ? (1)

Rational Unified Process (RUP) - produkt firmy Rational Software, wspomagający zdyscyplinowane podejście do rozwoju oprogramowania. Cel - produkcja oprogramowania wysokiej jakości w przewidywalnym dla klienta czasie i budżecie.

RUP, to także szkielet, rama (framework), który może być przystosowany (również rozszerzany) stosownie do specyficznych potrzeb adaptującej go organizacji. RUP oparty został o zbiór sześciu najlepszych praktyk:

iteracyjny rozwój, zarządzanie wymaganiami, architektura oparta o komponenty, wizualne modelowanie, systematyczna weryfikacja jakości i zarządzanie zmianami (ale nie tylko).

RUP jest zintegrowany z wieloma produktami firmy Rational Software, np.

Rational Rose (modelowanie wizualne) czy ClearCase (zarządzanie zmianami): każde z narzędzi zostało zaprojektowane w taki sposób, by dostarczyć wsparcia również użytkownikom początkującym (tool mentors).

Lee Osterweil (1987):

“Software processes are software, too”

(4)

Co to jest Rational Unified Process ? (2)

RUP - w ramach “douczania” - dostarcza:

 Microsoft Word i Adobe FrameMaker: szablony dla podstawowych dokumentów i raportów.

 Rational SoDa: szablony wspierające automatyzację prac przy przetwarzaniu dokumentów pochodzących z wielu źródeł.

 RequisitePro: szablony wspomagające zarządzanie wymaganiami.

 Microsoft Project: szablony wspomagające planowanie projektu realizowanego w oparciu o iteracyjne podejście i bazującego na RUP.

 HTML: szablony wspierające pracę online.

(2) Przykładowe artefakty dla prostych systemów.

(1) Szablony dla podstawowych artefaktów wytwarzanych w trakcie procesu projektowego, takich jak np.:

E-coach zawiera wiele wariantów RUP ( np. RUP dla e-biznesu), które mogą

służyć jako punkt startowy dla wielu różnych zastosowań.

(5)

Kto i jak używa RUP ?

 RUP został wykorzystany jak dotąd przez więcej niż 1000 organizacji (dane z końca 1999 roku) dla różnych zastosowań, dla małych i dużych projektów:

 Telekomunikacja: Ericsson, Alcatel, MCI

 Transport, lotnictwo, obrona: Lockheed-Martin, British Aerospace

 Produkcja: Xerox, Volvo, Intel

 Finance: Visa, Merrill Lynch, Schwab

 Inne: Ernst & Young, Oracle, Deloitte & Touche.

 Więcej niż 50% użytkowników albo już wykorzystywało RUP do e- biznesu albo planowało wykorzystać w najbliższej przyszłości.

 Niektóre z organizacji - ściśle w oparciu o RUP - budowały własny

proces dostosowany do ich specyficznych potrzeb, a niektóre

wykorzystywały RUP bardziej nieformalnie traktując jak repozytorium

rad, wytycznych i szablonów.

(6)

Dwa wymiary RUP (1)

Strukturę RUP można analizować z dwóch perspektyw, zwanych tu

“wymiarami”:

(1) Wymiar statyczny, związany ze statycznymi aspektami procesu, takimi jak, np.: części składowe procesu, przepływy prac, aktywności, artefakty i uczestnicy projektu. Wymiar statyczny procesu jest reprezentowany przez oś pionową rysunku na następnej folii. Na osi pionowej zostały oznaczone główne przepływy prac, grupujące aktywności zgodnie z ich wewnętrzną naturą.

(1) Wymiar dynamiczny, reprezentujący aspekty dynamiczne procesu i

opisywany w terminach, takich jak: cykle, fazy, iteracje i kamienie

milowe. Oś pozioma rysunku reprezentująca ten wymiar odzwierciedla

upływ czasu.

(7)

Dwa wymiary RUP (2)

Fazy

Początkowa Opracowywanie Modelowanie biznesowe

Wymagania Analiza i projektowanie Implementacja Testowanie

Konfiguracja i zarządzanie wymaganiami

Konstrukcja Wdrażanie

Zarządzanie projektem Środowisko

Przepływy prac

Wdrażanie

Iter. #1 Iter.#1, Iter.#2 Iter.#1, Iter.#2, Iter.#3 Iter.#1, Iter.#2

Iteracje

(8)

Najlepsze praktyki a RUP (1)

 Iteracyjny rozwój

 zarządzanie wymaganiami,

 integrację elementów składowych produktu (integracja postępuje progresywnie, a nie w postaci jednego “big bang” na końcu, ponadto integruje się mniejsze elementy),

 wcześniejszą mitygację ryzyk (z reguły moment integracji jest tym momentem, w którym odsłaniają się zagrożenia dla projektu),

 ponowne użycie,

 bardziej stabilną architekturę,

 zwiększenie zaangażowania i umiejętności uczestników projektu (patrz przykład testerów),

 ulepszenie procesu w efekcie nabywania doświadczeń w kolejnych iteracjach.

W RUP planowana jest liczba iteracji, cel i czas trwania każdej z nich, tak by zapobiec powstaniu niekontrolowanego, trwającego bez końca procesu.

Podejście iteracyjno-przyrostowe rekomendowane przez RUP wspomaga:

(9)

Najlepsze praktyki a RUP (2)

 Zarządzanie wymaganiami

 lepszą kontrolę złożonych projektów,

 uzyskanie produktu o lepszej jakości,

 zwiększenie satysfakcji klienta,

 poprawę komunikacji w zespole projektowym.

Zarządzanie wymaganiami rekomendowane przez RUP wspomaga:

 Architektura oparta o komponenty

Aktywności związane z projektowaniem, szczególnie w pierwszych

iteracjach, skupione są głównie na definiowaniu architektury przyszłego

systemu. W efekcie, w pierwszych iteracjach powstaje architektoniczny

prototyp, stopniowo ewoluujący, aż do przybrania ostatecznej postaci

systemu w iteracjach końcowych. RUP wspiera systematyczne, metodyczne

podejście do projektowania, rozwijania i poddawania walidacji architektury

systemu oferując style architektoniczne, reguły, ograniczenia oraz

szablony dla opisu architektury bazujące na idei posiadania wielu perspektyw

systemu.

(10)

Najlepsze praktyki a RUP (3)

Komponent: Nietrywialny fragment software’u (np. moduł, pakiet czy podsystem), który wykonuje jasno sformułowane zadania i jest dobrze wyizolowany z otoczenia dzięki wyraźnie określonym granicom. Komponent stanowi realizację elementu modelu logicznego.

 Komponenty mogą być stopniowo (dzięki iteracyjnemu podejściu), niezależnie rozwijane i stopniowo integrowane - “stary” pomysł bazujący na pojęciach: modularność i hermetyzacja (obiektowość idzie trochę dalej).

 Niektóre z komponentów mogą być przekształcone w aktywa ponownego użycia. Takie komponenty powinny obejmować większy fragment oprogramowania niż np. biblioteka funkcji. Aktywa ponownego użycia mogą znaleźć zastosowanie także w innych projektach w obrębie danej organizacji, dzięki czemu tworzenie ich może mieć wpływ na wzrost produktywności, a przez to na poprawę jakości produktów organizacji jako całości.

 CORBA, ActiveX, JavaBeans: co budować, co wykorzystać, co kupić?

Dwa ostatnie punkty przesuwają ciężar budowy systemów z programowania

na “składanie z komponentów”.

(11)

Najlepsze praktyki a RUP (4)

 Wizualne modelowanie: modelowanie a UML

 UML język z notacją graficzną do specyfikowania, wizualizowania i dokumentowania artefaktów wytwarzanych w trakcie procesu projektowego.

 UML nie jest metodyką, tzn. wspomaga modelowanie, ale nie narzuca reguł tworzenia systemu.

 Systematyczna weryfikacja jakości: jakość procesów i produktu

 RUP nie wyróżnia grupy członków zespołu projektowego odpowiedzialnych za jakość produktu, przeciwnie za ostateczną jakość produktu odpowiedzialny jest każdy członek zespołu.

 Jakość produktu dotyczy wszystkich artefaktów, które produkt obejmuje.

 Jakość procesów zależy od tego w jakim stopniu pomiary i kryteria jakości dla artefaktów wytwarzanych “w trakcie” (np. plan. iteracji, plan testów, realizacja use-case, model, itp.) są rzeczywiście wykorzystywane.

 RUP poświęca wiele uwagi systematycznej weryfikacji jakości.

(12)

Najlepsze praktyki a RUP (5)

 Konfiguracja i zarządzanie zmianami

W trakcie procesu projektowego, a szczególnie procesu opartego o podejście iteracyjne wiele produktów podlega modyfikacji. RUP wspomaga zarządzanie zmianami dzięki umożliwieniu śledzenia zmian w wymaganiach, projekcie implementacji i samej implementacji. Są zdefiniowane aktywności (wraz z odpowiednimi artefaktami) umożliwiające śledzenie defektów, nieporozumień czy uzgodnień.

 Inne własności RUP

 Rozwijanie oprogramowania w oparciu o przypadki użycia.

 Możliwość wykorzystania RUP jako wzorca (szablonu), który może być rozszerzany i przystosowywany do własnych potrzeb (konfiguracja procesu). Wszystkie elementy procesu: artefakty, aktywności. przepływy prac, wytyczne, szablony mogą być modyfikowane.

 Istnienie narzędzi, które wspierają tworzenie i zarządzanie artefaktami

wytwarzanymi w trakcie procesu projektowego.

(13)

Inne własności RUP

 Rozwijanie oprogramowania w oparciu o przypadki użycia

 Przypadki użycia (nazywane czasami scenariuszami czy wątkami (thread)) tworzą połączenie między zbiorem wymagań a innymi artefaktami wytwarzanymi w procesie projektowym, takimi jak np. projekt implementacji, kod czy testy. Ta własność powoduje, że są powszechnie wykorzystywane, choć nie są elementem koniecznym w obiektowym podejściu do tworzenia oprogramowania.

 RUP wspiera rozwijanie oprogramowania w oparciu o przypadki użycia, co oznacza, że właśnie przypadki użycia stanowią podstawę dla dalszych etapów projektowych. Przypadki użycia grają główną rolę w przepływach prac, takich jak: wymagania, projektowanie, testowanie czy zarządzanie projektem.

 Konfiguracja procesu

RUP może być z powodzeniem wykorzystany w postaci “as is” dla

małych i średnich organizacji, szczególnie dla tych, które nie rozwinęły

własnego procesu.

(14)

Podsumowanie

 RUP przykrywa całość cyklu życiowego SI.

 RUP wykorzystuje najnowsze trendy i technologie: obiektowe podejście, architektura oparta o komponenty, modelowanie wizualne z UML, podejście iteracyjne, itd.

 RUP jest systematycznie rozwijany i ulepszany (nie jest produktem zamrożonym”).

 RUP posiada “solidną” architekturę, która może być przystosowana do konkretnych potrzeb użytkownika.

 RUP wspiera rozwój oprogramowania w oparciu o sześć najlepszych praktyk: iteracyjny rozwój, zarządzanie wymaganiami, architektura oparta o komponenty, wizualne modelowanie, systematyczna weryfikacja jakości i zarządzanie zmianami.

 RUP posiada całą paletę wspierających narzędzi.

Cytaty

Powiązane dokumenty

Plan iteracji można traktować jak wystąpienie procesu dla danej iteracji, z wyborem aktywności, które będą wykonywane w trakcie iteracji. Wystąpienie procesu

 Jeśli proces sekwencyjny sprawdza się zarówno dla małych projektów, jak i dla tych z niewielką liczbą ryzyk, dlaczego nie realizować dużych projektów podzieliwszy

Reprezentacja: kto korzysta z architektury Reprezentacja: perspektywy architektoniczne Model a perspektywa architektoniczna.. Artefakty odnoszące się

Jest to zgodne z regułą obowiązującą przy projektowaniu: dane zachowanie systemu jest realizowane przez jeden podzbiór obiektów, niezależnie od tego, który

Plan następnej iteracji może być przyczyną zmiany Planu rozwoju oprogramowania, np.: gdy zmienia się allokacja funkcjonalności lub przypadek biznesowy (ulegają zmianie

(4) Generyczny model biznesowy: Jeśli budowany jest system, który będzie wykorzystywany przez kilka organizacji (np. system wspierający sprzedaż czy rozliczenia rachunkowe) może

 Dokument wizji zawiera zbiór potrzeb uczestników projektu i zbiór własności systemu wyspecyfikowanych na wysokim poziomie abstrakcji..  Pierwotne

Projektuj komponenty: Składa się z aktywności wykonywanych przez projektanta (projektuj przypadki użycia, projektuj klasy, projektuj podsystemy), i przez recenzenta (związane