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!