Pojem „životný cyklus“ znamená niečo, čo sa rodí, vyvíja a umiera. Softvérové ​​produkty sa ako živý organizmus vytvárajú, prevádzkujú a vyvíjajú sa v priebehu času.

Životný cyklus softvér zahŕňa všetky štádiá jeho vývoja: od vzniku jeho potreby až po úplné zastavenie jeho používania v dôsledku zastarania alebo straty potreby riešiť príslušné problémy.

Existuje niekoľko fáz existencie softvérového produktu počas jeho životného cyklu. Zatiaľ neexistujú všeobecne akceptované názvy týchto fáz a ich počet. V tejto otázke však neexistujú žiadne osobitné nezhody. Preto existuje niekoľko možností, ako rozdeliť životný cyklus softvéru na etapy. Otázka, či je konkrétny oddiel lepší ako ostatné, nie je hlavná. Hlavnou vecou je správne zorganizovať vývoj softvéru s prihliadnutím na ne.

Podľa dĺžky životného cyklu možno softvérové ​​produkty rozdeliť do dvoch tried: malý a skvelý život. Tieto triedy programov zodpovedajú flexibilnému (mäkkému) prístupu k ich tvorbe a používaniu a tvrdému priemyselnému prístupu k regulovanému dizajnu a prevádzke softvérových produktov. Vo vedeckých organizáciách a univerzitách napríklad prevláda vývoj prvotriednych programov, zatiaľ čo v dizajnérskych a priemyselných organizáciách - druhý.

Softvérové ​​produkty s krátkou životnosťou sú vytvorené najmä na riešenie vedeckých a inžinierskych problémov, na získanie konkrétnych výsledkov výpočtov. Takéto programy sú zvyčajne relatívne malé. Vyvíja ich jeden špecialista alebo malá skupina. O hlavnej myšlienke programu diskutuje jeden programátor a koncový používateľ. Niektoré detaily sa dajú na papier a projekt sa zrealizuje v priebehu niekoľkých dní alebo týždňov. Nie sú určené na replikáciu a prenos pre následné použitie v iných tímoch. Ako také sú takéto programy súčasťou výskumného projektu a nemali by sa považovať za softvérové ​​produkty na jedno použitie.

Ich životný cyklus pozostáva z dlhého obdobia systémovej analýzy a formalizácie problému, významnej etapy návrhu programu a relatívne krátkej doby prevádzky a získavania výsledkov. Požiadavky na funkčné a konštrukčné charakteristiky spravidla nie sú formalizované, neexistujú žiadne formalizované programové testy. Ich ukazovatele kvality kontrolujú iba vývojári v súlade s ich neformálnymi predstavami.

Softvérové ​​produkty s krátkou životnosťou

Údržba a úprava takýchto programov nie je povinná a ich životný cyklus je ukončený po obdržaní výsledkov výpočtov. Hlavné náklady v životnom cykle takýchto programov spadajú do štádií analýzy a návrhu systému, ktoré v dôsledku toho trvajú od mesiaca do 1 ... 2 rokov.

že životný cyklus softvérového produktu zriedka presahuje 3 roky.

Softvérové ​​produkty s dlhou životnosťou vytvorené na pravidelné spracovanie a správu informácií. Štruktúra takýchto programov je zložitá. Ich veľkosti sa môžu líšiť v širokom rozsahu (1...1000 tisíc príkazov), ale všetky majú vlastnosti rozpoznateľnosti a možnosti úpravy v procese dlhodobej údržby a používania rôznymi špecialistami. Softvérové ​​produkty tejto triedy sa dajú replikovať, sú sprevádzané dokumentáciou ako priemyselné produkty a sú to softvérové ​​produkty odcudzené vývojárom.

Softvérové ​​produkty s dlhou životnosťou

Na ich návrhu a prevádzke sa podieľajú veľké tímy špecialistov, čo si vyžaduje formalizáciu softvérového systému, ako aj formalizované testovanie a stanovenie dosahovaných ukazovateľov kvality finálneho produktu. Ich životný cyklus je 10...20 rokov. Až 70...90% tohto času pripadá na prevádzku a údržbu. V dôsledku hromadnej replikácie a dlhodobej údržby celkové náklady na prevádzku a údržbu takýchto softvérových produktov výrazne prevyšujú náklady na analýzu a návrh systému.

Všetky následné prezentácie sú zamerané na vývoj rozsiahlych (komplexných) softvérových nástrojov na správu a spracovanie informácií.

Zovšeobecnený model životný cyklus Softvérový produkt môže vyzerať takto:

ja Systémová analýza:

a) výskum;

b) štúdia uskutočniteľnosti:

operatívne;

ekonomické;

Komerčný.

II. Dizajn softvéru:

a) dizajn:

Funkčný rozklad systému, jeho architektúra;

Dizajn externého softvéru;

Návrh databázy;

Softvérová architektúra;

b) programovanie:

Interný softvérový dizajn;

Externý dizajn softvérových modulov;

Interný dizajn softvérových modulov;

kódovanie;

Ladiace programy;

Rozloženie programu;

c) ladenie softvéru.

III. Hodnotenie (testovanie) softvéru.

IV. Použitie softvéru:

a) prevádzka;

b) podpora.

ja. Systémová analýza. Na začiatku vývoja softvéru sa vykoná systémová analýza (jeho predbežný návrh), počas ktorej sa určí jeho potreba, jeho účel a hlavné funkčné charakteristiky. Odhadujú sa náklady a možná efektívnosť aplikácie budúceho softvérového produktu.

V tejto fáze sa zostavuje zoznam požiadaviek, teda jasná definícia toho, čo používateľ od hotového produktu očakáva. Tu sú stanovené ciele a zámery, kvôli ktorým sa vyvíja samotný projekt. Vo fáze systémovej analýzy možno rozlíšiť dva smery: výskum a analýza uskutočniteľnosti.

Začína sa výskum od momentu, keď si manažér vývoja uvedomí potrebu softvéru.

Práca spočíva v plánovaní a koordinácii činností potrebných na prípravu formálneho ručne písaného zoznamu požiadaviek na vyvíjaný softvérový produkt.

Výskum končí keď sú požiadavky formulované tak, že sa stanú viditeľnými a v prípade potreby ich môže upraviť a schváliť zodpovedný vedúci.

Štúdie uskutočniteľnosti existuje technická časť výskumu a začína, keď je zámer manažmentu taký silný, že je menovaný projektový manažér, ktorý organizuje návrh a distribúciu zdrojov (práce).

Práca spočíva v preštudovaní navrhovaného softvérového produktu za účelom získania praktického posúdenia možnosti realizácie projektu, najmä sú určené:

- prevádzková realizovateľnosť , Bude produkt dostatočne pohodlný na praktické použitie?

- ekonomická realizovateľnosť , Sú náklady na vyvinutý produkt prijateľné? Aké sú tieto náklady? Bude produkt nákladovo efektívnym nástrojom v rukách používateľa?

- komerčná realizovateľnosť, Bude produkt atraktívny, predajný, ľahko inštalovateľný, použiteľný a ľahko sa naučí?

Tieto a ďalšie otázky je potrebné riešiť hlavne pri zvažovaní vyššie uvedených požiadaviek.

Štúdia uskutočniteľnosti končí, keď sú zhromaždené a schválené všetky požiadavky.

Pred pokračovaním v ďalšej práci na projekte je potrebné zabezpečiť, aby boli prijaté všetky potrebné informácie. Tieto informácie musia byť presné, zrozumiteľné a vynútiteľné. Mal by to byť úplný súbor požiadaviek, ktoré uspokoja užívateľa na vyvíjaný softvérový produkt, vypracovaný vo forme špecifikácie.

V prípade nedodržania tejto požiadavky je možné v budúcnosti výrazne spomaliť realizáciu projektu z dôvodu opakovaných požiadaviek užívateľa na objasnenie nesprávne interpretovaných detailov, nešpecifikovaných podmienok a v dôsledku toho bude potrebné prepracovať už rozpracované jeho časti.

Často sa počas obdobia analýzy systému rozhodne zastaviť ďalší vývoj softvéru.

II. Návrh softvéru. Dizajn je hlavná a rozhodujúca fáza životného cyklu softvéru, počas ktorej vzniká softvérový produkt a na 90 % dostane svoju finálnu podobu.

Táto fáza života pokrýva rôzne druhy projektovú činnosť a možno ju rozdeliť do troch hlavných etáp: návrh, programovanie a ladenie softvérového produktu.

Stavebníctvo vývoj softvéru zvyčajne začína už vo fáze štúdie uskutočniteľnosti, len čo sú na papier zafixované nejaké predbežné ciele a požiadavky.

V čase schválenia požiadaviek budú práce vo fáze projektovania v plnom prúde.

V tomto segmente životnosti softvéru sa vykonáva nasledovné:

Funkčný rozklad riešeného problému, na základe ktorého sa určí architektúra systému tohto problému;

Externý návrh softvéru, vyjadrený vo forme jeho externej interakcie s používateľom;

Návrh databázy, ak je to potrebné;

Návrh softvérovej architektúry - definícia objektov, modulov a ich prepojenia.

Začína sa programovanie už vo fáze výstavby, hneď ako budú k dispozícii hlavné špecifikácie pre jednotlivé komponenty softvérového produktu, nie však pred schválením dohody o požiadavkách. Prekrývanie medzi fázou programovania a výstavby má za následok úsporu celkového času vývoja, ako aj zabezpečenie overenia návrhových rozhodnutí a v niektorých prípadoch ovplyvňuje kľúčové problémy.

V tejto fáze sa vykonávajú práce spojené s montážou softvérového produktu. Spočíva v detailnom internom návrhu softvérového produktu, vo vývoji vnútornej logiky každého modulu systému, ktorá je následne vyjadrená v texte konkrétneho programu.

Fáza programovania končí, keď vývojári dokončia dokumentáciu, ladenie a prepojenie jednotlivých častí softvérového produktu do celku.

Ladenie softvéru sa vykonáva po oddelenom odladení všetkých jeho komponentov a zostavení do jedného softvér.

III. Hodnotenie (testovanie) softvéru. V tejto fáze je softvérový produkt podrobený prísnemu systémovému testovaniu skupinou nevývojárov.

Deje sa tak s cieľom zabezpečiť, aby hotový softvérový produkt spĺňal všetky požiadavky a špecifikácie, mohol byť použitý v prostredí používateľa, nemal žiadne chyby a obsahoval potrebnú dokumentáciu, ktorá presne a úplne popisuje softvérový produkt.

Fáza hodnotenia začína, keď sú všetky komponenty (moduly) zostavené a otestované, t.j. po úplnom odladení hotového softvérového produktu. Končí po prijatí potvrdenia, že softvérový produkt prešiel všetkými testami a je pripravený na prevádzku.

Pokračuje rovnako dlho ako programovanie.

IV. Používanie softvéru. Ak je systémová analýza výzvou k akcii, dizajn je útokom a návratom s víťazstvom, potom je používanie softvérového produktu každodennou obranou, životne dôležitou, ale pre vývojárov zvyčajne nie čestnou.

Takéto porovnanie je vhodné vzhľadom na to, že počas používania softvérového produktu dochádza k oprave chýb, ktoré sa vkradli pri jeho návrhu.

Fáza používania softvérového produktu začína, keď je produkt prenesený do distribučného systému.

Toto je čas, počas ktorého je produkt v prevádzke a efektívne využívaný.

V tomto čase prebieha školenie personálu, implementácia, konfigurácia, údržba a prípadne rozšírenie softvérového produktu - takzvaný priebežný návrh.

Fáza používania končí, keď je výrobok stiahnutý z používania a ukončujú sa vyššie uvedené činnosti. Upozorňujeme však, že softvérový produkt môže používať niekto iný ešte dlhú dobu po ukončení fázy používania, ako je tu definovaná. Pretože tento niekto môže plodne využívať softvérový produkt aj bez pomoci vývojára.

Použitie softvérového produktu je podmienené jeho prevádzkou a údržbou.

Prevádzka softvérového produktu spočíva v jeho vykonávaní, jeho fungovaní na počítači na spracovanie informácií a v získavaní výsledkov, ktoré sú účelom jeho tvorby, ako aj v zabezpečení spoľahlivosti a spoľahlivosti vydávaných údajov.

Údržba softvéru spočíva v údržbe, rozvoji funkčnosť a zvyšovanie výkonnostné charakteristiky mnoho softvérových produktov pri replikácii a prenose softvérového produktu do Rôzne druhy výpočtové prostriedky.

Údržba zohráva úlohu potrebnej spätnej väzby z fázy prevádzky.

Počas prevádzky softvéru je možné odhaliť chyby v programoch a je potrebné ich upravovať a rozširovať ich funkcie.

Tieto vylepšenia sa spravidla vykonávajú súčasne s prevádzkou aktuálnej verzie softvérového produktu. Po skontrolovaní pripravených úprav na jednej z inštancií softvéru ďalšia verzia softvérového produktu nahradí predtým používané alebo niektoré z nich. Zároveň môže byť proces prevádzky softvérového produktu prakticky nepretržitý, keďže výmena verzie softvérového produktu je krátkodobá. Tieto okolnosti vedú k tomu, že proces prevádzky verzie softvérového produktu zvyčajne prebieha paralelne a nezávisle od fázy údržby.

Prekrývanie medzi fázami životného cyklu softvérového produktu

Presahy medzi rôznymi fázami životného cyklu softvérového produktu sú možné a zvyčajne žiaduce. Nesúvisiace procesy by sa však nemali prekrývať.

Spätná väzba medzi fázami je možná. Napríklad počas jedného z externých krokov návrhu sa môžu objaviť chyby vo formulácii cieľov, potom sa musíte okamžite vrátiť a opraviť ich.

Uvažovaný model životného cyklu softvérového produktu s určitými zmenami môže slúžiť aj ako model pre malé projekty.

Napríklad, keď sa navrhuje jeden program, často sa to robí bez návrhu architektúry systému a

návrh databáz; procesy počiatočného a podrobného externého dizajnu sa často spájajú atď.

Téma: Klasické a flexibilné modely LCPP: definícia, popis, charakteristické rysy, postupnosť krokov. Metódy výberu modelu ZhCPP pri vývoji softvéru v rôznych tematických oblastiach.

Modely a fázy životného cyklu softvéru

Model životného cyklu softvéru sa chápe ako štruktúra, ktorá určuje postupnosť vykonávania a vzťah procesov, akcií a úloh počas životného cyklu softvéru. Model životného cyklu závisí od špecifík, rozsahu a zložitosti projektu a konkrétnych podmienok, v ktorých systém vzniká a funguje.

Norma ISO/IEC 12207 nenavrhuje konkrétny model životného cyklu a metódy vývoja softvéru. Jeho ustanovenia sú spoločné pre všetky modely životného cyklu, metódy a technológie vývoja softvéru. Norma popisuje štruktúru procesov životného cyklu softvéru, ale nešpecifikuje, ako implementovať alebo vykonávať činnosti a úlohy zahrnuté v týchto procesoch.

Model životného cyklu každého konkrétneho softvéru určuje charakter procesu jeho tvorby, čo je súbor prác usporiadaných v čase, vzájomne prepojených a zjednotených v etapách (fázach), ktorých implementácia je nevyhnutná a postačujúca na vytvorenie softvéru, ktorý spĺňa špecifikované požiadavky.

Etapa (fáza) tvorby softvéru je chápaná ako súčasť procesu tvorby softvéru, ohraničená určitým časovým rámcom a končiaca vydaním konkrétneho produktu (modely softvéru, softvérové ​​komponenty, dokumentácia a pod.), určená špecifikovanými požiadavkami pre túto etapu. Etapy tvorby softvéru sa rozlišujú z dôvodov racionálneho plánovania a organizácie práce, končiac špecifikovanými výsledkami. Životný cyklus softvéru zvyčajne zahŕňa nasledujúce fázy:

1. tvorba softvérových požiadaviek;
2. dizajn (vývoj projektu systému);
3. implementácia (možno rozdeliť na čiastkové kroky: podrobný návrh, kódovanie);
4. testovanie (možno rozdeliť na samostatné a komplexné testovanie a integráciu);
5. uvedenie do prevádzky (realizácia);
6. Prevádzka a údržba;
7. vyraďovanie z prevádzky.

Niektorí odborníci zavádzajú ďalšiu počiatočnú fázu - štúdie uskutočniteľnosti systémov. Týka sa to softvérového a hardvérového systému, pre ktorý je softvér vytvorený, zakúpený alebo upravený.

Fáza tvorby softvérových požiadaviek je jednou z najdôležitejších a do značnej miery (až rozhodujúcej!) rozhoduje o úspechu celého projektu. Začiatkom tejto etapy je získanie schválenej a schválenej architektúry systému so zahrnutím základných zmlúv o rozdelení funkcií medzi hardvér a softvér. Tento dokument by mal obsahovať aj potvrdenie všeobecnej predstavy o fungovaní softvéru vrátane hlavných dohôd o rozdelení funkcií medzi osobou a systémom.

Fáza tvorby softvérových požiadaviek zahŕňa nasledujúce fázy.

1. Plánovanie prác pred projektom. Hlavnými úlohami etapy sú definovanie rozvojových cieľov, predbežné ekonomické zhodnotenie projekt, zostavenie harmonogramu prác, vytvorenie a zaškolenie spoločnej pracovnej skupiny.
2. Vykonávanie prieskumu činností automatizovanej organizácie (objektu), v rámci ktorého sa vykonáva predbežná identifikácia požiadaviek na budúci systém, určenie štruktúry organizácie, určenie zoznamu cieľových funkcií organizácie, analýza rozdelenie funkcií podľa oddelení a zamestnancov, identifikácia funkčných interakcií medzi oddeleniami, informačné toky v rámci oddelení a medzi nimi, externé voči organizácii objektov a externé informačné vplyvy, analýza existujúcich prostriedkov automatizácie činnosti organizácie.

Vytvorenie modelu činnosti organizácie (objektu), ktorý zabezpečuje spracovanie prieskumných materiálov a konštrukciu dvoch typov modelov:

• model „AS-IS“ („tak ako je“), ktorý odráža aktuálny stav v organizácii v čase prieskumu a umožňuje vám pochopiť, ako organizácia funguje, ako aj identifikovať úzke miesta a formulovať návrhy na zlepšenie situácia;
• Model "TO-BE" ("ako by mal byť"), ktorý odráža myšlienku nových technológií práce organizácie.

Každý z modelov by mal obsahovať kompletný funkčný a informačný model činnosti organizácie, ako aj (v prípade potreby) model, ktorý popisuje dynamiku správania organizácie. Všimnite si, že zostavené modely majú nezávislé praktickú hodnotu, bez ohľadu na to, či podnik vyvinie a implementuje informačný systém, pretože ho možno použiť na školenie zamestnancov a zlepšenie obchodných procesov podniku.

Výsledkom ukončenia etapy tvorby softvérových požiadaviek sú softvérové ​​špecifikácie, funkčné, technické a rozhrania, u ktorých je potvrdená ich úplnosť, overiteľnosť a realizovateľnosť.

Fáza návrhu zahŕňa nasledujúce kroky.

1. Vývoj projektu softvérového systému. V tejto fáze je daná odpoveď na otázku „Čo by mal robiť budúci systém?“, a to: architektúra systému, jeho funkcie, vonkajšie podmienky prevádzky, rozhrania a rozdelenie funkcií medzi používateľov a systémom, požiadavky na určuje sa softvérové ​​a informačné komponenty, zloženie účinkujúcich a termíny.vývoj, plán odlaďovania softvéru a kontrola kvality.

   Základom projektu systému sú modely navrhnutého systému, ktoré sú postavené na modeli „TO-BE“. Výsledkom vypracovania projektu systému by mala byť schválená a potvrdená špecifikácia softvérových požiadaviek: funkčné, technické a špecifikácie rozhrania, pri ktorých je potvrdená ich úplnosť, overiteľnosť a realizovateľnosť.

2. Vypracovanie podrobného (technického) projektu. V tejto fáze prebieha samotný návrh softvéru vrátane návrhu architektúry systému a detailného návrhu. Je teda daná odpoveď na otázku: "Ako postaviť systém tak, aby spĺňal požiadavky?"

Výsledkom detailného návrhu je vývoj overenej softvérovej špecifikácie vrátane:

• vytvorenie hierarchie softvérových komponentov, medzimodulových rozhraní pre dáta a riadenie;
• špecifikácia každého softvérového komponentu, názov, účel, predpoklady, veľkosti, sekvencia volania, vstupné a výstupné údaje, chybné výstupy, algoritmy a logické obvody;
• formovanie fyzických a logických dátových štruktúr až po úroveň jednotlivých polí;
• vypracovanie plánu distribúcie výpočtových zdrojov (čas centrálnych procesorov, pamäte atď.);
• overenie úplnosti, konzistentnosti, realizovateľnosti a platnosti požiadaviek;
• predbežný plán integrácie a ladenia, používateľská príručka a plán akceptačných testov.

Zavŕšením etapy podrobného návrhu je komplexná kontrola projektu alebo analýza kritických blokov projektu.

Realizačná etapa – realizácia nasledujúcich prác.

1. Vypracovanie overenej podrobnej špecifikácie pre každý podprogram (blok maximálne 100 zdrojových príkazov jazyka vysokej úrovne).

   Externé špecifikácie musia obsahovať tieto informácie:

   • názov modulu - je uvedený názov použitý na volanie modulu (pre modul s viacerými vstupmi musí byť pre každý vstup samostatná špecifikácia);
   • funkcia - definuje funkciu alebo funkcie vykonávané modulom;
   • zoznam parametrov (počet a poradie) odovzdaných modulu;
   • vstupné parametre - presný popis všetkých dát vrátených modulom (treba určiť správanie modulu za akýchkoľvek vstupných podmienok);
   • vonkajšie efekty (vytlačenie správy, prečítanie požiadavky z terminálu a pod.).
2. Návrh modulovej logiky a programovanie modulov (kódovanie).
3. Kontrola správnosti modulov.
4. Testovanie modulu.
5. Popis databázy až po úroveň jednotlivých parametrov, symbolov a bitov.
6. Plán akceptačných skúšok.
7. Užívateľská príručka.
8. Predbežný plán integrácie a ladenia. Obsah nasledujúcich etáp sa v podstate zhoduje s príslušnými procesmi životného cyklu softvéru. Vo všeobecnosti sa technologické etapy rozlišujú na základe úvah o rozumnom a racionálnom plánovaní a organizácii práce. Možný variant vzťahu a fáz práce s procesmi životného cyklu softvéru je znázornený na obrázku.

Ryža. jeden.

Typy modelov životného cyklu softvéru

Model vodopádu (klasický životný cyklus)

Tento model vďačí za svoj vzhľad W. Royceovi (1970). Model má iné meno - vodopád (vodopád). Zvláštnosťou modelu je, že prechod do ďalšej fázy sa uskutoční až po úplnom dokončení práce v predchádzajúcej fáze; Návraty k dokončeným etapám nie sú poskytované.

Požiadavky na vyvinuté PS, stanovené vo fázach tvorby a analýzy, sú prísne zdokumentované vo forme TOR a sú fixné počas celého trvania 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 pokračoval ďalší vývojový tím. Kritériom kvality vývoja pri tomto prístupe je presnosť plnenia špecifikácií TOR. Hlavným zameraním vývojárov je dosiahnutie optimálnych hodnôt technické údaje rozvinutý PS - výkon, množstvo obsadenej pamäte atď.

Výhody model vodopádu:

• v každej fáze sa vytvorí kompletný súbor projektovej dokumentácie, ktorý spĺňa kritériá úplnosti a konzistentnosti;
• fázy práce vykonávané v logickom slede vám umožňujú naplánovať načasovanie dokončenia všetkých prác a zodpovedajúcich nákladov.

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

nevýhody model vodopádu:

• identifikácia a odstraňovanie chýb sa vykonáva iba v štádiu testovania, ktoré sa môže výrazne rozšíriť;
• skutočné projekty často vyžadujú odchýlku od štandardnej postupnosti krokov;
• cyklus je založený na presnej formulácii počiatočných požiadaviek na PS, v skutočnosti sú na začiatku projektu požiadavky zákazníka definované 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 sa dá projekt rozpracovať do detailov budúci systém, 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 po ukončení ktorejkoľvek fázy vývoja budú vykonané potrebné korekcie. 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 iteratívnom modeli môžu byť nedostatky dizajnu a programovania odstránené neskôr čiastočným návratom k predchádzajúcej fáze. Čím nižšia je miera detekcie chyby, tým drahšia je jej oprava. Ak sa náklady na úsilie potrebné na odhalenie a odstránenie chýb vo fáze písania kódu vezmú ako jedna, potom náklady na identifikáciu a odstránenie chyby vo fáze požiadaviek budú 5- až 10-krát nižšie a náklady na identifikáciu a odstránenie chyby vo fáze údržby bude 20-krát menej.viac.

V takejto situácii má veľký význam fáza formulovania požiadaviek, vypracovania špecifikácií a vytvorenia plánu systému. Za všetky následné zmeny rozhodnutí o dizajne sú osobne zodpovední softvéroví architekti. Objem dokumentácie dosahuje tisíce strán, počet schvaľovacích stretnutí je obrovský. Mnoho projektov nikdy neopustí fázu plánovania a upadne do paralýzy analýzy. Jedným z možných spôsobov, ako sa takýmto situáciám vyhnúť, je breadboarding (prototypovanie).

Prototypovanie

Zákazník často nevie formulovať požiadavky na vstup, spracovanie alebo výstup dát pre budúci softvérový produkt. Vývojár môže pochybovať o vhodnosti produktu pre operačný systém vo 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íka. Modelovanie (prototypovanie) je proces vytvárania modelu požadovaného produktu.

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

1. Papierová maketa (ručne nakreslená schéma dialógu človek-stroj) alebo maketa založená na PC.
2. Pracovné rozloženie, ktoré implementuje niektoré z požadovaných funkcií.
3. Existujúci program, ktorého vlastnosti je potrebné zlepšiť.

Ako je znázornené na obrázku, 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í pre prototypovanie je znázornená na obrázku. Prototypovanie začína zberom a špecifikáciou požiadaviek na vytváraný softvérový systém. Vývojár a zákazník spoločne definujú ciele softvéru, stanovia, ktoré požiadavky sú známe a ktoré je potrebné predefinovať. Potom sa vykoná rýchly návrh. Zameriava sa na funkcie, ktoré by mali byť viditeľné pre používateľa. Rýchly dizajn vedie ku konštrukcii rozloženia. Rozloženie je vyhodnotené zákazníkom a slúži na objasnenie softvérových požiadaviek. Iterácie pokračujú, kým rozloženie neodhalí všetky požiadavky zákazníka a neumožní vývojárovi pochopiť, čo je potrebné urobiť.

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

• zákazník môže prevziať návrh produktu;
• vývojár si môže pomýliť rozloženie s produktom.

Nedostatky by sa mali vysvetliť. Keď zákazník uvidí funkčnú verziu PS, prestane si uvedomovať, že pri honbe za funkčnou verziou PS existuje veľa problémov s kvalitou a pohodlie sprevádzania systémov. Keď o tom vývojár povie zákazníkovi, odpoveďou môže byť rozhorčenie a požiadavka na rýchlu transformáciu layoutu na funkčný produkt. To negatívne ovplyvňuje riadenie vývoja softvéru.

Na druhej strane, aby vývojár rýchlo získal funkčné usporiadanie, často robí určité kompromisy. Napríklad môžu byť použité nevhodné programovacie jazyky, resp operačný systém. 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á vzdialená od ideálnej zvolenej možnosti.

Pred pohľadom na iné modely životného cyklu softvéru, ktoré boli nahradené model vodopádu, treba sa pozastaviť nad návrhovými stratégiami softvérové ​​systémy. 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 na vytváranie softvérových systémov:

• jeden priechod (kaskádová stratégia diskutovaná vyššie) - lineárna postupnosť krokov návrhu;
• prírastkovú stratégiu. Na začiatku procesu sa stanovia všetky užívateľské a systémové požiadavky, zvyšok konštrukcie sa realizuje ako séria verzií. Prvá verzia implementuje niektoré z plánovaných funkcií, ďalšia verzia implementuje ďalšie funkcie atď., kým sa nezíska kompletný systém;
• evolučnej stratégie. Systém je tiež zostavený ako séria verzií, ale nie všetky požiadavky sú definované na začiatku procesu. Požiadavky sú špecifikované ako výsledok vývoja verzií. Charakteristiky stratégií návrhu softvéru v súlade s požiadavkami normy IEEE/EIA 12207 sú uvedené v tabuľke 1.

prírastkový model

Prírastkový model je klasickým príkladom prírastkovej dizajnovej stratégie. Spája prvky sekvenčného modelu vodopádu s iteratívnou filozofiou rozloženia (navrhnutý B. Boehmom ako vylepšenie model vodopádu). Každá sekvencia riadkov tu generuje dodaný softvérový prírastok. Napríklad softvér na spracovanie textu v 1. prírastku (verzii) implementuje základné funkcie spracovania, úpravy a dokumentácie súborov; v 2. prírastku - sofistikovanejšie možnosti úprav a dokumentácie; v 3. prírastku - kontrola pravopisu a gramatiky; v 4. prírastku - možnosti rozloženia stránky.

Výsledkom prvého prírastku je základný produkt, ktorý implementuje základné požiadavky (mnohé pomocné požiadavky však zostávajú nerealizované). Plán pre ďalší prírastok zahŕňa úpravu základného produktu, aby poskytoval ďalšie funkcie a funkcie.

Svojou povahou je inkrementálny proces iteratívny, ale na rozdiel od breadboarding, inkrementálny model poskytuje pracovný produkt pri každom inkremente.

Schéma takéhoto modelu životného cyklu softvéru je znázornená na obrázku. Jednou z moderných implementácií inkrementálneho prístupu je extrémne programovanie (zamerané na veľmi malé prírastky funkčnosti).

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

špirálový model je klasickým príkladom evolučnej dizajnovej stratégie. Model (autor B. Boehm, 1988) je založený na najlepších vlastnostiach klasického životného cyklu a prototypovania, ku ktorému sa pridáva nový prvok - analýza rizika, ktorá v týchto paradigmách absentuje. Model definuje štyri aktivity reprezentované štyrmi kvadrantmi špirály.

1. Plánovanie je definovanie cieľov, možností a obmedzení.
2. Analýza rizika – analýza možností a rozpoznanie/výber rizika.
3. Inžinierstvo je ďalšou úrovňou vývoja produktu.
4. Hodnotenie - vyhodnotenie aktuálnych výsledkov návrhu zákazníkom.

Integračný aspekt špirálový model je zrejmé pri uvažovaní radiálneho rozmeru skrutkovice. S každou iteráciou viac a viac plné verzie PS. V prvom otočení špirály sa definujú počiatočné ciele, možnosti a obmedzenia, rozpozná sa a analyzuje riziko. Ak analýza rizík odhalí neistotu požiadaviek, prototyp použitý v kvadrante dizajnu prichádza na pomoc vývojárovi a zákazníkovi.

Modelovanie môže byť použité na ďalšiu identifikáciu problematických a rafinovaných požiadaviek. Zákazník hodnotí inžiniersku (projektovú) prácu a dáva návrhy na úpravy (kvadrant hodnotenia zákazníka). Ďalšia fáza plánovania a analýzy rizík je založená na návrhoch zákazníkov. V každom cykle cez špirálu sa výsledky analýzy rizík formujú vo forme „pokračovať, nepokračovať“. Ak je riziko príliš veľké, projekt môže byť zastavený.

Vo väčšine prípadov špirála pokračuje, pričom každý krok tlačí vývojárov k všeobecnejšiemu modelu systému. Každá slučka v špirále vyžaduje konštrukciu (pravý dolný kvadrant), ktorú možno implementovať klasickým životným cyklom alebo maketou. Všimnite si, že počet rozvojových aktivít (prebiehajúcich v pravom dolnom kvadrante) sa zvyšuje, keď sa vzďaľujete od stredu špirály.

Tieto akcie sú očíslované a majú nasledujúci obsah:

1. – zhromažďovanie počiatočných požiadaviek a plánovanie projektu;
2. – rovnaká práca, ale na základe odporúčaní zákazníka;
3. – analýza rizík založená na počiatočných požiadavkách;
4. – analýza rizík založená na reakcii zákazníka;
5. – prechod na integrovaný systém;
6. – počiatočné usporiadanie systému;
7. - ďalšia úroveň rozloženia;
8. – navrhnutý systém;
9. - Hodnotenie klientom.

Výhody špirálový model:

1. najrealistickejšie (vo forme evolúcie) odráža vývoj softvéru;
2. umožňuje explicitne zohľadniť riziko v každej fáze vývoja;
3. zahŕňa krok systémový prístup do iteratívnej vývojovej štruktúry;
4. používa simuláciu na zníženie rizika a zlepšenie softvérového produktu.

nevýhody špirálový model:

• komparatívna novinka (neexistuje dostatočná štatistika o účinnosti modelu);
• zvýšené požiadavky na zákazníka;
• Ťažkosti s monitorovaním a riadením času vývoja.

Špirálový model procesu vývoja je v súčasnosti najbežnejší. Jeho najznámejšie varianty sú RUP (Rational Unified Process) od Rational a MSF (Microsoft Solution Framework). Ako modelovací jazyk sa používa UML (Unified Modeling Language). Predpokladá sa, že vytvorenie systému bude prebiehať iteratívne, bude sa pohybovať v špirále a bude prechádzať rovnakými fázami pri každom kroku, aby sa spresnili vlastnosti budúceho produktu. Zdá sa, že teraz je všetko v poriadku: plánuje sa iba to, čo sa dá predvídať, vyvíja sa to, čo sa plánuje, a používatelia sa začínajú s produktom oboznamovať vopred, pričom majú možnosť vykonať potrebné úpravy.

To si však vyžaduje veľmi veľké finančné prostriedky. Ak totiž skôr bolo možné vytvárať a rozpúšťať skupiny špecialistov podľa potreby, teraz sa na projekte musia neustále podieľať všetci: architekti, programátori, testeri, inštruktori atď. rôzne skupiny by mali byť synchronizované, aby včas odrážali rozhodnutia o dizajne a robili potrebné zmeny.

Rational Unified Process

Racionálne jednotný proces(Rational Unified Process, RUP) je jednou z najlepších metodík vývoja softvéru. Na základe skúseností z mnohých úspešných softvérových projektov vám RUP umožňuje vytvárať komplexné softvérové ​​systémy založené na metódach priemyselného vývoja. Predpoklady pre rozvoj RUP vznikli začiatkom 80. rokov 20. storočia. v spoločnosti Rational Software. Začiatkom roku 2003 Rational získal IBM. Jedným z hlavných pilierov, o ktorý sa RUP opiera, je proces vytvárania modelov pomocou Unified Modeling Language (UML).

RUP je jednou zo špirálových metodík vývoja softvéru. Metodológia je udržiavaná a vyvíjaná spoločnosťou Rational Software. Spoločná báza znalostí používa ako modelovací jazyk Unified Modeling Language (UML). Iteračný a prírastkový vývoj softvéru v RUP zahŕňa rozdelenie projektu na niekoľko projektov, ktoré sa vykonávajú postupne, pričom každá iterácia vývoja je jasne definovaná súborom cieľov, ktoré sa majú dosiahnuť na konci iterácie. Finálna iterácia predpokladá, že množina cieľov iterácie sa musí presne zhodovať so množinou cieľov špecifikovaných zákazníkom produktu, to znamená, že musia byť splnené všetky požiadavky.

Proces zahŕňa vývoj modelov; iterácia vývojového cyklu jednoznačne zodpovedá konkrétnej verzii softvérového modelu. Každá z iterácií obsahuje ovládacie prvky životný cyklus softvéru: analýza a návrh (modelovanie), implementácia, integrácia, testovanie, implementácia. V tomto zmysle je RUP implementáciou špirálový model, aj keď sa pomerne často zobrazuje vo forme grafu a tabuľky.

Tento obrázok ukazuje dva rozmery: horizontálna os predstavuje čas a ukazuje časové aspekty životného cyklu procesu; vertikálna os predstavuje disciplíny, ktoré definujú fyzickú štruktúru procesu. Môžete vidieť, ako sa dôraz v projekte mení v priebehu času. Napríklad skoré iterácie trávia viac času požiadavkami; v neskorších iteráciách sa implementácii venuje viac času. Horizontálna os je tvorená časovými úsekmi - iteráciami, z ktorých každé je samostatným vývojovým cyklom; cieľom cyklu je priniesť určité vopred určené hmatateľné zdokonalenie konečného produktu, ktoré je užitočné z pohľadu zainteresovaných strán.

Na časovej osi je životný cyklus rozdelený do štyroch hlavných fáz.

1. Štart (Inception) - vytvorenie konceptu projektu, pochopenie toho, čo tvoríme, predstava o produkte (vízia), vypracovanie podnikateľského plánu (obchodný prípad), príprava prototypový program alebo čiastočné riešenie. Toto je fáza zhromažďovania informácií a analýzy požiadaviek, definovanie obrazu projektu ako celku. Cieľom je získať podporu a financie. V záverečnej iterácii sú výsledkom tejto fázy referenčné podmienky.
2. Návrh, vývoj (Spracovanie) - objasnenie plánu, pochopenie toho, ako ho tvoríme, návrh, plánovanie potrebných akcií a zdrojov, spresnenie funkcií. Etapa končí vykonateľnou architektúrou, keď sa urobia všetky architektonické rozhodnutia a zohľadnia sa riziká. Spustiteľná architektúra je spustený softvér, ktorý demonštruje implementáciu zákl architektonické riešenia. V konečnej iterácii ide o technický projekt.
3. Implementácia, tvorba systému (Construction) je etapa rozširovania funkcionality systému zabudovaného do architektúry. V konečnej iterácii ide o pracovný návrh.
4. Implementácia, nasadenie (Transition). Vytvorenie finálnej verzie produktu. Fáza implementácie produktu, dodanie produktu konkrétnemu užívateľovi (replikácia, dodávka a školenie).

Vertikálna os pozostáva z disciplín, z ktorých každá môže byť podrobnejšie opísaná z hľadiska vykonávaných úloh, rolí zodpovedných za ne, produktov, ktoré sú vstupom do úloh a uvoľnené počas ich vykonávania atď.

Pozdĺž tejto osi sú kľúčové disciplíny životného cyklu RUP, ktoré sa v ruštine často nazývajú procesy, aj keď to nie je úplne pravda z hľadiska tejto metodológie, podporovanej nástrojmi IBM (a / alebo tretích strán).

1. Podniková analýza a modelovanie ( Business modeling ) poskytuje implementáciu princípov modelovania s cieľom študovať podnikanie organizácie a zhromažďovať poznatky o ňom, optimalizovať obchodné procesy a rozhodovať o ich čiastočnej alebo úplnej automatizácii.
2. Riadenie požiadaviek spočíva v preberaní informácií od zainteresovaných strán a ich transformácii na súbor požiadaviek, ktoré definujú obsah vyvíjaného systému a podrobne uvádzajú očakávania toho, čo by mal systém robiť.
3. Analýza a návrh (Analýza a návrh) zahŕňa postupy na transformáciu požiadaviek na prechodné popisy (modely), ktoré predstavujú, ako by sa tieto požiadavky mali implementovať.
4. Implementácia zahŕňa vývoj kódu, testovanie na úrovni vývojárov a integráciu komponentov, subsystémov a celého systému v súlade so stanovenými špecifikáciami.
5. Testovanie je zamerané na posúdenie kvality vytváraného produktu.
6. Nasadenie zahŕňa operácie, ktoré prebiehajú pri dodávaní produktov zákazníkom a sprístupnení produktu koncovým používateľom.
7. Konfiguračný manažment a manažment zmien (Configuration management) sa venuje synchronizácii medziproduktov a finálnych produktov a riadeniu ich vývoja počas projektu a hľadaniu skrytých problémov.
8. Projektový manažment sa venuje plánovaniu projektov, riadeniu rizík, monitorovaniu priebehu projektu a priebežnému vyhodnocovaniu kľúčových ukazovateľov.
9. Manažérske prostredie (Environment) zahŕňa prvky formovania vývojového prostredia informačný systém a podpora projektových aktivít.

V závislosti od špecifík projektu je možné použiť akékoľvek nástroje IBM Rational, ako aj nástroje tretích strán. RUP odporúča dodržiavať šesť postupov pre úspešný rozvoj projektu: iteratívny vývoj; riadenie požiadaviek; používanie modulárnych architektúr; vizuálne modelovanie; kontrola kvality; sledovanie zmien.

Neoddeliteľnou súčasťou RUP sú artefakty (artefakt), precedensy (precedent) a role (rola). Artefakty sú niektoré z produktov projektu, ktoré sa v ňom generujú alebo používajú pri práci na konečnom produkte. Prípady použitia sú sekvencie akcií vykonávaných systémom, aby sa dosiahol pozorovateľný výsledok. V skutočnosti je artefaktom každý výsledok práce jednotlivca alebo skupiny, či už ide o analytický dokument, modelový prvok, kódový súbor, testovací skript, popis chyby atď. Určití špecialisti sú zodpovední za vytvorenie jedného alebo druhého typu artefaktu. RUP teda jasne definuje zodpovednosti – roly – každého člena vývojového tímu v tej či onej fáze, teda kedy a kto má ten či onen artefakt vytvoriť. Celý proces vývoja softvérového systému sa v RUP považuje za proces vytvárania artefaktov – od dokumentov prvotnej analýzy až po spustiteľné moduly, používateľské príručky atď.

Na počítačovú podporu procesov RUP vyvinula spoločnosť IBM širokú škálu nástrojov:

• Rational Rose-CASE- vizuálny modelovací nástroj informačných systémov, ktorý má schopnosť generovať prvky kódu. Špeciálna edícia produktu - Rational Rose RealTime - vám umožňuje získať spustiteľný modul na výstupe;
• Rational Requisite Pro je nástroj na správu požiadaviek, ktorý vám umožňuje vytvárať, štruktúrovať, uprednostňovať, sledovať a kontrolovať zmeny požiadaviek, ktoré sa vyskytujú v ktorejkoľvek fáze vývoja komponentov aplikácie;
• Rational ClearQuest je produkt na správu zmien a sledovanie chýb, ktorý sa úzko integruje s nástrojmi na testovanie a správu požiadaviek a poskytuje jednotné prostredie na vzájomné prepojenie všetkých chýb a dokumentov;
• Rational SoDA je produkt na automatické generovanie projektovej dokumentácie, ktorý umožňuje inštaláciu firemný štandard pre firemné dokumenty. Dokumentáciu je možné priniesť aj na už existujúce normy(ISO, CMM);
• Rational Purify, Rational Quantify, nástroje na testovanie a ladenie Rational PureCoverage;
• Rational Visual Quantify je nástroj na meranie výkonu pre vývojárov aplikácií a komponentov v jazykoch C/C++, Visual Basic a Java; pomáha identifikovať a odstraňovať úzke miesta vo výkone softvéru;
• Rational Visual PureCoverage – automaticky deteguje oblasti kódu, ktoré nie sú testované;
• Rational ClearCase je produkt na správu konfigurácie softvéru (Rational's Software Configuration Management, SCM), ktorý umožňuje kontrolu verzií všetkých projektových dokumentov. Možno ho použiť na udržiavanie viacerých verzií projektov súčasne a rýchle prepínanie medzi nimi. Rational Requisite Pro podporuje aktualizácie a sleduje zmeny v požiadavkách na vývojový tím;
• Nástroj SQA TeamTest automatizácia testov;
• Rational TestManager je systém správy testov, ktorý spája všetky nástroje, artefakty, skripty a údaje súvisiace s testovaním;
• Rational Robot - nástroj na vytváranie, úpravu a automatické spúšťanie testov;
• SiteLoad, SiteCheck - nástroje na testovanie webových stránok na výkon a nefunkčné odkazy;
• Rational PerformanceStudio – Merajte a predpovedajte výkonnostné charakteristiky systémov.

Táto sada produktov sa neustále zdokonaľuje a rozširuje. Napríklad najnovší produkt IBM Rational Software Architect (RSA) je súčasťou IBM Software Development Platform, sady nástrojov, ktoré podporujú životný cyklus vývoja softvérových systémov. Produkt IBM Rational Software Architect je určený na vytváranie modelov vyvíjaných softvérových systémov pomocou jednotného modelovacieho jazyka UML 2.0, predovšetkým modelov architektúry vyvíjanej aplikácie. RSA však kombinuje funkčnosť softvérových produktov, ako sú Rational Application Developer, Rational Web Developer a Rational Software Modeler, čím umožňuje architektom a analytikom vytvárať rôzne pohľady na informačný systém vo vývoji pomocou jazyka UML 2.0 a vývojárom vykonávať vývoj. J2EE, XML, webové služby atď.

Podľa princípov RUP vám Rational Software Architect umožňuje vytvárať potrebné modely v rámci pracovných postupov disciplín, ako sú:

• obchodné analýzy a modelovanie (obchodné modelovanie);
• Riadenie požiadaviek (Požiadavky);
• analýza a návrh (Analýza a návrh);
• implementácia (Implementation).

Okrem toho Rational Software Architect podporuje technológiu vývoja riadeného modelom (MDD), ktorá vám umožňuje modelovať softvér na rôznych úrovniach abstrakcie s sledovateľnosťou.

MSF (Microsoft Solution Framework)

V roku 1994, v snahe vyťažiť maximum z IT projektov, spoločnosť Microsoft vydala súbor pokynov na efektívne navrhovanie, vývoj, implementáciu a údržbu riešení postavených na jej technológii. Tieto znalosti sú založené na skúsenostiach získaných spoločnosťou Microsoft pri práci na veľkých projektoch vývoja a údržby softvéru, na skúsenostiach konzultantov spoločnosti Microsoft a na tom najlepšom, čo sa nazbieralo v tento moment IT priemysel. Toto všetko je prezentované vo forme dvoch vzájomne prepojených a dobre sa dopĺňajúcich oblastí znalostí: Microsoft Solutions Framework (MSF) a Microsoft Operations Framework (MOF).

Je potrebné poznamenať, že spoločnosť Microsoft vyvinula metodiky založené na všeobecných metódach Lekárov bez hraníc pre aplikované a špecializované aplikácie. Okrem toho spoločnosť Microsoft certifikuje expertov špeciálne pre aplikované znalosti v aplikácii MSF (napríklad certifikácia MCTS 74-131 pre odbornosť v metodológii projektového riadenia). Predtým, ako sa zoznámite s metódami Lekárov bez hraníc, musíte najprv určiť, ktorú aplikáciu Lekárov bez hraníc máte na mysli.

Najpopulárnejšie aplikačné varianty MSF vyvinuté spoločnosťou Microsoft sú:

• metodika implementácie riešení v oblasti projektového manažmentu;
• Metodológia riadenia IT projektov založená na metodikách MSF a Agile.

Dôležitosť aplikovaných variantov MSF zdôrazňuje fakt, že v „čistej verzii“ samotnú metodiku MSF nepoužíva Microsoft vo svojich IT projektoch. Projekty Microsoft Consulting Services využívajú hybridnú metodológiu medzi MSF a Agile. Napriek vonkajším významným rozdielom medzi aplikovanými verziami MSF vyvinutými odborníkmi Microsoftu, základ metód MSF pre nich zostáva spoločný a odráža spoločné metodologické prístupy k riadeniu iteratívnych projektov.

MOF je navrhnutý tak, aby organizáciám, ktoré budujú kritické IT riešenia založené na produktoch a technológiách spoločnosti Microsoft, poskytoval technické poradenstvo, ako dosiahnuť ich spoľahlivosť, dostupnosť, pohodlie sprevádzania(podporovateľnosť) a spravovateľnosť (manažovateľnosť). MF rieši otázky súvisiace s organizáciou personálu a procesov; technológií a riadenia v podmienkach komplexných (komplexných), distribuovaných (distribuovaných) a heterogénnych (heterogénnych) prostredí IT. MOF je založené na osvedčených postupoch zhromaždených v knižnici IT infraštruktúry (ITIL), ktorú zostavila Centrálna počítačová a telekomunikačná agentúra, vládna agentúra Spojeného kráľovstva.

Vytvorenie podnikového riešenia v rámci stanoveného času a rozpočtu si vyžaduje overený metodologický základ. Lekári bez hraníc poskytujú osvedčené metodiky plánovania, navrhovania, vývoja a implementácie úspešných IT riešení. Vďaka svojej flexibilite, škálovateľnosti a nedostatku pevných smerníc sú Lekári bez hraníc schopní splniť potreby organizácie alebo projektového tímu akejkoľvek veľkosti. Metodika Lekárov bez hraníc pozostáva z princípov, modelov a disciplín pre riadenie personálu, procesov, technologických prvkov a otázok súvisiacich so všetkými týmito faktormi, ktoré sú typické pre väčšinu projektov. Lekári bez hraníc pozostávajú z dvoch modelov a troch disciplín. Sú podrobne popísané v 5 bielych knihách. Je lepšie začať študovať MSF s modelmi (model projektového tímu, procesný model) a potom prejsť na disciplíny (disciplína projektového manažmentu, disciplína manažmentu rizík, disciplína manažmentu školenia).

Procesný model MSF predstavuje všeobecnú metodiku vývoja a implementácie IT riešení. Zvláštnosťou tohto modelu je, že vďaka svojej flexibilite a absencii pevne stanovených postupov je možné ho aplikovať pri vývoji veľmi širokého spektra IT projektov. Tento model kombinuje vlastnosti dvoch štandardných výrobných modelov: kaskáda (vodopád) a špirála (špirála). Procesný model v MSF 3.0 bol ďalej inovatívny: pokrýva celý životný cyklus riešenia, od počiatočného bodu až po implementáciu. Tento prístup pomáha projektovým tímom zamerať sa na obchodnú hodnotu riešenia, pretože táto hodnota sa stáva reálnou až po dokončení implementácie a používaní produktu.

Proces Lekárov bez hraníc je zameraný na „míľniky“ – kľúčové body projektu, charakterizujúce dosiahnuté výsledky v rámci akéhokoľvek významného (priebežného alebo konečného) výsledku. Tento výsledok je možné vyhodnotiť a analyzovať, čo znamená odpovede na otázky: „Did projektová skupina jasné pochopenie cieľov a rozsahu projektu?“, „Je akčný plán dostatočne pripravený?“, „Spĺňa produkt schválenú špecifikáciu?“, „Spĺňa riešenie potreby zákazníka?“ atď.

Procesný model Lekárov bez hraníc zohľadňuje neustále sa meniace požiadavky projektu. Vychádza z toho, že vývoj riešenia by mal pozostávať z krátkych cyklov, ktoré vytvárajú progresívny pohyb od najjednoduchších verzií riešenia až po jeho finálnu podobu.

Vlastnosti procesného modelu Lekárov bez hraníc sú:

• fázový a míľnikový prístup;
• iteračný prístup;
• integrovaný prístup k tvorbe a implementácii riešení.

Procesný model zahŕňa také hlavné fázy vývojového procesu, ako sú:

• vývoj koncepcií (predstavovanie);
• plánovanie (Plánovanie);
• vývoj (Vývoj);
• stabilizácia (Stabilizing);
• implementácia (Deploying).

Okrem toho existuje veľký počet prechodné míľniky, ktoré ukazujú dosiahnutie určitého pokroku v priebehu projektu a rozdeľujú veľké časti práce na menšie, pozorovateľné úseky. Pre každú fázu procesného modelu MSF definuje:

• čo (aké artefakty) je výsledkom tejto fázy;
• na čom každý z klastrov rolí v tejto fáze pracuje.

V rámci Lekárov bez hraníc sa kód, dokumentácia, návrhy, plány a iné pracovné materiály zvyčajne vytvárajú iteratívnym spôsobom. Lekári bez hraníc odporúčajú, aby ste začali s vývojom riešenia vytvorením, testovaním a nasadením jeho základných funkcií. Potom sa do riešenia pridávajú ďalšie a ďalšie funkcie. Táto stratégia sa nazýva stratégia tvorby verzií. Zatiaľ čo jedno vydanie môže postačovať pre menšie projekty, odporúča sa, aby ste nepremeškali príležitosť vytvoriť viacero verzií pre jedno riešenie. S vytváraním nových verzií sa vyvíja funkcionalita riešenia.

Iteratívny prístup k procesu vývoja si vyžaduje použitie flexibilnej dokumentácie. Živé dokumenty by sa mali meniť tak, ako sa projekt vyvíja spolu so zmenami v požiadavkách na konečný produkt. Lekári bez hraníc ponúkajú množstvo štandardných šablón dokumentov, ktoré sú artefaktmi každej fázy vývoja produktu a možno ich použiť na plánovanie a riadenie procesu vývoja.

Riešenie nemá žiadnu obchodnú hodnotu, kým nie je implementované. Práve z tohto dôvodu obsahuje procesný model MSF celý životný cyklus tvorby riešenia vrátane jeho implementácie až do momentu, kedy riešenie začne prinášať hodnotu.

Anotácia.

Úvod.

1. Životný cyklus softvéru

Úvod.

Kroky procesu programovania Riley

Úvod.

1.1.1. Formulácia problému.

1.1.2. Návrh riešenia.

1.1.3. Algoritmové kódovanie.

1.1.4. Programová podpora.

1.1.5. Softvérová dokumentácia.

Záver k bodu 1.1

1.2. Definícia ZhTsPO podľa Lehmana.

Úvod.

1.2.1 Definícia systému.

1.2.2. Implementácia.

1.2.3. servis.

Záver k bodu 1.2.

1.3. Fázy a práce programu životného cyklu podľa Boehma

1.3.1. kaskádový model.

1.3.2. Ekonomické zdôvodnenie kaskádového modelu.

1.3.3. Vylepšenie kaskádového modelu.

1.3.4. Definícia fáz životného cyklu.

1.3.5. Základná práca na projekte.

Literatúra.

Úvod

Priemyselné využitie počítačov a rastúci dopyt po programoch kladú naliehavé úlohy na výrazný nárast produktivita vývoja softvéru, rozvoj priemyselných metód plánovania a navrhovania programov, prenos organizačných, technických, technických, ekonomických a sociálno-psychologických techník, vzorov a metód zo sféry materiálovej výroby do sféry počítačov. Komplexný prístup do procesov vývoja, prevádzky a údržby softvéru kladie množstvo naliehavých problémov, ktorých riešením sa odstránia „úzke miesta“ pri navrhovaní programov, skráti sa čas dokončenia, zlepší sa výber a prispôsobenie existujúcich programov a možno určiť osud systémov so vstavanými počítačmi.

V praxi vývoja veľkých softvérových projektov často neexistuje jednotný prístup k hodnoteniu mzdových nákladov, termínov práce a materiálových nákladov, čo bráni zvyšovaniu produktivity vývoja softvéru a v konečnom dôsledku aj efektívnemu riadeniu životného cyklu softvéru. Keďže program akéhokoľvek druhu sa stáva produktom (možno okrem vzdelávacích, maketových programov), prístup k jeho výrobe by mal byť v mnohých ohľadoch podobný prístupu k výrobe priemyselných produktov a otázky dizajnu softvéru sa stávajú mimoriadne dôležitými. . Táto myšlienka je základom B.U. Boehm "Software Engineering Design", ktorý sme použili na napísanie tohto článku ročníková práca. V tejto knihe sa softvérový dizajn vzťahuje na proces vytvárania dizajnu softvérového produktu.

1 Životný cyklus softvéru

ÚVOD

LCPE je nepretržitý proces, ktorý začína od momentu rozhodnutia o potrebe vytvorenia softvéru a končí momentom jeho úplného stiahnutia z prevádzky.

Existuje niekoľko prístupov k definovaniu fáz a činností životného cyklu softvéru (SLLC), programovacích procesných krokov, vodopádových a špirálových modelov. Všetky však obsahujú spoločné základné komponenty: vyhlásenie o probléme, návrh riešenia, implementácia, údržba.

Najznámejšia a najkompletnejšia je snáď štruktúra životného cyklu podľa Boehma, ktorá zahŕňa osem fáz. Podrobnejšie bude predstavený neskôr.

Jednou z možných možností môže byť popis hornej úrovne podľa Lehmana, ktorý zahŕňa tri hlavné fázy a predstavuje popis programu životného cyklu v najvšeobecnejšom prípade.

A tu sú pre zmenu kroky procesu programovania prezentované D. Rileyom v knihe „Using the Modula-2 Language“. Táto myšlienka je podľa mňa veľmi jednoduchá a známa a začneme ňou.

1.1 Kroky procesu programovania Riley

Úvod

Proces programovania zahŕňa štyri kroky (obr. 1):

vyhlásenie o probléme, t.j. získanie primeranej predstavy o tom, akú úlohu by mal program vykonávať;

navrhnutie riešenia už nastoleného problému (vo všeobecnosti je takéto riešenie menej formálne ako konečný program);

programové kódovanie, t.j. preklad navrhnutého riešenia do programu, ktorý je možné vykonať na stroji;

programová podpora, t.j. prebiehajúci proces odstraňovania chýb v programe a pridávania nových funkcií.

Ryža. 1.Štyri kroky programovania.

Programovanie začína od momentu, kedy užívateľ, t.j. niekto, kto potrebuje program na vyriešenie problému, predstavuje problém systémový analytik. Používateľ a systémový analytik spoločne definujú vyhlásenie o probléme. Ten sa potom prenesie algoritmista kto je zodpovedný za návrh riešenia. Riešenie (alebo algoritmus) je postupnosť operácií, ktorých vykonanie vedie k riešeniu problému. Keďže algoritmus často nie je prispôsobený na vykonanie na stroji, mal by byť preložený do strojového programu. Túto operáciu vykonáva kódovač. Správca je zodpovedný za následné zmeny programu. programátor. A systémový analytik, algoritmus, kódovač a sprievodný programátor - to všetko sú programátori.

V prípade veľkého softvérového projektu môže byť počet používateľov, systémových analytikov a algoritmov významný. Okrem toho môže byť potrebné vrátiť sa k predchádzajúcim krokom v dôsledku nepredvídaných okolností. Toto všetko slúži ako dodatočný argument v prospech starostlivého návrhu softvéru: výsledky každého kroku by mali byť úplné, presné a zrozumiteľné.

1.1.1 Vyhlásenie problému

Jedným z najdôležitejších krokov pri programovaní je nastavenie problému. Funguje ako zmluva medzi používateľom a programátorom (programátormi). Rovnako ako právne zle vypracovaná zmluva, aj zlé vyhlásenie o poslaní je zbytočné. Pri dobrom zadaní problému užívateľ aj programátor jasne a jednoznačne predstavujú úlohu, ktorú treba vykonať, t.j. v tomto prípade sa berú do úvahy záujmy používateľa aj programátora. Používateľ si môže naplánovať používanie softvéru, ktorý ešte nebol vytvorený, na základe vedomostí, ktoré môže. Dobré vyjadrenie problému slúži ako základ pre formovanie jeho riešenia.

Formulácia problému (špecifikácia programu); v podstate znamená presný, úplný a zrozumiteľný popis toho, čo sa stane pri spustení konkrétneho programu. Používateľ sa zvyčajne pozerá na počítač ako na čiernu skrinku: nezáleží mu na tom, ako počítač funguje, ale je dôležité, aby počítač mohol robiť to, čo používateľa zaujíma. Dôraz je kladený na interakciu medzi človekom a strojom.

Charakteristiky dobrého vyhlásenia o probléme:

Presnosť, t.j. vylúčenie akejkoľvek nejednoznačnosti. Nemali by existovať žiadne otázky o tom, aký bude výstup programu pre daný vstup.

úplnosť, t.j. zváženie všetkých možností pre daný vstup, vrátane chybného alebo neočakávaného vstupu, a určenie vhodného výstupu.

Jasnosť, t.j. malo by byť zrozumiteľné pre používateľa aj pre systémového analytika, pretože vyhlásenie o probléme je jedinou zmluvou medzi nimi.

Požiadavky na presnosť, úplnosť a jasnosť sú často v rozpore. Mnohé právne dokumenty sú teda ťažko zrozumiteľné, pretože sú napísané formálnym jazykom, ktorý umožňuje formulovať určité ustanovenia s maximálnou presnosťou, s vylúčením aj tých najnepodstatnejších nezrovnalostí. Napríklad niektoré otázky na skúške sú niekedy formulované tak presne, že študent strávi viac času porozumením otázky, než jej zodpovedaním. Študent navyše nemusí vôbec pochopiť hlavný zmysel otázky kvôli veľkému množstvu detailov. Najlepšie vyhlásenie o probléme je také, ktoré dosahuje rovnováhu všetkých troch požiadaviek.

Štandardná forma vyhlásenia o probléme.

Zvážte nasledujúce vyhlásenie problému: "Zadajte tri čísla a vypíšte čísla v poradí."

Takéto vyhlásenie nespĺňa vyššie uvedené požiadavky: nie je presné, ani úplné, ani zrozumiteľné. Naozaj, mali by sa čísla zadávať jedno na riadok alebo všetky čísla na jeden riadok? Znamená výraz „v poradí“ zoradenie od najväčšieho po najmenšie, od najmenšieho po najväčšie alebo rovnaké poradie, v akom boli uvedené?

Je zrejmé, že takéto vyhlásenie neodpovedá na mnohé otázky. Ak vezmeme do úvahy odpovede na všetky otázky, potom sa problémové vyhlásenie stane rozvláčnym a ťažko zrozumiteľným. Preto D. Riley navrhuje použiť na stanovenie problému štandardný formulár, ktorý zabezpečuje maximálnu presnosť, úplnosť, prehľadnosť a zahŕňa:

názov úlohy (schematická definícia);

všeobecný popis (stručné vyjadrenie úlohy);

chyby (neobvyklé možnosti vstupu sú explicitne uvedené, aby ukázali používateľom a programátorom akcie, ktoré stroj vykoná v takýchto situáciách);

príklad ( dobrý príklad môže sprostredkovať podstatu problému, ako aj ilustrovať rôzne prípady).

Príklad. Vyhlásenie problému v štandardnom formulári.

TITLE

Zoradiť tri celé čísla.

POPIS

Vstup a výstup troch celých čísel zoradených od najmenšieho po najväčšie.

Zadávajú sa tri celé čísla, jedno číslo na riadok. V tomto prípade je celé číslo jedna alebo viac po sebe idúcich desatinných číslic, ktorým môže predchádzať znamienko plus „+“ alebo znamienko mínus „-“.

Vypíšu sa tri zadané celé čísla, pričom všetky tri sa zobrazia na rovnakom riadku. Susedné čísla sú oddelené medzerou. Čísla sa zobrazujú od najmenšieho po najväčšie, zľava doprava.

1) Ak zadáte menej ako tri čísla, program čaká na ďalšie zadanie.

2) Vstupné riadky iné ako prvé tri sa ignorujú.

3) Ak niektorý z prvých troch riadkov obsahuje viac ako jedno celé číslo, program sa ukončí a vydá správu.

Životný cyklus softvéru

Životný cyklus softvéru je časový úsek, ktorý začína okamihom prijatia rozhodnutia o potrebe vytvorenia softvérového produktu a končí okamihom jeho úplného vyradenia z prevádzky. (IEEE Std 610.12)

Potreba určiť fázy životného cyklu softvéru (LC) je spôsobená túžbou vývojárov zlepšiť kvalitu softvéru optimálne ovládanie vývoj a používanie rôznych mechanizmov kontroly kvality v každej fáze, od stanovenia úloh až po podporu pri tvorbe softvéru. Najvšeobecnejším znázornením životného cyklu softvéru je model vo forme základných etáp – procesov, medzi ktoré patria:

Systémová analýza a zdôvodnenie softvérových požiadaviek;

Predbežný (náčrt) a podrobný (technický) návrh softvéru;

Vývoj softvérových komponentov, ich integrácia a ladenie softvéru vo všeobecnosti;

Testovanie, skúšobná prevádzka a replikácia softvéru;

Pravidelná prevádzka softvéru, údržba prevádzky a analýza výsledkov;

Údržba softvéru, jeho úpravy a vylepšovanie, vytváranie nových verzií.

Tento model je všeobecne akceptovaný a zodpovedá obom domácim regulačné dokumenty v oblasti vývoja softvéru, a zahr. Z hľadiska poskytovania technologická bezpečnosť je vhodné podrobnejšie zvážiť vlastnosti znázornenia fáz životného cyklu v zahraničných modeloch, pretože práve cudzí softvér je najpravdepodobnejším nositeľom softvérových defektov typu sabotáže.

Štandardy životného cyklu softvéru

GOST 34.601-90

ISO/IEC 12207:1995 (ruský analóg - GOST R ISO/IEC 12207-99)

Grafické znázornenie modelov životného cyklu umožňuje vizuálne zvýrazniť ich vlastnosti a niektoré vlastnosti procesov.

Spočiatku bol vytvorený kaskádový model životného cyklu, v ktorom hlavné etapy začali jedna po druhej s využitím výsledkov predchádzajúcej práce. Zabezpečuje postupnú implementáciu všetkých fáz projektu v presne stanovenom poradí. Prechod do ďalšej fázy znamená úplné dokončenie práce v predchádzajúcej fáze. Požiadavky definované vo fáze tvorby požiadaviek sú prísne zdokumentované vo forme zadávacích podmienok a pevne stanovené počas celého trvania vývoja projektu. Každá fáza vyvrcholí vydaním kompletnej sady dokumentácie, ktorá je dostatočná na to, aby vo vývoji mohol pokračovať ďalší vývojový tím. Nepresnosť akejkoľvek požiadavky alebo jej nesprávna interpretácia v dôsledku toho vedie k tomu, že sa musíte „vrátiť“ do ranej fázy projektu a požadovaná revízia nielenže vyradí projektový tím z harmonogramu, ale často vedie k kvalitatívne zvýšenie nákladov a je možné aj ukončenie projektu v podobe, v akej bol pôvodne koncipovaný. Hlavným omylom autorov vodopádového modelu je predpoklad, že návrh prejde celým procesom raz, navrhnutá architektúra je dobrá a ľahko použiteľná, návrh implementácie je rozumný a chyby pri implementácii sa dajú ľahko odstrániť pomocou testovanie. Tento model predpokladá, že všetky chyby sa budú koncentrovať pri implementácii, a preto k ich odstraňovaniu dochádza rovnomerne pri testovaní komponentov a systému. Vodopádový model pre veľké projekty teda nie je príliš realistický a dá sa efektívne použiť len na vytváranie malých systémov.

Najšpecifickejší je špirálový model životného cyklu. V tomto modeli sa pozornosť sústreďuje na iteračný proces počiatočných fáz návrhu. V týchto fázach sa postupne vytvárajú koncepty, špecifikácie požiadaviek, predbežný a podrobný návrh. V každom kole sa špecifikuje obsah práce a sústredí sa vzhľad vytváraného softvéru, posúdi sa kvalita získaných výsledkov a naplánuje sa práca ďalšej iterácie. Pri každej iterácii sa vyhodnocujú:

Riziko prekročenia podmienok a nákladov projektu;

Potreba vykonať ďalšiu iteráciu;

Stupeň úplnosti a presnosti pochopenia požiadaviek na systém;

Vhodnosť ukončenia projektu.

Štandardizácia životného cyklu softvéru prebieha v troch smeroch. Prvý smer organizuje a stimuluje Medzinárodná organizácia pre normalizáciu (ISO - International Standard Organization) a Medzinárodná elektrotechnická komisia (IEC - International Electro-technical Commission). Na tejto úrovni sa realizuje štandardizácia najbežnejších technologických procesov dôležitých pre medzinárodnú spoluprácu. Druhý smer aktívne rozvíja v USA Institute of Electrical and Electronics Engineers (IEEE - Institute of Electrotechnical and Electronics Engineers) spolu s American National Standards Institute (ANSI). Normy ISO/IEC a ANSI/IEEE majú väčšinou poradný charakter. Tretí smer stimuluje Ministerstvo obrany USA (Department of Defense-DOD). Normy DOD sú povinné pre firmy pracujúce v mene Ministerstva obrany USA.

Pre návrh softvéru komplexný systém, najmä systémov v reálnom čase, je vhodné použiť celosystémový model životného cyklu založený na integrácii všetkých slávnych diel pod kontrolou základné procesy. Tento model je určený na použitie pri plánovaní, plánovaní, riadení rôznych softvérových projektov.

Súbor etáp tohto modelu životného cyklu je vhodné rozdeliť na dve časti, ktoré sa výrazne líšia charakteristikami procesov, technickými a ekonomickými charakteristikami a faktormi, ktoré ich ovplyvňujú.

V prvej časti životného cyklu sa vykonáva systémová analýza, návrh, vývoj, testovanie a testovanie softvéru. Rozsah prác, ich zložitosť, trvanie a ďalšie charakteristiky v týchto etapách výrazne závisia od objektu a vývojového prostredia. Štúdium takýchto závislostí pre rôzne triedy softvéru umožňuje predpovedať zloženie a hlavné charakteristiky pracovných harmonogramov pre nové verzie softvéru.

Druhá časť životného cyklu, ktorá odráža podporu prevádzky a údržby softvéru, pomerne slabo súvisí s charakteristikou objektu a vývojového prostredia. Rozsah prác v týchto fázach je stabilnejší a ich zložitosť a trvanie sa môžu výrazne líšiť a závisia od masovej aplikácie softvéru. Pre akýkoľvek model poskytovania životného cyklu Vysoká kvalita softvérových systémov je možné len pri použití regulovaného technologického procesu v každej z týchto etáp. Takýto proces je podporovaný nástrojmi automatizácie vývoja, ktoré je vhodné vybrať z existujúcich alebo vytvoriť s prihliadnutím na objekt vývoja a jemu adekvátny zoznam prác.

Rozvoj CT neustále rozširuje triedy úloh na riešenie, ktoré súvisia so spracovaním informácií rôzneho charakteru.

V zásade ide o tri typy informácií, a teda tri triedy úloh, na ktoré sa používajú počítače:

1) Výpočtové úlohy spojené so spracovaním číselných informácií. Patrí medzi ne napríklad problém riešenia sústavy lineárnych rovníc vysokej dimenzie. Kedysi to bola hlavná, dominantná oblasť používania počítačov.

2) Úlohy na spracovanie symbolických informácií spojených s tvorbou, úpravou a transformáciou textových údajov. S riešením takýchto problémov je spojená práca napríklad sekretárky-pisárky.

3) Úlohy na spracovanie grafických informácií t.j. diagramy, nákresy, grafy, náčrty atď. Medzi takéto úlohy patrí napríklad vypracovanie výkresov nových produktov dizajnérom.

4) Úlohy na spracovanie alfanumerických informácií - IS. V súčasnosti sa stala jednou z hlavných oblastí použitia počítačov a úlohy sú čoraz komplikovanejšie.

Počítačové riešenie úloh každej triedy má svoje špecifiká, možno ho však rozdeliť do niekoľkých etáp, ktoré sú typické pre väčšinu problémov.

Technológia programovaniaštuduje technologické procesy a poradie ich prechodu (stupňov) s využitím poznatkov, metód a prostriedkov.

Technológie sú vhodne charakterizované v dvoch dimenziách – vertikálnej (reprezentujú procesy) a horizontálne (reprezentujú fázy).

Obrázok

Proces je súbor vzájomne súvisiacich činností (technologických operácií), ktoré transformujú niektoré vstupné dáta na výstupné dáta. Procesy pozostávajú zo súboru akcií (technologických operácií) a každá akcia pozostáva zo súboru úloh a metód na ich riešenie. Vertikálna dimenzia odráža statické aspekty procesov a pracuje s takými pojmami, ako sú pracovné procesy, akcie, úlohy, výsledky výkonu, umelci.

Etapa je časť aktivít vývoja softvéru, ohraničená určitým časovým rámcom a končiaca vydaním konkrétneho produktu, určená požiadavkami špecifikovanými pre túto etapu. Niekedy sa fázy kombinujú do väčších časových rámcov nazývaných fázy alebo míľniky. Horizontálna dimenzia teda predstavuje čas, odráža dynamické aspekty procesov a pracuje s pojmami, ako sú fázy, etapy, etapy, iterácie a kontrolné body.

Vývoj softvéru sleduje špecifický životný cyklus.

Životný cyklus Softvér je nepretržitý a usporiadaný súbor činností vykonávaných a riadených v rámci každého projektu vývoja a prevádzky softvéru, počnúc okamihom, keď sa objaví nápad (koncept) na vytvorenie nejakého softvéru a rozhodnutie o potreba ho vytvoriť a končí v momente jeho úplného stiahnutia z využívania z dôvodov:

a) zastarávanie;

b) strata potreby riešiť zodpovedajúce úlohy.

Technologické prístupy sú mechanizmy na realizáciu životného cyklu.

Technologický prístup je určený špecifikami kombinácie etáp a procesov, zameraných na rôzne triedy softvéru a na vlastnosti vývojového tímu.

Životný cyklus definuje štádiá (fázy, štádiá) tak, že softvérový produkt prechádza z jednej fázy do druhej, od koncepcie produktu až po štádium jeho poskladania.

Životný cyklus vývoja softvéru môže byť prezentovaný s rôznym stupňom detailov jednotlivých fáz. Najjednoduchšie znázornenie životného cyklu zahŕňa fázy:

Dizajn

Implementácia

Testovanie a ladenie

Implementácia, prevádzka a údržba.

Najjednoduchšie znázornenie životného cyklu programu (kaskádový technologický prístup k riadeniu životného cyklu):

Procesy

Dizajn

Programovanie

Testovanie

eskortovať

Analýza Návrh Implementácia Testovanie Implementácia Operácia

a ladenie a údržba

V skutočnosti v každej fáze beží len jeden proces. Je zrejmé, že pri vývoji a vytváraní veľkých programov nie je takáto schéma dostatočne správna (neaplikovateľná), ale možno ju brať ako základ.

Štádium analýzy sa zameriava na systémové požiadavky. Požiadavky sú definované a špecifikované (popísané). Prebieha vývoj a integrácia funkčných modelov a dátových modelov pre systém. Okrem toho sú opravené nefunkčné a iné systémové požiadavky.

Fáza návrhu je rozdelená do dvoch hlavných čiastkových fáz: architektonický a detailný návrh. Prepracovaný je najmä dizajn programu, používateľské rozhranie a dátové štruktúry. Problémy s návrhom, ktoré ovplyvňujú zrozumiteľnosť, udržiavateľnosť a škálovateľnosť systému, sú uvedené a opravené.

Fáza implementácie zahŕňa napísanie programu.

Rozdiely v hardvéri a softvéri sú viditeľné najmä v štádiu vykorisťovanie. Ak spotrebný tovar prechádza fázami spustenia, rastu, zrelosti a poklesu, potom sa život softvéru podobá skôr príbehu nedokončenej, ale neustále dokončovanej a aktualizovanej budovy (lietadla) (Predplatiteľ).

Životný cyklus softvéru je regulovaný mnohými štandardmi, vrátane medzinárodných.

Účel štandardizácie životného cyklu komplexných PS:

Zhrnutie skúseností a výsledkov výskumu mnohých odborníkov;

Vývoj technologických procesov a vývojových techník, ako aj metodický základ pre ich automatizáciu.

Normy zahŕňajú:

Pravidlá pre popis počiatočných informácií, metód a metód vykonávania operácií;

Stanovte pravidlá riadenia procesov;

Stanoviť požiadavky na prezentáciu výsledkov;

Regulovať obsah technologických a prevádzkových dokumentov;

Určiť organizačnú štruktúru vývojového tímu;

Zabezpečiť distribúciu a plánovanie úloh;

Poskytnite kontrolu nad priebehom vytvárania PS.

V Rusku existujú normy upravujúce životný cyklus:

Etapy vývoja softvéru - GOST 19.102-77

Etapy vytvárania AS - GOST 34.601-90;

TK na vytvorenie AS - GOST 34.602-89;

Typy skúšok AS - GOST 34.603-92;

Tvorba, údržba a vývoj aplikačného softvéru pre IP v týchto štandardoch však nie sú dostatočne reflektované a niektoré ich ustanovenia sú zastarané z pohľadu budovania moderných distribuovaných systémov kvalitných aplikačných programov v systémoch riadenia a spracovania dát s. rôzne architektúry.

V tejto súvislosti si treba uvedomiť medzinárodnú normu ISO/IEC 12207-1999 – „Informačné technológie – Procesy životného cyklu softvéru“.

ISO - Medzinárodná organizácia pre normalizáciu - Medzinárodná organizácia pre normalizáciu, IEC - International Electrotechnical Commission - International Electrotechnical Commission.

Definuje štruktúru životného cyklu softvéru a jeho procesov.

Tie. vytváranie softvéru nie je taká jednoduchá úloha, preto existujú štandardy, v ktorých je všetko napísané: čo je potrebné urobiť, kedy a ako.

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

1) hlavné procesy životného cyklu softvéru (akvizícia, dodávka, vývoj, prevádzka, údržba). My sa zameriame na to posledné.

2) pomocné procesy, ktoré zabezpečujú implementáciu hlavných procesov ( dokumentáciu, konfiguračný manažment, zabezpečenie kvality, verifikácia, validácia, kolaboratívna kontrola (hodnotenie), audit, riešenie problémov).

1. Správa konfigurácieToto proces, ktorý podporuje hlavné procesy životného cyklu softvéru, predovšetkým procesy vývoja a údržby. Pri vývoji zložitých softvérových projektov zložených z mnohých komponentov, z ktorých každý môže mať variácie alebo verzie, vzniká problém zohľadniť ich vzťahy a funkcie, vytvoriť jednotnú (t. j. jednotnú) štruktúru a zabezpečiť rozvoj celého systému. Konfiguračný manažment umožňuje organizovať, systematicky zohľadňovať a kontrolovať zmeny rôznych softvérových komponentov vo všetkých fázach jeho životného cyklu.

2. Overenie je proces zisťovania, či Aktuálny stav softvér dosiahnutý na tejto fáze požiadavky tejto etapy.

3. Certifikácia– potvrdenie preskúmaním a predložením objektívnych dôkazov, že špecifické požiadavky na konkrétne objekty sú plne implementované.

4. Spoločná analýza (hodnotenie) – systematické určovanie stupňa zhody objektu so stanovenými kritériami.

5. Audit– overenie vykonané príslušným orgánom (osobou) s cieľom zabezpečiť nezávislé hodnotenie mieru, do akej softvérové ​​produkty alebo procesy vyhovujú špecifikovaným požiadavkám. Vyšetrenie umožňuje vyhodnotiť súlad parametrov vývoja s počiatočnými požiadavkami. Overovanie sa prekrýva s testovaním, ktoré sa vykonáva s cieľom určiť rozdiely medzi skutočnými a očakávanými výsledkami a posúdiť, či vlastnosti softvéru spĺňajú pôvodné požiadavky. V procese implementácie projektu zaujíma dôležité miesto otázky identifikácie, popisu a kontroly konfigurácie jednotlivých komponentov a celého systému ako celku.

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

Projektový manažment spojené s problematikou plánovania a organizácie práce, vytvárania tímov vývojárov a sledovania načasovania a kvality vykonávaných prác. Technicko-organizačné zabezpečenie projektu zahŕňa výber metód a nástrojov na realizáciu projektu, definovanie metód popisu medzistavov vývoja, vývoj metód a nástrojov na testovanie vytvoreného softvéru, školenia personálu a pod. . Zabezpečenie kvality projektu súvisí s problémami overovania, overovania a testovania softvérových komponentov.

Životný cyklus softvéru zvážime z pohľadu vývojára.

Proces vývoja v súlade s normou zabezpečuje úkony a úlohy vykonávané vývojárom a zahŕňa tvorbu softvéru a jeho komponentov v súlade so stanovenými požiadavkami, vrátane prípravy projektovej a prevádzkovej dokumentácie, ako aj prípravy materiály potrebné na kontrolu prevádzkyschopnosti a zhody kvality softvérových produktov, materiály potrebné na školenie personálu a pod.

Životný cyklus softvéru IP podľa normy zahŕňa nasledujúce kroky:

1) vznik a štúdium myšlienky (konceptu);

2) prípravná fáza - výber modelu životného cyklu, noriem, metód a nástrojov rozvoja, ako aj vypracovanie plánu práce.

3) analýza požiadaviek na informačný systém - jeho definovanie

funkčnosť, požiadavky používateľov, požiadavky na spoľahlivosť a bezpečnosť, požiadavky na externé rozhrania a pod.

4) návrh architektúry informačného systému - stanovenie zloženia potrebné vybavenie, softvér a operácie vykonávané servisným personálom.

5) analýza požiadaviek na softvér- definícia funkčnosti vrátane výkonnostných charakteristík, prevádzkového prostredia komponentov, externých rozhraní, špecifikácií spoľahlivosti a bezpečnosti, ergonomických požiadaviek, požiadaviek na využitie dát, inštalácie, akceptácie, užívateľskej dokumentácie, prevádzky a údržby.

6) návrh softvérovej architektúry - definovanie štruktúry softvéru, zdokumentovanie rozhraní jeho komponentov, vypracovanie predbežnej verzie používateľskej dokumentácie, ako aj požiadavky na testovanie a plán integrácie.

7) podrobný návrh softvéru - podrobne

popis softvérových komponentov a rozhraní medzi nimi, aktualizácia užívateľskej dokumentácie, vypracovanie a dokumentovanie testovacích požiadaviek a plánu testovania, softvérových komponentov, aktualizácia plánu integrácie komponentov.

8) softvérové ​​kódovanie -– vývoj a dokumentácia

každý softvérový komponent;

9)testovanie softvéru – vývoj súboru testovacích postupov a údajov na ich testovanie, testovanie komponentov, aktualizácia užívateľskej dokumentácie, aktualizácia plánu integrácie softvéru;

10) softvérová integrácia–montáž softvérových komponentov v súlade s

integračný plán a testovanie softvéru na zhodu kvalifikačné požiadavky, čo je súbor kritérií alebo podmienok, ktoré musia byť splnené, aby sa softvérový produkt kvalifikoval ako vyhovujúci svojim špecifikáciám a pripravený na použitie v daných prevádzkových podmienkach;

11) testovanie kvalifikácie softvéru – testovanie softvéru v

prítomnosť zákazníka na preukázanie jeho dodržiavania

požiadavky a pripravenosť na prevádzku; zároveň sa kontroluje aj pripravenosť a úplnosť technickej a užívateľskej dokumentácie;

12) integrácia systému – montáž všetkých komponentov informačného systému vrátane softvéru a hardvéru;

13) IP kvalifikačné testovanie – testovanie systému pre

splnenie požiadaviek na ňu a overenie návrhu a úplnosti dokumentácie;

14) inštalácia softvéru – inštalácia softvéru na zariadení zákazníka a kontrola jeho výkonu;;

15) akceptácia softvéru – vyhodnotenie výsledkov kvalifik

testovanie softvéru a informačných systémov vo všeobecnosti a

dokumentácia výsledkov hodnotenia spolu so zákazníkom, certifikácia a finálny prevod softvéru zákazníkovi.

16) Správa a vývoj dokumentácie;

17) prevádzka

18) eskort - proces vytvárania a implementácie nových verzií

softvérový produkt.;

19) dokončenie prevádzky.

Tieto akcie možno zoskupiť, podmienečne zdôrazňujúce tieto hlavné fázy vývoja softvéru:

vyhlásenie o úlohe (TOR) (podľa GOST 19.102-77 etapa "Referenčné podmienky")