Product Breakdown Structure

Apresentação em tema: "Product Breakdown Structure"— Transcrição da apresentação:

1 Product Breakdown Structure
Projeto: PBS Product Breakdown Structure Equipe: Alex Bezerra Bastos Amivaldo Batista dos Santos Francisco Rosa Santana Irapuan Coleto Bottosso Jacson Rodrigues Sônia Maria Pereira Valdemar Vicente Graciano Neto Universidade Federal de Goiás Instituto de Informática Prof. Juliano Lopes de Oliveira

2 Problema O desenvolvimento de projeto para qualquer área fim envolve uma variedade de entregáveis. Marcos que representam a evolução do processo. Há a dificuldade de monitorar de forma sistêmica o desenvolvimento do projeto. Registrar histórico de eventos durante a execução do projeto.

3 Medidas de sucesso Clientes satisfeitos com o produto final
Benefícios esperados do projeto são colhidos Equipe desfruta de boa qualidade de vida ao longo do projeto Clientes satisfeitos com o progresso e produtos intermediários

4 Oportunidade de negócio
Desenvolvimento da PBS – Product Breakdown Structure

5 Benefícios esperados Controle do progresso das atividades
Controle dos entregáveis ao longo do projeto Visualização macro das etapas do projeto

6 Stakeholders Patrocinador Equipe Prof. Juliano Lopes de Oliveira
Gerente de projetos (Francisco) Analista de requisitos (Jacson, Valdemar e Sônia) Projetista (Irapuan) Desenvolvedor (Francisco, Valdemar e Irapuan) Analista de teste (Alex e Sônia) Analista de suporte (Alex)

7 Etapas do projeto Processo iterativo (Semanal)
Período de 31/03/2010 à 24/06/2010

8 Entregas Evolução 1 – 06/04/2010 Evolução 2 – 20/04/2010
Produto – 24/06/2010 Evoluções 2, 4 e 6 terão validações funcionais.

9 Premissas Projeto deve ser entregue até 24/06/2010.

10 Restrições Participação ativa do patrocinador
Iterações semanais para acompanhamento do projeto, tendo dia acordado com o cliente.

11 Comunicação Assembla Relatório de acompanhamento

12 Agenda para Requisitos
Apresentação para o papel Professor Apresentação para o papel Patrocinador – Reunião de Eliciação de Requisitos

13 Cliente: Professor Apresentação das Técnicas Elucidadas pelo grupo
JAD (Joint Application Design) Etnografia Prototipagem Entrevista 5W2H Questionário Brainstorming Storyboarding

14 Cliente: Professor Análise de Viabilidade de Aplicação das Técnicas
JAD (Joint Application Design) Etnografia Prototipagem Entrevista 5W2H Questionário Brainstorming Storyboarding

15 Cliente: Patrocinador
Apresentação de Storyboarding associado a Protótipos

16 Cliente: Patrocinador
Reunião para Eliciação de Requisitos Apresentação de Papéis Entrevistador 1: Valdemar Entrevistador 2: Irapuan Escrevente 1: Francisco Escrevente 2: Sônia Escrevente 3: Amivaldo Moderador: Alex

17 Cliente: Patrocinador
Reunião para Eliciação de Requisitos Questionamentos: Necessidade N1: “Deverá ser possível gerar a PBS inicial de um software a partir dos produtos previstos nas atividades de um workflow definido para um projeto de desenvolvimento ou manutenção de software. ” Pergunta: Como o cliente deseja que o workflow seja definido? Ele pode ser importado a partir de um arquivo que represente o processo ou deve ser possível cadastrar o workflow dentro do software a ser construído, através de formulários de cadastro?

18 Cliente: Patrocinador
Reunião para Eliciação de Requisitos Questionamentos: Necessidade N2: “Deverá ser possível atualizar uma PBS de software a partir dos produtos previstos nas atividades de um workflow definido para um projeto de manutenção deste software. ” Pergunta: N1 e N2 não são redundantes?

19 Cliente: Patrocinador
Reunião para Eliciação de Requisitos Questionamentos: Necessidade N4: “Deverá ser possível visualizar a PBS de um projeto com as seguintes opções de visualização: a. a porcentagem de finalização dos produtos, ou seja, para cada produto da PBS visualizar o percentual do produto já foi concluído (0% para não iniciado, e 100% para produto terminado); Pergunta: O usuário é quem vai controlar a porcentagem de término dos produtos? Devemos disponibilizar formulários para cadastro e modificação de porcentagens de finalização de produtos?

20 Cliente: Patrocinador
Reunião para Eliciação de Requisitos Questionamentos: Necessidade N4.f: “o status de cada produto em termos de aprovação (quando pertinente) e de pendências relacionadas a cada produto”. Pergunta: Existe um conjunto comum de pendências dentro do domínio ou o usuário deve poder cadastrar qualquer tipo de pendência, não sendo os valores de pendências pré-definidos?

21 Cliente: Patrocinador
Reunião para Eliciação de Requisitos Questionamentos: Necessidade N4.g: “as comunicações geradas em relação a cada produto”. Pergunta: O que seriam estas comunicações?

22 Cliente: Patrocinador
Reunião para Eliciação de Requisitos Questionamentos: Necessidade N5: “Deverá ser possível apresentar a PBS de um software, sem nenhuma referência aos projetos que o desenvolveram ou modificaram”. Pergunta: A N4 usa a palavra visualizar. Há uma diferença intencional ou são sinônimos neste contexto? E o que viria a ser “sem nenhuma referência aos projetos que o desenvolveram ou modificaram”

23 Cliente: Patrocinador
Reunião para Eliciação de Requisitos Questionamentos: Necessidade N5.c: “os recursos humanos utilizados para a geração de cada produto”. Pergunta: N5.c parece redundante com N4.h. Elas são realmente? Necessidades N5.e e N5.f são semelhantes a N4.e e N4.g respectivamente. Isto caracteriza redundância?

24 Cliente: Patrocinador
Reunião para Eliciação de Requisitos Questionamentos adicionais do grupo.

25 Obrigado!