ESI EstimativasEsforço

Prévia do material em texto

Estimativas de Esforço
Prof. Wilson M Yonezawa
UNESP – FC – Bauru
Depto. Computação
yonezawa@fc.unesp.br
Engenharia Software I
O que é?
• Tentativa de se determinar quanto dinheiro,
esforço, recursos e tempo serão necessários
para construir um sistema ou produto
baseado em software específico
Por que é importante?
• Porque muitos trabalhadores técnicos preferem
fazem o trabalho técnico do que gastar tempo
planejando
• Muitos gerentes não possuem treinamento
suficiente em gestão técnica para sentir
confiança em que seu planejamento vai
melhorar o resultado de um projeto
• O projeto gasta em média 80% de seu tempo
em retrabalho
Sobre estimativas
• A estimativa de recursos, de custo e de cronograma para
um esforço de engenharia de software exige experiência,
acesso a boas informações históricas (métricas) e coragem
de se empenhar em precisões quantitativas, quando
informação qualitativa é tudo que existe
• Estimativa tem risco inerente e esse risco leva à incerteza
• O risco da estimativa é medido pelo grau de incerteza das
estimativas quantitativas estabelecidas para recursos,
custos e cronograma. Se o escopo do projeto é mal
entendido ou se os requisitos estão sujeitos a mudanças, a
incerteza e risco tornam-se perigosamente altos
Recursos de projeto
Estimativas de projeto
• Opções para conseguir estimativas:
1. Adie a estimativa até que o projeto esteja mais adiantado
2. Baseie as estimativas em projetos semelhantes, que já foram
completados
3. Use técnicas de decomposição relativamente simples para
gerar estimativas de custo e esforço de projeto
4. Use um ou mais modelos empíricos para estimativa de custo e
esforço de software
Ana
Highlight
Estimativa de esforço
• Importância
• Determinar o esforço necessário
• Determinar a duração (tempo)
• Determinar custo
• Determinar quantidade de pessoas
• Técnicas
• Não paramétricas
• Paramétricas
• Baseadas em linha de código
• Baseada em funcionalidade aparente
Técnicas paramétricas
• Baseadas em linha de código
• LOC (line of code) ou SLOC 
• COCOMO (Construtive Cost Model)
• COCOMO II (CII)
• Baseada em funcionalidade aparente
• FPA
• Pontos de Casos de Uso
• Pontos de História
Técnica LOC / SLOC
KSLOC otimista = número mínimo de linhas esperado
KSLOC pessimista = número máximo de linhas esperado
KSLOC esperado = número de linhas efetivamente esperado
KSLOC = (4*KSLOCesperado + KSLOCotimista + KSLOCpessimista) / 6
Técnicas de decomposição
• A precisão da estimativa depende de alguns fatores:
– Grau com que o planejador estimou o tamanho do produto a
ser construído
– A aptidão para traduzir a estimativa de tamanho em esforço
humano, tempo decorrido e dinheiro
– O grau com que o plano de projeto reflete a capacidade da
equipe de software
– A estabilidade dos requisitos do projeto e do ambiente que
apóiam o esforço de engenharia de software
Técnicas de decomposição
• Dimensionamento do software:
– Diz respeito ao tamanho do software
– Precisa ser quantificável
– Pode ser uma medida direta (LOC) ou
indireta (FP)
Estimativa baseada no problema
• Cálculo d valor esperado (variável de
estimativa S)
– S = (Sot + 4 Sm + Spess) / 6
– onde:
• Sot = Estimativa otimista
• Spess = Estimativa pessimista
• Sm = Estimativa mais provável
Estimativa baseada em LOC
S = (Sot + 4 Sm + Spess) / 6
Estimativa baseada em FP
Estimativa baseada em processo
Estimativa baseada em casos de uso
• Principais problemas para desenvolver estimativas:
– Casos de uso são descritos usando muitos formatos e
estilos diferentes
– Casos de uso representam uma visão externa do
software e são frequentemente escritos em diferentes
níveis de abstração
– Casos de uso não tratam da complexidade e das
características das funções que são descritas
– Casos de uso não descrevem comportamento
completo que envolvem muitas funções e
características
Estimativa baseada em casos de uso
• Estimando LOC com base no número real de casos de uso:
– LOCestimado = N x LOCavg + [(Sa / Sh – 1) + (Pa / Ph -1)] x LOC adjust
• N = Número real de casos de uso
• LOCavg = Média histórica de LOC por caso de uso para este tipo de subsistema
• LOC adjust = Representa um ajuste com base em n por cento de LOC em que n é
definido localmente e representa a diferença entre esse projeto e a “média” dos
projetos
• Sa = Cenários reais por casos de uso
• Sh = Média de cenários por caso de uso para este tipo de subsistema
• Pa = Páginas reais por caso de uso
• Ph = Média de páginas por caso de uso para esse tipo de subsistema
Modelos de estimativa empíricos
• Utiliza fórmulas derivadas empiricamente para
prever o esforço como função de LOC ou FP
• Os dados empíricos que apóiam a maioria dos
modelos são derivados de uma amostra limitada de
projetos
• Nenhum desses modelos é adequado a todas as
classes de software e todos os ambientes de
desenvolvimento
• Os resultados obtidos devem ser utilizados
cuidadosamente
Ana
Highlight
Modelos de estimativa empíricos
• Estrutura:
E = A + B (ev)c
onde:
– E = esforço em pessoas/mês
– A, B = constantes derivadas empiricamente
– Ev = variável de estimativa (LOC ou FP)
Modelos de estimativa empíricos
• Exemplos:
E = 5,2 x (KLOC)0,91 modelo de Walson-Felix
E = 5,5 + 0,73(KLOC)1,16 modelo de Bailey-Basili
E = 3,2 x (KLOC)1,05 modelo de Boehm simples
E = 5,288 x (KLOC)1,047 modelo de Doty para KLOC > 9
E = 91,4 + 0,355 FP modelo de Albrecht e Gaffney
E = 37 + 0,96 FP modelo de Kemerer
E = 12,88 + 0,405 FP modelo de regressão para pequenos projetos
Técnicas especializadas
• Estimativa para desenvolvimento ágil:
– Considerar cada cenário de usuário separadamente
– O cenário é decomposto em um conjunto de funções e
tarefas de engenharia de software que serão
necessárias para implementá-lo
– Cada tarefa é estimada separadamente
– Estimativas para cada tarefa são somadas para criar
um estimativa para o cenário
– As estimativas de esforço para todos os cenários que
devem ser implementados em um dado incremento de
software são somadas para desenvolver a estimativa
de esforço para o incremento
Ana
Highlight
Ana
Highlight
Ana
Highlight
Técnicas especializadas
• Estimativa para Projetos de Engenharia Web:
– Adaptar pontos de função para a aplicação Web
• Entradas – Telas ou formulários de entrada
• Saída – Página estática Web, script de página
dinâmica
• Tabelas – Tabela lógica do BD ou arquivos XML
• Interfaces – Arquivos lógicos nos limites de saída
do sistema
• Consultas – Interfaces externas publicadas (ex:
DCOM ou COM)
Ana
Highlight
Decisão de comprar ou fazer
• Comprar ou fazer software??
• Opções:
– Software de prateleira ou licenciado
– Componentes de software
– Construção sob medida
• Análise final:
– O produto de software vai ficar disponível antes do software
desenvolvido internamente?
– O custo de aquisição mais o custo de personalização serão
menores do que o custo de desenvolvimento interno?
– O custo do apoio externo será menor do que o custo de
apoio internet?
Técnica COCOMO II ou CII
• Técnica projeta para mensurar o esforço e 
o tamanho médio da equipe para as fases 
de elaboração e construção do Processo 
Unificado
Técnica COCOMO II ou CII
• Modelos:
• Early Design Model (fases de concepção e 
inicio da elaboração)
• Sete multiplicadores de esforço (M)
• Post-Achitectural Model
• Dezesete multiplicadores de esforço (M)
Técnica COCOMO II ou CII
E = Esforço total (fases de elaboração e construção)
A = Constante que deve ser calibrada a partir de dados históricos (2,94)
KSLOC = número estimado de linhas de código que serão desenvolvidas
S = Coeficiente de esforço 
Mi = Multiplicadoresde esforço
S = Expoente de esforço
B = Constante que deve ser calibrada a partir de dados históricos (0,91)
Fj = Fatores de escala
Técnica COCOMO II ou CII
T = Tempo linear ideal de desenvolvimento
B, C e D = Constante que deve ser calibrada a partir de dados históricos
E = Esforço total para o projeto
S = Coeficiente de esforço
P = Tamanho médio da equipe
A = 2,94
B = 0,91
C = 3,67
D = 0,28
Técnica COCOMO II - Fatores de Escala
• PREC – Precedentes (se o produto é similar a 
vários outros desenvolvidos anteriormente
• FLEX – Flexibilidade no Desenvolvimento (se o 
produto deve ser desenvolvido estritamente dentro 
dos requisitos)
• RESL – Arquitetura/Resolução de Riscos (se existe 
bom suporte para resolver riscos e para definir 
uma arquitetura)
• TEAM – Coesão da equipe (se a equipe é bem 
formada e coesa)
• PMAT – Maturidade de Processo (Nível de 
maturidade)
Técnica COCOMO II - Fatores de Escala
Tabela PREC
Técnica COCOMO II - Fatores de Escala
Tabela FLEX
Técnica COCOMO II - Fatores de Escala
Tabela RESL
Técnica COCOMO II - Fatores de Escala
Tabela TEAM
Técnica COCOMO II - Fatores de Escala
Tabela PMAT
Técnica COCOMO II – Multiplicadores de 
esforço
• Fatores do produto:
Confiabilidade requerida (RELY)
Tamanho da base de dados (DATA)
Complexidade do produto (CPLX)
Desenvolvimento visando reusabilidade (RUSE)
Documentação necessária (DOCU)
• Fatores da plataforma:
Restrição de tempo de execução (TIME)
Restrição de memória principal (STOR)
Volatilidade da plataforma (PVOL)
• Fatores humanos:
Capacidade dos analista (ACAP)
Capacidade dos programadores (PCAP)
Continuidade de Pessoal (PCON)
Experiência com apps semelhantes (APEX)
Experiência na plataforma (PLEX)
Experiência na ling. programação e ferramentas (LTEX)
• Fatores do projeto:
Uso de ferramentas de software (TOOLS)
Equipe de desenvolvimento distribuídas (SITE)
Cronograma de desenvolvimento requerido (SCED)
Técnica COCOMO II – Multiplicadores de 
esforço – Fatores do Produto
Técnica COCOMO II – Multiplicadores de 
esforço – Fatores do Produto
Técnica COCOMO II – Multiplicadores de 
esforço – Fatores da Plataforma
Técnica COCOMO II – Multiplicadores de 
esforço – Fatores Humanos
Técnica COCOMO II – Multiplicadores de 
esforço – Fatores Humanos
Técnica COCOMO II – Multiplicadores de 
esforço – Fatores do Projeto
Técnica COCOMO II – Calibragem do 
modelo
A = 2,62
Decisão de comprar ou fazer