7. diel - Rational Unified Process a Metodiky riadenie

V minulej lekcii, Metodiky ASD, FDD a Crystal methodologies , sme prebrali metodiky Adaptive Software Development, Feature-Driven Development a Crystal methodologies.

V tejto lekcii sa pozrieme na metodiku Rational Unified Process a potom na metodiky riadenia PRINCE2 a PMBOK.

Rational Unified Process

RUP (R ational U nified P rocess, česky racionálne jednotný proces) je proces vývoja softvéru vytvorený jednou z divízií firmy IBM. Táto metodika nebola vytvorená ako súbor pravidiel, ktoré by sa mala prísne dodržiavať, ale skôr ako súbor odporúčaní, ktoré si vývojové tímy vyberajú podľa toho, ktoré zodpovedajú ich potrebám. Vďaka rozsiahlemu plánovanie, analýzam a dokumentáciu je vhodnejšie skôr k riešeniu väčších projektov s veľkými tímami. Metodika je veľmi komplexná a systematická. Rovnako, ako už skôr spomínané metodiky, pristupuje k vývoju iteratívne, spravuje požiadavky zákazníkov, overuje kvalitu už vytvorených častí softvéru, ktorý vzniká na komponentovej architektúre a využíva vizuálneho modelovania k udržaniu prehľadu nad projektom.

Metodika Rational Unified Process uznáva 10 princípov:

• Vytvorte si jasnú víziu - Kto projekt platí, kto bude výsledný produkt využívať a aké sú obmedzenia? (Peniaze, čas, rozsah)
• Riaďte sa podľa plánu - Pomáha držať prehľad nad rozsahom a možnými rizikami.
• Nájdite, zmiernite a odstráňte riziká - Nutné urobiť už v počiatočných fázach projektu. Ak sa riziká neobjaví a neodstránia na začiatku vývoja, ich následná eliminácia môže byť pokojne 100 × až 1000 × drahšie.
• Pomenujte problémy a sledujte ich riešenie - To rieši zodpovedná osoba, ktorá zodpovedá aj za termíny, do ktorých sa musia problémy vyriešiť.
• Rozumejte obchodnému kontextu - Len tak môže byť produkt kvalitné. Ak nerozumiete tomu, prečo produkt vytvárate, je to zle, nepochopíte tak správne potreby zákazníka.
• Používajte komponentovú architektúru - Jednoduchšie a lacnejšie vývoj. Vzniká priestor na pridanie či odstránenie častí, o ktoré má / nemá zákazník záujem, a to jednoduchým pridaním / odobratím jednotlivých komponentov.
• Vyvíjajte inkrementálne, neustále testujte - Postupné pridávanie po menších častiach a ich dôkladné testovanie uľahčuje nájdenie chýb a ich elimináciu. Nájdenie a opravenie chyby zavčas je oveľa jednoduchšie a lacnejšie, než odstránenie chýb z "hotového produktu".
• Pravidelne vyhodnocujte výsledky - Či už sa jedná o vyhodnotení výsledkov vývoja alebo rokovania so zákazníkmi, pravidelné vyhodnocovanie pomôže k včasnému odhaleniu problémov.
• Riaďte a sledujte zmenové požiadavky - Každá požiadavka má životný cyklus, od jeho položenia, až po jeho naplnení. Na požiadavky dohliadajú poverenej osoby, aby boli požiadavky splnené.
• Poskytujte dostatočnú užívateľskú podporu - Návod na inštaláciu, manuál pre užívateľov, rôzne školenia a workshopy.

Graf znázorňujúci výšku nákladov v závislosti na čase.

Každý projekt sprevádzajú takzvané disciplíny (činnosti pri vývoji softvéru):

• tvorba modelu
• správa požiadaviek
• Analýza a návrh
• implementácia
• testovanie
• nasadenie
• Konfigurácia a zmeny
• riadenie projektu
• správa prostredia

Graf jednotlivých disciplín ide postupne:

Graf jednotlivých disciplín. .<>

Postupnosť disciplín.

Analýza a zber požiadaviek

Analýza a zber požiadaviek je proces, v ktorom sa snažíme zistiť niečo ako Hlavná úloha. Cieľom je vymedziť hranice vytváraného systému, umožniť presnejší odhad prácnosti, vyjasniť si so zákazníkom zadanie a zachytiť obmedzenia, ktoré sú na nami vytváraný produkt kladená. Toto prebieha v štyroch fázach:

• Zber - Schôdzky, rokovania, poskytnuté dokumenty pozorovanie používateľov a podobne.
• Analýza - Premýšľanie, vymýšľanie, debaty, poznámky ...
• Špecifikácia - dekompozícia problému na menšie časti, vlastné pochopenie požiadaviek a ich interpretácie.
• Overenie - Schôdzky, rokovania, premietanie prototypu, definícia rozsahu ...

Vyššie uvedené body sa môžu opakovať aj viackrát.

Prečo so špecifikáciou požiadaviek zaoberať?

• Zle definované požiadavky spôsobujú neúspech projektov
• Lepšie sa zadáva práce technikom
• Presný rozsah kontraktu
• Zákazník chce všetko, čo nie je explicitne "NIE"
• Dodávateľ robí len to, čo je explicitne "ÁNO" Z toho vyplýva - Pozor na šedú zónu (to, čo nie je presne špecifikované)
• Z toho vyplýva - Pozor na šedú zónu (to, čo nie je presne špecifikované)
• Základná časť dokumentácie systému
• Dôležitým parametrom ceny diela

Úloha analytika - Zákazník pozná svoje ciele, nie požiadavkami. Most medzi biznisom zákazníka a IT problematikou.

Kategorizácia požiadaviek

Požiadavky na softvér od zákazníka delíme pre väčšiu prehľadnosť do kategórií a priradili tak k jednotlivým kategóriám čo možno najvhodnejšie ľudí. V základe sa tieto požiadavky delia na funkčné (požiadavky na vlastné funkčnosť daného softvéru) a nefunkčné (všeobecné aspekty - výkon, bezpečnosť, spoľahlivosť, dostupnosť, atď., Splnenie požiadaviek by malo byť vždy overiteľné). Požiadavky sa ďalej kategorizovať pomocou rozdelenia FURPS:

F (functionality) - Funkčnosť, napríklad v Rational Unified Process mapujeme funkčnosti na prípady použitia. RUP je use-case driven (robený podľa príkladov použitia) U (usability) - Použiteľnosť R (reliability) - Spoľahlivosť P (performance) - Výkon S (supportability) - Podporovatelnost / Rozšíriteľnosť

Metodiky riadenia

Tu si predstavíme metodiky riadenia, ktoré sa využívajú nielen pri procese RUP.

Princov 2

PR ojects IN C ontrolled E nvironments, v českom preklade Procesy v kontrolovanom prostredí. Túto metodiku pôvodne vyvíjala vláda Spojeného Kráľovstva. Nevyužíva sa už len v IT, jedná sa o metodiku, ktorá je hojne využívaná v projektovom riadení ako takom. Je veľmi populárna a tiež vhodná pre menšie, ale aj väčšie projekty. Rozdeľuje projekty do fáz, ale na rozdiel od ostatných metodík tieto fázy priamo nepojmenovává.

Metodika PRINCE 2 využíva tri sedmičky. Najprv si uvedieme 7 princípov:

• Neustále zdôvodnenie projektov
• Jasne definované role a zodpovednosti
• Zameranie na produkty
• Riadenie po etapách
• Riadenie na základe výnimiek
• Učenie sa zo skúseností
• Prispôsobovanie metódy PRINCE 2 prostredie projektu

7 tém:

• Zdôvodnenie projektu (business case)
• organizácia
• Kvalita
• plány
• riziko
• Zmena
• progress

A 7 procesov:

• Začatie projektov (predprojektová príprava)
• Nastavenia (iniciácie) projektu
• Smerovanie (strategické riadenie projektu)
• Kontrola (riadenie) etapy
• Riadenie dodávky produktu
• Riadenie prechodu medzi etapami
• ukončenie projektov

PMBOK

Jedná sa o najpoužívanejší metodiku riadenia. Využíva sa až v 40 percentách prípadov. Skratka PMBOK pochádza z názvu P roject M anagement B ody o f K nowledge. Ako už možno môže vyplývať z názvu, jedná sa skôr o akúsi znalostnej báze, než o komplexnú metodiku. PMBOK je postavená na procesoch. Procesy delia do rôznych skupín:

• Iniciačný - Otvorenie projektu
• Plánovací - Príprava plánov pre úspešné zvládnutie projektov
• Realizačný - Plnenie plánu pripraveného v predchádzajúcej fáze
• Monitorovanie / ovládanie - Skúmanie, či projekt napĺňa očakávania a požiadavky
• Ukončovacie - Dokončenie projektu

Záver

Vývoj softvéru alebo riadenie projektov je pomerne komplexná záležitosť. Pomáhajú nám s tým najrôznejšie metodiky, ako napríklad tie, ktoré sme si tu za celú sériu uviedli. To však nie je všetko. Tieto metodiky treba častokrát upraviť pre vlastné potreby a tiež preto sa im skôr hovorí súbor odporúčaní, ako pevne dané pravidlá.

V nasledujúcom kvíze, Kvíz - Metodiky XP, ASD, FDD, Crystal, RUP a riadenia, si vyskúšame nadobudnuté skúsenosti z predchádzajúcich lekcií.