Rational Unified Process: základní pojmy

• Iterativní vývoj softwaru: fundamentální problém tradičního, sekvenčního přístupu spočívá v tom, že před sebou tlačí (často dosud netušená) rizika, jejichž odstranění je postupně čím dále dražší. Naproti tomu v iterativním a inkrementálním přístupu (viz následující obrázek), který vychází z Boehmova spirálového modelu, dochází k detekci rizik průběžně. Mezi další výhody iterativního vývoje patří snazší správa změn, lepší znovupoužitelnost, dokonalejší přiblížení k zákazníkovi, atd.
• Správa a řízení požadavků: požadavky jsou typicky dynamické a je nutné počítat s tím, že se v čase mění (syndrom IKIWISI – I Will Know It When I See It – „budu to vědět, až to uvidím“: s nadsázkou vyjádřená neschopnost zákazníka specifikovat dopředu všechny požadavky na vyvíjený produkt).
• Použití komponentové architektury: je-li vyvíjený systém otevřený k použití jiných komponent, může být vývoj efektivnější; znovupoužití hotové komponenty znamená podstatnou úsporu zdrojů. RUP poskytuje metodickou, systematickou cestu návrhu, vývoje a ověření správnosti architektury. Nabízí šablony, architektonické styly a pravidla designu.
• Vizuální modelování softwaru: model je zjednodušením reality; je vytvářen za účelem dokonalejšího porozumění systému; u rozsáhlejších projektů také proto, že není možné pochopit systém v celé jeho celistvosti. Použití standardního modelovacího jazyka (UML) znamená zjednodušení komunikace uvnitř týmu, zlepšení konzistence projektu, zvýšení pravděpodobnosti správného uchopení systému.
• Průběžné zajišťování a ověřování kvality: nalezení a odstranění problému je 100krát až 1000krát dražší po předání produktu než v úvodních fázích vývoje.
• Řízení změn: neřízené změny (ať již při vývoji nebo i po předání) vedou k chaosu.

RUP se ve svých jednotlivých oblastech snaží řídit všemi uvedenými obecnými praktikami a přibližuje se k nim pomocí mnoha definovaných aktivit.

RUP dále definuje čtyři základní, nejdůležitější elementy modelování, na nichž ovšem staví nejen celé modelování, ale přeneseně i celý vývojový proces (pomocí těchto elementů se modelují základní případy použití a pracovní procesy, z nichž se celý RUP skládá).

Pracovníci (workers)

Pracovníci (workers) odpovídají na otázku kdo. Pracovník definuje chování a odpovědnost jedince nebo skupiny. Chování pracovníka je popsáno pomocí činností (activities); každý pracovník je asociován s množinou činností. Odpovědnost je obvykle definována ve vztahu k meziproduktům (artifacts), které pracovník vytváří, modifikuje nebo kontroluje. Pracovníkem není ani tak fyzická osoba, jako spíše jakýsi „klobouk“, který může být v průběhu projektu „nasazován“ různým fyzickým osobám (jedna osoba může postupně nosit více klobouků). Pracovníka je vhodné vidět jako roli.

Příklady pracovníků: System analyst, Designer, Test designer, Code reviewer, Implementer apod. Přiřazení mezi fyzickými osobami a pracovníky provádí pracovník Bussiness Designer.

Činnosti (activities)

Činnosti (activities): odpovídají na otázku jak. Činnost je jednotkou práce, kterou má provést jednotlivec nebo skupina, a která má vyústit ve smysluplný výsledek v kontextu projektu. Činnost má jasně definovaný účel, obvykle vyjádřený jako vytvoření nebo modifikace meziproduktu (např. modelu, třídy, plánu apod.). Rozsah činností je různý, od několikahodinových po několikadenní. Činnost se však obvykle týká jen jednoho pracovníka a ovlivňuje nejvýše několik málo meziproduktů. Každá činnost má definovány své vstupní a výstupní meziprodukty.

Příklady činností: plán a integrace (provádí projektový manažer – Worker: Project Manager), nalezení případů použití a herců (systémový analytik – Worker: System Analyst), přezkoumání designu (Worder: Design Reviewer), spuštění výkonového testu (Worker: Performance Tester) apod.

Činnosti se dále dělí do kroků. Obecné dělení kroků spočívá ve stanovení tří základních kategorií:

• Úvahy (Thinking Steps)
• Provádění (Performing Steps)
• Přezkoumání (Reviewing Steps)

Konkrétní činnost má vždy stanovenu podrobnou posloupnost kroků, které vedou k jejímu uspokojivému provedení. Jako příklad lze uvést např. činnost návrh databázového designu (Activity: Database Design), která se skládá z následující posloupnosti kroků:

• provést mapování tříd z designu do datového modelu
• optimalizace datového modelu (datových struktur) z hlediska výkonnosti
• optimalizace přístupu k datům (použití indexů a jejich typů apod.)
• definice charakteristik uložení dat (velikost stránky apod.)
• definice referenčních tabulek a přednastavených hodnot atributů (např. uložení nejpoužívanější tabulky na nejrychlejší disk, optimalizace vyrovnávacích pamětí apod.)
• definice pravidel datové a referenční integrity
• distribuce chování třídy do databáze (uložené procedury apod.)
• přezkoumání výsledku (ověření kvality a integrity datového modelu)

Každý z uvedených kroků je v rámci RUP velmi podrobně dokumentován; RUP poskytuje řadu tipů, návodů, pomůcek a rad potřebných ke zvládnutí daného kroku.

Meziprodukty (artifacts)

Meziprodukty (artifacts) odpovídají na otázku co. Meziprodukt je část informace, která je produkována, modifikována nebo použita v rámci procesu. Meziprodukty jsou hmatatelné výsledky projektu; jsou použity pracovníky jako vstupy svých činností a jsou zároveň výstupy těchto aktivit. Za vytvoření a správnost meziproduktu odpovídá definovaný pracovník.

Meziprodukty mohou mít řadu forem:

• model (např. model případů použití nebo model designu)
• element modelu (např. třída, případ použití, subsystém)
• dokument (např. plán, část specifikace) – nepříliš často
• zdrojový kód
• spustitelná aplikace

Meziprodukty mohou být též vytvářeny za pomoci nejrůznějších nástrojů (např. modely pomocí Rational Rose, plány projektů pomocí Microsoft Project apod.).

Protože uvnitř RUP je definováno velké množství meziproduktů, je nutné rozdělit je do několika základních skupin. Následující přehled se týká RUP verze 2002; v předchozích verzích bylo dělení jiné (méně skupin):

• meziprodukty týkající se požadavků (Requirements Artifact Set)
• meziprodukty týkající se analýzy a designu (Analysis & Design Artifact Set)
• meziprodukty týkající se implementace (Implementation Artifact Set)
• meziprodukty týkající se testování (Test Artifact Set)
• meziprodukty týkající se šíření (Deployment Artifact Set)
• meziprodukty týkající se konfiguračního a změnového řízení (Configuration & Change Management Artifact Set)
• meziprodukty týkající se projektového řízení (Project Management Artifact Set)
• meziprodukty týkající se vývojového prostředí (Environment Artifact Set)
• meziprodukty týkající se obchodního modelování (Business Modelling Artifact Set)

Přestože RUP definuje mnoho meziproduktů, v konkrétním projektu není typicky nutné použít všechny. RUP je z principu určen k tomu, aby byl přizpůsoben konkrétním potřebám projektu; je tak možné využít pouze podmnožinu meziproduktů, stejně jako podmnožinu pracovníků a činností.

Příklady meziproduktů: prototyp uživatelského rozhraní, datový model, softwarová komponenta, požadavek na změnu, plán iterace apod.

Pracovní procesy (workflows)

Pracovní procesy (workflows) odpovídají na otázku kdy. Pouhý výčet všech pracovníků, činností a meziproduktů ještě nepředstavuje proces. Zbývá definovat smysluplnou posloupnost činností a stanovit interakce mezi pracovníky.

Pracovní proces je posloupnost činností vedoucí k vytvoření požadovaného výsledku. Pracovní proces může být s výhodou modelován v UML jako sekvenční diagram (sequence diagram), diagram spolupráce (collaboration diagram) nebo diagram činnosti (acivity diagram). Phillipe Kruechten však ve své knize The Rational Unified Process: An Introduction (Addison-Wesley, Boston, USA 2000) upozorňuje, že obvykle není možné dokonale postihnout veškeré (i skryté) závislosti mezi jednotlivými činnostmi; činnosti bývají navzájem značně protkány. Diagram pracovního procesu tedy nesmí být interpretován mechanicky.

Každý pracovní proces se tedy skládá z několika (typicky nejvýše z desíti) činností. RUP definuje devět klíčových pracovních procesů (Core Workflows). Tyto klíčové procesy se kryjí se skupinami meziproduktů uvedenými v předchozí kapitole.

Protože každý z devíti klíčových procesů pokrývá širokou oblast, dělí je dále RUP na tzv. podrobnosti pracovních procesů (Workflow Details). Ty se používají k vyjádření specifické skupiny úzce souvisejících činností. Například klíčový pracovní proces Workflow: Implementation se skládá z pěti podrobných pracovních procesů:

• vytvoření struktury implementace (Workflow Detail: Structure the Implementation Model)
• plánování integrace (Workflow Detail: Plan the Integration)
• implementace komponent (Workflow Detail: Implement Components)
• integrace každého podsystému (Workflow Detail: Integrate Each Susbystem)
• integrace systému (Workflow Detail: Integrate the System)

Dnešní článek se pokusil podat základní vysvětlení šesti základních principů a čtyř základních pojmů, které jsou definovány v metodice Rational Unified Process. Při podrobném zkoumání je patrné prolínání všech šesti principů celou metodikou. Stejně tak je zjevné, že skoro veškeré prvky RUP lze „zaškatulkovat“ do některé z kategorií definovaných základními pojmy – tedy vše, co je obsahem RUP, je buď pracovníkem, činností, pracovním procesem nebo meziproduktem.