Modelo COCOMO II

De acordo com Pressman e Maxim (2016, p. 745), COCOMO –COnstructive COst MOdel (Modelo Construtivo de Custo) é uma hierarquia de modelos de estimativa de software proposto por Barry Boehm em 1981. Este modelo evoluiu para um modelo mais abrangente denominado COCOMO II.

O modelo COCOMO II foi derivado dos dados de produtividade coletados de milhares de projetos de software e, com base nestes dados, foi derivado um modelo de estimativa E representado pela equação:

Onde:

E= esforço em pessoas-mês ou pessoas-ano

t = duração do projeto em meses ou anos

B = fator de habilidades especiais (para programas pequenos em torno de 5 a 15 KLOC, B= 0.16 e para programas grandes maiores que 70 KLOC B= 0.39)

P = parâmetro de produtividade (valores típicos podem ser P=2mil para software embarcado ou de tempo real, P= 10mil para softwares de telecomunicações e sistemas e P=28mil para aplicações comerciais).

Modelos de Estimativa Empíricos

Alguns modelos de estimativa para software usam fórmulas empíricas. Essas fórmulas são derivadas usando análise de regressão de dados coletados de projetos anteriores. Normalmente usa-se uma amostra limitada de dados de projetos.

Cada modelo de estimativa é adequado para um determinado conjunto de classes de software e ambientes de desenvolvimento, ou seja, são dependentes dos dados dos projetos que foram usados para obtê-los. Devido a isso, geralmente esses modelos de estimativa devem ser adaptados para as condições locais da organização.

É claro que, antes de serem usados na sua empresa, esses modelos devem ser testados usando resultados de projetos finalizados. Os dados estimados pelo modelo devem ser comparados aos resultados reais e a eficácia do modelo deve ser analisada para as condições locais.

De acordo com Pressman e Maxim (2016, p. 744), a estrutura geral dos modelos empíricos tem a forma:

E = A + B x (ev)c

Onde:

A, B, c são constantes derivadas empiricamente

E esforço em pessoas-mês

ev variável de estimativa (LOC ou PF)

A maioria dos modelos de estimativa tem alguma forma de fator de ajuste ao projeto. Isso permite que a variável E seja ajustada por características específicas do projeto, tais como complexidade do problema, experiência da equipe e ambiente de desenvolvimento.

A seguir, apresentamos alguns exemplos de modelos empíricos orientados a FP para esforço (E):

E = -13.39 + 0.0545 x (PF) (modelo de Albrecht e Gaffney)

E = 60.62 + 7.728 x 10-8 x (PF)3 (modelo de Kemerer)

E = 587.7 + 15.12 x (PF) (modelo de Matson, Barnett e Mellichamp)

E agora, alguns exemplos de modelos empíricos orientados a LOC para esforço (E):

E = 5.2 x (KLOC)0,91 (modelo de Walston-Felix)

E = 5.5 + 0.73 x (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)

É importante ressaltar que para os mesmos valores de FP ou LOC, os modelos vão gerar resultados diferentes (porque foram gerados, cada qual, em alguns domínios de aplicação específicos). Portanto, para utilizar esses modelos, eles devem ser adaptados para as necessidades locais.

Exemplos de Estimativas Baseadas em LOC (parte 2)

Exemplo 2:

A tabela 1 apresenta as estimativas de tamanho otimista, mais provável e pessimista para cada uma das funções a serem implementadas no software CAD do exemplo 1. Considerando que a empresa de software responsável em desenvolver o projeto produz 400 LOC/por mês, com um valor bruto de mão de obra de R$ 3000,00 por pessoa-mês, podemos, com base nesses dados, obter a estimativa de custo e esforço necessários para construir o software usando a técnica de estimativa baseada em LOC.

Tabela 1 – Estimativas de Tamanho Otimista, Mais Provável e Pessimista (em LOC)

Função	Otimista(Tot)	Mais Provável(Tmp)	Pessimista(Tpess)
Recursos de Visualização	3000	4400	6000
Recursos de Análise 2D	5000	5500	6500
Recursos de Análise 3D	6400	7000	6900
Recursos de Controle e Interface com o usuário	3300	2500	2300
Administração da Base de Dados	6000	4100	2600
Recursos de Controle de Periféricos	1000	2800	4200
Recursos de Análise de Projetos	7700	7900	8200

A tabela 2 apresenta o cálculo do tamanho de cada uma das funções (em LOC) utilizando a expressão apresentada anteriormente T=(Tot + 4Tmp + Tpess)/6.

Tabela 2 – Cálculo do tamanho de cada função

Função	Estimativa de LOC
Recursos de Visualização	T1 = ( Tot + 4Tmp + Tpess ) / 6 @4433
Recursos de Análise 2D	T2 = ( Tot + 4Tmp + Tpess ) / 6 @5583
Recursos de Análise 3D	T3 = ( Tot + 4Tmp + Tpess ) / 6 @6883
Recursos de Controle e Interface com o usuário	T4 = ( Tot + 4Tmp + Tpess ) / 6 @2600
Administração da Base de Dados	T5 = ( Tot + 4Tmp + Tpess ) / 6 @4167
Recursos de Controle de Periféricos	T6 = ( Tot + 4Tmp + Tpess ) / 6 @2733
Recursos de Análise de Projetos	T7 = ( Tot + 4Tmp + Tpess ) / 6 @7197
Estimativa das Linhas de Código (Total)	34317 LOC

Utilizando as estimativas de tamanho e os dados do valor bruto da mão de obra e produtividade fornecidos anteriormente, podemos calcular as estimativas de esforço e custo total conforme indicado a seguir.

Esforço necessário estimado=(Estimativa de LOC)/(produtividade média)

= (34317 LOC)/(400 LOC/pessoas-mês)

@ 86 pessoas-mês

Custo por LOC = (valor bruto da mão de obra) / (produtividade média)

= (3000 reais/pessoas-mês) / (400 LOC/pessoas-mês)

= 7.50 reais/LOC

Custo total estimado do projeto=(Estimativa de LOC) * (Custo por LOC)

= (34317 LOC) * (7.50 reais/LOC)

@ 257400.00 reais

Exemplos de Estimativas Baseadas em LOC

Exemplo 1:

Suponha um determinado software que será desenvolvido. Este software é do tipo CAD – Computer-Aided Design, ou seja, tem uma aplicação científica. Após a análise do escopo do software, suas funções principais foram identificadas e são relacionadas na tabela.

Principais funções identificadas no software CAD

Função	Estimativa de LOC
Recursos de Visualização	3000
Recursos de Análise 2D	5000
Recursos de Análise 3D	6400
Recursos de Controle e Interface com o usuário	3300
Administração da Base de Dados	6000
Recursos de Controle de Periféricos	1000
Recursos de Análise de Projetos	7700
Estimativa das Linhas de Código (Total)	32400

Em seguida, um intervalo de estimativa de LOC é desenvolvido para cada função. Esse intervalo considera as estimativas como otimista, mais provável e pessimista.

Os valores das estimativas apresentados na tabela 3, para cada função, foram obtidos utilizando a expressão para T já apresentada (T =(Tot + 4Tmp + Tpess)/6).

Por exemplo, para a função “Recursos de Análise 3D”, foram obtidas: estimativa otimista Tot= 3800 LOC; mais provável Tmp= 6500 LOC; pessimista TPess= 8600 LOC. Estes valores, aplicados na equação T= (3800 + 4x6500 + 8600)/ 6, produzem um valor esperado de T= 6400 LOC.

Após o cálculo das estimativas de LOC para cada função, foi identificada uma estimativa de 32400 LOC para o sistema a ser desenvolvido.

Considerando que uma análise de dados históricos revelou que a produtividade organizacional média para sistemas desse tipo é de 500 LOC/pessoas-mês e que o valor bruto da mão de obra é de R$ 4000,00 por pessoa-mês, o custo por linha de código é de aproximadamente:

Custo por LOC = (valor bruto da mão de obra)/(produtividade média)

= (4000 reais/pessoas-mês)/(500 LOC/pessoas-mês)

= 8 reais/LOC

Portanto, o custo total estimado para o projeto é de:

Custo total estimado do projeto = (Estimativa de LOC)*(Custo por LOC)

= (32400 LOC) * (8 reais/LOC)

= 25920.00 reais/mês

O esforço necessário estimado para desenvolver o projeto é de:

Esforço necessário estimado=(Estimativa de LOC)/(produtividade média)

= (32400 LOC)/(500 LOC/pessoas-mês)

@ 65 pessoas-mês

Técnica de decomposição: Estimativa Baseada em Problema

Como uma estimativa de projeto é tão boa quanto a estimativa do tamanho do trabalho a ser realizado, o dimensionamento representa o primeiro grande desafio do planejador de projeto. Para a determinação do tamanho do produto a ser construído, as abordagens mais utilizadas são:

• abordagem direta (medido em LOC – Lines of Code, por exemplo);
• abordagem indireta (medido em FP– Function Points, por exemplo).

De acordo com Pressman e Maxim (2016, p. 734), dados de LOC e FP são usados de duas maneiras distintas durante a estimativa do projeto de software: 1) como variáveis de estimativa para dimensionar cada elemento do software e 2) como métricas de referência coletadas de projetos anteriores e usadas em conjunto com variáveis de estimativa para desenvolver projeções de custo e esforço.

Em relação às técnicas de estimativa baseadas em LOC e FP, elas diferem quanto ao nível de detalhe necessário para a decomposição:

• Estimativa LOC: a decomposição considera que todas as funções podem ser decompostas em subfunções semelhantes a entradas de uma base de dados histórica (quanto maior for o grau de particionamento, mais provável será que estimativas precisas de LOC possam ser desenvolvidas)
• Estimativa FP: em vez de focalizar a função, é estimada cada uma das características do domínio de informação (entradas, saídas, arquivos de dados, consultas, interfaces externas), bem como os 14 valores de ajuste de complexidade.

Como alternativa, o planejador pode escolher outros componentes para dimensionar, como classes, objetos, casos de uso, modificações ou processos do negócio afetados.

Métricas referenciais de produtividade (por exemplo, LOC/PM ou FP/PM, onde PM=Pessoa por Mês) são então aplicadas à variável de estimativa adequada e o custo ou esforço correspondente à função é derivado. Em seguida, as estimativas de função são combinadas para produzir uma estimativa global para todo o projeto.

A experiência mostra que, frequentemente, há uma variação nos valores das métricas de produtividade de uma organização. Portanto, o uso como referencial de um único valor obtido de uma dada métrica não é recomendável.

O ideal é que a média de cada métrica deva ser calculada por domínio de projeto. Os projetos devem ser agrupados por tamanho de equipe, área de aplicação, complexidade e outros parâmetros relevantes. Em seguida, médias locais dos domínios devem ser calculadas.

No caso de estimativas de um novo projeto, ele deve ser primeiro classificado em um domínio e depois a média da métrica do domínio adequado deve ser usada para gerar a estimativa.

Independentemente da variável de estimativa que é usada (LOC, FP, número de classes, número de casos de usoetc), o planejador começa estimando um intervalo de valores para cada função (LOC, por exemplo) ou o valor do domínio de informação (FP, por exemplo).

Usando dados históricos (ou intuição caso todo o resto falhar), são estimados um valor de tamanho otimista (Tot), um mais provável (Tmp)e um pessimista (Tpess)para cada função ou contagem para cada valor do domínio de informação. Isso possibilita o cálculo de um valor esperado para a variável de estimativa tamanho (T), para cada função (LOC) ou valor do domínio de informação (FP).

Um exemplo de cálculo de um valor esperado para T pode ser a média ponderada:

T = ( Tot + 4Tmp + Tpess ) / 6

Uma vez determinado o valor esperado para a variável de estimativa de tamanho T, os dados históricos de LOC ou PF são aplicados.

Planejamento do Projeto: Estimativas do projeto

As estimativas de custo e esforço envolvem muitas variáveis como fatores humanos, técnicos, ambientais e políticos, que podem afetar o custo final do projeto e o esforço necessário para desenvolvê-lo.

Pressman e Maxim (2016, p. 733) indicam as seguintes opções que ajudam na obtenção de estimativas de custo e esforço que sejam confiáveis:

1. Adie a estimativa até que o projeto esteja mais adiantado: quanto mais tarde você fizer a estimativa, maior a probabilidade de acertar.
2. Baseie as estimativas em projetos semelhantes que já foram concluídos.
3. Use técnicas de decomposição: essas técnicas utilizam uma abordagem do tipo “dividir para conquistar”, que seria decompor o projeto em suas funções principais e atividades relacionadas.
4. Use um ou mais modelos empíricos para estimativas de custo e esforço.

Infelizmente, apesar de atraente, a opção 1 não é prática pois, normalmente, o cliente exige estimativas de custo e prazo logo no início. Desta forma, o adiamento deve ser feito com muito bom senso. A opção 2 depende fundamentalmente dos dados históricos usados para alimentar a estimativa; mas ainda que existam, nem sempre a experiência passada funciona como um bom indicador de estimativas futuras.

Na maioria das vezes, o problema de desenvolver uma estimativa de custo e esforço para um determinado projeto é muito complexo para ser considerado como um todo. Devido a isso, as técnicas de decomposição indicadas na opção 3, que reduzem o problema em um conjunto de problemas menores, se mostram atrativas, pois se espera que, com essa divisão, se torne mais fácil chegar à solução.

A opção 4 indica o uso de modelos empíricos. Esses modelos podem ser usados para complementar as técnicas de decomposição e oferecer uma estratégia valiosa.

A precisão da estimativa de um projeto depende dos seguintes fatores:

• o grau com que o planejador estimou adequadamente o tamanho do produto a ser construído;
• a aptidão para traduzir a estimativa de tamanho em esforço humano, tempo transcorrido e dinheiro;
• o grau com que o plano de projeto reflete a capacidade da equipe de software; e
• a estabilidade dos requisitos do produto e do ambiente que apoiam o esforço de Engenharia de Software.

Ferramentas automáticas de estimativa implementam uma ou mais técnicas de decomposição ou modelos empíricos, fornecendo uma interessante alternativa.

Planejamento do Projeto: Recursos do projeto

Uma tarefa importante no planejamento é a estimativa de recursos necessários para o desenvolvimento do software. A figura ilustra as três principais categorias de recursos de Engenharia de Software com que devemos nos preocupar em um projeto: recursos humanos, softwares reutilizáveis e ambiente de desenvolvimento.

Recursos de Engenharia de Software para o planejamento de estimativas

 

Fonte: Pressman; Maxim (2016, p. 731).

• Recursos humanos: após a avaliação do escopo, é realizada a seleção de habilidades necessárias para a conclusão do desenvolvimento, que envolve a especificação de cargos (como gerente de projeto, engenheiro de software sênior etc.) e a especialização (como banco de dados, teste, arquitetura cliente-servidor etc). Caso o projeto seja grande, a equipe pode estar geograficamente dispersa, o que requer a especificação da localização de cada recurso humano.
• Recursos de software reutilizáveis: as práticas de engenharia de software baseadas em componentes enfatizam a capacidade de reutilização. Esses componentes devem ser catalogados, padronizados e validados, podendo ser agrupados em quatro categorias: de prateleira (software já existente adquirido de terceiros ou de um projeto anterior), completamente testados (especificações, projetos, códigos ou dados de testes já existentes e validados), parcialmente testados (idem ao anterior, mas que requerem modificação significativa para serem usados) e novos (construídos pela equipe especificamente para o projeto).
• Recursos do ambiente de desenvolvimento: o Software Engineering Environment – SEE incorpora hardware e software, ou seja, uma plataforma de hardware que suporta as ferramentas de software necessárias para produzir os artefatos que irão compor o produto em desenvolvimento. Cada elemento de hardware e software deve ser especificado como parte do planejamento.