Metodika Rational Unified Process se stále více rozšiřuje ve firmách zabývající se vývojem SW.  Tato metodika patří primárně k metodikám tradičním; opakem jsou pak agilní přístupy k vývoji SW. Je ovšem RUP tak úžasný, když je mu všude věnováno tolik prostoru? ANO, RUP je vynikající metodika, která dokáže pomoci projektovému týmu sdělením Best Practices, jak by měli kdy postupovat. Úmyslně říkám „dokáže“ – výhody RUP se často v rukou nezkušených implementátorů stávají spíše nevýhodami.

Výhody metodiky RUP

Podívejme se na pár výhod, které RUP přináší:

• Obecnost, šíře, mohutnost -RUP začíná popisovat fáze vývoje SW už od raných počátků – v dobách, kdy tým jedná o zakázce ve formě Business Case nám RUP radí, čím bychom měli začít, jak bychom měli dále postupovat a tak to pokračuje až do nasazení výsledného produktu do užívání. RUP lze s úspěchem použít na jakýkoliv typ projektu SW vývoje – vývoj internetového bankovnictví, systém pro státní správu, logistický software, vývoj webu (i když zde bych RUP určitě nepoužil),…
• Detailní propracovanost kroků, které je třeba učinit – s touto otázkou se setkává většina lidí na projektu. Zvláště od projektového manažera je často očekávána odpověď na otázky: „co ode mne jako od analytika čekáš za výstupy?“ RUP díky nadefinovanému workflow všech svých kroků říká, co je za každý krok (či sled kroků v rámci procesu) od každé role očekáváno, jaké jsou potřebné vstupy a jak by měl vypadat takový vzorový výstup.  Jak by to vypadalo v případě analytika: první fází vývoje SW je fáze Inception. V rámci této fáze, kdy se definuje primárně business case jako takový, studie proveditelnost a klíčová funkčnost. Co by v tuto chvíli měl analytik zabezpečit? Dle nastíněného procesu fáze Inception je zodpovědností analytika, hned po procesu „Prepare Environment for Iteration“ zanalyzovat problém, následně identifikovat klíčové stakeholdery a v fázi Inception zakončit artefaktem Software Requirements (kterému předchází procesy Manage the scope of the system a Define the system. Stejně, jako u každého jiného artefaktu, se mohu podívat,jakou strukturu by dokument Software Requirements měl mít a na 1-2 vyplněné příklady. Toto je dle mne jedna z nejúžasnějších vlastností RUP.

RUP - Inception fáze

• RUP je založen na objektové přístupu. Současně existuje silné propojení a vazba na různé CASE nástroje. Se stereotypy RUP lze tak pracovat v mnoha vyspělejších CASE (např. Enterprise Architect, Magic Draw) a tak si přizpůsobit RUP svým potřebám (lze samozřejmě využít RUP Builder, který je součástí distribuce).

• Mnoho doplňkových nástrojů – firma Rational (nyní vlastněno IBM) poskytuje mnoho SW nástrojů, které dokáží usnadnit práci. Jedná se o nástroje pro sdílená úložiště, sběr požadavků, testování – vše silně provázáno na definované procesy v RUP.
• Doplňky třetích stran ve formě Whitepapers – RUP či jiné produkty firmy Rational lze používat i odděleně; pro většinu případů existuje sepsaný postup, jakým způsobem tyto 2 oblasti integrovat. Veškeré případy lze rozdělit do 2 oblastí:
  • Firma používá metodiku XY (jinou než RUP) a současně vývojové nástroje firmy Rational
  • Firma používá metodiku RUP a vývojový nástroj 3.strany (např. Visual Studio či Eclipse).

Nevýhody metodiky RUP

Velká část výhod RUP se stává současně i její nevýhodou. Vezměme např. hned první zmíněnou výhodu – ROZSÁHLOST. Ačkoliv navigace v metodice (distribuována jako sada HTML stránek) je velmi intuitivní, nezkušený člověk se v ní velmi rychle ztratí. Každý proces odkazuje na mnoho dalších míst, ke každému procesu či artefaktu je definován seznam kroků, které je potřeba mít hotov ještě před zahájením. A každý tento předchůdce má opět svůj seznam předpokladů. Opět se nám zde objevuje potřeba mít pro implementaci RUP řídícího člověka, který dokáže zbytek týmu v případě potřeb navigovat.

Velkou nevýhodu vidím současně v komplexnosti a univerzálnosti. Jelikož má RUP obsáhnout veškeré možné případy ve vývoji SW (a to už je pěkný oříšek), popisuje mnoho kroků, které ve většině projektů nebudou vůbec potřeba a které by projekt zbytečně pouze prodlužovaly. Hodnotu této nevýhody částečně snižuje poslední verze, kdy již v základní verzi existuje rozdělení na velké a malé projekty.

Shrnutí

I před pár popsaných nevýhod RUPu jeho používání vřele doporučuji. Zvláště v rukou zkušeného lídra se stává mocnou zbraní, kterou lze velmi dobře využít. Implementátor metodiky by měl vždy zvážit, co z metodiky tým použije, co nikoliv a co je vhodnější nahradit jiným způsobem řízení vývoje software. V některém z dalších článků se zaměřím na nejčastější chyby, ke kterým při implementaci RUP dochází.
Další informace k RUP na tomto webu: Presentace “Využití Rational Unified Process při řízení projektu vývoje SW”,  Vývoj SW – agilní vs. tradiční přístupy.