Ներքին փոխազդեցություն հաճախորդի հետ դիզայնի ընթացքում: Հաճախորդ և Կապալառու - հարաբերությունները որպես ծրագրի հաջողության հիմք

Հաճախորդի հետ փոխգործակցության ընդհանուր փուլերը հետևյալ կետերն են.

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

Հաճախորդի հետ փոխգործակցության կարևոր ձև է հանդիսանում նախագծի իրականացման ընթացքում մշակված փաստաթղթերը ԳՕՍՏ 34-ի և RUP-ի պահանջներին համապատասխան:

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

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

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

• Թեմայի վերլուծություն և տեխնիկական բնութագրերի ստեղծում (փոխգործակցություն հաճախորդի հետ)
• Ծրագրի կառուցվածքի ձևավորում
• Կոդավորում (ծրագրի կոդերի հավաքածու՝ ըստ նախագծի փաստաթղթերի)
• Փորձարկում և վրիպազերծում
• Ծրագրի իրականացում
• Ծրագրի աջակցություն
• Օտարում

Եկեք ավելի սերտ նայենք նախագծման գործընթացին: Նախագծման գործընթացում ճարտարապետը կամ փորձառու ծրագրավորողը ստեղծում է նախագծային փաստաթղթեր՝ ներառյալ ապագա ծրագրի տեքստային նկարագրությունները, դիագրամները և մոդելները: Այս դժվարին հարցում մեզ կօգնի UML լեզուն։

UML-ը գրաֆիկական լեզու է տարբեր համակարգերի (մասնավորապես ծրագրերի) վիզուալիզացիայի, պարամետրերի նկարագրության, նախագծման և փաստաթղթավորման համար: Դիագրամները ստեղծվում են հատուկ CASE գործիքների միջոցով, ինչպիսիք են Rational Rose (http://www-01.ibm.com/software/rational/) և Enterprise Architect (http://www.sparxsystems.com.au/): UML տեխնոլոգիայի հիման վրա կառուցված է մեկ տեղեկատվական մոդել: Վերոնշյալ CASE գործիքները կարող են գեներացնել կոդ տարբեր օբյեկտի վրա հիմնված լեզուներով, ինչպես նաև ունեն հակադարձ ինժեներական շատ օգտակար հատկություն: (Հակադարձ ճարտարագիտությունը թույլ է տալիս ստեղծել գրաֆիկական մոդել գոյություն ունեցող ծրագրի կոդից և դրա մեկնաբանություններից):

Մտածեք մոդելի վիզուալիզացիայի գծապատկերների տեսակները (դրանք պարտադիր են, չնայած կան շատ ավելի շատ տեսակներ).

Օգտագործեք դեպքի դիագրամ

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

Դասի դիագրամ (դասի դիագրամ)

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

Պետական ​​դիագրամ (statechart գծապատկեր)

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

Հերթականության դիագրամ

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

Համագործակցության դիագրամ

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

Բաղադրիչի դիագրամ

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

Տեղակայման դիագրամ

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

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

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

1.1. Փոխազդեցություն հաճախորդների հետ (հիմնական գործառույթներ)

1.1.1. Պատվիրեք որոնում

7.2.3.1. Ապրանքի մասին տեղեկատվության համար

1.1.2. Հաճախորդի հետ նախապայմանագրային աշխատանք

Կարգավորող փաստաթղթեր

2.2.1.2.1. Հաճախորդի հետ նախապայմանագրային աշխատանք STP-1-01

ISO9000:2000 Որակի կառավարման համակարգի պահանջների 7-րդ կետ

7.2.1.1. Ապրանքների նկատմամբ հաճախորդների պահանջները, ներառյալ առկայության, առաքման և սպասարկման պահանջները

7.2.2.4. Որոշակի պահանջներին համապատասխանության հասնելու ունակության որոշում

// Արտադրանքի պահանջների վերլուծություն / Սպառողի հետ կապված գործընթացներ / ԱՊՐԱՆՔՆԵՐԻ ՎԱՃԱՌՔ

1.1.3. Առաջադրանքի ձևավորում

Կարգավորող փաստաթղթեր

2.2.1.2.2. STP-2-01 պայմանագրի վերլուծության և կնքման կարգը // Ձեռնարկությունների ստանդարտներ Էլլաթ (STP) / Որակի կառավարման համակարգի փաստաթղթեր / Ներքին կարգավորող փաստաթղթեր / Կանոնակարգեր

ISO9000:2000 Որակի կառավարման համակարգի պահանջների 7-րդ կետ

7.2.1.2. Հաճախորդի կողմից չնշված պահանջներ, բայց անհրաժեշտ են նախատեսված կամ սահմանված օգտագործման համար // Հաճախորդի պահանջների սահմանում / Հաճախորդների հետ կապված գործընթացներ / ԱՊՐԱՆՔԻ ՎԱՃԱՌՔ

7.2.1.3. Արտադրանքի հետ կապված պարտավորություններ, ներառյալ պարտադիր պահանջները և իրավական դրույթները // Հաճախորդի պահանջների սահմանում / Հաճախորդների հետ կապված գործընթացներ / ԱՊՐԱՆՔԻ ՎԱՃԱՌՔ

// Արտադրանքի պահանջների վերլուծություն / Սպառողի հետ կապված գործընթացներ / ԱՊՐԱՆՔՆԵՐԻ ՎԱՃԱՌՔ

7.2.2.2. Սպառողների պահանջների հաստատումը մինչև դրանց ընդունումը, եթե սպառողը չի ներկայացնում պահանջների գրավոր հայտարարություն // Արտադրանքի պահանջների վերլուծություն / Սպառողի հետ կապված գործընթացներ / ԱՊՐԱՆՔՆԵՐԻ ՎԱՃԱՌՔ

7.2.2.3. Պայմանագրի կամ պատվերի պահանջների փոփոխությունների պարզաբանում, որոնք տարբերվում են նախկինում ներկայացվածներից (օրինակ՝ հայտով կամ հղումներով) // Արտադրանքի պահանջների վերլուծություն / Սպառողի հետ կապված գործընթացներ / ԱՊՐԱՆՔՆԵՐԻ ՎԱՃԱՌՔ

7.3.1.1. Նախագծման և/կամ մշակման գործընթացների փուլերի որոշում

7.3.2.2. Կիրառելի իրավական և կարգավորող պահանջներ

7.3.2.3. Կիրառելի տվյալներ՝ ստացված նմանատիպ նախորդ զարգացումներից // Մուտքագրեք տվյալներ նախագծման և մշակման համար / Դիզայն և մշակում / ԱՊՐԱՆՔԻ ՎԱՃԱՌՔ

7.3.2.4. Դիզայնի և զարգացման համար կարևոր այլ պահանջներ // Մուտքագրեք տվյալներ նախագծման և մշակման համար / Դիզայն և մշակում / ԱՊՐԱՆՔԻ ՎԱՃԱՌՔ

7.3.4.1. Պահանջներին բավարարելու ունակության գնահատում

1.1.4. Համաձայնագրերի կնքում

Կարգավորող փաստաթղթեր

2.2.1.2.3. Հաճախորդի հետ պայմանագրային աշխատանքի կանոնակարգ (STP-3-01) // Enterprise Standards Ellat (STP) / Որակի կառավարման համակարգի փաստաթղթեր / Ներքին կարգավորող փաստաթղթեր / Կանոնակարգեր

1.1.5. Պայմանագրային պարտավորությունների կատարման մոնիտորինգ

Կարգավորող փաստաթղթեր

2.2.1.2.3.2. Փոփոխությունների վերլուծության և պայմանագրային փաստաթղթերում փոփոխություններ կատարելու կարգը // Հաճախորդի հետ պայմանագրային աշխատանքի կանոնակարգ (STP-3-01) / Ձեռնարկությունների ստանդարտներ Էլլաթ (STP) / Որակի կառավարման համակարգի փաստաթղթեր / Ներքին կարգավորող փաստաթղթեր / Կանոնակարգեր

2.2.1.2.4.1. Հաճախորդի բողոքների և պահանջների քննարկման կարգը

2.2.1.2.4.2. Հաճախորդի մեկնաբանությունները վերացնելու կարգը // Ուղղիչ և կանխարգելիչ գործողությունների կանոնակարգ (STP-4-01) / Ellat Enterprise Standards (STP) / Որակի կառավարման համակարգի փաստաթղթեր / Ներքին կարգավորող փաստաթղթեր / Կանոնակարգեր

ISO9000:2000 Որակի կառավարման համակարգի պահանջների 7-րդ կետ

7.2.3.2. Հարցումների, պայմանագրերի, պատվերների մշակում, ներառյալ փոփոխությունները // Հաղորդակցություն սպառողի հետ / Սպառողի հետ կապված գործընթացներ / ԱՊՐԱՆՔՆԵՐԻ ՎԱՃԱՌՔ

1.2. Ծրագրի աշխատանքների ժամանակացույց (հիմնական գործառույթներ)

1.2.1. Համալիրի կազմի և զարգացման շրջանակի պարզաբանում

Կարգավորող փաստաթղթեր

// Enterprise Standards Ellat (STP) / Որակի կառավարման համակարգի փաստաթղթեր / Ներքին կարգավորող փաստաթղթեր / Կանոնակարգեր

ISO9000:2000 Որակի կառավարման համակարգի պահանջների 7-րդ կետ

7.2.2.1. Արտադրանքի պահանջների սահմանում // Արտադրանքի պահանջների վերլուծություն / Սպառողի հետ կապված գործընթացներ / ԱՊՐԱՆՔՆԵՐԻ ՎԱՃԱՌՔ

1.2.2. Ծրագրի որակի ապահովման պլանավորում

Կարգավորող փաստաթղթեր

2.2.1.2.5. Ծրագրի որակի ապահովման ծրագրի մշակման կազմը և ընթացակարգը (STP-5-01) // Enterprise Standards Ellat (STP) / Որակի կառավարման համակարգի փաստաթղթեր / Ներքին կարգավորող փաստաթղթեր / Կանոնակարգեր

ISO9000:2000 Որակի կառավարման համակարգի պահանջների 7-րդ կետ

• 7.1.1. Ապրանքի, նախագծի կամ պայմանագրի որակի նպատակների սահմանում

7.1.3. Վերանայման և հաստատման գործունեության և ընդունման չափանիշների սահմանում // Վաճառքի գործընթացների պլանավորում / ԱՊՐԱՆՔՆԵՐԻ ՎԱՃԱՌՔ

7.2.2.5. Վերլուծության արդյունքների և հետագա հետագա գործողությունների ամրագրում (տես 5.5.7 կետ) // Արտադրանքի պահանջների վերլուծություն / Սպառողի հետ կապված գործընթացներ / ԱՊՐԱՆՔՆԵՐԻ ՎԱՃԱՌՔ

7.3.1.2. Վերանայման, ստուգման և հաստատման գործողությունների սահմանում նախագծման և/կամ մշակման յուրաքանչյուր փուլի համար // Դիզայն և մշակման պլանավորում / Դիզայն և մշակում / ԱՊՐԱՆՔՆԵՐԻ ՎԱՃԱՌՔ

1.2.3. Համալիրի բաղադրիչների մշակման մասնավոր տեխնիկական բնութագրերի ձևավորում

Կարգավորող փաստաթղթեր

2.2.1.2.7. Ծրագրի իրականացման տեխնոլոգիա. Աշխատանքի փուլերը և կարգը (STP-7-01) // Enterprise Standards Ellat (STP) / Որակի կառավարման համակարգի փաստաթղթեր / Ներքին կարգավորող փաստաթղթեր / Կանոնակարգեր

1.2.4. Ծրագրի պլանավորում

Կարգավորող փաստաթղթեր

// Enterprise Standards Ellat (STP) / Որակի կառավարման համակարգի փաստաթղթեր / Ներքին կարգավորող փաստաթղթեր / Կանոնակարգեր

ISO9000:2000 Որակի կառավարման համակարգի պահանջների 7-րդ կետ

7.1.2. Գործընթացների և փաստաթղթերի ստեղծման, արտադրանքին հատուկ ռեսուրսների և ենթակառուցվածքների տրամադրման անհրաժեշտության որոշում // Վաճառքի գործընթացների պլանավորում / ԱՊՐԱՆՔՆԵՐԻ ՎԱՃԱՌՔ

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

Կարգավորող փաստաթղթեր

2.2.1.2.4.3. Ուղղիչ գործողությունների կարգը // Ուղղիչ և կանխարգելիչ գործողությունների կանոնակարգ (STP-4-01) / Ellat Enterprise Enterprise Standards (STP) / Որակի կառավարման համակարգի փաստաթղթեր / Ներքին կարգավորող փաստաթղթեր / Կանոնակարգեր

2.2.1.2.6. Աշխատանքային պլանավորման կանոնակարգ (STP-6-01) // Enterprise Standards Ellat (STP) / Որակի կառավարման համակարգի փաստաթղթեր / Ներքին կարգավորող փաստաթղթեր / Կանոնակարգեր

ISO9000:2000 Որակի կառավարման համակարգի պահանջների 7-րդ կետ

7.3.4.2. Խնդիրների բացահայտում և հետագա գործողությունների առաջարկների մշակում // Դիզայն և մշակում վերլուծություն / Դիզայն և մշակում / ԱՊՐԱՆՔԻ ՓՈՍՏԱՌՈՒՄ

7.3.7. Դիզայնի և զարգացման փոփոխությունների կառավարում

1.3. Դիզայնի, ծրագրային ապահովման և գործառնական փաստաթղթերի մշակում (Հիմնական գործառույթներ)

1.3.1. Համալիրի ապարատային փաստաթղթերի մշակում

Կարգավորող փաստաթղթեր

2.2.1.2.7. Ծրագրի իրականացման տեխնոլոգիա. Աշխատանքի փուլերը և կարգը (STP-7-01) // Enterprise Standards Ellat (STP) / Որակի կառավարման համակարգի փաստաթղթեր / Ներքին կարգավորող փաստաթղթեր / Կանոնակարգեր

2.3.3.3. Սարքավորումների մշակման և արտադրության բաժնի աշխատանքային պլան

1.3.2. Համալիրի ծրագրային մասի մշակում

Կարգավորող փաստաթղթեր

2.2.1.2.7. Ծրագրի իրականացման տեխնոլոգիա. Աշխատանքի փուլերը և կարգը (STP-7-01) // Enterprise Standards Ellat (STP) / Որակի կառավարման համակարգի փաստաթղթեր / Ներքին կարգավորող փաստաթղթեր / Կանոնակարգեր

2.3.3.4. Ծրագրային ապահովման մշակման և արտադրության բաժնի աշխատանքային պլան // Ծրագրեր և գործողությունների պլաններ / Ընկերության կազմակերպչական և վարչական փաստաթղթեր / Կանոնակարգ

1.3.4. Դիզայնի արդյունքների վերլուծություն և հաստատում

Կարգավորող փաստաթղթեր

2.2.1.2.7. Ծրագրի իրականացման տեխնոլոգիա. Աշխատանքի փուլերը և կարգը (STP-7-01) // Enterprise Standards Ellat (STP) / Որակի կառավարման համակարգի փաստաթղթեր / Ներքին կարգավորող փաստաթղթեր / Կանոնակարգեր

ISO9000:2000 Որակի կառավարման համակարգի պահանջների 7-րդ կետ

7.3.3.1. Համապատասխանում է նախագծման և մշակման ներդրման պահանջներին

7.3.3.2. Տրամադրել համապատասխան տեղեկատվություն արտադրական և սպասարկման գործառնությունների համար (տես 7.5) // Դիզայն և մշակում արդյունք / Դիզայն և մշակում / ԱՊՐԱՆՔԻ ՓՈՍՏԱՓՈԽՈՒՄ

7.3.3.4. Որոշեք արտադրանքի բնութագրերը, որոնք էական նշանակություն ունեն դրա անվտանգ և պատշաճ օգտագործման համար: // Դիզայն և մշակում արդյունք / Դիզայն և մշակում / ԱՊՐԱՆՔԻ ՓՈՍՏԱՓՈԽՈՒՄ

7.3.5.1. Ելքային տվյալների համապատասխանությունը մուտքային պահանջներին // Դիզայն և մշակում Ստուգում / Դիզայն և մշակում / ԱՊՐԱՆՔԻ ՎԱՃԱՌՔ

7.3.6. Նախագծման և մշակման արդյունքների հաստատում // Դիզայն և մշակում / ՎԱՃԱՌՔԻ ԱՊՐԱՆՔՆԵՐ

• Կրթություն, զարգացում, վերապատրաստումներ

Բանալի բառեր:

1 -1

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

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

* Հարկ է նշել, որ հաճախորդին հատկացվում է անձնական մենեջեր իր նախագծի ողջ ժամանակահատվածի համար, ով պատրաստ է պատասխանել բոլոր հարցերին և օգնել լուծել բոլոր խնդիրները:

Հաջորդը, մենեջերը օգնում է լրացնել համառոտ ձևվեբկայքի մշակման համար, որը պարունակում է համագործակցության թեմայի վերաբերյալ անհրաժեշտ հստակեցնող հարցեր և կոնտակտ է ավելացնում ներքին CRM համակարգին (Customer Relationship Management System):

Տվյալները մուտքագրվում են համակարգ՝ հաճախորդների բոլոր անհրաժեշտ տվյալները ապահով պահելու և ամբողջ կայքի որակյալ զարգացումն ապահովելու համար:

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

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

*Զանգից մինչև պայմանագրի ստորագրման գործընթացը սովորաբար տևում է ոչ ավելի, քան 1-2 օր:

Պայմանագիրը ստորագրելուց և էլեկտրոնային սկանավորված պատճենները փոխանակելուց հետո հաճախորդը վճարում է կանխավճար, որի գումարը սովորաբար կազմում է պայմանագրի ընդհանուր գումարի 50%-ը։

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

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

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

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

* Հաճախորդին անհրաժեշտ նյութերով ապահովելը կարևոր է, քանի որ.

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

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

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

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

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

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

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

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

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

Ընդունման վկայականը ստորագրելուց հետո պատվիրատուն, պայմանագրին համապատասխան, վճարում է աշխատանքի մնացած արժեքը։

Վերջնական հաշվարկից հետո փաստաթղթերի և կայքի հետ մեկտեղ հաճախորդը ստանում է օգտատիրոջ ձեռնարկ, կայքի պատճենը DVD-ովև անվճար տեխնիկական աջակցությունկայքի ընդունման օրվանից 2-4 շաբաթվա ընթացքում:

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

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

Հուսով ենք, որ փոխգործակցության նկարագրված սխեման թափանցիկ է և հասկանալի: Եթե ​​դեռ հարցեր ունեք, խնդրում եմ

Նախագիծ:	Էլեկտրոնային կատալոգում հարցումների բաշխում ըստ որոնման ինդեքսների և որոնման պայմանների
Ծրագրի շրջանակը.	13.02.2006 - 05.06.2006
Հաճախորդ:	Պետրոզավոդսկի պետական ​​համալսարանի գիտական ​​գրադարան.
Պատասխանատու:	Գորշկովա Գալինա Անատոլևնա, փաստաթղթերի համակարգչային մշակման և կատալոգների ստեղծման բաժնի վարիչ։ Էլ փոստ: Ստրուկ. հեռ.՝ 719602. Գրադարան՝ կաբ. 102. Գուրև Դմիտրի Բորիսովիչ, RCNIT-ի առաջատար ծրագրավորող։ Էլ փոստ: Ստրուկ. հեռ.՝ 784775. Ինտերնետ կենտրոն.
Հրահանգիչ:	Կուլակով Կիրիլ Ալեքսանդրովիչ փոստ՝ . Գրասենյակային հեռախոս՝ 711015. 215 սենյակ
Տեղեկություններ հրահանգչի համար.	Թիվ 13 խումբ
Առնչվող փաստաթղթեր.	Ծրագրի ակնարկ Ծրագրի պլանի Աշխատանքային ժամանակացույց (Gantt Chart) Պահանջներ Հստակեցում Նախագծման փորձարկման իրականացման Փաստաթղթի փորձարկման փաստաթուղթ Customer Engagement Developer Relations Reports Development Progress Glossary Օգտագործողի ուղեցույց

Առաջին հանդիպումը հաճախորդի հետ.

Առաջին հանդիպման ժամանակ հաճախորդին ներկայացվեց զարգացման թիմը: Հաճախորդն իր հերթին խոսեց ՊետրՊՀ գիտական ​​գրադարանի մասին.

Գրադարանը գործում է «Ֆոլիանտ» ավտոմատացված համակարգի հիման վրա։ Էլեկտրոնային գրացուցակը գրադարանային համակարգի մի մասն է: Կատալոգի որոնումն իրականացվում է հարցումների միջոցով: Օպերատորը ստեղծում է որոնման տողեր, որոնք կարող են պարունակել մեծ թվով որոնման ինդեքսներ և որոնման տերմիններ: Յուրաքանչյուր հարցում գրանցվում է գրանցամատյանների աղյուսակում: Այս աղյուսակը պարունակում է տվյալներ հարցման ժամանակի, հարցումը կատարած հաճախորդի հասցեի, բուն հարցումի, հարցման արդյունքի մասին:

Հաճախորդը պետք է մշտապես վերահսկի տեղեկամատյանների աղյուսակը և տրամադրի որոշ վիճակագրություն որոնման ինդեքսների օգտագործման վերաբերյալ:

Ներկայացվել են նաեւ իրականացվող ծրագրի նախնական պահանջները։ Պահանջներից մեկը վիճակագրության արդյունավետ կազմումն է։ Այսինքն՝ վիճակագրությունը պետք է ցուցադրվի հարցումն ուղարկելուց հետո ողջամիտ ժամանակ անց։ Այս պահանջի շնորհիվ մշակողները խրախուսվեցին օգտագործել սերվերի կողմի ընթացակարգերը PL/SQL-ում:

Երկրորդ հանդիպումը հաճախորդի հետ.

Հաճախորդը ծրագրավորողներին տրամադրել է մուտք և գաղտնաբառ՝ էլեկտրոնային կատալոգի համակարգ մուտք գործելու համար՝ աշխատանքի համար տրամադրելով երկու աղյուսակների պատճեններ՝ տեղեկամատյանների աղյուսակ և որոնման ինդեքսների աղյուսակ:

Գուրև Դմիտրի Բորիսովիչը մեզ ավելի մանրամասն ծանոթացրեց Oracle SQL*Plus DBMS հաճախորդի աշխատանքին։ Թիմը ծանոթացավ էլեկտրոնային կատալոգի աշխատանքին։

«Foliant» համակարգը աշխատում է RusMark ստանդարտի հիման վրա, որը պարունակում է մոտ 99 դաշտ։ AIBS «Foliant»-ի հետ աշխատող յուրաքանչյուր գրադարան ընտրում է այն դաշտերն ու ենթադաշտերը, որոնք կօգտագործի: Կան հատուկ ԳՕՍՏ-ներ, որոնք նկարագրում են գրադարանային տվյալների պահպանման կանոնները: Քանի որ կան մեծ թվով դաշտեր, մենք ստեղծեցինք որոնման ինդեքսների համակարգ։ Կան սպասարկման և հանրային ինդեքսներ։

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

Երրորդ հանդիպում հաճախորդի հետ.

Հաճախորդը մեզ գրավոր ներկայացրել է հստակ պահանջներ:

Հաճախորդին հետաքրքրում է հետևյալ վիճակագրությունը.

1. Էլեկտրոնային կատալոգի հարցումների քանակը:

• Վերջին ամսվա ընթացքում օրեցօր.
• Ընթացիկ տարվա ամսական հաշվառում.
• Հաշվապահական հաշվառում ըստ տարիների.
• Ստեղծեք տեղեկատվության պատմություն:

Հարցումների ցանկը ըստ յուրաքանչյուրինորոնման ինդեքս, որտեղ որոնման արդյունքը զրոյական էր:

Հաճախակի հանդիպող հարցումների ցանկ:

Որոշակի ժամկետով հարցումների կատարման վերլուծություն. Զեկույցը պետք է ներառի հետևյալ վիճակագրությունը.

• Հարցումների քանակը.
• Փնտրման հարցումների քանակը:
• Բարդ հարցումների քանակը.
• Հաջողված պատասխանների քանակը.
• Զուր պատասխանների քանակը:
Օգտագործեք հետևյալ որոնման ինդեքսները.
• Հեղինակ
• Հեղինակ rev. արդ.
• Փաստաթղթի տեսակը.
• Աշխարհագրական բաժին.
• Մուտքագրեք ամսաթիվը:
• Հրապարակման ամսաթիվը.
• Կոչում.

Չորրորդ հանդիպում հաճախորդի հետ.

Հաճախորդից մասնագետ Գուրև Դ.Բ. բացատրեց SQL*Plus կոմունալ ծրագիրը տեղադրելու և կազմաձևելու բարդությունները: Ծրագրի գործարկման խնդրի լուծումը եղել է SQL * Net փաթեթի տեղադրումը, ինչպես նաև Guryev D.B. տրամադրեց աղյուսակների ճշգրիտ անվանումները մշակողների համար, ինչպես նաև ավելացրեց թիմի տրամադրության տակ գտնվող ևս մեկ աղյուսակ: Մասնագետն ուսումնասիրել է ճարտարապետական ​​փաստաթուղթը և առաջարկել գործնականում իրականացնել ճարտարապետության բոլոր տեսակները և ընտրել ամենաօպտիմալը։ Միևնույն ժամանակ, ցանկալի է չվերակառուցել log-աղյուսակը և հնարավորինս լուծելով կոնկրետ խնդիր, ընդհանրացնել log-աղյուսակի տվյալները՝ հետագա օգտագործման համար տեղական տարբեր վիճակագրություններում:

Հաճախորդ Գորշկովա Գ.Ա. ծանոթացել է պահանջների փաստաթղթին՝ հաստատելով դրանք։

Հինգերորդ հանդիպում հաճախորդի հետ.

Հաճախորդի կողմից մասնագետ Գուրև Դմիտրի Բորիսովիչը հրավիրվել է «Oracle» DBMS-ի հետ աշխատելու համար անհրաժեշտ ծրագրակազմը PetrSU-ի ուսումնական սերվերի վրա տեղադրելու համար: Համալսարանի կողմից այս գործընթացին ներգրավված էր նաև Վադիմ Անատոլևիչ Պոնոմարևը, ով վարչական մուտք ունի PetrSU սերվեր: