> Livro: Software Engineering
> Autor: Roger S. Pressman
> Editora McGraw-Hill
> Capítulos 5 e 7
1
Planejamento de Projeto de Software









Introdução
Escopo do Software
Recursos
Estimativa de Projeto de Software
Relacionamento entre Pessoas e Esforço
Distribuição do Esforço
Determinação de Cronogramas
Rastreamento e Controle de Projeto
Plano de Projeto de Software
2
Planejamento de Projeto de Software
Introdução

Tempo: O mais valioso bem disponível a um
engenheiro de software. Se houver tempo disponível
suficiente:
– Um problema pode ser adequado/ analisado;
– Uma solução pode ser compreensiva/ projetada;
– O código-fonte deve ser cuidadosamente
implementado; e
– O programa, deve ser minuciosamente testado.
3
Planejamento de Projeto de Sofware
Introdução

Um projeto é planejado e tem seu cronograma
determinado casualmente;

Os riscos são considerados somente depois que eles
se transformaram em problemas completos; e

As pessoas não são organizadas de uma forma que
agilize o progresso.

O planejamento de projetos de software obriga
gerentes e profissionais a despender tempo para
organizar “suas ações”.
4
Planejamento de Projeto de Software
Introdução

Após compreender os requisitos funcionais do
software, restrições relativas ao sistema e
preocupações de confiabilidade, o planejador
aplica técnicas e ferramentas para deduzir
estimativas de esforço e de tempo.

Estimativas oferecem informações úteis somente
se estiverem integradas em uma estrutura de
planejamento mais completa.
5
Planejamento de Projeto de Software
Introdução

Objetivos do Planejamento de Projeto:
– Fornecer uma estrutura que permita o gerente fazer
estimativas de recursos, custo e cronograma.

Antes de iniciarmos o planejamento de projeto,
devemos:
– responder a algumas questões sobre riscos;
– desenvolver estratégia para atacar o problema;
– estabelecer mecanismo para avaliar o progresso;
– organizar a equipe escolhida para construir o software.
6
Planejamento de Projeto de Software
Escopo do Software



O escopo do software descreve função,
desempenho, restrições, interfaces e confiabilidade
O escopo do software é definido através da
comunicação entre o cliente e o analista de
sistemas.
Exemplo de técnica de comunicação usada:
– FAST (Facilitated Application Specification
Techniques)
7
Planejamento de Projeto de Software
Recursos
Pessoas
Componentes de
Software Reusável
Ferramentas de
Hardware/Software
8
Planejamento de Projeto de Software
Estimativa de Projeto de Software



Custo e esforço de software nunca serão uma
ciência exata.
Muitas variáveis - humana, técnica, ambiental,
política - podem afetar o custo final de software e
o esforço aplicado ao seu desenvolvimento.
Entretanto, estimativa de projeto de software pode
ser transformada de uma arte misteriosa a uma
série de passos sistemáticos que fornecem
estimativas com risco aceitável.
9
Planejamento de Projeto de Software
Estimativa de Projeto de Software

Para ativar custo confiável e estimativa de esforço,
existem várias opções:
– Estimativa de atraso no projeto;
– Estimativa baseada em projetos similares que já
tenham sido completados;
– Uso relativamente simples de “técnicas de
decomposição” para gerar custo de projeto e
estimativas de esforço;
– Uso de um ou mais modelos empíricos para
estimativa de custo e esforço do software.
10
Planejamento de Projeto de Software
Relacionamento entre Pessoas e Esforço



Em um projeto de desenvolvimento de software
pequeno, uma única pessoa pode analisar os
requisitos, executar o projeto, gerar o código e
realizar testes.
À medida que o tamanho do projeto aumenta,
mais pessoas devem ser envolvidas.
Há um mito comum no qual muitos gerentes que
são responsáveis pelo esforço de desenvolvimento
ainda acreditam:
11
Planejamento de Projeto de Software
Relacionamento entre Pessoas e Esforço

“...se nos atrasarmos, sempre poderemos
acrescentar mais programadores e posteriormente
sairmos do atraso do projeto...”.

Acrescentar pessoas tardiamente num projeto
muitas vezes tem um efeito desintegrador sobre o
projeto, fazendo com que o cronograma fuja ainda
mais do controle.
12
Planejamento de Projeto de Software
Relacionamento entre Pessoas e Esforço
As pessoas que são incluídas no sistema, e as
pessoas que as ensinam são as mesmas que estão
realizando o trabalho. Enquanto estão ensinando,
nenhum trabalho é feito
 Além do tempo despendido para se aprender o
sistema, um número maior de pessoas aumenta o
número de canais de comunicação e a
complexidade desta ao longo de um projeto.
* novo canal de comunicação => esforço e tempo
adicional.

13
Planejamento de Projeto de Software
Distribuição do Esforço

Cada uma das técnicas de estimativa de projetos
de software leva a estimativas de pessoas-mês (ou
pessoas-ano) exigidas para se concluir o
desenvolvimento do software.

Essa distribuição, outrora chamada regra 40-2040, enfatiza as tarefas de análise e projeto
realizadas no início do projeto e os testes
realizados no final.
14
Planejamento de Projeto de Software
Distribuição do Esforço
Análise e
projeto
(40 - 40%)
Atividade
de testes e
depuração
(30 - 40%)
Codificação
(15 - 20%)
15
Planejamento de Projeto de Software
Distribuição do Esforço

Atualmente, mais de 40% de todo o esforço de
projeto freqüentemente é recomendado para as
tarefas de análise e projeto de grande projetos de
desenvolvimento de software. Portanto, a regra
40-20-40 não mais se aplica num sentido estrito.

A distribuição de esforço ilustrada na figura deve
ser usada somente como uma diretriz.

As características de cada projeto devem ditar a
distribuição do esforço.
16
Planejamento de Projeto de Software
Distribuição do Esforço

O esforço despendido em planejamento de projeto
raramente é responsável por mais do que 2 a 3%
do esforço total, a menos que o plano envolva
grandes dispêndios com riscos.

A análise de requisitos pode envolver de 10 a 25%
do esforço de projeto.
O esforço despendido em análise ou construção de
protótipos deve elevar-se em proporção direta com
o tamanho e a complexidade do projeto.

17
Planejamento de Projeto de Software
Distribuição do Esforço




Uma margem de 20 a 25% do esforço
normalmente é aplicada no projeto de software.
O tempo gasto na revisão do projeto e na
subseqüente
iteração
também
deve
ser
considerado.
Por causa do esforço aplicado no projeto de
software, o código se desenvolverá com pouca
dificuldade.
Uma margem de 15 a 20% do esforço global pode
ser conseguida.
18
Planejamento de Projeto de Software
Distribuição do Esforço



O teste e a subseqüente depuração podem ser
responsáveis por uma margem de 30 a 40% do
esforço de desenvolvimento do software.
A condição crítica do software muitas vezes dita a
quantidade de teste que é exigida.
Se o software for human-rated (isto é, falha de
software que pode resultar em perdas de vidas
humanas), percentagens mais elevadas podem ser
consideradas.
19
Planejamento de Projeto de Software
Determinação de Cronogramas

A determinação de um cronograma para projetos
de desenvolvimento de software pode ser vista a
partir de duas perspectivas bem diferentes.
– Na primeira, uma data final para a entrega de um
sistema baseado em computador já foi (e de maneira
irrevogável) estabelecida. A organização é obrigada a
distribuir o esforço dentro do espaço de tempo previsto.
– A segunda presume que limites cronológicos
aproximados tenham sido discutidos, mas que a data
final seja estabelecida pela organização de engenharia
de software. O esforço é distribuído para que se possa
tirar melhor proveito dos recursos e uma data final é
definida após cuidadosa análise.
20
Planejamento de Projeto de Software
Determinação de Cronogramas



A precisão na determinação de um cronograma às
vezes pode ser bem mais importante do que a
precisão na determinação dos custos.
Num ambiente orientado ao produto, os custos
adicionados podem ser absorvidos por nova
determinação de preços ou por amortização ao
longo de um grande número de vendas.
Um cronograma descumprido, porém, pode
reduzir o impacto de mercado, criar clientes
insatisfeitos e elevar os custos internos.
21
Planejamento de Projeto de Software
Determinação de Cronogramas

Quando abordamos a fixação de prazos para
projetos de software, uma série de perguntas pode
ser feita.
– Como relacionamos o tempo cronológico com o esforço
humano?
– Quais tarefas e paralelismos podem ser esperados?
– Quais marcos de referência podem ser usados para
mostrar o progresso?
22
Planejamento de Projeto de Software
Determinação de Cronogramas
– Como o esforço é distribuído ao longo do processo de
engenharia de software?
– Existem métodos disponíveis de determinação de
prazos?
– Como representaremos fisicamente o cronograma e
como rastrearemos o progresso quando o projeto se
iniciar?
23
Planejamento de Projeto de Software
Determinação de Cronogramas

A determinação de um cronograma para um
projeto de software não difere significativamente
da fixação de prazos para qualquer esforço de
desenvolvimento de multitarefas.

Ferramentas e técnicas para determinação de um
cronograma de projeto podem ser aplicadas no
software com poucas modificações.
24
Planejamento de Projeto de Software
Determinação de Cronogramas
Fases, passos e atividades num projeto
25
Planejamento de Projeto de Software
Determinação de Cronogramas
Gráfico de atividades para a construção de uma casa
26
Planejamento de Projeto de Software
Determinação de Cronogramas
Gráfico de atividades com durações
27
Planejamento de Projeto de Software
Determinação de Cronogramas

O PERT - Program Evaluation and Review
Technique (método de avaliação e revisão
de programa) e o CPM - Critical Path
Method (método do caminho crítico) são
dois métodos de determinação de
cronogramas que podem ser aplicados no
desenvolvimento de software.
28
Planejamento de Projeto de Software
Determinação de Cronogramas

Ambas as técnicas são dirigidas por informações
já desenvolvidas em atividades de planejamento
de projeto anterior:
– estimativas de esforço;
– uma decomposição de função de produto;
– a seleção do modelo de processo apropriado;
– a seleção de tipo de projeto e conjunto de tarefas.
29
Planejamento de Projeto de Software
Determinação de Cronogramas

Independências entre tarefas pode ser definida
usando uma rede de tarefa.

Tarefas, algumas vezes chamadas WBS - Work
Breakdow Structure (estrutura de divisão de
trabalho), são definidas para o produto como um
todo ou para funções individuais.

Uma rede de tarefa é uma representação gráfica do
fluxo de tarefa para um projeto.
30
Planejamento de Projeto de Software
Determinação de Cronogramas
CPM bar chart
31
Planejamento de Projeto de Software
Determinação de Cronogramas
Exemplo de Work Breakdown Structure (WBS)
32
Planejamento de Projeto de Software
Determinação de Cronogramas
Gantt chart para o exemplo de WBS
33
Planejamento de Projeto de Software
Determinação de Cronogramas

Tanto o PERT como o CPM proporcionam
ferramentas quantitativas que permitem ao
planejador de software:
– determinar o caminho crítico - a cadeia de tarefas
que determina a duração do projeto;
– estabelecer as estimativas de tempo mais prováveis
para tarefas individuais ao aplicar modelos
estatísticos; e
– calcular limites de tempo que definam uma “janela”
de tempo para uma tarefa em particular.
34
Planejamento de Projeto de Software
Determinação de Cronogramas

Cálculos de limite de tempo podem ser muito úteis
na determinação de um cronograma para projetos
de software.

Deslize no projeto de uma função, por exemplo,
pode retardar ainda mais o desenvolvimento de
outras funções.
35
Planejamento de Projeto de Software
Determinação de Cronogramas

Importantes limites de tempo que podem ser
reconhecidos numa rede PERT ou CPM:
1) o tempo mais cedo em que uma tarefa pode iniciar-se
quando todas as tarefas precedentes foram completadas
no tempo mais curto possível;
2) o tempo mais tarde para o início da tarefa antes que o
tempo de conclusão mínimo do projeto seja atrasado;
3) o término mais breve - a soma do início mais cedo com
a duração da tarefa;
36
Planejamento de Projeto de Software
Determinação de Cronogramas
4) o término mais tardio - o momento de início mais tarde
somado à duração da tarefa;
5) a flutuação total - a quantidade de superávit de tempo ou
margem de segurança permitida nas tarefas, determinação
de prazos de forma que o caminho crítico da rede seja
mantido dentro do prazo.
37
Planejamento de Projeto de Software
Determinação de Cronogramas

Os cálculos de tempo-limite levam à determinação
do caminho crítico e proporcionam ao gerente um
método quantitativo para avaliar o progresso à
medida que as tarefas são concluídas.

O planejador deve reconhecer que o esforço de
manutenção, ainda que não seja fácil de programar
neste estágio, tornar-se-á, por fim, o maior fator de
custo.
38
Planejamento de Projeto de Software
Determinação de Cronogramas

PERT e CPM foram implementadas em uma
grande variedade de ferramentas automatizadas
que estão disponíveis para todos os computadores
pessoais.

Tais ferramentas são relativamente fáceis de serem
usadas e tornam os métodos de análise disponíveis
para todos os gerentes de projetos de software.
39
Planejamento de Projeto de Software
Rastreamento e Controle de Projeto


Há um ditado que diz: “Os projetos de software
atrasam-se em seu cronograma um dia de cada
vez”. O atraso de um dia na programação
raramente será fatal para um projeto. Mas os dias
se somam e, ao longo da extensão de um projeto,
pequenos atrasos podem resultar em grandes
problemas.
Um dos papéis da administração é rastrear e
controlar o projeto de software assim que ele é
iniciado.
40
Planejamento de Projeto de Software
Rastreamento e Controle de Projeto

O rastreamento (tracking) pode ser feito de muitas
maneiras diferentes:
– Realizando-se reuniões sobre a situação do projeto, em
que cada membro da equipe relate o progresso e os
problemas.
– Avaliando-se os resultados de todas as revisões
realizadas ao longo do processo de engenharia de
software.
– Determinando-se se os marcos de referência de projeto
formais foram atingidos até a data programada.
41
Planejamento de Projeto de Software
Rastreamento e Controle de Projeto
– Comparando-se a data de início real com a data de
início planejada para cada tarefa de projeto relacionada
na tabela de recursos.
– Reunindo-se informalmente com profissionais para se
obter suas avaliações subjetivas do progresso até o
momento e os problemas que aparecem no horizonte.
– Todas essas técnicas de rastreamento são usadas por
gerentes de projeto experientes.
42
Planejamento de Projeto de Software
Rastreamento e Controle de Projeto




O controle é empregado por um gerente de projetos de
software para administrar os recursos do projeto, enfrentar
problemas e dirigir o pessoal do projeto.
Se o projeto estiver no prazo e dentro do orçamento, as
revisões indicarem progresso real e os marcos estiverem
sendo atingidos, o controle é leve.
Quando ocorrerem problemas, o gerente de projetos deverá
exercer o controle para saná-los o mais rapidamente
possível.
Depois que o problema tiver sido diagnosticado, recursos
adicionais podem ser concentrados na área de problema; o
pessoal pode novamente ser disposto ou a programação do
projeto, redefinida.
43
Planejamento de Projeto de Software
Processo de Planejamento de Projeto
1) Estabelecer a data de início do projeto
2) Estabelecer a data final do projeto
3) Estabelecer a metodologia de projeto ou ciclo de
vida do projeto a ser usado
4) Determinar o escopo do projeto em termos das
fases da metodologia ou do ciclo de vida do
projeto
5) Identificar ou selecionar os métodos de revisão a
serem usados
44
Planejamento de Projeto de Software
Processo de Planejamento de Projeto
6) Identificar qualquer milestone (conclusão de uma
atividade) predeterminado ou outras datas críticas
que devem ser encontradas
7) Listar tarefas, por fase do projeto, a fim de que
elas possam ser acompanhadas
8) Estimar o pessoal necessário para acompanhar
cada tarefa
9) Estimar o pessoal disponível para acompanhar
cada tarefa
45
Planejamento de Projeto de Software
Processo de Planejamento de Projeto
10) Determinar nível de perfil necessário para
desempenhar cada tarefa
11) Determinar dependências de tarefa
– Quais tarefas podem ser feitas em paralelo
– Quais tarefas requerem estar completas para
que outras tarefas possam iniciar
12) Projetar pontos de controle ou de revisão
13) Realizar estimativa de custo de projeto e análise
de custo x benefício
46
Planejamento de Projeto de Software
Plano de Projeto de Software

Cada etapa do processo de engenharia de software
deve produzir um resultado que possa ser revisado
e possa funcionar como uma base para os passos
que se seguirão.

O Plano de Projeto de Software é produzido ao
término das tarefas de planejamento e fornece
informações básicas sobre o custo e programação
de recursos que serão usadas ao longo do processo
de engenharia de software
47
Planejamento de Projeto de Software
Plano de Projeto de Software

O Plano de Projeto de Software deve:
1. Comunicar o escopo e os recursos à administração, ao
pessoal técnico e ao cliente do software;
2. Definir os riscos e sugerir técnicas para evitá-los;
3. Definir custos e prazos para as revisões administrativas;
4. Oferecer uma abordagem global ao desenvolvimento
do software para todas as pessoas envolvidas no
projeto;
5. Delinear como qualidade será garantida e mudanças
serão gerenciadas.
48
Planejamento de Projeto de Software
Plano de Projeto de Software



O Plano de Projeto de Software não precisa ser
um documento extenso e complexo. Seu propósito
é ajudar a estabelecer a viabilidade do esforço de
desenvolvimento.
O plano concentra-se na declaração geral do “o
que” e na declaração específica de “quanto” e “por
quanto tempo”.
As etapas subseqüentes do processo de engenharia
de software concentrar-se-ão na definição,
desenvolvimento e manutenção.
49
Planejamento de Projeto de Software
Plano de Projeto de Software
I. Introdução
A. Propósito do plano
B. Escopo do projeto e objetivos
1. Declaração do escopo
2. Funções principais
3. Questões de desempenho
4. Restrições técnicas e de
gerenciamento
II. Estimativas de projeto
A. Dados históricos usados
B. Técnicas de estimativas
3. Estimativas de esforço, custo e
duração
III. Estratégia de Gerenc. de Riscos
A. Tabela de riscos.
B. Discussão de riscos a gerenciar
C. Plano RMMM para cada risco
1. Mitigação de risco
2. Monitoração de risco
3. Gerenciamento de risco
IV. Cronograma
A. Divisão de trabalho no projeto
B. Rede de tarefas
C. Gráfico de timeline (gráfico de
Gantt)
D. Tabela de recursos
V. Recursos do projeto
A. Pessoal
B. Hardware e software
C. Recursos especiais
VI. Organização do pessoal
A. Estrutura de equipe (se for o caso)
B. Relatórios administrativos
VII. Mecanismos de rastreamemto e
controle
A. Garantia e controle de qualidade
B. Gerenciamento e controle de
mudanças
VIII. Apêndices.
50