Mis sisaldub tarkvara elutsüklis. Tarkvara elutsükkel

Peaksime alustama määratlemisestEluring tarkvara (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:kaskaadne, astmeline (lavastatud mudel vahepealse juhtimisega ) Ja spiraalelutsükli mudelid.

Kaskaadmudel

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

Arendusprotsess viiakse ellu iseseisvate sammude järjestatud jada abil. Mudel näeb ette, et iga järgmine samm algab pärast eelmise etapi lõpetamist. Mudeli kõikidel etappidel tehakse abi- ja organisatsioonilisi protsesse ja töid, sealhulgas projektijuhtimist, hindamist ja kvaliteedijuhtimist, 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 arusaadavus 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 selgelt sõnastamise keerukus ja nende dünaamilise muutmise võimatus kogu elutsükli jooksul;
• vähene paindlikkus projektijuhtimisel;
• arendusprotsessi lineaarse struktuuri järjestus, 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;
• ehitamisega seotud probleemide hiline avastamine, mis on tingitud kõigi tulemuste samaaegsest integreerimisest arenduse lõpus;
• kasutaja ebapiisav osalus süsteemi loomisel - alguses (nõuete väljatöötamise ajal) ja lõpus (vastuvõtutestide ajal);
• kasutajad ei saa veenda arendatud toote kvaliteedis enne kogu arendusprotsessi lõppu. Neil puudub võimalus hinnata kvaliteeti, sest nad ei näe arenduse valmistoodet;
• 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 eelduseks järgnevate toimingute sooritamiseks, mistõttu on selline meetod riskantne valik süsteemide jaoks, millel pole analooge, sest. see ei sobi paindlikuks modelleerimiseks.

PS-i arendamise keerukuse tõttu on Waterfall Life Cycle mudelit keeruline rakendada ilma eelnevate sammude juurde tagasi pöördumata ja nende tulemusi muutmata, et kõrvaldada esilekerkivad probleemid.

Kaskaadimudeli ulatus

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

1. projektide väljatöötamisel selge, muutumatugaeluring rakendus- ja tehniliste metoodikate järgi arusaadavad nõuded;
2. kui töötate välja projekti, mis keskendub arendajate poolt varem välja töötatud sama tüüpi süsteemi või toote ehitamisele;
3. loomise ja väljaandmisega seotud projekti väljatöötamisel uus versioon olemasolev toode või süsteem;
4. olemasoleva toote või süsteemi uuele platvormile üleviimisega seotud projekti väljatöötamisel;
5. tehes suured projektid mis hõlmavad mitut suurt arendusmeeskonda.

inkrementaalne mudel

(lavastatud mudel vahepealse juhtimisega)

inkrementaalne mudel(ing. juurdekasv- suurendamine, juurdekasv) tähendab tarkvara arendamist lineaarse etappide jadaga, kuid mitmes astmes (versioonis), s.o. kavandatud tootetäiustustega nii kaua, kuni tarkvaraarenduse elutsükkel lõpeb.

Tarkvaraarendus toimub iteratsioonidena tsüklitega tagasisidet etappide vahel. Etappidevahelised kohandused võimaldavad arvestada arendustulemuste tegelikku vastastikust mõju erinevatel etappidel, iga etapi eluiga pikeneb kogu arendusperioodi jooksul.

Projekti kallal töötamise alguses määratakse kindlaks kõik süsteemi põhinõuded, mis on jagatud rohkem ja vähem olulisteks. Pärast seda toimub süsteemi arendamine järk-järgult, et arendaja saaks kasutada tarkvara arendamise käigus saadud andmeid. Iga samm peaks lisama süsteemile teatud funktsioonid. Sel juhul algab väljalase kõrgeima prioriteediga komponentidest. Kui süsteemi osad on määratletud, võtke esimene osa ja alustage selle üksikasjalikku kirjeldamist, kasutades selleks kõige sobivamat protsessi. Samas on võimalik täpsustada nõudeid ka teistele osadele, mis käesoleva töö kehtivas nõuetes on 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. Peamised verstapostid see protsess - lihtne rakendamine programmi nõuete alamhulgad ja mudeli täiustamine järjestikuste väljalasete seerias, kuni tarkvara on täielikult rakendatud.

Selle mudeli elutsükkel on tüüpiline keerukate ja keeruliste süsteemide arendamiseks, mille puhul on olemas selge visioon (nii tellija kui ka arendaja poolt), milline peaks olema lõpptulemus. Versiooni arendamine toimub erinevatel põhjustel:

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

Eelised Ja veadSelle mudeli (strateegia) mudelid on samad, mis kaskaadi (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 arenduse nõudeid, sellest loobuda või pakkuda uue lepingu sõlmimisega arenenuma toote väljatöötamist.

Eelised:

• vähenevad muutuvatest kasutajanõuetest tulenevad kulud, kordusanalüüs ja dokumentatsiooni kogumine vähenevad oluliselt võrreldes kosemudeliga;
• lihtsam on saada kliendilt tagasisidet tehtud tööde kohta - kliendid saavad valmis detailide kohta kommenteerida ja näha juba tehtut. Sest süsteemi esimesed osad on süsteemi kui terviku prototüüp.
• kliendil on võimalus tarkvara kiiresti omandada ja omandada – kliendid saavad süsteemist reaalset kasu varem, kui see juga mudeli puhul võimalik oleks.

Mudeli puudused:

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

Skeem ei võimalda koheselt arvesse võtta tekkivaid muudatusi ja tarkvaranõuete täpsustusi. Arendustulemuste kooskõlastamine kasutajatega toimub ainult nendes punktides, mis on planeeritud pärast iga tööetapi lõppu ja Üldnõuded tarkvarale fikseeritakse tehniliste kirjelduste kujul kogu selle loomise ajaks. 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, täpsustatakse 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 etappides kontrollitakse tehniliste lahenduste teostatavust ja kliendi vajaduste rahuldamise astet prototüüpide loomisega. 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 konkretiseeritakse projekti detaile järjepidevalt ning selle tulemusena valitakse välja mõistlik, tellija tegelikele nõudmistele vastav ja ellu viidud variant.

Elutsükkel igal spiraalipöördel – saab rakendada erinevaid tarkvaraarenduse protsessi mudeleid. Lõpptulemus on 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 praeguse töö täielikku lõpetamist. Peamine ülesanne on näidata süsteemi kasutajatele võimalikult kiiresti toimivat toodet, aktiveerides seeläbi nõuete selgitamise ja täiendamise protsessi.

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 tarkvaraarenduse käigus nõuete muutmist, mis on tüüpiline enamikule arendustele, sh standardsetele;
• mudel näeb ette paindliku disaini võimaluse, kuna see kätkeb endas kaskaadmudeli eeliseid ja samal ajal on lubatud iteratsioonid sama mudeli kõigis faasides;
• võimaldab teil saada usaldusväärsema ja stabiilsema süsteemi. Tarkvara arenedes leitakse ja parandatakse vead ja nõrkused igal iteratsioonil;
• see mudel võimaldab kasutajatel aktiivselt osaleda planeerimises, riskianalüüsis, arenduses, aga ka hindamistegevuste läbiviimises;
• vähendada kliendiriski. Klient saab minimaalse rahalise kahjuga lõpule viia vähetõotava projekti arendamise;
• antakse tagasisidet kasutajatelt arendajatele kõrgsagedus ja mudeli algstaadiumis, mis tagab soovitud kvaliteetse toote loomise.

Mudeli puudused:

• kui projekt on madala riskiga või väike, võib mudel olla kallis. Riski hindamine pärast iga spiraali on kallis;
• Mudeli elutsükkel on keerulise ülesehitusega, mistõttu selle rakendamine arendajate, juhtide ja klientide poolt võib olla keeruline;
• spiraal võib jätkuda lõputult, kuna iga kliendi reaktsioon loodud versioonile võib tekitada uue tsükli, mis lükkab projekti valmimise edasi;
• suur hulk vahetsükleid võib kaasa tuua vajaduse töödelda täiendavaid dokumente;
• mudeli kasutamine võib olla kulukas ja isegi taskukohane, sest aega. kulutused planeerimisele, ümbersihtimisele, riskianalüüsile ja prototüüpimisele võivad olla ülemäärased;
• võib olla raske määratleda eesmärke ja verstaposte, mis viitavad valmisolekule jätkata arendusprotsessi järgmisel ja

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

Spiraalmudeli ulatus

Spiraalmudeli kasutamine on soovitatav järgmistel juhtudel:

• projektide väljatöötamisel, kasutades uusi tehnoloogiaid;
• uue tooteseeria või süsteemide väljatöötamisel;
• eeldatavate oluliste muudatuste või nõuete täiendustega projektide väljatöötamisel;
• pikaajaliste projektide elluviimiseks;
• 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.

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

Selles PS-standardis (või tarkvara) on määratletud kui komplekt arvutiprogrammid, protseduurid ja võimalikud seotud dokumendid ja andmed. Protsess on defineeritud kui omavahel seotud toimingute kogum, mis muudab osa sisendandmed väljundandmeteks (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 jagatud ülesannete kogumiks. Iga protsessi, toimingu või ülesande algatab ja teostab teine ​​protsess vastavalt vajadusele ning etteantud täitmisjadasid pole (loomulikult sisendandmeühendusi säilitades).

Tuleb märkida, et Nõukogude Liidus ja seejärel Venemaal reguleeriti tarkvara (tarkvara) loomist algselt, eelmise sajandi 70ndatel, GOST ESPD standardid (programmidokumentatsiooni ühtne süsteem - GOST 19.XXX). seeriad), mis keskendusid üksikute programmeerijate loodud suhteliselt lihtsatele väikesemahulistele klassiprogrammidele. Praegu on need standardid nii kontseptuaalselt kui vormilt aegunud, nende kehtivusaeg on aegunud ja neid ei ole soovitav kasutada.

Loomisprotsessid automatiseeritud süsteemid(AS), mis sisaldab ka tarkvara, on reguleeritud GOST 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 testide tüübid". Paljud nende standardite sätted on aga aegunud, samas kui 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 standardeid.

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

Riis. 5.1.

Rühmades on määratletud viis peamist protsessi: hankimine, tarnimine, arendus, käitamine ja hooldus. Kaheksa alamprotsessi tagavad põhiprotsesside täitmise, nimelt dokumentatsioon, Konfiguratsiooni juhtimine, kvaliteedi tagamine, kontrollimine, valideerimine, ühishindamine, audit, probleemide lahendamine. Neli organisatsioonilist protsessi pakuvad juhtimist, infrastruktuuri ülesehitamist, 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. taotlusettepanekute koostamine;
3. lepingu ettevalmistamine ja kohandamine;
4. tarnija tegevuse järelevalve;
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 hankimisel, arendamisel või täiustamisel;
2. otsuse tegemine olemasoleva tarkvara soetamise, arendamise või täiustamise kohta;
3. tarkvaratoote ostmisel vajaliku dokumentatsiooni, garantiide, sertifikaatide, litsentside ja toe olemasolu kontrollimine;
4. soetusplaani koostamine ja kinnitamine, sh süsteeminõuded, lepingu liik, poolte kohustused jne.

Pakkumised peavad sisaldama:

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

Pakkumised saadetakse pakkumise korral valitud tarnijale või mitmele tarnijale. Tarnija on organisatsioon, kes sõlmib kliendiga lepingu süsteemi, tarkvara või tarkvarateenuse tarnimiseks 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 tarnija lepingud;
4. muudatuste tegemine (vajadusel) lepingus selle rakendamise käigus.

Tarnija tegevuse üle teostatakse järelevalvet vastavalt ühistes hindamis- ja auditeerimisprotsessides sätestatud toimingutele. Vastuvõtmise käigus valmistatakse ette ja tehakse vajalikud testid. Lepingujärgsed tööd lõpetatakse kõigi vastuvõtmise tingimuste täitmisel.

Tarneprotsess hõlmab tegevusi ja ülesandeid, mida teostab müüja, kes varustab klienti tarkvaratoote või -teenusega. See protsess sisaldab järgmisi samme:

1. kohaletoimetamise algatamine;
2. pakkumistele vastuse koostamine;
3. lepingu ettevalmistamine;
4. lepinguliste tööde planeerimine;
5. lepinguliste tööde teostamine ja kontroll ning nende hindamine;
6. tööde tarnimine ja lõpetamine.

Tarne algatamine seisneb pakkumiste läbivaatamises tarnija poolt ja otsuse tegemises, kas nõustuda seatud nõuete ja tingimustega või pakkuda oma (kokkulepitud) tingimusi. 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 juhtimine jne.

Arendusprotsess näeb ette arendaja tegevused ja ülesanded 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, personali koolituse korraldamiseks vajalikud materjalid jne.

Arendusprotsess hõlmab järgmisi samme:

1. ettevalmistustööd;
2. süsteemile esitatavate nõuete analüüs;
3. süsteemiarhitektuuri projekteerimine;
4. nõuete analüüs tarkvarale;
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 ulatusele, olulisusele ja keerukusele. Arendusprotsessi tegevused ja ülesanded peaksid olema valitud mudeliga kooskõlas. Arendaja peab valima, kohanema projekti tingimustega ning kasutama tellijaga kokkulepitud standardeid, meetodeid ja meetodeid. arendustööriistad, samuti koostada tööplaan.

Süsteemi nõuete analüüs hõlmab selle funktsionaalsuse kindlaksmääramist, kohandatud nõuded, nõuded töökindlusele, turvalisusele, nõuded välistele liidestele, jõudlusele jne. Süsteeminõudeid hinnatakse teostatavuskriteeriumide ja testimise käigus kontrollitavuse alusel.

Süsteemiarhitektuuri projekteerimine seisneb selle seadmete (riistvara), tarkvara komponentide ja operatsioonide määramises, mida teostavad süsteemi opereerivad töötajad. Süsteemi arhitektuur peab vastama süsteemi nõuetele ja olema aktsepteeritud projekteerimisstandardid ja meetodid.

Tarkvaranõuete analüüs hõlmab iga tarkvarakomponendi järgmiste omaduste mää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 testimise käigus kontrollitavuse 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. tarkvara ja andmebaaside (DB) programmiliideste arendamine ja dokumenteerimine;
3. kasutajadokumentatsiooni eelversiooni väljatöötamine;
4. arendus ja dokumentatsioon eeldused testide ja tarkvara integratsiooniplaani juurde.

Üksikasjalik tarkvaraprojekt sisaldab järgmisi ülesandeid:

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

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

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

Tarkvaraintegratsioon näeb ette väljatöötatud tarkvarakomponentide kokkupanemise vastavalt agregeeritud komponentide integreerimis- ja testimisplaanile. Iga koondatud komponendi jaoks töötatakse välja testikomplektid ja testimisprotseduurid, et testida iga pädevust järgnevatel tasemetestidel. Kvalifikatsiooninõue on kriteeriumide või tingimuste kogum, mis peavad kvalifitseerumiseks olema täidetud tarkvara kui see vastab selle spetsifikatsioonidele ja on valmis põllul kasutamiseks.

Tarkvara kvalifikatsioonitesti viib arendaja läbi kliendi juuresolekul (

Tööprotsess hõlmab süsteemi opereeriva operaatori organisatsiooni tegevusi ja ülesandeid. Toimimisprotsess sisaldab järgmisi samme.

1. Ettevalmistustööd, mis hõlmavad järgmiste ülesannete täitmist operaatori poolt:

   1. käitamise ajal tehtavate tegevuste ja tööde planeerimine ning tegevusstandardite 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 viiakse tööle.
3. Süsteemi tegelik töö, mida teostatakse selleks ettenähtud keskkonnas vastavalt kasutaja dokumentatsioonile.
4. probleemide ja tarkvara muutmise taotluste analüüs (tekkinud probleemi või muutmissoovi teadete analüüs, mastaabi hindamine, muutmise maksumus, sellest tulenev mõju, muutmise otstarbekuse 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 operatiivorganisatsiooni, hooldusteenistuse ja kasutajate osalusel. Kus tarkvaratooted ja dokumentatsioon kuuluvad arhiveerimisele vastavalt lepingule.

Annotatsioon.

Sissejuhatus.

1. Tarkvara elutsükkel

Sissejuhatus.

Riley programmeerimisprotsessi sammud

Sissejuhatus.

1.1.1. Probleemi sõnastamine.

1.1.2. Lahenduse disain.

1.1.3. Algoritmi kodeerimine.

1.1.4. Programmi tugi.

1.1.5. Tarkvara dokumentatsioon.

Järeldus punkti 1.1 kohta

1.2. ZhTsPO määratlus Lehmani järgi.

Sissejuhatus.

1.2.1 Süsteemi määratlus.

1.2.2. Rakendamine.

1.2.3. Teenindus.

Järeldus punkti 1.2 kohta.

1.3. Elutsükliprogrammi faasid ja tööd vastavalt Boehmile

1.3.1. kaskaadmudel.

1.3.2. Majanduslik põhjendus kaskaadmudel.

1.3.3. Kaskaadmudeli täiustamine.

1.3.4. Elutsükli faaside määratlus.

1.3.5. Põhitöö projektiga.

Kirjandus.

Sissejuhatus

Tööstuslik rakendus arvutid ja kasvav nõudlus programmide järele on seadnud kiireloomulised ülesanded märkimisväärselt suurendada tarkvaraarenduse tootlikkus, tööstuslike meetodite arendamine programmide kavandamiseks ja kujundamiseks, organisatsiooniliste, tehniliste, tehniliste, majanduslike ja sotsiaalpsühholoogiliste tehnikate, mustrite ja meetodite ülekandmine sfäärist materjali tootmine arvutite vallas. Kompleksne lähenemine tarkvara arendamise, käitamise ja hoolduse protsessidele esitas mitmeid pakilisi probleeme, mille lahendamine kõrvaldab programmide kujundamise "pudelikaelad", lühendab valmimisaega, parandab olemasolevate programmide valikut ja kohandamist ning võib-olla määrab manustatud arvutitega süsteemide saatuse.

Suurte tarkvaraprojektide arendamise praktikas sageli puudub ühtne lähenemine tööjõukulude, töötähtaegade ja materjalikulude hindamisele, mis takistab tarkvaraarenduse tootlikkuse tõusu ning lõppkokkuvõttes - tõhus juhtimine tarkvara elutsükkel. Kuna mis tahes tüüpi programmist saab toode (välja arvatud võib-olla õppe-, makettprogrammid), peaks lähenemine selle tootmisele olema paljuski sarnane tööstustoodete tootmise lähenemisviisiga ja tarkvara kujundamise küsimused muutuvad äärmiselt oluliseks. . See idee on aluseks B.U. Boehm "Software Engineering Design", mida kasutasime selle kirjutamiseks referaat. Selles raamatus viitab tarkvara disain tarkvaratoote disaini loomise protsessile.

1 Tarkvara elutsükkel

SISSEJUHATUS

LCPE on pidev protsess, mis algab hetkest, mil tehakse otsus tarkvara loomise vajaduse kohta ja lõpeb hetkel, mil see täielikult kasutusest kõrvaldatakse.

Tarkvara elutsükli (SLLC) faaside ja tegevuste, programmeerimisprotsessi etappide, kose- ja spiraalmudelite määratlemiseks on mitu lähenemisviisi. Kuid need kõik sisaldavad ühiseid põhikomponente: probleemi püstitus, lahenduse kavandamine, rakendamine, hooldus.

Kõige kuulsam ja täiuslikum on võib-olla Boehmi järgi elutsükli struktuur, mis sisaldab kaheksat faasi. Seda tutvustatakse üksikasjalikumalt hiljem.

Üks neist valikuid võib olla Lehmani järgi ülemise taseme kirjeldus, mis sisaldab kolme põhifaasi ja kujutab kõige üldisemal juhul elutsükli programmi kirjeldust.

Ja vahelduseks on siin D. Riley raamatus “Using the Modula-2 Language” esitatud programmeerimisprotsessi sammud. See idee on minu meelest väga lihtne ja tuttav ning alustame sellest.

1.1 Riley programmeerimisprotsessi etapid

Sissejuhatus

Programmeerimisprotsess koosneb neljast etapist (joonis 1):

probleemipüstitus, st. adekvaatse ettekujutuse saamine sellest, millist ülesannet programm peaks täitma;

juba püstitatud probleemile lahenduse kavandamine (üldiselt on selline lahendus vähem formaalne kui lõplik programm);

programmi kodeerimine ehk kavandatud lahenduse tõlkimine masinas täidetavaks programmiks;

programmi tugi, st. käimasoleva programmi vigade parandamise ja uute funktsioonide lisamise protsess.

Riis. 1.Neli programmeerimisetappi.

Programmeerimine algab hetkest, mil kasutaja, st. keegi, kes vajab probleemi lahendamiseks programmi, tekitab probleemi süsteemianalüütik. Kasutaja ja süsteemianalüütik määratlevad probleemiavalduse ühiselt. Viimane kantakse seejärel üle algoritmist kes vastutab lahenduse kavandamise eest. Lahendus (või algoritm) on toimingute jada, mille täitmine viib ülesande lahendamiseni. Kuna algoritm pole sageli kohandatud masinas täitmiseks, tuleks see tõlkida masinaprogrammiks. Seda toimingut teostab kodeerija. Hilisemate programmimuudatuste eest vastutab hooldaja. programmeerija. Ja süsteemianalüütik ja algoritmist, kodeerija ja kaasas olev programmeerija – nad kõik on programmeerijad.

Suure tarkvaraprojekti puhul võib kasutajate, süsteemianalüütikute ja algoritmide arv olla märkimisväärne. Lisaks võib ettenägematute asjaolude tõttu osutuda vajalikuks naasta eelmiste sammude juurde. Kõik see on lisaargument hoolika tarkvaradisaini kasuks: iga etapi tulemused peaksid olema täielikud, täpsed ja arusaadavad.

1.1.1 Probleemi kirjeldus

Programmeerimise üks olulisemaid samme on probleemi seadmine. See toimib lepinguna kasutaja ja programmeerija(te) vahel. Nagu juriidiliselt halvasti koostatud leping, on ka halb missioonikirjeldus kasutu. Hea probleemipüstituse korral esindavad nii kasutaja kui ka programmeerija selgelt ja ühemõtteliselt sooritatavat ülesannet, s.t. sel juhul arvestatakse nii kasutaja kui programmeerija huve. Kasutaja saab plaanida kasutada tarkvara, mida pole veel loodud, lähtudes teadmisest, et ta suudab. Probleemi hea sõnastus on selle lahenduse kujunemise aluseks.

Probleemi sõnastamine (programmi spetsifikatsioon); sisuliselt tähendab täpset, täielikku ja arusaadavat kirjeldust selle kohta, mis konkreetse programmi täitmisel juhtub. Tavaliselt vaatab kasutaja arvutit kui musta kasti: tema jaoks pole oluline, kuidas arvuti töötab, vaid oluline on, et arvuti saaks teha seda, millest kasutaja huvitab. Fookuses on inimese ja masina vaheline suhtlus.

Hea probleemiavalduse omadused:

Täpsus, st. igasuguse ebaselguse välistamine. Ei tohiks olla kahtlust, milline on programmi väljund konkreetse sisendi jaoks.

täielikkus, st. kõigi antud sisendi võimaluste, sealhulgas vigase või ootamatu sisendi kaalumine ja sobiva väljundi määramine.

Selgus, st. see peaks olema arusaadav nii kasutajale kui ka süsteemianalüütikule, kuna probleemi avaldus on nende vahel ainus leping.

Tihti on täpsuse, täielikkuse ja selguse nõuded vastuolus. Jah, paljud juriidilised dokumendid sellest on raske aru saada, sest need on kirjutatud formaalses keeles, mis võimaldab ühe või teise seisukoha sõnastada ülima täpsusega, välistades ka kõige ebaolulisemad lahknevused. Näiteks mõned küsimused eksamitöödel on mõnikord nii täpselt sõnastatud, et õpilasel kulub rohkem aega küsimuse mõistmisele kui sellele vastamisele. Pealegi ei pruugi üliõpilane detailide rohkuse tõttu küsimuse peamist tähendust üldse tabada. Parim probleemipüstitus on see, mis saavutab kõigi kolme nõude tasakaalu.

Probleemi avalduse standardvorm.

Mõelge järgmisele ülesande lausele: "Sisestage kolm numbrit ja sisestage numbrid järjekorras."

Selline väide ei vasta ülaltoodud nõuetele: see ei ole täpne, täielik ega arusaadav. Tõepoolest, kas numbrid tuleb sisestada üks rea kohta või kõik numbrid ühel real? Kas väljend "järjekorras" tähendab järjestamist suurimast väiksemani, väikseimast suurimani või samas järjekorras, milles need kasutusele võeti.

On ilmne, et selline sõnastus ei vasta paljudele küsimustele. Kui võtta arvesse vastused kõikidele küsimustele, muutub probleemipüstitus sõnaliseks ja raskesti mõistetavaks. Seetõttu teeb D. Riley ettepaneku kasutada probleemi püstitamiseks standardvormi, mis tagab maksimaalse täpsuse, täielikkuse, selguse ja sisaldab:

ülesande nimi (skemaatiline definitsioon);

üldkirjeldus (ülesande lühikirjeldus);

vead (ebatavalised sisestusvalikud on selgelt loetletud, et näidata kasutajatele ja programmeerijatele toiminguid, mida masin sellistes olukordades teeb);

näide ( hea näide võib anda edasi probleemi olemust, aga ka illustreerida erinevaid juhtumeid).

Näide. Probleemi avaldus standardvormis.

NIMI

Sorteeri kolm täisarvu.

KIRJELDUS

Kolme täisarvu sisend ja väljund, sorteeritud väikseimast suurimani.

Sisestatakse kolm täisarvu, üks arv rea kohta. Sel juhul on täisarv üks või mitu järjestikust kümnendkohta, millele võib eelneda plussmärk "+" või miinusmärk "-".

Kolm sisestatud täisarvu väljastatakse, kõik kolm kuvatakse samal real. Kõrvuti asetsevad numbrid on eraldatud tühikuga. Numbrid kuvatakse väikseimast suurimani, vasakult paremale.

1) Kui sisestatakse vähem kui kolm numbrit, ootab programm täiendavat sisestust.

2) Muud sisendridad peale esimese kolme ignoreeritakse.

3) Kui mõni esimesest kolmest reast sisaldab rohkem kui ühte täisarvu, siis programm väljub ja väljastab teate.

Annotatsioon.

Sissejuhatus.

1. Tarkvara elutsükkel

Sissejuhatus.

Riley programmeerimisprotsessi sammud

Sissejuhatus.

1.1.1. Probleemi sõnastamine.

1.1.2. Lahenduse disain.

1.1.3. Algoritmi kodeerimine.

1.1.4. Programmi tugi.

1.1.5. Tarkvara dokumentatsioon.

Järeldus punkti 1.1 kohta

1.2. ZhTsPO määratlus Lehmani järgi.

Sissejuhatus.

1.2.1 Süsteemi määratlus.

1.2.2. Rakendamine.

1.2.3. Teenindus.

Järeldus punkti 1.2 kohta.

1.3. Elutsükliprogrammi faasid ja tööd vastavalt Boehmile

1.3.1. kaskaadmudel.

1.3.2. Kaskaadmudeli majanduslik põhjendus.

1.3.3. Kaskaadmudeli täiustamine.

1.3.4. Elutsükli faaside määratlus.

1.3.5. Põhitöö projektiga.

Kirjandus.

Sissejuhatus

Arvutite tööstuslik rakendamine ja kasvav nõudlus programmide järele on seadnud kiireloomulised ülesanded selle oluliseks suurendamiseks tarkvaraarenduse tootlikkus, tööstuslike meetodite arendamine programmide kavandamiseks ja kujundamiseks, organisatsiooniliste, tehniliste, tehniliste, majanduslike ja sotsiaalpsühholoogiliste meetodite, mustrite ja meetodite ülekandmine materjali tootmise sfäärist arvutite sfääri. Kompleksne lähenemine tarkvara arendamise, käitamise ja hoolduse protsessidele esitas mitmeid pakilisi probleeme, mille lahendamine kõrvaldab programmide kujundamise "pudelikaelad", lühendab valmimisaega, parandab olemasolevate programmide valikut ja kohandamist ning võib-olla määrab manustatud arvutitega süsteemide saatuse.

Suurte tarkvaraprojektide arendamise praktikas sageli puudub ühtne lähenemine tööjõukulude, töötähtaegade ja materjalikulude hindamisele, mis takistab tarkvaraarenduse tootlikkuse tõusu ning lõppkokkuvõttes tarkvara elutsükli efektiivset juhtimist. Kuna mis tahes tüüpi programmist saab toode (välja arvatud võib-olla õppe-, makettprogrammid), peaks lähenemine selle tootmisele olema paljuski sarnane tööstustoodete tootmise lähenemisviisiga ja tarkvara kujundamise küsimused muutuvad äärmiselt oluliseks. . See idee on aluseks B.U. Boehm "Engineering Software Design", mida kasutasime käesoleva kursusetöö kirjutamisel. Selles raamatus viitab tarkvara disain tarkvaratoote disaini loomise protsessile.

1 Tarkvara elutsükkel

SISSEJUHATUS

LCPE on pidev protsess, mis algab hetkest, mil tehakse otsus tarkvara loomise vajaduse kohta ja lõpeb hetkel, mil see täielikult kasutusest kõrvaldatakse.

Tarkvara elutsükli (SLLC) faaside ja tegevuste, programmeerimisprotsessi etappide, kose- ja spiraalmudelite määratlemiseks on mitu lähenemisviisi. Kuid need kõik sisaldavad ühiseid põhikomponente: probleemi püstitus, lahenduse kavandamine, rakendamine, hooldus.

Kõige kuulsam ja täiuslikum on võib-olla Boehmi järgi elutsükli struktuur, mis sisaldab kaheksat faasi. Täpsemalt tutvustatakse seda hiljem.

Üheks võimalikuks variandiks võib olla Lehmani järgi ülemise taseme kirjeldus, mis sisaldab kolme põhifaasi ja kujutab kõige üldisemal juhul elutsükli programmi kirjeldust.

Ja vahelduseks on siin D. Riley raamatus “Using the Modula-2 Language” esitatud programmeerimisprotsessi sammud. See idee on minu meelest väga lihtne ja tuttav ning alustame sellest.

1.1 Riley programmeerimisprotsessi etapid

Programmeerimisprotsess koosneb neljast etapist (joonis 1):

probleemipüstitus, st. adekvaatse ettekujutuse saamine sellest, millist ülesannet programm peaks täitma;

juba püstitatud probleemile lahenduse kavandamine (üldiselt on selline lahendus vähem formaalne kui lõplik programm);

programmi kodeerimine ehk kavandatud lahenduse tõlkimine masinas täidetavaks programmiks;

programmi tugi, st. käimasoleva programmi vigade parandamise ja uute funktsioonide lisamise protsess.

Riis. 1.Neli programmeerimisetappi.

Programmeerimine algab hetkest, mil kasutaja, st. keegi, kes vajab probleemi lahendamiseks programmi, tekitab probleemi süsteemianalüütik. Kasutaja ja süsteemianalüütik määratlevad probleemiavalduse ühiselt. Viimane kantakse seejärel üle algoritmist kes vastutab lahenduse kavandamise eest. Lahendus (või algoritm) on toimingute jada, mille täitmine viib ülesande lahendamiseni. Kuna algoritm pole sageli kohandatud masinas täitmiseks, tuleks see tõlkida masinaprogrammiks. Seda toimingut teostab kodeerija. Kaasasolev programmeerija vastutab hilisemate programmi muudatuste eest. Ja süsteemianalüütik ja algoritmist, kodeerija ja kaasas olev programmeerija – nad kõik on programmeerijad.

Suure tarkvaraprojekti puhul võib kasutajate, süsteemianalüütikute ja algoritmide arv olla märkimisväärne. Lisaks võib ettenägematute asjaolude tõttu osutuda vajalikuks naasta eelmiste sammude juurde. Kõik see on lisaargument hoolika tarkvaradisaini kasuks: iga etapi tulemused peaksid olema täielikud, täpsed ja arusaadavad.

1.1.1 Probleemi kirjeldus

Programmeerimise üks olulisemaid samme on probleemi seadmine. See toimib lepinguna kasutaja ja programmeerija(te) vahel. Nagu juriidiliselt halvasti koostatud leping, on ka halb missioonikirjeldus kasutu. Hea probleemipüstituse korral esindavad nii kasutaja kui ka programmeerija selgelt ja ühemõtteliselt sooritatavat ülesannet, s.t. sel juhul arvestatakse nii kasutaja kui programmeerija huve. Kasutaja saab plaanida kasutada tarkvara, mida pole veel loodud, lähtudes teadmisest, et ta suudab. Probleemi hea sõnastus on selle lahenduse kujunemise aluseks.

Probleemi sõnastamine (programmi spetsifikatsioon); sisuliselt tähendab täpset, täielikku ja arusaadavat kirjeldust selle kohta, mis konkreetse programmi täitmisel juhtub. Tavaliselt vaatab kasutaja arvutit kui musta kasti: tema jaoks pole oluline, kuidas arvuti töötab, vaid oluline on, et arvuti saaks teha seda, millest kasutaja huvitab. Fookuses on inimese ja masina vaheline suhtlus.

Hea probleemiavalduse omadused:

Täpsus, st. igasuguse ebaselguse välistamine. Ei tohiks olla kahtlust, milline on programmi väljund konkreetse sisendi jaoks.

täielikkus, st. kõigi antud sisendi võimaluste, sealhulgas vigase või ootamatu sisendi kaalumine ja sobiva väljundi määramine.

Selgus, st. see peaks olema arusaadav nii kasutajale kui ka süsteemianalüütikule, kuna probleemi avaldus on nende vahel ainus leping.

Tihti on täpsuse, täielikkuse ja selguse nõuded vastuolus. Seega on paljud juriidilised dokumendid raskesti arusaadavad, kuna need on kirjutatud formaalses keeles, mis võimaldab sõnastada teatud sätted ülima täpsusega, välistades ka kõige ebaolulisemad lahknevused. Näiteks mõned küsimused eksamitöödel on mõnikord nii täpselt sõnastatud, et õpilasel kulub rohkem aega küsimuse mõistmisele kui sellele vastamisele. Pealegi ei pruugi üliõpilane detailide rohkuse tõttu küsimuse peamist tähendust üldse tabada. Parim probleemipüstitus on see, mis saavutab kõigi kolme nõude tasakaalu.

Probleemi avalduse standardvorm.

Mõelge järgmisele ülesande lausele: "Sisestage kolm numbrit ja sisestage numbrid järjekorras."

Selline väide ei vasta ülaltoodud nõuetele: see ei ole täpne, täielik ega arusaadav. Tõepoolest, kas numbrid tuleb sisestada üks rea kohta või kõik numbrid ühel real? Kas väljend "järjekorras" tähendab järjestamist suurimast väiksemani, väikseimast suurimani või samas järjekorras, milles need kasutusele võeti.

On ilmne, et selline sõnastus ei vasta paljudele küsimustele. Kui võtta arvesse vastused kõikidele küsimustele, muutub probleemipüstitus sõnaliseks ja raskesti mõistetavaks. Seetõttu teeb D. Riley ettepaneku kasutada probleemi püstitamiseks standardvormi, mis tagab maksimaalse täpsuse, täielikkuse, selguse ja sisaldab:

ülesande nimi (skemaatiline definitsioon);

üldkirjeldus (ülesande lühikirjeldus);

vead (ebatavalised sisestusvalikud on selgelt loetletud, et näidata kasutajatele ja programmeerijatele toiminguid, mida masin sellistes olukordades teeb);

näide (hea näitega saab edasi anda probleemi olemust, aga ka illustreerida erinevaid juhtumeid).

Näide. Probleemi avaldus standardvormis.

NIMI

Sorteeri kolm täisarvu.

KIRJELDUS

Kolme täisarvu sisend ja väljund, sorteeritud väikseimast suurimani.

Sisestatakse kolm täisarvu, üks arv rea kohta. Sel juhul on täisarv üks või mitu järjestikust kümnendkohta, millele võib eelneda plussmärk "+" või miinusmärk "-".

Kolm sisestatud täisarvu väljastatakse, kõik kolm kuvatakse samal real. Kõrvuti asetsevad numbrid on eraldatud tühikuga. Numbrid kuvatakse väikseimast suurimani, vasakult paremale.

1) Kui sisestatakse vähem kui kolm numbrit, ootab programm täiendavat sisestust.

1. märtsil 2012 võttis Vene Föderatsiooni Tehnilise Regulatsiooni ja Metroloogia Föderaalne Amet vastu GOST R ISO/IEC 12207-2010 standardi „Infotehnoloogia. Süsteemi- ja tarkvaratehnika. Elutsükli protsessid tarkvara tööriistad”, identne rahvusvaheline standard ISO/IEC 12207:2008 "Süsteemi- ja tarkvaratehnika – Tarkvara elutsükli protsessid".

See standard kehtestab väljakujunenud terminoloogiat kasutades üldine struktuur tarkvara elutsükli protsessid, mida saab kasutada tarkvaratööstuses võrdlusalusena. Standard määratleb protsessid, tegevused ja ülesanded, mida kasutatakse tarkvaratoote või -teenuse hankimisel, samuti tarkvaratoodete tarnimisel, arendamisel, sihtotstarbelisel kasutamisel, hooldamisel ja tootmise lõpetamisel.

Tarkvara elutsükli protsessid

Standardrühmad erinevat tüüpi tegevused, mida saab teha elutsükli jooksul tarkvarasüsteemid, seitsmeks protsessirühmaks. Kõiki nende rühmade elutsükli protsesse kirjeldatakse eesmärgi ja soovitud väljundite ning nende tulemuste saavutamiseks tehtavate toimingute ja ülesannete loeteluna.

• kokkuleppe protsessid - kaks protsessi;
• projekti organisatsioonilised tugiprotsessid - viis protsessi;
• projektiprotsessid - seitse protsessi;
• tehnilised protsessid - üksteist protsessi;
• tarkvara juurutamise protsessid - seitse protsessi;
• tarkvara tugiprotsessid - kaheksa protsessi;
• protsessid taaskasuta tarkvara - kolm protsessi.
• Peamine:
  • Omandamine (tarkvara ostva kliendi toimingud ja ülesanded)
  • Tarnimine (tarnija tegevused ja ülesanded, kes tarnib kliendile tarkvaratoote või -teenuse)
  • Arendus (arendaja toimingud ja ülesanded: tarkvara loomine, projekteerimis- ja töödokumentatsiooni koostamine, testi- ja koolitusmaterjalide koostamine jne)
  • Töötamine (operaatori – süsteemi haldava organisatsiooni tegevused ja ülesanded)
  • Hooldus (saatva organisatsiooni, st hooldusteenistuse toimingud ja ülesanded). Hooldus – tarkvaras muudatuste tegemine vigade parandamiseks, jõudluse parandamiseks või muutuvate töötingimuste või nõuetega kohanemiseks.
• Abistav
  • Dokumentatsioon (tarkvara elutsükli jooksul loodud teabe ametlik kirjeldus)
  • Konfiguratsioonihaldus (haldus- ja tehniliste protseduuride rakendamine kogu tarkvara elutsükli jooksul tarkvarakomponentide oleku määramiseks, selle modifikatsioonide haldamiseks).
  • Kvaliteedi tagamine (tagab, et IS ja selle elutsükli protsessid vastaksid kehtestatud nõuetele ja kinnitatud plaanidele)
  • Kontrollimine (määramine, et tarkvaratooted, mis on mõne tegevuse tulemus, vastavad täielikult eelnevatest tegevustest tulenevatele nõuetele või tingimustele)
  • Sertifitseerimine (määratletud nõuete ja loodud süsteemi nende konkreetsele funktsionaalsele otstarbele vastavuse täielikkuse kindlakstegemine)
  • Ühine hindamine (projekti töö seisu hindamine: ressursside, personali, seadmete, tööriistade planeerimise ja juhtimise kontroll)
  • Audit (lepingu nõuetele, plaanidele ja tingimustele vastavuse kindlakstegemine)
  • Probleemide lahendamine (arendus-, töö-, hooldus- või muude protsesside käigus avastatud probleemide analüüs ja lahendamine, sõltumata nende päritolust või allikast)
• Organisatsiooniline
  • Juhtimine (tegevused ja ülesanded, mida saab täita iga oma protsesse juhtiv osapool)
  • Infrastruktuuri loomine (tehnoloogia, standardite ja tööriistade valik ja hooldus, tarkvara arendamiseks, käitamiseks või hooldamiseks kasutatava riist- ja tarkvara valik ja paigaldamine)
  • Täiustamine (elutsükli protsesside hindamine, mõõtmine, kontroll ja täiustamine)
  • Koolitus (esialgne koolitus ja sellele järgnev pidev personali arendamine)

Iga protsess sisaldab mitmeid tegevusi. Näiteks hõlmab omandamise protsess järgmisi samme:

1. Omandamise algatamine
2. Pakkumiste koostamine
3. Lepingu koostamine ja kohandamine
4. Tarnija järelevalve
5. Tööde vastuvõtmine ja lõpetamine

Iga toiming sisaldab mitmeid ülesandeid. Näiteks peaks pakkumiste koostamine hõlmama järgmist:

1. Nõuete kujundamine süsteemile
2. Tarkvaratoodete loendi koostamine
3. Tingimuste ja kokkulepete seadmine
4. Tehniliste piirangute kirjeldus (süsteemi töökeskkond jne)

Tarkvara elutsükli etapid, seos protsesside ja etappide vahel

Tarkvara elutsükli mudel- struktuur, mis määrab täitmise järjekorra ning protsesside, toimingute ja ülesannete seose kogu elutsükli jooksul. Elutsükli mudel sõltub projekti spetsiifikast, ulatusest ja keerukusest ning konkreetsetest tingimustest, milles süsteem luuakse ja töötab.

GOST R ISO/IEC 12207-2010 standard ei paku konkreetset elutsükli mudelit. Selle sätted on ühised kõigi IP loomise olelustsükli mudelite, meetodite ja tehnoloogiate jaoks. See kirjeldab elutsükli protsesside struktuuri, täpsustamata, kuidas nendes protsessides sisalduvaid tegevusi ja ülesandeid rakendada või täita.

Tarkvara elutsükli mudel sisaldab:

1. etapid;
2. Töö tulemused igas etapis;
3. Võtmesündmused - tööde lõpetamise ja otsustamise punktid.