Métricas e Estimativas na Engenharia de Software

Prévia do material em texto

Curso de Pós-graduação a Distância 
 
 
 
 
Métricas e 
Estimativas na 
Engenharia de 
Software 
 
 
 
 
 
Autoras: 
Janaína Rolan Loureiro e Regina Beretta Mazaro 
 
 
 
 
Universidade Católica Dom Bosco Virtual 
www.virtual.ucdb.br | 0800 647 3335 
 
 
 
 
 
 
 
 
 
2 
www.virtual.ucdb.br | 0800 647 3335 
Objetivo Geral 
Conhecer quais métricas e estimativas de software são empregadas nas 
empresas desenvolvedoras de software para prover à empresa e ao cliente um 
cálculo confiável de valor e prazos. Compreender que a importância de medir e 
estimar um sistema é similar à importância de construir um software de acordo com 
os requisitos pedidos pelo cliente. 
 
SUMÁRIO 
UNIDADE 1 – MÉTRICAS E ESTIMATIVAS DE SOFTWARE ................................ 04 
1.1 Métricas Orientadas a Tamanho: Linhas de Código ........................................... 09 
 
UNIDADE 2 – MÉTRICAS ORIENTADAS A FUNÇÃO, CASOS DE USO E 
EQUIPE .................................................................................................................... 15 
2.1 Métricas orientadas a Função: Pontos por Função ............................................. 15 
2.2 Métricas orientadas a Casos de Uso: Pontos de Caso de Uso........................... 29 
2.3 Métricas orientadas a Equipe: Planning Poker ................................................... 36 
 
UNIDADE 3 – MODELO COCOMO (I E II) ............................................................... 43 
3.1 Aplicando o Cocomo I – Implementação Básica ................................................. 44 
3.2 Aplicando o Cocomo I – Implementação Intermediária ....................................... 45 
3.3 Aplicando o Cocomo I – Implementação Avançada ............................................ 47 
3.4 Cocomo II ........................................................................................................... 47 
3.5 Pessoal envolvido no projeto – O grande mito! .................................................. 59 
 
REFERÊNCIAS ........................................................................................................ 61 
ANEXO 1 .................................................................................................................. 63 
ANEXO 2 .................................................................................................................. 64 
 
 
 
3 
www.virtual.ucdb.br | 0800 647 3335 
Apresentação 
 
Pensando de maneira geral, a compra de um produto sempre possui um 
valor a ser considerado. No ato da compra refletimos se o preço é justo, se a 
qualidade apresentada pelo produto vale o que se pede por ele, se vai durar um 
tempo considerável e até mesmo realizamos uma pesquisa de mercado para 
averiguar qual seria o melhor lugar para se comprar o produto por um preço mais 
acessível. 
No universo de software isso não é muito diferente. O cliente está cada vez 
mais exigente, buscando softwares de qualidade e com bons preços. Além disso, o 
cliente deseja que o sistema esteja em funcionamento na sua empresa o mais 
breve possível. 
Métricas e estimativas de software são empregadas nas empresas 
desenvolvedoras de software justamente para prover à empresa e ao cliente um 
cálculo confiável de qual valor e prazos podem ser ponderados para serem 
atribuídos ao software a ser construído. 
A importância de medir e estimar um sistema é similar à importância de 
construir um software de acordo com os requisitos pedidos pelo cliente, pois não 
adianta construir um software bom, porém cobrar um preço que não o representa. 
Assim como não adianta construir um software dentro do acordado e não respeitar 
os prazos, ao final o cliente ficará insatisfeito da mesma forma. 
Dessa maneira, quando empresas desenvolvedoras de software aplicam 
métricas e estimativas conseguem mensurar dados quantitativos de tamanho e 
complexidade de um sistema e com isso, calcular esforço, tempo e até mesmo qual 
valor pode ser cobrado para se desenvolver um software conforme a necessidade 
do cliente e com a estrutura e pessoal disponível na organização. Estimativas bem 
feitas ajudam a empresa a se manter competitiva no mercado. 
Nesse material são apresentadas cinco das principais métricas de software: 
Linhas de Código, Pontos por Função, Pontos de Caso de Uso, Planning Poker e o 
modelo COCOMO. 
 
 
 
4 
www.virtual.ucdb.br | 0800 647 3335 
UNIDADE 1 – MÉTRICAS E ESTIMATIVAS DE SOFTWARE 
 
 
Sabe-se que a construção e manutenção de um software envolvem diversas 
atividades, que devem ser muito bem planejadas e conduzidas. Para isso, deve-se 
ponderar o tempo e esforço para executar essas atividades, além de considerar a 
dependência entre elas. Estimativa de software é usada para estimar o tempo e 
esforço que devem ser empregados, e com ela deve ser possível responder as 
seguintes questões (SOMMERVILLE, 2011): 
1. Quanto esforço é necessário para completar cada atividade? 
2. Quanto tempo de calendário é necessário para completar cada atividade? 
3. Qual é o custo total de cada atividade? 
Custos básicos envolvem tanto hardwares e softwares necessários para o 
desenvolvimento de software, quanto custos de deslocamento até a empresa do 
cliente para eventuais reuniões, coletas de requisitos, implantação do software, 
treinamento de usuários e 
manutenção. Toda forma de 
diminuir custos é válida, ou seja, 
apostar em reuniões web, suporte 
online e até mesmo treinamento 
por vídeo conferência pode ser 
um meio de economizar em um 
projeto de software. 
Fonte: http://migre.me/t0QB7 
Entretanto, o principal custo associado a um desenvolvimento de software é 
o custo de esforço. Esse custo é diretamente relacionado ao pagamento da equipe 
envolvida nesse desenvolvimento, isto é, o custo do salário do pessoal que compõe 
a equipe, mas também o custo de tudo que provém condições para que eles 
trabalhem com qualidade, por exemplo um escritório confortável, seguros de saúde 
e previdência, auxílios à pesquisa, maternidade/paternidade e até mesmo 
pagamento de terceiros envolvidos nesse processo (contadores, faxineiros, 
administradores e etc.). 
Logo, estimar o custo de esforço exigido para o desenvolvimento de um 
projeto é uma etapa fundamental do planejamento. Essa estimativa servirá de base 
 
 
 
5 
www.virtual.ucdb.br | 0800 647 3335 
para a definição do cronograma, orçamento e até atribuição das atividades para a 
equipe. Quanto mais precisa for essa estimativa, maiores as chances de sucesso 
do projeto. 
Contudo, realizar tal estimativa não é uma tarefa muito simples. Ao contrário 
das ciências físicas, em que é possível medir de forma direta e bem-definida a 
temperatura, velocidade, pressão, e demais grandezas, o software não possui uma 
unidade universal que permita sua medição de maneira absoluta. Pelo contrário, o 
desenvolvimento de software pode ser avaliado por diversas perspectivas, todas 
possuindo um certo grau de subjetividade. Isso faz com que as atividades de 
estimativas tenham um risco associado, que pode ser reduzido com constantes 
revisões das estimativas. 
Boehm (1981), introduziu a relação entre a imprecisão das estimativas e a 
fase corrente do projeto, conceito que mais tarde foi batizado de Cone da Incerteza 
por McConnell (1998) e pode ser conferido no Gráfico 1. Ele indica que as 
estimativas realizadas na fase inicial de um projeto possuem uma margem de erro 
de cerca de 35%, tanto para mais como para menos, embora a tendência 
observada seja de estimativas abaixo da realidade. 
 
Gráfico 1 - Cone da Incerteza de Estimativa 
 
Fonte: Adaptado de Futrell et al., 2002 
 
O cone da incerteza também indica que as estimativas são aprimoradas 
conforme o projeto é desenvolvido. Isso ocorre pois inicialmente os requisitos são 
 
 
 
6 
www.virtual.ucdb.br | 0800 647 3335 
pouco conhecidos e sujeitos a muitas mudanças durante o processo,tornando-se 
mais estáveis com as revisões e especificações detalhadas. 
Contudo, a redução no grau de incerteza das estimativas irá ocorrer apenas 
se for realizado o gerenciamento adequado das etapas do processo, para que as 
correções necessárias sejam executadas e as estimativas aperfeiçoadas. Sem esse 
acompanhamento, o cenário do projeto continuará refletindo incerteza, formando 
uma nuvem em torno dos valores do melhor caso, como pode ser conferido no 
Gráfico 2. 
 
Gráfico 2 - Nuvem de Incerteza em projetos não gerenciados 
 
Fonte: adaptado de McConnell's, 2006 
 
Uma das abordagens mais aplicadas para realizar-se a avaliação de esforço 
do desenvolvimento é através da estimativa do tamanho esperado que o software 
irá atingir quando pronto. De acordo com Hazan (2008), a estimativa do tamanho do 
software permite estabelecer como será realizado o seu desenvolvimento, o custo 
agregado e o tempo exigido para sua construção. O gerenciamento do projeto pode, 
então, aproveitar as estimativas obtidas para monitorar e aprimorar o projeto 
sempre que possível, buscando alcançar uma qualidade cada vez maior para o 
produto final. 
Além disso, é possível utilizar os dados obtidos nas medições de projetos 
anteriores como aprendizado para incrementar e ajustar continuamente o processo 
de desenvolvimento de software adotado pela empresa. A comparação entre o que 
foi previsto e o que foi de fato atingido na realidade permite que sejam identificados 
 
 
 
7 
www.virtual.ucdb.br | 0800 647 3335 
pontos deficitários do processo, sugerindo a necessidade de uma maior atenção 
nesses itens. Dessa forma, a medição é uma ferramenta poderosa para qualquer 
gestor de projeto, pois serve para embasar suas tomadas de decisões. 
 
 
 
 
 
 
Métricas de Processo e Projeto 
 
O que é? As métricas de projeto e processo de software são medidas 
quantitativas que permitem que você tenha o discernimento sobre a 
eficácia do processo de software e os projetos que são executados 
usando o processo como uma estrutura. São coletados dados básicos de 
qualidade e comparados com médias passadas, e avaliados para 
determinar se ocorreram melhorias de qualidade e produtividade. As 
métricas são usadas também para apontar áreas com problemas, de 
modo que as correções possam ser desenvolvidas e o processo de 
software melhorado. 
Quem realiza? Métricas de software são analisadas e avaliadas por 
gerentes de software. As medidas muitas vezes são coletadas por 
engenheiros de software. 
Por que é importante? Se você não medir, o julgamento só pode ser 
baseado em uma avaliação subjetiva. Com a medição, tendências (tanto 
boas quanto ruins) podem ser detectadas, podem ser feitas melhores 
estimativas e melhorias significativas podem ser obtidas ao longo do 
tempo. 
Quais são as etapas envolvidas? Comece definindo um conjunto 
limitado de medidas de processo, projeto e produto que sejam fáceis de 
coletar. Essas medidas são muitas vezes normalizadas usando-se 
métricas orientadas a tamanho ou função. O resultado é analisado e 
comparado com médias anteriores para projetos similares executados na 
organização. São avaliadas as tendências e são obtidas as conclusões. 
Qual é o artefato? Uma série de métricas de software que proporcionam 
discernimento sobre o processo e possibilitam entender o projeto. 
Como garantir que o trabalho foi realizado corretamente? Aplicando 
um esquema de medições consistente, embora simples que nunca deve 
ser usado para avaliar, recompensar, ou punir indivíduos por seu 
desempenho pessoal. 
Fonte: Pressman, 2021. 
 
 
 
8 
www.virtual.ucdb.br | 0800 647 3335 
Como o processo é o fator central na determinação da qualidade de um 
software, aplicar estratégias, como as métricas, que auxiliem na sua melhoria é 
sempre muito importante. Pressman (2021), representa o Processo por meio de um 
triângulo, em que a complexidade do Produto, a capacidade e motivação do 
Pessoal e a Tecnologia disponível para desenvolvimento exercem influência direta 
na qualidade e desempenho observados. Condições ambientais, como o ambiente 
de desenvolvimento, condições de negócios e características do cliente também 
geram impacto no processo. A Figura 1 ilustra o relacionamento desses fatores que 
influenciam a qualidade do produto de software. 
 
Figura 1 - Determinantes da qualidade de software 
 
Fonte: Adaptado de Pressman, 2021 
 
 
Nesse material, serão discutidas as principais métricas de software: 
• Orientadas a Tamanho: Linhas de Código 
o Consideram o tamanho em linhas de código do software em 
desenvolvimento como medida de normalização para estimar a 
produtividade do projeto. 
• Orientadas a Função: Pontos por Função 
 
 
 
9 
www.virtual.ucdb.br | 0800 647 3335 
o Consideram as funcionalidades a serem entregues como 
medida de normalização para estimar a produtividade do 
projeto. 
• Orientadas a Casos de Uso: Pontos de Caso de Uso 
o Consideram os casos de uso a serem desenvolvidos como 
medida de normalização para estimar a produtividade do 
projeto. 
• Orientadas a Equipe: Planning Poker 
o Consideram a experiência dos membros da equipe 
desenvolvedora para estimar a produtividade do projeto. 
Encerrando com o estudo do modelo de estimativa COCOMO II, que 
apresenta uma medição mais elaborada ao reunir características de mais de uma 
métrica em sua estrutura. 
 
1.1 Métricas Orientadas a Tamanho: Linhas de Código 
 
Introduzida inicialmente em meados de 
1960, a métrica de Linhas de Código (do inglês 
Lines of Code - LOC) foi a primeira a ser 
adotada na Engenharia de Software para 
estimativas de qualidade, produtividade e custo 
de projetos de desenvolvimento de softwares. 
Nessa época, cerca de 90% do trabalho total de 
um projeto de software se concentrava na produção de código, o que o tornava o 
principal produto gerado. Além disso, a única linguagem de programação 
empregada era Assembly, em que toda linha física de código representava uma 
única sentença lógica. Em conjunto, esses fatores fizeram com que a métrica LOC 
se mostrasse bastante eficaz para estimar custo, tempo gasto e qualidade do 
software produzido, e, portanto, se tornasse a principal métrica adotada no 
mercado. 
Contudo, com o surgimento das linguagens de programação de alto nível, 
como FORTRAN, COBOL, Basic e PL/I na década de 1970, os conceitos que 
sustentavam a métrica LOC sofreram alterações significativas, reduzindo assim a 
sua eficácia. Nessas novas linguagens de programação, as linhas físicas de código 
Linhas de código fonte (do 
inglês Source Lines of Code - 
SLOC) é outro termo utilizado 
para referir-se a essa mesma 
métrica. Já KLOC (do inglês Kilo 
Line os Code), ou KSLOC, 
representa uma unidade de 
medida para a métrica de LOC, 
indicando um conjunto de mil 
linhas de código. 
 
 
 
10 
www.virtual.ucdb.br | 0800 647 3335 
nem sempre coincidiam com as sentenças lógicas do programa. Em alguns casos, 
as sentenças lógicas passaram a ser divididas em mais de uma linha física para 
melhor compreensão. Em outras situações, era ainda possível agrupar mais de uma 
sentença lógica em uma única linha física, enfraquecendo assim a relação número 
de linhas físicas X quantidade de sentenças lógicas. 
Outro aspecto que contribuiu para a defasagem da métrica LOC foi a redução 
do esforço exigido na fase de programação em relação ao projeto total de 90% para 
cerca de 50%, segundo Jones (2013), especialmente em sistemas de grande porte. 
Isso porque as linguagens de alto nível facilitaram a produção de código, pois 
muitas de suas sentenças básicas representavam um conjunto de sentenças em 
Assembly. Sendo assim, estimar apenas o trabalho do desenvolvimento de código 
deixou de ser suficiente para realizar uma boa avaliação do projeto de software 
como um todo, pois esta passou a representar uma única etapa do processo, não 
sendo mais tão predominante como anteriormente.Com o avanço das linguagens de programação e das diferentes dimensões 
de qualidade de software exigidas, a métrica LOC se tornou cada vez menos 
recomendável para ser utilizada isoladamente na medição de projetos e processos 
de software. Ela esbarra em dificuldades como ambiguidades na contagem de 
linhas, aplicações desenvolvidas em mais de uma linguagem distinta, reuso de 
software e incapacidade de detectar falhas de usabilidade, interface, e outros 
requisitos não funcionais. Mesmo assim, LOC ainda é utilizada como complemento 
em outras métricas mais elaboradas que são empregadas na atualidade, o que 
torna seu estudo e compreensão relevantes. 
 
1.1.1 Como estimar e medir 
 
O primeiro passo para estimar-se o tamanho, em linhas de código, de um 
software é subdividi-lo em componentes menores, cada qual englobando uma 
funcionalidade específica. Assim, é possível realizar a estimativa dos elementos em 
separado e obter o total do sistema somando seus tamanhos. 
Uma das maneiras empregadas para estimar quantas linhas de código serão 
necessárias para implementar um determinado componente é consultar um 
especialista que já tenha desenvolvido uma funcionalidade semelhante, para que 
possam fazer uma estimativa com base em suas experiências passadas. Outra 
 
 
 
11 
www.virtual.ucdb.br | 0800 647 3335 
opção é que os mesmos desenvolvedores que serão responsáveis pela 
implementação desse elemento façam a estimativa. 
Para melhorar a qualidade das estimativas, é interessante que os 
especialistas ou desenvolvedores consultados forneçam três valores acerca da 
quantidade de linhas de código que acreditam que terão que ser implementadas 
para contemplar o componente: um valor otimista (mínimo, ), um valor pessimista 
(máximo, ) e outro valor realista (médio, ). Com isso, é possível calcular uma 
distribuição beta para a estimativa, aprimorando assim o valor obtido. Futrell et al. 
(2002) sugerem a seguinte distribuição, que prioriza o valor realista, mas balanceia 
a estimativa incluindo um grau de incerteza com os valores otimistas e pessimistas: 
 
 
 
Em geral, o valor final é apresentado em KLOC (ou KSLOC), por ser uma 
unidade mais adequada ao tamanho de softwares. 
Uma terceira alternativa para realizar a estimativa é por analogia, 
comparando-se as funcionalidades requeridas pelo sistema com outros softwares já 
desenvolvidos anteriormente. Contudo, é importante ressaltar que essa maneira 
oferece uma série de obstáculos para uma estimativa precisa, como por exemplo: 
uso de linguagens de programação diferentes, aplicação de algoritmos ou 
estruturas de dados distintos, funcionalidades semelhantes podem ser empregadas 
em escopos divergentes, entre outras inconsistências que podem ser observadas 
entre o software a ser desenvolvido e os que estão servindo de referência. 
Tão importante como estimar com 
precisão quantas linhas de código um software 
terá é saber contá-las uma vez prontas. Como foi 
visto, a simples contagem das linhas de arquivos 
de código fonte não é mais uma abordagem 
viável, pois com as linguagens de alto nível 
perdeu-se a relação um para um entre linhas 
físicas e sentenças lógicas. Faz-se necessário 
então definir alguns parâmetros para o cálculo do 
Robert E. Park desenvolveu no 
Software Engineering Institute 
(SEI) um framework para 
padronizar a contagem de linhas 
de código de um software. 
Conheça o documento completo 
em: 
<http://www.sei.cmu.edu/reports/
92tr020.pdf>. Acesso em: 17 set. 
2021. 
http://www.sei.cmu.edu/reports/92tr020.pdf
http://www.sei.cmu.edu/reports/92tr020.pdf
 
 
 
12 
www.virtual.ucdb.br | 0800 647 3335 
número de linhas de código de um software, e mantê-los consistentes para 
padronizar a métrica. 
Devem ser contadas como linhas de código apenas aquelas que trazem 
sentenças lógicas executáveis, desconsiderando-se, portanto, comentários, linhas 
em branco, aberturas/fechamentos de blocos e códigos temporários para testes ou 
debug. Cada sentença lógica deve ser contada como uma linha, ainda que estejam 
em uma mesma linha física. 
As linhas devem ser contadas de maneira contínua e integral, 
independentemente dos possíveis fluxos de execução que o sistema possa tomar. 
Isso é importante pois nessa métrica está sendo avaliado o esforço de produção do 
software, que precisa contemplar diferentes cenários de execução, até mesmo os 
pouco prováveis. 
Definições de variáveis e estruturas, assim como diretivas de inclusão ou 
chamadas de função, devem ser contadas uma única vez assim que aparecem. 
Código oriundo de reuso de software não deve ser computado, afinal o esforço para 
seu desenvolvimento ocorreu em seu projeto original, e não no atual. 
É evidente que o trabalho de contar as linhas de código de um software 
pronto, seja para avaliar a realidade alcançada com a estimativa prevista ou para 
utilizar o resultado como dado histórico para novos projetos, não precisa ser 
realizado manualmente. Existem diversos softwares que auxiliam nessa etapa, 
realizando a contagem de LOC conforme parâmetros pré-definidos. É o caso do 
LOC metrics1, CLOC2, Universal Code Lines Counter3 e Count Lines of Code with 
Understand4. 
Essas definições possibilitam que a contagem de linhas de código em 
diferentes projetos se mantenha estruturada, com diretrizes padronizadas adotadas 
em todos os projetos. Porém, ainda assim existem empecilhos em relação à 
comparação direta entre a quantidade de linhas de diferentes projetos, sendo que o 
uso de linguagens de programação diferentes é o principal deles. Pensando nisso, 
foi elaborada uma tabela que permite estimar quantas linhas de Assembly cada 
linha de código de uma determinada linguagem de alto nível representa. A ideia é 
que as estimativas de todos os projetos devem ser transformadas para o 
 
1 http://www.locmetrics.com 
2 https://github.com/AlDanial/cloc 
3 http://www.ab-tools.com/en/software/universalcodelinescounter/ 
4 https://scitools.com/count-lines-of-code/ 
 
 
 
13 
www.virtual.ucdb.br | 0800 647 3335 
equivalente em Assembly de acordo com a tabela de referência (Anexo 2), e 
apenas nesse contexto é apropriado comparar diferentes projetos. 
A partir da estimativa das linhas de código exigidas em um software, é 
possível também calcular o tempo necessário, de acordo com a produtividade da 
equipe. Para isso, basta ter a informação de qual a média de produtividade em 
linhas de código por mês de cada desenvolvedor. Futrell et al. (2002) defendem que 
há mais de duas décadas a média anual de produtividade dos desenvolvedores tem 
sido de 3 mil linhas de código entregues, independente da linguagem utilizada. 
 
1.1.2 Vantagens e desvantagens 
 
A métrica das linhas de código foi uma das pioneiras a surgir na área de 
Engenharia de Software, e sua aceitação foi alta pois seu objeto-alvo é o código 
fonte, elemento que constitui a base de qualquer software desenvolvido. Além 
disso, ela atribui um peso significativo ao desenvolvedor, pois é uma medida que 
foca o produto final gerado, mas através da ótica do desenvolvedor. 
Outra vantagem da métrica LOC é que ela permite a comparação entre 
diferentes projetos, através da normalização do número de instruções em 
Assembly. Calcular o tamanho em linhas de código do software desenvolvido é 
operação direta, limitada apenas à contagem das linhas segundo os parâmetros 
definidos. E como as estimativas são realizadas considerando a experiência de 
especialistas e desenvolvedores em projetos passados, a melhoria na sua 
qualidade segue sempre constante, sendo aperfeiçoada a cada novo projeto 
concluído. 
Contudo, apesar desses benefícios que a métrica LOC apresenta, ela 
também possui muitas desvantagens atreladas. Por exemplo, é difícil estimar o 
tamanho esperado de projetos inovadores, pois não existem dados anteriores para 
embasarem o cálculo. Além disso, os métodos de estimativa são subjetivosmesmo 
para projetos com que a equipe está familiarizada, e podem se mostrar 
completamente imprecisos com o decorrer do desenvolvimento. 
O estilo de programação do desenvolvedor exerce alta influência nessa 
métrica, seja tanto pela linguagem empregada como também pela tendência em 
escrever códigos mais concisos ou detalhados. De acordo com o conceito da 
métrica, a quantidade de linhas de código implementadas pode ser confundida com 
 
 
 
14 
www.virtual.ucdb.br | 0800 647 3335 
produtividade. Afinal, nem sempre o programador que mais escreveu código foi o 
mais produtivo em termos de entrega de funcionalidades. 
A preocupação apenas com a quantidade de código desenvolvido também 
pode aumentar a ocorrência de erros, que geralmente são custosos para serem 
consertados. Analisar apenas o aspecto do código também impossibilita a avaliação 
de melhoria em funcionalidades que não são diretamente relacionadas com código, 
como é o caso de muitos requisitos não funcionais. 
O reuso de software e a geração automática de código, práticas amplamente 
difundidas no mercado, não são abordagens que se encaixam facilmente com a 
métrica LOC. Apesar de fazerem parte do código final, o esforço exigido para seu 
desenvolvimento é muito inferior ao de códigos que foram implementados por 
inteiro, logo não devem ser computados da mesma maneira. 
Enfim, apesar do conhecimento geral sobre essa métrica e a impressão de 
simplicidade, ela ainda é utilizada como estimativa de tamanho de software. Vale, 
porém, ressaltar que, se utilizada isoladamente, essa métrica LOC pode chegar a 
ser prejudicial, pois sua imprecisão de estimativa gera um planejamento incorreto 
que pode acarretar em custos ou prazos maiores do que os previstos. 
 
Exercício 1 
 
Sobre a métrica de Linhas de Código, é correto afirmar que: 
a) Seu valor é sempre igual à quantidade de linhas de um arquivo de código. 
b) Uma de suas principais vantagens é que pode ser aplicado em qualquer projeto, 
sem que seja necessária nenhuma conversão, apenas confrontando-se os valores 
obtidos. 
c) As linguagens de programação de alto nível dificultaram a aplicação da métrica 
de linhas de código, pois a contagem não pode ser mais realizada de forma direta. 
d) Uma linha física corresponde a no máximo uma linha de código válida. 
e) Pode-se considerar o fluxo lógico ideal do programa, desconsiderando-se os 
caminhos mais improváveis de serem executados, ao realizar a contagem das 
linhas de código. 
 
 
 
 
15 
www.virtual.ucdb.br | 0800 647 3335 
UNIDADE 2 – MÉTRICAS ORIENTADAS A FUNÇÃO, CASOS DE 
USO E EQUIPE 
 
2.1 Métricas orientadas a Função: Pontos por Função 
 
Com o desenvolvimento das linguagens de programação de alto nível, os 
problemas relacionados à métrica de linhas de código passaram a se tornar maiores 
e mais inconvenientes para sua aplicação com sucesso. As estimativas começaram 
a perder precisão, e o mercado sentiu a necessidade de elaborar uma nova métrica 
para avaliar o tamanho esperado de um software e seu respectivo esforço de 
desenvolvimento. 
Foi então que em 1979, Allan Albrecht da IBM introduziu uma métrica que 
considera como medida para avaliar a complexidade do software as funções que 
este deve apresentar, ao invés de focar na quantidade de linhas de código 
elaboradas. Capers Jones, do Software Productivity Research (SPR), também 
aprimorou a métrica, tornando-a amplamente reconhecida. O International Function 
Point User Group (IFPUG) foi criado em 1986 para reunir os especialistas e 
aplicadores da métrica de pontos por função, de forma que eles pudessem trocar 
informações entre si. Várias publicações relacionadas ao tema surgiram dessa 
união, incluindo diretrizes e manuais para padronizar a métrica como o Function 
Point Counting Practices Manual5. 
O intuito da métrica de pontos por função é medir o software em termos de 
suas funções para o usuário final, e não simplesmente pelo número de linhas de 
código. Isso permite uma estimativa mais concreta do esforço do software, pois as 
funções são analisadas de acordo com sua categoria (entrada, saída, consultas, 
estruturas de dados e interfaces) e complexidade (baixa, média ou alta), cada qual 
possuindo um peso específico. Se necessário, é possível ainda obter a estimativa 
de linhas de código a partir dos pontos por função com a aplicação de uma fórmula 
de conversão. 
Futrell et al. (2002) definem seis passos básicos para a análise dos pontos 
por função conforme a Figura 2, que serão aprofundados nas seções subsequentes. 
No Anexo 1 são disponibilizadas planilhas-padrão para o cálculo dos pontos por 
função nas diferentes etapas do processo. 
 
5 Atualmente na versão 4.3.1, 2010. 
 
 
 
16 
www.virtual.ucdb.br | 0800 647 3335 
Figura 2 - Passos básicos na análise de pontos por função 
 
 
Fonte: Adaptado de Futrell et al., 2002 
 
2.1.1 Contar o número de funções em cada categoria 
O processo para estimar o tamanho do software a ser desenvolvido com 
base nos seus pontos por função se inicia com a avaliação dos requisitos e suas 
funções associadas. São avaliados os volumes de entradas, saídas, consultas e 
dados produzidos pelo software, conforme uma arquitetura básica inicial 
(preferencialmente de forma visual), que é suficiente para uma primeira estimativa. 
Cada categoria possui suas particularidades de identificação e definição de 
grau de complexidade, e por isso serão tratadas separadamente nessa seção. 
1. Saídas 
Qualquer estímulo produzido internamente no sistema que produza dados 
através de processamento para ser enviado ao usuário final constitui uma 
saída, como por exemplo as informações que são exibidas na tela a ele. 
Para fins da estimativa de pontos por função, devem ser contadas apenas 
saídas únicas, ou seja, que representam uma interação diferente. Elas 
devem então ser classificadas quanto a sua complexidade, considerando-se 
a quantidade de arquivos e campos envolvidos (Tabela 1), para que 
recebam o peso adequado. 
 
 
 
17 
www.virtual.ucdb.br | 0800 647 3335 
Tabela 1 - Fatores de peso para Saídas na Análise de Pontos por Função 
Quantidade de arquivos 
Quantidade de campos 
1 a 5 6 a 19 20 ou mais 
0 a 1 Baixa (4) Baixa (4) Média (5) 
2 a 3 Baixa (4) Média (5) Alta (7) 
4 ou mais Média (5) Alta (7) Alta (7) 
Fonte: IFPUG, 2010 
2. Entradas 
As entradas são formadas pelas informações que são passadas do usuário 
para o sistema, ou seja, são oriundas de fora do sistema, com o objetivo de 
serem armazenadas ou processadas. Novamente, apenas entradas únicas 
devem ser computadas, e cada qual deve ter sua classificação computada 
de acordo com os arquivos e campos com os quais interage, conforme pode 
ser conferido na Tabela 2. 
 
Tabela 2 - Fatores de peso para Entradas na Análise de Pontos por Função 
Quantidade de arquivos 
Quantidade de campos 
1 a 4 5 a 15 16 ou mais 
0 a 1 Baixa (3) Baixa (3) Média (4) 
2 Baixa (3) Média (4) Alta (6) 
3 ou mais Média (4) Alta (6) Alta (6) 
Fonte: IFPUG, 2010 
 
3. Consultas 
As consultas são solicitações originárias de fora do sistema, que são 
processadas para que as informações sejam recuperadas e retornadas ao 
solicitante. Em geral envolvem consultas a bancos de dados, com retorno 
imediato, e ao contrário das saídas não exigem processamento lógico 
interno. 
Além de apenas consultas únicas deverem ser computadas, vale 
ressaltar que as consultas apresentam partes internas e externas, que 
por sua vez apresentam pesos diferentes para a estimativa de pontos 
por função. Esses pesos são indicados nas Tabela 3 e Tabela 4. 
 
 
 
 
18 
www.virtual.ucdb.br | 0800 647 3335 
Tabela 3 - Fatores de peso para Consultas (parte externa) na Análise de 
Pontos por Função 
Quantidade de arquivos 
Quantidade de campos 
1 a 5 6 a 19 20 ou mais 
0 a 1 Baixa (4) Baixa (4) Média (5) 
2 a 3 Baixa (4) Média (5) Alta (7) 
4 ou mais Média(5) Alta (7) Alta (7) 
Fonte: IFPUG, 2010 
 
Tabela 4 - Fatores de peso para Consultas (parte interna) na Análise de Pontos 
por Função 
Quantidade de arquivos 
Quantidade de campos 
1 a 4 5 a 15 16 ou mais 
0 a 1 Baixa (3) Baixa (3) Média (4) 
2 Baixa (3) Média (4) Alta (6) 
3 ou mais Média (4) Alta (6) Alta (6) 
Fonte: IFPUG, 2010 
 
4. Estruturas de Dados ou Arquivos 
Nessa categoria são inclusas todas as estruturas de dados armazenadas no 
escopo do sistema, disponíveis aos usuários por meio de entradas, saídas, 
consultas ou interfaces (as demais categorias). Entram também nesse item 
os arquivos lógicos do software. A Tabela 5 traz o peso para cada 
complexidade de uma função nessa classe. 
 
Tabela 5 - Fatores de peso para Estruturas de Dados na Análise de Pontos por 
Função 
Quantidade de formas 
de organização 
Quantidade de campos 
1 a 19 20 a 50 51 ou mais 
1 Baixa (7) Baixa (7) Média (10) 
2 a 5 Baixa (7) Média (10) Alta (15) 
6 ou mais Média (10) Alta (15) Alta (15) 
Fonte: IFPUG, 2010 
 
5. Interfaces 
As interfaces englobam as informações e processamento que o sistema 
necessita, mas que são externos a ele. Uma diferença em relação às 
demais categorias é que estruturas de dados que sejam compartilhadas 
 
 
 
19 
www.virtual.ucdb.br | 0800 647 3335 
entre sistemas devem ser consideradas tanto nessa categoria como na de 
estruturas de dados e arquivos vista anteriormente. As demais interações 
devem ser consideradas como uma única interface, respeitando-se a 
direção. A Tabela 6 relaciona a quantidade de organizações e os campos 
utilizados para posicionar a complexidade das interfaces. 
 
Tabela 6 - Fatores de peso para Interfaces na Análise de Pontos por Função 
Quantidade de formas 
de organização 
Quantidade de campos 
1 a 19 20 a 50 51 ou mais 
1 Baixa (5) Baixa (5) Média (7) 
2 a 5 Baixa (5) Média (7) Alta (10) 
6 ou mais Média (7) Alta (10) Alta (10) 
Fonte: IFPUG, 2010 
 
 
2.1.2 Aplicar os fatores de peso de complexidade 
Uma vez que as funções foram contadas e classificadas, o passo seguinte é 
calcular o total dos pontos por função não ajustados gerados. Para isso, em cada 
categoria, a quantidade encontrada de funções em cada complexidade é 
multiplicada pelo respectivo peso. O total é então obtido a partir da soma desses 
valores individuais, resultando nos pontos por função não ajustados (PF). O Anexo 
1 traz um modelo de tabela que facilita bastante esse cálculo. 
 
2.1.3 Aplicar as características gerais do sistema 
As características gerais do sistema podem influenciar positivamente ou 
negativamente no desenvolvimento de softwares, impactando na sua dimensão. 
Para contemplar essa realidade, foi incluída na métrica de pontos por função um 
fator de ajuste que possibilite tornar a estimativa um pouco mais realista. 
Ao todo, 14 características devem ser consideradas para a estimativa dos 
pontos por função, atribuindo-se a cada um valor entre 0 e 5, conforme descrito 
abaixo: 
1. Não se aplica; 
2. Influência casual; 
3. Influência moderada; 
4. Influência média; 
5. Influência significativa 
 
 
 
20 
www.virtual.ucdb.br | 0800 647 3335 
6. Influência alta. 
A seguir, serão discutidos em maiores detalhes esses 14 fatores e suas 
diretrizes para classificação em relação à complexidade, segundo IFPUG (2010). 
• Comunicação de Dados: refere-se à maneira com que as informações e os 
controles de dados são enviados e recebidos na comunicação entre a 
aplicação e o processador. Essas comunicações requerem um protocolo, 
para que seja estabelecido um padrão para a troca de informações entre 
sistemas e dispositivos. 
 
Tabela 7 - Classificação de complexidade da Comunicação de Dados 
Valor Descrição para determinar o nível de influência 
0 Aplicação possui apenas processamento em lotes ou um computador isolado. 
1 
Aplicação possui processamento em lotes, mas também possui entrada de 
dados OU impressão remota. 
2 
Aplicação possui processamento em lotes, mas também possui entrada de 
dados E impressão remota. 
3 
Aplicação inclui coleta de dados online ou processamento front-end de um lote 
de processos ou consultas ao sistema. 
4 
Aplicação é mais do que apenas um front-end, mas suporta apenas um tipo de 
protocolo de comunicação. 
5 
Aplicação é mais do que apenas um front-end, e suporta mais de um tipo de 
protocolo de comunicação. 
Fonte: IFPUG, 2010 
 
• Processamento Distribuído de Dados: avalia o nível de transferência de 
dados entre componentes internos da aplicação. 
 
Tabela 8 - Classificação de complexidade do Processamento Distribuído 
Valor Descrição para determinar o nível de influência 
0 
Aplicação não auxilia a transferência de dados ou funções de processamento 
entre os componentes do sistema. 
1 
Aplicação prepara os dados para serem processados pelo usuário em outro 
componente do sistema. 
2 
Dados são preparados para transferência, e então são transferidos e 
processados em outro componente do sistema (não são para processamento do 
usuário final). 
3 
Processamento distribuído e transferência de dados são online e em uma 
direção apenas. 
4 
Processamento distribuído e transferência de dados são online e em ambas as 
direções. 
5 
Funções de processamento são realizadas dinamicamente nos componentes 
mais apropriados do sistema. 
Fonte: IFPUG, 2010 
 
 
 
21 
www.virtual.ucdb.br | 0800 647 3335 
• Desempenho: considera a influência do tempo de resposta e transferência 
para o design, desenvolvimento, instalação e manutenção da aplicação, de 
acordo com os objetivos estabelecidos pelo usuário. 
 
Tabela 9 - Classificação de complexidade de Desempenho 
Valor Descrição para determinar o nível de influência 
0 Nenhum requisito especial de desempenho foi estabelecido pelo usuário. 
1 
Requisitos de design e desempenho foram estabelecidos e revisados, mas 
nenhuma ação especial foi necessária. 
2 
Tempo de resposta ou transferência são críticos durante o horário de pico. 
Nenhum design especial para uso do processador foi imposto. Os prazos de 
processamento são o próximo dia útil. 
3 
Tempo de resposta ou transferência são críticos durante todo o horário de 
comercial. Nenhum design especial para uso do processador foi imposto. Os 
prazos de processamento são restritos. 
4 
Além disso, os requisitos de desempenho do usuário são rigorosos o suficiente 
para necessitarem análise de desempenho na fase de design. 
5 
Além disso, ferramentas de análise de desempenho são utilizadas nas fases do 
design, desenvolvimento, e/ou implementação para atender aos requisitos do 
usuário. 
Fonte: IFPUG, 2010 
 
• Configuração Intensamente Utilizada: refere-se à influência das restrições 
de recursos sobre o desenvolvimento da aplicação. Isso ocorre quando o 
usuário define uma configuração de equipamento na qual o sistema deve ser 
intensamente utilizado, o que por sua vez pode gerar restrições de projeto 
para adequação do sistema. 
 
Tabela 10 - Classificação de complexidade da Configuração Intensamente 
Utilizada 
Valor Descrição para determinar o nível de influência 
0 Nenhuma restrição operacional, implícita ou explícita, foi incluída. 
1 
Apesar de existirem restrições operacionais, elas não são muito restritivas e não 
exigem esforço adicional para serem satisfeitas. 
2 
Existem restrições operacionais típicas. Exigem um esforço específico para 
serem satisfeitas, como programas de controle. 
3 
As restrições operacionais impostas limitam parte da aplicação no processador 
central ou dedicado. 
4 
As restrições operacionais impostas limitam a aplicação no processador central 
ou dedicado. 
5 
Existem ainda limitações específicas da aplicação nos componentes 
distribuídos. 
Fonte: IFPUG, 2010 
 
 
 
22 
www.virtual.ucdb.br | 0800 647 3335 
• Volume de Transações: avalia se a taxa de transações do negócio irá 
influenciar o desenvolvimento do sistema. Caso esse volumeseja muito alto, 
todo o processo de projeto, desenvolvimento e instalação do sistema será 
influenciado, pois os usuários podem exigir um determinado tempo de 
resposta mesmo durante horários de pico. 
 
Tabela 11 - Classificação de complexidade do Volume de Transações 
Valor Descrição para determinar o nível de influência 
0 Não é previsto nenhum horário de pico de transações. 
1 
O volume de transações é baixo e pouco influencia as fases de projeto, 
desenvolvimento e instalação. 
2 
O volume de transações é médio e influencia levemente as fases de projeto, 
desenvolvimento e instalação. 
3 
O volume de transações é alto e influencia as fases de projeto, desenvolvimento 
e instalação. 
4 
O volume de transações é suficientemente alto e requer tarefas de análise de 
desempenho das fases de projeto, desenvolvimento e/ou instalação. 
5 
O volume de transações é suficientemente alto e requer tarefas e ferramentas 
de análise de desempenho das fases de projeto, desenvolvimento e/ou 
instalação. 
Fonte: IFPUG, 2010 
 
• Entrada de Dados Online: descreve o nível das transações que informam e 
recuperam dados no sistema. Essas interações com o usuário são realizadas 
através de interface online, funções de controle, relatórios e consultas. 
 
Tabela 12 - Classificação de complexidade da Entrada de Dados Online 
Valor Descrição para determinar o nível de influência 
0 Todas as transações são realizadas em lote. 
1 1% a 7% das transações são interativas. 
2 8% a 15% das transações são interativas. 
3 16% a 23% das transações são interativas. 
4 24% a 30% das transações são interativas. 
5 Mais de 30% das transações são interativas. 
Fonte: IFPUG, 2010 
 
• Eficiência do Usuário Final: avalia o grau com que a usabilidade e os 
recursos humanos foram considerados no desenvolvimento da aplicação. O 
projeto para apresentar maior usabilidade deve apresentar: 
• Apoio à navegação; 
• Menus; 
 
 
 
23 
www.virtual.ucdb.br | 0800 647 3335 
• Ajuda e documentação; 
• Movimentação do cursor; 
• Paginação; 
• Impressão remota; 
• Teclas de atalho; 
• Execução de tarefas em lote com base em transações online; 
• Combos; 
• Uso intensivo de indicadores de vídeo; 
• Documentação impressa das transações; 
• Interface do mouse; 
• Janelas pop-up; 
• Templates; 
• Suporte a dois idiomas; 
• Suporte a mais de dois idiomas. 
 
Tabela 13 - Classificação de complexidade da Eficiência do Usuário Final 
Valor Descrição para determinar o nível de influência 
0 Nenhum dos itens acima. 
1 1 a 3 itens acima. 
2 4 a 5 itens acima. 
3 
6 ou mais itens acima, sem existência de requisitos específicos do usuário em 
relação à eficiência. 
4 
6 ou mais itens acima, com existência de requisitos específicos do usuário em 
relação à eficiência suficientemente fortes para ser necessário o projeto de 
tarefas que considerem o fator humano. 
5 
6 ou mais itens acima, com existência de requisitos específicos do usuário em 
relação à eficiência suficientemente fortes para ser necessário o emprego de 
ferramentas e processos especiais para garantir que as metas fossem 
alcançadas. 
Fonte: IFPUG, 2010 
 
• Atualização Online: refere-se ao nível com que os arquivos lógicos internos 
são atualizados de maneira online pela aplicação. 
 
Tabela 14 - Classificação de complexidade da Atualização Online 
Valor Descrição para determinar o nível de influência 
0 Nenhuma. 
1 Há a atualização online de 1 a 3 arquivos de controle, com pequeno volume de 
 
 
 
24 
www.virtual.ucdb.br | 0800 647 3335 
atualizações e fácil recuperação. 
2 
Há a atualização online de 4 ou mais arquivos de controle, com pequeno volume 
de atualizações e fácil recuperação. 
3 Há a atualização online da maior parte dos arquivos lógicos internos. 
4 
Além disso, uma proteção contra perda de dados foi projetada e implementada 
na aplicação. 
5 
Os processos de recuperação de dados são otimizados para reduzir custos para 
que necessitem de mínima intervenção humana, pois os volumes de 
atualizações são elevados. 
Fonte: IFPUG, 2010 
 
• Processamento Complexo: avalia o grau com que o desenvolvimento do 
sistema foi influenciado pela lógica de processamento. É analisada a 
existência dos seguintes componentes: 
✓ Controle sensível e/ou processamento específico de segurança; 
✓ Processamento lógico extensivo; 
✓ Processamento matemático extensivo; 
✓ Muito processamento de exceções, gerando transações 
incompletas que devem ser executadas outra vez; 
✓ Processamento complexo para trabalhar com diversas 
alternativas de entrada e saída. 
 
Tabela 15 - Classificação de complexidade do Processamento Complexo 
Valor Descrição para determinar o nível de influência 
0 Nenhum dos itens acima. 
1 Qualquer 1 dos itens acima. 
2 Quaisquer 2 dos itens acima. 
3 Quaisquer 3 dos itens acima. 
4 Quaisquer 4 dos itens acima. 
5 Todos os 5 itens acima. 
Fonte: IFPUG, 2010 
 
• Reusabilidade: descreve o grau com que os elementos do sistema e seu 
código foram planejados, desenvolvidos e implementados com o intuito de 
serem reutilizados em outras aplicações futuramente. 
 
Tabela 16 - Classificação de complexidade de Reusabilidade 
Valor Descrição para determinar o nível de influência 
0 Não existe código reutilizável. 
 
 
 
25 
www.virtual.ucdb.br | 0800 647 3335 
1 É empregado código reutilizável na aplicação. 
2 
Menos de 10% do código desenvolvido na aplicação foi elaborado para ser 
reutilizado em outro sistema. 
3 
10% do código desenvolvido na aplicação foi elaborado para ser reutilizado em 
outro sistema. 
4 
A aplicação foi empacotada e/ou documentada para facilitar o reuso, com 
personalização em nível de código. 
5 
A aplicação foi empacotada e/ou documentada para facilitar o reuso, com 
personalização através de parâmetros do usuário. 
Fonte: IFPUG, 2010 
 
• Facilidade de Instalação: indica se existem requisitos especiais de 
configuração ou dados de versões anteriores da aplicação que precisam ser 
convertidos para serem compatíveis com o novo sistema. 
 
Tabela 17 - Classificação de complexidade da Facilidade de Instalação 
Valor Descrição para determinar o nível de influência 
0 
O usuário não especificou nenhuma consideração ou configuração especial para 
a instalação. 
1 
O usuário não especificou nenhuma consideração especial, mas é exigida uma 
configuração inicial para a instalação. 
2 
O usuário estabeleceu requisitos de conversão e instalação. Foram fornecidos e 
testados guias para isso, e a influência da conversão no projeto foi baixa. 
3 
O usuário estabeleceu requisitos de conversão e instalação. Foram fornecidos e 
testados guias para isso, e a influência da conversão no projeto foi significativa. 
4 
Além do item 2, foram fornecidas e testadas ferramentas automatizadas de 
instalação e conversão. 
5 
Além do item 3, foram fornecidas e testadas ferramentas automatizadas de 
instalação e conversão 
Fonte: IFPUG, 2010 
 
• Facilidade de Operação: avalia a adequação a aspectos operacionais, 
como processos de backup e recuperação. É uma característica intrínseca 
da aplicação, que de acordo com seu desenvolvimento pode reduzir a 
necessidade de intervenção manual do usuário. 
 
Tabela 18 - Classificação de complexidade da Facilidade de Operação 
Valor Descrição para determinar o nível de influência 
0 
O usuário não estabeleceu nenhum requisito operacional especial, apenas os 
procedimentos de backup regulares. 
1 - 4 Ao menos um dos itens abaixo são aplicáveis ao sistema. Devem ser 
 
 
 
26 
www.virtual.ucdb.br | 0800 647 3335 
selecionados os itens que se aplicam, e cada um vale um ponto (a não ser que 
haja especificação divergente) 
• Processos de inicialização, backup e recuperação foram fornecidos, mas 
a intervenção humana é necessária. 
• Processos de inicialização, backup e recuperação foram fornecidos, mas 
a intervenção humana é necessária (vale como dois itens).• A aplicação reduz a necessidade de montagem de fitas e/ou acesso a 
dados remotos por meio de intervenção humana. 
• A aplicação reduz a necessidade de manuseio de papéis. 
5 
A aplicação apenas necessita de intervenção humana para inicialização e 
encerramento. Todo o restante é realizado de forma automatizada, incluindo a 
recuperação de erros. 
Fonte: IFPUG, 2010 
 
• Múltiplos Locais: descreve para qual nível de descentralização a aplicação 
foi desenvolvida, no que diz respeito a diferentes ambientes de hardware e 
software. 
 
Tabela 19 - Classificação de complexidade de Múltiplos Locais 
Valor Descrição para determinar o nível de influência 
0 O projeto considerou as necessidades de somente um local de instalação. 
1 
O projeto considerou as necessidades de mais de um local de instalação e a 
aplicação está desenvolvida apenas para ambientes de hardware e software 
idênticos. 
2 
O projeto considerou as necessidades de mais de um local de instalação e a 
aplicação está desenvolvida para ambientes de hardware e software 
semelhantes. 
3 
O projeto considerou as necessidades de mais de um local de instalação e a 
aplicação está desenvolvida apenas para ambientes de hardware e software 
diferentes. 
4 
A aplicação é descrita no item 2, e a documentação e o suporte foram 
fornecidos e testados para manter a aplicação em múltiplos locais. 
5 
A aplicação é descrita no item 3, e a documentação e o suporte foram 
fornecidos e testados para manter a aplicação em múltiplos locais. 
Fonte: IFPUG, 2010 
 
• Facilidade de Mudança: refere-se à facilidade com que a aplicação pode 
passar por modificações de lógica ou estruturas de dados. As características 
abaixo podem ser aplicáveis ao sistema: 
A: Consulta Flexível 
✓ São fornecidas consultas e/ou relatórios flexíveis, possibilitando a 
manipulação de pedidos simples (equivale a 1 item) 
 
 
 
27 
www.virtual.ucdb.br | 0800 647 3335 
✓ São fornecidas consultas e/ou relatórios flexíveis, possibilitando a 
manipulação de pedidos de complexidade média (equivale a 2 itens) 
✓ São fornecidas consultas e/ou relatórios flexíveis, possibilitando a 
manipulação de pedidos complexos (equivale a 3 itens) 
 
B: Dados de controle do negócio: 
✓ Dados de controle do negócio são armazenados pelo usuário em 
processos online interativos, mas as alterações sofridas só são 
disponibilizadas num prazo de um dia útil. (Equivale a 1 item) 
✓ Dados de controle do negócio são armazenados pelo usuário em 
processos online interativos, e as alterações sofridas são 
disponibilizadas imediatamente. (Equivale a 2 itens) 
 
Tabela 20 - Classificação de complexidade da Facilidade de Mudança 
Valor Descrição para determinar o nível de influência 
0 Nenhum dos itens acima. 
1 Qualquer 1 dos itens acima. 
2 Quaisquer 2 dos itens acima. 
3 Quaisquer 3 dos itens acima. 
4 Quaisquer 4 dos itens acima. 
5 Quaisquer 5 dos itens acima. 
Fonte: IFPUG, 2010 
 
2.1.4 Calcular o fator de ajuste de complexidade 
Para Jones (1997), as características gerais do sistema influenciam a 
complexidade do desenvolvimento do software em no máximo 35% quando 
analisadas na fase inicial do projeto. Nesse período, a precisão das estimativas é 
menor, pois pouco se conhece do sistema e ele ainda não está bem definido, 
podendo sofrer alterações significativas. Considerando-se isso, pode-se calcular o 
Fator de Ajuste de Valor (FAV) que irá ser utilizado na fase seguinte para ajustar os 
pontos por função calculados no passo 2 para agregar o impacto das características 
gerais do sistema. A fórmula para o seu cálculo é a seguinte: 
 
 
Onde é o somatório dos valores atribuídos a cada uma das 14 
características gerais do sistema. Logo, como o valor de cada característica pode 
 
 
 
28 
www.virtual.ucdb.br | 0800 647 3335 
variar entre 0 e 5, pode variar entre 0 (nenhum item é aplicável) e 70 (todos os 
itens são aplicáveis em seu grau máximo). 
 
2.1.5 Computar os pontos por função ajustados 
Essa quinta fase da métrica de pontos por função permite o cálculo do valor 
final ajustado, e pode ser considerada a última etapa essencial para o processo. 
Seu objetivo é associar os resultados dos passos 2 (PF) e 4 (FAV) para obtenção 
dos pontos por função ajustados (PFA). Para isso, aplica-se a fórmula: 
 
 
O valor encontrado em PFA indica a complexidade do software em 
desenvolvimento calculada em relação às suas funções, do ponto de vista do 
usuário final. Esse valor já é suficiente para ser utilizado como estimativa de 
esforço, prazo e custo de desenvolvimento, bastando ter-se a média de 
produtividade de pontos por função por desenvolvedor. 
 
2.1.6 Converter para linhas de código (opcional) 
Ainda que os pontos por função ajustados já forneçam a estimativa de 
complexidade necessária, em muitas situações é interessante que essa estimativa 
também seja apresentada como linhas de código (LOC). É possível então realizar a 
conversão de pontos por função para linhas de código através da seguinte fórmula: 
 
 
 
Onde o valor de LOC por PFA deve ser consultado na tabela de referência 
adequada, que associa a linguagem de programação com a estimativa de quantas 
linhas de código equivalem a um ponto por função. A tabela original é bastante 
extensa, portanto, nesse material ela foi reproduzida apenas parcialmente, 
contendo as principais linguagens de programação utilizadas. A tabela pode ser 
conferida no Anexo 2. 
 
 
 
 
 
 
 
29 
www.virtual.ucdb.br | 0800 647 3335 
2.2 Métricas orientadas a Casos de Uso: Pontos de Caso de Uso 
 
Sabe-se que casos de uso são vistos 
como uma das formas mais eficazes da equipe 
de software entender os requisitos a serem 
implementados em um software em 
desenvolvimento, além de fornecer uma visão 
bastante ampla do escopo do software em 
questão. Dessa forma, um caso de uso necessita 
conceber um processo de negócio que faça sentido para o usuário, e esse processo 
deve ser completo, ou seja, deve ser possível determinar o seu começo e seu fim, 
que deve deixar o sistema em um estado consistente. Além disso, um caso de uso 
representa um processo interativo, em que os atores informam dados ao sistema e 
o sistema devolve alguma informação relativa ao dado informado. 
Visando a vantagem de se empregar caso de uso em um processo de 
desenvolvimento de software, em 1993 Gustav Karner apresenta uma técnica para 
estimativa de software, chamada de Pontos de Caso de Uso. Wazlawivk (2013), 
pondera que o método se baseia na análise da quantidade e complexidade dos 
atores e casos de uso, o que gera os UUCP, ou pontos de caso de uso não 
ajustados. Depois, a aplicação e os fatores técnicos e ambientais levam aos UCP, 
ou pontos de caso de uso (ajustados). Essa técnica é baseada em Análise de 
Pontos por Função, porém tem a vantagem de demonstrar resultados mais cedo no 
ciclo de desenvolvimento. 
 
2.2.1 Pontos de Caso de Uso Não Ajustados – UUCP 
 
Pontos de caso de uso não ajustados são calculados baseados no valor 
atribuído à complexidade de atores ( ) e do valor atribuído à complexidade dos 
casos de uso ( ) que compõem o sistema: 
 
 
 
As seções i e ii a seguir explicam como determinar e . 
 
 
Caso de uso é um documento 
que captura as interações que 
ocorrem entre produtores e 
consumidores de informação 
e o sistema em 
desenvolvimento. 
(PRESSMAN, 2021) 
 
 
 
 
30 
www.virtual.ucdb.br | 0800 647 3335 
i. Complexidade de Atores 
 
A complexidade de atores ( ) é 
simples de ser calculada, pois basta somar 
os pontos atribuídos a todos os atores que 
compõem o sistema para determinar o seu 
valor. Para isso, primeiramente deve-se 
identificar os atores dos casos de uso. 
Atenção: mesmo que um ator apareça em 
diferentes casos de uso, ele deve ser 
contabilizado apenas uma única vez. Para cada ator identificado é atribuída uma 
pontuação, conforme as seguintes regras daTabela 21: 
 
Tabela 21 - Tabela de referência de Complexidade de Atores 
Pontuação equivalente 
Atribuindo pontuação 
Identificação Justificativa 
1 ponto de caso de uso 
Sistemas externos que serão 
acessados por interface de 
programação (API). 
Baixa Complexidade 
2 pontos de caso de uso 
Sistemas externos que 
interagem com o sistema via 
protocolo TCP/IP. 
Média complexidade 
Atores humanos que 
interagem com o sistema via 
linha de códigos. 
3 pontos de caso de uso 
Atores Humanos que 
interagem no sistema por 
intermédio de interface 
gráfica. 
São considerados 
complexos 
 
Dessa forma, a fórmula para calcular é: 
 
 
 
 
No qual é a quantidade de atores identificada e é a pontuação 
atribuída para cada ator. 
 
Atores em Casos de Uso são 
pessoas ou sistemas externos que 
interagem com o sistema principal. 
Usualmente os atores fornecem 
entradas ao sistema e o sistema 
após processá-las devolve uma 
saída, ou ocasiona uma mudança 
de status no próprio sistema. 
 
 
 
31 
www.virtual.ucdb.br | 0800 647 3335 
ii. Complexidade dos Casos de Uso 
 
Assim como no processo para determinar a complexidade de atores, para 
definir a complexidade dos casos de uso ( ) é necessário contabilizar quantos 
casos de uso foram propostos para o sistema. 
Atenção: cada caso de uso deve ser contabilizado 
apenas uma vez e só deve ser contabilizado se 
representar o processo completo. Variantes e casos 
de uso incluídos não devem ser computados. 
Existem três maneiras distintas de atribuir pontuação aos casos de uso. 
Apenas uma delas deve ser utilizada para definir o , escolhida conforme 
exposição e configuração dos casos de uso do projeto: 
1. Proposta juntamente com a técnica por Karner em 1993, essa é a 
primeira maneira conhecida e é baseada no número estimado de 
transações: 
 
 
Tabela 22 - Tabela de referência de Complexidade dos Casos de Uso – 
Número de Transações 
Pontuação 
equivalente 
Atribuindo pontuação 
Identificação Justificativa 
5 pontos de 
caso de uso 
O caso de uso possui no 
máximo 3 transações. 
Casos de uso 
simples 
10 pontos 
de caso de 
uso 
O caso de uso possui de 4 até 
7 transações. 
Casos de uso 
médios 
15 pontos 
de caso de 
uso 
O caso de uso possui mais de 
7 transações. 
Casos de uso 
complexos 
 
 
2. A segunda maneira é baseada na quantidade de classes necessárias 
para contemplar um caso de uso: 
 
 
Tabela 23 - Tabela de referência de Complexidade dos Casos de Uso – 
Número de Classes 
Pontuação 
equivalente 
Atribuindo pontuação 
Identificação Justificativa 
5 pontos de O caso de uso necessita de Casos de uso 
Uma transação é quando 
ocorre uma entrada ou 
saída de informação no 
sistema. 
 
 
 
32 
www.virtual.ucdb.br | 0800 647 3335 
caso de uso até 5 classes para ser 
implementado. 
simples 
10 pontos 
de caso de 
uso 
O caso de uso necessita de 6 
até 10 classes para ser 
implementado. 
Casos de uso 
médios 
15 pontos 
de caso de 
uso 
O caso de uso necessita de 
mais de 10 classes para ser 
implementado. 
Casos de uso 
complexos 
 
3. A terceira e última forma de atribuir pontuação para casos de uso é 
baseado na sua análise de risco: 
 
Tabela 24 - Tabela de referência de Complexidade dos Casos de Uso – 
Análise de Risco 
Pontuação 
equivalente 
Atribuindo pontuação 
Identificação Justificativa 
5 pontos de 
caso de uso 
O caso de uso não altera dados 
e possui cerca de 1 ou 2 
transações. 
Casos de uso de 
baixo risco 
10 pontos 
de caso de 
uso 
O caso de uso é padronizado 
(tem a lógica de funcionamento 
já conhecida), tendo um número 
conhecido de transações. 
Casos de uso de risco 
médio, pois embora 
seja padronizado, 
regras de negócio 
devem ser 
consideradas. 
15 pontos 
de caso de 
uso 
O caso de uso tem um número 
desconhecido de transações, 
pois ainda não se sabe qual é 
seu fluxo principal e suas 
continuações alternativas. 
Casos de uso de risco 
alto 
 
Dessa maneira, a fórmula para calcular é: 
 
 
 
No qual é a quantidade de casos de uso identificada e é a 
pontuação atribuída para cada caso de uso. 
iii. Fatores Técnicos e Fatores Ambientais – Fatores de ajuste 
 
O método de ajuste é bastante semelhante ao adotado pela técnica de 
Pontos de Função, utilizam-se fatores técnicos (TCF) e fatores ambientais (EF) para 
 
 
 
33 
www.virtual.ucdb.br | 0800 647 3335 
ajustar pontos de casos de uso. Existem 13 fatores técnicos a serem considerados 
e cada um apresenta um peso específico: 
 
Tabela 25 - Fatores técnicos e seus pesos 
Fator técnico Peso do fator 
T1. Sistema Distribuído 2 
T2. Performance 2 
T3. Eficiência de usuário final 1 
T4. Complexidade de processamento 1 
T5. Projeto visando código reusável 1 
T6. Facilidade de instalação 0,5 
T7. Facilidade de uso 0,5 
T8. Portabilidade 2 
T9. Facilidade de mudança 1 
T10. Concorrência 1 
T11.Segurança 1 
T12. Acesso fornecido a terceiros 1 
T13. Necessidade de treinamento 1 
 Fonte: Adaptado de Wazlawick, 2013 
 
Cada fator deve receber uma nota variando de 0 até 5, sendo a nota 0 
aplicada quando o fator não apresenta 
nenhuma importância no projeto e a nota 5 
aplicada quando o fator apresenta uma 
grande importância no projeto. Após atribuir 
essa nota para cada um dos 13 fatores 
técnicos apresentados na Tabela 25, ela deve ser multiplicada pelo peso 
equivalente do fator e então somadas para se construir o valor da variável : 
 
 
 
Onde varia de 1 até 13. Assim, é possível calcular o , aplicando 
normalização do com a seguinte fórmula: 
 
 
 
 
Sistema distribuído é um conjunto 
de computadores ligados em rede 
compartilhando recursos e 
coordenação de atividades. 
(COLOURIS et al., 2001) 
 
 
 
34 
www.virtual.ucdb.br | 0800 647 3335 
Em relação aos fatores ambientais (EF), na técnica de caso de uso existem 
no total 8 fatores que caracterizam a equipe de desenvolvimento envolvida no 
projeto de software e o ambiente de trabalho que atuam. Assim como nos fatores 
técnicos cada fator deve receber uma nota de 0 até 5, sendo 0 usado quando a 
qualidade do fator for ruim no ambiente de trabalho, ou quando ele não está 
presente, e 5 quando for ótima. 
 
Tabela 26 - Fatores ambientais e seus pesos 
Fator Ambiental Peso do fator 
E1. Familiaridade com o processo de desenvolvimento 1,5 
E2. Experiência com a aplicação 0,5 
E3. Experiência com orientação a objetos 1 
E4. Capacidade do analista líder 0,5 
E5. Motivação 1 
E6. Estabilidade de requisitos obtida historicamente 2 
E7. Equipe em tempo parcial -1 
E8. Dificuldade com a linguagem de programação -1 
Fonte: adaptado de Wazlawick, 2013 
 
Depois de atribuir nota para cada um dos 8 fatores ambientais apresentados 
na Tabela 26, deve-se multiplicar a nota pelo peso equivalente do fator e então 
somá-las para se construir o valor da variável . Perceba que fatores 
ambientais (T7 e T8) podem receber valores negativos, pois existem pesos -1. 
 
, 
 
Em que varia de 1 até 8. Portanto normalizando o é possível calcular 
o , aplicando a seguinte fórmula: 
 
 
 
 
2.2.2 UCP– Pontos de Caso de Uso Ajustados 
 
Após estabelecer o valor de pontos de casos de uso não ajustados ( ) e 
calcular os fatores de ajuste técnicos ( ) e ambientais ( ) é possível calcular o 
valor total do sistema em Pontos de Caso de Uso ( ) ajustados, através da 
fórmula: 
 
 
 
35 
www.virtual.ucdb.br | 0800 647 3335 
 
 
 
i. Esforço (E) 
 
Os pontos de caso de uso serão úteis para se calcular a estimativa de 
esforço, ou seja, o trabalho necessário para o desenvolvimento do projeto. Para 
transformar o em esforço aplica-se a fórmula: 
 
 
 
Onde é calculado baseado em projetos anteriores. Para isso, soma-se o 
tempo total de trabalho do desenvolvedor e o divide pelo número de pontos de caso 
de uso ( ) estimado. Por exemplo: se o trabalho total em umconjunto de projetos 
foi de 1000 desenvolvedores-hora e o desses projetos era de 50, então 
 de trabalho por desenvolvedor, ou seja, = 20. 
Outra forma de determinar foi proposta por Schneider e Winters em 1998: 
1. Conta-se a quantidade de fatores técnicos entre T1 e T6 que receberam 
nota maior que 3; 
2. Soma-se o valor obtido à quantidade de fatores ambientais entre E7 e E8 
que receberam valor menor que 3. 
Se o somatório for igual a 2, = 20 horas/UCP; 
Se o somatório for igual a 3 ou 4, = 28 horas/UCP; 
Se o somatório for 5 ou mais, = 36 horas/UCP 
 
 com horas igual a 36 representam que o projeto precisa ser revisto com 
urgência e a equipe precisa de treinamento para se adequar às tecnologias, aos 
requisitos, ou até mesmo melhorar os conhecimentos acerca de linguagem de 
programação, reuso e orientação a objetos. 
É recomendável dividir o resultado obtido com a fórmula de esforço por 158, 
que representa a média de horas de trabalho em um mês, obtendo a unidade de 
medida pessoas-mês. 
 
 
 
 
 
 
36 
www.virtual.ucdb.br | 0800 647 3335 
2.3 Métricas orientadas a Equipe: Planning Poker 
 
O Planning Poker é uma 
técnica de estimativa bastante 
empregada em projetos ágeis, 
principalmente em projetos que 
utilizam o framework do Scrum. A 
principal diferença dessa técnica 
para as demais é que toda a 
equipe de desenvolvimento 
envolvida na implementação do 
Sprint deve colocar a sua visão de 
complexidade para que juntos 
possam chegar a um consenso de 
indicador de complexidade para o 
time. Ou seja, nos demais métodos apresentados nesse material didático, uma 
pessoa da equipe com um bom conhecimento acerca de cálculos de prazos e 
esforço estima um prazo para uma determinada atividade de um projeto e repassa 
para a equipe executar, no Planning Poker a equipe inteira deve chegar a um 
acordo sobre a atividade. 
 Dessa forma, o modo de decisão do Planning Poker estabelece 
intensamente o conceito de colaboração e comprometimento de toda a equipe. 
Grenning em 2002 ponderou que essa é a melhor ferramenta encontrada para 
estimar tamanho de projetos em metodologias ágeis, pois é uma técnica que utiliza 
a interação de todos os membros da equipe para determinar o tamanho de um 
software (COHN, 2005). 
No Planning Poker a estimativa é realizada simulando um jogo de cartas. 
Durante a reunião de um Sprint, cada 
integrante da equipe de desenvolvimento tem 
um baralho com 13 cartas a sua disposição 
(Figura 3). Essas cartas trazem números 
similares à sequência de Fibonacci, que 
representam um número de complexidade. 
CTIC-UFPA em 2011 diz que existe um 
A sequência de Fibonacci foi 
proposta por um matemático e 
cada termo (Tn) que a compõe é 
igual à soma dos dois termos 
anteriores a ele na sequência, 
com exceção dos dois primeiros 
números que são iguais a 1: 
 
Scrum é uma metodologia ágil para gestão 
e planejamento de projetos de software. No 
Scrum, os projetos são divididos em ciclos 
(tipicamente mensais) chamados de 
Sprints. O Sprint representa um ciclo de 
tempo dentro do qual um conjunto de 
atividades deve ser executado. 
(Desenvolvimento Ágil, 2014). 
Desenvolvimento ágil é um processo de 
desenvolvimento que divide o software em 
construção em pequenos pedaços e utiliza 
ciclos para implementar essa parcela de 
software, garantindo que ela seja funcional, 
testada e aprovada. Ou seja, a cada ciclo o 
software é acrescido de funcionalidades e 
no último tem-se um software completo 
pronto para ser entregue ao cliente. 
 
 
 
 
37 
www.virtual.ucdb.br | 0800 647 3335 
propósito ao utilizar uma sequência não linear na determinação de estimativas. O 
objetivo de utilizar estes números é que o intervalo entre os valores permite 
visualizar melhor as diferenças de complexidade entre as funcionalidades. 
 
Figura 3 - Cartas do Planning Poker 
 
 
Fonte: Crisp Konsulter, 20166 
 
Em métodos ágeis, as atividades a serem desenvolvidas são baseadas em 
estórias. Estórias representam a parte do produto a ser implementada, pois contêm 
uma descrição detalhada do que deve ser considerado para a implementação. Para 
isso, é necessário envolver diferentes membros da equipe para criá-las, garantindo 
assim que elas serão o mais abrangente possível, pois cada um pode levantar 
questões relacionadas a sua atuação dentro do projeto. 
Essas estórias são planejadas a priori pela equipe sem que ela saiba a 
extensão propriamente do que irá se implementar. Isso não quer dizer que os 
membros da equipe não entendem o contexto da estória, pelo contrário, quanto 
mais compreensão da natureza da estória melhor ela será e mais os membros da 
equipe vão se ajudar para desenvolver uma boa iteração. Depois de estimar uma 
estória, é necessário discutir e chegar a um consenso de qualquer questão em 
aberto referente a ela, para então ter uma estória definida. 
Após definir as estórias, chega o momento de aplicar o Planning Poker para 
decidir a complexidade da estória. Para isso, um coordenador eleito descreve uma 
estória para a equipe e o grupo faz uma contagem até três e então todos devem 
apresentar uma carta que representa a complexidade da estória apresentada na 
 
6 https://www.crisp.se/bocker-och-produkter/planning-poker 
 
 
 
38 
www.virtual.ucdb.br | 0800 647 3335 
sua opinião. Essa complexidade deve envolver tempo e esforço necessário para 
aquela estória. É importante que todos mostrem a carta simultaneamente, pois a 
técnica acredita que o acerto no cálculo de esforço vem da colaboração natural dos 
membros, sem que nenhum exerça influência sobre o outro. 
 
2.3.1 Entendendo o Baralho 
Na Figura 3 é apresentado um exemplo de baralho da técnica Planning 
Poker, os valores representados por cada carta podem ser entendidos dessa forma: 
• O valor zero (0) representa que na opinião do membro da equipe a 
estória está finalizada ou é muito simples de resolver e por isso, pode 
ser finalizada em demanda de minutos. 
• O símbolo interrogação (?) representa que na opinião do membro da 
equipe ele não tem conhecimento suficiente para estimar um esforço 
para a estória em questão. 
• O símbolo Café representa que na opinião do membro da equipe ele 
necessita refletir sobre a estória antes de tomar uma decisão e por 
isso está pedindo uma parada na reunião. 
• Valor igual a 100 representa que, na opinião do membro da equipe, a 
estória é muito grande e necessita de mais de uma iteração para ser 
resolvida. Por isso, sugere que a estória seja subdivida em estórias 
menores para reduzir sua complexidade. 
• Valores abaixo de cem (100) podem determinar a complexidade de 
uma estória (ver regras na Seção 2.3.2), sendo que valores até 20 
indicam que o membro da equipe acredita que a complexidade para 
resolver a estória é de baixa a média. Já o valor 40 representa uma 
complexidade alta. 
 
2.3.2 O jogo 
Após todos os membros presentes na reunião colocarem uma carta é feita 
uma contabilidade dos valores obtidos: 
• Se todos os valores das cartas convergirem e forem menores do que 
100, adota-se esse valor como a complexidade da estória; 
• Se existem valores que estão divergindo, ou seja, se membros da 
equipe colocam cartas com valores diferentes para uma mesma 
 
 
 
39 
www.virtual.ucdb.br | 0800 647 3335 
estória, é pedido pelo coordenador que quem colocou o menor e o 
maior valor justifique a sua escolha, fazendo com que todos os 
membros da equipe reflitam mais uma vez sobre a estória. Após a 
exposição de motivos, o coordenador propõe uma nova rodada. 
o Se dessa vez todos os valores convergirem e forem menores 
que 100, o valor é adotado como complexidade da estória; 
o Senão, a complexidade da estória é definida sobre a 
contabilidade do valor que obteve maior estimativa 
▪ Se o valor que obteve maior estimativa foi a interrogação 
(?), a estória deve ser detalhada novamente. 
▪ 
 
Haugen (2006), afirmou haver umamelhora na eficiência das estimativas 
com valores por estórias quando utilizada esta técnica para atribuição da 
complexidade. Mas observe que o Planning Poker deve ser utilizado por equipes 
alocadas geograficamente próximas. Além disso, deve-se lembrar que após definida 
uma complexidade para uma estória, toda a equipe vai trabalhar nela e essa 
discussão acerca dela pode levar a um membro da equipe que tem familiaridade 
com as atividades a serem desenvolvidas a influenciar os demais membros a 
atribuir uma complexidade baixa, o que pode prejudicar a estimativa de esforço 
acerca daquela estória. 
 
2.3.3 Utilizando Planning Poker para definir esforço 
Vimos que um Sprint define algumas estórias e a complexidade delas. Mas 
como estimar tempo e esforço necessário para implementar uma estória baseada 
na complexidade atribuída? 
Como o Planning Poker se baseia na união da equipe de desenvolvimento do 
projeto, o cálculo de tempo e esforço também depende dessa união. A seguinte 
lógica deve ser aplicada: 
1) Dentre todas as estórias discutidas no Sprint, seleciona-se a de menor 
complexidade atribuída para a equipe trabalhar inicialmente. 
Observação: Pode-se optar por novas discussões empregando novas rodadas em 
caso de grandes divergências de opiniões. Mas o ideal é não ultrapassar o total de 
quatro rodadas. 
 
 
 
40 
www.virtual.ucdb.br | 0800 647 3335 
2) Após a implementação dessa estória é feita uma estimativa de tempo e 
esforço (desenvolvedores–mês) necessários para resolver a estória com 
sucesso. 
3) Para as demais estórias, é feito um cálculo para estimar esforço e tempo 
considerando essa primeira estória como referência. Ou seja, a primeira 
estória que tem a menor complexidade dentre todas do Sprint, servirá de 
base para a próxima estória a ser trabalhada, que tem a segunda menor 
complexidade entre todas e assim sucessivamente. O cálculo de esforço 
e tempo é baseado na relação da complexidade da primeira estória com 
as demais e assim é possível estimar o esforço e tempo necessário para 
resolvê-las baseado no tempo (TA) e esforço da primeira estória. Por 
exemplo, se a primeira estória tinha complexidade igual a 2 e a segunda 
estória tem complexidade igual a 8, o esforço e tempo despendido para 
resolver a segunda estória será quatro vezes maior do que os utilizados 
na primeira estória: 
 
 
 
Em que representa o esforço da estória que será calculado baseado na 
primeira estória do Sprint, representa a complexidade atribuída a essa 
estória com a técnica de Planning Poker, indica o esforço utilizado para resolver 
a primeira estória e representa a complexidade atribuída para a primeira 
estória com a técnica de Planning Poker. 
 
 
Tem-se que representa o tempo da estória que será calculado utilizando a 
primeira estória do Sprint como referência, representa a complexidade 
atribuída a essa estória com a técnica de Planning Poker, o tempo utilizado para 
resolver a primeira estória e a complexidade atribuída para a primeira 
estória com a técnica de Planning Poker. 
 
 
 
41 
www.virtual.ucdb.br | 0800 647 3335 
 
 
Exercício 2 
 
1. Considere que você está realizando a estimativa do software a ser desenvolvido 
através da métrica de Pontos por Função. Até o momento, você já realizou os três 
primeiros passos da aplicação da métrica, e obteve os seguintes valores: 
I. N = 51, referente às características gerais do sistema 
II. PF = 652, referente aos pontos por função identificados 
Dando prosseguimento à aplicação da métrica, nas próximas etapas você terá que 
calcular o FAV (Fator de Ajuste de Valor), que será utilizado para ajustar a 
complexidade dos pontos de função de acordo com as características do sistema e 
encontrar o PFA (Pontos por Função Ajustados). 
Aplicando as respectivas fórmulas, quais serão os valores do FAV e do PFA 
encontrados? 
 
a) FAV = 1.16 e PFA = 562.06 
b) FAV = 1.6 e PFA = 765.91 
c) FAV = 0.61 e PFA = 567.24 
d) FAV = 1.6 e PFA = 1043,2 
e) FAV = 1.16 e PFA = 756.32 
 
2. Calcule (Pontos de Caso de Uso Ajustados de um projeto em 
desenvolvimento. Para isso, utilize as seguintes informações: 
I. O valor de Pontos de Caso de Uso Não Ajustados ( é igual a 100. 
II. Os fatores técnicos ( tem valor igual a 1. 
Em relação aos fatores ambientais sabe-se os seguintes dados: 
 
Fator Ambiental Peso do fator Nota 
E1. Familiaridade com o processo de 
desenvolvimento 
1,5 3 
E2. Experiência com a aplicação 0,5 2 
E3. Experiência com orientação a objetos 1 5 
E4. Capacidade do analista líder 0,5 3 
E5. Motivação 1 3 
E6. Estabilidade de requisitos obtida historicamente 2 1 
E7. Equipe em tempo parcial -1 3 
E8. Dificuldade com a linguagem de programação -1 2 
 
 
 
42 
www.virtual.ucdb.br | 0800 647 3335 
 
a) 101 
b) 104 
c) 110 
d) 114 
e) 140 
 
3. Utilizando o UCP (Pontos de Caso de Uso Ajustados) calculado no exercício 
anterior, produza a estimativa de esforço baseada em pontos de caso de uso. 
Para isso, determine IP baseado na técnica de Schneider e Winters com 
somatório igual a 4. Observação. Transforme seu resultado de esforço para a 
unidade pessoas-mês dividindo-o por 158. 
a) E=18,5 pessoas-mês 
b) E=20 pessoas-mês 
c) E=16,5 pessoas-mês 
d) E=21,5 pessoas-mês 
e) E=12 pessoas-mês 
 
4. Em projeto desenvolvido pelas diretrizes do desenvolvimento ágil foi 
determinado por intermédio do Planning Poker que a estória mais simples de 
um Sprint tinha complexidade igual a 2 e o esforço necessário para realizá-la 
foi de 5 desenvolvedores-mês. Você deve calcular qual o esforço necessário 
para que uma estória com complexidade igual a 20 desse mesmo Sprint seja 
implementada. 
a) 10 desenvolvedores-mês 
b) 20 desenvolvedores-mês 
c) 50 desenvolvedores-mês 
d) 100 desenvolvedores-mês 
e) 5 desenvolvedores-mês 
 
 
 
 
 
43 
www.virtual.ucdb.br | 0800 647 3335 
UNIDADE 3 – MODELO COCOMO (I E II) 
 
O modelo COCOMO (Construtive Cost Model) foi lançado inicialmente em 
1981 por Boehm e é considerado um modelo empírico, uma vez que foi criado 
baseado na experiência com 63 diferentes projetos de software, ao longo de um 
período de 15 anos (TEIXEIRA; SANCHES, 2000). Com a observação dos projetos, 
foi possível gerar fórmulas envolvendo tamanho do sistema, fatores de projeto e 
esforço que embasam o COCOMO. 
O primeiro COCOMO – 1981 (COCOMO I) considera que os softwares são 
desenvolvidos baseando-se no 
modelo de desenvolvimento 
Cascata (processo sequencial) e 
utilizam apenas linguagens de 
programação padronizadas (como 
por exemplo C, COBOL ou 
FORTRAN). É dividido em três níveis de complexidade crescente, que evoluem 
conforme o grau de informação que a equipe desenvolvedora tem do software em 
desenvolvimento (WAZLAWICK, 2013): 
1. Implementação básica: quando a única informação sobre o sistema 
efetivamente disponível é o número estimado de linhas de código; 
2. Implementação intermediária: Quando certos fatores relativos ao 
produto, suporte computacional, pessoal e processo são conhecidos e 
podem ser avaliados para o sistema ser produzido. 
3. Implementação Avançada: Quando for necessário subdividir o 
sistema em subsistemas e distribuir as estimativas de esforço por fase 
e atividade. 
Além dos níveis, esse modelo considera também o caráter do software em 
desenvolvimento. Atribuindo um modo orgânico (baixo risco) para projetos que 
envolvem pouca ou nenhuma interação com dispositivos de hardware e em que a 
equipe de desenvolvimento já tinha domínio do escopo da aplicação. O modo 
semidestacado (médio risco) era atribuído para projetos com interações expressivas 
com hardware, mas que a equipe ainda tivesse um domínio mínimo do escopo da 
aplicação e por fim, o modo embutido (alto risco) era atribuído para projetos com 
Modelo Cascata: divide o desenvolvimento do 
software em 5 etapas (comunicação, 
planejamento, modelagem, construção e 
implantação) sequenciais,