Životný cyklus softvéru: koncepcia, štandardy, procesy. Životný cyklus softvéru. Etapy a etapy životného cyklu projektu vývoja softvéru

Životný cyklus softvér(Softvér) - č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. Tento cyklus je procesom budovania a vývoja softvéru.

Etapy životného cyklu:

2. Dizajn

3. Implementácia

4. Montáž, skúšanie, skúšanie

5. Implementácia (vydanie)

6. Doprovod

Existujú 2 prípady výroby softvéru: 1) Softvér je vyrobený pre konkrétneho zákazníka. V tomto prípade musíte aplikovanú úlohu zmeniť na programátorskú. Musíte pochopiť, ako funguje prostredie, ktoré je potrebné automatizovať (analýza obchodných procesov). V dôsledku toho sa objaví dokumentačná špecifikácia požiadavky, kde presne musia byť uvedené úlohy. vyriešené a za akých podmienok. Túto prácu vykonáva systémový analytik (analytik obchodných procesov).

2) Softvér je vyvinutý pre trh. Je potrebné vykonať marketingový výskum a zistite, ktorý produkt nie je na trhu. S tým je spojené veľké riziko. Cieľom je vyvinúť špecifikáciu požiadaviek.

Dizajn

Účel – definícia celková štruktúra(architektúrny) softvér. Výsledkom je špecifikácia softvéru. Túto prácu vykonáva systémový programátor.

Implementácia

Zápis programového kódu. Implementácia zahŕňa vývoj, testovanie a dokumentáciu.

Montáž, skúšanie, skúšanie

Zostavenie všetkého, čo urobili rôzni programátori. Testovanie celého softvérového balíka. Ladenie – hľadanie a odstraňovanie príčin chýb. Test – spresnenie technické vlastnosti... Výsledkom je, že program bude zaručene fungovať.

Implementácia (vydanie)

Realizácia – keď pracujú pre jedného zákazníka. Zahŕňa nastavenie programu u zákazníka, zaškolenie zákazníka, poradenstvo, odstraňovanie chýb a zjavných nedostatkov. Softvér by mal byť odcudzený - používateľ môže pracovať so softvérom bez účasti autora.

Release – keď je softvér vyvinutý pre trh. Začína sa fázou beta testovania. Zodpovedajúce verzia - beta verzia. Alfa testovanie je testovanie ľuďmi z rovnakej organizácie, ktorí neboli zapojení do vývoja programov. Beta testovanie – vytvorenie niekoľkých kópií softvéru a jeho odoslanie potenciálnym zákazníkom. Cieľom je dvakrát skontrolovať vývoj softvéru.

Ak sa na trh dostane zásadne nový softvér, je možné vykonať niekoľko beta testov. Po beta testovaní - uvoľnenie komerčnej verzie.

eskortovať

Odstránenie chýb zaznamenaných počas prevádzky. Vykonávanie menších vylepšení. Hromadenie návrhov na vývoj ďalšej verzie.

Modely životného cyklu

1. Vodopád ("vodopád", kaskádový model)

2. Prototypovanie

Po prvé, nevyvíja sa samotný softvérový produkt, ale jeho prototyp, ktorý obsahuje riešenie hlavných problémov, ktorým vývojári čelia. Po úspešnom ukončení vývoja prototypu sa podľa rovnakých princípov vyvíja skutočný softvérový produkt. Prototyp umožňuje lepšie pochopiť požiadavky na vyvíjaný program. Pomocou prototypu môže zákazník aj presnejšie formulovať svoje požiadavky. Vývojár má možnosť prezentovať predbežné výsledky svojej práce zákazníkovi pomocou prototypu.

3. Iteračný model

Úloha je rozdelená na čiastkové úlohy a je určené poradie ich realizácie tak, aby každá ďalšia čiastková úloha rozširovala možnosti softvéru. Úspech v podstate závisí od toho, ako dobre sú úlohy rozdelené do podúloh a ako je zvolené poradie. Výhody: 1) možnosť aktívnej účasti zákazníka na vývoji, má možnosť ujasniť si svoje požiadavky už pri vývoji; 2) schopnosť testovať novo vyvinuté časti spolu s predtým vyvinutými časťami, čo zníži náklady na komplexné ladenie; 3) počas vývoja môžete začať s implementáciou po častiach.

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. Kódovanie algoritmov.

1.1.4. Údržba programu.

1.1.5. Softvérová dokumentácia.

Záver k bodu 1.1

1.2. Definícia výroby životného cyklu podľa Lehmana.

Úvod.

1.2.1 Definícia systému.

1.2.2. Implementácia.

1.2.3. servis.

Záver k článku 1.2.

1.3. Fázy a práca ZHCPO podľa Boehma

1.3.1. Model vodopádu.

1.3.2. Ekonomické opodstatnenie kaskádový model.

1.3.3. Vylepšenie modelu vodopádu.

1.3.4. Stanovenie 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 softvéri stanovili naliehavé úlohy výrazného nárastu produktivita vývoja softvéru, rozvoj priemyselných metód plánovania a navrhovania programov, prenos organizačných a 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 používania počítačov. Komplexný prístup do procesov vývoja, prevádzky a údržby softvéru prinieslo 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 práce, zlepší sa výber a prispôsobenie existujúcich programov. programy a možno aj určiť osud systémov so zabudovanými počítačmi.

V praxi vývoja veľkých softvérových projektov často neexistuje jednotný prístup na posúdenie mzdových nákladov, načasovania prác a materiálové náklady, čo bráni zvýšeniu produktivity vývoja softvéru a v konečnom dôsledku - efektívne riadenieživotný cyklus softvéru. Keďže program akéhokoľvek typu sa stáva produktom (možno okrem vzdelávacích, modelový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 navrhovania programov sa stávajú mimoriadne dôležitými. . Táto myšlienka je podstatou B.W. Boehmovo „Softvérové inžinierstvo“, ktoré sme použili pri písaní 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

Program životného cyklu je nepretržitý proces, ktorý sa začína od okamihu prijatia rozhodnutia o potrebe vytvorenia softvéru a končí okamihom jeho úplného vyradenia z prevádzky.

Existuje niekoľko prístupov k definovaniu fáz a činností životného cyklu softvéru (LCP), krokov procesu programovania, 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.

Asi najznámejšia a najkompletnejšia je štruktúra centra životného cyklu podľa Boehma, ktorá zahŕňa osem fáz. V budúcnosti bude predstavená podrobnejšie.

Jednou z možných možností je popis hornej úrovne podľa Lehmanna, ktorý zahŕňa tri hlavné fázy a predstavuje popis životného cyklu života v najvšeobecnejšom prípade.

A pre zmenu - uvádzame kroky procesu programovania prezentované D. Rileym v knihe "Using the Module-2 language". Táto myšlienka je podľa mňa veľmi jednoduchá a známa a začneme ňou.

1.1 Kroky v procese 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);

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

údržba programu, t.j. prebiehajúci proces odstraňovania problémov 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 prenáša algoritmista kto je zodpovedný za návrh riešenia. Riešenie (alebo algoritmus) predstavuje postupnosť operácií, ktorých vykonanie vedie k riešeniu problému. Keďže algoritmus často nie je prispôsobený na spustenie na stroji, musí byť preložený do strojového programu. Túto operáciu vykonáva kódovač. Správca je zodpovedný za následné zmeny v programe. programátor. Systémový analytik, algoritmista, kódovač a sprievodný programátor sú programátormi.

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í. To všetko prispieva k argumentu pre starostlivý návrh softvéru: výsledky každého kroku musia byť úplné, presné a zrozumiteľné.

1.1.1 Vyhlásenie o probléme

Jedným z najdôležitejších krokov v programovaní je vyhlásenie o probléme. Slúži ako zmluva medzi používateľom a programátorom (programátormi). Rovnako ako právne zle napísaná zmluva, zlé vyhlásenie o probléme je zbytočné. Pri dobrej formulácii úlohy užívateľ aj programátor jasne a jednoznačne predstavujú úlohu, ktorú je potrebné 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á formulácia 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 keby to bola čierna skrinka: nezáleží mu na tom, ako počítač funguje, ale dôležité je, čo počítač dokáže, čo používateľa zaujíma. V tomto prípade je hlavný dôraz kladený na interakciu človeka so strojom.

Charakteristika dobrého vyhlásenia o úlohe:

Presnosť, t.j. odstránenie akýchkoľvek nejasností. 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 neúmyselného vstupu, a určenie vhodného výstupu.

Jasnosť, t.j. malo by to byť jasné tak používateľovi, ako aj systémovému analytikovi, keďž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ú napríklad ťažko zrozumiteľné, pretože sú napísané formálnym jazykom, ktorý umožňuje čo najpresnejšiu formuláciu určitých ustanovení, s vylúčením akýchkoľvek menších nezrovnalostí. Napríklad niektoré otázky na lístkoch na skúšku sú niekedy také presné, ž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šia formulácia problému je taká, pri ktorej sa dosiahne rovnováha všetkých troch požiadaviek.

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

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

Táto formulácia nespĺňa vyššie uvedené požiadavky: nie je ani 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í“ poradie od najvyššieho po najnižšie, od najnižšieho po najvyššie alebo rovnaké poradie, v akom boli zavedené?

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

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

všeobecný popis(zhrnutie problému);

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

príklad ( dobrý príklad môže vyjadriť podstatu problému a tiež ilustrovať rôzne prípady).

Príklad. Vyhlásenie problému v štandardnej forme.

TITLE

Triedenie troch celých čísel.

POPIS

Vstupné a výstupné tri celé čísla zoradené od najnižšieho po najvyššie.

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

Zobrazia sa tri zadané celé čísla, pričom všetky tri sa zobrazia na rovnakom riadku. Susedné čísla oddeľte medzerou. Čísla sa zobrazujú od najnižšieho po najvyššie, zľava doprava.

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

2) Iné vstupné riadky ako prvé tri sa ignorujú.

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

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. Kódovanie algoritmov.

1.1.4. Údržba programu.

1.1.5. Softvérová dokumentácia.

Záver k bodu 1.1

1.2. Definícia výroby životného cyklu podľa Lehmana.

Úvod.

1.2.1 Definícia systému.

1.2.2. Implementácia.

1.2.3. servis.

Záver k článku 1.2.

1.3. Fázy a práca ZHCPO podľa Boehma

1.3.1. Model vodopádu.

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

1.3.3. Vylepšenie modelu vodopádu.

1.3.4. Stanovenie fáz životného cyklu.

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

Literatúra.

Úvod

V praxi vývoja veľkých softvérových projektov často neexistuje jednotný prístup k odhadu mzdových nákladov, načasovania prác a materiálových nákladov, čo bráni zvyšovaniu produktivity vývoja softvéru a v konečnom dôsledku - efektívnemu riadeniu životného cyklu softvéru. Keďže program akéhokoľvek typu sa stáva produktom (možno okrem vzdelávacích, modelový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 navrhovania programov sa stávajú mimoriadne dôležitými. . Táto myšlienka je podstatou B.W. Boehmov „Software Engineering“, ktorý sme použili pri písaní tejto semestrálnej práce. V tejto knihe sa softvérový dizajn vzťahuje na proces vytvárania dizajnu softvérového produktu.

1 Životný cyklus softvéru

ÚVOD

Program životného cyklu je nepretržitý proces, ktorý sa začína od okamihu prijatia rozhodnutia o potrebe vytvorenia softvéru a končí okamihom jeho úplného vyradenia z prevádzky.

Asi najznámejšia a najkompletnejšia je štruktúra centra životného cyklu podľa Boehma, ktorá zahŕňa osem fáz. V budúcnosti bude predstavená podrobnejšie.

Jednou z možných možností je popis hornej úrovne podľa Lehmanna, ktorý zahŕňa tri hlavné fázy a predstavuje popis životného cyklu života v najvšeobecnejšom prípade.

A pre zmenu - uvádzame kroky procesu programovania prezentované D. Rileym v knihe "Using the Module-2 language". Táto myšlienka je podľa mňa veľmi jednoduchá a známa a začneme ňou.

1.1 Kroky v procese programovania Riley

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);

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

údržbu programu, t.j. prebiehajúci proces odstraňovania problémov 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 prenáša algoritmista kto je zodpovedný za návrh riešenia. Riešenie (alebo algoritmus) predstavuje postupnosť operácií, ktorých vykonanie vedie k riešeniu problému. Keďže algoritmus často nie je prispôsobený na spustenie na stroji, musí byť preložený do strojového programu. Túto operáciu vykonáva kódovač. Správca je zodpovedný za následné zmeny programu. Systémový analytik, algoritmista, kódovač a sprievodný programátor sú programátormi.

1.1.1 Vyhlásenie o probléme

Jedným z najdôležitejších krokov v programovaní je vyhlásenie o probléme. Slúži ako zmluva medzi používateľom a programátorom (programátormi). Rovnako ako právne zle napísaná zmluva, zlé vyhlásenie o probléme je zbytočné. Pri dobrej formulácii úlohy užívateľ aj programátor jasne a jednoznačne predstavujú úlohu, ktorú je potrebné vykonať, t.j. v tomto prípade sa berú do úvahy záujmy uží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á formulácia problému slúži ako základ pre formovanie jeho riešenia.

Charakteristiky dobrej úlohy:

Presnosť, t.j. odstránenie akýchkoľvek nejasností. 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 neúmyselného vstupu, a určenie vhodného výstupu.

Jasnosť, t.j. malo by to byť jasné tak používateľovi, ako aj systémovému analytikovi, keďž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ú napríklad ťažko zrozumiteľné, pretože sú napísané formálnym jazykom, ktorý umožňuje čo najpresnejšiu formuláciu určitých ustanovení, s vylúčením akýchkoľvek menších nezrovnalostí. Napríklad niektoré otázky na lístkoch na skúšku sú niekedy také presné, že študent trávi viac času porozumením otázky, než jej zodpovedaním. Študent navyše nemusí vôbec pochopiť hlavný význam otázky kvôli veľkému množstvu detailov. Najlepšia formulácia problému je taká, pri ktorej sa dosiahne rovnováha všetkých troch požiadaviek.

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

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

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

všeobecný popis (stručné vyjadrenie problému);

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

príklad (dobrý príklad môže vyjadriť podstatu problému a tiež ilustrovať rôzne prípady).

Príklad. Vyhlásenie problému v štandardnej forme.

TITLE

Triedenie troch celých čísel.

POPIS

Vstupné a výstupné tri celé čísla zoradené od najnižšieho po najvyššie.

Zobrazia sa tri zadané celé čísla, pričom všetky tri sa zobrazia na rovnakom riadku. Susedné čísla oddeľte medzerou. Čísla sa zobrazujú od najnižšieho po najvyššie, zľava doprava.

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

Téma: Klasické a flexibilné modely životného cyklu: definícia, popis, charakteristické rysy, postupnosť etáp. Metódy výberu modelu životného cyklu pri vývoji softvéru v rôznych tematických oblastiach.

Informačný zdroj https://www.intuit.ru/studies/courses/3632/874/print_lecture/14297

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

Model životného cyklu je chápaný ako štruktúra, ktorá určuje postupnosť vykonávania a vzájomný 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 špecifík podmienok, v ktorých systém vzniká a funguje.

ISO / IEC 12207 neposkytuje špecifický 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ť akcie a úlohy zahrnuté v týchto procesoch.

Model životného cyklu akéhokoľvek konkrétneho softvéru určuje charakter procesu jeho tvorby, ktorý je súborom časovo usporiadaných, vzájomne prepojených a zjednotených v etapách (fázach) práce, ktorých výkon je nevyhnutný a postačujúci na vytvorenie softvéru, ktorý spĺňa stanovené požiadavky.

Etapa (fáza) tvorby softvéru sa chápe ako časť procesu tvorby softvéru, ohraničená určitým časovým rámcom a končiaca vydaním konkrétneho produktu (modely softvéru, softvérové komponenty, dokumentácia a pod.), určená požiadavkami špecifikované pre túto etapu. Etapy vývoja 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:

tvorba softvérových požiadaviek;
dizajn (vývoj projektu systému);
implementácia (možno rozdeliť na čiastkové etapy: podrobný návrh, kódovanie);
testovanie (možno rozdeliť na samostatné a komplexné testovanie a integrácia);
uvedenie do prevádzky (realizácia);
Prevádzka a údržba;
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 veľkej miery (až rozhodujúcej!) určuje úspešnosť celého projektu. Začiatkom tejto etapy je získanie schválenej a overenej architektúry systému so zahrnutím základných dohôd o rozdelení funkcií medzi hardvér a softvér. Tento dokument by mal obsahovať aj potvrdenie všeobecného chápania fungovania softvéru vrátane základných zmlúv o rozdelení funkcií medzi osobu a systém.

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

Plánovanie práce pred prácou na projekte. Hlavnými úlohami etapy sú definovanie rozvojových cieľov, predbežné ekonomické hodnotenie projekt, zostavenie harmonogramu prác, vytvorenie a zaškolenie spoločnej pracovnej skupiny.
Vedenie prieskumu činnosti 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 rozdelenia 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 vzťahu k organizácii objektov a vonkajšie informačné vplyvy, analýza existujúce fondy automatizáciu činností organizácie.

Zostavenie modelu činnosti organizácie (objektu), zabezpečenie spracovania prieskumných materiálov a zostavenie dvoch typov modelov:

model „AS-IS“ („tak ako je“), ktorý odráža aktuálny stav v organizácii v čase prieskumu a umožňuje pochopiť, ako organizácia funguje, ako aj identifikovať úzke miesta a formulovať návrhy na zlepšenie situácia;
model "TO-BE" ("ako by to malo byť"), odrážajúci myšlienku nových technológií 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 skonštruované modely majú nezávislé praktický význam, 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šovanie 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 bola potvrdená ich úplnosť, testovateľnosť a realizovateľnosť.

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

Vývoj projektu softvérového systému. V tejto fáze je odpoveď na otázku „Čo by mal robiť budúci systém?“ vývoj, plán ladenia softvéru a kontrola kvality.

Návrh systému je založený na modeloch návrhu systému, ktoré sú založené na modeli „TO-BE“. Výsledkom vývoja 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 bola potvrdená ich úplnosť, testovateľnosť a realizovateľnosť.
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. Dostáva sa teda 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, intermodulárne rozhrania pre dáta a riadenie;
špecifikácia každého softvérového komponentu, názov, účel, predpoklady, veľkosti, postupnosť volaní, vstupné a výstupné dáta, chybné výstupy, algoritmy a logické obvody;
formovanie fyzických a logické štruktúryúdaje na ú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 fázy podrobného návrhu je komplexná kontrola projektu alebo analýza kritických blokov projektu.

Štádiom realizácie je realizácia nasledujúcich prác.

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

Externé špecifikácie by mali obsahovať nasledujúce informácie:
- názov modulu – označuje názov, ktorý sa používa 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 (správanie modulu musí byť definované za akýchkoľvek vstupných podmienok);
- vonkajšie efekty (vytlačenie správy, prečítanie požiadavky z terminálu a pod.).
Navrhovanie logiky modulov a programovanie (kódovanie) modulov.
Kontrola správnosti modulov.
Testovacie moduly.
Popis databázy až po úroveň jednotlivých parametrov, symbolov a bitov.
Plán akceptačných skúšok.
Používateľská príručka.
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 so životným cyklom softvéru je znázornený na obrázku.

Ryža. 1.

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á aj iné meno - 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áhrady za prekonané fázy sa neposkytujú.

Ryža. 2.

Požiadavky na vyvinutý softvérový systém, stanovené vo fázach tvorby a analýzy, sú prísne zdokumentované vo forme technických špecifikácií a sú stanovené na celé obdobie 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ť implementácie špecifikácií TK. Hlavná pozornosť vývojárov je zameraná na dosiahnutie optimálnych hodnôt technických charakteristík vyvíjaného softvérového systému - výkon, množstvo obsadenej pamäte atď.

Výhody kaskádový model:

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úce náklady.

Vodopádový prístup sa osvedčil pri budovaní softvérového systému, na ktorý je možné už na začiatku projektu úplne a jasne formulovať všetky požiadavky. Pokiaľ toto všetko kontrolujú normy a rôzne akceptačné komisie štátu, schéma funguje dobre.

nevýhody kaskádový model:

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ýlky 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 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ť projekt 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é opravy budú vykonané po dokončení akejkoľvek vývojovej fázy. 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.

Ryža. 3.

V iteratívnom modeli môžu byť nedostatky v dizajne a programovaní napravené neskôr čiastočným návratom do predchádzajúcej fázy. Čím nižšia je miera detekcie chyby, tým drahšia je jej oprava. Ak sa náklady na úsilie potrebné na zistenie a odstránenie chýb vo fáze písania kódu vezmú ako celok, potom náklady na identifikáciu a odstránenie chyby vo fáze vývoja požiadaviek budú 5- až 10-krát nižšie a náklady na identifikácia a odstránenie chyby v štádiu údržby bude 20-krát menej.viac.

Ryža. 4.

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 dizajnu sú osobne zodpovední softvéroví architekti. Objem dokumentácie sa pohybuje v tisíckach 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“. Jedným z možných spôsobov, ako sa takýmto situáciám vyhnúť, je prototypovanie (prototypovanie).

Rozloženie

Zákazník často nevie sformulovať požiadavky na vstup, spracovanie alebo výstup dát pre budúci softvérový produkt. Vývojár môže mať pochybnosti 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íkov. Layout (prototypovanie) je proces vytvárania modelu požadovaného produktu.

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

Papierová maketa (ručne nakreslená schéma dialógu človek-stroj) alebo maketa založená na PC.
Pracovné rozloženie, ktoré implementuje niektoré z požadovaných funkcií.
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 medzi zákazníkom a vývojárom.

Ryža. 5.

Postupnosť akcií pre prototypovanie je znázornená na obrázku. 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 definujú ciele softvéru, stanovia, ktoré požiadavky sú známe a ktoré je potrebné ďalej definovať. Potom sa urobí rýchly dizajn. Zameriava sa na vlastnosti, ktoré by mali byť viditeľné pre používateľa. Rýchly dizajn vedie k vytvoreniu rozloženia. Rozloženie vyhodnotí zákazník a slúži na objasnenie softvérových požiadaviek. Iterácie pokračujú, kým rozloženie neidentifikuje všetky požiadavky zákazníka a nedá vývojárovi príležitosť pochopiť, čo je potrebné urobiť.

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

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

Mala by sa objasniť podstata nedostatkov. Keď zákazník uvidí funkčnú verziu PS, prestane si uvedomovať, že v snahe o funkčnú verziu PS zostalo veľa problémov s kvalitou nevyriešených. jednoduchosť údržby systémov. Keď o tom developer povie zákazníkovi, odpoveďou môže byť rozhorčenie a požiadavka čo najrýchlejšej premeny layoutu na fungujúci produkt. To negatívne ovplyvňuje riadenie vývoja softvéru.

Ryža. 6.

Na druhej strane vývojár často robí určité kompromisy, aby rýchlo získal pracovné rozloženie. Napríklad môže byť použitý nesprávny programovací jazyk alebo operačný systém. Pre jednoduchú demonštráciu je možné použiť neefektívny (jednoduchý) algoritmus. Po chvíli vývojár zabudne na dôvody, prečo tieto nástroje nie sú vhodné. Výsledkom je, že do systému je integrovaná ďaleko od ideálnej zvolenej možnosti.

Pred zvážením iných modelov softvéru životného cyklu, ktoré boli nahradené kaskádový model, mali by sme sa zamerať na stratégie dizajnu 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 navrhovania 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 sú určené všetky užívateľské a systémové požiadavky, zvyšok návrhu sa robí ako postupnosť verzií. Prvá verzia implementuje niektoré z plánovaných funkcií, nasledujúca verzia implementuje ďalšie funkcie atď., kým nedostaneme kompletný systém;
evolučnej stratégie. Systém je tiež zostavený v sérii verzií, ale nie všetky požiadavky sú identifikované na začiatku procesu. Požiadavky sa spresňujú v dôsledku vytvárania 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

Inkrementálny model je klasickým príkladom inkrementálnej dizajnovej stratégie. Spája prvky sekvenčného vodopádového modelu s iteračnou filozofiou prototypovania (ktorú navrhol B. Boehm ako vylepšenie kaskádový model). Každá lineárna sekvencia tu generuje dodaný softvérový prírastok. Napríklad softvér na spracovanie slov v 1. prírastku (verzii) implementuje funkcie základného spracovania súborov, editáciu a dokumentáciu; v 2. prírastku - zložitejš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 (hoci mnohé vedľajšie požiadavky zostávajú nesplnené). Ďalší plán prírastkov obsahuje úpravy základného produktu, aby poskytoval ďalšie funkcie a funkcie.

Prírastkový proces je vo svojej podstate iteratívny, ale na rozdiel od prototypovania poskytuje prírastkový model pracovný produkt pri každom prírastku.

Diagram 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).

Ryža. 7.

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

Špirálový model Je klasickým príkladom evolučnej dizajnovej stratégie. Model (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 akcie, reprezentované štyrmi kvadrantmi špirály.

Ryža. osem.

Plánovanie – definovanie cieľov, možností a obmedzení.
Analýza rizika - analýza možností a rozpoznanie/výber rizika.
Inžinierstvo je ďalšou úrovňou vývoja produktu.
Hodnotenie - hodnotenie zákazníka k aktuálnym výsledkom návrhu.

Integračný aspekt špirálový model zrejmé pri uvažovaní o radiálnom rozmere špirály. S každou iteráciou sa viac a viac kompletných verzií PS stavia do špirály. V prvom otočení špirály sa identifikujú počiatočné ciele, možnosti a obmedzenia a rozpozná sa a analyzuje riziko. Ak analýza rizík odhalí nejednoznačnosť požiadaviek, prototypovanie použité v kvadrante dizajnu príde 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žinierske (projektové) práce a robí návrhy na úpravy (kvadrant posudku zákazníka). Ďalšia fáza plánovania a analýzy rizík je založená na podnetoch zákazníka. V každom cykle v špirále sa výsledky analýzy rizík tvoria 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 posúva vývojárov smerom k všeobecnejšiemu modelu systému. Každý špirálový cyklus si vyžaduje návrh (pravý dolný kvadrant), ktorý možno dosiahnuť klasickým životným cyklom alebo prototypovaním. Všimnite si, že počet rozvojových aktivít (prebiehajúcich v pravom dolnom kvadrante) sa zvyšuje, keď sa pohybujete od stredu špirály.

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

- počiatočný zber požiadaviek a plánovanie projektu;
- rovnaká práca, ale na základe odporúčaní zákazníka;
- analýza rizík založená na počiatočných požiadavkách;
- analýza rizík na základe reakcie zákazníka;
- prechod na integrovaný systém;
- počiatočné usporiadanie systému;
- ďalšia úroveň rozloženia;
- navrhnutý systém;
- hodnotenie zákazníkom.

Dôstojnosť špirálový model:

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

nevýhody špirálový model:

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

Špirálový vývojový procesný model je v súčasnosti najrozšírenejší. 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, aby sa spresnili charakteristiky budúceho produktu v každej slučke. 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. Skutočne, ak skôr bolo možné vytvárať a rozpúšťať tímy špecialistov podľa potreby, teraz sa všetci musia neustále podieľať na projekte: architekti, programátori, testeri, inštruktori atď. Okrem toho musia byť snahy rôznych skupín synchronizované, včas odrážať dizajnové riešenia a vykonať potrebné zmeny.

Racionálny jednotný proces

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 začali 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 RUP 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 podporovaná a vyvinutá spoločnosťou Rational Software. Vo všeobecnej znalostnej báze sa ako modelovací jazyk používa 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, a 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 súbor cieľov pre iteráciu sa musí presne zhodovať so súborom 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 je jednoznačne spojená s konkrétnou verziou softvérového modelu. Každá iterácia 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 často zobrazuje vo forme grafu-tabuľky ..

Tento obrázok predstavuje 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 akcenty v projekte časom menia. Napríklad v skorých iteráciách sa viac času venuje požiadavkám; v neskorších iteráciách sa viac času venuje implementácii. Horizontálna os je tvorená časovými intervalmi - iteráciami, z ktorých každá je samostatným vývojovým cyklom; cieľom cyklu je priniesť určité preddefinované hmatateľné zdokonalenie konečného produktu, ktoré je užitočné z hľadiska zainteresovaných strán.

Ryža. deväť.

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

Inception - vytvorenie konceptu projektu, pochopenie toho, čo tvoríme, vízia produktu (vízia), vypracovanie podnikateľského plánu (business case), príprava prototypu programu alebo čiastkového riešenia. Toto je fáza zberu 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.
Návrh, vývoj (Spracovanie) - objasnenie plánu, pochopenie toho, ako ho tvoríme, navrhovanie, plánovanie potrebných akcií a zdrojov, detailné rozpracovanie 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ákladných architektonických riešení. V poslednej iterácii je to - technický projekt.
Implementácia, tvorba systému (Construction) - etapa rozširovania funkcionality systému, zabudovaného do architektúry. V konečnej iterácii ide o pracovný návrh.
Implementácia, nasadenie (Transition). Vytvorenie finálnej verzie produktu. Fáza implementácie produktu, dodávka produktu konkrétnemu používateľovi (replikácia, dodávka a školenie).

Vertikálnu os tvoria disciplíny, pričom každá z nich môže byť podrobnejšie opísaná z hľadiska vykonávaných úloh, rolí, ktoré sú za ne zodpovedné, produktov, ktoré sú zadávané úlohám ako vstup a ktoré sa uvoľňujú 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).

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 nej, optimalizovať obchodné procesy a rozhodovať o ich čiastočnej alebo úplnej automatizácii.
Riadenie požiadaviek je o získavaní informácií od zainteresovaných strán a ich premene 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ť.
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ť.
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.
Testovanie (Test) sa venuje posudzovaniu kvality vytváraného produktu.
Nasadenie zahŕňa operácie, ktoré sa uskutočňujú, keď sa produkty prenášajú zákazníkom a keď je produkt sprístupnený koncovým používateľom.
Správa konfigurácie je o synchronizácii middlewaru a koncových produktov a riadení ich vývoja počas projektu a hľadaní skrytých problémov.
Projektový manažment (Management) sa venuje projektovému plánovaniu, riadeniu rizík, sledovaniu jeho priebehu a priebežnému vyhodnocovaniu kľúčových ukazovateľov.
Environmentálny manažment (Environment) zahŕňa prvky tvorby prostredia rozvoja informačného systému a podporu projektových aktivít.

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

Neoddeliteľnú súčasť RUP tvoria artefakty, precedensy a roly. Artefakty sú niektoré z produktov projektu, ktoré sa 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, súbor kódu, testovací skript, popis chyby atď. Za vytvorenie sú zodpovední určití špecialisti. toho či onoho druhu artefaktov. 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 je v RUP považovaný za proces vytvárania artefaktov – od prvotných analytických dokumentov až po spustiteľné moduly, uží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 simulátor 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 – produkt na riadenie zmien a sledovanie defektov v projekte (sledovanie chýb), úzko integrovaný s nástrojmi na testovanie a správu požiadaviek a poskytujúci 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 nastaviť firemný štandard pre interné dokumenty. Je tiež možné priniesť dokumentáciu k existujúcim normám (ISO, CMM);
Rational Purify, Rational Quantify Rational PureCoverage - nástroje na testovanie a ladenie;
Rational Visual Quantify je nástroj na meranie výkonu pre vývojárov aplikácií a komponentov, ktorí programujú v C/C++, Visual Basic a Java; pomáha identifikovať a odstraňovať úzke miesta vo výkone softvéru;
Rational Visual PureCoverage – Automaticky identifikuje oblasti kódu, ktoré sa netestujú.
Rational ClearCase je produkt na správu konfigurácie softvéru (SCM), ktorý umožňuje kontrolu verzií všetkých projektových dokumentov. Umožňuje vám udržiavať viacero verzií projektov súčasne a rýchlo medzi nimi prepínať. Rational Requisite Pro podporuje aktualizácie a sleduje zmeny v požiadavkách pre vývojový tím;
SQA TeamTest – nástroj 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ému.

Táto sada produktov sa neustále zdokonaľuje a dopĺňa. 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éru. 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 integruje funkcie 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 UML 2.0 a umožňuje 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ť požadované 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áciu

Rational Software Architect navyše podporuje technológiu vývoja riadeného modelom (MDD), ktorá umožňuje modelovanie softvéru rôzne úrovne abstrakcie s sledovateľnosťou.

MSF (Microsoft Solution Framework)

V roku 1994, v snahe maximalizovať dopad IT projektov, Microsoft vydal súbor smerníc pre efektívny návrh, vývoj, implementáciu a údržbu riešení postavených na základe jeho technológií. Tieto poznatky vychádzajú zo skúseností, ktoré spoločnosť Microsoft získala pri práci na veľkých projektoch vývoja a údržby softvéru, zo skúseností konzultantov spoločnosti Microsoft a z toho najlepšieho, čo IT priemysel doteraz nazbieral. 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 na aplikované a špecializované použitie. Okrem toho spoločnosť Microsoft certifikuje odborníkov špecificky na aplikované znalosti pri aplikácii MSF (napríklad certifikácia MCTS 74-131 pre odbornosť v technikách projektového riadenia). Predtým, ako sa naučíte techniky Lekárov bez hraníc, mali by ste najprv určiť, na ktorú aplikáciu Lekárov bez hraníc máte odkaz.

Najpopulárnejšie aplikácie Lekárov bez hraníc vyvinuté spoločnosťou Microsoft sú:

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

Dôležitosť aplikácií MSF podčiarkuje fakt, že Microsoft vo svojich IT projektoch nepoužíva samotnú metodiku MSF v „čistej verzii“. Projekty Microsoft Consulting Services využívajú hybridnú metodiku MSF a Agile. Napriek vonkajším významným rozdielom v aplikovaných verziách MSF, ktoré vyvinuli experti spoločnosti Microsoft, základ metód MSF pre nich zostáva spoločný a odráža všeobecné metodologické prístupy k riadeniu iteračných projektov.

Cieľom MOF je poskytnúť organizáciám, ktoré budujú kritické IT riešenia založené na produktoch a technológiách spoločnosti Microsoft, technické poradenstvo, ako dosiahnuť ich spoľahlivosť, dostupnosť, jednoduchosť údržby(podporovateľnosť) a ovládateľnosť (manažovateľnosť). MF rieši otázky súvisiace s organizáciou ľudí a procesov; technológie a riadenie v komplexných, distribuovaných a heterogénnych IT prostrediach. MOF je založené na najlepších výrobných postupoch zostavených v knižnici IT infraštruktúry (ITIL) zostavenej Centrálnou počítačovou a telekomunikačnou agentúrou – vládnou agentúrou Spojeného kráľovstva.

Vybudovanie podnikového riešenia v rámci prideleného času a rozpočtu si vyžaduje overený metodický rámec. Lekári bez hraníc ponúkajú 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 absencii prísnych predpisov sú Lekári bez hraníc schopní uspokojiť potreby organizácie alebo projektového tímu akejkoľvek veľkosti. Metodológia Lekárov bez hraníc pozostáva z princípov, modelov a disciplín pre riadenie ľudí, procesov, technologických prvkov a súvisiacich problémov, ktoré sú spoločné pre väčšinu projektov. Lekári bez hraníc pozostávajú z dvoch modelov a troch disciplín. Tieto 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 riadenia, disciplína riadenia rizík, disciplína riadenia tréningov).

Procesný model Lekárov bez hraníc poskytuje všeobecnú metodológiu pre vývoj a implementáciu IT riešení. Zvláštnosťou tohto modelu je, že vďaka svojej flexibilite a absencii prísne 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: vodopád a špirála. Procesný model v MSF 3.0 bol doplnený o jeden inovatívny aspekt: pokrýva celý životný cyklus riešenia, od jeho počiatočného bodu až po samotnú implementáciu. Tento prístup pomáha dizajnérskym tímom zamerať sa na obchodnú hodnotu riešenia, pretože táto návratnosť sa stáva reálnou až po nasadení 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 implikuje odpovede na otázky: „Dospel projektový tím k jednoznačnému pochopeniu cieľov a rozsahu projektu?“, „Je akčný plán dostatočne pripravený?“ Spĺňa riešenie potreby zákazníka?" atď.

Procesný model Lekárov bez hraníc sa prispôsobuje neustálym zmenám v požiadavkách na dizajn. Predpokladá, ž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.

Charakteristiky 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;
nasadenie (Deploying).

Okrem toho existuje veľké množstvo míľnikov, ktoré ukazujú určitý pokrok v projekte a rozkladajú veľké segmenty práce na menšie, viditeľné oblasti. 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 MSF 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 implementáciou základných funkcií. Potom sa do riešenia pridávajú ďalšie a ďalšie funkcie. Táto stratégia sa označuje ako stratégia tvorby verzií. Zatiaľ čo vydanie jednej verzie môže byť postačujúce pre malé projekty, odporúča sa, aby ste si dávali pozor na možnosť vytvorenia viacerých verzií pre jedno riešenie. S vytváraním nových verzií sa vyvíja funkcionalita riešenia.

Iteratívny prístup k vývojovému procesu si vyžaduje flexibilný spôsob udržiavania dokumentácie. Živé dokumenty sa musia 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 Lekárov bez hraníc celý životný cyklus riešenia vrátane jeho implementácie až do bodu, kedy sa riešenie začne vyplácať.

Pojem životného cyklu softvéru (životný cyklus softvéru) je jedným zo základných pojmov v softvérovom inžinierstve. Životný cyklus je definovaný ako časový úsek, ktorý začína okamihom prijatia rozhodnutia o potrebe vytvorenia softvéru a končí okamihom jeho úplného vyradenia z prevádzky.

V súlade s normou ISO / IEC 12207 sú všetky procesy životného cyklu rozdelené do troch skupín (obr. 2.1).

Pod model životného cyklu Softvér je chápaný ako štruktúra, ktorá určuje postupnosť vykonávania a vzťah procesov, akcií a úloh počas celého životného cyklu. Závisí to od špecifík, rozsahu a zložitosti projektu a špecifík podmienok, v ktorých systém vzniká a funguje. Životný cyklus softvéru zvyčajne zahŕňa nasledujúce fázy:

1. Tvorba softvérových požiadaviek.

2. Dizajn.

3. Implementácia.

4. Testovanie.

5. Uvedenie do prevádzky.

6. Prevádzka a údržba.

7. Vyraďovanie z prevádzky.

V súčasnosti sa najčastejšie používajú tieto základné modely životného cyklu softvéru:

a) kaskádové a

b) špirála (evolučná).

Prvý bol použitý pre malé programy, ktoré sú jedným celkom. Hlavná vlastnosť vodopádový prístup spočíva v tom, že prechod do ďalšej etapy sa uskutoční až po úplnom dokončení prác na súčasnej a už nie sú žiadne návraty k prekonaným etapám. Jeho schéma je znázornená na obr. 2.2.

Výhody použitia vodopádového modelu sú nasledovné:

V každej fáze sa vytvorí kompletná projektová dokumentácia;

Fázy vykonaných prác vám umožňujú naplánovať si dátum ich dokončenia a zodpovedajúce náklady.

Tento model sa používa pre systémy, na ktoré je možné na začiatku vývoja presne formulovať všetky požiadavky. Patria sem napríklad systémy, v ktorých sa riešia najmä problémy výpočtového typu. Skutočné procesy majú zvyčajne iteratívny charakter: výsledky ďalšej fázy často spôsobujú zmeny v konštrukčných riešeniach vyvinutých v skorších fázach. Bežnejší model je teda so stredným riadením, ktoré je znázornené na obr. 2.3.

Hlavnou nevýhodou kaskádového prístupu je značné oneskorenie pri získavaní výsledkov a v dôsledku toho pomerne vysoké riziko vytvorenia systému, ktorý nevyhovuje zmeneným potrebám používateľov.

Tieto problémy sú vyriešené v špirálový model životného cyklu (obr. 2.4). Jeho základnou vlastnosťou je, že aplikačný softvér nevzniká okamžite, ako v prípade vodopádového prístupu, ale po častiach metódou prototypovanie ... Prototyp je chápaný ako aktívny softvérový komponent, ktorý implementuje jednotlivé funkcie a externé rozhranie vyvíjaného softvéru. Prototypovanie sa vykonáva v niekoľkých iteráciách - otáčkach špirály.

Vodopádový (evolučný) model je možné znázorniť vo forme diagramu, ktorý je znázornený na obrázku 2.5.

Jedným z výsledkov aplikácie špirálového modelu životného cyklu je široko používaná metóda tzv rýchly vývoj aplikácií , alebo RAD (Rýchly vývoj aplikácií). Podľa tejto metódy zahŕňa životný cyklus softvéru štyri fázy:

1) analýza a plánovanie požiadaviek;

2) dizajn;

3) implementácia;

4) implementácia.

Analýza životného cyklu programov vám umožňuje objasniť obsah a zdôrazniť nasledujúce procesy pre návrh zložitých systémov.

1) Stratégia;

2) analýza;

3) Dizajn;

4) Implementácia;

5) Testovanie;

6) Implementácia;

7) Prevádzka a technická podpora.

Stratégia

Definovanie stratégie zahŕňa preskúmanie systému. Hlavnou úlohou prieskumu je posúdiť skutočný rozsah projektu, jeho ciele a zámery, ako aj získať definície entít a funkcií na vysokej úrovni. V tejto fáze sú zapojení vysokokvalifikovaní obchodní analytici, ktorí majú neustály prístup k manažmentu firmy. Okrem toho sa očakáva úzka interakcia s hlavnými používateľmi systému a obchodnými expertmi. Hlavnou úlohou takejto interakcie je získať čo najúplnejšie informácie o systéme, jednoznačne pochopiť požiadavky zákazníka a odovzdať prijaté informácie vo formalizovanej forme analytikom systému. Informácie o systéme možno zvyčajne získať zo série rozhovorov (alebo seminárov) s vedením, odborníkmi a používateľmi.

Výsledkom fázy definovania stratégie je dokument, v ktorom je jasne formulované:

Čo presne patrí zákazníkovi, ak súhlasí s financovaním projektu;

Kedy bude môcť dostať hotový výrobok (rozvrh práce);

Koľko ho to bude stáť (rozpis etáp financovania veľkých projektov).

Dokument by mal odrážať nielen náklady, ale aj prínosy, napríklad dobu návratnosti projektu, očakávaný ekonomický efekt (ak sa dá odhadnúť).

Uvažovaná fáza životného cyklu softvéru môže byť reprezentovaná v modeli iba raz, najmä ak má model cyklickú štruktúru. To neznamená, že v cyklických modeloch strategické plánovanie vyrobené raz a navždy. V takýchto modeloch sú fázy definovania stratégie a analýzy akoby spojené a ich oddelenie existuje len v prvej fáze, keď vedenie podniku akceptuje principiálne rozhodnutie o začatí projektu. Vo všeobecnosti je strategická etapa venovaná vypracovaniu dokumentu na úrovni podnikového manažmentu.

Fáza analýzy zahŕňa podrobnú štúdiu podnikových procesov (funkcií definovaných v predchádzajúcej fáze) a informácií potrebných na ich implementáciu (subjekty, ich atribúty a vzťahy (vzťahy)). Táto fáza poskytuje informačný model a ďalšou fázou návrhu je dátový model.

Všetky informácie o systéme, zhromaždené vo fáze určovania stratégie, sú formalizované a spresnené vo fáze analýzy. Osobitná pozornosť sa venuje úplnosti prijatých informácií, ich analýze z hľadiska konzistencie, ako aj vyhľadávaniu nepoužitých alebo duplicitných informácií. Zákazník spravidla najskôr vytvára požiadavky nie na systém ako celok, ale na jeho jednotlivé komponenty. A v tomto konkrétnom prípade majú výhodu cyklické modely životného cyklu softvéru, pretože časom si to s najväčšou pravdepodobnosťou vyžiada opätovná analýza, keďže chuť zákazníka často prichádza s jedlom. V tej istej fáze sa určia potrebné zložky plánu skúšok.

Analytici zhromažďujú a zaznamenávajú informácie v dvoch vzájomne súvisiacich formách:

a) funkcie - informácie o udalostiach a procesoch, ktoré sa vyskytujú v podniku;

b) entity - informácie o položkách, ktoré sú pre organizáciu relevantné a o ktorých je niečo známe.

Zároveň sa budujú diagramy komponentov, dátových tokov a životných cyklov, ktoré popisujú dynamiku systému. O nich sa bude diskutovať neskôr.

Dizajn

Vo fáze návrhu sa vytvorí dátový model. Dizajnéri spracovávajú analytické dáta. Konečným produktom fázy návrhu je schéma databázy (ak taká v projekte existuje) alebo schéma dátového skladu (model ER) a súbor špecifikácií systémových modulov (model funkcie).

V malom projekte (napríklad v projekte kurzu) môžu tí istí ľudia pôsobiť ako analytici, dizajnéri a vývojári. Vyššie uvedené schémy a modely pomáhajú nájsť napríklad vôbec nepopísané, vágne popísané, protichodne popísané komponenty systému a iné nedostatky, čo pomáha predchádzať prípadným chybám.

Všetky špecifikácie musia byť veľmi presné. V tejto fáze vývoja sa tiež dokončuje plán testovania systému. V mnohých projektoch sú výsledky projektovej fázy zdokumentované v jedinom dokumente – takzvanej technickej špecifikácii. Zároveň sa rozšírilo používanie jazyka UML, ktorý vám umožňuje súčasne získať analytické dokumenty, ktoré sú menej podrobné (ich spotrebitelia sú manažéri výroby), ako aj dizajnové dokumenty (ich spotrebitelia sú manažéri vývojových a testovacích skupín). O tomto jazyku sa bude diskutovať neskôr. Softvér vytvorený pomocou UML uľahčuje generovanie kódu – prinajmenšom hierarchiu tried, ako aj niektoré časti kódu samotných metód (postupov a funkcií).

Konštrukčné úlohy sú:

Zváženie výsledkov analýzy a overenie ich úplnosti;

Semináre so zákazníkom;

Identifikácia kritických oblastí projektu a posúdenie jeho obmedzení;

Určenie architektúry systému;

Rozhodovanie o používaní produktov tretích strán, ako aj o metódach integrácie a mechanizmoch výmeny informácií s týmito produktmi;

Návrh dátového skladu: databázový model;

Návrh procesu a kódu: konečný výber vývojových nástrojov, definícia programových rozhraní, mapovanie funkcií systému na jeho moduly a definícia špecifikácií modulov;

Stanovenie požiadaviek na proces testovania;

Stanovenie požiadaviek na bezpečnosť systému.

Implementácia

Pri realizácii projektu je obzvlášť dôležitá koordinácia vývojového tímu (tímov). Všetci vývojári musia dodržiavať prísne pokyny na kontrolu zdroja. Po získaní technického projektu začnú písať kód modulu. Hlavnou úlohou vývojárov je porozumieť špecifikácii: dizajnér napísal, čo je potrebné urobiť, a vývojár určuje, ako to urobiť.

Počas fázy vývoja existuje úzka interakcia medzi dizajnérmi, vývojármi a testovacími tímami. V prípade intenzívneho vývoja je tester doslova neoddeliteľný od vývojára, efektívne sa stáva členom vývojového tímu.

Používateľské rozhrania sa najčastejšie menia vo fáze vývoja. Dôvodom je pravidelné predvádzanie modulov zákazníkovi. Dokáže tiež výrazne upraviť dátové dotazy.

Fáza vývoja je spojená s fázou testovania a oba procesy prebiehajú paralelne. Systém sledovania chýb synchronizuje akcie testerov a vývojárov.

Chyby by mali byť klasifikované podľa priority. Pre každú triedu chýb by sa mala definovať jasná štruktúra činností: „čo robiť“, „ako naliehavé“, „kto je zodpovedný za výsledok“. Každý problém by mal sledovať dizajnér / vývojár / tester zodpovedný za jeho opravu. To isté platí pre situácie, keď sú porušené plánované podmienky vývoja a odovzdania modulov na testovanie.

Okrem toho by sa mali organizovať úložiská hotových projektových modulov a knižníc, ktoré sa používajú pri zostavovaní modulov. Toto úložisko sa neustále aktualizuje. Na proces aktualizácie by mala dohliadať jedna osoba. Jedno úložisko je vytvorené pre moduly, ktoré prešli funkčným testovaním, druhé je pre moduly, ktoré prešli testovaním odkazov. Prvým sú návrhy, druhým niečo, z čoho je už možné zostaviť rozvodnú súpravu systému a predviesť ju zákazníkovi na kontrolné skúšky alebo na dodanie akýchkoľvek etáp prác.

Testovanie

Testovacie tímy môžu byť zapojené do spolupráce už na začiatku vývoja projektu. Komplexné testovanie sa zvyčajne vyčleňuje ako samostatná fáza vývoja. V závislosti od zložitosti projektu môže testovanie a oprava chýb trvať tretinu, polovicu celkového času projektu alebo aj viac.

Čím zložitejší je projekt, tým väčšia je potreba automatizovať systém sledovania chýb, ktorý poskytuje nasledujúce funkcie:

Uloženie chybového hlásenia (ktorému komponentu systému chyba patrí, kto ju našiel, ako ju reprodukovať, kto je zodpovedný za jej opravu, kedy ju treba opraviť);

Systém upozornení na výskyt nových chýb, o zmenách stavu chýb známych v systéme (upozornenia e-mailom);

Správy o skutočných chybách systémových komponentov;

Informácie o chybe a jej histórii;

Pravidlá prístupu k chybám určitých kategórií;

Rozhranie obmedzeného prístupu systému na sledovanie chýb pre koncového používateľa.

Takéto systémy preberajú mnoho organizačných problémov, najmä problémy s automatickým upozornením na chyby.

Skutočné systémové testy sú zvyčajne rozdelené do niekoľkých kategórií:

a) offline testy moduly; používajú sa už v štádiu vývoja komponentov systému a umožňujú sledovať chyby jednotlivých komponentov;

b) testy odkazov systémové komponenty; tieto testy sa používajú aj vo fáze vývoja, umožňujú vám sledovať správnu interakciu a výmenu informácií medzi systémovými komponentmi;

c) systémový test; je to hlavné kritérium prijatia systému; Zvyčajne ide o skupinu testov, ktorá zahŕňa samostatné testy aj testy a modely konektivity; takýto test by mal reprodukovať fungovanie všetkých komponentov a funkcií systému; jeho hlavným cieľom je interná akceptácia systému a posúdenie jeho kvality;

d) Akceptačný test; jeho hlavným účelom je odovzdanie systému zákazníkovi;

e) výkonové a záťažové testy; táto skupina testov je zahrnutá v systéme, je to ona, ktorá je hlavná pre hodnotenie spoľahlivosti systému.

Každá skupina nevyhnutne zahŕňa testy na modelovanie porúch. Kontrolujú reakciu komponentu, skupiny komponentov a systému ako celku na nasledujúce poruchy:

Samostatná súčasť informačného systému;

Skupiny komponentov systému;

Hlavné moduly systému;

Operačný systém;

Hard failure (výpadok napájania, pevné disky).

Tieto testy umožňujú posúdiť kvalitu subsystému pre obnovenie správneho stavu informačného systému a slúžia ako hlavný zdroj informácií pre vypracovanie stratégií predchádzania negatívnym následkom porúch počas priemyselnej prevádzky.

Ďalším dôležitým aspektom programu testovania informačných systémov je dostupnosť generátorov testovacích dát. Používajú sa na testovanie funkčnosti, spoľahlivosti a výkonu systému. Bez generátorov dát nie je možné vyriešiť problém posudzovania charakteristík závislosti výkonu informačného systému od rastu objemov spracovávaných informácií.

Implementácia

Skúšobná prevádzka sa prekrýva s testovacím procesom. Systém je zriedka plne implementovaný. Zvyčajne ide o postupný alebo opakovaný proces (v prípade cyklického životného cyklu).

Uvedenie do prevádzky prechádza najmenej tromi fázami:

2) hromadenie informácií;

3) dosiahnutie projektovanej kapacity (to znamená skutočný prechod do prevádzkovej fázy).

informácie môžu spôsobiť pomerne úzky rozsah chýb: najmä nesúlad údajov počas načítavania a vlastné chyby zavádzača. Na ich identifikáciu a elimináciu sa používajú metódy kontroly kvality dát. Takéto chyby sa musia čo najskôr opraviť.

Počas obdobia hromadenie informácií v informačný systém je zistený najväčší počet chýb spojených s viacužívateľským prístupom. Druhá kategória opráv súvisí s tým, že používateľ nie je spokojný s rozhraním. Zároveň cyklické a spätnoväzbové modely etáp môžu znížiť náklady. Táto fáza je zároveň najzávažnejšou skúškou – akceptačnými skúškami zákazníka.

Systém dosahuje svoju konštrukčnú kapacitu v dobrej verzii je to dolaďovanie menších chýb a zriedkavých závažných chýb.

Prevádzka a technická podpora

V tejto fáze je konečným dokumentom pre vývojárov akt technickej akceptácie. Dokument definuje potrebný personál a požadované vybavenie na podporu prevádzkyschopnosti systému, ako aj podmienky pre narušenie prevádzky produktu a zodpovednosti zmluvných strán. Okrem toho sú podmienky technickej podpory zvyčajne vypracované ako samostatný dokument.