5.2 Разработка, ориентированная на обучение

В прошлом разработка программного обеспечения и поль­зовательского интерфейса развивались только за счет эво­люции технологий и систем, на базе которых, программы строились. Это называлось системно-управляемой или тех­нологически управляемой разработкой (рисунок 5.1).

В 50-х годах интересы пользователей совершенно не учитывались. Им предлагались программные функции с интерфейсом, который разработчики были в состоянии предложить. Мощ­ность компьютеров была ограничена настолько, что ее едва хватало для выполнения элементарных операций.

С начала 80-х годов акцент был перенесен на разработку, ориентированную на пользователя, причем к разработке привлекались и сами пользователи. У них выясняли, какие требования они предъявляют к компьютеру, и какие задачи собираются с его помощью решать. Сейчас многие разработчики при­держиваются новых методологий, называемых разработ­кой с вовлечением пользователей и разработкой, ориенти­рованной на обучение. Бэннон (Bannon) так описыва­ет разработку с вовлечением пользователей: «Новый подход заключается в том, чтобы взглянуть на пользователей не просто как на объекты изучения, а как на активных участников самого процесса разработки. Подобное вовле­чение пользователей в разработку содействует демократи­зации, а также служит гарантией, что получаемая ком­пьютерная система будет отвечать запросам пользовате­лей».

Рисунок 5.1 – Эволюция разработки интерфейсов

Разработка, ориентированная на обучение, направ­лена на то, чтобы в процессе решения своих задач человек обучался новым навыкам работы с компьютером. Соловэй (Soloway) и Прайор (Ргуог) отмечают: «Без всякого сомне­ния, простое использование ценно, но не стоит ограничи­ваться только этим. Нам необходимо повышать наши тре­бования к компьютерным технологиям. Мы должны содействовать интеллектуальному развитию детей и взрослых, помогать в решении проблем, тренировать их воображение и, кроме того, давать им знания в различных областях».

5.3 Четыре этапа разработки

Проектирование пользовательского интерфейса может осуществляться как отдельно, так и совместно с осталь­ными процессами разработки программного продукта.

Однако сейчас больше внимания уделяется элементам интерфейса и объектам, воспринимаемым и используемым пользователями, а не функциональности программы. Во многих проектах разработка пользовательско­го интерфейса и программирование продукта ведутся па­раллельно, особенно на ранних стадиях. На более поздних этапах учитываются требования пользовательского ин­терфейса и обратной связи, выявляемые в результате тес­тирования на удобство применения.

Процесс состоит из четырех основных этапов. Это сбор и анализ информации от пользователей, разработка пользовательского интерфейса, построение пользовательского интерфейса, подтверждение качества созданного пользователь­ского интерфейса.

Данный алгоритм может использоваться как при разра­ботке объектно-ориентированных пользовательских интер­фейсов, так и при проектировании традиционных проблем­но-ориентированных интерфейсов или ГПИ. Этот процесс зависит от материальной и программной платформ, операционной системы и применяемого инструментария. IBM и Microsoft выступают за ведение итерационного процесса разработки.

Словарь Webster New Collegiate Dictionary дает следующее определение сло­ву «итерационный»: «...компьютерная процедура или имею­щая к ней отношение, где повторение цикла операций дает результат, который все более приближается к искомому ре­зультату». То есть не удастся получить качест­венный интерфейс без периодического возврата к преды­дущим этапам. Желательно проводить тестирование интерфейса с участием пользователей. Мнение пользователей и удобство применения продукта должны быть не менее важны, чем функциональность программы.

Традиционные методологии проектирования и разра­ботки продукта часто разрабатываются по водопадной модели жизненного цикла (ЖЦ). Их этапы аналогичны описанным выше – анализ, разработ­ка, построение, тестирование. Однако такой процесс яв­ляется в большей степени линейным, чем итерационным. Любая современная методология разработки программ­ного обеспечения должна поддерживать концепцию ите­рации (рисунок 5.2).

Рисунок 5.2 – Различные схемы итерационного процесса

На рисунке 5.2 а, изображена спираль с началом в центре, которая раскручивается на протяжении четырех этапов, чтобы показать, что итерации, на ранних стадиях быстрые и неформальные, со временем становятся более длинными и формальными. Спирали в окружности по­казывают, что в любой момент, на любом этапе можно вернуться к центральному «ядру» для дальнейшего усо­вершенствования интерфейса (рисунок 5.2 б).

Итерационные проверки нужно использовать до тех пор, пока намеченные цели не будут достигнуты.

Первый этап: сбор и анализ информации, поступающей от пользователей

Прежде чем приступать к разработке и построению любой системы, следует выяснить, какие проблемы пользовате­ли хотят разрешить и как они привыкли работать. Нужно наблю­дать за пользователями, расспрашивать их. Предлагаемое ре­шение должно соответствовать не только настоящим, но и будущим потребностям пользователей.

Первый этап – действия по сбору и анализу информа­ции – может быть разбит на пять шагов:

• определение профиля пользователей;

• анализ стоящих перед пользователями задач;

• сбор требований, предъявляемых пользователями;

• анализ рабочей среды пользователей;

• соответствие требований пользователей стоящим перед разработчиками задачам.

Проектирование и постановка вопросов, а также про­ведение анализа являются настоящим искусством.

1. Определение профиля пользователей.

Профиль пользователя дает ответ на вопрос: «Что пред­ставляет собой ваш пользователь?». Он позволяет вам со­ставить представление о возрасте, образовании, предпоч­тениях пользователей, получить другую необходимую ин­формацию. Нужно проводить интервьюирование и исследования, наблюдать за пользователями и снимать их на видео, изучать специальную литературу (опубликованные тек­сты докладов, материалы прессы и маркетинговых иссле­дований).

2. Анализ стоящих перед пользователями задач

Анализ стоящих перед пользователем задач – это оп­ределение того, чего хотят пользователи и каким образом они собираются решать свои задачи.

Независимо от метода анализа задач нужно полу­чить ответы на следующие вопросы:

• Какие задачи решают пользователи?

• Какие задачи являются наиболее важными?

• Какие шаги предпринимаются для решения задач?

• Какие цели преследуют пользователи при решении тех или иных задач?

• Какой информацией необходимо располагать для выполнения задач?

• Какой инструментарий (компьютеры и т.д.) исполь­зуется для решения задач?

• Каков ожидаемый итог от решения задачи?

• Каким образом пользователи выполняют свою работу (вручную, на компьютере, по телефону и т.д.)?

• Каким образом они взаимодействуют с другими лицами при решении задач?

• Каким образом задачи учитываются в общем бизнес-процессе?

• Как часто пользователям приходится решать за­дачи?

• Каким образом компьютер или другая компьютер­ная техника помогает пользователям в решении за­дач?

3. Сбор требований, предъявляемых поль­зователями

Анализ и сбор требований, предъявляемых пользова­телями, отвечают на вопрос: «Какую, с точки зрения поль­зователя, пользу принесет им предлагаемый продукт или интерфейс?». Практически во всех проектах программно­го обеспечения учитываются требования пользователей. Это помогает определить особенности проекта и структу­ру пользовательского интерфейса. Ключевыми в данном контексте являются следующие вопросы:

• Какие основные технологии требуются пользовате­лям?

• Сколько пользователи и менеджеры готовы запла­тить за продукт?

• Кто устанавливает продукт?

• Кто будет сопровождать продукт, когда он будет ус­тановлен?

Как правило, сбором требований занимаются специ­альные группы. Существуют некоторые общие для всех пользователей требования, предъявляемые к бизнес-про­граммам, в соответствии с которыми новый продукт дол­жен:

• сокращать работу с бумагами;

• уменьшать ошибки пользователей;

• автоматизировать существующие ручные процессы;

• повышать скорость совершения транзакций.

4. Анализ рабочей среды пользователей

Анализ среды пользователя отвечает на вопрос: «Где ваши пользователи решают стоящие перед ними задачи?». Необходимо определить характеристики среды, которые могут оказывать влияние на выполнение пользователями своей работы:

• физическая сторона рабочей среды (освещение, шум, рабочее пространство, температура, наличие компьютеров, телефонов, количество персонала и т.д.);

• места работы пользователя и степени его мобильности (офис, квартира, стационарно, с передвиже­ниями и т.д.);

• вопросы эргономики, условий труда (задействуются ли зрение, слух, работа ведется стоя/сидя, на клавиатуре и т.д.);

• особые запросы (уровень подготовки, физическое состояние, интерес к познавательному процессу, особенности речи и возможные недостатки);

• интернационализация и другие культурологиче­ские условия (перевод, цвета, иконки, текст, сообщения и т.д.).

Все эти факторы влияют на разработку продукта.

Существует множество руководств, рекомендаций и технологий для этих областей разработки программного обеспечения.

5. Соответствие требований, стоящим перед пользователями решаемым задачам

Анализ соответствия требований стоящим перед пользователями задачам это проверка на их реалистичность. Если требования пользователей не со­размерны выполняемым задачам, необходимо предло­жить им оптимальный вариант. Необходимо проверить, не превы­шают ли возможности продукта действительные потреб­ности клиента.

Проанализировав задачи, стоящие перед пользова­телями, и их требования выясняется, какие элементы интерфейса потребуются и как их расположить.

Второй этап: разработка пользовательского интерфейса

Разработка пользовательского интерфейса для про­граммного продукта обычно требует значительных затрат времени и ресурсов. Этап разработки состоит из опреде­ленных шагов, выполняемых в заданной последователь­ности. Разработка включает в себя следующие шаги:

• определение цели с точки зрения удобства применения продукта;

• разработка задач и сценария действий пользовате­лей;

• определение целей и операций интерфейса;

• определение иконок объектов и визуального пред­ставления;

• разработка меню объектов и окон;

• оптимизация визуальной разработки.

1. Определение цели с точки зрения удоб­ства применения продукта

Цели разработки лучше всего сформулировать в тер­минах, характеризующих действия пользователя. Напри­мер, длительность задач, возможное количество ожидае­мых ошибок. Следующие области, наиболее подходящие для установления целей и задач:

• пригодность;

• эффективность;

• легкость в освоении;

• оценка пользователями качества продукта.

2. Разработка сценария действий пользо­вателей и задачи, стоящие перед ними

Сложно с высокой степенью точности определить, что представляет собой сценарий по сравнению с задачей, стоя­щей перед пользователями. Как правило, сценарий явля­ется описанием действий, выполняемых пользователем. Сценарий представляется как последовательность задач, стоящих перед пользователями, или событий, направленных на достижение единой цеди. «Оплата обеда» является примером сценария высокого уровня, который будет со­стоять из множества более мелких задач, таких как «пой­ти в ресторан», «заказать еду», «съесть обед» и «заплатить». При необходимости задачи могут подразделяться на под­задачи.

Рекомендуется разработать несколько сцена­риев пользователей. Чем больше их будет, тем меньше ве­роятность того, что будут упущены из виду ключевые объек­ты и операции, необходимые в интерфейсе.

3. Определение объектов и операций

Этот шаг является, возможно, самым сложным (и самым важным) в процессе разработки. На этой стадии следует предпринять некоторые действия:

• выделить объекты, данные и действия из сценариев и задач, стоящих перед пользователями;

• просмотреть и уточнить список объектов и действий совместно с пользователями;

• начертить диаграмму взаимодействия между объектами;

• заполнить матрицу прямого манипулирования объ­ектами.

Необходимо определить исходный набор объектов и действий пользователя на основании информации, соб­ранной на первом этапе, а также сценариев, разработанных на втором этапе.

Обычно основному объекту (например, гостинице) с более чем одной копией требуется объект-контейнер вы­сокого уровня для хранения всей «коллекции индивиду­альных объектов. Например, в системе, связанной с тор­говлей автомобилями через сеть дилеров и имеющей мно­жество объектов «автомобилей», вероятно, будут присут­ствовать и объекты – «группы автомобилей». Такие объ­екты-контейнеры в итоге могут превратиться в папки ин­терфейса или в элементы управления списком.

Необходимо определить объекты устройств об­щего назначения, с помощью которых пользователи долж­ны выполнять определенные действия. К примеру, могут потребоваться объекты «принтеры» или «факсы», «пепельницы» или «корзины для мусора».

Одна из целей разработки пользовательского интер­фейса заключается в том, чтобы максимально скрыть слож­ность внутренних бизнес моделей и моделей программи­рования. Необходимо скрыть от пользователей функционирование «систем­ных объектов, они должны видеть эти объекты только через систему поиска или в списках имеющихся эле­ментов.

4. Определение иконок объектов и ви­зуальных представлений

Когда объекты уже установлены, нужно определить, как наи­лучшим образом представить их на экране, в каком виде их увидят пользователи, какую информацию они будут содержать. При определении представлений объектов необходимо учи­тывать способ общения пользователей с каждым из объ­ектов и с информацией, содержащейся в них.

Разработчик графики должен отвечать за проектиро­вание иконок. Обратная связь с пользователями и прове­дение тестирования на удобство применения также долж­ны использоваться для подтверждения того, что иконки узнаваемы, понятны и способны помогать в решении задач (рисунок 5.3).

Клиент Список клиентов Профиль клиента

Заказ Список заказов Список гостиниц

Рисунок 5.3 – Примеры иконок объектов, выполненных вручную

Разработку иконок лучше начать с черновых набросков, затем постепенно дорабатывать и тестировать их в процессе разработки.

5. Разработка меню и окна

Когда объекты, их типы и иконки определены и раз­работаны, остается выяснить, как пользователи будут об­щаться с объектами и окнами. Следует ответить на сле­дующие вопросы:

• Какие действия свойственны каждому объекту и типу?

• Что содержится во всплывающих меню?

• Каким окнам требуется панель меню?

Для этого составляются список объектов и действий и матрица прямого манипулирования объектами из третье­го шага, которые являются отправными пунктами для пятого шага. Необходимо перестроить эти схемы и определить действия, относящиеся к объектам, пред­ставленным в виде иконок.

Нужно изучить каждое окно, чтобы определить, тре­буется ли пользователю панель меню. Поскольку прило­жения становятся все более объектно-ориентированными, то упомянутые панели открывают путь к способам более прямого взаимодействия, например прямому манипули­рованию и всплывающим меню. Приложения, имеющие только одно окно, для представления всех относящихся к ним действий требуют сложных панелей меню. Они раз­биваются на объектно-ориентированные компоненты, при этом на уровне окна требуется меньше действий, а боль­шая часть операций может выполняться косвенным обра­зом, посредством всплывающих меню.

Основное различие между панелью проблемно-ориен­тированного меню и объектно-ориентированного заключа­ется в том, что панель объектно-ориентированного меню указывает объект как первый ва­риант на панели, а выпадающее меню содержит действия, допустимые для выделенного объекта в данном окне.

6. Усовершенствование визуальной разра­ботки

При первоначальной разработке схем окон удобнее поль­зоваться бумагой и карандашом. Когда вид окна опреде­лен, можно перейти к использованию инструментов прототипирования или проектирования, чтобы разработать схематическое изображение иконок и окон. Возможно, что, разрабатывая меню на шестом шаге, необходимо вернутся назад.

Третий этап: построение пользовательского интерфейса

При первом обращении к итерационному процессу раз­работки нужно создавать прототипы. Прототипирование яв­ляется исключительно ценным способом создания первых проектов и демонстрации продукта, особенно на ранних этапах тестирования на удобство применения.

Цель прототипирования заключается в том, чтобы быстро и лег­ко визуализировать различные альтернативные варианты разработки, а не создавать код, который должен стать ча­стью продукта.

Необходимо следовать трем «золотым» правилам при использовании прототипов:

• прототипируйте на ранних стадиях и не забывайте про итерационный принцип разработки;

• создавайте различные альтернативные варианты;

• будьте готовы выбросить код прототипа.

Существует много способов прототипирования интер­фейсов: бумага и карандаш, доски для мела и фломасте­ров, альбомы для презентаций, клеящиеся листочки и т.д. Для показа последовательности визуальных разработок применяют прототип с анимацией либо презентационные графические программы (например, Lotus Freelance Graph­ics и др.). Может использоваться и такой способ: человек работает «компьютером», переключая экраны по запросу пользователя. Для прототипирования могут применяться либо спе­циальные инструменты, либо инструменты проектирова­ния (обычно для написания кода продукта).

Прототип может быть полезен и с точки зрения маркетинга и продаж продукта, если де­монстрировать его менеджерам, руководящим сотрудни­кам и клиентам. Демонстрационная версия продукта так­же является практически бесплатным элементом бизнес показов и рекламных рассылок по почте.

Программное прототипирование становится специа­лизированной областью в рамках разработки программ­ного обеспечения и тестирования на удобство использова­ния.

Четвертый этап: подтверждение качества

Тестирование на удобство применения является клю­чевым элементом итерационного процесса разработки. Оно заключается в том, чтобы выдать продукт на руки боль­шому количеству пользователей и посмотреть, смогут ли они с ним работать. Цель тестирования на удобство при­менения должна заключаться в оценке поведения, дейст­вий и степени удовлетворения пользователей. Многие раз­работчики обращаются к подобному виду тестирования ближе к концу проектирова­ния. Но это слишком поздно для того, чтобы на основании его результатов вносить изменения. Даже если они и вносятся, нельзя быть уверенным в том, что исправ­ленный продукт можно использовать без проведения по­вторного тестирования.

Разработчики должны обязательно присутствовать при проведении тестирования, и оказать техническую под­держку. Деятельность по оценке удобства применения не пре­кращается после продажи продукта или внедрения его в производство (таблица 5.1).

Разработка и проектирование программного продукта могут потребовать внедрения множества подсис­тем, сетей, баз данных, других программ и т.д. Как пра­вило, операционная система, языки программирования и инструментарий для проектирования определяются рань­ше, еще до разработки пользовательского интерфейса. При создании программного продукта необходимо привязываться к предыдущим версиям, дру­гим продуктам или специальному набору языков програм­мирования и инструментарию. На рисунке 5.4 представлены два различных подхода к разработке интерфейса.

Таблица 5.1 – Действия по оценке удобства применения продукта

Стадии разра­ботки продукта	Действия по оценке возможности использования
Определение концепции	Сбор требований пользователей концептуальное определение разработки
Подтверждение концепции	Концептуальные оценки разработки (бумага/карандаш, прототипы)
Разработка	Оценки прототипов. Отслеживание и фиксирование проблем, возникающих у пользователей
Проектирование	Итерационное тестирование на ранних стадиях разработки (индивидуальные модели, ключевые задачи). Итерационное тестирование окончатель­ных вариантов разработки (целиком продукт, все задачи). Отслеживание и фиксирование проблем, возникающих у пользователей
Распространение пилотной версии. Анкета для пользователей пилотной версии	Наблюдение на месте за пользователями пилотной версии. Обратная связь с пользователями пилотной версии. Отслеживание и фиксирование проблем, возникающих у пользователей
Внедрение продукта	Наблюдение на месте за пользователями продукта. Обратная связь с пользователями продукта. Отслеживание и фиксирование проблем, возникающих у пользователей. Анкета для пользователей продукта
Поддержка и обслуживание	Сравнение показателей удобства примене­ния за длительный период времени (1-месячный, 3-месячный, 6-месячный интервалы). Обновление и внесение изменений в тесты. Тест для пилотных разработок новых продуктов

Рисунок 5.4 – Два направления разработки интерфейса

При разработке, основанной на вовлечении пользователей, проектируются интерфейсные метафоры, визуальные элементы и способы ввода/вывода, соответственно их пожеланиям.

Историческим примером проектирования компьютер­ной системы на базе ее интерфейса является Apple Com­puter. Данный пример стал классикой успешной истории, где сначала был создан проект интерфейса, а затем постро­ен сам компьютер для его поддержания. Персонал компа­нии Apple всегда гордился своим дружественно настроен­ным к пользователю компьютером Macintosh.

Разработчик пользовательского интерфейса разделяет два очень различных мира – пользователей и разработчиков приложения. Разра­ботка, ориентированная на пользователя, основана на ряде руководящих принципов:

• понимание нужд пользователей является движущей силой всего проекта;

• все, что пользователи видят и к чему прикасаются, должно проектироваться совместными усилиями;

• инновационный проект всегда является результа­том интенсивной работы;

• используются команды специалистов в разных об­ластях;

• конкурентоспособный проект требует постоянного акцента на соревнование;

• проект, утвержденный пользователями, управляет разработкой кода;

• принимаемые решения должны основываться на обратной связи с пользователями;

• информация от обратной связи с пользователями должна собираться часто, точно и быстро;

• обратная связь осуществляется как с потенциаль­ными, так и с уже существующими клиентами;

• разработка, ориентированная на пользователя, долж­на постоянно совершенствоваться.