Частью приспособления структуры RUP для использования в определенном проекте является решение о том, какие дисциплины необходимо ввести. Как описано в разделе Задача: Приспособление процесса разработки под проект, нужно избегать использования всего RUP в одном проекте. И если ваш проект является новым для практик использования, описанных в RUP, вы должны сконцентрироваться на ограничении неизвестных факторов до небольшого числа, чтобы облегчить переход коллектива на платформу нового проекта.

После того как выбраны дисциплины, которые необходимо ввести, решите для каждой из них: 

• Каким образом должен выполняться поток операций. 
• Какие части потока операций должны использоваться. 
• Когда в процессе жизненного цикла проекта нужно вводить потоки операций и их части.  

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

Когда вы решили ввести определенную дисциплину или ее часть, обратите внимание на следующее:

• Применимость. Применима ли она в этом проекте? Имеет ли смысл вводить ее?
• Решаемые проблемы и корневые причины. Решает ли она какую-нибудь из обнаруженных проблем и ее корневых причин?
• Инструментальная поддержка. Какая инструментальная поддержка необходима?
• Согласование по времени. Когда в процессе жизненного цикла проекта она должна быть введена? Более подробная информация находится в разделе Концепция: Реализация процесса в проекте.
• Затраты на реализацию. Каковы затраты на реализацию ее в проекте? Это включает в себя:
  • Затраты на тренировку сотрудников. 
  • Затраты на установку средств поддержки.
  • Затраты на разработку рекомендаций и шаблонов.

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

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

Выполните следующие действия:

1. Решите, как должен использоваться рабочий продукт (моделирование элемента или документ).  Более подробная информация о  схеме классификации для документирования важности отдельных рабочих продуктов и необходимости их использования находится в разделе Рекомендация: Классификация рабочих продуктов.
2. Выберите уровень проверки для каждого рабочего продукта и зафиксируйте его в документе "Подробности проверки". Более подробная информация находится в разделе Рекомендация: Уровни проверки. Решите, как будет проверяться каждый рабочий продукт, то есть, какие процедуры проверки будут применяться.  
3. Решите, как вы будете фиксировать окончательные результаты дисциплины. Нужно ли сохранять результаты на бумаге? Если да, то нужно разработать один или несколько отчетов, которые будут извлекать результаты из инструментальных средств и фиксировать их на бумаге.  
4. Выберите средства для разработки и поддержки рабочего продукта.
5. Решите, какие свойства будут использоваться и каким образом. Обратитесь к таблице Свойства и разделу "Подгонка" для каждого рабочего продукта.
6. Там где это возможно, выберите стереотипы для использования. Для каждого рабочего продукта просмотрите раздел "Подгонка".
7. Выберите структуру документов рабочих продуктов. Для соответствующего рабочего продукта просмотрите раздел "Краткое содержание" основного описания.

Кроме этих шагов необходимо также:

• Решить, какие отчеты использовать. Решить, должны ли рабочие отчеты извлекать информацию из моделей и создавать бумажный документ для проверки. Эти рабочие отчеты обычно создаются нерегулярно, потому что они временные и становятся не нужны сразу после завершения проверки. Может понадобиться подогнать структуру отчета.

Существуют и другие решения, которые нужно принять для каждой дисциплины. Более подробная информация содержится в рекомендации "важные решения в <имя дисциплины>" для каждой дисциплины.

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

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

Опишите изменения в Прецеденте разработки.

Выберите вид модели жизненного цикла для проекта. Уточните модель RUP о отрегулируйте вехи и их критерии оценки, если это необходимо. Можно даже пропустить один или несколько этапов, а также добавить или удалить вехи. Более подробная информация находится в разделах Концепция: Этап  и Концепция: Итерация. Внесите в документацию модель жизненного цикла проекта в Прецеденте разработки в разделе "Обзор Прецедента разработки".

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

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

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

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

Роль Заинтересованное лицо представляет всех возможных заинтересованных лиц в проекте. Необходимо определить и описать различные типы заинтересованных лиц, их потребности и обязанности. В качестве примеров различных заинтересованных лиц можно привести представителя заказчика, представителя пользователя, инвестора, рабочего администратора и покупателя.

Опишите различных заинтересованных лиц и их потребности в прецеденте разработки в разделе "Роли".

В некоторых организациях разработчиков определены должности. Если в организации принято использовать должности, имеет смысл установить соответствие между ролями в RUP и должностями в организации. Соответствие ролей и должностей может помочь людям понять, как применить RUP. Это также поможет устранить обычное недоразумение, что роли являются должностями. Внесите в документацию это соответствие в прецеденте разработки в разделе "Роли".

Опишите прецедент разработки. Обратитесь к разделу "Опции представления", а также к любым связанным указаниям (например, шаблонам и/или примерам).

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