տուն » Բիզնես պլաններ » Ծրագրային համակարգեր մշակող կազմակերպությունների հասունության գնահատման մոդելներ. Ստանդարտներ ISO, SW-CMM

Ծրագրային համակարգեր մշակող կազմակերպությունների հասունության գնահատման մոդելներ. Ստանդարտներ ISO, SW-CMM

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

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

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

Արդյունքում թողարկվեց CMM ստանդարտը՝ 1.1 տարբերակը, որը մինչ օրս ակտիվորեն օգտագործվում է ամբողջ աշխարհում։

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

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

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

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

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

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

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-ի միջոցով?

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

Որակը հեշտ էր չափվում՝ կա՛մ վարձատրվեցինք, կա՛մ՝ ոչ:
Դին Լեֆինգվել, Դոն Վիդրիգ.
Ծրագրային ապահովման պահանջների կառավարում

CMM/CMMI

Թերևս ամենահայտնի որակի ստանդարտը պետք է համարել Կարողությունների հասունության մոդելը (CMM)՝ զարգացման գործընթացների հասունության մակարդակը իր ածանցյալների հետ միասին գնահատելու մոդել: Այն ստեղծվել է SEI-ի (Ծրագրային ճարտարագիտության ինստիտուտ) կողմից, որը ֆինանսավորվում է ԱՄՆ պաշտպանության նախարարության կողմից և հանդիսանում է Քարնեգի Մելլոնի համալսարանի կառուցվածքային ստորաբաժանումը։ Ստանդարտի առաջին պաշտոնական տարբերակը թողարկվել է 1993 թվականին, չնայած դրա վրա աշխատանքը սկսվել է շատ ավելի վաղ. դրա հիմնական դրույթները հրապարակվել են դեռևս 1986 թվականին:

CMM-ի հաջողությունը կանխորոշված էր մի քանի գործոններով. Այս ստանդարտը առաջիններից մեկն էր՝ ի սկզբանե հաշվի առնելով ծրագրային ապահովման մշակման առանձնահատկությունները։ Պարզվեց, որ այն բավականին պարզ և թափանցիկ է թե՛ հասկանալու, թե՛ օգտագործման համար, և կարգավորել է «ինչ», և ոչ թե «ինչպես» անել, և, հետևաբար, հարմար է զարգացման տարբեր մեթոդաբանությունների համար և չի սահմանել որևէ սահմանափակում փաստաթղթային ստանդարտների, գործիքների, շրջակա միջավայրը և նախագծերում օգտագործվող լեզուները: Եվ, հնարավոր է, գլխավոր գործոնը, որը կանխորոշեց CMM-ի ժողովրդականությունը, SEI-ի համագործակցությունն էր ԱՄՆ պաշտպանության նախարարության հետ, ինչը դե ֆակտո նշանակում էր ստանդարտի կիրառում այս գերատեսչության կողմից պատվիրված նախագծերի իրականացման ժամանակ։

CMM մոդելը (Աղյուսակ 1) նախատեսում է հասունության հինգ մակարդակ, որոնցից յուրաքանչյուրը համապատասխանում է գործընթացի որոշակի հիմնական ոլորտներին (Key Process Areas, KPA):

Աղյուսակ 1. CMM մոդելի շերտերը

մակարդակի համարը	Մակարդակի անվանումը	Հիմնական գործընթացների ոլորտները
1	Տարրական	Եթե կազմակերպությունն այս մակարդակի վրա է, ապա դրա համար չկան հիմնական գործընթացային ոլորտներ
2	կրկնվող	Ծրագրային ապահովման կոնֆիգուրացիայի կառավարում Ծրագրային արտադրանքի որակի ապահովում Կապալառուի պայմանագրերի կառավարում Ծրագրի առաջընթացի մոնիտորինգ Ծրագրային ծրագրի պլանավորում Պահանջների կառավարում.
3	Որոշակի	Փորձագիտական գնահատումներ Նախագծային խմբերի միջև փոխգործակցության համակարգում Ճարտարագիտական ծրագրային արտադրանք.Ծրագրային ինտեգրված կառավարում.Կադրերի վերապատրաստման ծրագիր.Կազմակերպչական գործընթացի սահմանում.Կազմակերպչական գործընթացի շրջանակը.
4	Կարողացավ	Ծրագրային ապահովման որակի կառավարում Գործընթացների կառավարում` հիմնված քանակական մեթոդների վրա
5	Օպտիմալացվող	Գործընթացների փոփոխության կառավարում: Տեխնոլոգիական փոփոխությունների կառավարում: Արատների կանխարգելում

Մակարդակների բաժանումը և դրանցից յուրաքանչյուրի համար KPA-ի սահմանումը թույլ է տալիս հետևողականորեն իրականացնել CMM-ը՝ օգտագործելով ստանդարտը որպես ուղեցույց, որը կարող է ապահովել զարգացման գործընթացի շարունակական բարելավում:

CMM ստանդարտը շատ հաջողակ դարձավ, և հետագայում դրա հիման վրա ստեղծվեց ստանդարտների մի ամբողջ շարք (Աղյուսակ 2): Ավելին, այն ստացավ նոր անվանում՝ SW-CMM (Capability Maturity Model for Software), որն ավելի ճշգրիտ է արտացոլում նրա դիրքը ստանդարտների բավականին մեծ ընտանիքում։

Աղյուսակ 2. CMM ստանդարտների մշակում

Ստանդարտի անվանումը	Նկարագրություն
Համակարգային ինժեներական CMM (SE-CMM)	Կենտրոնանում է համակարգի ինժեներական խնդիրների վրա՝ արտադրանքի մշակում (պահանջների վերլուծություն, արտադրանքի համակարգերի նախագծում և ինտեգրում) և դրանց արտադրություն (արտադրական գծի պլանավորում և շահագործում)
Վստահելի CMM (T-CMM)	Նախատեսված է զգայուն և փակ սպասարկման համար ծրագրային համակարգերորոնք պահանջում են բարձրորակ ծրագրային ապահովման ապահովում
Համակարգի անվտանգության ճարտարագիտական CMM (SSE-CMM)	Կենտրոնանում է ծրագրային ապահովման ճարտարագիտության անվտանգության ասպեկտների վրա, ապահովում է մշակման անվտանգ գործընթաց, ներառյալ ստեղծման թիմի անդամների անվտանգությունը
Մարդկանց CMM (P-CMM)	Դիտարկում է ծրագրային ապահովման կազմակերպություններում կադրերի զարգացման խնդիրները
Ծրագրաշարի ձեռքբերման CMM (SA-CMM)	Ծածկում է արտաքին կազմակերպություններից ծրագրային ապահովման արտադրանքի ձեռքբերումը
Ինտեգրված արտադրանքի մշակման CMM (IPD-CMM)	Ծառայում է որպես միջավայր՝ զարգացման ջանքերը կյանքի ցիկլի բոլոր փուլերում և ընկերության յուրաքանչյուր ստորաբաժանումից ինտեգրելու համար

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

Նաև CMM-ի էական խնդիրն է բոլոր գործընթացները «հավասարեցնելու» անհրաժեշտությունը։ Եթե կազմակերպությունը փորձում է հավաստագրել որոշակի մակարդակի, ապա նա պետք է ապահովի, որ համապատասխան մակարդակը կիրառվի իր բոլոր գործընթացների համար: Նույնիսկ եթե առանձնահատկությունները, մեթոդաբանությունը կամ զարգացման առանձնահատկությունները չունեն որոշակի գործընթացներ, որոնք պետք է կատարվեն, հավաստագրումը դա է պահանջում:

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

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

Լուծել խնդիրների մեծ մասը CMM-ը նախագծված է նոր ստանդարտ SEI - Capability Maturity Model Integrated (CMMI) - Զարգացման գործընթացների հասունության մակարդակը գնահատելու ինտեգրված մոդել: CMMI ստանդարտը ի սկզբանե ստեղծվել է այնպես, որ համակցվի առկա տարբերակները CMM և վերացնել ցանկացած հակասություն դրա գործնական կիրառման մեջ բարձր տեխնոլոգիական ընկերությունների գործունեության տարբեր ոլորտներում:

Կազմակերպության գործընթացները «հավասարեցնելու» անհրաժեշտությունը վերացնելու և նրա բիզնես կարիքներին ավելի հարմարեցվելու համար, և ոչ հակառակը, CMMI ստանդարտն ունի ներկայացման երկու ձև՝ դասական, բազմամակարդակ, որը համապատասխանում է CMM-ին, իսկ նորը՝ շարունակական։ Ներկայացման շարունակական ձևը հաշվի չի առնում հասունության մակարդակները (Maturity Levels), այլ Կարողությունների մակարդակները, որոնք գնահատվում են գործընթացի առանձին ոլորտների համար (Process Areas, PA): Աղյուսակում. 3-ը տալիս է CMM ստանդարտի հասունության մակարդակների քարտեզագրում, ինչպես նաև CMMI շերտավորված ներկայացման հասունության մակարդակները և շարունակական CMMI ներկայացման կարողությունների մակարդակները:

SEI-ն հեռանում է CMM-ից և դրա դիմաց ակտիվորեն խթանում է CMMI-ը՝ խոստանալով խստացնել հսկողությունը սերտիֆիկացման գործընթացի վրա՝ ներմուծելով նոր դասեր՝ ծախսերը նվազեցնելու և այն ավելի գրավիչ դարձնելով փոքր կազմակերպությունների համար; ISO ստանդարտների հետ համատեղելիության ապահովում. Սակայն փաստը մնում է փաստ, որ ներս ժամանակակից պայմաններ CMM / CMMI-ի որոշակի մակարդակի վկայագրի առկայությունը այնքան էլ նշանակալի գործոն չէ, ինչպես դա մի քանի տարի առաջ էր, և ընդունվում է առանց լրացուցիչ հարցերի, բացառությամբ, գուցե, կառավարության պատվերով իրականացվող նախագծերի:

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

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

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

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

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

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

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

արտադրական աշխատանք

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

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

ընդհանուր բնութագրերը

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

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

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

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

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

Ընկերությունների տեխնոլոգիական հասունության գնահատումը կարող է օգտագործվել.

հաճախորդը լավագույն կատարողներին ընտրելիս (օրինակ՝ մրցույթում).

· Ծրագրային ապահովման ընկերությունները համակարգված գնահատել իրենց տեխնոլոգիական գործընթացների վիճակը և ընտրել դրանց բարելավման ոլորտները.

· ընկերություններ, որոնք որոշում են ատեստավորում անցնել «աղետի չափը» գնահատելու համար, այսինքն. ձեր ներկայիս վիճակը;

աուդիտորները որոշել ստանդարտ հավաստագրման ընթացակարգը և իրականացնել անհրաժեշտ գնահատումներ.

· խորհրդատվական ընկերություններ, որոնք ներգրավված են տեղեկատվական տեխնոլոգիաների և հարակից ծառայությունների ընկերությունների և ծառայություններ մատուցողների վերակառուցման մեջ:

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

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

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

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

1990 թվականից SEI-ն ԱՄՆ պետական կառույցների և ծրագրային ապահովման մշակող կազմակերպությունների աջակցությամբ մշտապես մշակել և կատարելագործել է այս մոդելը՝ հաշվի առնելով ծրագրային ապահովման ստեղծման և պահպանման ոլորտում բոլոր վերջին ձեռքբերումները:

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

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

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

Բրինձ. 1.7. SMM տեխնոլոգիական հասունության հինգ մակարդակ

Սլաքների վրայի մակագրությունները սահմանում են մակարդակից մակարդակ տեղափոխվելու գործընթացների բարելավման առանձնահատկությունները:

Երկրորդից հինգերորդ մակարդակները կարող են բնութագրվել ծրագրային ապահովման ստեղծման գործընթացների ստանդարտացման և (կամ) արդիականացմանն ուղղված գործողությունների միջոցով, ինչպես նաև այն գործողությունների միջոցով, որոնք կազմում են դրա ստեղծման գործընթացները: Միևնույն ժամանակ, առաջին մակարդակը, կարծես, հիմքն է, հիմքը համեմատական վերլուծությունվերին մակարդակները.

1-ին մակարդակում (սկզբնական) ծրագրային ապահովման ստեղծման և պահպանման հիմնական գործընթացները պատահական են և քաոսային: Ծրագրի հաջողությունն ամբողջությամբ կախված է անձնակազմի անհատական ջանքերից: Այս մակարդակում, որպես կանոն, կազմակերպությունը չունի ծրագրային ապահովման ստեղծման և պահպանման համար անհրաժեշտ կայուն միջավայր։

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

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

2-րդ մակարդակում (կրկնվող գործընթացների մակարդակ) ծրագրի կառավարման գործընթացները ապահովում են ծրագրի արժեքի, ժամանակացույցի և կատարվող գործառույթների շարունակական վերահսկողություն: Ծրագրի կարգապահությունն այնպիսին է, որ հնարավոր է կանխատեսել նմանատիպ ծրագրային արտադրանք ստեղծելու նախագծերի հաջողությունը:

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

CMM-ի յուրաքանչյուր մակարդակ, սկսած երկրորդից, բնութագրվում է մի շարք, այսպես կոչված, հիմնական գործընթացների խմբերի (KPA) առկայությամբ: CMM մոդելը պարունակում է 18 նման խմբեր, CMMI մոդելի վերջին տարբերակը պարունակում է 20 խումբ։ 2-րդ մակարդակի CMM-ն բնութագրվում է կազմակերպությունում հետևյալ գործընթացների առկայությամբ (դրանց անունները համապատասխանում են CMMI-ին).

պահանջների կառավարում;

կոնֆիգուրացիայի կառավարում;

ծրագրի պլանավորում;

ծրագրի մոնիտորինգ և վերահսկում;

պայմանագրերի կառավարում;

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

գործընթացի և արտադրանքի որակի ապահովում.

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

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

Այս մակարդակում 2-րդ մակարդակի գործընթացներին ավելացվում են հետևյալ գործընթացները.

պահանջների ճշգրտում;

արտադրանքի ինտեգրում;

ստուգում;

սերտիֆիկացում;

կազմակերպչական գործընթացների ստանդարտացում;

· կրթություն;

Ծրագրի ինտեգրված կառավարում;

· Ռիսկերի կառավարում;

Վերլուծություն և որոշումների կայացում:

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

Յուրաքանչյուր նախագծի համար մեկ տեխնոլոգիայի հիման վրա կարելի է մշակել իր սեփական գործընթացները՝ հաշվի առնելով դրա առանձնահատկությունները: Նման գործընթացները CMM-ում կոչվում են «նախագծի վրա հիմնված ծրագրային ապահովման մշակման գործընթացներ» (նախագծի «սահմանված ծրագրային գործընթաց):

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

4-րդ մակարդակի (կառավարվող գործընթացների մակարդակ) հիմնական նպատակը գործընթացների ընթացիկ վերահսկողությունն է: Ղեկավարությունը պետք է ապահովի, որ գործընթացներն իրականացվեն սահմանված որակի շրջանակներում: Չափված արդյունքներում կարող են լինել անխուսափելի կորուստներ և ժամանակավոր գագաթնակետեր, որոնք պահանջում են միջամտություն, բայց ընդհանուր առմամբ համակարգը պետք է կայուն լինի:

4-րդ մակարդակում ավելացվում են հետևյալ գործընթացները.

կատարողականի և արտադրողականության կառավարում;

Ծրագրի քանակական կառավարում.

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

Ամբողջ կազմակերպության շրջանակներում մշակվում է ծրագրային ապահովման ստեղծման արտադրողականության և դրա որակի քանակական վերահսկողության միասնական ծրագիր։ Գործընթացների վերլուծությունը հեշտացնելու համար կազմակերպությունում իրականացվող բոլոր նախագծերի համար ստեղծվում է ծրագրային ապահովման ստեղծման և պահպանման գործընթացների միասնական տվյալների բազա: Մշակվում են ունիվերսալ մեթոդներ՝ գործընթացների արտադրողականությունը և դրանց իրականացման որակը չափելու համար։ Սա թույլ է տալիս ծրագրային ապահովման ստեղծման և սպասարկման գործընթացների քանակական վերլուծություն և գնահատում:

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

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

5-րդ մակարդակում ավելացվում են հետևյալ գործընթացները.

տեխնոլոգիական և կազմակերպչական նորամուծությունների ներդրում;

պատճառահետևանքային վերլուծություն և խնդիրների լուծում: Ծրագրային ապահովման ստեղծման և պահպանման գործընթացները բնութագրվում են

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

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

Յուրաքանչյուր հաջորդ մակարդակ լրացուցիչ ապահովում է ծրագրային ապահովման ստեղծման և պահպանման գործընթացների ավելի ամբողջական տեսանելիություն:

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

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

Երրորդ մակարդակում սահմանվում է «սև արկղերի» ներքին կառուցվածքը, այսինքն. առաջադրանքները, որոնք կազմում են գործընթացները: Ներքին կառուցվածքն այն ձևն է, որով կազմակերպությունում ստանդարտ գործընթացները կիրառվում են կոնկրետ նախագծերի համար: Կառավարման օղակը և կատարողները գիտեն իրենց դերերն ու պարտականությունները նախագծի շրջանակներում այնքան մանրամասնորեն: Ղեկավարությունը նախապես պատրաստված է այն ռիսկերին, որոնք կարող են առաջանալ ծրագրի իրականացման ընթացքում: Քանի որ ստանդարտացված և փաստաթղթավորված գործընթացները վերանայման համար դառնում են «թափանցիկ», այն աշխատակիցները, ովքեր անմիջականորեն ներգրավված չեն նախագծում, կարող են ժամանակին ստանալ ճշգրիտ տեղեկատվություն դրա ներկայիս կարգավիճակի մասին:

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

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

Չորրորդ և հինգերորդ մակարդակները հազվադեպ են ծրագրային ապահովման ոլորտում: Այսպիսով, եթե աշխարհում մի քանի հարյուր ընկերություններ հասել են երրորդ մակարդակին, ապա հինգերորդ մակարդակի 62 ընկերություն կար (ըստ SEI 2002 թվականի տվյալների), իսկ չորրորդից՝ 72։ Ոմանք շահագրգռված չեն գովազդել իրենց կազմակերպչական տեխնոլոգիաները, իսկ մյուսները սերտիֆիկացում են կատարում պարզապես հաճախորդի ճնշման ներքո:

SMM-ի ամենաբարձր մակարդակներին հասնելու համար տաս կամ ավելի տարի է պահանջվում: Բայց նույնիսկ 3-րդ մակարդակը թույլ է տալիս համարձակորեն դուրս գալ միջազգային ասպարեզ: SMM-ից օգտվելու համար ընկերությունը կարիք չունի որոշ յուրահատուկ ունակություններով աշխատողներ փնտրելու, բավական է, որ նա հասկանա ընդհանուր գաղափարը։ CMM մոդելի նկարագրությունը մանրամասնորեն նշում է, թե ինչ է պետք անել այս մոդելին համապատասխան զարգանալու համար: Միջին խավի ցանկացած մենեջեր ի վիճակի է հետևել CMM-ի կանոնակարգված գործողություններին:

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

2002 թվականից CMMI-ի հատուկ ինտեգրացիոն տարբերակը պաշտոնապես տարածվել է: Սա SEI-ի նոր զարգացումն է, որն ընդգրկում է ընկերության գործունեության բոլոր ասպեկտները՝ կապալառուի մշակումից և ընտրությունից մինչև վերապատրաստում, իրականացում և սպասարկում: Բացի այդ, CMMI մոդելը ընդլայնվել է համակարգերի ճարտարագիտության մոտեցումներով: Այս մոդելը ներառում է CMM 2.0 տարբերակի նախագծման ժամանակ կատարված զարգացումները (այն չի ավարտվել), որոնց հիմնական փոփոխություններն ուղղված են եղել չորրորդ և հինգերորդ մակարդակների ընկերությունների գործընթացների պարզաբանմանը, ինչը առավել արդիական է ամերիկյան խոշոր նախագծերի համար:

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

SMM-ի թերությունները ներառում են հետևյալը.

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

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

3. Մոդելի շրջանակը սահմանված չէ, թեև հեղինակները ընդունում են, որ այն ունիվերսալ է և հարմար է բոլոր կազմակերպությունների համար։ Այնուամենայնիվ, հեղինակները հստակ տարբերակում չեն դնում այն կազմակերպությունների միջև, որոնք կարող են կամ չեն կարող իրականացնել SMM-ն իրենց գործունեության մեջ: Փոքր ընկերությունները այս մոդելը չափազանց բյուրոկրատական են համարում: Ի պատասխան այս քննադատությունների՝ մշակվել են գործընթացների բարելավման ռազմավարություններ փոքր կազմակերպությունների համար:

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

1. ոչ պաշտոնական գործընթաց.Չունի բարելավման հստակ սահմանված մոդել։ Այն կարող է հաջողությամբ օգտագործվել զարգացման առանձին թիմի կողմից

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

2. Կառավարվող գործընթաց.Ունի պատրաստված մոդել, որն ուղղորդում է կատարելագործման գործընթացը: Մոդելը սահմանում է գործողությունները, դրանց ժամանակացույցը և նրանց միջև փոխհարաբերությունները:

3. Մեթոդական հիմնավոր գործընթաց.Ենթադրվում է, որ ներդրվել են որոշակի մեթոդներ (օրինակ, օբյեկտի վրա հիմնված նախագծման մեթոդները համակարգված են կիրառվում): Այս տեսակի գործընթացի համար օգտակար կլինեն գործընթացի նախագծման և վերլուծության օժանդակ գործիքները (CASE-tools):

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

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

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

Բրինձ. 1.8. Բարելավման գործընթացների կիրառելիություն

Մշակվող արտադրանքի տեսակի իմացությունը կստեղծի համապատասխանություն ծրագրային համակարգերի և բարելավման գործընթացների միջև, որոնք ներկայացված են Նկ. 1.8 օգտակար գործընթացի բարելավման ընտրության հարցում: Օրինակ, դուք պետք է ստեղծեք ծրագիր, որը կաջակցի ծրագրային ապահովման անցումը մեկ համակարգչային հարթակից մյուսին: Նման ծրագիրն ունի բավականին կարճ ժամկետ, ուստի դրա մշակումը չի պահանջում ստանդարտներ և հատուկ վարչակազմբարելավման գործընթաց, ինչպես երկարակյաց համակարգերի ստեղծման դեպքում։

Շատերը տեխնոլոգիական գործընթացներներկայումս ունեն CASE աջակցություն, այնպես որ նրանք կարող են զանգահարել աջակցվող գործընթացներ:Մեթոդապես արդարացված գործընթացներաջակցվում է վերլուծության և նախագծման գործիքներով: Աջակցման գործիքի արդյունավետությունը կախված է կիրառվող բարելավման գործընթացից: Օրինակ, ոչ ֆորմալ գործընթացում կարող են օգտագործվել տիպիկ օժանդակ գործիքներ (նախատիպային գործիքներ, կոմպիլյատորներ, վրիպազերծման գործիքներ, տեքստային պրոցեսորներ և այլն): Քիչ հավանական է, որ ոչ պաշտոնական գործընթացներում շարունակաբար կիրառվեն աջակցության ավելի մասնագիտացված գործիքներ:

SMM մոդելը եզակի չէ: Գրեթե ամեն մեծ ընկերությունմշակում է ծրագրային ապահովման ստեղծման սեփական տեխնոլոգիաները, երբեմն այդ տեխնոլոգիաները դառնում են հանրությանը հասանելի և շատ տարածված: HMM մոդելի լայն ժողովրդականությունը կապված է դրա հետ պետական աջակցություն, սակայն SMM-ի իրական արդյունավետությունը քննադատվում է բազմաթիվ առաջատար փորձագետների կողմից: ՀՄՄ-ի հիմնական թերություններից մեկը կապված է այս մոդելի սկզբունքներից չշեղվելու անհարկի կոշտ պահանջի հետ, նույնիսկ եթե ողջախոհությունն այլ բան է հուշում: Բացարձակ ճշմարտության տիրապետման նման պնդումները չեն կարող կասկածներ չհարուցել, հետևաբար փոքր և միջին ընկերությունների շրջանում ավելի տարածված են մոտեցումները, որոնք շատ ավելի մեծ ազատություն են թողնում անհատական և կոլեկտիվ ստեղծագործության համար: Ստորև քննարկված SPMN մեթոդաբանությունը միջանկյալ տեղ է զբաղեցնում կոշտ, «ծանր», արդյունավետ խոշոր կազմակերպությունների համար լուծումների, ինչպիսիք են CMM-ը և առավել ճկուն տեխնոլոգիաները: Նա հայտնվում է լավագույն տարբերակըընկերությունների համար, որոնք, մի կողմից, ցանկանում են արդիականացնել իրենց կառավարչական գործունեություն, իսկ մյուս կողմից՝ ապագայում ծրագրում են հասնել միջազգային մակարդակովորտեղ CMM հավաստագրումը շատ ցանկալի է:

Օգտագործելով սահմանված ծրագրային ապահովման մշակման գործընթաց՝ կազմակերպություններն ունեն գործընթացի հետևողական ծրագիր, որը նրանք կարող են հարմարեցնել իրենց հատուկ կարիքներին: Անհատականացման և ստանդարտացման անհամատեղելի կարիքները կարող են լուծվել գործընթացի կառուցվածքը կառուցելով որպես ստանդարտ մոդուլներից կամ «հիմնական» քայլերից և կանոններից, որոնք օգտագործվում են նկարագրելու և այդ քայլերի միջև հարաբերություններ հաստատելու համար: Այս դեպքում հարմարվողականությունը ձեռք է բերվում դրանք գործընթացի մոդելում համատեղելով:

Որպես կանոն, ծրագրային նախագծերի որակի կառավարումը հիմնված է երեք աղբյուրների գիտելիքների վրա.

Ծրագրային ճարտարագիտություն (ACM, IEEE);

Ծրագրի կառավարում (PMI);

Որակ (ASQ):

Քարնեգի Մալոնի համալսարանի Ծրագրային ճարտարագիտության ինստիտուտը (SEI) միավորում է այս երեք աղբյուրները:

Հասունության առանձնահատկությունների մոդելը (ՀնարավորությունՀասունությունՄոդել, SMM), ծառայում է որպես «շրջանակ» ծրագրային ապահովման մշակման գործընթացի համար։ Այս մոդելը հիմնված է գործողությունների վրա և արտացոլում է այն անհատների լավագույն արդյունքները, որոնք աշխատում են ծրագրային ապահովման մշակման գործընթացը բարելավելու և գործընթացի գնահատողական վերլուծություն իրականացնելու ուղղությամբ: Հետևյալում կանդրադառնանք, թե ինչպես է ծրագրային ապահովման նախագծերի որակի կառավարումը համապատասխանում SEI CMM մոդելին: Քանի որ CMM մոդելը լավ հայտնի է ծրագրային ապահովման մշակման համայնքում, դրա սահմանման հատուկ կարիք չկա: Մենք կներկայացնենք դրա միայն համառոտ նկարագրությունը՝ ցույց տալու համար կյանքի ցիկլի օգտագործման անհրաժեշտությունը զարգացման գործընթացում։ Ստորև ներկայացված է HMM մոդելի ֆունկցիոնալ հնարավորությունների զարգացման մակարդակների համառոտ ընդհանրացված նկարագրությունը:

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

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

Կրկնվող.Ծրագրի կառավարման հիմնական գործընթացները ստեղծվում են ծախսերը, ժամանակացույցը և ֆունկցիոնալությունը հետևելու համար: Այստեղ պահպանվում է գործընթացի կատարման անհրաժեշտ կարգը՝ նախատեսված նմանատիպ նախագծերի իրականացման ժամանակ նախկինում ձեռք բերված ձեռքբերումները կրկնելու համար։

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

Կարողացավ.Հավաքվում են ծրագրային ապահովման մշակման գործընթացի և արտադրանքի որակական բնութագրերի մանրամասն ցուցիչներ: Ծրագրային արտադրանքի մշակման գործընթացի կառավարումն իրականացվում է քանակական մակարդակով։

Օպտիմիզացման մակարդակ:Զարգացման գործընթացի շարունակական բարելավումը ձեռք է բերվում քանակական հետադարձ կապի միջոցով:

Այս կապը ձեռք է բերվում հենց գործընթացի իրականացման, ինչպես նաև նորարարական գաղափարների և տեխնոլոգիաների հիման վրա։ Յուրաքանչյուր հասունության մակարդակ բաժանված է մի քանի հիմնական գործընթացների ոլորտների, որոնք ցույց են տալիս, թե ինչ գործողություններ դեռ պետք է ձեռնարկվեն ծրագրային ապահովման մշակման գործընթացը բարելավելու համար: Յուրաքանչյուրը հիմնական գործընթացի տարածքը (բանալիգործընթացտարածք,KPA) սահմանում է փոխկապակցված գործողությունների մի շարք, որոնք անհրաժեշտ են այս գործընթացը օպտիմալացնելու համար:

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

Այնուամենայնիվ, կրկնվող գործընթաց ունենալը (մակարդակ 2) պարտադիր չէ, որ հանգեցնի լավ մշակված գործընթացի: Ընդհանուր առմամբ, գործընթացի բարելավումը տեղի է ունենում, երբ կազմակերպությունը հասնում է 3-րդ մակարդակին: Մակարդակ 3-ը վերաբերում է ինչպես նախագծին առնչվող, այնպես էլ կազմակերպչական խնդիրների լուծմանը, քանի որ կազմակերպությունը ստեղծում է ենթակառուցվածք, որն ապահովում է արդյունավետ ծրագրային ապահովման տեխնիկա և կառավարում բոլոր նախագծերի համար: KPA-ի երկու ոլորտները՝ գործընթացի կազմակերպման սահմանումը և ինտեգրված ծրագրի կառավարումը, պատկանում են առարկայական ոլորտին կյանքի ցիկլերը.

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

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

CMM-ը վերաբերում է ծրագրային ապահովման գործընթացի մոդելների խմբին, որոնք մշակվել են ծրագրային ապահովման մշակման համայնքի կողմից մշակված լայն բազայի վրա: Քանի որ մենք գործ ունենք մոդելի հետ, կա բուն ինժեներական գործընթացի պարզեցում: Ներկայացնելով ստանդարտ՝ CMM մոդելը բացահայտում է որոշակի հասունության կատեգորիային պատկանող կազմակերպության հնարավորությունները:

Այս մոդելը որպես գործընթացների չափման և բարելավման մեխանիզմ օգտագործող կազմակերպությունները պետք է օգտագործեն գործընթացի գիտելիքների ոլորտների ընդունելի մեկնաբանությունը բիզնեսի նպատակների տեսանկյունից: Երբ օգտագործվում է որպես գործընթացի գնահատման և չափման գործիք, այս մոդելը դառնում է գործընթացի հաջող բարելավման ճանապարհային քարտեզ: Ընդհանուր առմամբ, CMM մոդելը կարող է դիտվել որպես լավ ձևակերպված ինժեներական և կառավարման հայեցակարգերի մի շարք, որոնք հիմնված են ապացուցված երաշխիքի սկզբունքների վրա: Ծրագրային ապահովման մշակման գործընթացում, որտեղ գիտելիքը պետք է պատշաճ կերպով գնահատվի և պաշտպանվի, որակի ապահովման սկզբունքներին պետք է զգալի ուշադրություն դարձնել: SMM մոդել ոչբոլոր առիթների համար նախատեսված դեղատոմսերի հավաքածու է: Այն չի նշում, թե ինչպես պետք է կազմակերպությունը սահմանի գործընթացի ատրիբուտները: Նաև դրա կիրառումը չի երաշխավորում անմիջական հաջողություն: Բարելավումների իրականացման գործընթացը պահանջում է ժամանակ և շարունակական ջանք ամբողջ կազմակերպությունում: Միաժամանակ առանձնահատուկ նշանակություն ունեն գործադիր կառավարումը և հատկացված միջոցները։ CMM մոդելը դժվար է դասակարգել որպես ունիվերսալ մեթոդոլոգիա, երբ «մեկ չափը համապատասխանում է բոլոր առիթներին»: Այս մոդելն օգտագործելու առաջին քայլը հավելվածի հասունության մակարդակների հարմարեցումն է ձեր կազմակերպությանը և գոյություն ունեցող նախագծերի շարքին համապատասխանելու համար: SEI-ի կողմից մշակվել են կարողությունների հասունության այլ մոդելներ, որոնք կիրառելի են կազմակերպչական անձնակազմի, ծրագրային ապահովման ձեռքբերման գործընթացի, համակարգերի ճարտարագիտության, ինտեգրված ծրագրային ապահովման մշակման գործընթացի և անձնական ծրագրային ապահովման գործընթացի համար:

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

HMM մոդելի հիմնական կիրառություններից մեկը սահմանելն է, թե ինչ է նշանակում հասունության որոշակի աստիճանի հասած գործընթաց: Ինչ վերաբերում է ծրագրային ապահովմանը, մենք կարող ենք ասել, որ հասուն գործընթացն ունի հետևյալ հատկանիշները.

Սահմանված - նշում է «գործը ավարտելու համար անհրաժեշտ մեթոդը»;

Փաստաթղթավորված - նախագծված է այնպես, որ այն հնարավոր լինի ճանաչել և օգտագործել ապագայում.

Սովորած - փաստաթղթերի վրա հիմնված ուսուցում;

Գործնական - կարող է կիրառվել գործնականում, և ոչ թե անորոշ ժամանակով հետաձգվել;

Պահպանված - հասանելի, վերանայված և բարելավված;

Վերահսկվող - փոփոխությունները հաստատվում են «համատեղ գործի մասնակիցների» կողմից.

Ստուգված - գործընթացը ճիշտ է ընթանում.

Ստուգված - կատարվում է հենց այն գործընթացը, որն անհրաժեշտ է.

Չափված - գնահատված կատարողականը կիրառվում է որպես գործընթացի վերահսկման և բարելավման հիմք;

Բարելավվելու ունակություն - ճկունություն և փոխելու ունակություն:

Ծրագրային ճարտարագիտությունը պատկանում է 3-րդ մակարդակի հիմնական գործընթացների ոլորտին, այսինքն. «որոշ». Մինչեւ 1968 թվականը «ծրագրային ճարտարագիտություն» տերմինն ընդհանրապես չէր օգտագործվում։ Ծրագրային ապահովման ճարտարագիտությունգիտական գիտելիքների գործնական կիրառում է համակարգչային ծրագրերի նախագծման և մշակման գործընթացում: Այս գործընթացը կոչվում է նաև ծրագրային ապահովման մշակումկամ ծրագրի արտադրություն։

Համատարած ծրագրային ապահովման առաջին ի հայտ գալը թվագրվում է 1890 թվականին։ Հենց այդ ժամանակ էր, որ Հերման Չոլերիտի (1860-1929), Մասաչուսեթսի տեխնոլոգիական ինստիտուտի (Քեմբրիջ, Մասաչուսեթս) դակված բացիկները հայտնվեցին ամերիկյան մարդահամարի կենտրոններում:

Միևնույն ժամանակ եղել է ծախսերի առաջին գերակատարումը «համակարգիչների» մեղքով։ ԱՄՆ-ի մարդահամարի կենտրոնների արդյունքներն ի սկզբանե աղյուսակավորվել են մեխանիկական օժանդակ միջոցներով. մեխանիկական աղյուսակներ Հերման Հոլերիթի կողմից: Զուգահեռաբար սկսեց զարգանալ բռունցքով հարվածված քարտերի արտադրությունը։ Այս մարդահամարի կենտրոնների աղյուսակավորման վրա ծախսված միջոցները 98%-ով ավելի են եղել, քան նախկինում կատարված նմանատիպ ծախսերը: Սա մասամբ պայմանավորված է նրանով, որ տվյալների աղյուսակավորման համար օգտագործվող ձևանմուշը մշակվել է շատ մանրամասն, և աղյուսակավորված տվյալների քանակը գերազանցել է նվազագույն պահանջվող քանակը: Թեև աղյուսակավորման գործընթացը ինքնին զգալիորեն արագացել է։ Միաժամանակ հայտնվել են դակված բացիկներ, որոնց ընթերցումը կատարվել է էլեկտրական եղանակով։

Վերադառնալով CMM մոդելին՝ մենք նշում ենք, որ 2-րդ մակարդակում ծրագրային ապահովման մշակման գործընթացը կարող է ներկայացվել որպես «սև արկղերի» մի շարք՝ որոշակի կառավարման կետերով (փուլերով): Ինչպես ցույց է տրված նկ. 2.1, պահանջները ներառված են գործընթացում և սահուն «հոսում» են «սև արկղերի» մի շարք։

Բրինձ. 2.1. 2-րդ մակարդակի գործընթաց

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

3-րդ մակարդակում, այսինքն. «սահմանված», փաստաթղթերում և հետևողականորեն օգտագործում է ստանդարտ գործընթացը, որն օգտագործվում է կազմակերպությունում ծրագրային ապահովման մշակման և պահպանման համար, որը սխեմատիկորեն պատկերված է Նկ. 2.2.

Բրինձ. 2.2. Մակարդակ 3 Գործընթաց

Նախագծերի շրջանակներում կազմակերպության ստանդարտ ծրագրային գործընթացները ճշգրտվում են դրանք կոնկրետացնելու համար։ Ինտեգրված են նաև կառավարման և ծրագրային ապահովման գործընթացները: Ստանդարտ գործընթաց իրականացնելու ունակությունը ստանդարտ է, և մշակող թիմը պատասխանատու է այնտեղ կատարվող գործողությունների համար ծրագրային նախագիծ. Հետևյալները KPA տարածքներն են հասունության երրորդ մակարդակի համար.

1) կազմակերպչական գործընթացի շրջանակը.

2) կազմակերպչական գործընթացի սահմանումը.

3) ծրագրային արտադրանքի ճարտարագիտություն.

4) ինտեգրված ծրագրային կառավարում.

5) խմբերի փոխազդեցությունը.

6) փորձագիտական գնահատականները.

7) ուսումնական պլան.

3-րդ մակարդակում ծրագրային ապահովման մշակման գործընթացը հետևում է հստակ սահմանված գործընթացին: Գործընթացի ընթացքում անհրաժեշտ է դերերի և պարտականությունների իրազեկում: Ծրագրային արտադրանքի արտադրության գործընթացը ցուցադրվում է ծրագրային ապահովման գործընթացի կատարման ընթացքում:

Մակարդակ 4 (նկ. 2.3), այսինքն. «կառավարվող», ներառում է KPA-ի երկու ոլորտ՝ գործընթացների քանակական կառավարում և ծրագրային ապահովման որակի կառավարում:

Բրինձ. 2.3. 4-րդ մակարդակի գործընթաց

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

5-րդ մակարդակում («օպտիմալացում») KPA-ի տարածքները կենտրոնանում են տեխնոլոգիական փոփոխությունների կառավարման, գործընթացների փոփոխության կառավարման և թերությունների կանխարգելման փուլերի վրա: Գործընթացի շարունակական բարելավման միջոցով՝ քանակական Հետադարձ կապծրագրային ապահովման մշակման գործընթացի հետ կապված: Այս մակարդակում կազմակերպությունում կարող են փորձարկվել նոր գաղափարներ և տեխնոլոգիաներ՝ բարելավելու ծրագրային արտադրանքի որակը, որը սխեմատիկորեն պատկերված է Նկ. 2.4.

Բրինձ. 2.4. Մակարդակ 5 Գործընթաց

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

1) գործընթացը պետք է մշակութային առումով համապատասխան լինի կազմակերպությանը.

2) ղեկավարությունը պարտավոր է նպաստել մշակույթի աստիճանի բարձրացմանը.

3) մշակույթը պետք է խրախուսի դերային օրինակների և պարգևների ներդրումը:

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