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

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

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

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

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

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

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

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

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. Бөлшекті талаптарды ұйымдастыру әдісі мен қасиеттерінің бірнеше категорияларын атаңыз.

4- Дәріс. Архитектуралы жобалау

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

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

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

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

Программалық қамтама жүйесінің принциптік проблемасы – бұл оның күрделілігі. Күрделілікке күресудің тиімді әдісі – модуляризация немесе есептің ішкі есептерге декомпозициясы болып табылады. Декомпозицияның орындалуының критериіне - байланыстылық пен (сцепление) сияқты сипаттамалары жатады. Модуль ішіндегі байланыстылық деген ол – модуль элементтерінің арасындағы өзара байланыс күші. Сцепление – модульдер арасындағы өзара әрекеттестік дәрежесін сипаттайды. Тиімді модульдік - байланыстылықтың максимизациясы мен сцепление минимизациясы кезінде анықталады.

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

Мысал ретінде жеке қаржылық қосымша декомпозициясын қарастырайық.

• Есептер (тексеру, сақтау және т.б.);

• Есептер төлемі (электронды, чектер және т.б.);

• Глобальді есептер (жалпы активтер, қарыз және т.б.);

• Займ (қарыз) (автомобиль, білім, үй және т.б.);

• Инвестициялар (акциялар, қарыз міндеттері және т.б. );

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

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

• Интерфейс (пайдаланушы және коммуникациялы интерфейс, есеп берушілік отчетность және т.с.с.);

• Жабдықтаушылар (поставщики) (жалға беруші, пайызсыз қарыз, коммуналдық қызметтер және т.б.);

• Активтер (есептерді тексеру, акциялар, қарыз міндеттері және т.б.);