Технічна відповідність (придатність)

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

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

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

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

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

Мета цього тесту — визначити, чи забезпечує система потріб­ні поради і аналіз, що є сумісними з тими, які міг би зробити до­свідчений аналітик. Перед тестом експерта-аналітика просять прокоментувати рішення або пояснення для ситуації, яку ОПР

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

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

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

зв'язку) з корисністю СППР, а отже, не забезпечує надійності вимірювання ефективності системи.

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

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

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