projeto: pbs equipe: alex bezerra bastos amivaldo batista dos santos francisco rosa santana irapuan...
TRANSCRIPT
Projeto: PBS
Equipe:Alex Bezerra BastosAmivaldo Batista dos Santos Francisco Rosa SantanaIrapuan Coleto BottossoJacson RodriguesSônia Maria PereiraValdemar Vicente Graciano Neto
Universidade Federal de GoiásInstituto de InformáticaProf. Juliano Lopes de Oliveira
Product Breakdown Structure
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
Projeto
Produto 1 Produto 2 Produto 3
Produto 4
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– Prof. Juliano Lopes de Oliveira
Equipe– 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 Evolução 3 – 04/05/2010 Evolução 4 – 18/05/2010 Evolução 5 – 01/06/2010 Evolução 6 – 15/06/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!