Розділ 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