Методы разработки удобного программного обеспечения
Одним из наиболее технологичных подходов к разработке удобного пользовательского интерфейса является проектирование, ориентированное на использование (usage-centered design), предложенное Л. Константайном и Л. Локвуд (L. Constantine, L. Lockwood) [3].
Основная идея этого метода — использование специальных моделей, способствующих адекватному определению набора задач, которые необходимо решать пользователям, и способов организации информации, позволяющих упростить их решение.
Список моделей, которые используются в рамках проектирования, ориентированного на использование, следующий:
- Модель ролей.
Эта модель представляет собой список ролей пользователей системы. Каждая роль — это группа связанных задач и потребностей некоторого множества пользователей. Модель ролей может определять связи между ролями (роли могут уточнять друг друга, включать друг друга или просто быть похожими) и набор из одной-трех центральных ролей, на которые, в основном, и будет нацелено проектирование.
Кроме того, каждая роль может быть снабжена профилями, указывающими различные ее характеристики по отношению к контексту использования системы. Профили могут включать следующую информацию.
- Обязанности — требования к знаниям (о предметной области, о самой системе и пр.), которым пользователь в данной роли, скорее всего, удовлетворяет.
- Умения — уровень мастерства в работе с системой.
- Взаимодействия — типичные варианты взаимодействия пользователя в этой роли с системой, включая их частоту, регулярность, непрерывность, концентрацию, интенсивность, сложность, предсказуемость, а также управление взаимодействием (направляется ли оно пользователем, или он только реагирует на действия системы).
- Информация — источники, объем, направление передачи и сложность информации при взаимодействии с системой.
- Критерии удобства — специфические критерии удобства работы для данной роли (быстрота реакции, точность указаний, удобство навигации и пр.).
- Функции — специфические функции, возможности и свойства системы, необходимые или полезные для данной роли.
- Возможные убытки от ошибок, которые может совершить человек в данной роли, риски использования различных функций.
Пример модели ролей для пользователей банкомата приведен на рис. 9.5.
увеличить изображение
Рис. 9.5. Модель ролей пользователей банкомата - Модель задач.
Модель задач при проектировании пользовательского интерфейса строится на основе сущностных вариантов использования (essential use cases). Описание сущностного варианта использования отличается от обычного тем, что в рамках его сценариев выделяются только цели и задачи пользователя, а не конкретные его действия.Таблица 9.9. Описание обычного (слева) и сущностного (справа) вариантов использования
Целью такого выделения является освобождение от неявных предположений о наличии определенных элементов интерфейсов, что помогает разрабатывать их именно для решаемых задач. Удобно описывать такие сценарии в виде двух последовательностей — устремлений пользователя (не действий, а задач, которые он хочет решить) и обязательств системы в ответ на эти устремления.ДействияРеакции ЗадачиОбязательства Вставить карту Регистрация в системе Считать данные Запросить PIN Проверка личности Ввести PIN Проверить PIN Вывести меню Предложение набора операций Нажать клавишу выдачи денег Выбор операции выдачи денег Запросить сумму Ввести сумму Вывести сумму Запросить подтверждение Нажать клавишу подтверждения Вернуть карту Выдать деньги Выдача денег Напечатать чек Выдача чека Выдать чек
Пример описания обычного и сущностного варианта использования при работе приведен в табл. 9.
В результате модель задач представляет собой набор переработанных вариантов использования со связями между ними по обобщению, расширению и использованию. Некоторые из вариантов использования объявляются основными — без них программа потеряет значительное количество пользователей.
Всякая пользовательская роль при этом должна быть связана с одним или несколькими вариантами использования. - Модель содержимого.
Модель содержимого пользовательского интерфейса описывает набор взаимосвязанных контекстов взаимодействия или рабочих пространств (представляемых экранами, формами, окнами, диалогами, страницами и пр.) с содержащимися в них данными и возможными в их рамках действиями.
При построении этой модели нужно определить, что войдет в состав интерфейса (какие данные и функции), и не решать вопрос о том, как именно оно будет выглядеть.
На начальном этапе один контекст взаимодействия ставится в соответствие одному (не вспомогательному!) варианту использования или группе очень похожих вариантов, для выполнения которых понадобится один и тот же набор инструментов.
Средства для поддержки вспомогательных расширяющих вариантов использования обычно удобно помещать в контексты расширяемых ими основных вариантов.
Сначала устанавливается, какая информация должна находиться в заданном контексте для успешного решения задач соответствующего варианта использования, затем определяется список необходимых операций для работы с этой информацией.
увеличить изображение
Рис. 9.6. Пример модели содержимого контекста взаимодействия
Часто при обсуждении содержимого контекста взаимодействия для его представления используют лист бумаги с наклеенными на него подписанными стикерами разных цветов (для различения информационных элементов и элементов управления). Такое представление удобно для быстрого внесения изменений по ходу обсуждения. Оно также наглядно показывает, что рассматривается лишь прототип окна или странички, а его элементы абстрактны, для них пока не предлагается конкретная форма. Его трудно принять за "почти готовый" проект окна, формы или странички, описывающий итоговые форму, расположение и цвета элементов интерфейса.
На рис. 9.6 приведен пример модели содержимого окна поиска номеров телефонов программы, реализующей корпоративный телефонный справочник.
После определения набора контекстов и их информационного и функционального содержимого рисуется карта навигации между контекстами, показывающая возможные переходы между ними. Карта навигации объединяет различные контексты взаимодействия в рамках модели содержимого интерфейса.
увеличить изображение
Рис. 9.7. Часть карты навигации редактора Microsoft Word
После разработки модели содержимого всякий основной вариант использования должен быть поддержан при помощи одного или нескольких контекстов взаимодействия. Чем меньше контекстов нужно использовать для выполнения одного варианта использования, тем лучше.
Перечисленные три вида моделей — ролей, задач и содержимого — являются основными. Оставшиеся два вида моделей используются только при необходимости.
- Операционная модель описывает контекст использования системы и состоит из профилей пользовательских ролей.
- Модель реализации представляет собой визуальный проект интерфейса и описание его работы.
Основные виды деятельности в рамках проектирования, ориентированного на использование, следующие:
- Совместное с пользователями определение требований к ПО, с учетом пожеланий и требований к его интерфейсу.
- Разработка модели предметной области с помощью пользователей.
- Разработка моделей ролей и задач с помощью пользователей.
- Разработка модели содержимого.
- Разработка визуального проекта интерфейса (модели реализации).
- Контроль удобства использования проекта интерфейса с участием пользователей.
- Проектирование объектной структуры ПО.
- Определение стандартов и стиля интерфейса с привлечением пользователей.
- Проектирование и разработка справочной системы и документации.
- Привязка интерфейса к контексту использования.
- Итеративная разработка архитектуры ПО.
- Итеративное конструирование ПО с постепенным введением запланированных функций.
- Контроль удобства использования готового ПО.
увеличить изображение
Рис. 9.8. Взаимосвязи и распределение деятельностей во времени
Деятельности, в которые вовлечены пользователи, помечены звездочкой
Эти деятельности не выполняются строго друг за другом в виде отдельных шагов. Для описания их распределения во времени используется диаграмма, изображенная на рис. 9.8.