Essas diretrizes descrevem algumas coisas a considerar ao adaptar o RUP. 

Para obter uma descrição do processo geral para adaptar o RUP, consulte Conceito: Adaptação do RUP. 

Para obter uma descrição de algumas boas práticas relativas à adaptação do processo, consulte Diretriz: Práticas de Adaptação do Processo.

Definindo o Escopo do Esforço de Adaptação

Definindo o escopo do esforço de adaptação é onde você identifica o que deseja alterar e como alterá-lo.

Para definir o escopo efetivamente, é importante familiarizar-se com o RUP.  Para obter informações adicionais, consulte Introdução ao RUP.

Quanto do processo você decide adaptar, assim como o nível de adaptação que você decide assegurar, ambos dependem de uma série de fatores. Esses fatores estão descritos em Diretriz: Discriminantes do Processo.  

Elementos Variáveis em Processos de Engenharia de Software

Esta seção revê os componentes de um processo que provavelmente serão modificados, personalizados, incluídos ou suprimidos como parte de um esforço de adaptação do RUP.

• Disciplinas
  Raramente um projeto de software ignoraria uma das disciplinas, como Análise e Design, Implementação e outras. Em casos excepcionais, é possível que algumas disciplinas (como, por exemplo, Requisitos ou Implementação) tenham sido executadas por outras organizações. No entanto, o mais provável é que fluxos de trabalho específicos sejam modificados nas ou através das disciplinas.  
  
• Produtos de Trabalho
  É muito mais provável que os projetos se diferenciem pelos produtos de trabalho que eles têm que produzir, atualizar e liberar. Em uma das extremidades de um intervalo, imagine um projeto sem qualquer documentação escrita, que mantenha eletronicamente apenas um pequeno número de produtos de trabalho, que seja suportado por ferramentas como planilhas, ferramentas de design e de teste e que apenas libere o software e a documentação eletronicamente em disco, em CD ou pela World-Wide Web. Na outra ponta, há projetos que devem produzir e manter um conjunto muito mais amplo de documentos impressos por razões contratuais, reguladoras ou organizacionais. Em alguns casos, modelos completos podem ser omitidos.
  
• Tarefas
  É provável que as tarefas variem devido a duas razões, no mínimo. As tarefas que utilizam produtos de trabalho como entrada e que produzem ou atualizam produtos de trabalho como saída são afetadas pela modificação desses produtos de trabalho. Em particular, se algum produto de trabalho ou algum elemento de informações em um produto de trabalho não for mais necessário, as etapas correspondentes poderão ser suprimidas ou modificadas de forma significativa. As tarefas também são modificadas para introduzir determinadas técnicas, métodos e ferramentas pertencentes ao domínio específico do aplicativo ou a especializações de desenvolvimento, como etapas de design, linguagens de programação, ferramentas para geração automática de códigos, técnicas de medição e assim por diante.

Em um nível mais detalhado, outros elementos de método podem ser modificados, incluídos ou suprimidos:

• Funções
• Etapas nas tarefas
• Diretrizes e orientação para tarefas
• Notações, como o uso de subconjuntos da UML ou o uso de estereótipos para lidar com alguma necessidade específica de alguns (ou de todos os) modelos
• Listas de verificação para revisões
• Suporte à ferramenta para automatizar algumas tarefas
• Mudanças de terminologia para, por exemplo, adaptar o processo ao contexto organizacional

Em resumo, o engenheiro de processo deve tomar inúmeras decisões ao adaptar o RUP. É possível que o RUP tenha de ser ajustado, para que possa tirar proveito de determinadas práticas e padrões da empresa estabelecidos com êxito, como documentos, terminologia e assim por diante.

Cenários de Adaptação Difíceis

Certos cenários de adaptação são difíceis de implementar e precisam ser considerados com muito cuidado. Por exemplo:

• Alteração na arquitetura do processo
  Um extenso reempacotamento das tarefas em um outro conjunto de disciplinas para corresponder a um processo ou organização existente pode resultar em um esforço muito grande para um ganho muito pequeno. Geralmente, é mais prático simplesmente estabelecer um mapeamento para avaliar se todos os aspectos são abordados pelo RUP. Lembre-se de que as disciplinas não são fases executadas em seqüência, mas sim contêiners de tarefas, sendo executadas repetidas vezes em cada iteração e, muitas vezes, simultaneamente em uma iteração.
  
• Alterações na terminologia
  Embora a substituição de uma palavra por outra possa parecer um exercício trivial no processamento de texto, essas alterações devem ser consideradas com muito cuidado. No domínio da engenharia de software, geralmente as organizações utilizam a mesma palavra com significados ligeiramente diferentes ou palavras diferentes com o mesmo significado. Mudanças isoladas no RUP podem levar a um processo de difícil compreensão. Uma solução é criar uma "tabela de tradução" da terminologia, que faça a tradução entre a terminologia do RUP e a da organização.

Entre os exemplos de palavras perigosas estão sistema, fase, função, atividade, tarefa, modelo e documento.

Se os resultados do processo forem captados em um idioma diferente do inglês, os problemas de terminologia serão mais complexos quando for necessário traduzir para esse outro idioma as descrições de produtos de trabalho, documentos, relatórios e possivelmente outras partes do RUP.