5. Анализ пользователей.

Первый шаг анализа - узнать своего пользователя.

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

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

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

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

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

Методы сбора информации №1.

Прямой - Косвенный.

Прямой: сбор информации при прямом контакте с пользователем.

Косвенный: сбор информации без прямого контакта с пользователями.

Индивидуальный - Групповой.

Индивидуальный: один пользователь в определенный момент времени.

Групповой: несколько пользователей в определенный момент времени.

Производительность - Обсуждение.

Производительность: задачи выполняются.

Обсуждение: задачи обсуждаются

Наиболее полную информацию можно получить при применении прямого и косвенного методов сбора информации.

Методы сбора информации №2.

Интервью. Сбор мнений (опрос). Фокус-группы. Полевые исследования (наблюдение). Журналирование.

Интервью.

Usability-специалисты формируют вопросы, по какой-либо проблеме использования системы.

Они опрашивают пользователей для получения необходимой информации.

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

Типы интервью.

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

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

Фокус-группы

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

Полевое исследование

Понимание основных трудовых задач пользователей.

Описание трудового процесса работы пользователей.

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

Выяснение основных характеристик пользователей.

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

В течение исследования необходимо собрать следующие данные:

Характерные особенности пользователей (опыт работы, уровень образования, возраст, предыдущий опыт работы с ПК и т.п.)

Анализ задач (общие цели пользователя, способы их реализации, информационные потребности пользователя, поведение в нестандартных ситуациях и пр.):

Перечень всех необходимых к решению задач.

Перечень всей информации, необходимой для реализации задач.

Перечень шагов по достижению поставленных целей.

Критерии, применяемые для оценки эффективности работы (и реализации поставленных целей).

Описание степени и порядка взаимодействия с другими пользователями.

Выработка требований.

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

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

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

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

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

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

Адекватное определение требований – одно из важнейших условий успеха проекта.

Модель требований.

Требования являются базой для:

планирования проекта;

управления рисками;

приемочного тестирования;

компромиссов (согласований);

управления изменениями.

Причины провалов проектов

Неполнота требований 13.1%

Недостаточное привлечение пользователей 12.4%

Недостаток в ресурсах 10.6%

Нереалистические ожидания 9.9%

Недостаток поддержки от руководства 9.3%

Изменение требований/спецификаций 8.7%

Недостаточное планирование 8.1%

Потеря необходимости 7.5%

Факторы успехов проектов

Вовлечение пользователей 15.9%

Поддержка руководства 13.9%

Четкая и ясная постановка требований 13.0%

Хорошее планирование 9.6%

Реалистичные ожидания 8.2%

Частые контрольные точки 7.7%

Компетентная команда 7.2%

Владение (требованиями) 5.3%

Прежде чем приступать к работе с входящими требованиями, необходимо оценить составляют ли они приемлемый «фундамент» для последующей работы. Чтобы оценить приемлемость требований для работы, необходимо ответить на следующие вопросы:

Является ли требование полным?

Является ли требование ясным?

Является ли требование осуществимым?

Является ли план проверки требований понятным и приемлемым?

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

функциональные требования - какое поведение должна предлагать система;

нефункциональные требования - особое свойство или ограничение, накладываемое на систему.

Язык требований Использование четкого и ясного языка (согласованных терминов) при написании требований позволяет существенном образом облегчить последующее понимание требований и их классификацию. Простым примером здесь может служить использование в тексте слова «должен»(должна, должно), как ключевого слова, обозначающего наличие требования. У каждого требования может быть ряд атрибутов, фиксирующих дополнительную информацию (метаданные) о требовании. Самым распространенным атрибутом требований является priority (приоритет). Его значение определяет приоритет требования относительно остальных требований. Набор критериев MoSCoW

Значения атрибута Priority	Семантика
Must have (обязан иметь)	Обязательное требование, является фундаментальным для системы.
Shoul have (должен иметь)	Важные требования, которые могут быть опущены.
Could have (мог бы иметь)	По-настоящему необязательные требования (реализуются, если на это есть время)
Want to have (хотел бы иметь)	Требования, которые могут подождать до следующих версий системы.