Kaskádová stratégia (jednorazový prechod, vodopád alebo klasický model) implikuje lineárnu postupnosť vykonávania etáp tvorby informačného systému (obr. 3.1). Inými slovami, prechod z jednej etapy do ďalšej nastáva až po úplnom dokončení prác na súčasnej.
Obr.3.1. Kaskádová stratégia
Tento model sa využíva pri vývoji informačných systémov, na ktoré sa dajú všetky požiadavky celkom presne a kompletne formulovať už na začiatku vývoja.
Výhody modelu:
V každej fáze sa vygeneruje kompletný súbor dokumentácie, softvéru a hardvéru, ktorý spĺňa kritériá úplnosti a konzistentnosti;
Etapy, vykonávané v jasnom poradí, vám umožňujú s istotou naplánovať načasovanie práce a zodpovedajúce zdroje (peňažné, materiálne a ľudské).
Nevýhody modelu:
Samotný proces vývoja informačného systému málokedy úplne zapadá do takejto rigidnej schémy. To platí najmä pre vývoj atypických a inovatívnych systémov;
Na základe presnej formulácie prvotných požiadaviek na informačný systém. V skutočnosti sú na začiatku projektu požiadavky zákazníka definované len čiastočne;
Hlavnou nevýhodou je, že výsledky vývoja sú zákazníkovi k dispozícii až na konci projektu. Ak sú požiadavky uvedené nepresne alebo sa menia počas dlhého obdobia vytvárania IP, zákazník dostáva systém, ktorý nevyhovuje jeho potrebám.
3.3. Prírastková stratégia
Inkrementálna stratégia (anglicky: increment) znamená vývoj informačného systému s lineárnou postupnosťou etáp, ale v niekoľkých inkrementoch (verziách), t. j. s plánovaným zlepšovaním produktu.
Obr.3.2. Prírastková stratégia
Na začiatku projektu sa stanovia všetky základné požiadavky na systém, po ktorom sa vyvinie vo forme postupnosti verzií. Každá verzia je navyše kompletný a funkčný produkt. Prvá verzia implementuje časť plánovaných schopností, ďalšia verzia implementuje ďalšie schopnosti atď., kým sa nedosiahne úplný systém.
Tento model životného cyklu je typický pre vývoj komplexných a integrovaných systémov, pre ktoré existuje jasná vízia (na strane zákazníka aj na strane vývojára), aký by mal byť konečný výsledok (informačný systém). Vývoj verzie sa vykonáva z rôznych dôvodov:
Zákazník nemá možnosť financovať celý nákladný projekt naraz;
Developerovi chýbajú potrebné zdroje na realizáciu komplexného projektu v krátkom čase;
Požiadavky na fázovú implementáciu a prijatie produktu koncovými užívateľmi. Implementácia celého systému naraz môže spôsobiť odmietnutie medzi jeho používateľmi a iba „spomaliť“ proces prechodu na nové technológie. Obrazne povedané, možno jednoducho „nestrávia veľký kus, takže ho treba nasekať a rozdať po častiach“.
Výhody A nedostatky Táto stratégia je rovnaká ako klasická. Ale na rozdiel od klasickej stratégie môže zákazník vidieť výsledky skôr. Na základe výsledkov vývoja a implementácie prvej verzie môže mierne zmeniť požiadavky na vývoj, upustiť od neho, prípadne ponúknuť vývoj pokročilejšieho produktu s uzavretím novej zmluvy.
3.4. Špirálová stratégia
Špirálová stratégia (evolučný alebo iteračný model, Barry Boehm, 1988) zahŕňa vývoj v postupnosti verzií, ale nie všetky požiadavky sú definované na začiatku projektu. Požiadavky sa spresňujú pri vývoji verzií.
Ryža. 3.3. Špirálová stratégia
Tento model životného cyklu je typický pre vývoj inovatívnych (neštandardných) systémov. Zákazník a developer nemajú na začiatku práce na projekte jasnú víziu finálneho produktu (nedá sa jasne definovať požiadavky) ani stopercentnú dôveru v úspešnú realizáciu projektu (riziká sú veľmi vysoké). V tejto súvislosti sa rozhoduje o vývoji systému po častiach s možnosťou zmeny požiadaviek alebo odmietnutia jeho ďalšieho vývoja. Ako je zrejmé z Obr. 3.3, vývoj projektu môže byť ukončený nielen po fáze implementácie, ale aj po fáze analýzy rizík.
Výhody modelu:
Umožňuje rýchlo ukázať používateľom systému funkčný produkt, čím sa aktivuje proces objasňovania a dopĺňania požiadaviek;
Umožňuje zmeny požiadaviek pri vývoji informačného systému, čo je typické pre väčšinu vývojov vrátane štandardných;
Poskytuje väčšiu flexibilitu pri riadení projektov;
Umožňuje vám získať spoľahlivejší a stabilnejší systém. Ako sa systém vyvíja, chyby a slabé stránky sa zisťujú a opravujú pri každej iterácii;
Umožňuje vám zlepšiť proces vývoja - analýza vykonaná v každej iterácii vám umožní posúdiť, čo je potrebné zmeniť vo vývojovej organizácii a zlepšiť to pri ďalšej iterácii;
Riziká zákazníkov sú znížené. Zákazník môže dokončiť vývoj neperspektívneho projektu s minimálnymi finančnými stratami.
Nevýhody modelu:
Zvyšuje sa neistota developera ohľadom perspektív rozvoja projektu. Táto nevýhoda vyplýva z predchádzajúcej výhody modelu;
Operácie plánovania času a zdrojov celého projektu ako celku sú komplikované. Na vyriešenie tohto problému je potrebné zaviesť časové obmedzenia pre každú fázu životného cyklu. Prechod prebieha podľa plánu, aj keď nie sú dokončené všetky plánované práce. Plán je zostavený na základe štatistických údajov získaných v predchádzajúcich projektoch a osobných skúseností vývojárov.
3.5. Porovnávacia analýza modelov
Znalosť rôznych modelov životného cyklu a schopnosť ich aplikovať v praxi sú nevyhnutné pre každého projektového manažéra. Správny výber modelu vám umožňuje kompetentne naplánovať množstvo financií, načasovanie a zdroje potrebné na dokončenie diela, čím sa znížia riziká developera aj zákazníka. To pomáha zvyšovať autoritu (imidž) vývojárov v očiach zákazníka a následne ovplyvňuje vyhliadky na ďalšiu spoluprácu s ním a ostatnými zákazníkmi. Je nesprávne myslieť si, že špirálový model je lepší ako ostatné. Koniec koncov, pre každý projekt sa uzatvára samostatná zmluva s určitými nákladmi. Zákazník nikdy neuzavrie zmluvu na vysokú sumu s neistým konečným výsledkom (pokiaľ nie je altruista). V tomto prípade ponúkne počiatočnú investíciu malej sumy do projektu a na základe výsledkov prvej verzie (iterácie) rozhodne o uzavretí dodatočnej zmluvy na vývoj systému.
Každý z modelov má svoje výhody a nevýhody, ako aj oblasti použitia v závislosti od špecifík vyvíjaného systému, možností zákazníka a vývojára atď. Tabuľka. 3.1 poskytuje porovnávací popis vyššie diskutovaných modelov, ktorý by mal pomôcť pri výbere stratégie pre konkrétny projekt.
Tabuľka 3.1. Porovnanie modelov životného cyklu
| Charakteristický projektu |
Model (stratégia) | ||
| Novosť vývoja a dostupnosti zdrojov | Typické. Dobre vyvinutá technológia a metódy na riešenie problému | Atypické (inovatívne). Pre developera netradičné |
|
| Zdroje zákazníka a developera sú dostatočné na realizáciu projektu v krátkom časovom horizonte | Zdroje zákazníka alebo developera nestačia na realizáciu projektu v krátkom čase | ||
| Rozsah projektu | Malé a stredné projekty | Stredné a veľké projekty | Akékoľvek projekty |
| Termíny projektov | Až rok | Až niekoľko rokov. Vývoj jednej verzie môže trvať niekoľko týždňov až rok | |
| Uzavretie samostatných zmlúv pre jednotlivé verzie | Uzavretá je jedna zmluva. Verzia je konečným výsledkom projektu | Samostatná zmluva sa zvyčajne uzatvára na jednu verziu alebo niekoľko po sebe nasledujúcich verzií | |
| Definovanie základných požiadaviek na začiatku projektu | Áno | Áno | Nie |
| Požiadavky sa menia s vývojom projektu | Nie | Menší | Áno |
| Vývoj podľa iterácií (verzií) | Nie | Áno | Áno |
| Distribúcia middlewaru | Nie | Možno | Áno |
V tabuľke 3.1, hodnoty „Áno“ a „Nie“ by sa nemali považovať za prísne požiadavky. Napríklad menšie zmeny v požiadavkách počas vývoja projektu pri použití vodopádového modelu (napríklad pridanie niektorých nepredvídaných servisných funkcií) nie sú také zriedkavé a ak sa implementujú, prispievajú k zlepšeniu vzťahu medzi stranami. Podobne distribúcia middlewaru v špirálovom modeli je zbytočná a niekedy dokonca škodí procesu implementácie a skúšobnej prevádzky systému.
Pri vývoji systému by sa mal konečný produkt a middleware chápať takto:
- audit (opravné alebo experimentálne) - akékoľvek prevádzkové zmeny softvéru a informačného softvéru, ako aj databázy, ktoré momentálne nie sú potrebné na prenos na miesta implementácie a sú spojené s odstraňovaním chýb a zlepšovaním;
- modifikácia – akékoľvek prevádzkové zmeny softvéru a informačného softvéru, ako aj databázy, povinné na prenos na miesta implementácie a spôsobujúce zmenu prevádzkových charakteristík bez zmeny funkcií (zabezpečené), ako aj zmeny súvisiace s odstraňovaním chýb a zlepšovaním;
- verzia – akékoľvek zmeny softvéru a informačného softvéru, ako aj databázy, povinné na prenos do objektov implementácie, umožňujúce vykonávanie deklarovaných alebo dodatočných funkcií, ako aj zabezpečenie prechodu na nové operačné systémy a informačné prostredie;
- vývoj (poradie) – plánované zmeny informačného systému súvisiace so zavádzaním nových funkcií a zlepšovaním prevádzkových charakteristík, prechodom na nové informačné prostredie, zavádzaním nových súborov technických prostriedkov, nových informačných technológií a pod.
V súlade s vyššie uvedenou klasifikáciou je konečný produkt pre ktorýkoľvek z modelov životného cyklu povinnou verziou alebo radom systému. Vývoj vo frontoch je typický pre inkrementálnu stratégiu. Revízie a úpravy by sa mali považovať za middleware. Ako bolo uvedené vyššie, častá distribúcia revízií a úprav koncovým používateľom (najmä tým, ktorí sú zaneprázdnení inými výrobnými činnosťami) je nežiaduca. Podľa zmeny verzií informačných systémov v železničnej doprave by sa zmeny mali vykonávať maximálne raz až dvakrát ročne a úpravy by sa mali vykonávať maximálne raz za mesiac.
3.6. Metodiky, ktoré podporujú špirálový model
V súčasnosti existuje niekoľko metodík vývoja softvéru 1, ktoré možno odporučiť pri použití špirálového modelu životného cyklu. Najznámejšie z nich sú metodika pre rýchly vývoj aplikácií (RAD) a extrémne programovanie (eXtreme Programming, XP – autor Kent Beck, 1999).
3. Uveďte stručný popis metodík a.
Prednáška 2.
Koncept životného cyklu a model životného cyklu. Kaskádový model životného cyklu. Krokový model so stredným ovládaním. Špirála ModelJ C. ProcesyJ CBY. Rýchly vývoj aplikácií (RAD). Extrémne programovanie (XP). Rational Unified Process (RUP). Microsoft Solution Framework (MSF). Vlastná metóda vývoja (metodikyOracle).
2.1. Koncepcia životného cyklu a model životného cyklu
Životný cyklus IS –časové obdobie, ktoré začína okamihom prijatia rozhodnutia o potrebe vytvorenia IP a končí okamihom jeho úplného stiahnutia z používania. Životný cyklus informačného systému možno znázorniť ako sériu udalostí, ktoré sa vyskytujú v systéme počas procesu jeho tvorby a používania.
Model životného cyklu sa chápe akoštruktúra, ktorá definuje postupnosť vykonávania a vzťahy procesov, akcií a úloh, ktoré sa vykonávajú počas vývoja, prevádzky a údržby softvérového produktu počas celej životnosti systému, od určenia požiadaviek až po koniec jeho používania. (snímka 2) .
Model životného cyklu softvéru zahŕňa (snímka 3) : etapy, výsledky práce v každej etape, kľúčové udalosti - body ukončenia práce a rozhodovania.
Pod etapa sa chápe ako časť procesu tvorby softvéru, ohraničená určitým časovým rámcom a končiaca vydaním konkrétneho produktu (modely, softvérové komponenty, dokumentácia), určená požiadavkami špecifikovanými pre túto etapu.
Za extrémny prípad modelu životného cyklu možno považovať takzvaný model „black box“ alebo „code and fix“, čo vlastne znamená absenciu akéhokoľvek modelu. V tomto prípade nie je možné identifikovať žiadne racionálne fázy v procese vývoja softvéru, pretože neexistuje žiadne plánovanie a organizácia práce.
V súčasnosti sú známe a používané nasledujúce modely životného cyklu:
Kaskádový model(typické pre obdobie 1970-1980);
Krokový model so stredným ovládaním(typické pre obdobie 1980-1985);
Špirálový model(typické pre obdobie po roku 1986)
2.2. Kaskádový model životného cyklu
V roku 1970 publikoval softvérový expert Winston Royce široko uznávaný článok, v ktorom vyjadril svoje názory na techniku, ktorá sa neskôr stala známou ako model vodopádu. (snímka 4) .
Následne bol tento model regulovaný mnohými regulačnými dokumentmi, najmä známym štandardom amerického ministerstva obrany Dod-STD-2167A a ruskými štandardmi série GOST 34.
Kaskádový modelzabezpečuje postupnú realizáciu všetkých etáp projektu v presne stanovenom poradí. Prechod do ďalšej fázy znamená úplné dokončenie práce v predchádzajúcej fáze.
Základné vlastnosti takzvaného „čistého“ kaskádového modelu sú nasledovné:
Stanovenie požiadaviek na systém pred jeho dodaním zákazníkovi;
Postupné vykonávanie etáp.
Prechod do ďalšej etapy projektu až po úplnom dokončení prác v súčasnej etape, bez návratu k ukončeným etapám.
Žiadne dočasné prekrývanie etáp
Bez návratu do predchádzajúcich fáz
Dostupnosť výsledkov až na konci vývoja.
Výhody použitia kaskádového modelu sú nasledovné:
v každej fáze sa vygeneruje kompletný súbor projektovej dokumentácie, ktorá spĺňa kritériá úplnosti a konzistentnosti;
fázy práce vykonávané v logickom slede umožňujú naplánovať načasovanie dokončenia všetkých prác a zodpovedajúce náklady.
Hlavnou nevýhodou tohto prístupu je, že samotný proces vytvárania systému nikdy úplne nezapadá do takejto rigidnej schémy, vždy je potrebné vracať sa k predchádzajúcim etapám a objasňovať alebo revidovať už prijaté rozhodnutia.
Ďalšie nevýhody vodopádového prístupu sú:
neskoré odhalenie problémov. Chyby sa identifikujú a odstraňujú iba v štádiu testovania, ktoré môže trvať dlho alebo sa nemusí nikdy dokončiť.
opustenie kalendára, oneskorenie pri získavaní výsledkov;
nadmerné množstvo dokumentácie;
neschopnosť rozdeliť systém na časti (celý produkt je vyvinutý naraz);
vysoké riziko vytvorenia systému, ktorý nezodpovedá meniacim sa potrebám používateľov.
Historicky ide o prvý model životného cyklu IS. Používal sa pre pomerne jednoduché informačné systémy, kedy každá aplikácia bola jedným, funkčne a informačne nezávislým blokom. Teraz je možné vodopádový model použiť na vytvorenie softvéru, pre ktorý sa dajú na úplnom začiatku vývoja celkom presne a úplne sformulovať všetky požiadavky, aby vývojári mali voľnosť pri ich technickej implementácii čo najlepšie.
Softvérový priemysel sa vyvíja rýchlym tempom, no nie je žiadnym tajomstvom, že proces vývoja má k dokonalosti ešte veľmi ďaleko a vyznačuje sa mnohými vnútornými problémami. Podľa štúdie Standish Group (www.standishgroup.com) je úspešná menej ako tretina softvérových projektov, zvyšok sa buď nezmestí do finančného a časového rámca, alebo skončí úplným neúspechom.
Hrdina pracujúci sám -
programátor je anachronizmus.
Edward Yordon
Spomínaná štúdia uvádza, že malé projekty sú najúspešnejšie a čím väčší projekt, tým väčšie riziko neúspechu. To naznačuje, že ako sa rozsah úlohy zvyšuje, manažéri nie sú schopní spravovať pridelené zdroje.
V skutočnosti problém zvyšovania zložitosti riadenia v závislosti od nárastu veľkosti organizácie nie je ani zďaleka nový, v programovaní však nadobúda nové tvary: ak nie je dostatok zdrojov na včasnú realizáciu projektu, jednoducho ich zväčšite. problém len prehĺbi a termín sa posunie ešte ďalej (hovoríme predovšetkým o ľudských zdrojoch, pretože ostatné sú v programovaní oveľa menej významné).
Prvýkrát sa o tom vážne diskutovalo po vydaní knihy Fredericka Brooksa The Mythical Man-Moon v roku 1975, ktorá sa neskôr stala klasikou. Je príznačné, že sa opakovane vydáva už mnoho rokov a jeho hlavné ustanovenia zostávajú stále v platnosti. Vo svojej neskoršej práci Brooks identifikoval dve zložky zložitosti vývoja softvéru: ťažkosti spojené so špecifikami vytvárania softvéru a náhodné - v tomto kontexte tie, ktoré sú spojené s obmedzeniami na úrovni rozvoja vedy a techniky. Tie druhé sú viac-menej úspešne prekonávané na ceste vedecko-technického pokroku, no tie prvé budú vždy sprevádzať vývoj softvéru.
Efektívne riadenie akéhokoľvek procesu je možné za predpokladu, že subjekt kontroly adekvátne vníma stav a správanie sa objektu kontroly. Čo sa týka tvorby softvéru, ide o veľmi náročnú úlohu, keďže proces vývoja je čisto intelektuálna, do značnej miery tvorivá činnosť, na ktorú nie je možné použiť pipeline alebo iné podobné metódy. Preto sa aktívne pokúšali prezentovať model procesu tvorby softvéru, ktorý by mohol v maximálnej miere zohľadňovať jeho vlastné vlastnosti a robiť ho zvládnuteľným.
Modely založené na inžinierskom prístupe
Model eliminácie chýb kódovania. Je to opísané nasledovne: 1) nastaviť úlohu; 2) vykonávať až do úspešného ukončenia alebo zrušenia; 3) skontrolujte výsledok; 4) v prípade potreby zopakujte postup od kroku 1.
Prirodzene, takýto model nijako neštrukturoval vývojový proces a o možnosti jeho efektívneho využitia najmä vo veľkých projektoch je zbytočné hovoriť.
Kaskádový model. Prvý model, ktorý sa stal všeobecne známym a skutočne štruktúroval proces vývoja, je kaskáda alebo vodopád. Vznikol po konferencii NATO o vede a technike v roku 1968, kde sa uvažovalo o podobných otázkach, a rozdeľuje proces tvorby softvérového produktu na postupné etapy (treba podotknúť, že už v tom čase ho používali rôzni vývojári, ale ani počet ani obsah etáp nezjednotený).
Kaskádový model krátko po svojom zrode upravil Winst Royce s prihliadnutím na vzájomnú závislosť etáp a potrebu návratu k predchádzajúcim stupňom, čo môže byť spôsobené napríklad neúplnými požiadavkami alebo chybami pri tvorbe úloha. V tejto „reverzibilnej“ podobe kaskádový model existoval dlho a bol základom mnohých projektov (obr. 1).
Praktické využitie tohto modelu však odhalilo mnohé z jeho nedostatkov, z ktorých hlavným bolo, že je vhodnejší pre tradičné typy inžinierskych činností ako pre vývoj softvéru. Ako jeden z najväčších problémov sa ukázala najmä jeho „predispozícia“ k prípadným nezrovnalostiam medzi výsledným produktom a požiadavkami, ktoré naň boli kladené. Hlavným dôvodom je to, že úplne vytvorený produkt sa objavuje až v neskorších fázach vývoja, ale keďže prácu v rôznych fázach zvyčajne vykonávali rôzni špecialisti a projekt sa presúval z jednej skupiny do druhej, potom podľa princípu pokazeného telefónu sa ukázalo, že výstup nebol úplne taký, ako sa pôvodne očakávalo.
Model v tvare V. Bol navrhnutý práve preto, aby sa odstránili nedostatky kaskádového modelu a názov - v tvare V, alebo kĺbový - sa objavil pre jeho špecifické grafické znázornenie (obr. 2).
Model v tvare V umožnil výrazne zlepšiť kvalitu softvéru vďaka zameraniu na testovanie a tiež do značnej miery vyriešil problém súladu vytvoreného produktu s predloženými požiadavkami vďaka overovacím a certifikačným postupom v počiatočných fázach vývoj (bodkované čiary na obrázku označujú závislosť fáz plánovania/nastavenia problému a testovania/akceptovania).
Vo všeobecnosti je však model v tvare V len modifikáciou kaskádového modelu a má veľa svojich nevýhod. Obe sú najmä zle prispôsobené prípadným zmenám požiadaviek zákazníkov. Ak proces vývoja trvá dlho (niekedy až niekoľko rokov), potom môže byť výsledný produkt pre zákazníka v skutočnosti nepotrebný, keďže jeho potreby sa výrazne zmenili.
Rovnako dôležitá je aj otázka vplyvu vedecko-technického pokroku: požiadavky na softvér sa predkladajú s prihliadnutím na súčasný stav vedeckých a praktických výsledkov v oblasti hardvéru a softvéru, no sektor IT sa rozvíja veľmi rýchlo. zdĺhavý vývojový proces môže viesť k vytvoreniu produktu, ktorý je založený na zastaraných technológiách a ešte predtým, ako sa objaví, sa ukáže ako nekonkurencieschopný.
Dôležitá je aj otázka plánovacích ukazovateľov očakávanej funkčnosti, keďže v týchto modeloch nejde o nič iné ako o predpoklad: najmä je takmer nemožné určiť, akú rýchlosť spracovania dát vytvorený produkt poskytne alebo koľko pamäte zaberie pri štádium nastolenia problému. Ak sú takéto požiadavky jasne uvedené v podmienkach zmluvy medzi objednávateľom a zhotoviteľom, potom je pravdepodobné, že ich výsledné riešenie nebude spĺňať, hoci sa to dozvie až v záverečných fázach vývoja, keď budú mať hlavné zdroje k dispozícii už boli vynaložené.
V dôsledku toho bude zákazník nútený buď sa zmieriť s obmedzeniami riešenia vytvoreného na základe uvažovaných modelov, alebo investovať ďalšie prostriedky, aby skutočne dostal to, čo potrebuje.
Modely, ktoré zohľadňujú špecifiká vývoja softvéru
Keďže prvé modely boli požičané z tradičnej strojárskej oblasti, nezohľadňovali úplne špecifiká výroby softvéru. Nasledujúce modely sa však oveľa viac zameriavali na vlastnosti tohto druhu činnosti, ktorá má veľa zásadných rozdielov od konštrukcie objektov hmotného sveta.
Model založený na prototypovaní. Vzhľadom na to, že zákazník často nie je softvérový špecialista, väčšinou nevníma dobre „holé“ špecifikácie produktu. Aby sa prekonala informačná bariéra medzi zákazníkom a vývojárom a znížilo sa riziko získania produktu, ktorý nespĺňa požiadavky, začal sa používať prístup zameraný na vytváranie prototypov, ktoré sú plne alebo čiastočne funkčnými modelmi hotového systému. . Umožňuje výrazne zlepšiť vzájomné porozumenie medzi všetkými účastníkmi procesu vďaka dôslednému, evolučnému vývoju systému založenému na iteratívnom zdokonaľovaní prototypov.
Využitie tých druhých je podobné ako použitie zmenšených modelov stavieb v architektúre – umožňujú vizualizovať konečný výsledok, ich výstavba a úprava je oveľa menej náročná na prácu v porovnaní so stavbou a úpravou samotnej stavby.
Napriek nie všetkým výhodám sa však tento model tiež nestal všeliekom. Jeho hlavné problémy spočívali v rovine vzťahu „zákazník – realizátor“: prvý mal záujem o vytvorenie čo najpodrobnejších prototypov, aby sa znížilo riziko prijatia neadekvátneho systému, zatiaľ čo pre druhého znamenal každý nový prototyp dodatočné náklady. času a zdrojov a v dôsledku toho - zníženie ziskovosti projektu.
Prírastkový model. Softvér, na rozdiel napríklad od mikroobvodu, je možné uvádzať do prevádzky po častiach, čo znamená, že ho možno vyvíjať a dodávať zákazníkovi aj postupne. Presne na tom je založený inkrementálny model, ktorý zahŕňa fragmentáciu produktu na relatívne nezávislé komponenty, ktoré sa vyvíjajú a uvádzajú do prevádzky oddelene.
Tento model je výhodný pre zákazníka aj pre tvorcu systému, pretože umožňuje napredovať pri rešpektovaní záujmov oboch strán. Má to však svoje nevýhody. Rozdelenie na funkčné bloky vo všeobecnosti spomaľuje proces, pretože je potrebné zabezpečiť ich interakciu. Pre mnohé riešenia nie je tento spôsob použiteľný, pretože nie je možné od nich oddeliť jednotlivé komponenty, ktoré by bolo možné dodať a fungovať samostatne. Výrazne narastá aj záťaž riadiacich pracovníkov z dôvodu zložitosti úloh koordinácie prác na jednotlivých komponentoch systému a zvyšujú sa náklady na vykonávanie zmien už nainštalovaných hotových komponentov a prácu so zákazníkom.
Špirálový model. Navrhol ho Barry Boehm v roku 1988 a predstavoval významný prelom v chápaní podstaty vývoja softvéru, hoci vo všeobecnosti ide o kombináciu dvoch modelov: vodopádu a prototypovania (obr. 3).
Špirálový model Boema je zameraná na dizajn. Samotný vývoj softvéru prebieha až na poslednom otočení špirály podľa obvyklého kaskádového modelu, tomu však predchádza niekoľko návrhových iterácií založených na tvorbe prototypov – každá iterácia zahŕňa etapu identifikácie a analýzy rizík a najzložitejších úloh.
Keďže špirálový model pokrýva predovšetkým dizajn, vo svojej pôvodnej podobe nebol široko používaný ako metóda na riadenie celého životného cyklu tvorby softvéru. Jeho hlavná myšlienka, že proces práce na projekte môže pozostávať z cyklov, ktoré prechádzajú rovnakými fázami, však slúžila ako východisko pre ďalší výskum a stala sa základom najmodernejších modelov procesu vývoja softvéru.
Moderné modely
V polovici 90. rokov softvérový priemysel dozrel, komplexné projekty sa úspešne implementovali pomocou čoraz obľúbenejšej objektovo orientovanej metodológie a vývojové tímy si osvojili prístupy, ktoré ťažili z najvýznamnejších výhod predchádzajúcich modelov.
Objektovo orientovaný model. Táto metodika zahŕňa konštrukciu softvérového riešenia z hotových objektov, pre ktoré sú určené pravidlá ich interakcie, prenášanie objektov z jedného stavu do druhého. Tento model, ktorý zabezpečuje úplný súlad vývojového procesu s ustanoveniami objektovo orientovanej metodológie (objektovo orientovaná analýza, návrh, programovanie), je účinný vo veľkých projektoch, ako aj tam, kde tzv. nástroje rýchleho vývoja (RAD, Rapid Application Development), založené na týchto technológiách a obsahujúce hotové knižnice tried.
Samotné RAD systémy však nepodporujú vytváranie objektovo orientovaných riešení. Programátori, rozmaznaní nástrojmi, ktoré im umožňujú vytvárať produkty v priebehu niekoľkých hodín z hotových komponentov, ktoré predtým zaberali dni a mesiace práce, považujú za zbytočné trápiť sa podrobným štúdiom metodiky a UML, ba čo viac. neusilujú o formalizáciu svojich riešení vo forme tried vhodných na opätovné použitie.
Objektovo orientovaný model sa teda používa predovšetkým vo veľmi veľkých projektoch, kde sa venuje náležitá pozornosť fázam analýzy a návrhu a kde sú vývojári prísne kontrolovaní z hľadiska dodržiavania stanovených pravidiel.
Iteračný model. Tento model, ktorý prvýkrát navrhol Philippe Kratchen v roku 1995, kombinuje hlavné výhody špirálových, prírastkových, vodopádových, prototypových a objektovo orientovaných vývojových metód (obrázok 4). Získal si veľkú obľubu a v tej či onej forme sa používa v mnohých moderných projektoch.
Podľa iteračného modelu existujú štyri hlavné fázy životného cyklu vývoja softvéru (iniciácia, prieskum, konštrukcia a implementácia). V každej fáze projekt prechádza mnohými iteráciami, ktoré vedú k vytvoreniu funkčných verzií: v počiatočných fázach sa vytvárajú prototypy, vyjasňujú sa požiadavky a riešia sa najzložitejšie problémy; konečné vedú k vytvoreniu produktu, jeho skvalitneniu a rozšíreniu funkčnosti.
Iteračný model okrem hlavných fáz rozlišuje ešte dve skupiny procesov: pracovné (riadenie požiadaviek, analýza a návrh, implementácia, testovanie, nasadenie) a pomocné (riadenie konfigurácie a zmien, projekt a proces). Počet a podstata procesov sa líši v závislosti od potrieb vývojára, môžu mať aj svoje cykly, ktoré ani nemusia zodpovedať hlavným fázam. Výsledkom pracovných postupov však vždy je vytváranie verzií produktov.
Iteračný model, podobne ako špirálový model, umožňuje úspešne zvládnuť riziká. Ak sa pri práci na ďalšej verzii zistí, že mzdové náklady na implementáciu požadovanej funkcionality sú príliš vysoké, potom sa možno vyhnúť prekročeniu rozpočtu a zmeškaným termínom koreláciou priorít vývoja a mzdových nákladov na začiatku každej iterácie. Tento model je teda vhodný pre väčšinu typov softvérových projektov, ale jeho výhody sú badateľné najmä pri práci na produktoch určených na vstup na voľný trh, vzhľadom na počiatočné zameranie na vydávanie sekvenčných verzií.
Philip Kratchen už dlhší čas pracuje v spoločnosti Rational Software, ktorú teraz vlastní IBM. Práve z tohto dôvodu sa iteračný model stal základom RUP (Rational Unified Process) – jednej z najbežnejších metód integrovaného riadenia procesu vývoja softvéru. Na jeho základe bol vyvinutý hlavný konkurent RUP od Microsoftu, MSF (Microsoft Solutions Framework), ako aj podobný prístup od Borlandu - ALM (Application Lifecycle Management).
Modely rýchleho rozvoja. Mnohé obmedzenia v moderných metodológiách vývoja softvéru viedli k tomu, že vývojárske spoločnosti sa v mnohých ohľadoch podobali obrovským byrokratickým systémom. Prítomnosť veľkého množstva formálnych postupov a pravidiel výrazne zužuje slobodu konania každého jednotlivého programátora a mení ho na ozubené koliesko v obrovskom a nemotornom stroji. Napriek tomu, že takéto stroje sú schopné celkom úspešne zvládnuť úlohy, ktorým čelia, ich účinnosť je zvyčajne dosť nízka a špecifická produktivita jednotlivého vývojára je taká malá, že pre programátora možno považovať za normálne napísať niekoľko riadkov kódu. za deň.
Modely rýchleho vývoja, ako napríklad extrémne programovanie, sú navrhnuté tak, aby spochybňovali takéto formalistické prístupy. Ich podstata spočíva v odmietnutí všetkého zbytočného, čo priamo nesúvisí s tvorbou kvalitného softvérového produktu a za základ sa berú len najefektívnejšie metódy tvorby softvéru. Osobitná pozornosť sa venuje otázkam interakcie so zákazníkom, organizácii produktívnej práce a testovaniu. Mnohé z nápadov rýchleho rozvoja neboli nových, napríklad jednotkové testy sa už dlho používali v mnohých projektoch, ale keď sa spojili a stali sa povinnými na použitie, mali pozitívny účinok. O týchto metódach sa v poslednej dobe začalo hovoriť čoraz častejšie a ich prvky si začali požičiavať mnohé klasické modely.
V moderných podmienkach je rýchly vývoj veľmi módnym prístupom a používa sa čoraz aktívnejšie. Hlavnou výhodou je, že relatívne malé tímy vývojárov sú schopné dokončiť projekty za rovnaký čas, aký trvá rádovo väčším tímom, aby použili tradičnejšie metódy.
Sú tu však aj nevýhody, najmä rýchly vývoj nie je vhodný pre veľké projekty a je zameraný hlavne na malé a stredné projekty, navyše jeho efektívne využitie je možné len vtedy, ak majú tvorcovia softvéru veľmi vysokú kvalifikáciu a význam skúsenosti.
Prispôsobené a kombinované modely. V skutočnosti, ako sa modely životného cyklu vývoja softvéru vyvíjali, nové nápady úplne nenahradili staré. Je správnejšie zvážiť, že každý z nich má svoj vlastný rozsah pôsobnosti. Okrem toho sa v každom konkrétnom prípade môže ukázať, že neexistuje žiadna technika, ktorá by bola ideálne vhodná na riešenie daného problému. V tomto prípade by manažéri softvérových projektov mali zvážiť možnosti prispôsobenia modelov špecifickým potrebám alebo použitie kombinovaných metód, ktoré zahŕňajú prvky rôznych prístupov. Napríklad úspech rýchleho vývoja viedol k tomu, že konzervatívnejšie modely prijali jeho najúčinnejšie techniky a začali ich používať ako súčasť svojich procesov.
prezentácia finálnych dokumentov, procesných metrík, kritérií pre začatie a ukončenie úloh a prechod na ďalší krok v procese; výber testovacích metód pre vybranú triedu softvéru na overenie správneho vykonania testovacích úloh; vývoj špeciálnych šablón dokumentov na zdokumentovanie procesu testovania týkajúceho sa každého kroku procesu testovania.Tie. vychádza sa z predpokladu, že každá práca bude vykonaná tak dôkladne, že po jej dokončení a dokončení ďalšieho kroku už nebude potrebné vracať sa k predchádzajúcemu.
Vývojár skontroluje medzivýsledok pomocou rôznych známych overovacích metód a zaznamená ho ako hotový štandard pre ďalší proces.
Podľa tohto modelu životného cyklu sa práca a úlohy procesu vývoja zvyčajne vykonávajú postupne, ako je znázornené na diagrame. Pomocné a organizačné procesy (kontrola požiadaviek, riadenie kvality atď.) sa však zvyčajne vykonávajú súbežne s procesom vývoja. V tomto modeli je zabezpečený návrat k počiatočnému procesu po údržbe a oprave chýb.
Zvláštnosťou tohto modelu je, že zachytáva postupné procesy vývoja softvérového produktu. Je založený na továrenskom modeli, kde výrobok prechádza fázami od koncepcie až po výrobu, následne je odovzdaný zákazníkovi ako hotový výrobok, ktorého výmena nie je zabezpečená, hoci náhrada za iný podobný výrobok je možná v prípade reklamácia alebo niektoré jej časti zlyhali.
Nevýhody tohto modelu:
- proces vytvárania PS nie vždy zapadá do takejto rigidnej formy a postupnosti akcií;
- nezohľadňujú sa zmenené potreby používateľov, zmeny vonkajšieho prostredia, ktoré spôsobia zmeny v požiadavkách na systém počas jeho vývoja;
- veľká medzera medzi časom zavedenia chyby (napríklad vo fáze návrhu) a časom jej odhalenia (počas údržby), čo vedie k veľkému prepracovaniu softvéru.
Pri použití kaskádového modelu sa môžu vyskytnúť nasledujúce rizikové faktory:
- požiadavky na softvér nie sú jasne formulované alebo nezohľadňujú vyhliadky vývoja OS, prostredia atď.;
- veľký systém, ktorý neumožňuje rozklad komponentov, môže spôsobiť problémy s ich umiestnením do pamäte alebo na platformy, ktoré nie sú uvedené v požiadavkách;
- rýchle zmeny v technológii a požiadavkách môžu zhoršiť proces vývoja jednotlivých častí systému alebo systému ako celku;
- obmedzenia zdrojov (ľudských, softvérových, technických a pod.) počas vývoja môžu zúžiť jednotlivé možnosti implementácie systému;
výsledný produkt môže byť nepoužiteľný z dôvodu nepochopenia požiadaviek alebo funkcií systému vývojármi alebo z dôvodu nedostatočného testovania. Výhody implementácie systému pomocou kaskádového modelu sú nasledovné:
- všetky úlohy subsystémov a systému sú implementované súčasne (t. j. ani jedna úloha nie je zabudnutá), čo prispieva k vytvoreniu stabilných spojení a vzťahov medzi nimi;
- plne vyvinutý systém s dokumentáciou je jednoduchší na údržbu, testovanie, opravu chýb a vykonávanie zmien nie náhodne, ale cielene, počnúc požiadavkami (napríklad pridanie alebo nahradenie niektorých funkcií) a opakovaním procesu.
Kaskádový model možno považovať za model životného cyklu vhodný na vytvorenie prvej verzie softvéru za účelom testovania funkcií v ňom implementovaných. Pri údržbe a prevádzke sa môžu objaviť rôzne druhy chýb, ktorých náprava si vyžiada opakovanie všetkých procesov, počnúc objasnením požiadaviek.
2.2.2. Prírastkový model životného cyklu
Prvá vytvorená prechodná verzia systému (vydanie 1) implementuje časť požiadaviek, do nasledujúcej verzie (vydanie 2) sa pridajú ďalšie požiadavky a tak ďalej, až kým nie sú definitívne splnené všetky požiadavky a vyriešené problémy s vývojom systému. Pre každú medziverziu sa v etapách životného cyklu vykonávajú potrebné procesy, práce a úlohy vrátane analýzy požiadaviek a vytvorenia novej architektúry, ktorú je možné vykonávať súčasne.
Procesy vypracovania technického návrhu PS, jeho programovania a testovania, montáže a kvalifikačných skúšok PS sa vykonávajú pri tvorbe každej ďalšej verzie.
V súlade s týmto modelom životného cyklu, ktorého procesy sú takmer rovnaké ako vo vodopádovom modeli, sa pozornosť sústreďuje na vývoj nejakej úplnej prechodnej verzie a úlohy vývojového procesu sa vykonávajú postupne alebo čiastočne paralelne pre počet jednotlivých štruktúr strednej verzie.
Práce a úlohy vývojového procesu pre ďalšiu verziu systému s dodatočnými požiadavkami alebo funkciami je možné vykonávať opakovane v rovnakom poradí pre všetky prechodné verzie systému. Procesy údržby a prevádzky môžu byť implementované paralelne s procesom vývoja verzie kontrolou čiastočne implementovaných požiadaviek v každej prechodnej verzii a tak ďalej, kým sa nezíska kompletná verzia systému. Podporné a organizačné procesy životného cyklu sa zvyčajne vykonávajú súbežne s procesom vývoja verzie systému a do konca vývoja sa zbierajú dáta, na základe ktorých je možné stanoviť úroveň úplnosti a kvality vyrábaného systému.
Pri použití tohto modelu je potrebné vziať do úvahy nasledujúce rizikové faktory:
- požiadavky sú vypracované s prihliadnutím na možnosť ich zmeny počas predaja produktu;
- všetky možnosti systému musia byť implementované od začiatku;
- rýchle zmeny v technológii a systémových požiadavkách môžu viesť k narušeniu výslednej štruktúry systému;
- Obmedzenia v poskytovaní zdrojov (výkonní pracovníci, financie) môžu viesť k oneskoreniu uvedenia systému do prevádzky.
Tento model životného cyklu sa odporúča použiť v prípadoch, keď:
- je žiaduce rýchlo implementovať niektoré funkcie systému vytvorením strednej verzie produktu;
- systém sa rozloží na samostatné komponenty, ktoré sa môžu predávať ako nejaké nezávislé medziprodukty alebo hotové výrobky;
- je možné navýšiť financie na rozvoj jednotlivých častí systému.
V rámci konkrétnych modely životného cyklu, ktoré predpisujú pravidlá organizácie vývoja softvéru v rámci daného odvetvia alebo organizácie, konkrétnejšie vývojové procesy. Od štandardov sa líšia predovšetkým väčším detailom a jasným popisom väzieb medzi jednotlivcami druhy činností, definovanie dátových tokov (dokumentov a artefaktov) počas životný cyklus. Takýchto modelov je pomerne veľa, pretože v podstate zakaždým si organizácia definuje svoj vlastný vývojový proces, ako základ pre tento proces, niektoré model životného cyklu softvéru. V tejto prednáške sa budeme zaoberať len niekoľkými modelmi. Žiaľ, je veľmi ťažké vybrať kritériá, podľa ktorých by bolo možné poskytnúť nejakú užitočnú klasifikáciu známych modely životného cyklu.
Najznámejšou a dlhodobo používanou zostala takzvaná kaskáda resp vodopád model životného cyklu, o ktorej sa predpokladá, že bola prvýkrát jasne formulovaná v práci a následne zachytená v normách Ministerstva obrany USA v 70-80 rokoch XX storočia. Tento model zahŕňa postupné vykonávanie rôznych druhy činností, počnúc vývojom požiadaviek a končiac údržbou, s jasným vymedzením hraníc medzi fázami, pri ktorých sa súbor dokumentov vytvorených v predchádzajúcej fáze prenáša ako vstup do ďalšej. Takže všetci Druh činnosti realizované v jednej fáze životný cyklus. Postupnosť vývojových krokov navrhovaných v článku je znázornená na obr. 2.2. "klasický" kaskádový model zahŕňa iba postup vpred podľa tejto schémy: všetko potrebné na vykonanie ďalšej činnosti musí byť pripravené v priebehu predchádzajúcej práce.
Ak si však článok pozorne prečítate, ukáže sa, že nepredpisuje dodržiavanie tohto konkrétneho poradia práce, ale predstavuje model iteračného procesu (pozri obr. 2.3) - vo svojej sekvenčnej podobe bol tento model zjavne zafixovaný v mysliach úradníkov z ministerstiev a manažérov firiem spolupracujúcich s týmito ministerstvami na základe zmlúv. Pri skutočnej práci podľa modelu, ktorý umožňuje pohyb iba jedným smerom, zvyčajne nastanú problémy, keď sa zistia chyby a chyby urobené v počiatočných fázach. Ešte ťažšie je však vysporiadať sa so zmenami v prostredí, v ktorom sa softvér vyvíja (môžu to byť zmeny v požiadavkách, zmeny dodávateľov, zmeny v politike vyvíjajúcej alebo prevádzkovej organizácie, zmeny v priemyselných štandardoch, vznik konkurencie). produkty atď.).
V súlade s týmto modelom je možné pracovať len vtedy, ak je možné vopred predvídať možné peripetie napredovania projektu a starostlivo zbierať a integrovať informácie v prvých fázach, aby bolo možné výsledky neskôr použiť bez ohľadu na možné zmeny. .
Medzi vývojármi a výskumníkmi zaoberajúcimi sa vývojom komplexného softvéru sú takmer od samého začiatku priemyslu výroby softvéru (pozri napríklad) veľmi populárne modely evolučných alebo iteračných procesov, pretože majú väčšiu flexibilitu a schopnosť pracovať v meniacom sa prostredí.
Iteratívne alebo prírastkové modely(známych je niekoľko takýchto modelov) zahŕňajú rozdelenie vytvoreného systému na sadu dielov, ktoré sa vyvíjajú pomocou niekoľkých po sebe nasledujúcich prechodov celého diela alebo jeho časti.
Pri prvej iterácii sa vyvinie časť systému, ktorá je nezávislá od ostatných. V tomto prípade sa na ňom dokončí väčšina alebo aj celý cyklus práce, potom sa vyhodnotia výsledky a pri ďalšej iterácii sa buď prerobí prvý kus, alebo sa vyvinie ďalší, čo môže závisieť od prvého, resp. revízia prvého kusu je nejakým spôsobom kombinovaná s pridaním nových funkcií. Výsledkom je, že pri každej iterácii je možné analyzovať medzivýsledky práce a reakcie všetkých zainteresovaných strán vrátane používateľov na ne a pri ďalších iteráciách vykonať nápravné zmeny. Každá iterácia môže obsahovať kompletnú sadu druhy činností- od analýzy požiadaviek až po uvedenie do prevádzky ďalšieho softvéru.
Kaskádový model s možnosťou návratu k predchádzajúcemu kroku v prípade potreby revízie jeho výsledkov sa stáva iteratívnym.
Iteračný proces predpokladá, že inak činnosti nie sú pevne viazané na určité štádiá vývoja, ale vykonávajú sa podľa potreby, niekedy sa opakujú, kým sa nedosiahne požadovaný výsledok.
Spolu s flexibilitou a schopnosťou rýchlo reagovať na zmeny, iteračné modely priniesť ďalšiu zložitosť projektový manažment a sledovanie jeho pokroku. Pri použití iteratívneho prístupu je oveľa ťažšie primerane posúdiť aktuálny stav projektu a plánovať dlhodobý vývoj, ako aj predpovedať načasovanie a zdroje potrebné na zabezpečenie určitej kvality výsledku.
Rozšírením myšlienky iterácií je
