Կասկադ մոդելի նազ. Ավտոմատացված տեղեկատվական համակարգերի կյանքի ցիկլը (LC AIS): AIS կյանքի ցիկլի մոդելներ. Տեղեկատվական համակարգի կյանքի ցիկլի փուլերը

3.1 AIS-ի կյանքի ցիկլի մոդելի սահմանում

մոդելի տակ կյանքի ցիկլԾրագրային արտադրանքի մշակումը հասկացվում է որպես կառույց, որը որոշում է կատարման հաջորդականությունը և գործընթացների, գործողությունների և առաջադրանքների փոխհարաբերությունները, որոնք կատարվել են ծրագրային արտադրանքի մշակման կյանքի ցիկլի ընթացքում: Ծրագրային արտադրանքի մշակման կյանքի ցիկլի հետևյալ մոդելները առավել լայնորեն կիրառվում են (Աղյուսակ 1. Համառոտ բնութագրեր AIS կյանքի ցիկլի մոդելներ՝ ջրվեժի մոդել կամ ջրվեժ (ջրվեժի մոդել); v-shaped մոդելը (v-shaped model); նախատիպային մոդել (նախատիպի մոդել); հավելվածների մշակման արագ մոդել, կամ RAD-մոդել (RAD-արագ հավելվածի մշակման մոդել); պարույր մոդել.

Աղյուսակ 1. Թվարկված մոդելներից յուրաքանչյուրի համառոտ բնութագրերը

Անուն	բնութագրերը
Կասկադ մոդել	Ուղղակի և հեշտ օգտագործման համար: Աշխատանքի առաջընթացի նկատմամբ մշտական ​​խիստ վերահսկողություն է անհրաժեշտ։ Մշակված ծրագրակազմը հասանելի չէ փոփոխության համար
v-ձևավորված մոդել	Հեշտ է օգտագործել. Շեշտը դրվում է թեստավորման և փորձարկման և նախագծման փուլերի արդյունքների համեմատության վրա
Նախատիպային մոդել	Համակարգի «արագ» մասնակի ներդրում է ստեղծվում մինչև վերջնական պահանջների ձևավորումը։ Տրամադրված է Հետադարձ կապօգտատերերի և մշակողների միջև նախագծի ընթացքում: Օգտագործված պահանջները ամբողջական չեն
Դիմումների արագ զարգացման մոդել	Ծրագրի թիմերփոքր (3 ... 7 հոգի) և կազմված են բարձր որակավորում ունեցող մասնագետներից։ Զարգացման ցիկլի ժամանակի կրճատում (մինչև 3 ամիս) և բարելավված կատարողականություն: Կոդի վերաօգտագործում և մշակման գործընթացի ավտոմատացում
Multi-pass մոդել	Արագ ստեղծվում է աշխատանքային համակարգ։ Նվազեցնում է զարգացման գործընթացում փոփոխություններ կատարելու հնարավորությունը: Ներկայիս իրականացումից նոր տարբերակի տեղափոխումը հնարավոր չէ մինչ ընթացիկ մասնակի իրականացումը կառուցվում է
պարույր մոդել	Ծածկում է ջրվեժի մոդելը: Ֆազերը բաժանում է փոքր մասերի: Թույլ է տալիս ճկուն դիզայն: Վերլուծում և կառավարում է ռիսկերը: Օգտագործողները նախատիպերի շնորհիվ ծանոթանում են ծրագրային արտադրանքի հետ ավելի վաղ փուլում

3.2 Կասկադ մոդել

Միատարր վիճակում տեղեկատվական համակարգեր 1970-ականների և 1980-ականների ընթացքում կիրառական ծրագրային արտադրանքները մեկ միավոր էին: Այս տեսակի ծրագրային արտադրանք մշակելու համար օգտագործվել է կասկադային մոդել կամ «ջրվեժ»:

Ծրագրային արտադրանքի կասկադային մոդելը նման է ավտոմատացված կառավարման համակարգի մոդելին (տե՛ս Գլուխ 1, Նկար 1):

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

3.3 V-մոդել

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

Ջրվեժի մոդելից v-աձեւ մոդելը ժառանգել է հաջորդական կառուցվածք, ըստ որի յուրաքանչյուր հաջորդ փուլ սկսվում է միայն նախորդ փուլի հաջող ավարտից հետո։

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

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

Մոդելը ներառում է հետևյալ փուլերը.

Ծրագրի պահանջների մշակում և պլանավորում. որոշվում են համակարգի պահանջները և իրականացվում է աշխատանքի պլանավորում.

Արտադրանքի պահանջների պատրաստում և դրանց վերլուծություն - կազմվում է ծրագրային արտադրանքի պահանջների ամբողջական ճշգրտում.

Բարձր մակարդակի դիզայն - կառուցվածքը սահմանված է ծրագրային ապահովում, դրա հիմնական բաղադրիչների և նրանց կողմից իրականացվող գործառույթների միջև կապը.

Մանրամասն դիզայն - որոշվում է յուրաքանչյուր բաղադրիչի շահագործման ալգորիթմը.

Կոդավորում - կատարվում է ալգորիթմների փոխակերպումը պատրաստի ծրագրակազմի;

Միավորի փորձարկում - ծրագրային արտադրանքի յուրաքանչյուր բաղադրիչ կամ մոդուլ փորձարկվում է.

Ինտեգրման թեստավորում - իրականացվում է ծրագրային արտադրանքի ինտեգրում և դրա փորձարկում;

Համակարգի փորձարկում - ծրագրային ապահովման արտադրանքի շահագործումը ստուգվում է այն բանից հետո, երբ այն տեղադրվում է ապարատային միջավայրում՝ պահանջների ճշգրտմանը համապատասխան.

Շահագործում և սպասարկում - ծրագրային արտադրանքի արտադրություն: Այս փուլում ծրագրային ապահովման արտադրանքը կարող է փոփոխվել և արդիականացվել:

Նկ.5 V-աձև մոդել

V- ձևավորված մոդելի առավելությունները.

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

2) ենթադրվում է ոչ միայն բուն ծրագրային արտադրանքի, այլ նաև ստացված բոլոր ներքին և արտաքին տվյալների ատեստավորում և ստուգում.

3) Աշխատանքի առաջընթացը կարելի է հեշտությամբ հետևել, քանի որ յուրաքանչյուր փուլի ավարտը կարևոր իրադարձություն է:

Բացի այս առավելություններից, մոդելն ունի նաև մի շարք թերություններ.

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

Այս մոդելը նպատակահարմար է օգտագործել ծրագրային ապահովման արտադրանքի մշակման ժամանակ, որի հիմնական պահանջը բարձր հուսալիությունն է։

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

Համակարգեր. Հիմնական նորմատիվ փաստաթղթեր, որը կարգավորում է ցանկացած IS և ՏՏ նախագծի ստեղծման գործընթացը, հանդիսանում են ԳՕՍՏ-ները և դրանց համալիրները ստեղծման և փաստաթղթավորումինֆորմացիոն տեխնոլոգիա, ավտոմատացված համակարգեր, ծրագրային ապահովման, կազմակերպման և տվյալների մշակման, ինչպես նաև Ռուսաստանի Պետական ​​տեխնիկական հանձնաժողովի կառավարման փաստաթղթերը ծրագրային ապահովման մշակման, արտադրության և շահագործման և ...

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

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

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

AIS կյանքի ցիկլի մոդելը ներառում է.

Աշխատանքի արդյունքները յուրաքանչյուր փուլում;

Հիմնական իրադարձությունները կամ ավարտի կետերը և որոշումների կայացումը:

Համաձայն ծրագրային ապահովման կյանքի ցիկլի հայտնի մոդելների, որոշվում են AIS կյանքի ցիկլի մոդելները. կասկադ, կրկնվող, պարույր:

I. Կասկադ մոդելնկարագրում է դասական մոտեցումը համակարգերի զարգացմանը ցանկացած առարկայական ոլորտներում. լայնորեն կիրառվել է 1970-80-ական թթ.

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

Հատկացնել հինգկայուն զարգացման փուլեր՝ գործնականում անկախ առարկայական ոլորտից

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

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

Երրորդփուլ - ծրագրի իրականացում; ըստ էության՝ ծրագրային ապահովման մշակում (կոդավորում)՝ նախորդ փուլի նախագծային որոշումներին համապատասխան։ Իրականացման մեթոդները հիմնարար նշանակություն չունեն։ Բեմի արդյունքը պատրաստի ծրագրային արտադրանք է:

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

Վերջին քայլը հանձնվելն է ավարտված նախագիծ, և այստեղ գլխավորը հաճախորդին համոզելն է, որ նրա բոլոր պահանջները լիովին բավարարված են։

Նկար 1.1 AIS LC կասկադ մոդել

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

Ջրվեժի մոդելի առավելությունները.

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

2) աշխատանքի փուլերի հաջորդական կատարումը թույլ է տալիս պլանավորել ավարտի ժամկետները և համապատասխան ծախսերը:

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

Ջրվեժի մոդելի թերությունները.

Արդյունքների ստացման զգալի ուշացում;

Սխալներն ու թերությունները ցանկացած փուլի դեպքում, որպես կանոն, հայտնվում են աշխատանքի հետագա փուլերում, ինչը հանգեցնում է վերադարձի անհրաժեշտության.

Ծրագրի վրա զուգահեռ աշխատանքի բարդությունը;

Յուրաքանչյուր փուլի չափազանց տեղեկատվական ծանրաբեռնվածություն;

Ծրագրի կառավարման բարդությունը;

Ռիսկի բարձր մակարդակ և ներդրումների անվստահելիություն:

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

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

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

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

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

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

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

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

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

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

II. Կրկնվող մոդել (Բեմական մոդել՝ միջանկյալ հսկողությամբ) պլանավորման, իրականացման, ուսումնասիրության, գործողությունների կարճ ցիկլերի (քայլերի) շարք է։

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

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

Թերություններկրկնվող մոդել.

· Յուրաքանչյուր փուլի ժամկետը ձգվում է աշխատանքի ողջ ժամանակահատվածի համար.

· կրկնությունների մեծ քանակի պատճառով նախագծային որոշումների և փաստաթղթերի կատարման մեջ առկա են անհամապատասխանություններ.

ճարտարապետության բարդությունները

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

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

Յուրաքանչյուր կրկնություն զարգացման ամբողջական ցիկլ է, որը հանգեցնում է արտադրանքի ներքին կամ արտաքին տարբերակի (կամ վերջնական արտադրանքի ենթաբազմության) թողարկմանը, որը բարելավվում է կրկնությունից մինչև կրկնություն՝ դառնալով ամբողջական համակարգ (Նկար 1.2):

Բրինձ. 1.2. AIS-ի կյանքի ցիկլի պարուրաձև մոդել

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

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

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

Առավելություններըկրկնվող մոտեցում.

Կրկնվող զարգացումը զգալիորեն հեշտացնում է նախագծում փոփոխությունների ներմուծումը հաճախորդի պահանջները փոխելու ժամանակ.

Պարույրային մոդելն օգտագործելիս AIS-ի առանձին տարրերը աստիճանաբար ինտեգրվում են մեկ ամբողջության մեջ: Քանի որ ինտեգրումը սկսվում է ավելի քիչ տարրերից, դրա իրականացման ընթացքում շատ ավելի քիչ խնդիրներ կան.

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

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

Կրկնվող մոտեցումը հեշտացնում է բաղադրիչների կրկնակի օգտագործումը, քանի որ շատ ավելի հեշտ է բացահայտել (նույնականացնել) նախագծի ընդհանուր մասերը, երբ դրանք արդեն մասամբ մշակված են, քան փորձել մեկուսացնել դրանք նախագծի հենց սկզբում: Դիզայնի վերլուծությունը մի քանի նախնական կրկնություններից հետո բացահայտում է սովորական բազմակի օգտագործման բաղադրիչներ, որոնք կբարելավվեն հետագա կրկնումներում.

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

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

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

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

Կյանքի ցիկլի մոդելը և դիզայնի տեխնոլոգիան

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

առաջադրանքները, կատարված աշխատանքների կազմը և հաջորդականությունը.

· յուրաքանչյուր կատարված գործողության արդյունքները.

Աշխատանքի կատարման համար անհրաժեշտ մեթոդներ և միջոցներ.

մասնակիցների դերերն ու պարտականությունները.

այլ տեղեկություններ, որոնք անհրաժեշտ են ՄՍ-ի հավաքական զարգացման պլանավորման, կազմակերպման և կառավարման համար,

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

Դիզայնի փուլերը և փուլերը

Դիզայնի «փուլ» և «փուլ» հասկացությունները հաճախ շփոթվում են: Երբեմն խոսում են փուլերըկամ փուլերըկյանքի ցիկլ, քայլերըդիզայն. Հարց է առաջանում՝ ո՞րն է ճիշտ ճանապարհը։

Պետք է հիշել, որ տարբեր միջազգային չափանիշներինՕգտագործված տերմինաբանությունը կարող է տարբեր լինել: Հնարավորության դեպքում մենք կկենտրոնանանք ներքին ԳՕՍՏ-ների տերմինաբանության վրա: Դիզայնի փուլմենք կանվանենք IS-ի ստեղծման գործընթացի այն մասը, որը սահմանափակվում է որոշակի ժամկետով և ավարտվում է որոշակի արտադրանքի թողարկումով (մոդել, փաստաթղթեր, ծրագրի տեքստ և այլն):Ըստ նպատակների ընդհանրության՝ նախագծման փուլերը կարելի է համատեղել փուլերը. Օրինակ՝ «Տեխնիկական նախագծման» փուլը, «Իրականացման» փուլը եւ այլն։

Հրապարակված տվյալների համաձայն՝ AIS-ի մշակման յուրաքանչյուր փուլ որոշակի ժամանակ է պահանջում։ Ժամանակի մեծ մասը (45-50%) ծախսվում է կոդավորման, բարդ և ինքնուրույն թեստավորման վրա: Միջին հաշվով, AIS-ի զարգացումը զբաղեցնում է համակարգի ողջ կյանքի ցիկլի մեկ երրորդը:

Բրինձ. Ժամանակի բաշխում AIS-ի զարգացման մեջ

AIS-ի ստեղծման փուլերը (ISO/IEC 15288)

ISO/IEC 12207 ստանդարտը սահմանում է կյանքի ցիկլի շրջանակ, որը պարունակում է գործընթացները, գործողությունները և առաջադրանքները, որոնք պետք է կատարվեն տեղեկատվական համակարգի ստեղծման ժամանակ:

AIS-ը, որպես կանոն, գոյություն ունի երկար ժամանակ՝ հաջորդաբար անցնելով դրանց զարգացման համակցված զարգացման մի քանի փուլ: կյանքի ցիկլ(LC) համակարգեր.

1) կազմակերպության նախանախագծային հետազոտություն (կամ վերլուծություն).

2) AIS դիզայն,

3) AIS-ի ներդրում.

4) AIS-ի ներդրում.

5) գործունեությունը (շահագործումը, օգտագործումը)

6) ԱԻԾ ուղեկցորդ.

7) ԱԻՍ նախագծի արդիականացում.

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

Հարկ է նշել, որ AIS-ը տեղեկատվության արտադրության արտադրանք է, ինչպես որ մեքենան մեքենաշինական արտադրության արտադրանք է, նրբերշիկը սննդի արտադրության արտադրանք է և այլն, հետևաբար, AIS-ի կյանքի ցիկլի փուլերը 1-ից 5-ը նման են ցանկացած ապրանքի կյանքի ցիկլի փուլերին.

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

AIS-ի ֆիզիկական վատթարացումն այն է, որ չկարողանա բավարարել կազմակերպության պահանջները AIS-ի համար՝ համակարգի բաղադրիչների խափանման, ձախողման կամ ձախողման պատճառով:

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

Եթե ​​ձեր կազմակերպությունը պատասխանատու և համակողմանի մոտեցավ ավտոմատացմանը, համապատասխանաբար կազմակերպեց բոլոր փուլերն ու փուլերը, ապա. AIS-ի կյանքի ցիկլը սահմանափակում է միայն ձեր կազմակերպության կյանքի տևողությունը, ինչը նշանակում է, որ AIS-ի վրա ծախսված միջոցները չեն նետվի աղբարկղը ֆիզիկապես կամ բարոյապես հնացած AIS-ի հետ միասին:

AIS-ի կյանքի ցիկլի բոլոր փուլերը թվարկված են վերևում, բայց դրանցից մի քանիսը զուգահեռ են ընթանում, ուստի դրանք հատկացնում են միայն AIS-ի կյանքի ցիկլի 5 փուլ(նկ.35):

առաջին փուլում» Նախանախագծային հարցում» (նկ. 33) ընդունված է առանձնացնել երկու հիմնական ենթափուլ և մեկ լրացուցիչ ենթափուլ.

1.1. դիրիժորություն նախանախագծային հարցումև հետազոտության նյութերի հավաքագրում;

1.2. հետազոտության նյութերի վերլուծություն և մշակում` հիմնված տեխնիկատնտեսական հիմնավորման (FS) և տեխնիկական առաջադրանքների (TOR) վերլուծության վրա.

1.3. համակարգի հայեցակարգի տարբերակի ընտրություն և մշակում:

Նախանախագծային հետազոտության փուլի նպատակները հետևյալն են.

· ձևակերպել նոր AIS-ի կարիքները, այսինքն. բացահայտել առկա IS-ի բոլոր թերությունները.

· ընտրել ուղղությունը և որոշել AIS-ի նախագծման տնտեսական նպատակահարմարությունը:

Հարցումների աշխատանքը սկսվում է առաջնային պահանջների վերլուծությամբ և աշխատանքի պլանավորման միջոցով, որը տևում է 2 օրից մինչև 4 շաբաթ: Այնուհետև իրականացվում է ձեռնարկության հետազոտությունը (հարցման տևողությունը 1-2 շաբաթ է):

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

Որոշվում է ձեռնարկությունում օգտագործվող ավտոմատացման միջոցների ցանկը:

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

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

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

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

Ավտոմատացման օբյեկտի մանրամասն ուսումնասիրություն;

Պահանջվող հետազոտական ​​աշխատանք (R&D)՝ կապված ուղիների որոնման և օգտագործողների պահանջների իրականացման հնարավորության գնահատման հետ.

Ստեղծված AIS-ի հայեցակարգի այլընտրանքային տարբերակների մշակում և դրանց իրականացման պլաններ.

Դասարան անհրաժեշտ ռեսուրսներդրանց իրականացման և շահագործման համար.

Յուրաքանչյուր տարբերակի առավելությունների և թերությունների գնահատում;

Օգտագործողի պահանջների և առաջարկվող համակարգի բնութագրերի համեմատություն և ընտրություն լավագույն տարբերակը;

Համակարգի ընդունման որակի և պայմանների գնահատման կարգի որոշում.

Համակարգից ստացված էֆեկտների գնահատում;

Կատարված աշխատանքի նկարագրությունը պարունակող հաշվետվության կազմում.

Համակարգի հայեցակարգի առաջարկվող տարբերակի նկարագրությունը և հիմնավորումը:

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

Փաստորեն, այս փուլում պատասխան է տրվում «Ի՞նչ պետք է անի ապագա համակարգը» հարցին։ Հենց այստեղ է ամբողջ ավտոմատացման նախագծի հաջողության բանալին: Խոշոր ծրագրային համակարգերի ստեղծման պրակտիկայում կան անհաջող իրականացման բազմաթիվ օրինակներ հենց համակարգի պահանջների ոչ ամբողջականության և մշուշոտ սահմանման պատճառով:

Այս փուլում որոշվում են հետևյալը.

§ համակարգի ճարտարապետությունը, նրա գործառույթները, նրա գործունեության արտաքին պայմանները, գործառույթների բաշխումը ապարատային և ծրագրային մասերի միջև.

§ ինտերֆեյսներ և գործառույթների բաշխում անձի և համակարգի միջև.

§ համակարգի ծրագրային և տեղեկատվական բաղադրիչներին ներկայացվող պահանջները, անհրաժեշտ ապարատային ռեսուրսները, տվյալների բազայի պահանջները, համակարգի բաղադրիչների ֆիզիկական բնութագրերը, դրանց միջերեսները.

§ համակարգի հետ կապված մարդկանց և աշխատատեղերի կազմը.

§ զարգացման գործընթացի սահմանափակումներ (առանձին փուլերի ավարտման հրահանգի ժամկետներ, առկա ռեսուրսներ);

§ կազմակերպչական ընթացակարգեր, որոնք ապահովում են տեղեկատվության պաշտպանությունը.

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

Կառուցվածքային ստորաբաժանումների գործունեության շրջանակներում ֆունկցիոնալ առաջադրանքների կազմի, կառուցվածքի և բնութագրերի որոշում.

Խնդիրների լուծման տեխնոլոգիայի ավտոմատացման ծրագրաշարի կազմի և կառուցվածքի որոշում՝ հաշվի առնելով առկա գործիքները կառուցվածքային ստորաբաժանումներ;

Տեղեկատվական աջակցության տեխնոլոգիայի կառուցվածքի և բնութագրերի որոշում խնդիրների լուծման համար.

Տեխնիկական լուծումների մշակում տեղեկատվական աջակցության կառուցման համար (տրամաբանական տվյալների բազայի կառուցվածքներ, դասակարգիչ կառույցներ);

§ ավտոմատացված աշխատանքային պրոցեդուրաների կազմի մշակում.

Համակարգային նախագիծպետք է ներառի.

ապագա համակարգի պահանջների ամբողջական ֆունկցիոնալ մոդել;

Մեկնաբանություններ ֆունկցիոնալ մոդելի վերաբերյալ (ցածր մակարդակի գործընթացի բնութագրերը տեքստային ձևով);

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

· Ինտեգրված տվյալների բազայի հայեցակարգային մոդել (դիագրամների փաթեթ);

համակարգի ճարտարապետություն՝ հայեցակարգային մոդելին հղումով.

· Համակարգին աջակցելու կազմակերպչական կառուցվածքի առաջարկներ.

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

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

Նկարագրեք, «տեսեք» և ուղղեք ապագա համակարգը՝ նախքան այն ֆիզիկապես կիրառվելը.

Նվազեցնել համակարգի մշակման և ներդրման ծախսերը.

Գնահատել զարգացումը ժամանակի և արդյունքների առումով.

Աշխատանքի բոլոր մասնակիցների միջև (հաճախորդներ, օգտվողներ, մշակողներ, ծրագրավորողներ և այլն) փոխըմբռնման հասնել;

Բարելավել մշակված համակարգի որակը, այն է՝ ստեղծել ինտեգրված տվյալների բազայի օպտիմալ կառուցվածք, կատարել բնորոշ մոդուլների ֆունկցիոնալ տարրալուծում:

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

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

Առանց ձեռնարկության ղեկավարության կողմից նման աջակցության, ընդհանրապես անիմաստ է նախագիծ սկսել:

Նկար 33. Աշխատանքի հաջորդականությունը AIS-ի կյանքի ցիկլի նախանախագծային փուլում:

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

Որպես TOR-ի ձևավորման մաս, ավտոմատացման առաջարկները մշակվում են բացահայտված և համաձայնեցված պահանջների հիման վրա, որոնք ներառում են.

Ձեռնարկության ավտոմատացված աշխատատեղերի և դրանց միջև փոխգործակցության ուղիների ցուցակի կազմում.

Գործող ձեռնարկությունների կառավարման համակարգերի (հիմնականում MRP և ERP դասեր) կիրառելիության վերլուծություն՝ պահանջվող խնդիրները լուծելու և նման համակարգ ընտրելու վերաբերյալ առաջարկությունների ձևավորման համար.

Հաճախորդի հետ համատեղ որոշումների կայացում ընտրելով կոնկրետ ձեռնարկության կառավարման համակարգ կամ զարգացրեք ձեր սեփականըհամակարգեր.

Տեխնիկական միջոցների առաջարկների մշակում;

Ծրագրային առաջարկների մշակում;

Տեղական ցանցի տոպոլոգիայի, կազմի և կառուցվածքի մշակում;

Ավտոմատացման փուլերի և ժամկետների վերաբերյալ առաջարկների մշակում.

Եթե ​​որոշվել է ընտրել կոնկրետ կառավարման համակարգ, ապա որոշ քայլեր բաց են թողնվում։

Երկրորդ փուլ» Դիզայն» (նկ. 34) կատարում է հետևյալ ենթակետերը.

1) նախնական նախագիծ՝ ՏԿ պահանջների հստակեցում, նախնական նախագծի կատարում և հաստատում.

2) տեխնիկական նախագծում՝ նախագծային լուծումների ընտրություն AIS-ի մշակման բոլոր ասպեկտների համար, AIS-ի բոլոր բաղադրիչների նկարագրություն, տեխնիկական նախագծի իրականացում և հաստատում.

3) մանրամասն նախագծում. ծրագրերի մաթեմատիկական մեթոդների և ալգորիթմների ընտրություն և մշակում, տվյալների բազաների կառուցվածքի ճշգրտում (DB), ծրագրային ապահովման արտադրանքի մատակարարման և մշակման համար փաստաթղթերի ստեղծում, AIS սարքավորումների հավաքածուի ընտրություն, փաստաթղթերի ստեղծում. սարքավորումների մատակարարում և տեղադրում, AIS-ի աշխատանքային նախագծի մշակում:

Այս փուլի նպատակներն են.

· Մշակել AIS-ի ֆունկցիոնալ ճարտարապետություն, որն արտացոլում է ֆունկցիոնալ ենթահամակարգերի կառուցվածքը և կազմը, կազմակերպության կառավարման որոշակի գործառույթների ավտոմատացված աջակցության համար.

· մշակել ընտրված AIS տարբերակի համակարգի ճարտարապետությունը, այսինքն՝ օժանդակ ենթահամակարգերի կազմը:

Բարդ խոշոր AIS-ի համար, ավտոմատացում խոշոր ձեռնարկություն, պահում, մարմիններ պետական ​​իշխանությունև այլն, ենթակետում 1" Նախնական նախագիծ» ձևակերպվում են նախնական լուծումներ ապագա ՀՏՀ-ի և դրա բաղադրիչների համար, որոնց արդյունքում նախնական նախագիծ(ՊԸ): Համակարգի և դրա մասերի նախնական նախագծային լուծումների մշակումը ներառում է.

AIS ֆունկցիայի սահմանում;

Ենթահամակարգերի գործառույթի սահմանում, դրանց նպատակներն ու ազդեցությունները.

Առաջադրանքների համալիրների և անհատական ​​առաջադրանքների կազմի որոշում.

Տեղեկատվական բազայի հայեցակարգի սահմանում, դրա ընդլայնված կառուցվածքը.

Տվյալների բազայի կառավարման համակարգի գործառույթների սահմանում;

Համակարգչային համակարգի կազմի որոշում;

Հիմնական ծրագրային գործիքների գործառույթի և պարամետրերի սահմանում:

Ծրագրի այս մասի համար փաստաթղթերի մշակում:

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

2-րդ ենթակետում. Ինժեներական դիզայն » աշխատել տրամաբանական զարգացման և ընտրության վրա լավագույն տարբերակներընախագծային որոշումներ, որոնց արդյունքում ստեղծվում է տեխնիկական նախագիծ (TP): Տեխնիկական նախագծի ստեղծման շրջանակներում իրականացվում է հետևյալը.

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

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

- տեխնիկական նախագծային աշխատանքներ:

Համակարգի և դրա մասերի ընդհանուր լուծումների մշակում,

Ֆունկցիոնալ-ալգորիթմական ընդհանուր լուծումների մշակում համակարգի կառուցվածքը,

անձնակազմի գործառույթների և կազմակերպչական կառուցվածքի վերաբերյալ ընդհանուր որոշումների մշակում,

Տեխնիկական միջոցների կառուցվածքի ընդհանուր լուծումների մշակում,

Խնդիրների լուծման ալգորիթմների և օգտագործվող լեզուների ընդհանուր լուծումների մշակում,

Տեղեկատվական բազայի կազմակերպման և պահպանման ընդհանուր լուծումների մշակում,

Տեղեկատվության դասակարգման և կոդավորման համակարգի ընդհանուր լուծումների մշակում,

Ընդհանուր ծրագրային լուծումների մշակում;

Իրականացնել նախագծի բոլոր մասերի, ներառյալ փաստաթղթի, փաստաթղթերի մշակումը, կատարումը «Խնդիրի ձևակերպում».,

AIS-ի և (կամ) ձեռքբերման համար ապրանքների մատակարարման համար փաստաթղթերի մշակում և կատարում տեխնիկական պահանջներ(տեխնիկական բնութագրեր) դրանց մշակման համար.

Ավտոմատացման օբյեկտի նախագծի հարակից մասերում նախագծային առաջադրանքների մշակում.

Ենթափուլ 3». Աշխատանքային դիզայն » կապված ընտրված նախագծի տարբերակի ֆիզիկական իրականացման և մանրամասն նախագծային փաստաթղթերի (ՊՏ) ստացման հետ:

Այս ենթափուլն իրականացվում է.

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

Համակարգի ծրագրերի և ծրագրային գործիքների մշակում, ինչպես նաև գնված ծրագրային գործիքների ընտրություն, հարմարեցում և (կամ) կապում,

Ծրագրային փաստաթղթերի մշակում:

AIS բաղադրիչների (ծրագրային ապահովման և սարքավորումների, ծրագրային ապահովման և ապարատային համակարգերի, տեղեկատվական արտադրանքների) մատակարարման մրցույթների կազմակերպում.

Նկար 34. Աշխատանքի հաջորդականությունը AIS-ի կյանքի ցիկլի նախագծման փուլում:

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

Երրորդ փուլ Իրականացում» (նկ. 35) համակարգի ֆիզիկական ձևավորումն է հետևյալ հաջորդականությամբ.

1) տեխնիկական միջոցների ստացում և տեղադրում.

2) ծրագրերի կոդավորում, փորձարկում և մշակում.

3) ծրագրային ապահովման ձեռքբերում և տեղադրում.

4) տեղեկատվական աջակցության ստեղծում, ներառյալ տվյալների բազաների լրացում.

5) ծրագրային ապահովման և սարքավորումների շահագործման հրահանգների մշակում, ինչպես նաև աշխատանքի նկարագրություններըանձնակազմի համար։

Այդ աշխատանքները գործնականում կարող են իրականացվել զուգահեռաբար։

AIS-ի կյանքի ցիկլի չորրորդ փուլում» Իրականացում» Կան հետևյալ ենթակետերը.

1) փորձնական իրականացում.

տեխնիկական սարքավորումների շահագործման հանձնում,

ծրագրային գործիքների գործարկումը, բոլոր բաղադրիչների և համակարգերի փորձնական շահագործումն ամբողջությամբ,

· անձնակազմի վերապատրաստում և ատեստավորում:

Փորձնական իրականացումբաղկացած է նախագծի տարրերի և մոդուլների գործունակության ստուգումից, տարրերի մակարդակում սխալների վերացումից և դրանց միջև եղած կապերից:

Այս փուլում աշխատանքներ են տարվում կազմակերպչական ուսուցում AIS-ը շահագործման հանձնելու ավտոմատացման օբյեկտ, ներառյալ.

AIS-ի կազմակերպչական կառուցվածքի վերաբերյալ նախագծային որոշումների իրականացում.

Վերահսկիչ օբյեկտի ստորաբաժանումներին ուսուցողական և մեթոդական նյութերով ապահովում.

Տեղեկատվության դասակարգիչների ներդրում;

Ուսուցում,

Ստուգում է AIS-ի գործունեությունը ապահովելու նրա կարողությունը:

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

Կատարել AIS-ի փորձարկումներ կատարման և տեխնիկական առաջադրանքների հետ կապված՝ նախապես պատրաստված նախնական թեստերի ծրագրին և մեթոդաբանությանը համապատասխան.

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

Փորձնական իրականացման աշխատանքներն ավարտվում են փորձնական գործողության ավարտի մասին ակտի կազմում.

2) արդյունաբերական իրականացում (առևտրային շահագործման հանձնում).

շահագործման հանձնում,

Աշխատանքների ընդունման և հանձնման ակտերի ստորագրում.

Շահագործման հանձնումներառում է ծրագրի ստուգման կազմակերպումը գործառույթների մակարդակով և վերահսկում է դրա պահանջներին համապատասխանությունը, որոնք ձևակերպվել են նախածրագրային հետազոտության փուլում, այսինքն.

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

AIS թեստի արդյունքների վերլուծություն և թեստերի ընթացքում հայտնաբերված թերությունների վերացում:

Ավարտելով աշխատանքը AIS-ի մշտական ​​շահագործման ընդունման մասին ակտի կազմում.

AIS-ի կյանքի ցիկլի վերջին հինգերորդ փուլում, շահագործում, սպասարկում և արդիականացումծրագրային ապահովում, սարքաշար և ամբողջ նախագիծը:

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

Հետերաշխիքային սպասարկումը բաղկացած է.

Համակարգի գործունեության վերլուծության աշխատանքների իրականացման ժամանակ.

AIS-ի փաստացի գործառնական բնութագրերի նախագծային արժեքներից շեղումները հայտնաբերելիս.

Այս շեղումների պատճառները պարզելիս.

Հայտնաբերված թերությունները վերացնելու և ԱԻՀ-ի գործառնական բնութագրերի կայունության ապահովման գործում.

AIS-ի փաստաթղթերում անհրաժեշտ փոփոխություններ կատարելիս:

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

Նկար 35. AIS-ի կյանքի ցիկլի փուլերը:

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

Ամենատարածվածը կյանքի ցիկլի երեք մոդելներ.

կասկադային մոդել (մինչև 70-ական թվականները) - հաջորդական անցում դեպի հաջորդ փուլ նախորդի ավարտից հետո.

· կրկնվող մոդել (70-ական - 80-ական թթ.) - հաջորդ փուլի ավարտից հետո նախորդ փուլերին կրկնվող վերադարձով.

· պարուրաձև մոդել (80-90-ական թթ.) - նախատիպ մոդել, որը ենթադրում է AIS-ի նախատիպի աստիճանական ընդլայնում:

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

Կրկնվող կյանքի ցիկլի մոդել. Համալիր AIS-ի ստեղծումը ենթադրում է անհատական ​​առաջադրանքների իրականացման ընթացքում ձեռք բերված նախագծային լուծումների միացում: «Ներքևից վեր» նախագծման մոտեցումը պահանջում է նման կրկնվող վերադարձներ, երբ առանձին առաջադրանքների նախագծային լուծումները լրացվում են ընդհանուր համակարգային լուծումների մեջ, և միևնույն ժամանակ անհրաժեշտություն է առաջանում վերանայել նախկինում ձևակերպված պահանջները: Որպես կանոն, մեծ թվով կրկնությունների պատճառով անհամապատասխանություններ են առաջանում ավարտված նախագծային որոշումներում և փաստաթղթերում: Ֆունկցիոնալ և համակարգի ճարտարապետություն AIS-ի կողմից ստեղծված նախագծային փաստաթղթերի օգտագործման դժվարությունը առաջացնում է ամբողջ համակարգի վերանախագծման անհրաժեշտությունը իրականացման և շահագործման փուլերում: Տեղեկատվական համակարգի մշակման երկար կյանքի ցիկլը ավարտվում է ներդրման փուլով, որին հաջորդում է նոր AIS-ի ստեղծման կյանքի ցիկլը:

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

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

Կյանքի ցիկլի պարուրաձև մոդելը հիմնված է նախատիպի տեխնոլոգիայի կամ RAD տեխնոլոգիայի (կիրառման արագ զարգացում) օգտագործման վրա։

Համաձայն այս տեխնոլոգիայի՝ AIS-ը մշակվում է ծրագրային ապահովման նախատիպերի ընդլայնմամբ՝ հետևելով պահանջների ճշգրտումից մինչև ծրագրի կոդի հստակեցում:

Բնականաբար, նախատիպի տեխնոլոգիայով կրկնությունների քանակը կրճատվում է, և ավելի քիչ սխալներ և անհամապատասխանություններ կան, որոնք պետք է շտկվեն հետագա կրկնումներում, և դիզայնն ինքնին իրականացվում է ավելի արագ տեմպերով, և պարզեցվում է նախագծային փաստաթղթերի ստեղծումը: AIS-ի կողմից մշակված նախագծային փաստաթղթերին ավելի ճշգրիտ համապատասխանելու համար ավելի ու ավելի մեծ նշանակություն է տրվում համակարգային պահեստի պահպանմանը և դիզայնի ավտոմատացմանը, մասնավորապես՝ CASE (Computers Aids System Engineering) տեխնոլոգիաների կիրառմանը:

Պարույր մոդելն օգտագործելիս.

· առկա է նախագծային լուծումների, նախագծման գործիքների, մոդելների և նախատիպերի կուտակում և վերօգտագործում AIS-ի և տեղեկատվական տեխնոլոգիաների.

· Կողմնորոշում է իրականացվում համակարգի և տեխնոլոգիաների մշակման և փոփոխման ուղղությամբ դրանց նախագծման գործընթացում.

· Համակարգի նախագծման գործընթացում իրականացվում է ռիսկերի և ծախսերի վերլուծություն:

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

Նախատիպ - համակարգի նվազագույն տարբերակը, որն օգտագործվում է ամբողջական տարբերակը ստեղծելու կամ մշակելու համար

Պահեստը պարունակում է տեղեկատվություն նախագծված AIS-ի օբյեկտների և նրանց միջև փոխհարաբերությունների մասին, բոլոր ենթահամակարգերը դրա հետ փոխանակում են տվյալներ:

AIS կյանքի ցիկլի մոդելներ -Կառուցվածք, որը սահմանում է գործընթացների, գործողությունների, առաջադրանքների հաջորդական իրականացումը կյանքի ցիկլի ընթացքում և այդ գործընթացների միջև փոխհարաբերությունները:

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

Ծրագրի փուլերը ըստ ջրվեժի մոդելի.

1. Պահանջների ձևավորում;

2. Դիզայն;

3. Զարգացում;

4. Փորձարկում;

5. Ներածություն;

6. Շահագործում և սպասարկում:

Առավելությունները:

-Լրիվ և համաձայնեցված փաստաթղթեր յուրաքանչյուր փուլում.

- Աշխատանքի հաջորդականության սահմանում;

- Թույլ է տալիս հստակ պլանավորել ժամանակն ու ծախսերը:

Թերություններ:

-Պատրաստի արդյունքների ձեռքբերման զգալի ուշացում;

- Հետագա փուլերում հայտնաբերվում են ցանկացած փուլի սխալները, ինչը հանգեցնում է նախագծային փաստաթղթերի վերադարձի և վերագրանցման անհրաժեշտության.

- Ծրագրի կառավարման դժվարություն:

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

Յուրաքանչյուր կրկնություն - ավարտված զարգացման ցիկլեր AIS-ի 1-ին տարբերակի տեսքով:

Կրկնման քայլեր.

1.Պահանջների ձևավորում

3. Դիզայն

4. Զարգացում

5. Ինտեգրում

Յուրաքանչյուր կրկնության ժամանակ գնահատվում են հետևյալը.

Ծրագրի պայմանները և արժեքը գերազանցելու ռիսկը.

Մեկ այլ կրկնություն կատարելու անհրաժեշտություն;

Համակարգի պահանջները հասկանալու ամբողջականության և ճշգրտության աստիճանը.

Նախագծի դադարեցման նպատակահարմարությունը.

Առավելությունները:

- Պարզեցնում է նախագծում փոփոխություններ կատարելու գործընթացը.

- Ապահովում է ավելի մեծ ճկունություն ծրագրի կառավարման մեջ;

- Հուսալի և կայուն համակարգ ձեռք բերելու հնարավորությունը, քանի որ սխալներ և անհամապատասխանություններ հայտնաբերվում են յուրաքանչյուր կրկնության ժամանակ.

- Հաճախորդի ազդեցությունը աշխատանքի վրա յուրաքանչյուր կրկնության ստուգման գործընթացում:

Թերություններ:

-Պլանավորման բարդություն;

- ինտենսիվ աշխատանքի ռեժիմ մշակողների համար;

-Աշխատանքների պլանավորումը հիմնված է փորձի վրա, և յուրաքանչյուր տարբերակի որակը չափելու համար բավարար չափումներ չկան:

AIS-ի նախագծման, մշակման և սպասարկման տեխնոլոգիայի պահանջները

Դիզայնի տեխնոլոգիա- սահմանում է երեք բաղադրիչների համադրություն.

- քայլ առ քայլ ընթացակարգ, որը որոշում է տեխնոլոգիական նախագծման գործողությունների հաջորդականությունը.

- տեխնոլոգիական գործողությունների արդյունքների գնահատման համար օգտագործվող կանոններ.

- նախագծային մշակումների ներկայացում փորձաքննության և հաստատման համար:

Տեխնոլոգիական հրահանգներ, որոնք կազմում են տեխնոլոգիայի հիմնական բովանդակությունը, պետք է բաղկացած լինեն տեխնոլոգիական գործողությունների հաջորդականության նկարագրությունից, պայմաններից՝ կախված նրանից, թե որից է կատարվում այս կամ այն ​​գործողությունը, և բուն գործողությունների նկարագրությունները։

IS նախագծման, մշակման և պահպանման տեխնոլոգիան պետք է համապատասխանի հետևյալին ընդհանուր պահանջներ:

Տեխնոլոգիան պետք է ապահովի ծրագրային ապահովման ողջ կյանքի ցիկլը.

Տեխնոլոգիան պետք է ապահովի ՏՏ զարգացման նպատակների երաշխավորված իրագործումը տվյալ որակով և սահմանված ժամկետում.

Տեխնոլոգիան պետք է ապահովի փոքր խմբերով (3-7 հոգի) առանձին ենթահամակարգերի նախագծման աշխատանքների իրականացման հնարավորություն։ Դա պայմանավորված է թիմի կառավարելիության և արտադրողականության բարձրացման սկզբունքներով` նվազագույնի հասցնելով արտաքին կապերի քանակը;

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

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

- դիզայնի ստանդարտ;

- նախագծային փաստաթղթերի նախագծման ստանդարտ.

- օգտագործողի միջերեսի ստանդարտ:

Զարգացման պահանջ

- Ծրագրային ապահովման ստեղծման աշխատանքների կատարում;

AIS-ի ներդրման նախապատրաստում;

Ծրագրի հիմնական ցուցանիշների վերահսկում, փորձարկում.

Ուղեկցող պահանջներ

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

ԱՊՀ-ի պահպանման գործընթացում խնդիր է դրված պահպանել դրա կենսունակությունը։ ԱՊՀ-ի կենսունակությունը մեծապես պայմանավորված է նրանով, թե որքանով է այն համապատասխանում բուհի իրական խնդիրներին և կարիքներին, որոնք փոխվում են ԱՊՀ-ի կյանքի ցիկլի ընթացքում։

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

1. Ավտոմատացված տեղեկատվական համակարգերի ճարտարապետությունը և դրա կատարելագործման խնդիրները 13

1.1. Ճարտարապետության մոդելները և AIS 13-ի հիմնական բաղադրիչները

1.2. AIS-ի զարգացման խնդիրներ 47

1.3. AIS UP 53-ի նոր ճարտարապետության ներդրման հարթակներ

1.4. Գլուխ 1 Եզրակացություններ 57

2. AIS UE ճարտարապետության մոդել 58

2.1. AIS UP 59-ի հիմնական պահանջները

2.2. Ճարտարապետություն AIS UP 66

2.3. AIS UP 89 բաղադրիչ

2.4. Գլուխ 2 Եզրակացություններ 102

3. AIS UE-ի գործնական իրականացման մեթոդներ 104

3.1. Գործիքներ AIS UP 104-ի մշակում

3.2. AIS UP 111 մոդելի գործնական ներդրման փորձ

3.3. Գլուխ 3 Եզրակացություններ 123

4. Եզրակացություն 125

5. Տերմինաբանություն և հապավումներ 128

6. Գրականություն

Աշխատանքի ներածություն

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

Անցած 40 տարիների ընթացքում ավտոմատացված տեղեկատվական տեխնոլոգիաները (ՏՏ) ակտիվորեն օգտագործվել են հաշվապահական հաշվառման, պլանավորման և վերլուծության խնդիրները լուծելու համար։ տնտեսական գործունեությունսեփականության տարբեր ձևերի ձեռնարկություններ, արդյունաբերության պատկանելություն, կազմակերպչական կառուցվածքըև գործունեության մասշտաբը։ Այս ընթացքում կուտակվել է մեծ գործնական փորձ ձեռնարկությունների կառավարման ավտոմատացված տեղեկատվական համակարգերի ստեղծման գործում (AIS UE), մշակվել և համընդհանուր ճանաչում են ստացել կառավարման մեթոդոլոգիաներ, որոնց կիրառումն անհնար է համակարգչային միջավայրից դուրս։ Ամբողջ պատասխանատվությամբ կարելի է փաստել, որ AIS UE-ն դարձել է բիզնես ենթակառուցվածքի անբաժանելի մասը։ Տնտեսական գործընթացների ավտոմատացման տեսական և գործնական խնդիրները խորապես ուսումնասիրված են Գլուշկով Վ.Մ., Վոլկով Ս.Ի., Իսակով Վ.Ի., Օստրովսկի Օ.Մ., Պոդոլսկի Վ.Ի., Ռատմիրով Յու.Ա., Ռոմանով Ա.Ն., Հոտյաշովա Է.Ն., Բրեդի Ռ. Cook M., Finkelstein K., Hammer M. և այլ հեղինակներ: Նրանց առաջարկած մոտեցումները հիմք հանդիսացան ձեռնարկություններում համակարգչային տեխնոլոգիաների կիրառման համար՝ ֆինանսական և տնտեսական գործունեության հաշվառման, պլանավորման և վերլուծության խնդիրների լուծման համար։ Այնուամենայնիվ

նրանց առաջարկած մոդելները հաշվի չեն առել տեղեկատվական հասարակության տնտեսության իրողությունները և ՏՏ զարգացման ներկա մակարդակը։

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

AIS UE կազմակերպության գոյություն ունեցող հայեցակարգերը հիմնված են նրա ենթահամակարգերի միջև առաջադրանքների բաշխման ֆունկցիոնալ մոտեցման վրա: Այնուամենայնիվ, AIS-ը, որը կառուցվել է որպես անհատական ​​կառավարման գործառույթների վրա կենտրոնացած ենթահամակարգերի համալիր, լավագույնս չի բավարարում ձեռնարկության վերջնական բիզնես գործընթացների շարունակականության պահանջը: Հետևաբար, վերջին տարիներին գնալով ավելի տարածված է դարձել այն մոտեցումը, որտեղ առաջնային պլան են մղվում բիզնես գործընթացները, այլ ոչ թե դրանք կատարող կառավարման համակարգի ծառայությունների առանձին գործառույթները: Զարգացման կարիք ունի նոր հայեցակարգ AIS UE ճարտարապետություն. Միևնույն ժամանակ, ակնհայտ է, որ անցումը նոր AIS UE ճարտարապետությանը չի կարող միանգամից իրականացվել, քանի որ տարիների ընթացքում ձեռնարկությունները և կազմակերպությունները գործի են դրել մեծ թվով ծրագրային գործիքներ, որոնք իրականացնում են կառավարման կարևոր խնդիրների լուծում: , որի օգտագործումը չի կարելի անմիջապես հրաժարվել։ Ցավոք, դրանց մեծ մասը կենտրոնացած է ինքնավար գործունեության վրա, ինչը զգալիորեն բարդացնում է տեղեկատվական հոսքերի համալիր ինտեգրումը: Շատ գոյություն ունեցող ծրագրային արտադրանքներ, որոնք աջակցություն են տրամադրում ձեռնարկությունների կառավարման նոր խնդիրների լուծմանը, որոնք առաջացել են տնտեսության գլոբալացման համատեքստում, նույնպես մշակվում են առանց ինտերֆեյսների բավարար մշակման՝ ծրագրային համակարգերի հետ փոխգործակցության համար, որոնք իրականացնում են հարակից խնդիրների լուծումը: Այս պայմաններում առանձնահատուկ կարևորություն ունի ձեռնարկությունների կառավարման ինտեգրված համակարգերի սինթեզումը` ինտեգրելով արդյունահանվող երրորդ կողմի բաղադրիչները, մաքսային լուծումները և ներքին մշակումները:

Տարբեր արտադրողների կողմից մատակարարվող ծրագրային գործիքների համար համակարգի ինտեգրման ստանդարտների ներդրման գաղափարը վաղուց քննարկվել է գիտնականների և պրակտիկանտների հրապարակումներում: Համակարգային գործիքների առաջընթացը հանգեցրել է օբյեկտի վրա հիմնված և բաղադրիչ ծրագրային ապահովման մշակման տեխնոլոգիաների առաջացմանը, որոնք թույլ են տալիս պատրաստի բլոկներից կառուցել լայնածավալ համակարգեր: Սարքավորումների և համակարգային ծրագրերի առաջատար մատակարարներ (Intel, Microsoft, Sun, Oracle, IBM և այլն), կապի գործիքներ (Cisco, Nortel, Ericsson, Motorola), կիրառական լուծումներ (SAP, PeopleSoft, Siebel և այլն), հեղինակավոր պետություն, միջազգային, կոմերցիոն և շահույթ չհետապնդող կազմակերպություններև ասոցիացիաները (ISO, IEEE, ASCII, APICS, RosStandard և այլն) մինչ այժմ մշակել և գործնականում ակտիվորեն կիրառում են սարքավորումների և ծրագրաշարերի ինտեգրման տեխնոլոգիաներ, որոնք թույլ են տալիս ստեղծել բաց համակարգեր՝ հիմնված տվյալների փոխանակման և բաղադրիչների փոխազդեցության համար ստանդարտների և արձանագրությունների վրա: իրական ժամանակի ռեժիմում տարասեռ միջավայր:

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

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

AIS PM-ի համակարգային ինտեգրման և ժամանակակից ՏՏ-ի վրա հիմնված միկրոտնտեսական գործընթացների վերջնական ավտոմատացման խնդիրների լուծմանն ուղղված ամբողջական մոտեցում մշակելու անհրաժեշտությունը որոշեց այս հետազոտության թեմայի և ուղղության ընտրությունը:

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

Ելնելով նախատեսված նպատակից՝ դրվել և լուծվել են հետևյալ գիտագործնական խնդիրները.

Վերլուծել և ընդհանրացնել AIS UP ծրագրային ապահովման նախագծման, մշակման և ներդրման առկա մոտեցումները.

Դասակարգել ձեռնարկությունների կառավարման պրակտիկայում օգտագործվող ծրագրային ապահովման տեսակները.

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

Բացահայտել խնդիրները, որոնք առաջանում են AIS UE-ում օգտագործվող ծրագրային գործիքների ինտեգրման ժամանակ.

Համակարգել ձեռնարկությունների կողմից AIS UE ծրագրային ապահովման համար սահմանված պահանջները՝ ապահովելու համար տեղեկատվական աջակցությունտնտեսական գործընթացների միջոցով;

Մշակել AIS UE ճարտարապետության մոդել և ընդգծել դրա հիմնական բաղադրիչները.

Մշակել AIS UE բաղադրիչների փոխազդեցության և տվյալների փոխանակման սկզբունքները.

Հետազոտության առարկան տնտեսական տեղեկատվական համակարգերի մշակման մեթոդներն ու գործիքներն են։

Ուսումնասիրության առարկան ձեռնարկությունների կառավարման ԻՍ-ն է:

Հետազոտության մեթոդաբանությունը հիմնված է գիտական ​​գիտելիքների մեթոդաբանության հատուկ կիրառությունների վրա ինֆորմատիկայի և մաթեմատիկայի կիրառական ոլորտներում:

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

Համակարգային տեսության վրա հիմնված ընդհանուր գիտական ​​մոտեցման հետ մեկտեղ ատենախոսությունն ամփոփում է հայրենական և արտասահմանյան արտադրողների ծրագրային գործիքների մշակման, ներդրման և շահագործման փորձը, մեթոդները.

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

Աշխատանքում օգտագործվում են հայրենական և արտասահմանյան հեղինակների աշխատությունների տեսական դրույթները.

Տնտեսական տեղեկատվության ավտոմատացված մշակում և տնտեսական գործընթացների մոդելավորում;

Արտադրության և պաշարների պլանավորման և գործառնական կառավարման մեթոդներ.

Բիզնես գործընթացների վերաճարտարագիտություն և համակարգչային ձևավորում;

Տեղեկատվական տեխնոլոգիաների ժամանակակից ստանդարտներ.

Ուսումնասիրության ընթացքում հետազոտական ​​թիմերի և անհատ գիտնականների կողմից կատարված զարգացումները Ռուսաստանի Դաշնության կառավարությանն առընթեր Ֆինանսական ակադեմիայում, Ֆինանսների և տնտեսագիտության համառուսաստանյան թղթակցային ինստիտուտում, Մոսկվայի պետական ​​համալսարանՏնտեսագիտություն, վիճակագրություն և ինֆորմատիկա, Սանկտ Պետերբուրգի տնտեսագիտության և ֆինանսների համալսարան. Վոզնեսենսկին, Հետազոտական ​​ֆինանսական ինստիտուտը և այլ կազմակերպություններ։

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

Ռուսաստանում և ԱՊՀ երկրներում ծրագրային ապահովման շուկայի հետազոտություն TSIES «Business-Programs-Service».

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

Գիտական ​​նորույթը պարունակում է ատենախոսությունում ստացված հետևյալ արդյունքները.

համար պահանջների սահմանում և դասակարգում ֆունկցիոնալությունըձեռնարկությունների կազմակերպչական և տնտեսական կառավարման ծրագրեր;

AIS UE ճարտարապետական ​​մոդելը կենտրոնացած է բիզնես գործընթացների վերջնական ավտոմատացման վրա.

Ձեռնարկության ֆունկցիոնալ ծառայությունների խնդիրները լուծելու համար ծրագրային գործիքների ինտեգրման սկզբունքները բիզնես գործընթացների կառավարման, տվյալների փոխանակման և փաստաթղթերի կառավարման հիմնական ծրագրակազմով.

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

վերլուծական գործիքների օգտագործմամբ հաշվետվությունների ձևավորման և դասակարգման միասնական համակարգի ներդրման առաջարկներ.

Օբյեկտ-կողմնորոշված ​​և բաղադրիչ տեխնոլոգիաների վրա հիմնված AIS UE ենթահամակարգերի փոխազդեցության իրականացման սկզբունքները և բաշխված ցանցում ծրագրային բաղադրիչների փոխազդեցությունը

արդյունաբերության ստանդարտներին և ինտերնետ արձանագրություններին համապատասխան միջավայր.

AIS UE ծրագրաշարի ճարտարապետական ​​մոդելի հարմարվողական հատկությունների ներդրման մեխանիզմը որոշակի ձեռնարկության պահանջներին համապատասխան՝ հիմնված հիմնական ենթահամակարգերը առկա և նախագծված աշխատանքային գործընթացներին կարգավորելու ունակության վրա:

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

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

Անկախ գործնական արժեք ունեն.

AIS UE-ի համակարգային ինտեգրման մեջ օգտագործվող ստանդարտների, արձանագրությունների և այլ մեխանիզմների ընտրության և կիրառման առաջարկներ.

Առաջարկներ համար ինտեգրված ավտոմատացումավարտից մինչև վերջ բիզնես գործընթացներ և աշխատանքային հոսք;

վեբ պորտալների մեխանիզմի օգտագործմամբ ձեռնարկության միասնական տեղեկատվական տարածք ստեղծելու առաջարկներ.

AIS UP ծրագրային ապահովման մշակման և ներդրման մեջ պարուրաձև կրկնվող մոտեցման հարմարեցման առաջարկներ:

Աշխատանքի գործնական նշանակությունը գնահատվել է ձեռնարկության ավտոմատացման համակարգի առաջարկվող խնդրին ուղղված մոդելի իրականացման կոնկրետ նախագծերում.

«Infosoft» ընկերության «Flagman» ձեռնարկությունների կառավարման ինտեգրված համակարգ,

eRelationship հաճախորդների հետ հարաբերությունների կառավարման համակարգեր Pivotal Software Corporation (Կանադա),

DataWatch ընկերության Monarch ES կորպորատիվ հաշվետվության համակարգեր (ԱՄՆ),

Sovintel և Tele Ross ընկերությունների տեղեկատվական համակարգերի ինտեգրման նախագիծը։

Vest-MetaTechnology ուսումնական կենտրոնը օգտագործում է նյութեր, որոնք պատրաստվել են հեղինակի կողմից՝ հիմնվելով այս հետազոտության ընթացքում առաջարկված մոտեցման վրա, ձեռնարկությունների կառավարման տեղեկատվական համակարգերի զարգացման դասընթացներ անցկացնելիս (տես http://www.vest.msk.ru):

Ատենախոսության հետազոտական ​​նյութերը օգտագործվում են հետազոտության մեջ և գործնական գործունեությունՏնտեսագիտության ծրագրային ապահովման մշակողների ասոցիացիայի (AREP) գործադիր մարմինները և նրա անդամները:

Աշխատանքի հիմնական դրույթները զեկուցվել և քննարկվել են.

Կոնֆերանս «IBM լուծումներ հեռահաղորդակցական ընկերությունների բիզնեսի ինտեգրման ոլորտում», IBM-ի ներկայացուցչություն Արևելյան Եվրոպայում (Մոսկվա, 18 հունիսի, 2002 թ.);

Սիմպոզիում «Call Center CRM Solutions 2002/Call Centers and Customer Relationship Management» (Մոսկվա, մարտ 2002 թ.);

Centura Software Corp կորպորացիայի գործիքների վրա հիմնված տեղեկատվական համակարգեր մշակողների կոնֆերանսներ: (Բեռլին, Գերմանիա, նոյեմբերի 17-19, 1999 թ.);

«InfoCity. քաղաքների տեղեկատվականացման պրակտիկա և հիմնախնդիրներ» կոնֆերանս (Մոսկվա, հոկտեմբեր 1999 թ.);

«Infosoft» ընկերության գիտական ​​և գործնական կոնֆերանսներ (Մոսկվա, 1995-1999 թթ.);

ACS և ԱՊՀ ոլորտի մասնագետների համաժողով» Ձեռնարկությունների համակարգեր«(Մոսկվա, 1998թ. ապրիլի և 1997թ. ապրիլի 28-30, կազմակերպիչներ. SoftService ընկերություն և Oracle, Informix, Sybase, Borland և Centura-ի ներկայացուցչություններ);

3-րդ տարեկան կոնֆերանս «Կորպորատիվ տվյալների բազաներ 98» (Մոսկվա, 1998թ. մարտի 31-ապրիլի 3, 1996թ. մարտի 26-29, կազմակերպված Տեղեկատվական տեխնոլոգիաների կենտրոնի կողմից Բաց համակարգերի հրատարակչության մասնակցությամբ);

«Տեխնիկոմ-97» կոնֆերանս (Մոսկվա, 1997թ. նոյեմբերի 24-26, կազմակերպիչներ՝ SoftService, Oracle-ի օգտագործողների ռուսական ասոցիացիա, Microsoft-ի, Borland-ի, Computer Associates, Lucent Software-ի ներկայացուցչություններ):

AIS-ի զարգացման խնդիրներ

Տեղեկատվական տեխնոլոգիաների ներդրումը տնտեսություն, համակարգչային և հաղորդակցման գործիքների ներթափանցումը ձեռնարկությունների կառավարման մեջ բոլոր մակարդակներում, ինտերնետի միջոցով ընկերությունների փոխգործակցության նկատմամբ աճող հետաքրքրությունը պահանջում են հայեցակարգային փոփոխություններ AIS UE-ի կառուցման մոտեցումներում: Սա վերաբերում է ոչ միայն IS-ի ստեղծման և շահագործման զուտ տեխնոլոգիական խնդիրներին, այլ նաև տեղեկատվական հասարակության տնտեսության մեջ բիզնեսի կառավարման մոտեցումներին:

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

Տարասեռ հավելվածների ինտեգրումը մեկ AIS-ի շրջանակներում պետք է ապահովի աջակցություն. մեկ օգտագործողի միջերես (պորտալ); ընդհանուր տեղեկատվական տարածք:

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

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

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

Այնուամենայնիվ, նույնիսկ եթե տվյալների բազայի կենտրոնական սերվերն ի վիճակի է ապահովելու պահանջվող կատարումը, նման IS կառուցվածքով, անխուսափելիորեն խնդիրներ են առաջանում միասնական տվյալների բազայի մեկ կառուցվածքի պահպանման հարցում, եթե IS-ի առանձին ծրագրային բաղադրիչները մշակվում են տարբեր ընկերությունների կամ նույնիսկ զարգացման թիմերի կողմից: նույն կազմակերպությունը։ Տարբեր կիրառական խնդիրների լուծման ծրագրերից հասանելի տվյալների բազայի տեղադրումը հնարավորություն է տալիս ապահովել ընդհանուր տեղեկատվական տարածք, վերը թվարկված տեխնոլոգիաները թույլ են տալիս մեծ թվով օգտվողների մուտք գործել տվյալների բազա, բայց դա չի երաշխավորում ճիշտ աշխատանք ընդհանուր տվյալների հետ: Մնում է տրամաբանական տվյալների ամբողջականության խնդիրը։ Տարբեր արտադրողների ծրագրեր օգտագործելիս անխուսափելի է դառնում տվյալների բաժանումը ենթահամակարգերի մեջ, հնարավոր է դրանք ապանորմալացնելով և ավելորդ կառուցվածքներ ստեղծելով: Սխեմատիկ ճարտարապետություն հետ ընդհանուր բազացույց է տրված հետևյալ նկարում (Նկար 1-14): Ինչպես երևում է վերը նշված գծապատկերից, մոդուլները չեն փոխազդում, այսինքն՝ իրական ժամանակում չկա զանգ մի մոդուլից մյուսին, չկա գործառնական աջակցություն վերջից մինչև վերջ գործընթացի համար: Տվյալները պահվում են տվյալների բազայում, որտեղից այն հասանելի է այլ մոդուլների համար, որոնք պետք է պարունակեն դրանում փոփոխություններին հետևելու գործառույթները, և տվյալների համապատասխանությունը կախված է թարմացումների ստուգման հաճախականությունից: Ավարտից մինչև վերջ գործընթացի օրինակ կարող է լինել վաճառքի բաժնի աշխատակցի կողմից հաշիվ-ապրանքագիրը: Եթե ​​դրա համար նա օգտագործում է CRM համակարգ, ապա գեներացված հաշիվ-ապրանքագիրը պետք է մշակվի ERP համակարգի լոգիստիկ մոդուլի քաղվածքին զուգահեռ՝ ապրանքները պահելու համար, իսկ դրանից անմիջապես հետո՝ ֆինանսական մոդուլում՝ գնորդի պարտքը մեծացնելու համար: Դա անելու համար համապատասխան մոդուլները պետք է ստուգեն նոր հաշվի առկայությունը։ Եթե ​​դա ժամանակին չկատարվի, ապա փաստացի պահված ապրանքի համար կարող է տրվել հաշիվ-ապրանքագիր:

Որպեսզի տարբեր մոդուլներ աշխատեն տվյալների բազայի ընդհանուր կառուցվածքի հետ, դրանք պետք է ի սկզբանե մշակվեն՝ նկատի ունենալով տվյալների որոշակի կառուցվածք կամ օգտագործեն համաձայնեցված մետատվյալների մեխանիզմ (պահեստ):

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

Նոր AIS UE ճարտարապետության ներդրման հարթակներ

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

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

համակարգված աջակցության ավտոմատացված միջոցներ համատեղ աշխատանքաշխատողների խմբեր («թիմեր») մեկ նախագծի, փաստաթղթի, առաջադրանքի և այլնի վրա.

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

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

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

Բաշխված տարասեռ միջավայրում աշխատելու համար, ինչպիսին է ինտերնետը, ակտիվորեն մշակվում են վեբ ծառայությունների բնութագրերը, որոնցից յուրաքանչյուրը կարող է իրականացնել մեկ կամ մի քանի բիզնես ընթացակարգեր կամ գործառույթներ (բիզնես ընթացակարգեր, գործառույթներ): OASIS-ը, BPMI-ն և IBM-ը, Microsoft-ը և BEA-ն հրապարակել են BPEL4WS (Business Process Execution Language Web Services-ի համար), XLANG և WSFL (Web Services Flow Language) աշխատանքային հոսքի կարգավորման առանձնահատկությունները և WfML կոալիցիան՝ XPDL (XML Process Definition Language) .

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

Նման ճարտարապետության իրականացման համար տեխնիկական խոչընդոտներ չկան։ Արդյունաբերական կիրառական ժամանակակից սերվերները (օրինակ, MTS / COM + / .Net, ONE կամ J2EE / EJB) թույլ են տալիս կառուցել բազմաշերտ համակարգեր, տրամադրել ընդհանուր հարթակ տարբեր վեբ ծառայություններ մուտք գործելու համար, ապահովել գործառնությունների գործարքային ամբողջականություն, բեռի հավասարակշռում: Տասնյակ հազարավոր օգտատերերի մրցակցային հասանելիությունը իրական ժամանակում, ինչպես նաև երաշխավորում է սխալների հանդուրժողականություն և վերականգնում ձախողումներից հետո:

ՏՏ ոլորտի կարևոր ձեռքբերումն այն ստանդարտներն են, որոնք լայնորեն տարածվել և ճանաչվել են ծրագրային ապահովման առաջատար արտադրողների կողմից՝ բաղադրիչների փոխազդեցության արձանագրությունները (COM/DCOM, CORBA, Java RMI) և տվյալների փոխանակման ձևաչափերը (EDI, XML,):

EDI ստանդարտը և դրա ոլորտին բնորոշ տարբերակները (EDIFACT, XI2, HIPAA և այլն) օգտագործվել են Հյուսիսային Ամերիկայի և Եվրոպայի ֆինանսական և արդյունաբերական հատվածներում 1970-ականների կեսերից և այսօր գերակշռում են ամբողջ աշխարհում: Ինտերնետում XML-ի աճող ժողովրդականության հետ մեկտեղ EDI-ն թարգմանվեց XML-ի:

XML-ի (DTD և XDR) հիման վրա տվյալները մշակվել, կառուցվածքավորվել և ձևաչափվել են տարբեր տնտեսական ոլորտներում, այսպես կոչված, առարկայական բառարանների կամ փաստաթղթերի տեսակների տեսքով, օրինակ՝ WIDL, OFX, FpML, IFX, XBRL, CRML: և շատ ուրիշներ Արևմուտքում, ինչպես նաև CommerceML.ru և XML Partnership/ARB Ռուսաստանում: Արտադրության և գույքագրման կառավարման ամերիկյան միությունը APICS, որը հավաստում է ERP / MRP դասի համակարգերը, հրապարակում է բնութագրերը տնտեսվարող սուբյեկտները XML ձևաչափով, օրինակ՝ հաճախորդի կամ ապրանքագրի տվյալների կառուցվածքը և ձևաչափը: Ինքնավաստագրվող XML-ը ապահովում է տվյալների միանշանակ ըմբռնում ինչպես մարդկանց, այնպես էլ ծրագրերի կողմից:

AIS UE ճարտարապետություն

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

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

Ձեռնարկության մասշտաբի պարամետրերը ազդում են որոշակի ձեռնարկության կառավարման կազմակերպման վրա, ինչը արտացոլված է AIS UE-ի պահանջներում: Մյուս կողմից, AIS UE-ն ազդում է ձեռնարկության մասշտաբի վրա, օրինակ՝ նպաստելով բիզնեսի աճին: Պարամետրերից մեկի փոփոխությունը ենթադրում է AIS-ի թարմացում այնպես, ինչպես AIS-ի ներդրումը կարող է փոխել կառավարման կազմակերպումը:

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

Որպես AIS PM-ի առանցք, անհրաժեշտ է մշակել մի համակարգ, որը համատեղում է գործընթացների կառավարման համակարգերի վերանայման ժամանակ քննարկված մի քանի գործառույթներ (պարբերություններ «1.1.7 Փաստաթղթերի կառավարման համակարգեր» էջ 31-ում և «1.1.8 Գործընթացների կառավարման համակարգեր» էջում։ 34): Դրանց թվում՝ Workflow - աշխատողների կառավարման ենթահամակարգ և տեխնոլոգիական գործընթացներ, որն ապահովում է կատարողների միջև առաջադրանքների կանխորոշված ​​և ազատ երթուղում. Docflow - փաստաթղթերի հոսքի կառավարման և փաստաթղթերի երթուղղման ենթահամակարգ՝ դրանց վիճակներին հետևելու միջոցով. Groupware - ենթահամակարգ, որն աջակցում է առաջադրանքների գործառնական նշանակման գործառույթներին և կատարողների խմբի անդամների միջև առաջադրանքների ազատ երթուղղմանը (ad hoc). Տվյալների հոսք - երթուղային տվյալներ, տվյալների փաթեթներ, հաղորդագրություններ հավելվածների միջև:

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

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

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

AIS UE մոդելի գործնական ներդրման փորձ

1995 թվականից մինչև 1999 թվականը թեզի հեղինակի ղեկավարությամբ մշակվել է Infosoft ընկերության Flagman ձեռնարկությունների կառավարման համակարգը, որը ներկայումս ներդրված է ավելի քան հարյուր խոշոր և միջին արդյունաբերական, շինարարական, առևտրային, գյուղատնտեսական ձեռնարկություններում և բյուջետային կազմակերպություններՌուսաստանը և ԱՊՀ երկրները. Համակարգը շարունակում է զարգանալ հեղինակի կողմից մշակված միջուկի հիման վրա, և մինչև 2002 թվականը «Flagship»-ը ներառում է ավելի քան տասը հիմնական ենթահամակարգեր, որոնք ներկայացված են հետևյալ նկարում (Նկար 3-2).

«Flagman» համակարգի հիմքը «Փաստաթղթերի կառավարում» հիմնական մոդուլն է, որը պատասխանատու է բոլոր առաջնային փաստաթղթերի մուտքագրման, մշակման, երթուղղման և տպագրության համար: Այլ հիմնական մոդուլներն են «Կառավարում» և «Գործիքներ», որոնք ընդհանուր են բոլոր ֆունկցիոնալ մոդուլների համար: Նրանք թույլ են տալիս կարգավորել դերերի խմբերը և մուտքի իրավունքները, աշխատանքային կայանները մինչև ընտրացանկի տարրերը, փաստաթղթերի դասավորությունը և հաշվետվությունների ձևանմուշները:

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

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

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

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

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

Նշենք նաև, որ Flagship համակարգը իրականացնում է միասնական տեսքըենթահամակարգեր։ Օգտվողի միջերեսի տարրերի, AWP գործառույթների, ներառյալ ընտրացանկերի և գործիքների տողերի ընդհանուր կառավարման մոդուլը թույլ է տալիս հարմարեցնել արտաքին տեսքը միատեսակ ձևով:

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

Այնուամենայնիվ, Flagman համակարգի հաջող ներդրման և կոմերցիոն գործունեության բազմաթիվ օրինակներ, 2001-2002 թվականներին դրա վաճառքների թվի աճը վկայում են. տնտեսական արդյունավետությունըլուծումներ գործունեության տարբեր ոլորտների, արդյունաբերության և մասշտաբների ձեռնարկությունների ավտոմատացման համար:

1999 թվականի փետրվարին Infosoft ընկերության Flagman համակարգը, որը ստեղծվել է հեղինակի ղեկավարությամբ, ճանաչվել է որպես լավագույն ռուսական մշակում, որը հիմնված է Centura Team Developer գործիքակազմի կողմից Centura Software Corp-ի կողմից: (ԱՄՆ) և «Ինտերֆեյս» ընկերությունը (Ռուսաստան): 1999, 2000 և 2001 թթ ԱՊՀ «Flagman»-ը հավաստագրվել է որպես ձեռնարկության տեղեկատվական համակարգ՝ «Business-Soft» մրցույթի ժյուրիի փորձագետների կողմից, որն անցկացվել է Տնտեսագիտության ոլորտում ծրագրային ապահովման մշակողների ասոցիացիայի (AREP), TSIES «Business Programs-Service»-ի կողմից։ », «Հաշվապահական հաշվառում» ամսագիրը և «Ֆինանսական թերթը»: