Lekce 7 - Rational Unified Process a Metodiky řízení

V minulé lekci, Metodiky ASD, FDD a Crystal Methodologies, jsme probrali metodiky Adaptive Software Development, Feature-Driven Development a Crystal Methodologies.

V této lekci se podíváme na metodiku Rational Unified Process a pak na metodiky řízení PRINCE2 a PMBoK.

Rational Unified Process

RUP (Rational Unified Process, česky racionální jednotný proces) je proces vývoje softwaru vytvořen jednou z divizí firmy IBM. Tato metodika nebyla vytvořena jako soubor pravidel, která by se měla přísně dodržovat, ale spíše jako soubor doporučení, které si vývojové týmy vybírají podle toho, které odpovídají jejich potřebám. Díky rozsáhlému plánování, analýzám a dokumentaci je vhodnější spíše k řešení větších projektů s velkými týmy. Metodika je velmi komplexní a systematická. Stejně, jako již dříve zmíněné metodiky, přistupuje k vývoji iterativně, spravuje požadavky zákazníků, ověřuje kvalitu již vytvořených částí softwaru, který vzniká na komponentové architektuře a využívá vizuálního modelování k udržení přehledu nad projektem.

Metodika Rational Unified Process uznává 10 principů:

• Vytvořte si jasnou vizi – Kdo projekt platí, kdo bude výsledný produkt využívat a jaká jsou omezení? (peníze, čas, rozsah)
• Řiďte se podle plánu – Pomáhá držet přehled nad rozsahem a možnými riziky.
• Nalezněte, zmírněte a odstraňte rizika – Nutno udělat již v počátečních fázích projektu. Pokud se rizika neobjeví a neodstraní na začátku vývoje, jejich následná eliminace může být klidně 100× až 1000× dražší.
• Pojmenujte problémy a sledujte jejich řešení – To řeší odpovědná osoba, která zodpovídá i za termíny, do kterých se musí problémy vyřešit.
• Rozumějte obchodnímu kontextu – Jen tak může být produkt kvalitní. Pokud nerozumíte tomu, proč produkt vytváříte, je to špatně, nepochopíte tak správně potřeby zákazníka.
• Používejte komponentovou architekturu – Jednodušší a levnější vývoj. Vzniká prostor na přidání či odebrání částí, o které má/nemá zákazník zájem, a to jednoduchým přidáním/odebráním jednotlivých komponent.
• Vyvíjejte inkrementálně, neustále testujte - Postupné přidávání po menších částech a jejich důkladné testování usnadňuje nalezení chyb a jejich eliminaci. Nalezení a opravení chyby zavčas je mnohem jednodušší a levnější, než odstranění chyb z „hotového produktu“.
• Pravidelně vyhodnocujte výsledky – Ať už se jedná o vyhodnocení výsledků vývoje nebo jednání se zákazníky, pravidelné vyhodnocování pomůže k včasnému odhalení problémů.
• Řiďte a sledujte změnové požadavky – Každý požadavek má životní cyklus, od jeho položení, až po jeho naplnění. Na požadavky dohlížejí pověřené osoby, aby byly požadavky splněny.
• Poskytujte dostatečnou uživatelskou podporu – Návod na instalaci, manuál pro uživatele, různá školení a workshopy.

Graf znázorňující výši nákladů v závislosti na čase.

Každý projekt provázejí takzvané disciplíny (činnosti při vývoji softwaru):

• Tvorba modelu
• Správa požadavků
• Analýza a návrh
• Implementace
• Testování
• Nasazení
• Konfigurace a změny
• Řízení projektu
• Správa prostředí

Graf jednotlivých disciplín jde postupně:

Graf jednotlivých disciplín.

Posloupnost disciplín.

Analýza a sběr požadavků

Analýza a sběr požadavků je proces, ve kterém se snažíme zjistit něco jako Hlavní úkol. Cílem je vymezit hranice vytvářeného systému, umožnit přesnější odhad pracnosti, vyjasnit si se zákazníkem zadání a zachytit omezení, která jsou na námi vytvářený produkt kladena. Toto probíhá ve čtyřech fázích:

• Sběr – Schůzky, jednání, poskytnuté dokumenty, pozorování uživatelů a podobně.
• Analýza – Přemýšlení, vymýšlení, debaty, poznámky…
• Specifikace – Dekompozice problému na menší části, vlastní pochopení požadavků a jejich interpretace.
• Ověření – Schůzky, jednání, promítání prototypu, definice rozsahu…

Výše zmíněné body se můžou opakovat i vícekrát.

Proč se specifikací požadavků zabývat?

• Špatně definované požadavky způsobují neúspěch projektů
• Lépe se zadává práce technikům
• Přesný rozsah kontraktu
• Zákazník chce vše, co není explicitně „NE“
• Dodavatel dělá jen to, co je explicitně „ANO“
  • Z toho vyplývá – Pozor na šedou zónu (to, co není přesně specifikované)
• Základní část dokumentace systému
• Důležitým parametrem ceny díla

Role analytika – Zákazník zná své cíle, ne požadavky. Most mezi byznysem zákazníka a IT problematikou.

Kategorizace požadavků

Požadavky na software od zákazníka dělíme pro větší přehlednost do kategorií a abychom tak přiřadili k jednotlivým kategoriím co možná nejvhodnější lidi. V základu se tyto požadavky dělí na funkční (požadavky na vlastní funkčnost daného softwaru) a nefunkční (obecné aspekty – výkon, bezpečnost, spolehlivost, dostupnost, atd., splnění požadavků by mělo být vždy ověřitelné). Požadavky se dále kategorizují pomocí rozdělení FURPS:

F (functionality) – Funkčnost, například v Rational Unified Process mapujeme funkčnosti na případy použití. RUP je use-case driven (dělaný podle příkladů použití) U (usability) – Použitelnost R (reliability) – Spolehlivost P (performance) – Výkon S (supportability) – Podporovatelnos­t/Rozšířitelnost

Metodiky řízení

Zde si představíme metodiky řízení, které se využívají nejen při procesu RUP.

PRINCE 2

PRojects IN Controlled Environments, v českém překladu Projekty v kontrolovaném prostředí. Tuto metodiku původně vyvíjela vláda Spojeného Království. Nevyužívá se už pouze v IT, jedná se o metodiku, která je hojně využívána v projektovém řízení jako takovém. Je velmi populární a také vhodná pro menší, ale i větší projekty. Rozděluje projekty do fází, ale na rozdíl od ostatních metodik tyto fáze přímo nepojmenovává.

Metodika PRINCE 2 využívá tři sedmičky. Nejprve si uvedeme 7 principů:

• Neustálé zdůvodnění projektů
• Jasně definované role a odpovědnosti
• Zaměření na produkty
• Řízení po etapách
• Řízení na základě výjimek
• Učení se ze zkušeností
• Přizpůsobování metody PRINCE 2 prostředí projektu

7 témat:

• Zdůvodnění projektu (business case)
• Organizace
• Kvalita
• Plány
• Riziko
• Změna
• Progres

A 7 procesů:

• Zahájení projektů (předprojektová příprava)
• Nastavení (iniciace) projektu
• Směřování (strategické řízení projektu)
• Kontrola (řízení) etapy
• Řízení dodávky produktu
• Řízení přechodu mezi etapami
• Ukončení projektů

PMBoK

Jedná se o nejpoužívanější metodiku řízení. Využívá se až ve 40 procentech případů. Zkratka PMBoK pochází z názvu Project Management Body of Knowledge. Jak už možná může vyplývat z názvu, jedná se spíše o jakousi znalostní bázi, než o komplexní metodiku. PMBoK je postavená na procesech. Procesy dělí do různých skupin:

• Iniciační – Zahájení projektu
• Plánovací – Příprava plánů pro úspěšné zvládnutí projektů
• Realizační – Plnění plánů připravených v předchozí fázi
• Monitorování/o­vládání – Zkoumání, zda projekt naplňuje očekávání a požadavky
• Ukončovací – Dokončení projektu

Závěr

Vývoj softwaru nebo řízení projektů je poměrně komplexní záležitost. Pomáhají nám s tím nejrůznější metodiky, jako například ty, které jsme si zde za celou sérii uvedli. To ovšem není vše. Tyto metodiky je třeba častokrát upravit pro vlastní potřeby a také proto se jim spíše říká soubor doporučení, než pevně daná pravidla.

V následujícím kvízu, Kvíz - Metodiky XP, ASD, FDD, Crystal, RUP a řízení, si vyzkoušíme nabyté zkušenosti z předchozích lekcí.