Tarefa: Adaptar o Processo de Desenvolvimento para o Projeto
Essa tarefa é onde o processo de desenvolvimento é personalizado para atingir as necessidades específicas do projeto.
Disciplinas: Ambiente
Objetivo

A finalidade dessa tarefa é:

  • Colocar o processo de desenvolvimento de software no tamanho correto, de acordo com as necessidades específicas do projeto.
  • Fornecer orientação do processo relevante o suficiente para os membros do projeto fazerem seu trabalho de forma eficiente e com qualidade aceitável.
  • Fornecer uma descrição relevante e acessível do projeto para os membros do projeto.
Relacionamentos
FunçõesExecutor Primário: Executores Adicionais:
EntradasObrigatório:
    Opcional:
      Saídas
        Descrição Principal

        AS tarefas seguintes fornecem informações sobre o desenvolvimento de recursos de método específico do projeto.  Elas são executadas em conjunto com as etapas de desenvolvimento do método dessa tarefa:

        Quando um Caso de Desenvolvimento é utilizado, Tarefa: Desenvolver Caso de Desenvolvimento é executada em conjunto com essa tarefa de adaptação.

        Etapas
        Analisar o Projeto
        Finalidade:  Obter uma idéia geral do problema rapidamente e os recursos disponíveis para o projeto.

        É crucial para o sucesso do projeto que o processo de desenvolvimento seja relevante para o projeto em mãos e para os requisitos de tamanho e de formalidade do projeto. Muitos processos tendem a entrar no caminho da criatividade, eficácia e eficiência. Poucos processos podem levar a um ambiente caótico, normalmente levando membros de projetos a tomarem decisões locais que podem gerar resultados ineficientes, inconsistentes e imprevisíveis.

        Definir o Escopo do Esforço de Adaptação (VBSE EC4, EC7)
        Finalidade:  Definir quais áreas de processo devem ser cobertas no processo específico do projeto.

        Os resultados da análise dos recursos do projeto e sua experiência com os projetos de desenvolvimento de software semelhantes ajudam a identificar o escopo do esforço de adaptação. Um processo específico do projeto não tem que incluir todas as disciplinas em RUP nem deve ser necessário para cobrir todas as funções definidas no RUP. Lembre-se de que o RUP é uma estrutura de processo adequada para uma grande variedade de tipos de projeto e, assim, será demais para um projeto específico seguir. As áreas selecionadas para serem cobertas no processo do projeto dependem fortemente dos conjuntos de habilidades dos membros de projeto existentes e da natureza do projeto à mão. A seguir, há algumas considerações típicas a serem avaliadas ao definir o escopo do esforço de adaptação.

        • Áreas em que os membros do projeto têm um método comum de trabalho, nas quais não é necessário introduzir novos processos e ferramentas. Por exemplo, se eles sabem como testar, pode ser aconselhável não introduzir a disciplina Teste do RUP, para limitar o número de fatores novos. É possível enfatizar a introdução de algumas partes do RUP para corrigir problemas no processo existente.  Consulte Conceito: Implementando um Processo em um Projeto, seção Aprimorando o Processo e as Ferramentas, para obter detalhes. 
        • Áreas (disciplinas) nas quais o projeto deve introduzir novos processos e ferramentas, porque não há um método de trabalho. Em alguns casos, não há processos nem ferramentas de apoio, e é necessário incluir a maior parte do RUP, junto com ferramentas de suporte. Consulte Concept: Implementando um Processo em um Projeto, seção Alterar Tudo, para obter detalhes. 
        • Problemas no processo existente. Ênfase nas áreas de aprimoramento nas quais a organização tem tido problemas.
        • Quais ferramentas utilizar? Se o projeto decidiu utilizar determinadas ferramentas, o processo de desenvolvimento deve normalmente cobrir as áreas correspondentes do RUP.
        • A capacidade do projeto para mudanças de processo. Durante a verificação dos problemas da organização, há uma tendência de tentar solucionar tudo de uma vez, principalmente porque muitos desses problemas ocorrem em conjunto. Essa é em geral uma armadilha fatal. As organizações, assim como as pessoas, podem se adaptar às mudanças, mas apenas em um nível limitado. Se a capacidade para mudanças for pequena, você deve avançar gradativamente e talvez apresentar apenas uma ou duas disciplinas do RUP no primeiro projeto.
        • A exposição aos riscos -- isto é, probabilidade vezes impacto dos riscos -- decorrentes de se adotar um processo mais completo; esses riscos têm como impacto provocar um alongamento dos prazos de entrega. Esta consideração é crítica se o time-to-market é um fator importante para o produto de software.
        • A exposição aos riscos decorrentes de deixar o processo mais "leve", o que pode diminuir o time-to-market mas pode pôr em risco a qualidade do produto. Essa consideração é crítica se o produto é uma atualização, especialmente se tem uma grande base instalada.
        • Áreas em que os membros do projeto precisam de conhecimento específico. Permita que o processo de desenvolvimento cubra essas áreas. Certifique-se de que as informações corretas possam ser facilmente encontradas no RUP.

        Para obter informações adicionais sobre definir o escopo do esforço de adaptação, consulte Diretriz: Adaptando RUP

        Para uma descrição dos fatores que afetam como um processo é personalizado para o projeto, consulte Diretriz: Discriminadores do Processo.

        As áreas de aprimoramento identificadas não devem ser necessariamente introduzidas pela primeira vez no mesmo projeto. Reduza o número de fatores desconhecidos e procure as áreas em que a organização de desenvolvimento passou por maiores dificuldades no passado. Recomendamos que você implemente o RUP iterativamente, conforme descrito em Conceito: Implementando um Processo em um Projeto. Para pequenos projetos, há também orientação em Exemplo: Um Pequeno Projeto Adota RUP.

        Embora possa haver necessidades descobertas para os aprimoramentos dentro de várias disciplinas, considere a opção de introduzi-las iterativamente no curso de vários projetos em vez de buscar uma abordagem que altere tudo de uma vez. Um exemplo desse comércio é introduzir Requisitos com Casos de Uso e adiar a introdução de um novo processo CM, se os projetos anteriores tiverem lutado contra requisitos obscuros e/ou insuficientes ou se reclamações mais importantes foram feitas pelos usuários de que o produto entregue não atendeu as suas necessidades.

        Os comércios feitos e o escopo resultante devem ser documentados como parte do processo, a fim de comunicar as decisões do escopo para investidores externos.

        Desenvolver Conteúdo Específico do Projeto
        Finalidade:  Criar "know-how do processo" em áreas em que a cobertura na estrutura do processo RUP é considerada insuficiente para o projeto.

        A estrutura do processo RUP é manifestada em um modelo de processo definido utilizando um metamodelo baseado em UML. A estrutura do método RUP baseia-se em um metamodelo chamado "UMA" (Unified Method Architecture). As noções básicas de UMA são descritas em Conceito: Recursos-chave da UMA (Unified Method Architecture)

        Você pode estender uma estrutura RUP, incluindo Funções, Tarefas, e/ou Produtos de Trabalho ou você pode incluir Orientação específica do projeto na estrutura Rup existente.  

        Como uma parte de qualquer processo específico do projeto, deve haver um conjunto de recursos disponíveis personalizados para fornecer ajuda específica e material de referência para a produção de artefatos de projeto. Exemplos de tais recursos são:

        • Diretrizes comuns para como produzir determinados artefatos.
        • Os gabaritos personalizados para utilização em projetos. Esses serão parcialmente instanciados com as informações do projeto.
        • Os exemplos de artefato relevantes para o conjunto de produtos liberados definido e a tecnologia escolhida do projeto.
        • Os recursos reutilizáveis, como padrões de design e bibliotecas de código.

        No início do projeto, o Coordenador do Projeto trabalha tipicamente com o Engenheiro do Processo, para selecionar o conjunto apropriado de recursos e torná-los disponíveis para os membros do projeto, como parte do processo específico do projeto. A necessidade de recursos adicionais é revista no início de cada iteração.

        Configurar o Processo
        Finalidade:  Colocar o processo no tamanho certo para suportar exatamente as necessidades de um projeto.

        Configurar um processo envolve selecionar o conteúdo de métodos (produtos de trabalho, tarefas, funções, etc.) que serão incluídos no processo. Para recomendações específicas sobre que elementos de método incluir para cada disciplina, consulte as diretrizes de "decisões importantes no <nome da disciplina>", que são fornecidas para cada uma das disciplinas RUP. Selecionar o conjunto correto de conteúdo de métodos para um projeto determinado não é uma tarefa trivial. Para ser eficiente, o processo precisa ser relevante e estar no tamanho certo, junto com dimensões diferentes, como o tamanho do projeto (recursos e tempo do calendário), formalidade, plataforma tecnológica, domínio, isso para mencionar apenas alguns.

        Para informações sobre um esquema de classificação para documentar a importância de produtos de trabalho individuais e se eles serão utilizados ou não, consulte Diretriz: Classificando Produtos de Trabalho.

        Definir o Modelo de Ciclo de Vida para o Projeto
        Finalidade:  Definir o modelo de ciclo de vida para o projeto.

        Uma parte importante da adaptação de um processo para um projeto é decidir sobre um modelo de ciclo de vida a ser seguido para o projeto, incluindo a quebra em fases e iterações. Para essa parte do trabalho de adaptação, o engenheiro de processo deve colaborar de perto com o coordenador de projetos, já que o modelo de ciclo de vida escolhido projetará a parte essencial do processo de planejamento de projeto. Dependendo da natureza do projeto, pode haver uma necessidade de ajustar o ciclo de vida RUP para corresponder melhor às necessidades específicas. Por exemplo, o desenvolvimento de campo recente normalmente requer mais esforço no Início do que em um projeto de manutenção. Assim, a descrição do ciclo de vida deve ser ajustada de acordo com a natureza do projeto. Consulte Conceito: Iterações para uma discussão sobre vários tipos de modelos de ciclo de vida.

        Além de selecionar o modelo de ciclo de vida geral, também é importante decidir como executar os fluxos de trabalho associados com cada uma das disciplinas que são incluídas no esforço de adaptação, assim como decidir quando, durante o ciclo de vida do projeto, introduzir cada parte do fluxo de trabalho das disciplinas.  Decidir como executar o fluxo de trabalho envolve a decisão de que atividades desempenhar e em que ordem. Decidir quando executar cada parte do fluxo de trabalho envolve a decisão de onde o ciclo de vida (por exemplo, em que fase introduzir as atividades selecionadas). Para obter informações sobre como adaptar o fluxo de trabalho para cada uma das disciplinas RUP, consulte as notas de uso para os fluxos de trabalho de referência fornecidos para cada disciplina RUP.

        Algumas informações adicionais que você pode desejar especificar nesse momento é a sincronização dos requisitos de formalidade dos produtos de trabalho nos vários pontos no ciclo de vida. Por exemplo, em que fases está um produto de trabalho criado e/ ou atualizado e qual é a formalidade requerida do produto de trabalho (exemplo, ele precisa de uma aprovação pelo cliente?).

        Tornar o Processo Disponível para os Membros do Projeto
        Finalidade:  Tornar o processo específico para o projeto disponível para os membros do projeto.

        Após o trabalho de adaptação inicial se completar, o processo resultante precisa ser disponibilizado para a equipe do projeto em um formato consumível.

        Uma possibilidade é tornar o processo disponível via web site que pode residir em um Servidor da Web na rede da organização ou ser instalado em cada computador individual dos membros da equipe. Se os membros do projeto estiverem conectados à rede a maioria do tempo, a implementação do Servidor da Web será recomendada para evitar qualquer despesa adicional associada a atualizações do processo durante o ciclo de vida do projeto.

        Manter o Processo

        Embora a maior parte do trabalho de adaptação seja feito nos primeiros dias do projeto, ela deve ser mantida atualizada continuamente, na medida em que as equipes de projeto descobrem obstáculos e outros problemas no processo.   À medida que o processo se desenrola, são aprendidas muitas lições, que são usadas pelo engenheiro de processo como feedback para aprimorá-lo. As avaliações feitas durante o projeto são também entradas importantes para aprimorar o processo.

        Os ajustes menores são normalmente manuseados pelo projeto e as atualizações para o processo específico para o projeto são feitas como parte da preparação do ambiente de desenvolvimento para a iteração de lançamento.   Esse tipo de aprimoramento de processo freqüentemente levará às atualizações sendo feitas nos processos específicos do processo (por ex., refinamentos para gabaritos do produto de trabalho e diretrizes).   Os problemas mais complexos são levantados como controles de mudanças no processo. 

        Um dos maiores benefícios do desenvolvimento iterativo é a permissão para que as equipes de projeto aprimorem gradualmente o modo de desenvolvimento do software. Recomendamos que cada projeto inclua microciclos de engenharia de processo consistindo nas seguintes etapas:

        • Definir processo
        • Realizar trabalho de projeto com base no processo definido
        • Avaliar seu trabalho
        • Refinar processo
        Ilustrações
        Considerações de Teclas

        Não importa em que nível de adaptação é executado, o importante é capturar os resultados de (e possivelmente o fundamento lógico para) o esforço de adaptação.  Além disso, se é desejado que o processo que está sendo adaptado seja adaptado novamente (por exemplo, o processo está sendo adaptado para uma organização inteira e deseja-se que o processo organizational resultante seja adaptado para cada projeto), então, também é importante desenvolver diretrizes de como adaptar o processo de desenvolvimento. Tais decisões de adaptação e recomendações podem ser capturadas em um documento separado ou como uma parte integral do processo de desenvolvimento. Para obter informações adicionais sobre os níveis de adaptação, consulte Conceito: Adaptando RUP.

        O Software Plano de Desenvolvimento e organização tem um impacto grande no Processo de Desenvolvimento e vice versa. A adaptação do processo deve ser coordenada com o desenvolvimento do plano de projeto. Por exemplo, se o projeto decidir utilizar um conjunto diferente de fases daquele utilizado no RUP (Rational Unified Process), isso é algo que precisará ser capturado no processo de desenvolvimento adaptado.  Ademais, logo que o processo de desenvolvimento for adaptado, deverá ser instanciado em um plano de projeto executável. Para obter informações adicionais sobre o planejamento do projeto, consulte Tarefa: Fases do Plano e Iterações e Tarefa: Desenvolver Plano de Iteração.


        Quando adaptando o processo, recomendamos que você não adapte o processo inteiro de uma vez só.  Ao invés disso, concentre-se na disciplina que deve ser aplicada no próximo projeto.  Para obter informações adicionais sobre uma abordagem iterativa, consulte Conceito: Implementando um Processo em um Projeto

        Uma avaliação da organização de desenvolvimento, se disponível, indica em que áreas a organização de desenvolvimento, como um todo, precisa se concentrar. É necessário que seja tomada uma decisão inteligente sobre quais áreas de aprimoramento identificadas devem ser utilizadas como destino para o projeto. Essa decisão afeta diretamente o escopo do esforço ajustado

        Ajustar o processo para um projeto deve ser tratado como um projeto em seu próprio direito, com planos separados, orçamento e mecanismos de controle. Você deve definir um caso de negócios, com base na análise de retorno do investimento. O verdadeiro desenvolvimento do plug-in será beneficiado dos seguintes ciclo de vida e disciplinas no RUP. Recomendamos que você experimente as idéias principais do plug-in em um projeto real antes de iniciar o projeto para desenvolver o plug-in.

        Um Caso de Desenvolvimento pode ser utilizado para documentar decisões de adaptação (por exemplo, que partes de RUP foram adaptadas e por quê), assim como diretrizes para futuros esforços de adaptação. Dependendo do nível de adaptação sendo executado, o caso de desenvolvimento pode ser incluído como parte do próprio Processo de Desenvolvimento  ou pode apenas ser utilizado para planejar, orientar e documentar o esforço de adaptação. Para obter informações adicionais sobre os níveis de adaptação, consulte Conceito: Adaptando RUP.

        Alternativas
        Existem vários níveis diferentes de adaptações disponíveis para o RUP.  Para obter informações adicionais, consulte Conceito: Adaptando RUP.
        Informações Adicionais