Plano de Projeto

<Nome do Projeto>

Versão 1.0

Histórico de Revisão

Data	Versão	Descrição	Autor
06/04/2010	1.0

Tabela de Conteúdos

Project Charter	5

1	Membro da Equipe	5

1.1	Designação.	5

1.2	Responsabilidades.	5

1.3	Autoridade.	5

2	Escopo.	5

2.1	Objetivos:	5

2.2	Metas:	5

2.3	Premissas.	5

2.4	Restrições.	5

2.5	Riscos.	5

2.6	Prazo:	5

2.7	WBS do Projeto (Escopo).	6

2.8	Principais envolvidos.	6

2.9	Comentários.	6

2.10	Aprovado por.	6

Especificação de Requisitos de Software	7

1	Introdução	7

2	Escopo deste documento	7

3	Requisitos	7

3.1	Requisitos Funcionais	7

3.2	Requisitos Não-Funcionais	7

3.3	Requisitos de Interface	7

3.4	Requisitos de Documentação	7

WBS Expandida	8

1	Gerenciamento.	8

1.1	Atividade 01.	8

1.1.1	Tarefa 01.	8

1.1.2	Tarefa 02.	8

1.2	Atividade02.	8

1.2.1	Tarefa 01.	8

Cronograma do Projeto	10

Lista de Atividades	11

Plano de Métricas	12

1	Nome da Organização	12

1.1	Objetivos Organizacionais.	12

1.1.1	Objetivo.	12

2	Nome do Projeto	12

2.1	Objetivos	12

2.1.1	Objetivo.	12

2.2	Métricas.	12

2.2.1	Métrica.	12

Plano de Riscos	14

1	Introdução	14

2	Finalidade	14

3	Escopo	14

4	Definições, Acrônimos e Abreviações	14

5	Referências	14

6	Visão Geral	14

6.1	Sumário de Riscos	14

6.2	Tarefas de Gerenciamento de Riscos	14

6.3	Organização e Responsabilidades	15

6.4	Orçamento	15

6.5	Ferramentas e Técnicas	15

6.6	Itens de Risco a Serem Gerenciados	15

1	Objetivo	16

2	Cenários	16

3	Pré-requisitos para os testes	16

4	Requisitos para os testes	16

5	Documentos Auxiliares	16

6	Estratégia de Teste	16

7	Ambiente de teste	16

8	Características de Qualidade	17

9	Relação dos Casos de Uso	17

10	Relação de Casos de Testes	17

11	Observações	17

12	Anexo I	17

Project Charter

Membro da Equipe

Designação.

<Descrevem-se aqui as designações de cada integrante do projeto.

Coloca-se informações sobre o papel a ser desempenhado no projeto, a sua descrição (destacar a importância do papel) e também a quem o membro do projeto responde.>

Responsabilidades.

<Descrevem-se pontualmente as responsabilidades do membro da equipe>

Autoridade.

<Descrevem-se aqui as fronteiras de autoridade que membro do projeto possui, devem ficar claros os limites de autoridade (à quem responde, quem responde para ele, entre outros>

Escopo.

Objetivos:

<Descrever o objetivo do projeto de modo geral.>

Metas:

<Descrever as metas a serem alcançadas pontual e ordenadamente. (quebra dos objetivos em metas menores)>

Premissas.

<Descrição pontual das premissas de realização do projeto>

Restrições.

<Descrição pontual de possíveis restrições e contratempos que possam ocorrer durante o projeto>

Riscos.

<Descrição pontual e ordenada dos riscos e suas implicações para o projeto.>

Prazo:

<Estimativa de prazo (intervalo de datas).>

WBS do Projeto (Escopo).

Principais envolvidos.

<Citação e descrição dos principais envolvidos para o desenvolvimento do projeto, organizações, empresas, instituições órgãos. Informações sobre o envolvimento de cada um.>

Comentários.

<Fornecem-se aqui informações extras sobre o projeto.>

Aprovado por.

<Nome e assinatura dos aprovadores do projeto.>

_______________________________

Especificação de Requisitos de Software

Introdução

<Introdução do Documento de Especificação de Requisitos de Software.>

Escopo deste documento

<Escopo do documento de Especificação de Requisitos de Software.>

Requisitos

Requisitos Funcionais

Requisito Funcional 1

Requisito Funcional 2

Requisito Funcional 3

Requisito Funcional n

Requisitos Não-Funcionais

Requisito Não-Funcional 1

Requisito Não-Funcional 2

Requisito Não-Funcional 3

Requisito Não-Funcional n

Requisitos de Interface

Requisito de Interface 1

Requisito de Interface 2

Requisito de Interface 3

Requisito de Interface n

Requisitos de Documentação

Requisito de Documentação 1

Requisito de Documentação 2

Requisito de Documentação 3

Requisito de Documentação n

WBS Expandida

<Dicionário da WBS.>

Gerenciamento.

<Descrição do branch da WBS.>

Atividade 01.

<Descrição da Atividade.>

Tarefa 01.

<Descrição da Tarefa>

Tarefa 02.

<Descrição da Tarefa.>

Atividade02.

<Descrição da Atividade.>

Tarefa 01.

<Descrição da Tarefa.>

Funcionalidade 01.

Descrição do branch da WBS.

Atividade 01.

Descrição da Atividade.

Atividade 02.

Descrição da Atividade.

Funcionalidade 02.

Descrição do branch da WBS.

Atividade 01.

Descrição da Atividade.

Tarefa 01.

Descrição da Tarefa.

Tarefa 02.

Descrição da Tarefa.

Funcionalidade 03.

Descrição do branch da WBS.

Atividade 01.

Descrição da Atividade.

Área de Negócios.

Descrição do branch da WBS.

Atividade 01.

Descrição da Atividade.

Cronograma do Projeto

#	Atividades	Duração	Data Inicio	Data fim	Recursos	Precursoras
Grupo de Atividade	x+y horas	dd/mm/aaaa	dd/mm/aaa
1	Atividade 01	x = a+ b horas	dd/mm/aaaa	dd/mm/aaa
2	Tarefa 01	a horas	dd/mm/aaaa	dd/mm/aaa
3	Tarefa 02	b horas	dd/mm/aaaa	dd/mm/aaa	Tarefa 02
4	Atividade 02	Y horas	dd/mm/aaaa	dd/mm/aaa	Atividade 01
Grupo de Atividade
5
6

Lista de Atividades

Finalidade

<Finalidade da Lista de Tarefas e Atividades>

Descrição das Atividades

Atividade 1

<Descrição da Atividade 1>

Plano de Métricas

Nome da Organização

<Informar uma breve descrição sobre a organização.>

Objetivos Organizacionais.

<Aqui são descritos os objetivos em nível organizacional. Ou seja, que podem ser aplicado á todos os projetos ou a um subconjunto dos projetos realizados pela organização. Estes objetivos são estabelecidos pela alta gerência da organização e pode ser como exemplo a tomada de decisões estratégicas, comparação de produtividade entre equipes.

A partir destes objetivos se derivarão as métricas globais. Porém elas só serão definidas. O modo de como elas serão utilizadas será definido dentro de cada projeto.>

Objetivo.

<Descrição do objetivo.

Métricas Sugeridas. Numero da Equipe, Linhas de Código produzidas por dia.

OBS: Podem existir quantos objetivos organizacionais quanto forem necessários.>

Nome do Projeto

<Breve descrição do projeto ao qual o plano de métricas será aplicado.

Esta descrição deve conter informações como Natureza, tipo do projeto, tecnologias para seu desenvolvimento (linguagem, IDEs, plataforma, etc.), equipe de desenvolvimento, responsável pelo projeto. Prazos e custos se conveniente.>

Objetivos

<Devem-se informar aqui os objetivos do projeto, dos quais serão derivadas as métricas, o seja, o que se deseja alcançar com a aplicação das métricas.

OBS: Um projeto pode ter vários objetivos>

Objetivo.

<Descrição do objetivo do projeto.

Métricas Sugeridas. Numero da Equipe, Linhas de Código produzidas por dia por cada membro da equipe.

OBS: Podem existir quantos objetivos de projeto quanto forem necessários.>

Métricas.

Métrica.

<Descrição breve sobre a métrica.>

Por que

<Relaciona-se a métrica com o objetivo ao qual ela atenderá. Uma métrica pode estar relacionada a um ou mais objetivos e estes objetivos podem ser tanto organizacionais quanto de projeto

É conveniente explicar como a métrica pode atingir os objetivos. Ex. A métrica de linhas de código produzidas ao ser combinada com a métrica quantidade de pessoas na equipe e com uma escala de tempo irá nos dar informações sobre a produtividade de cada equipe em um determinado período de tempo.>

O que

<Nesta sessão deve-se informar o que será coletado pela métrica. Ex. para a Métrica Quantidade de Linhas Produzidas deve-se informar quantas linhas foram produzidas, também se deve guardar junto com a quantidade de linhas produzidas a data em que foi realizada a coleta.

É conveniente neste ponto definir a escala que a métrica utilizará.>

Aonde

<Define-se o lugar em que os dados necessários para as métricas serão capturados. Ex. para a métrica Quantidade de Linhas Produzidas: Os dados para alimentação da métrica estabelecida serão adquiridos no repositório do projeto em questão.>

Quando

<Define-se quando as coletas serão realizadas, esta definição pode ser feita tanto periodicamente quanto pontualmente. Ex. para a métrica Quantidade de Linhas Produzidas: A coleta de dados para a métrica estabelecida deverá ser realizada diariamente deste o dia “dd/mm/aaaa” até o dia “dd/mm/aaaa”. Ou ainda, deve ser realizada nos dias dd, dd, dd de mm de aaaa.

Ainda pode-se estabelecer uma relação com o gerenciamento do projeto, ou seja, quando realizar a coleta dos dados pode estar relacionado de acordo com o processo de desenvolvimento, ao final de cada iteração, de cada fase. E também pode-se usar referenciais tais como, a partir do inicio do projeto, metade do projeto, fim do projeto, ao iniciar a fase de implantação do projeto.>

Como

<Define-se como os dados para a métrica serão coletados. Ex. para a métrica Quantidade de Linhas Produzidas: A coleta de dados será realizada a partir da contagem do total de linhas que estão no repositório subtraído da quantidade de linhas coletadas anteriormente, obedecendo a seguinte formula. [qtd. Linhas Existentes no Repositório] – [Quantidade de Linhas da Ultima Coleta] = [Quantidade de Linhas Produzidas].

Caso a coleta se utilize de alguma ferramenta para sua execução deve ser informado neste ponto. Ex. A coleta de dados deve ser realizada através da ferramenta lineCount.

Também é conveniente definir aonde as métricas serão armazenadas.>

Quem

<Neste ponto, define-se o responsável pela coleta, e armazenamento da métrica.

Ex. O responsável pela coleta, armazenamento e manutenção da métrica é o gerente de projeto José da Silva da equipe de desenvolvimento b.>

Plano de Riscos

Introdução

<A introdução do Plano de Gerenciamento de Riscos oferece uma visão geral do documento todo. Ela inclui a finalidade, o escopo, as definições, os acrônimos, as abreviações, as referências e uma visão geral deste Plano de Gerenciamento de Riscos.>

Finalidade

<Especifique a finalidade deste Plano de Gerenciamento de Riscos.>

Escopo

<Uma breve descrição do escopo deste Plano de Gerenciamento de Riscos; os Projetos aos quais ele está associado e tudo o que é afetado ou influenciado por este documento.>

Definições, Acrônimos e Abreviações

<Esta subseção apresenta as definições de todos os termos, acrônimos e abreviações necessários para a correta interpretação do Plano de Gerenciamento de Riscos. Essas informações podem ser fornecidas mediante referência ao Glossário do projeto.>

Referências

<Esta subseção apresenta uma lista completa de todos os documentos mencionados no Plano de Gerenciamento de Riscos. Identifique cada documento por título, número do relatório (se aplicável), data e organização de publicação. Especifique as fontes a partir das quais as referências podem ser obtidas. Essas informações podem ser fornecidas por um anexo ou outro documento.>

Visão Geral

<Esta subseção descreve o conteúdo restante do Plano de Gerenciamento de Riscos e explica como o documento está organizado.>

Sumário de Riscos

<[Uma breve descrição do projeto e um resumo do risco total envolvido no projeto.>

Tarefas de Gerenciamento de Riscos

<Uma breve descrição das tarefas de gerenciamento de riscos a serem executadas durante o projeto. Nesta seção, você deve descrever o seguinte:

A abordagem a ser adotada para identificar riscos e como a lista de riscos será analisada e priorizada.

As estratégias de gerenciamento de riscos que serão usadas, incluindo estratégias de diminuição, anulação e/ou prevenção para os riscos mais significativos.

Como o status de cada risco significativo e as respectivas atividades de diminuição serão monitorados.

Cronogramas de revisão e relatório de riscos. Uma revisão dos riscos deve fazer parte da revisão de aceitação de cada iteração ou fase.>

Organização e Responsabilidades

<Uma lista das pessoas ou grupos específicos envolvidos nas atividades de gerenciamento de riscos do projeto e uma descrição das tarefas e responsabilidades de cada um deles.>

Orçamento

<O orçamento disponível para o gerenciamento dos riscos do projeto (quando essas informações ainda não estiverem incluídas no orçamento geral do projeto).>

Ferramentas e Técnicas

<Uma lista das ferramentas e técnicas que serão usadas para armazenar informações sobre riscos, avaliar riscos, monitorar o status dos riscos ou gerar relatórios de gerenciamento de riscos.>

Itens de Risco a Serem Gerenciados

<Uma lista dos itens de risco que foram identificados. Poderá ser um link para Artefato: Lista de Riscos do projeto.

Uma das melhores práticas do setor é publicar e manter visível uma lista dos 10 principais riscos que são considerados significativos o bastante para o projeto empregar recursos para o seu gerenciamento. Você poderá manter uma lista maior se assim for exigido pela prática organizacional ou pelo contrato.

Indicadores de que o risco está sendo detectado e estratégias de diminuição, anulação ou prevenção são identificados para cada risco listado.

Alguns riscos também exigirão uma descrição da ação que está condicionada ao risco identificado.>

Plano de Testes

Objetivo

<Descrever o objetivo do plano de teste (o que será testado, performance esperada, etc).>

Cenários

<Descrever os cenários que serão utilizados para o teste.

Se não for teste funcional, descrever quantos cenários corretos e incorretos deverão ser testados.

Descrever as considerações, se houver, relacionadas com os cenários.>

Pré-requisitos para os testes

<Relacionar os itens que servem como pré-requisitos para os testes (exemplo: documento visão, fluxos e outros)>

Requisitos para os testes

<Relacionar todos os documentos que servem de insumo para os testes (exemplo: caso de uso, especificação suplementar, caso de teste, arquivos XML, XSD; Massa de testes para inserção nos campos: Presente no caso de teste, etc).>

Exemplo:

MIP_Teste.zip

orderCheckout_MIP.xml

Pedidos XML.zip (cenários)

Documentos Auxiliares

<Descrever documentos considerados auxiliares para os testes.>

Exemplo:

Descrição_MIP_Teste.doc (resumo dos emails trocados para este teste).

Estratégia de Teste

Estágio do teste:	( ) Integração	( X ) Sistema
Abordagem do teste:	( ) Caixa branca	( X ) Caixa preta
Procedimento:	( ) Manual	( ) Automático
Tipos de testes:	( ) Ciclo de Negócios

( ) Funcional

( X ) Carga

( ) Volume - Massivo

( ) Stress

( ) Benchmark

( ) Contenção	( ) Interface de Usuário

( ) Configuração

( ) Integridade de Dados e BD

( ) Instalação

( ) Estrutura

( ) Falha e Recuperação

( ) Segurança e Controle de Acesso

Ambiente de teste

<O ambiente que o sistema será usado.>

Exemplo:

Servidor: WebLogic server 10.0.2; Aqualogic Bus 3.0

Base de dados: Oracle 10g

Fila: MipJms_InsertSiteOrderMIPRequestProxyQueue

Características de Qualidade

Exemplo:

Eficiência - Se aplica, devido a necessidade de atender aos requisitos do cliente.

Performance - Se aplica devido a necessidade de atender aos requisitos do cliente.

Continuidade - Se aplica, devido ao sistema ser um módulo integrador do pedido com outros sistemas. Porém neste teste, abordaremos somente os dados que passam pelo BUS até o MIP.

Relação dos Casos de Uso

<Descrever os casos de uso (seria o índice do documento caso de uso)>

Exemplo:

Login

Realizar Configurações

Consultar Pedido

Relação de Casos de Testes

<Descrever os casos de uso (seria o índice do documento caso de teste)>

Exemplo:

[TC00] Efetuar Login

[TC00-1] Login e senha válida

[TC00-2] Login válido e senha inválida

[TC00-3] Login inválido e senha válida

[TC00-4] Login inválido e senha inválida

[TC00-5] Login válido e senha em branco

[TC00-6] Login em branco e senha válida

[TC00-7] Login em branco em branco

[TC00-8] Entrada de caracteres inválidos

[TC00-9] Logout

Observações

<Descrever alguma observação a ser considerada para os testes.>

Anexo I

<Pendências>

Descrever as pendências para o fechamento do plano de testes (exemplo: falta da URL de entrada e outros)

Documento de Especificação de Requisitos

gaffo

2010-04-26

fernando

faccar