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

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

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

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

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

• Які типи завдань щодо збирання інформації зобов'язані під­тримувати супроводжуючі штатні працівники?

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

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

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

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

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

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

Є багато способів проведення опитувань і кожен із них забезпе­чує різні види інформації щодо визначення концепцій, проблем, рі­шень, етапів розв'язання проблем. Опитування може бути структу-рованим, неструктурованим та фокусованим (цілеспрямованим). Інтерв'ю може здійснюватися шляхом вивчення прикладів (case studies) або аналізу протоколів. І нарешті, можна використовувати деякі інструментальні засоби, як наприклад, упорядкування карток.

Структуроване опитування — це опитування, за якого всі за­питання розміщені у визначеному порядку. Той, кого опитують, надає лаконічні відповіді на поставлені для отримання специфіч­ної інформації запитання.

фокусоване опитування, з іншого боку, є відносно неструкту-рованим. У такому разі інтерв'юер також має низку запитань, що розміщені у визначеному порядку, але вони загальніші і дають змогу відповідачеві вести обговорення у відповідному напрямі.

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

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

Для того, щоб ідентифікувати більше інформаційних потреб, проектувальники уважно досліджують специфічні види рішень шляхом вивчення прикладів (case studies). Зокрема, вони можуть виявити деякі інформаційні потреби, вивчаючи концептуальні й теоретичні засади прийняття рішень, наприклад, у бізнес-класах.

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

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

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

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

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

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

— логічні блок-схеми, які використовуються для ілюстрації проходження даних через систему (програму) і місцезнаходжен­ня процесів прийняття рішень і керуючої логіки;

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

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

Оболонки (альбоми) сюжетів. Моделі екранних зображень і оболонки сюжетів (низки копій екранних зображень) являють со­бою найкорисніші моделі, як такі, що дають можливість проде-

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

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

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

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

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

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

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

Є кілька важливих показників ефективного інтерактивного ПЗ, головними з яких є:

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

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

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

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

5) використання загальноприйнятих стандартів програмуван­ня в інженерії систем.

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

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

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

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

У разі прийняття рішень стосовно вибору апаратної бази СППР часто має місце передчасність розв'язання цього питання: тип ЕОМ, а нерідко і периферійні пристрої, і вся конфігурація зага­лом вручаються розробнику як визначені і розв'язані питання на самому початку проектування. Тому доводиться підганяти СППР до апаратної бази, хоча ідеальною є протилежна стратегія — вибирати апаратні засоби після встановлення вимог і моделювання системи.

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

Вимоги до системи і програмне забезпечення мають підтримува­тися ввідними пристроями. Є різноманітні альтернативні засоби введення, але не всі вони можуть підходити до конкретних застосу­вань. Розроблювачі мають також різноманітні альтернативні типи відображень. У більшості застосувань СППР виникає необхідність отримання твердих копій; наявні засоби, як правило, уможливлю­ють це та задовольняють вимоги стосовно показника «вартість— ефективність». Важливе значення для успіху системи має загальний людино-машинний інтерфейс. Оптимальне проектування інтерфей­су для СППР потребує участі спеціаліста з інженерної психології.

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

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

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

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

8.3.2.8. Передавання системи

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

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

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

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

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

8.3.2.9. Оцінювання системи

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

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

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

8.3.2.10. Зворотний зв'язок

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

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

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

8.4. Впровадження та оцінювання СППР

Впровадити СППР означає реалізувати заплановану систему. Реалізація включає трансформацію проекту в коди, але це виходить далеко за межі програмування. Вона також включає створення та початкове завантаження бази даних і бази моделей та керування кінцевим продуктом, яке передбачає інсталяцію (установку), введення в дію, компоновку та реальне випробуван­ня. Ще одним аспектом упровадження СППР є навчання корис­тувачів та забезпечення того, щоб вони сприймали СППР як ко­рисний та надійний інструментальний засіб. І нарешті, оціню­вання включає всі ті кроки, які б гарантували, що система здійс­нює те, що потрібно, і виконує все добре. Ці питання докладно описані в [103]. Змістовна інформація та джерела з приводу впро­вадження та оцінювання СППР розміщені на Web-сторінці — http://www.umsl.edu/~sauter/DSS/impl.html. Стисло розглянемо пи­тання впровадження та оцінювання СППР.

8.4.1. Стратегії впровадження

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

8.4.1.1- Досягнення добрих кондицій СППР

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

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

8.4.1.2. Додержуватися простого розв'язання

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

Більшість потреб щодо прийняття рішень не є «простими». В такому разі СППР не може бути спроектована просто. Однак, си­стема з погляду потреб ОПР має бути простою. Взагалі користу­вачам не потрібно докладно знати про виконання операцій сис-темою. Підхід до розв'язання проблеми і необхідні для цього

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

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

Поиск по сайту: