MEDIDAS DE ESFORO DE

DESENVOLVIMENTO DE
SOFTWARE

autor
MARCOS CHIODI

1 edio
SESES
rio de janeiro 2016
Conselho editorial regiane burger; roberto paes; gladis linhares; karen bortoloti;
helcimara affonso de souza

Autor do original marcos danilo chiodi

Projeto editorial roberto paes

Coordenao de produo gladis linhares

Coordenao de produo EaD karen fernanda bortoloti

Projeto grfico paulo vitor bastos

Diagramao bfs media

Reviso lingustica amanda carla duarte aguiar

Imagem de capa nmedia | dreamstime.com

Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida
por quaisquer meios (eletrnico ou mecnico, incluindo fotocpia e gravao) ou arquivada em
qualquer sistema ou banco de dados sem permisso escrita da Editora. Copyright seses, 2016.

Dados Internacionais de Catalogao na Publicao (cip)

C539m Chiodi, Marcos

Medidas de esforo de desenvolvimento de software / Marcos Chiodi
Rio de Janeiro : SESES, 2016.
152 p. : il.

isbn: 978-85-5548-210-6

1. Medidas. 2. Mtricas. 3. Estimativas. 4. Software. 5. Esforo. I. SESES.

II. Estcio.
cdd 005

Diretoria de Ensino Fbrica de Conhecimento

Rua do Bispo, 83, bloco F, Campus Joo Ucha
Rio Comprido Rio de Janeiro rj cep 20261-063
Sumrio

Prefcio 5

1. Mtricas e Medidas 7
1.1 Introduo s mtricas e medidas 9
1.2 Introduo s mtricas e medidas 17
1.3 Boas prticas para o uso de mtricas 24
1.4 Por que utilizar mtricas de software 25

2. Determinao de Ponto por Funo 31

2.1 Categorizao de mtricas na engenharia

de software e mtricas no ciclo de vida do software. 33
2.2 Determinao de pontos por funo. 43

3. Mtricas Utilizando Pontos por Funo 57

3.1 Estudo de caso exemplo simples de

contagem utilizando um DFD. 59
3.2 Discusses iniciais sobre estimativas. 70
3.3 Outros tipos de contagem de pontos de funo. 74

4. Tcnicas de Estimativa de Esforo e Custo 81

4.1 Tcnicas de estimativa uma introduo. 83

4.2 Tcnicas de estimativa de esforo e custo em gesto de projetos 83
5. Tcnicas de Estimativas e
Estimativas com Base Estatstica 107

5.1 Tcnicas de estimativa continuao. 109

5.2 COCOMO 109
5.3 COCOMO II 116
5.4 Modelo de Estimativa de Putnam 122
5.5 Estimativa de projetos orientado a objetos 123
5.6 Estimativas com mtodos geis 124
5.7 Pontos de caso de uso 124
5.8 Gesto do desenvolvimento e
projetos de software usando mtricas 127
5.9 Anlise do valor agregado 130
5.10 Estimativas estatsticas 131
Prefcio
Prezados(as) alunos(as),

Seja bem-vindo nossa disciplina de Medidas de esforo de desenvolvimento

de software, na qual trataremos os vrios aspectos sobre medidas e estimativa de
softwares com o objetivo de aumentar a qualidade do planejamento do projeto de
desenvolvimento de software e tambm com o objetivo de suportar o gerente de
desenvolvimento com indicadores que o possibilite aplicar a melhoria contnua no
processo de desenvolvimento de software.
Focaremos aqui em tcnicas como o pontos de funo, a qual tem a proposta de
realizar o tamanho da complexidade de um sistema antes mesmo do seu desenvol-
vimento utilizando artefatos de projeto de software, por exemplo. Aprenderemos
um pouco sobre estimativa com o COCOMO.
Temos certeza de que esta disciplina agregar muito ao seu currculo acadmi-
co bem como ter bastante aderncia ao seu contexto prtico profissional de forma
que o aprendizado aqui conquistado pelo aluno poder ser diretamente aplicado
no seu local de trabalho em projetos e equipes de desenvolvimento de software.

Bons estudos!

5
 1
Mtricas e
Medidas
Neste captulo teremos a introduo da nossa disciplina medidas de esforo
de desenvolvimento de software.
Como um captulo introdutrio trataremos da base da nossa disciplina, que
: medidas e mtricas.
Queremos que voc entenda a importncia de se medir no processo de desen-
volvimento de sistemas. Queremos que voc saiba o que uma medida, o que
uma mtrica, qual a diferena entre uma e outra, quais so as caractersticas de
uma mtrica, como criar uma mtrica de boa qualidade.
Assim, voc ter alicerce para continuar na disciplina e ter mais facilidade
para enteder e aplicar as medidas de esforo de desenvolvimento de software,
tanto no mbito acadmico quanto no mbito profissional, por que lgico,
no queremos que esta disciplina seja somente um livro a mais na sua prate-
leira. Queremos que esta disciplina lhe ajude a desenvolver softwares melhores
em processos sistematizados de produo e que com isso voc tenha mais e
mais sucesso na sua carreira profissional.

OBJETIVOS
Entender a importncia das medidas e mtricas no processo de desenvolvimento de
software e no produto de software.
Definir mtricas e medidas.
Entender quais so as caractersticas de uma mtrica.
Aprender a definir uma mtrica.
Aprender boas prticas para a definio de mtricas.

8 captulo 1
1.1 Introduo s mtricas e medidas
Ol, seja bem-vindo ao primeiro captulo da nossa disciplina de medidas de
esforo de desenvolvimento de software, temos certeza que voc ir aprender
bastante e encontrar conhecimentos importantes para o seu futuro acadmico
e profissional na rea de desenvolvimento de sistemas e qualidade de software.
Contudo, agora no comeo, sabemos que as vezes difcil para o aluno en-
tender a importncia desta disciplina e das tecnologias que estudaremos nela
e sabemos que voc pode estar se perguntando: por que eu tenho que estudar
esta disciplina neste curso? Eu quero programar e no medir ....
Ento, iremos aqui estabelecer uma interessante discusso para que possamos
lhe explicar a importncia desta disciplina no seu curso e na sua vida profissio-
nal. Para iniciar a discusso gostaramos que voc pensasse na seguinte pergunta:
voc um bom desenvolvedor de sistema? . Caso voc no desenvolva pense em
uma outra pergunta: voc conhece um bom desenvolvedor de sistema?.
Independente da sua resposta para a pergunta ser SIM ou NO (para qual-
quer uma das perguntas) gostaramos que voc pensasse no que levou voc a
dar esta resposta. No que voc se baseou para julgar a sua performance de de-
senvolvedor? Foi nos sentimentos (feelings), percepo ou outros argumentos?
Para nos ajudar na contextualizao da discusso, gostaramos agora que voc
olhe para a figura abaixo e responda: quem o melhor jogador de basquete? .
JERRY COLI | DREAMSTIME.COM

JERRY COLI | DREAMSTIME.COM

Figura 1.1 Bogues (esq. primeiro plano) menor jogador que a liga NBA de basket j teve
e Bol (dir.) maior jogador que a NBA j teve. (Lobo, 2013)

captulo 1 9
 Voc pode mostrar esta imagem para os seus amigos e tabular as informa-
es, acreditamos que a resposta ser: o da esquerda. Isto por que provavel-
mente voc e seus amigos sero levados a acreditar que o principal fator que
determina se um jogador bom ou no no basquete seja a altura. Contudo, este
indicador de medida direta talvez no seja capaz de dizer quem o melhor jo-
gador e sim apenas quem o mais alto e voc e seus amigos possam ter se con-
fundido com a informao de senso comum (e nem sempre verdadeira) de que
o jogador mais alto o melhor. (Wikipedia, 2011) (Wikipedia, s.d.)
No caso da Imagem 1 talvez seja interessante voc saber que o jogador da di-
reita, Bogues, na poca em que jogou na franquia Charlote Hornets, colecionou
recordes como sendo o jogador que jogou o maior nmero de minutos, o de
maior nmero de assistncias e de roubo de bolas, alm de ser o jogador com a
maior mdia de assistncias por partida e o melhor percentual de acerto de sex-
tas de 3 pontos nos playoffs da NBA. Enquanto o jogador da esquerda, Manute
Bol, coleciona apenas recordes relacionados bloqueios (tocos) no basquete.
(Wikipedia, 2015)
WIKIPEDIA

O filme norte americano de 2011, Moneyball,

conta a histria do gerente de basebol do Okland
Athletics Billy Beane, que em 2002 precisava
montar um time para a temporada e resolveu uti-
lizar mtricas e um avanado sistema estatstico
ao invs de apostar na velha maneira de selecio-
nar jogadores que utilizava apenas olheiros que
indicavam jogadores de acordo com as suas per-
cepes e sentimentos (alis, h um dito popular
na administrao que diz que a nica pessoa que
ganhou muito dinheiro com sentimentos foi o
cantor Morris Albert com a msica Feelings).
No filme acima citado h um timo exemplo
no qual um daqueles que viria a ser um dos melhores arremessadores da tem-
porada era rejeitado pelos outros times por que o jeito de arremessar a bola
no era legal. Beane, juntamente com o seu sistema de mtricas e estatstica,
identificou que apesar do estilo no ser legal as medidas das mtricas mos-
travam que o arremesso era eficiente. Ento, contratou o profissional para o
seu time por preo de banana (j que ningum o queria na liga).

10 captulo 1
 O resultado desta ao do gerente de futebol no time foi a segunda colo-
cao na temporada daquele ano mesmo sendo o terceiro menor oramento
entre os times.
Voltando ento a pergunta se voc era um bom desenvolvedor, ser que a
resposta que voc havia dado inicialmente no foi baseada em ditos populares,
senso comum, percepes e/ou sentimentos que no necessariamente possam
traduzir o que de fato um bom desenvolvedor ou no?
O que queremos explicar que assim como no Okland Athletics voc no
deve determinar se um desenvolvedor bom ou no e/ou se um software tem
qualidade ou no usando apenas percepo ou senso comum. necessrio a
determinao de um sistema de mtricas e medidas que possam lhe oferecer
uma anlise mais correta e um melhor julgamento.
Se voc ainda no se convenceu da importncia de se medir, vamos aqui ini-
ciar uma outra discusso, uma pouco mais aprofundada, colocando o conceito
de medir e mtricas dentro de um sistema de evoluo contnua aplicada em
algumas outras reas. Para tal, vamos utilizar um ensaio que j escrevi em outro
livro e que cabe perfeitamente aqui.

PERGUNTAS
Responda as questes a seguir:
1. Qual a diferena entre cincias e artes?
2. Qual seleo melhor, a seleo brasileira masculina de vlei ou a de futebol?
3. Por que o Japo conseguiu se reerguer to rapidamente da segunda guerra mundial?

Vamos discutir um pouco as questes acima. Mas importante lembrar que

aqui no h nenhum especialista em artes, esportes ou histria japonesa e a
nossa discusso ser superficial apenas para introduzir a importncia do es-
tudo de mtricas e medidas na engenharia de software e no desenvolvimento
de sistemas.
Vamos comear pela primeira pergunta. Voc consegue pintar quadros
como Leonardo Da Vinci? Provavelmente no, ele era um gnio e dominava a
arte da pintura. Porm, com um bom curso de pintura voc poder pintar bons
quadros. No mesmo?

captulo 1 11
 WIKIMEDIA

O que estamos tentando dizer que a cin-

cia pode desenvolver tcnicas, procedimentos e
processos que serviro de meios (caminhos) para
uma produo artstica, e em contrapartida a arte
pode servir de inspirao para o desenvolvimento
da cincia.
Lgico, que somente com as tcnicas artsticas
desenvolvidas pela cincia, dificilmente iremos
criar vrios Leonardo Da Vinci, pois, como voc
j deve ter estudado, a competncia no depende
apenas do conhecimento, h ainda a atitude e a
habilidade cercando este conceito. Contudo, um
arcabouo de conhecimentos e tcnicas o come-
o para a construo dessa competncia.
Vamos ento transportar este raciocnio para a nossa segunda pergunta.
Mas para discuti-la, vamos fazer outra pergunta: qual a diferena entre a sele-
o brasileira de vlei masculina e a seleo brasileira de futebol masculina?.
Nossos meninos do futebol normalmente so artistas. Sim, artistas! So
artistas do corpo, artistas do espao, artistas da bola. Quero dizer que dificil-
mente um menino se torna jogador de futebol por que treinou exaustivamente
todos os fundamentos quando criana, com tcnicos os observando e com a
aplicao de tcnicas e fundamentos estudados pela cincia esportiva.

O que acontece, como diria Thierry Henry, jogador da seleo francesa de futebol em
2006, ... que os meninos do Brasil jogam futebol das 8:00 as 18:00 e j nascem
com a bola nos ps.... (Terra Esportes, 2006)

O que o jogador francs quis dizer que o jogador brasileiro de futebol j

nasce com um conhecimento tcito, inato, que vem com ele. E isso se reflete na
seleo brasileira.
Na verdade, o que queremos dizer que quase todas as glrias da seleo
brasileira de futebol so conseguidas no s por treinamentos esforados e t-
ticas bem elaboradas, mas tambm, e principalmente, pelo herosmo dos nos-
sos jogadores, o que nos remete a pensar que s conseguiremos alcanar novos
ttulos enquanto conseguirmos gerar jogadores artistas e brilhantes.

12 captulo 1
 J a seleo brasileira de vlei masculina no construda apenas por he-
ris brilhantes que se destacam pelo individualismo, mas sim por um time que
treina exaustivamente cada fundamento, planeja e pratica tticas de jogos e
quando termina um jogo no outro dia esto analisando os erros e apurando
as estatsticas. Ou seja, h todo um processo, procedimento e vrias tcnicas
envolvidas por trs das glrias desta seleo.
Podemos dizer que o padro de vitrias da seleo brasileira de vlei mas-
culina ir se repetir enquanto a aplicao desses procedimentos, processos e
tcnicas de treinamento que antecedem cada jogo persistirem.
Por meio desta anlise podemos considerar que ambas as selees so vi-
toriosas por caminhos diferentes, ou seja, uma muito mais pela arte e a outra
muito mais pela tcnica (cincia).
Para concluirmos esta introduo, vamos discutir a ltima questo propos-
ta. Por que os japoneses conseguiram se reerguer to rapidamente aps o terror
da segunda guerra mundial?
bvio que so vrios os fatores que levaram o Japo a se reerguer to rapi-
damente da segunda guerra mundial, mas gostaramos de dar ateno a um
especial, a implantao nas empresas japonesas, principalmente as empresas
automobilsticas, da tcnica da qualidade total.
Esta tcnica busca atuar principalmente no processo de produo dos bens
e servios para conseguir produtos mais baratos e com maior qualidade, ou
seja, busca melhorar a qualidade do processo para consequentemente conse-
guir uma melhora na qualidade do produto.
De forma resumida, a tcnica de qualidade total um conjunto de metodo-
logias e ferramentas que devem ser aplicadas ao processo produtivo de forma
sistemtica para que este torne-se maduro o suficiente para produzir sempre
produtos de qualidade.
Portanto, podemos pensar que o sucesso das empresas japonesas ps-guerra
pode ser atribudo sistematizao do processo de produo (principalmente) para
que a qualidade do produto pudesse se repetir a cada unidade produzida indepen-
dentemente do herosmo das pessoas que esto produzindo cada unidade dessas.

CURIOSIDADE
Sistematizao e melhoria continua de processo no uma inveno do mundo da computa-
o. Na verdade isto vem acontecendo na indstria desde o sculo passado. Iniciou-se com

captulo 1 13
Ford e sua linha de produo e a primeira fase da administrao cientfica onde tudo era
medido e controlado afim de se conseguir maiores desempenhos e passou pelo Japo com
tcnicas como o Just in Time e a Qualidade Total. Para saber mais sobre isso acesse o link:
http://www.infoescola.com/administracao_/historia-da-qualidade/ ou este http://gqp-
gunit.blogspot.com.br/2009/03/historia-da-qualidade.html. Bons estudos!

Discutimos as trs perguntas feitas no incio deste tpico. Mas temos cer-
teza que voc deve estar pensando: Mas por que eu deveria medir aspectos do
meu desenvolvimento? O que eu ganho com isso? E o que essas perguntas tem
a ver com o gerenciamento de projetos de sistemas e medidas de esforo?.
A resposta simples e vem na forma de uma outra pergunta: como voc quer
desenvolver os softwares na sua empresa ou na empresa que voc trabalha? .
Fazendo uma analogia com a discusso que tivemos at aqui, para desen-
volver um sistema/software ns podemos agir pelo lado da arte, dependendo
nica e exclusivamente da competncia e herosmo dos desenvolvedores e ana-
lista de sistemas e torcer, a cada projeto que for realizado, que tudo d certo e
tambm torcer para que os desenvolvedores que saibam desenvolver bem um
sistema nunca saiam da sua empresa, pois se isto acontecer juntamente com a
sada do seu desenvolvedor tambm sairo os conhecimentos sobre como de-
senvolver softwares na sua empresa.
Ou ento, podemos atuar no processo de desenvolvimento de software de
forma a sistematiz-lo e sempre buscar repetir no projeto de desenvolvimento
presente os sucessos de projetos de desenvolvimento anteriores por meio da
utilizao das melhores prticas, ferramentas e metodologias de desenvolvi-
mento de software e sempre buscar melhorar e amadurecer este processo por
meio de medies, de suas mtricas e comparaes com possibilidades inter-
nas e com benchmarks externos.
Na primeira forma, o projeto de software pode dar certo para alguns proje-
tos, mas dificilmente os sucessos anteriores sero repetidos em projetos pre-
sentes, pois quase sempre no h uma sistematizao que indique o motivo
pelo qual o desenvolvimento anterior deu certo e o que deu errado e deve ser
melhorado, por que no h mtricas e muito menos medidas.
De fato, se me permitem a analogia, a primeira forma se assemelha muito a
seleo brasileira de futebol na qual o processo de se jogar bola pertence aos
jogadores e no CBF e a vitria de um time quase nunca se atribuda pelo

14 captulo 1
trabalho da equipe ou de um processo de treinamento, mas sim ao herosmo
de algumas poucas pessoas. E por incrvel que parea isto est mudando no
futebol brasileiro, times como Corinthians e Santos mantm departamentos
responsveis por definir mtricas e realizar medidas sobre o desempenho dos
jogadores. Mtricas estas que vo desde informaes sobre o potencial e vigor
fsico de cada jogador at sobre o desempenho de cada um nas partidas, indi-
cando os pontos fortes e os pontos que devem ser melhorados que so ento
fortemente treinados.
J na segunda forma de se gerenciar um projeto, a instituio (ou a equipe,
ou a organizao ...) define um processo sistemtico e formalizado por meio do
qual TODOS os desenvolvedores devem desenvolver seus sistemas.
Dessa forma, possvel identificar nos projetos findados o que ocorreu de
errado (por meio de medies das mtricas previamente estabelecidas) para
que consertos no processo de desenvolvimento possam acontecer inibindo que
a falha no se repita. E como TODOS os desenvolvedores utilizam o MESMO
processo, TODOS eles iro usufruir desta melhoria. E a identificao desses
pontos que deram errados e os pontos positivos s so possveis quando dentro
do processo de desenvolvimento tenha sido definido mtricas e durante o de-
senvolvimento dos sistemas as medidas tenham sido realizadas e consolidadas.
Alm do mais, utilizando a segunda forma, o conhecimento de como de-
senvolver fica tambm na instituio se tornando um ativo dela e no somente
um ativo da cabea de cada desenvolvedor.
bvio que um desenvolvedor competente ainda essencial para a boa
execuo desse processo de desenvolvimento. Contudo, o treinamento de de-
senvolvedores fica mais facilitado, uma vez que o formalismo do processo de
desenvolvimento e as mtricas de performance definidas permitem a repro-
duo deste conhecimento com o objetivo de atingir os padres de exceln-
cia desejados.
Mais uma vez, se me permitem a analogia, a segunda forma se assemelha
muito a seleo brasileira de vlei, na qual o processo de se jogar bola perten-
ce equipe e h uma tcnica sistematizada de se treinar jogadores competen-
tes e prepar-los para cada novo jogo de forma a buscar o sucesso conquistado
em partidas passadas.
Para resumir tudo o que foi discutido podemos dizer que a produo de
software/sistema de qualidade pode ser realizada de duas formas: 1) montan-
do uma equipe com mitos/artistas do desenvolvimento de software; 2) ou

captulo 1 15
montando um processo de desenvolvimento de software sistematizado, men-
survel e com melhoria contnua. A primeira opo pode dar certo algumas ve-
zes e dar errada em outras vezes e com certeza ser bastante cara, assim como
por exemplo cara uma seleo de futebol brasileira masculina. A segunda op-
o oferece uma forma de produzir produtos de software de qualidade que au-
mentaro a qualidade a cada projeto entregue, com uma equipe de custo com-
petitivo que pode ser financiada por meio de um oramento modesto.
Na primeira opo no h medidas concretas para dizer se o sistema deu
certo ou no e no h como tentar entender o que est dando errado para se
melhorar em um novo projeto (uma vez que no h mtricas/medidas estabe-
lecidas) a no ser pelo uso de percepes e sentimentos (lembre-se do que voc
leu aqui sobre a nica pessoa que ganhou dinheiro com feelings).
J a segunda opo nos permite entender cada ponto do processo por meio
das mtricas previamente estabelecidas e medidas realizadas durante o desen-
volvimento possibilitando diagnosticar o que deu certo (para repetir no prxi-
mo projeto) e o que precisa ser melhorado para que o time possa reconher os
erros e consert-los para os prximos projetos garantindo um ciclo de melhoria
contnua do processo de desenvolvimento de software.
Hoje o mercado entende que a melhor forma de atuar da segunda manei-
ra, haja visto nosso exemplo sobre como o Japo se reergueu aps na segunda
guerra mundial ou nosso exemplo dos times de futebol brasileiro e baseball
americano que j utilizaram muito da primeira forma de atuao contratando
atletas caros baseando a anlise de desempenho em sentimentos e percep-
es e agora j implementaram o estabelecimento de mtricas e medidas para
analisar suas contrataes e melhorar o seu estilo de jogo.
Portanto o grande objetivo desta disciplina capacitar voc nas tcnicas
de mtricas e medidas de desempenho de software de forma que voc possa
aplica-las no seu desenvolvimento de software para o amadurecimento do seu
processo e a gerao de produtos de alta qualidade.

CONEXO
Quer ler um artigo interessante sobre o uso de mtricas em processos de desenvolvimento
de software? Ento acesse http://www.inf.furb.br/seminco/2005/artigos/130-vf.pdf e leia
o artigo. Boa leitura!

16 captulo 1
1.2 Introduo s mtricas e medidas
Muito j falamos sobre mtricas e medidas, mas voc consegue nos dizer o que
uma mtrica e o que uma medida? Ou ainda, qual a diferena entre uma
e outra?
Provavelmente no! Vamos facilitar: voc consegue nos dar um exemplo de
uma mtrica de software?
Agora sim, ficou mais tranquilo, correto? Voc j deve estar pensando em
algo como custo e ou tempo de desenvolvimento.
isso mesmo, se voc pensou nos exemplos acima ou em algo parecido,
voc acertou. Na verdade, o conceito de mtricas e medidas chega a ser intuiti-
vo e por isso mais fcil para voc dar exemplos do que definir ou classificar.
Contudo, perceba que nos exemplos acima citamos mtricas relacionadas ao
processo de desenvolvimento apenas, mas ainda h a possibilidade de mtricas
relacionadas ao produto tambm, como por exemplo tempo de processamen-
to e quantidade de armazenamento.
Por isso, apesar do conceito ser intuitivo, a definio e classificao das
mtricas e medidas se faz importante para que voc entenda profundamente o
conceito e consiga aplica-lo de forma ampla e completa. Ento vamos l.
Segundo (Pressman, 1995) todas as engenharias realizam medies e isto
de extrema importncia nessas disciplinas e na engenharia de software o con-
texto no diferente e, conforme mostramos no tpico anterior, a necessidade
de se medir se mostra importante tambm. (Pressman, 1995) se justifica utili-
zando o trecho abaixo de Lorde Kelvin:

Quando se pode medir aquilo sobre o qual se est falado e express-lo em nmeros,
sabe-se alguma coisa sobre o mesmo; mas quando no se pode medi-lo, quando no
se pode express-lo em nmeros, o conhecimento que se tem de um tipo inade-
quado e insatisfatrio; este pode ser o comeo do conhecimento, mas dificilmente
algum ter avanado em suas ideias para o estgio de cincia.

Perceba que estamos falando de dois conceitos: mtricas e medies. Eles

so conceitos diferentes mesmo? Se sim, o que um quer dizer e o que o outro
quer dizer?

captulo 1 17
 Vamos comear falando sobre mtricas.
Mtricas, segundo (IEEE - The institute of Electrical and Electronics
Engineers , 1990), a indicao de uma medida quantitativa que medir o
quanto um determinado sistema, componente o processo possui de uma deter-
minada caracterstica. Ou seja, uma mtrica uma definio ou indicao do
que se quer conhecer ou acompanhar sobre um processo, sistema ou compo-
nente. Ento, uma mtrica pode ser considerada um conceito que nos ajuda
a determinar algo que se deseja saber.
A definio acima um tanto quanto formal e talvez at um pouco compli-
cado de se entender, ento, vamos a um exemplo:
Suponha que voc deseja saber qual a altura de um quarto. Isso mesmo,
queremos saber qual a distncia entre o teto e cho. Sem uma mtrica bem
definida que explique o conceito da medida estabelecendo como realizar a me-
dida e o que est includo e o que no est includo pode ficar um pouco com-
plicado realizar a medida e confuses podem acontecer.
Vamos supor que voc d esta tarefa para duas pessoas realizar a mesma
medida, ento, a pessoa A vai at o quarto indicado por voc e realiza e medida
solicitada e traz o valor de 2,40 m enquanto a pessoa B vai posteriormente no
mesmo quarto, com a mesma fita mtrica e traz a medida de 98 in (polegadas).
A vem o primeiro problema: a pessoa A trouxe a medida em metros e a pes-
soa B em polegadas. Caso uma mtrica tivesse sido completamente definida
anteriormente esta confuso no estaria acontecendo, pois, na definio de
uma mtrica, um dos pontos que so cobertos o estabelecimento da unidade
na qual a medida que compem a mtrica dever ser tomada.
Supondo ento que as duas pessoas tivessem entrado em um acordo e de-
finiram que o sistema de medida seria o metro. Ento a pessoa B realizar a
transformao da medida em polegadas para metro e chega no resultado de
2,50 m.
Opa! Outra confuso, a medida tomada pela pessoa A est diferente em
10 cm daquela tomada pela pessoa B. Por que isto pode estar acontecendo.
Solicitando para ambas as pessoas explicarem como procederam para rea-
lizar a medida, temos que a pessoa A realizou a medida do cho at a base da
laje, enquanto a pessoa B realizou a medida considerando do cho at o topo da
laje (ou seja, considerou tambm a espessura da laje). E agora, quem est certo?

18 captulo 1
 Bom, como no temos uma mtrica formal definida, poderamos conside-
rar que as duas pessoas esto corretas, contudo, estas medidas pouco ajuda-
riam um engenheiro civil que sempre estaria em dvida sobre se a pessoa con-
siderou ou no a espessura da laje.
Ento, como resolver este problema?
Na engenharia civil, foi-se definida a mtrica p-direito, que poderamos
descrever formalmente (e com efeito didtico, uma vez que este no um livro
sobre construo civil) da seguinte forma:

NOME DA MTRICA P direito

OBJETIVO DA MTRICA Determinar o vo entre o cho e o teto interior de uma construo
Diferena de cota entre o piso inferior e o piso superior, incluindo a
DESCRIO DA MTRICA espessura da laje superior e desprezando a espessura da laje inferior.
(Engenhariacivil.com, 2015)
Para realizar a medida ser utilizado o sistema mks (metro, quilme-
SISTEMA DE MEDIDAS tros e segundos).
Realizar e medida de uma linha imaginria que cruza o cho e o teto
FORMAS DE SE OBTER A em um ngulo de 90. A medida dever se iniciar no cho e terminar
MEDIDA na parte superior do teto (ou seja, incluindo a espessura da laje)

Tabela 1.1 Especificao de uma mtrica - exemplo didtico.

Perceba que com a descrio da mtrica acima possvel conceitualizar de

forma completa e no dbia aquilo que se deseja medir, ou seja, a mtrica con-
segue indicar exatamente o que se pretende mensurar.
Perceba que a mtrica no a medida em si, mas sim a definio de como a
medida e como ela deve acontecer.
A propsito a tabela 1.1 nos traz um exemplo do que uma boa especifica-
o de mtrica deve conter, ou seja, uma mtrica deve ser especificada com o
seu nome, objetivo, descrio da mtrica, seu sistema de medida e instruo
de como realizar a medida para compor a mtrica. Alias, bom que voc saiba
que uma mtrica no precisa ser composta de apenas uma medida. possvel
termos mtricas que so compostas por mais de uma medida.
Para explicar melhor o que foi dito acima vamos inventar uma mtrica aqui.
Por exemplo, se quisermos estipular uma mtrica que nos mostre o nmero de
erros encontrados em um pedao de software importante definirmos muito
bem a mtrica. Isto por que deve estar bem claro o que pedao de software e
tambm o que erro. Ento, poderamos fazer da seguinte forma:

captulo 1 19
 NOME DA MTRICA Erros em pedao de software
OBJETIVO DA MTRICA Identificar a qualidade do cdigo que est sendo produzido;
um nmero real com uma casa decimal que determina a quantidade
DESCRIO DA MTRICA de erros crticos encontrados por milhares de linha de cdigo.
KLOC = milhares de linha de cdigo (nmero real com uma casa
SISTEMA DE MEDIDAS decimal) e # de erros crticos (nmero de erros crticos nmero
inteiro).
Medida 1 Linhas de cdigo: Realizar a contagem da quantidade de
NOVAS linhas de cdigo geradas no pacote que foi testado e divid
-las por 1000 para gerar KLOCs.
FORMAS DE SE OBTER A Medida 2 Contar a quantidade de novos erros crticos somada a
MEDIDA quantidade de erros crticos antigos que deveriam ter sido conserta-
dos, mas persistiram.
Realizar a razo: medida 2 / medida 1

Tabela 1.2 Exemplo hipottico de uma mtrica que usa duas medidas diferentes na
sua composio.

Veja que na tabela 1.2 a mtrica em questo composta por duas medidas
diferentes que juntas, ao calcularmos a razo entre elas, nos dar a informao
desejada. Isto bastante comum em software.
De tudo o que foi falado, importante voc entender que uma mtrica, ape-
sar de poder ser composta por vrias medidas, deve ser simples de se entender
e de ser aplicada ou ento no passar de algo terico sem valor prtico. Sendo
simples de entender e aplicar ela conseguir mais facilmente atender o seu ob-
jetivo, que subsidiar a melhoria continua de processos de desenvolvimento e
subsidiar processos de tomada de deciso.
Uma boa mtrica tambm deve ser o menos subjetivo possvel. No pode-
mos criar mtricas cujas medidas sejam baseadas em percepo e sentimentos
(lembre-se, feelings s trouxe resultados concretos para o autor da msica).
A seguir mostramos um quadro que resume as caractersticas de uma
boa mtrica.

No crie uma mtrica para depois entender o objetivo dela. Faa

sempre o contrrio, ou seja, entenda a necessidade de se medir,
ATENO AO OBJETIVO DA analise o retorno que a mtrica pode dar e depois crie a mtrica.
MTRICA Uma mtrica que baseada em objetivo previamente estabelecido
tende a ser uma mtrica mais til na prtica.
s vezes, na nsia de se fazer uma mtrica perfeita as pessoas ten-
dem a criar mtricas complicadas de serem entendidas ou de serem
MTRICA COMPLEXA IGUAL aplicadas. O resultado disso uma mtrica que de fato no ser uti-
A MTRICA QUE NO SER lizada na prtica ou por que difcil de se executar ou por que o seu
UTILIZADA custo excede os seus benefcios. Tente sempre pensar em mtricas
que sejam de fato efetivas ao objetivo querido, mas que sejam fceis
de se entender e principalmente fceis de serem aplicadas.

20 captulo 1
 Uma mtrica sempre deve ter seu benefcio maior do que o custo
MTRICA BOA MTRICA de produzi-la e mant-la. Uma mtrica que tem seu custo maior do
BARATA que o valor que ela d de retorno, no aplicvel.
Uma boa mtrica aquela que independente de quem faa a medi-
da, dar sempre o mesmo resultado. Ou seja, a boa mtrica espe-
MTRICA NO PODE DEPENDER cificada de tal forma que suas medidas independem daqueles que
DE JULGAMENTO PESSOAL a faz, totalmente impessoal, objetiva, clara e lgica. Portanto, no
importa se ser o Joo ou o Jos quem far as medidas da mtrica,
se bem especificada e objetiva ela dar os mesmos resultados.

Tabela 1.3 Cuidados para criar uma boa mtrica (Fernandes, 1995)

Ainda em relao tabela 1.3, mais especificamente ao primeiro item cita-

do, (Sommerville, 2011) sugere a aplicao do mtodo GQM (Goal, question,
metrics), ou seja, no momento de se definir uma mtrica, antes defina o objeti-
vo, depois as questes e ai sim as mtricas, sendo que:
Objetvo (Goal): a meta que a organizao est tentando atingir e deve estar
relacionado algo que afetado pelo processo de desenvolvimento de software
e no ao processo de desenvolvimento em si;
Questes (questions): questes relacionadas a reas de incertezas que afe-
tam o objetivo estruturado previamente;
Mtricas (metrics): medidas que devem ser coletadas para responder s
questes acima e acompanhar se as melhorias implantadas esto contemplan-
do as metas especificadas.
Veja que pelo GQM a mtrica s definida depois que o objetivo foi estru-
turado e questes foram elaboradas. Este deve ser o processo de criao de m-
tricas. Para deixar ainda mais claro este processo (Sommerville, 2011) mostra a

Objetivos a serem
Meta 1 Meta 2
alcanados

Questes a serem
Q1 Q2 Q3 Q4 Q5 Q6
feitas

M2 M4 M6 M8 M10
Coisas a serem
medidas
M1 M3 M5 M7 M9

Figura 1.2 GQM para a defino de mtricas, baseado em (Sommerville, 2011)

captulo 1 21
 PERGUNTA
Entendeu o que uma mtrica e como ela deve ser desenvolvida e documentada? Ento tes-
te os seus conhecimentos, junte-se com seus amigos e determine 3 mtricas interessantes
para saber se o seu estudo esta indo bem ou no, ou seja, coloque como meta Passar na
prova e ai desenvolva as questes sobre o seu processo de estudo e depois defina mtricas
para entender se voc esta desempenhando bem o seu processo de estudo. Boa sorte!

Falamos bastante at aqui sobre mtricas, ainda temos mais o que falar so-
bre elas, mas antes vamos conceitualizar o que vem a ser as medidas.
Uma medida uma tomada de valor de algo que se quer avaliar contra
um padro estabelecido (IEEE - The institute of Electrical and Electronics
Engineers , 1990). Para explicar melhor, vamos pensar na medida de um lpis.
Um lpis possui 17,5 cm de comprimento, ou seja, ele possui 17,5 vezes o pa-
dro centmetro.
No entendeu, ento vamos tentar uma definio de (Pressman, Engenharia
de Software, 2006) que diz que uma medida o processo por meio do qual so
associados smbolos ou nmeros atributos de entidades de modo que os de-
terminem conforme com padres bem definidas.
Ou seja, ambas as definies dizem a mesma coisa, que medida uma for-
ma de atribuir um valor a algo utilizando para isso um padro bem definido
(por exemplo centmetros, gramas e etc.)
Para nosso contexto at agora explorado, a medida ser uma tomada de va-
lor de algo contra um determinado padro de acordo com o especificado por
uma mtrica. Ou seja, as mtricas definem as medidas que quando tomadas
comporo o valor da mtrica segundo o que foi especificado por esta ltima.
Simples no?! Pois . E uma medida pode ser de dois tipos: direta e indireta.
Uma medida direta a mais comuns e mais fcil de ser conseguida. So
aqueles que medem diretamente um fenmeno, como por exemplo esta que
usamos no exemplo anterior: a altura de um lpis. Diretamente com uma rgua
consegue-se proceder com a medida e o padro contra o qual a medida ser rea-
lizada tambm j bem conhecido e estvel: o centmetro; o que gera uma me-
dida absoluta e incontestvel. Isto acontece tambm com medidas de massa
(grama), voltagem (volts), velocidade (metros/segundo) ou temperatura (graus
celsius, farenhait e kelvin). Normalmente quando se faz uma medida como est

22 captulo 1
no h discusso sobre a estabilidade e a certeza da medida, como j dissemos,
ela absoluta. Seu padro muito conhecido e esta medida facilmente re-
produzida por qualquer pessoa que utilize um instrumento calibrado com o
padro usa em princpio (por exemplo, uma fita mtrica calibrada em centme-
tros para medir o lpis da mesma forma que a rgua que fez a primeira medida
estava -> o resultado ser o mesmo para ambos os processos de medio).
J as medidas indiretas so aquelas que conseguimos por meio de outras,
como por exemplo medir a qualidade de um software por meio da quantidade
de tempo que ele fica sem travar, ou ainda medir a velocidade de desenvolvi-
mento por meio da quantidade de linhas de cdigo que o desenvolvedor produz
por hora.
Na verdade, so medidas para as quais precisamos de mais de um passo
para realizar e que geralmente no ofertam resultados absolutos como aqueles
das medidas indiretas (ou seja, no ofertam resultados incontestveis). So me-
didas no to refinadas quanto quelas do mundo das cincias fsicas, contudo
elas tambm so feitas baseadas em um conjunto de regras bastante claras.
Nos exemplos dados h dois pargrafos atrs dissemos que poderamos
medir a velocidade de desenvolvimento por meio da quantidade de linhas de
cdigo desenvolvidas por hora. Veja como esta medida indireta pode ser con-
testada, pois as vezes, um bom desenvolvedor, costuma resolve um grande pro-
blema com menos linhas de cdigo do que um desenvolvedor mdio consegui-
ria. Queremos dizer que as vezes um bom desenvolvedor, em uma hora, resolve
dois problemas utilizando mil linhas de cdigo enquanto um desenvolvedor
medocre poderia hipoteticamente resolver meio problema utilizando 1200 li-
nhas de cdigo em uma hora e por esta mtrica indireta o desenvolvedor me-
docre estaria produzindo mais do que o bom desenvolvedor (definitivamente
linhas de cdigo no uma boa maneira de se medir indiretamente a produo
de um desenvolvedor). Veja como esta medida direta contestvel. Ento ser
que deveramos utiliz-las mesmo?
No mundo dos softwares a maioria das medidas que encontraremos so do
tipo indiretas e (Pressman, Engenharia de Software, 2006) faz uma discusso
em seu livro sobre o uso dessas medidas afirmando que h uma classe de pro-
fissionais dentro da engenharia de software que entende que medir aspectos
de software atualmente seria medir o no-mensurvel e que seria interessan-
te que a comunidade de desenvolvimento de sistemas aguardasse que a cincia

captulo 1 23
entendesse melhor o software e os aspectos que deveriam ser medidos antes de
tentar realizar medidas no diretas ou menos absolutas (mais imaturas).
Contudo, o prprio autor afirma que isto um erro por que mesmo sendo
as mtricas de software no absolutas em sua grande maioria, elas ainda so
apoiadas em um conjunto de regras bem definidas que oferecem uma forma
sistemtica de avaliar, por exemplo, produtos de software e outras aspectos do
desenvolvimento possibilitando um entendimento de imediato sobre a situa-
o do software (ou desenvolvimento) ao invs de a posteriori, o que permite
que o engenheiro de software possa tomar aes (apoia a tomada de deciso)
precocemente em relao ao produto e ao desenvolvimento de software.
E esta posio de (Pressman, Engenharia de Software, 2006) que adota-
remos na disciplina e neste livro. Entendemos que s podemos gerenciar o
que medimos e por mais no absoluta ou indireta que uma mtrica possa
ser desde que ela seja baseada em um conjunto de regras claras e possa trazer
apoio tomada de deciso e evoluo do processo de desenvolvimento ser
algo possvel de ser utilizada dentro do desenvolvimento de sistemas.

1.3 Boas prticas para o uso de mtricas

Vamos nos aprofundar mais no uso das mtricas em processo de desenvol-
vimento de sistemas e entender boas prticas (no so regras, mas prticas
adequadas que vem sendo utilizadas pelas comunidades de desenvolvimento
de software).
interessante classificar as mtricas em pblicas e privadas. Esta prtica
busca garantir que as mtricas sejam utilizadas para a evoluo do processo e
pessoas e no para a punio ou exposio. (Pressman, Engenharia de Software,
2006)
Mtricas privadas so aquelas coletadas utilizando base individual, por
exemplo: nmero de linhas de cdigo por desenvolvedor; defeitos por desen-
volvedor; classes por desenvolvedor e outras.
As mtricas privadas devem ser expostas apenas para o indivduo que est
relacionado ela e com o objetivo de se iniciar a evoluo do processo de de-
senvolvimento de software pelo nvel individual (o que uma possibilidade)
propiciando ento ao indivduo em questo um maior entendimento de como

24 captulo 1
ele est colaborando para o processo como um todo e possa melhor trabalhar
para se aperfeioar.
Quando as mtricas privadas so consolidadas e perdem a caracterstica
de expor informaes de um indivduo, ento podemos considera-las pblicas,
por exemplo: quantidade de defeito por mdulo do sistema, quantidade de de-
feitos por milhares de linha de cdigo e outros. Essas mtricas podem ser ex-
postas a todos com o objetivo que a equipe do projeto e a organizao no qual
o projeto est inserido possa melhor entender o que est acontecendo e traba-
lhar para aumentar a maturidade do processo de desenvolvimento de software
a ponto de entregar produtos de software com maior qualidade.
Com o intuito de fornecer parmetros para a criao de mtricas de boa
qualidade, (Pressman, Engenharia de Software, 2006) fornece dicas de como
cria-las:
Nmeros devem ser interpretados com bom senso e sensibilidade empre-
sarial. No utilize as mtricas sem antes entende-las.
Mtricas coletadas, feedback fornecido. Seno, a mtrica cai no desuso e
sua aplicao perde fora.
Mtricas no so para avaliao e sim para evoluo. Use as mtricas para
fornecer a indivduos e organizao um direcionador de desenvolvimento e no
um direcionador de avaliao.
As mtricas devem ser claras e objetivas, e aps a sua definio busque
definir metas a serem alcanadas baseando-se nessas as mtricas.
Medidas de mtricas que indicam possveis problemas no devem ser
vistas de forma negativa e sim como uma oportunidade encontrada de aplicar
melhorias em processos e indivduos.
Uma mtrica sozinha no faz vero. No fique obcecado por uma determi-
nada mtrica enquanto outras no esto sendo utilizadas.

1.4 Por que utilizar mtricas de software

J fizemos uma intensa discusso sobre por que utilizar mtricas no incio des-
te captulo, contudo, interessante fecharmos o assunto e para tal vamos uti-
lizar a citao que (Pressman, Engenharia de Software, 2006) faz em seu livro
sobre as razes de se medir:

captulo 1 25
 Ao se medir possvel entender fenmenos que esto acontecendo em um
ENTENDIMENTO processo, produto, recursos e ambientes.
Ao medir processos, produtos, recursos e ambientes em diferentes momentos
no tempo possvel estabelecer base histrica o que permite ao engenhei-
BASE HISTRICA ro de software comparar desempenho e entender se est havendo uma
evoluo.
As mtricas no utilizadas para entender a execuo em relao ao que foi
ACOMPANHAMENTO planejado.
Com mtricas possvel entender tendncias, prever futuras situaes e
TENDNCIA proceder com planos de ao para ajustar o rumo de projetos e produtos de
software.
Por meio de mtricas se torna mais possvel o entendimento de problemas
MELHORIA CONTNUA e causas razes de forma que um plano de ao de correo pode ser criado
com a inteno de se amadurecer processos e produtos de software.

ATIVIDADES
01. Defina uma mtrica para se medir a velocidade de desenvolvimento de um time, segun-
do a forma ensinada neste captulo.

02. Defina o que so medidas diretas e o que so medidas indiretas.

03. Cite 3 exemplos de medidas diretas.

04. Cite 3 exemplos de medidas indiretas.

05. Estabelea uma discusso sobre a importncia das medidas indiretas para a engenharia
de software.

06. Veja as mtricas abaixo e determine se elas deveriam ser privadas ou pblicas

a)

NOME DA MTRICA Defeitos por indivduo

Identificar a quantidade de defeitos que um individuo da equipe de
OBJETIVO DA MTRICA desenvolvimento de software esta gerando para poder melhorar a
sua atuao dentro do time e do processo.
Estabelecer a quantidade de defeitos identificados por milhares de
DESCRIO DA MTRICA linhas de cdigo desenvolvidas.
KLOC = milhares de linha de cdigo (nmero real com uma casa
SISTEMA DE MEDIDAS decimal) e # de defeitos (nmero de defeitos nmero inteiro).

26 captulo 1

FORMAS DE SE OBTER A MEDIDA
Medida 1 Linhas de cdigo: Realizar a contagem da quantidade
de NOVAS linhas de cdigo geradas no pacote pelo indivduo e
divid-las por 1000 para gerar KLOCs.
Medida 2 Contar a quantidade de novos defeitos somada a
quantidade de erros crticos antigos que deveriam ter sido conser-
tados pelo indivduo, mas persistiram.
Realizar a razo: medida 2 / medida 1.

b)

NOME DA MTRICA Tamanho de funcionalidade

Identificar o tamanho de uma funcionalidade a ser desenvolvida
OBJETIVO DA MTRICA para entender o seu grau de complexidade e posteriormente esti-
mar o tempo para o seu desenvolvimento.
Contagem de quantidade de classes e entidades de dados que
DESCRIO DA MTRICA sero construdas para a funcionalidade.
SISTEMA DE MEDIDAS Nmero inteiro
Medida 1 Estimativa de quantidade de classes.
FORMAS DE SE OBTER A MEDIDA Medida 2 Estimativa de quantidade de entidades de dados.
A mtrica dever ser formada pela soma da medida 1 com a 2.

c)

NOME DA MTRICA Quantidade de linhas de cdigo por indivduo

Determinar a velocidade de desenvolvimento de um determinado
OBJETIVO DA MTRICA individuo do time;
Contagem de milhares de linhas de cdigo que o indivduo desen-
DESCRIO DA MTRICA volve por semana.
SISTEMA DE MEDIDAS KLOC = milhares de linha de cdigo (nmero real com uma casa decimal)
A cada semana contar a quantidade de linhas de cdigo novas e
FORMAS DE SE OBTER A MEDIDA alteradas que um determinado indivduo do time deposita no reposi-
trio de cdigo do sistema em questo

d)

NOME DA MTRICA Quantidade de classes por requisitos

Identificar a complexidade mdia de um requisito por sua quantida-
OBJETIVO DA MTRICA de de classes;
Nmero que indica a quantidade de classes que foi desenvolvida
DESCRIO DA MTRICA para atender a um determinado requisito.
SISTEMA DE MEDIDAS Nmero inteiro
Contar a quantidade de classe desenvolvida ou alterada para se
FORMAS DE SE OBTER A MEDIDA performar um determinado requisito documentado no documento
de requisitos do projeto.

captulo 1 27
07. Analise as mtricas abaixo e diga se sua medida conseguida de forma direta ou indi-
reta? Por que?

NOME DA MTRICA Facilidade de uso do sistema

OBJETIVO DA MTRICA Determinar se um produto de software fcil de usar ou no.
Entender o tempo mdio que um usurio leva para executar qual-
DESCRIO DA MTRICA quer atividade do sistema.
SISTEMA DE MEDIDAS Nmero inteiro em segundos
Solicitar trs atividades aleatrias no sistema para trs usurios di-
ferentes e calcular o tempo de cada uma das execues, soma-los
FORMAS DE SE OBTER A MEDIDA e depois dividir por 9. Caso a mdia de maior do que 90 segundos,
ento o sistema no tem uma boa usabilidade, caso contrrio ele
tem uma boa usabilidade.

NOME DA MTRICA Quantidade de classes por requisitos

Identificar a complexidade mdia de um requisito por sua quantida-
OBJETIVO DA MTRICA de de classes;
Nmero que indica a quantidade de classes que foi desenvolvida
DESCRIO DA MTRICA para atender a um determinado requisito.
SISTEMA DE MEDIDAS Nmero inteiro
Contar a quantidade de classe desenvolvida ou alterada para se
FORMAS DE SE OBTER A MEDIDA performar um determinado requisito documentado no documento
de requisitos do projeto.

NOME DA MTRICA Quantidade de linhas de cdigo por classe

OBJETIVO DA MTRICA Determinar o tamanho de uma classe;
DESCRIO DA MTRICA Contagem de milhares de linhas de cdigo que uma classe possui.
KLOC = milhares de linha de cdigo (nmero real com uma casa
SISTEMA DE MEDIDAS decimal) da classe
A cada classe contar a quantidade de linha de cdigo que ela
FORMAS DE SE OBTER A MEDIDA possui.

REFLEXO
Parabns, voc conseguiu chegar at o final do nosso primeiro captulo. Aqui voc j deve
estar sabendo o que uma mtrica e a importncia dela para o processo de desenvolvimento
de software e para o produto de software.
Tambm j deve estar sabendo o que uma medida e a diferena existente entre medida
e mtrica. Alm disso, voc j deve estar craque em identificar e descrever mtricas. E no
estamos falando de descrever uma mtrica de qualquer jeito no, mas sim descrever uma
mtrica utilizando o mtodo GQM, baseando a mtrica em seu objetivo e descrevendo-a
baseada no template que foi oferecido neste captulo.

28 captulo 1
 Gostaramos de recuperar aqui uma discusso que foi realizada anteriormente neste
captulo sobre a importncia de se medir software e processo de software mesmo que a
medida seja indireta e no absoluta. Voc entendeu bem esta parte? Por que ela o ponto
forte do entendimento da necessidade das mtricas na engenharia de software.
importante que voc entenda que apesar da grande maioria das mtricas que utili-
zaremos na engenharia de software ser mtricas no absolutas e indiretas, o processo de
mensurao realmente muito importante para que o engenheiro de software possa melhor
se guiar na rdua misso de estabelecer um processo de desenvolvimento de qualidade, ma-
duro e que evolua constantemente com o objetivo de gerar produtos de software que sejam
de qualidade e que de fato agreguem valor ao usurio final.
Portanto, deste ponto em diante, queremos dizer, nos prximos captulos, o que faremos
entender quais tipos de mtricas podem existir na engenharia de software de uma forma
geral, apresentar as mtricas de medidas de esforo de desenvolvimento de software, que
so o objetivo desta disciplina e nos aprofundarmos nesta tcnica, tanto no entendimento
das mesmas quanto em como aplica-las no processo de desenvolvimento de software.
J bom adiantar que a grande maioria dessas mtricas de esforo de desenvolvimento
de software so indiretas e no absolutas e que por muitos momentos iremos nos perguntar:
esta medida realmente exata?;Vale a pena a mensurao de algo que no conseguimos
garantir valores absolutos?. Toda vez que esta dvida atentar os nossos estudos pediremos
a voc que volte neste captulo 1 e refaa a leitura das discusses que tivemos e volte a
entender que s podemos gerenciar aquilo que medimos e se queremos de alguma forma
gerenciar o desenvolvimento de software, ento, bom que passemos a medi-lo, e se esta
a forma que conhecemos hoje, ento ser ela que utilizaremos.

LEITURA
Uma leitura bastante interessante que fala sobre como utilizar indicadores para realizar a
gesto (no necessariamente de software) O Verdadeiro Poder do autor Vicente Falconi,
2 Edio. Recomendamos esta leitura para os alunos que querem entender qual o propsito
de se realizar medidas e estimativas no mundo corporativo. Boa leitura.

captulo 1 29
 REFERNCIAS BIBLIOGRFICAS
Engenhariacivil.com. (22 de 08 de 2015). P Direito. Acesso em 22 de 08 de 2015, disponvel em
EngenhariaCivil.Com: http://www.engenhariacivil.com/dicionario/pe-direito
Fernandes, A. A. (1995). Gerncia de software atravs de mtricas: garantindo aqualidade do
projeto, processo e produto. So Paulo: Atlas.
IEEE - The institute of Electrical and Electronics Engineers . (1990). IEEE Standart Glossary of
Software Engineering Terminology. New York: IEEE.
Lobo, G. (2013). spinballnet. Acesso em 15 de 07 de 2015, disponvel em spinballnet: http://www.
spinballnet.com.br/2013/01/os-10-jogadores-mais-baixos-da-nba-que.html
Pressman, R. (1995). Engenharia de Software. Sao Paulo: Pearson Makron Books.
Pressman, R. (2006). Engenharia de Software. So Paulo: McGraw-Hill.
Sommerville, I. (2011). Engenharia de Software. So Paulo: Pearson.
Terra Esportes. (29 de 06 de 2006). Selees. Acesso em 19 de 08 de 2015, disponvel em Terra
Esportes: http://esportes.terra.com.br/futebol/copa2006/selecoes/interna/0,,OI1056503-EI5720,00.html
Wikipedia. (2011). Wikipedia - Muggsy Bogues. Acesso em 15 de 07 de 2015, disponvel em
Wikipedia: https://pt.wikipedia.org/wiki/Muggsy_Bogues
Wikipedia. (s.d.). Wikipedia - Manute_Bol. Acesso em 15 de 07 de 2015, disponvel em Wikipedia:
https://pt.wikipedia.org/wiki/Manute_Bol

30 captulo 1
 2
Determinao de
Ponto por Funo
Ol, seja bem vindo a mais um captulo do nosso livro e parabns por ter ini-
ciado novamente os estudos da disciplina, temos certeza de que o que temos
para falar para voc agora ser bastante interessante, principalmente na sua
carreira profissional.
Este captulo tratar de uma tcnica bastante interessante para se estimar o ta-
manho/complexidade de um software: pontos de funo.
Por meio desta tcnica voc ser capaz de determinar, de forma indireta,
qual o tamanho de um determinado software antes mesmo de terminar a co-
dificao dele, o que bastante importante para realizar as estimativas de tem-
po e custo de desenvolvimento de sistemas.

OBJETIVOS
Este captulo possui por objetivo:
Transmitir para o aluno uma taxonomia de medidas e mtricas de software e dar nfase
a alguns grupos de mtrica que so essenciais para a estimativa de esforo de desenvolvi-
mento de software;
Discutir as diferenas entre mtricas diretas de medida de tamanho de software e outras
mtricas que tambm podem servir para medir de forma indireta o tamanho do software;
Mostrar ao aluno uma mtrica funcional de software que mede de forma indireta o tama-
nho do software: a anlise de pontos de funo;
Treinar o aluno no processo de realizao das medidas que compem a anlise de pontos
de funo.

32 captulo 2
2.1 Categorizao de mtricas na
engenharia de software e mtricas no ciclo
de vida do software.
No captulo passado falamos muito sobre mtricas e medidas e a importncia
delas no desenvolvimento de software e na engenharia de software. Mas voc
j parou para pensar sobre quais mtricas so possveis dentro da engenharia
de software?
Lgico que deve haver possibilidades infinitas, mas dentro do ciclo de vida
de um software, considerando que este vai da concepo, desenvolvimento e
produo/uso, h vrios autores da literatura de engenharia de software que
busca categorizar os tipos de mtricas possveis. Vamos aqui explicar a catego-
rizao sugerida por (Pressman, Engenharia de Software, 2006).
Para iniciar a nossa explicao, vamos nos atentar ao desenho abaixo:

Gesto de projeto de software

Processo de desenvolvimento de software

e outras atividades guarda chuva

Engenharia de
requisitos Software em produo-
>Produto de Software

Projeto de
software

Implementao

Testes

Manuteno

Tabela 2.1 Ciclo de vida sugerido de um software

captulo 2 33
 Pela figura 2.1 possvel entender uma diviso no ciclo de vida de software
de 3 partes:

onde todo o planejamento, gerenciamento da execuo e monitoramen-

GESTO DE PROJETOS DE to e controle do software realizada. Atividades de cunho ttico que
SOFTWARE envolvem por exemplo estimativas de tempo, custo, planejamento de RH,
comunicaes e outros.
so as fases pelas quais o software passa para a sua construo. A ins-
tncia desse processo contm as atividades que de execuo do projeto
de software e que de fato criaro o escopo e o produto de software. Por-
PROCESSO DE DESENVOL- tanto, so atividades de cunho operacional do software. Como vimos no
VIMENTO DE SOFTWARE captulo passado, um bom processo de software (maduro e com qualidade
cumprimento das normas de desenvolvimento explicitamente documen-
tadas) tende a gerar produtos de software de qualidade.
o software pronto, o qual deseja-se qualidade, ou seja, para o qual es-
pera-se que cumpra os requisitos funcionais e de desempenho que foram
PRODUTO DE SOFTWARE declarados no planejamento do projeto juntamente com as caractersticas
implcitas esperadas.

Uma vez entendido o ciclo de vida de desenvolvimento de software expli-

cado fica mais fcil entender a categorizao de mtricas. De fato, (Pressman,
Engenharia de Software, 2006) sugere a categorizao das mtricas nas mes-
mas componentes que utilizamos para explicar o processo de desenvolvimen-
to de software, ou seja: mtricas de produto de software, mtricas de processo
de software e aperfeioamento do processo de software e mtricas de projeto
de software.
Para entender melhor cada uma dessas categorias de mtricas vamos expli-
car uma a uma.

I. Mtricas de produtos para software.

Segundo uma taxonomia de (Pressman, Engenharia de Software, 2006) para

mtricas de produtos de software essas poderiam se dividir em:

so mtricas que podem ser aplicadas no modelo de anlise dos sistemas,

MTRICAS PARA O antes mesmo da codificao e implementao. Estas mtricas incluem: Fun-
MODELO DE ANLISE cionalidades entregue; Tamanho do sistema; Qualidade da especificao.
so mtricas que objetivam oferecer ao engenheiro de software uma forma
MTRICAS PARA O de avaliar a qualidade do design (projeto) do software. Essas mtricas
MODELO DE PROJETO incluem: Mtrica arquitetural; mtrica no nvel de componente; Mtricas de
projeto de interface; Mtricas especializadas em projeto OO.
so mtricas que buscam avaliar a qualidade do cdigo fonte no que diz
MTRICAS PARA O respeito sua complexidade, sua facilidade de se dar manuteno, a sua
CDIGO FONTE facilidade de se testar entre outros. Incluem: Mtricas de Haltstead; mtricas
de complexidade; mtricas de comprimento

34 captulo 2
 utilizadas para apoiar o design dos casos de testes avaliando o poder dos
testes que foram criados. Incluem: mtricas de cobertura de comando e
MTRICAS DE TESTE desvio; mtricas relacionadas a defeito. Mtricas de efetividade de testes.
Mtricas em processo.

II. Mtricas de processo de software e de aperfeioamento de

processo de software.

Para se gerenciar um processo profissional de desenvolvimento de software

necessrio realizar medidas sobre ele afim de entende-lo e assim evolu-lo. Tc-
nicas de melhoria contnua de processos como PDCA e IDEAL so baseados em
medidas que buscam evoluir o processo entendendo os gaps e causas razes
e depois acompanhando as novas medidas das mtricas para entender se a evo-
luo foi positiva e pode ser implantada em toda a empresa.

CURIOSIDADE
PDCA
um mtodo de gesto de processos composto por 4 passos (plan, do, check, act) que
acontecem de forma interativa que deve ser utilizado principalmente para atividades de ges-
to de melhoria contnua de processos e produtos.
Este mtodo foi estudado por Dr. W Eduards Deming e foi revolucionrio principalmente
na poca ps guerra na indstria automobilstica principalmente em pases como Japo e
EUA. Atualmente a filosofia do PDCA (que baseado no mtodo cientfico) utilizado em
outros programas de qualidade como o Six Sigma. (Wikipedia, 2015).
Caso queira saber um pouco mais sobre assunto, v at este link e leia um artigo interessan-
te. http://www.portal-administracao.com/2014/08/ciclo-pdca-conceito-e-aplicacao.html

Exemplos de mtricas que podem ser utilizadas para a evoluo do proces-

so de desenvolvimento de software so: medidas dos erros descobertos antes
da entrega do software; defeitos entregues aos usurios finais; produtividade
e outros.

captulo 2 35
 CURIOSIDADE
Modelo IDEAL
Ainda falando sobre modelos de melhoria contnua de processo surge o IDEAL que um
modelo de melhoramento organizacional, criado pela SEI (Software Engineering Institute) ba-
seado em 5 passos iterativos, a saber: Initiating, Learning, Acting, Establishing e Diagnosing.
Muito parecido com o PDCA, mas criado por um rgo diretamente ligado s prticas de
engenharia de software, o IDEAL tem objetivo principal guiar organizaes no planejamento
e na implementao de um efetivo programa de melhoramento de processo de software.
(Silva, 2015)
Para saber mais sobre o IDEAL acesse: http://www.cin.ufpe.br/~rls/ideal/ ou https://
resources.sei.cmu.edu/asset_files/handbook/1996_002_001_16433.pdf

III. Mtricas de projeto de software.

So mtricas tticas que ajudam o gerente de projetos do desenvolvimento do

sistema a: planejar (principalmente no que tange s estimativas de tempo, cus-
to, RH e outros), monitorar (entender se o progresso esta de acordo com o pla-
nejado), controlar (realizar as mudanas necessrias para trazer a execuo o
mais prxima possvel do planejado).
Alm das necessidades acima, o gerente de projeto tambm precisa enten-
der a produtividade do time depois que o projeto inicia-se, o que tambm pode
ser apoiado por mtricas de projeto de software.
Por fim, o gerente de projetos pode utilizar mtricas de qualidade de pro-
cesso e projeto para entender se o time est desenvolvendo dentro do que foi
inicialmente estipulado e tambm se o produto est ficando com a qualida-
de esperada.
Alm da classificao acima citada, as mtricas ainda podem ser classifica-
das em:

MTRICA ORIENTADA A TAMANHO

So mtricas diretas que buscam entender qual o tamanho do software. A ideia aqui envolvida
entender o tamanho do software para poder relacionar outras mtricas e traar um histrico da
efetividade do processo e pontos de melhorias que poderiam ser encontrados e consertados. Por
exemplo, veja a tabela a seguir:

36 captulo 2
 PROJETO KLOC HORAS/HOMENS CUSTO ERROS PESSOAS
1 10 20000 200000 120 3
2 30 62000 350000 180 5
3 25 60000 300000 150 4
4 37 80000 380000 200 7
5 80 155000 850000 250 10

Tabela 2.2 Mtricas orientadas a tamanha baseadas em (Pressman, Engenharia de

Software, 2006)

Os projetos, aps finalizados, foram medidas de acordo com vrias mtricas

orientadas a tamanho que so normalizadas por uma das mais famosas tcni-
cas orientadas a tamanho que a mtrica linhas de cdico (LOC) ou milhares
de linhas de cdigo (KLOC). Veja que saber apenas a quantidade de horas ho-
mens utilizada no projeto, o custo do projeto ou ainda a quantidade de erros
no faz sentido se no possuirmos uma base de comparao, ou seja, algo para
normalizar o nmero. Ento, houve uma poca que esta base de comparao
foi a mtrica de tamanho de software chamada KLOC no qual considerava-se
o tamanho de um software de acordo com a quantidade de linhas que ele pos-
sua, desta maneira, as demais mtricas seriam calculadas em funo do KLOC,
ou seja, Horas/homens utilizadas no projeto por KLOC, custo do projeto por
KLOC, erros no software por KLOC entre outros.
A inteno era poder fazer uma base histrica de projetos e entender se o
processo utilizado na construo dos sistemas estava propiciando, com o pas-
sar do tempo, um produto de software com menos erros por linha de cdigo, ou
um custo menor por linha de cdigo ou ainda menos horas/homem por linha
de cdigo.
Com uma base de comparao como esta poderiam ser feitos inclusive ben-
chmark com outras empresas para entender a produtividade de uma determi-
nada organizao comparada a um concorrente ou a uma empresa parceira que
tambm desenvolve softwares, porm para mercados diferentes.
Em princpio, a ideia de normalizar as mtricas por linhas de cdigo parecia
bastante interessante porque:
I. todo software possui linha de cdigo;
II. um artefato que se pode contar com extrema facilidade (alm da con-
tagem poder ser facilmente automatizada junto s ferramentas de controle de
verso por exemplo);
III. e j possui vasta literatura e base histrica registrada a respeito.

captulo 2 37
 Contudo, muitas controvrsias surgiram em relao a este uso uma vez que
se a linguagem de programao for alterada, a quantidade de linhas de cdigo
tambm pode ser afetada dando a impresso que um software que feito em
C possa ser menor do que o mesmo feito em JAVA, por exemplo (o que pode-
ria ser resolvido com fatores de ajuste), e principalmente por que este tipo de
medida acaba punindo softwares bem projetados e bem desenvolvidos, uma
vez que softwares que so bem projetados e bem desenvolvidos normalmen-
te apresentam uma quantidade menor de linhas de cdigo dando a impresso
que so menores, quando na verdade possuem o mesmo tamanho em requisi-
tos e complexidade do que o mesmo software quando desenvolvido de forma
mal projetada. Por isso, este tipo de medida no caiu nas graas da comunidade
de desenvolvimento de software e at hoje no utilizado em larga escala.

MTRICA ORIENTADA A FUNO

Com a grande discusso que se deu em relao medida de linha de cdigo LOC, a comunidade
buscou outras formas de entender o tamanho de software e iniciou estudos de tcnicas e medidas
que pudessem compor uma mtrica que mostrasse o tamanho do software de acordo com as suas
funcionalidades entregues, ou seja, ao invs de entender o tamanho do cdigo por meio da quanti-
dade de linhas de cdigo implementadas para a sua confeco agora iramos entender o tamanho
do software por meio de uma medida indireta que fosse relacionada com a quantidade de funes
entregues por este software.

Em 1979 (Albrecht, 1979) props ento uma mtrica que busca medir o ta-
manho do software indiretamente por meio da sua complexidade que seria ba-
seada nas funes que ele oferece. A mtrica proposta foi o Pontos por Funo
(function points FP) e pode ser considerada uma mtrica no domnio da anli-
se, uma vez que no necessrio ter o cdigo pronto para a realizao das medi-
das, o que tornou-se uma grande vantagem para o uso desta mtrica, j que por
meio de uma medida feita na fase de anlise do ciclo de vida do software (que
uma das fases iniciais do software) j possvel realizar estimativas, basean-
do-se em base histrica, da quantidade de linhas de cdigo que espera-se para
o software, do custo e tempo de desenvolvimento, da quantidade de erros es-
peradas e outros. (Pressman, Engenharia de Software, 2006) (Pressman, 1995).
Desta forma, essa mtrica foi bem aceita pela comunidade e profissionais
de engenharia de software incluindo o seu uso como medida de normalizao
de outras mtricas como tempo de desenvolvimento, defeitos, produtividade
e outros.

38 captulo 2
 Falaremos detalhadamente mais adiante sobre esta mtrica uma vez que
temos um interesse particular no potencial que ela possui em estimar esforo
de desenvolvimento de software.

Entenda a diferena entre mtrica e estimativa

Como j estudamos, uma mtrica pode ser entendida como um conjunto de medidas
diretas e/ou indiretas que se aplica em algo segundo um procedimento utilizando pa-
dro e sistemas para a medida. Portanto, entende-se que uma medida deva acontecer
em algo que j exista.
J uma estimativa uma previso que se faz sobre algo futuro baseando-se, principal-
mente, em bases de medidas histricas.
Existem algumas tcnicas generalistas de projeto para se realizar estimativas, uma
das mais utilizadas a tcnica paramtrica, na qual utiliza-se uma base histrica de
informaes paramtricas normalizadas para se calcular a estimativa em questo.
Por exemplo, um pedreiro sabe que no passado ele possui a performance de instalar
1 metro quadro de piso por hora (base histrica normalizada por hora), se agora ele
precisa instalar 10 metros quadrados a estimativa que se faz (utilizando uma param-
trica proporcional a mais comum) de que ele demorar 10 horas para instalar. Isto
tambm extensvel para a estimativa de custo, sendo que se ele cobrar R$ 100,00
por metro quadrado ento o total ser de R$ 1000,00.

MTRICA ORIENTADA A CASOS DE USO

A possibilidade de se conseguir mtricas em fases iniciais do processo que sirvam para indiretamen-
te entender o tamanho do software e extrapolar estimativas de prazo e tempo de forma precoce se
mostrou bastante interessante para os engenheiros de software que precisam planejar com a maior
qualidade possvel o projeto antes que a execuo se iniciasse ou tomasse corpo.

Com o advento da orientao a objetos e o uso da UML, mais especifica-

mente casos de uso, para modelar sistemas e seus requisitos os engenheiros
de softwares buscaram construir mtricas indiretas para medir o tamanho do
software baseado nas suas funes que pudessem ser calculadas utilizando es-
ses casos de uso como artefato principal, uma vez que os casos de uso tambm
mostram a entrega de funes que o software conter.
Ento, em 1993 (Kerner, 1993) publicou um artigo no qual demonstrava
uma mtrica chamada Pontos de Caso de Uso (Use Case Points) que utiliza
a contagem de casos de uso, atores e transaes em um mtodo baseado na

captulo 2 39
mtrica de pontos por funo para a determinao do tamanho do esforo para
o desenvolvimento do sistema sendo que este nmero pode ser utilizado como
base para estimar o nmero de homens hora, o nmero de LOC e outros.
Assim como os pontos por funo mencionado anteriormente, os pontos
de caso de uso uma tcnica que desperta particularmente o nosso interesse
pelos mesmos motivos e por isso ser profundamente explorada mais adiante.

MTRICA ORIENTADA A OBJETOS

So mtricas criadas para ambientes e sistemas orientados a objeto no qual o grande propsito aqui
colecionar essas mtricas juntamente com mtricas de esforo, custo e erros (por exemplo) crian-
do uma base histrica relacionada (mtrica orientada a objeto vs esfoo; ou ainda mtrica orientada
a objeto vs custo; ou ento mtricas orientada a objeto vs erros) que possa ser utilizada no futuro
para a estimativa de tempo e prazo. Segue a seguir algumas mtricas orientadas a objetos possveis
citadas por (Pressman, 2006).

considera-se script de cenrio algo parecido com o caso de uso sendo

NMERO DE SCRIPTS DE uma sequncia de passos que so seguidos durante a interao entre
CENRIO o usurio e o sistema em questo. Esta mtrica diretamente propor-
cional ao tamanho do software e a quantidade de cenrios de testes.
so classes centrais relacionadas ao domnio do problema do sistema
NMERO DE CLASSES-CHAVE e normalmente sua quantidade proporcional ao esforo de desenvol-
vimento requerido.
so as classes do sistema que no so diretamente relacionadas ao
NMERO DE CLASSES DE domnio do sistema para precisam ser implementadas para dar vida ao
APOIO sistema e tambm so um indicativo do esforo que ser necessrio
para o desenvolvimento do sistema.
a ideia colecionar durante vrios projetos qual a relao mdia
entre classes de apoio e classes-chaves para que em projetos futuros
NMERO DE CLASSES DE possa-se estimar o nmero de classes de apoio baseado em uma pa-
APOIO POR CLASSES-CHAVE ramtrica entre classe-chave e mdia de nmero de classes de apoio
por classes-chave colecionado. Isto por que as classes-chave no proje-
to so conhecidas logo no incio ao contrrio das classes de apoio.

Para exemplificar imagine que uma empresa trabalhe desenvolvendo soft-

ware para comrcio eletrnico e durante 5 anos vem medindo em seus soft-
wares a relao entre a quantidade de classes de apoio e a quantidade de clas-
ses-chave e chegou ao nmero de 5 classes de apoio para cada classe chave.
Atualmente esta mesma empresa est desenvolvendo um novo software e no
seu diagrama de classe na anlise identifica 20 classes-chave. Por meio de uma
extrapolao possvel estimarmos que a empresa ter neste software cerca de
100 classes de apoio.
Imagine que esta mesma empresa tambm tenha colecionado durante os
5 anos medidas de esforo de desenvolvimento (tempo) para uma classe-chave

40 captulo 2
e para uma classe de apoio e atualmente tem a mdia desses nmeros em 10
homens/hora para uma classe-chave e 8 horas/homem uma classe de apoio.
Utilizando um clculo paramtrico proporcional uma estimativa de horas/ho-
mem para este desenvolvimento seria a seguinte:

Esforo = Qtdd classes-chave * 10 + Qtdd classes de apoio * 8

Esforo = 20 * 10 + 100 * 8 = 1000 horas/homem

a contagem de subsistemas (dividir o sistema em grandes funes que

sero implementados por um conjunto especfico de classes). Uma vez
NMERO DE SUBSISTEMAS que os subsistemas foram determinados mais fcil estimar para cada um
desses subsistemas do que para o sistema como um todo.

MTRICA DE PROJETO DE ENGENHARIA DA WEB

Assim como um ambiente de software orientado a objetos pode ter um conjunto de mtricas espe-
cficas para o contexto de processo e desenvolvimento orientado a objetos, um software;projeto de
engenharia de software para WEB tambm pode ter mtricas especficas para ele. So algumas das
mtricas possveis segundo (Pressman, 2006):

o Nmero de pginas estticas da Web;

o Nmero de pginas dinmicas da Web;
o Nmero de links internos da pgina;
o Nmero de objetos de dados persistentes;
o Nmero de sistemas externos interfaceados;
o Nmero de objetos de contedo estticos;
o Nmero de objetos de contedo dinmico;
o Nmero de funes executveis;

Acima voc teve um profundo estudo sobre os tipos de mtricas segun-

do uma taxonomia proposta por Pressman e para cada um dos tipos foi dado
exemplos de mtrica e de suas aplicaes.
Entendemos ento que voc est craque no que tange mtricas e tambm
sabe a diferena entre mtrica e estimativa. Partindo deste princpio voc j
deve ter entendido que para eu fazer uma estimativa de esforo (ou custo) de
desenvolvimento de software muito importante que se saiba qual o tama-
nho do software.
Voc se lembra qual mtrica anteriormente estudada fala sobre tamanho
de software?

captulo 2 41
 Muito bom! Voc acertou, a mtrica de Linhas de Cdigo - LOC (ou milha-
res de linha de cdigo KLOC). Esta uma mtrica que por meio de uma medida
direta simples de contagem de linhas de cdigo do sistema nos d o tamanho
do software.
Contudo, conforme j discutimos anteriormente, ela no resolve o proble-
ma de se estimar o tempo de desenvolvimento do software por que para contar
linhas de cdigo o software j deve estar pronto e quando queremos estimar o
esforo justamente antes de iniciar o desenvolvimento do software, ou seja,
antes de saber qual o nmero de linhas de cdigo do software.
Portanto, necessrio utilizar outras mtricas de tamanho de software que
nos d um nmero em momentos iniciais do desenvolvimento de software de
forma a permitir o clculo de estimativas de esforo e custo de desenvolvimen-
to. Voc teria alguma sugesto?
O que acha dos pontos por funo ou dos pontos de caso de uso?
(Martins, 2007) comenta que embora o valor de ambas as mtricas represen-
te a complexidade associada ao software (e no diretamente o seu tamanho),
com base nesse valor possvel calcular vrios indiretamente vrias outras m-
tricas, incluindo mtrica de tamanho do software, j que se pode transformar
esse valor em linhas de cdigo, por exemplo. Por isso podemos dizer que tanto
Pontos por Funo como Pontos de Casos de Uso podem ser consideradas m-
tricas para determinar o tamanho do software.
Considerar ento estas mtricas de complexidade/funo como sendo m-
tricas de tamanho a opo de diversos outros autores, como por exemplo,
(Andrade, 2004) que afirma existir vrias mtricas de estimativa de tamanho
de software sendo que a maioria desenvolvida com base nas funes do soft-
ware como: Anlise de Pontos de Funo, Bang, Feature Points, Boeings ED
Function Points, Mark II, Pontos de Caso de Uso e COSMIC Full Function Point.
(Anda, 2001) (Fetcke. T., 1998) (Smith, 1999).
Ento, nesta disciplina, consideraremos essas duas mtricas, pontos por
funo e pontos de caso de uso, como medidas de tamanho de software que
apoiaro estimativas de esforo e custo.
Desta forma, dando continuidade neste captulo iremos nos aprofundar na
tcnica de medio dos pontos por funo e no prximo captulo estudaremos
um estudo de caso sobre pontos por funo e nos aprofundaremos nas tcnicas
sobre pontos de caso de uso para ento, no captulo subsequente estudarmos
como podemos realizar estimativas baseados nessas duas mtricas.

42 captulo 2
2.2 Determinao de pontos por funo.
Segundo (Martins, 2007) em seu trabalho de dissertao, a mtrica Anlise
de Pontos por Funo caracteriza a complexidade da funcionalidade do soft-
ware a ser desenvolvido, o que de forma indireta nos aponta o tamanho do
software em questo, tendo como base itens que esto presentes nos produtos
de software, como arquivos, transaes de entrada, de sada, etc. e algumas
perguntas que procuram caracterizar outros aspectos que no esto atribu-
dos diretamente funcionalidade do produto, porm que podem interferir na
complexidade de desenvolvimento do produto, como por exemplo exigncia
de disponibilidade de recursos computacionais, processamento de dados dis-
tribudo, entre outros.

CURIOSIDADE
Quem usa pontos de funo no Brasil?
No Brasil pode-se citar empresas como Accenture, Bradesco, Vale, Caixa, Correios,
CPMBraxis, Datamec, Totvs, DBA, EDS, IBM, Petrobras, Politec, OI, Unisys, Xerox, dentre
outras.
O IFPUG possui filiados de mais de 40 pases; sendo que o uso da APF mais in-
tenso na Alemanha, Austrlia, Brasil, Canad, Coria, Estados Unidos, ndia, Inglaterra,
Itlia e Holanda. Exemplos de outras empresas no mundo que usam a APF: IBM, Unisys,
Xerox, EDS, Citigroup, Tata, Lockheed Martin-EIS, Booz Allen & Hamilton, Nielsen Media
Research, Bank of Canada, Ralston Purina Co., Northrop Grumman Corp, Samsung SDS
Co Ltd, BASF Corporation, Accenture, Pepsi Co, Compuware, Pricewaterhouse Cooper.
(Fatto, 2015)

O processo de medio da mtrica de Anlise de Pontos por Funo, divi-

dido em 3 passos sendo que o ltimo deve ser subdivido em 5 etapas, conforme
mostra a figura a seguir.

captulo 2 43
 Contar
funes do
tipo dados Determinar
contagem
Identicar de PF no
escopo da ajustados Calcular
Determinar contagem Contar
pontos por
o tipo de e as funes do
funo
contagem fronteiras tipo transao
ajustados
da
aplicao Determinar
fator de
ajuste

Figura 2.3 processo de contagem de pontos por funo (Vazques, Simes, & Albert, 2005)

Vamos na sequencia entender cada um desses passos e desta forma en-

tender o processo de contagem como um todo segundo (IFPUG International
Function Point Users Group, 1999) e (Vazques, Simes, & Albert, 2005).
I. Determinar o tipo de contagem A APF pode ser aplicada para calcular
3 tipos de contagem, a saber:
a. Projetos de desenvolvimento: so projetos de software que ainda
no esto em uso, ou seja, software novinho em folha, ou seja, na sua
primeira instalao e pode abranger inclusive as eventuais necessidades
de migrao de dados entre o sistema legado e o novo sistema que esta
sendo instalado.
b. Projeto de melhoria: so para projetos que melhoram um software
j existente e serve para medir os pontos das funes que esto sendo
adicionadas, modificadas e/ou excludas.
c. Aplicao: a medida de APF de baseline, ou seja, ela deve ser
executada ao final da contagem do APF do projeto de desenvolvimen-
to e depois ao final do projeto como um todo (passando pelos proje-
tos de melhoria para se entender o acrscimo de funcionalidade que
houve entre a entrega da primeira verso do projeto e todas as melho-
rias subsequentes.

II. Determinar o escopo da contagem e as fronteiras da aplicao im-

portante que se estabelea de forma claras fronteiras da aplicao em relao
s aplicaes externas e ao domnio do usurio.

44 captulo 2
 Esse limite dever levar em considerao o propsito para o qual a APF ser
usada; como e quais os sistemas iro manter os dados; e a identificao das
regras de negcio que daro suporte aplicao. (Longstreet, 2004). Vamos
aos detalhes:
Fronteira da aplicao: trata-se fronteira uma linha virtual que
delimita o que faz parte do sistema que ser implementado e o que
est fora do sistema que ser implementado e de fato interage com este
sistema.

Isto essencialmente importante para o processo por que desta forma

garante-se contar apenas aquilo que esta dentro do sistema e que de
fato ser desenvolvido e busca tambm evitar duplicar contagens.

Um bom delimitador de fronteira o diagrama de casos de uso que

considera os atores como o mundo exterior e que no ser implementa-
do pelo sistema e os casos de uso como o conjunto de servios/funes
que o sistema dever ter.

Segundo (Vazques, Simes, & Albert, 2005) as dicas a seguir ajudam na

determinao da fronteira do sistema.

1. Obter uma documentao do fluxo de dados no sistema e desenhar uma fronteira

em volta para destacar quais partes so internas e externas aplicao;
2. Verificar como os grupos de dados so mantidos;
3. Identificar reas funcionais pela atribuio de propriedade de certos objetos de
anlise, como entidades e processos.
4. Comparar os critrios utilizados em outras mtricas como esforo, durao, custos
e defeitos. As fronteiras para efeito da anlise de pontos de funo e as outras mtri-
cas devem ser as mesmas.
5. Verificar como a aplicao gerenciada; se desenvolvido ou mantida na sua
totalidade por uma equipe distinta.
6. Verificar se o software possui Ordens de Servio especficas e independentes.

Tabela 2.3 Dicas para identificar a fronteira da aplicao (Vazques, Simes, & Albert, 2005)

captulo 2 45
 Escopo da contagem: busca determinar o que fato ser contato, por
exemplo: contar-se- todas as funcionalidades; ou apenas as funcionali-
dades que de fato sero utilizadas pelos usurios; ou ainda apenas algu-
mas funcionalidades especficas.

III Contar as funes do tipo dados Funes de dados so funcionalida-

des solicitadas pelo usurio e que representam requisitos de dados internos e
externos. As funes de dados so divididas em arquivos lgicos internos (ALI)
e arquivos de interface externa (AIE). importante deixar claro que o termo ar-
quivo no deve ser interpretado no seu sentido tradicional de sistema operacio-
nal e sim como sendo apenas um conjunto de dados lgicos agrupados, mas
no necessariamente em uma implementao fsica de arquivo podendo ser,
por exemplo, uma implementao de tabela de dados em um banco de dados.
Para contar as funes de dados necessrio identificar os ALI e os AIE e
determinar suas complexidades.
Um ALI um grupo lgico de informaes de controle ou dados identifica-
dos pelo usurio e mantido dentro dos limites da aplicao. Exemplo: tabela de
banco de dados atualizadas pela aplicao. (Vazques, Simes, & Albert, 2005)
J um AIE um grupo lgico de informaes de controle ou de dados iden-
tificados pelo usurio e relacionado com a aplicao que est sendo contada,
mas atualizados e mantidos dentro dos limites de uma outra aplicao. Um
AIE de uma aplicao sempre ser contado como um ALI em uma outra apli-
cao (Andrade, 2004). Exemplo: tabelas que armazenam dados mantidos pela
aplicao; arquivos de configurao mantidos pela aplicao (excluir aqueles
mantidos por exigncia da tecnologia e manter aqueles relacionados s regras
de negcio); arquivos de segurana de acesso aplicao, mantidos por ela;
arquivos mantidos no s pela aplicao, mas tambm por outra aplicao.
(Vazques, Simes, & Albert, 2005)
A complexidade de cada ALI/AIE baseada no nmero de itens de tipo de
dados (TD) e de tipo de registros lgicos (TR) identificados e associados a cada
ALI/AIE, sendo que um item de dado TD definido como um campo no repe-
tido, nico e identificvel pelo usurio. E um registro lgico um subgrupo de
dados de um ALI/AIE reconhecido pelo usurio, podendo existir dois tipos de
subgrupos: opcional e obrigatrio.
Exemplo de um TD: Uma data de vencimento no formato dd/mm/aaaa re-
conhecida como 1 TD (apesar de ser composta por 3 informaes a data s faz

46 captulo 2
sentido para o usurio de forma inteira e por isso compem um campo atmico
e conta-se 1 TD).
Com a identificao e contagem de cada TD e TR, pode-se classificar um
ALI, de acordo com o Quadro 1, como sendo de complexidade baixa, mdia ou
alta o que contribui, respectivamente, com 7, 10 ou 15 Pontos por Funo No
Ajustados para a contagem final dos Pontos por Funo No Ajustados.
Um AIE tambm classificado como sendo baixo, mdio ou alto de acordo
com o nmero de itens de dados e registros lgicos identificados contribuindo
respectivamente com 5,7e 10 Pontos por Funo No Ajustados como tambm
mostra a tabela 2.4 [Vazquez et al. 2006].

TIPO DE DADOS
TIPOS DE REGISTRO 1 A 19 20 A 50 51 OU MAIS
1 BAIXA BAIXA MDIA
2a5 BAIXA MDIA ALTA
6 ou mais MDIA ALTA ALTA

Tabela 2.4 Complexidade funcional [IFPUG, 1999].

IV. Contar funes do tipo transao funes transacionais so as fun-

cionalidades de processamento dos dados providas para o usurio atravs da
aplicao. Essas funes so definidas como entradas externas (EE), sadas ex-
ternas (SE) e consultas externas (CE).
Com o objetivo de entender a contagem das funes transacionais preciso
antes entender o conceito de processo elementar, que a menor unidade fun-
cional que possui significado no software que est sendo desenvolvido.
Assim, para identifica-los deve-se observar as atividades que os usurios
realizam na aplicao e que obedeam duas regras abaixo estabelecidas.
a) O processo a menor atividade possvel e que ainda assim tenha signi-
ficado para o usurio.
b) O processo auto-contido e deixa as regras de negcio do sistema em
um estado consistente.
Agora que voc j entendeu o que um processo elementar, vamos iniciar
o aprendizado sobre como contar as transaes, comeando pelas entradas ex-
ternas (EE).
Uma EE (entrada externa) um processo elementar que processa dados ou
entradas de controle que vm de fora (da fronteira) da aplicao. Uma entrada

captulo 2 47
externa tem como objetivo fundamental a manuteno de uma ou mais ALI e/
ou alterar o comportamento do sistema.
Uma SE (sada externa) um processo elementar que envia dados ou infor-
maes de controle para fora da fronteira da aplicao. Uma sada SE tem como
objetivo fundamental apresentar informaes para o usurio por meio do pro-
cessamento de outras informaes ou ainda apresentar a resposta de um dado
ou informao de controle.
J uma CE (consulta externa) um processo elementar que envia informa-
es de controle ou dados fora da fronteira do sistema. A funo principal de
uma CE mostrar informaes para o usurio por meio do retorno de um dado
ou de uma informao de controle que venha de uma ALI ou de uma AIE.
A seguir segue uma tabela que mostra um resumo dos objetivos primrios
de cada funo de transao explicada aqui anteriormente.

TIPO DE FUNO TRANSAO

Tpico (EE) entrada externa (SE) sada externa (CE) consulta externa
F - Uma operao que
pode ser feita pela
Alterar o comportamen- IP - Inteno primria NP - No permitida a
funo, mas no sua
to do sistema da funo de transao funo transacional
inteno primria. Ela
pode existir ou no
F - Uma operao que
pode ser feita pela
Manter um ou mais IP - Inteno primria NP - No permitida a
funo, mas no sua
ALIs da funo de transao funo transacional
inteno primria. Ela
pode existir ou no
F - Uma operao que
pode ser feita pela
IP - Inteno primria IP - Inteno primria
Apresentar informaes funo, mas no sua
da funo de transao da funo de transao
inteno primria. Ela
pode existir ou no

Tabela 2.5 Resumo de objetivos primrios das funes de transao (Universidade Est-
cio de S, 2015)

Uma vez identificados todos os CE, SE e EE necessrio contar os itens de

dados para a determinao da complexidade funcional dessas funes transa-
cionais para ento entender e quantificar a contribuio para o clculo do pon-
tos por funo no ajustado.
Em outras palavras, ser necessrio agora atribuir um nmero de com-
plexidade para cada CE, SE e EE sendo que este nmero de complexidade

48 captulo 2
dependente da quantidade de itens de dados e arquivos referenciados que a
funo transacional se relaciona. Quanto mais itens de dados e arquivos refe-
renciados a funo transacional mantr relao, maior ser o nmero de com-
plexidade (que ser classificado em BAIXO MDIO ALTO), quanto menor o
nmero de itens de dados e arquivos referenciados menor ento ser o nmero
de complexidade.
Para que voc tenha um entendimento completo desta contagem acho que
apenas esta faltando dizer o que significa arquivos referenciados (AR).
Um AR : 1) um ALI lido ou mantido pela funo do tipo transao; ou 2) um
AIE lido pela funo do tipo transao.
Agora que voc j entende o que um arquivo referenciado (AR) vamos s
atribuies de complexidades para depois realizar as contagens de pontos de
funo no ajustados. No caso das funes transacionais atribuio de comple-
xidade para uma EE diferente da atribuio de complexidade de uma SE que
por sua vez semelhante a uma atribuio de complexidade de uma CE.
Desta forma, vamos primeiramente entender como funciona a contagem
para a EE e posteriormente para a SE e CE.
Aps contar os itens de dados e os arquivos referenciados de uma EE deve-
se determinar a sua contribuio para a contagem final dos Pontos por Funo
No Ajustados como 3, 4 ou 6 Pontos por Funo No Ajustados respectivamen-
te a uma complexidade BAIXA, MIA ou ALTA que determinada utilizando o
tabela 2.6 logo a seguir.

ARQUIVOS ITENS DE DADOS

REFERENCIADOS 14 5 15 16 - mais
01 Baixa Baixa Mdia
2 Baixa Mdia Alta
3 mais Mdia Alta Alta

Tabela 2.6 Complexidade de EE (IFPUG, 1999)

J o processo para a contagem dos pontos por funo no ajustados das SEs
e CEs, apesar de ser o mesmo da EE, diferente no que tange aos parmetros
de classificao da complexidade, que seguem a tabela 2.7. E a contribuio de
Pontos por Funo No Ajustados para a SE deve ser de 4 para uma complexi-
dade baixa, 5 para a mdia e 6 para a alta. Mas para uma CE a contribuio de
Pontos por Funo No Ajustados deve ser de 3 para a complexidade baixa, 4
para a mdia e 6 para a alta.

captulo 2 49
 ARQUIVOS ITENS DE DADOS
REFERENCIADOS 15 6 19 20 - mais
01 Baixa Baixa Mdia
23 Baixa Mdia Alta
4 mais Mdia Alta Alta

Tabela 2.7 Complexidade de SE [IFPUG, 1999]

v. Determinar o ponto de funo no ajustado o ponto de funo no

ajustado (PFNA) reflete a contagem especifica das funcionalidades do sistema
providas para o usurio. Essa contagem baseada no que ser entregue para
o usurio, e no em como isto ser entregue. Sendo assim, s esto sendo
levados em considerao nesta contagem os requisitos dos usurios.
Para voc encontrar o PFNA deve-se multiplicar o total de ALI, AIE, EE, SE e
CE por suas contribuies adquiridas por meio de sua complexidade. O Quadro
4 exemplifica uma contagem de Pontos por Funo no ajustado no qual se tem
um ALI com complexidade alta, dois AIE com complexidade mdia e um AIE
com complexidade alta, uma EE com complexidade baixa, uma SE com com-
plexidade mdia e duas CE com complexidade alta.

TIPO DE
QDDE COMPLEXIDADE CONTRIBUIO MULT TOTAL
FUNO
ALI 0 BAIXA 7 0
0 MDIA 10 0
1 ALTA 15 15 15
AIE 0 BAIXA 5 0
2 MDIA 7 14
1 ALTA 10 10 24
EE 1 BAIXA 3 3
0 MDIA 4 0
0 ALTA 6 0 3
SE 0 BAIXA 4 0
1 MDIA 5 5
0 ALTA 6 0 5
CE 0 BAIXA 3 0
0 MDIA 4 0
2 ALTA 6 12 12
Total PFNA = 59

Tabela 2.8 Exemplo de clculo dos Pontos por Funo No Ajustados [IFPUG, 1999].

O significado dos pontos de funo no ajustados um valor de complexi-

dade que reflete o sistema no que tange aos requisitos especficos de armazena-
mento e processamento, contudo, dependendo do software, h fatores gerais

50 captulo 2
que podem influenciar o seu tamanho funcional. Portanto, o prximo passo se
justifica exatamente pelo entendimento desses fatores gerais que ajustaro os
pontos de funo contados at ento. (Vazques, Simes, & Albert, 2005)
Ento, ao final, como um template, voc ter um quadro conforme a figura
a seguir:

Fator de Ponderao

Parmetro de Medidas Contagem Simples Mdio Complexo

Nmero de entradas x 3 4 6 =
do usurio
Nmero de sadas x 4 5 7 =
do usurio
Nmero de consultas x 3 4 6 =
do usurio
Nmero de earquivos x 7 10 15 =

Nmero de interfaces x 5 7 10 =
externas

Contagem total

Figura 2.4 Quadro resumo da contagem de pontos de funo no ajustados. (Pressman,

2006)

VI. Determinar o fator de ajuste O valor do fator de ajuste (VFA) basea-

do em 14 caractersticas gerais do sistema que pontuam as funcionalidades do
sistema que esta sendo contado. Cada uma dessas caractersticas associada a
descries que auxiliam na determinao do grau de influncia dessas caracte-
rsticas no sistema.
O grau de influncia dessas caractersticas varia em uma escala de zero a
cinco, significando no influencia para o 0 at fortemente influente para o 5.
Conforme a tabela a seguir.

1 Nenhuma influncia.
2 Influncia mnima.
3 Influncia moderada.
4 Influncia significativa.
5 Grande influncia.

Tabela 2.9 Tabela de nveis de influncia das caractersticas gerais da aplicao (Vaz-
ques, Simes, & Albert, 2005)

captulo 2 51
 As caractersticas gerais do sistema, que esto mostradas na tabela, so 14
itens que avaliam, de maneira geral, o grau de complexidade do sistema.

CARACTERSTICAS GERAIS DO SISTEMA

Comunicao de dados
Processamento distribudo
Desempenho
Configurao altamente utilizada
Volume de transaes
Entrada de dados on-line
Eficincia do usurio final
Atualizao on-line
Processamento complexo
Reutilizao de cdigo
Facilidade de implantao
Facilidade operacional
Mltiplos locais
Facilidade de mudanas

Tabela 2.10 Caractersticas gerais do sistema (Andrade, 2004)

Juntamente com o seu grau de influncia, as caractersticas gerais do sis-

tema so responsveis pelo clculo do valor do fator de ajuste que capaz de
ajustar os Pontos por Funo No Ajustados em +/- 35%, produzindo assim o
valor dos Pontos por Funo Ajustado.
A tabela 2.11 mostra os trs passos necessrios para se determinar o VFA.

PASSO AES
Avaliar cada uma das 14 caractersticas gerais do sistema em uma escala de zero a cinco
1 correspondendo a no influncia at a fortemente influente respectivamente, determinando
o grau de influncia.
2 Somar os graus de influncia encontrados para gerar o total de grau de influncia (TGI).
Usar a seguinte formula para determinar o VFA:
3
VFA = (TGI * 0,01) + 0,65

Tabela 2.11 Passos para a determinao do VFA [IFPUG, 1999].

Vamos a um exemplo para o seu entendimento. Imagine que para um deter-

minado software tenha-se constado a seguinte tabela de caractersticas gerais:

CGS PESO ATRIBUDO CGS PESO ATRIBUDO

Comunicao de dados 3 Atualizao on-line 2
Processamento distribudo 2 Processamento complexo 4
Desempenho 1 Reutilizao de cdigo 2
Configurao altamente utilizada 5 Facilidade de implantao 3
Volume de transaes 4 Facilidade operacional 1
Entrada de dados on-line 5 Mltiplos locais 5
Eficincia do usurio final 1 Facilidade de mudanas 1
TOTAL 39

Baseado nesta tabela, o VFA para o sistema seria VFA = (39 * 0,01)+0,65 = 1,04.

52 captulo 2
 VII. Calcular os Pontos por Funo Ajustados Este o ltimo passo para
a concluso da contagem dos Pontos por Funo. Como visto na etapa i, h trs
tipos de projetos que podem ser contados, a saber: projetos de desenvolvimen-
to, aplicaes em uso ou projetos de manuteno. Sendo assim, tem-se trs fr-
mulas para o clculo dos Pontos por Funo ajustado, uma para cada tipo de
projeto.
Contudo para esta disciplina focaremos apenas a contagem dos Pontos por
Funo para projetos de desenvolvimento.
O clculo dos Pontos por Funo para projetos de desenvolvimento se d
pela seguinte frmula:

PF_Desenvolvimento = PFNA * Fator_de_Ajuste

Com o passo vii chegamos ao ltimo passo do procedimento para a conta-

gem dos pontos de funo.
Entendemos que talvez apenas a explicao do procedimento pode ter sido
um tanto quanto abstrata para voc e algumas dvidas ainda possam existir,
por isso, no captulo que segue preparamos um estudo de caso que com certeza
ir finalizar todas as suas dvidas. Portanto, no pare agora, siga com os estu-
dos e vamos juntos construir a sua competncia neste assunto.

MULTIMDIA
Quer ver um exemplo de contagem de pontos por funo em um vdeo aula interessante?
Ento acesse o link abaixo e divirta-se:
https://www.youtube.com/watch?v=N3AO3JKaLa4

ATIVIDADES
01. Faa uma breve discusso sobre a diferena entre mtricas e estimativas. Busque mos-
trar se so conceitos idnticos, semelhantes ou totalmente diferentes e caso seja um dos
dois ltimos casos mostre quais so as diferenas.

02. Por que to importante medir na engenharia de software?

captulo 2 53
03. Imagine uma aplicao que possua 10 consultas externas, 10 entradas externas, 10
sadas externas, 5 arquivos lgicos internos, 5 arquivos de interfaces externas todos de com-
plexidade mdia. Qual o valor dos pontos de funo no ajustados para este caso conside-
rando uma contagem para projetos de desenvolvimento?

04. Para a tabela abaixo de caractersticas gerais do sistema (CGS) avaliada para um deter-
minado sistema calcule o valor do fator de ajuste.

CGS PESO ATRIBUDO CGS PESO ATRIBUDO

Comunicao de dados 3 Atualizao on-line 2
Processamento distribudo 2 Processamento complexo 3
Desempenho 3 Reutilizao de cdigo 2
Configurao altamente utilizada 2 Facilidade de implantao 3
Volume de transaes 3 Facilidade operacional 2
Entrada de dados on-line 2 Mltiplos locais 3
Eficincia do usurio final 3 Facilidade de mudanas 2
TOTAL

05. Faa uma anlise do valor do fator de ajuste encontrado no exerccio anterior e discutin-
do em alguns pargrafos o seu significado.

06. Calcule o valor de pontos por funo para projeto de desenvolvimento para o software
que possui as seguintes caractersticas:

QUANTIDADE
PARMETRO MEDIDO QUANTIDADE SIMPLES QUANTIDADE MDIO
COMPLEXO/ALTO
Arquivo lgico interno 3 2 1
Arquivo de interface externa 6 4 2
Consultas Externas 5 1 1
Sadas Externas 10 3 2
Entradas Externas 15 10 5

CGS PESO ATRIBUDO CGS PESO ATRIBUDO

Comunicao de dados 4 Atualizao on-line 3
Processamento distribudo 5 Processamento complexo 1
Desempenho 5 Reutilizao de cdigo 4
Configurao altamente utilizada 2 Facilidade de implantao 2
Volume de transaes 5 Facilidade operacional 3
Entrada de dados on-line 1 Mltiplos locais 2
Eficincia do usurio final 3 Facilidade de mudanas 3
TOTAL

54 captulo 2
 REFLEXO
Muito bom meu caro aluno, voc chegou ao final de mais uma etapa do aprendizado sobre
medidas de esforo de desenvolvimento de software.
Neste captulo voc encerrou os estudos acerca do que nos alicera para entender me-
didas de esforo: medidas e mtricas.
Foi mostrado a voc que h vrias formas de realizarmos uma taxonomia de medidas
e mtricas de software e escolhemos mostrar para voc aquela defendida por (Pressman,
2006) e (Pressman, Engenharia de Software, 1995).
Na sequncia, lhe mostramos que dentre os tipos de mtricas apresentadas havia uma
que era de principal interesse, a LOC (linhas de cdigo) por que esta era uma medida de ta-
manho de software e que nos serviria de base para calcular estimativas de tempo e custo de
desenvolvimento de sistemas. Contudo vimos que esta medida s pode ser conseguida (sem
ser estimada) ao final da fase de desenvolvimento de sistemas, de forma que no nos serviria
para estimativas de custo e tempo que so quase sempre realizadas no incio do projeto de
desenvolvimento de software.
Ento, foi mostrado para voc que vrias autores iniciaram uma busca por medidas de
sistema que pudessem ser realizadas em momentos mais iniciais do ciclo de desenvolvimen-
to de software, e uma das medidas que passou a se tornar quase que um padro de fato no
uso para estimativas o Pontos por funo, que uma medida funcional (complexidade),
mas que de certa forma, ou melhor, de forma indireta, tambm pode nos mostrar o tamanho
do software (inclusive alguns autores consideram que esta tambm poderia ser considerada
uma mtrica de medida de tamanho de sistema).
Dada a importncia desta mtrica, seguimos no captulo um estudo bastante minucioso
do procedimento para realizar as vrias medidas que esto por trs da mtrica, e mostramos
a voc todos os passos necessrios para chegar at l.
Agora, no prximo captulo, atuaremos em dois pontos especficos, a saber: mostrar es-
tudo de caso pedaggicos da aplicao do procedimento de medidas dos pontos de funo
e introduzir uma outra mtrica (e seu procedimento) que tambm serve para a determinao
da complexidade do software e uma medida indireta para o tamanho do software que a
anlise de pontos de caso de uso.

captulo 2 55
 LEITURA
Um timo livro na rea de medidas e estimativas de software que foca na tcnica de pontos
de funo o livro Anlise de Pontos de Funo: Medio, Estimativas e Gerenciamento de
Projetos de Software dos autores Carlos Vasquez, Guilherme Simes, Renato Albert.

REFERNCIAS BIBLIOGRFICAS
Albrecht, A. (1979). Measuring application development productivity. IBM Applic. Dev. Joint
SHARE/GUIDE Symposium, 83-92. Monterey, CA.
Anda, B. D. (2001). Estimating Software Development Effort Based on Use Cases Experiences
from industry. UML 2001 - The Unified Modeling Language. Modeling Languages, Concepts, and
Tools, 4th International Conference (LNCS 2185), p. 487-502. Toronto, Canada.
Andrade, E. L. (2004). Pontos de Caso de Uso e Ponto de Funo na gesto de estimativa de
tamanho de projetos de software orientado a objeto. Dissertao de mestrado, 143 f. Braslia.
Fatto. (20 de 08 de 2015). Fatto FAQ. Fonte: Fatto FAQ: http://www.fattocs.com/pt/faq-11.html
Fetcke. T., A. A. (1998). Mapping the OO-Jacobson Approach into Function Point Analysis.
International Conference on Technology of Object-Oriented Languages and Systems (TOOLS-23).
IEEE Comput. Soc. Los Alamitos, CA, USA.
IFPUG International Function Point Users Group. (1999). Function Point Counting Pratices Manual.
. Ohio: IFPUG.
Kerner, G. (1993). Use Case Points: resource estimation for Objectory projects. Objective Systems SF
AB (copyright owned by Rational/IBM).
Longstreet, D. (October de 2004). Function Points Analysis Training Course. 116 p. Acesso em 21
de 03 de 2004., disponvel em www.softwaremetrics.com
Martins, M. D. (2007). GERAO DE PONTOS DE CASOS DE USO NO AMBIENTE COCCAR.
Dissertao de mestrado. So Carlos, So Paulo, Brasil.
Pressman, R. (1995). Engenharia de Software. Sao Paulo: Pearson Makron Books.
Pressman, R. (2006). Engenharia de Software. So Paulo: McGraw-Hill.
Silva, R. L. (20 de 08 de 2015). O modelo ideal de melhoria de processo. Fonte: CIN: http://www.
cin.ufpe.br/~rls/ideal/
Smith, J. (1999). The Estimation of Effort Based on Use Cases. Rational Software, White paper.
Vazques, C. E., Simes, G. S., & Albert, R. M. (2005). Anlise de Pontos de Funo: medio,
estimativas e gerenciamento de projetos de software. So Paulo: rica.
Wikipedia. (29 de 08 de 2015). Ciclo PDCA. Fonte: Wikipedia: https://pt.wikipedia.org/wiki/Ciclo_PDCA

56 captulo 2
 3
Mtricas
Utilizando Pontos
por Funo
Ol caro aluno, estamos impressionados com o seu desempenho, j fechou o
segundo captulo do livro e agora, sem perder tempo, j est iniciando o tercei-
ro. Parabns.
No captulo anterior iniciamos a discusso sobre a tcnica de pontos de fun-
o. Vamos ento aproveitar este captulo para nos aprofundarmos um pouco
mais no tema e tambm estudar alguns estudos de caso acerca da anlise de
pontos de funo.

OBJETIVOS
Este captulo possui por objetivo:
Aprofundar os conhecimentos do aluno no processo da contagem dos pontos de funo
de um determinado sistema. Inclusive dando mais detalhes sobre a forma de identificao de
funes tipo dado e tipo transao.
Aplicar os conhecimentos adquiridos no captulo anterior em um estudo de caso no qual o
aluno poder visualizar a anlise de pontos de funo acontecendo de forma prtica e obje-
tiva e ainda recuperar os conceitos que aprendeu no captulo anterior.
Iniciar as discusses com os alunos sobre estimativas de software, principalmente aquelas
realizadas por mtodo paramtrico proporcional.
a. Mostrar para os alunos a relao entre estimativa de LOC e PF e a influncia da
linguagem de programao nesta estimativa.
b. Realizar a estimativa de custo do estudo de caso em questo.
c. Realizar a estimativa de esforo/produtividade do estudo de caso em questo.
Mostrar com maior profundidade para o aluno os dois tipos adicionais de anlise de pontos
de funo alm do projetos de desenvolvimento.

58 captulo 3
3.1 Estudo de caso exemplo simples de
contagem utilizando um DFD.

Ol caro aluno! Vamos neste captulo falar um pouco sobre a aplicao da anli-
se de pontos de funo por meio de exemplos pedaggicos prticos.
O primeiro estudo de casoque mostraremos aqui o de um sistema de bi-
blioteca modelado por meio de um DFD que baseado no estudo de caso do
material de contedo on-line desta disciplina (Universidade Estcio de S,
2015).
Escolhemos este exemplo por que h um senso comum bastante difundi-
do sobre um sistema de biblioteca que poder ser utilizado aqui para apoiar o
entendimento dos requisitos do sistema que, para no complicar o problema
onde no precisamos (nos requisitos), sero abaixo mostrados em alto nvel.
O sistema em questo possui os seguintes requisitos:
1. Incluir aluno um aluno pode ser includo no sistema para que poste-
riormente ele possa emprestar livros.
2. Emprestar um aluno cadastrado pode tomar um livro emprestado
da biblioteca.
3. Cadastrar livro a bibliotecria pode cadastrar um livro no acervo que
acabou de chegar na biblioteca.
4. Verificar atrasos os livros que esto atrasados podem ser verificados.

A figura 3.1 mostra o modelo DFD (diagrama de fluxo de dados) que modela
o sistema em questo.
Perceba que o modelo tambm traz as interaes que os usurios (aluno e
bibliotecria) fazem com os depsitos de dados, contudo, como o modelo em
questo no traz o dicionrio de dados relativo aos depsitos de dados e ou ao
fluxo de dados, teremos que nos valer de um diagrama adicional, que mostra-
do na figura 3.1.

captulo 3 59
 Considere o DFD Livro
Nmero Autor
Cadastrar Nome Nome
Primeiro CPF
Atendente Num.
Volume
Emprestar
Autoria
Usurio CPF
(fornecido pelo Usurio Nmero
Conexo
sistema acadmico) Nome
Matrcula Emprstimo
END
Matrcula
CPF
Livro
Data_EMP

Figura 3.1 Diagrama de auxlio ao DFD (Universidade Estcio de S, 2015)

Veja que na figura 3.1 o item livro de persistncia e constituir um ALI de

um registro lgico e quatro itens de dados, portanto complexidade BAIXA.
O item autor tambm constituir um ALI de um registro lgico e dois itens
de dados e, portanto, tambm de complexidade BAIXA.
O item autoria, que relaciona autor com livro tem um registro lgico e como
j contamos os itens de relacionamento, consideraremos um item de dados.
A item emprstimo associa um elemento externo com o livro. Nesse caso,
s contamos o nmero de livro em livro. Temos um registro lgico e dois itens
de dados, portanto verificamos na tabela que de complexidade BAIXA.
Para os demais itens do estudo de caso que no estiverem explicitamente espe-
cificados consideraremos uma complexidade padro para todos, a saber: BAIXA.
Olhando para a figura 3.2 voc consegue nos dizer a quantidade de arquivos
lgicos internos (ALI) que o sistema possu?
Aluno Sistema de Biblioteca
a. Aluno D1 Aluno Vlido

Incluir
Aluno D2 Pedido

Pedido
Emprestar
b. Bibliotecria
D3 Acervo
Livro
D4 Emprstimo
Cadastrar
Livro

vericar
Atrasos
Emprstimos

Multa

c. Sistema
Financeiro

Figura 3.2 Modelo DFD de sistema de biblioteca

60 captulo 3
 CONCEITO
Diagrama de fluxo de dados
Segundo a (Wikipedia, 2015) O diagrama de fluxos de dados (DFD) uma represen-
tao grfica do "fluxo" de dados existente em um sistema de informao, modelando seus
aspectos de processo. Ela fornece apenas uma viso do sistema, a viso estruturada das
funes, ou seja, o fluxo dos dados. Frequentemente, eles so uma etapa preliminar usada
para criar uma viso geral do sistema que pode posteriormente ser elaborado.
Os DFDs so excelentes para definir, detalhar, desenhar e estabelecer limites (suas
fronteiras) e domnios (estrutura e abrangncia) para as funcionalidades do aplicativo a ser
gerado, sendo uma das principais ferramentas utilizadas, com essa finalidade, em projetos
de sistemas de informao. Tambm estabelecem uma viso integrada de todas as relaes
existentes entre os dados e os processos que os transformam, bem como os limites que de-
marcam aquilo que pertence ao sistema ou processo de negcio e aquilo que est fora dele,
da sua utilidade em definir o escopo do projeto.
Para entender melhor este estudo de caso seria interessante que voc entendesse o
DFD, para tal v at o link https://pt.wikipedia.org/wiki/Diagrama_de_fluxo_de_dados e es-
tudo como funciona um diagrama de fluxo de dados.
Preste bastante ateno principalmente nos conceitos de entidade externa, depsito de
dados, processos e fluxo de dados.

Se voc falou 4, ento acertou! Perceba que no exemplo temos vrios depsi-
tos de dados que so representaes de persistncias internas do sistema. Desta
forma, consideraremos estes depsitos de dados como sendo nossos ALIs. Assim
possvel identificarmos: ALUNO VLIDO, PEDIDO, EMPRSTIMO e ACERO.
Relembrando, um ALI :

um grupo logicamente relacionado de dados ou informao de controle, cuja manu-

teno feita pela prpria aplicao. Sua funo principal armazenar dados mantidos
dentro da fronteira da aplicao, atravs dos processos da aplicao. Os ALI contribuem
para o clculo de pontos de funo, com base na sua quantidade e complexidade
As informaes de controle so dados usados pela aplicao para garantir total con-
formidade com os requisitos das funes do negcio definidas pelo usurio. (Vazques,
Simes, & Albert, 2005)

captulo 3 61
 Um ALI no pode ser:
Arquivos temporrios.
Arquivos de trabalho.
Arquivos de classificao.
Arquivos de cpia de segurana requerido pelo CPD.
Arquivos introduzidos somente por causa da tecnologia usada.
Ex.: Arquivos de parmetro para um software WFL, JCL etc.
Operaes de juno e projeo.
Arquivos de ndices alternativos. (Vazques, Simes, & Albert, 2005)

Um ALI pode ser:

Tabelas que armazenam dados mantidos pela aplicao;
Arquivos de configurao mantidos pela aplicao;
Arquivos de segurana de acesso aplicao (senhas), mantidos por ela;
Arquivos mantidos no s pela aplicao, mas tambm por outra aplicao.

Agora vamos encontrar as interfaces externas. Para tal, tente encontrar

no diagrama outros sistemas que interagem com o sistema em questo, ou
seja, algo que esteja fora da fronteira deste sistema que estamos analisando.
Lembrando que uma AIE :

Um Arquivo de Interface Externa (AIE) um grupo de dados logicamente relacionados,

ou informaes de controle identificadas pelo usurio, referenciados na aplicao para
fins de recuperao de dados, cuja manuteno feita por outra aplicao. Os dados
so armazenados fora da fronteira da aplicao. (Vazques, Simes, & Albert, 2005)

Uma AIE no pode ser:

Arquivos de movimento recebidos de outra aplicao para manter um ALI
(exemplos: arquivos de remessa e retorno). No entanto os processos de carga e
de gerao destes arquivos podem ser funes do tipo transao. O arquivo de
movimento simplesmente um relatrio gerado em formato de arquivo texto.
Dados mantidos pela aplicao e utilizados por outra aplicao;
Dados formatados e processados para uso de outras aplicaes. (Vazques,
Simes, & Albert, 2005)

62 captulo 3
 Um AIE pode ser:
Dados de referncia externos utilizados pela aplicao. (Vazques, Simes,
& Albert, 2005)
Para uma funo ser identificada como um AIE:
O grupo de dados ou informao de controle logicamente relacionado e
identificvel pelo usurios;
O grupo de dados referenciado pela aplicao sendo contada, porm
externo a ela.
O grupo de dados no mantido pela aplicao sendo contada.
O grupo de dados mantido por outra aplicao, isto , deve ser um ALI
para a outra aplicao. (Vazques, Simes, & Albert, 2005)

Veja no diagrama que h um sistema financeiro, este ser considerado o

nosso AIE (muito provavelmente a multa ser armazenada no sistema finan-
ceiro em um ALI, ento, consideraremos aqui um AIE), portanto, possumos
apenas 1 AIE.
Vamos agora identificar as entradas externas (EE) da aplicao. Para reali-
zar esta atividade basta olhar para o diagrama e entender as entradas que usu-
rios (ou outros sistemas) inserem no sistema que est sendo contato. De forma
completa, um EE ser (Vazques, Simes, & Albert, 2005):
Um processo elementar;
Que processa dados ou informaes de controle recebidos de fora da fron-
teira da aplicao;
Cuja principal inteno manter (incluir, alterar ou excluir) um ou mais
ALIs e/ou modificar o comportamento do sistema.

Lembrando que um processo elementar :

Um processo elementar a menor unidade de atividade significativa para o usurio

final e tem as caractersticas:
Deve ser completo em si mesmo.
Deve deixar a aplicao em um estado consistente. (Vazques, Simes, & Albert, 2005)

captulo 3 63
 So exemplos de EE:
Transaes que recebem dados externos utilizados na manuteno
de ALIs;
Janela que permite adicionar, excluir, e alterar registros em arquivos.
Nesse caso contribuem com 3 entradas externas.
Processamento em lotes de atualizao de bases cadastrais a partir de ar-
quivos de movimento. (Vazques, Simes, & Albert, 2005)

No so exemplos de EE
Telas de filtro de relatrios e consultas;
Menus;
Telas de login. (Vazques, Simes, & Albert, 2005)

So regras de ouro para se identificar uma EE (Universidade Estcio de S, 2015):

Regra 1: os dados ou informaes devem ser recebidos de fora da frontei-
ra da aplicao;
Regra 2: se a entrada de dados pela fronteira no for uma informao que
modifique o comportamento do sistema, deve manter no mnimo um AIE;
Regra 3: pelo menos uma das 3 opes a seguir deve ser satisfeita para o
processo elementar ser identificado como uma EE:
o A lgica de processamento deve ser nica e diferente das demais en-
tradas externas.
o O conjunto de dados elementares identificados distinto dos con-
juntos identificados por outras EE.
o Os ALIs mantidos e os AIEs referenciados so distintos dos utiliza-
dos por outras EE.

Em posse de todas as informaes ditas anteriormente, vamos ento fa-

zer esta anlise por usurios/entidades, que so: ALUNO, BIBLIOTECARIA,
SISTEMA FINANCEIRO.
O ALUNO procede com as seguintes entradas no sistema que assumiremos
estar mantendo algo: ALUNO e PEIDO. Contabilizamos ento duas entradas.
J a BIBLIOTECRIA procede com as seguintes entradas no sistema: LIVRO,
que mantm o cadastro de livro da biblioteca por meio do CADASTARR LIVRO.
Ento contabilizaremos uma entrada externa.

64 captulo 3
 O SISTEMA FINANCEIRO no procede com nenhuma entrada no sistema,
ele simplesmente recebe uma sada do sistema, que ser contabilizada em ou-
tra funo transacional mais frente.
No total teremos ento 3 EEs no sistema que est sendo analisado.
Muito bom, j contamos uma das funes transacionais, agora vamos para
a segunda, no caso, sadas externas (SEs).
Para determinar as SEs deste diagrama mais uma vez olharemos as enti-
dades que interagem com o sistema, mas agora ao invs de prestar ateno nas
setas que saem das entidades externas, iremos prestar ateno nas setas que
chegam essas entidades.
Alm disso, uma SE caracterizada por (Vazques, Simes, & Albert, 2005):
Um processo elementar;
Que envia dados ou informaes de controle para fora da fronteira
da aplicao;
Cuja principal inteno apresentar a informao ao usurio por meio de
lgica de processamento que no seja apenas a recuperao de dados ou infor-
mao de controle. A lgica de processamento deve obrigatoriamente conter
ao menos uma frmula matemtica ou clculo, ou criar dados derivados (no
necessrio que esses dados ou clculo sejam apresentados ao usurio). Pode
tambm manter um ou mais ALI e/ou alterar o comportamento do sistema.

Uma SE pode ser:

Relatrios com totalizao de dados;
Relatrios que tambm atualizam arquivos;
Consultas com clculos ou apresentao de dados derivados;
Arquivo de movimento (exemplo: arquivo de remessa ou retorno) gerado
para outra aplicao;
Informaes em formato grfico;
Telas de login (com criptografia). (Vazques, Simes, & Albert, 2005)

Uma SE no pode ser:

Telas de help.
Drops-downs.
Consultas e relatrios sem nenhum totalizados, que no atualizam arquivos,
no tm dados derivados ou modificam o comportamento do sistema. (Vazques,
Simes, & Albert, 2005)

captulo 3 65
 Com todas as informaes dadas anteriormente e observando o diagra-
ma de fluxo de dados possvel perceber que a entidade ALUNO no recebe
nenhum fluxo de dados, portanto, no contabilizaremos nenhuma SE para
essa entidade.
J a entidade externa BIBLIOTERCRIA recebe a sada EMPRSTIMO do
processo VERIFICAR ATRASOS que provavelmente foi um clculo efetuado
para saber quem est atrasado, portanto, contm uma frmula matemtica e
por isso pode ser contabilizada como uma SE.
Por fim, a entidade SISTEMA FINANCEIRO recebe um fluxo de dados
MULTA do processo VERIFICAR ATRASO, se partirmos do princpio que esta
MULTA derivada de um clculo dos dias de atraso e do valor atual de multa
ento devemos considerar uma SE tambm.
Desta forma, chegamos concluso que h 2 SEs neste sistema.
Por fim, necessrio contar as consultas externas, que caracterizada por
(Vazques, Simes, & Albert, 2005):
Um processo elementar;
Que envia dados ou informaes de controle para fora da fronteira
da aplicao;
Cuja principal inteno apresentar informao ao usurio por meio de
uma simples recuperao de dados ou informaes de controle de ALIs e/ou
AIEs. A lgica de processamento no deve conter frmulas matemtica ou
clculo, nem tampouco criar dados derivados. Nenhum ALI mantido durante
seu processamento, nem o comportamento do sistema alterado.

Uma CE pode ser:

Telas de help;
Informaes em formato grfico;
Drop-downs, desde que recuperem dados de um ALI ou AIE.
Telas de login.
Menu gerados dinamicamente com base em configurao da aplicao.

Uma CE no pode ser:

Menus estticos;
Relatrio e consultas que contenham clculo ou gerem dados derivados.

66 captulo 3
 Tendo em mente todas as informaes que foram faladas anteriormente, ao
analisarmos o sistema em questo possvel perceber que nenhuma das sadas
pode ser caracterizada como como uma consulta externa. Portanto, no conta-
bilizaremos nenhuma consulta externa aqui.
Desta forma, temos a seguinte anlise representada na figura 3.3.

Aluno Sistema de Biblioteca

a. Aluno D1 Aluno Vlido

Incluir
Aluno D2 Pedido

Pedido
Emprestar
b. Bibliotecria
D3 Acervo
Livro
D4 Emprstimo
Cadastrar
Livro

vericar
Atrasos
Emprstimos

Legenda Multa
ALI SE
c. Sistema
AIE CE
Financeiro
EE

Figura 3.3 DFD com analise de ponto de funo

Uma vez que j identificamos todas as funes de tipo transao e todas

as funes do tipo dado e partimos do princpio que as complexidades dessas
funes sero todas BAIXAs, basta agora chegarmos ao clculo dos pontos de
funo no ajustados, para tal utilizaremos a tabela 3.1.

captulo 3 67
 FATOR DE PONDERAO
FUNES TIPO
CONTAGEM NO
DADO E TIPO SIMPLES MDIO ALTO TOTAL
SISTEMA
TRANSAO
EE 3 3 4 6 9
SE 2 4 5 7 8
CE 0 3 4 6 0
ALI 4 7 10 15 28
AIE 1 5 7 10 5
TOTAL 50

Tabela 3.1 Contagem dos pontos de funo no ajustados utilizando SIMPLES como fa-
tor de ponderao (que deve ser multiplicado pela contagem). Utilizamos desta forma por
que o DFD no trouxe informaes para a realizao do clculo da complexidade das fun-
es de dado e de transao. Baseado em (Universidade Estcio de S, 2015)

Portanto, o sistema em questo, segundo o clculo feito na Tabela 1, con-

tm 50 pontos de funo no ajustados.
Agora, o prximo passo, seria realizar a determinao do valor do fator de
ajuste para chegarmos ao ponto por funo.
Para nos ajudar com o clculo do fator de ajuste, vamos aqui terminar hipo-
teticamente algumas caractersticas deste software:
O software dever ser de alta performance, ou seja, caso o usurio queira
consultar um livro ou pega-lo emprestado, o software deve performar as ativida-
des em menos de 1 segundo.
O software ter um volume de transaes mdio.
Todas as entradas de dados ocorrero on line.
O sistema deve ter uma usabilidade alta de forma que qualquer ao deve
ser performada em no mximo 3 cliques de mouse e todas as aes devem ser
amparadas por instrues na tela do computador.
O software receber no futuro vrias atualizaes, uma vez que esta
uma verso de desenvolvimento inicial. Desta forma, importante que ele
tenha como uma de suas principais caractersticas a facilidade de mudana
e manuteno.
As demais caractersticas do software como por exemplo configuraes,
atualizaes, reutilizao e complexidade de processamento influenciam mi-
nimamente as funes do software e consequentemente a sua complexidade
funcional e tamanho.

68 captulo 3
 Tendo em vista essas suposies acima realizadas, sugere-se a seguinte me-
dio das configuraes gerais do sistema.

CARACTERSTICAS GERAIS DO SISTEMA

Comunicao de dados 1 Atualizao on-line 1
Processamento distribudo 1 Processamento complexo 1
Desempenho 5 Reutilizao de cdigo 1
Configurao altamente utilizada 1 Facilidade de implantao 1
Volume de transaes 3 Facilidade operacional 5
Entrada de dados on-line 5 Mltiplos locais 1
Eficincia do usurio final 1 Facilidade de mudanas 5
TOTAL 32

Tabela 3.2 Medio das caractersticas gerais do sistema.

Com a tabela 3.2 conseguimos identificar que para o sistema em questo

temos um TGI (total de grau de influncia) de 32. Agora precisamos encontrar o
valor do fator de ajuste que dado pela frmula abaixo:

VFA = (TGI*0,01) + 0,65

Ento no nosso caso teremos:

VFA = (32*0,01) + 0,65 = 0,97

Desta forma chegamos ao valor de 0,97 para o fator de ajuste.

Perfeito, estamos indo muito bem. Parabns por ter chegado at aqui. Mas,
no pararemos ainda no! Vamos fechar este estudo de caso com chave de ouro,
agora chegando determinao dos pontos de funo ajustados.
Como este um projeto de desenvolvimento, utilizaremos a frmula de de-
senvolvimento dos pontos de funo que aprendemos no captulo anterior e
que, para facilitar a nossa anlise, repetimos logo abaixo:

PF_Desenvolvimento = PFNA*Fator_de_Ajuste

Portanto, no nosso estudo de caso, teremos o seguinte:

PF_Desenvolvimento = 50*0,97 = 48,5

captulo 3 69
3.2 Discusses iniciais sobre estimativas.
Magnfico, chegamos ao valor de pontos de funo do sistema analisado.
Mas, ficam as perguntas: o que esse nmero quer dizer? O que devemos fa-
zer agora?.
Na verdade, como dito anteriormente, este nmero mede a complexidade
funcional do software em questo, e, indiretamente, mede o seu tamanho.
Se pudssemos fazer uma analogia com outra mtrica, poderamos utilizar
por exemplo a medida de distncia entre dois pontos. No entendeu ainda?
Vamos melhora a explicao.
Imagine que voc queira medir a distncia, em linha reta, entre o Rio de
Janeiro e Londres (na Inglaterra) utilizando o sistema internacional de medi-
das conhecido como MKS (metro, kilo e segundos). Olhando rapidamente na
Internet pode-se constatar que a distncia em linha reta de:

Resultado

Rio de Janeiro (Brasil) Londres (Reino Unido)

Latitude: 22 15 0 O Latitude: 51 30 30 O
Latitude: 42 30 0 N Latitude: 0 7 32 N
Algumas cidades prximas Rio de Janeiro Algumas cidades prximas Londres

Distncia: 9182 Km
Azimute: 25

Figura 3.4 Distncia entre Rio de Janeiro e Londres em linha reta- uma mtrica de tama-
nho (HorlogeParlante, 2015)

Ou seja, 9.182.000 metros. Veja que esta medida, assim como os pontos de
funo, mede o tamanho de algo. Assim, os 9.182.000 metros medem a distn-
cia entre duas cidades e os 48,5 pontos de funo o tamanho (de forma indireta)
do sistema que analisamos.
Um ponto interessante a se salientar que ambas as medidas acima so
feitas com mtricas que possibilitam que novas medidas cheguem ao mesmo
resultado, ou seja, se outra pessoa realizar a medida (de forma correta) ambas
chegaro aos mesmos nmeros.

70 captulo 3
 Com esta medida de tamanho podemos fazer previses, ou melhor, esti-
mativas de vrios aspectos. Por exemplo, com a medida da distncia entre Rio
de Janeiro e Londres podemos tentar prever qual seria o tempo gasto por uma
pessoa que sai do Rio de Janeiro com destino a Londres. Como vimos no captu-
lo anterior, podemos fazer esta estimativa utilizando uma paramtrica propor-
cional, queremos dizer, basta entender qual a velocidade que a pessoa viaja
para depois pegar a medida da distncia e dividir por este valor de velocidade.
Veja a tabela 3.3 que mostra velocidades e tempo estimado para a viagem
dependendo do meio de transporte.

MEIO DE VELOCIDADE MDIA DISTNCIA

ESTIMATIVA DE TEMPO PARA A VIAGEM
TRANSPORTE CONSIDERADA MEDIDA
A p 1,5 m/s 918.2000 m 6121333,33 segundos (equivalente a 1700 horas).
Bicicleta 18 m/s 918.2000 m 510111,11 segundos (equivalente a 141,7 horas)
Carro 27,7m/s 918.2000 m 331480,14 segundos (equivalente a 92 horas)
Avio 250 m/s 918.2000 m 36728 segundos (aproximadamente 10,20 horas)
Navio 13 m/s 918.2000 m 706307,7 segundos (equivalente a 196,2 horas)

Tabela 3.3 Estimativas de tempo para percorrer o percurso entre Rio de Janeiro e Londres

E uma estimativa no uma medida?

Na verdade, a estimativa carrega consigo um grau de incerteza. Por exem-
plo, a velocidade mdia do navio de 13 m/s e a estimativa foi feita baseando-se
no fato de que o nvaio viajara nesta velocidade constantemente, no parar e
no ter problemas. Por que, caso o navio pare por algum motivo, ou algum
temporal acontea forando o navio a reduzir a velocidade, o tempo que ele to-
mar para fazer a viagem ser muito maior do que o previsto. Em contrapartida,
caso o vento sopre a favor, nenhuma chuva acontea e ele tenha partido com
um peso menor do que previsto inicialmente, ento, pode acontecer dele che-
gar mais cedo no destino.
Alm disso, a estimativa que utilizamos fez uso de uma paramtrica propor-
cional, ou seja, que considera que no importa o tempo que se decorra a veloci-
dade sempre a mesma. Mas sabemos que em alguns casos isto no verdade,
como por exemplo quando o meio de transporte a bicicleta. Sabemos que a
velocidade mdia no ser mantida constante (na verdade este um exemplo
didtico, sabemos que no d para ir para l apenas de bicicleta).
Vamos agora transpor o exemplo para o software. A medida que encontra-
mos de 49,5 pontos de funo indica, de forma indireta, o tamanho do softwa-
re, ou seja, teria a mesma funo da indicao de 918.2000 m da distncia entre

captulo 3 71
as duas cidades. Portanto, da mesma foram, podemos procurar calcular vrias
estimativas. Podemos por exemplo tentar estimar o nmero de linhas de cdi-
go que este software ter.
Existem diversos estudos que indicam, dependendo da linguagem de pro-
gramao, a quantidade de linhas de cdigo prevista para o sistema baseando-
se no nmero de pontos de funo medidos para o sistema antes da sua imple-
mentao. Abaixo, na mostramos os nmeros de LOC/FP segundo (Pressman,
2011).

LOC/PF
LINGUAGEM DE
MDIA MEDIANA BAIXA ALTA
PROGRAMAO
JAVA 63 53 77
C++ 66 53 29 178
VISUAL BASIC 47 42 16 158
C 162 109 33 704
ADA 154 - 104 205
COBOL 77 77 14 400
CLIPPER 38 39 27 70
INFORMIX 41 31 24 57
LOTUS NOTES 21 22 15 25

Tabela 3.4 Loc/PF (Pressman, 2011)

Vamos pensar um pouco, utilizando uma paramtrica simples, proporcio-

nal, diga-nos, no caso do software que acabamos de analisar no estudo de caso
fosse desenvolvido em Java, qual seria o tamanho estimado (utilizando a m-
dia) em linhas de cdigo do software?
Se voc disse 3.055,5 linhas de cdigo, ento voc acertou! Provavelmente
para chegar neste resultado voc pegou a nossa medida de pontos de funo
ajustados (48,5 pf) e multiplicou por 63 loc/pf que a mdia estimada de linhas
de cdigo para cada ponto de funo medido.
Voc tambm poderia estimar o tempo para se desenvolver esse sistema
considerando uma equipe de uma pessoa. H tambm vrios estudos que mos-
tram qual a mdia de tempo de desenvolvimento de software para cada LOC
ou PF. Por exemplo, (Aguiar, 2004) indica em sua apresentao no congresso
do IFPUG que no Brasil, em 2004, a mdia de horas/fp com linguagens de 3 ge-
rao (Java, C, C++ e outras) de 11,9 horas para cada ponto de funo medido.

72 captulo 3
 Utilizando o dado informado no pargrafo anterior, quanto voc estimaria
que seria o esforo em horas para o desenvolvimento do software do nosso es-
tudo de caso?
Bom, se voc respondeu 577,15 horas ento voc acertou! Voc deve ter
chegado a este nmero fazendo o seguinte clculo: multiplicando os pontos
de funo ajustados encontrados no nosso estudo de caso, que foi de 48,5, por
11,9 horas/fp que o trabalho de (Aguiar, 2004) nos indicou. Parabns!
importante lembrar aqui que esta estimativa considera que a capacidade
de desenvolvimento do time constante, ou seja, sempre ser de 11,9 horas/
FP. H outros mtodos de estimativa, como o COCOMO II, que buscam realizar
estimativas que levam em considerao mais fatores e por isso geram uma pa-
ramtrica no proporcional e que tambm podem ser utilizadas para a estima-
tiva de tempo e custo de sistemas.
Por exemplo, sabemos que equipe de desenvolvimento no costumam se
comportar de forma proporcional medida que inserimos mais pessoas, ou
seja, uma pessoa desenvolveria o software em questo em 577,15 horas, se co-
locarmos mais uma pessoa na equipe, a estimativa paramtrica proporcional
que estamos utilizando sugeriria que ento o software seria desenvolvido em
288,58 horas. Contudo, como dissemos, raramente uma equipe se comporta
de forma proporcional e provavelmente este nmero estaria equivocado. Por
isso recomenda-se tambm o uso de outros mtodos de estimativa de software,
como o COCOMO II.
Imagine agora que voc precise tambm estimar o custo do desenvolvimen-
to deste software. Para tal, tambm podemos realizar a estimativa paramtrica
proporcional utilizando o custo/hora. Por exemplo, suponha que o software
em questo seja desenvolvido em uma empresa no qual o custo operacional de
desenvolvimento de software seja de R$ 100,00/hora. Ento, qual seria o custo
estimado para a produo do software em questo?
Se voc disse R$ 57.715,00 ento voc acertou. Para chegar neste nmero
voc provavelmente multiplicou a quantidade de horas estimadas (577,15)
pelo custo por hora de desenvolvimento da empresa em questo. Parabns,
isso mesmo!

captulo 3 73
3.3 Outros tipos de contagem de pontos de
funo.

No captulo anterior foi falado a voc que a anlise de ponto por funo pode
ser feita para 3 tipos de situaes, a saber: projeto de desenvolvimento, projeto
de melhoria, aplicao.
Para a anlise de pontos de funo para projeto de desenvolvimento foi
falado no captulo anterior a sua formula e neste captulo foi realizado um estu-
do de caso bastante interessante para este tipo de anlise de pontos de funo.
Contudo, no foi dito ainda as frmulas e aspectos de contagem para os
outros tipos de projetos. Ento, vamos abaixo discutir um pouquinho as duas
situaes restantes.

Clculo de Pontos de Funo para um projeto de Melhoria

Segundo o (IFPUG International Function Point Users Group, 1999), o concei-

to de melhoria envolve apenas manutenes evolutivas na aplicao, ou seja,
alteraes feitas na aplicao para atender aos novos requisitos de negcio do
usurio. No so levadas em conta manutenes corretivas e preventivas. (Vaz-
ques, Simes, & Albert, 2005)
Um projeto de melhoria consiste de trs componentes em termos de funes:
1. Funcionalidades da aplicao, includas como requisitos pelo usu-
rio para o projeto: Funes includas, alteradas ou excludas pelo projeto
de melhoria;
2. Funcionalidades de Converso: "Consiste dos pontos de funo entre-
gues por causa de qualquer funcionalidade de converso requerida pelo usu-
rio". (IFPUG International Function Point Users Group, 1999)
3. Valor do fator de ajuste da aplicao Dois valores so considerados,
segundo o manual:
Valor do fator de ajuste ANTES do incio do projeto de melhoria (VAFB)
Valor do fator de ajuste DEPOIS da concluso do projeto de melho-
ria (VAFA)

74 captulo 3
 Deve ser considerado que uma funo do tipo dado (ALI ou AIE) foi alterada
quando ela foi modificada em sua estrutura com alguma incluso, alterao ou
excluso de campos ou atributos.
Frmula para clculo :
EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL * VAFB)

Onde:
EFP Nmero de pontos de funo do projeto de melhoria;
ADD Nmero de pontos de funo no ajustados das funes includas
pelo projeto de melhoria;
CHGA Nmero de pontos de funo no ajustados das funes modifica-
das depois das modificaes;
CFP - Nmero de pontos de funo no ajustados adicionados pela converso;
VAFA Valor do fator de ajuste da aplicao depois do projeto de melhoria;
DEL - Nmero de pontos de funo no ajustados das funes excludas
pelo projeto de melhoria;
VAFB Valor do fator de ajuste da aplicao antes do projeto de melhoria.
(Universidade Estcio de S, 2015)

Clculo de Pontos de Funo para uma aplicao

Para calcular os pontos de funo de uma aplicao existem duas frmulas que
so utilizadas.
Frmula para Contagem Inicial representa todas as funcionalidades re-
queridas pelo usurio de uma aplicao instalada. As funes da converso
de dados no devem ser computadas no tamanho da aplicao entregue, pois,
elas existiro somente para o processo de implantao do aplicativo (Vazques,
Simes, & Albert, 2005).
AFP = ADD * VAF

Onde:
AFP Nmero de pontos de funo ajustados da aplicao;
ADD Nmero de pontos de funo no ajustados das funes instaladas;
VAF Valor do fator de ajuste da aplicao.
Frmula usada aps o projeto de melhoria Aps a concluso de um pro-
jeto de melhoria, os pontos de funo devem ser atualizados para refletir as

captulo 3 75
mudanas na aplicao. Novamente, as funes de converso de dados no de-
vem ser computadas, pois, elas no fazem parte da aplicao (VAZQUEZ, 2005).
AFP = [(UFPB + ADD + CHGA) (CHGB + DEL)] * VAFA

Onde:
AFP Nmero de pontos de funo ajustados da aplicao
UFPB Nmero de pontos de funo no ajustados da aplicao antes do
projeto de melhoria;
ADD Nmero de pontos de funo no ajustados das funes includas
pelo projeto de melhoria;
CHGA Nmero de pontos de funo no ajustados das funes modifica-
das depois do seu trmino;
CHGB Nmero de pontos de funo no ajustados das funes modifica-
das antes do seu trmino;
DEL - Nmero de pontos de funo no ajustados das funes excludas
pelo projeto de melhoria;
VAFA Valor do fator de ajuste da aplicao depois do projeto de melhoria.
(Universidade Estcio de S, 2015)

MULTIMDIA
Gostou do estudo de caso que foi mostrado neste captulo e tambm das outras formas
que existem e contagem da anlise de pontos de funao, a saber: projeto de melhoria,
aplicao?
Sim! timo. Ento acho que voc tambm ir gostar de ver mais um exemplo prtico de
uma contagem de pontos de funo que mostra o processo para os 3 tipos que estudamos:
projeto de desenvolvimento, projeto de melhoria e aplicao.
Para acessar esta aplicao basta clicar neste link:
https://www.youtube.com/watch?v=T2NShJoKJqI
Bom estudo!

76 captulo 3
 ATIVIDADES
01. Calcule a estimativa de tempo e custo para um sistema desenvolvido em C++ conside-
rando as caractersticas abaixo. Utilize o mtodo paramtrico proporcional.

QUANTIDADE QUANTIDADE QUANTIDADE

PARMETRO MEDIDO
SIMPLES MDIO COMPLEXO/ALTO
ARQUIVO LGICO INTERNO 4 1 2
ARQUIVO DE INTERFACE EXTERNA 10 3 1
CONSULTAS EXTERNAS 6 3 2
SADAS EXTERNAS 10 4 3
ENTRADAS EXTERNAS 13 8 5

PESO PESO
CGS CGS
ATRIBUDO ATRIBUDO
Comunicao de dados 3 Atualizao on-line 5
Processamento distribudo 3 Processamento complexo 5
Desempenho 3 Reutilizao de cdigo 5
Configurao altamente utilizada 3 Facilidade de implantao 1
Volume de transaes 1 Facilidade operacional 1
Entrada de dados on-line 1 Mltiplos locais 5
Eficincia do usurio final 1 Facilidade de mudanas 5
TOTAL

Quantidade de horas mdia que um recurso de desenvolvimento demora para desenvol-

ver um ponto de funo = 15 horas/ponto de funo.
Custo por uma hora de desenvolvimento de um recurso de desenvolvimento de software
= R$ 150,00.

02. Calcule a estimativa de tempo e custo para um sistema desenvolvido em COBOL consi-
derando as caractersticas abaixo. Utilize o mtodo paramtrico proporcional.

03. As caractersticas abaixo. Utilize o mtodo paramtrico proporcional.

QUANTIDADE QUANTIDADE QUANTIDADE

PARMETRO MEDIDO
SIMPLES MDIO COMPLEXO/ALTO
ARQUIVO LGICO INTERNO 5 2 6
ARQUIVO DE INTERFACE EXTERNA 15 5 2
CONSULTAS EXTERNAS 5 5 5
SADAS EXTERNAS 8 3 2
ENTRADAS EXTERNAS 11 13 4

captulo 3 77
 PESO PESO
CGS CGS
ATRIBUDO ATRIBUDO
Comunicao de dados 5 Atualizao on-line 5
Processamento distribudo 5 Processamento complexo 5
Desempenho 5 Reutilizao de cdigo 5
Configurao altamente utilizada 5 Facilidade de implantao 5
Volume de transaes 5 Facilidade operacional 5
Entrada de dados on-line 5 Mltiplos locais 5
Eficincia do usurio final 5 Facilidade de mudanas 5
TOTAL

Quantidade de horas mdia que um recurso de desenvolvimento demora para desenvol-

ver um LOC = 0,05 horas/LOC.
Custo por uma hora de desenvolvimento de um recurso de desenvolvimento de software
= R$ 250,00.

04. Deixe claro qual a diferena entre um ALI e um AIE.

05. Alm da estimativa paramtrica proporcional que aprendemos neste captulo, h uma
outra forma de se estimar esforo de software? Qual seria?

REFLEXO
Parabns, voc chegou ao final de mais um captulo, estamos muito orgulhosos de voc.
J percebeu que voc acabou de ultrapassar o marco de metade desta disciplina?
verdade, voc inclusive j caminhou um pouco mais do que a metade.
E voc j percebeu o quanto voc aprendeu? No? Ento vamos ajud-lo a se lembrar.
Veja, at o captulo anterior voc j aprendeu as definies de medidas e mtricas e
tambm a importncia de se medir na engenharia de software.
Tambm aprendeu a classificar os tipos de mtricas que existem na engenharia de soft-
ware segundo a viso de um dos principais autores: Pressman.
Na sequncia voc aprendeu uma nova mtrica, o pontos de funo e tambm apren-
deu todo o procedimento de como realizar uma anlise de pontos de funo em um deter-
minado sistema.
Porm, devo concordar contigo, que at o final do captulo anterior tudo estava muito
terico, correto? Mas neste captulo fomos da teoria prtica usando um exemplo de um
software bastante simples no que tange a quantidade de requisitos para realizar a anlise de
pontos de funo de software. E veja voc, fomos at o final. Executamos todos os passos
do processo.

78 captulo 3
 De quebra, tambm iniciamos as discusses sobre estimativas de software. Na verdade,
colocamos a parte mais simples, que a utilizao de tcnicas paramtrica proporcionais
para a realizao de estimativas. Para fazer isso at relacionamos transformao de PF para
LOC para diversas linguagens. Acredito que tenha sido um dos pontos alto deste captulo
para voc, no foi mesmo?
Agora que voc j sabe medir o tamanho e complexidade funcional de sistemas, preci-
samos, nos prximos captulos, nos preocupar em afinar contigo as tcnicas de estimativa de
esforo de desenvolvimento de software, agora no mais apenas baseado em tcnicas pa-
ramtricas proporcionais simples, mas utilizando modelos mais refinados como o COCOMO
II e tcnica estatstica mais apuradas.
, j percorremos bastante o conhecimento necessrio para a disciplina at aqui, mas
isto no quer dizer que no haja mais coisas interessantes pela frente para finalizarmos
o curso.
Por isso, chega de papo e vamos continuando. Bom estudo!

LEITURA
No incio deste captulo voc estudou um estudo de caso que tinha um modelo bastante co-
nhecido na computao: o DFD (diagrama de fluxo de dados). Voc conhece este diagrama
e esta tcnica de modelagem?
Caso no conhea, uma leitura interessante que indicamos o livro Anlise Estruturada
de Sistemas da autora Chris Gane. Neste livro voc encontrar conhecimentos interessan-
tes sobre a anlise estruturada sendo que o DFD um dos diagramas desta anlise que
muito bem explicado, com exemplos inclusive, neste livro que indicamos. Boa leitura!

REFERNCIAS BIBLIOGRFICAS
Aguiar, M. (2004). Functions Point in Brazil. Conference Proceedings IFPUG 2004. Fonte: http://
www.ifpug.org/Conference%20Proceedings/IFPUG-2004/IFPUG2004-01-Aguiar-function-points-in-
Brazil.pdf
HorlogeParlante. (30 de 08 de 2015). Clculo da distncia entre duas cidades. Fonte:
HorlogeParlante: http://www.horlogeparlante.com/dist%C3%A2ncia-c%C3%A1lculo.html
IFPUG International Function Point Users Group. (1999). Function Point Counting Pratices Manual.
. Ohio: IFPUG.

captulo 3 79
Pressman, R. (1995). Engenharia de Software. Sao Paulo: Pearson Makron Books.
Pressman, R. (2006). Engenharia de Software. So Paulo: McGraw-Hill.
Pressman, R. (2011). Engenharia de Software - Uma abordagem profissional. So Paulo:
McGraw Hill - ARTMED.
Universidade Estcio de S. (20 de 08 de 2015). Contedo on line da disciplina Medidas de
Esforo de Desenvolvimento de Software. Fonte: Estcio WebAula.
Vazques, C. E., Simes, G. S., & Albert, R. M. (2005). Anlise de Pontos de Funo: medio,
estimativas e gerenciamento de projetos de software. So Paulo: rica.
Wikipedia. (29 de 08 de 2015). Wikipidia-Diagrama de fluxo de dados. Fonte: https://pt.wikipedia.
org/wiki/Diagrama_de_fluxo_de_dados

80 captulo 3
 4
Tcnicas de
Estimativa de
Esforo e Custo
Voc j quase um Jedi em medidas de esforo de desenvolvimento de softwa-
re. Olha s at onde chegou voc. Grande caminhada voc fez!
No captulo anterior fizemos um mergulho profundo na tcnica de pontos de
funo, agora, neste captulo, trataremos de como esta tcnica pode ser utili-
zada para a realizao de estimatitvas de esforo/tempo e custo em projetos de
desenvolvimento de software.
Bom estudo!

OBJETIVOS
Este captulo possui por objetivo:
Introduzir o conceito de tcnica de estimativa;
Apresentar o PMI e o PMBOK.
Apresentar os conceitos de tcnicas de estimativa de tempo/esforo e custo segundo
o PMBOK.
Gerar competncia no aluno para a execuo de estimativas utilizando as tcnicas defen-
didas pelo PMBOK.

82 captulo 4
4.1 Tcnicas de estimativa uma introduo.
Ol caro aluno! Vamos neste captulo falar um pouco sobre a aplicao de tc-
nicas de estimativa.
J parou para pensar o que uma estimativa? Lgico que sim, no ver-
dade? No captulo anterior fizemos uma pequena discusso sobre a diferente
entre estimativa e mtrica e voc j sabe que estimativa algo que traz consigo
um grau de incerteza, mas que de certa forma calculada em cima de mtricas
e medidas atuais e/ou de bases histricas.
Por exemplo, possvel realizar uma estimativa de quanto ir chover em
uma determinada poca do ano que vem baseando-se nas medidas de quanto
choveu (medida) nesta mesma poca em anos anteriores.
Contudo, se fizermos uma anlise dos ltimos anos pode ser que nos depa-
remos com vrios valores e ficaria difcil escolher um para usar como previso
no ano que vir. Ento, o que os engenheiros e estatsticos fazem buscar uma
equao que modele o comportamento dos dados medidos (as vezes inclusive
baseados em outras variveis que influenciam a que estamos estimando por
exemplo a quantidade que choveu no perodo imediatamente anterior) para en-
to fazer uma projeo em tempo futuro de como os dados se comportariam.
Nos aprofundaremos nestas tcnicas estatsticas de estimativa mais a frente, no
captulo 5, contudo, j neste captulo, falaremos sobre os tipos possveis (no esta-
tsticas) de estimativas consideradas em projetos pelo PMBOK (PMI, 2013) e depois,
tambm no captulo 5, falaremos de um mtodo especfico que o COCOMO II.
Ento, vamos seguindo por que tem bastante conhecimento importante e
interessante para voc aprender e depois poder colocar em prtica na sua em-
presa e na sua equipe de desenvolvimento de software.

4.2 Tcnicas de estimativa de esforo e

custo em gesto de projetos

I O PMBOK e as estimativas em projetos

Para realizarmos a abordagem das tcnicas de estimativa em gesto de projetos

utilizaremos uma das maiores referencias no assunto que o PMBOK escrito
pelo PMI. (PMI, 2013)

captulo 4 83
 Porm, antes de falarmos especificamente das tcnicas, achamos interes-
sante voc entender um pouco sobre o prprio PMI e o PMBOK, segundo a viso
de (Martins, 2010).
O PMI uma organizao sem fins lucrativos, dedicada ao avano do estado
da arte em gerenciamento de projetos mantendo como compromisso promo-
ver o profissionalismo e a tica em gerenciamento de projeto.
Foi inicialmente criado na Pensilvnia (EUA) em 1969 por 5 voluntrios e
hoje conta com uma comunidade de 265.000 associados e 140.000 certificados
sendo considerada a maior e mais acreditada instituio de educao e desen-
volvimento de padres em gerncia de projetos.

REFLEXO
Em 1969 acontecia no mundo a Guerra Fria, a corrida armamentista e a corrida espacial nos
quais vrios projetos de grande porte estavam sendo executados, como por exemplo: a ida
do homem ao espao, a ida do homem lua, projetos blicos, projetos de infraestrutura como
hidroeltricas, portos, siderrgicas e outros.
Com tantos projetos acontecendo a necessidade de um bom gerenciamento para au-
mentar ficou bvia e da ento o surgimento e rpido crescimento do PMI como sendo uma
organizao que pesquisa e batalha pela profissionalizao do gerenciamento de projeto no
mundo e sempre est na vanguarda do estado da arte do gerenciamento de projetos.

Para atingir esse nmero de pessoas, o PMI se internacionalizou e hoje est

presente em vrios pases por meio de seus captulos (ou, em ingls: chapters),
que so filiais espalhadas geograficamente e contribuem nas misses e objeti-
vos do PMI, promovendo o profissionalismo em gerncia de projetos sendo que
hoje o PMI est presente em mais de 170 pases
O Brasil foi o primeiro pas do mundo a possuir um captulo do PMI. Este
captulo durou at 1984 e posteriormente foi reaberto na dcada de 1990 sendo
que hoje o Brasil possui 13 captulos conforme mostra a figura 4.1.
Voc, estudante ou profissional, pode se associar ao PMI tornando-se um
membro dessa instituio e tendo acesso a vrios estudos e documentos rela-
cionados gerncia de projetos bem como desconto em eventos promovidos
pelo PMI, livros e certificaes.

84 captulo 4
 Chapter Chapter
CE GO
Chapter Chapter
ES SC

Chapter Chapter
DF AM

PMI
Chapter Chapter
BA MG

Chapter Chapter
SP PR

Chapter Chapter
RJ PE
Chapter
RS
Figura 4.1 Captulos PMI Brasil

O PMI tambm oferta aos seus associados, e a populao em geral, vrios

produtos e servios, entre eles:

O PMI desenvolve padres para a prtica profissional de gerncia de pro-

jetos, sendo que um dos principais documentos produzidos o PMBOK
Guide ou A Guidetothe Project Manager Base ofKnowledge (Um guia
para a base de conhecimentos de gerencia de projeto). Hoje, o PMBOK
PADRES se encontra em sua quinta edio e aprovado como um padro nacional
PROFISSIONAIS americano (ANS) pelo Instituto de Padres Nacional Americano (ANSI).
Como temos um especial interesse por esta publicao para falarmos sobre
estimativas em gesto de projetos, mais a frente nos aprofundaremos neste
tpico.
O PMI tambm oferece programas de certificao profissional para
CERTIFICAO promover o crescimento da profisso de gerenciamento de projetos, sendo
que a mais conhecida delas a PMP ou Project Manager Professional;

Vamos falar agora um pouco mais sobre o PMBOK Guide(PMI, 2013).

O PMBOK Guide foi o primeiro padro de prticas profissionais desenvol-
vido pelo PMI e abrange todo o conhecimento da profisso de gerenciamento
de projetos. Ele foi desenvolvido com a ajuda de praticantes e acadmicos que
utilizam de fato essas prticas ou que as desenvolve.

captulo 4 85
 Ou seja, o que apresentado pelo PMBOK Guide amplamente testado
pelos praticantes de gerncia de projetos e aprovadas por eles sendo considera-
das boas prticas para a gerncia de projeto em muitos projetos na maior parte
do tempo, sendo que existe um consenso por parte dos praticantes sobre seus
valores e aplicabilidade.(PMI, 2013)
O PMBOK Guide, alm de trazer esse conjunto de boas prticas, tambm
busca estabelecer uma linguagem comum para o profissional de gerenciamen-
to de projeto. (PMI, 2013)
O PMI diz que o PMBOK Guide no deve ser considerado como um do-
cumento que contempla a totalidade de conhecimento de gerenciamento de
projetos, uma vez que essa profisso muito dinmica e sofre atualizaes a
todo o momento.
As boas prticas de gerenciamento de projetos so estruturadas no PMBOK
Guide em por meio de 10 grandes reas, a saber:
Gerenciamento da Integrao do Projeto;
Gerenciamento do Escopo do Projeto;
Gerenciamento do Prazo do Projeto;
Gerenciamento do Custo do Projeto;
Gerenciamento da Qualidade do Projeto;
Gerenciamento de Recursos Humanos do Projeto;
Gerenciamento da Comunicao;
Gerenciamento dos Riscos do Projeto;
Gerenciamento de Aquisies.
Gerenciamento de partes interessadas. (PMI, 2013)

Cada uma dessas reas organizada em processos que so agrupados em 5

grandes grupos, a saber: iniciao, planejamento, execuo, monitoramento &
controle e execuo.
Para o tpico em questo, estimativa, estamos mais interessados nas gran-
des reas de prazo e custo e mais especificamente no grupo de processos de
planejamento, que onde as principais estimativas acontecem, veja no dia-
grama abaixo na figura 4.2 e figura 4.3 os processos que estas duas grandes
reas possuem.

86 captulo 4

Planejar o
gerenciamento do
cronograma
1. Entradas
.1 Plano de gerenciamento do
projeto
.2 Termo de abertura do projeto
.3 Fatores ambientais da
empresa
.4 Ativos de processos
organizacionais
2. Ferramentas e Tcnicas
.1 Opinio especializada
.2 Tcnicas Analticas
.3 Reunies
3. Sadas
.1 Plano de gerenciamento de
cronograma
Estimar as duraes
das atividades
1. Entradas
.1 Plano de gerenciameto do
cronograma
.2 Lista de atividades
.3 Atributos das atividades
.4 Requisitos de recursos das
atividades
.5 Calendrios dos recursos
.6 Especificao do escopo
do projeto
.7 Registro dos riscos
.8 Estrutura analtica dos
recursos
.9 Fatores ambientais da
empresa
.10 Ativos de processos
organizacionais
2. Ferramentas e tcnicas
.1 Opinio especializada
.2 Estimativa anloga
.3 Estimativa paramtrica
.4 Estimativas de trs pontos
.5 Tcnicas de tomada de
deciso em grupo
.6 Anlise de reservas
3. Sadas
.1 Estimativas das duraes
das atividades
.2 Atualizaes nos
documentos do projeto
Figura 4.2 Processos de gerenciamento de tempo (PMI, 2013)
Viso geral do gerenciamento
do tempo do projeto
Definir as atividades
1. Entradas
.1 Plano de gerenciamento do
cronograma
.2 Linha de base do escopo
.3 Fatores ambientais da
empresa
.4 Ativos de processos
organizacionais
2. Ferramentas e tcnicas
.1 Decomposio
.2 Planejamento em ondas
sucessivas
.3 Opinio especializada
3. Sadas
.1 Lista de atividades
.2 Atributos das atividades
.3 Lista de marcos
Desenvolver o
cronograma
1. Entradas
.1 Plano de gerenciamento do
cronograma
.2 Lista de atividades
.3 Atributos das atividades
.4 Diagramas de rede de
cronograma do projeto
.5 Requisitos de recursos das
atividades
.6 Calendrios dos recursos
.7 Estimativas de durao das
atividades
.8 Especificao do escopo
do projeto
.9 Registro dos riscos
.10 Designaes do pessoal
do projeto
.11 Estrutura analtica dos
recursos
.12 Fatores ambientais da
empresa
.13 Ativos de processos
organizacionais
2. Ferramentas e tcnicas
.1 Anlise de rede do
cronograma
.2 Mtodo do caminho crtico
.3 Mtodo da corrente crtica
.4 Tcnicas de otimizao de
recursos
.5 Tcnicas de desenvol-
vimento de modelos
.6 Antecipaes e esperas
.7 Compresso de cronograma
.8 Ferramenta de cronograma
3. Sadas
.1 Linha de base do
cronograma
.2 Cronograma do projeto
.3 Dados do cronograma
.4 Calendrio do projeto
.5 Atualizaes do plano de
gerenciamento do projeto
.6 Atualizaes nos
documentos do projeto
Sequenciar Estimar os
as atividades recursos das atividades
1. Entradas 1. Entradas
.1 Plano de gerenciamento do .1 Plano de gerenciamento
cronograma do cronograma
.2 Lista de atividades .2 Lista de atividades
.3 Atributos das atividades .3 Atributos das atividades
.4 Lista de marcos .4 Calendrio dos recursos
.5 Especificao do escopo do .5 Registro dos riscos
projeto .6 Estimativas de custos das
.6 Fatores ambientais da atividades
empresa .7 Fatores ambientais da
.7 Ativos de processos empresa
organizacionais .8 Ativos de processos
organizacionais
2. Ferramentas e tcnicas
.1 Mtodo de digrama de 2. Ferramentas e tcnicas
procedncia (MDP) .1 Opinio especializada
.2 Determinao de dependncia .2 Anlise de alternativas
.3 Antecipaes e esperas .3 Dados publicados sobre
estimativas
3. Sadas .4 Estimativa ...
.1 Diagramas de rede do .5 Software de gerenciamento
cronograma do projeto de projetos
.2 Atualizaes nos
documentos do projeto 3. Sadas
.1 Requisitos de recursos das
atividades
Controlar o
.2 Estrutura analtica dos
cronograma
recursos
.3 Atualizaes nos
1. Entradas
documentos do projeto
.1 Plano de gereciamento do
projeto
.2 Cronograma do projeto
.3 Dados de desempenho do
trabalho
.4 Calendrio do projeto
.5 Dados do cronograma
.6 Ativos de processos
organizacionais
2. Ferramentas e tcnicas
.1 Anlise de desempenho
.2 Software de
gerenciamento de projetos
.3 Tcnicas de otimizao
de recursos
.4 Tcnicas de desenvol-
vimento de modelos
.5 Antecipaes e esperas
.6 Compresso de cronograma
.7 Ferramenta de cronograma
3. Sadas
.1 Informaes sobre o
desempenho do trabalho
.2 Previses de cronograma
.3 Solicitaes de mudana
.4 Atualizaes no plano de
gerenciamento do projeto
.5 Atualizaes nos
documentos do projeto
.6 Atualizaes nos ativos de
processos organizacionais
captulo 4 87

Planejar o
gerenciamento dos custos
1. Entradas
.1 Plano de gerenciamento do
projeto
.2 Termo de abertura do projeto
.3 Fatores ambientais da
empresa
.4 Ativos de processos
organizacionais
2. Ferramentas e tcnicas
.1 Opinio especializada
.2 Tcnicas analticas
.3 Reunies
3. Sadas
.1 Plano de gerenciamento
dos custos
Controlar os custos
1. Entradas
.1 Plano de gerenciamento do
projeto
.2 Requisitos de recursos
financeiros do projeto
.3 Dados de desempenho do
trabalho
.4 Ativos de processos
organizacionais
2. Ferramentas e tcnicas
.1 Gerenciamento do valor
agragado
.2 Previso
.3 ndice de desempenho para
trmino (DPT)
.4 Anlises de desempenho
.5 Software de gereciamento
de projetos
.6 Anlise de reservas
3. Sadas
.1 Informaes sobre o
desempenho do trabalho
.2 Previses de custos
.3 Solicitaes de mudana
.4 Atualizaes no plano de
gerenciamento do projeto
.5 Atualizaes nos documen-
tos do projeto
.6 atualizaes nos ativos de
processos organizacionais
Figura 4.3 Processos de gesto de custo (PMI, 2013)
88 captulo 4
Viso geral do gerenciamento
dos custos do projeto
Estimar os custos
1. Entradas
.1 Plano de gerenciamento
dos custos
.2 Plano de gerenciamento
dos recursos humanos
.3 Linha de base do escopo
.4 Cronograma do projeto
.5 Registro dos riscos
.6 Fatores ambientais da
empresa
.7 ativos de processos
organizacionais
2. Ferramentas e tcnicas
.1 Opinio especializada 2. Ferramentas e tcnicas
.2 Estimativa anloga
.3 Estimativa paramtrica
.4 Estimativa bot tom-up
.5 Estimativa de trs pontos
.6 Anlise de reservas
.7 Custo da qualidade
.8 Software de gerencia-
mento de projetos
.9 Anlise de proposta de
fornecedor
.10 Tcnicas de tomadas de
decises em grupo
3. Sadas
.1 Estimativas de custos das
atividades
.2 Base das estimativas
.3 Atualizaes nos docu-
mentos do projeto
Determinar o
oramento
1. Entradas
.1 Plano de gerenciamento dos
custos
.2 Linha de base do escopo
.3 Estimativas dos custos das
atividades
.4 Base das estimativas
.5 Cronograma do projeto
.6 Calendrios dos recursos
.7 Registro dos riscos
.8 Acordos
.9 Ativos de processos
organizacionais
.1 Agregao de custos
.2 Anlise de reservas
.3 Opinio especializada
.4 Relaes histricas
.5 Reconciliao dos limites de
recursos financeiros
3. Sadas
.1 Linha de base dos custos
.2 Requisistos de recursos
financeiros do projeto
.3 Atualizaes nos documen-
tos do projeto
 Perceba a preocupao da estimativa no planejamento de tempo e custo.
Na gesto de tempo h o processo de estimar recursos e o processo de estimar
tempo, j na gesto de custo h o processo de estimar custo. Vamos nos ater
nos processos de estimar tempo e custo.
Olhando mais detalhadamente possvel perceber, principalmente nos
processos de gesto de tempo, que a sequncia sugerida (e no obrigatria) dos
processos acontece de tal forma que quando se alcana o processo 6.5, estimar
a durao das atividades j tudo esta preparado para a aplicao das tcnicas
de estimativas em questo, que a propsito se repetem no processo 7.2, esti-
mar custo que so:
Opinio especializada;
Estimativa anloga;
Estimativa paramtrica;
Estimativa de 3 pontos;
Tcnicas de tomada de deciso em grupo;
Anlise de reservas.

Vamos adicionar algumas tambm do processo estimar custo

Estimativa bottom-up;
Estimativa top-down.

Vamos a cada uma delas!

II. Estimativa anloga

Imagine que um cliente chegue para uma empresa de desenvolvimento de soft-

ware e o seguinte dilogo acontece:
Cliente: Quanto tempo se leva para desenvolver um software de comrcio
eletrnico e qual ser o custo final deste software ?.
Empresa: Ol Sr., para responder a sua pergunta precisamos de mais de-
talhes, por exemplo, preciso saber o escopo completo do software para realizar
uma estimativa mais detalhada e isso leva um pouco de tempo. Portanto, no
posso lhe responder agora?
Cliente: Entendo, contudo, preciso de uma estimativa inicial, mesmo que
no muito precisa, para eu poder fazer um primeiro business case para o pro-
jeto dentro da empresa que trabalho. No h uma outra forma de agirmos para
garantir uma estimativa de ordem de grandeza (magnitude) entre + ou 50%?

captulo 4 89
 Empresa: Podemos tentar sim. Por favor nos responda, quais mdulos o
sr. Gostaria de ter no seu sistema de comrcio eletrnico?
Cliente: Pois bem, gostaria de possuir no lado da administrativo um mdu-
lo de cadastro de produto, promoes (cdigo de promoes) e CRM. Do lado
do cliente o sistema de carrinho de compras.
Empresa: Entendemos a sua necessidade. No passado, fizemos um siste-
ma muito parecido com este que pretende desenvolver. Para tal, foram neces-
srias 1000 horas de esforo de desenvolvimento que performamos em aproxi-
madamente 2 meses com uma equipe de 3 pessoas. O custo final para o cliente
foi de R$ 100.000,00.
Cliente: Ok, obrigado. Agora consigo finalizar o meu plano de negcios,
caso ele seja aprovado venho at aqui para realizarmos uma estimativa mais
precisa de +ou- 5%.

Voc acha que no dialogo acima com o que a empresa que est vendendo o
software fez foi um chute ou uma estimativa?
Sabemos que voc pode ter respondido um chute, principalmente por
que pelo dilogo parece que a empresa cedeu a uma presso do cliente em de-
terminar o prazo.
Contudo, perceba no dilogo que a estimativa saiu com base em um projeto
passado, que provavelmente no igual ao projeto atual, mas parecido, ou
seja, anlogo.
Ento podemos dizer que a situao anterior retratou uma estimativa an-
loga, que usa valores de um projeto anterior semelhante ao atual para estimar
valores do atual como esforo, custo, oramento, durao e outros.
Normalmente a tcnica de estimativa anlogo no muito precisa e por isso
utilizada nas fases iniciais do projeto, quando h poucas informaes dispo-
nveis (conhecidas) sobre o projeto. ento entendida como uma estimativa
de ordem de magnitude com uma margem de erro de -50% a +75%. (PMI, 2013)
(BARBOSA, ABDOLLAHYAN, DIAS, & LONGO, 2007).Em contrapartida, um
tipo de estimativa bastante prtica e rpida e por isso utilizada.
Obviamente quanto mais parecido os dois projetos forem, maior ser a pre-
ciso da estimativa e embora seja uma tcnica quase sempre aplicada para se
estimar o projeto como um todo em uma abordagem top-down (veremos mais
frente o que isto quer dizer) ela tambm pode ser aplicada para partes do pro-
jeto e tambm em conjunto com outras tcnicas.

90 captulo 4
 Mas a fica a pergunta: h uma outra tcnica que pode ser utilizada para
conseguirmos estimativas mais precisas? .
H, vamos estuda-las em seguida!

III. Estimativa paramtrica

Lembra do dilogo da histria anterior? Ento, a histria no parou por ai no,

teve continuao, veja abaixo!
... o cliente voltou loja depois de um ms.
Cliente: Ol a todos, esto lembrados de mim? Eu vim h um ms para
falarmos sobre um projeto de e-commerce. .
Empresa: Lgico que lembramos senhor. O que deseja? .
Cliente: Aquele projeto de comrcio eletrnico foi aprovado aps a apre-
sentao do business case e agora preciso realizar a sua execuo. Para tal, es-
tou fazendo uma cotao e precisamos agora daquela estimativa mais precisa.
possvel fornec-la?
Empresa: O senhor conseguiu fechar o escopo do projeto e j possui as es-
pecificaes? .
Cliente: Sim claro, j realizamos todas as especificaes que consistem
em: diagrama de casos de uso com a descrio; um diagrama de classe de neg-
cios de alto nvel; um diagrama de entidade relacionamento de alto nvel; a des-
crio em fluxograma dos processos com as regras de negcio e um dicionrio
de dados. Isto suficiente para vocs realizarem a estimativa? .
Empresa: Claro senhor, at estranho quando um cliente nos fornece tan-
tos documentos e to bem detalhados, isto nos ajuda muito na estimativa a di-
minuir o grau de incerteza, e de certa forma reduz o preo de implementao,
por que h menos riscos envolvidos para ns em uma possvel negociao de
escopo fechado. Vamos fazer a anlise de pontos de funo do software para
medir o seu tamanho e por meio desta anlise conseguimos fazer a estimativa
e esforo, durao e custo.
... uma semana depois.
Empresa: Ol senhor, tudo bem? Conseguimos finalizar a estimativa do
seu sistema de comrcio eletrnico. Segundo nossa medida de pontos de fun-
o o seu software possui 1100 PFs. Em nossa base histrica baseada em 10
anos de desenvolvimento de softwares neste contexto verificamos que nossos
desenvolvedores conseguem desenvolver 0,8PF por hora, desta forma estima-
mos um esforo de 1375 horas.

captulo 4 91
 Fizemos tambm uma anlise de riscos por meio da qual foi possvel reali-
zar uma anlise de reservas para os riscos identificados e que responderemos
ativamente caso ocorram. Como as informaes que nos foram passadas esto
bem detalhadas, os riscos foram poucos e a anlise de reserva nos apontou buf-
fers que correspondem a 5% tanto de tempo quanto de custo.
Como temos a disponibilidade de montar uma equipe de 4 pessoas para o
seu projeto e considerando um esforo j com as reservas de 1444 horas estima-
mos uma durao de aproximadamente 3 meses. um pouco mais do que os
2,25 meses que uma conta rpida responderia, mas temos que nos atentar ao
diagrama de redes do projeto e ao seu caminho crtico.
Referente aos custos, a nossa hora de desenvolvimento de R$ 100,00, desta
forma, j incluindo as reservas, poderamos fazer o software por R$ 144.400,00.
Cliente: Muito bom, entendi a lgica da sua estimativa e consideraremos a
sua empresa na concorrncia que estamos montando. Obrigado!

Perceba pelo dilogo acima que a empresa no mais utilizou a estimativa

anlogo, mas mesmo assim ainda olhou para o passado para entender os valo-
res futuros do projeto atual.
Dizemos que a empresa se valeu de uma tcnica de estimativa conhecida
como paramtrica, que quando se utiliza os valores unitrios de produtivi-
dade por hora de trabalho (por exemplo, para se colocar o piso em uma casa
demora-se em mdia 10m2/dia) e os multiplica pela quantidade total do traba-
lho (ento, se temos 10m2 de piso para colocar em uma determinada atividade,
estima-se que a atividade ter a durao de 10 dias). (Xavier, 2014)

Esta uma tcnica que pode oferecer um grau de preciso muito maior do
que a anloga, mas dependente de dois aspectos:
1. Da qualidade da medida de tamanho do trabalho a ser realizado que
produzida.
2. Da qualidade da base histrica de produtividade unitria que ser utili-
zado para a multiplicao pelo tamanho.

Apesar de ser mais precisa, necessita de um nvel de informao alto para

ser aplicada e, por isso, quase sempre no acontece com preciso em pontos
iniciais do projeto, mas quando j se conhece um pouco melhor o escopo.
Bom, voc deve ter percebido no dilogo que houve a anlise de risco e uma
anlise de reserva tambm foi utilizada, o que isso?

92 captulo 4
IV. Anlise de reservas

Percebeu no item anterior que a estimativa paramtrica costuma ser bem pre-
cisa? Lgico que sim. Tambm deve ter percebido que este tipo de estimativa
muito utilizado no ramo da engenharia civil, certo? Costumamos dizer que
este tipo de estimativa a estimativa do pedreiro, ou seja, quando o pedreiro
precisa cobrar o servio ou ver tempo que leva para executar o servio quase
sempre ele faz uma medida de tamanho de rea e multiplica por uma produti-
vidade histrica dele.
Bom, se a estimativa paramtrica to precisa e esta tcnica utilizada em
obras, por que ento as obras costumam atrasar tanto? Pelo menos este o
mito popular dito.
Acontece que estimar durao e estimar esforo so coisas diferentes.
Primeiro precisa analisar se as medidas de tamanho realizadas so boas e
se a base histrica tambm de qualidade. Na verdade, no ramo de engenharia
civil, ambos costumam ser de boa qualidade, o que nos confere estimativas de
esforo razoveis. Contudo, a durao depende do esforo e tambm de uma
anlise de risco, uma vez que se tudo ocorrer bem este esforo poder ser exe-
cutado em oito horas dirias, por exemplo, sem interrupo, no entanto, caso
chova (por exemplo) o pedreiro ter que interromper o trabalho, afetando a du-
rao. Ou ento, caso algum retrabalho seja necessrio, por baixa qualidade de
execuo, a durao e o esforo sero afetados.
Ento, para melhorar a estimativa, a tcnica de anlise de reserva pode ser
utilizada (e tambm a tcnica de anlise de 3 pontos que veremos mais adiante)
e consiste na adio de reservas de tempo (ou buffers ou ainda reservas para
contingencia) s estimativas para contingenciar o risco das incertezas do cro-
nograma. (PMI, 2013)
A quantidade desta reserva pode ser um nmero fixo por tarefa, uma por-
centagem por tarefa ou ainda pode ser adquirido por meio de uma anlise utili-
zando mtodos quantitativos.(BARCAUI, BORBA, SILVA, & NEVES, 2007)
Porm, importante que voc entenda que esta anlise de reserva no pode
ser considerada uma gordura no planejamento. Ela deve vir de uma anlise
de risco, principalmente considerando tcnicas como o VME (valor monetrio
esperado - no caso de custo) calculadas para os riscos para os quais a resposta
foi uma aceitao ativa por meio de plano de contingncia.

captulo 4 93
V. Estimativa de 3 pontos

Vamos a um exemplo: nas suas experincias passadas, quando voc marcou um

compromisso com algum, quantas vezes voc chegou exatamente no horrio?
Quando dizemos EXATAMENTE EXATAMENTE mesmo. Se voc fizer esta
anlise perceber que muito difcil mesmo conseguirmos atender a um deter-
minado horrio exatamente como foi combinado. O que se faz habitualmente
chegar com antecedncia para garantir que no horrio marcado estejamos
prontos. No mesmo?
Ento, no projeto tambm acontece assim. Na verdade a distribuio de
chances de uma determinada tarefa ser concluda exatamente conforme pre-
vista pode ser modelada em uma curva normal, parecida com a curva mostrada
na figura 4.4.
Veja como a linha azul representa pouco perto de todas as possibilida-
des, ou seja, acertar a estimativa em cima realmente muito difcil mesmo,
no acha?

CONCEITO
Distribuio Normal
Uma varivel aleatria contnua x tem distribuio Normal se sua funo densidade de
probabilidade for dada por:

1 1 x 2
f (x) = exp , x ( , ) .
22 2

Usamos a notao X N ( , 2 )

A variao natural de muitos processos industriais realmente aleatria. Embora as dis-

tribuies de muitos processos possam assumir uma variedade de formas, muitas variveis
observadas possuem uma distribuio de frequncias que , aproximadamente, uma distri-
buio de probabilidade Normal. (Portal Action, 2015)

94 captulo 4
 Normal Padro
0,4

0,3

Densidade (x)
0,2

0,1

0,0
4 2 0 2 4

Figura 4.4 Exemplo de distribuio normal padronizada (Portal Action, 2015)

Ento, qual seria a soluo? Veja a continuao do dilogo do nosso cliente

com a empresa que desenvolve sistemas.
Cliente: Ol novamente. Finalizamos a concorrncia dentro da nossa em-
presa e vocs ganharam o projeto. Vamos iniciar?.
Empresa: Que tima notcia senhor! Vamos sim!
Cliente: H apenas uma inconvenincia: vocs conseguiro terminar em
exatamente 3 meses? Estou um pouco incomodado com o fato de assumir pe-
rante meus clientes internos da empresa uma data to assim, digamos, singu-
lar! No h uma forma mais confortvel de trabalharmos com estas estimati-
vas? Sabemos que muito difcil acertamos uma data com tamanha preciso..
Empresa: Lgico, entendemos a sua posio! Na verdade, no nosso pro-
cesso, podemos refinar ainda mais esta estimativa, deixando-a um pouco mais
confivel e, talvez, at calcular o grau de confiana do cronograma e atividades
por meio da tcnica de 3 pontos que nos dar ao final um intervalo de datas,
ao invs de uma determinada data, no qual o projeto ser findado, dando uma
certeza maior de cumprimento do mesmo, o que acha?
Cliente: Bem melhor, podemos ento utilizar esta tcnica para realizar o
cronograma do projeto. Pode nos preparar o plano de projeto com esta tcnica?
Empresa: Sim claro, conte conosco.
Olha s que interessante, existe uma tcnica conhecida como tcnica de 3
pontos (tambm conhecida como tcnica PERT) que ao invs de dar uma es-
timativa de 1 ponto que tem baixa probabilidade de acontecer, fornece uma

captulo 4 95
estimativa de intervalo de tempo que mais provvel de ocorrer. Ela funciona
assim (Mulcahys, 2011) :
1. Cada atividade deve ser estimada pensando em 3 possibilidades, a sa-
ber: a pessimista, a otimista e a mais provvel. Vamos para um exemplo:
a) para uma atividade de se desenvolver a tela de cadastro de funcion-
rio um determinado desenvolvedor estimou (utilizando pontos por fun-
o e o histrico de produtividade de desenvolvimento dele) que o mais
provvel seria terminar a tarefa em 12 horas.
b) Contudo, ele pesquisou em sua base histrica e j houve momentos
em que a produtividade dele foi bem maior, sendo que se ele atingisse
novamente aquela produtividade provavelmente terminaria em 6 horas.
c) Mas, tambm verificou que em determinados momentos passados,
em virtudes de outras variveis, a produtividade dele no foi to boa, sen-
do que se isso se repetisse ele terminar a 25 horas.
d) Desta forma, as estimativas para esta atividade ficaram assim:

Mais provvel (MP) 12 horas

Otimista (O) 6 horas
Pessimista (P) 25 horas

2. Com esses valores em mos, possvel determinar a durao esperada

da atividade, ou abreviando o DEA, que se d pela seguinte formula:
a)

( P + 4 MP + 0 )
DEA =
6

b) Aplicando a frmula ao exemplo anterior, teramos o seguinte DEA

para a atividade:

( 25 + 4 12 + 6 )
DEA = = 13,7
6

c) Isso quer dizer que a durao esperada desta atividade, utilizando

os 3 pontos, seria de 13,17. Contudo, isto ainda um nmero e no um
intervalo. Como devemos proceder para chegar no intervalo?

3. Agora importante importante calcularmos o desvio padro para

por meio dele estabelecermos os intervalos da estimativa juntamente com o

96 captulo 4
seu grau de confiana. Para calcular o desvio padro a frmula abaixo deve
ser utilizada:
a)

(P 0)
=
6

b) No nosso exemplo teramos o seguinte desvio padro:

( 25 6 )
= = 3,17
6

4. Pronto, basta agora definir quantos desvios padro o intervalo ter.

Quanto mais desvios padro maior ser o grau de confiana na estimativa.
Vamos utilizar um desvio padro. Veja abaixo a frmula:
a)

Intervalo da atividade = DEA DP

b)

Intervalo da atividade = 13,17 3,17

c) Portanto, consideraremos para o nosso exemplo o intervalo de esti-

mativa de horas que ir de 10,00 at 16,34

5. No exemplo colocamos a confiabilidade para 1 sigma (1 desvio padro)

que para a curva normal em questo da uma confiana de 68,26%. Caso queira
uma confiana maior, ao invs de aplicar apenas um sigma, poderamos aplicar
2 sigmas:
a) Para dois sigmas o intervalo seria de 13,17 6,34 at 13,17 at + 6,34
(observe que o 6,34 utilizado o desvio padro multiplicado por dois),
desta forma o grau de confiana esperado seria de 95,46%.
b) A tabela abaixo mostra o grau de confiabilidade at 6 sigmas
(Mulcahys, 2011):

SIGMA CONFIABILIDADE
1 SIGMA 68,26%
2 SIGMA 95,44%
3 SIGMA 99,74%
6 SIGMA 99,99985%

captulo 4 97
 c) A mostra a tabela acima de forma grfica, perceba que quanto mais
sigmas (desvio padro) consideramos no intervalo, maior a abran-
gncia da curva normal considerada e ento maior a confiabilidade
da estimativa.
99,74%

95,44%

68,26%

3 2 + + 2 + 3

Figura 4.5 Distribuio normal da curva da tcnica de 3 pontos

6. J vimos como determinar o intervalo de uma atividade, mas como fa-

zer para o projeto como um todo? Para tal considere as atividades que esto no
caminho crtico do projeto apenas (uma vez que elas sequenciadas configuram
o maior caminho do incio ao final do projeto). Vamos a um exemplo
a) Considere que as atividades da tabela abaixo esto sequenciadas
incio fim (a primeira tem que terminar para que a segunda se inicie e a
segunda deve terminar para que a terceira se inicie e assim por diante)
(Mulcahys, 2011).

ATIVIDADE P M O DEA SIGMA INTERVALO

A 47 27 14 28,17 5,5 22,67- 33,67
B 89 60 41 61,67 8,0 53,67 - 69,67
C 48 44 39 43,83 1,5 42,33 - 45,33
D 42 37 29 36,50 2,17 34,33 - 38,67

b) Para calcular a durao total do projeto no podemos simplesmen-

te calcular todos os DEAs e depois todos os SIGMAS e fazer DEA + ou
SIGMA, isto estaria estatisticamente equivocado. O que devemos fazer

98 captulo 4
 encontrar a VARINCIA de cada uma das atividades, soma-las, e depois
tirar a raiz quadrada para encontrar o desvio padro do projeto. Vamos l!
c) A VARINCIA de cada atividade dada pela frmula:
2
(P 0)
Vari ncia da Atividade =
6

d) Ento a nossa tabela de atividades ficaria da seguinte forma:

ATV P M O DEA SIGMA INTER. VARINCIA

A 47 27 14 28,17 5,5 22,67 33,67 30,25
B 89 60 41 61,67 8,0 53,67 69,67 64,00
C 48 44 39 43,83 1,5 42,33 45,33 2,25
D 42 37 29 36,50 2,17 34,33 38,67 4,70

e) A soma de todas as varincias do projeto ser de: 101,20.

f) Para calcular o desvio padro do projeto basta tirar a raiz quadrada
da soma das varincias, que ser de: 10,06.
g) A soma de todos os DEAs das atividades resultar na durao espe-
rada do projeto (DEP) que ser de: 170,17.
h) Ento, para este projeto, a estimativa para 1 sigma (1 desvio padro)
de durao ser de: 170,17 + ou 10,06. Ou seja, a durao do projeto ser
de 160,11 a 180,23 com uma confiana de 68,26%.

CONCEITO
Caminho crtico do projeto
O caminho crtico a sequncia de atividades que devem ser concludas nas datas progra-
madas para que o projeto possa ser concludo dentro do prazo final. Se o prazo final for ex-
cedido, porque no mnimo uma das atividades do caminho crtico no foi concluda na data
programada. importante entender a sequncia do caminho crtico para saber onde voc
tem e onde voc no tem flexibilidade. Por exemplo, voc poder ter uma srie de atividades
que foram concludas com atraso, no entanto, o projeto como um todo ainda ser concludo
dentro do prazo, porque estas atividades no se encontravam no caminho crtico. Por outro
lado, se o seu projeto est atrasado, e voc alocar recursos adicionais em atividades que no
esto no caminho crtico no far com que o projeto termine mais cedo. (Wikipedia, 2015)

captulo 4 99
VI Opinio especializada e tcnicas de tomada de deciso em
grupo

Nas estimativas, a opinio especializada pode complementar bases histricas

e trazer um olhar mais crtico para as estimativas j calculadas com as tcnicas
anteriores ou at para ajudar no clculo das tcnicas anteriores.
Desta forma, conseguir a opinio especializada por meio de uma abor-
dagem de equipe com tcnicas como brainstorm, tcnica Delphi ou Grupo
Nominal podem trazer eficincia e qualidade ao processo de estimativa, alm
de aumentar o envolvimento das pessoas no projeto tornando-as mais compro-
metidas com o planejamento e com as estimativas realizadas.

CONEXO
No tpico anterior voc viu que para gerenciar melhor as opinies e ideias de um grupo
de pessoas algumas tcnicas podem ser utilizadas como brainstorm, tcnica Delphi e Gru-
po Nominal.
Quer saber um pouco mais sobre essas tcnicas? Ento acesse os links abaixo e
bons estudos.
Brainstorm:http://goo.gl/oW9U89
Tcnica Delphi:http://goo.gl/rh38sJ
Grupo Nominal: http://goo.gl/dn9xhL

VII. Estimativa top-down

A tcnica de estimativa top-down (de cima para baixo) utilizada juntamente

com a estimativa anloga na qual uma estimativa total para o projeto reali-
zada (de tempo ou de custo) e a partir da deriva-se esta estimativa para partes
menores do projeto.
Ela utilizada principalmente no incio do projeto quando pouco se conhe-
ce sobre os detalhes do projeto e o planejamento do mesmo se encontra em
fases bem iniciais.
Por exemplo, um engenheiro civil, no incio do projeto, poderia dizer que
o custo de construo de uma determinada casa seria de R$ 1.000.000,00 por
meio da tcnica anloga. Perguntado sobre quanto disso seria para a fundao

100 captulo 4
e quanto para acabamento ele poderia utilizar a estimativa anloga top-down
e dividir o R$ 1.000.000,00 de acordo com sua opinio especializada de obras
anteriores percentualmente e dizer, por exemplo, que normalmente para uma
obra daquele tipo e porte gasta-se 20% em fundamento e 35% em acabamento
(valores didticos apenas para exemplificar a tcnica de top-down).

VIII. Estimativa bottom-up

Ao contrrio da top-down a estimativa bottom-up parte de baixo para cima

para realizar a estimativa de esforo ou custo total do projeto e utilizada quan-
do o nvel de detalhamento do planejamento do projeto alto com informaes
bastante interessantes sobre o escopo e atividades para permorm-lo.
Este mtodo busca estimar cada atividade (ou componente) do projeto e depois
somar essas estimativas para se conseguir a estimativa total do projeto (de esforo
ou custo). Diz-se de baixo para cima por que normalmente o escopo do projeto (e
na sequencia suas atividades) derivado em uma estrutura hierrquica conhecida
como EAP (estrutura analtica do projeto) a qual tem em seu topo o nome do pro-
jeto que vai sendo derivado (quebrado) em componentes menores como fases do
ciclo de vida do projeto, componentes das fases e assim at ser complementadas
pelas atividades para se executar cada componente identificado na EAP.
Depois que a derivao feita e a menor poro derivada estimada, parte-
se somando de baixo para cima as estimativas (de esforo ou custo) at ento
chegar ao topo do projeto novamente quando se ter a estimativa para o projeto
como um todo.

ATIVIDADES
01. Para o projeto exemplo que enunciamos no tpico de estimativa de 3 pontos, calcule o
intervalo para 2 sigmas, 4 sigmas e 6 sigmas conforme abaixo:

INTERVALO
PROJETO DEP D. PAD. PROJETO VAR PROJETO ESTIMATIVA
PROJETO
1 SIGMA 170,17 10,06 101,20 160,11 a 180,23
2 SIGMA 170,17 10,06 101,20
4 SIGMA 170,17 10,06 101,20
6 SIGMA 170,17 10,06 101,20

captulo 4 101
02. Um projeto possuir 4 atividades com dependncia incio-fim em seu caminho crtico, a
saber: A, B, C e D. A atividade A foi estimada para ser realizada em 20 horas na melhor das
hipteses, 80 horas na pior e 70 na mais provvel. Da mesmo forma, a atividade B, que ser
executada aps a A, foi estimada em 80 horas na melhor das hipteses, 90 horas na pior
e 88 na mais provvel. J a atividade C, que ser executada imediatamente aps o trmino
da atividade B foi estimada em 50 horas na melhor das hipteses, 85 horas na pior e 60
na mais provvel. E a atividade D, que dever ser executada logo aps a atividade C foi
estimada em 30 horas na melhor das hipteses, 40 horas na pior e 32 na mais provvel.
Calcule o que se pede:
a) O DEA de cada uma das atividades.
b) O desvio padro de cada uma das atividades.
c) A varincia de cada uma das atividades.
d) O intervalo estimado de cada uma das atividades para a confiabilidade de 1 sigma.
e) A durao total do projeto.
f) O desvio padro do projeto.
g) O Intervalo de durao do projeto para 1, 2, 4 e 6 sigmas de confiabilidade.

Para guia-lo no exerccio use os dois quadros a seguir:

ATV P M O DEA D. PAD.ATV. VAR ATV INTERVALO ESTIMATIVA

A 80 70 20
B 90 88 80
C 85 60 50
D 40 32 30

INTERVALO
PROJETO DEP D. PAD. PROJETO ESTIMATIVA
PROJETO
1 SIGMA
2 SIGMA
4 SIGMA
6 SIGMA

03. Voc estudou nos captulos anteriores sobre os pontos de funo e aprendeu que esta
uma mtrica indireta para se medir o tamanho do software. Agora voc estudou vrias tc-
nicas de estimativa. Como voc usaria os pontos de funo para estimar software e com qual
das tcnicas de estimativa voc considera que os pontos de funo trabalhariam melhor?

102 captulo 4
04. Qual tcnica de estimativa mais precisa: paramtrica ou anloga? Explique a
sua resposta.

05. Qual tcnica voc utilizaria em conjunto com a tcnica de 3 pontos para realizar as esti-
mativas mais provvel, otimista e pessimista? Por que?

06. Leia o dilogo abaixo e responda qual tcnica de estimativa foi utilizada pela empresa.
Famlia: Ol, boa tarde. Tudo bem? Viemos aqui por que gostaramos de fazer um pas-
seio pelas dunas do deserto da cidade. Esta agncia de turismo realiza o passeio?
Atendente da agncia de turismo: Ol, tudo bem sim, espero que com vocs tambm.
A nossa agncia faz o passeio sim. Voc deseja faz-lo quando? .
Famlia: Gostaramos de fazer amanh pela manh. O problema que o nosso voo de
volta para nossa cidade sai s 17:30. Voc acredita que haja tempo para fazermos o passei
completo? .
Atendente da agncia de turismo: Acredito que sim, aguarde apenas um momento.
Depois de 5 minutos ...
Atendente da agncia de turismo: Conversei com os animadores de turismo que
costumam realizar esse passeio com os nossos clientes e eles disseram que normalmente
uma famlia de 3 pessoas como a de vocs costuma fazer o passeio em 4 horas. Assim, caso
vocs se decidam pelo passei acreditamos que saindo s 08:00 vocs conseguiro finalizar
o passei e ainda ter um tempo razovel para ir at o aeroporto e no perder o voo.
Famlia: Ok, obrigado. Ficaremos com o passeio. .

07. Um pedreiro consegue colocar um metro quadrado de piso de porcelanato de 0,6m x

0,6m em 1 hora. H 100 metros quadrados que devem receber o piso em questo. Estima-
se ento que o pedreiro levar 100 horas para concluir o servio. Que tipo de estimativa
foi utilizada? Voc acredita que h outra tcnica que tambm poderia ser utilizada aqui (em
conjunto com a utilizada ou em substituio a ela) que traria maior confiabilidade estimativa
realizada? Se sim, qual seria a tcnica e por que traria mais confiabilidade?

captulo 4 103
 REFLEXO
Olha s! Estamos impressionados com voc. Conseguiu finalizar mais um captulo e conquis-
tar mais conhecimentos sobre medidas de esforo de desenvolvimento de software. Muito
bom mesmo!
Agora, temos certeza que voc consegue entender que estimar desenvolvimento de soft-
ware no uma coisa impossvel ou algum tipo de magia ou feitiaria, h sim muitas tcnicas
e cincia por trs destas estimativas.
Falamos assim por que na rea de desenvolvimento de software muitos profissionais no
acreditam em estimativas ou pensam que isto impossvel ou invivel.
Na nossa opinio achar que estimar software algo que no funciona ou desnecessrio
pura falta de conhecimento. E se durante esses quatro captulos ns conseguimos fomen-
tar em voc opinio diversa a esta, ento entendemos que fomos bem-sucedidos e que voc
est no caminho certo para realizar o desenvolvimento de softwares profissional.
Mas, isto no quer dizer que sua caminhada chegou ao fim. Ainda temos mais um captulo
para estudar e a sim finalizar a jornada que iniciamos no captulo 1.
Neste captulo estudamos os tipos de estimativas que so utilizadas em gerenciamento
de projetos. Perceba que no estudamos nenhum processo de estimativa em si, mas sim ti-
pos/tcnicas de estimativa e debatemos suas potencialidades e debilidades, quando e onde
utiliz-las.
Agora, voc precisa entender que cada tipo de tcnica estudada aqui pode ser realizada
usando procedimentos de estimativas j consagrados.
Por exemplo, voc aprendeu aqui a tcnica de estimativa paramtrica e viu que esta
tcnica se baseia na medida de tamanho daquilo que se quer estimar e utiliza uma medida
de produtividade histrica unitria para se estimar o esforo. Pois bem, no captulo 5 voc
estudar uma forma de se realizar estimativa paramtrica chamada COCOMO II que foi cria-
da especialmente para se realizar estimativas paramtricas em softwares, ou seja, bastante
especfica para a nossa rea.
Alm disso, voc tambm aprenderar outras tcnicas estatsticas para se realizar estima-
tivas alm de tambm debatermos sobre o controle de prazo e custo por meio da tcnica de
anlise do valor agregado.
Percebeu como ainda temos algumas coisinhas para estudar antes de nos declararmos
experts em medidas de esforo de desenvolvimento de software?
Pois , ento, chega de conversa e vamos ao que interessa: captulo 5, a vamos ns!
Bons estudos!

104 captulo 4
 LEITURA
Caso voc queira se aprofundar um pouco mais na gesto de tempo e custo em projetos,
sugerimos a leitura dos livros de Gerenciamento de Custo em Projetos e Gerenciamento de
tempo em Projetos da coleo de gerenciamento de projetos da FGV, a saber:
BARBOSA, C., ABDOLLAHYAN, F., DIAS, P. R., & LONGO, O. C. (2007). Gerenciamento de Custos
em projetos. So Paulo: FGV.
BARCAUI, A., BORBA, D., SILVA, I., & NEVES, R. (2007). Gerenciamento do Tempo em projetos.
So Paulo: FGV.

REFERNCIAS BIBLIOGRFICAS
BARBOSA, C., ABDOLLAHYAN, F., DIAS, P. R., & LONGO, O. C. (2007). Gerenciamento de Custos
em projetos. So Paulo: FGV.
BARCAUI, A., BORBA, D., SILVA, I., & NEVES, R. (2007). Gerenciamento do Tempo em projetos.
So Paulo: FGV.
Martins, M. D. (2010). Gerenciamento de projetos. Ribeiro Preto, So Paulo, Brasil: Uniseb.
Mulcahys, R. (2011). Preparatrio para o exame de PMP. RMC Publications Inc.
PMI. (2013). Um guia de conhecimento em gerenciamento de projetos. Pennsylvania: Project
Management Institute Inc.
Portal Action. (29 de 08 de 2015). Distribuio Normal. Fonte: Portal Action: http://www.
portalaction.com.br/probabilidades/62-distribuicao-normal
Pressman, R. (2006). Engenharia de Software. So Paulo: McGraw-Hill.
Pressman, R. (2011). Engenharia de Software - Uma abordagem profissional. So Paulo:
McGraw Hill - ARTMED.
Wikipedia. (30 de 08 de 2015). Wikipedia. Fonte: Caminho crtico do projeto: https://pt.wikipedia.
org/wiki/Caminho_cr%C3%ADtico
Xavier, C. d. (2014). Metodologia de Gerenciamento de Projetos: Methodware. 3. ed. Editora
Brasport.

captulo 4 105
106 captulo 4
 5
Tcnicas de
Estimativas e
Estimativas com
Base Estatstica
 isso ai! Voc conseguiu chegar no ltimo captulo do curso. Parabns!
No captulo anterior falamos sobre tcnicas de estimativa de esforo/tempo e
custo genricas abordadas e defendidas pelo PMBOK. Neste captulo vamos en-
tender um tipo de tcnica especfica para software, o COCOMO, o COCOMO II
e o Putnam.
Alm disso voc estudar uma tcnica de controle de projetos bastante inte-
ressante e tambm defendida pelo PMBOK que a tcnica da anlise do valor
agregado, ou EVA.
Bons estudos!

OBJETIVOS
Este captulo possui por objetivo:
Apresentar as tcnicas COCOMO e COCOMO II e ensinar o aluno a como aplica-las.
Dar conhecimento ao aluno sobre gerenciamento de projetos e empresas de software uti-
lizando algumas tcnicas de administrao consagradas, como o ponto de equilbrio, porm
utilizando como parmetro o ponto de funo.
Permitir que o aluno tome contato com alguns mtodos estatsticos, como interpolao e
tambm com a tcnica de valor agregado.

108 captulo 5
5.1 Tcnicas de estimativa continuao.
Ol caro aluno! Vamos neste captulo continuar falando sobre tcnicas de es-
timativa e depois ainda falar sobre algumas tcnicas baseadas em estatstica.
Vamos nos explicar melhor! No captulo anterior tambm falamos sobre
tcnicas de estimativa, correto? Sim. Porm, falamos sobre tcnicas, vamos
dizer, gerais, ou seja, tcnicas que podem ser aplicadas em qualquer tipo de
projeto, seja ele de engenharia civil, naval, mecnica ou de software. Queremos
dizer que no importa o contexto do projeto voc pode aplicar uma tcnica pa-
ramtrica de estimativa ou anloga sem nenhum problema.
Contudo, sabemos que o contexto influencia muito nas estimativas, e se de
repente tivssemos tcnicas de estimativa dependente de contexto, estas pode-
riam ser um pouco mais precisas.
Desta forma, na engenharia de software, alguns acadmicos iniciaram es-
tudos para fazer, por exemplo, uma tcnica paramtrica mais especfica para
trabalhar com o desenvolvimento de software, como o caso do COCOMO II. E
so exatamente essas tcnicas que iremos nos aprofundar agora.
Alm disso, tambm gostaramos que voc tivesse algum conhecimento so-
bre outras tcnicas de estimativa com base estatstica e iremos estuda-las tam-
bm aqui neste captulo.
Por fim, h outro assunto importante que no trata especificamente sobre
estimativa e medidas de esforo, mas sim sobre o acompanhamento do projeto
no que diz respeito a comparar as estimativas realizadas com o que est sendo
executado e entender o quanto o projeto est andando dentro do planejado.
essas tcnicas se d o nome de controle de projeto e uma das mais famosas (e uti-
lizadas) o EVA (valor agregado) que enunciada dentro do PMBOK (PMI, 2013).
Viu quantas coisas legais temos pela frente? Ento, vamos iniciar os nos-
sos estudos!

5.2 COCOMO
Como vimos na introduo deste captulo, vamos estudar algumas tcnicas pa-
ramtricas de estimativas que so bem aderentes ao processo de desenvolvi-
mento de software e foram criadas especialmente para ele.

captulo 5 109
 importante voc saber que estes modelos que estudaremos daqui para
frente so modelo de estimativa para software que usam frmulas empirica-
mente derivadas (estudaremos mais adiante as interpolaes que nos permi-
tem isso) de um conjunto limitados de projetos medidos. Ou seja, para se che-
gar a essas frmulas o pesquisar rene os dados de N projetos realizados no
passado, plota os dados em um grfico bidimensional e aplica tcnicas esta-
tsticas e matemticas para extrair uma frmula que modelo o comportamen-
to dos dados em questo e que possa ento modelar projetos futuros pareci-
dos com aqueles nos quais a frmula foi baseada. (Pressman, Engenharia de
Software, 1995)
Por isso necessrio que voc saiba que nenhuma dessas frmulas podem
ser aplicadas a qualquer tipo de projeto de software que voc deve ser bastante
criterioso no uso delas e principalmente ter em mente que isto se trata de uma
estimativa e que por isso h sempre um nvel de erro associado ao que se pro-
duziu de fato.
Uma vez que voc j entendeu as premissas do que iremos aprender agora,
acho que j esta na hora de lhe apresentar uma tcnica de estimativa de esforo
e durao bastante famosa e, de certa forma, precursora no desenvolvimento
de software, o COCOMO.
O COCOMO, que significa COnstructive COst MOdel (modelo de custo
construtivo) foi criado por Barry Boehm em 1981 (Boehm, 1981) de fato uma
hierarquia de estimativas que busca realizar a estimativa de esforo e durao
baseada em um modelo estatstico de uma s varivel.
A hierarquia prev 3 tipos de estimativas, a saber:

Modelo estatstico simples que computa o esforo (custo) por meio de

MODELO BSICO uma funo paramtrica simples baseada apenas no tamanho do soft-
ware. (Pressman, Engenharia de Software, 1995)
Modelo estatstico que computa o esforo de desenvolvimento baseado
no tamanho (como no poderia deixar de ser) e tambm baseado em
MODELO INTERMEDIRIO direcionadores de custo que incluem avaliaes subjetivas de: produto,
hardware, pessoal e outros atributos do projeto. (Pressman, Engenharia
de Software, 1995)
Modelo estatstico que junta composto por tudo o que falou-se nos mo-
delos bsicos e intermedirios e ainda j uma avaliao do impacto dos
MODELO AVANADO direcionadores de custo sobre cada passo do processo de engenharia
de software, a saber: engenharia de requisitos, projeto, implementao e
etc). (Pressman, Engenharia de Software, 1995)

Para cada um dos modelos acima h uma frmula/procedimento de clculo.

110 captulo 5
COCOMO Bsico

Vamos analisar o COCOMO bsico que, como dito, composto por uma equa-
o paramtrica simples para se estimar o esforo e durao do desenvolvimen-
to do software.

E = ab (KLOC)bb D = cb (E)db

Figura 5.1 Frmula de esforo do Figura 5.2 Frmula de durao do

COCOMO bsico (Pressman, Engenharia de COCOMO bsico (Pressman, Engenharia de
Software, 1995) Software, 1995)

E = esforo aplicado em pessoas-ms;

D = tempo de desenvolvimento em meses cronolgicos;
KLOC =nmero estimado de milhares de linhas de cdigo do projeto;
ab, cb e bb , db = so os coeficientes e expoentes que se alteram dependendo
do tipo de software que est sendo utilizado e que pode ser verificado na (Pressman,
Engenharia de Software, 1995)

MODELO DE PROJETO DE SOFTWARE ab bb cb db

Modelo orgnico 2,4 1,05 2,5 0,38
Modelo semidestacado 3,0 1,12 2,5 0,35
Modelo embutido 3,6 1,20 2,5 0,32

Tabela 5.1 Valores dos coeficientes e expoentes do COCOMO bsico de acordo com o
modelo de projeto (Pressman, Engenharia de Software, 1995)

Como se pode perceber na equao da figura 5.1 h 2 coeficientes e 2 ex-

poentes que devem ser escolhidos de acordo com o tipo do software que est
sendo analisado e que j enunciamos na tabela 5.1. Vamos explicar cada um
deles segundo (Universidade Estcio de S, 2015).

MODO ORGNICO OU CONVENCIONAL

Projetos de software simples, pequenos, pequenas equipes com relativa experincia. Trabalha-se um
conjunto de requisitos no to rgidos, pode exemplificar pequenos sistemas.

captulo 5 111
 MODO SEMIDESTACADO OU DIFUSO
Projetos de software intermedirio (em tamanho e complexidade), nos quais temos equipes com v-
rios nveis de experincia, que devem programar uma combinao de requisitos rgidos. Por exemplo:
um sistema de processamento de transaes.

MODO EMBUTIDO OU RESTRITO

Um projeto que deve ser desenvolvido dentro de restries operacionais, como por exemplo, sistema
de controle de telefonia

Vamos a um exemplo rpido. Se tivssemos um software convencional sen-

do desenvolvido em uma equipe de 3 a 4 pessoas poderamos utilizar o Modo
Orgnico. Imagine que este software foi medido inicialmente com 20 FP e ser
desenvolvido em C.
Tomando por base a tabela de (Pressman, 2011) que enunciamos no captu-
lo 3 podemos fazer a converso de PF para LOC. Veja a tabela abaixo novamente:

LOC/PF
LINGUAGEM DE PROGRAMAO MDIA MEDIANA BAIXA ALTA
JAVA 63 53 77 -
C++ 66 53 29 178
VISUAL BASIC 47 42 16 158
C 162 109 33 704
ADA 154 - 104 205
COBOL 77 77 14 400
CLIPPER 38 39 27 70
INFORMIX 41 31 24 57
LOTUS NOTES 21 22 15 25

Tabela 5.2 Loc/PF (Pressman, 2011)

Ou seja, o software medido com 20 PF segunda a tabela ter em mdia 3249

LOC ou 3,25 KLOC.
Desta forma, o esforo para a construo do software ser de

E = 2,4 (3,25)1,05 D = 2,5 (8,27)0,38

E = 8,27 pessoas / ms D = 5,58 meses

Os nmeros acima significam que o software em questo levaria 1 ms se

fosse feito por 8,27 pessoas, sendo que o COCOMO recomenda 5,58 mses para
o software, o que nos leva a uma equipe recomendada de:

N = E/T N = 8,27/5,58 = 2 pessoas para performar o software em 5,58 meses.

112 captulo 5
COCOMO Intermedirio

O COCOMO intermedirio calcula o esforo de desenvolvimento de software

em funo do tamanho do programa e de um conjunto de direcionadores de
custo, alternativamente chamados atributos ou fatores de software, que in-
cluem avaliaes subjetivas do produto, do hardware, do pessoal e dos atribu-
tos do projeto. (Jnior & Sanches, 2000)
Esses direcionadores de custo so caractersticas do desenvolvimento do
software em questo que podem adicionar ou retirar esforo da estimativa.
Segundo os estudos de (Boehm, 1981) 15 direcionadores foram identifica-
dos e definidos como provocadores de impactos representativos na produtivi-
dade e custo do software. E tambm agrupou esses direcionadores em 4 gru-
pos, a saber (Pressman, 1995):
Atributos do produto
o Confiabilidade exigida do software
o Tamanho do banco de dados da aplicao
o Complexidade do produto
Atributos de hardware
o Restries ao desempenho de run-time
o Restries de memria
o Volatilidade do ambiente de mquina virtual
o Tempo de turnaround (tempo para completar o ciclo) exigido
Atributos de pessoal
o Capacidade de anlise
o Capacidade em engenharia de software
o Experincia em aplicaes
o Experincia em mquina virtual
o Experincia em linguagens de programao
Atributos de projeto
o Uso de ferramentas de software
o Aplicao de mtodos de engenharia de software
o Cronograma de atividades de desenvolvimento exigido

Para cada um dos atributos acima, durante o clculo do COCOMO interme-

dirio, necessrio classifica-los em uma escala de 6 pontos que vai de muito
baixo a extra alto. Veja a seguir.

captulo 5 113
 ESCALA
Muito baixo
Baixo
Normal
Alto
Muito alto
Extra alto

Tabela 5.3 Escala para avaliao qualitativa dos fatores direcionadores de custo

Depois de ter classificado quantitativamente cada um dos fatores direciona-

dores de custo de acordo com a tabela 5.3, importante agora fazer a classifica-
o quantitativa para mais tarde ser possvel gerar o EAF (fator de ajuste de es-
foro) que ser adicionado frmula de esforo que aprendemos no COCOMO
Bsico para compor o COCOMO Intermedirio.
Veja na os valores quantitativos para cada classificao qualitativa dos fato-
res de ajuste de custo realizados segundo teoria de (Boehm, 1981) exposta em
(Universidade Estcio de S, 2015).

MUITO MUITO EXTRA

ATRIBUTOS DO PROJETO BAIXO NORMAL ALTO
BAIXO ALTO ALTO
CONFIABILIDADE EXIGIDA DO SOFTWARE 0,75 0,88 1 1,15 1,40
TAMANHO DO BANCO DE DADOS DA 0,94 1 1,08 1,16
APLICAO
COMPLEXIDADE DO PRODUTO 0,70 0,85 1 1,15 1,30 1,65
RESTRIES AO DESEMPENHO DE 1 1,11 1,30 1,66
RUN-TIME
RESTRIES DE MEMRIA 1 1,06 1,21 1,56
VOLATILIDADE DO AMBIENTE DE MQUINA 0,87 1 1,15 1,30
VIRTUAL
TEMPO DE TURNAROUND (TEMPO PARA 0,87 1 1,07 1,15
COMPLETAR O CICLO) EXIGIDO
CAPACIDADE DE ANLISE 1,46 1,19 1 0,86 0,71
CAPACIDADE EM ENGENHARIA DE 1,42 1,17 1 0,86 0,70
SOFTWARE
EXPERINCIA EM APLICAES 1,29 1,13 1 0,91 0,82 0
EXPERINCIA EM MQUINA VIRTUAL 1,21 1,10 1 0,9
EXPERINCIA EM LINGUAGENS DE 1,14 1,07 1 0,95
PROGRAMAO
USO DE FERRAMENTAS DE SOFTWARE 1,24 1,10 1 0,91 0,83
APLICAO DE MTODOS DE ENGENHARIA 1,24 1,10 1 0,91 0,82
DE SOFTWARE
CRONOGRAMA DE ATIVIDADES DE DESEN- 1,23 1,08 1 1,04 1,10
VOLVIMENTO EXIGIDO

114 captulo 5
 Uma vez determinados os valores quantitativos dos fatores direcionadores
de custo, importante definir o EAF (fator de ajustamento de esforo) que ser
dado pela multiplicao dos valores de todos os direcionadores de custo que
foram atribudos para a aplicao que esta sendo estimada.
Agora, s aplicar na equao do COCOMO Intermedirio que dada abaixo:

E = ai (KLOC)bi EAF

Figura 5.3 Equao do COCOMO Intermedirio

Porm, os valores do coeficiente ai e do expoente bi so diferentes daque-

les estabelecidos para o COCOMO bsico, na verdade eles seguem a tabela
5.4 abaixo:

PROJETO DE SOFTWARE A B
Orgnico 3,2 1,05
Semidestacado 3,0 1,12
Embutido 2,8 1,20

Tabela 5.4 Coeficientes e expoentes COCOMO Intermedirio

COCOMO Avanado

O COCOMO Avanado inclui o que j estudamos at o COCOMO Intermedirio,

porm faz a considerao do esforo e prazo distribuindo-os proporcionalmen-
te pelas fases do desenvolvimento do software, que segundo (Jnior & Sanches,
2000) acontece de acordo com as tabelas abaixo:

DISTRIBUIO DE ESFORO (%) TAMANHO

MODO FASE 2KDSI 8KDSI 32KDSI 128KDSO 512 KDSI
Planos e Requisitos 6 6 6 6 ...
Projeto do Produto 16 16 16 16 ...
Programao 68 65 62 59 ...
Orgnico
Projeto Detalhado 26 25 24 23 ...
Codificao 42 40 38 36 ...
Integrao e teste 16 19 22 25 ...
Planos e requisitos 7 7 7 7 7
Projeto do Produto 17 17 17 17 17
Programao 64 61 58 55 52
Semidestacadoo
Projeto detalhado 27 26 25 24 23
Codificao 37 35 33 31 29
Integrao e teste 19 22 25 28 31

captulo 5 115
 DISTRIBUIO DE ESFORO (%) TAMANHO
MODO FASE 2KDSI 8KDSI 32KDSI 128KDSO 512 KDSI
Planos e requisitos 8 8 8 8 8
Projeto do Produto 18 18 18 18 18
Programao 60 57 54 51 48
Embutido
Projeto detalhado 28 27 26 25 24
Codificao 32 30 28 26 24
Integrao e teste 22 25 28 31 34

Tabela 5.5 Distribuio de esforo (Fernandes, 1995) apud (Jnior & Sanches, 2000)

DISTRIBUIO DE ESFORO (%) TAMANHO

MODO FASE 2KDSI 8KDSI 32KDSI 128KDSO 512 KDSI
Planos e Requisitos 10 11 12 13 ...
Projeto do Produto 19 19 19 19 ...
Orgnico
Programao 63 59 55 51 ...
Integrao e teste 18 22 26 30 ...
Planos e requisitos 16 18 20 22 24
Projeto do Produto 24 25 26 27 28
Semidestacadoo
Programao 56 52 48 44 40
Integrao e teste 20 23 26 29 32
Planos e requisitos 24 28 32 36 40
Projeto do Produto 30 32 34 36 38
Embutido
Programao 48 44 40 36 38
Integrao e teste 22 24 26 28 30

Tabela 5.6 Distribuio de prazo (Fernandes, 1995) apud (Jnior & Sanches, 2000)

5.3 COCOMO II
O COCOMO II uma evoluo do COCOMO de 1981 e leva em considerao
abordagens mais modernas para o desenvolvimento de software que agora
usam linguagens dinmicas, componentizao e desenvolvimento em banco
de dados (Sommerville, 2011). E tambm incorporou um conjunto de submo-
delos capaz de produzir estimativas mais detalhadas, a saber:
Um modelo de composio de aplicao;
Um modelo de projeto preliminar;
Um modelo de reuso;
Um modelo de ps arquitetura.

116 captulo 5
Modelo de composio de aplicao

Utilizado para projetos no qual o software ser composto por componentes reu-
sveis, scripts ou programao de banco de dados ou ento para projetos de
prototipao. (Sommerville, 2011)
A frmula para se calcular o esforo em PM (pessoas/ms) dada segundo
a figura 5.4

(NAP (1 %REUSO) )
PM = 100
PROD

Figura 5.4 Equao de esforo COCOMO II modelo de composio de aplicao (Som-

merville, 2011)

Onde:
PM = esforo pessoas/ms
NAP = Nmero total de pontos de aplicao
PROD = produtividade de pontos de aplicao que dada segundo a:

EXPERINCIA E CAPACIDADE DO Muito Baixa Baixa Nominal Alta Muito Alta

DESENVOLVEDOR
CAPACIDADE E MATURIDADE ICASE Muito Baixa Baixa Nominal Alta Muito Alta
PROD (NAP/MS) 4 7 13 25 50

Tabela 5.7 Produtividade de pontos de aplicao (Sommerville, 2011)

O processo de aplicao (e de contagem dos NAPs) se d conforme explica-

do em (Jnior & Sanches, 2000) a seguir:
O processo de contagem do NAP segue o processo de contagem de pontos
de objeto que o seguinte:
1. Efetuar o NAP iniciando pela contagem de nmero de objetos da apli-
cao que sai pela contagem de nmero de telas, relatrios e componentes em
linguagem 3GL que constituiro a aplicao.
2. Classificar cada instncia do objeto segundo sua complexidade confor-
me tabela 5.8:

captulo 5 117
 TELAS
# e fontes de tabelas e dados
Nmero de vi-
Total < 4 Total < 8 Total ou +
ses contidas
(< srvr e < 3 cint) (2 - 3 srvr e 3 - 5 cint) (> srvr e > cint)
<3 simples simples mdia
3a7 simples mdia difcil
>8 mdia difcil difcil
RELATRIOS
Nmero # e fontes de tabelas e dados
de sees Total < 4 Total < 8 Total ou +
contidas (< srvr e < 3 cint) (2 - 3 srvr e 3 - 5 cint) (> srvr e > cint)
0 ou 1 simples simples mdio
2 ou 3 simples mdia difcil
4 ou . mdia difcil difcil
NOP New Object Points. Novos Pontos de Objetos contados, ajustados para reuso.
Nmero de servidores (mainftrame ou equivalente) de tabelas de dados usados
Srvr
em conjuno com TELA ou RELATRIO.
Nmero de clientes (estao de trabalho pessoal) de tabelas de dados usados em
Clnt
conjuno com TELA ou RELATRIO.
Porcentagem de telas, relatrios e mdulos 3GL (linguagem de terceira gerao)
%reuso
reusados a partir de aplicaes prvias)

Tabela 5.8 Classificao de pontos de objetos (Jnior & Sanches, 2000)

3. Atribuir um nmero para cada atributo utilizando-se a :

PESO DA COMPLEXIDADE
TIPO DE OBJETO
SIMPLES MDIA DIFCIL
TELAS 1 2 3
RELATRIOS 2 5 8
COMPONENTES 3 GL ... ... 10

Tabela 5.9 Peso de complexidade de pontos de objeto (Jnior & Sanches, 2000)

4. Somar todos os pesos conseguidos para obter os NAPs;

5. Determinar a %REUSO do sistema;
6. Determinar a produtividade segundo a Tabela 7;
7. Determinar o PM segundo a frmula da Figura 4.

Modelo de projeto preliminar

Este modelo pode ser utilizado antes do projeto de arquitetura detalhada do

sistema estar disponvel, mas quando j se tem acordados os requisitos de
usurio, ou seja, em fases iniciais do projeto do software. Tudo isto para gerar
uma estimativa de custo rpida e aproximada no incio do projeto.

118 captulo 5
 A frmula dada a seguir:

PM = A TamanhoB M
PM = Esforo pessoas/ms
Tamanho = dado em KSLOC (kilo source of lines) normalmente uma transforma-
o de pontos de funo para KSLOC. Pode-se utilizar a tabela abaixo para isto no
COCOMO II:

Tabela 5.10 Transformao entre SLOC e Pontos de Funo (Jnior & Sanches, 2000)

LINGUAGEM SLO/UFP LINGUAGEM SLOC/UFP

Ada 71 ANSI Cobol 85 91
Al Shell 49 Fortan 77 105
APL 32 Forth 64
Assembly 320 Jovial 105
Assembly (Macro) 213 Lisp 64
ANSI/Quick/Turbo Basic 64 Modula2 80
Basic Compilado 91 Pascal 91
Basic Interpretado 128 Prolog 64
C 128 Report Genarator 80
C++ 29 Spreadsheet 6
A = Coeficiente com o valor 2,94
B = fator de escala que mostra a economia ou deseconomia de escala e substituem, por exemplo,
os modos de desenvolvimento (orgnico, semidestacado e embutido) do modelo COCOMO original.
Explicado melhor a seguir.
M = Multiplicador baseado em sete atributos de projeto que veremos mais abaixo.

Tabela 5.11 Frmula de esforo do COCOMO II modelo de projeto preliminar (Sommer-

ville, 2011)

O fator de escala B calculado segundo a tabela 5.12 abaixo:

FATORES DE ESCALA
Precedncia
Flexibilidade de desenvolvimento
Arquitetura/Resoluo de risco
Coeso da Equipe
Maturidade do processo

Tabela 5.12 Fator de escala COCOMO II (Sommerville, 2011)

captulo 5 119
 Para cada um desses fatores de escala atribui-se uma nota de 0 a 5, sendo 0
significa extra alto e 5 muito baixo.
Depois de atribuda a nota, soma-se todas as notas, divide-se o resultado por
100 e some a ele 1,01 e ento voc tem o valor de B. (Sommerville, 2011)
J o fator multiplicador M baseado em sete atributos de projeto e proces-
so, a saber:

M = PERS RCPX RUSE PDIF PREX FCIL SCED

PERS Capacidade de pessoal

RCPX Confiabilidade e complexidade do produto
RUSE Reso
PDIF Dificuldade da plataforma
PREX Experincia do pessoal
FCIL Recursos de apoio
SCED Cronograma

Tabela 5.13 Atributos de projeto e processo COCOMO II (Sommerville, 2011)

Os valores para esses atributos devem ser estimados usando uma escala de
seis pontos, em que 1 corresponde a muito baixo e 6 corresponde a mui-
to alto.

Modelo de reso

Este modelo deve ser utilizado quando o projeto utilizar cdigos reaproveita-
do de outros projetos, o que altamente comum nos dias de hoje.
Segundo o COCOMO II h dois tipos de reutilizao de cdigo possveis:
aquela que se reutiliza 100% do cdigo, chamada de reutilizao caixa preta,
na qual o esforo considerado ZERO; e aquela que se adapta um cdigo j
existente para a situao atual, o que conhecido como reaproveitamento de
cdigo de caixa branca.
H tambm a ser considerada as ferramentas que geram cdigo automa-
ticamente por meio de um modelo realizado, como por exemplo ferramentas
de UML e que tambm deve ter um esforo de integrao do cdigo calculado.
(Sommerville, 2011)

120 captulo 5
 Para realizar o clculo de esforo no modelo de reuso a seguinte frmula
deve ser utilizada:

ASLOC AT
PM Auto = 100
ATPROD

Onde:
ASLOC o nmero total de linhas de cdigo reusado, incluindo o cdigo
que gerado automaticamente.
AT a porcentagem de cdigos reusados gerados automaticamente.
ATPROD a produtividade dos engenheiros na integrao do cdigo, que
no COCOMO II foi calculada como sendo 2.400 declaraes-fonte por ms.
(Sommerville, 2011)
Para se chegar ao esforo necessrio para a integrao do cdigo fonte de
outro sistema ao sistema estimado, h a necessidade de se aplicar a frmula
abaixo (Sommerville, 2011):

AT
ESLOC = ALOC 1 AAM
100

Onde:
ESLOC = nmero de linhas equivalente do novo cdigo-fonte
ASLOC = o nmero de linhas de cdigo nos componentes que precisam
ser alterados.
AAM um multiplicador de ajuste de adaptao conforme abaixo:

AAF Componente de adaptao que representa os custos de se alterar o cdigo reusado.

Elemento de compreenso que representa os custos de compreender o cdigo para ser
reusado e a familiaridade do engenheiro com esse cdigo. Varia de 50 para cdigos com-
SU plexos e no estruturados at 10 para cdigos estruturados, bem escritos e orientados a
objeto
Fator de avaliao que representa os custos de tomada de deciso de reuso. Vai de zero
AA a oito, dependendo da quantidade de esforo de anlise necessrios.

Tabela 5.14 Clculo do AAM - multiplicador de ajuste de adaptao - coma dos trs com-
ponentes. (Sommerville, 2011)

captulo 5 121
Modelo de ps arquitetura

Este modelo deve ser utilizado quando um modelo de arquitetura do sistema,

mesmo que preliminar, esteja disponvel e seja capaz de identificar as estru-
turas de subsistemas de forma ser possvel realizar a mensurao de cada um
desses subsistemas.
Ele ser composto por 3 estimativas:
1. Uma estimativa do nmero total de linhas de cdigo novo para ser de-
senvolvido (SLOC).
2. Uma estimativa dos custos de reuso baseado em um nmero equivalen-
te de linhas de cdigo-fonte calculado (ESLOC), usando o modelo de reuso.
3. Uma estimativa do nmero de linhas de cdigo que podem ser modifi-
cadas por causa de alteraes nos requisitos de sistema. (Sommerville, 2011)

Adicionando os valores desses parmetros calcula-se o tamanho total do

cdigo que deve ser utilizado na frmula abaixo (j enunciada anteriormente).

PM = A Tamanho B M

Sendo que a diferena principal aqui que M baseado em 17 atributos de

produto, processo e organizao (que no especificaremos aqui) ao invs dos 7
anteriormente utilizados.

5.4 Modelo de Estimativa de Putnam

Este um modelo dinmico de mltiplas variveis que tem como premissa que
cada fase do processo de desenvolvimento de software apresenta uma determi-
nada distribuio de esforo, conforme mostra a figura 5.5.
Por meio dessas curvas foi possvel estabelecer uma equao de softwa-
re que relacionam linhas de cdigo ao tempo e esforo de desenvolvimento.
(Pressman, Engenharia de Software, 1995)
1
L = CK K 3 t d 34

122 captulo 5
 Denio Projeto funcional, Desenvol-
do sistema especicao vimento Operao e manuteno

(clinte ou (contratante) (clinte)

contratante)
Projeto e Teste e Instalao (um
Fora de trabalho (pessoas/ano)

Projeto funcional, Codicao validao tanto varivel)

Denio especializao
do sistema

Trabalho de Trabalho de modicao e incluses

desenvolvimen- funcionais = 60%
to = 40% do
esforo total
Tempo

Figura 5.5 Distribuio do esforo - grandes fases Software Cost Estimating and Life
Cycle Control, IEEE Computer Society Press, 1980. pg 15 apud (Pressman, Engenharia de
Software, 1995)

Onde:
L = nmero de linhas
Ck = representa restries que impedem o progresso do programador e
pode assumir os valores 2000 para um ambiente de desenvolvimento bastante
imaturo; 8000 para um ambiente de desenvolvimento maduro (com metodolo-
gia, documentao e etc); 11000 para um ambiente excelente (com ferramentas
e tcnicas automatizadas por exemplo).
K = esforo despendido (em pessoas-ano) ao longo de todo o ciclo de vida
para desenvolvimento e manuteno do software. Pode ser dada pela equao:
L3
K=
CK3 t d4

Td = tempo de desenvolvimento em anos

5.5 Estimativa de projetos orientado a

objetos

Ver mtricas orientadas a objetos no captulo 2.

captulo 5 123
5.6 Estimativas com mtodos geis
Segundo Universidade Estcio de S, 2015 um projeto usando um processo
de desenvolvimento gil feito com um conjunto de cenrios de usurios.
possvel desenvolver uma estimativa com razovel significado com os seguin-
tes passos:
1. Cada cenrio de usurio considerado separadamente para a estimativa.
2. O cenrio composto de um conjunto de funes e tarefas de engenha-
ria de software.
3 a. Cada tarefa estimada separadamente.
3 b. O tamanho do cenrio pode ser estimado em LOC, PF ou alguma outra
medida orientada a volume
4.a. As estimativas de cada tarefa so somadas para criar uma estimativa
de cenrio
4.b. O volume de esforo estimado para cenrio traduzido para esforo
baseado em dados histricos
5. As estimativas de esforo para todos os cenrios que devem imple-
mentar um incremento de software so somadas para definir a estimativa para
o incremento.
Normalmente, a durao do desenvolvimento de um incremento da or-
dem de 3-6 semanas; a estimativa serve para garantir que o nmero de cenrios
a ser includo no incremento esteja de acordo com os recursos disponveis.

5.7 Pontos de caso de uso

Vamos aqui analisar os pontos de caso de uso segundo a viso de Martins, GE-
RAO DE PONTOS DE CASOS DE USO NO AMBIENTE SCORPIUS, 2007.
Pensando no processo de desenvolvimento de software estabelecido por
Jacobson et al (1992), chamado Objectory, (Kerner, 1993) prope a mtrica de
tamanho de software Pontos de Casos de Uso (PCU), que baseada na tcnica
Pontos de Funo j estudada por ns anteriormente neste livro.
Os Pontos de Casos de Uso uma estimativa de tamanho/complexidade de
software que se prope a estabelecer uma medida logo nas etapas iniciais do
processo de desenvolvimento.

124 captulo 5
 Posteriormente, por meio de funes de transformao e tabelas de bases
histricas, possvel realizar a transformao desta medida para pontos de
funo e KLOC.
O pontos de caso de uso inicia propondo a contagem do fator Pontos de
Casos de Uso No Ajustados (PCUNA) que computado por meio da classifica-
o de cada ator como simples, mdio ou complexo de acordo com os critrios
definidos na tabela 5.15.

COMPLEXIDADE DEFINIO PESO

Um ator considerado simples se ele representa um outro sistema
SIMPLES com uma interface programvel de aplicao definida.
1

Um ator considerado como mdio se:

1. Ele interage com um outro sistema usando para isso
MDIO um protocolo.
2

2. Ele interage com o sistema atravs de linhas de comando.

Um ator considerado complexo se ele interage com o sistema
COMPLEXO atravs de uma interface grfica com o usurio.
3

Tabela 5.15 Forma de classificao dos atores com seus respectivos pesos (Kerner,
1993)

Na sequncia, cada Caso de Uso tambm deve ser classificado como sim-
ples, mdio ou complexo utilizando para isso o critrio proposto na tabela 5.16.

COMPLEXIDADE DEFINIO PESO

Um Caso de Uso simples se ele tem 3 ou menos transaes incluin-
SIMPLES do aquelas do curso alternativo. Ou seja, deve ser possvel implemen- 5
tar o Caso de Uso usando para isso menos que 5 objetos lgicos.
Um Caso de Uso mdio se ele tem de 3 a 7 transaes incluindo
MDIO aquelas do curso alternativo. Ou seja, deve ser possvel implemen- 10
tar o Caso de Uso usando para isso de 5 a 10 objetos lgicos.
Um Caso de Uso complexo se ele tem mais do que 7 transaes
COMPLEXO incluindo aquelas do curso alternativo. Ou seja, deve ser possvel imple- 15
mentar o Caso de Uso usando para isso mais que 10 objetos lgicos.

Tabela 5.16 Forma de classificao dos Casos de Uso com seus respectivos pesos [Kar-
ner, 1993]

Agora calcula-se a soma dos pesos dos Atores e Caso de Usos utilizando a Equao
1, para se chegar ao fator PCUNA, na qual ni o nmero de itens de variedade i (sim-
ples, mdio e complexo para atores e casos de uso) e Pi o peso dado a variedade de i.
6
PCUNA = ni Pi
i1

Equao 1

captulo 5 125
 Caso haja informaes sobre o ambiente de implementao do projeto e/
ou informaes sobre a complexidade tcnica de se implementar o projeto, os
fatores Fator de Complexidade Tcnica (FCT) e o Fator Ambiental (FA) preci-
sam ser calculados conforme mostra a tabela 5.17.

Fi Fatores que contribuem para a complexidade do sistema Pi

F1 Distribuio do sistema. 2
F2 Resposta aos objetivos de desempenho 1
F3 Eficincia do usurio final. 1
F4 Complexidade do processamento interno. 1
F5 Cdigo deve ser reutilizado 1
F6 Facilidade de instalao 0.5
F7 Facilidade de uso 0.5
F8 Portabilidade 2
F9 Fcil de alterar 1
F10 Concorrncia 1
F11 Feature de segurana 1
F12 Acesso direto a dispositivos de parceiros 1
F13 Treinamento especial aos usurios 1

Tabela 5.17 Fatores que contribuem para a complexidade do sistema [Medeiros, 2004;
Karner, 1993]

13
FCT = C1 + C2 Fi Pi
i1

Equao 2
Onde: C1 = 0.6 e C2 = 0.01.

Para o clculo do FCT preciso realizar a atribuio de uma nota de 0 a 5

para cada um dos fatores presentes na tabela 5.17, sendo que o valor 0 deve
ser atribudo quando o fator for irrelevante para o sistema e o valor 5 deve ser
atribudo para quando o fator for essencial para o sistema, por fim aplique o
resultado na Equao 2.
Para o Fator Ambiental, que um outro fator usado tambm para balancear
o PCUNA, tambm necessrio a atribuio de uma nota entre 0 4 5 para cada
um dos quesitos da tabela 5.18, sendo que 0 considerado para quando o fator
for irrelevante para o sistema e 5 quando o fator for essencial para o sistema,
posteriormente deve-se aplicar o resultado na Equao 3.

126 captulo 5
 Fi Fatores que contribuem para a eficincia Pi
F1 Familiaridade com o Processo de Interativo Unificado 1.5
F2 Experincia na Aplicao 0.5
F3 Experincia com orientao a objeto 1
F4 Capacidade de Liderana de Anlise 0.5
F5 Motivao 1
F6 Estabilidade de Requisitos 2
F7 Consultores Part-Time 1
F8 Dificuldade de Programao na Linguagem 1

Tabela 5.18 Fatores que contribuem para a eficincia (Kerner, 1993)

8
FA = C1 + C2 Fi Pi
i1

Equao 3

Onde: C1 = 0.6 e C2 = 0.01.

Agora podemos chegar ao valor dos Pontos de Casos de Uso (PCU) pela
Equao 4.
PCU = PCUNA FCT FA

Equao 4

Tendo a medida de tamanho/complexidade de Pontos de Casos de Uso cal-

culada, j possvel realizar a estimativa da quantidade de esforo necessria
para a construo de um determinado sistema por meio de uma paramtrica
que segundo (Kerner, 1993), propem pode ser realizada por meio de um fator
de 20 horas homens para o desenvolvimento de cada Ponto de Casos de Uso.
Assim como os pontos de funo, o PCU pode ser usado como dado de en-
trada para algum mtodo de estimativa como o COCOMO ou COCOMO II.

5.8 Gesto do desenvolvimento e projetos de

software usando mtricas

Uma empresa de desenvolvimento de software, juntamente com os seus pro-

jetos, podem ser gerenciados com a ajuda das mtricas que estudamos, mais
especificamente, por exemplo, pontos de funo.

captulo 5 127
 Uma empresa pode querer se medir, e at se comparar com o mercado, por
meio do custo de um ponto de funo produzido por ela. Por exemplo, imagine
uma empresa que mantm um escritrio de gerenciamento de projetos de soft-
ware e quando vende algum projeto contrata pessoal para o desenvolvimento
do software. A tabela abaixo representa o perodo didtico de um determinado
ms da empresa, na qual foram desenvolvidos 200 PFs.

CUSTO TIPO VALOR

ALUGUEL Fixo R$ 5000,00
ENERGIA Fixo R$ 500,00
COMUNICAO Fixo R$ 5500,00
ESCRITRIO Fixo R$ 1000,00
GERENCIAMENTO DOS PROJETOS Varivel R$ 5000,00
DESENVOLVIMENTO DE SOFTWARE Varivel R$ 15000,00

Veja que o custo total da empresa foi de R$ 32000,00. Isto quer dizer que
neste ms cada Ponto de Funo custou 32000/200 = R$ 160,00.
Baseado nisso, possvel inclusive determinar o ponto de equilbrio dessa
empresa, que quanto o custo da empresa empata com a receita da empresa.
Imagine que esta empresa cobre R$ 150,00 para cada ponto de funo de-
senvolvido e entregue ao cliente. Ento diramos que a equao de lucro seria
dada por:

Lucro = 150*#PF_desenvolvido ( Custo Fixo + Custo_Varivel_Unitrio * PF_desenvolvido)

Onde:
#PF_desenvolvido a quantidade de pontos de funo entregue.

Custo varivel unitrio o custo varivel pago para o desenvolvimento de

1 ponto de funo, no nosso exemplo ele seria de (R$ 5000 + R$ 15000)/200 =
R$100/pf.
Ento, no caso do ms do exemplo acima, diramos que a frmula de
Lucro seria:

Lucro = 150*200 (12000 + 100*200) = 30000 32000 = 2000

128 captulo 5
 Como pde ser visto, a empresa teve um prejuzo de R$ 2.000,00. Ento qual
seria o ponto de equilbrio para esta empresa? Na verdade, a pergunta certa se-
ria: qual a quantidade mensal de pontos de funo que a empresa deve desen-
volver para que ela tenha lucro ZERO -> este o ponto de equilbrio, e poderia
ser alcanado da seguinte forma:

150*PF (12000+100*PF) = 0
150PF 12000 100PF = 0
50PF = 12000
PF = 12000/50
PF = 240.

Ou seja, necessrio a empresa produzir 240 pontos de funo mensais

para que ela alcance o seu ponto de equilbrio fazendo com que as receitas
igualem o lucro. O comportamento da equao de ponto de equilbrio pode ser
visualizado na figura 5.6.
Alm do ponto de equilbrio da empresa, por meio das mtricas de
PF produzidas e com uma base histrica coletada da empresa possvel
determinar/gerenciar:
1. Desempenho de times de desenvolvimento.
2. Custos de desenvolvimento por PF e por hora.
3. Custos e eficincias por processo de desenvolvimento.
4. Verificar a qualidade das estimativas comparando o estimado com
o executado.
5. Outros.

PF
PF produzida

Lucro Custo total

Prejuzo Ponto de Custo varivel

equilibrio em PF

Custo xo
PF.custo.xo
Tempo

Figura 5.6 Ponto de equilbrio em PF (Universidade Estcio de S, 2015)

captulo 5 129
5.9 Anlise do valor agregado
Estimar projetos de qualquer natureza fundamental para o planejamento.
Contudo, o plano feito para ser seguido e identificar desvios, de forma que
no adiantam as estimativas para o planejamento se no houver acompanha-
mento (monitoramento e controle) da execuo.
(PMI, 2013) indica a tcnica de EVA (gerenciamento do valor agregado) para
o monitoramento de controle do projeto no que tange a escopo, tempo e custo.
Abaixo seguem as frmulas para o EVA.
Os indicadores mais interessantes que podemos explorar da Figura 9 para o
contexto em questo o CPI e o SPI que indicam, respectivamente, se o projeto
est dentro do oramento e dentro do cronograma.
Para esses indicadores UM quer dizer que est tudo certo, ou seja, um CPI
UM significa que o projeto est dentro do oramento e para cada R$ 1,00 gasto,
R$ 1,00 est sendo convertido dentro do projeto, da mesma forma um SPI 1
indica que o cronograma est dentro do esperado.

NOME
PLANED VALUE (PV)
EARNED VALUE (EA)
ACTUAL COST (AC)
BUDGET AT COMPLETION (BAC)
ESTIMATE AT COMPLETION (EAC)
ESTIMATE TO COMPLETE (EC)
VARIANC AT COMPLETIO (VAC)
COST VARIANCE (CV)
SCHEDULE VARIANCE (SV)
COST PERFOMANCE INDEX (CPI)
SCHEUDULE PERFOMANCE INDEX (SPI)
DESCRIO
Quanto de trabalho deveria ser feito
quanto trabalho foi feito em relao ao que foi
planejado
Quanto custou o que foi planejado para o traba-
lho total
Qual o oramento planejado para o trabalho total
Com os dados de progresso atuais, quanto se es-
pera que ser o custo total do trabalho (frmula:
BAC/CPI)
Com os dados de progresso atuais, qanto mais ir
ser gasto at o final do projeto (frmula: EAC AC)
Qual o valor acima/baixo do planejado espera-se
consumir at o final do projeto (fmula: BAC
EAC)
Comparao entre o valor estimado para o traba-
lho e o custo atual (frmula: EV AC)
Comparao entre o trabalho realizado e o plane-
jado para o momento atual (frmula: EV PV)
ndice que verifica se o projeto est dentro ou
fora do oramento (frmula: EV/AC)
ndice que verifica se o projeto est dentro ou
fora do crongrama (frmula: EV/PV)

Tabela 5.19 Indicadores do mtodo EVA (da Silva, Tincani, Camargo, & Jnior, 2013)

130 captulo 5
 Caso o CPI seja menor que UM, ento isto significa que o projeto est gas-
tando mais do que previsto. Da mesma forma um SPI menor que UM significa
que o projeto est indo mais devagar do que o previsto.
J no caso do CPI ser maior do que UM, isto significa que o projeto est gas-
tando menos do que o previsto (opa, cuidado com a qualidade ento). E da mes-
ma forma caso o SPI seja maior do que UM, ento quer dizer que o projeto est
indo mais rpido do que o previsto (mais uma vez, cuidado com a qualidade).

5.10 Estimativas estatsticas

Vimos at agora bastante frmulas, equaes, mtodos para realizar medidas e
estatsticas. Muitas vezes dissemos que essas frmulas e equaes derivam de
observaes e um conjunto de dados que posteriormente so extrapolados para
outros projetos de forma geral, mas como isto feito?
Uma das formas de se fazer isso utilizando modelos empricos de estima-
tiva, que segundo (Pressman, 1995) pode ser dos seguintes tipos:
Modelo estatstico de varivel simples: que toma o seguinte formato
o Recurso = c1 X (caractersticas estimadas)c2

O modelo COCOMO original um exemplo deste tipo de estimativa.

Modelo estatstico de mltiplas variveis que assume a forma
o Recurso = c11 e 1 + c21 e 2 + ...

Modelo dinmico de mltiplas variveis, que assume que os requisitos

de recurso em funo do tempo, como o modelo de estimativa de Putman.

Outra forma que os engenheiros costumam utilizar coletar uma base his-
trica daquilo que se quer modelar e posteriormente plotar os dados em um
grfico bidimensional e por meio de tcnicas matemticas gerar uma equao
que modela uma curva que mais se aproxima da nuvem de pontos plotada. Por
exemplo, veja a tabela 5.20 a seguir e se concentre nas colunas de TOTAL de PF
estimados e Homem Horas trabalhados.

captulo 5 131
 TOTAL PF HOMEM HORAS
PROJETO TOTAL PF ESTIMADO PRAZO (DIAS UTEIS)
REALIZADO TRABALHADAS
MDULO DE PONTO 82,45 112,2 2400 40
SISTEMA ESTOQUE 180,90 179,34 8400 70
GESTO DE VENDAS 198,90 215 9600 160
CONTROLE DE 268,30 265,2 7200 180
TRAFEGO
SISTEMA 431,45 420,78 9600 160
ACADMICO
Tabela 5.20 Exemplo didtico de base histrica (Universidade Estcio de S, 2015)

Se plotssemos o total de PF estimado vs Homem horas trabalhadas em

um grfico, teramos a figura 5.7.

Homem* horas trabalhadas

12000

10000

8000

6000

4000

2000

0
100 200 300 400 500
0
Homem* horas trabalhadas

Figura 5.7 Grfico PF estimado vs Homem*horas trabalhados (Universidade Estcio de

S, 2015)

CONCEITO
Interpolao
O problema da interpolao consiste em substituir funes intricadas por um conjunto de
funes mais simples, de tal forma que muitas operaes comuns como a diferenciao e a
integrao, possam ser realizadas mais facilmente. A interpolao consiste basicamente em
encontrar uma funo que seja a expresso lgica de determinados pontos de uma funo

132 captulo 5
desconhecida, ou seja, conhecendo-se (x1 , y1), (x2 , y2).....(xn , yn) de uma funo desconhe-
cida poderemos calcular o valor numrico intermedirio da funo num ponto no tabelado
com certo grau de erro.
Outra aplicao da interpolao a aproximao de funes complexas por funes
mais simples. Suponha que tenhamos uma funo, mas que seja complicada demais para
que seja possvel avali-la de forma eficiente. Podemos, ento, escolher alguns dados pon-
tuais da funo complicada e tentar interpol-los com uma funo mais simples. Obviamente,
quando utilizamos a funo mais simples para calcular novos dados, normalmente no se
obtm o mesmo resultado da funo original, mas dependendo do domnio do problema e do
mtodo de interpolao utilizado, o ganho de simplicidade pode compensar o erro. (Universi-
dade Estcio de S, 2015)

Caso para o grfico acima decida-se modela-lo por meio de uma curva li-
near, o que possvel, veja pela figura 5.8 que o erro pode ser enorme, ou seja,
estes nmeros no podem ser representados por uma simples regresso linear
(polinmio do primeiro grau).

Homem* Horas Trabalhadas

12000

10000

8000

6000

4000

2000

0
0,00 100,00 200,00 300,00 400,00 500,00

Srie 1 Linear (Srie 1)

Figura 5.8 Grfico modelado de forma linear (Universidade Estcio de S, 2015)

captulo 5 133
 CONCEITO
Interpolao Linear
Em matemtica, denomina-se interpolao linear o mtodo de interpolao que se utiliza de
uma funo linear p(x) (um polinmio de primeiro grau) para representar, por aproximao,
uma suposta funo f(x) que originalmente representaria as imagens de um intervalo des-
contnuo (ou degenerado) contido no domnio de f(x). (Wikipedia, 2015).

Caso para o grfico acima decida-se modela-lo por meio de uma curva li-
near, o que possvel, veja pela figura 5.9a que o erro pode ser enorme, ou seja,
estes nmeros no podem ser representados por uma simples regresso linear
(polinmio do primeiro grau).
Porm, se representarmos a curva utilizando uma interpolao em uma cur-
va de segundo grau ou logartmica correremos menos risco, conforme pode ser
observado nos grficos da figura 5.9b.

Homem* horas trabalhadas

12000

10000

8000

6000

4000

2000

0
0 100 200 300 400 500
Homem* horas trabalhadas
Polinmio (homem* horas trabalhadas)

134 captulo 5
 Ttulo do Grco
12000

10000

8000
Ttulo do Eixo

6000

4000

2000

0
0,00 100,00 200,00 300,00 400,00 500,00
Ttulo do Eixo
Srie 1 Logaritimo (Srie 1)

Figura 5.9 Nmeros modelados por curva de segundo grau e logartmica (Universidade
Estcio de S, 2015)

CONEXO
Interpolao
Quer saber mais sobre interpolao? Ento acesse: http://estaciodocente.webaula.com.
br/Cursos/gra104/docs/09MEDS_doc01.pdf

Por mais prximo que a curva modelada tenha chegado dos nmeros reais
e dos pontos de amarrao, em uma interpolao ainda haver a presena de
erros. H vrios processos matemticos que podem ser utilizados para tratar
os erros em interpolaes, mas para simplificarmos o assunto, o que pode ser
feito determinarmos curvas de erro limites mximo e mnimo e manter a cur-
va modelada entre as duas. Conforme mais base histrica for coletada, menor
ser a distncia entre as duas curvas de mximo e mnimo.

captulo 5 135
 ATIVIDADES
01. O que o COCOMO e quais tipos de COCOMO existem?

02. Por que foi necessrio o desenvolvimento do COCOMO II?

03. Se um projeto tem o SPI = 1,5 e o CPI = 0,9, o que podemos dizer dele?

04. Explique o que significa ponto de equilbrio e como ele pode ser calculado para uma
empresa de desenvolvimento de software utilizando o PF.

REFLEXO
Agora sim, parabns em definitivo! Voc conseguiu chegar ao final da disciplina percorrendo
os 5 captulos propostos.
Neste ltimo captulo, tambm o seu ltimo desafio da disciplina, voc aprendeu tcnicas
importantes e consagradas de estimativa de sistemas, como o COCOMO e o COCOMO II,
alm tambm de ter tomado conhecimento sobre controle de projetos de software com o
EVA, algumas tcnicas estatsticas e etc.
Esperamos que o que voc tenha aprendido aqui na disciplina seja bastante til no s
no contexto acadmico, mas tambm na sua carreira profissional e que voc consiga aplicar
com xito tudo o que aprendeu sobre estimativa e medidas de esforo de desenvolvimento
de software.

LEITURA
Para fechar com chave de ouro esta disciplina recomendamos fortemente que voc leia o
relatrio tcnico do ICMC de So Carlos sobre a tcnica COCOMO. um estudo bastante
interessante e detalhado da tcnica que poder fazer o seu entendimento sobre o assunto
muito mais apurado e refinado.
Jnior, W. T., & Sanches, R. (2000). Modelos de Estimativas de Custo de Software - RE-
LATRIOS TCNICOS DO ICMC. So Carlos. Acesso em 30 de 08 de 2015, disponvel em:
http://www.icmc.usp.br/CMS/Arquivos/arquivos_enviados/BIBLIOTECA_113_RT_106.pdf

136 captulo 5
 REFERNCIAS BIBLIOGRFICAS
Boehm, B. (1981). Software Engineering Economics. New Jersey: Prentice Hall.
da Silva, L., Tincani, D., Camargo, M., & Jnior, A. (2013). Marketing Estratgico - Mdulo 4.2.
Ribeiro Preto: Uniseb Interativo.
Fernandes, A. A. (1995). Gerncia de Software atravs de mtricas: garantindo a qualidade do
projeto, processo e produto. So Paulo: Atlas.
Jnior, W. T., & Sanches, R. (2000). Modelos de Estimativas de Custo de Software - RELATRIOS
TCNICOS DO ICMC. So Carlos. Acesso em 30 de 08 de 2015, disponvel em http://www.icmc.usp.
br/CMS/Arquivos/arquivos_enviados/BIBLIOTECA_113_RT_106.pdf
Kerner, G. (1993). Use Case Points: resource estimation for Objectory projects. Objective Systems SF
AB (copyright owned by Rational/IBM).
Martins, M. D. (2007). GERAO DE PONTOS DE CASOS DE USO NO AMBIENTE SCORPIUS.
Dissertao de mestrado. So Carlos, So Paulo, Brasil.
PMI. (2013). Um guia de conhecimento em gerenciamento de projetos. Pennsylvania: Project
Management Institute Inc.
Pressman, R. (1995). Engenharia de Software. Sao Paulo: Pearson Makron Books.
Pressman, R. (2011). Engenharia de Software - Uma abordagem profissional. So Paulo: McGraw
Hill - ARTMED.
Sommerville, I. (2011). Engenharia de Software. So Paulo: Pearson.
Universidade Estcio de S. (30 de 08 de 2015). Mais sobre modelos usados para classificar
o tipo do software. Fonte: Notas de aula de Medidas de Esforo de Desenvolvimento de Software:
http://estaciodocente.webaula.com.br/Cursos/gra104/docs/06MEDS_doc02.pdf
Wikipedia. (30 de 08 de 2015). Interpolao linear. Fonte: Interpolao linear: https://pt.wikipedia.
org/wiki/Interpola%C3%A7%C3%A3o_linear

captulo 5 137
 GABARITO
Captulo1

01.
NOME DA MTRICA Velocidade de desenvolvimento
Verificar a velocidade de desenvolvimento de um determinado time em
OBJETIVO DA MTRICA para a release de uma determinada verso do software
Determinar a quantidade de pontos de funo desenvolvido por tempo de
DESCRIO DA MTRICA esforo executado
SISTEMA DE MEDIDAS PF/horas
Medida 1 medir os pontos de funo do release que foi desenvolvido
pelo time.
FORMAS DE SE OBTER A Medida 2 medir a quantidade total de horas que o time trabalhou
MEDIDA na release.
Realizar a razo: medida 1 / medida 2.

02. Uma medida direta a mais comuns e mais fcil de ser conseguida. So aqueles que
medem diretamente um fenmeno, como por exemplo esta que usamos no exemplo anterior:
a altura de um lpis.
J as medidas indiretas so aquelas que conseguimos por meio de outras, como por exemplo
medir a qualidade de um software por meio da quantidade de tempo que ele fica sem travar,
ou ainda medir a velocidade de desenvolvimento por meio da quantidade de linhas de cdigo
que o desenvolvedor produz por hora.
03. Tamanho de um prdio, velocidade de um carro, profundidade de um rio.
04. Qualidade de software, tamanho do software por meio de medidas de complexidade
funcional, qualidade do cdigo por meio da medida de complexidade do cdigo.
05. No mundo dos softwares a maioria das medidas que encontraremos so do tipo indire-
tas e (Pressman, Engenharia de Software, 2006) faz uma discusso em seu livro sobre o uso
dessas medidas afirmando que h uma classe de profissionais dentro da engenharia de soft-
ware que entende que medir aspectos de software atualmente seria medir o no-mensur-
vel e que seria interessante que a comunidade de desenvolvimento de sistemas aguardasse
que a cincia entendesse melhor o software e os aspectos que deveriam ser medidos antes
de tentar realizar medidas no diretas ou menos absolutas (mais imaturas).
Contudo, o prprio autor afirma que isto um erro por que mesmo sendo as mtricas
de software no absolutas em sua grande maioria, elas ainda so apoiadas em um conjunto

138 captulo 5
de regras bem definidas que oferecem uma forma sistemtica de avaliar, por exemplo, pro-
dutos de software e outras aspectos do desenvolvimento possibilitando um entendimento
de imediato sobre a situao do software (ou desenvolvimento) ao invs de a posteriori, o
que permite que o engenheiro de software possa tomar aes (apoia a tomada de deciso)
precocemente em relao ao produto e ao desenvolvimento de software.
E esta posio de (Pressman, Engenharia de Software, 2006) que adotaremos na dis-
ciplina e neste livro. Entendemos que s podemos gerenciar o que medimos e por mais no
absoluta ou indireta que uma mtrica possa ser desde que ela seja baseada em um conjunto
de regras claras e possa trazer apoio tomada de deciso e evoluo do processo de
desenvolvimento ser algo possvel de ser utilizada dentro do desenvolvimento de sistemas.
06.
a) Privada
NOME DA MTRICA Defeitos por indivduo
Identificar a quantidade de defeitos que um individuo da equipe de desen-
OBJETIVO DA MTRICA volvimento de software esta gerando para poder melhorar a sua atuao
dentro do time e do processo.
Estabelecer a quantidade de defeitos identificados por milhares de linhas
DESCRIO DA MTRICA de cdigo desenvolvidas.
KLOC = milhares de linha de cdigo (nmero real com uma casa deci-
SISTEMA DE MEDIDAS mal) e # de defeitos (nmero de defeitos nmero inteiro).
Medida 1 Linhas de cdigo: Realizar a contagem da quantidade de
NOVAS linhas de cdigo geradas no pacote pelo indivduo e divid-las por
1000 para gerar KLOCs.
FORMAS DE SE OBTER A Medida 2 Contar a quantidade de novos defeitos somada a quanti-
MEDIDA dade de erros crticos antigos que deveriam ter sido consertados pelo
indivduo, mas persistiram.
Realizar a razo: medida 2 / medida 1.

b) Pblica
NOME DA MTRICA Tamanho de funcionalidade
Identificar o tamanho de uma funcionalidade a ser desenvolvida para
OBJETIVO DA MTRICA entender o seu grau de complexidade e posteriormente estimar o tempo
para o seu desenvolvimento.
Contagem de quantidade de classes e entidades de dados que sero
DESCRIO DA MTRICA construdas para a funcionalidade.
SISTEMA DE MEDIDAS Nmero inteiro
Medida 1 Estimativa de quantidade de classes.
FORMAS DE SE OBTER A Medida 2 Estimativa de quantidade de entidades de dados.
MEDIDA A mtrica dever ser formada pela soma da medida 1 com a 2.

captulo 5 139
 c) Privada
NOME DA MTRICA Quantidade de linhas de cdigo por indivduo
Determinar a velocidade de desenvolvimento de um determinado indivi-
OBJETIVO DA MTRICA duo do time;
Contagem de milhares de linhas de cdigo que o indivduo desenvolve
DESCRIO DA MTRICA por semana.
KLOC = milhares de linha de cdigo (nmero real com uma casa
SISTEMA DE MEDIDAS decimal)
A cada semana contar a quantidade de linhas de cdigo novas e alte-
FORMAS DE SE OBTER A radas que um determinado indivduo do time deposita no repositrio de
MEDIDA cdigo do sistema em questo

d) Pblica
NOME DA MTRICA Quantidade de classes por requisitos
Identificar a complexidade mdia de um requisito por sua quantidade de
OBJETIVO DA MTRICA classes;
Nmero que indica a quantidade de classes que foi desenvolvida para
DESCRIO DA MTRICA atender a um determinado requisito.
SISTEMA DE MEDIDAS Nmero inteiro
Contar a quantidade de classe desenvolvida ou alterada para se perfor-
FORMAS DE SE OBTER A mar um determinado requisito documentado no documento de requisitos
MEDIDA do projeto.
07.
INDIRETA: por que consegue a facilidade de uso por meio de uma outra medida que o
tempo que o usurio leva para executar uma determinada funo.
NOME DA MTRICA Facilidade de uso do sistema
OBJETIVO DA MTRICA Determinar se um produto de software fcil de usar ou no.
Entender o tempo mdio que um usurio leva para executar qualquer
DESCRIO DA MTRICA atividade do sistema.
SISTEMA DE MEDIDAS Nmero inteiro em segundos
Solicitar trs atividades aleatrias no sistema para trs usurios
diferentes e calcular o tempo de cada uma das execues, soma-los e
FORMAS DE SE OBTER A depois dividir por 9. Caso a mdia de maior do que 90 segundos, ento
MEDIDA o sistema no tem uma boa usabilidade, caso contrrio ele tem uma boa
usabilidade.

DIRETA: pois conta as classes diretamente.

NOME DA MTRICA Quantidade de classes por requisitos
Identificar a complexidade mdia de um requisito por sua quantidade de
OBJETIVO DA MTRICA classes;
Nmero que indica a quantidade de classes que foi desenvolvida para
DESCRIO DA MTRICA atender a um determinado requisito.
SISTEMA DE MEDIDAS Nmero inteiro
Contar a quantidade de classe desenvolvida ou alterada para se perfor-
FORMAS DE SE OBTER A mar um determinado requisito documentado no documento de requisitos
MEDIDA do projeto.

140 captulo 5
DIRETA: pois conta as linhas de cdigo diretamente
NOME DA MTRICA Quantidade de linhas de cdigo por classe
OBJETIVO DA MTRICA Determinar o tamanho de uma classe;
DESCRIO DA MTRICA Contagem de milhares de linhas de cdigo que uma classe possui.
KLOC = milhares de linha de cdigo (nmero real com uma casa deci-
SISTEMA DE MEDIDAS mal) da classe
FORMAS DE SE OBTER A A cada classe contar a quantidade de linha de cdigo que ela possui.
MEDIDA

Captulo2

01. Como j estudamos, uma mtrica pode ser entendida como um conjunto de medidas
diretas e/ou indiretas que se aplica em algo segundo um procedimento utilizando padro e
sistemas para a medida. Portanto, entende-se que uma medida deva acontecer em algo que
j exista.
J uma estimativa uma previso que se faz sobre algo futuro baseando-se, principalmente,
em bases de medidas histricas.
Existem algumas tcnicas generalistas de projeto para se realizar estimativas, uma das
mais utilizadas a tcnica paramtrica, na qual utiliza-se uma base histrica de informaes
paramtricas normalizadas para se calcular a estimativa em questo. Por exemplo, um pe-
dreiro sabe que no passado ele possui a performance de instalar 1 metro quadro de piso por
hora (base histrica normalizada por hora), se agora ele precisa instalar 10 metros quadrados
a estimativa que se faz (utilizando uma paramtrica proporcional a mais comum) de que
ele demorar 10 horas para instalar. Isto tambm extensvel para a estimativa de custo,
sendo que se ele cobrar R$ 100,00 por metro quadrado ento o total ser de R$ 1000,00.
02. Segundo (Pressman, 1995) todas as engenharias realizam medies e isto de extre-
ma importncia nessas disciplinas e na engenharia de software o contexto no diferente
e, conforme mostramos no tpico anterior, a necessidade de se medir se mostra importante
tambm. (Pressman, 1995) se justifica utilizando o trecho abaixo de Lorde Kelvin:

Quando se pode medir aquilo sobre o qual se est falado e express-lo em nmeros,
sabe-se alguma coisa sobre o mesmo; mas quando no se pode medi-lo, quando no
se pode express-lo em nmeros, o conhecimento que se tem de um tipo inade-
quado e insatisfatrio; este pode ser o comeo do conhecimento, mas dificilmente
algum ter avanado em suas ideias para o estgio de cincia.

captulo 5 141
 importante que voc entenda que apesar da grande maioria das mtricas que utilizaremos
na engenharia de software ser mtricas no absolutas e indiretas, o processo de mensurao
realmente muito importante para que o engenheiro de software possa melhor se guiar na
rdua misso de estabelecer um processo de desenvolvimento de qualidade, maduro e que
evolua constantemente com o objetivo de gerar produtos de software que sejam de qualida-
de e que de fato agreguem valor ao usurio final.
Portanto, deste ponto em diante, queremos dizer, nos prximos captulos, o que faremos
entender quais tipos de mtricas podem existir na engenharia de software de uma forma
geral, apresentar as mtricas de medidas de esforo de desenvolvimento de software, que
so o objetivo desta disciplina e nos aprofundarmos nesta tcnica, tanto no entendimento
das mesmas quanto em como aplica-las no processo de desenvolvimento de software.
J bom adiantar que a grande maioria dessas mtricas de esforo de desenvolvimento
de software so indiretas e no absolutas e que por muitos momentos iremos nos perguntar:
esta medida realmente exata?;Vale a pena a mensurao de algo que no conseguimos
garantir valores absolutos?. Toda vez que esta dvida atentar os nossos estudos pediremos
a voc que volte neste captulo 1 e refaa a leitura das discusses que tivemos e volte a
entender que s podemos gerenciar aquilo que medimos e se queremos de alguma forma
gerenciar o desenvolvimento de software, ento, bom que passemos a medi-lo, e se esta
a forma que conhecemos hoje, ento ser ela que utilizaremos.
03.

SIMPLES MDIO COMPLEXO TOTAL

ALI 0 7 5 10 0 15 50
AIE 0 5 5 7 0 10 35
SE 0 4 10 5 0 7 50
CE 0 3 10 4 0 6 40
EE 0 3 10 4 0 6 40
TOTAL 215

142 captulo 5
04.

CGS PESO ATRIBUDO CGS PESO ATRIBUDO

Comunicao de dados 3 Atualizao on-line 2
Processamento Processamento
2 3
distribudo complexo
Desempenho 3 Reutilizao de cdigo 2
Configurao altamente Facilidade de
2 3
utilizada implantao
Volume de transaes 3 Facilidade operacional 2
Entrada de dados
2 Mltiplos locais 3
on-line
Eficincia do usurio Facilidade de
3 2
final mudanas

TOTAL 30

VFA = (30 * 0,01) + 0,65 = 0,95

05. A situao colocada no exerccio anterior nos leva a entender que quanto mais prximo
de 1 o VFA for, menor o seu impacto, ou seja, quanto mais prxima a avaliao de cada
item do TGI for de 2,5, menor o impacto. Quanto maior de 2,5, maior o impacto aumentando
o ponto de funo ajustado. Quanto menor de 2,5 maior o impacto diminuindo o pondo de
funo ajustado em relao ao ponto de funo no ajustado.
06.

SIMPLES MDIO COMPLEXO TOTAL

ALI 3 7 2 10 1 15 50
AIE 6 5 4 7 2 10 35
SE 5 4 1 5 1 7 50
CE 10 3 3 4 2 6 40
EE 15 3 10 4 5 6 40
TOTAL 335
Pontos de funo no ajustados = 335
TGI = 43
VFA = (43*0,01)+0,65 = 1,08
Pontos de funo ajustados (projeto de desenvolvimento) = PFNA * VFA = 335 * 1,08 =
361,08 pontos de funo.

captulo 5 143
Captulo3

01.

SIMPLES MDIO COMPLEXO TOTAL

ALI 4 7 1 10 2 15 50
AIE 10 5 3 7 1 10 35
SE 6 4 3 5 2 7 50
CE 10 3 4 4 3 6 40
EE 13 3 8 4 5 6 40
TOTAL 367
PFNA = 367
TGI = 42
VFA = (42*0,01)+0,65 = 1,07
Pontos de funo ajustados (projeto de desenvolvimento) = PFNA * VFA = 367 * 1,07 =
392,69 pontos de funo.
Esforo = 15 * 392,69 = 5890,35
Custo = 5.890,35 * 150 = R$ 883.552,50
02.
03.

SIMPLES MDIO COMPLEXO TOTAL

ALI 5 7 2 10 6 15 50
AIE 15 5 5 7 2 10 35
SE 5 4 5 5 5 7 50
CE 8 3 3 4 2 6 40
EE 11 3 13 4 4 6 40
TOTAL 512
PFNA = 512
TGI = 70
VFA = (70*0,01)+0,65 = 1,35
Pontos de funo ajustados (projeto de desenvolvimento) = PFNA * VFA = 512 * 1,35 =
691,12 pontos de funo.
Mdia de LOC/PF em COBOL = 77 LOC/PF
Quantidade de LOC estimada = 53216,24 LOCS
Velocidade de desenvolvimento dada = 0,05 horas/LOC
Esforo em horas estimado = 0,05 * 53216,24 = 2660,81 horas
Custo = 2.660,81 * 250 = R$ 665.203,00

144 captulo 5
04. Um ALI no pode ser:
Arquivos temporrios.
Arquivos de trabalho.
Arquivos de classificao.
Arquivos de cpia de segurana requerido pelo CPD.
Arquivos introduzidos somente por causa da tecnologia usada.
Ex.: Arquivos de parmetro para um software WFL, JCL etc.
Operaes de juno e projeo.
Arquivos de ndices alternativos. (Vazques, Simes, & Albert, 2005)
Um ALI pode ser:
Tabelas que armazenam dados mantidos pela aplicao;
Arquivos de configurao mantidos pela aplicao;
Arquivos de segurana de acesso aplicao (senhas), mantidos por ela;
Arquivos mantidos no s pela aplicao, mas tambm por outra aplicao.
Uma AIE no pode ser:
Arquivos de movimento recebidos de outra aplicao para manter um ALI (exemplos: arqui-
vos de remessa e retorno). No entanto os processos de carga e de gerao destes arquivos
podem ser funes do tipo transao. O arquivo de movimento simplesmente um relatrio
gerado em formato de arquivo texto.
Dados mantidos pela aplicao e utilizados por outra aplicao;
Dados formatados e processados para uso de outras aplicaes. (Vazques, Simes, & Al-
bert, 2005)
Um AIE pode ser:
Dados de referncia externos utilizados pela aplicao. (Vazques, Simes, & Albert, 2005)
Para uma funo ser identificada como um AIE:
O grupo de dados ou informao de controle logicamente relacionado e identificvel
pelo usurios;
O grupo de dados referenciado pela aplicao sendo contada, porm externo a ela.
O grupo de dados no mantido pela aplicao sendo contada.
O grupo de dados mantido por outra aplicao, isto , deve ser um ALI para a outra apli-
cao. (Vazques, Simes, & Albert, 2005)
05. Sim, h outros trabalhos como o COCOMO e COCOMO II que buscam realizar a estima-
tiva de esforo sem utilizar uma paramtrica proporcional.

captulo 5 145
Captulo4

01.
INTERVALO INTERVALO
ESTIMATIVA ESTIMATIVA
SIGMA DEP D. PADRO VAR PROJETO
PROJETO PROJETO
(MENOR) (MAIOR)
1 170,17 10,06 101,2 91,14 111,26
2 170,17 10,06 101,2 81,08 121,32
4 170,17 10,06 101,2 60,96 141,44
6 170,17 10,06 101,2 40,84 161,56

02.

INTERVALO DE ESTI- INTERVALO DE

D. PAD
ATV P M O DEA VAR ATV MATIVA (MENOR) 1 ESTIMATIVA (MAIOR)
ATV
SIGMA SIGMA
A 80 70 20 63 10,00 100,00 53,33 73,33
B 90 88 80 87 1,67 2,78 85,33 88,67
C 85 60 50 63 5,83 34,03 56,67 68,33
D 40 32 30 33 1,67 2,78 31,33 34,67

INTERVALO INTERVALO
ESTIMATIVA ESTIMATIVA
SIGMA DEP D. PADRO VAR PROJETO
PROJETO PROJETO
(MENOR) (MAIOR)
1 245,83 11,81 234,02 257,65 111,26
2 245,83 11,81 222,20 269,46 121,32
4 245,83 11,81 198,58 293,09 141,44
6 245,83 11,81 174,95 316,72 161,56
03. Poderia utilizar os pontos de funo para fazer estimativas de um ponto pela tcnica
paramtrica ou de trs pontos pela mesma tcnica paramtrica, sendo que esta ltima mais
indicada por que minimiza o risco do cronograma de projetos.
04. A tcnica mais precisa a paramtrica, principalmente quando apoiada em uma base
histrica de qualidade. Ela mais precisa do que a anloga por que esta ltima considera
projetos e atividades que so parecidas (e no iguais) de forma que uma estimativa baseada
nessa premissa de semelhana pode trazer altos nveis de erro justamente por que ser seme-
lhante no ser igual. Alm disso a anloga utilizada, usualmente, com a tcnica top-down
a qual tambm tem um alto grau de erro.
05. Em desenvolvimento de software seria interessante utilizar o pontos de funo com a
tcnica de 3 pontos. Tambm poderia ser utilizado o pontos de caso de uso. Em desenvol-
vimento gil, comum o uso de pontos de histria de usurio. Todos esses poderiam ser
utilizados juntamente com a tcnica de 3 pontos.

146 captulo 5
06. Tcnica de estimativa anloga.
07. Foi utilizada a tcnica paramtrica de um ponto. Para maior segurana seria interessan-
te o uso da mesma tcnica paramtrica, porm, utilizando os 3 pontos. Assim consegue-se
um intervalo de estimativa no qual a chance de acerto aumenta, diminuindo assim o risco
do cronograma.

Captulo5

01. O COCOMO, que significa COnstructive COst MOdel (modelo de custo construtivo) foi
criado por Barry Boehm em 1981 (Boehm, 1981) de fato uma hierarquia de estimativas
que busca realizar a estimativa de esforo e durao baseada em um modelo estatstico de
uma s varivel.
A hierarquia prev 3 tipos de estimativas, a saber:
1 Modelo bsico: modelo estatstico simples que computa o esforo (custo) por meio
de uma funo paramtrica simples baseada apenas no tamanho do software. (Pressman,
Engenharia de Software, 1995)
2 Modelo intermedirio: modelo estatstico que computa o esforo de desenvolvimento
baseado no tamanho (como no poderia deixar de ser) e tambm baseado em direciona-
dores de custo que incluem avaliaes subjetivas de: produto, hardware, pessoal e outros
atributos do projeto. (Pressman, Engenharia de Software, 1995)
3 Modelo avanado: modelo estatstico que junta composto por tudo o que falou-se
nos modelos bsicos e intermedirios e ainda j uma avaliao do impacto dos direcionado-
res de custo sobre cada passo do processo de engenharia de software, a saber: engenharia
de requisitos, projeto, implementao e etc). (Pressman, Engenharia de Software, 1995)
Para cada um dos modelos acima h uma frmula/procedimento de clculo.
02. O COCOMO II uma evoluo do COCOMO de 1981 e leva em considerao abor-
dagens mais modernas para o desenvolvimento de software que agora usam linguagens
dinmicas, componentizao e desenvolvimento em banco de dados (Sommerville, 2011).
E tambm incorporou um conjunto de submodelos capaz de produzir estimativas mais deta-
lhadas, a saber:
Um modelo de composio de aplicao;
Um modelo de projeto preliminar;
Um modelo de reuso;
Um modelo de ps arquitetura.

captulo 5 147
03. que para cada uma unidade monetria investida no projeto h um retorno de 0,9 unida-
des monetrias (ou seja, esta custando mais caro do que o esperado) e que para cara uma
unidade de tempo investida o projeto anda 1,5 unidades de tempo (ou seja, esta andando
mais rpido do que o esperado).
04. ponto de equilbrio: momento em que o custo da empresa empata com a receita da
empresa, levando-se em considerao sua receita total, o custo fixo e o custo varivel total,
segundo o grfico abaixo.

PF
PF produzida

Lucro Custo total

Prejuzo Ponto de Custo varivel

equilibrio em PF

Custo xo
PF.custo.xo
Tempo

148 captulo 5
ANOTAES

captulo 5 149
 ANOTAES

150 captulo 5
ANOTAES

captulo 5 151
 ANOTAES

152 captulo 5