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

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

Բովանդակություն

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

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

  • Ծրագրային ապահովման ճկուն մշակում (Agile Software Development )
  • Բյուրեղյա մեթոդներ (Crystal Methods)
  • Դինամիկ համակարգերի մշակման մոդել (ԴՀՄՄ, DSDM: Dynamic Systems Development Model)
  • Ծայրահեղ ծրագրավորում (ԾԾ, XP: Extreme Programming)
  • Հնարավորությունների մշակում (ՀՄ, FDD: Feature Driven Development)
  • Կիրառական ծրագրերի համատեղ մշակում (ԿԾՀՄ, JAD: Joint Application Development)
  • Lean մշակում (ԼՄ, LD: Lean Development)
  • Կիրառական ծրագրերի արագ մշակում (ԿԾԱՄ, RAD: Rapid Application Development)
  • Նպատակահարմար միասնական գործընթաց (ՆՄԳ, RUP: Rational Unified Process)
  • Scrum
  • Պարույր (Գալարաձև, Spiral)
  • Համակարգերի մշակման կենսափուլ (ՀՄԿՓ, SDLC: Systems Development Life Cycle)
  • Ջրվեժ (նաև հայտնի է որպես ավանդական մեթոդաբանություն, Waterfall)

 

Ծրագրային ապահովման ճկուն մշակում մեթոդաբանություն (Agile Software Development Methodology)

Ծրագրային ապահովման ճկուն մշակումը (Agile software development )հայեցակարգային հիմք է ծրագրային ապահովման մշակման և կառավարման նախագծեր նախաձեռնելու համար: Առկա են ծրագրային ապահովման մշակման մի շարք ճկուն մեթոդաբանություններ, ինչպես օրինակ բյուրեղյա մեթոդներ (Crystal Methods), դինամիկ համակարգերի մշակման մոդել (ԴՀՄՄ, DSDM: Dynamic Systems Development Model) և Scrum:

 

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

 

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

 

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

 

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

 

Բյուրեղյա մեթոդներ մեթոդաբանություն (Crystal Methods Methodology)

Բյուրեղյա մեթոդների մոտեցումը մշակել է Էլիստեյր Քոքբրնը (Alistair Cockburn): Նրա ուշադրության կենտրոնում էին մարդիկ, փոխազդեցությունը, կոլեկտիվը, հմտությունները, տաղանդները և հաղորդակցումները` այն համոզմունքով, որ այս հանգամանքներն են առաջին հերթին ազդում կատարման վրա: Նա ասում էր նաև, որ գործընթացը կարևոր է, բայց երկրորդական է:

 

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

 

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

 

Քոքբրնը նաև տարբերակում է մեթոդաբանության, մեթոդների և քաղաքականութան միջև: Մեթոդաբանությունը տարրերի ամբողջություն է (փորձառություն, գործիքներ), մեթոդները (հնարքները) հմտության, կարողության շրջանակ է, ինչպես օրինակ օգտագործման դեպքերի (use cases) մշակումը, իսկ քաղաքականությունը թելադրում է կազմակերպչական «անհրաժեշտությունները»:

 

Դինամիկ համակարգերի մշակման մոդել մեթոդաբանություն (ԴՀՄՄ, DSDM: Dynamic Systems Development Model Methodology)

Դինամիկ համակարգերի մշակման մոդելը մշակվել է Մեծ Բրիտանիայի Միացյալ Թագավորությունում 1990-ականների կեսերին: Դա կիրառական ծրագրերի արագ մշակման (ԿԾԱՄ) փորձի զարգացումն է: Դինամիկ համակարգերի մշակման մոդելն օժտված է ծրագրային ապահովման ճկուն մշակման ցանկացած մեթոդի լավագույն աջակցությամբ վերապատրաստմամբ և փաստաթղթավորմամբ, առնվազն Եվրոպայում:

 

ԴՀՄՄ հարում է այն փիլիսոփայությունը, որ առաջին անգամ ոչինչ անթերի չի ստեղծվում, և ծրագրային ապահովման մշակումը դիտարկում է որպես հետազոտման նախաձեռնություն:

 

Դինամիկ համակարգերի մշակման մոդելի ինը սկզբունքներն են`

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

 

Ծայրահեղ ծրագրավորում մեթոդաբանություն (ԾԾ, XP: Extreme Programming Methodology)

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

 

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

 

ԾԾ հիմնական գործունեությունները

Ծայրահեղ ծրագրավորման հիմնական գործունեությունները (փորձառությունները), ինչպես նկարագրված է «Ծայրահեղ ծրագրավորումը մեկնաբանում է» (“Extreme Programming Explained” 1st edition) առաջին հրատարակությունում, կարելի է խմբավորել չորս ոլորտներում (12 գործունեություններ) հետևյալ կերպ`

 

Փոքր մասշտաբի հետադարձ կապ (Fine scale feedback)

  • Փորձարկման վրա հիմնված մշակում
  • Խաղի պլանավորում
  • Ամբողջ աշխատանքային խումբ
  • Զույգերով ծրագրավորում

 

Շարունակական գործընթաց, այլ ոչ թե փաթեթ

  • Շարունակական ինտեգրում
  • Նախագծման բարելավում
  • Փոքր թողարկումներ

 

Ընդհանուր փոխըմբռնում

  • Պարզ դիզայն
  • Համակարգի մոդել
  • Հավաքական կոդի սեփականության իրավունք
  • Կոդավորման չափորոշիչների կամ կոդավորման համաձայնություններ

 

Ծրագրավորողի բարեկեցություն

  • Կայուն արագություն (այսինքն շաբաթական քառասուն ժամ):

 

«Ծայրահեղ ծրագրավորումը մեկնաբանում է» (Extreme Programming Explained 2 nd edition) երկրորդ հրատարակությունում թվարկված են մի շարք հավելյալ գործունեություններ (փորձառություններ) ի լրումն վերը թվարկված հիմնական գործունեությունների:

Հիմնական գործունեությունները ծագում են ընդունված լավագույն փորձառություններից (գործելակարգից) և օգտագործվում են ծայրահեղ իրավիճակներում.

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

 

Կարծիք կա, որ ծայրահեղ ծրագրավորումը կարող էր միայն աշխատել փոքր աշխատանքային խմբերով` ոչ ավել, քան 12 մարդ: Սակայն ծայրահեղ ծրագրավորման մեթոդաբանությունը հաջողությամբ օգտագործվել է հարյուրից ավելի ծրագրավորողներից բաղկացած աշխատանքային խմբերի դեպքում:

 

Հնարավորությունների մշակում մեթոդաբանություն (ՀՄ, FDD: Feature Driven Development Methodology)

Ջեֆ դե Լուքա (Jeff De Luca) և Պիտեր Քոուդը (Peter Coad) երկուսն էլ մեծապես ներգրավված էին հնարավորությունների մշակում մեթոդաբանության (FDD: Feature Driven Development) մշակման գործընթացում: Հնարավորությունների մշակում մեթոդաբանությունը Պիտերը նկարագրում է որպես բավարար գործընթաց ունեցող մեթոդաբանություն` մասշտաբայնությունը և կրկնությունը ապահովելու համար` խրախուսելով ստեղծագործ և նորարար մոտեցումը:

 

Ավելի հստակ, հնարավորությունների մշակումը հավաստիացնում է, որ`

  • Համակարգերի ստեղծման համար անհրաժեշտ է մի համակարգ ավելի մեծ նախագծեր ծավալելու համար:
  • Պարզ, բայց լավ սահմանված գործընթացը պետք է հնարավորինս  լավ աշխատի:
  • Գործընթացի քայլերը պետք է լինեն տրամաբանական, իսկ դրանց արժեքը` ուղղակիորեն ակնհայտ աշխատանքային խմբի յուրաքանչյուր անդամի համար:
  • «Գործընթացի հպարտությունը» կարող է խոչընդոտել իրական աշխատանքի կատարմանը:
  • Բավարար գործընթացները տեղափոխվում են հետին պլան, որպեսզի աշխատանքային խմբի անդամները կարողանան կենտրոնանալ արդյունքների վրա:
  • Հնարավորությունների մշակման կարճ, կրկնվող, կենսափուլերը լավագույնն են:

 

Հնարավորությունների մշակում մեթոդաբանությունը շարունակում է անդրադառնալ վերը նշված կետերին ստորև բերված պարզ գործընթացի միջոցով (փակագծերում նշված թվերը ցույց են տալիս նախագծի վրա ծախսված ժամանակը).

  1. ընդհանուր մոդելի մշակում (10 տոկոս սկզբնական, 4 տոկոս գործող)
  2. հնարավորությունների ցանկի կազմում (4 տոկոս սկզբնական, 1 տոկոս գործող)
  3. ըստ հնարավորությունների պլանավորում (2 տոկոս սկզբնական, 2 տոկոս գործող)
  4. ըստ հնարավորությունների նախագծում
  5. ըստ հնարավորությունների ստեղծում (77 տոկոս նախագծման և ստեղծման համար համատեղ):

 

Կիրառական ծրագրերի համատեղ մշակում մեթոդաբանություն (ԿԾՀՄ, JAD: Joint Application Development Methodology)

Կիրառական ծրագրերի համատեղ մշակումը պահանջների սահմանման և օգտվողի ինտերֆեյսի (միջերեսի) նախագծման մեթոդաբանություն է, որտեղ վերջնական օգտվողները, իրականացնողները և ծրագրավորողները ինտենսիվ հաճախում են ընկերության սահմաններից դուրս տեղի ունեցող հանդիպումների` համակարգի մանրամասները մշակելու համար: Այսպիսով, կիրառական ծրագրերի համատեղ մշակման մեթոդաբանության նպատակն է ներգրավել պատվիրատուին կիրառական ծրագրերի նախագծման և մշակման գործընթացում: Ներգրավվման գործընթացը կատարվում է մի շարք համատեղ սեմինարների միջոցով, որոնք կոչվում են ԿԾՀՄ խորհրդակցություններ: IBM-ի երկու աշխատակիցներ, Չակ Մորիսը (Chuck Morris) և Թոնի Քրոուֆորդը (Tony Crawford), ԿԾՀՄ մեթոդաբանությունը մշակեցին 1970-ականների վերջերին և այս մոտեցման ուսուցման գործընթացը սկսեցին 1980-ականներին:

 

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

 

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

 

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

 

Ի հակադրություն ջրվեժ (Waterfall) մոտեցմանը, համարվում է, որ կիրառական ծրագրերի համատեղ մշակումը (ԿԾՀՄ) հանգեցնում է մշակման ավելի կարճ ժամանակահատվածների և պատվիրատուի առավել մեծ բավարարվածության` մշակման ամբողջ գործընթացում պատվիրատուի մշտական ներգրավվածության շնորհիվ:

 

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

 

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

 

Lean մշակում մեթոդաբանություն (ԼՄ, LD: Lean Development Methodology)

Lean մշակումը կենտրոնանում է փոփոխություն թույլատրող ծրագրային ապահովման ստեղծման վրա: Այս մեթոդաբանությունը միավորում է դինամիկ կայունության հասկացությունը (պատկերացումը), որը կարող է նման համարվել նրան, թե ինչպես է Scrum-ն ընդգրկում վերահսկելի քաոսը: Բոբ Չերիթը (Bob Charette), նախաձեռնողը, գրում է, որ Lean մշակման չափելի նպատակն է ստեղծել ծրագրային ապահովում մեկ երրորդը մարդու ջանքերի, մեկ երրորդը մշակման ժամերի և մեկ երրորդը ներդրումների միջոցով` համեմատած, թե ինչ կարող է նվաճել ԾԱՃԻ (Ծրագրային ապահովման ճարտարագիտության ինստիտուտ) կարողության հասունության մոդելի 3-րդ մակարդակի (CMM: Capability Maturity Model) կազմակերպությունը:

 

Առկա է Lean մշակման 12 սկզբունք.

  1. Պատվիրատուին, հաճախորդին բավարարելը գլխավոր առաջնահերթությունն է:
  2. Միշտ ապահովեք որակի և գնի լավագույն հարաբերակցությունը:
  3. Հաջողությունը կախված է պատվիրատուի, հաճախորդի ակտիվ մասնակցությունից:
  4. Յուրաքանչյուր Lean մշակման նախագիծ աշխատանքային խմբի կողմից գործադրած ջանքի արդյունք է:
  5. Ամեն ինչ փոփոխական է:
  6. Համակարգչային ցանցերում մեկ հանգույցով կառավարվող միջոցների խումբ ունենալը դեռ չի նշանակում լուծումներ ունենալ:
  7. Ավարտեք, ոչ թե կառուցեք:
  8. Լուծման 80 տոկոսն այսօր վաղվա 100 տոկոս լուծման փոխարեն:
  9. Մինիմալիզմը կարևորագույնն է:
  10. Պահանջները որոշում են տեխնիկական միջոցները:
  11. ՏՏ լուծման (ապրանքի) աճը հնարավորության աճ է, ոչ թե չափի աճ:
  12. Երբեք մի դուրս եկեք Lean մշակման սահմաններից:

 

Կիրառական ծրագրերի արագ մշակում մեթոդաբանություն (ԿԾԱՄ, RAD: Rapid Application Development Methodology)

«Արագ մշակման լեզուն» ընդհանուր տերմին է, որն առնչվում է ցանկացած ծրագրավորման լեզվին, որն առաջարկում է ավելի արագ իրագործում, քան երրորդ սերնդի ավանդական լեզուները, ինչպիսիք են օրինակ C/C + +, Պասկալ (Pascal) կամ Fortran: Արագ մշակման լեզուները (ԱՄԼ-րը) տնտեսում են նվազեցնելով կառուցվածքի չափը, որն անհրաժեշտ է ՏՏ լուծման (արտադրանքի) ստեղծման համար: Չնայած խնայողականությունները իրականացվում են ստեղծման ժամանակ, ստեղծման փուլը կրճատելու կարողությունն ազդում է ամբողջ նախագծի վրա` ստեղծման ավելի կարճ փուլերը ձևավորում են ավելացող կենսափուլեր, ինչպես օրինակ առաջխաղացման գործնական նախատիպերի ստեղծումը:

 

Քանի որ ԱՄԼ-ը հաճախ կարիք ունեն առաջնակարգ կատարման, սահմանափակում են ճկունությունը, և սահմանափակվում են որոշակի տեսակի խնդիրների, նրանք սովորաբար ավելի հարմար են ներքին բիզնես ծրագրային ապահովման և սահմանափակ-բաշխվածությամբ հատուկ ծրագրային ապահովման մշակման համար, քան համակարգերի ծրագրային ապահովման համար:

 

Կիրառական ծրագրերի արագ մշակման մեթոդաբանությունն առաջարկում է, որ ՏՏ լուծումները կարող են մշակվել ավելի արագ և ավելի բարձր որակի եթե իրականացվեն հետևյալ միջոցառումները`

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

Առկա են կոմերցիոն ՏՏ լուծումներ, որոնք ներառում են պահանջների հավաքագրման գործիքներ, նախատիպերի մշակման գործիքներ, ծրագրային ապահովման մշակման միջավայրեր, ինչպես օրինակ Java պլատֆորմի համար, աշխատանքային խմբի անդամների միջև հաղորդակցման համար ծրագրային ապահովում և փորձարկման գործիքներ: ԿԾԱՄ սովորաբար ընդգրկում է օբյեկտ-կողմնորոշված ծրագրավորման մեթոդաբանություն, որն ըստ էության նպաստում է ծրագրային ապահովման կրկին օգտագործմանը: Ամենահանրաճանաչ օբյեկտ-կողմնորոշված ծրագրավորման լեզուները` C++ և Java, առաջարկվում են տեսողական ծրագրավորման (visual programming) փաթեթներում, որոնք հաճախ նկարագրվում են որպես կիրառական ծրագրերի արագ մշակում ապահովող:

 

Նպատակահարմար միասնական գործընթաց մեթոդաբանություն (ՆՄԳ, RUP: Rational Unified Process Methodology)

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

 

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

  • Այն թույլ է տալիս հաշվի առնել փոփոխվող պահանջները, ինչը, չնայած նախագծի բոլոր ղեկավարների լավագույն ջանքերի, դեռևս իրականություն է գրեթե յուրաքանչյուր նախագծի համար:
  • Ինտեգրման գործընթացը վերջնական փուլում այսպես կոչված մեկ «Մեծ պոռթկում» չէ` փոխարենը, տարրերը ինտեգրվում են աստիճանաբար:
  • Ռիսկերը սովորաբար հայտնաբերվում են կամ դրանց անդրադառնում են ինտեգրման ընթացքում: Կրկնվող մոտեցմամբ, հնարավոր է նախօրոք կանխարգելել ռիսկերը:
  • Կրկնվող մշակումն ապահովում է կառավարում ՏՏ լուծման (արտադրանքի) նկատմամբ մարտավարական փոփոխություններ կատարելու միջոցով: Այն թույլ է տալիս ՏՏ լուծումը թողարկել նախատեսվածից ավելի շուտ նախատեսվածից ավելի քիչ հնարավորությամբ մրցակիցներին դիմադրելու համար, կամ տվյալ տեխնոլոգիայի ապահովման համար ընդունել մեկ այլ ընկերության կողմից մատուցվող ծառայությունները:
  • Կրկնվող քայլը նպաստում է կրկին օգտագործմանը, ավելի հեշտ է բացահայտել ընդհանուր մասերը, երբ նրանք մասամբ նախագծված են կամ իրականացված, քան որոշել դրանք պլանավորման ընթացքում:
  • Եթե հնարավոր է սխալներն ուղղել ավելի քան մի քանի կրկնվող քայլերի դեպքում, ապա  արդյունքում կստացվի ավելի ամուր կառուցվածք (robust architecture): Կատարման խոչընդոտները, սահմանափակող օղակները (bottlenecks) հայտնաբերվում են այն ժամանակ, երբ նրանք դեռ կարող են վերացվել, տրամադրման նախօրեին խուճապ ստեղծելու փոխարեն:
  • Ծրագրավորողները կարող են ընթացքում սովորել, և նրանց տարբեր ընդունակությունները և մասնագիտությունները ավելի լիարժեք են օգտագործվում ամբողջ կենսափուլի ընթացքում: Փորձարկողները, տեխնիկական խմբագիրները համապատասխանաբար իրենց աշխատանքները սկսում են ավելի շուտ և այսպես շարունակ:
  • Մշակման գործընթացն ինքնին կարող է ընթացքում բարելավվել և կատարելագործվել: Գնահատումը կրկնվող քայլի վերջում ոչ միայն ցույց է տալիս նախագծի կարգավիճակը արտադրանքի կամ ժամանակացույցի տեսանկյունից, այլ նաև վերլուծում է, թե ինչ պետք է փոխել կազմակերպությունում և գործընթացում, որպեսզի այն ավելի լավ աշխատի հաջորդ կրկնվող քայլի ընթացքում:

 

Scrum մեթոդաբանություն (Scrum Methodology)

Scrum մեթոդաբանությունը նախագծի կառավարման ճկուն մեթոդ է, որը մշակվել է Քեն Սչվաբերի (Ken Schwaber) կողմից: Նրա նպատակն է աշխատանքային խմբերում, որոնք նախկինում ուժասպառ էին լինում ավելի ծանր, ծանրաբեռնված գործընթացով մեթոդաբանությունների կիրառման արդյունքում, կտրուկ բարելավել արդյունավետությունը:

 

Scrum մեթոդաբանությունը բնութագրվում է հետևյալ քայլերով`

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

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

 

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

 

Պարույր մեթոդաբանություն (Գալարաձև, Spiral Methodology)

 

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

 

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

 

Բարձր մակարդակի, պարույր մոդելի քայլերը հետևյալն են`

  1. Նոր համակարգի պահանջները սահմանված են հնարավորինս մանրամասն: Այս գործընթացը սովորաբար ներառում է մի շարք օգտվողների հետ հարցազրույցներ, որոնք ներկայացնում են գործող համակարգի բոլոր արտաքին կամ ներքին օգտվողներին և այլ բնութագրեր:
  2. Նոր համակարգի համար ստեղծվում է նախնական նախագիծ:
  3. Նոր համակարգի նախատիպի առաջին տարբերակը ստեղծվում է նախնական նախագծման հիման վրա: Ինչը սովորաբար պարզ համակարգ է և ներկայացնում է վերջնական ՏՏ լուծման բնութագրերի մոտավոր պատկերը:
  4. Նախատիպի երկրորդ տարբերակը զարգանում է օգտագործելով հետևյալ չորս քայլերը`
    • նախատիպի առաջին տարբերակի գնահատում և նրա ուժեղ, թույլ կողմերի և ռիսկերի որոշում
    • նախատիպի երկրորդ տարբերակի պահանջների սահմանում
    • նախատիպի երկրորդ տարբերակի պլանավորում և նախագծում
    • նախատիպի երկրորդ տարբերակի մշակում և փորձարկում
  5. Նախագծի հովանավորի ընտրությամբ, ամբողջ նախագիծը կարող է դադարեցվել, եթե ռիսկը համարվում է չափազանց մեծ: Ռիսկի գործոնները կարող են ընդգրկել մշակման արժեքի գերծախսեր, գործող արժեքի սխալ հաշվարկներ, կամ որևէ այլ գործոն, որը կարող է հանգեցնել ոչ գոհացուցիչ վերջնական արտադրանքի:
  6. Առկա նախատիպը գնահատվում է նույն ձևով, ինչպես նախորդ նախատիպը, և, անհրաժեշտության դեպքում, այդ նախատիպը զարգացվում է այլ նախատիպի ըստ վերը նշված չորս քայլերի ընթացակարգի:
  7. Նախորդող քայլերը կրկնվում են մինչև պատվիրատուն գոհ և բավարարված է, որ վերամշակված նախատիպը ներկայացնում է ցանկալի վերջնական ՏՏ լուծում:
  8. Վերջնական համակարգը մշակվում է վերամշակված նախատիպի հիման վրա:
  9. Վերջնական համակարգը լիովին գնահատվում և փորձարկվում է: Առօրյա սպասարկումը իրականացվում է շարունակական հիմունքներով խոշոր, լայնածավալ խափանումները կանխելու և աշխատանքի դադարը նվազագույնի հասցնելու նպատակով:

 

Համակարգերի մշակման կենսափուլ մեթոդաբանություն (ՀՄԿՓ, SDLC: Systems Development Life Cycle Methodology)

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

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

 

Ընդհանուր առմամբ, ՀՄԿՓ մեթոդաբանությունը հետևում է հետևյալ քայլերին.

  1. Եթե առկա է գործող համակարգ, ապա նրա թերությունները հայտնաբերվում են: Այս գործընթացն իրականացվում է օգտվողների հետ հարցազրույցի և սպասարկման անձնակազմի հետ խորհրդատվության միջոցով:
  2. Նոր համակարգի պահանջները սահմանված են, այդ թվում` գործող համակարգի ցանկացած թերություններին անդրադառնալը, բարելավման որոշակի առաջարկներ ներկայացնելով:
  3. Առաջարկվող համակարգը նախագծված է: Պլանները ստեղծված են` մանրամասնելով տեխնիկական միջոցները, օպերացիոն համակարգերը, ծրագրավորման և անվտանգության հարցերը:
  4. Նոր համակարգը մշակված է: Նոր բաղադրիչները և ծրագրերը պետք է ձեռք բերվեն և տեղակայվեն: Համակարգի օգտվողները պետք է անցնեն վերապատրաստում համակարգի շահագործման համար, և կատարման բոլոր տեսակետները պետք է փորձարկվեն: Անհրաժեշտության դեպքում, պետք է այս փուլում ճշգրտումներ կատարվեն:
  5. Համակարգը սկսում է շահագործվել: Շահագործումը կարող է կատարվել տարբեր եղանակներով: Նոր համակարգի շահագործման գործընթացը կարող է բաժանվել փուլերի` ըստ կիրառման կամ գտնվելու վայրի, և հին համակարգը աստիճանաբար փոխարինվի նոր համակարգով: Որոշ դեպքերում կարող է լինել ավելի ծախսաարդյունավետ դադարեցնել հին համակարգի շահագործումը և ներդնել նոր համակարգը միանգամից:
  6. Երբ նոր համակարգը գործում է ու աշխատում է որոշ ժամանակ, այն պետք է ամբողջությամբ գնահատել: Սպասարկումը պետք է ճշգրիտ մատուցվի բոլոր ժամանակներում: Համակարգի օգտվողները պետք է տեղեկացված լինեն վերջին փոփոխություններին և ընթացակարգերին:

 

Ջրվեժ մեթոդաբանություն (նաև հայտնի է որպես Ավանդական, Waterfall Methodology)

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

 

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

 

Գործնականում, ջրվեժ (Waterfall) մշակումը հաճախ չի համապատասխանում սպասելիքներին, քանի որ այն չի ընդգրկում անխուսափելի փոփոխությունները և տարբերակները, որոնք անհրաժեշտ են յուրաքանչյուր նախագծի համար: Երբ կիրառական ծրագիրն արդեն գտնվում է փորձարկման փուլում, շատ դժվար է վերադառնալ և փոխել մի բան, որ հաշվի չեն առել նախագծման նախնական փուլում: Ջրվեժ (Waterfall) մոդելի այլընտրանքային տարբերակներն են կիրառական ծրագրերի համատեղ մշակումը (ԿԾՀՄ), կիրառական ծրագրերի արագ մշակումը (ԿԾԱՄ), սինքրոնացում (համաժամանակացում) և կայունացնումը, կառուցում և վերանորոգումը և պարույր (գալարաձև) մոդելը:






 
 
© 2017 Association of Modern Technologies Professionals