Коллективный подход к разработке

Разработка , ориентированная на обучающихся

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

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

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

 

102

103

Человеко-машинное взаимодействие: теория и практика

Теория

 

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

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

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

104

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

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

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

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

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

Процесс состоит из четырех основных этапов (рис. 5.2):

♦ сбор и анализ информации от пользователей;

♦ разработка пользовательского интерфейса;

♦ построение пользовательского интерфейса;

♦ подтверждение качества созданного пользователь­ского интерфейса.

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

105

Человеко-машинное взаимодействие: теория и практика

Теория

 

 

Подтверждение

Построение

Рис . 5.2. Итерационный процесс разработки и проектирования пользовательского интерфейса

ционной системы и применяемого инструментария. И IBM, и Microsoft выступают за ведение итерационного процесса разработки.

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

109

Человеко-машинное взаимодействие: теория и практика

Теория

 

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

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

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

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

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

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

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

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

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

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

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

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

Третий шаг: сбор требований, предъявляемых поль­зователями

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

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

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

 

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

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

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

JKCH»

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

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

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

♦ повышать скорость совершения трансакций.
Четвертый шаг: анализ рабочей среды пользователей
Анализ среды пользователя отвечает на вопрос: «Где

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

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

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

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

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

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

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

 

110

111

Человеко-машинное взаимодействие: теория и практика

Теория

 

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

Существует множество руководств, рекомендаций и технологий для этих областей разработки программного обеспечения. Может возникнуть необходимость «внедрить» в проект некоторые конкретные идеи. Однако уже создано немало специальных вспомогательных элементов для раз­работки, доступных для программных операционных сис­тем. Например, Windows 95 и OS/3 предлагают способы настройки экрана, клавиатуры, мыши и других устройств ввода/вывода для пользователей с особыми требованиями. В руководстве фирмы Microsoft данный вопрос рассмотрен достаточно подробно.

Пятый шаг: соответствие требований стоящим перед пользователями задачам

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

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

112

 

Разработка иконок объектов

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

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

Не тратьте слишком много времени на ранних стадиях разработки интерфейса на иконки. Начните с черновых набросков, затем постепенна дорабатывайте и тестируйте иконки в процессе разработки. Можно обратиться к кни­ге Вильяма Хортона (William Horton), где достаточно под­робно рассмотрен этот вопрос.

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

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

Примеры результатов выполнения работ на этапах разработки пользовательского интерфейса

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

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

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

Таблица 5.2 Первый этап: результаты анализа требований,

предъявляемых пользователями

 

 

 

 

 

 

 

 

 

 

Результаты анализа	Клиенты	Представители обслуживающего персонала
Первый шаг: профиль пользователя	Мужчины и женщины	Мужчины и женщины
	Взрослые	Взрослые
	Жители разных стран	Жители разных стран
	Русско- и англогово­рящие	Русско- и англогово­рящие
	Минимальное владение ЭВМ	Средний уровень владения ЭВМ
	Предварительные знания по программе отсутствуют	Средний уровень владения программой
Второй шаг: задачи, стоящие перед пользо­вателями	Просмотр информа­ции по гостинице и тарифам	Просмотр информа­ции по гостинице и тарифам
	Просмотреть и обно­вить бронирование	Просмотреть и обно­вить бронирование
	Сохранить информа­цию о бронировании	Проверить информа­цию о бронировании
Третий шаг: . требования пользовате­лей	Требуется небольшой (или никакого) тренинг	Требуется минималь­ный тренинг
	Требуется мало времени	Возможность исполь­зовать программу, одновременно обща­ясь с клиентом по телефону
	Доступность 24 часа в сутки	Стиль интерфейса аналогичный продук­ту клиента

 

130

131

Человеко-машинное взаимодействие: теория и практика

Теория

 

Продолжение табл. 5.2

Окончание табл. 5.2

 

 

 

 

 

 

 

Результаты анализа	Клиенты	Представители обслуживающего персонала
	Возможность про­смотра и вывода графической и текстовой информа­ции о гостиницах	Потребность в мини­мальной технической поддержке
	Успешное выполне­ние задачи	Время ответа систе­мы, допустимое для ожидающего клиента
	Отсутствие необходи­мости в другом инструментарии и программах	Выполнение задачи может быть прервано и аннулировано
Четвертый шаг: среда пользо­вателя	ПК-программа, использующая локальную базу данных	Сетевые ПК, исполь­зуемые в среде обслуживания клиентов
	ПК-Internet-программы, исполь­зующие системную базу данных	Несколько представи­телей обслуживающе­го персонала, исполь­зующие системы одновременно
	Возможность исполь­зования дома, в офисе или в путешествии	Несколько представи­телей обслуживающе­го персонала, имею­щие доступ к сетевой базе данных одновре­менно
	Минимальные требования к компь­ютерной системе и телефонному обслу­живанию	Стандартизированные ПК, рабочие станции и телефонные систе­мы

 

 

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

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

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

В табл. 5.4 представлены сценарии и задачи, стоящие перед пользователями системы.

В табл. 5.5 проиллюстрированы сценарии после иден­тификации объекта и действий для системы.

 

132

133

Человеко-машинное взаимодействие: теория и практика

Теория

 

Таблица 5.3 Второй этап: цели и задачи, стоящие перед продуктом

 

 

 

 

Цели и задачи, стоящие перед продуктом	Клиенты	Представители сферы обслужива­ния
Удобство применения	Цель: пользователи получают возмож­ность использовать программу для выполнения своих задач	Цель: пользователи получают возмож­ность использовать программу для выполнения своих задач
	Задача: 100% потребителей смогут использовать систему для решения своей задачи уже после первой попытки	Задача: 100% потребителей смогут использовать систему для решения своей задачи после прохож­дения соответствую­щего тренинга
Эффектив­ность	Цель: деятельность пользователей станет более продуктивной (по сравнению с руч­ным методом работы)	Цель: деятельность пользователей станет более продуктивной (по сравнению с руч­ным методом работы)
	Задача: 100% пользователей выполнят стоящие перед ними задачи в течение заданного промежутка времени	Задача: 100% пользователей выполнят стоящие перед ними задачи в течение заданного промежутка времени
Легкость в освоении	Цель: пользователям потребуется мини­мальный тренинг	Цель: пользователям потребуется мини­мальный тренинг
	Задача: пользователи будут в состоянии успешно работать с продуктом после про­хождения соответст­вующего обучения	Задача: пользователи будут в состоянии успешно работать с продуктом после прохождения 4-ча­сового тренинга

 

 

Цели и задачи, стоящие перед продуктом	Клиенты	Представители сферы обслужива­ния
Оценка пользователя­ми качества продукта	Цель: пользователи будут удовлетворены качеством продукта	Цель: пользователи будут удовлетворены качеством продукта
	Задача: пользователи будут высоко оцени­вать степень своего удовлетворения качеством продукта	Задача: пользователи будут высоко оцени­вать степень своего удовлетворения качеством продукта

Таблица 5.4

Коллективный подход к разработке

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

Дональд Норман (Donald Norman)

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

101

Человеко-машинное взаимодействие: теория и практика

Теория

 

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

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

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

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

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

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

Основная часть продуктов программного обеспечения появилась благодаря командному подходу к разработке. Салливан (Sullivan) рассказывает, как создавалась Micro­soft Windows 95: «Команда разработчиков обладала зна­ниями в самых различных областях. В нее входили люди, обученные проектированию продукта, графическому про­ектированию, тестированию на удобство применения, а также компетентные специалисты в области компьютер­ных технологий».

1234567Следующая ⇒

Поделиться: