5.2.2 Súhrn procesov životného cyklu

V tejto medzinárodnej norme sú dve dôležité časti procesu. Odsek 6 poskytuje systémový kontext pre prácu so samostatným softvérovým produktom alebo službou, príp softvérový systém. Článok 7 obsahuje špecifické softvérové ​​procesy na použitie pri implementácii softvérového produktu alebo služby, ktoré sú nejakým prvkom väčšieho systému.

Na pomoc pri súbežnom používaní tejto medzinárodnej normy majú zodpovedajúce procesy v kapitole 6 rovnaké označenia pododdielov.

Vo všeobecnosti je súbor procesov uvedených v tejto medzinárodnej norme prispôsobený softvérovým nástrojom alebo vstupom do výsledkov poskytovaných procesov. Mnohé z procesov sú podobné implementáciám procesov špecifických pre softvér, no zachovávajú si dôležité rozdiely na základe cieľov, výsledkov a cieľových skupín. Používatelia tejto medzinárodnej normy aj tejto medzinárodnej normy by si mali byť istí, že zvážia vysvetlenia a poznámky v každom takomto špecifickom procese.

Procesy dohody definujú činnosti potrebné na vypracovanie dohôd medzi dvoma organizáciami. Ak je implementovaný akvizičný proces, poskytuje prostriedok na obchodovanie s dodávateľom produktov poskytovaných na použitie vo fungujúcom systéme, podporné služby pre tento systém alebo systémové prvky vyvinuté v rámci projektu. Ak sa implementuje proces dodávky, poskytuje prostriedky na realizáciu projektu, ktorého výsledkom je produkt alebo služba dodaná nadobúdateľovi.

Procesy dohody uvedené v tejto medzinárodnej norme sú teda softvérovo orientované procesy dohody z .

Procesy umožňujúce projekty riadia schopnosť organizácií získavať a dodávať produkty alebo služby prostredníctvom iniciácie projektu, podpory a riadenia. Tieto procesy poskytujú zdroje a infraštruktúru potrebnú na podporu projektov a zabezpečujú splnenie cieľov organizácie a stanovených dohôd. Netvrdia, že sú úplným súborom podnikových procesov, ktoré implementujú riadenie obchodných aktivít organizácie.

Procesy organizačnej podpory projektu zahŕňajú:

a) modelový proces riadenia životný cyklus;

B) proces riadenia infraštruktúry;

c) proces riadenia projektového portfólia;

d) proces riadenia ľudských zdrojov;

e) proces riadenia kvality.

Vo všeobecnosti sú procesy projektového manažmentu uvedené v tejto medzinárodnej norme softvérovo orientované procesy zo zodpovedajúceho súboru procesov v .

V tejto medzinárodnej norme je projekt vybraný ako základ pre popis procesov súvisiacich s plánovaním, hodnotením a kontrolou. Princípy spojené s týmito procesmi možno aplikovať na akúkoľvek oblasť riadenia organizácie.

Existujú dve kategórie projektových procesov. Procesy projektového manažmentu sa používajú na plánovanie, vykonávanie, hodnotenie a riadenie postupu projektu. Procesy podpory projektu zabezpečujú splnenie špecializovaných cieľov riadenia. Obe kategórie procesov projektu sú popísané nižšie.

Procesy projektového manažmentu sa používajú na vytváranie a vývoj projektových plánov, hodnotenie skutočného výkonu a pokroku v porovnaní s cieľmi a riadenie pokroku projektu až po jeho dokončenie. Jednotlivé procesy projektového manažmentu je možné vyvolať kedykoľvek v životnom cykle a na akejkoľvek úrovni hierarchie projektu v súlade s plánmi projektu alebo výskytom nepredvídaných udalostí. Procesy projektového riadenia sa uplatňujú na úrovni prísnosti a formalizácie v závislosti od rizika a zložitosti projektu:

a) proces plánovania projektu;

b) proces riadenia a hodnotenia projektu.

Procesy projektovej podpory tvoria špecifický súbor úloh zameraných na plnenie konkrétnych cieľov riadenia. Všetky tieto procesy sú zrejmé pri riadení akejkoľvek iniciovanej činnosti, siahajúcej od organizácie ako celku až po individuálny proces životného cyklu a jeho ciele:

a) proces riadenia rozhodovania;

b) proces riadenia rizík;

c) proces riadenia konfigurácie;

d) proces riadenia informácií;

f) proces merania.

Vo všeobecnosti sú procesy projektovej podpory prezentované v tejto medzinárodnej norme totožné s procesmi projektovej podpory uvedenými v , s výnimkou niektorých rozdielov vo forme ich prezentácie. V niektorých prípadoch môžu mať procesy softvérovej podpory vzťah s procesmi podpory projektu.

Technické procesy sa používajú na definovanie požiadaviek na systém, konverziu požiadaviek na použiteľný produkt, umožnenie nepretržitého kopírovania produktu (ak je to potrebné), aplikovanie produktu, poskytovanie požadovaných služieb, udržiavanie poskytovania týchto služieb a ukončenie používania. výrobok z obehu, ak nie je použitý pri poskytovaní služby.

Technické procesy definujú činnosti, ktoré umožňujú implementáciu organizačných a projektových funkcií na optimalizáciu prínosov a znižovanie rizík z toho vyplývajúcich technické riešenia a akcia. Tieto činnosti umožňujú, aby produkty a služby mali vlastnosti, ako je aktuálnosť a dostupnosť, efektívnosť nákladov, ako aj funkčnosť, spoľahlivosť, udržiavateľnosť, produktivita, použiteľnosť a ďalšie kvality požadované akvizíciou a podporou organizácií. Umožňuje tiež, aby produkty a služby spĺňali očakávania alebo požiadavky občianskeho práva vrátane faktorov zdravia, bezpečnosti, ochrany a životného prostredia.

Technické procesy pozostávajú z nasledujúcich procesov:

a) určenie požiadaviek nositeľov práv (špeciálny prípad procesu určovania požiadaviek nositeľov práv, uvedený v );

b) analýza systémových požiadaviek (špeciálny prípad procesu analýzy požiadaviek);

C) návrh architektúry systému (špeciálny prípad procesu návrhu architektúry uvedený v );

D) proces implementácie (špeciálny prípad procesu implementácie prvkov systému uvedený a ďalej rozpracovaný v kapitole 7 tejto medzinárodnej normy ako proces implementácie softvéru);

e) proces systémovej integrácie (špeciálny prípad integračného procesu uvedený v );

f) proces testovania kvalifikácie systému (proces, ktorý prispieva k dosiahnutiu výsledkov procesu overovania uvedených v );

G) proces inštalácie softvéru (proces, ktorý prispieva k dosiahnutiu výsledkov procesu prenosu v );

H) proces podpory akceptácie softvéru (proces, ktorý prispieva k dosiahnutiu výsledkov procesu odovzdania v );

i) proces prevádzky softvéru (špeciálny prípad procesu prevádzky uvedený v );

j) proces údržby softvéru (špeciálny prípad procesu údržby uvedený v );

k) proces vyraďovania softvéru (špeciálny prípad procesu vyraďovania a vyraďovania v ).

Vo všeobecnosti sú technické procesy uvedené v tejto medzinárodnej norme softvérovo orientované špeciálnymi prípadmi alebo príspevkami k výsledkom technických procesov uvedených v . Väčšina z nich je podobná procesom implementácie softvéru, no zachovávajú si dôležité rozdiely, napríklad analýza systémových požiadaviek a analýza softvérových požiadaviek začínajú z rôznych počiatočných bodov a majú rôzne účely.

Procesy implementácie softvéru slúžia na vytvorenie špecifického prvku systému (komponentu) vyrobeného vo forme softvérového nástroja. Tieto procesy premieňajú špecifikované správanie, rozhrania a implementačné obmedzenia na akcie, ktorých výsledkom je prvok systému, ktorý spĺňa požiadavky vyplývajúce zo systémových požiadaviek.

Špeciálny proces je proces implementácie softvéru, ktorý vyjadruje špecifickú softvérovú vlastnosť procesu implementácie uvedenú v .

Proces implementácie softvéru zahŕňa niekoľko špeciálnych procesov nižšej úrovne:

a) proces analýzy požiadaviek na softvér;

B) proces návrhu softvérovej architektúry;

c) podrobný proces návrhu softvéru;

d) proces tvorby softvéru;

e) proces integrácie softvéru;

f) proces testovania kvalifikácie softvéru.

Procesy softvérovej podpory poskytujú špecificky zameraný súbor činností zameraných na vykonávanie špecializovaných softvérový proces. Akýkoľvek podporný proces napomáha procesu implementácie softvéru ako celku s osobitným účelom, čím prispieva k úspechu a kvalite softvérového projektu. Existuje osem takýchto procesov:

a) proces riadenia softvérovej dokumentácie;

b) proces riadenia konfigurácie softvéru;

c) proces zabezpečenia kvality softvéru;

d) proces overovania softvéru;

e) proces validácie softvéru;

f) proces revízie softvéru;

g) proces auditu softvéru;

H) proces riešenia softvérových problémov.

Skupina procesov opätovného použitia softvéru pozostáva z troch procesov, ktoré podporujú schopnosť organizácie opätovne použiť softvérové ​​komponenty v rámci hraníc projektu. Tieto procesy sú jedinečné, pretože sa svojou povahou používajú mimo hraníc akéhokoľvek konkrétneho projektu.

Procesy opätovného použitia softvéru sú:

a) proces návrhu domény;

b) proces riadenia opätovného použitia aktív;

C) proces riadenia opätovného použitia softvéru.

Norma ISO/IEC 12207-95 definuje stratégiu a všeobecný poriadok pri tvorbe a prevádzke softvéru, pokrýva životný cyklus softvéru od konceptualizácie myšlienok až po ukončenie životného cyklu (životného cyklu).

Štandardné funkcie

Štandardné nepredpisuje konkrétny model životného cyklu alebo metóda vývoja softvéru; Definuje, že strany, ktoré sa podieľajú na používaní normy, sú zodpovedné =

1. pre výber modelu životného cyklu pre softvérový projekt,
2. za prispôsobenie procesov a úloh normy tomuto modelu,
3. pre výber a aplikáciu metód vývoja softvéru,
4. za vykonávanie činností a úloh vhodných pre softvérový projekt;

Norma ISO/IEC 12207-95 je rovnako zameraná na organizáciu akcií každej z dvoch strán: dodávateľa (vývojára) a kupujúceho (užívateľa); možno použiť rovnako, ak sú obe strany z rovnakej organizácie.

Štandardné definície

systém je kombináciou jedného alebo viacerých procesov, hardvéru, softvér zariadení a ľudí, aby bolo možné splniť určité potreby alebo účely.

Model životného cyklu- štruktúra obsahujúca procesy, činnosti a úlohy, ktoré sa vykonávajú pri vývoji, prevádzke a údržbe softvérového produktu počas celej životnosti systému, od definovania požiadaviek až po ukončenie jeho používania.

Kvalifikačné požiadavky- súbor kritérií alebo podmienok ( kvalifikačné požiadavky ), ktoré musia byť splnené, aby sa softvérový produkt kvalifikoval ako spĺňajúci jeho špecifikácie a pripravený na použitie v cieľovom prostredí.

Norma definuje všeobecnú štruktúru životného cyklu softvéru vo forme 3-stupňového modelu, ktorý pozostáva z:

1. procesy,
2. · činnosti,
3. úlohy

Štandard nedefinuje metriky, ktoré by mohli sledovať postup prác a ich efektivitu. Najväčšie prvky sú procesy životného cyklu softvéru. Celkovo bolo identifikovaných 18 procesov, ktoré sú spojené do 3 skupín:

1. - základné procesy;
2. - podporné procesy;
3. - organizačné procesy;
4. - adaptačný proces.

Hlavné procesy životného cyklu

1) Proces akvizície- jeho úlohou je určiť akcie podniku-kupujúceho, ktorý nadobúda automatizovaný systém, softvérový produkt alebo softvérová služba:

1. iniciácia akvizície;
2. príprava žiadosti o návrhy;
3. príprava zmluvy;
4. analýza dodávateľov;
5. prijímací softvér.

2) Proces prenosu(dodávka) definuje činnosť dodávateľského podniku, ktorý dodáva kupujúcemu systém, softvérový produkt alebo softvérovú službu.

3) Proces vývoja- jeho úlohou je určiť činnosť vývojárskeho podniku, ktorý vytvára softvérový produkt.
Zahŕňa nasledovné Tvorba:

1. Nasadenie vývojového procesu;
2. analýza systémových požiadaviek;
3. Navrhovanie (softvéru a hardvéru) systému ako celku;
4. Analýza softvérových požiadaviek;
5. Návrh softvérovej architektúry;
6. podrobný dizajn;
7. kódovanie;
8. testovanie ladenia;
9. integrácia softvéru;
10. kvalifikačné testovanie softvéru;
11. integrácia systému;
12. kvalifikačné testovanie systému;
13. Nasadenie (inštalácia alebo inštalácia) softvéru.

4) Prevádzkový proces určuje úkony prevádzkovateľa podniku, ktorý zabezpečuje údržbu systému počas jeho prevádzky v záujme užívateľov. Zahŕňa diela ako:

1. konzultácie s používateľmi;
2. prijímanie spätná väzba atď.

5) Proces podpory Softvér určuje činnosti eskortného personálu, ktorý zabezpečuje:

1. inštalácia a odstraňovanie softvérových produktov v počítačovom systéme;
2. analýza vznikajúcich problémov;
3. · zmena;
4. skúmanie a prenos upraveného softvéru;
5. Prenos softvéru z jednej platformy na druhú;
6. Odstránenie softvéru zo služby.

Anotácia: Logické pokračovanie predchádzajúcej prednášky. Problém je podrobne zvážený praktické uplatnenie GOST R ISO/IEC 12207 v organizáciách a projektoch. V tejto súvislosti sa študujú normy GOST R ISO/IEC 15271 a GOST R ISO/IEC 16326.

Z predchádzajúcej prednášky by malo byť zrejmé, že implementácia GOST R ISO/IEC 12207 je veľmi náročná úloha. Po prvé, nie je jasné, čo znamená „implementovať GOST R ISO / IEC 12207“? Dá sa považovať za implementovaný, ak sa niektoré procesy organizácie zhodujú s procesmi normy a niektoré nie? Môže sa norma považovať za implementovanú, ak sa niektoré projekty vykonávajú v súlade s ňou a niektoré nie? Tento zoznam otázok môže pokračovať ďalej a ďalej.

Nie je náhoda, že podľa GOST R ISO/IEC 12207 bola špeciálne vyvinutá norma GOST R ISO/IEC 15271-02 (GOST 15271, 2002), ktorá sa nazýva „Smernice pre aplikáciu GOST R ISO/IEC 12207“. venovaný úlohe jeho realizácie. Teraz prejdeme k jeho úvahe.

Norma GOST R ISO/IEC 15271

Význam normy je odhalený v jej úvodnej časti.

"1.2. Používatelia normy.

Túto normu môžu používať subjekty (osoby, organizácie), ktoré chcú aplikovať GOST R ISO / IEC 12207 pri realizácii zákaziek, bez ohľadu na objem alebo zložitosť projektu, konkrétnou organizáciou na sebakontrolu alebo zlepšovacie práce. procesy životného cyklu softvérové ​​nástroje.

Táto medzinárodná norma špecifikuje spôsob použitia GOST R ISO/IEC 12207 v súvislosti s odlišné typy softvérové ​​nástroje a ktoré procesy sú vhodné pre každý prípad.

Táto norma dopĺňa GOST R ISO / IEC 12207, čo nie je len normatívny dokument, ale aj meradlom pre skutočný projektový manažment. (Napríklad druhý prípad nastane, keď GOST R ISO / IEC 12207 je modelom pre časť práce procesu zlepšovania). Táto medzinárodná norma by sa mala chápať ako celok, ale v jednotlivých prípadoch sa môžu použiť špecifické časti."

Norma GOST R ISO/IEC 15271 pozostáva z 8 častí a 4 príloh. Podstatné časti sa nazývajú takto (číslovanie je prevzaté z textu):

• 4. Základné pojmy pre vývoj GOST R ISO / IEC 12207.
• 5. Implementácia GOST R ISO/IEC 12207.
• 6. Aplikácia v projektoch.
• 7. Aplikácia v organizáciách.
• 8. Aplikácie modely životného cyklu systémov.

Časť 4 je napísaná v štýle komentárov a vysvetlení k textu GOST R ISO/IEC 12207. Najdôležitejšie vysvetlenia sa týkajú interakcie GOST R ISO/IEC 12207 s firemné štandardy organizácia, rozdiel medzi pojmami „softvér“ a „systém“ a z toho vyplývajúce rozdiely medzi procesmi súvisiacimi so softvérom a systémami. Koncept je podrobne opísaný manažment kvality, implementovaný v GOST R ISO / IEC 12207. Vo všeobecnosti táto časť pôsobí dojmom stručného koncepčného prehľadu GOST R ISO / IEC 12207, ktorý pripomína vzdelávaciu poznámku.

Kapitola 5 predstavuje všeobecný prístup k implementácii, ktorý sa nazýva implementačná stratégia GOST R ISO / IEC 12207. Stratégia je podľa normy „typická implementačná metóda, ktorá by sa mala dodržiavať pri vykonávaní zmien v činnosti organizácie alebo projektu. " Stratégia je implementovaná ako projekt, pozostávajúci z povinných krokov, popísaných neformálne a bez akéhokoľvek prepojenia s procesmi organizácie. Tieto kroky sú:

• a) vypracovanie plánu implementácie;
• b) praktická aplikácia GOST R ISO/IEC 12207;
• c) vykonávanie sprievodu pilotný projekt(s);
• d) formalizácia spôsobu implementácie;
• e) schválenie spôsobu realizácie.

Vypracovanie implementačného plánu zahŕňa definovanie rozsahu GOST R ISO/IEC 12207. Rozsahom môže byť napríklad skupina oddelení alebo projektov organizácie. Rozsah môžete definovať aj ako súbor kľúčových procesov pre organizáciu, ktoré budú nahradené procesmi z GOST R ISO / IEC 12207. Samotný plán implementácie určuje skladbu projektov vykonávaných počas implementácie (môže byť niekoľko oni). Je samozrejmé, že pri vypracovaní plánu implementácie potrebné zdroje: finančné, ľudské, technické atď.

V praktickej aplikácii, ako by sa dalo očakávať, sa navrhuje použiť adaptačný proces opísaný v samotnej GOST R ISO / IEC 12207.

Stratégia samotná nevyvoláva otázky - takáto postupnosť krokov môže byť v špecifických podmienkach celkom efektívna, ale stojí za zmienku, že formálny projektový prístup k implementácii GOST R ISO / IEC 12207 je založený na zjednodušenej myšlienke skutočný stav. Vzhľadom na to, že procesy organizácie (a jej organizačná štruktúra) sa neustále menia, domnievam sa, že metodicky správnejšie by bolo považovať implementáciu normy za priebežný proces, a nie za časovo obmedzený projekt. Tento proces sleduje zmeny v procesoch organizácie a spúšťa jednotlivé projekty, napríklad:

• projekty na aplikáciu GOST R ISO / IEC 12207;
• projekt školenia všetkých nových zamestnancov v procesoch GOST R ISO/IEC 12207;
• projekt na zavedenie zmien do realizovaných procesov v súvislosti so zmenou organizačnej štruktúry organizácie; atď.

Prístup k implementácii GOST R ISO / IEC 12207 ako procesu, najmä ak sa má začať s jeho aplikáciou v projektoch alebo jednotlivých oddeleniach organizácie, umožní sústrediť zodpovednosť za celkový výsledok do rúk vlastníka procesu. , umožní zaviesť celkové sledovanie výsledkov a pod. Po implementácii by samozrejme mala nasledovať údržba implementovaných procesov, ktorá je tiež prirodzene organizovaná ako proces.

Viac informácií o aplikácii GOST R ISO / IEC 12207 v projektoch nájdete v časti 6 „Aplikácia v projektoch“. Norma navrhuje klasifikovať projekty a na tento účel zavádza nový pojem - " model životného cyklu systém“ (zoznam generických modelov je uvedený v prílohe C). Čo je model, nie je formálne definované. model životného cyklu systémy sa delia na stupne (etapy) s následným prispôsobením každej z nich modely životného cyklušpecifický systém" (nasleduje zoznam etáp). Celkovo sa berú do úvahy tri takéto modely: kaskádový, prírastkový, evolučný. Analyzujú sa ich výhody a nevýhody a následne sa "prekrývajú procesy podľa GOST R ISO / IEC 12207". " na štruktúre modelov. Výsledkom je, že tieto procesy získavajú ďalšie vlastnosti, ako je viacnásobné opakovanie v životnom cykle alebo prekrývanie sa v čase s inými procesmi. Okrem toho časť obsahuje množstvo odporúčaní rôznej miere užitočnosť týkajúca sa určité aspekty projektov. Tu je typický príklad.

"6.1.3. Charakteristiky systému

Subsystémy a prvky konfigurácie systému musia byť definované na príslušnej úrovni podrobností. Je potrebné definovať vlastnosti systému, najmä tie, ktoré súvisia so softvérom. Pri určovaní týchto charakteristík je potrebné poznamenať, ktoré z nich sú rozhodujúce pri prevádzke systému.

Orientačný zoznam charakteristík na úrovni systému (súvisiacich so softvérom a podliehajúcich zváženiu) zahŕňa:

• medzisystémové a vnútrosystémové rozhrania;
• používateľské rozhrania;
• vplyv softvérových chýb na bezpečnosť a zabezpečenie systému;
• hodnotenie výpočtového výkonu a časových obmedzení;
• dostupnosť programov realizovaných technickými prostriedkami;
• dostupnosť vhodných počítačov.

Ak systém obsahuje veľa podsystémov alebo konfiguračných položiek, musia byť úplne pokryté prácou na systémovej úrovni z procesu vývoja. Musia sa zohľadniť všetky požiadavky na rozhrania a montáž (integráciu) systémov. Pre malý systém nemusí byť taká striktná postupnosť krokov potrebná.“

Približnosť a vágnosť formulácií v uvedenej pasáži sú charakteristické pre celú normu ako celok.

Nasledujúci text slúži ako ústredná časť veľmi krátkej časti 7 „Aplikácia v organizáciách“.

"7.2. Možnosti aplikácie."

Dôvody, prečo sa GOST R ISO / IEC 12207 implementuje v organizáciách, môžu byť nasledovné:

• test dokonalosti existujúca metóda. Toto je zvyčajne prípad, keď metódu vyvinula samotná organizácia alebo organizácia vybrala a upravila existujúcu metódu;
• praktické využitie túto metódu predchádzať riziku spojenému so vstupom do nových sektorov trhu s prísnejšími požiadavkami spojenými s potenciálnym rizikom;
• vývoj novej metódy, napríklad na uspokojenie potrieb nová organizácia. To môže zahŕňať organizácie vytvorené fúziou alebo obchodnou spoluprácou. To môže byť potrebné na podporu niektorých modelov procesov poskytovania špecifickej práce;
• riadenie implementácie Nová technológia ako je automatizácia manuálnych procesov alebo zmena metód používaných na implementáciu softvérového produktu. GOST R ISO/IEC 12207 stanovuje kritériá, ktoré možno použiť na kontrolu excelentnosti príslušnej metódy pred alebo po zmene technológie;
• posúdenie vnútorných schopností zmluvnej strany z hľadiska plnenia kritérií zmluvy, napríklad ako zmluvnej strany, ktorá sa zúčastňuje súťažného (tendrového) procesu;
• identifikácia míľnikov, z ktorých je možné vyvinúť vylepšené programy, ako je napríklad vykonanie auditu v súlade s GOST R ISO / IEC 12207 a využitie samotného procesu zlepšovania.

Aj pri úplnej absencii vecných námietok je stále nemožné považovať tento text za štandard. Zo všetkého najviac pripomína tutoriál a v tejto funkcii bude pravdepodobne žiadaný, ale takýto text nemožno použiť ako návod na postup pri implementácii GOST R ISO / IEC 12207 v organizácii.

Nakoniec časť 8 „Použitie podľa účelu použitia modely životného cyklu systémy“ obsahuje dosť vágne definície „ modely životného cyklu systémy" a " modely životného cyklu softvérový nástroj“ a snaží sa medzi nimi nadviazať korešpondenciu presné definície chýba, nie je možné posúdiť výsledky.

Vo všeobecnosti norma GOST R ISO / IEC 15271 pôsobí dojmom čisto pomocného dokumentu vo vzťahu k GOST R ISO / IEC 12207, ktorý trpí aproximáciou a množstvom spoločných miest. Pre praktických manažérov je nevhodný – príliš abstraktné uvažovanie a príliš málo konkrétnosti. Pre študentov a profesionálov študujúcich procesy IT manažmentu chýba široký pohľad na danú problematiku (predsa len sa obmedzuje na GOST R ISO / IEC 12207) a je preťažený zbytočnými technickými detailmi. Napriek tomu je znalosť GOST R ISO / IEC 15271 užitočná, pretože ukazuje smer myslenia špecialistov v oblasti IT manažmentu, ukazuje, kde a ako sa vyvíjajú moderné normy. Považoval by som to za predbežný pracovný dokument, síce vo forme štandardu, ale určený skôr na diskusiu zainteresovanému publiku z radov odborníkov v oblasti IT manažmentu.

Norma GOST R ISO/IEC 16326

Ďalší pokus o formalizáciu procesu aplikácie GOST R ISO/IEC 12207 sa uskutočnil v GOST R ISO/IEC 16326 „Smernice pre aplikáciu GOST R ISO/IEC 12207 v projektovom manažmente“ (GOST 16326, 2002). Prejavuje snahu o zjednotenie procesy životného cyklu z GOST R ISO / IEC 12207 s procesmi projektového riadenia z populárnej metodickej príručky PMBOK 1 PMBOK- projektový manažment súbor vedomostí(PMBOK, 2009) a normou ISO 10006 (ruská verzia normy je obsiahnutá v (GOST 10006, 2005)). Toto je schematicky znázornené na obr. 4.1 uvedené v norme.

Ryža. 4.1.

Okruh používateľov normy je pomerne presne definovaný v časti 1.1.

"1.1. Okruh užívateľov

Táto medzinárodná norma je určená pre subjekty, ktoré používajú alebo plánujú používať GOST R ISO/IEC 12207 v softvérových projektoch, bez ohľadu na ich rozsah, vytvorené produkty, metodika, rozsah alebo zložitosť. Norma je primárne určená pre projektových administrátorov zodpovedných za súlad manažérskych procesov s GOST R ISO / IEC 12207:

• správcov zodpovedných za organizáciu a neustále zlepšovanie procesy životného cyklu softvérové ​​nástroje podľa GOST R ISO/IEC 12207;
• správcov zodpovedných za aplikáciu procesy životného cyklu softvérové ​​nástroje podľa GOST R ISO/IEC/12207 na úrovni návrhu;
• organizácie alebo osoby, ktoré sú subdodávateľmi pri implementácii SCP ( Manažment softvérových projektov. - AB).

Úvahy o osobách sú dané:

• zapojené v softvérové ​​projekty, ale nie AP ( projektových administrátorov. - AB);
• ktorí sú správcami nesoftvérových projektov, ale súvisiacich so softvérovými zariadeniami“.

Relatívne krátky hlavný text (bod 6 „Pokyny“ zaberá iba 9 strán z celkového počtu 35) je konzistentným komentárom k procesu 7.1 „Kontrola“ z GOST R ISO/IEC 12207 z pohľadu PMBOK. Štýl komentára je neformálny, zdôvodnenie má prevažne poradný charakter. Komentár sa nevymyká bežnému zdravému rozumu a neobsahuje nič nové. Vo všeobecnosti je to užitočné čítanie pre projektových manažérov (v terminológii prekladateľov – „správcov“) projektov, no nič viac.

Príloha A je jedna veľká tabuľka znázorňujúca vzťahy medzi hlavnými procesmi GOST R ISO/IEC 12207 a z nich vyvolanými činnosťami procesu riadenia. Všetky tieto odkazy sú obsiahnuté v tele normy GOST R ISO/IEC 12207; ich uvedenie do jednej tabuľky nepridáva žiadne nové informácie.

Príloha B je presne tá istá tabuľka spájajúca procesné oblasti a jednotlivé procesy z PMBOK s aktivitami Kontrolného procesu z GOST R ISO/IEC 12207.

Podobná tabuľka používajúca skupiny procesov v zmysle PMBOK namiesto oblastí je uvedená v prílohe C. Prílohy B a C v skutočnosti zhŕňajú všetko, čo bolo povedané v časti 6 normy. Prečo to bolo potrebné prezentovať vo forme tabuliek, nie je jasné. nie Ďalšie informácie tieto tabuľky sa neuvádzajú, dokazujú len skutočnosť, že existuje prepojenie medzi PMBOK a GOST R ISO / IEC 12207. Stav oboch príloh je však „referenčný“, takže nemusia mať žiadnu nezávislú hodnotu.

Ďalšia súhrnná tabuľka je uvedená v prílohe D. Zobrazuje prepojenia medzi tromi zdrojmi: GOST R ISO / IEC 12207, PMBOK a ISO 10006. Hneď poznamenávam, že druhý bol preložený do ruštiny až v roku 2005; v dôsledku toho sa terminológia použitá v prílohe D k norme GOST R ISO/IEC 16326 2002 líši od neskoršej. Rovnako ako v predchádzajúcich prípadoch nie je jasný význam prezentácie týchto vzťahov v kompaktnej tabuľkovej forme. Navyše celkový objem Prílohy A-D presahuje objem hlavnej časti 6 „Pokynov“ viac ako dvojnásobne.

Podľa môjho názoru sa GOST R ISO / IEC 16326-2002 formou a účelom nelíši od GOST R ISO / IEC 15271-2002. Obaja trpia prebytkom správneho „všeobecne“ a založeného len na rozumovej úvahe. Tieto úvahy sú zrejmé každému, kto má praktická skúsenosť projektového manažmentu a je nepravdepodobné, že bude vyzerať rozumne pre tých, ktorí takéto skúsenosti nemajú. Na rozdiel od GOST R ISO/IEC 15271-2002 je GOST R ISO/IEC 16326-2002 formálnejšia, ale praktický význam navrhovaného formalizmu nie je jasný.

Z hľadiska praktickej aplikácie pri navrhovaní podnikových procesov súvisiacich s IT sú obe normy do značnej miery zbytočné. Na druhej strane môžu byť žiadaní pri realizácii komplexných projektov, ktoré zahŕňajú popri štúdiu postupov riadenia IT aj analýzy projektový manažment a manažment kvality.

Okrem vyššie diskutovanej GOST R ISO / IEC 12207 vstúpilo do života množstvo noriem, ktoré podrobne popisujú procesy životného cyklu. Patria sem napríklad GOST R ISO/IEC 15910-2002 „Proces tvorby používateľskej dokumentácie softvéru“ (GOST 15910, 2002) a GOST R ISO/IEC 14764-2002 „Údržba softvéru“ (GOST 14764, 2002). Niektoré podobné normy ISO ešte neboli preložené do ruštiny; je pravdepodobné, že v budúcnosti sa počet ruskojazyčných noriem GOST R ISO priamo súvisiacich s GOST R ISO / IEC 12207 zvýši.

1) Umožňuje implementovať akýkoľvek model životného cyklu- je to možné, pretože Norma ponúka spôsob, ako definovať postupnosť vykonávania procesov a úloh, pričom jeden proces môže volať iný proces alebo jeho časti.

2) Poskytuje maximálnu flexibilitu- mnohé procesy a úlohy sú navrhnuté tak, aby sa dali prispôsobiť v súlade s konkrétnymi projektmi IS. Prispôsobovanie sa redukuje na vylúčenie procesov, činností a úloh, ktoré nie sú aplikované v konkrétnom projekte.

3) Norma v podstate neobsahuje popis konkrétnych spôsobov pôsobenia, najmä polotovary, riešenia alebo dokumentácia, popisuje iba architektúru procesov životného cyklu softvéru, ale nešpecifikuje podrobne, ako vykonávať alebo implementovať úlohy zahrnuté v procesoch.

4) Štandard obsahuje extrémne málo popisov týkajúcich sa návrhu databázy- je to opodstatnené, pretože rôzne IS a rôzne softvérové ​​systémy môžu nielen používať špecifické typy databáz, ale tiež nepoužívať databázy vôbec.

5) Hodnota normy je taká obsahuje súbory úloh, charakteristiky kvality, kritériá hodnotenia atď., poskytujúce komplexné pokrytie dizajnových riešení.

6) Hoci norma nenariaďuje použitie konkrétneho modelu životného cyklu alebo metódy vývoja, špecifikuje, že strany projektu sú zodpovedné za nasledovné:

výber modelu životného cyklu pre vyvíjaný projekt;

prispôsobenie procesov a úloh normy zvolenému modelu;

výber a aplikácia metód vývoja softvéru;

vykonávanie činností a úloh vhodných pre daný softvérový projekt.

Komplexné normy GOST 34.

Bol koncipovaný ako ucelený súbor vzájomne prepojených medzisektorových dokumentov.

Predmety štandardizácie: automatizované systémy rôznych druhov a všetky druhy ich komponentov.

Normy GOST stanovujú etapy a etapy práce na vytvorenie automatizovaného systému, ale výslovne nestanovujú komplexné procesy, ktoré prebiehajú počas implementácie životného cyklu.

Podľa GOST je vývoj automatizovaného systému rozdelený do nasledujúcich etáp a etáp:

1. fáza formovanie požiadaviek na AÚ:

Etapa a: kontrola objektu a zdôvodnenie potreby vývoja automatizovaného systému;

Etapa b: tvorba požiadaviek zákazníka na automatizovaný systém;

Etapa c: vypracovanie správy o pokroku a príprava návrhu rozvoja referenčné podmienky.

2. fáza vývoj koncepcie:

a: štúdium objektu;

b: vykonávanie potrebného výskumu a vývoja;

c: vývoj variantov koncepcie AU, ktoré zodpovedajú požiadavkám zákazníka;

d: vypracovanie správy o pokroku.

3. fáza vypracovanie a schválenie podmienok založenia jadrových elektrární.

4. fáza Vývoj návrhu projektu JE:

a: vývoj predbežných konštrukčných riešení pre celý systém ako celok a pre jeho jednotlivé komponenty;

b: vývoj dokumentácie.

5. fáza vypracovanie technického projektu:

a: vývoj konštrukčných riešení pre celý systém a pre jeho časti;

b: vypracovanie dokumentácie pre automatizovaný systém a subsystémy v ňom zahrnuté;

c: vypracovanie a vyhotovenie dokumentácie pre dodávku produktov na obstaranie jadrových elektrární alebo vypracovanie a vyhotovenie technických požiadaviek na vývoj týchto produktov.

štádium 6 vypracovanie technickej dokumentácie:

a: vypracovanie pracovnej dokumentácie pre systém jeho časti;

b: vývoj alebo adaptácia softvéru.

7. fázauvedenie vyvinutého systému do prevádzky:

a: príprava objektu automatizácie na implementáciu AS;

b: školenie personálu;

c: dokončenie AU softvérom a hardvérom;

d: inštalačné práce;

e: uvedenie do prevádzky;

e: predbežné testy;

g: skúšobná prevádzka;

h: akceptačné skúšky.

8. fáza eskorty:

a: výkon práce v súlade so zárukou;

b: pozáručný servis.

Rusko v súčasnosti používa štandard GOST R ISO/IEC 12207-2010 Procesy životného cyklu softvéru ( ISO/IEC 12207:2008 Systémové a softvérové ​​inžinierstvo – Procesy životného cyklu softvéru)

ISO/IEC 12207 - základný štandard procesy životného cyklu softvéru, zamerané na rôzne (akékoľvek!) typy softvéru a typy AS projektov, kde je softvér súčasťou. Norma definuje stratégiu a všeobecný poriadok pri tvorbe a prevádzke softvéru, pokrýva životný cyklus softvéru od konceptualizácie nápadov až po ukončenie životného cyklu.

Všeobecná štruktúra– presvedčte sa sami!

Zvláštnosti:

Norma ISO pozostáva z veľmi rozsiahlych zovšeobecnených procesov: „akvizícia“, „dodávka“, „vývoj“ atď. Zhruba povedané, jeden takýto proces je porovnateľný so všetkými procesmi CDM dohromady. Každý proces je rozdelený na súbor činností, z ktorých každý činnosti do súboru úloh. Veľmi dôležitý rozdiel medzi ISO: každý proces, akcia alebo úloha je iniciovaná a vykonávaná iným procesom podľa potreby a neexistujú žiadne vopred určené sekvencie (prirodzene, pri zachovaní logiky vzťahov podľa prvotných informácií úloh a pod.).

- "Dynamická" povaha normy je určená spôsobom, akým sa procesy a úlohy sekvenujú, v ktorom jeden proces v prípade potreby volá iný alebo jeho časť. Tento znak vám umožňuje implementovať akýkoľvek model životného cyklu.

Stupeň prispôsobivosti: maximálny. Mnohé procesy a úlohy sú navrhnuté tak, aby sa dali prispôsobiť softvérovým projektom. Proces prispôsobenia je proces eliminácie procesov, činností a úloh, ktoré nie sú použiteľné pre konkrétny projekt.

Norma zásadne neobsahuje konkrétne metódy pôsobenia, najmä - prípravy riešení či dokumentácie. Popisuje architektúru procesov životného cyklu softvéru, ale nešpecifikuje podrobne, ako implementovať alebo vykonávať služby a úlohy zahrnuté v procesoch, a nie je určený na predpisovanie názvu, formátu alebo presného obsahu výslednej dokumentácie. Rozhodnutia tohto typu sa robia pomocou normy.

Špecifikom použitia štandardu je, že obsahuje súbory úloh, kvalitatívnych charakteristík, hodnotiacich kritérií atď., čím poskytuje komplexné pokrytie projektových situácií. Norma nepredpisuje konkrétny model životného cyklu alebo metódu vývoja softvéru, ale špecifikuje, že strany používajúce normu sú zodpovedné za výber modelu životného cyklu pre softvérový projekt, za prispôsobenie procesov a úloh normy tomuto model, na výber a aplikáciu metód vývoja softvéru, na vykonávanie akcií a úloh vhodných pre softvérový projekt.

Stupeň požiadavky: Keď sa organizácia rozhodne použiť ISO12207 ako podmienku obchodného vzťahu, je jej zodpovednosťou špecifikovať minimálny súbor požadovaných procesov a úloh, ktoré predstavujú súlad s týmto štandardom.

MODEL SEI SW-CMM

Metodológia CMM navrhnutý a vyvinutý v USA ako nástroj na výber najlepších výrobcov ON plniť vládne nariadenia.

K tomu malo vytvoriť kritériá na hodnotenie vyspelosti kľúčových procesov developerskej spoločnosti a určiť súbor opatrení potrebných na ich ďalšie zlepšovanie. V dôsledku toho sa metodika ukázala ako mimoriadne užitočná pre väčšinu spoločností, ktoré sa snažia o kvalitatívne zlepšenie existujúce procesy navrhovanie, vývoj, testovanie softvérových nástrojov a redukovanie ich správy na zrozumiteľné a ľahko implementovateľné algoritmy a technológie opísané v jedinom štandarde.

SMM je de facto štandard.

Základom pre vznik CMM bol základný postoj, že základným problémom „krízy“ procesu rozvoja kvality ON nespočíva v absencii nových metód a nástrojov rozvoja, ale v neschopnosti spoločnosti organizovať sa technologických procesov a spravovať ich.

Posúdiť pripravenosť podniku na rozvoj kvality softvér SMM uvádza kľúčový koncept vyspelosti organizácie (Vyspelosť).

SMM definuje 5 úrovní technologická vyspelosť firmy:

1. Úroveň 1, počiatočné - organizácie, ktoré vyvíjajú softvér, ale nemajú vedomý proces vývoja, neplánujú a nevyhodnocujú svoje schopnosti;

2. Úroveň 2, opakovateľné - v takýchto organizáciách sa evidujú náklady na zdroje a sleduje sa priebeh projektov, stanovujú sa pravidlá projektového manažmentu na základe existujúcich skúseností;

3. Úroveň 3, definované - v takýchto organizáciách je akceptovaný, plne zdokumentovaný, zodpovedajúci skutočnému stavu a prístupný zamestnancom, proces vývoja a údržby softvéru. Tento proces by mal zahŕňať manažérske a technické podprocesy, ako aj zaškolenie zamestnancov na prácu s ním;

4. Úroveň 4, riadené - v týchto organizáciách sa okrem stanoveného a popísaného procesu využívajú merateľné ukazovatele kvality produktov a efektívnosti procesov, ktoré umožňujú presne predpovedať množstvo zdrojov (čas, peniaze, personál) potrebných vyvinúť produkt s určitou kvalitou);

5. Úroveň 5 zlepšovanie - v takýchto organizáciách okrem procesov a metód na ich posudzovanie existujú metódy na zisťovanie slabých stránok, postupy na vyhľadávanie a hodnotenie nových metód a techník rozvoja, školenie pracovníkov na prácu s nimi a ich zaradenie do všeobecný proces organizácie v prípade zvyšovania efektívnosti výroby).

Každá ďalšia úroveň celkom určite zahŕňa všetky kľúčové charakteristiky predchádzajúcich. Čo sa týka certifikácia spoločnosti na jedna z úrovní znamená bezpodmienečné splnenie všetkých požiadaviek nižších úrovní.