Կառուցվածքային մոտեցում. Համակարգային մոտեցում ծրագրային ապահովման մշակմանը: Համակարգային մոտեցման ժամանակային և «տարածական» ասպեկտները: Waterfall ծրագրային ապահովման կյանքի ցիկլի մոդելը Ծրագրային ապահովման մշակման մոտեցումներ

1. Կասկադ (անգլերեն ջրվեժ)՝ զարգացման ստանդարտ մոդել

Կասկադի զարգացման մոդել - մոդել, որում զարգացման բոլոր փուլերն իրականացվում են հաջորդաբար, հաջորդ փուլը սկսվում է նախորդի ավարտից հետո:

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

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

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

Ջրվեժի զարգացման հիմնական առավելությունները.

2. Արագաշարժ ծրագրային ապահովման մշակման մեթոդիկա

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

Յուրաքանչյուր նման փուլի արդյունքը, ներառյալ կրկնությունների ցիկլը, մանրանկարչական ծրագրային նախագիծ է,

Կան մի քանի արագաշարժ զարգացման մեթոդներ, առավել հայտնի են Scrum, Extreme Programming, DSDM:

Ճկուն զարգացման հիմնական առավելությունները.

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

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

Արագաշարժ զարգացման սկզբունքները.

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

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

Կտեսնենք, թե ինչպես կանցնի…

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

Մշակում «Ինչպես է այն աշխատում»

Ի՞նչ կասեք կրկնվող մոտեցման մասին: Ավաղ, որպես կանոն, այն չի օգտագործվում նման նախագծերում։ Առաջին հերթին, որովհետև դա թույլ կտա նույնիսկ առաջին անգամների ժամանակ նախագիծը գնահատել որպես ծայրահեղ կասկածելի և կարգուկանոնը վերականգնելու համար բարձրագույն ղեկավարության հրատապ միջամտություն պահանջող: Ի վերջո, կրկնվող նախագծում ծրագրավորողի ավանդական պատասխանը, որ իր համար ամեն ինչ 90%-ով պատրաստ է, տևում է միայն մինչև առաջին կրկնության ավարտը…

Կառուցվածքային մեթոդաբանություններ

Կառուցվածքային մեթոդաբանություններ

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

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

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

Արագաշարժ մեթոդներ

Արագաշարժ մեթոդաբանությունները հիմնված են տասը սկզբունքների վրա, որոնցից մենք կնշենք միայն նրանք, որոնք որոշում են այս մեթոդոլոգիաների գնահատումը ըստ ընտրված պարամետրերի.

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

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

էքստրեմալ ծրագրավորում կամ XP (ծայրահեղ ծրագրավորում)

XP մեթոդաբանությունը, որը մշակվել է Քենթ Բեքի, Ուորդ Կանինգհեմի և Ռոն Ջեֆրիսի կողմից, այսօր ամենահայտնին արագաշարժ մեթոդոլոգիաներից է: Երբեմն հենց «ճկուն մեթոդոլոգիաների» հասկացությունը բացահայտ կամ անուղղակիորեն նույնացվում է XP-ի հետ, որը քարոզում է մարդամոտություն, պարզություն, հետադարձ կապև քաջություն: Այն նկարագրվում է որպես պրակտիկաների մի շարք՝ պլանավորման խաղ, կարճ թողարկումներ, փոխաբերություններ, պարզ ձևավորում, կոդի վերամշակում (վերագործարկում), փորձնական մշակում, զույգերի ծրագրավորում, կոլեկտիվ կոդի սեփականություն, 40-ժամյա աշխատանքային շաբաթ, մշտական ​​հաճախորդի ներկայություն և կոդերի ստանդարտներ: XP-ի նկատմամբ հետաքրքրությունն աճեց ներքևից վեր՝ մշակողների և փորձարկողների կողմից, որոնց տանջում էին ցավոտ գործընթացները, փաստաթղթերը, չափումները և այլ ֆորմալիզմը: Նրանք չէին մերժում կարգապահությունը, բայց չէին ցանկանում անիմաստ հետևել ֆորմալ պահանջներին և փնտրում էին նոր արագ և ճկուն մոտեցումներ բարձրորակ ծրագրերի մշակման համար։

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

Թեև զույգ ծրագրավորումը և 40-ժամյա աշխատանքային շաբաթը, հավանաբար, XP-ի ամենահայտնի հատկանիշներն են, դրանք դեռևս օգտակար և աջակցող են: բարձր կատարողականմշակողներին և նվազեցնելով մշակման սխալների քանակը:

Բյուրեղյա մաքուր

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

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

Crystal Clear-ի հիմնական առանձնահատկությունները.

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

Բացի Crystal Clear-ից, Crystal ընտանիքում կան մի քանի այլ մեթոդաբանություններ, որոնք նախատեսված են ավելի մեծ կամ ավելի կարևոր նախագծերի համար: Դրանք տարբերվում են փաստաթղթերի քանակի և օժանդակ ընթացակարգերի համար մի փոքր ավելի խիստ պահանջներով, ինչպիսիք են փոփոխությունները և տարբերակների վերահսկումը:

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

Առանձնահատկությունների վրա հիմնված զարգացում (FDD) գործում է համակարգի գործառույթի կամ հատկանիշի տեսանկյունից, որը բավականին մոտ է RUP-ի օգտագործման դեպքերի հայեցակարգին: Թերևս ամենաէական տարբերությունը լրացուցիչ սահմանափակումն է. «յուրաքանչյուր գործառույթ պետք է թույլ տա իրականացնել ոչ ավելի, քան երկու շաբաթում»: Այսինքն, եթե օգտագործման գործը բավականաչափ փոքր է, այն կարելի է համարել ֆունկցիա, իսկ եթե մեծ է, ապա պետք է բաժանել մի քանի համեմատաբար անկախ ֆունկցիաների։

FDD-ն ներառում է հինգ գործընթաց, որոնց վերջին երկուսը կրկնվում են յուրաքանչյուր հատկանիշի համար.

• զարգացում ընդհանուր մոդել;
• ցուցակագրում անհրաժեշտ գործառույթներըհամակարգեր;
• պլանավորել աշխատանք յուրաքանչյուր գործառույթի վրա;
• գործառույթի ձևավորում;
• ֆունկցիայի կառուցում։

Նախագծի վրա աշխատանքը ներառում է հաճախակի կառուցումներ և բաժանված են կրկնությունների, որոնցից յուրաքանչյուրն իրականացվում է հատուկ գործառույթների կիրառմամբ:

FDD-ում մշակողները բաժանվում են «դասակարգի վարպետների» և «գլխավոր ծրագրավորողների»: Հիմնական ծրագրավորողները ներգրավում են ներգրավված դասերի տերերին՝ հաջորդ գույքի վրա աշխատելու համար։ Համեմատության համար. XP-ում դասերի կամ մեթոդների համար անձնական պատասխանատվություն չկա:

Ընդհանուր հատկանիշներ

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

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

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

Արագաշարժ մեթոդներ

ԳՕՍՏ-ներ

ԳՕՍՏ-ները, ինչպես հաջորդ բաժնում նկարագրված CMM-ի պահանջները, մեթոդաբանություն չեն: Նրանք, որպես կանոն, իրենք չեն նկարագրում ծրագրային ապահովման մշակման գործընթացները, այլ միայն ձևակերպում են գործընթացների որոշակի պահանջներ, որոնց այս կամ այն ​​աստիճանին համապատասխանում են տարբեր մեթոդաբանություններ։ Պահանջների համեմատությունը նույն չափանիշների համաձայն, որոնցով մենք համեմատում ենք մեթոդաբանությունները, կօգնի ձեզ անմիջապես որոշել, թե որ մեթոդոլոգիաները պետք է օգտագործեք, եթե ձեզ անհրաժեշտ է մշակել ԳՕՍՏ-ին համապատասխան:

Ներկայումս Ռուսաստանում գործում են 19-րդ և 34-րդ սերիաների հին ԳՕՍՏ-ները և ավելի նոր ԳՕՍՏ Ռ ԻՍՕ IEC 122207: 19-րդ և 34-րդ սերիաների ԳՕՍՏ-ները խստորեն կենտրոնացած են ծրագրային ապահովման մշակման կասկադային մոտեցման վրա: Այս ԳՕՍՏ-ներին համապատասխան մշակումն իրականացվում է փուլերով, որոնցից յուրաքանչյուրը ներառում է խիստ սահմանված աշխատանքների կատարում և ավարտվում է բավականին մեծ թվով շատ պաշտոնական և ծավալուն փաստաթղթերի թողարկումով: Այսպիսով, այդ չափանիշներին անհապաղ խիստ պահպանումը ոչ միայն հանգեցնում է ջրվեժի մոտեցմանը, այլև ապահովում է զարգացման շատ բարձր աստիճանի պաշտոնականացում:

ԳՕՍՏ-ի պահանջները

ԳՕՍՏ 12207-ը, ի տարբերություն 19-րդ և 34-րդ սերիաների ստանդարտների, նկարագրում է ծրագրային ապահովման մշակումը որպես հիմնական և օժանդակ գործընթացների մի շարք, որոնք կարող են գործել նախագծի սկզբից մինչև վերջ: Մոդել կյանքի ցիկլկարող է ընտրվել՝ ելնելով նախագծի առանձնահատկություններից: Այսպիսով, այս ԳՕՍՏ-ը բացահայտորեն չի արգելում կրկնվող մոտեցման օգտագործումը, բայց բացահայտորեն չի առաջարկում դրա օգտագործումը: ԳՕՍՏ 12207-ն ավելի ճկուն է նաև մշակման գործընթացի ձևականության պահանջների առումով: Այն պարունակում է միայն բոլոր գործընթացների հիմնական արդյունքները փաստաթղթավորելու անհրաժեշտության ցուցումներ, սակայն չի պարունակում պահանջվող փաստաթղթերի ցանկեր և դրանց բովանդակության վերաբերյալ հրահանգներ:

Այսպիսով, ԳՕՍՏ 12207-ը թույլ է տալիս կրկնվող և ավելի քիչ պաշտոնականացված ծրագրային ապահովման մշակում:

Մշակման գործընթացի հասունության մոդելներ (CMM, CMMI)

Բացի կառավարությունից և միջազգային չափանիշներին, զարգացման գործընթացի հավաստագրման մի քանի մոտեցում կա։ Ռուսաստանում դրանցից ամենահայտնին, ըստ երևույթին, CMM և CMMI են:

CMM (Capability Maturity Model) ծրագրային ապահովման մշակման գործընթացների հասունության մոդել է, որը նախատեսված է որոշակի ընկերությունում մշակման գործընթացի հասունության մակարդակը գնահատելու համար: Ըստ այս մոդելի՝ զարգացման գործընթացի հասունության հինգ մակարդակ կա. Առաջին մակարդակը համապատասխանում է «ինչպես է ընթանում» մշակմանը, երբ ծրագրավորողները գնում են յուրաքանչյուր նախագծի որպես սխրանք: Երկրորդը համապատասխանում է քիչ թե շատ կայացած գործընթացներին, երբ բավարար վստահությամբ հնարավոր է հույս դնել նախագծի դրական արդյունքի վրա: Երրորդը համապատասխանում է մշակված և լավ նկարագրված գործընթացների առկայությանը, որոնք օգտագործվում են մշակման մեջ, իսկ չորրորդը համապատասխանում է չափումների ակտիվ օգտագործմանը կառավարման գործընթացում՝ նպատակներ դնելու և դրանց ձեռքբերումը վերահսկելու համար: Վերջապես, հինգերորդ մակարդակը վերաբերում է ընկերության կարողությանը օպտիմալացնել գործընթացը ըստ անհրաժեշտության:

CMM և CMMI պահանջներ

CMM-ի հայտնվելուց հետո սկսեցին մշակվել մասնագիտացված հասունության մոդելներ՝ ստեղծելու համար տեղեկատվական համակարգեր, մատակարարների ընտրության գործընթացի համար և մի քանի այլ: Դրանց հիման վրա մշակվել է ինտեգրված CMMI մոդել (Capability Maturity Model Integration): Բացի այդ, CMMI-ում փորձ է արվել հաղթահարել CMM-ի այն թերությունները, որոնք դրսևորվել էին այն ժամանակ. բայց ոչ նկարագրված գործընթաց: Այնուամենայնիվ, CMMI-ն նույնպես կենտրոնացած է խիստ ֆորմալացված գործընթացի օգտագործման վրա:

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

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

RUP

Իհարկե, RUP-ը կրկնվող մեթոդաբանություն է: Թեև ֆորմալ առումով բոլոր փուլերի պարտադիր կատարումը կամ կրկնությունների մի քանի նվազագույն քանակը ոչ մի տեղ նշված չէ RUP-ում, ամբողջ մոտեցումը կենտրոնացած է այն փաստի վրա, որ դրանք բավականին շատ են: Կրկնումների սահմանափակ թիվը թույլ չի տալիս լիարժեք օգտվել RUP-ից: Միևնույն ժամանակ, RUP-ը կարող է օգտագործվել նաև գրեթե կասկադային նախագծերում, որոնք իսկապես ներառում են ընդամենը մի քանի կրկնություններ՝ մեկը Build փուլում, մյուսը՝ Փոխանցման փուլում: Ի դեպ, սա այն կրկնությունների քանակն է, որն իրականում օգտագործվում է ջրվեժի նախագծերում: Ի վերջո, համակարգի թեստավորումը և փորձնական գործարկումը ենթադրում են ուղղումներ, որոնք կարող են ներառել որոշակի գործողություններ՝ կապված վերլուծության, նախագծման և մշակման հետ, այսինքն, իրականում դրանք ևս մեկ անցում են զարգացման բոլոր փուլերի միջով:

RUP մեթոդաբանություն

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

Այսպիսով, RUP-ը կրկնվող մեթոդաբանություն է՝ շատ լայն շրջանակով հնարավոր լուծումներզարգացման գործընթացի պաշտոնականացման առումով։

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

Իսկ թե ինչու է դա այդքան կարևոր, մենք կքննարկենք հաջորդ մասում:

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

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

Կառուցվածքային մոտեցման հիմնական սկզբունքներն են.

o սկզբունք» բաժանիր և տիրիր»;

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

Այս սկզբունքներից հիմնականներն են.

o վերացականություն - ընդգծելով համակարգի էական կողմերը.

o հետևողականություն - համակարգի տարրերի վավերականությունը և հետևողականությունը.

o տվյալների կառուցվածքավորում - տվյալները պետք է լինեն կառուցվածքային և հիերարխիկորեն կազմակերպված:

Ծրագրային ապահովման մշակման տեխնոլոգիաների մեթոդաբանական հիմքերը

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

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

o նախագծված համակարգի դժվարությունները.

o դրա նկարագրության անհրաժեշտ ամբողջականությունը.

o ծրագրի մասնակիցների գիտելիքներն ու հմտությունները.

o նախագծման համար հատկացված ժամանակ:

Տեսողական մոդելավորումը մեծ ազդեցություն է ունեցել հատկապես CASE գործիքների զարգացման վրա: CASE (Computer Aided Software Engineering) հայեցակարգը օգտագործվում է լայն իմաստով: Այս հայեցակարգի սկզբնական իմաստը, որը սահմանափակվում է միայն ծրագրային ապահովման մշակման ավտոմատացման խնդիրներով, այժմ նոր իմաստ է ստացել՝ ընդգրկելով ծրագրային ապահովման կյանքի ցիկլի գործընթացների մեծ մասը:

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

1. Ծրագրավորման տեխնոլոգիայի նպատակը. Ծրագրավորման տեխնոլոգիայի զարգացման պատմությունը. Ծրագրային նախագծերի տեսակները. Ծրագրավորման տեխնոլոգիայի բաղադրիչներ. Նախագիծ, արտադրանք, գործընթաց և մարդիկ

2. Ծրագրի կյանքի ցիկլը. Զարգացման ցիկլային բնույթը. Ծրագրավորման տեխնոլոգիայի հիմնական հասկացությունները. Գործընթացներ և մոդելներ. Փուլեր և շրջադարձեր. Նշաններ և արտեֆակտներ: Շահագրգիռ կողմեր ​​և աշխատակիցներ.

3. Պահանջների բացահայտում և վերլուծություն: Ծրագրային ապահովման պահանջներ. Պահանջների մշակման սխեմա. Պահանջների կառավարում.

4. Ճարտարապետական ​​և մանրամասն ձևավորում. Իրականացում և կոդավորում: Փորձարկում և ստուգում. Որակի վերահսկման գործընթաց: Սպիտակ տուփի և սև տուփի մեթոդները. Ստուգում և վերանայում: Փորձարկման նպատակներ. Ստուգում, վավերացում և համակարգի փորձարկում: Պահպանում և շարունակական զարգացում:

5. Զարգացման գործընթացի մոդելներ. Ջրվեժի և կոնվեյերի մոդելներ. Պարույր և աճող մոդելներ: Զարգացման գործընթացի ճկուն մոդելներ:

6. Գործընթացի մոդելի նախագծում. Գործընթացի պահանջների նույնականացում: Օգտագործված փուլեր, նշաձողեր և արտեֆակտներ: Գործընթացի ճարտարապետության ընտրություն: Տիպիկ նախագծի իրականացման կարգը. փաստաթղթավորված ընթացակարգեր:

7. Զարգացման թիմի մոդելները. Զարգացման կոլեկտիվ բնույթը. Թիմի օպտիմալ չափը. Ծրագրի մասնակիցների ենթակայություն. Թիմի զարգացում և անձնակազմի զարգացում: Մասնագիտացում, համագործակցություն և փոխազդեցություն:

8. Զարգացման թիմի մոդելները. Հիերարխիկ թիմի մոդել. Վիրաբուժական թիմային մեթոդ. Հավասարների թիմի մոդել.

9. Ծրագրավորման բնույթը. Ծրագրավորման գիտություն. Ծրագրավորման արվեստ. Ծրագրավորման արհեստ. ծրագրավորման պարադիգմներ. Կառուցվածքային ծրագրավորում. Տրամաբանական ծրագրավորում. Օբյեկտ-կողմնորոշված ​​ծրագրավորում.

10. Ծրագրային ճարտարապետություն. Միջոցառումների կառավարում. Հաճախորդ/սերվերի ճարտարապետություն. Ծառայություններ. եռաշերտ ճարտարապետություն. Ծրագրի ձևավորում. Հայեցակարգային դիզայն. Տրամաբանական դիզայն. Մանրամասն դիզայն.

1. Նովիկովի մոտեցումները ծրագրային ապահովման մշակմանը» http://window. /window_catalog/files/r60368/itmo307.pdf.

2. Ծայրահեղ ծրագրավորում. - Սանկտ Պետերբուրգ: Պետեր, 2002 թ.

3. Ծրագրային ապահովման մշակման տեխնոլոգիա. - Սանկտ Պետերբուրգ. Պիտեր, 2004 թ.

4. Բրուքս կրտսեր. նախագծվել և ստեղծվել է ծրագրային համալիրներ. Մոսկվա: Նաուկա, 1975; նոր թարգմանական հրատարակություն՝ Առասպելական մարդ-ամիս։ Սանկտ Պետերբուրգ՝ SYMBOL+, 1999 թ.

5. Ալգորիթմներ + տվյալների կառուցվածքներ = ծրագրեր: Մ., Միր, 1978։

6. Համակարգված ծրագրավորում. Ներածություն. Մ.: Միր, 1977:

7. Կառուցվածքային ծրագրավորում. Մ.: Միր, 1975:

8. Ծրագրավորման կարգապահություն. Մ.: Միր, 1978:

9. Ծրագրային ապահովման մշակման տեխնոլոգիաներ. - Սանկտ Պետերբուրգ: Պետեր, 2002 թ.

10. Տերեխով ծրագրավորում. M.: BINOM, 2006 թ.

11. Rambo J. Ծրագրային ապահովման մշակման միասնական գործընթաց: Սանկտ Պետերբուրգ: Պետեր, 2002 թ.

Տնտեսական տեսություն մենեջերների համար

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

Տնտեսական տեսության դասընթաց. Դասագիրք համալսարանների համար / Ed. . -Կիրով. «ACA», 2004. Կոլեմաև - մաթեմատիկական մոդելավորում. Մակրոտնտեսական գործընթացների և համակարգերի մոդելավորում. Դասագիրք. Մ.: Միասնություն-ԴԱՆԱ, 2005. Բաժին կիբեռնետիկա. Խարկով. Հյուպատոս, 2004թ. Լեուշինի աշխատաժողով մաթեմատիկական մոդելավորման մեթոդների վերաբերյալ. դասագիրք: Նիժնի Նովգորոդի նահանգ տեխ. Համալսարան - Ն. Նովորոդ, 2007. Քաղաքական գործիչները տնտեսության մասին. Նոբելյան մրցանակակիրների դասախոսություններ տնտեսագիտության մեջ: Մոսկվա: Ժամանակակից տնտեսագիտություն և իրավունք, 2005 թ. Չերեմնիխ. Ընդլայնված մակարդակ. Դասագիրք.-M.:INFRA-M, 2008. Մինի-տնտեսության ինստիտուտների էվոլյուցիան. Ռուսաստանի գիտությունների ակադեմիայի Ուրալի մասնաճյուղի տնտեսագիտության ինստիտուտ, - Մ.: Նաուկա, 2007 թ.

Կառավարչական որոշումների մշակման և ընդունման տեխնոլոգիաներ [N]

Որոշումների կայացումը ղեկավարի գործունեության հիմքն է։ Որոշումների տեսության ներածություն. Որոշումների տեսության հիմնական հասկացությունները. Բիզնեսի կառավարման մոդելները և դրանց ազդեցությունը որոշումների կայացման վրա: Տարբեր ուղիներլուծումների դասակարգում. Դասակարգումներ՝ ըստ ձեւականության աստիճանի, ըստ առօրյայի աստիճանի, ըստ հաճախականության, ըստ հրատապության, ըստ նպատակներին հասնելու աստիճանի, ըստ այլընտրանքի ընտրության մեթոդի։ Որոշումների կայացման հիմնական մեթոդները. Որոշումների կայացման կամային մեթոդներ. Որոշումների կայացման նպատակներ. Ժամանակն է լուծումներ գտնել. Հիմնական սխալներ Որոշումների կայացման մաթեմատիկական մեթոդներ. Որոշումների կայացման տեսության մաթեմատիկական ասպեկտները. Գործառնությունների հետազոտություն. Մաթեմատիկական մոտեցում որոշումների կայացմանը: Որոշման ծառ. Մշակման և որոշումների կայացման մոդելներ: Խաղերի տեսություն. Որոշումների կայացման մաթեմատիկական մեթոդներ. Որոշումների կայացման տեսության մաթեմատիկական ասպեկտները. Հերթի տեսության մոդելներ. Պաշարների կառավարման մոդելներ. Գծային ծրագրավորման մոդել. տրանսպորտային առաջադրանքներ. Սիմուլյացիոն մոդելավորում. Ցանցի վերլուծություն. Տնտեսական վերլուծություն. Ռացիոնալ մոդելների սահմանափակումները. Խմբում զարգացման և որոշումների կայացման առանձնահատկությունները. Խմբերի համախմբվածության որոշման մեթոդ՝ հիմնված բազմությունների միացման աստիճանի վրա: Կոլեկտիվ որոշում կայացնելու մեթոդներ. կոնսենսուսի մեթոդ. քվեարկության մեթոդներ. Որոշումների կայացման ստեղծագործական մեթոդներ. Մտքերի փոթորիկ. Գաղափարների կոնֆերանս. Նավի խորհուրդ. Մտավոր գլխարկների մեթոդը դե Բոնոյի կողմից: Գյուտարարական խնդիրների լուծման տեսություն (TRIZ): Իդեալական վերջնական լուծում. Խնդիրների օրինակներ և դրանց լուծում՝ օգտագործելով TRIZ: ՏՐԻԶ մեթոդների կիրառումը յուրօրինակ և ստեղծագործ որոշումներ կայացնելիս։ Լուծման գաղափարներ մշակելու և իրավիճակին հարմարեցնելու մեթոդներ: Թիրախային ծառի մոդելը. Շահերի համակարգման ռազմավարություն. Շահերի համաձայնեցման վերաբերյալ որոշումների ձևավորում. Կողմերի շահերի որոշման մեթոդներ. Որոշումների աջակցման համակարգեր (փորձագիտական ​​համակարգեր): Որոշումների կայացման համակարգերի ստեղծման պատմությունը. Որոշումների կայացման համակարգերի դասակարգում. Փորձագիտական ​​համակարգի բնորոշ կառուցվածքը: Գիտելիքների ներկայացման ուղիները. Տրամաբանական եզրակացության մեթոդներ. Դիմում փորձագիտական ​​համակարգերպրակտիկայի վրա։

I. Որոշումների կայացման տեսություն՝ դասագիրք. - Մ.: Քննություն, 2006. - 573 էջ. I. Որոշումների կայացում. Կառավարման որոշումների մշակման տեսություն և մեթոդներ: Ուսուցողական. - M.: Մարտ, 2005. - 496 p. Կառավարման որոշման մշակում - M.: Delo Publishing House, 2004 - 392 p. Գ. Փորձագիտական ​​գնահատումներ և որոշումների կայացում - Մ .: Արտոնագիր, 1996. - 271 էջ. Տահա // Գործառնությունների հետազոտության ներածություն = Գործառնական հետազոտություն. ներածություն: - 7-րդ հրատ. - M.: «Williams», 2007. - S. 549-594. G. Theil. Տնտեսական կանխատեսումներ և որոշումների կայացում: M.: Progress, 1970. K. D. Lewis. Տնտեսական ցուցանիշների կանխատեսման մեթոդներ. Մ.: «Ֆինանսներ և վիճակագրություն», 1986. Գ. Ս. Կիլդիշև, Ա. Ա. Ֆրենկել: Ժամանակային շարքերի վերլուծություն և կանխատեսում: M.: «Վիճակագրություն» 1973. O. Kim, C. W. Muller, W. R. Klekka et al. Գործոն, տարբերակիչ և կլաստերային վերլուծություն: Մ.. «Ֆինանսներ և վիճակագրություն» 1989. Արդյունավետ մենեջեր. Գիրք 3. Որոշումների կայացում. - MIM LINK, 1999 Տուրևսկին և ավտոտրանսպորտային ձեռնարկության ղեկավարությունը: - Մ .: Բարձրագույն դպրոց, 2005 թ.,; խմբ. . Համակարգի վերլուծություն կառավարման մեջ. ուսուցողական. - Մ.: Ֆինանսներ և վիճակագրություն, 2006 թ., Տինկով: Դասագիրք: - M.: KNORUS, 2006:

Բիզնես գործընթացների մոդելավորում ինտեգրված կառավարման համակարգերում

Որո՞նք են բիզնես գործընթացների սկզբունքները: Ո՞րն է բիզնես գործընթացների ամբողջական նկարագրության խնդիրը: Ի՞նչ է համակարգը, ի՞նչ հատկություններ ունի այն: Համակարգային վերլուծության դերը բիզնես գործընթացների մոդելավորման մեջ: Գործընթացը որպես վերահսկողության օբյեկտ: Գործընթացի միջավայր. Բիզնես գործընթացի հիմնական տարրերը. Ֆունկցիոնալ և գործընթացների կառավարման առավելություններն ու թերությունները: PDCA կառավարման ցիկլ. Գործընթացի կառավարման ցիկլի փուլերը. PDCA ցիկլը և ISO 9001:2008 պահանջների իրականացումը: SADT մեթոդաբանություն (Structured Analysis and Design Technique - կառուցվածքային վերլուծության և նախագծման մեթոդ): Բնահյութ. Հիմնական դրույթներ. Ինչպե՞ս է ներկայացված գործունեության ֆունկցիոնալ մոդելը IDEF0 մեթոդաբանության մեջ: Ի՞նչ են նշանակում ֆունկցիոնալ մոդելի դիագրամների աշխատանքները, ինչպե՞ս են դրանք ցուցադրվում ըստ IDEF0 մեթոդաբանության։ Ինչի՞ համար են նախատեսված ֆունկցիոնալ մոդելի դիագրամների սլաքները, որո՞նք են դրանց տեսակներն ու տեսակները: DFD մեթոդաբանություն. Բնահյութ. DFD գծապատկերների հիմնական բաղադրիչները. Որո՞նք են DFD-դիագրամների առանձնահատկությունները, ի՞նչ է նկարագրված դրանցում: Որո՞նք են DFD դիագրամային օբյեկտների առանձնահատկությունները: Ի՞նչ են ներկայացնում DFD դիագրամի սլաքները: IDEF3 մեթոդաբանություն. Բնահյութ. Փաստաթղթավորման և մոդելավորման միջոցներ: Որո՞նք են IDEF3 դիագրամների առանձնահատկությունները, ի՞նչ են դրանք նկարագրում: Որո՞նք են IDEF3 դիագրամային օբյեկտների առանձնահատկությունները: Իսկ կրակողը. Գործընթացների դասակարգում. Բնորոշ բիզնես գործընթացներ. Վերաճարտարագիտությունը և դրա տեխնոլոգիան: Ե՞րբ է նպատակահարմար օգտագործել վերաճարտարագիտությունը ընկերության կառավարման մեջ: Գործընթացների մոնիտորինգ և չափում: Կազմակերպության գործընթացների ցուցանիշները. Գործընթացների թվային և վարկանիշային գնահատում:

«Modeling business processes with AllFusion Process Modeler (BPwin 4.1) Dialog-MEPhI» 2003 «Creating Information systems with AllFusion Modeling Suite» ed. «Dialogue-MEPhI» 2003 «Ֆունկցիոնալ մոդելավորման պրակտիկան AllFusion Process Modeler 4.1-ի հետ: (BPwin) Որտե՞ղ, ինչու՞, ինչպե՞ս: խմբ. «Dialogue-MEPhI» 2004 Դուբեյկովսկու մոդելավորում AllFusion Process Modeler-ով (BPwin): խմբ. "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "Methodology of structural analysis and design SADT" 1993 դասական աշխատանք SADT մեթոդաբանության վերաբերյալ: Չերեմնիխ համակարգերի վերլուծություն. IDEF-տեխնոլոգիաներ, համակարգերի մոդելավորում և վերլուծություն: IDEF տեխնոլոգիաներ. Արհեստանոց. Մ.: Ֆինանսներ և վիճակագրություն, 2001թ., «Կառուցվածքային բիզնես մոդելներ. DFD-տեխնոլոգիաներ» http://www. /Level4.asp? ItemId=5810 «Բիզնես գործընթացների վերակազմակերպման տեսություն և պրակտիկա» 2003թ./ P50.1.. Ֆունկցիոնալ մոդելավորման մեթոդիկա. Մոսկվա: Ռուսաստանի Գոստանդարտ, 2000: http://www. IDEF0, IDEF3, DFD http://www. Բիզնես գործընթացների մոդելավորում BPwin-ի միջոցով http://www. /department/se/devis/7/ IDEF0 բիզնես գործընթացների մոդելավորման կառավարման մեջ http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

Ծրագրային արտադրանքի արդյունավետության գնահատում

1. ՏՏ ճարտարապետություն

2. Կառավարման գործընթացների տիրույթներ.

3. Պլանավորման և կազմակերպման տիրույթի գործընթացների ցանկ

4. Դոմեյն գործընթացների ձեռքբերում և իրականացում

5. Գործառնությունների և սպասարկման տիրույթի գործընթացների ցանկ

6. Մոնիտորինգի և գնահատման տիրույթի գործընթացների ցանկ

7. Գործընթացի հասունության մոդելի մակարդակների բնութագրում

9. KPI և KGI իրենց հարաբերություններն ու նպատակը

1. 10. Ընդհանուր ՏՏ հսկողություն և կիրառական հսկողություն: Բիզնեսի և ՏՏ ոլորտի պատասխանատվության և պարտականությունների ոլորտները:

Cobit 4.1 ռուսերեն հրատարակություն.

Մտավոր սեփականության ստեղծման և օգտագործման իրավական կարգավորումը

1. Թվարկե՛ք մտավոր սեփականության իրավունքները մտավոր գործունեության արդյունքների նկատմամբ և բացահայտե՛ք դրանց բովանդակությունը:

2. Թվարկե՛ք բացառիկ իրավունքի տնօրինման պայմանագրերի տեսակները. Նկարագրեք այս պայմանագրերից յուրաքանչյուրը բացառիկ իրավունքի տնօրինման վերաբերյալ:

4. Նկարագրե՛ք Համակարգչային ծրագրի՝ որպես հեղինակային իրավունքի օբյեկտի իրավական պաշտպանության հիմնական դրույթները:

5. Համեմատեք Տվյալների բազայի իրավական պաշտպանության հիմնական դրույթները՝ որպես հեղինակային իրավունքի օբյեկտ և որպես հարակից իրավունքների օբյեկտ։

6. Նկարագրել արտոնագրային իրավունքների օբյեկտների՝ գյուտերի արտոնագրման պայմանները. օգտակար մոդելներ; արդյունաբերական նմուշներ.

7. Ընդլայնել գյուտի արտոնագրման չափանիշների բովանդակությունը. նորություն; գյուտարարական քայլ; արդյունաբերական կիրառելիություն.

8. Նկարագրեք գյուտի, օգտակար մոդելի կամ արդյունաբերական նմուշի արտոնագիր ստանալու պայմաններն ու կարգը, ինչպես նաև արտոնագրերի վավերականությունն ու տևողությունը ապահովող պայմանները:

9. Տրե՛ք «նոու-հաու»-ի սահմանում և թվարկե՛ք այն պայմանները, որոնց դեպքում առաջանում և իրականացվում է արտադրական գաղտնիքների իրավական պաշտպանությունը:

10. Թվարկե՛ք անհատականացման պաշտպանված միջոցները և տվեք դրանց համեմատական ​​բնութագրերը:

1., Մտավոր սեփականության իրավունքը Ռուսաստանի Դաշնություն, դասագիրք // Մ, Հեռանկար, 2007

2., Մտավոր սեփականության իրավունք, դասագիրք // Մ, ՌԻՈՐ, 2009

Ծրագրի կառավարում և ծրագրային ապահովման մշակում [R]

Ինչ է մեթոդաբանությունը, ինչու է դա անհրաժեշտ: Մեթոդաբանության ընդհանուր կառուցվածքը, մեթոդաբանության հիմնական տարրերը. Սեփական մեթոդաբանության նախագծման սկզբունքները. Տարբեր արտեֆակտների, դերերի, իրավասությունների, սահմանային պայմանների օրինակներ: Cowburn մեթոդաբանության կառուցվածքը, մեթոդաբանության չափումները: Cowburn նախագծի չափանիշները. Մեթոդաբանության ընտրության չափանիշներ, Cowburn մատրիցա. Ծրագրի կյանքի ցիկլը. Ջրվեժի և կյանքի ցիկլի կրկնվող մոդելներ: Կիրառելիության սահմանները ջրվեժի և կրկնվող մոդելների համար: RUP-ը որպես կրկնվող մեթոդաբանության օրինակ: Հիմնական RUP հասկացությունները, կիրառելիության սահմանները: Մարդու դերը ծրագրային ապահովման մշակման գործում. Արագաշարժ մեթոդոլոգիաներ, արագաշարժ մեթոդոլոգիաների հիմնական սկզբունքներ. Արագաշարժ մեթոդոլոգիաների ծագումը. Scrum-ը որպես արագաշարժ մեթոդաբանության օրինակ։ Դերեր, արտեֆակտներ, գործունեությունը Scrum-ում: Scrum-ի կիրառելիության սահմանները. Ծայրահեղ ծրագրավորում (XP) Գաղափարներ, արժեքներ, հիմնական պրակտիկա, կիրառելիության սահմաններ: Scrum-ի և XP-ի նմանություններն ու տարբերությունները: Պահանջների հավաքագրում և կառավարում: Հիմնական պրակտիկա, տերմիններ, սկզբունքներ: Նախագծի և արտադրանքի փաստաթղթավորման մոտեցումները, փաստաթղթերի հիմնական տեսակները: Դասընթացում քննարկված մեթոդաբանություններից պահանջների կառավարման պրակտիկայի օրինակներ: Ծրագրային ապահովման մշակման պլանավորում. Պլանների տեսակները, ռիսկերի կառավարումը, հանրաճանաչ ռիսկերը: Դասընթացում քննարկված մեթոդաբանություններից զարգացման պլանավորման պրակտիկայի օրինակներ: Թեստավորում ծրագրային ապահովման մշակման մեջ: Ծրագրային արտադրանքի հավաքման (կառուցման) հայեցակարգը: Հիմնական փորձարկման մեթոդներ, տերմիններ. Դասընթացում քննարկված մեթոդաբանություններից թեստավորման պրակտիկայի օրինակներ: Մոնտաժման (կառուցման) հայեցակարգը, կոդի պահպանման եղանակները, գործիքները։ Տարբերակային կառավարման համակարգի հետ աշխատանքի կազմակերպման երկու սկզբունք. Արտադրանքի թողարկման/դասավորության գործընթացի առանձնահատկությունները ապրանքների տարբեր կատեգորիաների համար, պրակտիկայի օրինակներ: Ծրագրային ճարտարապետության ժամանակակից հայեցակարգեր, բազմամակարդակ ճարտարապետություններ, ճարտարապետության չափանիշներ: Ցուցակ անհրաժեշտ որոշումներծրագրային ապահովման նախագծման ժամանակ, պահպանման համակարգի ընտրության մոտեցումները.

Քենթ Բեք - Ծայրահեղ ծրագրավորում Ֆրեդերիկ Բրուքս - Առասպելական մարդ-ամիս կամ ինչպես են ստեղծվել ծրագրային համակարգեր. Թոմ դե Մարկո - Վերջնաժամկետ: Վեպ նախագծերի կառավարման մասին։ Թոմ դե Մարկո, Թիմոթի Լիստեր - Վալս Արջերի հետ: Թոմ դե Մարկո, Թիմոթի Լիստեր - Մարդկային գործոնը_ հաջողված նախագծեր և թիմեր: Alistair Cowburn - Յուրաքանչյուր նախագիծ ունի իր մեթոդաբանությունը: Alistair Cowburn - Մարդիկ որպես ոչ գծային և ամենակարևոր բաղադրիչները ծրագրային ապահովման մշակման մեջ: Անդրեյ Օրլով - Ավտոմատի նշումներ. Մասնագիտական ​​խոստովանություն. Ֆիլիպ Կրախտեն - Ներածություն ռացիոնալ միասնական գործընթացին: Հենրիկ Կնիբերգ - Scrum և XP. նշումներ առաջին գծից: Դասընթացի դասախոսությունների ներկայացումներ

Ջրվեժի մոդելը Պահանջների վերլուծություն Դիզայն Իրականացում Ինտեգրման փորձարկում Արտադրանքի բնութագրերի նախագծում Արտադրանքի ճարտարապետության նախագծում Աղբյուրի կոդերի մշակում Աղբյուրի կոդերի մասերի ինտեգրում Փորձարկում և անսարքությունների վերացում

Ծրագրային ապահովման մշակման միասնական գործընթացի (USDP) Օգտագործման դեպքի մոդելը նկարագրում է այն դեպքերը, երբ հավելվածը կօգտագործվի: Վերլուծական մոդելը նկարագրում է կիրառման հիմնական դասերը: Դիզայնի մոդելը նկարագրում է կապերն ու հարաբերությունները դասերի և հատուկ օբյեկտների միջև, տեղակայման մոդելը նկարագրում է ծրագրային ապահովման բաշխումը համակարգիչների միջև: Իրականացման մոդելը նկարագրում է ներքին կազմակերպությունը ծրագրի կոդը. Փորձարկման մոդելը բաղկացած է փորձարկման բաղադրիչներից, փորձարկման ընթացակարգերից և տարբեր փորձարկման դեպքերից:

Տիպիկ ծրագրային արտադրանքի ճարտարապետության բաղադրիչներ և տիպիկ ծրագրային պահանջներ Ծրագրի կազմակերպում Հիմնական համակարգի դասեր Տվյալների կազմակերպում Բիզնեսի կանոններ Օգտագործողի միջերես Ռեսուրսների կառավարում Անվտանգություն Գործողություն ընդլայնելիություն Փոխազդեցություն այլ համակարգերի հետ (ինտեգրում) Միջազգայնացում, տեղայնացում Մուտքային-ելքային տվյալներ Սխալների մշակում

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

Ծրագրային արտադրանքի ճարտարապետության բնորոշ բաղադրիչները և տիպային ծրագրային պահանջները Մշակված ճարտարապետության ներդրման հնարավորությունները: Մշակված ճարտարապետության ներդրման հնարավորությունները. ավելորդ ֆունկցիոնալություն: ավելորդ ֆունկցիոնալություն: Պատրաստի ծրագրային բաղադրիչների գնման որոշում. Պատրաստի ծրագրային բաղադրիչների գնման որոշում. Փոխել ռազմավարությունը. Փոխել ռազմավարությունը.

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

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

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

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

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

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

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