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