Rational Unified Process (RUP) – proces iteracyjnego wytwarzania oprogramowania opracowany przez firmę 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 (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 – jeden z głównych autorów RUP, Ken Hartman, prowadził razem z Boehmem badania. Podejście Rational (Rational Approach) zostało opracowane przez w latach osiemdziesiątych i dziewięćdziesiątych.

W roku 1995 Rational przejęło szwedzką firmę . Zunifikowany proces Rational (Rational Unified Process) był rezultatem połączenia podejścia Rational oraz metodyki Objectory zdefiniowanej przez jej założyciela . 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ł .

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: iteracyjnym wytwarzaniu oprogramowania (Iterative Development) zarządzaniu wymaganiami (Requirement Management) używaniu architektury bazującej na komponentach (Component-based architecture) graficznym projektowaniu oprogramowania kontroli jakości oprogramowania (Quality Assurance) 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: