Techninė dokumentacija. Techninė dokumentacija Priėmimo bandymų atlikimas

Anotacija: Logiškas ankstesnės paskaitos tęsinys. Išsamiai aptariama GOST R ISO/IEC 12207 praktinio taikymo organizacijose ir projektuose problema. Šiuo atžvilgiu yra tiriami standartai GOST R ISO/IEC 15271 ir GOST R ISO/IEC 16326.

Iš ankstesnės paskaitos turėtų būti akivaizdu, kad GOST R ISO/IEC 12207 įdiegimas yra labai sudėtinga užduotis. Visų pirma, neaišku, ką reiškia „įgyvendinti GOST R ISO/IEC 12207“? Ar jis gali būti laikomas įgyvendintu, jei kai kurie organizacijos procesai sutampa su standarto procesais, o kai kurie ne? Ar standartas gali būti laikomas įgyvendintu, jei vieni projektai vykdomi pagal jį, o kiti – ne? Šį klausimų sąrašą galima tęsti ir tęsti.

Neatsitiktinai vadovaujantis GOST R ISO/IEC 12207, buvo sukurtas standartas GOST R ISO/IEC 15271-02 (GOST 15271, 2002), specialiai skirtas jo įgyvendinimo užduočiai, kuris vadinamas „GOST taikymo gairėmis. R ISO/IEC 12207“. Dabar pereisime prie jo svarstymo.

Standartas GOST R ISO/IEC 15271

Standarto prasmė atskleista jo įvadinėje dalyje.

"1.2. Standarto vartotojai.

Šį standartą gali naudoti subjektai (asmenys, organizacijos), norintys taikyti GOST R ISO/IEC 12207 vykdydami sutartis, nepriklausomai nuo projekto apimties ar sudėtingumo, konkrečios organizacijos savikontrolės ar tobulinimo darbams. gyvavimo ciklo procesai programinės įrangos įrankiai.

Šis standartas nurodo, kaip GOST R ISO/IEC 12207 gali būti naudojamas įvairių tipų programinei įrangai ir kokie procesai yra tinkami kiekvienu atveju.

Šis standartas papildo GOST R ISO/IEC 12207, kuris yra ne tik norminis dokumentas, bet ir realaus projekto valdymo standartas. (Pavyzdžiui, paskutinis atvejis pasitaiko, kai GOST R ISO/IEC 12207 yra modelis, skirtas daliai tobulinimo proceso darbų atlikti). Šis standartas turėtų būti skaitomas kaip visuma, tačiau atskirais atvejais gali būti naudojami atskiri skyriai.

GOST R ISO/IEC 15271 standartą sudaro 8 skyriai ir 4 priedai. Turinio skyriai vadinami taip (numeracija paimta iš teksto):

• 4. Pagrindinės GOST R ISO/IEC 12207 kūrimo koncepcijos.
• 5. GOST R ISO/IEC 12207 įgyvendinimas.
• 6. Taikymas projektuose.
• 7. Taikymas organizacijose.
• 8. Paraiška gyvavimo ciklo modeliai sistemos.

4 skyrius parašytas GOST R ISO/IEC 12207 teksto komentarų ir paaiškinimų stiliumi. Svarbiausi paaiškinimai yra susiję su GOST R ISO/IEC 12207 sąveika su organizacijos korporaciniais standartais, sąvokų skirtumu. programinė įranga“ ir „sistema“ ir dėl to atsirandantys skirtumai tarp procesų, susijusių su programine įranga ir sistemomis. Koncepcija išsamiai aprašyta kokybės valdymas, įgyvendintas GOST R ISO/IEC 12207. Apskritai skyriuje susidaro trumpos konceptualios GOST R ISO/IEC 12207 apžvalgos įspūdis, primenantis vadovėlį.

5 skyriuje pateikiamas bendras įgyvendinimo metodas, vadinamas GOST R ISO/IEC 12207 įgyvendinimo strategija. Pagal standartą strategija yra „tipinis įgyvendinimo metodas, kurio reikia laikytis keičiant organizacijos veiklą ar projektą“. Strategija įgyvendinama kaip projektas, susidedantis iš privalomų žingsnių, aprašytų neformaliai ir be jokio ryšio su organizacijos procesais. Šie veiksmai yra tokie:

• a) įgyvendinimo plano rengimas;
• b) praktinis GOST R ISO/IEC 12207 pritaikymas;
• c) teikiant paramą bandomasis projektas(s);
• d) įgyvendinimo metodo įforminimas;
• e) įgyvendinimo metodo patvirtinimas.

Įgyvendinimo plano rengimas apima GOST R ISO/IEC 12207 taikymo srities nustatymą. Apimtis gali būti, pavyzdžiui, padalinių grupė arba organizacijos projektai. Taikymo sritį taip pat galite apibrėžti kaip pagrindinių organizacijos procesų rinkinį, kuris bus pakeistas procesais iš GOST R ISO/IEC 12207. Pats įgyvendinimo planas nustato įgyvendinimo metu vykdomų projektų sudėtį (gali būti keli iš jų). Savaime suprantama, kad kuriant įgyvendinimo planą nustatomi būtini ištekliai: finansiniai, žmogiškieji, techniniai ir kt.

Praktikoje, kaip ir galima tikėtis, siūloma naudoti pritaikymo procesą, aprašytą pačiame GOST R ISO/IEC 12207.

Pati strategija nekelia klausimų – tokia veiksmų seka konkrečiomis sąlygomis gali būti gana efektyvi, tačiau verta paminėti, kad formalus projektinis požiūris į GOST R ISO/IEC 12207 įgyvendinimą yra pagrįstas supaprastintu supratimu apie realų. situacija. Atsižvelgiant į tai, kad organizacijos procesai (kaip ir organizacinė struktūra) nuolat kinta, manau, kad metodologiškai teisingiau būtų standarto įgyvendinimą vertinti kaip nuolatinį procesą, o ne kaip į terminuotą projektą. Šis procesas stebi organizacijos procesų pokyčius ir inicijuoja atskirus projektus, pavyzdžiui:

• GOST R ISO/IEC 12207 taikymo projektai;
• visų naujų darbuotojų apmokymo GOST R ISO/IEC 12207 procesų projektas;
• įgyvendinamų procesų pokyčių, susijusių su organizacijos organizacinės struktūros pokyčiais, diegimo projektas; ir taip toliau.

Požiūris į GOST R ISO/IEC 12207 įgyvendinimą kaip procesą, ypač jei jis skirtas pradėti nuo jo taikymo projektuose ar atskiruose organizacijos padaliniuose, leis sutelkti atsakomybę už bendrą rezultatą proceso savininko rankose. , leis nustatyti bendrą rezultatų stebėseną ir pan. Akivaizdu, kad po įgyvendinimo turėtų sekti įgyvendinamų procesų palaikymas, kuris taip pat natūraliai organizuojamas kaip procesas.

Daugiau informacijos apie GOST R ISO/IEC 12207 naudojimą projektuose aprašyta 6 skyriuje „Taikymas projektuose“. Standarte siūloma klasifikuoti projektus ir šiuo tikslu įvedama nauja sąvoka - " gyvavimo ciklo modelis sistemos" (tipinių modelių sąrašas pateiktas C priede). Kas yra modelis, formaliai nėra apibrėžta. Vėliau 8 skirsnyje teigiama, kad „bendrieji gyvavimo ciklo modelis sistemos skirstomos į etapus (etapus), vėliau kiekvieną iš jų pritaikant prie gyvavimo ciklo modeliai specifinė sistema" (toliau pateikiamas etapų sąrašas). Iš viso nagrinėjami trys tokie modeliai: kaskadinis, inkrementinis, evoliucinis. Išanalizuojami jų pranašumai ir trūkumai, o tada „uždengiami" GOST R ISO/IEC 12207 procesai. Dėl modelių struktūros šie procesai įgyja papildomų savybių, pavyzdžiui, kartojasi gyvavimo cikle arba sutampa su kitais procesais. Be to, skyriuje pateikiama daug įvairaus naudingumo rekomendacijų projektų aspektai. Čia yra tipiškas pavyzdys.

"6.1.3. Sistemos charakteristikos

Posistemiai ir sistemos konfigūracijos elementai turi būti apibrėžti atitinkamu detalumo lygiu. Būtina nustatyti sistemos charakteristikas, ypač susijusias su programine įranga. Nustatant šias charakteristikas, būtina atkreipti dėmesį, kurios iš jų yra kritinės sistemos veikimo metu.

Orientacinis sistemos lygio charakteristikų (susijusių su programine įranga ir į kurias reikia atsižvelgti) sąrašas apima:

• tarpsisteminės ir vidinės sistemos sąsajos;
• vartotojo sąsajos;
• programinės įrangos klaidų įtaka apsaugai ir sistemos saugumas;
• skaičiavimo galios ir laiko apribojimų įvertinimas;
• techninėmis priemonėmis įgyvendinamų programų prieinamumas;
• Tinkamų kompiuterių prieinamumas.

Jei sistemoje yra daug posistemių arba konfigūracijos elementų, jie turi būti visiškai padengti sistemos lygmens darbu nuo kūrimo proceso. Turi būti atsižvelgta į visus sąsajų ir sistemų surinkimo (integravimo) reikalavimus. Mažai sistemai tokia griežta veiksmų seka gali būti nereikalinga“.

Apytikslė ir neaiški formuluotė pirmiau pateiktoje ištraukoje būdinga visam standartui kaip visumai.

Centrinė labai trumpos 7 dalies „Taikymas organizacijose“ dalis yra toks tekstas.

"7.2. Taikymo galimybės

Priežastys, kodėl GOST R ISO/IEC 12207 yra įdiegtos organizacijose, gali būti šios:

• esamo metodo tobulumo patikrinimas. Dažniausiai taip būna, kai metodą sukūrė pati organizacija arba ji pasirinko ir modifikavo esamą metodą;
• praktinis šio metodo taikymas siekiant užkirsti kelią rizikai, susijusiai su patekimu į naujus rinkos sektorius, kuriems taikomi griežtesni reikalavimai, susiję su galima rizika;
• sukurti naują metodą, pavyzdžiui, patenkinti naujos organizacijos poreikius. Gali būti įtrauktos organizacijos, sukurtos susijungimo ar verslo bendradarbiavimo būdu. To gali prireikti tam, kad būtų palaikomi kai kurie konkretaus darbo procesų modeliai;
• Naujų technologijų diegimo valdymas, pavyzdžiui, rankinių procesų automatizavimas arba programinės įrangos produkto diegimo metodų keitimas. GOST R ISO/IEC 12207 nustato kriterijus, pagal kuriuos galima stebėti atitinkamo metodo tobulumą prieš arba po technologijos pakeitimo;
• šalies vidinių galimybių, susijusių su sutarties kriterijų atitikimu, įvertinimas, pavyzdžiui, dalyvaujant konkurso (konkurso) procese;
• nustatyti gaires, kurios gali paskatinti tobulesnių programų kūrimą, pvz., auditą pagal GOST R ISO/IEC 12207 ir paties tobulinimo proceso naudojimą.

Net ir visiškai nesant esminių prieštaravimų, šio teksto vis tiek neįmanoma laikyti standartu. Labiausiai jis primena mokymo vadovą ir tikriausiai bus paklausus, tačiau toks tekstas negali būti naudojamas kaip veiksmų vadovas diegiant GOST R ISO/IEC 12207 organizacijoje.

Galiausiai, 8 skyrius „Paraiška gyvavimo ciklo modeliai sistemos" yra gana neaiškios apibrėžtys" gyvavimo ciklo modeliai sistemos“ ir „ gyvavimo ciklo modeliai programinė įranga" ir bando nustatyti jų atitiktį. Kadangi nėra tikslių apibrėžimų, neįmanoma spręsti apie rezultatus.

Apskritai, GOST R ISO/IEC 15271 standartas sukuria įspūdį, kad tai yra grynai pagalbinis dokumentas, palyginti su GOST R ISO/IEC 12207, kenčiantis nuo apytikslumo ir gausybės bendrų dalykų. Tai netinka praktiškiems vadovams – per daug abstrakčių samprotavimų ir per mažai konkretumo. Studentams ir specialistams, studijuojantiems IT valdymo procesus, trūksta plataus dalyko požiūrio (juk ribojamas GOST R ISO/IEC 12207) ir yra perkrautas nereikalingomis techninėmis detalėmis. Nepaisant to, susipažinimas su GOST R ISO/IEC 15271 yra naudingas, nes jis parodo IT valdymo srities specialistų minties kryptį ir parodo, kur ir kaip vystosi šiuolaikiniai standartai. Į jį žiūrėčiau kaip į tarpinį darbinį dokumentą, nors ir standartinį, bet skirtą daugiau diskusijoms tarp suinteresuotos IT valdymo specialistų auditorijos.

Standartas GOST R ISO/IEC 16326

Dar vienas bandymas įforminti GOST R ISO/IEC 12207 taikymo procesą buvo atliktas GOST R ISO/IEC 16326 standarte „GOST R ISO/IEC 12207 naudojimo projektų valdyme gairės“ (GOST 16326, 2002). Tai rodo bandymą susivienyti gyvavimo ciklo procesai iš GOST R ISO/IEC 12207 su projektų valdymo procesais iš populiarios metodinės žinyno PMBOK 1 PMBOK – Projektų valdymo žinių įstaiga(PMBOK, 2009) ir ISO 10006 standartas (rusiška standarto versija yra (GOST 10006, 2005)). Tai schematiškai parodyta fig. 4.1 pateiktas standarte.

Ryžiai.

4.1.

Standarto naudotojų ratas gana tiksliai apibrėžtas 1.1 skyriuje.

Šis standartas skirtas įmonėms, naudojančioms arba planuojančioms naudoti GOST R ISO/IEC 12207 programinės įrangos projektuose, neatsižvelgiant į jų apimtį, sukurtus produktus, metodiką, apimtį ar sudėtingumą. Standartas pirmiausia skirtas projektų administratoriams, atsakingiems už valdymo procesų atitikimą GOST R ISO/IEC 12207:

• administratoriai, atsakingi už organizavimą ir nuolatinį tobulėjimą gyvavimo ciklo procesai programinė įranga pagal GOST R ISO/IEC 12207;
• už paraišką atsakingi administratoriai gyvavimo ciklo procesai programinė įranga pagal GOST R ISO/IEC/12207 projektavimo lygmeniu;
• organizacijos ar asmenys, kurie yra subrangovai įgyvendinant SCP ( Programinės įrangos projektų valdymas. - AB).

Asmenims reikia atsižvelgti:

• dalyvauja programinės įrangos projektuose, bet ne AP ( Projekto administratoriai. - AB);
• kurie yra ne programinės įrangos projektų administratoriai, bet susiję su AP programine įranga.

Palyginti trumpas pagrindinis tekstas (6 skyrius „Vadovas“ užima tik 9 puslapius iš 35) yra nuoseklus GOST R ISO/IEC 12207 proceso 7.1 „Valdymas“ komentaras PMBOK požiūriu. Komentavimo stilius yra neformalus, argumentai dažniausiai yra patariamojo pobūdžio. Komentaras neperžengia įprasto sveiko proto ribų ir neturi nieko naujo. Apskritai tai naudinga skaitymo projektų vadovams (vertėjų terminologija – „administratoriams“), bet nieko daugiau.

A priedas yra viena didelė lentelė, parodanti sąsajas tarp pagrindinių GOST R ISO/IEC 12207 procesų ir iš jų vadinamo „Valdymo“ proceso veiklos. Visos šios nuorodos yra GOST R ISO/IEC 12207 standarto turinyje; jas sujungus į vieną lentelę jokios naujos informacijos nepridedama.

B priedas yra lygiai tokia pati lentelė, susiejanti proceso sritis ir atskirus procesus iš PMBOK su „Valdymo“ proceso veikla pagal GOST R ISO/IEC 12207.

Panaši lentelė, kurioje vietoj sričių naudojamos proceso grupės PMBOK prasme, yra pateikta C priede. B ir C prieduose iš tikrųjų apibendrinama viskas, kas buvo pasakyta standarto 6 skyriuje. Kodėl reikėjo tai pateikti lentelių pavidalu, neaišku. Šios lentelės nepateikia jokios papildomos informacijos, tik parodo faktą, kad yra sąsajų tarp PMBOK ir GOST R ISO/IEC 12207. Tačiau abiejų priedų būsena yra „nuoroda“, todėl jie galėjo neturėti jokios nepriklausomos reikšmės.

Dar viena suvestinė lentelė pateikta D priede. Joje matyti trijų šaltinių ryšiai: GOST R ISO/IEC 12207, PMBOK ir ISO 10006 standartas Iš karto pažymėsiu, kad pastarasis į rusų kalbą išverstas tik 2005 m. dėl to GOST R ISO/IEC 16326 2002 standarto D priede vartojama terminija skiriasi nuo vėlesnės. Kaip ir ankstesniais atvejais, šių ryšių pateikimo kompaktiška lentelės forma prasmė neaiški. Be to, bendra A-D priedų apimtis daugiau nei du kartus viršija pagrindinio 6 skyriaus „Instrukcija“ apimtį.

Mano nuomone, GOST R ISO/IEC 16326-2002 forma ir paskirtimi nesiskiria nuo GOST R ISO/IEC 15271-2002. Abu jie kenčia nuo perteklinio samprotavimo, kuris yra teisingas „apskritai“ ir pagrįstas tik sveiku protu. Šie argumentai yra akivaizdūs kiekvienam, turinčiam praktinės projektų valdymo patirties, ir vargu ar atrodo pagrįsti tiems, kurie tokios patirties neturi. Priešingai nei GOST R ISO/IEC 15271-2002, GOST R ISO/IEC 16326-2002 standartas yra formalesnis, tačiau siūlomo formalizmo praktinė prasmė nėra aiški.

Praktinio pritaikymo projektuojant su IT susijusius verslo procesus požiūriu abu standartai iš esmės yra nenaudingi. Kita vertus, jie gali būti paklausūs įgyvendinant sudėtingus projektus, kurie kartu su IT valdymo praktikos studijomis apima projektų valdymo ir kokybės valdymas.

Be aukščiau aptartų, GOST R ISO/IEC 12207 sukūrė keletą standartų, kuriuose išsamiai aprašomi jame esantys standartai. gyvavimo ciklo procesai. Tai apima, pavyzdžiui, GOST R ISO/IEC 15910-2002 „Programinės įrangos vartotojo dokumentacijos kūrimo procesas“ (GOST 15910, 2002) ir GOST R ISO/IEC 14764-2002 „Programinės įrangos priežiūra“ (GOST 14764, 2002). . Kai kurie panašūs ISO standartai dar nebuvo išversti į rusų kalbą; Tikėtina, kad ateityje daugės rusakalbių GOST R ISO standartų, tiesiogiai susijusių su GOST R ISO/IEC 12207.

Bazinis lygis pagal GOST R ISO/IEC 12207-2010

arba kurie buvo oficialiai peržiūrėti ir vėliau naudojami kaip tolesnio tobulinimo pagrindas ir kuriuos galima pakeisti tik oficialiais ir kontroliuojamais pakeitimais [iš GOST R ISO/IEC 12207-2010 4.6 punkto]

Patvirtinimas pagal GOST R ISO/IEC 12207-2010

Patvirtinimas (remiantis objektyvių įrodymų pateikimu), kad numatytas tikslas arba taikymas buvo įvykdytas. Pastaba. Patvirtinimas kontekste yra veiksmų rinkinys, garantuojantis ir suteikiantis pasitikėjimo, kad jis gali įgyvendinti savo tikslą, esamą ir būsimą [iš GOST R ISO/IEC 12207-2010 4.54 punkto]

Patikra pagal GOST R ISO/IEC 12207-2010

Patvirtinimas (pagrįstas objektyvių įrodymų pateikimu), kad nurodyti reikalavimai buvo visiškai įvykdyti. PASTABA Patikrinimas kontekste – tai veiksmų rinkinys, kurio metu gyvavimo ciklo rezultatas lyginamas su reikiamomis to rezultato charakteristikomis. Gyvavimo ciklo rezultatai gali būti (bet tuo neapsiribojant) nurodyti reikalavimai, aprašymas ir tiesiogiai [iš GOST R ISO/IEC 12207-2010 4.55 punkto]

Kokybės užtikrinimas pagal GOST R ISO/IEC 12207-2010

Visa suplanuota ir sisteminga veikla, vykdoma pagal sistemą ir tinkamai parodyta, kad būtų užtikrintas pakankamas pasitikėjimas, kad klientas yra visiškai patenkintas.

1. Yra tiek vidinės, tiek išorinės kokybės garantijos:
   1. vidinis kokybės užtikrinimas: kokybės užtikrinimo ribose suteikia pasitikėjimo;
   2. Išorinis kokybės užtikrinimas: Sutartinėse situacijose kokybės užtikrinimas suteikia pasitikėjimo ar kitiems.
2. Kai kurios kokybės užtikrinimo ir kokybės užtikrinimo veiklos yra tarpusavyje susijusios.
3. Jei kokybės reikalavimai visiškai nepatenkina poreikių, kokybės užtikrinimas negali suteikti reikiamo užtikrinimo.

[iš GOST R ISO/IEC 12207-2010 4.34 punkto]

5.2.2 Gyvavimo ciklo procesų santrauka

Šiame standarte yra du svarbūs proceso skyriai. 6 skyriuje pateikiamas sistemos kontekstas, skirtas naudoti atskirą programinės įrangos produktą ar paslaugą arba programinės įrangos sistemą. 7 skirsnyje pateikiami konkretūs programinės įrangos procesai, naudojami diegiant programinės įrangos produktą ar paslaugą, kuri yra didesnės sistemos elementas.

Siekiant padėti vienu metu naudoti šį tarptautinį standartą, atitinkamiems 6 skirsnio procesams suteikiami tie patys poskyrio pavadinimai.

Apskritai šiame standarte pateiktas procesų rinkinys yra pritaikytas programinei įrangai arba įvesties į numatytų procesų rezultatus. Daugelis procesų yra panašūs į konkrečios programinės įrangos procesų įgyvendinimą, tačiau jie išlaiko svarbius skirtumus, pagrįstus tikslais, rezultatais ir auditorijomis. Šio standarto ir šio standarto naudotojai turėtų būtinai peržiūrėti kiekvieno tokio specifinio proceso paaiškinimus ir pastabas.

Sutarčių procesai apibrėžia veiklą, reikalingą susitarimams tarp dviejų organizacijų sudaryti. Jeigu įgyvendinamas įsigijimo procesas, tai suteikia galimybę vykdyti verslą su operacinėje sistemoje numatytų naudoti produktų tiekėju, sistemos palaikymo paslaugomis ar sistemos elementais, sukurtais kaip projekto dalis. Jei pristatymo procesas yra įgyvendinamas, jis suteikia galimybę įgyvendinti projektą, kurio rezultatas yra įsigyjančiajai šaliai pristatytas produktas ar paslauga.

Taigi šiame standarte pateikti sutarties procesai yra skirti programinės įrangos sutarties procesams nuo .

Organizacijos projektų palaikymo procesai valdo organizacijų gebėjimą įsigyti ir teikti produktus ar paslaugas inicijuojant, palaikant ir valdant projektą. Šie procesai suteikia išteklių ir infrastruktūros, reikalingos projektams palaikyti ir užtikrinti, kad būtų laikomasi organizacinių tikslų ir nustatytų susitarimų. Jie nepretenduoja į visą verslo procesų rinkinį, kuris įgyvendina organizacijos verslo veiklos valdymą.

Projekto organizacinio palaikymo procesai apima:

a) gyvavimo ciklo modelio valdymo procesas;

B) infrastruktūros valdymo procesas;

c) projektų portfelio valdymo procesas;

d) žmogiškųjų išteklių valdymo procesas;

e) kokybės valdymo procesas.

Apskritai šiame standarte numatyti projekto organizacinio palaikymo procesai yra procesai, orientuoti į programinę įrangą iš atitinkamo procesų rinkinio .

Šiame standarte projektas pasirinktas kaip pagrindas aprašant su planavimu, vertinimu ir kontrole susijusius procesus. Su šiais procesais susiję principai gali būti taikomi bet kuriai organizacijos valdymo sričiai.

Yra dvi projektų procesų kategorijos. Projektų valdymo procesai naudojami planuoti, vykdyti, įvertinti ir valdyti projekto eigą. Projektų palaikymo procesai užtikrina, kad būtų pasiekti specializuoti valdymo tikslai. Abi projektų procesų kategorijos aprašytos toliau.

Projektų valdymo procesai naudojami projektų planams kurti ir plėtoti, įvertinti faktinę pažangą ir pažangą, palyginti su planais, ir valdyti projekto pažangą iki pabaigos. Atskirų projektų valdymo procesai gali būti naudojami bet kuriuo gyvavimo ciklo metu ir bet kuriame projekto hierarchijos lygyje, reaguojant į projekto planus arba įvykus nenumatytiems įvykiams. Projekto valdymo procesai taikomi griežtai ir formaliai, atsižvelgiant į projekto riziką ir sudėtingumą:

a) projekto planavimo procesas;

b) projekto valdymo ir vertinimo procesą.

Projekto palaikymo procesai sudaro specifinį užduočių rinkinį, kuriuo siekiama konkrečių valdymo tikslų. Visi šie procesai yra akivaizdūs valdant bet kokią pradėtą ​​veiklą, nusileidžiant nuo visos organizacijos iki atskiro gyvavimo ciklo proceso ir jo uždavinių:

a) sprendimų valdymo procesas;

b) rizikos valdymo procesas;

c) konfigūracijos valdymo procesas;

d) informacijos valdymo procesas;

e) matavimo procesas.

Apskritai šiame standarte pateikti projektų paramos procesai yra identiški projektų palaikymo procesams, nurodytiems , išskyrus kai kuriuos jų pateikimo formos skirtumus. Kai kuriais atvejais programinės įrangos palaikymo procesai gali būti susiję su projekto palaikymo procesais.

Techniniai procesai naudojami sistemos reikalavimams apibrėžti, reikalavimus paversti naudingu produktu, leisti nuolat kopijuoti gaminį (jei reikia), pritaikyti produktą, teikti reikiamas paslaugas, palaikyti šių paslaugų teikimą ir pašalinti gaminį iš apyvartos, kai. jis nenaudojamas teikiant paslaugą.

Techniniai procesai apibrėžia veiklą, leidžiančią įgyvendinti organizacines ir projektavimo funkcijas, siekiant optimizuoti naudą ir sumažinti riziką, kylančią dėl techninių sprendimų ir veiksmų. Ši veikla leidžia produktams ir paslaugoms turėti savalaikiškumo ir prieinamumo, ekonomiškumo, funkcionalumo, patikimumo, techninės priežiūros, našumo, pritaikomumo ir kitas kokybės charakteristikas, kurių reikalauja įsigyjančios ir remiančios organizacijos. Taip pat produktai ir paslaugos atitinka civilinės teisės lūkesčius ar reikalavimus, įskaitant sveikatos, saugos, saugumo ir aplinkos veiksnius.

Techniniai procesai susideda iš šių procesų:

a) teisių turėtojų reikalavimų nustatymas (specialus teisių turėtojų reikalavimų nustatymo proceso atvejis nurodytas);

b) sistemos reikalavimų analizė (ypatingas reikalavimų analizės proceso atvejis);

C) sistemos architektūros projektavimas (specialus architektūros projektavimo proceso atvejis pateiktas);

D) diegimo procesas (specialus sistemos elementų diegimo proceso atvejis, pateiktas ir toliau plėtojamas šio standarto 7 skyriuje kaip programinės įrangos diegimo procesas);

e) sistemos integravimo procesas (specialus integravimo proceso atvejis, nurodytas);

f) sistemos kvalifikacijos testavimo procesas (procesas, padedantis pasiekti patikrinimo proceso, nurodyto ) rezultatų;

G) programinės įrangos diegimo procesas (procesas, padedantis pasiekti punkte aprašyto perdavimo proceso rezultatus);

H) programinės įrangos priėmimo palaikymo procesas (procesas, kuris prisideda prie perdavimo proceso rezultatų, aprašytų );

i) programinės įrangos veikimo procesas (ypač nurodytas veikimo proceso atvejis);

j) programinės įrangos priežiūros procesas (specialus priežiūros proceso atvejis, nurodytas );

k) programinės įrangos išėmimo iš apyvartos procesas (nurodytas specialus pašalinimo ir nurašymo proceso atvejis).

Apskritai šiame standarte pateikti techniniai procesai yra į programinę įrangą orientuoti specialūs atvejai arba indėlis į techninių procesų rezultatus, pateiktus . Dauguma jų yra panašūs į programinės įrangos diegimo procesus, tačiau išlaiko svarbius skirtumus, pavyzdžiui, sistemos reikalavimų analizė ir programinės įrangos reikalavimų analizė prasideda nuo skirtingų pradžios taškų ir turi skirtingą paskirtį.

Programinės įrangos diegimo procesai naudojami tam tikram sistemos elementui (komponentui), pagamintam programinės įrangos įrankio pavidalu, sukurti. Šie procesai paverčia nurodytą elgesį, sąsajas ir įgyvendinimo apribojimus į veiksmus, kurių rezultatas yra sistemos elementas, atitinkantis iš sistemos reikalavimų kylančius reikalavimus.

Ypatingas procesas yra programinės įrangos diegimo procesas, išreiškiantis tam tikrą diegimo proceso programinę įrangą.

Programinės įrangos diegimo procesas apima keletą specialių žemesnio lygio procesų:

a) programinės įrangos reikalavimų analizės procesas;

B) programinės įrangos architektūros projektavimo procesas;

c) detalus programinės įrangos projektavimo procesas;

d) programinės įrangos projektavimo procesas;

e) programinės įrangos integravimo procesas;

f) programinės įrangos kvalifikacijos testavimo procesas.

Programinės įrangos palaikymo procesai suteikia konkretų veiksmų rinkinį, skirtą specializuotam programinės įrangos procesui vykdyti. Bet koks pagalbinis procesas padeda įdiegti visą programinę įrangą, turinčią konkretų tikslą, ir prisideda prie programinės įrangos projekto sėkmės ir kokybės. Yra aštuoni tokie procesai:

a) programinės įrangos dokumentacijos valdymo procesas;

b) programinės įrangos konfigūracijos valdymo procesas;

c) programinės įrangos kokybės užtikrinimo procesas;

d) programinės įrangos tikrinimo procesas;

e) programinės įrangos patvirtinimo procesas;

f) programinės įrangos audito procesas;

g) programinės įrangos audito procesas;

H) problemų sprendimo procesas programinėje įrangoje.

Programinės įrangos pakartotinio naudojimo procesų grupę sudaro trys procesai, kurie palaiko organizacijos gebėjimą pakartotinai naudoti programinės įrangos komponentus peržengiant projekto ribas. Šie procesai yra unikalūs, nes dėl savo pobūdžio jie naudojami už bet kokio konkretaus projekto ribų.

Programinės įrangos pakartotinio naudojimo procesai yra šie:

a) domenų projektavimo procesas;

b) turto pakartotinio naudojimo valdymo procesas;

C) pakartotinio programos naudojimo valdymo procesas.

1) Leidžia įgyvendinti bet kokį gyvavimo ciklo modelį– tai įmanoma, nes Standartas suteikia galimybę apibrėžti procesų ir užduočių vykdymo tvarką, kurioje vienas procesas gali vadinti kitą procesą ar jo dalis.

2) Suteikia maksimalų lankstumą– daugelis procesų ir užduočių suprojektuoti taip, kad juos būtų galima pritaikyti pagal konkrečius IS projektus. Prisitaikymas reiškia procesų, veiklų ir užduočių, kurios nėra taikomos konkrečiam projektui, pašalinimą.

3) Standarte iš esmės nėra konkrečių veiksmų metodų aprašymo, ypač, ruošinius, sprendimus ar dokumentaciją, jame tik aprašoma programinės įrangos gyvavimo ciklo procesų architektūra, tačiau nėra detaliai nurodyta, kaip atlikti ar įgyvendinti į procesus įtrauktas užduotis.

4) Standarte yra labai mažai duomenų bazės dizaino aprašymų- tai pateisinama, nes skirtingos IS ir skirtingos programinės įrangos sistemos gali ne tik naudoti tam tikro tipo duomenų bazes, bet ir visai nenaudoti duomenų bazių.

5) Standarto reikšmė yra ta yra užduočių rinkiniai, kokybės charakteristikos, vertinimo kriterijai ir kt., teikianti visapusišką dizaino sprendimų aprėptį.

6) Nors standartas nenumato naudoti konkretaus gyvavimo ciklo modelio ar kūrimo metodo, jame nurodoma, kad projekto šalys yra atsakingos už:

kuriamo projekto gyvavimo ciklo modelio parinkimas;

standarto procesų ir užduočių pritaikymas pasirinktam modeliui;

programinės įrangos kūrimo metodų parinkimas ir taikymas;

Veiklos ir užduočių atlikimas, tinkamas tam tikram programinės įrangos projektui.

GOST 34 sudėtingi standartai.

Jis buvo sumanytas kaip išsamus tarpusavyje susijusių tarpsektorinių dokumentų rinkinys.

Standartizacijos objektai: įvairių tipų automatizuotos sistemos ir visų tipų jų komponentai.

GOST standartai numato darbo etapus ir etapus kuriant automatizuotą sistemą, tačiau aiškiai nenumato galutinių procesų, vykstančių gyvavimo ciklo įgyvendinimo metu.

Pagal GOST automatizuotos sistemos kūrimas yra padalintas į šiuos etapus ir etapus:

1 etapas reikalavimų garsiakalbiams formavimas:

a etapas: objekto apžiūra ir būtinybės sukurti automatizuotą sistemą pagrindimas;

B etapas: klientų reikalavimų automatizuotai sistemai formavimas;

c etapas: atliktų darbų ataskaitos rengimas ir paraiškos techninėms specifikacijoms rengti parengimas.

2 etapas koncepcijos kūrimas:

a: objekto tyrimas;

b: būtinų tyrimų atlikimas;

c: klientų reikalavimus atitinkančios AE koncepcijos variantų kūrimas;

d: atlikto darbo ataskaitos rengimas.

3 etapas branduolinių elektrinių kūrimo techninių specifikacijų rengimas ir tvirtinimas.

4 etapas AE preliminaraus projekto parengimas:

a: visos sistemos ir atskirų jos komponentų preliminaraus projektavimo sprendimų kūrimas;

b: dokumentacijos rengimas.

5 etapas techninio projekto rengimas:

a: visos sistemos ir jos dalių projektinių sprendimų kūrimas;

b: automatizuotos sistemos ir į ją įtrauktų posistemių dokumentacijos kūrimas;

c: gaminių tiekimo atominėms elektrinėms užbaigti arba šių produktų kūrimo techninių reikalavimų parengimas ir vykdymas.

6 etapas techninės dokumentacijos rengimas:

a: sistemos dalies darbinės dokumentacijos kūrimas;

b: programinės įrangos kūrimas arba pritaikymas.

7 etapassukurtos sistemos pradėjimas eksploatuoti:

a: automatizavimo objekto paruošimas AS diegimui;

b: personalo mokymas;

c: garsiakalbių aprūpinimas programine ir technine įranga;

d: montavimo darbai;

d: paleidimas;

e: preliminarūs testai;

g: bandomoji operacija;

h: priėmimo testai.

8 etapas palyda:

a: darbų atlikimas pagal garantinius įsipareigojimus;

b: pogarantinis aptarnavimas.