лучшие книги по экономике
Главная страница

Главная

Замовити роботу

Последние поступления

Форум

Создай свою тему

Карта сайта

Обратная связь

Статьи партнёров


Замовити роботу
Книги по
алфавиту

Б
В
Г
Д
Е
Ж
З
И
К
Л
М
Н
О

системи підтримки прийняття рішень

Страницы [ 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 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]

 

8.2.3. Використання СППР-генераторів для створення специфічних СППР


Як уже зазначалося, з метою прискорення розроблення специфічних систем підтримки прийняття рішень проектувальники використовують комерційно доступні найновіші засоби і технології. Ці інструментальні засоби і технології об’єднуються загальним поняттям «генератори СППР» або «СППР-генерато­ри». Раніше була описана сутність СППР-генераторів і наведені деякі відповідні програмні продукти. Питання полягає в тому,
у який спосіб можна оцінити наявні додатки з метою створення при­кладної СППР, якими можливостями СППР-генератори мають бути забезпечені з погляду їх відповідності потребам користувачів. Найґрунтовніші рекомендації щодо цього наводить Vicki Sauter у навчальному посібнику «Decision Support Systems: An Applied Managerial Approach» 1997 року (С. 293—303). До речі, достатньо змістовна інформація та джерела з проектування СППР розміщені на Web-сторінці цього автора — http://www.­umsl.edu/~sauter/ DSS/design.html.
Звичайно, найкращим варіантом оцінювання СППР-генера­тора перед його купівлею чи орендою є перевірка його можливостей щодо реалізації вимог до прикладних СППР і потреб творців рішень. Ці вимоги мають бути заявлені перед купівлею чи орендою. Вони повинні стосуватися основних компонентів СППР (керування даними, керування моделями і аналізом, користувацького інтерфейсу) та деяких відповідних умов.

Вимоги до даних і керування ними,
що обговорюються за вибору генератора СППР

Виходячи із загальної перспективи, необхідно відповісти на запитання: генератор буде сприяти спрощенню чи заважати доступу і обробленню необхідних даних. Наприклад, у табл. 8.1. наведені деякі властивості, які стосуються бази даних і СКБД у СППР. На жаль, не завжди легко можна визначити, які саме дані будуть використовуватися або як буде розширюватися попит на них, коли застосовуватиметься СППР. Тому проектувальникам необхідно виявити перспективні бачення ОПР, аналізуючи, чи генератор є адекватним, гнучким і придатним для використання і чи забезпечує він достатній захист, ураховуючи функції приклад­ної СППР.

Таблиця 8.1

ВИМОГИ ДО ДАНИХ І КЕРУВАННЯ НИМИ,
ЩО ОБГОВОРЮЮТЬСЯ У РАЗІ ВИБОРУ ГЕНЕРАТОРА СППР
Вимоги

Характеристика

Адекватність
  • Забезпечує загальне зображення даних користувача
  • Добрі зв’язки з системою керування корпоративної бази даних
  • Підтримує створення сховищ даних
Гнучкість
  • Пропонує утворення «персональної» бази даних
  • Підтримує широкий діапазон форматів бази даних (текст, графіку, звук, відео тощо)
  • Полегшує можливість незапланованих запитів
  • Надає гнучкі засоби перегляду загальнодоступних даних
Простота використання
  • Легкі пропозиції у виборі даних
  • Має словник бази даних
  • Можливість маніпуляції даними
  • Можливість працювати з неітегрованими даними
Захист
  • Забезпечує можливостями захисту даних
  • Пропонує багаторівневий захист
  • Наявні засоби керування одночасним доступом інших користувачів
  • Створює контрольні журнали

Зокрема, проектувальникам потрібно визначити, чи: узгоджений стосовно забезпечення даними; має добрий інтерфейс з інструментальними засобами керування корпоративними даними; уможливлює створення сховища даних. Інакше кажучи, адекватність генератора відбиває те, чи буде він надійним і чи спрощений доступ користувача до необхідних даних.
Генератор також має бути гнучким стосовно використання даних, щоб відповідати різним потребам ОПР, наприклад, щодо створення і використання персональних баз даних виключно творцями рішень. Так само ОПР мусять мати певний інструментальний засіб, який досліджував би загальнодоступні бази даних та використовував би повний ряд розробок щодо запитів, які використовуються в корпоративних базах даних. Крім того, генератор має забезпечувати використання різних форматів, оскільки ОПР можуть бути потрібні графічні, звукові й відео зображення, і навіть доступ до файлів віртуальної реальності.
Простота використання стосується здатності системи задовольняти потреби ОПР у вибиранні даних і підтримці рішень. З одного боку, питання щодо легкості використання СППР визначається розмірами бази даних та результатних таблиць або кількістю запитів, що можуть бути створені одночасно. Оскільки розмір і ціна часто надзвичайно тісно пов’язані, тому потрібно бути достатньо впевненим у покупці, щоб вона відповідала передбачуваним потребам. З другого боку, питання щодо простоти використання може зумовлюватися здатністю ОПР знаходити необхідні змінні й примушувати систему сприймати їх.
Врешті, будь-якій компанії потрібно мати захист специфічних даних. Користувачі сподіваються, що СППР полегшить проблеми розміщення інформації і звітів. Разом із цією легкістю, однак, виникає вимога, щоб генератор СППР унеможливлював користування інформацією тим, хто не працює на корпорацію. Є також очевидним, що існують дуже важливі або конфіденційні дані, доступ до яких за певних умов можуть мати лише окремі службовці. Тому генератор має забезпечувати багаторівневий захист та постійний контроль для визначення того, хто намагався отримати доступ до захищених даних і саме до яких.

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

Так само проектувальникам потрібно оцінити ключові питання стосовно моделей і системи керування ними, що асоцію­ються з генератором СППР. Генератору потрібно задовольняти як можливості моделювання, так і аналізу ОПР. У даному разі здійснення моделювання генератором має відбуватися з тими видами і розмірами моделей, якими зацікавлені ОПР. Зокрема, це стосується моделей, які доступні й легко використовуються, гнучкі (особливо щодо розміру) та мають функціональні можливості, які можна реалізувати у створюваній системі.
Можливості аналізу, з другого боку, стосуються спроможності генератора забезпечити ОПР багатим середовищем з моделювання. Особливість СППР, що відрізняє її від простого пакета моделювання, якраз і полягає в здатності спростити як використання, так і інтерпретацію моделей. Наприклад, компонента керування моделями має бути спроможною за необхідності використовувати виведення даних одного аналізу як введення до іншого. Крім того, генератор СППР повинен уможливлювати проведення і спрощення аналізу чутливості, що відповідає визначеному ряду моделей.
Система має не тільки уможливлювати перегляд припущень і повторне застосування моделей за наявності змін у припущеннях, але також заохочувати користувачів до цього за допомогою забезпечення легкого маршруту до таких аналізів і дружньої інтерпретації виведення даних. Урешті, генератор має надавати контекстно-залежну допомогу користувачеві за моделювання. Це не є повторенням он-лайнової версії інструкцій для користувачів, які нині є в багатьох ПК-базованих додатках, скоріше це рівень допомоги в тому, як застосувати модель, включаючи обґрунтування допущень і обмежень моделі, і навіть інтелектуальне втручання, коли за моделювання припущення були порушені.

Розгляди інтерфейсу користувача
за вибору СППР-генератора

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

Інші вимоги щодо
вибору СППР-генератора

Як із будь-яким прийнятним програмним забезпеченням, потрібно турбуватися, щоб система могла функціонувати в середовищі користувача, щоб можна було придбати це програмне забезпечення і з часом модернізувати його. Питання сумісності, передусім, стосуються: сумісності з доступною системою електронної пошти (спільне використання документа, розподіл даних; комунікації; оброблення пошти і встановлення коду пріоритетності); доступу до ресурсів Інтернету, включаючи послуги щодо новин, пошуку і Web-сторінок; електронні пошукові пристрої для Інтернет-ресурсів; готовність вогнезахисту. Важливо гарантувати, щоб вибраний генератор СППР відповідав доступному устаткуванню, операційним системам і мережевим опціям. Крім цього, він має функціонувати з будь-якими додатково придбаними ресурсами, включаючи засоби введення і виведення даних, пристрої пам’яті тощо.
8.3. Макетування СППР
8.3.1. Суть і стратегія макетування
Що таке макетування?
Виникнення нових технічних і програмних засобів, які дають змогу «індустріалізувати» технологію побудови нових систем, зумовило появу нової концепції проектування СППР — адаптивного проектування, згідно з якою створення кінцевого продукту відбувається за рахунок інтерактивного процесу, в якому користувач, розробник і система багатократно взаємодіють один з одним.
З погляду адаптивного проектування СППР основні проблеми можна сформулювати так: зрозуміння динаміки зв’язків між користувачем, проектувальником і системою; аналіз зв’язків між проблемами, завданнями, поведінкою користувача, а також проек­туванням системи; інтеграція організаційних, психологічних та
інструментальних аспектів у процесі проектування СППР.
Основним методом побудови СППР у рамках адаптивного проектування є макетування або прототипування (від англ. prototyping), тобто розробник спочатку створює макет або прототип (Prototype), який має основні риси бажаної системи, а потім у результаті спільної праці розроблювача і користувача цей зразок доводиться до кінцевої стадії. Прототип забезпечує розробників і потенційних користувачів ідеєю стосовно того, як система функціонуватиме в досконалому вигляді.
Необхідність макетування як процесу створення спрощеної версії (попереднього варіанта) системи обґрунтовується тим, що інтерактивні системи типу СППР неможливо розробити легко, швидко і без введення інформації протягом усього життєвого циклу майбутніми кінцевими користувачами; такі системи потребують участі користувачів для отримання необхідної інформації якомога швидше і з мінімальними витратами.
Можливими цілями макетування СППР є:
отримання інформації про роботу системи від користувачів, для яких призначена СППР. На основі цієї інформації можуть бути змінені конкретні вимоги до системи, що буде сприяти збільшенню гарантій правильності функціонування кінцевої версії системи;
дослідження проблемних завдань або деяких наслідків, альтернативних рішень, прийнятих під час проектування чи реалізації СППР. При цьому можна абсолютно не звертати увагу на ефективність або робочі характеристики системи і повністю ігнорувати деякі функції системи в кінцевому її варіанті. Звичайно, у разі дослідження за допомогою макетування аспектів поведінки системи створений прототип СППР має бути цілком реальним.
Для систем малого масштабу макетування може замінити метод розроблення життєвого циклу системи. Однак для великих систем або тих, що впливають на великі організаційні структури, макетування об’єднується з розробленням життєвого циклу системи (SDLC). Наприклад, макетування у фазі аналізу може допомогти користувачам визначити їхні інформаційні потреби. У фазі проектування воно може допомогти оцінити альтернативні конфігурації системи. Усе це відображено в дев’ятиетапній моделі макетування (рис. 8.6).

Види прототипів

Є два види прототипів. Вид І зрештою стає діючою системою. Вид II прототипу є тимчасовим (що з часом відкидається) зразком системи, який служить ескізом діючої системи.

Привабливість і потенційні недоліки
(пастки) макетування

Як користувачі, так і інформаційні фахівці зацікавлені в макетуванні з таких причин:

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

Ці переваги дають можливість зменшувати витрати на розроб­лення СППР і збільшувати задоволення користувачів від її функціонування.
Макетування не позбавлене потенційних недоліків (пасток). До них належать:

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

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

Стратегія макетування

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


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

Рис. 8.6. Дев’ятиетапна модель макетування СППР
Модель макетування містить дев’ять етапів: 1. Аналіз вимог. 2. Моделювання. 3. Вибір методів. 4. Вибір і проектування програмного забезпечення. 5. Вибір і компонування апаратних засобів. 6. Складання системи. 7. Передавання системи. 8. Оцінювання системи. 9. Зворотний зв’язок. Розглянемо детально перелічені етапи макетування СППР.
8.3.2.2. Аналіз вимог
Підходи до аналізу вимог
Увесь життєвий цикл СППР міцно пов’язаний з якістю і широтою аналізу вимог до майбутньої системи. Ця обставина зумов­лена двома основними причинами: на початку важко передбачити, який кінцевий вигляд повинна мати система; важко також сказати, чи досягла конкретна СППР кінцевого вигляду, тому що у зв’язку із змінами у середовищі системи, завдань користувача або самого користувача вона може бути піддана дальшим змінам. Аналіз вимог користувачів, які, головно, зумовлені їхніми потребами, має бути структурованим, кількісним і можливим для перевірки процесом з тим, щоб одержати робочий проект адаптивної системи, яка задовольняє вимоги користувачів. Звичайно, слід зазначити, що добре проведений аналіз вимог лише сприяє, але аж ніяк не гарантує успіху всієї справи.
Центральним аспектом етапу аналізу вимог є виявлення мети і здійснюваності проекту, концентрація уваги, передусім, на тому, для чого призначена СППР. Для цього проектувальники хотіли б мати чіткі критерії оцінювання системи. Не досить лише визначити систему у вигляді входів і виходів, даних і звітів. Потрібні точні знання багатопланового контексту проблеми.
Під час аналізу цільової орієнтації системи, передусім, необхідно звернути увагу на два ключові елементи СППР — користувачів і задачі. Побудова профілю користувача СППР пов’язана з вивченням його характеристик, які стосуються поєднання: ОПР—комп’ютерна система. Існують кілька таксономій (класифікацій) характеристик користувачів, що ґрунтуються на обмеженому ряді критеріїв. Наприклад, користувачів можна поді-
лити на ряді категорії: за принципом їхнього досвіду роботи з інтерактивними комп’ютерними системами; відповідно до їхніх описів своєї роботи; за очікуваною частотою використання СППР.
Вивчення процесу прийняття рішень у ряді предметних галузей, де використовуються СППР, зумовило необхідність ввести поняття «задача», як чітко окреслене коло операцій з прийняття рішень (яке охоплює широкий діапазон операцій від збору інфор­мації до вибору варіантів, реалізації і зворотного зв’язку). У процесі аналізу задач, включених до СППР, здійснюють їх ідентифікацію й оцінювання.
Існує кілька методів ідентифікації задач. До класичних методів належать інтерв’ювання, запитальники і спостереження спеціалізованими робочими групами, оскільки за традицією прийнято вважати, що кращим (якщо не єдиним) методом для складання списку функцій (задач) групи користувачів є їх опитування або стеження за ними у той чи інший спосіб (аналогічно здійснюється збір знань за створення експертних систем). Поширеним методом визначення вимог є симуляція (для широких і складних предметних галузей), а також метод критичного випадку. Але жодний із методів не є незаперечним, що потребує застосування одночасно двох або більше методів у їх взаємозв’язку.
Особлива сутність СППР вимагає створення спеціального інструментарію — сукупності унікальних моделей і методів, призначених для ідентифікації, відтворення та виведення інформації і дій з прийняття рішень, які характерні для задач, що підлягають включенню в СППР. Інструментарій для аналізу вимог до СППР у загальному випадку складається з трьох базових емпіричних дослідних стратегій:

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

Перша стратегія поєднує широкий діапазон способів, починаючи від простого аналізу прикладів для обмежених контекстів до керованих експериментальних досліджень (де вводяться експериментальні змінні, але немає засобів керування) і реальних експериментів (коли є засоби керування, але експеримент проводиться в реальному середовищі). Аналіз вимог, проведений в натуральному середовищі, має велику цінність, тому що в такому разі можна успішно робити узагальнення від близького до широкого середовища задачі, що потребує прийняття рішень. У такому разі має місце дилема: зовнішня вірогідність (тобто здатність до узагальнення) висока і в той же час внутрішня вірогідність (що означає межі застосування науково обґрунтованих засобів керування) низька. Але в усякому разі стратегія реального середовища найдоречніша.
Існує кілька моделей і методів для реальних досліджень і аналізу прикладів. До найпоширеніших належать:
модель «переконання або напрям думок», що відтворює бажання чи сподівання особи, яка приймає рішення, на основі допущення, що думки і сприйняття індивідуума є ключовими детер­мінантами входів для моделі процесу прийняття рішень, під­тримуваних СППР;
модель «взаємодія», де розглядаються основи взаємодії керівника і середовища для того, щоб визначити сутність джерел інформації;
«комунікаційна» модель, концепція якої передбачає визначення інформаційних потоків у самій організації.
Слід зазначити, що ці три моделі дуже важливі для аналізу вимог до СППР, оскільки комп’ютерна система, яка ігнорує або пробує довільно змінювати протікання фактичного процесу, наперед приречена на невдачу.
Для проведення аналізу в експериментальних (чи квазіекспериментальних) ситуаціях, де вивчення проводиться в штучному лабораторному середовищі, також розроблено ряд моделей і методів, зокрема, «регресійну модель» і метод «аналізу протоколів».
«Регресійна модель», яка найпридатніша для структурованих задач СППР, спочатку потребує регресійного моделювання міркувань, висновків і варіантів вибору ОПР. Індивідууми здійснюють оцінювання (наприклад, керівники банку, куди звертаються особи за кредитом, можуть прогнозувати успіх або невдачу), використовуючи «навідні» вказівки-чинники, які пояснюють очікуваний результат. Потім будується регресійна модель (для пояснення міркувань), в якій передбачення є ендогенними величинами, а «навідні» чинники використовуються як незалежні змінні. Причому вплив різних факторів можна регулювати (або цілком ігнорувати) за рахунок введення в модель коефіцієнтів їх важливості.
Отже, регресійна модель пов’язує входи і виходи системи, але повністю ігнорує процес, який проходить усередині системи. Цей проміжний процес можна прослідкувати за допомогою методу «аналізу протоколу». Для цього аналітик записує на магнітну стрічку розмову ОПР, що відтворює її «думки вголос» протягом сеансу прийняття рішень, а потім пробує ідентифікувати і відтворити процес, який покладений в основу сеансу. Протоколи «думок уголос» майже незамінні в багатьох випадках застосування засобів підтримки прийняття рішень. Метод аналізу протоколу краще пристосований для слабоструктурованих контекстів, але є трудомісткішим і тривалішим.

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

Методи опитування та інші
методи аналізу вимог (потреб)

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

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

Відповіді на ці запитання сприяють діалогу між користувачами та групою розробників СППР, зокрема, розробників виконавчих інформаційних систем.
Є багато способів проведення опитувань і кожен із них забезпечує різні види інформації щодо визначення концепцій, проблем, рішень, етапів розв’язання проблем. Опитування може бути структурованим, неструктурованим та фокусованим (цілеспрямованим). Інтерв’ю може здійснюватися шляхом вивчення прикладів (case studies) або аналізу протоколів. І нарешті, можна використовувати деякі інструментальні засоби, як наприклад, упорядкування карток.
Структуроване опитування — це опитування, за якого всі запитання розміщені у визначеному порядку. Той, кого опитують, надає лаконічні відповіді на поставлені для отримання специфічної інформації запитання.
Фокусоване опитування, з іншого боку, є відносно неструктурованим. У такому разі інтерв’юер також має низку запитань, що розміщені у визначеному порядку, але вони загальніші і дають змогу відповідачеві вести обговорення у відповідному напрямі.
Протокольний аналіз є іншим видом інтерв’ю, тому що інтерв’юер навіть не встановлює чіткого базису для обговорення. Замість того, відповідачі виконують свої типові процеси стосовно прийняття рішень (включаючи пошук інформації, генерування альтернатив, моделювання, аналіз чутливості та інші операції, які належать до цього процесу). Для того, щоб повідомити про те, що трапилось і чому саме так трапилось, ОПР формулює словами кожне завдання й субзавдання, і як дане рішення примушує приступати до розв’язання іншої задачі. Звичайно, інтерв’юер не втручається в цей процес, а тільки забезпечує його описання. Протокольний аналіз є цінним інструментальним засобом, тому що він допомагає розробникам зрозуміти те, що детально роблять ОПР у процесі прийняття рішень.
Упорядкування (сортування) карток можна застосовувати до будь-якого завдання (від використання однорідних карток до комп’ютерної імітації), в якому творець рішень в інтерактивному режимі сортує інформацію і комбінує тренди чи концепції, щоб визначити тенденцію розвитку подій. Наприклад, якщо ситуація вибору стосується заяв на позику, ОПР має сортувати певну сукупність заяв на позику на окремі купки (наприклад, «прийнятні», «граничні», «неприйнятні»). Після того, як ОПР задоволена подібністю кредитних документів у кожній пачці, проектувальник аналізує документи за допомогою творця рішення для того, щоб визначити критерії сортування. Інакше кажучи, знайшовши подібності й відмінності між документами в одній пачці та документами в різних пачках, проектувальник може визначити критерії та їх стандартні величини, що застосовуються для сортування. Це допомагає проектувальнику зрозуміти, як він має забезпечити інформацією та які моделі розробити для ОПР.
Для того, щоб ідентифікувати більше інформаційних потреб, проектувальники уважно досліджують специфічні види рішень шляхом вивчення прикладів (case studies). Зокрема, вони можуть виявити деякі інформаційні потреби, вивчаючи концептуальні й теоретичні засади прийняття рішень, наприклад, у бізнес-класах.

Страницы [ 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 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]


ВНИМАНИЕ! Содержимое сайта предназначено исключительно для ознакомления, без целей коммерческого использования. Все права принадлежат их законным правообладателям. Любое использование возможно лишь с согласия законных правообладателей. Администрация сайта не несет ответственности за возможный вред и/или убытки, возникшие или полученные в связи с использованием содержимого сайта.
© 2007-2019 BPK Group.