Tito. vychází se z předpokladu, že každá práce bude provedena tak důkladně, že po jejím dokončení a dokončení dalšího kroku nebude potřeba se vracet k předchozímu.
Vývojář zkontroluje mezivýsledek pomocí různých známých ověřovacích metod a zaznamená jej jako hotový standard pro další proces.
Podle tohoto modelu životního cyklu se práce a úkoly vývojového procesu obvykle provádějí postupně, jak je znázorněno na diagramu. Paralelně s vývojovým procesem se však obvykle provádějí pomocné a organizační procesy (kontrola požadavků, řízení kvality atd.). V tomto modelu je zajištěn návrat k původnímu procesu po údržbě a opravě chyb.
Zvláštností tohoto modelu je, že zachycuje sekvenční procesy vývoje softwarového produktu. Vychází z továrního modelu, kdy výrobek prochází etapami od koncepce po výrobu, poté je předán zákazníkovi jako hotový výrobek, jehož změna není zajištěna, i když výměna za jiný podobný výrobek je možná v případě reklamace nebo některá její část selhala.
Nevýhody tohoto modelu:
- proces tvorby PS ne vždy zapadá do tak rigidní formy a sledu akcí;
- nejsou zohledněny změněné potřeby uživatelů, změny vnějšího prostředí, které způsobí změny požadavků na systém při jeho vývoji;
- velká prodleva mezi časem, kdy byla chyba zavedena (například ve fázi návrhu) a časem, kdy byla zjištěna (během údržby), což vede k rozsáhlému přepracování softwaru.
Při použití kaskádového modelu se mohou vyskytnout následující rizikové faktory:
- požadavky na software nejsou jasně formulovány nebo neberou v úvahu vyhlídky vývoje OS, prostředí atd.;
- velký systém, který neumožňuje rozklad komponent, může způsobit problémy s jejich umístěním do paměti nebo na platformy, které nejsou uvedeny v požadavcích;
- rychlé změny v technologii a požadavcích mohou zhoršit proces vývoje jednotlivých částí systému nebo systému jako celku;
- omezení zdrojů (lidských, softwarových, technických atd.) při vývoji může zúžit jednotlivé možnosti implementace systému;
výsledný produkt může být nepoužitelný z důvodu nepochopení požadavků či funkcí systému vývojáři nebo z důvodu nedostatečného testování. Výhody implementace systému pomocí kaskádového modelu jsou následující:
- všechny úkoly subsystémů a systému jsou implementovány současně (tj. není zapomenut ani jeden úkol), což přispívá k vytvoření stabilních vazeb a vztahů mezi nimi;
- plně vyvinutý systém s dokumentací se snadněji udržuje, testuje, opravuje chyby a provádí změny ne náhodně, ale cíleně, počínaje požadavky (například přidáním nebo nahrazením některých funkcí) a opakováním procesu.
Kaskádový model lze považovat za model životního cyklu vhodný pro vytvoření první verze softwaru za účelem testování funkcí v něm implementovaných. Při údržbě a provozu může dojít k odhalení různých typů chyb, jejichž náprava bude vyžadovat opakování všech procesů, počínaje vyjasněním požadavků.
2.2.2. Inkrementální model životního cyklu
První vytvořená přechodná verze systému (vydání 1) implementuje část požadavků, další požadavky jsou přidány do následující verze (vydání 2) a tak dále, dokud nejsou všechny požadavky konečně splněny a problémy s vývojem systému vyřešeny. U každé meziverze jsou ve fázích životního cyklu prováděny potřebné procesy, práce a úkoly, včetně analýzy požadavků a vytvoření nové architektury, kterou lze provádět současně.
Procesy vývoje technického návrhu PS, jeho programování a testování, montáže a kvalifikační zkoušky PS jsou prováděny při tvorbě každé další verze.
V souladu s tímto modelem životního cyklu, jehož procesy jsou téměř stejné jako u vodopádového modelu, je kladen důraz na vývoj nějaké kompletní přechodné verze a úkoly vývojového procesu jsou prováděny postupně nebo částečně paralelně po dobu počet jednotlivých struktur střední verze.
Práce a úkoly vývojového procesu pro další verzi systému s dalšími požadavky nebo funkcemi lze provádět opakovaně ve stejném pořadí pro všechny meziverze systému. Procesy údržby a provozu mohou být implementovány souběžně s procesem vývoje verze kontrolou částečně implementovaných požadavků v každé přechodné verzi a tak dále, dokud není získána kompletní verze systému. Podpůrné a organizační procesy životního cyklu jsou obvykle prováděny souběžně s procesem vývoje verze systému a do konce vývoje budou shromážděna data, na jejichž základě lze stanovit úroveň úplnosti a kvality vyráběného systému.
Při použití tohoto modelu je třeba vzít v úvahu následující rizikové faktory:
- požadavky jsou vypracovány s přihlédnutím k možnosti jejich změny v průběhu prodeje produktu;
- všechny schopnosti systému musí být implementovány od začátku;
- rychlé změny v technologii a požadavcích na systém mohou vést k narušení výsledné struktury systému;
- Omezení v poskytování zdrojů (výkonní pracovníci, finance) mohou vést ke zpoždění při uvádění systému do provozu.
Tento model životního cyklu je vhodné použít v případech, kdy:
- je žádoucí rychle implementovat některé funkce systému vytvořením přechodné verze produktu;
- systém je rozložen na samostatné komponenty, které mohou být prodávány jako nějaké nezávislé meziprodukty nebo hotové výrobky;
- je možné navýšit finanční prostředky na rozvoj jednotlivých částí systému.
Někdy lidé jasně nerozlišují mezi prací projektového řízení a prací životního cyklu projektu, protože oba typy práce jsou nezbytné pro úspěšné dokončení projektu. Hlavním rozdílem mezi těmito dvěma je, že projektové řízení se zaměřuje na definování, plánování, monitorování a kontrolu a uzavření projektu. Práce spojená s vlastní tvorbou výsledků dodávky projektu se obvykle nazývá „životní cyklus“ projektu. V procesu projektového řízení vzniká projektový harmonogram, ale převážnou většinu práce v tomto harmonogramu tvoří práce životního cyklu projektu, v jehož důsledku se objevují výstupní produkty.
Zatímco všechny projekty jsou jedinečné, stejně jako existují obecné procesy řízení, které se vztahují na většinu projektů, existují také obecné modely, které mohou sloužit jako vodítka pro definování životního cyklu většiny projektů. Tyto obecné modely jsou cenné, protože šetří projektovým týmům čas při vytváření harmonogramu projektu.
Příkladem jednoho z modelů životního cyklu je běžný klasický model „vodopádu“. Tento model představuje základní přístup, který lze aplikovat na jakýkoli projekt. Více často než ne, začnete pochopením požadavků na výstup projektu, poté navrhnete výstup, vytvoříte a otestujete výstup a skončíte implementací produktu. Každá z těchto oblastí zaměření se nazývá fáze (fáze analýzy, fáze návrhu, fáze implementace atd.). Klasický vodopádový přístup je model životního cyklu, který pravděpodobně můžete použít, aniž byste věděli cokoli o metodologii a plánovali projekt od začátku.
Co by mohlo být jednodušší? I když máte velmi malý projekt, stále procházíte těmito základními kroky, alespoň některé z nich děláte ve své hlavě. Pokud máte například 40hodinový (jeden pracovní týden) projekt na vývoj nebo vylepšení dokumentu, může se zdát, že spěcháte přímo do fáze Implementace. Ale je to tak? S největší pravděpodobností jste dostali nějaký druh zadání s požadavky nebo přáními, které bude třeba pochopit (Analýza) a převést je do plánu budoucího obsahu (Design). Poté nápad implementujete (Implementace), zkontrolujete výsledek (Testování) a předáte k použití (Implementace).
Schéma vodopádu (kaskády) zahrnuje několik důležitých operací, které platí pro všechny projekty:
* vypracování akčního plánu rozvoje systému;
* plánování práce spojené s každou akcí;
* aplikace provozu sledování průběhu akcí s kontrolními stupni.
Grafické znázornění „modelu vodopádu“ projektového cyklu
Obrázek.3 Vodopádový model životního cyklu projektu
Výhody modelu vodopádu (kaskády).
Vodopádový model má výhody při použití v projektu, pro který je vhodný.
A. Tento model je dobře známý spotřebitelům, kteří se nepodílejí na vývoji a provozu programů, a koncovým uživatelům.
b. Zabývá se složitostí uspořádaným způsobem a funguje dobře pro projekty, které jsou poměrně srozumitelné, ale stále obtížně řešitelné.
C. Je snadné to pochopit, protože cíl je jednoduchý - dokončit potřebné akce.
d. Je jednoduchý a snadno se používá, protože proces vývoje probíhá po etapách.
E. Vyznačuje se stálostí požadavků.
F. Poskytuje šablonu, do které lze umístit metody pro provádění analýzy, návrhu, kódování, testování a zajišťování.
G. Umožňuje účastníkům projektu, kteří dokončili aktivity ve fázi, kterou vykonávají, podílet se na realizaci jiných projektů.
h. Definuje postupy kontroly kvality. Všechna přijatá data jsou zkontrolována. Tento postup používá vývojový tým k určení kvality systému.
i. Postup projektu lze snadno sledovat pomocí časové osy (Ganttův diagram), protože bod, ve kterém je každá fáze dokončena, se používá jako fáze.
Nevýhody kaskádového modelu.
Při použití vodopádového modelu pro projekt, který je pro něj stěží vhodný, se objevují následující nevýhody:
A. Model je založen na sekvenční lineární struktuře a v důsledku toho pokus o návrat o jednu nebo dvě fáze zpět k nápravě problému nebo nedostatku povede k výraznému zvýšení nákladů a narušení harmonogramu.
b. Ne vždy má klient možnost se se systémem předem seznámit, děje se tak až na samém konci životního cyklu.
C. Klient nemá možnost těžit z průběžných výsledků a zpětnou vazbu od uživatelů nelze předat zpět vývojářům. Vzhledem k tomu, že hotový produkt není k dispozici až do konce procesu, je uživatel zapojen do procesu pouze na začátku – při shromažďování požadavků a na konci při akceptačních testech.
d. Každá fáze je nezbytným předpokladem pro následné akce, což z této metody činí riskantní volbu pro bezkonkurenční systémy, protože není vhodná pro flexibilní modelování.
E. Pro každou fázi se vytvoří výstupní data, která se po dokončení považují za zmrazená. To znamená, že by se během následujících fází životního cyklu produktu neměly měnit. Pokud se změní datový prvek dodávky etapy, bude projekt negativně ovlivněn změnou plánu, protože ani model, ani plán nebyly navrženy tak, aby vyhovovaly a řešily změnu později v životním cyklu.
F. Všechny požadavky by měly být známy na začátku životního cyklu, ale klienti nemusí být v tomto bodě vývoje vždy schopni formulovat všechny jasně definované požadavky.
Zatímco vodopád je univerzální a lze jej použít na jakýkoli projekt, jiné modely životního cyklu mohou být efektivnější a efektivnější v závislosti na vlastnostech projektu. Pokud například nainstalujete softwarový balíček, přeskočíte fáze návrhu a implementace. Podobně, pokud děláte vývojovou práci, možná budete chtít použít konkrétní model životního cyklu projektu výzkumu a vývoje, který bere v úvahu, že provedená práce nebo její část může skončit v koši. Pro urychlení určitých typů projektů lze použít další důležité modely životního cyklu. Projekty informačních technologií například často využívají iterativní nebo rychlý (agilní) vývoj.
Níže jsou uvedeny některé další modely životního cyklu projektu:
Iterativní přístup(anglická iterace - opakování) - provádění práce souběžně s průběžnou analýzou získaných výsledků a úpravou předchozích etap práce. S tímto přístupem prochází projekt v každé fázi vývoje opakujícím se cyklem: Plánování – Implementace – Kontrola – Hodnocení (cyklus plánujte – provádějte – kontrolujte – jednajte).
Výhody iterativního přístupu:
1. snížení dopadu závažných rizik v raných fázích projektu, což vede k minimalizaci nákladů na jejich odstranění;
2. organizování efektivní zpětné vazby od projektového týmu spotřebiteli (stejně jako zákazníkům, zainteresovaným stranám) a vytváření produktu, který skutečně odpovídá jejich potřebám;
3. zaměření úsilí na nejdůležitější a kritické oblasti projektu;
4. průběžné iterativní testování, které nám umožňuje hodnotit úspěšnost celého projektu jako celku;
5. včasné odhalení konfliktů mezi požadavky, modely a 6. realizací projektu;
8. efektivní využití nashromážděných zkušeností;
9. reálné zhodnocení aktuálního stavu projektu a v důsledku toho větší 10. důvěru zákazníků a přímých účastníků v jeho úspěšné dokončení.
Model životního cyklu spirálového projektu. Tento model zkoumá závislost efektivity projektu na jeho nákladech v čase. Při každém otočení spirály se vytvoří další verze produktu, upřesní se požadavky projektu, určí se jeho kvalita a naplánuje se práce na další zatáčku.
Spirální model poprvé formuloval Barry Boehm v roce 1988. Charakteristickým rysem tohoto modelu je zvláštní pozornost k rizikům ovlivňujícím organizaci životního cyklu. Boehm formuluje „top 10“ nejběžnějších (podle priority) rizik
1. Nedostatek specialistů.
2. Nereálné termíny a rozpočet.
3. Implementace nevhodné funkcionality.
4. Návrh nesprávného uživatelského rozhraní.
5. „Zlaté prostírání“, perfekcionismus, zbytečná optimalizace a pilování detailů.
6. Neustálý proud změn.
7. Nedostatek informací o externích komponentách, které definují prostředí systému nebo se podílejí na integraci.
8. Nevýhody v práci vykonávané externími (ve vztahu k projektu) zdroji.
9. Nedostatečný výkon výsledného systému.
10. „Mezera“ v kvalifikaci specialistů v různých oblastech znalostí.
Většina těchto rizik je spojena s organizačními a procesními aspekty interakce mezi specialisty v projektovém týmu.
Každé otočení spirály odpovídá vytvoření fragmentu nebo verze softwaru, kde jsou vyjasněny cíle a charakteristiky projektu, stanovena jeho kvalita a naplánována práce na dalším otočení spirály. Tím se prohloubí a důsledně upřesní detaily projektu a ve výsledku se vybere rozumná varianta, která se přivede k realizaci. Každé kolo je rozděleno do 4 sektorů:
posouzení a řešení rizik,
definování cílů,
vývoj a testování,
plánování.
Spirálový model je zaměřen na velké, drahé a složité projekty.
Výhody spirálového modelu:
Při použití spirálového modelu na projektu, pro který se dobře hodí, vznikají následující výhody:
a Spirálový model umožňuje uživatelům „vidět“ systém včas pomocí rychlého prototypování v životním cyklu vývoje projektu.
b Umožňuje identifikaci nepřekonatelných rizik při nízkých nákladech.
c Model umožňuje uživatelům aktivně se podílet na plánování, analýze rizik, návrhu a hodnocení.
d Zajišťuje, že velké potenciální množství práce na vývoji produktu je rozděleno na malé kousky.
e Model umožňuje flexibilní návrh, protože zachycuje výhody vodopádového modelu a zároveň umožňuje iteraci napříč všemi fázemi stejného modelu.
f Výhody inkrementálního modelu jsou realizovány, jmenovitě uvolňování inkrementů, redukce plánu překrývajícími se inkrementy a neměnnost zdrojů, jak systém postupně roste.
Nevýhody spirálového modelu:
Při použití spirálového modelu na projektu, pro který není vhodný, se objevují následující nevýhody:
a Spirála může pokračovat donekonečna.
b Velký počet mezistupňů může vést k nutnosti zpracovávat interní doplňkovou a externí dokumentaci.
c Používání modelu se může prodražit, protože čas strávený plánováním, předefinováním cílů, analýzou rizik a vytvářením prototypů může být nadměrný.
Inkrementální model projektového cyklu. Tento model se ve většině případů používá při provádění komplexních vývojových prací, které vyžadují velký počet účastníků a mnoho různých problémů, které je třeba vyřešit. Jeho podstata spočívá v rozložení velkého množství práce na posloupnost menších součástek. Jde o proces částečné implementace celého systému a pomalého zvyšování funkčnosti či efektivity.
Tento model zahrnuje rozdělení životního cyklu projektu do posloupnosti iterací, z nichž každá připomíná „miniprojekt“, včetně všech fází životního cyklu, jak je aplikováno na vytváření menších částí funkčnosti ve srovnání s projektem jako celkem. Cílem každé iterace je získat pracovní verzi softwarového systému, která zahrnuje funkcionalitu definovanou integrovaným obsahem všech předchozích a současných iterací. Výsledky konečné iterace obsahují všechny požadované funkce produktu.
Výhody inkrementálního modelu.
Použitím přírůstkového modelu při vývoji projektu, pro který je dostatečně vhodný, se můžete přesvědčit o následujících výhodách:
a Není potřeba utrácet peníze předem na vývoj celého projektu.
b Výsledkem každého přírůstku je získání funkčního produktu.
c Použití přírůstkových přírůstků umožňuje zkombinovat uživatelské zkušenosti do vylepšeného produktu za zlomek nákladů na nový vývoj.
d Pravidlo rozděl a panuj vám umožňuje rozdělit problém na zvládnutelné části, což vývojovému týmu brání ve vytváření těžkopádných seznamů požadavků.
e Během procesu vývoje můžete omezit počet zaměstnanců tak, aby stejný tým konzistentně pracoval na dodání každého přírůstku.
f Na konci každé přírůstkové dodávky je možnost přehodnotit rizika spojená s náklady a dodržováním stanoveného harmonogramu.
g Protože přechod ze současnosti do budoucnosti neproběhne okamžitě, může si zákazník na novou technologii zvyknout postupně.
h Riziko je rozloženo do několika menších přírůstků a není soustředěno do jednoho velkého developerského projektu.
Nevýhody inkrementálního modelu.
Při použití tohoto modelu ve vztahu k projektu, pro který není dostatečně vhodný, se objevují následující nevýhody:
a Model neumožňuje iterace v rámci každého přírůstku.
b Definice kompletního funkčního systému by měla být provedena na začátku životního cyklu, aby bylo zajištěno, že bude možné identifikovat přírůstky.
c Klient si musí být vědom toho, že celkové náklady na dokončení projektu nebudou sníženy.
Standardy životního cyklu softwaru
- GOST 34.601-90
- ISO/IEC 12207:1995 (ruský ekvivalent - GOST R ISO/IEC 12207-99)
Metodiky vývoje softwaru
- Rational Unified Process (RUP).
- Microsoft Solutions Framework (MSF). Zahrnuje 4 fáze: analýza, návrh, vývoj, stabilizace, zahrnuje použití objektově orientovaného modelování.
- Extrémní programování ( Extrémní programování, XP). Metodika je založena na týmové práci a efektivní komunikaci mezi zákazníkem a zhotovitelem v průběhu celého projektu vývoje IP. Vývoj probíhá pomocí postupně zdokonalovaných prototypů.
Norma GOST 34.601-90
Norma GOST 34.601-90 poskytuje následující fáze a fáze vytváření automatizovaného systému:
- Formování požadavků na mluvčí
- Kontrola zařízení a zdůvodnění potřeby vytvoření jaderné elektrárny
- Formování požadavků uživatelů na reproduktory
- Vypracování zprávy o ukončení prací a žádosti o výstavbu JE
- Vývoj koncepce AC
- Studium objektu
- Provádění nezbytných výzkumných prací
- Vývoj možností pro koncepci AC a výběr varianty pro koncepci AC, která splňuje požadavky uživatele
- Vypracování protokolu o provedené práci
- Technický úkol
- Vývoj a schvalování technických specifikací pro výstavbu jaderných elektráren
- Předběžný návrh
- Vývoj předběžných konstrukčních řešení systému a jeho částí
- Technický projekt
- Vývoj konstrukčních řešení systému a jeho částí
- Vypracování dokumentace pro reproduktorový systém a jeho části
- Vypracování a zpracování dokumentace pro dodávky komponentů
- Vypracování konstrukčních úkolů v navazujících částech projektu
- Pracovní dokumentace
- Vypracování pracovní dokumentace pro JE a její části
- Vývoj a adaptace programů
- Uvedení do provozu
- Příprava objektu automatizace
- Školení personálu
- Kompletní sada reproduktorů s dodávanými produkty (software a hardware, softwarové a hardwarové systémy, informační produkty)
- Stavební a instalační práce
- Uvedení do provozu
- Provádění předběžných testů
- Provádění zkušebního provozu
- Provádění akceptačních zkoušek
- AC podpora.
- Provádění prací v souladu se záručními povinnostmi
- Pozáruční servis
Skica, technické návrhy a pracovní dokumentace jsou důslednou konstrukcí stále přesnějších konstrukčních řešení. Je možné vyloučit fázi „Návrh skici“ a jednotlivé fáze práce ve všech fázích, spojit fáze „Technický návrh“ a „Pracovní dokumentace“ do „Technického podrobného návrhu“, provádět různé fáze a pracovat paralelně. a zahrnout další.
Tento standard není zcela vhodný pro současný vývoj: mnoho procesů není dostatečně zohledněno a některá ustanovení jsou zastaralá.
Norma ISO/IEC 12207/ a její aplikace
Norma ISO/IEC 12207:1995 „Informační technologie – Procesy životního cyklu softwaru“ je hlavním regulačním dokumentem upravujícím složení procesů životního cyklu softwaru. Definuje strukturu životního cyklu obsahující procesy, činnosti a úkoly, které musí být dokončeny při tvorbě softwaru.
Každý proces je rozdělen na sadu akcí, každá akce na sadu úkolů. Každý proces, činnost nebo úkol je podle potřeby iniciován a vykonáván jiným procesem a neexistují žádné předem určené sekvence provádění. Vazby mezi vstupními daty jsou zachovány.
Procesy životního cyklu softwaru
- Základní:
- Akvizice (akce a úkoly zákazníka nakupujícího software)
- Dodávka (úkony a úkoly dodavatele, který dodává zákazníkovi softwarový produkt nebo službu)
- Vývoj (akce a úkoly prováděné vývojářem: tvorba softwaru, příprava projektové a provozní dokumentace, příprava testovacích a školicích materiálů atd.)
- Provoz (činnosti a úkoly provozovatele - organizace provozující systém)
- Údržba (činnosti a úkoly prováděné doprovázející organizací, tedy podpůrnou službou). Podpora – provádění změn v softwaru za účelem opravy chyb, zvýšení produktivity nebo přizpůsobení změněným provozním podmínkám nebo požadavkům.
- Pomocný
- Dokumentace (formalizovaný popis informací vytvořených během životního cyklu softwaru)
- Správa konfigurace (aplikace administrativních a technických postupů v průběhu životního cyklu softwaru pro zjištění stavu softwarových komponent a správu jeho modifikací).
- Zajištění kvality (poskytování záruk, že informační systém a procesy jeho životního cyklu odpovídají stanoveným požadavkům a schváleným plánům)
- Ověření (určení, že softwarové produkty vyplývající z nějaké akce plně splňují požadavky nebo podmínky uložené předchozími akcemi)
- Certifikace (určující úplnost shody zadaných požadavků a vytvořeného systému s jejich konkrétním funkčním účelem)
- Společné hodnocení (posouzení stavu prací na projektu: kontrola plánování a řízení zdrojů, personálu, vybavení, nástrojů)
- Audit (určení souladu s požadavky, plány a smluvními podmínkami)
- Řešení problémů (analýza a řešení problémů, bez ohledu na jejich původ nebo zdroj, které se objeví během vývoje, provozu, údržby nebo jiných procesů)
- Organizační
- Kontrola (akce a úkoly, které může provádět kterákoli strana řídící její procesy)
- Vytvoření infrastruktury (výběr a údržba technologie, standardů a nástrojů, výběr a instalace hardwaru a softwaru sloužícího k vývoji, provozu nebo údržbě softwaru)
- Zlepšení (posuzování, měření, kontrola a zlepšování procesů životního cyklu)
- Školení (úvodní školení a následný průběžný rozvoj zaměstnanců)
Každý proces zahrnuje řadu akcí. Akviziční proces zahrnuje například následující činnosti:
- Zahájení akvizice
- Příprava nabídek
- Příprava a úprava smlouvy
- Dohled nad dodavatelskou činností
- Převzetí a dokončení práce
Každá aktivita obsahuje řadu úkolů. Například příprava nabídek by měla zahrnovat:
- Tvorba systémových požadavků
- Generování seznamu softwarových produktů
- Stanovení podmínek a dohod
- Popis technických omezení (operační prostředí systému atd.)
Fáze životního cyklu softwaru, vztahy mezi procesy a fázemi
Model životního cyklu softwaru- struktura, která určuje posloupnost provádění a vztahy mezi procesy, akcemi a úkoly v průběhu životního cyklu. Model životního cyklu závisí na specifikách, rozsahu a složitosti projektu a konkrétních podmínkách, ve kterých systém vzniká a funguje.
Norma GOST R ISO/IEC 12207-99 nenabízí konkrétní model životního cyklu. Jeho ustanovení jsou společná pro všechny modely životního cyklu, metody a technologie pro vytváření IP. Popisuje strukturu procesů životního cyklu, aniž by specifikoval, jak implementovat nebo dokončit činnosti a úkoly zahrnuté v těchto procesech.
Model životního cyklu softwaru zahrnuje:
- Pódia;
- Výsledky práce v každé fázi;
- Klíčové události jsou body dokončení práce a rozhodování.
Etapa- část procesu tvorby softwaru, omezená určitým časovým rámcem a končící vydáním konkrétního produktu (modely, softwarové komponenty, dokumentace), určená požadavky specifikovanými pro tuto etapu.
V každé fázi lze provést několik procesů definovaných v normě GOST R ISO/IEC 12207-99 a naopak stejný proces lze provést v různých fázích. Vztah mezi procesy a fázemi je také určen použitým modelem životního cyklu softwaru.
Modely životního cyklu softwaru
Model životního cyklu je struktura, která definuje posloupnost provádění a vztahy procesů, akcí a úkolů prováděných v průběhu životního cyklu. Model životního cyklu závisí na specifikách informačního systému a konkrétních podmínkách, ve kterých je informační systém vytvářen a provozován
K dnešnímu dni se nejvíce rozšířily následující hlavní modely životního cyklu:
- Problémový model;
- kaskádový model (nebo systém) (70-85);
- spirálový model (současnost).
Problémový model
Při vývoji systému „zdola“ od jednotlivých úloh až po celý systém (model úloh) se nevyhnutelně ztrácí jednotný přístup k vývoji a vznikají problémy v informačním propojení jednotlivých komponent. S narůstajícím počtem úloh se zpravidla zvyšují obtíže a je nutné neustále měnit stávající programy a datové struktury. Rychlost vývoje systému se zpomaluje, což zpomaluje vývoj samotné organizace. V některých případech však může být tato technologie vhodná:
- Krajní naléhavost (problémy se musí nějak vyřešit, pak se bude muset vše dělat znovu);
- Experiment a přizpůsobení zákazníka (algoritmy nejsou jasné, řešení se nalézají metodou pokus-omyl).
Obecným závěrem je, že tímto způsobem nelze vytvořit dostatečně velký, efektivní informační systém.
Kaskádový model
Kaskádový modelživotní cyklus navrhl v roce 1970 Winston Royce. Zajišťuje postupnou realizaci všech fází projektu v přesně stanoveném pořadí. Přechod do další fáze znamená úplné dokončení práce v předchozí fázi (obr. 1). Požadavky stanovené ve fázi tvorby požadavků jsou přísně dokumentovány formou technických specifikací a jsou evidovány po celý vývoj projektu. Každá fáze vyvrcholí vydáním kompletní sady dokumentace dostatečné k tomu, aby ve vývoji mohl pokračovat další vývojový tým.
Pozitivní aspekty použití kaskádového přístupu jsou následující:
- v každé fázi je generována kompletní sada projektové dokumentace, která splňuje kritéria úplnosti a konzistence;
- etapy prací prováděné v logickém sledu umožňují naplánovat dobu dokončení všech prací a odpovídající náklady.
Fáze projektu podle vodopádového modelu:
- Tvorba požadavků;
- Design;
- Implementace;
- Testování;
- Implementace;
- Provoz a údržba.
Rýže. 1. Schéma kaskádového vývoje
Kaskádový přístup se dobře osvědčil při konstrukci informačních systémů, u kterých lze na samém počátku vývoje zcela přesně a kompletně formulovat všechny požadavky tak, aby vývojáři měli volnost je co nejlépe implementovat z technického hlediska. Pohled. Do této kategorie spadají komplexní výpočetní systémy, systémy v reálném čase a další podobné úlohy. V procesu používání tohoto přístupu však byla objevena řada jeho nedostatků způsobených především tím, že skutečný proces tvorby systémů nikdy zcela nezapadal do takto rigidního schématu. Během procesu tvorby byla neustálá potřeba vracet se k předchozím fázím a vyjasňovat nebo revidovat dříve učiněná rozhodnutí. V důsledku toho měl vlastní proces tvorby softwaru následující podobu (obr. 2):
Rýže. 2. Reálný proces vývoje softwaru pomocí vodopádového schématu
Hlavní nevýhodou kaskádového přístupu je značné zpoždění při získávání výsledků. Koordinace výsledků s uživateli probíhá pouze v bodech plánovaných po ukončení každé etapy prací, požadavky na informační systémy jsou „zmrazeny“ ve formě technických specifikací po celou dobu jeho vzniku. Uživatelé tak mohou vznášet své připomínky až po úplném dokončení práce na systému. Pokud jsou požadavky uvedeny nepřesně nebo se mění v průběhu dlouhé doby vývoje softwaru, uživatelé se dostávají do systému, který nevyhovuje jejich potřebám. Modely (funkční i informační) automatizovaného objektu mohou zastarat současně s jejich schválením. Podstata systematického přístupu k vývoji IS spočívá v jeho dekompozici (rozčlenění) na automatizované funkce: systém je rozdělen na funkční subsystémy, které se dále dělí na subfunkce, dále se dělí na úkoly a tak dále. Proces rozdělení pokračuje až ke konkrétním postupům. Automatizovaný systém si zároveň zachovává holistický pohled, ve kterém jsou všechny komponenty propojeny. Hlavní výhodou tohoto modelu je tedy jeho systematický vývoj a jeho hlavní nevýhodou je, že je pomalý a drahý.
Spirálový model
K překonání těchto problémů bylo navrženo spirálový modelživotního cyklu (obrázek 3), který byl vyvinut v polovině 80. let 20. století Barrym Boehmem. Vychází z počátečních fází životního cyklu: analýzy a návrhu. V těchto fázích se testuje proveditelnost technických řešení vytvářením prototypů.
Prototyp- komponenta operačního softwaru, která implementuje jednotlivé funkce a externí rozhraní. Každá iterace odpovídá vytvoření fragmentu nebo verze softwaru, při které se vyjasní cíle a charakteristiky projektu, posoudí se kvalita získaných výsledků a naplánuje se práce na další iteraci.
Každá iterace představuje úplný vývojový cyklus, jehož výsledkem je vydání interní nebo externí verze produktu (nebo podmnožiny konečného produktu), která se od iterace k iteraci vylepšuje, aby se stala kompletním systémem.
Každé otočení spirály odpovídá vytvoření fragmentu nebo verze softwaru, kde jsou vyjasněny cíle a charakteristiky projektu, stanovena jeho kvalita a naplánována práce na dalším otočení spirály. Dochází tak k prohloubení a důslednému upřesnění detailů projektu a ve výsledku je vybrána rozumná varianta, která je uvedena do realizace.
Vývoj po iteracích odráží objektivně existující spirálový cyklus vytváření systému. Neúplné dokončení práce v každé fázi vám umožňuje přejít do další fáze, aniž byste čekali na úplné dokončení práce v aktuální fázi. Pomocí metody iterativního vývoje lze chybějící práci dokončit v další iteraci. Hlavním úkolem je co nejrychleji ukázat uživatelům systému funkční produkt, a tím aktivovat proces vyjasňování a doplňování požadavků.
Hlavním problémem spirálového cyklu je určení okamžiku přechodu do další fáze. K jeho vyřešení je nutné zavést časová omezení pro každou fázi životního cyklu. Přechod probíhá podle plánu, i když nejsou dokončeny všechny plánované práce. Plán je sestaven na základě statistických údajů získaných v předchozích projektech a osobních zkušeností vývojářů.
Obrázek 3. Spirálový model životního cyklu IC
Jedním z možných přístupů k vývoji softwaru v rámci spirálového modelu životního cyklu je metodika RAD (Rapid Application Development), která se v poslední době rozšířila. Tento termín obvykle označuje proces vývoje softwaru obsahující 3 prvky:
- malý tým programátorů (od 2 do 10 lidí);
- krátký, ale pečlivě zpracovaný plán výroby (od 2 do 6 měsíců);
- opakující se cyklus, ve kterém vývojáři, jak se aplikace začíná utvářet, požadují a implementují do produktu požadavky získané prostřednictvím interakce se zákazníkem.
Životní cyklus softwaru podle metodiky RAD se skládá ze čtyř fází:
- fáze definování požadavků a analýzy;
- fáze návrhu;
- realizační fáze;
- realizační fáze.
Při každé iteraci se hodnotí:
- riziko překročení termínů projektu a nákladů;
- nutnost provést další iteraci;
- stupeň úplnosti a přesnosti pochopení systémových požadavků;
- proveditelnosti ukončení projektu.
Výhody iterativního přístupu:
- Iterativní vývoj výrazně zjednodušuje provádění změn v projektu, když se mění požadavky zákazníka.
- Při použití spirálového modelu jsou jednotlivé prvky informačního systému postupně integrovány do jediného celku. Při iterativním přístupu k integraci dochází prakticky nepřetržitě. Vzhledem k tomu, že integrace začíná s menším počtem prvků, dochází při její implementaci k mnohem menším problémům (podle některých odhadů při použití vodopádového modelu rozvoje tvoří integrace až 40 % všech nákladů na konci projektu).
- Iterativní vývoj poskytuje větší flexibilitu při řízení projektů, což umožňuje provádět taktické změny vyvíjeného produktu.
- Iterativní přístup zjednodušuje opětovné použití komponent (implementuje komponentový přístup k programování). Je totiž mnohem snazší identifikovat společné části projektu, když jsou již částečně vyvinuty, než se je snažit identifikovat na samém začátku projektu. Analýza návrhu po několika počátečních iteracích odhalí běžné, opakovaně použitelné součásti, které budou vylepšeny v následujících iteracích.
- Spirálový model umožňuje spolehlivější a stabilnější systém. Je to proto, že jak se systém vyvíjí, chyby a slabiny jsou odhalovány a opravovány při každé iteraci. Současně lze upravit kritické parametry účinnosti, což je v případě kaskádového modelu možné pouze před implementací systému.
- Iterativní přístup umožňuje zlepšit proces vývoje – analýza provedená na konci každé iterace nám umožňuje posoudit, co je třeba ve vývojové organizaci změnit a zlepšit to při další iteraci.
Kaskádová strategie (jednorázový průchod, vodopád nebo klasický model) implikuje lineární sled provádění fází tvorby informačního systému (obr. 3.1). Jinými slovy, přechod z jedné fáze do druhé nastává až po úplném dokončení práce na té současné.
Obr.3.1. Kaskádová strategie
Tento model se využívá při vývoji informačních systémů, na které lze již na začátku vývoje zcela přesně a kompletně formulovat všechny požadavky.
Výhody modelu:
V každé fázi je generována kompletní sada dokumentace, softwaru a hardwaru, která splňuje kritéria úplnosti a konzistence;
Fáze, prováděné v jasném pořadí, vám umožňují s jistotou naplánovat načasování práce a odpovídající zdroje (peněžní, materiální a lidské).
Nevýhody modelu:
Vlastní proces vývoje informačního systému málokdy zcela zapadá do takto rigidního schématu. To platí zejména pro vývoj atypických a inovativních systémů;
Na základě přesné formulace výchozích požadavků na informační systém. Ve skutečnosti jsou na začátku projektu požadavky zákazníka definovány pouze částečně;
Hlavní nevýhodou je, že výsledky vývoje jsou zákazníkovi k dispozici až na konci projektu. Pokud jsou požadavky uvedeny nepřesně nebo se během dlouhé doby vytváření IP mění, dostává zákazník systém, který nevyhovuje jeho potřebám.
3.3. Přírůstková strategie
Inkrementální strategie (anglicky: increment) znamená vývoj informačního systému s lineárním sledem fází, ale v několika inkrementech (verzích), tedy s plánovaným vylepšením produktu.
Obr.3.2. Přírůstková strategie
Na začátku práce na projektu jsou stanoveny všechny základní požadavky na systém, poté je vyvíjen ve formě sledu verzí. Každá verze je navíc kompletní a funkční produkt. První verze implementuje část plánovaných schopností, další verze implementuje další schopnosti a tak dále, dokud nebude dosaženo kompletního systému.
Tento model životního cyklu je typický pro vývoj komplexních a integrovaných systémů, u kterých existuje jasná vize (jak ze strany zákazníka, tak ze strany vývojáře), jaký by měl být konečný výsledek (informační systém). Vývoj verzí se provádí z různých důvodů:
Zákazník nemá možnost financovat celý nákladný projekt najednou;
Developerovi chybí potřebné zdroje k realizaci složitého projektu v krátké době;
Požadavky na postupnou implementaci a přijetí produktu koncovými uživateli. Implementace celého systému najednou může způsobit odmítnutí jeho uživatelů a pouze „zpomalit“ proces přechodu na nové technologie. Obrazně řečeno, mohou jednoduše „nestrávit velký kus, takže se musí nakrájet a rozdělit na části“.
Výhody A nedostatky Tato strategie je stejná jako ta klasická. Ale na rozdíl od klasické strategie může zákazník vidět výsledky dříve. Na základě výsledků vývoje a implementace první verze může mírně změnit požadavky na vývoj, upustit od něj nebo nabídnout vývoj pokročilejšího produktu s uzavřením nové smlouvy.
3.4. Spirálová strategie
Spirální strategie (evoluční nebo iterativní model, Barry Boehm, 1988) zahrnuje vývoj v řadě verzí, ale ne všechny požadavky jsou definovány na začátku projektu. Požadavky se zpřesňují s vývojem verzí.
Rýže. 3.3. Spirálová strategie
Tento model životního cyklu je typický pro vývoj inovativních (nestandardních) systémů. Zákazník a developer nemají na začátku práce na projektu jasnou vizi výsledného produktu (nelze jednoznačně definovat požadavky) ani stoprocentní důvěru v úspěšnou realizaci projektu (rizika jsou velmi vysoká). V tomto ohledu je rozhodnuto systém rozvíjet po částech s možností změny požadavků nebo odmítnutí jeho dalšího vývoje. Jak je patrné z obr. 3.3, vývoj projektu může být dokončen nejen po fázi implementace, ale také po fázi analýzy rizik.
Výhody modelu:
Umožňuje rychle ukázat uživatelům systému funkční produkt, čímž aktivuje proces vyjasňování a doplňování požadavků;
Umožňuje změny požadavků při vývoji informačního systému, což je typické pro většinu vývojů, včetně standardních;
Poskytuje větší flexibilitu při řízení projektů;
Umožňuje získat spolehlivější a stabilnější systém. Jak se systém vyvíjí, chyby a slabiny jsou odhalovány a opravovány při každé iteraci;
Umožňuje zlepšit proces vývoje - analýza provedená v každé iteraci vám umožní posoudit, co je třeba ve vývojové organizaci změnit, a zlepšit to v další iteraci;
Rizika zákazníků jsou snížena. Zákazník může dokončit vývoj neperspektivního projektu s minimálními finančními ztrátami.
Nevýhody modelu:
Nejistota developera ohledně perspektiv rozvoje projektu se zvyšuje. Tato nevýhoda vyplývá z předchozí výhody modelu;
Operace plánování času a zdrojů celého projektu jako celku jsou komplikované. K vyřešení tohoto problému je nutné zavést časová omezení pro každou fázi životního cyklu. Přechod probíhá podle plánu, i když nejsou dokončeny všechny plánované práce. Plán je sestaven na základě statistických údajů získaných v předchozích projektech a osobních zkušeností vývojářů.
3.5. Srovnávací analýza modelů
Znalost různých modelů životního cyklu a schopnost je aplikovat v praxi jsou nezbytné pro každého projektového manažera. Správná volba modelu vám umožní kvalifikovaně naplánovat výši financování, načasování a zdroje potřebné k dokončení díla, čímž se sníží rizika jak pro vývojáře, tak pro zákazníka. To pomáhá zvyšovat autoritu (obraz) vývojářů v očích zákazníka a následně ovlivňuje vyhlídky na další spolupráci s ním a ostatními zákazníky. Je nesprávné si myslet, že spirálový model je lepší než ostatní. Koneckonců, pro každý projekt je uzavřena samostatná smlouva s určitými náklady. Zákazník nikdy neuzavře smlouvu na vysokou částku s nejistým konečným výsledkem (pokud není altruista). V tomto případě nabídne prvotní investici do projektu malou částku a na základě výsledků první verze (iterace) rozhodne o uzavření dodatečné smlouvy na vývoj systému.
Každý z modelů má své výhody a nevýhody a také oblasti použití v závislosti na specifikách vyvíjeného systému, možnostech zákazníka a vývojáře atd. Tabulka. 3.1 poskytuje srovnávací popis výše diskutovaných modelů, který by měl pomoci při výběru strategie pro konkrétní projekt.
Tabulka 3.1. Porovnání modelů životního cyklu
| Charakteristický projekt |
Model (strategie) | ||
| Novinka ve vývoji a dostupnosti zdrojů | Typický. Dobře vyvinutá technologie a metody řešení problému | Atypické (inovativní). Pro vývojáře netradiční |
|
| Zdroje zákazníka a vývojáře jsou dostatečné pro realizaci projektu v krátkém časovém horizontu | Prostředky zákazníka nebo vývojáře nestačí na realizaci projektu v krátké době | ||
| Rozsah projektu | Malé a střední projekty | Střední a velké projekty | Jakékoli projekty |
| Termíny projektu | Až rok | Až několik let. Vývoj jedné verze může trvat několik týdnů až rok | |
| Uzavření samostatných smluv pro jednotlivé verze | Je uzavřena jedna smlouva. Verze je konečným výsledkem projektu | Samostatná smlouva se obvykle uzavírá na jednu verzi nebo několik po sobě jdoucích verzí | |
| Definování základních požadavků na začátku projektu | Ano | Ano | Ne |
| Požadavky se mění s tím, jak se projekt vyvíjí | Ne | Méně důležitý | Ano |
| Vývoj podle iterací (verzí) | Ne | Ano | Ano |
| Distribuce middlewaru | Ne | Možná | Ano |
V tabulce 3.1, hodnoty „Ano“ a „Ne“ by neměly být považovány za přísné požadavky. Například drobné změny v požadavcích během vývoje projektu při použití vodopádového modelu (například přidání některých nepředvídaných servisních funkcí) nejsou tak vzácné a pokud jsou implementovány, přispívají ke zlepšení vztahů mezi stranami. Stejně tak distribuce middlewaru ve spirálovém modelu je zbytečná a někdy dokonce škodí procesu implementace a zkušebního provozu systému.
Při vývoji systému by měl být konečný produkt a middleware chápán následovně:
- audit (opravné nebo experimentální) - jakékoli provozní změny softwaru a informačního softwaru, jakož i databáze, které nejsou aktuálně nutné pro přenos na místa implementace a jsou spojeny s odstraňováním chyb a zlepšováním;
- modifikace – jakékoli provozní změny softwaru a informačního softwaru, jakož i databáze, povinné pro přenos na místa implementace a způsobující změnu provozních charakteristik bez změny funkcí (za předpokladu), jakož i změny související s odstraňováním chyb a zlepšováním;
- verze – jakékoli změny softwaru a informačního softwaru, jakož i databáze, povinné pro přenos do objektů implementace, umožňující výkon deklarovaných nebo doplňkových funkcí, jakož i zajištění přechodu na nové operační systémy a informační prostředí;
- vývoj (fronta) – plánované změny informačního systému související se zaváděním nových funkcí a zlepšováním provozních charakteristik, přechodem na nové informační prostředí, zaváděním nových souborů technických prostředků, nových informačních technologií apod.
V souladu s výše uvedenou klasifikací je konečný produkt pro kterýkoli z modelů životního cyklu povinnou verzí nebo frontou systému. Vývoj ve frontách je typický pro inkrementální strategii. Revize a úpravy by měly být považovány za middleware. Jak bylo uvedeno výše, časté rozesílání revizí a úprav koncovým uživatelům (zejména těm, kteří jsou zaneprázdněni jinými výrobními činnostmi) je nežádoucí. Podle změny verzí informačních systémů v železniční dopravě by změny měly být prováděny maximálně 1x až 2x ročně a úpravy by měly být prováděny maximálně 1x měsíčně.
3.6. Metodiky, které podporují spirálový model
V současné době existuje několik metodik vývoje softwaru 1 , které lze doporučit při použití spirálového modelu životního cyklu. Nejznámější z nich jsou metodika pro rychlý vývoj aplikací (RAD) a extrémní programování (eXtreme Programming, XP - autor Kent Beck, 1999).
3. Uveďte stručný popis metodik a.
Měli bychom začít definovánímŽivotní cyklus softwaru(Software Life Cycle Model) je časový úsek, který začíná okamžikem rozhodnutí o vytvoření softwarového produktu a končí okamžikem jeho úplného vyřazení z provozu. Tento cyklus je proces budování a vývoje softwaru.
Modely životního cyklu softwaru
Životní cyklus lze znázornit ve formě modelů. V současnosti jsou nejběžnější:kaskáda, přírůstkové (krokový model se středním ovládáním ) A spirálamodely životního cyklu.
Kaskádový model
Kaskádový model(Angličtina) model vodopádu) je model procesu vývoje softwaru, jehož životní cyklus vypadá jako tok, který postupně prochází fázemi analýzy požadavků a návrhu. implementace, testování, integrace a podpora.
Proces vývoje je realizován prostřednictvím uspořádané sekvence nezávislých kroků. Model zajišťuje, že každý následující krok začíná po úplném dokončení předchozího kroku. Ve všech krocích modelu jsou prováděny pomocné a organizační procesy a práce, včetně projektového řízení, hodnocení a řízení kvality, ověřování a certifikace, konfiguračního managementu a tvorby dokumentace. V důsledku dokončení kroků se tvoří meziprodukty, které nelze v následujících krocích měnit.
Životní cyklus se tradičně dělí na následující hlavníetapy:
- Analýza požadavků,
- Design,
- kódování (programování),
- Testování a ladění,
- Provoz a údržba.
Výhody modelu:
- stabilita požadavků během celého životního cyklu vývoje;
- v každé fázi je generována kompletní sada projektové dokumentace, která splňuje kritéria úplnosti a konzistence;
- jistota a jasnost kroků modelu a snadnost jeho aplikace;
- etapy práce prováděné v logickém sledu umožňují naplánovat načasování dokončení všech prací a odpovídající zdroje (peněžní, materiální a lidské).
Nevýhody modelu:
- obtížnost jasné formulace požadavků a nemožnost je dynamicky měnit v průběhu celého životního cyklu;
- nízká flexibilita v řízení projektů;
- konzistentnost lineární struktury vývojového procesu v důsledku vede návrat k předchozím krokům k řešení vznikajících problémů ke zvýšení nákladů a narušení harmonogramu práce;
- nevhodnost meziproduktu k použití;
- nemožnost flexibilního modelování unikátních systémů;
- Pozdní detekce problémů s montáží v důsledku současné integrace všech výsledků na konci vývoje;
- nedostatečná účast uživatele na tvorbě systému - na samém začátku (při vývoji požadavků) i na konci (při akceptačních testech);
- uživatelé si nemohou být jisti kvalitou vyvíjeného produktu, dokud není dokončen celý proces vývoje. Nemají možnost posoudit kvalitu, protože není možné vidět hotový vývojový produkt;
- uživatel nemá možnost postupně si zvykat na systém. Proces učení nastává na konci životního cyklu, kdy již byl software uveden do provozu;
- každá fáze je předpokladem pro následné akce, což činí tuto metodu riskantní volbou pro systémy, které nemají analogy, protože není vhodný pro flexibilní modelování.
Je obtížné implementovat model životního cyklu Cascade kvůli složitosti vývoje softwarového systému bez návratu k předchozím krokům a změně jejich výsledků tak, aby se eliminovaly vznikající problémy.
Rozsah použití kaskádového modelu
Omezení rozsahu použití kaskádového modelu je dáno jeho nedostatky. Jeho použití je nejúčinnější v následujících případech:
- při vývoji projektů s jasným, neměnnýmživotní cyklus požadavky, srozumitelná implementace a technické metody;
- při vývoji projektu zaměřeného na vybudování systému nebo produktu stejného typu, který byl již dříve vyvinut vývojáři;
- při vývoji projektu souvisejícího s vytvořením a vydáním nové verze stávajícího produktu nebo systému;
- při vývoji projektu souvisejícího s převodem stávajícího produktu nebo systému na novou platformu;
- při realizaci velkých projektů, které zahrnují několik velkých vývojových týmů.
Přírůstkový model
(model krok za krokem se středním ovládáním)
Přírůstkový model(Angličtina) přírůstek- zvýšení, přírůstek) znamená vývoj softwaru s lineárním sledem fází, ale v několika přírůstcích (verzích), tzn. s plánovanými vylepšeními produktu po celou dobu až do konce životního cyklu vývoje softwaru.
Vývoj softwaru probíhá v iteracích, se zpětnovazebními smyčkami mezi fázemi. Mezietapové úpravy umožňují zohlednit skutečné vzájemné ovlivňování výsledků vývoje v různých fázích, životnost každé etapy se prodlužuje po celou dobu vývoje.
Na začátku práce na projektu jsou stanoveny všechny základní požadavky na systém a rozděleny na více a méně důležité. Systém je pak vyvíjen postupně, aby vývojář mohl využít data získaná při vývoji softwaru. Každý přírůstek by měl do systému přidat určitou funkcionalitu. V tomto případě vydání začíná komponentami s nejvyšší prioritou. Jakmile jsou části systému identifikovány, vezměte první část a začněte ji podrobně popisovat pomocí nejvhodnějšího postupu. Zároveň je možné upřesnit požadavky na další části, které byly zmrazeny v aktuálním souboru požadavků na tuto práci. V případě potřeby se můžete k této části vrátit později. Pokud je díl hotový, je doručen klientovi, který jej může využít při své práci. To zákazníkovi umožní ujasnit si požadavky na následující komponenty. Poté vyvinou další část systému. Klíčovými kroky v tomto procesu je jednoduchá implementace podmnožiny softwarových požadavků a zdokonalování modelu v řadě po sobě jdoucích vydání, dokud není software plně implementován.
Životní cyklus tohoto modelu je typický při vývoji složitých a komplexních systémů, u kterých existuje jasná vize (jak ze strany zákazníka, tak ze strany vývojáře), jaký by měl být konečný výsledek. Vývoj verzí se provádí z různých důvodů:
- neschopnost zákazníka financovat celý nákladný projekt najednou;
- developerovi chybí potřebné zdroje k realizaci složitého projektu v krátké době;
- požadavky na postupnou implementaci a přijetí produktu koncovými uživateli. Implementace celého systému najednou může způsobit odmítnutí jeho uživatelů a pouze „zpomalit“ proces přechodu na nové technologie. Obrazně řečeno, mohou jednoduše „nestrávit velký kus, takže se musí nakrájet a rozdělit na části“.
Výhody A nedostatkyTento model (strategie) jsou stejné jako u vodopádu (klasický model životního cyklu). Ale na rozdíl od klasické strategie může zákazník vidět výsledky dříve. Na základě výsledků vývoje a implementace první verze může mírně změnit požadavky na vývoj, upustit od něj nebo nabídnout vývoj pokročilejšího produktu s uzavřením nové smlouvy.
výhody:
- náklady vzniklé v důsledku změn v požadavcích uživatelů jsou sníženy, re-analýza a dokumentace jsou výrazně sníženy ve srovnání s vodopádovým modelem;
- Je snazší získat zpětnou vazbu od klienta o provedené práci - klienti mohou vyjádřit své připomínky k hotovým dílům a mohou vidět, co již bylo hotovo. Protože První části systému jsou prototypem systému jako celku.
- klient má možnost rychle získat a osvojit si software - klienti mohou realizovat skutečné výhody systému dříve, než by to bylo možné s vodopádovým modelem.
Nevýhody modelu:
- manažeři musí neustále měřit pokrok v procesu. v případě rychlého vývoje byste neměli vytvářet dokumenty pro každou minimální změnu verze;
- struktura systému má tendenci se zhoršovat, když jsou přidávány nové komponenty – neustálé změny narušují strukturu systému. Aby se tomu zabránilo, je nutný další čas a peníze na refaktorizaci. Špatný design způsobuje, že pozdější změna softwaru je obtížná a nákladná. A přerušený životní cyklus softwaru vede k ještě větším ztrátám.
Schéma neumožňuje rychle zohlednit vznikající změny a upřesnění softwarových požadavků. Koordinace výsledků vývoje s uživateli probíhá pouze v bodech plánovaných po ukončení každé etapy práce a obecné požadavky na software jsou evidovány ve formě technických specifikací po celou dobu jeho tvorby. Uživatelé tak často dostávají software, který neodpovídá jejich skutečným potřebám.
Spirálový model
Spirálový model:Životní cyklus - při každém otočení spirály se vytvoří další verze produktu, vyjasní se požadavky projektu, určí se jeho kvalita a naplánuje se práce na další zatáčku. Zvláštní pozornost je věnována počátečním fázím vývoje - analýze a návrhu, kde se testuje proveditelnost určitých technických řešení a odůvodňuje se tvorbou prototypů.
Tento model je procesem vývoje softwaru, který kombinuje jak návrh, tak inkrementální prototypování, aby spojil výhody konceptů zdola nahoru a shora dolů, s důrazem na rané fáze životního cyklu: analýzu a návrh.Výrazná vlastnost Tento model věnuje zvláštní pozornost rizikům ovlivňujícím organizaci životního cyklu.
Ve fázích analýzy a návrhu se pomocí vytváření prototypů ověřuje proveditelnost technických řešení a stupeň uspokojení potřeb zákazníků. Každé otočení spirály odpovídá vytvoření funkčního fragmentu nebo verze systému. To vám umožní ujasnit si požadavky, cíle a charakteristiky projektu, určit kvalitu vývoje a naplánovat práci na další zatáčku spirály. Dochází tak k prohloubení a důslednému upřesnění detailů projektu a ve výsledku je vybrána rozumná varianta, která vyhovuje skutečným požadavkům zákazníka a je přivedena k realizaci.
Životní cyklus při každém otočení spirály – lze použít různé modely procesu vývoje softwaru. Výstupem je nakonec hotový výrobek. Model kombinuje schopnosti prototypového modelu amodel vodopádu. Vývoj po iteracích odráží objektivně existující spirálový cyklus vytváření systému. Neúplné dokončení práce v každé fázi vám umožňuje přejít do další fáze, aniž byste čekali na úplné dokončení práce v aktuální fázi. Hlavním úkolem je co nejrychleji ukázat uživatelům systému fungující produkt, a tím aktivovat proces upřesňování a doplňování požadavků.
Výhody modelu:
- umožňuje rychle ukázat uživatelům systému funkční produkt, čímž aktivuje proces vyjasňování a doplňování požadavků;
- umožňuje změny požadavků během vývoje softwaru, což je typické pro většinu vývojů, včetně standardních;
- model umožňuje flexibilní design, protože ztělesňuje výhody vodopádového modelu a zároveň umožňuje iterace napříč všemi fázemi stejného modelu;
- umožňuje získat spolehlivější a stabilnější systém. Jak se software vyvíjí, jsou při každé iteraci objeveny a opraveny chyby a slabiny;
- tento model umožňuje uživatelům aktivně se podílet na plánování, analýze rizik, návrhu a hodnocení;
- rizika pro zákazníky jsou snížena. Zákazník může dokončit vývoj neperspektivního projektu s minimálními finančními ztrátami;
- Zpětná vazba od uživatelů k vývojářům se objevuje s vysokou frekvencí a na začátku modelu, což zajišťuje vytvoření požadovaného produktu vysoké kvality.
Nevýhody modelu:
- pokud je projekt nízkorizikový nebo malý, model může být drahý. Hodnocení rizik po každé spirále je spojeno s vysokými náklady;
- Životní cyklus modelu má složitou strukturu, takže jeho použití vývojáři, manažery a zákazníky může být obtížné;
- spirála může pokračovat donekonečna, protože každá reakce zákazníka na vytvořenou verzi může vygenerovat nový cyklus, který oddálí konec projektu;
- velký počet mezicyklů může vést k nutnosti zpracovat další dokumentaci;
- použití modelu se může ukázat jako drahé a dokonce nedostupné, protože čas. čas strávený plánováním, předefinováním cílů, prováděním analýz rizik a vytvářením prototypů může být nadměrný;
- Může být obtížné definovat cíle a milníky, které indikují připravenost pokračovat ve vývojovém procesu do dalšího a
Hlavním problémem spirálového cyklu je určení okamžiku přechodu do další fáze. K vyřešení tohoto problému jsou pro každou fázi zavedena časová omezení.životní cyklus a přechod probíhá podle plánu, i když nejsou dokončeny všechny plánované práce.Plánovánívytvořené na základě statistických údajů získaných v předchozích projektech a osobních zkušeností vývojářů.
Rozsah použití spirálového modelu
Použití spirálového modelu se doporučuje v následujících případech:
- při vývoji projektů využívajících nové technologie;
- při vývoji nové řady produktů nebo systémů;
- při vývoji projektů s očekávanými významnými změnami nebo doplnění požadavků;
- provádět dlouhodobé projekty;
- při vývoji projektů, které vyžadují prokázání kvality a verzí systému nebo produktu během krátké doby;
- při vývoji projektů. u kterých je nutné kalkulovat náklady spojené s posuzováním a řešením rizik.
