Lecture09 (1133566), страница 6
Текст из файла (страница 6)
Карта навигации объединяет различные контексты взаимодействияв рамках модели содержимого интерфейса (см., например, Рис. 63).После разработки модели содержимого всякий основной вариант использования долженбыть поддержан при помощи одного или нескольких контекстов взаимодействия. Чемменьше контекстов нужно использовать для выполнения одного варианта использования,тем лучше.Перечисленные три вида моделей — ролей, задач и содержимого — являются основными.Оставшиеся два вида моделей используются только при необходимости.• Операционная модель описывает контекст использования системы и состоит из профилейпользовательских ролей.• Модель реализации представляет собой визуальный проект интерфейса и описание егоработы.Совместное определение требований *Разработка моделисодержимогоРазработка проектаинтерфейсаКонтроль удобстваиспользования *ИтеративноеконструированиеВремяРазработка справочнойсистемы и документацииРазработка моделейролей и задач *Определение стандартов истиля *Проектированиеобъектной структурыПривязка к контекстуиспользованияРазработка моделипредметной области *АрхитектурныеитерацииКонтроль удобстваиспользования *Рисунок 64.
Взаимосвязи и распределение деятельностей во времени.Деятельности, в которых вовлечены пользователи, помечены звездочкой.Основные виды деятельности в рамках проектирования, ориентированного на использование,следующие.• Совместное с пользователями определение требований к ПО, с учетом пожеланий итребований к его интерфейсу.• Разработка модели предметной области с помощью пользователей.• Разработка моделей ролей и задач с помощью пользователей.• Разработка модели содержимого.• Разработка визуального проекта интерфейса (модели реализации).• Контроль удобства использования проекта интерфейса с участием пользователей.• Проектирование объектной структуры ПО.• Определение стандартов и стиля интерфейса с привлечением пользователей.• Проектирование и разработка справочной системы и документации.• Привязка интерфейса к контексту использования.• Итеративная разработка архитектуры ПО.• Итеративное конструирование ПО с постепенным введением запланированных функций.• Контроль удобства использования готового ПО.Эти деятельности не выполняются строго друг за другом в виде отдельных шагов.
Дляописания их распределения во времени используется диаграмма, изображенная на Рис. 64.Контроль удобства программного обеспеченияНаиболее широко для контроля удобства использования ПО применяются различные видыинспектирования.Эвристическое инспектирование [7] организуется как систематическая оценка различныхэлементов и аспектов интерфейса с точки зрения определенных эвристик. В качестве такихэвристик можно использовать изложенные выше правила и принципы построения удобных виспользовании интерфейсов, или любую другую достаточно полную систему эвристик,приводимых в руководствах по удобству использования ПО.В рамках одного сеанса инспектирования оценка интерфейса проводится несколькимиспециалистами, имеющими опыт в деятельности такого рода.
Число оценщиков варьируется от 3-хдо 5-ти. Их результаты объединяются в общую картину. В процессе инспектированияразработчики должны отвечать на вопросы, касающиеся различных аспектов как предметнойобласти, так и работы проверяемой программы.Оценка проводится в два этапа. На первом исследуется архитектура интерфейса в целом, навтором — отдельные контексты взаимодействия и элементы интерфейса. В целом оценка занимает1-3 часа, после чего проводится анализ полученных результатов, во время которого оценщикиописывают обнаруженные ими проблемы и предлагают способы их устранения.При других видах инспектирования могут использоваться различные роли в группе оценщиков(оценщики, ведущий, летописец, пользователи, разработчики, эксперты в предметной области),различные шкалы серьезности обнаруженных дефектов (не более 3-4-х уровней).В качестве метрик удобства использования применяются, например, следующие показатели(выбраны одни из самых простых и применимые в рамках описанного выше проектирования,ориентированного на удобство использования).• Сущностная эффективность показывает степень приближения производительностипользователей при работе с данным интерфейсом к некоторой идеальной.
Определяется онакак процентное отношение количества действий, выполняемых пользователем в идеале — врамках сущностного варианта использования, — к количеству действий пользователя всоответствующем сценарии работы с данным ПО.EE =Количество действий пользователя в сущностном варианте использования⋅100%Количество действий пользователя в соответсвующем реальном сценарииВ качестве элементарных действий пользователя учитываются концептуально целостныеединицы взаимодействия, такие как перечисленные ниже.o Ввод данных в одно поле вместе с нажатием перевода строки или табуляции.o Выбор поля, объекта или группы объектов (двойным или обычным) щелчком мыши илис помощью клавиатуры.o Переход от мыши к клавиатуре или обратно.o Выполнение действия (двойным или обычным) щелчком мыши на каком-либо объекте,с помощью меню или клавиатуры.o Перетаскивание объекта.Сущностная эффективность интерфейса, предназначенного для решения многих задач,определяется как сумма произведений сущностных эффективностей выполнения отдельныхзадач на частоты их выполнения.EE = ∑ pi * EEii•Согласованность задач показывает соответствие между частотами выполнения задач искоростью их выполнения в данном интерфейсе.
Вычисляется она следующим образом.o Задачи располагаются в порядке убывания частоты их возникновения на практике.o Оценивается количество действий пользователя, необходимое для выполнения каждойзадачи.o Вычисляется индекс согласованности: для каждой пары задач, если порядок в этой парев соответствии с трудоемкостью их выполнения совпадает с их порядком по частотеиспользования, к индексу прибавляется 1, иначе из индекса вычитается 1.o Итоговая согласованность задач оценивается как процентное отношение индексасогласованности к общему количеству различных пар задач, т.е.
к n(n-1)/2, где n —число различных задач.Значение этой метрики колеблется от -100% (полная несогласованность) через 0%(отсутствие корреляции) до 100% (полная согласованность).Для контроля эффективности работы пользователя с данным интерфейсом часто используетсяметод количественной оценки, основанный на выделении целей пользователя, операторов,методов и правил их выбора, в качестве названия которого используется аббревиатура GOMS(Goals, Operators, Methods, and Selection Rules) [8,9].Этот метод применим для оценки эффективности работы только достаточно опытныхпользователей и не учитывает возникающих по ходу работы ошибок.
Кроме того, он опирается наоценки времени реакции системы, которые очень сложно получить для некоторых видов ПО,например, Web-приложений.Основан GOMS на правилах разбиения задач на отдельные действия пользователя и на таблицезаранее определенных длительностей выполнения этих действий. В качестве таких действийрассматриваются следующие.• Нажатие на любую клавишу на клавиатуре, оценивается в 0.28 с.• Нажатие на кнопку мыши, оценивается в 0.1 с.• Перемещение указателя мыши, оценивается в 1.1 с.• Переход от использования клавиатуры к мыши или обратно, оценивается в 0.4 с.• Выбор очередного действия, оценивается в 1.2 с.Обычно считается, что выбор совершается при каждом переходе фокуса действийпользователя от одного элемента интерфейса к другому.• Время реакции системы, оценивается в зависимости от имеющихся данных, как минимум в0.1 с.Время реакции системы при выборе пункта меню или элемента раскрывающегося спискаобычно не учитывается, но учитывается время открытия окон.Помимо перечисленных оценочных методов используется и тестирование удобстваиспользования, но, по сравнению с ними, оно может применяться только на поздних этапахразработки и, обнаруживая отдельные проблемы, не дает указаний на возможные исправления илиболее важные недостатки проекта в целом.Тестирование проводится обычно в отдельном помещении, в котором пользователь можетцеликом сосредоточиться на работе с программой.
Кроме того, все действия пользователя,ответные реакции системы и реакции пользователя на то, что он видит, протоколируются. Дляэтого удобно использовать съемку на видеокамеру со спины пользователя, так, чтобы были видныего действия и происходящее на экране. Для фиксации реакций пользователя можно установитьзеркало, с помощью которого та же камера может снимать выражение его лица. Это помогаетпользователю впоследствии объяснить, чем именно были вызваны его затруднения в данномместе.
Кроме того, для протоколирования событий, которые видеокамера может и незафиксировать, необходимо присутствие наблюдателей-людей, которые, однако, никак не должнывлиять на действия пользователя (даже похмыкиванием, вздохами или ерзаньем на стуле, чтопользователь может истолковать, часто обосновано, как какие-то намеки на «неправильность» егодействий, или наоборот, одобрение).Пользователь, участвующий в тестировании, должен чувствовать себя раскованно и понимать,что проводимое мероприятие никак не связано с оценкой его профессионализма, знаний илинавыков.
Это необходимо объяснять, поскольку большинство людей в такой ситуации так илииначе увязывают свои действия с их возможной оценкой окружающими, что вредит адекватноститестирования.Об удобстве использования можно говорить еще очень долго, например, рассказать опроектировании и применении отдельных элементов интерфейса, а также об особенностяхпроектирования интерфейса различных видов ПО. Из-за ограниченности объема лекции мыостановимся здесь, а читателям, интересующимся данными вопросами, рекомендуем обратиться кспециальной литературе по удобству использования ПО [3,4,7,10-13].Литература к Лекции 9[1] У. Вудсон, Д. Коновер.
Справочник по инженерной психологии для инженеров ихудожников-конструкторов. М.: Мир, 1968.[2] Ю. К. Стрелков. Инженерная и профессиональная психология. Доступно по ссылкеhttp://psy.msu.ru/science/public/strelkov/index.html.[3] Л. Константайн, Л. Локвуд. Разработка программного обеспечения. СПб.: Питер, 2004.[4] В. В. Головач. Дизайн пользовательского интерфейса. Доступна на сайтеhttp://www.uibook1.ru.[5] D. O. Norman. The Design of Everyday Things. Basic Books, NY, 1988.[6] P. M. Fitts. The Information Capacity of the Human Motor System in Controlling Amplitude ofMovement. Experimental Psychology, 47, pp. 381–391, 1954.[7] J.