《丧尸围城》绿色度测评报告

百度 叙利亚方面一直否认它在建设核反应堆。

Rational Unified Process (RUP) – proces iteracyjnego wytwarzania oprogramowania opracowany przez firm? Rational Software Corporation (przedsi?biorstwo zosta?o przej?te przez IBM).

Proces RUP nie jest pojedynczym, ?ci?le okre?lonym procesem, ale raczej szablonem procesu. Zosta? on zaprojektowany w celu przystosowania do charakteru konkretnej organizacji (przedsi?biorstwa), konkretnego zespo?u projektowego lub nawet charakteru konkretnego projektu. Z szablonu RUP mo?na wybra? elementy w zale?no?ci od konkretnych potrzeb.

Rational Unified Process (RUP) to tak?e nazwa oprogramowania, opracowanego przez Rational Software (obecnie dost?pnego w IBM). Produkt ten zawiera hipertekstow? baz? wiedzy z przyk?adowymi artefaktami oraz szczegó?owymi opisami wielu typów czynno?ci. Process RUP definiowany jest tak?e w produkcie Rational Method Composer (RMC), który pozwala na tworzenie spersonalizowanych wersji RUP.

Obecnie firma IBM sponsoruje projekt Eclipse Process Framework, który w wersji otwartej zawiera definicj? procesu OpenUP/Basic – lekk? wersj? procesu Open Unified Process. Na aplikacji Eclipse Process Framework b?dzie oparty te? komercyjny produkt Rational Method Composer.

Historia

Proces Rational si?ga swoimi korzeniami do oryginalnego modelu spiralnego Barry’ego Boehma – jeden z g?ównych autorów RUP, Ken Hartman, prowadzi? razem z Boehmem badania. Podej?cie Rational (Rational Approach) zosta?o opracowane przez Rational Software w latach osiemdziesi?tych i dziewi??dziesi?tych.

W roku 1995 Rational przej??o szwedzk? firm? Objectory AB. Zunifikowany proces Rational (Rational Unified Process) by? rezultatem po??czenia podej?cia Rational oraz metodyki Objectory zdefiniowanej przez jej za?o?yciela Ivara Jacobsona. Pocz?tkowo powsta? proces nazwany Rational Objectory Process, który by? podej?ciem firmy Objectory przystosowanym do narz?dzia Rose. Kiedy po??czenie obydwu metodyk zosta?o ostatecznie osi?gni?te, zmieniono nazw? na obecn?. Pierwsza wersja RUP 5.0 opublikowana zosta?a w 1998 roku. G?ównym architektem by? Philippe Kruchten.

Budowa

Autorzy procesu skupili si? na diagnozowaniu charakterystyk projektów, które zakończy?y si? fiaskiem. Post?puj?c w ten sposób, próbowali pozna? przyczyny owych niepowodzeń. Przygl?dali si? równie? ówcze?nie istniej?cym procesom in?ynierii oprogramowania i sposobom, w jaki rozwi?zywa?y one problemy.

Lista najcz?stszych b??dów zawiera?a nast?puj?ce rzeczy:

• Zarz?dzanie wymaganiami ad hoc (najcz??ciej brak zarz?dzania nimi)
• Niejednoznaczna, nieprecyzyjna komunikacja
• Architektura oprogramowania nieodporna na obci??enia (ang. Brittle architecture)
• Zbytnia, niepotrzebna z?o?ono?? oprogramowania
• Niewykryte niespójno?ci w wymaganiach, projekcie oraz implementacji
• Brak lub niewystarczaj?ce testowanie
• Subiektywna ocena post?pu projektu
• Brak zarz?dzania ryzykiem
• Brak automatyzacji prowadzenia projektu

Niepowodzenie projektu by?o spowodowane kombinacj? wielu czynników, w ka?dym projekcie w specyficzny sposób. Rezultatem badań firmy Rational by?o opracowanie zbioru dobrych praktyk, które nazwane zosta?y w?a?nie Rational Unified Process.

Proces RUP zosta? opracowany z u?yciem tych samych technik, których zespó? Rational u?ywa? do modelowania systemów – j?zyka UML. J?zyk UML powstawa? równolegle z RUP (równie? jako po??czenie do?wiadczenia w modelowaniu firm Objectory i Rational).

Podstawy i najlepsze praktyki

RUP bazuje na zbiorze zasad in?ynierii programowania oraz najlepszych praktykach, na przyk?ad:

1. iteracyjnym wytwarzaniu oprogramowania (Iterative Development)
2. zarz?dzaniu wymaganiami (Requirement Management)
3. u?ywaniu architektury bazuj?cej na komponentach (Component-based architecture)
4. graficznym projektowaniu oprogramowania
5. kontroli jako?ci oprogramowania (Quality Assurance)
6. procesu kontroli zmian w oprogramowaniu (Change Management)

Iteracyjne wytwarzanie oprogramowania

Wymagania podczas procesu wytwarzania oprogramowania ulegaj? cz?stym zmianom, z powodu ograniczeń architektury, zmiany potrzeb u?ytkownika lub lepszego zrozumienia problemu. Wytwarzanie oprogramowania w kolejnych iteracjach, pozwala skupi? si? w pierwszej kolejno?ci na obszarach najbardziej ryzykownych (np. najmniej rozpoznanych). W idealnym przypadku ka?da iteracja kończy si? stworzeniem wykonywalnego artefaktu – pomaga to zredukowa? ryzyko w projekcie, otrzymujemy szybciej opinie od odbiorców oprogramowania a programistom pozwalamy skupi? si? na w??szej dziedzinie.

RUP u?ywa podej?cia iteracyjnego i przyrostowego z nast?puj?cych powodów:

• Integracja oprogramowania robiona krok po kroku podczas wytwarzania oprogramowania, ograniczaj?c go do mniejszej liczby elementów
• Integracja jest prostsza i mniej kosztowna
• Sk?adowe oprogramowania s? projektowane oddzielnie i ?atwiej u?y? ich ponownie
• ?atwiej wykrywa? zmiany wymagań i ?atwiej nimi zarz?dza?
• Zagro?enia identyfikowane i atakowane s? wcze?nie poniewa? ka?da iteracja pozwala wykry? kolejne zagro?enia
• W iteracjach ulepszana jest architektura oprogramowania

Projekt wykorzystuj?cy model iteracyjny b?dzie posiada? jeden g?ówny plan faz, a zarazem wiele planów iteracji. W??czenie si? udzia?owców (stakeholders) jest cz?sto praktykowane przy ka?dym kamieniu milowym. W tej sytuacji, kamienie milowe stanowi? zach?t? dla udzia?owców oraz dostarczaj? informacj? dotycz?c? spe?nienia wymagań przez system oraz gotowo?ci organizacji do jego wdro?enia.

Zarz?dzanie wymaganiami

Zarz?dzanie wymaganiami w RUP jest skupione na zaspokojeniu oczekiwań u?ytkowników końcowych systemu poprzez identyfikacj? i specyfikacj? ich potrzeb oraz wykrywanie zmiany tych wymagań. Zalety zarz?dzania wymaganiami:

• Poprawnie zidentyfikowane wymagania tworz? prawid?owy produkt, potrzeby u?ytkownika s? zaspokojone.
• Tworzymy istotn? dla u?ytkowników funkcjonalno??, redukuj?c pó?niejsze koszty dobudowywania zapomnianej (niezidentyfikowanej podczas tworzenia) funkcjonalno?ci.

RUP sugeruje, ?e zarz?dzanie wymaganiami sk?ada si? z nast?puj?cych czynno?ci:

Analiza problemu – uzgodnienie problemu i stworzenie miar, które dowiod? jego istotno?ci dla klienta.

Zrozumienie potrzeb udzia?owców (stakeholders) (interesariuszy), s? to odbiorcy i u?ytkownicy oprogramowania na ró?nych szczeblach w organizacji, w innych metodykach zarz?dzania projektami nazywa si? ich interesariuszami) – konsultacja problemu i jego warto?ci z g?ównymi udzia?owcami (stakeholders) i rozpoznanie w jaki sposób koncepcja rozwi?zania zaspokaja ich potrzeby.

Definicja systemu – tworzenie projektu funkcjonalno?ci na podstawie potrzeb u?ytkowników, identyfikacja przypadków u?ycia – które prezentuj? ogólne wymagania (high-level requirements) i u?yteczno?? modelu systemu.

Zarz?dzanie zakresem systemu (Scope Management) – modyfikowanie zakresu prac nad systemem bazuj?c na analizie wymagań, wybór kolejno?ci realizacji (atakowania) przypadków u?ycia.

Zaw??anie definicji systemu – uszczegó?awianie scenariuszy przypadków u?ycia razem z u?ytkownikami systemu w celu stworzenia dok?adnej specyfikacji wymagań (ang. Software Requirements Specification – SRS), która mo?e s?u?y? (i na ogó? s?u?y) jako umowa pomi?dzy wykonawc? systemu a klientem. Na podstawie dokumentu SRS tworzony jest projekt systemu oraz scenariusze testów.

Zarz?dzanie zmianami wymagań – zarz?dzanie zmianami wymagań lub nowozidentyfikowanymi wymaganiami w czasie trwania projektu.

Architektura bazuj?ca na komponentach

U?ycie architektury bazuj?cej na komponentach pozwala na stworzenie systemu, który jest ?atwo rozszerzalny, intuicyjnie zrozumia?y i wspomaga reu?ywalno??. Komponentem nazywamy zbiór powi?zanych obiektów (w sensie programowania obiektowego).

Architektura oprogramowania zyskuje na znaczeniu w miar? jak systemy informatyczne staj? si? coraz wi?ksze i bardziej z?o?one. RUP skupia si? na stworzeniu prostej architektury w pocz?tkowych iteracjach. Staje si? ona prototypem dla pierwszej fazy implementacji (development). Ewoluuje ona w ka?dej iteracji zbli?aj?c si? do architektury finalnej. RUP zak?ada regu?y i ograniczenia projektowe w celu uchwycenia regu? architektury. Poprzez iteracyjne wytwarzanie oprogramowania zyskujemy mo?liwo?? stopniowej identyfikacji komponentów, które mog? by? w dalszej cz??ci: zakupione, zbudowane, lub u?yte ponownie. Komponenty s? cz?sto budowane na bazie istniej?cych technologii typu CORBA, COM, JEE.

Wizualne modelowanie oprogramowania

Abstrakcja projektowania od kodu i przedstawienie koncepcji za pomoc? bloków graficznych mo?e by? efektywnym sposobem aby pokaza? perspektyw? rozwi?zania. U?ywaj?c takiej reprezentacji, techniczni cz?onkowie zespo?u maj? mo?liwo?? wybrania najlepszego sposobu implementacji zbioru powi?zanej funkcjonalno?ci. Reprezentacja graficzna jest tak?e produktem po?rednim pomi?dzy analiz? procesu biznesowego a implementacj?. Model w tym kontek?cie jest form? wizualizacji oraz uproszczeniem bardziej skomplikowanego projektu. RUP specyfikuje wymagane modele i opisuje dlaczego s? wymagane.

Kontrola i weryfikacja jako?ci oprogramowania

Ocena jako?ci jest najcz?stszym s?abym punktem projektów programistycznych poniewa? jest cz?sto planowana po fakcie budowy systemu i czasami obs?ugiwana przez inny zespó?. RUP pomaga w planowaniu kontroli jako?ci i jej ocenie poprzez wbudowanie jej w ca?y proces i zaanga?owanie w ni? wszystkich cz?onków zespo?u. Nie ma pracowników przypisanych tylko do jako?ci – RUP zak?ada, ?e ka?dy cz?onek zespo?u jest odpowiedzialny za jako?? w ci?gu ca?ego procesu. Proces koncentruje si? na spe?nieniu wymaganego poziomu jako?ci i zapewnia mechanizmy (workflows) do pomiaru tego poziomu.

Zarz?dzanie zmianami w oprogramowaniu

We wszystkich projektach programistycznych pojawiaj? si? z czasem zmiany i s? one nieuniknione. RUP definiuje metody ?ledzenia, ewidencji i kontroli zmian. Zdefiniowane s? tak?e tzw. secure workspaces (bezpieczne przestrzenie robocze), które pozwalaj? na zagwarantowanie, ?e zmiany w innych systemach nie wp?yn? na system tworzony. Koncepcja ta jest ?ci?le powi?zana z tworzeniem architektury zorientowanej komponentowo.

Cykl ?ycia projektu

Cykl ?ycia w RUP bazuje na modelu spiralnym. RUP jest dost?pny jako struktura prowadzenia projektu, która mo?e by? personalizowana w celu przystosowania do specyficznych potrzeb projektowych. Cykl ?ycia w RUP uk?ada zadania w fazy i iteracje.

Projekt zosta? podzielony na cztery fazy:

• faza rozpocz?cia (Inception phase),
• faza opracowywania (Elaboration phase),
• faza konstrukcji (Construction phase),
• faza przekazania systemu (Transition phase).

Faza rozpocz?cia (Inception phase)

W fazie tej formu?owany jest problem – zagadnienie biznesowe (business case). Przy opracowaniu tego zagadnienia okre?la si? jego kontekst (business context); czynniki wp?ywaj?ce na jego powodzenie (success factors) – na przyk?ad spodziewany zwrot z inwestycji, zwi?kszenie udzia?u w rynku; oraz prognoz? finansow?. Dodatkowo uzupe?nia si? go o prosty model przypadków u?ycia, plan projektu, wst?pn? analiz? ryzyka oraz opis projektu (g?ówne wymagania, ograniczenia, g?ówna funkcjonalno??). Po stworzeniu powy?szych dokumentów projekt sprawdza si? wed?ug nast?puj?cych kryteriów:

• Zgoda u?ytkowników na oszacowany koszt/czas wykonania.
• Zrozumienie wymagań poprzez ocen? jako?ci g?ównych przypadków u?ycia.
• Wiarygodno?? szacowanych kosztów, priorytetów, ryzyka i planu procesu wytwarzania.
• Rozmiar stworzonego prototypu architektury.
• Wydatki rzeczywiste wzgl?dem wydatków planowanych.

Je?eli wst?pny projekt nie osi?gnie kamienia milowego (ang. milestone), nazywanego Lifecycle Objective Milestone, mo?e by? albo zakończony, albo faza ta mo?e zosta? jeszcze raz powtórzona (w celu ulepszenia projektu wst?pnego).

Faza opracowania (Elaboration phase)

W tej fazie projekt systemu nabiera kszta?tów. Przeprowadzona jest analiza dziedziny zagadnienia (ang. Domain Analysis – nazywana te? w literaturze polskiej Analiz?/Modelem Domeny) i budowana podstawowa architektura systemu.

Zakończenie tej fazy wi??e si? z osi?gni?ciem kamienia milowego Lifecycle Architecture Milestone poprzez spe?nienie kryteriów:

• Stworzony zosta? model przypadków u?ycia – zidentyfikowani zostali aktorzy i wi?kszo?? przypadków. Model jest kompletny w 80%.
• Zosta?a opracowana architektura systemu.
• Architektura ta pozwala realizowa? g?ówne przypadki u?ycia.
• Sprawdzona zosta?a zgodno?? zagadnienia biznesowego oraz listy ryzyk.
• Stworzony zosta? plan prac dla ca?ego projektu.

Je?eli projekt nie mo?e przej?? tej fazy, ci?gle mamy czas na jego zaniechanie, lub ponowne opracowanie. Przechodz?c do nast?pnej fazy przechodzimy w obszar wi?kszego ryzyka, w którym zmiana (np. wymagań) jest du?o trudniejsza i znacz?ca.

Faza konstrukcji (Construction phase)

W fazie tej g?ówny nacisk po?o?ony jest na budow? komponentów i innych funkcjonalno?ci opracowywanego systemu. W tej fazie odbywa si? wi?kszo?? prac programistycznych. W wi?kszych projektach mo?e by? wiele iteracji konstrukcji, w celu podzielenia dziedziny przypadków u?ycia na mniejsze, zarz?dzalne poddziedziny. Pozwala to tak?e na szybsze przekazywanie cz??ci prac (lub prototypów).

W tej fazie tworzona jest pierwsza wersja oprogramowania do wgl?du u?ytkowników zewn?trznych. Zakończenie fazy wi??e si? z osi?gni?ciem Initial Operational Capability Milestone.

Faza przekazania systemu (Transition phase)

W tej fazie produkt przekazywany jest od zespo?u programistycznego do u?ytkowników końcowych (potocznie mówi?c: do produkcji). W tej fazie znajduj? si? takie czynno?ci jak: trening u?ytkowników końcowych i administratorów, testy akceptacyjne (testy beta). Sprawdzana jest zgodno?? produktu z miarami jako?ci okre?lonymi w pierwszej fazie.

Spe?nienie celów jest to?same z osi?gni?ciem Product Release Milestone i zakończeniem cyklu wytwarzania oprogramowania.

Dyscypliny (Disciplines and workflows)

RUP bazuje na zbiorze klocków (building blocks, content elements). Opisuj? one, co ma zosta? stworzone, jakie umiej?tno?ci s? do tego wymagane oraz, krok po kroku, jak powinien wygl?da? proces wytwarzania.

G?ówne klocki:

• Rola (Roles) – Kto? – Rola definiuje zbiór wymaganych umiej?tno?ci, kompetencji i odpowiedzialno?ci.
• Produkt (Work Products) – Co? – Produkt reprezentuje wynik zadania oraz wszystkie dokumenty i modele utworzone w czasie procesu.
• Zadanie (Tasks) – Jak? – Zadanie opisuje jednostk? pracy przypisan? do roli.

W ramach ka?dej iteracji zadania podzielone s? na dziewi?? dyscyplin (disciplines):

Dyscypliny in?ynierskie (Engineering Disciplines):

• Modelowanie biznesowe (Business modeling)
• Wymagania (Requirements)
• Analiza i projekt (Analysis and design)
• Implementacja (Implementation)
• Testowanie (Test)
• Wdro?enie (Deployment)

Dyscypliny pomocnicze (Supporting Disciplines):

• Zarz?dzanie zmianami oraz konfiguracj? (Configuration and change management)
• Zarz?dzanie projektem (Project management)
• ?rodowisko (Environment)

Modelowanie biznesowe (dyscyplina)

Z biegiem czasu przedsi?biorstwa i inne organizacje staj? si? coraz bardziej zale?ne od systemów informatycznych. Wymusza to w sposób oczywisty na in?ynierach tworz?cych oprogramowanie wiedz?, w jaki sposób ich systemy wpasowuj? si? w procesy zachodz?ce w administracji i jakie jej wymogi adresuj?. Z kolei firmy inwestuj? na ogó? w systemy informatyczne na podstawie racjonalnych przes?anek – wtedy, kiedy widz? warto?? dodan? wynikaj?c? ze stworzenia takiego systemu.

Celem modelowania biznesowego jest przede wszystkim zapewnienie komunikacji i lepsze zrozumienie pomi?dzy biznesem (in?ynieria biznesowa) a IT (in?ynieria oprogramowania). Zrozumienie biznesu oznacza, ?e in?ynierowie oprogramowania musz? zrozumie? struktur? i dynamik? organizacji swojego klienta, jego bie??ce problemy i mo?liwe usprawnienia. Musz? tak?e zapewni? wspólne zrozumienie celów pomi?dzy klientami, u?ytkownikami końcowymi a programistami.

Modelowanie biznesowe t?umaczy w jaki sposób opisa? wizj? organizacji, w której b?dzie wdro?ony system i jak pó?niej u?y? jej do opisania procesów, ról i odpowiedzialno?ci w organizacji. Modelowanie biznesowe to fundamentalna dyscyplina w metodyce RUP. Zapewnia spójno?? i jasno?? w okre?laniu celów oraz ich spe?nienia.

Wymagania (dyscyplina)

Celem Wymagań jest opisanie tego, co system powinien robi?. Wymagania zbierane s? przez analityków, którzy odkrywaj? je, klasyfikuj? i dokumentuj?. Proces zbierania wymagań polega na dyskusji i uzgodnieniach pomi?dzy tworz?cymi system a klientem.

Analiza i projekt (dyscyplina)

Celem Analizy i projektu jest zobrazowanie sposobu w jaki b?dzie tworzony system w fazie implementacji. Ma to by? system, który:

• Zapewnia w specyficznym ?rodowisku realizacj? zadań i funkcji opisanych w przypadkach u?ycia.
• Spe?nia wszystkie swoje wymagania.
• Jest ?atwy do zmiany, gdy zmieni? si? wymagania funkcjonalne.

Analiza i projekt tworzy model projektowy i opcjonalnie model analityczny systemu. Model analityczny zapewnia abstrakcj? od kodu ?ród?owego – to znaczy, s?u?y on jako wytyczne do stworzenia tego kodu. Model projektowy sk?ada si? z klas zorganizowanych w pakiety i podsystemy z dobrze okre?lonymi interfejsami. S?u?y to wyodr?bnieniu komponentów w fazie implementacji. Zawiera tak?e opis, które obiekty klas wspó?pracuj? w celu realizacji przypadków u?ycia.

Implementacja (dyscyplina)

Celami implementacji s?:

• zdefiniowanie organizacji kodu systemu, w sensie podsystemów zorganizowanych w warstwy.
• stworzenie klas i obiektów w sensie komponentów (pliki ?ród?owe, binaria, pliki wykonywalne i inne)
• testowanie tworzonych komponentów jako jednostki (testami jednostkowymi).
• integracja wyników tworzonych przez poszczególne osoby lub zespo?y do pe?nego systemu.

Systemy realizowane s? poprzez implementacj? swoich komponentów. Proces opisuje w jaki sposób zapewni? reu?ywalno?? istniej?cych komponentów albo implementowa? nowe komponenty ze zdefiniowan? odpowiedzialno?ci? tworz?c system ?atwiejszy do utrzymania i zwi?kszaj?c reu?ywalno??.

Testowanie (dyscyplina)

Celami dyscypliny testowania s?:

• weryfikacja interakcji pomi?dzy obiektami.
• weryfikacja poprawnej integracji komponentów.
• sprawdzenie, czy wszystkie wymagania zosta?y zaimplementowane w sposób poprawny.
• identyfikacja i sprawdzenie, ?e defekty zosta?y usuni?te przed wdro?eniem oprogramowania.

Proces RUP proponuje podej?cie iteracyjne, które oznacza testowanie od pocz?tkowych faz projektu. Pozwala to na szybsze wykrywanie defektów i ograniczenie kosztów ich usuni?cia. Testy s? prowadzone w ramach wymiarów jako?ci: wiarygodno?ci, funkcjonalno?ci, osi?gów pojedynczych aplikacji oraz systemu (performance). RUP opisuje w jaki sposób testowa? w ka?dym z tych wymiarów w czasie trwania projektu.

Wdro?enie (dyscyplina)

Celem wdro?enia (deployment) jest udane wytwarzanie dystrybucji produktu i dostarczanie oprogramowania końcowym u?ytkownikom. Pokrywa ono szeroki zbiór czynno?ci w??czaj?c:

• Produkcja zewn?trznych dystrybucji oprogramowania
• Pakowanie oprogramowania
• Dystrybucja oprogramowania
• Instalacja oprogramowania
• Zapewnienie pomocy i wsparcia u?ytkownikom

Jakkolwiek czynno?ci wdro?enia s? skoncentrowane g?ównie na fazie przekazania (transition), wiele z nich musi by? w??czone we wcze?niejsze fazy w celu przygotowania do wdro?enia na końcu fazy budowy (construction). Procesy (workflows) Deployment and Environment w procesie RUP zawieraj? mniej szczegó?ów ni? inne procesy.

Zarz?dzanie zmian? i konfiguracj? (dyscyplina)

Dyscyplina zarz?dzania zmian? (change management) w RUP dotyka trzech obszarów:

• Zarz?dzania konfiguracj? (configuration management) – jest odpowiedzialne za systematyczne strukturalizowanie produktów. Artefakty takie jak dokumenty i modele musz? by? wersjonowane (version control) a zmiany musz? by? widoczne. W sk?ad zarz?dzania konfiguracj? wchodzi tak?e utrzymywanie rejestru zale?no?ci pomi?dzy artefaktami, tak, aby wszystkie powi?zane cz??ci by?y uaktualniane wraz ze zmianami.
• Zarz?dzanie zleceniami zmian (Change request management) – w czasie opracowywania oprogramowania istnieje wiele artefaktów z ró?nymi wersjami. Zarz?dzanie polega na trzymaniu rejestru propozycji lub zleceń zmian.
• Zarz?dzanie stanem i miarami (Status and measurement management) – zlecenia zmian (change requests) maj? stany takie jak nowy, zalogowany, zatwierdzony, przypisany i zakończony. Zlecenia zmian maj? tak?e atrybuty takie jak przyczyna (root cause) oraz natura (jak defekt lub rozszerzenie), priorytet itp. Te stany i atrybuty powinny by? przechowywane w bazie danych, tak aby umo?liwi? tworzenie u?ytecznych raportów na temat post?pów prac. Firma Rational posiada produkt, który umo?liwia utrzymywanie takiego rejestru ClearQuest. Czynno?? ta wi??e si? z procedurami, które trzeba wykonywa?.

Zarz?dzanie projektem (dyscyplina)

Planowanie projektu w RUP wyst?puje na dwóch poziomach – zgrubnym (coarse-grained) zwanym planem faz, który opisuje ca?y projekt oraz serii szczegó?owych planów iteracji, które opisuj? iteracje.

Ta dyscyplina skupia si? g?ównie na wa?nych aspektach iteracyjnego procesu wytwarzania oprogramowania. Nie próbuje obj?? natomiast wszystkich aspektów zarz?dzania projektami, na przyk?ad:

• zarz?dzania zespo?em: zatrudniania, szkoleń, opieki (coaching)
• zarz?dzania bud?etem: definiowania, alokowania itp.
• zarz?dzania umowami ze sprzedawcami i klientami

G?ówne obszary dyscypliny:

• zarz?dzanie ryzykiem
• planowanie projektu iteracyjnego, w ramach ca?ego cyklu i pojedynczych iteracji
• monitorowanie post?pu projektu iteracyjnego, miary

Dyscyplina zarz?dzania projektem zawiera równie? inne Plany i Artefakty, które s? u?ywane do kontrolowania projektu i monitorowania jego post?pu. Do planów nale??:

• plan faz (The Software Development Plan)
• plan iteracji

Plan faz

Ka?da faza traktowana jest jako projekt, kontrolowany i mierzony poprzez Software Development Plan pogrupowany w podzbiór planów kontrolnych:

• Plan miar (Measurement Plan) – definiuje cele pomiarów, skojarzone miary, i proste miary, które b?d? gromadzone w projekcie w celu monitorowania jego post?pu.
• Plan zarz?dzania ryzykiem (Risk Management Plan) – uszczegó?awia w jaki sposób zarz?dza? ryzykami zwi?zanymi z projektem. Wymaga uszczegó?owienia zadań zarz?dzania ryzykami, które b?d? wykonywane, przypisania do nich odpowiedzialno?ci oraz dodatkowych wymaganych zasobów. W projektach mniejszej skali plan mo?e by? powi?zany z Software Development Plan.
• Lista ryzyk (Risk list) – posortowana lista znanych i otwartych ryzyk posortowanych wed?ug wa?no?ci i skojarzonych z akcjami minimalizacji oraz planami awaryjnymi (mitigation and contingency actions).

Dyskusja

• RUP jest cz?sto b??dnie postrzegany jako ci??ki i kosztowny proces. Tymczasem RUP nie by? opracowany, pozycjonowany i promowany jako gotowy proces ?prosto z pude?ka”. Na przystosowywanie procesu do w?asnych potrzeb pozwala produkt Rational Method Composer. W chwili obecnej jest on rozwijany na bazie produktu Eclipse Process Framework powstaj?cego w ramach Eclipse. W ramach tego projektu udost?pniona zosta?a za darmo wersja Open Unified Process.
• ?Moje do?wiadczenie z RUP jest takie, ?e jego nieograniczona dostosowywalno?? stwarza problemy. Napotyka?em przypadki u?ycia RUP od modelu kaskadowego z iteracjami analitycznymi, do pe?nego procesu Agile. Uderzy?o mnie to, ?e promowanie RUP jako pojedynczego procesu doprowadzi?o do tego, ?e ludzie mog? zrobi? wszystko i nazwa? to RUP – co prowadzi do tego, ?e RUP staje si? nic nie znacz?cym s?owem.”
• ?Moje do?wiadczenie natomiast jest takie, ?e musz? istnie? pewne wzorce w kierunku których prace maj? pod??a?. Problem ró?nej interpretacji RUP, de facto, jest jego zalet?. Negatywne skutki, które zauwa?amy w aktualnych projektach, wywodz? si? z ?ci?cia kosztów” nie w tym miejscu organizacji projektu – co potrzeba. Brakuje w nim najcz??ciej zapomnianej roli ?In?yniera procesu wytwórczego”. By? mo?e kto? nazwa?by go kierownikiem projektu (Ale zwykle kierownika projektu postrzega si? inaczej i ocenia inne kompetencje projektu. Zreszt? opisano ten problem w artykule powy?ej).”
• RUP jest metodyk? oparta na koncepcji Modelu perspektyw architektonicznych 4+1 Philippe’a Kruchtena. G?ównym sposobem budowy oprogramowania w tej metodyce to opracowywanie kolejnych modeli opisuj?cych zazwyczaj co najwy?ej jedn? perspektyw?. Zgodnie z RUP zaleca si? stosowanie pi?ciu perspektyw: perspektywa logiczna, implementacyjna, procesowa, wdro?eniowa i perspektywa przypadków u?ycia. Najwa?niejsz? perspektyw? jest perspektywa przypadków u?ycia, któr? RUP zaleca jako perspektyw? do sprawdzania prawid?owo?ci pozosta?ych perspektyw.

Zobacz te?

• Open Unified Process (OpenUP) – otwarty proces wytwarzania oprogramowania, opracowany jako cz??? projektu Eclipse Process Framework (EPF).