Dokumentacioni teknik. Dokumentacioni teknik Kryerja e testeve të pranimit

Shënim: Një vazhdim logjik i leksionit të mëparshëm. Problemi i aplikimit praktik të GOST R ISO/IEC 12207 në organizata dhe projekte është diskutuar në detaje. Në këtë drejtim, janë duke u studiuar standardet GOST R ISO/IEC 15271 dhe GOST R ISO/IEC 16326.

Nga leksioni i mëparshëm duhet të jetë e qartë se zbatimi i GOST R ISO/IEC 12207 është një detyrë shumë e vështirë. Para së gjithash, nuk është e qartë se çfarë do të thotë "zbatimi i GOST R ISO/IEC 12207"? A mund të konsiderohet i zbatuar nëse disa nga proceset e organizatës përkojnë me proceset e standardit, dhe disa jo? A mund të konsiderohet një standard i zbatuar nëse disa projekte kryhen në përputhje me të, dhe të tjerët jo? Kjo listë pyetjesh mund të vazhdojë pa pushim.

Nuk është rastësi që duke ndjekur GOST R ISO/IEC 12207, standardi GOST R ISO/IEC 15271-02 (GOST 15271, 2002) u zhvillua posaçërisht për detyrën e zbatimit të tij, i cili quhet "Udhëzime për zbatimin e GOST R ISO/IEC 12207”. Tani do të vazhdojmë ta shqyrtojmë atë.

Standardi GOST R ISO/IEC 15271

Kuptimi i standardit zbulohet në seksionin e tij hyrës.

"1.2 Përdoruesit e standardit.

Ky standard mund të përdoret nga subjektet (individë, organizata) që dëshirojnë të zbatojnë GOST R ISO/IEC 12207 gjatë zbatimit të kontratave, pavarësisht nga vëllimi ose kompleksiteti i projektit, nga një organizatë specifike për punë vetë-monitoruese ose përmirësimi. proceset e ciklit jetësor mjete softuerike.

Ky standard specifikon se si mund të përdoret GOST R ISO/IEC 12207 në lidhje me lloje të ndryshme softuerësh dhe cilat procese janë të përshtatshme për secilin rast.

Ky standard plotëson GOST R ISO/IEC 12207, i cili nuk është vetëm një dokument normativ, por edhe një standard për menaxhimin e një projekti real. (Për shembull, rasti i fundit ndodh kur GOST R ISO/IEC 12207 është një model për kryerjen e një pjese të punës së procesit të përmirësimit). Ky standard duhet lexuar në tërësi, por seksione specifike mund të përdoren në raste individuale."

Standardi GOST R ISO/IEC 15271 përbëhet nga 8 seksione dhe 4 shtojca. Seksionet e përmbajtjes quhen si më poshtë (numërimi i marrë nga teksti):

• 4. Konceptet bazë të zhvillimit të GOST R ISO/IEC 12207.
• 5. Zbatimi i GOST R ISO/IEC 12207.
• 6. Aplikimi në projekte.
• 7. Aplikimi në organizata.
• 8. Aplikimi modelet e ciklit jetësor sistemeve.

Seksioni 4 është shkruar në stilin e komenteve dhe sqarimeve për tekstin e GOST R ISO/IEC 12207. Sqarimet më të rëndësishme kanë të bëjnë me ndërveprimin e GOST R ISO/IEC 12207 me standardet e korporatës së organizatës, dallimin midis koncepteve të " software" dhe "sistemi" dhe dallimet që rezultojnë midis proceseve që lidhen me softuerin dhe sistemet. Koncepti është përshkruar në detaje menaxhimin e cilësisë, zbatuar në GOST R ISO/IEC 12207. Në përgjithësi, seksioni jep përshtypjen e një pasqyre të shkurtër konceptuale të GOST R ISO/IEC 12207, që të kujton një tekst shkollor.

Seksioni 5 paraqet një qasje të përgjithshme ndaj zbatimit, të quajtur strategjia e zbatimit GOST R ISO/IEC 12207. Një strategji, sipas standardit, është "një metodë tipike zbatimi që duhet ndjekur kur bëhen ndryshime në aktivitetet ose projektin e një organizate." Strategjia zbatohet si një projekt i përbërë nga hapa të detyrueshëm, të përshkruar në mënyrë joformale dhe pa asnjë lidhje me proceset e organizatës. Këto hapa janë si më poshtë:

• a) zhvillimi i një plani zbatimi;
• b) aplikimi praktik i GOST R ISO/IEC 12207;
• c) ofrimin e mbështetjes projekt pilot(s);
• d) formalizimi i metodës së zbatimit;
• e) miratimin e metodës së zbatimit.

Zhvillimi i një plani zbatimi përfshin përcaktimin e fushës së zbatimit të GOST R ISO/IEC 12207. Objekti mund të jetë, për shembull, një grup departamentesh ose projekte të një organizate. Ju gjithashtu mund të përcaktoni fushëveprimin e aplikimit si një grup procesesh kyçe për organizatën, të cilat do të zëvendësohen me procese nga GOST R ISO/IEC 12207. Vetë plani i zbatimit përcakton përbërjen e projekteve të kryera gjatë zbatimit (mund të ketë disa prej tyre). Vetëkuptohet që gjatë zhvillimit të një plani zbatimi përcaktohen burimet e nevojshme: financiare, njerëzore, teknike etj.

Në zbatim praktik, siç mund të pritej, propozohet të përdoret procesi i përshtatjes i përshkruar në vetë GOST R ISO/IEC 12207.

Vetë strategjia nuk ngre pyetje - një sekuencë e tillë hapash mund të jetë mjaft efektive në kushte specifike, por vlen të përmendet se qasja formale e projektit për zbatimin e GOST R ISO/IEC 12207 bazohet në një kuptim të thjeshtuar të realitetit. situatë. Duke marrë parasysh që proceset e një organizate (si dhe struktura e saj organizative) po ndryshojnë vazhdimisht, besoj se do të ishte metodologjikisht më korrekte ta konsideronim zbatimin e një standardi si një proces të vazhdueshëm, sesa si një projekt të kufizuar në kohë. Ky proces monitoron ndryshimet në proceset e organizatës dhe fillon projekte individuale, për shembull:

• projekte për aplikimin e GOST R ISO/IEC 12207;
• një projekt për të trajnuar të gjithë punonjësit e rinj në proceset e GOST R ISO/IEC 12207;
• një projekt për futjen e ndryshimeve në proceset e zbatuara në lidhje me ndryshimet në strukturën organizative të organizatës; e kështu me radhë.

Qasja ndaj zbatimit të GOST R ISO/IEC 12207 si një proces, veçanërisht nëse synohet të fillojë me aplikimin e tij në projekte ose departamente individuale të organizatës, do të lejojë përqendrimin e përgjegjësisë për rezultatin e përgjithshëm në duart e pronarit të procesit. , do të bëjë të mundur vendosjen e monitorimit të përgjithshëm të rezultateve, etj. Është e qartë se zbatimi duhet të pasohet nga mbështetja e proceseve të zbatuara, e cila organizohet natyrshëm edhe si proces.

Më shumë detaje rreth përdorimit të GOST R ISO/IEC 12207 në projekte përshkruhen në seksionin 6 "Aplikimi në projekte". Standardi propozon klasifikimin e projekteve dhe për këtë qëllim prezanton një koncept të ri - " modeli i ciklit jetësor sistemet" (një listë e modeleve tipike jepet në Shtojcën C). Çfarë është një model nuk është përcaktuar zyrtarisht. Më vonë, Seksioni 8 thotë se "e përgjithshme modeli i ciklit jetësor sistemet ndahen në faza (faza) me përshtatjen e mëvonshme të secilit prej tyre modelet e ciklit jetësor sistem specifik" (më poshtë është një listë fazash). Gjithsej konsiderohen tre modele të tilla: kaskadë, rritëse, evolucionare. Analizohen avantazhet dhe disavantazhet e tyre dhe më pas proceset e GOST R ISO/IEC 12207 "mbivendosen" mbi strukturën e modeleve. Si rezultat, këto procese marrin veti shtesë, për shembull, përsëritje të përsëritur në ciklin jetësor ose mbivendosje kohore me procese të tjera. Përveç kësaj, seksioni përmban shumë rekomandime të shkallëve të ndryshme të dobisë në lidhje me individin. aspektet e projekteve Ja një shembull tipik.

“6.1.3 Karakteristikat e sistemit

Nënsistemet dhe elementët e konfigurimit të sistemit duhet të përcaktohen në nivelin e duhur të detajeve. Është e nevojshme të përcaktohen karakteristikat e sistemit, veçanërisht ato që lidhen me softuerin. Gjatë përcaktimit të këtyre karakteristikave, është e nevojshme të theksohet se cilat prej tyre janë kritike gjatë funksionimit të sistemit.

Një listë treguese e karakteristikave të nivelit të sistemit (të lidhura me softuerin dhe që i nënshtrohen shqyrtimit) përfshin:

• ndërfaqet ndër-sistem dhe brenda sistemit;
• ndërfaqet e përdoruesit;
• ndikimi i gabimeve të softuerit në mbrojtjen dhe siguria e sistemit;
• vlerësimi i fuqisë kompjuterike dhe kufizimeve kohore;
• disponueshmëria e programeve të zbatuara me mjete teknike;
• Disponueshmëria e kompjuterëve të përshtatshëm.

Nëse një sistem përfshin shumë nënsisteme ose elementë konfigurimi, ato duhet të mbulohen plotësisht nga puna në nivel sistemi që nga procesi i zhvillimit. Duhet të merren parasysh të gjitha kërkesat për ndërfaqet dhe montimin (integrimin) e sistemeve. Për një sistem të vogël, një sekuencë kaq e rreptë veprimesh mund të mos jetë e nevojshme."

Formulimi i përafërt dhe i paqartë në pasazhin e mësipërm është karakteristik për të gjithë standardin në tërësi.

Pjesa qendrore e seksionit shumë të shkurtër 7 “Aplikimi në organizata” është teksti i mëposhtëm.

“7.2 Mundësitë e aplikimit

Arsyet pse GOST R ISO/IEC 12207 zbatohet në organizata mund të jenë si më poshtë:

• duke kontrolluar përsosmërinë e një metode ekzistuese. Ky është zakonisht rasti kur metoda është zhvilluar nga vetë organizata ose ajo ka zgjedhur dhe modifikuar një metodë ekzistuese;
• aplikimi praktik i kësaj metode për të parandaluar rrezikun që lidhet me hyrjen në sektorë të rinj të tregut me kërkesa më të rrepta që lidhen me rrezikun e mundshëm;
• zhvillimi i një metode të re, për shembull për të përmbushur nevojat e një organizate të re. Organizatat e krijuara përmes një bashkimi ose bashkëpunimi biznesi mund të mbulohen. Kjo mund të jetë e nevojshme për të mbështetur disa modele procesi për ofrimin e një pune specifike;
• Menaxhimi i zbatimit të teknologjisë së re, si automatizimi i proceseve manuale ose ndryshimi i metodave të përdorura për zbatimin e një produkti softuerësh. GOST R ISO/IEC 12207 përcakton kriteret që mund të përdoren për të monitoruar përsosmërinë e metodës përkatëse përpara ose pas një ndryshimi në teknologji;
• vlerësimi i aftësive të brendshme të palës në drejtim të përmbushjes së kritereve të kontratës, për shembull, si palë pjesëmarrëse në procesin konkurrues (tender);
• identifikimi i momenteve që mund të çojnë në zhvillimin e programeve më të avancuara, të tilla si auditimi në përputhje me GOST R ISO/IEC 12207 dhe përdorimi i vetë procesit të përmirësimit."

Edhe në mungesë të plotë të kundërshtimeve thelbësore, është ende e pamundur të konsiderohet ky tekst si standard. Mbi të gjitha, ai i ngjan një manuali trajnimi dhe ndoshta do të jetë i kërkuar si i tillë, por një tekst i tillë nuk mund të përdoret si një udhëzues për veprim kur zbatohet GOST R ISO/IEC 12207 në një organizatë.

Më në fund, seksioni 8 "Aplikimi modelet e ciklit jetësor sistemet" përmban përkufizime mjaft të paqarta" modelet e ciklit jetësor sistemet" dhe " modelet e ciklit jetësor software" dhe përpiqet të krijojë një korrespondencë midis tyre. Meqenëse nuk ka përkufizime të sakta, është e pamundur të gjykohen rezultatet.

Në përgjithësi, standardi GOST R ISO/IEC 15271 jep përshtypjen se është një dokument thjesht ndihmës në lidhje me GOST R ISO/IEC 12207, që vuan nga përafërsia dhe një bollëk gjërash të zakonshme. Është e papërshtatshme për menaxherët praktikë - ka shumë arsyetim abstrakt dhe shumë pak specifikë. Për studentët dhe specialistët që studiojnë proceset e menaxhimit të IT, i mungon një pamje e gjerë e temës (në fund të fundit, ajo është e kufizuar nga GOST R ISO/IEC 12207) dhe është e mbingarkuar me detaje teknike të panevojshme. Sidoqoftë, njohja me GOST R ISO/IEC 15271 është e dobishme, pasi tregon drejtimin e mendimit të specialistëve në fushën e menaxhimit të IT dhe tregon se ku dhe si po zhvillohen standardet moderne. Unë do ta shihja atë si një dokument pune të përkohshëm, megjithëse në formën e një standardi, por të destinuar më shumë për diskutim midis një auditori të interesuar specialistësh të menaxhimit të IT.

Standardi GOST R ISO/IEC 16326

Një përpjekje tjetër për të zyrtarizuar procesin e aplikimit të GOST R ISO/IEC 12207 u bë në standardin GOST R ISO/IEC 16326 "Udhëzime për përdorimin e GOST R ISO/IEC 12207 në menaxhimin e projektit" (GOST 16326, 2002). Ajo tregon një përpjekje për t'u bashkuar proceset e ciklit jetësor nga GOST R ISO/IEC 12207 me proceset e menaxhimit të projektit nga libri popullor i referencës metodologjike PMBOK 1 PMBOK - Trupi i njohurive për Menaxhimin e Projektit(PMBOK, 2009) dhe standardin ISO 10006 (versioni rus i standardit përmbahet në (GOST 10006, 2005)). Kjo është paraqitur në mënyrë skematike në Fig. 4.1 dhënë në standard.

Oriz. 4.1.

Gama e përdoruesve të standardit është përcaktuar mjaft saktë në seksionin 1.1.

"1.1 Gama e përdoruesve

Ky standard është menduar për subjektet që përdorin ose planifikojnë të përdorin GOST R ISO/IEC 12207 në projektet softuerike, pavarësisht nga qëllimi, produktet e krijuara, metodologjia, vëllimi ose kompleksiteti i tyre. Standardi është menduar kryesisht për administratorët e projektit përgjegjës për pajtueshmërinë e proceseve të menaxhimit me GOST R ISO/IEC 12207:

• administratorët përgjegjës për organizimin dhe përmirësimin e vazhdueshëm proceset e ciklit jetësor softuer sipas GOST R ISO/IEC 12207;
• administratorët përgjegjës për aplikimin proceset e ciklit jetësor softuer sipas GOST R ISO/IEC/12207 në nivelin e projektimit;
• organizata ose persona që janë nënkontraktorë në zbatimin e SCP ( Menaxhimi i projekteve softuerike. - AB).

Konsideratat për individët përfshijnë:

• të përfshirë në projekte softuerike, por jo në AP ( Administratorët e projektit. - AB);
• të cilët janë administratorë të projekteve jo-softuerike, por të lidhur me softuerin AP."

Teksti kryesor relativisht i shkurtër (seksioni 6 "Udhëzuesi" zë vetëm 9 faqe nga gjithsej 35) është një koment vijues i procesit 7.1 "Menaxhimi" nga GOST R ISO/IEC 12207 nga pikëpamja PMBOK. Stili i komentimit është joformal, argumentet janë kryesisht të natyrës këshilluese. Komenti nuk shkon përtej sensit të zakonshëm të zakonshëm dhe nuk përmban asgjë të re. Në përgjithësi, ky është lexim i dobishëm për menaxherët e projektit (në terminologjinë e përkthyesve, "administratorët"), por asgjë më shumë.

Shtojca A është një tabelë e madhe që tregon lidhjet midis proceseve kryesore të GOST R ISO/IEC 12207 dhe aktiviteteve të procesit të "Menaxhimit" të thirrur prej tyre. Të gjitha këto lidhje janë të përfshira në trupin e standardit GOST R ISO/IEC 12207; kombinimi i tyre në një tabelë nuk shton ndonjë informacion të ri.

Shtojca B është saktësisht e njëjta tabelë që lidh zonat e procesit dhe proceset individuale nga PMBOK me aktivitetet e procesit të "Menaxhimit" nga GOST R ISO/IEC 12207.

Një tabelë e ngjashme, ku grupet e procesit në kuptimin PMBOK përdoren në vend të zonave, jepet në Shtojcën C. Shtojcat B dhe C në fakt përmbledhin gjithçka që u tha në seksionin 6 të standardit. Pse ishte e nevojshme të paraqitej kjo në formën e tabelave është e paqartë. Këto tabela nuk ofrojnë asnjë informacion shtesë, duke demonstruar vetëm faktin se ka lidhje midis PMBOK dhe GOST R ISO/IEC 12207. Megjithatë, statusi i të dy anekseve është "referencë", kështu që ato mund të mos kenë pasur ndonjë vlerë të pavarur.

Një tabelë tjetër përmbledhëse është paraqitur në Shtojcën D. Ajo tregon marrëdhëniet midis tre burimeve: GOST R ISO/IEC 12207, PMBOK dhe standardi ISO 10006. Do të vërej menjëherë se ky i fundit është përkthyer në Rusisht vetëm në 2005; si pasojë, terminologjia e përdorur në Shtojcën D të standardit GOST R ISO/IEC 16326 2002 ndryshon nga ajo e mëvonshme. Si në rastet e mëparshme, kuptimi i paraqitjes së këtyre marrëdhënieve në formë kompakte tabelare është i paqartë. Për më tepër, vëllimi i përgjithshëm i Shtojcave A-D e tejkalon vëllimin e seksionit kryesor 6 "Manual" me më shumë se dy herë.

Sipas mendimit tim, GOST R ISO/IEC 16326-2002 nuk ndryshon në formë dhe qëllim nga GOST R ISO/IEC 15271-2002. Të dy vuajnë nga një teprim arsyetimi që është i saktë “në përgjithësi” dhe i bazuar vetëm në sensin e shëndoshë. Këto argumente janë të dukshme për këdo që ka përvojë praktike në menaxhimin e projekteve dhe vështirë se duken të arsyeshme për ata që nuk kanë përvojë të tillë. Ndryshe nga GOST R ISO/IEC 15271-2002, standardi GOST R ISO/IEC 16326-2002 është më formal, por kuptimi praktik i formalizmit të propozuar nuk është i qartë.

Nga pikëpamja e zbatimit praktik në hartimin e proceseve të biznesit të lidhura me TI, të dy standardet janë kryesisht të padobishme. Nga ana tjetër, ato mund të jenë të kërkuara gjatë zbatimit të projekteve komplekse që përfshijnë, së bashku me një studim të praktikave të menaxhimit të IT, analizën e menaxhimit të projektit dhe menaxhimin e cilësisë.

Përveç atyre të diskutuara më sipër, GOST R ISO/IEC 12207 ka lindur një sërë standardesh që detajojnë ato që përmbahen në të. proceset e ciklit jetësor. Këto përfshijnë, për shembull, GOST R ISO/IEC 15910-2002 "Procesi i krijimit të dokumentacionit të përdoruesit për softuer" (GOST 15910, 2002) dhe GOST R ISO/IEC 14764-2002 "Mirëmbajtja e softuerit" (GOST 14764, 2002) . Disa standarde të ngjashme ISO nuk janë përkthyer ende në Rusisht; Ka të ngjarë që në të ardhmen të rritet numri i standardeve në gjuhën ruse GOST R ISO që lidhen drejtpërdrejt me GOST R ISO/IEC 12207.

Vija bazë sipas GOST R ISO/IEC 12207-2010

ose, të cilat janë rishikuar zyrtarisht dhe më pas shërbejnë si bazë për zhvillim të mëtejshëm, dhe që mund të ndryshohen vetëm nëpërmjet ndryshimeve zyrtare dhe të kontrolluara [nga pika 4.6 e GOST R ISO/IEC 12207-2010]

Vleresimi sipas GOST R ISO/IEC 12207-2010

Vërtetim (bazuar në paraqitjen e provave objektive) se qëllimi ose aplikimi i synuar është realizuar. Shënim - Vleresimi në kontekst është një grup veprimesh që garantojnë dhe sigurojnë besimin se ai është në gjendje të realizojë qëllimin e tij, aktual dhe të ardhshëm [nga pika 4.54 e GOST R ISO/IEC 12207-2010]

Verifikimi sipas GOST R ISO/IEC 12207-2010

Vërtetim (bazuar në sigurimin e provave objektive) se kërkesat e specifikuara janë përmbushur plotësisht. SHËNIM Verifikimi në kontekst është një grup veprimesh që krahasojnë një rezultat të ciklit jetësor me karakteristikat e kërkuara për atë rezultat. Rezultatet e ciklit jetësor mund të jenë (por nuk kufizohen në) kërkesat e specifikuara, përshkrimi dhe drejtpërdrejt [nga pika 4.55 e GOST R ISO/IEC 12207-2010]

Sigurimi i cilësisë sipas GOST R ISO/IEC 12207-2010

Të gjitha aktivitetet e planifikuara dhe sistematike të kryera brenda kornizës dhe të demonstruara në mënyrë të përshtatshme për të siguruar besimin e duhur se klienti është plotësisht i kënaqur.

1. Ekzistojnë garanci të cilësisë së brendshme dhe të jashtme:
   1. sigurimi i brendshëm i cilësisë: brenda kufijve të sigurimit të cilësisë ofron besim;
   2. Sigurimi i jashtëm i cilësisë: Në situata kontraktuale, sigurimi i cilësisë ofron besim ose për të tjerët.
2. Disa aktivitete të sigurimit të cilësisë dhe të sigurimit të cilësisë janë të ndërlidhura.
3. Nëse kërkesat e cilësisë nuk plotësojnë plotësisht nevojat, sigurimi i cilësisë nuk mund të sigurojë sigurinë e nevojshme.

[nga pika 4.34 GOST R ISO/IEC 12207-2010]

5.2.2 Përmbledhje e proceseve të ciklit jetësor

Ekzistojnë dy ndarje të rëndësishme të procesit në këtë standard. Seksioni 6 ofron kontekstin e sistemit për funksionimin e një produkti ose shërbimi softuerik të pavarur, ose një sistemi softuerësh. Seksioni 7 përmban procese specifike softuerike për përdorim në zbatimin e një produkti ose shërbimi softuerësh që është një element i një sistemi më të madh.

Për të ndihmuar në përdorimin e njëkohshëm të këtij standardi ndërkombëtar, proceseve përkatëse të pikës 6 u jepen të njëjtat përcaktime të nënklauzolave.

Në përgjithësi, grupi i proceseve të paraqitura në këtë standard është i përshtatur me softuerin ose inputet për rezultatet e proceseve të parashikuara. Shumë procese janë të ngjashme me implementimet e proceseve specifike të softuerit, por ato ruajnë dallime të rëndësishme bazuar në qëllimet, rezultatet dhe audiencat. Përdoruesit si të këtij standardi ashtu edhe të këtij standardi duhet të jenë të sigurt që të rishikojnë shpjegimet dhe shënimet në secilin proces të tillë specifik.

Proceset e marrëveshjes përcaktojnë aktivitetet e nevojshme për të zhvilluar marrëveshje ndërmjet dy organizatave. Nëse zbatohet një proces blerjeje, ai siguron mjetet për të kryer biznes me furnizuesin e produkteve të ofruara për përdorim në sistemin operativ, shërbimet mbështetëse të sistemit ose elementët e sistemit të zhvilluara si pjesë e projektit. Nëse zbatohet një proces shpërndarjeje, ai siguron mjetet për të realizuar një projekt në të cilin rezultati është një produkt ose shërbim i dorëzuar palës blerëse.

Kështu, proceset e marrëveshjes të dhëna në këtë standard synojnë proceset e marrëveshjes së softuerit nga .

Proceset e mbështetjes së projekteve organizative menaxhojnë aftësinë e organizatave për të blerë dhe ofruar produkte ose shërbime përmes inicimit, mbështetjes dhe menaxhimit të projektit. Këto procese ofrojnë burimet dhe infrastrukturën e nevojshme për të mbështetur projektet dhe për të siguruar që qëllimet organizative dhe marrëveshjet e vendosura janë përmbushur. Ata nuk pretendojnë të jenë një grup i plotë i proceseve të biznesit që zbatojnë menaxhimin e aktiviteteve të biznesit të një organizate.

Proceset e mbështetjes organizative të projektit përfshijnë:

a) procesi i menaxhimit të modelit të ciklit jetësor;

B) procesi i menaxhimit të infrastrukturës;

c) procesi i menaxhimit të portofolit të projektit;

d) procesin e menaxhimit të burimeve njerëzore;

e) procesi i menaxhimit të cilësisë.

Në përgjithësi, proceset e mbështetjes organizative të projektit të parashikuara nga ky standard janë procese të fokusuara në softuer nga grupi përkatës i proceseve në.

Në këtë standard, projekti zgjidhet si bazë për përshkrimin e proceseve që lidhen me planifikimin, vlerësimin dhe kontrollin. Parimet që lidhen me këto procese mund të zbatohen në çdo fushë të menaxhimit organizativ.

Ekzistojnë dy kategori të proceseve të projektit. Proceset e menaxhimit të projektit përdoren për të planifikuar, ekzekutuar, vlerësuar dhe menaxhuar progresin e një projekti. Proceset e mbështetjes së projektit sigurojnë që objektivat e specializuara të menaxhimit janë përmbushur. Të dyja kategoritë e proceseve të projektit janë përshkruar më poshtë.

Proceset e menaxhimit të projektit përdoren për të krijuar dhe zhvilluar planet e projektit, për të vlerësuar progresin dhe progresin aktual kundrejt planeve dhe për të menaxhuar progresin e projektit deri në përfundim. Proceset individuale të menaxhimit të projektit mund të thirren në çdo kohë të ciklit jetësor dhe në çdo nivel të hierarkisë së projektit në përgjigje të planeve të projektit ose shfaqjes së ngjarjeve të paparashikuara. Proceset e menaxhimit të projektit zbatohen në një nivel rigoroziteti dhe formalizimi në varësi të rrezikut dhe kompleksitetit të projektit:

a) procesi i planifikimit të projektit;

b) procesin e menaxhimit dhe vlerësimit të projektit.

Proceset e mbështetjes së projektit formojnë një grup specifik detyrash që synojnë arritjen e qëllimeve specifike të menaxhimit. Të gjitha këto procese janë të dukshme në menaxhimin e çdo aktiviteti të nisur, duke zbritur nga organizata në tërësi deri në një proces të veçantë të ciklit jetësor dhe detyrat e tij:

a) procesi i menaxhimit të vendimeve;

b) procesin e menaxhimit të rrezikut;

c) procesi i menaxhimit të konfigurimit;

d) procesi i menaxhimit të informacionit;

e) procesi i matjes.

Në përgjithësi, proceset e mbështetjes së projektit të paraqitura në këtë standard janë identike me proceset e mbështetjes së projektit të dhëna në , me përjashtim të disa dallimeve në formën e paraqitjes së tyre. Në disa raste, proceset e mbështetjes së softuerit mund të kenë lidhje me proceset e mbështetjes së projektit.

Proceset teknike përdoren për të përcaktuar kërkesat e sistemit, për të transformuar kërkesat në një produkt të dobishëm, për të lejuar kopjimin e vazhdueshëm të produktit (kur është e nevojshme), për të aplikuar produktin, për të ofruar shërbimet e kërkuara, për të ruajtur ofrimin e këtyre shërbimeve dhe për të hequr produktin nga qarkullimi kur nuk perdoret ne ofrimin e sherbimit..

Proceset teknike përcaktojnë aktivitetet që mundësojnë zbatimin e funksioneve organizative dhe të projektimit për të optimizuar përfitimet dhe për të zvogëluar rreziqet që rrjedhin nga vendimet dhe veprimet teknike. Këto aktivitete mundësojnë që produktet dhe shërbimet të kenë karakteristikat e kohës dhe disponueshmërisë, kosto-efektivitetit, funksionalitetit, besueshmërisë, mirëmbajtjes, produktivitetit, përshtatshmërisë dhe karakteristikave të tjera cilësore të kërkuara nga organizatat blerëse dhe mbështetëse. Ai gjithashtu mundëson që produktet dhe shërbimet të përmbushin pritshmëritë ose kërkesat e ligjit civil, duke përfshirë shëndetin, sigurinë, sigurinë dhe faktorët mjedisorë.

Proceset teknike përbëhen nga proceset e mëposhtme:

a) përcaktimi i kërkesave të mbajtësve të të drejtave (rast i veçantë i procesit të përcaktimit të kërkesave të mbajtësve të të drejtave të dhëna në);

b) analiza e kërkesave të sistemit (një rast i veçantë i procesit të analizës së kërkesave);

C) dizajni i arkitekturës së sistemit (një rast i veçantë i procesit të projektimit të arkitekturës i dhënë në);

D) procesi i zbatimit (një rast i veçantë i procesit të zbatimit të elementit të sistemit i dhënë dhe i zhvilluar më tej në seksionin 7 të këtij standardi si procesi i zbatimit të softuerit);

e) procesi i integrimit të sistemit (një rast i veçantë i procesit të integrimit të dhënë në);

f) procesin e testimit të kualifikimit të sistemit (një proces që kontribuon në arritjen e rezultateve të procesit të verifikimit të dhënë në );

G) procesi i instalimit të softuerit (procesi që kontribuon në arritjen e rezultateve të procesit të transferimit të përshkruar në);

H) procesi i mbështetjes së pranimit të softuerit (procesi që kontribuon në arritjen e rezultateve të procesit të transferimit të përshkruar në );

i) procesi i funksionimit të softuerit (një rast i veçantë i procesit të funksionimit të dhënë në);

j) procesi i mirëmbajtjes së softuerit (një rast i veçantë i procesit të mirëmbajtjes dhënë në );

k) procesi i tërheqjes së softuerit nga qarkullimi (një rast i veçantë i procesit të tërheqjes dhe fshirjes së dhënë).

Në përgjithësi, proceset teknike të paraqitura në këtë standard janë raste të veçanta të orientuara drejt softuerit ose kontribute në rezultatet e proceseve teknike të paraqitura në. Shumica e tyre janë të ngjashme me proceset e zbatimit të softuerit, por ruajnë dallime të rëndësishme, për shembull, analiza e kërkesave të sistemit dhe analiza e kërkesave të softuerit fillojnë nga pika të ndryshme fillestare dhe kanë qëllime të ndryshme.

Proceset e zbatimit të softuerit përdoren për të krijuar një element specifik të sistemit (komponent) të bërë në formën e një vegle softuerike. Këto procese transformojnë sjelljet e specifikuara, ndërfaqet dhe kufizimet e zbatimit në veprime që rezultojnë në një element të sistemit që plotëson kërkesat që rrjedhin nga kërkesat e sistemit.

Një proces i veçantë është procesi i zbatimit të softuerit, duke shprehur një veçori specifike softuerike të procesit të zbatimit të dhënë në.

Procesi i zbatimit të softuerit përfshin disa procese speciale të nivelit më të ulët:

a) procesi i analizimit të kërkesave të softuerit;

B) procesi i projektimit të arkitekturës së softuerit;

c) procesi i detajuar i projektimit të softuerit;

d) procesi i projektimit të softuerit;

e) procesi i integrimit të softuerit;

f) procesi i testimit të kualifikimit të softuerit.

Proceset e mbështetjes së softuerit ofrojnë një grup aktivitetesh të fokusuara në mënyrë specifike që synojnë ekzekutimin e një procesi të specializuar softuerësh. Çdo proces mbështetës ndihmon procesin e zbatimit të softuerit në tërësi me një qëllim të veçantë, duke kontribuar në suksesin dhe cilësinë e projektit të softuerit. Ekzistojnë tetë procese të tilla:

a) procesi i menaxhimit të dokumentacionit të softuerit;

b) procesi i menaxhimit të konfigurimit të softuerit;

c) procesi i sigurimit të cilësisë së softuerit;

d) procesi i verifikimit të softuerit;

e) procesi i vlefshmërisë së softuerit;

f) procesi i auditimit të softuerit;

g) procesi i auditimit të softuerit;

H) procesi i zgjidhjes së problemeve në softuer.

Grupi i procesit të ripërdorimit të softuerit përbëhet nga tre procese që mbështesin aftësinë e një organizate për të ripërdorur komponentët e softuerit përtej kufijve të projektit. Këto procese janë unike sepse, për nga natyra e tyre, ato përdoren jashtë kufijve të çdo projekti specifik.

Proceset e ripërdorimit të softuerit janë:

a) procesi i projektimit të domenit;

b) procesi i menaxhimit të ripërdorimit të aseteve;

C) procesi i menaxhimit të ripërdorimit të programit.

1) Ju lejon të zbatoni çdo model të ciklit jetësor- kjo është e mundur, sepse Standardi ofron një mënyrë për të përcaktuar rendin e ekzekutimit të proceseve dhe detyrave, në të cilën një proces mund të thërrasë një proces tjetër ose pjesë të tij.

2) Ofron fleksibilitet maksimal– shumë procese dhe detyra janë të dizajnuara në atë mënyrë që ato të mund të përshtaten në përputhje me projektet specifike të IS. Përshtatja zbret në eliminimin e proceseve, aktiviteteve dhe detyrave që nuk janë të zbatueshme për një projekt specifik.

3) Standardi nuk përmban në thelb një përshkrim të metodave specifike të veprimit, veçanërisht, boshllëqet, zgjidhjet ose dokumentacioni, ai përshkruan vetëm arkitekturën e proceseve të ciklit jetësor të softuerit, por nuk specifikon në detaje se si të kryhen ose zbatohen detyrat e përfshira në procese.

4) Standardi përmban shumë pak përshkrime në lidhje me hartimin e bazës së të dhënave- kjo është e justifikuar, sepse IS të ndryshme dhe sisteme të ndryshme softuerike jo vetëm që mund të përdorin lloje specifike të bazave të të dhënave, por gjithashtu nuk mund të përdorin fare baza të të dhënave.

5) Vlera e standardit është se ai përmban grupe detyrash, karakteristika cilësore, kritere vlerësimi etj., duke ofruar mbulim të plotë të zgjidhjeve të projektimit.

6) Megjithëse standardi nuk përshkruan përdorimin e një modeli specifik të ciklit jetësor ose metodës së zhvillimit, ai përcakton që palët e projektit janë përgjegjëse për sa vijon:

përzgjedhja e një modeli të ciklit jetësor për projektin në zhvillim;

përshtatja e proceseve dhe detyrave të standardit me modelin e zgjedhur;

përzgjedhja dhe aplikimi i metodave të zhvillimit të softuerit;

Kryerja e aktiviteteve dhe detyrave të përshtatshme për një projekt të caktuar softuerik.

Standardet komplekse GOST 34.

Ai u konceptua si një grup gjithëpërfshirës dokumentesh ndërsektoriale të ndërlidhura.

Objektet e standardizimit: sisteme të automatizuara të llojeve të ndryshme dhe të gjitha llojet e komponentëve të tyre.

Standardet GOST parashikojnë faza dhe faza të punës për krijimin e një sistemi të automatizuar, por nuk parashikojnë në mënyrë të qartë proceset nga fundi në fund që ndodhin gjatë zbatimit të ciklit jetësor.

Sipas GOST, zhvillimi i një sistemi të automatizuar ndahet në hapat dhe fazat e mëposhtme:

Faza 1 formimi i kërkesave për folësit:

Faza a: inspektimi i objektit dhe justifikimi i nevojës për zhvillimin e një sistemi të automatizuar;

Faza b: formimi i kërkesave të klientëve për një sistem të automatizuar;

Faza c: zhvillimi i një raporti për punën e bërë dhe përgatitja e një aplikacioni për zhvillimin e specifikimeve teknike.

Faza 2 zhvillimin e konceptit:

a: studimi i objektit;

b: kryerja e kërkimeve të nevojshme;

c: zhvillimi i opsioneve për konceptin e NPP që plotëson kërkesat e klientëve;

d: hartimi i një raporti për punën e bërë.

Faza 3 zhvillimin dhe miratimin e specifikimeve teknike për krijimin e centraleve bërthamore.

Faza 4 zhvillimi i një projekti paraprak të NPP-së:

a: zhvillimi i zgjidhjeve të projektimit paraprak për të gjithë sistemin në tërësi dhe për komponentët e tij individualë;

b: zhvillimi i dokumentacionit.

Faza 5 zhvillimin e projektit teknik:

a: zhvillimi i zgjidhjeve të projektimit për të gjithë sistemin dhe pjesët e tij;

b: zhvillimi i dokumentacionit për sistemin e automatizuar dhe nënsistemet e përfshira në të;

c: zhvillimi dhe ekzekutimi i dokumentacionit për furnizimin e produkteve për kompletimin e centraleve bërthamore ose zhvillimin dhe zbatimin e kërkesave teknike për zhvillimin e këtyre produkteve.

Faza 6 zhvillimi i dokumentacionit teknik:

a: zhvillimi i dokumentacionit të punës për pjesën e sistemit;

b: zhvillimi ose përshtatja e softuerit.

Faza 7vënien në funksion të sistemit të zhvilluar:

a: përgatitja e objektit të automatizimit për zbatimin e AS;

b: trajnimi i personelit;

c: pajisja e altoparlantëve me softuer dhe harduer;

d: punë instalimi;

d: komisionimi;

e: testet paraprake;

g: operacion provë;

h: testet e pranimit.

Faza 8 përcjellje:

a: kryerja e punës në përputhje me detyrimet e garancisë;

b: shërbim pas garancisë.