Planejamento/Gerenciamento
Alexandre Monteiro
1/57
Objetivos





Evitar os erros clássicos
O que é projeto?
Ciclo de vida de projetos
Elementos essenciais
Objetivos gerais do planejamento e
gerenciamento do projeto de
software
2/57
Erros Clássicos
Desenvolvimento de Software é
uma atividade complicada ...
3/57
Pessoas

Motivação incoerente


Pessoal fraco


Seleção apressada ao invés de conveniente …
Pessoal problemático


Esforço do pessoal e chefe de férias …
Uma pessoa pode desconcentrar uma equipe …
Heroísmo

Posso fazer tudo, não preciso da equipe …
4/57
Pessoas

Mais pessoas no final do projeto


Escritórios barulhentos


Em pequeno incêndio, jogue gasolina …
Meu nível de concentração é excelente …
Atrito entre desenvolvedores e
clientes

Se você não adicionar isso, não quero
mais …
5/57
Pessoas

Expectativas irreais


Falta de interação com o usuário


Vamos terminar o projeto em 6 meses …
Isso é ambíguo …, mas vamos decidir sozinhos …
Crença cega

Essa parte do sistema é muito simples, em 1 ou
2 dias removemos todos os erros …
6/57
Processo

Cronogramas altamente otimistas


Gerenciamento de riscos insuficiente


Ganhamos tempo na análise de requisitos e no
projeto …
Se o risco A se concretizar, resolvemos …
Falha de contratos

Com o módulo M, a ser criado pela empresa E,
vamos melhorar nosso cronograma …
7/57
Processo

Planejamento insuficiente


Esse sistema é simples, não há o que
planejar …
Abandono de plano sob pressão

Devido ao cronograma, vamos codificar
já da especificação de requisitos e não
vamos testar …
8/57
Processo

Garantia de qualidade prejudicada


Controle de gerenciamento insuficiente


Só precisamos fazer os testes a partir da GUI
…
O que já fizemos? Não sei, mas sem problema …
Sem estimativas para tarefas necessárias

Não precisamos registrar o tempo para tarefa T
…
9/57
Processo

Planejamento para controlar depois


Fizemos em 3 meses, o que planejamos
fazer em 2, mas depois nós ganhamos
tempo …
Programação sem padronização

Vou codificar de qualquer jeito; ganho
tempo …
10/57
Produto

Requisitos demais


Desenvolvedor exagerado


Sei que o usuário não pediu, mas vamos melhorar
a performance do sistema …
Sei que o sistema não precisa e que não domino
a tecnologia, mas vou usar o recurso R …
Desenvolvimento orientado a pesquisa

Sei que vou desenvolver funcionalidade F, que é
estado-da-arte, mas minha estimativa é
razoável …
11/57
Tecnologia

Síndrome da bala de prata


Vou usar o gerador de GUIs e não terei
problemas quanto ao desenvolvimento das
GUIs …
Estimativa otimista com novas
ferramentas ou métodos

Vou usar ferramenta F, no lugar de G, daí
vou ganhar tempo …
12/57
Tecnologia

Troca de ferramentas no meio do
projeto


Vou usar a nova versão de F, pois tem
mais recursos …
Falta de controle sobre o códigofonte

Vamos trabalhar em paralelo no módulo
M (único arquivo), para ganharmos tempo
…
13/57
Projeto: Definição PMI

Um empreendimento temporário
realizado para criar um produto ou
serviço único
14/57
Ciclo de Vida



Delimitar início e fim de um projeto
Controlar administração do projeto
Estudo de viabilidade


Uma primeira fase do projeto?
Define

Trabalho a ser feito X envolvidos
15/57
Por que Planejar?

Criar propostas que sejam




Econômicamente viáveis e
Realizadas com recursos financeiros préestabelecidos
E que estejam de acordo com as
necessidades requisitadas
Representar precisamente o que se
pode fazer
16/57
Planejando um projeto de
software



Inicie com uma declaração explícita
do trabalho a ser feito e verifique se
corresponde ao que o cliente espera
Em projetos médios e grandes, criamse subprojetos menores e estima-os
separadamente
Baseie suas estimativas em dados
históricos de projetos semelhantes
17/57
Planejamento e Estimativa


Registre suas estimativas para
comparar com os resultados reais no
final do projeto
Planejamento continua durante
desenvolvimento e manutenção


Planejamento inicial não é suficiente
Planejamento detalhado só ocorre após a
especificação de requisitos
18/57
Planejamento e o Processo
de Software
19/57
Estimativa de Esforço


Há várias técnicas para estimar o
esforço (tamanho) exigido no
desenvolvimento de um produto de
software
Uma das mais recentes é a baseada
em casos de uso
20/57
Classificando Atores

Ator Simples


Sistema onde há uma API bem definida
para a interação
Peso 1
21/57
Classificando Atores

Ator Médio


Sistema onde a interação envolve um
protocolo, por exemplo TCP/IP
Peso 2
22/57
Classificando Atores

Ator Complexo


Ser humano que necessita de uma GUI ou
Web page
Peso 3
23/57
Classificando Casos de Uso

Casos de uso simples



Se a quantidade de passos no fluxo for
no máximo 3, ou
Necessitar de até 5 classes de análise
Peso 5
24/57
Classificando Casos de Uso

Casos de uso médio



Se a quantidade de passos no fluxo
estiver entre 4 e 7 (inclusive), ou
Necessitar de 5 a 10 classes de análise
Peso 10
25/57
Classificando Casos de Uso

Casos de uso complexo



Se a quantidade de passos no fluxo for
maior que 7, ou
Necessitar mais de 10 classes de análise
Peso 15
26/57
Fatores Técnicos
Fator
Descrição
Peso
T1
Sistema
Distribuído
Tempo de
resposta crítico
2
Treinamento
Especial
Requerido
1
T2
1
...
T13
27/57
Fatores Ambientais
Fator
Descrição
Peso
F1
Familiar com
modelo
Experiência na
Aplicação
1.5
Equipe 1/2
expediente
Ling. prog.
-1
F2
0.5
...
F7
F8
-1
28/57
Calculando os UCP´s


Atores (UAW)
Casos de uso (UUCW)




UUCP = UAW + UUCW
Fatores técnicos (TCF=0.6+0.01*TF)
Fatores ambientais (EF=1.4-0.03*EF)
UCP = UUCP * TCF * EF
29/57
Convertendo UCP em Horas

Karner



Portanto, um projeto com


1 UCP => 20 h
Este valor deve estar entre 15 e 30h e
deve ser ajustado de acordo com
histórico da empresa
UCP = 1.07 * 0.62 * 264 = 175.14
Demanda 175.14*20h = +/-3503h
30/57
Ferramenta para Calcular

EZEstimate

http://www.openrage.com/main/ezestima
te_full.htm
31/57
O que é um plano?

Documento que define o trabalho que e como
deve ser feito


Com uma estimativa de tempo e recursos
exigidos, e um contexto para gerenciamento de
controle e revisão, para cada maior tarefa
Servir de benchmark para comparar com
projetos anteriores, quando documentado
apropriadamente

Melhorando erros em estimativas e sua precisão
32/57
Estrutura Básica de um Plano






Introdução
Organização do Projeto
Requisitos com Recursos (Pessoas, SW,
HW)
Detalhamento das Tarefas
Análise de Riscos
Cronograma do Projeto




Milestones/Deliverables
Atribuição de tarefas a pessoas
Estimativa de tempo
Custo do Projeto
33/57
Recursos

Pessoas

Ricardo, Larissa, João, Márcia e Alberto


Software


Especialidades
JBuilder, .NET
Hardware

Laptop, PC, PDA
34/57
Tarefas





Dividir para conquistar
Normalmente atribuída a uma pessoa
Estimativa de tempo/esforço precisa
Pode-se associar especialidade(s)
necessária(s) para sua realização
Podem gerar (parte de) resultado
desejável (milestone)
35/57
Exemplos de Tarefas






Entrevistar cliente CL
Reunião
Projetar a GUI Gi
Criar o relatório R
Atualizar o site
Testar método M da classe C
36/57
Por que Gerenciar?

Para atingir objetivos e produzir
resultados


Concentrar responsabilidade e
autoridade para atingir objetivos
Coordenar e integrar todas as atividades
para chegar aos resultados
37/57
Objetivos do Gerenciamento
Custo
Objetivo:
• Limite de orçamento
• Prazo de entrega
• Desempenho Almejado
Tempo
Desempenho
38/57
Qualidades de Gerente







Liderança
Comunicação
Resolver problemas
Negociação
Influenciar a organização
Mentor
Especialista técnico e em processo
39/57
Gerenciamento das Tarefas

Milestones


Ponto final de uma atividade do processo
de software (um marco no cronograma)
Deliverables

Resultado do projeto a ser entregue ao
cliente. Usualmente entregue ao final de
uma fase.
40/57
Tarefas: Duração e
Dependências
Tarefa
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
Duração (dias)
8
15
15
10
10
5
20
25
15
15
7
10
Dependências
T1 (M1)
T2, T4 (M2)
T1, T2 (M3)
T1 (M1)
T4 (M5)
T3, T6 (M4)
T5, T7 (M7)
T9 (M6)
T11 (M8) 41/57
Rede de Atividades
8 days
15 days
M1
T3
15 days
T9
T1
25/7/99
4/7/99
start
14/7/99
5 days
4/8/99
25/8/99
T6
M4
M6
M3
7 days
20 days
15 days
T7
T2
25/7/99
10 days
M2
T4
T11
10 days
M7
T5
5/9/99
11/8/99
T10
18/7/99
M8
15 days
10 days
T12
M5
25 days
T8
Finish
19/9/99
42/57
Alocação de Pessoal
4/7
Fre d
11/7
18/7
25/
1/8
8/8
15/8 22/8
29/8
5/9
12/9
19/9
T4
T8
T11
T12
Ja ne
T1
T3
T9
Anne
T2
T6
Jim
Mar y
T10
T7
T5
43/57
Tempo de Desenvolvimento

A partir da rede de atividades


Determinar o caminho crítico



Grafo interligando tarefas com tempo
O caminho que leva mais tempo para
concluir
Gerente deve dar especial atenção às
tarefas contidas no caminho crítico
É crucial ter folgas no caminho crítico
44/57
Acompanhamento das
Tarefas
Data
Início
Fim
Interrup. Tarefa
20/04 08:00 15:30 30min
T1
21/04 08:00 14:00 30min
T2
25/04 15:00 18:00 10min
T3
01/05 08:00 18:00 1hora
T4
ATENÇÃO: Existe uma tabela semelhante com tempo estimado
45/57
Ferramenta para
Acompanhamento


Uma vez definidas as atividades e
estimativas de tempo para suas
realizações
Pode-se usar a ferramenta web
XPlanner para o acompanhamento
(http://www.xplanner.org/)
46/57
Custo do Projeto





Recursos humanos (R$/hora)
Instalações (fone, luz, etc.)
Reuniões (tempo, pessoas, etc.)
Material de escritório/informática
Etc.
47/57
Riscos

Identificação de Riscos


Análise de Riscos


Avalia as conseqüências dos riscos
Planejamento de Riscos


Identificar riscos de projeto, produto e negócio
Alternativas para evitar ou minimizar seus
efeitos
Monitoramento de Riscos

Acompanhar os riscos durante o projeto
48/57
Processo de Gerenciamento
de Riscos
Risk
identification
Risk analysis
Risk planning
Risk
monitoring
List of potential
risks
Prioritised risk
list
Risk avoidance
and contingency
plans
Risk
assessment
49/57
Identificação de Riscos





Riscos com Tecnologia
Riscos com Pessoal
Riscos Organizacionais
Riscos nos Requisitos
Riscos nas Estimativas
50/57
Principais Áreas de Riscos






Pessoal
Cronograma e Custo
Funcionalidade do Sistema
 Falta de entendimento da aplicação
 Análise de requisitos inadequada
Estabilidade dos Requisitos
 Cliente tenta alterar requisitos o tempo todo
Qualidade de Componentes Externos
DIFICULDADE EM ANTECIPAR TUDO!!!
51/57
Análise de Riscos



Avaliar a probabilidade e seriedade
de cada risco
A probabilidade pode variar de muito
baixo (0-20%), baixo (20-40%), médio
(40-60%), alto (60-80%) e muito alta
(80-100%)
Os efeitos dos riscos podem ser
catastróficos, sérios, toleráveis ou
insignificantes
52/57
Planejamento de Riscos

Para cada risco, elaborar estratégia
para gerenciá-lo

Estratégias para Evitar


Estratégias para Minimizar


A probabilidade de ocorrência é reduzida
O efeito do risco no projeto ou produto é
reduzido
Planos de Contingência

Se o risco ocorrer, o que devemos fazer?
53/57
Monitoramento de Riscos



Avaliar cada risco periodicamente
para determinar se está mais ou
menos provável de ocorrer
Avaliar os efeitos pois podem mudar
Cada risco crítico deve ser discutido
em reuniões gerenciais de progresso
do projeto
54/57
Identificação de Riscos
Risco
Probabilidade
Efeitos
Pessoal doente
Moderada
Sério
Tamanho do
software
desconhecido
...
Alta
Tolerável
Pessoal qualificado
não disponível
Alta
…
…
Catastrófico
55/57
Estratégias de
Gerenciamento
Risco
Estratégia
Pessoal doente Reorganizar equipe para ter
sobreposição de pessoas/trabalho
Recrutamento Alertar cliente sobre possível
atraso
…
…
Mudança nos
requisitos
Analisar rastreamento entre
requisitos para determinar
impacto
56/57
Bibliografia



Sommerville, I. Software Engineering
Humphrey, W. A Discipline for
Software Engineering
McConnel, S. Rapid Development
57/57