Глава 14
Оцінка практичності
Основний елемент розробки програмного продукту і ПІ - тестування за участю користувачів. Якщо продукт задовольняє вимогам до практичності й інших критеріїв, він передається клієнтам. Якщо продукт не відповідає критеріям, він допрацьовується в ході чергової ітерації.
У процесі проектування і реалізації ПО клієнти звичайно знайомляться із сис-темой за допомогою презентацій, специфікацій, демонстрацій і завчасної установки програм. Презентації, специфікації і демонстрації дають загальне пред-ставление про функції і стилі ПІ продукту, однак ці способи недостатні для того, щоб дати користувачам глибоке розуміння особливостей повсякденної експлуатації продукту.
Дострокова установка програм надає клієнтам досить часу, что-бы одержати враження і відчуття від використання продукту в робітничому середовищі. Однак проблеми з термінами початку використання продукту можуть виявитися пре-пятствием для задовільної резолюції. Потенційне рішення цієї проблеми полягає в завчасному і безупинному тестуванні продукту на практичність з використанням різних методів (мал. 14.1).
У даній главі описується ряд методів оцінки практичності. Ці методи на-правлены на те, щоб дати можливість проектній бригаді підготуватися до проведення оцінок практичності продукту разом з користувачами, проаналізувати результати цих оцінок і належним чином відреагувати на них. Один розроблювач при іспитах практичності на підприємстві замовника якось сказав: "Що ж тут такого важкого?" Для проектної бригади, серйозно зацікавленої в тім, щоб розробляти продукти, що приносять користувачам велике задоволення, відповідь нескладна - якщо застосувати потрібні навички і методи.
У даній главі розглядаються наступні теми.
" Мети оцінки.
" Види оцінок.
" Підготовка до проведення оцінки.
" Проведення оцінки.
" Оцінка даних.
" Участь розроблювачів.
" Коротко про перевірку за столом.
" Продовження обговорення проекту.
Важливо нагадати, що практичність, чи загальний рівень задоволеності користувачів, залежить від багатьох факторів.
Корисне правило. У залежності від задач і навичок кінцевих користувачів, практичність ПО- це функція можливостей, ПІ, продуктивності, надійності, простоти установки й інформаційної підтримки продукту.
Перераховані перемінні є базовими факторами. Якщо їх адекватно не забезпечити, розробка системи з великою імовірністю ризикує виявитися непрак-тичной, у результаті чого користувачі і замовники будуть незадоволені продуктом. Збір користувальницьких відгуків по кожному з цих факторів важливий для причинного аналізу проблем і загальної оцінки практичності. У залежності від характеру продукту важливу роль для загальної практичності можуть грати й інші фактори.
Оцінка практичності висуває наступні основні мети.
" Прогнозування користувальницької задоволеності.
" Аналіз підходів, зв'язаних із зовнішнім виглядом, поводженням і користувальницькою взаємодією.
" Виявлення і дозвіл проблем.
" Перевірка критеріїв.
" Конкурентна оцінка.
Оцінки призначені для визначення рівня короткострокової і довгострокової практичності. З погляду проектної бригади, існує безліч проектних альтернатив для програмного інтерфейсу, тому важливо одержати відповіді користувачів на проектні питання і вибрати відповідні підходи до проектування. Крім того, звичайно корисно, щоб користувачі у відповідь на отриману проектну інформацію направляли дії розроблювачів і підтримували їх своїми радами. Головна мета ітеративної розробки - поступове удосконалення продукту. У залежності від цілей розробки і розвитку продукту можливе застосування різних методів оцінки.
Види оцінок
Методи оцінки практичності- перегляд (Revіew), наскрізний контроль (Walk-Through), лабораторні іспити при участі типових користувачів (Lab-Based Test), іспиту на площадці замовника при участі реальних замовників (Іn-Your-House Test) і експлуатаційні іспити (Fіeld Test) - багаторазово описані в ли-тературе. Оцінки проводяться при участі експертів, користувачів і інших заинте-ресованных сторін.
Неформальний перегляд. Виконання оцінки продукту при відсутності структурного чи підходу заздалегідь визначених критеріїв, інструкцій і методів називається неформальним переглядом. Перегляд виконується з використанням документації, чи прототипу реального продукту. Кожен експерт визначає видимі проблеми в неформальному стилі. Неформальний перегляд можна розглядати як інтуїтивний аналіз.
Корисне правило. Варто уникати неформальних переглядів на користь структурних методів.
Евристичний перегляд. Існують критерії, інструкції і методи оцінки практичності продукту, документально зафіксовані в різних друкованих матеріалах. Інструкції з проведення оцінок називаються чи евристиками емпіричними правилами. Багато хто з них наближаються до проектних принципів і носять суб'єктивний характер. Приклад евристики- мінімальне завантаження пам'яті користувачів.
Евристичний перегляд можна представити як перегляд проектних чи рішень програмного коду, проведений колегами. Однак існує чимало труднощів, зв'язаних з визначенням того, що є прийнятним з погляду вимог, проекту і реалізації.
Корисне правило. Установите об'єктивні евристики, ґрунтуючись на це-лях, принципах і інструкціях, заданих для проекту, а також на распространен-ных галузевих евристиках і процедурах оцінки.
Для підвищення ефективності евристичних оцінок вони перетворяться в об'єктивні інструкції. У ході евристичного перегляду продукт оцінюється по засобом аналізу документації, чи прототипи роботи реальних кінцевих користувачів. Оцінку з використанням розповсюджених чи евристик процедур виконує один чи трохи експертів.
Наскрізний контроль. Метод, що дозволяє здійснити інспекцію продукту за допомогою виконання в покроковому режимі сценарію роботи кінцевого користувача, називається наскрізним контролем (чи прогоном). Наскрізний контроль виробляється одним чи декількома експертами з використанням документації, чи прототипів продукту. Практична оцінка продукту - переконливий метод. Наскрізний контроль можна також проводити з кінцевими користувачами, з якими встановлюється зворотний зв'язок.
Традиційні іспити на практичність. Традиційні і формальні оцінки практичності продукту проводяться в лабораторному середовищі, оснащеної телекамерами, магнітофонами, однобічними дзеркалами й іншим подібним устаткуванням. Однак не менш ефективні неформальні оцінки практичності з користувачами і ведучим тестування фахівцем у чи офісі конференц-залі.
При виконанні оцінок, заснованих на сценаріях передбачуваного использова-ния, яким мається на увазі суб'єктом іспитів є типовий користувач. Тривалість тестування (тобто перевірка особливостей початкового періоду обу-чения і використання) може коливатися від декількох годин до одного дня. Расши-ренное тестування на більш пізніх етапах життєвого циклу продукту може продовжуватися від декількох днів до декількох тижнів і корисно при оцінці довго-тимчасового використання продукту. Користувачі виконують задачі й одночасно відповідають на питання анкети. У загальному випадку, що визначає питання, що задається користувачам, звучить так: "Що ви думаєте про цей продукт?"
Порівняльні оцінки практичності. Багато видів оцінок практичності проводяться в автономному режимі. Ці тести корисні при вивченні базової практичності продукту. Однак такий тип тестування не завжди дає можливість зрозуміти, як продукт витримує порівняння з практичністю інших продуктів, що можуть застосовувати чи користувачі до яких у них мається доступ.
З цієї причини надзвичайно корисно, порівняльне тестування. Пользовате-лям вручають сценарій для виконання задачі з застосуванням кожного з оцінюваних продуктів. По завершенні кожного сценарію і тесту користувачів просять указати найбільш кращий продукт. У загальному випадку, що визначає питання звучить так: "Яку марку ви предпочитаете -А чи Б?"
Порівняльні оцінки корисні для визначення можливостей і методів, що дають продукту конкурентна відмінність і конкурентна перевага. Для про-ектной бригади, що наміряється перевершити конкурентів, порівняльне тестування допомагає установити, які фактори найбільш важливі для користувачів. Цей тип оцінки служить серйозним іспитом, що дозволяє визначити, наскільки продукт гарний у порівнянні з конкуруючими продуктами, і додає новий зміст знеособленому проектуванню ПІ.
Іспиту на площадці замовника. Унаслідок того, що можливості лабораторних іспитів, як правило, обмежені, іноді зручно проводити оцінку практичності на площадці замовника. Реальні клієнти грають при цьому роль суб'єктів практичного тестування продукту. Аналогічно формальному і неформальному оцінюванню практичності, користувачі дають відповіді на питання анкети, наданої їм при тестуванні.
Оцінка повинна бути запланована якомога раніше в рамках життєвого циклу розробки продукту. Ціль у даному випадку складається в оцінці продукту з залученням широкого і представницького кола кінцевих користувачів з числа клієнтів. Реально оцінка проводиться в робочих офісах замовника в спеціально виділеній кімнаті. Очевидно, що більш доцільно проводити оцінки в реальних робочих приміщеннях замовника на робочих місцях кінцевих користувачів.
У загальному випадку, що визначає питання звучить так: "Як виглядає пропонований продукт у порівнянні з тим, що мається у вашому розпорядженні?"
Експлуатаційні іспити. Проведення іспитів на площадці за-казчика дуже схоже на експлуатаційні іспити, за винятком того, що замість бета- чи остаточної версії продукту використовується чи імітація прототип. Експлуатаційні іспити носять більш формальний, але менш структурований характер у тім змісті, що від користувачів не потрібно виконання сценаріїв. Користувачі здійснюють реальну роботу з використанням продукту і відповідають на питання більш высокоуровневой анкети, що стосується продукту.
Корисне правило. Використовуйте сценарний підхід до оцінки продукту з заздалегідь визначеними критеріями, методами і залученням користувачів протягом усього періоду розробки.
Так багато методів, так мало часу! Ніж раніш починається оцінка проектних рішень і чим раніш користувачі залучаються до оцінки, тим краще. Увага повинна бути зосереджена на тих областях, у яких найчастіше встре-чаются проблеми. Однак при проведенні оцінок найбільшу роль грають наступні фактори.
" Заздалегідь визначені й об'єктивні критерії.
" Структурні й об'єктивні методи.
" Залучення користувачів до проведення оцінок.
" Методи, що дозволяють визначити, що правильно, а що ні.
Структурні методи включають плани тестування, процедури, сценарії і правильні відповіді, зв'язані з кроками роботи й одержуваних результатів. Аналогічно проектним рішенням, іспиту практичності не дають тих самих результатів при повторенні тестів - процес відрізняється невизначеністю. Однак повторення тестів повинне давати результати, що лежать у тім же діапазоні, що і попередні результати.
Використовуючи порівняно невелику кількість суб'єктів тестування, цей тип тестування дуже корисний для ідентифікації основних проблем практичності зв'язаних з навчанням користувачів і початковим періодом застосування продукту. У залежності від типу оцінки і тривалості тестування, кількості суб'єктів тестування і повторюваності операцій у сценаріях можливий переспів оцінка практичності в розрахунку на довгострокове використання продукту.
Підготовка до проведення оцінки
Оскільки не всі колективи розроблювачів ПО можуть залучити професіоналів в області забезпечення практичності, розглянемо на прикладі, як проектна бригада готується, проводить і формує звітність по оцінці практичності. Ретельна підготовка до проведення оцінки і її виконання сприяють обґрунтованому ре-зультату, а уміння вислухати користувачів може забезпечити стійкий і якісний зворотний зв'язок з ними. Незалежно від використовуваного методу при проведенні оціню! необхідно випливати базової послідовності кроків для залучення користувачів і одержання надійних результатів (мал. 14.2).
Проект. Якщо в проведенні оцінки практичності бере участь персонал, знайомий з експериментальним проектуванням методів, можна розробити відповідний план. Складні оцінки, оцінки життєво важливого чи відповідального ПО вимагають дуже ретельного проектування. Прості оцінки, проектовані і проведені бригадою розроблювачів, можуть принести цілком заслуговують результати. Підлягаючі вивченню сторони продукту вибираються серед критичних компонентів проекту ПІ.
Евристичні оцінки також вимагають підготовки проекту. Як мінімум, необхідні самі евристики. Щоб установити контекст і оцінку розповсюджених евристик (таких як навантаження на пам'ять користувачів і погодженість), застосовують сценарії, для цієї мети також підходять критерії і правильні відповіді на питання (експерт не має намірів тестировать продукт стосовно непередбаченим цілям).
Простий, але надійний проект тестування практичності для більшості при-ложений виходить за допомогою вибору від п'яти до семи представницьких сценаріїв, що оцінюють шість користувачів від кожної з груп, що входить у загальне коло користувачів продукту. Більш складне тестування передбачає виконання користувачами аналогічних задач як із застосуванням конкурентного, так і розроблювального в рамках проекту ПО. У проведеному в такий спосіб експерименті користувачі поперемінно працюють із програмними додатками. У той час як одна група використовує проектоване ПО, друга випробує альтернативне ПО. Потім групи переключаються з одного додатка на інше і виконують ті ж задачі. Після цього результати порівнюються.
Брифінг, що випереджає оцінку. Для обговорення будь-яких аспектів оцінки учасникам настійно рекомендується провести інформаційна нарада - брифінг. Це корисно, насамперед , з погляду створення необхідної загальної атмосфери і правильного вибору контексту. Персонал, що приймає участь як чи експертів спостерігачів, інформується у відношенні цілей, ролей і процедур оцінки. Незалежно від того, чи мають користувачі доступ до проектних рішень у виді чи прототипу продукту, корисно установити сприятливу атмосферу. Перед початком тестування кожному експерту, спостерігачу і користувачу варто нагадати один фундаментальний аспект оцінки - оцінці підлягає продукт, а не користувачі.
Необхідно досягти згоди, заснованого на одержанні даних у відношенні Цілей тестування і способу використання зібраної інформації. Кожному користувачу надається доступ до системи з установленим на ній продуктом, копією всієї документації й артефактами, що стосуються продукту, а також інструкцією з виконання задач. Від користувача не обов'язково потрібно читання документації на продукт, якщо тільки одна з цілей оцінки не складається у визначенні 1 ефективності навчання за допомогою документації, що передує тестуванню, j
Корисне правило. Брифінг варто готувати так само ретельно, як і інші аспекти оцінки.
Анкетування, що випереджає оцінку. До початку оцінки здійснюється контроль рівня навичок експертів і користувачів - бажано знати, який внесок можуть внести ті чи інші фахівці в результати оцінки. Для цього проектується належна анкета, що дозволить визначити, наскільки предмет ис-пытаний відповідає передбачуваному колу користувачів. Фахівців, не вхо-дящих у передбачувану групу, немає необхідності оцінювати.
Варто задати трохи допускають різні тлумачення питань, зв'язаних із з'ясуванням того, наскільки користувач відповідає передбачуваному пользова-тельскому профілю. Ці питання складають на підставі користувальницького профілю для продукту (глава 10).
Нижче приведені приклади питань, зв'язаних з навичками.
" Як би ви оцінили рівень вашої поінформованості про мережу World Wіde Web і Web-броузерах?
" Як би ви оцінили рівень вашої поінформованості про назву заданої предметної області і її задач?
" Як би ви оцінили рівень вашої поінформованості про іншому ПО, що підтримує ці задачі?
У загальному випадку відповіді на питання анкети, що передує тестуванню, займають не більш 10 хвилин.
Корисне правило. Необхідно провести анкетування експертів і суб'єктів тестування, що стосується рівня їхніх навичок.
Сценарії і задачі. Багато додатків підтримують рішення дуже великого кола задач. Незалежно від типу методу оцінки спроба оцінити таку велику кількість задач неефективна у відношенні витрат і найчастіше в цьому немає необхідності. Як правило, у ході кожної оцінки з залученням користувачів досить розглянути від п'яти до семи найбільш важливих задач. Інші задачі додаються при аналізі потенційних проблемних областей, з якими має справу проектна бригада, чи найбільше що часто зустрічаються проблем з чи ПІ системами.
Для експертів і суб'єктів тестування обрані задачі описуються у виді дуже простий, виконуваний крок за кроком, легень для читання конкретних сценаріїв.
Варто пам'ятати, що тестуванню піддається система, а не здатність пользо-вателей читати і розуміти складні документи. Задачі упорядковуються відповідно до ймовірної послідовності їхнього початкового використання, потім уводяться рідко використовувані задачі.
Корисне правило. У випадку оцінок, заснованих на застосуванні чи прототипів реальних систем, може бути доречним почати і завершити тестування дослідницьким сценарієм, що дозволяє користувачам проаналізувати можливості системи без виконання визначеної задачі.
Анкетування по завершенні сценарію. По завершенні кожного сценарію оцінки передбачене анкетування. Анкети розробляються таким об-разом, щоб зафіксувати суб'єктивна думка користувачів в об'єктивному стилі. Для одержання всебічної оцінки системи необхідно передбачити питання у відношенні кожного основного фактора (тобто функцій, користувальницького інтерфейсу, продуктивності і т.д.). При необхідності в анкету додаються інші питання, а користувальницькі коментарі фіксуються.
Підхід до складання анкети полягає в тім, щоб представити її як серію нейтральних чи питань тверджень, відповідь на який можна дати за допомогою семи бальної шкали, у якій значення 1 відповідає найгіршому варіанту відповіді, а 7 - найкращому. Можна використовувати альтернативну шкалу, у якій значення 0 відповідає негативному відношенню, 1 - нейтральній відповіді, 2 - схваленню. Ліворуч після кожного питання залишене вільне місце для користувальницьких коментарів. От приклади питань, що задаються по завершенні сценарію.
Анкетування по завершенні іспитів. По завершенні оцінки Передбачене більш велике і деталізоване анкетування. Користувачі висловлюють своє враження від продукту як цілого, оцінюються основні, свя-занные з продуктом, фактори, а при необхідності в анкету додаються інші специфічні питання. От приклад питання, що задається по завершенні оцінки.
Яка ступінь вашої задоволеності даним додатком?
Приклад питання, що допускає різні тлумачення і спрямований на виявлення позитивних аспектів додатка, виглядає в такий спосіб.
Які три аспекти додатка сподобалися вам більше всього?
Корисне правило. Анкета, використовувана по завершенні сценарію, повинна займати приблизно двох сторінок тексту.
Питання спрямовані на збір вхідної інформації, що стосується всіх основопола-гающих факторів і негативних аспектів системи.
Збір інших даних. Крім даних, що містяться в анкетах, до базової інформації, фиксируемой при прогоні сценарію, відносяться виміри, зв'язані з такими критеріями.
" Час, необхідне для завершення сценарію.
" Кількість звертань за допомогою.
" Помилки і проблеми користувача.
" Коментарі і питання користувача.
" Місця в сценарії, де користувач був позбавлений можливості продовжувати виконання чи задачі робив серйозні помилки.
У такий спосіб збирається інша інформація, що визначена для продукту за допомогою вимірних критеріїв. Якщо суб'єкт тестування попадає в скрутне положення, координатор тестування просить користувача відобразити меню Help (Довідка) чи звернутися до іншої документації по продукті. Якщо після читання довідкової чи інформації документації користувач не може вирішити проблему, координатор тестування дає користувачу вказівки по подоланню труднощів, що потім фіксуються в списку тестових проблем.
Так багато користувачів, так мало часу. Багато фахівців почувають себе комфортно, проводячи оцінки з величезною кількістю суб'єктів тестування по усьому світі, однак існуючі цикли розробки ПО роблять тестування з великою кількістю суб'єктів непрактичним. Відома мудрість говорить, що основні проблеми практичності можна виявити при тестуванні, у якому бере участь усього лише шість суб'єктів, однак при цьому кількісні дані не дозволяють робити статистично достовірні висновки.
Корисне правило. Статистичні методи малих вибірок використовуються при роботі із шістьма чи великою кількістю суб'єктів, а вибірки обсягом 10 чи 12 спостережень можуть дати дуже гарні аналітичні результати.
Виконання оцінки практичності додатків з 10 чи великою кількістю суб'єктів тестування займає кілька календарних тижнів. Аналіз статистичних даних і анкет по завершенні роботи проводять шість суб'єктів тестування доти , поки результати, що спостерігаються, залишаються незмінними (не надходить ніякої нової важливої інформації).
Корисне правило. Якщо результати змінюються непередбаченим образом, іноді приймають проектне рішення, засноване на "копії" стану процесу в заданий момент чи часу проміжних результатах, повертаються до проекту оцінки, і/чи продовжують оцінку іншим способом.
Суб'єкти тестування. Для оцінки практичності вимагаються суб'єкти тестування, що представляють передбачуване коло користувачів продукту. Кращий спосіб роздобути подібних суб'єктів тестування- налагодити партнерські стосунки з передбачуваними замовниками.
Тестова платформа. Оцінку практичності проводять, ґрунтуючись на ранніх версіях документації, макетах, моделях, чи прототипах реальних продуктах. Оскільки ціль складається в оцінюванні продукту в цілому, варто використовувати перво-начальные прообрази таких артефактів, як інформація про продукт, комплектація, а також інші артефакти, засновані на досвіді користувачів.
Корисне правило. Використовуване для оцінок інтерактивне ПО повинно бути добре "відшліфовано" у своїй основі, перш ніж користувачі одержать до нього доступ, інакше іспиту можуть принести непередбачені негативні результати.
Замовник приходить з дуже конкретного середовища і не завжди розташований вникати в абстрактні поняття і вислухувати пояснення про тім, чому щось не працює, хоча виглядає правильно. Тестова платформа повинна задовольняти можливим сценаріям.
Координатори тестування. Кожен член проектної бригади повинний мати можливість працювати з окремими замовниками і кінцевими користувачами. Основна якість експерта - відкритість і об'єктивність у сприйнятті інформації і критики, що виходить від замовника.
Корисне правило. Ніщо не зрівняється з безпосередніми відкликаннями користувача про продукт, особливо , якщо це негативні зауваження.
Варто наполегливо прагнути до встановлення довгострокових взаємин між проектною бригадою і замовниками. Така взаємодія корисна для наступного дозволу проблем і удосконалення продукту.
Проведення оцінки
Крім планування і підготовки, проведення оцінки включає інші основ-ные кроки. Після того як матеріали й об'єкт тестування готові, бригада по оцінці продукту виконує наступні задачі. Припустимо, що планується проведення оцінки разом з кінцевими користувачами.
Організація. Необхідним образом сконфигурированные апаратні і програмні засоби встановлені. Місце проведення оцінних іспитів постачено програмним продуктом і супутньою інформацією. Анкети, інструктивна інформація і сценарії маються в розпорядженні всіх суб'єктів, що беруть участь у тестуванні.
Пилотное тестування. Для перевірки тестових матеріалів і процедур проводиться попередня оцінка. Пилотное тестування - це спробний прогін для оцінки. Суб'єктів пилотного тестування представляють реальні користувачі. У залежності від характеру проходження тестування результати пилотного тестування чи зберігаються відкидаються. Якщо це доцільно, у тестові матеріали і процедури вносяться корективи, щоб забезпечити адекватний підхід до оцінки.
Анкетування, що випереджає оцінку. Проведіть брифінг із поль-зователями. Роздайте анкети, що випереджають тестування, щоб розібратися в досвіді, навичках, роботі і задачах користувачів. Якщо користувачі не підходять по своїм навичкам і досвіду, необхідно вирішити, чи продовжувати тестування.
Виконання сценарію. Попросите суб'єктів тестування виконати за-думанные задачі на об'єкті тестування.
Корисне правило. Придумайте тест, що займає один-два годин. Виділите час користувачам для того, щоб задати питання і висловити свої зауваження і вимоги.
У загальному випадку, кожен користувач повинний виконати тест без чи підказок переривання з боку координатора тестування. Коли користувач не може продовжувати подальше виконання тесту, тест-координатор неупереджено спонукує користувача до дослідження чи системи одержанню довідки для пошуку рішення. Якщо даних, отриманих у результаті звертання до довідкової інформації, недостатньо, тест-координатор втручається і пропонує свої інструкції.
Корисне правило. Помнете, що тест задуманий для оцінки продукту, а не користувача.
Зауваження до оцінки. Записуйте всі користувальницькі коментарі і за-мечания, що потрібно роз'яснити кінцевим користувачам. Стежите за тим, скільки часу витрачається на кожен артефакт ПІ і крок задачі. Обов'язково на-блюдайте за тим, де користувачі випробують чи утруднення роблять помилки. Візьміть до відома , чи допомагає довідкова інформація перебороти користувачам проблеми. Запишіть зауваження користувачів щодо інформації про продукт.
Корисне правило. Іноді за користувачами в процесі оцінки стежать два чоловіки - посередник (модератор) і спостерігач.
Порівняння. Надайте можливість суб'єктам тестування виконати ті ж задачі на існуючій системі. Якщо це неможливо, попросите суб'єктів тес-тирования описати, як працює поточна чи інша система при виконанні задач.
Анкетування по завершенні сценарію. По завершенні кожного сценарію і по закінченні тестування роздайте анкети, що стосуються проведеної оцінки. Визначальний питання звучить у такий спосіб: "Як вам подобається цей продукт у порівнянні з тим, чим ви користаєтеся сьогодні?"
Коли усе сказано. Проектна бригада піддає оцінці анкети і коммен-тарии одночасно з "розбором польотів" координаторів тестування; Проводиться статистичний аналіз і агрегація отриманої інформації.
Післямова. По можливості варто продовжити роботу з замовниками відразу після аналізу результатів тестування. Важливо довідатися думка користувачів із приводу внесення тих чи інших змін, заснованих на їхніх зауваженнях і результатах іспитів. У даному випадку ціль полягає в тому, щоб зрозуміти, чи правильно обраний напрямок змін.
Корисне правило. Усувайте проблеми якомога швидше !
Продовження. Макети, моделі і прототипи заміняються реальним ПО продукту в міру того, як воно стає досить надійним, щоб справитися зі сценаріями і тестами замовника. Щоб одержати представлення про поточний рівні задоволеності користувачів, знову варто звернутися до допомоги сценаріїв і анкет.
Корисне правило. З часом рівень користувальницької задоволеності і продуктивності повинний зрости в міру того, як користувачам стає доступні завершений інтерфейс і функціональні можливості. У противному випадку проект може відхилитися від обраного напрямку.
Коротко про всебічну оцінку. Оцінки евристичного характеру по-зволяют оцінити систему в цілому з погляду ефективності витрат. Експерти використовують систему таким чином, щоб випробувати кожну можливість і компо-ненту ПІ. Кожен компонент оцінюється стосовно евристик і критеріїв, обраним для продукту в цілому. Результати узагальнюються і на їхній основі складається звіт про відхилення продукту від заданих евристик.
Оцінка даних
Після завершення оцінки продукту за участю кінцевих користувачів у распо-ряжении координатора тестування виявляється набір даних у табличній формі, що стосуються виконаних задач і заключних анкет. Крім цього в координатора маються коментарі користувачів. Тепер виникає питання, що робити
із самооцінками користувачів і оцінками продукту. По можливості їх варто представити у виді вимірних результатів.
Типові результати. Якщо побудувати залежність часу, затрачуваного на задачу, від часу використання системи, то для ПО з високим рівнем практичності відповідний графік ясно показує швидке зменшення обсягу часу на задачу і досягає мінімуму після того, як користувачі вивчили систему й у них виробилися стереотипи використання (робітники навички). Аналогічні криві будуються для інших метрик практичності (наприклад, для звертань за допомогою, рівня користувальницької задоволеності і користувальницької переваги). Аналогічно часу на задачу більш практична система має тенденцію демонструвати меншу кількість звертань за допомогою, більш високий рівень користувальницької задоволеності і користувальницької переваги.
Корисне правило. При проведенні порівняльних оцінок практичне ПО повинне показувати більш швидке виконання користувачами задачі, високий рівень користувальницької задоволеності і користувальницької переваги. Компроміси між цими факторами, як правило, не спостерігаються.
Поряд з кількісними даними по завершенні оцінки у вашому розпорядженні виявляється також інформація якісного характеру у виді зауважень, зроблених користувачами і координаторами тестування. Користувачі констатують, що їм подобається і що не подобається. Тест - координатори описують, що і як роблять користувачі при виконанні задач, а також характеризують проблеми.
Статистика й інтерпретація. Описова статистика, довірчі інтервали і тестові гіпотези - от деякі методи, що підходять для аналізу даних. Розглянуті методи застосовні як до малих, так і до великих вибірок тестових даних. Важливу роль грає описова статистика (середнє, дисперсія, мінімум і максимум). До важливих аналітичних засобів відносяться також довірчі інтервали, перевірка гіпотез і дисперсійний аналіз.
Причинний аналіз. Аналіз результатів тестування повинний бути спрямований на виявлення тенденцій серед безлічі користувачів виходячи з заданого типового поводження в процесі навчання і застосування продукту. Внесені в ПО зміни не можуть ґрунтуватися на зауваженнях тільки одного суб'єкта і спостереженнях над ним доти , поки не буде зазначена неочевидна, але реальна проблема, що вимагає подібних змін.
Корисне правило. Варто проаналізувати всі анкети кожного користувача, що участвуют в іспитах.
Експерт повинний прагнути краще зрозуміти, як окремі користувачі характе-ризуют ПО і зроблені зауваження, а не оцінювати тільки підсумкові зауваження.
Формування звітності. Якщо розширені звіти спеціально не вимагаються, досить простих звітів. Звіт повинний містити наступні питання.
" Аналіз суб'єктів тестування.
" Аналіз продуктивності роботи користувачів і її розкиду (описова статистика).
" Оцінка загального рівня задоволеності як функції основних факторів (функцій, ПІ, продуктивності і т.д.).
" Розподіл рівня загальної задоволеності по користувачах і задачам.
" Наполегливі і ненаполегливі зауваження користувачів.
" Визначення результатів іспиту ПО відповідно до критеріїв.
" Сукупність припущень у відношенні того, яким образом перебороти проблеми і домогтися виконання критеріїв (у випадку, якщо ПО не пройшло іспиту).
" Список пріоритетів проблем (із указівкою кількості користувачів, столк-нувшихся з визначеною проблемою).
У результаті проведених іспитів проектна бригада має у своєму розпорядженні достатній обсяг даних, щоб відтворити проблему з користувальницької точки зору.
Участь розроблювачів
Для більшості видів оцінок координатор тестування розробляє і документує підхід до оцінки, зразкові задачі і сценарії, анкети, метрики і крите-рии. Оцінки можуть передбачати збір даних з погляду визначення рівня практичності ПО в короткостроковій і довгостроковій перспективі.
Корисне правило. Проаналізуйте матеріали, що стосуються добору суб'єктів тестування, переглянете сценарії, виконаєте прогін тестів, переглянете анкети, а коли продукт буде готів з погляду встановлених цілей іспитів, приступайте до тестування практичності і зробіть допомогу в проведенні іспитів.
Участь в іспитах дає, насамперед , можливість зрозуміти, до чого прагнуть користувачі, що вони хотіли б робити і як. Крім того, корисно довідатися про непередбачені і несподівані проблеми (наприклад, про дефекти, що легко чи пропустити не відчути під час реалізації). Спостереження за користувачами (замовниками), що зіштовхуються з проблемами, ініціює процес рішення проблем, у багатьох випадках позволяющий швидко усунути виявлені помилки (на противагу чеканню звіту після тестування). Це ще один вид ітерації.
Після одержання результатів оцінки проектна бригада визначає свої даль-нейшие дії: які зміни необхідно внести, на що не слід звертати увагу. Керівні принципи обробки результатів тестування і здійснення ітерації над продуктом для усунення проблем і підвищення рівня практичності розглядаються в главі 15.
Коротко про перевірку за столом
Оцінка практичності ПО й інші аспекти аналізу користувальницького досвіду були зведені до тестування практичності в тій чи іншій формі, у багатьох випадку без участі проектної бригади. Перейдемо до методу, що вимагає подальшого вивчення і зв'язаного з поняттям "перевірки за столом". Нехай задана функція l) = f(C, U Р, І, D) і розроблювач оцінює адекватність ПО стосовно перемінна, визначальна практичність.
Проста перевірка за столом приймає форму питань, заснованих на принці пахнув, нормативах і евристиках, застосовуваних при створенні продукту. Ці питання задаються щодо передбачуваних вимог до ПО, кола користувачів і задач для підтримки яких призначений продукт.
" чи Досить можливостей забезпечує ПО ( чиволодіє він достатніми функціональними можливостями для ефективного виконання задач)?
" чи Досить властивостей і методів, якими наділений ПІ, для ефективного виконання задач?
" чи Задовольняє інтерфейс ключовим принципам простоти, естетичності, продуктивності, пристосовності.
o чи Удалося уникнути розповсюджених проблем, властивих розробці ПІ (висока завантаженість пам'яті користувача, неясність, занадто! велика кількість екранів, занадто багато переходів миша-клавіатура, дуже багато кроків при виконанні задачі).
o чи Досить швидко, реагує система?
" чи Проста інсталяція?
" чи Досить надійно ПО?
" чи Є документація і підтримка експлуатації за своїм характером мінімальними? Чи відповідає система допомоги на реальні запити користувачів?
Корисне правило. Для відповіді на ці основні питання зовсім не потрібно проводити тестування з користувачами.
Продовження обговорення проекту
До цього часу кількість відгуків на проект було порівняно невелике й обмежувалося думками з боку проектної бригади, вищого керівництва і за-казчиков, що відвідують демонстрації. Усі відгуки, що ґрунтувалися на разра-ботанном до дійсного часу прототипу, носили позитивний характер і, здається, указували на те, що проектування продукту ведеться в потрібному напрямку. Однак не випливало забувати про альтернативи концептуального проекту і різних макетів, моделях і прототипах. Перш ніж закрити концептуальний проект, була почата спроба провести оцінку практичності при участі кінцевих користувачів.
Менеджер, відповідальний за продукт, повідомив, що вище керівництво интере-суется, як проходить тестування практичності. Керівники бажали б провести ранком брифінг. Крім того, виявилося, що в керівника, що виразив бажання працювати з вами над посібником зі стилю, не вистачає для цього часу. Однак він сказав менеджеру по продукті, що бажав би виконати деталізований перегляд прототипу ПІ. Вам належить відповісти на це прохання ранком.
Оскільки дотепер ніяких реальних оцінок за участю пользова-телей не проводилося, усе, що ви можете зробити- сформулювати план, описы-вающий, як повинна здійснюватися оцінка практичності продукту. Крім того, у вас їсти можливість швидко провести аналіз персонального складу передбачуваних учасників і евристик, а також здійснити разом із членами проектної бригади наскрізний контроль проектних рішень, вироблених дотепер .
Подбайте про презентацію, на якій можна буде обговорити методи оцінки, плановані в рамках проекту. Сформулюйте терміни проведення оцінок. Крім того, розглянете наступні аспекти оцінки практичності.
" Основні евристики, використовувані у вашому аналізі продукту.
" Зв'язані з практичністю області стосовно до кожної підтримуваної платформи.
" Зв'язані з практичністю області стосовно до прикладного ПО.
" Типові проблеми, з якими зіштовхуються додатки, аналогічні розроблювальної в рамках проекту.
" Обґрунтування пропонованих вами визначених методів.
" Типові анкети, що повинні використовуватися при проведенні оцінки.
" Кількість фахівців, задіяних у проведенні оцінки.
" Прогнозовані проблеми і рішення, якщо такі відомі.
" Прогнозована відповідність вимогам до ПІ і практичності.
" Визначення того, наскільки правильно ведеться проектування щодо евристик і розповсюджених проблем, зв'язаних з ПІ і практичністю.
Продовжуйте ваше дослідження в Іnternet, вивчайте теми, зв'язані з практич-ностью.
Для роботи над завданням у вашому розпорядженні біля трьох годин. Питання?
Посилання
Devore J.L. Probabіlіty and Statіstіcs for Engіneerіng and Scіences, Duxbury Press
Belmont, CA, 1991
Nіelsen J. usabіlіty Engіneerіng, Academіc Press: New York, 1993
Nіelsen J., and Mack R. Usabіlіty Іnspectіon Methods, John Wіley and Sons: New York,
1994
Rubіn J. Handbook of Usabіlіty Testіng, John Wіley and Sons: New York,
1994
Schneіderman B. Desіgnіng the user іnterface, Addіson - Wesley: Readіng,MA,1987
Torres R.G. Graphіcal User Іnterface Usabіlіty Evaluatіon, Share 84 Conference
Proceedіngs, Aug. 1995