Читайте также:
|
макетування СППР часто викликає асоціацію з анархічним процесом. Однак правильний підхід до макетування повністю сумісний із процесом створення структурузованої проектної документації СППР. Зображена на рис.9 дев’ятиетапна модель макетування являє собою гібрид в якому поєднані принципи швидкого прикладного макетування з деякими більш традиційними методами і вимогами, що прийняті в області проектування систем. Модель макетування включає дев’ять етапів.
1. Аналіз вимог
2. Моделювання.
3. Вибір методів.
4. Вибір і проектування програмного забезпечення.
5. Вибір і консруювання апаратних засобів.
6. Складання системи.ї
7. Передача системи.
8. Оцінка системи.
9. Зворотний зв’язок
Розглянемо детально перазовані етапи макетування СППР.
Аналіз вимог
Увесь життєвий циклСППР міцно пов’язаний з якістю і широтою аналізу вимог до майбутньої чсистеми. Ця обставина обумовлена дією двох основних причин: на початку важко передбачити, який кінцевий вигляд повинна мати система; важко сказати, чи досягла конкретна СППР кінцевого виду, так як в зв’язку із змінами оточення системи, задач користувача або самого користувача вона може бути підданна наступним змінам. Аналіз вимог має бути структурованим, кількісним і можливим для перевірки процесом, з тим, щоб одержати робочий проект адекватної системи, яка задовольняє вимсоги користувача. Правда, слід відмітити, щоб добре проведений аналіз вимог лише сприяє але ніяк не гарантує успіху всієї справи.
Центральним аспектом етапу аналізу вимог є вияснення мети і здійснимості проекту, концентрація уваги на тому, чому потрібна служити СППР. При цьому проектант хотів би користуватися ясними критеріями оцінки системи. Не досить лише визначити систему у вигляді входів і виходів, даних і звітів. Потрібні точні знання багатопланового контексту проблеми. Наприклад, добре професійно підготовлений економічний директор торговельного підприємства може таким чином сформувати вимоги до потрібної йому СППР:
Ні
ні
ні
ні
так
Так
Ні
Рис. 8. Стратегія макетування
|
Здійстинмість; оцінка обмежень;
Користувач; задача матри матриці;
2 
Організацінйої доктрини
|
Складання блок-схем;
3 Компонування сюжетів
|
Сумісність вимог
|
увід; відображення;
вивід; розробка ПЗ;
|
вибір системи; увід; відображення;
вивід; вибір обладнання проектування
6 людино-машиного інтерфейса;
|
підтримка;навчання
7
|
оцінка ситуації;
8 
вибір методу управління
змінами
|
розробка критерію;
вибір сценарію
|
замкнення зворотного зв’язку.
Рис.9. Дев’ятиетапна модель макетування
“Надіюсь, що система полегшить для мене доступ до всіх необхідних контрактів і пропозицій, які можна накопичувати в комп’ютері. Спочатку задовольняють мене прості відповіді на питання типу: Хто заключив більшість контрактів зазначеного виду? Який був середній діапазон оцінок для певного роду контрактів? Який найбільший контракт заключила фірма в поточному році? Спочатку ми не в змозі визначити питання більш складного характеру. Я буду задоволений, якщо система досить 90% відповідей на мої запитання.
Я рекомендую спроектувати таку систему, яка б могла бути використана керівниками відділів, зокрема відділу збуту. Уявляю собі, що система буде створена таким чином, щоб можна було легко й просто підключати нові необхідні процедури. Я не хочу, щоб ми могли загрузнути в купі величезних звітів і баз даних. Чим скоріше я розпочну експериментувати з системою, тим краще.”
Прикладом більш формалізованих вимог до СППР може бути наступна конкретна ситуація. Підприємство, яке випускає комп’ютерні та інші точні вироби з річним рівнем реалізації продукції в розмірі 20 тисяч працівників, виявило суттєві недоліки існуючої системи і вирішило створити на підприємстві СППР. Система повинна виконувати такі функції:
¨ створення основної бази даних підприємства з тим, щоб зробити можливим накопичування, класифікацію і маніпулювання даними для цілей планування;
¨ видача простих звітів у відповідності з запитами користувачів, які охоплюють різні дії з даними;
¨ розробка економетричних процедур для задач прогнозування і екстраполяції;
¨ розробка процедур для роботи з таблицями /наприклад, розрахувати показники під сумуванням по рядках і колонках таблиці/;
¨ надання картин і рисунків на екрані на папері в чотирьох кольорах;
¨ побудова аналітичних процедур типу “якщо так, то що”.
Під час аналізу цільової орієнтації системи, перш за все, необхідно звернути увагу на два ключові інгридієнти СППР: користувачі і задачі. Побудова профілю користувача СППР зв’язана з вивченням його характеристик, які мають відношення до агрегації ЛПР – комп’ютерна система. Існують декілька технологій і (класифікацій) характеристик користувачів, основаних на обмеженому наборі критеріїв. Наприклад, користуачів можна розбити на категорії: за принципом їхнього досвіду роботи з інтерактивними комп’ютерними системами; у відповідності до їхніх описів своєї роботи; за очікуваною частотою використання СППР.
Вивчення процесу прийняття рішень в ряді предметних областей, де використовуються СППР, обумовило необхідність ввести поняття “задача”, які чітко окреслений круг операцій прийняття рішень (який охоплює широкий діапазон від фази збору інформації до вибору варіантів, реалізації і зворотного зв’язку). Аналіз вимог до задач включає ідентифікацію і оцінку задач, які складають основу СППР, що розвивається.
Існує декілька методів ідентифікації задач. До числа класичних методів відносяться інтерв’ю, запитальники і спеціалізовані робочі групи, поскільки за традицією прийнято вважати, що кращий (якщо не єдиний) метод для складання профілю функцій (задач) групи користувачів полягає в тому, щоб опитати членів групи або простежити за ними тим чи іншим способом (аналогічно здійснюється збір знань в області створення експертних систем). Популярним методом визначення вимог є симуляція (для широких і складних предметних областей), а також метод критичного випадку. Але ні один із методів не є заперечним, що вимагає використання одночасно двох або більше методів у взаємозв’язку один з одним.
Особлива природа СППР вимагає створення спеціального інструментарію – сукупності унікальних моделей і методів, призначених для ідентифікації, відтворення та виводу інформації і дій для прийняття рішень, які характерні для задач, що підлягають втіленню в СППР. Інструментарій для аналізу вимог СППР включає три базові емпітричні дослідні стратегії:
1. Вивчення в оточенні натуральної поведінки;
2. Аналіз прийняття рішень в експериментальних (або квазіекспериментальних) ситуаціях;
3. Дослідження, незалежні від оточення, з запитальниками.
Перша стратегія поєднує широкий діапазон способів, починаючи від простого аналізу прикладів для обмежених контекстів до більш керованих польових досліджень (де вводяться експериментальні зміни, але відсутні засоби керування) і польових експерементів (де присутні засоби керування, але експеремент проводиться в реальному оточенні). Аналіз вимог, проведений в натуральному оточенні, має велику цінність, так як в цьому випадку можна успішно робити узагальнення від оточення до середовища задачі для прийняття рішень. Правда, при цьому має місце дилема: зовнішня достовірність (тобто здібність до узагальнення) висока, в той час як внутрішня – (що означає межі застосування науково обгрунтованих засобів керування) низька. Але стратегія натурального оточення найбільш доречна.
Існує декілька моделей і методів польових досліджень і аналізу прикладів. До числа найбільш вживаних відносяться:
- модель “переконання або напрям думок”; яка відтворює чи вимірює бажання або сподівання особи, яка приймає рішення (ОПР) на основі передумови, що думки і сприйняття індивідуума є ключовим детермінантом входів в процес прийняття рішень, представлених чи підтримуваних в СППР;
- модель “взаємодія”, де розглядається основи взаємодії керівника і середовища з тим, щоб визначити природу джерел інформації;
- “комунікаційна” модель, концепція якої передбачає визначення інформаційних потоків у середині організації.
Слід зазначити, що ці три моделі дуже важливі для аналізу вимог до СППР, поскільки комп’ютерна система, яка ігнорує або пробує довільним чином змінити проходження фактичного процесу, приречена на невдачу.
- Для проведення аналізу в експериментальних (квазіекспериментальних) ситуаціях, де вивчення проводиться в штучному лабораторному оточенні, а також розроблено ряд моделей та методів, зокрема “регресивна модель” і метод “аналізу протоколів”.
- “Регресивна модель”, яка найбільш придатна для структурованих задач СППР, спочатку вимагає регресивного моделюваня міркувань, висновків і варіантів вибору ОПР. Індивідууми роблять оцінку (наприклад керівників банку, куди звертаються особи за комерційним кредитом, можуть запропонувати прогноз успіху або невдачі, (використовуючі), “навідні” вказівки-чинники, - які пояснюють очікуваний успіх чи невдачу. Потім будується регресивна модель (для пояснення міркувань), в якій передбачення виступають як ендогенні величини, а навідні чинники використовуються як незалежні змінні. Причому вплив різних факторів можна регулювати (або цілком ігнорувати) за рахунок введення в модель вагових коефіцієнтів.
Таким чином, регресивна модель пов’язує входи і виходи системи, але повністю ігнорує процес, який проходить в проміжку між ними. Цей проміжний процес можна прослідкувати за допомогою методу “аналіз протоколу”. В цьому випадку аналітик записує на магнітну стрічку розмову ОПР, що відтворює “думки вголос” цієї особи пртягом сеансу прийняття рішень, а потім пробує ідентифікувати і відтворити процес, який покладений в основу сеансу. Протоколи “думок вголос” майже незамінні в багатьох випадках застосування засобів підтримки прийняття рішень. Метод аналізу протоколу краще пристосований для слабоструктурованих контекстів, але є більш трудомістким і тривалим.
Важливість структурованого аналізу вимог неможливо переоцінити. Колективи розробників не залишають цю проблему до тих пір, поки не буде закінчена попередня специфікація системи в задачно-аналітичному розрізі, наприклад на основі співставлення сукупності користувачів, задач, організаційних доктрин і процедур для СППР.
Моделювання
Структурування задач для проектування і розробки інтерактивних систем не буде повним (закінченим) до тих пір, поки процес узгодження і співставлення не буде функціональнозмодельовано. Але після завершення моделювання системи розробниками слід повертатися назад до моделей, задач, користувачів організаційної доктрини, поскіьки проектування та розробка це – ітераційний процес повторного моделювання. Існує чотири форми представлення моделей системи: описові (текстуальні) моделі; моделеі в вигляді блок-схем; математичні (кількісні) моделі; оболонки (альбоми, набори) сюжетів. Розглянемо ці форми моделей детальніше.
- описові (текстуальні) моделі повинні вміщувати відомості про задачі, які буде виконувати система, подавати перелік вимог до вхідної інформації, описувати та ілюструвати вивід СППР і запропонувати програмну та апаратну конфігурацію. Описове представлення повинно бути точним і стислим, по можливості ілюструватися симульованими екранними зображеннями. Слід відмітити, що описовий підхід прийнятий для нескладних прикладень СППР непізнавальних системних задач.
- Існує декілька різних видів блок-схем, які можна досить продуктивно використати для розробки моделей прототипів СППР.
Сюди відносяться:
- концептуальні блок-схеми, в яких графічно зображений потік інформації;
- функціональні блок-схеми, де візуально зображена картина функціонування системи;
- логічні блок-схеми, які використовуються для ілюстрації проходження даних через систему (програму) і місцезнаходження процесів прийняття рішень та керуючої логіки;
- узагальнені блок-схеми, що являють собою представлення вищого рівня, призначені для використання керівництвом.
Для представлення прототипів СППР можна використати готові методи математичного моделювання, зокрема сіткові моделі, - моделі на основі теорії управління, моделі на основі теорії рішень, моделі обробки інформації людиною, моделі комп’ютерних систем.
Сіткові моделі дозволяють інтегрувати дані про ефективність роботи користувачів і функціонування комп’ютерних систем в одну модель, навіть якщо ці дані поступили з різних джерел. В них користувач і система розглядаються як еквівалентні системи в загальному процесі. Виконувані як користувачем, так і системою індивідуальні задачі (для кожної із яких необхідно подати дані їхньої ефективності (описуються під кутом очікуваної ефективності та логічного відношення попередник-послідовник, що дозволяє збудувати сітку задач – як модель ефективності системи користувач-комп’ютер. Такі моделі застосовуються, як правило, для передбачення комплексного набору задач “успіху чи невдачі” або часу завершення. Слід зауважити, що процес збору даних ефективності окремих задач і формування правил інтеграції цих даних (для одержання комплексного прогнозу ефективності) нерідко буває важким або через сумнівний характер емпітричних даних чи їх відсутність, або тому, що взаємодії між задачами, зокрема пізнавального характеру чи паралельно виконуваними можуть бути досить складними. Ця обставина деякою мірою змінює діапазон застосування сітьових моделей, хоча сам процес їх побудови, є дуже цінним фактором розуміння проблеми.
Моделі на основі теорії управліня напрвлені на комунікацію системи користувач- комп’ютер, причому користувач розглядається як елемент в контурі зворотнього зв’язку. Система розглядається в широкому аспекті, окремі деталі інтерфейса, наприклад конструкція дисплея, не враховується, що зменшує корисність такого підходу для розроблювачів системи інтерфейса СППР. Моделі такого типу застосовуються для прогнозування загальної ефективності системи користувач- комп’ютер в середовищі задачі безперервного керування і контролю.
Моделі на основі теорій рішень моделюють поведінку користувачів в контексті прийняття рішень. Для цього потрібно створити набір можливих станів навколишнього середовища з відповідними очікуваними імовірностями і набір можливих рішень (напрямків дій) разом з іншими сподіваними значеннями та вартістю для різних елементів набору станів, аналізуючи значення і вартість на множині визначених станів. За допомогою моделі можна вибрати траекторію дій. Моделі на основі теорії рішень використовуються для одержання рекомендацій за опитувальними рішеннями або для опису поведінки користувачів в сфері прийняття рішень.
Моделі обробки інформації людиною передбачають інтенсивний аналіз розв’язуємої задачі і протоколів, які поступають від ОПР в процесі рішення задачі. Для цього потрібно охарактеризувати: середовище задач, включаючи саму проблему і наявні засоби її розв’язку; простір станів, використовуваний суб’єктом для представлення проблеми і вивідного рішення її; розроблену процедуру для досягнення рішення.
Потенційні можливості таких моделей досить високі для інтеграції обробки інформації людиною при розробці та застосуванні систем. Але в зв’язку з тим, що відношення з тим, що відношення між вимогами задач і можливостями та обмеженнями людини не досить вивчені, то існуючі моделі або дуже спеціалізовані, або досить детальні.
Моделі комп’ютерних ситем орієнтовані на опис поведінки комп’ютерного компонента інтерактивної системи, а детальний опис поведінки користувача в них відсутній. Тому ці системи, як правило, націлені на прогнозування часу реакції системи, потребу в ресурсах центрального процесора і пам’яті, вимоги до підсистеми вводу-виводу. По них можна визначити, чи задовольняє пропонована система вимоги користувачів щодо часу реакції та інших сумарних характеристик системи. Моделі такого типу не завжди потрібні для визначення вимог до користувача.
Дата добавления: 2015-11-14; просмотров: 56 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| Суть і стратегія макетування СППР | | | Вибір методів |