1. Программалық қамтамассыздандыру тексерісі – жүйенің барлық өңдеуінің үрдіс кезеңінде талдау және тексерудің әртүрлі көріністе болуы. Тексеріс – бұл верификация және аттестацияның статикалық әдісі, сондықтан ол жүйенің атқарылуын керек етпейді.

2. Программалық қамтамассыздандыру тестілеуі.

Программалық қамтамассыздандыру тестілеуге арналған көп кітаптарда программалық жүйенің тестілеу үрдісі ретінде суреттеледі. Ол программалық қамтамассыздандырудың функциялық моделін өңдейді, бірақ оны объекті – бағытталған жүйенің жеке тестілеуі деп қарастыруға болмайды. Фунционалды моделдің өңдеу жүйесінде және объекті бағытталған жүйенің маңызды айырмашылықтары бар:

• объект, жеке программалар немесе фунциялардан гөрі өзі көп көрініс береді.

• объект интеграцияланған жүйе, әдетте олар бір – бірімен әлсіз байланыста болғандықтан оның жоғарғы-төменгі деңгейін анықтау қиын.

• талдау кезінде қолданылатын объектінің қайталануында оның шығыс коды тестілеушілерге қатынас болмайды.

Объекті – бағытталған жүйенің 4 тестілеу деңгейі анықталған:

1. Тестілеудің жеке әдісі(операция) – ол объектілермен ассоцияланған. Әдетте әдістер өздерімен функция немесе процедураны көрсетеді, сондықтан мұндай тестілеу әдісінің қара-ақ жәшігін қолдануға болады. Функционалды тестілеу, немесе тестілеу әдісі қара жәшікте базаланған, сол себепті специикация жүйесі немесе оның компоненттері бір-бірлерімен тығыз байланысқан. Қара жәшіктің іс- әрекетін оның кіру сәйкесінше шығу дерегімен анықтауға болады, яғни программалық қамтамассыздандыру реализациясы емес, ал оның атқарылу функциясы анықталады.

2. Тестілеудің жеке кластар объектісі.

Тестілеу әдісінің негізгі принципі қара жәшіктің өзгеріссіз қалуы, бірақ “класс эквиваленттілігін ” анықталуын қажетті кеңейту керек.

Объектіні тестілегенде толық тестеу жабуын (покрытие) қосу:

• бөлек тестілеудің барлық әдісі, объектілермен ассоцияланған.

• барлық атрибуттың тексерілуі, объектілермен ассоцияланған.

• барлық объектінің күй жағдайының текскрілуі, сол объектілердің жағдайын өзгерту.

3. Тестілеудің объект кластері.

Шығатын немесе кіретін құрастырулар бір –бірімен құрастырылған объект группаларына жарамсыз болады. Сол себепті, басқа тестілеу әдісін құрастыру керек. Масалы, сценарийлермен негіз болуы мүмкін.

Кластердің құрылуы әдістердің белгілеуіне және сервистерге негіз бола алады.

Объекті – бағытталған тестілеудің құрастыру жүйесінде 3 түрі бар:

1. Тестілеудің сценарийі және қолдану нұсқасы (Use Case).

Сценарийі қандай да бір жұмыс жүйесімен суреттеледі. Тестілеу осы сценарий және объект кластарында Use Case –ті жүзеге асыру негізінде базаланған.

2. Ағындар тестілеуі.

Бұл подход шығу кезінде жүйелерге тексеріс ретінде үн қату немесе группалардың кіру жағдайын анықтайды. Объекті –бағытталған жүйе, ережесі бойынша, жағдайлар басқарылады, сондықтан олар үшін осы тестілеудің түрі негіз болады.

3. Тестелеудің объектімен қарым – қатынасы.

Бұл тестілеу әдісі объектінің группаларымен қарым –қатынасы. Осы аралық деңгейі тестінің құрастыру жүйесі “әдіс –хабар ” анықталу жолына негізделген, және объектілердің бір –біріне тізбек бола алады. Тестілеу сценарийі басқа тестілеу әдісіне қарағанда неғұрлым эффектті екен.

Негізгі әдебиет: - 7[385-425], 4[390-411], 2[63-72],

2[487-519], 12[354-385], 11[155-205].

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

1. Тестілеу әдісімен құрылымдық тестілеудің негізгі айырмашылығы? Осы екі әдістің бір –бірімен қолдануын пайдаланып көріңіз.

2. Банкомат жағдайының тестілеу сценарийін құрыңыз.

3. Объекті –бағытталған жүйенің тестілік интеграциясының негізгі мәселесі неден тұрады?

4. Сценарийге негізделген тестілеудің мазмұнын түсіндіріңіз?

13- Дәріс. Программалық жүйені құрудың унифицирленген процесі

Бұл тақырыпта негізінен әртүрлі схемада құру мүмкіндігі бар базада ПО – ROP унифияланған процесті құру туралы нақтылы талқылау жатады.

Rational Onified Process ( RUP ) – бұл Rational Software компаниясымен құрылған және тексерілген ПО – ны дамыту технологиясының негізі болып табылады. Ол өзіне ПО – ның дамуын қосады және дамытумен айналысатын орындардың міндеттері мен мәселерін басқарып және соны бөлу дисципациялық әдісімен қамтамасыз етеді. Бұл қолдана отырып жоғары сапалы ПО – ларды құра алады. Олар барлық қолданушылардың барлық шаттарын қанағаттандырады: графиктерді және бюджеттерді құрады.

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

Rational Onified Process негізінде көптеген ыңғайлы проекттерден жиналған бірнеше функциональдық қағидалардан тұрады:

• Негізгі шұғыл шешімдерді ертерек қабылдаудан бастаңыз және оны үзіліссіз енгізіп отырыңыз немесе олар сізге өздері шығады;

- Тапсырыс берушілердің міндеттерін атқару;

- Өзіңізді осы программаға дайындаңыз;

- Проекттің басынан бастап өзгерістерге дайын болыңыз;

- Орындалатын архитектураны ертерек дайындаңыз;

- Компоненттерден жүйе құрыңыз;

- Бір команда сияқты жұмыс істеңіздер;

- Сапасын өмір сияқты істеңіздер;

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

Rational Onified Process программаны итерациялық дамытуға қолдана отырып проектті төрт фазаға бөледі: Басы, Проекттілеу, Құру және Енгізу. Әрбір фаза соңғы нүктенің процесімен жеткізіледі. Оларда осы фазаның жеткен жетістіктері тексеріледі және келесі фазаға өтуі туралы шешім қабылдайды. RUP төрт фазаның әрқайсысының вехасы және анық мақсаттары болады. Бұл – мақсаттар қандай мәселерді орындау керек және қандай артефактіні құру керек үшін қолданылады. Әрбір фаза бизнесті көтеру үшін жалғыз шешім қабылдайды.

Процестің барлық элементтері – рольдер, мәселелер, артефактар және шаблондар логикалық контейнерлерге топтастырылған. Олар дисциплина ( Disciplines ) деп аталады. Стандартты RUP- та тоғыз дисциплина бар. Оларға: бизнес – моделдеу, міндеттерді басқару, анализ және жобалау, жүзеге асыру, тестілеу, жобамен басқару, өзгерістерді басқару, айналдыру және орта.

Процестің әрбір жұмыс ағыны: міндеттердің жиынтығы, талдау, жобалау, жүзеге асыру және тестілеу байланған артефакттар мен іс - әрекеттерді анықтайды. Еске түсіре кетелік, артефакттар дегеніміз документтер, орындалатын элемент.

Артефакт дамытыла немесе қолданыла алады. Артефакттардың арасында тәуелділік бар. Мысалыға, міндеттердің жиынтығында қолданылатын Use Case моделі талдау процесінен моделді таңдайды және жоболау процесінен моделді жобалайды, жүзеге асыру процесінде моделді жүзеге асырады және тестілеу процесінде тестілеу моделін тексереді.

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

• бизнес – модель. Жүйе құрылып жатқан ұжымның абстракциясын анықтайды;

• аудан анықтау моделі. Жүйені бекітеді;

• Use Case моделі. Жүйеге функционалдық міндеттерді анықтайды;

• талдау моделі. Жүйедегі жоболау моделіндегі міндеттерді итерациялайды;

• жобалау моделі. Нақты ауданның сөздігі мен шешімін анықтайды;

• орналастыру моделі. Жүйе орындалатын аппараттық топологияны анықтайды;

• жүзеге асыру моделі. Физикалық жүйенің және оларды қолданатын бөліктерді анықтайды;

• процесстер моделі. Жүйедегі параллелдікті және механизмдердің синхронизациясын анықтайды.

Техникалық артефакттар негізгі төрт топқа бөлінеді.

• міндеттердің тобы. Жүйенің не істеу керек екенін анықтайды;

• жобалау тобы.Жүйені қалай жобалау керек екендігін көрсетеді;

• жүзеге асыру тобы. Дайындалған программалық компоненттердің тобын көрсетеді;

• орналастыру тобы. Қойылған конфигурацияның барлық ақпараттарымен қамтамасыз етеді.

Міндеттер тобы өзіне Use Case моделін функциялық емес міндеттер моделі, аудан анықтау моделі, талдау моделін қосады.

Жобалау моделі жобалық моделді, тестілік моделді және басқа да жүйеге керектілерді қосады.

Жүзеге асыру тобы программаның элементтерінің барлық ақпараттарын топтайды ( программалық код, конфигурацияның файлдары, деректер файлдары, программалық компоненттер, жүйені құру туралы ақпараттар ).

Орналастыру тобы жөнелту, орнату және жүйені енгізу туралы барлық ақпараттарды топтайды.

Әрбір технологиялық үрдіс тігуден тұрады. Ппрграммалық затты дамыту кезіндегі қанағаттандырмайтын шешімдер ( ҚШ ) болуы мүмкін: бюджеттің көбеюі, сенімділіктің төмендігі, ж. т. б. Қатер былайша анықталады.

Қатердің көрсетулігі = ықтиалдық ( ҚШ ) * жоғалту ( ҚШ )

Қатермен басқару алты іс - әрекеттен тұрады:

1. Қатердің идентификациясы – жобадағы қатер элементінің әсер ету.

2. Қатер талдауы – ықтималдықты бағалау.

3. Қатерді шифрлау – олардың элементке әсер ету дәрежесі.

4. Жобалау қатерін басқару - әрбір элементпен жұмысқа дайындық.

5. Қатерге рұқсат ету – қатердің элементтеріне рұқсат ету.

6. Қатерді бақылау – қатер элементтерін қадағалау динамикасы.

Бірінші үшеуі қатерді бағалауға, қалған үшеуі қатерді қадағалауға жатады.

Қатерден шығудың үш категориясы бар: жобалау қатері, техникалық қатер және коммерциялық қатер. Идентификациядан кейін программалық жобаға олардың әсерін бағалау керек. Бұл сұрақтар талдау қатерінде шешіледі. Қорытындысында, программалық жоболауда әрбір элементті басқару жоспары құрылады.

Негізгі әдебиет – 2 [ж.1, с. 37 – 106, Гл.2.с. 107 - 182],

7[81 – 102], 12 [315 – 343].

Бақылау сұрақтары:

1. ПО – ның төрт құрылымын атаңыз.

2. ПО – ның үрдістер моделдерін анықтаңыз.

3. Жобаны басқару дегеніміз не? Жобаны басқару неден тұрады?

4. Унифиялық үрдістің қандай құрылымы бар?

5. Унифиялық үрдісте қандай жұмыстық ағындар бар?

6. Унифициялық үрдісте қандай техникалық артефактілер бар?

7. Қатерді талдау және басқаруды жобалау не үшін керек?

14- Дәріс. Программалық жобаның бағасы / құны.

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

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

Жобаны орыдаудаға бағаның, құнның және мерзімнің қарапайым сұлбасы келесі түрде берілген:

1. Алдыңғы жұмыстардағы теңестірулерді қолданып, размерлі –бағытталған метриканың құнын және жобаның ұзақтылығын немесе кодтың жолдық санын бағалау үшін керек.

2. Немесе фнкционалды –бағытталған метрик әдісін қолданыңыз.

   0. Функционалды размердің жақындауын есептеңіз.

   1. Нақтылау үрдісін қолданыңыз.

3. Бағаның кодтық жолдық санын қолдану үшін, оның еңбек шығының және жобаның ұзақтылығын есептеу үшін СОСОМО формуласының көмегімен шығару.

Бағаның кодтық жолдық санының функционалдық размерін учетсіз қолдану.

Осындай баға рұқсат етілген фаза бойынша жобалаудың және кодтаудың алдында, немесе размерлі –бағыттталған метрикаға негіз болады.

Размерлі –бағытталған метрика программалық өнім және соның өңдеу үрдісін төте өлшейді. Метрика LOC- бағасына (Lines of Code) негізделген.

LOC- бағасы – бұл өндірілетін аналогтық жобаның жолдық программалық өнімдегі саны. LOC –метриктің шығыс деректері келесі кестеде берілген:

Жоба	Шығын, чел-мес	Құны, тыс.$	KLoc,тыс. Loc	Прог.док-ты страниц	Қателік	Адамдар
PR-1 PR-2	24 62	168 440	12,1 27,2	365 1224	29 86	3 5

Кесте жобаның кейінгі жылдардағы деректерінен тұрады. Мысалы, PR-2 жобасының көрсетуі бойынша: 24-адам көмегімен 12100 жолдық программа өңделіп, оның құны $168000 болған. Сондай –ақ PR-1 жобасында 365 беттік документ өңделіп, соның ішінде бірінші жылдық эксплуатация кезінде 29 қате тіркелген.

Кестенің негізінде размерлі –бағытталған метриканың сапасы және өнімділігі есептеледі(әрбір жоба үшін) :

өнімділік = Ұзындық [тыс.LOC

Шығын Чел.-мес]

сапа = Қате [бірлік

Ұзындық тыс.LOC]

салыстырмалы_құны = Құн [тыс.$

Ұзындық тыс.LOC]

құжаттандырылған = Документ беті [бет

Ұзындық тыс.LOC]

Размерлі-бағытталған метриктің ерекшелігі:

• кең танымалдығы.

• Жеңіл және тез есептелінуі.

Размерлі бағытталған метриктің кемшілігі:

• программалық тілдерден тәуелділігі.

• Шығыс деректерді алу қиын, өйткені оның жобадағы бастапқы стадиясын алу қиынға түседі.

• Программалық тілдердің процедураларына бейімделмеген.

сапа= [ ]

салыстырмалы құн = [ ]

құжаттандырылған = [ ]

Функционалды- бағытталған метрактың артықшылықтары:

• программалау тіліне тәуелді емес;

• проекттің кез келген сатысында оңай есептелінеді;

Метрактың кемшілігі болып оның нәтижесінің субъективтік деректерге негізделгендігі және тура емес, жанама өлшемдердің қолданылуы табылады.