Ситник В.Ф. Системи підтримки прийняття рішень

Подождите немного. Документ загружается.

8.3.2. Дев 'ятиетапна модель макетування

8.3.2.1. Загальна схема

Макетування СППР часто викликає асоціацію з

хаотичним процесом. Однак правильний підхід до

макетування повністю сумісний із процесом створення

структурованої проектної документації СППР. Зображена на

рис. 8.6 дев'ятиетапна модель макетування являє собою

комбінацію, в якій поєднані принципи швидкого прикладного

макетування з деякими більш традиційними методами і

вимогами, які прийняті в галузі проектування систем

(наприклад, з підходом на основі життєвого циклу системи).

Етапи Дії (операції)

Модель макетування містить дев'ять етапів: 1. Аналіз

вимог. 2. Моделювання. 3. Вибір методів. 4. Вибір і

проектування програмного забезпечення. 5. Вибір і

компонування апаратних засобів. 6. Складання системи. 7.

Передавання системи. 8. Оцінювання системи. 9. Зворотний

зв'язок. Розглянемо детально перелічені етапи макетування

СППР.

8.3.2.2. Аналіз вимог

Підходи до аналізу вимог

Увесь життєвий цикл СППР міцно пов'язаний з

якістю і широтою аналізу вимог до майбутньої системи. Ця

обставина зумовлена двома основними причинами: на початку

важко передбачити, який кінцевий вигляд повинна мати

система; важко також сказати, чи досягла конкретна СППР

кінцевого вигляду, тому що у зв'язку із змінами у середовищі

системи, завдань користувача або самого користувача вона

може бути піддана дальшим змінам. Аналіз вимог

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

бути структурованим, кількісним і можливим для перевірки

процесом з тим, щоб одержати робочий проект адаптивної

системи, яка задовольняє вимоги користувачів. Звичайно, слід

зазначити, що добре проведений аналіз вимог лише сприяє,

але аж ніяк не гарантує успіху всієї справи.

Центральним аспектом етапу аналізу вимог є виявлення

мети і здійснюваності проекту, концентрація уваги, передусім,

на тому, для чого призначена СППР. Для цього

проектувальники хотіли б мати чіткі критерії оцінювання

системи. Не досить лише визначити систему у вигляді входів і

виходів, даних і звітів. Потрібні точні знання багатопланового

контексту проблеми.

Під час аналізу цільової орієнтації системи, передусім,

необхідно звернути увагу на два ключові елементи СППР —

користувачів і задачі. Побудова профілю користувача СППР

пов'язана з вивченням його характеристик, які стосуються

поєднання: ОПР—комп'ютерна система. Існують кілька

таксономій (класифікацій) характеристик користувачів, що

ґрунтуються на обмеженому ряді критеріїв. Наприклад,

користувачів можна поділити на ряді категорії: за принципом

їхнього досвіду роботи з інтерактивними комп'ютерними

системами; відповідно до їхніх описів своєї роботи; за

очікуваною частотою використання СППР.

361

Вивчення процесу прийняття рішень у ряді предметних

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

ввести поняття «задача», як чітко окреслене коло операцій з

прийняття рішень (яке охоплює широкий діапазон операцій

від збору інформації до вибору варіантів, реалізації і

зворотного зв'язку). У процесі аналізу задач, включених до

СППР, здійснюють їх ідентифікацію й оцінювання.

Генує кілька методів ідентифікації задач. До класичних

методів належать інтерв'ювання, запитальники і

спостереження спеціалізованими робочими групами, оскільки

за традицією прийнято вважати, що кращим (якщо не єдиним)

методом для складання списку функцій (задач) групи

користувачів є їх опитування або стеження за ними у той чи

інший спосіб (аналогічно здійснюється збір знань за

створення експертних систем). Поширеним методом

визначення вимог є симуляція (для широких і складних

предметних галузей), а також метод критичного випадку. Але

жодний із методів не є незаперечним, що потребує

застосування одночасно двох або більше методів у їх

взаємозв'язку.

Особлива сутність СППР вимагає створення спеціального

інструментарію — сукупності унікальних моделей і методів,

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

інформації і дій з прийняття рішень, які характерні для задач,

що підлягають включенню в СППР. Інструментарій для

аналізу вимог до СППР у загальному випадку складається з

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

— вивчення в середовищі натуральної поведінки;

— аналіз прийняття рішень в експериментальних (або

квазіек-спериментальних) ситуаціях;

— дослідження, незалежні від середовища, з

запитальниками.

Перша стратегія поєднує широкий діапазон способів,

починаючи

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

керованих експериментальних досліджень (де вводяться

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

реальних експериментів (коли є засоби керування, але

експеримент проводиться в реальному середовищі). Аналіз

вимог, проведений в натуральному середовищі, має велику

цінність, тому що в такому разі можна успішно робити

узагальнення від близького до широкого середовища задачі,

що потребує прийняття рішень. У такому разі має місце

дилема: зовнішня вірогідність (тобто здатність до

узагальнення) висока і в той же час внутрішня вірогідність

(що означає межі застосування науково обгрунтованих

засобів керування) низька. Але в усякому разі стратегія

реального середовища найдоречніша.

362

Існує кілька моделей і методів для реальних досліджень і аналізу

прикладів. До найпоширеніших належать:

модель «переконання або напрям думок», що відтворює бажання

чи сподівання особи, яка приймає рішення, на основі допущення,

що думки і сприйняття індивідуума є ключовими детермінантами

входів для моделі процесу прийняття рішень, підтримуваних СППР;

модель «взаємодія», де розглядаються основи взаємодії керів-

ника і середовища для того, щоб визначити сутність джерел ін-

формації;

«комунікаційна» модель, концепція якої передбачає визначення

інформаційних потоків у самій організації.

Слід зазначити, що ці три моделі дуже важливі для аналізу вимог

до СППР, оскільки комп'ютерна система, яка ігнорує або пробує

довільно змінювати протікання фактичного процесу, наперед

приречена на невдачу.

Для проведення аналізу в експериментальних (чи квазіекспе-

риментальних) ситуаціях, де вивчення проводиться в штучному

лабораторному середовищі, також розроблено ряд моделей і ме-

тодів, зокрема, «регресійну модель» і метод «аналізу протоколів».

«Регресійна модель», яка найпридатніша для структурованих за-

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

висновків і варіантів вибору ОПР. Індивідууми здійснюють

оцінювання (наприклад, керівники банку, куди звертаються особи за

кредитом, можуть прогнозувати успіх або невдачу), використо-

вуючи «навідні» вказівки-чинники, які пояснюють очікуваний ре-

зультат. Потім будується регресійна модель (для пояснення мірку-

вань), в якій передбачення є ендогенними величинами, а «навідні»

чинники використовуються як незалежні змінні. Причому вплив рі-

зних факторів можна регулювати (або цілком ігнорувати) за раху-

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

Отже, регресійна модель пов'язує входи і виходи системи, але

повністю ігнорує процес, який проходить усередині системи. Цей

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

«аналізу протоколу». Для цього аналітик записує на магнітну

стрічку розмову ОПР, що відтворює її «думки вголос» протягом

сеансу прийняття рішень, а потім пробує ідентифікувати і відтво-

рити процес, який покладений в основу сеансу. Протоколи «думок

уголос» майже незамінні в багатьох випадках застосування засобів

підтримки прийняття рішень. Метод аналізу протоколу краще

пристосований для слабоструктурованих контекстів, але є

трудомісткішим і тривалішим.

363

Важливість структурованого аналізу вимог неможливо

переоцінити. Колективи розробників не залишають цю першу

проблему, поки не буде закінчена попередня специфікація

системи в задачно-аналітичному розрізі, наприклад, на основі

зіставлення сукупності користувачів, задач, організаційних

доктрин і процедур для СППР.

Методи опитування та інші

методи аналізу вимог

(потреб)

Дуже часто проектувальники вивчають потреби

ОПР за допомогою опитування (інтерв'ювання). Наприклад,

типовий список запитань, що використовується під час

інтерв'ю з топ-менеджерами (виконавцями) чи в процесі

обстеження їх роботи, може містити такі запитання:

• Які ваші цілі і як вони стосуються ваших інформаційних

потреб?

• Чи дійсно є типи інформації, якою менеджери

обмінюються тільки усно (вербально), проте вона має бути

включена до організаційних рішень та інформаційних

ресурсів?

• Чи необхідно цю інформацію включати до формального

звіту або схеми?

• Які типи завдань щодо збирання інформації зобов'язані

підтримувати супроводжуючі штатні працівники?

• Чи має місце збіг термінів у різних частинах організації

стосовно інформаційних ресурсів та потреб?

• Як має бути інтегрована інформація від різноманітних

джерел та департаментів?

• Чи можна деякі задачі централізувати та обробляти

автоматично?

• Яку інформацію ви бажали б мати, проте зараз вам її

бракує?

• Які ваші майбутні інформаційні потреби?

Відповіді на ці запитання сприяють діалогу між

користувачами та групою розробників СППР, зокрема,

розробників виконавчих інформаційних систем.

Є багато способів проведення опитувань і кожен із них

забезпечує різні види інформації щодо визначення концепцій,

проблем, рішень, етапів розв'язання проблем. Опитування

може бути структу-рованим, неструктурованим та

фокусованим (цілеспрямованим). Інтерв'ю може

здійснюватися шляхом вивчення прикладів (case studies) або

аналізу протоколів. І нарешті, можна використовувати деякі

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

364

Структуроване опитування — це опитування, за якого всі

запитання розміщені у визначеному порядку. Той, кого

опитують, надає лаконічні відповіді на поставлені для

отримання специфічної інформації запитання.

фокусоване опитування, з іншого боку, є відносно

неструкту-рованим. У такому разі інтерв'юер також має низку

запитань, що розміщені у визначеному порядку, але вони

загальніші і дають змогу відповідачеві вести обговорення у

відповідному напрямі.

Протокольний аналіз є іншим видом інтерв'ю, тому що ін-

терв'юер навіть не встановлює чіткого базису для

обговорення. Замість того, відповідачі виконують свої типові

процеси стосовно прийняття рішень (включаючи пошук

інформації, генерування альтернатив, моделювання, аналіз

чутливості та інші операції, які належать до цього процесу).

Для того, щоб повідомити про те, що трапилось і чому саме

так трапилось, ОПР формулює словами кожне завдання й

субзавдання, і як дане рішення примушує приступати до

розв'язання іншої задачі. Звичайно, інтерв'юер не втручається

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

Протокольний аналіз є цінним інструментальним засобом,

тому що він допомагає розробникам зрозуміти те, що

детально роблять ОПР у процесі прийняття рішень.

Упорядкування (сортування) карток можна застосовувати

до будь-якого завдання (від використання однорідних карток

до комп'ютерної імітації), в якому творець рішень в

інтерактивному режимі сортує інформацію і комбінує тренди

чи концепції, щоб визначити тенденцію розвитку подій.

Наприклад, якщо ситуація вибору стосується заяв на позику,

ОПР має сортувати певну сукупність заяв на позику на окремі

купки (наприклад, «прийнятні», «граничні», «неприйнятні»).

Після того, як ОПР задоволена подібністю кредитних

документів у кожній пачці, проектувальник аналізує

документи за допомогою творця рішення для того, щоб

визначити критерії сортування. Інакше кажучи, знайшовши

подібності й відмінності між документами в одній пачці та

документами в різних пачках, проектувальник може

визначити критерії та їх стандартні величини, що

застосовуються для сортування. Це допомагає

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

інформацією та які моделі розробити для ОПР.

Для того, щоб ідентифікувати більше інформаційних

потреб, проектувальники уважно досліджують специфічні

види рішень шляхом вивчення прикладів (case studies).

Зокрема, вони можуть виявити деякі інформаційні потреби,

вивчаючи концептуальні й теоретичні засади прийняття

рішень, наприклад, у бізнес-класах.

365

8.3.2.3. Моделювання

Структурування задач для проектування й

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

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

функціонально змодельований. Але після завершення

моделювання системи її розробниками слід повертатися назад

до моделей, задач, користувачів, організаційної доктрини,

оскільки проектування та розроблення — це ітера-ційний

процес, що потребує повторного моделювання. Можна

виділити чотири форми подання моделей системи: описові

(вербальні) моделі; моделі у вигляді блок-схем; математичні

(кількісні) моделі; оболонки (альбоми, набори) сюжетів.

Розглянемо ці форми моделей детальніше.

Описові (вербальні) моделі мають містити відомості про

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

до вхідної інформації, описувати та ілюструвати вихід СППР і

пропонувати програмну й апаратну конфігурацію. Описове

подання має бути точним і лаконічним, за можливості

ілюструватися симульованими екранними зображеннями.

Слід зазначити, що описовий підхід прийнятний для

нескладних застосувань СППР і непі-знавальних системних

задач.

Є кілька різних видів блок-схем, які можна досить

продуктивно використати для розроблення моделей

прототипів СППР. Сюди відносяться:

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

потоки інформації;

— функціональні блок-схеми, де візуально зображена

картина функціонування системи;

— логічні блок-схеми, які використовуються для

ілюстрації проходження даних через систему (програму) і

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

логіки;

— узагальнені блок-схеми, що являють собою подання

вищого рівня, призначені для використання керівництвом.

Для подання прототипів СППР можна використати готові

методи математичного моделювання, зокрема, сітьові моделі,

моделі на засадах теорії управління, моделі на засадах теорії

рішень, моделі оброблення інформації людиною, моделі

комп'ютерних систем.

Оболонки (альбоми) сюжетів. Моделі екранних зображень

і оболонки сюжетів (низки копій екранних зображень)

являють собою найкорисніші моделі, як такі, що дають

можливість проде-

366

монструвати кінцевому користувачу, якими будуть остаточні

можливості системи і як вони будуть реалізовані. Такі

оболонки сюжетів симулюють людино-машинну взаємодію в

міру розгортання їх за проектування СППР. Сучасні пакети

мультиплікацію-вання дають змогу «оживляти» всі низки

сюжетів, імітуючи складні інтерактивні графічні засоби.

Розробники СППР усе частіше поєднують оболонки сюжетів

із швидким макетуванням застосувань.

8.3.2.4.Вибір методів

Оцінювання і вибір аналітичних методів для

створення методологічної бази підсистеми СППР є змістом

третього етапу макетування. Відправною точкою для

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

результати зіставлення задач і методів, одержані за аналізу

вимог. Добре ідентифіковані характеристики задачі СППР на

першому етапі дають можливість легко і виразно вивчати

розумні пропозиції відносно застосованих методів.

Наприклад, якою є галузь СППР за своєю суттю: індуктивною

чи дедуктивною (чи деякою комбінацією цих концепцій)?

Відповіді на ці запитання стануть орієнтирами для вибору

потрібного типу методів.

Перед тим, як вибрати для СППР метод (або комбінацію

методів), необхідно оцінити пов'язаний з ним

епістемологічний (пізнавальний) і аналітичний супровід та

переконатися в сумісності методів, задач, користувачів і

організацій з відповідними доктринами.

8.3.2.5.Вибір і (або) проектування

програмного забезпечення

Програмне забезпечення (ПЗ) реальної СППР можна

отримати двома шляхами: купити готове чи замовити його

розроблення. Готові або комерційні програми для системи

підтримки прийняття рішень можуть бути цілком

прийнятними. Готове ПЗ завжди дешевше ніж замовлене, але

менше пристосоване до конкретних потреб користувачів.

Замовлене ПЗ має розроблятися за висхідним принципом,

починаючи від урахування вимог користувачів. Є і проміжний

варіант, коли куплене готове програмне забезпечення

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

367

його дальшого модифікування і вдосконалення. Вибір для

цього питання правильного рішення вимагає застосування

структуро-ваного підходу, зокрема, за допомогою методів

аналізу рішень або аналізу затрат і вигід.

Є кілька важливих показників ефективного інтерактивного

ПЗ, головними з яких є:

1) ефективний інтерактивний діалог;

2) раціональна (дружня, ергономічно продумана) структура

введення інформації;

3) високоякісна система відображення;

4) реалістичний і практичний аналіз та вибір мовних

програмних засобів;

5) використання загальноприйнятих стандартів

програмування в інженерії систем.

Структура інтерактивного діалогу має враховувати

ініціацію, гнучкість, складність, потужність та інформаційне

навантаження під час проектування і розроблення

високоякісного, орієнтованого на користувача ПЗ для СППР.

Найважливіші типи інтерактивного діалогу були розглянуті

раніше.

Розроблення програмного забезпечення СППР має

проводитись у відповідності із загальноприйнятими

стандартами програмування. Добре програмне забезпечення

створюється в результаті процесу інженерії зусиллями

систематично працюючих програмістів під керівництвом

обережних аналітиків. Структуровані методи програмування,

правильне використання міток і ретельне документування —

це лише деякі із характерних ознак якісних програм СППР.

За умови вибору шляху вдосконалення замовленого ПЗ

проектування і розроблення його мають здійснюватися на базі

перегляду альбому сюжетів і реалізації всіх доцільних

модифікацій навіть у тому разі, коли в даний момент уже є

«робоча» система для демонстраційних цілей. «Живий»

альбом (оболонки) сюжетів належить модифікувати, тому що

на цій стадії проектування СППР це забезпечує найкраще

подання функцій системи: крім того, оболонка сюжетів буде

служити «контрольним журналом» або пам'яттю для

проектувальників системи. Важливим є залучення

користувачів в усі аспекти створення ПЗ під час розроблення

нових екранних зображень інтерактивних послідовностей. Ім

потрібно передавати відповідальність за підтримку «живої»

оболонки сюжетів і частину функцій щодо складання

початкової версії посібника для користувачів.

368

8.3.2.6. Вибір і компонування апаратних

засобів

У разі прийняття рішень стосовно вибору апаратної

бази СППР часто має місце передчасність розв'язання цього

питання: тип ЕОМ, а нерідко і периферійні пристрої, і вся

конфігурація загалом вручаються розробнику як визначені і

розв'язані питання на самому початку проектування. Тому

доводиться підганяти СППР до апаратної бази, хоча

ідеальною є протилежна стратегія — вибирати апаратні

засоби після встановлення вимог і моделювання системи.

У центрі питання про створення апаратної бази СППР

знаходиться вибір міні- і мікрокомп'ютерів. Програмне

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

комп'ютерів. Існують також розроблені СППР для будь-яких

апаратних конфігурацій.

Вимоги до системи і програмне забезпечення мають

підтримуватися ввідними пристроями. Є різноманітні

альтернативні засоби введення, але не всі вони можуть

підходити до конкретних застосувань. Розроблювачі мають

також різноманітні альтернативні типи відображень. У

більшості застосувань СППР виникає необхідність отримання

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

та задовольняють вимоги стосовно показника «вартість—

ефективність». Важливе значення для успіху системи має

загальний людино-машинний інтерфейс. Оптимальне

проектування інтерфейсу для СППР потребує участі

спеціаліста з інженерної психології.

8.3.2.7. Складання (комплектування) системи

Усі СППР мають бути добре укомплектованими. Ця

необхідність зумовлена вимогою створення якісної

документації, яка має включати специфікацію системи,

функціональний опис і посібник для користувача. Часто має

місце спокуса частково або цілком уникнути цієї трудомісткої

і нерідко монотонної роботи зі складання «твердих» копій

документів, особливо на заключній стадії розроблення

системи і написання програмних (машинних) кодів.

Нехтування створенням необхідної документації може мати

катастрофічні наслідки, зокрема, на майже обов'язковому ета-

пі налагоджування системи, коли потрібно здійснювати як ви-

правлення, так і супроводження програмного забезпечення.

Частиною комплекту документації системи мають бути

засоби підтримки. СППР, яка не має таких засобів, можливо,

узагалі не буде використовуватись. Підтримка на місці

експлуатації разом із під-

369