Тініш анализі үрдісінің схемасы

1. «Тапсырыс берушіні» идентификациялау. Қ ызығ ушылық танынатын тұ лғ аларды анық тау, яғ ни, қ ортындылаушы ө німде ө зіне тиесілі бө лігі бар тұ лғ алар;

2. Тапсырыс беруші ө кілдерімен сұ хбат ұ йымдастыру. Яғ ни олардың:

· талғ амы мен қ ажеттілігін анық тау;

· Қ олдау қ ұ ралдарын пайдалану;

· Пайдаланушының графикалық интерфейсін нобайын жасау;

· Жабдық тың конструкциясын анық тау;

3. С-талабын стандартты қ ұ жат формасында жазу.

4. С-талабын тексеру;

5. В-талабын қ ұ ру;

Барлық этаптар ү шін келесі куә ліктерді қ адағ алау керек:

· Жұ мсалғ ан уақ ыт;

· С-талабының беттер саны;

· Тапсырыс берушімен сө йлесуге кеткен уақ ыт мө лшері;

· Сапасын ө зіндік бағ алау;

· Тексеру жайында кемшіліктерді бағ алау;

SPS-ті ұ йымдастырудың бірнеше тә сілдері бар. IEEE830-1993 стандартының тарауы берілген:

1. Кіріспе

Мақ саты

Қ олдану аймағ ы

Анық талуы, терминдер мен қ ысқ артулар

Сілтеме

Шолу

2. Жалпы сипатталуы

Ө німнің перспективасы

Жү йелік интерфейстер

Пайдаланушы интерфейстер

Аппараттық интерфейтер

Программалық интерфейстер

Коммуникациялық интерфейтер

Жады бойынша шектеулер

Операциялар

Бейімделу бойынша ө тініш

Ө нім функциясы

Пайдаланушы сипаттамалары

Шектеулер

Болжамдар мен тә уелділіктер

Ө тініштердің бө лінуі

3. Толық қ анды ө тініштер

4. Ақ паратты сү йемелдеу

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

Ө тініш анализін контекстте қ арау керек. Себебі:

– Ө тініш туындауының себепшісі адамдар екені даусыз

– ө тініш беруде ә р тапсырыс берушінің талабы дара сипатталады

– жасаушылар ө тініштерге тү бегейлі ық пал ететін кә сіби жауапкершілікті арқ алайды;

– тапсырыс берушінің қ алауынан гө рі мұ қ таждығ ын анық тау қ иынырақ;

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

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

 

Тапсырыс беруші ө тініштерінің сипаттамасы (С-талаптар)

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

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

USE CASE тұ тыну варианты – тұ тынушы ү шін қ андай да бір ұ тымдылығ ы бар қ ызметтердің толық қ анды жиынтығ ы іспетті.

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

Лешека Мацяшек [4] бойынша ө тініш анализі тұ тыну мен пә ндік сала объектілерін кесте арқ ылы анық тау вариантының спецификасымен сә йкес болуы мү мкін:

– тұ тыну варианты мен субъекті бойынша тармақ тау;

– тұ тыну варинаты спецификасының сипаттамасы;

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

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

Тұ тынушығ а бейімделген интерфейсті жобалаудың принциптері басты бастамашы принциптері [4, 7 тарауда] кө рсетілген.

Тұ тынушы интерфейстерін жасаудағ ы басты қ адамдарын кө рсетейік:

1. Ө з тұ тыеушың ызды анық таң ыз (с) (С-ө тініштерді ө ң деу);

2. Жобаланғ ан жү йенің бағ ытын тү сінің із (С, D);

3. Жақ сы экрандық дизаинның принциптерінің қ олданылуы (С, D).

4. Терезелердің тиісті типін таң даң ыз (С, D);

5. Меню жү йесін жасап шығ ың ыз (С, D);

6. Қ ажетінше басқ арудың аппараттық қ ұ рлымын таң даң ыз (С);

7. Қ ажетінше басқ арудың экрандық элементтерін таң даң ыз (С);

8. Терезелерді реттемесін ұ йымдастырып, жасап шығ ың ыз (С, D);

9. Қ ажетті тү стерді таң даң ыз (D);

10. Сарапталғ ан белгілерді қ ұ рың ыздар (С, D);

11. Нә тижелі хабарламалар, кері байланыс жә не басшылық ты табың ыздар (D).

Тапсырыс беруші талаптарын жү йелеудің тө рт ә дісі:

1. Қ арапайым жә не ө зімен-ө зі тұ ратын талаптар бар, оны қ ысқ а да нұ сқ а сө йлемдермен берің із;

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

3. Егер де талаптар ә рбірі мә ліметтерді алатын жә не беретін ө ң деу элементтеріне қ атысы болса, мә лімметтер легінің диаграммасын пайдаланың ыз;

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

– бағ дарламаның барлық кү йін анық таң ыз;

– бастапқ ы кү йді кө рсетің із;

– кү йлердің алмасуын қ амтитын жағ дайларды анық таң ыз;

– енгізілген кү йлерді анық таң ыз.

 

Жылдам прототиптеу жә не жү зеге асырудың зерттелуі

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

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

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

 

Ө тініштер анализі: детальдық талаптардың қ осылуы

Детальдық талаптар (Д-талаптар) – бағ дарламаның нақ ты табиғ аты ашылатын бір ғ ана қ ұ жат. Детальдау дең гейі шамадан тыс емес, толық қ анды болуы керек.

Жасаушылар ү шін Д-талаптар жобалау мен ө ң деудің базасы ретінде алынады.

Д-талаптар анализі процесінің типтік сызбасы мыналардан тұ рады:

1. Д-талаптарды ұ йымдастыру жү йесін таң дау;

2. Тұ тыну варианттары ү шін реттілік диаграммасын қ ұ ру;

3. С-талаптардан жә не тапсырыс берушіден Д-талаптарды алу;

4. Тестілеу жоспарының шимай парағ ын жасау;

5. Инспекциялау жү ргізу;

6. Тапсырыс берушімен келісу (кері байланыс 3п.)

7. Компонент тапсырыс берушіні қ анағ аттандырғ ан уақ ытта шығ ару.

Д-талаптардың типтері:

Талаптардың бірнеше типі болады:

1. Талаптардың функционалдығ ы:

– қ осымшаның функционалдығ ы;

2. Функционалды емес талаптар:

1) Ө німділік: жылдамдық, ө ткізу қ абілеті, жадыны қ олдану;

2) Сенімділігі мен іздеуге оң айлығ ы;

3) Қ ателіктерді ө ң деу;

4) Интерфейстік талаптар, басқ аша айтқ анда бағ дарлама ө зге бағ дарламалар немесе тұ тынушымен қ алай ө зара байланысады;

5) Шектеулер: жобалау қ ұ ралдары мен тілінің нақ тылығ ы, қ олданылатын стандарттар мен платформалар;

 

3.Кері байланыс, бағ дарлама орындамайтындарды санамалап кө рсету. Бұ л жіктеме С, сондай-ақ Д-талаптарғ а арналғ ан. Алайда Д-талаптарды жазуда маң ызы арта тү седі. Себебі, ол тү рлі аспектілерді тестілеу жә не ө ң деу процестерін басқ арады.

Д-талаптардың қ асиеттері:

Жобаның барлық детальдары қ атылуы жә не де ұ мыт қ алмасы ү шін Д-талаптар иеленуге тиісті тө мендегі талаптар енгізілуі тиіс.

1) Қ адағ алануы:

· функционалды талаптардың қ адағ алануы;

· фунционалды емес талаптардың қ адағ алануы.

2) Тестілеуге жарамдылығ ы мен бірізділігі;

3) Артық шылық тары немесе талаптарды: маң ызды, мү мкіндігінше қ ажет жә не шарт емес деген категорияларғ а жіктеу арқ ылы артық шылық тарды белгілеу;

4) Талаптардың толық тығ ы немесе ө здігінен толық қ анды болуы;

5) Қ ателіктің жағ дайы – қ ателік оқ иғ асына деген талаптарды тексеру;

6) Келісімділік – талаптар арасында қ айшылық тың болмауы.

Д-талаптарды ұ йымдастырудың ә дістері:

Д-талаптарды бірнеше сызба арқ ылы бейнелеп беруге болады:

– басты қ асиеттері бойынша, яғ ни талаптар бағ дарламаның тү рлі қ асиеттері бойынша топтастырлығ ан;

– бағ дарламаның жұ мыс режимі бойынша;

– тұ тыну варианттары немесе сценарий бойынша. Мұ ның детальдық талаптардың кө пшілігі қ олдану вариантының бө лігі болып табылатындығ ында.

– класс бойынша;

– функциялар иерархиясы бойынша, басқ аша айтқ анда бағ дарламаны функционалды декомпазициялау арқ ылы;

– жағ дайлар арқ ылы немесе бағ дарлама қ амтылуы мү мкін ә р жағ дайда қ олданылатын детальдық талаптарды кө рсету арқ ылы. Ә р жағ дай классификациясы ішінде бағ дарламағ а ық пал ететін нақ ты бір жағ дайдағ ы оқ иғ алар кө рсетілген.

Д-талаптарды жіктеме жиынтығ ында ұ йымдастыруды кең ес етуге болады.

Д-талаптарды ұ йымдастыру қ ұ ру ә дісі қ осымшаның мү мкін болатын архитектурасымен байланысты.

Д-талаптарды анализдеуге арналғ ан куә ліктер

Детальдық талаптар сапасын бақ ылайтын куә ліктер мынаны қ амтиды:

– талаптар қ аншалық ты жақ сыс жазылғ андығ ын кө рсететіндердің куә лігі;

– талаптарды тексерудің нә тижелілігінің куә лігі;

– талаптар анализі процесінің нә тижелілігі процесінің куә лігі.

– талап(требование) толық тығ ының метрикасы.

 

Негізгі ә дебиеттер – 2[3-бө лім, 183-215; 4-бө лім, 239-293], 7[103-202],

5[1-бө лім, 57-98; 2-бө лім, 99-164; 5-бө лім, 223-292].

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

1. С- жә не D-талаптарының арасындағ ы ерекшеліктері қ андай?

2. Талаптарды С- жә не D-талаптарына бө лудің артық шылық тары мен кемшіліктері неде?

3. Талаптарды талдау қ андай мә селелерді шешеді?

4. Мә ліметтердің ағ ынының диаграммасы деген не?

5. Ағ ындарды басқ ару диаграммасының ерекшеліктері неде?

6. Кү йлерге ауысу диаграммасын қ алай орындайды(ұ йымдастырады)?

7. Мә ліметтер қ ұ рылымына бағ ытталғ ан талдау ә дістері қ андай мә селелерді шешеді?

8. Тапсырыс берушінің талаптарын қ ұ растыруда контекстті пайдалану нұ сқ асы деген не?

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

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