Estimativas em Engenharia de Software

Prévia do material em texto

ENGENHARIA DE 
SOFTWARE 
Adriana de Souza
Técnicas para estimativa 
de tamanho e de custo
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Classificar as técnicas de estimativas function points analysis (FPA), use 
case points (UCP) e constructive cost model (COCOMO).
  Identificar as diferenças entre as técnicas (FPA, UCP e COCOMO).
  Avaliar as técnicas de estimativas (FPA, UCP e COCOMO).
Introdução
Neste capítulo, você vai estudar sobre técnicas para estimativa de ta-
manho e de custo. Para o sucesso de um projeto de desenvolvimento 
de software, trabalhar com estimativas é essencial. Quando falamos em 
sucesso, o esperado é que o produto, além de atender às necessidades 
do usuário, seja desenvolvido dentro do tempo estimado e de acordo 
com o orçamento planejado.
Com as estimativas, podemos calcular: esforço de desenvolvimento 
de software, custo de software, taxa de produção de software, taxa de 
manutenção de software e nível de produtividade da equipe. Continue 
lendo o capítulo e aprenda sobre as técnicas de estimativas de tamanho 
e de custo de um projeto de software.
As técnicas para estimativas
Fazer estimativas não é uma tarefa simples. Fazer estimativas requer esforço e 
talvez você tenha que fazer uma estimativa inicial com base em uma defi nição 
de requisitos de usuário de mais alto nível. 
Alguns desafios, tais como precisar usar novas tecnologias, desconheci-
mento das habilidades das pessoas envolvidas no projeto, entre outros, dificul-
tam estimar custos de desenvolvimento precisamente no início de um projeto.
A estimativa de custo de projeto é autossuficiente e é usada para definir o 
orçamento do projeto e o produto é ajustado para cumprir o planejado. Para 
auxiliar nas estimativas, existem algumas técnicas que podem ser usadas. Todas 
elas contam com o conhecimento explícito dos gestores de projetos que usam os 
projetos anteriores para chegar a uma estimativa de recursos necessários para 
o desenvolvimento do projeto atual. Porém, diferenças significativas podem 
acontecer entre projetos passados e futuros, podendo afetar as estimativas. 
Para auxiliar nas estimativas, existem algumas técnicas. Dentre elas, podemos 
citar: FPA, UCP e COCOMO.
A técnica FPA
Segundo Summerville, a técnica FPA dimensiona uma aplicação na perspectiva 
do usuário fi nal, ao invés de levar em consideração as características técnicas 
da linguagem utilizada.
Na visão do usuário, essa aplicação nada mais é do que um conjunto de 
funções do negócio que o auxiliam na realização de suas tarefas. A análise 
dessa função é feita sob a ótica do que será fornecido, e não de como é for-
necido ou “como” é abstraído, assim fica mais fácil para o usuário entender 
o que será entregue. 
Na técnica de análise de pontos de função (FP), somente componentes 
visíveis ao usuário são considerados para o dimensionamento. Essa técnica 
considera a funcionalidade geral que a aplicação proporciona ao usuário.
A FPA tem como objetivo medir o que o software faz e, dessa forma, de-
terminar o seu tamanho. A partir daí as estimativas de esforço, produtividade 
e custo são calculadas ajudando a:
  prover uma métrica de medição para apoiar a análise de produtividade 
e da qualidade.
  prover uma forma de estimar o tamanho do software.
  prover um fator de normalização para comparação de software.
As premissas do FPA são:
  entradas externas (EE).
  saídas externas (SE).
  arquivos lógicos internos (ALI).
  arquivos de interface externa (AIE).
  consulta externa (CE).
Técnicas para estimativa de tamanho e de custo2
Após levantar as funcionalidades do software, um valor numérico é atribuí-
do a cada uma delas de acordo com a complexidade. Veja os Quadros 1 a 5.
Fonte: Adaptado de Paula Filho (2008).
Campos (TD)
Arquivos (AR)
1 a 4 itens 
de dados 
referenciados
5 a 15 itens 
de dados 
referenciados
16 ou mais 
itens de 
dados 
referenciados
0 ou 1 tipo 
de arquivo 
referenciado
Simples Simples Médio
2 tipos de arquivos 
referenciados
Simples Médio Complexo
3 ou mais tipos 
de arquivos 
referenciados
Médio Complexo Complexo
Quadro 1. Complexidade das EEs
Fonte: Adaptado de Paula Filho (2008).
Campos (TD)
Arquivos (AR)
1 a 5 itens 
de dados 
referenciados
6 a 19 itens 
de dados 
referenciados
20 ou mais 
itens de 
dados 
referenciados
0 ou 1 tipo 
de arquivo 
referenciado
Simples Simples Médio
2 ou 3 tipos 
de arquivos 
referenciados
Simples Médio Complexo
4 ou mais tipos 
de arquivos 
referenciados
Médio Complexo Complexo
Quadro 2. Complexidade das saídas externas (SE)
3Técnicas para estimativa de tamanho e de custo
Fonte: Adaptado de Paula Filho (2008).
Campos (TD)
Registros (TR) 
1 a 19 itens 
de dados 
referenciados
20 a 50 itens 
de dados 
referenciados
51 ou mais 
itens de 
dados 
referenciados
1 tipo de registro 
lógico
Simples Simples Médio
2 a 5 tipos de 
registros lógicos
Simples Médio Complexo
6 ou mais tipos de 
registros lógicos
Médio Complexo Complexo
Quadro 3. Complexidade dos arquivos lógicos internos (ALI)
Fonte: Adaptado de Paula Filho (2008).
Campos (TD)
Registros (TR) 
1 a 19 itens 
de dados 
referenciados
20 a 50 itens 
de dados 
referenciados
51 ou mais 
itens de 
dados 
referenciados
1 tipo de registro 
lógico
Simples Simples Médio
2 a 5 tipos de 
registros lógicos
Simples Médio Complexo
6 ou mais tipos de 
registros lógicos
Médio Complexo Complexo
Quadro 4. Complexidade de arquivos de interface externa (AIE)
Técnicas para estimativa de tamanho e de custo4
Fonte: Adaptado de Paula Filho (2008).
Campos (TD)
Arquivos (AR)
1 a 5 itens 
de dados 
referenciados
6 a 19 itens 
de dados 
referenciados
20 ou mais 
itens de 
dados 
referenciados
0 ou 1 tipo 
de arquivo 
referenciado
Simples Simples Médio
2 ou 3 tipos 
de arquivos 
referenciados
Simples Médio Complexo
4 ou mais tipos 
de arquivos 
referenciados
Médio Complexo Complexo
Quadro 5. Complexidade dos consulta externa (CE)
Após levantar o número de ocorrências, aplica-se o peso de acordo com a 
complexidade para se chegar ao resultado. Um exemplo é apresentado na Figura 1.
Figura 1. Exemplo de tabela para cálculo de pontos.
Fonte: Paula Filho (2008).
Função
Entrada externa
Simples
Médio
Complexo
Simples
Médio
Complexo
Total 1
Total 2
Simples
Médio
Complexo
× 3 =
× 4 =
× 6 =
=
× 4 =
× 5 =
× 7 =
=
× 3 =
× 4 =
× 6 =
=
× 5 =
× 7 =
× 10 =
=
× 7 =
× 10 =
× 15 =
=
Total 5
Simples
Médio
Complexo
Total 3
Simples
Médio
Complexo
Total 4
Saída externa
Arquivos lógicos
internos
Arquivo
interface
externo
Consultas
Nº de ocorrências Complexidade Peso Resultado
5Técnicas para estimativa de tamanho e de custo
Esta técnica serve para diversos propósitos para o desenvolvimento de 
software, pois ajuda a minimizar a subjetividade nas estimativas por meio da 
padronização de critérios, de acordo com os Quadros 1 a 5 anteriores. Veja 
a Figura 2 a seguir.
Figura 2. Passos da contagem por FP.
Fonte: Adaptada de Ribeiro (2013, documento on-line).
Determinar
tipo de
contagem
Identi�car
a fronteira
da aplicação
Contar
funções tipo
dados
Contar
funções tipo
transação
Calcular
número de
pontos de
função
ajustados
Calcular
pontos de
função não
ajustados
Calcular 
valor do
fator de
ajuste
A técnica UCP
A técnica “pontos por caso de uso” foi baseada na análise de FP. Essa técnica 
estima o tamanho de um software baseado no modo como os usuários utilizarão 
o sistema; pela complexidade das ações que são requeridas por cada usuário 
e pela análise do workfl ow da realização das tarefas.
Essa técnica estima o tamanho do software na fase de levantamento de 
casos de uso. Para isso, utiliza os próprios documentos gerados nessa fase para 
subsidiar o cálculo dimensional. Tem como objetivo medir software orientado 
a objeto e tem sua utilização mais simplificada que a UCP. 
A UCP, a exemplo da FPA, também utiliza tabelas declassificação de 
complexidade, conforme mostram a seguir os Quadros 6 e 7.
Técnicas para estimativa de tamanho e de custo6
Fonte: Adaptado de Paula Filho (2008).
Complexidade Definição Peso
Simples Quando o ator representa um sistema 
externo que é acessado por meio de API.
1
Médio Quando o ator representa um 
sistema externo, acessado por meio 
de um protocolo de comunicação, 
por exemplo TCP/IP.
2
Complexo Quando o ator interage com o sistema 
por meio de uma interface gráfica GUI.
3
Quadro 6. Classificação dos atores envolvidos
Fonte: Adaptado de Paula Filho (2008).
Complexidade Definição Peso
Simples Quando o caso de uso tem três ou menos 
transações, incluindo cenários alternativos, 
e sua realização deve acontecer com menos 
de cinco objetivos (classes de análise).
5
Médio Quando o caso de uso tem de 4 a 7 
transações, incluindo cenários alternativos, 
e sua realização deve acontecer com 
5 a 10 objetivos (classes de análise).
10
Complexo Quando o caso de uso tem mais de sete 
transações, incluindo cenários alternativos, 
e sua realização deve acontecer com mais 
de 10 objetivos (classes de análise).
15
Quadro 7. Classificação dos casos de uso
7Técnicas para estimativa de tamanho e de custo
Métricas
A primeira métrica a ser gerada é a unajusted use case point (UUCP) ou pontos 
de casos de uso não ajustado, onde:
UCCP = total dos pesos dos atores relacionados + 
total de pesos dos casos de uso relacionados.
A segunda métrica a ser gerada é o technical complexity factor (TCF) ou 
fator de complexidade. Esse fator tem uma escala de 0 a 5, onde o 0 é o 
menos relevante e o 5 é o mais relevante. Observe o Quadro 8.
Fonte: Adaptado de Paula Filho (2008).
Código 
fator Descrição do fator Peso
Valor 
(fator) Resultado
F1 Sistema distribuído 2 0
F2 Performance 1 0
F3 Eficiência para o usuário 
final (on-line)
1 0
F4 Processamento 
interno complexo
1 0
F5 Código deve ser recusável 1 0
F6 Fácil para instalar 0,5 0
F7 Fácil para usar 0,5 0
F8 Portável 2 0
F9 Fácil para mudar 1 0
F10 Concorrente 1 0
F11 Seguro 1 0
F12 Fornece acesso direto 
para third parties (sistemas/
componentes externos)
1 0
F13 É requerido treinamento do 
usuário para usar o software
1 0
Quadro 8. Cálculo de fator
Técnicas para estimativa de tamanho e de custo8
O valor do fator será atribuído pelo gestor de acordo com o estipulado da 
relevância. Para calcular, utiliza-se a seguinte fórmula:
TCF = 0,6 + (0,01 ∙ TFATOR)
A terceira métrica gerada é o environmental factor (EF) ou fator ambiente. 
Esse fator tem uma escala de 0 a 5, onde 0 é o menos relevante e 5 é o mais 
relevante. Observe o Quadro 9.
Fonte: Adaptado de Paula Filho (2008).
Código 
fator Descrição do fator Peso
Valor 
(fator) Resultado
F1 Familiaridade com 
o processo de 
desenvolvimento orientado 
a objetos adotado
1,5 0
F2 Colaboradores de 
meio período
-1 0
F3 Capacidade de análise 0,5 0
F4 Experiência em 
desenvolvimento de 
aplicações deste gênero
0,5 0
F5 Experiência em 
orientação a objetos
1 0
F6 Motivação 1 0
F7 Dificuldade na linguagem 
de programação
-1 0
F8 Requisitos estáveis 2 0
Quadro 9. Cálculo de fator
O valor do fator também será atribuído pelo gestor de acordo com o esti-
pulado da relevância. Para calcular, utiliza-se a seguinte fórmula:
EF = 1,4 + (-0,03 ∙ EFATOR)
9Técnicas para estimativa de tamanho e de custo
Tendo o valor dessas fórmulas, é possível calcular o UCP final, onde:
UCP = UUCP ∙ TCF ∙ EF
Após encontrar o UCP final, podemos encontrar a estimativa de horas, 
em que a maioria das literaturas sugerem a aplicação de 20 horas por pontos 
de caso de uso. Então:
estimativa de horas = UCP ∙ 20
Fazendo esses cálculos para os casos de uso, você terá as estimativas 
necessárias.
O UCP e a FPA não consideram apenas o desenvolvimento do software, mas também 
toda a parte de análise, projeto, teste e treinamento, ou seja, todo o projeto.
A técnica COCOMO
A técnica COCOMO tornou-se um dos modelos de estimativa de custo de 
software mais usados. Essa técnica foi criada por meio de coleta de dados 
com base em um grande número de projetos de software (SOMMERVILLE, 
2007). Existem duas versões: COCOMO e COCOMO II.
COCOMO é apresentado na forma de um conjunto de modelos divididos 
em simples, moderados e incorporados (Quadro 10).
Técnicas para estimativa de tamanho e de custo10
Fonte: Adaptado de Sommerville (2007).
Complexidade Descrição
Simples Aplicações bem compreendidas, desenvolvidas por 
pequenas equipes. Modelo estatístico que calcula o 
esforço de desenvolvimento de software e seu custo em 
função do tamanho de linhas de código desenvolvido.
Moderada Projetos mais complexos em que os membros da 
equipe podem ter experiência limitada com os 
sistemas relacionados. Modelo que calcula o esforço de 
desenvolvimento do software em função do tamanho 
do programa que inclui custo, avaliação subjetiva do 
produto hardware, pessoas e atributos do projeto.
Incorporada Projetos complexos nos quais o software é parte de 
um conjunto complexo e fortemente acoplado de 
hardware, software, leis e procedimentos operacionais.
Incorpora características da versão intermediária com uma 
avaliação de impacto de custo em cada passo de todo o projeto.
Quadro 10. Modelos COCOMO
Modelo COCOMO básico
A versão COCOMO considerava que o software seria desenvolvido de acordo 
com o modelo tradicional cascata, usando linguagem de programação como 
C e Fortran. Porém, desde a sua proposta inicial, muitas mudanças ocorreram 
no desenvolvimento de software. 
Esse modelo evoluiu para um modelo de estimativas mais abrangentes, o 
COCOMO II, que reconhece abordagens diferentes para o desenvolvimento 
de software, como a prototipação, o desenvolvimento por composição de 
componentes e o uso de programação de banco de dados. Veja no Quadro 11 
as áreas de que trata.
11Técnicas para estimativa de tamanho e de custo
Fonte: Adaptado de Sommerville (2007).
Modelo de composição 
de aplicação
Usado durante os primeiros estágios da 
engenharia de software, em que o protótipo 
das interfaces de usuário, a consideração da 
interação de software e de sistema, a avaliação 
do desempenho e a avaliação da maturidade 
da tecnologia são de suma importância.
Modelo de estágio 
do início do projeto
Usado quando os requisitos tiverem 
sido estabilizados e a arquitetura básica 
de software tiver sido estabelecida.
Modelo de estágio 
pós-arquitetura
Usado durante a construção do software.
Quadro 11. Modelos do COCOMO básico
Veja a seguir as equações COCOMO básicas.
E = Ab(KLOC)exp(Bb) - esforço aplicado pessoa-mês
D = Cb(E.exp(Db)) - tempo de desenvolvimento (meses cronológicos)
P = E/D
Onde:
E é o esforço aplicado pela pessoa no mês;
D é o tempo de desenvolvimento em meses cronológicos;
KLOC é o número calculado de linhas de código para o projeto (expressado em 
milhares);
P é o número das pessoas necessário.
Os coeficientes ab, bb, cb e db são dados no Quadro 12.
Técnicas para estimativa de tamanho e de custo12
Fonte: Adaptado de Sommerville (2007).
Projeto de 
software ab bb cb db
Orgânico 2.4 1.05 2.5 0.38
Semidestacado 3.0 1.12 2.5 0.35
Embutido 3.6 1.20 2.5 0.32
Quadro 12. Coeficientes
Modelo COCOMO intermediário
É a ampliação do modelo básico ampliado para levar em consideração os 
atributos direcionadores de custo, tais como:
  atributos do produto (confiabilidade, tamanho BD e complexidade);
  atributos do hardware (restrições de desempenho, memória, etc.);
  atributos de pessoal (experiência);
  atributos de projeto (uso de case, metodologias, cronograma de ativi-
dades, etc.);
Total = 15 atributos (pontua-se em uma escala de 0 a 6 pontos, onde 0 é 
muito baixo e 6 é muito alto).
Classificação:
  determina-se um multiplicador de esforços;
  calcula-se o fator de ajuste de esforço, em que os valores variam de 
0.9 a 1.4.
13Técnicas para estimativa de tamanho e de custo
Veja a seguir as equações COCMO intermediário.
E = Ai(LOC). Exp(bi) × FAE (pessoa-mês)Onde:
E é o esforço aplicado em pessoas por mês;
KLOC é o número de linhas de código (expressado em milhares) para o projeto;
EAF é o fator calculado acima.
Os coeficientes ai e bi são dados no Quadro 13.
Fonte: Adaptado de Sommerville (2007).
Projeto de software ai bi
Início (orgânico) 3.2 1.05
Meio (semidestacado) 3.0 1.12
Fim (embutido) 2.8 1.5
Quadro 13. Coeficientes
Para estimativas utilizando o COCOMO, pode-se usar o software.
A base de análise para os FPs são a análise de requisitos e a estimativa.
Técnicas para estimativa de tamanho e de custo14
PAULA FILHO, W. P. Engenharia de software: fundamentos, métodos e padrões. 3. ed. 
Rio de Janeiro: LTC, 2008.
RIBEIRO, G. Métricas de softwares. 2013. Disponível em: <http://es-it.blogspot.com/p/
metricas-de-softwares.html>. Acesso em: 20 out. 2018.
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson, 2007.
Leituras recomendadas
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem profissional. 
8. ed. Porto Alegre: Penso, 2016.
STEFFEN, J. B. O que são essas tais de metodologias Ágeis? 23 jan. 2012. Disponível em: 
<https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/
mas_o_que_s_c3_a3o_essas_tais_de_metodologias__c3_a1geis?lang=en>. Acesso 
em: 19 out. 2018.
15Técnicas para estimativa de tamanho e de custo
Conteúdo: