План лекции. Лекция 11 Управление требованиями к программному продукту

Лекция 11 Управление требованиями к программному продукту. CASE-средство Requisite Pro.

Заключениеительные рекомендации по построению диаграмм последовательности

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

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

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

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

· Внедрение системы управления требованиями.

· Определение принципов создания хранилищ и политики доступа к ним.

· Фиксация инструментария, рабочей среды, средств разработки и внешних интерфейсов.

· Определение идентификации требований.

· Определение трассировки требований.

· Определение группы, видов, атрибутов требований.

· Определение метрик и отчетов.

· Определение принципов управления требованиями, формирование группы управления изменениями.

· Определение контрольных точек проекта.

· Внедрение разработанной системы УТ на проекте.

· Подсистема управления требованиями на основе IBM Rational RequisitePro.

Дата добавления: 2014-01-07