УМКД

Ақпараттық жүйелерді жобалау әдістері

Пәнінің оқу-әдістемелік кешені

"Ақпараттық жүйелерді жобалау"

5В070300 – «Ақпараттық жүйелер» мамандығына арналған

ОҚУ - ӘДІСТЕМЕЛІК МАТЕРИАЛДАР

Семей
2014

Алғы сөз

1. Құрастырылған

Құрастырушы ___________ «______» ______________ 2014 ж., Д.Д.
Жақсығұлова, аға оқытушы, Семей қаласының Шәкәрім атындағы мемлекеттік
университетінің «Ақпараттық жүйелер» кафедрасы.

2. Талқыланды

2.1. Шәкәрім атындағы мемлекеттік университетінің «Ақпараттық жүйелер»
кафедрасының мәжілісінде

Хаттама № ______ , «_____» __________ 2014 ж.

Кафедра меңгерушісі __________ С.К. Смагулов

2.2. «Ақпараттық-коммуникациялық технологиялар» факультетінің оқу-
әдістемелік бюросының отырысында қарастырылды

Хаттама № ______ , «_____» __________ 2014 ж.

Төрайымы__________ Р.С. Бекбаева

3. бекітілГЕН

Университеттің оқу-әдістемелік кеңесінің мәжілісінде қаралып, баспаға
ұсынылды

Хаттама № ______ , «_____» __________ 2014 ж.

ОӘК төрайымы _______________ Г.К. Искакова

4 18.09.2013 ж. №1 баспа орнына енгізілді

Мазмұны

1. глоссарий

Осы ОӘМ келесі терминдер қолданылған:

2. Дәрістер

Дәрістік сабақтардың тезисі

1,2,3 апталар

Тақырып 1. Кіріспе. Ақпараттық жүйелер

Дәріс жоспары
1. «АЖ жоспарлау» пәнінің мақсаты және міндеті.
2. Жүйе, АЖ: анықтамасы.
3. Сақталатын берілгендерді типіне байланысты АЖ классификациясы.
4. Автоматтандыру жағынан АЖ классификациясы.
5. Қолдану сферасындағы АЖ классификациясы.
6. Берілгендерді өңдеудегі АЖ классификациясы.
7. АЖ басқару деңгейінің классификациясы.
8. Масштабы бойынша АЖ классификациясы.
9. Ұйымдастыру тәсілі бойынша АЖ классификациясы.

Дәрістің қысқаша конспектісі

«АЖ жобалау» пәнінің мақсаты және міндеті.
«АЖ жобалау» пәнінің мақсаты- күрделі жүйелердің синтезі және негізгі
концепциялары мен анализ методологиясы, ақпараттық жүйелерді жобалаудың
принцптері, қазіргі заманғы экономико-математикалық тәсілдерге және есептеу
техникасына негіз болады.
«АЖ жобалау» пәнінің мағынасымен ролі әртүрлі кәсіподақтар мен
экономикада, жаңа ғасырдың технологиялық дамуындағы компьютерлік жүйелерге
қажеттілікпен анықталады. Ақпараттық жүйелер тек кана күрделене бермей,
және де ақпараттандыруы дамыған, мобильді, қауысыз, қол жетімді және
пайдаланушыға жолдас болуы қажет және т.с.с.
Курсты оқу кезінде студенттер келесіні білу қажет:
Білу:
- ақпаратты жүйелерді жоспарлаудың методологиясын макро және микро
деңгейде;
- жүйелердің иерархиялық принцптері;
- жүйелік анализ;
Іскерлік

- жобалаудың барлық кезеңдерінде ақпаратты жүйелерді тиімді жобалау үшін
есеп жүйелерін декомпозициялау әдістерін пайдалану;
- ақпаратты жүйелердің ұйымдастырылған және функцияналды құрылымдарын
жобалаудың формальданған тәсілін әдісін пайдалану;
- күрделі жүйенің эскиздік жобасын жасау және жобаланған жүйенің сапасы
мен сенімділігінің бағасы анықтау;
Дағды

- ақпаратты жүйенің қамтамасыздандырудың барлық түрлерінжобалаудың
инструментальды құралдарын және жаңа ақпараттық технологияларды
пайдаланып жобалау;

Ұғымдарды анықтау: Жүйе, Ақпараттық жүйелер

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

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

1. Сақталатын деректердің типіне байланысты АЖ фактографиялық және
документтік болып классификацияланады.

Фактографиялық жүйелер құрылымдалған деректерді мәтін және сан
түрінде сақтауға немесе өңдеуге болады. Мұндай деректермен әртүрлі
операциялар жасауға болады. Құжаттық жүйелерде ақпарат құжат түрінде
берілген, олар нұсқаулар мен реферат және тексттерден тұрады. Таңдап
алынған құжат тер пайдаланушыға беріледі, ал берілгендерді өңдеу бұл жүйеде
іс жүзінде жасалмайды.
2. Автоматтандыру деңгейі бойынша классификациясы. Ақпараттық жүйелер
бірнеше түрге бөлінеді: қарапайым қол күшімен, автоматтық және
автоматизацияланған.
Қолдық АЖ: Мұнда ақпаратты өңдейтін жаңа технологиялар жоқ, барлық
операциялар адаммен орындалады. Мысалы: менеджері бар офисте
компьютерлердің жоқтығы, оны қолдық АЖ деп айтуға болады.
Автоматтандырылған АЖ ақпаратты өңдеуде адамды және технологиялық
құрылғылардың қатысуы, дегенмен компьютерге негізгі рол бағытталады. Дәл
осы класс қазіргі заманғы АЖ-ге нақ келеді.
Автоматты АЖ өндірудің барлық операциялары орындалады, бірақ адам
көмегінсіз.
3. Қолдану аясы бойынша классификациясы.
Ұйымдастырылған басқару АЖ - басқару персоналының функциясын
автоматтандыруға арналған. Бұл класқа ақпараттық жүйелерді басқару кәсіптік
фирмада және кәсіптік емес фирмаларда қолданылады: қонақ үйлерде,
банктерде, сауда фирмаларымен және тағы басқалар. Осындай жүйелердің
негізгі функциялары мыналар болып табылады: оперативті контроль және
реттеу, оперативті учет және анализ, оперативті жоспарлау, бугалтерлік
учет, қамтамасыздандыру мен басқа экономикалық және ұйымдастыру есептері.
Технологиялық процестерді (ТП) басқарудың АЖ өндірістегі персонал
функциясын автоматтандырады. Мұндай жүйелерде негізінен технологиялық
процестер, графикалық документтер жасау, проекттік документация құру,
жобаланушы объекттерді модельдеу.
Автоматтандырылған жобалаудың АЖ (САПР) предназначены для
автоматизации функций инженеров-проектировщиков, конструкторов,
архитекторов, дизайнеров при создании новой техники или технологии.
Основными функциями подобных систем являются: инженерные расчеты, создание
графической документации (чертежей, схем, планов), создание проектной
документации, моделирование проектируемых объектов.
Интегрирланған (корпоративті) АЖ фирманың барлық функцияларын
автоматтандыру үшін пайдаланылады, жобалаудан өнім өндіруге дейін. Олардың
құрамына бірнеше модульдер енген, олар бір ортақ ақпараттық кеңістікте
жұмыс істейді.
4. Деректерді өңдеудеу характері бойынша классификациясы.
Ақпаратты - іздеушілер жүйелері пайдаланушының сұранысы бойынша
деректерді күрделі түрлендірусіз ақпаратты енгізуді, жүйелеуді, сақтауді,
беруді орындайды. Мысалы, ақпаратты іздеу жүйесі кітапханада, теміржол
кассаларында билет сату.
Ақпаратты - шешуші жүйелер белгілі бір алгоритіммен ақпаратты
өңдеудегі барлық функцияларды, операцияларды орындайды. Мұндай жүйелер
басқаратын және бағыт беретін болып бөлінеді.
Басқарушы АЖ адам есептеу кезінде пайдаланылатын ақпарат жинайды.
Мұндай жүйелерге үлкен көлемді жүйелерді өңдеуге және есептік шығаруларға
арналған.
Кеңес беретін АЖ бұл жүйелер жоғары интелектті, сондықтан бұлар
берілгенді емес, білімді өңдейді.
5. Басқару деңгейі бойынша классификациясы. АЖ оперативті деңгейі
АЖ оперативті ()операциялы) деңгейі - фирма мен сыртқы орта мен
байлаушы звено болып табылады.
Мамандардың АЖ берілгендер мен біліммен тығыз қатынаста болады, бұл
инжинер мен жаба құрушылардың өнімін өсіреді.
Стратегиялық деңгейдің АЖ құрылымдалмаған есептерді шешуге көмектеседі
және жобалаудың ұзақ болуына әсер етеді.
Негізгі мақсаты – ішкі ортадағы болып жатқан өзгерістерді салыстыру.
Кейбір стратегиялық жүйелердің аналитикалық мүмкіндіктері шектелген болады.
АЖ классификациясын бір қатар белгілері бойынша жүргізуге болады: масштабы
бойынша, апараттық құралдардың структурасы бойынша, ұйымдастыру тәсілі, ПҚ
пайдалану типі, пйдаланушымен ара қатынас, шығарылатын шешімнің типі
бойынша, ақпаратты өңдеудің тәсілі бойынша.

Өзін тексеру сұрақтары
1. Түсініктердің анықтамасын бер: жүйе, ақпараттық жүйе.
2. АЖ сақталатын деректердің типіне байланысты классификациялағанда қандай
АЖ қарастырылады?
3. АЖ автоматтандыру деңгейі бойынша классификациялағанда қандай АЖ
қарастырылады?
4. АЖ автоматтандыру дәрежесі бойынша классификациялағанда қандай АЖ
қарастырылады?
5. АЖ қолданылу аясы бойынша классификациялағанда қандай АЖ қарастырылады?
6. АЖ деректерді өңдеу мінездемесі бойынша классификациялағанда қандай АЖ
қарастырылады?
7. АЖ басқару деңгейі бойынша классификациялағанда қандай АЖ қарастырылады?
8. АЖ масштабы бойынша классификациялағанда қандай АЖ қарастырылады?
9. АЖ ұйымдастыру тәсілі бойынша классификациялағанда қандай АЖ
қарастырылады?

Әдебиет:
1. Петров В.Н. Информационные системы. СПб.: Питер, 2002.
2. Диго С.М. Проектирование и использование баз данных. - М.: Финансы
и статистика, 1996.
3. Проектирование экономических информационных систем // под ред.
Смирновой Г.Н. - М.: Финансы и статистика, 2001.

4 апта

Тақырып 2. Түсініктерді анықтау: АЖ жобалау, АЖ жобалау
методологиясы, АЖ жобалау технологиясы.

Дәріс жоспары
1. АЖ жобалау .
2. АЖ жобалау технологиясы.
3. АЖ жобалау әдістемесі.
4.
Дәрістің қысқаша конспектісі
Қазіргі уақыттағы ақпараттық технологиялар таңдаулары өңдеу процесінде
өзгеріп отыратын көбінесе таңдау қолданушылар талабы негізінде іске асатын
АЖ реализациясының кең әдістерін көрсетеді.
АЖ жобасымен АЖ нақты программалық-техникалық ортадағы эксплуатацтясын
құру бойынша біз технологиялық және жобалы-конструкторлық құжаттаманы
түсінеміз.
АЖ жобалаумен АЖ жобасындағы ГОСТ-қа сәйкес аналогты берудің
объектілерін жобалау мамандануы, әдістері және объекті туралы кіріс
ақпаратының түрлену процесі түсіндіріледі. Осы көзқарас бойынша АЖ жобалау
АЖ өмірлік циклының түрлі стадияларындағы жобалы шешімдердің кезекті
формализациясына сәйкестендіріледі: жоспарлаудың және талаптың анализінің,
техникалық және жұмысшы жобалаудың, АЖ эксплуатациялау және енгізудің.
Өңделетін жүйелердің масштабтары жобалау процесінің қатысушыларының
санын және құрамын анықтайды. Жобалы жұмысты орындаудың қатаң мерзімдері
және үлкен өлемі кезінде жүйенің өңделуінде бірнеше жобалы ұжым (өңдеушілер-
ұйымдар) қатыса алады. Бұл жағдайда барлық ұйымдар-орындаушылар қызметтерін
координациялайтын басты ұйым ерекшеленеді.
АЖ жобалаудың іске асуы өңделетін жобаның ерекшелігіне және масштабына
сәйкес келетін жобалаудың нақты технологиясын жобалаушылармен қолдануды
айқындайды.
АЖ жобалаудың технологиясы — бұл АЖ жобалаудың құралдары және
әдістемесі, сондай-ақ оның ұйымының құралдары мен әдістері (АЖ жобасының
модернизациясының және құрылу процесін басқару).
Жобалау технологиясының негізінде іс-әрекетін, оның кезектілігін,
талап етілетін орындаушылардың құрамын, құралдарын және ресурстарын
анықтайтын технологиялық процесс жатыр.
АЖ жобалаудың технологиялық процесі толығымен әрбіреуінде өзінің заты
бар байланысқан және кезекті-параллельді әрекеттерге бөлінеді. Осылайша,
жобалау технологиясы нәтижесінде, тек жобаны құруға жасалу керектігі үшін
емес, және де қалай және кіммен қандай кезектілікте анық болатын сол немесе
басқа әдіс негізінде орындалатын технологиялық операциялардың
регламентацияланған кезектілігімен беріледі.
Жобалаудың кез келген таңдалған технологиясының заты боп АЖ барлық
өмірлік стадияларындағы жобалау процесстерінің қатынастарының бейнесі
қызмет етуі керек. Жобалаудың таңдалған технологиясына қойылатын негізгі
талаптарға келесілер жатады:
• құрылған жоба тапсырыс берушінің талабына жауап беруі керек;
• жобаның барлық өмірлік циклының максималды бейнесі;
• жобалауға және жобаны алып жүруге бағалы және минималды шығындардың
қамтамасы;
• технология жобаның жобалауы және алып жүруі арасындағы байланыс негізі
болуы керек;
• жобалаушының еңбек шығармашылығының бойы;
• жобалау процесінің және жоба эксплуатациясының тиімділігі;
• жобалы құжаттаманың қарапайым жүргізілуі.
АЖ жобалау технологиясының негізін болмысы анықтайтын әдістеме,
негізгі ерекшеленетін технологиялық ерекшеліктер құрайды.
Жобалау әдістемесі өз кезегінде кейбір құралдармен ұстанатын әдістер
жиынымен реализацияланатын кейбір жобалау принциптерін, концепцияларының
болуын айқындайды.
Ақпараттық жүйелерді құру әдістемесі ақпараттық жүйені құру процесінің
ұйымына және бұл процесті басқаруда жүйенің өзіне қойылған талапқа
жауаптылық сияқты, сондай-ақ өңдеу процесінің мінездемесінде
қорытындыланады.
Шешімі корпоративті ақпараттық жүйелердің құрылу әдістемесін
қамтамасыз етуі керек болатын негізгі әдістер боп:
• құрылған ақпараттық жүйенің ұйымның мақсаттарына және есептеріне,
сондай-ақ бизнес-процесстердің автоматтандырылуы бойынша оған
қойылатын талаптарға сәйкестігі;
• алдын ала келіскен бюджет рамкасындағы берілген уақыт ағымындағы
берілген параметрлері бар жүйенің құрылуына жауаптылық;
• ұйым жұмысының өзгеріп отыратын шарттарына сәйкес қамтамасыз ету
мақсатымен жүйенің кеңейтілуінің және модификациясының, алып жүруінің
қарапайымдылығы;
• құрылған корпоративті ақпараттық жүйенің ашықтылық, ауыстырымдылық
және масштабтылық талаптарына сәйкестілігі;
• алдында өңделген құрылған жүйедегі және ұйымдарда қолданылатын
ақпараттық технологиялар құралдарын қолдану мүмкіндігі (программалық
қамтаманың, мәліметтер базасының, есептегіш техника, телекоммуникация
құралдарының).
Жобалаудың әдістемелері, технологиялары және инструментальды құралдар
(CASE-құралдар) кез келген ақпараттық жүйенің жоба негізін құрайды.
Әдістеме нақты технологиялар және ақпараттық жүйелердің өмірлік цикл
процесстерінің орындалуын қамтамасыз ететін инструменталды құралдар,
әдістемелер және оларды ұстайтын стандарттар арқылы іске асады.
Жобалау технологиясының негізгі мазмұнын кезекті технологиялық
операцияларының сипатталуынан тұратын технологиялық инструкциялар, сол
немесе басқа операциялар осыған тәуелді орындалатын шарттар, және
операциялардың өзінің сипаттамалары құрайды.
Жобалау ұйымдастыру жобалаушылар мен тапсырыс берушілер арасындағы
қатынастар әдістерін, сондай-ақ спецификалық құралдар жиынымен ұстана
алатын АЖ жобасын құру процесіндегі әдістемелер анықтамасын болжайды.

Өзін тексеру сұрақтары

Тақырып 3. АЖ құрылымы
Дәріс жоспары
1. АЖ құрылымы: АЖ қамсыздандырушы және функционалды ішкіжүйелері.
2. АЖ қамсыздаушы ішкіжүйелері.
3. АЖ функционалды ішкіжүйелері.

Дәрістің қысқаша конспектісі

АЖ-ң негізгі түсініктері

АЖ қойылған мақсатқа жету шүін ақпаратты сақтау, өңдеу ж әне
беруге пайдаланатын әдістермен, тәсілдердің өзара байланысқан
жиынтығы. АЖ қазіргі түсінігі дербес компьютердің ақпаратты қайта
өңдеудің негізгі техникалық әдістері ретінде пайдалануды
қамтамасыз етеді.
АЖ-ның даму сатылары.
1. АЖ- лер 50 - жылдары пайда болды. Бұл жылдары олар есептерді
өңдеуге және еңбекақыны есептеуге арналган.
2. 60 жылдары алыңған ақпарат көптеген параметрлер бойынша периодтық
есеп беру үшін қолданыла бастады.
3. 70 және 80 жылдардың басында АЖ - лер шешім қабылдау процесін
жеделдететін басқарушы бақлауаның әдісі ретінде кеңінен пайдалына
бастады.
4. 80 жылдардың аяғында АЖ - ны пайдалану концепциясы өзгеріске
ұшырады. Бұл кезеңнен АЖ - лері дер кезінде ақпаратты беру арқылы өнді
рістерге табыс әкелуге өтімділіктің жаңа нарығын табуға төмен
бағамен өнімді шығаруды қамтамасыз етуге көмектесті.
АТ ЭЕМ - нің көмегімен ақпаратты жинау, енгізу, тасымалдау,
сұрыптау, өңдеу, реттеу, және өңдеу жұмыстарының тізбегі.
Қазірг кездегі АТ ұғымен мәіліметтер өңдеуге байланысты үш
түрге жүктеуге болады. Олар:
-Есепке алу
-Талдау
-Шешім қабылдау.

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

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

АЖ ні ендіру келесідей мүмкіндіктер береді.
• Математикалық әдістер мен интеллектуалды жүйелер және т.б. енгізу
кезінде есептерді шешудің рационалды варианттарын алу.

• Оны автоматтандыру негізнде ауыр жұмыстардан жұмысшыларды босату.
• Ақараттың дұрыстығын қамтамасыз ету.

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

• Ақпараттар тобының кұрылысын және фирмада құжат айналым жүйелерін
жетілдіру.

• Өнімдер мен қызметтерді өңдіруге кететін шығындарды азайту.

• Бірегей кызметтерді тұтынушыларға беру.

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

Ақпараттық жүйелердің классификациясы.

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

[pic]

1 сурет. Шешілетін есептердің құрылымдық белгісі бойынша АЖ - дің
клссификациясы.
Модельдік АЖ-лер тұтынушыға математикалық статистикалық қаржылық
және басқа да модельдерді береді. Оларды пайдалану альте- рнативаларды
құруға және бағалауға мүмкіндік береді. Тұтынушы шешім қабылдау үшін
оған жетіспейтін ақпаратты алу үшін зерттеу процесінде модель мен
диолог құру жолымен алуға болады.
Эксперттік АЖ лер экспертті жүйелерді құру есебіне тұтынушылардың
мүмкін альтернативаларын бағалауды қамтамасыз етеді.

АЖ- дің басқа да классификациялары.
1. Автоматтандырылу дәрежесі бойынша классификациялау.
2. Ақпаратты пайдалану бойынша классификациялау.
3. Қолдану сферасына байланысты классификациялау.

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

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

Автоматтандыру деңгейі бойынша

[pic]

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

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

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

Өзін тексеру сұрақтары:
1. Ішкіжүйе дегеніміз не?
2. АЖ қамтамасыздаушы ішкіжүйелер деген не?
3. АЖ функционалды ішкіжүйелер деген не?
4. Келесі АЖ қамтамасыздаушы ішкіжүйелердің мағынасын ашу керек:
техникалық қамсыздандыру, ұйымдастырушылық қамсыздандыру, программалық
қамсыздандыру, құқықтық қамсыздандыру, математикалық қамсыздандыру,
ақпараттық қамсыздандыру, технологиялық қамсыздандыру, лингвистикалық
қамсыздандыру.
Келесі АЖ функционалды ішкіжүйелердің мағынасын ашу керек:
перспективті даму, өнімнің сапасын басқару, технико – экономикалық
жоспарлау, дайын өнімді сату және таратуды басқару, бухгалтерлік есеп және
шаруашылық қызметтің анализі, өндірістің техникалық дайындығы, негізгі
өндірісті басқару, кадрларды басқару, көмекші персоналдарды басқару,
материалдық – техникалық қамтамасыздау..

Әдебиет:
1. Петров В.Н. Информационные системы. СПб.: Питер, 2002.
2. Диго С.М. Проектирование и использование баз данных. - М.: Финансы
и статистика, 1996.
Проектирование экономических информационных систем // под ред.
Смирновой Г.Н. - М.: Финансы и статистика, 2001.

7, 8 апталар

Тақырып 4. Ақпараттық жүйелердің өмірлік циклы
Дәріс жоспары
1. АЖ өмірлік циклы.
2. ПҚ ӨЦ құрылымы.
3. АЖ ПҚ ӨЦ стадиялары.
4. АЖ ПҚ ӨЦ үлгілері.
Ақпараттық жүйелердің өмірлік циклы
АЖ жобалаудың әдістерінің базалық түсініктерінің бірі боп оның
программалық қамтамасының өмірлік циклы түсінігі табылады.
АЖ ПҚ ӨЦ – бұл АЖ құру қажеттілігі туралы шешімді қабылдау моментінен
басталатын және оның эксплуатациясы кезінен толық алу моментінде аяқталатын
үздіксіз процесс. Әйтпесе АЖ ПҚ ӨЦ оның құрылуы және қолданылу процесі
кезінде жүйемен болып жататын оқиғалары сияқты көрсетуге болады.
АЖ ӨЦ регламентациялайтын негізгі нормативті құжат боп ISO/IEC 12207
халықаралық стандарт (ISO - International Organization of Standardization –
стандарттау бойыынша халықаралық ұйымдар, IEC - International
Electrotechnical Commission – электротехника бойынша халықаралық комиссия)
табылады. Ол АЖ құру уақытында орындалатын процесстерден, әрекеттерден және
есептерден тұратын ӨЦ құрылымын анықтайды.
ISO/IEC 12207 стандарты бойынша ПҚ ӨЦ құрылымы процесстердің үш
тобына базаланады:
• ӨЦ негізгі процесстері (алу, қою, өңдеу, эксплуатация, алып жүру);
• Негізгі процестердің орындалуын қамтамасыз ететін көмекші процесстер
(құжаттау, конфигурацияны басқару, сапаны қамтамасыз ету, верификация,
аттестация, баға, аудит, проблемаларды шешу);
• Ұйымдастырылған процесстер (жобаларды басқару, жобаның
инфрақұрылымының құрылуы, анықтау, ӨЦ өзінің жақсаруы және бағасы,
оқыту).
ӨЦ негізгі үрдістері
ӨЦ негізгі процесстерінің ішінде маңызды орынды үшеуі алады: өңдеу,
эксплуатациялау және алып жүру.
АЖ өңдеу өзіне ақпараттық ПҚ құру бойынша барлық жұмыстарды және оның
берілген талаптарына сай компоненттерін, онымен қоса жобаланаған және
эксплуатацияланған құжаттауды, өңделген программалық азықтар үшін қажет
материалдардың дайындығын және персоналды оқытуға арналған ұйымдар үшін
қажет материалдарды өңдеуді және т.б. қосады. Эксплуатация өзіне
эксплуатациға АЖ компоненттерін енгізу бойынша барлық жұмыстарды, сонымен
қатар мәліметтер базасының конфигурациялануын және қолданушылардың жұмыс
орнын, эксплуатационды құжаттауды қолданушыларды қамтамасыз етуді,
персоналды оқытуды жүргізуді және т.б., және эксплуатацияны, сонымен қатар
проблемалардың локализациясын және олардың пайда болу себептерін жоғалтуын,
орнатылған регламент рамкаларындағы ПҚ модификациясын, орындалуы бойынша
ұсыныстардың дайындығын және жүйенің модернизациясын қосады.
Алып жүру өзіне АЖ техникалық көмегін қосады. АЖ техникалық қызмет
көрсету ұйымына дайындалу кезінде алдын ала негізгі әрекеттер боп табылады:
жүйенің неғұрлым жауапты түйіндерінің ерекшеленуі және олар үшін критикалық
тұрудың анықтамасы (бұл АЖ неғұрлым критикалық құраушысын ерекшелеуге және
техникалық қызмет көрсету үшін ресурстардың таралымын оптимизациялауға
мүмкіндік береді); техникалық қызмет көрсетудің есептерін анықтау және
олардың қызмет көрсететін бөлімшелер күшімен шешілетін ішкіге және
мамандандырылған сервисті ұйымдармен шешілетін сыртқыға бөлінулермен
анықталу (яғни, орындалатын функциялардың нақты анықтамасы және
жауаптылықтың бөлінуі туады); орындалатын әрекеттер этаптарын анықтауға
қажет техникалық қызмет көрсету ұйымының жоспарының дайындығы, оларды
орындау уақыты, этаптарға жұмсалған шығындар, орындаушылардың жауаптылығы.
АЖ сапалы техникалық қызмет көрсетуін қамтамасыз ету тек күнделікті
проблемаларды шешетін емес, сондай-ақ ахуалдар кезінде жүйе жұмысын тез
қалпына келтіретін жоғары квалификациялы мамандардың болуын талап етеді.
ӨЦ көмекші процесстері
Конфигурацияны басқару АЖ өмірлік циклының негізгі процесстерін,
бәрінен бұрын өңдеу және алып жүруші процестерін ұстайтын көмекші
процестердің бірі боп табылады. Әрбіреуінде түрлі версиялары бар көптеген
компоненттерден тұратын АЖ күрделі жобаларын өңдеу кезінде олардың байланыс
және функцияларын санауда, барлық жүйенің дамуын қамтамасыз етуде және
унифициярлы құрылымын құру кезінде проблемалар туады. Конфигурацияны
басқару АЖ түрлі компоненттеріне және оның барлық ӨЦ стадияларына
өзгерістер енгізуді бақылауға және систематикалық түрде санауға,
ұйымдастыруға мүмкіндік береді.
ӨЦ ұйымдастырылған үрдістері
Жобаны басқару жұмыстарды ұйымдастыру және жоспарлау сұрақтарымен,
өңдеушілер коллективінің құрылуымен және уақыттарды бақылаумен орындалған
жұмыстардың сапалылығымен байланысты. Жобаның техникалық және
ұйымдастырылған қамтамасы өзіне жобаның реализациясы, өңдеудің аралық
қалпын сипаттау әдістерінің анықтамасына және құрылған ПҚ шыдау
құралдарына, персоналды оқытуға арналған инструменталды құралдарды және
әдістерді таңдауды қосады. Жобаның сапасын қамтамасыз ету АЖ
компоненттерінің тестілеуімен және тексеруімен, верификация проблемаларымен
байланысты.
Верификация – бұл берілген этапта жеткен өңдеудің қалпы бұл этап
талабына жауап беруі туралы анықтаманың процесі.
Тексеру шыққан талаптармен өңдеу параметрлерінің сәйкестігін бағалауға
ммкіндік береді. Тексеру нақты және тосу нәтижелері арасындағы
ерекшеліктерді анықтауға арналған тестілеуге сәйкес келеді. Жобаның
реализациясы кезіндегі процессте маңызды орынды идентификация сұрақтары,
барлық жүйенің толығымен және конфигурацияны бақылау және сипаттауы алады.
ӨЦ кезеңдері
Жұмыс көлеміне және күрделілігіне тәуелді емес әрбір жоба оның
орындалуына қажет өзінің дамуында анықталған жағдайлардан өтеді: «жоба әлі
жоқ» жағдайынан, «жоба жоқ» жағдайына дейін. Идеяның тууынан жобаның толық
аяқталуына дейін дамудың баспалдағының болуын стадияларға бөлу қабылданған
(фазалар, этаптар).
АЖ өңдеудің ӨЦ болуы түрлі жақындауларда бірдей және келесі
стадиялардың орындалуына сәйкестенеді:
1. Талаптың жоспарлануы және сараптамасы (жоба алдындағы стадия) –
жүйелік сараптама. Әрекеттегі АЖ сараптамасы және зерттеуі, құрылатын
АЖ талаптарды анықтау, техникалық-экономикалық жауаптылықтың өңделуі
және АЖ өңдеуге техникалық есептің сараптамасы.
2. Жобалау (техникалық жобалау, логикалық жобалау). Қамтамасыз етілетін
жүйеастылардың құрамының және автоматталатын функциялардың қалыптасқан
талаптарының құрамының сәйкестігіндегі өңдеу және АЖ техникалық
жобасының өңделуі
3. Реализация (жұмыстық жобалау, физикалық жобалау, программалау).
Программалардың бапталуы және өңделуі, мәліметтер базасының толуы,
персоналға арналған жұмысшы инструкциялардың құрылуы, жұмысшы жобаның
өңделуі.
4. Енгізу (тестілеу, нәтижелі эксплуатация). Жүйеастының комплексті
отладкасы, персоналды оқыту, экономикалық объектілердің бөлімшелері
бойынша Эксплуатацияға АЖ этапты енізу, актінің өңделуі.
5. АЖ эксплуатациясы (алып жүру, модернизация). АЖ функционалдауы туралы
санақтарды және жарнамаларды жинау, қателерді жөндеу, АЖ
модернизациясына талаптарды өңдеу және оны орындау.
АЖ ПҚ өмірлік циклының үлгілері
ISO/IEC 12207 стандарты ӨЦ нақты үлгісін және АЖ өңдеу әдістерін
ұсынбайды. Оның регламенттері ӨЦ кез келген үлгілері, әдістері және өңдеу
технологиялары үшін жалпы боп табылады. ISO/IEC 12207 стандарты тек қана АЖ
ӨЦ процесстер құрылымын сипаттайды.
ӨЦ белгілі үлгілерінің ішінде келесілерді ерекшелеуге болады:
• Каскадты үлгі (70-ші жж.) қатал фиксацияланған қатарда жобаның
барлық этаптарының кезекті орындалуын қарастырады. Келесі этапқа көшу
алдыңғы этаптағы жұмыстың толық аяқталуын көрсетеді.
[pic]
АЖ ӨЦ каскадты үлгісі
• Итерационды үлгі (аралықты бақылауы бар этапты үлгі) (70-ші – 80-ші
жж.). АЖ өңдеу этаптар арасындағы кері байланыстың циклдері бар итерациямен
жүргізіледі. Этапраралық корректілеу түрлі этаптарда өңдеу нәтижелерінің
өзараәсерлігін нақты санауға мүмкіндік береді; этаптардың әрбіреуіндегі
өмір уақыты өңдеудің барлық периодына созылады.
[pic]
Аралықты бақылауы бар этапты үлгі
• Спиральді үлгі (80-ші – 90-шы жж.). Спиральдың әрбір орамында
азықтың кезекті версиясының құрылуы орындалады, жобаның талабы нақтыланады,
оның сапасы анықталады және келесі орамның жұмысы жоспарланады. Ерекше
көңіл өңдеудің бастапқы этапына аударылады – сараптамаға және жобалауға.
[pic]
АЖ ӨЦ спиральді үлгісі

Өзін тексеру сұрақтары:
1. АЖ бойынша ӨЦ деген не?
2. АЖ бойынша ӨЦ құрылымы қандай?
3. АЖ бойынша ӨЦ қандай үрдістер негізгі үрдістер деп аталады?
4. АЖ бойынша ӨЦ қандай үрдістер көмекші үрдістер деп аталады?
5. АЖ бойынша ӨЦ қандай үрдістер ұйымдастырушы үрдістер деп аталады??
6. АЖ бойынша ӨЦ қандай кезеңдері бар және олардың маңызы неде?
7. АЖ ӨЦ қандай модельдері бар және олардың маңызы неде?

Әдебиет:
1. Петров В.Н. Информационные системы. СПб.: Питер, 2002.
2. Диго С.М. Проектирование и использование баз данных. - М.:
Финансы и статистика, 1996.
3. Проектирование экономических информационных систем // под ред.
Смирновой Г.Н. - М.: Финансы и статистика, 2001.

9 апта

5 тақырып. АЖ-ны жобалау әдістері
Дәріс жоспары
1. Ақпараттық жүйелерді жобалау әдістері.
2. Ақпараттық жүйелерді канондық жобалау.
3. Ақпараттық жүйелерді типтік жобалау.

Дәрістің қысқаша мазмұны
Ақпараттық жүйелерді жобалау әдістері.
Ақпараттық жүйелерді жобалау әдістерін автоматтандыру құралдарын
пайдалану дәрежесі, типтік жобалау шешімдері, ұсынылған өзгертулердің
қолайлығы бойынша классификациялауға болады.
Автоматтандыру дәрежесіне байланысты жобалау әдістері бөлінеді:
• қолдық, бұнда АЖ компоненттерін жобалау арнайы программалық
құралдарсыз іска асады, ал программалау – алгоритмдік тілдерде;
• компьютерлік, бұнда жобалық шешімдерді арнайы программалық құралдар
негізінде генерациялау немесе баптау жүргізіледі.
Типтік жобалау шешімдерін пайдалану дәрежесі бойынша жобалаудың келесі
әдістерін ажыратады:
• бірегей (жеке), жобалау мәселелері Автоматтандырылған ақпараттық
жүйелерге қойылатын барлық талаптарға сай «ең басынан» құрылған кезде.
Бұл әдісте жобалау жұмыстарының барлығы жобаның әрбір объектісін
құруға негізделгенімен сипатталады, ал бұл қасиеттер бұл әдістің
барлық мүмкіншіліктерін максималды түрде бейнелейді;
• типтік, бұл әдіс АЖ-ні жылдық типтік жобалау шешімдерден
конфигурациялауды ұсынады (программалық модульдерді) Жеке жобаларды
құрудан алынған тәжірибе нәтижесінде орындалады. Типтік жобалар кейбір
ұйымдастырушылық-экономикалық топтар үшін немесе жұмыстар түрлері үшін
арналған жалпыланған тәжірибе сияқты, нақты жағдайларда көптеген
спецификалық ерекшеліктермен байланысты және басқару функциясының
қамту деңгейімен ажыратылады.
Жобалау шешімдерінің адаптация дәрежесіне байланысты келесі әдістерді
ерекше қарастырады:
• реконструкциялар (қайта құрулар), бұнда жобалау шешімдерінің
адаптациясының сәйкес компоненттері қайта өңделеді (программалық
модульдерді қайта программалау);
• параметрлеу, жобалау шешімдері өзгеріп отыратын параметрлерге сәйкес
бапталады;
• проблемалы аймақ моделі өзгерген кезде модельді қайта құрылымдау,
осының негізінде жоба шешімдері аывтоматты түрде генерацияланады.
Әдістердің әртүрлі белгілерінің үйлесімділігі АЖ жобалауда
пайдаланылатын технологияның сипаттамасын шартты түрде көрсетеді, соның
ішінде негізгі екі класты ерекшелейді: канондық және индустриалдық
технологиялар.Жобалаудың индустриалдық технологиясы, өз кезегінде, екі
подкласқа бөлінеді: автоматтандырылған (CASE-технологиясын пайдалану) және
типтік (параметрліік-бағытталған немесе модельді-бағытталған) жобалау.
Индустриалдық технологияны пайдалану кей кездері канондықты да пайдалануды
шектемейді
АЖ-ні канондық жобалау
Канондық модельдеу негізінде АЖ-нің өмірлік циклінің каскадты моделі
жатыр, біздің елімізде қолданыстағы ГОСТ 34.601-90 «Автоматтындырылған
жүйелер стандартына сай. Деңгейге бөлінеді:
1. жүйе құрудың негізі және зерттеулер;
2. техникалық тапсырманы құру;
3. жоба эскизін жасау;
4. техникалық жобалау;
5. жұмыстық жобалау;
6. іске енгізу;
7. функционалдау, жаңлау.
Нақты АЖ құрғандағы автоматтандыру объектісінің және тапсырма
күрделілігіне байланысты деңгейлер мен этаптар әр түрлі еңбексиымдылықта
болуы мүмкін. Тіркескен этаптарды біріктіріп , тіпті кейбіруін жобалаудың
әр дәрежесінде шығарып тастауға да болады. Сонымен қоса , істелініп жатқан
жұмысқа қарамастан келесі деңгейдегі жұмысты бастай беруге де болады.
Ұйымдар мен учаскеледе орындалатын АЖ-ні құру деңгейлері мен этаптары
жұмысты орындау үшін келісім-шартар мен техникалық тапсырмаларда тіркеліп
жазылады:
1 деңгей. АЖ-ға қойылатын талаптарды құрылымдау. Жобалаудың бастапқы
деңгейінде жұмыстардың келесі этаптарын бөліп қарастырады:
• объекті тексеру және АЖ құру қажеттілігін негіздеу;
• пайдаланушылардың АЖ-ге қоятын талаптарын құрылымдау;
• орындалған жұмыс және құруға арналған тактикалық-техникалық
тапсырмалар туралы есепті рәсімдеу.
2 деңгей. АЖ концепциясын құру.
• Автоматтандыру объектісін тексеру;
• Қажетті ғылыми-техникалық ізденіс жұмыстарын жүргізу;
• Пайдаланушылар талаптарын қанағаттандыратын АЖ концепциясының
варианттарын құру;
• Концепцияны бекіту және есепті рәсімдеу.
3деңгей. Техникалық тапсырма.
• АЖ-ні құруға арналған техникалық тапсырманы құру және бекіту.
4деңгей. Жоба эскизі.
• Жүйе және оның бөліктері бойынша алдын ала құрылған жоба шешімдерін
құру;
• АЖ-ға және оның бөлшектеріне эскизді құжаттар дайындау.
5деңгей. Техникалық жоба.
• Жүйе және оның бөлшектері бойынша жобалық шешімдерді құру;
• Жүйе және оның бөлшектері бойынша құжаттар құру;
• Комплектіленетін бұйымдарды жеткізуге арналған құжаттарды және
құруларды рәсімдеу;
• Жобаның аралас бөліктеріндегі жобалауға тапсырмалар құру.
6 деңгей. Жұмыстық құжаттар.
• АЖ-ге және оның бөліктеріне жұмыстық құжаттар дайындау;
• Программалады құру және олардың адаптациясы.
7 деңгей. Енгізу және іске қосу.
• Автоматтандыру объектісін дайындау;
• Персонал дайындау
• Бұйымдармен, техникалық құралдармен, программалық-техникалық
кешендермен жеткізілетін АЖ- ны комплектілеу;
• құрылыстық-монтаждық жұмыстар;
• іске қосу жұмыстары;
• алдын ала сынақтар жүргізу;
• тәжірибелі эксплуатация жүргізу;
• қабылдау сынақтарын жүргізу.
8деңгей. АЖ-ні Сопровождение ИС.
• Кепілдік міндеттемелеріне сәйкес жұмыс жасау;
• Кепілдік бергеннен кейін де қызмет көрету.

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

Өзін-өзі тексеру сұрақтары
1. Автоматтандыру дәрежесімен классификацияланған әдістер кезінде АЖ-ні
жобалаудың қандай әдістерін бөліп қарастыруға болады?
2. Типтік жобалау шешімдері дәрежесі бойынша классификацияланған әдістер
негізінде АЖ-ні жобалаудың қандай түрлерін бөліп қарастыруға болады?
3. Жобалық шешімдердің бейімділік деңгейі бойынша классификацияланған АЖ-
ның қандай әдістерін бөліп қарастыруға болады?
4. Канондық жобалау мәнін түсіндір.
5. Типтік жобалау мәнін түсіндіру.

Әдебиет:
4. Петров В.Н. Информационные системы. СПб.: Питер, 2002.
5. Диго С.М. Проектирование и использование баз данных. - М.:
Финансы и статистика, 1996.
6. Проектирование экономических информационных систем // под ред.
Смирновой Г.Н. - М.: Финансы и статистика, 2001.

10, 11 апталар

6 тақырып. АЖ RAD жобалауының методологиясы

Дәріс жоспаты
1. RAD Методологиясы.
2. RAD Методологиясының негізгі ерекшеліктері.
3. Объектілі-бағытталған жақындау(подход).
4. Визуальді программалау.
5. Оқиғалы программалау.
6. RAD Методологиясының шеңберіндегі өмірлік цикл фазалары.
7. RAD Методологиясының шектеулері.

Дәрістің қысқаша мазмұны
RAD Методологиясы
Компьютерлік ақпараттық жүйелер ең алғашқы құрылғанда дәстүрлі
программалау тілдерінде құрылға болатын.Алайда құрылып жатқан жүйелер мен
сұраныстардың жылдан жылға күрделенуіне байланысты құрудың жылдамдығын
қамтамасыз ететін құралдар керек болды. Бұл программалық қамтама облысына
үлкен түрткі болды – қосымшалардың жылдам құрылуына арналған
инструментальді құралдарын құру. Бұл бағытың дамуы программалық қамтама
нарығында АЖ-нің барлық циклінде қолданылатын автоматтандыру құралдарының
пайда болуына ықпал етті.

RAD Методологиясының негізгі ерекшеліктері
Қосымшаны жылдам құратын құралдарды пайдалану негізінде АЖ құру
методологиясы соңғы кездері аса танымал бола бастап, қосымшаны жылдам
жасаушы методология деген атаққа ие болды.(Rapid Application Development,
RAD). Аталмыш методология қазіргі АЖ-нің барлық өмірлік циклдерін қамтыған.
RAD Методологиясы – бұл арнайы инструментальдық құралдар комплексі, бұл
комплекс қосымшаның жеке АЖ-ін бейнелейтін графикалық элементтермен жұмыс
жасауға мүмкіндік береді.
Негізінде қосымшаны жылдам жасаушы методологиясы дегеніміз 3 негізгі
элементке негізделген АЖ құру процесі:
• Программистердің шағын командасына (әдетте 2-ден 10 аадамға дейін);
• Салыстырмалы түрде аз мерзімге есептелінген өндірістік жұмыс кестесіне
( 2-ден 6 айға дейін);
• Тапсырыс берушімен тығыз байланыс жасай отырып құру моделін
интерациялау —жобаны құру барысында тапсырыс берушіге қажетті өнім
түрін анықтайды.
RAD Методологиясын пайдалану кезінде құрастырушылардың мамандану
деңгейіне аса көп мән беріледі. Құрастырушылар командасында талдау, жобалау
және программалық қамтаманы тестілеу сфераларында жұмыс істеп көрген, мол
тәжірибелі адамдар болу керек.
RAD Методологиясының негізгі принциптері:
• Жобалаудың интерациялық моделі пайдаланылады (спиральді);
• өмірлік циклдің әр этапында жұмысты толығымен аяқтау міндетті емес;
• АЖ-ні құру процесінде тапсырыс берушімен және өнімді артынан
пайдаланатын адамдармен тығыз байланыс қамтамасыз етіледі;
• CASE-құралдар және қосымшаны жылдам құратын құралдар пайдаланылады;
• Дайын жүйені қадағалайтын , жобаға өзгертулерді оңай енгізуге
мүмкіндік беретін конфигурацияны басқару құралдары пайдаланылады;
• Соңғы пайдаланушының қажеттіліктерін анықтап және оны іске асыруға
мүмкіндік беретін прототиптар пайдаланылады;
• Жобанының дамуы мен оны тестілеу жобамен қатар жүреді;
• Құрастру жұмыстары шағын және жақсы басқарылатын мамандар командасымен
іске асырылады;
• Жүйені құруды сапалы басқару, нақты жоспарлау және жұмыстың орындалуын
қадағалау қамтамасыз етіледі.

Объектілі-бағытталған көз-қарас(подход)
RAD құралдары қосымша құрудың дәстүрлі құралдар технологиясына
қарағанда мүлде басқа құралдарды іске асыруға мүмкіндік туғызды: ақпараттық
объектілер іс-әрекет жасаушы модельдер ретінде құрылымдалады (прототиптер),
олардың қызмет етуі пайдаланушымен келісіледі, содан кейін құрастырушы
жобаланушы жүйенің жалпы түрін көзде таса қылмастан аяқталған қосымшаларды
қалыпқа келтіруге көше алады.
Мұндай көз-қарасты (подход) пайдалану мүмкіндігі көбінесе объектілі-
бағытталған жобалау принциптерін пайдалану нәтижесі болып табылады. Бұл
принциптер күрделі жүйк құру кезінде туындайтын қиыншылықтық ең ауыр түрін
жеңуге мүмкіндін туғызады — нақты өмір (пәндік облыс) мен имитацияланатын
орта арасындағы өте үлкен айырмашылық.
Объектілі – бағытталған принциптерді пайдалану пәндік облысты
объектілердің үйлесімділігі ретінде – мәліметтер мен осы мәліметтерді өңдеу
әдістерінің болмысы ретінде сипаттауға мүмкіндік туғызады. Әр объект
өзіндік іс-қимылға ие және нақты өмірдің кейбір объектісін модельдейді Осы
тұрғыдан алғанда объектіні толығымен ұстап көруге болады және ол анық іс-
қимылды көрсете алады.
Объектілі көз-қараста(подход) программалық модельдеудің құралы болып
табылатын физикалық немесе абстрактілі жүйенің нақты сипаттамасына аса
басты назар аударылады. Объектілер бүлінбейтін тұтастыққа ие. Осылайша,
объектіні және оның іс-қимылын сипаттайтын қасиеттер өзгертусіз қалады.
Объект тек өзінің жағдайын өзгертіп, басқарылып немесе құрыла алады және
басқа объектілермен қарым-қатынаста бола алады.
Объектілі – бағытталған программалау визуалды программалау құралдары
пайда бола бастағаннан бастап кең қолданысқа түсе бастады, ол құралдар
нақты объктілердің іс-қимылын сипаттайтын деректер мен процедуралардың
бірігуін қамтамасыз етеді. Бұл нақтыға ұқсайтын программалық жүйе құруға
көмегін тигізеді. Өз кезегінде объектілі – бағытталған программалау дайын
объектілердегідей сенімді код құруға мүмкіндік береді.
RAD құралдарының көмегімен қосымша құру кезінде көптеген дайын
объектілер пайдаланылады, ол объектілер қол жететін ашық сақтау қорында
тұрады. Алайда, басқа да жаңа объектілерді де құра беруге болады. Бұған
қарамастан, алдыңғы жасалынған объектілер негізінде де басынан бастап та
құрыла береді.
RAD инструментальдық құралдарының ыңғайлы графикалық интерфейстері бар
және стандартты объектілер негізінде программа кодын жасбастан жай
қосымшаларды форматтай беруге болады. Бұл RAD –тың аса ерекше қасиеті болып
табылады, өйткені бұл пайдаланушы интерфейстерін құру жұмыстарын белгілі
бір дәрежеде қысқартады. Жоғарғы жылдамдық қосымшаның интерфейстік бөлігін
құрастыру кезінде прототиптерді жылдам құруға және соңғы пайдаланушымен
жұмыстарды азайтады.
Осылайша, RAD инструменттері ыңғайлы жүйе құру арқылы құрастырушыларға
нақты бизнес жасауға мүмкіндік туғызады.
Визуалды программалау
Объектілі – бағытталған программалау принциптерін пайдалану қосымшаны
программалаудың жаңа құралдарын құруға мүмкіндік туғызды, ол визуальді
программалау деп аталды.RAD –тың визуальді инструменттері пайдаланушының
күрделі графикалық элементтерін құруға мүмкіндік береді. Осылайша,
құрастырушы шешім негізіне алынған нәрсені бақылай алады.
Визуальді құралдар бірінші кезекте, стандартты интерфейстік
объектілермен операция жүргізеді – деректер базасымен оңай байланыстырып,
мониторда бейнеленетін терезелермен, тізімдермен.Объектілердің басқа тобы
басқарудың стандартты
Элементтерін білдіреді – батыралыр, ауыстырып қосқыштар, жалаушалар,
мәзірлер және т.б. , осылардың көмегімен бейнеленіп тұрған деректерді
басқаруға болады.Объктілер стандартты түрде тілдер құралымен сипатталуы
мүмкін.
Қазіргі уақытты қосымша құрудың визуальді құралдары өте көп, бірақ
олардың барлығы екі топқа бөлінеді - әмбебап және мамандандырылған.
Әмбебап визуальді программалау жүйелерінің ішінен көпке танымалдары -
Borland Delphi және Visual Basic. Әмбебап дейтін себебіміз, олар тек
деректер базасының қосымшаларын құруға негізделген – олардың көмегімен кез
келген типтегі қосымшалар құрыла береді, соның ішінде ақпараттық қосымшалар
да. Сонымен қоса, әмбебап жүйе көмегімен құрылған программалар деректер
базасын басқарудың кез келген жүйесімен байланыста бола алады.
Мамандандырылған құралдар тек деректер базасының қосымшаларын құруға
бағытталған. Және де олар , әдетте , нақты деректер базасының жүйелерімен
байланысқан болады. Мысал ретінде Sybase фирмасының Power Builder жүесін
келтіруге болады(әрине,, предназначенную для работы с СУБД Sybase Anywhere
Server МҰБЖ-мен жұмыс істеуге арналған) және Мicrosoft фирмасының Visual
FoxPro жүйесі.
Прототиптер құру мен пайдаланушы интерфейстерін құру мәселелері
біріккендіктен, программалаушы соңғы пайдаланушымен үзіліссіз байланыста
болу мүмкіндігіне ие, оларқосымша құруды бақылап қана қоймай, сонымен
қатар, осы процеске қатысада алады, өзінің талаптары мен нәтижелерді түзете
де алады. Бұл, сонымен қатар, құрастыру мерзімін қысқартып, маңызды
психологиялық аспектілер болып табылады
RAD – тың визуальді инструменттері АЖ-ні құру этаптарын
жақындачтырады: бастапқы шарттар талдауы, жүйені жоюалау, прототиптерді
құрастыру және қосымшаны нақты түрде қалыпқа клтіру.

Оқиғалы программалау
RAD құралдарымен құрылған қосымша логикасы оқиғалы – бағытталған болып
табылады. Бұл дегеніміз, қосымша құрамына кіретін әрбір объект оқиғаны
генерациялап, басқа объектілермен генерацияланған оқиғаға реакция бере
алады деген сөз. Оқиға мысалы ретінде терезенің жабылуы мен ашылуын,
батырмадағы шертпе, пернетақтаның пернесін басу, тышқанның қимылдауы,
деректер базасындағы деректерді өзгерту және т.б
Құрастырушы қосымша логикасын әрбір оқиғаның өңдеушісін анықтау
негізінде іске асырады — сәйкес оқиға туындағанда объект орындайтын
процедуралар.Мысалы, «батырмадағы шертпе» өңдеушісі диалогтық терезені ашуы
мүмкін. Осылайша, объектіні басқару оқиға көмегімен іске асады.
Деректер базасын басқарумен байланысқан оқиғаны өңдеуші (DELETE,
INSERT, UPDATE), клиенттік немесе серверлік түйінде триггерлер ретінде іске
асуы мүмкін Мұндай өңдеушілер өшіру, қою және жаңарту, сонымен қатар
алғашқы кілттердің автоматты түрде генерациялану операциясын орындау
кезінде деректер базасының сілтеме бүтіндігін қамтамасыз етеді.

RAD Методологиясының шеңберіндегі өмірлік цикл фазалары.
Қосымшаны жылдам құру методологисын пайдалану кезінде АЖ-ның өмірлік
циклі фазадан тұрады:
• Талаптарды жоспарлау мен талдаудан;
• жобалаудан;
• құрудан;
• енгізуден.
Әр қайсысын жекелеп қарастырайық.

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

Жобалау фазасы
Жобалау фазасында CASE- құралдар қажетті инструмент болып табылады,
олар қосымшаның жұмыс істеп тұрған прототиптерін жылдам алу үшін
пайдаланылады. CASE- құралдар көмегімен құрылған прототиптер , пайдаланушы
тарапынан талданады. Осылайша, аталмыш фазада сонымен қатар болашақ
пайдаланушылардың қатысқандығы маңызды.
Процестерді бөлшектеп қарастырғаннан кейін құрастырылатын жүйенің
функционалды элементтерінің саны анықталады. Бұл АЖ – ны бірнеше
подсистемалар қатарына бөлуге мүмкіндік береді, олардың әрқайсысы
құрастырушылардың бір командасымен іске асырылады. CASE- құралдарды
пайдаланумен жоба әртүрлі командалар арасында бөлінеді – функционалды
модель бөлінеді.
Осы фазада қажетті құжаттамалар жинағы аныталады.
Аталмыш фаза нәтижесі болып:
• жүйенің жалпы ақпараттық моделі;
• құрастырушылардың жеке командасымен іске асырылатын жүйенің тұтас және
подсистемалардың функционалдық моделдері;
• автономды құрастырылатын подсистемалар арасындағы CASE- құралдарының
көмегімен нақты анықталған интерфейстер;
• экрандардың, диалогтық терезелердің және есептердің құрылған
прототиптері.

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

Енгізу фазасы
Енгізу фазасы негізінде пайдаланушыларды енгізілген АЖ-мен жұмыс
істеуге оқытуға негізделеді. Құру фазасы созылмалы болғандықтан енгізуге
жоспарлау және дайындық іс-шаралары жүйені жобалау этапында жасалуы керек.

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

Өзін-өзі тексері сұрақтары
1. RAD Методологиясы дегеніміз не?
2. RAD Методологиясының негізгі ерекшеліктері қандай?
3. Объектілі – бағытталғаг подход немесе жобаланған АЖ неге негізделген?
4. Визуалды программалау дегеніміз не?
5. Оқиғалы программалау дегеніміз не?
6. RAD Методологиясының шеңберінде өмірлік циклдың қандай фазалары бар?
7. RAD Методологиясының қандай шектеулері бар?

Әдебиет:
7. Петров В.Н. Информационные системы. СПб.: Питер, 2002.
8. Диго С.М. Проектирование и использование баз данных. - М.:
Финансы и статистика, 1996.
9. Проектирование экономических информационных систем // под ред.
Смирновой Г.Н. - М.: Финансы и статистика, 2001.

11 апта

8 тақырып. CASE - технологиясы

Дәріс жоспары
1. Case – технологиясы.
2. Case – құралдары.

Дәрістің қысқаша конспектісі
1. CASE-технологиясы
Басқарудың автоматтандырылу есебіне автоматтылық жүйелердегі ауысу
шешім қабылдауды да қоса отырып, жүйелік сипаттамада қажеттілік туды.
Бірініш моделдердің бірі бұл бағытта форрестеровтық үлгілер. Соңынан
автоматтандырудың әдістемесі пайда болды (Structures Analysis Design
Technique) SADT .
Үлгілік компоненттер боп ERD, DFD, STD-ды құрайтындар табылады.
CASE-технологиясы МБ құрудағы компьютерлерді қолдануда сипаттаудың
әдістер жиынын көрсетеді. Computer-Aided Software/System (CASE-технология)
– программалық қамтаманың күрделі жүйелерінің қатысуы, өңделуініңғ
жобалаудың, сараптама әдістемесінің болуы. CASE – жүйелік аналитиктерге,
өңдеушілерге және программистерге арналған құрал.
CASE-технологиясы жүйелік анализдің әдістемесіне негізделеді. Жүйе
астында күрделі объектілердің зерртеінің жалпы принциптерін өңдейтін ғылыми
дисциплина түсіндіріледі. Оның негізгі мақсаты - өңдеудің бастапқы
этаптарына назар салу. CASE-технологиясының ішінде жүйелік анализ
программалаудан жобалауды бөлуге арналған. Өңдеуде СASE-технологиясына сай
архитектураның құрылымы және оның кезекті реализациясы ерекшеленеді,
сондықтан жүйелік анализді құрылымды жүйелік анализ немесе жай құрылымды
анализ деп атайды. Маңызды принциптер боп иерархиялық реттіліктің бөлінуі
табылады.
Олар келесі принциптермен толықтырылады.
1. Қалыптастыру принципі.
2. Концептуалды жалпылықтың принципі. Осыдан құрылымдық жүйе анализінің
әдістемесі – барлық үлкен деңгейлері бар иерархиялық құрылымға
детализация арқылы жалпы қараудан зерттеу әдісі.
3. Қарсыласпау пртинципі – элементтердің қатынасуы және жауаптылығы.
4. Мәліметтердің физикалық және логикалық тәуелсіздігінің принципі.
5. Соңғы қолданушының құралсыз кіру принципі.
Бұл технология программалық CASE-құралдардың реализациясы негізіне
жатқызылған.
Сипаттаудың формальды құралы боп ER-диаграмм (ERD)-дың, (DFD)
мәліметтер ағымының диаграммалардың, (STD) қалпының көшу диаграммалары,
процесс спецификациясын сипаттайтын жүйе табылады.
Процестерді сипаттауда екі жағдайы мүмкін.
1. Күрделі процестер.
2. Қарапайым процестер.
А. Күрделі процестер.
ER-диаграммалар. CASE – үлгісінің әдістерінің түрлілігінің бірінішісі
боп Ченнің ER-үлгілері табылады. Бұнда оның түрлілігіне тек – Баркер үлгісі
табылады. Бұнда көпшілік деңгейі байланыстың (мысалы, 1:М), міндеттілік
(–––-) немесе міндеттілік емес (...........)табылады.
DF-диаграммалар. Диаграммалар ену-шығу процестерін бейнелеуге
арналған. SADT әдістемесі алғашында қолданылды, содан DFD схемасында көшті.
Нотацияның негізгі екі түрі бар: Иордан-Демарконың және Гейн-Сарсонның.
Олардың арасындағы ерекшеліктер кең емес, сондықтан Гейна-Сарсонның
нотациясын қолдануға болады. Нотацияда аттармен жаңартылған символдар
қолданылады.
Қойма – жадыда сақталған мәліметтер.
Сыртқы бейне – мәліметтердің қабылдағыш немесе қайнар көзі.
DFD декомпозиция негізінде құрылады, және жоғары деңгей үлгісін
контексті диаграммасы деп атайды. Кез келген нақты жобада ол жалғыз. Бұндай
үлгілер басқару объектісін сипаттайды, басқару бөлігінің бейнесі үшін
жүйелер нақты уақыттың кеңейтілуін қолданады: саналған мағына пунктирлі
сызықпен немесе нүктемен суреттеледі. Басқару ағымдарының негізгі типтері
боп Т-ағым (триггер), А-ағым , E/D-ағым.
Диаграммаларды қолданудың иллюстрациясы үшін алдымен процестің сөздік
сипатын келтіреміз.
1 мысал. Тапсырыстар бойынша тауарларды тарату процесінің сөздік
үлгісі.
Фирмамен алынған заказдар кіріс бақылауына сұрыпталады.
Фирманың тауар номенклатурасына заказ жауап бермесе, ол жоғалады.
Егер заказ қабылданса, онда складтағы тауарлар анықталады.
Егер тауар болса, тапсырушыға төлем есепшотын жазады.
Егер заказ складтағы тауарлармен қамтамасыз етілсе, онда шығарушыға
фирмамен өтініш жіберіледі.
Гейн-Сарсонның контексті диаграммасы ену және шығу ағымдарын көруге
мүмкіндік береді. Детализацияланған диаграмма процестердің әрбіреуі 1-3
жалпы жағдай кезінде, түрде беріледі.
Үлгілеудің мәтіндік құралдары мәліметтер сөздігінен алынды. Бэкус-
Наураның формасында оның фрагменті көрсетіледі.
ST-диаграммасы. Өңдеу процестерінің бейнесі үшін және шешім
реализациясының нәтижесі үшін қолданылады. «Қалып» ұғымы енеді. Қалыптың
өзгеру прцесі кесте көмегімен берілуі мүмкін.
|Текущее состояние|Условие |Действие |Следующее |
| | | |состояние |
|Начальное |Активизируется | | |
|состояние |каждый раз | | |
|ОЖИДАНИЕ |Заказ |Получить заказ |ОБРАБОТKА |
|ОБРАБОТKА |Заказ не отвечает|Аннулировать |ОЖИДАНИЕ |
| |номенклатуре |заказ | |
|ОБРАБОТKА |Заказ обеспечен |Реализация заказа|ОЖИДАНИЕ |
| |складскими | | |
| |запасами | | |
|ОБРАБОТKА |Заказ не |Заявка на товар |ОЖИДАНИЕ |
| |обеспечен | | |
| |складскими | | |
| |запасами | | |

Қарастырылып отырған аппарат масштабты процестер үшін қолданылады.
Б. Қарапайым процестер
Бұл жағдайда жүйелік негіз боп нөмірден, атынан, процесс атынан,
енетін-шығатын тізімдерден тұратын процесс спецификациясы табылады. Процесс
спецификациясы мынадай түрде болады:
ВХОД=ЗАКАЗ
ВЫХОД=ЗАКАЗ АННУЛИРОВАН
ВЫХОД=ЗАКАЗ ПРИНЯТ
СПЕЦ. ПРОЦЕСС 1
ВЫПОЛНИТЬ ПОЛУЧИТЬ ЗАКАЗ
ДО_ТЕХ_ПОР_ПОКА ЗАКАЗ_ОТСОРТИРОВАН
КОНЕЦ_ВЫПОЛНИТЬ
ВЫПОЛНИТЬ установить флаг ЗАКАЗ АННУЛИРОВАН, если он не соответствует
номенклатуре
ВЫПОЛНИТЬ установить флаг ЗАКАЗ АННУЛИРОВАН, если он неверно оформлен
ВЫПОЛНИТЬ установить флаг ЗАКАЗ ПРИНЯТ, если он соответствует
номенклатуре
КОНЕЦ_ВЫПОЛНИТЬ
КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.
Сондай шарттар Flow-формаларын көрсететін визуалды тілдермен
сипатталады.Олар түрлі толтырылуы бар тікбұрышты болады.
Шешім кестелері көбінесе ЕСЛИ ..., ТО... схемасы бойынша беріледі.
Flow-форманың ерекшесі боп Несси-Шнейдердікі табылады.
Жеке көрсетілімдер боп программаның схемалары болады.
Ары қарай күрделі процестер туралы сөз айтылады.
CASE-технологиялары бірнеше қасиеттер бойынша классификацияланады.
1. Software Engineerig (SE) және Information Engineerig (IE) шкаласы
бойынша. Бірінші шкала программалық қамтаманы жобалауға арналған және
белгілі.
2. Үлгіні құру реті бойынша:
а) процедуралы-жобалы (қазіргі жақындау);
б) мәліметтерге жобалы (дәстүрлі жақындау).
3. Мақсатты жүйелер типі бойынша – нақты уақыт жүйесі үшін және ақпараттық
жүйелер үшін.

2. CASE-құралдар
CASE-технологиясы көрсетілгендей, CASE-құралдарымен көрсетіледі. Бұнда
олардың тек мүмкіндіктерін сипаттаймыз.
CASE –құралдар пакетінің 4 негізгі компоненті бар.
1. Ақпаратты орталықтандырлыған құралы.
2. Сақтауға арналған мәліметтерді енгізу құралы.
3. Анализ, жобалаудың және өңдеудің құралы.
4. Шығару құралы.
Для CASE-технологиясы үшін графикалық диаграммалардың төрт негізгі
типтері бар:
1. (DFD) функционалды жобалау;
2. (ERD) мәліметтердің үлгісі;
3. (STD) тәртіп үлгісі;
4. құрылымдық диаграммалар (карталар) – модульдер арасындағы қатынас және
ішінде-модульдік құрылым..
CASE-құралдары функционалды және сатылары бойынша классификациялауға
мүмкін.
1. Сатылары бойынша. Интеграция деңгейін ерекшелейді: көмекші программалар
(tools); (toolkit) пакеттері; инструментальды құралдар (workbench, АРМ).
2. Функционалды қасиеті бойынша.
Анализ және жобалау үшін CASE-аналитик қолданылады, Application
Development Workbench, Easy CASE System Designer.
МБ жобалау ERWin (фирма Oracle) қолданған кезде жеңілдетіледі.
Программалау (кодогенерирование) - DECACE (Borland).
Алып жүру және реинжиниринг (анализ, корректировка, реинжиниринг) -
SuperStructure (Computer Data System).
Жобаны басқару (жоспарлау, бақылау, қарым-қатынас) - Project Workbench
(Applied Business Technology).
Жобалаудың автоматтылығының нақты жүйелерінің бірін қарастырайық.
Oracle ішінде (Cooperative Development Environment - CDE), оған
CASE*Dictionary, CASE*Designer, CASE*Generator кіреді.
CASE*Dictionary – ақпарат қоймасы. CASE*Designer – процесті үлгілеу
құралы және сыртқы интерфейс арқылы жүйедегі мәліметтерді графикалық үлгі
көмегімен. CASE*Designer толығымен интеграцияланған CASE*Dictionary.
CASE*Generator - CASE*Designer ақпарат негізінде автоматты түрде үлгіні
программалық кодты генерациялайды. CASE*Generator DLL-сценарииді
генерациялауы мүмкін.
Oracle7 ашық архитектурамен жобаланған және сондықтан басқа
компаниялар қосымша құралдар құрылды:
Application Development Workbench - KnowledgeWare компаниясы;
Easy CASE System Designer - Evergreen CASE Tools компаниясы;
ERWin/ERX - Logic Works компаниясы;
ADW – анализ, жоспарлау және процестердің және мәліметтердің үлгіленуі
және қосымшаның автоматты генерациялануының құралдар наборы.

Бақылауға арналған сұрақтар
1. Case – технология дегеніміз не?
2. CASE-технологиясымен байланысты қандай принциптер ерекшеленеді?
3. Процестерді сипаттауда қандай жағдайлар мүмкін?Оларға сипаттама беру.
4. Case – құралдар деген не?
5. Case – құралдар құрамына қандай компоненттер кіреді?
6. Case – құралдардың қандай түрлері бар?

Әдебиет:
10. Петров В.Н. Информационные системы. СПб.: Питер, 2002.
11. Диго С.М. Проектирование и использование баз данных. - М.:
Финансы и статистика, 1996.
12. Проектирование экономических информационных систем // под ред.
Смирновой Г.Н. - М.: Финансы и статистика, 2001.

Тема 8. Инструментальное CASE-средство BPwin 4.0

План лекции
1. Назначение программы BPwin 4.0.
2. Интерфейс программы BPwin 4.0.
3. Основы методологии функционального моделирования и построение
моделей IDEF0, IDEF3 и DFD с помощью BPwin 4.0.
4. Построение отчетов на основе информации функциональной модели с
помощью BPwin 4.0.
5. Модель данных.

Краткий конспект лекции
BPwin является средством, которое позволяет облегчить проведение
обследования предприятия, построить функциональные модели и в дальнейшем с
их помощью проанализировать и улучшить бизнес-процессы. Этот инструмент
используют в основном системные аналитики и специалисты по внедрению
информационных систем.

Инструментальные средства BPwin 4.0
Общее описание интерфейса BPwin 4.0
BPwin имеет достаточно простой и интуитивно понятный интерфейс
пользователя, дающий возможность аналитику создавать сложные модели при
минимальных усилиях.

[pic]

Рис. 1.1.1. Интегрированная среда разработки модели BPwin 4.0

При запуске BPwin по умолчанию появляется основная панель
инструментов, палитра инструментов (вид которой зависит от выбранной
нотации) и, в левой части, навигатор модели - Model Explorer (рис. 1.1.1).
Функциональность панели инструментов доступна из основного меню BPwin
(табл. 1.1.1).

Создание новой модели
При создании новой модели возникает диалог, в котором следует указать,
будет ли создана модель заново, или она будет открыта из файла либо из
репозитория ModelMart, внести имя модели и выбрать методологию, в которой
будет построена модель.
Как было указано выше, BPwin поддерживает три методологии -
IDEF0,IDEF3 и DFD, каждая из которых решает свои специфические задачи. В
BPwin возможно построение смешанных моделей, т.е. модель может содержать
одновременно как диаграммы IDEF0, так и диаграммы IDEF3 и DFD. Состав
палитры инструментов изменяется автоматически, когда происходит
переключение с одной нотации, на другую.
После щелчка по кнопке ОК появляется диалог Properties for New Models,
в котором следует внести свойства модели.
Модель в BPwin рассматривается как совокупность работ, каждая из
которых оперирует некоторым набором данных. Работа изображается в виде
прямоугольников, данные - в виде стрелок. Если щелкнуть по любому объекту
модели левой кнопкой мыши, появляется всплывающее контекстное меню, каждый
пункт которого соответствует редактору какого-либо свойства объекта.

Model Explorer - навигатор модели
Инструмент навигации Model Explorer имеет три вкладки - Activities,
Diagrams и Objects. Вкладка Activities (рис. 1.1.5) показывает в виде
раскрывающегося иерархического списка все работы модели. Одновременно могут
быть показаны все модели, открытые в BPwin. Работы с диаграмм IDEF0
показываются зеленым цветом, IDEF3 - желтым и DFD - голубым.
[pic]
Рис. 1.1.5. Вкладка Activities навигатора Model Explorer

Щелчок по работе во вкладке Activity переключает левое окно BPwin на
диаграмму, на которой эта работа размещена. Для редактирования свойств
работы следует щелкнуть по ней правой кнопкой мыши. Появляется контекстное
меню.
Если с помощью вкладки Activities можно перейти на стандартные
диаграммы (контекстную и декомпозиции, см. 1.2), то вторая вкладка Diagrams
(рис. 1.1.6) - служит для перехода на любую диаграмму модели.
[pic]
Рис. 1.1.6. Вкладка Diagrams навигатора Model Explorer

После перехода на вкладку Objects на ней показываются все объекты,
соответствующие выбранной на вкладке Diagrams диаграмме, в том числе
работы, хранилища данных, внешние ссылки, объекты ссылок и перекрестки
(рис. 1.1.7).
[pic]
Рис. 1.1.7. Вкладка Objects навигатора Model Explorer

Создание модели в стандарте IDEF0
Принципы построения модели IDEF0
На начальных этапах создания информационной системы необходимо понять,
как работает организация, которую собираются автоматизировать. Для описания
работы предприятия необходимо построить модель. Такая модель должна быть
адекватна предметной области, следовательно, она должна содержать в себе
знания всех участников бизнес-процессов организации.
Наиболее удобным языком моделирования бизнес-процессов является IDEF0,
предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и
называвшийся первоначально SADT - Structured Analysis and Design Technique.
(Подробно методология SADT излагается в книге Дэвида А. Марка и Клемента
Мак-Гоуэна "Методология структурного анализа и проектирования SADT"
(М.:Метатехнология, 1993.) В начале 70-х годов вооруженные силы США
применили подмножество SADT, касающееся моделирования процессов, для
реализации проектов в рамках программы ICAM (Integrated Computer-Aided
Manufacturing). В дальнейшем это подмножество SADT было принято в качестве
федерального стандарта США под наименованием IDEF0. Подробные спецификации
на стандарты IDEF можно найти на сайте http://www.idef.com.
В IDEF0 система представляется как совокупность взаимодействующих
работ или функций. Такая чисто функциональная ориентация является
принципиальной - функции системы анализируются независимо от объектов,
которыми они оперируют. Это позволяет более четко смоделировать логику и
взаимодействие процессов организации.
Под моделью в IDEF0 понимают описание системы (текстовое и
графическое), которое должно дать ответ на некоторые заранее определенные
вопросы.
Моделируемая система рассматривается как произвольное подмножество
Вселенной. Произвольное потому, что, во-первых, мы сами умозрительно
определяем, будет ли некий объект компонентом системы, или мы будем его
рассматривать как внешнее воздействие, и, во-вторых, оно зависит от точки
зрения на систему. Система имеет границу, которая отделяет ее от остальной
Вселенной. Взаимодействие системы с окружающим миром описывается как вход
(нечто, что перерабатывается системой), выход (результат деятельности
системы), управление (стратегии и процедуры, под управлением которых
производится работа) и механизм (ресурсы, необходимые для проведения
работы). Находясь под управлением, система преобразует входы в выходы,
используя механизмы.
Процесс моделирования какой-либо системы в IDEF0 начинается с
определения контекста, т. е. наиболее абстрактного уровня описания системы
в целом. В контекст входит определение субъекта моделирования, цели и точки
зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно
установить, что входит в систему, а что лежит за ее пределами, другими
словами, мы должны определить, что мы будем в дальнейшем рассматривать как
компоненты системы, а что как внешнее воздействие. На определение субъекта
системы будет существенно влиять позиция, с которой рассматривается
система, и цель моделирования - вопросы, на которые построенная модель
должна дать ответ, другими словами, первоначально необходимо определить
область (Scope) моделирования. Описание области как системы в целом, так и
ее компонентов является основой построения модели. Хотя предполагается, что
в течение моделирования область может корректироваться, она должна быть в
основном сформулирована изначально, поскольку именно область определяет
направление моделирования и когда должна быть закончена модель. При
формулировании области необходимо учитывать два компонента - широту и
глубину. Широта подразумевает определение границ модели - мы определяем,
что будет рассматриваться внутри системы, а что снаружи. Глубина
определяет, на каком уровне детализации модель является завершенной. При
определении глубины системы необходимо не забывать об ограничениях времени
- трудоемкость построения модели растет в геометрической прогрессии от
глубины декомпозиции. После определения границ модели предполагается, что
новые объекты не должны вноситься в моделируемую систему; поскольку все
объекты модели взаимосвязаны, внесение нового объекта может быть не просто
арифметической добавкой, но в состоянии изменить существующие взаимосвязи.
Внесение таких изменений в готовую модель является, как правило, очень
трудоемким процессом (так называемая проблема "плавающей области").

Цель моделирования (Purpose).
Модель не может быть построена без четко сформулированной цели. Цель
должна отвечать на следующие вопросы:
• Почему этот процесс должен быть замоделирован?
• Что должна показывать модель?
• Что может получить читатель?
Формулировка цели позволяет команде аналитиков сфокусировать усилия в
нужном направлении. Примерами формулирования цели могут быть следующие
утверждения: "Идентифицировать и определить текущие проблемы, сделать
возможным анализ потенциальных улучшений", "Идентифицировать роли и
ответственность служащих для написания должностных инструкций", "Описать
функциональность предприятия с целью написания спецификаций информационной
системы" и т. д.

Точка зрения (Viewpoint).
Хотя при построении модели учитываются мнения различных людей, модель
должна строиться с единой точки зрения. Точку зрения можно представить как
взгляд человека, который видит систему в нужном для моделирования аспекте.
Точка зрения должна соответствовать цели моделирования. Очевидно, что
описание работы предприятия с точки зрения финансиста и технолога будет
выглядеть совершенно по-разному, поэтому в течение моделирования важно
оставаться на выбранной точке зрения. Как правило, выбирается точка зрения
человека, ответственного за моделируемую работу в целом. Часто при выборе
точки зрения на модель важно задокументировать дополнительные
альтернативные точки зрения. Для этой цели обычно используют диаграммы FEO
(For Exposition Only), которые будут описаны в дальнейшем.
IDEF0-модель предполагает наличие четко сформулированной цели,
единственного субъекта моделирования и одной точки зрения.

Модели AS-IS и ТО-ВЕ.
Целью построения функциональных моделей обычно является выявление
наиболее слабых и уязвимых мест деятельности организации, анализе
преимуществ новых бизнес-процессов и степени изменения существующей
структуры организации бизнеса. Анализ недостатков и "узких мест" начинают с
построения модели AS-IS (Как есть), т.е. модели существующей организации
работы. Модель AS-IS может строиться на основе изучения документации
(должностных инструкций, положений о предприятии, приказов, отчетов и
т.п.), анкетирования и опроса служащих предприятия (организация опроса
должна быть итерационной и реализовать цикл автор-читатель, см. 1.2.9),
создания фотографии рабочего дня и других источников. Полученная модель AS-
IS служит для выявления неуправляемых работ, работ не обеспеченных
ресурсами, ненужных и неэффективных работ, дублирующихся работ и других
недостатков в организации деятельности предприятия. Исправление
недостатков, перенаправление информационных и материальных потоков приводит
к созданию модели ТО-ВЕ (Как будет) - модели идеальной организации бизнес-
процессов. Как правило, строится несколько моделей ТО-ВЕ, среди которых
определяют наилучший вариант.
Следует указать на распространенную ошибку при создании модели AS-IS -
это создание идеализированной модели. Примером может служить создание
модели на основе знаний руководителя, а не конкретного исполнителя работ.
Руководитель знаком с тем, как предполагается выполнение работы по
руководствам и должностным инструкциям, и часто не знает, как на самом деле
подчиненные выполняют рутинные работы. В результате получается
приукрашенная, искаженная модель, которая несет ложную информацию и которую
невозможно в дальнейшем использовать для анализа. Такая модель называется
SHOULD BE (Как должно бы быть).
Технология проектирования информационных систем подразумевает сначала
создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т. е.
создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель
данных, прототип и затем окончательный вариант информационной системы.
Построение системы на основе модели AS-IS приводит к автоматизации
предприятия по принципу "все оставить как есть, только чтобы компьютеры
стояли", т. е. информационная система автоматизирует несовершенные бизнес-
процессы и дублирует, а не заменяет существующий документооборот. В
результате внедрение и эксплуатация такой системы приводит лишь к
дополнительным издержкам на закупку оборудования, создание программного
обеспечения и сопровождение того и другого.
Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно,
так что переход от начального к конечному состоянию становится неочевидным.
В этом случае необходима третья модель, описывающая процесс перехода от
начального к конечному состоянию системы, поскольку такой переход - это
тоже бизнес-процесс.
Результат описания модели можно получить в отчете Model Report. Диалог
настройки отчета по модели вызывается из пункта меню Tools/Reports/Model
Report. В диалоге настройки следует выбрать необходимые поля, при этом
автоматически отображается очередность вывода информации в отчет (рис.
1.2.2).
[pic]

[pic]
Рис. 1.2.2. Отчет по модели

Диаграммы IDEF0. Основу методологии IDEF0 составляет графический язык
описания бизнес-процессов. Модель в нотации IDEF0 представляет собой
совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая
диаграмма является единицей описания систем и располагается на отдельном
листе.
Модель может содержать четыре типа диаграмм:
• контекстную (в каждой модели может быть только одна контекстная
диаграмма);
• декомпозиции;
• дерева узлов;
• только для экспозиции (FEO).
Контекстная диаграмма является вершиной древовидной структуры диаграмм
и представляет собой самое общее описание системы и ее взаимодействия с
внешней средой. После описания системы в целом проводится разбиение ее на
крупные фрагменты. Этот процесс называется функциональной декомпозицией, а
диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов,
называются диаграммами декомпозиции. После декомпозиции контекстной
диаграммы проводится декомпозиция каждого большого фрагмента системы на
более мелкие и т. д., до достижения нужного уровня подробности описания.
После каждого сеанса декомпозиции проводятся сеансы экспертизы - эксперты
предметной области указывают на соответствие реальных бизнес-процессов
созданным диаграммам. Найденные несоответствия исправляются, и только после
прохождения экспертизы без замечаний можно приступать к следующему сеансу
декомпозиции. Так достигается соответствие модели реальным бизнес-процессам
на любом уровне модели. Синтаксис описания системы ' в целом и каждого ее
фрагмента одинаков во всей модели.
Диаграмма дерева узлов показывает иерархическую зависимость работ, но
не взаимосвязи между работами. Диаграмм деревьев узлов может быть в модели
сколь угодно много, поскольку дерево может быть построено на произвольную
глубину и не обязательно с корня.
Диаграммы для экспозиции (FEO) строятся для иллюстрации отдельных
фрагментов модели, для иллюстрации альтернативной точки зрения либо для
специальных целей.

Работы (Activity)
Работы обозначают поименованные процессы, функции или задачи, которые
происходят в течение определенного времени и имеют распознаваемые
результаты. Работы изображаются в виде прямоугольников. Все работы должны
быть названы и определены. Имя работы должно быть выражено отглагольным
существительным, обозначающим действие (например, "Изготовление детали",
"Прием заказа" и т.д.). Работа "Изготовление детали" может иметь, например,
следующее определение: "Работа относится к полному циклу изготовления
изделия от контроля качества сырья до отгрузки готового упакованного
изделия". При создании новой модели (меню File/New) автоматически создается
контекстная диаграмма с единственной работой, изображающей систему в целом
(рис. 1.2.3).
[pic]
Рис. 1.2.3. Пример контекстной диаграммы

Диаграммы декомпозиции содержат родственные работы, т. е. дочерние
работы, имеющие общую родительскую работу. Для создания диаграммы
декомпозиции следует щелкнуть по кнопке [pic]. Возникает диалог Activity
Box Count (рис. 1.2.5), в котором следует указать нотацию новой диаграммы и
количество работ на ней. Остановимся пока на нотации IDEF0 и щелкнем на ОК.
Появляется диаграмма декомпозиций (рис. 1.2.6). Допустимый интервал числа
работ 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы
с количеством работ более восьми получаются перенасыщенными и плохо
читаются. Для обеспечения наглядности и лучшего понимания моделируемых
процессов рекомендуется использовать от 3 до 6 блоков на одной диаграмме.
[pic]
Рис. 1.2.5. Диалог Activity Box Count
Если оказывается, что количество работ недостаточно, то работу можно
добавить в диаграмму, щелкнув сначала по кнопке на палитре инструментов
[pic], а затем по свободному месту на диаграмме.
Работы на диаграммах декомпозиции обычно располагаются по диагонали от
левого верхнего угла к правому нижнему.
Такой порядок называется порядком доминирования. Согласно этому
принципу расположения в левом верхнем углу располагается самая важная
работа или работа, выполняемая по времени первой. Далее вправо вниз
располагаются менее важные или выполняемые позже работы. Такое расположение
облегчает чтение диаграмм, кроме того, на нем основывается понятие
взаимосвязей работ (см. ниже).
[pic]
Рис. 1.2.6. Пример диаграммы декомпозиции

Каждая из работ на диаграмме декомпозиции может быть, в свою очередь
декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически
слева направо. Номер работы показывается в правом нижнем углу. В левом
верхнем углу изображается небольшая диагональная черта, которая показывает,
что данная работа не была декомпозирована. Так, на рис. 1.2.7 работа
"Сборка изделия" имеет номер 3 и не была еще декомпозирована. Работа
"Контроль качества" (номер 4) имеет нижний уровень декомпозиции.
[pic]
Рис. 1.2.7. Пример декомпозируемых работ

Стрелки (Arrow)
Взаимодействие работ с внешним миром и между собой описывается в виде
стрелок. Стрелки представляют собой некую информацию и именуются
Существительными (например, "Заготовка", "Изделие", "Заказ").
В IDEF0 различают пять типов стрелок:
Вход (Input) - материал или информация, которые используются ил;
преобразуются работой для получения результата (выхода). Допускается, что
работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к
определенной стороне прямоугольника, изображающего работу, или выходит из
нее. Стрелка входа рисуется как входящая в левую грань работы. При описании
технологических процессов (для этого и был придуман IDEF0) не возникает
проблем определения входов. Действительно, "Сырье" на рис. 1.2.3 - это
нечто, что перерабатывается в процессе "Изготовление изделия" для получения
результата. При моделировании информационных систем, когда стрелками
являются не физические объекты, а данные, не все так очевидно. Например,
при "Приеме пациента" карта пациента может быть и на входе и на выходе
между тем качество этих данных меняется. Другими словами, в наша примере
для того, чтобы оправдать свое назначение, стрелки вход и выхода должны
быть точно определены с тем, чтобы указать на то, что данные действительно
были переработаны (например, на выходе "Заполненная карта пациента"). Очень
часто сложно определит! являются ли данные входом или управлением. В этом
случае подсказкой может служить то, перерабатываются/изменяются ли данные в
работ или нет. Если изменяются, то скорее всего это вход, если нет
управление.
Управление (Control) - правила, стратегии, процедуры ил стандарты,
которыми руководствуется работа. "Каждая работа должна иметь хотя бы одну
стрелку управления. Стрелка управления рисуете как входящая в верхнюю грань
работы. На рис. 1.2.3 стрелки "Задание и "Чертеж" - управление для работы
"Изготовление изделия". Управление влияет на работу, но не преобразуется
работой. Если цель работ изменить процедуру или стратегию, то такая
процедура или стратеги будет для работы входом. В случае возникновения
неопределенности статусе стрелки (управление или контроль) рекомендуется
рисовать стрелку управления.
Выход (Output) - материал или информация, которые производятся
работой. Каждая работа должна иметь хотя бы одну стрелку выход. Работа без
результата не имеет смысла и не должна моделироваться Стрелка выхода
рисуется как исходящая из правой грани работы. На рис. 1.2.3 стрелка
"Готовое изделие" является выходом для работ) "Изготовление изделия".
Механизм (Mechanism) - ресурсы, которые выполняют работу, например
персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется
как входящая в нижнюю грань работы. На рис. 1.2.3 стрелка "Персонал
предприятия" является механизмом для работы "Изготовление изделия". По
усмотрению аналитика стрелки механизма могут не изображаться в модели.
Вызов (Call) - специальная стрелка, указывающая на другую модель
работы. Стрелка механизма рисуется как исходящая из нижней грани работы. На
рис. 1.2.3 стрелка "Другая модель работы" является вызовом для работы
"Изготовление изделия". Стрелка вызова используется для указания того, что
некоторая работа выполняется за пределами моделируемой системы. В BPwin
стрелки вызова используются в механизме слияния и разделения моделей.
Граничные стрелки. Стрелки на контекстной диаграмме служат для
описания взаимодействия системы с окружающим миром. Они могут начинаться у
границы диаграммы и заканчиваться у работы, и наоборот. Такие стрелки
называются граничными.
Для внесения граничной стрелки входа надо:
• щелкнуть по кнопке с символом стрелки [pic]в палитре инструментов и
перенести курсор к левой стороне экрана, пока не появится начальная
темная полоска;
• щелкнуть один раз по полоске (откуда выходит стрелка) и еще раз в
левой части работы со стороны входа (где заканчивается стрелка);
• вернуться в палитру инструментов и выбрать опцию редактирования
стрелки [pic];
• щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню
выбрать Name и добавить имя стрелки во вкладке Name диалога Arrow
Properties (рис. 1.2.8).
Стрелки управления, выхода и механизма изображаются аналогично. Для
рисования стрелки выхода, например, следует щелкнуть по кнопке с символом
стрелки в палитре инструментов, щелкнуть в правой часта, работы со стороны
выхода (где начинается стрелка), перенести курсор к правой стороне экрана,
пока не появится начальная штриховая полоска, и щелкнуть один раз по
штриховой полоске.
Имена вновь внесенных стрелок автоматически заносятся в словаре (Arrow
Dictionary).

Нумерация работ и диаграмм
Все работы модели нумеруются. Номер состоит из префикса и числа. Может
быть использован префикс любой длины, но обычно используют префикс А.
Контекстная (корневая) работа дерева имеет номер А0. Работы декомпозиции А0
имеют номера Al, A2, A3 и т. д. Работы декомпозиции нижнего уровня имеют
номер родительской работы и очередной порядковый номер, например работы
декомпозиции A3 будут иметь номера А31, А32, А33, А34 и т. д. Работы
образуют иерархию, где каждая работа может иметь одну родительскую и
несколько дочерних работ, образуя дерево. Такое дерево называют деревом
узлов, а вышеописанную нумерацию - нумерацией по узлам. Имеются
незначительные варианты нумерации, которые можно настроить во вкладке
Presentation диалога Model Properties (меню Edit/Model Properties).
Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют
номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция
контекстной диаграммы - номер А0, остальные диаграммы декомпозиции - номера
по соответствующему узлу (например, Al, A2, А21, А213 и т.д.). BPwin
автоматически поддерживает нумерацию по узлам, т. е. при проведении
декомпозиции создается новая диаграмма и ей автоматически присваивается
соответствующий номер. В результате проведения экспертизы диаграммы могут
уточняться и изменяться, следовательно, могут быть созданы различные версии
одной и той же (с точки зрения ее расположения в дереве узлов) диаграммы
декомпозиции. BPwin позволяет иметь в модели только одну диаграмму
декомпозиции выданном узле. Прежние версии диаграммы можно хранить в виде
бумажной копии либо как FEO-диаграмму. (К сожалению, при создании FEO-
диаграмм отсутствует возможность отката, т. е. можно получить из диаграммы
декомпозиции FEO, но не наоборот.) В любом случае следует отличать
различные версии одной и той же диаграммы. Для этого существует специальный
номер - С-number, который должен присваиваться автором модели вручную. C-
number - это произвольная строка, но рекомендуется придерживаться
стандарта, когда номер состоит из буквенного префикса и порядкового номера,
причем в качестве префикса используются инициалы автора диаграммы, а
порядковый номер отслеживается автором вручную, например МСВ00021.

Вопросы для самоконтроля
1. BPwin программасының негізгі қызметі?
2. BPwin программасы мекеменің қызметінің моделін құрудың қандай
әдістемесін қолдайды?
3. IDEF0 – дегі модель дегеніміз не?
4. AS-IS және ТО-ВЕ модельдерінің негізгі қызметі?
5. IDEF0 нотациясында модель қандай типті диаграммаларды қамтиды?
6. Модельдегі жұмыстар нені білдіреді?
7. Модельдерде қандай стрелкалар болады және олар нені білдіреді?
8. Модельде жұмыстар және стрелкалар қалай нөмірленеді?
9. Түйіндер ағашының және FEO диаграммасын қалай құруға болады және олар
не үшін арналған?
10. Диаграмманың каркасын сипатын жасау.
11. Құндылық анализді (ABC) қалай жүргізу керек және олар не үшін
арналған?
12. BPwin 4.0 көмегімен функционалды модель негізінде есеп беруді
тұрғызуды қалай жүргізу қажет?

Әдебиет:
1. Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0. – М.:
ДИАЛОГ-МИФИ, 2002.

3. Тәжірибелік және зертханалық сабақтар

а) Тәжірибелік сабақтың (семинардың) құрылымы

Тәжірибелік сабақтар №1

Тақырып 1. Кіріспе. Ақпараттық жүйелер

Сабақ мақсаты:
Жүйе, ақпараттық жүйе ұғымдарымен танысу. Әртүрлі белгілеріне қарай АЖ
классификациялау.

Тәжірибелік сабаққа дайындалу сұрақтары
1. Жүйе, ақпараттық жүйе ұғымдарына анықтама беру.
2. АЖ классификациялағанда сақталатын деректердің типіне байланысты
қандай АЖ қарастырылады?
3. АЖ классификациялағанда автоматтандыру дәрежесіне байланысты қандай АЖ
қарастырылады?
4. АЖ классификациялағанда қолданылу саласына байланысты қандай АЖ
қарастырылады
5. АЖ классификациялағанда деректерді өңдеу сипатына байланысты қандай АЖ
қарастырылады?
6. АЖ классификациялағанда басқару деңгейіне байланысты қандай АЖ
қарастырылады?
7. АЖ классификациялағанда масштабқа байланысты қандай АЖ қарастырылады?

8. АЖ классификациялағанда ұйымдастыру тәсіліне байланысты қандай АЖ
қарастырылады?