Wykład 3Statyczna struktura RUP Rational Unified Process Studia Podyplomowe IT w Biznesie

(1)

Studia Podyplomowe IT w Biznesie

Rational Unified Process

Wykład 3

Statyczna struktura RUP

Wykładowca:

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

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

Warszawa

(2)

Zagadnienia

Elementy składowe procesu Pracownicy

Aktywności Artefakty

Przepływy prac

Dodatkowe elementy procesu

Prezentowany materiał został przygotowany w oparciu o publikację: Philippe Kruchten, The Rational Unified Process An Introduction, Addison-Wesley, 1999.

(3)

Elementy składowe procesu

Struktura RUP jest budowana z czterech głównych elementów składowych:

 pracownicy (w RUP2001 “pracowników” przemianowano na “role” ): kto,

 aktywności: jak,

 artefakty: co,

 przepływy prac: kiedy.

projektant analiza use-case projektowanie use-case aktywności

realizacja use-case artefakt

jest odpowiedzialny za pracownik

(4)

Pracownicy (1)

 Pracownik reprezentuje albo pojedynczą osobę, albo grupę osób pracujących razem jako zespół. Pracownik nie reprezentuje konkretnej osoby czy zespołu, odzwierciedla raczej funkcję związaną z pewnymi obowiązkami (odpowiedzialnościami) i w tym sensie nazwa “rola” wydaje się być bardziej odpowiednia. Konkretna osoba może pełnić wiele ról. Mapowanie ról (pracowników) na konkretne osoby należy do obowiązków kierownika projektu i wykonywane jest w trakcie planowania obsady projektu.

 Każdy pracownik jest skojarzony z pewnym zbiorem wzajemnie powiązanych aktywności, które ma do wykonania i za które jest odpowiedzialny. W najlepszym przypadku z każdą aktywnością powinna być skojarzona dokładnie jedna osoba.

 Odpowiedzialność pracownika jest zwykle wyrażana w terminach artefaktów, które tworzy, modyfikuje czy nadzoruje.

Przykłady pracowników:

 Analityk: Odpowiada za określenie wymagań. Buduje model use-case specyfikując funkcjonalność i ograniczenia nakładane na oprogramowanie.

(5)

Pracownicy (2)

 Projektant: specyfikuje odpowiedzialności, operacje, atrybuty i związki jednej lub kilku klas, a następnie dopasowuje projekt klas(y) do środowiska implementacji.

 Projektant testów: odpowiada za planowanie (plan testów), model testów, implementację i ewaluację pokrycia testów, wyników i efektywności.

Jan

Piotr Alicja Paweł Maria

Zasoby Pracownik Aktywności

Projektant Autor use-case Projektant use-case Recenzent use-case Architekt

Projektuj (obiektowo) Uszczegółów use-case Projektuj use-case Zrób przegląd use-case Analizuj architekturę Projektuj architekturę

(6)

Aktywności (1)

 Aktywność specyfikuje jednostkową pracę, którą pracownik ma do wykonania i która ma być uwieczniona rezultatem “znaczącym” w kontekście projektu. Każda aktywność musi mieć jasno określony cel.

 Rozmiar aktywności jest określany za pomocą czasu potrzebnego na jej wykonanie: zazwyczaj kilka godzin do kilku dni.

 Aktywność z reguły związana jest z jednym pracownikiem i pracą nad jednym lub niewielką liczbą artefaktów.

 Aktywność może stanowić element ponownego użycia dla procesów planowania i rozwoju.

 Aktywność związana z danym artefaktem może być wielokrotnie powtarzana, szczególnie gdy przechodzi się do kolejnych iteracji w procesie rozszerzania i udoskonalania produktu.

 Powtarzane aktywności mogą być wykonywane przez tego samego pracownika, ale niekoniecznie przez tą samą osobę.

(7)

Aktywności (2)

 W podejściu obiektowym, pracownik jest traktowany jako aktywny obiekt a aktywności jako operacje wykonywane na tym obiekcie.

Przykłady aktywności:

 Planuj iterację: Wykonywane przez pracownika Kierownik projektu.

 Znajdź przypadki użycia: Wykonywane przez pracownika Analityk.

 Zrób przegląd projektu: Wykonywane przez pracownika Recenzent projektu.

 Przeprowadź test wydajnościowy: Wykonywane przez pracownika Tester wydajności.

 Nazwa aktywności powinna odzwierciedlać jej podstawowy cel.

Kroki (etapy) aktywności

Aktywności są dzielone na kolejne kroki, które przynależą do trzech podstawowych rodzajów: (1) “myślenie”, (2) wykonywanie i (3) ocenianie rezultatów (nie zawsze wszystkie kroki są wykonywane).

(8)

Aktywności (3)

(1) Pracownik podejmuje wysiłki w celu zrozumienia natury zadania, bada artefakty wejściowe i stara się określić artefakty wyjściowe.

(2) Pracownik tworzy lub modyfikuje artefakty.

(3) Pracownik szacuje wyniki - ocenia artefakty wyjściowe w oparciu o określone kryteria, np. kompletność, solidność (robustness), zrozumiałość.

Przykładowe kroki dla aktywności: Znajdź przypadki użycia.

1-3 etap myślenia, 4-6 etap wykonywania, 7 - etap oceniania rezultatów 1. Znajdź aktorów

2. Znajdź przypadki użycia

3. Opisz interakcje aktorów z przypadkami użycia 4. “Spakuj” aktorów i przypadki użycia

5. Prezentuj model przypadków użycia (w oparciu o zbudowane diagramy) 6. Zrób przegląd modelu

7. Oszacuj wyniki

(9)

Artefakty (1)

 Artefakt: Termin wprowadzony przez Rational Unified Process (inne procesy: “produkt pracy”, “jednostka pracy”) oznaczający produkt wytwarzany, modyfikowany, nadzorowany bądź używany w trakcie którejś z aktywności realizowanych w procesie wytwarzania produktu finalnego.

Produkt finalny obejmuje pewien podzbiór artefaktów - tych, które zostaną dostarczone do rąk klienta. W podejściu obiektowym, artefakty są traktowane jako parametry operacji (aktywności) wykonywanych na obiektach aktywnych, za jakie uważa się tu pracowników.

Przykłady artefaktów:

 Projekt implementacji (model logiczny): Rational Rose

 Plan projektu: Microsoft Project

 Defekty: ClearQuest

 Wymagania: Requisite Pro

 RUP promuje ideę: “każda porcja informacji związana jest z konkretną, odpowiedzialną za nią osobą”, co oznacza przyporządkowanie artefaktów do osób, w roli ich “właścicieli”. Inne osoby mogą wykorzystywać artefakt, ale aktualizacja zawsze wymaga zgody właściciela.

(10)

Artefakty (2)

 Artefakty stanowią przedmiot zarządzania wersjami i zarządzania konfiguracją.

 Artefakty mogą przyjmować różną postać, np.:

 model, np. model use-case czy też model pojęciowy czy logiczny,

 element modelu, np. przypadek użycia czy klasa,

 dokument, np. przypadek biznesowy czy dokument specyfikacji architektury,

 kod źródłowy,

 kod wynikowy.

 Artefakty mogą być złożone z innych artefaktów (zagnieżdżane), np.

model pojęciowy składa się z wielu klas.

 RUP stara się zniechęcać do takiego sposobu prowadzenia projektu, gdzie głównymi artefaktami są dokumenty, a już w szczególności dokumenty papierowe. Najbardziej pragmatycznym i efektywnym podejściem do zarządzania artefaktami jest przechowywanie ich w środowisku, w którym zostały wytworzone.

(11)

Artefakty (3)

 Raport: Specjalny rodzaj artefaktu, wykorzystywany w aktywnościach związanych z przeglądami; dotyczy informacji o modelu (lub jego elementach) zebranych za pośrednictwem narzędzia, w którym zbudowano model; w przeciwieństwie do “zwykłych” artefaktów nie podlega zarządzaniu wersjami (generowany na życzenie w dowolnym momencie).

 Zbiory artefaktów: Artefakty w RUP zostały pogrupowane w pięć kategorii:

(1) związane z biznesem i zarządzaniem projektem (Z), (2) związane z wymaganiami (W),

(3) związane z projektowaniem (P), (4) związane z implementacją (I), (5) związane z wdrażaniem (Wd).

(1) Artefakty związane z biznesem i zarządzaniem projektem:

 artefakty związane z planowaniem projektu (SDP Software Development Plan), przypadki biznesowe, wystąpienie procesu dla danego projektu, itd.

(12)

Artefakty (4)

(2) Artefakty związane z definiowaniem tworzonego oprogramowania (z wymaganiami):

 dokument wizji,

 wymagania w postaci potrzeb uczestników projektu, gdzie przez uczestnika projektu rozumie się zarówno klienta, użytkownika końcowego, jak i członka zespołu projektowego,

 model przypadków użycia wraz z uzupełniającą specyfikacją,

 model biznesowy, o ile jest niezbędny dla zrozumienia procesów biznesowych wspieranych przez oprogramowanie.

 artefakty operacyjne, np. artefakty związane z wypuszczaniem produktu czy ewaluacją statusu, dokumenty wdrożeniowe, itd.

(3) Artefakty związane z projektowaniem w postaci:

 modelu projektowego,

 opisu architektury,

 modelu testów.

(13)

Artefakty (5)

(4) Artefakty związane z implementowaniem:

 kod źródłowy,

 kod wynikowy,

 pliki z danymi i pliki potrzebne do ich generowania.

(5) Artefakty związane z wdrażaniem:

 materiał instalacyjny,

 dokumentacja użytkownika,

 materiał treningowy.

Początkowa Opracowywanie Konstrukcja Wdrożenie

Z W P I Wd Z W P I Wd Z W P I Wd Z W P I Wd

(14)

Główne artefakty w RUP

Przypadek biznesowy

Wizja Lista ryzyk

Wymagania uczestnika projektu

Słownik Plan rozwoju

oprogramowania Specyfikacja

uzupełniająca

Model use-case

Specyfikacja wymagań na oprogramowanie

Dokument architektury

oprogramowania Plan testów Plan

rozmieszczenia

Produkt Model fizyczny

Model logiczny Model pojęciowy

(15)

Przepływy prac (1)

 Przepływ prac: Sekwencja aktywności, której efektem jest wytworzenie

“obserwowalnej (znaczącej) wartości”. Zgodnie z notacją UML, przepływ prac może być opisany za pośrednictwem digramów aktywności (najbardziej naturalna forma), diagramów sekwencji czy diagramów współpracy.

 Nie zawsze jest możliwe (i w praktyce nie zawsze potrzebne) oznaczanie wszelkich możliwych zależności między aktywnościami. Przepływy prac dotyczą ludzi i nie muszą być interpretowane tak dosłownie, jak programy komputerowe.

 RUP wyróżnia trzy podstawowe kategorie elementów wykorzystywanych przy opisie przepływów prac:

 przepływy podstawowe,

 szczegóły (detale) przepływów,

 plany iteracji.

Przepływy podstawowe

RUP wyróżnia dziewięć podstawowych przepływów prac, podzielonych na dwie grupy: przepływy prac związane z czynnościami inżynierskimi oraz tzw. przepływy “wspierające”.

(16)

 Przepływy podstawowe związane z czynnościami inżynierskimi: Modelowanie biznesowe

 Wymagania

 Analiza i projektowanie

 Implementacja

 Testowanie

 Wdrażanie

 Przepływy wspierające :

 Konfiguracja i zarządzanie zmianami

 Zarządzanie projektem

 Środowisko

Nazwy pierwszych sześciu z dziewięciu podstawowych przepływów prac mogą nasuwać skojarzenia z tradycyjnym modelem wodospadowym, nie mniej jednak występują pewne różnice między modelem wodospadowym a podejściem iteracyjnym; w podejściu iteracyjnym przepływy prac są wielokrotnie - choć z różnym naciskiem i różną intensywnością - powtarzane w kolejnych iteracjach.

(17)

Fazy

Początkowa Opracowywanie Modelowanie biznesowe

Wymagania Analiza i projektowanie Implementacja Testowanie

Konfiguracja i zarządzanie wymaganiami

Konstrukcja Wdrożenie

Zarządzanie projektem Środowisko

Przepływy prac

Wdrożenie

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

(18)

 Detale przepływów: Każdy z przepływów podstawowych składa się szeregu ściśle powiązanych aktywności. Dla ich bardziej szczegółowego opisu - w RUP - wykorzystywane są tzw. “detale przepływów”. Z pomocą detali można określać, np.: czy aktywności są wykonywane jednocześnie czy cyklicznie (w ramach przpływu), lub że są wykonywane przez grupę osób biorących udział w workshopie. Ponadto, detale służą zarówno specyfikowaniu wejściowo/wyjściowych artefaktów dla aktywności jak i przebiegu wymiany informacji między aktywnościami za pośrednictwem artefaktów.

 Plany iteracji: Stanowią inny rodzaj środków do opisu procesu, opisu z perspektywy tego, co się dzieje w typowej iteracji. 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 można utworzyć na wiele sposobów, innymi słowy można utworzyć wiele wystąpień procesu. RUP zawiera predefiniowane opisy dla kilku typowych planów iteracji, głównie dla celów nauczania.

(19)

Dodatkowe elementy procesu (1)

 Pracownicy, artefakty i aktywności (zorganizowane w przepływy prac) budują “szkielet” struktury RUP. Elementy dodatkowe z kolei, mają ułatwić zrozumienie i wspomóc wykorzystywanie procesu - szczególnie użyteczne dla osób niedoświadczonych:

 wytyczne (zalecenia),

 szablony,

 nauczyciele narzędzi (doradcy narzędziowi),

 idee (iteracje, fazy, ryzyka, itp.).

Wytyczne, zalecenia: Są przypisane do aktywności, kroków i artefaktów.

Stanowią zbiór reguł, rekomendacji i heurystyk wspierających użytkownika w procesie realizacji aktywności (kroku). Z kolei, wytyczne przypisane do artefaktów zawierają wskazówki zarówno jak je tworzyć (z naciskiem na pewne specyficzne własności, np.: co cechuje dobry przypadek użycia, dobrze zaprojektowaną klasę czy dobry test + określenie listy typowych ryzyk + dobre przykłady) oraz jak je rozwijać i jak wykorzystywać. Wytyczne mogą być związane z modelowaniem, z językiem programowania (np. standard dla nazewnictwa) czy z interfejsem użytkownika.

(20)

Ponadto, wytyczne opisują specyficzne techniki wykorzystywane do tworzenia pewnych artefaktów, czy też transformacji artefaktów oraz służą pomocą w szacowaniu jakości artefaktów czy dokonywaniu przeglądów aktywności dostarczając czegoś w rodzaju “checklist’y” - listy rzeczy, które trzeba sprawdzić.

Szablony: RUP posiada szablony dla modeli, prototypów, itd. Szablony są przechowywane w tym środowisku, w którym zostały wytworzone:

 Microsoft Word: szablony dla dokumentów i raportów,

 SoDa: szablony dla Microsft Word i FrameMaker w celu ekstrakcji informacji z narzędzi takich jak Rational Rose, RequisitePro czy TeamTest,

 Microsoft FrontPage: szablony dla różnych elementów procesu,

 Microsoft Project: szablony dla planów projektów.

RUP - ze strukturą jak powyżej - to rodzaj ramy, którą każda organizacja może skonfigurować tak, by dopasować do swoich specyficznych potrzeb.

(21)

Nauczyciele narzędzi: Stanowią krok dalej niż wytyczne. Specyfikują, jak wykonywać kolejne kroki (aktywności) posługując się konkretnym narzędziem.

RUP dostarcza nauczycieli do narzędzi takich, jak: Rational Rose, RequisitePro, ClearCase, ClearQuest i TestStudio oraz pozwala na dołączanie własnych.

projektant znajdź klasy rozdziel zachowania aktywności

realizacja use-case

artefakt jest odpowiedzialny za pracownik

Szablon use-case Wytyczne dla

projektowania

Nauczyciel Rational Rose