Tarkvara elutsükkel (SOFTW). Tarkvaraarenduse elutsükkel ja verstapostid Mida teate tarkvaraarenduse elutsükli kohta?

Tarkvara elutsükkel - ajavahemik, mis algab hetkest, mil tehakse otsus tarkvaratoote loomise vajaduse kohta ja lõpeb selle täieliku kasutusest kõrvaldamise hetkel.

Tarkvara elutsükli protsessid:

Põhiline,

abiteenistus,

Organisatsiooniline.

Peamine:

1. Omandamine - tarkvara ostva kliendi toimingud ja ülesanded;

2. Tarne - tarnija tegevus ja ülesanded, kes tarnib klienti tarkvaratoote või -teenusega;

3. Arendus - arendaja poolt teostatavad tegevused ja ülesanded: tarkvara loomine, projekteerimis- ja töödokumentatsiooni teostamine, test- ja koolitusmaterjalide koostamine;

4. Toimimine - süsteemi haldava organisatsiooni operaatori tegevused ja ülesanded;

5. Hooldus – tarkvaras muudatuste tegemine vigade parandamiseks, jõudluse parandamiseks või muutuvate töötingimuste või nõuetega kohanemiseks.

Abiseade:

1. Dokumentatsioon - tarkvara elutsükli jooksul loodud teabe formaliseeritud kirjeldus;

2. Konfiguratsioonihaldus – haldus- ja tehniliste protseduuride rakendamine kogu tarkvara elutsükli jooksul tarkvarakomponentide oleku kindlaksmääramiseks, selle modifikatsioonide haldamiseks;

3. Kvaliteedi tagamine - tarkvara ja selle elutsükli protsesside vastavuse tagamine kindlaksmääratud nõuetele ja kinnitatud plaanidele;

4. Kontrollimine – tarkvaratooted vastavate eelnevate toimingute tõttu täielikult nõuetele või tingimustele kindlakstegemine;

5. Sertifitseerimine - kindlaksmääratud nõuete ja loodud süsteemi nende konkreetsele funktsionaalsele otstarbele vastavuse määramine;

6. Ühishindamine – projekti töö seisu hindamine: ressursside, personali, seadmete, tööriistade planeerimise ja juhtimise kontroll;

7. Audit - lepingu nõuetele, plaanidele ja tingimustele vastavuse kindlakstegemine;

8. Probleemide lahendamine - arenduse, ekspluatatsiooni, hoolduse või muude protsesside käigus avastatud probleemide analüüs ja lahendamine, sõltumata nende päritolust või allikast.

Organisatsiooniline:

1. Juhtimine - tegevused ja ülesanded, mida saab teha iga osapool, kes juhib oma protsesse;

2. Infrastruktuuri loomine - tehnoloogia valik ja hooldus, standardid ja tööriistad, tarkvara arendamiseks, käitamiseks või hooldamiseks kasutatava riist- ja tarkvara valimine ja installimine;

3. Parendamine - elutsükli protsesside hindamine, mõõtmine, kontroll ja täiustamine;

4. Koolitus – personali esmane väljaõpe ja sellele järgnev pidev professionaalne areng.

2002. aastal avaldati süsteemi elutsükli protsesside standard (ISO/IEC 15288 Süsteemi elutsükli protsessid). Standardi väljatöötamisse kaasati spetsialiste erinevatest valdkondadest: süsteemitehnika, programmeerimine, kvaliteedijuhtimine, personalitöö, turvalisus jne. praktiline kogemus süsteemide ehitamine valitsus-, kaubandus-, sõjaväe- ja akadeemilistes organisatsioonides. Standard on rakendatav paljudele süsteemide klassile, kuid selle põhieesmärk on toetada arvutisüsteemide loomist.

Vastavalt ISO/IEC 15288 seeriale tuleks elutsükli struktuuri kaasata järgmised protsessirühmad:

1. Lepingulised protsessid:

omandamine (majasisesed lahendused või välise pakkuja lahendused);

Tarne (siselahendused või välistarnija lahendused);

2. Ettevõtte protsessid:

Kontroll keskkond ettevõtted;

Investeeringute juhtimine;

IP elutsükli juhtimine;

Ressursihaldus;

Kvaliteedi kontroll;

3. Disainiprotsessid:

Projekti planeerimine;

Projektide hindamine;

Projekti kontroll;

Riskide juhtimine;

Konfiguratsiooni juhtimine;

Infovoo juhtimine;

Otsuste tegemine.

4. Tehnilised protsessid:

Nõuete määratlemine;

Nõuete analüüs;

Arhitektuuri arendamine;

rakendamine;

Integratsioon;

Kontrollimine;

Üleminek;

Sertifitseerimine;

ekspluateerimine;

Saatja;

Utiliseerimine.

5. Eriprotsessid:

Ülesannetest ja eesmärkidest lähtuvate seoste määratlemine ja loomine.

IP-tarkvara põhiolelustsükli protsesside loomine (ISO/IEC 15288)

Protsess (protsessi täitja)	Tegevused	Sissepääs	Tulemus
Omandamine (klient)	- Algatamine - Pakkumisettepanekute koostamine - Lepingu ettevalmistamine - Tarnija tegevuse kontroll - IP vastuvõtmine	- Otsus alustada tööd IP juurutamisega - Kliendi tegevuste uuringu tulemused - IP turu / hanke analüüsi tulemused - Tarne / arendusplaan - IP terviklik test	- IS-i rakendamise teostatavusuuring - IS-i lähteülesanne - Tarne-/arendusleping - Tööetappide vastuvõtuaktid - Vastuvõtukatsetuste akt
Kohaletoimetamine (IS arendaja)	- Algatamine - Pakkumistele vastamine - Lepingu ettevalmistamine - Teostuse planeerimine - IP tarnimine	- IS lähteülesanne - Juhtkonna otsus arenduses osaleda - Hanke tulemused - IS lähteülesanne - Projekti juhtimisplaan - Väljatöötatud IS ja dokumentatsioon	- otsus arenduses osaleda - Kommertspakkumised/ pakkumine - Tarne-/arendusleping - Projekti juhtimisplaan - Rakendamine/kohandamine - Aktsepteerimistesti aruanne
Arendus (IS arendaja)	- Ettevalmistus - IS-i nõuete analüüs - IS-i arhitektuuri projekteerimine - Tarkvaranõuete arendus - Tarkvaraarhitektuuri projekteerimine - Tarkvara detailne projekteerimine - Tarkvara kodeerimine ja testimine - Tarkvara integreerimine ja tarkvara kvalifikatsiooni testimine - IS-i integreerimine ja IS-i kvalifitseeritud testimine	- IS-i lähteülesanne - IS-i lähteülesanne, olelusringi mudel - IS-i alamsüsteemid - Tarkvarakomponentide nõuete spetsifikatsioonid - Tarkvaraarhitektuur - Tarkvara disaini üksikasjalikud materjalid - Tarkvara integratsiooniplaan, testid - IS-i arhitektuur, tarkvara, dokumentatsioon IS-i jaoks, testid	- Kasutatav elutsükli mudel, arendusstandardid - Tööplaan - Alamsüsteemide, riistvarakomponentide koostis - Tarkvarakomponentidele esitatavate nõuete spetsifikatsioonid - Tarkvarakomponentide koostis, liidesed andmebaasiga, tarkvara integreerimise plaan - Andmebaasi projekt, spetsifikatsioonid tarkvarakomponentide vahelistele liidestele, nõuded testidele - Moodulitekstid Tarkvara, autonoomse testimise aktid - Tarkvarakompleksi TOR-i nõuetele vastavuse hindamine - Tarkvara, andmebaasi vastavuse hindamine, tehniline kompleks ja dokumentide komplekt vastavalt TOR-i nõuetele

Süsteemi arendamise etapid (ISO/IEC 15288)

CPC: looge projekti "Queue" lähtetingimused saidil www.mastertz.ru

Tarkvara elutsükli mudelid:

1. kaskaad,

2. spiraal,

3. iteratiivne.

Kaskaadmudel elutsükli (“juga mudel”, inglise kose mudel) pakkus välja 1970. aastal Winston Royce. See näeb ette projekti kõigi etappide järjestikuse rakendamise rangelt fikseeritud järjekorras. Üleminek järgmisele etapile tähendab töö täielikku lõpetamist eelmises etapis.

Nõuete kujundamise etapis määratletud nõuded on rangelt dokumenteeritud lähteülesande vormis ja fikseeritud kogu projekti arendamise ajaks.

Iga etapp kulmineerub täieliku dokumentatsioonikomplekti avaldamisega, millest piisab arenduse jätkamiseks teise arendusmeeskonna poolt.

Nõuete väljatöötamine

Moodustamine

spiraalne mudel(inglise spiraalmudel) töötas välja 1980. aastate keskel Barry Boehm. See põhineb Edward Demingi klassikalisel PDCA (plan-do-check-act) tsüklil. Selle mudeli kasutamisel luuakse tarkvara mitmes iteratsioonis (spiraalpöördes) prototüüpimise teel.

Prototüüp on aktiivne tarkvarakomponent, mis rakendab üksikuid funktsioone ja väliseid liideseid.

Iga iteratsioon vastab tarkvara fragmendi või versiooni loomisele, see selgitab projekti eesmärgid ja omadused, hindab saadud tulemuste kvaliteeti ja kavandab järgmise iteratsiooni tööd.

Riis. 21. Tarkvara elutsükli spiraalmudel

Igas iteratsioonis hinnatakse järgmist:

1. Projekti tingimuste ja maksumuse ületamise risk;

2. Vajadus sooritada veel üks iteratsioon;

3. süsteemi nõuetest arusaamise täielikkuse ja täpsuse aste;

4. Projekti lõpetamise otstarbekus.

Üks näide spiraalmudeli rakendamisest on RAD.

RAD-i põhiprintsiibid:

1. Tööriistakomplekti eesmärk peaks olema arendusaja minimeerimine;

2. Prototüübi loomine kliendi nõudmiste selgitamiseks;

3. Arendustsükkel: iga toote uus versioon põhineb kliendipoolsel hinnangul eelmise versiooni töö tulemusele;

4. Versiooniarenduse aja minimeerimine valmismoodulite ülekandmise ja uuele versioonile funktsionaalsuse lisamisega;

5. Arendusmeeskond peab tegema tihedat koostööd, iga liige peab olema valmis täitma mitmeid kohustusi;

6. Projektijuhtimine peaks minimeerima arendustsükli kestust.

Iteratiivne mudel: kaskaad- ja spiraalmudelite loomulik areng on viinud nende lähenemiseni ja moodsa iteratiivse lähenemise tekkeni, mis on nende mudelite ratsionaalne kombinatsioon.

Riis. 22. Tarkvara elutsükli iteratiivne mudel

Eluring tarkvara

Tarkvara projekteerimise metoodika üks põhimõisteid on selle tarkvara elutsükli (tarkvara elutsükli) kontseptsioon. Tarkvara elutsükkel on pidev protsess, mis algab hetkest, mil tehakse otsus selle loomise vajaduse kohta ja lõpeb selle täieliku tegevuse lõpetamise hetkel.

Peamine normdokument, mis reguleerib tarkvara elutsüklit, on rahvusvaheline standard ISO / IEC 12207 (ISO - International Organization of Standardization - International Organisation for Standardization, IEC - International Electrotechnical Commission - International Commission on Electrical Engineering). See määratleb elutsükli struktuuri, mis sisaldab protsesse, tegevusi ja ülesandeid, mis tuleb tarkvaraarenduse käigus täita. Selles standardis Tarkvara (tarkvaratoode) määratletud komplektina arvutiprogrammid, protseduurid ja võimalikud seotud dokumendid ja andmed. Protsess on määratletud kui omavahel seotud toimingute kogum, mis muudab mõne sisendi väljundiks. Iga protsessi iseloomustavad teatud ülesanded ja meetodid nende lahendamiseks, teistest protsessidest saadud lähteandmed ja tulemused.

Tarkvara elutsükli struktuur vastavalt ISO/IEC 12207 standardile põhineb kolmel protsesside rühmal:

tarkvara elutsükli põhiprotsessid (ost, tarnimine, arendus, käitamine, hooldus);

abiprotsessid, mis tagavad põhiprotsesside elluviimise (dokumentatsioon, konfiguratsioonihaldus, kvaliteedi tagamine, kontrollimine, sertifitseerimine, hindamine, audit, probleemide lahendamine);

· organisatsioonilised protsessid(projektijuhtimine, projekti infrastruktuuri loomine, elutsükli enda määratlemine, hindamine ja täiustamine, koolitus).

Tarkvara elutsükli mudelid

Elutsükli mudel- struktuur, mis määrab elluviimise järjestuse ning etappide ja sooritatavate etappide suhte kogu elutsükli jooksul. Elutsükli mudel sõltub tarkvara spetsiifikast ning viimase loomise ja toimimise tingimuste eripärast. Peamised elutsükli mudelid on järgmised.

1. Kaskaadmudel(kuni XX sajandi 70. aastateni) määrab järjestikuse ülemineku järgmisse etappi pärast eelmise lõpetamist.

Seda mudelit iseloomustab üksikute mitteseotud ülesannete automatiseerimine, mis ei nõua teabe integreerimist ja ühilduvust, tarkvara, tehnilist ja organisatsioonilist liidest.

Väärikust: hea sooritus arendusaja ja usaldusväärsuse osas üksikute probleemide lahendamisel.

Viga: kohaldamatus suurte ja keerulised projektid süsteeminõuete varieeruvuse tõttu pikaajalise projekteerimise käigus.

2. Iteratiivne mudel(20. sajandi 70-80ndad) vastab “alt-üles” disainitehnoloogiale. Võimaldab pärast järgmise etapi täitmist iteratiivselt naasta eelmistele etappidele;

Mudel näeb ette üksikute ülesannete jaoks saadud projektlahenduste üldistamist süsteemiülesteks lahendusteks. Sel juhul on vaja eelnevalt sõnastatud nõuded üle vaadata.

Väärikus: võimalus projektis kiiresti muudatusi teha.

Viga: suure iteratsioonide arvuga pikeneb projekteerimisaeg, esineb lahknevusi projekteerimislahendustes ja dokumentatsioonis ning loodava tarkvara funktsionaalne ja süsteemiarhitektuur on segamini. Vajadus vana süsteem ümber kujundada või uus luua võib tekkida kohe pärast juurutamise või käitamisetappi.

3. Spiraalmudel(20. sajandi 80-90ndad) vastab ülalt-alla disainitehnoloogiale. Eeldab tarkvara prototüübi kasutamist, mis võimaldab tarkvara laiendamist. Süsteemi ülesehitus kordab tsükliliselt teed nõuete täpsustamisest programmikoodi täpsustamiseni.

Süsteemi arhitektuuri kujundamisel määratakse esmalt kindlaks funktsionaalsete alamsüsteemide koosseis ja lahendatakse kogu süsteemi hõlmavad küsimused (integreeritud andmebaasi korraldus, teabe kogumise, edastamise ja akumuleerimise tehnoloogia). Seejärel formuleeritakse individuaalsed ülesanded ja töötatakse välja tehnoloogia nende lahendamiseks.

Programmeerimisel töötatakse esmalt välja põhiprogrammi moodulid ja seejärel üksikuid funktsioone täitvad moodulid. Esiteks suhtlevad moodulid omavahel ja andmebaasiga ning seejärel realiseeritakse algoritmid.

Eelised:

1. iteratsioonide arvu ja sellest tulenevalt parandamist vajavate vigade ja ebakõlade arvu vähendamine;

2. projekteerimisaja vähendamine;

3. loomise lihtsustamine projekti dokumentatsioon.

Viga: kõrged nõuded kogu süsteemi hõlmava hoidla kvaliteedile ( ühine alus projekteerimisandmed).

Aluseks on spiraalmudel kiire rakenduste arendamise tehnoloogiad või RAD-tehnoloogia (kiire rakendusarendus), mis hõlmab Aktiivne osalemine tulevase süsteemi lõppkasutajad selle loomise protsessis. Infotehnoloogia peamised etapid on järgmised:

· Infostrateegia analüüs ja planeerimine. Kasutajad osalevad koos spetsialistide arendajatega probleemse piirkonna tuvastamisel.

· Disain. Kasutajad osalevad arendajate juhendamisel tehnilises projekteerimises.

· Disain. Arendajad kujundavad tarkvara tööversiooni, kasutades 4. põlvkonna keeli;

· Rakendamine. Arendajad koolitavad kasutajaid uues tarkvarakeskkonnas töötama.

CT areng laiendab pidevalt erineva iseloomuga teabe töötlemisega seotud lahendatavate ülesannete klasse.

Põhimõtteliselt on tegemist kolme tüüpi teabega ja vastavalt kolme tüüpi ülesannetega, mille jaoks arvutit kasutatakse:

1) Arvteabe töötlemisega seotud arvutusülesanded. Nende hulka kuuluvad näiteks suure mõõtmega lineaarvõrrandisüsteemi lahendamise probleem. Varem oli see arvutite peamine, domineeriv kasutusala.

2) Ülesanded tekstiandmete loomise, toimetamise ja teisendamisega seotud sümboolse teabe töötlemiseks. Selliste probleemide lahendamisega on seotud näiteks sekretär-masinakirjutaja töö.

3) Graafilise teabe töötlemise ülesanded ᴛ.ᴇ. diagrammid, joonised, graafikud, visandid jne. Selliste ülesannete hulka kuulub näiteks disaineri ülesanne töötada välja uute toodete joonised.

4) Ülesanded tähtnumbrilise teabe töötlemiseks - IS. Tänaseks on sellest saanud üks arvutite põhilisi rakendusvaldkondi ja ülesanded muutuvad järjest keerulisemaks.

Iga klassi ülesannete arvutilahendusel on oma spetsiifika, kuid selle võib jagada mitmeks etapiks, mis on tüüpilised enamikule probleemidele.

Programmeerimistehnoloogiauurib tehnoloogilisi protsesse ja nende läbimise (etappide) järjekorda kasutades teadmisi, meetodeid ja vahendeid.

Tehnoloogiaid iseloomustatakse mugavalt kahes mõõtmes – vertikaalne (esindab protsesse) ja horisontaalne (esindab etappe).

Pilt

Protsess on omavahel seotud toimingute (tehnoloogiliste toimingute) kogum, mis muudab mõned sisendandmed väljundandmeteks. Protsessid koosnevad tegevuste (tehnoloogiliste operatsioonide) kogumist ja iga toiming koosneb ülesannete kogumist ja nende lahendamise meetoditest. Vertikaalne mõõde peegeldab protsesside staatilisi aspekte ja opereerib selliste mõistetega nagu tööprotsessid, tegevused, ülesanded, sooritustulemused, sooritajad.

Etapp on tarkvara loomise tegevuste osa, mis on piiratud teatud ajaraamiga ja lõpeb konkreetse toote väljalaskmisega, mis on määratud sellele etapile seatud nõuetega. Mõnikord ühendatakse etapid suuremateks ajaraamideks, mida nimetatakse faasideks või verstapostideks. Niisiis, horisontaalne mõõde esindab aega, peegeldab protsesside dünaamilisi aspekte ja töötab selliste mõistetega nagu faasid, etapid, etapid, iteratsioonid ja kontrollpunktid.

Tarkvaraarendus järgib kindlaksmääratud elutsüklit.

Eluring Tarkvara - ϶ᴛᴏ iga tarkvara arendamise ja käitamise projekti raames läbiviidav ja juhitav pidev ja korrastatud tegevuste kogum, alates hetkest, kui tekib idee (kontseptsioon) mõne tarkvara loomiseks ja tehakse otsus tarkvara arendamise ja kasutamise kohta. selle loomise äärmine tähtsus ja lõpeb selle loomise hetkel. täielik tegevuse lõpetamine järgmistel põhjustel:

a) vananemine;

b) vastavate probleemide lahendamise kriitilise tähtsuse kaotus.

Tehnoloogilised lähenemised - ϶ᴛᴏ mehhanismid elutsükli rakendamiseks.

Tehnoloogilise lähenemise määrab etappide ja protsesside kombineerimise eripära, keskendudes erinevatele tarkvaraklassidele ja arendusmeeskonna omadustele.

Elutsükkel määratleb etapid (faasid, etapid), nii et tarkvaratoode liigub ühest etapist teise, alates toote kontseptsioonist kuni selle voltimise etapini.

Tarkvaraarenduse elutsükkel tuleks esitada erineva üksikasjalikkusega etappide kohta. Elutsükli lihtsaim esitus sisaldab etappe:

Disain

Rakendamine

Testimine ja silumine

Rakendamine, kasutamine ja hooldus.

Programmi elutsükli lihtsaim esitus (kaskaadtehnoloogia lähenemisviis elutsükli juhtimisele):

Protsessid

Disain

Programmeerimine

Testimine

Saatja

Analüüs Disain juurutamine Testimine Rakendusoperatsioon

ning silumine ja hooldus

Tegelikult töötab igas etapis ainult üks protsess. Ilmselgelt ei ole suurte programmide arendamisel ja loomisel selline skeem piisavalt korrektne (ei ole rakendatav), kuid selle võib aluseks võtta.

Analüüsi etapp keskendub süsteeminõuetele. Nõuded on määratletud ja täpsustatud (kirjeldatud). Teostatakse funktsionaalsete mudelite ja süsteemi andmemudelite väljatöötamist ja integreerimist. Samal ajal on fikseeritud mittefunktsionaalsed ja muud süsteeminõuded.

Projekteerimisetapp on jagatud kaheks põhiliseks alamfaasiks: arhitektuurne ja detailplaneering. Eelkõige viimistletakse programmi disaini, kasutajaliidest ja andmestruktuure. Tõstetakse üles ja fikseeritakse disainiprobleemid, mis mõjutavad süsteemi arusaadavust, hooldatavust ja skaleeritavust.

Rakendusfaas sisaldab programmi kirjutamist.

Erinevused riist- ja tarkvaras on eriti nähtavad etapil ärakasutamine. Kui tarbekaubad läbivad turule toomise, kasvu, küpsuse ja languse etapid, siis tarkvara eluiga sarnaneb pigem poolelioleva, kuid pidevalt valmiva ja uuendatava hoone (lennuki) ajalooga. (tellija).

Tarkvara elutsükkel on reguleeritud paljude standarditega, sh. ja rahvusvaheline.

Keerulise PS-i elutsükli standardimise eesmärk:

Paljude spetsialistide kogemuste ja uurimistulemuste kokkuvõtte tegemine;

Töötab maha tehnoloogilised protsessid ja arendustehnikad ning metoodiline baas nende automatiseerimiseks.

Standardid hõlmavad järgmist:

Alginfo kirjeldamise reeglid, toimingute sooritamise meetodid ja meetodid;

Kehtestada protsessi juhtimise reeglid;

Kehtestada nõuded tulemuste esitamisele;

Reguleerida tehnoloogiliste ja tegevusdokumentide sisu;

Määrake organisatsiooniline struktuur arendusmeeskond;

Pakkuda ülesannete jaotamist ja ajakava koostamist;

Andke kontroll PS-i loomise edenemise üle.

Venemaal on elutsüklit reguleerivad standardid:

Tarkvara arendamise etapid - GOST 19.102-77

AS-i loomise etapid - GOST 34.601-90;

TK ASi loomiseks - GOST 34.602-89;

Testi tüübid AS - GOST 34.603-92;

Samal ajal ei ole nendes standardites IP-rakendustarkvara loomine, hooldus ja arendamine piisavalt kajastatud ning mõned nende sätted on juhtimis- ja andmesüsteemides kvaliteetsete rakendusprogrammide kaasaegsete hajutatud süsteemide ehitamise seisukohast aegunud. erineva arhitektuuriga töötlemissüsteemid.

Sellega seoses tuleb märkida rahvusvahelist standardit ISO / IEC 12207-1999 - ʼʼ Infotehnoloogia– Tarkvara elutsükli protsessidʼʼ.

ISO – Rahvusvaheline Standardiorganisatsioon – Rahvusvaheline Standardiorganisatsioon, IEC – Rahvusvaheline Elektrotehnikakomisjon – Rahvusvaheline Elektrotehnika Komisjon.

See määratleb tarkvara elutsükli struktuuri ja selle protsessid.

Need. tarkvara loomine pole nii lihtne ülesanne, sellega seoses on olemas standardid, milles on kõik kirjas: mida tuleb teha, millal ja kuidas.

Tarkvara elutsükli struktuur vastavalt rahvusvaheline standard ISO/IEC 12207-95 põhineb kolmel protsessirühmal:

1) tarkvara elutsükli põhiprotsessid (ost, tarnimine, arendus, käitamine, hooldus). Keskendume viimasele.

2) abiprotsessid, mis tagavad põhiprotsesside rakendamise ( dokumentatsioon, konfiguratsioonihaldus, kvaliteedi tagamine, kontrollimine, valideerimine, koostööülevaade (hindamine), audit, probleemide lahendamine).

1. Konfiguratsioonihaldussee on protsess, mis toetab tarkvara elutsükli põhiprotsesse, eelkõige arendus- ja hooldusprotsesse. Paljudest komponentidest koosnevate keerukate tarkvaraprojektide väljatöötamisel, millest igaühel võib olla variatsioone või versioone, tekib probleem nende seoste ja funktsioonidega arvestamises, ühtse (ᴛ.ᴇ. unified) struktuuri loomises ning kogu süsteemi arengu tagamises. . Konfiguratsioonihaldus võimaldab korraldada, süstemaatiliselt arvesse võtta ja juhtida erinevate tarkvarakomponentide muudatusi nende elutsükli kõigil etappidel.

2. Kontrollimine on protsess, mille käigus tehakse kindlaks, kas tarkvara praegune olek saavutati see etapp, selle etapi nõuded.

3. Sertifitseerimine– kontrollimise ja objektiivsete tõendite esitamise kinnitamine, et konkreetsete objektide erinõuded on täielikult täidetud.

4. Ühine analüüs (hindamine) – objekti kehtestatud kriteeriumidele vastavuse astme süstemaatiline kindlaksmääramine.

5. Audit– pädeva asutuse (isiku) poolt läbi viidud audit, et anda sõltumatu hinnang tarkvaratoodete või -protsesside vastavuse taseme kohta kehtestatud nõuetele. Läbivaatus võimaldab hinnata arendusparameetrite vastavust esialgsetele nõuetele. Kontrollimine kattub testimisega, kuna seda tehakse tegelike ja oodatavate tulemuste erinevuste kindlakstegemiseks ning selle hindamiseks, kas tarkvara funktsioonid vastavad algsetele nõuetele. Projekti elluviimise protsessis on olulisel kohal üksikute komponentide ja kogu süsteemi kui terviku identifitseerimise, kirjeldamise ja konfiguratsiooni kontrollimise küsimused.

3) organisatsioonilised protsessid (projektijuhtimine, projekti infrastruktuuri loomine, elutsükli enda määratlemine, hindamine ja täiustamine, koolitus).

Projekti juht seotud tööde planeerimise ja korraldamise, arendajameeskondade loomise ning teostatavate tööde ajastuse ja kvaliteedi jälgimisega. Projekti tehniline ja korralduslik tugi hõlmab meetodite ja vahendite valikut projekti elluviimiseks, arengu vaheseisundite kirjeldamise meetodite määratlemist, meetodite ja vahendite väljatöötamist loodud tarkvara testimiseks, personali koolitust jne. . Projekti kvaliteedi tagamine on seotud tarkvarakomponentide verifitseerimise, verifitseerimise ja testimise probleemidega.

Vaatleme tarkvara elutsüklit arendaja vaatenurgast.

Standardile vastav arendusprotsess näeb ette arendaja poolt tehtavad toimingud ja ülesanded ning hõlmab tarkvara ja selle komponentide loomist vastavalt kindlaksmääratud nõuetele, sealhulgas projekteerimis- ja kasutusdokumentatsiooni koostamist, samuti tarkvara ja selle komponentide koostamist. materjalid, mis on vajalikud tarkvaratoodete toimivuse ja kvaliteedi vastavuse kontrollimiseks, personali koolituseks vajalikud materjalid jne.

Vastavalt standardile sisaldab IP-tarkvara elutsükkel järgmisi toiminguid:

1) idee (kontseptsiooni) tekkimine ja uurimine;

2) ettevalmistav etapp - elutsükli mudeli, standardite, meetodite ja arendusvahendite valik, samuti tööplaani koostamine.

3) infosüsteemi nõuete analüüs - selle määratlus

funktsionaalsus, nõuded kasutajale, nõuded töökindlusele ja turvalisusele, nõuded välistele liidestele jne.

4) infosüsteemide arhitektuuri projekteerimine - tuvastada kriitilise tähtsusega riistvara, tarkvara ja hooldustoimingud.

5) tarkvaranõuete analüüs- funktsionaalsuse määratlemine, sealhulgas jõudlusnäitajad, komponentide töökeskkonnad, välised liidesed, töökindlus- ja ohutusspetsifikatsioonid, ergonoomilised nõuded, andmekasutuse nõuded, paigaldamine, vastuvõtmine, kasutaja dokumentatsioon, kasutamine ja hooldus.

6) tarkvara arhitektuuri projekteerimine - tarkvara struktuuri määratlemine, selle komponentide liideste dokumenteerimine, kasutajadokumentatsiooni eelversiooni väljatöötamine, samuti testimisnõuded ja integratsiooniplaan.

7) üksikasjalik tarkvara disain - üksikasjalik

tarkvara komponentide ja nendevaheliste liideste kirjeldus, kasutajadokumentatsiooni uuendamine, testinõuete ja testimisplaani väljatöötamine ja dokumenteerimine, tarkvarakomponendid, komponentide integreerimisplaani uuendamine.

8) tarkvara kodeerimine -– arendus ja dokumentatsioon

iga tarkvarakomponent;

9)tarkvara testimine – testimisprotseduuride ja -andmete komplekti väljatöötamine nende testimiseks, komponentide testimine, kasutajadokumentatsiooni uuendamine, tarkvara integreerimisplaani uuendamine;

10) tarkvara integreerimine–tarkvarakomponentide kokkupanek vastavalt

integratsiooniplaan ja tarkvara testimine vastavuse tagamiseks kvalifikatsiooninõuded, mis on kriteeriumide või tingimuste kogum, mille täitmine on äärmiselt oluline, et kvalifitseerida tarkvaratoode spetsifikatsioonidele vastavaks ja antud töötingimustes kasutamiseks valmis;

11) tarkvara kvalifikatsiooni testimine – tarkvara testimine sisse

kliendi kohalolek, et tõendada selle vastavust

nõuded ja valmisolek tööks; samas kontrollitakse ka tehnilise ja kasutusdokumentatsiooni valmisolekut ja täielikkust;

12) süsteemi integreerimine – kõigi komponentide kokkupanek infosüsteem, sealhulgas tarkvara ja riistvara;

13) IP kvalifikatsiooni testimine – süsteemi testimine

sellele esitatavate nõuete täitmine ning kujunduse ja dokumentatsiooni täielikkuse kontrollimine;

14) tarkvara installimine – tarkvara paigaldamine kliendi seadmetele ja selle toimimise kontrollimine;;

15) tarkvara aktsepteerimine – kvalifitseeritud tulemuste hindamine

tarkvara ja infosüsteemide testimine üldiselt ja

hindamistulemuste dokumenteerimine koos kliendiga, sertifitseerimine ja tarkvara lõplik üleandmine kliendile.

16) Dokumentatsiooni haldamine ja arendamine;

17) operatsioon

18) saatja - uute versioonide loomise ja juurutamise protsess

tarkvaratoode.;

19) toimingu lõpetamine.

Neid toiminguid saab rühmitada, tuues tinglikult esile järgmised tarkvaraarenduse peamised etapid:

ülesande avaldus (TOR) (vastavalt GOST 19.102-77 etapile ʼʼTerms of Referenceʼʼ)

nõuete analüüs ja spetsifikatsioonide väljatöötamine (vastavalt GOST 19.102-77 etapile "Eelnõu");

disain (vastavalt GOST 19.102-77 etapile ʼʼ Tehniline projektʼʼ)

Rakendamine (kodeerimine, testimine ja silumine) (vastavalt GOST 19.102-77 etapile ʼʼWorking draftʼʼ).

käitamine ja hooldus.

Tarkvaraarenduse elutsükkel ja etapid - kontseptsioon ja tüübid. Kategooria "Tarkvara arendamise elutsükkel ja etapid" klassifikatsioon ja tunnused 2017, 2018.

Riis. 5.2.

Need aspektid on:

1. lepinguline aspekt, milles klient ja tarnija sõlmivad lepinguline suhe ning rakendama hankimis- ja tarneprotsesse;
2. juhtimisaspekt, mis hõlmab tarkvara elutsüklis osalevate isikute (tarnija, tellija, arendaja, operaatori jne) juhtimistoiminguid;
3. toimimise 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. tugiprotsesside rakendamisega kaasnev toe aspekt, mille kaudu tugiteenused osutavad vajalikke teenuseid kõigile teistele töös osalejatele. Selles aspektis võib välja tuua tarkvara kvaliteedijuhtimise aspekti, mis hõlmab kvaliteedi tagamise protsesse, verifitseerimist, sertifitseerimist, ühishindamist ja auditit.

Organisatsiooniprotsesse teostatakse 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äärab täitmisjärjekorra ning protsesside, toimingute ja ülesannete seose 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 olelustsükli mudelit ja tarkvara arendusmeetodeid. Selle sätted on ühised kõigi tarkvaraarenduse olelustsükli mudelite, meetodite ja tehnoloogiate jaoks. Standard kirjeldab tarkvara elutsükli protsesside struktuuri, kuid ei täpsusta, kuidas nendes protsessides sisalduvaid tegevusi ja ülesandeid rakendada või täita.

Iga konkreetse tarkvara elutsükli mudel määrab selle loomise protsessi olemuse, mis on ajas järjestatud, omavahel seotud ja etappidena (faasidena) ühendatud tööde kogum, mille rakendamine 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 teatud ajaraamiga ja lõpeb konkreetse toote (tarkvaramudelid, tarkvarakomponendid, dokumentatsioon jne) väljalaskmisega, mis on määratud kindlaksmääratud nõuetega. selle etapi jaoks. Tarkvara loomise etapid eristatakse ratsionaalse planeerimise ja töökorralduse kaalutlustel, lõpetades täpsustatud tulemustega. Tarkvara elutsükkel sisaldab tavaliselt järgmisi etappe:

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

Mõned eksperdid tutvustavad täiendavat algetappi - teostatavusuuring süsteemid. See viitab tarkvarale ja riistvarasüsteemile, mille jaoks tarkvara luuakse, ostetakse või muudetakse.

Tarkvaranõuete kujunemise etapp on üks olulisemaid ja määrab suurel määral (isegi määrava!) kogu projekti edu. Selle etapi algus on kinnitatud ja heakskiidetud süsteemiarhitektuuri hankimine, mis hõlmab põhilepinguid funktsioonide jaotamise kohta riist- ja tarkvara vahel. See dokument peaks sisaldama ka kinnitust tarkvara toimimise üldise idee kohta, sealhulgas peamisi lepinguid funktsioonide jaotamise kohta isiku ja süsteemi vahel.

Tarkvaranõuete kujundamise etapp sisaldab järgmisi etappe.

1. Projektieelse töö planeerimine. Etapi põhiülesanneteks on arengueesmärkide määratlemine, esialgne majanduslik hindamine projekt, töögraafiku koostamine, ühise töörühma loomine ja koolitamine.
2. Automatiseeritud organisatsiooni (objekti) tegevuse uuringu läbiviimine, mille raames viiakse läbi tulevasele süsteemile esitatavate nõuete esialgne väljaselgitamine, organisatsiooni struktuuri kindlaksmääramine, organisatsiooni sihtfunktsioonide loetelu määramine, süsteemide analüüs funktsioonide jaotus osakondade ja töötajate kaupa, tuvastamine funktsionaalsed interaktsioonid osakondade vahel, infovood osakondade sees ja nende vahel, organisatsioonivälised objektid ja välised infomõjud, organisatsiooni tegevuse automatiseerimise olemasolevate vahendite analüüs.

Organisatsiooni (objekti) tegevuse mudeli koostamine, mis näeb ette uuringumaterjalide töötlemise ja kahte tüüpi mudelite ehitamise:

• "NAGU ON" ("nagu on") mudel, mis kajastab organisatsiooni hetkeseisu küsitluse ajal ja võimaldab mõista organisatsiooni toimimist, samuti tuvastada kitsaskohad ja sõnastada ettepanekud organisatsiooni parandamiseks. olukord;
• "TO-BE" mudel ("nagu see peaks olema"), mis peegeldab organisatsiooni töö uute tehnoloogiate ideed.

Iga mudel peaks sisaldama organisatsiooni tegevuse terviklikku funktsionaalset ja informatsioonilist mudelit, samuti (vajadusel) mudelit, mis kirjeldab organisatsiooni käitumise dünaamikat. Pange tähele, et konstrueeritud mudelid on iseseisva praktilise tähtsusega, olenemata sellest, kas ettevõte arendab ja juurutab infosüsteemi, kuna neid saab kasutada töötajate koolitamiseks ja ettevõtte äriprotsesside täiustamiseks.

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

Projekteerimisetapp sisaldab järgmisi samme.

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 tingimused funktsioneerimine, liidesed ja funktsioonide jaotus kasutajate ja süsteemi vahel, nõuded tarkvarale ja infokomponentidele, personali- ja arendusaeg, 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 peaks 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, andmete ja juhtimise moodulitevahelised liidesed;
• iga tarkvarakomponendi spetsifikatsioon, nimi, eesmärk, eeldused, suurused, kõnede jada, sisend- ja väljundandmed, ekslikud väljundid, algoritmid ja loogikalülitused;
• füüsiliste ja loogiliste andmestruktuuride moodustamine kuni üksikute väljade tasemeni;
• arvutusressursside jaotamise plaani väljatöötamine (keskprotsessorite aeg, mälu jne);
• nõuete täielikkuse, järjepidevuse, teostatavuse ja kehtivuse kontrollimine;
• esialgne integreerimis- ja silumisplaan, kasutusjuhend ja vastuvõtutesti plaan.

Detailprojekti valmimine on otsast lõpuni

Tarkvara elutsükli standardid

• GOST 34.601-90
• ISO/IEC 12207:1995 (Vene analoog – GOST R ISO/IEC 12207-99)

Tarkvaraarenduse metoodikad

• Rational Unified Process (RUP).
• Microsoft Solutions Framework (MSF). Sisaldab 4 faasi: analüüs, projekteerimine, arendus, stabiliseerimine, hõlmab objektorienteeritud modelleerimise kasutamist.
• äärmuslik programmeerimine ( äärmuslik programmeerimine, XP). Metoodika põhineb meeskonnatööl, efektiivne suhtlus kliendi ja töövõtja vahel kogu IP arendamise projekti jooksul. Arendus toimub järjestikku täiustatud prototüüpide abil.

Standard GOST 34.601-90

Standard GOST 34.601-90 näeb ette järgmised automatiseeritud süsteemi loomise etapid ja etapid:

1. Nõuete kujundamine AU-le
   1. Objekti ülevaatus ja AÜ loomise vajaduse põhjendus
   2. AU kasutajanõuete kujundamine
   3. Tööde sooritamise aruande ja ASi arendamise taotluse registreerimine
2. AS-i kontseptsiooni väljatöötamine
   1. Objekti uurimine
   2. Vajalike uurimistööde tegemine
   3. AU kontseptsiooni variantide väljatöötamine ja kasutajate nõudmistele vastava AU kontseptsiooni variandi valik
   4. Tehtud töö kohta aruande koostamine
3. Tehniline ülesanne
   1. Aafrika Liidu loomise lähteülesande väljatöötamine ja kinnitamine
4. Eelprojekt
   1. Süsteemi ja selle osade eelprojektlahenduste väljatöötamine
5. Tehniline projekt
   1. Süsteemi ja selle osade projekteerimislahenduste väljatöötamine
   2. AU ja selle osade dokumentatsiooni väljatöötamine
   3. Komponentide tarnimise dokumentatsiooni väljatöötamine ja vormistamine
   4. Projekteerimisülesannete väljatöötamine projekti külgnevates osades
6. töödokumentatsioon
   1. TEJ ja selle osade töödokumentatsiooni väljatöötamine
   2. Programmide väljatöötamine ja kohandamine
7. Kasutuselevõtt
   1. Automatiseerimisobjekti ettevalmistamine
   2. Personali koolitus
   3. AU komplekteerimine tarnitud toodetega (tarkvara ja riistvara, tarkvara ja riistvarasüsteemid, infotooted)
   4. Ehitus- ja paigaldustööd
   5. Kasutuselevõtutööd
   6. Eelkatsete läbiviimine
   7. Proovioperatsiooni läbiviimine
   8. Vastuvõtutestide läbiviimine
8. AC tugi.
   1. Tööde tegemine vastavalt garantiikohustustele
   2. Garantiijärgne teenindus

Eelnõud, tehnilised projektid ja töödokumentatsioon on järjest täpsemate projektlahenduste järjepidev konstrueerimine. Lubatud on välistada etapp "Eskiisprojekt" ja üksikud tööetapid kõigis etappides, ühendada etapid "Tehniline projekteerimine" ja "Detailne dokumentatsioon" "Detailprojektiks", teostada paralleelselt erinevaid etappe ja töid, lisada täiendavaid.

See standard ei ole praegu arendamiseks päris sobiv: paljud protsessid ei ole piisavalt kajastatud ja mõned sätted on aegunud.

ISO/IEC 12207/ ja selle rakendus

ISO/IEC 12207:1995 "Infotehnoloogia – tarkvara elutsükli protsessid" on peamine normatiivdokument, mis reguleerib tarkvara elutsükli protsesside koostist. See määratleb elutsükli raamistiku, mis sisaldab protsesse, tegevusi ja ülesandeid, mis tuleb tarkvara arendamise käigus täita.

Iga protsess on jagatud tegevuste komplektiks, iga toiming ülesannete kogumiks. Iga protsessi, toimingu või ülesande algatab ja teostab teine ​​protsess vastavalt vajadusele ning eelmääratletud täitmisjadasid pole. Ühendused sisendandmete alusel säilivad.

Tarkvara elutsükli protsessid

• 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 – tarkvara 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-99 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.

Lava- tarkvara loomise protsessi osa, mis on piiratud teatud ajaraamiga ja lõpeb konkreetse toote (mudelid, tarkvarakomponendid, dokumentatsioon) väljalaskmisega, mis on määratud selle etapi nõuetega.

Igas etapis saab läbi viia mitu ISO/IEC 12207-99 defineeritud protsessi ja vastupidi, sama protsessi saab läbi viia erinevates etappides. Protsesside ja etappide vahelise seose määrab ka kasutatav tarkvara elutsükli mudel.

Tarkvara elutsükli mudelid

Elutsükli mudeli all mõistetakse struktuuri, mis määrab elluviimise järjestuse ning protsesside, tegevuste ja ülesannete seose kogu elutsükli jooksul. Elutsükli mudel sõltub infosüsteemi spetsiifikast ning viimase loomise ja toimimise tingimuste eripärast.

Praeguseks on kõige laialdasemalt kasutatud järgmised peamised elutsükli mudelid:

• Ülesande mudel;

• kaskaadmudel (või süsteemne) (70-85);

• spiraalmudel (praegu).

Ülesande mudel

Süsteemi "alt-üles" arendamisel üksikutelt ülesannetelt kogu süsteemile (ülesannete mudelile) kaob paratamatult ühtne lähenemine arendusele, probleemid tekivad üksikute komponentide informatiivsel dokkimisel. Reeglina on nii, et ülesannete arvu kasvades suurenevad raskused, pead juba pidevalt muutuma olemasolevaid programme ja andmestruktuurid. Süsteemi arengutempo aeglustub, mis pidurdab organisatsiooni enda arengut. Kuid mõnel juhul võib see tehnoloogia olla asjakohane:

• Äärmiselt kiireloomulisus (vajalik, et ülesanded vähemalt kuidagi lahendatud saaks; siis tuleb kõik uuesti teha);

• Kliendi katsetamine ja kohandamine (algoritmid pole selged, lahendusi kobatakse katse-eksituse meetodil).

Üldine järeldus on, et sellisel viisil on võimatu luua piisavalt suurt tõhusat infosüsteemi.

Kaskaadmudel

Kaskaadmudel elutsükli pakkus välja 1970. aastal Winston Royce. See näeb ette projekti kõigi etappide järjestikuse rakendamise rangelt fikseeritud järjekorras. Üleminek järgmisele etapile tähendab eelmise etapi töö täielikku lõpetamist (joonis 1). Nõuete kujundamise etapis määratletud nõuded on rangelt dokumenteeritud lähteülesande vormis ja fikseeritud kogu projekti arendamise ajaks. Iga etapp kulmineerub täieliku dokumentatsioonikomplekti avaldamisega, millest piisab arenduse jätkamiseks teise arendusmeeskonna poolt.

Kaskaadmeetodi rakendamise positiivsed küljed on järgmised:

• igas etapis moodustatakse täielik projektdokumentatsiooni komplekt, mis vastab täielikkuse ja järjepidevuse kriteeriumidele;

• loogilises järjestuses teostatavad tööde etapid võimaldavad planeerida kõigi tööde valmimise ajastust ja vastavaid kulusid.

Projekti etapid vastavalt kose mudelile:

1. Nõuete kujundamine;
2. Disain;
3. Rakendamine;
4. Testimine;
5. rakendamine;
6. Kasutamine ja hooldus.

Riis. 1. Kaskaadne arendusskeem

Kose lähenemine on ennast tõestanud infosüsteemide ehitamisel, millele juba arenduse alguses saab kõik nõuded üsna täpselt ja terviklikult sõnastada, et anda arendajatele vabadus neid tehnilisest aspektist võimalikult hästi rakendada. Sellesse kategooriasse kuuluvad komplekssed arveldussüsteemid, reaalajas süsteemid ja muud sarnased ülesanded. Selle lähenemisviisi kasutamise käigus avastati aga mitmeid selle puudusi, mille põhjuseks oli eelkõige asjaolu, et tegelik süsteemide loomise protsess ei sobinud kunagi täielikult nii jäigasse skeemi. Loomise käigus tekkis pidev vajadus naasta eelmiste etappide juurde ja varem täpsustada või üle vaadata tehtud otsused. Selle tulemusena toimus tarkvara loomise tegelik protsess järgmisel kujul (joonis 2):

Riis. 2. Tarkvaraarenduse reaalne protsess vastavalt kaskaadskeemile

Kaskaadmeetodi peamiseks puuduseks on märkimisväärne viivitus tulemuste saamisel. Tulemuste kooskõlastamine kasutajatega toimub ainult pärast iga tööetapi lõppu planeeritud punktides, infosüsteemidele esitatavad nõuded "külmutatakse" tehnilise ülesande vormis kogu selle loomise ajaks. Seega saavad kasutajad esitada oma kommentaare alles pärast seda, kui töö süsteemiga on täielikult lõpetatud. Kui nõudeid ei ole pika tarkvaraarenduse perioodi jooksul täpselt sõnastatud või muudetud, jõuavad kasutajad süsteemini, mis ei vasta nende vajadustele. Automatiseeritud objekti mudelid (nii funktsionaalsed kui ka informatiivsed) võivad vananeda samaaegselt nende heakskiitmisega. IS-i arendamise süstemaatilise lähenemise olemus seisneb selle lagunemises (partitsioneerimises) automatiseeritud funktsioonideks: süsteem jaguneb funktsionaalseteks alamsüsteemideks, mis omakorda jagunevad alamfunktsioonideks, jaotatakse ülesanneteks jne. Jaotamisprotsess jätkub kuni konkreetsete protseduurideni. Samal ajal säilitab automatiseeritud süsteem tervikliku vaate, milles kõik komponendid on omavahel ühendatud. Seega on selle mudeli peamiseks eeliseks süstemaatiline arendus ning peamised puudused on aeglane ja kallis.

spiraalne mudel

Nende probleemide lahendamiseks tehti ettepanek spiraalne mudel elutsükkel (joonis 3), mille töötas välja 1980. aastate keskel Barry Boehm. See põhineb varajased staadiumid elutsükkel: analüüs ja disain. Nendel etappidel testitakse tehniliste lahenduste teostatavust prototüüpide loomisega.

Prototüüp- aktiivne tarkvarakomponent, mis rakendab üksikuid funktsioone ja väliseid liideseid. Iga iteratsioon vastab tarkvara fragmendi või versiooni loomisele, see selgitab projekti eesmärgid ja omadused, hindab saadud tulemuste kvaliteeti ja kavandab järgmise iteratsiooni tööd.

Iga iteratsioon on täielik arendustsükkel, mis viib toote sisemise või välise versiooni (või lõpptoote alamhulga) väljalaskmiseni, mida täiustatakse iteratsioonist iteratsioonini, et saada terviklik süsteem.

Iga spiraali pööre vastab tarkvara fragmendi või versiooni loomisele, mille peal määratakse projekti eesmärgid ja omadused, määratakse selle kvaliteet ning planeeritakse spiraali järgmise pöörde tööd. Nii süvenetakse ja konkretiseeritakse projekti detailidesse järjepidevalt ning selle tulemusena valitakse välja mõistlik variant, mis viiakse teostuseni.

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. Iteratiivse arenduse korral saab puuduva töö järgmise iteratsiooniga lõpule viia. Peamine ülesanne on näidata süsteemi kasutajatele võimalikult kiiresti toimivat toodet, aktiveerides seeläbi nõuete selgitamise ja täiendamise protsessi.

Spiraaltsükli põhiprobleemiks on järgmisse etappi ülemineku hetke kindlaksmääramine. Selle lahendamiseks on vaja kehtestada ajapiirangud igale elutsükli etapile. Üleminek kulgeb plaanipäraselt, isegi kui kõik plaanitud tööd ei ole tehtud. Plaan koostatakse varasemates projektides saadud statistiliste andmete alusel ning isiklik kogemus arendajad.

Joonis 3. IS elutsükli spiraalmudel

Üks võimalik lähenemine tarkvaraarendusele spiraalse elutsükli mudeli raames on viimasel ajal laialt levinud Rapid Application Development (RAD) metoodika. Seda mõistet mõistetakse tavaliselt tarkvara arendusprotsessina, mis sisaldab kolme elementi:

• väike programmeerijate meeskond (2-10 inimest);

• lühike, kuid hoolikalt läbi töötatud tootmisgraafik (2 kuni 6 kuud);

• iteratiivne tsükkel, mille käigus arendajad, kui rakendus hakkab kujundama, taotlevad ja rakendavad tootes kliendiga suhtlemise kaudu saadud nõudeid.

Tarkvara elutsükkel RAD metoodika järgi koosneb neljast faasist:

• nõuete määratlemise ja analüüsi etapp;

• projekteerimise etapp;

• rakendamise etapp;

• rakendamise etapp.

Igas iteratsioonis hinnatakse järgmist:

• projekti tähtaegade ja maksumuse ületamise risk;
• vajadus sooritada veel üks iteratsioon;
• süsteemi nõuetest arusaamise täielikkuse ja täpsuse aste;
• projekti lõpetamise otstarbekus.

Iteratiivse lähenemise eelised:

• Iteratiivne arendus lihtsustab oluliselt projekti muudatuste sisseviimist kliendi nõuete muutumisel.
• Spiraalmudeli kasutamisel üksikud elemendid infosüsteemid integreeritakse ühtseks tervikuks järk-järgult. Iteratiivse lähenemise korral on integratsioon praktiliselt pidev. Kuna integreerimine algab vähematest elementidest, siis selle juurutamisel tekib palju vähem probleeme (mõnede hinnangute kohaselt kulub juga arendusmudeli kasutamisel integreerimine projekti lõppedes kuni 40% kõigist kuludest).
• Iteratiivne arendus annab projektijuhtimises suurema paindlikkuse, võimaldades teha arendatavas tootes taktikalisi muudatusi.
• Iteratiivne lähenemine lihtsustab komponentide taaskasutamist (rakestab programmeerimisel komponentlähenemist). Selle põhjuseks on asjaolu, et projekti ühiseid osi on palju lihtsam tuvastada (identifitseerida), kui need on juba osaliselt välja töötatud, kui püüda neid esile tõsta kohe projekti alguses. Disaini ülevaatamine pärast mõnda esialgset iteratsiooni paljastab tavalised korduvkasutatavad komponendid, mida järgnevates iteratsioonides täiustatakse.
• Spiraalmudel võimaldab teil saada usaldusväärsema ja stabiilsema süsteemi. Seda seetõttu, et süsteemi arenedes leitakse ja parandatakse vead ja nõrkused igal iteratsioonil. Samas saab reguleerida kriitilisi jõudlusparameetreid, mis kosemudeli puhul on saadaval alles enne süsteemi juurutamist.
• Iteratiivne lähenemine annab võimaluse arendusprotsessi täiustada – iga iteratsiooni lõpus läbiviidav analüüs võimaldab hinnata, mida on vaja arendusorganisatsioonis muuta ja seda järgmises iteratsioonis parandada.