The spirálový vzor je to archetyp procesu vývoje aplikace. Je založen na hypotéze, že vývoj softwaru je iterační cyklus, který se opakuje, dokud není dosaženo stanovených cílů. Má schopnost zvládnout velké množství rizik, která by mohla nastat při vývoji jakéhokoli softwaru.
Jedná se o jeden z nejdůležitějších modelů na podporu řízení rizik. Jak název napovídá, tento model je zobrazen jako spirálovitý, kde jsou různé fáze modelu distribuovány v různých cyklech. Počet cyklů v modelu není pevný a může se u jednotlivých projektů lišit.
Rejstřík článků
Spirálový model definoval americký matematik a profesor softwarového inženýrství Barry Boehm. Poté, co v roce 1986 představil svůj koncept vývoje komplexních aplikací, publikoval svůj model v roce 1988 v komplexnějším rámci ve svém článku „Spirálový model vývoje a zlepšování softwaru".
Část této publikace z roku 1988 graficky znázornila spirálový model, který plně ukazuje, jak proces vývoje softwaru vypadá spirálovitě a je podporován cykly..
Boehm je známý svými četnými příspěvky do softwarového inženýrství, jako je model konstruktivních nákladů (COCOMO), spirálový model softwarového procesu, přístup G-Theory (win-win) k určování a správě požadavků..
Ve své publikaci Boehm popsal spirálový model jako možnou alternativu k dříve zavedenému modelu vodopádu, který také sloužil jako základ pro jeho praxi..
Spirálový model nebyl první, kdo diskutoval o cyklickém vývoji, ale jako první vysvětlil, proč je iterace důležitá. Jak se původně předpokládalo, byla zaměřena na velké a složité projekty, jejichž iterace se obvykle pohybují od 6 měsíců do 2 let..
Tento model nepředpokládá, že úlohy vývoje softwaru jsou navrženy lineárně, na rozdíl od modelu vodopádu, ale vidí je jako iterativní úlohy.
Tento cyklický model ovlivňoval modelovou architekturu softwarového inženýrství (MBASE) a extrémní programování.
Tím, co tento model výrazně odlišuje od ostatních modelů softwarových procesů, je to, že výslovně uznává rizika. Výrazně tak snižuje selhání velkých softwarových projektů opakovaným hodnocením rizik a pokaždé ověřováním vyvíjeného produktu..
Tento počítačový model obsahuje komponenty téměř jakéhokoli jiného modelu životního cyklu softwaru, například model vodopádu, prototypový model, iterativní model, evoluční model atd..
Z tohoto důvodu je schopen zvládnout téměř jakýkoli typ rizika, které jiné modely obecně nezvládají. Vzhledem k tomu, že má tolik komponent, je tento model mnohem složitější než ostatní modely vývoje softwaru..
Každé otočení spirály představuje kompletní cyklus, kterým vždy procházejí čtyři kvadranty, představující čtyři fáze modelu..
Jak se zvětšuje velikost spirály, zvyšuje se i dosažený pokrok. Fáze se proto neprovádějí jen jednou, ale několikrát ve formě spirály..
Ačkoli toto cyklické opakování způsobí, že se projekt pomalu přibližuje k stanoveným cílům, riziko selhání vývojového procesu je silně minimalizováno..
Čtyři fáze provádějí pouze základní cíle cyklu, ale nemusí se projevovat v každém cyklu.
Pořadí každého cyklu také není přesně stanoveno. Proto lze model kdykoli kombinovat s jinými modely.
Je to docela flexibilní, protože procesy definování cílů, analýzy rizik, vývoje a plánování jsou prováděny samostatně pro každou fázi projektu..
Je považován za metamodel, protože zahrnuje ostatní modely. Například pokud by spirála byla jednoho cyklu, představovala by model vodopádu, protože zahrnuje postupný přístup tohoto klasického modelu.
Využívá také přístup prototypového modelu, protože na začátku každého cyklu sestavuje prototyp pro řízení rizik..
Kromě toho je kompatibilní s evolučním modelem, protože iterace spirály lze považovat za evoluční úrovně, jimiž je vytvořen konečný systém..
Systémové požadavky jsou definovány co nejpodrobněji, včetně výkonu, hardwarových / softwarových rozhraní, klíčových indikátorů úspěchu atd. a zvážit, které cíle by měly být spojeny s aktuálním vývojovým cyklem.
Kromě toho jsou zkoumány různé alternativy pro jeho implementaci, například build vs. nákup, opětovné použití stávajících komponent nebo outsourcing atd..
Podobně jsou stanovena omezení, jako jsou náklady, plán a rozhraní, spotřeba času atd..
Vyhodnocují se všechny navrhované alternativy. Cíle a omezení slouží jako určující odkazy k výběru nejlepšího řešení.
Kromě toho jsou identifikována rizika, která mohou bránit úspěchu projektu, jako je nedostatek zkušeností, nové technologie, omezené časové plány, nedostatečné procesy atd., Implementace nejvýnosnějších strategií s nejnižším rizikem..
Nakonec jsou použity metody jako prototypování, simulace, analytické modely a průzkumy uživatelů..
Provádí se veškerý potřebný vývoj s využitím zvolené technologie a řešení. S každou iterací se vytvoří lepší verze aplikace.
Skutečný kód je několikrát psán a testován, dokud není dosaženo požadovaného výsledku, který pak poslouží jako základ pro další vývojové kroky.
Po dokončení jednoho cyklu začíná plánování dalšího. Tímto plánováním by mohlo být normální pokračování projektu, pokud by bylo dosaženo cíle cyklu, s ohledem na definici dalšího cíle.
Může se také jednat o nalezení jiných řešení, pokud by se předchozí fáze vývoje ukázala chybná. Stávající strategii lze nahradit jednou z dříve definovaných alternativ nebo novou. Tím by byl zahájen nový pokus o dosažení daného cíle..
Armáda Spojených států přijala spirálový model pro vývoj a aktualizaci modernizačního programu Future Fighting Systems (SCF)..
Oficiálně zahájené v roce 2003 se předpokládalo, že SCF vybaví vojáky vozidly připojenými v reálném čase k mimořádně rychlé a flexibilní síti bojišť..
Projekt byl rozdělen na čtyři vývojové spirály, každá o délce asi dvou let. Spirála 1 měla začít v roce 2008 a měla dodávat prototypy pro použití a vyhodnocení..
Po dokončení Spirála 1 měl být Spirála 2 zahájena v roce 2010. Konečný vývoj produktu by měl být dodán v roce 2015..
V srpnu 2005 společnost Boeing oznámila dokončení prvního významného milníku projektu, kterým byla funkční revize systémů. Spoluvedoucími projektu byli společnosti Boeing a Science Applications International Corporation.
Pro říjen 2005 však Pentagon doporučil odložit projekt kvůli vysokému dopadu na náklady z války v Iráku a pomoci hurikánu Katrina..
Projekt byl zrušen v roce 2009 poté, co se objevily škrty v rozpočtu, aniž by bylo možné prokázat výhody spirálového modelu v této misi.
Díky tomuto typu konstrukce jsou díky pravidelným kontrolám mlčky eliminovány problémy mezi designem a technickými požadavky softwaru..
Před dalším postupem jsou rizika analyzována v každé fázi produktu. To pomáhá překonat nebo zmírnit potenciální rizika.
Všichni zaměstnanci těží z velkého významu analýzy rizik v tomto modelu, což může představovat jejich největší výhodu oproti jiným procesním modelům.
Pravidelné hodnocení rizik získává hodnotu při používání nových technických prostředí, která jsou obecně spojena s určitým rizikovým potenciálem kvůli absenci empirických hodnot.
Zákazníci jsou zapojeni do každé fáze projektu, dokud není projekt dokončen. Proto je možné shromáždit různé zpětné vazby ke zlepšení další verze projektu..
Zpětnou vazbu lze navíc získat kdykoli díky postupu spirály. Zákazníci a uživatelé tak mohou být od začátku integrováni do procesu vývoje.
Je obzvláště populární a prominentní pro velké a složité projekty, kde je kontrola rozpočtu prioritou pro klienty a vývojáře. Máte maximální kontrolu nad náklady, zdroji a kvalitou softwarového projektu.
Může to být docela nákladné, protože vyžaduje vysokou úroveň odborných znalostí pro analýzu rizik. Vývoj projektů navíc trvá značné množství času, což může zvýšit režii.
Je vyžadováno velmi aktivní a komplexní předchozí řízení projektu, kde je každý cyklus průběžně a pečlivě kontrolován a dokumentován.
Je to poměrně složitější než u jiných modelů, protože existuje mnoho cyklů, z nichž každý prochází různými fázemi, což zvyšuje úsilí procesu dokumentace..
Znalosti o analýze a řízení rizik, které často nejsou k dispozici, jsou zásadní.
Řízení času je obtížné, protože počet cyklů není znám. Proces vývoje lze navíc kdykoli odložit, pokud je třeba učinit důležitá rozhodnutí v rámci cyklu nebo pomocí dalších akcí při plánování dalšího cyklu..
Není vždy výhodné provádět mnoho kroků ve vývoji softwaru, protože i přes všestrannost testů mohou nedokončené části programu dosáhnout hotového systému..
V důsledku toho vždy existuje nebezpečí, že jakákoli chyba nebo koncepční nekonzistence ovlivní konečný produkt..
Zatím žádné komentáře