Tarkvaraarenduse elutsükkel ja etapid. Tarkvara elutsükkel: kontseptsioon, standardid, protsessid. Tarkvara elutsükli mudelid

See jaotis määratleb järgmised tugiprotsessid eluring:

1. dokumenteerimisprotsess;
2. konfiguratsioonihaldusprotsess;
3. kvaliteedi tagamise protsess;
4. kontrollimise protsess;
5. sertifitseerimisprotsess;
6. osalusülevaate protsess;
7. auditiprotsess;
8. probleemide lahendamise protsess.

Abiprotsessi töö ja ülesannete eest vastutab seda protsessi teostav organisatsioon. See organisatsioon tagab konkreetse protsessi olemasolu ja funktsionaalsed omadused.

See organisatsioon korraldab ja juhib abiprotsessi projekti tasandil vastavalt juhtimisprotsessile (alajaotis 7.1); määratleb selle protsessi infrastruktuuri vastavalt infrastruktuuri loomise protsessile (alapunkt 7.2);

kohandab selle protsessi projekti tingimustega vastavalt kohandamisprotsessile (lisa A) ja juhib abiprotsessi organisatsiooni tasandil vastavalt parendusprotsessidele (alapunkt 7.3) ja koolitusele (alapunkt 7.4). Kasutada saab järgmisi kvaliteedi tagamise meetodeid: ühisanalüüsid, auditid, kontrollimine ja sertifitseerimine.

6.1 Dokumenteerimisprotsess

Dokumenteerimisprotsess on elutsükli protsessi või tegevuse käigus loodud teabe vormistamise protsess. See protsess koosneb tegevuste kogumist, mis kavandavad, kujundavad, arendavad, toodavad, redigeerivad, levitavad ja hooldavad neid dokumente, mida vajavad kõik huvitatud osapooled, nagu administraatorid, insenerid ja süsteemi kasutajad või tarkvaratoode.

1. protsessi ettevalmistamine;
2. projekteerimine ja arendus;
3. vabastamine;
4. saatel.

6.1.1 Protsessi ettevalmistamine

6.1.1.1 Tarkvaratoote elutsükli protsesside käigus välja antud dokumentide tuvastamise plaan tuleb välja töötada, dokumenteerida ja ellu viia. Iga määratud dokumendi jaoks tuleb määratleda järgmine:

a) tiitel või ametinimetus;

b) eesmärk;

c) dokumendi kasutajad;

d) allika ettevalmistamise, arendamise, kontrollimise, muutmise, kinnitamise, vabastamise, säilitamise, levitamise, hoolduse ja konfiguratsioonihalduse protseduurid ja vastutus;

e) vahe- ja lõplike väljaannete väljaandmise aeg.

6.1.2 Disain ja arendus

See töö koosneb järgmistest ülesannetest:

6.1.2.1 Iga konkreetne dokument peab olema kujundatud vastavalt kehtivatele dokumentatsioonistandarditele järgmistes aspektides: vorm; sektsioonide koostis ja sisu; lehekülgede nummerdamine; jooniste ja tabelite paigutus ja kujundus; autoriõiguste teatised, juurdepääsuõigused; brošüürid ja muud teabe esitamise elemendid.

6.1.2.2 Dokumentide algmaterjalide allikas ja piisavus tuleb kinnitada. Dokumentide koostamisel saab kasutada dokumentatsiooni automatiseerimise tööriistu.

6.1.2.3 Koostatud dokumentide vorminguid, tehnilist sisu ja esitusstiili tuleks kontrollida ja redigeerida vastavalt kehtivatele dokumentatsioonistandarditele. Enne väljastamist peavad dokumendid olema pädevate isikute poolt heaks kiidetud (kokkulepitud).

6.1.3 Vabastamine

See töö koosneb järgmistest ülesannetest:

6.1.3.1 Dokumendid tuleb avaldada ja levitada plaanipäraselt. Dokumentide avaldamisel ja levitamisel võib kasutada paberkandjat, elektroonilist või muud meediat. Originaaldokumente tuleb säilitada arvestuse, säilitamise, kaitsmise, ringluse ja paljundamise nõuete kohaselt.

6.1.3.2 Dokumentatsiooni juhtelemendid määratletakse vastavalt k(6.2).

6.1.4 Hooldus

6.1.4.1 Dokumentatsioonis muudatuste tegemisega seotud probleemid tuleb lahendada (alapunkt 5.5). Konfiguratsioonihalduses olevate dokumentide muudatused tehakse vastavalt konfiguratsioonihalduse protsessile (alajaotis 6.2).

6.2 Konfiguratsioonihaldusprotsess

Konfiguratsioonihaldusprotsess on protsess, mille käigus rakendatakse haldus- ja tehnilisi protseduure kogu tarkvara elutsükli jooksul, et: tuvastada, defineerida ja kindlaks teha süsteemi tarkvaraobjektide olek (algseisund);

objektide muutmise ja vabastamise haldus; kirjeldused ja teated objektide olekute kohta ning taotlused nende muutmiseks; objektide terviklikkuse, ühilduvuse ja õigsuse tagamine; esemete ladustamise, ringluse ja tarnimise juhtimine.

Märkus. Kui seda protsessi rakendatakse teistele tarkvaratoodetele või objektidele, tõlgendatakse terminit "tarkvaraobjekt" allpool vastavalt.

Tööde nimekiri. See protsess koosneb järgmistest töödest:

1. protsessi ettevalmistamine;
2. konfiguratsiooni määratlus;
3. konfiguratsiooni juhtimine;
4. konfiguratsiooniolekute arvestus;
5. konfiguratsiooni hindamine;
6. väljalaske haldamine ja kohaletoimetamine.

6.2.1 Protsessi ettevalmistamine

See töö koosneb järgmisest ülesandest:

6.2.1.1 Koostatakse konfiguratsiooni haldusplaan. Plaan peaks määratlema:

konfiguratsioonihaldustööd; nende tööde teostamise kord ja ajakava; nende tööde teostamise eest vastutavad organisatsioonid; selle organisatsiooni(de) ühendamine teiste organisatsioonidega, näiteks tarkvara arendamiseks ja hooldamiseks. Plaan peab olema dokumenteeritud ja ellu viidud.

Märkus. See plaan võib olla osa süsteemi konfiguratsiooni haldusplaanist.

6.2.2 Konfiguratsiooni määratlemine.

See töö koosneb järgmisest ülesandest:

6.2.2.1 Projekti elluviimise käigus juhitavate tarkvaraobjektide ja nende versioonide (tarkvara konfiguratsiooniobjektide) tähistamise skeem tuleb määratleda. Iga tarkvaraobjekti ja selle versioonide jaoks tuleb määratleda: dokumentatsioon, mis salvestab selle konfiguratsiooni oleku; viiteversioonid ja muud tähistuselemendid.

6.2.3 Konfiguratsiooni juhtimine

See töö koosneb järgmisest ülesandest:

6.2.3.1 Täita tuleb: muudatustaotluste tähistamine ja registreerimine;

muudatuste analüüs ja hindamine; taotluse vastuvõtmine või mitteaktsepteerimine; muudetud tarkvaraobjekti rakendamine, kontrollimine ja vabastamine. Iga muudatuse puhul tuleb läbi viia auditid, mis vaatavad üle iga muudatuse, selle põhjuse ja volituse. Kõiki kontrollitavaid tarkvaraobjekte, mis on seotud kriitiliste ohutus- või turvafunktsioonidega, tuleb kontrollida ja auditeerida.

6.2.4 Konfiguratsiooniolekute arvestamine

See töö koosneb järgmisest ülesandest:

6.2.4.1 Koostatakse haldusdokumendid ja olekuaruanded, mis kajastavad kontrollitavate tarkvaraobjektide olekut ja muudatuste ajalugu, sealhulgas nende konfiguratsiooni olekut. Olekuaruanded peaksid sisaldama antud projekti muudatuste arvu, uusimad versioonid tarkvaraüksused, välja antud versioonide tähistused, väljalasete arv ja tarkvaraüksuste võrdlus väljaannete lõikes.

6.2.5 Konfiguratsiooni hindamine

See töö koosneb järgmisest ülesandest:

6.2.5.1 Tuleb kindlaks määrata ja tagada: tarkvaraobjektide funktsionaalne terviklikkus neile kehtestatud nõuete täitmise osas; tarkvaraobjektide füüsiline täielikkus kõigi projektis ja programmides tehtud muudatuste rakendamise osas.

6.2.6 Väljalaske haldamine ja kohaletoimetamine

See töö koosneb järgmisest ülesandest:

6.2.6.1 Tarkvaratoodete väljalaskmist ja tarnimist koos nendega seotud dokumentatsiooniga kontrollitakse ametlikult. Originaalprogrammid ja -dokumentatsioon peavad olema kaasas kogu elutsükli jooksul. Kriitiliste ohutus- või turvafunktsioonidega seotud programme ja dokumentatsiooni tuleb töödelda, säilitada, pakendada ja tarnida vastavalt kehtestatud korrale.

6.3 Kvaliteedi tagamise protsess

Kvaliteedi tagamise protsess on protsess, mis annab piisava tagatise, et tarkvaratooted ja protsessid projekti elutsükli jooksul vastavad kindlaksmääratud nõuetele ja kinnitatud plaanidele. Erapooletuse seisukohalt peaks kvaliteedi tagamine olema organisatsiooniliselt ja autoriteetselt sõltumatu üksustest, mis on otseselt seotud tarkvaratoote arendamise või projektis toimuva protsessi läbiviimisega. Kvaliteedi tagamine võib subjektiivselt (sisemiselt või väliselt) sõltuda sellest, kas tarnija või kliendi kontrolli all on tõendatud toote või protsessi kvaliteet. Kvaliteedi tagamine võib kasutada muude toetavate protsesside, nagu kontrollimine, valideerimine, ühised ülevaatused, auditeerimine ja probleemide lahendamine, tulemusi.

Tööde nimekiri. See protsess koosneb järgmistest töödest:

1. protsessi ettevalmistamine;
2. toote pakkumine;
3. protsessi tagamine;
4. kvaliteedisüsteemide tagamine.

6.3.1 Protsessi ettevalmistamine

See töö koosneb järgmistest ülesannetest:

6.3.1.1 Kvaliteedi tagamise protsess peab olema kohandatud konkreetsetele projektitingimustele. Kvaliteedi tagamise protsessi eesmärgid määratletakse tagamaks, et tarkvaratooted ja nende tarkvaratoodete loomiseks kasutatavad protsessid vastaksid kindlaksmääratud nõuetele ja heakskiidetud plaanidele.

6.3.1.2 Kvaliteedi tagamise protsess peab olema kooskõlastatud sellega seotud kontrolli (6.4), kvalifitseerimise (6.5), vastastikuse eksperdihinnangu (6.6) ja auditi (6.7) protsessidega.

6.3.1.3 Kvaliteedi tagamise protsessi tööde ja ülesannete elluviimise plaan tuleb välja töötada, dokumenteerida, ellu viia ja lepingu täitmise käigus toetada. Plaan peaks sätestama:

a) kvaliteedistandardid, metoodikad, protseduurid ja vahendid kvaliteedi tagamise töö tegemiseks (või sisaldavad linke asjakohasele ametlikule dokumentatsioonile);

b) lepingu täitmise ajal kvaliteedianalüüside läbiviimise ja nende tööde kooskõlastamise kord;

c) kvaliteetse teabe tuvastamise, kogumise, salvestamise, säilitamise ja levitamise kord;

d) kvaliteedi tagamise tegevuste ressursid, ajakavad ja vastutus;

e) valitud tegevused ja ülesanded tugiprotsessidest, nagu kontrollimine (6.4), valideerimine (6.5), koostööülevaade (6.6), audit (6.7) ja probleemide lahendamine (6.8).

6.3.1.4 Planeeritud ja traditsioonilised kvaliteedi tagamise tegevused ja ülesanded peavad olema täidetud. Juhtudel, kui ilmnevad probleemid või avastatakse lepingunõuetele mittevastavus, tuleb need dokumenteerida ja saata sisendina probleemi lahendamise protsessi (alapunkt 6.8). Nende tööde ja ülesannete, nende teostamise, ilmnenud probleemide ja nende lahenduste kohta tuleb koostada ja lisada aruanded.

6.3.1.5 Kvaliteedi tagamise tegevuste ja ülesannete aruanded tuleb teha kliendile kättesaadavaks vastavalt lepingutingimustele.

6.3.1.6 Tuleb tagada, et lepingu täitmise eest vastutavad isikud on organisatsiooniliselt sõltumatud, neil on vahendid ja volitused objektiivsete hinnangute andmiseks ning tekkinud probleemide lahenduste leidmiseks, rakendamiseks ja kontrollimiseks.

6.3.2 Tootega varustamine

See töö koosneb järgmistest ülesannetest:

6.3.2.1 Tuleb tagada, et kõik lepingus nõutud plaanid oleksid dokumenteeritud, vastaksid lepingutingimustele, oleksid vastastikku kokku lepitud ja nõuetekohaselt täidetud.

6.3.2.2 Tuleb tagada, et tarkvaratooted ja nendega seotud dokumentatsioon oleksid valmistatud lepingutingimuste ja kinnitatud plaanide kohaselt.

6.3.2.3 Tarkvaratoodete tarnimise ettevalmistamisel tuleb veenduda, et need tooted vastavad täielikult lepingus kehtestatud nõuetele ja rahuldavad klienti.

6.3.3 Protsessi tugi

See töö koosneb järgmistest ülesannetest:

6.3.3.1 Tagatakse, et projekti elluviimisega kaasnevad tarkvara elutsükli protsessid (tarne-, arendus-, käitamis-, hooldus- ja tugiprotsessid, sh kvaliteedi tagamine) viiakse läbi vastavalt lepingutingimustele ja lepingutingimuste piires. kinnitatud plaanid.

6.3.3.2 Tuleb tagada, et projektis kasutatavad programmeerimistehnoloogiad, arendustingimused, testimistingimused ja arhiiviraamatukogud vastaksid lepingutingimustele.

6.3.3.3 Tuleb tagada, et põhilepingus sätestatud nõuded on alltöövõtjale teatavaks tehtud ning alltöövõtja poolt arendatud tarkvaratooted vastavad põhilepingu nõuetele.

6.3.3.4 Tagatakse, et tellija ja teised lepingupooled osutavad vastastikust tuge ja koostööd vastavalt lepingutingimustele, saavutatud kokkulepetele ja kinnitatud plaanidele.

6.3.3.5 Tuleb tagada, et tarkvaratoote ja -protsesside omadused vastaksid kehtestatud standarditele ja protseduuridele.

6.3.3.6 Tagatakse, et projekti elluviimisega seotud töötajatel on kindlaksmääratud nõuete täitmiseks vajalikud kogemused ja teadmised ning nad on võimelised läbima vajalikku koolitust.

6.3.4 Kvaliteedisüsteemide tagamine

See töö koosneb järgmisest ülesandest:

6.3.4.1 Täiendavad kvaliteedijuhtimistööd tuleb tagada vastavalt lepingus märgitud GOST R ISO 9001 punktidele.

6.4 Kinnitusprotsess

Kontrolliprotsess on protsess, mille käigus tehakse kindlaks, kas tarkvaratooted toimivad täielikult kooskõlas eelmises töös rakendatud nõuete või tingimustega. Kulutõhususe ja toimivuse hindamiseks tuleks kontrollimine asjakohastes protsessides (nagu tarnimine, arendus, käitamine või hooldus) läbi viia võimalikult varakult. See protsess võib hõlmata analüüsi, kontrollimist ja testimist (testimist).

Seda protsessi saab läbi viia esinejate erineva sõltumatuse astmega. Esinejate iseseisvuse aste võib jaguneda nii organisatsiooni enda erinevate subjektide kui ka teises organisatsioonis olevate subjektide vahel erineva vastutuse jaotusastmega. Seda protsessi nimetatakse sõltumatuks kontrolliprotsessiks, kui teostav organisatsioon on tarnijast, arendajast, operaatorist või tugipersonalist sõltumatu.

Tööde nimekiri. See protsess koosneb järgmistest töödest:

1. protsessi ettevalmistamine;
2. kontrollimine.

6.4.1 Protsessi ettevalmistamine

See töö koosneb järgmistest ülesannetest:

6.4.1.1 Tuleb kindlaks määrata projekti kontrollimistööde vajadus ja organisatsiooni sõltumatuse aste selle töö teostamisel. Projekteerimisnõuete kriitilisust tuleb analüüsida. Kriitilisust saab hinnata järgmiselt:

a) võimalikku avastamata viga süsteemis või tarkvaranõudes, mis põhjustab töötajate surma või vigastusi, missiooni ebaõnnestumist, rahalist kahju või seadmete katastroofilist hävimist;

b) kasutatava programmeerimistehnoloogia keerukus ja selle kasutamisega seotud riskid;

c) rahaliste vahendite ja ressursside olemasolu.

6.4.1.2 Kui projekt hõlmab verifitseerimistööd, tuleb tarkvaratoote verifitseerimiseks luua kontrolliprotsess.

6.4.1.3 Kui projekt hõlmab sõltumatut taatlustööd, tuleb valida taatlemise eest vastutav kvalifitseeritud organisatsioon. Sellele organisatsioonile tuleb taatlustööde tegemisel tagada sõltumatus ja volitused.

6.4.1.4 Kavandatavad olelusringi tegevused ja kontrollimist vajavad tarkvaratooted tehakse kindlaks projekti ulatuse, mahu, keerukuse ja kriitilisuse analüüsi põhjal. Tööd ja taatlusülesanded tuleb valida punktis 6.4.2 elutsükli jooksul verifitseeritud tööde ja tarkvaratoodete jaoks, sealhulgas asjakohased meetodid, tehnikad ja tööriistad.

6.4.1.5 Töötatakse välja ja dokumenteeritakse taatluskava, mis põhineb kehtestatud taatluseesmärkidel. Plaan peab olema seotud elutsükli jooksul kontrollitud töö- ja tarkvaratoodetega; sisaldama iga objekti jaoks vajalikke kontrolliülesandeid; Määrake kindlaks sobivad ressursid, kohustused ja töögraafik. Plaan peaks sisaldama kordi kontrollaruannete edastamiseks kliendile ja teistele huvitatud isikutele.

6.4.1.6 Rakendatakse taatluskava. Kontrollimise käigus leitud probleemid ja ebakõlad tuleks sisestada probleemi lahendamise protsessi (punkt 6.8). Kõik esilekerkivad probleemid tuleb lahendada ja leitud ebakõlad tuleb kõrvaldada. Taatlustöö tulemused peavad olema kliendile ja teistele lepingus osalevatele organisatsioonidele kättesaadavad.

6.4.2 Kontrollimine

See töö koosneb järgmistest ülesannetest:

6.4.2.1 Lepingu kontrollimine

Lepingut tuleb kontrollida järgmiste kriteeriumide alusel:

a) tarnija suutlikkust täita kindlaksmääratud nõudeid;

b) nõuete järjepidevus ja kasutajate vajaduste katmine;

c) kindlaksmääratud nõuete muutmiseks ja probleemide lahendamiseks on kehtestatud asjakohased protseduurid;

d) menetluste ja reeglite olemasolu nende kohaldamiseks lepinguosaliste vahelise suhtluse ja koostöö osas, sealhulgas omandiõigused, garantiid, autoriõigused ja konfidentsiaalsus;

e) asjakohaste kriteeriumide ja protseduuride olemasolu vastavalt kehtestatud nõuetele.

Märkus. Seda tööd võib teha lepingu hindamise käigus (vt punkt 6.3.1.3.b)].

6.4.2.2 Protsessi kontrollimine

Protsessi tuleb kontrollida vastavalt järgmistele kriteeriumidele:

a) projekti planeerimise nõuete kehtestamise piisavus ja õigeaegsus;

b) projekti jaoks valitud protsesside sobivus, teostatavus, teostatavus vastavalt plaanile ja lepingutingimustele;

c) standardite, protseduuride ja tingimuste kohaldatavus projekteerimisprotsessidele;

d) töötajate komplekteerimine ja väljaõpe vastavalt lepingutingimustele.

6.4.2.3 Nõuete kontrollimine

Nõudeid tuleb kontrollida järgmiste kriteeriumide alusel:

a) süsteeminõuete järjepidevus, teostatavus ja testitavus;

b) süsteeminõuete jaotamine riistvara, tarkvara ja käsitsi töötavate üksuste vahel vastavalt projektile;

c) tarkvaranõuetes süsteeminõuete kajastamise järjepidevus, teostatavus, testitavus ja täpsus;

d) ohutuse, turvalisuse ja kriitilisuse tarkvaranõuete õigsus, mis on asjakohaste meetoditega kinnitatud.

6.4.2.4 Projekti kontrollimine

Projekti tuleb kontrollida vastavalt järgmistele kriteeriumidele:

a) projekti õigsus, vastavus kehtestatud nõuetele ja nende nõuete projektis sisaldumine;

b) sobiva sündmuste jada, sisendandmete, väljundtulemuste, liideste, loogika, aja ja materiaalsete ressursside jaotamise, samuti vigade tuvastamise, lokaliseerimise ja taastamise teostatavust projektis;

c) oskus valida projekt kehtestatud nõuete alusel;

d) ohutus-, turva- ja muude kriitiliste nõuete projekti rakendamise õigsus, mida on asjakohaste meetoditega kontrollitud.

6.4.2.5 Programmi kinnitamine

Programmi tuleb kontrollida vastavalt järgmistele kriteeriumidele:

a) programm võtab arvesse projekti tingimusi ja kehtestatud nõudeid; selle testitavus, õigsus ja vastavus kehtestatud nõuetele ja programmeerimisstandarditele;

b) rakendatavus programmis: asjakohane sündmuste jada, sobivad liidesed, õiged andmed ja juhtimisloogika; aja ja materiaalsete ressursside jaotamine; vigade tuvastamine, lokaliseerimine ja taastamine, samuti selle täielikkus:

c) võimalus valida programm vastavalt projektile või kindlaksmääratud nõuetele;

d) ohutuse, turvalisuse ja muude kriitiliste nõuete rakendamist programmis on kontrollitud asjakohaste meetoditega.

6.4.2.6 Kooste kontroll

Koostu tuleb kontrollida järgmiste kriteeriumide kohaselt:

a) iga tarkvaraobjekti tarkvarakomponentide ja moodulite täielikkus ja korrektne komplekteerimine vastavaks tarkvaraobjektiks;

b) tehniliste ja tarkvaraobjektide ning käsitsi toimingute süsteemi komplekteerimise täielikkus ja korrektsus;

c) Teostage monteerimistööd vastavalt montaažiplaanile.

6.4.2.7 Dokumentatsiooni kontrollimine

Dokumentatsiooni tuleb kontrollida järgmiste kriteeriumide kohaselt:

a) dokumentatsiooni piisavus, täielikkus ja järjepidevus;

b) dokumentatsiooni õigeaegne koostamine;

c) vastavus kehtestatud dokumendikonfiguratsiooni haldusprotseduuridele.

6.5 Valideerimisprotsess

Sertifitseerimisprotsess on kehtestatud nõuete, loodud süsteemi või tarkvaratoote funktsionaalsele otstarbele vastavuse täielikkuse kindlakstegemise protsess. Sertifitseerimist saab läbi viia töö algfaasis. Seda protsessi võib läbi viia tarkvara aktsepteerimise jõupingutuste osana (vt 5.3.13).

Seda protsessi saab läbi viia esinejate erineva sõltumatuse astmega. Esinejate iseseisvuse aste võib jaguneda nii organisatsiooni enda erinevate subjektide kui ka teises organisatsioonis olevate subjektide vahel erineva vastutuse jaotusastmega. Seda protsessi nimetatakse sõltumatuks sertifitseerimisprotsessiks, kui rakendusorganisatsioon on tarnijast, arendajast, operaatorist või tugipersonalist sõltumatu.

Tööde nimekiri. See protsess koosneb järgmistest töödest:

1. protsessi ettevalmistamine;
2. sertifitseerimine.

6.5.1 Protsessi ettevalmistamine

See töö koosneb järgmistest ülesannetest:

6.5.1.1 Tuleb kindlaks määrata projekti sertifitseerimistööde vajadus ja organisatsiooni sõltumatuse aste selle töö teostamisel.

6.5.1.2 Kui projekt hõlmab kvalifitseerimistööd, tuleb süsteemi või tarkvaratoote kvalifitseerimiseks luua kvalifitseerimisprotsess. Tuleb määratleda allpool kirjeldatud hindamise eesmärgid, sealhulgas nende eesmärkide saavutamiseks sobivad meetodid, tehnikad ja vahendid.

6.5.1.3 Kui projekt hõlmab sõltumatut sertifitseerimistööd, tuleb valida sertifitseerimise eest vastutav kvalifitseeritud organisatsioon. Sellele organisatsioonile tuleb sertifitseerimistööde tegemisel tagada sõltumatus ja autoriteet.

6.5.1.4 Sertifitseerimisplaan tuleb välja töötada ja dokumenteerida. Plaan peaks määratlema (kuid mitte ainult):

a) sertifitseerimisele kuuluvad objektid;

b) sertifitseerimise käigus lahendatavad ülesanded;

c) hindamise läbiviimise ressursid, vastutus ja ajakava;

d) kvalifikatsiooniaruannete kliendile ja teistele osapooltele edastamise kord.

6.5.1.5 Sertifitseerimise läbiviimise plaan tuleb ellu viia. Hindamise käigus leitud probleemid ja mittevastavused tuleks sisestada probleemi lahendamise protsessi (6.8). Kõik esilekerkivad probleemid tuleb lahendada ja leitud ebakõlad tuleb kõrvaldada. Sertifitseerimistöö tulemused peavad olema kliendile ja teistele lepingus osalevatele organisatsioonidele kättesaadavad.

6.5.2 Tõendamine

See töö koosneb järgmistest ülesannetest:

6.5.2.1 Valmistage ette valitud testinõuded, katsejuhud ja testi spetsifikatsioonid katsetulemuste analüüsimiseks.

6.5.2.2 Tagada, et testimisnõuded, testjuhtumid ja tehnilised kirjeldused testid kajastasid spetsiifilisi nõudeid konkreetsetele sertifitseerimisobjektidele.

6.5.2.3 Katsete läbiviimine, võttes arvesse punkte 6.5.2.1 ja 6.5.2.2, sealhulgas:

a) testid sisendandmete kriitilistel, piir- ja eriväärtustel;

b) tarkvaratoote testimine selle suutlikkuse suhtes isoleerida ja minimeerida vigade mõju, järk-järgult vähendada tõrgete mõju ja paluda operaatori abi kriitilistes, piir- ja eritingimustes;

c) testimine esindusliku valimiga kasutajatest, kes suudavad tarkvaratoote abil oma ülesanded edukalt täita.

6.5.2.4 Kinnitus, et tarkvaratoode vastab esitatud võimalustele.

6.5.2.5 Tarkvaratoote testimine valitud töökeskkonna piirkondades.

6.6 Koostööülevaatus

Ühisülevaate protsess on projekti töö (toodete) olekute ja vajadusel tulemuste hindamise protsess. Ühiseid ülevaatusi rakendatakse nii projektijuhtimise kui ka projekti tehnilise teostuse tasandil ning neid viiakse läbi kogu lepingu kehtivusaja jooksul. Seda protsessi võivad läbi viia kõik kaks lepinguosalist, kusjuures üks pool (analüüsib) kontrollib teist poolt (analüüs).

6.1 Tööde loetelu.

See protsess koosneb järgmistest töödest:

1) protsessi ettevalmistamine;

2) projektijuhtimise ülevaated;

3) tehnilised analüüsid.

6.6.1 Protsessi ettevalmistamine

See töö koosneb järgmistest ülesannetest:

6.6.1.1. Perioodilised eduülevaatused viiakse läbi projektiplaani(de)ga kehtestatud aja jooksul. Sihtanalüüsid tuleks läbi viia huvitatud poole määratud aja jooksul.

6.6.1.2 Analüüsi läbiviimiseks vajalike ressursside maht ja koostis tuleb analüüsiga seotud osapoolte vahel kokku leppida. Need ressursid hõlmavad personali, toimumiskohta, tingimusi, vajalikku tehnilist, tarkvara ja tööriistu.

6.6.1.3 Osapooled peavad iga analüüsi puhul kokku leppima järgmistes küsimustes: analüüsiplaan; analüüsitavate tarkvaratoodete koostis (töötulemused) ja probleemid; analüüsi ulatus ja protseduurid; analüüsi esialgsed ja lõplikud kriteeriumid.

6.6.1.4 Analüüsi käigus tuvastatud probleemid tuleb dokumenteerida ja sisestada probleemide lahendamise protsessi (alajaotis 6.8).

6.6.1.5 Analüüsi tulemused tuleb dokumenteerida ja jagada huvitatud isikutele. Analüüsiv pool peab analüüsitavale osapoolele edastama analüüsi asjakohased tulemused (näiteks kokkulepitud, kokkuleppimata või tingimuslikult kokku lepitud).

6.6.1.6 Osapooled peavad kokku leppima ülevaatuse lõpptulemuse, võetavate kohustuste ja ülevaatuse lõpuleviimise kriteeriumide osas.

6.6.2 Projektijuhtimise ülevaated

See töö koosneb järgmistest ülesannetest:

6.6.2.1 Projekti staatust hinnatakse projekti plaanide, ajakavade, standardite ja juhiste alusel. Analüüsi lõpptulemust peaksid kaks asjaosalist arutama ja see peaks sisaldama järgmist:

a) ettepanekud tööde intensiivistamiseks vastavalt plaanile, mis põhinevad tööde või tarkvaratoodete seisundi hindamisel;

b) ettepanekud projekti üldiseks kontrolliks ressursside asjakohase ümberjaotamise kaudu;

c) ettepanekud projekti käigu muutmiseks või projekti ümberplaneerimise vajaduse kindlakstegemiseks;

d) ettepanekud kriitiliste olukordade hindamiseks ja juhtimiseks, mis võivad ohustada projekti edukat kulgu.

6.6.3 Tehnilised analüüsid

See töö koosneb järgmistest ülesannetest:

6.6.3.1 Tehnilised ülevaatused viiakse läbi selleks, et hinnata nende ülevaatamiseks loodavaid tarkvaratooteid või teenuseid ja tõendada, et:

a) need on hetkel täielikult rakendatud;

b) need vastavad aktsepteeritud standarditele ja tehnilistele nõuetele;

c) muudatused nendes on tehtud asjakohaselt ja mõjutavad ainult kmääratletud valdkondi (alapunkt 6.2);

d) need peavad täielikult kinni kehtestatud graafikud töötab;

e) nad on valmis edasiseks tööks;

f) neid arendatakse, käitatakse või hooldatakse vastavalt projektiplaanidele, ajakavadele, standarditele ja suunistele.

6.7 Auditiprotsess

Auditiprotsess on nõuetele, plaanidele ja lepingutingimustele vastavuse kindlakstegemise protsess. Seda protsessi võivad läbi viia kaks lepinguosalist, kusjuures üks pool (auditeeritav) auditeerib teist poolt (auditeeritav).

Tööde nimekiri. See protsess koosneb järgmistest töödest:

1. protsessi ettevalmistamine;
2. auditeerimine.

6.7.1 Protsessi ettevalmistamine

See töö koosneb järgmistest ülesannetest:

6.7.1.1 Auditid viiakse läbi projektiplaani(de)s sätestatud tähtaegadel.

6.7.1.2 Auditipersonal ei vastuta otseselt auditeeritud tarkvaratoodete ja tööde eest.

6.7.1.3 Auditi läbiviimiseks vajalike ressursside maht ja koosseis tuleb auditiga seotud osapoolte vahel kokku leppida. Need ressursid hõlmavad personali, toimumiskohta, tingimusi, vajalikku tehnilist, tarkvara ja tööriistu.

6.7.1.4 Osapooled peavad iga auditi puhul kokku leppima järgmistes küsimustes: auditi plaan; testitavate tarkvaratoodete koostis (ja töötulemused); auditi läbiviimise ulatus ja protseduurid; esialgsed ja lõplikud kriteeriumid auditi läbiviimisel.

6.7.1.5 Auditi käigus tuvastatud probleemid tuleb dokumenteerida ja sisestada probleemi lahendamise protsessi (alapunkt 6.8).

6.7.1.6 Auditi tulemused pärast selle lõpetamist tuleb dokumenteerida ja esitada auditeeritavale. Auditeeriv osapool peab juhtima auditeeritava tähelepanu kõikidele auditi käigus avastatud probleemidele ja kavandatud lahendustele vastavatele probleemidele.

6.7.1.7 Osapooled peaksid kokku leppima auditi lõpptulemuse, võetavate kohustuste ja auditi lõpuleviimise kriteeriumide. 6.7.2 Audit See töö koosneb järgmisest ülesandest:

6.7.2.1 Auditid tuleks läbi viia tagamaks, et:

a) programmeeritud tarkvaratooted (nt tarkvaraobjekt) kajastavad projektdokumentatsiooni;

b) dokumentatsioonis toodud aktsepteerimise ettevalmistamise ja testimise nõuded on sobivad tarkvaratoodete aktsepteerimiseks;

c) katseandmed vastasid kindlaksmääratud tehnilistele nõuetele;

d) tarkvaratooted on edukalt testitud ja vastavad neile kehtestatud nõuetele;

e) katsearuanded on õiged ning tegelike ja oodatavate tulemuste lahknevused on parandatud;

o kasutaja dokumentatsioon vastab kehtestatud standarditele;

g) tööd tehti kooskõlas kinnitatud nõuete, plaanide ja lepinguga;

h) tööde maksumus ja graafikud vastavad kinnitatud plaanidele.

6.8 Probleemide lahendamise protsess

Probleemide lahendamise protsess on arenduse, käitamise, hoolduse või muude protsesside käigus avastatud probleemide (sh avastatud mittevastavuste) analüüsimise ja lahendamise protsess, olenemata nende päritolust või allikast. Selle protsessi eesmärk on pakkuda vahendeid kõigi tuvastatud probleemide õigeaegseks, vastutustundlikuks ja dokumenteeritud analüüsimiseks ja lahendamiseks ning nende esinemise põhjuste väljaselgitamiseks.

Tööde nimekiri. See protsess koosneb järgmistest töödest:

1. protsessi ettevalmistamine;
2. probleemi lahendus.

6.8.1 Protsessi ettevalmistamine

See töö koosneb järgmisest ülesandest:

6.8.1.1 Kõikide tarkvaratoodetes ja teostes tuvastatud probleemide (sealhulgas tuvastatud mittevastavuste) käsitlemiseks tuleb luua probleemide lahendamise protsess. Protsess peab vastama järgmistele nõuetele:

a) protsess peab olema tsükliliselt suletud, tagades vastavalt lepingutingimustele: õigeaegse dokumenteerimise ja kõigi avastatud probleemide sisestamise probleemide lahendamise protsessi; nende kallal töökorraldus; asjakohased teated huvitatud isikud nende probleemide kohta; nende esinemise põhjuste väljaselgitamine, analüüs ja võimalik kõrvaldamine;

nendele probleemidele lahenduste elluviimine ja nende kaasamine vastavatesse objektidesse; probleemseisundite arvestus ja dokumenteerimine; probleemiaruannete pidamine;

b) protsess peaks sisaldama skeemi probleemide klassifitseerimiseks ja tähtsuse järjekorda seadmiseks. Iga probleemi jaoks tuleb määrata vastav klass ja prioriteet, et lihtsustada selle tekkimise põhjuste analüüsi ja probleemi lahendamist;

c) probleemiaruanded peaksid sisaldama põhjuste analüüsi;

d) rakendatud probleemide lahendusi ja nende rakendamist vastavates objektides tuleks hinnata järgmiste kriteeriumide alusel: millised probleemid lahendati; millised nende esinemise ebasoodsad põhjused on kõrvaldatud; milliseid muudatusi on vastavates tarkvaratoodetes ja töödes korrektselt tehtud; Milliseid täiendavaid probleeme on avastatud?

6.8.2 Probleemide lahendamine

See töö koosneb järgmisest ülesandest:

6.8.2.1 Kui tarkvaratootes või töös tuvastatakse probleemid (sh avastatud mittevastavused), koostatakse probleemiaruanne, mis kirjeldab iga tuvastatud probleemi. Probleemi aruanne peaks olema lahutamatu osaülalkirjeldatud protsess, mis hõlmab järgmisi küsimusi: probleemide tuvastamine; nende uurimine, analüüs ja lahendused, samuti nende esinemise põhjused; probleemidele kaasa aitavate suundumuste tuvastamine.

elektrotehnikas). See standard määratleb elutsükli struktuuri, mis sisaldab protsesse, tegevusi ja ülesandeid, mis tuleb tarkvarasüsteemi loomisel täita.

Selles PS-standardis (või tarkvara) on defineeritud kui arvutiprogrammide, protseduuride ja võimalik, et nendega seotud dokumentide ja andmete kogum. Protsessi defineeritakse kui omavahel seotud toimingute kogumit, mis teisendavad mõned sisendandmed väljundiks (G. Myers nimetab seda andmete tõlkimiseks). Iga protsessi iseloomustavad teatud ülesanded ja meetodid nende lahendamiseks. Iga protsess on omakorda jagatud tegevuste kogumiks ja iga toiming ülesannete kogumiks. Iga protsessi, toimingu või ülesande algatab ja teostab teine ​​protsess vastavalt vajadusele ning etteantud täitmisjadasid ei ole (muidugi, säilitades samal ajal ühendused sisendandmete vahel).

Tuleb märkida, et Nõukogude Liidus ja seejärel Venemaal loodi tarkvara(PO) reguleeriti algselt, eelmise sajandi 70ndatel, GOST ESPD standarditega ( Ühtne süsteem programmi dokumentatsioon - seeria GOST 19.ХХХ), mis keskendusid üksikute programmeerijate loodud suhteliselt lihtsate väikesemahuliste programmide klassile. Praegu on need standardid kontseptuaalselt ja vormilt aegunud, nende kehtivusaeg on lõppenud ja nende kasutamine on sobimatu.

Loomisprotsessid automatiseeritud süsteemid(AS), mis sisaldab tarkvara, on reguleeritud GOST standarditega 34.601-90 " Infotehnoloogia. Automatiseeritud süsteemide standardite kogum. Loomise etapid", GOST 34.602-89 "Infotehnoloogia. Automatiseeritud süsteemide standardite kogum. Tehniline ülesanne automatiseeritud süsteemi loomiseks" ja GOST 34.603-92 "Infotehnoloogia. Automatiseeritud süsteemide testimise tüübid." Paljud nende standardite sätted on aga aegunud ja teised ei ole piisavalt kajastatud, et neid saaks kasutada tõsiste projektide jaoks PS-i loomisel. Seetõttu on kodumaistes arendustes soovitatav kasutada kaasaegseid rahvusvahelisi standarditele.

Vastavalt ISO / IEC 12207 standardile on kõik tarkvara elutsükli protsessid jagatud kolme rühma (joonis 5.1).

Riis. 5.1.

Rühmad määratlevad viis peamist protsessi: omandamine, tarnimine, arendus, käitamine ja tugi. Kaheksa abiprotsessi tagavad põhiprotsesside täitmise, nimelt dokumentatsioon, Konfiguratsiooni juhtimine, kvaliteedi tagamine, kontrollimine, sertifitseerimine, ühishindamine, audit, probleemide lahendamine. Neli organisatsioonilist protsessi pakuvad juhtimist, infrastruktuuri, täiustamist ja õppimist.

5.2. PS elutsükli peamised protsessid

Omandamise protsess koosneb tarkvara ostva kliendi tegevustest ja ülesannetest. See protsess hõlmab järgmisi samme:

1. omandamise algatamine;
2. pakkumisettepanekute koostamine;
3. lepingu ettevalmistamine ja kohandamine;
4. järelevalve tarnija tegevuse üle;
5. tööde vastuvõtmine ja lõpetamine.

Omandamise algatamine hõlmab järgmisi ülesandeid:

1. kliendi poolt tema vajaduste kindlaksmääramine süsteemi, tarkvaratoodete või teenuste omandamiseks, arendamiseks või täiustamiseks;
2. otsuste tegemine olemasoleva tarkvara soetamise, arendamise või täiustamise kohta;
3. saadavuse kontroll vajalik dokumentatsioon, garantiid, sertifikaadid, litsentsid ja tugi tarkvaratoote ostmisel;
4. soetusplaani koostamine ja kinnitamine, sh süsteeminõuded, lepingu liik, poolte kohustused jne.

Taotlusettepanekud peavad sisaldama:

1. nõuded süsteemile;
2. tarkvaratoodete loend;
3. omandamise ja lepingu tingimused;
4. tehnilised piirangud (näiteks süsteemi töökeskkonna kohta).

Pakkumised saadetakse valitud tarnijale või pakkumise korral mitmele tarnijale. Tarnija on organisatsioon, kes sõlmib kliendiga lepingu süsteemi, tarkvara või tarkvarateenus lepingus määratud tingimustel.

Lepingu ettevalmistamine ja kohandamine hõlmab järgmisi ülesandeid:

1. tarnija valiku korra kindlaksmääramine kliendi poolt, sealhulgas võimalike tarnijate ettepanekute hindamise kriteeriumid;
2. konkreetse tarnija valimine pakkumiste analüüsi põhjal;
3. ettevalmistus ja järeldus lepingud tarnijaga;
4. muudatuste tegemine (vajadusel) lepingus selle täitmise ajal.

Järelevalve tarnija tegevuse üle toimub vastavalt ühistes hindamis- ja auditeerimisprotsessides ette nähtud toimingutele. Vastuvõtmise käigus valmistatakse ette ja tehakse vajalikud testid. Lepingujärgne töö lõpetatakse, kui kõik vastuvõtutingimused on täidetud.

Tarneprotsess hõlmab tegevusi ja ülesandeid, mida teostab tarnija, kes tarnib kliendile tarkvaratoote või -teenuse. See protsess sisaldab järgmisi samme:

1. kohaletoimetamise algatamine;
2. pakkumisettepanekutele vastuse koostamine;
3. lepingu ettevalmistamine;
4. lepingujärgsete tööde planeerimine;
5. teostamine ja kontroll lepinguline töö ja nende hindamine;
6. kohaletoimetamine ja tööde lõpetamine.

Tarne algatamine seisneb selles, et tarnija vaatab pakkumuse ettepanekud läbi ja otsustab, kas nõustuda esitatud nõuete ja tingimustega või pakkuda oma (kokkulepitud). Planeerimine sisaldab järgmisi ülesandeid:

1. tarnijapoolse otsuse tegemine tööde tegemise kohta iseseisvalt või alltöövõtja kaasamisega;
2. tarnija poolt projektijuhtimisplaani väljatöötamine, mis sisaldab organisatsiooniline struktuur projekt, vastutuse jaotus, tehnilised nõuded arenduskeskkonnale ja ressurssidele, alltöövõtjate juhtimisele jne.

Arendusprotsess hõlmab arendaja tegevusi ja ülesandeid ning hõlmab tarkvara ja selle komponentide loomise tööd vastavalt kindlaksmääratud nõuetele. See hõlmab projekteerimis- ja töödokumentatsiooni koostamist, jõudluskontrolliks vajalike materjalide ettevalmistamist ja tarkvaratoodete kvaliteet, personalikoolituse korraldamiseks vajalikud materjalid jne.

Arendusprotsess hõlmab järgmisi samme:

1. ettevalmistustööd;
2. süsteeminõuete analüüs;
3. süsteemiarhitektuuri projekteerimine;
4. tarkvaranõuete analüüs;
5. Tarkvaraarhitektuuri projekteerimine;
6. üksikasjalik tarkvara disain;
7. Tarkvara kodeerimine ja testimine;
8. tarkvara integreerimine;
9. tarkvara kvalifikatsiooni testimine;
10. süsteemi integreerimine;
11. süsteemi kvalifikatsiooni testimine;
12. tarkvara installeerimine;
13. tarkvara aktsepteerimine.

Ettevalmistav töö algab tarkvara elutsükli mudeli valikuga, mis vastab projekti mastaabile, olulisusele ja keerukusele. Arendusprotsessi tegevused ja ülesanded peavad vastama valitud mudelile. Arendaja peab valima, kohanema projekti tingimustega ja kasutama standardeid, meetodeid ja arendustööriistad, samuti koostada tööde teostamise plaan.

Süsteemi nõuete analüüs hõlmab selle kindlaksmääramist funktsionaalsus, kasutaja nõuded, nõuded töökindlusele, turvalisusele, nõuded välistele liidestele, jõudlusele jne. Süsteeminõudeid hinnatakse teostatavuse ja testitavuse kriteeriumide alusel.

Süsteemi arhitektuuri kujundamine hõlmab selle riistvara (riistvara), tarkvara komponentide ja süsteemi opereeriva personali poolt teostatavate toimingute kindlaksmääramist. Süsteemi arhitektuur peab vastama süsteeminõuetele ning aktsepteeritud projekteerimisstandarditele ja tavadele.

Tarkvaranõuete analüüs hõlmab iga tarkvarakomponendi järgmiste omaduste kindlaksmääramist:

1. funktsionaalsus, sealhulgas komponendi jõudlusnäitajad ja töökeskkond;
2. välised liidesed;
3. töökindluse ja ohutuse spetsifikatsioonid;
4. ergonoomilised nõuded;
5. nõuded kasutatavatele andmetele;
6. paigaldus- ja vastuvõtunõuded;
7. nõuded kasutaja dokumentatsioonile;
8. kasutus- ja hooldusnõuded.

Tarkvaranõuete hindamisel lähtutakse süsteemi kui terviku nõuetele vastavuse, teostatavuse ja testitavuse kriteeriumidest.

Tarkvaraarhitektuuri disain sisaldab iga tarkvarakomponendi jaoks järgmisi ülesandeid.

1. tarkvaranõuete muutmine arhitektuuriks, mis määratleb kõrge tase tarkvara struktuur ja selle komponentide koostis;
2. tarkvaraliideste ja andmebaaside (DB) arendamine ja dokumenteerimine;
3. kasutajadokumentatsiooni eelversiooni väljatöötamine;
4. eeltesti nõuete ja tarkvara integratsiooniplaani väljatöötamine ja dokumenteerimine.

Üksikasjalik tarkvaraprojekt sisaldab järgmisi ülesandeid:

1. tarkvarakomponentide ja nendevaheliste liideste kirjeldus madalamal tasemel, mis on piisav järgnevaks kodeerimiseks ja testimiseks;
2. üksikasjaliku andmebaasi kujunduse väljatöötamine ja dokumenteerimine;
3. kasutajadokumentatsiooni uuendamine (vajadusel);
4. tarkvarakomponentide testimisnõuete ja testimisplaani väljatöötamine ja dokumenteerimine;

Tarkvara kodeerimine ja testimine hõlmab järgmisi ülesandeid:

1. iga tarkvarakomponendi ja andmebaasi kodeerimine ja dokumenteerimine, samuti testimisprotseduuride komplekti ja andmete koostamine nende testimiseks;
2. iga tarkvara ja andmebaasi komponendi testimine nende nõuetele vastavuse osas, millele järgneb testimistulemuste dokumenteerimine;
3. dokumentatsiooni uuendamine (vajadusel);
4. tarkvara integreerimisplaani värskendamine.

Tarkvara integreerimine hõlmab arendatud tarkvarakomponentide kokkupanemist vastavalt koondatud komponentide integreerimis- ja testimisplaanile. Iga koondatud komponendi jaoks töötatakse välja katsekomplektid ja testimisprotseduurid, et kontrollida iga kvalifikatsiooninõudeid järgneva kvalifikatsiooni testimise käigus. Kvalifikatsiooninõue on kriteeriumide või tingimuste kogum, mis peavad kvalifitseerumiseks olema täidetud. tarkvara kui vastab spetsifikatsioonidele ja on valmis kasutamiseks põllul.

Tarkvara kvalifikatsiooni testimise viib läbi arendaja kliendi juuresolekul (

Tööprotsess hõlmab süsteemi käitava operaatoriorganisatsiooni tegevusi ja ülesandeid. Toimimisprotsess sisaldab järgmisi samme.

1. Ettevalmistustööd, mille käigus operaator täidab järgmisi ülesandeid:

   1. käitamise ajal tehtavate tegevuste ja tööde planeerimine ning tegevusnormide seadmine;
   2. töö käigus tekkivate probleemide lokaliseerimise ja lahendamise protseduuride määramine.
2. Tarkvaratoote iga järgmise väljaande jaoks viiakse läbi talitlustestid, mille järel see väljaanne kasutusele võetakse.
3. Süsteemi tegelik toimimine, mida teostatakse selleks ettenähtud keskkonnas vastavalt kasutaja dokumentatsioonile.
4. probleemide ja tarkvara muutmistaotluste analüüs (probleemi või muutmistaotluse teadete analüüs, mastaabi hindamine, muutmise maksumus, sellest tulenev mõju, muutmise teostatavuse hindamine);
5. tarkvara muutmine (tarkvaratoote komponentides ja dokumentatsioonis muudatuste tegemine vastavalt arendusprotsessi reeglitele);
6. kontrollimine ja aktsepteerimine (muudetud süsteemi terviklikkuse osas);
7. tarkvara üleviimine teise keskkonda (programmide ja andmete teisendamine, tarkvara paralleelne töötamine vanas ja uues keskkonnas teatud aja jooksul);
8. tarkvara dekomisjoneerimine kliendi otsusel opereeriva organisatsiooni, tugiteenuse ja kasutajate osalusel. Sel juhul kuuluvad tarkvaratooted ja dokumentatsioon lepingu kohaselt arhiveerimisele.

Riis. 5.2.

Need aspektid on:

1. lepinguline aspekt, milles klient ja tarnija sõlmivad lepingulised suhted ning viivad ellu hanke- ja tarneprotsesse;
2. juhtimisaspekt, mis hõlmab tarkvara elutsüklis osalevate isikute (tarnija, tellija, arendaja, operaatori jne) juhtimistoiminguid;
3. operatiivne aspekt, mis hõlmab operaatori tegevust süsteemi kasutajatele teenuste osutamisel;
4. inseneriaspekt, mis sisaldab arendaja või tugiteenuse tegevust tarkvaratoodete arendamise või muutmisega seotud tehniliste probleemide lahendamiseks;
5. Toe aspekt, mis on seotud tugiprotsesside rakendamisega, mille kaudu kasutajatoed pakuvad vajalikke teenuseid kõigile teistele töös osalejatele. Selles aspektis saame esile tõsta tarkvara kvaliteedijuhtimise aspekti, mis hõlmab kvaliteedi tagamise protsesse, verifitseerimist, sertifitseerimist, ühishindamist ja auditit.

Organisatsioonilised protsessid viiakse läbi ettevõtte tasandil või kogu organisatsiooni kui terviku tasandil, luues aluse tarkvara elutsükli protsesside juurutamiseks ja pidevaks täiustamiseks.

5.6. Tarkvara elutsükli mudelid ja etapid

Tarkvara elutsükli mudeli all mõistetakse struktuuri, mis määratleb protsesside, toimingute ja ülesannete täitmise ja seosed kogu tarkvara elutsükli jooksul. Elutsükli mudel sõltub projekti spetsiifikast, ulatusest ja keerukusest ning konkreetsetest tingimustest, milles süsteem luuakse ja töötab.

ISO/IEC 12207 standard ei paku konkreetset elutsükli mudelit ja tarkvara arendusmeetodeid. Selle sätted on üldised kõigi olelustsükli mudelite, meetodite ja tarkvaraarendustehnoloogiate kohta. Standard kirjeldab tarkvara elutsükli protsesside struktuuri, kuid ei täpsusta, kuidas nendes protsessides sisalduvaid toiminguid ja ülesandeid rakendada või sooritada.

Iga konkreetse tarkvara elutsükli mudel määrab selle loomise protsessi olemuse, mis on ajas järjestatud, omavahel seotud ja etappideks (faasideks) kombineeritud tööde kogum, mille realiseerimine on vajalik ja piisav, et luua tarkvara, mis vastab nõuetele. määratud nõuded.

Tarkvara loomise etappi (faasi) mõistetakse tarkvara loomise protsessi osana, mis on piiratud kindla ajaraamiga ja lõpeb konkreetse toote (tarkvaramudelid, tarkvarakomponendid, dokumentatsioon jne) väljalaskmisega, mis on määratud nõuetega. selle etapi jaoks määratud. Tarkvara loomise etapid eristatakse ratsionaalse planeerimise ja kindlate tulemustega lõppeva töö korraldamise kaalutlustel. Tarkvara elutsükkel sisaldab tavaliselt järgmisi etappe:

1. tarkvaranõuete kujundamine;
2. projekteerimine (süsteemiprojekti väljatöötamine);
3. teostus (võib jaotada alaetappideks: detailplaneering, kodeerimine);
4. testimine (võib jaotada eraldiseisvaks ja integreeritud testimiseks ja integreerimiseks);
5. kasutuselevõtt (elluviimine);
6. käitamine ja hooldus;
7. dekomisjoneerimine.

Mõned eksperdid tutvustavad täiendavat algetappi - teostatavusanalüüs süsteemid. Siin peame silmas riist- ja tarkvarasüsteemi, mille jaoks tarkvara luuakse, ostetakse või muudetakse.

Tarkvaranõuete kujundamise etapp on üks olulisemaid ja määrab olulisel (isegi otsustaval!) määral kogu projekti edukuse. Selle etapi alguseks on kinnitatud ja kinnitatud süsteemiarhitektuuri hankimine, sealhulgas põhikokkulepped funktsioonide jaotamise kohta riist- ja tarkvara vahel. See dokument peaks sisaldama ka kinnitust üldise arusaamise kohta tarkvara toimimisest, sealhulgas põhikokkulepetest funktsioonide jaotamise kohta isiku ja süsteemi vahel.

Tarkvaranõuete koostamise etapp sisaldab järgmisi etappe.

1. Tööde planeerimine enne projekti kallal töötamist. Etapi põhieesmärgid on arengueesmärkide määramine, esialgne majanduslik hinnang projekt, töögraafiku koostamine, ühise töörühma loomine ja koolitamine.
2. Automatiseeritud organisatsiooni (objekti) tegevuse uuringu läbiviimine, mille raames viiakse läbi tulevase süsteemi nõuete esialgne väljaselgitamine, organisatsiooni struktuuri kindlaksmääramine, organisatsiooni sihtfunktsioonide loetelu kindlaksmääramine, funktsioonide jaotuse analüüs osakondade ja töötajate vahel, osakondadevaheliste funktsionaalsete interaktsioonide tuvastamine, infovood osakondade sees ja vahel, organisatsioonivälised objektid ja välised infomõjud, organisatsiooni tegevuse automatiseerimise olemasolevate vahendite analüüs.

Organisatsiooni (objekti) tegevuse mudeli koostamine, mis hõlmab uuringumaterjalide töötlemist ja kahte tüüpi mudelite koostamist:

• mudel "NAGU IS" ("nagu on"), mis peegeldab organisatsiooni hetkeseisu küsitluse ajal ja võimaldab mõista, kuidas see organisatsioon toimib, ning tuvastada kitsad kohad ja sõnastada ettepanekuid olukorra parandamiseks;
• mudel "TO-BE" ("kuidas see peaks olema"), peegeldades organisatsiooni uute tehnoloogiate ideed.

Iga mudel peaks sisaldama organisatsiooni tegevuse terviklikku funktsionaalset ja infomudelit, samuti (vajadusel) organisatsiooni käitumise dünaamikat kirjeldavat mudelit. Pange tähele, et konstrueeritud mudelitel on iseseisev praktiline tähendus, olenemata sellest, kas ettevõte hakkab välja töötama ja juurutama Infosüsteem, sest nende abiga saate koolitada töötajaid ja parandada ettevõtte äriprotsesse.

Tarkvaranõuete genereerimise etapi läbimise tulemuseks on tarkvara spetsifikatsioonid, funktsionaalsed, tehnilised ja liidese spetsifikatsioonid, mille puhul kinnitatakse nende täielikkus, kontrollitavus ja teostatavus.

Projekteerimisetapp sisaldab järgmisi etappe.

1. Tarkvarasüsteemi projekti väljatöötamine. Selles etapis antakse vastus küsimusele “Mida peaks tulevane süsteem tegema?”, nimelt: süsteemi arhitektuur, selle funktsioonid, välised töötingimused, liidesed ja funktsioonide jaotus kasutajate ja süsteemi vahel, nõuded tarkvarale. ja infokomponendid, esinejate koosseis ja tähtajad määratakse arendus, tarkvara silumisplaan ja kvaliteedikontroll.

   Süsteemiprojekti aluseks on projekteeritud süsteemi mudelid, mis on üles ehitatud “TO-BE” mudelile. Süsteemiprojekti väljatöötamise tulemuseks peab olema kinnitatud ja kinnitatud tarkvaranõuete spetsifikatsioon: funktsionaalsed, tehnilised ja liidese spetsifikatsioonid, mille puhul on kinnitatud nende täielikkus, kontrollitavus ja teostatavus.

2. Detailse (tehnilise) projekti väljatöötamine. Selles etapis viiakse läbi tegelik tarkvara projekteerimine, sealhulgas süsteemi arhitektuur ja detailne projekteerimine. Seega antakse vastus küsimusele: "Kuidas ehitada süsteem nii, et see vastaks nõuetele?"

Detailse projekteerimise tulemuseks on kontrollitud tarkvara spetsifikatsiooni väljatöötamine, sealhulgas:

• tarkvarakomponentide hierarhia moodustamine, moodulitevahelised liidesed andmete ja halduse jaoks;
• iga tarkvarakomponendi spetsifikatsioon, nimi, eesmärk, eeldused, mõõtmed, kõnede jada, sisend- ja väljundandmed, vead väljundid, algoritmid ja loogikalülitused;
• füüsiliste ja loogiliste andmestruktuuride moodustamine kuni üksikute väljade tasemeni;
• arvutusressursside (keskprotsessori aeg, mälu jne) jaotamise plaani väljatöötamine;
• nõuete täielikkuse, järjepidevuse, teostatavuse ja kehtivuse kontrollimine;
• integreerimise ja silumise esialgne plaan, kasutusjuhendi ja vastuvõtutestimise plaan.

Detailprojekti valmimine on otsast lõpuni

Teema 3. Tarkvara elutsükkel 28

Tarkvara elutsükkel

Vastavalt standardile on kõik tarkvara elutsükli protsessid jagatud kolme rühma:

viis peamist protsessi (ost, tarnimine, arendus, käitamine, tugi.

Kaheksa tugiprotsessi, mis toetavad põhiprotsesse (dokumentatsioon, konfiguratsioonihaldus, kvaliteedi tagamine, kontrollimine, valideerimine, vastastikune hindamine, audit, probleemide lahendamine).

Neli organisatsioonilist protsessi (juhtimine, infrastruktuuri loomine, täiustamine, koolitus).

TARKVARA ELUTSÜKLI PÕHIPROTSESSID

Omandamise protsess.

See koosneb tarkvara ostva kliendi tegevustest ja ülesannetest. See protsess hõlmab järgmisi samme:

omandamise algatamine;

pakkumisettepanekute koostamine;

lepingu ettevalmistamine ja kohandamine;

järelevalve tarnija tegevuse üle;

tööde vastuvõtmine ja lõpetamine.

Omandamise algatamine hõlmab järgmisi ülesandeid:

kliendi poolt tema vajaduste kindlaksmääramine süsteemi, tarkvaratoodete või teenuste omandamiseks, arendamiseks või täiustamiseks;

süsteeminõuete analüüs;

otsuste tegemine olemasoleva tarkvara soetamise, arendamise või täiustamise kohta;

tarkvaratoote ostmisel vajaliku dokumentatsiooni, garantiide, sertifikaatide, litsentside ja toe olemasolu kontrollimine;

hankeplaani koostamine ja kinnitamine, sealhulgas süsteeminõuded, lepingu tüüp, poolte kohustused jne. Pakkumisettepanekud peavad sisaldama:

Nõuded süsteemile;

tarkvaratoodete loend;

tingimused ja kokkulepped;

tehnilised piirangud (näiteks süsteemi töökeskkond).

Pakkumised saadetakse valitud tarnijale (või pakkumise korral mitmele tarnijale). Tarnija on organisatsioon, kes sõlmib kliendiga lepingu tarkvarasüsteemi või tarkvarateenuse tarnimiseks lepingus määratud tingimustel.

Lepingu ettevalmistamine ja kohandamine hõlmab järgmisi ülesandeid:

tarnija valiku korra kindlaksmääramine kliendi poolt, sealhulgas võimalike tarnijate ettepanekute hindamise kriteeriumid;

konkreetse tarnija valimine pakkumiste analüüsi põhjal;

lepingu koostamine ja sõlmimine tarnijaga;

muudatuste tegemine (vajadusel) lepingus selle täitmise ajal.

Järelevalve tarnija tegevuse üle toimub vastavalt ühistes hindamis- ja auditeerimisprotsessides ette nähtud toimingutele.

Vastuvõtmise käigus valmistatakse ette ja tehakse vajalikud testid. Lepingujärgne töö lõpetatakse, kui kõik vastuvõtutingimused on täidetud.

Tarneprotsess.

See hõlmab tegevusi ja ülesandeid, mida teostab müüja, kes tarnib kliendile tarkvaratoote või -teenuse. See protsess sisaldab järgmisi samme:

kohaletoimetamise algatamine;

pakkumisettepanekutele vastuse koostamine;

lepingu ettevalmistamine;

planeerimine;

teostamine ja kontroll;

ülevaatus ja hindamine;

kohaletoimetamine ja tööde lõpetamine.

Tarne algatamine seisneb selles, et tarnija vaatab pakkumiste ettepanekud läbi ja teeb otsuse, kas nõustuda esitatud nõuete ja tingimustega või pakkuda oma.

Planeerimine sisaldab järgmisi ülesandeid:

tarnijapoolse otsuse tegemine tööde tegemise kohta iseseisvalt või alltöövõtja kaasamisega;

tarnijapoolne projektijuhtimisplaani väljatöötamine, mis sisaldab projekti organisatsioonilist struktuuri, vastutusalade jaotust, tehnilisi nõudeid arenduskeskkonnale ja ressurssidele, alltöövõtjate juhtimist jne.

Arendusprotsess.

See näeb ette arendaja toimingud ja ülesanded ning hõlmab tarkvara ja selle komponentide loomist vastavalt kindlaksmääratud nõuetele, sealhulgas projekteerimis- ja töödokumentatsiooni koostamist, tarkvara funktsionaalsuse ja sobiva kvaliteedi testimiseks vajalike materjalide ettevalmistamist. koolituspersonali korraldamiseks vajalikud tooted, materjalid jms.

Arendusprotsess hõlmab järgmisi samme:

ettevalmistustööd;

süsteeminõuete analüüs;

süsteemiarhitektuuri projekteerimine;

tarkvaranõuete analüüs;

Tarkvaraarhitektuuri projekteerimine;

üksikasjalik tarkvara disain;

Tarkvara kodeerimine ja testimine;

tarkvara integreerimine;

tarkvara kvalifikatsiooni testimine;

süsteemi integreerimine;

süsteemi kvalifikatsiooni testimine;

tarkvara installeerimine;

tarkvara aktsepteerimine.

Ettevalmistav töö algab tarkvara elutsükli mudeli valikuga, mis sobib projekti mastaabi, olulisuse ja keerukusega. Arendusprotsessi tegevused ja ülesanded peavad vastama valitud mudelile. Arendaja peab valima, kohandama projekti tingimustega ja kasutama tellijaga kokkulepitud standardeid, meetodeid ja arendusvahendeid ning koostama ka tööde teostamise plaani.

Süsteeminõuete analüüs hõlmab selle funktsionaalsuse, kasutajanõuete, töökindlus- ja turvanõuete, välisliidese nõuete jms kindlaksmääramist. Süsteeminõudeid hinnatakse teostatavuse ja testitavuse kriteeriumide alusel.

Süsteemi arhitektuuri kõrgel tasemel kujundamine seisneb selle riistvarakomponentide, tarkvara ja süsteemi opereeriva personali poolt teostatavate toimingute määratlemises. Süsteemi arhitektuur peab vastama süsteeminõuetele ning aktsepteeritud projekteerimisstandarditele ja tavadele.

Tarkvaranõuete analüüs hõlmab iga tarkvarakomponendi järgmiste omaduste kindlaksmääramist:

funktsionaalsus, sealhulgas komponendi jõudlusnäitajad ja töökeskkond;

välised liidesed;

töökindluse ja ohutuse spetsifikatsioonid;

ergonoomilised nõuded;

nõuded kasutatavatele andmetele;

paigaldus- ja vastuvõtunõuded;

nõuded kasutaja dokumentatsioonile;

kasutus- ja hooldusnõuded.

Tarkvaranõudeid hinnatakse süsteeminõuetele vastavuse, teostatavuse ja testimise käigus kontrollitavuse kriteeriumide alusel.

Tarkvaraarhitektuuri kujundamine sisaldab järgmisi ülesandeid (iga tarkvarakomponendi jaoks):

tarkvaranõuete muutmine arhitektuuriks, mis määratleb kõrgel tasemel tarkvara struktuuri ja selle komponentide koostise;

Tarkvaraliideste ja andmebaaside arendamine ja dokumenteerimine;

kasutajadokumentatsiooni eelversiooni väljatöötamine;

eeltesti nõuete ja tarkvara integratsiooniplaani väljatöötamine ja dokumenteerimine.

Tarkvarakomponentide arhitektuur peab vastama neile esitatavatele nõuetele, samuti aktsepteeritud projekteerimisstandarditele ja -meetoditele.

Üksikasjalik tarkvaraprojekt sisaldab järgmisi ülesandeid:

tarkvarakomponentide ja nendevaheliste liideste kirjeldus madalamal tasemel, mis on piisav nende hilisemaks iseseisvaks kodeerimiseks ja testimiseks;

üksikasjaliku andmebaasi kujunduse väljatöötamine ja dokumenteerimine;

kasutajadokumentatsiooni uuendamine (vajadusel);

tarkvarakomponentide testimisnõuete ja testimisplaani väljatöötamine ja dokumenteerimine;

Tarkvara kodeerimine ja testimine hõlmab järgmisi ülesandeid:

iga tarkvarakomponendi ja andmebaasi arendamine (kodeerimine) ja dokumenteerimine, samuti testimisprotseduuride komplekt ja andmed nende testimiseks;

iga tarkvarakomponendi ja andmebaasi testimine neile kehtestatud nõuetele vastavuse osas. Komponentide testimise tulemused tuleb dokumenteerida;

kasutajadokumentatsiooni uuendamine (vajadusel);

tarkvara integreerimisplaani värskendamine.

Tarkvara integreerimine hõlmab väljatöötatud tarkvarakomponentide kokkupanemist vastavalt integratsiooniplaanile ja koondatud komponentide testimist. Iga koondatud komponendi jaoks töötatakse välja katsekomplektid ja testimisprotseduurid, et kontrollida iga kvalifikatsiooninõudeid järgneva kvalifikatsiooni testimise käigus. Kvalifikatsiooninõue on kriteeriumide või tingimuste kogum, mis peavad olema täidetud, et kvalifitseerida tarkvaratoode spetsifikatsioonidele vastavaks ja selles valdkonnas kasutamiseks valmis.

Tarkvara kvalifikatsiooni testimise viib arendaja läbi kliendi juuresolekul (võimaluse korral), et näidata, et tarkvara vastab spetsifikatsioonidele ja on valmis välitingimustes kasutamiseks. Kvalifikatsioonitestid viiakse läbi iga tarkvarakomponendi jaoks kõigis nõuete jaotistes, kasutades laia valikut teste. Samal ajal kontrollitakse ka tehnilise ja kasutajadokumentatsiooni täielikkust ning selle vastavust tarkvarakomponentidele endile.

Süsteemi integreerimine seisneb kõigi selle komponentide, sealhulgas tarkvara ja riistvara kokkupanemises. Pärast integreerimist läbib süsteem omakorda kvalifikatsioonitesti, et kontrollida, kas see vastab sellele kehtestatud nõuetele. Samal ajal koostatakse ja kontrollitakse ka süsteemi täielikku dokumentatsiooni.

Tarkvara paigalduse teostab arendaja vastavalt plaanile lepingus ettenähtud keskkonnas ja seadmetele. Installimise käigus kontrollitakse tarkvara ja andmebaaside funktsionaalsust. Kui installitud tarkvara asendab olemasolevat süsteemi, peab arendaja tagama nende paralleelse toimimise vastavalt lepingule.

Tarkvara aktsepteerimine hõlmab tarkvara ja süsteemi kvalifikatsiooni testimise tulemuste hindamist ning hindamistulemuste dokumenteerimist, mille teostab arendaja abiga klient. Arendaja teostab kliendile tarkvara lõpliku tarnimise vastavalt lepingule, pakkudes samas vajalikku koolitust ja tuge.

Toimimisprotsess.

See hõlmab operaatori – süsteemi haldava organisatsiooni – tegevusi ja ülesandeid. See protsess sisaldab järgmisi samme:

1) ettevalmistustööd;

2) töökatsetused;

3) süsteemi toimimine;

4) kasutajatugi.

Ettevalmistustöö hõlmab operaatori järgmiste ülesannete täitmist:

käitamise ajal tehtavate tegevuste ja tööde planeerimine ning tegevusnormide seadmine;

töö käigus tekkivate probleemide lokaliseerimise ja lahendamise protseduuride määramine.

Tarkvaratoote iga järgneva väljaande jaoks viiakse läbi talitlustestid, misjärel see kasutusele võetakse.

Süsteemi käitatakse selleks ettenähtud keskkonnas vastavalt kasutaja dokumentatsioonile.

Kasutajatugi seisneb abi ja nõustamises, kui tarkvara töö käigus avastatakse vigu.

Hooldusprotsess.

See näeb ette toimingud ja ülesanded, mida saateorganisatsioon (eskortteenus) täidab. See protsess aktiveerub, kui tarkvaratoote ja sellega seotud dokumentatsiooni muudatused (muudatused) on põhjustatud probleemidest või vajadusest tarkvara moderniseerimiseks või kohandamiseks. IEEE-90 standardi kohaselt tähendab hooldus tarkvara muudatuste tegemist vigade parandamiseks, jõudluse parandamiseks või muutuvate töötingimuste või nõuetega kohanemiseks.

Olemasolevas tarkvaras tehtud muudatused ei tohi rikkuda selle terviklikkust. Hooldusprotsess hõlmab tarkvara teisaldamist teise keskkonda (migratsiooni) ja lõpeb tarkvara dekomisjoneerimisega.

Hooldusprotsess hõlmab järgmisi toiminguid:

ettevalmistustööd;

probleemide ja tarkvara muutmise taotluste analüüs;

tarkvara muutmine;

ülevaatus ja vastuvõtmine;

tarkvara teisaldamine teise keskkonda;

tarkvara dekomisjoneerimine.

Saateteenistuse ettevalmistustöö hõlmab järgmisi ülesandeid:

tugiprotsessi käigus tehtavate toimingute ja tööde kavandamine;

hooldusprotsessi käigus tekkivate probleemide lokaliseerimise ja lahendamise protseduuride määramine.

Tugiteenuse teostatud probleemide ja tarkvara muutmise taotluste analüüs hõlmab järgmisi ülesandeid:

probleemiraporti või tarkvara muutmise taotluse analüüs selle mõju kohta organisatsioonile, olemasolevale süsteemile ja liidestele teiste süsteemidega. Sel juhul määratakse võimaliku modifikatsiooni järgmised omadused: tüüp (korrigeeriv, parandav, ennetav või uue keskkonnaga kohanemine); ulatus (muudatuse suurus, maksumus ja selle rakendamise aeg); kriitilisus (mõju jõudlusele, töökindlusele või ohutusele);

muutmise teostatavuse hindamine ja selle teostamise võimalikud variandid;

valitud muutmisvaliku heakskiit. Tarkvara muutmine hõlmab tarkvarakomponentide määratlemist,

nende versioonid ja dokumentatsioon võivad muutuda ning teha vajalikud muudatused vastavalt arendusprotsessi reeglitele. Ettevalmistatud muudatusi testitakse ja kontrollitakse vastavalt dokumentatsioonis määratletud kriteeriumidele. Kui programmide muudatuste õigsus on kinnitatud, korrigeeritakse dokumentatsiooni.

Kontrollimine ja aktsepteerimine seisneb muudetud süsteemi terviklikkuse kontrollimises ja tehtud muudatuste kinnitamises.

Tarkvara teise keskkonda migreerimisel kasutatakse olemasolevaid migratsioonitööriistu või töötatakse välja uued ning seejärel teisendatakse programmid ja andmed uude keskkonda. Ülemineku hõlbustamiseks on ette nähtud tarkvara paralleelne töötamine vanas ja uues keskkonnas teatud perioodi jooksul, mil viiakse läbi vajalik kasutajakoolitus uues keskkonnas töötamiseks.

Tarkvara dekomisjoneerimine toimub kliendi äranägemisel opereeriva organisatsiooni, tugiteenistuse ja kasutajate osalusel. Sel juhul kuuluvad tarkvaratooted ja nendega seotud dokumentatsioon lepingu kohaselt arhiveerimisele. Sarnaselt tarkvara teisaldamisega teise keskkonda, et hõlbustada üleminekut uus süsteem Vana ja uue tarkvara paralleelne töö on ette nähtud teatud perioodiks, mille jooksul viiakse läbi kasutajate vajalik koolitus uue süsteemiga töötamiseks.

TARKVARA ELU MUUTMISE ABIPROTSESSID

Dokumenteerimisprotsess.

See annab vormistatud kirjelduse tarkvara elutsükli jooksul loodud teabest. Protsess koosneb tegevuste kogumist, mis kavandavad, kujundavad, arendavad, toodavad, redigeerivad, levitavad ja hooldavad dokumente, mida vajavad kõik sidusrühmad, nagu juhtkond, tehnikud ja süsteemi kasutajad.

Dokumenteerimisprotsess hõlmab järgmisi samme:

ettevalmistustööd;

projekteerimine ja arendus;

dokumentatsiooni väljastamine;

saatel.

Konfiguratsioonihaldusprotsess.

See hõlmab haldus- ja tehniliste protseduuride kasutamist kogu tarkvara elutsükli jooksul, et teha kindlaks tarkvarakomponentide olek süsteemis, hallata tarkvara muudatusi, kirjeldada ja koostada aruandeid tarkvarakomponentide oleku kohta.

ja muutmistaotlused, tarkvarakomponentide täielikkuse, ühilduvuse ja õigsuse tagamine, tarkvara hoidmise ja tarnimise haldamine.

Konfiguratsioonihaldusprotsess sisaldab järgmisi samme:

ettevalmistustööd;

konfiguratsiooni tuvastamine;

konfiguratsiooni juhtimine;

konfiguratsiooni oleku arvestus;

konfiguratsiooni hindamine;

väljalaske haldamine ja kohaletoimetamine.

Ettevalmistav töö hõlmab konfiguratsioonihalduse planeerimist.

Konfiguratsioonituvastus kehtestab reeglid, mida saab kasutada tarkvarakomponentide ja nende versioonide unikaalseks tuvastamiseks ja eristamiseks. Lisaks vastab iga komponent ja selle versioon unikaalsele dokumentatsioonikomplektile, mis loob aluse tarkvarakomponentide versioonide ühemõtteliseks valimiseks ja nendega manipuleerimiseks, kasutades selleks piiratud ja järjestatud sümbolite süsteemi, mis identifitseerib tarkvara erinevaid versioone.

Konfiguratsioonikontroll on mõeldud kavandatavate tarkvaramuudatuste süstemaatiliseks hindamiseks ja nende rakendamise koordineerimiseks, võttes arvesse iga modifikatsiooni efektiivsust ja selle rakendamise kulusid. See võimaldab kontrollida tarkvarakomponentide ja nende versioonide olekut ja arengut, samuti tegelikult muutuvate komponentide ja nende täieliku dokumentatsiooni adekvaatsust.

Konfiguratsiooni oleku arvestus on tarkvarakomponentide oleku registreerimine, aruannete koostamine tarkvarakomponentide versioonide kõigi rakendatud ja tagasilükatud muudatuste kohta. Aruannete kogum annab ühemõttelise ülevaate süsteemi ja selle komponentide hetkeseisust ning säilitab muudatuste ajaloo.

Konfiguratsiooni hindamine seisneb tarkvarakomponentide funktsionaalse terviklikkuse ning nende füüsilise seisundi vastavuse hindamises kehtivale tehnilisele kirjeldusele.

Väljaannete haldamine ja edastamine hõlmab programmide ja dokumentatsiooni põhikoopiate valmistamist, nende salvestamist ja kasutajatele edastamist vastavalt organisatsioonilistele protseduuridele.

Kvaliteedi tagamise protsess.

See tagab asjakohase tagatise, et tarkvara ja selle elutsükli protsessid vastavad kindlaksmääratud nõuetele ja kinnitatud plaanidele. Tarkvara kvaliteedi all mõistetakse omaduste kogumit, mis iseloomustavad tarkvara võimet täita kindlaksmääratud nõudeid.

Loodavale tarkvarale usaldusväärse hinnangu saamiseks peab selle kvaliteedi tagamise protsess toimuma tarkvaraarendusega otseselt seotud üksustest sõltumatult. Kasutada võib muude toetavate protsesside, nagu kontrollimine, valideerimine, ühishindamine, audit ja probleemide lahendamine, tulemusi.

Kvaliteedi tagamise protsess hõlmab järgmisi tegevusi:

ettevalmistustööd;

toote kvaliteedi tagamine;

protsessi kvaliteedi tagamine;

süsteemi kvaliteedi muude näitajate tagamine.

Ettevalmistustöö seisneb kooskõlastamises teiste toetavate protsessidega ning kvaliteedi tagamise protsessi enda planeerimises, arvestades kasutatavaid standardeid, meetodeid, protseduure ja vahendeid.

Tootekvaliteedi tagamine tähendab tarkvaratoodete ja nende dokumentatsiooni täielikku vastavust lepingus sätestatud kliendi nõuetele.

Protsessi kvaliteedi tagamine hõlmab tarkvara elutsükli protsesside, arendusmeetodite, arenduskeskkonna ja personali kvalifikatsiooni vastavuse tagamist lepingutingimustele, kehtestatud standarditele ja protseduuridele.

Süsteemi muude kvaliteedinäitajate tagamine toimub vastavalt lepingutingimustele.

Kinnitusprotsess.

See seisneb kindlaksmääramises, et tarkvaratooted, mis on mõne tegevuse tulemuseks, vastavad täielikult eelnevate toimingute poolt määratud nõuetele või tingimustele (kinnitamine kitsamas tähenduses tähendab tarkvara õigsuse formaalset tõendamist). Tõhususe parandamiseks tuleks kontrollimine võimalikult varakult integreerida seda kasutavate protsessidega (nt tarnimine, arendus, käitamine või hooldus). See protsess võib hõlmata analüüsi, hindamist ja testimist.

Kontrolli saab läbi viia erineva sõltumatuse astmega. Sõltumatuse aste võib varieeruda alates töövõtja enda või antud organisatsiooni mõne muu spetsialisti poolt teostatavast kontrollist kuni teise organisatsiooni spetsialisti poolt läbiviidava erinevate variatsioonidega. Kui verifitseerimisprotsessi viib läbi tarnijast, arendajast, operaatorist või tugiteenusest sõltumatu organisatsioon, nimetatakse seda sõltumatuks kontrolliprotsessiks.

Kinnitusprotsess hõlmab järgmisi samme.

1) ettevalmistustööd;

2) kontrollimine.

Kinnitusprotsessi käigus kontrollitakse järgmisi tingimusi:

süsteemile esitatavate nõuete järjepidevus ja kasutajate vajaduste arvessevõtmise määr;

tarnija suutlikkus täita kindlaksmääratud nõudeid;

valitud elutsükli protsesside vastavus lepingutingimustele;

standardite, protseduuride ja arenduskeskkonna adekvaatsus tarkvara elutsükli protsessidele;

tarkvara disaini spetsifikatsioonide vastavus kindlaksmääratud nõuetele;

kirjelduse õigsus sisend- ja väljundandmetees, sündmuste jada, liidesed, loogika jne;

koodi vastavus projekti spetsifikatsioonidele ja nõuetele;

koodi testitavus ja korrektsus, vastavus aktsepteeritud kodeerimisstandarditele;

tarkvara komponentide korrektne integreerimine süsteemi;

dokumentatsiooni piisavus, täielikkus ja järjepidevus.

Sertifitseerimisprotsess.

See hõlmab kindlaksmääratud nõuete ja loodud süsteemi või tarkvaratoote konkreetsele funktsionaalsele otstarbele vastavuse täielikkuse kindlakstegemist. Sertifitseerimine tähendab tavaliselt tarkvara testimise usaldusväärsuse kinnitamist ja hindamist. Sertifitseerimine peab tagama, et tarkvara vastab täielikult spetsifikatsioonidele, nõuetele ja dokumentatsioonile ning et kasutaja saab seda ohutult ja usaldusväärselt kasutada. Sertifitseerimine on soovitatav läbi viia testides kõigis võimalikes olukordades ja kasutades sõltumatuid spetsialiste. Sertifitseerimist saab läbi viia tarkvara elutsükli algfaasis või tarkvara vastuvõtutöö osana.

Sertifitseerimist, nagu ka kontrollimist, saab läbi viia erineva sõltumatuse astmega. Kui sertifitseerimisprotsessi viib läbi organisatsioon, mis on müüjast, arendajast, operaatorist või tugiteenusest sõltumatu, nimetatakse seda kolmanda osapoole sertifitseerimisprotsessiks.

Sertifitseerimisprotsess hõlmab järgmisi samme:

ettevalmistustööd;

sertifitseerimine.

Osalushindamise protsess.

Selle eesmärk on hinnata projektiga seotud tööde ja nende tööde (toimingute) teostamise käigus loodud tarkvara seisu. See keskendub eelkõige projektiressursside, personali, seadmete ja tööriistade planeerimise ja juhtimise kontrollimisele.

Hindamist rakendatakse nii projektijuhtimise kui ka projekti tehnilise elluviimise tasandil ning see viiakse läbi kogu lepingu kehtivusaja jooksul. Seda protsessi võivad läbi viia kaks lepinguosalist, kusjuures üks pool kontrollib teist.

Osalushindamise protsess sisaldab järgmisi samme:

ettevalmistustööd;

projektijuhtimise hindamine;

tehniline hinnang.

Auditiprotsess.

See on nõuete, plaanide ja lepingutingimuste täitmise kindlaksmääramine. Auditi võivad läbi viia kaks lepinguosalist, kusjuures üks pool auditeerib teist.

Audit on audit (kontroll), mille viib läbi pädev asutus (isik), et anda sõltumatu hinnang tarkvara või protsesside vastavuse astmele kehtestatud nõuetele. Auditi eesmärk on kontrollida vastavust päris töö ning aruanded nõuetele, plaanidele ja lepingule. Audiitoritel (inspektoritel) ei tohiks olla otsest sõltuvust tarkvaraarendajatest. Need määravad kindlaks töö seisu, ressursside kasutamise, dokumentatsiooni vastavuse spetsifikatsioonidele ja standarditele ning testimise õigsuse.

Auditiprotsess sisaldab järgmisi samme:

ettevalmistustööd;

Probleemi lahendamise protsess.

See hõlmab arenduse, käitamise, hoolduse või muude protsesside käigus avastatud probleemide (sh tuvastatud ebakõlade) analüüsi ja lahendamist olenemata nende päritolust või allikast. Iga avastatud probleem tuleb tuvastada, kirjeldada, analüüsida ja lahendada.

Probleemi lahendamise protsess hõlmab järgmisi samme:

1) ettevalmistustööd;

2) probleemide lahendamine.

TARKVARA ELUKESKUSE KORRALDUSPROTSESSID

Juhtimisprotsess.

See koosneb tegevustest ja ülesannetest, mida saab täita iga oma protsesse juhtiv osapool. See osapool (haldur) vastutab toote väljalaskehalduse, projektijuhtimise ja seotud protsesside ülesannete haldamise eest, nagu hankimine, tarnimine, arendus, käitamine, hooldus jne.

Juhtimisprotsess hõlmab järgmisi toiminguid:

juhtimise algatamine ja ulatuse määratlemine;

planeerimine;

teostamine ja kontroll;

ülevaatus ja hindamine;

lõpetamine.

Algatamisel peab juht tagama, et juhtimiseks vajalikud ressursid (personal, seadmed ja tehnika) oleksid tema käsutuses piisavas koguses.

Planeerimine hõlmab vähemalt järgmiste ülesannete täitmist:

töögraafikute koostamine;

kuluprognoos;

vajalike ressursside eraldamine;

vastutuse jaotus;

konkreetsete ülesannetega kaasnevate riskide hindamine;

juhtimistaristu loomine.

Infrastruktuuri loomise protsess.

See hõlmab tehnoloogia, standardite ja tööriistade valikut ja toetamist (hooldust), tarkvara arendamiseks, käitamiseks või hooldamiseks kasutatava riist- ja tarkvara valikut ja installimist. Taristut tuleb muuta ja hooldada vastavalt asjakohaste protsesside nõuete muutumisele. Infrastruktuur on omakorda üks konfiguratsioonihalduse objekte.

Infrastruktuuri loomise protsess hõlmab järgmisi samme:

ettevalmistustööd;

infrastruktuuri loomine;

infrastruktuuri tugi.

Parandusprotsess.

See näeb ette tarkvara elutsükli protsesside hindamise, mõõtmise, kontrolli ja täiustamise. See protsess sisaldab järgmisi samme:

protsessi loomine;

protsessi hindamine;

protsessi parandamine.

Tarkvara elutsükli protsesside täiustamine on suunatud kõigi nendega seotud spetsialistide tööviljakuse tõstmisele kasutatava tehnoloogia, juhtimismeetodite, tööriistade valiku ja personali koolituse täiustamise kaudu. Parendamine põhineb iga protsessi eeliste ja puuduste analüüsil. Sellist analüüsi hõlbustab oluliselt ajaloolise, tehnilise, majandusliku ja muu teabe kogumine elluviidud projektide kohta.

Õppimisprotsess.

Peaksime alustama määratlemisestTarkvara elutsükkel(Tarkvara elutsükli mudel) on ajavahemik, mis algab hetkest, mil tehakse otsus tarkvaratoote loomiseks, ja lõpeb hetkel, mil see täielikult kasutusest kõrvaldatakse. See tsükkel on tarkvara loomise ja arendamise protsess.

Tarkvara elutsükli mudelid

Elutsüklit saab esitada mudelite kujul. Praegu on kõige levinumad:kaskaad, astmeline (astmeline mudel vahepealse juhtimisega ) Ja spiraalelutsükli mudelid.

Kaskaadmudel

Kaskaadmudel(Inglise) kose mudel) on tarkvara arendusprotsessi mudel, mille elutsükkel näeb välja vooluna, mis läbib järjestikku nõuete analüüsi ja disaini faase. juurutamine, testimine, integreerimine ja tugi.

Arendusprotsess viiakse ellu iseseisvate sammude järjestatud jada kaudu. Mudel näeb ette, et iga järgmine samm algab pärast eelmise etapi täielikku lõpetamist. Mudeli kõikidel etappidel tehakse abi- ja organisatsioonilisi protsesse ja töid, sealhulgas projektijuhtimist, kvaliteedi hindamist ja juhtimist, kontrollimist ja sertifitseerimist, konfiguratsioonihaldust ja dokumentatsiooni väljatöötamist. Etappide lõpuleviimise tulemusena moodustuvad vaheproduktid, mida ei saa järgmistes etappides muuta.

Elutsükkel on traditsiooniliselt jagatud järgmisteks peamisteksetapid:

1. Nõuete analüüs,
2. disain,
3. kodeerimine (programmeerimine),
4. Testimine ja silumine,
5. Kasutamine ja hooldus.

Mudeli eelised:

• nõuete stabiilsus kogu arenduse elutsükli jooksul;
• igas etapis moodustatakse täielik komplekt projekti dokumentatsioon, mis vastab täielikkuse ja järjepidevuse kriteeriumidele;
• mudeli sammude kindlus ja selgus ning selle rakendamise lihtsus;
• loogilises järjestuses tehtavad tööde etapid võimaldavad planeerida kõigi tööde valmimise ajastust ja vastavaid ressursse (rahalised, materiaalsed ja inimlikud).

Mudeli puudused:

• nõuete selge sõnastamise raskus ja võimatus neid dünaamiliselt kogu elutsükli jooksul muuta;
• vähene paindlikkus projektijuhtimisel;
• järeljada lineaarne struktuur arendusprotsess, mille tulemusena naasmine eelmiste sammude juurde esilekerkivate probleemide lahendamiseks toob kaasa kulude suurenemise ja töögraafiku katkemise;
• vahetoote kasutuskõlbmatus;
• ainulaadsete süsteemide paindliku modelleerimise võimatus;
• Montaažiprobleemide hiline avastamine kõigi tulemuste samaaegse integreerimise tõttu arenduse lõpus;
• kasutaja ebapiisav osalemine süsteemi loomisel - alguses (nõuete väljatöötamise ajal) ja lõpus (vastuvõtutestide ajal);
• kasutajad ei saa olla kindlad arendatava toote kvaliteedis enne, kui kogu arendusprotsess on lõppenud. Neil pole võimalust kvaliteeti hinnata, sest nad ei näe lõpetatud toode arendamine;
• kasutajal puudub võimalus süsteemiga järk-järgult harjuda. Õppeprotsess toimub elutsükli lõpus, kui tarkvara on juba kasutusele võetud;
• iga faas on edasiste toimingute eeltingimus, mistõttu on see meetod riskantne valik süsteemide jaoks, millel pole analooge, sest see ei sobi paindlikuks modelleerimiseks.

Kaskaadi elutsükli mudelit on keeruline rakendada tarkvarasüsteemi arendamise keerukuse tõttu ilma eelnevate sammude juurde tagasi pöördumata ja nende tulemusi muutmata, et kõrvaldada esilekerkivad probleemid.

Kaskaadi mudeli rakendusala

Kaskaadmudeli rakendusala piirangu määravad selle puudused. Selle kasutamine on kõige tõhusam järgmistel juhtudel:

1. projektide väljatöötamisel selge, muutumatugaeluring nõuded, arusaadav teostus ja tehnilised meetodid;
2. kui töötate välja projekti, mis keskendub sama tüüpi süsteemi või toote ehitamisele, mille arendajad on juba varem välja töötanud;
3. olemasoleva toote või süsteemi uue versiooni loomise ja väljalaskmisega seotud projekti väljatöötamisel;
4. olemasoleva toote või süsteemi uuele platvormile üleviimisega seotud projekti väljatöötamisel;
5. suurte projektide elluviimisel, mis hõlmavad mitut suurt arendusmeeskonda.

Inkrementaalne mudel

(samm-sammuline mudel vahepealse juhtimisega)

Inkrementaalne mudel(Inglise) juurdekasv- suurendamine, juurdekasv) tähendab tarkvara arendamist lineaarse etappide jadaga, kuid mitmes astmes (versioonis), s.o. kavandatud tootetäiustustega kogu aja jooksul kuni tarkvaraarenduse elutsükli lõpuni.

Tarkvaraarendus toimub iteratsioonidena tsüklitega tagasisidet etappide vahel. Etappidevahelised kohandused võimaldavad arvestada arendustulemuste tegelikku vastastikust mõju erinevad etapid, ulatub iga etapi eluiga üle kogu arendusperioodi.

Projekti kallal töötamise alguses määratakse kindlaks kõik süsteemi põhinõuded ja jagatakse need rohkem ja vähem olulisteks. Seejärel arendatakse süsteemi järk-järgult, et arendaja saaks tarkvaraarenduse käigus saadud andmeid kasutada. Iga samm peaks lisama süsteemile teatud funktsioonid. Sel juhul algab vabastamine kõrgeima prioriteediga komponentidest. Kui süsteemi osad on tuvastatud, võtke esimene osa ja hakake seda üksikasjalikult kirjeldama, kasutades selleks kõige sobivamat protsessi. Samas on võimalik täpsustada nõudeid teistele osadele, mis on praeguses käesoleva töö nõuetes külmunud. Vajadusel saate selle osa juurde hiljem naasta. Kui detail on valmis, toimetatakse see kliendile, kes saab seda oma töös kasutada. See võimaldab kliendil selgitada järgmiste komponentide nõudeid. Seejärel töötavad nad välja süsteemi järgmise osa. Selle protsessi põhietapid on lihtsalt tarkvaranõuete alamhulga rakendamine ja mudeli viimistlemine mitme järjestikuse väljalase kaudu, kuni tarkvara on täielikult rakendatud.

Selle mudeli elutsükkel on tüüpiline keerukate ja integreeritud süsteemide väljatöötamisel, mille jaoks on olemas selge nägemus (nii kliendi kui ka arendaja poolt), milline see olema peaks lõpptulemus. Versiooni arendamine toimub erinevatel põhjustel:

• kliendi suutmatus rahastada kogu kallist projekti korraga;
• arendaja puudus vajalikke ressursse lühikese ajaga ellu viia keeruline projekt;
• nõuded toote järkjärguliseks rakendamiseks ja kasutuselevõtuks lõppkasutajate poolt. Kogu süsteemi korraga rakendamine võib põhjustada selle kasutajate tagasilükkamist ja ainult "aeglustada" uutele tehnoloogiatele ülemineku protsessi. Piltlikult öeldes ei pruugi nad lihtsalt "suurt tükki seedida, nii et see tuleb tükeldada ja jagada osadeks".

Eelised Ja veadSee mudel (strateegiad) on samad, mis kose mudelid (klassikaline elutsükli mudel). Kuid erinevalt klassikalisest strateegiast näeb klient tulemusi varem. Lähtudes esimese versiooni väljatöötamise ja juurutamise tulemustest, võib ta veidi muuta arendusele esitatavaid nõudeid, sellest loobuda või pakkuda uue lepingu sõlmimisega arenenuma toote väljatöötamist.

Eelised:

• vähenevad kasutajate nõuete muutumisest tulenevad kulud, kordusanalüüs ja dokumentatsioon vähenevad oluliselt võrreldes kosemudeliga;
• Lihtsam on saada kliendilt tagasisidet tehtud tööde kohta – kliendid saavad valmis osade kohta omapoolseid kommentaare avaldada ja näha, mis on juba tehtud. Sest Süsteemi esimesed osad on süsteemi kui terviku prototüüp.
• kliendil on võimalus tarkvara kiiresti hankida ja omandada – kliendid saavad süsteemist tegelikku kasu kiiremini realiseerida, kui see oleks võimalik kosemudeli puhul.

Mudeli puudused:

• juhid peavad protsessi edenemist pidevalt mõõtma. kiire arengu korral ei tohiks iga minimaalse versioonimuudatuse jaoks dokumente luua;
• süsteemi struktuur kipub uute komponentide lisandudes halvenema – pidevad muutused rikuvad süsteemi struktuuri. Selle vältimiseks kulub ümbertöötlemiseks lisaaega ja raha. Kehv disain muudab tarkvara hilisema muutmise keeruliseks ja kulukaks. Ja tarkvara katkenud elutsükkel toob kaasa veelgi suuremaid kaotusi.

Skeem ei võimalda kiiresti arvesse võtta tekkivaid muudatusi ja tarkvaranõuete täpsustusi. Arendustulemuste kooskõlastamine kasutajatega toimub ainult punktides, mis on planeeritud pärast iga tööetapi lõppu ja Üldnõuded tarkvarale salvestatakse vormile lähteülesanne kogu selle loomise aja. Seega saavad kasutajad sageli tarkvara, mis ei vasta nende tegelikele vajadustele.

Spiraalne mudel

Spiraalne mudel:Elutsükkel - igal spiraali pöördel luuakse toote järgmine versioon, selgitatakse välja projekti nõuded, määratakse selle kvaliteet ja planeeritakse järgmise pöörde tööd. Erilist tähelepanu pööratakse arenduse algfaasidele - analüüsile ja projekteerimisele, kus teatud tehniliste lahenduste teostatavust testitakse ja põhjendatakse prototüüpide loomise kaudu.

See mudel on tarkvara arendusprotsess, mis ühendab nii disaini kui ka järkjärgulise prototüüpimise, et kombineerida alt-üles ja ülalt-alla kontseptsioonide eeliseid, rõhutades esialgsed etapid elutsükkel: analüüs ja disain.Iseloomulik omadus See mudel pöörab erilist tähelepanu elutsükli korraldust mõjutavatele riskidele.

Analüüsi ja projekteerimise etapis kontrollitakse prototüüpide loomisega tehniliste lahenduste teostatavust ja kliendi vajaduste rahuldamise taset. Iga spiraali pööre vastab toimiva fragmendi või süsteemi versiooni loomisele. See võimaldab teil teha selgeks projekti nõuded, eesmärgid ja omadused, määrata arenduse kvaliteedi ja planeerida spiraali järgmise pöörde tööd. Nii süvendatakse ja järjepidevalt täpsustatakse projekti detaile ning selle tulemusena valitakse välja mõistlik ja kliendi tegelikke nõudmisi rahuldav variant, mis viiakse ellu.

Elutsükkel igal spiraali pöördel – kasutada saab tarkvara arendusprotsessi erinevaid mudeleid. Lõppkokkuvõttes on väljund valmistoode. Mudel ühendab endas prototüüpimise mudeli võimalused jakose mudel. Areng iteratsioonide järgi peegeldab objektiivselt eksisteerivat süsteemi loomise spiraalitsüklit. Töö mittetäielik lõpetamine igas etapis võimaldab teil liikuda järgmisse etappi, ootamata töö täielikku lõpetamist praeguses etapis. peamine ülesanne— näidata süsteemi kasutajatele võimalikult kiiresti toimivat toodet, aktiveerides seeläbi nõuete selgitamise ja täiendamise.

Mudeli eelised:

• võimaldab teil kiiresti näidata süsteemi kasutajatele toimivat toodet, aktiveerides seeläbi nõuete selgitamise ja täiendamise protsessi;
• võimaldab muuta tarkvaraarenduse käigus nõudeid, mis on tüüpiline enamikule arendustele, sh standardsetele;
• mudel võimaldab paindlikku disaini, kuna see hõlmab kosemudeli eeliseid, võimaldades samal ajal iteratsioone sama mudeli kõigis faasides;
• võimaldab teil saada usaldusväärsema ja stabiilsema süsteemi. Tarkvara arenedes avastatakse ja parandatakse iga iteratsiooni käigus vead ja nõrkused;
• see mudel võimaldab kasutajatel aktiivselt osaleda planeerimis-, riskianalüüsi-, disaini- ja hindamistegevustes;
• kliendiriskid vähenevad. Klient saab minimaalse rahalise kahjuga lõpule viia vähetõotava projekti arendamise;
• Tagasiside kasutajatelt arendajatele toimub sageli ja mudeli alguses, mis tagab soovitud kvaliteetse toote loomise.

Mudeli puudused:

• kui projekt on väikese riskiga või väikese suurusega, võib mudel olla kallis. Riski hindamine pärast iga spiraali on seotud suurte kuludega;
• Mudeli elutsüklil on keeruline struktuur, mistõttu võib selle kasutamine arendajatel, juhtidel ja klientidel olla keeruline;
• spiraal võib jätkuda lõputult, kuna iga kliendi vastus loodud versioonile võib genereerida uue tsükli, mis lükkab projekti lõppu edasi;
• suur hulk vahetsükleid võib kaasa tuua vajaduse töödelda täiendavaid dokumente;
• mudeli kasutamine võib osutuda kulukaks ja isegi taskukohaseks, sest aega. planeerimisele, eesmärkide ümberdefineerimisele, riskianalüüside tegemisele ja prototüüpimisele kuluv aeg võib olla ülemäärane;
• Võib olla raske määratleda eesmärke ja verstaposte, mis näitavad valmisolekut jätkata arendusprotsessi järgmises ja

Spiraaltsükli põhiprobleemiks on järgmisse etappi ülemineku hetke kindlaksmääramine. Selle probleemi lahendamiseks kehtestatakse iga etapi jaoks ajapiirangud.eluring ja üleminek kulgeb plaanipäraselt, isegi kui kõik plaanitud tööd ei ole tehtud.Planeeriminetoodetud varasemates projektides saadud statistiliste andmete alusel ja isiklik kogemus arendajad.

Spiraalmudeli kasutusala

Spiraalmudeli kasutamine on soovitatav järgmistel juhtudel:

• projektide väljatöötamisel, kasutades uusi tehnoloogiaid;
• uue tooteseeria või süsteemide väljatöötamisel;
• ootustega projektide väljatöötamisel olulisi muutusi või nõuete täiendused;
• viia ellu pikaajalisi projekte;
• projektide väljatöötamisel, mis nõuavad süsteemi või toote kvaliteedi ja versioonide demonstreerimist lühikese aja jooksul;
• projektide väljatöötamisel. mille jaoks on vaja arvutada riskide hindamise ja lahendamisega kaasnevad kulud.