medida de esforço de desenvolvimento de...

Medida de Esforço de Desenvolvimento de Software

Luiz Leão – [email protected]

http://www.luizleao.com

Unidade IV – Técnicas de Estimativa

de Esforço e Prazo

mailto:[email protected]

http://www.luizleao.com/

Unidade IV – Técnicas de Estimativa de Esforço e Prazo


Conteúdo Programático

Unidade IV – Técnicas de estimativa de esforço e prazo

COCOMO (Básico – Intermediário – detalhado)

COCOMO II

Estimativas de prazo

Estimativas de custo

Estimativas de defeitos pré-release

Estimativas de esforço de retrabalho

Método de Putnam

Estimativa de custos e esforço para a manutenção de software

Outros métodos

Estudo de casos

Acompanhar projetos (método EVA).

COCOMO



COCOMO - Introdução

Construtive Cost Model

Criado por Barry Boehm no seu livro “Economia da Engenharia de

Software” (1981)

É um modelo desenvolvido para estimar esforço, prazo, custo e

tamanho da equipe para um projeto de software.

Como foi desenvolvido em 1981, ficou conhecido como COCOMO 81



COCOMO - Introdução

O método foi derivado e baseado nas análises feitas em um conjunto

de 63 projetos, cobrindo áreas como: negócios, controle, científica,

suporte e sistema operacional.

Os programas examinaram de 2.000 a 100.000 linhas de código em

linguagens de programação de Assembly a PL/I.



COCOMO – Modos de Desenvolvimento

Definidos por Boehm para caracterizar o desenvolvimento de

software, podem ser:

Orgânico

Semi-Destacado

Embutido




ORGÂNICO:

Equipes relativamente pequenas desenvolvem sistemas num

ambiente altamente “familiar”.

Nesse modo de desenvolvimento, a maior parte das pessoas

engajadas no projeto tem experiência prévia com sistemas

similares na organização e entendimento completo do sistema.




ORGÂNICO (Cont.):

Outras características do modo orgânico são:

Ambiente estável de desenvolvimento com pouca

necessidade de inovação

Inexistência de requisitos de entrega rígidos;

Uso de algoritmos simples

Tamanho relativamente pequeno, com projetos na faixa de

até 50.000 linhas de código.




SEMIDESTACADO:

O modo semidestacado é aplicado em projetos de software com

características situadas entre os modos orgânico e embutido.

Suas características básicas são:

A equipe mescla grande e pouca experiência com a aplicação

e com a tecnologia

O tamanho do software pode chegar a 300.000 linhas de

código.




EMBUTIDO:

O principal fator que distingue um projeto de software de modo

embutido ou restrito é a necessidade de seguir restrições

rigorosas.

O produto a ser desenvolvido deverá operar dentro de um

contexto complexo de hardware, software e regras e

procedimentos operacionais.

São projetos de software caracterizados por serem relativamente

grandes, com muita necessidade de inovação, que demandam

altos custos de verificação e validação.




EMBUTIDO (Cont.):

Exemplos de projetos do modo embutido são:

Projeto de sistema de transferência eletrônica de fundos

Projeto de sistema de controle de tráfego aéreo

Projeto de Controle de Hidroelétrica

Etc.



COCOMO – MODELOS

O COCOMO possui 3 diferentes modelos que refletem a

complexidade de desenvolvimento do produto:

Básico

Intermediário

Avançado ou Detalhado



COCOMO - BÁSICO

Calcula o esforço do desenvolvimento de software em função do

tamanho estimado do programa expresso em linhas de código

estimadas.



COCOMO - BÁSICO

FÓRMULAS:

Esforço aplicado por pessoa no mês:

Eb = ab(KLOC)bb

Onde:

ab, bb = Coeficientes de Desenvolvimento

KLOC = Quantidade de milhares de linhas de código

Projeto de Software ab bb cb db

Orgânico 2.4 1.05 2.5 0.38

Semi-Destacado 3.0 1.12 2.5 0.35

Embutido 3.6 1.20 2.5 0.32



COCOMO - BÁSICO

FÓRMULAS:

Tempo de Desenvolvimento:

D = cb(E)db

Onde:

cb, db = Coeficientes de Desenvolvimento

E = Esforço aplicado pelo desenvolvedor


Orgânico 2.4 1.05 2.5 0.38


Embutido 3.6 1.20 2.5 0.32



COCOMO - BÁSICO

FÓRMULAS:

Quantidade de Desenvolvedores Necessários:

P = E / D

Onde:

E = Esforço aplicado pelo desenvolvedor

D = Tempo de Desenvolvimento


Orgânico 2.4 1.05 2.5 0.38


Embutido 3.6 1.20 2.5 0.32



COCOMO - BÁSICO

COCOMO básico é bom por ser rápido em estimativas e custos de

software, mas sua exatidão é limitada .

Ele não leva em conta as limitações de hardware, a qualidade do

pessoal e experiência, o uso de ferramentas e técnicas modernas, e

outros atributos do projeto conhecido por ter uma influência

significativa sobre os custos de software, o que limita a sua precisão



COCOMO – INTERMEDIÁRIO

Calcula o esforço de desenvolvimento de software em função do

tamanho do programa e de um conjunto de direcionadores de custo,

alternativamente chamados atributos ou fatores de software, que

incluem avaliações subjetivas do produto, do hardware, do pessoal e

dos atributos do projeto.




Direcionador de Custo:

É uma característica de desenvolvimento de software que tem

efeito aumentativo ou diminutivo na quantidade de esforço de

desenvolvimento final do projeto, como por exemplo, a

experiência da equipe de projeto, ou ainda, a confiabilidade

requerida do software [COCOMOII, 2000].




FATOR DE AJUSTAMENTO DE ESFORÇO (EAF):

No Modelo Intermediário são utilizados itens de avaliação do

modelo básico e criados mais alguns, tais como:

Atributos de Produto,

Atributos de Hardware,

Atributos Pessoais,

Atributos de Projeto.




FATOR DE AJUSTAMENTO DE ESFORÇO (EAF):

Para cada um dos atributos é dado um valor, de 0 a 6 onde 0 =

muito baixo e 6 = muito alto, posteriormente é feita uma

multiplicação dos resultados para a criação do EAF(Effort,

Adjustment Factor), ou, Fator de Ajustamento de Esforço.



COCOMO - INTERMEDIÁRIO

FÓRMULAS:

Esforço aplicado pelo desenvolvedor:

E = ai(LOC)(bi).EAF

Onde:

ai, bi = Coeficientes de Desenvolvimento

LOC = Quantidade de linhas de código

EAF = Fator de Ajustamento de Esforço

Projeto de Software ai bi

Início (orgânico) 3.2 1.05

Meio (semidestacado) 3.0 1.12

Fim (embutido) 2.8 1.50



COCOMO - AVANÇADO

Também conhecido como Detalhado, ele incorpora todas as

características da versão intermediária, incluindo a avaliação do

impacto dos atributos do software e da equipe desenvolvedora em

cada passo do processo de engenharia de software.



Modelos Paramétricos

Relação matemática entre tamanho, esforço, prazo e qualidade

Essa relação é afetada por fatores de performance, ou parâmetros

Ex: COCOMO II, SLiM, KnowledgePan, etc.

COCOMO II



COCOMO II

Devido à idade dos projetos que embasaram o modelo, assim como

sua incapacidade de lidar com ciclos de vida iterativos e com a

utilização de componentes Commercial-Off-The-Shelff – COTS

(Comerciais de Prateleira), o COCOMO 81 é atualmente considerado

obsoleto, tendo sido substituído por sua versão II, publicada em 2000.

Foi Obtido e Calibrado com base em 161 projetos cuidadosamente

selecionados a partir de 2000 projetos candidatos

Antes de ser usado, o modelo deve ser calibrado a partir dos dados

históricos de projetos semelhantes àqueles que se deseja estimar



COCOMO II – Calibrando o Esforço



COCOMO II – Estimando Produtividade



• Possui 22 parâmetros (5 com efeito exponencial e 17

com efeito linear) que permitem ajustar as

características de um projeto específico.

COCOMO II



O COCOMO II é compatível com os métodos iterativos

e incrementais tais como RUP (Rational Unified

Process)

A Rational e a Microsoft são empresas que ajudam a

financiar o COCOMO II

O modelo encontra-se em um livro e a USC promove

encontros anuais sobre o método

COCOMO II



COCOMO II

Ele evoluiu para um modelo de estimativa de custo de software mais

abrangente

Assim como o seu predecessor, o COCOMO II é na realidade uma

hierarquia de modelos de estimativa que trata as seguintes áreas:

Modelo de Composição de aplicação

Modelo de Estágio do Início do Projeto

Modelo do Estágio Pós-Arquitetura



COCOMO II – Modelo de Composição de Aplicação

Usado durante os primeiros estágios da engenharia de software, em

que:

Protótipo das interfaces de usuário;

Consideração da interação de software e sistema;

Avaliação do desempenho;

Avaliação da maturidade da tecnologia;

São de suma importância



COCOMO II – Modelo de Estágio do Início do Projeto

Usado quando os requisitos tiverem sido estabilizados e a arquitetura

básica de software tiver sido estabelecida.



COCOMO II – Modelo de Estágio Pós-Arquitetura

Usado durante a construção do software.



COCOMO II

Assim como todos os modelos de estimativa para software, os

modelos COMO II requerem informações de tamanho. Há disponíveis

3 diferentes opções como parte da hierarquia de modelo:

Pontos de Objeto

Pontos de Função

Linhas de Código-Fonte



COCOMO II

O modelo de composição de aplicação COCOMO II utiliza pontos de

objeto e é ilustrado nos próximos parágrafos

Devemos observar que há também disponíveis outros modelos de

estimativa mais sofisticados (Usando PF e KLOC) como parte do

COCOMO II



Assim como os Pontos de Função, o Ponto de Objeto é

uma medida indireta de software calculada por meio de

contagens dos números de:

Telas (na interface do usuário)

Relatórios

Componentes que podem ser necessários para

construir a aplicação

COCOMO II – Pontos de Objeto



Roteiro de Estimativa



Ferramenta USC-COCOMO II



COCOMO II – Fórmula

Método de Putnam



• É um modelo dinâmico de múltiplas variáveis que

pressupõe uma distribuição de esforço específica ao

longo da existência de um projeto de desenvolvimento

de software.

• O modelo foi construído a partir de uma distribuição de

mão-de-obra encontrada em grandes projetos (esforço

total de 30 pessoas-ano ou mais), porém a aplicação

desse método para projetos de software menores é

possível.

Método de Putnam



• A estimativa de Putnam relaciona linhas de

código ao tempo e esforço de desenvolvimento,

utilizando as seguintes equações:

Modelo Putnam

Fórmula



Modelo Putnam

Fórmulas



• Os valores típicos para a constante do estado da

tecnologia são:

– Para um ambiente pobre¹:

• Ck = 2.000

– Para um ambiente de desenvolvimento de bom nível²:

• Ck = 8.000

– Para um ambiente excelente³:

• Ck = 11.000

Modelo Putnam

Fórmulas



• ¹Ambiente de Desenvolvimento Pobre é um ambiente

sem base metodológica, sem documentação e com

revisões precárias

• ²Ambiente de Desenvolvimento Bom é um ambiente que

aplica metodologias, com documentação

• ³Ambiente de Desenvolvimento Excelente é um

ambiente com ferramentas e técnicas automatizadas

Modelo Putnam

Fórmulas



• O valor da constante de tecnologia (Ck) também pode

ser derivado das condições locais utilizando dados

históricos coletados no esforço do desenvolvimento

Modelo Putnam

Fórmulas



• O valor da constante de tecnologia (Ck) também pode

ser derivado das condições locais utilizando dados

históricos coletados no esforço do desenvolvimento

Modelo Putnam



• A estimativa de Putnam permite a troca de tempo pelo

esforço.

• Ao acrescentar pessoas num projeto, diminui-se o

tempo do desenvolvimento.

• Em contra partida aumenta-se o custo do projeto.

• Ao ultrapassar o ponto máximo para esta troca, o

projeto torna-se incontrolável

• Por outro lado, os administradores podem simular

outras situações, verificando o tempo, o esforço e o

custo do projeto.

• Quanto menor o tempo, maior o esforço e o custo do

desenvolvimento de um projeto

Modelo Putnam



• Esta estimativa permite o cálculo da produtividade

média constante através da fórmula:

Modelo Putnam



• Isso significa que a produtividade média constante (PR)

está relacionada ao tempo (T) e ao esforço do

desenvolvimento do sistema (K).

• Por isso, conclui-se que é difícil medir a produtividade

de um projeto com base em outro, por que ambos

devem ter o mesmo grau de dificuldade (mesmo

número de arquivos, mesmo número de consultas,

relatórios,...) e o mesmo tempo

Modelo Putnam



• A equação utilizada pela estimativa de Putnam (também

conhecida como equação do software) apresenta como

resultado uma função, fazendo com que o usuário

defina valores para determinar a curva (Rayleigh-

Norden - Tempo x Esorço) e decidir qual será o esforço

e o tempo necessário para o desenvolvimento do

software.

Modelo Putnam



Modelo Putnam – Curva Rayleigh-Norden



• Barry Boehm fez um interessante estudo em tentativas

para diminuir o cronograma de projetos;

• Ele examinou mais de 700 projetos que tentaram

entregar código em menos tempo do que o ponto de

entrega nominal Tn.

• Nenhum dos projetos foram bem sucedidos na redução

do cronograma abaixo de 75% do valor nominal ponto

de entrega Tn, e ele batizou a área de "Região

Impossível" para indicar que você não pode comprimir

tempo para além deste ponto. (Veja Barry Boehm

“Software Engineering Economics”, Prentice Hall, 1981),

Modelo Putnam – Curva Rayleigh-Norden

Método EVA



Earned Value Analysis – Análise de Valor Agregado

É uma técnica de medição de desempenho para medir

a performance do projeto. Isto de maneira conjunta, pois

análises isoladas de prazo, custo, qualidade, esforço

tendem a mascarar a performance do projeto.

Foi utilizado pela primeira vez na década de 60 pela

Força Aérea dos EUA no projeto do míssil “Minuteman”;

Em 1998 foi reconhecido pelo ANSI sendo divulgado

fortemente entre segmentos industriais;

Método EVA



• A análise de valor agregado é uma ferramenta que vem

sendo bastante utilizada no gerenciamento de projetos.

Nesse contexto, consiste em analisar o desempenho do

projeto considerando três dimensões:

– Tempo

– Custo

– Trabalho (Escopo).

Método EVA



• Linha de Base (Baseline): É o planejamento aprovado

para os itens de projeto. Os itens do projeto podem ser

Escopo, Custo e Tempo ou ainda parâmetros Técnicos

e de Qualidade. De uma forma geral as linhas de base

são criadas após a aprovação de um planejamento ou

de um replanejamento.

• Linha de Andamento: Linha de Andamento ou Data de

Andamento é gerada por meio da coleta de informação

de execução realizada do projeto em um determinado

momento para os itens estabelecidos.

Conceitos Complementares



• A Linha de Base e a Linha de Andamento servem para

auxiliar o controle do projeto por meio da comparação

dos parâmetros de planejamento contra os de execução

e com isso verificar se ocorreram desvios entre o

previsto e o realizado.

• Ocorrendo desvios é necessários efetuar uma análise

para descobrir a causa desse desvio e assim tomar uma

ação corretiva adequada para corrigir o problema

Conceitos Complementares



• De forma resumida, significa analisar três curvas de

desempenho:

– (i) Uma curva representa o valor planejado para o projeto

(dado pelo custo previsto para o projeto em sua baseline).

– (ii) Outra curva representa o valor planejado para o projeto

para o trabalho a ser realizado até um dado momento (dado

pelo custo previsto para o projeto até aquele momento).

– (iii) A terceira curva representa o valor real do trabalho

realizado para o projeto naquele dado momento (dado pelo

custo real do projeto naquele momento).

Método EVA



Método EVA

Gráfico



• Planned Value ou Custo Orçado do Trabalho Agendado

(PV – COTA): É o custo planejado para o trabalho que deve

ser realizado até um dado momento do projeto em sua

baseline.

• Earned Value ou Custo Orçado do Trabalho Realizado

(EV – COTR): É o custo planejado para o trabalho realizado

até o momento. Corresponde ao Valor Agregado

• Actual Cost ou Custo Real do Trabalho Realizado (AC –

CRTR): É o custo real para o trabalho realizado até o

momento.

Variáveis para cálculo do Valor Agregado



• É uma medida do desempenho, em termos de custo,

em um projeto. É a diferença algébrica entre o valor

agregado (earned value) e o custo real (actual cost). Um

valor positivo indica um bom desempenho.

CV = EV - AC

Principais Indicadores da Análise de Valor Agregado

Variação de Custo (VC) ou Cost Variance (CV)



• É uma medida do desempenho ao atender o cronograma de um

projeto.

• É a diferença algébrica entre o valor agregado (earned value) e o

valor planejado (planned value).

• Um valor positivo demonstra que a entrega do valor é antecipado.

Vale observar que isto não significa necessariamente que haja

antecipação do marco final do projeto, pois para que se possa

afirmar uma antecipação efetiva, todas as variações observadas

devem ser no caminho crítico do projeto.

SV = EV - PV


Variação de Cronograma ou SV (Schedule Variance)



• É uma medida da eficiência ao atender o cronograma

de um projeto.

• É a razão entre o valor agregado (earned value) e o

valor planejado (planned value).

• Índice de Performance de Cronograma maior ou igual a

1 indica ritmo eficiente de avanço no cronograma

SPI = EV/PV


Índice de Desempenho de Prazos (IDP) ou

Schedule Performance Index (SPI )



• É uma medida da eficiência, em termos de custo, em

um projeto. É a razão entre o valor agregado (earned

value) e o custo real (actual cost).

• Índice de Desempenho de Custo maior ou igual a 1

indica que os recursos do projeto estão sendo utilizados

de forma eficiente.

CPI = EV/AC


Índice de Desempenho de Custo (IDC) ou Cost

Performance Index (CPI )



• Custo total orçado: R$ 50.000,00 (custo da baseline)

• Duração total: 69 dias

• COTA (PV – Custo Planejado) x COTR (EV – Custo planejado para o

Trabalho Realizado) x CRTR (AC – Custo Real do Trabalho Realizado)

• O projeto está atrasado (linha azul) e acima do custo previsto (linha

vermelha

Exemplo



Custo Previsto (Otimista) = (AC – EV ) + custo da baseline

Duração Prevista (Otimista) = Atraso Atual + duração da baseline

Atraso Atual = (1 – SPI) x tempo decorrido

Exemplo: Para o projeto hipotético representado no Gráfico 1, após decorridos

32 dias do projeto, EV é R$ 12.800, PV é R$ 21.000 e AC é R$ 29.500.

• As previsões otimistas para esse projeto são: – Custo Previsto (Otimista) = (AC - EV )+ custo da baseline = 29.500 – 12.800 + 50.000

= R$ 66.700

– Duração Prevista (Otimista) = Atraso Atual + duração da baseline

= ((1 – SPI) x Tempo decorrido) + 69

= ((1 - 0,68) x 32) + 69 = 10,24 + 69 = 79,24 dias

Previsões de Custos e Prazos usando EVA

Método Otimista: “Todo o trabalho futuro do projeto será realizado de

acordo com o ritmo previsto inicialmente”



Custo Previsto (Realista) = custo da baseline/CPI

Duração Prevista (Realista) = duração da baseline/SPI

• Exemplo: Para o projeto citado anteriormente, as

previsões realistas são: – Custo Previsto (Realista) = custo da baseline/CPI = 50.000 / 0,42

= R$119.000

– Duração Prevista (Realista) = duração da baseline/SPI

= 69 / 0,68

= 101 dias


Método Realista (ou do Valor Mais Provável): “O ritmo do projeto

continuará com a mesma taxa de desvio que apresenta atualmente”



Custo Previsto (Pessimista) = custo da baseline/(CPI x SPI)

• Exemplo: Para o projeto citado anteriormente, a previsão de custo

pessimista é:

– Custo Previsto (Pessimista) = custo da baseline/(CPI x SPI)

= 50.000 / (0,42 x 0,68)

= R$175.000,00


Método Pessimista: “O projeto vai custar ainda mais, pois mais

recursos serão empregados para entregar no prazo”



Otimista Realista Pessimista

Custos 66.700 119.000 175.000

Duração 79,24 101 -

Comparando Estimativas de Custo



Exercício

• Os valores a seguir representam o desempenho de um projeto hipotético em seu 30º

dia, utilizando-se a análise de valor agregado. O custo total previsto para o projeto é

de R$ 100.000 e a duração total prevista é de 130 dias.

a)O que o gerente do projeto pode concluir a partir dos valores apresentados na tabela?

b)Com esses valores, faça as previsões otimista e realista para os custos e a duração

do projeto.

Variáveis Nomenclatura Valor

Custo Planejado para o Trabalho do Projeto Planned Value (PV) 30.000

Custo Planejado para o Trabalho Realizado Earned Value (EV) 25.000

Custo Real do Trabalho Realizado Actual Cost (AC) 27.000

Indicadores Nomenclatura Valor

Índice de Desempenho do Tempo Schedule Perfomance Index (SPI=EV/PV) 0,83

Índice de Desempenho do Custo Cost Performance Index (CPI=EV/AC) 0,93



Leitura Complementar

• Por que é importante fazer análise de Valor

Agregado?

http://www.clubegp.com.br/artigo/184-por-que-

e-importante-fazer-analise-de-valor-agregado

http://www.clubegp.com.br/artigo/184-por-que-e-importante-fazer-analise-de-valor-agregado





















medida de esforço de desenvolvimento de...

Documents