Рекомендация: Важные решения в сфере анализа и проектирования

Выбор способа применения рабочих продуктов

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

В следующей таблице перечислены рабочие продукты анализа и проектирования. Эти продукты разделены на рекомендуемые и необязательные (которые можно использовать только в определенных случаях). Дополнительные замечания по адаптации рабочих продуктов приведены в разделе об адаптации на странице описания конкретного продукта.

Рабочий продукт	Назначение	Адаптация (Необязательный продукт, рекомендуется)
Модель анализа (Класс анализа)	Модель анализа применяется для четкого определения требований при планировании проектирования. В сложных системах эта модель применяется для формирования общего представления о системе.	Необязательные продукты Во многих проектах вместо модели анализа применяется модель проекта. Если в проекте все же создается модель анализа, обычно она служит временным артефактом и преобразуется в модель проекта.
Схема навигации, Прототип пользовательского интерфейса	В проектах со сложным многофункциональным пользовательским интерфейсом следует учесть его проектирование.	Необязательные продукты В менее объемных проектах можно ограничиться простым проектом пользовательского интерфейса.
Модель проекта	При разработке большинства систем (даже небольших) следует сначала выполнить проектирование, и только затем реализацию. Это позволит избежать значительных расходов на исправление ошибок проектирования. Визуальные модели упрощают работу по проектированию. Инструменты прямого и обратного программирования упрощают работу с моделью реализации и позволяют сократить трудозатраты.	Рекомендуются для большинства проектов. В небольших проектах необязательно применять автоматизированные инструменты, однако их использование может положительно сказаться на производительности в долгосрочной перспективе.
Класс проектирования; Пакет проектирования	Классы и пакеты составляют основу любого объектно-ориентированного проектирования. Объектно-ориентированное проектирование - это стандартный метод проектирования, применяемый в большинстве проектов.	Рекомендуются для большинства проектов. Важный аспект адаптации заключается в выборе стереотипов (дополнительная информация приведена в рекомендациях по проектированию).
Реализация вариантов использования	Связывает варианты использования с проектированием.	Рекомендуются для большинства проектов.
Интерфейс	Интерфейсы обычно используются для определения поведения независимо от крупных компонентов, реализующих поведение.	Рекомендуются для большинства проектов. Проектирование на основе компонентов становится стандартным методом проектирования.
Подсистема проектирования	Подсистемы проектирования инкапсулируют поведение внутри компонента, предоставляющего интерфейсы. Эти подсистемы инкапсулируют взаимодействия классов и/или других подсистем.	Рекомендуются для большинства проектов. Подсистемы часто используются для повышения уровня абстракции проектирования. Они облегчают работу с системами.
Событие	Может быть полезным в системах, отвечающих на множество внешних событий.	Рекомендуется для систем в реальном времени.
Протокол	Обязателен для систем в реальном времени.	Рекомендуется для систем в реальном времени.
Сигнал	Может быть полезным в системах, функционирующих по принципу параллелизма и на основе событий. Обязателен для систем в реальном времени.	Может быть полезным в системах, функционирующих по принципу параллелизма и на основе событий. Рекомендуется для систем в реальном времени.
Капсула	Предназначена для систем в реальном времени, но также может использоваться при моделировании и проектировании любой системы с высоким уровнем параллелизма.	Рекомендуется для систем в реальном времени.
Модель данных	Содержит описание логической и, возможно, физической структуры постоянных данных.	Рекомендуется для проектов, в которых используется база данных.
Модель развертывания	Содержит описание конфигурации узлов обработки в реальном времени, связей между ними и экземпляров компонентов и объектов, расположенных в узлах.	Необязательный продукт. Многие системы содержат множество узлов обработки и поэтому должны обращаться к модели развертывания. Модель развертывания необязательно создавать как отдельный артефакт. Ее можно оформить как часть документа архитектуры программного обеспечения.
Доказательство концепции архитектуры	На его основе определяют, существует ли решение, удовлетворяющее архитектурным требованиям.	Рекомендуются для большинства проектов. Во многих проектах с помощью доказательства концепции архитектуры определяют, выполнимы ли требования. Доказательство концепции архитектуры может быть оформлено следующими способами: в виде списка известных технологий, которые потенциально подходят для решения в виде эскиза концептуальной модели решения в виде имитации решения в виде исполняемого прототипа.
Архитектура ссылок	Архитектура ссылок позволяет повторно использовать проверенные решения и поэтому ускоряет процесс разработки и сокращает риски.	Рекомендуются для большинства проектов. Материалы архитектуры ссылок помогают значительно ускорить процесс разработки и уменьшить риски.
Документ архитектуры программного обеспечения (SAD)	Документ архитектуры программного обеспечения содержит всесторонний архитектурный обзор системы. Этот обзор помогает составить представление об архитектуре и используется в принятии ключевых решений при работе с архитектурой.	Рекомендуются для большинства проектов. Общий архитектурный обзор рекомендуется составлять для всех систем, за исключением самых небольших. Обычно чем крупнее проект, тем более детальный составляется обзор и тем больше аспектов он охватывает.
Прототип пользовательского интерфейса	Используется для определения и тестирования функций и удобства работы до начала основной разработки. Это удобный способ предварительной оценки проекта, прежде чем потрачено слишком много времени.	Рекомендуются для большинства проектов.

Выбор отчетов

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

Выбор способов проверки

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

Проверки при анализе и проектировании дают следующие преимущества:

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

Недостатки проверок при анализе и проектировании:

Занимают время и расходуют ресурсы.
При непрофессиональном подходе велика вероятность их неправильного использования.

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

Локальные изменения в подсистему проверяются только одним специалистом, который проводит проверку и ведет запись результатов.
Выбор тех частей проекта, которые не будут проверяться совсем. Например, проверке подлежат только некоторые классы из каждой части проекта, причем предполагается, что остальные результаты не будут значительно отличаться.
Документ архитектуры программного обеспечения проверяется заказчиком в ходе отдельной встречи.
Изменения в основных интерфейсах (то есть в тех, которые используют несколько участников проекта) обсуждаются на официальных встречах.

Дополнительная информация об уровнях проверки приведена в разделе Рекомендация: Уровни проверки.

Выбор, создавать ли код

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