Finalidade
  • Para colocar o processo de desenvolvimento de software no tamanho correto, de acordo com as necessidades específicas do projeto
  • Para fornecer uma descrição relevante e acessível do projeto para os membros do projeto
Função:  Engenheiro de Processos 
Freqüência: A massa do trabalho faz parte do início do projeto. Pode repetir conforme necessário em qualquer iteração
Etapas
Artefatos de Entrada:  Artefatos Resultantes: 
Mentores de Ferramentas: 
Informações Adicionais: 

Detalhes de Workflow: 

Analisar o Projeto Para o início da página

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 e para os requisitos de tamanho e formalidade do projeto. Muitos processos tendem a entrar no caminho da criatividade 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.

A cerimônia de processo varia muito em diferentes organizações de desenvolvimento. Algumas são muito maduras em termos de processo e colocam grupos de processo para procurar a definição e aprimoramentos do processo de desenvolvimento por toda a organização. Outras se preocupam apenas com a adaptação do projeto. Esses projetos serão normalmente iniciados com uma das configurações predefinidas que acompanham o produto RUP e a partir dela instanciarão o processo para cada projeto. A abordagem para a adaptação do processo para o projeto depende de vários fatores, por exemplo:

  • A maturidade do processo da organização de desenvolvimento.
  • O tamanho do projeto em termos de tempo no calendário e o número de recursos de desenvolvimento.
  • A exposição anterior de membros do projeto a processos semelhantes.
  • Os requisitos de formalidade do projeto.

Consulte Orientação: Discriminantes do Processo para obter detalhes.

Definir o Escopo do Processo Para o início da página

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 dos conjuntos de habilidades dos membros de projeto existentes e a natureza do projeto. A seguir, há algumas considerações típicas a serem consideradas 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 ../workflow/environm/co_iproj.htm#Improving Process and Tools -- This hyperlink in not present in this generated websiteConceitos: 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 ../workflow/environm/co_iproj.htm#Change Everything -- This hyperlink in not present in this generated websiteConceitos: 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. 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.
  • Á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.

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 ../workflow/environm/co_iproj.htm -- This hyperlink in not present in this generated websiteConceitos: Implementando um Processo em um Projeto. 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 de troca é 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 finais aos quais o produto entregue não atendeu as necessidades.

As trocas realizadas devem ser documentadas para comunicar as decisões de escopo aos investidores externos. Ao criar a configuração no produto RUP Builder, essas decisões podem ser documentadas como uma descrição da configuração e flutuarão no Web site publicado.

Estender a Estrutura do Processo (opcional) Para o início da página

Finalidade:  Incluir conhecimento adicional sobre processos ao processo específico do projeto em áreas em que a cobertura na estrutura do processo RUP é considerada insuficiente para o projeto.

Um dos pontos fortes da estrutura do processo RUP é que ela é aplicável a uma grande variedade de projetos e ambientes. Mas isso também pode ser visto como uma desvantagem porque a descrição do processo tende a se tornar um pouco genérica demais. A tecnologia de plug-in do RUP foi projetada para superar alguns desses problemas, permitindo que os fornecedores de ferramentas ou de tecnologia e empresas individuais criem descrições de processos mais específicas por meio de plug-ins. Você localizará uma lista atualizada de plug-ins disponíveis para download na seção RUP do developerWorks®: Rational®.

O ../res_processworkbench.htm -- This hyperlink in not present in this generated websiteproduto RPW (Rational Process Workbench™) permite a criação de extensões RUP utilizando a tecnologia de Plug-ins RUP. Seguindo as recomendações para essa tecnologia, a estrutura RUP pode ser estendida de duas maneiras. É possível criar um plug-in estrutural para estender o modelo de processo RUP ou criar extensões que fornecerão recursos reutilizáveis relevantes da organização de desenvolvimento para o projeto por meio de pequenos plug-ins.

A criação de um plug-in RUP (estrutural) deve ser tratada como um projeto em seu próprio direito, com planos, orçamento e mecanismos de controle separados. 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.

Consulte ../workflow/environm/co_polpr.htm#Extend -- This hyperlink in not present in this generated websiteOrientação: Adaptação RUP, seção Estender o RUP, para obter informações adicionais.

Configurar o Processo Para o início da   página

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

A estrutura RUP foi construída de um conjunto de componentes de processo e plug-ins, cada componente contém um conjunto de elementos de processo relacionados. A criação de uma configuração RUP significa selecionar um conjunto de componentes de processo. Selecionar o conjunto correto de componentes para um determinado projeto não é uma tarefa rotineira. 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 obter informações mais detalhadas sobre a configuração RUP, consulte

Preparar o Processo para o Projeto Para o início da página

Finalidade:  Definir como o processo configurado será ativado no projeto.

Uma descrição de processo configurada para um projeto freqüentemente não está no nível dos detalhes prontos para serem ativados. Por exemplo, o processo define um conjunto de artefatos a ser utilizado com base em uma seleção de componentes de processo relevantes (conforme descrito na seção anterior Criar uma Configuração RUP), mas não especifica os requisitos de sincronização e de formalidade dos artefatos para esse projeto específico. As diretrizes prescritas e os gabaritos de artefato instanciados parcialmente também são considerados parte de um processo específico para o projeto instanciado. O esforço necessário para realizar esta etapa é altamente dependente da precisão do processo configurado. Qualquer desvio do processo base deve ser justificado e documentado como parte do processo específico para o projeto.

Subtópicos:

Definir Colapso do Ciclo de VidaPara Preparar o Processo

O trabalho de instanciar o processo configurado no projeto envolve a decisão 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 em vários tipos de modelos de ciclo de vida.

Personalizar Artefatos Para o início da página

O processo configurado contém descrições dos artefatos que espera-se que o projeto produza. Já que a configuração provavelmente será definida para ajustar-se a um determinado tipo de projeto, essa seleção deve ser convidada como parte do processo de instanciamento. Não planeje produzir um artefato se você não pode explicar porquê precisa dele. Os artefatos também devem ser qualificados com informações como:

  • Em que fase esse artefato será criado ou atualizado
  • Qual a formalidade necessária do artefato (por exemplo, se é necessária uma desconexão do cliente)
  • Quais ferramentas devem ser utilizadas para produzi-los

Essas informações podem ser mantidas em uma planilha ou documento acessível a partir do Web site do processo ou podem se tornar parte integral da descrição do processo.

Preparar Recursos do Artefato para o Projeto Para o início da página

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, por exemplo, Diretrizes de Modelagem do Caso de Uso.
  • 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 de Projetos normalmente trabalha com o Engenheiro de Processo para selecionar o conjunto de recursos apropriado e torná-lo disponível para os membros de projeto como parte do processo específico para o projeto. A necessidade de recursos adicionais é revista no início de cada iteração.

Introduzir o Processo para os Membros do Projeto Para o início da página

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

Após o trabalho de adaptação inicial, o processo resultante precisa ser publicado em um formato consumível. O RUP Builder fornece um meio de publicar o processo configurado, resultando em um Web site RUP que contém somente os componentes e os recursos do processo selecionado. O Engenheiro de Processo precisa trabalhar com o Coordenador de Projeto para tornar o processo específico para o projeto público e decidir como educar os membros do projeto. Isso pode variar de uma apresentação informal de 2 horas para um treinamento formal, dependendo do tamanho do projeto e da familiaridade dos membros do projeto com processos de desenvolvimento semelhantes. Cada atualização significante do processo, durante o ciclo de vida do projeto, deve ser reativada para o projeto, enfatizando as mudanças.

O Web site para o processo específico para o projeto pode ser publicado em um servidor da Web na rede da organização ou instalado em cada computador dos membros da equipe. Se os membros do projeto estiverem conectados à rede a maioria do tempo, a implementação do Web site RUP em um servidor da Web será recomendada para evitar qualquer elevação associada a atualizações do processo durante o ciclo de vida do projeto.

Manter o Processo Para o início da página

Embora a maior parte do trabalho de adaptação seja feito nos primeiros dias do projeto, ela deve ser mantida atualizada contínuamente, na medida em que as equipes de projeto descobrem obstáculos e outros problemas no processo. As avaliações feitas durante o projeto são 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. Os problemas mais complexos são levantados como controles de mudanças no processo. Isso normalmente é manuseado pelo grupo de processo, fora dos limites do projeto, que tem a responsabilidade do processo de desenvolvimento do software em uma base organizacional.

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

O Processo de Engenharia de Processo dentro do ../res_processworkbench.htm -- This hyperlink in not present in this generated websiteRational Process Workbench contém informações sobre o Aprimoramento do Processo em uma definição organizacional.



Rational Unified Process   2003.06.15