Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Методичні вказівки СППР.DOC
Скачиваний:
33
Добавлен:
04.03.2016
Размер:
851.97 Кб
Скачать

Функції та підфункції процесу прийняття рішень, які потребують підтримки

Функції

Підфункції

Аналіз ситуації: пошук інформації

  1. Генерація та ідентифікація альтернитивних джерел інформації

  2. Оцінка альтернитивних джерел інформації

  3. Вибір поміж альтернативними джерелами інформації

Аналіз ситуації: пояснення

  1. Генерація альтернативних пояснень

  2. Оцінка альтернативних пояснень

  3. Вибір поміж альтернативними поясненнями

Планування і прийняття рішень

  1. Генерація альтернативних напрямківт дій

  2. Оцінка альтернативних напрямків дій

  3. Вибір між альтернативними напрямками дій

Виконання і контроль

  1. План реалізації

  2. Спостереження наслідків дій

  3. Оцінка відхилень від сподіваного (очікуваного) результату

  4. Вибір (прийняти чи відхилити)

Таблиця 6.6.

Узагальнена матриця методів/ситуацій

Ситуації

Методи

Закриті

Відкриті

Кризові

Невизначеність вхідної інформації

Невизначеність наслідків дій

Обидві невизначеності

Якісні

Н

В

С

В

В

Суб’єктивний якісні

Н

В

С

С

В

Структуровані якісні

С

В

В

В

В

Кількісні

В

С

С

С

С

Часові ряди

В

Н

Н

Н

С

Стохастичні (імовірні)

С

В

В

В

В

Статистичні (дослідження операцій)

В

Н

Н

Н

С

Причинні моделі

В

В*

В*

В*

В*

Гібридні

С

В*

В*

В*

В*

На основі інформатики

С

С

С

С

С

Інформаційні системи

В

С

С

С

С

Штучний інтелект

Н

В*

В*

В*

В*

6.3. Література до теми

  1. Hopple, Gerald W. The state of art in desion support System // rinted in USA. – 1988. – P. 101-193.

Тема 7. Макетування сппр

7.1. Зміст теми

адаптивне проектування і впровадження СППР. Макетування як процес створення зразка складного інтерактивного програмноо продукту. Основні цілі макетування СППР. Стратегій макетування СППР. Загальна схема дев’ятиетапної моделі макетування СППР. Аналіз вимог до задач СППР: ідентифікація задач; оцінка задач. Методи ідентифікації задач. Базові емпіричні дослідні стратегії аналізу вимог до СППР. Методи аналізу вимог: модель “довіра-позиції”, “модель взаємодії”, комунікаційна модель, регресивне моделювання, метод аналізу протоколу. Моделювання СППР. Форми зображення моделей СППР. Методи моделювання СППР. Вибір методів для СППР. Класи методів. Матриця співставлення вимог і методів. Вибір (проектування) програмного забезпечення. Найважливіші компоненти ефективного програмного забезпечення для СППР. Вісім типів інтерактивного діалогу в СППР. Вибір (компонування) апаратних засобів СППР. Базові типи засобів відображення. Перенос (передача) системи.

7.2. Пояснення до теми

7.2.1. Суть і стратегія макетування сппр

Виникнення нових технічних і програмних засобів, які дозволяють “індустрілізувати” технологію побудування нових систем, обумовила появу нової концепції проектування СППР – адаптивного проектування, згідно якої створення кінцевого продукту выдбудовується за рахунок інтерактивного процесу, в якому користувач, розробник і система багатократно взаємодіють один з одним.

З точки зору адаптивного проектування СППР основні проблеми можна охопити таким чином:

  • розуміння динаміки зв’язків між користувачем, проектувальником і системою;

  • аналіз зв’язків між проблемами, задачами, поведінкою користувача, а також проектуванням системи;

  • інтеракція організаційних, психологічних та інструментальних аспектів в процесі проектування СППР.

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

Необхідність прототипування (від англ. рrototyping), як процесу створення спрощеної версії (попереднього варіанту) системи, обгрунтовується тим, що інтерактивні системи типу СППР неможливо розробити легко, швидко і без вводу інформації протягом життєвого циклу перспективними кінцевими користувачами. Такі системи вимагають участі користувача для отримання необхідної інформації швидше і з мінімльними втратами. Життєвим циклом СППР називається сукупність взаємоув’язаних процесів створення і послідовних змін стану СППР від формування вихідних вимог до закінчення експлуатації системи.

Моживими цілями макетуваня СППР є:

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

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

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

Початковим етапом процесу інженерного макетування СППР є ідентифікація базових потреб. На основі вибраного прототипу і потреб користуачів розроблювач зосереджує увагу на шидкій побудові робочої моделі СППР, з тим, щоб викликати і підтримувати активну зацікавленість користувачів. Далі йде демонстрація по запиту удосконалень і розширень, коли користувач отримує можливість здійснити попередню “прогулянку” системи, яка проектується. Заключною фразою макетування є цілий ряд операцій і переробок для того\ щоб цільова придатність та інші зовнішні характеристики СППР були цілком схвалені колективами розроблювачів і користувачів.

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