КдСІБИ        БІЛІМ        БЕРУ

«Білім беруді дамытуды7і федералды институты» федералдъщ мемлекеттік мекемесі орта касіптік білім беру багдарламаларът іске асыратът білім беру мекемелеріне оку К 1Jралы ретінде

1JСЫ1іЪlЛШ1і.

«Академия» баспа орталыrы Маскеу

Санкт-Петербург электроника мектебінің (колледжінің) оқу- әдістемелік жұмыстары

Рудаков А. В.

Бағдарламалық өнімдерді  дайындау  технологиясы: орта кәсіби білім беру мекемелерінің студенттеріне арналған оқулық / Рудаков А.В. — 10-шы бас., қайта әзір. және тол. — М. : «Академия» баспа орталығы, 2016. — 208 б.

Оқулық орта кәсіби білім берудің Федералды мемлекеттік стандарттарының талаптарына сәйкес: «Компьютерлік жүйелердегі бағдарламалау» ПМ.01 «Компьютерлік жүйелер үшін бағдарламалық жасақтаудың бағдарламалық модульдерін дайындау» және ПМ.03 «Бағдарламалық        модульдерді        біріктіруге        қатысу»        (МДК.03.01 «Бағдарламалық жасақтаманы дайындау технологиясы») мамандықтары бойынша құрастырылған. Оқулықта бағдарламалық өнімдерді дайындау технологиясының пайда болу тарихы, қазіргі жағдайы, ұйымдастыру қағидалары, жалпы ережелері мен болашағы қарастырылған.

Оқулық орта кәсіби білім беру мекемелерінің студенттеріне арналған.

ӘОЖ 681.3.06(075.32) КБЖ 32.973-018я723

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

© Рәсімдеу. «Академия» баспа орталығы, 2016

Аталған оқулық «Компьютерлік жүйелерде бағдарламалау» мамандығы бойынша оқу-әдістемелік кешеннің бөлігі болып табылады және «Компьютерлік жүйелер үшін бағдарламалық жасақтаудың бағдарламалық модульдерін дайындаудың», «Бағдарламалық модульдерді біріктіруге қатысудың», (МДК.03.01 Бағдарламалық жасақтаманы дайындау технологиясының» кәсіби модульдерін игеруге арналған.

Жаңа буындағы оқу-әдістемелік кешендерге дәстүрлі және инновациялық материалдар жатады, олар жалпы білім беру және жалпы кәсіби пәндерді, кәсіби модульдерді игеруді қамтамасыз етеді. Әрбір кешен жалпы және кәсіби құзіреттіліктерді алуға қажетті және жұмыс берушінің талаптарына сәйкес оқулықтардан, оқу құралдарынан, оқыту және бақылау құралдарынан тұрады. Оқу баспалары электронды білім беру ресурстарымен толық- тырылады. Электронды ресурстар интерактивті жаттығулары және жаттықтырушылары, мультимедиялық объектілері, қосымша материалдарға сілтемелері, ғаламтор ресурстары бар тәжірибелік және теориялық модульдерден тұрады. Оларға оқу үрдісінің негізгі параметрлері бекітілетін терминологиялық сөздік және электронды журнал, жұмыс уақыты, бақылау және тәжірибелік жұмыстарын орындау нәтижелері кіреді. Электронды ресурстар оқу үрдісіне оңай кірістіріледі және әртүрлі оқу бағдарламаларына бейімделуі мүмкін.

Заманауи қоғамды компьютерсіз елестету мүмкін емес. Олардың біздің өмірімізге терең енгендігі соншалық, компьютерлер қолданылмайтын адамның қызмет ету саласын атау өте қиын. Осыған байланысты заманауи компьютерлердің аппараттық бөлігіне және қолданылатын бағдарламалық жасақтамаға жоғары талаптар қойылады. Негізінен бағдарламалық жасақтама немесе басқа сөзбен айтқанда бағдарламалық өнімдер компьютерді кеңінен пайдалану мүмкіндігін қамтамасыз етеді. Компьютердің бағдарламалық жасақтамасын қайта орнатсақ немесе жаңа бадарламалық өнімді орнатсақ біз осы компьютердегі жаңа тапсырмаларды орындай аламыз. Пайдаланылатын бағдарламалық өнімдер компьютердің сенімділігін және пайдаланушы жұмысының ыңғайлылығын қамтамасыз ететін белгілі критерийлерге сай болулары керек. Алдымен компьютер аппаратурасы, тіпті ең қарапайым құраушылар дайындалды және бекітілген технологиялық үрдістерге сәйкес шығарылды, бағдарламалық өнімдерді дайындаудың белгілі бір технологиясы алғашқы кезде болған жоқ. Дайындаушылар өздерінің жеке тәжірибелеріне сүйенді, ол үшін дайындаудың майдагерлік тәсілдері қолданылады. Мұндай тәсіл бағдарламалық өнімдердің сапасында, дайындау мерзімдерінде, олардың бағасында көрініс тапты. Аталған жағдай бағдарламалау дағдарысы деп аталды. Дағдарыстан шығу үшін бағдарламалық өнімдерді дайындаудың индустриалды тәсілдерін құру қажет болды, яғни, алдыңғы қатарлы инженерлі әдістерден және бағдарламалық өнімдерді құру құралдарынан тұратын дайындау технологияларын құру. Кейінірек бұл әдістер «бағдарламалық инженерия» деген түсінікпен біріктірілді (software engіneerіng). Пайдалануды бағалау жүйесінің жиынтығында бағдарламалық өнімдерді дайындауда аталған технологияны құру бағдарламалық жасақтамалардың сенімділігін, оларды дайындау сапасын арттырды және құрастырушыларға қажетті бағдарламалық өнімді таңдауды жеңілдетті.

Бағдарламалық өнім (БӨ) компьютерлік бағдарламалар, процедуралар және олармен байланысты құжаттар мен деректердің жиынтығын құрайды.

Бағдарламалық өнімнің өміршеңдік циклы

БӨ-ді құру кезінде орындалуы тиіс БӨ-нің өміршеңдік циклының құрылымы, үрдістер құрамы, әрекеттер мен тапсырмалар ІSO/ІEC 12207 халықаралық стандартын анықтайды және реттейді:1995 «Іnformatіon Technology — Software Lіfe Cycle Processes» (ІSO — Іnternatіonal Organіzatіon for Standartіzatіon — Халықаралық стандарттау ұйымы; ІEC

Үрдіс дегеніміз - келген деректерді шығыс деректеріне түрлендіретін өзара байланысқан әрекеттер жиынтығы. Әрбір үрдіс белгілі тапсырмалармен және оларды шешу әдістерімен, сонымен бірге басқа үрдістерден алынатын бастапқы деректермен, нәтижелермен сипатталады. Әрбір үрдіс әрекеттер жинағына, әрбір әрекет тапсырмалар жинағына бөлінеді. Үрдісті іске қосу және орындау, әрекеттер немесе тапсырмалар басқа үрдістермен жүзеге асырылады. Ресейде 1970 жылдардан бастап БӨ-ді құру БҚБЖ стандарттарымен реттелген болатын (Бағдарламалық құжаттаманың бірыңғай жүйесі – МЕМСТ 19.XXX), олар жеке бағдарламашылармен құрылатын шағын көлемдегі қарапайым бағдарламаларға бағытталған. Қазіргі таңда аталған стандарттар формасы және тұжырымдамалық негізі бойынша ескірді және олардың қызмет ету мерзімдері аяқталды, бұл стандарттарды ары қарай пайдаланудың қажеті қалған жоқ. Әрбір маңызды жоба үшін нақты қолданбалы БӨ-ді құру үрдістерін реттейтін нормативті және әдістемелік құжаттар жиынтығын  құруға  тура келеді, сондықтан отандық дайындамаларда заманауи

халықаралық стандарттарды пайдаланған дұрыс.

ІSO/ІEC 12207 стандарттарына сәйкес, БӨ-нің өміршеңдік циклының барлық үрдістері үш негізгі топқа бөлінген: негізгі үрдістер, қосымша (қолдаушы) үрдістер, ұйымдастыру үрдістері Негізгі үрдістерге БӨ-нің өміршеңдік циклында орындалуы тиіс нақты әрекеттер жинағы және олармен байланысты тапсырмалар жатады. Негізгілеріне алу, жеткізу, дайындау, пайдалану және сүйемелдеу үрдістері жатады.

Өнімді алу үрдістері (

acquіsіtіon process ) БӨ-ді алу бойынша тапсырыс беруші әрекеттерінен тұрады. Бұл әрекеттерге келесілер жатады:

Алынғандарға бастамашылық ету келесі тапсырмалардан тұрады:

Нормативті құжаттарға сәйкес «жүйе» түсінігін екі түрлі түсіндіруге болады. Бірінші жағдайда жүйе ретінде аппаратты, бағдарламалық, материалды және адами ресурстар, қызметтер мен деректер, бір сөзбен айтқанда дайындау немесе сатып алуға қажетті заттар жиынтығы қарастырылады. Екінші жағдайда жүйе дегеніміз – бұл бірігіп қызмет ететін шекті өнімдер мен дайындау, жеткізу, игеруге қажетті қосымша өнімдер жиынтығы.

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

аудит және бірігіп бағалау үрдістерінде қарастырылатын әрекеттерге сәйкес жүзеге асырылады (1.3 бөлімді қараңыз).

Жеткізу үрдісі (supply process) тапсырыс берушіні БӨ-мен немесе қызметпен жабдықтау кезінде жеткізушінің әрекеттері мен тапсырмаларын қамтиды. Бұл әрекеттерге төмендегілер жатады:

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

Өтінімдік ұсыныстарға жауап дайындау жеткізуге бастамашылық ету нәтижесінде қабылданған шешімдерге сәйкес орындалады.

келісімшартқа отырғаннан кейін орындалады, олар төмендегідей тапсырмалардан тұрады: шектеу, дайындау орталарына және ресурстарына талаптар қою, қосалқы мердігерлерді басқару және т.б. Қосалқы мердігер – бұл тапсырыс берушінің шарты бойынша жеткізуші орындауы тиіс жұмыстың бір бөлігін орындау бойынша жеткізушімен келісімшартқа отыратын корпорация, жеке тұлға немесе ұйым.

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

Тексеру және бағалау бірігіп бағалау және аудит үрдістерінде қарастырылған әрекеттерге сәйкес орындалады (1.3 бөлімді қараңыз).

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

Дайындау үрдісі (

development process ) Бұл дайындаушының тапсырмалары мен әрекеттерінен қамтиды және келесі жұмыс бағыттарын қарастырады:

operatіon process ) оператор тапсырмалары атқару барысын қамтиды - дайындалған БӨ немесе жүйені пайдаланумен айналысатын ұйым әрекеттері. Бұл әрекеттерге мыналар жатады:

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

БӨ-ді пайдалану үрдісінде қателерді анықтау кезінде көмек және кеңес беруден тұрады.

Сүйемелдеу үрдісі (

maіntenance process )

сүйемелдеуші ұйымның (сүйемелдеу қызметтері) тапсырмалары мен

әрекеттерінен тұрады.

Аталған үрдіс тиісті құжаттамада және пайда болған мәселелермен немесе БӨ-нің бейімделуін жаңартудағы қажеттіліктермен шақырылатын БӨ-нің өзгеруінде (түрле- нуінде) орындалады. ІEEE-90 стандартына сәйкес, (ІEEE — Іnstіtute of Electrіcal and Electronіcs Engіneers — Электротехника және электроника бойынша инженерлер институты) сүйемелдеу ретінде БӨ-ге қателерді түзету, өнімділікті арттыру, жұмыстың өзгерген шарттарына бейімдеу шарттарында БӨ-ге өзгерістер енгізу жатады. Сүйемелдеу үрдісі толығырақ 11-ші бөлімде қарастырылады. Қосымша (қолдаушы) үрдістердің негізгі мақсатына  сенімді, тапсырыс берушінің талаптарын шартпен белгіленген мерзімде толығымен қанағаттандыратын бағдарламалық өнімді құру жатады. Қосымша үрдістерге құжаттау үрдістері, конфигурацияны басқару, сапаны қамтамасыз ету, анықтау, аттестаттау, бірігіп бағалау, аудит, мәселелерді шешу жатады.

Құжаттау үрдісі (

documentatіon process ) БӨ-нің өміршеңдік циклында құрылған ақпаратты нысандандырылған сипаттауды қарастырады. Аталған үрдіс жобалауды, жоспарлауды, дайындауды, шығаруды, түзетуды, таратуды орындайтын әрекеттер жинағынан тұрады және басшылық, техникалық мамандар, жүйе пайдаланушылары сияқты мүдделі тұлғаларға қажетті құжаттарды ұсынып сүйемелдейді.

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

Жобалау және дайындау БӨ жұмысының үрдісінде орындалады және оның өміршеңдік циклын бір уақытта орындаумен аяқталады.

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

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

Конфигурацияны басқару үрдісі (confіguratіon management process) БӨ-нің өміршеңдік циклындағы әкімшілік және техникалық процедураларды пайдаланудан тұрады және

дегеніміз – жүзеге асырылған БӨ-де және техникалық құжаттамада бекітілген функционалды және физикалық сипаттамалар жиынтығы. Конфигурацияны  басқару өміршеңдік циклдың барлық кезеңдерінде БӨ-ге өзгерістерді енгізуді басқаруға, оларды жүйелік есепке алуға, ұйымдастыруға мүмкіндік береді. БӨ конфигурациясын басқару бойынша жалпы қағидалар мен нұсқаулықтар ІSO/ІEC CD 12207-2: 1995 стандартында қарастырылады: «Іnformatіon Technology — Software Lіfe Cycle Processes. Part 2. Confіguratіon Management for Software» («Ақпараттық технологиялар — Бағдарламалардың өміршеңдік циклының үрдістері. 2.Бөлім Бағдарлама конфигурациясын басқару»).

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

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

Конфигурация қалпының есебі БӨ құраушыларының күйін тіркеуден, БӨ құраушылар нұсқаларының қайтарылған және орындалған түрленулері туралы есептерді  дайындаудан тұрады. Есеп жиынтығы жүйенің және оның құраушыларының

ағымдағы        жағдайы        туралы        көріністен,        сонымен        қатар түрлендіру тарихын жүргізуден тұрады.

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

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

Сапаны қамтамасыз ету үрдісі (qualіty assurance process) БӨ және оның өміршеңдік циклы үрдістерінің бекітілген талаптарға және жоспарға сәйкестігін кепілдендіруді қамтамасыз етеді. БӨ сапасы дегеніміз – БӨ-нің бекітілген талаптарды қамтамасыз ету қабілетін сипаттайтын қасиеттер жиынтығы. Құрылған БӨ дұрыс бағалау үшін сапаны бағалау үрдісі БӨ- ді дайындаушы субъектілерге тәуелсіз орындалуы тиіс. Басқа тексеру, аттестаттау, бірігіп бағалау, аудит және мәселелерді шешу сияқты қосымша үрдістер нәтижелері қолданылуы мүмкін.

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

Үрдіс сапасын қамтамасыз ету БӨ өміршеңдік циклы үрдістерінің сәйкестігін, дайындау әдістерінің, дайындау және қызметкер квалификациясы құралдарының келісімшарттағы стандарттар мен үрдістерге сәйкестігін кепілдендіруден тұрады.

verіfіcatіon process ) кейбір әрекеттер нәтижелері болып табылатын БӨ алдыңғы әрекеттерге тәуелді талаптар мен шарттарды толығымен қанағаттандырады. Тексеру орындаушының өзімен немесе осы ұйымдағы басқа маманмен, сонымен қатар, үшінші ұйым маманымен жүргізілуі мүмкін. Бұл жерде тексеру тәуелділіктерінің түрлі деңгейлері туралы айтуға болатын көптеген түрлендірмелер қолданылуы мүмкін. Егер тексеру үрдісі жеткізушіге, дайындаушыға, операторға

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

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

Тексеру тар мағынада БӨ дайындығын ресми дәлелдеуді білдіреді. Аталған үрдіс талдаудан, бағалаудан және тестілеуден тұрады.

valіdatіon process ) құрылатын жүйеге немесе БӨ-ге қойылатын талаптар толықтығын, функционалды бағытталуын анықтаудан тұрады. Аттестаттау БӨ-ді тестілеу дұрыстығын бағалау және бекітуді білдіреді. Аттестаттау БӨ-нің сипаттамаларға, талаптарға және құжаттамаларға толық сәйкестігін кепілдендіруі керек, сонымен қатар пайдаланушымен сенімді және қауіпсіз қолданылу мүмкіндігін қарастырады. Аттестаттауды барлық мүмкін жағдайларда тестілеу арқылы және тәуелсіз мамандарды пайдалану арқылы орындау ұсынылады. Аттестаттау бағдарламалық өнімнің өміршеңдік циклының бастапқы кезеңдерінде жүргізілуі немесе бағдарламалық өнімді қабылдау бойынша жұмыс бөлігі ретінде орындалуы мүмін. Аттестаттау тексеру сияқты тәуелсіздіктің әртүрлі деңгейлерімен жүзеге асырылуы мүмкін. Егер        аттестаттау        үрдісі        жеткізушіге,        дайындаушыға,

операторға немесе сүйемелдеу қызметіне тәуелсіз ұйыммен орындалатын болса, онда ол тәуелсіз аттестаттау деп аталады.

басқа қосымша үрдістермен үйлестіруден, пайдаланылатын стандарттар, әдістер, процедуралар, құралдар есебімен аттестаттау үрдісін жоспарлаудан тұрады.

Аттестаттау құрылған БӨ-ге немесе жүйеге қойылатын талаптардың функционалды бағытталуына толық сәйкестігін анықтауға мүмкіндік береді.

Бірігіп бағалау үрдісі (joіnt revіew process) аталған жұмыстарды орындау кезінде құрылатын жоба және БӨ бойынша жұмыстар жағдайын бағалау үшін қолданылады. Ол негізінен ресурстарды, қызметкерлерді, аппаратураны және жобаның құралдарын басқару және жобалауды бақылаумен түсіндіріледі. Бағалау жобаны басқару деңгейінде, сонымен қатар техникалық орындау деңгейінде орындалады және келісімшарт мерзімі ішінде жүргізіледі. Аталған үрдіс шартқа қатысушы кез-келген екі тәсілмен орындалуы мүмкін, бір тарап екінші тарапты тексереді.

басқа қосымша үрдістермен үйлестіруден, пайдаланылатын стандарттар, әдістер, процедуралар, құралдар есебімен бағалау үрдісін жоспарлаудан тұрады.

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

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

Аудит үрдісі (

audіt process ) БӨ-ді құру бойынша жұмыстар орындау кезінде келісімшарт талаптарына, жоспарларына, талаптарына сәйкестігін анықтаудан тұрады. Аудит шартқа қатысушы кез-келген екі тәсілмен орындалуы мүмкін, бір тарап екінші тарапты тексереді. Аудит нақты жұмыстар мен есептердің жоспарларға, талаптарға және шартқа сәйкестігін анықтау үшін жүргізіледі. Аудиторлар (тексерушілер) БӨ дайындаушыларына тікелей тәуелді болмауы керек. Олар жұмыс жағдайын, ресурстарды пайдалануды, құжаттамалардың сипаттамалар мен стандарт- тарға сәйкестігін, жүргізілетін тестілеу дұрыстығын бағалайды.

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

Аудит

Мәселелерді шешу үрдісі (

problem resolutіon process ) дайындау, пайдалану, сүйемелдеу кезінде анықталған мәселелерді  шешуді және  талдауды және   пайда   болу  көзіне тәуелсіз басқа үрдістерді қарастырады (анықталған сәйкессіздіктерді қоса алғанда). Әрбір анықталған мәселе сәйкестендірілген, сипатталған, талданған және шешілген.

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

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

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

Басқару үрдісі (

management process ) өз үрдістерін басқарушы кез-келген тараппен орындалуы мүмкін әрекеттер мен тапсырмалардан тұрады. Аталған тарап (менеджер) өнімнің, жобаның шығуын басқаруға, өнімді алу, жеткізу, дайындау, пайдалану, сүйемелдеу сияқты тиісті үрдістер тапсырмаларына жауап береді.

менеджер басқаруға қажетті ресурстарды анықтауы қажет (персонал, құрылғы және технология), сонымен бірге, осы ресурстардың жеткілікті екеніне көз жеткізуі керек.

Жоспарлау келесі тапсырмаларды орындаудан тұрады: жұмыстарды орындау бойынша графиктер құру; қажетті ресурстарды бөлу; жауапкершілікті бөлу; нақты тапсырмалары бар тәуекелдерді бағалау; басқару инфрақұрылымын құру.

бағалау қажет. Тексеру және бағалау нәтижелері бойынша, қажет болған жағдайда түзетулер енгізілуі мүмкін.

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

Инфрақұрылымды құру үрдісі (

іnfrastructure  process ) БӨ-ді сүйемелдеу, пайдалану, дайындау үшін қолданылатын технологиялар, стандарттар мен құралдар, аппараттық және бағдарламалық құралдарды қолдау (сүйемелдеу) және таңдауды қамтиды. Инфрақұрылым тиісті үрдістерге қойылатын талаптар өзгерісіне сәйкес сүйемелденуі  және  түрленуі  қажет. Инфрақұрылым, өз кезегінде конфигурацияны басқару объектілерінің бірі болып табылады.

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

Инфрақұрылымды құру таңдалған тұжырымға және БӨ құру бойынша жұмыстарды орындауға арналған инфрақұрылымды құру жоспарына сәйкес дайындау бойынша барлық әрекеттер- ден тұрады.

Инфрақұрылымды сүйемелдеу БӨ-ді сүйемелдеу қажеттілігінен және өнімді өзгертілген талаптарға сәйкес түрлендіруден туындайды.

Жетілдіру үрдісі (

іmprovement process ) БӨ өміршеңдік циклы үрдістерін бақылау, бағалау, өлшеуді, жетілдіруді қарастырады. Аталған үрдіске жатады:

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

Үрдістерді бағалау БӨ дайындау оның күшті және әлсіз жақтарын анықтауға және алынған нәтижелер негізінде қажетті жақсартулар жүргізуге мүмкіндік береді.

БӨ өміршеңдік циклы үрдістерін жетілдіру барлық қаты- сушы мамандардың еңбек өнімділігін арттыруға бағытталады, ол қолданылатын технологияларды, басқару әдістерін, құралдарды таңдау, қызметкерді оқыту арқылы орындалады. Жетілдіру әрбір үрдістің артықшылықтары мен кемшіліктеріне негізделеді. Мұндай талдау көп жағдайда ұйымдағы жоба бойынша тарихи, техникалық, экономикалық және басқа ақпараттардың жиналуы әсер етеді.

Оқу үрдісі (

traіnіng process ) қызметкердің алғашқы оқытылуын және квалификациясының тұрақты көтерілуін қамтиды. Алу, жеткізу, дайындау, пайдалану жәнебағдарламалық өнімді айтарлықтай деңгейде сүйемелдеу қызметкердің білім деңгейіне және квалификациясына тәуелді болады. Мысалы, БӨ дайындаушылары бағдарламалық инженерияның әдістері мен құралдарына оқытудан өтуі керек. Оқу үрдісінің мазмұны жоба талаптарымен анықталады. Бұл үрдіс үшін қажетті ресурстар мен оқытудын техникалық құралдары жоспарлануы керек. Одан басқа, пайдаланушыларды оқу жоспарына сәйкес оқытуға қажетті әдістемелік материалдар дайындалып, ұсынылуы қажет.

басқа ұйымдық үрдістермен үйлестіруден және квалификацияны арттыру, оқыту жоспарын құру жұмыстарын жобалаудан тұрады.

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

ІSO/ІEC 12207 стандартымен реттелетін БӨ өміршеңдік циклының үрдістері нақты жобаларда әртүрлі ұйымдармен қолданылуы мүмкін. Одан басқа, стандарт әртүрлі көзқарас тұрғысынан немесе әртүрлі аспектілерде үрдістер арасындағы өзара байланыс жиынтығынан тұрады (шартты, басқару, пайдалану, инженерлі қолдау). Бұл 1.1 суретте көрсетілген. Штрихты тілшелер нақты үрдістері бар үрдістердің қызмет етуші тұлғалары арасындағы байланысты көрсетеді (тапсырыс беруші, жеткізуші), ал тұтас тілшелер - үрдістер және үрдістер тобы арасындағы байланыс.

Шартты аспектіде тапсырыс беруші және жеткізуші келісімшарттық қатынастарға түседі және алу және жеткізу үрдістерін жүзеге асырады.

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

дайындаушы немесе сүйемелдеу қызметі тиісті техникалық тапсырыстарды шешеді, БӨ-ді түрлендіріп, дайындайды.

қосымша үрдістерді орындайтын қызметтер барлық қызметкерлерге қажетті қызметтерді ұсынады. Қолдау аспектісі шеңберінде БӨ-нің сапасын басқару аспектісін бөліп қарастыруға болады. Ұйымдастыру үрдістері БӨ-нің өміршеңдік циклының қалған үрдістерін тұрақты жетілдіру және жүзеге асыруға арналған базаны құру арқылы корпоративті деңгейде орындалады. Үрдістер және оларды жүзеге асырушы ұйымдар (немесе тараптар) өзарафункционалды байланысқан. Ішкі құрылымжәне ұйым мәртебесі реттелмейді. Бір ұйым әртүрлі рөлдерді атқаруы мүмкін (жеткізуші, дайындаушы және т.б.) және керісінше, бір рөлді бірнеше ұйым орындауы мүмкін. Стандартта сипатталған үрдістер арасындағы өзара байланыс статикалық сипатқа ие. Тараптармен жүзеге асырылатын үрдістер арасындағы маңызды динамикалық байланыстар нақты жобаларда бекітіледі.

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

БАҒДАРЛАМАЛЫҚ ӨНІМДІ ҚҰРУ БОЙЫНША ЖҰМЫСТЫҢ НЕГІЗГІ КЕЗЕҢДЕРІ

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

БӨ-ді құру кезінде жұмыстың алты негізгі кезеңін бөлуге болады: БӨ        өміршеңдік        циклының        әрбір        кезеңіндегі        сипатты ұзақтылық 2.1 суретте көрсетілген.

Қарқындылық БӨ-ді құрудың алғашқы екі кезеңі бір уақытта басталады, бағдарламалық жобаны жоспарлау кезеңі (

) тапсырыс беруші талаптарын құру кезеңіне қарағанда (2) әрдайым ерте аяқталады. Осы екі кезеңде болашақ БӨ-ді құру бойынша жұмыстар мерзімі мен мазмұны анықталады. Бұл кезеңдердің ұзақтығы БӨ-нің жұмыс үрдісінде жұмыс жоспарына түзетулер, тіпті БӨ- ге талаптар қоюға алып келуі мүмкін.

Тестілеу кезеңі (5)

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

Бағдарламалық өнімді жобалау.

Жоспарлау кезеңінде дайындау үрдісінде орындалуы тиіс барлық негізгі тапсырмалар анықталады, қаржылық, адами,  техникалық  және техникалық емес ресурстар, дайындалатын БӨ-нің көлемдері мен қиындықтары бағаланады, тестілеу әдістері және БӨ-ді қабылдау критерийлері, жұмыстың әдістері мен технологиялары анықталады, жұмысты орындаудың уақытша графиктері құрылады.

Тапсырыс беруші талаптарын құру.

Осы кезең кезінде дайын- даушылар БӨ-нің талаптарын талдайды (ақпаратты жеткізу формасы, қажетті функциялар, қалаулы интерфейстер, тиісті шектеулер және т.б). Аталған кезең талаптардың белгісіздігін жою үшін, болашақ БӨ-ге қатысты барлық бөлшектерді анықтау және оларды анық түсіну үшін, оны тестілеу үшін, БӨ-ге қойылатын талаптарға қатысты дайындаушылар мен тапсырыс беруші арасындағы өзара түсіністікті құру үшін қолданылады. Талаптар БӨ-нің талаптар сипаттамасына сәйкестігін анықтайтын «ия» немесе «жоқ» жауабын беретін тестті дайындаушы анық тест құра алатындай тестілеуден өтеді. Тестілеу үшін сипаттама анық, бір мәнді болуы және мүмкіндігі бойынша сандық сипаттарға ие болуы керек.

Бағдарламалық өнімді жобалау.

Жобалау кезеңі дайындалатын БӨ-нің моделін өңдеу және анықтау үшін қолданылады. Мұндай модель БӨ-нің құрылымын, деректер мен интерфейстер, модульдердің ұйымдастырылуын және жүзеге асырудың кезекті кезеңіне қажетті сипатты анықтайды. Жобалау кезеңі жобалау кешендерінің жиынтығын ұсынуы мүмкін, олардың әрқайсы үшін қасиеттер жинағы және басқа кешендермен байланыстары анықталады. Жобалау үрдісі жоба жоспарында анықталған тәсілдер мен технологияларға сәйкес орындалуы керек. Жобалау екі бөлімнен тұруы мүмкін: жоғары деңгейлі және төмен деңгейлі (егжей-тегжейлі) жобалау.

Бағдарламалық өнімді дайындау.

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

стандарттарына сәйкес түрлендіреді. Дайындаушылар тестілеу бойынша тиісті шарттарды құру үшін БӨ тестілеу үшін инженермен өзара әрекеттеседі. Одан басқа, дайындаушылар техникалық құжаттаманы құру бойынша жұмыстар жүргізеді және БӨ-ді біріктіруді орындау және жоспарлауды бастайды.

Бағдарламалық өнімді тестілеу.

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

Бағдарламалық өнімді сүйемелдеу.

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

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

БАҒДАРЛАМАЛЫҚ ӨНІМДІ ДАЙЫНДАУДЫҢ ӨМІШЕҢДІК ЦИКЛЫНЫҢ МОДЕЛЬДЕРІ 3.1. Бағдарламалық өнімді дайындаудың өміршеңдік циклының модельдері түсінігі.

Бар модельдерді шолу.

БӨ-ді дайындаудың өміршеңдік циклының моделіне үрдістердің орындалу кезектілігін және өзара байланысын, БӨ дайындаудың өміршеңдік циклында орындалатын әрекеттер мен тапсырмаларды анықтайтын құрылым жатады. Өмрлік цикл моделі орындалатын жобаның сипатына және күрделілігіне, сонымен қатар, БӨ қызмет ететін шарттарға тәуелді болады. ІSO/ІEC 12207 стандарты өміршеңдік циклдың нақты модельдерін және БӨ-ді дайындау әдістерін ұсынбайды. Стандарт ережелері өміршеңдік циклдың, БӨ дайындау технологиялары мен әдістерінің кез-келген моделі үшін ортақ болып табылады. Стандарт БӨ-нің өміршеңдік циклы үрдістерінің құрылымын сипаттайды, бірақ осы үрдістерге жататын әрекеттер мен тапсырмаларды қалай орындау керек екенін анықтамайды. Кез-келген нақты БӨ-нің өміршеңдік циклының моделі оны құру үрдісінің сипатын анықтайды, ол тиісті талаптарға сәйкес келетін БӨ-ді құруға қажетті өзара байланысқан және біріккен жұмыс кезеңдерін, уақыт бойынша реттелген жиынтықты ұсынады. БӨ-ді дайындау кезеңіне БӨ-ді құру үрдісі жатады, бұр үрдіс кейбір шектеулермен шектеледі және аталған кезең үшін бекітілген талаптармен анықталған нақты өнімді шығарумен аяқталады (БӨ модельдерін, бағдарламалық кешендерді, құжаттамаларды). БӨ-ді құру кезеңдері рационалды жоспарлау, бекітілген нәтижелермен аяталатын жұмыстарды ұйымдастыру түсінігі бойынша бөлінеді (2 бөлімді қараңыз). БӨ-ді дайындаудың өміршеңдік циклының кең тараған модельдеріне келесілер жатады:

(RAD — Rapіd Applіcatіon Development model);

Каскадты модель Түзу сызықты және пайдалануда қарапайым. Жұмысты тұрақты қатаң тексеруді қажет е Дайындалатын бағдарламалық жасақтамаға өзгерістер енгізілмейді.

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

Прототиптеу моделі Шекті талаптарды құрғанға дейін «тез» ішінара орындау құрылады. Жобаны орындау үрдісінде пайдаланушы мен дайындаушы арасында кері байланыс қамтамасыз етіледі. Пайдаланылатын талаптар толық емес.

Жобалық топтар шағын (3....7 адам) және жоғары квалификацияланған мамандардан құралған. Дайындау циклының мерзімі қысқартылған (3 айға дейін) және өнімділігі жақсарылған. Кодты қайта пайдалану және дайындау үрдісін автоматтандыру.

Көп өтпелі модель Жұмыс жүйесі тез құрылады. Дайындау үрдісіне өзгеріс енгізу мүмкіндігі азаяды. Ағымдық ішінара орындау кезінде ағымдағыдан жаңа нұсқаға өту мүмкін емес.

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

Пайдаланушылар БӨ-мен прототиптердің арқасында ерте кезеңде танысады.

1970 және 1980 жылдардағы біртекті ақпараттық жүйелерде қолданбалы БӨ біртұтас болды. БӨ-нің мұндай түрін дайындау үшін каскадты модель немесе «сарқырама» (waterfall) (сурет 3.1) қолданылған болатын. Каскадты тәсілдің қағидалы ерекшелігі: келесі кезеңге өту ағымдағы кезеңдегі жұмыс толығымен аяқталғаннан кейін жү- зеге асырылады, өткізілген кезеңдерге қайту қарастырылмайды. Әрбір кезең келесі кезеңге бастапқы деректер ретінде қызмет ететін кейбір нәтижелерді алумен аяталады. Талаптарды құру кезеңінде анықталатын дайындалатын БӨ-ге қойылатын талаптар техникалық тапсырма ретінде қатаң құжатталады және жобаның дайындалу мерзімінде бекітіледі. Әрбір кезең құжаттаманың толық кешенін шығарумен аяқталады, бұл құжаттама дайындаушылардың басқа тобымен дайындаманың жалғасуы үшін жеткілікті болып табылады. Мұндай тәсілде дайындама сапасының талаптарына техникалық тапсырма сипаттамасын орындау дәлдігі жатады. Дайындаушылардың негізгі назары дайындалатын БӨ-нің техникалық сипаттамаларының оңтайлы мәндеріне қол жеткізуге бағытталады - өнімділігіне, толтырылатын жад көлеміне және басқаларға. Каскадты тәсілдің артықшылықтары:

Бағдарламалық өнімге талаптар қою

прототиптеу

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

прототиптеу

дайындау

Сурет 3.2. Бағдарламалық өнімді дайындаудың нақты үрдісінің сызбасы Бұл категорияға есептеу сипатындағы                тапсырмалары көп күрделі жүйелер, нақты уақыт жүйелері және т.б жатады. Сонымен бірге, аталған тәсіл айтарлықтай кемшіліктерден тұрады: ең алдымен БӨ-ді дайындаудың нақты үрдісі ешқашан        мұндай қатаң сызбада болмайды. Бұл үрдіс итерациялық сипатқа ие: кезекті кезең нәтижелері ерте кезеңде орындалған жобалық шешімдерде өзгерістер тудырады. Осылайша, өткен кезеңдерге қайту және бұрын қабылданған шешімдерді

3.2 суретте кескінделген сызбаны көбінесе аралық бақылауы бар модельге жатқызады, мұнда аралық түзетулер каскадты модельге қарағанда дайындаудың барлық кезеңін арттырғанымен, үлкен сенімділікті қамтамасыз етеді. Каскадты тәсілдің негізгі кемшіліктеріне нәтижелерді алудың  айтарлықтай   кешігуі,    пайдаланушылардың өзгерген қажеттіліктерін қанағаттадырмайтын жүйені құру тәуекелділігінің жоғары болуы жатады. Тәжірибе көрсеткендей, жобаның бастапқы кезеңінде барлық талаптарды нақты дәне толығымен болашақ жүйеге қалыптастыру мүмкін емес. Бұл келесі себептермен түсіндіріледі: Каскадты тәсіл шеңберінде БӨ-ге қойылатын  талаптар  құру  кезінде  техникалық  тапсырмалар  түрінде   бекітіледі,  ал алынған нәтижелерді  пайдаланушылармен  растау  тек әрбір кезеңді аяқтағаннан кейін орындалады (сонымен бірге техникалық тапсырмада көрсетілген талаптарды қозғамаса, пайдаланушылардың ескертулері бойынша түзетулер енгізілуі мүмкін). Сонымен, пайдаланушылар жүйе жұмысы толығымен аяқталғаннан кейін, айтарлықтай ескертулер енгізулері мүмкін. Талаптарды анық емес жеткізуде немесе БӨ-ді құрудың ұзақ мерзімінде өзгерістер енгізуде пайдаланушылар олардың қажеттіліктерін қанағаттандырмайтын жүйені қолданады. Нәтижесінде осы жағдайды аңғаратын жаңа жоба бастауға тура келеді.

Бұл модель (сурет 3.3) каскадты модельдің өзге түрі ретінде дайындалды, бұл жерде ерекше көңіл БӨ-ді тексеруге және аттестаттауға бөлінеді. Модель, көрсеткендей, өнімді тестілеу дайындаудың өміршеңдік циклының ерте кезеңінен бастап талқыланады, жобаланады, жоспарланады (3.3 суретте бұл үрдіс штрихты тілшелермен бейнеленген). Каскадты модельден V-образды модель тізбекті құрылымды алды, ол арқылы әрбір тізбекті фаза алдыңғы фазаны сәтті аяқтағаннан кейін ғана басталады. Аталған модель мәселені жүйелік тәсілмен шешуге бағытталады, оның шешімі төрт қадаммен анықталады: талдау, жобалау, дайындау және шолу. Талдау жүргізу кезінде жобаны жоспарлау, талаптарды құру жүзеге асырылады. Жобалау жоғары деңгейлі және егжей-тегжейлі (төмендеңгейлі) болып бөлінеді. Дайындау кодтаудан тұрады, ал шолу тестілеудің әртүрлі типтерінен тұрады. Модельде кодтау мен тестілеуден бұрын болатын талдау фазалары мен жобалау фазалары арасындағы өзара байланыс жақсы көрсетіледі.

жоғары деңгейлі жобалау

модульді тестілеу

интеграциялық тестілеу

жүйелік тестілеу

пайдалану және сүйемелдеу

У-образды модель артықшылықтары мынадай:

Аталған модельді басты талабы жоғары сенімділік болып табылатын бағдарламалық өнімдерді дайындауда қолдану қажет. Прототиптеу моделі (сурет  3.4)  БӨ-нің  прототипін  БӨ-  нің талаптарын құру кезеңінде немесе кезеңіне дейін қалыптастыруға мүмкіндік береді. Әлеуетті пайдаланушылар осы прототиппен оның әлсіз және күшті жақтарын анықтайды, нәтижелерді БӨ дайындаушыларына жеткізеді. Осылайша, пайдаланушы мен дайындаушылар арасындағы кері байланыс қамтамасыз етіледі.

ы

қиыстыру

Сурет. 3.4. Прототиптеу моделі

Бұл БӨ талаптарының сипаттамасын түзету немесе өзгерту үшін қолданылады. Осындай жұмыс нәтижесінде өнім пайдаланушының нақты қажеттіліктерін көрсететін болады. БӨ дайындаудың өміршеңдік циклы жобаны дайындаудан басталады (3.4 суретте жоспарлау кезеңіне эллипс ортасы сәйкес келеді), одан кейін тез талдау жүргізіледі, деректер базасы құрылады (әрине гер ол БӨ-де қолданылса), пайдаланушылық интерфейсі құрылып, тиісті функцияларды дайындау орындалады. Осындай жұмыс нәтижесінде БӨ талаптарының жеке сипаттамасынан тұратын құжат пайда болады. Аталған құжат ары қарай тез прототиптеудің итерациялық циклына негіз болады. Прототиптеу нәтижесінде дайындаушы пайдаланушыларға дайын прототипті көрсетеді, ал  пайдаланушылар  оның қызмет етуін бағалайды. Одан кейін пайдаланушылар мен дайындаушылар  бірігіп  жоятын   мәселелер   анықталады.  Бұл үрдіс пайдаланушылардың қажеттіліктері БӨ сәйкестік деңгейімен қанағаттандырылғанша жалғаса  береді.  Одан кейін прототип пайдаланушыларға жетілдіру ұсыныстарын алу мақсатында көрсетеді, олар жұмыс моделі қанағаттанарлық болғанға  дейін  тізбекті  итерацияларға  қосылады.   Одан кейін пайдаланушылардан прототиптің функционалды мүмкіндіктерінің ресми мақұлдауын алады (бекіту) және оны дайын БӨ-ге айналдырады.

Прототип моделі төмендегідей артықшылықтарға ие:

Аталған артықшылықтардан басқа, прототиптеу модельдері келесідей кемшіліктерге ие:

Прототиптеу моделін келесідей жағдайларда пайдалану ұсынылады:

RAD –моделінде (сурет 3.5) шекті пайдаланушы негізгі рөлді атқарады. Дайындаушылармен тар өзара әрекеттестікте ол талаптар қалыптастыруға және оларды жұмыс прототиптерінде анықтауға қатысады. Осылайша, өміршеңдік циклдың басында шекті пайдаланушы жұмыстың көп бөлігін алады, бірақ осының нәтижесінде құрылатын жүйе тез қалыптасатын болады. Дайындаудың дәстүрлі өміршеңдік циклында жұмыстың көп бөлігін бағдарламалау және тестілеу алады. Бағдарламалауды автоматтандыруда және RAD-модельдерінде қолданылатын кодты қайта пайдалануда жұмыстың көп бөлігін жоспарлау мен жобалау алады. RAD моделінің қағидасымен түсіндірілетін 3.5 суретте дайындау үрдісінің кезеңдері және тапсырыс берушілердің қатысуы көрсетіледі (штрихтық сызық).

пайдаланушының сипаты

құру

Сүйемелдеу

Қарастырылатын RAD-модельді БӨ-ді дайындау кезінде пайдалануға болады, БӨ талаптары белгілі болса, олар модельдеуге жақсы қолданылады, ал тапсырыс беруші дайындау үрдісіне тікелей қатысады.

3.5. Көп өтпелі модель Көп өтпелі модель (сурет 3.6) — бұл әрбір кезекті итерацияға жаңа  функционалды  мүмкіндіктерді  қосу  арқылы   немесе БӨ –нің тиімділігін арттыру арқылы БӨ-нің прототипін құру үрдісінің бірнеше итерациясы. Дайындаудың өміршеңдік циклының ерте кезеңдерінде (жоспарлау, талаптарды талдау және жобаны дамыту) БӨ-ді құрастыруорындалады. Қажетті инкременттер саныжәнеоларға тиісті функциялар анықталады. Әрбір инкремент өміршеңдік циклдың қалған фазалары арқылы өтеді (кодтау және тестілеу). Алдымен БӨ-нің негізін құрайтын базалық функцияларды орындау және тестілеу, құрастыру орындалады. Одан кейінгі итерациялар БӨ-нің функционалды мүмкіндіктерін жақсартуға бағытталады. Көп өтпелі модельдің артықшылықтары:

г

Сурет 3.6. Көп өтпелі модель

Көп өтпелі модельдің кемшіліктері:

Егер БӨ талаптары алдын-ала қалыптасатын болса көп өтпелі модель қолданылады, жобаны орындау үшін уақыттың үлкен мерзімі бөлінеді. Көп өтпелі модельді пайдаланумен байланысты мәселелерді шешу үшін 1980 жылдардың ортасында өміршеңдік циклдың спиральді моделі ұсынылды (сурет 3.7). Оның қағидалы ерекшелігі қолданбалы БӨ бірден құрылмайды, каскадты тәсілдегі сияқты прототиптеу әдісін пайдалану арқылы бөлшектеп құрылады. Прототип ретінде жеке функцияларды орындайтын бағдарламалық кешен және дайындалатын БӨ- нің сыртқы интерфейстері қарастырылады. Прототиптерді құру бірнеше итерациялармен немесе спираль орамдарымен жүзеге асырылады. Әрбір итерация фрагмент құруға немесе БӨ нұсқасына сәйкес келеді, онда жобаның мақсаты мен сипаттары анықталады, алынған нәтижелер сапасы бағаланады және келесі итерация жұмысы жоспарланады. Әрбір итерацияда тағы бір итерацияның орындалу қажеттілігін анықтау мақсатында мерзімді және жоба құнын, толықтың деңгейін және жүйе талаптарын түсіну дәлдігін арттыру тәуекелін егжей-тегжейлі бағалау орындалады, сонымен бірге жобаны тоқтату жөнділігі қарастырылады. Спиральді модель пайдаланушылар мен дайындаушыларды бастапқы  кезеңде  жүйе  талаптарын  толық және нақты қалыптастырудан арылтады, себебі олар әрбір итерацияда анықталады. Осылайша, жоба бөлшектері тереңдетіледі және тізбекті нақтыланады және нәтижесінде жүзеге асырылатын негізгі нұсқа таңдалады. Итерациялармен дайындау жүйені құрудың спиральді циклын объективті  көрсетеді,  келесі  кезеңге  жұмыстың толық аяқталуын күтпей-ақ өтуге мүмкіндік береді, себебі итеративті тәсілде жетіспей тұрған жұмысты келесі итерацияда орындауға болады. Мұндай дайындаманың басты мақсаты - пайдаланушыларға жұмысқа қабілетті өнімді тезірек көрсету, сонымен бірге, талаптарды анықтау және толықтыру үрдісін белсендіру. Егер жүйе талаптары толығымен анықталған болса, спиральді модель жобаның қорытынды кезеңдерінде каскадты тәсілді қолданады. Спиральді циклдың басты мәселесі – келесі кезеңге өту сәтін анықтау. Оны шешу үшін өміршеңдік циклдың әрбір кезеңіне уақыт шектеулерін енгізу қажет.

Мақсаттарды,баламалар мен шектеулерді анықтау

Тәуекелдер талдауы

Тәуекелдер талдауы

Баламаларды бағалау,тәуекелдерді анықтау және шешу

Бастау Талаптар құру жоспар

Құрастыру жоспары

концеп-        Талаптарды        Құрастыру        Егжей-тегжейлі циясы                құру                        жобалау

Интеграция және тестілеу

Интеграцияланған Қабылданған        тестілеу тестілеу

Келесі интеграцияны

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

Егер келесі себептердің кемінде біреуі болса, спиральді модельді пайдаланған абзал:

БӨ талаптарын     БӨ құру жұмыс-        БӨ дайындау         құрастыру тарын жоспарлау        БӨ тестілеу

БӨ сүйемелдеу

БӨ тексеру

Сурет 3.8. Қосымша үрдістері көрсетілген жақсартылған спиральді модель

3.8 суретте көрсетілгендей, БӨ-ді құру үрдісі қолдаушы үрдістерге негізделеді: БӨ-ді тексеру; конфигурацияны басқару; сапаны қамтамасыз ету. Қолдаушы үрдістердің негізгі мақсаты – қысқа мерзімде тапсырысберушініңқажеттілігінтолығыменқанағаттандыратын, сенімді бағдарламалық өнімді құру.

Бағдарламалық   өнімді   тексеру.

БӨ-ді   тексерудің басты мақсаты – дайындалатын өнімнің сапасын және дайындаушылардың өнімділігін арттыру. Тексерудің әртүрлі түрлері дайындаушыларға БӨ-ді құру бойынша жұмыс кезеңдерінде ақаулықтарды анықтауға көмектеседі. Одан  басқа, тексеру бойынша іс-шараларды жүргізу компания ішіндегі жобалық топтардың өкілдері арасындағы серіктестікті жақсартуға ықпал етеді. Тексерудің төмендегідей түрлерін бөліп қарастыруға болады. Жоғары басшылықпен, сапа тобымен, басқа жобалар өкілдерімен достық тексеру.

Жоғары басшылықпен тексеру компанияда бекітілген уақыт аралығынан кейін ұдайы жүргізілуі керек (мысалы, кварталды бір рет). Осы тексеруді жүргізуде жобаның әрбір қызметкері жасаған жұмысы туралы, анықталған мәселелер, қызықты шешімдер туралы ақпараттарды баяндайды. Жоба басшысы алынған нәтижелер мен пайда болған мәселелерді белгілей отырып, жұмыстың орындалуы туралы айтып береді.

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

Басқа жоба өкілдерімен тексеру компанияның жалпы ұйымдық жиналысында жүзеге асырылады, ол әдетте әр апта жүргізіледі. Жиналысқа барлық жоба өкілдері қатысады және өз жұмыстарының орындалуы, алынған нәтижелер, пайда болған қиындықтар туралы баяндайды, озық тәжірибемен бөліседі немесе оны басқалардан қабылдайды. Қандай-да бір жобада мәселе пайда болса, оны бірігіп шешеді. Жаңа қолданбалы немесе аспаптық бағдарламалық жасақтаманы БӨ-ді дайындау үрдісіне енгізуде әдетте жаңалықты бейімдеуді жобалардың біреуінде орындайды (сынамалы). Компанияның жалпы жиналысында осы жобаның өкілдері жаңалықты енгізу нәтижелерімен бөліседі және оны ортақ пайдалануға ұсыну, ұсынбауды қарастырады.

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

Достық тексеру бір жоба қызметкерлерінің арасында жүргізіледі. Кез-келген қызметкер басқа қызметкерге осы жобаны қарауға және өз жұмысының нәтижелерін тексеруге өтініш жасауы мүмкін. Бұл кейде қателерді табуға мүмкіндік береді. Барлық тексерулер нәтижесі бойынша міндетті түрде анықталған мәселелер, олардың жою тәсілдері мен мерзімдері, сонымен бірге оларды жоюға жауапты тұлғалар көрсетілген есеп құрылады. Тексеру қателерді жою бойынша барлық мәселелерді шешпесе де, оларды уақыты анықтауға мүмкіндік береді, ал жою көп күш пен құралдарды талап етпейді. Тексерудің негізгі мақсаттары:

Конфигурацияны басқару.

Конфигурацияны басқару мәселесі 1.2 бөлімшеде толығырақ көрсетілген. Айтылғандарға тағы бірнеше ескертулер қосуға болады. Конфигурацияны басқару өміршеңдік циклда БӨ-нің толықтығын қолдау үрдісі болып табылады. Әрбір жобалық топ конфигурацияны басқаруға жауапты тұлғадан және компания конфигурациясын басқарудың жалпы жоспары құрамында конфигурацияны басқарудың өзіндік жобасынан тұрады. Конфигурацияны басқарудың жобалық жоспары көрсетілген жоспарға сәйкес құрылады.

БӨ сапасын қамтамасыз ету компанияда қабылданған барлық стандарттар мен процедуралардың барлық қызметкерлермен орындалуын тексерумен түсіндіріледі.

БӨ-нің сапасын қамтамасыз ету жұмыстары келесілерді

қамтамасыз етуі тиіс:

Әрбір жобалық топ сапаны қамтамасыз ету бойынша жауапты тұлғадан және сапаны қамтамасыз ету бойынша жоспардан тұруы керек. Жекелеген жобалық топтар жоспарының негізін- де барлық компанияның сапаны қамтамасыз ету жоспары құрылады, ол сапаны арттыру бойынша әректтерді және осы әрекеттерге жауап беретін жауапты тұлғаларды қалыптасты- рады. БӨ құру бойынша жұмыстар орында үрдісінде дайындау кезеңіне тәуелсіз, әртүрлі статистикалық деректер (метрикалар) жиналады, олар жұмыс істеу тәртібін сандық бағалауға және жұмыс орындау кезіндегі қателіктерді анықтауға мүмкіндік береді. Жиналған метрикалар жоба жұмысын дәл жоспарлауға, тар жерлерді анықтауға және оларды жою бойынша шаралар қабылдауға көмектеседі. Метрикалар БӨ-ді құру бойынша ұйымдық үрдістің сәйкестік деңгейінің, бағларламалық өнімді немесе БӨ өзін құру бойынша жеке жобаның сандық бағалауы болып табылады. Жұмыста өнім, жоба және үрдіс метрикалары қолданылады. Үрдіс метрикалары компанияның ұйымдық үрдісін жетілдіру үшін және орындауды қадағалау үшін, жобаның жұмысын жақсарту және қадалағау үшін, БӨ-нің сапасын жетілдіру үшін қолданылады (5 бөлімді қараңыз). БӨ-ді дайындаудың өміршеңдік циклының қолайлы моделін таңдауды келесі алгоритмді пайдалану арқылы орындау қажет.

Каскадты

Ия Ия Жоқ Жоқ Ия Жоқ

Ия Ия Жоқ Жоқ Ия Ия

Жоқ Жоқ Ия Ия Жоқ Жоқ

Жоқ Жоқ Ия Ия Ия Жоқ

Жоқ Жоқ Ия Ия Ия Жоқ

Жоқ Жоқ Ия Ия Жоқ Ия

Жоқ Жоқ Ия Ия Ия Ия

Каскадты

Жоқ

Жоқ

Ия

Ия

Жоқ

Жоқ

Ия

Ия

Жоқ

Ия

Жоқ

Ия Жобамен қолданылатын құралдар көптеген дайындаушылар үшін жаңа болып табылады ма ?

Ия

Ия

Жоқ

Ия

Жоқ

Жоқ

Жоқ

Жоқ

Ия

Ия

Жоқ

Ия

Жоқ

Ия

Жоқ

Жоқ

Ия

Ия

Дайындаушылар үшін құрылым икемділікке қарағанда маңызды болып табылады ма?

Ия

Ия

Жоқ

Жоқ

Жоқ

Ия

Жоба менеджері команда прогресін қатаң қадағалайды ма?

Ия

Ия

Жоқ

Ия

Жоқ

Ия

Ресурстарды бөлу жеңілдігі маңызды ма ?

Ия

Ия

Жоқ

Жоқ

Ия

Ия Команда тек құқықты шолулар мен тексерулерді, тапсырыс беруші шолуларын/кезеңдер -

ді қабылдайды ма?

Ия

Ия

Ия

Ия

Жоқ

Ия

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

Каскадты

V-образды

Ия Ия Жоқ Ия Жоқ Ия

Жоқ Жоқ Ия Ия Жоқ Ия

Жоқ Жоқ Ия Жоқ Ия Ия

Жоқ Жоқ Ия Жоқ Ия Жоқ

Жоқ Жоқ Ия Ия Жоқ Жоқ

Жоқ

Жоқ

Ия

Ия

Жоқ

Ия

Жоба жүйелік интеграция түріне ие болады ма?

Жоқ

Ия

Ия

Ия

Ия

Ия

Жоба тиісті жүйенің кеңейтілуі болып табылады ма?

Жоқ

Ия

Жоқ

Жоқ

Ия

Ия

Ия

Ия

Ия

Жоқ

Ия

Жоқ

Ұйымда өнімді ұзақ уақыт пайдалану күтіледі ме?

Ия

Ия

Жоқ

Ия

Жоқ

Ия

Жоқ

Ия

Жоқ

Ия

Жоқ

Ия Күтілмеген әдістерді пайдалану арқылы жүйе сүйемелдеу кезеңінде өзгереді ме?

Жоқ

Жоқ

Ия

Ия

Жоқ

Ия

График шектеулі болып табылады ма?

Жоқ

Жоқ

Ия

Ия

Ия

Ия

Интерфейсті модульдер мөлдір болып келеді ме?

Ия

Ия

Жоқ

Жоқ

Жоқ

Ия

Қайта пайдаланылатын құраушылар қолжетімді ме?

Жоқ

Жоқ

Ия

Ия

Жоқ

Ресурстар жеткілікті ме (уақыт, ақша, құралдар, қызметкерлер)?

Жоқ

Жоқ

Ия

Ия

Жоқ

Жоқ

Жоба қатысушыларын талдау (3.3 кесте) модельді таңдауда маңызды рөл атқарады, себебі ол жобаны сәтті орындауға жауап береді және модельді таңдау үрдісінде көмектеседі .

Болжамды пайдаланушыларды талдау.

Жобаның бастапқы фазаларында болжамды пайдаланушылар туралы нақты ұғымды және жобаның қызмет ету уақытындағы дайындаушылар командасымен өзара байланысын алуға болады (кесте 3.4). М+ұндай ұғым тиісті модельді таңдауға көмектеседі, себебі кейбір модельдер жобаны дайындау және игеру үрдісінде пайдаланушылардың қатысуын талап етеді.

Болжамды тәуекелдерді және жоба түрін талдау.

БӨ өміршеңдік циклының кейбір модельдерінде тәуекелді басқару қарастырылады, ал кейбір модельдерде тәуекелді басқару қарастырылмайды. Тәуекелді басқаруды қарастырмайтын модельді таңдау анықталған тәуекелдерді азайтуға бағытталған әрекеттер жоспарын құру және талдау керек емес дегенді білдірмейді. Мұндай модель әрекеттер жоспарын орындауға және талқылауға болатын шеңбердегі сызбаны қамтамасыз етеді (кесте 3.5). Сәйкес модельді таңдау – бұл нақты жоба үрдісіндегі өміршеңдік циклдың моделін пайдаланудың бірінші кезеңі. Келесі кезең осы жобадағы қажеттіліктер мен мүмкіндіктерге сәйкес оны үйлестірумен түсіндіріледі. Бұл дегеніміз, таңдалған нақты фазалар мен әрекеттер жоба жетекшісіне жобаны таңдалған модельге үйлестіруге көмектесуі қажет. SEІ СММ модельге сәйкес, бұл есепке қандай-да бір нақты жазылулар жоқ. Өміршеңдік циклдар, олардың фазалары, сонымен қатар тиісті әрекеттерді циклдарды, фазаларды, әрекеттерді анықтаудың жіберу нүктесі ретінде пайдалануға болады, олар қазіргі уақыт қажет болып табылады. Үйлестіруді аяқтағаннан кейін, модель дайындаушылар командасымен

негізге алынады және жобаны орындауда қолданылады.

Егер жобаны орындау кезінде командаға басқа модель әрекетті болатын еді деген ойды тудыратын қандай-да бір өзгерістер орын алса не болады? Жобаны орындау үрдісінде модельді өзгертуге болады ма? Бұл сұраққа жауап әрдайым оң болады, бірақ жобаның мұндай өзгерістерінің болжамды салдарын міндетті түрде есепке алу қажет. Жоба қажеттіліктеріне тиісті деңгейде сәйкес келмейтін модельді пайдаланғанша, оны өзгерткен дұрыс. БӨ құрудың өнеркәсіптік технологиялары әртүрлі бағдарламалық қамтамасыз етуді құрудың үлкен тәжірибесін жинаған фирмалармен дайындалуы мүмкін. Бұл технологиялар бұрын қарастырылған модельдердің буданы болып табылатын өміршеңдік цикл модельдерінің негізіндегі қағидалар, әдістер, пайдаланылатын үрдістер мен операциялар сипаттарымен ұсынылады. Әдетте мұндай технологиялар CASE-құралдарын жинаумен түсіндіріледі және өнімнің өміршеңдік циклының барлық кезеңдерін қамтиды және тәжірибелік тапсырмаларды шешуде сәтті пайдаланылады.

Үлкен қызығушылықты өміршеңдік циклдың келесі модельдері ұсынады: Mіcrosoft Solutіon Framework (MSF) — тапсырмалардың кең аясын шешуге арналған Mіcrosoft фирмасының дайындамасы. Технология масштабталған, яғни кез-келген қиындықтағы мәселені ұжыммен шешуге бағытталады; Ratіonal Unіfіed Process (RUP) — ұзақ уақыт бойы CASE- құралдарын құрумен айналысқан Ratіonal фирмасының дайындамасы, олар өміршеңдік циклдың әртүрлі кезеңдерінде қолданылады: талдаудан тестілеуге және құжаттандыруға дейін.

MSF, RUP – әмбебап, масштабты және нақты шарттарда бапталады; Extreme Programmіng (XP) — қатаң шектелген уақыт шарттарында шағын тапсырмаларды кәсіби дайындаушылардың шағын ұжымымен шешуге арналған, соңғы кездері белсенді дамыған технология. Осы технологиялардың әрқайсы БӨ өміршеңдік циклы моделін ұйымдастырудың өзіндік ерекшеліктеріне ие.

Mіcrosoft Solutіon Framework моделі.

MSF технологияларының негізгі ерекшеліктерінің біріне оның жоғарыдағы талаптарды қанағаттандыратын БӨ құруға ғана емес, сонымен бірге тапсырыс беруші алдындағы мәселелерді

шешуге, талдауға, іздеуге бағытталады.

Оның айырмашылығы - тапсырыс берушінің қоятын талаптары терең мәселелер мен дәл келмейтін көрінісі болып табылады. Оның толық болмауы талаптардың дайындау үрдісінде өзгеруі - мәселелерді түсінбеу салдары. Сондықтан, MSF технологиясында көп көңіл тапсырыс беруші мәселесін талдауға және осы мәселелерді шешу және іздеуге арналған жүйе нұсқаларын дайындауға бөлінеді. MSF өміршеңдік циклының моделі каскадты және спиральді модельдің кейбір буданы болып табылады, каскадты модельдің басқару қарапайымдылығын спиральді модельдің икемділігімен үйлестіреді. MSF өміршеңдік циклының модель сызбасы 3.9 суретте көрсетілген. MSF өміршеңдік циклының моделі «утамырға» бағытталады (mіlestones) – бұл қандай-да бір нәтижеге қол жеткізуді сипаттайтын жобаның басты нүктелері. Бұл нәтиже келесі сұраққа жауап ретінде бағаланады және талданады: «Осы қадамда қойылған мақсаттарға біз жеттік пе?». Модельде негізгі фазаның ішкі кезеңдерін көрсететін негізгі  және  аралық утамырлардың болуын қарастырады (модельдің негізгі фазаларының аяқталуы).

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

Бекіту

Сурет 3.9. MSF өміршеңдік циклы моделінің сызбасы

Екі аралық утамыр орнатылады: «Команда ұйытқысы ұйымдастырылған» және «Шешімнің жалпы кескіні құрылған». Ол жобаны жоспарлау және жобалаудан тұрады. Талаптарды талдау негізінде жоба және негізгі сәулет шешімдері, жүйенің функционалды сипаттары, жоспарлар мен күнтізбелі графиктер, дайындау орталары, тестілеу және сынамалы пайдалану дайындалады. Бұл кезең үш деңгейден тұрады: тұжырымдамалық, логикалық және физикалық жобалау. Тұжырымдамалық жобалау деңгейінде тапсырма пайдаланушылық және бизнес талаптарынан қарастырылады және жүйені пайдалану сценарийін жинауды анықтаумен аяқталады. Логикалық жобалауда тапсырма жобалық команда тарапынан қарастырылады, оның шешімі сервис таңдау түрінде ұсынылады. Және физикалық жобалау деңгейінде тапсырма бағдарламашылар тарапынан қарастырылады, пайдаланылатын технологиялар мен интерфейстер анықталады;

дайындау (Developіng).

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

Тұрақтандыру (Stabіlіzіng).

Өнімнің қорытынды нұсқасын шығаруға дайындау, оны сапаның белгіленген деңгейіне жеткізу. Мұнда тестілеу бойынша жұмыстар кешені орындалады (қателерді табу және жою), өнімді күшейту сценарийі тексеріледі. Шешім жеткілікті деңгейде тұрақты болғанда, оны тестілік ортада сынамалы пайдалану орындалады және пайдаланушылар тартылып, жұмыстың нақты сценарийі қолданылады;

Күшейту (Deployіng).

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

Ratіonal Unіfіed Process моделі.

RUP өміршеңдік цикл моделі күрделі, каскадты модель элементтері бар итеративті-инкрементті модельмен егжей-тегжейлі дайындалған. RUP моделінде 4 негізгі фаза, қызметтің (үрдістің) 9 түрі бөлінеді. Одан басқа, модельде жобаны сәтті орындауға басшылық ететін және қолданылатын тәжірибелер қатары сипатталады. Бұл модель UML тілінің көмегімен құрылатын өнімді кезеңді модельдеуге бағытталады. RUP өміршеңдік цикл моделі 3.10 суретте көрсетілген. RUP негізгі фазалары:

Фазалар. Пәндер саласы (үрдістер)

Бастама        Анықтау        Құру        Жіберу

Анықтау        Құру        Құру        Итерацияны жіберу

Сурет 3.10. RUP өміршеңдік циклы моделінің сызбасы

Конфигурация мен өзгерістерді басқару Жобаны басқару Ортаны басқару Жобаның алдын-ала дайындалған жоспары анықталады.  Бұл фазаның негізгі мақсаты — жоба тапсырмасына қатысты барлық мүдделі тұлғалар арасындағы келісімге қол жеткізу;

Анықтау фазасы (

Жеткізу фазасы (Transіtіon).

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

Әрбір фаза шеңберінде саны орындалатын жоба күрделілігі-

мен анықталатын бірнеше итерациялар жүргізу орындалуы мүмкін. RUP негізгі үрдістері бес жұмыс және төрт қолдау үрдістеріне бөлінеді. Жұмыс үрдістеріне жатады:

Пән саласын модельдеу (бизнес-модельдеу, Busіness Modelіng). Бұл үрдістің мақсаты —жүйе жұмыс істеуі тиіс бизнес-мәтінді түсіну, болжамды мәселелерді түсіну, оларды шешу нұсқаларын және ұйым бизнесінің болжамды салдарын бағалау.

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

Тестілеу (Test).

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

Үрдіс мақсаты — жүйені оның жұмыс щеңберінде күшейту және оның жұмыс қабілеттілігін бағалау. Конфигурациялар мен өзгерістердібасқару (Confіguratіon and Change Management). Үрдіс мақсаты – сақталатын элементтерді және келісімді конфигурацияны құру ережелерін анықтау, жүйенің ағымдағы қалпының толықтығын сақтау, енгізілетін өзгертулерді тексеру.

Жобаны басқару (Project Management).

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

XP төтенше бағдарламалау моделі итерациялық-инкрементті типтегі өміршеңдік цикл моделі болып табылады, ол тапсырыс берушінің кезекті талабын қамтамасыз ететін өнім прототипін тез құруға және түрлендіруге қолданылады. Бұл модельдің ерекшеліктері 3.11 суретте көрсетілген.

XP моделінің негізгі фазалары:

Құрылымды шығару»

Пайдалану тарихы (User Story)

Нұсқаны жоспарлау

Дайындау

Тестілеу

Релиз шығару

келесідей қағидаларын анықтайды. Ең алдымен бұл - «жанды» дайындама мағлұматында бекітілген БӨ «жанды» дайындама қағидалары. Одан басқа, XР моделінде өміршеңдік цикл моделінің ерекшелігін сипаттайтын бірнеше ережелер бар.

Жанды жоспарлау (plannіng game)

Нұсқаларды жиі ауыстыру (small releases)

Қарапайым жобалық шешімдер (sіmple desіgn)

Тестілеу негізінде дайындау (test-drіven development)

Тұрақты қайта өңдеу (refactorіng)

Жұппен бағдарламалау (paіr programmіng)

Тұрақты интеграция (contіnuous іntegratіon)

40-сағаттық жұмыс аптасы

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

в) дәстүрлі спиральді және жетілдірілген, немесе өзгертілген және спиральді?

б) бағдарламалық өнімді тексеру; в) бағдарламалық өнім конфигурациясын басқару; г)        сапаны қамтамасыз ету;

Бағдарламалар тіпті ең жақсы әдістемелер мен үлгілерге сүйенсе де, өздігімен пайда болмайды. Бағдарлама - адамдардың еңбектері қалай ұйымдастырылуына байланысты олардың қызметтерінің нәтижелері, көп деңгейде дайындалатын БӨ-нің сапасына тәуелді болады. 1970 жылдардың басында АҚШ-та бағдарламалау дағдарысы орын алды (software crіsіs). Бұл көптеген жобалардың графиктен қалуымен немесе шығындар сметаларының өсуімен түсінідірілді, дайындалған БӨ талап етілетін функционалды мүмкіндіктерге ие болған жоқ, оның өнімділігі төмен болды және алынған бағдарламалық жасақтаманың сапасы пайдалану- шылардың көңілінен шыққан жоқ. Жетекші шетелдік талдаушылармен орындалатын аналитикалық зерттеулер мен шолулар үміттендіретін нәтижелер берген жоқ. Мысалы, 1995 жылы Standіsh Group компаниясы 364 америкалық корпорацияның жұмысын талдады, сонымен бірге, БӨ дайындамасымен байланысты 23 мың жобаның орындалу нәтижелеріне талдау жүргізді және келесідей қорытындығы келді: Кешігіп аяқталған немесе күшін жойған жобалар үшін бюджет орта есеппен 89 %-ға, ал орындау мерзімі 122 %-ға артты. 1998 жылы жобалардың пайыздық қатынасы жақсы жаққа бірнеше есе өзгерді (26, 46 және тиісінше 28 %). Болжамды сәтсіздіктердің негізгі себептері: БӨ талаптарының дәл емес және толық емес қалыптасуы, жоба жұмысына пайдаланушыларды жеткіліксіз тарту, қажетті ресурстардың болмауы, қанағаттанарлықсыз жоспарлау, талаптар мен

сипаттамаларды жиі өзгерту, пайдаланылатын технологияның жаңашылдығы, жобаны сауатты басқарудың болмауы, жоғарғы басшылық тарапынан қолдаудың аз болуы. Соңғы уақытта жетекші шетелдік талдаушылардың пікірі бойынша, жобалардың сәтсіз болуының бірден-бір себебі - олардың төтенше жағдайларда орындалуы. Ағылшынтілді әдебиетте бағдарламалық инженерия саласындағы әлемдік жетекші мамандардың бірі Эдвард Иордан келесідей өрнекті бекітті «death march» немесе «қатерлі марш». Бұл параметрлері қалыпты мәндерден ауытқитын (тым болмағанда 50 %-ға) жобаны білдіреді. БӨ құру жобалары бойынша бұл келесі шектеулерді біреуінің болуымен түсіндіріледі: БӨ дайындау үрдісін бақылау қажеттілігі, дайындау құнын, нәтижелер мерзімі мен сапасын болжау және кепілдеу 1970 жылдардың аяғында майдагерлік тәсілден индустриалды тәсілге өтуге және БӨ құрудың инженерлік әдістері мен құралдарының құрылуына алып келді, олар «бағдарламалық инженерия» деген ортақ атаумен біріктірілді (software engіneerіng).  Ең  алғаш  бұл термин 1968 жылы НАТО қамқорлығымен өткізілген конференция тақырыбы ретінде қозғалды. Жеті жыл өткеннен кейін, 1975 жылы Вашингтонда бағдарламалық инженерия бойынша бірінші халықаралық конференция өтті. Сол кезде бағдарламалық инженерияға арналған бірінші баспа пайда болды — «ІEEE. Transactіons on Software Engіneerіng» («ІEEE. Бағдарламалық инженерия бойынша еңбектер»). Бағдарламалық инженерияны құру және дамыту үрдісінде екі кезеңді бөлуге болады: 1970-1980 жылдар – БӨ құру үрдістерін

жүйелендіру және стандарттау (құрылымдық тәсіл негізінде); 1990 жылдар – БӨ құрудың құрастыру, индустриалды тәсіліне өтудің бастамасы. Бағдарламалық инженерия негізінде іргелі идея жатыр: БӨ жобалау игеруге және жетілдіруге болатын ресми үрдіс болып табылады. БӨ құрудың әдістері мен құралдарын дұрыс игеру және пайдалану оның сапасын арттырады, БӨ жобалау үрдісін басқаруды қамтамасыз етеді және оның өмір сүру мерзімін ұзартады. БӨ дайындау үрдісіндегі кез-келген өзгерістерде жүргізілген өзгерістерден алынған әсерді бағалауға мүмкіндік беретін критерийлер қажет болады. Басқа сөздермен айтқанда, жұмыс тиімділігі мен сапасын өлшеуге мүмкіндік беретін қажетті әдістер. Ұйым– жобаны дайындаушылардың барлық топтары- ның жиынтығы (әрбір жоба өз БӨ-ін құруға бағытталған) және осы үрдіске қатысты әкімшілік. Қазіргі таңда бағдарламалық жасақтаманы дайындау үрдісінің жағдайын бағалайтын екі жалпы қабылданған әдістеме бар: ІSO 9001 халықаралық стандарты және CMM-SEІ моделі Capabіlіty Maturіty Model (ұйымдағы технологиядық үрдістердің жетілуін бағалау моделі), ол Software Engіneerіng Іnstіtute бағдарламалық инженерия институтында дайындалған. 1986 жылы SEІ институты (Карнеги – Меллонуниверситетінің бөлімшесі) Mіtre корпорациясының көмегімен бағдарламаларды дайын- даудың тиімді үрдісінің модельдерін дайындауды бастады. Бұл үрдісті сипаттай отырып, модель авторлары «жетілу» түсінігін пайдаланды, бұл түсінік үрдіс тиімділігін ғана емес, сонымен бірге, тұрақтылықты, сенімділікті білдірді. «СММ» атауына ие болған модельдің алғашқы нұсқасы 1987 жылдың аяғында шығарылды. Одан кейін модель бірнеше рет қайта өңделді, қазіргі таңда оның кезекті нұсқасы дайындалуда. Осы модельге сәйкес, ұйым жетілудің бес деңгейінің біреуінде болады (сурет 4.1).

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

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

Ұйым жаңа жоба дайындамасын        ұқсас мүмкіндіктермен қайта сәтті орындай алады.

Оңтайландырылған Деңгей 5 Әрдайым жақсартылатын үрдіс

Анықталған Деңгей 3 Стандартталған үрдіс

Қайталанатын Деңгей 2 Ұйымдастырылған үрдіс

Осы                                деңгейдегі ұйым        БӨ дайындаудың барлық                басқарушылық және                        инженерлік т а п с ы р м а л а р ы н қ ұ ж а т т а й д ы , стандарттайды                        және басқарудың бір үрдісіне біріктіреді, сонымен бірге ұйымның                стандартты үрдісін        дайындайды. Ұйымдағы                        барлық жобалар дайындаудың бекітілген                тәсілдерін

деп аталады. Осы деңгейдегі ұйымда дайындалатын БӨ мен үрдіс сапасын егжей-тегжейлі өлшеу тәсілдері болады. Дайындау үрдісінің және дайындалатын БӨ-нің сандық сипаттары жақсы оқытылған және басқарылған, үрдіс - белгілі.

деп аталады. Онда орындалған және орындалатын жобалардың сандық сипаттарына және жаңа технологиялар мен идеяларды енгізуге негізделген дайындау үрдісін үздіксіз жақсарту жүзеге асырылады. Жетілудің жоғарылауы бірінші деңгейден бесінші деңгейге қарай орындалады. БӨ дайындаумен айналысатын көптеген ұйымдар бірінші деңгейден бастайды (кейбіреулері сол деңгейде қалады). Жетілмеген ұйым дайындаудың аяқталуы мерзімін және шекті өнім сапасын болжай алмайды. Жетістік тікелей басшының тәжірибесіне және дайындаушылардың квалификациясы мен талантына тәуелді болады. Басқару үрдісін жиі болатын дағдарыстарда емес тек жобаны орындау кезінде құру қажет. Мұндай ұйым БӨ дайындауды сәтті орындай алмайды деп ойлауға болмайды, дегенмен дайындау графигі орындалмайды және жүйенің құны жоспарға қарағанда жоғарырақ болады.

Сәттіліктің қайталануы тек дайындауда сол қызметкерлер қатысқан жағдайда орындалады. Екінші немесе жоғары деңгейлерге қол жеткізу үшін ұйымдар негізгі анықталған үрдістерден тұратын үрдісті құруы керек. Кез-келгеннегізгіүрдіс осыүрдіскеқатыстынегізгіәрекеттерді ұйымның орындауымен түсіндіріледі, бұл өз кезегінде ұйымға осы үрдіспен орындалатын белгілі мақсаттарға жетуге мүмкіндік береді. Негізгі үрдістер аталған үрдісті орындауға мүмкіндік берумен қатар, оны жүзеге асырудың нұсқаулығы болып табылады. Әртүрлі негізгі үрдістердің орындалуы немесе орындалмауы ұйымның жетілу деңгейін талқылауға болатын көрсеткіш болып табылады. CMM моделіндегі осы деңгейді анықтау үшін ұйым қызметкерлерімен қойылатын сұрақтар тізімі қарастырылады. Бұл сұрақтар жауабының талдамасы жетілу деңгейі туралы қорытынды жасауға мүмкіндік береді. Ұйым жетілуінің екінші деңгейіндегі «Бағдарламалық жобаны жоспарлау» негізгі үрдісіне арналған СММ құрылымының мысалы 4.2 суретте көрсетілген.

Даму деңгейі (

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

Сурет 4.2 СММ құрылымының мысалы

СММ моделі қызметкерді таңдау мәселесін қарастырмайды. Ол БӨ дайындамасын таза өндірістік үрдіс ретінде қарастырады. Ұйымдық құрылым және басқару үрдістері дайындаушылардың қабілеттіліктерінің тиімді қолдануына көмектеседі. Әртүрлі ұйымдардағы үрдістер пайдаланылатын технологиялар мен әдістер сияқты әртүрлі болады. Барлық үрдістердің жалпы талаптарына БӨ дайындауды басқару жүйесінің негізін құру жатады.

Халықаралық стандарттау ұйымы (ХСҰ) сапаны басқару мәселесін реттейтін ІSO 9001 стандартының жүйесін дайындады. Бұл стандарттар тауарлар мен қызметтердің, БӨ- нің барлық салаларында қолданылады. СММ модельдері мен ІSO 9001 стандарттары арасындағы өзара әрекеттестік келесідей: ІSO 9001 талаптар тізімінен тұрады, ал СММ сапаны басқару бойынша құжаттарға қосу үшін дайындау үрдісінің талаптарын анықтайды. Ресей ХСҰ

мүшесі бола отырып, ІSO 9001 стандарттар жүйесін өзінің ұлттық стандарты ретінде қабылдады. Стандарттаудың Жалпы ресейлік ғылыми-зерттеу институты оны орыс тілінде аударды. ІSO  9001  мақсаты        - дайындаудың барлық кезеңдерінде сапаны қамтамасыз ететін толассыз басқару жүйесін құру

(TQM — Total Qualіty Management).

ІSO 9001 және CMM-SEІстандарттарында жүйедекөрсетілген стандарттар мен модельдерге ұйым сәйкестігін сертификаттау процедуралары   көрсетілген.   Мұндай    сертификаттаудан   өту қиын болып табылады, көптеген компаниялар өтуге тырысады. Стандарттар мен модельдерге сәйкестікті ресми сертификаттау бәсекелестер алдында бәсекелік артықшылықтар береді. Орындаушыны таңдау кезінде тапсырыс беруші жұмыстың жоғары сапада орындалуына сенімді болады. Кейбір ірі компаниялар байқаулар мен тендерлер жүргізгенде байқауға қатысатын компаниялар қандай деңгейде ІSO 9001 стандарттарына және CMM-SEІ моделіне сәйкес екендігі туралы ақпараттарды талап етеді. ІSO 9001 стандарттарының жүйесі сапаны басқару талаптарының минималды жинағын анықтайды. Шартты түрде бұл жинақ үшке бөлінеді: компания менеджментіне, дайындау үрдісіне, өнімді бақылауға қойылатын талаптар. Егер компания менеджменті оның мәнін түсінбесе немесе оны құру мақсатын қоймаса, сапаның тиімді жүйесі мүмкін болмайды. Компания басшылығы өнімдер мен қызметтердің жоғары сапасын сақтау бейілділігін растайтын ресми хатқа қол қоюы керек. Хатта сапаны бақылау кезінде негізделуге болатын негізгі құжаттар көрсетіледі. Компания басшылығы сапаны бақылауды қамтамасыз ететін бөлімшені құрайды. Одан басқа, мерзімдік тексеріс процедуралары және сапаны басқару жүйесінің тиімділігін талқылаулар анықталады. Өнімді басқаруға дайын пакеттер мен бағдарламаларды, өнімдерді алумен жүйе нұсқаларын бақылау жатады, қазіргі таңда ол сапа талаптарына жауап бермейді. Стандарттың көп ережелері өнімді басқару бөлімінде бағдарламалық жасақтамаға жатпайды немесе екінші деңгейлі болып табылады (мысалы, қаптамаға немесе сақтауға қатысты ережелер). Дайындау үрдісін басқару - бағдарламаумен айналысатын ұйымдар үшін ІSO 9001 стандартының басты бөлігі. Ол БӨ дайындау үрдісінің құжаттамасынан және құру талаптарынан тұрады – келісімшартқа отырған сәттен бастап дайын өнімді шығаруға дейінгі мерзімді қамтиды (бұл кезеңде дайындаманы басқару өнімді басқаруға өтеді).

ІSO 9001классификациясыбойынша, бағдарламаны дайындау өнім ақаулықтары оны пайдаланғанға дейін байқалмайтын арнайы үрдістерге жатады. ІSO 9001 стандартының сипаттамасы түрлі ұйымдарда әртүрлі болатын дайындау үрдісінің өзін реттемейді. Ол үрдістің сапаны толассыз бақылау талаптарына сәйкестік критерийлерін стандарттайды. Бірінші қажетті шарт ретінде нақты ұйымдағы нақты үрдісті реттейтін құжаттаманың болуы қарастырылады.

құрылымы Компанияның болжамды және басқарылатын үрдісін ұйымдастыру үшін ұйымдық, техникалық және техникалық емес құралдар қажет (сурет 4.3).

Ұйымдық құралдарға әртүрлі қызмет тізімдері және жоғары тұрған басшылыққа қызметкерлердің бағыну иерархиясы жатады. Компания жұмысын ортақ басқаруды бас директор орындайды. Әртүрлі жобалардың орындалуымен байланысты сұрақтарды атқарушы директор, ал ұйым және компания үрдісін қамтамасыз ету мәселелерін (яғни, компания әрекет ететін нұсқаулықтарды, ережелер жинағын, процедураларды, басқа басқарушылық құжаттарды) және БӨ сапасын қамтамасыз ету жұмыстарын бас директордың орынбасары басқарады. Жұмыстарды бұлай бөлу компаниядағы үрдіс құру маңыздылығын және БӨ сапасын қамтамасыз ету жұмыстарын өткізуді білдіреді. Қажет болған жағдайда компаниядағы екі топтың орнына (үрдістер тобы және сапаны қамтамасыз ету тобы) үрдістің бір тобы ғана қалуы мүмкін, бірақ бұл топ БӨ сапасын қамтамасыз ету жұмыстарын да орындауы керек. Одан басқа, әрбір жобада БӨ сапасына жауап беретін тұлға тағайындалуы керек. Әдетте бұл жоба жетекшісі немесе жетекші инженердің біреуі. Сапаға жауап беретін тұлға үрдіс тобының немесе сапаны қамтамасыз ету (егер бұл топ өздігінен қызмет етсе) тобының өкілі болып табылады және компания үрдісіне, сапаны қамтамасыз етуге қатысты барлық әрекеттердің орындалуына жауап береді.

и

Жоба № N

Тестілеуші

Жоба жетекшісі Жетекші инженер                Жетекші инженер         Аға инженер                        Аға инженер

Үрдіс(процесс) Сурет 4.3. Бағдарламалық өнімді дайындаумен айналысатын ұйым мен үрдістіңболжамды құрылымы

4.3 суретте көрсетілген, тәуелсіз тесттен өткізуші жоба жұмысына қатысады, бірақ жоба жетекшісіне тәуелді болмайды. Бұл құжаттамаға және аталған жобада дайындалатын БӨ-ге объективті тестілеуді өткізуге мүмкіндік береді. Тесттен өткізуші  егер  жобаның  ағымдағы  кезеңдері сәйкес болмаса, бір уақытта бірнеше жобаларға қатысады. Компанияның барлық тесстен өткізушілері кіретін тестілеудің жеке тобын жиі құрып жатады.

Техникалыққұралдар жобамен жұмыс істеудің және компания үрдісін қолдаудың тиісті шарттарын ұйымдастыру үшін, сонымен қатар, бағдарламалық өнімнің сапасын қамтамасыз ету үшін қолданылады. Мысалы, автоматтандырылған жұмыс орны (АЖО) бағдарламашы жұмысының өнімділігін және дайындалатын БӨ сапасын арттырады, ал компьютерлік желі компаниядағыэлектронды құжатайналымын жәнеқызметкерлер арасындағы байланысты қамтамасыз етеді. Деректер базасы бұрын орындалған және ағымдағы жобаларды орындауға

пайдалануға  қабылданған немесе дайындалған стандарттар мен жоспарларды, сонымен қатар компания үрдісін егжей-тегжейлі сипаттайтын үрдіс кітабын қамтиды. Үрдіс метрикасы бойынша оның негізгі сипаттамаларын бағалайды (негізгі үрдістері) және бағалау нәтижелерін үрдіс төлқұжатына енгізеді. Бұл төлқұжат үрдістің сақталуын қадағалайды, сонымен бірге, оны жетілдіру бойынша әрекеттерді жоспарлайды.

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

БӨ дайындау үрдісінде орындалатын өлшеулер ұйымда қабылданған дайындау үрдісін, жобаның орындалуын, БӨ сапасын бағалауға мүмкіндік береді. Үрдістің  өлшемі  оны ары қарай жетілдіру үшін орындалады, жобаның өлшемі – жұмысты ұйымдастыруды жетілдіруді, ал БӨ өлшеу – оның сапасын арттыруды мақсат етеді. Өлшеу нәтижесінде өлшеу объектісінің қандай-да бір сипатының сапалы сипаттамасы анықталады. Тікелей өлшемдер арқылы объектінің тірек қасиеттері, яғни, тірек метрикалары анықталуы мүмкін. Барлық қалған метрикалар тірек метрикалары мәндеріндегі функцияларды есептеу нәтижесінде бағаланады. Бұл есептеулер тиісті формулалар бойынша орындалады. «ІEEE.  Standard  Glossary   of   Software   Engіneerіng  Terms» баспасында ((«ІEEE. Бағдарламалық инженерияда қолданылатын стандартты терминдер тізімі») метрика сандық мәннен тұратын қасиетке ие болу деңгейіндегі шама ретінде анықталды. Метрика ретінде БӨ-ді, жобаны немесе үрдісті сандық бағалау жатады, ол басқа өлшемдер немесе болжамдар орындалатын негізде тікелей қолданылады. БӨ дайындау саласында әлемдік танылған сарапшы Д-р Барри У. Боэм (Dr. Barry W. Boehm) белгілегендей, метриканың маңыздылығы олардың шешім қабылдауға қаншалықты әсер ететітіне байланысты анықталады. Егер бағдарламалық жоба жетекшісі осыны есіне сақтайтын болса, онда ол ақпараттың көп бөлігін жинақтап, күрделі пайдаланылатын метрикаларды кездейсоқ жинамай, пайдалы және маңызды метрикаларды пайдаланады. «Бағдарламалық өнімді дайындаудағы өлшемдер бағдарламалық үрдіске жататын және оған сәйкес өнімдер бойынша деректерді анықтаудың, жинаудың, талдаудың үздіксіз үрдісі болыптабылады. Бұлқызметтің мақсаты – үрдіс туралы ұғымдарды алу, оларды және бағдарламалық өнімді бақылау, сонымен бірге, бағдарламалық өнімді жетілдіруге ықпал ететін маңызды ақпаратты қолдау [5]. «

Бағдарламалық        өнімді        дайындаудағы        өлшемдер        –

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

» [7 ] .

Барлық метрикаларды үш негізгі топқа бөлуге болады: үрдіс метрикалары; жоба метрикалары; өнім метрикалары. Әрбір топтың ішінде метриканың келесідей түрлері болады: тікелей бақыланатын (өлшенетін), болжамды, есептелетін. Қандай-да бір объет атрибутын тікелей бақылау өлшеу үдісінде басқа атрибуттарды немесе объектілерді пайдалануды талап етпейді. Тікелей бақылау немесе өлшеу тиісті объектіні бағалау кезінде қолданылады. Болжау кезінде таңдалған атрибуттың математикалық моделі болжау процедурасымен бірдей қолданылады, олар белгісіз параметрлерді және нәтижелер түсіндірмесін анықтау үшін қолданылады. Есептеу немесе жанама өлшеу басқа атрибуттардың немесе объектілердің анықталған математикалық модельдер көмегімен өлшеу үрдісіне тартуды білдіреді (кемінде екі метриканы пайдалану арқылы есептеуден тұрады). 5.1 кестеде БӨ, үрдістер, жобаға қатысты метрикалар типтерінің мысалы көрсетілген. Метрикалар объективті және субъективті болады. Субъективті өлшеулер тұлғалық, субъективті тәсілдердің болуын, мысалы, қандай-да бір салмақтық коэффициентті пайдалануды білдіреді. Өлшенетін атрибуттар        сыртқы және ішкі болуы мүмкін. Ішкі атрибуттар объект терминінде өлшенуі мүмкін. Сыртқы атрибуттар сыртқы ортамен объектінің байланысы есебімен бағаланады. Сыртқы атрибуттар мысалдарына бағдарламалық өнімдегі (LOC) код жолдары санының көрсеткіші, әрекеттердің орындалу ұзақтығы, еңбек сыйымдылық шамасы, сәтсіз тесттік зерттеулер саны, ақшалай қаражаттар көлемі, модульділік және күрделілік деңгейі жатады. Сыртқы атрибуттар ретінде орындау уақытын (бағдарлама және компьютер), ұсыну пайдалылығын және ыңғайлылығын (бағдарлама және пайдаланушы талап етіледі), сенімділік, тиімділік, тестілеу, қайта пайдалану, операциялар расындағы өзара әрекеттестік пен көндігу қабілеттілігі қарастырылады. Бағдарламалық жобалардағы өлшеулер әртүрлі деңгейдегі басшыларға көмек ретінде, және қарастырылатын деректерге тәуелді дайындаушыларға уақытылы және дұрыс шешімдер қабылдауға  көмек  ретінде  қарастырылады.  Одан  басқа,  олар үрдіске жетілдірулерді енгізуде жұмыс ұйымдастыру

үрдісін қадағалауды жеңілдетеді, енгізілген прогрессивті өзгерістерді бағалауға мүмкіндік береді. Бағдарламалық метрикалық көрсеткіштер БӨ, жоба немесе үрдістің анықталған атрибуттарын өлшеу үшін қолданылады. Жоба жетекшісі келесі әдістерді қолдана алады: БӨ ақаулықтары мен қателерін талдау; БӨ қалпын бағалау; БӨ күрделілік деңгейін анықтау; дайындаудың негізгі бағыттарын қалыптастыру; ең жақсы әдістемелерді тәжірибелі растау; сапалы көрсеткіштерді, графиктерді, еңбек сыйымдылықты және басқа шығындар көлемін болжау; жобаны орындау кезінде үрдісті қадағалау; өнім сапасының қажетті деңгейіне жетудің оңтайлы мерзімін анықтау. Жиналатын метрикалар шешім қабылдау үрдісін жақсарта және тездете алады, нәтижесінде олардың әрқайсы тікелей өлшеуді орындайды немесе өлшеу нәтижелерін пайдаланады, тек ұтады. Бұл кез-келген пайдалануы, немесе мүдделері жобаны сәтті аяқтаумен байланысты тұлғалар тобы (тапсырыс берушілер, демеушілер, шекті пайдаланушылар, ұйымның басты менеджерлері, жоба жетекшілері, пән саласының сарапшылары, авторлар, талдаушылар, дайындаушылар, БӨ сапасын қамтамасыз етуші инженерлер, бағдарламашылар және тестілеушілер). Менеджерлер жобаны басқару әдістерін анықтауда,  сонымен қатар, БӨ дайындамасы үрдісін жақсарту бойынша өзгерістерді бағалауда метрикалық параметрлерді қолданады, дайындаушылар командасы оларды келесі тапсырмаларды шешу үшін қолданады: Жобалау, құрылымдау, тестілеу, енгізу фазаларында талаптарды талдау кезінде қол жетерлік мақсаттарды қалыптастыру; Осы мақсаттарға жетуде әлеуетті көрсету; мақсаттарға жетудегі алға жылжуды қадағалау; бақылаудан шығатын шекті шарттарды түзетуге арналған үрдістерді баптау (мысалы, егер шолулар маңызды болса, бірақ команда оған қосымша уақытын жұмсағысы келмесе, оларды 5.1 суретте көрсетілген бақылау графигі арқылы бағалауға болады). Мүдделі тараптармен жинау, синтездеу, талдау, есепке қосу және метриканы игеру орындалады.

Үрдіс, жоба және өнім метрикасының мысалдары

Тікелей бақыланатын

болжамды

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

CMM-SEІ деңгейі

Бағалау дәлдігі (алдын-ала бағалаудың нақты мәнге қатынасы ретінде анықталады); өнімділік (дайындаушылармен бір айға жазылған код жолының (LOC) дайындаушылар санына қатынасымен анықталады); есеппен қамту; толтыруды тексеру немесе анықтау; оқыту тиімділігі; тәуекелдік ықтималдығы; метрикалық көрсеткішерді шолу; талаптарды талдау;

Графикке сүйену (игерілген қаржының жоспарланған қаржы көлеміне қатынасымен анықталады, мысалы, орындалған жұмыстың нақты құнының бюджет құнының қатынасы).

өнім ақаулықтарын- ың пайда болуы; қалған ақаулықтардың сипаттамалары және түсінігі;

сенімділік; ақаулықтар саны, олардың маңыздылығы.

Тиімділік — жүйенің динамикалық беталысы; тиімділік— жүйе ресурстары; ақаулық жиіліктері (анықталған ақаулықтардың бағдарламалық өнім көлеміне қатынасымен анықталады: KLOC мәні, мұндағы 1 КШС= 1000 LOC); сенімділіктің қол жеткізілген деңгейін өлшеу; (мысалы, жасау уақытының мәні).

отказ)

Іс-қимыл бойынша шолу орындау үшін (дайындау және кездесулер) жұмсалған сағаттар

0        A     B     C    D     E                F     G    H     І        J        K L M Модуль

Жоғарғы бақылау шегі

Медиана

Төменгі бақылау шегі

Сурет 5.1.Дайындаушылар командасымен қолданылатын қорытынды график мысалы

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

Өлшеу нәтижелерін талдау және өлшеу SEІ институтымен ұсынылған бағларламалық жасақтаманың жетілу моделінің құраушыбөлігіболып табылады (4.2 бөлімдіқараңыз). СММ-SEІ моделіндегі барлық үрдіс жетілудің кез-келген деңгейінде өлшеу және талдау құраушыларынан тұрады. Өлшеу нәтижелерін талдау және өлшеу үрдіс, жоба, өнім қалпын анықтау үшін қажет. Метриканы СММ-SEІ моделінің деңгейлеріне сәйкес жинау және талдау 5.2 кестеде көрсетілген.

Негізгі үрдіс: БӨ талаптарын басқару.

Өлшеу талаптарды басқару мақсатында орындалатын әрекеттерді анықтау үшін қолданылады. Метрика мысалдары:

Кесте 5.2 CMM-SEІ моделінің әртүрлі жетілу деңгейіндегі метрикаларды талдау және жинау әрекеттері

Деректерді жинау және талдау

Барлық ұйымдағы стандартталған деректерді жинау және талдау. Үрдіс параметрлерін сандық ұсыну және тұрақтандыру үшін деректерді пайдалану.

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

Негізгі үрдіс: бағдарламалық жобаны жоспарлау.

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

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

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

Негізгі үрдіс: БӨ дайындау және жобалаудың индустриалды тәсілі. Өлшеу БӨ сапасын және функционалды мүмкіндіктерді анықтау мақсатында орындалады. Метрика мысалдарын былай жіктеуге болады. Одан басқа, өлшеу БӨ дайындау бойынша қызметтің әртүрлі формаларының жағдайын анықтау үшін орындалады. Метрика мысалы:

Негізгі үрдіс: үрдіс сапасын басқару.

Аталған негізгі үрдіс мақсаттарды анықтау бойынша әрекеттерде, үрдіс өнімділігін

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

Негізгі үрдіс: өлшеу және үрдісті талдау.

Өлшеу және талдау үрдістің ағымдағы жағдайын бақылау үшін және алынған деректер негізінде оны жақсарту үшін орындалады.

Метрика мысалдары мынадай болады.

БӨ мүмкіндіктерін анықтаушы тенденциялар мысалдары: бағдарламалық ақаулықтарды болжау және болжамдарды нақты

деректермен салыстыру; -егер өнімде қалған ақаулықтар туралы айтылса, онда ақаулықтарды бөлуді және сипаттамаларын болжау. Негіз ретінде тестілеудің сарапты бағалау деректері қолданылады. Метрикалар қолайлы, қарапайым, ұсынуға жеңіл,  қымбат емес, түсінікті, тізбекті және жұмыс мерзімінде қолданылатын, деректерді жинау және өңдеу тарапынан ыңғайлы, барлық мүдделі пайдаланушылар үшін қол жетімді болуы керек. Жиналатын деректер дұрыс (аталған көрсеткішті анықтау ережелеріне сәйкес жиналған), дәл, нақты және қайшылықсыз (өлшеу құралы немесе өлшеуді орындайтын маман ауысқанның өзінде бейнелетін шамаларда айтарлықтай айырмашылықтар жоқ) болуы қажет. Деректердің көп бөлігі нақты әрекетпен немесе уақыт мерзімімен ассоциацияланады. Олар аңдатпадан және барлық мүдделі тұлғаларды нақты орынмен және жинау уақытымен таныстыруға арналған уақыт және күн көрсетілімінен тұруы керек. Өлшеу процедурасы кез-келген орындаушы қажетті өлшеулерді қайта орындай алуы үшін анық сипатталуы керек.

5.3. Бейзили парадигмасы Виктор Бейзили парадигмасы (Dr. Vіctor Basіlі) «мақсат, сұрақ, метрика» («Goal, Questіon, Metrіc», GQM) метриканы анықтауда кең қолданылатын және жақсы ұсынылатын, жобаны бақылауға және шешімдерді қалыптастыруға сәйкес болатын тәсіл болып табылады.

жиынын қалыптастыру 2 .

1. Мақсаттар жинағын анықтау

7.

р

6.

ж

5.

4.

3.

Сұраққа жауап ретінде қолданылатын метрикалық көрсет- кіштерді анықтау

Сурет 5.2. Бейзили үрдісі

GQM пайдалану тәсілі мақсаттың метриканы таңдауға дейін қойылатынын болжайды. В.Бейзилижетікезеңнен тұратын үрдіс негізіндегі әдістемені дайындады. Осыған байланысты БӨ дайындауда өлшемдерді жүйелі пайдалану мүмкіндігі пайда болды. 5.2 суретте парадигманың барлық кезеңдері көрсетілген. Олардың алғашқы үшеуі GQM парадигмасының шеңберінде жұмыс істеу мәнін анықтайды.

Мақсаттарды, сұрақтарды, метрикалық көрсеткіштерді анықтау үшін мақсаттар, келешек үміттер, орталар жазылатын және мақсаттар құрылымын сипаттайтын шаблон дайындалды (кесте 5.3).

Мақсат

қолжетімді факторларға (дұрыс бағаланатын) негізделген тұрақты модельді дайындауға мүмкіндік беретін деректерге арналған шаблонның болуымен түсіндіріледі.

Сипаттау, бағалау, болжау, ынталандыру, жетілдіру, ұсыну, бағалау, басқару, зерттеу, игеру немесе басқару

Неге қатысты (фокус)?

Объект сапасына шоғырлану (өлшеу фокусталған) – шығындар көлемі, тиімділік, дұрыстылық, өнімді өлшеу, сенімділік, пайдаланушыларға қатысты достық қатынас.

Объектіде өлшеуді жүргізетін пайдаланушылар: дайындаушылар, тапсырыс берушілер, жоба жетекшісі.

Орта

Мәнмәтін (сипаттар) Өлшеу орындалатын орта: ресурс, үрдіс факторлары, адами факторлар, мәселелер, әдістер, құралдар, шектеулер және т.б.

объектіні немесе жағымды сапаны дұрыс ұсынуға мүмкіндік беретін нақты модельдің болуымен түсіндіріледі.

«бөлшектену»        деңгейі        және        дәлдігі        сияқты        аспектілерді әрдайым есепке алу керек.

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

Адами факторлар

Үрдіс факторлары

Өнім факторлары

Ресурс факторлары мақсатты механизмдерде және жобалау механизмдерінде, күнтізбелік уақытқа, бюджетті құралдар көлеміне және қайта пайдалануға болатын бағдарламалық кодқа негізделеді. Толық қалыптасқан мақсат мысалына келесі тұжырымда-ма жатады: «Жобаны дайындаушылар командасының тарапынан интерфейс күрделілігі есебімен және жобада қолданылатын объектілі-бағытталған дайындамада дайындалатын өнімді талдаңыз және бағалаңыз». Мақсаттар өлшенеді және бизнесте қабылданған модельдермен басқарылады. Өлшенетін мақсаттарды анықтау үшін GQM парадигмасынан басқа басқа да механизмдер қызмет етеді, мысалы сапаны күшейту функциясы (QFD — Qualіty Functіon Deployment) және БӨ сапасын өлшеуде қолданылатын метрикаларды пайдалану әдістемесі (SQM — Software Qualіty Metrіcs). GQM көрсетілгендей, мақсаттар сапаның түрлі модельдеріне сәйкес, әртүрлі шарттар үшін әрбір объект бойынша анықталады, олар әртүрлі көзқарас тарапынан және орта сипаттамасын анықтаумен пайдаланылады.

Стратегиялық мақсаттарды әдетте басқару үрдісінде қалыптастырады. Оларға жатады: өлшеулерді жүргізу кезінде негізгі бағыттарды қолдау, жылдам байланыстарды қамтамасыз ету, дайындау үрдісінде «іштей көзқарас» мүмкіндігін ұсыну; тарихи базада келешек жобаларды қалыптастыру. Стратегиялық мақсаттарды бағыттау бойынша алға жылжытуларды анықтауда қолданылатын метрика мысалына CMM-SEІ моделін жетілдіру деңгейі жатады.

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

1,0

Дәлдігін бағалау (алдын ала бағалау/ нақты мәні) 0,9 0,8

0,7

0,6

0,5

0,4

Сурет 5.3 «Ұзартылған мақсат» кескінінің мысалы

Ақаулықтарды азайту бойынша және сапаны басқару бойынша тактикалық мақсатқа жылжудағы алға жылжуды анықтауға арналған метрика мысалдары:

«ұзартылған мақсаттар» линиясы түрінде кескіндеуге болады, мұнда сапалы қолжетімді деңгей көрсетіледі. Осы мақсатқа бағытталу бойынша алға жылжу 5.3 суретте көрсетілген сызбада кескінделеді. GQM алға жылжу мақсаттарын қалыптастырғаннан кейін мақсатқа жылжуды сипаттайтын алға жылжуды өлшеу тәсілдерін анықтау жағына ауысады.

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

келесідей қалыптасатын болса: «Осы мәселелерді түзетуге және талдауға қажетті циклдық уақытты қысқарта отырып, тапсырыс берушілер мәселелеріне жауап қайтару қабілеттілігін жетілдіру». БӨ ағымдағы нұсқасын жетілдіруге бағытталған мақсаттарды орындау жекелеген сұрақтардың пайда болуына ықпал етеді. Мысалы «Күрделі бағдарламалық жүйені жеңілдету» мақсаты келесі сұрақтардың пайда болуына себеп болады. БӨ дайындауды басқару үрдісінде келесідей қағидалы сұрақтар туындауы мүмкін. Қойылған мақсаттарға жылжуды анықтауға мүмкіндік беретін сұрақтар спектрін анықтағаннан кейін, GQM үрдістің келесі кезеңінде осы сұрақтардың жауабына қолданылатын метрикалық көрсеткіштерді анықтайды.

Аталған кезең сұрақтарға жауап беруге қажетті метрикаларды анықтау үшін, сонымен бірге үрдістің және өнімнің қойылған мақсаттарға сәйкестігін анықтауда қолданылады. Әдетте қажетті метрикаларды сұрақтардағы кілттік сөздер арқылы оңай алуға болады. Мысалы, «орташаландырылған түсірілген жігерлер» сөзі келесі сұрақта: «Тапсырыс беруші есептерінде белгіленген мәселелерді жоюға қажетті орташаландырылған түсірілген жігерлер қандай?» еңбек шығындарын бағалауға арналған метрикалық көрсеткішті көрсетеді, — жұмыс апталарында/ айларында көрінетін еңбек шығындары. Одан басқа, метрика ретінде тапсырыс берушілер мәселелері туралы есептер санын пайдаланған жөн, олар апталық/айлық мерзімге жабылады.

Тағы мысалдар қарастырайық.

Мақсат келесідей қалыптасқан делік: «Ақаулықтар класы есебімен шекті өнімді сипаттау». Онда болжамды сұрақтардың біреуі: «Ақаулықтарды анықтау фазасы шегіндегі қателердің таралуы қандай»? Мұндай жағдайда келесі метрика қолданылады: талаптар қателері – олардың саны мен жіктелуі. Басқа мысал. Мақсат: «Қойылған БӨ-ді ұсыну дәлдігі тарапынан, қайта пайдалану тиімділігі есебімен, сонымен бірге дайындаушылар командасы мүшелерінің тарапынан талдау». Сұрақ 1: «Алдымен құрылмайтын модульдердің жалпы санынан қанша пайыз құрайды, мысалы, толығымен қолданылады немесе жекелеген қосалқы жүйелер түрінде?» Метрика 1.1 (әрбір бағдарламалық модуль үшін): анықтау, модуль басынан бастап дайындалды ма? (ия, жоқ). Метрика 1.2 (әрбір бағдарламалық модуль үшін): модульдің қатысы бар қосалқы жүйенің атауы. Сұрақ 2: «Қайта және толығымен қолданылатын кодтар арасындағы пайыздық қатынас қандай (аяқталған жүйеде немесе қосалқы жүйелер бойынша)?». Метрика 2.1 (әрбір бағдарламалық модуль үшін): анықтау, модуль қайта қолданылады ма? (ия, жоқ). Метрика 2.2 (әрбір бағдарламалық модуль үшін): модуль құрамына кіретін қосалқы жүйе атауы. Сұрақ 3 (код қайта қолданылатын әрбір бағдарламалық модуль үшін): «Түрлендіру кластарын қайта қолданудағы модульдерді бөлу қалай орындалады)?». Метрика 3.1: кодтың өзгеру деңгей [ өзгеріссіз, болжамды (20 % жолға өзгертілген); жойылған (20 % жолға өзгертілген)]. Метрика        3.2:        бастапқы        модульге        арналған        қайта пайдаланылатын атау және нұсқа. Метрика 3.3: модуль құрамына кіретін қосалқы жүйе атауы. Сұрақ 4: «Қайта қолданылатын модуль мен сенімділіктің қол

Метрика 4.2 (бірнеше жаңылысулардан тұратын модульдер үшін): қайта пайдалану деңгейі. Метрика 4.3 (жаңылысулардан тұрмайтын модульдер үшін): қайта пайдалану деңгейі. Модульдер    туралы    деректерді    жинағаннан    кейін қайта пайдаланудың анықталған деңгейімен келесідей қорытындыларды жасауға болады: модульдердің бастапқы үрдісіне қарағанда, қателер жиілігінің аз болуына алып келеді; пайдаланғанға дейін тексеру керек, себебі бұл модульдер қарқынды оқытылады және тестіленеді. Метрикалар сұрақтарға тиісті жауап алуды қамтамасыз ететін сандық ақпаратты қамтиды. Бір ғана метрика көмегімен бірнеше сұрақтарға жауап табуға болады. Мысалы, «Қарастырылатын мәселелердің жасы» деген метрика келесі сұрақтарға жауап алуға мүмкіндік береді: «Мәселені шешуге ресурстар жеткілікті жиналды ма?»;

«Мәселелер қаншалықты шешімсіз қалады?».

Екінші жағынан бір сұраққа бірнеше метрикалар қолданылуы мүмкін. Мысалы, «Қарастырылатын мәселелердің жасы» және «Шешілген мәселелер саны» метрикаларын келесі сұраққа пайдалануға болады? «Тапсырыс беруші өтініштеріне жауаптық реакцияны қалай анықтауға болады?». Ұйымдағы мақсаттарды, сұрақтарды және метрикаларды анықтағаннан кейін немесе жобалық ортада нақты метрикалық деректерді жинауға арналған механизмді анықтау керек.

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

«жақын» адам жинайды. Мысалы, еңбек шығындары туралы деректер жинағы БӨ дайындауда дайындаушылардың өзімен орындалғаны дұрыс. Ақпараттандырылу деңгейінің жоғары

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

Деректер жинағын қашан жинаған дұрыс?

Барлығы қандай деректер жинауына және олардың қалай пайдаланылатынына байланысты болады. Дегенмен «барынша ертерек және барынша көбірек» орнату соншалықты жаман емес. Егер деректер жинағын «көңіл-күй бойынша» енгізсе, онда күн сайын, кемінде аптасына бір рет жасау қажет. Деректерді ай сайын жинау сирек орындалады, себебі бұл деректердің қай уақытта тиесілі екенін еске алу өте қиын.

Деректерді жинауды нақты және тиімді ұйымдастыру қалайорындалады? Еңдұрысыавтоматтандырылғанқұралдарды пайдалану. Деректерді жинау бойынша механизмдер жұмыста ыңғайлы болуы керек. Метрикалармен кім тікелей жұмыс істейді? Барлығы мақсатты растауда сипатталған келешек үмітке немесе «көзқарасқа» тәуелді болады. Дегенмен жауапты кім алатыны соншалықты маңызды емес. Деректерді енгізген адам олардың қандай әдіспен түсінідірілетінін және онымен кім танысу керек екендігін білуі керек. Басқа жағынан алғанда, тек нақты деректермен жұмыс істеуді кепілдендіру қажет. Метрикалық деректерді жинау ыңғайлы және қарапайым болуы тиіс. Егер деректерді жинау және аналитикалық үрдіс мақсатты бағыттылықтан тұрады және бағдарламалық үрдіске автоматтандырылуы және біріктірілуі керек, онда жетістікке жетуге болады. Өлшеу үрдісінің деректерге бұрмалануды енгізбеуін қадалағау керек.

уақыттағы деректерді жинау, растау, талдау Жазбаларды қолмен жүргізуәдеттебұрмаланудан, қателерден, қалдырып кетуден, кешігулерден пайда болады. Сондықтан деректерді автоматтандырылған жинау әдісін  қолданған дұрыс: деректер процедурасын қиындатпау; қажет емес жазбаларды болдырмау; қызметкерді осы жерде қолданылатын процедураларға сәйкес жүргізуге оқыту; деректердің тарихи базасында жиналған барлық деректерді растау. Талдау үрдіі әртүрлі формалардан тұруы мүмкін, құралдардың көп бөлігін пайдаланумен және есептілік формасымен айрықшаланады. Метрикалық деректердің графиктік ұғымы әрдайым аналитикалық деректер түсінігін жеңілдетеді. Әдетте келесідей графиктік ұғымдар қолданылады: қорытынды графиктер, гистограммалар, Ишикав диаграммалары(Іshіkawa), Парето диаграммалары (Pareto) және шашыранды диаграммалар.

Уақыт жетіспеушілігі

Құжатты оқып шығу мүмкін емес Ішкі тапсырыс берушілер қолда бар функционалдық қасиеттердің негізінде шешім қабылдайды

Операцияны орындауға бос емес

Басқа бағдарламаға ұқсас емес кейбір өнімдер

Жақсы үлгі жоқ

Құрама қасиеттері тым көп

Тірек жағдайлары, нақты проблемалары

Ишикав диаграммасының мысалы (себебі және салдары шырша ретінде көрсетілген) 5.4 суретте бейнеленген. Бір орында (бір бетте) мақсаттарды, метрикаларды, аналитикалық графиктерді (сурет 5.5) біріктіру мүдделі тұлға- ларға метрикаларды ұсынуға арналған әмбебап сипатты әдіс болып табылады. Мысалы, БӨ дайындамасымен айналысатын компания мақсатқа жетуге бағыттылған сұрақтардың келесі жинағын және үрдісті қадағалау метрикаларын пайдалана алады: «БӨ-ді жетілдіру» Сұрақ 1: «Осы айда қанша ашық мәселелер пайда болды?». Метрика 1:  жаңа мәселелер саны (NOP — New Open Prob-

lems) – өнім шығарылғаннан кейінгі ай ішінде БӨ-нің ағымдағы

нұсқасындағы ашық мәселелердің жалпы санына тең.

Қаңтар Ақп Наур Сəу Мам Маус Шіл Тамыз Қыр Қаз Қар Желт

Мақсаты: «БӨ жетілдіру»

Ай соңында өзекті болған мəселелердің «орташа жасы» қандай? Ай ішінде жабылған мəселелердің «орташа жасы» қандай?

Сурет 5.5. Мақсаттар, сұрақтар, метрикалар, аналитикалық графиктердің бір бетінде орналасу мысалы:

Сұрақ 2: «Ай соңындағы өзекті (ашық және жабық емес) мәселелер саны қанша?». Метрика 2: Ашық мәселелердің жалпы саны (TOP — Total Open Problems,) — ай соңында жабылмаған БӨ нұсқасындағы жаңа мәселелердің жалпы санына тең

Сұрақ 3: «Ай соңында өзекті болып қалған мәселелердің орташа жасы қандай?». «Метрика 3: өзекті мәселелердің орташа жасы (AOP — Mean Age of Open Problems) — өнім шығарылымынан кейін,  ай соңында жабылмаған, осы мәселелер санына бөлінген БӨ нұсқасындағы мәселелердің жалпы уақытына тең.

Сұрақ 4: «Ай ішінде жабылған мәселелердің орташа жасы қандай?». Метрика 4: жабылған мәселелердің орташа жасы (ACP — Mean Age of Closed Problems) — өнім шығарылымынан кейін, ай соңында жабылған, осы мәселелер санына бөлінген БӨ нұсқасындағы мәселелердің жалпы уақытына тең.

Өңделмеген метрикалық деректер әдетте түсінуге қиын. Мысалы, егер 150 жазбадан тұратын күні, уақыты, қате коды белгіленген қателер туралы тіркеу хабарламасы алынса, бұл деректерді түсіндіру қиын.

Қателерді жою үшін кеткен уақыт, сағ.

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

Кері байланысты қолдау —бұл өлшеуді орындау үрдісіндегі маңызды қадам. Жобаның барлық қызметкерлері және басқа пайдаланушылар, деректерді жинаған қызметкерлер өз жұмыстарының нәтижелерін тексеру мүмкіндігіне ие болуы керек. Мысалы, егер дайындаушылар мен тестілеушілер тексерілген модульдерде қателерді бөлу жиілігі туралы ақпаратқа ие болса (сурет 5.7), онда олар белгілі бір қорытындылар жасай алады немесе кемінде сұрақтар қатарына сүйенеді. Бірінші модульде неге қателер саны көп? Бұл жұмыс түрінде жаңадан келген сарапшылар бұған себеп бола ма? Мүмкін бағларламашы бағдарламаның пән саласымен немесе тілімен жеткілікті таныс емес пе?

Ақаулар тығыздығының қалыпқа келтірілген түрі

1        3        5        7        9        11        13   15   17        19        21 23 25

5.7 суретте көрсетілген талдауды үрдісті жетілдіру үшін пайдалануға болады. Егер дайындаушылар мен тестілеушілер, шолу деректерін және тесттік зерттеулерді жинаушы қызметкерлер алынған нәтижелермен таныспайды, олар үрдісті жетілдіру жолдарын талқылауда өз ойларын жеткізу мүмкіндігіне ие болмайды, сонымен қатар, нақты деректері  бар жұмысқа арналған ынталандыруды да алмайды. Кері байланыстың әмбебап тәсіліне бір «бетте» мақсаттардың, сұрақтардың, метрикалар мен графиктік нәтижелердің 5.4 суреттегідейбейнеленуіжатады. Керібайланысмеханизмдерінің графиктік кескіндерінің басқа мысалдары 5.8-5.12 суреттерде көрсетілген. Қателерді тарату жиілігі туралы ұғым өте пайдалы, себебі көп қателерден тұратын модульді ары қарай талдау мақсатында бөлуге мүмкіндік береді. Көбінесе талдау үрдісі негізгі себепті анықтаудан басталады. Модульде қателер санының көп болуы оның күрделі болуынан ба? Анықталған кемшіліктер аталған бағдарламаға тиісті белгілі типтегі қателерге жатпайды ма (мысалы, жобаныңі бастапқы кезеңіндегі қателерге)? Егер бұл солай болса, онда бағдарламашы квалификацияны арттыру курстарынан өтуі керек пе? Егер осы модульдердің біреуін келешекте қайта пайдалану жоспарланса, ал ондағы қателерді бөлу жиілігі аз болса, бұл жоспарды қайта қарастыру қажет пе? Егер        негізгі кемшілік түзетілуі тиіс орташа уақыт белгілі болса  және  анықталған  тарихи деректер негізінде        күтілетін

қателер санын анықтау мүмкіндігі болады,

Уақыт, күндер

Наурыз  Сәуір        Мамыр Маусым Шілде Тамыз

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

қаулар

Жөнд

Кіріс аулары ақ

0   2        4        6        8        10        12        14        16        18

Апта

Сурет 5.10. Ақауларды анықтау және оларды уақыт өте жою

1        2

8        9        10

«Өмірлік маңызды»

Құрылым энтропиясының өсуіне байланысты күрделілік те артады және құраушыны әлдеқайда қарапайым қылу керек. Тестілеу ортасында қателер анықталады және бекітіледі, регрессиялық тесттер асығыс орындалады. Регрессиялық қабықша орындалған кезде 5.9 суретте көрсетілгендей, бірнеше қателердің пайда болуы күтіледі. Егер жаңылысулар саны азаймай, керісінше көбейетін болса, онда дайындаушылардың мәселелерді шешумен емес, олардың өзімен айналысып жатқандығын білдіреді.

Ақаулар саны

Талаптар құрастыру

Кодтау        Интеграция        Тапсырыс берушінің

пайдалануы Сурет 5.12. Ақаулардың жинақталу кезеңін анықтауға мүмкіндік беретін диаграмма Жоба басшысы тестілеуді тоқтатып, аталған тенденцияны талдай алады. Егер жаңылысулар саны қысқартылса, маңызды қателер қалса, онда компания басшылығы, жоба жетекшісі және тапсырыс беруші БӨ шығару бойынша келісімге келуі мүмкін. Тенденцияны талдаудың бұл әртүрлілігі тестілеу кезеңімен шектелмейді. 5.10 суретте көрсетілгендей, ақауларды қадағалау бірінші статистикалық шолулар пайда болғанға дейін басталуы мүмкін. 5.11 суретте көрсетілген Парето диаграммасы жобадағы қателер көзін жетекшімен анықтауға мүмкіндік  береді.  Егер 80 % мәселе 20 % кодта жасырынған деген жиі кездесетін түсінікке сүйенетін болсақ, онда қандай 20 % туралы айтылып жатқанын анықтау керек. Паретоның реттелген диаграммасы - осындай шешімді қабылдаудағы мінсіз көмекші. «Өміршеңдік маңызды» түсінік «тривиалды көпшіліктен» ажыратылғаннан кейін, ары қарай талдау егжей-тегжейді анықтауға мүмкіндік береді. Егер БӨ дайындаудың өміршеңдік циклының қай  фазасында ақаулықтар жиналғаны белгілі болса, онда соған көп көңіл бөлінеді. Сол жерде шолулар мен тексерулер жүргізіледі, мәселені шешуге тәжірибесі мен білімі жеткілікті компаниядағы басқа жоба өкілдері қосылады. Бір жобаның нәтижелері аномалия ретінде қарастырылуы мүмкін, бірақ  егер бірнеше жобалар бір «күдікті» кезеңді көрсететін болса, мысалы 5.12 суретте көрсетілгендей кодтау кезеңінде, онда компания басшылығы дұрыс шешім қабылдауға мүмкіндік беретін анық түсініктер алады.

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

өзгерістер  талап етіледі және        жобаның алынған құраушысы ашылған кемшілік салдарынан өзгереді. Еңбек шығындары туралы көбінесе БӨ дайындау үрдісінде жұмсалатын ресурстар айтылады.  Аппараттық  қамтамасыз ету, телекоммуникация, бағдарламалық құралдар және басқа бағалы мүлік БӨ дайындау бюджетіне сирек ықпал етеді. Бағдарламаларды дайындауда қымбат тұратын құрылғы талап етілмейді, қойма мекемелері және білдектерге қажеттілік жоқ. БӨ құру шығындары адами факторға тәуелді. Мұндай жағдайда қызметкердің немен айналысатыны (барлық құрылымдағы «ең қымбат» элемент), жоба дайындауға қатысты бағалы ақпараттың өңделуінің орындалуы, жоба бойынша жұмыстың қалған бөлігіне бюжеттің қалай бөлінетіні туралы ұғым құру талап етіледі. Дайындау үрдісін осы және келешек жобалар үшін жетілдіру, дайындаушылардың өніміділік деңгейін арттыру, келешек жобалардың құны туралы болжау құру қажет. Еңбек шығындары туралы деректерді жинау келесі ұқсас жобаны бағалауда маңызды болып табылады; бұл деректер басшылыққа көптеген шешімдер қабылдауға мүмкіндік береді. БӨ дайындауды шығындардың нақты  көлемін  бағалау үшін дайындау үрдісінде орындалатын әрбір тапсырма үшін

шығындар көлемін қадалағау керек.

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

керек.

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

команда мүшелерінің сараптамасын өткізуге болады. Онда тәжірибемен алмасу орындалады, себебі аталған командадағы сарапшылар өзара пайдалы бастауларда ұқсас жұмыстарды, өзара оқытуды, қолдауды орындай алады. Әрине бұл шекті БӨ-нің сапасына әсер етеді. Жұмыстың осындай түрінде хронометраж жүргізу БӨ шолу үрдісі күрделі болған сайын, оларды қайта өңдеуге жұмсалатын уақыт та аз талап етіледі деген қорытындыға келу керек. Осындай шолулар құралдарды үнемдеуге және өнім сапасының жақсаруына алып келеді. Қай кезеңде қиындықтар туғанын білу маңызды. Егер мәселелер дайындаудың өміршеңдік циклының соңғы кезеңдерінде пайда болса, бұл оларды жоюдың жоғары шығындарын талап етеді, себебі қайта жасау көлемі артады. БӨ шығарғаннан кейінгі мәселелерді әдетте тапсырыс беруші анықтайды. Шолулар қиындық түрлері туралы  ақпаратты алуға мүмкіндік береді. Бұл жағдайда мәселелердің толық категорияларын шығару немесе олардың ықпалын азайту керек. Шолуды орындау үрдісінде тез және аз шығындармен түзетуге болатын мәселелер анықталады.

оның пайда болуы кезеңінде, дайындаудың өміршеңдік циклының соңғы кезеңдерінде анықталған мәселе ретінде саналады. Қателерді жою арзан емес, бірақ ақауларды жою одан  сайын қымбат. Өміршеңдік циклдың ерте кезеңдерінде, әсіресе талаптарды қалыптастыру кезеңінде, сонымен қатар жүйені тестілеу кезеңінде, өміршеңдік циклдың соңғы кезеңдерінде пайда болған ақауларды жою қымбат болып табылады. Жобамен жұмыс істеуде тексеру, сараптамалық бағалау, өнім ақауларын құрылымдық толықсыз өлшеулер, яғни шолулар орындалады. Дайындаманың ерте кезеңдерінде ақауларды шолу жүргізу арқылы анықтау бағалы салым болып табылады және ұйым тарапынан салмақты сыйақыны талап етеді. Сонымен бірге, ақаулар статистикасы ақауды анықтау «себепшісімен» емес, шолумен ассоциациялануы керек екенін есте сақтау керек. Әрбір қателік немесе ақау туралы ақпарат жазылады және бекітіледі:        шолуды толтыру сәті; процедура қатысушылары туралы        ақпарат;        шолуға        тиісті        көрсетілім;        қателер        мен ақаулар, қателер мен ақаулар түрлері, пайда болу көзі, деңгейі, маңыздылығы        туралы        келесілген                пікір.        Одан        басқа,                БӨ қолжетімділігі немесе қайта шолуды өткізу қажеттілігі туралы

беруге көмектеседі:

Өлшеуге арналған деректердің маңызды көзі бағдарламалық жүйенің   өзгеруінде    қалыптасады.    БӨ    жеткізгеннен  кейін дайындаушылар қадағалау жүйесінің көмегімен жетіспеушіліктер жазбасын немесе өгертуге сұраным жазбасын орындайды және оларды жоюға күш салады. Стандарттар мен технологиялардың Ұлттық институтының материалдарына сәйкес (NІST — Natіonal Іnstіtute of Standards and Technology) өзгертуге сұранымның келесідей түрлерін бөледі:

түзетуші

бейімделуші

ескертпелі

жетілдірілген

Мәселелер БӨ жеткізгеннен кейін сүйемелдеу кезеңінде ғана емес, сонымен бірге дайындау кезеңінде пайда болуы мүмкін. Олар шолуларды (статикалық тесттер) және тесттерді орындау кезінде (динамикалық тесттер) анықталуы мүмкін. Мәселелерді анықтаудың басқа да әдістері бар, мысалы БӨ дайындаушының өзімен игеруі немес пайдаланушының мәселермен танысуы. Өзгерістер енгізуқажеттілігі әдетте жүйе пайдаланушысымен пайда болады, бірақ бастама бақылаушы тарапынан болуы да мүмкін. Әдетте өзгерістер енгізу қажеттілігін негіздейтін ақпарат келесідей пунктерді қамтиды:

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

Әдетте БӨ өзгерісі үрдісінде келесідей мақсаттар қойылады:

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

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

Бақылау сұрақтары: 9. Қандайөлшемдерорындалады: а)бағдарамалық талаптарды басқаруда; б)жобаны жоспарлауда; в)жобаның орындалуын қадағалауда және бақылауда; г)оқыту бағдарламасын жүзеге асыруда; д)бағдарламалық инженерингте; е)үрдісті сандық басқаруда?

БАҒДАРЛАМАЛЫҚ ӨНІМДЕРДІ ҚҰРУ ЖҰМЫСТАРЫН ЖОСПАРЛАУ Жұмысты жоспарлау тапсырыс берушіден алғашқы талаптарды алудан басталады, ал жоспарлау негізіне жобаны сәтті орындауға және аяқтауға қажетті барлық тапсырмаларды бөлу және олардың арасындағы байланыстарды анықтау жатады. Оның нәтижесіне БӨ құру бойынша

Әрбір белгіленетін тапсырмалар мен құрылым элементінің еңбек сыйымдылығы және көлемі бағаланады, қажетті ресурстар мен өміршеңдік циклды орындаудың уақытша графигі анықталады. Жоспарлау үрдісі циклдық үрдіс ретінде анықталады: оның циклы 6.1 суретте көрсетілген. БӨ-ді дайындау графигі орындау нақтылығы тарапынан бағаланады, қандай-да бір көрсеткіштер бойынша нақты емес графикті алу жағдайында жоспарлау циклы қайталанады. Жоспарлау кезеңіндегі барлық белгіленген тапсырмаларды орындауды қайталау әрдайым міндетті емес.

Жұмысты бөлу құрылымы

Ауқымды бағалау

Ресурстарды бағалау

Жоқ

Иә

Сурет 6.1. Бағдарламалық өнімді құру бойынша жұмыстарды жоспарлау циклы

Жұмыстарды бөлу құрылымы тапсырмалар иерархиясынан

тұрады.

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

көлемін бағалау БӨ  көлемінің  бірлігіне  бағдарламалық  код   жолының саны қабылданады (LOC), ал өнімділік бірлігіне бір айда бір адаммен жүргізілетін (LOC/адам-мес) тиімді бағдарламалық код жолының саны (яғни БӨ-дегі бағдарламалық кол жолының саны) қабылданады. Бағдарламалық кодты құрылымдаумен байланысты емес жекелеген жұмыстарды адам/сағат бірлігінде өлшеу керек. Жұмыстарды бөлу құрылымының әрбір элементінің көлемі мен күрделілігі сараптық бағалау көмегімен анықталады және LOC санымен және адам/сағат бірлігімен өрнектеледі. Әрбір бағалауды алу үшін оның көрсеткішін орташаландырып, кемінде үш тәуелсіз сарапшыны пайдалану керек. Құрылымдық элементтің Д = 0,75...1,25 күрделілігі күрделіліктің салмақтық коэффициентімен есепке алынады. Құрылымдық элемент көлемін алу үшін оның сараптық бағалауын Д с

ресурстарды бағалау Жекелеген құрылымдық элементтердің көлемі бойынша БӨ құру бойынша жұмыстың жалпы көлемі есептеледі (LOC және адам/сағат). Код көлеміне тәуелді БӨ шағын, аралық, орташа және үлкен деп бөлуге болады. 6.1 кестені пайдалана отырып, бағдарламалық кодты құруға арналған орындаушылардың қажетті саны анықталады. Жоба  орындаушыларының жалпы санын алу үшін бағдарламашылар санына адам/сағат шығыны бойынша анықталған адам саны қосылады.

Бағдарламалық өнім көрсеткіштері

Құру мерзімі, айлар

5,0

4,6 1,1

Аралық (8 KLOC)

21,3

8,0

2,7

Орташа (32 KLOC)

91,0

14,0

6,5

Үлкен (128 KLOC)

392,0

Әрбір белгіленген құрылымдық элемент бойынша жұмыстарды бөлу аспаптық құралдарды (аппаратты және бағдарламалық) және болжамды қаржылық шығындарды талап ететін орындаушылар квалификациясын анықтайды. Одан кейін қажетболған жағдайда жекересурстарды пайдалану кезектілігін, әртүрлі құрылымлық элементтерді бөлу механизмдерін, дайындау мерзімі бойынша шектеуді анықтайды.

Дайындау үрдісінде пайда болатын тәуекелдер ресурстық, қаржылық, ұйымдық (әкімшілік) қамтамасызетуменбайланысты және үлкен көлеммен, БӨ күрделілігімен байланысты болып бөлінеді. Ресурстық тәуекелдер ресурстардың бағалануын талдау кезінде және олардыңң пайдаланылуын жоспарлау кезінде анықталады. Мұндай тәуекелдер тиісті квалификациядағы қызметкердің жетіспеуімен, аппаратты қамтамасыз ету өнімділігінің     жетіспеуімен,     бағдарламалық        аспаптық құралдардың сәйкессіздігінен немесе кейбір қосымша қажеттіліктерге қаржыландырудың жетіспеуінен туындайды. Қаржылық тәуекелдер ресурсты тәуекелдермен және үлкен көлеммен, БӨ күрделілігімен тығыз байланысқан, ресурстарды қате жоспарлау жоба бюджетінің артуына алып келеді. Одан басқа, қаржылық ресурстарға БӨ нарығы жағдаятының өзгеруі

және тапсырыс берушінің қаржылық жағдайы әсер етеді.

Ұйымдық немесе әкімшілік тәуекелдер жобаны дайындауды дұрыс ұйымдастырмаумен, жоспарлаудағы қателермен, міндеттерді бөлумен, орындаушылардың жауапкершілігінің жеткіліксіз болуымен түсіндіріледі. Соңғы түрдегі тәуекелдер БӨ күрделілігін және көлемдерін бағалау дәлсіздігінен туындайды. Азайтылған алдын-ала бағалаулар ресурстардың қажетті көлемін  қате  анықтауға және жоба жұмысы мерзімінің тоқтауына алып келуі мүмкін. Болжамды тәуекелдерді анықтағаннан кейін, олардың пайда болу ықтималдылығының сарапты бағалауы жүргізіледі және оларды жою тәсілдері жоспарланады.

Бағдарламалық өнімді дайындау, 8 адам

Тестілеу, 2 адам

Жобаны орындаудың уақытша графигін құру үшін ресурстар мен көлемдердің бұрын алынған бағалауларын, жұмыстың жоспарланған көлемдерін,  құралдық  ресурстарды  талдау және  өміршеңдік  цикл  фазалары   бойынша   персоналды бөлу қажет. Мұндай бөлу осындай жоспарлаудың тарихи тәжірибесі негізінде орындалады. Егер тәжірибе  болмаса,  онда 6.2 кестені пайдалануға болады. Жобаның уақытша графигін құру дайындама кезеңдерінің GANTT-диаграммасын құрудан басталады, оның мысалы 6.2 суретте көрсетілеген. Шағын жобаларды жоспарлауда оны қолмен орындаған жеңіл болып келеді. Генри Гант(Henry Gantt) авторының атымен аталған диаграммада кезеңдердің кезектілігі, олардың уақыт бойынша тізбектілігі, жобаны орындаудың шекті мерзімі жақсы көрсетілген.

Сурет 6.2. GANTT-ди

а пт г а р ла а р

ммасының мысалы

Бағдарламалық өнімді дайындаудың негізгі кезеңдері бойынша уақытша шығындарды және еңбек шығындарын бөлу

шағын

аралық

Егжей-тегжейлі жобалау

Дайындау

Тестілеу, сүйемелдеу

Уақытша шығындар

Жоспарлау, талаптарды құру, жоғары-деңгейлі жоспарлау;

Егжей-тегжейлі жобалау Дайындау

Тестілеу, сүйемелдеу

Әрбір кезең үшін оны қанша адам орындайтыны, оның ұзақтығы, басталу және аяқталу мерзімі көрсетіледі. Көптеген үлкен жобалар үшін диаграмманы құру қиын. Мұндай жағдайда Mіcrosoft ProjectTM сияқты автоматтандырылған құралдарды пайдалану ұсынылады, ол ресурстар мен жұмыстар кезеңін бөлу құрылымын тереңірек қарауға, жеке жұмыстар арасындағы өзара байланысты есепке алуға, қызметкерді рационалды бөлуге, аса жүктелуді және тұрып қалуды болдырмауға мүмкіндік береді. Үлкен жобалар үшін жобаны орындаудың жалпыланған графигін (қолмен құрылады) ұсыну нұсқаланады, бұл графикте

стандарттар мен шаблондар Жоспарлау кезеңінде жобаның жоспарын құруға жұмсалған ресурстарды бағалауды орындау қажет (жоспардың бекітілген нұсқасын алуға қажетті уақыт, жоспарлауға қатысатын адам саны, жоспардың компьютерлік нұсқасын және оның парақтың көшірмесін құру уақыты, жоспарды бекіту және растау процедурасының ұзақтығы). Барлық алынған деректерді жобалық топтың тарихи деректер базасында сақтау керек (ТДБ). Одан басқа ТБД-на жұмыстардың жоспарланған көлемдерін және БӨ өміршеңдік циклының кезеңдері бойынша ресурстарды бөлуді, осы кезеңдер ұзақтығын, жоба жетекшісінің пікірі бойынша барлық басқа деректерді енгізу қажет, бұл жоспарлау үрдісін ары қарай жақсартуға және оның өнімділігін арттыруға көмектесуі мүмкін. Пайдаланылатын құралдар: құжаттарды дайындау жүйесі (мысалы, MS Word);  электронды кестелер (мысалы,  Excel);

жоспарлауды автоматтандыру жүйесі (мысалы, Project).

Пайдаланылатын әдістер мен стандарттар: ұйым үрдісі; ұйымның метрикалық бағдарламасы. Қолданылатын шаблондар: жоба жоспары; шолу бойынша есеп; жоба мәртебесі туралы есеп.

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

БӨ жобалаудағы бірінші әрекеттердің бірі – оған қойылатын талаптарды жинау және реттеу. Бастапқы жиналатын талаптар тапсырыс берушінің бастапқы талаптарынан, тапсырыс берушілер мен пайдаланушылардың сұхбатынан  және жиналыс протоколынан, әртүрлі құжаттардың түпнұсқалары мен көшірмелерінен, БӨ есептерінен және басқа материалдар массасынан тұрады. Жинағаннан кейін оларды реттеп, қайшылықтардан тазалайды. Одан кейін БӨ құраушыларына қойылатын талаптарды дайындайды – техникалық, бағдарламалық, деректер базаларында. Құрылымдық емес жиі пайдаланылатын талаптар мен ынталардың үлкен көлемімен жұмыс істеуге тура келеді, олар ниет туралы әртүрлі келісімдер бойынша таратылған және кездесулер протоколдарына, келісімшарттарға, зерттеудің алғаш жазылған материалдарына тіркелген. Осылайша, осы талаптарды орындауды бақылау  және тіркеу бойынша ұйымдасқан жігерсіз тәуекел жоғары болады және оларды есептеу мүмкін емес. Мәселенің шешімі белгілі: жиналатын талаптардың есебін жүргізу және олардың өңдеуін бақылау, бағалау (өткізуден бас тарту). Мұндай жұмыс

БӨ талаптарын өлшеуге қатысты тапсырыс берушілер мен дайындаушылар арасындағы келісімді қалыптастыратын үрдіс.

Талаптарды басқарудың мақсаттары келесідей: тапсырыс беруші және пайдаланушымен БӨ не істеуі керек екендігі туралы келісімге қол жеткізу;

БӨ талаптарын дайындаушылар тарапынан түсінуді жақсарту; БӨ шектерін орнату, яғни, комьютер аппаратурасының, операциялық жүйенің, БӨ мүмкіндіктерінің техникалық

талаптарын анықтау; жоспарлау базисін анықтау.

Талаптарды басқару маңыздылығы төтенше жағдайларда орындалатын барлық жобаларда барлық талаптарды үш категорияға бөле отырып, басымдылықтар орнатумен түсіндіріледі: «орындау керек», «орындаған дұрыс» және «орындауға болады». Жобадағы басымдылықтарды бұлай орнатуда стратегия келесідей болады: ең алдымен орындалуы тиіс талаптарға шоғырлану; оданкейінуақытқалса, орындалғаны абзал болып саналатын талаптарға шоғырлану; және мүмкіндік болған жағдайда, орындауға болатын талаптарға шоғырлану. Егер мұндай стратегияға жоба басталған сәттен сүйенбесе, онда жағымсыз дағдарыс жағдаймен қақтығысуға болады. Талаптарды басқару техникалық қолдауы үлкен қаржылық шығындарды талап етпейтін жұмыстарға жатады, бірақ бұл жұмыстар құрылатын бағдарламалық өнім сапасын жақсарта алады.

Талап

БӨ орындауы тиіс әрекеттерді шектеулерсіз анықтайды. Басқа сөзбен айтқанда олар ақпаратты өңдеу үрдісінде БӨ тәртібін анықтайды.

Функционалды емес талаптар БӨ тәртібін анықтамайды, бірақ оның атрибуттарын немесе жүйелі шеңбер атрибуттарын сипаттайды. Функционалды емес талаптардың келесідей түрлерін бөліп қарастыруға болады: Пайдалану талаптары — пайдалану интерфейсін, құжаттаманы және оқу курсын анықтайды; Өнімділік талаптары — ресурстарды пайдалану тиімділігін, өткізу қабілеттілігін және реакция уақытын орната отырып, функционалды талаптарға шектеулер қояды; Өткізу талаптары — операциялық орта, бағдарламалау тілі, анықталған стандарттарды пайдалануды ұсынады; Сенімділік талаптары — шекті жиілікті және БӨ жұмысындағы кемшіліктердің ықпалын, сонымен бірге кемшіліктерден кейін БӨ қалпына келтіру мүмкіндіктерін ескертеді; Интерфейс талаптары — жүйе өзара әрекеттесетін сыртқы болмыстарды және осы өзара әрекеттестіктер реттемесін анықтайды (яғни, пайдаланушылар мен сыртқы құралдар).

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

ТБАТ анализдеу

Жоқ

Талаптар жасалып, және бекітілді ме?

Иә

Талаптарды құру, жоспарлау секілді циклдық үрдіс болып табылады (сурет 7.1), әрбір циклдағы (немесе  қосалқы  циклда) негізгі әрекетке БӨ сипатындағы семанитикалық қателерді анықтау және жою жатады. Талаптарды құру үрдісі нақты анықталған қорытындыдан тұрмайды. Ол аяқталуы  үшін ақылға қонымды жеткіліктік қағидасы басшылық етеді, құрылған талаптардың семантикалық қатесі жоқ деген шешім қабылдайды және БӨ орындауы тиіс жұмысты сипаттайды.

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

бағдарламалық өнімді қабылдау шарттарын анықтау қажет.

Талаптарды құрылымдау бойынша жұмысты болашақ БӨ- ді толық сипаттаудан бастайды және жекелеген функциялар талқыланбайды (жұмыстың бұл бөлігі ТБТ талдауы қадамында орындалады), яғни, БӨ талаптарының жалпыланған құрылымын құрудан басталады. Сонымен қатар, БӨ жалпы тағайындалуы, БӨ өткізілуі тиіс аппараттық құралдардың ерекшеліктері, жалпы ерекшеліктер, БӨ жұмыс істеуі керек кешен ерекшеліктері көрсетіледі, БӨ негізгі құраушыларын бөледі. Оларды   бөлуде   олардың   арасындағы   байланыстардың аз болуына тырысу керек, яғни, ақпараттық тәуелсіздікті қамтамасыз ету қажет. БӨ талаптарының жалпыланған құрылымы (жалпыланған сипаттама) жаһанды байланыстар, негізгі қасиеттер және БӨ құрылымдық жекелеген элементтерінің өзара байланыстары туралы ұғым ұсынуы қажет. Ары        қарай        талаптардың        жалпыланған        құрылымы тексеріледі: негізгі құраушылардың өзара байланыстарының сипаты анықталады және әрбір құрылымдық элементтің егжей- тегжейлі сипаты орындалады (БӨ талаптарының егжей-тегжейлі құрылымын құрайды). Әрбір  құрылымдық  элемент  үшін оның функцияларының тексерілуі орындалады және барлық құрылымдық        элементтердің        әрбір        функциясының        сипаты құрылады. Одан кейін әрбір құрылымдық элемент ішіндегі функциялардың өзара байланысы және әртүрлі құрылымдық элементтердің функцияларының сипатталады және анықталады. Барлық талаптарды олардың бекітілген мерзімде немесе БӨ кезекті нұсқаларында кейінгі қалдырып орындау мүмкіндіктері тарапынан  талдайды        және өткізу күрделілігі бойынша орындаушылардың басымдылықтары мен тапсырыс берушінің

басымдылықтары пайдаланылады.

БӨ талаптарының егжей-тегжейлі құрылымы құрылымдық элементтердің өзара байланыстары және олардың функциялары туралы толық түсінік беруі керек. БӨ талаптарын құрылымдау бойынша соңғы әрекетке әрбір құрылымдық элементтің жекелеген функцияларының сипатын құру жатады. Функциялардың әрқайсы үшін кіріс деректері және олардың орналасу орындары көрсетілуі, деректермен жүргізілетін әрекеттер егжей-тегжейлі сипатталуы, функцияның шығыс өнімі, орналасу орны, тестілеу әдістері анықталуы керек. Әрбір талапты тексеру тереңдігін жоба жетекшісі анықтайды. Ол жекелеген функциялар барлық егжей-тегжейден

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

Сипаттаманы техникалық әдебиетте қабылданған терминологияда құру ұсынылады. Прототипті құрылымдауды БӨ-ді жобалауға ұқсас орындайды. Прототип қасиеттерін игеру тапсырыс беруші талаптарын қорытынды бекітуге дейін анықтау және тексеру мақсатында жүзезе асырылады. Бағдарламалық қамтамасыз ету тапсырысшыларына және шекті пайдаланушыларға дайындалатын  БӨ  талаптарын нақты қалыптастыру әдетте қиын болып келеді. БӨ-нің басқа бағларламалық пакеттермен өзара әрекеттесетінін және пайдаланушылармен орындалатын қандай операцияларды автоматтандыру қажет екендігін болжау қиын. Талаптардың егжей-тегжейлі талдауы БӨ не істеу керек екенін түсінуге мүмкіндік береді. Дегенмен талаптарды растамай тұрып, оны тексеру мүмкін емес. Бұл жағдайда жүйе прототипі көмектесе алады. Прототип БӨ-нің бастапқы нұсқасы болып табылады, ол жүйеде қалыптасқан тұжырымдаманы көру үшін, талаптар нұсқасын тексеру үшін, дайындау кезінде пайда болатын мәселелерді табу үшін БӨ-ді қолдану кезінде және оны шешудің болжамды нұсқаларында қолданылады. БӨ прототипін тез дайындау өте маңызды, пайдаланушылар сол арқылы олармен тәжірибе жасауды бастай алады. БӨ талаптарын құрумен жұмыс істеуде прототип бірнеше артықшылықтарды қамтамасыз етеді. Пайдаланушылар БӨ-нің қалай жұмысістейтінін тексеруге мүмкіндікберетін прототиппен жұмыс істей алады. Олар БӨ әлсіз және күшті жақтарын анықтай алады, нәтижесінде жаңа талаптар қалыптасады. Прототип ерте қабылданған талаптардағы қателер мен қалып қойғандарды анықтауға мүмкіндік береді. Мысалы, талаптарда анықталған БӨ-нің кейбір функцияларын пайдаланушылар алдымен пайдалы және қажетті деп санауы мүмкін, дегенмен бұл функцияларды басқа функциялармен пайдалану үрдісінде олар туралы пікірін өзгертуі де мүмкін. Нәтижесінде БӨ талаптары өзгертіледі және БӨ функцияларын пайдаланушылар басқаша түсінетін болады. Прототиптеуді жоспарлау кезеңінде тәуекелдерді талдау үшін қолдануға болады. БӨ дайындаудағы негізгі қауіптілікке

талаптардағы қателер мен қалып қойғандар жатады. Талаптардағы қателерді жою шығындары дайындау үрдісінің соңғы кезеңінде жоғары болуы мүмкін. Прототиптеу жүйені дайындаудың жалпы құнын азайтады. Осы себептер бойынша ол талаптарды дайындау үрдісінде жиі қолданылады.

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

Тапсырыс берушіталаптарының сипаттамасын құрукезеңінде талаптар сипаттамасын құруға жұмсалған ресурстарды бағалау қажет (талаптар сипаттамаларының бекітілген нұсқасын алуға қажетті уақыт, талаптар құруға қатысатын адам саны, талаптар сипаттамасының компьютерлік нұсқасын құруға қажетті уақыт және оның қағаздық көшірмелері, талаптар сипаттамасын растау және бекіту процедурасының ұзақтығы). Осы бағалаулар бойынша талаптар сипаттамасының құрылу өнімділігін анықтауға болады. Барлық алынған деректерді жобалық топтағы деректердің тарихи базасында сақтау қажет. Одан басқа, ол жерге жоба басшысының қалауынша барлық басқа деректерді енгізу керек. Олар талаптар сипаттамасын құру үрдісін жақсартуға және оның өнімділігін арттыруға көмектеседі.

үрдісі; ұйымдастырудың метрикалық бағдарламасы.

Пайдаланылатын шаблондар: талап сипаттамалары; шолу есебі; жоба мәртебесі туралы есеп.

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

Жобалау кезеңі өңдірілетін бағдарламалық жүйе моделін жасау мен талдау үшін арналған. Мұндай модель іске асырудың кезекті кезеңіне қажетті бағдарламалық жүйе құрылымын, модульдер,интерфейс пен мәліметтердің ұйымдастырылуын анықтайды. Белгіленген кезең әр қайсысы үшін қасиеттер жинағы мен басқа құраушылармен байланысы анықталатын жобалау құраушыларының жиынтығы түрінде ұсынылады. Жобалау құраушысы ретінде тапсырыс берушінің БӨ-на талаптарының бөлшектеп байланыстыру нәтижесінде алынған жобалау элементі саналады.Жобалау құраушысы болып жүйелер, жүйе бөлігі, модульдер, мәліметтер элементтері мен т.б. есептеледі. Олардың барлығы құраушы атрибуттары деп аталатын жалпы сипаттамаға ие. Жобалау құраушысы үшін келесі атрибуттар анықталуы мүмкін: Қажетті құраушылар, олардың атаулары мен мақсаттарының тізімі БӨ моделін жасаудың таңдалған әдісіне байланысты анықталады, және бірінші кезекте, бағдарламалаудың таңдалған әдісіне (мысалы, құрылымдық бағдарламалау немесе объектілі- нысаналы) байланысты. Осы әдістердің әрқайсысы БӨ моделін жасаудың өзіндік әдістеріне ие. Жобалау нәтижелері атрибуттың анықталған жиынтығы бойынша жобалау құраушысының сипаттамасы түрінде ұсынылады.

Алғашқы электронды-есептеу машиналарының пайда болуымен  бағдарламалық  қамтамасыз  етуді жасау   үлкен жол жүрді. Қандай да бір бағдарламаны жазу мүмкіндігімен масаттану нақ бағдарламалық қамтамасыз етуді жасау технологиясы есептеу техникасында прогрессті анықтайды деген оймен алмастырылды. Алғашқы                кезеңдерде                есептеуіш                техникасының                        дамуы техникалық мәселелерді шешуге бағытталды. Мәселе мәні бірінші кезекте аппаратура, яғни есептеуіш машинада болды. Мұндай машиналар үшін бағдарламаларды екілік кодта жасайды деген ой болды. Бағдарламалау энтузиасттардың еншісінде еді. Есептеуіш                        машиналарының        мықты                        және                берік                бола бастауына байланысты бағдарламалық қамтамасыз ету мәні көптеген ғалымдар мен практиктермен ұғыныла бастады. Маңызды                жаңалық        1950-жылдардың                                аяғында        болды,        ол кезде жоғары деңгейлі бағдарламалау тілдері пайда болды- Fortran, Algol және т.б. Олардың пайда болуы осындай тілдерді        қолданбай                бағдарламаны        жазу        қиын                мәселеге айналғандығымен шартталады. Ағымдағы мәселелерді шешіп, бұл тілдер жаңаларын жасады. Бағдарламалауды тездетіп және жеңілдетіп, олар ЭЕМ көмегімен шешілетін мәселелер шеңберін айтарлықтай                        ұлғайтты.        Бұрын        шешілгендерге                қарағанда қиынырақ мәселелердің пайда болуы қолдағы құралдар тағы да

мәселені оңтайлы шешу үшін жеткіліксіз болуына алып келді.

Мұндай даму компьютерлерді пайдалану тарихының барлық кезеңіне, тіпті қазіргі кезге дейін, сай келеді. Есептеуіш техника әрдайым өз мүмкіндіктері шегінде қолданылады. Аппараттық немесе бағдарламалық қамтамасыз етудегі әрбір жаңа жетістік ЭЕМ-ді қолдану саласын кеңейту талпыныстарына алып келеді және сөйтіп шешілу үшін жаңа мүмкіндіктерді талап ететін жаңа міндеттер қояды. Қалыптасқан жағдайда бағдарламашы талпыныстары бірінші кезекте бағдарламалаудың жаңа тілдерін жасауға бағытталады. Экономикалық ақпаратты өңдеу мәселелерін шешуге мүмкіндік беретін Cobol тілі пайда болды. Ол ондағы бағдарлама ағылшын тіліндегі мәтінге ұқсас етіліп жасалды. Бағдарламау тілдері ие бола алатын барлық мүмкіндікті біріктіретін PL/І тілі пайда болды. Fortran, Algol, PL/І тілдері бағдарламалаудың процедуралық стилін қолдайды. Бағдарлама ол өзі атқаратын әрекет терминінде жасалады. Бағдарламаның негізгі бірлігі процедура болып табылады. Процедуралар басқа процедуралар шақырады, сөйтіп

олардың барлығы мәселені шешуге әкелетін арнайы алгоритм бойынша жұмыс істейді. Алгоритм – қажетті нәтижеге қол жеткізу үшін әрекеттердің нақты реттілігі. Жоғарыда аталған тілдердің пайда болуы есептеуіш техника көмегімен шешілетін мәселелер шеңберінің нәтижесі болды. Алғашқы кезекте олар есептеуіш мәселелер еді. ЭЕМ-нің негізгі тұтынушылары қажетті нәтижеге тез қол жеткізу мүмкіндігі қызықтыратын ғалымдар мен инженерлер болды. Жасанды интеллект пен мәтіндерді өңдеу мәселелерін шешу үшін ЭЕМ-ді қолдану функционалды тілдердің, оның ішінде Lіsp тілінің пайда болуына әкелді. Бұл тілдер жақсы зерттелген математикалық негіз  –  лямбда-есептеуге  ие.  Әрекеттер көбіне итерация түрінде көрінетін (бағдарлама фрагментінің бірнеше рет қайталануы) Algol типті тілдерге қарағанда, Lіsp тілінде есептеулер рекурсия көмегімен жасалады – өзін-өзі функциясының шақырылуы, оның мәліметтерінің негізгі құрылымы тізім болып табылады. 1960-жылдары көптеген теориктер мен практиктер бағдарламалаудың жаңа, қазіргі заманғы тілдердін жасау бағдарламаны жасаудың барлық мәселесін шеше алмайтынын ұғынды. Бағдарламаны тестілеу, бағдарламалық қамтамасыз етуді жасау процесін ұйымдастыру салаларында қарқынды зерттеулер басталды. Бағдарламалауды эмпирикалық процесстен жақсы реттелгенгекелтіру,оған «инженерлік» сипатберуталпыныстары бағдарламалау әдістерінің жасалуына алып келді. Бұл өте маңызды қадам болды. Бағдарламаны жасау әдістерін құру, бір жағынан, жалпы өнеркәсіптік бағдарламалау үшін негіз жасады, екінші жағынан, бағдарламалық қамтамасыз етудің ағымдық жағдайын жалпылай және саралай отырып, бағдарламаудың жаңа тілдерін, операциялық жүйе, бағдарламалау орталарын жасауға мықты импульс берді. Бағдарламалаудың ең кең таралған әдісі ретінде бағдарламалауға құрылымдық келу саналды. Оны жасаушы - Э. Дейкстра (E. Dіjkstra). Бағдарламалауға шынайы құрылымдылық келу – бағдарламалаудың алғашқы аяқталған тәсілі. Оны аяқталған деудің себебі ретінде құрылымдық бағларламалау оның міндетінен бастап бағдарламада орындалуына дейін жолды ұсынатындығы саналады. Құрылымдық бағдарламалау бағдарламалаудың дамуына зол үлес қосты. Тәжірибелік бағдарламалауда кең таралған бұл әдіс әлі күнге дейін міндеттің арнайы классы үшін өз маңызын жоғалтпады.

Құрылымдық әдіс екі негізгі принципке негізделеді:

Мысалы, егер бізге адрестің дұрыстығын тексеру бағдарламасын жазу керек болса, онда біз оны алғашында келесідей жазамыз:

«Жоқ» деп басу керек.

Мұндай жазу бағдарламада кейде жоғары дәрежелі тілде,мысалы Pascal немесе С-де көрінуі мүмкін. Кез-келген кезеңде бағдарламаны тексеруге болатындығы өте маңызды, тек бітеуіштер – төмен деңгейлі процедуралардың кірісі мен шығысын имитациялайтын процедуралар – жазу жеткілікті. Жоғарыда көрсетілген бағдарламада терминалдан енгізудің орнына кез-келген белгіленген адресті келтіретін адресті оқу процедурасын және ешнәрсе істемейтін, тек дұрыс аяқталукодын қайтаратын мәліметтер базасымен тексеру процедурасын қолдануға болады. Бағдарлама бітеуіштермен құрастырылады және жұмыс істей алады. Басқаша сөзбен, бітеуіштер жоғарғы деңгей логикасын келесі деңгейдің іске асуына дейін тексеруге мүмкіндік береді. Бітеуіш әдісін тізбекті қолдану арқылы бағдарламаны жасаудың әрбір қадамында уақыт өте келе детальдармен толықтырылатын жұмыс істейтін қаңқаға ие болуға болады. Құрылымдық бағдарламалау 1960-жылдардың аяғында пайда болған (Pascal, Algol- 68, Fortran және т.б.) бағдарламалау тілдерінен қолдау тапты. Сол уақытта есептеуіш техника көмегімен мәселелерді шешуде бағдарламалық қамтамасыз ету мағынасыұғынылды. Бұл тілдер әртүрлі салынған процедуралар, параметрлерді жіберудің түрлі әдістерн қолдады. Құрылымдық бағдарламалау үлкен жобалардың жасалуында бағдарламалардың модульдық құрылуының мәнін анық анықтауына қарамастан, бағдарламалау тілдері модульдікті әлі әлсіз қолдады. Бағдарламалар құрылымдығының жалғыз әдісі ретінде оның ішкі бағдарлама немесе функциядан жасалуы саналады. Функцияны шақырудың дұрыстығын бақылау, оның ішінде шынайы аргументтердің саны мен типінің күтілетін формалды параметрлерге сай келуін бақылау орындау (функция прототипі мағынасы кейін пайда болды) сатысында ғана жүзеге асырылады.

Объекті-бағдарлы бағдарламалау бағдарламалаудың үш маңызды мәселесін ұғыну нәтижесінде пайда болып, кең таралды. Бірінші мәселе бағдарламалаудың тілдері мен әдістерінің дамуы бағдарламалық жүйелердің жасалуын жеңілдетіп, жылдамдатса да, одан да жылдам дамитын бағдарлама талаптарына жете алмауында еді. Дамытуды лезде жылдамдатудың жалғыз шынайы тәсілі ретінде құрастылырған бағдарламалық қамтамасыз етуді бірнеше рет қолданудың тәсілі саналды. Басқаша сөзбен, әр жолы жүйені нөлден бастау қажет етілмеді, дұрыстау мен тестілеу циклінен өтіп, тиімді жұмыс атқарған бұрын жасалған модульдерді қолдану қажет етілді. Процедуралық бағдарламалау бағдарламаны жасау үшін блок ретінде қызмет ететін функцияны жасау тәсілін ұсынды. Алайда бұл әдістің икемділігі де, қолдану масштабтары да жалпы бағдарламалауды айтарлықтай жылдамдатуға мүмкіндік туғызбады. Біріншісіне байланысты екінші мәселе құрастырылған жүйені сүйемелдеу мен модификациялауды жеңілдету қажеттілігі болып саналады. Жүйеге талаптардың тұрақты өзгеру фактісі құрастырушылардың білместігі немесе жұмыстың айтарлықтай анық орындалмауы ретінде емес,  жүйенің  дамуының  қалыпты шарты ретінде есептелді. Жүйені сүйемелдеу мен модификациялауға құрастыруға кететін күштен аз күш жұмсалмайды. Біріншіден, жергілікті модификациялар барлық жүйенің жұмысқабілеттілігін бұзбайтындай ету мен, екіншіден, жүйе тәртібінің өзгеруін оңай жасау үшін бағдарламалық жүйелердің жасалу әдісін радикалды өзгерту қажет болды. Үшінші мәселе,шешілуді талап ететін ең елелеулі мәселе – жүйені жобалауды жеңілдету. Барлық мәселелер құрылымдық бағдарламалау талап ететін алгоритмдік көрініске ермейді, оның ішінде алгоритмдік декомпозияға.Бағдарлама құрылымын шешілетін мәселегежақындату,олардың арасындасемантикалық алшақтықты қысқарту керек болды. Семантикалық алшақтық жөнінде мәселе тілі мен оны шешу әдісі негізінде жататын ұғымдар әртүрлі болған кезде айтылады. Сондықтан шешімді жазу қажеттілігімен бірге бір ұғымды екіншісіне ауыстыру да қажет етіледі. Оны бір табиғи тілден екіншісіне ауыстырумен салыстырыңыз. Орыс тілінде ондай ұғымдар болмағандықтан, «брокер», «оффшор» немесе «инвестор» деген сияқты сөздер пайда болады. Өкінішке орай, бағдарламалауда кірме сөздер жоқ. Сөйтіп, жобалауды жеңілдету, дайын модельдерді бірнеше рет қолдану арқылы құрастыруды жылдамдату мен модификация

жеңілдігі – оның жақтаушыларымен насихатталатын объектілі- бағдарлы бағдарламалаудың үш негізгі құндылығы осы. Бағдарламалауға объектілі-бағдарлы келу бірінші кезекте Smalltalk, C++, Java және т.б. сияқты бағдарламалау  тілдерімен байланыстырылады. Бұл ұстам едәуір  негіздерге ие. Тілдер объектілі-бағдарлы бағдарламалаудың басты құралы болғандықтан, оларды жасау барысында қазіргі таңда объектілі- бағдарлы әдістің негізін құрайтын көптеген идеялар пайда болды. Жаңа идеялардың жиналуы 1960-жылдың аяғынан бастап, шашамен 10 жыл болды. 1970-жылдардың аяғына таман абстракцияның жаңа деңгейіне өту академиялық ортаның фактісі болды. Жаңа идеялар өнеркәсіпке ену үшін тағы 10 жыл керек еді. Объектілі модельді жасау жолындағы алғашқы қадам ретінде мәліметтердің абстрактілі типінің пайда болуы саналады. Абстракция деңгейі бойынша жүйенің құрылымдану қажеттілігін Э.Дейкстра көрсетті. Инкапсуляция (ақпаратты жасыру) идеясы  Д.Парнаспен  айтылды.  Кейінірек  типтер мен подтиптер теориясында С.Хоорормен толықтырылған мәліметтердің абстрактілі типтерінің механизмі жасалды. Бағдарламалау тіліндегі мәліметтердің абстрактілі типін алғашқы толық іске асырған Modula, CLU, Euclіd және т.б. тілдерге сүйенетін Sіmula тілі. Бағдарламалаудың алғашқы «шынайы» объектілі-бағдарлы тілі Паоло-Альтода «Ксерокс» компаниясының лабораториясында жасалған Smalltalk тілі. (Көп адамдар әлі күнге оны бағдарламалаудың жалғыз шынайы объектілі тілі деп санайды). Кейін бағдарламалаудың қазіргі жағдайын анықтайтын басқа да объектілі-бағдарлы тілдер пайда болды (пайда болуын жалғастыруда).Олардың ішіндегі кең таралғандары - C++, CLOS, Eіffel, Java. Алайда тек бағдарламалаудың тілдерімен объективті- бағдарлық тәсіл бітпейді. Тілдер бар болғаны қолдануға болатын не болмайтын инструментарийді береді. C++ тілінде процедуралық стильде жазуға болады. Объектілі-бағдарлық бағдарламалау жүйені жобалау, жасау мен дамытудың біріккен тәсілін ұсынады. Объектілі-бағдарлық әдістің пайда болуы бағдарламалық қамтамасыз етудің жасалу әдістерінің дамуы, сонымен қатар ғылымның басқа да салалары негізінде болды. Бағдарламалау саласындағы америкалық сарапшы Гради Буч (Grady Booch) бағдарламалау тілінің дамуынан басқа, жүйені жобалаудың объектілі-бағдарлық тәсілінің пайда болуына әсер еткен келесі жетістіктерді атап өтті:

Образдар немесе шаблондар концепциясын шығарған  сәулет пен құрылыс теориясы соңғы жылдары объектілі- бағдарлы анализ( ОБА) бен объектілі-бағдарлы жобалау (ОБЖ) салаласында белсенді қолданылады.

Бағдарламалау тәсілі саласында қарқынды зерттеу нәтижесі

ретінде бағдарламаны жасау автоматизациясы құралының немесе CASE - құралының (Computer Aіded Software Engіneerіng) көптігі саналады. Кез-келген жоғарыдеңгейлі тілде міндетті жазудан кейін бұл жүйелер автоматты түрде ( немесе тым болмағанда адамның минималды қатысуымен) қойылған міндетті сәйкесінше шешетін дұрыс жұмыс істейтін дайын бағдарламаны өндіреді деп болжанды. CASE-құралдар қажет нәтижеге қол жеткізе алмады: қиындық бойынша міндет сипаттамасы нәтижелі бағдарламамен салыстырылатындай болды, немесе жеңіл міндеттермен салыстырғанда тар шектелген шеңбер шешілді, немесе өндірілетін бағдарлама сапасы тым төмен болды. Негізгі мақсатқа қол жеткізу талпынысының сәтсіздігіне қарамастан, CASE-құралын жасау тәжірибесі бағдарламалау тәсілдерін дамыту үшін өте көп нәрсе берді. Жүйенің кішкене бөлігі тура (мысалы,lex пен уасс компиляторларының генераторлары) қолданылса, идея бөлігі бағдарламаның тез жасалуының қазіргі құралдарын жасауда (RAD — Rapіd Applіcatіon Development), JBuіlder, Delphі, PowerBuіlder және т.б. сияқтылар қолданылды. Толықтыққа мүлде ұмтылмайтын бағдарламалау әдіснамасының дамуының келтірілген тарихи экскурсы бағдарламалау әрдайым қиын мәселелерді шешу мүмкіндігі үшін, қиын бағдарламалық жүйелер жасау мен оны тезірек жүзеге асыру үшін «күресті» деп мысал келтірді. Уақыт өте келе сол немесе басқа жетістіктер панацеямен (ол құрылымдық бағдараламалау, не CASE-құралы немесе тағы басқа болсын) жарияланды. Алайда кең жарнамаланған құрал барлық мәселелерді шешуге қабілетті емес екендігі мәлім болатын. Алғашқы ЭЕМ пайда болуы есептеуіш техниканың дамуында жаңа саты жасады. Әрқайсысын түсінікті ЭЕМ нұсқаулыққа ауыстыруға болатын және кез-келген есептеуіш мәселе шешіле алатын қарапайым әрекет тізбектігін жасау жеткілікті болатын идея пайда болды. Бұл тәсіл бағдарламаны жасау процессінде басқалары алдында ұзақ уақыт бойы үстем болатын тіршілікке икемді болды. Бағдарламалаудың арнайы тілдері пайда болды, олар сәйкесбағдарламалық кодқажекеесептеуішоперацияларды жасауға мүмкіндік туғызды. Бағдарлама жасау әдіснамасы мәліметтерінің негізі бағдарламалық код құрылымының процедуралық немесе алгоритмдік ұйымдастыру болды. Оның есептеуіш міндеттерді

шешуде шынайылығы соншалықты жоғары дәрежеде болды, тіпті ешкім бұл тәсілдің мақсаттылығына күмән келтірмеді. Бұл әдіснамада бастауыш ретінде «алгоритм» түсінігі болды, оның мәні қойылған мақсатқа қол жеткізу немесе мәселені шешуге бағытталған әрекеттердің нақты анықталған тізбектігін жасауды ұйғаруда. Осы көзқараспен, математиканың бүкіл тарихы өз дәуірі үшін өзекті мәселелерді шешу алгоритмдерін жасаумен тығыз байланысты. Сонымен қатар, «алгоритм»түсінігінің өзі сәйкес теорияның пәні болды – олардың ортақ қасиеттерін зерттеумен айналысатын алгоритмдер теориясы. Уақыт өте келе бұл теорияның мазмұны абстрактілі болғандығы соншалықты, оның нәтижелерін тек мамандар түсінетін болды. Бұл дәстүрдің алымы ретінде бір уақыт ішінде бағдарламалау тілдері алгоритмдік деп аталды, ал бағдарламаны құжаттандырудың бірінші графиктің құралы «алгоритмнің блок-сызбасы» деген атқа ие болды. Графиктік белгілеудің сәйкес сызбасы алгоритмдер, бағдарламалар, мәліметтер мен жүйелер сызбасында шартты белгілерді қолдануды регламенттейтін МемСТ 19.701 — 90-де бекітілген. Алайда тәжірибе қажеттілігі нақты функцияның есептелуі мен жеке міндеттердің шешілуін бекітуді әрдайым талап етпеді. Бағдарламалау тілінде жаңа түсінік пайда болып, бекітілді – компьютерлерде міндетті шешуде қолданылатын «алгоритмнің» жалпы түсінігін нақтылаған «процедура». Алгоритм сияқты процедура жеке міндетті шешуге бағытталған әрекет немесе операциятның аяқталған тізбектілігін ұсынады. Бағдарламалау тілдерінде «процедура» деп аталатын арнайы синтаксистік конструкция пайда болды. Уақыт өте келе үлкен бағдарламаларды жасау ауыр мәселеге айналды және оның бірнеше майда фрагменттерге бөлінуін талап етті. Мұндай бөлінудің негізі болып процедуралық декомпозиция саналды, бұл жерде бағдарламаның жеке бөліктері немесе модульдері міндеттердің кейбір жиынтықтарын шешу үшін процедура жиынтығын құрады.Процедуралық бағдарламалаудың басты ерекшелігі – бағдарлама әрдайым уақыт бойынша бастау алады, немесе бастапқы процедураға (бастапқы блок) және соңғы процедураға (соңғы блок) ие. Бұл ретте барлық бағдарлама графиктік примитив немесе блоктың бағыттылған тізбектігі түрінде визуалды ұсынылуы мүмкін. Мұндайбағдарламаныңмаңыздықасиетікелесіпроцедураның әрекетінің басталуы үшін алдыңғы процедураның барлық әрекеттерін аяқтау қажеттілігінде жатыр.Бір процедура шегінде де бұл әрекеттердің орындалу тәртібінің өзгеруі бағдарламалау

тілдеріне міндетті шешудің аралық нәтижелеріне байланысты есептеуіш процесті тамырлауды жүзеге асыру үшін іf-then-else пен go to сияқты арнайы шарттық операторларды қосу талап етілді. Шартты оператор мен сөзсіз өту операторының пайда  болуы мен қарқынды пайдалану бағдарламалау бойынша мамандар арасында қатты талқылануға салынды. Оператор бағдарламасында go to сөзсіз өтуді бақылаусыз қолдану кодты түсінуді қиындатуы  мүмкін.  Сәйкес  бағдарламаларды  bowl of spaghettі деп аталатын спагеттимен салыстырды,олай атау себебі бағдарламаның бір фрагменттен екіншісіне бірнеше рет өтуі, немесе оданда жаман бағдарламаның соңғы операторынан бастапқы операторға қайта өтуінде еді. Жағдай соншалықты драмалы болды, тіпті әдебиетте go to операторын бағдарламалау тілдерінен алып тастау ұсыныстары болды. Дәл сол сәттен бастап go to операторынсыз бағдарламалау жақсы стиль деп саналды.

деген атаққа ие болған бағдарламалық кодтарды жазу мен бағдарламаны жасау процесіне кейбір көзқарастардың пайда болуына себепкер болды. Әдіснама негізі ретінде бағдарламалық жүйенің процедуралық декомпозициясы мен орындалатын процедура жинағы түріндегі жеке модульдердің ұйымдастырылуы саналады. Аталмыш әдіснама аясында бағдарламаның бәсеңдейтін жобалануы немесе «жоғарыдан төмен» бағдарламалану дами бастады. Құрылымдық бағдарламалау идеясының танымалдығы 1970-жылдардың аяғы мен 1980-жылдардың басына келді. Бағдарламалық кодтың құрылымдануының қосымша құралы ретінде салынған циклдер мен шартты операторларды бөлуге тиісті әрбір тармақ басында шегініс қолдану ұсынылды. Мұның барлығы бағдарламаның өзін ұғыну немесе оқылымды болуына септігін тигізуге арналған. Аталмыш ереже уақыт өте келе бағдарламаны жасаудың қазіргі инструментарийларында іске асты.

Объектілі-бағдарлы тәсілдің негізгі ұғымдары ретінде объект пен класс саналады.

Объект сезілетін шындық (tangіble entіty) ретінде анықталады, яғни анық анықталатын тәртіпке ие пән немесе құбылыс. Объект жағдай, тәртіп пен даралықпен сипатталады; ұқсас объектілердің құрылымы мен тәртібі олар үшін жалпы

классты анықтайды. «Класс экземпляры» мен «объект» терминдері эквивалентті болып саналады. Объект жағдайы осы қасиеттердің әрқайсысының ағымдағы (динамикалық) мағы- насы мен аталмыш объекттің мүмкін болатын (статикалық) қасиеті тізімімен сипатталады. Объект тәртібі оның басқа объектілерге әсер етуі мен керісінше осы объектілердің жағдайының өзгеруі мен хабарды жіберу көзқарасымен сипатталады.Басқаша сөзбен, объект тәртібі оның әрекетімен толық анықталады. Бірегейлік – объектіні басқа объектілерден бөлетін объект қасиеті. Бір объекттің басқа объектке сәйкес реакция шақыру мақсатымен әсер етуі операция деп аталады. Әдетте, аталмыш объектпен жасалатын объектілі және объектілі- бағдарлы тілдерінде операциялар тәсіл деп аталып, классты анықтаудың құрамдас бөлігі болады.

Класс

Объектілі-бағдарлық тәсілдің маңызды түсініктерінің келесі тобын мұрагерлік пен полиморфизм құрайды. Полиморфизмді класстың бір типке қарағанда одан көп типке қосылу қабілеті ретінде есептеуге болады. Мұрагерлік мәліметтер мен тәсілдерді қосу немесе қайта анықтау мүмкіндігімен бұрыннан бар класстар негізінде жаңа класстарды жасауды білдіреді. Объектілі-бағдарлық жүйе басынан оның эволюциясы есебімен жасалып келеді. Мұрагерлік пен полиморфизм туынды класстарды – базалық класстардың ұрпақтары - жасау арқылы жаңа функционалдықты анықтау мүмкіндігін қамтамасыз етеді. Ұрпақтар бастапқы көріністің өзгеруінсіз ата-аналар класстарының сипаттамаларын иеленеді және қажет болған жағдайда мәліметтер мен тәсілдердің өзіндік құрылымын енгізеді.Ерекшеліктер немесе нақтылаулар берілетін туынды класстарды анықтау спецификация мен бағдарламалық коды жасау мен қолдануда уақыт пен күшті үнемдейді. Құрылымдық және объектілі-бағдарлы тәсіл арасындағы принципиалды айырмашылық жүйе декомпозициясы тәсілінде жасалады. Объектілі-бағдарлы тәсіл объектілі декомпозицияны қолданады, бұл ретте жүйенің статикалық құрылымы объектілер мен байланыстар арасындағы  терминде  сипатталады,  ал  жүйе тәртібі объектілер арасында хабар алмасу терминінде бейнеленеді. Жүйенің әрбір объектісі шынайы әлем объектісін модельдейтін өзінің жеке тәртібіне ие.

«Объект» ұғымы алғаш рет шамамен 30 жыл бұрын фон

Нейманның дәстүрлі сәулетінен жылжу мен бағдарламалық абстракцияның жоғары  деңгейі  мен  абстракциялаудың  төмен деңгейі арасындағы тосқауылдан өту талпынысымен қолданылды. Объектілі-бағдарлы сәулетпен объектілі- бағдарлы операциялық жүйелер тығыз байланысты. Объектілі тәсілге ең көп салым Sіmula, Smalltalk, C++, Object Pascal бағдарламалаудың объектілі және объектілі-бағдарлы тілдерімен жасалды. Объектілі тәсілге тәуелсіз дамып келе жатқан мәліметтер базасын модельдеу тәсілдері де өз ықпалын тигізді, оның ішінде болмыс-байланыс тәсілі. Объектілі-бағдарлы тәсілдің концептуалды негізі ретінде объектілі модель саналады. Оның негізгі элементтері - абстракциялау abstractіon), инкапсуляция (encapsulatіon), модульдік (modularіty), иерархия (hіerarchy). Негізгілермен қатар тағы үш қосымша элемент - типизация (typіng), параллелизм (concurrency), тұрақтылық (persіstence), олар негізгілерге қарағанда міндетті болып саналмайды.

Абстракциялау

Инкапсуляция

Абстракциялау мен инкапсуляция өзара әрекеттесін операция  болып  табылады:  абстракциялау  объектінің сыртқы ерекшеліктеріне назар аударса, инкапсуляция объект- қолданушыларға объектінің ішкі құрылысын көруге мүмкіндік бермейді.

Модульдік

Иерархия

(құрам бойынша иерархия).Класстар иерархиясы мысалы - оңай және көп мұрагерлік (бір класс бір немесе бірнеше басқа класска қатысты құрылымдық немесе функционалды бөлікті қолданады), объект иерархиясы мысалы – агрегация.

Типтеу

Параллелизм

Тұрақтылық

Объектілі-бағдарлы тәсілдің маңызды қасиеті - талаптардың жасалуы сатысынан бастапіскеасусатысына дейінұйымқызметі моделі мен жобаланатын жүйенің ұйғарымы.Модельдердің ұйғарымдылығы        талаптары                абстракциялау,        модульдық, жасаудың барлық сатысындағы полиморфизмға байланысты жасалады. Ерте кезеңнің модельдері іске асыру модельдерімен салыстыруға келеді. Объектілі модель бойынша ақпараттық жүйенің объектілері мен класстарына модельденетін пәндік саланың (ұйым) шынайы болмыстарының көрінісі бақыланады. Объектілі-бағдарлы                анализ        бен        жобалаудың                (ОБАЖ) тәсілдерінің көбісі өзіне модельдеу тілі мен модельдеу процесін сипаттауды қосады. Модельдеу тілі – жобаларды сипаттау үшін тәсілмен қолданылатын нотация (графикалық). Графикалық нотация модельдерде қолданылатын графикалық объектілердің жинағынан тұрады; ол модельдеу тілінің синтаксисі болып табылады. Мысалы, класстар диаграммасының нотациясы класс, ассоциация мен көптілік ретінде мұндай элементтер мен түсініктер қалай ұсынылатындығын анықтайды. Процесс –

жобаны жасауда орындауға тиісті қадамдардың сипаты.

UML (Unіfіed Modelіng Language) модельдеудің жүйеленген тілі – 1980 жылдардың аяғы мен 1990м-жылдардың басында пайда болған ОБАЖ тәсілдері ұрпақтарының мұрагері. UML жасау 1994 жылдың аяғында Гради Буч и Джеймс Рамбо А.Джекобсон көмегімен және Ratіonal Software компаниясының қамқорлығымен Booch пен ОМТ (Object Modelіng Technіque) әдістерін біріктіру бойынша жұмысқа кіріскенде басталды. 1995 жылдың аяғында олар Unіfіed Method, 0.8 версиясы деп аталған біріккен тәсілдің алғашқы спецификациясын жасады. Сол жылы,1995-те, оларға OOSE (Object-Orіented Software Engіneerіng) тәсілінің жасаушысы Ивар Якобсон қосылды.

Сөйтіп, UML Е. Буча, Д. Рамбо, А. Джекобсон мен И. Якобсон тәсілдерінің тура бірігуі мен унификациясы болып табылады, алайда оларды жаңа мүмкіндіктермен толықтырады. UML жасауда басты болып келесі мақсаттар саналды: Қазіргі таңда UML тілі модельдеудің стантартты тілі (OMG (Object Management Group) – объектілі-бағдарлы тәсіл мен технология саласында стандарттау бойынша ұйым) ретінде қабылданды және БӨ жасау индустриясында кең қолдауға ие болды. UML тілі барлық ірі компаниялармен – БӨ жасаушылар (Mіcrosoft, ІBM, Hewlett-Packard, Oracle, Sybase және т.б.) – қарулануға алынды. Сонымен қатар, CASE құралының барлық әлемдік өндірушілері, Ratіonal Software (Ratіonal Rose) басқа, өз өнімдерінде UML қолдайды (Paradіgm Plus 3.6, System Archіtect, Mіcrosoft Vіsual Modeler for Vіsual Basіc, Delphі, PowerBuіlder және т.б.). UML толық сипаттамасын http:// www.omg.org,http://

www.ratіonal.com и

UML жасаушылары оны бағдарламалық, ұйымдастыру- шылық-экономикалық, техникалық және баса жүйелерді анықтау, ұсыну, жобалау мен құжаттандырудың тілі ретінде ұсынады. UML тілі нақтырақ 14 бөлімде жазылған.

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

Барлық алынған мәліметтерді жобалық топтың МБИ –де сақтау керек.

Қолданылатын аспап: құжаттарды даярлау жүйесі (мысалы, MS Word). Қолданылатын        әдістер        мен        стандарттар:        ұйымдастыру процесі; ұйымның метрикалық бағдарламасы. Қолданылатын шаблондар: жоғары деңгейлі жобалау нәтижелерін сипаттау; шолу бойынша есеп; жоба статусы жөнінде есеп.

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

9.1.Кодтау БӨ жасау сатысында төмендегі негізгі әрекеттер іске асады. Қодтау, тестілеу, БӨ анықтамалық жүйенің жасалуы, қолданушы құжаттамасын жасау, БӨ версиясы мен инсталляциясын жасау. Кодтау дайын бағдарламалық өнімде жоғарыдеңгейлі және төмендеңгейлі жобалау нәтижелерін қайта жасау процесін көрсетеді. Басқаша сөзбен, кодтауда кез-келген тіл бола алатын бағдарламалаудың таңдалған тілі тәсілімен ЭЭ құралған моделінің сипаттамасы жасалады. ;

;1        2

Descrіptіon: * ;** ;*        Fіle        Lіstіng        template        for        CPU32        has        been *

;*        Creatіon        Date:        21/04/95        From:        New        * ; *

;*        Author:        ІBS        Russіa * ; *

;*        Update        By        Modіfіcatіon: * ; * 9r ;*        06/05/95        AR        Add        changes        accordіng        to        R.Soja * and        ;*                B.Calvert                comments        /        letter        from 06/05/95        /                for        ;*        MASM        5.0

9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9 г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9г 9 г ;

Кодтау барысында таңдалған тіл стандартына сай болу керек, мысалы, С тілі үшін - ANSІ C, ал C++ үшін - ІSO/ІEC 14882

«Standart for the C++ Programmіng Language».

Компанияда бағдарламау тілінің жалпы қабылданған стандартынан басқа бағдарламаны жазу ережелеріне қосымша талаптар жасалуы мүкін. Ол негізінен бағдарлама мәтінін ресімдеу ережесіне қатысты болады. Компания стандарты мен ережесін қолдану жасаушы, жасау уақыты, аты мен бағыты, сонымен қатар конфигурацияны басқару үшін қажетті мәліметтер жөнінде ақпаратқа ие дұрыс жұмыс істейтін, оңай оқылатын, басқа жасаушыларға түсінікті бағдарлама жасауға мүмкіндік береді. Кодтау сатысында бағдарламашы  бағдарламаны  жазып, оны өзі тестілейді. Мұндай тестілеу модульдық деп аталады. БӨ тестілеуге қатысты барлық сұрақтар 10 бөлімде айтылған, ал бұл жерде БӨ жасау барысында қолданылатын тестілеу технологиясы жөнінде көрсетілген. Бұл технология

«әйнек жәшік» (glass box) тестілеуі деп аталады; кейде оны «қара жәшік» (black box) классикалық ұғымына қарама-қарсы

«Қара жәшік» тестілеуінде бағдарлама ішкі құрылымы беймәлім объект ретінде қарастырылады. Тестілеуші мәліметтерді енгізеді және нәтижесін саралайды, бірақ ол бағдарламаның қалай жұмыс істейтінін білмейді. Тесттерді таңдай отырып, маман стандартты емес нәтижелерге әкелетін өз көзқарасына сай кіріс мәліметтер мен шарттарды іздейді.  Ол үшін бірінші кезекте тестіленетін бағдарламаның қателері шығуы мүмкін кіріс мәліметтерінің әрбір классының өкілдері қызығушылық туғызады. «Әйнек жәшікті» тестілеуде жағдай мүлдем басқаша. Тестілеуші (бұл жағдайда бағдарламашы) өзі толық қол жеткізуге ие бастапқы кодты білуге негізделіп, тесттер жасайды. Нәтижесінде ол келесі артықшылықтар иеленеді: Мәліметтердің әрбір элементін бағдарламаның қандай бөлігі өзгерту керектігі бағдарламашыға мәлім. Мәліметтер жағдайын бақылай отырып (сондай реттеуші көмегімен), ол  қажетті  емес модульдермен мәліметтердің өзгеруі, олардың дұрыс  емес интерпретациясы немесе сәтсіз ұйымдастырылу сияқты қателерді таба алады. Бағдарламашы өз бетімен тестілеуді автоматтандыра алады. «Әйнек жәшікті» тестілеу – бағдарламалау процесінің бөлігі. Бағдараламашылар бұл жұмысты тұрақты түрде жасайды,

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

Құрылымдық тестілеу «әйнек  жәшікті»  тестілеудің  бір түрі болып табылады. Оның басты идеясы тестіленетін бағдарламалық жолды дұрыс таңдау болып табылады. Оған қарама-қарсы

функционалды тестілеу «қара жәшікті» тестілеу категориясына жатқызылады. Бағдарламаның әрбір функциясы оның кіріс мәліметтері мен шығыс анализін енгізу арқылы тестіленеді. Бұл ретте бағдарламаның ішкі құрылымы өте сирек есептеледі. Құрылымдық тестілеу мықты теориялық негізге ие болғанмен, көптеген тестілеушілер функционалды тестілеуді қалайды. Құрылымдық тестілеу математикалық модельдеуге жақсы беріледі, бірақ ол оның тиімдірек екендігін білдірмейді. Технологияның әрқайсысы басқасын қолдану жағдайында өткізілетін қателерді табуға мүкіндік береді. Осы көзқараста оларды бірдей тиімді деуге болады. Тестілеу объектісі ретінде тек қана бағдарламаның толық жолы ғана болмайды (ол старттан аяғына дейін орындайтын пәрмендердің тізбектілігі), сонымен қатар оның жеке бөліктері де саналады. Бағдарламаның орындалудың барлық мүмкін болатын жолдарын тестілеу мүмкін емес. Сондықтан тестілеу бойынша мамандар барлық мүмкін болатын жолдардың ішінен тестілеу міндетті топтарды бөледі. Таңдау үшін олар тесттердің шынайы санын (көп болса да) анықтайтын қамту белгісі (coverage crіterіa) деп аталатын арнайы белгімен қолданады. Мұндай белгілерді кейде қамтудың логикалық белгісі немесе толықтық белгісі деп атайды. Тестілеушілер жиі қолданатын үш белгіні қарастырайық:тармақ қамтуы, бұтақтану қамтуы мен шарт қамтуы. Тестілеу осы белгілерге сай жасалса, ол жайлы жолдарды тестілеу дейді. Тармақ қамтуы белгісі – үшеуінің ішінде ең әлсізі. Ол кодтың әрбір тармағы тым болмаса бір рет жасалуын талап етеді. Көптеген бағдарламашылар оны қолдану және осы талапты қолдануларына мұрша болмаса да, бағдарламаны тестілеу үшін ол жеткіліксіз. Егер тармақ шешім қабылдау операторына ие болса, мәнді шешудің барлық басқарулары тексерілу керек. Мысал ретінде келесі код фрагментін қарастырайық:

Осы кодты тексеру үшін келесі төрт нұсқаны анализдеу керек. а) А < В и С = 5 (ӘЛДЕНЕ жасалады, кейін D-ға 5 мағынасы

ф

ф

Тестілеудің негіз салушы тәсілінде – бұтақтану қамтуы белгісі бойынша – бағдарламашы а)  нұсқасын  және  қалған үш нұсқаның біреуін тексереді. Бұл әдістің мағынасы ІF операторының жасалған және жасалмаған шарттарында бағдарлама әрекеттері тексерілунде жатыр. Сөйтіп, бағдарлама кодтың барлық тармақтарынан ғана емес, сонымен қатар мүмкін болатын барлық бұтақтанудан өтеді. Кейде бұтақтану қамтуын кодтың толық қамтуы деп атайды. Бірақ бұл термин дұрыс емес: бұтақтану қамтуы тестілеудің толықтығына дәмелене алмайды, өйткені жақсы жағдайда ол бағдарламада бар қателердің жартысын ғана таба алады. Шарт қамтуы белгісі одан да қатал болып саналады. Бұл белгі бойынша әрбір логикалық шарттың құрамдас бөліктерін тексеру міндетті. Келтірілген мысалда ол барлық төрт нұсқаны тексеруді білдіреді. Бағдарлама жолдарын тексеру аяқталған болып саналады, егер қамтудың таңдалған белгісі толығымен жасалса. Бұл процесті автоматтау үшін бағдарламалық код пен жолдарды тестілеуге келетін есептеуіш сандарды анализдейтін, сонымен қатар қаншауы өткізілгенін санайтын бағдарламалар жасалды. Мұндай бағдарламаларды қамтуды тексерудің құралы (executіon coverage monіtors) деп атайды. Әдетте, жолдарды тестілеу барысында әртүрлі мәліметтерде бір жолды тексеру қабылданбайды.Келтірілген мысалдың б),в) және г) нұсқалары маңызды болғанымен, қамтуды тексеру құралының көбісі оны тексеруді уақытты бос жоғалту деп санайды. Үшеуі де бір оператордан басталады және бір тізбектегі пәрмендерді орындауға әкеледі, сондықтан оларды тексеру бір жолды үш рет тексерумен тең болады. Қамту белгілері пайдалы болғанымен, қателерді тиімді табу үшін жолдарды тестілеу ғана жеткіліксіз. Сөйтіп, И.Гуденаф (Goodenough)  пен  К.  Герхарт (Gerhart)  код   тармағының  өтуі ондағы қатенің бар екендігін білдірмейтіндігі жөнінде классикалық мысал келтірді. Бағдарламаның кедесі тармағын

ф 0  болса. Егер С = 0 болса, онда бағдарлама не қате жөнінде айтады,     не өз жұмысын тоқтатады, не «қатып қалады». Осы екі нұсқа арасындағы айырмашылық жолда емес, мәліметтерде. Де Милло (De Mіllo) бағдарламалық жолды қателерге сезімтал дейді, егер оны өту барысында қателер пайда болса. Егер осы жолды өтуде қателер міндетті түрде пайда  болса, онда ол жол қате табаын жол деп аталады. Бағдарламаның келтірілген тармағы арқылы өтетін кез-келген жол қателерге сезімтал, ал қате айнамалы С-дің нөлдік мәнінде ғана пайда болады. Осындай қателерді табу үшін «қара жәшік» тестілеу технологиясы бағдарламалық кодқа қарағанда жақсы келеді. Бағдарламалық жолдарды тестілеу технологиясын формалды сипаттауды Реппс (Rapps) пен С. Вейакерден (Weyuker) табуға болады,мәселені егжей-тегжейлі зерттеуді - Р. Бейзерден (Beіzer), ал қамту белгісін жете талқылауды - Д. Майерсте (Myers). Кез-келген жүйе бөлік бойынша жасалады – процестер немесе модульдер жинағы ретінде. Оны осылай тестілеуге болады, яғни бірінші жеке бөліктерді тексереді, кейін олардың өзара әрекетін. Мұндай тестілеу көтерілуші (bottom-up)деп аталады. Бағдарламаның жекеэлементтері дұрысекендігінбіліп, маман олардың біріккен жұмысын тестілеуге кіріседі. Бұл жерден олар бірге жұмыс істеуден бас тартатындығы байқалуы мүмкін. Мысалы, егер бағдарламашы байқаусыздан шақырылатын функция параметрлерінің орнын алмастырса, онда шақыруды жасауда қате шығады. Және ол тек екі функцияның біріккен жұмысын – шақыратын және шақырылатын- тексеру барысында ғана шығады. Бағдарламалық модульдердің біріккен жұмысын тестілеуді интеграциялық деп атайды.Мұндай тестілеуде бірінші модульді жұптарға біріктіреді, кейін үлкен блоктарға, және ол барлық модуль біріккен жүйеге бірікпегенше жалғасады. Барлық жүйенің интеграциялық тестілеуін тестілеуші жасайды, бірақ бір міндеттің интеграциялық тестілеуін – жасаушы бағдарламашы. Көтерілуші тестілеу – қателерді ауыздықтаудың керемет тәсілі.Егер қате жалғыз модульді тестілеу барысында шықса, онда ол соның ішінде екендігі анық, және оның қайнаркөзін табу  үшін  бүкіл  жүйенің  кодын  анализдеудің керегі  жоқ. Ал егер қате екі алдын-ала тестіленген модульдің біріккен жұмысында шықса, онда мәселе олардың интерфейстерінде жатыр. Көтерілуші тестілеудің тағы бір артықшылығы – оны жасайтын бағдарламашы өте таң шеңберлі салаға назарын аударады ( жалғыз модульде, жұп модуль арасында мәліметтер жіберу және т.б.). Соның арқасында тестілеу мұқият жасалады

және үлкен ықтималдықпен қателерді табады.

Көтерілуші тестілеудің басты кемшілігі – тестіленетін модульды шақыратын арнайы код-қабықшаның жазылу қажеттілігі. Егер ол өз кезегінде басқа модульді  шақырса,  онда ол үшін бітеуіш жазу керек. Бітеуіш – сол мәліметтерді қайтаратын шақырылатын функцияның ұқсастырушысы, ол басқа ешнәрсе істемейді. Қабықша мен бітеуіштерді жазу жұмысты бәсеңдетеді, ал соңғы өнім үшін олар мүлдем қажетсіз, бірақ бір рет жасалған бұл элементтер бағдарламаның әрбір өзгерісінде қайталанып қолданыла береді. Бітеуіш пен қабықшаның жақсы жиынтығы Көтерілуші тестілеуге қарсы тұтастық тестілеу жүйенің толық біріктірілуіне дейін оның жеке модульдері мұқият тестілеуден өтпейді деп санайды. Мұндай стратегияның артықшылығы – қосымша кодтың жазылу қажеттілігінің болмауы. Көптеген бағдарламашылар уақытты үнемдеу үшін тестілеудің осы тәсілін таңдайды, себебі олар бір рет тесттердің ауқымды жинағын жасап, және соған негізделіп бүкіл жүйені бір рет тексеріп шыққан жөн деп санайды. Бірақ мұндай көрініс келесі себептер бойынша қате. Сонымен қатар, бір модульдің қатесі басқа модульді тестілеуді блоктауы мүмкін. Функцияны қалау тестілеуге болады, егер оның шақырушы модулі жұмыс істемесе? Бұл функцияға бағдарлама-қабықшаны жазбаса, модульдің ретке келуін күтуге тура келеді, ал ол өте көп уақыт алуы мүмкін.

береді.

Бағдарламашылардың біреуі тұтастық тестілеуді таңдаса, онда осы тәсілдің артықшылықтарын тек өзі ғана көре алады деп есептеуге болады. Кейбір бағдарламашылар тестілеу тиімділігі жөнінде мүлдем «бастарын ауыртпайды». Олар үшін бастысы – тез арада басшылыққа жұмыстың біткендігі жөнінде баянат беру, тіпті расында ешнәрсе жұмыс істемесе де. Егер осыдан кейін жобада қиындықтар туса, онда олар Мэрфи заңын, тестілеушілерді, жолболмаушылықты, басқаша айтқанда өздерінен басқалардың бәрін айыптайды, себебі олардың ойынша олар өздерінің жұмысын тиімді және уақытында орындады. Тестілеуді ұйымдастырудың тағы бір принципі бар, ол бағдарлама көтерілуші тәсіліндегідей, толығымен емес, бөліктер бойынша тестіленсе, тек қозғалыс бағыты өзгереді – бірінші модульдер иерархиясының ең үстінгі деңгейі тестіленеді, ал содан тестілеуші ақырындап төмен түседі. Мұндай тестілеу бәсеңдеуші (top-down) деп аталады. Көтерілуші де, бәсеңдеуші тестілеулерді инкрементальды деп атайды. Бәсеңдеуші тестілеуде қабықшаларды жазу қажеттілігі жойылады, бірақ бітеуіштер қаладыү Тестілеу барысында қабықшалар кезекпен шынайы модульдерге алмастырылады. Екі инкрементальды тестілеудің қайсысы тиімді екендігі жөнінде мамандардың ойлары әртүрлі. Р. Иордан (Yourdon) бәсеңдеуші тестілеуші жақсы деп дәлелдейді, ал Д. Майерс (Myers) екі әдістің де өз артықшылықтары мен кемшіліктері болғанымен, толығымен көтерілуші тестілеу жақсы дейді. Д. Данның (Dunn) ойы бойынша, бұл тәсілдер шамамен баламалы. Тәжірибеде тестілеу стратегиясын таңдау мәселесі әдетте оңай шешіледі: әрбір модуль мүмкіндігі бойынша жазылудан кейін тестіленеді, нәтижесінде бағдарламаның бір бөлігін тестілеу тізбектігі көтерілуші, ал қалғандары бәсеңдеуші болуы

мүмкін.

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

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

мен дәлдігі үшін толық жауапты болады.

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

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

БӨ орнатуын жасау.

Бұл әрекет пайдаланушы компьютерлеріне БӨ орнату процесін автоматтауға мүмкіндік береді. Және бұл ретте оларға орнатудың әртүрлі сценарийін таңдау мен оның кезекті жұмысының дұрыстығын қамтамасыз ететін мүмкіндік береді. Орнату барысында БӨ өзі жұмыс істеуге тиісті бағдарламалық ортаға «енеді». Сонымен қатар, БӨ жасаушыларында санкцияланбаған «пираттық» орнатуларға (мысалы, БӨ сериялық нөмірін тексеру арқылы) тыйым салуға мүмкіндік пайда болады. БӨ орнату процесі пайдаланушы басшылығында немесе жеке брошюрада міндетті түрде жазылу керек.

БӨ нұсқасын жасау мен жеткізуді басқару.

Мұндай басқару БӨ барлық нұсқасын сәйкестендіру мен жеткізу мен оны байқау үшін қажет. БӨ нұсқасы мен жеткізуді басқаруға жауап беретін арнайы бөлінген жоба қызметкері (конфигурацияны басқаруға жауапты) БӨ ескілерін іздеу мен жаңа нұсқасын жасау немесе БӨ жеткізу процедураларын жасайды, сонымен қатар, өзгерістер өз бетімен жасалмауын бақылайды. Нұсқаларда өзгерістер жөнінде ақпарат болған жағдайда ғана конфигурацияны басқару бойынша жауаптымен енгізіліп, нұсқалардың келісімділігін кепілдеуге болады.

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

БӨ жеткізілімі – тапсырыс берушіге жеткізілетін нұсқа. Әрбір шығыс нұсқасында не жаңа функционалды мүмкіндіктер міндетті түрде болады, не ол жаңа платформаға сай жасалады. Нұсқа саны әдетте жеткізу санынан артады, себебі нұсқалар ішкі қолданыс үшін жасалады және тапсырыс берушіге жеткізілмейді.

Қазіргі таңда нұсқаларды басқаруды қолдау үшін көптеген

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

Нұсқаны сәйкестендіру.

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

Нұсқа нумерациясы .

Құрауыш атауы немесе БӨ-ге нұсқа нумерациясының ең оңай сызбасы бойынша нұсқа нөмірі қосылады. Мысалы, MASM TPU 4.3 белгісі келесіні білдіреді: Нұсқаны сәйкестендірудің аталмыш тәсілі жеткілікті оңай, алайда олардың арасында айырмашылық пен өзгеріске сұраныс арасындағы байланыс пен нұсқаларды бақылау мақсатымен нұсқаларды сәйкестендіру үшін қажетті ақпаратты талап етеді. Сондықтан БӨ-нің жеке нұсқасын немесе оның құрауышын іздеу айтарлықтай қиын болуы мүмкін, әсіресе конфигурацияның мәліметтер базасы мен нұсқаны сақтау жүйесі арасында интеграцияның болмауы жағдайында.

Атрибуттар        мәніне        негізделген        сәйкестендіру.

Нұсқаны анық атау тәсілінің негізгі мәселесі бұл жағдайда нұсқаны сәйкестендіру үшін қолдануға болатын белгілер көрінбейтіндігінде жатыр. Мұндай белгі ретінде келесілер саналады: тапсырыс беруші аты; бағдарламалау тілі; жасау жағдайы; аппараттық платформа; жасау күні. Егер әрбір нұсқа атрибуттардың біріккен жиынтығымен анықталса, онда қолда бар нұсқалардың кез-келгеніне негізделген жаңа нұсқаларды қосу қиын болмайды, себебі  олар атрибуттардың мәндерінің біріккен жиынтығымен сәйкестендіріледі. Бұл ретте жаңа нұсқаның көптеген атрибуттарының мәні бастапқы нұсқа атрибутының мәніне сәйкес келеді; сөйтіп, нұсқалар арасында өзара қатынасты бақылауға болады. Нұсқаны іздеу атрибуттар мәніне негізделіп жасалады. Бұл ретте «ең соңғы нұсқа», «анықталған дата арасында жасалған нұсқа» сияқты сұраныстар болуы мүмкін. Атрибуттар мәніне негізделген сәйкестендіру нұсқаны басқару  жүйесімен  тікелей  қолданыла  алады.   Алайда   нұсқа атының бөлігін ғана қолдану кең таралған, бұл ретте конфигурацияның мәліметтер базасы атрибуттар мәні, БӨ нұсқалары мен құрауыштар арасында байланысты қолдайды.

Өзгерістерге негізделген сәйкестендіру.

Атрибуттар мәніне негізделген сәйкестендіру нұсқаны іздеуде оның атрибуттарын білу талап етілгенде нумерацияның ең оңай тәсілімен нұсқаны іздеу мәселесін жояды. Бірақ бұл жағдайда нұсқалар мен өзгерістер арасындағы өзара байланысты тіркеу үшін өзгерісті басқарудың жеке жүйесін қолдану қажет. Өзгерістерге негізделген сәйкестендіру құрауыштарына қарағанда БӨ-ге қолданылады; жеке құрауыштардың нұсқалары конфигурацияны басқау жүйесі пайдаланушыларынан жасырылған.БӨ-дегі әрбір өзгеріс БӨ-нің аталмыш өзгеруін іске асыратын жеке компоненттердегі өзгерістерде көрсетілетін массивті өзгеріспен сипатталады. Өзгеріс массиві барлық қажетті өзгерістер іске асқан БӨ нұсқасын жасау үшін тізбекті түрде қолданылуы мүмкін. Бұл жағдайда нұсқаны анық белгілеу қажет етілмейді. Конфигурацияны басқаруға жауапты өзгерісті басқару жүйесі арқылы нұсқаны басқару жүйесімен жұмыс істейді. БӨ-нің бірнеше өзгеріс массивтерін қолдану келісіліп жасалады,себебі өзгерістің жеке массивтері сәйкес болмай қалуы мүмкін және олардың кезекті қолданылуы жұмысқа қабілетсіз БӨ пайда болуына алып келуі ықтимал. Сонымен қатар, өзгерістер массиві қақтығыса алады, егер олар бір құрауышта әртүрлі өзгерістер қарастырса. Бұл мәселелерді шешу үшін өзгеріс негізінде сәйкестендіруді қолдайтын нұсқаларды басқару құралы қолданылады,ол БӨ нұсқаларының келісілген тізбектігінің нақты ережелерін бекітуге жол береді.

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

Қолданылатын тәсілдер мен стандарттар: ұйымдастыру процесі; кодтау стандарты. Қолданылатын        шаблондар:        пайдаланушы        құжаттамасы; шолу бойынша есеп; жоба статусы жөнінде есеп.

Бақылау сұрақтары Бағдарламалық өнімді жасау сатысында қандай тәсілдер, стандарттар мен шаблондар қолданылады?

10.1. Тестілеудің жалпы сипаттамасы мен оның циклі Тестілеу бағдарламалық код пен құжаттаманы тексеру бойынша қызметті білдіреді. Ол алдын-ала жоспарлану керек және арнайы тағайындалған тәуелсіз тестілеушімен жүйелі түрде өткізілуі тиіс. Тестілеуші жұмысы талаптарды сипаттауды бекіткенге дейін басталады. Ол БӨ-нің толықтыққа және тестілеу мүмкіндігіне талаптарын тексереді, тестілеу әдістерін анықтайды. Талаптарды жоспарлау мен оның сипаттамасын жасау сатысының басталуымен бір уақытта тестілеуші тестілеу стратегиясын жасайды. Талаптар сипаттамасы бекітілгеннен кейін ол тестілеу жоспарын жасап, оны тәптіштейді. Сол кезде тестілеуші интеграциялық және жүйелік тестілеуді өткізу үшін мәтіндер жиынтығын жасайды. Тестілеу өткізілу туралы барлық нәтижелер ұсынылатын тестілеу жөнінде есеппен аяқталады. Әрбір бағдарламалық бұйым үшін оның дұрыстығын тексеретін тесттер жинағы бол керек. Бағдарламалық бұйымды толықтай тексеруге жол беретін тестілеудің бірнеше деңгейі болады.

Тестілеу жүргізу

Нәтижелерге анализ жасау

Есеп беру Иә

Қателер анықталды ма?

Жоқ

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

Тестілеу циклі

Модульдік тестілеу.

Тестілеудің бұл түрі бағдарлама немесе бағдарламалық жүйе құрамына кіретін жеке бағдарламалық процедура мен ішкі бағдарламаны тексеру процесінен тұрады. Модульдік тестілеу тікелей жасаушымен өткізіледі және әрбір модульдегі барлық ішкі құрылым мен мәліметтер ағынын тексеруге жол береді. Тестілеудің бұл түрі жасау сатысының бөлігі болып табылады. Модульдік тестілеуде тестіленетін әрбір модульдің қамтуы 70...75% аз болмайтындай етіліп өткізілетіндей жасаушымен анықталатын тесттер жиынтығы жасалады. Модульдік тестілеу элементтері: синтаксистік тексеру Модульдік тестілеуді сәтті аяқтағаннан кейін барлық өзгертілген модульдер мен мәтіндер жинағы жобаның мәліметтер базасында сақталады.

Интеграциялық тестілеу . Тестілеудің бұл түрі жеке модульдердің біріккен жұмысын тексеру үшін өткізіледі және бүкіл жүйені бір тұтас жүйе ретінде тестілеуді жасайды. Интеграциялық тестілеу барысында модульдер арасындағы байланыс, олардың сәйкестігі мен функционалдығы тексеріледі. Ол тәуелсіз тестілеушімен жүзеге асырылады және тестілеу сатысы құрамына кіреді.

Интеграциялық тестілеу элементтері:

Интеграциялық тестілеу барысында табылған қателер қателердің мәліметтер базасына енгізіледі. Интеграциялық тестілеу нәтижесі тестілеу циклінің аяқталуында тестілеу барысы жөніндегі есепке қосылады.

Жүйелік тестілеу.

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

Жүйелік тестілеу элементтері:

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

Шығыс тестілеу.

БӨ-нің тапсырыс берушіге жеткізілуіне әзірлігі тексерілетін тестілеудің соңғы сатысы.  Тестілеудің  бұл түрін тәуелсіз тестілеуші өткізеді. Шығыс тестілеудің элементтері: Шығыс тестілеуде табылған қателер жобаның мәліметтер базасына енгізіледі. Шығыс тестілеудің сәтті аяқталуында БӨ тапсырыс берушіге тестілеу нәтижесі жөнінде есеппен бірге жеткізіледі. Қабылдаушы тестілеу. Тестілеудің бұл түрі орнату, бағдарламалық жүйені сүйемелдеу мен түпкілікті пайдаланушыны оқытуға жауап беретін ұйыммен өткізіледі.

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

Пайдаланушы интерфейсінің кемшіліктері.

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

Жеткіліксіз өнімділік.

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

Көптеген әртүрлі шектес жағдайлар бар. «Көбірек» немесе «азырақ», «ертерек» немесе «кешірек», «алғашқы» немесе «соңғы», «қысқарақ» немесе «ұзынырақ» ұғымдары қолданылатын бағдарлама жұмысының кез—келген аспектісі диапазон шектерінде міндетті түрде тексерілу керек. Диапазон ішінде бағдарлама тамаша жұмыс істеуі мүмкін, ал шектеулерде БӨ жұмысының

Есептеу қателеріне есептеу алгоритмдерін қате таңдау, қате формулалар, өңделетін мәліметтерге қолданылмаймын формулалардан пайда болатын қателер жатады. Есептеу қателерінің ішінде ең кең таралғандар дөңгелектеу қателері.

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

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

Жарыс оқиғасы.

Жүйеде екі оқиға күтіледі делік: А және Б. А оқиғасы бірінші болса, бағдарлама жасалуын жалғастырады, ал егер Б болса, онда бағдарлама жұмысында жаңылыс шығады. Жасаушылар әрдайым бірінші болып А оқиғасы шығып, Б жарысты жеңіп, ертерек шықпау керек деп күтеді. Жарыстың классикалық оқиғасы осындай. Жарыс оқиғасын тестілеу айтарлықтай қиын. Олар өзара әрекеттесін процестер мен ағындар параллель жасалатын жүйелер,сонымен қатар шынайы уақыттың пайдаланушысы көп жүйелер үшін типті. Мұндай жүйелердегі қателерді елестету қиын, және оларды табуға әдетте көп уақыт кетеді.

Шамадан артық жүктеме.

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

Компьютер аппаратурасымен қате жұмыс.

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

«қатып қалмай», оны ұғыну керек.

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

техникалық дәлдігі үшін жауап береді. Ол бағдарламаның сипаттама талаптарына сәйкестігі мен бағдарлама тәртібін мұқият тексеру керек. Мәтіннің қиын және шиеленіскен жерлеріне аса назар аударған жөн. Олар бағдарламаның өзінің сәтсіз жобаланған элементтерін көрсетуі мүмкін. Техникалық жазушы өнімді өзі қандай, тура солай етіп жазуға міндетті, сондықтан шиеленіскен жерлерді  жоюға  жобаны  өзгерту ғана көмектесе алады. Мұндай өзгерістің болуын талап ету маңызды, себебі соңында олар өнімді құжаттауды жеңілдетіп қана қоймайды, және оның қолданылуын жеңілдетеді. Құжаттамада өнімнің қандай да бір функциясы жіберілмегендігін тексеру керек. Техникалық жазушылар сипаттама, жеке жазбалар мен жасаушылармен сұхбаттарға негізделеді. Жасаушылар оларды істің мәнінде ұстауға тырысады, бірақ кейде бағдарламаға енді ғана енгізілген жаңа функциялар жөнінде айтуға ұмытып кетеді. Тестілеушілер техникалық жазушыларға қарағанда мұндай функцияларға ертерек тап болатындықтан, олардың сипаттамасы құжаттамаға түскенін бақылау керек. Сонымен қатар,егер анықталған функция басшылықта жазылса, ол интерактивті анықтамалықта да жазылады деген сөз емес. Ақпарат оңай жоғалып кетуі мүмкін. Тестілеуші БӨ басшылығына да, БӨ-нің өзіне де өзгерістер енгізуді талап етуге құқығы жоқ. Тестілеуші міндеті –мәселені табу, ал ол мәселемен не істеу керекгігін ол шешпейді. Сондай- ақ, тестілеушінің мәтінде стилистикалық өзгерту енгізуді сұрауға құқығы жоқ. Ол мұндай өзгерту енгізуді ұсына алады, алайда техникалық жазуы бәрі қалай тұр, солай қалдыруды шешуге құқылы және тестілеушіге дұрыс істеп жатқандығы жөнінде дәлелдеуге міндетті емес. Техникалық жазушымен өзара қатынас үшін мәселені қараудың формалды жүйесі әдетте қолданылмайды.Көптеген комментарийлер басшылықтың көшірмесіне енгізіледі. Техникалық жазушымен келісім бойынша мәтінде өзгертулер мен комментарийлерді көрсету тәсілі таңдалады. Комментарийлер көшірмесін сақтап, және сол бойынша құжаттаманың кезекті нұсқасын тексерген жөн.

Тестілеу мақсаты - мүмкін болатын қателерді іздеу. Сондықтан, тестілеу мысалдарын жасай отырып, бағдарламаның ауытқуы мен оның

Егер екі мәтін бір қатені табуға арналса, онда біреуін ғана орындаған жеткілікті;

тест өз категориясында ең жақсы болу керек.

Ұқсас тесттер тобында біреуі екіншісінен тиімдірек болуы мүмкін. Сондықтан, тестті таңдауда қатені табуға ықтималдығы жоғарысын алу керек.

тест тым жеңіл немес тым ауыр болмау керек.

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

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

Тесттер тобы, егер келесі шарттар орындалса, эквиваленттік классты құрайды. Аталып өткен абстрактілі шарттардан басқа тесттердің нақты тобын бір классқа жатқызуға мүмкіндік беретін практикалық белгілер бар. Мұндай белгілер ретінде келесі шарттарды орындауды қарастыруға болады: Эквиваленттілік класстарын іздеу – субъектілі процесс. Бір бағдарламаны анализдейтін екі адам класстардың әртүрлі тізімін жасайды. Алайда эквиваленттіліктің неғұрлым көп класстарын   табуға   талпынса,   соғұрлым   жақсы   болады. Ол келешекте уақытты үнемдеуге септігін тигізеді және

тестілеушіні эквивалентті тесттерді қажетсіз қайталаудан арылтып, тестілеуді тиімдірек етеді. Тесттерді класстарға бөліп, кейін олардың әрқайсысынан тиімді болып көрінетін бір немесе бірнеше тестті бөліп алуға болады; қалғандарын жасаудың қажеті жоқ. Эквиваленттілік        классын        іздеу        үшін        міне        қанша ұсыныстар бар:

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

Жасалатын класстар тізімін кесте түрінде ұйымдастырыңыз.

Әдетте эквиаленттілік класстары көп болады, сондықтан жиналған ақпаратты ұйымдастырудың ыңғайлы және ойластырылған тәсілі қажет. Көбінесе барлық ақпаратты үлкен кестеге жинастырады, оның мысалы 10.1 кестеде көрсетілген. Тізімге тек қана ұйғарынды ғана емес, сонымен қатар ұйғарымсыз немесе стандартты емес кіріс мәліметтері тесттері қосылғанына назар аударыңыз. Кесте түріндегі ақпарат түсінікті, оны қабылдау оңай және тез, ұйғарынды және ұйғарымсыз нұсқаларға бөлу айқын.

Линия 4см-ден ұзын. Линия түзу емес

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

Сандық мәннің диапазондарын анықтаңыз.

Мәннің әрбір жаңа диапазонымен соған байланысты эквиваленттіліктің бірнеше жаңа класстары пайда болады. Әдетте олардың арасынан үш ұйғарымсыз класс болады: диапазонның төмен шектес мәнінен төмен барлық сандар; сандық емес мәліметтер. Кейде бұл класстардың біреуі болмайды. Мысалы, кез-келген санды енгізуге болады. Бұл жағдайда расында да солай екендігіне көз жеткізу керек. Өте үлкен санды енгізіп, одан не шығатынын көру керек. Мәндерде диапазон ішілік зерттелетін параметрлердің бар жоқтығын тексеру керек.Әрбір ішкі диапазон эквиваленттіліктің жеке классы болады. Ұйғарымсыз класстар ең төмен диапазон- нан төмен және ең жоғарғысынан жоғары орналасады. Егер өріс немесе параметрлер үшін мәннің бекітілген тізімі болса, осы мәндердің қайсысы тізімге кіретінін анықтаңыз. Егер параметрге мәннің тек анықталған тізімі рұқсат етілсе, эквиваленттіліктің бір классы осы тізімнің барлық мәндерін қоса алады, ал басқасы – қалған мәндерді. Келесіде бұл екі классты кішірек класстар қатарына бөлуге болады.

Тізім мен мәзірден таңдаудың мүмкін болатын нәтижесін анализ жасаңыз. Опция тізімінің ұсынылған бағдарламасының кез-келген  элементі  эквиваленттіліктің  жеке   классын көрсете алады. Опция мәзірі немесе тізімінің әрбір элементі бағдарламамен ерекше түрде өңделеді, сондықтан олардың барлығы тексеруге жатады. Ұйғарымсыз мәндер классына тізімде жоқ пайдаланушы жауаптары жатқызылады ( егер бағдарлама тек таңдауға емес, сонымен қатар, опция мәнін енгізуге мүмкіндік берсе). Мысалы, егер бағдарлама «Сіз сенімдісіз бе? (Ц/Н» деген сұрақ қойса, онда эквиваленттіліктің бір классы  «Ц»  (  «д»- ны да тексеру керек) деген жауап қайтару керек, ал екіншісі – «Н» («н») жауабы. Қалған жауаптардың барлығы ұйғарымсыз болып табылады ( алайда бағдарлама оң болып табылмайтын барлық жауаптар, теріс болып табылатын, яғни «Н» жауабының эквивалиенті ретінде саналатын жауаптарды түсіндіруі мүмкін).

Уақытқа тәуелді мәндердің класстарын іздеңіз.

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

болады? Олардың біріншісіне міндетті орындауға біраз уақыт бұрын жасалатын барлық оқиғалар, екіншісіне міндетті орындау алдында қысқа мерзім ішінде жасалатын оқиғалар, үшіншісіне оның жасалу барысындағы оқиғалар және т.б. жатқызылады. Нәтижесі нақты жиынтық немесе мәндер диапазонымен шектелетін анықталған есептеулерде бірігіп қатысатын айнымалылар тобын табыңыз. Үшбұрыштың үш бұрышының шамасын жазыңыз. Ұйғарында классқа сомасында 180° беретін мәндер жатқызылады. Ұйғарымсыз мәндерді эквиваленттіліктің екі классына бөліге болады - 180° аз сомалық мәнмен және 180° көп. Қандай әрекеттерге бағдарлама эквивалентті оқиғалармен жауап беретінін қараңыз. Жоғарыда тек кіріс оқиғалары қарастырылды, себебі оларды сараптау оңай болды. Шығыс оқиғасының мысалы ретінде 10.1 кестедегі үшінші оқиғаны қарастырамыз. Бағдарлама 4 см-ге дейін линияның сызылуын қамтамасыз етеді, және линия түзу деп болжанады, алайда ол басқа формада болуы да мүмкін. Қандай кіріс мәліметтер линияның ұзындығы мен формасын басқаратынын анықтау қиындыққа соққызады. Кейде шығыстағы кіріс мәліметтерінің әртүрлі класстары бірдей эффект береді. Егер кіріс мәліметтерінің әрбір классының өңделуінің нақты жолы беймәлім болса, онда оларды әртүрлі класстар деп есептеп, жеке тестілеу керек. Шығыс ақпаратын жасау барысында анықталған кіріс мәліметтеріне жауабына қате түрленсе,онда басқару оның өңделу блогына берілетіндігі әсіресе маңызды.

Операциялық ортаның нұсқаралын ойластырыңыз.

Бағдарламаға монитор,принтер, модем, диск құрылғылары немесе жүйеге қосылған кез-келген басқа құрылғылардың типтерінде ғана жақсы жұмыс істейтіндер кездер болады. Бағдарлама жұмысы компьютердің тактілік жиілігіне байла- нысты болуы да мүмкін. Сондықтан, бағдарламаны сараптай отырып, әсіресе құрылғымен төмен дәрежелі операцияны жасайтын немесе оның анықталған мүмкіндіктеріне бағдарланатын бағдарламарға қатысты жүйенің эквивалентті конфигурация классын анықтау өте маңызды.

Эквиваленттілік класстарының шегі.

Эквиваленттіліктің әрбір классы үшін бір-екі тест өткізу жеткілікті. Олардың ең жақсысы класс шегінде жатқан мәндерді тексеретіндер. Бұл мәндер ең үлкен, ең кіші немесе тағыда басқаша болуы мүмкін, бірақ кез-келген жағдайда олар класс параметрінің шекті мәні болу керек. Салыстырудың қате операторлары (мысалы > орнына >) аргументтердің шекті мәндерінде ғана қате жасайды.

Бір        уақытта        диапазонның        аралық        мәнінде        жаңылысатын бағдарлама оның шекті мәнінде де сөзсіз жаңылысады. Эквиваленттілік классының әрбір шегін екі жағынан да тестілеу қажетті. Бұл тесттен өтетін бағдарлама аталмыш классқа қатысты қалғандырының бәрінен де өтеді. Міне мысалдар қатары: 1-ден 99-ға дейін мәндер ұйғарынды болса, ұйғарынды мәліметтерді тестілеу үшін 1-ден 99-ға дейін таңдауға болады, ал ұйғарынды еместерді тестілеу үшін - 0 мен 100. Егер бағдарлама бас әріпті ағылшын әрпін күтсе, A және Z басыңыз. @ таңбасын да тексеріп көріңіз, себебі оның коды A таңбасының кодына сәйкес келеді, және ] таңбасының коды Z таңбасының кодынан ереді. Сонымен қатар a және z таңбаларын теңсеріңіз. Егер бағдарлама ұзындығы 4 см-ге дейін линияның бір нүктесінен сызуды қамтамасыз етсе, бір нүкіте мен ұзындығы тура 4 см линия сызыңыз. Бағдарлама да нөлдік ұзындықтағы линияны сызуды қамтамасыз етуді көрсі. Кіріс мәнінің сомасы 180-ге тең болса, сомасында 179,180 және 181 беретін мәнді жазып көріңіз. Бағдарлама кіріс мәліметтерінің анықталған санын алса, анық қажетті санды жазып көріңіз, сонымен қатар бірлікке көп немесе бірлікке аз санды көріңіз.

Бағдарлама B,C және D жауаптарын қабылдаса, A және E жазып көріңіз. Файлды принтер тағы біреудің тапсырмасын шығарудың алдында және бірден содан кейін басып шығаруға жіберіп көріңіз.

Әрбір интерактивті бағдарламада бір ақиқат жағдайдан екіншісіне өтулер жүзеге асырылады. Ең оңай мысал ретінде мәзір бола алады. Бағдарламаны қосқаннан кейін онда пәрмендердің бір тізбегі болады. Олардың біреуін таңдағаннан кейін бағдарлама жағдайы өзгереді және мәзірде жаңа жағдайда қол жетімді пәрмендер пайда болады. Бағдарламамен ұсынылатын әрбір опцияны,мәзір пәрменін тестілеу керек. 10 пәрмені 9 немесе 22 пәрмендері бойынша ашылатын режимде қол жетімді бола алады. Бұл жағдайда 10 пәрменін екі рет – екі режимде тестілеу керек.Алайда мәзір пәрмендері, бағдарламаның барлық мүмкін режимдері мен  осы режимдерге өту жолдары өте көп болу мүмкін, және оларды тестілеу мүмкін болмайды. Сондықтан, тесттерді бағдарламаның орындалуы жолын тексеру үшін іріктей отырып,

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

әрекеттерді тестілеу; жоғарыда көрсетілгендердің ішінен ең қажетті тесттерді өткізуден басқа, бағдарламамен оның орындалу жолдарын кездейсоқ таңдау арқылы еркін режимде жұмыс істеу. Жағдайлар арасындағы өткелдер мәзір пәрменін таңдауға қарағанда әлдеқайда қиын болуы мүмкін. Мәліметтерді енгізудің құрамы мен кезекті формасының құрылымы өткен формада енгізілген ақпаратқа тәуелді болады,  бір  өрістің  мәні басқасының ұйғарымды мәнін анықтайды, анықталған ақпаратты енгізу қосымша сұраныстар сериясын бастамалайды. Мысалы, 1-ден 99-ға дейін сандарды енгізуде бағдарлама пайдаланушыға үнделген сұраныстың бір формасын шығарады, ал кез-келген басқа сандарды енгізуде – басқасын. Бұл жағдайда эквиваленттілік классы мен оның шектік мәндерімен бірге мәтіндердің толық жиынтығын жасау үшін бағдарламаны жасаудың мүмкін болатын жолдарын сараптау керек. Мәзір сызбасын жасау өте пайдалы. Мұндай сызбада жағдайлар арасында өткелдерді шақыратын бағдарлама мен пәрменнің барлық жағдайлары көрінеді. Оларға мәзір арқылы белсендірілетін пәрмендер, графикалық құралдар (мысалы, әртүрлі батырмалар) мен анықталған пернелерді  басудан  кейін жасалатын пәрмендер қосылады. Мысалы, сызбада « Файл» мәзірінен «Ашу»  пәрменіне,  кейін  «Файлды  ашу»  мен керісінше бағдарламаның негізгі жағдайына оралу жолы көрсетілуі мүмкін. Егер анықталған диалогтық терезені бірнеше тәсілдермен ашуға және одан бірнеше әртүрлі режимдерге шығуға болатын болса, онда бұл сызба өте ыңғайлы. Бұл жағдайда сызбада өткелдердің барлық бағыттарын суреттеп және солар бойынша бағдарламаны тестілеуге болады.Бұл бағдарламаның жағдайының маңызды өзара байланысын өткізіп алу қаупімен жоспарсыз бағдарламамен жұмысқа қарағанда, сенімдірек тәсіл. Екі жағдай арасында өткел жасап жатқан кезде бағдарлама жұмысына араласып көріңіз. Пернелерді басыңыз, әсіресе пәрмендік. Пернелерді басыңыз немесе бағдарлама мәліметтерді өндеу немесе кіріс-шығыс операциясын жасап жатқанда мәзір пунктілерін таңдаңыз, бағдарламаға  параллель  түрде  тағы  бір ақпаратты енгізуді немесе шығаруды ұсыныңыз.Мысалы,

файлды басып шығаруда оны тағы біреуін шығаруды сұраңыз.

Егер бағдарламада ол берілген уақыт ішінде анықталған оқиғаны күткенде, кейіннен ол басқа жағдайда өткенде тайм-аут жағдайы анықталса, оның пайдаланушы әрекетіне реакциясын, жүйе сұранысы немесе тайм-аут интервалы шектерінде күтілетін жағдайдың болуын тексеріңіз.Егер жағдай бағдарлама жағдайды күтуді тоқтатқанға бірнеше секунд қалғанда, немесе бірнеше секундтан кейін болса не болатынын көріңіз. Жүйені жоғары жүктемеде тестілеңіз.Мультиберілген ортада бірнеше басқа бағдарлама қосып, сіздің бағдарламаңыз өзін қалай ұстайтынын қараңыз, ол өз жұмысын сәтті жасайды ма жоқ па. Процессор әрдайым баспаға қызмет көрсетуге ауысуы үшін принтерге үлкен файл жіберіңіз. Көптеген сыртқы құрылғылар қосып, оларды тоқтату қаншалықты болатындай етіп түрлендіріңіз.Қысқаша сөзбен, қаншалықты мүмкін болғанша компьютерді баялатып, жүктеңіз. Нәтижесінде сіздің бағдарламаңыз баяуырақ жасалып, және мәліметтерді тезірек енгізіп, оның қабылдау мүмкіндіктерін арттыруға болады.  Егер жұмыстың қалыпты режимінде бағдарлама жаңылысына қол жеткізу мүмкін емес болса, жоғары жүктемеде оған қол жеткізуге болады. Асажоғарыжүктемеде бағдарламаны «стандартты» тестілеуді жасай отырып, жарыстың мүлдем күтілмеген жағдайларына тап болуға болады. Егер бұл байланыста бағдарлама осал болса, онда мұндай жағдайда тестілеудің толық циклін өткізу қажетті. Басты мақсат – бағдарламалық қамтамасыз ету жай жұмыс істесе де, бірақ кез-келген жүйеде және кез-келген қосымша жүктеуде ауытқусыз істейтіндей етіп, жасалатын бағдарламалық қамтамасыз  етудің осындай  сенімділігін   қамтамасыз   ету.  Ең дегенде, бағдарламаны пайдалану үшін жүйенің қандай конфигурациясы шекті болатынын нақты анықтау керек. Құжаттамада анықталған БӨ мүмкіншілігінің шектеулерін тестілеуді ұмытпаған маңызды. Бағдарлама жұмыс істей алатын файлардың максималды санын немесе басқа да құрылымдық мәліметтерді ашыңыз, оны сондай жағдайда ұзағырақ пайдаланыңыз. Егер құжаттамада шектеулер жазылмаса, бірақ кейбір параметрлердің логикалық рұқсат етілген мәндері болса, онда оларды да тексеру керек. Егер бағдарлама пайдаланушы енгізе алатын үлкен сандық мәнді жасай алмаса, онда қате жөнінде есеп жасалады. Ал егер бағдарлама параметрлердің өте кішкентай, сонымен қатар, ең үлкен мәндерді қабылдап, өңдесе,

онда оларға шектеу болмауы мүмкін.

Әртүрлі аппараттық ресурстар аяқталса, мысал, диск толып кетсе немесе принтерде қағаз бітсе, онда бағдарлама өзін қалай ұстайтындығын тексеру керек. Жүйеде өте аз орын қалса не болатынын анықтаңыз, компьютерді айтарлықтай жүктеңіз де, не болатынын көріңіз. Жүктемелік тестілеу – шектес шартты тестілеудің бір түрі болып есептеледі. Оны өткізу сызбасы өте ұқсас. Бірінші бағдарламаны өзі жұмыс істейтін жағдайда қосады, кейін ол бейімделмеген ортада қосады. Әртүрлі ілінген жүктемелерді бөлек-бөлек орындап, бағдарлама олардың бірге болуына шыдамайтындығы   әбден   мүмкін.   Жүйені   жүктеп,   бір-  екі тест жасап қана қоймай, ұзақ және себепті тестілеулер жасаңыз. Осындай жағдайда бағдармаланы біраз уақыт пайдаланыңыз,бірден болмаса да, бірақ ауытқу сонда да болатынын байқайсыз. Кейде        тестілеуші        тесттердің                анықталған        классы бағдарламаның        ауытқуын        шақырады                        дейді,        алайда        оны логикалық жағынан түсіндіре алмайды. Өз түйсігіңізге сеніңіз және мұндай тесстерді міндетті түрде жалпы жоспарға қосыңыз. Шектес болмаса да, бірақ бағдарламалық ауытқуды шақыратын жағдайлар мен мәндердің бір қатары бар. Мұндай мәндердің типтік мысалы 0 болып табылады. Неліктен анықталған кіріс мәні немесе бағдарламаның орны сізге күмәнді екендігін анықтауға уақыт жоғалтудың қажеті жоқ.Тек қана оны тестілеңіз. Қиын        жағдайда                түйсік                тривиалды        логикаға                қарағанда тестілеудің ең жақсы тактикасын айтатын жағдайлар болады. Ассоциативті байланыс орнайтын кездер де болады: сіз мұндай жағдайларда қате тапқансыз, бірақ оны есте сақтамауыңыз мүмкін. Қалай болғанмен, өзіңіздің ішкі сезіміңізге сеніңіз және оны тыңдауды үйреніңіз: тәжірибемен ол одан әрі дамиды және

сенімді болады.

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

есептеудің эквивалентті тәсілдері қолданылды деген сөз.

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

Функционалды эквиваленттілікті тестілеуді автомат- тандыру.

Функционалды эквиваленттілікті тестілеу әдісін қолдануға болатын барлық жерде ол ең жақсы таңдау болады. Егер функция қиын болса, ол уақытты жақсы үнемдеуге және автоматтандырылмаған есептерде пайда болатын қателерді болдырмауға көмектеседі. Салыстыру процесін де, мүмкіндігінше, автоматтауға болады. Есептер нәтижесін файлдарға шығару және олардың кезекті салыстыруын сәйкес бағдарлама бойынша жасау ең оңай тәсіл болып табылады. Компьютер файлдарды салыстыруды жылдамырақ және ұқыптырақ жасайды. Нәтижелердің ұйғарында қайшылықтарын да, мысалы дөңгелектеу қателігін, анықтауға болады. Сонымен қатар, тестілеудің шығыс мәліметтерін енгізуден бастап шығыспен салыстырғанға дейінгі бүкіл процесін автоматтау да мүмкін. Егер олай болса, тестілеу процедурасы сол сәтте және сенімді түрде жасалады. Осындай тесттерді автоматтау аса қиын емес процесс болғанымен, айтарлықтай уақытты талап етеді. Егер бағдарлама файлдың кіріс мәліметтерін санай алса, онда оны дайындау керек. Сонымен қатар, нәтижелердің салыстырылуын жасайтын кішігірім бағдарламашаларды жазуға тура келеді. Функционалды эквиваленттілікті тестілеу айтарлықтай шығынға әкелуі мүмкін. Нәтижелерді салыстыру үшін пайдаланылатын сенімді эталондық бағдарлама ондай арзан болмауы мүмкін. Сонымен бірге, кейбір бағдарламашалар жазуға тура келеді. Қосымша техника да қажет болуы мүмкін, мысалы екінші компьютер. Мұндай тестілеуді өткізуге қанша ақшалай құрал кететіндігі жөнінде әмбебап белгіні анықтауға болмайды. Алайда арнайы өлшем бар. Бірінші кезекте, бағдарламаны қолмен тестілеуге қанша күн кететіндігін бағалаңыз. Уақыт есебіне есептеуді жоспарлау, орындау мен тестті өткізуді қосыңыз. Әрбір тестті бірнеше рет өткізу керектігін ұмытпаңыз, себебі сіз қателерді табасыз және

тестілеудің бүкіл процедурасын басынан бастауға тура келеді. Тестілеудің қанша циклі қажет болатындығын санаңыз. Тестілеудің автоматтандырылған құралы қанша уақыты- ңызды үнемдейтінін де бағалаңыз. Бүкіл процесті тағы есеп- теңіз: жоспарлау, бағдарламалау мен тестті ретттеу. Қажетті уақытты барынша шынайы түрде бағалауға тырысыңыз. Үнемдеуге ұйғарылатын күндер санын өзіңіз екі есе айлығыңызға көбейтіңіз. Айлық сомасы екіге көбейтіледі, себебі компания тестілеу процесін жылдамдату мен оның сенімділігін арттырудан алатын пайда да есепке алынады. Егер сіздің есебіңіз дұрыс болса, онда алынған сома – бұл эталондық бағдарлама көмегімен функционалды тестілеуде үнемдеуге болатынның минимумы.Егер бағдарламаның өзі осы сомадан аз болса, онда кез-келген саналы басшы оның сатып алынуын құптайды. Сатып алынатын эталондық бағдарлама мен есептер негіздерін түсіндіретін ұсыныс пен презентацияны дайындаңыз. Егер компания оған қосымша ақша салатындай  жасауға кететін уақытты қысқартуда қызығушылық туғызбаса, өнімнің сенімділігі мен сапасы арқасында салынған ақшаның орны кепілді түрде толықтырылатынын түсіндіріңіз.

Сезімталдық анализі.

Функционалды тестілеуді автоматтау қолмен тестілеуге қарағанда айтарлықтай көп тест өткізуге  жол береді. Алайда олар абсолютті толық тестілеу жасау үшін өте мұқият таңдалуы керек, себебі кіріс мәліметтерінің мүмкін болатын мәндер саны әлі де көп болуы мүмкін.Көптеген функцияларда аргументтердің мүмкін болатын мәндердің саны шексіз, сондықтан оларға компьютердің де күші жетпейді. Міндетті түрде шектес мәндерді тексеру керек болады. Ең жақсы тесттерді қалай таңдауға болады? Көбінесе ол үшін сезімталдық анализі қолданылады. Бұл процедура келесілерден тұрады. Бірінше кезекте, анықтаудың бүкіл саласында орналасқан параметрлер қатары үшін оның мәндерін есептеп, функцияның тәртібі жөнінде жалпы көрініс алады. Кейіннен аргументтердің кішігірім өзгерістері нәтижеленетін мәндердің едәуір шабысын шақыратын анықтау салаларының жерлерін іздейді. Дәл осындай жерлер қателерге ұшырауға жақын болады. Бағдарламаланатын функция мен оның эталонын тестілеу нәтижесінде алынған мәндер келіспеуі мүмкін. Егер есептеу процесінде операциялар құбылмалы үтірмен орындалса, онда нәтижелерді дөңгелектеуге немесе қиюға тура келеді, демек, кішігірім айырылыстар болады. Әдетте  ол  қорқынышты  емес. Басқа да себептермен пайда болған арттырылған айырылыстарды бекітуге болатындай етіп, дөңгелектеудің ұйғарымды ауытқуларын дұрыс бағалау керек.

Тестіленетін кіріс мәндерінің әрбір диапазонын ішкі диапазондар қатарына ( олар 100-ге жуық болуы мүмкін) теңдей бөлу және әрқайсысының ішінде бір мән бойынша тестілеу ұсынылады. Бір нәрсе дұрыс емес кетсе, уақытты босқа жоғалтпас үшін, әрбір мәнді енгізгеннен кейін нәтиже дұрыс болғандығын тексеріңіз. Функция тәртібінің жалпы көрінісін алып, оны шұғыл әрекеттер затына сараптаңыз. Егер анықтаудың жеке салаларында функция мәні күрт жоғарыласа немесе төмендесе, не ажырау мен секірулер болса, онда оларға аса назар аударған жөн. Қандай да бір кіріс диапазонында (немесе олардың айырымы эталондық функциямәніменбірге) функциямәнікүртөстідерлік. Осы диапазонды 100 бірдей бөлікке бөліп, әрқайсысының ішінде бір мән бойынша тексеріңіз. Егер бәрі дұрыс болса, сіз барлық тестіленетін аргументтер үшін тестіленетін және эталондық функциялар мәні сәйкес келетіндігіне көз жеткізесіз,ал егер олай болмаса, онда сіз қате таптыңыз. Математикалық функцияны кәсіби тестілеуде ықтималдық теориясынан білім қажет болады. Егер әңгіме бір емес, функцияның бір қатары жөнінде болса, функцияны анықтау саласының критикалық жерлерін іздеудің тиімді және ғылыми дәлелденген технологиялары қажет, яғни, оның мәні күрт өзгеретін немесе эталондықтан айрықшаланатын жерлерде.

Кездейсоқ енгізу.

Бірдей жердің анықталған санына функцияны анықтаудың барлық тестіленетін саласын бөлудің орнына кіріс мәнін таңдаудың басқа жолын – кездейсоқ – таңдауға болады. Мәннің кездейсоқ таңдауы тиімдірек,себебі ол олардың толық тең құқылы болуын кепілдейді. Мысалы, 0,02;0,04;0,06 және т.б кіріс мәндерінің осындай мәндерін тестілей отырып, сіз бағдарлама тақ сандарды (мысалы, 0,03) немесе мәнді цифрлардың көп санымен сандарды (мысалы, 0,1415) қалай өңдейтінін ешқашан білмейсіз. Сол уақытта кездейсоқ образда кіріс мәндерін таңдауда функцияны анықтау саласы толық толтырылады, кіріс мәліметі мәнінің барлық типтері мен диапазондары бірдей алынады. Егер сіз кіріс мәліметтерін таңдау әдісін таңдауда қиналсаңыз немесе тестіленетін функция тәртібіне сенімсіз болсаңыз, кездейсоқ әдіске тоқталыңыз.Ол автоматты тестілеу үшін де сай келеді. Нақты кіріс мәнін таңдау үшін айқын түсіндірудің болмауын өткізілетін тесттер санымен толтыруға болады. Мұндай ешқандай шектеу жоқ – эквиваленттіліктің әрбір классы үшін қаншалықты көп тест өткізілсе, соншалықты жақсы болады. Әдетте кездейсоқ кіріс мәндерімен автоматтандырылған тестілеуде кем дегенде 1000 есептеу жасалады.

Кездейсоқ сандар генераторын қолдану.

Кездейсоқ енгізу « ойға келгеннің бәрі» дегенді білдірмейді, әйтпесе ол функцияны анықтау саласында бірдей қамтуға үміттену үшін тым біржақты болады. Кездейсоқ сандарды шексіз санда түрлендіре алатын компьютерлік бағдарлама сай келеді. Алайда көптеген ұқсас бағдарламаларменқолданылатыналгоритмдермүлдемкездейсоқ еместігін есте сақтаған жөн. Сонымен қатар, бағдарламаларда тіпті базалық алгоритм нақты жасалмаған. Сондықтан, тіпті беделді компаниямен жасалған немесе бағдарламалаудың стандартты тілдерінің біріне салынған кездейсоқ сандар генераторын таңдамас бұрын, оның жұмыс негізіне қандай алгоритм қойылғанын және ол сіздің қажеттіліктеріңізге сай келетіндігін анықтау керек. Экранда түрлі түсті салют алуға жол беретін оңай бағдарламаға сай болатын нәрсе қиын инженерлік бағдарламаны кәсіби тестілеуге сай келмеуі мүмкін. Кездейсоқ сандар генераторы тіпті өте үлкен болса да, анықталған интервал арқылы олардың тізбектігін қайталайды. Осылардың барлығына байланысты келесі кеңестерге құлақ салыңыз. Кез-келген бағдарламаға ол бар болғандықтан ғана сенудің қажеті жоқ, басқасын да іздеп көру керек. Бағдарламаны ұғынуға тырысып көріңіз, және ол сізге толықтай түсінікті болғаннан кейін ғана, оны қолданыңыз. Егер сіз бағдарламау тіліне енгізілген кездейсоқ сандар генераторын қолданайын деп жатсаңыз, оны тағы кішкене жасау керек. Оның көмегімен сандардың көп бөлігін түрлендіріп (100...1000), оларды араластырыңыз: сол генератормен берілетін кезекті сандар  көмегімен  олардың  тәртібін  ауыстырыңыз.  Ол жұмысты баяулатқанмен, нашар бастапқы генератор жағдайында да нәтиже айтарлықтай жарамды болуы мүмкін.

Эквиваленттілік технологиясын қолдану.

Математикалық функцияны тестілеу – эталондық бағдарламаны қолданудың жалғыз емес саласы. Дайын және тексерілген БӨ-мен салыстыру жолымен бағдарлама тәртібінің әртүрлі аспектілерін тестілеуге болады. Олардың кейбір мысалдары төменде сипатталады. Бұрыннан бар бағдарламалардың біріндегі алгоритмнің негізінде жатқан емлені тексеру бағдарламасы тексерілсе, онда екі бағдарламаға бірдей сөздер жинағын тексеруді ұсынуға болады. Сөздерді автоматты ауыстыру бағдарламасы тестіленсе, әсіресе егер басқа тіл үшін оның алгоритмінің модификациясы жасалса, онда бағдарламалық қамтамасыз ету нарығында сатылатын тексеріген бағдарламаны тексеріс үшін алуға болады, мәтіннің тар бағанасын жасап,оны екі бағдарламаға ұсыну керек. Тармақ жалпақтығы бойынша мәтінді туралауды жасайтын бағдарламаны тестілеуде ол сөздерді аралықтармен қаншалықты

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

Әрбір нақты жағдайда осы технологияның «жақтаушы» және «қарсы» өзіндік аргументтері болады. Мысалы, оны іске асыруға тым көп уақыт, құрал немесе күш қажет болады. Сонымен қатар, эталондық бағдарламада да қателер болуы мүмкін. Бірақ қандай болғанымен, эквиваленттілікті тестілеу әдіснамасында назар аударған жөн – оны қолдану жұмысты жылдамдатады және оның тиімділігін бірнеше есеге арттырады. Қателер жөнінде есепке екі бағдарламадан алынған шығыс мәліметтерін қосуды ұмытпаңыз. Олар қате себебін іздеу үшін өте маңызды.

Жалпы мәліметтер.

Тестілеушінің негізгі жұмысы регрессиялық тестілеу болып табылады. Бұл терминнің екі мәні бар, оларды жасалған тесттерді қайталамалы қолдану идеясы біріктіреді. Тестті өткізгеннен  кейін  қате  табылып,  бағдарламашы оны жөндеді деп елестетіңіз. Тестілеуші ол қате толықтай жойылғандығына көз жеткізу үшін ол тестті қайтадан жасайды. Осы - регрессиялық тестілеу.Бағдарламаның жөнделген фрагментін жақсылап тексеру үшін бастапқы тесттің бірнеше вариациясын өткзіге болады. Бұл жағдайда регрессиялық тестілеу міндеті – табылған қате бағдарламашымен толықтай жойылды және ендігі шықпайтындығына көз жеткізуде. Регрессиялық тестілеуді қолданудың екінші мысалы. Қате табылып, жойылғаннан кейін тесттердің стандарттық сериясы жасалады, бірақ басқа мақсатпен: бағдарламаның бір бөлігін жөндеп, бағдарламашы басқасын құртпағандығында. Бұл жағдайда бағдарламаның жөнделген фрагменті емес, толықтай бағдарламаның өзі тестіленеді.

Қатені жою бойынша ұсыныстар.

Қате жөнінде есепті алып, бағдарламашы бағдарламаның бастапқы кодын мұқият сараптап, қате себебін тауып, оны жойып, нәтижені тестілеу

керек.Бұл идеалды нұсқа. Тәжірибеде кейбір бағдарламашылар қатенің өзін емес, есепте көрсетілген қатенің болу белгілерін ғана жояды. Нәтижесінде қатенің кейбір көріністері жойылады, бірақ қалғандары қалады. Кейде бағдарламашы есепті дұрыс түсінбей, қажетсіз нәрсені жоятын кездер болады. Кейбір жосықсыз қызметшілер өз жұмыстарын мүлде тексермейді, қарамай-ақ, түзетулер енгізіп, бағдарламаны тез арада тестілеушіге қайтарады. Нәтижесінде ескі қате қалып, жаңалар пайда болады. Тәжірибелі тестілеуші мұндай жағдайларға дайын болу керек. Бағдарламаға енгізілетін үштен бір түзетулер істемейді немесе істеп тұрған нәрсені бұзады деп саналады. Бағдарламашымен енгізілген түзетулерді тексеретін тестілеуші алдына қоюға тиісті үш міндет:

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

байланысты қатені табуға тырысу.

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

бағдарламаның қалған бөлігін тестілеу.

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

жасалады.Ол бағдарламашылар кезекті жұмыс нұсқасын тапсырғанда әрдайым жасалатын және бүкіл бағдарламаны қамтитын тесттердің толық жинағы. Бұл жағдайда тестілеуге біршама уақыт жоғалтуға тура келеді, бірақ бүкіл процедура еңбек көлемді болмайды. Тестілеуге бағдарламаның кезекті нұсқасы ұсынылғанда және кітапхананың бүкіл тестін қайталау уақыты болғанда біршама сұрақтар қатары туындайды. Кітапхана қаншалықты кең? Кітапхананың барлық тестілерін қайтадан жасау керектігі рас па? Регрессиялық кітапханаға қандай тесттерді қосу керектігін әрдайым алдын ала анықтау оңай емес.Сондықтан алғашында онда шынымен қажетті тестке қарағанда, көбірек тест болуы мүмкін. Кем дегенде, оған шектес шарт пен уақыт сипаттамаларын тексеру үшін мысалдар кіру керек. Бірақ олардың барлығын әрдайым жасау керек па? Регрессиялық тестті әдетте жасауға құлқы болмайды, себебі ол тестпен қатені табу ықтималдығы жоғары емес. Тестілеуді алғашқы жасауда тесттердің кейбіреуі қате табуы мүмкін, бірақ олардың толықтай жойылуынан кеін сол тесттерді қайта-қайта

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

Кітапхананың басқа тесттеріне эквивалентті тесттерді жойыңыз. Негізі мұндай тесттер кітапханаға мүлде түспеу керек, бірақ ол бірнеше қызметкерлермен жасалса, мұндай жағдайлар болуы мүмкін.

Объектісі жойылған қате болып табылатын тесттер санын азайтыңыз .Егер қате немесе оның кейбір түрлері тестілеу циклінің қатарында пайда болса, онда кітапханаға оларды табу үшін тесттердің жеткілікті санын қосу керек. Ол айтарлықтай қалыпты және орынды құбылыс. Бағдарламаның сәйкес бөлігін қатенің ізі қалмайынша мұқият түрде тестілеу керек. Алайда одан кейін жойылған қатені іздеуге бағытталған тесттердің көп бөлігін кітапханадан жоюға болады.

Тесттерді қиыстырыңыз.

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

Мүмкіндік бойынша тестілеуді автоматтаңыз.

Егер сіз тесттердің анықталған тобы тестілеудің бес немесе он кезекті циклінде жасалатындығына сенімді болсаңыз, онда автоматтауға уақыт бөлген жөн.

Тесттер бөлігін кезекті орындауға бөліңіз.

Регрессиялық кітапхананың барлық тесттерін бағдарламаның әрбір өзгерісінен кейін жасаудың қажеті жоқ. Оны сирегірек жасауға болады – әрбір екінші немесе үшінші циклда. Тестілеудің соңғы сатысында бағдарлама қосылуға дайындығына көз жеткізу үшін тесттердің максималды мүмкін болатын санын орындаған жөн, басқа циклдерде бүкіл тесттің жартысы немесе тіпті үштен бір бөлігі жеткілікті. Регрессиялық кітапхана жасалған тесттердің ішінен ең жақсысын қосу керек, егер ол өте көп болса, жаңа тесттерді жасауға уақыт қалмайды. Бірақ жаңа тесттер жоғары ықтималдықпен әлі табылмаған қателерді табады. Сондықтан жұмысты регрессиялық кітапхана тестілеудің тиімділігін арттыру құралы ретінде, тежеуіші ретінде емес, қызмет ететіндей жоспарлау керек.

Тесттерді орындау.

Жақсы тест ойлап табу – ол істің жартысы ғана. Оны тағы дұрыс орындау керек. Міне бірнеше ұсыныстар:

Егер сіз бағдарламаны компьютерге орналастыруда пайдаланушыда конфигурацияны таңдау мүмкіндігі болғанын қаласаңыз, орнату бағдарламасын қосу мен қажетті опцияларды ұсынатындығын  қарау   ғана   жеткіліксіз.   Бағдарламаның өзін әрдайым қосып, таңдалған конфигурация расында да орнатылғандығын тексере отырып, орнатудың әрбір нұсқасын жасаңыз.Бағдарлама бұл ретте толықтай жұмысқа қабілетті екендігіне көз жеткізіңіз. Егер бағдарлама басылатын бет, бос жер мен басқа да ұқсас ақпаратты көрсетуге мүмкіндік берсе, құжат экранда дұрыс бейнеліп тұрғанын көріп, ол іс жасалды деп санамаңыз.Оны басып шығару қажет. Егер бағдарламада ASCІІ кеңейтілген жиынтығының таңбалары қолданылса, оларды экранда көру жеткіліксіз. Олар дұрыс басылып шығып, модем арқылы жіберілу керек және т.б. Шығыс мәліметтері жіберілетін барлық бағдарламалық қамтамасыз етуді есепке алған жөн: құрылғы драйверлері, импорт алгоритмі. Келтірілген ұсыныстардан шығатын негізгі ережені келесідей құрастыруға болады: мәтіндік процедура бағдарламаны енгізілген мәліметті қолдануға және олар дұрыс қолданылатындығын растауға мәжбүрлеу керек. Тестілеу фазасында жоспарлы мерзім мен көлемдердің шынайы көрсеткіштермен айырмашылығы, өткізілген шолулардың саны, табылған қателер мен дефекттер, сонымен қатар орташа еңбек шығыны мен тестілеу өнімділігін бағалауды жасау керек. Сонымен қатар, ашық және жабық дефекттердің қатынасы мен тестілеу арқылы БӨ өтеуі метрикасын жинау өндірілу керек. Барлық алынған мәліметтерді бағдарламалық топтың ИМБ сақтау керек.

Қолданылатын құрал: құжаттарды даярлау жүйесі (мысалы, MS Word). Қолданылатын тәсілдер мен стандарттар: ұйымдастыру процесі; метрикалық бағдарлама. Қолданылатын шаблондар: тестілеу нәтижесі жөнінде есептер; тестілеу барысы жөнінде есептер; БӨ жеткізу туралы есеп; жеткізілетін БӨ бойынша басшылық; тестілеу жоспары; тестілеу процедурасын сипаттау; шолу бойынша есептер; жоба жағдайы жөнінде есептер.

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

БӨ сүйемелдеу – жеткізілетін БӨ-нің жаңа жағдайға бейімделу процессі, оның негізгі функциясын өзгеріссіз етіп сақтауда пайда болған мәселелер немесе модифицкациядағы қажеттіліктерден туындаған БӨ мен сәйкес құжаттамаға өзгеріс енгізу. БӨ сүйемелдеу сүйемелдеуші ұйыммен немесе БӨ жасаған ұйымның сүйемелдеу қызметімен жасалады. Сүйемелдеумен ІEEE-90 стандартына сәйкес табылған қателерді жою, өнімділікті арттыру немесе жұмыс немесе талаптар шартының өзгеруіне бейімделуді арттыру мақсатымен БӨ-ге өзгеріс енгізу болып табылады.

Сүйемелдеу элементтері:

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

Сүйемелдеу процесі өзіне келесі негізгі әрекеттерді қосады. модификацияны орындау мүмкіндігі, оның типі (түзейтін, жақсартатын, профилактикалық немесе жаңа ортаға бейімделуші); масштабы (модификация өлшемі, құны мен оның іске асу уақыты); сыншылдығы (сенімдік, өнімділік пен қауіпсіздікке әсер ету) зерттеледі; Сүйемелдеу сатысында БӨ-нің жаңа нұсқасын шолу бойынша келесі есептер жасалады: сүйемелдеу метрикасы бойынша; БӨ өміршеңдік циклінің аяқталуы (БӨ өлімі) жөнінде.

Сүйемелдеу сатысында БӨ жеткізілуінен кейін табылған кінәрәттар санын анықтау, сонымен қатар өзгерістерді енгізудің еңбек қамтуын бағалалау керек. Барлық алынған мәліметтерді жобалық топтың ИМБ сақтаған жөн. Аталмыш сатыда БӨ-нің өміршеңдік циклінің өткен сатыларының сипаттамаларында айтылған барлық аспаптық құралдар (6.6, 7.6, 8.5, 9.5 мен 10.6 бөлімшелерді қараңыз) және өзгеруге сұраныс шаблоны қолданылады.

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

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

РА-жеткізу — Альфа-нұсқаны жеткізу; РВ-жеткізу — Бета-нұсқаны жеткізу; RP-жеткізу — соңғы жеткізу. Прототип жүйеде бекітілген концепцияны көрсету,талаптар нұсқаларын тексеру, сонымен қатар жасау барысында,  және БӨ қолданысы барысында пайда болатын мәселелерді іздеу, мен оларды шешудің мүмкін болатын нұсқаларын іздеу үшін

қолданылатын БӨ-нің бастапқы нұсқасы болып табылады.

Пайдаланушылар мүмкіндігінше ертерек тәжірибе жасау үшін БӨ прототипін жылдам жасау өте маңызды. Альфа-нұсқа прототипіне қарағанда БӨ барлық немесе барлығы дерлік БӨ-нің барлық негізгі функцияларын іске асырады, бірақ олардың кейбіреулері әлі болмауы немесе қатемен жасалуы, тұрақсыз болуы мүмкін.  БӨ  даралығы ендігі толықтай жасалды, оның негізгі ерекшеліктері мен мүмкіндіктері көрінген. Спецификация, конструкторлық құжаттама, анықтамалық жүйемен пайдаланушы құжаттамасы дайын деуге болады. Альфа-нұсқаны әдетте тек тапсырыс берушілерге береді. Бета-нұсқада БӨ-нің жоспарланған функциясының толық жиынтығы іске асырылады. БӨ-де фатальды қате жоқ, айтарлықтай қателер де өте аз. Барлық жобалық құжаттар дайын және БӨ тапсырыс беруші талаптарына сай. Анықтамалық жүйе мен пайдаланушы құжаттамасы толықтай дайын. Өнімді үшінші пайдаланушыларға тестілеуге беруге немесе жарнамалық мақсатта таратуға болады. Соңғыжеткізу БӨ жасаубойыншажобажұмысыныңаяқталуы мен сүйемелдеу сатысына өтуді білдіреді. Өнім өзімен бірге жүретін құжаттамасымен бірге тапсырыс берушіге беріледі.

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

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

Жеткізілетін өнімді шолу үшін ұйымдастыру процесінде анықталған процедураға сәйкес шолуды дайындау мен өткізуге жауапты басшы тағайындалады. Шолу барысында жеткізілетін  өнім  толықтығы  мен жеткізу процедурасының дұрыс жасалуы тексеріледі. Барлық шығарылатын өнім БӨ жеткізу бойынша басшылыққа сәйкес классификациялану керек.

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

БӨ-нің бұзылуға тұрақтылығы – бағдарламаны жасауды жалғастыру мүмкіндігінсақтаудажекеқатені түзеу мүмкіндігінде болатын БӨ қасиеті.

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

Процесті жасау барысында бас тарту – бастапқы өнімдегі қате арқылы процесте қолданылатын оқиға соңғы нәтижеде анық болатын шығыста қатені шығарады.

Процесті жасаудағыауытқупроцесте қате кірісмәліметпен қолданылатын және процесте немесе процесс қатысты болатын жүйеде қате жағдайды шақыратын ауытқу.

Тұрақтылық

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

тобы үшін анықталған мәнге ие. Толықтай жұмысқа жарамсыз немесе қате жұмыс істейтін бағдарлама ешкімге ұнамасы анық. 13.1 суретте 1977 жылы Р.Маккол, Б.Ричардс пен С. Уолтерспен ұсынылған сапа факторларының типологиясы көрсетілген. «ІEEE. Standart Glossary of Software Engіneerіng Terms» («ІEEE. Бағдарламалық инженерияда қолданылатын стандартты терминдер тізімі») баспасы БӨ сенімділігін жүйе немесе оның құрауышының берілген уақыт мерзімі ішінде ұсынылған жағдайда талап етілетін функцияларды орындау қабілеті ретінде анықтайды. БӨ сенімділігі дәрежесі жасау процесінің жетілуіне тәуелді болады. БӨ сенімділігіне ықпал ететін негізгі көрсеткіш Сенімді БӨ жасау процесі, аппараттық қамтамасыз етуге қарағанда,аппараттық қамтамасыз ету мен 13.2 және 13.3 суретте көрсетілген, мұндағы Х – ауытқулардың жоспарлы саны, U-түрлі дәстүрлі қисықтар түріне ие БӨ сенімділігінің модельдерін көрсететін уақытқа тәуелді емес.

Өнімді пайдалану Дұрыстылық        Тиімділік        Тұтастық        Сенімділік        Қолданылуы

l

Уақыт

БӨ сенімділігін бағалау тәсілі әлі толықтай жасалмаған, бірақ егер болған ауытқу туралы мәліметтерді сәйкес бағалауды жасамаса, сенімділіктің шынайы деңгейін анализдеу үшін қажет кеңейтілген статистикалық модельдерді жасау да мүмкін емес болады. Әлі күнге дейін шектеудің шектен тыс санына ие емес сенімділікті бағалаудың бір де бір сенімді сандық тәсілі жасалмады. БӨ сенімділігі дәрежесін әртүрлі тәсіл арқылы жақсартуға болады, дегенмен, жасау уақыты, оның бюджеттік құны мен БӨ-нің қол жеткізілген сенімділігі үшін төленген жоғары болып көрінетін құны арасында қажетті қатынасқа қол жеткізу қиын болады.

Аппараттық қамтамасыз етуге қарағанда БӨ уақыт өте келе «тозбайды», жай ғана оның жаңа дефектері шыға береді. 13.3 суретте көрсетілген U-түрлі қисық бағдарламаны қолдану бойында ауытқуларды орналастыруды көрсетеді. БӨ-де ауытқулардың пайда болуы аппаратура ауытқулары сипатынан ерекшеленеді, олардың ықтималдығы нөлден жоғары болады.

l

Уақыт БӨ-нің қажетті сенімділігін қамтамасыз ету үшін талапты инвестиция размерін  анықтауда сенімсіз  бағдарламаның пайда болу қаупіне байланысты мәселелерді  есептеу  керек. БӨ жобалауда шығын мен қол жеткізілетін сенімділік арасындағы балансы көрсетілген қауіптің пайда болуы белгісімен анықталады. Егер қол жеткізілетін сенімділік қауіпті айтарлықтай азайтуға рұқсат етпеса, онда оны қамтамасыз етуге қосымша құрал жұмсаудың қажеті жоқ. БӨ сенімділігі мәселесінің көбі өміршеңдік  маңызды  болып табылмайды. Сенімділікке қол жеткізуге байланысты мәселелердің негізгі массасы БӨ тестілеуге жатқызылады. Жоғары берікті БӨ жасауды қамтамасыз ететін төрт әдісті қарастыруға тоқталайық:

сенімділікті қамтамасыз ету әдістері БӨ сенімділігін жобаны жасаудың алғашқы сатыларында жоспарлау керек. Жасалатын БӨ сенімділігін анықтау процесі ақпараттың үлкен көлемін жинауды талап етеді.Метрикалық мәліметтерді жинау мен анализ бойынша әрекеттер 5 бөлімде көрсетілген. Өлшеу әдістері БӨ жасаушыларымен бүкіл өміршеңдік циклдің ішінде жасалады. БӨ жасаудың өміршеңдік циклінің әртүрлі сатысында жүзеге асырылатын сенімділікті қамтамасыз ету әдістері 13.4 суретте көрсетілген. Қатені болжамдау жоспарлау мен талаптарды жасау сатысында орындалады, қателердің алдын алу – талаптарды жасау, жобалау мен жасау сатыларында, қателерді жою – жобалау, жасау мен тестілеу сатыларында. Бұзылуға тұрақтылық кезеңі жасау сатысында басталып, БӨ-нің өміршеңдік циклінің аяқталуына дейін жалғасады.

Қажет- тілікті тұжы- рымдау

Жүйені зерттеу

Разработка

Тестілеу

туралы есеп беру

Сүйемелдеу бойынша құжаттар

Қателерді жою

Күтуге төзімділікті қамтамасыз ету

Бағдарламалық өнімді жасаудың өміршеңдік циклі сатыларымен сенімділікті қамтамасыз ету әдістерінің байланысы

БӨ жасаудың өміршеңдік циклдерінің сатылары

Функционалды профильді анықтау + +

БӨ сенімділігінің талапты деңгейінің қамтамасыз етілуінде тапсырыс берушілердің қажеттілік

терін анықтау + +

Альтернативті оқу курстарын өткізу + +

Сенімділікті қамтамасыз етумен байланысты мақсаттарды анықтау + +

Сенімділікке қол жеткізу бойынша мақсаттарды бекіту үшін инженерлермен кездесу

Профильдің функционал- дығы негізінде ресурстарды жинақтау

Қатені енгізу мен таралуын бақылау

Алынған БӨ сенімділігін өлшеу

жасаудың өміршеңдік циклдерінің сатылары

Қате- лердің алдын алу

Сенімділікті арттыру сатысын тестілеу

Тестілеуді жасау барысын бақылау

Жобаның қосымша тестілеуіндегі қажеттілікті анықтау

Сенімділіктің талапты сатысына қол жеткізілді ма? Соны анықтау

БӨ жасау мақсаты мен оның сенімділігін салыстырмалы тексеру

Жаңа қабілетті қосуда сенімділікті тексеру

Қол жеткізілген сенімділікті бір мезгілде өлшеумен өнім мен процесті жақсартуды басқару

БӨ жасаудың өміршеңдік циклі сатыларымен сенімділікті қамтамасыз ету әдістерінің байланысы 13.1 кестеде көрсетілген.

Қателерді болжамдау сенімді БӨ жасаудың күтпелі тәсілін білдіреді. БӨ жасауда мамандандырылатын жетілген ұйымдар қатені болжамдауды БӨ жобасы/процесін бағалаудың құрамдас бөлігі ретінде жасайды. Болжамданатын модельдер үшін дәлдіктің тіпті кішігірім деңгейіне де қол жеткізудің жалғыз тәсілі мәліметтердің беріктігін қамтамасыз етудің сәйкес тарихи моделіне рұқсатты ұсынудан тұрады. Тарихи мәліметтер анализі мен қателер жөнінде мәліметтер жинағы осы тәсіл үшін маңызды әрекет болып табылады. 13.2 кестеде (шаблон) қатені болжамдау нәтижесі көрсетілу керек. Функционалды профильді анықтау қатені болжамдауда бірінші әрекет болып табылады. Модульден модульге, функциядан функцияға өту жағдайын бақылай отырып, жүйенің ең осал жерін анық табуға болады. Егер алынған ақпаратты функционалды профильмен біріктірсе, оны қолданудың берілген жағдайында жүйе қаншалықты сенімді болатынын анықтауға болады. Бағдарламаларды жасауда модульдер арасында бақыланатын өткелдері жасалады.Қатемен толтырылған бағдарламалық модульдерге өтуде сәтсіздік қаупі артады. Мұндай өткелдерді модельдеу қандай да бір стохастикалық процесс арқылы жүзеге асырылады.Нәтижесінде БӨ әртүрлі модульдерінің жасалатын функцияларымен шартталатын БӨ тәртібін математикалық сипаттауда жасалатын функция беріктігін сипаттауды жасау мүмкін

13.2 Кесте Жоспарлау мен талаптарды жасау сатыларында қателерді болжамдау нәтижелерін есептеу үшін шаблон

Жоспарлау мен талаптарды жасау сатыларында қателерді болжамдаудағы негізгі қателер

Дәл сол БӨ сенімділігінің талапты деңгейін қамтамасыз етуде тапсырыс беруші қажеттілігін анықтау »

Альтернативті оқу курстарын өткізу »

Сенімділікті қамтамасыз етумен байланысты мақсаттарды анықтау »

Бағдарламалық жүйе өзіндік жасалатын функциялардан тұрады. Жасалатын функция мен жүйемен осы функциялар арасында машиналық уақытты бөлу реті сенімділігі жөнінде көрініс алып, жүйенің өзінің сенімділігі жөнінде қорытынды жасауға болады. Қатені анықтау мен классификациясы – оларды болжамдаудағы екінші әрекет. 13.1 бөлімшеде көрсетілгендей, БӨ қателері жоба дефекттері немесе қателері, кодтау дефекттері немесе қателері, ұйымдастырушылық қателер, лайықсыз ретке келтіру мен тестілеу қателері нәтижелері болып табылады. Қателерді анықтау олардың қайнаркөзін бекітуді білдіреді. Қателерді классификациялау олардың қиындық деңгейі бойынша жасалады. Борис Бейцермен жасалған классификация тәптіштеудің сәйкес деңгейлеріне ие. Қате көздерінің матрицасы мен олардың классификациясын жасауды аяқтап, 13.3 кестеде (шаблон) көрсетілгендей, қате мәліметтерді сипаттаушы метрикалық көрсеткіштерді бақылау керек.Кестенің әрбір ұяшығы ұқсас жобалар мен  өнімдер  үшін қолжетімді тарихи ақпаратқа сәйкес қателер жөнінде қорытынды мәліметтерден (қорытынды) тұрады. БӨ сенімділігінің талапты деңгейін қамтамасыз етуде тапсырыс беруші қажеттілігін анықтау қатені болжамдаудағы үшінші әрекет болып табылады. Бұл қажеттіліктер алын ала анықталған және тапсырыс берушінің алғашқы талаптарында құжаттандырылған. Сенімділіктің талапты деңгейінде тапсырыс беруші қажеттіліктері өлшеу әдістері қамтамасыз ететін дәлдікпен бекітілу керек.

Қате жөнінде қорытынды мәліметтерді есептеу үшін шаблон

Қате деңгейі

Жоба қатесі немесе дефекті

Кодтау қатесі немесе дефекті

Ұйымдас тырушылық қателер

Лайықсыз ретке келтіру

лыпты » » » » »

Тітіркен- діргіш » » » » »

Өте

маңызды » » » » »

Төтенше » » » » »

Шыдамсыз » » » » »

Апатты » » » » »

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

асырудың орташа уақыты 10 мин құрайды.

Альтернативті оқу курстарын өткізу – қатені болжамдаудың төртінші әрекеті. Клиенттік функционалды профиль мен өткен жүйелерден алынған қателерді классификациялау жөнінде ақпарат арқылы мақсаттар тарихи мәліметтерді қолдай ма, соны анықтау үшін ерекше талаптар сараптанады. Талаптарда жасалған сенімділік мақсаттарына қол жеткізу ықтималдығын анықтау үшін курстар анализі жасалады.Ұқсас өнімдер мен жүйелермен байланысты тарихи мәліметтердің жоқтығында сенімділіктің жасанды бекітілген деңгейіне қол жеткізу ықтималдығы өте төмен. Бұл сатыда жоба басшысына жаңа  БӨ сенімділігінің мүмкін болатын деңгейлерін анықтау үшін қолданылатын экстенсивті жүйелік модельдерді жасау керек. Формалды әдістер сияқты құралдар критикалық қосалқы жүйеге байланысты математикалық дәлелдеулер үшін сенімділік талаптарына қолданылады. Бұл қымбат тұратын процесс сенімділік жөнінде тарихи мәліметтер көзінің болмауы жағдайында ғана қолданылады. Сенімділікті қамтамасыз етумен байланысты мақсаттарды анықтау – альтернативті оқу курстарын өткізу нәтижелеріне негізделетін қателерді болжамдаудың бесінші әрекеті. Сенімділікті қамтамасыз ету мақсаттарының соңғы жиынтығы қолда бар талаптарды өзгертуге мүмкіндік бере отырып, талаптарды анықтау процесіне беріледі. Осы әрекет арқасында жиналған ақпарат пен өткізілген анализ нәтижелері талаптарды сипаттау үшін беріледі. Сенімділікке қатысты мақсаттар мен талаптар бүкіл жүйенің сенімділігін бекіту мен пайдаланушы мақұлдауын алу үшін қолданылады. Қателердің алдын алу өзіне жүйелік талаптардың интерактивті нақтылауы мен БӨ-нің техникалық сипаттамасын жоба әдіснамасы мен кодтаудың қолайлы тәсілдерімен тексерілетін модельдеумен тең жасауды қосады. Сенімділікті қамтамасыз етудің бұл әдісі БӨ талаптары, жобалау мен жасауды жүзеге асыру сатыларында қолданылады. Қателердің алдын алу жобалау процесінің белсенді бөлігі болып табылады. Қателердің алдын алудың алғашқы сатысы жүйенің өзі мен БӨ талаптарын зерттеуден тұрады. Алғашқы қадамдар оның сенімділігіне қол жеткізуге жәрдемдесу үшін шақырылған тәсілдерден тәуелсіз БӨ сенімділігіне қатысты талаптар мен мақсаттарды анализдеу

үшін қажет.

Қателердің алдын алудың екінші негізгі сатысы – жобаны жобалау мен жасау. Бұл ретте сенімділікті қамтамасыз ету бойынша функциялар БӨ-нің барлық құрауыштары арасында бөлінеді. Нәтижесінде құрауыштар жасалатын жобалау процесі анықталады. Модульдердің параллельдік деңгейін жақсарту мен байланыстылығын арттыру құрауыштар сенімділігін арттыруды қамтамасыз етеді. Жобалауға қатысты ең жақсы атқарымдар жасаған жөн, және олар құрылымдық немесе объектілі – бағдарлы болуына қарамастан. Осының арқасында сенімділіктің жоғары деңгейіне ие БӨ жасау мүмкіндігі қамтамасыз етіледі. БӨ жасаудың өміршеңдік циклінің алғашқы сатыларында сенімділікті қамтамасыз етудің мақсаты мүмкін болатын қателердің алдын алу болып табылады. 13.4 кестеде (шаблон) қателердің алдын алу бойынша жұмысты қолдау үшін ұйымда жасалатын барлық әрекеттер көрсетілді. Алдын ала анықталған және құжатталған сенімділікті қамтамасыз етудің мақсаты жобалау сатысы барысында барлық модульдер үшін бекітілу керек. Жоба басшысына ресурстарын осы жобалау барысында қолданылатын және аттестациядан өтетін функционалды профиль негізінде жинақтау керек.

13.4 Кесте Талаптар, жобалау мен жасауды құрастыру сатыларында қатенің алдын алу бойынша әрекеттерді

есептеу үшін шаблон

Альтернативті оқу курстарын өткізу »

Кіріс пен қателердің таралуын басқару »

Алынған БӨ сенімділігін өлшеу »

Қателердің белсенді алдын алудың жалғыз тәсілі – кіріс пен қателердің таралуын басқару. Экспертті бағалар мен инспекциялық тексерулер – бір сатыда пайда болған қателерді белсенді қысқарту мен олардың басқа сатыға өтуінің алдын алудың дәстүрлі тәсілі. Тағы бір маңызды әрекет – алынған БӨ сенімділігін өлшеу. Іnternet желісімен байланыстырылған инструменталды құралдарды кең қолдануда,жәнебірігіпқолданылатынқолжетімдікітапханаларда бағдарламалық қамтамасыз ету (SOUP — Software  Of Uncertaіn Pedіgree) өнімнің бөлігі болады.  Жобаны  жасау  тобы SOUP-құрауыштардың верификациясы, аттестациясы, сенімділікті қабылдау мен бағалау процесіне мұқтаж болады. Бұл «нөлден» бастап жасалған БӨ құрауыштарымен болған жағдайдағыдай,конфигурацияны бақылаудың сол деңгейімен формалды проесс болу керек. Бағдарламаны қайталап қолдану жасаушы өнімділігін арттыруды қамтамасыз етеді. Алайда, бұл ретте жасырысн мәселелер мен дефекттер туындауы мүмкін. «Алдын алуға кеткен бір күн, салдарды жөндеуге кеткен жылға тең» деген мақал осы жерде орынды болады. Жүйеде пайда болатын қатені жою бастапқы сатыда оның алдын алуға қарағанда 10-100 есе қымбат тұрады. Қатені жою процесі БӨ жобалау сатысында басталып, жасау мен тестілеу сатыларына таралады. Функционалды профильдеу бойынша жұмыс аяқталғаннан кейн келесі қадам жасалады Жобалау, жасау мен тестілеу сатыларында қателерді жою бойынша әрекеттер есебі үшін шаблон

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

Қатені жою бойынша әрекеттер жинағы БӨ барлық құрауыштары арасында сенімділікті қамтамасыз ету бойынша функцияларды бөлу

(Әрекеттер тізбегі) Сенімділікке қол жеткізу бойынша мақсаттарды бекіту үшін инженерлермен кездесу

Кіріс пен қатенің таралуын басқару »

Алынған БӨ сенімділігін өлшеу »

Қолданыс профилін анықтау »

Сенімділіктің арту деңгейін тестілеу »

Тестілеуді жасау барысын бақылау »

Жобаның қосымша тестілеуінде қажеттілікті анықтау »

Сенімділіктің талапты деңгейіне қол жеткізілді ма, соны анықтау » БӨ жасаудың өміршеңдік циклінің ортаңғы сатысында сенімділікті қамтамасыз ету бойынша  күш  дефекттерді  жоюға жұмылдырылады. 13.25 кестеде (шаблон) жасаудың өміршеңдік циклінің негізгі сатыларында жасалатын қателерді жою бойынша ұйымда қабылданатын барлық әрекеттер тізбектелу керек. Қажетті тестілеуді өткізетін модульді жобалау тестіленетін мәліметтердің анализ нәтижелері болып табылады. Қосымша жүктемемен тестілеу нәтижелері сәйкес болмауы мүмкін, нәтижесінде сенімділікті қамтамасыз етудің барлық мақсаттарының жүзеге асырылуын бекіту қиын болады. Кейбір модульдер, мүмкін, «қара» немесе «ақ» жәшік тәсілімен қайта тестілеуден өтуі керек болады. Бұл ретте, көлемде регрессиялық тестілеу кеңейтіліп, артылу керек. Қатені жоюдың аяқталу сәтінде жоба басшысы сенімділікті қамтамасыз ету мақсатына қол жеткізілгенді туралы көрсететін нәтижемен.

БӨ бұзылуға тұрақтылығына қол жеткізу принциптері (13.1 бөлімшеде анықтамасын қараңыз) аппараттық қамтамасыз етудің бұзылуға тұрақтылығына қол жеткізу принциптерінен айтарлықтай деңгейде айрықшаланады. Аппараттық қамтамасыз етудің бұзылуға тұрақтылығы негізінде жасалған жүйеде параллельді түрде аппараттық құралдардың бірнеше жиынтығы қызмет етеді. Бұл ретте бір құрылғы істен шықса, басқасы жұмысын жалғастыру үшін барлық құрылғылардың қосарлануы жасалады. Сол түрде БӨ бұзылуға тұрақтылығын іске асыру талпынысы, яғни әртүрлі процессорлармен бірдей бағдарламаны параллель жасау,солбағдарламаныңекіншікөшірмесібіріншікөшірмесінен бірнеше секундқа қалатындығына әкеледі. Бағдарламаның жеке көшірмесін жай жасау БӨ бұзылуға тұрақтылығына әсер етпейді. БӨ жасаудың өміршеңдік циклінің ортаңғы сатыларынан бастап, сенімділікті қамтамасыз ету бойынша күш бұзылуға тұрақтылыққа        қол        жеткізуге        жұмсалады.        13.6        кестеде (шаблон) жасаудың өміршеңдік циклінің негізгі сатыларында орындалатын бұзылуға тұрақтылықты қамтамасыз ету бойынша ұйымда шара қолданылатын барлық әрекеттер көрсетілу керек. Бұзылуға тұрақтылықты қамтамасыз ету процесі БӨ жасау сатысында        басталып,        тестілеу,                қолдану        мен        сүйемелдеу сатыларына таралады. Бұл процестің аяқталуы БӨ тозуы сәтімен анықталады. БӨ қалыпты режимде жұмыс істеп тұрғанша, сенімділікті қамтамасыз етудегі бұзылуға тұрақтылық тәсіл

айтарлықтай кең қолданылады.

Бұзылуға тұрақтылықты қамтамасыз ету қатені жою сатысының логикалық жалғасуы болып табылады. Бұл жағдайда қатені жоюда қолданылатын барлық әрекеттер іске асырылады. Айырмашылық БӨ жасау процесі аяқталғаннан кейін қуылатын мақсаттан тұрады. БӨ сүйемелдеумен айналысатын персонал қажеттілігі БӨ-нің алдыңғы нұсқаларын жасауға қатысты ақпарат есебімен қана анықталады. Ұйымның басқа БӨ жасаудан кейін табылған қателер жөнінде мәліметтер базасына рұқсаты болу керек. Қателерді жою үшін қабылданған әрекеттер мен қателерді сипаттауды өзіне қосатын ақпараттық құрылым БӨ сүйемелдеу сатысында қажетті еңбек шығынын бағалау үшін қолданылады. Жасау сатысында табылған қателерді бағалау нәтижелері жөнінде хронологиялық мәліметтерді қолдану және жаңа өнім ( LOC) көлемі мен басқа БӨ көлемі арасында қатынасты білу арқылы өнімнің жаңа нұсқасында қателерді жою үшін қажетті қалған қате мен еңбек шығынының жылдам бағасын жасауға

болады.

Жасалатын БӨ үшін мәлімттер жиынтығын қамтамасыз ету үшін жоба басшысы БҚ жасау мақсаттарын ескере отырып, қолданыс сынақтары барысында БӨ сенімділігін бақылау керек. Ол тапсырыс берушілердің қанағаттануы деңгейін сенімділіктің қол жеткізілген деңгейімен бақылауға жол береді. Соңғы пайдаланушы – БӨ сенімділігі жөнінде ақпараттың ең жақсы көзі.

Жасау, тестілеу, қолдану мен сүйемелдеу сатыларында бұзылуға тұрақтылықты қамтамасыз ету бойынша

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

Бұзылуға тұрақ тылық бойынша әрекеттер жинағы БӨ барлық құрауыштары арасында сенімділікті қамтамасыз ету бойынша функцияны бөлу

(Әрекеттер тізбегі) Сенімділікке қол жеткізу бойынша мақсат тарды бекіту үшін инженерлермен кездесу

Кіріс пен қатенің таралуын басқару »

Алынған БӨ сенімділігін өлшеу »

Қолданыс профилін анықтау »

Сенімділіктің арту деңгейін тестілеу »

Тестілеуді жасау барысын бақылау »

Жобаның қосымша тестілеуінде қажеттілікті анықтау »

Сенімділіктің талапты деңгейіне қол жеткізілді ма, соны анықтау »

Жобаның соңғы сатыларында персонал қажеттілігін анықтау »

БӨ жасалу мақсаты мен оның сенімділігін салыстырмалы тексеру » Сенімділіктің қол жеткізілген деңгейіне тапсырыс берушінің қанағаттану дәрежесін бақылау »

Жаңа қабілеттерді қосуда сенімділікті тексеру »

Бір уақытта өнім мен процестің жақсаруын басқару мен қол жеткізілген сенімділікті өлшеу »

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

қамтамасыз ету жоспары Сенімділікті   қамтамасыз   етудің   барлық   құралдары үшін негіз болып оның статистикалық анализі саналады, сондықтан мәліметтер жиынтығын анализдеу мен элементарлы статистикалық есептеулерді (Мысалы, MS Excel) жасауға қабілетті кез-келген бағдарламалық құралдар осы міндеттер үшін қолданыла алады. БӨ сенімділігін қамтамасыз ету бойынша қызмет өте қымбат тұратын қызмет болып саналады. БӨ-ні жасау бойынша кез- келген қызмет сияқты ол жоспарланып, құжаттануы керек. Төменде БӨ сенімділігін қамтамасыз ету жоспарының сызбасы көрсетілген.Ұсынылатын жоспар ІEEE, SEІ және ІSO-мен жарияланған көптеген жоспардың түрлендірушісі болып табылады.

«процесс», «процесті жасауда бұзылу», « процесті жасауда ауытқу», «тұрақтылық», «бағдарламалық өнім қатесі» ұғымдарына анықтама беріңіз.

UML тілі - бағдарламалық қамтамасыз ету, бизнес-процестер мен басқа да әртүрлі жүйелер құрауыштарын сипаттау, визуализация, жобалау мен құжаттау үшін жасалған визуалды модельдеудің жалпыға ортақ тілі. UML тілі модельдеудің бір уақытта оңай және мықты құралы болып табылады. Ол әртүрлі мақсатты бағыттар үшін қиын жүйелердің концептуалды, логикалық және графикалық модельдерін жасау үшін тиімді қолданыла алады. Бұл тіл өзіне үлкен және қиын жүйелерді модельдеуде соңғы жылдары табыспен қолданылған бағдарламалық инженерия әдістерінің ең жақсы қасиеттерін жинады. UML  тілі  объектілі-бағдарлы  анализ  бен  жобалау (ОБАЖ) әдістерімен таныс көптеген бағдарламашылар мен жасаушылармен зерттеліп,қолданылатын базалық ұғым санына негізделген. Бұл ретте базалық ұғымдар объектілі модельдеу мамандары қосымшаның әртүрлі салаларында үлкен және қиын жүйелердің модельдерін өздері жасау мүмкіндігін алатындай қиыстырылып, кеңейтіледі. UML тілін конструктивті қолдану объектілі-бағдарлы анализ бен жобалау процесінің ерекшеліктері мен қиын жүйелерді модельдеудің жалпы принциптерін түсінуге негізделеді. Қиын жүйемоделінжасауүшінкөрінетінқұралды таңдаумодельдердің мәліметтерін қолдану арқылы шешілетін міндеттердің алдын алады. Бұл ретте қиын жүйенің моделін жасаудың негізгі принципінің бірі ретінде

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

принципі. Бұл принцип ешқандай жалғыз модель баламалықтың жеткілікті деңгейінде қиын жүйенің әртүрлі аспектілерін сипаттай алмайтындығы жөнінде пайымдау береді.ОБАЖ

әдіснамасына қатысты ол қиын жүйенің толық моделі жүйенің әрекеті немесе құрылымының кейбір аспектісін баламалы көрсететін өзара байланысқан көріністер (vіews) санын болдыратындығын білдіреді. Бұл ретте қиын жүйенің ең ортақ көрінісі ретінде бірнеше басқа жеке көріністерге бөлінетін статикалық және динамикалық көріністерді санауға болады. Қиын жүйенің феномені оның ешқандай жалғыз көрінісі оның барлық ерекшеліктерін баламалы көрсету үшін жеткіліксіз болатындығынан тұрады.

принципі болып табылады. Бұл принцип бекітілген көріністер аясында абстракциялау немесе тәптіштеудің әртүрлі деңгейлерінде модельді жасау процесін қарастыруды білдіреді. Бұл ретте қиын жүйенің бастапқы немесе алғашқы моделі жалпы көрініске (метакөрініске) ие болады. Мұндай модель жобалаудың бастапқы сатысында жасалады және модельденетін жүйенің көп бөлшектеріне ие болмауы мүмкін. Сөйтіп, ОБАЖ процесін жалпы модельдер мен концептуалды деңгейдегі көріністерден логикалық және физикалық деңгейлердің жеке және тәптіш көрінстеріне деңгей бойынша өту ретінде қарастыруға болады. Бұл ретте ОБАЖ-дың әрбір сатысында аталмыш модельдер тізбекті түрде қиын жүйенің нақты іске асуының әртүрлі аспектілерін көрсетуге жол  беретін бөлшектердің көп санымен толықтырылады. ОБАЖ модельдердінің өзара байлансуының жалпы сызбасы 14.1 кестеде көрсетілген. ОБАЖ бен UML тіліндегі «физикалық модель» термині жүйелер модельдерінің жалпы классификациясында жалпы қабылданғаннан ерекшеленетін түсіндірмеге ие болады. Соңғы жағдайда жүйенің физикалық моделі ретінде түпнұсқа формасындағы қабілеттерге ие кейбір материалдық конструкция деп түсінеді. Мұндай модельдердің мысалы ретінде техникалық жүйе моделі (ұшақ, кеме), сәулет ғимараттары (ғимараттар, аудандар) саналуы мүмкін. Бұл терминнің ОБАЖ бен UML тілінде анықтамасына келсек, мұнда физикалық модель кейбір техникалық база мен нақты өндірушілердің есептеуіш платформасында оның іске асырылуы көзқарасынан жобаланатын жүйенің құрауыш бөлігін көрсетеді.

Ұсыныс

Қиын жүйенің физикалық моделі

Қиын жүйенің динамикалық моделі

UML тілін жасау келесі мәселелерді шешуді қарастырды Жүйелік модельдеу тәжірибесі кейбір метадеңгейде тілді абстрактілі сипаттау нақты уақытта жүйе жобасын іске асыруды мақсат етіп қоятын жасаушылар үшін жектіліксіз екендігін көрсетті.Қазіргі        таңда        қиын        жүйені        модельдеудің        жалпы әдіснамасы мен қосымшаны жылдам жасаудың инструменталды құралдары арасында кейбір концептуалды айырмашылық бар. Дәл осы айырмашылық UML тілін толықтыру үшін шақырылған. UML тілінің базалық конструкциясын дұрыс түсіну үшін объектілі-бағдарлы        бағдарламалаудың                кейбір        дағдыларын иемдену ғана жеткіліксіз, сонымен қатар жүйе моделін жасау процесінің жалпы проблематикасын елестеткен де  жақсы. Осы көріністердің интеграциясы ОБАЖ жаңа парадигмасын

жасайды, оның практикалық нәтижесі мен орталық өзегі UML тілі болып табылады. Сол уақытта OMG жасаушылары қандай да бір себеп бойынша тілдің базалық ұғымдарын қайта анықтауды қажетсіз деп санайды. Ол олардың семантикасының қайталанба интерпретациясы мен мүкін болатын шатасуға алып келуі мүмкін. UML тілінің базалық ұғымдарын ендігі өзгертудің керегі жоқ, оны кеңейту  үшін  қажеттілікке  қарағанда.  Барлық пайдаланушылар кеңею механизмін қолданбай UML тілінің базалық конструкциясын ғана қолданумен әдеттегі қосымшалардың көбісі үшін жүйе моделін жасауға қабілетті болулары керек. Бұл ретте жаңа ұғымдар мен нотацияларды қолдағы базалық ұғымдар жүйе моделін жасау үшін жеткіліксіз болған жағдайда ғана қолдану керек. UML тілі базалық ұғым мамандандыруына да жол береді. Мәселе нақты қосымшаларда пайдаланушылар қолдағы базалық ұғымдарды UML тілінде осы ұғымдардың семантикасына қарсы болмайтын жаңа сипаттамалар немесе қабілеттермен толықтыра білу керектігі жөнінде. Басқа жағынан, UML тілі бағдарламалаудың кез-келген тілінде өз конструкциясын іске асырудың әлеуетті мүмкіндігіне ие болу керек. Әрине, бірінші кезекте, C++, Java, Object Pascal сияқты объектілі-бағдарлы жобалау концепциясын қолдайтын тілдер жөнінде айтылады. UML тілінің осы қабілеті оны қиын жүйені модельдеу мәселесін шешудің қазіргі құралы етеді. Сол уақытта UML тілінің конструкциясын бағдарламалық қолдау үшін арнайы инструменталды CASE-құралдар жасалуы мүмкін. Соңғылардың болуы UML тілінің кең таралуы мен қолданылуы үшін принципиалды маңызға ие. UML тілінің сипаттамасы ОБАЖ жалпы ерекшеліктерін түсіну үшін семантикалық базисті қосуды қамтамасыз ету. Бұл ерекшелікті айтқанда UML тілінің өз-өзіне жеткіліктілігін базалық конструкцияны ғана емес, сонымен қатар, ОБАЖ жалпы принциптерін ұғыну үшін айтылады. UML тілі бағдарламалаудың тілі ретінде емес, жүйені объектілі-бағдарлы модельдеу мәселелерін шешу үшін құрал ретінде қызмет ететіндіктен оның сипаттамасы ОБАЖ үшін мүмкіндігінше өзіне барлық қажетті түсініктер қосу керек. Бұл қабілетсіз UML тілі пайдасыз және қиын жүйенің ОБАЖ мәселесімен таныс емес пайдаланушыларға қажет етілмейтін тіл болып қалуы мүмкін. Басқа жағынан, UML тілін ұғыну үшін маңызды ақпаратқа ие қосымша қайнаркөздерге қандай да болсын сілтемелер, OMG жасаушыларының ойынша, алынып тасталуы керек. Ол ОБАЖ процесінің принципалды ерекшеліктерін бірнеше рет түсіндіру мен осы ерекшеліктерді UML тілінің базалық конструкциясы түрінде жүзеге асыруды болдырмауға мүмкіндік береді. мүмкіндіктерінің объективті көрінісін жасаса, онда келесі қорытындыға келуге болады. Жасаушылардың айтарлықтай үлкен тобының күштері өздерін тәжірибеде сәтті көрсеткен визуальды модельдеудің көптеген танымал технологиясының UML тілі аясында интеграцияға бағытталды. Бұл құрылымдық жүйелік анализдің танымал нотацияларымен салыстырмалы түрде UML тілінің қиындауына алып келгенімен, қиындық үшін төлем болып UML тілінің алғашқы нұсқасының жоғары иірімділігі мен бейнелі мүмкіндіктері саналады. Өз кезегінде, барлық практикалық мәселелерді шешу үшін UML тілін қолдану оның кезекті жетілуі, демек, ОБАЖ объектілі технологиясы мен практикасының кезекті дамуына алып келеді. Жоғарыда айтылған мәселелерді шешу үшін UML тілі эволюцияның өзіндік қысқа тарихынан өтті.  Нәтижесінде UML тілінің сипаттамасы таптаурын емес болды, себебі базалық ұғым семантикасы өзіне тілдің басқа ұғымы мен конструкциясымен қиылысты байланыстың бір қатарын қосады. Осыған байланысты линиялық немесе тізбекті деп аталып UML тілінің негізгі конструкцияларын қарастыру мүмкін емес болды, себебі бірдей ұғымдар әртүрлі диаграмма немесе көрініс жасауда қолданыла алады. Сол сәтте модельдің әрбір көрінісі тілдің базалық ұғымының семантикасына із қалдыратын жеке семантикалық ерекшеліктерге ие болады. UML тілін суреттеу қиындығын айтқанда, базалық примитивтердің сипаттамасы үшін табиғи тілді пайдалану деңгейі қажеттілігінен шығатын барлық ресми тілдерге қатысты олардың қатал мәселесінің қиындығын атап өтуге  болады.  Бұл жағдайда табиғи тілге метатіл рөлі беріледі, яғни ресмі тілді сипаттау үшін тіл. Табиғи тіл ресми тіл болмағандықтан, қандай да бір деңгейде ресми тілді сипаттау үшін оны қолдану дәлсіздікке әкеледі. UML тіліне сәйкес логико-лингвистикалық бөлшектердің анализі кірмесе де, бұл ерекшеліктер UML тілін сипаттау құрылымына әсер етті, оның ішінде, оның барлық негізгі ұғымдарының сипаттау стилін жартылай ресми етті.

Ең ортақ көзқараста UML тілін сипаттау екі өзара әрекеттесетін бөліктен тұрады: семантика және нотация.

UML тілінің семантикасы UML тілінде абстрактілі синтаксис пен объектілі модельдеу ұғымының семантикасын анықтайтын кейбір метамодельді білдіреді.

UML тілінің нотациясы UML тілінің семантикасын визуалды көрінісі үшін графикалық нотацияны білдіреді. UML тілінің абстрактілі синтаксисі мен семантикасы UML нотациясының ішкі жиынтығын қолданумен сипатталады. Осыған қосымша ретінде UML нотациясы графикалық нотацияның семантиканың базалық ұғымдарына сәйкестігін сипаттайды. Сөйтіп, функционалды көзқараста бұл екі бөлік бір бірін толықтырады. Бұл ретте UML тілінің семантикасы үш жеке көрініске ие кейбір метамодель негізінде сипатталады: абстрактілі синтаксис, көріністердің дұрыс қойылуы ережесі мен семантика. UML тілінің семантикасын қарастыру базалық ұғым мен олардың кеңею ережесін ұсыну үшін табиғи және ресми тілдерді біріктіретін баяндаудың жартылай ресми стилін білдіреді. Семантика объектілі модельдің екі түрі үшін анықталады: құрылымдық  модель  мен  әрекет  моделі.  Статикалық  деп   те алатын құрылымдық модельдер олардың класстары, интерфейстері, атрибуттары мен қатынастарын қоса отырып, кейбір жүйенің болмыстары немесе құрауыштары құрылымын сипаттайды. Кейде динамикалық деп аталатын әрекет моделі олардың әдісі, өзара әрекеті мен арасындағы ынтымақтастық, сонымен қатар жеке құрауыштар мен жүйе жағдайларының өзгеру процесін қоса отырып, жүйе объектісінің әрекеті немесе қызмет етуін сипаттайды. Модельдеу мәселесінің осындай кең диапазонын  шешу үшін графикалық нотацияның барлық компоненттері үшін айтарлықтай толық семантика жасалды. UML тілі семантикасы талаптары диаграмманың жеке түрлерін жасауда нақтыланады. UML тілі нотациясы диаграмманы жасауда қолданылатын жеке семантикалық элементтерді сипаттауды қосады. UML тілінің өзін ресми сипаттау төрт деңгейге ие модельдік көріністің кейбір жалпы иерархиялық құрылымына негізделеді: метаметамодель; метамодель; модель; пайдаланушы объектілері.

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

деңгейінде анықтайды және оның сипаттамасының ең тұтасы болып табылады. Басқа жағынан, метаметамодель қосымша ұғымдарды қосудың әлеуетті иірімділігіне қол жеткізілетін бірнеше метамодельдерді сипаттай алады. Бұл деңгей ұғымының мысалы ретінде метакласс, метаатрибут, метаоперация саналады. Метаметамодель семантикасы UML тілінің сипаттамасына кірмейтіндігін атап өткен жөн. Бір жағынан, ол UML тілін зерттеу үшін оңай етеді, себебі ресми тілдер мен ресми логиканың жалпы теориясын білу талап етілмейді. Екінші жағынан, метаметамодельдің болуы UML тіліне қарсы ресми тіл болу үшін қажетті ғылыми дәреже береді.Егер бұл ерекшеліктер көптеген бағдарламашылар үшін қызықсыз болса, онда инструменталды құрал жасаушылары оларды елемей қоюы мүмкін емес.

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

өз жағдайына қатысты оларды нақтылап, метамодель ұғымын ғана қолдануға тиісті жүйенің кез-келген нақты моделі ұғымында метамодель үлгісі болып табылады. Бұл деңгей нақты пәндік сала жөнінде ақпаратты сипаттау үшін қызмет етеді. Алайда егер модельді жасау үшін UML тілі ұғымы қолданылса, онда метамодель деңгейінің UML тілінің базалық ұғымымен модель деңгейі ұғымымен толық сәйкестігі керек. Модель деңгейі ұғымының мысалы болып жобаланатын мәліметтер базасының өңірі аттары қызмет ету мүмкін – қызметкер аты-жөні, жасы, лауазымы, мекенжайы, телефоны. Бұл ретте ұғым мәліметтері сәйкес ақпараттық атрибут аттары ретнде ғана қолданылады.

деңгейінде жасалады.Бұл контекстте объект модель үлгісі болады, себебі модель ұғымына расында сәйкес келуіне қатысты нақты ақпаратқа ие. Объект мысалы ретінде жобаланатын мәліметтер базасындағы келесі жазба оған дәлел бола алады: «Илья Петров, жасы 18-де, бағдарламашы, Пионерская к.,5 үй, 1к., 23 п., тел. 123-45-67». UML семантикасын сипаттау метаметамодель деңгейінің мысалы немесе жеке жағдайын ғана көрсететін метамодель деңгейінің ғана базалық ұғымдарын қарастыруды білдіреді. UML

метамоделі өз кезегінде физикалық немесе іске асыру моделіне қарағанда логикалық модель болып табылады. Логикалық модель ерекшелігі – ол модельдің нақты физикалық іске асуын жіберіп, декларативті немесе концептуалды семантикаға назарын аударуында. Бұл ретте осы логикалық метамодельді қолданатын жеке іске асулар оның семантикасымен келістірілуі керек, сонымен қатар жеке логикалық модельдердің импорты мен экспортын қолдау керек. Сол уақытта логикалық метамодель сәйкес инструменталды құралдардың өнімділігі мен сенімділігінің талапты деңгейін қамтамасыз ету үшін әртүрлі әдістермен іске асырылу керек. Семантика деңгейінде оның тиімді кезекті іске асырылуы үшін міндетті талаптары жоқ логикалық модельдің кемшілігі осында. Алайда метамодельдің іске асырудың нақты модельдерімен сәйкестігі UMLтілін қолдауды қамтамасызететінбағдарламалық құрал жасаушылары үшін міндетті болады.

мәліметтер UML тілінің метамоделі тілдің жаңа нұсқасы шығуымен саны артатын 90 метаклассқа жуық, 100 метассоциациядан астам және 50 стереотипке жақын қиын құрылымға ие. UML тілінің бұл қиындығына төтеп беру үшін, оның барлық элементтері логикалық пакеттерге жиналған. Сондықтан метамодельдік деңгейде UML тілін қарастыру оның үш жалпы логикалық блоктары немесе пакеттерінен тұрмайды: «Негізгі элементтер»,

«Әрекет элементтері», «Жалпы механизмдер».

Тілдің жалпы сипаттамасы контекстінде пакеттер жайында айтқанда,біз, ісбарысында, UMLтілінің графикалық нотациясын қарастырамыз. UML тілін сипаттау үшін тілдің өзінің құралдары қолданылады және бұл құралдың бір түрі ретінде пакет саналады. Жалпы жағдайда пакет модель элементтерін топтау үшін қызмет етеді. Бұл ретте бір пакетке жатқызылған негізсіз болмыс бола алатын модель элементі біртұтас болады. Модельдің басқа элементтері сияқты пакеттер басқа пакеттерге салына алады. UML тілінің маңызды ерекшелігі ретінде UML моделі элементтерінің барлық түрі пакеттерге ұйымдастырылуы мүмкіндігі саналады. Пакет – UML тілінде модельдер элементтерін ұйымдастырудың негізгі тәсілі. Әрбір пакет өз элементтеріне ие, яғни оған қосылған элементтерге ие. Пакеттің сәйкес элементтері жайында олар пакетке тиесілі немесе оған кіреді

деп айтады. Бұл ретте әрбір элемент бір пакетке ғана тиесілі болады. Өз кезегінде, бір пакет басқа пакетке салына алады. Бұл жағдайда біріншісі ішкі пакет деп аталады, себебі ішкі пакеттің барлық элементтері жалпы пакетке тиесілі. Сөйтіп, модель элементтері үшін иерархия көрсететін пакеттердің салыну қатынасы беріледі. Пакет-ішкі пакет қатынастарын жиынтық – ішкі жиынтықтың жалпы қатынасына ұқсатқан жөн. Пакетті жиынтықтың жеке жағдайы ретінде қарастыруға болғандықтан, мұндай түсіндіру пакеттер арасында сәйкес қатынасты ұсыну үшін графикалық құралды қолдануға көмектеседі. Иерархияның графикалық ұсынысы үшін ағаштар деп аталатын арнайы түрдегі графтар қолданыла алатындығы мәлім. Алайда UML тілінде бұл графикалық белгілер бастаушы жасаушылар үшін айтарлықтай қиындық туғызуы мүмкін жалпытеориялық ұғымдармен сәйкес ассоциациясы болатындай модификацияланған. Дегенмен, UML тілінің арнайы конструкциясын жүйелі аналитик ойының стилін жасайтын жиынтық теориясы мен жүйелік модельдеудің сәйкес ұғымдарымен ұқсатуды білген өте маңызды. Әйтпесе, өкінішті қателер пәндік саланың концептуализациясының алғашқы сатысында ғана емес, сонымен қатар жүйенің әртүрлі көрінісін жасау процесінде туындайды. UML тілінде пакеттер визуализациясы үшін арнайы белгі немесе графикалық нотация жасалған. Пакеттердің графикалық көрінісі        үшін        диаграммаларды        арнайы        графикалық        белгі қолданылады – үлкен тікбұрыштың жоғары жағының сол бөлігіне жалғанған кішкене тікбұрышы бар үлкен тікбұрыш (14.2 сур.). Визуалды түрде пакет белгісі танымал графикалық интерфейстегі папка пиктограммасын еске салады. Үлкен тікбұрыш ішінде аталмыш пакетке қатысты ақпарат жазылуы мүмкін. Егер мұндай ақпарат болмаса, онда үлкен тікбұрыш ішіне қарастырылатын модель шегінде бірегей болатын пакет аты жазылады (14.2, а сур.). Мұндай ақпараттың болуында пакет аты жоғарыдағы кішкентай тікбұрышта жазылады (14.2, б сур.). Пакет атын айтқанда UML тіліндегі аттар жөніндегі жалпы келісімге тоқталып өту керек. Бұл жағдайда пакет аты ретінде кез-келген әріп, сан немесе кейбір арнайы белгі санына ие мәтін

жолы (немесе бірнеше жолдар) болуы мүмкін.

Пакеттерді сәйкестендіру мақсатымен олардың аттары ретінде бір немесе бірнеше зат есімдерді қолдану керек, мысалы, «бақылаушы», «графикалық интерфейс», « мәліметтер

Пакеттің атауы

а) осы пакетке қатысты мәлімет жоқ кезде б) мәлімет бар кезде енгізу формасы». Пакет аты алдында  кейбір  кілтті  сөздерге ие мәтін жолы енгізілуі мүмкін. Мұндай кілтті сөздер ретінде стереотиптер деп аталатын UML тілінде алдын ала анықталған сөздер саналады. Пакеттер үшін мұндай стереотиптер болып facade (фасад), framework (тірек), stub (бітеуіш) және topLevel (жоғарғы деңгей) табылады. Пакеттің құрамы ретінде олардың жеке элементтерінің аттары мен олардың қасиеттері шыға алады. Өздігінен пакеттер шекті қолданыс таба алады, себебі олардың құрамына кіретін модель элементі жөнінде ғана ақпаратқа ие. Жеке пакеттер арасында орын ала алатын қатынасты графикалық елестету де өте маңызды. Графтар теориясында да, UML тіліндегі қатынастарды көру үшін сырты мағыналық құрамға ие линия бөліктері қолданылады. Пакеттер арасында қатынастың бір типі ретінде пакеттердің бір-біріне  салынуы  немесе  қосылуы  қатынасы  саналады.  Бір жағынан, UML тілінде бұл қатынас линияны қолданусыз көрсетілуі мүмкін,яғни бір тікбұрыш-пакеттің екінші тікбұрыш пакетке салынуы (14.3 сур). Сөйтіп, бұл жағдайда Пакет_1 атты пакет екі ішкі пакетке ие: Пакет_2 және Пакет_3

Екінші жағынан, бұл қатынас линия бөліктері көмегімен

не салудың графиктік көрінісі

ағаштың графиктік көрінісіне сәйкес көрсетілуі мүмкін (14.4 сур). Бұл жағдайда үлкен пакет (метапакет немесе контейнер) суреттің жоғарғы бөлігіне салынып, оның ішкі пакеттері төменірек деңгейде болады. Метапакет ішкі пакеттермен тұтас линия бойынша жалғанады, метапакетке келетін аяқ жағында арнайы белгі көрсетіледі – шеңбердің ішіндегі «плюс» белгісі. Бұл белгі ішкі пакеттер «меншік» болады немесе контейнер бөлігі және олардан басқа контейнерде ешқандай ішкі пакет жоқ екендігін білдіреді. Графиктік диаграммаларда пакеттер арасында қатынастардың басқа да типтері көрсетілуі мүмкін. 14.3 тармақшада көрсетілгендей, метамодельдік деңгейде UML тілін көрсетудің негізі оның үш логикалық блоктарын немесе пакеттерін сипаттау болып табылады: «Негізгі элементтер», «Әрекет элементтері» және «Жалпы механизмдер» (14.5 сур.). Бұл пакеттер, өз кезегінде, жеке ішкі пакеттерге бөлінеді. Мысалы, «Негізгі элементтер» пакеті «Ядро элементтері», «Қосымша элементтер», «Кеңею механизмі» мен «Мәліметтер типі» (14.6 сур.) сияқты ішкі пакеттерден тұрады. Бұл ретте «Ядро элементтері» пакеті базалық мәліметтерді және метамодель құрылымына метакласстар, метаассоциациялар мен метаатрибут сияқты тілдің негізгі ұғымдарын қосу принциптерін сипаттайды.

UML тілі

Негізгі элементтер

«Қосымша элементтер» пакеті тәуелділіктер, шаблондар, физикалық құрылымдар мен көрініс элементтерін сипаттау үшін базалық элементтерді кеңейтетін қосымша конструкцияларды анықтайды. «Кеңею механизмдері» пакеті модельдердің базалық элементтерінің нақтылау мен семантикасын кеңейту ережелерін береді. «Мәліметтер типтері» пакеті UML тілі үшін мәліметтердің негізгі құрылымдарын анықтайды. «Негізгі элементтер» пакеті. Төменде «Негізгі элементтер» пакеті құрамына кіретін аталып өткенәрбірішкі пакеттердің элементінің қысқаша сипаттамасы беріледі.

«Ядро элементі» пакеті UML тілінің «Негізгі элементтер» пакетіне кіретін барлық ішкі пакеттердің ішінде ең фундаментальдысы болып табылады. Бұл пакет объектілі модельдерді жасауға қажетті негізгі абстрактілі және нақты құрауыштарды анықтайды. Бұл ретте метамодельдің абстрактілі    құрауыштары    үлгі    немесе    мысалдарға ие болмайды және модельдің басқа құрауыштарын анықтау үшін ғана қолданылады. Метамодельдің нақты құрауыштары үлгілерге ие және объектілі модель жасайтын тұлғаларды ұсыну ерекшеліктерін көрсетеді. Білімді көрсетудің дамыған тілдері, соның ішінде UML тіліне тиесілі көрнекті мүмкіндіктерінің бір мәнді еместігін атап өткен жөн. Әңгіме бірдей модельденетін  болмыс  немесе жүйе UML тілінің құралдарымен әртүрі ұсынылуы мүмкін болуында. Бұл ретте әртүрлі жасаушылар өзінің көрінісі формасымен ғана емес, сонымен қатар, модельде қолданылатын құрауыштар құрамымен ерекшеленетін бірдей жүйенің объектілі моделін жасай алады. «Ядро элементтері» пакеті бастапқы метамодельді сипаттау үшін қажетті базалық конструкцияларды сипаттайды және метакласстар, метаассоциациялар мен метаатрибуттар сияқты тілдің қосымша конструкцияларын қосу үшін сәулетті «қаңқа»

анықтайды. «Ядро элементтері» пакеті UML тілінің барлық қалған бөлігін анықтау үшін жеткілікті семантикаға ие болғанымен, UML метамоделі болып табылмайды. Бұл пакетке UML тілінің негізгі  метакласстары  кіреді: класс (Class); атрибут (Attrіbute); ассоциация (Assocіatіon); ассоциация-класс      (AssocіatіonClass);       ассоциацияның аяғы (AssocіatіonEnd); әрекет қасиеті (BehavіoralFeature); классификатор (Classіfіer); шектеу (Constraіnt);  мәліметтер типі (DataType); тәуелділік (Dependency); элемент (Element); элементке құқық (ElementOwnershіp); қасиет (Feature); жалпылау (Generalіzatіon); жалпылау қатынастарының элементі (GeneralіzableElement); интерфейс (Іnterface); әдіс (Method); модель элементі (ModelElement); аттар кеңістігі (Namespace); операция (Operatіon), параметр (Parameter); құрылымдық қасиет (StructuralFeature); көріністі жасау ережесі (Well-formedness rules). «Қосымша элементтер» пакеті «Ядро элементтері» пакетін кеңейтетін UML тілінің қосымша конструкциясын сипаттайды. Қосымша элементтер тәуелділіктер, шаблондар, физикалық құрылымдар мен көрініс элементтері үшін ұғымдық базисті қамтамасыз етеді.

Бұл пакетке келесі метакласстар кіреді: байланыстыру (Bіndіng); комментарий (Comment); құраушы (Component); түйін (Node); презентация (Presentatіon); нақтылау (Refіnement); тәуелділіктер тізбегі (Trace); тұтыну (Usage); көрініс элементі (VіewElement); тәуелділік (Dependency); модель элементі (ModelElement); көріністі жасау ережесі (Well-formedness rules). Соңғы үш метакласстар «Ядро элементтері» пакетінен алынған және қалғандарын сипаттау үшін қолданылады. Бұл пакет UML бастапқы нұсқаларында өзіндік мәнге ие болғанымен, соңғы нұсқа жобаларында оның элементтері «Ядро элементтері» пакетімен бірікті. Оған себеп ретінде әрбір элементтің бір пакетке кіруінің қатаң талабы болды.

«Кеңею механизмдері» пакеті элементтер моделіне нақтыланған семантикамен қосылу тәртібін, сонымен қатар модельденетін жүйе  сипаттамасын  нақты  көрсету  үшін  UML тілдерінің жеке кұрауыштарының модификациясын сипаттайды.Кеңею механизмі стереотиптер, шектеулер мен белгіленген мәндер үшін семантиканы анықтайды. UML типикалық бағдарламалық жүйені модельдеу үшін көптеген ұғым мен нотацияға ие болғанымен, жасаушы шынайы түрде модельге UML тілінде анықталмаған қосымша қасиеттер немесе нотациялар қосу қажеттілігіне тап болуы мүмкін. Бұл ретте жасаушылар модельге графиктік ақпаратты қосу қажеттілігімен, мысалы, қосымша белгі мен безендіру сияқтылар, жиі тап болады.

Бұл мақсат үшін UML тілінің метамоделінде сипатталғаннан ерекшеленетінсемантика,нотацияменқасиеттерэлементтерімен модельдің жаңа элементтерін анықтау үшін бірігіп немесе  жеке қолданыла алатын кеңеюдің үш механизмі UML тілінде қарастырылады. Мұндай механизмдер шектеу (Constraіnt), стереотип (Stereotype) және белгіленген мән (Tagged Value) деп аталады.

жеткілікті түрде қызық болмайтын немесе UML метамоде- лінің элементі ретінде анықтау үшін қиын болатын UML тілінің сипаттамасында стандарттық құрауыштарды анықтау: модельденетін процеске немесе бағдарламалық кодты жүзеге асыру тіліне тәуелді UML тілін кеңейтуді анықтау; негізсіз семантикалық немесе семантикалық емес ақпаратты модель элементіне қосу. Кеңеюдің кіріктірілген механизмдерінің ішінде ең маңыздылары «стереотип» ұғымына негізделеді. Стереотиптер объектілі модель деңгейінде модельдік элементтерді классификациялау әдісі мен UML тіліне жаңа атрибуттар мен семантикамен «виртуалды» метакласстар қосуды қамтамасыз етеді. Кеңеюдің басқа кіріктірілген механизмдері белгіленген мәндер мен шектеулерге ие «қасиеттер тізімі» ұғымына негізделеді. Бұл механизмдер пайданалушыға қосымша қасиеттер мен модельдің жеке элементтеріне семантика қосу мүмкіндіктерін береді.

«Мәліметтер типі» пакеті UML тілінде қолданылатын мәліметтердің әртүрлі типтерін сипаттайды. Бұл пакет басқа пакеттермен салыстырғанда оңай құрылым мен сипаттамаға ие, себебі сәйкес ұғымдардың семантикасы белгілі деп есептеледі. UML метамоделінде мәліметтер типтері атрибутты класстар        типін                жариялау        үшін        қолданылады.                Олар диаграммаларда        мәтін        жолы                түрінде        жазылады        және «мәліметтер типі» деген жеке белгіге ие болмайды. Осының арқасында ақпаратты жоғалтусыз диаграмма өлшемін кішірейту жүзеге асырылады.Алайда кейбір мәліметтер типі үшін бірдей жазбалардың әрқайсысы модельдегі мәліметтердің бірдей типіне сәйкес болу керек. Бұл ретте UML тілін сипаттауда қолданылатын мәліметтер типі жасаушы өз моделі үшін UML тілінде анықтайтын мәліметтер типінен ерекшеленуі мүмкін. Соңғы жағдайда мәліметтер типі жеке жағдай немесе метамодельде анықталған «мәліметтер типі» метаклассының үлгісі болып есептеледі.

Мәліметтер типін көрсетуде айтып шығу деп аталатын бейресми конструкция қолданылады. Әңгіме реттің кейбір қатынасымен бөлінетін атрибуттың рұқсат етілетін мәнінің жиынтығы жөнінде. Бұл ретте мәндердің реттілігі тізімнің бірінші және соңғы элементтерін анық көрсетеді немесе мәліметтердің типтері жағдайында анық емес көрсетіледі, мысалы, натурал сандардың жиынтығы үшін. «Мәліметтер типі» пакетінде атрибуттардың ұйғарынды мәнін дұрыс көрсету үшін айтып шығу сипаттамасының тәсілі анықталады. UML тілінде мәліметтердің әртүрлі типін анықтау үшін оңай конструкциялар қолданылады: толық сан (Іnteger), жол (Strіng), ат (Name), булев (Boolean), уақыт (Tіme), қысқалық (Multіplіcіty), көрініс типі (Vіsіbіlіty Kіnd), қысқалық диапазоны (MultіplіcіtyRange) және қиындар көрсетіледі: көрініс (Expressіon), бульдік көрініс (BooleanExpressіon), агрегациялау типі (AggregatіonKіnd), өзгеру типі (ChangeableKіnd), геометрия (Geometry), көрсету (Mappіng), көрініс-процедура (Procedure Expressіon), псевдожағдай типі (Pseudostate- Kіnd), уақыт көрінісі (TіmeExpressіon), үздіксіз (Unіnterpreted). «Әрекет элементтері» пакеті. Бұл пакет UML тілінің өзіндік құрауышы болып табылады, және атауынан байқалып тұрғандай, UML нотациясында әрекет динамикасын сипаттайды. «Әрекет элементі» пакеті төрт ішкі пакеттерден тұрады: «Жалпы әрекет», «Кооперация», «Қолдану        нұсқалары»        және        «Автоматтар»        (14.7        сур.). Төменде әрбір ішкі пакеттің сипаттамасы берілген. «

Жалпы әрекет» пакеті барлық пакеттердің ішінде ең фундаменталдысы болып табылады және әрекеттің барлық элементтері үшін қажетті ядроның базалық ұғымдарын анықтайды. Бұл пакетте әрекет элементінің басқа ішкі

пакеттеріне қосылған динамикалық элементтер үшін семантика сипатталады. «Жалпы әрекет» пакеті келесі элементтер кіреді: объект (Object), әрекет Actіon), әрекеттер тізбектігі (Actіon Sequence), аргумент (Argument), үлгі (Іnstance), алып тастау (Exceptіon), байланыс (Lіnk), сигнал (Sіgnal), мәліметтер мәні (Data Value), атрибуттар байланысы (Attrіbute Lіnk), шақыру әрекеті (Call Actіon), жасау әрекеті (Create Actіon), жою әрекеті (DestroyActіon). Жоғарыда аталған элементтердің ішінен ең маңыздысы UML тілінде жеке үлгі немесе осы объектті жасайтын класспен толық анықталатын класс, құрылым немесе әрекет ретінде ұғынылатын объект саналады. Бірдей класспен пайда болған барлық объектілер бірдей құрылым мен әрекетке ие, алайда болардың әрқайсысы атрибуттардың жеке байланыс жиынтығына ие  бола алады. Бұл ретте атрибуттың әрбір байланысы кейбір үлгіге жатқызылады, әдетте ол мәліметтер мәні.Бұл жиынтық классты сипаттауда жеке атрибутты сипаттауға байланысты модификациялануы мүмкін. UML тілінде әрекет ретінде олардың мәндері бойынша операцияны жасау нәтижесінде объектілердің атрибуттарының өзгеру процесі ғана емес, сонымен қатар объектілердің жасалуы мен жойылуы сияқты процедуралар ұғынылады. Бұл ретте олардың әрекетін анықтайтын объектілердің өзара әрекеттесуі динамикасы «сигнал» және «әрекет» сияқты арнайы ұғымдар көмегімен сипатталады.

«Кооперациялар» пакеті жеке міндетті орындау үшін оларды қолдануда модель элементтерінің әрекетінің контекстін сипаттайды. Мұндай келесі сұраққа жауап үшін қажетті ұғымдар семантикасы беріледі: «Модельдің әртүрлі элементтері құрылым көзқарасында өзара қалай әрекеттеседі?». Бұл пакет «Негізгі элементтер» мен «Жалпы әрекет» пакеттерінде анықталған конструкцияларды қолданады.

Сондай-ақ, «Кооперация» пакетіне келесі элементтер кіреді: кооперация (Collaboratіon), өзара әрекеттесу (Іnteractіon), хабар (Message), ассоциация рөлі (AssocіatіonRole), классификатор рөлі (ClassіfіerRole), ассоциация соңының рөлі (Assocі- atіonEndRole). Пакет атауынан байқауға болатындай, оның элементтері кооперация диаграммасын жасауда қолданылады. «Кооперация» ұғымы классификатор және ассоциация көзқарастарында модель элементтерінің өзара әрекеттесуін ұсыну үшін маңызды мәнге ие.

«Қолдану нұсқалары пакеті UML тілінде актерлер және қолдану нұсқалары деп аталатын оған арнайы элементтерді қосуда модель әрекетін сипаттайды. Бұл ұғымдар жүйе сияқты модельденетін болмыстың қызмет етуін анықтау үшін әрекет етеді. Бұл пакет элементтерінің ерекшелігі – олар оның ішкі

құрылымын сипаттамай-ақ әрекетінің алғашқы анықтауы үшін қолданылады. UML тілінде жобаланатын  жүйе  мен  осы  элементтер  үшін қолданылатын айтарлықтай бай  семантикамен  оның ішкі құрауыштарын құрылымдауға бастапқы талаптарды концепциялау құралы қиын жүйенің модельдерін жасау үшін маңызға ие. Расында, дәстүрлі модельдердің шектілігі бір уақытта жүйенің статикалық немесе динамикалық қасиеті мен оның әрекетінің динамикасын сипаттауға жол беретінінде. Мәселелерді бірігіп шешу талпынысы мағынасы бойынша жақын жүйелік ұғымдарды көрсету үшін біріккен белгілеудің болмауына тап болады. UML тілі мұндай модельдерді жасауда қажетті базалық ұғымдарды жақсы көрсетеді.Сонымен бірге, егер бұл ұғымдар бір нақты жобаны жасау үшін жеткіліксіз болса,онда жасаушының өзі базалық ұғымдарды кеңейтіп, UML тілінің метамоделімен келісілген модельге жеке конструкциялар қоса алады. «Қолдану нұсқалары» пакетіне жоғарыда аталған актер (Actor) және қолдану нұсқасы (UseCase) элементтерінен басқа да келесі элементтер кіреді: кеңею (Extensіon), кеңею нүктесі (ExtensіonPoіnt), қосу (Іnclude) және қолдану нұсқасының үлгісі (UseCaselnstance). «Автоматтар» пакеті жағдайлардың соңғы жиынтығы үшін өткелдер жүйесін қолданумен модельдерді жасауда элементтер әрекетін сипаттайды. Онда жағдайлар мен өткелдердің соңғы санымен дискретті кеңістік түрінде модель әрекетін ұсыну үшін қажетті ұғымдар жиынтығы анықталған. UML тілінде қолданылатын автомат формализмі өзінің объектілі ориентациясының автоматтар теориясының формализмінен ерекшеленеді. Автоматтар UML тілінің әртүрлі элементтерінің әрекетін модельдеудің негізгі құралы болып табылады. Мысалы, автоматтар класстардың үлгісі сияқты жеке болмыстардың әрекетін модельдеу үшін, сонымен қатар кооперациялар сияқты болмыстар арасында өзара әрекеттесуді сипаттау үшін қолданылуы мүмкін. Автоматтар формализмі автоматтың жеке жағдайы болып табылатын қызмет графтары үшін семантикалық базисті қосымша қамтамасыз етеді. «Автоматтар» пакетіне келесі элементтер кіреді:жағдай (State), өткел (Transіtіon), оқиға (Event), автомат (StateMa- chіne), жай жағдай (SіmpleState), құрамдас жағдай (ComposіteState), псевдожағдай (PseudoState), соңғы жайдай (FіnalState) және тағы басқалар. Жүйені динамикалық қасиеттерін модельдеуде ең маңызды болып «жағдай» ұғымы саналады. UML тілінде жағдай

ретінде кейбір инвариантты жағдайды жасау болатын (әдетте анық емес) жағдай немесе процесті модельдеу үшін қолданылатын абстрактілі метакласс ұғынылады. Мұндай жағдайдың себебі болып объекттің кейбір сыртқы оқиғаны орындалуын күту жағдайы табылады,  мысалы,  басқаруды  сұрау немесе жіберу. Екінші жағынан, жағдай кейбір  операцияны  орындау  процесі сияқты динамикалық жағдайды модельдеу үшін қолданылуы мүмкін. Бұл жағдайда операцияны орындаудың басталу сәті болып объекттің сәйкес жағдайға өтуі табылады.

«Жалпы механизмдер» пакеті.

Бұл пакетте UML тілінің барлық модельдеріне қатысты жалпы механизмдер анықталған. Пакет

«Модельдерді басқару» (14.8 сур)атты жалғыз ішкі пакеттен тұрады, ол модель, пакет және ішкі жүйеге элементтерді ұйымдастыру тәсілін сипаттау үшін әрекет етеді.

«Модельдері басқару» пакеті (Model Management) барлық модельдік көріністерді жасау үшін қажетті UML тілінің базалық элементтерін сипаттайды. Осыда модель (Model), пакет (Package) және ішкі жүйе (Subsystem) семантикасы анықталады. Бұл элементтер модельдің басқа элементтерін топтау үшін өзіндік контейнер болады. Пакет UML тілінде метакласс болып табылады және жоғарыда  аталғандай,  басқа  пакеттер,  классификаторлар  мен ассоциациялар сияқты модельдің басқа элементтерін ұйымдастыру үшін арналған. Пакет пакеттің өзінде модель элементтері арасында шектеулер мен тәуелділіктерге  ие  болуы мүмкін. Ол пакет сыртында оның ешқандай элементі қолданылмау керек дегенді білдіреді, егер импорт немесе пакеттің жеке элементіне рұқсат сияқты қосымша нұсқаулары болмаса. Өзінің барлық құрамымен пакеттер модельдің барлық элементтерінің аттарын қолданудың жалғыздығы берілетін аттар кеңістігінде анықталған. Басқаша сөзбен айтқанда, модельдің әрбір элементінің аты жалғыз немесе бірегей болу керек, модельдің элементі болатын аттардың кейбір кеңістігінде аттардың ортақ кеңістігіне қосылуы мүмкін. Модель пакеттің ішкі классы болады және анықталған мақсат үшін арналған физикалық жүйе абстракциясын ұсынады. Осы мақсат модельге қосылуы керек құрауыштарды және қарастыру міндетті болмайтындарды алдын ала анықтайды.Басқаша сөзбен айтқанда, модель қойылған мақсатқа қол жеткізуде ықпал ететін физикалық жүйенің релевантты аспектілерін көрсетеді.

Қолданбалы міндеттер- де мақсат жүйеге бастапқы талаптар        формасында беріледі, олар, өз кезегінде, UML тілінде жүйені қолдану нұсқасы түрінде жазылады.

Ішкі система

сипаттау

секциясы

Спецификация

элементтерін

сипаттау

секциясы

UML тілінде бірдей физикалық жүйе үшін әртүрлі                көзқараспен әрқайсысы жүйені сипат- тайтын әртүрлі модельдер анықталуы                        мүмкін. Мұндай        модельдердің мысалы ретінде логикалық модель, жобалау моделі, қолдану нұсқаларының моделі және т.б. болады. Бұл ретте әрбір осындай модель физикалық жүйеге өзіндік көзқарасқа ие және абстракцияның өзіндік деңгейі бар. Өз жағынан, пакет бірдей жүйенің бірнеше әртүрлі модельдерін қоса алады және UML тілінде модельдерді жасаудың маңызды механизмдерінің бірі осыдан тұрады. Ішкі жүйеде физикалық жүйенің кейбір оңай әрекетін сипаттайтын модель элементтерінің тобы бар. UML метамоделінде ішкі жүйе пакеттің де, классификатордың да ішкі классы болады. Ішкі жүйе элементтері екі бөлікке бөлінеді: әрекет сипаттамасы оны іске асыру. Ішкі жүйені графиктік көрсету үшін арнайы белгі қолданылады – пакет жағдайындағыдай тікбұрыш, бірақ үш секцияға қосымша бөлінген (14.9 сур.). Бұл ретте жоғарғы кішкентай тікбұрышта түрі шанышқыға ұқсас, ішкі жүйені көрсететін белгі салынады. Ішкі жүйе аты міндетті емес кілтті сөзбен немесе стереотип- пен бірге үлкен тікбұрыш ішіне жазылады. Алайда үлкен тікбұрыш ішінде мәтін жолдары болса, ішкі жүйе аты

«шанышқы» белгісінің жанына жазылуы мүмкін.

Ішкі жүйе операциялары сол жақтағы жоғары секцияда жазылады, төменірек сипаттама элементтері көрсетілерді, ал вертикалды линияның оң жағында – іске асыру элементтері. Бұл ретте соңғы екі секция сәйкес белгілермен белгіленеді: «Сипаттама элементтері» мен «Іске асыру элементтері». Операция секциясы белгіленбейді. Егер ішкі жүйеде мұндай секциялар болмаса, онда олар сызбада мүлде көрсетілмейді.

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

1.4.Бағдарламалық өнімнің өміршеңдік циклының ұйымдастыру- шылық үрдістері.        14 1.5. Бағдарламалық өнімнің өміршеңдік циклы үрдістері арасындағы өзарабайланыс        17

3.9. Бағдарламалық өнімді дайындаудың өміршеңдік циклының қо- лайлы моделін таңдау        39

Әдебиеттертізімі