Standard ieee 90 eskort elementi. Tarkvara elutsükli protsessid. Edastatud andmete korrektsuse signaali kirjeldus

IT valdkonnas avaldavad praktika seisukohalt kõige asjakohasemad standardid järgmised organisatsioonid:

• Elektri- ja raadioelektroonikainseneride instituut(IEEE, www.ieee.org) on ​​olnud aastaid juhtiv teadus- ja tehnikaorganisatsioon, sealhulgas dokumentatsioonistandardite loomisel tarkvara. Enamiku standarditest on välja töötanud erinevad kogenud ja vastutustundlikest professionaalsetest inseneridest koosnevad komisjonid. Mõned IEEE standardid on muutunud ka ANSI (American National Standards Institute) standarditeks. Enamasti moodustasid IEEE standardid MU ettevalmistamise KP jaoks. Schmidt M. IEEE tarkvaratehnika standardite rakendamine.
• rahvusvaheline organisatsioon standardimiseks (ISO) omab tohutut mõju kogu maailmas, eriti Euroopa Liiduga (EL) tegelevate tootjaorganisatsioonide seas. Praegu on peaaegu kõik Vene Föderatsioonis tõlgitud ja vastu võetud kaasaegsed IT-standardid ISO poolt koos Rahvusvahelise Elektrotehnikakomisjoniga IEC (IEC) koostatud standardid. Teate, et toote kvaliteedi tagamise küsimustele pööratakse erilist tähelepanu aadressil rahvusvahelisel tasemel, seega vastavalt Vene Föderatsiooni valitsuse 02.02.1998 määrusele nr 113 vastavus ISO 9000 (ettevõtete kvaliteedijuhtimist (kvaliteedijuhtimist) reguleerivate standardite seeria) nõuetele - nõutav tingimus saada valitsuse korraldusi.
• Tarkvaraarendustehnoloogiate instituut(Software Engineering Institute – SEI, sei.cmu.edu – rohkem kui 1000 artiklit) asutas USA kaitseministeerium Carnegie Melloni ülikoolis, et tõsta DoD töövõtjate tarkvaratehnoloogia taset. SEI töö on omaks võtnud ka paljud äriettevõtted, kes peavad oma strateegiliseks eesmärgiks tarkvara arendusprotsessi täiustamist. ettevõtte missioon. Viitame ühele SEI väljatöötatud standardile nimega Capability Maturity Model (CMM).
• Objekti manipuleerimise tehnoloogia konsortsium(Object Management Group, www.omg.org) on mittetulundusühing, mille liikmeteks on umbes 700 ettevõtet. OMG seab hajutatud objektorienteeritud andmetöötluse standardi. Tuleb märkida, et OMG kasutab projektide kirjeldamisel standardina ühtset modelleerimiskeelt (UML). Uurime UML-i üksikasjalikult, kuna. selle keele kasutamine koos Rationali ühtse protsessiga on kursuseprojekti tuuma arendamise aluseks.

Süsteemi elutsükli mõiste

Tarkvaraarenduse standardimise vajadust on kõige tabavamalt kirjeldatud standardi tutvustuses. GOST R ISO / IEC 12207-99 " Infotehnoloogia. Protsessid eluring tarkvara tööriistad» : „Tarkvara on infotehnoloogia ja traditsiooniliste süsteemide, nagu transport, sõjandus, meditsiin ja finantssüsteem, lahutamatu osa. Tarkvara arendamiseks ja haldamiseks on palju ja erinevaid standardeid, protseduure, meetodeid, tööriistu ja töökeskkondi. See mitmekesisus tekitab raskusi tarkvara kavandamisel ja haldamisel, eriti tarkvaratoodete ja utiliitide kombineerimisel. Tarkvaraarenduse strateegia nõuab üleminekut sellelt komplektilt ühisele korrale, mis võimaldab tarkvara praktikutel tarkvara arendamisel ja haldamisel "sama keelt rääkida". See rahvusvaheline standard sätestab sellise üldise korra.

Standard GOST R ISO/IEC 12207-99 määratleb tarkvarasüsteemi põhikontseptsiooni - "elutsükkel" (GOST R ISO / IEC TO 15271-2002 "Infotehnoloogia. GOST R ISO / IEC 12207 rakendamise juhised").

GOST R ISO/IEC 12207-99 tutvustab elutsükli mudeli mõistet kui protsessidest koosnevat struktuuri, mis hõlmab süsteemi eluiga alates sellele nõuete kehtestamisest kuni kasutamise lõpetamiseni. Tehakse ettepanek seda määratlust parandada ja jagada kaheks määratluseks:

1. eluring- protsesside kogum, mis on jagatud töödeks ja ülesanneteks, sealhulgas arendus, kasutamine ja hooldus tarkvaratoode, mis hõlmab süsteemi eluiga alates sellele nõuete kehtestamisest kuni selle kasutamise lõpetamiseni.
2. elutsükli mudel- struktuur, mis määrab tarkvarasüsteemi elutsükli jooksul teostatavate protsesside, tööde ja ülesannete realiseerimise järjestuse ning nendevahelise seose.

Elutsükli protsessid jagunevad kolme rühma: põhi-, abi- ja organisatsiooniline.

Põhiprotsesside rühm sisaldab: hankimine, tarnimine, arendus, käitamine ja hooldus. Peamised elutsükli protsessid viiakse ellu tarkvara elutsükli peamiste osapoolte kontrolli all. Peamise osapoole all mõistetakse üht neist organisatsioonidest, kes algatavad või teostavad tarkvaratoodete arendust, käitamist või hooldust. Peamised osapooled on klient, tarnija, arendaja, operaator ja tarkvara hoolduspersonal.

Joonis - IS-i elutsükli peamised protsessid

Abiprotsesside rühma kuuluvad protsessid, mis tagavad põhiprotsesside täitmise:

• dokumentatsioon;
• Konfiguratsiooni juhtimine;
• kvaliteedi tagamine;
• kontrollimine;
• atesteerimine;
• hinne;
• audit;
• probleemide lahendus.

Organisatsiooniprotsesside rühm hõlmab protsesse:

• projekti juht;
• projekti infrastruktuuri loomine;
• elutsükli enda määratlemine, hindamine ja täiustamine;
• haridust.

GOST 12207-99 tekstis põhi-, abi- ja korraldusprotsessidesse kuuluvaid töid iseloomustatakse väga üldiselt, tegelikult on välja toodud vaid nende suunad, mistõttu on projekteerimisega alustamiseks vaja standardeid ja lisakirjandust, mis paljastab iga sisu. eraldi protsess või veel parem – eraldi teos.
Põhiprotsesside rühmast pakub suurimat huvi arendusprotsess.
Tuleb märkida, et GOST 34.601-90 " Automatiseeritud süsteemid. Loomise etapid" on automatiseeritud süsteemi loomise protsess jagatud järgmisteks etappideks:

• AU-le nõuete kujundamine,
• AS-i kontseptsiooni väljatöötamine,
• tehniline ülesanne,
• eelprojekt,
• tehniline projekt,
• töödokumentatsioon,
• kasutuselevõtt,
• saatel.

Etapid on jagatud etappideks, mille sisu kajastab mitmete GOST 12207-99 kirjeldatud ülesannete sisu.

Arendusprotsess

Arendusprotsess näeb ette arendaja poolt tehtavad toimingud ja ülesanded ning katab PS ja selle komponentide loomise vastavalt määratud nõuetele, sh projekteerimis- ja töödokumentatsiooni koostamist; tarkvaratoodete toimivuse ja sobiva kvaliteedi kontrollimiseks vajalike materjalide ettevalmistamine, personali koolituse korraldamiseks vajalikud materjalid jms.

Joonis – Arendusprotsessi struktuur

Ettevalmistustööd

algab PS elutsükli mudeli valikuga, mis vastab projekti mastaapile, olulisusele ja keerukusele. Arendusprotsessi tegevused ja ülesanded peaksid olema valitud mudeliga kooskõlas. Arendaja peab valima, kohandama projekti tingimustega ja kasutama tellijaga kokkulepitud standardeid, meetodeid ja arendusvahendeid, samuti koostama tööplaani.

Nõuete analüüs

PS-i nõuete analüüs hõlmab järgmiste omaduste määramist iga PS-i komponendi jaoks:

• funktsionaalsus, sealhulgas komponendi jõudlusnäitajad ja töökeskkond;
• välised liidesed;
• töökindluse ja ohutuse spetsifikatsioonid;
• ergonoomilised nõuded;
• nõuded kasutatavatele andmetele;
• paigaldus- ja vastuvõtunõuded;
• nõuded kasutaja dokumentatsioonile;
• kasutus- ja hooldusnõuded.

arhitektuurne disain

Süsteemi kõrgel tasemel eesmärk on määrata kindlaks oma seadmete, tarkvara komponendid ja toimingud, mida süsteemi käitavad töötajad teevad. Süsteemi arhitektuur peab vastama süsteemi nõuetele ning aktsepteeritud projekteerimisstandarditele ja tavadele.
PS-i arhitektuuri disain sisaldab järgmisi ülesandeid (iga PS-i komponendi jaoks):

• PS-i nõuete muutmine arhitektuuriks, mis määratleb kõrgel tasemel PS-i struktuuri ja selle komponentide koostise;
• PS-i ja andmebaaside programmiliideste arendamine ja dokumenteerimine;
• kasutajadokumentatsiooni eelversiooni väljatöötamine;
• testide eelnõuete ja PS-i integreerimisplaani väljatöötamine ja dokumenteerimine.

Detailne disain

PS sisaldab järgmisi ülesandeid:

• PS komponentide ja nendevaheliste liideste kirjeldus madalamal tasemel, mis on piisav nende hilisemaks sõltumatuks kodeerimiseks ja testimiseks;
• üksikasjaliku andmebaasi kujunduse väljatöötamine ja dokumenteerimine;
• testidele esitatavate nõuete ja tarkvarakomponentide testimise plaani väljatöötamine ja dokumenteerimine;

Kodeerimine ja testimine

PS hõlmab järgmisi ülesandeid:

• PS-i ja andmebaasi iga komponendi arendamine (kodeerimine) ja dokumenteerimine, samuti testimisprotseduuride komplekt ja andmed nende testimiseks;
• PS iga komponendi ja andmebaasi testimine nende nõuetele vastavuse osas. Komponentide testimise tulemused tuleks dokumenteerida;
• kasutajadokumentatsiooni uuendamine (vajadusel);
• PS integratsiooniplaani uuendamine.

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 olema täidetud, et kvalifitseerida tarkvaratoode spetsifikatsioonidele vastavaks ja kohapeal kasutamiseks valmis.

GOST R ISO/IEC 12119-2000 “Infotehnoloogia. Tarkvarapaketid. Kvaliteedinõuded ja testimine" sisaldab juhiseid, mis määratlevad, kuidas testitakse toote vastavust selle kvaliteedinõuetele. Testimine on töömahukas protsess. Mõnede ekspertide sõnul protsent
ajajaotus projekteerimise - arenduse - testimise protsesside vahel on vahekorras 40-20-40. Sellega seoses kasutatakse laialdaselt testimise automatiseerimissüsteeme. IEEE 1209-1992 standard "CASE-tööriistade hindamise ja valiku soovituslik praktika" sätestab üldised nõuded testimise automatiseerimise tööriistade funktsioonidele.

Süsteemi integreerimine

seisneb kõigi selle komponentide, sealhulgas PS ja seadmete kokkupanemises. Pärast integreerimist läbib süsteem omakorda kvalifikatsioonitesti, et kontrollida, kas see vastab sellele kehtestatud nõuetele. Samal ajal toimub ka süsteemi täieliku dokumentatsiooni registreerimine ja kontrollimine.

Süsteemi paigaldamine

teostab arendaja vastavalt planeeringule lepingus ette nähtud keskkonnas ja seadmetel. Installiprotsessi käigus kontrollitakse PS-i ja andmebaaside toimivust.

Süsteemi aktsepteerimine

näeb ette tarkvara ja süsteemi kvalifikatsiooni testimise tulemuste hindamise ja hindamise tulemuste dokumenteerimise, mille teostab arendaja abiga tellija. Tarkvara lõpliku üleandmise kliendile teostab vastavalt lepingule arendaja, pakkudes samas vajalikku koolitust ja tuge. Meie kursus on peamiselt suunatud tarkvaraarenduse protsessi esimese nelja töö üksikasjalikule ülevaatele. Kõigile nendele teostele on pühendatud eraldi jaotis ja nüüd on edasiseks tutvustamiseks vaja öelda paar sõna PS-i elutsükli mudelite kohta.

Tarkvara elutsükli mudelid

Elutsükli mudel- struktuur, mis määrab infosüsteemi elutsükli jooksul teostatavate protsesside, tööde ja ülesannete elluviimise järjestuse ning nendevahelise seose.

Praeguseks on enim kasutatud kahte peamist elutsükli mudelit:

• kaskaadi (juga) mudel;
• spiraalne mudel.

Kaskaadmudel

Kaskaadmudel demonstreerib klassikalist lähenemist arengule erinevaid süsteeme erinevates rakendusvaldkondades. Arenguks infosüsteemid Seda mudelit kasutati laialdaselt 70ndatel ja 80ndate esimesel poolel. See on GOST 34.xxx seeria ja USA kaitseministeeriumi standardi DOD-STD-2167A aluseks olev kaskaadmudel. Töötleb GOST 12207-99 standardis GOST 34.601-90 “Automatiseeritud süsteemid. Loomise etapid» nimetatakse etappideks ja nende koostis on veidi erinev.
Kaskaadmudel näeb ette protsesside järjestikuse korraldamise. Veelgi enam, üleminek järgmisele protsessile toimub alles pärast seda, kui kõik eelmisega seotud tööd on täielikult lõpetatud. Iga protsess kulmineerub täieliku dokumentatsiooni väljastamisega, millest piisab töö jätkamiseks teise arendusmeeskonna poolt.

Kose mudeli peamine puudus on see, et vead ja puudused mis tahes etapis ilmnevad reeglina järgmistes tööetappides, mis toob kaasa vajaduse tagasi pöörduda. Vastavalt konsultatsioonifirma Standish Group 1998. aastal USA-s lõppes enam kui 28% ettevõtete infosüsteemidest (IT-projektidest) ebaõnnestumisega; ligi 46% IT-projektidest lõppes eelarve ületamisega (keskmiselt 189%); ja ainult 26% projektidest mahub ettenähtud aja ja eelarvesse.

Lisaks on kaskaadmudeli puudused järgmised:

• paralleelse töö keerukus;
• projektijuhtimise keerukus;
• investeeringute kõrge riskitase ja ebausaldusväärsus (eelmistesse etappidesse naasmist võib seostada mitte ainult vigadega, vaid ka muudatustega, mis on arenduse käigus toimunud ainevaldkonnas või kliendi nõudmistes. Pealegi nendel põhjustel projekti ülevaatamiseks tagastamine ei garanteeri, et ainevaldkond ei muutu projekti järgmise versiooni valmimise ajaks uuesti.Tegelikult tähendab see, et on võimalus, et arendusprotsess "loopib" ja süsteem ei jõua kunagi kasutuselevõtuni.Projekt kulud kasvavad pidevalt ja toote valmimise tähtajad hilinevad pidevalt).

spiraalne mudel

Erinevalt kaskaadist hõlmab see infosüsteemi arendamise iteratiivset protsessi. Spiraalmudeli pakkus välja 1980. aastate keskel Barry Boehm. Iga spiraali pööre vastab tarkvaratoote fragmendi või versiooni loomisele, see määrab projekti eesmärgid ja omadused, määrab selle kvaliteedi ja kavandab tööd spiraali järgmisel pöördel. Igal iteratsioonil süvendatakse ja järjepidevalt konkretiseeritakse projekti üksikasju, kogutakse mõõdikuandmeid, mida kasutatakse järgnevate iteratsioonide optimeerimiseks. Keerulisemaks muutuvad aga dokumentatsiooni terviklikkuse tagamise mehhanismid (kui konkreetne nõue või definitsioon on tekstis toodud vaid üks kord), mis nõuab spetsiaalsete tööriistade kasutamist.
Spiraalmudeli peamised omadused:

• keeldumine nõuete fikseerimisest ja kasutajanõuetele prioriteetide määramisest;
• prototüüpide jada väljatöötamine, alustades kõrgeima prioriteediga nõuetest;
• riskide tuvastamine ja analüüs igal iteratsioonil;
• tulemuste hindamine iga iteratsiooni lõpus ja järgmise iteratsiooni kavandamine.

Rakenduste kiire arendus

XX sajandi 90ndatel loodi spiraalmudeli põhjal praktiline tehnoloogia nimega "kiire rakendusarendus" - RAD (Rapid Application Development). Samal ajal koosnes LC neljast etapist:

• nõuete analüüs ja planeerimine,
• disain,
• rakendamine,
• rakendamine.

RAD-i põhiprintsiibid:

• rakenduste arendamine iteratsioonide teel;
• valikuline töö täielik lõpetamine tarkvara elutsükli igas etapis;
• kasutajate kohustuslik kaasamine arendusprotsessi;
• konfiguratsioonihaldusvahendite kasutamine, mis hõlbustavad projektis muudatuste tegemist ja valmis süsteemi hooldamist;
• prototüüpide kasutamine kasutajate vajaduste paremaks mõistmiseks ja rahuldamiseks;
• projekti testimine ja arendus, mis viiakse läbi arendusega samaaegselt;
• väikese hästi juhitud professionaalide meeskonna arendamise juhtimine;
• süsteemiarenduse pädev juhtimine, töö selge planeerimine ja kontroll.

2001. aasta alguses moodustasid mitmed juhtivad tarkvarainsenerid (Martin Fowler, Kent Beck jt) grupi nimega Agile Alliance, et toetada ja arendada uut lähenemist disainile – "kiire tarkvaraarendus" (Agile Software Development). Selle lähenemisviisi üheks teostuseks on äärmuslik programmeerimine (XP).

Ekstreemse programmeerimise põhimõtted on järgmised:

1. Meeskonda kuulub kolm kuni kümme programmeerijat. Üks või mitu klienti peavad suutma pidevalt pakkuda jooksvaid teadmisi.
2. Programmid töötatakse välja kolmenädalaste iteratsioonidena. Iga iteratsioon loob töötava testitud koodi, mida kliendid saavad kohe kasutada. Kokkupandud süsteem tarnitakse lõppkasutajatele iga väljalaskeperioodi lõpus, mis võib kesta kaks kuni viis iteratsiooni.
3. Kogutud tarkvaranõuete ühikuks on registrikaardile jäädvustatud “kasutajalugu” (kasutajalugu), mis kirjeldab kasutaja seisukohast ühe iteratsiooniga arendatavat funktsionaalsust. Kliendid ja programmeerijad kavandavad järgmise iteratsiooni tööd järgmisel viisil:
   • programmeerijad hindavad iga kaardi täitmise aega;
   • kliendid tähtsustavad, muudavad ja muudavad vastavalt vajadusele. Loo arendamine algab selle arutelust programmeerijate ja asjatundliku kliendi poolt.
4. Programmeerijad töötavad paaris ja järgivad rangeid kodeerimisstandardeid, mille nad on projekti alguses seadnud. Nad loovad üksusetestid kõige jaoks, mida nad kirjutavad, ja tagavad, et neid teste käitatakse iga kord, kui kood kontrollitakse kohustuslikku versioonikontrolli ja konfiguratsioonihaldust.
5. Kui programmeerijad on tööl, külastavad kliendid programmeerijaid, et selgitada ideid, kirjutada süsteemi aktsepteerimise teste, mida iteratsiooni ajal käivitada, ja lõpuks valida lugusid, mida järgmises iteratsioonis rakendada.
6. Iga päev korraldab meeskond operatiivkoosolekuid, kus programmeerijad räägivad, millega nad tegelevad, mis läheb hästi ja mis vajab abi. Iga iteratsiooni lõpus on veel üks koosolek, kus hinnatakse, mis läks hästi ja mille kallal on vaja järgmisel korral tööd teha. See kontroll-loend on postitatud, et kõik saaksid järgmise iteratsiooni ajal tööd näha.
7. Üks inimene meeskonnast määratakse "mentoriks". Koos meeskonnaliikmetega hindab ta nende põhitehnikate kasutamist: paarisprogrammeerimine ja -testimine, paarisrotatsioon, disainiotsuste lihtsaks hoidmine, suhtlemine jne. arendusprotsessi pidevaks täiustamiseks.

Kiire tarkvaraarenduse lähenemine ei ole universaalne ja on rakendatav ainult teatud klassi projektidele. Selliste projektide iseloomustamiseks võttis Alistair Coburn kasutusele kaks parameetrit – kriitilisus ja mastaap.
Kriitilisuse määravad tarkvara defektide tagajärjed ja sellel võib olla üks neljast tasemest:

• C - defektid põhjustavad mugavuse kaotust;
• D - defektid põhjustavad tagastatavate vahendite (materiaalsete või rahaliste) kaotuse;
• E - defektid põhjustavad asendamatute vahendite kaotust;
• L - defektid kujutavad endast ohtu inimese elule.

Skaala määrab projektis osalevate arendajate arv:

• 1 kuni 6 inimest - väikesemahuline;
• 6 kuni 20 inimest - keskmise suurusega;
• üle 20 inimese – suur ulatus.

Coburni sõnul on kiire tarkvaraarendus rakendatav ainult väikese ja keskmise mastaabiga madala kriitilisusega (C või D) projektides. See tähendab, et RAD ja XP tehnoloogiad sobivad kõige paremini suhteliselt väikeste projektide jaoks, mis on välja töötatud konkreetsele kliendile ning ei ole rakendatavad keerukate arvutusprogrammide, operatsioonisüsteemide või keerukate objektide reaalajas juhtimisprogrammide ehitamisel, samuti turvalisusest sõltuvate süsteemide jaoks. inimestest.

Ühtne tarkvara arendusprotsess

Praegu jätkub töö IP arendamiseks mingi universaalse protsessi loomisel. 1999. aastal Ratsionaalsed töötajad Ivar Jacobson, Gradi Booch ja James Rambo andsid välja raamatu Unified Software Development Process (Unified Software Development Process, Unified Software Development Process), mis tõlgiti vene keelde ja ilmus kirjastuses Piter aastal 2002. Ühtne protsess on katse ühendada kose ja iteratiivsed mudelid J C.

Samal ajal on LC jagatud 4 faasi:

1. Algus (algamine): projekti esialgne hindamine.
   • luuakse lihtsustatud kasutusjuhtude mudel, mis sisaldab juurutamise seisukohalt kriitilisemaid kasutusjuhtumeid;
   • luuakse arhitektuuri prooviversioon, mis sisaldab tähtsamaid alamsüsteeme;
   • riskid tuvastatakse ja prioriseeritakse;
   • kavandatakse projekteerimise etapp;
   • kogu projekt tervikuna on ligikaudne;
2. täpsustamine: enamik kasutusjuhtumeid on üksikasjalikult kirjeldatud ja süsteemi arhitektuur on välja töötatud. Projekteerimisetapi lõpus koostab projektijuht projekti lõpuleviimiseks vajalike ressursside hinnangu. Vaja on vastata küsimusele: kas kasutusjuhud, arhitektuur ja planeering on piisavalt välja töötatud, et oleks võimalik anda lepingulisi kohustusi tööde teostamiseks ning liikuda edasi “Lähteülesande” koostamise ja allkirjastamisega?;
3. Ehitus- toote loomine. Selle etapi lõpus sisaldab toode kõiki kasutusjuhtumeid, mille arendajad ja klient on otsustanud praegusesse väljalasesse lisada;
4. rakendamine (üleminek)- toote vabastamine. Toote beetaversiooni testib ettevõtte testimisosakond ning samal ajal korraldatakse süsteemi proovitöö kasutajate poolt. Seejärel parandavad arendajad leitud vead ja teevad mõned soovitatud täiustused suureks väljalaseks, mida valmistatakse ette laialdaseks levitamiseks.

Iga USDP etapp võib olenevalt projekti suurusest sisaldada ühte või mitut iteratsiooni. Iga iteratsiooni ajal saab käivitada 5 peamist ja mitmeid täiendavaid töölõime.
USDP peamised töövood hõlmavad järgmist:

• nõuete määratlemine (OT);
• analüüs (A);
• disain (P);
• rakendamine (P);
• testimine (T).

Täiendavad töövood võivad hõlmata järgmist:

• kvaliteedi tagamise töö (K),
• dokumentatsioon (D),
• projektijuhtimine (U),
• konfiguratsioonihaldus (MC),
• infrastruktuuri loomine ja haldamine (I)
• ja teised.

Joonis - Elutsükli mudel ühtse tarkvaraarenduse protsessi järgi

Elutsükli mudeli valik sõltub suuresti arendatava süsteemi tüübist ja mastaabist. Iteratiivne elutsükli mudel on rakendatav enamiku vaba aja ASOI-de arendamiseks, samal ajal kui kose mudel on sobivam reaalajas süsteemide jaoks. Loengutes pöörame IS-i disaini küsimustega tegelemisel erilist tähelepanu Unified Modeling Language (UML) kasutamisele ning kuna selle loojad on Grady Booch ja James Rambo, siis viitame ka ühtse arenduse ideoloogiale. Protsess.

Pilt - määrused arendusprotsessiga kaasnev

Elutsükli protsesside toetamine

Kvaliteedi tagamise protsess

Kvaliteedi tagamise protsess annab asjakohased garantiid, et PS ja selle elutsükli protsessid vastavad kindlaksmääratud nõuetele ja kinnitatud plaanidele. PS-i kvaliteedi all mõistetakse omaduste kogumit, mis iseloomustavad PS-i võimet täita määratud nõudeid.

Joonis - Elutsükli abiprotsesside struktuur

GOST R ISO/IEC 9126-93 kontekstis. "Infotehnoloogia. Tarkvaratoodete hindamine. Kvaliteedikarakteristikud ja nende kasutamise juhised“ kvaliteeditunnust mõistetakse kui „tarkvaratoote omaduste (atribuutide) kogumit, mille abil selle kvaliteeti kirjeldatakse ja hinnatakse“.

Standard määratleb kuus kõikehõlmavat omadust, mis minimaalse kattumisega kirjeldavad PS kvaliteeti:

• funktsionaalsust– funktsioonide komplekti olemuse ja nende spetsiifiliste omadustega seotud atribuutide kogum. Funktsioonid on need, mis täidavad välja öeldud või kaudseid vajadusi;
• usaldusväärsus– atribuutide kogum, mis on seotud tarkvara võimega säilitada oma jõudluse taset kindlaksmääratud tingimustel kindlaksmääratud ajavahemiku jooksul;
• praktilisus– atribuutide kogum, mis on seotud kasutamiseks vajaliku töö ulatuse ja sellise kasutuse individuaalse hindamisega konkreetse või kavandatud kasutajate kogumi poolt;
• tõhusust– atribuutide kogum, mis on seotud tarkvara töökvaliteedi taseme ja kindlaksmääratud tingimustel kasutatavate ressursside hulga vahelise seosega
• hooldatavus– konkreetsete muudatuste (muudatuste) tegemiseks vajalike tööde mahuga seotud atribuutide kogum;
• liikuvus– atribuutide kogum, mis on seotud tarkvara võimalusega teisaldada ühest keskkonnast teise.

GOST 28195-89 “Tarkvara kvaliteedi hindamine. Üldsätted» ülaosas, esimesel tasemel, identifitseerib see 6 näitajat – kvaliteeditegurid: töökindlus, korrektsus, kasutusmugavus, tõhusus, mitmekülgsus ja hooldatavus. Neid tegureid kirjeldatakse kokkuvõttes 19 teise taseme kvaliteedikriteeriumiga. Kvaliteedinäitajate täpsemat täpsustamist esindavad mõõdikud ja hindamiselemendid, mida on umbes 240. Igaüht neist on soovitatav hinnata eksperdil vahemikus 0 kuni 1. Tehakse ettepanek valida tegurite koosseis, kasutatavad kriteeriumid ja mõõdikud olenevalt PS eesmärgist, funktsioonidest ja elutsükli etappidest.

Standardis GOST 28806-90 “Tarkvara kvaliteet. Tingimused ja määratlused" on vormistatud üldmõisteid programm, tarkvaratööriist, tarkvaratoode ja nende kvaliteet. Antud on 18 kõige sagedamini kasutatava programmi jõudluse hindamisega seotud termini definitsioonid. Täpsustatud on GOST 28195-89 toodud põhiliste kvaliteedinäitajate mõisteid.
PS kvaliteedi tagamise küsimus nõuab erilist tähelepanu, sest vastavalt Vene Föderatsiooni valitsuse 02.02.1998 määrusele nr 113 on riikliku tellimuse saamise eelduseks kvaliteedi tagamise ja juhtimise rahvusvahelise standardi ISO 9000 nõuete täitmine.
peal praegune etapp ei piisa ainult meetodite olemasolust toodetava ja kasutatava tarkvara kvaliteedi hindamiseks (väljundkontroll), vaid on vaja osata kvaliteeti planeerida, mõõta seda tarkvara elutsükli kõikides etappides ning kohandada tarkvara tootmisprotsessi vastavalt oma vajadustele. kvaliteeti parandada.

ISO 9000 seeria standardid on liiga üldised. Iga tarkvaraettevõte, kes soovib juurutada tõhusat ISO 9000 seeria standarditel põhinevat kvaliteedijuhtimissüsteemi, peab arvestama oma valdkonna eripäraga ning välja töötama kvaliteediskoorikaardi, mis kajastaks kvaliteeditegurite tegelikku mõju tarkvaratootele. Selleks on paljud organisatsioonid määratlenud protsessi süstemaatilise ja täielik kontroll– Kvaliteedi tagamine, mis algab projekti käivitamisega, hõlmab ülevaatust ja testimist ning mida ideaalis viib läbi mõni sõltumatu organisatsioon. Tegelikult viib kvaliteedikontrolli enamasti läbi töö autori kolleegide rühm.
Ülevaatuse eesmärk on kontrollida konstruktsiooni osadel defekte:

• dokumentatsioon,
• nõuded
• analüüsi tulemused,
• disain,
• nimekirjad jne.

Ülevaatuse asjakohasus näitab kulude võrdlust ning defekti tuvastamist ja parandamist ülevaatuse ja integreerimise ajal vastavalt Fagin, M., Design and Code Inspections to Reduce Errors in Program Development, IBM Systems Journal. Mõned autorid peavad neid andmeid väga alahinnatuks.

Veaotsing on muutunud palju tõsisemaks pärast seda, kui Veenusele saadetud mitme miljardi dollari suurune Ameerika satelliit kaotas juhitavuse trajektoori korrigeerimise alamprogrammi kirjavea tõttu - koma asemel pandi semikoolon.
Kvaliteedi hindamine ja parandamine toimub mõõdikute – mõne protsessiindikaatori kvantitatiivse iseloomustuse – kasutamise kaudu.

Kontrollimine nõuab järgmisi samme:

1. Kontrolliprotsess algab planeerimisest. Defektid liigitatakse kirjelduse, raskusastme ja tüübi järgi. Mõõdikute valik, mille järgi kontrolli teostatakse, saadud andmete kogumise ja analüüsimise tööriistade valik, samuti rollide jaotus inspektorite vahel toimub:
   • Ülevaatuse korrektse läbiviimise eest vastutab juht.
   • Korrektor vastutab meeskonna tegevuse eest ja suunab seda õiges suunas. Kontrollimisel osaleb korrektor.
   • Defektide kirjelduse ja liigitamise fikseerimise eest vastutab registripidaja, nagu meeskonnas tavaks. Kontrollimisel osaleb ka registripidaja.
   • Spetsialiseerunud inspektor on mõne kitsa valdkonna spetsialist, kuhu kontrollitav fragment kuulub.
2. Kontrolliobjekti paremaks mõistmiseks võib vajadusel korraldada ülevaateseminari.
3. Ülevaatuse läbiviimine. Inspektorid kontrollivad tööd täies mahus oma töökohtadel (näiteks kontrollivad, kas kontrollitav programmikood vastab detailprojektile). Tavaliselt sisestavad inspektorid kõik vead andmebaasi (näiteks võrgu kaudu kättesaadavad) koos kirjelduste ja klassifikatsiooniga. Kontrollitavad süsteemi osad peavad olema loogiliselt terviklikud.
4. Toimub kontrollkoosolek, mille käigus osalejad tutvustavad oma tulemusi.
5. Autor parandab vead (täpsustusfaas).
6. Viimasel töö valmimise koosolekul veenduvad korrektor ja autor, et kõik vead on parandatud. See ei tähenda aga, et korrektor peab kogu töö üksikasjalikult läbi vaatama. Kõik parandused jäävad oma töö eest vastutava autori südametunnistusele.
7. Nagu teistegi protsesside puhul, tuleb grupp kokku, et arutada kontrolliprotsessi ennast ja otsustada, kuidas seda parandada.

Ettevõte peab arvestust kontrollidele kulunud aja ja ülevaadatud tööde mahu kohta, et kasutada seda edaspidi kontrollide hindamisel. Range ajapiirangu tingimustes nn. nn eestkostesüsteem, kus iga meeskonnaliiget valvab kolleeg.
Kõigi kvaliteedikontrolli tegurite arvessevõtmiseks on mugav kasutada loendeid kontrollküsimused. Sellised loendid sisaldavad üksusi, mida tuleb järjestikku kontrollida.
Näiteks tarkvara kvaliteedi tagamise plaan (SQAP) vastavalt IEEE 739-1989 standardile määratleb:

• kes vastutab kvaliteedi eest individuaalne, juht, rühm, organisatsioon jne;
• millist dokumentatsiooni on vaja;
• milliseid meetodeid hakatakse kvaliteedi tagamisel kasutama – kontrollimine, testimine jne;
• milliseid tegevusi protsessijuhtimise käigus läbi viia - koosolekud, auditid, ülevaated jne.

Töökindlus ja turvalisus

Üks olulisemaid kvaliteedi mõistes sisalduvaid omadusi on usaldusväärsuse omadus.
Vastavalt GOST 13377-75 "Inseneri töökindlus. Mõisted ja määratlused", töökindlus on objekti omadus täita kindlaksmääratud funktsioone, säilitades samal ajal kehtestatud toimivusnäitajate väärtused kindlaksmääratud piirides, mis vastavad kindlaksmääratud kasutusviisidele ja -tingimustele, hooldusele, remondile, ladustamisele ja säilitamisele. transport. Seega on töökindlus süsteemi sisemine omadus, mis sisaldub selle loomisel ja avaldub ajas töötamise ja töötamise ajal.
PS töökindlust iseloomustab kõige laiemalt stabiilsus ehk tõrgeteta töövõime ja tööseisundi taastatavus pärast rikkeid või rikkeid.
Loodud ja muudetud programmide töökindlus ja turvakontroll peaks kaasnema kogu tarkvarasüsteemi elutsükliga spetsiaalselt organiseeritud tõhusa tehnoloogiline süsteem nende kvaliteedi tagamine. Keerulise ja kriitilise tähtsusega tarkvara kvaliteedi kontrollimine ja kinnitamine peaks toimuma sertifitseeritud probleemidele orienteeritud sertifitseeritud laborite sertifitseerimisega.

Standardid valdkonnas infoturbe jagunevad kahte rühma:

• hindamisstandardid, mis on loodud IS ja kaitsevahendite hindamiseks ja klassifitseerimiseks vastavalt turvanõuetele – USA kaitseministeeriumi standard "Usaldusväärsete hindamiskriteeriumid arvutisüsteemid”, “Euroopa riikide ühtlustatud kriteeriumid”, rahvusvaheline standard “Infotehnoloogia turvalisuse hindamise kriteeriumid”, Venemaa Riikliku Tehnilise Komisjoni juhenddokumendid;
• reguleerivad spetsifikatsioonid erinevaid aspekte Internet Engineering Task Force (IETF) ja selle tütarettevõtete, turvalisuse töörühma poolt avaldatud turvatööriistade ja meetodite rakendamine ja kasutamine.

Kõige olulisemate hindamisstandardite hulka kuuluvad:

• Venemaa riiklik tehniline komisjon. Juhenddokument. Arvutiseadmed. Tulemüürid. Kaitse volitamata juurdepääsu eest teabele. Turvanäitajad volitamata juurdepääsu eest teabele. - Moskva, 1997 - klassifitseerib tulemüürid vastavalt seitsmetasemelise võrdlusmudeli andmevoogude filtreerimise tasemele.
• ISO/IEC 15408:1999 Infotehnoloogia turvalisuse hindamise kriteeriumid.

Teine rühm sisaldab järgmisi dokumente:

• X.800 "Koostalitlusvõime turvaarhitektuur avatud süsteemid". Tuvastatakse peamised võrguturbeteenused: autentimine, juurdepääsukontroll, konfidentsiaalsus ja/või andmete terviklikkus. Teenuste rakendamiseks on ette nähtud järgmised võrguturbe mehhanismid ja nende kombinatsioonid: krüptimine, elektrooniline digitaalne allkiri, juurdepääsu kontroll, andmete terviklikkuse kontroll, autentimine, liikluse suurendamine, marsruutimise kontroll, notariaalne kinnitamine.
• Interneti kogukonna spetsifikatsioon RFC 1510 "Kerberose võrgu autentimise teenus (V5)" käsitleb autentimise probleemi heterogeenses hajutatud keskkonnas, mis toetab ühekordse sisselogimise kontseptsiooni;
• X.500 "Katalogiteenus: ülevaade kontseptsioonidest, mudelitest ja teenustest", X.509 "Katalogiteenus: sertifikaadiraamistikud avalikud võtmed ja atribuudid.

Kontrollimise, sertifitseerimise ja auditi protsessid

Kontrollimine, atesteerimine ja audit on lahutamatu osa kvaliteedikontrolli plaan SQAP IEEE 739-1989.
Kontrollimine vastab küsimusele: "Kas me teeme selles etapis seda, mida plaanisime?". Sertifitseerimine ja audit vastab küsimusele: "Kas ehitatav objekt vastab tellija vajadustele?".
IEEE 1012-1986 tarkvara verifitseerimis- ja valideerimisplaani (SVVP) standard ühendab valideerimis- ja auditiprotsessid, mida nimetatakse valideerimiseks, ning määratleb nende teostamise.

Kinnitusprotsessi käigus kontrollitakse järgmisi tingimusi:

• süsteeminõuete järjepidevus ja kasutajate vajaduste arvessevõtmise määr;
• tarnija suutlikkus täita kindlaksmääratud nõudeid;
• PS elutsükli valitud protsesside vastavus lepingutingimustele;
• standardite, protseduuride ja arenduskeskkonna adekvaatsus PS elutsükli protsesside jaoks;
• alajaama projekteerimistingimuste vastavus määratud nõuetele;
• kirjelduse õigsus sisend- ja väljundandmetees, sündmuste järjestus, liidesed, loogika jne;
• koodeksi vastavus projekteerimise spetsifikatsioonidele ja nõuetele;
• koodi testitavus ja korrektsus, vastavus aktsepteeritud kodeerimisstandarditele;
• PS komponentide süsteemi integreerimise õigsus;
• dokumentatsiooni piisavus, täielikkus ja järjepidevus.

Ühine läbivaatamise protsess

Ühine läbivaatamise protsess on mõeldud projektitöö seisu hindamiseks ja keskendub peamiselt projekti ressursside, personali, seadmete ja tööriistade kontrolli planeerimisele ja juhtimisele.
Hindamist rakendatakse nii projektijuhtimise kui ka projekti tehnilise elluviimise käigus ning see viiakse läbi kogu lepingu kehtivusaja jooksul. See protsess saab täita mis tahes kaks lepinguosalist, kusjuures üks pool kontrollib teist.

Probleemi lahendamise protsess

Probleemi lahendamise protsess näeb ette probleemide (sealhulgas tuvastatud mittevastavuste) analüüsi ja lahendamise, olenemata nende päritolust või allikast, mis avastatakse arenduse, käitamise, hoolduse või muude protsesside käigus. Probleemi lahendamise protsess on tihedalt seotud riskijuhtimisega. Projekti ebaõnnestumist põhjustavad tegurid avalduvad riskidena. Riskijuhtimine koosneb tuvastamisest, likvideerimise planeerimisest, prioriteetide seadmisest, kõrvaldamisest (või leevendamisest).

Riskide ilmnemise põhjused võivad olla järgmised:

1. nõuete ebamäärane ja/või mittetäielik sõnastus;
2. Sidusrühmade ebapiisav kaasamine projekti;
3. Halb planeerimine – kompetentse projektijuhtimise puudumine;
4. Nõuete sagedased muutused, mis on põhjustatud ulatuse, projekti eesmärkide ja muude põhjuste muutumisest;
5. kasutatud projekteerimistehnoloogia ebatäiuslikkus;
6. Esinejate teadmiste või oskuste puudumine.

Riskide ennetamiseks on kaks võimalust:

1. projekti nõuetes muudatuste tegemine, riski põhjuse kõrvaldamine;
2. tehnoloogia areng, probleemi lahendamine seotud riski esinemisega.

Projekti juhtimise käigus peaks juht aeg-ajalt algatama riskide tuvastamise protsessi projekti erinevates osades, et koostada ravi ootavate riskide nimekiri. Iga riski jaoks määratakse kolm väärtust: riski realiseerumise tõenäosus; selle riskiga projektile selle elluviimisel tekitatud kahju; riski kõrvaldamise kulude hindamine. Kõigi väärtuste puhul kasutatakse ühte skaalat, näiteks 1–10.

Dokumentatsiooni ja konfiguratsiooni haldamise protsess

“Tarkvaraprojekti dokumentatsioonihaldus nõuab märkimisväärset organisatsioonilist pingutust, sest dokumentatsioon on keeruline süsteem alluvad pidevatele muutustele, mida saavad korraga teha paljud inimesed" (E. Braude)

Dokumenteerimisprotsess näeb ette vormistatud teabe kirjeldus loodud PS elutsükli jooksul. See protsess koosneb tegevuste kogumist, mille käigus nad kavandavad, kujundavad, arendavad, väljastavad, redigeerivad, levitavad ja hooldavad dokumente, mis on vajalikud kõigile huvitatud osapooltele (juhtidele, tehnilised spetsialistid ja süsteemi kasutajad).

GOST R ISO/IEC 9294-93. "Infotehnoloogia. Tarkvara dokumentatsiooni haldamise juhend" kehtestab juhised hea valitsemistava PS dokumentatsioon. Standardi eesmärk on aidata OS-i dokumenteerimise strateegia määratlemisel; dokumentatsiooni standardite valik; dokumenteerimisprotseduuride valik; vajalike ressursside määramine; dokumentatsiooniplaanide koostamine.

Dokumentatsiooni haldamine hõlmab selle täielikku ja järjepidevat hoidmist (mõned autorid lisavad siia konfiguratsioonihalduse).

Dokumentatsiooni täielikkus mida iseloomustab standardite ja regulatiivsete dokumentide arv, mis moodustasid PS-i elutsükli ühe või teise protsessiga kaasneva dokumentatsiooni kogumi aluse.
Dokumentatsiooni järjepidevus tähendab, et dokumentide kogumil ei ole sisemisi ebakõlasid. See saavutatakse iga spetsifikatsiooni paigutamisega ainult ühte kohta – sellist dokumentatsiooni nimetatakse holistiliseks. Dokumentatsiooni terviklikkus tagatakse hüperlinkide kasutamisega.

Iga nõue peab olema jälgitav, selleks antakse igale nõudele kordumatu number, millele viidatakse kontseptsiooni väljatöötamise, kavandamise ja kuni meetodite loendi koostamisel.

• // nõue 4.3
• // autor
• // versioon
• // argumendid
• …meetodite loend…

Projekti osad ei sisalda mitte ainult programmide lähtekoodi, vaid ka kogu dokumentatsiooni, sealhulgas projektiplaani. Projektide eluea jooksul toimuvad muutused kahes suunas:

• Esiteks on see uute osade omandamine,
• Teiseks olemasolevate osade uute versioonide hankimine. Nende muudatuste korrektseks jälgimiseks kasutatakse spetsiaalselt organiseeritud haldus- ja tehniliste protseduuride komplekti, mis on seotuda.

Projekti osade jälgimiseks peate määratlema nende piirid ja tõstma esile konfiguratsioonielemendid (Configuration Items – CI-d). Konfiguratsioonielemendid võivad olla klassid, harvem funktsioonid, olulised andmekogumid – globaalsed tabelid, dokumentatsioon. Konfiguratsiooni oleku arvestamine toimub PS-i komponentide oleku registreerimisega, PS-komponentide versioonide kõigi rakendatud ja tagasilükatud muudatuste aruannete koostamisega. Aruannete kogum annab ühemõttelise ülevaate süsteemi ja selle komponentide hetkeseisust ning säilitab muudatuste ajaloo.
Konfiguratsioonihalduseks on spetsiaalsed tarkvaratööriistad (näiteks Microsoft Visual SourceSafe, Microsoft Visual Studio Team Foundation Server, IBM Rational ClearCase, Subversion jne).

Tavaliselt vastavad konfiguratsioonihaldussüsteemid järgmistele miinimumnõuetele:

• konfiguratsioonielementide määratlemise oskus;
• iga süsteemi arendamise käigus loodud või muudetud objekti versioonide täielike kronoloogiate säilitamine konfiguratsioonihalduse andmebaasis (nende hulka kuuluvad lähtekood, teegid, käivitatavad programmid, mudelid, dokumentatsioon, testid, veebilehed ja kataloogid);
• geograafiliselt hajutatud arendusmeeskondade toetamine;
• muutmisõiguse keelamine, et takistada rohkem kui ühel konfiguratsioonielemendil korraga töötamist;
• kõikidel süsteemi objektidel tehtud muudatuste kontroll;
• tarkvaraversioonide kokkupanek projekti komponentidest.

IEEE töötas välja IEEE 828-1990 standardi"Tarkvara konfiguratsiooni haldusplaan (SCMP)". Standardi pealkiri ja konfiguratsioonihaldusplaani koostamise näide on toodud Eric Braude raamatus.

Joonis - Elutsükli abiprotsesside normdokumendid

Organisatsiooni elutsükli protsessid

Elutsükli organisatsiooniliste protsesside hulka kuuluvad: infrastruktuuri loomise protsess, täiustamise protsess, õppimisprotsess, juhtimisprotsess.

Joonis - Elutsükli organisatsiooniliste protsesside struktuur

Infrastruktuuri protsess

on infrastruktuuri loomise ja pakkumise (hoolduse) protsess, mis võib sisaldada riist- ja tarkvara, tööriistu, metoodikat, standardeid ja arendus-, käitamis- või hooldustingimusi. Infrastruktuuri loomise 1. etapis valitakse projekteerimise toeks CASE-süsteem, programmeerimiskeel, DBMS; tugiteenuse korraldamine - süsteemiadministraatorid, võrguadministraatorid, andmebaasiadministraatorid, sekretärid jne.
Valikuprobleemi lahendamisel kirjandusallikate abil on vaja klassifikatsiooni koostamiseks analüüsida enamlevinud instrumentaalsüsteemide võimalusi ning seejärel teatud klassifikatsioonirühma piires määrata parameetrid, mille järgi valik tehakse.
Tegelik valikuprotseduur sisaldab järgmisi samme:

1. Selgitatakse välja valitud süsteemi põhinäitajad, mis on antud ASOIU projekteerimisel olulised, võttes arvesse selle iseärasusi, piiranguid, ressursse jne.
2. Kõik näitajad on kokku võetud tabelis (vt tabel 5), milles eksperthinnangute põhjal on igale näitajale määratud kaalukoefitsient Vi (näiteks 1-10), mis iseloomustab selle näitaja olulisust teistega võrreldes. . Kõigi kaalutegurite väärtuste summa peab olema võrdne kaaluteguri ülempiiriga (näiteks 10).
3. Kasutades kirjandusallikatest ja/või ekspertidelt saadud andmeid, määratakse iga j-nda süsteemi iga i-nda näitaja jaoks kindlaks kasulikkuse aste Ui,j (alates 1 - miinimum, kuni 10 - maksimaalne). Näiteks võib suhteliselt kalli konfiguratsioonihaldussüsteemi utiliit olla 1, vabavarasüsteemi utiliit aga 10.
4. Iga j-nda võrreldava süsteemi jaoks arvutatakse hindamisfunktsiooni väärtus valemiga: Fj = V1 x U1,j + V2 x U2,j + …=Σ Vi x Ui,j
5. Hindamisfunktsiooni väärtuse põhjal tehakse järeldus konkreetse süsteemi kasutamise otstarbekuse kohta selles projektis, võttes arvesse valitud kriteeriume ja täpsustatud piiranguid. Võrreldavate alternatiivide hulgast valides on parim süsteem, mille puhul hindamisfunktsiooni väärtus osutub suuremaks.

Õppimisprotsess

on töötajatele esmase ja jätkukoolituse pakkumine. Tarkvaratoodete tellimine, tarnimine, arendamine, käitamine ja hooldus sõltuvad suuresti personali kvalifikatsioonist. Seetõttu tuleb personali koolitus eelnevalt planeerida ja läbi viia, et valmistada neid ette tööks tarkvaraprojekti tellimisel, tarnimisel, arendusel, käitamisel või hooldamisel.

Parandusprotsess

on mis tahes tarkvara elutsükli protsessi loomise, hindamise, mõõtmise, kontrollimise ja täiustamise protsess. Inseneripraktikas kasutatakse IS-i väljatöötamisel mõõdikuid - mõne näitaja kvantitatiivseid omadusi.

Kõige sagedamini kasutatavad mõõdikud on:

• tehtud töö maht, mõõdetuna füüsilistes ühikutes (näiteks koodiridade arv);
• tööle kulutatud aeg;
• defekti aste (näiteks defektide arv 1000 koodirea kohta, defektide arv dokumentatsiooni lehel jne).

Esialgsed või soovitud meetrilised väärtused ennustatakse eelnevalt ja võrreldakse saadud tulemustega.
Kuna defektidega seotud mõõdikud mängivad erilist rolli, loetleme neist mõned:

1. 12 nädala jooksul pärast projekti tarnimist leitud defektide arv tuhande koodirea kohta.
2. Ajakava kõrvalekalded igas faasis: (tegelik kestus – planeeritud kestus) / planeeritud kestus.
3. Kulude erinevused: (tegelik kulu – planeeritud kulu) / planeeritud kulu.
4. Projekteerimise koguaeg / Programmeerimise koguaeg (mõnede hinnangute kohaselt peaks see olema vähemalt 50%).
5. Defektide esinemise ja avastamise määr mingil etapil on üks lihtsamaid mõõdikuid.

Defektide tuvastamise tulemuste võrdlemisel organisatsiooni normidega hinnatakse kogu süsteemi loomise protsessi tervikuna, mitte ainult konkreetset projekti. Kogunenud andmed defektide kohta igas etapis on esitatud tabelina, nagu on näidatud näiteks tabelis.

Defektide avastamise etapid (selles projektis / normis)	Defekte sisaldavad etapid
	Nõuete kujundamine	Tehniline ülesanne	Eelprojekt
Nõuete kujundamine	2/5
Tehniline ülesanne	0,5/1,5	3/1
Eelprojekt	0,1/0,3	1/3	2/2

Etapi "Nõude kujundamine" analüüs näitab, et defektide avastamise määr on projekti kõikides etappides normist väiksem. Rohkem disainivigu leiti vahetult nende valmistamise faasis ja vähem defekte leiti hilisemates faasides. Tavaliselt saavutatakse see kontrollimise teel.

Toimingute jada, mida tuleb kogu projekti elutsükli jooksul teha, et seda parandada, võib näiteks olla järgmine:

1. Tuvastage ja määratlege mõõdikud, mida meeskond igas etapis kasutab, sealhulgas:
   • uurimistööle, rakendamisele ja tulemuste analüüsile kulutatud aeg;
   • suurus (näiteks koodiridade arv);
   • moodulis leitud defektide arv (näiteks koodiridade arv) ja defekti tuvastamise allikas;
   • kvaliteedihinnang skaalal 1-10.
2. Dokumenteerige saadud teave SQAP-is.
3. Koguge iga faasi kohta statistikat.
4. Määrake igas etapis andmete kogumise eest vastutavad arendajad, näiteks "vastutab kvaliteedi eest".
5. Planeerige mõõdikute andmete ülevaatamine, mis on tulevikus kasulikud. Eelnevalt on vaja kindlaks määrata, millised mõõdikute väärtused võivad olla ja millised peaksid olema. Saadud andmed on aluseks ettevõtte projektide andmebaasi loomisele.

Organisatsiooni võimekuse küpsuse mudel

Tarkvaraarenduse tehnoloogia täiustamise protsess kajastub organisatsiooni strateegilistes plaanides, selle struktuuris, kasutatavates tehnoloogiates, üldises sotsiaalses kultuuris ja juhtimissüsteemis.
1990. aastate alguses kujundas Ameerika Tarkvaratehnoloogia Instituut (Tarkvaratehnoloogia Instituut – SEI of Carnegie Mellon University (Pittsburgh, Pennsylvania, USA)) CMM-i organisatsioonide tehnoloogilise küpsuse mudeli (Capability [capability] Maturity [matsharity] Model). Praegu on läänes arendusettevõttel olulisi raskusi tellimuse saamisel, kui see pole CMM-i järgi sertifitseeritud.
SMM on metoodiline materjal, milles määratletakse tarkvara loomise ja hooldamise juhtimissüsteemi moodustamise reeglid ning meetodid tootmiskultuuri järkjärguliseks ja pidevaks täiustamiseks. SMM-i eesmärk on pakkuda arendusorganisatsioonidele vajalikud juhised protsesside kvaliteedi parandamise strateegia valikul, analüüsides nende tehnoloogilise küpsuse astet ja tegureid, mis kõige enam mõjutavad toodete kvaliteeti. Igal CMM-i tasemel kehtestatakse nõuded, mille täitmisel saavutatakse protsesside olulisemate näitajate stabiliseerimine.

Juhtimisprotsess

Projektijuhtimine seisneb tasakaalu saavutamises kulude, võimaluste, kvaliteedi ja ajastuse vahel. Projektijuhtimise protsessiga on seotud mitu aspekti: personalijuhtimine, ajakava koostamine, projekti maksumuse hindamine.

Personali juhtimine

Teadaolevad empiirilised andmed meeskonnaliikmete optimaalse arvu määramiseks.

Joonis – Arendusmeeskonna efektiivsuse sõltuvus selle koosseisust

See sõltuvus toob kaasa vajaduse kasutada hierarhilisi juhtimisstruktuure.

Joonis - Hierarhiline juhtimisstruktuur

Hoolimata asjaolust, et iga töötaja ühenduste arv on rahuldav, ei osale nad probleemi sõnastamisel, mis rikub süsteemianalüüsi üht põhinõuet – arutelust peaks osa võtma võimalikult palju sidusrühmi. probleem.
Alternatiivset skeemi töötajate meeskonna organiseerimiseks nimetatakse "võrdsete meeskonnaks". Sel juhul on kõik meeskonnaliikmed hierarhia samal tasemel ja rollid on nende vahel jaotatud. Pealegi võib rollijaotus teatud aja möödudes muutuda. Suure projekti ühenduste arvu suurendamise probleem lahendatakse sel juhul väliskommunikatsiooni eest vastutava isiku rolli jagamisega.

Kent Backi pakutud ekstreemse programmeerimise kontseptsioonis. rõhk on pandud arendajate ja kliendi vahelisele pidevale suhtele (pealegi tehakse klient arenduses üheks osalejaks), süsteemi arendusprotsessi radikaalse lihtsustamise soovile ja paarisprogrammeerimisele. Veelgi enam, paarisprogrammeerimisega töötavad arendajad kordamööda ainult ühes arvutis koos. Seega realiseeritakse pideva kontrolli vorm.

Ajakava koostamine

Tarkvaraprojektide juhtimisplaanide loomist ja hooldamist kirjeldavad paljud standardid. Soovitatav on kasutada IEEE 1058.1-1987 tarkvaraprojekti haldusplaani (SPMP) standardit. SPMP pakub ajakava, mis määrab, kuidas ja millal projekti erinevad etapid tuleb lõpetada. Projekteerimise iga järgneva etapi lõpus tuleb ajakava täiendada ja kohandada. Projekti ajakava kõige levinum esitusviis on Gantti diagramm.

Joonis – Gantti diagrammi ligikaudne vaade

Soovitatav on, et plaan sisaldaks puhverperioode, mil ühtegi protsessi ei käitata. Gantti diagrammi kujul olev ajakava on enamikul juhtudel koostatud Microsoft Office Projecti abil.
Eelkõige projekti elluviimise ja projektijuhtimise planeerimise protsess on seotud projekti maksumuse ja kestuse hindamisega. See teave on esitatud jaotises 5.4. SPMP “eelarve ja ressursside jaotus” ning lisaks projekti esialgne kuluprognoos võivad mõjutada kliendi ja töövõtja vahelise lepingu lõplikku versiooni ning seetõttu tuleks need läbi viia enne TOR-i allkirjastamist.

PS-i loomise kulude hindamine

Keerukuse hindamise protsess algab reeglina samaaegselt projekti algusega ja jätkub isegi programmikoodi kirjutamise etapis.

Kõige tavalisemate töömahukuse hindamise meetodite hulgas eristatakse järgmist:

• Algoritmiline modelleerimine. Meetod põhineb varem lõpetatud projektide statistiliste andmete analüüsil, samas määratakse projekti keerukuse sõltuvus mõnest tarkvaratoote kvantitatiivsest näitajast (tavaliselt programmikoodi suurusest). See näitaja on selle projekti jaoks hinnanguline, mille järel mudel prognoosib tulevasi kulusid.
• Eksperthinnangud. Küsitlus viiakse läbi mitmete tarkvaraarendustehnoloogia ekspertide seas, kes teavad loodava tarkvaratoote ulatust. Igaüks neist annab projekti keerukuse kohta oma hinnangu. Seejärel võrreldakse kõiki hindeid ja arutatakse läbi.
• Hindamine analoogia alusel. Seda meetodit kasutatakse juhul, kui loodava tarkvara antud rakendusvaldkonnas on sarnaseid projekte juba ellu viidud. Meetod põhineb kavandatud projekti võrdlemisel varasemate sarnaste omadustega projektidega. See kasutab ekspertandmeid või salvestatud projektiandmeid. Eksperdid arvutavad uute ja eelmiste projektide erinevuste põhjal välja suure, madala ja kõige tõenäolisema hinnangulise jõupingutuse.

Igal hindamismeetodil on nõrkused ja tugevused Seetõttu kasutatakse praegu erinevaid meetodeid kombineerivaid lähenemisviise.

Tarkvaraarenduse keerukuse hindamise protseduur koosneb järgmistest etappidest:

1. väljatöötatava toote suuruse hinnang;
2. töömahukuse hindamine inimkuudes või inimtundides;
3. projekti kestuse kalkulatsioon kalendrikuudes;
4. projekti maksumuse kalkulatsioon.

Tarkvara suuruse mõõtmise peamised ühikud on:

• koodiridade arv (LOC - Lines of Code);
• funktsionaalsed punktid (FP – Function Points).

Funktsionaalse suuruse hindamise metoodika

Funktsionaalse suuruse hindamise metoodika (FP – funktsionaalsed punktid) on mõõta ühtlaselt kõiki rakenduse võimalusi ja väljendada rakenduse suurust ühe numbrina. Seda numbrit saab seejärel kasutada projekti koodiridade arvu, maksumuse ja ajakava hindamiseks.
Funktsionaalse suuruse arvutamiseks määratakse iga süsteemile iseloomuliku teabe jaoks auaste ja keerukus. Rahvusvaheline funktsioonipunktide kasutajate rühm (IFPUG - International Function Point Users Group, www.ifpug.org) on ​​avaldanud kriteeriumid, mille järgi tuleks eristada teabe tunnuseid, mis jagunevad viide rühma:

• – kasutaja poolt äratuntav loogiliselt seotud andmete rühm, mis asub rakenduses ja mida edastatakse väliste sisendite kaudu.

• – kasutaja poolt äratuntav loogiliselt seotud andmete rühm, mida hostib ja hooldab mõni muu rakendus. Selle rakenduse väline fail on sisemine loogiline fail teises rakenduses.

• - elementaarne protsess, mis viib andmed väliskeskkonnast rakendusse. Andmed võivad pärineda sidekanalitest, kasutajalt sisendekraanil või mõnest muust rakendusest. Andmeid saab kasutada sisemiste loogiliste failide värskendamiseks ja need võivad sisaldada nii juhtimis- kui ka äriteavet. Juhtandmed ei tohi muuta sisemist loogilist faili (nt andmesisestusväljad, veateated, arvutatud väärtused, nupud).

• on elementaarne protsess, mis liigutab rakenduses arvutatud andmed väliskeskkond. Lisaks võidakse selle protsessi käigus värskendada sisemisi loogilisi faile. Andmed loovad aruandeid või väljundfaile, mis saadetakse teistele rakendustele. Aruanded ja failid genereeritakse sisemistest loogikafailidest ja välistest liidesefailidest. Lisaks võib see protsess kasutada sisendandmeid, mis on moodustatud otsingukriteeriumide ja parameetritega, mida sisemised loogilised failid ei toeta. Sisendandmed tulevad väljast, kuid on ajutised ega salvestata sisemisse loogilisse faili (nt andmeväljad aruannetes, arvutatud väärtused, veateated).

• – elementaarprotsess, mis töötab nii sisend- kui ka väljundandmetega, mis koosneb päringu-vastuse kombinatsioonist, kuid ei ole seotud tuletatud andmete arvutamise ega ILF-i uuendamisega. Selle tulemuseks on sisemistest loogikafailidest ja välistest liidesefailidest tagastatud andmed. Protsessi sisendosa ei muuda sisemisi loogilisi faile ja väljundosa ei kanna rakenduse arvutatud andmeid (see on päringu ja väljundi erinevus). Näiteks: sisestuselemendid - otsimiseks kasutatav väli, hiireklõps; väljundelemendid - ekraanil kuvatavad väljad.

Barõšnikova Marina Jurjevna
MSTU im. N.E. Bauman
Osakond PS-7

3. loeng

Tarkvara elutsükkel
kindlustama

Tarkvara elutsükkel

on ajavahemik, mis algab
otsuse tegemise aeg
vajadus luua tarkvara
turvalisus ja lõpeb hetkel
selle täielik kasutusest kõrvaldamine
(IEEE Std. 610.12 – 19990 Standardne tarkvarasõnastik
inseneriterminoloogia)

Peamised elutsükli määratlemisega seotud mõisted

Artefaktid – inimese loodud teave
üksused on dokumendid üsna üldises tähenduses
osalemine sisendina ja tulemuseks
erinevate tegevuste tulemustena.
Roll – abstraktne sidusrühmade rühm,
kaasatud loomisesse ja toimimisse
süsteemid, mis lahendavad samu probleeme või millel on samad
ja samad huvid tema vastu
Tarkvaratoode on arvutiprogrammide kogum
protseduurid ja võimalikud seotud dokumendid ning
andmeid
Protsess on omavahel seotud tegevuste kogum
mõne sisendi teisendamine väljundiks

Tarkvara elutsükkel vastavalt standardile ISO/IEC 12207: 1995
"Rahvusvaheline tehnoloogia – tarkvara elutsükli protsessid"
(GOST ISO IEC 12207-99 Infotehnoloogia.
Tarkvara elutsükkel)
Eluring
Organisatsiooniline
protsessid
Kontroll
projekt
Loomine
infrastruktuuri
Hindamine ja täiustamine
eluring
Haridus
Peamine
protsessid
Omandamine
Abistav
protsessid
Dokumentatsioon
Pakkumine
Kontroll
konfiguratsiooni
Areng
Turvalisus
kvaliteet
Ärakasutamine
Kontrollimine
Saatja
Sertifitseerimine
liigend
hinne
Audit
Luba
probleeme

Tarkvara hankimise protsess
Määratleb tarkvara ostva kliendi toimingud
tarkvaraga seotud tarkvara või teenused lepingu alusel
suhted
Selle protsessi käigus teeb klient järgmist
toimingud:
teadlikkus oma vajadustest tarkvarasüsteemis ja
ostuotsuse tegemine, arendus tellimisel
või olemasoleva süsteemi parandused;
kohta nõudeid sisaldavate taotlusettepanekute koostamine
süsteem, selle töötingimused ja tehnilised
piirangud, aga ka muud lepingutingimused
Omandamine - süsteemi hankimise protsess,
tarkvaratoode või tarkvarateenus

Tarneprotsess
Määratleb teenusepakkuja organisatsiooni tegevused
seoses kliendi pakkumistega
Protsess sisaldab:
tellija taotlusettepanekute läbivaatamine ja nende tegemine
nende kohandused (vajadusel);
lepingu koostamine kliendiga;
tööde teostamise planeerimine (töö võib
teostatakse iseseisvalt või alltöövõtja kaasamisel);
arengut organisatsiooniline struktuur projekt, tehniline
nõuded arengukeskkonnale ja ressurssidele, meetmed selleks
projektijuhtimine jne.
Protsesside läbiviimise eest vastutab tarneprotsess
arendamine, kasutamine ja (või) hooldus

Arendusprotsess

Määrab toimingud, mida arendaja peab tegema
tarkvara loomise protsess ja selle
komponendid vastavalt kindlaksmääratud nõuetele
See protsess hõlmab muu hulgas järgmist:
disain ja töökorras
dokumentatsioon;
taatlemiseks vajalike materjalide ettevalmistamine
tarkvaratoote ja selle toimivus
vastavus kvaliteedistandarditele;
materjalide väljatöötamine (metoodilised ja õppematerjalid),
vajalik personali koolitamiseks ja koolitamiseks ning
jne.

Arendusprotsess

Elutsükli mudeli valimine
Süsteeminõuete analüüs
Süsteemiarhitektuuri projekteerimine
Tarkvaranõuete analüüs
Üksikasjalik tarkvaratehnika
Tarkvara kodeerimine ja testimine
Tarkvara integreerimine
Tarkvara kvalifikatsiooni testimine
Süsteemi integreerimine
Süsteemi kvalifikatsiooni testimine
Tarkvara installimine
Tarkvara aktsepteerimine

10. Süsteeminõuete analüüs

Selles etapis võetakse arvesse süsteemi ulatust.
Väljatöötatud süsteemi nõuete loend peaks sisaldama:
tingimuste kogum, mille korral see kavatsetakse töötada
tulevane süsteem (riist- ja tarkvararessursid,
süsteemile antud; selle toimimise välistingimused;
inimeste koosseis ja sellega seotud teosed);
süsteemi poolt täidetavate funktsioonide kirjeldus;
piirangud arendusprotsessis (juhised valmimise tähtajad
üksikud etapid, olemasolevad ressursid, organisatsioonilised protseduurid
ja meetmed teabe kaitse tagamiseks jne)
Süsteeminõudeid hinnatakse kriteeriumide alusel
teostatavus ja kontrollitavus katsetamise ajal

11. Tarkvaranõuete analüüs

Eeldab järgmise definitsiooni
iga tarkvarakomponendi omadused:
funktsionaalsus, sealhulgas
jõudlus- ja keskkonnaomadused
komponendi toimimine
välised liidesed
töökindluse ja ohutuse spetsifikatsioonid;
ergonoomilised nõuded
nõuded kasutatavatele andmetele
paigaldus- ja vastuvõtunõuded
nõuded kasutaja dokumentatsioonile
kasutus- ja hooldusnõuded

12. Tarkvaraarhitektuuri projekteerimine

Tarkvara arhitektuur
on tarkvara alamsüsteemide ja komponentide kirjeldus
süsteemid ja nendevahelised seosed.
Igaühe arhitektuuriprojekti osana
Tarkvarakomponent täidab järgmisi ülesandeid:
struktuuri abstraktsiooni kõrgetasemeline määratlus
tarkvara ja selle komponentide koostis
tarkvara arendamine ja dokumenteerimine
tarkvara ja andmebaasi liidesed
tava esialgse versiooni väljatöötamine
dokumentatsioon
eeltöö väljatöötamine ja dokumenteerimine
testimisnõuded ja tarkvara integreerimise plaan

13. Tarkvara detailplaneering (tarkvaraarenduse tööplaan)

Sisaldab järgmisi ülesandeid:
tarkvara komponentide ja liideste kirjeldus
neid nende jaoks piisavas koguses
järgnev isekodeerimine ja
testimine
detailide väljatöötamine ja dokumenteerimine
andmebaasi projekt
kasutaja dokumentatsiooni värskendus
kohta nõuete väljatöötamine ja dokumenteerimine
testid ja tarkvarakomponentide testimise plaan

14. Kodeerimine ja tarkvara testimine hõlmab järgmiste ülesannete lahendamist:

arendus (kodeerimine) ja dokumentatsioon
iga tarkvara ja andmebaasi komponent ning
katseprotseduuride ja andmete kogum
testimine
iga tarkvarakomponendi ja baasi testimine
andmed nõuete täitmiseks
nõuded
kasutaja värskendamine (vajadusel).
dokumentatsioon
tarkvara integratsiooniplaani värskendus

15. Süsteemi integreerimine

on kõik kokku panna
komponendid, sealhulgas tarkvara ja
seadmed ja testimine
agregeeritud komponendid
Samuti integratsiooniprotsess
kogu komplekti registreerimine ja kontrollimine
süsteemi dokumentatsioon

16. Tarkvara kvalifikatsiooni testimine

teostab arendaja juuresolekul
kliendile näidata, et tarkvara
vastab selle spetsifikatsioonidele ja
tingimustes kasutamiseks valmis
ärakasutamine
Samuti kontrollib see täielikkust
tehniline ja kasutaja dokumentatsioon ning
selle sobivust tarkvarakomponentidele

17. Tarkvara installeerimine ja vastuvõtmine

Tarkvara installi viib läbi arendaja
vastavalt plaanile selles keskkonnas ja sellel
lepingus ettenähtud varustus. AT
installiprotsess kontrollib funktsionaalsust
Tarkvara ja andmebaasid
Tarkvara aktsepteerimine näeb ette tulemuste hindamise
süsteemi kvalifikatsiooni testimine ja
hindamistulemuste dokumenteerimine, mis
mille toodab arendaja abiga klient.
Arendaja teostab tarkvara lõpliku ülekandmise
kliendile vastavalt lepingule, sätestades
koos vajaliku koolituse ja toega

18. Tarkvara kasutamine

Süsteem töötab sisse
selleks mõeldud keskkond
kombe kohaselt
dokumentatsioon
Sisaldab seadistust
tööstandardid ja
töökorras
testimine

19. Tarkvara hooldus (vastavalt IEEE-90 standardile)

parandamiseks tarkvaras muudatuste tegemine
vead, jõudluse täiustused või
kohanemine muutuvate töötingimustega
või nõuded
Eskortteenuse funktsioonid:
probleemide ja tarkvara muutmise taotluste analüüs
tarkvara toote muutmine
selle kontrollimine ja vastuvõtmine
tarkvara teisaldamine teise keskkonda
tarkvara dekomisjoneerimine

20. Tarkvara elutsükli abiprotsessid

Dokumentatsioon
Konfiguratsiooni juhtimine
Kvaliteedi tagamine
Kontrollimine
Sertifitseerimine
Ühine hindamine
Audit
Probleemi lahendamine

21. Dokumenteerimisprotsess

Dokumentatsioon – vormistatud kirjeldus
kogu genereeritud teave
tarkvara elutsükkel
See on tegevuste kogum, mis
planeerida, kujundada, arendada,
toota, redigeerida, levitada ja
kaasas kõigile nõutavad dokumendid
arendusse kaasatud sidusrühmad
Tarkvara, samuti süsteemi kasutajatele

22. Konfiguratsioonihaldus

Tarkvara konfiguratsioon on
selle funktsionaalne ja füüsiline tervik
tehnilises osas kehtestatud omadused
dokumenteerida ja programmidesse rakendada
Protsess võimaldab teil süstemaatiliselt korraldada
muudatusi arvesse võtma ja kontrollima
Tarkvara elutsükli kõigil etappidel
Kajastatakse konfiguratsioonihalduse üldpõhimõtteid ja soovitusi
standardis ISO/IEC CD 12207 – 2:1995 „Infotehnoloogia – tarkvara
tsükli protsessid. 2. osa. Tarkvara konfiguratsioonihaldus”

23. Kvaliteedi tagamise protsess

Annab kindluse, et tarkvaratoode ja
selle elutsükli protsessid vastavad etteantule
nõuetele, samuti välja töötatud ja heaks kiidetud
tööplaanid
Kvaliteet on omaduste kogum, mis iseloomustab
tarkvara kohtumisvõime
kõigi huviliste nõuded ja vajadused
peod
Protsess on kavandatud vastavuse tagamiseks
elutsükli protsessid, arenduskeskkond ja
personali kvalifikatsioon kehtestatud lepingu tingimuste kohaselt
standardid ja protseduurid. Selleks peab olema
toote kvaliteet, protsessi kvaliteet ja muu
süsteemi kvaliteedinäitajad

24. Kontrollimine

See on protsess, mille käigus tehakse kindlaks, kas praegune arenguseisund vastab,
selles etapis saavutatud, selle etapi nõuded. Selle protsessi käigus
Kontrollimine kontrollib järgmisi tingimusi:
süsteeminõuete järjepidevus ja vajaduste arvessevõtmise määr
kasutaja
tarnija suutlikkust täita kindlaksmääratud nõudeid
valitud tarkvara elutsükli protsesside vastavus lepingutingimustele
standardite, protseduuride ja arenduskeskkonna adekvaatsus tarkvara elutsükli protsesside jaoks
pvastavus kindlaksmääratud nõuetele
sisendi ja väljundi pkirjelduse õigsust
andmed, sündmuste jada, loogika jne.
koodi vastavus projekti spetsifikatsioonidele ja nõuetele
koodi testitavus ja korrektsus, vastavus aktsepteeritud standarditele
kodeerimine
tarkvarakomponentide korrektne integreerimine süsteemi
dokumentatsiooni piisavus, täielikkus ja järjepidevus
Kinnitamine on võrdlemiseks vajalike toimingute kogum
saadud elutsükli tulemus koos nõutavate omadustega
selle tulemuse jaoks, mida peetakse formaalseks tõendiks
tarkvara korrektsus

25. Sertifitseerimine

sätestab täielikkuse määratluse
kindlaksmääratud nõuete täitmine ja
loodud süsteem või tarkvara
toode nende spetsiifiliseks
funktsionaalne eesmärk
Kontrollimine ja sertifitseerimine – kaks vaadet kvaliteedile:
kui kontrollimisel hinnatakse tarkvara selle loomise järgi,
siis sertifitseerimine kaalub tarkvarasüsteem seisukohast
mida see teeb (st hindab tarkvarasüsteemi võimekust
rahuldada kasutajate funktsionaalseid vajadusi)

26. Tarkvara elutsükli organisatsioonilised protsessid

Kontroll
Infrastruktuuri loomine (infrastruktuur
tarkvaraprojekt sisaldab tehnoloogiat ja
standardid, aga ka riistvara komplekt,
tarkvara ja tööriistad
tarkvara arendamine, kasutamine või hooldus)
parandamine
Koolitus (esmaõpe ja
järgnev püsiv tõus
töötajate kvalifikatsioon, sealhulgas areng
õppematerjalid)

27. ESPD standardite rühmad

Grupi kood
0
1
2
3
4
5
6
7
8
9
Grupi nimi
Üldsätted
Põhistandardid
Arendusdokumentatsiooni eeskirjad
Tootmisdokumentatsiooni vormistamise reeglid
Hooldusdokumentatsiooni reeglid
Operatiivdokumentatsiooni rakendamise reeglid
Programmi dokumentatsiooni käsitlemise reeglid
Reservrühmad
Muud standardid
ESPD standardi tähistus koosneb:
number 19 (määratud ESPD standardite klassile);
üks number (punkti järel), mis näitab standardite klassifikatsioonirühma koodi,
tabelis näidatud;
kahekohaline number (pärast sidekriipsu), mis näitab standardi registreerimise aastat

28. ESPD dokumentide loetelu

GOST 19.001-77 ESPD. Üldsätted
GOST 19.101-77 ESPD. Programmide tüübid ja programmi dokumendid
GOST 19.102-77 ESPD. Arengu etapid
GOST 19.103-77 ESPD. Programmide ja programmidokumentide määramine
GOST 19.104-78 ESPD. Põhilised pealdised
GOST 19.105-78 ESPD. Üldnõuded poliitikadokumentidele
GOST 19.106-78 ESPD. Trükitud kujul tehtud programmidokumentidele esitatavad nõuded
GOST 19.201-78 ESPD. Tehniline ülesanne. Nõuded sisule ja kujundusele
GOST 19.202-78 ESPD. Spetsifikatsioon. Nõuded sisule ja kujundusele
GOST 19.301-79 ESPD. Protseduur ja katsemenetlus
GOST 19.401-78 ESPD. Programmi tekst. Nõuded sisule ja kujundusele
GOST 19.402-78 ESPD. Programmi kirjeldus
GOST 19.404-79 ESPD. Selgitav märkus. Nõuded sisule ja kujundusele
GOST 19.501-78 ESPD. Vorm. Nõuded sisule ja kujundusele
GOST 19.502-78 ESPD. Rakenduse kirjeldus. Nõuded sisule ja kujundusele
GOST 19.503-79 ESPD. Süsteemi programmeerija juhend. sisunõuded ja
registreerimine
GOST 19.504-79 ESPD. Programmeerija juhend
GOST 19.505-79 ESPD. Kasutusjuhend
GOST 19.506-79 ESPD. Keelekirjeldus
GOST 19.508-79 ESPD. Giid hooldus. sisunõuded ja
registreerimine
GOST 19.604-78 ESPD. Teostatud programmidokumentides muudatuste tegemise reeglid
trükitud
GOST 19.701-90 ESPD. Algoritmide, programmide, andmete ja süsteemide skeemid. konventsioonid ja
täitmise reeglid
GOST 19.781-90. Infotöötlussüsteemide pakkumine

29. ESPD standardite kasutamise eelised

ESPD standardid lisavad sujuvamaks muutmise elemendi
tarkvara dokumenteerimise protsess
(PS);
hoolimata komplekti nõuete olemasolust
PS dokumentatsioon, mis on ette nähtud standardites
ESPD, need võimaldavad teil teha täiendavaid tüüpe
dokumendid;
ESPD standardid võimaldavad mobiilset vahetamist
väljakujunenud seisukohtade struktuur ja sisu
nõuetest lähtuvad programmidokumendid
klient ja kasutaja

30. ESPD standardite puudused

orienteerumine ühele, "kaskaad" elumudelile
tarkvara tsükkel;
selgete juhiste puudumine dokumenteerimiseks
tarkvara kvaliteediomadused;
süsteemse seose puudumine teiste olemasolevatega
kodumaiste standardite süsteemid elutsükli ja
toodete dokumenteerimine üldiselt, näiteks ESKD;
hägune lähenemine PS-i kui dokumenteerimisele
kaubanduslikud tooted;
soovituste puudumine PS-i isedokumenteerimiseks,
nt ekraanimenüüde ja veebiabitööriistade kujul
kasutaja ("aitab");
soovituste puudumine koostise, sisu ja kujunduse kohta
dokumendid tarkvara kohta, kokkuleppel
rahvusvaheliste ja piirkondlike standardite soovitused

31. Standard GOST 34.601-90: automatiseeritud süsteemi loomise etapid ja etapid

1.
Nõuete kujundamine AU-le
2.
AS-i kontseptsiooni väljatöötamine
3.
Objekti uurimine
Vajalike uurimistööde tegemine
AÜ kontseptsiooni variantide väljatöötamine ja AU kontseptsiooni variandi valik,
kasutajate nõudmistele vastav
Tehtud töö kohta aruande koostamine
Tehniline ülesanne
4.
Objekti ülevaatus ja AÜ loomise vajaduse põhjendus
AU kasutajanõuete kujundamine
Tööde sooritamise aruande ja ASi arendamise taotluse registreerimine
Arendus ja heakskiit lähteülesanne ASi loomiseks
Eelprojekt
Süsteemi ja selle osade eelprojektlahenduste väljatöötamine

32.

Standard GOST 34.601-90: etapid ja etapid
automatiseeritud süsteemi loomine
5.
Tehniline projekt
6.
töödokumentatsioon
7.
TEJ ja selle osade töödokumentatsiooni väljatöötamine
Programmide väljatöötamine ja kohandamine
Kasutuselevõtt
8.
Süsteemi ja selle osade projekteerimislahenduste väljatöötamine
AU ja selle osade dokumentatsiooni väljatöötamine
Komponentide tarnimise dokumentatsiooni väljatöötamine ja vormistamine
Projekteerimisülesannete väljatöötamine projekti külgnevates osades
Automatiseerimisobjekti ettevalmistamine
Personali koolitus
AU lõpetamine tarnitud toodetega (tarkvara ja riistvara,
tarkvara ja riistvara kompleksid, infotooted)
Ehitus- ja paigaldustööd
Kasutuselevõtutööd
Eelkatsete läbiviimine
Proovioperatsiooni läbiviimine
Vastuvõtutestide läbiviimine
Vahelduvvoolu tugi
Tööde tegemine vastavalt garantiikohustustele
Garantiijärgne teenindus

Disainimetoodika eesmärgid ja eesmärgidPEAL. Peamised disainivaldkonnadPEAL. Loomise etapidPEAL.

Tarkvara (Tarkvara) - intellektuaalne toode, mis ei sõltu keskkonnast, kuhu see on kirjutatud, sealhulgas programmid, reeglid ja seotud andmed, mis arvutiprogrammi täitmisalasse laadimisel tagab selle toimimise.

Tarkvara (Tarkvaratoode) - arvutiprogrammide, protseduuride ja võimalusel ka nendega seotud dokumentatsiooni ja andmete kogum.

Tarkvara (Tarkvaratoode) – mis tahes arvutiprogrammide, protseduuride ja nendega seotud dokumentatsiooni ja andmete kogum, mis tuleneb tarkvaratoodete väljatöötamisest ja on mõeldud kasutajale tarnimiseks [ISO / IEC 12207]. Märge. Tooted hõlmavad vahetooteid ja tooteid, mis on mõeldud kasutajatele, näiteks arendajatele ja hooldajatele.

Tarkvaraarendus (Tarkvaratehnika) Arendusvorm, mis rakendab arvutiteaduse, infotehnoloogia, matemaatika ja rakendusvaldkonna põhimõtteid, et saavutada tarkvara kaudu praktilistele probleemidele kulutõhusaid lahendusi.

Tarkvara disain on tegeliku suuruse ja praktilise väärtusega rakenduste loomise protsess, mis vastavad kindlaksmääratud funktsionaalsus- ja jõudlusnõuetele.

Programmeerimine - see on üks tarkvara arendustsüklis sisalduvatest tegevustest.

Tarkvara arendamise etapid

1. Mõistke kavandatava toote olemust ja ulatust.

2. Valige arendusprotsess ja koostage plaan.

3. Nõude kogumine.

4. Kujundage ja komplekteerige toode.

5. Tehke toote testimine.

6. Vabastage toode ja hooldage seda.

Programmi elutsükli all peame silmas etappide kogumit:

Ainevaldkonna analüüs ja tehniliste kirjelduste loomine (suhtlemine kliendiga)

Programmi struktuuri kujundamine

Kodeerimine (programmikoodi komplekt vastavalt projekti dokumentatsioonile)

Testimine ja silumine

Programmi rakendamine

Programmi tugi

Utiliseerimine

Tarkvara elutsükli (LC) mõiste. Elutsükli määratlus rahvusvahelise standardi ISO/IEC 12207:1995 järgi. Tarkvara elutsükli põhiprotsessid.

Tarkvara elutsükkel on pidev protsess, mis algab hetkest, mil tehakse otsus selle loomise vajaduse kohta ja lõpeb selle täieliku kasutusest kõrvaldamise hetkega.

Tarkvara elutsükkel (LC) on defineeritud kui ajavahemik, mis algab hetkest, mil tehakse otsus tarkvara loomise vajaduse kohta ja lõpeb selle täieliku kasutusest kõrvaldamise hetkel.

Peamine regulatiivne dokument, mis reguleerib tarkvara elutsükli protsesside koostist, on rahvusvaheline standard ISO / IEC 12207: 1995 "Infotehnoloogia - Tarkvara elutsükli protsessid" (ISO - International Organisation for Standardization - International Organisation for Standardization, IEC - International Electrotechnical Commission - International Commission for It määratleb elutsükli struktuuri, mis sisaldab protsesse, tegevusi ja ülesandeid, mida tarkvara arendamise käigus tuleb täita.

Selles standardis Tarkvara (või tarkvaratoode) määratletud kui arvutiprogrammide, protseduuride ja võimalusel seotud dokumentatsiooni ja andmete kogum.

Protsess on määratletud kui omavahel seotud toimingute kogum (vastavalt seotud tegevuste kogum), mis muudavad mõned algandmed (sisendandmed) väljundiks (tulemusteks). Iga protsessi iseloomustavad teatud ülesanded ja meetodid nende lahendamiseks, teistest protsessidest saadud lähteandmed ja tulemused.

Iga protsessi jagatud tegevuste komplektiks, millest igaüks tegevust- komplekti kohta ülesandeid. Iga protsessi, toimingu või ülesande algatab ja teostab teine ​​protsess vastavalt vajadusele ning etteantud täitmisjadasid pole (loomulikult sisendandmeühendusi säilitades).

Peamised elutsükli protsessid :

Tellimus (soetamine);

Tegevus – omandamise algatamine

Tegevus – pakkumiste koostamine

Tegevus - lepingu ettevalmistamine ja kohandamine

Tegevus – Järelevalve tarnija tegevuse üle

Selle protsessi käigus vastuvõtt vajalikud testid valmistatakse ette ja viiakse läbi. Tööde lõpetamine lepingu alusel teostatakse, kui kõik vastuvõtmise tingimused on täidetud

Pakkumine;

Kohaletoimetamise algatamine

Planeerimine

Areng;

Arendusprotsess näeb ette arendaja poolt tehtavad tegevused ja ülesanded ning hõlmab järgmisi tegevusi

Ettevalmistustööd

Süsteeminõuete analüüs

Süsteemiarhitektuuri projekteerimine kõrgel tasemel on määrata kindlaks selle riistvara, tarkvara komponendid ja süsteemi käitavad toimingud. Süsteemi arhitektuur peab vastama süsteemi nõuetele ning aktsepteeritud projekteerimisstandarditele ja tavadele.

Tarkvaranõuete analüüs

Tarkvaraarhitektuuri projekteerimine

Tarkvara kodeerimine ja testimine

Tarkvara integreerimine

Tarkvara kvalifikatsiooni testimine

Süsteemi integreerimine

Tarkvara installimine

Tarkvara aktsepteerimine

ekspluateerimine; hõlmab operaatori – süsteemi haldava organisatsiooni – tegevusi ja ülesandeid ning hõlmab tegevusi:

Ettevalmistustööd sisaldab järgmisi operaatori ülesandeid:

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

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

Töökatsed tehakse tarkvaratoote iga järgmise väljaande jaoks, misjärel see viiakse tööle.

Süsteemi töö

Kasutajatugi

Protsesssaatjad sätestab hooldusteenistuse tegevused ja ülesanded. Vastavalt IEEE-90 standardile all saatja tähendab tarkvara muudatuste tegemist, et parandada vigu, parandada jõudlust või kohaneda muutuvate töötingimuste või nõuetega.

Ettevalmistustööd tugiteenus sisaldab järgmisi ülesandeid:

hoolduse käigus tehtavate toimingute ja tööde planeerimine;

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

Probleemide ja tarkvara muutmise taotluste analüüs

Tarkvara muutmine

Ülevaatus ja vastuvõtmine

Tarkvara kasutusest kõrvaldamine teostatakse kliendi otsusel käitava organisatsiooni, hooldusteenistuse ja kasutajate osalusel. Samas kuuluvad tarkvaratooted ja nendega seotud dokumentatsioon lepingujärgselt arhiveerimisele.

Tarkvara elutsükli (LC) mõiste. Elutsükli määratlus rahvusvahelise standardi ISO/IEC 12207:1995 järgi. Tarkvara elutsükli abiprotsessid.

Vaata punkti 2

Abielutsükli protsessid :

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

Dokumenteerimisprotsess hõlmab järgmisi samme:

ettevalmistustööd;

projekteerimine ja arendus;

dokumentatsiooni väljastamine;

saatja

Konfiguratsiooni juhtimine tema; teha kindlaks tarkvarakomponentide seisukord süsteemis, hallata tarkvara muudatusi, kirjeldada ja koostada aruandeid tarkvara komponentide seisu ja muudatuste taotluste kohta, tagada tarkvara täielikkus, ühilduvus ja korrektsus, hallata tarkvara säilitamist ja tarnimist. Vastavalt IEEE standardile - 90 alla konfiguratsiooni Tarkvara all mõistetakse selle funktsionaalsete ja füüsilised omadused seatud tehnilises dokumentatsioonis ja rakendatud tarkvaras.

ettevalmistustööd

konfiguratsiooni tuvastamine kehtestab reeglid, mille järgi saab tarkvarakomponente ja nende versioone üheselt tuvastada ja eristada

konfiguratsiooni juhtimine loodud kavandatud tarkvaramuudatuste süstemaatiliseks hindamiseks ja nende rakendamise koordineerimiseks, võttes arvesse iga modifikatsiooni tõhusust ja selle rakendamise kulusid

konfiguratsiooni oleku raamatupidamine (esindab tarkvarakomponentide oleku registreerimist, aruannete koostamist kõigi tarkvarakomponentide versioonide rakendatud ja tagasilükatud muudatuste kohta). + muudatuste ajalugu

konfiguratsiooni hindamine (koosneb tarkvarakomponentide funktsionaalse terviklikkuse, samuti nende füüsilise seisukorra vastavuse hindamisest kehtivale tehnilisele kirjeldusele);

väljalaske haldamine ja kohaletoimetamine (hõlmavad programmide ja dokumentatsiooni põhikoopiate valmistamist, nende säilitamist ja kasutajatele kättetoimetamist vastavalt organisatsioonis vastuvõetud korrale).

Kvaliteedi tagamine;

Kvaliteedi tagamise protsess annab asjakohase tagatise, et tarkvara ja selle elutsükli protsessid vastavad kindlaksmääratud nõuetele ja kinnitatud plaanidele. Under tarkvara kvaliteet viitab omaduste kogumile, mis iseloomustavad tarkvara võimet täita kindlaksmääratud nõudeid.

Kvaliteedi tagamise protsess hõlmab järgmisi samme:

ettevalmistustööd

toote kvaliteedi tagamine, tarkvaratoodete ja nende dokumentatsiooni täieliku vastavuse tagamine lepingus sätestatud kliendi nõuetele;

tarkvara elutsükli protsesside, arendusmeetodite, arenduskeskkonna ja töötajate kvalifikatsiooni vastavuse protsessi kvaliteedi tagamine lepingutingimustele, tagades muud süsteemi kvaliteedinäitajad

Kontrollimine; seisneb selle kindlakstegemises, et tarkvaratooted vastavad täielikult eelnevatest tegevustest tulenevatele nõuetele või tingimustele (kontrollimine kitsamas tähenduses tähendab tarkvara õigsuse formaalset tõendamist).

ettevalmistustööd;

kontrollimine;

Kinnitusprotsess kontrollib järgmisi tingimusi:

süsteeminõuete järjepidevus ja kasutajate vajaduste arvessevõtmise määr;

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

valitud tarkvara elutsükli protsesside vastavus lepingutingimustele;

standardite, protseduuride ja arenduskeskkonna adekvaatsus tarkvara elutsükli protsessi jaoks;

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

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

koodeksi vastavus projekteerimise spetsifikatsioonidele ja nõuetele;

koodi testitavus ja korrektsus, vastavus aktsepteeritud kodeerimisstandarditele;

tarkvara komponentide korrektne integreerimine süsteemi;

dokumentatsiooni piisavus, täielikkus ja järjepidevus.

Sertifitseerimine;

sätestab kindlaksmääratud nõuete ja loodud süsteemi või tarkvaratoote lõplikule funktsionaalsele otstarbele vastavuse täielikkuse tuvastamise. Sertifitseerimise all mõistetakse tavaliselt läbitud testi usaldusväärsuse kinnitamist ja hindamist. Sertifitseerimine on soovitatav läbi viia testides kõigis võimalikes olukordades ja kasutades sõltumatuid spetsialiste.

Ühine hindamine(Ühisanalüüs); hinnata projekti ja tarkvaraga seotud töö seisu.

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

Osalushindamise protsess sisaldab järgmisi samme:

ettevalmistustööd;

projektijuhtimise hindamine (analüüs);

tehniline hinnang.

Audit;

lepingu nõuetele, plaanidele ja tingimustele vastavuse kindlaksmääramine. Auditi võivad läbi viia kaks lepinguosalist, kusjuures üks pool kontrollib teist. Audit on audit (kontroll), mille teostab pädev asutus (isik) tagamaks sõltumatu hindamine tarkvara või protsesside vastavus kindlaksmääratud nõuetele.

Luba(Lahendus) probleeme.

näeb ette probleemide (sealhulgas tuvastatud mittevastavuste) analüüsi ja lahendamise, olenemata nende päritolust või allikast, mis avastatakse arenduse, käitamise, hoolduse või muude protsesside käigus. Iga leitud probleem tuleb tuvastada, kirjeldada, analüüsida ja lahendada.

Tarkvara elutsükli (LC) mõiste. Elutsükli määratlus rahvusvahelise standardi ISO/IEC 12207:1995 järgi. Tarkvara elutsükli organisatsioonilised protsessid. Tarkvara elutsükli protsesside vaheline seos.

Vaata punkti 2

Elutsükli organisatsioonilised protsessid :

Kontroll;

koosneb tegevustest üldtööd) ja ülesandeid, mida saab täita iga oma ressursse haldav osapool. See osapool (haldur) vastutab toote väljalaske haldamise, projektijuhtimise ja seotud protsesside, nagu hankimine, tarnimine, arendus, käitamine, hooldus jne, ülesannete haldamise eest. Näiteks vastutab administraator projektijuhtimise, tarnimise, arenduse, käitamise, hoolduse jms eest.

Juhtimisprotsess sisaldab järgmisi samme:

juhtimise ulatuse ettevalmistamine ja määratlemine . Juht peab veenduma, et juhtimiseks vajalikud ressursid (personal, seadmed ja tehnika) oleksid tema käsutuses piisavas koguses;

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

töögraafikute koostamine;

kuluprognoos;

vajalike ressursside eraldamine;

vastutuse jaotus;

konkreetsete ülesannetega seotud riskide hindamine;

juhtimistaristu loomine.

rakendamine ja kontroll;

kontrollimine ja hindamine;

lõpetamine.

Infrastruktuuri loomine;

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

parandamine;

näeb ette tarkvara elutsükli protsesside hindamise, mõõtmise, kontrolli ja täiustamise.

Haridus.

hõlmab esmast koolitust ja järgnevat pidevat personali arendamist.

Tarkvara elutsükli protsesside vaheline seos

Standardis ISO/IEC 12207 määratletud tarkvara elutsükli protsesse saavad erinevad organisatsioonid konkreetsetes projektides kasutada mitmel viisil. Siiski pakub standard erinevatest vaatenurkadest mõningaid põhilisi seoseid protsesside vahel (joonis 1). Need aspektid on:

lepinguline aspekt;

juhtimise aspekt;

toimimise aspekt;

insenertehniline aspekt;

toetuse aspekt.

AT lepinguline aspekt klient ja tarnija sõlmivad lepingulise suhte ning rakendavad vastavalt hanke- ja tarneprotsesse. AT juhtimise aspekt klient, tarnija, arendaja, operaator, hooldaja ja teised tarkvara elutsükliga seotud osapooled juhivad oma protsesside täitmist. AT toimimise aspekt süsteemi operaator osutab kasutajatele vajalikke teenuseid. AT inseneri aspekt arendaja või hooldusteenus lahendab vastavad tehnilised probleemid tarkvaratooteid arendades või muutes. AT toetuse aspekt abiprotsesse rakendavad teenused pakuvad vajalikke teenuseid kõigile teistele töös osalejatele.

Standardis kirjeldatud protsessidevahelised seosed on staatiline iseloom . Tähtsam dünaamilised lingid protsesside vahel ja neid ellu viivad osapooled pannakse paika reaalsetes projektides.

Tarkvara elutsükli mudeli ja etapi kontseptsioon. Tarkvaraarenduse etappide tunnused.

1) Rahvusvaheline standard ISO/ IEC 12207: 1995 Elutsükli mudel on määratletud järgmiselt:

Tarkvara elutsükli mudeli all mõistetakse struktuuri, mis määrab täitmise järjekorra ning protsesside, toimingute, ü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.

2) GOST R ISO/IEC 12207-99 Elutsükli mudel on määratletud järgmiselt:

Elutsükli mudel - protsessidest, tegevustest ja ülesannetest koosnev struktuur, sealhulgas tarkvaratoote arendamine, käitamine ja hooldus, mis hõlmab süsteemi eluiga alates sellele nõuete kehtestamisest kuni kasutamise lõpetamiseni.

Under etapp tarkvara loomist mõistetakse tarkvara loomise protsessi osana, mis on piiratud teatud ajaraamiga ja lõpeb konkreetse toote (tarkvaramudelid, tarkvarakomponendid, dokumentatsioon) väljalaskmisega, mis on määratud selle etapi nõuetega. Tarkvara loomise etapid eristatakse ratsionaalse planeerimise ja töökorralduse kaalutlustel, lõpetades soovitud tulemustega.

Tarkvara elutsükli koostis sisaldab tavaliselt järgmisi jaamu:

Tarkvaranõuete kujundamine.

Disain.

Rakendamine.

Testimine.

Kasutuselevõtt.

Kasutamine ja hooldus.

Dekomisjoneerimine.

Tarkvara elutsükli mudeli kontseptsioon. Tarkvara elutsükli kose (kaskaad) mudel.

Vaata punkti 5

Algselt eksisteerinud homogeenses IS-is oli iga rakendus ühtne tervik. Seda tüüpi rakenduse väljatöötamiseks kasutati kaskaadmeetodit. Selle peamiseks tunnuseks on kogu arenduse jagamine etappideks ning üleminek ühest etapist järgmisse toimub alles pärast seda, kui töö praeguse kallal on täielikult lõpetatud (joonis 2). Iga etapp kulmineerub täieliku dokumentatsiooni väljastamisega, millest piisab arendusmeeskonna poolt järgmises etapis arenduse jätkamiseks.

Kaskaadmeetodi kasutamise eelised :

igas etapis moodustatakse täielik projektdokumentatsiooni komplekt, mis vastab täielikkuse ja järjepidevuse nõuetele;

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

IS-i ehitamisel on end tõestanud kaskaadkäsitlus, millele juba arenduse alguses on võimalik kõik nõuded üsna täpselt ja terviklikult sõnastada, et anda arendajatele vabadus need tehniliselt võimalikult hästi ellu viia.

Samal ajal on sellel lähenemisviisil mitmeid puudusi, mis on tingitud eelkõige sellest, et tarkvara loomise tegelik protsess ei mahu kunagi täielikult nii jäigasse skeemi. Tarkvara arendusprotsess on tavaliselt iteratiivne iseloom : järgmise etapi tulemused põhjustavad sageli muudatusi eelmistes etappides välja töötatud projekteerimisotsustes. Seega on pidev vajadus naasta eelmiste etappide juurde ja eelnevalt tehtud otsuseid täpsustada või üle vaadata. Selle tulemusena omandab tegelik tarkvara loomise protsess teistsuguse kuju (joonis 2).

Märkimisväärne viivitus tulemuste saamisel. Tulemuste kooskõlastamine kasutajatega toimub ainult pärast iga tööetapi lõppu planeeritud punktides, IS-ile esitatavad nõuded on tehnilise ülesande vormis "külmutatud" 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õuded on ebatäpsed või muutuvad pika tarkvaraarenduse perioodi jooksul, jõuavad kasutajad süsteemini, mis ei vasta nende vajadustele. Automatiseeritud objekti mudelid (nii funktsionaalsed kui ka informatiivsed) võivad vananeda samaaegselt nende heakskiitmisega.

Tarkvara elutsükli mudeli kontseptsioon.Kiire rakenduste arendamise mudel. Vaata punkti 5

Üheks võimalikuks lähenemiseks rakendustarkvara arendamiseks spiraalse elutsükli mudeli raames on laialdaselt kasutatav nn kiirrakenduse arendus ehk RAD (Rapid Application Development). RAD-il on kolm komponenti:

väikesed arendajate rühmad (3-7 inimest), kes teostavad töid üksikute tarkvara alamsüsteemide projekteerimisel. See on tingitud meeskonna maksimaalse juhitavuse nõudest;

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

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

Arendusmeeskond peaks koosnema tarkvara kujundamise, programmeerimise ja testimise alal kogenud professionaalidest, kes on suutelised lõppkasutajaga hästi suhtlema ja nende ettepanekud töötavateks prototüüpideks muutma.

Seal on järgmised RAD-i arendusprotsessi etapid :

äri modelleerimine . Modelleeritakse infovooge ärifunktsioonide vahel.

Andmete modelleerimine . Info liikumine kaardistatud andmeobjektide komplektiga.

Töötlemise simulatsioon . Määratletakse andmeobjektide teisendused, mis tagavad ärifunktsioonide rakendamise.

Rakenduste genereerimine . Automatiseerimisutiliidi konstrueerimiseks kasutatakse 4. põlvkonna programmeerimiskeeli, valmiskomponente.

Testimine ja liitmine . Korduvkasutatavate komponentide kasutamine vähendab testimise aega.

Iga põhifunktsiooni arendab eraldi arendajate rühm paralleelselt mitte rohkem kui 3 kuud ja seejärel integreeritakse need kogu süsteemi.

Rakenduse puudused RAD :

Suured projektid nõuavad meeskondade loomiseks märkimisväärseid inimressursse.

Mudel on rakendatav ainult nendele süsteemidele, mida saab laotada eraldi mooduliteks ja milles jõudlus ei ole kriitiline väärtus.

Ei kohaldata kõrgete tehniliste riskide tingimustes, s.t. uue tehnoloogia kasutamisel.

Tarkvara elutsükli mudeli kontseptsioon. V-kujuline tarkvara elutsükli mudel.

V-kujuline elutsükli mudel loodi selleks, et aidata projektimeeskonnal ette planeerida, et nad saaksid süsteemi testida. Selles mudelis pööratakse erilist tähelepanu toote kontrollimisele ja valideerimisele suunatud tegevustele. See näitab, et toote testimist arutatakse, kavandatakse ja kavandatakse arenduse elutsükli alguses.

Kliendi vastuvõtutesti plaan töötatakse välja planeerimise faasis ning süsteemi paigutustest analüüsi, disaini väljatöötamise jms faasides. Seda katseplaani väljatöötamise protsessi tähistab punktiirjoon V-mudeli kastide vahel.

V-kujuline mudel töötati välja kosemudeli variatsioonina, mis tähendab, et see pärandas sellelt sama järjestikuse struktuuri. Iga järgnev faas algab pärast eelmise faasi tulemusandmete hankimise lõpetamist.

Modell demonstreerib Kompleksne lähenemine tarkvara arendusprotsessi faaside määratlemisele. See tõstab esile seosed, mis eksisteerivad analüütiliste etappide ja kodeerimisele eelnevate projekteerimisfaaside vahel, millele järgnevad testimisfaasid. Punktiirjooned tähendavad, et neid faase tuleks käsitleda paralleelselt.

Riis. . Elutsükli V-mudel

Allpool antud Lühike kirjeldus V-mudeli iga faas alates projekti planeerimisest ja nõuetest kuni vastuvõtutestini:

projekti ja nõuete planeerimine - määratakse kindlaks süsteeminõuded, samuti see, kuidas jaotatakse organisatsiooni ressursse seatud nõuete täitmiseks (vajadusel tehakse selles etapis riist- ja tarkvara funktsioonide määratlemine);

tootenõuete ja spetsifikatsioonide analüüs – tarkvara hetkel olemasoleva probleemi analüüs, mis lõpeb loodava tarkvarasüsteemi eeldatava välise käitumise täieliku täpsustusega;

arhitektuur või disain kõrgeimal tasemel – määrab, kuidas tarkvara funktsioone projekti elluviimisel rakendada;

üksikasjalik projektiarendus – määratleb ja dokumenteerib iga arhitektuurifaasis määratletud komponendi algoritmid. Need algoritmid teisendatakse hiljem koodiks;

koodi arendamine – teostatakse detailplaneeringu etapis defineeritud algoritmide teisendamine valmistarkvaraks;

ühiku testimine – iga kodeeritud moodulit kontrollitakse vigade suhtes;

integreerimine ja testimine – seoste loomine eelnevalt testitud moodulite rühmade vahel elementide kaupa, et kinnitada nende rühmade ja elementide testimise etapis üksteisest sõltumatult testitud moodulite toimimist;

süsteemi- ja vastuvõtutestimine – tarkvarasüsteemi kui terviku (täielikult integreeritud süsteemi) toimimist kontrollitakse pärast selle riistvarakeskkonda paigutamist vastavalt tarkvaranõuete spetsifikatsioonile;

tootmine, käitamine ja hooldus - tarkvara käivitatakse tootmisse. See etapp hõlmab ka uuendusi ja muudatusi;

vastuvõtutestid (joonisel pole näidatud) – võimaldab kasutajal testida süsteemi funktsionaalsust vastavuse osas esialgsetele nõuetele. Pärast viimast testimist hakkavad tarkvara ja seda ümbritsev riistvara tööle. Pärast seda on ette nähtud süsteemi hooldus.

eelised:

mudelis pööratakse erilist tähelepanu planeerimisele, mille eesmärk on kontrollida ja sertifitseerida arendatavat toodet selle väljatöötamise varases staadiumis. Üksuse testimise etapp kinnitab üksikasjaliku disaini. Integratsiooni- ja testimisfaasid rakendavad arhitektuurset või tipptasemel disaini. Süsteemi testimise faas kinnitab, et toote ja selle spetsifikatsiooni nõuete faas on õigesti läbitud;

mudel näeb ette kõigi saadud väliste ja sisemiste andmete, mitte ainult tarkvaratoote sertifitseerimise ja kontrollimise;

V-kujulises mudelis tehakse nõuete määratlemine enne süsteemi disaini väljatöötamist ja tarkvara projekteerimine enne komponentide väljatöötamist;

mudel määratleb arendusprotsessi tulemusena saadavad tooted ning iga saadud andmeid tuleb testida;

tänu mudelile saavad projektijuhid jälgida arendusprotsessi edenemist, kuna sel juhul on ajaskaala kasutamine täiesti võimalik ja iga etapi läbimine on verstapost;

mudelit on lihtne kasutada (võrreldes projektiga, mille jaoks see on vastuvõetav).

piirangud:

tema abiga pole lihtne paralleelsete sündmustega toime tulla;

see ei võta arvesse faaside vahelisi iteratsioone;

mudel ei näe ette dünaamiliste muutuste nõude kehtestamist elutsükli erinevatel etappidel;

nõuete testimine elutsüklis toimub liiga hilja, mistõttu ei ole võimalik muudatusi teha ilma projekti ajakava mõjutamata;

mudel ei sisalda riskianalüüsile suunatud tegevusi.

Nende puuduste ületamiseks saab V-kujulist mudelit muuta nii, et see hõlmaks iteratiivseid silmuseid, mille eesmärk on lahendada nõuete muutused pärast analüüsifaasi.

Sarnaselt eelkäijale, kosemudelile, töötab V-kujuline mudel kõige paremini siis, kui kogu teave nõuete kohta on eelnevalt saadaval. V-kujulise mudeli tavaline modifikatsioon selle puuduste ületamiseks hõlmab iteratiivsete tsüklite kasutuselevõttu, et lahendada nõuete muutused pärast analüüsifaasi.

Mudeli kasutamine on efektiivne, kui on olemas informatsioon lahenduse juurutamise meetodi ja tehnoloogia kohta ning töötajatel on selle tehnoloogiaga töötamiseks vajalikud oskused ja kogemused.

V-muster on suurepärane valik kõrget töökindlust nõudvate süsteemide jaoks, näiteks kliinikutes patsientide jälgimise rakendused, aga ka autode hädaolukorra turvapadja juhtimisseadmete sisseehitatud tarkvara.

Tarkvara elutsükli mudeli kontseptsioon. Boehmi tarkvara elutsükli spiraalmudel.

spiraalne mudel - klassikaline näide evolutsioonilise disainistrateegia rakendamisest. Spiraalmudel (autor Barry Boehm, 1988) tugineb klassikalise elutsükli ja paigutuse parimatele omadustele, millele lisandub uus element – ​​riskianalüüs, mida varem ei olnud.

Nagu on näidatud joonisel fig. Nagu on näidatud joonisel 3, määratleb mudel neli tegevust, mida esindavad spiraali neli kvadrandit:

Planeerimine – eesmärkide, valikute ja piirangute määratlemine.

Riskianalüüs - võimaluste analüüs ja riskide tuvastamine/valik.

Tehnika – järgmise taseme tootearendus.

Hindamine – hetkeprojekti tulemuste hindamine tellija poolt.

Spiraali mudeli integreeriv aspekt on ilmne, kui arvestada spiraali radiaalset mõõdet. Iga iteratsiooniga mööda spiraali (keskmest perifeeriasse liikudes) aina rohkem täisversioonid PEAL.

Juhtimisprotsess konfiguratsioon hõlmab haldus- ja tehnilisi protseduure kogu tarkvara elutsükli jooksul, et määrata tarkvarakomponentide olekut, kirjeldada ja aru anda tarkvarakomponentide olekust ja muudatuste taotlustest, tagada tarkvarakomponentide täielikkus, ühilduvus ja õigsus, hallata tarkvara komponentide seisukorda ja tarnimist. tarkvara.

IEEE-90 standardi kohaselt mõistetakse tarkvara konfiguratsiooni all tehnilises dokumentatsioonis kindlaks määratud ja tarkvaras realiseeritud selle funktsionaalsete ja füüsiliste omaduste kogumit. Konfiguratsiooni juhtimine võimaldab korraldada, süstemaatiliselt arvestada ja kontrollida tarkvara muudatusi elutsükli kõigil etappidel. Tarkvara konfiguratsioonihalduse üldpõhimõtted ja soovitused on kajastatud standardis ISO / IEC 15288 "Infotehnoloogia. Tarkvara elutsükli protsess. Tarkvara konfiguratsioonihaldus".

Juhtimisprotsess konfiguratsioon sisaldab järgmist:

1. planeerimise konfiguratsioonihalduse ettevalmistustööd;
2. konfiguratsiooni identifitseerimine, mis kehtestab reeglid, mille järgi tarkvara komponendid ja nende versioonid on üheselt identifitseeritud. Samal ajal vastab dokumentide komplekt igale komponendile unikaalselt;
3. konfiguratsioonikontroll - toiming, mille eesmärk on kavandatud tarkvaramuudatuste süstemaatiline hindamine ja nende rakendamise koordineerimine, võttes arvesse iga modifikatsiooni tõhusust ja selle rakendamise maksumust;
4. konfiguratsiooni oleku arvestamine, mis on tarkvarakomponentide oleku registreerimine. Pakub aruandlust tarkvarakomponentide versioonide rakendatud ja tagasilükatud muudatuste kohta. Aruannete kogum annab ühemõttelise ülevaate süsteemi ja selle komponentide hetkeseisust ning sisaldab ka muudatuste ajalugu;
5. konfiguratsiooni hindamine, mis seisneb määramises funktsionaalne täielikkus tarkvarakomponendid, samuti nende füüsilise seisundi vastavus kehtivale tehnilisele kirjeldusele;
6. väljalasete haldamine ja tarnimine, mis hõlmab programmide ja dokumentatsiooni originaalkoopiate valmistamist, nende säilitamist ja kasutajatele edastamist vastavalt organisatsiooni poolt vastuvõetud korrale.

Varustamise protsess kvaliteedi tagamine peaks tagama, et tarkvara ja selle elutsükli protsessid vastavad kindlaksmääratud nõuetele ja kinnitatud plaanidele. Tarkvara kvaliteedi all mõistetakse omaduste kogumit, mis iseloomustab tarkvara võimet täita kindlaksmääratud nõudeid. Usaldusväärsete hinnangute saamiseks loodava tarkvara kohta tagamise protsess selle kvaliteet peaks olema sõltumatu tarkvaratoote arendamisega otseselt seotud teemadest. Kasutada võib ka muude toetavate protsesside, nagu kontrollimine, atesteerimine, osalushindamine, audit ja probleemide lahendamine, tulemusi.

Varustamise protsess kvaliteet sisaldab järgmist:

1. ettevalmistustööd (kooskõlastus teiste tugiprotsessidega ja tarkvara kvaliteedi tagamise protsessi enda planeerimine, arvestades kasutatavaid standardeid, meetodeid, protseduure ja tööriistu);
2. toote kvaliteedi tagamine, mis eeldab tarkvara ja selle dokumentatsiooni garanteeritud täielikku vastavust lepingus sätestatud kliendi nõuetele;
3. protsessi kvaliteedi tagamine, mis eeldab tarkvara elutsükli protsesside, arendusmeetodite, arenduskeskkonna ja personali kvalifikatsiooni garanteeritud vastavust lepingutingimustele, kehtestatud standarditele ja protseduuridele;
4. muude tarkvara kvaliteedinäitajate tagamine, mis viiakse läbi vastavalt lepingutingimustele ja ISO 9001 kvaliteedistandardile.

Kontrolliprotsess seisneb selles, et tehakse kindlaks, kas mõne tegevuse tulemusena valminud tarkvara vastab täielikult eelnevatest tegevustest tulenevatele nõuetele või tingimustele. Kogu tarkvara elutsükli protsessi efektiivsuse parandamiseks tuleks verifitseerimine võimalikult varakult integreerida seda kasutavate protsessidega (st tarnimise, arenduse, käitamisega). Kinnitusprotsess võib hõlmata ülevaatamist, hindamist ja testimist.

Kontrollimist saab läbi viia erineva sõltumatuse astmega (alates teostajast kuni teise tarnijast, arendajast jne sõltumatu organisatsiooni spetsialistideni). Kinnitusprotsessi käigus kontrollitakse järgmisi tingimusi:

1. süsteemile esitatavate nõuete järjepidevus ja kasutajate vajaduste arvessevõtmise määr;
2. tarnija suutlikkus täita kindlaksmääratud nõudeid;
3. valitud tarkvara elutsükli protsesside vastavus lepingutingimustele;
4. tarkvara elutsükli protsesside standardite, protseduuride ja arenduskeskkonna piisavus;
5. tarkvara disaini spetsifikatsioonide vastavus kindlaksmääratud nõuetele;
6. kirjelduse õigsus sisend- ja väljundandmetees, sündmuste järjestus, liidesed, loogika jne;
7. koodeksi vastavus projekteerimise spetsifikatsioonidele ja nõuetele;
8. koodi testitavus ja korrektsus, vastavus aktsepteeritud kodeerimisstandarditele;
9. tarkvara komponentide korrektne integreerimine süsteemi;
10. dokumentatsiooni piisavus, täielikkus ja järjepidevus.

Sertifitseerimisprotsess on mõeldud kindlaksmääratud nõuete ja loodud tarkvara täielikkuse kindlakstegemiseks nende konkreetse funktsionaalse otstarbe jaoks (mida tarbija vajab). Atesteerimise all mõistetakse tavaliselt tarkvaratoote testimise usaldusväärsuse kinnitamist ja hindamist. Kvalifikatsioon peaks tagama, et tarkvara vastab täielikult spetsifikatsioonidele, nõuetele ja dokumentatsioonile ning et kasutaja saab tarkvara ohutult ja turvaliselt kasutada.

Atesteerimist, nagu ka kontrollimist, saab läbi viia erineva sõltumatuse astmega (kuni tarnijast, arendajast, operaatorist või hooldusteenusest sõltumatu organisatsioon).

Ühine hindamisprotsess on mõeldud projektiga seotud töö ja nende tööde teostamise käigus loodud tarkvaratoote oleku hindamiseks. See keskendub peamiselt projekti ressursside, personali, seadmete ja tööriistade planeerimisele ja juhtimisele.

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

Auditiprotsess on projekti ja toote vastavuse tuvastamine nõuetele, plaanidele ja lepingutingimustele. Auditi võivad läbi viia kaks lepinguosalist, kusjuures üks pool kontrollib teist.

Audit on audit (tõendamine), mille viib läbi pädev asutus (isik), et anda sõltumatu hinnang tarkvara või protsesside vastavuse astmele kehtestatud nõuetele.

Auditi eesmärk on tuvastada tegelike tööde ja aruannete vastavus nõuetele, plaanidele ja lepingule. Audiitorid ei tohiks tarkvaraarendajatest otseselt sõltuda. Need määravad kindlaks töö seisu, ressursside kasutamise, dokumentatsiooni vastavuse spetsifikatsioonidele ja standarditele, testimise õigsuse jne.

Probleemi lahendamise protsess hõlmab arenduse, töö või muude protsesside käigus leitud probleemide (sh avastatud mittevastavuste) analüüsi ja lahendamist, sõltumata nende päritolust või allikast.

5.4. Tarkvara elutsükli organisatsioonilised protsessid

Juhtimisprotsess koosneb tegevustest ja ülesannetest, mida saab täita iga oma protsesse juhtiv osapool. See pool(haldur) vastutab toote vabastamise haldamise eest,

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

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

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

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

Riis. 1. Tarkvara elutsükli protsessid.

Omandamise protsess(omandamise protsess). See koosneb toimingutest

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

1) soetamise algatamine;

2) taotlusettepanekute koostamine;

3) lepingu koostamine ja kohandamine;

4) tarnija tegevuse järelevalve;

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

Tarneprotsess(tarneprotsess). See hõlmab tegevusi ja ülesandeid, mida teostab tarnija, kes pakub kliendile tarkvaratoodet või -teenust. See protsess sisaldab järgmisi samme:

1) kohaletoimetamise algatamine;

2) pakkumistele vastuse koostamine;

3) lepingu koostamine;

4) planeerimine;

5) rakendamine ja kontroll;

6) kontrollimine ja hindamine;

7) tööde tarnimine ja lõpetamine.

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

Arendusprotsess hõlmab järgmisi samme:

1) süsteeminõuete analüüs;

2) süsteemiarhitektuuri projekteerimine;

3) tarkvaranõuete analüüs;

4) tarkvaraarhitektuuri projekteerimine;

5) üksikasjalik tarkvaraprojekt;

6) tarkvara kodeerimine ja testimine;

7) tarkvara integreerimine;

8) tarkvara kvalifikatsiooni testimine;

9) süsteemiintegratsioon;

10) süsteemi kvalifikatsiooni testimine;

11) tarkvara installeerimine;

12) tarkvara aktsepteerimine.

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

1) töökatsetused;

2) süsteemi toimimine;

3) kasutajatugi.

Hooldusprotsess(hooldusprotsess). See sätestab saateorganisatsiooni (tugiteenistuse) tegevused ja ülesanded. See protsess aktiveeritakse tarkvaratoote ja sellega seotud dokumentatsiooni muudatuste (muudatuste) korral, mis on põhjustatud tekkinud probleemidest või vajadusest tarkvara uuendada või kohandada. IEEE-90 standardi kohaselt tähendab hooldus tarkvara muudatuste tegemist, et parandada vigu, parandada jõudlust või kohaneda muutuvate töötingimustega või

nõuded. Olemasoleva tarkvara muudatused ei tohi rikkuda

selle terviklikkus. Hooldusprotsess hõlmab tarkvara üleviimist teise keskkonda (migratsiooni) ja lõpeb tarkvara kasutusest kõrvaldamisega.

Hooldusprotsess hõlmab järgmisi samme:

1) probleemide ja tarkvara muutmise taotluste analüüs;

2) tarkvara muutmine;

3) kontrollimine ja vastuvõtmine;

4) tarkvara ülekandmine teise keskkonda;

5) tarkvara dekomisjoneerimine.

Abiprotsesside rühma kuuluvad:

Dokumentatsioon;

Konfiguratsiooni juhtimine; kvaliteedi tagamine;

Kontrollimine; atesteerimine;

Ühine hindamine;

Probleemi lahendamine.

Dokumenteerimisprotsess(dokumentatsiooniprotsess). See annab tarkvara elutsükli jooksul loodud teabe ametliku kirjelduse. Dokumenteerimisprotsess hõlmab järgmisi samme:

1) projekteerimine ja arendus;

2) dokumentatsiooni väljastamine;

3) dokumentatsiooni pidamine.

Konfiguratsioonihaldusprotsess(konfiguratsioonihaldusprotsess). See hõlmab haldus- ja tehniliste protseduuride rakendamist kogu tarkvara elutsükli jooksul, et teha kindlaks tarkvarakomponentide olek süsteemis, hallata tarkvara muudatusi, kirjeldada ja raporteerida tarkvarakomponentide olekut ja muudatuste taotlusi, tagada täielikkus, ühilduvus ja korrektsus. tarkvarakomponentide jaoks, hallata ladustamist ja tarnimist ON. IEEE-90 standardi kohaselt mõistetakse tarkvara konfiguratsiooni all selle funktsionaalsete ja füüsiliste omaduste kogumit.

tehnilises dokumentatsioonis kehtestatud ja tarkvaras rakendatud omadused.

Konfiguratsioonihaldus võimaldab korraldada, süstemaatiliselt arvesse võtta ja kontrollida tarkvara muudatusi elutsükli kõigil etappidel. Tarkvara konfiguratsiooni haldamise üldpõhimõtted ja soovitused on kajastatud standardi eelnõus ISO/I EC CD 12207-2: 1995 "Infotehnoloogia – tarkvara elutsükli protsessid. 2. osa.

Tarkvara konfiguratsioonihaldus". Konfiguratsioonihaldusprotsess sisaldab järgmisi samme.

1) konfiguratsiooni identifitseerimine;

2) konfiguratsiooni juhtimine;

3) konfiguratsiooni seisu arvestamine;

4) konfiguratsiooni hindamine;

5) vabastamise haldamine ja kättetoimetamine.

Kvaliteedi tagamise protsess(kvaliteedi tagamise protsess). See tagab asjakohase tagatise, et tarkvara ja selle elutsükli protsessid vastavad kindlaksmääratud nõuetele ja kinnitatud plaanidele. Tarkvara kvaliteedi all mõistetakse omaduste kogumit, mis iseloomustavad tarkvara võimet täita kindlaksmääratud nõudeid. Loodava tarkvara kohta usaldusväärsete hinnangute saamiseks peab selle kvaliteedi tagamise protsess toimuma tarkvaraarendusega otseselt seotud teemadest sõltumatult. Kasutada võib ka muude toetavate protsesside, nagu kontrollimine, atesteerimine, osalushindamine, audit ja probleemide lahendamine, tulemusi. Kvaliteedi tagamise protsess hõlmab järgmisi tegevusi:

1) toote kvaliteedi tagamine;

2) protsesside kvaliteedi tagamine;

3) muude süsteemi kvaliteedinäitajate tagamine.

Kinnitusprotsess(kontrolliprotsess). See seisneb kindlakstegemises, et tarkvaratooted, mis on mõne tegevuse tulemus, vastavad täielikult eelnevate tegevustega kehtestatud nõuetele või tingimustele (kinnitamine kitsamas tähenduses tähendab tarkvara õigsuse formaalset tõendamist).

Atesteerimisprotsess(valideerimisprotsess). See näeb ette kindlaksmääratud nõuete ja loodud süsteemi või tarkvaratoote nende konkreetsele funktsionaalsele otstarbele vastavuse täielikkuse kindlaksmääramise. Sertifitseerimise all mõistetakse tavaliselt tarkvara testimise usaldusväärsuse kinnitamist ja hindamist.

Ühine hindamisprotsess(ühine läbivaatamise protsess). See on mõeldud projektiga seotud tööde ja nende tööde (toimingute) teostamise käigus loodud tarkvara oleku hindamiseks. See keskendub peamiselt projekti ressursside, personali, seadmete ja tööriistade planeerimisele ja juhtimisele.

Auditiprotsess(auditiprotsess). Tegemist on lepingu nõuete, plaanide ja tingimuste täitmise kindlaksmääramisega.

Probleemi lahendamise protsess(probleemide lahendamise protsess). See näeb ette probleemide (sealhulgas avastatud mittevastavuste) analüüsi ja lahendamise, olenemata nende päritolust või allikast, mis avastatakse arenduse, käitamise, hoolduse või muude protsesside käigus. Iga leitud probleem tuleb tuvastada, kirjeldada, analüüsida ja lahendada.

Tarkvara elutsükli organisatsiooniliste protsesside rühm hõlmab:

Kontroll;

Infrastruktuuri loomine;

parandamine;

Uute versioonide väljaandmine;

Haridus.

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

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

Parandusprotsess(parandusprotsess). See näeb ette tarkvara elutsükli protsesside hindamise, mõõtmise, kontrolli ja täiustamise. Tarkvara elutsükli protsesside täiustamine on suunatud kõigi nendega seotud spetsialistide tootlikkuse tõstmisele kasutatava tehnoloogia, juhtimismeetodite, tööriistade valiku ja koolituse täiustamise kaudu.

töötajad.

Õppimisprotsess(koolitusprotsess). See hõlmab töötajate esmast koolitust ja järgnevat täiendõpet.