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

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.

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

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

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

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)

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

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.

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

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

Comunicação Assembla E-mail Relatório de acompanhamento

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

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

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

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

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

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?

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?

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?

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?

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?

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”

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?

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

Obrigado!