UNIVERSIDADE FEDERAL DE SERGIPE

DEPARTAMENTO DE COMPUTAÇÃO
PROCC – PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

Disciplina: Engenharia de Software

Professor: Rogério P C do Nascimento
rogerio@ufs.br

Plano de Projeto
Programas de Avaliação de Poços de Petróleo

Danielle Amaral Menéndez

Givanildo Santana Nascimento

Aracaju-SE
Novembro de 2010
 Sumário

1.0 INTRODUÇÃO ................................................................................................................... 3

1.1 Âmbito do Projeto ..................................................................................................................... 3
1.2 Funções principais do produto de software .............................................................................. 3
1.3 Requisitos comportamentais ou de performance ...................................................................... 4
1.4 Gestão e Restrições Técnicas .................................................................................................... 5
2.0 ESTIMATIVAS DO PROJETO ............................................................................................... 6
2.1 Dados históricos utilizados para as estimativas do projeto ....................................................... 6
2.2 Técnicas de estimativas e resultados......................................................................................... 6
2.2.1 Técnica de estimativa ............................................................................................................. 6
2.3 Resultados ................................................................................................................................. 7
2.4 Estimativas usando Análise de Pontos por Função (APF) ........................................................ 9
3.0 ANÁLISE E GESTÃO DE RISCOS ...................................................................................... 10
3.1 Riscos do projeto..................................................................................................................... 11
3.2 Tabela de riscos....................................................................................................................... 12
3.3 Redução e Gestão do Risco..................................................................................................... 13
4.0 PLANEAMENTO TEMPORAL ............................................................................................ 14
4.1 Conjunto de Tarefas do Projeto .............................................................................................. 14
4.2 Diagrama de Gantt .................................................................................................................. 15
5.0 ORGANIZAÇÃO DO PESSOAL .......................................................................................... 17
6.0 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................... 18

Sumário de Tabelas
Tabela 1:Fatores multiplicativos para encontrar o nº de classes de suporte ................................... 7
Tabela 2: Identificação dos Riscos do Projeto .............................................................................. 11
Tabela 3: Riscos do Projeto .......................................................................................................... 13
Tabela 4: Tempos em dias do Projeto ........................................................................................... 15

Sumário de Figuras
Figura 1: Cronograma do projeto .................................................................................................. 15
Figura 2: Cronograma do projeto ................................................................................................. 16
Figura 3: Diagrama do Projeto ...................................................................................................... 16
Figura 4: Diagrama do Projeto ...................................................................................................... 17
1.0 INTRODUÇÃO
Esta seção descreve uma visão geral sobre o projeto de software, iniciando com uma
descrição do seu âmbito. Em seguida enumera as principais funções que o sistema deve
oferecer. Descreve-se também quais são os requisitos de comportamento e temporais da
aplicação e fala-se das restrições técnicas e temporais existentes no projeto.

1.1 Âmbito do Projeto

Este projeto tem o objetivo de desenvolver um produto de software para a empresa
Lacertae SW que consiste numa aplicação Desktop, cliente-servidor, para a programação de
avaliações de reservatórios de petróleo. Este projeto foi encomendado por uma empresa de
petróleo brasileira, com atuação nacional e internacional.

A produção comercial de campos de petróleo passa pela escolha de modelos

adequados de extração dos fluidos para que seja eficiente, duradoura e rentável. É necessário
que o reservatório seja avaliado e sua produção simulada em laboratório considerando
diversos planos de desenvolvimento do campo, possibilitando a definição do melhor conjunto
de equipamentos, logística de produção, armazenamento e escoamento dos fluidos
produzidos. A escolha de um modelo inadequado ao reservatório pode resultar em prejuízos
altíssimos para a empresa que desenvolve o campo.

A atividade de Avaliação de Reservatórios tem como objetivo obter um conjunto de

informações que permitem identificar, confirmar ou corroborar o modelo mais apropriado ao
reservatório. Essas informações são obtidas durante a fase exploratória e durante toda a vida
produtiva do campo, de maneira a maximizar a extração de fluidos e o retorno financeiro do
projeto.
Nesse contexto, as avaliações devem ser corretamente programadas para que
produzam os resultados esperados, sejam eficientes e tenham um baixo impacto ambiental.
Um programa de avaliação de poço é composto por um conjunto de programações de testes,
perfilagens e outras operações com objetivos bem definidos. Os programas de testes podem
ser executados conforme o previsto, com alterações ou podem ser cancelados por falta de
recursos financeiros, materiais ou humanos, ou mesmo em função dos resultados de testes
anteriores que sinalizem a inviabilidade econômica do projeto.
A aplicação desenvolvida neste projeto deverá permitir ao engenheiro de petróleo
elaborar programas de avaliação de poços e acompanhar a execução desses programas por
meio dos testes realizados.

1.2 Funções principais do produto de software

O produto de software será um módulo do Sistema de Informações de Reservas e
Reservatórios com a finalidade de permitir a elaboração de programas de avaliação de poços.
As funcionalidades previstas são:
 1. Consultar programas de avaliação
a. Dados de entrada
i. Unidade operativa. Cada usuário só poderá acessar os
programas da sua unidade operativa. Os usuários da
SEDE terão acesso aos programas de todas as
unidades.
b. Dados de saída
i. Poço;
ii. Cliente;
iii. Data de programação;
iv. Responsável pelo programa.
2. Cadastrar programas de avaliação
a. Dados de entrada
i. Poço;
ii. Cliente;
iii. Data de programação;
iv. Histórico do poço.
3. Consultar programas de teste
a. Dados de entrada
i. Programa de avaliação
b. Dados de saída
i. Tipo de teste;
ii. Descrição do intervalo;
iii. Topo (m);
iv. Base (m);
v. Cancelado.
4. Cadastrar programas de teste.
a. Dados de entrada
i. Programa de avaliação
ii. Tipo de teste;
iii. Descrição do intervalo;
iv. Topo (m);
v. Base (m);
vi. Objetivos vinculados ao programa;
vii. Objetivos adicionais;
viii. Cancelado.

1.3 Requisitos comportamentais ou de performance

O sistema deve funcionar on-line, conectado aos bancos de dados corporativos, com
tempo de resposta máximo de 10 segundos para cada ação solicitada pelo usuário. A interface
deve ser desktop, com atualização automática de versões a partir de uma página na Intranet da
companhia.
 É necessário que a interface que o software apresenta seja agradável, simples e fácil
de utilizar.
No que diz respeito aos requisitos comportamentais, todas as funcionalidades são
criticas e devem funcionar corretamente para o bom funcionamento do software.

1.4 Gestão e Restrições Técnicas

O cliente tem a expectativa de receber o produto em no máximo 6 meses, mas o
prazo será negociado com base nas estimativas produzidas neste plano de projeto.
O projeto será executado utilizando metodologias ágeis de gerenciamento e
execução, a principal será o framework Scrum. O Scrum não é um processo ou uma técnica
para o desenvolvimento de produtos. É um framework dentro do qual pode-se empregar
diversos processos e técnicas. Fundamentado na teoria de controle de processos empíricos, o
Scrum emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e
controlar os riscos. O framework Scrum consiste em um conjunto formado por Times Scrum e
seus papéis associados, Eventos com Duração Fixa (Time-Boxes), Artefatos e Regras
(SCHWABER, 2009).
Os Times Scrum são projetados para otimizar flexibilidade e produtividade. Para esse
fim, eles são auto-organizáveis, interdisciplinares e trabalham em iterações. O Scrum emprega
os eventos com duração fixa (time-boxes) para criar regularidade. Entre os elementos do
Scrum que têm duração fixa, temos a reunião de Planejamento da Versão para Entrega, a
Sprint, a Reunião Diária, a Revisão da Sprint e a Retrospectiva da Sprint O coração do Scrum é
a Sprint, que é uma iteração de um mês ou menos de duração, consistente com o esforço de
desenvolvimento. Todas as Sprints têm como resultado um incremento do produto final que é
potencialmente entregável. Cada Sprint começa imediatamente após a anterior. O Time Scrum
é composto pelo ScrumMaster, pelo Product Owner e pelo Time (SCHWABER, 2009).
O Scrum utiliza quatro artefatos principais. O Backlog do Produto é uma lista
priorizada de tudo que pode ser necessário no produto. O Backlog da Sprint é uma lista de
tarefas para transformar o Backlog do Produto, por uma Sprint, em um incremento do produto
potencialmente entregável. Um burndown é uma medida do backlog restante pelo tempo. Um
Burndown de Versão para Entrega mede o Backlog do Produto restante ao longo do tempo de
um plano de entrega. Um Burndown de Sprint mede os itens do Backlog da Sprint restantes ao
longo do tempo de uma Sprint (SCHWABER, 2009).
As Regras fazem o elo entre os eventos com duração fixa (time-boxes), os papéis e
os artefatos do Scrum. Suas regras são descritas ao longo deste documento. Por exemplo,
uma regra do Scrum diz que somente membros do Time - as pessoas comprometidas em
transformar o Backlog do Produto em um incremento - podem falar durante uma Reunião Diária
(SCHWABER, 2009).
2.0 ESTIMATIVAS DO PROJETO

As estimativas do projeto são importantes pois proporcionarão ao gestor uma

maior percepção da duração que o projeto terá, ou seja, o tempo total do projeto. Na
estimativa serão efetuados os cálculos necessários para determinar o tempo de cada
fase do projeto, planejamento, requisitos, análise, projeto, implementação e testes.

De acordo com Lorenz e Kidd (1994), a importância das métricas se deve ao

efeito econômico que a utilização das mesmas representa para o desenvolvimento de
um projeto de software.

2.1 Dados históricos utilizados para as estimativas do projeto

Por se tratar do primeiro projeto a utilizar a estimativa baseada em número de

classes, não possuímos dados históricos para relato.

2.2 Técnicas de estimativas e resultados

Nesta seção é demonstrado como efetuar todo o cálculo para encontrar o tempo
total de duração do projeto (em dias). Para encontrar esse tempo é necessário aplicar
uma técnica de estimativas e neste caso utilizaremos a métrica de Lorenz & Kidd,
aconselhada pela Lacertae Software.

2.2.1 Técnica de estimativa

Para este projeto utilizaremos a técnica de estimativa usada em projetos de

Software Orientados a Objetos da Lacertae Software, técnica essa que é a Lorenz &
Kidd. Trata-se de uma métrica orientada a classes, a qual se destaca por ser simples e
fácil de utilizar.

Segundo Pressman (2006), as métricas de software ajudam na avaliação dos

modelos de análise e projeto, fornecem uma indicação da complexidade do projeto
procedimental e do código-fonte além de facilitar o processo de teste de software
tornando-o mais efetivo.

Para usar a métrica de Lorenz & Kidd temos que:

 1. Definir o número de classes chave.

2. Encontrar o número de classes de suporte, que para isso temos que

classificar o tipo de Interface do Produto e desenvolver um Multiplicador para as
Classes de Suporte, tabela1.

3. Multiplicar a quantidade de classes-chave pelo Multiplicador para obter uma

estimativa do número de classes de suporte

4. De seguida, calcula-se a quantidade total de Classes, somando o nº de

Classes-Chave com o nº de Classes de Suporte.

5. Multiplicar a quantidade total de Classes (classes-chave + classes de suporte)

pelo “número médio de unidades de trabalho (dias-pessoa) por classe”.
Lorenz & Kidd sugere entre 15 e 20 dias-pessoa por classe.
Escolher um número entre 15-20 dias-pessoa e justificar a escolha.

6. Determinar a quantidade de esforço estimada.

7. Cálculo do tempo previsto para a elaboração do projeto

Interface Multiplicador

Não gráfica 2,0

Baseada em textos 2,25

GUI 2,5

GUI Complexa 3,0

Tabela 1:Fatores multiplicativos para encontrar o nº de classes de suporte

2.3 Resultados

Com base na métrica de Lorenz & Kidd, obtivemos os seguintes resultados:

1. Nº de classes chave = 3;

2. Escolhemos o Interface com base na aplicação gráfica que irá ter o produto
final. Multiplicador do GUI = 2,5;
 3. 3 X 2.5 = 7.5 . Logo teremos 7,5 Classes de Suporte.

4. O número total de classes é igual a:

Nº Classes Chave + Nº Classes de Suporte = 3 + 7.5 = 10,5

5. Em seguida escolhe-se o número médio de unidades de trabalho (dias-pessoa)

por classe onde a métrica Lorenz & Kidd sugere entre 15 e 20 dias-pessoa por
classe. Em conjunto optamos por escolher 20 dias-pessoa devido ao fato de ser
a primeira experiência que o método será utilizado com as ferramentas de
trabalho disponibilizadas na empresa.

6. Sendo assim o cálculo da quantidade do esforço estimada é:

10.5 X 20 = 210 dias de trabalho

7. Agora se pretendemos ter os dias/meses corridos (incluindo os fins de semana),

temos que multiplicar os dias de trabalho com os 30 dias corridos e em seguida
dividir pelos os 22 dias úteis.

210 X 30 = 6300 / 22 = 286,36 _ 287 dias corridos

286,36 / 30 = 9.5_ 10 Meses corridos

Novamente como base os dias de trabalho total (210 dias), estes dias serão
distribuídos de acordo com as seguintes percentagens de distribuição dos
componentes essenciais num projeto:

1) Planejamento: 2-3%
2) Requisitos – Análise – Desenho: 40%
3) Geração de Código: 20%
4) Testes: 37-38%

Os valores calculados são:

1) Planejamento: 210 * 3% = 6 dias de trabalho
2) Requisitos – Análise – Desenho: 210 * 40% = 84 dias de trabalho
3) Geração de código: 210 * 20% = 42 dias de trabalho
4) Testes: 210 * 37% = 78 dias de trabalho
210 Dias de trabalho

Podemos calcular agora os dias de trabalho por pessoa, sendo assim temos 3
membros da equipe para este projeto e 210 dias de trabalho. Dividindo o total de dias
pelos membros da equipe ficaremos com aproximadamente 70 dias de trabalho para
cada membro da equipe.

2.4 Estimativas usando Análise de Pontos por Função (APF)

A NESMA (Netherlands Software Metrics Association) propôs um método para

medição antecipada de pontos de função que é mundialmente aceito e utilizado.
Segundo Vazquez (2008), a NESMA reconhece três tipos de contagem de pontos de
função:

 contagem de pontos de função detalhada

 contagem de pontos de função estimativa
 contagem de pontos de função indicativa

Os métodos estimativo e indicativo para a contagem de pontos de função foram

desenvolvidos pela NESMA para permitir que uma contagem de pontos de função seja
feita nos momentos iniciais do ciclo de vida de um sistema. A contagem indicativa da
NESMA é também conhecida como "método holandês".

A contagem detalhada é a contagem usual de pontos de função, descrita no

Manual de Práticas de Contagem (CPM) do International Function Point Users Group
(IFPUG), e é realizada da seguinte forma:

 determina-se todas as funções de todos os tipos:

o Arquivo Lógico Interno (ALI);
o Arquivo de Interface Externa (AIE);
o Entrada Externa (EE);
o Saída Externa (SE);
o Consulta Externa (CE).
 determina-se a complexidade de cada função (Baixa, Média, Alta);
 calcula-se o total de pontos de função não ajustados.

A contagem estimativa é realizada da seguinte forma:

 determina-se todas as funções de todos os tipos (ALI, AIE, EE, SE, CE);
 toda função do tipo dado (ALI, AIE) tem sua complexidade funcional avaliada
como Baixa, e toda função transacional (EE, SE, CE) é avaliada como de
complexidade média;
 calcula-se o total de pontos de função não ajustados.

Logo, a única diferença em relação à contagem usual de pontos de função é que

a complexidade funcional não é determinada individualmente para cada função, mas
pré-definida para todas elas.
 A contagem indicativa é realizada da seguinte forma:

 determina-se a quantidade das funções do tipo dado (ALIs e AIEs);

 calcula-se o total total de pontos de função não ajustados da aplicação da
seguinte forma: tamanho indicativo (pf) = 35 x número de ALIs + 15 x número de
AIEs.

Portanto esta estimativa é baseada somente na quantidade de arquivos lógicos

existentes (ALIs e AIEs). A contagem indicativa é baseada na premissa de que existem
aproximadamente três EEs (para adicionar, alterar, e excluir dados do ALI), duas SEs,
e uma CE na média para cada ALI, e aproximadamente uma SE e uma CE para cada
AIE.

3.0 ANÁLISE E GESTÃO DE RISCOS

Os projetos de tecnologia da informação sofrem constantemente com mudanças

de paradigmas,evoluções de padrões técnicos, mudanças de requisitos do cliente,
novas ferramentas e tecnologias, rotatividade de pessoal, entre outros. Estes fatores
forçam a equipe lidar com diversos riscos que surgem e tomar decisões que podem
modificar o planejamento no meio do andamento do projeto. Tais características tornam
a gerência de risco efetiva uma atividade essencial para o sucesso do projeto (NETO,
2009)

De acordo com PRESSMAN (2001), a gerência de riscos é uma série de passos

que ajudam a entender e administrar as incertezas em um projeto. Projetos de
softwares são geralmente difíceis, onde muitas coisas podem sair erradas. Por este
motivo, estar preparado para entender os riscos e tomar medidas proativas para evitá-
los ou administrá-los é o principal elemento de uma boa gerência de projeto, na qual
todas as pessoas envolvidas no processo podem participar e contribuir para a gerência
de risco do projeto.

Segundo PMI (2004), o gerenciamento de riscos é um processo sistemático que

tem por objetivo aumentar a probabilidade e o impacto dos eventos positivos e diminuir
a probabilidade e o impacto dos eventos adversos do projeto. As fases da gerência de
risco são atualizadas durante todo o projeto interagindo entre si e com processos de
outras áreas de conhecimento.

Já o CMMI (2006), diz que o objetivo da gerência de risco é identificar problemas

potenciais antes que eles ocorram, de forma que as atividades planejadas sejam
executadas assim que preciso durante o ciclo de vida do projeto para mitigar impactos
adversos que possam atingir seus objetivos.

Por fim, BOEHM (1988) define que a gerência de risco busca evitar desastres,
retrabalho e cancelamento de projetos, proporcionando um ambiente favorável ao seu
tratamento direcionando o sucesso nos projetos de software. A gerência de riscos
direciona as atividades, estimulando a exposição dos riscos para que o gerente atue
nas questões relevantes do projeto de forma preventiva ou corretiva, assim mais
benefícios serão obtidos.

3.1 Riscos do projeto

Existe um subconjunto de riscos que estão presentes em qualquer projeto de

software, estes riscos são denominados riscos gerais e podem ser vistos na tabela 2.

Risco Projeto Técnico Negócio Comum Especial

Descontinuidade do contrato da X X
equipe
Greve X X
Mudanças nos requisitos X X
Perda do interesse do cliente no X X
projeto
Retenção de pessoas chaves X X
Sub-estimativa do esforço. X X
Tabela 2: Identificação dos Riscos do Projeto

Avaliação Global do Risco:

1. O Gestor de Software dá suporte ao projeto?

 Sim, o gestor de software é um participante ativo em todo o desenvolvimento do
projeto inclusive na comunicação direta com os usuários.

2. Os Clientes estão entusiasmados com o projeto e o produto?

 Sim, pois trará maior agilidade no processo de avaliação dos poços.

3. Os Engenheiros de Software compreenderam bem os requisitos?

 Sim, os engenheiros estão bem conscientes dos requisitos do projeto. Pois os
mesmos acompanharam o processo atual de como a avaliação dos poços é
feita.

4. Os Clientes estiveram envolvidos na definição dos requisitos?

 Sim, pois é de grande interesse por parte dos clientes que o sistema contemple
todas as funcionalidades.

5. O âmbito do projeto é estável?

  Até o presente momento sim, pois como os clientes participaram do
levantamento de requisitos, ainda não foram detectadas falhas que implicassem
na modificação do projeto.

6. Os engenheiros de Software têm as competências requeridas?

 Os engenheiros de software são altamente competentes, já fazem parte de
diversos projetos da empresa.

7. Os requisitos do projeto são estáveis?

 Não, pois existe a possibilidade de mudar os usuários responsáveis pelas
definições dos requisitos.

8. A Equipe de Desenvolvimento tem experiência na tecnologia que será utilizada?

 A equipe tem experiência com a tecnologia, pois já trabalha com a mesma a
mais de 5 anos. Porém não tem muita experiência na metodologia adotada.

9. É adequado o número de pessoas da equipa de trabalho?

 Sim, pois o tamanho do projeto e o prazo estimado satisfazem as necessidades
da empresa e dos clientes.

3.2 Tabela de riscos

Na tabela 3 encontram-se descritos todos os riscos identificados no projeto. Os

riscos estão enumerados da seguinte forma, na primeira coluna encontra-se a
descrição do risco, na segunda coluna a categoria do risco, na terceira a probabilidade
de o risco acontecer e na quarta o tamanho de impacto que o risco pode causar no
projeto.

Risco Categoria Probabilidade Impacto

Âmbito instável Tamanho 60% Crítico
Data da Entrega muito ajustada Negócio 70% Crítico
Descontinuidade do contrato da Pessoal 10% Marginal
equipe
Descontinuidade do projeto Negócio 30% Catastrófico
Greve Pessoal 30% Crítico
Mudanças nos requisitos Negócio 80% Crítico
Número insuficiente de membros da Pessoal 20% Marginal
equipe
Retenção de Pessoas chaves Pessoal 10% Catastrófico
Sub-estimativa do tempo/esforço Tamanho 70% Crítico
 Tabela 3: Riscos do Projeto

3.3 Redução e Gestão do Risco

Dos riscos elencados, escolhemos três deles aleatoriamente para descrevermos

as suas atividades de redução, supervisão e gestão do risco.

As mudanças de requisitos são outro fator que sempre ronda os projetos pela
sua alta probabilidade, neste caso faz-se estritamente necessário um plano de redução
de risco.

Mudança nos requisitos

Risco: 001 Prob.:80% Impacto: Crítico

Descrição: Quando são detectadas alterações nos requisitos do projeto.

Estratégia de redução: Fazer o levantamento dos requisitos com as pessoas
detentoras de maior conhecimento sobre o processo do projeto e tê-las
acompanhando diretamente sua evolução

Plano de contingência: Renegociar prazos com o cliente.

Pessoa responsável: Rubens ( criação 10-10-2010)

Status: Simulação completada (20-11-2010)

Existe um histórico considerável na ocorrência de greves dentro do quadro

funcional da empresa, apesar de estarmos passando por um período estável em
relação a este item, é muito importante traçar o plano para redução deste risco.

Greve

Risco: 002 Prob.:30% Impacto: Crítico

Descrição: Ocorrência de greve no período de execução do projeto

Estratégia de redução: Não há estratégia para evitar a greve. Pois a mesma não é
definida em âmbito setorial e sim da empresa como um todo.

Plano de contingência: Terceirizar o projeto.

Pessoa responsável: Rubens ( criação 08-10-2010)

Status: Simulação completada (01-11-2010)

A Sub-estimativa do tempo/esforço, se trata de um risco de alta incidência em

diversos projetos desta forma, faz-se necessário traçar as estratégias para reduzir o
rico.

Sub-estimativa do tempo/esforço

Risco: 003 Prob.:70% Impacto: Crítico

Descrição: Erro na estimativa do tempo necessário para a realização de tarefas

Estratégia de redução: Realizar reuniões periódicas de forma a verificar se o

desenvolvimento do projeto está a correspondendo às estimativas. Redefinir o
planejamento temporal e a distribuição de tarefas sempre que necessário

Plano de contingência: Redução das funcionalidades do sistema. Pedido de

prorrogação do prazo de entrega.

Pessoa responsável: Lucas ( criação 05-10-2010)

Status: Simulação completada (10-11-2010)

4.0 PLANEAMENTO TEMPORAL

No planejamento temporal definem-se as datas de execução das tarefas e os
responsáveis pelas tarefas, este processo designa-se Diagrama de Gantt. Sendo a pessoa
responsável pelo planejamento do Gestor de projeto.

4.1 Conjunto de Tarefas do Projeto

Após realizar a Estimativa do Projeto de Software, a divisão do plano de tarefas pela

percentagem de tempo foi efetuada conforme a tabela 2. É importante observar que como a
equipe possuía 3 membros o tempo calculado de 210 dias foi reduzido para 70 dias.

Tarefas Percentagem do tempo Dias de atividade

Planejamento 3% 2

Analise 40% 28
Geração de Código 20% 14

Manutenção e Teste 37% 26

Tabela 4: Tempos em dias do Projeto

4.2 Diagrama de Gantt

O diagrama de Gantt é composto pela divisão em tarefas e sub-tarefas das várias fases
do projeto, onde todas as tarefas tem uma data de inicio e dada de conclusão, associando a
um ou mais elementos da equipe de desenvolvimento do projeto. As divisões das atividades
podem ser vistas nas figuras 1,2,3 e 4.

Figura 1: Cronograma do projeto

Figura 2: Cronograma do projeto

Figura 3: Diagrama do Projeto

 Figura 4: Diagrama do Projeto

5.0 ORGANIZAÇÃO DO PESSOAL

Os Times Scrum são projetados para otimizar flexibilidade e produtividade. Para esse
fim, eles são auto-organizáveis, interdisciplinares e trabalham em iterações. Cada Time Scrum
possui três papéis:
1) o ScrumMaster é o responsável por garantir que o processo seja entendido e
seguido;
2) o Product Owner é o responsável por maximizar o valor do trabalho que o Time
Scrum faz; e
3) o Time executa o trabalho propriamente dito. O Time consiste em desenvolvedores
com todas as habilidades necessárias para transformar os requisitos do Product Owner em um
pedaço potencialmente entregável do produto ao final da Sprint.
6.0 REFERÊNCIAS BIBLIOGRÁFICAS

BOEHM, Barry. Software Risk Management: Principles and Practices. IEEE Computer
Society Press, 1991.

CMMI - SEI - Software Engineering Institute. Capability Maturity Model Integration.

Versão 1.2. Agosto, 2006. Disponível em: <www.sei.cmu.edu/cmmi/>. Acesso em
Junho 2009.

LORENZ. M, KIDD J., Object-Oriented Software Metrics, Prentice Hall, 1994.

NETO, José P. Planejamento de Projeto de Software Orientado por Risco, Salvador

2009. Disponível em:
https://www.disciplinas.dcc.ufba.br/pub/MATA66/AnteProjetos20091/AnteProjeto_Jose
PinaNeto.pdf. Acesso em : Novembro 2010.

PMI - Project Management Institute. A Guide to the Project Management Body of

Knowledge
(PMBOK Guide). Project Management Institute, 2004.

PRESSMAN, Roger S. Engenharia de Software 6ª Edição São Paulo: McGraw-Hill,

2006.

PRESSMAN, Roger S. Software engineering : a practitioner’s approach . 5th ed.

Boston:McGraw-Hill, c2001. 860 p.

SCHWABER, Ken. Guia do Scrum, maio de 2009. Disponível em www.scrumalliance.org.

VAZQUEZ, Carlos Eduardo, SIMÕES, Guilherme S., ALBERT, Renato S. Análise de Pontos
de Função: medição, estimativas e gerenciamento de projetos de software. 8.ed. 2008, 232p.