Životný cyklus softvéru. Životný cyklus softvérových systémov Definujte koncept životného cyklu softvéru

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

Modely a etapy ž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, činností 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 je systém vytvorený a funguje.

ISO / IEC 12207 neposkytuje 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. Štandard 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 povahu procesu jeho vytvárania, čo je súbor prác usporiadaných v čase, prepojených a zjednotených v etapách (fázach) práce, ktorých implementácia je potrebná a dostačujúca na vytvorenie softvéru. ktorý spĺňa stanovené požiadavky.

Fáza (fáza) vytvárania softvéru sa chápe ako časť procesu vytvárania softvéru, obmedzená určitým časovým rámcom a končiaca vydaním konkrétneho produktu (softvérové ​​modely, softvérové ​​komponenty, dokumentácia atď.), Určená požiadavkami. špecifikované pre túto fázu. Fázy vývoja softvéru sa rozlišujú z dôvodov racionálneho plánovania a organizácie práce a končia stanovenými výsledkami. Životný cyklus softvéru zvyčajne obsahuje nasledujúce fázy:

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

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

Fáza formovania softvérových požiadaviek je jednou z najdôležitejších a do značnej miery (dokonca rozhodujúcej!) Miery určuje úspech celého projektu. Začiatkom tejto fázy je získanie schválenej a overenej architektúry systému so zahrnutím základných dohôd o distribúcii funkcií medzi hardvérom a softvérom. Tento dokument by mal tiež obsahovať potvrdenie všeobecného porozumenia fungovaniu softvéru vrátane základných dohôd o distribúcii funkcií medzi osobou a systémom.

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

1. Plánovanie práce pred prácou na projekte. Hlavnými úlohami etapy sú definícia rozvojových cieľov, predbežná ekonomické hodnotenie projekt, zostavenie rozvrhu práce, vytvorenie a školenie spoločnej pracovnej skupiny.
2. Vykonanie 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, stanovenie zoznamu cieľových funkcií organizácie, analýza rozloženia funkcií podľa oddelení a zamestnancov, identifikácia funkčných interakcií medzi oddeleniami, informačné toky v rámci oddelení a medzi nimi, vonkajšie vo vzťahu k organizácii objektov a vonkajšie informačné vplyvy, analýza existujúce fondy automatizácia činností organizácie.

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

• model „AS-IS“ („taký, aký je“), ktorý odzrkadľuje 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 to malo byť“), odrážajúci myšlienku nových technológií organizácie.

Každý z modelov musí obsahovať plne funkčné a informačný modelčinnosti organizácie, ako aj (v prípade potreby) model, ktorý popisuje dynamiku správania sa organizácie. Uvedomte 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 ich možno použiť na školenie zamestnancov a zlepšenie obchodných procesov podniku.

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

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

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

   Návrh systému vychádza z modelov návrhu systému, ktoré vychádzajú z modelu „TO-BE“. Výsledkom vývoja systémového projektu by mala byť schválená a potvrdená špecifikácia softvérových požiadaviek: funkčné, technické a špecifikácie rozhrania, u ktorých bola potvrdená ich úplnosť, testovateľnosť a realizovateľnosť.

2. Vypracovanie podrobného (technického) projektu. V tejto fáze sa vykonáva samotný návrh softvéru vrátane návrhu architektúry systému a podrobného návrhu. Odpoveď je teda daná na otázku: „Ako vybudovať systém tak, aby spĺňal požiadavky?“

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

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

Dokončenie fázy podrobného návrhu je komplexná kontrola projektu alebo kritická bloková analýza projektu.

Etapa implementácie je realizácia nasledujúcich prác.

1. Vývoj overenej podrobnej špecifikácie každého podprogramu (blok nie viac ako 100 zdrojových príkazov jazyka na vysokej úrovni).

   Externé špecifikácie by mali obsahovať nasledujúce informácie:

   • názov modulu - uvádza názov používaný na volanie modulu (pre modul s viacerými vstupmi musia existovať samostatné špecifikácie pre každý vstup);
   • funkcia - definuje funkciu alebo funkcie vykonávané modulom;
   • zoznam parametrov (počet a poradie) odovzdaných do modulu;
   • vstupné parametre - presný popis všetkých údajov vrátených modulom (správanie modulu musí byť definované za akýchkoľvek vstupných podmienok);
   • externé efekty (vytlačenie správy, prečítanie požiadavky z terminálu a pod.).
2. Navrhovanie logiky modulov a programovanie (kódovanie) modulov.
3. Kontrola správnosti modulov.
4. Testovacie moduly.
5. Popis databázy až na úroveň jednotlivých parametrov, symbolov a bitov.
6. Plán prijímacích skúšok.
7. Používateľská príručka.
8. Predbežný plán integrácie a ladenia. Obsah nasledujúcich fáz sa v zásade zhoduje s príslušnými procesmi životného cyklu softvéru. Technologické etapy sa vo všeobecnosti 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 životným cyklom softvéru je znázornený na obrázku.

Ryža. 1.

Typy modelov životného cyklu softvéru

Vodopádový model (klasický životný cyklus)

Tento model vďačí za svoj vzhľad W. Royceovi (1970). Model má aj ďalšie meno - vodopád. Zvláštnosťou modelu je, že prechod do ďalšej fázy sa vykonáva až po úplnom dokončení práce v predchádzajúcej fáze; náhrady za absolvované etapy sa neposkytujú.

Požiadavky na vyvinutý softvérový systém určené vo fázach tvorby a analýzy sú prísne dokumentované vo forme technických špecifikácií a sú stanovené na celé obdobie vývoja projektu. Každá etapa končí vydaním kompletnej sady dokumentácie (TOR, EP, TP, RP), dostatočnej na to, aby vo vývoji mohol pokračovať ďalší vývojový tím. Kritériom kvality vývoja s týmto prístupom je presnosť implementácie špecifikácií TK. Hlavné zameranie vývojárov je zamerané na dosiahnutie optimálnych hodnôt technické vlastnosti vyvinutý softvérový systém - výkon, veľkosť pamäte a pod.

Výhody kaskádový model:

• v každej fáze je vytvorený kompletný súbor projektovej dokumentácie, ktorý spĺňa kritériá úplnosti a konzistentnosti;
• etapy 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, pre ktorý je možné na začiatku projektu úplne a jasne formulovať všetky požiadavky. Pokiaľ je toto všetko riadené štandardmi a rôznymi štátnymi schvaľovacími komisiami, schéma funguje dobre.

nevýhody kaskádový model:

• identifikácia a odstránenie chýb sa vykonáva iba v štádiu testovania, ktoré je možné 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é iba čiastočne;
• výsledky práce sú zákazníkovi k dispozícii až po dokončení projektu.

Iteratívny model životného cyklu PS

S rastom komerčných projektov sa ukázalo, že nie vždy je možné podrobne vypracovať projekt budúceho systému, pretože mnohé aspekty jeho fungovania v dynamických oblastiach činnosti (podnikania) sa pri vytváraní systému menia. Bolo potrebné zmeniť vývojový proces, aby sa zaistilo, že po dokončení akejkoľvek vývojovej fázy budú vykonané potrebné opravy. 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 je možné chyby v návrhu a programovaní opraviť neskôr čiastočným návratom do predchádzajúcej fázy. Čím nižšia je miera detekcie chýb, tým drahšia je oprava. Ak sa náklady na úsilie potrebné na odhalenie a odstránenie chýb vo fáze písania kódu budú brať ako jednotka, potom náklady na identifikáciu a odstránenie chyby vo fáze vývoja požiadaviek budú 5-10 krát nižšie a náklady na identifikácia a odstránenie chyby vo fáze údržby bude 20 -krát menej. viac.

V takejto situácii má fáza formulovania požiadaviek, vypracovania špecifikácií a vytvorenia systémového plánu veľký význam. Softwaroví architekti sú osobne zodpovední za všetky následné zmeny dizajnu. Objem dokumentácie sa pohybuje v tisíckach strán a počet schvaľujúcich schôdzí je obrovský. Mnoho projektov nikdy neopustí fázu plánovania a nespadá do „analytickej paralýzy“. Jednou z možností, ako sa takýmto situáciám vyhnúť, je prototypovanie (prototypovanie).

Rozloženie

Zákazník často nemôže formulovať požiadavky na vstup, spracovanie alebo výstup údajov 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 (prototyping) je proces vytvárania modelu požadovaného produktu.

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

1. Maketa papiera (ručne kreslený diagram dialógu človek-stroj) alebo maketa na báze 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 medzi zákazníkom a vývojárom.

Postupnosť činností počas prototypovania je znázornená na obrázku. Prototypovanie začína zhromažďovaním a objasňovaním požiadaviek na vytváraný softvérový systém. Vývojár a zákazník spoločne definujú ciele softvéru, stanovujú, ktoré požiadavky sú známe a ktoré je potrebné ďalej definovať. Potom sa vykoná rýchly návrh. Zameriava sa na vlastnosti, ktoré by mali byť pre používateľa viditeľné. Rýchly dizajn vedie k vytvoreniu 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 neidentifikuje všetky požiadavky zákazníka a nedovolí vývojárovi porozumieť tomu, čo je potrebné urobiť.

Cnosti prototypovania sú schopnosť zabezpečiť, aby boli definované úplné systémové požiadavky. Nevýhody rozloženia:

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

Mala by sa objasniť podstata nedostatkov. Akonáhle zákazník uvidí funkčnú verziu PS, prestane si uvedomovať, že pri hľadaní pracovnej verzie PS zostáva mnoho problémov s kvalitou nevyriešených a jednoduchosť údržby systémy. Keď vývojár o tom zákazníkovi povie, odpoveďou môže byť rozhorčenie a dopyt po najrýchlejšej transformácii rozloženia na funkčný produkt. To má negatívny vplyv na riadenie vývoja softvéru.

Na druhej strane, aby vývojár rýchlo získal fungujúce rozloženie, často robí určité kompromisy. Napríklad nemusia byť použité najvhodnejšie programovacie jazyky, príp operačný systém... Na jednoduchú ukážku je možné použiť neúčinný (jednoduchý) algoritmus. Vývojár po chvíli zabúda na dôvody, prečo tieto nástroje nie sú vhodné. Výsledkom je, že do systému je integrovaná zďaleka nie ideálna zvolená možnosť.

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

Stratégie navrhovania 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;
• inkrementálna stratégia. Na začiatku procesu sú určené všetky užívateľské a systémové požiadavky, zvyšok návrhu je vykonaný ako postupnosť verzií. Prvá verzia implementuje niektoré z plánovaných funkcií, ďalšia verzia implementuje pridané vlastnosti a tak ďalej, kým sa nezíska kompletný systém;
• evolučná stratégia. Systém je tiež postavený v sérii verzií, ale na začiatku procesu nie sú uvedené všetky požiadavky. V dôsledku vývoja verzií sa požiadavky spresňujú. 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 stratégie prírastkového dizajnu. Kombinuje prvky sekvenčného modelu vodopádu s iteračnou filozofiou prototypovania (ako vylepšenie navrhol B. Boehm 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 (verzia) implementuje funkcie základného spracovania, úpravy a dokumentácie súborov; v 2. prírastku - komplexnejš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 (aj keď mnohé doplnkové požiadavky zostávajú nesplnené). Ďalší plán prírastkov obsahuje úpravy základného produktu, aby poskytovali ďalšie funkcie a funkcie.

Inkrementálny proces je vo svojej podstate iteračný, ale na rozdiel od prototypovania, inkrementálny model poskytuje funkčný produkt pri každom prírastku.

Schéma takého modelu životného cyklu softvéru je zobrazená 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 softvéru životného cyklu

Špirálový model Je klasickým príkladom evolučnej stratégie dizajnu. Model (B. Boehm, 1988) je založený na najlepšie vlastnosti klasický životný cyklus a prototypovanie, ku ktorému sa pridáva nový prvok - analýza rizika, ktorá v týchto paradigmách chýba. Model definuje štyri akcie, reprezentované štyrmi kvadrantmi špirály.

1. Plánovanie - 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 - hodnotenie súčasných výsledkov návrhu zákazníkom.

Integrujúci aspekt špirálový model zrejmé pri zvažovaní radiálneho rozmeru špirály. S každou iteráciou viac a viac plné verzie PS. V prvom rade špirály sú identifikované počiatočné ciele, možnosti a obmedzenia a je rozpoznané a analyzované riziko. Ak analýza rizika odhalí nejednoznačnosť požiadaviek, vývojári a zákazník zachránia prototypy použité v kvadrante návrhu.

Na ďalšiu identifikáciu problémových a spresnených požiadaviek je možné použiť modelovanie. Zákazník vyhodnotí inžiniersku (projekčnú) prácu a navrhne ú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íka. V každom cykle v špirále sú výsledky analýzy rizika formulované v tvare „pokračovať, nepokračovať“. Ak je riziko príliš veľké, projekt je možné zastaviť.

Vo väčšine prípadov špirála pokračuje, pričom každý krok smeruje vývojárov k všeobecnejšiemu modelu systému. Každý špirálový cyklus vyžaduje návrh (pravý dolný kvadrant), ktorý je možné dosiahnuť klasickým životným cyklom alebo prototypovaním. Všimnite si toho, že počet vývojových aktivít (vyskytujúcich sa v pravom dolnom kvadrante) sa zvyšuje, keď sa pohybujete zo stredu špirály.

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

1. - počiatočný zber požiadaviek a plánovanie projektu;
2. - rovnaká práca, ale na základe odporúčaní zákazníka;
3. - analýza rizika na základe počiatočných požiadaviek;
4. - analýza rizika na základe reakcie zákazníka;
5. - prechod na integrovaný systém;
6. - počiatočné rozloženie systému;
7. - ďalšia úroveň rozloženia;
8. - navrhnutý systém;
9. - hodnotenie zákazníkom.

Dôstojnosť špirálový model:

1. najrealistickejšie (vo forme evolúcie) odráža vývoj softvér;
2. umožňuje vám výslovne vziať do úvahy riziko v každej fáze vývoja;
3. obsahuje krok systémový prístup do iteratívnej vývojovej štruktúry;
4. používa simuláciu na zníženie rizika a vylepšenie softvérového produktu.

nevýhody špirálový model:

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

V súčasnosti je najbežnejší model procesu špirálového vývoja. Najslávnejšie varianty sú RUP (Rational Unified Process) od Rational a MSF (Microsoft Solution Framework). Ako modelovací jazyk sa používa UML (Unified Modeling Language). Vytvorenie systému sa má vykonávať iteračne, pohybovať sa v špirále a v rovnakých fázach vylepšovať vlastnosti 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ť, čo sa plánuje, a používatelia sa s výrobkom začínajú vopred zoznámiť a majú možnosť vykonať potrebné úpravy.

Vyžaduje si to však veľmi veľké finančné prostriedky. Skutočne, ak bolo predtým možné vytvárať a rozpustiť tímy špecialistov podľa potreby, teraz sa musia všetci neustále zúčastňovať projektu: architekti, programátori, testeri, inštruktori atď. Okrem toho je potrebné synchronizovať úsilie rôznych skupín, aby sa včas reflektovať konštrukčné riešenia a vykonať potrebné zmeny.

Racionálny jednotný proces

Racionálne jednotný postup(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 sa začali na začiatku osemdesiatych rokov minulého storočia. v spoločnosti Rational Software corporation. Začiatkom roku 2003 spoločnosť Rational získala spoločnosť IBM. Jedným z hlavných pilierov RUP je proces vytvárania modelov pomocou Unified Modeling Language (UML).

RUP je jednou z metodík špirálového vývoja softvéru. Metodiku podporuje a vyvíja spoločnosť Rational Software. Unified Modeling Language (UML) sa používa ako modelovací jazyk vo všeobecnej znalostnej základni. Iteračný a prírastkový vývoj softvéru v RUP zahŕňa rozdelenie projektu na viacero projektov, ktoré sa vykonávajú postupne, a každá iterácia vývoja je jasne definovaná súborom cieľov, ktoré je potrebné dosiahnuť na konci iterácie. Konečná iterácia predpokladá, že súbor cieľov pre iteráciu musí presne zodpovedať súboru cieľov stanovených zákazníkom produktu, to znamená, že musia byť splnené všetky požiadavky.

Tento proces zahŕňa vývoj modelov; iterácia vývojového cyklu je jedinečne spojená s konkrétnou verziou 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ď je často zobrazovaný ako tabuľka grafov ..

Tento obrázok predstavuje dve dimenzie: 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 počiatočných iteráciách je viac času venovaného požiadavkám; v neskorších iteráciách je implementácii venovaných viac času. Horizontálna os je tvorená časovými intervalmi - iteráciami, z ktorých každá je nezávislým vývojovým cyklom; cieľom cyklu je vniesť do vopred definovaného hmatateľného upresnenia konečný produkt, ktorý je užitočný z pohľadu zainteresovaných strán.

Životný cyklus je rozdelený na štyri hlavné fázy pozdĺž časovej osi.

1. Počiatok - formovanie koncepcie projektu, porozumenie tomu, čo vytvárame, vízia produktu (vízia), vypracovanie podnikateľského plánu (obchodného prípadu), príprava prototypu programu alebo čiastočného riešenia. Toto je fáza zhromažďovania informácií a analyzovania požiadaviek, ktoré definujú obraz projektu ako celku. Cieľom je získať podporu a finančné prostriedky. V záverečnej iterácii sú výsledkom tejto fázy referenčné podmienky.
2. Návrh, vývoj (Vypracovanie) - objasnenie plánu, pochopenie toho, ako ho vytvárame, navrhovanie, plánovanie potrebných akcií a zdrojov, podrobný popis funkcií. Fáza končí spustiteľnou architektúrou, keď sa urobia všetky architektonické rozhodnutia a vezmú sa do úvahy riziká. Spustiteľná architektúra je spustený softvér, ktorý predvádza implementáciu základných architektonických riešení. V konečnej iterácii ide o technický projekt.
3. Implementácia, vytvorenie systému (Konštrukcia) - etapa rozšírenia funkčnosti systému, vloženého do architektúry. V konečnej iterácii je to pracovný návrh.
4. Implementácia, nasadenie (prechod). Vytvorenie konečnej verzie produktu. Fáza implementácie produktu, dodanie produktu konkrétnemu používateľovi (replikácia, dodanie a školenie).

Vertikálna os pozostáva z disciplín, z ktorých každá môže byť podrobnejšie popísaná z hľadiska vykonávaných úloh, úloh, ktoré sú za ne zodpovedné, produktov, ktoré sú predložené úlohám ako vstup a uvoľňujú sa 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 z pohľadu tejto metodiky, podporovanej nástrojmi IBM (a / alebo tretích strán), nie je celkom pravda.

1. Obchodná analýza a modelovanie (Business modeling) poskytuje implementáciu zásad modelovania s cieľom študovať podnikanie organizácie a zhromažďovať o nej znalosti, optimalizovať obchodné procesy a rozhodovať o ich čiastočnej alebo úplnej automatizácii.
2. Riadenie požiadaviek je o získavaní 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 opisujú očakávania toho, čo by mal systém robiť.
3. Analýza a návrh pokrýva postupy transformácie požiadaviek na prechodné popisy (modely), ktoré predstavujú spôsob, akým 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 (Test) sa zaoberá hodnotením kvality vytváraného produktu.
6. Nasadenie zahŕňa operácie, ktoré sa vykonávajú pri prechode produktov k zákazníkom a pri sprístupnení produktu koncovým používateľom.
7. Správa konfigurácií je predovšetkým o synchronizácii middlewaru a koncových produktov a riadení ich vývoja v celom projekte a hľadaní skrytých problémov.
8. Project Management (Management) sa zaoberá plánovaním projektov, riadením rizík, monitorovaním jeho priebehu a priebežným hodnotením kľúčových ukazovateľov.
9. Manažment životného prostredia (Environment) zahŕňa prvky formovania vývojového prostredia informačný systém a podpora aktivít projektu.

V závislosti od špecifík projektu je možné použiť akékoľvek nástroje IBM Rational alebo nástroje tretích strán. RUP odporúča šesť postupov úspešného vývoja projektu: iteračný 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 úlohy. Artefakty sú niektoré z produktov projektu, ktoré sú generované alebo použité pri práci na konečnom produkte. Prípady použitia sú sekvencie akcií vykonaných systémom na dosiahnutie pozorovateľného výsledku. V skutočnosti je akýkoľvek výsledok práce jednotlivca alebo skupiny artefaktom, či už ide o analytický dokument, prvok modelu, súbor s kódom, testovací skript, popis chyby atď. Za vytvorenie sú zodpovední niektorí špecialisti tohto alebo toho druhu artefaktov. RUP teda jasne definuje zodpovednosti - úlohy - každého člena vývojového tímu v jednom alebo inom štádiu, to znamená, kedy a kto by mal vytvoriť ten alebo onen artefakt. Celý proces vývoja softvérového systému je v RUP považovaný za proces vytvárania artefaktov - od počiatočných analytických dokumentov po spustiteľné moduly, používateľské príručky atď.

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

• Rational Rose - PRÍPAD- vizuálny simulátor informačné systémy, ktoré majú schopnosť generovať prvky kódu. Špeciálna edícia produktu - Rational Rose RealTime - vám umožňuje získať na výstupe spustiteľný modul;
• Rational Requisite Pro je nástroj na správu požiadaviek, ktorý vám umožňuje vytvárať, štruktúrovať, určovať priority, sledovať a kontrolovať zmeny požiadaviek, ku ktorým dochádza v akejkoľvek fáze vývoja komponentov aplikácie;
• Rational ClearQuest je produkt na riadenie zmien a sledovanie chýb v projekte (sledovanie chýb), úzko integrovaný 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ý vám umožňuje nastaviť firemný štandard pre interné dokumenty. Je tiež možné uviesť 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 jazykoch C / C ++, Visual Basic a Java; pomáha identifikovať a odstraňovať prekážky vo výkone softvéru;
• Rational Visual PureCoverage - Automaticky identifikuje oblasti kódu, ktoré sa netestujú.
• Rational ClearCase je produkt správy konfigurácie softvéru (SCM), ktorý umožňuje správu 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 test automatizácie;
• 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 je nástroj na vytváranie, úpravu a automatické spúšťanie testov;
• SiteLoad, SiteCheck - nástroje na testovanie výkonu webových stránok 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. Nedávny produkt IBM Rational Software Architect (RSA) je napríklad súčasťou platformy 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 vyvinutý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 funkcie softvérových produktov, ako sú Rational Application Developer, Rational Web Developer a Rational Software Modeler, čo umožňuje architektom a analytikom vytvárať rôzne pohľady na vyvíjaný informačný systém pomocou UML 2.0 a vývojárom vykonávať vývoj J2EE, XML, webové služby atď.

Rational Software Architect vám podľa zásad RUP umožňuje vytvárať požadované modely v rámci pracovných tokov disciplín, ako sú:

• obchodná analýza a modelovanie (obchodné modelovanie);
• manažment požiadaviek (Požiadavky);
• analýza a návrh (analýza a návrh);
• implementácia

Rational Software Architect navyše podporuje technológiu MDD (Model-Driven Development), ktorá umožňuje modelovanie softvéru na rôznych úrovniach abstrakcie s vysledovateľnosťou.

MSF (Microsoft Solution Framework)

V roku 1994 spoločnosť Microsoft v snahe maximalizovať vplyv projektov IT vydala súbor pokynov pre účinný návrh, vývoj, implementáciu a údržbu riešení založených na svojich technológiách. Tieto znalosti sú založené na skúsenostiach, ktoré spoločnosť Microsoft získala 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 IT priemysel doteraz nazhromaždil. To všetko je prezentované vo forme dvoch vzájomne súvisiacich 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 MSF pre aplikované a špecializované použitie. Spoločnosť Microsoft okrem toho certifikuje odborníkov konkrétne na aplikované znalosti pri aplikácii MSF (napríklad certifikácia MCTS 74-131 za odbornosť v technikách projektového riadenia). Predtým, ako sa naučíte techniky MSF, mali by ste najskôr určiť, o ktorú aplikáciu MSF hovoríte.

Najpopulárnejšie aplikácie MSF vyvinuté spoločnosťou Microsoft sú:

• metodika implementácie riešení v oblasti projektového riadenia;
• metodika riadenia projektov IT založená na metodikách Lekárov bez hraníc a Agile.

Dôležitosť aplikácií MSF podčiarkuje fakt, že Microsoft pri svojich IT projektoch v „čistej verzii“ nepoužíva samotnú metodiku MSF. Projekty konzultačných služieb spoločnosti Microsoft používajú hybridnú metodológiu MSF a Agile. Napriek vonkajším významným rozdielom v použitých verziách MSF, ktoré vyvinuli odborníci spoločnosti Microsoft, zostáva základňa metód MSF pre ne spoločná a odráža všeobecné metodologické prístupy k iteračnému riadeniu projektov.

Cieľom MOF je poskytnúť organizáciám, ktoré stavajú najdôležitejšie IT riešenia založené na produktoch a technológiách spoločnosti Microsoft, technické pokyny, ako dosiahnuť ich spoľahlivosť, dostupnosť, jednoduchosť údržby(podporovateľnosť) a ovládateľnosť (ovládateľnosť). MOF rieši problémy súvisiace s organizáciou ľudí a procesmi; technológie a manažment v komplexných, distribuovaných a heterogénnych prostrediach IT. MOF je založený na najlepších výrobných postupoch zostavených v knižnici IT Infrastructure Library (ITIL) zostavenej Ústrednou počítačovou a telekomunikačnou agentúrou - vládnou agentúrou Spojeného kráľovstva.

Vybudovanie obchodného riešenia v stanovenom čase a rozpočte si vyžaduje osvedčený metodický rámec. Lekári bez hraníc ponúkajú osvedčené metodiky pre plánovanie, navrhovanie, vývoj a implementáciu úspešných riešení IT. Vďaka svojej flexibilite, škálovateľnosti a nedostatku prísnych predpisov sú Lekári bez hraníc schopní uspokojiť potreby organizácie alebo projektového tímu akejkoľvek veľkosti. Metodika MSF pozostáva zo zásad, modelov a disciplín riadenia ľ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. Sú podrobne popísané v 5 bielych obrázkoch. Je lepšie začať študovať Lekárov bez hraníc 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 školenia).

Procesný model MSF poskytuje všeobecnú metodológiu pre vývoj a implementáciu IT riešení. Zvláštnosťou tohto modelu je, že ho vďaka svojej flexibilite a absencii prísne stanovených postupov možno uplatniť pri vývoji veľmi širokého spektra projektov IT. 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 ďalší inovatívny aspekt: ​​pokrýva celý životný cyklus vytvárania riešenia, od počiatočného bodu po samotnú implementáciu. Tento prístup pomáha projektovým tímom zamerať sa na obchodnú hodnotu riešenia, pretože tento výnos sa stane skutočným až po nasadení a použití produktu.

Proces MSF je zameraný na „míľniky“ - kľúčové body projektu, charakterizujúce dosiahnutie akéhokoľvek významného (strednodobého alebo konečného) výsledku v jeho rámci. Tento výsledok je možné vyhodnotiť a analyzovať, čo znamená zodpovedať otázky: „Dosiahol projektový tím jednoznačné pochopenie cieľov a rozsahu projektu?“, „Je akčný plán dostatočne pripravený?“ Spĺňa riešenie potreby zákazníka? " atď.

Procesný model MSF vyhovuje neustálym zmenám v konštrukčných požiadavkách. 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 konečnú podobu.

Vlastnosti procesného modelu MSF 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 koncepcie (predstavovanie);
• plánovanie (plánovanie);
• vývoj (vývoj);
• stabilizácia;
• nasadenie (nasadenie).

Okrem toho existuje veľký počet míľnikov, ktoré ukazujú určitý pokrok v projekte a rozdeľujú veľké segmenty práce na menšie, viditeľné oblasti. Lekár bez hraníc pre každú fázu modelu procesu 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 ďalšie pracovné materiály zvyčajne vytvárajú iteračným spôsobom. Lekári bez hraníc odporúčajú začať s vývojom riešení budovaním, testovaním a implementáciou základných funkcií. Potom sú do riešenia pridávané ďalšie a ďalšie funkcie. Táto stratégia sa označuje ako stratégia vytvárania verzií. Aj keď jedno vydanie môže stačiť na malé projekty, odporúča sa dávať si pozor na príležitosť vytvoriť viacero verzií pre jedno riešenie. S vytváraním nových verzií sa funkčnosť riešenia vyvíja.

Iteračný prístup k vývojovému procesu vyžaduje flexibilný spôsob vedenia dokumentácie. Živé dokumenty by sa mali meniť podľa vývoja projektu spolu so zmenami požiadaviek na konečný produkt. MSF poskytuje množstvo štandardných šablón dokumentov, ktoré sú artefaktmi každej fázy vývoja produktu a je ich možné použiť na plánovanie a riadenie procesu vývoja.

Riešenie nemá žiadnu obchodnú hodnotu, kým nie je implementované. Z tohto dôvodu procesný model MSF obsahuje celý životný cyklus riešenia vrátane jeho implementácie až do bodu, keď sa riešenie začne vyplácať.

Pojem „životný cyklus“ predpokladá niečo, čo sa narodí, vyvíja a zomrie. Rovnako ako živý organizmus, aj softvérové ​​produkty sa vytvárajú, prevádzkujú a vyvíjajú v priebehu času.

Životný cyklus softvér zahŕňa všetky fázy jeho vývoja: od vzniku jeho potreby až po úplné zastavenie jeho používania v dôsledku zastarávania alebo straty potreby riešiť zodpovedajúce problémy.

Existuje niekoľko fáz existencie softvérového produktu počas jeho životného cyklu. Pre tieto fázy a ich počet stále neexistujú žiadne všeobecne akceptované názvy. Ale ani v tejto otázke nie sú žiadne konkrétne nezhody. Preto existuje niekoľko možností na rozdelenie životného cyklu softvéru na etapy. Otázka, či je daný konkrétny oddiel lepší ako ostatné, nie je zásadná. Hlavnou vecou je správne zorganizovať vývoj softvéru a zohľadniť ich.

Podľa dĺžky životného cyklu je možné softvérové ​​produkty rozdeliť do dvoch tried: malý a dlhá životnosť. Tieto triedy programov zodpovedajú flexibilnému (mäkkému) prístupu k ich tvorbe a používaniu a rigidnému priemyselnému prístupu k regulovanému návrhu a prevádzke softvérových produktov. V. vedeckých organizácií a univerzitám napríklad dominuje rozvoj programov prvej triedy a v dizajnérskych a priemyselných organizáciách - druhá.

Softvérové ​​produkty s krátkou životnosťou sú vytvorené hlavne na riešenie vedeckých a technických problémov, na získanie konkrétnych výsledkov výpočtov. Takéto programy sú spravidla relatívne malé. Vyvíja ich jeden špecialista alebo malá skupina. Hlavnú myšlienku programu prediskutuje jeden programátor a koncový používateľ. Niektoré detaily sú uvedené na papier a projekt je dokončený do niekoľkých dní alebo týždňov. Nie sú určené na replikáciu a odovzdanie na neskoršie použitie iným tímom. Tieto programy sú ako také súčasťou výskumu a vývoja a nemožno ich považovať za odcudziteľné softvérové ​​produkty.

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

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

Údržba a úpravy takýchto programov nie sú potrebné a ich životný cyklus sa končí po obdržaní výsledkov výpočtov. Hlavné náklady v životnom cykle takýchto programov spadajú do fáz systémovej analýzy a návrhu, ktoré v dôsledku toho trvajú mesiac až 1 ... 2 roky.

pričom životný cyklus softvérového produktu zriedka prekročí 3 roky.

Softvérové ​​produkty s dlhou životnosťou sú 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 ... 1 000 tisíc príkazov), ale všetky majú vlastnosti poznateľnosti a možnosti modifikácie v procese dlhodobej údržby a používania rôznymi odborníkmi. Softvérové ​​produkty tejto triedy je možné replikovať, sú sprevádzané dokumentáciou ako priemyselné výrobky a ide o softvérové ​​produkty odcudzené vývojárovi.

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

Ich návrhom a prevádzkou sa zaoberajú veľké tímy špecialistov, ktoré vyžadujú formalizáciu softvérového systému, ako aj formálne testovanie a stanovenie dosiahnutých ukazovateľov kvality konečného produktu. Ich životný cyklus je 10 ... 20 rokov. Až 70 ... 90% tohto času sa vynakladá 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 systémová analýza a dizajn.

Všetky nasledujúce prezentácie sa zameriavajú na vývoj veľkých (komplexných) softvérových nástrojov na riadenie a spracovanie informácií.

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

I. Analýza systému:

a) výskum;

b) analýza uskutočniteľnosti:

Prevádzkové;

Ekonomický;

Obchodné.

II. Návrh softvéru:

a) dizajn:

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

Návrh externého softvéru;

Návrh databázy;

Softvérová architektúra;

b) programovanie:

Interný návrh softvéru;

Externý návrh softvérových modulov;

Interný návrh softvérových modulov;

Kódovanie;

Ladiace programy;

Programovanie;

c) ladenie softvéru.

III. Hodnotenie (testovanie) softvéru.

IV. Použitie softvéru:

a) operácia;

b) sprievod.

Ja... Analýza systému. Na začiatku vývoja softvéru sa vykonáva systémová analýza (predbežný návrh), počas ktorej sa určuje jeho potreba, účel a hlavné funkčné charakteristiky. Odhadujú sa náklady a možná účinnosť budúceho softvérového produktu.

V tejto fáze je zostavený zoznam požiadaviek, tj. Jasná definícia toho, čo používateľ očakáva od hotového výrobku. Tu sa uskutočňuje stanovovanie cieľov a zámerov, kvôli implementácii ktorých 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 okamihu, keď si vývojový manažér uvedomí potrebu softvéru.

Práca pozostáva z plánovania a koordinácie činností potrebných na prípravu formálneho ručne napísaného zoznamu požiadaviek na vyvíjaný softvérový produkt.

Výskum končí keď sú požiadavky formulované takým spôsobom, že sú viditeľné 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 sa vtedy, keď je zámer vedenia natoľko posilnený, že je vymenovaný projektový manažér, ktorý organizuje návrh a alokáciu zdrojov (práce).

Práca spočíva vo výskume navrhovaného softvérového produktu s cieľom získať praktické hodnotenie možnosti realizácie projektu sú určené predovšetkým:

- prevádzková uskutočniteľnosť , Bude výrobok dostatočne pohodlný na praktické použitie?

- ekonomická uskutočniteľnosť , Sú náklady na vývoj výrobku prijateľné? Aké sú tieto náklady? Bude výrobok ekonomický účinný nástroj v rukách užívateľa?

- obchodná uskutočniteľnosť, Bude produkt atraktívny, žiadaný, ľahko sa inštaluje, prispôsobí sa službe a bude sa ľahko učiť?

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ú zozbierané a schválené všetky požiadavky.

Pred pokračovaním v ďalšej práci na projekte sa musíte uistiť, že sú prijaté všetky potrebné informácie. Tieto informácie musia byť presné, zrozumiteľné a funkčné. Mal by predstavovať celý rad požiadaviek, ktoré uspokoja užívateľa pre vyvinutý softvérový produkt, vypracovaný vo forme špecifikácie.

Nedodržanie tejto požiadavky môže v budúcnosti výrazne spomaliť realizáciu projektu v dôsledku opakovaných opakovaných výziev užívateľa na objasnenie nesprávne interpretovaných podrobností, nešpecifikovaných podmienok a v dôsledku toho si vyžiada prepracovanie už vyvinutých častí.

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

II... Návrh softvéru. Dizajn je hlavnou a rozhodujúcou fázou životného cyklu softvéru, počas ktorého vzniká softvérový produkt a 90% nadobúda konečnú podobu.

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

Konštrukcia softvér zvyčajne začína už vo fáze štúdie uskutočniteľnosti, akonáhle sú na papieri stanovené niektoré predbežné ciele a požiadavky.

Kým budú požiadavky schválené, práce vo fáze návrhu budú v plnom prúde.

V tomto segmente životnosti softvéru vykonávajú:

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

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

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

Návrh architektúry softvéru - definovanie objektov, modulov a ich prepojení.

Programovanie začína už vo fáze návrhu, akonáhle budú k dispozícii základné špecifikácie pre jednotlivé súčasti softvérového produktu, nie však skôr, ako sa schváli dohoda o požiadavkách. Prekrývanie fáz programovania a návrhu vedie k úspore celkového času vývoja, ako aj k zaisteniu validácie rozhodnutí o návrhu a v niektorých prípadoch k riešeniu kľúčových problémov.

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

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

Ladiaci softvér sa vykonáva potom, ako sú všetky jeho súčasti odladené oddelene a zostavené do jedného softvérového produktu.

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

Toto sa vykonáva s cieľom zaistiť, aby hotový softvérový produkt spĺňal všetky požiadavky a špecifikácie, mohol byť použitý v používateľskom prostredí bez akýchkoľvek chýb a obsahovať potrebnú dokumentáciu, ktorá presne a úplne popisuje softvérový produkt.

Fáza hodnotenia začína, akonáhle sú všetky súčiastky (moduly) zmontované a testované, t.j. po úplnom odladení hotového softvérového produktu. Končí sa po prijatí potvrdenia, že softvérový produkt prešiel všetkými testami a je pripravený na použitie.

Programovanie trvá tak dlho.

IV. Použitie softvéru. Ak je systémová analýza signálom boja, 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 spravidla nie poctivou pre vývojárov.

Takéto porovnanie je vhodné vzhľadom na skutočnosť, že počas používania softvérového produktu sú opravené chyby, ktoré sa vkradli v procese jeho návrhu.

Fáza používania softvérovej položky sa začína prenosom položky do distribučného systému.

Toto je čas, počas ktorého je výrobok v prevádzke a efektívne sa používa.

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

Fáza použitia končí, keď je výrobok vyradený z používania a činnosti uvedené vyššie sú ukončené. Uvedomte si však, že softvérový produkt môže dlhodobo používať niekto iný a po skončení fázy definovania, ako je tu definované. Pretože tento niekto môže softvérový produkt plodne používať doma, aj bez pomoci vývojára.

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

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

Údržba softvéru spočíva v údržbe, vývoji funkčnosti a zlepšovaní prevádzkových charakteristík softvérového produktu, v replikácii a prenose softvérového produktu na rôzne typy výpočtových zariadení.

Údržba hrá úlohu potrebnej spätnej väzby z prevádzkovej fázy.

Počas prevádzky softvéru je možné odhaliť chyby v programoch a existuje potreba ich úpravy a rozšírenia funkcií.

Tieto úpravy sa spravidla vykonávajú súčasne s prevádzkou aktuálnej verzie softvérového produktu. Po skontrolovaní pripravených opráv na jednej z kópií programov predchádzajúca verzia softvérového produktu nahradí predtým používané alebo niektoré z nich. V tomto prípade môže byť prevádzka softvérového produktu takmer nepretržitá, pretož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 obvykle prebieha paralelne a nezávisle od fázy údržby.

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

Prekrývanie medzi rôznymi fázami životného cyklu softvérového produktu je možné a zvyčajne žiaduce. Medzi nesúvislými procesmi by sa však nemalo prekrývať.

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

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

Napríklad, keď sa navrhuje jeden program, architektúra systému sa často upúšťa od a

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

Anotácia.

Úvod.

1. Životný cyklus softvéru

Úvod.

Kroky programovania Riley

Úvod.

1.1.1. Formulácia problému.

1.1.2. Návrh riešenia.

1.1.3. Kódovanie algoritmu.

1.1.4. Údržba programu.

1.1.5. Softvérová dokumentácia.

Záver k článku 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. Služba.

Záver k článku 1.2.

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

1.3.1. Vodopádový model.

1.3.2. Ekonomické zdôvodnenie 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áce na projekte.

Literatúra.

Úvod

Priemyselná aplikácia počítače a rastúci dopyt po softvéri stanovili naliehavé úlohy, aby sa výrazne zvýšili produktivita vývoja softvéru, rozvoj priemyselných metód pre plánovanie a navrhovanie programov, prenos organizačno-technických, technicko-ekonomických a sociálno-psychologických techník, vzorov a metód zo sféry materiálnej výroby do sféry používania počítačov. Komplexný prístup k procesom vývoja, prevádzky a údržby softvéru predložilo niekoľko naliehavých problémov, ktorých riešenie odstráni „úzke miesta“ pri navrhovaní programov, zníži čas dokončenia práce, zlepší výber a prispôsobenie existujúcich programov a možno určiť osud systémov s vstavanými počítačmi.

V praxi vývoja veľkých softvérových projektov často neexistuje jednotný prístup na odhad nákladov práce, načasovanie práce a nákladov na materiál, čo bráni zvýšeniu produktivity vývoja softvéru, a v konečnom dôsledku - efektívne riadenie životného cyklu softvéru. Keďže program akéhokoľvek druhu sa stáva výrobkom (s výnimkou snáď 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 výrobkov a otázky navrhovania programov sa stávajú mimoriadne dôležitými. . Táto myšlienka je v srdci spoločnosti B.W. „Softwarové inžinierstvo“ spoločnosti Boehm, ktoré sme použili pri písaní tohto textu semestrálna práca... V tejto knihe sa návrh softvéru 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ý začína od okamihu, keď sa rozhodne o potrebe vytvoriť softvér, a končí v čase jeho úplného vyradenia zo služby.

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. Ale všetky obsahujú spoločné základné komponenty: vyhlásenie o probléme, návrh riešenia, implementácia, údržba.

Najznámejšou a najkompletnejšou je azda š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 opis hornej úrovne podľa Lehmanna, ktorý zahŕňa tri hlavné fázy a predstavuje popis životného cyklu života v najobecnejšom prípade.

A pre zmenu - uvádzame kroky programovacieho procesu, ktoré predstavil D. Riley v knihe „Používanie jazyka Module -2“. Táto myšlienka je podľa mňa veľmi jednoduchá a známa a začneme s ňou.

1.1 Kroky v procese programovania Riley

Programovací proces zahŕňa štyri kroky (obr. 1):

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

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

kódovanie programu, t. j. prekladanie navrhnutého riešenia do programu, ktorý je možné vykonať na počítači;

údržba programu, t.j. prebiehajúci proces odstraňovania problémov v programe a pridávanie nových funkcií.

Ryža. 1. Štyri kroky programovania.

Programovanie sa začína od okamihu, keď používateľ, t.j. niekto, kto potrebuje program na vyriešenie problému, problém predstaví systémový analytik. Používateľ a systémový analytik spoločne definujú vyhlásenie o probléme. Ten sa potom prenesie algoritmista ktorý je zodpovedný za návrh riešenia. Riešenie (alebo algoritmus) predstavuje postupnosť operácií, ktorých vykonanie vedie k vyriešeniu problému. Pretože algoritmus často nie je strojovo čitateľný, mal by byť preložený do strojového programu. Túto operáciu vykonáva kodér. Správca je zodpovedný za následné zmeny programu. Systémový analytik, algoritmus, kodér a sprievodný programátor sú všetci programátori.

V prípade veľkého softvérového projektu môže byť významný počet používateľov, systémových analytikov a algoritmov. Vzhľadom na nepredvídané okolnosti môže byť navyše potrebné vrátiť sa k predchádzajúcim krokom. To všetko podporuje argument 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

Jednou z najdôležitejších činností v programovaní je vyhlásenie o probléme. Slúži ako zmluva medzi užívateľom a programátorom (programátormi). Rovnako ako právne zle napísaná zmluva je zlé vyhlásenie o probléme zbytočné. Pri dobrej formulácii problému používateľ aj programátor jasne a jednoznačne predstavujú úlohu, ktorú je potrebné vykonať, t.j. v tomto prípade sa prihliada na záujmy užívateľa aj programátora. Užívateľ môže plánovať používanie softvéru, ktorý ešte nebol vytvorený, na základe vedomostí, že môže. Dobrá formulácia problému slúži ako základ pre vytvorenie jeho riešenia.

Formulácia problému (špecifikácia programu); v zásade znamená presný, úplný a zrozumiteľný popis toho, čo sa stane, keď sa spustí konkrétny program. Užívateľ sa zvyčajne pozerá na počítač, ako keby to bola čierna skrinka: nie je pre neho dôležité, ako počítač funguje, ale dôležité je, čo počítač dokáže, čo používateľa zaujíma. V tomto prípade sa hlavná pozornosť zameriava na interakciu osoby so strojom.

Charakteristika vyhlásenia o dobrej úlohe:

Presnosť, t.j. odstránenie akýchkoľvek nejasností. Nemalo by byť otázky, 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. analytikovi systému i používateľovi by to malo byť jasné, pretože vyhlásenie o probléme je jedinou zmluvou medzi nimi.

Požiadavka na presnosť, úplnosť a zrozumiteľnosť je často v rozpore. Mnohým právnym dokumentom je preto ťažké porozumieť, pretože sú napísané vo formálnom jazyku, ktorý vám umožňuje extrémne presne formulovať určité ustanovenia bez akýchkoľvek menších nezrovnalostí. Niektoré otázky na lístkoch na skúšky sú napríklad niekedy také presné, že študent strávi viac času pochopením otázky, než jej zodpovedaním. Vzhľadom na veľký počet podrobností navyše študent nemusí vôbec pochopiť hlavný význam otázky. Najlepšia formulácia problému je tá, ktorá dosahuje rovnováhu všetkých troch požiadaviek.

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

Zvážte nasledujúce tvrdenie o probléme: „Zadajte tri čísla a zadajte čísla v uvedenom poradí.“

Táto formulácia nespĺňa vyššie uvedené požiadavky: nie je ani presná, ani úplná, ani zrozumiteľná. Skutočne by sa mali čísla zadávať po jednom na riadok alebo všetky čísla v jednom riadku? Znamená výraz „v poradí“ zoradenie od najvyššieho po najnižšie, od najnižšieho po najvyššie alebo v rovnakom poradí, 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, vyhlásenie o probléme sa stane podrobným a ťažko zrozumiteľným. D. Riley preto navrhuje použiť na riešenie problému štandardný formulár, ktorý poskytuje maximálnu presnosť, úplnosť, zrozumiteľnosť a zahŕňa:

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

všeobecný popis (zhrnutieúlohy);

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

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

Príklad. Vyjadrenie problému v štandardnej forme.

NÁZOV

Zoradenie troch celých čísel.

POPIS

Vstup a výstup sú tri celé čísla zoradené od najnižšieho po najvyššie.

Zadajú sa tri celé čísla, jedno číslo na riadok. V tomto prípade je celé číslo jedna alebo viac za sebou 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. Oddelené čísla oddeľte medzerou. Čísla sa zobrazujú od najnižšej po najvyššiu, zľava doprava.

1) Ak sú zadané menej ako tri čísla, program čaká na ďalšie zadanie.

Životný cyklus softvéru

Životný cyklus softvéru je časové obdobie, ktoré začína od okamihu, keď sa rozhodne o potrebe vytvoriť softvérový produkt, a končí okamihom jeho úplného vyradenia zo služby. (Štandard IEEE Std 610.12)

Potreba určiť etapy životného cyklu softvéru (LC) je daná túžbou vývojárov zlepšiť kvalitu softvéru prostredníctvom optimálneho riadenia vývoja a použitia rôznych mechanizmov kontroly kvality v každej fáze, od formulácie problému po autorskú podporu softvéru. Najobecnejšou reprezentáciou životného cyklu softvéru je model vo forme základných fáz - procesov, ktoré zahŕňajú:

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 ako celku;

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

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

Údržba softvéru, jeho modifikácia a vylepšovanie, tvorba nových verzií.

Tento model je všeobecne uznávaný a zodpovedá obom domácim regulačné dokumenty v oblasti vývoja softvéru a zahraničných. Z hľadiska zaistenia technologickej bezpečnosti je vhodné podrobnejšie zvážiť zvláštnosti prezentácie fáz životného cyklu v zahraničných modeloch, pretože práve zahraničný softvér je najpravdepodobnejším nositeľom softvérových defektov sabotážny typ.

Štandardy životného cyklu softvéru

GOST 34,601-90

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

Grafická prezentácia modelov životného cyklu vám 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čínali jedna po druhej s využitím výsledkov predchádzajúcej práce. Zabezpečuje postupné vykonávanie všetkých fáz projektu v prísne stanovenom poradí. Prechod do ďalšej fázy znamená úplné dokončenie práce v predchádzajúcej fáze. Požiadavky identifikované vo fáze vytvárania požiadaviek sú prísne zdokumentované vo formulári referenčný rámec a sú zaznamenávané počas celého trvania vývoja projektu. Každá etapa končí vydaním kompletnej sady dokumentácie, dostatočnej 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 je potrebné „vrátiť sa“ do ranej fázy projektu a požadované prepracovanie nielenže vyradí projektový tím z plánu, ale často vedie ku kvalitatívnemu zvýšeniu nákladov a prípadne k ukončeniu projektu v podobe, v akej bol pôvodne koncipovaný. Hlavnou mylnou predstavou autorov modelu vodopádu je predpoklad, že projekt raz prejde celým procesom, navrhnutá architektúra je dobrá a ľahko sa používa, návrh implementácie je rozumný a chyby implementácie sa dajú v priebehu testovania ľahko odstrániť. Tento model predpokladá, že všetky chyby budú koncentrované v implementácii, a preto sú počas testovania komponentov a systému eliminované rovnomerne. Vodopádový model pre veľké projekty preto nie je veľmi realistický a dá sa efektívne použiť iba na vytváranie malých systémov.

Najšpecifickejším je model špirálového životného cyklu. V tomto modeli je pozornosť zameraná 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ždej fáze je špecifikovaný obsah práce a je sústredený vzhľad vytváraného softvéru, je hodnotená kvalita získaných výsledkov a je naplánovaná práca ďalšej iterácie. Pri každej iterácii sa hodnotí nasledovné:

Riziko prekročenia podmienok a nákladov na projekt;

Potreba vykonať ešte jednu iteráciu;

Stupeň úplnosti a presnosti porozumenia požiadavkám na systém;

Realizovateľnosť ukončenia projektu.

Štandardizácia životného cyklu softvéru sa vykonáva v troch smeroch. Prvý smer organizuje a propaguje Medzinárodná organizácia pre normalizáciu (ISO - Medzinárodná organizácia pre normalizáciu) a Medzinárodná elektrotechnická komisia (IEC - Medzinárodná elektrotechnická komisia). Na tejto úrovni štandardizácia najobecnejších technologické procesy vzhľadom k Medzinárodná spolupráca... Druhý smer v USA aktívne rozvíja Institute of Electrotechnical and Electronics Engineers (IEEE) spolu s American National Standards Institute (ANSI). Štandardy ISO / IEC a ANSI / IEEE majú väčšinou poradný charakter. Tretiu oblasť stimuluje ministerstvo obrany USA (ministerstvo obrany-DOD). Štandardy DOD sú záväzné pre firmy poverené ministerstvom obrany USA.

Na návrh softvéru pre komplexný systém, najmä systém v reálnom čase, je vhodné použiť systémový model životného cyklu založený na kombinácii všetkých známych diel v rámci uvažovaných základných procesov. Tento model je určený na použitie pri plánovaní, plánovaní, správe rôznych softvérových projektov.

Je vhodné rozdeliť súbor etáp tohto modelu životného cyklu na dve časti, ktoré sa výrazne líšia vo vlastnostiach procesov, technických a ekonomických charakteristikách a faktoroch, 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 náročnosť na prácu, trvanie a ďalšie charakteristiky v týchto fázach 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 plánov pre nové verzie softvéru.

Druhá časť životného cyklu, odrážajúca podporu prevádzky a údržby softvéru, relatívne slabo súvisí s charakteristikami objektu a vývojového prostredia. Rozsah práce v týchto fázach je stabilnejší a ich intenzita práce a trvanie sa môžu výrazne líšiť a závisia od masívneho používania softvéru. V prípade akéhokoľvek modelu životného cyklu je zaistenie vysokej kvality softvérových systémov možné iba pri použití regulovaného technologického postupu v každej z týchto fáz. Tento proces je podporovaný nástrojmi na automatizáciu vývoja, ktoré je vhodné vybrať si z dostupných alebo ich vytvoriť s prihliadnutím na vývojový objekt a zoznam adekvátnych prác.

Rozvoj VT neustále rozširuje triedy úloh, ktoré je potrebné riešiť súvisiace so spracovaním informácií iného charakteru.

Ide v zásade o tri typy informácií, a teda o tri triedy problémov, na ktorých riešenie sa používajú počítače:

1) Výpočtové úlohy súvisiace so spracovaním číselných informácií. Patrí sem napríklad problém riešenia sústavy lineárnych rovníc veľkých rozmerov. Kedysi to bola hlavná, dominantná oblasť používania počítača.

2) Úlohy na spracovanie symbolických informácií týkajúcich sa vytvárania, úpravy a transformácie textových údajov. Riešenie takýchto úloh je spojené s prácou napríklad sekretárky-písačky.

3) Úlohy na spracovanie grafických informácií, t.j. schémy, kresby, grafy, náčrty atď. K takýmto úlohám patrí napríklad úloha vypracovania návrhov návrhov nových produktov.

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

Riešenie problémov každej triedy na počítači má svoje špecifiká, ale môže byť rozdelené do niekoľkých fáz, ktoré sú typické pre väčšinu problémov.

Technológia programovaniaštuduje technologické procesy a poradie ich prechodu (etapy) pomocou znalostí, metód a prostriedkov.

Je vhodné charakterizovať technológie v dvoch dimenziách - vertikálne (predstavujúce procesy) a horizontálne (reprezentujúce etapy).

Kresba

Proces je súbor vzájomne súvisiacich akcií ( technologické operácie) prevod určitého vstupu na výstup. 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 konceptmi, akými sú pracovné procesy, akcie, úlohy, výsledky výkonnosti, výkonní umelci.

Fáza je súčasťou aktivít vývoja softvéru, obmedzená určitým časovým rámcom a končí vydaním konkrétneho produktu, ktorá je určená požiadavkami stanovenými pre túto fázu. Niekedy sú fázy zoskupené do väčších časových rámcov, ktoré sa nazývajú fázy alebo míľniky. Horizontálna dimenzia teda predstavuje čas, odráža dynamické aspekty procesov a pracuje s konceptmi, ako sú fázy, etapy, etapy, iterácie a kontrolné body.

Vývoj softvéru prebieha podľa konkrétneho životného cyklu.

Životný cyklus Softvér je nepretržitý a usporiadaný súbor činností vykonávaných a kontrolovaných v rámci každého projektu vývoja a prevádzky softvéru, počínajúc od myšlienky (konceptu) vytvorenia určitého softvéru a rozhodnutia o potrebe jeho vytvorenia. a končiac okamihom jeho úplného vyradenia z prevádzky z dôvodov:

a) zastarávanie;

b) strata potreby riešenia zodpovedajúcich problémov.

Technologické prístupy sú mechanizmy implementácie ž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 fázy (fázy, etapy), takže softvérový produkt sa pohybuje z jednej fázy do druhej, počnúc počiatkom koncepcie produktu a končiac fázou jeho skladania.

Životný cyklus vývoja softvéru môže byť predstavený s rôznym stupňom podrobností fáz. Najjednoduchší pohľad na životný cyklus 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 zachovaniu životného cyklu):

Procesy

Dizajn

Programovanie

Testovanie

Doprovod

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

a ladenie a údržba

V skutočnosti sa tu v každej fáze vykonáva 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 (nepoužiteľná), ale môže byť braná 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 a dátových modelov pre systém. Okrem toho sa zaznamenávajú nefunkčné a ďalšie systémové požiadavky.

Fáza návrhu je rozdelená na dve hlavné čiastkové fázy: architektonický a podrobný dizajn. Upresňuje sa najmä návrh programu, užívateľské rozhranie a dátové štruktúry. Nastoľujú sa a zaznamenávajú sa problémy s dizajnom, ktoré ovplyvňujú zrozumiteľnosť, udržiavateľnosť a škálovateľnosť systému.

Realizačná fáza zahŕňa napísanie programu.

Rozdiely v hardvéri a softvéri sú viditeľné najmä vo fáze vykorisťovanie... Ak spotrebný tovar prechádza fázami uvedenia na trh, rastu, zrelosti a poklesu, životnosť softvéru je skôr ako príbeh nedokončenej, ale neustále dokončovanej a renovovanej budovy (lietadla) (Predplatiteľ).

Softvér životného cyklu je regulovaný mnohými štandardmi, vrátane medzinárodných.

Cieľom štandardizácie životného cyklu komplexných softvérových systémov:

Zovšeobecnenie skúseností a výsledkov výskumu mnohých špecialistov;

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

Štandardy zahŕňajú:

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

Stanoviť pravidlá kontroly technologických procesov;

Stanovte požiadavky na prezentáciu výsledkov;

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

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

Zabezpečte priradenie a plánovanie úloh;

Poskytnite kontrolu nad priebehom vytvárania PS.

V Rusku existujú normy, ktoré upravujú životný cyklus:

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

Etapy vývoja JE - GOST 34,601 –90;

Podmienky vytvorenia AU - GOST 34.602-89;

Typy testov reproduktorov - GOST 34,603-92;

Tieto normy však dostatočne neodrážajú vytváranie, údržbu a vývoj aplikovaných softvérových systémov pre IS a niektoré ich ustanovenia sú zastarané z hľadiska budovania moderných distribuovaných komplexov vysokokvalitných aplikačných programov v riadiacich systémoch a spracovania údajov s rôzne architektúry.

V tejto súvislosti je potrebné poznamenať 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 - Medzinárodná elektrotechnická komisia - Medzinárodná elektrotechnická komisia.

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

Títo. vytváranie softvéru nie je taká ľahká ú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 (nákup, dodanie, vývoj, prevádzka, údržba). My sa zameriame na to druhé.

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

1. Správa konfigurácietoto je proces, ktorý podporuje hlavné procesy životného cyklu softvéru, predovšetkým procesy vývoja a údržby. Pri vývoji projektov komplexného softvéru pozostávajúceho z mnohých komponentov, z ktorých každý môže mať rôzne verzie alebo verzie, vzniká problém zohľadniť ich prepojenia a funkcie, vytvoriť jednotnú (tj. Jedinú) štruktúru a zabezpečiť vývoj celého systému. Správa konfigurácií vám umožňuje organizovať, systematicky brať do úvahy a kontrolovať zmeny rôznych softvérových komponentov vo všetkých fázach jeho životného cyklu.

2. Overenie je proces určovania, či je aktuálny stav softvéru dosiahnutý do táto etapa, požiadavky tejto etapy.

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

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

5. Audit- overenie vykonané príslušným orgánom (osobou), ktoré má zabezpečiť nezávislé hodnotenie stupeň súladu softvérových produktov alebo procesov so stanovenými požiadavkami. Vyšetrenie umožňuje posúdiť súlad parametrov vývoja s pôvodnými požiadavkami. Overovanie sa prekrýva s testovaním, ktoré sa vykonáva s cieľom zistiť rozdiel medzi skutočnými a očakávanými výsledkami a posúdiť, či vlastnosti softvéru zodpovedajú pôvodným požiadavkám. V procese implementácie projektu dôležité miesto zaujímajú otázky identifikácie, popisu a kontroly konfigurácie jednotlivých komponentov a celého systému ako celku.

3) organizačné procesy (projektový manažment, tvorba projektovej infraštruktúry, definícia, hodnotenie a zlepšovanie samotného životného cyklu, školenia).

Projektový manažment spojené s plánovaním a organizáciou práce, vytváraním tímov vývojárov a kontrolou nad načasovaním a kvalitou vykonanej práce. Technická a organizačná podpora projektu zahŕňa výber metód a nástrojov na implementáciu projektu, definíciu metód na opis prechodných stavov vývoja, vývoj metód a nástrojov na testovanie vytvoreného softvéru, školenie personálu, atď. Zabezpečovanie kvality projektu sa zaoberá problémami overovania, validácie 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 činnosti a úlohy vykonávané vývojárom a zahŕňa práce na vytvorení softvéru a jeho súčastí v súlade so špecifikovanými požiadavkami vrátane prípravy projektovej a prevádzkovej dokumentácie, ako aj príprava materiálov potrebných na kontrolu výkonnosti a kvality softvérových produktov, materiálov potrebných na školenie zamestnancov atď.

Podľa štandardu zahŕňa životný cyklus softvéru IP nasledujúce akcie:

1) vznik a výskum myšlienky (konceptu);

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

3) analýza požiadaviek na informačný systém - definovať to

funkčnosť, požiadavky používateľov, požiadavky na spoľahlivosť a zabezpečenie, požiadavky na externé rozhranie atď.

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 softvérových požiadaviek- 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 použité údaje, inštalácie, prijatia, používateľskej dokumentácie, prevádzky a údržby.

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

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

popis softvérových komponentov a rozhraní medzi nimi, aktualizácia užívateľskej dokumentácie, vývoj a dokumentácia požiadaviek na test a testovacieho plánu, 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áciu používateľskej dokumentácie, aktualizáciu plánu integrácie softvéru;

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

integračný plán a testovanie zhody softvéru kvalifikačné požiadavky, čo je súbor kritérií alebo podmienok, ktoré je potrebné splniť, aby sa softvérový produkt kvalifikoval tak, aby spĺňal jeho špecifikácie a bol pripravený na použitie v danom operačnom prostredí;

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

prítomnosť zákazníka na preukázanie jeho zhody

požiadavky a pripravenosť na prevádzku; súčasne 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) Kvalifikačné testovanie IP – testovanie systému pre

súlad s požiadavkami na ňu a overenie návrhu a úplnosti dokumentácie;

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

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

testovanie softvéru a informačného systému ako celku a

dokumentovanie výsledkov posúdenia spolu so zákazníkom, certifikácia a konečný prenos softvéru k zákazníkovi.

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

17) vykorisťovanie

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

softvérový produkt.;

19) dokončenie prevádzky.

Tieto akcie je možné zoskupiť konvenčným zvýraznením nasledujúcich hlavných fáz vývoja softvéru:

· Vyhlásenie o probléme (TZ) (podľa stupňa GOST 19.102-77 „Referenčné podmienky“)