Koncept životného cyklu softvéru. Modely životného cyklu informačných systémov

Životný cyklus softvér

Jedným zo základných pojmov metodológie návrhu softvéru je koncept jeho životného cyklu softvéru (SO). Životný cyklus softvéru je nepretržitý proces, ktorý sa začína od okamihu rozhodnutia o potrebe jeho vytvorenia a končí okamihom jeho úplného vyradenia z prevádzky.

Hlavná normatívny dokument, upravujúca životný cyklus softvéru je medzinárodná norma ISO/IEC 12207 (ISO - International Organization of Standardization, IEC - International Electrotechnical Commission). Definuje štruktúru životného cyklu obsahujúcu procesy, činnosti a úlohy, ktoré je potrebné vykonať pri tvorbe softvéru. V tomto štandarde Softvér (softvérový produkt) definovaný ako súbor počítačové programy, postupy a prípadne súvisiacu dokumentáciu a údaje. Proces je definovaný ako súbor vzájomne súvisiacich akcií, ktoré transformujú niektoré vstupné dáta na výstupné dáta. Každý proces je charakterizovaný určitými úlohami a metódami ich riešenia, vstupnými údajmi získanými z iných procesov a výsledkami.

Štruktúra životného cyklu softvéru podľa normy ISO/IEC 12207 je založená na troch skupinách procesov:

· hlavné procesy životného cyklu softvéru (nákup, dodávka, vývoj, prevádzka, podpora);

· pomocné procesy, ktoré zabezpečujú implementáciu hlavných procesov (dokumentácia, konfiguračný manažment, zabezpečenie kvality, overovanie, certifikácia, hodnotenie, audit, riešenie problémov);

· organizačné procesy (riadenie projektu, tvorba infraštruktúry projektu, definovanie, hodnotenie a zlepšovanie samotného životného cyklu, školenia).

Modely životného cyklu softvéru

Model životného cyklu- štruktúra, ktorá určuje postupnosť vykonávania a vzťah fáz a fáz vykonávaných počas celého životného cyklu. Model životného cyklu závisí od špecifík softvéru a špecifických podmienok, v ktorých je vytvorený a funguje. Hlavné modely životného cyklu sú nasledovné.

1. Kaskádový model(do 70. rokov XX. storočia) určuje sekvenčný prechod do ďalšej etapy po dokončení predchádzajúcej.

Tento model sa vyznačuje automatizáciou jednotlivých nesúvisiacich úloh, ktorá nevyžaduje informačnú integráciu a kompatibilitu, softvérové, technické a organizačné rozhranie.

Dôstojnosť: dobré ukazovatele z hľadiska času vývoja a spoľahlivosti pri riešení jednotlivých problémov.

Chyba: Nevzťahuje sa na veľké a zložité projekty kvôli variabilite systémových požiadaviek počas dlhého obdobia návrhu.

2. Iteračný model(70-80-te roky XX storočia) zodpovedá technológii dizajnu „zdola nahor“. Umožňuje opakovaný návrat do predchádzajúcich fáz po dokončení ďalšej fázy;

Model umožňuje zovšeobecnenie získaných konštrukčných riešení jednotlivých problémov na celosystémové riešenia. V tomto prípade je potrebné revidovať predtým formulované požiadavky.

dôstojnosť: schopnosť rýchlo vykonať úpravy projektu.

Chyba: pri veľkom počte iterácií sa zvyšuje čas návrhu, vznikajú nezrovnalosti v konštrukčných riešeniach a dokumentácii a dochádza k zámene funkčnej a systémovej architektúry vytvoreného softvéru. Potreba prerobiť starý alebo vytvoriť nový systém môže nastať ihneď po realizačnej alebo prevádzkovej fáze.

3. Špirálový model(80-90-te roky XX storočia) zodpovedá technológii dizajnu „zhora nadol“. Zahŕňa použitie prototypu softvéru, ktorý umožňuje rozšírenie softvéru. Návrh systému cyklicky opakuje cestu od detailovania požiadaviek k detailnému programovému kódu.

Pri návrhu architektúry systému sa najprv určí zloženie funkčných subsystémov a vyriešia sa celosystémové problémy (organizácia integrovanej databázy, technológia na zber, prenos a ukladanie informácií). Potom sa formulujú jednotlivé problémy a vyvíja sa technológia na ich riešenie.

Pri programovaní sa najskôr vyvinú hlavné softvérové ​​moduly a potom moduly, ktoré vykonávajú jednotlivé funkcie. Najprv je zabezpečená interakcia modulov medzi sebou a s databázou a následne implementácia algoritmov.

Výhody:

1. zníženie počtu opakovaní a následne počtu chýb a nezrovnalostí, ktoré je potrebné opraviť;

2. skrátenie času návrhu;

3. zjednodušenie tvorby projektovej dokumentácie.

Chyba: vysoké požiadavky na kvalitu celosystémového úložiska (spoločná dizajnová databáza).

Základom je špirálový model technológie rýchleho vývoja aplikácií alebo technológia RAD (rýchly vývoj aplikácií), ktorá zahŕňa aktívnu účasť koncových používateľov budúceho systému na procese jeho tvorby. Hlavné fázy informačného inžinierstva sú nasledovné:

· Analýza a plánovanie informačnej stratégie. Používatelia sa spolu so špecializovanými vývojármi podieľajú na identifikácii problémovej oblasti.

· Dizajn. Používatelia sa pod vedením vývojárov podieľajú na technickom návrhu.

· Stavebníctvo. Vývojári navrhujú pracovnú verziu softvéru pomocou jazykov 4. generácie;

· Implementácia. Vývojári školia používateľov na prácu v novom softvérovom prostredí.

Požiadavky na vyvinutý softvér, stanovené vo fázach tvorby a analýzy, sú prísne zdokumentované vo forme technických špecifikácií a zaznamenávajú sa počas celého vývoja projektu. Každá etapa končí vydaním kompletnej dokumentácie (TOR, EP, TP, RP), ktorá je dostatočná na to, aby vo vývoji mohol pokračovať ďalší vývojový tím. Kritériom kvality vývoja pri tomto prístupe je presnosť plnenia technických špecifikácií. Hlavným zameraním vývojárov je dosiahnutie optimálnych hodnôt technické vlastnosti vyvinutý softvér - výkon, množstvo obsadenej pamäte atď.

Výhody kaskádový model:

• v každej fáze sa vygeneruje kompletný súbor projektovej dokumentácie, ktorá spĺňa kritériá úplnosti a konzistentnosti;
• etapy 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.

Kaskádový prístup sa dobre osvedčil pri konštrukcii softvérových systémov, na ktoré môžu byť všetky požiadavky úplne a jasne formulované už na začiatku projektu. Pokiaľ toto všetko kontrolujú normy a rôzne akceptačné komisie štátu, schéma funguje dobre.

Nedostatky kaskádový model:

• Chyby sa identifikujú a odstraňujú iba v štádiu testovania, čo môže trvať veľa času;
• skutočné projekty často vyžadujú odchýlky od štandardnej postupnosti krokov;
• cyklus je založený na presnej formulácii počiatočných požiadaviek na softvér, v skutočnosti sú na začiatku projektu požiadavky zákazníka stanovené len čiastočne;
• výsledky práce sú zákazníkovi k dispozícii až po dokončení projektu.

Iteračný model životného cyklu PS

S rastom komerčných projektov sa ukázalo, že nie vždy je možné detailne rozpracovať návrh budúceho systému, keďže mnohé aspekty jeho fungovania v dynamických oblastiach činnosti (podnikania) sa pri vytváraní systému menia. Bolo potrebné zmeniť proces vývoja, aby sa zabezpečilo, že potrebné korekcie budú vykonané po dokončení ktorejkoľvek fázy vývoja. Takto sa objavil iteračný model životného cyklu PS, nazývaný model so stredným riadením alebo model s cyklickým opakovaním fáz.

V takejto situácii nadobúda veľký význam fáza formulovania požiadaviek, vypracovania špecifikácií a vytvorenia plánu systému. Za všetky následné zmeny dizajnu sú osobne zodpovední softvéroví architekti. Objem dokumentácie dosahuje tisíce strán a počet schvaľovacích stretnutí je enormný. Mnoho projektov nikdy neopustí fázu plánovania a upadne do „paralýzy analýzy“. Jeden z možné spôsoby Výnimkou z takýchto situácií je prototypovanie (prototypovanie).

Rozloženie

Zákazník často nevie formulovať požiadavky na vstup, spracovanie alebo výstup dát do budúcnosti softvérový produkt. Vývojár môže pochybovať o vhodnosti produktu pre operačný systém, o forme dialógu s používateľom alebo o účinnosti algoritmu. V takýchto prípadoch je vhodné použiť prototypovanie. Hlavným účelom prototypovania je odstrániť neistotu v požiadavkách zákazníkov. Layout (prototypovanie) je proces vytvárania modelu požadovaného produktu.

Model môže mať nasledujúce formy.

1. Rozloženie papiera (nakreslený diagram dialógu človek-stroj) alebo rozloženie na počítači.
2. Pracovné rozloženie, ktoré implementuje niektoré z požadovaných funkcií.
3. Existujúci program, ktorého výkon je potrebné zlepšiť.

Ako je znázornené na obrázku 5.7, prototypovanie je založené na opakovaných iteráciách, na ktorých sa zúčastňuje zákazník a vývojár.

Postupnosť akcií pri prototypovaní je znázornená na obr. 5.8. Prototypovanie začína zhromaždením a objasnením požiadaviek na vytváraný softvérový systém. Vývojár a zákazník spoločne určujú ciele softvéru, stanovujú, ktoré požiadavky sú známe a ktoré je potrebné ďalej definovať. Potom sa vykoná rýchly návrh. Zameriava sa na vlastnosti, ktoré by mali byť viditeľné pre používateľa. Rýchly dizajn vedie ku konštrukcii rozloženia. Rozloženie posúdi zákazník a použije sa na objasnenie softvérových požiadaviek. Iterácie pokračujú, kým maketa neodhalí všetky požiadavky zákazníka a neumožní dizajnérovi pochopiť, čo je potrebné urobiť.

Výhodou prototypovania je schopnosť zabezpečiť, aby boli určené kompletné systémové požiadavky. Nevýhody rozloženia:

• zákazník si môže pomýliť dizajn s produktom;
• vývojár si môže pomýliť maketu s produktom.

Treba vysvetliť podstatu nedostatkov. Keď zákazník uvidí fungujúcu verziu softvéru, prestane si uvedomovať, že pri hľadaní fungujúcej verzie softvéru zostáva veľa problémov s kvalitou a kvalitou nevyriešených. pohodlie podpory systémov. Keď o tom vývojár povie zákazníkovi, odpoveďou môže byť rozhorčenie a požiadavka rýchlej transformácie rozloženia na funkčný produkt. To má negatívny vplyv na riadenie vývoja softvéru.

Na druhej strane, na rýchle získanie funkčného rozloženia vývojár často robí určité kompromisy. Napríklad programovací jazyk alebo operačný systém nemusia byť najvhodnejšie. Pre jednoduchú demonštráciu možno použiť neefektívny (jednoduchý) algoritmus. Po určitom čase vývojár zabudne na dôvody, prečo tieto nástroje nie sú vhodné. Výsledkom je, že do systému je integrovaná aj zďaleka nie ideálna zvolená možnosť.

Pred zvážením iných modelov životného cyklu softvéru, ktoré boli nahradené kaskádový model, mali by sme sa zamerať na stratégie navrhovania softvérových systémov. Je to stratégia návrhu softvéru, ktorá do značnej miery určuje model životného cyklu softvéru.

Stratégie návrhu softvéru

Existujú tri stratégie navrhovania softvérových systémov:

• jeden priechod (kaskádová stratégia diskutovaná vyššie) – lineárna postupnosť fáz návrhu;
• prírastkovú stratégiu. Na začiatku procesu sú definované všetky užívateľské a systémové požiadavky, zvyšok návrhu prebieha ako postupnosť verzií. Prvá verzia implementuje časť plánovaných schopností, ďalšia verzia implementuje dodatočné schopnosti atď., kým sa nezíska kompletný systém;
• evolučnej stratégie. Systém je tiež zostavený ako postupnosť verzií, ale nie všetky požiadavky sú definované na začiatku procesu. Požiadavky sa spresňujú pri vývoji verzií. Charakteristiky stratégií návrhu softvéru v súlade s požiadavkami normy IEEE/EIA 12207 sú uvedené v

Vývoj softvéru nie je možný bez pochopenia takzvaného životného cyklu softvéru. Bežný používateľ to nemusí vedieť, ale je vhodné ovládať základné štandardy (neskôr si povieme, prečo je to potrebné).

Čo je životný cyklus vo formálnom zmysle?

Životným cyklom akejkoľvek aplikácie sa zvyčajne rozumie doba jej existencie, počnúc fázou vývoja a až do okamihu úplného opustenia používania vo zvolenej oblasti použitia až po úplné stiahnutie aplikácie z používania.

Rozprávanie jednoduchým jazykom, informačné systémy vo forme programov, databáz či dokonca „operačných systémov“ sú žiadané len vtedy, ak sú dáta a možnosti, ktoré poskytujú, aktuálne.

Predpokladá sa, že definícia životného cyklu sa v žiadnom prípade nevzťahuje na testovacie aplikácie, ako sú beta verzie, ktoré sú v prevádzke najnestabilnejšie. Samotný životný cyklus softvéru závisí od mnohých faktorov, medzi ktorými jednu z hlavných úloh zohráva prostredie, v ktorom sa bude program používať. Je však možné aj zvýrazniť Všeobecné podmienky, používané pri definovaní pojmu životný cyklus.

Počiatočné požiadavky

• formulácia problému;
• analýza vzájomných požiadaviek budúceho softvéru pre systém;
• dizajn;
• programovanie;
• kódovanie a kompilácia;
• testovanie;
• ladenie;
• implementáciu a údržbu softvérového produktu.

Vývoj softvéru pozostáva zo všetkých vyššie spomenutých etáp a nezaobíde sa aspoň bez jednej z nich. Na kontrolu takýchto procesov však boli vytvorené špeciálne normy.

Štandardy procesov životného cyklu softvéru

Spomedzi systémov, ktoré predurčujú podmienky a požiadavky na takéto procesy, dnes môžeme vymenovať iba tri hlavné:

• GOST 34.601-90;
• ISO/IEC 12207:2008;
• Oracle CDM.

Pre druhú medzinárodný štandard existuje ruský analóg. Ide o GOST R ISO/IEC 12207-2010, ktorá je zodpovedná za systémové a softvérové ​​inžinierstvo. Ale životný cyklus softvéru opísaný v oboch pravidlách je v podstate identický. Toto je vysvetlené celkom jednoducho.

Typy softvéru a aktualizácie

Mimochodom, pre väčšinu v súčasnosti známych multimediálnych programov sú prostriedkom na uloženie základných konfiguračných parametrov. Využitie softvéru tohto typu je, samozrejme, značne obmedzené, no pochopenie všeobecných princípov práce s rovnakými prehrávačmi médií nezaškodí. A preto.

V skutočnosti zahŕňajú životný cyklus softvéru iba na úrovni aktualizácie verzie samotného prehrávača alebo inštalácie kodekov a dekodérov. A audio a video transkodéry sú neoddeliteľnou súčasťou každého audio alebo video systému.

Príklad založený na FL Studio

Spočiatku sa virtuálny štúdiový sekvencer FL Studio nazýval Fruity Loops. Životný cyklus softvéru v počiatočnej úprave vypršal, no aplikácia sa do istej miery transformovala a nadobudla súčasnú podobu.

Ak hovoríme o fázach životného cyklu, po prvé, vo fáze vzniku problému bolo stanovených niekoľko povinných podmienok:

• vytvorenie bubnového modulu podobného rytmickým strojom ako Yamaha RX, ale s použitím jednorazových vzoriek alebo sekvencií vo formáte WAV nahraných naživo v štúdiách;
• integrácia do OS Windows;
• možnosť exportu projektu vo formátoch WAV, MP3 a OGG;
• Kompatibilita projektov s doplnkovou aplikáciou Fruity Tracks.

Vo fáze vývoja boli použité nástroje programovacieho jazyka C. Platforma ale vyzerala dosť primitívne a koncovému používateľovi neposkytovala požadovanú kvalitu zvuku.

V tomto smere museli vývojári vo fáze testovania a ladenia ísť cestou nemeckej korporácie Steinberg a v požiadavkách na hlavný zvukový ovládač uplatniť podporu pre režim Full Duplex. Kvalita zvuku sa zvýšila a umožňuje vám meniť tempo, výšku tónu a aplikovať ďalšie efektové efekty v reálnom čase.

Za koniec životného cyklu tohto softvéru sa považuje vydanie prvého oficiálna verzia FL Studio, ktoré už na rozdiel od svojich predkov disponovalo rozhraním plnohodnotného sekvencera s možnosťou úpravy parametrov na virtuálnom 64-kanálovom mixážnom pulte s neobmedzeným pridávaním audio stôp a MIDI stôp.

Neostalo len pri tom. Vo fáze projektového manažmentu bola zavedená podpora pre pripojenie zásuvných modulov formátu VST (najprv druhá a potom tretia verzia), ktorý kedysi vyvinul Steinberg. Zhruba povedané, k programu sa môže pripojiť akýkoľvek virtuálny syntetizátor, ktorý podporuje hostiteľa VST.

Nie je prekvapujúce, že čoskoro mohol každý skladateľ použiť analógy „hardvérových“ modelov, napríklad kompletné sady zvukov kedysi populárneho Korg M1. Ďalej viac. Použitie modulov ako Addictive Drums alebo univerzálny plugin Kontakt umožnilo reprodukovať živé zvuky skutočných nástrojov nahratých so všetkými odtieňmi artikulácie v profesionálnych štúdiách.

Zároveň sa vývojári snažili dosiahnuť maximálnu kvalitu vytvorením podpory pre ovládače ASIO4ALL, čo sa ukázalo byť hlava a ramená nad režimom Full Duplex. V súlade s tým sa zvýšila aj bitová rýchlosť. Dnes môže byť kvalita exportovaného zvukového súboru 320 kbps pri vzorkovacej frekvencii 192 kHz. A toto je profesionálny zvuk.

Pokiaľ ide o pôvodnú verziu, jej životný cyklus by sa dal nazvať úplne úplný, ale takéto vyhlásenie je relatívne, pretože aplikácia zmenila iba svoj názov a získala nové možnosti.

Perspektívy rozvoja

Aké sú fázy životného cyklu softvéru, je už jasné. Ale vývoj takýchto technológií stojí za zmienku samostatne.

Netreba dodávať, že žiadny vývojár softvéru nemá záujem o vytvorenie prchavého produktu, ktorý pravdepodobne neprežije na trhu niekoľko rokov. Z dlhodobého hľadiska sa každý pozerá na jeho dlhodobé používanie. Dá sa to dosiahnuť rôzne cesty. Spravidla sa však takmer všetky týkajú vydania aktualizácií alebo nových verzií programov.

Aj v prípade OS Windows sú takéto trendy viditeľné voľným okom. Je nepravdepodobné, že dnes bude aspoň jeden používateľ používať systémy ako modifikácie 3.1, 95, 98 alebo Millennium. Ich životný cyklus sa skončil po vydaní XP. Verzie serverov založené na technológiách NT sú však stále relevantné. Aj Windows 2000 je dnes nielen veľmi aktuálny, ale v niektorých parametroch inštalácie či zabezpečenia dokonca predčí najnovší vývoj. To isté platí pre systém NT 4.0, ako aj špecializovanú modifikáciu Windows Server 2012.

Ale vo vzťahu k týmto systémom je podpora stále deklarovaná na najvyššej úrovni. Kedysi senzačná Vista však zjavne zažíva úpadok svojho cyklu. Nielenže sa ukázalo, že je nedokončený, ale bolo v ňom toľko chýb a medzier v jeho bezpečnostnom systéme, že sa dá len hádať, ako sa také neudržateľné riešenie mohlo dostať na softvérový trh.

Ak však povieme, že vývoj softvéru akéhokoľvek typu (riadenia alebo aplikácie) nestojí na mieste, môžeme len povedať, že sa to dnes týka nielen počítačových systémov, ale aj mobilné zariadenia, v ktorej používané technológie často predbiehajú počítačový sektor. Vznik procesorových čipov založených na ôsmich jadrách nie je najlepší najlepší príklad? Nie každý notebook sa však môže pochváliť takýmto hardvérom.

Niekoľko doplňujúcich otázok

Čo sa týka pochopenia životného cyklu softvéru, možno veľmi podmienečne povedať, že v určitom časovom bode skončil, pretože softvérové ​​produkty majú stále podporu od vývojárov, ktorí ich vytvorili. Koniec skôr odkazuje na staršie aplikácie, ktoré nespĺňajú požiadavky moderných systémov a nemôžu bežať vo svojom prostredí.

Ale aj s prihliadnutím technický pokrok mnohé z nich sa môžu čoskoro dostať do platobnej neschopnosti. Potom sa budete musieť rozhodnúť, či vydáte aktualizácie, alebo kompletne zrevidujete celý koncept pôvodne začlenený do softvérového produktu. Preto nový cyklus, ktorý zahŕňa zmenu počiatočných podmienok, vývojového prostredia, testovania a možného dlhodobého používania v určitej oblasti.

Ale vo výpočtovej technike sa dnes uprednostňuje vývoj automatizovaných riadiacich systémov (ACS), ktoré sa používajú vo výrobe. Dokonca aj operačné systémy v porovnaní so špecializovanými programami strácajú.

Prostredia založené na Visual Basic zostávajú oveľa populárnejšie ako systémy Windows. A to už vôbec nehovoríme o aplikačnom softvéri pre UNIXové systémy. Čo môžeme povedať, ak takmer všetky komunikačné siete tých istých Spojených štátov fungujú výlučne pre nich. Mimochodom, systémy ako Linux a Android boli tiež pôvodne vytvorené na tejto platforme. Preto má UNIX s najväčšou pravdepodobnosťou oveľa väčšie vyhliadky ako ostatné produkty dohromady.

Namiesto celkom

Ostáva dodať, že len v tomto prípade všeobecné zásady a fázach životného cyklu softvéru. V skutočnosti sa aj pôvodne stanovené úlohy môžu veľmi výrazne líšiť. V súlade s tým je možné pozorovať rozdiely v iných fázach.

Jasné by ale mali byť základné technológie vývoja softvérových produktov a ich následná podpora. Vo zvyšku by ste mali vziať do úvahy špecifiká vytváraného softvéru, prostredia, v ktorých má fungovať, a možnosti programov poskytovaných koncovému používateľovi alebo výrobe a oveľa viac.

Navyše, niekedy môže životný cyklus závisieť od relevantnosti vývojových nástrojov. Ak sa napríklad programovací jazyk stane zastaraným, nikto na ňom nebude písať programy, tým menej ich do nich implementovať automatizované systémy produkčný manažment. Tu ani nie sú do popredia programátori, ale marketéri, ktorí musia včas reagovať na zmeny na trhu s počítačmi. A takých špecialistov na svete nie je až tak veľa. Najžiadanejší sa stáva vysokokvalifikovaný personál, ktorý dokáže držať prst na pulze trhu. A často sú to takzvaní „šedí kardináli“, od ktorých závisí úspech či neúspech určitého softvérového produktu v IT oblasti.

Možno nie vždy pochopia podstatu programovania, ale jednoznačne vedia určiť modely životného cyklu softvéru a dĺžku ich používania na základe globálnych trendov v tejto oblasti. Efektívne riadenie často prináša hmatateľnejšie výsledky. Áno, aspoň PR technológie, reklama atď. Používateľ možno nejakú aplikáciu nepotrebuje, ale ak je aktívne inzerovaná, používateľ si ju nainštaluje. Toto je už takpovediac podvedomá úroveň (rovnaký efekt 25. snímky, keď sa informácie vkladajú do vedomia používateľa nezávisle od neho).

Samozrejme, takéto technológie sú vo svete zakázané, no mnohí z nás si ani neuvedomujú, že sa stále dajú využiť a určitým spôsobom ovplyvňovať podvedomie. Stačí sa pozrieť na cenu „zombifikácia“ spravodajskými kanálmi alebo internetovými stránkami, nehovoriac o použití výkonnejších prostriedkov, ako je vystavenie infrazvuku (toto bolo použité v jednej opernej produkcii), v dôsledku čoho môže človek zažiť strach alebo neprimerané emócie.

Vráťme sa k softvéru, treba dodať, že niektoré programy používajú pri spustení zvukový signál, aby upútali pozornosť používateľa. A ako ukazuje výskum, takéto aplikácie sú životaschopnejšie ako iné programy. Prirodzene sa zvyšuje aj životný cyklus softvéru, bez ohľadu na to, aká funkcia mu bola pôvodne priradená. A, bohužiaľ, veľa vývojárov to používa, čo vyvoláva pochybnosti o zákonnosti takýchto metód.

Ale to nám neprináleží posudzovať. Je možné, že v blízkej budúcnosti budú vyvinuté nástroje na identifikáciu takýchto hrozieb. Zatiaľ je to len teória, ale podľa niektorých analytikov a expertov zostáva len veľmi málo pred praktickou aplikáciou. Ak už vytvárajú kópie neurónových sietí ľudského mozgu, čo potom môžeme povedať?

Dobrý deň, milí obyvatelia Khabrovska! Myslím si, že pre niekoho bude zaujímavé pripomenúť si, aké modely vývoja, implementácie a používania softvéru existovali predtým, aké modely sa dnes prevažne používajú, prečo a čo to vlastne je. Toto bude moja malá téma.

Vlastne, čo to je životný cyklus softvéru- séria udalostí, ktoré sa vyskytujú so systémom počas jeho vytvárania a ďalšieho používania. Inými slovami, ide o čas od počiatočného momentu vytvorenia akéhokoľvek softvérového produktu až po koniec jeho vývoja a implementácie. Životný cyklus softvéru možno znázorniť vo forme modelov.

Model životného cyklu softvéru- štruktúra obsahujúca akčné procesy a úlohy, ktoré sa vykonávajú počas vývoja, používania a údržby softvérového produktu.
Tieto modely možno rozdeliť do 3 hlavných skupín:

1. Inžiniersky prístup
2. Berúc do úvahy špecifiká úlohy
3. Moderné technológie rýchleho rozvoja

Model kódovania a eliminácie chýb

1. Formulácia problému
2. Výkon
3. Kontrola výsledku
4. V prípade potreby prejdite na prvý bod

Model životného cyklu softvéru vodopádu (vodopád)

Výhody:

• Postupná realizácia etáp projektu v presne stanovenom poradí
• Umožňuje zhodnotiť kvalitu produktu v každej fáze

• Žiadna spätná väzba medzi fázami
• Nezodpovedá skutočným podmienkam vývoja softvérového produktu

Kaskádový model so stredným ovládaním (vírivá vaňa)

Model V (testom riadený vývoj)

Model založený na vývoji prototypu

1. Objasnenie nejasných požiadaviek (prototyp používateľského rozhrania)
2. Vyberte si jedno z množstva koncepčných riešení (implementácia scenárov)
3. Analyzujte realizovateľnosť projektu

1. Horizontálne a vertikálne
2. Jednorazové a evolučné
3. papier a storyboardy

Model patrí do druhej skupiny.

Špirálový model životného cyklu softvéru

Výhody:

• Získajte výsledky rýchlo
• Zvýšená konkurencieschopnosť
• Zmena požiadaviek nie je problém

• Nedostatok regulácie javiska

Ďakujem vám veľmi pekne za vašu pozornosť!

Ľudia niekedy jasne nerozlišujú medzi prácou na riadení projektu a prácou počas životného cyklu projektu, pretože oba typy práce sú potrebné na úspešné dokončenie projektu. Hlavný rozdiel medzi nimi je v tom, že projektový manažment sa zameriava na definovanie, plánovanie, monitorovanie a kontrolu a uzatváranie projektu. Práca spojená so samotnou tvorbou výsledkov dodávky projektu sa zvyčajne označuje ako „životný cyklus“ projektu. V procese projektového manažmentu vzniká projektový harmonogram, avšak prevažnú väčšinu prác v tomto harmonograme tvorí práca životného cyklu projektu, v dôsledku ktorej sa objavujú výstupné produkty.

Zatiaľ čo všetky projekty sú jedinečné, rovnako ako existujú všeobecné procesy riadenia, ktoré sa vzťahujú na väčšinu projektov, existujú aj všeobecné modely, ktoré môžu slúžiť ako usmernenia na definovanie životného cyklu väčšiny projektov. Tieto všeobecné modely sú cenné, pretože šetria čas projektovým tímom pri vytváraní harmonogramu projektu.

Príkladom jedného z modelov životného cyklu je bežný klasický „vodopádový“ model. Tento model predstavuje základný prístup, ktorý možno aplikovať na akýkoľvek projekt. Častejšie začnete s pochopením požiadaviek na výstup projektu, potom navrhnete výstup, zostavíte a otestujete výstup a skončíte implementáciou produktu. Každá z týchto oblastí zamerania sa nazýva fáza (fáza analýzy, fáza návrhu, fáza implementácie atď.). Klasický vodopádový prístup je model životného cyklu, ktorý pravdepodobne môžete použiť bez toho, aby ste vedeli čokoľvek o metodológiách a plánovaní projektu od začiatku.

Čo môže byť jednoduchšie? Aj keď máte veľmi malý projekt, stále prechádzate týmito základnými krokmi, pričom aspoň niektoré z nich robíte vo svojej hlave. Napríklad, ak máte 40-hodinový (jeden pracovný týždeň) projekt na vývoj alebo zlepšenie dokumentu, môže sa zdať, že sa ponáhľate priamo do fázy implementácie. Ale je to tak? S najväčšou pravdepodobnosťou ste dostali nejakú úlohu s požiadavkami alebo želaniami, ktoré budete musieť pochopiť (Analýza) a premeniť na plán budúceho obsahu (Dizajn). Potom nápad zrealizujete (Implementácia), skontrolujete výsledok (Testovanie) a prenesiete na použitie (Implementácia).

Schéma vodopádu (kaskády) zahŕňa niekoľko dôležitých operácií, ktoré sa vzťahujú na všetky projekty:

* vypracovanie akčného plánu rozvoja systému;

* plánovanie práce spojenej s každou akciou;

* aplikácia operácie sledovania priebehu akcií s kontrolnými stupňami.

Grafické znázornenie „modelu vodopádu“ projektového cyklu

Obrázok.3 Vodopádový model životného cyklu projektu

Výhody vodopádového (kaskádového) modelu.

Model vodopádu má výhody pri použití v projekte, pre ktorý je vhodný.

a. Tento model je dobre známy spotrebiteľom, ktorí sa nepodieľajú na vývoji a prevádzke programov, a koncovým používateľom.

b. Zaoberá sa komplexnosťou usporiadaným spôsobom a funguje dobre pre tie projekty, ktoré sú pomerne zrozumiteľné, ale stále je ťažké ich vyriešiť.

c. Je ľahké to pochopiť, pretože cieľ je jednoduchý - dokončiť potrebné akcie.

d. Je jednoduchý a ľahko sa používa, pretože proces vývoja prebieha v etapách.

e. Vyznačuje sa stálosťou požiadaviek.

f. Poskytuje šablónu, do ktorej možno umiestniť metódy na vykonávanie analýzy, návrhu, kódovania, testovania a poskytovania.

g. Umožňuje účastníkom projektu, ktorí ukončili aktivity vo fáze, ktorú vykonávajú, zúčastniť sa na realizácii iných projektov.

h. Definuje postupy kontroly kvality. Všetky prijaté údaje sa skontrolujú. Tento postup používa vývojový tím na určenie kvality systému.

i. Postup projektu možno ľahko sledovať pomocou časovej osi (Ganttov diagram), pretože bod, v ktorom je každá fáza dokončená, sa používa ako fáza.

Nevýhody kaskádového modelu.

Pri použití vodopádového modelu pre projekt, ktorý je preň sotva vhodný, sa objavia nasledujúce nevýhody:

a. Model je založený na konzistentnom lineárna štruktúra, pričom pokus vrátiť sa o fázu alebo dve späť na nápravu akéhokoľvek problému alebo nedostatku bude mať za následok výrazné zvýšenie nákladov a narušenie harmonogramu.

b. Nie vždy má klient možnosť vopred sa zoznámiť so systémom, to sa stáva až na samom konci životného cyklu.

c. Klient nie je schopný používať priebežné výsledky a spätnú väzbu od používateľov nemožno poslať späť vývojárom. Keďže hotový produkt nie je k dispozícii až do konca procesu, používateľ je zapojený do procesu len na samom začiatku – pri zhromažďovaní požiadaviek a na konci pri akceptačnom testovaní.

d. Každá fáza je predpokladom pre následné akcie, čo robí túto metódu riskantnou voľbou pre jedinečné systémy, pretože ju nemožno flexibilne modelovať.

e. Pre každú fázu sa vytvoria výstupné dáta, ktoré sa po dokončení považujú za zmrazené. To znamená, že by sa nemali meniť počas nasledujúcich fáz životného cyklu produktu. Ak sa niektorý z fázových prvkov zmení, bude to mať vplyv na projekt. Negatívny vplyv zmena v pláne, pretože ani model, ani plán neboli navrhnuté tak, aby vyhovovali a riešili zmeny neskôr v životnom cykle.

f. Všetky požiadavky by mali byť známe na začiatku životného cyklu, ale klienti nemusia byť v tomto štádiu vývoja vždy schopní formulovať všetky jasne definované požiadavky.

Zatiaľ čo vodopád je univerzálny a možno ho použiť na akýkoľvek projekt, iné modely životného cyklu môžu byť efektívnejšie a efektívnejšie v závislosti od charakteristík projektu. Ak napríklad nainštalujete softvérový balík, preskočíte fázy návrhu a implementácie. Podobne, ak robíte vývojovú prácu, možno budete chcieť použiť špecifický model životného cyklu výskumno-vývojového projektu, ktorý berie do úvahy, že vykonaná práca alebo časť z nej môže skončiť v koši. Na urýchlenie určitých typov projektov možno použiť ďalšie dôležité modely životného cyklu. Projekty informačných technológií napríklad často využívajú iteratívny alebo rýchly (agilný) vývoj.

Nižšie sú uvedené niektoré ďalšie modely životného cyklu projektu:

Iteračný prístup(anglická iterácia - opakovanie) - vykonávanie práce súbežne s priebežnou analýzou získaných výsledkov a úpravou predchádzajúcich etáp práce. S týmto prístupom prechádza projekt v každej fáze vývoja opakujúcim sa cyklom: Plánovanie - Implementácia - Kontrola - Hodnotenie (cyklus plánuj-urob-kontroluj-konaj).

Výhody iteratívneho prístupu:

1. znižovanie dopadu závažných rizík v počiatočných fázach projektu, čo vedie k minimalizácii nákladov na ich odstránenie;

2. efektívna organizácia spätná väzba projektový tím so spotrebiteľom (ako aj so zákazníkmi, zainteresovanými stranami) a vytvorenie produktu, ktorý skutočne spĺňa jeho potreby;

3. zameranie úsilia na najdôležitejšie a kritické oblasti projektu;

4. priebežné iteratívne testovanie, ktoré nám umožňuje hodnotiť úspešnosť celého projektu ako celku;

5. včasné odhalenie konfliktov medzi požiadavkami, modelmi a 6. realizáciou projektu;

8. efektívne využitie nazbieraných skúseností;

9. reálne zhodnotenie súčasného stavu projektu a v dôsledku toho väčšia 10. dôvera zákazníkov a priamych účastníkov v jeho úspešné dokončenie.

Model životného cyklu špirálového projektu. Tento model skúma závislosť efektívnosti projektu od jeho nákladov v čase. Pri každom otočení špirály sa vytvorí ďalšia verzia produktu, špecifikujú sa požiadavky projektu, určí sa jeho kvalita a naplánuje sa práca ďalšieho otočenia.

Špirálový model prvýkrát sformuloval Barry Boehm v roku 1988. Výrazná vlastnosť Tento model venuje osobitnú pozornosť rizikám ovplyvňujúcim organizáciu životného cyklu. Boehm formuluje „top 10“ najbežnejších (podľa priority) rizík

1. Nedostatok odborníkov.

2. Nereálne termíny a rozpočet.

3. Implementácia nevhodnej funkcionality.

4. Navrhovanie nesprávneho používateľského rozhrania.

5. „Zlaté prestieranie“, perfekcionizmus, zbytočná optimalizácia a pilovanie detailov.

6. Neustály prúd zmien.

7. Nedostatok informácií o externých komponentoch, ktoré definujú prostredie systému alebo sa podieľajú na integrácii.

8. Nevýhody v práci vykonávanej externými (vo vzťahu k projektu) zdrojmi.

9. Nedostatočný výkon výsledného systému.

10. „Medzera“ v kvalifikácii špecialistov v rôznych oblastiach vedomostí.

Väčšina týchto rizík je spojená s organizačnými a procesnými aspektmi interakcie medzi špecialistami v projektovom tíme.

Každé otočenie špirály zodpovedá vytvoreniu fragmentu alebo verzie softvéru, kde sa vyjasnia ciele a charakteristiky projektu, určí sa jeho kvalita a naplánuje sa práca na ďalšom otočení špirály. Týmto spôsobom sa prehĺbia a dôsledne špecifikujú detaily projektu a vo výsledku sa vyberie rozumná možnosť, ktorá sa privedie k realizácii. Každý ťah je rozdelený do 4 sektorov:

posúdenie a riešenie rizík,

definovanie cieľov

vývoj a testovanie,

plánovanie.

Špirálový model je zameraný na veľké, drahé a zložité projekty.

Výhody špirálového modelu:

Pri použití špirálového modelu na projekte, pre ktorý je vhodný, vznikajú nasledujúce výhody:

a Špirálový model umožňuje užívateľom „vidieť“ systém včas, pomocou rýchleho prototypovania v životnom cykle vývoja projektu.

b Umožňuje identifikovať neprekonateľné riziká pri nízkych nákladoch.

c Model umožňuje používateľom aktívne sa podieľať na plánovaní, analýze rizík, návrhu a hodnotení.

d Zabezpečuje, že veľké potenciálne množstvo práce na vývoji produktu je rozdelené na malé časti.

e Model umožňuje flexibilný dizajn, pretože zachytáva výhody vodopádového modelu a zároveň umožňuje iteráciu vo všetkých fázach toho istého modelu.

f Výhody prírastkového modelu sú realizované, a to uvoľňovanie prírastkov, redukcia harmonogramu prekrývajúcimi sa prírastkami a nemennosť zdrojov pri postupnom raste systému.

Nevýhody špirálového modelu:

Pri použití špirálového modelu na projekte, pre ktorý nie je vhodný, sa objavia nasledujúce nevýhody:

a Špirála môže pokračovať donekonečna.

b Veľký počet medzistupňov môže viesť k potrebe spracovania internej doplnkovej a externej dokumentácie.

c Používanie modelu môže byť drahé, pretože čas strávený plánovaním, predefinovaním cieľov, analýzou rizík a prototypovaním môže byť nadmerný.

Inkrementálny model projektového cyklu. Tento model sa vo väčšine prípadov používa pri vykonávaní komplexných vývojových prác, ktoré si vyžadujú veľký počet účastníkov rôzne problémy ktoré je potrebné vyriešiť. Jeho podstata spočíva v rozdelení veľkého množstva práce na postupnosť menších komponentov. Je to proces čiastočnej implementácie celého systému a pomalého budovania funkčnosť alebo efektívnosť.

Tento model zahŕňa rozdelenie životného cyklu projektu na postupnosť iterácií, z ktorých každá pripomína „miniprojekt“, vrátane všetkých fáz životného cyklu, ako je aplikované na vytváranie menších častí funkčnosti v porovnaní s projektom ako celkom. Cieľom každej iterácie je získať pracovnú verziu softvérového systému, ktorá obsahuje funkcionalitu definovanú integrovaným obsahom všetkých predchádzajúcich a súčasných iterácií. Výsledky finálnej iterácie obsahujú všetky požadované funkcie produktu.

Výhody inkrementálneho modelu.

Použitím prírastkového modelu pri vývoji projektu, pre ktorý je dostatočne vhodný, sa môžete presvedčiť o nasledujúcich výhodách:

a Nie je potrebné utrácať peniaze vopred na vývoj celého projektu.

b Výsledkom každého prírastku je získanie funkčného produktu.

c Použitie postupných prírastkov umožňuje kombinovať skúsenosti používateľov do vylepšeného produktu za zlomok nákladov na opätovný vývoj.

d Pravidlo rozdeľ a panuj vám umožňuje rozdeliť problém na zvládnuteľné časti, čo vývojovému tímu bráni vytvárať ťažkopádne zoznamy požiadaviek.

e Počas procesu vývoja môžete obmedziť počet zamestnancov tak, aby na dodaní každého prírastku dôsledne pracoval ten istý tím.

f Na konci každej prírastkovej dodávky je možnosť prehodnotiť riziká spojené s nákladmi a dodržiavaním stanoveného harmonogramu.

g Keďže prechod zo súčasnosti do budúcnosti nenastane okamžite, zákazník si môže zvyknúť Nová technológia postupne.

h Riziko je rozložené do niekoľkých menších prírastkov a nie je sústredené v jednom veľkom developerskom projekte.

Nevýhody inkrementálneho modelu.

Pri použití tohto modelu v súvislosti s projektom, pre ktorý nie je dostatočne vhodný, sa objavujú tieto nevýhody:

a Model neumožňuje iterácie v rámci každého prírastku.

b Definícia úplného funkčný systém by sa malo vykonať na začiatku životného cyklu, aby sa zabezpečilo určenie prírastkov.

c Klient si musí byť vedomý toho, že celkové náklady na dokončenie projektu sa neznížia.