7)Метод разработки User Centered Design.

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

-Кто будет пользоваться продуктом?

-Какие задачи будут решать пользователи при помощи продукта?

-В каком контексте?

На сегодняшний момент в России существует (пока только в виде проекта) - ТЕХНИЧЕСКИЙ РЕГЛАМЕНТ CТАНДАРТЫ РАЗРАБОТКИ ОФИЦИАЛЬНЫХ ИНТЕРНЕТ-РЕСУРСОВ ГОСУДАРСТВЕННЫХ УЧРЕЖДЕНИЙ. Целие создания:

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

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

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

-Повысить качество оказываемых населению услуг

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

Этапы разработки продукта: Требования. Каковы требования к продукту? Целевые пользователи. Кто будет пользоваться продуктом? Задачи пользователей. Зачем эти люди будут пользоваться продуктом? Контекст использования. В каком контексте пользователи будут выполнять свои задачи при помощи продукта? Проектирование интерфейсов. Проектирование. Юзабилити тестирование. Тестирование. Дизайн, разработка, тестирование, поддержка. User-centered design (UCD) - 6 methods Focus groups Usability testing Card sorting Participatory design(участие в дизайне) Questionnaires(анкеты) Interviews

8) Выяснение желания клиента. Первичные требования.

Выяснение желания клиента(методы выяснения "желаний").

1. Интервью. Проведение интервью с заинтересованными сторонами является самым прямым способом сбора требований. Обычно более полную информацию можно получить при интервьюировании один на один. Основные моменты:

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

-Задавайте контекстно-свободные вопросы – вопросы, которые не предполагают какого-либо конкретного ответа и заставляют интервьюируемого говорить о проблеме. Например, вопрос «Кто использует систему?» является контекстно-свободным и способствует обсуждению, тогда как вопрос «Систему используете вы?» предполагает ответ «Дя\Нет» и заканчивает дискуссию.

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

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

-Запаситесь терпением.

-Пригласите человека, наконец, в кафе!

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

MindMap.

Одним из вариантов фиксации этих противоречий, т.е. мыслей заказчика, может быть представлен в виде "mindmap".

Первоначальные требования.

Требования следуют из контекста моделируемой системы. В этот контекст входят:

-Непосредственные пользователи системы.

-Другие заинтересованные стороны (например, руководители, специалисты обслуживания, установщики)

-Другие системы, с которыми взаимодействует данная система

-Аппаратные устройства, с которыми взаимодействует данная система

-Правовые и регулирующие ограничения

-Технические ограничения

-Коммерческие цели

Как правило, после первой встречи с заказчиком, у вас есть небольшой набор «просьб» относительно будущего проекта или просто общее описание того, что будет делать система. Требование можно определить как "подробное описание того, что должно быть реализовано". Существует два основных типа требований:

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

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