Содержание к диссертации
Введение
1. Анализ существующих методов обеспечения качества интерфейсов 12
1.1 Введение в проблему эргономики пользовательских интерфейсов: основные понятия и подходы к обеспечению 12
1.2 Анализ существующих методов оценки и повышения удобства интерфейсов 24
1.3 Анализ пакета утилит для тестирования интерфейса компании webmetrics 35
1.4 Постановка цели и задач исследования 37
2. Разработка метотодов улучшения качества интерфейса 39
2.1 Анализ существующих методик описания требований к интерфейсам 39
2.2 Классификация свойств интерфейса 42
2.3 Разработка функции качества интерфейса 47
2.4 Адаптация метода анализа иерархий для организации итерационного процесса улучшения интерфейса 55
2.4.1 Метод сравнений относительно стандартов 56
2.4.2 Учет мнений множества экспертов 60
2.5 Разработка методики юзабилити-тестоваыия 63
2.5.1 Подготовка тестовых заданий 63
2.5.2 Подбор испытуемых 65
2.5.3 Подготовка участников к тестированию 66
2.5.4 Проведение теста и анализ результатов 67
2.5.5 Разработка рекомендаций по улучшению удобства интерфейса68
3. Программная система улучшения эргономических показателей интерефесов веб-приложений 70
3.1 Требования к программной системе поддержки улучшения пользовательского интерфейса веб-приложений 70
3.1.1 Функциональные требования к системе 70
3.1.2 Требования к архитектуре и организации хранилища данных 71
3.1.3 Требования к средствам разработки 73
3.1.4 Требования к удобству использования 74
3.2 Реализация системы 74
3.2.1 Иерархия классов системы 75
3.3 Контрольный пример 77
3.3.1 Формулировка тестовых заданий 79
3.3.2 Итерация №1 79
3.3.3 Итарация№2 90
4. Исследование экономической эффективности процесса тестирования 97
4.1 Определение рационального количества пользователей для проведения тестирования 97
4.2 Функционально-стоимостной анализ удобства интерфейса 102
5. Библиография 114
6. Приложения 125
- Анализ существующих методов оценки и повышения удобства интерфейсов
- Метод сравнений относительно стандартов
- Требования к архитектуре и организации хранилища данных
- Функционально-стоимостной анализ удобства интерфейса
Введение к работе
Актуальность проблемы
В условиях постоянного роста количества разрабатываемых программ-<; систем и смены их версий, особенно актуальной является проблема про-ирования эффективного пользовательского интерфейса, который позволит ізить затраты и сократить время на обучение пользователей работе с но-л программным обеспечением, повысит качество и эффективность работы. жно выделить пять причин важности удобства пользовательского интер-ica: Товышение конкурентоспособности
Разработка продукта более простого и удобного в использовании позволяет получить значительный перевес в конкурентной борьбе. Существуют примеры [78], когда переработка интерфейса, проведенная с соблюдением требований качественного интерфейса, увеличила доходы производителя на 80%. При этом пользователи всегда оценивают простоту использования продукта как важнейшую его характеристику; Снижение стоимости разработки
Реальная себестоимость программных продуктов, как правило, значительно выше стоимости их разработки. Себестоимость вырастает за счет внедрения и поддержки продукта, причем она может вырастать на 80% от стоимости разработки. Это объясняется, в первую очередь, непониманием программистами целей и ожиданий конечных пользователей продукта, причем это непонимание обнаруживается сразу после сдачи продукта в эксплуатацию. За счет локализации проблем пользовательского интерфейса на ранних этапах разработки почти всегда можно снизить затраты на 60-90% [78]; Увеличение аудитории продукта
Интернет переполнен ресурсами, которые, не учитывая потребностей
посетителей, отталкивают потенциальную аудиторию - они сложны в использовании, на них трудно найти нужную информацию, они не доносят до посетителя послание владельца. Используя ориентированный на цели пользователей подход, можно быть уверенным в том, что ресурс будет отвечать нуждам посетителей, а это, в свою очередь, повысит отдачу от ресурса;
4. Увеличение удовлетворенности пользователей
Вовлечение будущих пользователей в процесс разработки ПО и сайтов с применением техник обеспечения качества интерфейса повышает субъективную удовлетворенность пользователя в среднем на 40% [39];
5. Уменьшение затрат на обучение и поддержку пользователей
Использование юзабилити1 методов[42] при проектировании ПО значительно снижает время, необходимое для обучения пользователей, равно как и ресурсы технической поддержки. В среднем использование таких методов при проектировании продукта снижает время обучения на 25%, а количество обращений в службу технической поддержки - на 60% [42]. Основной вклад в исследовании данной проблемы внесли русские веб-дизайнеры и разработчики Влад Головач [7], Николай Покровский [42], Артемий Лебедев [2], а также американские ученые Якоб Нильсен (Jakob Nielsen) [75,76,86,87,88,89,90,91,92,93,94,95], Том Ландауэр (Tom Landauer) [78,93], Дональд Норманн (Donald Norman) [68].
Цель и задачи исследований
Цель работы: улучшение эргономических показателей пользовательских
интерфейсов, повышение эффективности и сокращение сроков создания интерфейсов создаваемых веб-приложений.
От англ. «Usability» - удобство использования
Для достижения цели необходимо решить следующие основные задачи:
Провести теоретическое и экспериментальное исследование понятия «качество интерфейса» и средств повышения качества;
Разработать содержательную структуру понятия «качество интерфейса»;
Разработать методы оценки показателей качества пользовательских интерфейсов программных изделий;
Создать программный продукт для автоматизации тестирования качества интерфейсов на основе методик и результатов исследований;
Разработать методику проведения тестирования интерфейса с учетом экономической эффективности.
Методы исследования
Для решения поставленных задач применялись методы системного анализа, методологии SADT и IDEF, методы объектно-ориентированного анализа и проектирования, математического моделирования, оптимизации, принятия решений, в частности метод анализа иерархий Саати, методы проектирования автоматизированных информационных систем.
Результаты, выносимые на защиту
На защиту выносятся:
содержательная структура понятия качества интерфейса;
функция качества интерфейса;
метод оценки показателя качества интерфейса;
программный продукт для автоматизации тестирования качества интерфейсов, созданный на основе разработанного метода;
методика проведения итеративного тестирования.
Научная новизна результатов
В результате выполнения данного исследования был разработан метод
улучшения эргономических показателей пользовательских интерфейсов веб-приложений, как на стадии проектирования, так и в процессе эксплуатации, позволяющие увеличить эффективность веб-приложений и сократить сроки процесса проектирования и реализации интерфейсов. В процессе исследований были получены следующие результаты, обладающие научной новизной:
Предложена содержательная структура понятия качества интерфейса, включающая в себя подход к формализации процесса оценки качества интерфейса и отличающаяся от существующих наличием элементов анализа по стадиям взаимодействия пользователя с интерфейсом и по группам управляющих элементов;
Впервые предложена функция качества интерфейса, позволяющая количественно оценить эргономические свойства интерфейса и выявить его наиболее слабые стороны. Данная функция легла в основу метода оценки показателя качества интерфейсов. Эффективность метода заключается в объективности проводимой оценки качества.
Предложена методика итеративного тестирования качества интерфейса с использованием разработанного программного обеспечения, содержащая в себе теоретические и организационные аспекты проведения тестирования и отличающаяся от существующих использованием математического аппарата для определения экономической эффективности проведения процедуры тестирования.
Практическая ценность и внедрение результатов
Практическая ценность выбранного пути решения задачи заключается в том, что выполненные теоретические исследования позволили разработать и внедрить в практику программную систему поддержки исследований эргономических показателей интерфейса для продуктов, разрабатываемых и сопровождаемых продуктов, что позволило:
- повысить качество интерфейса разрабатываемых веб-приложений: по-
вышение качества интерфейса позволит сократить сроки на обучения персонала использованию программного продукта, снизить затраты на его развитие и поддержку, улучшить морально-психилогическое состояние пользователей программного продукта;
повысить эффективность и снизить сроки и затраты на проведение тестирования готовых программных продуктов;
получить средства для сертификации качества интерфейсов программных продуктов.
Результаты, полученные в работе, внедрены в ГосНИИ ИТТ «Информи-ка» при разработке федерального портала «Российское образование» (), в МОАО «Нефтеавтоматика» при создании корпоративного веб-сайта организации (), а также в ООО «Рекламное агентство «ЭрЭмСи» () при разработке интернет-проектов.
Основания для выполнения работы
Работа связана с выполнением научно-исследовательских работ (НИР)
по проектам, реализуемым с 2001 по 2003 год в рамках программ Минобразования России:
«Разработка программного обеспечения типовой системы проведения тестирования знаний и обработки результатов тестирования (Интернет-технология)», 2001-2002 годы, код проекта: 4.1.4.(000) 240.34;
«Разработка методологии создания системы образовательных порталов», выполнены работы по разделу «Дизайн и юзабилити образовательных порталов», 2002 год;
«Создание Федерального ресурсного центра методического, кадрового и материально-технического обеспечения развития единой образовательной информационной среды в Приволжском Федеральном округе», в рамках ФЦП «Развитие единой образовательной информационной среды (2001-2005 годы)», 2002 год;
- «Анализ информационных ресурсов и сервисов функционирующих и создаваемых образовательных порталов и выработка рекомендаций по их гармонизации», 2003 год.
Апробация работы и публикации
Основные положения, представленные в диссертации, регулярно докладывались и обсуждались на научных мероприятиях различного уровня. В том числе на следующих научных конференциях:
Республиканской научно-методической конференции «Новые информационные технологии в образовании», Уфа, 2001;
Одиннадцатой международной научно-методической конференции «Проблемы качества образования», Уфа, 2001;
Международной научно-методической конференции «Телематика», Санкт-Петербург, 2001, 2002, 2003;
Всероссийской конференции «Современная образовательная среда», Москва, 2001;
Всероссийской научной конференции «Научный сервис в сети Интернет», Новороссийск, 2002, 2003;
5-й Международной конференции по проблемам информатики и информационных технологий CSIT2003» Уфа, Россия, 2003.
6-й Международной конференции по проблемам информатики и информационных технологий CSIT2004» Будапешт, Венгрия, 2004.
Результаты диссертационной работы непосредственно отражены в 13 публикациях, в том числе 3 статьях, 10 трудах конференций.
Обоснованность и достоверность результатов диссертации.
Содержательная структура понятия качества интерфейса основана на методе анализа человеко-машинного взаимодействия, методике анализа прецедентов.
Функция качества интерфейса основана на методе анализа иерархий
Саати и корректном применении результатов теории принятия решений. Достоверность подтверждается корреляцией значений функции, полученных экспериментально, с результатами других методик тестирования интерфейсов.
Методика итеративного тестирования качества интерфейса основана на элементах теории функционально-стоимостного анализа и подтверждена экспериментально в процессе тестирования интерфейса разрабатываемых приложений.
Результаты работы апробированы и их эффективность подтверждена в реальных проектах.
Структура и объем работы
Диссертация состоит из введения, 4-х глав, выводов, списка литературы и приложений. Работа изложена на 130 страницах машинописного текста, кроме того, содержит 14 рисунков и 25 таблиц, размещенных на 36 страницах. Библиографический список включает 120 наименований и занимает 10 страниц.
Анализ существующих методов оценки и повышения удобства интерфейсов
Юзабилити-тестирование представляет собой постановку экспериментов с целью выявления специфичной информации, касающейся дизайна исследуемого продукта.
Юзабилити-тестирование производится на протяжении всего цикла разработки продукта. На ранних стадиях разработки тестирование предыдущей версии или конкурирующих продуктов позволяет команде проектировщиков наметить контрольные точки, которых необходимо достигнуть в процессе разработки. В середине работы над продуктом, тестирование проверяет корректность произведённого дизайна и предоставляет обратную связь, сообщая места, где дизайн нуждается в улучшении. На заключительных этапах тестирование удостоверяет, что продукт соответствует тем целям, для которых был спроектирован.
В целом, процесс проведения теста не сложен: необходимо с помощью некоторого заданного количества пользователей и выяснить, как именно производится работа с исследуемым продуктом. Как правило, в процессе тестирования производятся индивидуальные наблюдения за каждым из пользователей, которые выполняют ряд специально подготовленных заданий, требующих работы с продуктом. Производится сбор всех возможных данных, касающихся того, как именно пользователь выполняет задания, - например, сколько времени уходит на выполнение каждого задания или сколько ошибок совершается в процессе работы. Затем производится анализ собранной информации с выявлением тенденций и закономерностей.
Естественно, с помощью тестирования можно определить только слабые места интерфейса, и почти невозможно обнаружить сильные, поскольку они пользователями просто не замечаются. Определить новые способы улучшения также весьма затруднительно. Карточная сортировка (Card Sorting) Карточная сортировка — это классификационный метод, при котором пользователи сортируют различные элементы разрабатываемого веб-сайта по нескольким категориям. Для проведения карточной сортировки создается список параметров, которые предполагается подвергнуть классификации, после чего каждый из указанных параметров выписывается на отдельной карточке. Карточки предъявляются пользователям, которых инструктируют сгруппировать наиболее логичным, по их мнению, образом. Полученную в результате карточной сортировки информацию используют для организации пользовательского интерфейса. Данный метод работает только на самых ранних стадиях разработки и годится для создания набросков будущего интерфейса. Для оценки готового продукта он не приемлем [66]. Контекстное исследование (Contextual Inquiry) Контекстное исследование — это метод структурированного интервью, который отличается от обычного, например, журналистского интервью, тем, что он всегда построен на трех базовых принципах: - учет контекста, в котором используется изучаемый сайт; - совместная оценка сайта пользователем и разработчиком; - в фокусе оценки сайта находится именно его удобство для пользователя. При контекстном исследовании удобство оценивается в лабораторных условиях, а не в привычной для пользователя рабочей обстановке. При контекстном исследовании работа, время, мотивация и социальные факторы, воздействующие на пользователя, остаются такими же, как в реальном мире, в отличие от лабораторных исследований, где эти факторы контролируются экспериментатором. Контекстное исследование наиболее применимо для того, чтобы оценить ту обстановку, в которой будет использоваться продукт, поэтому оно проводится на ранних стадиях разработки продукта [70]. Контрольные списки (Checklists) Контрольные листы помогают удостовериться в том, что веб-сайт выполнен с учетом принципов функциональности дизайна. Обычно их используют на заключительной стадии работы в дополнение к экспертным методам (макетирование, эвристическое исследование) для того, чтобы структурировать экспертные оценки по каким-то определенным признакам. Существует большое количество готовых контрольных листов, однако решение об использовании того или иного списка должно зависеть от задач исследования. Зачастую возникает необходимость в разработке собственных критериев качества в определенной области. Среди вопросов могут быть, например, такие: - показывает ли ваш сайт возможность воспринять действия пользователя? По преимуществу это касается активных (изменяющих свой вид в зависимости от положения курсора) кнопок; - всегда ли вы предупреждаете пользователя о неприятных последствиях его действий? В основном вопрос касается апплетов, но также затрагивает необходимость предупреждать пользователя о длительном ожидании загрузки станицы (если она богата графикой); - постоянно ли доступны пользователю все элементы управления сайта? К примеру, постоянно ли доступна пользователю вся необходимая сие 28 тема навигации? Вопрос относительный, т.к. единственный на данное время способ сделать что-нибудь постоянно видимым — это кадры, которые сами по себе нехороши; - корректно ли сайт печатается? Очень важный вопрос для страниц, объёмом больших, нежели 2Kb (их чаще печатают). Надо проверить, как печатаются страницы на монохромных и цветных принтерах. Если вы режете большие тексты на множество отдельных страниц, вы должны предоставить пользователю возможность открыть и напечатать весь текст одной страницей (причём без красот экранного дизайна); - если глубина вашего сайта больше 5 страниц, предоставляете ли вы возможность текстового поиска? Задача контрольных листов - не оценка интерфейса сайта, а скорее напоминание разработчику о некоторых базовых принципах и нюансах, которые ему нельзя забывать при разработке, потому эту методику нельзя назвать методикой оценки [7, 77]. Макетирование (Prototyping) Макетирование — это создание модели конечного продукта (веб-сайта), позволяющее протестировать его составляющие на любых стадиях разработки.
В процессе макетирования строится модель, включающая все тестируемые компоненты (дизайн, элементы управления и т.д.). Можно использовать различные способы ее построения, от изображения элементов интерфейса на бумаге до создания рабочего макета веб-сайта. Различают горизонтальное и вертикальное макетирование.
Метод сравнений относительно стандартов
Как видно из вышеприведенной классификации, структура свойств интерфейса имеет иерархическую структуру. Первостепенная цель разрабатываемого метода - отсортировать все свойства интерфейса по приоритетам, т.е. определить наиболее критичные свойства тестируемого интерфейса, исправление которых наиболее важно для общего процесса повышения качества интерфейсов.
Для этого проведем декомпозицию проблемы на более простые составляющие части при помощи построения иерархии критериев оценки. В результате обработки суждений лиц, принимающих участие в тесте, определяется относительная значимость исследуемых альтернатив для всех критериев, находящихся в иерархии. Относительная значимость выражается численно в виде векторов приоритетов. Полученные таким образом значения векторов являются оценками в шкале отношений и соответствуют так называемым жестким оценкам.
Существует три способа анализа полученной иерархии: - попарное сравнение; - сравнение альтернатив относительно стандартов; - сравнение альтернатив копированием. Метод сравнения позволяет отнести каждую альтернативу определенному классу (стандарту). То есть вместо того, чтобы проводить численную оценку преимущества одного свойства над другим, эксперт может отнести альтернативу к одному из нескольких классов. Данный метод эффективен в нашем случае по следующим причинам: - эксперту может быть предложено для анализа более девяти альтернатив. В этом случае построение однородных матриц попарных сравнений становится затруднительным. Это связано с физическими ограничениями интеллекта человека; - при добавлении новых альтернатив изменяется порядок ранее прошедших сравнение альтернатив относительно критериев качества; - альтернативы могут поступать эксперту для сравнения не одновременно, а через определенные промежутки времени. Поэтому в данной ситуации не представляется возможным попарно сравнить объекты. Для решения проблемы сравнения и оценки альтернатив в указанных ситуациях наиболее целесообразен метод сравнения альтернатив относительно стандартов. Стандарт устанавливает уровень качества объекта относительно критерия качества. Например, критерию "удобство" для ЭУ интерфейса может быть назначено три стандарта, характеризующих соответственно высокий (Н — high), средний (М — medium), низкий (L — little) уровень удобства. В иерархической структуре стандарты присваиваются элементам, имеющим непосредственную связь с альтернативами. При этом число стандартов по каждому такому элементу (критерию качества) может быть различно и определяется экспертом с учетом конкретной ситуации. По каждому стандарту экспертом устанавливается относительная степень предпочтения, которая указывает значимость стандарта для эксперта. Численное значение каждого стандарта определяется их попарным сравнением по девятибалльной шкале путем обработки матрицы. Из вышеприведенной матрицы следует, что эксперт отдал слабое предпочтение высокому стандарту (Н) перед средним (М), а также среднему перед низким стандартом (L). В то же время предпочтение высокого стандарта (Н) перед низким (L) определено как очень сильное (оценка 7 в матрице). Рассмотрим правила построения иерархии, учитывающей стандарты и алгоритм вычисления векторов приоритетов альтернатив. Введем следующие обозначения: С - {С0, Cg} — множество стандартов, включающее два подмножества, устанавливающие соответственно основную {Со} и дополнительную {Cg} шкалы. Основная шкала включает градации С0 = {Н, М, L}, где Н, М, L — соответственно высокий, средний и низкий уровень стандартов по определенному критерию. Дополнительная шкала может включать градации Cg = {НН, НМ, ML, LL}, где НН, НМ, ML, LL — соответственно очень высокое; промежуточное между высоким и средним; промежуточное между средним и низким; очень низкое значение стандартов. Для конкретного элемента , включенного в иерархию из множества С, определяется подмножество стандартов Q, такое, что . Например, для элементов иерархии (см. рис. 2.6) 1 и определены стандарты Н, М, L, а для элемента Е"- — стандарты Н, НМ, М, ML, L. Следует отметить, что экспертом могут быть назначены различные значения для одних и тех же по наименованию стандартов, ОТНО сящихся соответственно к элементам і и . Вычисление векторов приоритетов альтернатив относительно элементов иерархии, учитывающей стандарты, осуществим следующим образом. Для каждого элемента " иерархии, непосредственно связанного со С сг С стандартами, устанавливается подмножество . Стандарты, входящие в подмножества С,, сформированные относительно , попарно сравниваются по девятибалльной шкале предпочтений. Относительные предпочтения стандартов фиксируются в матрицах, обработка которых по итерационному алгоритму, выполняемому в соответствии с соотношениями (2.2) и (2.3), позволяет определить для них правые собственные векторы. В собственном векторе верхний индекс указывает на принадлежность вектора уровню стандартов в иерархии.
Требования к архитектуре и организации хранилища данных
Поддержка процесса улучшения пользовательского интерфейса веб-приложений: выявление слабых мест тестируемых интерфейсов с точки зрения их удобства, вынесение рекомендаций по их исправлению, поддержка итеративного процесса тестирования. Процесс разработки программной системы целесообразно начать с определения набора требований (прецедентов) к системе (п.0). Весь набор требований разделен на: - функциональные (описывающие функции системы, т.е. то, что она должна делать); - к архитектуре и хранилищу данные (эти требования описывают то, как система должны быть построена); - к средствам разработки (регламентируют используемые для разработки средства, инструменты, серверное ПО и готовые программные модули); - к легкости и удобству использования системы. Система должна обеспечивать выполнение следующих функций: 1. Проведение юзабилити-тестирования, сбор и сохранение полученных результатов тестирования; 2. Вопросы тестов должны формироваться на основе требований (вариантов использования) к исследуемому веб-приложению; 3. Поддержка произвольного числа территориально удаленных пользователей, тестирующих интерфейс; 4. Анализ результатов; 5. Выявление ошибок в эргономике интерфейса на основе анализа; 6. Вынесение рекомендации по исправлению ошибок; 7. Поддержка итеративного процесса тестирования, т.е. сохранение результатов каждой итерации и сравнения их между собой; Функциональная модель системы приведена в Приложении 6.2. Программная архитектура отражает состав компонентов системы тестирования и обработки результатов. К архитектуре программной системы предъявляются следующие требования: 1. Пользователи участвуют в юзабилити-тестировании посредством работы с веб-браузером; 2. Когда все пользователи прошли свои тесты, результаты ответов агрегируются и направляются в XML файл; 3. Веб-приложение, осуществляющее тестирование, принимает ответы на вопросы и сохраняет их в базе данных; 4. Программное обеспечение, анализирующее результаты тестов, должно быть выполнено виде отдельного windows- приложения; 5. Программное обеспечение, анализирующее результаты тестов, открывает загруженный с веб-сервера XML-файл производит вычисления и выдает результат эксперту по эргономике, который пользуется результатом вычислений для исправления юзибилити-ошибок в интерфейса веб-приложений; 6. Затем, если требуемый результат не достигнут, итерация тестирования повторяется. В соответствии с требованиями, описанными выше, в состав системы тестирования входят следующие типовые следующие компоненты: 1. Web-сервер; 2. Система управления базой данных; 3. Web-браузер. Нетиповые программные компоненты: - серверное программное обеспечение для проведения юзабилити-тестирования и агрегации полученных результатов; - программное обеспечение анализа результатов тестов посредством адаптированного метода анализа иерархии. Обязательным компонентом, не показанным на схеме, является операционная система, служащая платформой для всех программных модулей. Из всех перечисленных компонентов непосредственной разработки программного кода требуют только функциональные подсистемы, для чего необходимо выбрать соответствующую технологию — язык программирования и инструментальные средства. При выборе типовых компонентов необходимо учитывать их возможности по интеграции с разрабатываемыми нетиповыми компонентами. Требования к организации хранилища данных: - результаты тестов должны храниться в реляционной базе данных; - программное обеспечение анализа результатов тестов должно обмениваться информацией с базой данных посредством XML. При выборе программного обеспечения производился анализ по следующим критериям: - соответствие сформулированным выше требованиям к программному обеспечению; - возможности интеграции с нетиповыми компонентами. В результате сравнения ряда программных продуктов был выбран следующий набор компонентов: - web-сервер: Microsoft Internet Information Server 6.0; - сервер БД: Microsoft SQL Server 2003; - платформа: Microsoft ASP.NET; - операционная система: Microsoft Windows 2003 Server. Данный набор при полном соответствии сформулированным выше требованиям обеспечивает максимальную эффективность, масштабируемость и безопасность работы компонентов проектируемой экспертной системы. К программному обеспечению предъявляются следующие требования: 1. Возможность проведения тестирования посредством World Wide Web; 2. Пользователю, участвующему в тесте должно быть достаточно веб-браузера (Microsoft Internet Explorer 5+ или Netscape Navigator 6+) для проведения тестирования; Тестируемый продукт и вопросы тестов должны отображаться визуально рядом, желательно в одном окне для упрощения работы пользователей. Реализация системы производилась в соответствии с методологией разработки программных систем (Rational Unified Process): - были сформулированы все требования к системе; - были выделены два основных класса пользователей системы: эксперты и пользователи; - построены модели иерархии классов, информационная модель данных, функциональная модель системы; - произведен выбор платформы и средств реализации: в качестве платформы выбрана Microsoft .NET CLR, в качестве средств разработки Borland Delphi 7.0 и Microsoft Visual Studio .NET; - на основе построенных моделей был сгенерирован каркас кода системы; - проведена разработка кода в соответствии с поставленными требованиями и разработанными моделями;
Функционально-стоимостной анализ удобства интерфейса
Кривая графика четко демонстрирует, что для обнаружения всех эргономических проблем необходимо по крайней мере 15 пользователей. Однако целесообразнее проводить тесты с гораздо меньшим количеством пользователей.
Главная причина в том, что лучше вложить ресурсы в несколько небольших тестов, вместо того, чтобы вкладывать все в один, сложный тест.
Несколько тестов эффективнее потому, что настоящая цель исследования - это улучшить дизайн, а не просто засвидетельствовать его недостатки. После первого теста с пятью пользователями будет найдено эргономических проблем 85%. Затем необходимо будет исправить эти проблемы перепроектировав дизайн. После создания нового дизайна, необходимо опять провести тест. Хотя выше и было сказано, что перепроектирование дизайна интерфейса должно исправить проблемы, обнаруженные при первом тесте, новый дизайн будет только казаться свободным от ошибок. Так как идеальный пользовательский интерфейс создать просто невозможно, нет никакой гарантии, что новый дизайн не имеет никаких проблем и ошибок. Второй тест должен показать, сработали ли внесенные исправления, или нет. Так же в новый дизайн может вкрасться новая эргономическая ошибка, несмотря на то, что старые ошибки были исправлены.
Так, второй тест с пятью пользователями позволит найти оставшиеся 15% ошибок, необнаруженных при первом тесте. (По-прежнему останется еще 2% ненайденных ошибок, которые будут обнаружены при третьем тесте).
Наконец, второй тест позволит более глубоко исследовать саму структуру сайта, оценить его информационную архитектуру, проверить порядок исполнения действий, подогнать сайт под требования пользователей. Эти важные моменты обычно ускользают из поля зрения при начальных тестированиях, когда пользователи тратят время, преодолевая простые поверхностные ошибки в пользовательском интерфейсе. Их внимания уже не хватает на более глубокое изучения сайта.
Таким образом, второй тест будет служить проверке результатов перепроектирования после первого теста и поможет более глубоко оценить сайт. При втором тесте неизбежно получится новый (но меньший) список эргономических проблем, которые нужно будет решать при новом перепроектировании дизайна. И опять же: не все проблемы при новой переработке будут решены; некоторые очень глубокие ошибки неизбежно всплывут, когда в результате работы будет модифицирован интерфейс. Вот для этого и необходим третий тест.
Следовательно, качество проделанной работы и эффективность пользователей при работе с сайтом увеличится гораздо больше, если будут проведены три теста по пять пользователей, чем один большой тест с 15 пользователями.
Почему одного пользователя недостаточно? Казалось бы, пятнадцать тестов с одним пользователем могут быть еще более эффективными, чем три с пятью. Ведь график показывает, что от первого пользователя мы узнаем намного больше, чем от последующих, так зачем привлекать этих последующих? По двум причинам: 1) всегда существует риск, войти в заблуждение от поведения одного единственного пользователя, который натолкнулся на проблему совершая спонтанные и совершенно неважные действия; 2) даже трех пользователей достаточно, чтобы понять различие в поведении пользователей, и определить, что между ними общего, а что нетипично Таким образом, приходим к выводу, что три-пять пользователей - это оптимальное количество в зависимости от стиля теста. Всегда есть опреде ленная постоянная стоимость затрат, связанных с планированием и проведе нием теста: лучше всего разложить эти начальные затраты на результаты, полученные от нескольких пользователей, чем всего лишь от одного. Когда следует привлекать много пользователей? Если предполагается, что у сайта будет несколько сильно различных групп пользователей, к тесту следует привлечь большее количество пользователей. Наша формула относится к тем случаям, когда есть пользователи, работающие с сайтом в примерно одинаковом стиле. Например, необходимо исследовать образовательный сайт, которым будут пользоваться учащиеся разных возрастных групп: школьники и студенты. В этом случае две группы пользователей будут вести себя на сайте со вершенно по-разному. Следовательно, необходимо проводить тесты с представителями из обеих групп пользователей. То же самое относится, например, к сайту, назначение которого - свести в одном месте продавцов и покупателей какого-либо товара. Даже если группы пользователей очень сильно отличаются друг от друга, все-таки что-то общее в их поведении будет. Ведь все они - люди. Кроме того, многие эргономические проблемы относятся к фундаментальным принципам взаимодействия людей с Web и влиянием других сайтов на поведение пользователей. При проведении тестов с группами различных пользователей нет необходимости составлять большую группу, как это делается при проведении тестов с одной единственной группой пользователей. Так как результаты тестов будут пересекаться, лучше всего в каждую группу включить небольшое количество пользователей. В результате исследования оптимального числа участников тестирования получены следующие выводы: - оптимальное число пользователей для проведения теста должно быть примерно равно пяти; - целесообразнее провести больше итераций тестирования с меньшим число пользователей, чем одну или две итерации с большим числом пользователей.
