Programinės įrangos sistemų kūrimo gyvavimo ciklo modeliai. Programinės įrangos gyvavimo ciklas

baigiamųjų dokumentų pristatymas, proceso metrikos, užduočių pradžios ir pabaigos kriterijai bei pereiti prie kito proceso žingsnio; testavimo metodų parinkimas pasirinktai programinės įrangos klasei, siekiant patikrinti teisingą testavimo užduočių atlikimą; specialių dokumentų šablonų, skirtų kiekvienam testavimo proceso žingsniui dokumentuoti testavimo procesą, kūrimas.

Tie. daroma prielaida, kad kiekvienas darbas bus atliktas taip kruopščiai, kad jį užbaigus ir atlikus kitą žingsnį nebereikės grįžti prie ankstesnio.

Kūrėjas patikrina tarpinį rezultatą naudodamas įvairius gerai žinomus patikrinimo metodus ir įrašo jį kaip paruoštą standartą kitam procesui.

Pagal šį gyvavimo ciklo modelį kūrimo proceso darbai ir užduotys dažniausiai atliekami nuosekliai, kaip parodyta diagramoje. Tačiau pagalbiniai ir organizaciniai procesai (reikalavimų kontrolė, kokybės valdymas ir kt.) dažniausiai vykdomi lygiagrečiai su kūrimo procesu. Šiame modelyje po priežiūros ir klaidų ištaisymo grįžtama prie pradinio proceso.

Šio modelio ypatumas yra tas, kad jis fiksuoja nuoseklius programinės įrangos produkto kūrimo procesus. Jis pagrįstas gamykliniu modeliu, kai gaminys pereina etapus nuo sumanymo iki pagaminimo, tada perduodamas klientui kaip gatavas produktas, kurio keitimas nenumatytas, nors pakeitimas kitu panašiu gaminiu galimas skundas ar kai kurios jo dalys nepavyko.

Šio modelio trūkumai:

• PS kūrimo procesas ne visada telpa į tokią griežtą formą ir veiksmų seką;
• neatsižvelgiama į pasikeitusius vartotojų poreikius, išorinės aplinkos pokyčius, dėl kurių pasikeis reikalavimai sistemai jos kūrimo metu;
• didelis atotrūkis tarp klaidos įvedimo (pavyzdžiui, projektavimo etape) ir jos aptikimo (techninės priežiūros metu) laiko, dėl kurio programinė įranga yra labai pertvarkyta.

Taikant pakopinį modelį gali atsirasti šie rizikos veiksniai:

• reikalavimai programinei įrangai nėra aiškiai suformuluoti arba neatsižvelgiama į OS, aplinkų ir pan. plėtros perspektyvas;
• didelė sistema, neleidžianti suskaidyti komponentų, gali sukelti problemų jį talpinant į atmintį ar platformose, kurios nenumatytos reikalavimuose;
• greiti technologijų ir reikalavimų pokyčiai gali pabloginti atskirų sistemos dalių ar visos sistemos kūrimo procesą;
• išteklių (žmogiškųjų, programinės įrangos, techninių ir kt.) apribojimai kūrimo metu gali susiaurinti individualias sistemos diegimo galimybes;

gautas produktas gali būti netinkamas naudoti dėl kūrėjų neteisingo sistemos reikalavimų ar funkcijų supratimo arba dėl nepakankamo testavimo. Sistemos diegimo naudojant kaskadinį modelį pranašumai yra šie:

• visos posistemių ir sistemos užduotys įgyvendinamos vienu metu (t.y. neužmirštama nei viena užduotis), o tai prisideda prie stabilių ryšių ir ryšių tarp jų užmezgimo;
• pilnai išvystytą sistemą su dokumentacija jai lengviau prižiūrėti, testuoti, taisyti klaidas ir daryti pakeitimus ne atsitiktinai, o tikslingai, pradedant nuo reikalavimų (pavyzdžiui, papildant ar pakeičiant kai kurias funkcijas) ir kartojant procesą.

Kaskadinis modelis gali būti vertinamas kaip gyvavimo ciklo modelis, tinkamas kuriant pirmą programinės įrangos versiją, siekiant išbandyti joje įdiegtas funkcijas. Techninės priežiūros ir eksploatacijos metu gali būti aptiktos įvairios klaidos, kurias taisant reikės kartoti visus procesus, pradedant nuo reikalavimų išsiaiškinimo.

2.2.2. Prieauginio gyvavimo ciklo modelis

Sukurta pirmoji tarpinė sistemos versija (1 leidimas) įgyvendina dalį reikalavimų, į vėlesnę versiją (2 leidimas) pridedami papildomi reikalavimai ir taip toliau, kol galiausiai bus įvykdyti visi reikalavimai ir išspręstos sistemos kūrimo problemos. Kiekvienai tarpinei versijai gyvavimo ciklo etapuose atliekami būtini procesai, darbai ir užduotys, įskaitant reikalavimų analizę ir naujos architektūros kūrimą, kurie gali būti atliekami vienu metu.

Kuriant kiekvieną paskesnę versiją, atliekami PS techninio projekto kūrimo, jo programavimo ir testavimo procesai, PS surinkimas ir kvalifikaciniai testai.

Pagal šį gyvavimo ciklo modelį, kurio procesai yra beveik tokie patys kaip krioklio modelyje, pagrindinis dėmesys skiriamas tam tikros pilnos tarpinės versijos kūrimui, o kūrimo proceso užduotys atliekamos nuosekliai arba iš dalies lygiagrečiai. atskirų tarpinių versijų struktūrų skaičius.

Kitos sistemos versijos su papildomais reikalavimais ar funkcijomis kūrimo proceso darbai ir užduotys gali būti atliekami pakartotinai ta pačia seka visoms tarpinėms sistemos versijoms. Priežiūros ir eksploatavimo procesus galima įgyvendinti lygiagrečiai su versijos kūrimo procesu, tikrinant iš dalies įgyvendintus reikalavimus kiekvienoje tarpinėje versijoje ir taip toliau, kol bus gauta visa sistemos versija. Pagalbiniai ir organizaciniai gyvavimo ciklo procesai dažniausiai vykdomi lygiagrečiai su sistemos versijos kūrimo procesu ir iki kūrimo pabaigos bus renkami duomenys, kuriais remiantis galima nustatyti pagamintos sistemos išsamumo ir kokybės lygį.

Taikant šį modelį reikia atsižvelgti į šiuos rizikos veiksnius:

• reikalavimai rengiami atsižvelgiant į jų pasikeitimo galimybę prekę parduodant;
• visos sistemos galimybės turi būti įdiegtos nuo pat pradžių;
• greiti technologijų ir sistemos reikalavimų pokyčiai gali lemti susidariusios sistemos struktūros sutrikimą;
• Dėl išteklių tiekimo apribojimų (atlikėjų, finansų) sistema gali vėluoti pradėti eksploatuoti.

Šį gyvavimo ciklo modelį patartina naudoti tais atvejais, kai:

• pageidautina greitai įdiegti kai kurias sistemos galimybes, sukuriant tarpinę produkto versiją;
• sistema suskaidoma į atskirus komponentus, kurie gali būti parduodami kaip atskiri tarpiniai arba gatavi produktai;
• galima padidinti finansavimą atskiroms sistemos dalims plėtoti.

Kartais žmonės aiškiai neskiria projektų valdymo darbų ir projekto gyvavimo ciklo darbų, nes norint sėkmingai užbaigti projektą būtinos abi darbo rūšys. Pagrindinis skirtumas tarp šių dviejų yra tas, kad projektų valdymas yra sutelktas į projekto apibrėžimą, planavimą, stebėjimą ir kontrolę bei projekto uždarymą. Darbas, susijęs su realiu projekto pristatymo rezultatų kūrimu, paprastai vadinamas projekto „gyvenimo ciklu“. Projekto valdymo procese sudaromas projekto grafikas, tačiau didžiąją šio grafiko darbų dalį sudaro projekto gyvavimo ciklo darbai, dėl kurių atsiranda produkcijos produktai.

Nors visi projektai yra unikalūs, kaip ir daugumai projektų taikomi bendrieji valdymo procesai, taip pat yra bendrųjų modelių, kurie gali būti gairės apibrėžiant daugumos projektų gyvavimo ciklą. Šie bendrieji modeliai yra vertingi, nes sutaupo projekto komandų laiką kuriant projekto tvarkaraštį.

Vieno iš gyvavimo ciklo modelių pavyzdys yra įprastas klasikinis „krioklio“ modelis. Šis modelis yra pagrindinis metodas, kuris gali būti taikomas bet kuriam projektui. Dažniau pradėsite nuo projekto rezultato reikalavimų supratimo, tada sukursite rezultatą, sukursite ir išbandysite rezultatą, o baigsite įgyvendindami rezultatą. Kiekviena iš šių dėmesio sričių vadinama faze (analizės fazė, projektavimo fazė, įgyvendinimo fazė ir kt.). Klasikinis krioklio metodas yra gyvavimo ciklo modelis, kurį tikriausiai galite taikyti nieko nežinodami apie metodikas ir planuodami projektą nuo nulio.

Kas gali būti paprasčiau? Net jei turite labai mažą projektą, vis tiek atliekate šiuos pagrindinius veiksmus, bent jau kai kuriuos iš jų atlikdami savo galvoje. Pavyzdžiui, jei turite 40 valandų (vienos darbo savaitės) projektą dokumentui sukurti ar tobulinti, gali atrodyti, kad skubate tiesiai į įgyvendinimo etapą. Bet ar taip? Greičiausiai gavote kažkokią užduotį su reikalavimais ar pageidavimais, kuriuos teks suvokti (Analizė) ir paversti ateities turinio planu (Dizainas). Tada įgyvendinate idėją (Įgyvendinimas), patikrinate rezultatą (Testing) ir perduodate naudoti (Įgyvendinimas).

Krioklio (kaskados) schema apima keletą svarbių operacijų, taikomų visiems projektams:

* sistemos plėtros veiksmų plano sudarymas;

* su kiekvienu veiksmu susijusių darbų planavimas;

* Veiksmų eigos stebėjimo su valdymo etapais operacijos taikymas.

Grafinė projekto ciklo „krioklio modelio“ iliustracija

3 pav. Projekto gyvavimo ciklo krioklio modelis

Krioklio (kaskados) modelio privalumai.

Krioklio modelis turi pranašumų, kai naudojamas projekte, kuriam jis tinkamas.

a. Modelis yra gerai žinomas vartotojams, kurie nėra susiję su programų kūrimu ir veikimu, ir galutiniams vartotojams.

b. Jis tvarkingai sprendžia sudėtingumą ir puikiai tinka tiems projektams, kurie yra gana suprantami, bet vis tiek sunkiai išsprendžiami.

c. Tai lengva suprasti, nes tikslas paprastas – atlikti reikiamus veiksmus.

d. Tai paprasta ir lengva naudoti, nes kūrimo procesas vyksta etapais.

e. Jai būdingas reikalavimų stabilumas.

f. Jame pateikiamas šablonas, į kurį galima įdėti metodus analizei, projektavimui, kodavimui, testavimui ir aprūpinimui atlikti.

g. Tai leidžia projekto dalyviams, baigusiems veiklą toje fazėje, kurią atlieka, dalyvauti kitų projektų įgyvendinime.

h. Jame apibrėžiamos kokybės kontrolės procedūros. Visi gauti duomenys yra peržiūrimi. Šią procedūrą kūrimo komanda naudoja sistemos kokybei nustatyti.

i. Projekto eigą galima lengvai sekti naudojant laiko juostą (Ganto diagramą), nes kiekvienos fazės užbaigimo taškas naudojamas kaip etapas.

Kaskadinio modelio trūkumai.

Naudojant krioklio modelį projektui, kuris jam sunkiai tinka, atsiranda šie trūkumai:

a. Modelis pagrįstas nuoseklia linijine struktūra, todėl bandant grįžti vieną ar dvi fazes atgal, kad būtų ištaisyta problema ar trūkumas, labai padidės sąnaudos ir sutrinka tvarkaraštis.

b. Klientas ne visada turi galimybę iš anksto susipažinti su sistema tai atsitinka tik pačioje gyvavimo ciklo pabaigoje.

c. Klientas neturi galimybės pasinaudoti tarpiniais rezultatais, o vartotojų atsiliepimai negali būti grąžinti kūrėjams. Kadangi gatavas produktas nepasiekiamas iki proceso pabaigos, vartotojas į procesą įtraukiamas tik pačioje pradžioje – reikalavimų rinkimo metu, o pabaigoje – priėmimo testavimo metu.

d. Kiekviena fazė yra būtina sąlyga tolesniems veiksmams, todėl šis metodas yra rizikingas pasirinkimas neprilygstančioms sistemoms, nes jo negalima lanksčiai modeliuoti.

e. Kiekvienai fazei sukuriami išvesties duomenys, kurie pasibaigus laikomi užšaldytais. Tai reiškia, kad jie neturėtų keistis vėlesniais gaminio gyvavimo ciklo etapais. Jei etapo pateikiamų duomenų elementas pasikeis, grafiko pakeitimas neigiamai paveiks projektą, nes nei modelis, nei planas nebuvo sukurti taip, kad būtų pritaikytas ir išspręstas pakeitimas vėliau gyvavimo ciklo metu.

f. Visi reikalavimai turėtų būti žinomi gyvavimo ciklo pradžioje, tačiau klientai ne visada gali suformuluoti visus aiškiai apibrėžtus reikalavimus šiuo kūrimo momentu.

Nors krioklys yra universalus ir gali būti pritaikytas bet kokiam projektui, kiti gyvavimo ciklo modeliai gali būti efektyvesni ir efektyvesni, atsižvelgiant į projekto ypatybes. Pavyzdžiui, jei įdiegiate programinės įrangos paketą, praleidžiate projektavimo ir diegimo etapus. Taip pat, jei dirbate kūrimo darbus, galbūt norėsite naudoti konkretų MTEP projekto gyvavimo ciklo modelį, kuriame atsižvelgiama į tai, kad atliktas darbas arba dalis jo gali patekti į šiukšliadėžę. Kiti svarbūs gyvavimo ciklo modeliai gali būti naudojami tam tikrų tipų projektams pagreitinti. Pavyzdžiui, informacinių technologijų projektuose dažnai naudojamas iteracinis arba greitas (Agile) vystymas.

Žemiau yra keletas kitų projekto gyvavimo ciklo modelių:

Iteratyvus požiūris(angl. iteration – repetition) – darbų atlikimas lygiagrečiai su nuolatine gautų rezultatų analize ir koreguojant ankstesnius darbo etapus. Taikant šį metodą, projektas kiekviename kūrimo etape pereina pasikartojantį ciklą: planavimas – įgyvendinimas – tikrinimas – vertinimas (ciklas planuoti – daryk – patikrink – veik).

Iteratyvaus metodo pranašumai:

1. sumažinti rimtų rizikų poveikį ankstyvosiose projekto stadijose, o tai leidžia sumažinti jų pašalinimo išlaidas;

2. efektyvaus grįžtamojo ryšio iš projekto komandos vartotojui (taip pat klientams, suinteresuotosioms šalims) organizavimas ir realiai jų poreikius atitinkančio produkto kūrimas;

3. pastangų sutelkimas į svarbiausias ir kritiškiausias projekto sritis;

4. nuolatinis kartotinis testavimas, leidžiantis įvertinti viso projekto sėkmę kaip visumą;

5. ankstyvas prieštaravimų tarp reikalavimų, modelių ir 6.projekto įgyvendinimo nustatymas;

8. efektyvus sukauptos patirties panaudojimas;

9. realus esamos projekto būklės įvertinimas ir dėl to didesnis klientų ir tiesioginių dalyvių 10. pasitikėjimas sėkmingu projekto įgyvendinimu.

Spiralinio projekto gyvavimo ciklo modelis. Šis modelis tiria projekto efektyvumo priklausomybę nuo jo sąnaudų laikui bėgant. Prie kiekvieno spiralės posūkio sukuriamas kitas gaminio variantas, patikslinami projekto reikalavimai, nustatoma jo kokybė, planuojamas kito posūkio darbas.

Pirmą kartą spiralinį modelį suformulavo Barry Boehm 1988 m. Išskirtinis šio modelio bruožas – ypatingas dėmesys rizikai, turinčiai įtakos gyvavimo ciklo organizavimui. Boehm suformuluoja labiausiai paplitusių (pagal prioritetą) pavojų „10 geriausių“.

1. Specialistų trūkumas.

2. Nerealūs terminai ir biudžetas.

3. Netinkamo funkcionalumo įdiegimas.

4. Netinkamos vartotojo sąsajos projektavimas.

5. „Auksinis stalo serviravimas“, perfekcionizmas, nereikalingas optimizavimas ir detalių šlifavimas.

6. Nuolatinis pokyčių srautas.

7. Trūksta informacijos apie išorinius komponentus, kurie apibrėžia sistemos aplinką arba dalyvauja integracijoje.

8. Išoriniais (projekto atžvilgiu) resursais atliekamų darbų trūkumai.

9. Nepakankamas gautos sistemos veikimas.

10. Įvairių žinių sričių specialistų kvalifikacijos „spraga“.

Dauguma šių rizikų yra susijusios su projekto komandos specialistų sąveikos organizaciniais ir proceso aspektais.

Kiekvienas spiralės posūkis atitinka programinės įrangos fragmento ar versijos sukūrimą, kur išsiaiškinami projekto tikslai ir charakteristikos, nustatoma jo kokybė, suplanuojami kito spiralės posūkio darbai. Tokiu būdu gilinamos ir nuosekliai patikslinamos projekto detalės, o to pasekoje parenkamas pagrįstas variantas, kuris nukreipiamas į įgyvendinimą. Kiekvienas posūkis yra padalintas į 4 sektorius:

rizikos vertinimas ir sprendimas,

tikslų apibrėžimas,

kūrimas ir bandymai,

planavimas.

Spiralinis modelis skirtas dideliems, brangiems ir sudėtingiems projektams.

Spiralinio modelio privalumai:

Naudojant spiralinį modelį projekte, kuriam jis puikiai tinka, atsiranda šie pranašumai:

a Spiralinis modelis leidžia vartotojams „pamatyti“ sistemą anksti, naudojant greitą prototipų kūrimą projekto kūrimo cikle.

b Leidžia mažomis sąnaudomis nustatyti neįveikiamą riziką.

c Modelis leidžia vartotojams aktyviai dalyvauti planavimo, rizikos analizės, projektavimo ir vertinimo veikloje.

d Tai užtikrina, kad didelis potencialus produkto kūrimo darbų kiekis būtų suskirstytas į mažas dalis.

e Modelis leidžia sukurti lankstų dizainą, nes išreiškia krioklio modelio pranašumus ir leidžia kartoti visas to paties modelio fazes.

f Realizuojami prieauginio modelio pranašumai, būtent prieaugių išleidimas, grafiko sumažinimas persidengiant prieaugiais ir išteklių nekintamumas sistemai palaipsniui augant.

Spiralinio modelio trūkumai:

Naudojant spiralinį modelį projekte, kuriam jis netinkamas, atsiranda šie trūkumai:

a Spiralė gali tęstis neribotą laiką.

b Dėl didelio tarpinių etapų skaičiaus gali prireikti tvarkyti vidinius papildomus ir išorinius dokumentus.

c Modelio naudojimas gali būti brangus, nes gali būti per daug laiko, praleisto planuojant, iš naujo apibrėžiant tikslus, rizikos analizę ir kuriant prototipus.

Prieauginis projekto ciklo modelis.Šis modelis dažniausiai naudojamas atliekant sudėtingus plėtros darbus, kuriems reikalingas didelis dalyvių skaičius ir daug įvairių problemų, kurias reikia išspręsti. Jo esmė yra suskaidyti didelį darbo kiekį į mažesnių sudedamųjų dalių seką. Tai procesas, kai dalinai įdiegiama visa sistema ir lėtai didėja funkcionalumas ar efektyvumas.

Šis modelis apima projekto gyvavimo ciklo suskaidymą į iteracijų seką, kurių kiekviena primena „mini projektą“, įskaitant visas gyvavimo ciklo fazes, taikomas kuriant mažesnius funkcionalumo elementus, palyginti su visu projektu. Kiekvienos iteracijos tikslas – gauti veikiančią programinės įrangos sistemos versiją, apimančią funkcionalumą, apibrėžtą visų ankstesnių ir dabartinių iteracijų integruoto turinio. Galutinės iteracijos rezultatuose yra visos reikalingos gaminio funkcijos.

Inkrementinio modelio privalumai.

Naudodami prieauginį modelį kurdami projektą, kuriam jis yra pakankamai tinkamas, galite įsitikinti šiais pranašumais:

a Nereikia leisti pinigų iš anksto, kad būtų sukurtas visas projektas.

b Dėl kiekvieno prieaugio gaunamas funkcinis produktas.

c Naudodamiesi nuosekliais žingsniais, naudotojo patirtį galima sujungti į patobulintą produktą už nedidelę naujo kūrimo išlaidų dalį.

d „Skaldyk ir valdyk“ taisyklė leidžia suskaidyti problemą į valdomas dalis, o tai neleidžia kūrimo komandai sudaryti sudėtingų reikalavimų sąrašų.

e Vykdydami kūrimo procesą galite apriboti darbuotojų skaičių, kad ta pati komanda nuolat dirbtų kiekvieną priedą.

f Kiekvieno papildomo pristatymo pabaigoje yra galimybė iš naujo įvertinti riziką, susijusią su išlaidomis ir nustatyto grafiko laikymusi.

g Kadangi perėjimas iš dabarties į ateitį neįvyksta akimirksniu, klientas prie naujos technologijos gali priprasti palaipsniui.

h Rizika paskirstoma keliais mažesniais žingsniais ir nėra sutelkta viename dideliame plėtros projekte.

Inkrementinio modelio trūkumai.

Naudojant šį modelį projektui, kuriam jis nėra pakankamai tinkamas, atsiranda šie trūkumai:

a Modelis neleidžia kartoti kiekvieno žingsnio.

b Visa funkcinė sistema turėtų būti apibrėžiama gyvavimo ciklo pradžioje, siekiant užtikrinti, kad būtų galima apibrėžti priedus.

c Klientas turi žinoti, kad bendros projekto užbaigimo išlaidos nesumažės.

Programinės įrangos gyvavimo ciklo standartai

• GOST 34.601-90
• ISO/IEC 12207:1995 (rusiškas atitikmuo – GOST R ISO/IEC 12207-99)

Programinės įrangos kūrimo metodikos

• Racionalus vieningas procesas (RUP).
• „Microsoft Solutions Framework“ (MSF). Apima 4 fazes: analizę, projektavimą, kūrimą, stabilizavimą, apima objektinio modeliavimo naudojimą.
• Ekstremalus programavimas ( Ekstremalus programavimas, XP). Metodika paremta komandiniu darbu ir efektyviu bendravimu tarp užsakovo ir rangovo viso IP kūrimo projekto metu. Kūrimas vykdomas naudojant paeiliui patobulintus prototipus.

Standartas GOST 34.601-90

GOST 34.601-90 standartas numato šiuos automatizuotos sistemos kūrimo etapus ir etapus:

1. Reikalavimų garsiakalbiams formavimas
   1. Objekto apžiūra ir atominės elektrinės kūrimo būtinumo pagrindimas
   2. Vartotojo reikalavimų garsiakalbiams formavimas
   3. Darbų atlikimo ataskaitos ir paraiškos AE plėtrai parengimas
2. AC koncepcijos kūrimas
   1. Objekto tyrinėjimas
   2. Būtinų tiriamųjų darbų atlikimas
   3. Kintamosios srovės koncepcijos variantų kūrimas ir vartotojo reikalavimus atitinkančios kintamosios srovės koncepcijos varianto parinkimas
   4. Atliktų darbų ataskaitos surašymas
3. Techninė užduotis
   1. Atominių elektrinių kūrimo techninių specifikacijų rengimas ir tvirtinimas
4. Preliminarus dizainas
   1. Sistemos ir jos dalių preliminaraus projektavimo sprendinių kūrimas
5. Techninis projektas
   1. Sistemos ir jos dalių projektinių sprendimų kūrimas
   2. Garsiakalbių sistemos ir jos dalių dokumentacijos kūrimas
   3. Komponentų tiekimo dokumentacijos kūrimas ir įforminimas
   4. Projektavimo užduočių rengimas gretimose projekto dalyse
6. Darbo dokumentacija
   1. AE ir jos dalių darbo dokumentacijos rengimas
   2. Programų kūrimas ir pritaikymas
7. Paleidimas eksploatuoti
   1. Automatikos objekto paruošimas
   2. Personalo mokymas
   3. Visas garsiakalbių komplektas su tiekiamais produktais (programine ir technine įranga, programine ir technine įranga, informaciniais produktais)
   4. Statybos ir montavimo darbai
   5. Paleidimo darbai
   6. Preliminarių testų atlikimas
   7. Bandomosios operacijos vykdymas
   8. Priėmimo testų atlikimas
8. AC palaikymas.
   1. Darbų atlikimas pagal garantinius įsipareigojimus
   2. Pogarantinis aptarnavimas

Eskizas, techniniai projektai ir darbo dokumentacija – tai nuoseklus vis tikslesnių projektinių sprendimų konstravimas. Visuose etapuose galima išskirti „Eskizo projektavimo“ etapą ir atskirus darbo etapus, „Techninio projekto“ ir „Darbo dokumentacijos“ etapus sujungti į „Techninį detalųjį projektą“, atlikti įvairius etapus ir dirbti lygiagrečiai. , ir įtraukti papildomų.

Šis standartas nėra visiškai tinkamas dabartiniams pokyčiams: daugelis procesų nėra pakankamai atspindėti, o kai kurios nuostatos yra pasenusios.

ISO/IEC 12207/ standartas ir jo taikymas

ISO/IEC 12207:1995 standartas „Informacinės technologijos – programinės įrangos gyvavimo ciklo procesai“ yra pagrindinis norminis dokumentas, reglamentuojantis programinės įrangos gyvavimo ciklo procesų sudėtį. Ji apibrėžia gyvavimo ciklo struktūrą, apimančią procesus, veiklą ir užduotis, kurios turi būti įvykdytos kuriant programinę įrangą.

Kiekvienas procesas yra padalintas į veiksmų rinkinį, kiekvienas veiksmas į užduočių rinkinį. Kiekvieną procesą, veiklą ar užduotį pagal poreikį inicijuoja ir vykdo kitas procesas, ir nėra iš anksto nustatytų vykdymo sekų. Ryšiai tarp įvesties duomenų išsaugomi.

Programinės įrangos gyvavimo ciklo procesai

• Pagrindiniai:
  • Įsigijimas (programinę įrangą perkančio kliento veiksmai ir užduotys)
  • Pristatymas (tiekėjo, tiekiančio klientui programinės įrangos produktą ar paslaugą, veiksmai ir užduotys)
  • Kūrimas (kūrėjo atliekami veiksmai ir užduotys: programinės įrangos kūrimas, projektavimas ir eksploatacinė dokumentacija, testų ir mokymo medžiagos paruošimas ir kt.)
  • Veikimas (operatoriaus – sistemą valdančios organizacijos – veiksmai ir užduotys)
  • Priežiūra (lydinčiosios organizacijos, tai yra pagalbos tarnybos, atliekami veiksmai ir užduotys). Pagalba – programinės įrangos keitimas, siekiant ištaisyti klaidas, pagerinti produktyvumą arba prisitaikyti prie pasikeitusių veiklos sąlygų ar reikalavimų.
• Pagalbinis
  • Dokumentacija (formalizuotas informacijos, sukurtos per programinės įrangos gyvavimo ciklą, aprašymas)
  • Konfigūracijos valdymas (administracinių ir techninių procedūrų taikymas per visą programinės įrangos gyvavimo ciklą, siekiant nustatyti programinės įrangos komponentų būseną ir valdyti jos modifikacijas).
  • Kokybės užtikrinimas (garantijos, kad informacinė sistema ir jos gyvavimo ciklo procesai atitinka nustatytus reikalavimus ir patvirtintus planus)
  • Patikrinimas (nustatymas, kad programinės įrangos produktai, sukurti po tam tikro veiksmo, visiškai atitinka ankstesniais veiksmais keliamus reikalavimus ar sąlygas)
  • Sertifikavimas (nustatantis nurodytų reikalavimų ir sukurtos sistemos atitikties konkrečiam funkciniam tikslui išsamumą)
  • Bendras vertinimas (projekto darbų būklės įvertinimas: išteklių, personalo, įrangos, įrankių planavimo ir valdymo kontrolė)
  • Auditas (atitikties reikalavimams, planų ir sutarties sąlygų nustatymas)
  • Problemų sprendimas (problemų, neatsižvelgiant į jų kilmę ar šaltinį, aptinkamų kūrimo, eksploatavimo, priežiūros ar kitų procesų metu, analizė ir sprendimas)
• Organizacinis
  • Kontrolė (veiksmai ir užduotys, kurias gali atlikti bet kuri savo procesus valdanti šalis)
  • Infrastruktūros kūrimas (technologijų, standartų ir įrankių parinkimas ir priežiūra, aparatinės ir programinės įrangos, naudojamos programinei įrangai kurti, eksploatuoti ar prižiūrėti, parinkimas ir įdiegimas)
  • Tobulinimas (gyvavimo ciklo procesų įvertinimas, matavimas, kontrolė ir tobulinimas)
  • Mokymas (pradinis mokymas ir tolesnis nuolatinis personalo tobulinimas)

Kiekvienas procesas apima keletą veiksmų. Pavyzdžiui, įsigijimo procesas apima šias veiklas:

1. Įsigijimo inicijavimas
2. Pasiūlymų parengimas
3. Sutarties rengimas ir derinimas
4. Tiekėjų veiklos priežiūra
5. Darbų priėmimas ir užbaigimas

Kiekviena veikla apima keletą užduočių. Pavyzdžiui, rengiant pasiūlymų pasiūlymus turėtų būti:

1. Sistemos reikalavimų formavimas
2. Programinės įrangos produktų sąrašo generavimas
3. Sąlygų ir susitarimų nustatymas
4. Techninių apribojimų aprašymas (sistemos veikimo aplinka ir kt.)

Programinės įrangos gyvavimo ciklo etapai, procesų ir etapų santykiai

Programinės įrangos gyvavimo ciklo modelis- struktūra, kuri nustato vykdymo seką ir ryšius tarp procesų, veiksmų ir užduočių per visą gyvavimo ciklą. Gyvavimo ciklo modelis priklauso nuo projekto specifikos, masto ir sudėtingumo bei konkrečių sąlygų, kuriomis sistema kuriama ir veikia.

GOST R ISO/IEC 12207-99 standartas nesiūlo konkretaus gyvavimo ciklo modelio. Jos nuostatos yra bendros visiems gyvavimo ciklo modeliams, metodams ir technologijoms kuriant IP. Jame aprašoma gyvavimo ciklo procesų struktūra, nenurodant, kaip įgyvendinti ar užbaigti į tuos procesus įtrauktas veiklas ir užduotis.

Programinės įrangos gyvavimo ciklo modelis apima:

1. Etapai;
2. Kiekvieno etapo darbo rezultatai;
3. Pagrindiniai įvykiai yra darbo užbaigimo ir sprendimų priėmimo taškai.

Scena- programinės įrangos kūrimo proceso dalis, apribota tam tikru terminu ir baigiasi konkretaus produkto (modelių, programinės įrangos komponentų, dokumentacijos) išleidimu, nulemta šiam etapui nustatytų reikalavimų.

Kiekviename etape gali būti atliekami keli procesai, apibrėžti GOST R ISO/IEC 12207-99 standarte, ir atvirkščiai, tas pats procesas gali būti atliekamas skirtinguose etapuose. Santykį tarp procesų ir etapų taip pat lemia naudojamas programinės įrangos gyvavimo ciklo modelis.

Programinės įrangos gyvavimo ciklo modeliai

Gyvavimo ciklo modelis yra struktūra, apibrėžianti procesų, veiksmų ir užduočių, atliekamų per visą gyvavimo ciklą, vykdymo seką ir ryšius. Gyvavimo ciklo modelis priklauso nuo informacinės sistemos specifikos ir konkrečių sąlygų, kuriomis pastaroji sukuriama ir veikia

Iki šiol labiausiai paplitę šie pagrindiniai gyvavimo ciklo modeliai:

• Probleminis modelis;

• kaskadinis modelis (arba sistema) (70-85);

• spiralinis modelis (dabar).

Probleminis modelis

Kuriant sistemą „iš apačios į viršų“ nuo atskirų užduočių iki visos sistemos (užduočių modelio), neišvengiamai prarandamas vieningas požiūris į plėtrą, kyla problemų dėl atskirų komponentų informacinio ryšio. Paprastai, didėjant užduočių skaičiui, sunkumai didėja, todėl reikia nuolat keisti esamas programas ir duomenų struktūras. Sulėtėja sistemos vystymosi greitis, o tai stabdo ir pačios organizacijos vystymąsi. Tačiau kai kuriais atvejais ši technologija gali būti patartina:

• Ypatinga skuba (problemas reikia kažkaip išspręsti; tada viską teks daryti iš naujo);

• Kliento eksperimentavimas ir pritaikymas (algoritmai neaiškūs, sprendimai randami bandymų ir klaidų būdu).

Bendra išvada – tokiu būdu sukurti pakankamai didelės, efektyvios informacinės sistemos neįmanoma.

Kaskadinis modelis

Kaskadinis modelis gyvavimo ciklą 1970 metais pasiūlė Winstonas Royce'as. Jame numatytas nuoseklus visų projekto etapų įgyvendinimas griežtai nustatyta tvarka. Perėjimas į kitą etapą reiškia visišką ankstesnio etapo darbų užbaigimą (1 pav.). Reikalavimų formavimo etape nustatyti reikalavimai yra griežtai dokumentuojami techninių specifikacijų forma ir registruojami visam projekto vystymui. Kiekvienas etapas baigiasi išleidžiant visą dokumentų rinkinį, kurio pakanka, kad kūrimą galėtų tęsti kita kūrimo komanda.

Teigiami kaskadinio metodo naudojimo aspektai yra šie:

• kiekviename etape sukuriamas visas projektinės dokumentacijos rinkinys, atitinkantis išsamumo ir nuoseklumo kriterijus;

• logiška seka atliekami darbų etapai leidžia planuoti visų darbų atlikimo laiką ir atitinkamas išlaidas.

Projekto etapai pagal krioklio modelį:

1. Reikalavimų formavimas;
2. Dizainas;
3. Įgyvendinimas;
4. Testavimas;
5. Įgyvendinimas;
6. Eksploatavimas ir priežiūra.

Ryžiai. 1. Kaskados kūrimo schema

Kaskadinis metodas puikiai pasiteisino kuriant informacines sistemas, kurioms pačioje kūrimo pradžioje visi reikalavimai gali būti gana tiksliai ir iki galo suformuluoti, kad kūrėjams būtų suteikta laisvė jas kuo geriau įgyvendinti techniniu požiūriu. peržiūrėti. Į šią kategoriją patenka sudėtingos skaičiavimo sistemos, realaus laiko sistemos ir kitos panašios užduotys. Tačiau taikant šį metodą buvo aptikta keletas jo trūkumų, pirmiausia dėl to, kad tikrasis sistemų kūrimo procesas niekada visiškai netelpa į tokią griežtą schemą. Kūrimo proceso metu nuolat reikėjo grįžti į ankstesnius etapus ir patikslinti ar peržiūrėti anksčiau priimtus sprendimus. Dėl to tikrasis programinės įrangos kūrimo procesas įgavo tokią formą (2 pav.):

Ryžiai. 2. Realus programinės įrangos kūrimo procesas naudojant krioklio schemą

Pagrindinis kaskadinio metodo trūkumas yra didelis vėlavimas gauti rezultatus. Rezultatų derinimas su vartotojais vykdomas tik taškuose, kurie suplanuoti baigus kiekvieną darbo etapą, reikalavimai informacinėms sistemoms „įšaldomi“ techninių specifikacijų pavidalu visam jos sukūrimo laikui. Taigi vartotojai gali pateikti savo pastabas tik visiškai užbaigus darbą su sistema. Jei reikalavimai pateikiami netiksliai arba jie keičiasi per ilgą programinės įrangos kūrimo laikotarpį, vartotojai gauna sistemą, kuri neatitinka jų poreikių. Automatizuoto objekto modeliai (tiek funkciniai, tiek informaciniai) gali pasenti kartu su jų patvirtinimu. Sisteminio požiūrio į IS kūrimą esmė slypi jos skaidyme (suskirstyme) į automatizuotas funkcijas: sistema suskirstoma į funkcines posistemes, kurios savo ruožtu skirstomos į subfunkcijas, suskirstomos į užduotis ir pan. Padalijimo procesas tęsiasi iki konkrečių procedūrų. Tuo pačiu metu automatizuota sistema palaiko holistinį vaizdą, kuriame visi komponentai yra tarpusavyje susiję. Taigi pagrindinis šio modelio pranašumas yra sistemingas tobulinimas, o pagrindiniai trūkumai – lėtas ir brangus.

Spiralinis modelis

Siekiant išspręsti šias problemas, buvo pasiūlyta spiralinis modelis gyvavimo ciklas (3 pav.), kurį devintojo dešimtmečio viduryje sukūrė Barry Boehm. Jis pagrįstas pradiniais gyvavimo ciklo etapais: analize ir projektavimu. Šiuose etapuose, kuriant prototipus, išbandomas techninių sprendimų pagrįstumas.

Prototipas- veikiantis programinės įrangos komponentas, įgyvendinantis atskiras funkcijas ir išorines sąsajas. Kiekviena iteracija atitinka programinės įrangos fragmento ar versijos sukūrimą, kurio metu išsiaiškinami projekto tikslai ir charakteristikos, įvertinama gautų rezultatų kokybė ir planuojamas kitos iteracijos darbas.

Kiekviena iteracija reiškia visą kūrimo ciklą, dėl kurio išleidžiama vidinė arba išorinė produkto versija (arba galutinio produkto poaibis), kuri patobulinama nuo iteracijos iki iteracijos, kad taptų visa sistema.

Kiekvienas spiralės posūkis atitinka programinės įrangos fragmento ar versijos sukūrimą, kur išsiaiškinami projekto tikslai ir charakteristikos, nustatoma jo kokybė, suplanuojami kito spiralės posūkio darbai. Taip gilinamos ir nuosekliai patikslinamos projekto detalės, todėl parenkamas pagrįstas variantas, kuris yra įgyvendinamas.

Plėtra iteracijomis atspindi objektyviai egzistuojantį sistemos kūrimo spiralinį ciklą. Neužbaigtas kiekvieno etapo darbų atlikimas leidžia pereiti į kitą etapą, nelaukiant, kol bus baigti darbai dabartiniame. Taikant kartotinį kūrimo metodą, trūkstamą darbą galima atlikti kitoje iteracijoje. Pagrindinė užduotis – sistemos naudotojams kuo greičiau parodyti veikiantį produktą, taip suaktyvinant reikalavimų išaiškinimo ir papildymo procesą.

Pagrindinė spiralinio ciklo problema yra perėjimo į kitą etapą momento nustatymas. Norint ją išspręsti, būtina įvesti laiko apribojimus kiekvienam gyvavimo ciklo etapui. Perėjimas vyksta taip, kaip planuota, net jei ne visi suplanuoti darbai atlikti. Planas sudaromas remiantis statistiniais duomenimis, gautais ankstesniuose projektuose ir asmenine vystytojų patirtimi.

3 pav. IC gyvavimo ciklo spiralinis modelis

Vienas iš galimų spiralinio gyvavimo ciklo modelio programinės įrangos kūrimo būdų yra pastaruoju metu plačiai paplitusi RAD (Rapid Application Development) metodika. Šis terminas paprastai reiškia programinės įrangos kūrimo procesą, kurį sudaro 3 elementai:

• nedidelę programuotojų komandą (nuo 2 iki 10 žmonių);

• trumpas, bet kruopščiai parengtas gamybos grafikas (nuo 2 iki 6 mėnesių);

• pasikartojantis ciklas, kurio metu kūrėjai, kai programa pradeda formuotis, reikalauja ir produkte įgyvendina reikalavimus, gautus sąveikaujant su klientu.

Programinės įrangos gyvavimo ciklas pagal RAD metodiką susideda iš keturių fazių:

• reikalavimų apibrėžimo ir analizės etapas;

• projektavimo etapas;

• įgyvendinimo etapas;

• įgyvendinimo etapas.

Kiekvienoje iteracijoje įvertinama:

• projekto terminų ir išlaidų viršijimo rizika;
• poreikis atlikti kitą iteraciją;
• sistemos reikalavimų supratimo išsamumo ir tikslumo laipsnis;
• projekto nutraukimo galimybė.

Iteratyvaus metodo pranašumai:

• Iteratyvus vystymas labai supaprastina projekto pakeitimus, kai keičiasi klientų reikalavimai.
• Naudojant spiralinį modelį, atskiri informacinės sistemos elementai palaipsniui integruojami į vientisą visumą. Taikant iteracinį metodą, integracija vyksta praktiškai nuolat. Kadangi integracija prasideda nuo mažiau elementų, ją įgyvendinant kyla daug mažiau problemų (kai kuriais vertinimais, naudojant krioklio plėtros modelį, integracija projekto pabaigoje sudaro iki 40 proc. visų išlaidų).
• Iteratyvus vystymas suteikia didesnį projektų valdymo lankstumą, todėl galima atlikti taktinius kuriamo produkto pakeitimus.
• Iteratyvus metodas supaprastina pakartotinį komponentų naudojimą (diegia komponentais pagrįstą programavimo metodą). Taip yra todėl, kad daug lengviau nustatyti bendras projekto dalis, kai jos jau iš dalies sukurtos, nei bandyti jas identifikuoti pačioje projekto pradžioje. Išanalizavus dizainą po kelių pradinių iteracijų, atsiranda bendrų daugkartinio naudojimo komponentų, kurie bus patobulinti vėlesnių iteracijų metu.
• Spiralinis modelis leidžia sukurti patikimesnę ir stabilesnę sistemą. Taip yra todėl, kad sistemai tobulėjant, kiekvienos iteracijos metu aptinkamos ir ištaisomos klaidos ir trūkumai. Tuo pačiu galima koreguoti kritinius efektyvumo parametrus, o tai kaskadinio modelio atveju įmanoma tik prieš įdiegiant sistemą.
• Iteratyvus metodas leidžia tobulinti kūrimo procesą – kiekvienos iteracijos pabaigoje atlikta analizė leidžia įvertinti, ką reikia keisti kūrimo organizacijoje ir patobulinti kitoje iteracijoje.

3.2. Kaskados strategija

Kaskados strategija (vienkartinis praėjimas, krioklys arba klasikinis modelis) reiškia linijinę informacinės sistemos kūrimo etapų vykdymo seką (3.1 pav.). Kitaip tariant, perėjimas iš vieno etapo į kitą įvyksta tik visiškai užbaigus esamą darbą.

3.1 pav. Kaskados strategija

Šis modelis naudojamas kuriant informacines sistemas, kurioms jau pačioje kūrimo pradžioje galima gana tiksliai ir visiškai suformuluoti visus reikalavimus.

Modelio privalumai:

Kiekviename etape sukuriamas visas dokumentacijos, programinės ir techninės įrangos komplektas, atitinkantis išsamumo ir nuoseklumo kriterijus;

Aiškia seka atliekami etapai leidžia užtikrintai planuoti darbų laiką ir atitinkamus išteklius (piniginius, materialinius ir žmogiškuosius).

Modelio trūkumai:

Tikrasis informacinės sistemos kūrimo procesas retai visiškai patenka į tokią griežtą schemą. Tai ypač pasakytina apie netipinių ir naujoviškų sistemų kūrimą;

Remiantis tikslia pradinių reikalavimų informacinei sistemai suformulavimu. Realiai projekto pradžioje užsakovo reikalavimai apibrėžiami tik iš dalies;

Pagrindinis trūkumas yra tas, kad plėtros rezultatai užsakovui prieinami tik projekto pabaigoje. Jeigu reikalavimai yra nurodyti netiksliai arba jie keičiasi per ilgą IP kūrimo laikotarpį, klientas gauna jo poreikių neatitinkančią sistemą.

3.3. Inkrementinė strategija

Inkrementinė strategija (angl. increment) reiškia informacinės sistemos kūrimą su linijine etapų seka, bet keliais žingsniais (versijomis), t.y. su planuojamu produkto tobulinimu.

3.2 pav. Inkrementinė strategija

Darbo su projektu pradžioje nustatomi visi pagrindiniai sistemos reikalavimai, po kurių ji kuriama versijų sekos pavidalu. Be to, kiekviena versija yra pilnas ir funkcionalus produktas. Pirmoje versijoje įgyvendinama dalis suplanuotų galimybių, kitoje – papildomos galimybės ir t.t., kol bus pasiekta visa sistema.

Šis gyvavimo ciklo modelis būdingas kuriant sudėtingas ir integruotas sistemas, kurioms yra aiški vizija (tiek iš užsakovo, tiek iš kūrėjo pusės), koks turi būti galutinis rezultatas (informacinė sistema). Versija kuriama dėl įvairių priežasčių:

Užsakovas neturi galimybės finansuoti viso brangaus projekto iš karto;

Vystytojui trūksta reikiamų resursų kompleksiniam projektui įgyvendinti per trumpą laiką;

Reikalavimai, kad galutiniai vartotojai laipsniškai diegtų ir priimtų produktą. Visos sistemos įdiegimas vienu metu gali sukelti jos vartotojų atmetimą ir tik „sulėtinti“ perėjimo prie naujų technologijų procesą. Vaizdžiai tariant, jie gali tiesiog „nesuvirškinti didelio gabalo, todėl jį reikia supjaustyti ir dalyti dalimis“.

Privalumai Ir trūkumai Ši strategija yra tokia pati kaip ir klasikinė. Tačiau skirtingai nuo klasikinės strategijos, klientas rezultatus gali pamatyti anksčiau. Remdamasis pirmosios versijos kūrimo ir diegimo rezultatais, jis gali šiek tiek pakeisti kūrimo reikalavimus, jo atsisakyti arba pasiūlyti sukurti pažangesnį produktą sudaręs naują sutartį.

3.4. Spiralinė strategija

Spiralinė strategija (evoliucinis arba kartotinis modelis, Barry Boehm, 1988) apima kūrimą versijų seka, tačiau ne visi reikalavimai yra apibrėžti projekto pradžioje. Kuriant versijas, reikalavimai tobulinami.

Ryžiai. 3.3. Spiralinė strategija

Šis gyvavimo ciklo modelis būdingas novatoriškų (nestandartinių) sistemų kūrimui. Darbo su projektu pradžioje užsakovas ir kūrėjas neturi aiškios galutinio produkto vizijos (negali būti aiškiai apibrėžti reikalavimai) arba šimtaprocentinio pasitikėjimo sėkmingu projekto įgyvendinimu (rizika labai didelė). Atsižvelgiant į tai, priimamas sprendimas plėtoti sistemą dalimis su galimybe keisti reikalavimus arba atsisakyti tolesnės jos plėtros. Kaip matyti iš 3.3 pav., projekto vystymas gali būti baigtas ne tik po įgyvendinimo, bet ir po rizikos analizės etapo.

Modelio privalumai:

Leidžia greitai parodyti sistemos naudotojams veikiantį produktą, taip suaktyvinant reikalavimų paaiškinimo ir papildymo procesą;

Leidžia keisti reikalavimus kuriant informacinę sistemą, kuri būdinga daugumai patobulinimų, įskaitant standartinius;

Suteikia didesnį projektų valdymo lankstumą;

Leidžia gauti patikimesnę ir stabilesnę sistemą. Sistemai tobulėjant, kiekvienos iteracijos metu aptinkamos ir ištaisomos klaidos ir trūkumai;

Leidžia tobulinti kūrimo procesą – kiekvienoje iteracijoje atliekama analizė leidžia įvertinti, ką reikia keisti kūrimo organizacijoje ir patobulinti kitoje iteracijoje;

Sumažėja klientų rizika. Klientas gali užbaigti neperspektyvaus projekto vystymą su minimaliais finansiniais nuostoliais.

Modelio trūkumai:

Didėja vystytojo neapibrėžtumas dėl projekto plėtros perspektyvų. Šis trūkumas išplaukia iš ankstesnio modelio pranašumo;

Viso projekto laiko ir išteklių planavimo operacijos yra sudėtingos. Norint išspręsti šią problemą, būtina įvesti laiko apribojimus kiekvienam gyvavimo ciklo etapui. Perėjimas vyksta taip, kaip planuota, net jei ne visi suplanuoti darbai atlikti. Planas sudaromas remiantis ankstesniuose projektuose gautais statistiniais duomenimis ir asmenine kūrėjų patirtimi.

3.5. Lyginamoji modelių analizė

Įvairių gyvavimo ciklo modelių išmanymas ir gebėjimas juos pritaikyti praktikoje yra būtinos bet kuriam projektų vadovui. Teisingas modelio pasirinkimas leidžia kompetentingai planuoti finansavimo dydį, laiką ir išteklius, reikalingus darbams atlikti, sumažinant tiek kūrėjo, tiek užsakovo rizikas. Tai padeda didinti kūrėjų autoritetą (įvaizdį) užsakovo akyse ir, savo ruožtu, įtakoja tolesnio bendradarbiavimo su juo ir kitais klientais perspektyvas. Klaidinga manyti, kad spiralinis modelis yra geresnis už kitus. Juk kiekvienam projektui sudaroma atskira sutartis su tam tikra kaina. Klientas niekada nesudarys sutarties dėl didelės sumos su neaiškiu galutiniu rezultatu (nebent jis būtų altruistas). Tokiu atveju jis pasiūlys iš pradžių investuoti nedidelę sumą į projektą ir, remdamasis pirmosios versijos (iteracijos) rezultatais, nuspręs dėl papildomos sistemos kūrimo sutarties sudarymo.

Kiekvienas iš modelių turi savo privalumų ir trūkumų, taip pat pritaikymo sritis, priklausomai nuo kuriamos sistemos specifikos, užsakovo ir kūrėjo galimybių ir kt. Lentelė. 3.1 pateikiamas lyginamasis aukščiau aptartų modelių aprašymas, kuris turėtų padėti pasirinkti konkretaus projekto strategiją.

3.1 lentelė. Gyvenimo ciklo modelių palyginimas

Charakteristika projektą	Modelis (strategija)
Plėtros naujumas ir išteklių prieinamumas	Tipiškas. Gerai išvystyta technologija ir problemos sprendimo būdai		Netipiškas (novatoriškas). Netradicinis kūrėjui
	Užsakovo ir kūrėjo išteklių pakanka projektui įgyvendinti per trumpą laiką	Projektui įgyvendinti per trumpą laiką neužtenka užsakovo ar kūrėjo resursų
Projekto apimtis	Maži ir vidutiniai projektai	Vidutiniai ir dideli projektai	Bet kokie projektai
Projekto terminai	Iki metų	Iki kelių metų. Vienos versijos kūrimas gali užtrukti nuo kelių savaičių iki metų
Atskirų sutarčių sudarymas atskiroms versijoms	Sudaroma viena sutartis. Versija yra galutinis projekto rezultatas	Atskira sutartis paprastai sudaroma vienai versijai arba kelioms iš eilės versijoms
Pagrindinių reikalavimų apibrėžimas projekto pradžioje	Taip	Taip	Nr
Reikalavimai keičiasi vystantis projektui	Nr	Nepilnametis	Taip
Kūrimas pagal iteracijas (versijos)	Nr	Taip	Taip
Tarpinės programinės įrangos platinimas	Nr	Gal būt	Taip

Lentelėje 3.1, reikšmės „Taip“ ir „Ne“ neturėtų būti laikomos griežtais reikalavimais. Pavyzdžiui, nedideli reikalavimų pasikeitimai vystant projektą, kai naudojamas krioklio modelis (pavyzdžiui, pridedant tam tikrų nenumatytų paslaugų funkcijų), nėra tokie reti ir, jei jie įgyvendinami, prisideda prie santykių tarp šalių gerinimo. Panašiai tarpinės programinės įrangos platinimas spiraliniame modelyje yra nereikalingas, o kartais net kenkia sistemos diegimo ir bandomojo veikimo procesui.

Kuriant sistemą galutinis produktas ir tarpinė programinė įranga turėtų būti suprantami taip:

- auditas (korekcinis arba eksperimentinis) – bet kokie operatyvūs programinės ir informacinės programinės įrangos, taip pat duomenų bazės pakeitimai, kurie šiuo metu nėra būtini perkėlimui į diegimo vietas ir yra susiję su klaidų pašalinimu ir tobulinimu;

- modifikacija – bet kokie programinės ir informacinės programinės įrangos, taip pat duomenų bazės operatyviniai pakeitimai, privalomi perkelti į diegimo vietas ir sukeliantys eksploatacinių charakteristikų pasikeitimą nekeičiant funkcijų (numatytų), taip pat pakeitimai, susiję su klaidų šalinimu ir tobulinimu;

- versija – bet kokie programinės įrangos ir informacinės programinės įrangos, taip pat duomenų bazės pakeitimai, privalomi perkelti į įgyvendinimo objektus, leidžiantys atlikti deklaruojamas ar papildomas funkcijas, taip pat užtikrinti perėjimą prie naujų operacinių sistemų ir informacinės aplinkos;

- plėtra (eilė) – planuojami informacinės sistemos pakeitimai, susiję su naujų funkcijų įdiegimu ir veiklos charakteristikų gerinimu, perėjimu į naują informacinę aplinką, naujų techninių priemonių rinkinių, naujų informacinių technologijų diegimu ir kt.

Pagal pirmiau pateiktą klasifikaciją galutinis bet kurio gyvavimo ciklo modelio produktas yra privaloma sistemos versija arba eilė. Plėtra eilėse būdinga laipsninei strategijai. Pataisymai ir pakeitimai turėtų būti laikomi tarpine programine įranga. Kaip minėta pirmiau, dažnas pataisymų ir modifikacijų platinimas galutiniams vartotojams (ypač tiems, kurie užsiima kita gamybos veikla) ​​yra nepageidautina. Atsižvelgiant į informacinių sistemų versijų pasikeitimą geležinkelių transporte, pakeitimai turėtų būti atliekami ne dažniau kaip kartą ar du per metus, o modifikacijos – ne dažniau kaip kartą per mėnesį.

3.6. Spiralinį modelį palaikančios metodikos

Šiuo metu yra keletas programinės įrangos kūrimo metodikų 1, kurias galima rekomenduoti naudojant spiralinio gyvavimo ciklo modelį. Garsiausios iš jų – greitojo taikomųjų programų kūrimo (RAD) ir ekstremalaus programavimo metodika (eXtreme Programming, XP – autorius Kent Beck, 1999).

3. Trumpai apibūdinkite metodikas ir.

Turėtume pradėti nuo apibrėžimoPrograminės įrangos gyvavimo ciklas(Programinės įrangos gyvavimo ciklo modelis) – tai laikotarpis, kuris prasideda nuo sprendimo sukurti programinės įrangos produktą priėmimo momento ir baigiasi tuo momentu, kai jis visiškai pašalinamas. Šis ciklas yra programinės įrangos kūrimo ir tobulinimo procesas.

Programinės įrangos gyvavimo ciklo modeliai

Gyvenimo ciklas gali būti pavaizduotas modelių pavidalu. Šiuo metu labiausiai paplitę yra:kaskados, Inkrementinis (laipsniškas modelis su tarpiniu valdymu ) Ir spiralėgyvavimo ciklo modeliai.

Kaskadinis modelis

Kaskadinis modelis(Anglų) krioklio modelis) yra programinės įrangos kūrimo proceso modelis, kurio gyvavimo ciklas atrodo kaip srautas, kuris nuosekliai pereina reikalavimų analizės ir projektavimo fazes. įgyvendinimas, testavimas, integravimas ir palaikymas.

Kūrimo procesas įgyvendinamas pagal užsakytą nepriklausomų žingsnių seką. Modelis numato, kad kiekvienas tolesnis veiksmas prasideda po to, kai ankstesnis veiksmas yra visiškai užbaigtas. Visuose modelio etapuose atliekami pagalbiniai ir organizaciniai procesai bei darbai, įskaitant projektų valdymą, kokybės vertinimą ir valdymą, patikrą ir sertifikavimą, konfigūracijos valdymą ir dokumentacijos kūrimą. Atlikus veiksmus, susidaro tarpiniai produktai, kurių negalima pakeisti tolesniuose etapuose.

Gyvenimo ciklas tradiciškai skirstomas į šiuos pagrindiniusetapai:

1. Reikalavimų analizė,
2. Dizainas,
3. kodavimas (programavimas),
4. Testavimas ir derinimas,
5. Eksploatavimas ir priežiūra.

Modelio privalumai:

• reikalavimų stabilumas per visą plėtros gyvavimo ciklą;
• kiekviename etape sukuriamas visas projektinės dokumentacijos rinkinys, atitinkantis išsamumo ir nuoseklumo kriterijus;
• modelio žingsnių tikrumas ir aiškumas bei jo taikymo paprastumas;
• logiška seka atliekami darbų etapai leidžia planuoti visų darbų atlikimo laiką ir atitinkamus išteklius (piniginius, materialinius ir žmogiškuosius).

Modelio trūkumai:

• sunku aiškiai suformuluoti reikalavimus ir neįmanoma jų dinamiškai keisti per visą gyvavimo ciklą;
• mažas projektų valdymo lankstumas;
• linijinės kūrimo proceso struktūros nuoseklumas, dėl to grįžtant prie ankstesnių žingsnių sprendžiant kylančias problemas didėja išlaidos ir sutrinka darbo grafikas;
• tarpinio produkto netinkamumas naudoti;
• galimybės lanksčiai modeliuoti unikalias sistemas;
• Pavėluotas surinkimo problemų aptikimas dėl visų rezultatų vienu metu integravimo kūrimo pabaigoje;
• nepakankamas vartotojo dalyvavimas kuriant sistemą – pačioje pradžioje (reikalavimų rengimo metu) ir pabaigoje (priėmimo testų metu);
• vartotojai negali būti tikri dėl kuriamo produkto kokybės, kol nebaigtas visas kūrimo procesas. Jie neturi galimybės įvertinti kokybės, nes neįmanoma pamatyti gatavo kūrimo produkto;
• vartotojas neturi galimybės palaipsniui priprasti prie sistemos. Mokymosi procesas vyksta gyvavimo ciklo pabaigoje, kai programinė įranga jau pradėta eksploatuoti;
• kiekviena fazė yra būtina sąlyga tolesniems veiksmams, todėl šis metodas yra rizikingas pasirinkimas sistemoms, kurios neturi analogų, nes ji nepritaikyta lanksčiam modeliavimui.

Kaskados gyvavimo ciklo modelį sunku įgyvendinti dėl sudėtingo programinės įrangos sistemos kūrimo negrįžtant prie ankstesnių žingsnių ir nekeičiant jų rezultatų, kad būtų pašalintos kylančios problemos.

Kaskados modelio taikymo sritis

Kaskadinio modelio taikymo srities apribojimą lemia jo trūkumai. Jo naudojimas yra veiksmingiausias šiais atvejais:

1. kuriant projektus su aiškiais, nekeičiamaisgyvenimo ciklas reikalavimus, suprantamą įgyvendinimą ir techninius metodus;
2. kai kuriamas projektas, orientuotas į to paties tipo sistemos ar produkto, kurį kūrėjai jau sukūrė anksčiau, kūrimą;
3. rengiant projektą, susijusį su esamo produkto ar sistemos naujos versijos sukūrimu ir išleidimu;
4. rengiant projektą, susijusį su esamo produkto ar sistemos perkėlimu į naują platformą;
5. vykdant didelius projektus, kuriuose dalyvauja kelios didelės kūrėjų komandos.

Inkrementinis modelis

(Žingsnis po žingsnio modelis su tarpiniu valdymu)

Inkrementinis modelis(Anglų) prieaugis- didinti, didinti) reiškia programinės įrangos kūrimą tiesine etapų seka, bet keliais žingsniais (versijomis), t.y. su planuojamais produkto patobulinimais visą laiką, kol pasibaigs programinės įrangos kūrimo gyvavimo ciklas.

Programinės įrangos kūrimas vyksta iteracijomis, tarp etapų naudojant grįžtamąjį ryšį. Tarppakopiniai koregavimai leidžia atsižvelgti į realią abipusę vystymosi rezultatų įtaką įvairiuose etapuose, kiekvieno etapo gyvavimo trukmė pailgėja per visą kūrimo laikotarpį.

Darbo su projektu pradžioje nustatomi visi pagrindiniai reikalavimai sistemai ir suskirstomi į daugiau ir mažiau svarbius. Tada sistema tobulinama laipsniškai, kad kūrėjas galėtų naudoti programinės įrangos kūrimo metu gautus duomenis. Kiekvienas žingsnis turėtų pridėti tam tikrų sistemos funkcijų. Tokiu atveju išleidimas prasideda nuo komponentų, turinčių aukščiausią prioritetą. Kai nustatomos sistemos dalys, paimkite pirmąją dalį ir pradėkite ją detalizuoti naudodami tinkamiausią procesą. Tuo pačiu galima patikslinti reikalavimus kitoms dalims, kurios buvo įšaldytos galiojančiame šio darbo reikalavimų rinkinyje. Jei reikia, prie šios dalies galite grįžti vėliau. Jei detalė yra paruošta, ji pristatoma klientui, kuris gali ją panaudoti savo darbe. Tai leis klientui paaiškinti toliau nurodytų komponentų reikalavimus. Tada jie kuria kitą sistemos dalį. Pagrindiniai šio proceso žingsniai yra paprasčiausias programinės įrangos reikalavimų pogrupio įgyvendinimas ir modelio tobulinimas per keletą nuoseklių leidimų, kol programinė įranga bus visiškai įdiegta.

Šio modelio gyvavimo ciklas būdingas kuriant sudėtingas ir sudėtingas sistemas, kurioms yra aiški vizija (tiek iš užsakovo, tiek iš kūrėjo pusės), koks turi būti galutinis rezultatas. Versija kuriama dėl įvairių priežasčių:

• užsakovo nesugebėjimas finansuoti viso brangaus projekto iš karto;
• kūrėjui trūksta reikiamų resursų kompleksiniam projektui įgyvendinti per trumpą laiką;
• reikalavimus, taikomus galutiniams vartotojams laipsniškai diegti ir priimti gaminį. Visos sistemos įdiegimas vienu metu gali sukelti jos vartotojų atmetimą ir tik „sulėtinti“ perėjimo prie naujų technologijų procesą. Vaizdžiai tariant, jie gali tiesiog „nesuvirškinti didelio gabalo, todėl jį reikia supjaustyti ir dalyti dalimis“.

Privalumai Ir trūkumaiŠis modelis (strategijos) yra toks pat, kaip ir krioklio (klasikinis gyvavimo ciklo modelis). Tačiau skirtingai nuo klasikinės strategijos, klientas rezultatus gali pamatyti anksčiau. Remdamasis pirmosios versijos kūrimo ir diegimo rezultatais, jis gali šiek tiek pakeisti kūrimo reikalavimus, jo atsisakyti arba pasiūlyti sukurti pažangesnį produktą sudaręs naują sutartį.

Privalumai:

• sumažėja išlaidos, patiriamos pasikeitus vartotojų reikalavimams, ženkliai sumažėja pakartotinė analizė ir dokumentacija, lyginant su krioklio modeliu;
• Lengviau gauti atsiliepimą iš kliento apie atliktus darbus – klientai gali išsakyti savo pastabas apie atliktas dalis ir matyti, kas jau atlikta. Nes Pirmosios sistemos dalys yra visos sistemos prototipas.
• klientas turi galimybę greitai gauti ir įsisavinti programinę įrangą – klientai gali greičiau suvokti realią sistemos naudą, nei tai būtų įmanoma naudojant krioklio modelį.

Modelio trūkumai:

• vadovai turi nuolat matuoti proceso pažangą. esant sparčiai plėtrai, neturėtumėte kurti dokumentų kiekvienam minimaliam versijos pakeitimui;
• sistemos struktūra linkusi blogėti, kai pridedami nauji komponentai – nuolatiniai pokyčiai sutrikdo sistemos struktūrą. Norint to išvengti, pertvarkymui reikia papildomo laiko ir pinigų. Dėl prasto dizaino programinę įrangą sunku ir brangu pakeisti vėliau. O nutrūkęs programinės įrangos gyvavimo ciklas sukelia dar didesnius nuostolius.

Schema neleidžia greitai atsižvelgti į atsirandančius pakeitimus ir programinės įrangos reikalavimų paaiškinimus. Kūrimo rezultatų derinimas su vartotojais vykdomas tik taškuose, kurie suplanuoti baigus kiekvieną darbo etapą, o bendrieji reikalavimai programinei įrangai fiksuojami techninių specifikacijų pavidalu visą jos sukūrimo laiką. Taigi vartotojai dažnai gauna programinę įrangą, kuri neatitinka realių jų poreikių.

Spiralinis modelis

Spiralinis modelis:Gyvavimo ciklas – kiekviename spiralės posūkyje sukuriamas kitas gaminio variantas, išsiaiškinami projekto reikalavimai, nustatoma jo kokybė, planuojami kito posūkio darbai. Ypatingas dėmesys skiriamas pradiniams kūrimo etapams – analizei ir projektavimui, kai tam tikrų techninių sprendimų įgyvendinamumas yra išbandomas ir pagrindžiamas kuriant prototipus.

Šis modelis yra programinės įrangos kūrimo procesas, kuriame derinamas ir dizainas, ir etapinis prototipų kūrimas, kad būtų derinami „iš apačios į viršų“ ir „iš viršaus į apačią“ koncepcijų pranašumai, pabrėžiant ankstyvąsias gyvavimo ciklo stadijas: analizę ir dizainą.Išskirtinis bruožas Šis modelis yra ypatingas dėmesys rizikoms, turinčioms įtakos gyvavimo ciklo organizavimui.

Analizės ir projektavimo etapuose techninių sprendimų pagrįstumas ir klientų poreikių tenkinimo laipsnis tikrinamas kuriant prototipus. Kiekvienas spiralės posūkis atitinka veikiančio sistemos fragmento arba versijos sukūrimą. Tai leidžia išsiaiškinti projekto reikalavimus, tikslus ir ypatybes, nustatyti plėtros kokybę ir planuoti kito spiralės posūkio darbus. Tokiu būdu gilinamos ir nuosekliai patikslinamos projekto detalės, o to pasekoje parenkamas pagrįstas, realius užsakovo reikalavimus atitinkantis ir įgyvendinamas variantas.

Gyvenimo ciklas kiekviename spiralės posūkyje – gali būti naudojami skirtingi programinės įrangos kūrimo proceso modeliai. Galiausiai produkcija yra gatavas produktas. Modelis sujungia modelio prototipų kūrimo galimybes irkrioklio modelis. Plėtra iteracijomis atspindi objektyviai egzistuojantį sistemos kūrimo spiralinį ciklą. Neužbaigtas kiekvieno etapo darbų atlikimas leidžia pereiti į kitą etapą, nelaukiant, kol bus baigti darbai dabartiniame. Pagrindinė užduotis – sistemos naudotojams kuo greičiau parodyti veikiantį produktą, taip suaktyvinant reikalavimų išaiškinimo ir papildymo procesą.

Modelio privalumai:

• leidžia greitai parodyti sistemos vartotojams veikiantį produktą, taip suaktyvinant reikalavimų paaiškinimo ir papildymo procesą;
• leidžia keisti reikalavimus programinės įrangos kūrimo metu, o tai būdinga daugumai patobulinimų, įskaitant standartinius;
• modelis leidžia sukurti lankstų dizainą, nes įkūnija krioklio modelio privalumus ir tuo pačiu leidžia kartoti visas to paties modelio fazes;
• leidžia gauti patikimesnę ir stabilesnę sistemą. Tobulėjant programinei įrangai, kiekvienos iteracijos metu aptinkamos ir ištaisomos klaidos ir trūkumai;
• šis modelis leidžia vartotojams aktyviai dalyvauti planavimo, rizikos analizės, projektavimo ir vertinimo veikloje;
• sumažėja klientų rizika. Klientas gali užbaigti neperspektyvaus projekto vystymą su minimaliais finansiniais nuostoliais;
• Vartotojų atsiliepimai kūrėjams atsiranda labai dažnai ir modelio pradžioje, o tai užtikrina norimo aukštos kokybės produkto sukūrimą.

Modelio trūkumai:

• jei projektas yra mažos rizikos arba mažo dydžio, modelis gali būti brangus. Rizikos įvertinimas po kiekvienos spiralės yra susijęs su didelėmis išlaidomis;
• Modelio gyvavimo ciklas turi sudėtingą struktūrą, todėl kūrėjams, vadovams ir klientams gali būti sunku jį naudoti;
• spiralė gali tęstis neribotą laiką, nes kiekvienas kliento atsakymas į sukurtą versiją gali generuoti naują ciklą, kuris atitolina projekto pabaigą;
• dėl didelio tarpinių ciklų skaičiaus gali prireikti tvarkyti papildomus dokumentus;
• modelio naudojimas gali pasirodyti brangus ir net neįperkamas, nes laikas. laikas, praleistas planuojant, iš naujo apibrėžiant tikslus, atliekant rizikos analizę ir prototipų kūrimą, gali būti per daug;
• Gali būti sunku apibrėžti tikslus ir gaires, rodančias pasirengimą tęsti kūrimo procesą į kitą ir

Pagrindinė spiralinio ciklo problema yra perėjimo į kitą etapą momento nustatymas. Siekiant išspręsti šią problemą, kiekvienam etapui įvedami laiko apribojimai.gyvenimo ciklas ir perėjimas vyksta taip, kaip planuota, net jei ne visi suplanuoti darbai atlikti.Planavimasparengta remiantis ankstesniuose projektuose gautais statistiniais duomenimis ir asmenine kūrėjų patirtimi.

Spiralinio modelio taikymo sritis

Spiralinį modelį patartina naudoti šiais atvejais:

• kuriant projektus naudojant naujas technologijas;
• kuriant naują produktų ar sistemų seriją;
• rengiant projektus su numatomais reikšmingais reikalavimų pakeitimais ar papildymais;
• vykdyti ilgalaikius projektus;
• rengiant projektus, kuriems reikia per trumpą laiką parodyti sistemos ar produkto kokybę ir versijas;
• rengiant projektus. kurioms būtina apskaičiuoti išlaidas, susijusias su rizikos įvertinimu ir sprendimu.