СППР

МІНІСТЕРСТВО  ОСВІТИ, НАУКИ, МОЛОДІ І СПОРТУ УКРАЇНИ

ДЕРЖАВНИЙ ВИЩИЙ НАВЧАЛЬНИЙ ЗАКЛАД

КИЇВСЬКИЙ  НАЦІОНАЛЬНИЙ  ЕКОНОМІЧНИЙ  УНІВЕРСИТЕТ імені Вадима Гетьмана

 

Кафедра  інформаційних систем в економіці

 

 

 

ЗАТВЕРДЖЕНО:

Протокол № ___ від _____ 20__р.

Вчений секретар

__________________ Ю.І. Кусий

 

 

 

МЕТОДИЧНI  ВКАЗІВКИ ТА ЗАВДАННЯ ДЛЯ ВИКОНАННЯ КУРСОВОГО ПРОЕКТУ З  ДИСЦИПЛІНИ  «СИСТЕМИ ПІДТРИМКИ ПРИЙНЯТТЯ РІШЕНЬ»

 

 для  студентів-бакалаврів спеціальності

6404 “Інтелектуальні системи прийняття рішень”

 

 

        

 

 Затверджено:

                                                                      на засіданні  кафедри

                                                              “Інформаційні системи в економіці"                                                                    

                                                              Протокол №___ від __________р.                                                                                                                                                                        

                                 Завідувач кафедри                                                                     

                                            _________С.В.Устенко

 

 

 

 

 

 

 

 

 

Київ КНЕУ 2012

 

 

 

 

 

 

 

 

1.1.      Мета й завдання курсового проектування

 

Мета курсового  проектування - закрiпити та поглибити теоретичнi знанння з дисципліни,  набути навичок проектування компонентів систем підтримки прийняття рішень (СППР).

Завдання курсового проектування такi:

• закріплення теоретичних знань та  вмiнь застосовувати  їх  при роз’язуваннi конкретних задач проектування компонентів систем підтримки прийняття рішень;
• набуття вмiння вибирати методи проектування СППР i вiдповiднi iнструментальнi засоби;
• закрiплення навичок роботи iз сучасними СППР, засобами штучного інтелекту та інтелектуального аналізу даних, OLAP-системами, CASE-засобами проектування баз і сховищ даних.

 

1.2.      Органiзацiя курсового проектування

 

Тема курсового проекту вибирається з  перелiку, який наведено в  додатку 4 чи може визначатися за мiсцем роботи чи майбутньої практики студента, але обов’язково потрібно затвердження  керiвника курсу.

Вибрану тему студент має оформити у виглядi заяви  й  подати  на кафедру не пiзнiше як через три тижнi пiсля початку читання лекцiй з  даної дисциплiни.

Пiсля затвердження теми на кафедрi керiвник видає студентовi завдання на курсове проектування. Курсовий проект потрiбно подати на кафедру в термiн,  зазначений у завданнi. Якщо проект зданий несвоєчасно, це вважається порушенням навчального плану.

 

1.3.      Структура та оформлення  курсового  проекту.

 

Структура курсового проекту в багатьох випадках залежить від специфіки розроблюваної теми, використовуваного комплексу технічних засобів, методів розв’язання задач тощо.

Рекомендована наступна структура курсового проекту:

Титульна сторiнка

Анотацiя

Реферат

Змiст

Вступ

Роздiл 1. Дослiдження  предметної  областi

Розділ 2. Визначення ситуацій і задач прийняття рішень

Розділ 3. Проектування бази знань (моделей, сховища даних, OLAP- системи, тощо – в залежності від обраної тематики курсового проекту)

Розділ 4. Проектування користвацького інтерфейсу

Висновки

Список лiтератури

Додатки

 

Титульна сторiнка(титул) оформляється вiдповiдно ГОСТ 2.105-79 ЕСКД (додаток 5).

Анотацiя. У нiй стисло висвiтлюється головна  iдея курсового проекту, розкривається його основний змiст, зазначаються застосовуванi методи та обгрунтовується новизна матерiалу. Форма викладу ствердна,  наприклад: "у проектi запропоновано...",  "наведено..."," показано..." i тощо.

Оптимальний обсяг анотацї - 400 знакiв.

Реферат. Структура реферату визначається ГОСТ 7.9-77 "Система інформацiйно-бiблiографiчної  документацiї."  Загальнi  вимоги та правила оформлення регламентуються ГОСТ 7.32-81 "Звiт про науково-дослiдну роботу".

Реферат має мiстити таку iнформацiю:

вiдомостi про  обсяг  проекту  (загальна  кiлькiсть сторiнок тексту, кiлькiсть iлюстрацiй, таблиць, назв у списку використаних лiтературних джерел);

перелiк ключових слiв (записаних у називному вiдмiнку в  один рядок через кому), який має вiдбивати змiст реферованого проекту;

об’єкт  дослiдження;

апаратура  використана при дослідженні;

результат досягнуті  в процесi науково-дослiдної роботи, їх новизна та ступiнь упровадження;

рекомендацiї щодо практичного застосування здобутих  результатiв iз зазначенням ефективностi,  сфери використання,  основних конструкторських i технiко-економiчних характеристик.

Оптимальний об’єм реферату - 800-1000 знакiв.

 

Змiст

Являє собою перелiк  назв усiх роздiлiв та параграфів iз зазначенням сторiнок, з яких починаються роздiли чи параграфи проекту.

 

Вступ

Розкриває мету курсового проекту,  обгрунтовує потребу розроблення бази моделей, (знань, правил, сховище даних) для підтримки прийняття рішень дослiджуваної задачi чи комплексу задач, висвітлює суть проблеми.

 

Роздiл 1. Дослiдження  предметної  областi

В цьому розділі необхідно описати характеристику задачі, показати її роль і місце в діяльності підприємства чи галузі економіки.

При описі проблемної області необхідно:

вказати призначення, описати техніко-економічну сутність задачі, для якої буде проектуватись база моделей, (знань, даних, правил, сховище даних), і обгрунтування необхідності її розв'язання;

привести перелік об'єктів, при управлінні якими розв'язується задача;

визначити перелік задач, для яких необхідна підтримка прийняття рішень, визначити, чи розв’язуються ситуації з повторюваними, чи неповторюваними рішеннями;

описати призначення і використання вхідної інформації, описати джерела її надходження;

привести періодичність розв'язання і термін видачі результатів;

вказати умови, за яких припиняється автоматизоване  розв'язання задачі.

За необхідності, у цьому розділі слід описати зв'язки даної задачі з іншими задачами і навести схему інформаційної моделі задачі.

Якщо рішення приймаються на основі бази даних (БД), визначити перелік масивів БД та показати їх на інформаційній моделі задачі.

В цьому розділі також необхідно визначити та обґрунтувати методи, на основі яких проектується СППР (відповідно до чотирьох "шкіл" створення СППР: аналіз рішеннь, числення рішень, дослідження рішень, процес впровадження). Відповідно  до обраного методу, необхідно запропонувати порядок роботи користувача з системою (в системі???), описати розподіл дій між персоналом і технічними засобами при різних ситуаціях розв'язання задачі. (Для детального ознайомлення  із "школами" створення СППР пропонується п.7.3., стор. 319-329 навчального посібника) [1].

Орієнтовний обсяг першого розділу – 5-10 сторінок.

 

Розділ 2. Визначення ситуацій і задач прийняття рішень

 

У цьому розділі необхідно описати конкретні ситуації і задачі, що вимагають прийняття рішень і відповідні умови щодо їх підтримки. Орієнтовний обсяг другого розділу – 5-10 сторінок.

Для цього визначається перелік ситуацій і задач прийняття рішень, які мають бути реалізовані в СППР.

Описуючи проблемну ситуацію, необхідно навести її характеристику, визначивши ступінь її стуктурованості; ступінь новизни проблеми для ОПР; рівень повноти знань ОПР щодо структури проблеми; ступінь неточності вхідних даних, варіантів рішень, імовірності настання наслідків; рівень часового горизонту.

Наприклад, надати перелік рішень за сферою організаційного управління (стратегічні, адміністративні, оперативні) або в умовах невизначеності, ризику, нечіткої інформації, тощо.

Ситуації, пов’язані з прийняттям рішень, можна представити у вигляді таблиці 1 (стор. 94-97, 300-305 навчального посібника [1].

Таблиця 1

Перелік ситуацій і задач прийняття рішень

Назва ситуації (задачі ПР)	Тип ситуації	Вид ситуації	Тип проблеми організаційного управління	Характерні особливості	Категорія творців рішень

 

Для заповнення таблиці рекомендується скористатись додатками 1,2,3.

В колонці "Назва ситуації (задачі ПР)" вказують конкретну ситуацію або задачу прийняття рішення.

Тип ситуації — вказують, до якого типу відноситься ситуація: закритих, відкритих чи кризових задач.

Вид ситуації — вказують, до якого типу відноситься ситуація: детерміновані, за умов ризику, за умови невизначеності, умови нечітких цілей, посилених відкритих рішень.

Тип проблеми організаційного управління — визначають, чи це структурована, слобоструктурована чи неструктурована проблема.

Характерні особливості — описують ступінь визначеності цілей, ступінь визначеності вхідної та вихідної інформації, тип і ступінь часових обмежень, тощо.

Категорія творців рішень — вказують, яка категорія працівників є учасником процесу прийняття рішень (керівники, фахівці, технічні працівники, тощо)

Наприклад

Назва ситуації (задачі ПР)	Тип ситуації	Вид ситуації	Тип проблеми організаційного управління	Характерні особливості	Категорія творців рішень
Визначення оптимальної кількості випуску продукції на рік	відкрита задача	ситуація за умов ризику	слабоструктурована	Добре визначена ціль, відома вхідна інформація, є елементи ризику і невизначеності	керівник відділу виробництва
Вибір стратегії збуту продукції	відкрита задача	ситуація за умов невизначеності	неструктурована	невизначеність наслідків прийняття рішення	заступник генерального директова з питань маркетингу
Вибір дій у зв’язку з розривом контркту постачальника на поставку сировини	відкрита задача	кризова	неструктурована	нечіткі цілі, жорсткі часові обмеження	генеральний директор, заступники з економічного блоку питань

 

В цьому розділі слід охарактеризувати особу або групу осіб, які беруть участь у прийнятті рішень. Можна охарактеризувати творців рішень, виходячи з того, як вони мають використовувати СППР.

Необхідно визначити вимоги щодо подачі та використання інформації для  прийняття рішень.

Після аналізу проблемних ситуацій і задач прийняття рішень повинні бути представлені пропозиції щодо вибору методів підтримки прийняття рішень (п.7.1.1, стор 295-300 навчального посібника) [1] та виду (структури) СППР (розділ 6 навчального посібника) [1]. Наприклад, можна вказати, що для підтримки перелічених рішень пропонується розробити систему на основі бази знань (даних, моделей, нейронних мереж, сховища даних, OLAP- системи, тощо)

 

Розділ 3. Проектування бази знань (моделей, сховища даних, OLAP- системи, тощо – в залежності від обраної тематики курсового проекту)

 

В рамках курсового проекту  цей розділ може бути реалізований одним із способів:

     1) як проект бази моделей для СППР;

     2) як проект бази знань (бази правил) для СППР

     3) як проект сховища даних для СППР та моделей аналізу даних.

Реалізацію запропонованого проектного рішення необхідно представити в контрольному прикладі, який може бути поданий як в даному розділі по тексту, так і в додатках.

     Орієнтовний обсяг цього розділу – 10-15 сторінок.

 

1) Вимоги до проектування бази моделей в СППР

При проектуванні баз моделей слід враховувати, що СППР може містити різні типи моделей. В зальному випадку база моделей СППР може включати оптимізаційні та  неоптимізаційні, аналітичні, імітаційні, евристичні, алгоритмічні та інші моделі.

При розробленні бази моделей необхідно вказати і обґрунтувати тип запропонованих моделей підтримки рішень.

Базу моделей необхідно описати у вигляді математичних формул, економіко-математичних моделей чи функцій.

Реалізацію запропонованих моделей можна представити за допомогою обраної мови програмування або обраного середовища системи керування базою моделей. Наприклад, MatLab. Можна скористатись середовищем СППР, орієнтованим на моделі (СППР Ithink, СППР Analitica, тощо)

 

2) Вимоги до проектування бази знань в СППР

При розробребленні бази знань або правил необхідно вказати і обґрунтувати тип моделі опису знань або правил та мову подання знань.     

Знання в базі знань подаються в певному вигляді, тобто в певних інформаційних одиницях знань і зв’язках між ними. За розроблення специфічних моделей подання знань намагаються дотримуватися таких вимог:

1. подання знань має бути однорідним (одноманітним). Однорідна презентація знань приводить до спрощення механізму управління логічними висновками і управління знаннями взагалі;
2. подання знань має бути зрозумілим експертам і користувачам системи. В іншому разі утрудняються набуття знань та їх оцінювання.

Відомі чотири основні типи моделей описання знань у базах знань:

• логічні, основою яких є формальна модель, тобто формальний опис деякою логічною мовою структури об’єкта;
• продукційні, що ґрунтуються на використанні правил (продукцій);
• фреймові, тобто форми подання знань, в основу яких покладені фрейми, кожен з яких складається зі слотів. Фреймова форма подання знань визначається рекурсивно;
• моделі у вигляді семантичної мережі, тобто мережі, у вершинах якої містяться інформаційні одиниці, а дуги характеризують відношення і зв’язки між ними.

Мова, що використовується для розроблення систем на основі цих моделей, називається мовою подання знань.

Відомі такі мови подання знань:

• логічна мова подання знань, в основу якої покладено числення предикатів першого порядку. Виразами цієї мови є синтаксично правильні формули даного числення, через які виражаються всі записані в системі декларативні й процедурні знання;
• продукційна мова, основними одиницями якої є продукції (правила);
• фреймова мова, у котрій для подання і маніпулювання знаннями використовується фреймова модель подання знань. На даний час найвідомішими фреймовими мовами є FRL (Frame Representa­tion Language) і KRL (Knowlenge Representation Language).

Далі повинна бути представлена модель бази знань або правил.

 

3) Вимоги до проектування сховища даних в СППР

В цьому розділі необхідно спроектувати сховище даних та описами основні процедури аналізу даних на основі сховища  чи OLAP-моделі.

Основні процедури аналізу даних необхідно описати у вигляді математичних формул, економіко-математичних моделей, функцій чи моделей інтелектуального аналізу даних.

 

При проектуванні сховища даних обгрунтовується  мотивація (мета) його створення та виконується вибір денормалізованої чи нормалізованої моделі його побудови („сніжинка” чи „зірка”).  Проектування сховища даних виконується на основі вивчення аналітичних бізнес-запитів згідно методики багатовимірного моделювання (dimensional methodology).   Для автоматизації проектування сховищ даних можуть бути використані CASE-засоби зокрема пакет Erwin. Необхідно запроектувати таблиці фактів і таблиці вимірювань та  об’єднати їх відповідними зв’язками, надавши схему моделі СД.  Вибрати архітектуру побудови сховища та надати її опис.

В розділі необхідно обгрунтувати вибір СКБД для підтримки і роботи зі сховищем даних.  При цьому  враховуються такі є фактори, як при виборі СКБД для БД, а також ряд таких специфічних факторів як: можливість паралельного оброблення складних аналітичних запитів, наявність вбудованих OLAP–засобів, наявність засобів для фільтрації, очищення, перетворення та завантаження даних в сховище з баз даних OLTP-систем, наявність засобів візуалізації аналітичних даних, підтримка кіосків (вітрин) даних, можливості розширення і підтримки великих корпоративних сховищ,  механізм оптимізації запитів.  

Можна надати опис механізму доступу  до даних систем-джерел.  Розробити та описати  технологію завантаження даних у сховище даних, описавши  процедури фільтрації, очищення, перетворення  типів даних та приведення їх до єдиного формату та процедури узагальнення (агрегування) даних. 

Запроектоване сховище даних завантажується даними контрольного прикладу і роздруковується. Контрольний приклад повинен бути розроблений таким чином, щоб дозволив формування основних OLAP-запитів чи вирішення задач  Data Mining.  Зміст  таблиць фактів та вимірів, завантажених  контрольним прикладом роздруковується надається в додатках.  

 

Розділ 4. Проектування користвацького інтерфейсу

 

Орієнтовний обсяг цього розділу – 3-5 сторінок. (Для детального ознайомлення  з питаннями розроблення користвацького інтерфейсу пропонується п.5.2, стор. 179-189 навчального посібника) [1].

В цьому розділі необхідно запропонувати і обґрунтувати механізм організації взаємодії користвачів із СППР та описати основні вимоги до користувацького інтерфейсу системи виходячи із трьох основних аспектів: мова дій, мова відображення і база знань.

.

Існують наступні три механізми:

•  формальний діалог   -  ґрунтується на «кмітливості» комп’ютера з урахуванням його структури як віртуальної машини;
•     природна мова   -  відбиває особливості мислення конкретної людини, у результаті чого мова реалізується на лінгвістичній основі подання знань, комунікації і логічного висновку;
•    графічний діалог   -  відтворює задану предметну галузь, зок­рема, із застосуванням піктограм (графічних зображень об’єктів чи дій). Останні мають деякий сенс для користувача, а в комп’ютері — це просто розміщення маркера.

 

Враховуючи основні аспекти проектування користвацького інтерфейсу, необхідно:.

Мова дій. Необхідно описати, що може робити користувач під час спілкування з СППР. Необхідно надати розширений перелік команд і функцій, які може виконувати користвач. Описати пристрої, якими може оперувати користувач (наприклад, клавіатура, сенсорна панель, команди звичайної мови, тощо).

  Мова відображення. Необхідно описати, що бачить користувач під час роботи з системою. Також описати варіанти вибору мови відображення: принтери, екрани, графічні засоби, кольорі, сигнали, звукові виводи, тощо.

База знань. Необхідно описати, що повинен знати користувач, щоб вести діалог із системою. База знань для користувача може бути надрукована у вигляді посібника або бути доступною як сукупність діалогових команд підказування (із застосуванням навчальних засобів) чи у вигляді деякої комбінації перелічених компонентів.

 

При описі користувацького інтерфейсу необхідно запропонувати його стиль, проекти екрану, послідовність користвача з програмним забезпеченням, використання кольорів, ліній і графіків, піктограм і символів, альтернативних пристроїв введення-виведення інформації.

 

Висновки

У висновках приводиться аналiз результатiв  проектування та пропозиції щодо  подальшого їх практичного впровадження та використання.

 

Графiчний матерiал виконується на окремих сторiнках, якi входять до загальної нумерацiї сторiнок роботи. Малюнки й таблицi виконуються згiдно з ГОСТ 24.301-80 (???).

Перед текстом роботи має бути титульна сторiнка  (дод.  5), яка  виконується  згiдно з ГОСТ 2.105-79.  Наприкiнцi тексту слiд навести список лiтератури,  яка використовувалась  при  виконаннi проекту. Якщо  в  курсовому  проектi  використовувались цитати чи якийсь цифровий матерiал,  запозичений з лiтературних джерел,  то потрiбно вiдповiднi бiблiографiчнi посилання (джерело, сторiнка).

В додатку   до  проекту  в залежності від обраної тематики можуть бути наведені  екранні форми  первинних та вихiдних повiдомлень, результати розрахунків контрольного прикладу, лістинги програмних кодів, контрольний приклад бази моделей (знань), структури файлiв сховища даних, описанi  в термiнах МОД вибраної СКБД, представлення основних запитів на мові SQL, тощо.

 

Умовнi й графiчнi позначення,  термiнологiя та  визначення  мають вiдповiдати  стандартам. Курсовий  проект потрiбно переплести. Студент, пiдписавши проект, здає його на перевiрку керiвнику в термiн, затверджений на кафедрi. Керiвник проекту, перевiривши роботу, може допустити її до захисту чи вiддати студенту  на  доопрацювання за окремими зауваженнями.

 

1.5. Захист  курсового проекту. Допущений до захисту проект пiдписується керiвником i захищається на  комiсiї,  до якої входять два-три викладачi кафедри (з урахуванням  керiвника проекту).

Студент робить коротку доповiдь (5-10 хв.),  в якiй викладає сутнiсть проектних розроблень, наголошуючи при цьому на розроблених ним пропозицiях, а потiм вiдповiдає на запитання.

За результами захисту виставляється оцiнка, яка заноситься до залiкової книжки та у вiдомiсть з пiдписами членiв комiсiї.

 

 

 

Додаток 1

 

КЛАСИФІКАЦІЯ СИТУАЦІЙ, ПОВ’ЯЗАНИХ ІЗ ПРИЙНЯТТЯМ РІШЕНЬ

Тип ситуацій	Вид ситуації	Характерна особливість	Приклад
Ситуації закритих задач (структуровані проблеми)	детерміновані ситуації	1) добре визначені цілі; 2) цілковита доступність інформації; 3) детерміновані фактори	моделі лінійного програмування
	ситуації за умов ризику	1) добре визначені цілі; 2) необхідна інформація вільно доступна; 3) змінні і післядії стохастичні	задачі керування запасами; побудова черг
Ситуації відкритих задач	прийняття рішень за умов невизначеності (слабо структуровані проблеми)	1) добре визначені цілі; 2) невизначеність вхідноїінформації (неповна інформація)	аналіз капітальних вкладень
	прийняття рішень за умов нечітких цілей (неструктуровані проблеми)	1) нечіткі цілі; 2) невизначеність вхідної інформації; 3) обидві форми невизначеності	диверсифікація; організаційні розробки
Кризові ситуації	посилені відкриті рішення (неструк-туровані проблеми)	1) нечіткі цілі; 2) невизначеність вхідної інформації; 3) невизначеність післядій; 4) обидві форми невизначеності; 5) жорсткі часові обмеження	боротьба з терором

 

Додаток 2

КЛАСИФІКАЦІЯ ТВОРЦІВ РІШЕНЬ

Номер групи	Назва групи	Клас завдань, що розв’язуються
1	керівники (директори, головні адміністратори та ін.)	неструктуровані, меншою мірою — слабоструктуровані
2	фахівці (керівники функціональних служб, головні спеціалісти)	слабоструктуровані
3	технічні працівники (секретарі, касири, експерти, клерки та ін.)	структуровані

 

Додаток 3

КЛАСИФІКАЦІЯ ПРОБЛЕМ ОРГАНІЗАЦІЙНОГО УПРАВЛІННЯ

Клас	Визначальна особливість	Методи розроблення рішень	Галузі використання
Перший	цілком структуровані (формалізовані) процедури розроблення рішень	ті, що ґрунтуються на стандартизації і програмуванні	бухгалтерський облік; підготовка виробництва; складський облік та ін.
Другий	слабоструктуровані процедури розроблення рішень	умови неповної інформації, теорії нечітких (розмитих) множин	поточне планування; оперативно-календарне планування; управління запасами
Третій	неструктуровані процедури розроблення рішень	творчий підхід на основі інформованості, кваліфікації, інтуїції тощо	прогнозування; перспективне планування

 

 

Додаток 4

ПРИКЛАДИ ТЕМ КУРСОВИХ ПРОЕКТIВ

1. Проектування бази моделей для підтримки прийняття рішень при управлінні інвестиційним портфелем.
2. Проектування бази знань для підтримки прийняття рішень при управлінні інвестиційним портфелем.
3. Проектування сховища даних  та моделей аналізу даних  для підтримки прийняття рішень при управлінні інвестиційним портфелем.
4. Проектування бази моделей для підтримки прийняття рішень при управлінні електронним магазином.
5. Проектування бази знань для підтримки прийняття рішень при управлінні електронним магазином.
6. Проектування сховища даних  та моделей аналізу даних  для підтримки прийняття рішень при управлінні електронним магазином.
7. Проектування бази моделей для підтримки прийняття рішень при  виборі постачальників сировини для виробничого підприємства.
8. Проектування бази знань для підтримки прийняття рішень при управлінні при  виборі постачальників сировини для виробничого підприємства.
9. Проектування сховища даних  та моделей аналізу даних  для підтримки прийняття рішень  при  виборі постачальників сировини для виробничого підприємства.
10. Проектування бази моделей для підтримки прийняття рішень при виборі банку для отримання кредиту юридичними особами.
11. Проектування бази знань для підтримки прийняття рішень при виборі банку для отримання кредиту юридичними особами.
12. Проектування сховища даних  та моделей аналізу даних  для підтримки прийняття рішень при виборі банку для отримання кредиту юридичними особами.
13. Проектування бази моделей для підтримки прийняття рішень при виборі позичальника комерційного банку.
14. Проектування бази знань для підтримки прийняття рішень при виборі позичальника комерційного банку.
15. Проектування сховища даних  та моделей аналізу даних  для підтримки прийняття рішень при виборі позичальника комерційного банку.
16. Проектування бази моделей для підтримки прийняття рішень при виборі каналів збуту нової продукції  виробничим підприємством.
17. Проектування бази знань для підтримки прийняття рішень при виборі каналів збуту нової продукції  виробничим підприємством.
18. Проектування сховища даних  та моделей аналізу даних  для підтримки прийняття рішень при виборі каналів збуту нової продукції  виробничим підприємством.
19. Проектування бази моделей для підтримки прийняття рішень при  виборі фінансових інструментів на фондовому ринку.
20. Проектування бази знань для підтримки прийняття рішень при виборі фінансових інструментів на фондовому ринку.
21. Проектування сховища даних  та моделей аналізу даних  для підтримки прийняття рішень при  виборі фінансових інструментів на фондовому ринку.
22. Проектування бази моделей для підтримки прийняття рішень при виборі  місця розташування філії комерційного банку.
23. Проектування бази знань для підтримки прийняття рішень при виборі  місця розташування філії комерційного банку.
24. Проектування сховища даних  та моделей аналізу даних  для підтримки прийняття рішень при виборі  місця розташування філії комерційного банку.
25. Проектування бази моделей для підтримки прийняття рішень при виборі джерел фінансування нового інвестиційного проекту.
26. Проектування бази знань для підтримки прийняття рішень при виборі  джерел фінансування нового інвестиційного проекту.
27. Проектування сховища даних  та моделей аналізу даних  для підтримки прийняття рішень при виборі  джерел фінансування нового інвестиційного проекту.
28. Проектування бази моделей для підтримки прийняття рішень при підборі  персоналу для підприємства/банку.
29. Проектування бази знань для підтримки прийняття рішень при підборі  персоналу для підприємства/банку.
30. Проектування сховища даних  та моделей аналізу даних  для підтримки прийняття рішень при підборі  персоналу для підприємства/банку.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Додаток 5

МІНІСТЕРСТВО  ОСВІТИ, НАУКИ, МОЛОДІ І СПОРТУ УКРАЇНИ

ДЕРЖАВНИЙ ВИЩИЙ НАВЧАЛЬНИЙ ЗАКЛАД

КИЇВСЬКИЙ  НАЦІОНАЛЬНИЙ  ЕКОНОМІЧНИЙ  УНІВЕРСИТЕТ імені Вадима Гетьмана

 

Кафедра  інформаційних систем в економіці

 

 

 

 

 

КУРСОВИЙ ПРОЕКТ

 

 

з дисциплiни "Системи підтримки  прийняття рішень"

_____________________________________

(назва теми курсового  проекту)

 

 

 

 

 

Студент _______________ група ____ курс_______

 

Керiвник проекту______________________________

 

 

 

КИЇВ

КНЕУ 2012  р.

 

 

 

 

 

 

   Додаток 6

Рекомендована література

    1) Ситник В.Ф. Системи підтримки прийняття рішень: Навч. посібник.. -- К: КНЕУ, 2004. – 624с.

     2) Ситник В.Ф., Гордієнко І.В.  Системи підтримки прийняття рішень: Навч.-метод. посіб. для самост. вивч. дисц. -- К: КНЕУ, 2004. – 427 с.

     3) Ситник В.Ф., Гужва В.М. та інші. Системи підтримки прийняття рішень. – К.: Техніка, 1995. – 162 с.

     4) Компьютеризация информационных процессов на промышленных предприятиях/ В.Ф.Сытник, Х.Срока, Н.В.Еремина, и др. - К.: Техніка; Катовице: Экономическая академия им. Карола Адамецкого, 1991. - 216 с.

      5)  Sauter V.  Decision Support Systems. -- Printed in United States of America, 1997. --  408 . (http://www.umsl.edu/~sauter/DSS/book.html)

     6)  Hopple G.W. The state of the decision support systems. Printed in USA, 1988. – 246 p.