Е Аналіз вимогтапи 1 дії (активності)

Здійстинмість; оцінка обмежень;

Користувач; задача матри матриці;

2. Організацінйої доктрини

Моделювання

Описова частина;

Складання блок-схем;

3 Компонування сюжетів

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

Оцінка; порівняння затрат і вигод;

Сумісність вимог

4

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

оцінка стандартного ПЗ;

увід; відображення;

вивід; розробка ПЗ;

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

5

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

вивід; вибір обладнання проектування

6 людино-машиного інтерфейса;

Складання системи

документування;

підтримка;навчання

7. о

   Передача системи

   цінка ситуації;

8. вибір методу управління

змінами

Оцінка системи

ціль; специфікація методу;

розробка критерію;

вибір сценарію

Зворотний зв’язок

вивчення оцінки;

замкнення зворотного зв’язку.

Рис.9. Дев’ятиетапна модель макетування

“Надіюсь, що система полегшить для мене доступ до всіх необхідних контрактів і пропозицій, які можна накопичувати в комп’ютері. Спочатку задовольняють мене прості відповіді на питання типу: Хто заключив більшість контрактів зазначеного виду? Який був середній діапазон оцінок для певного роду контрактів? Який найбільший контракт заключила фірма в поточному році? Спочатку ми не в змозі визначити питання більш складного характеру. Я буду задоволений, якщо система досить 90% відповідей на мої запитання.

Я рекомендую спроектувати таку систему, яка б могла бути використана керівниками відділів, зокрема відділу збуту. Уявляю собі, що система буде створена таким чином, щоб можна було легко й просто підключати нові необхідні процедури. Я не хочу, щоб ми могли загрузнути в купі величезних звітів і баз даних. Чим скоріше я розпочну експериментувати з системою, тим краще.”

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

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

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

• розробка економетричних процедур для задач прогнозування і екстраполяції;

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

• надання картин і рисунків на екрані на папері в чотирьох кольорах;

• побудова аналітичних процедур типу “якщо так, то що”.

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

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

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

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

1. Вивчення в оточенні натуральної поведінки;

2. Аналіз прийняття рішень в експериментальних (або квазіекспериментальних) ситуаціях;

3. Дослідження, незалежні від оточення , з запитальниками.

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

Існує декілька моделей і методів польових досліджень і аналізу прикладів. До числа найбільш вживаних відносяться:

• модель “переконання або напрям думок”; яка відтворює чи вимірює бажання або сподівання особи, яка приймає рішення (ОПР) на основі передумови, що думки і сприйняття індивідуума є ключовим детермінантом входів в процес прийняття рішень, представлених чи підтримуваних в СППР;

• модель “взаємодія”, де розглядається основи взаємодії керівника і середовища з тим, щоб визначити природу джерел інформації;

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

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

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

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

Таким чином, регресивна модель пов’язує входи і виходи системи, але повністю ігнорує процес, який проходить в проміжку між ними. Цей проміжний процес можна прослідкувати за допомогою методу “аналіз протоколу”. В цьому випадку аналітик записує на магнітну стрічку розмову ОПР, що відтворює “думки вголос” цієї особи пртягом сеансу прийняття рішень, а потім пробує ідентифікувати і відтворити процес, який покладений в основу сеансу. Протоколи “думок вголос” майже незамінні в багатьох випадках застосування засобів підтримки прийняття рішень. Метод аналізу протоколу краще пристосований для слабоструктурованих контекстів, але є більш трудомістким і тривалим.

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