ESTIMATIVAS BASEADAS

EM NMERO DE LINHAS
DE CDIGO
PROF. RAUL SIDNEI WAZLAWICK
UFSC-CTC-INE
2010

ESTIMATIVA DE ESFORO
Uma das questes fundamentais em um projeto
de software saber, antes de execut-lo, quanto
esforo em horas de trabalho ser necessrio para
executar o projeto.

Essa rea, chamada de estimativa de esforo
conta com algumas tcnicas que tm apresentado
resultados interessantes ao longo dos ltimos
anos.

As tcnicas de estimao de esforo utilizam pelo
menos um parmetro como base.

Existem tcnicas baseadas em uma predio do nmero de

linhas que o programa dever ter e existem tcnicas baseadas
em requisitos, sejam eles descritos como funes, casos de uso
ou histrias de usurio.

LOC E KLOC
A tcnica conhecida como LOC (Lines of Code) ou
SLOC (Source Lines of Code) foi possivelmente a
primeira a surgir e consiste em estimar o nmero
de linhas que um programa dever ter a partir da
opinio de especialistas.

Rapidamente a tcnica evoluiu para a forma
conhecida como KLOC (Kilo Lines of Code), tendo
em vista o tamanho dos programas.

Uma unidade KLOC, portanto, vale mil unidades

LOC.

Alm disso, tambm so usados os termos MLOC
para milhes de linhas e GLOC para bilhes de
linhas de cdigo.

Este tipo de tcnica surgiu numa poca em que as

linguagens de programao, como FORTRAN eram
fortemente orientadas a linhas de cdigo.

Naquele tempo, programas eram registrados em cartes
perfurados, uma linha de cdigo por carto, de forma
que era uma medida bastante natural.
Porm, as linguagens atuais no so mais to restritivas
em termos de linhas de cdigo, de forma que talvez fizesse
mais sentido falar em comandos ao invs de linhas.

Usurios de linguagens como C, Java ou Pascal, por
exemplo, podero contar o nmero de comandos
terminados por ;, obtendo assim uma boa medida de
complexidade de um programa.

Mesmo assim, a noo de comando s funciona bem para
linguagens imperativas.

No caso de linguagens declarativas ou funcionais outras
formas de medir complexidade precisam ser usadas.

RELATIVIDADE DA TCNICA
A noo de linha de cdigo continua sendo uma
medida popular para complexidade de
programas, que podem varias de 10 a
100.000.000 de linhas ou comandos, com
complexidade inerente diretamente proporcional
na maioria das vezes.

A medida LOC faz sentido quando se compara
ordens de magnitude.

Um programa com 100.000 linhas possivelmente ser

mais complexo do que um programa com 10.000
linhas.

Mas pouco se pode concluir ao se comparar um
programa com 10.000 linhas e um programa com
11.000 linhas.

COMO ESTIMAR KLOC

Uma tcnica para estimao de KLOC reunir a
equipe para discutir o sistema a ser desenvolvido.

Cada participante dar a sua opinio sobre a
quantidade de KLOC que sero necessrias para
desenvolver o sistema.

Usualmente a reunio no chegar a um valor
nico.

3 VALORES DE KLOC SO OBTIDOS:

O KLOC otimista, ou seja, o nmero mnimo de
linhas que se espera desenvolver se todas as
condies forem favorveis.

O KLOC pessimista, ou seja, o nmero mximo
de linhas que se espera desenvolver ante
condies desfavorveis.

O KLOC mdio, ou seja, o nmero de linhas que
se espera desenvolver em uma situao de
normalidade.

KLOC ESPERADO
KLOCesperado = (4*KLOCmdio + KLOCotimista + KLOCpessimista) / 6

ARMADILHAS
Programadores experientes produziro software
com possivelmente menos linhas do que
programadores menos experientes.

A reutilizao de software baixa o nmero de
linhas efetivamente produzidas em relao s
funcionalidades efetivamente disponibilizadas.

Assim, essa medida sempre ser relativa ao tipo
de equipe e estrutura de trabalho que se tenha.

LOC E PRODUTIVIDADE

No se deve tambm considerar LOC como uma

boa medida de produtividade individualmente,
pois muitas vezes a complexidade inerente de um
programa vai muito alm da quantidade de
linhas:

poucas linhas de cdigo podero realizar tarefas

difceis e complexas enquanto muitas linhas podero
efetuar tarefas triviais apenas.

o caso de quem desenvolve software cientfico

ou jogos em contraponto com a produo de meros
cadastros e relatrios.

LOC E REFATORAO

Outra situao a considerar o fato de que

refatoraes do software podero remover muitas
linhas de cdigo intil ou redundante e isso no
deve ser considerado como uma produtividade
negativa.

COCOMO
COCOMO ou Constructive Cost Model um
modelo de estimativa de esforo baseado em
KLOC.

O modelo foi criado por Boehm (1981) a partir de
um estudo emprico sobre sessenta e trs projetos
na empresa TRW Aerospace.

Os programas examinados tinham de 2 a 100
KLOC e eram escritos em diversas linguagens de
programao.

Tambm conhecido como COCOMO 81.

COCOMO TEM 3 IMPLEMENTAES

Implementao bsica, quando a nica
informao sobre o sistema efetivamente
disponvel o nmero estimado de linhas de
cdigo.

Implementao intermediria, quando certos
fatores relativos ao produto, suporte
computacional, pessoal e processo so conhecidos
e podem ser avaliados para o sistema a ser
produzido.

Implementao avanada, quando for necessrio
subdividir o sistema em subsistemas e distribuir
as estimativas de esforo por fase e atividade.

TIPO DE PROJETO

Modo orgnico

se aplica quando o sistema a ser desenvolvido no envolver
dispositivos de hardware e a equipe estiver acostumada a
desenvolver este tipo de aplicao, ou seja, sistemas de baixo
risco tecnolgico e baixo risco de pessoal.

Modo semi-destacado

se aplica a sistemas com maior grau de novidade para a equipe
e que envolvem interaes significativas com hardware, mas
para os quais a equipe ainda tem algum conhecimento, ou
seja, sistemas onde a combinao do risco tecnolgico e de
pessoal seja mdio.

Modo embutido

se aplica a sistemas com alto grau de interao com diferentes
dispositivos de hardware, ou que sejam embarcados, e para os
quais a equipe tenha considervel dificuldade de abordagem.
So os sistemas com alto risco tecnolgico e/ou de pessoal.

COMO ESCOLHER O TIPO DE PROJETO

INFORMAES OBTIDAS COM COCOMO

E: O esforo estimado em pessoas/ms.

D: O tempo de desenvolvimento sugerido em
meses corridos.

P: O nmero de pessoas recomendado para a
equipe.

TAMANHO DA EQUIPE
O nmero de pessoas para a equipe ser sempre
dado por P = E/D.

A medida parece simplista, porque
aparentemente considera que a relao entre o
nmero de pessoas e o tempo de projeto linear.

Mas o clculo do esforo estimado (E) j leva em
conta esses fatores, pois uma funo
exponencial, como ser visto adiante.

COCOMO BSICO
E = ab * KLOCbb

D = cb * Edb

LIMITAO
Deve-se observar que o modelo bsico tambm
fica limitado a projetos cujo esforo total no
ultrapasse 100 pessoas/ms, visto que acima
deste limite, o plano de projeto ser
demasiadamente grande para ser devidamente
gerenciado.

Neste caso, o projeto deve ser quebrado em
subprojetos e, se possvel, o modelo COCOMO
avanado deve ser aplicado.

EXEMPLO
KLOC = 20

E = 2,4 * 201,05 = 56 pessoas/ms

D = 11,5 meses

P = 5 pessoas

Todos os valores so aproximados devido s casas

decimais, mas a concluso do modelo COCOMO
bsico que um projeto orgnico com previso de
20.000 linhas de cdigo ser desenvolvido em cerca de
1 ano por uma equipe de 5 pessoas.

O modelo bsico bom por ser simples e rpido,

mas sua capacidade preditiva limitada devido
ao fato de que o esforo de desenvolvimento no
ser funo apenas do nmero de linhas de cdigo,
mas tambm de outros fatores, que so
considerados a partir do modelo intermedirio

COCOMO INTERMEDIRIO

O modelo intermedirio vai considerar uma avaliao sobre

vrios aspectos do projeto alm das simples linhas de
cdigo.
A tabela mostrada a seguir apresenta os 15 fatores do
modelo original organizados em 4 grupos.
A tabela exige que se indique para cada fator uma nota que
varia de muito baixa a extra alta.
A partir dessa nota, um valor numrico correspondente
obtido para cada fator.
Por exemplo, se a dimenso da base de dados esperada
muito alta ento o fator DATA ter valor numrico 1,16.

FATORES INFLUENCIADORES

EAF

Os 15 valores numricos obtidos para os fatores

so combinados atravs a multiplicao,
produzindo o valor EAF:

EAF = RELY * DATA * CPLX * ... * SCED

NO MODELO INTERMEDIRIO

E = ai * KLOCbi * EAF

CENRIOS
As notas para os fatores ainda podem ser obtidas
em funo de cenrios mais otimistas ou mais
pessimistas.

Na tabela anterior um projeto fictcio avaliado
com duas notas: a maior a pessimista e a menor
a otimista.

As notas esto indicadas nas clulas pintadas de
cinza.

Quando apenas uma clula pintada em uma
linha porque os cenrios otimista e pessimista
se confundem.

FATORES INFLUENCIADORES

CENRIO OTIMISTA
EAF = 1,3267

E = 2,8 * 201,05 * 1,3267 = 86 meses

CENRIO PESSIMISTA
EAF = 2,8497

E = 2,8 * 201,05 * 2,8497 = 185 meses

Essa discrepncia mostra como esses fatores

podem afetar a produtividade da equipe em
funo do projeto.

COCOMO AVANADO

A implementao avanada ou completa do

modelo COCOMO introduz facetas como a
decomposio do projeto em subprojetos, bem
como estimativas individualizadas para as fases
do projeto.

COCOMO II

ftp://ftp.usc.edu/pub/soft_engineering/COCOMOII
/cocomo97docs/modelman.pdf

BIBLIOGRAFIA
Boehm, B. (1981). Software Engineering
Economics. Englewood Cliffs, NJ: Prentice-Hall.

Boehm, B. (2004). COCOMO II Model Definition
Manual. USC. Disponvel em:
ftp://ftp.usc.edu/pub/soft_engineering/COCOMOII
/cocomo97docs/modelman.pdf Consultado em:
20/09/2010.