Վ.Իլյին.

TopSBI-ի որակի ծառայության ղեկավար

«Եթե ինչ-որ բան անես

սխալ - կարիք չկա
սպասեք ճիշտ արդյունքի»։

Ժողովրդական չինական իմաստություն

Համապարփակ լուծում որակի ապահովման խնդիրների համար ծրագրային գործիքներներառում է որոշակի որակի կառավարման համակարգի մշակում և ներդրում (Որակի կառավարման համակարգ - QMS): Համաշխարհային պրակտիկայում ամենաշատը տարածված է դարձել միջազգային ստանդարտների պահանջների վրա հիմնված համակարգ։ ISO շարք 9000, քանի որ այն հստակորեն սահմանում է ամենաընդհանուր պահանջները, այդ թվում՝ PS-ին, և այդպիսով, ընդհանուր առմամբ, արդեն կանխորոշում է գործընթացների սկզբնական հասունությունը, որն անհրաժեշտ է ՏՏ ոլորտում արդյունաբերության բազմաթիվ մոդելներին և ստանդարտներին համապատասխանելու համար: .

Բայց այն հարցին, թե որակի համակարգի ներդրումն ու հաջող սերտիֆիկացումը երաշխավորու՞մ են որակյալ արտադրանքի թողարկումը, պետք է անկեղծորեն պատասխանել՝ «ոչ»։

Ընդգծելով, որ ISO 9000-ը «հիանալի գաղափար է», Gartner Group-ը խորհուրդ է տալիս ISO 9001 հավաստագրումը դիտարկել միայն որպես որակի ճանապարհին մեկնարկային կետ (1):

Այն, կարծես, կազմում է որակի համակարգի «կմախքը», և այս համակարգը «մկաններով» լցնելը (մասնագիտական ​​բովանդակություն, որը հիմնված է արդեն հատուկ, արդյունաբերական ստանդարտների և մեթոդաբանությունների վրա, ինչպիսիք են CMM-ը) կարող է ապահովել որակի մակարդակ, որը կհամապատասխանի աճող մակարդակին: շուկայի պահանջները:

Վերոնշյալի հետ կապված, ինչպես մեթոդական, այնպես էլ գործնական տեսանկյունից, որակի կառավարման ոլորտի շատ փորձագետներ նպատակահարմար են համարում ՏՏ ընկերությունների զարգացման ռազմավարության կառուցումը հետևյալ կերպ.

Նախ, մշակեք և կիրառեք QMS՝ համաձայն ISO 9001:2000 մոդելի: (Ի վերջո, ընկերությունների մեծ մասը, որոնք այժմ գտնվում են SW-CMM-ի 4-րդ և 5-րդ մակարդակներում, սկզբում անցել են իրենց գործընթացները ISO մոդելին համապատասխանեցնելու ճանապարհով: Ինչպես ցույց է տալիս պրակտիկան, սա. լավագույն տարբերակՈԿՀ-ի մշակումը կառավարելու և ռիսկերի նվազեցման առումով):

Եվ միայն դրանից հետո սկսեք մշակել և իրականացնել SW-CMM մոդելի և, անհրաժեշտության դեպքում, CMMI մոդելի հիմնական գործընթացները:

Որպեսզի հասկանանք, թե ինչպես է դա իսկապես ճիշտ, եկեք համեմատենք այս մոդելները:

1. Դիմորդների վերանայում.

Եկեք ծախսենք կարճ ակնարկամենատարածված ստանդարտները, որոնք կարող են օգտագործվել ՏՏ ընկերության կողմից՝ իրենց բիզնես գործընթացները օպտիմալացնելու համար:

ISO9001.Ամենատարածվածը և հատկապես Եվրոպայում ISO 9001(2) է:

Միաժամանակ մեթոդաբար, շինարարական կարգապահությանը լիովին համապատասխան բարդ համակարգեր, ISO 9001 ստանդարտը ապահովում է, մի կողմից, շինարարությունը կազմակերպչական համակարգ«վերևից ներքև». ձեռնարկության նպատակներից և նրա քաղաքականությունից մինչև կազմակերպչական կառուցվածքը և բիզնես գործընթացների ձևավորումը, իսկ մյուս կողմից՝ կազմակերպչական համակարգի կրկնվող զարգացումը չափման և կատարելագործման մեխանիզմների միջոցով:

Պարզեցված «որակը», ըստ ISO 9000 ստանդարտների շարքի, այն իրավիճակն է, երբ սպառողները արտադրողից ստանում են ապրանքներ, որոնք համապատասխանում են իրենց ուղղակի պահանջներին և անուղղակի ակնկալիքներին: Հետեւաբար, որակի կառավարումը, ISO 9000-ի համաձայն, ներառում է այսպես կոչված օգտագործումը. «գործընթացային մոտեցում», երբ մոդելավորվում և ներդրվում է «փոխակերպումներ-գործընթացների» ամենաօպտիմալ շղթան՝ ապահովելով, որ սպառողների կարիքները ընկալվեն արտադրողի կողմից և մարմնավորվեն ցանկացած ապրանքի մեջ՝ առանց աղավաղումների։

Ծրագրային ապահովման մշակման շատ կազմակերպություններ հաջողությամբ օգտագործում են ISO 9000 ստանդարտների այս հայտնի շարքը: Նոր տարբերակԱյս շարքի ստանդարտները թողարկվել են 2000 թվականին և արդեն պարունակում են այնպիսի հասկացություններ, ինչպիսիք են գործընթացի մոտեցումը, վերլուծությունը և չափումը, գործընթացի բարելավումը, փոխառված CMM մոդելից և նախկինում բացակայում է ISO 9000-ի նախորդ տարբերակներում: Ճիշտ է, պետք է նշել, որ ստանդարտները. այս շարքը ունիվերսալ է. դրանք կենտրոնացած չեն որևէ կոնկրետ արդյունաբերության վրա, հաշվի չեն առնում ՏՏ ոլորտի առանձնահատկությունները և, այս առումով, իհարկե, ճշգրտման աստիճանի առումով նկատելիորեն զիջում են CMM-ին։ Բացի այդ, ISO 9000-ը չի ենթադրում համապատասխանության որևէ աստիճանավորում (մակարդակ) և, հետևաբար, դժվարացնում է կազմակերպության «իսկական» հնարավորությունների և, համապատասխանաբար, դրանց հետագա զարգացման ուղիների որոշումը:

CMM(Capability Maturity Model) մշակվել է Քարնեգի Մելլոնի համալսարանի ծրագրային ապահովման ճարտարագիտության ինստիտուտի կողմից (ԱՄՆ) և նկարագրում է զարգացման գործընթացի հասունության մոդելը։ ծրագրային ապահովումձեռնարկություններում (3). Այս մոդելի շրջանակներում յուրաքանչյուր ընկերության համար կարելի է համեմատել որոշակի մակարդակ (հինգ հնարավորից մեկը)՝ ցույց տալով ծրագրային ապահովման մշակման գործընթացի ձեռք բերված որակը։ Քանի որ այս ստանդարտները հիմնականում մշակվել են ԱՄՆ պաշտպանության նախարարության կապալառուների ընտրության գործընթացը պարզեցնելու համար, դրանք կենտրոնանում են ծրագրային ապահովման նախագծերի կառավարման գործընթացների վրա, մինչդեռ մշակման տեխնիկական ասպեկտները ավելի քիչ են լուսաբանվում:

Կան 316 հիմնական պրակտիկա SW-CMM v.1.1 (Capability Maturity Model for Software): Հիմնական պրակտիկաներն այն են, ինչ պետք է իրականացվի ձեռնարկությունում և ինչին ուշադրություն դարձնի գործընթացի գնահատման թիմը: Դրանք համակցված են ոլորտներում՝ Հիմնական պրակտիկաների տարածքներ (KPA) - սրանք արդեն փոխկապակցված գործընթացների մի շարք են, որոնք, երբ իրականացվում են միասին, հանգեցնում են որոշակի նպատակների իրականացմանը:

CMMI(Capability Maturity Model Integration) - CMM մոդելի հետագա զարգացում: CMMI-SE / SW 1.02 տարբերակում (CMMI համակարգերի ճարտարագիտության / ծրագրային ճարտարագիտության համար), հավանաբար ամենահարմարը մշակողների համար ծրագրային համակարգեր, - Հիմնական պրակտիկաների թիվը հասնում է 417-ի։

Հիմնական պրակտիկաների աճը կապված է CMMI-ի մշակման բուն նպատակի հետ. մոդելը պետք է օգնի խուսափել ոլորտին հատուկ CMM մոդելների օգտագործման հետ կապված խնդիրներից:

(1991 թվականից ի վեր CMM-ները մշակվել են տարբեր ծրագրերի համար, որոնցից ամենակարևորներն են.

Ծրագրային ապահովման մշակման գործընթացի հասունության մոդել (Capability Maturity Model for Software - SW-CMM)
- գործընթացների հասունության մոդել համակարգերի վերաճարտարագիտության համար (Electronic Industries Alliance միջանկյալ ստանդարտ - EIA/IS 731)
- ինտեգրված արտադրանքի մշակման գործընթացների հասունության մոդելը Ինտեգրված արտադրանքի զարգացման հնարավորությունների հասունության մոդել - IPD-CMM)

Այս մոդելների հիման վրա կառուցվել է CMMI: Այն կլանել է այս մոդելներից լավագույնները՝ վերացնելով որոշ հասկացությունների մեկնաբանման անորոշությունը՝ բազմաթիվ մոդելների առկայության պատճառով, հետևաբար, հիմնական պրակտիկաների թիվը զգալիորեն աճել է):

Հասկանալի է, որ սա զգալիորեն ավելի «ծանր» մոդել է, տես Նկ. Բրինձ. մեկ, որը, ընդ որում, գործնականում դեռ բավականաչափ փորձարկված չէ (թողարկվել է միայն 2002 թվականին)։ Այս առումով, իմ կարծիքով, մոդելն իրականացնելիս հնարավոր են մեծ ռիսկեր, որոնք կապված են ինչպես ծրագրային ապահովման մշակման արագության չհիմնավորված կորուստների, այնպես էլ ներդրված KPA-ի շահագործման (և աջակցության) համար աշխատուժի ծախսերի միաժամանակյա միանշանակ աճի հետ: - տեսնել. Նկար 1. Որպես պրակտիկ մասնագետ, ով արդեն կառուցել է QMS երեք տարբեր ՏՏ ընկերություններում, ինձ թվում է, որ CMMI մոդելում ակնհայտորեն խախտված է անհրաժեշտի և բավարարի հավասարակշռությունը՝ ՏՏ ընկերության անձնակազմը (և սա, որպես կանոն, հիմնականում «ծածկագիր նկարիչներն» են) ուղղակի «չի ընդունի» վերահսկվող նման մի շարք կանոնակարգեր («Պոտյոմկին գյուղ» կառուցելու շատ մեծ ռիսկ կա)!

Բրինձ. 1 KPA կազմի համեմատությունը CMM և CMMI մոդելներում:

Բացի այդ, CMMI-ի համար գնահատումը զգալիորեն ավելի թանկ կլինի, քանի որ լիազորված է SEI Առաջատար գնահատող»դեռևս շատ քիչ օվներ կլինեն, և այդ ծառայությունները շատ ավելի թանկ կլինեն, քան CMM մոդելի համապատասխանությունը գնահատելիս:

Ավելին, որակի կառավարման ոլորտի շատ օտարերկրյա փորձագետներ (որոնց հետ ես լիովին համաձայն եմ այս պահին) բավականին թերահավատորեն են վերաբերվում CMMI-ին փոքր և միջին կազմակերպություններում դրա իրականացման օգտակարության համատեքստում (հենց այդպիսի կազմակերպություններն են բնորոշ. Ռուսաստանի համար): Նույնիսկ կարծիք կա, որ որոշ ժամանակ անց SEI-ն կամ պետք է թողարկի հարմարեցված SW-CMM v.2, կամ էլ նման քայլեր ձեռնարկի։ Նրանք. եթե շուկան չի ընդունում մոդելը, և նման նախադրյալներ արդեն գոյություն ունեն այս գրելու պահին, ապա SEI-ն պետք է հարմարվի շուկայի պահանջներին:

Վերոնշյալի հետ կապված՝ տեղին է թվում վերլուծել արդեն նշված հավասարակշռությունը, թե ինչն է անհրաժեշտ և բավարար այս բոլոր հիմնական ՈԿՀ մոդելներում:

Եկեք այն գծենք հետևյալ կոորդինատներով (տես Նկ. Բրինձ. 2) :

զարգացման գործընթացների կարգավորման աստիճանը - նշենք այս հասկացությունը. RP,

պլանավորված արդյունքների հասնելու հավանականությունը - նշեք այս հայեցակարգը. PQ.

Նկ. 2-ը ցույց է տալիս կարգավորման աստիճանի հավասարակշռության և պլանավորված արդյունքների հասնելու հավանականության փորձագիտական ​​գնահատականը, որն իրականացվել է հեղինակի կողմից՝ հիմնվելով այս մոդելների պահանջների կիրառման պրակտիկայի արդյունքների վրա PS (ծրագրային ապահովում) մշակման և իրականացման գործում գործիքներ):

Մաթեմատիկական առումով ածանցյալի արժեքը. F(Q) = dPQ \ dRQ(որակի հասնելու արդյունավետության բարձրացում dPQպահանջների կատարմանը աջակցելու համար աշխատաժամանակի արժեքի բարձրացմամբ dRQ), նվազում է, համապատասխանաբար, հետեւյալ հաջորդականությամբ : ISO 9000, CMM, CMMI:

Ուստի Նկ. 2-ը պարզ և պարզ բացատրում է.

ISO 9000 մոդելի ժողովրդականությունը,

մեթոդաբանության ճիշտությունը՝ սկզբում ISO, և միայն այնուհետև, անհրաժեշտության դեպքում, CMM,

որոշակի թերահավատություն CMMI մոդելի արդյունավետության վերաբերյալ:

Բրինձ. 2 Կարգավորման աստիճանի և պլանավորված արդյունքների հասնելու հավանականության միջև հավասարակշռության վերլուծություն (ըստ հեղինակի փորձագիտական ​​գնահատականի)

Այժմ դիտարկենք մեկ այլ ուղեցույց, որը լայնորեն կիրառվում է ՏՏ ընկերություններում և կնշվի ստորև՝ ՈԿՀ ներդրման պրակտիկայի խնդիրները վերլուծելիս:

Սա PMBoK(Ուղեցույց դեպի ծրագրի կառավարումԳիտելիքի մարմին) է ՆախագիծԿառավարման ինստիտուտ, որը յուրացրել է նախագծերի կառավարման ոլորտում կուտակված գիտելիքները։ Փաստաթղթի վերջին տարբերակը հրապարակվել է 2000 թվականին և միևնույն ժամանակ ստացել է Ամերիկյան ստանդարտների ինստիտուտի ANSI ստանդարտի կարգավիճակ (չնայած ANSI և IEEE ստանդարտները պաշտոնապես համարվում են ամերիկյան, դրանց մեծ մասը դե ֆակտո միջազգային բնույթ է կրում): PMBoK-ի կարևոր առանձնահատկությունն այն է, որ այն դիտարկում է ծրագրի կառավարումը ընդհանուր իմաստով, առանց կապվելու կոնկրետ առարկայական ոլորտների, ինչպիսին է ՏՏ-ն, և, հետևաբար, չի կարող կիրառվել ինքնուրույն. ստորև մենք կքննարկենք, թե դա ինչ ազդեցություն ունի ISO-ի հետ համատեղ օգտագործման դեպքում: 9000։

Եկեք հիմա դիտարկենք, թե ինչպես են արդեն հայտնի ISO 9001:2000 ստանդարտի պահանջները փոխկապակցված ավելի ու ավելի տարածված HMM մոդելի ընդհանուր հատկությունների հետ: {3}- սմ. Բրինձ. 3.

Բրինձ. 3. CMM-ի ընդհանուր հատկությունների և ISO 9001:2000-ի տարրերի համապատասխանությունը.

HMM-ի յուրաքանչյուր մակարդակ, ինչպես նշվեց վերևում, բնութագրվում է մի շարքով հիմնական գործընթացների ոլորտները - KPA (Key Process Areas) -սմ. Նկ.3.Ներքին բոլոր նպատակների ձեռքբերումը KPAորոշակի մակարդակի համար CMM-ը որոշում է կազմակերպության համապատասխանությունը այս մակարդակին: Եթե ​​գոնե մեկ գոլի առնվազն մեկը KPAքանի որ CMM մակարդակը չի հասել, ապա կազմակերպությունը չի կարող բավարարել այս CMM մակարդակը: KPAկարելի է բաժանել երեք կատեգորիաների. մենեջերներ , կազմակերպչական Եվ ապահովելով (սմ. Բրինձ. 4).

CMM-ը չի սահմանում ծրագրային ապահովման մշակմանն առնչվող բոլոր գործընթացները. այն ընդգծում է միայն նրանք, որոնք անհրաժեշտ են SMM մակարդակին հասնելու համար, և դրանք ներառված են KPA. Յուրաքանչյուրը KPAբաժանված է 5 ընդհանուր հատկանիշների. Կատարելու պարտավորություն (Comment to perform); Կատարելու ունակություն; Կատարված գործողություններ; Չափում և վերլուծություն (Measurement and Analysis); Իրականացման ստուգում

Ընդհանուր սեփականություն» Կատարված գործողություններ»նկարագրում է նպատակներին հասնելու համար ձեռնարկվելիք գործողությունները KPA, մնացած չորս ընդհանուր հատկությունները նկարագրում են ֆորմալ գործոնները, որոնք գործընթացը դարձնում են մի մասը կազմակերպչական մշակույթ. Բոլորի ամբողջական իրականացում հիմնական տեխնիկա (հիմնական պրակտիկա)բոլոր ընդհանուր հատկությունները ապահովում են նպատակների իրագործումը KPA. Հիմնական գործառնական պրակտիկան նկարագրում է, թե ինչ պետք է դառնա աշխատանքային հոսքը (կամ գործընթացի տարրը կամ ենթակառուցվածքի մի մասը), բայց չեն սահմանում, թե ինչպես հասնել ( կոնկրետ տեխնոլոգիաներկամ տեխնիկա), չնայած որոշ տեխնիկայի համար տրված են ընդհանուր առաջարկություններ: Համար տարբեր պայմաններնույն արդյունքին կարելի է հասնել տարբեր ձևերով: Դա ավելի շուտ ընդհանուր սկզբունքներաշխատանք, քան կոնկրետ գործողություններ:

Ընդհանուր հատկությունների հաջորդական կատարումը իրականում իրականացնում է բիզնես գործընթացի բարելավման ցիկլ (Բիզնես գործընթացի բարելավում - BPI-սմ. Բրինձ. հինգ.), այսինքն. բիզնես գործընթացների շարունակական բարելավում (BP):

Բրինձ. 5. Բիզնես գործընթացների շարունակական բարելավման ցիկլը ըստ CMM մոդելի և ISO 9000:2000:

Կարճ ժամանակում համապատասխանության վկայական ստանալու ցանկությունը ստիպում է խորհրդատվական ընկերություններին և որակի կառավարմամբ զբաղվող մասնագետներին օգտագործել վերը նշված բոլոր բարձր մակարդակի մոդելների ճկունությունն ու շրջանակային պահանջներն իրենց «եսասիրական» նպատակների համար:
Իրադարձությունների այս պարտադրման արդյունքում, օրինակ, կազմակերպությունը, որը ստացել է ISO 9000:2000 վկայագիր, ունի միայն ISO 9001-ին համապատասխանելու համար պահանջվող նվազագույն գործընթացները, և ոչ բոլոր գործընթացները, որոնք անհրաժեշտ են ընկերությանը գործելու համար: արդյունավետ - տես ստորև: Բրինձ. 2. Բացի այդ, գործընթացների մանրամասնության մակարդակը կարող է բավարար չլինել հստակ հասկանալու համար, թե ինչ է տեղի ունենում գործընթացների ներսում և ով է պատասխանատու գործընթացի շրջանակներում ինչ խնդիրների համար:
IN լավագույն դեպքըմիայն մի քանի թեստային նախագծեր են անցել նոր ընթացակարգերով, և որոշ ժամանակ անց պարզ է դառնում, որ դրանք շտկման և լրացման կարիք ունեն։ Հաճախ, ՈԿՀ-ի հավաստագրումից անմիջապես հետո, գործընթացները մոռացվում են մինչև հաջորդ դիտորդական աուդիտը՝ մոռանալով ծախսվածի մասին։ ֆինանսական ռեսուրսներև անձնակազմի ոգևորությունը:
Իրոք, երբ դուք գործում եք որպես անկախ աուդիտոր, շատ դժվար է ապացուցել, որ գործընթացի մանրամասների ընդունված մակարդակը ակնհայտորեն բավարար չէ ընկերության ՈԿՀ-ի արդյունավետ գործունեության համար: Բայց ISO 9000 աուդիտի համար հատկացված ժամանակում հակառակն ապացուցելը չափազանց դժվար է (սա կարող է շատ հաջող օգտագործվել աուդիտորին հակադրվելիս): Պրակտիկան ցույց է տալիս, որ անհնար է արագ կառուցել արդյունավետ գործընթացներ նույնիսկ հասունության 3-րդ մակարդակի (ինչպես նաև ISO 9000-ի վրա հիմնված գործընթացներ):
Դրան հասնելու համար բավական չէ միայն նկարագրել գործընթացները՝ հաշվի առնելով ընտրված մոդելի պահանջները։ Հիմնական դժվարությունը կայանում է նրանում, որ վերանախագծել արտադրական մշակույթը կազմակերպության ներսում .

Իսկ դա հնարավոր չէ անել ղեկավարության կամային վճռականությամբ։ Այդ իսկ պատճառով այն մոտեցումը, որը սահմանված է CMM-ում, պարզապես ավելի կենսունակ և իրատեսական է, քան ISO 9000 մոդելներում - տես. Բրինձ. հինգ.

Եկեք հիմա դիտարկենք, թե գործնականում ինչպես է հնարավոր երկու մոդելների հետ համատեղելի QMS կառուցել:

ISO 9000:2000-ի պահանջներով հիմնական CMM գործընթացների ծածկույթի աստիճանի փորձագիտական ​​գնահատումը, համաձայն CMM-ի հեղինակների գնահատման (4), ներկայացված է. Նկ.6.

Գնահատումն ինքնին իրականացվել է երկու կոորդինատների համաձայն.

զարգացման գործընթացների (SWP) համապատասխանության աստիճանը (%-ով) CMM-ում հասունության մակարդակին. բավարարություն»;

նման բավարարության հնարավորության աստիճանը (%-ներով), որը տալիս է ISO 9000:2000 - « հնարավորություն».

Ինչպես երևում է Բրինձ. 6,Ստեղծվում են ISO 9000:2000 պահանջներ իրական հնարավորությունհասնել նույնիսկ վերին (CMM մակարդակ 5) SWP-ի մարման մակարդակին:

Այնուամենայնիվ, SWP-ի առնվազն երրորդ (CMM մակարդակ 3) մակարդակի արդեն իսկ ապահովելու իմաստով, ՈԿՀ-ն ըստ ISO 9000:2000 մոդելի պետք է փոքր-ինչ բարելավվի, այն է՝ մշակել և իրականացնել ևս երկու կազմակերպչական ընթացակարգեր: ( Կազմակերպչական գործընթացի սահմանումև կենտրոնացում) և ընթացակարգը ընդհանուր կառավարում (ինտեգրված ծրագրային կառավարում ), որի բովանդակությունը դժվար չէ ՏՏ ոլորտի ոչ մի ընկերության համար:

Բայց հնարավոր է և անհրաժեշտ է ավելի հեռուն գնալ (CMM 4-րդ մակարդակ), օրինակ, փակագծերում նշված է այս հոդվածի հեղինակի գնահատականը (նույն կոորդինատներում՝ հասանելիություն և հնարավորություն), որը համապատասխանում է QMS-ին ըստ ISO 9000-ի: :2000 մոդել, որում QMS գործընթացի լանդշաֆտը լրացվում է գործընթացների նախագծի կառավարմամբ՝ արդեն վերը նշված մեկ այլ ստանդարտի պահանջներին համապատասխան։ P.M. Bok- սա կօգնի ձեզ զգալիորեն մեծացնել նույնիսկ այդպիսիների հասունությունը SWP, ինչպես:

Ծրագրերի առաջընթացի մոնիտորինգ (Ծրագրային ծրագրերի հետևում և վերահսկողություն);

• Ծրագրի պլանավորում (Ծրագրային ծրագրի պլանավորում);

Ծրագրային ապահովման ընդհանուր կառավարում (Ինտեգրված ծրագրային կառավարում);

Գործընթացների կառավարում քանակական գնահատումների միջոցով (Quantitative process management).

Բրինձ. 6. ԻՍՕ 9000:2000-ի պահանջներով հիմնական CMM գործընթացների ընդգրկվածության աստիճանի փորձագիտական ​​գնահատում.

Ինչպես երևում է Նկ.6., CMM մոդելը, իր սկզբունքների համաձայն, շատ մոտ է ISO 9001:2000 ստանդարտի համաձայն կառուցված QMS-ին և լրացվում է նախագծերի կառավարման գործընթացներով՝ համաձայն. Վարչապետ BoK..

Չանելու համար լրացուցիչ աշխատանք ISO 9000-ի համաձայն միաժամանակյա սերտիֆիկացումով և CMM-ի համաձայն հետագա գնահատմամբ, ես խորհուրդ եմ տալիս, որ ձեր արտադրական գործընթացները սահմանելիս ներառեք (կամ գուցե սահմանափակվեք դրանցով. ի վերջո, դրանք արտադրական գործընթացներ են ՏՏ ընկերության համար): Դրանք բոլորն անհրաժեշտ են: CMM KPA մոդելում: Այսպիսով, ընկերությունը միաժամանակ.

կատարում է պահանջները ISO 9001:2000գործընթացային մոտեցման իրականացման վերաբերյալ;

բոլոր անհրաժեշտ փաստաթղթերը CMMգործընթացներ ( KPA);

կատարում է մի շարք կարևոր պահանջներ ISO 9001:2000ինչպես:

չափումների վրա հիմնված գործընթացների կառավարում (Քանակական գործընթացի կառավարում);

Մատակարարների կառավարում` հիմնված ենթապայմանագրի կառավարման վրա ( Ծրագրային ապահովման ենթապայմանագրի կառավարում );

սպառողների պահանջների վերլուծություն՝ հիմնված պահանջների կառավարում (Պահանջների կառավարում );

հիմնված մարդկային ռեսուրսների կառավարման վրա Անձնակազմի վերապատրաստման ծրագրեր (Ուսուցման ծրագիր );

կապի կառավարում հիմնված պաշտոնական մոդելների կառուցում կազմակերպչական գործընթացներ (Կազմակերպչական գործընթացի սահմանում );

գործարկում է բարելավման մեխանիզմ (Plan-Dо-Check-Action)նկարագրված բոլոր գործընթացները (SWP)բոլոր հինգի հետեւողական իրականացման միջոցով Ընդհանուր հատկանիշներ-սմ. Բրինձ. հինգ.

Այսպիսով, եթե մենք օգտագործենք KPA CMM-ը որպես BP և օգտագործենք PS-ի զարգացման ծրագրի կառավարման ընթացակարգերի պահանջները P.M.BoK,ապա այս կերպ կառուցված ՈԿՀ-ն կարող է ամբողջությամբ գնահատվել CMM մակարդակ 4 - տես. Բրինձ. 7.

Բրինձ. 7. CMM 4-րդ մակարդակի հասնելու սխեման, երբ օգտագործվում է QMS մոդելը ISO 9000-ի և PM BoK 2000 ուղեցույցի համաձայն:

Եզրափակելով, պարզության նկատառումներից ելնելով (հեղինակի ոճավորման մեջ) ես ներկայացնում եմ ՏՏ ընկերության QMS-ի գործունեության սխեման ISO 9000 և CMM մոդելների հետևողական ներդրմամբ. տե՛ս Նկ. Բրինձ. 8.

Բրինձ. 8. ՈԿՀ-ի սխեման, որը գործում է ISO 9000 և CMM մոդելների հետևողական ներդրմամբ (հեղինակային ոճավորում)

Այստեղ կարևոր է հասկանալ, որ և՛ CMM-ը, և՛ ISO 9001:2000-ն ինքնին պարզապես շարունակական կատարելագործման գործիքներ են:

Այսպիսով, ISO 9001:2000 ստանդարտով սերտիֆիկացումը և սերտիֆիկատի հաստատումը պետք է նպաստեն ընկերության գործընթացների որակի բարձրացմանը, որտեղ գործընթացների որակի աճը գնահատելու չափանիշը ընկերության դուրս գալն է նոր մակարդակ: bpi,այսինքն՝ դրանց գնահատումն արդեն իսկ մոդելի համաձայն է CMM {3}.

գրականություն

«Ծրագրային ապահովման որակի գնահատում», Վ. Լիպաև, Սինտեգ, 2001 թ

ISO 9001:2000. Որակի կառավարման համակարգ. Պահանջներ.

Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Հնարավորությունների հասունության մոդել ծրագրային ապահովման համար (SW-CMM), տարբերակ 1.1: // CMU/SEI-93-TR-024, փետրվար 1993 թ.

Անոտացիա: Մանրամասն ուսումնասիրված է ծրագրային ապահովման մշակման գործընթացների բարելավման, հավանաբար, ամենահայտնի մեթոդոլոգիայի՝ CMM-ի հիմքում ընկած գաղափարների շրջանակը: Վերլուծվում է ՀՄՄ-ի տրամաբանությունը և կառուցվածքը: Ցուցադրված է կապը HMM-ի և նախկինում ուսումնասիրված գործընթացի մոդելների միջև:

-ի շրջանակներում ստեղծված հրաշալի գործնական գործիք գործընթացի մոտեցումգործունեության նկարագրությանը նախագծային կազմակերպություն մասնավորապես այն կազմակերպությունը, որը զարգացնում է Տեղեկատվական համակարգեր, ցուցադրում է ՀՄՄ մեթոդոլոգիան։ CMM-ն նշանակում է «Capability Maturity Model», որը մոտավորապես նշանակում է «կառավարման համակարգի հասունության մոդել»: Գրականության մեջ CMM-ն ավելի հաճախ կոչվում է կազմակերպչական հասունության մոդել, և ես նույնպես կհետևեմ այդ ավանդույթին:

SMM-ի առաջացման պատմությունը հետևյալն է. 80-ականների վերջին։ Անցյալ դարում ԱՄՆ պաշտպանության նախարարությունը պատվիրեց Ծրագրային ճարտարագիտության ինստիտուտի 1Eng. SEI - Ծրագրային ճարտարագիտության ինստիտուտ Carnegie Mellon University-ն աշխատում է ծրագրային ապահովման մշակման նախագծերում ենթակապալառուների ընտրության չափանիշների համակարգի վրա: Աշխատանքներն ավարտվել են 1991 թվականին, և արդյունքը եղել է CMM-ը։ Պետք է անհապաղ վերապահում անել, որ մոդելը չի ​​պարունակում որեւէ ֆինանսական, տնտեսական, քաղաքական, կազմակերպչական ընտրության չափանիշներենթակապալառուին, ինչպես նաև գաղտնի աշխատանքի ընդունվելու հնարավորության չափանիշներին (հավանաբար, այդպիսի խնդիրներ չեն դրվել): Խոսքը միայն այն չափանիշների մասին է, որոնք բնութագրում են պոտենցիալ ենթակապալառուի կարողությունը ծրագրային համակարգերի մշակման առումով։

CMM կառուցվածքը

Մոդելի ստեղծողները հիմք են ընդունել կազմակերպության գործընթացները՝ գնահատելու կազմակերպության որակյալ աշխատանք կատարելու կարողությունը, որը (կարողությունը) կոչվում է հասունություն: Հետո նրանք արեցին մի քանի ոչ տրիվիալ ենթադրություններ, որոնք հետագայում ընդունվեցին և արդարացի ճանաչվեցին ՏՏ ոլորտի շատ մասնագետների կողմից (և գուցե նրանցից շատերը):

Ենթադրություն 1. Գոյություն ունեն հասունության որակապես տարբեր մակարդակներ նախագծային կազմակերպությունզարգացող Տեղեկատվական համակարգեր(այդպիսի հինգ մակարդակ կա HMM մոդելում):

Ենթադրություն 2. Զարգացման ցանկացած կազմակերպություն շահագրգռված է հասունության ավելի բարձր մակարդակի անցնելու համար (ոչ միայն պաշտպանության նախարարության պայմանագրերի համար պայքարում իր հնարավորությունները մեծացնելու, այլ նաև սեփական կատարելագործման նպատակով):

Ենթադրություն 3. Անցումը հնարավոր է միայն հաջորդ մակարդակին հերթականությամբ: Մակարդակի վրայից «ցատկել» անհնար է (ավելի ճիշտ՝ կազմակերպության համար ռիսկերը միաժամանակ կտրուկ աճում են)։

Այսպիսով, մակարդակները կազմում են «սանդուղք», որով կազմակերպությունը բարձրանում է որպես սեփական զարգացում. Յուրաքանչյուր մակարդակ բնութագրվում է կազմակերպության գործընթացների որոշակի կազմով և հատկություններով: SMM «Level Ladder»-ը լայնորեն ընդունվել և տարածվել է: Ահա թե ինչ տեսք ունի նա.

Մակարդակ 1 «Սկսնակ». Արտադրության գործընթացը որպես ամբողջություն բնութագրվում է որպես ամեն անգամ ստեղծվող կոնկրետ նախագծի համար, իսկ երբեմն նույնիսկ քաոսային: Սահմանված են միայն մի քանի գործընթացներ, և նախագծի հաջողությունը կախված է անհատների ջանքերից:

Մակարդակ 2 «Կրկնվող». Ստեղծվել են ծրագրի կառավարման հիմնական գործընթացները, որոնք թույլ են տալիս հետևել ծախսերին, վերահսկել աշխատանքային գրաֆիկը և ստեղծված նախագծի ֆունկցիոնալությունը: ծրագրային լուծում. Սահմանել է գործընթացի կարգապահությունը, որն անհրաժեշտ է նմանատիպ հավելվածների մշակման նախագծերում անցյալի հաջողությունները կրկնելու համար:

Մակարդակ 3 «Հաստատ». Արտադրական գործընթացը փաստաթղթավորված և ստանդարտացված է ինչպես կառավարման, այնպես էլ ճարտարագիտության համար: Այս գործընթացը ինտեգրված է կազմակերպության ստանդարտ արտադրական գործընթացին: Բոլոր նախագծերը օգտագործում են կազմակերպության ստանդարտ գործառնական գործընթացի հաստատված հարմարեցված տարբերակը:

Մակարդակ 4 «Կառավարվող». Հավաքվում են արտադրական գործընթացի և ստեղծվող արտադրանքի որակի մանրամասն քանակական ցուցանիշներ։ Ե՛վ արտադրության գործընթացը, և՛ արտադրանքը գնահատվում և վերահսկվում են քանակական տեսանկյունից:

Մակարդակ 5 «Օպտիմալացում». Գործընթացի շարունակական բարելավումը ձեռք է բերվում քանակական միջոցով հետադարձ կապգործընթացի և դրանում առաջադեմ գաղափարների ու տեխնոլոգիաների ներդրման հետ։

Չնայած խստության բացակայությանը, վերը նշված սահմանումը ինտուիտիվորեն ամենից հաճախ առարկություններ չի առաջացնում: Ավելին, փորձառու մասնագետները հասկանում են, թե ինչու են հնարավոր անցումները միայն հաջորդ մակարդակ, ինչպես նաև, թե ինչու արժե ընդհանրապես ձգտել նման անցման։ Միևնույն ժամանակ, ՀՄՄ մոդելը չի ​​պարունակում նման մոտեցման որևէ քանակական կամ նույնիսկ ձևական հիմնավորում, ինչը, սակայն, չի նսեմացնում դրա արժանիքները։

Հետագայում, ինչպես ասում են, տեխնոլոգիայի խնդիր է։ Մոդելի կառուցվածքը սահմանվում է (Նկար 7.1), տրված են սահմանումներ, և սկսվում է տքնաջան աշխատանքը յուրաքանչյուր մակարդակի յուրաքանչյուր գործընթաց ճշգրիտ նկարագրելու համար: Արվածի գործնական արժեքը գնահատելու համար անցնենք այս ճանապարհի մի մասը։

Բրինձ. 7.1.

Նկ. 7.1-ը պարունակում է հետևյալ հասկացությունները.

Հիմնական գործընթացների խումբ. Ինչպես ասվում է (Paulk, et al., 1995 թ.), «հիմնական գործընթացների յուրաքանչյուր խումբ սահմանում է հարակից գործողությունների բլոկ, որի արդյունքում ձեռք է բերվում մի շարք նպատակներ, որոնք նշանակալի են արտադրական գործընթացի արտադրողականության բարձրացման համար: օրինակ, հիմնական գործընթացների խմբի համար» Պահանջների կառավարում«(Տե՛ս նկար 7.2) նպատակը ծրագրային ապահովման մշակման նախագծի պահանջները հաճախորդի և մշակողի միջև հաշտեցնելն է»:

Ոչ CMM-ում անհատական ​​գործընթացներ. Փոխարենը, կան առանձին աշխատանքներ, որոնք կոչվում են հիմնական պրակտիկա (տե՛ս ստորև), որոնք կապված են միմյանց մուտքերի և ելքերի միջոցով և ծառայում են որպես գործընթացների կառուցման սկզբնաղբյուր: CMM-ը չի տրամադրում ուղեցույց այն մասին, թե ինչպես պետք է կառուցված լինեն գործընթացները, այսինքն՝ հիմնական պրակտիկան կապել տրամաբանական հաջորդականության մեջ: Հիմնական պրակտիկաների հավաքածուները կոչվում են հիմնական գործընթացների խմբեր:

Բրինձ. 7.2.

CMM-ում հիմնական գործընթացների խմբերը քարտեզագրված են հասունության մակարդակներով (Նկար 7.2), այսինքն՝ մակարդակի բոլոր պրակտիկաները փոխազդում են միայն միմյանց հետ և չեն փոխազդում այլ մակարդակների պրակտիկայի հետ: Սա թույլ է տալիս երաշխավորել բոլոր գործընթացների լիարժեք կատարումը կոնկրետ մակարդակով և, հետևաբար, մակարդակը կապել կազմակերպության զարգացման ավարտված փուլի հետ:

«Բանալին» ածականը ենթադրում է, որ կան գործընթացների խմբեր(այսինքն՝ պրակտիկաների մի շարք), որոնք առանցքային չեն հասունության որոշակի մակարդակի առումով, այսինքն՝ կապված չեն այս մակարդակի նպատակների իրականացման հետ (տես ստորև): HMM մոդելը չի ​​նկարագրում ամեն ինչ գործընթացների խմբերծրագրային ապահովման մշակման և պահպանման հետ կապված: Այն նկարագրում է միայն այն խմբերը, որոնք ճանաչված են որպես արտադրական գործընթացի արտադրողականության հիմնական որոշիչներ:

Նպատակներ. CMM-ում նպատակները կապված չեն գործընթացների, այլ հիմնական գործընթացների խմբերի հետ: Ինչպես նշվեց վերևում, նպատակները ձեռք են բերվում հիմնական պրակտիկաների իրականացման միջոցով: CMM-ում նպատակին հասնելը նշանակում է, որ նախ՝ առանցքային պրակտիկաների ներդրումից հետո ստացվում է ցանկալի արդյունք, և երկրորդ՝ ստացվում է բավականին հետևողական։ Հիմնական գործընթացների խմբի նպատակներին հասնելու ձևը կարող է տարբերվել ծրագրից նախագիծ՝ պայմանավորված տարբերությունների. առարկայական տարածքկամ միջավայր։

Եթե ​​այս նպատակները իրագործվում են բոլոր նախագծերի համար, ապա դա նշանակում է, որ կազմակերպությունը հասել է արտադրական գործընթացի հասունության մակարդակին, որը փոխկապակցված է. այս խումբըհիմնական գործընթացները:

Գլուխ. Բաժինները (յուրաքանչյուր մակարդակում դրանք հինգն են, և դրանք միշտ նույնն են) ներկայացնում են հիմնական գործընթացների խմբերի հատկությունները, որոնք պետք է իրականացվեն համապատասխան մակարդակում: Այս հատկությունները նկարագրում են, թե ինչպես են գործընթացներն իրականացվում և որքանով են դրանք օրինականացված կազմակերպությունում, այսինքն՝ պաշտոնապես հաստատված և համաձայնեցված կորպորատիվ ընթացակարգերի, քաղաքականության և այլ գործընթացների հետ: Ահա հինգ բաժինները:

Կատարման պարտավորություններ

Նկարագրեք այն գործողությունները, որոնք կազմակերպությունը պետք է ձեռնարկի` ապահովելու, որ գործընթացը հաստատված է և կայուն: Կատարման պարտավորությունները սովորաբար վերաբերում են կազմակերպչական քաղաքականության հաստատմանը և բարձրագույն ղեկավարության աջակցությանը:

Նախադրյալներ

Նկարագրեք այն նախադրյալները, որոնք պետք է բավարարվեն նախագծում կամ կազմակերպությունում՝ արտադրական գործընթացի իրավասու իրականացման համար. սովորաբար կապված է ռեսուրսների հետ, կազմակերպչական կառույցներև պահանջվում է վերապատրաստում:

Գործողություններն ընթացքի մեջ են

Գործողություններն ընթացքի մեջ են բաժինը նկարագրում է այն բովանդակային աշխատանքը, որը պետք է կատարվի այս մակարդակում: Կատարված գործողությունները սովորաբար ներառում են պլանների ստեղծում և կոնկրետ գործողությունների իրականացում, աշխատանքների կատարում և հետևում, ինչպես նաև անհրաժեշտության դեպքում ուղղիչ գործողությունների կատարում:

Չափումներ և վերլուծություն

Բաժին «Չափումներ և

«Առանցքային գործընթացների յուրաքանչյուր խումբ արտահայտվում է հիմնական պրակտիկաներով, որոնց իրականացումը նպաստում է խմբի նպատակների իրականացմանը: Հիմնական պրակտիկաները նկարագրում են ենթակառուցվածքները և գործողությունները, որոնք առավելապես նպաստում են հիմնական գործընթացների խմբի արդյունավետ իրականացմանը և ստեղծմանը:

Յուրաքանչյուր հիմնական պրակտիկա բաղկացած է մեկ նախադասությունից, որին հաճախ հաջորդում է ավելի մանրամասն նկարագրությունը, որը կարող է ներառել օրինակներ և պարզաբանումներ: Հիմնական պրակտիկաներ, որոնք երբեմն կոչվում են հիմնական պրակտիկա բարձր մակարդակ, հիմնել հիմնական քաղաքականությունները, ընթացակարգերը և գործողությունները մի խումբ հիմնական գործընթացների համար: Բաղադրիչներ մանրամասն նկարագրությունհաճախ կոչվում են ենթապրակտիկա»:

Հիմնական պրակտիկաները նկարագրում են, թե ԻՆՉ է պետք անել, բայց դրանք չպետք է ընկալվեն որպես դոգմա այն մասին, թե ԻՆՉՊԵՍ պետք է հասնել նպատակներին: Հիմնական գործընթացների խմբի նպատակներին կարելի է հասնել այլընտրանքային պրակտիկայի միջոցով: Հիմնական պրակտիկայի մեկնաբանումը պետք է լինի ողջամիտ՝ թույլ տալով հասնել հիմնական գործընթացների խմբի նպատակներին. արդյունավետ միջոց, չնայած, գուցե, պաշտոնապես և տարբերվում է առաջարկվող CMM-ից:

Հայացք ՏՏ կառավարման գործունեությանը, որտեղ գործընթացների փոխարեն դիտարկվում են դրանց բաղադրիչները՝ հիմնական պրակտիկաները, և գործընթացները ներկա են միայն վիրտուալ, քանի որ այն, որը կարելի է կառուցել հիմնական պրակտիկաներից, առաջին հայացքից մի փոքր էկզոտիկ է թվում: Մինչ այժմ ՏՏ կառավարման կատարելագործման խնդիրը լուծվում էր ռեֆերենս գործընթացի մոդելից պատրաստի գործընթացների ներդրմամբ։ Այժմ կա մի շարք մակարդակներ, որոնք պարունակում են տարբեր (այսինքն՝ գործընթացներին չինտեգրված) հիմնական պրակտիկաներ և մակարդակների միջով շարժվելու առաջարկվող հաջորդականություն: ՏՏ կառավարումը, ըստ CMM-ի, բարելավվում է, քանի որ այն անցնում է հասունության ավելի բարձր մակարդակի: Ի՞նչ է տեղի ունենում այս խթանման հետ:

Մակարդակների սահմանումներում (տե՛ս Նկար 7.2) հայտնվել է այնպիսի բան, ինչպիսին է «արտադրական գործընթաց»: Այն առկա է նաև առանցքային գործընթացների խմբի սահմանման մեջ, և դա պատահական չէ։ Արտադրական գործընթացը, կամ ինչպես այն ճիշտ է կոչվում CMM-ում՝ Ստանդարտ Արտադրական գործընթացըԿազմակերպությունները (OSS) ամբողջ մոդելի կենտրոնական հասկացություններից մեկն է:

1986 թվականի նոյեմբերին Ամերիկյան Ծրագրային ճարտարագիտության ինստիտուտը (SEI), Mitre Corporation-ի հետ համատեղ, սկսեց մշակել ծրագրային ապահովման մշակման գործընթացի հասունության հարցում, որը նպատակ ուներ օգնել բարելավելու իրենց ներքին գործընթացները:

Այս վերանայման մշակումը պայմանավորված էր ԱՄՆ դաշնային կառավարության կողմից ծրագրային ապահովման մշակման ենթակապալառուների գնահատման մեթոդի խնդրանքով: Իրական խնդիրը կառավարելու անկարողությունն էր մեծ նախագծեր. Շատ ընկերություններում նախագծերը ներկայացվել են զգալիորեն ուշ և բյուջեից ավելի: Պետք էր լուծում գտնել այս խնդրին։

1987 թվականի սեպտեմբերին SEI-ն հրապարակեց ծրագրային ապահովման մշակման գործընթացների ամփոփագիրը, որը նկարագրում էր դրանց հասունության մակարդակները, ինչպես նաև հարցաթերթիկ, որը նախատեսված էր ընկերությունում այն ​​ոլորտները բացահայտելու համար, որտեղ բարելավումներ են անհրաժեշտ: Այնուամենայնիվ, ընկերությունների մեծ մասը այս հարցաշարը համարել է որպես ավարտված մոդել, ինչի արդյունքում 4 տարի անց հարցաշարը վերածվեց իրական մոդելի՝ Ծրագրային ապահովման կարողությունների հասունության մոդելի (CMM): CMM-ի առաջին տարբերակը (տարբերակ 1.0), որը թողարկվել է 1991 թվականին, վերանայվել է 1992 թվականին աշխատանքային հանդիպման մասնակիցների կողմից, որին մասնակցել են ծրագրային ապահովման շուրջ 200 մասնագետներ և մշակողների հասարակության անդամներ:

Արդյունքում այն ​​ազատ է արձակվել CMM ստանդարտ, Տարբերակ 1.1, որը դեռ ակտիվորեն օգտագործվում է ամբողջ աշխարհում։

Բրինձ. 1. SMM-ի օգտագործման գլոբալ ազդեցությունը

SMM-ի նկատմամբ այս հետաքրքրության պատճառները պարզ են. Չնայած այն հանգամանքին, որ և՛ իրենք՝ ծրագրային ապահովման մշակողները, և՛ նրանց ղեկավարությունը հաճախ շատ տեղյակ են իրենց մշտական ​​խնդիրների մասին, նրանք չեն կարողանում համաձայնության գալ այն մասին, թե ի սկզբանե ինչ փոփոխություններ են անհրաժեշտ ընկերությանը: Առանց բարելավման միասնական ռազմավարություն մշակելու, ղեկավարությունը չի կարող փոխըմբռնում գտնել իր աշխատակիցների հետ՝ կապված բարելավման ամենաառաջնահերթ խնդիրների հետ: Գործընթացների բարելավման վրա ծախսված ջանքերից առավելագույն արդյունքի հասնելու համար անհրաժեշտ է ունենալ զարգացման փուլային ռազմավարություն, որը աստիճանաբար, էվոլյուցիոն ճանապարհով կբարելավի զարգացման գործընթացների հասունությունը:

Գործընթացի շարունակական բարելավումը հիմնված է ընկերության մշակույթի աստիճանական աճեցման, այլ ոչ թե հեղափոխական նորարարությունների իրականացման վրա: CMM-ն ապահովում է այս աստիճանական բարելավման ծրագիր՝ բաժանված գործընթացի հասունության 5 մակարդակների: Այս 5 մակարդակները սանդղակ են ընկերությունում ծրագրային ապահովման մշակման գործընթացների հասունության մակարդակը գնահատելու և դրանց պարամետրերը չափելու համար:

Բրինձ. 2. Հասունության մակարդակի առաջանցիկ բարձրացման սկզբունք՝ կազմակերպության զարգացման հնարավորություններ

Ահա յուրաքանչյուր մակարդակի հիմնական բնութագրերը.

1. Նախնական - Զարգացման գործընթացը քաոսային է: Գործընթացներից քչերն են սահմանված, և նախագծերի հաջողությունը կախված է առանձին դերակատարներից:
2. Կրկնվող - Հիմնադրվել են ծրագրի կառավարման հիմնական գործընթացները՝ ծախսերի հետևում, աշխատանքային գրաֆիկ և ֆունկցիոնալություն: Հեշտացրել է որոշ գործընթացներ, որոնք անհրաժեշտ են նմանատիպ նախագծերում նախորդ ձեռքբերումները կրկնելու համար (նման կիրառական ծրագրերով):
3. Սահմանված - Ծրագրային ապահովման մշակման և նախագծերի կառավարման գործընթացները նկարագրված և իրականացված են միասնական համակարգընկերության գործընթացները: Բոլոր նախագծերն օգտագործում են կազմակերպության համար ծրագրային ապահովման մշակման և աջակցության ստանդարտ գործընթաց՝ հարմարեցված կոնկրետ նախագծին:
4. Կառավարվող - Հավաքում է մանրամասն քանակական տվյալներ զարգացման գործընթացների գործունեության և որակի վերաբերյալ վերջնական արտադրանք. Վերլուծվում են այս տվյալների նշանակությունը և դինամիկան:
5. Օպտիմալացում - Գործընթացների շարունակական բարելավումը հիմնված է գործընթացների քանակական տվյալների և նոր գաղափարների և տեխնոլոգիաների փորձնական ներդրման վրա:

SW-CMM-ի ներածություն

(ծրագրային ապահովման մշակման գործընթացների հասունության բարելավում` հիմնված Ծրագրային ապահովման ճարտարագիտական ​​ինստիտուտի կարողությունների հասունության մոդելի վրա)

Դասընթացը նախատեսված է.
Ծրագրային ապահովման մշակման ընկերությունների ղեկավարների, ծրագրային ապահովման մշակման բաժինների և նախագծերի ղեկավարների և որակյալ մասնագետների համար, ովքեր հետաքրքրված են.

առկա արտադրական գործընթացների թափանցիկության բարելավում.

գործընթացների և ամբողջ ընկերության արտադրողականության բարձրացում.

արտադրության ինքնարժեքի և առկա «թաքնված» արտադրության ծավալների կրճատում.

ընկերության հեղինակության բարելավում մասնագիտական ​​միջավայրում.

ապրանքների համար նոր շուկաների բացում.

2.1 Արժեքը, տևողությունը և արդյունքները: Արդյունաբերության վիճակագրություն
2.2 CMM-ում ներդրումների վերադարձը

3.1 TQM (ընդհանուր որակի կառավարում), SPI (Ծրագրային գործընթացի բարելավում) և լավագույն բիզնես պրակտիկան որպես CMM-ի հիմք
3.2 Հիմնական հասկացություններ TQM. TQM մոտեցումների կիրառում ծրագրային ապահովման արտադրանքի արտադրության մեջ
3.3 CMM գործընթացի բարելավման մոդելի առավելություններն ու ռիսկերը
3.4 Գործընթացի հայեցակարգ. Գործընթացային մոտեցման հիմնական բաղադրիչները
3.5 Գործընթացի հասունության մակարդակները

9.1 ՏՏ ոլորտի ստանդարտների համակարգ (ճանապարհային քարտեզ)
9.2 ISO-ի կապը CMM-ի հետ, Ռացիոնալ միասնական գործընթաց, Ծրագրի կառավարում
9.3 CMM հավելված փոքր կազմակերպությունների համար
9.4 Ինչ չկա SMM-ում
9.5 Փաստաթղթեր և գործընթացներ

10.1 SW-CMM-ի վերջնական վերանայում: Բաշխում աշխարհում. Հիմնական դժվարությունները
10.2 CMMI (Capability Maturity Model Integration) - CMM մոդելի հետագա զարգացում

Սլայդների հավաքածու, գործնական ուսումնական նյութեր, լրացուցիչ նյութեր ինքնուրույն ուսումնասիրության համար:

SW-CMM-ի վերաբերյալ փաստաթղթերի ամբողջական փաթեթ (ստանդարտի տեքստը, գնահատման մեթոդները, ոլորտի վիճակագրությունը, փաստաթղթերի օրինակներ)

Գործնական դասընթաց ՏՏ ընկերություններում SW-CMM մոդելի ներդրման տեխնոլոգիայի վերաբերյալ

Համառոտ նշում.
Այս դասընթացի նպատակն է օգնել ընկերություններին ինքնուրույն և գրագետ պլանավորել և իրականացնել աշխատանք գործընթացի հասունության բարելավման մոդելի ներդրման ուղղությամբ, օգնել խուսափելու ընդհանուր սխալներև իրականացման ընթացքում առաջացած խնդիրները:

Դասընթացը նախատեսված է.
Դասընթացը նախատեսված է ծրագրային ապահովման մշակմամբ զբաղվող ձեռնարկությունների և ստորաբաժանումների մենեջերների, նախագծերի մենեջերների, որակի մենեջերների և այլոց համար, ովքեր հետաքրքրված են իրենց մշակումների որակի բարելավմամբ և CMM-ի համար իրենց գործընթացի հավաստագրմամբ:

ՏՏ որակի կառավարման ոլորտում ճանաչված ստանդարտների ակնարկ (ISO 9000, SW-CMM, CMMI, TickIT, SPICE)

17. Դեպի CMM ISO-ի միջոցով?

Կազմակերպչական գործընթացների կառավարման 5 էվոլյուցիոն փուլ. Հնարավորությունների հասունության մոդելի բացատրություն ֆունկցիոնալությունը): CMM

Հնարավորությունների հասունության մոդել CM-CEI կազմակերպչական մոդել, որը նկարագրում է 5 էվոլյուցիոն փուլերը (մակարդակները), որոնցով կառավարվում են կազմակերպությունում տեղի ունեցող գործընթացները։

Ի սկզբանե ստեղծված ծրագրային ապահովման մշակման համար, Կարողությունների հասունության մոդելի իմաստն այն է, որ կազմակերպությունը պետք է կարողանա ընդունել և աջակցել իր ծրագրային հավելվածները: Մոդելը նաև առաջարկում է կոնկրետ քայլեր և նախաձեռնություններ, որոնք կօգնեն կազմակերպությանը զարգացնել հաջորդ մակարդակ:

Կարողությունների հասունության մոդելի 5 փուլերը

Սկզբնական (գործընթացները ժամանակավոր են, քաոսային, կամ իրականում դրանցից քչերը սահմանված են) Կրկնվող (հիմնական գործընթացները հաստատված են, և կա կարգապահություն, որը կառչում է այդ գործընթացներին) Սահմանված (բոլոր գործընթացները սահմանված են, փաստաթղթավորված), միասնական և ինտեգրված) Կառավարվող ( գործընթացները չափվում են գործընթացների և դրանց որակի վերաբերյալ մանրամասն տվյալների համախմբմամբ) Օպտիմիզացում (օպտիմիզացում) ( շարունակական զարգացումգործընթաց՝ քանակական հետադարձ կապի և նոր գաղափարների և տեխնոլոգիաների փորձարկման միջոցով)

Ծրագրային ապահովման մշակման մոդել

CMM-ը նկարագրում է այն սկզբունքներն ու գործելակերպերը, որոնք ընկած են ծրագրային ապահովման գործընթացի հասունության հայեցակարգի հիմքում: Դրանք նախագծված են օգնելու ծրագրային ապահովման մշակման և վաճառքի ընկերություններին բարելավելու իրենց ծրագրային գործընթացների բարդությունը էվոլյուցիոն ճանապարհով: Սկսած ժամանակավոր, քաոսային գործընթացներից, անցնելով հասուն, կարգապահ ծրագրային գործընթացներին: Ուշադրության կենտրոնում է գտնվում հիմնական գործընթացների ոլորտները և օրինակելի պրակտիկաները, որոնք կարող են լինել կարգապահ ծրագրային գործընթացներ: CMM հասունության հայեցակարգը ստեղծում է մի համատեքստ, որտեղ.

Պրակտիկան կարող է կրկնվել։ Եթե ​​դուք չեք կրկնում ինչ-որ գործողություն, ապա չպետք է բարելավեք այն։ Կան կանոններ, ընթացակարգեր և պրակտիկա, որոնք ստիպում են կազմակերպությանը իրականացնել և հետևողականորեն կատարել: Արտադրական աշխատանքի կազմակերպման լավագույն փորձը կարող է արագորեն տարածվել խմբերի միջև: Պրակտիկան սահմանվում է նախագծերի միջև փոխանակում թույլ տալու համար՝ այդպիսով որոշակի ստանդարտացում ապահովելով կազմակերպության համար: Այս մեթոդների կատարման հետ կապված շեղումները նվազագույնի են հասցվում: Առաջադրանքների համար սահմանվում են քանակական նպատակներ. և չափումները սահմանվում, արտադրվում և պահպանվում են գնահատման համար հիմք հանդիսանալու համար: Գործողությունները շարունակաբար բարելավվում են՝ բարելավելու հնարավորությունները (օպտիմալացում):

Կարողությունների հասունության մոդելը օգտակար է ոչ միայն ծրագրային ապահովման մշակման համար, այլ նաև ընդհանուր առմամբ կազմակերպությունների էվոլյուցիոն մակարդակները նկարագրելու և կառավարման մակարդակը նկարագրելու համար, որը կազմակերպությունն իրականացրել է կամ ցանկանում է հասնել:

Առանձնահատկությունների զարգացման մոդելի կառուցվածքը

Հասունության մակարդակները շերտավոր հասկացություն են, որն ապահովում է կարգապահության հետևողականությունը, որն անհրաժեշտ է շարունակական բարելավմանը հասնելու համար: Այստեղ կարևոր է նշել, որ կազմակերպությունը զարգացնում է նոր պրակտիկայի, տեխնոլոգիայի կամ գործիքի հետևանքները գնահատելու կարողությունը: Հետևաբար, խոսքը ոչ թե այս նորամուծությունների ընդունման մասին է, այլ այն, թե ինչպես են այդ նորարարական ջանքերն ազդում առկա պրակտիկայի վրա: Այն աջակցում է նախագծերին, խմբերին և կազմակերպություններին՝ հիմք տալով նրանց տեղեկացված ընտրությունների համար: Հիմնական գործընթացների ոլորտները - Հիմնական գործընթացի տարածքը (KPA) սահմանում է հարակից գործողությունների խումբ, որոնք, երբ իրականացվում են միասին, հասնում են մի շարք կարևոր նպատակների: Նպատակներ - Հիմնական գործընթացի տարածքի նպատակները նկարագրում են այն դրույթները, որոնք պետք է գոյություն ունենան գործընթացի հիմնական ոլորտի համար: Կանոնակարգերը պետք է իրականացվեն արդյունավետ և անվտանգ ձևով: Նպատակների իրագործման չափը ցույց է տալիս, թե ինչպիսի կարողություններ է կազմակերպությունը հաստատել այդ գերազանցության մակարդակում: Նպատակները սահմանում են յուրաքանչյուր հիմնական գործընթացի շրջանակը, սահմանները և նպատակը: Ընդհանուր բնութագրեր - Ընդհանուր բնութագրերը ներառում են պրակտիկաներ, որոնք իրականացնում և ինստիտուցիոնալացնում են հիմնական գործընթացների ոլորտները: Այս 5 տեսակները ընդհանուր բնութագրերըներառում են՝ Կատարելու պարտավորություն, Կատարելու կարողություն, Կատարվելիք Նախաձեռնություններ, Չափում և վերլուծություն և Իրականացման վերահսկում: Հիմնական պրակտիկա - Հիմնական պրակտիկաները նկարագրում են ենթակառուցվածքի տարրերն ու գործելակերպերը, որոնք առավել արդյունավետ կերպով նպաստում են հիմնական գործընթացների ոլորտների իրականացմանը և ինստիտուցիոնալացմանը:

Գործընթացի սահմանման չափանիշներ

Գործընթացը սահմանելու չափանիշները գործընթացի տարրերի մի շարք են, որոնք պետք է ներառվեն ծրագրային գործընթացի նկարագրության մեջ, որպեսզի մարդիկ կարողանան դրանք գործնականում օգտագործել: Չափորոշիչներ սահմանելու համար պետք է հարց տալ.

Ներածություն

Ժամանակակից բարդ համակարգերի ամենակարևոր մասը ծրագրային արտադրանքներն են՝ ինտելեկտուալ բաղադրիչը: Ծրագրային արտադրանքներն այժմ օգտագործվում են մարդկային գործունեության գրեթե բոլոր ոլորտներում կառավարման խնդիրները լուծելու համար՝ տնտեսության, սոցիալական, ռազմական և այլ ոլորտներում: Ներքին ծրագրային ապահովման արտադրանքի բարձր որակի ապահովումը երկրում և համաշխարհային շուկայում դրանց զանգվածային մշակման և կիրառման տարբեր ոլորտներում առաքման ընթացքում դարձել է. ռազմավարական նպատակ.

Ներկայումս ծրագրային ապահովման ճարտարագիտության և ծրագրային արտադրանքի որակի ապահովման ստանդարտացման երկու գրեթե անկախ ոլորտներ կան, որոնք պայմանականորեն կարելի է անվանել ISO ստանդարտների պրոֆիլներ ( միջազգային կազմակերպությունստանդարտացում) և SEI (ԱՄՆ Ծրագրային ճարտարագիտական ​​ինստիտուտ) հասունության մոդելները: Առաջինները լիովին ներկայացված են [ , ]-ում, իսկ երկրորդները՝ [ , ]-ում։ Հոդվածի հիմնական բովանդակությունը նվիրված է հասունության մոդելներին։

Համալիր ծրագրային արտադրանքների աշխարհում մրցունակությունն ապահովելու և դրանց հաջող արտահանման հնարավորությունը ապահովելու համար դրանք պետք է մշակվեն և հավաստագրվեն պահանջներին համապատասխան: միջազգային ստանդարտների պրոֆիլներհիմքի վրա ISO 9000:2000կամ հասունության մոդելներ - CMMI: 2003 թ(Capability Maturity Model Integration - Ինտեգրված ծրագրային ինժեներական հասունության գնահատման մոդել): Այս երկու ուղղությունները մեթոդաբանորեն շատ մոտ են և մասամբ հատվում են փոխադարձ հղումների միջոցով։

Տեխնիկական և տնտեսական ցուցանիշների և ծրագրային ապահովման արտադրանքի որակի բարելավումը, ինչպես նաև սխալների և թերությունների կանխումը ապահովվում է ժամանակակից ծրագրային ինժեներական տեխնոլոգիաների և համակարգերի կիրառմամբ։ համակարգչային օժանդակ դիզայն. Սրանք բարձր արդյունավետությամբ, ռեսուրս խնայող տեխնոլոգիաներ են՝ բարձր որակի, հուսալիության և անվտանգության ծրագրային համալիրներ ստեղծելու համար, որոնք ուղղված են ծրագրային գործիքների (PS) նախագծման, ներդրման և սպասարկման ռեսուրսների ընդհանուր արժեքի նվազեցմանը: Դրա համար առաջին հերթին անհրաժեշտ է կիրառել վերլուծության և նախագծման մեթոդներ և գործիքներ՝ ի սկզբանե ապահովելով կոնկրետացում և նպատակների, նպատակների և գործառույթների առավել ճշգրիտ ներկայացում: կյանքի ցիկլ(LC) PS-ի և կանխելով համակարգի հնարավոր թերությունների տարածումը զարգացման հետագա փուլերում: Ծրագրային ինժեներական նման տեխնոլոգիաները հնարավորություն են տալիս վերացնել կամ զգալիորեն նվազեցնել համակարգային, ալգորիթմական և ծրագրային սխալների մակարդակը շահագործման համար փոխանցված ծրագրային արտադրանքներում: Բացի այդ, դրանք արդյունավետ են ծրագրային ապահովման փոփոխման և պահպանման, ինչպես նաև փոփոխությունների մեջ արտաքին միջավայր.

Բարդ, կարևոր համակարգերի օգտագործման որակը, հուսալիությունը և անվտանգությունը հավաստելու համար դրանցում օգտագործվող ծրագրային արտադրանքները ենթարկվում են. սերտիֆիկացումհավաստագրված, խնդրահարույց փորձարկման կենտրոններ կամ լաբորատորիաներ: Նման փորձարկումները պետք է իրականացվեն, երբ ծրագրերը կառավարում են բարդ, կրիտիկական գործընթացները կամ մշակում այնպիսի կարևոր տեղեկատվություն, որ դրանց թերությունները կամ անբավարար որակը կարող են զգալի վնաս պատճառել: Հավաստագրման թեստերը պետք է հաստատեն ծրագրային համալիրների համապատասխանությունը փաստաթղթերի պահանջներին և թույլ տան նրանց գործել թեստերի ընթացքում ուսումնասիրված արտաքին միջավայրի պարամետրերի փոփոխությունների սահմաններում: Այս տեսակի թեստերը բնութագրվում են ստուգումների ամենամեծ խստությամբ և խորությամբ և պետք է իրականացվեն մշակողներից և հաճախորդներից (օգտագործողներից) անկախ մասնագետների կողմից:

Հավաստագրման հիմքը պետք է լինի մանրամասն և արդյունավետ ծրագրերն ու մեթոդները՝ ծրագրային փաթեթների ստանդարտացված հաճախորդների պահանջներին համապատասխանելու համար, հատուկ նախագծված թեստային խնդիրներն ու դրանց ձևավորման գեներատորները, ինչպես նաև թեստավորողների բարձր որակավորումն ու հեղինակությունը: Ծրագրային արտադրանքի, որակի հավաստագրված համակարգերի, պահանջների վրա հիմնված PS-ի կյանքի ցիկլը ապահովելու համար կիրառություն ձեռնարկություններում. ISO 9000:2000կամ CMMI: 2003 թ, երաշխավորում է դրանց կյանքի ցիկլի գործընթացների և արտադրանքի բարձր, կայուն որակի կառավարումը, ինչպես նաև թույլ է տալիս շատ դեպքերում հեշտացնել վերջնական ծրագրային արտադրանքի հավաստագրումը: Հետևաբար, բարդ ծրագրային նախագծերի հաճախորդները հակված են ընտրել իրականացնող կապալառուներին, ովքեր ունեն որակի ապահովման համակարգերի կիրառումը հավաստող վկայականներ՝ հիմնված համապատասխանեցված միջազգային ստանդարտների պրոֆիլների կամ հասունության մոդելների վրա:

Ծրագրային ճարտարագիտության մեթոդների ուսուցման բացթողումները լայն լուսանցք են թողնում մասնագետների կամայականության համար իրենց աշխատանքի որակը գնահատելու, ինչպես նաև ծրագրային նախագծերում բազմաթիվ թերությունների և սխալների առաջացման համար: Բարդության և պատասխանատվության բարձրացում ժամանակակից առաջադրանքներԾրագրերով լուծված, ինչպես նաև դրանց արդյունքների անբավարար որակի հնարավոր վնասը զգալիորեն մեծացրել է որակի բնութագրերի պահանջների և դրանց իրական, ձեռք բերված արժեքների չափման մեթոդների ամբողջական, ստանդարտացված նկարագրության մեթոդների յուրացման արդիականությունը։ ծրագրային ապահովման կյանքի ցիկլի տարբեր փուլերում: Կտրուկ աճել է ծրագրային ապահովման արտադրանքի որակի բնութագրերի գնահատման հասկացությունների, սահմանումների և մեթոդների իմացության մասնագետների անհրաժեշտությունը։

Ծրագրային համալիրների արագ աճն ու բարդացումը հանգեցնում է աշխատանքի պրոֆեսիոնալ բաշխմամբ մեծ ծրագրավորման թիմերի ստեղծմանը, որոնցում անհրաժեշտ է կարգավորել մասնագետների խմբերի համակարգված գործունեությունը մեկ նախագծի վրա: Պայմանագրերում ծրագրավորողների խոստումները՝ համաձայնեցված ժամկետներում բարձրորակ ծրագրակազմ մատակարարելու վերաբերյալ, հաճախ չեն պահպանվում: Հաճախ դա տեղի է ունենում այն ​​պատճառով, որ պատվիրատուն և կապալառուն գնահատում են որակի մակարդակը տարբեր չափանիշներով, և նրանք համաձայնություն չունեն այս հարցում, և ծրագրերի որակը գնահատելու մոտեցումը բավականաչափ ձևավորված չէ: Բացի այդ, երբեմն ի հայտ է գալիս բարձր որակի ծրագրերի հասնելու համար անհրաժեշտ ռեսուրսները ճիշտ գնահատելու կարողության պակաս: Արդյունքում, ծրագրային ապահովման արտադրանքի որակը հաճախ մնում է ցածր, անվստահելի և անմրցունակ միջազգային շուկայում: Հետևաբար, շատերի զարգացման և կիրառման կարևորագույն խնդիրը ժամանակակից համակարգերծրագրային ապահովման ճարտարագիտության ոլորտում մասնագետների պատրաստումն ու կրթությունն է, միջազգային ստանդարտների կիրառումը, որոնք նպաստում են ծրագրային ապահովման բարձր որակին և դրա հուսալի գնահատմանը, որի հիմնական նպատակն է՝ իրականացնել նախագծային գործընթացներ: կառավարելի, և արդյունքներն են կանխատեսելի. Անհրաժեշտ է կարողանալ ձևակերպել պահանջները և հասնել բարդ ծրագրային փաթեթների գործունեության որակի և կիրառման բնութագրերի հատուկ արժեքների՝ հաշվի առնելով այն ռեսուրսները, որոնք առկա են այդ որակն ապահովելու և բարելավելու համար:

CMMI մարման մոդել - 1.1կատարելագործում և կատարելագործում է նախորդ մոդելները CMM(տես ), ինչպես նաև մասամբ հաշվի է առնում ծրագրային ապահովման կառավարման ոլորտում գործող միջազգային ստանդարտների հիմնական պահանջները։ Զգալի ուշադրություն է CMMIտրվում է զարգացման գործընթացներին և հաճախորդի պահանջները փոխելու ժամանակ կրկնությունների հաշվառմանը, դրանց հետագծելիությանը մինչև գործառույթները, բաղադրիչները, թեստերը և նախագծային փաստաթղթերը: IN Վերջերստեղեկություններ կային 2003 թվականի տարբերակի SEI տարբերակի արդիականացման մասին CMMI-1.1կուտակված փորձի և ձեռնարկությունների հետադարձ կապի հիման վրա: Ենթադրվում է, որ այն 2006 թվականին կթողարկի մոդելի նոր՝ զգալիորեն արդիականացված տարբերակը CMMI-1.2, որից հետո 1.1 տարբերակը պետք է աստիճանաբար հանվի։ Մինչև 2007 թվականի վերջ օգտատերերը պետք է անցնեն տարբերակին CMMI-1.2, իսկ ապագայում պարտադիր կդառնա ծրագրային ապահովման ճարտարագիտության ոլորտում ձեռնարկության տեխնոլոգիաների որակի (սերտիֆիկացման) պաշտոնական գնահատման համար։ Վկայագրի գործողության ժամկետը կսահմանափակվի երեք տարով: Խոշոր ծրագրային համակարգերի հաճախորդները և մշակողները պետք է պատրաստվեն այս փոփոխություններին մինչև SEI-ի կողմից 1.2 տարբերակի պաշտոնական հրապարակումը:

CMMI մարման մոդելի կառուցվածքը և բովանդակությունը - 1.1

Երկու մոդելի տարբերակ CMMI-1.1նախատեսված է ապահովելու համար շարունակականծրագրային ապահովման մշակման որոշակի ոլորտում գործընթացների մի շարք գնահատում կամ դրա համար փուլայինձեռնարկության հասունության գնահատումն ու բարելավումը, ինչպես նաև ընդհանրապես ծրագրային համալիրների կյանքի ցիկլը կազմակերպելու համար։ Մոդելներ CMMIօգնություն ցուցաբերել մասնագետներին իրենց արտադրանքը կազմակերպելու և կատարելագործելու, ինչպես նաև PS-ի մշակման և պահպանման գործընթացները պարզեցնելու և սպասարկելու հարցում: Այս մոդելների հայեցակարգն ընդգրկում է բարդ համակարգերի հասունության կառավարումն ու գնահատումը, ծրագրային ճարտարագիտությունը, ինչպես նաև ինտեգրված ծրագրային արտադրանքի ստեղծման և դրանց զարգացման բարելավման գործընթացները: Շարունակական և փուլային մոդելների բաղադրիչները հիմնականում նման են, և կարող են ընտրվել և կիրառվել տարբեր կազմով և օգտագործման հաջորդականությամբ՝ կախված կոնկրետ նախագծերի հատկություններից և բնութագրերից:

Մոդելի նկարագրության տարբերակները կառուցված են մեկ սխեմայի համաձայն, որը ներառում է ընդհանուր բաժիններ.

• առաջաբան;
• 1 բաժին - ներածություն;
• Բաժին 2 - բաղադրիչ մոդել;
• Բաժին 3 - տերմինաբանություն;
• Բաժին 4 - մոդելի յուրաքանչյուր տարբերակի մակարդակների և հիմնական բաղադրիչների բովանդակությունը (նպատակների և ընթացակարգերի մշակում);
• Բաժին 5 - գործընթացների փոխազդեցության կառուցվածքը; 7-րդ բաժնի գործընթացների չորս կատեգորիաները ծանոթագրված են, դրանց ընդհանուր ակնարկը և CMMI գործընթացների փոխազդեցության սխեմաները.
  • գործընթացի կառավարում;
  • կառավարում - ծրագրի կառավարում;
  • ճարտարագիտություն (տեխնոլոգիա);
  • աջակցություն;
• Բաժին 6. Մոդելի օգտագործումը CMMI- հակիրճ առաջարկություններ օգտագործողների համար մոդելի կիրառման և ուսուցման վերաբերյալ. նշվում է մոդելային գործընթացների համատեղելիությունը և համապատասխանությունը ստանդարտի 2-րդ և 3-րդ մասերում նախորդ CMM մոդելի կարգավորվող գործընթացներին. ISO 15504.
• Բաժին 7-ը վերջինն է, ամենամեծը յուրաքանչյուր ստանդարտում, այն զբաղեցնում է ընդհանուր փաստաթղթի մոտ 500 էջը, որը կազմում է ավելի քան 700 էջ: Այս բաժինը մանրամասն առաջարկություններ է տալիս դրանում թվարկված գործընթացներից յուրաքանչյուրի իրականացման համար, որոնք հաշվի են առնում որոշակի մոդելի բնութագրերը:

Առաջին տարբերակ(շարունակական) մոդելը արտացոլում է փաստաթուղթը. Հնարավորությունների հասունության մոդելի ինտեգրում (CMMI) համակարգերի ճարտարագիտության/ծրագրային ճարտարագիտության/ինտեգրված արտադրանքի և գործընթացի մշակման համար, տարբերակ 1.1, շարունակական ներկայացում (CMMI-SE/SW/IPPD, V1.1, շարունակական): Ինտեգրված համակարգերի ճարտարագիտություն/Ծրագրային ճարտարագիտություն/Ինտեգրված արտադրանքի և զարգացման գործընթացի հասունության գնահատման մոդել - շարունակական դիտում. Այս մոդելում յոթերորդ բաժինը բաղկացած է գործընթացներից.

• գործընթացի կառավարում.
  • վերապատրաստման կազմակերպում;
  • գործընթացների վերափոխման (փոփոխությունների) կազմակերպում.
  • նորարարությունների և ընդլայնումների կազմակերպում;
• ծրագրի կառավարում:
  • ծրագրի պլանավորում;
  • Ծրագրի գործընթացների մոնիտորինգ և վերահսկում;
  • Ռիսկերի կառավարում;
  • Ծրագրի քանակական կառավարում;
• ճարտարագիտություն (տեխնոլոգիա):
  • պահանջների կառավարում;
  • պահանջների մշակում;
  • տեխնիկական լուծումներ;
  • արտադրանքի ինտեգրում;
  • ստուգում;
  • վավերացում (ատեստավորում, հաստատում);
• աջակցություն:
  • կոնֆիգուրացիայի կառավարում;
  • փոփոխությունների վերլուծություն և որոշումներ կայացնել;
  • արմատական ​​պատճառի վերլուծություն և խնդրի լուծում (թերության վերացում):

Հինգ հավելվածները ներկայացնում են.

ԲԱՅՑ- օգտագործված գրական աղբյուրների և փաստաթղթերի կազմը, որտեղ, սակայն, ստանդարտներ չկան ISO;

IN- հապավումներ;

ԻՑ- բառարանի վրա հիմնված տերմինաբանություն ISOօգտագործվում է միայն չորս ստանդարտներում ISO 9000, ISO 12207, ISO 15504:1-9, ISO 15288;

Դ - մոդելային բաղադրիչների ձևավորման պահանջների և առաջարկների նկարագրություններ ըստ հասունության մակարդակների.

E - զարգացման մասնակիցների ցուցակ CMMI- նախագիծ.

Այս մոդելում ուշադրությունը կենտրոնացված է կազմակերպչական գործընթացների, ծրագրային ապահովման նախագծերի իրականացման գործընթացների պլանավորման, կառավարման և վերահսկման, ծրագրային ապահովման արտադրանքի պահանջների մշակման և կառավարման վրա: Ստորև բերված են մանրամասների օրինակներ CMMIնրանցից մի քանիսը:

Ծրագրի պլանավորումայս, ինչպես նաև երկրորդ մոդելում ներառում է.

• գնահատում հնարավոր չափըծրագրային արտադրանքի (սանդղակ);
• PS նախագծի գործառույթների և բնութագրերի բարդության գնահատում.
• Ծրագրային փաթեթի կյանքի ցիկլի մոդելի և փուլերի սահմանում.
• Ծրագրի տեխնիկատնտեսական հիմնավորում - ենթակայանի կյանքի ցիկլի արժեքի, աշխատանքի ինտենսիվության և տևողության որոշում.
• փուլային աշխատանքային գրաֆիկի և ծրագրի բյուջեի մշակում.
• ծրագրի ռիսկերի վերլուծություն, նույնականացում և գնահատում;
• PS ծրագրի կյանքի ցիկլի գործընթացների և արտադրանքների փաստաթղթերի պլանավորում և կառավարում.
• Տեխնիկական և կադրային ռեսուրսների պլանավորում և բաշխում` ըստ ՀԾ-ի կյանքի ցիկլի փուլերի.
• ծրագրի իրականացման համար մասնագետների թիմի գիտելիքների և որակավորումների տրամադրման պլանավորում.
• PS ծրագրի պլանների փաթեթի ընդհանրացում և վերլուծություն.
• Մշակողի կողմից կյանքի ցիկլի փուլերի աշխատանքների և ռեսուրսների համակարգում PS նախագծի հաճախորդի հետ.
• աշխատանքային պլանի փաստաթղթավորում և դրա հաստատում ծրագրի մշակողի ղեկավարի կողմից:

Պահանջների մշակման գործընթացներծրագրային արտադրանքի համար նման են երկու մոդելների գործընթացներին և ներառում են.

• Հաճախորդի և օգտագործողների իրական կարիքների նույնականացում ծրագրային արտադրանքի գործառույթների և բնութագրերի համար.
• Հաճախորդի և ծրագրավորողի միջև նախնական, հիմնական պահանջների մշակում և համակարգում ծրագրային արտադրանքի գործառույթների համար.
• Ծրագրային փաթեթի նախագծի առկա ռեսուրսների և սահմանափակումների որոշում.
• PS-ի գործառույթների հիմնական սկզբնական պահանջների տարրալուծումը ծրագրային փաթեթի բաղադրիչներին և թեստերին ներկայացվող պահանջների մի շարքի.
• Բաղադրիչների միջև ինտերֆեյսի պահանջների ձևակերպում, գործառնական և արտաքին միջավայրի հետ.
• Ծրագրային արտադրանքի հայեցակարգի և դրա օգտագործման սցենարների մշակում.
• ֆունկցիոնալ պիտանիության ընդհանրացված բնութագրերի պահանջների մշակում և ծրագրային արտադրանքի գործառույթների օգտագործումը նախատեսված նպատակի համար:

Պահանջների կառավարումերկու մոդելները ներառում են.

• Հաճախորդի և մշակողների կողմից PS նախագծի պահանջների միանշանակ ըմբռնում.
• հաճախորդի կողմից մշակողների կողմից ծրագրային արտադրանքի նկատմամբ իր բոլոր պահանջները կատարելու պարտավորությունների ձեռքբերում.
• հաճախորդի և մշակողի միջև համաձայնեցված PS նախագծի պահանջների փոփոխությունների կառավարում.
• Ապահովել PS նախագծի ընդհանուր պահանջներից մինչև բաղադրիչների և որոշակի գործընթացների պահանջների փոփոխությունների ճշգրտությունը.
• նախագծի մշակման գործընթացների և հաճախորդի պահանջների միջև անհամապատասխանությունների բացահայտում և բացահայտում:

Երկրորդ տարբերակներկայացնում է փաստաթուղթը. Հնարավորությունների հասունության մոդելի ինտեգրում (CMMI) Համակարգերի ճարտարագիտության/Ծրագրային ճարտարագիտության/Ինտեգրված արտադրանքի և գործընթացի մշակման համար, տարբերակ 1.1, փուլային ներկայացում (CMMI-SE/SW/IPPD, V1.1, Բեմականացված): Ինտեգրված համակարգերի ճարտարագիտություն/Ծրագրային ճարտարագիտություն/Ինտեգրված արտադրանքի և զարգացման գործընթացի հասունության գնահատման մոդել - փուլային ներածություն. Մոդելը հիմնված է հասունության հինգ մակարդակների հայեցակարգի պահպանման վրա CMM[ , ]։ Գործընթացների կազմը գործնականում կրկնում է վերը նշվածը մոդելի առաջին տարբերակի համար, բայց մի փոքր այլ հաջորդականությամբ և համեմատաբար փոքր հավելումներով:

Առաջին մակարդակբնութագրվում է տարբեր համեմատաբար պարզ նախագծերում գործընթացների կազմի և բովանդակության զգալի անորոշությամբ, հետևաբար այն չի մեկնաբանվում փաստաթղթում: Ուստի գործընթացների բովանդակությունը փուլային տարբերակով հստակեցնելու և մանրամասնելու ժամանակ CMMIխորհուրդ է տրվում սահմանափակվել չորս հիմնական մակարդակ:

• երկրորդ մակարդակ- պաշտոնականացնում է հիմնական կառավարումնախագծեր:
  • պահանջների կառավարում;
  • ծրագրի պլանավորում;
  • ծրագրի մոնիտորինգ և վերահսկում;
  • մատակարարների հետ պայմանագրերի կառավարում;
  • գործընթացների և արտադրանքի չափում և վերլուծություն;
  • գործընթացների և արտադրանքի որակի ապահովում.
  • կոնֆիգուրացիայի կառավարում;
• երրորդ մակարդակ- պարունակում է հիմնական գործընթացների ստանդարտացում.
  • պահանջների մշակում;
  • տեխնիկական լուծումներ;
  • արտադրանքի ինտեգրում;
  • ստուգում;
  • վավերացում (սերտիֆիկացում);
  • կազմակերպչական գործընթացների բովանդակությունը;
  • կազմակերպչական գործընթացների սահմանում;
  • վերապատրաստման կազմակերպում;
  • Ծրագրի գործընթացների և արտադրանքի ինտեգրված կառավարում;
  • Ռիսկերի կառավարում;
  • զարգացման թիմի ինտեգրում;
  • մատակարարների ինտեգրված կառավարում;
  • խնդիրների վերլուծություն և լուծում (թերությունների վերացում);
  • ինտեգրման համար միջավայրի կազմակերպում;
• չորրորդ մակարդակ- սահմանում է քանակական կառավարում.
  • գործընթացների որակի ներկայացման կազմակերպում.
  • ամբողջ ծրագրի և ռեսուրսների քանակական կառավարում.
• հինգերորդ մակարդակ- օպտիմալացում, շարունակական բարելավում.
  • կազմակերպում, նորարարություն, գործընթացների քանակական կառավարում և ռեսուրսների ապահովում.
  • թերությունների պատճառների վերլուծություն, գործընթացների և արտադրանքի որակի բարելավում և կառավարում:

Մոդելի երկրորդ տարբերակի հավելվածներն իրենց կազմով նման են առաջին մոդելի վերը նշված հավելվածներին: Հասունության յուրաքանչյուր բարձր մակարդակի դեպքում խորհուրդ է տրվում կիրառել բոլոր գործընթացներընախորդ ստորին մակարդակները. Մոդելի երկու տարբերակներում վերը նշված յուրաքանչյուր հիմնական գործընթաց մեկնաբանվում է դրա գործնական իրականացման մանրամասն առաջարկություններով, որոնք պարունակում են մոտ 20–30 էջերի նկարագրություններ՝ միասնական կառուցվածքով.

• գործընթացի ընդհանուր նպատակները, որոնք պետք է հասնել.
• ներածական դիտողություններ և ընդհանուր նկարագրությունըգործընթացի գործառույթներ;
• գործընթացի հատուկ նպատակներ;
• գործընթացի կառավարում;
• գործընթացի պահանջների մշակում;
• փոխազդեցություն և ինտերֆեյս այլ գործընթացների հետ;
• գործնական նպատակներ - գործընթացի գործունեության պահանջվող արդյունքները.
• որոշակի գործընթացում գործողությունների պլանավորում;
• գործընթացի իրականացման արդյունքների վերլուծություն և վավերացում (հաստատում);
• գործընթացի մոնիտորինգ և վերահսկում:

Այս առաջարկությունները հիմնական գործընթացների նկարագրությունների շրջանակի, բովանդակության և ամբողջականության առումով նման են PS Life Cycle Profile-ում ներկայացված մի շարք ստանդարտների: Օգտագործված գործընթացների ամբողջականության պատվիրումը և գնահատումը հասունության մակարդակներին համապատասխան, թույլ է տալիս հաստատել ձեռնարկությունների արտադրական ներուժը` ծրագրային արտադրանք մշակողներ գործընթացների կանխատեսվող որակի և դրանց գործունեության արդյունքների և սերտիֆիկացման պատրաստակամության առումով: համապատասխանությունը մոդելի հասունության որոշակի մակարդակին CMMI - 1.1.

Շեշտը մոդելների վրա CMMIտրվում է ՀԾ նախագծի կառավարման գործընթացներին։ Մոդելների այս պահանջները և գործընթացները գործնականում համապատասխանում են ստանդարտների կանոնակարգված և մանրամասն առաջարկություններին: ISO 9001:2000և բարդ PS կյանքի ցիկլի ստանդարտների պրոֆիլի հիմնական բաղադրիչները [ , ]: Ստանդարտների 4-8-րդ ֆունկցիոնալ բաժինների գործընթացներին ներկայացվող պահանջները ISO 9001, ISO 9004, ISO 90003Մոդելում կարելի է համեմատել բովանդակությամբ համարժեք մի շարք բաժիններ CMMI(նկ. 1-ում, բովանդակության համընկնման գոտի): Գործընթացների և պահանջների ընդհանրությունը բաղկացած է նմանությունից՝ կազմը, տերմինաբանությունը, կառուցվածքը, առաջարկվող կառավարման գործընթացների ցանկը, պլանավորումը, հասանելի ռեսուրսների հաշվառումը, ծրագրային ապահովման ինժեներական գործընթացների իրականացումը, մասնագետների գնահատումը և կազմակերպումը:

Գծապատկեր 1. Գործընթացների և ստանդարտների և հասունության մոդելների պահանջների ընդհանրություն

Խոշոր ծրագրային նախագծերի ողջ կյանքի ցիկլը աջակցելու և կարգավորելու տեսակետից, մոդելների թերությունները. CMMIառկա ստանդարտների պրոֆիլի վերաբերյալ ISOկարող է ներառել հետևյալը.

1998 թվականին մշակվել և ի սկզբանե հաստատվել է լայնածավալ տեխնիկական հաշվետվություն՝ վերը ներկայացված ՊՍ-ի կյանքի ցիկլի ապահովման գործընթացների հասունության մակարդակները որոշելու համար: ISO 15504, բաղկացած ինը մասից և բազմաթիվ հավելվածներից։ Այն ուրվագծում է հասունության մոդելը CMMև ստանդարտի վրա հիմնված ծրագրային ապահովման ճարտարագիտության ութ հիմնական սկզբունքներ ISO 9000:2000. Հետո ներս ISOայս փաստաթուղթը ենթարկվել է արմատական ​​վերանայման, կրճատման, կառուցվածքի և բովանդակության պարզեցման՝ ամբողջությամբ պահպանելով նպատակներն ու հայեցակարգը և հաստատվել է. որպես ստանդարտհինգ մասով.

Ստանդարտ ISO 15504:1-5:2003-2006կարգավորում է ձեռնարկությունների կողմից իրականացվող ծրագրային գործիքների և համակարգերի ստեղծման, պահպանման և կատարելագործման գործընթացների հասունության գնահատումն ու հավաստագրումը.

• հաստատել սեփական տեխնոլոգիական գործընթացների վիճակը և դրանց կատարելագործումը.
• որոշել սեփական գործընթացների համապատասխանությունը կոնկրետ պահանջներին կամ հաճախորդների պահանջների դասերին բավարարելու համար.
• ՀԾ և համակարգերի հաճախորդների հետ որոշակի պայմանագրերի կատարման համար դրա պիտանիության նպատակով:

Ստանդարտը նպաստում է. ձեռնարկությունների հասունության ինքնագնահատմանը, ատեստավորված գործընթացների համարժեք կառավարման ապահովմանը, գործընթացների վարկանիշների պրոֆիլի որոշմանը, ինչպես նաև համապատասխանում է ՕՀ-ի և համակարգերի ցանկացած շրջանակի և չափի: Ստանդարտի կիրառումն ուղղված է ձեռնարկությունների և մասնագետների զարգացմանը շարունակական կատարելագործման տեխնոլոգիական հասունության մշակույթԾրագրերի բիզնես նպատակներին համապատասխանող ՀԾ-ի կյանքի ցիկլի ապահովում և առկա ռեսուրսների օգտագործման օպտիմալացում: Ձեռնարկությունների գործընթացի հասունության գնահատումը հնարավորություն է տալիս համեմատելու և ընտրելու դրանք, որոնք նախընտրելի են որոշակի նախագծերի համար.

• հաճախորդների, գնորդների, ծրագրային ապահովման արտադրանքի և համակարգերի օգտագործողների համար. մատակարարի կյանքի ցիկլի գործընթացների ընթացիկ և պոտենցիալ հասունությունը որոշելու ունակություն.
• վաճառողների և մշակողների համար՝ սեփական ծրագրային ապահովման և համակարգերի կյանքի ցիկլի գործընթացների, ոլորտների և գործընթացների բարելավման առաջնահերթությունները որոշելու կարողություն.
• Մագիստրատուրայի գնահատողների համար՝ գնահատման գործընթացների անցկացման և բարելավման շրջանակ:

Ստանդարտում հաստատումը վերաբերվում է դրան երկու ասպեկտԲարելավել որոշակի ձեռնարկության PS-ի և համակարգերի կյանքի ցիկլի գործընթացները և որոշել, թե արդյոք ծրագրի կամ ձեռնարկության աջակցության գործընթացների հայտարարված ժամկետայնությունը համապատասխանում է իրական օգտագործվող գործընթացներին: Սա արտացոլված է ստանդարտի հետևյալ հինգ մասերում. ISO 15504:1-5:2003-2006.

Մաս 1 - Հայեցակարգ և բառապաշար:Պարունակում է ընդհանուր տեղեկությունծրագրային ապահովման և համակարգերի հասունության սերտիֆիկացման գործընթացների և ստանդարտի մասերի օգտագործման վերաբերյալ առաջարկություններ: Նախանշված են սերտիֆիկացման, տերմինաբանության, կառուցվածքի ընդհանուր պահանջները, որոշվում է ստանդարտի մնացած մասերի շրջանակը:

Մաս 2 - Հավաստագրման կատարում (արտադրություն):Այն ներառում է սերտիֆիկացման գործընթացների իրականացման մանրամասն պահանջներ՝ որպես տեխնոլոգիական գործընթացների հասունության մակարդակի բարելավման և որոշման հիմք՝ ՊՍ-ի և համակարգերի կյանքի ցիկլը ապահովելու համար: Փաստաթուղթը սահմանում է ատեստավորման իրականացման գործընթացներ, ատեստավորման և գործընթացների ստուգման համար առաջարկվող գործընթացների մոդելներ, որպեսզի դրանք լինեն օբյեկտիվ, իմաստալից և ներկայացուցչական:

Մաս 3 - Հավաստագրման արտադրության ուղեցույց:Տրամադրում է հասունության գնահատման գործընթացների կատարման և պահանջների կատարման մեկնաբանման տեխնոլոգիայի ակնարկ: Այն արտացոլում է. սերտիֆիկացման կատարումը. հասունացման գործընթացները որոշելու չափիչ գործիքներ. սերտիֆիկացման գործիքների ընտրություն և կիրառում; հավաստագրողների իրավասության գնահատում. ատեստավորման համապատասխանության ստուգում հայտարարված պահանջներին. Վավերացման գործիքները ձեռնարկությունների կողմից կարող են օգտագործվել ծրագրային ապահովման արտադրանքների և համակարգերի պլանավորման, կառավարման, մոնիտորինգի, վերահսկման և կատարելագործման համար, դրանց ձեռքբերման, մշակման, կիրառման և պահպանման համար:

Մաս 4 - Օգտագործողի ուղեցույց գործընթացի բարելավման և գործընթացի հասունության համար այս երկու ասպեկտներում: Առաջարկվում են մի շարք քայլեր, որոնք ներառում են. վավերացման գործընթացների արդյունքների կիրառում. հասունության գնահատման նպատակների սահմանում; նախնական տվյալների որոշում սերտիֆիկացման համար. բխող ռիսկերի հնարավոր նվազեցման գնահատում. գործընթացները բարելավելու քայլեր; հասունության մակարդակը որոշելու քայլեր. որակավորման վերլուծության արդյունքները համեմատելով պահանջների հետ.

Մաս 5 - Մաս 2-ում ներկայացված պահանջներին համապատասխանության ատեստավորման գործընթացների օրինակելի մոդել:Ընդարձակ փաստաթուղթը (162 էջ) ներկայացնում է ստանդարտի նախորդ մասերի գործնական օրինակներ՝ տարբեր կիրառական ոլորտների, ծրագրային նախագծերի և ձեռնարկությունների կյանքի ցիկլի հասունության գնահատումների կազմակերպման, գնահատման և բարելավման համար:

Նախագծերի գործնական իրականացման և բարդ ծրագրաշարի կյանքի ցիկլը ապահովելու ժամանակ մշակողների և մատակարարների համար երբեմն դժվար է բացահայտել և ընդգծել կիրառման մոդելների առավելությունները: CMMI. Կախված ձեռնարկության ավանդույթներից և մեծ նախագծի առանձնահատկություններից, հաճախ խորհուրդ է տրվում օգտագործել PS-ը որպես հիմնական ամբողջական ստանդարտների պրոֆիլըISOև հաճախորդների գնահատման համար հասունության մակարդակը PS նախագծերի ղեկավարումը, կազմակերպչական և տեխնոլոգիական աջակցությունը կիրառվում են հատուկ առաջարկություններ CMMI. Այս ուղեցույցները կարող են արդյունավետորեն օգտագործվել գործընթացի որակի սերտիֆիկացումձեռնարկություններում, որոնք ապահովում են PS-ի կյանքի ցիկլը, որպես այլընտրանք կամ սերտիֆիկացման հետ մեկտեղ՝ համաձայն կառավարման ստանդարտների. ISO 9000, կախված նախագծի առանձնահատկություններից և ծրագրային ապահովման արտադրանքի կամ տեխնոլոգիայի հավաստագրման համար դիմողի պահանջներից՝ դրա կյանքի ցիկլը ապահովելու համար։

Ծրագրային արտադրանքի սերտիֆիկացման կազմակերպում

Հավաստագրումը բաղկացած է մի շարք կազմակերպչական գործընթացներից, որոնք կազմում են սերտիֆիկացման համակարգ, այդ գործընթացներն ապահովվում են կանոնակարգված ընթացակարգերով և փաստաթղթերով և պետք է իրականացվեն որակավորված, հավաստագրված փորձագետ-տեսուչների կողմից։ Ձեռնարկություն-ծրագրավորողի և նրա գործունեության արդյունքների հավաստագրման համար՝ ծրագրային արտադրանք, մոդելներ CMMIկամ ստանդարտ պրոֆիլներ ISO[ , ] խորհուրդ է տրվում որոշակի կարգապահություն, որը պետք է հարմարեցված լինի PS-ի կյանքի ցիկլի օբյեկտների և միջավայրի հատուկ բնութագրերին: Ստորև թվարկված գործընթացներն ու փաստաթղթերը նախատեսված են խոշոր նախագծերի համար և կարող են կրճատվել ծրագրավորողների, հաճախորդների և հավաստագրողների միջև համաձայնությամբ ավելի պարզ դեպքերում:

Հավաստագրման աշխատանքները սկսվում են մարմնի կամ փորձարկման լաբորատորիայի հավատարմագրմամբ, դիմումի և փաստաթղթերի փաթեթի ձևավորումով և ներկայացմամբ Կենտրոնական սերտիֆիկացման մարմնին հավատարմագրման նպատակահարմարության վերաբերյալ որոշման համար: Եթե ​​թեստի արդյունքները դրական են, ապա կազմվում և տրվում է հավատարմագրման վկայական:

Կանոնակարգեր սերտիֆիկացման մարմնի կամ լաբորատորիայի վերաբերյալհիմնական փաստաթուղթն է, որը սահմանում է հավատարմագրման առարկայական ոլորտը, իրավական կարգավիճակը, գործառույթները, կառուցվածքը, իրավունքներն ու պարտականությունները, մեթոդները, միջոցները և թեստերի կազմակերպումը: Սերտիֆիկացման լաբորատորիայի (կենտրոնի) անձնագիրը պետք է պարունակի տեղեկատվություն փորձարկման համար անհրաժեշտ համակարգչային սարքավորումներով սարքավորումների, անձնակազմի և անձնակազմի, փորձարկման գործիքների սարքավորումների, կարգավորող, տեխնիկական և մեթոդական փաստաթղթերի տրամադրման, ինչպես նաև անհրաժեշտ այլ ռեսուրսների մասին: փորձարկում.

Որակի որակպարունակում է սկզբունքների հայտարարություն, մեթոդների և ընթացակարգերի նկարագրություն, որոնք կապված են սերտիֆիկացման մարմնի կամ լաբորատորիայի հիմնական գործառույթների և խնդիրների կատարման հետ՝ ապահովելով թեստերի որակը և վստահությունը գնահատումների, թեստերի և փորձաքննության արդյունքների նկատմամբ: Որակի ձեռնարկը սովորաբար ներառում է բաժիններ [ TWLSC$

• քաղաքականություն թեստավորման և փորձաքննությունների որակի ապահովման ոլորտում.
• կենտրոնը համալրել համապատասխան մեթոդական նյութերով և ծրագրային ապահովմամբ և թեստավորման գործիքներով.
• փորձարկման օբյեկտների պահանջների ձևակերպում.
• Քաղաքականություն կենտրոնի տեխնիկական հագեցվածության և անձնակազմի զարգացման ոլորտում.
• հավաստագրման արդյունքների փաստաթղթերի արխիվացում և անվտանգության վերահսկում:

Հավաստագրման ենթակա ապրանքների կամ գործընթացների գնահատման համար հայտատուն սերտիֆիկացման համակարգում ընդունված ձևով դիմում է ուղարկում սերտիֆիկացման մարմին: Սերտիֆիկացման մարմինը աշխատանքներ է իրականացնում արտադրանքի սերտիֆիկացման պատրաստման և կազմակերպման ուղղությամբ՝ դիմումի հիման վրա: Այս աշխատանքը ներառում է.

• սերտիֆիկացման սխեմայի ընտրություն՝ հաշվի առնելով արտադրանքի առանձնահատկությունները (ծավալը, տեխնոլոգիան, կարգավորող փաստաթղթերի պահանջները և այլն) և մշակողի առաջարկությունները.
• նմուշառման և փորձարկման ենթակա բաղադրիչների քանակի և կարգի որոշում, եթե դա նշված չէ ստանդարտներում.
• թեստերն իրականացնելու համար հավատարմագրված թեստավորման լաբորատորիայի ընտրություն և նույնականացում.
• աշխատանքի կատարման համար պայմանագրի նախագծի պատրաստում.

Հավաստագրման աշխատանքների նախապատրաստական ​​մասը ավարտվում է հավաստագրման համակարգում ընդունված ձևով որոշման հրապարակմամբ: Որոշումը աշխատանքի կատարման պայմանագրի նախագծի հետ միասին ուղարկվում է դիմողին։ Հավաստագրման թեստեր կազմակերպելիս, սերտիֆիկացման համար հայտարարված ապրանքների ընթացիկ կարգավորող փաստաթղթերի ընտրություն և ուսումնասիրություն, իրականացվում են թեստավորման և արդյունքների գնահատման մեթոդներ:

Դիմորդը վերջնական որոշումներ է կայացնում, թե որակի համակարգի որ տարրերը, կազմակերպչական և տեխնիկական գործունեության ոլորտները և տեսակները ենթակա են ստուգման սերտիֆիկացման ընթացքում տվյալ ժամանակահատվածում: Դիմորդը պետք է պայմաններ ստեղծի և փաստաթղթեր ներկայացնի ստուգման գործընթացներն ապահովելու համար։ Նա կարող է սերտիֆիկացման մարմնին ներկայացնել արտադրանքի մշակման և արտադրության ընթացքում կատարված փորձարկման հաշվետվություններ, երրորդ կողմի փորձարկման լաբորատորիաների կողմից կատարված թեստերի վերաբերյալ փաստաթղթեր և այլ փաստաթղթեր, որոնք ցույց են տալիս տեխնոլոգիայի կամ արտադրանքի համապատասխանությունը սահմանված պահանջներին: Հավաստագրման մարմինը, հայտին կից ներկայացված իր արտադրանքի սահմանված պահանջներին համապատասխանության փաստագրված ապացույցների վերլուծության հիման վրա, կարող է որոշել նվազեցնել թեստերի շրջանակը կամ տրամադրել վկայագիր:

Թեստերն իրականացվում են թեստավորման լաբորատորիաների կողմից, որոնք հավատարմագրված են միայն այն թեստերն անցկացնելու համար, որոնք նախատեսված են իրենց կարգավորող, հավատարմագրման փաստաթղթերում: Եթե ​​հնարավոր չէ թեստեր անցկացնել հավատարմագրված լաբորատորիայի փորձարկման հաստատությունում, փորձարկումները կարող են իրականացվել այս լաբորատորիայի անձնակազմի կողմից այս արտադրանքի արտադրողի կամ սպառողի մոտ՝ օգտագործելով փորձարկման լաբորատորիայի սեփական հնարավորությունները կամ մատակարարից հասանելի փորձարկման հնարավորությունները: .

Ծրագրային արտադրանքի և ձեռնարկության որակի համակարգերի հավաստագրման գործընթացը ներառում է.

• մշակողի կամ պատվիրատուի (դիմորդի) կողմից այս ոլորտում իրավասու մարմնի և սերտիֆիկացված լաբորատորիայի ընտրություն և սերտիֆիկացման փորձարկումներ կատարելու համար.
• հայտատուի կողմից թեստավորման համար հայտ ներկայացնելը սերտիֆիկացման մարմնին և հավաստագրողների կողմից հայտի վերաբերյալ որոշման ընդունումը, հավաստագրման սխեմայի ընտրությունը, հավաստագրման պայմանագրի կնքումը.
• ձեռնարկության որակի համակարգի և (կամ) փորձարկվող ծրագրային արտադրանքի տարբերակի պահանջների նույնականացում.
• սերտիֆիկացման լաբորատորիայի կողմից ընկերության որակի համակարգի կամ ծրագրային արտադրանքի տարբերակի հավաստագրման թեստերի կատարում.
• ստացված արդյունքների վերլուծություն և լաբորատորիայի և (կամ) սերտիֆիկացման մարմնի կողմից հայտատուին համապատասխանության վկայական տալու հնարավորության վերաբերյալ որոշումների կայացում.
• սերտիֆիկացման մարմնի կողմից հայտատուին տրամադրում է համապատասխանության նշանի օգտագործման վկայական և լիցենզիա և ծրագրային արտադրանքի սերտիֆիկացված արտադրանքներ տրամադրելու լիցենզիա.
• ձեռնարկության և (կամ) արտադրանքի հավաստագրված որակի համակարգի սերտիֆիկացման մարմնի կողմից տեսչական հսկողության իրականացում.
• հայտատուի կողմից ուղղիչ միջոցառումների իրականացում որակի համակարգի և (կամ) արտադրանքի գործընթացների սահմանված պահանջներին համապատասխանության խախտման և համապատասխանության նշանի ոչ ճիշտ կիրառման դեպքում.

Արտադրանքի որակի համար մշակողի ղեկավարության պատասխանատվությունը ստուգելիս պետք է պարզել, որ ձեռնարկությունը կամ նախագիծն ունի փաստաթղթավորված որակի քաղաքականություն, նպատակներ և պարտավորություններ, ինչպես նաև այն աստիճանը, որով այս քաղաքականությունը ըմբռնված է, իրականացվում և պահպանվում է աշխատանքային վիճակում: կազմակերպության բոլոր մակարդակները. Պետք է սահմանվի, որ ձեռնարկությունն ունի կառավարման ներկայացուցիչ, ով, անկախ այլ պարտականություններից, ունի որակի համակարգի ստանդարտների և կարգավորող փաստաթղթերի պահանջների շարունակական կատարման իրավասություն և պատասխանատվություն: Որակի համակարգի գործընթացների գործնական իրականացման համար պահանջների, ընթացակարգերի, գործիքների և պատրաստված անձնակազմի առկայությունը, ինչպես նաև որակի համակարգի բոլոր բաղադրիչների, պահանջների և դրույթների համապատասխանությունը և համակարգված փաստաթղթավորումը, որը ինտեգրված գործընթաց է ողջ կյանքի ընթացքում։ PS-ի ցիկլը, պետք է ստուգվի: Որակի համակարգի ստուգումներպետք է ներառի սահմանում.

• տեխնոլոգիական փաստաթղթերի առկայությունը և ամբողջականությունը և դրա պահանջներին գործնականում համապատասխանելը.
• տեխնոլոգիական սարքավորումների վիճակը և դրանց սպասարկման համակարգի առկայությունը.
• վերահսկողության և թեստավորման համակարգի առկայությունը և արդյունավետությունը.
• չափման և փորձարկման գործիքների վիճակը.
• արտադրանքի կամ տեխնոլոգիայի հայտնաբերված թերությունների հայտնաբերման և վերացման համակարգի առկայություն:

Թեստերի հիման վրա գնահատվում են ստացված արդյունքները և հիմնավորվում են կարգավորող փաստաթղթերի պահանջներին արտադրանքի կամ գործընթացների համապատասխանության կամ անհամապատասխանության վերաբերյալ եզրակացությունները: Փորձարկման հաշվետվությունները ներկայացվում են սերտիֆիկացման մարմնին, ինչպես նաև դիմողին` նրա խնդրանքով: Փորձարկման հաշվետվությունները ենթակա են պահպանման արտադրանքի սերտիֆիկացման համակարգերի կանոններով և փորձարկման լաբորատորիայի փաստաթղթերով սահմանված ժամկետներով, բայց ոչ պակաս, քան երեք տարի:

Փաստաթղթերի ամբողջականությունն ու որակը ստանալուց և ստուգելուց հետո փորձարկման լաբորատորիայի մասնագետները պետք է իրականացնեն որակի համակարգի փաստացի կիրառման աստիճանի քննությունձեռնարկությունում։ Թեստավորումը սկսվում է որակի համակարգի թեստավորման ծրագրի մշակմամբ, որը պետք է ծառայի որպես հետագա աշխատանքների աշխատանքային պլան: Ծրագիրը փորձարկման լաբորատորիայի ներքին աշխատանքային փաստաթուղթն է և պետք է պարունակի աշխատանքների ցանկ՝ մանրամասն մշակող ձեռնարկության առանձնահատկություններին համապատասխան և ներառելով ներկայացված սկզբնական փաստաթղթերի ամբողջականության և որակի վերլուծություն և դրանց գործնական կիրառման աստիճանը: ծրագրային ապահովման նախագծման, մշակման և առաքման մեջ: Որակի համակարգի ընթացակարգերի կիրառման փորձաքննությունն իրականացվում է փորձարկման լաբորատորիայի կողմից այն ձեռնարկության աշխատատեղերում, որն ապահովում է ՊՍ-ի կյանքի ցիկլը: Ստուգումներ են իրականացվում աշխատավայրում համապատասխան փաստաթղթեր մշակողների առկայության և դրանց դրույթների և առաջարկությունների օգտագործման ամբողջականության վերաբերյալ: Ծրագրի կարգավիճակի և որակի համակարգի, գործընթացների և/կամ արտադրանքի ներքին աուդիտի վերանայումները պետք է իրականացվեն անձնակազմի կողմից՝ անկախ այդ աշխատանքների իրականացման համար անմիջականորեն պատասխանատուներից:

Մշակման որակի ստուգման մեթոդներպետք է ապահովված լինեն թեստային ծրագրի իրականացման համար անհրաժեշտ ռեսուրսներով, մասնավոր թեստավորման ընթացակարգերի պլանավորման և մշակման մեթոդներով: Մեթոդները պետք է պարունակեն՝ թեստավորման առարկաներ և նպատակներ. գնահատված որակի ցուցանիշներ; թեստավորման պայմանները և կարգը. թեստի արդյունքների մշակման, վերլուծության և գնահատման մեթոդներ. տեխնիկական աջակցություն փորձարկման և հաշվետվությունների համար: Պետք է նշվեն թեստերի և փորձարկման ընթացակարգի ընթացքում օգտագործվող սարքավորումները և ծրագրային ապահովումը, ինչպես նաև ստուգումների ակնկալվող արդյունքները: Մեթոդներ պետք է մշակվեն ուղղումները, թերությունները շտկելու գործողություններ վերահսկելու համար, եթե այդպիսի հարցում է ստացվել աուդիտի կառավարման ծառայության կողմից: Թեստային ծրագրի կառավարման ծառայությունը պետք է ընթացակարգեր սահմանի ցանկացած թեստային տեղեկատվության, ինչպես նաև գնահատողների կողմից պահվող տվյալների գաղտնիությունը պահպանելու համար:

Փորձարկման հաշվետվություններներկայացվում է հայտատուին և սերտիֆիկացման մարմնին: Դիմորդը կարող է սերտիֆիկացման մարմնին ներկայացնել թեստային հաշվետվություններ՝ հաշվի առնելով դրանց վավերականության ժամկետները, որոնք իրականացվել են արտադրանքի մշակման և արտադրության ընթացքում, կամ փաստաթղթեր սերտիֆիկացման համակարգում հավատարմագրված կամ ճանաչված տեղական կամ արտասահմանյան փորձարկման լաբորատորիաների կողմից կատարված թեստերի վերաբերյալ։ Հավաստագրման թեստային հաշվետվությունների հիման վրա գնահատվում են ստացված արդյունքները և հիմնավորվում են կարգավորող փաստաթղթերի պահանջներին ապրանքների համապատասխանության կամ անհամապատասխանության վերաբերյալ եզրակացությունները:

Եզրակացություն սերտիֆիկացման թեստերի արդյունքների վերաբերյալմշակված է սերտիֆիկատորների կողմից և պարունակում է ընդհանրացված տեղեկատվություն թեստի արդյունքների և վկայագրի տրամադրման հիմնավորման մասին: Հավաստագրման թեստերի բացասական արդյունքներ ստանալու դեպքում որոշում է կայացվում հրաժարվել համապատասխանության վկայական տալուց: Հավաստագրված արտադրանքի կամ որակի համակարգի ավարտից հետո թեստերը կարող են կրկնվել: Տեխնոլոգիաների վիճակի կամ արտադրանքի որակի վերլուծության արդյունքները կազմվում են ակտով, որը տալիս է գնահատականներ թեստային ծրագրի բոլոր պաշտոնների համար և պարունակում է եզրակացություններ, այդ թվում ընդհանուր միավորարտադրության և արտադրանքի վիճակը, ուղղիչ միջոցառումների անհրաժեշտությունը. Ակտը սերտիֆիկացման մարմնի կողմից օգտագործվում է թեստային հաշվետվությունների, ծրագրային ապահովման արտադրանքի համար սերտիֆիկատի վավերականության ժամկետի տրամադրման և որոշման դիմումի, ստուգման հսկողության հաճախականության, ինչպես նաև ուղղիչ միջոցառումների մշակման համար:

Հավաստագրման թեստերի և փաստաթղթերի փորձաքննության արդյունքների հիման վրա որոշում է կայացվում վկայական տալու մասին: Հավաստագրման թեստերի բացասական արդյունքներ ստանալու դեպքում որոշում է կայացվում վկայական տալուց հրաժարվելըհամապատասխանությունը. Բացի այդ, առաջարկներ կարող են ուղարկվել դիմող ձեռնարկությանը` վերացնելու փորձարկման բացասական արդյունքների ենթադրյալ պատճառները, սերտիֆիկացված արտադրանքի ավարտից հետո թեստերը կարող են կրկնվել:

Հավաստագրման մարմինը, փորձարկման հաշվետվությունները վերլուծելուց, արտադրությունը գնահատելուց, որակի համակարգը հավաստելուց, հայտի վերաբերյալ որոշման մեջ նշված փաստաթղթերը վերլուծելուց հետո, գնահատում է արտադրանքի համապատասխանությունը սահմանված պահանջներին, փորձագետների կարծիքի հիման վրա կազմում է վկայագիր: և գրանցում է այն։ Նախագծային կամ գործառնական փաստաթղթերում փոփոխություններ կատարելիս, որոնք կարող են ազդել սերտիֆիկացման ընթացքում հավաստագրված համակարգի կամ ծրագրային արտադրանքի որակի վրա, հայտատուն պետք է այդ մասին տեղեկացնի սերտիֆիկացման մարմնին՝ լրացուցիչ թեստերի անհրաժեշտության մասին որոշելու համար: Գրանցվելուց հետո վկայականն ուժի մեջ է մտնում և ուղարկվում դիմող ձեռնարկությանը: Հավաստագրի տրամադրման հետ միաժամանակ դիմող ձեռնարկությանը կարող է տրվել լիցենզիահամապատասխանության նշանն օգտագործելու իրավունքի համար։

Հավաստագրված ծրագրային արտադրանքի համար՝ դրանց շահագործման ընթացքում համապատասխանության հավաստագրի գործողության ողջ ընթացքում, տեսչական հսկողություն. Տեսչական հսկողությունն իրականացվում է տեխնոլոգիայի և սերտիֆիկացված արտադրանքի որակի պահանջներին համապատասխանության պարբերական և չպլանավորված ստուգումների տեսքով: Վերահսկողության օբյեկտները, կախված սերտիֆիկացման սխեմայից, սերտիֆիկացված արտադրանքն են, որակի համակարգը կամ մշակողի արտադրության կայունությունը: Հաճախականությունը և ծավալը որոշելիս ստուգման ստուգումհաշվի են առնվում հետևյալ գործոնները՝ ծրագրային արտադրանքի պոտենցիալ վտանգի աստիճանը, արտադրության կայունությունը, թողարկման ծավալը, մշակման ընթացքում որակի համակարգի առկայությունն ու կիրառումը, արտադրանքի և դրա փորձարկումների արդյունքների մասին տեղեկատվություն։ արտադրությունը, որն իրականացվում է արտադրողի, իշխանությունների կողմից պետական ​​վերահսկողությունև վերահսկողություն։

Տեսչական հսկողության արդյունքները կազմվում են ակտով, որը գնահատում է նմուշային թեստերի և այլ ստուգումների արդյունքները, ընդհանուր եզրակացություն է անում սերտիֆիկացված արտադրանքի արտադրության վիճակի և տրված սերտիֆիկատի վավերականության պահպանման հնարավորության մասին։ Ակտը պահվում է սերտիֆիկացման մարմնում, և դրա պատճեններն ուղարկվում են մշակողին և տեսչական հսկողությանը մասնակցած կազմակերպություններին: Ստուգման հսկողության արդյունքների հիման վրա սերտիֆիկացման մարմինը կարող է կասեցնել կամ չեղարկել սերտիֆիկատը և ուժը կորցրած ճանաչել համապատասխանության նշանի օգտագործման իրավունքի լիցենզիան՝ սերտիֆիկացման ընթացքում վերահսկվող կարգավորող փաստաթղթերի պահանջներին արտադրանքի չհամապատասխանելու դեպքում, ինչպես նաև. ինչպես նաև հետևյալ դեպքերում.

• հիմնարար փոփոխություններ հասունության մոդելի, ստանդարտների պրոֆիլի, արտադրանքի կանոնակարգերի կամ փորձարկման մեթոդի մեջ.
• դիզայնի (կազմի) փոփոխություններ, արտադրանքի ամբողջականություն.
• փոփոխություններ մշակման և արտադրության կազմակերպման կամ տեխնոլոգիայի մեջ.
• տեխնոլոգիայի, վերահսկման և փորձարկման մեթոդների, որակի համակարգի պահանջներին չհամապատասխանելը, եթե թվարկված փոփոխությունները կարող են առաջացնել արտադրանքի անհամապատասխանություն սերտիֆիկացման ընթացքում վերահսկվող պահանջներին:

Համապատասխանության նշանի օգտագործման իրավունքի վկայականի և լիցենզիայի գործողությունը կասեցնելու մասին որոշումը չի ընդունվում, եթե այն թողարկած սերտիֆիկացման մարմնի հետ համաձայնեցված ուղղիչ միջոցառումների միջոցով դիմորդը կարող է վերացնել անհամապատասխանության հայտնաբերված պատճառները և հաստատել. , առանց հավատարմագրված լաբորատորիայում վերստուգման՝ արտադրանքի կամ գործընթացների համապատասխանությունը նորմատիվ փաստաթղթերին։ Եթե ​​դա հնարավոր չէ անել, ապա վկայագրի վավերականությունը չեղյալ է հայտարարվում, իսկ համապատասխանության նշանի օգտագործման իրավունքի լիցենզիան չեղյալ է հայտարարվում: Վկայագրի գործողության կասեցման կամ չեղարկման մասին տեղեկատվությունը տրամադրվում է այն տված սերտիֆիկացման մարմնի կողմից հայտատուին, սպառողներին և շահագրգիռ այլ կազմակերպություններին: Հավաստագրի վավերականությունը և ապրանքները համապատասխանության նշանով մակնշելու իրավունքը կարող են երկարաձգվել, եթե կառուցապատող ձեռնարկությունը կատարում է հետևյալ պայմանները.

• անհամապատասխանության պատճառների բացահայտում և դրանց վերացում.
• արտադրանքի որակի բարելավման և ապահովման ուղղությամբ կատարված աշխատանքների վերաբերյալ հաշվետվություն սերտիֆիկացման մարմնին ներկայացնելը.
• արտադրանքի լրացուցիչ փորձարկումների անցկացում` ըստ մեթոդների և սերտիֆիկացման մարմնի հսկողության ներքո և դրական արդյունքների ստացում:

Ծրագրային արտադրանքի սերտիֆիկացման գործընթացների և արդյունքների փաստաթղթավորում

Որակի համակարգի հավաստագրման համար փաստաթղթերի կազմը և բովանդակությունըձեռնարկությունները կախված են ծրագրային ապահովման նախագծման, մշակման և ձևափոխման բնութագրերից, ինչպես նաև դրանց որակի պահանջներից և տեխնոլոգիական միջավայրի բնութագրերից: Հետևաբար, յուրաքանչյուր ձեռնարկության կամ նախագծի համար անհրաժեշտ փաստաթղթերի փաթեթը պետք է ընտրվի և հարմարեցվի այս բնութագրերին համապատասխան: Հավաստագրման ընթացքում գնահատված որակի համակարգի ցուցանիշներն են համապատասխան փաստաթղթերի առկայությունը և հասունության մոդելի որոշակի մակարդակի պահանջների գործնական կատարումը: SMMIկամ հարմարեցված ստանդարտների պրոֆիլի վրա հիմնված ISO 9000:2000, ինչպես նաև դրանց հիման վրա ստեղծված ձեռնարկության կառուցապատողի մասնագետների կողմից աշխատանքի նկարագրությունները: Դիմորդը պետք է պատրաստի և փորձարկման լաբորատորիա ներկայացնի պատվիրատուի և մշակողի միջև համաձայնեցված և հաստատված փաստաթղթերի փաթեթ՝ ստուգելու դրանց հուսալիությունը, կազմի բավարարությունը և կատարողականությունը՝ կարգավորող փաստաթղթերին համապատասխան:

Հավաստագրման հիմնական փաստաթղթերի ցուցիչ փաթեթը բաղկացած է երեք խմբից.

• հիմնական կանոնակարգերըորակի համակարգեր՝ համաձայն անվանացանկի և բովանդակության վրա հիմնված ստանդարտների պրոֆիլի ISO 9000:2000կամ հասունության մոդելներ SMMI, ինչպես նաև մշակողների կողմից դրանց հիման վրա պատրաստված ծրագիրը, ձեռնարկը և հրահանգները, որոնք ներկայացված են աուդիտի ենթարկված ձեռնարկության որակի համակարգի կամ արտադրանքի փորձարկողներին (փորձագետներին).
• որոշակի ձեռնարկություն կամ նախագիծ բնութագրող սկզբնաղբյուր փաստաթղթեր, ինչպես նաև ծրագրային ապահովման գործիքի կյանքի ցիկլը, որը պատրաստվել է ծրագրի ղեկավարության կողմից դրա որակի հավաստագրման համար.
• փորձարկողների հաշվետվական փաստաթղթերը, որոնք արտացոլում են ձեռնարկության որակի համակարգի և (կամ) ծրագրային արտադրանքի աուդիտի (սերտիֆիկացման) արդյունքները, որոնք ներկայացվում են սերտիֆիկացման մարմնին, հայտատուին և աուդիտի ենթարկված ձեռնարկության ղեկավարությանը:

Հավաստագրման ներկայացված ծրագրային արտադրանքը կամ ձեռնարկության որակի համակարգը պետք է ներկայացվեն համապատասխան փաստաթղթերի հետ միասին: Այս փաստաթղթերի խմբերի ցանկը և մոտավոր բովանդակությունը կենտրոնացած են ձեռնարկությունների որակի համակարգերի ստուգման ընդհանուր դեպքի վրա, որոնք ապահովում են խոշոր ծրագրային արտադրանքի կյանքի ցիկլը: Փաստաթղթերի փաթեթը կարող է կրճատվել և հարմարեցվել, ինչպես համաձայնեցված է հայտատուի, հավաստագրողի և աուդիտի ենթարկված ձեռնարկության ղեկավարության միջև՝ ծրագրային նախագծերի բնութագրերին համապատասխան: Որոշ փաստաթղթեր կարող են համակցվել ինտեգրված հաշվետվությունների մեջ՝ դրանց իրականացման համար որոշակի մասնագետների հստակ պատասխանատվությամբ:

Ձեռնարկության որակի համակարգի և ծրագրային ապահովման կյանքի ցիկլի հիմնական փաստաթղթերը

1. Գործողության բարելավման հայեցակարգ, տերմինաբանություն, պահանջներ և ուղեցույցներ - որակի կառավարման համակարգեր - ISO 9000:2000կամ CMMI հասունության մոդելի տարբերակ:
2. Ստանդարտների հարմարեցված տարբերակները կամ բաժինների ցանկը և առաջարկությունները ISO 12207, ISO 15504, դրանց փոփոխությունները և կիրառման ուղեցույցները, որոնք ընտրվել են հարմարեցման ընթացքում և պարտադիր են որոշակի ձեռնարկության կամ ծրագրային արտադրանքի նախագծի որակի համակարգում օգտագործելու համար:
3. Ստանդարտի ադապտացված տարբերակ կամ բաժինների և առաջարկությունների ցանկ ISO 900003, ընտրված ադապտացիայի ընթացքում և պարտադիր ծրագրային արտադրանք արտադրող ձեռնարկության որակի համակարգում օգտագործելու համար։
4. PS նախագծի հիմնական բնութագրերը և որակի հատկանիշները, որոնք բացահայտված, հարմարեցված և ճշգրտված են ստանդարտների հիման վրա ISO 12182, ISO 9126, ISO 14598, ISO 25000.
5. Պահպանման և կազմաձևման կառավարման ձեռնարկի հարմարեցված տարբերակը և հաստատված հրատարակությունը՝ հիմնված ստանդարտների առաջարկությունների վրա ISO 14764, ISO 10007, ISO 15846.
6. Աշխատանքի նկարագրությունների մի շարք, որոնք սահմանում են պատասխանատվությունը, իրավասությունը և կարգը բոլոր ղեկավարների, կատարող և ստուգող անձնակազմի աշխատանքը, որը ներգրավված է ձեռնարկության որակի համակարգի ընթացակարգերում կոնկրետ PS նախագծի համար:

Աղբյուր փաստաթղթեր, որոնք արտացոլում են որոշակի ծրագրային գործիքի կյանքի ցիկլի առանձնահատկությունները

1. Ձեռնարկությունում ստեղծված ծրագրային ապահովման արտադրանքի բնութագրերի նկարագրությունը, համակարգը և դրանց կյանքի ցիկլի արտաքին միջավայրը, որոնք անհրաժեշտ են PS նախագծի ստանդարտների և պահանջների աշխատանքային տարբերակների հարմարեցման և պատրաստման համար և ձեռնարկության որակի համակարգի համաձայն. ստանդարտների առաջարկությունները ISO 12207, ISO 15504, ISO 90003Եվ ISO 9126.
2. Որակի համակարգի ոլորտում ձեռնարկության ծրագրավորողի նպատակների, պահանջների և պարտավորությունների նկարագրությունը, ծրագրային ապահովման ողջ կյանքի ցիկլի մշակման գործընթացների և արտադրանքի որակի չափանիշները:
3. Գործառնական փաստաթղթերի մի շարք, որոնք տրամադրվում են հաճախորդին և օգտագործողներին՝ ապահովելու ծրագրային ապահովման արտադրանքի որոշակի տարբերակի կյանքի ցիկլը և օգտագործումը՝ հիմնված հարմարեցված ստանդարտների վրա: ISO 9294, ISO 15910, ISO 18019.
4. Փաստաթղթային և ավտոմատացման գործիքներ նախագծման, մշակման, փոփոխման, վերահսկման և փորձարկման համար, որոնք օգտագործվում են ծրագրային արտադրանքի կյանքի ցիկլը ապահովելու համար:
5. Ձեռնարկության որակի համակարգի և ծրագրային արտադրանքի կիրառման փորձարկման և գործընթացների արդյունավետության գնահատման պլաններ և մեթոդներ:
6. Սպասարկման մեթոդներ, ծրագրային արտադրանքի բաղադրիչների և փաստաթղթերի նույնականացում, ծրագրային ապահովման և տվյալների համալիրների տարբերակների վերլուծություն և հաստատում:
7. Կազմաձևերի կառավարման, հաստատման, պահպանման, պաշտպանության, ծրագրային արտադրանքի տարբերակների և ուղեկցող փաստաթղթերի պատճենման մեթոդիկա, ինչպես նաև ծրագրային արտադրանքի տարբերակների կյանքի ցիկլի ընթացքում ձեռնարկության արխիվում գրանցված որակի բնութագրերի վերաբերյալ տվյալների կուտակում և պահպանում:

Ստացված փորձարկման փաստաթղթերը՝ ձեռնարկության որակի համակարգի և (կամ) ծրագրային արտադրանքի հավաստագրում

1. Ձեռնարկության որակի համակարգի պահանջներին և դրույթներին հարմարեցված փաստաթղթերի առկայության, համապատասխանության և համակարգված կատարման մասին հաշվետվություն, որն ապահովում է որակի ապահովման ինտեգրված գործընթաց ծրագրային արտադրանքի ողջ կյանքի ընթացքում:
2. Որակի համակարգի վիճակի և կիրառման մոնիտորինգի և փորձարկման արդյունքները, որոնք պարբերաբար իրականացվում են դրա համապատասխանությունն ու արդյունավետությունը որոշելու համար:
3. Զեկույց ստուգումների անցկացման մեթոդների առկայության և պահպանման մասին և փաստաթղթավորված հաշվետվություններ ձեռք բերված որակի արդյունքների վերաբերյալ հաճախորդի հետ սերտիֆիկացման պայմանագրի պահանջների կատարման մեջ:
4. Ծրագրային փաթեթի ձեռք բերված որակական բնութագրերի գրանցման արդյունքները` ծրագրային արտադրանքի և դրա բաղադրիչների որակի բնութագրերի և հատկանիշների վերաբերյալ գրանցված տվյալների նույնականացում, կուտակում, պահպանում:
5. Զարգացման ծրագրի իրականացման արդյունքները, փաստաթղթավորված մուտքային և ելքային տվյալները մշակման փուլերի և ՀՍ-ի կյանքի ցիկլի իրականացման ստուգման արձանագրություններ:
6. որակի ծրագրի գործնական իրականացման արդյունքները և որակի ոլորտում կանոնակարգված գործունեության իրականացումը ԳԾ-ի կյանքի ցիկլի բոլոր փուլերում.
7. Շրջակա միջավայրի սիմուլյատորների և թեստային գեներատորների սերտիֆիկացման արդյունքները, ինչպես նաև ծրագրային արտադրանքի սերտիֆիկացման թեստերի կատարման համար դրանց բավարարության գնահատումը:
8. Պլանների և փորձարկման մեթոդների կատարման վերլուծության արդյունքները, թեստային հաշվետվությունները, թեստի արդյունքների պահանջներին համապատասխանության գնահատումները, ինչպես նաև հայտատուի, հաճախորդի և մատակարարի ներկայացուցիչների կողմից հաստատված թեստի արդյունքները:
9. Ծրագրային ապահովման համակարգի և ձեռնարկության որակի համակարգի կյանքի ցիկլի իրական բնութագրերի ստուգման արդյունքների ակտ, եզրակացություններ դրանց համապատասխանության վերաբերյալ ծրագրային արտադրանքի արտադրության սերտիֆիկացման պահանջներին:
10. Ձեռնարկության և (կամ) ծրագրային արտադրանքի որակի համակարգի վկայագիր և դրա կյանքի ցիկլը ապահովելու, համապատասխանության նշանների օգտագործման լիցենզիա.

գրականություն

Վ.Վ. Լիպաև - Ծրագրային ապահովման կյանքի ցիկլի ստանդարտների պրոֆիլներ: -- Jet Info, Newsletter, N 12, 2005 թ

Կ. Միլման, Ս. Միլման -- SMMI-ն քայլ է դեպի ապագա: -- բաց համակարգեր., N 5-6 (2005), N2 (2006) , 2005, 2006 թ.

ISO IEC TR 15504-CMMI ծրագրային գործիքների և տեղեկատվական համակարգերի ստեղծման և պահպանման գործընթացների հասունության գնահատում և հավաստագրում: Պեր. անգլերենից -- Մ.: Գիրք և բիզնես, 2001

Վ.Վ. Լիպաև - Բարդ ծրագրային ապահովման կյանքի ցիկլի գործընթացները և չափանիշները: տեղեկատու.-- Մ.: ՍԻՆՏԵԳ, 2006

Վ.Վ. Լիպաև - Լայնածավալ ծրագրային ապահովման որակի ապահովման մեթոդներ.-- M.: RFBR: ՍԻՆՏԵԳ, 2003

«Ծրագրային արտադրանքներն այժմ օգտագործվում են մարդկային գործունեության գրեթե բոլոր ոլորտներում կառավարման խնդիրները լուծելու համար՝ տնտեսության, սոցիալական, ռազմական և այլ ոլորտներում: Ներքին ծրագրային ապահովման արտադրանքի բարձր որակի ապահովումը դրանց զանգվածային մշակման և տարբեր կիրառությունների համար երկրում և համաշխարհային շուկայում առաքման ընթացքում դարձել է ռազմավարական խնդիր։» պայման՝ 1]$։