Операция: Анализ поведения
Эта операция позволяет преобразовать описание поведения в набор элементов, на основе которых будет создан проект.
ОписаниеСтруктура работыРаспределение группИспользование рабочего продукта
Взаимосвязи
Родительские операции
Описание

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

Анализ требований к поведению состоит из следующих элементов:

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

В ходе данной операции также может осуществляться моделирование и создание прототипов пользовательского интерфейса.

Свойства
Управляется событиями
Несколько вхождений
Выполняющийся
Необязательный
Запланированный
Повторяющийся
Персонал

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

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

Использование
Указания по использованию

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

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

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