Здесь приводятся моменты, на которые следует обратить внимание при адаптации RUP. 

Общее описание процесса адаптации RUP приведено в Понятия: Адаптация RUP. 

См. также Практические рекомендации по адаптации.

Определение охвата адаптации.

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

Для эффективного определения рамок адаптации важно предварительно хорошо ознакомиться с RUP.  См. Введение в RUP.

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

Изменяемые элементы процесса разработки ПО

В этом разделе рассматриваются составляющие процесса, которые наиболее вероятно будут модифицировано, добавлены или вообще не будут взяты "на вооружение" при адаптации RUP.

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

На более конкретном уровне также возможно изменение, добавление и удаление определенных элементов, а именно:

• Ролей
• Этапов задач
• Рекомендаций и руководств по выполнению задач
• Систем обозначений, таких как подмножества UML или стереотипы, используемых в некоторых или во всех моделях
• Справочных таблиц для мероприятий по контролю
• Инструментов автоматизации определенных задач
• Терминологии, например адаптация процесса к организационному контексту

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

Сложные сценарии адаптации

Некоторые изменения адаптации достаточно сложны в реализации, поэтому их следует рассматривать очень тщательно. Например:

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

Примеры неоднозначных слов: система, фаза, роль, действие, задача, модель, документ.

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