Lucka Žoltá

Modely RUP, SCRUM, XP - softwarový proces

Z toho důvodu se zavádí modely, které mají zabránit vzniku těchto problémů. Patří sem například vodopádový model, iterační model, V-model, model prototypování a také RUP, SCRUM a IP.

Model RUP (Rational Unified Proces)

Process RUP navrhla firma Rational. Definuje disciplinovaný přístup k přiřazování úkolů a zodpovědností v rámci vývojové organizace. Jeho cílem je zajistit vytvoření produktu vysoké kvality požadované zákazníkem v rámci predikovatelného rozpočtu a časového rozvrhu. 

Klíčové aktivity RUP:

• Software je vyvíjen iterativně (v cyklech). Na konci každé iterace je spustitelný kód (verze). Softwarový systém je tak vyvíjen ve verzích, které lze průběžně ověřovat se zadavatelem a případně jej pozměnit pro následující iteraci. 
• Při vývoji se využívá existujících komponent. Vývoj softwaru se tak přesouvá do oblasti skládání produktu z prefabrikovaných komponent. 
• Model softwarového systému je vizualizován pomocí UML, který pomáhá uchopit strukturu a chování výsledné architektury produktu.
• Součástí RUP jsou i metody pro správu požadavků, které obsahují postupy jak dostat ze zadavatele požadavky na systém, jak s nimi dále pracovat.
• Ve všech aktivitách se neustále ověřuje kvalita softwarového produktu.
• RUP zahrnuje i princip řízení změn, který se stará o monitorování změn, ke kterým v systému došlo, ať už vlivem doplnění požadavků, či oprav chyb apod.  Řízení změn umožňuje zaručit, že každá změna je přijatelná a všechny změny systému jsou sledovatelné. 

Výhody RUP

• Obecnost a mohutnost
• Iterativní přístup – včasné odhalení rizik
• Snazší správa změn
• Provázanost s notací UML, dokumentace
• Výrobce průběžně pracuje na zlepšování metodiky
• Existence doplňkových nástrojů

Nevýhody RUP

• Komerční, placený produkt
• Rozsáhlost RUP může být na škodu u malých týmů – tým stráví spoustu času implementací metodiky
• Její použití vyžaduje hluboké studium, týká se i projektových manažerů

 Každá fáze může být dále rozložena do několika iterací.

V rámci každé iterace proběhnou činnosti, které jsou uspořádány do toků charakteristických svým účelem - tzv. základních toků, jejichž výsledkem je část softwarového produktu (artefakt), a ty jsou:

• Byznys modelování - popisující strukturu a dynamiku podniku či organizace. 
• Specifikace požadavků - definující prostřednictvím specifikace tzv. případů použití softwarového systému jeho funkcionalitu. 
• Analýza a návrh - zaměřené na specifikaci architektury softwarového produktu. 
• Implementace - reprezentující vlastní tvorbu softwaru, testování komponent a jejich integraci. 
• Testování - zaměřené na činnosti spjaté s ověřením správnosti řešení softwaru v celé  jeho složitosti. 
• Rozmístění - zabývající se problematikou konfigurace výsledného produktu na cílové počítačové infrastruktuře. 

Mimo základní toky existují i toky podpůrné, které nevytváří hodnotu, ale jsou nutné pro realizaci základních toků. A ty jsou:

• Řízení změn a konfigurací zabývající se problematikou správy jednotlivých verzí vytvářených artefaktů odrážejících vývoj změn požadavků kladených na softwarový systém. 
• Projektové řízení zahrnující problematiku koordinace pracovníků, zajištění a dodržení rozpočtu, aktivity plánování a kontroly dosažených výsledků. Nedílnou součástí je tzv. řízení rizik, tedy identifikace problematických situací a jejich řešení. 
• Prostředí a jeho správa je tok činností poskytující vývojové organizaci metodiku, nástroje a infrastrukturu podporující vývojový tým. 

Schématické zobrazení procesu RUP a všech jeho toků, jak jsou vyvíjeny v čase.

  Čerpáno ze skript Úvod do softwarového inženýrství (Prof. Ivo Vondrák)

Agilní metodiky 

Jsou skupiny metod původně určených pro vyvíjení softwaru založené na iterativním a inkrementálním vývoji. Umožňují rychlý vývoj softwaru a zároveň dokáží reagovat na změnu požadavků v průběhu vývojového cyklu. Podle těchto metodik se správnost systému ověří jedině pomocí rychlého vývoje, předložení zákazníkovi a následných úprav dle zpětné vazby.

Do agilních metodik patří další 2 modely SCRUM a XP. 

Model SCRUM

Metodika Scrum se řadí mezi agilní metodiky pro vývoj software. Tato metodika má několik zajímavých myšlenek a nápadů (denní meetingy, samostatné přiřazování vývojářů na úkoly,…), které přispívají k zrychlení a zefektivnění vývojového cyklu.

Klíčovou částí metodiky jsou každodenní setkání týmu. Každý člen zde referuje o své činnosti z minulého dne, o tom, co bude dělat dnes, a na jaké problémy narazil. Metodika prosazuje iterativní vývoj, období iterace se nazývá Sprint a trvá 2-4 týdny. Výsledkem Sprintu je demo vzniklých úprav, které je předvedeno zákazníkovi. Ten poskytne zpětnou vazbu, což umožňuje rychle reagovat na změny v požadavcích.

Jsou zde rozeznávány tři role:

• Product Owner (PO) má za úkol komunikovat se zákazníkem.
• Správné fungování vývojového týmu zajišťuje Scrum Master (SM)
  
• Člen vývojového týmu se nazývá Scrum Team Member (STM)
  

Vývojový cyklus

V první fázi komunikuje PO se zákazníkem zadání nových požadavků. Ty tvoří tzv. User Stories (požadavky zákazníka). Poté se na Sprint Planning Meetingu sejde PO, SM a Scrum Team a společně odhadnou zadané User Stories. Poté podle priorit naplánují budoucí Sprint, tedy vyberou user story, které budou v tomto Sprintu dokončeny.

Tyto user story jsou poté ve Scrum Teamu dále rozepsány do Sprint Backlogu (popis problému na technické úrovni pro programátora) a ty následně do Tasků (samostatný úkol pro člena týmu). Během trvání sprintu (asi 3 týdny) probíhají každodenní meetingy (Daily Scrum Meetings). Na konci Sprintu, resp. Releasu je zákazníkovi předvedeno demo vzniklých úprav. Zákazník se k nim může vyjádřit a zhodnotit, zda jsou splněny jeho požadavky. Scrum díky tomu dokáže rychle reagovat na změny zadání od uživatele.

Další pojmy vázající se ke SCRUM:

• Story Point, Velocity - Story point (SP) je označení základní jednotky pro odhady pracnosti. S tímto pojmem souvisí také tzv. Velocity, což je koeficient převodu hodiny na SP pro každého vývojáře. Většinou bývá hodnota SP 4 hodiny.
• Burndown Chart - Graf závislosti počtu SP v období daného Sprintu. Graf má sloužit pro Scrummastera k tomu, aby dokázal lépe sledovát průběh vývoje.

Burndown chart - modře vyznačená ideální linie počtu hodin v čase, červená skutečně doručené hodiny

Model XP ( Extrémní programování)

XP je pravděpodobně nejznámější agilní metodikou. Propaguje časté dodávky software v krátkých vývojových cyklech. Kromě toho navrhuje párové programování, jednotkové testování celého kódu (nejdříve se vytvoří test, až pak samotný kód), programovat jen to, co je v danou chvíli nezbytné, jednoduchý a jasný kód. Mezi další praktiky patří společné vlastnictví kódu a neustálý refaktoring. Vývojáři by měli počítat se změnami požadavků v průběhu času. Důležitá je častá komunikace se zákazníkem i mezi programátory.

Základní princip je v dotažení osvědčených činností do extrému.

• Pokud se osvědčila revize kódu, pak v XP se zdrojový text reviduje neustále. Využívá se tzv. párového programování, kdy společně u jednoho počítače pracují dva programátoři. Zabraňuje se tam mimo jiné tzv. profesionální slepotě.
• Pokud se osvědčilo testování kódu, pak v XP se testuje vše a neustále. Testují jak programátoři pomocí „jednotkových testů“ tak i zákazníci pomocí „akceptačních testů“(testů funkcionality). Testovací kód mnohdy svým rozsahem převyšuje vlastní výkonný kód. Testování pak probíhá prakticky neustále, před změnou kódu, po změně kódu a kontroluje zda se v průběhu vývoje funkcionalita nepoškodila.
• Pokud se osvědčilo navrhování kódu, pak v XP bude navrhovat úplně každý a neustále. Pomocí refaktorizace může každý kontrolovat návrh kódu a vhodně ho upravovat.
• Pokud se osvědčila jednoduchost, pak v XP udržujeme program na co nejmenší úrovni složitosti. Vždy programujeme jen to, co je v danou chvíli nezbytné. Nejjednodušší program, který bude fungovat.
• Pokud je důležitá architektura, pak v XP se bude každý neustále podílet na definování a úpravě architektury. Využívá se k tomu metafory.
• Pokud je důležité testování integrace, pak se v XP testuje integrace jednotlivých komponent i několikrát denně, aby bylo zajištěno že všechny části spolupracují tak jak mají. Toto pravidlo se nazývá neustálou integrací.
• Pokud se osvědčily krátké iterace, pak v XP zkrátíme iterační periodu na extrémně krátkou – minuty, hodiny či dny místo týdnů, měsíců či roků. Jakmile je nová funkce připravena a otestována, integrujeme ji do produkční verze programu. K určení optimální iterační periody využíváme plánovací hru.

Extrémní programování uznává základní čtyři hodnoty:

Komunikace - V rámci projektu je třeba udržovat kvalitní komunikaci mezi všemi zainteresovanými subjekty. XP přichází s postupy práce, které komunikaci podporují nebo i vyžadují - párové programování. Stejně tak důležitá je i role kouče, který je v týmu mimo jiné od toho, aby špatně komunikující články a jejich interakci s týmem obnovil.

Jednoduchost - V XP se vždy programuje pouze to, co je třeba ke splnění aktuálních požadavků. Nikdy se nevytváří kód, který se bude „nejspíš“ hodit v budoucnu. XP vychází z předpokladu, že požadavky se mohou zítra změnit.

Zpětná vazba - Zpětná vazba se v projektu projevuje hned na několika místech. V první řadě programátoři neustále tvoří jednotkové testy, takže v krátkých časových intervalech dokáží ověřit, že vše funguje tak jak má a že se nic poslední změnou kódu nerozbilo. Dále je zde například zpětná vazba pro zákazníky, kteří prováděním svých akceptačních testů dokáží zjistit, v jakém stavu se program nachází. 

Odvaha - Odvaha je u programátora potřeba, pokud například narazí na významný problém, jehož oprava nejspíš způsobí kaskádu souvisejících problémů. Pustit se do tak velké změny vyžaduje odvahu. Stejně tak vyžaduje odvahu zahodit kód, na kterém programátor pracoval třeba celý den bez úspěchu (druhý den programátor pravděpodobně dokáže najít optimální řešení mnohem rychleji).

Postup vývoje u XP

1.  Zadání

• sepsání „User stories“ (uživatelských příběhů, scénářů), seznam funkčních požadavků, akceptačních kritérií
• zákazník může akceptační kritéria kdykoli doplnit a restartovat tak cyklus vývoje - dosavadní již rozběhlý běh vývoje pak je ale nutno prohlásit za promarněný (i peněžně).

2. Plánování

• plánování vydání tvoří časový harmonogram
• časté vydávání malých změn
• měří se aktuální rychlost vývoje
• projekt je rozdělen do iterací - každá iterace začíná plánováním
• rychlé schůze, nejlépe ve stoje
• „sprav to, když se to rozbije“

3.  Design

• ceněná je jednoduchost
• pro systém musí existovat metafora
• pro design se používají Class, Responsibilities, and Collaboration kartičky
• pro zmenšení rizika „spike solution“
• funkčnost není přidávána předčasně
• časté refaktorování (provádění změn) kdykoliv a kdekoliv

4. Programování

• zákazník vždy spolupracuje
• zdrojový kód musí odpovídat firemní kultuře
• nejdřív se píší jednotkové testy (unit testy)
• veškerý kód programují programátoři ve dvojicích (tj. dva programátoři sedí u jednoho počítače a u jedné klávesnice)
• integraci provádí v jednu chvíli pouze jediný pár programátorů
• integrace probíhá často
• zdrojové kódy vlastní všichni programátoři (každý přispívá k celku a odpovídá za celek)
• optimalizace se provádí až nakonec
• žádné pracovní přesčasy

5. Testování

• všechen kód má své unit testy a všemi musí produkt úspěšně projít, všechny splnit, než je vydán.
• když se najde chyba, vytvoří se na ní nové unit testy. (je zahrnuta do knowledge-base, znalostní báze produktu)
• unit testy jsou jen nutnou, ale ne postačující podmínkou "otestovanosti": Cílené testování testery/QA se i nadále předpokládá
• interní akceptační testy se spouští/provádí často a reprodukovatelně, jejich výsledky se zaznamenávají.

6. Dodávka a akceptace

• Dodavatel je povinen pro zákazníka připravit akceptační prostředí, do něj produkt nasadit, nakonfigurovat ho a naplnit daty.
• Zákazník svá akceptační testování provádí právě a jen podle příběhů a kritérií ze zadání.
• Pokud dodávka splňuje všechna akceptační kritéria, zákazník ji musí převzít. Zákazník však může akceptační kritéria doplnit a iniciovat tak další cyklus vývoje (placeného).