Қауіптерді басқару

Жоба менеджер жұмысының маңызды бір бөлігі болып жұмыс графигіне әсер ететін қатерлерді бағалау болып саналады немесе бағдарлама өнімінің сапасына және қатерлерді жою мерекелерін құру болып табылады.

Жалпы қатерлер 3 типі анықталады:

1. Жобаның жұмыс графигі немесе ресурсына арналған катер;

2. Құрылатын жобаның сапасына немесе программалық өнімнің өнімділігіне арналған катерлер;

3. Құрастырушы немесе жабдықтаушы ұйымына кіретін бизнес катерлер. Қатерлерді басқару 4 кезеңнен тұрады:

1. Қатерді анықтау;

2. Қатер анализі;

3. Қауіп-қатерді жоспарлау;

4. Қауіп-қатер моноторингі.

Негізгі әдебиеттер - 7[81-101], 12[36-39], 2[107-134].

Бақылау сұрақтары мен жаттығулар:

1. Проектті басқару дегеніміз не? Проектіні басқару құрамалары.

2. Программалалық проектілерді басқару үрдісінде программалық жүйелердің нематериальность не үшін ерекше мәселелерді(порождает особые проблемы)тудыратынын түсіндіріңіз?

3. Не себепті проетті жобалау үрдісі(процесс плонирования) итерация түрінде болады(является итерационным) және проекттің жүзеге асу мерзімі кезінде план әр кез қайта қаралып отыру керек(постоянно пересматриваться)?

4. Сіздің көз-қарасыңыз бойынша нақар аударуға тұрарлықтай көрсетілген қатер толықтырларын анықтаңыз?

5. Жұмыс графтарының графикалық сипаттау тәсілдерінің негізін түсіндіріңіз

3 - Дәріс. ӨТІНІШ АНАЛИЗІ

Бір нәрсе құру үшін біз алдын-ана ол не болуы мүмкін соны түсініп алуымыз керек. Мұндағы түсіну және құжаттау үрдісі өтініш анализі деп аталады.

Өтініш анализі (requirements analysis) – қосымшаның болмысы, жұмыс өнімділігі, сыртқы келбеті мен қызметі қандай болатынын анықтаушы, аяқталған жазбаша тұжырымды алу процесі.

Өтініш анализі тапсырыс беруші орындайтын талаптардың формальды емес сипаттамасы мен жүйені жобалау арасын байланыстырушы көпір қызметін атқарады. Анализ әдістері жүйенің міндеттерін қалыпқа келтіруге тиіс, олардың қолданысы: «Келешек жүйе нендей қызмет атқаруы керек?» деген сауалдың жауабын беруі керек.

Құрлымдық анализ – ПО-ға қатысты талап ету анализдерінің қалыпқа келтірілген әдістерінің бірі.

Бұл әдістің авторы – Том Де Марко (1979)[14]. Бұл әдісте программалық өнім мәліметтердің ақпараттық легін түзуші ретінде қарастырылады. Құрлымдық анализдің басты элементі – мәліметтер легінің диаграммасы. Мәліметтер легінің диаграммасы – мәліметтер жүйеге ену және шығу кезінде кездесетін түзілімдер мен ақпараттардың легін кескіндеуге арналған графикалық құрал.

Өзіміз білетіндей, кез-келген жүйе үшін проблема тудырушы мәселе мәліметтердің легі, процестері және құрлымы. Құрлымдық анализ кезінде мәліметтер мен порцестер легі кеңінен қолданылады.

Мәліметтер құрлымына бағытталған анализ әдістері мыналарды қамтамасыз етеді:

1. шешуші ақпараттық объектілер мен операцияларды анықтайды;

2. мәліметтер иерархиялық құрлымын анықтайды;

3. типтік конструкциядағы мәліметтер құрлымының компоновкасы – тәртіптеу, таңдау және қайталау;

4. мәліммердің иерархиялық құрлымын Бағдарламалар құрлымына айналдыру үшін жасалатын қадамдардың реттілігі.

Кеңінен қолданылатын екі әдіс бар: Варнье-Орра әдісі мен Джексон әдісі[14].

Қосымшаға арналған өтініш анализі нақты бір формадағы тұжырымды қажет тұсында бейнелеу мен сараптау процесі болып табылады. Өндірілген ПО-дағы кемшіліктердің көпшілігі талап ету анализі кезінде туындаған және мұндай кемшіліктерді қалпына келтіру өте қиын.

Әдетте, өтініштер қосымша қандай қызмет атқаратынын көрсетеді: көп жағдайда тиісті функциялардың орындауға қалай қол жеткізуге болатындығын жүйелеуге талпынбайды да. Мысалға, мына ұсынғанымыз бухгалтерлік қосымшаға арналған:

Жүйе тұтынушының өз банктік есебінің балансына қол жеткізуіне мүмкіндік береді.

Былайша айтқанда мына ұсынғанымыз қосымшаға арналмаған:

Клиеттердің есеп балансы Access дерекқорындағы кестеде «баланс» атымен сақталады.

Екіншісі қосымша не істеу керектігне емес, қалай құрылу керек екеніне қатысты .

Өтініш анализінің нәтижесі болып әдетте талап ету спецификациясы немесе ПО-ға қатысты өтініш спецификациясы(SRS – Software Requirements Specification) деп аталатын құжат болып табылады.

C-талаптары және D–талаптары

Өтініш анализі екі деңгейге бөлінеді[2]. Бірінші деңгей тапсырыс берушінің талғамы мен қажеттілігін құжаттайды дәне ол тапсырыс берушіге түсінікті тілде жазылады. Нәтижені кейде тапсырыс беруші өтініші немесе С-талабы деп атайды. С-талабының бірінші аудиториясы жасаушылар қауымдастығы болады, ал екіншісі – тапсырыс берушілер қауымдастығы. Бірақ, C және D–талабының мақсаттық аудиториялары әр түрлі, жасаушылар мен тапсырыс берушілер сәтті өнім шығару барысында тығыз қарым-қатынаста болады.

Программаларды құру теориясы және әлемдік тәжірибе талаптың ұқыпты құжатталуына талап етеді. Мұндай құжаттарсыз бірлестік қандай мақсаттарға жету керектігін білмейді, өзінің жұмысын қатесіз тексере алмайды, жұмыс өнімділігін қадағалап, жұмысы жайында шынайы ақпарат ала алмайды. Өзінің келесі жұмысының көлемі және шарты жайында ақпарат беріп, тапсырыс берушілерін қанағаттандыра алмайды. Яғни, жазбаша түрдегі өтінішсіз кәсіби жасаушылар болмайды, сол себептен әрбір өтініш:

• нақты сипатталу керек;

• оңай қол жеткізу мүмкіндігі;

• нөмірленттуі керек;

• Растайтын тексттермен берілуі керек;

• Проектпен сәйкестендірілуі керек;

• Кодпен ескерілу керек;

• Бөлек тестілеу керек;

• Басқа өтініштермен тұтастықа тестіленуі керек;

• Жинау есебі орындалып болғаннан кейін тестілеуді растау керек;