Compartilhar via


Atividades de projeto

Para fazer o uso mais eficiente do MSF para Melhoria do Processo de CMMI, você deve organizar seu projeto em uma série de iterações, normalmente entre quatro e oito semanas. Isso ajuda a reduzir os riscos para seu projeto que derivam dos requisitos em constante mudança e dos custos de implementação. A estrutura iterativa de projeto é uma contribuição importante para atender aos requisitos de gerenciamento dos riscos do CMMI.

No início do projeto

Início do projeto

O início inclui a definição da visão do projeto, que indica o que os usuários poderão fazer quando o projeto liberar o produto.

Também inclui configurar a equipe, a infraestrutura, e outros recursos, e determinar o processo de desenvolvimento.

Para obter mais informações, consulte Incepção de projeto.

Planejamento de projeto inicial

O planejamento do projeto inclui as seguintes atividades:

  • A análise bem detalhada dos requisitos permite a formação de um plano. Essa análise pode incluir o uso de modelos de requisitos, storyboards e outras ferramentas que ajudam a imaginar o sistema de trabalho.

  • Planejando um projeto geral ou uma arquitetura do sistema. Se isso incluir trabalhar em uma plataforma que é nova para os membros da equipe, eles deverão ter algum tempo para testá-la. O desenvolvimento será lento em iterações anteriores.

  • Conversão dos requisitos como um conjunto de requisitos incrementais do produto cujo desenvolvimento pode ser estimado. A diferença entre requisitos gerais e requisitos do produto é importante, e esta é uma atividade significativa. Para obter mais informações, consulte Requisitos de desenvolvimento.

  • Fazendo uma atribuição inicial dos requisitos de produto para as iterações.

  • Configuração de datas para versões.

Os modelos de plano e requisitos serão revisitados e refinados em todo o projeto. A parte da finalidade do desenvolvimento iterativo é permitir melhorias nos requisitos que provêm da demonstração do software de trabalho em um estágio inicial.

O planejamento de projeto inicial é feito na iteração 0.

Para obter mais informações, consulte Planejar um projeto (CMMI).

Explorando um produto existente

O objetivo do seu projeto pode ser atualizar um produto que já existe. Nesse caso, se a equipe não estiver familiarizada com o produto, a exploração do código é uma atividade para a iteração 0. Cada tarefa de desenvolvimento em iterações subsequentes também envolverá a compreensão do código em um local específico e o rastreamento das consequências de alterá-lo.

Para obter mais informações, consulte Visualizar código.

Durante o projeto

O plano é revisado e está sujeito a alterações em todo o projeto.

Várias atividades relacionadas ao plano de projeto são executadas regularmente em todo o projeto, geralmente, para o final de uma iteração.

Validação

Demonstre a seus clientes ou participantes de negócio o software que foi desenvolvido durante a iteração. Quando possível, libere-o de modo que elas possam testá-lo ou usá-lo até certo ponto em um contexto prático.

Após um intervalo adequado, organize uma reunião para analisar os comentários do usuário. Os comentários devem ser usados para gerar solicitações de alteração.

Para obter mais informações, consulte Validation.

Gerenciamento de riscos

Verifique a probabilidade e o impacto de possíveis eventos adversos e siga as etapas para reduzir os riscos. Para obter mais informações, consulte Gerenciar riscos.

Alterar gerenciamento

Você pode usar itens de trabalho de solicitação de alteração para gravar alterações nos requisitos que são declarados pelos participantes de negócios. Eles podem derivar de alterações no contexto de negócios, mas também da demonstração e das versões de avaliação de versões anteriores do produto. Essas alterações devem ser bem vistas porque aprimoram a aptidão do seu produto a sua finalidade comercial. Esse efeito faz parte do objetivo de desenvolvimento incremental.

Algumas equipes de projeto ajustam os itens de trabalho dos requisitos do produto quando são solicitadas alterações, sem usar um item de trabalho separado. Mas a vantagem do item de trabalho da solicitação de alteração é que, na parte mais recente do projeto, você pode revisar o número e a natureza das alterações feitas. Você pode usar essas informações para melhorar o processo ou a arquitetura para o futuro.

As solicitações de alteração devem ser usadas como entrada para a revisão de plano do produto.

Para obter mais informações, consulte Gerenciar alterações.

Revisão de plano do produto

Armazene uma revisão de plano de produto antes de planejar cada iteração. O plano de projeto atribui requisitos de produto a iterações.

O plano será alterado por dois motivos principais:

  • Alterações nos requisitos.

  • Alterações em estimativas feitas pelos desenvolvedores. Conforme o projeto progride, a equipe de desenvolvimento pode fazer estimativas mais confiáveis do trabalho que será necessário para implementar recursos futuros. Em alguns casos, algumas funcionalidades podem ter sido adiadas de uma iteração anterior, que adiciona um recurso ao plano.

Ambos os tipos de alteração ficam menos frequentes em iterações posteriores.

Revise os modelos de requisitos dos quais os requisitos do produto são derivados.

Revise a atribuição de requisitos para iterações. Assim como na atividade inicial de planejamento, os participantes do negócio fornecem as prioridades, a equipe de desenvolvimento fornece as avaliações, e a reunião manipula os recursos entre as iterações.

Para obter mais informações, consulte Planejar um projeto (CMMI).

Antes das principais versões do produto

As atividades envolvidas na implantação de um produto variam de acordo com o seu tipo e não são tratadas aqui.

Considere os seguintes pontos com relação às iterações posteriores de desenvolvimento de software:

  • Exclua mudanças importantes no design para evitar a possibilidade de problemas imprevisíveis.

  • Gere a barra de alterações e bugs em reuniões de triagem. As alterações e as correções de bug propostas devem ser rejeitadas, a menos que tenham efeitos significativos na usabilidade e adequação à finalidade do produto.

  • Dedicar recursos à cobertura crescente de teste e à execução de testes manuais.

Consulte também

Conceitos

Plano de fundo para CMMI