Finalidade
  • Elaborar um caso de desenvolvimento que descreva o processo de desenvolvimento de software para um projeto (ou projetos).
  • Relacionar o caso de desenvolvimento ao produto de processo específico da organização.
Passos
Artefatos Informados:   Artefatos Resultantes:  
Freqüência: Uma vez a cada iteração no projeto de software.
Papel: Engenheiro de Processo
Diretrizes:
Mentores de Ferramentas:

Detalhamentos do Fluxo de Trabalho:

Um caso de desenvolvimento é elaborado para ser usado em um projeto de desenvolvimento de software.

A organização e o plano de fase do projeto causam um forte impacto sobre processos e vice-versa. Portanto, a elaboração do caso de desenvolvimento deve ser coordenada com o desenvolvimento do plano de projeto. Consulte o Artefato: Plano de Desenvolvimento de Software, seção "Plano de Projeto", para obter mais detalhes. Por exemplo, se o projeto decidir usar um outro conjunto de fases diferente do utilizado no Rational Unified Process (RUP), esse conjunto deverá ser capturado no caso de desenvolvimento.

A escolha dos itens de configuração do projeto também causam um impacto sobre processos e vice-versa. Portanto, a elaboração do caso de desenvolvimento deve ser coordenada com o desenvolvimento do plano de gerenciamento de configuração. Os itens de configuração são definidos no plano de gerenciamento de configuração. Consulte o Artefato: Plano de Gerenciamento de Configuração e Conceitos: Estrutura de Diretórios do Produto.

Analisar o Projeto e a Organização Início da página

O Artefato: Avaliação da Organização de Desenvolvimento contém informações sobre o projeto e a organização. Analise os fatores para decidir como eles deverão afetar o caso de desenvolvimento. Consulte Diretrizes: Discriminantes do Processo para obter diretrizes sobre como os principais fatores influenciam a escolha do processo.

Definir Escopo Início da página

Defina quais disciplinas serão abordadas no caso de desenvolvimento verificando os seguintes aspectos da Avaliação da Organização de Desenvolvimento:

  • Á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. Você pode enfatizar a introdução de algumas partes do RUP, a fim de solucionar problemas nos processos já existentes.  Consulte Conceitos: Implementação de um Processo em um Projeto, seção "Melhoria de Processos e 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 Conceitos: Implementação de um Processo em um Projeto, seção "Mudança Geral", para obter detalhes. 
  • Problemas no processo existente. Priorize a melhoria das áreas em que a organização tem apresentado problemas.
  • As ferramentas que eles planejam usar. Se o projeto decidiu usar certas ferramentas, o caso de desenvolvimento, normalmente, deve abranger 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. O caso de desenvolvimento deve abranger essas áreas. Certifique-se de que as informações corretas possam ser facilmente encontradas no RUP.

Implemente o RUP iterativamente, como descrito em Conceitos: Implementação de um Processo em um Projeto. O caso de desenvolvimento não precisa capturar todo o processo. Prepare-se para não abranger todas as disciplinas, ignore disciplinas e delegue responsabilidades de processo. Consulte "Delegação de Responsabilidades de Processo" em Diretrizes: Caso de Desenvolvimento.

Documente o resultado na seção "Escopo" no Caso de Desenvolvimento.

Decidir como Executar cada Disciplina Início da página

Depois de escolher quais disciplinas precisam ser incluídas, decida as seguintes questões sobre cada uma: 

  • Como executar o fluxo de trabalho. 
  • Que partes do fluxo de trabalho devem ser usadas. 
  • Quando, durante o ciclo de vida do projeto, introduzir os fluxos de trabalho e suas partes. 

Para ajudá-lo a escolher, existe uma seção "Decidir como Executar o Fluxo de Trabalho", sobre cada uma das seguintes diretrizes:

Ao considerar a introdução de determinada disciplina, ou parte dela, leve em conta:

  • Aplicabilidade. É aplicável para o projeto? É vantajoso incluí-la?
  • Problemas e causas originais abordados. Ela aborda os problemas percebidos e suas causas originais?
  • Ferramentas de Suporte. Que ferramentas de suporte são necessárias?
  • Tempo. Quando, durante o ciclo de vida do projeto, ela deve ser introduzida? Consulte Conceitos: Implementação de um Processo em um Projeto para obter mais informações.
  • Custo de implementação. Qual é o seu custo de implementação no projeto? Esse procedimento inclui:
    • Custo com o treinamento de membros do projeto. 
    • Custo com a instalação de ferramentas de suporte.
    • Custo com o desenvolvimento de guias e templates.

Adaptar Artefatos por Disciplina Início da página

Adapte os artefatos para cada disciplina. Consulte Diretrizes: Adaptação do Processo.

Não execute todas as disciplinas de uma vez - concentre-se na próxima disciplina a ser aplicada no projeto. Siga estes passos:

  1. Decida como o artefato (elemento ou documento de modelagem) deve ser usado (consulte Diretrizes: Classificação de Artefatos para obter mais informações):
    • Necessário.
    • Recomendável
    • Possível
    • Desnecessário
  2. Decida o nível de revisão de cada artefato e capture-o em "Revisar Detalhes". Para obter detalhes, consulte Diretrizes: Níveis de Revisão. Decida como revisar o artefato, ou seja, quais procedimentos de revisão serão usados. 
  3. Decida como capturar os resultados finais de uma disciplina. É necessário guardar os resultados impressos em papel? Se preciso, você deverá escolher um ou mais relatórios que extraiam os resultados das ferramentas e imprimi-los. 
  4. Decida quais ferramentas serão usadas para desenvolver e manter o artefato.
  5. Decida quais propriedades serão usadas e como usá-las. Consulte a tabela de Propriedades sobre cada artefato e a seção intitulada "Adaptação" de cada artefato.
  6. Quando relevante, decida quais estereótipos serão usados. Para cada artefato, consulte a seção "Adaptação."
  7. Decida sobre uma descrição dos artefatos de documento. Para o respectivo artefato, consulte a seção "Breve Resumo."

Além desses passos:

  • Decida os relatórios a serem usados. Decida se você precisará de relatórios de trabalho para extrair informações dos modelos e documente-as em papel para futuras revisões. Esses relatórios de trabalho são geralmente tratados casualmente, pois são temporários e serão descartados assim que a revisão for concluída. Consulte "Relatórios" para obter um exemplo de diversos relatórios predefinidos que podem ser usados. Talvez seja preciso adaptar o resumo.

Há ainda mais questões a serem decididas para cada disciplina. Consulte as diretrizes referentes a cada disciplina para obter mais detalhes:

Modificar Disciplinas e Atividades Início da página

Analise o conjunto modificado de artefatos e as atividades que utilizam, criam e atualizam esses artefatos. Decida se os artefatos devem ser modificados ou simplificados. Lembre-se de que há artefatos indicados para cada atividade informada e resultante. Certifique-se de excluir passos ou atividades desnecessários. Considere o seguinte:

  • Introduza novos passos e possivelmente novas atividades que reflitam os artefatos, os relatórios e os documentos que precisaram ser acrescentados.
  • Verifique como as ferramentas usadas podem facilitar, automatizar ou, até mesmo, excluir alguns passos.
  • Inclua nas atividades diretrizes e regras específicas desenvolvidas com base na experiência da organização. Elas podem ser acrescentadas como pontos de orientação e verificação, itens de revisão ou documentos separados para referência.
  • Depois de saber quais são as atividades necessárias, volte aos fluxos de trabalho que indicam como as atividades interagem, e remova-as ou inclua outras caso seja necessário.
  • Disciplinas inteiras podem ser omitidas ou criadas.
  • Pode ser preciso introduzir papéis adicionais para tratar de atividades especiais que requerem habilidades específicas.

Descreva as mudanças no Caso de Desenvolvimento.

Escolher Modelo de Ciclo de Vida Início da página

Escolha o tipo de modelo de ciclo de vida empregado pelo projeto. Refine o modelo do RUP e ajuste marcos, assim como os critérios de avaliação de marcos, se for necessário. Você pode preferir omitir uma ou várias fases, e também adicionar ou remover marcos. Consulte Fases e Conceitos: Iteração para obter mais informações e idéias. Documente o modelo de ciclo de vida do projeto na seção "Visão Geral do Caso de Desenvolvimento".

Descrever Planos de Iteração de Exemplo Início da página

Descreva pelo menos um plano de iteração de exemplo (mais provavelmente você descreverá vários planos) para cada fase. Esses planos de iteração descrevem como o projeto funcionará em várias iterações e fases do projeto. A finalidade dos planos de iteração de exemplo no caso de desenvolvimento é descrever as atividades que o projeto executará e a ordem de execução dessas atividades. Dessa forma, servem como um plano de iteração mais detalhado. O plano de iteração de exemplo é importante como meio de os membros da equipe entenderem como o processo será aplicado.

A descrição do plano de iteração de exemplo deve ser concisa. Não inclua detalhes que pertencem a atividades, artefatos e diretrizes. Você pode preferir descrever o plano de iteração de exemplo em termos de atividades ou detalhamentos de fluxo de trabalho.

Esses fluxos de trabalho de iteração podem ser capturados textualmente (ou graficamente), como nos planos de iteração de exemplo que integram o RUP (consulte Fases).

Na maioria dos casos, você deve descrever pelo menos um plano de iteração de exemplo por fase. Descreva os planos de iteração de exemplo quando necessário. No início de um projeto, não há motivo para descrever como será o trabalho durante a fase de Transição. Comece definindo como o projeto funcionará na fase de Iniciação.

Identificar Envolvidos Início da página

O papel Envolvido representa todos os possíveis envolvidos em um projeto. É preciso identificar e descrever os diversos tipos de envolvidos, suas necessidades e responsabilidades. Representantes do cliente, representantes do usuário, investidores, gerentes de produção e compradores são exemplos de envolvidos.

Descreva os diversos envolvidos e suas necessidades no caso de desenvolvimento, na seção "Papéis".

Mapear Papéis para Cargos Início da página

Em algumas organizações de desenvolvimento, os cargos são definidos. Se esses cargos são usados comumente e são amplamente aceitos na organização, pode ser útil fazer um mapeamento entre os papéis no RUP e os cargos na organização. O mapeamento de cargos para papéis pode facilitar o entendimento do pessoal da organização sobre como empregar o RUP. O mapeamento também pode ajudá-los a entender que papéis e cargos não são a mesma coisa, o que é uma idéia incorreta. Documente o mapeamento no caso de desenvolvimento, seção "Papéis".

Documentar o Caso de Desenvolvimento Início da página

Descreva o caso de desenvolvimento. Você deve descrever o caso de desenvolvimento em páginas da Web, com hyperlinks para o RUP on-line e outras diretrizes. Esse procedimento será explicado na seção "Representação de um Caso de Desenvolvimento On-line" em Diretrizes: Caso de Desenvolvimento. Use o Exemplo: Caso de Desenvolvimento como ponto de partida. Consulte também Kit de Ferramentas: Criação de um Caso de Desenvolvimento Usando o Rational Unified Process e Kit de Ferramentas: Criação de Páginas da Web.

Manter o Caso de Desenvolvimento Início da página

Muitas decisões devem ser tomadas antes do início do projeto. Após cada iteração do projeto de desenvolvimento de software, avalie o processo e reconsidere as decisões tomadas. Se houver uma nova versão do RUP, você deverá atualizar o caso de desenvolvimento. Para obter uma explicação, consulte Kit de Ferramentas: Atualização do Rational Unified Process.



Copyright  (c) 1987 - 2001 Rational Software Corporation


Exibir o Rational Unified Process usando quadros

Rational Unified Process