Tehniline dokumentatsioon. Tehniline dokumentatsioon Vastuvõtukatsete läbiviimine

Märkus: Loogiline jätk eelmisele loengule. Üksikasjalikult käsitletakse GOST R ISO/IEC 12207 praktilise rakendamise probleemi organisatsioonides ja projektides. Sellega seoses uuritakse standardeid GOST R ISO/IEC 15271 ja GOST R ISO/IEC 16326.

Eelmisest loengust peaks ilmnema, et GOST R ISO/IEC 12207 juurutamine on väga raske ülesanne. Esiteks pole selge, mida tähendab "GOST R ISO/IEC 12207 rakendamine"? Kas seda võib lugeda rakendatuks, kui osa organisatsiooni protsessidest ühtivad standardi protsessidega ja osa mitte? Kas standardit saab lugeda rakendatuks, kui mõned projektid viiakse ellu selle järgi, teised aga mitte? Seda küsimuste loendit võib jätkata ja jätkata.

Pole juhus, et GOST R ISO/IEC 12207 järgi töötati välja standard GOST R ISO/IEC 15271-02 (GOST 15271, 2002), mis on spetsiaalselt pühendatud selle rakendamise ülesandele, mida nimetatakse "GOST-i rakendamise juhisteks". R ISO/IEC 12207”. Nüüd jätkame selle kaalumisega.

Standard GOST R ISO/IEC 15271

Standardi tähendus selgub selle sissejuhatavas osas.

"1.2. Standardi kasutajad.

Seda standardit saavad kasutada subjektid (üksikisikud, organisatsioonid), kes soovivad lepingute rakendamisel rakendada GOST R ISO/IEC 12207, olenemata projekti mahust või keerukusest konkreetse organisatsiooni poolt enesekontrolli või parendustööde tegemiseks. elutsükli protsessid tarkvara tööriistad.

See standard määrab kindlaks, kuidas standardit GOST R ISO/IEC 12207 saab kasutada seoses erinevat tüüpi tarkvaraga ja millised protsessid on iga juhtumi jaoks sobivad.

See standard täiendab standardit GOST R ISO/IEC 12207, mis pole mitte ainult normatiivne dokument, vaid ka reaalse projekti haldamise standard. (Näiteks viimane juhtum esineb siis, kui GOST R ISO/IEC 12207 on parendusprotsessi osa läbiviimise mudel). Seda standardit tuleks lugeda tervikuna, kuid üksikjuhtudel võib kasutada konkreetseid jaotisi."

GOST R ISO/IEC 15271 standard koosneb 8 osast ja 4 lisast. Sisuosasid nimetatakse järgmiselt (tekstist võetud nummerdamine):

• 4. GOST R ISO/IEC 12207 väljatöötamise põhikontseptsioonid.
• 5. GOST R ISO/IEC 12207 rakendamine.
• 6. Rakendamine projektides.
• 7. Rakendamine organisatsioonides.
• 8. Taotlus elutsükli mudelid süsteemid.

Jaotis 4 on kirjutatud GOST R ISO/IEC 12207 teksti kommentaaride ja täpsustuste stiilis. Kõige olulisemad täpsustused puudutavad GOST R ISO/IEC 12207 koostoimet organisatsiooni korporatiivsete standarditega, mõistete „eraldust“. tarkvara” ja „süsteem” ning sellest tulenevad eristused tarkvara ja süsteemidega seotud protsesside vahel. Kontseptsiooni kirjeldatakse üksikasjalikult kvaliteedijuhtimine, rakendatud standardis GOST R ISO/IEC 12207. Üldjoontes jätab jaotis mulje GOST R ISO/IEC 12207 lühiülevaatest, mis meenutab õpikut.

Jaotis 5 esitab üldise lähenemisviisi rakendamisele, mida nimetatakse GOST R ISO/IEC 12207 rakendusstrateegiaks. Standardi kohaselt on strateegia "tüüpiline rakendusmeetod, mida tuleks järgida organisatsiooni tegevuses või projektis muudatuste tegemisel". Strateegia viiakse ellu kohustuslikest sammudest koosneva projektina, mida kirjeldatakse mitteametlikult ja ilma igasuguse seoseta organisatsiooni protsessidega. Need sammud on järgmised.

• a) rakendusplaani väljatöötamine;
• b) GOST R ISO/IEC 12207 praktiline rakendamine;
• c) toetuse pakkumine pilootprojekt(s);
• d) rakendusmeetodi vormistamine;
• e) rakendusmeetodi kinnitamine.

Rakendusplaani väljatöötamine hõlmab GOST R ISO/IEC 12207 rakendusala määramist. Ulatus võib olla näiteks osakondade rühm või organisatsiooni projektid. Rakendusala saate määratleda ka organisatsiooni võtmeprotsesside kogumina, mis asendatakse protsessidega standardist GOST R ISO/IEC 12207. Rakendusplaan ise määrab juurutamise käigus läbiviidavate projektide koosseisu (võib olla mitu neist). On ütlematagi selge, et rakendusplaani väljatöötamisel määratakse vajalikud ressursid: rahalised, inimlikud, tehnilised jne.

Praktilises rakenduses, nagu arvata võib, tehakse ettepanek kasutada GOST R ISO/IEC 12207-s endas kirjeldatud kohandamisprotsessi.

Strateegia ise ei tekita küsimusi – selline sammude jada võib konkreetsetes tingimustes olla üsna tõhus, kuid väärib märkimist, et formaalne projektikäsitlus GOST R ISO/IEC 12207 rakendamisel põhineb lihtsustatud arusaamal tegelikust. olukord. Arvestades, et organisatsiooni protsessid (nagu ka organisatsiooni struktuur) on pidevas muutumises, leian, et metoodiliselt oleks õigem käsitleda standardi rakendamist kui pidevat protsessi, mitte kui ajaliselt piiratud projekti. See protsess jälgib muutusi organisatsiooni protsessides ja algatab üksikuid projekte, näiteks:

• projektid GOST R ISO/IEC 12207 rakendamiseks;
• projekt kõigi uute töötajate koolitamiseks GOST R ISO/IEC 12207 protsessides;
• projekt muudatuste sisseviimiseks juurutatud protsessidesse seoses muutustega organisatsiooni organisatsioonilises struktuuris; jne.

GOST R ISO/IEC 12207 kui protsessi rakendamise lähenemisviis, eriti kui see on ette nähtud selle rakendamiseks projektides või organisatsiooni üksikutes osakondades, võimaldab koondada vastutuse üldise tulemuse eest protsessi omaniku kätte. , võimaldab luua üldist tulemuste monitooringut jne. Ilmselt peaks rakendamisele järgnema rakendatavate protsesside toetamine, mis on samuti loomulikult protsessina organiseeritud.

Lisateavet standardi GOST R ISO/IEC 12207 kasutamise kohta projektides on kirjeldatud jaotises 6 "Rakendamine projektides". Standardis tehakse ettepanek projektide klassifitseerimiseks ja selleks võetakse kasutusele uus mõiste - " elutsükli mudel süsteemid" (tüüpmudelite loend on toodud lisas C). See, mis mudel on, pole formaalselt määratletud. Hiljem on 8. jaos öeldud, et "üldine elutsükli mudel süsteemid on jagatud etappideks (etappideks), millele järgneb igaühe kohandamine elutsükli mudelid konkreetne süsteem" (järgmine on etappide loend). Kokku vaadeldakse kolme sellist mudelit: kaskaad-, inkrement-, evolutsiooniline. Analüüsitakse nende eeliseid ja puudusi ning seejärel "kaetakse" GOST R ISO/IEC 12207 protsessid. mudelite struktuurist Selle tulemusena saavad need protsessid täiendavaid omadusi, näiteks korduvad kordused elutsüklis või ajaline kattumine muude protsessidega. Lisaks sisaldab jaotis palju erineva kasulikkusega soovitusi Siin on tüüpiline näide.

"6.1.3. Süsteemi omadused

Alamsüsteemid ja süsteemi konfiguratsioonielemendid tuleb määratleda asjakohasel üksikasjalikkuse tasemel. On vaja kindlaks määrata süsteemi omadused, eriti need, mis on seotud tarkvaraga. Nende omaduste määramisel tuleb märkida, millised neist on süsteemi töötamise ajal kriitilised.

Süsteemitaseme omaduste (seotud tarkvaraga ja kaalumisel) soovituslik loend sisaldab:

• süsteemidevahelised ja süsteemisisesed liidesed;
• kasutajaliidesed;
• tarkvara vigade mõju kaitsele ja süsteemi turvalisus;
• arvutusvõimsuse ja ajapiirangute hindamine;
• tehniliste vahenditega rakendatud programmide kättesaadavus;
• Sobivate arvutite olemasolu.

Kui süsteem sisaldab palju alamsüsteeme või konfiguratsiooniüksusi, peavad need arendusprotsessis olema täielikult kaetud süsteemitasandi tööga. Arvestada tuleb kõiki liideste ja süsteemide komplekteerimise (integreerimise) nõudeid. Väikese süsteemi jaoks ei pruugi nii range toimingute jada vajalik olla."

Eeltoodud lõigu ligikaudne ja ebamäärane sõnastus on iseloomulik kogu standardile tervikuna.

Väga lühikese osa 7 “Rakendamine organisatsioonides” keskne osa on järgmine tekst.

"7.2. Rakendusvõimalused

Põhjused, miks GOST R ISO/IEC 12207 rakendatakse organisatsioonides, võivad olla järgmised:

• olemasoleva meetodi täiuslikkuse kontrollimine. Tavaliselt on see nii, kui meetodi töötas välja organisatsioon ise või ta valis ja muutis olemasolevat meetodit;
• selle meetodi praktiline rakendamine, et vältida riski, mis on seotud sisenemisega uutesse turusektoritesse, kus potentsiaalse riskiga seotud rangemad nõuded;
• uue meetodi väljatöötamine, näiteks uue organisatsiooni vajaduste rahuldamiseks. Hõlmatud võivad olla ühinemise või ärikoostöö teel loodud organisatsioonid. See võib olla vajalik teatud protsessimudelite toetamiseks konkreetse töö pakkumisel;
• Uue tehnoloogia juurutamise juhtimine, näiteks manuaalsete protsesside automatiseerimine või tarkvaratoote juurutamiseks kasutatavate meetodite muutmine. GOST R ISO/IEC 12207 kehtestab kriteeriumid, mille abil saab jälgida vastava meetodi tipptaset enne või pärast tehnoloogia muutmist;
• poole sisemise suutlikkuse hindamine lepingu kriteeriumide täitmise osas, näiteks konkursi (pakkumis)menetluses osaleva poolena;
• teha kindlaks verstapostid, mis võivad viia täiustatud programmide väljatöötamiseni, näiteks auditeerimine vastavalt standardile GOST R ISO/IEC 12207 ja täiustamisprotsessi enda kasutamine.

Isegi sisuliste vastuväidete puudumisel on siiski võimatu seda teksti standardiks pidada. Eelkõige meenutab see koolitusjuhendit ja tõenäoliselt on see sellisena nõutud, kuid sellist teksti ei saa kasutada tegevusjuhisena GOST R ISO/IEC 12207 rakendamisel organisatsioonis.

Lõpuks jaotis 8 „Taotlus elutsükli mudelid süsteemid" sisaldab üsna ebamääraseid määratlusi" elutsükli mudelid süsteemid" ja " elutsükli mudelid tarkvara" ja püüab luua nende vahel vastavust. Kuna täpsed määratlused puuduvad, on tulemuste üle võimatu hinnata.

Üldiselt jätab standard GOST R ISO/IEC 15271 mulje, et tegemist on puhtalt abidokumendiga võrreldes GOST R ISO/IEC 12207-ga, mis kannatab ligikaudsuse ja üldtunnuste rohkuse all. See ei sobi praktilistele juhtidele – liiga palju on abstraktset arutluskäiku ja liiga vähe konkreetsust. IT-juhtimise protsesse õppivate üliõpilaste ja spetsialistide jaoks puudub sellel teema laiaulatuslik vaade (piirab ju GOST R ISO/IEC 12207) ja see on ülekoormatud tarbetute tehniliste detailidega. Sellegipoolest on GOST R ISO/IEC 15271 tundmine kasulik, kuna see näitab IT-juhtimise valdkonna spetsialistide mõttesuunda ja näitab, kus ja kuidas kaasaegsed standardid arenevad. Ma näeksin seda vahetöödokumendina, küll standardvormis, kuid mõeldud pigem IT-juhtimise spetsialistide huvilisele auditooriumile.

Standard GOST R ISO/IEC 16326

Veel üks katse vormistada GOST R ISO/IEC 12207 rakendamise protsess tehti standardis GOST R ISO/IEC 16326 “Juhised GOST R ISO/IEC 12207 kasutamiseks projektijuhtimises” (GOST 16326, 2002). See näitab püüdlust ühineda elutsükli protsessid GOST R ISO/IEC 12207 projektijuhtimisprotsessidega populaarsest metoodilisest teatmeraamatust PMBOK 1 PMBOK – projektijuhtimise teadmiste kogu(PMBOK, 2009) ja ISO 10006 standard (standardi venekeelne versioon sisaldub (GOST 10006, 2005)). See on skemaatiliselt näidatud joonisel fig.

4.1 standardis antud.

Riis. 4.1.

Standardi kasutajate ring on üsna täpselt määratletud punktis 1.1.

See standard on mõeldud ettevõtetele, kes kasutavad või kavatsevad kasutada GOST R ISO/IEC 12207 tarkvaraprojektides, olenemata nende ulatusest, loodud toodetest, metoodikast, mahust või keerukusest. Standard on mõeldud eelkõige projektiadministraatoritele, kes vastutavad juhtimisprotsesside vastavuse eest standardile GOST R ISO/IEC 12207:

• organisatsiooni ja pideva täiustamise eest vastutavad administraatorid elutsükli protsessid tarkvara vastavalt standardile GOST R ISO/IEC 12207;
• rakenduse eest vastutavad administraatorid elutsükli protsessid tarkvara vastavalt GOST R ISO/IEC/12207 projekteerimise tasemel;
• organisatsioonid või isikud, kes on SCP rakendamisel alltöövõtjad ( Tarkvaraprojektide juhtimine. - AB).

Üksikisikute jaoks on järgmised kaalutlused:

• kaasatud tarkvaraprojektidesse, kuid mitte AP ( Projekti administraatorid. - AB);
• kes on mittetarkvaraprojektide administraatorid, kuid seotud AP-tarkvaraga."

Suhteliselt lühike põhitekst (jaotis 6 "Juhend" võtab enda alla vaid 9 lehekülge kokku 35-st) on protsessi 7.1 "Juhend" järjestikune kommentaar standardist GOST R ISO/IEC 12207 PMBOK-i vaatenurgast. Kommenteerimisstiil on mitteametlik, arutelud on enamasti nõuandva iseloomuga. Kommentaar ei ületa tavamõistust ega sisalda midagi uut. Üldiselt on see kasulik lugemine projektijuhtidele (tõlkijate terminoloogias “administraatorid”), aga ei midagi enamat.

Lisa A on üks suur tabel, mis demonstreerib seoseid standardi GOST R ISO/IEC 12207 põhiprotsesside ja nendest välja kutsutud “Management” protsessi tegevuste vahel. Kõik need lingid sisalduvad GOST R ISO/IEC 12207 standardi põhiosas; nende ühte tabelisse liitmine ei lisa uut infot.

Lisa B on täpselt sama tabel, mis ühendab protsessivaldkonnad ja üksikud protsessid PMBOK-ist GOST R ISO/IEC 12207 protsessi "Juhtimine" tegevustega.

Sarnane tabel, kus alade asemel kasutatakse protsessigruppe PMBOK tähenduses, on toodud lisas C. Lisades B ja C on tegelikult kokku võetud kõik standardi 6. osas öeldu. Miks oli seda vaja tabelite kujul esitada, jääb selgusetuks. Need tabelid ei anna lisateavet, näidates vaid tõsiasja, et PMBOK ja GOST R ISO/IEC 12207 vahel on seosed. Mõlema lisa olek on aga „viide”, seega ei pruukinud neil olla sõltumatut väärtust.

Teine kokkuvõtlik tabel on toodud lisas D. See näitab seoseid kolme allika vahel: GOST R ISO/IEC 12207, PMBOK ja ISO 10006 standard Märgin kohe, et viimane tõlgiti vene keelde alles 2005. aastal. sellest tulenevalt erineb standardi GOST R ISO/IEC 16326 2002 lisas D kasutatud terminoloogia hilisemast. Nagu eelmistel juhtudel, on nende seoste kompaktse tabelina esitamise tähendus ebaselge. Lisaks ületab lisade A-D kogumaht enam kui kaks korda põhijaotise 6 “Käsiraamat” mahtu.

Minu arvates ei erine GOST R ISO/IEC 16326-2002 vormilt ja eesmärgi poolest GOST R ISO/IEC 15271-2002. Mõlemad kannatavad liigse arutluskäigu all, mis on "üldiselt" õige ja põhineb ainult tervel mõistusel. Need argumendid on ilmsed kõigile, kellel on praktiline projektijuhtimise kogemus, ja vaevalt tunduvad mõistlikud neile, kellel sellist kogemust pole. Erinevalt GOST R ISO/IEC 15271-2002 standardist on GOST R ISO/IEC 16326-2002 standard formaalsem, kuid kavandatava formalismi praktiline tähendus pole selge.

Praktilise rakendamise seisukohalt IT-ga seotud äriprotsesside kujundamisel on mõlemad standardid suures osas kasutud. Teisest küljest võivad need olla nõudlikud keerukate projektide elluviimisel, mis koos IT-juhtimise tavade uurimisega hõlmavad projektijuhtimise ja projektijuhtimise analüüsi. kvaliteedijuhtimine.

Lisaks ülalkirjeldatule on GOST R ISO/IEC 12207 loonud mitmeid standardeid, mis kirjeldavad üksikasjalikult selles sisalduvaid. elutsükli protsessid. Nende hulka kuuluvad näiteks GOST R ISO/IEC 15910-2002 “Tarkvara kasutajadokumentatsiooni loomise protsess” (GOST 15910, 2002) ja GOST R ISO/IEC 14764-2002 “Tarkvara hooldus” (GOST 14764, 2002) . Mõnda sarnast ISO standardit pole veel vene keelde tõlgitud; Tõenäoliselt kasvab tulevikus GOST R ISO/IEC 12207-ga otseselt seotud venekeelsete GOST R ISO standardite arv.

Lähtejoon vastavalt standardile GOST R ISO/IEC 12207-2010

või mis on ametlikult üle vaadatud ja on hiljem edasise arendamise aluseks ning mida saab muuta ainult ametlike ja kontrollitud muudatustega [alates GOST R ISO/IEC 12207-2010 punktist 4.6]

Valideerimine vastavalt standardile GOST R ISO/IEC 12207-2010

Kinnitus (objektiivsete tõendite esitamise alusel), et kavandatud eesmärk või rakendus on täidetud. Märkus. Valideerimine kontekstis on toimingute kogum, mis garanteerib ja annab kindlustunde, et see suudab realiseerida oma praeguse ja tulevase eesmärgi [alates GOST R ISO/IEC 12207-2010 punktist 4.54]

Kontrollimine vastavalt standardile GOST R ISO/IEC 12207-2010

Kinnitus (objektiivsete tõendite esitamise alusel), et nimetatud nõuded on täielikult täidetud. MÄRKUS Konteksti kontrollimine on toimingute kogum, mis võrdleb elutsükli tulemust selle tulemuse jaoks nõutavate omadustega. Elutsükli tulemused võivad olla (kuid mitte ainult) täpsustatud nõuded, kirjeldus ja otse [GOST R ISO/IEC 12207-2010 punktist 4.55]

Kvaliteedi tagamine vastavalt standardile GOST R ISO/IEC 12207-2010

Kõik kavandatud ja süstemaatilised tegevused, mis on raamistikus läbi viidud ja näidatud asjakohasel viisil, et tagada piisav kindlus, et klient on täielikult rahul.

1. On olemas nii sisemised kui ka välised kvaliteedigarantiid:
   1. sisemine kvaliteeditagamine: kvaliteedi tagamise piirides annab kindlustunde;
   2. Väline kvaliteeditagamine: lepingulistes olukordades annab kvaliteeditagamine kindlustunde või teistele.
2. Mõned kvaliteedi tagamise ja kvaliteedi tagamise tegevused on omavahel seotud.
3. Kui kvaliteedinõuded ei rahulda vajadusi täielikult, ei saa kvaliteeditagamine tagada vajalikku kindlust.

[alates punktist 4.34 GOST R ISO/IEC 12207-2010]

5.2.2 Kokkuvõte elutsükli protsessidest

Selles standardis on kaks olulist protsessijaotust. Jaotis 6 pakub süsteemi konteksti eraldiseisva tarkvaratoote või -teenuse või tarkvarasüsteemi kasutamiseks. Jaotis 7 sisaldab spetsiifilisi tarkvaraprotsesse, mida kasutatakse tarkvaratoote või -teenuse rakendamisel, mis on suurema süsteemi osa.

Selle rahvusvahelise standardi samaaegse kasutamise hõlbustamiseks antakse punkti 6 vastavatele protsessidele samad alapunkti tähised.

Üldiselt on selles standardis esitatud protsesside kogum kohandatud vastavalt tarkvarale või ette nähtud protsesside tulemuste sisendid. Paljud protsessid on sarnased tarkvaraspetsiifiliste protsesside juurutustega, kuid neil on eesmärkidel, tulemustel ja sihtrühmadel põhinevad olulised erinevused. Nii selle standardi kui ka selle standardi kasutajad peaksid kindlasti iga sellise konkreetse protsessi selgitused ja märkused üle vaatama.

Lepinguprotsessid määratlevad kahe organisatsiooni vaheliste lepingute väljatöötamiseks vajalikud tegevused. Kui omandamisprotsess viiakse ellu, annab see vahendid äritegevuseks operatsioonisüsteemis kasutamiseks ettenähtud toodete tarnijaga, süsteemi tugiteenustega või projekti raames välja töötatud süsteemielementidega. Kui tarneprotsess on rakendatud, annab see vahendid projekti elluviimiseks, mille tulemuseks on omandavale poolele tarnitud toode või teenus.

Seega on selles standardis antud lepinguprotsessid suunatud tarkvara lepinguprotsessidele alates .

Organisatsiooni projekti tugiprotsessid juhivad organisatsioonide võimet hankida ja pakkuda tooteid või teenuseid projekti algatamise, toe ja juhtimise kaudu. Need protsessid pakuvad projektide toetamiseks vajalikke ressursse ja infrastruktuuri ning tagavad organisatsiooni eesmärkide ja sõlmitud kokkulepete täitmise. Nad ei väida, et nad on äriprotsesside täielik komplekt, mis rakendab organisatsiooni äritegevuse juhtimist.

Projekti organisatsioonilised tugiprotsessid hõlmavad järgmist:

a) olelustsükli mudeli haldamise protsess;

B) infrastruktuuri haldamise protsess;

c) projektiportfelli haldamise protsess;

d) personalijuhtimise protsess;

e) kvaliteedijuhtimise protsess.

Üldiselt on selle standardiga ette nähtud projektiorganisatsiooni tugiprotsessid protsessid, mis on keskendunud tarkvarale vastavast protsesside komplektist aastal.

Selles standardis on projekt valitud planeerimise, hindamise ja kontrolliga seotud protsesside kirjeldamise aluseks. Nende protsessidega seotud põhimõtteid saab rakendada mis tahes organisatsiooni juhtimise valdkonnas.

Projektiprotsesse on kahte kategooriat. Projektijuhtimise protsesse kasutatakse projekti edenemise kavandamiseks, teostamiseks, hindamiseks ja juhtimiseks. Projekti tugiprotsessid tagavad juhtimise erieesmärkide täitmise. Mõlemat projektiprotsesside kategooriat kirjeldatakse allpool.

Projektijuhtimise protsesse kasutatakse projektiplaanide koostamiseks ja arendamiseks, tegeliku edenemise ja plaanide võrdluse hindamiseks ning projekti edenemise juhtimiseks kuni lõpuni. Individuaalseid projektijuhtimisprotsesse saab käivitada igal ajal elutsükli jooksul ja projekti hierarhia igal tasandil vastuseks projektiplaanidele või ettenägematutele sündmustele. Projektijuhtimise protsesse rakendatakse ranguse ja vormistamise tasemel sõltuvalt projekti riskist ja keerukusest:

a) projekti planeerimise protsess;

b) projektijuhtimise ja hindamise protsess.

Projekti tugiprotsessid moodustavad konkreetse ülesannete kogumi, mis on suunatud konkreetsete juhtimiseesmärkide saavutamisele. Kõik need protsessid on ilmsed iga algatatud tegevuse juhtimisel, ulatudes organisatsioonist kui tervikust kuni eraldiseisva elutsükli protsessi ja selle ülesanneteni:

a) otsuste haldamise protsess;

b) riskijuhtimisprotsess;

c) konfiguratsioonihaldusprotsess;

d) teabehaldusprotsess;

e) mõõtmisprotsess.

Üldiselt on selles standardis esitatud projektitoetusprotsessid identsed punktis toodud projektitoetusprotsessidega, välja arvatud mõned erinevused nende esitusviisis. Mõnel juhul võivad tarkvara tugiprotsessid olla seotud projekti tugiprotsessidega.

Tehnilisi protsesse kasutatakse süsteeminõuete määratlemiseks, nõuete muutmiseks kasulikuks tooteks, toote pidevaks kopeerimiseks (vajadusel), toote rakendamiseks, vajalike teenuste osutamiseks, nende teenuste osutamise jätkamiseks ja toote ringlusest eemaldamiseks, kui seda ei kasutata teenuse osutamisel.

Tehnilised protsessid määratlevad tegevused, mis võimaldavad rakendada organisatsioonilisi ja disainifunktsioone, et optimeerida tehnilistest otsustest ja tegevustest tulenevaid kasu ja vähendada riske. Need tegevused võimaldavad toodetel ja teenustel olla õigeaegsuse ja kättesaadavuse, kulutõhususe, funktsionaalsuse, töökindluse, hooldatavuse, tootlikkuse, kohanemisvõime ja muud omandavatele ja toetavatele organisatsioonidele nõutavad kvaliteedinäitajad. Samuti võimaldab see toodetel ja teenustel vastata tsiviilõiguslikele ootustele või nõuetele, sealhulgas tervise-, ohutus-, turva- ja keskkonnateguritele.

Tehnilised protsessid koosnevad järgmistest protsessidest:

a) õiguste valdajate nõuete määramine (punktis toodud õiguste valdajate nõuete määramise protsessi erijuhtum);

b) süsteeminõuete analüüs (nõuete analüüsi protsessi erijuhtum);

C) süsteemiarhitektuuri projekteerimine (punktis toodud arhitektuuri projekteerimise protsessi erijuhtum);

D) juurutusprotsess (käesoleva standardi jaotises 7 toodud ja edasi arendatud süsteemielementide juurutamisprotsessi erijuhtum tarkvara juurutamise protsessina);

e) süsteemiintegratsiooni protsess (punktis toodud integreerimisprotsessi erijuhtum);

f) süsteemi kvalifikatsiooni testimise protsess (protsess, mis aitab kaasa punktis toodud kontrolliprotsessi tulemuste saavutamisele);

G) tarkvara installiprotsess (protsess, mis aitab kaasa punktis kirjeldatud ülekandeprotsessi tulemuste saavutamisele);

H) tarkvara vastuvõtmise tugiprotsess (protsess, mis aitab kaasa punktis kirjeldatud üleandmisprotsessi tulemuste saavutamisele);

i) tarkvara tööprotsess (punktis toodud tööprotsessi erijuhtum);

j) tarkvara hooldusprotsess (punktis toodud hooldusprotsessi erijuhtum);

k) tarkvara käibelt kõrvaldamise protsess (punktis toodud väljavõtmise ja mahakandmise protsessi erijuht).

Üldiselt on selles standardis esitatud tehnilised protsessid tarkvarale orienteeritud erijuhud või panused tehniliste protsesside tulemustesse, mis on esitatud . Enamik neist on sarnased tarkvara juurutamisprotsessidega, kuid säilitavad olulised erinevused, näiteks süsteeminõuete analüüs ja tarkvaranõuete analüüs saavad alguse erinevatest lähtepunktidest ja neil on erinev eesmärk.

Tarkvara juurutusprotsesse kasutatakse konkreetse süsteemielemendi (komponendi) loomiseks, mis on valmistatud tarkvaratööriista kujul. Need protsessid muudavad kindlaksmääratud käitumised, liidesed ja rakenduspiirangud toiminguteks, mille tulemuseks on süsteemielement, mis vastab süsteeminõuetest tulenevatele nõuetele.

Eriprotsess on tarkvara juurutamise protsess, mis väljendab konkreetselt antud juurutusprotsessi tarkvarafunktsiooni.

Tarkvara juurutamisprotsess hõlmab mitmeid spetsiaalseid madalama taseme protsesse:

a) tarkvaranõuete analüüsimise protsess;

B) tarkvaraarhitektuuri projekteerimise protsess;

c) üksikasjalik tarkvara kavandamise protsess;

d) tarkvara kujundamise protsess;

e) tarkvara integreerimise protsess;

f) tarkvara kvalifikatsiooni testimise protsess.

Tarkvara tugiprotsessid pakuvad konkreetselt keskendunud tegevuste kogumit, mis on suunatud spetsiaalse tarkvaraprotsessi läbiviimisele. Iga toetav protsess aitab kaasa tarkvara juurutamise protsessile tervikuna, millel on kindel eesmärk, aidates kaasa tarkvaraprojekti edule ja kvaliteedile. Selliseid protsesse on kaheksa:

a) tarkvara dokumentatsiooni haldusprotsess;

b) tarkvara konfiguratsiooni haldusprotsess;

c) tarkvara kvaliteedi tagamise protsess;

d) tarkvara kontrollimise protsess;

e) tarkvara valideerimisprotsess;

f) tarkvara auditi protsess;

g) tarkvara auditi protsess;

H) probleemide lahendamise protsess tarkvaras.

Tarkvara taaskasutusprotsesside rühm koosneb kolmest protsessist, mis toetavad organisatsiooni võimet tarkvara komponente projekti piire ületava taaskasutada. Need protsessid on ainulaadsed, kuna oma olemuselt kasutatakse neid väljaspool mis tahes konkreetse projekti piire.

Tarkvara taaskasutusprotsessid on järgmised:

a) domeeni kujundamise protsess;

b) varade taaskasutuse haldusprotsess;

C) programmi taaskasutuse haldamise protsess.

1) Võimaldab rakendada mis tahes elutsükli mudelit- see on võimalik, sest Standard annab võimaluse määratleda protsesside ja ülesannete täitmise järjekord, milles üks protsess võib kutsuda teist protsessi või selle osi.

2) Pakub maksimaalset paindlikkust– paljud protsessid ja ülesanded on kavandatud nii, et neid saab kohandada vastavalt konkreetsetele IS-projektidele. Kohanemine taandub protsesside, tegevuste ja ülesannete kõrvaldamisele, mis ei ole konkreetse projekti puhul rakendatavad.

3) Standard ei sisalda põhimõtteliselt konkreetsete tegevusmeetodite kirjeldust, eelkõige toorikud, lahendused või dokumentatsioon, kirjeldab vaid tarkvara elutsükli protsesside arhitektuuri, kuid ei täpsusta täpsemalt, kuidas protsessides sisalduvaid ülesandeid täita või realiseerida.

4) Standard sisaldab väga vähe kirjeldusi andmebaasi kujundamise kohta- see on õigustatud, sest erinevad IS ja erinevad tarkvarasüsteemid ei saa kasutada mitte ainult kindlat tüüpi andmebaase, vaid ka üldse mitte kasutada.

5) Standardi väärtus on see, et see sisaldab ülesandeid, kvaliteedinäitajaid, hindamiskriteeriume jne., pakkudes igakülgset ülevaadet disainilahendustest.

6) Kuigi standard ei näe ette konkreetse olelusringi mudeli või arendusmeetodi kasutamist, määrab see siiski, et projekti osapooled vastutavad järgmise eest:

väljatöötatava projekti elutsükli mudeli valik;

standardi protsesside ja ülesannete kohandamine valitud mudeliga;

tarkvara arendusmeetodite valik ja rakendamine;

Antud tarkvaraprojektile vastavate tegevuste ja ülesannete sooritamine.

GOST 34 keerulised standardid.

See loodi tervikliku omavahel seotud sektoritevaheliste dokumentide kogumina.

Standardimise objektid: erinevat tüüpi automatiseeritud süsteemid ja nende igat tüüpi komponendid.

GOST-i standardid näevad ette automatiseeritud süsteemi loomise tööetapid ja -faasid, kuid ei näe selgesõnaliselt ette elutsükli rakendamise ajal toimuvaid protsesse.

Vastavalt GOST-ile on automatiseeritud süsteemi väljatöötamine jagatud järgmisteks etappideks ja etappideks:

1. etapp kõlaritele esitatavate nõuete kujundamine:

Etapp a: rajatise ülevaatus ja automatiseeritud süsteemi arendamise vajaduse põhjendamine;

Etapp b: kliendi nõuete kujundamine automatiseeritud süsteemile;

Etapp c: tehtud tööde aruande koostamine ja tehnilise kirjelduse väljatöötamise taotluse koostamine.

2. etapp kontseptsiooni väljatöötamine:

a: objekti uurimine;

b: vajalike uuringute läbiviimine;

c: klientide nõudmistele vastava TEJ kontseptsiooni võimaluste väljatöötamine;

d: tehtud töö aruande koostamine.

3. etapp tuumaelektrijaamade rajamise tehniliste kirjelduste väljatöötamine ja kinnitamine.

4. etapp TEJ eelprojekti väljatöötamine:

a: kogu süsteemi kui terviku ja selle üksikute komponentide eelprojektlahenduste väljatöötamine;

b: dokumentatsiooni väljatöötamine.

5. etapp tehnilise projekti väljatöötamine:

a: kogu süsteemi ja selle osade projekteerimislahenduste väljatöötamine;

b: automatiseeritud süsteemi ja selles sisalduvate alamsüsteemide dokumentatsiooni väljatöötamine;

c: tuumaelektrijaamade lõpetamiseks vajalike toodete tarnimise dokumentatsiooni väljatöötamine ja täitmine või tehniliste nõuete väljatöötamine ja täitmine nende toodete arendamiseks.

6. etapp tehnilise dokumentatsiooni väljatöötamine:

a: süsteemiosa töödokumentatsiooni väljatöötamine;

b: tarkvara arendamine või kohandamine.

7. etappväljatöötatud süsteemi kasutuselevõtt:

a: automatiseerimisobjekti ettevalmistamine AS-i juurutamiseks;

b: personali väljaõpe;

c: kõlarite varustamine tarkvara ja riistvaraga;

d: paigaldustööd;

d: kasutuselevõtt;

e: eelkatsed;

g: proovioperatsioon;

h: vastuvõtutestid.

8. etapp saatja:

a: tööde tegemine vastavalt garantiikohustustele;

b: garantiijärgne teenindus.