лучшие книги по экономике
Главная страница

Главная

Замовити роботу

Последние поступления

Форум

Создай свою тему

Карта сайта

Обратная связь

Статьи партнёров


Замовити роботу
Книги по
алфавиту

Б
В
Г
Д
Е
Ж
З
И
К
Л
М
Н
О

системи підтримки прийняття рішень

Страницы [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ]
[ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]

 

Розділ 5

Базові компоненти систем підтримки прийняття рішень

5.1. Архітектура СППР та суміжні питання


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

  • Інтернет (Internet), який уможливлює з’єднання окремих індивідів у планетарному масштабі;
  • Екстранет (Extranet), що забезпечує зв’язок окремих компаній між собою.
  • Інтранет (Intranet), який призначений для з’єднання індивідів усередині компаній.

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


Рис. 5.1. Загальна архітектура СППР
Як буде показано далі в цьому розділі, головним компонентом у проекті СППР є інтерфейс користувача. До інструментальних засобів для побудови інтерфейсу користувача належать: симулятори інтерфейсу, СППР-генератори, інструментальні засоби запиту і звітів, пакет розроблення кінцевого користувача (front-end). Інтерфейси користувачів СППР можуть бути безпосередньо у клієнтів за архітектури «товстого клієнта» (thick-client) або доставлені мережею, використовуючи Web-сторінки чи Java applets (Java-додатки), в архітектурі «тонкого клієнта» (thin-client). Архітектура «тонкого клієнта», де користувач взаємодіє з використанням Web-сторінок, має багато переваг, але донедавна витонченість інтерфейсу користувача була обмежена принципами архітектури «товстого клієнта», коли програма зберігається в комп’ютері користувача СППР.
База даних СППР є сукупністю даних, які організовуються для легкого доступу до них і аналізу. Великі бази даних у СППР мас-штабу підприємств (корпоративних СППР) часто називають сховищами даних або вітринами даних. Документи або неструктуровані дані зберігаються інакше, ніж структуровані дані. Web-сервери забезпечують потужну платформу для неструктурованих даних і документів. Архітектура для структурованої бази даних СППР в орієн­тованих на дані СППР часто включає кілька серверів, спеціа­лізовані апаратні засоби і в деяких випадках програмне забезпечен­ня як багатовимірних, так і реляційних баз даних. Розроблено бага­то ефективних методів виділення, перетворення, завантаження й індексації структурованих даних у СППР, а також є багато стратегій інжинірингу великих обсягів даних, якими є сховища даних.
Математичні моделі і аналітичні інструментальні засоби є важливою складовою багатьох СППР, особливо орієнтованих на моделі. Програмне забезпечення керування моделями може бути централізовано розміщеним з базою даних на сервері або специфічні моделі можуть розміщатися в комп’ютерах клієнтів. Додатки Java applets і програми JavaScript забезпечують могутні нові засоби доставлення моделей до користувачів в архітектурі «тонкий клієнт».
Архітектура СППР і мережеві компоненти стосуються того, як апаратні засоби організовуються, як програмне забезпечення і дані розподіляються в системі і як компоненти СППР інтегровані й фізично з’єднані. Наявність чітко визначеної і добре комунікованої архітектури системи підтримки прийняття рішень забезпечує організацію значними перевагами. Вона допомагає співпраці розробників та сприяє вдосконаленню планування і виконання окремих кроків створення СППР.
Уся архітектура СППР має бути поданою у вигляді діаграм і бути зрозумілою перед тим, як прийматимуться конкретні рішення. Тип архітектури залежить від СППР. Маломасштабні СППР, розроблені індивідами для їхнього власного використання, не потребують зусиль стосовно вищого архітектурного планування, хоча загальна архітектура інформаційної системи організації може впливати на можливості настільної СППР. Корпоративні (широкомасштабні) СППР вимагають ретельного планування архітектури для того, щоб вони мали успішне завершення. Слід за-уважити, що поки що не створені єдині стандарти архітектури СППР, різні автори трактують це поняття по-своєму. Базовими типами архітектур систем підтримки прийняття рішень є: «мережа», «міст», «сандвіч», «башта», які докладно описані в [35].

5.2. Компоненти користувацького інтерфейсу

5.2.1. Призначення та загальні ознаки
користувацького інтерфейсу

Важливість та ефективність
користувацького інтерфейсу СППР

Комп’ютерні системи підтримки прийняття рішень призначені для розв’язування завдань користувачами, а тому невіддільною складовою їх роботи має бути точне дотримання вимог щодо деяких параметрів, здобутих від користувачів, урахування їх побажань за проектування системи. При цьому, якщо система функціонує коректно, але подає результати у спосіб, який є незручним для користувача, то роботу такої системи не можна вважати задовільною (людському фактору за створення СППР приділяється головна увага). Загальне побажання користувачів полягає в тому, щоб зі складними інформаційними системами можна було працювати успішно, обминаючи тривалий і дорогий етап навчання. Усе це зумовлює ряд вимог та особливостей щодо побудови користувацького інтерфейсу СППР.
Фактично для ОПР система підтримки прийняття рішень — це інтерфейс користувача. Він охоплює всі механізми, якими команди, запити і дані вводяться в систему підтримки прийняття рішень, так само як і всі методи, якими результати чи будь-яка інша інформація виводяться системою. Якщо ОПР не має доступу до моделей і даних і не може легко переглядати результати, то система не може забезпечувати підтримку рішень. Тому, якщо інтерфейс не відповідатиме їхнім потребам і очікуванням, то ОПР часто повністю відмовлятимуться використовувати систему незалежно від потужності моделювання або придатності даних.
Ефективний інтерфейс користувача є важливим компонентом СППР будь-якого типу, але він особливо важливий для систем, які використовуватимуться безпосередньо менеджерами. У системах підтримки прийняття рішень інтерфейс користувача інколи називають діалоговим або «фронт-кінцевим» компонентом. Дехто міг би запитати: «чому інтерфейс користувача або компоненти діалогу СППР так важливі?» Дослідження показують, що коли інтерфейс СППР легкий у використовуванні, то більшість людей розглядає систему як «дружню в користуванні» і тому більшою є ймовірність того, що менеджери дійсно використовуватимуть СППР.
Інтерфейс користувача — це фактично те, що менеджери бачать і використовують, коли вони взаємодіють з СППР. Можна дати конкретніше визначення: інтерфейс користувача — це ряд меню, піктограм, команд, форматів графічного дисплея і/або інші презентації, які забезпечуються відповідною програмою, щоб дати змогу користувачеві мати зв’язок з СППР і використовувати її.
Інтерфейс користувача пов’язаний також з апаратними засобами і програмним забезпеченням, яке створює зв’язок і взаємодію між користувачем СППР і комп’ютерним процесором. Він містить відповіді й різні графічні, звукові, сенсорні та інші засоби. Еволюція механізмів людино-машинної взаємодії показана в табл. 5.1.

Таблиця 5.1

ЕВОЛЮЦІЯ РОЗВИТКУ МЕХАНІЗМІВ
ЛЮДИНО-МАШИННОЇ ВЗАЄМОДІЇ

Покоління ЕОМ

Характерні особливості користувацького інтерфейсу

Перше
(1948—1955 роки)

Складний формальний стиль взаємодії; людина мала пристосовуватися до машини

Друге
(1956—1963 роки)

Виявлення уваги до ергономіки користувацького інтерфейсу; створення деяких засобів графічного діалогу (імітаторів); застосування природної мови для виведення інформації

Третє
(1964—1971 роки)

Поява примітивних (клавіатурних) засобів діалогу природною мовою, стандартних або формальних інтерактивних механізмів; зростання доступності графічних засобів

Четверте
(1972—1979 роки)

Перехід до епохи орієнтації на користувача. База даних. Персональні комп’ютери як «слуги» чи «партнери» користувачів

П’яте
(1980—1987 роки)

Ера експертних систем. Недорогі графічні інтерфейси. Інтегровані системи формального діалогу; досить розвинені системи з природною мовою; простота в користуванні, «дружність до користувача»

Шосте
(після 1988 р.)

Злиття штучного інтелекту і людино-машинного діалогу, очікування появи «розумних» комп’ютерів, здатних розпізнавати ситуації інтуїтивним способом, робити індуктивні висновки та навчатися

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

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

  • формальний діалог, що ґрунтується на «кмітливості» ком-п’ютера з урахуванням його структури як віртуальної машини;
  • природна мова, яка відбиває особливості мислення конкретної людини, у результаті чого мова реалізується на лінгвістичній основі подання знань, комунікації і логічного висновку;
  • графічний діалог, що відтворює задану предметну галузь, зок­рема, із застосуванням піктограм (графічних зображень об’єктів чи дій). Останні мають деякий сенс для користувача, а в комп’ютері — це просто розміщення маркера.

Комп’ютер «надає перевагу» модальності формального діалогу, причому найперші обчислювальні системи розроблялися виключно для експертів з обчислювальної техніки; такі системи не мали ознак «дружності до користувача» і вимагали від серйозних користувачів знань однієї чи кількох мов програмування. Проте людям зручніше працювати з простішими в користуванні формальними засобами мовного інтерфейсу (меню, заповнення форм тощо), а також із графічними інтерфейсами і звичайною мовою.
Формальна і природна мови, графіка, а також різні комбінації цих елементів являють собою альтернативи для створення користувацьких інтерфейсів. До окремих інтерфейсних механізмів і критеріїв належать вибір із меню, кульковий маніпулятор (trackballs), керування за допомогою команд голосом, підказування голосом, клавішні керування курсором, клавіші фіксованих функцій, скролінг (вертикальні чи горизонтальні переміщення зображень у вікні екрана), керування вікнами на екрані дисплея, використання динамічних (електронних) таблиць, миша, визначені користувачем функціональні клавіші, сенсорні екрани та ін.
Важливою темою за створення сучасних користувацьких інтерфейсів є їхня адаптованість. В основу ідеї побудови адаптивних інтерфейсів покладено концепцію створення адаптивних програмних засобів, які можуть пристосовуватися до умов функціонування, непередбачених на етапі розроблення систем.
Стосовно створення інтерфейсу користувача СППР слід зазначити: кожна людина, яка працює з комп’ютером, має улюблені синоніми команд, свою інформацію, пристосовану до власних потреб, ураховуючи свій рівень знань, інтересів і навіть самопочуття в конкретний період доби. Ці фактори враховуються за побудови користувацьких інтерфейсів інформаційних систем, тобто ОПР надається можливість вносити до системи зміни, зумовлені особистісними сприйняттями інформаційного середовища. Незважаючи на те, що існують певні складності й технічні труднощі зі створенням і застосуванням адаптивних інтерфейсів (вони не можуть бути придатними до всіх ситуацій), перспектива їх упровадження в СППР може вважатися реальною.
Загальні висновки щодо
користувацького інтерфейсу

Висновок про те, якому методу чи стилю користувацького інтерфейсу слід віддати перевагу, чи існує взагалі найпріоритетніший варіант інтерфейсу, значною мірою залежить від контексту рішень, предметних галузей, користувачів і завдань, що належать до цього процесу.
В інтерфейсах, які працюють під керуванням меню, можливі цілі СППР мають бути цілком передбачені розробниками системи, тобто бути вмонтованими чи заданими завчасно. У системах інтерфейсу на формальній мові користувачеві надається більше можливостей для досягнення цілей, поставлених перед СППР, але це досягається за рахунок вивчення кількох командних мов на рівні операційної системи чи на рівні робочих програм. Природна мова нині пробиває собі дорогу як потенційний життєздатний, робастий і складний інтерфейс для задоволення найвимогливіших потреб користувача.
Цінність графіки й кольору безпосередньо пов’язана з тим, наскільки ці елементи підтримують розв’язання завдань у СППР, зокрема, як вони впливають на якість та час прийняття рішення, використання інформації і на сприйняття користувача. Неодноразово було доведено, що режим подання дійсно впливає на ефект сприйняття та усвідомлення цінності інформації, але за чітко окреслених умов. Використання графіки зумовлює скорочення часу, необхідного для розв’язування задачі лише в тому разі, коли засоби одержання графічного звіту безпосередньо сприяють розв’язанню поставленої задачі. Багатокольорові протоколи ство­рюють певні переваги, але також за певних умов.
Iнтерфейс «користувач—система»забезпечує зв’язок ОПР із СППР та її компонентами. У свою чергу, користувацький інтерфейс має свої взаємопов’язані три компоненти або ключові аспекти:
мову дій те, що може робити користувач під час спілкування із СППР. Мова дій охоплює операції від звичайного користування клавіатурою чи функціональними клавішами та сенсорними панелями до джойстика і усних команд звичайною мовою;
мову відображення — те, що бачить користувач у результаті роботи системи. Варіанти вибору щодо мови відображення досить різноманітні: використання різних принтерів, екранів, графічних засобів, кольору, графопобудовачів, звукового виводу тощо;
базу знань — те, що необхідно знати користувачеві, щоб вести діалог із системою. Базу знань користувач може знати. Вона може бути надрукованою на папері (як посібник) або бути доступною як сукупність діалогових команд підказування (із застосуванням навчальних засобів) чи у вигляді деякої комбінації перелічених компонентів.
Питання про те, який конкретний метод чи пристрій користувацького інтерфейсу необхідний для мов дій і відображень у СППР, може розв’язуватися з двох поглядів — з погляду принципів і керуючих вказівок з проектування інтерфейсів інтерактивних інформаційних систем і з погляду врахування потреб потенційних користувачів.
5.2.2. Компоненти мови дій користувача
Мова дій (активностей) визначає форму введення, яку використовує ОПР, щоб ввести запити в систему підтримки прийняття рішень. Вона включає способи, якими користувачі отримують інформацію, подають запити про нові дані, вибирають моделі, задають чутливість і навіть отримують поштові пові­домлення. Нині використовуються вісім головних типів мов дій, короткі характеристики яких наведено в табл. 5.2.
Таблиця 5.2
ТИПИ ІНТЕРАКТИВНИХ ДІАЛОГІВ ЛЮДИНИ
З КОМП’ЮТЕРОМ У СППР


Тип діалогу

Описання діалогу

Коментар

Запитання і відповіді

Комп’ютер ставить ряд запитань, на які відповідає людина

Ініціюється комп’ютером. Для абсолютно непідготовленої особи — найменш здатний на помилки тип діалогу. З набуттям людиною досвіду стає обтяжливим

Заповнення форм

Комп’ютер подає фор­ми у вигляді бланків.
Людина заповнює бланки

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

Закінчення табл. 5.2


Тип діалогу

Описання діалогу

Коментар

Вибір із меню

Комп’ютер дає спи­сок альтернатив.
Людина вибирає од­ну чи кілька з них

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

Функціональні кла­віші і командна мова

Людина здійснює бажану дію натискуванням клавіш, кожна з яких — ко­манда, модифікатор команди чи значення параметра

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

Ініційована людиною командна мова

Людина набирає ко­манди, можливо, за­стосовуючи мнемо­нічну абревіатуру

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

Мова запи­тів

Людина вводить за­питання чи виконує процедури доступу до БД. Система формулює відповідь чи формує звіт

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

Природна мова

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

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

Інтерактив­на графіка

Генерування графіч­них зображень. Людина вибирає відображені об’єкти шля­хом вказівок чи іншими немовними за­собами

У разі швидкої реакції можливий досить ефективний і природний діалог, що виправдовує додаткові витрати (інтерактивна графіка відносно дорога) навіть у порівняно простих задачах (наприклад, пошук в єрархічних БД)

5.2.3. Компоненти мови
відображень (презентацій)

У той час як мова дій описує, як і якими засобами користувач повідомляє комп’ютер про необхідне оброблення, другий аспект користувацького інтерфейсу — мова відображень (показу, презентацій) описує, в який спосіб комп’ютер забезпечує отримання інформації користувачем. Звичайно, такий інтерфейс має передавати аналіз у такий спосіб, який є оптимальним для користувача. Це стосується не тільки результатів аналізу, але також і проміжних результатів на всіх стадіях прийняття рішення. Крім того, інтерфейс має забезпечувати відчуття контролю з боку людини щодо відтворюваного процесу і отримуваних результатів. Усе це має виконуватися приємним і зрозумілим способом [103].
Робота з вікнами (кадрування)
Спосіб організації інформації залежить від вигляду й типу моделей, ОПР і оточення, в якому ця особа працює. Основний принцип мови подання — вигляд форми показу інформації має бути «очищеним» і легким для сприйняття. Нині використання стандартів щодо проектування вікон для багатьох програм­них виробів забезпечує їх приємним виглядом. Зокрема, цей
стандарт відображає аналогію робочого стола, що складається з картотек. На екрані ми бачимо вікна, кожне з яких являє собою різний вигляд виведення даних. Одне вікно, наприклад, може містити діа-граму, друге — електронну таблицю, а третє — текст допомоги користувачеві. На рис. 5.2 зображений приклад багатовіконного екрана. Використання кількох вікон для окремих видів інформації виділяє різні аспекти остаточного рішення.
Проектувальники мусять, однак, утримуватися від розміщення надмірної кількості вікон відразу на екрані, оскільки він стає загромадженим, дуже багато речей стають втраченими, і стає важче розглядати перспективу розв’язання проблеми загалом. Замість цього, якщо застосування дає змогу, то проектувальник має використати піктограми, щоб показати різні опції, як це ілюструється на рис. 5.3. Коли користувачі хочуть дослідити певний аспект проблеми, то вони можуть просто клацнути на відповідній піктограмі, щоб розкрити його для детального розгляду. Користувачам мають надаватися повні, але не завалені «робочі столи», метушня не має бути властивою застосуванню СППР.

Рис. 5.2. Приклад режиму багатовіконного
подання прийнятого рішення

Рис. 5.3. Піктограмні опції
Зображення (образи)
Найзагальніше завдання виведення даних — показати результати деякого аналізу. Нехай, наприклад, мета полягає в тому, щоб показати збут у різних регіонах минулого року. Відповідна форма виведення даних залежить від того, що творець рішення сподівається робити з інформацією. Якщо ОПР просто хочуть знати, як різні зони збуту відповідають їхнім сподіванням, то вони могли б оцінювати результати, використовуючи зображення різних мордочок (metri-glyphs), як наприклад, показано на рис. 5.4. Ті з «облич, що усміхаються,» показують сприятливий збут, у той час, як «сумні обличчя» відображають протилежне. Разом із цим, чим більша усмішка, тим більше збут перевищив сподівання, і, навпаки, чим сумніша гримаса, тим гірші результати.

Рис. 5.4. Мордочки (Metri-glyphs)
Можна навіть пов’язати одну множину результатів з «усмішкою», іншу — з «очима» обличчя. Наприклад, якщо усмішка відображає рівень прибутку, то очі могли б означати рівень дивідендів. Закриті очі асоціювалися б з невиплатою дивідендів, у той час, як ступінь відкритості очей міг би означати їх величину. Звичайно, не всі творці рішень (або не всі культури) розуміють переваги використання metri-glyphs, як одного із способів виведення даних.
Якщо мета аналізу полягала у визначенні місць, де збут був найбільший, то ми могли б показати це на карті різними штрихами або кольорами, як позначками місцевостей з відповідними результатами. Якщо метою аналізу було визначення динаміки збуту за окремі роки, то найбільш відповідним форматом виведення даних було б традиційне графічне подання результатів. Графік дає змогу точніше побачити, наскільки деякі зони збільшили збут, у той час як інші зменшили, а також визначити відносні оцінки (як наприклад «значно більше» або «незначно»).
З іншого боку, якщо ОПР хотіла б мати фактичні обсяги для обчислення збуту протягом деякого періоду, то графічне зображення не зовсім відповідає цьому завданню через те, що важко зібрати з різних джерел дані про збут. У такому разі таблиці надходжень є кориснішою формою виведення результатів.
Звичайно, інколи відповіднішою формою виведення даних могла б бути анімація (мультиплікація) і/або відео, ніж статичне відображення на екрані. Наприклад, якщо завдання полягає у моделюванні банку і в моделі змінюється кількість клерків, типів оброблених кож­ним з них послуг і кількість черг, то з метою виявлення впливу
кожного з цих факторів на довжину черги анімація черг могла б бути ілюстративнішою, ніж наведення статистичних даних.
Персональне монопольне
володіння аналізом

На додаток до надання можливості виводити відповідного типу результатні дані під контролем ОПР проектувальники мають надати користувачам право персонального монопольного володіння аналізом, тобто відчуття того, що вони контролюють процес здійснення аналізу і, отже, їх вибір є повноважним. Ком-п’ютерні новаки не можуть відчувати власної участі у формуванні відповіді через те, що в них складається враження нібито це було «зроблено комп’ютером», а не ними.
Один із шляхів протидіяння цій тенденції — забезпечити користувачів легким засобом змінювати вид аналізу, якщо результати не відповідають запиту деякою мірою або цілком. Це досягається за рахунок розміщення на екрані кнопок, які відповідають різним варіантам аналізу. Наприклад, обчислення рівня рентабельності продукції можна виконувати двома шляхами: ураховуючи чи не враховуючи дисконт-фактор. Отже, користувач сам має вибирати форму аналізу, натискуючи одну з двох відповідних кнопок вікна. Або коли середня величина деякого показника може бути отримана автоматично, користувач може захотіти протестувати чутливість моделі сам, а не отримуючи відповідні результати автоматично, «всліпу». Тому має бути клавіша, яка давала б змогу переглядати доречні статистики на різних горизонтах часу.
Діаграми і зміщення
Оскільки необхідною умовою є об’єктивне використання моделей користувачами, то також важливо забезпечити їх неупередженим виведенням даних. Зміст і спосіб виведення інформації проектувальниками може вплинути на те, як вона сприймається творцем рішення. Звичайно, проектувальники не будутьнавмисно спотворювати систему презентації, щоб забезпечувати тим самим упереджені результати. Однак, небезпечніша проблема виникає тоді, коли спотворення з’являється ненавмисно.
Нехай, наприклад, користувач аналізує управління двома об’єк­тами, досліджуючи середню щоденну їх продуктивність. Якщо система виведення надає лише середні значення продуктивності, то при цьому може появитися упереджене сприйняття виведення даних через те, що середні значення не допомагають користувачеві повною мірою бачити значимість показників. Скажімо, середня продуктивність у першому об’єкті може бути 6000 одиниць, а в другому — 8000. Ця різниця на перший погляд є суттєвою. Проте якщо одночасно система покаже, що середнє квадратичне відхилення щоденної продуктивності дорівнює 2000, то різниця не буде здаватися такою великою.
Інша проблема виникає тоді, коли проектувальники із-за неуваж­ності допускають зміщення в результатах, що відображені на діаг­рамах. Так, частіше за все творці рішень дивляться на діаграми, щоб одержати швидке враження від значень даних. Але часто таке враження знаходиться під впливом виду графіка, зумовленого, зокрема, різницею в масштабуванні координат. Наприклад, за допомогою простого збільшення масштабу осі абсцис графік може складати враження значно вищого темпу зростання за той же період. Аналогічно збільшення масштабу осі ординат робить рівень зростання немов би набагато меншим (графік розтягується). Проектувальник мусить надати допомогу користувачеві, пояснивши, що подібне неадекватне висвітлення відбувається завдяки неправильному вибору одиниць вимірювання системи координат. Це також стосується і використання стовпчикових діаграм.
Іншим факторам, який може призвести до ефекту зміщення для творців рішень, є відсутність агрегації показників за створення гістограм чи кругових діаграм. З другого боку, агреговані значення можуть часто давати змогу творцям рішень узагальнювати неправильні дані. Важко перерахувати всі спотворення і зміщення, які можуть мати місце в діаграмах, однак розуміння досліджуваної проблеми може допомогти уникнути ефектів зміщення результатів у проекті СППР.
5.2.4. Роль знань у користувацькому інтерфейсі
База знань або низка знань, що належить до інтерфейсу користувача, містить всю інформацію про систему, котру користувач мусить знати, щоб використовувати її ефективно. Ці знання стосуються того, які є команди для виконання операцій системи, щоб включити одне, ввести інше, вибрати опції чи змінити їх. Ці команди подаються на розгляд користувачам різними шляхами. Попередня підготовка для використання системи могла б бути індивідуальною чи груповою, включати тренінг з клавіатурою та концептуальну підготовку. На додаток до цього тренінгу, звичайно, є можливість використовувати деякі позаекранні підказки і екрани допомоги з додатковою інформацією.
Загальна мета створення користувацького інтерфейсу полягає в тому, щоб зробити систему як можна простішою, щоб уможливити користувачам найповніше використання програмного забезпечення. Такий засіб має забезпечувати як досвідчених, так інедосвідчених користувачів, щоб надавати потрібну допомогу, зокрема, щодо застосування специфічних методів і моделей. Користувачі, зазвичай, не є фахівцями в статистичному чи фінансовому моделюванні, математичному програмуванні тощо. Їм потрібна допомога у формуванні їхніх моделей і використанні їх у належний спосіб. Така допомога має міститися в системі.

Страницы [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ]
[ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]


ВНИМАНИЕ! Содержимое сайта предназначено исключительно для ознакомления, без целей коммерческого использования. Все права принадлежат их законным правообладателям. Любое использование возможно лишь с согласия законных правообладателей. Администрация сайта не несет ответственности за возможный вред и/или убытки, возникшие или полученные в связи с использованием содержимого сайта.
© 2007-2019 BPK Group.