Planejando o projeto (CMMI)

O resultado desejado de planejar um projeto é um plano que inclui um escopo, uma cronograma, um orçamento, um plano de gerenciamento dos riscos, e um comprometida e uma aprovação de todos os participantes.Com um plano de projeto combinado, você deseja progride com análise, design, desenvolvimento, teste, e eventualmente entrega.

Você pode reduzir o risco usando um método iterativo de desenvolvimento.As iterações permitem que você demonstrar um produto em parte trabalhando no final da cada iteração e agir em comentários da demonstração.Portanto, o plano fornece uma maneira geral e é sujeita a revisão e o refinamento antes do início de cada iteração.

Neste tópico

• Coletando e modelagem os requisitos

• Criando incrementais requisitos de produto

• Inserindo e editando requisitos de produto

• Estimando requisitos do produto

• Requisitos de produto de atribuição para iterações

• Planejando teste

• Revisando requisitos do produto

Coletando e modelagem os requisitos

Esta atividade é a discussão sobre o que o sistema deve fazer, com participantes comerciais, usuários em potencial, e especialistas de assunto.É importante compreender o contexto de negócios.Se você for solicitado para escrever um aplicativo do agente de polícia, é útil entender seus jargão, procedimentos, e regras.

Os modelos de UML são uma ferramenta útil para expressar e pensar sobre relacionamentos complexas.Você pode desenhar-los em Visual Studio e links para outros documentos e itens de trabalho de Team Foundation .Para obter mais informações, consulte: Requisitos do usuário de modelagem..

Atualizar e refinar os requisitos de todo o projeto.Como cada iteração aproxima, adicione mais detalhes aos aspectos de modelo que são relevantes à iteração.O modelo, você pode derivar teste de verificação.

Para obter mais informações, consulte Developing Customer Requirements e O desenvolvimento de testes de um modelo.

Criando incrementais requisitos de produto

Os requisitos que você obteve dos seus clientes não são diretamente apropriados para a finalidade de agendar o desenvolvimento incremental.Por exemplo, para esclarecer o procedimento quando um usuário compra algo de um site, você pode ter escrito detalhada uma série de etapas: o cliente procurar o catálogo, adiciona o item para carro, confira o carro, endereço fontes, e paga-o; entrega de agendas de armazenamento; e assim por diante.Essas etapas, ou um diagrama equivalente de atividade, não são requisitos incrementais.

Em vez de isso, o primeiro incremento do seu sistema pode oferecer somente um item à venda, entregá-lo a apenas um endereço, e executar apenas uma transação de teste com o serviço de pagamento.O segundo incremento pode fornecer um catálogo que consistisse em uma lista simples.Um incrementos posteriores podem adicionar a opção de papel de embrulho compra ou de pedir catálogos que são fornecidos por fornecedores diferentes.Alguns incrementos podem ser sobre a qualidade de serviço, como a capacidade de manipular 1.000 clientes em vez de apenas um.

Ou seja os incrementos adiantados devem exercitar os principais exemplos de uso ponto-a-ponto e gradualmente adicionar funcionalidade em toda a árvore.

Se você trabalha com um produto existente, o princípio é o mesmo, mas você parte da funcionalidade existente.Se você é irrelevante com seu design interno, o custo das atualizações podem ser difíceis de estimar.Valem ser liberais com suas classificações para as alterações anteriores.

Para obter mais informações, consulte Requisitos desenvolvimento.

Inserindo e editando requisitos de produto

Registrar os requisitos incrementais do produto como itens de trabalho do requisito em Team Foundation, e defina os requisitos necessários para caracterizar.Você pode criar itens de trabalho do requisito em Team Explorer. Se você tiver vários itens de trabalho que você deseja criar ao mesmo tempo, você pode usar o conceito de Office Excel de consulta dos requisitos do produto.Para obter mais informações, consulte Trabalhando no Microsoft Excel e Microsoft Project conectado ao de Team Foundation Server e Executar o planejamento de cima para baixo usando uma lista de árvore de itens de trabalho (no Excel).

Estimando requisitos do produto

A equipe de desenvolvimento deve estimar o trabalho que são necessários para desenvolver cada requisito do produto.A avaliação deve ser incorporada para a hora original, no campo de avaliação de item de trabalho.

Em o início do projeto, uma avaliação bruta é tudo que é necessário.

Quebrar grandes requisitos de produto em menores.Idealmente, cada requisito do produto receberá apenas alguns dias de tempo de desenvolvimento.

Requisitos de produto de atribuição para iterações

Os representantes dos participantes comerciais e da equipe de desenvolvimento devem funcionar juntos para atribuir requisitos de produto para iterações.Normalmente, você faz isso em uma reunião, onde você compartilhe ou projeto a exibição de Office Excel de consulta dos requisitos do produto.

A atribuição é concluída usando os fragmentos de informação:

• A prioridade do requisito.Veja anotações na seção.

• . O custo moradoresDado o número de membros da equipe e o comprimento de iteração, cada iteração tem apenas um número fixo de tempo que está disponível para desenvolvimento.Além de isso, um número significativo de essas hora será usado para o planejamento de iteração e outras tarefas que não envolve diretamente o desenvolvimento.

• Dependências entre os requisitos do produto.Em uma série de incremental requisitos, os requisitos os mais simples devem ser abordados antes dos aprimoramentos na mesma área.

Você pode definir o requisito em um item de trabalho especificando uma variedade de informações, como as ilustrações a seguir mostram:

Algumas diretrizes em priorização

Vários esquemas detalhados existem para a priorização.Nós examinaremos algumas de elas quando nós consideramos planejamento de iteração.Por enquanto, em nível de projeto, nós incluímos algumas diretrizes que podem ser úteis para ajudar a gerencie riscos e otimizar o valor adicionado.

1. Prioridade a cenários ponto-a-ponto mínimos.

   Aponta obter um cenário de ponta a ponta tão simples no início do projeto como possível.Posteriormente, adicionar mais recursos para partes diferentes de cenário.Esta prática garante que as funções principais da plataforma e as exibições dos requisitos principais são tentadas no início.

   Por outro lado, não dividir a agenta de acordo com a arquitetura.Uma agenda terminar o banco de dados, então a lógica comercial e em seguida, na interface do usuário provavelmente irá precisar muito rework integrar partes no final.De a mesma forma, uma separação horizontal como {componente de vendas; componente de armazenamento; o componente de pagamento} não é recomendado.Provavelmente geraria um sistema maravilhoso para vender na Web mas executá-lo fora de tempo antes do negócio tem meios para obter dinheiro de seus clientes.Os componentes completos podem ser agendados para uma iterações posteriores somente se são realmente complementos opcional.

2. Prioridade o risco de serviço.

   Se um cenário inclui um elemento tecnicamente arriscado, desenvolva-o no início da agenda.Leva uma “falha no início do risco.” aproximam-seSe algo não pode ser feito, você quiser saber este no início do projeto para que ele possa ser cancelado ou substituído por uma abordagem alternativa.Requisitos de prioridade para a tecnicamente arriscados em iterações adiantadas.

3. Prioridade a redução de incerteza.

   Os participantes comerciais não serão algum sobre alguns requisitos.É difícil prever o comportamento do produto funcionará melhor no contexto de negócios.Prioridade ao trabalho que é provável reduzir as incertezas.Isso geralmente pode ser obtido desenvolvendo uma versão mais simples de cenário com que os usuários podem fazer experiências.Adia o cenário completo para uma iteração posterior, em que os resultados de essas experiências podem ser considerados.

4. Requisitos de prioridade a altamente importantes.

   Se possível, tente estabelecer uma função de oportunidade-custo -- atraso para cada cenário.Use esses para determinar os requisitos que potencialmente podem transferir mais valor para clientes anteriores.Prioridade a esses requisitos nas iterações anteriores.Isso pode comprá-lo a opção de liberar um produto parcial no início

5. Agrupar os cenários que são comuns a vários personas.

   Se você tiver cenários que têm o utilitário para dois ou mais personas, agrupar esses juntos.Classificar-los pelo número de personas que exigem o cenário.Prioridade para os cenários que se aplicam a um número maior de personas em iterações adiantadas.

6. Classificar personas.

   Personas representam os segmentos de mercado ou grupos de usuários.Pessoas ou os proprietários de marketing comerciais possam articular a prioridade de tais segmentos ou grupos com base no utilitário a ser enviados ou no valor do segmento.Se os segmentos ou grupos de usuários podem ser classificadas na prioridade mostrar isso, listando os personas para cada segmento classificação.Identifica os cenários para os personas classificados os mais alto, e prioridade a esses nas iterações anteriores na agenda.

Em geral, desejamos priorizar a redução de risco devido à possibilidade de falha.Desejamos priorizar a funcionalidade comum porque é provável de ser necessário e improvável de ser alterado.Desejamos priorizar aos requisitos mais importantes.Queremos ativar a opção para a versão anterior do produto a um subconjunto de personas dando a prioridade todos os cenários que são necessários para atender às necessidades de qualquer uma personalidade.

Planejando teste

A avaliação de trabalho para cada requisito deve incluir o esforço que é necessário testar o requisito, manualmente ou criando um teste automatizado.

Antes de ela ser considerado concluído, cada requisito do produto deve ser associado a um conjunto de itens de trabalho de situação de teste que demonstram juntos se o requisito foi atingido, e os testes devem passar por.

Quando você cria ou revisa requisitos do produto, o plano de teste correspondente deve ser atualizado.

Revisando requisitos do produto

Revisite esta atividade antes que cada iteração para considerar revisados e novos requisitos, prioridades revisadas, e avaliações revisadas.Haverá mais revisões nas primeiras iterações.

Após as primeiras iterações, os membros da equipe de desenvolvimento serão mais seguros sobre as classificações.Devem passar pelas avaliações para uma ou duas as seguintes iterações e para revisar o original estima campos de requisitos que são atribuídos 2 essas iterações.

Consulte também

Conceitos

Planejando e acompanhando projetos