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.
Přednáška 2.
Pojem životního cyklu a model životního cyklu. Kaskádový model životního cyklu. Krokový model se středním ovládáním. Spirála ModelkaJ C. ProcesyJ CPODLE. Rychlý vývoj aplikací (RAD). Extrémní programování (XP). Rational Unified Process (RUP). Microsoft Solution Framework (MSF). Vlastní metoda vývoje (metodologieVěštec).
2.1. Koncepce životního cyklu a model životního cyklu
Životní cyklus IS –časové období, které začíná okamžikem rozhodnutí o nutnosti vytvoření IP a končí okamžikem jeho úplného stažení z užívání. Životní cyklus informačního systému lze znázornit jako řadu událostí, které se v systému vyskytují během procesu jeho tvorby a používání.
Model životního cyklu je chápán jako struktura, která definuje posloupnost provádění a vztahy procesů, akcí a úkolů, které jsou prováděny během vývoje, provozu a údržby softwarového produktu po celou dobu životnosti systému, od stanovení požadavků až po konec jeho používání. (snímek 2) .
Model životního cyklu softwaru zahrnuje (snímek 3) : etapy, výsledky práce v každé etapě, klíčové události - body dokončení práce a rozhodování.
Pod etapa je chápána jako část procesu tvorby softwaru, ohraničená 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.
Za extrémní případ modelu životního cyklu lze považovat tzv. model „black box“ nebo „code and fix“, což vlastně znamená absenci jakéhokoli modelu. V tomto případě není možné identifikovat žádné racionální fáze procesu vývoje softwaru, protože neexistuje žádné plánování a organizace práce.
V současné době jsou známy a používány následující modely životního cyklu:
Kaskádový model(typické pro období 1970-1980);
Krokový model se středním ovládáním(typické pro období 1980-1985);
Spirálový model(typické pro období po roce 1986)
2.2. Kaskádový model životního cyklu
V roce 1970 publikoval softwarový expert Winston Royce široce uznávaný článek, ve kterém vyjádřil své názory na techniku, která se později stala známou jako model vodopádu. (snímek 4) .
Následně byl tento model regulován mnoha regulačními dokumenty, zejména známým standardem amerického ministerstva obrany Dod-STD-2167A a ruskými standardy řady GOST 34.
Kaskádový modelzajišťuje sekvenční 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.
Základní vlastnosti takzvaného „čistého“ kaskádového modelu jsou následující:
Stanovení požadavků na systém před jeho dodáním zákazníkovi;
Sekvenční provádění etap.
Přechod do další fáze projektu až po úplném dokončení prací v současné fázi, bez návratu do dokončených fází.
Žádné dočasné překrývání etap
Bez návratu k předchozím etapám
Dostupnost výsledků až na konci vývoje.
Výhody použití kaskádového modelu 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 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í náklady.
Hlavní nevýhodou tohoto přístupu je, že vlastní proces tvorby systému nikdy zcela nezapadá do takto rigidního schématu, vždy je potřeba vracet se k předchozím fázím a vyjasňovat či revidovat dříve učiněná rozhodnutí.
Další nevýhody vodopádového přístupu jsou:
pozdní odhalení problémů. Chyby jsou identifikovány a eliminovány pouze ve fázi testování, které může trvat dlouho nebo nemusí být nikdy dokončeno.
opuštění kalendáře, zpoždění při získávání výsledků;
nadměrné množství dokumentace;
neschopnost rozdělit systém na části (celý produkt je vyvíjen najednou);
vysoké riziko vytvoření systému, který nevyhovuje měnícím se potřebám uživatelů.
Historicky jde o první model životního cyklu IS. Používal se pro poměrně jednoduché informační systémy, kdy každá aplikace byla jedním, funkčně a informačně nezávislým blokem. Nyní lze vodopádový model použít k vytvoření softwaru, pro který lze na samém počátku vývoje zcela přesně a kompletně formulovat všechny požadavky, aby vývojáři měli volnost je technicky co nejlépe implementovat.
Softwarový průmysl se vyvíjí rychlým tempem, ale není žádným tajemstvím, že vývojový proces má k dokonalosti stále velmi daleko a vyznačuje se mnoha vnitřními problémy. Podle studie Standish Group (www.standishgroup.com) je úspěšná méně než třetina softwarových projektů, zbytek se buď nevejde do finančních a časových rámců, nebo skončí úplným neúspěchem.
Hrdina pracující sám -
programátor je anachronismus.
Edward Yordon
Zmíněná studie uvádí, že malé projekty jsou nejúspěšnější a čím větší projekt, tím větší riziko neúspěchu. To naznačuje, že jak se rozsah úkolu zvyšuje, manažeři nejsou schopni spravovat přidělené zdroje.
Ve skutečnosti problém rostoucí složitosti řízení v závislosti na nárůstu velikosti organizace není zdaleka nový, ale v programování nabývá nových tvarů: pokud není dostatek zdrojů k včasné realizaci projektu, jednoduše je zvětšíme. problém jen prohloubí a termín se ještě posune (hovoříme především o lidských zdrojích, protože zbytek je v programování mnohem méně významný).
Poprvé se o tom vážně diskutovalo po vydání knihy Fredericka Brookse The Mythical Man-Moon v roce 1975, která se později stala klasikou. Je příznačné, že je po mnoho let znovu vydáván a jeho hlavní ustanovení zůstávají stále v platnosti. Ve své pozdější práci Brooks identifikoval dvě složky složitosti vývoje softwaru: obtíže spojené se specifiky tvorby softwaru a náhodné – v této souvislosti ty, které jsou spojeny s omezeními na úrovni rozvoje vědy a techniky. Ty druhé jsou více či méně úspěšně překonány na cestě vědeckotechnického pokroku, ale ty první budou vždy doprovázet vývoj softwaru.
Efektivní řízení jakéhokoli procesu je možné za předpokladu, že subjekt kontroly adekvátně vnímá stav a chování kontrolního objektu. Pokud jde o tvorbu softwaru, jde o velmi obtížný úkol, protože vývojový proces je čistě intelektuální, z velké části tvůrčí činnost, na kterou nejsou pipeline nebo jiné podobné metody použitelné. Proto byly činěny aktivní pokusy představit model procesu tvorby softwaru, který by mohl v maximální míře zohlednit jeho přirozené vlastnosti a učinit jej zvládnutelným.
Modely založené na inženýrském přístupu
Model eliminace chyb kódování. Je to popsáno následovně: 1) nastavit úkol; 2) provádět jej až do úspěšného dokončení nebo zrušení; 3) zkontrolujte výsledek; 4) v případě potřeby opakujte od kroku 1.
Takový model přirozeně vývojový proces nijak nestrukturoval a o možnosti jeho efektivního využití zejména ve velkých projektech je zbytečné hovořit.
Kaskádový model. První model, který se stal široce známým a skutečně strukturoval proces vývoje, je kaskáda nebo vodopád. Vznikl po konferenci NATO o vědě a technice v roce 1968, kde se o podobných otázkách uvažovalo, a rozděluje proces tvorby softwarového produktu do po sobě jdoucích fází (nutno podotknout, že již v té době jej používali různí vývojáři, ale ani počet ani obsah etap není sjednocen).
Krátce po svém zrodu byl kaskádový model modifikován Winst Roycem s přihlédnutím k vzájemné provázanosti etap a nutnosti návratu k předchozím etapám, což může být způsobeno např. neúplnými požadavky nebo chybami při tvorbě úkol. V této „reverzibilní“ podobě kaskádový model existoval dlouhou dobu a byl základem mnoha projektů (obr. 1).
Praktické použití tohoto modelu však odhalilo mnoho jeho nedostatků, z nichž hlavním bylo, že je vhodnější pro tradiční typy inženýrských činností než pro vývoj softwaru. Zejména se jako jeden z největších problémů ukázala jeho „dispozice“ k případným nesrovnalostem mezi výsledným produktem a požadavky, které na něj byly kladeny. Hlavním důvodem je to, že plně vytvořený produkt se objevuje až v pozdějších fázích vývoje, ale protože práce v různých fázích obvykle prováděli různí specialisté a projekt byl převeden z jedné skupiny do druhé, pak podle principu rozbitého telefonu se ukázalo, že výstup nebyl úplně takový, jak se původně očekávalo.
Model ve tvaru V. Byl navržen právě proto, aby se odstranily nedostatky kaskádového modelu, a název - ve tvaru V, neboli kloubový - se objevil kvůli jeho specifickému grafickému znázornění (obr. 2).
Model ve tvaru V umožnil výrazně zlepšit kvalitu softwaru díky jeho zaměření na testování a také do značné míry vyřešil problém souladu vytvořeného produktu s předloženými požadavky díky ověřovacím a certifikačním postupům v raných fázích vývoje. vývoj (tečkované čáry na obrázku označují závislost fází plánování/nastavení problému a testování/akceptace).
Obecně je však model ve tvaru V jen modifikací kaskádového modelu a má mnoho svých nevýhod. Oba jsou zejména špatně přizpůsobeny případným změnám požadavků zákazníků. Pokud proces vývoje trvá dlouho (někdy až několik let), může být výsledný produkt pro zákazníka vlastně zbytečný, protože se jeho potřeby výrazně změnily.
Otázka vlivu vědeckého a technologického pokroku je stejně aktuální: požadavky na software jsou předkládány s ohledem na současný stav vědeckých a praktických výsledků v oblasti hardwaru a softwaru, ale sektor IT se velmi rychle rozvíjí. zdlouhavý vývojový proces může vést k vytvoření produktu, který je založen na zastaralých technologiích a který se ještě dříve, než se objeví, ukáže jako nekonkurenceschopný.
Důležitá je také otázka plánovacích ukazatelů očekávané funkčnosti, protože v těchto modelech nejde o nic jiného než o předpoklad: zejména je téměř nemožné určit, jakou rychlost zpracování dat bude vytvořený produkt poskytovat nebo kolik paměti bude zabírat při fázi nastavení problému. Pokud jsou takové požadavky jasně uvedeny v podmínkách smlouvy mezi objednatelem a zhotovitelem, je pravděpodobné, že je výsledné řešení nesplní, i když se to dozví až v závěrečných fázích vývoje, kdy budou mít hlavní zdroje k dispozici již byly utraceny.
V důsledku toho bude zákazník nucen buď se smířit s omezeními řešení vytvořeného na základě uvažovaných modelů, nebo investovat další finanční prostředky, aby skutečně dostal to, co potřebuje.
Modely, které zohledňují specifika vývoje softwaru
Vzhledem k tomu, že první modely byly vypůjčeny z tradičního strojírenského oboru, nebraly plně v úvahu specifika softwarové výroby. Následující modely však byly mnohem více zaměřeny na rysy tohoto druhu činnosti, která má mnoho zásadních rozdílů od konstrukce objektů hmotného světa.
Model založený na prototypování. Vzhledem k tomu, že zákazník často není softwarovým specialistou, většinou nevnímá dobře „holé“ specifikace produktu. Aby se překonala informační bariéra mezi zákazníkem a vývojářem a snížilo se riziko získání produktu, který nesplňuje požadavky, začal se uplatňovat přístup zaměřený na tvorbu prototypů, což jsou plně nebo částečně fungující modely hotového systému. . Umožňuje výrazně zlepšit vzájemné porozumění mezi všemi účastníky procesu díky důslednému, evolučnímu vývoji systému založenému na iterativním zdokonalování prototypů.
Využití posledně jmenovaných je obdobné jako použití zmenšených modelů staveb v architektuře - umožňují vizualizovat konečný výsledek, jejich stavba a úprava je mnohem méně pracná ve srovnání se stavbou a úpravou stavby samotné.
Přes ne všechny výhody se však tento model také nestal všelékem. Jeho hlavní problémy spočívaly v rovině vztahu „zákazník – vykonavatel“: první měl zájem o vytvoření co nejpodrobnějších prototypů, aby se snížilo riziko obdržení nevyhovujícího systému, zatímco pro druhého znamenal každý nový prototyp dodatečné náklady. času a zdrojů a v důsledku toho - snížení ziskovosti projektu.
Přírůstkový model. Software lze na rozdíl např. od mikroobvodu zprovozňovat po částech, což znamená, že jej lze vyvíjet a dodávat zákazníkovi i postupně. Právě na tom je založen inkrementální model, který zahrnuje fragmentaci produktu na relativně nezávislé komponenty, které jsou vyvíjeny a uváděny do provozu samostatně.
Tento model je výhodný jak pro zákazníka, tak pro tvůrce systému, protože umožňuje postupovat vpřed při respektování zájmů obou stran. Má to však své nevýhody. Rozdělení do funkčních bloků obecně zpomaluje proces, protože je nutné zajistit jejich interakci. U mnoha řešení není tato metoda použitelná, protože z nich nelze izolovat jednotlivé komponenty, které by bylo možné dodat a fungovat nezávisle. Výrazně se zvyšuje i zátěž řídícího personálu z důvodu zkomplikování úkolů koordinace prací na jednotlivých komponentách systému a zvyšují se náklady na provádění změn na již nainstalovaných a provozovaných komponentách u zákazníka.
Spirálový model. Byl navržen Barrym Boehmem v roce 1988 a představoval významný průlom v chápání podstaty vývoje softwaru, i když celkově jde o kombinaci dvou modelů: vodopádu a prototypování (obr. 3).
Spirálový model Boema je zaměřena na design. K samotnému vývoji softwaru dochází až na posledním otočení spirály podle obvyklého kaskádového modelu, tomu však předchází několik iterací návrhu založených na tvorbě prototypů - každá iterace zahrnuje fázi identifikace a analýzy rizik a nejsložitějších úkolů.
Vzhledem k tomu, že spirálový model pokrývá především design, nebyl ve své původní podobě široce používán jako metoda pro řízení celého životního cyklu tvorby softwaru. Jeho hlavní myšlenka, že proces práce na projektu se může skládat z cyklů, které procházejí stejnými fázemi, však posloužila jako výchozí bod pro další výzkum a stala se základem nejmodernějších modelů procesu vývoje softwaru.
Moderní modely
V polovině 90. let softwarový průmysl dozrál, složité projekty byly úspěšně implementovány pomocí stále oblíbenější objektově orientované metodologie a vývojové týmy si osvojovaly přístupy, které těžily z nejvýznamnějších výhod předchozích modelů.
Objektově orientovaný model. Tato metodika zahrnuje konstrukci softwarového řešení z hotových objektů, pro které jsou stanovena pravidla jejich interakce, přenášení objektů z jednoho stavu do druhého. Tento model, který zajišťuje plnou shodu vývojového procesu s ustanoveními objektově orientované metodologie (objektově orientovaná analýza, návrh, programování), je účinný ve velkých projektech, stejně jako tam, kde jsou tzv. nástroje rychlého vývoje (RAD, Rapid Application Development), založené na těchto technologiích a obsahující hotové knihovny tříd.
Samotné systémy RAD však nepodporují vytváření objektově orientovaných řešení. Programátoři, zhýčkaní nástroji, které jim umožňují vytvářet produkty v řádu hodin z hotových komponent, které dříve zabíraly dny a měsíce práce, považují za zbytečné trápit se podrobným studiem metodiky a UML, ba co víc. neusilovat o formalizaci svých řešení ve formě tříd vhodných pro opětovné použití.
Objektově orientovaný model se tedy používá především ve velmi velkých projektech, kde je věnována náležitá pozornost fázím analýzy a návrhu a kde jsou vývojáři přísně kontrolováni, zda dodržují stanovená pravidla.
Iterativní model. Tento model, který poprvé navrhl Philippe Kratchen v roce 1995, kombinuje hlavní výhody spirálových, inkrementálních, vodopádových, prototypových a objektově orientovaných vývojových metod (obrázek 4). Získal si velkou oblibu a v té či oné podobě se používá v mnoha moderních projektech.
Podle iterativního modelu existují čtyři hlavní fáze životního cyklu vývoje softwaru (iniciace, průzkum, konstrukce a implementace). V každé fázi prochází projekt mnoha iteracemi, které vedou k vytvoření funkčních verzí: v počátečních fázích se vytvářejí prototypy, vyjasňují se požadavky a řeší se nejsložitější problémy; poslední vedou k vytvoření produktu, jeho vylepšení a rozšíření funkčnosti.
Iterační model kromě hlavních fází rozlišuje ještě dvě skupiny procesů: pracovní (správa požadavků, analýza a návrh, implementace, testování, nasazení) a pomocné (řízení konfigurace a změn, projekt a proces). Počet a podstata procesů se liší v závislosti na potřebách vývojáře, mohou mít i své cykly, které ani nemusí nutně odpovídat hlavním fázím. Výsledkem pracovních postupů však vždy je vytvoření verzí produktu.
Iterativní model, stejně jako spirálový model, umožňuje úspěšně se vyrovnat s riziky. Pokud se při práci na další verzi zjistí, že mzdové náklady na implementaci požadované funkcionality jsou příliš vysoké, lze překročení rozpočtu a zmeškaným termínům předejít korelací priorit vývoje a mzdových nákladů na začátku každé iterace. Tento model se tedy dobře hodí pro většinu typů softwarových projektů, ale jeho výhody jsou patrné zejména při práci na produktech určených pro vstup na volný trh, vzhledem k počátečnímu zaměření na vydávání sekvenčních verzí.
Philip Kratchen již delší dobu pracuje ve společnosti Rational Software, kterou nyní vlastní IBM. Z tohoto důvodu se iterační model stal základem RUP (Rational Unified Process) – jedné z nejběžnějších metod integrovaného řízení procesu vývoje softwaru. Na jejím základě byl vyvinut hlavní konkurent RUP od Microsoftu MSF (Microsoft Solutions Framework) a obdobný přístup od Borlandu - ALM (Application Lifecycle Management).
Modely rychlého rozvoje. Mnohá omezení v moderních metodologiích vývoje softwaru vedla k tomu, že vývojářské společnosti se v mnoha ohledech podobaly obřím byrokratickým systémům. Přítomnost velkého množství formálních postupů a pravidel výrazně zužuje svobodu jednání každého jednotlivého programátora a mění ho v kolečko v obrovském a neohrabaném stroji. Navzdory skutečnosti, že tyto stroje jsou schopny poměrně úspěšně zvládnout úkoly, které před nimi stojí, jejich účinnost je obvykle poměrně nízká a specifická produktivita jednotlivého vývojáře je tak malá, že pro programátora lze považovat za normální napsat několik řádků kódu. denně.
Modely rychlého vývoje, jako je extrémní programování, jsou navrženy tak, aby zpochybnily takové formalistické přístupy. Jejich podstata spočívá v odmítnutí všeho zbytečného, co přímo nesouvisí s tvorbou kvalitního softwarového produktu a za základ se berou jen ty nejefektivnější metody tvorby softwaru. Zvláštní pozornost je věnována otázkám interakce se zákazníkem, organizování produktivní práce a testování. Mnoho nápadů rychlého rozvoje nebylo nových, například jednotkové testy byly v mnoha projektech používány již dlouhou dobu, ale když se spojily a byly povinné pro použití, měly pozitivní efekt. O těchto metodách se v poslední době začíná mluvit stále častěji a jejich prvky si začalo vypůjčovat mnoho klasických modelů.
V moderních podmínkách je rychlý vývoj velmi módním přístupem a používá se stále aktivněji. Hlavní výhodou je, že relativně malé týmy vývojářů jsou schopny dokončit projekty za stejnou dobu, jakou řádově větším týmům zabere použití tradičnějších metod.
Jsou zde však i nevýhody, zejména rychlý vývoj se špatně hodí pro velké projekty a je zaměřen především na malé a střední, navíc jeho efektivní využití je možné pouze v případě, že tvůrci softwaru mají velmi vysokou kvalifikaci a význam Zkušenosti.
Upravené a kombinované modely. Ve skutečnosti, jak se vyvíjely modely životního cyklu vývoje softwaru, nové nápady úplně nenahradily ty staré. Je správnější uvažovat o tom, že každý z nich má svůj vlastní rozsah použití. Kromě toho se v každém konkrétním případě může ukázat, že neexistuje žádná technika, která by byla ideálně vhodná pro řešení daného problému. V tomto případě by manažeři softwarových projektů měli zvážit možnosti přizpůsobení modelů konkrétním potřebám nebo použití kombinovaných metod, které zahrnují prvky různých přístupů. Například úspěch rychlého vývoje vedl k tomu, že konzervativnější modely přijaly jeho nejúčinnější techniky a začaly je používat jako součást svých procesů.
prezentace finálních dokumentů, procesních metrik, kritérií pro zahájení a dokončení úkolů a přechod k dalšímu kroku v procesu; výběr testovacích metod pro vybranou třídu softwaru pro ověření správného provedení testovacích úloh; vývoj speciálních šablon dokumentů, které dokumentují proces testování týkající se každého kroku procesu testování.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.
V rámci konkrétních modely životního cyklu, které předepisují pravidla pro organizaci vývoje softwaru v rámci daného odvětví nebo organizace, konkrétněji vývojové procesy. Od norem se liší především podrobnostmi a jasným popisem vazeb mezi jednotlivci druhy činností, definující datové toky (dokumenty a artefakty) během životní cyklus. Takových modelů je poměrně hodně, protože vlastně pokaždé si organizace definuje svůj vlastní vývojový proces, jako základ pro tento proces, některé model životního cyklu softwaru. V této přednášce se budeme zabývat pouze několika modely. Bohužel je velmi obtížné vybrat kritéria, podle kterých by bylo možné dát nějakou užitečnou klasifikaci známých modely životního cyklu.
Nejznámější a dlouhou dobu používanou zůstala tzv. kaskáda resp vodopád model životního cyklu, o kterém se předpokládá, že byl poprvé v práci jasně formulován a následně zachycen ve standardech Ministerstva obrany USA v 70.–80. letech XX. Tento model zahrnuje sekvenční provádění různých druhy činností, počínaje vývojem požadavků a konče údržbou, s jasným vymezením hranic mezi fázemi, ve kterých se soubor dokumentů vytvořených v předchozí fázi přenáší jako vstup do další. Takže všichni Druh činnosti provedeny v jedné fázi životní cyklus. Posloupnost vývojových kroků navržená v článku je znázorněna na Obr. 2.2. "Klasický" kaskádový model zahrnuje pouze postup vpřed podle tohoto schématu: vše potřebné k provedení další činnosti musí být připraveno v průběhu předchozí práce.
Pokud si však článek pozorně přečtete, ukáže se, že nepředepisuje dodržování tohoto konkrétního pořadí práce, ale představuje model iterativního procesu (viz obr. 2.3) - ve své sekvenční podobě byl tento model zřejmě opraven v myslích úředníků z ministerstev a manažerů firem spolupracujících s těmito ministerstvy na základě smluv. Při skutečné práci podle modelu, který umožňuje pohyb pouze jedním směrem, obvykle nastávají problémy, když jsou odhaleny nedostatky a chyby učiněné v raných fázích. Ještě obtížnější je ale vypořádat se se změnami v prostředí, ve kterém je software vyvíjen (mohou to být změny požadavků, změny dodavatelů, změny v politice vyvíjející se nebo provozující organizace, změny v průmyslových standardech, vznik konkurenčních produkty atd.).
V souladu s tímto modelem je možné pracovat pouze tehdy, je-li možné předem předvídat možné peripetie postupu projektu a v prvních fázích pečlivě sbírat a integrovat informace, aby bylo možné výsledky později použít bez ohledu na možné změny. .
Mezi vývojáři a výzkumníky, kteří se zabývají vývojem komplexního softwaru, jsou téměř od samého počátku průmyslu výroby softwaru (viz například) velmi oblíbené modely evolučních nebo iteračních procesů, protože mají větší flexibilitu a schopnost pracovat v měnícím se prostředí.
Iterativní nebo přírůstkové modely(je známo několik takových modelů) zahrnují rozdělení vytvořeného systému na sadu kusů, které jsou vyvíjeny pomocí několika po sobě jdoucích průchodů celého díla nebo jeho části.
Při první iteraci je vyvinuta část systému, která je nezávislá na ostatních. V tomto případě se na něm dokončí většina nebo i celý cyklus práce, poté se vyhodnotí výsledky a při další iteraci se buď předělá první kus, nebo se vyvine další, což může záviset na prvním, popř. revize prvního kusu je nějak spojena s přidáním nových funkcí. Výsledkem je, že při každé iteraci je možné analyzovat mezivýsledky práce a reakce všech zúčastněných stran, včetně uživatelů, na ně a v dalších iteracích provést nápravné změny. Každá iterace může obsahovat kompletní sadu druhy činností- od analýzy požadavků až po uvedení dalšího softwaru do provozu.
Kaskádový model s možností návratu k předchozímu kroku v případě potřeby revize jeho výsledků se stává iterativní.
Iterační proces předpokládá, že jinak činnosti nejsou pevně vázány na určité fáze vývoje, ale provádějí se podle potřeby, někdy se opakují, dokud se nedosáhne požadovaného výsledku.
Spolu s flexibilitou a schopností rychle reagovat na změny, iterativní modely přinést další složitost projektový management a sledování jeho pokroku. Při použití iterativního přístupu je mnohem obtížnější adekvátně posoudit aktuální stav projektu a naplánovat dlouhodobý vývoj, stejně jako předvídat načasování a zdroje potřebné k zajištění určité kvality výsledku.
Rozšířením myšlenky iterací je
