В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 40
Текст из файла (страница 40)
Удобно описывать такие сценарии в виде двух последовательностей —устремлений пользователя (не действий, а задач которые он хочет решить) и обязательствсистемы в ответ на эти устремления.Пример описания обычного и сущностного варианта использования при работе приведен вТаблице 9.В результате модель задач представляет собой набор переработанных вариантовиспользования со связями между ними по обобщению, расширению и использованию.Некоторые из вариантов использования объявляются основными — без них программапотеряет значительное количество пользователей.Всякая пользовательская роль при этом должна быть связана с одним или несколькимивариантами использования.Модель содержимого.Модель содержимого пользовательского интерфейса описывает набор взаимосвязанныхконтекстов взаимодействия или рабочих пространств (представляемых экранами,формами, окнами, диалогами, страницами и пр.) с содержащимися в них данными ивозможными в их рамках действиями.При построении этой модели нужно определить, что войдет в состав интерфейса (какиеданные и функции), и не решать вопрос о том, как именно оно будет выглядеть.На начальном этапе один контекст взаимодействия ставится в соответствие одному (невспомогательному!) варианту использования или группе очень похожих вариантов, длявыполнения которых понадобится один и тот же набор инструментов.Средства для поддержки вспомогательных расширяющих вариантов использования обычноудобно помещать в контексты расширяемых ими основных вариантов.Сначала устанавливается, какая информация должна находиться в заданном контексте дляуспешного решения задач соответствующего варианта использования, затем определяетсясписок необходимых операций для работы с этой информацией.Поиск номеровИзвестная информация обискомом сотруднике (ФИОполностью, отдел, группа,номера телефонов, другое)Список найденныхсотрудников (ФИО,отдел, группа, номерателефонов)Поиск (по всематрибутам, в томчисле частичноопределенным)Сортировкаинформации осотрудникахПросмотр полнойинформации осотрудникеПереключатель междуразными списками (все,корпоративный, личный,часто используемыеномера)Рисунок 62.
Пример модели содержимого контекста взаимодействия.132Часто при обсуждении содержимого контекста взаимодействия для его представленияиспользуют лист бумаги с наклеенными на него подписанными стикерами разных цветов(для различения информационных элементов и элементов управления). Такоепредставление удобно для быстрого внесения изменений по ходу обсуждения. Оно такженаглядно показывает, что рассматривается лишь прототип окна или странички, а егоэлементы абстрактны, для них пока не предлагается конкретная форма. Его трудно принятьза «почти готовый» проект окна, формы или странички, описывающий итоговые форму,расположение и цвета элементов интерфейса.На Рис. 62 приведен пример модели содержимого окна поиска номеров телефоновпрограммы, реализующей корпоративный телефонный справочник.После определения набора контекстов и их информационного и функциональногосодержимого рисуется карта навигации между контекстами, показывающая возможныепереходы между ними.
Карта навигации объединяет различные контексты взаимодействияв рамках модели содержимого интерфейса.ОсновноеокноПараметры страницы — переход на последнюю использованную закладкуПараметры страницыПечатьБумагаПечатьПоискпринтераДополнительныенастройки печатиОтступыРазмещениеНумерациястрокГраницыСвойствапринтераРисунок 63. Часть карты навигации редактора Microsoft Word.После разработки модели содержимого всякий основной вариант использования долженбыть поддержан при помощи одного или нескольких контекстов взаимодействия. Чемменьше контекстов нужно использовать для выполнения одного варианта использования,тем лучше.Перечисленные три вида моделей — ролей, задач и содержимого — являются основными.Оставшиеся два вида моделей используются только при необходимости.• Операционная модель описывает контекст использования системы и состоит из профилейпользовательских ролей.• Модель реализации представляет собой визуальный проект интерфейса и описание егоработы.Основные виды деятельности в рамках проектирования, ориентированного на использование,следующие.• Совместное с пользователями определение требований к ПО, с учетом пожеланий итребований к его интерфейсу.• Разработка модели предметной области с помощью пользователей.• Разработка моделей ролей и задач с помощью пользователей.• Разработка модели содержимого.133•••••••••Разработка визуального проекта интерфейса (модели реализации).Контроль удобства использования проекта интерфейса с участием пользователей.Проектирование объектной структуры ПО.Определение стандартов и стиля интерфейса с привлечением пользователей.Проектирование и разработка справочной системы и документации.Привязка интерфейса к контексту использования.Итеративная разработка архитектуры ПО.Итеративное конструирование ПО с постепенным введением запланированных функций.Контроль удобства использования готового ПО.Совместное определение требований *Разработка моделисодержимогоРазработка проектаинтерфейсаКонтроль удобстваиспользования *ИтеративноеконструированиеВремяРазработка справочнойсистемы и документацииРазработка моделейролей и задач *Определение стандартов истиля *Проектированиеобъектной структурыПривязка к контекстуиспользованияРазработка моделипредметной области *АрхитектурныеитерацииКонтроль удобстваиспользования *Рисунок 64.
Взаимосвязи и распределение деятельностей во времени.Деятельности, в которых вовлечены пользователи, помечены звездочкой.Эти деятельности не выполняются строго друг за другом в виде отдельных шагов. Дляописания их распределения во времени используется диаграмма, изображенная на Рис. 64.Контроль удобства программного обеспеченияНаиболее широко для контроля удобства использования ПО применяются различные видыинспектирования.Эвристическое инспектирование [7] организуется как систематическая оценка различныхэлементов и аспектов интерфейса с точки зрения определенных эвристик.
В качестве такихэвристик можно использовать изложенные выше правила и принципы построения удобных виспользовании интерфейсов, или любую другую достаточно полную систему эвристик,приводимых в руководствах по удобству использования ПО.В рамках одного сеанса инспектирования оценка интерфейса проводится несколькимиспециалистами, имеющими опыт в деятельности такого рода. Число оценщиков варьируется от 3-хдо 5-ти. Их результаты объединяются в общую картину. В процессе инспектированияразработчики должны отвечать на вопросы, касающиеся различных аспектов как предметнойобласти, так и работы проверяемой программы.Оценка проводится в два этапа.
На первом исследуется архитектура интерфейса в целом, навтором — отдельные контексты взаимодействия и элементы интерфейса. В целом оценка занимает1-3 часа, после чего проводится анализ полученных результатов, во время которого оценщикиописывают обнаруженные ими проблемы и предлагают способы их устранения.134При других видах инспектирования могут использоваться различные роли в группе оценщиков(оценщики, ведущий, летописец, пользователи, разработчики, эксперты в предметной области),различные шкалы серьезности обнаруженных дефектов (не более 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-приложений.135Основан GOMS на правилах разбиения задач на отдельные действия пользователя и на таблицезаранее определенных длительностей выполнения этих действий. В качестве таких действийрассматриваются следующие.• Нажатие на любую клавишу на клавиатуре, оценивается в 0.28 с.• Нажатие на кнопку мыши, оценивается в 0.1 с.• Перемещение указателя мыши, оценивается в 1.1 с.• Переход от использования клавиатуры к мыши или обратно, оценивается в 0.4 с.• Выбор очередного действия, оценивается в 1.2 с.Обычно считается, что выбор совершается при каждом переходе фокуса действийпользователя от одного элемента интерфейса к другому.• Время реакции системы, оценивается в зависимости от имеющихся данных, как минимум в0.1 с.Время реакции системы при выборе пункта меню или элемента раскрывающегося спискаобычно не учитывается, но учитывается время открытия окон.Помимо перечисленных оценочных методов используется и тестирование удобстваиспользования, но, по сравнению с ними, оно может применяться только на поздних этапахразработки и, обнаруживая отдельные проблемы, не дает указаний на возможные исправления илиболее важные недостатки проекта в целом.Тестирование проводится обычно в отдельном помещении, в котором пользователь можетцеликом сосредоточиться на работе с программой.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
