Modely životního cyklu vývoje softwaru

Součástí projektového řízení jsou následující metodiky vývoje softwaru. Což jsou v podstatě komplexní návody a postupy zkoumající správný vývoj aplikace s větším nadhledem. Metodiky se obecně nezabývají konkrétními způsoby jak danou operaci provést nebo čím ji provést.

2.5.1 Model napiš a oprav

Vznikl v úplném prvopočátku vývoje softwarových programů. Nejedná se však o uměle vytvořený model, spíše než to, se jedná o zcela spontánní a přirozený způsob jak lidé pracují. Nejdříve dojde k naprogramování aplikace a jejímu následnému uvedení do provozu, kde po té dochází k opravování veškerých chyb. Tyto kroky jsou znázorněny na obrázku 7. Tento model je značně neefektivní. Proto se často využívá jen u malých projektů, kde je jeho využití ospravedlnitelné. (Kadlec, 2004)

Obrázek 7: Schéma modelu napiš a oprav Zdroj: Upraveno dle (Kadlec, 2004)

2.5.2 Stagewise model

Tento model je založen na striktní posloupnosti jednotlivých fází, které tak rozdělují vývojový cyklus. Tyto fáze jsou Definice problému, specifikace požadavků, návrh a architektura, implementace integrace a provoz. A jsou znázorněny na obrázku 8.

Nejzásadnějším problémem v tomto modelu je absence jakékoli zpětné vazby. Postup vývoje směřuje pouze kupředu. Nedochází k žádným revizím, nehledají se žádná rizika, nehodnotí se dosavadní výsledky a ani nedochází k návratu do předchozích fází projektu za účelem upravení požadavků. K návratu bylo možné až po samotném dokončení celého cyklu, tedy po dodání. (Kadlec, 2004)

Implementace Dodání

aplikace

Oprava chyb,

rozšiřování

Obrázek 8: Schéma modelu Stagewise Zdroj: Upraveno dle (Kadlec, 2004)

2.5.3 Vodopádový model

Vodopádový model vznikl v sedmdesátých letech s cílem klást větší důraz na způsob vedení vývoje softwaru. Hlavním rozdílem oproti předchozímu modelu a zároveň největším přínosem Vodopádového modelu je zakomponování zpětné vazby na konci každé fáze vývoje. Pokud po dokončení jednotlivých fází vývoje očekávaný stav neodpovídá žádoucímu, lze například upravit specifikaci, doladit návrh nebo zvolit jiné podmínky testů a podobně. Vodopádový model je všeobecně považován za vynikající výchozí bod pro vývoj softwaru. Je jednoduchý, lze snadno kontrolovat dosažený pokrok a umožňuje vracení se o krok zpět během vývoje. Což ilustruje obrázek 9.

Naopak ale existují i jeho nevýhody, například dlouhé dodací doby, určitá nepružnost modelu a způsob dodání systému najednou, kdy zákazník dlouhou dobu nevidí žádnou aktivitu a pak dostane hotový kompletní produkt. (Kadlec, 2004)

Definice problému

Specifikace požadavků

Návrh

Architektura

Implementace

Integrace

Provoz

Obrázek 9: Základní struktura vodopádového modelu Zdroj: Upraveno dle (Kadlec, 2004)

2.5.4 Spirálový model

Spirálový model vznikl v roce 1985 a dodnes věrně odráží skutečný životní cyklus širokého spektra systémů. Spirálový model byl reakcí na některé nedostatky vodopádového modelu. A to použitím iterativního přístupu a důslednou analýzou rizik. Dále také určuje jinou posloupnost jednotlivých fází projektu. Idea je, že na začátku projektu je složité načrtnout podrobné specifikace požadavků a jednotlivé funkce, a tudíž by se měl stanovit pouze obecný rámec. A posléze se vyvine část systému, který se dále po vytvoření prokonzultuje se zákazníkem a ten poté dodá zpětnou vazbu, podle které se doplní podrobnější specifikace. To znamená, že vývoj probíhá v opakovaných krocích jinak zvaných iteracích. Na svoji dobu to byla revoluční koncepce a zcela změnila chápání životního cyklu. (Kadlec, 2004)

Jednotlivé kroky během vývoje softwaru ve spirálovém modelu jsou popsány obrázkem 10.

Definice problému

Specifikace požadavků

Návrh

Architektura

Implementace

Integrace

Provoz

Obrázek 10: Schéma spirálového modelu životního cyklu

Zdroj: Diagnostika a testování elektronických systémů [online]. [cit. 2019-02-26]. Dostupné z:

http://www.umel.feec.vutbr.cz/bdts/index.php/embedded-systemy/vyvojove-modely

2.5.5 Agilní metodiky

Agilní metodiky se vyznačují podstatně menší měrou formálnosti oproti klasickým metodikám. Agilní metodiky se soustředí hlavně na spolupráci, komunikaci a připravenost na změnu. Jde o to, aby pracovní tým byl pokud možno co nejvíce produktivní a efektivní a aby výsledný produkt byl dodán v prvotřídní kvalitě a v co nejkratším čase. Cílem agilních metodik není nějaký produkt, ale hodnota zákazníka neboli jeho spokojenost.

(Šochová, 2014, s. 13)

U agilního vývoje neexistuje žádný přesně definovaný postup nebo model, kterého by se vývojáři měli nebo museli striktně držet. Spíše se jedná o způsob myšlení a řešení problémů. Myšlenku agilního vývoje softwaru přibližuje následující manifest (Agilemanifesto, 2001):

 Jednotlivci a interakce před procesy a nástroji

 Fungující software před vyčerpávající dokumentací

 Spolupráce se zákazníkem před vyjednáváním o smlouvě

 Reagování na změny před dodržováním plánu

Při vývoji softwaru je složité odhadnout čas a náklady pro vytvoření aplikace. Obvykle také dochází ke změně zadání ze strany zákazníka, protože sám na začátku ani neví, co chce.

Lean metoda

Lean metoda je založena na omezování rozdělané práce, to znamená, že v danou chvíli se pracuje jen na tom, co je přesně známé a definované. Jedná se o převedení „systému tahu“

do vývoje informačních technologií. Takzvaně přestat vyrábět na sklad, ale až tehdy, když je to potřeba. Podle základních doporučení by se nemělo pracovat na něčem, co se později ani nepoužije, tento čas by měl být využit efektivněji. Zpětná vazba by se měla zjišťovat již během vývoje, aby se předešlo časovým ztrátám po dokončení vývoje a možnému předělávání aplikace. Čím později padne rozhodnutí, tím více informací bude do té doby možno získat. Dále může pomoct delegování zodpovědnosti na jednotlivé členy týmu, což povede k jejich většímu zapojení a též i motivaci na rozdíl od klasických topdown firemních struktur. (Šochová, 2014, s. 18-19)

2.5.6 Další modely vývoje softwaru

Jedná se o různé modely, které vycházejí z vodopádového modelu a snaží se odstranit jeho nedostatky. (Kadlec, 2004)

 Test Development – vodopádový model je rozšířen na konci každé fáze o specifikaci a provádění testů

 Exploratory Programming – předchůdce iterativního přístupu spočívá ve vyvinutí pouze základní kostry podle základních požadavků, které se poté rozšiřují o konkrétní připomínky a specifičtější požadavky zákazníků

 Prototyping Model – vodopádový model kde se nejdříve vytvoří prototyp systému

 Evolutionary/Incremental Model – Evoluční či Inkrementální model je předchůdcem iterativního programování