Estimando qualidade de software com COQUALMO

FUNDAÇÃO INSTITUTO DE ADMINISTRAÇÃO – FIA

MBA EM GESTÃO DA TECNOLOGIA DE INFORMAÇÃO

TURMA 14

MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE
BASEADO NA PREDIÇÃO DE DEFEITOS

EDWAGNEY I. S. LUZ

Matricula nº 14754

ORIENTADOR: Professor Ronaldo Zwicker

AGOSTO 2009

DEDICATÓRIA

Dedico este trabalho primeiramente a Deus, pois sem Ele não seria possível atingir essa meta.

Aos meus grandes e eternos “amigos-irmãos” Carlos Fernando e Adriane Maia que em
nenhum momento deixaram de dar um incondicional apoio, carinho, compreensão e
companheirismo para que eu pudesse alcançar mais esse objetivo em minha vida.

Aos meus irmãos Edward Luz e Dayse Luz pelo apoio, amizade e carinho de sempre.

Em especial aos meus pais Edvard Luz (in memorian) e Veigma Luz, pelo constante esforço,
dedicação, amor, carinho e compreensão em todos os momentos da minha vida, e que tanto
contribuíram para minha formação pessoal e profissional. Sem vocês, realmente nada disso
seria possível ser concretizado.

“É na simplicidade das coisas que encontramos a verdadeira felicidade.”

Edwagney Luz

AGRADECIMENTOS

Aos meus colegas de turma, com quem compartilhei as aulas durante a semana, manhãs de
sábado, noites no MSN compartilhando informações, enfim, deixo meus sinceros
agradecimentos pelo companheirismo, amizade, convivência e confiança durante todos esses
meses.

Aos meus colegas e amigos de trabalho Valquiria Costa, Ely Christina, Janaine Arruda,
Arilson Pinto, Eliseu Gomes, Daniele Ferraro, Nelson Junior e Alisson Hervatin, com quem
passei a maior parte do meu tempo e que me ensinam a ser um profissional e uma pessoa
melhor a cada dia. Deixo com vocês meus sinceros agradecimentos pelo carinho, amizade,
apoio, incentivo e confiança de sempre. Isso foi de fundamental importância para que eu
pudesse atingir essa meta.

Ao professor Aguinaldo Aragon pela ajuda e confiança dispensada, mesmo com o pouco
tempo de convivência.

Ao meu grande amigo e mestre André Luiz Alves, que tenho eterna gratidão pela a amizade,
ensinamentos de início de carreira, que hoje fazem a diferença entre ser apenas mais um
profissional e ser um profissional ético com valores bem equalizados e definidos, e
principalmente ensinamentos de como ser um grande ser humano, e pelo apoio e incentivo no
desenvolvimento deste trabalho.

A minha amiga Virgínia Elizabeth, pelo incentivo, ajuda na revisão deste trabalho e confiança
dispensada, mesmo com o pouco tempo de convivência. Meus sinceros agradecimentos.

Enfim, reservo este especial agradecimento à minha diretora Marise De Luca e aos meus
gerentes Koki Sakai e Maria Beatriz Kerber por sempre acreditarem em mim e na minha
capacidade profissional na condução dos projetos, e principalmente por me darem a
oportunidade de poder desenvolver mais este trabalho. A vocês meu muito obrigado.

“Amigos é a família que Deus nos ofereceu a chance de escolher.”

Edwagney Luz

RESUMO

A utilização de modelos e técnicas de estimativas de projetos de software auxilia na
busca contínua por projetos cada vez mais coesos, que terminem dentro do prazo e orçamento
previsto. Estimativas de tamanho, esforço e prazo são baseadas em uma vasta quantidade de
variáveis que ajudam a atingirmos um valor próximo do real. Entretanto, atualmente as
organizações buscam não apenas melhorar a estimativa de seus projetos em relação a
tamanho, esforço e prazo. É necessário que o produto apresente qualidade dentro de um nível
aceitável e solicitado pelo cliente.
Como estimar essa qualidade? Baseado em quais variáveis conseguiremos estimar a
qualidade de um produto?
Pesquisas de satisfação junto ao cliente é uma boa saída, porém somente funciona
quando o projeto já foi entregue e o produto está em uso. Encontrar um modelo adequado,
passivo de calibração e que envolva as variáveis corretas é o desafio de muitas empresas, e
essa foi uma das finalidades desse estudo. Encontrar um modelo preditivo de qualidade, que
possa facilmente ser usado e seja baseado em fatores e variáveis conhecidos.
A proposta desse trabalho é estudar e apresentar um modelo que surgiu como extensão
do modelo COCOMO II (COnstructive COst MOdel), que tem por finalidade estimar a
qualidade de um projeto de software baseado na predição de defeitos, usando características
específicas do projeto já levantadas através do modelo COCOMO II, auxiliando gerentes de
projetos a determinar a qualidade do produto baseado na densidade de defeitos que por sua
vez é um excelente modo de identificar a confiabilidade do produto. Este modelo é o
COQUALMO (COnstructive QUALity MOdel).

ABSTRACT

The use of software projects models and techniques estimation assists in the
continuous search for cohesion projects that finish on time and budget determined. Estimates
of size, effort and time are based on a great amount of variable that helps to reach an almost
real value. However, actually the organizations not only search to improve the project size,
effort and time estimations. It is necessary that the product presents a quality of an acceptable
and requested level for the customer.
How to estimates this quality? Which variable we will get used to estimate of the
product quality?
Research of satisfaction with the customer is a good idea, however it will only give
resulted when the project was delivered and the product is in use by customer. To find a
model adjusted, of easy calibration and that has the correct variable, is the challenge of the
many companies and this is the one of the reasons of this study. To find a predictive quality
model, that can easily used and to be based on factors and variable known.
The proposal of this study is to present a model that appeared as extension of the
COCOMO II (COnstructive COst MOdel), that is has the purpose to estimate the project
quality of software based on defects prediction, using specific characteristic of the project
through the model COCOMO II, helping project managers to determine the quality of the
product based of the defects density that in turn is early predictor of software reliability. This
model is called COQUALMO (COnstructive QUALity MOdel).

ÍNDICE

ÍNDICE DE FIGURAS ............................................................................................................ 8
ÍNDICE DE TABELAS ........................................................................................................... 9
ÍNDICE DE GRAFICOS ....................................................................................................... 12
ACRÔNIMOS E ABREVIAÇÕES ....................................................................................... 13
CAPÍTULO 1 – INTRODUÇÃO .......................................................................................... 15
1.1. CONSIDERAÇÕES INICIAIS......................................................................................... 15
1.2. OBJETIVO .................................................................................................................. 17
1.3. ESTRUTURA ............................................................................................................... 17
CAPÍTULO 2 – MODELOS E TÉCNICAS DE ESTIMATIVAS ..................................... 19
2.2. REGRESSÃO LINEAR .................................................................................................. 20
2.3. ANÁLISE POR PONTOS DE FUNÇÃO (APF) ................................................................ 26
2.3.1. O Processo de Contagem ................................................................................... 26
2.3.2. Determinando o Tipo de Contagem .................................................................. 27
2.3.3. Definindo a Fronteira da Aplicação e o Escopo da Contagem ....................... 28
2.3.4. Contagem de Função do Tipo DADO ............................................................... 28
2.3.5. Contagem de Função do Tipo TRANSAÇÃO .................................................. 29
2.3.6. Contagem dos Pontos de Função Não-Ajustados (PFNA) .............................. 31
2.3.7. Determinar Fator de Ajuste .............................................................................. 33
2.3.8. Determinar Ponto de Função Ajustado (PFA) ................................................ 35
2.3.9. Considerações Finais ........................................................................................ 35
2.4. COCOMO II (CONSTRUCTIVE COST MODEL II) .................................................... 36
2.4.1. Considerações Iniciais ....................................................................................... 36
2.4.2. Sub-modelos ....................................................................................................... 37
2.4.3. Estimativa de Esforço e Prazo........................................................................... 38
2.4.4. Número Médio da Equipe ................................................................................. 45
2.5. CONSIDERAÇÕES FINAIS ........................................................................................... 46
CAPÍTULO 3 – MODELO DE ESTIMATIVA DE QUALIDADE – COQUALMO
(CONSTRUCTIVE QUALITY MODEL) ........................................................................... 47
3.2. INTRODUÇÃO ............................................................................................................. 48
3.3. MODELO DE INJEÇÃO DE DEFEITOS DE SOFTWARE (DEFECT INTRODUCTION
SOFTWARE) (DI).................................................................................................................... 49
3.4. MODELO DE REMOÇÃO DE DEFEITOS DE SOFTWARE (DEFECT REMOVAL
SOFTWARE) (DR) .................................................................................................................. 57

3.5. CALIBRAÇÃO DO MODELO ........................................................................................ 62
CAPÍTULO 4 – APLICAÇÃO DOS MODELOS E TÉCNICAS DE ESTIMATIVAS
APRESENTADOS .................................................................................................................. 63
4.1. ESTIMANDO O TAMANHO DO PROJETO ..................................................................... 65
4.2. ESTIMANDO O ESFORÇO PARA REALIZAÇÃO DO PROJETO ..................................... 65
4.3. ESTIMANDO O PRAZO PARA A REALIZAÇÃO DO PROJETO ...................................... 66
4.4. ESTIMANDO O TAMANHO DA EQUIPE DO PROJETO ................................................. 66
4.5. ESTIMANDO A QUALIDADE DO PROJETO .................................................................. 66
4.5.1. Estimando a Quantidade de Defeitos Injetados ............................................... 66
4.5.2. Estimando a Quantidade de Defeitos Residuais ............................................... 67
4.6. CONSIDERAÇÕES FINAIS ............................................................................................ 68
CAPÍTULO 5 – CONCLUSÃO E TRABALHOS FUTUROS........................................... 70
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 72
ANEXOS ................................................................................................................................. 74

ÍNDICE DE FIGURAS

FIGURA 1 – MODELO DE CONFIGURAÇÃO DE DADOS. (FONTE: FERNANDES (FERNANDES, 1995, P.
117).................................................................................................................................... 20
FIGURA 2 – VISÃO GERAL DO PROCESSO DE CONTAGEM DE PONTOS DE FUNÇÃO. (FONTE:
VAZQUEZ (VAZQUEZ, SIMÕES, & MACHADO, 2003, P. 47) ................................................ 26
FIGURA 3 – INTRODUÇÃO E REMOÇÃO DE DEFEITOS DE SOFTWARE. (FONTE: SUNITA CHULANI
(CHULANI, STEECE, & BOEHM, DETERMINING SOFTWARE QUALITY USING COQUALMO,
2003)) ................................................................................................................................ 49
FIGURA 4 – MODELO DE INJEÇÃO DE DEFEITOS DE SOFTWARE. (FONTE: BARRY BOEHM
(BOEHM, ET AL., 2000)) ..................................................................................................... 51
FIGURA 5 – MODELO DE REMOÇÃO DE DEFEITOS DE SOFTWARE. (FONTE: BARRY BOEHM
(BOEHM, ET AL., 2000)) ..................................................................................................... 57

ÍNDICE DE TABELAS

TABELA 1 – AMOSTRAGEM DE DEFEITOS ................................................................................... 21
TABELA 2 – AMOSTRAGEM DE DEFEITOS POR TAMANHO DE SOFTWARE ..................................... 22
TABELA 3 – COMPLEXIDADE ALI E AIE. (FONTE: FERNANDES (FERNANDES, 1995, P. 123) ..... 29
TABELA 4 – RELAÇÃO DOS PESOS DE ALI E AIE PARA DETERMINAÇÃO DOS PF NÃO-AJUSTADOS.
(FONTE: FERNANDES (FERNANDES, 1995, P. 125) .............................................................. 29
TABELA 5 – COMPLEXIDADE DE EE. (FONTE: FERNANDES (FERNANDES, 1995, P. 123) ............ 29
TABELA 6 – RELAÇÃO DOS PESOS DE EE PARA DETERMINAÇÃO DOS PF NÃO-AJUSTADOS.
TABELA 7 – COMPLEXIDADE DE SE. (FONTE: FERNANDES (FERNANDES, 1995, P. 123) ............ 30
TABELA 8 – RELAÇÃO DOS PESOS DE SE PARA DETERMINAÇÃO DOS PF NÃO-AJUSTADOS.
TABELA 9 – COMPLEXIDADE DE CE. (FONTE: FERNANDES (FERNANDES, 1995, P. 123) ............ 31
TABELA 10 – RELAÇÃO DOS PESOS DE CE PARA DETERMINAÇÃO DOS PF NÃO-AJUSTADOS.
TABELA 11 – DETERMINAÇÃO DOS PFNA (PONTOS POR FUNÇÃO NÃO-AJUSTADOS) ............... 33
TABELA 12 – DETERMINAÇÃO DO NÍVEL TOTAL DE INFLUÊNCIA. (FONTE: FERNANDES
(FERNANDES, 1995, P. 126) ................................................................................................ 35
TABELA 13 – CONVERSÃO DE PFNA PARA SLOC. (FONTE: BARRY BOEHM (BOEHM, ET AL.,
2000)) ................................................................................................................................ 39
TABELA 14 – PESOS CALIBRADOS DOS SF'S. (FONTE: BARRY BOEHM (BOEHM, ET AL., 2000).. 41
TABELA 15 – DRIVERS DE CUSTO PARA O SUB-MODELO EARLY DESIGN (FONTE: COCOMO II
MANUAL 2000) .................................................................................................................. 42
TABELA 16 – DRIVERS DE CUSTO PARA O SUB-MODELO POST-ARCHITECTURE (FONTE:
COCOMO II MANUAL 2000) ............................................................................................ 43
TABELA 17 – DRIVERS DO MODELO DE INJEÇÃO DE DEFEITOS DE SOFTWARE .......................... 50
TABELA 18 – PCAP CAPACIDADE DO PROGRAMADOR – ESCALA DE TAXAS DA INJEÇÃO DE
DEFEITOS. (FONTE: BARRY BOEHM (BOEHM, ET AL., 2000)) ............................................. 55
TABELA 19 – CLASSIFICAÇÃO DOS TIPOS DE REMOÇÃO DE DEFEITOS. (FONTE: BARRY BOEHM
(BOEHM, ET AL., 2000)) ..................................................................................................... 60
TABELA 20 – DENSIDADE DE DEFEITOS RESIDUAIS DOS VALORES DAS FRAÇÕES DE REMOÇÃO
DE DEFEITOS. (FONTE: BARRY BOEHM (BOEHM, ET AL., 2000)) ........................................ 61
TABELA 21 – CARACTERÍSTICAS DO PROJETO, MULTIPLICADORES DE ESFORÇO E INJEÇÃO DE
DEFEITOS ........................................................................................................................... 64
TABELA 22 – CLASSIFICAÇÃO DOS TIPOS DE REMOÇÃO DE DEFEITOS NO PROJETO..................... 64
TABELA 23 – DENSIDADE RESIDUAL DE DEFEITOS ..................................................................... 69
TABELA 24 – VALORES DOS EM PARA O SUB-MODELO EARLY DESIGN (FONTE: COCOMO II
MANUAL 2000 (USC, 2000)) ............................................................................................. 74
TABELA 25 – VALORES DOS EM PARA O SUB-MODELO POST-ARCHITECTURE (FONTE:
COCOMO II MANUAL 2000 (USC, 2000)) ....................................................................... 74

TABELA 26 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER RELY.
(FONTE: SUNITA CHULANI (CHULANI, RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 75
TABELA 27 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER DATA.
TABELA 28 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER RUSE.
TABELA 29 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER DOCU.
TABELA 30 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER CPLX.
TABELA 31 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER TIME.
TABELA 32 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER STOR.
TABELA 33 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PVOL.
TABELA 34 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER ACAP.
TABELA 35 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PCAP.
TABELA 36 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PCON.
TABELA 37 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER APEX.
TABELA 38 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PLEX.
TABELA 39 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER LTEX.

TABELA 40 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER TOOL.
TABELA 41 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER SITE.
TABELA 42 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER SCED.
TABELA 43 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PREC.
TABELA 44 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER RESL.
TABELA 45 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER TEAM.
TABELA 46 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PMAT.

ÍNDICE DE GRAFICOS

GRÁFICO 1 – DISPERSÃO DOS DEFEITOS DA AMOSTRAGEM ........................................................ 22
GRÁFICO 2 - DISPERSÃO DOS DEFEITOS DA AMOSTRAGEM POR TAMANHO DE SOFTWARE .......... 23
GRÁFICO 3 – EQUAÇÃO DE AJUSTE AOS PONTOS DA RETA ......................................................... 25
GRÁFICO 4 – ESCALAS DE INJEÇÃO DE DEFEITOS DE CODIFICAÇÃO (DIR). (FONTE: SUNITA
CHULANI E BARRY BOEHM (CHULANI & BOEHM, MODELING SOFTWARE DEFECT
INTRODUCTION AND REMOVAL: COQUALMO (CONSTRUCTIVE QUALITY MODEL),
1999)) ................................................................................................................................ 56

ACRÔNIMOS E ABREVIAÇÕES

COCOMO Constructive Cost Model
COQUALMO Constructive Quality Model
IFPUG International Function Point Users Group
APF Análise por Pontos de Função
CPM Counting Practices Manual
FPNA Pontos de Função Não-Ajustados
PFA Pontos de Função Ajustados
COTS Commercial-Off_The_Shelf
kSLOC Kilo Source Lines Of Code
SLOC Source Lines Of Code
DI Defect Introduction Software
DR Defect Removal Software
QAF Quality Adjustment Factor
DIR Defect Introduction Rate
DRR Defect Removal Rate
DRF Defect Removal Fraction
PM Person-Months
TDEV Time to Development
SF Scale Factor
EM Effort Multiplication
RELY Required Software Reliability
DATA Data Base Size
CPLX Product Complexity
RUSE Developed for Reusability
DOCU Documentation Match to Life-Cycle Needs
TIME Execution Time Constraint
STOR Main Storage Constraint
PVOL Platform Volatility
ACAP Analyst Capability
PCAP Programmer Capability
PCON Personnel Continuity
APEX Applications Experience
PLEX Platform Experience
LTEX Language and Tool Experience
TOOL Use of Software Tools
SITE Multisite Development
SCED Required Development Schedule
RCPX Product Reliability and Complexity
RUSE Developed for Reusability
PDIF Platform Difficulty

PERS Personnel Capability
PREX Personnel Experience
FCIL Facilities
SCED Required Development Schedule
PREC Precedentedness
FLEX Development Flexibility
RESL Architecture/Risk Resolution
TEAM Team Cohesion
PMAT Process Maturity

15

CAPÍTULO 1 – INTRODUÇÃO

1.1. Considerações Iniciais

“Os alertas começaram a mais de uma década antes do evento, mas ninguém prestou
muita atenção. Há menos de dois anos da data, os meios de comunicação publicaram a
história. Depois, representantes do governo manifestaram sua preocupação, lideranças
empresariais empenharam vastos recursos financeiros e, finalmente, sérios alertas de
catástrofes iminentes penetraram a consciência do público. O Software, por causa agora do
infame erro do milênio, iria falhar e como resultado pararia o mundo, tal como então o
conhecemos.”

Se observarmos com uma visão crítica o trecho acima, extraído de Pressman
(Pressman, 2002), podemos facilmente concluirmos de que forma o desenvolvimento de
projetos de software era tratado anos atrás. Observando mais a fundo, não será difícil
percebermos que não era um problema meramente técnico, mas sim gerencial, de
planejamento.

Alguns anos antes de tomar-se conhecido e consequentemente divulgação do maior
erro da história do software, o chamado “bug do milênio”, discutia-se a crise do software. O
aumento da demanda por software provocava o conseqüente aumento da complexidade dos
problemas a serem resolvidos e aliado à falta de técnicas e métodos para desenvolvimento fez
com que ao final dos anos 60 e início dos anos 70, esse termo fosse usado em uma
conferência para discutir as dificuldades acerca do desenvolvimento do software.
(Sommerville, 2003) e (Wikipédia, http://pt.wikipedia.org/wiki/Crise_do_software, 2009).

Roger Pressman (Pressman, 2002) cita que o grande sucesso alcançado pela indústria
do software, levou muitos a questionarem o termo crise de software. Isso pelo fato dessa
indústria ter um número mais significativo de sucessos contra o de insucessos.

Com o advento e uso efetivo da Engenharia de Software, podemos considerar que
grande parte desse sucesso vem do uso contínuo dos modelos, métodos e ferramentas
disponíveis para a melhoria de um projeto de desenvolvimento de software, o que comprova
que o uso de métodos e ferramentas aumenta consideravelmente a capacidade de se produzir
softwares que, cada vez mais se enquadrem quantitativamente no prazo e orçamento
previstos.

16

Aguinaldo Fernandes (Fernandes, 1995) contextualiza a “crise do software” à
realidade brasileira quando cita em no prefácio de seu livro, que “a crise é eminentemente
gerencial, com raízes culturais, caracteristicamente brasileiras, onde o pragmatismo e o
comportamento imediatista não têm atingido os objetivos pretendidos.”

Diante disso, mesmo tendo uma grande quantidade de sucessos na indústria de
software, concluímos que ainda estamos no interior da chamada crise. Não é difícil
observarmos cada vez mais projetos ultrapassando o prazo e orçamento previstos, pouca ou
nenhuma qualidade inerente ao processo e/ou produto, ingerência nos projetos, dificuldade de
manutenção e/ou evolução do software. Conforme colocado por Aguinaldo Fernandes
(Fernandes, 1995) muitas vezes os verdadeiros culpados do insucesso ou má gestão de um
projeto, transcende as responsabilidades do gerente do projeto de software, pois sem o
patrocínio para a realização das mudanças necessárias, muito provavelmente a implantação de
um método eficaz de gestão será bem sucedido, e sem esse crédito dificilmente se conseguirá
atingir os objetivos desejados.

O que fazer então para melhorar esse contexto? Existe um ditado popular que diz:
“Contra fatos, não há argumentos”, e é exatamente esse o ponto de partida que precisamos
considerar para melhorar a atual situação da produção de software explanado no parágrafo
anterior. É nesse cenário que se propõe o uso de modelos para medição de projetos de
software, os quais possuem o objetivo de nos auxiliar na definição e coleta de métricas que
compõe uma base de informações de projetos de software, que nos permite responder algumas
questões como: Qual o custo de um determinado projeto de desenvolvimento de software?
Qual o ritmo mais adequado para um determinado projeto de desenvolvimento de software?
Qual o prazo ideal de um determinado projeto de desenvolvimento de software? Qual será o
nível de qualidade possível na entregar o produto de um determinado projeto de
desenvolvimento de software?

A resposta à última pergunta, no entanto, traduz o principal objetivo quando
realizamos medições em um projeto de desenvolvimento de software. O importante não é
apenas medir quantitativamente um projeto, mas tão importante quanto é o medirmos de
forma qualitativa.

17

O processo de evolução de um software e o nível de exigência de quem os usa cresce
de forma exponencial. Não basta mais entregarmos um produto no prazo e dentro do
orçamento planejado, mas também entregá-lo em um nível de qualidade que supera as
expectativas.

1.2. Objetivo

Este trabalho tem por objetivo estudar e apresentar um modelo para medição de
projeto de software para estimar qualitativamente um projeto de desenvolvimento de
software.

O modelo a ser apresentado baseia-se na predição de defeitos inerentes ao processo de
desenvolvimento e foi inicialmente proposto por Sunita Chulani e Berry Boehm (Chulani &
Boehm, Modeling Software Defect Introduction and Removal: COQUALMO (COnstructive
QUALity MOdel), 1999) denominado COQUALMO (COnstructive QUALity MOdel).

Os modelos para medição quantitativa que serão apresentados neste trabalho são:
Regressão Linear, Análise por Pontos de Função (Function Points Analysis) e COCOMO II.

1.3. Estrutura

Este trabalho está estruturado da seguinte forma:

O Capítulo 1 – Introdução – apresenta alguns pontos importantes para a compreensão deste
trabalho, bem como sua descrição e de forma este trabalho foi estruturado.

O Capítulo 2 – Modelos e Técnicas de Estimativas – apresenta modelos e técnicas mais
conhecidas de estimativas de projetos de softwares. A identificação dos modelos para uso
neste trabalho foi baseado na aplicação das melhores práticas em termos de estimativa de
projetos de software.

O Capítulo 3 – Modelo de Estimativa de Qualidade COQUALMO (COnstructive QUALity
MOdel) - apresenta detalhadamente o modelo de estimativa de qualidade COQUALMO, bem
como o descritivo do passos a ser seguido para se medir qualitativamente o projeto utilizando
este modelo, e os pontos onde esse tipo de estimativa pode auxiliar um projeto de software a
atingir um melhor nível de qualidade.

18

O Capítulo 4 – Aplicação dos Modelos e Técnicas de Estimativas Apresentados – apresenta
um exemplo de aplicação integrada dos modelos apresentados neste trabalho, considerando
para fins de cálculos dados fictícios e coletados das referências utilizadas.

O Capítulo 5 – Conclusão e Trabalhos Futuros – apresenta as conclusões finais obtidas após a
realização deste trabalho e uma breve proposta de trabalhos futuros como extensão deste
estudo.

19

CAPÍTULO 2 – MODELOS E TÉCNICAS DE ESTIMATIVAS


Citado por Fernandes (Fernandes, 1995) e de acordo com Norman Fenton (Fenton,
1991), os principais modelos de predição de projetos de softwares são desenvolvidos após
análises de um conjunto de dados e amostras específicas, onde certamente incluem parâmetros
difíceis de serem determinados no início de um projeto. Dessa forma, teremos a necessidade
de calibração desses modelos de forma a adequá-los à realidade da organização e do ambiente
no qual o modelo de estimativa será aplicado.

A coleta dessas informações não é trivial, pois exige esforço e disciplina para que se
armazene de cada projeto uma base histórica de informações desses projetos. Considerando
essa base histórica de dados, coletam-se as informações necessárias para se alimentar os
parâmetros da técnica ou modelo de estimativa escolhida(o). Quanto maior a base histórica,
melhor podemos afirmar que a técnica ou modelo estará calibrada(o), e dessa forma os
resultados dela obtidos terão um maior nível de exatidão.

Esse raciocínio é apresentado na Figura 1.

20

Figura 1 – Modelo de configuração de dados. (Fonte: Fernandes (Fernandes, 1995, p. 117)

Cada técnica exige um conjunto específico de parâmetros. Daí a necessidade de se
escolher com bastante critério qual(is) técnica(s) ou modelo(s) utilizar.

Neste capítulo serão apresentadas algumas das principais técnicas e modelos de
estimativas de projetos de software. Essas técnicas e modelos foram escolhidos baseados em
melhores práticas no que diz respeito a estimativas de projetos de software.

Antes de avançarmos no estudo do modelo para estimativa da qualidade de um projeto
de desenvolvimento de software, precisaremos tomar conhecimento de algumas técnicas de
estimativas de tamanho, esforço e prazo. Esse conhecimento é necessário para melhor
entendermos os fundamentos do modelo COQUALMO a ser estudado no Capítulo 3.

2.2. Regressão Linear

O modelo de regressão linear é uma das técnicas estatísticas com capacidade preditiva
que envolve duas variáveis, uma dependente(Y) e outra independente(X). É uma análise
realizada a partir de uma correlação linear entre essas duas variáveis, buscando estabelecer

21

um modelo de previsão dos valores de Y a partir dos valores de X. Em estatística esse tipo de
modelo é chamado de Regressão Linear Simples.

O valor da variável (Y) se dá através da equação:

ࢅ = ݂(ܺ) Eq. 2.2.1

Onde,

Y é o número de defeitos de um software;

f(X) é a função que determina o valor de (Y).

Consideremos o seguinte cenário: Queremos saber o número de defeitos a ser
encontrado em cada ciclo de teste de um determinado software.

Baseando-nos na base histórica de defeitos de software por ciclo, conforme Tabela 1.

Tabela 1 – Amostragem de defeitos

Ciclo Defeitos (Y)
1 8
2 48
3 159
4 218
5 294
6 308
7 455
Média 212,86

Nesse caso temos uma média de 212,86 defeitos, porém ela é apenas uma referência,
pois nessa previsão não existe nenhuma variável independente. Sem nenhuma outra variável a
considerar, podemos afirmar que a média de defeitos é uma boa previsão.

O Gráfico 1 apresenta a dispersão dos defeitos da amostragem da Tabela 1.

22

Defeitos(Y)
500
450
400
350
# Defeitos

300
250
200 Defeitos(Y)
150
100
50
0
0 1 2 3 4 5 6 7 8
Ciclo

Gráfico 1 – Dispersão dos defeitos da amostragem

A prática do uso da técnica de Regressão Linear nos ajuda a melhorar essa previsão,
pois nos permite usar uma ou mais variáveis explicativas.

Consideremos agora a inclusão de mais uma variável – tamanho do software medido
em pontos de função – no contexto do cenário em questão, conforme Tabela 2.

Tabela 2 – Amostragem de defeitos por tamanho de software

Tamanho do Software em
Ciclo Defeitos (Y)
Pontos de Função (X)
1 50 8
2 100 48
3 200 159
4 400 218
5 800 294
6 1600 308
7 3200 455
Média 907,14 212,86

23

O Gráfico 2 apresenta a dispersão dos defeitos da amostragem da Tabela 2.

# Defeitos(Y)
500
450
400
350
# Defeitos

300
250
200
150 # Defeitos(Y)
100
50
0
0 500 1000 1500 2000 2500 3000 3500
Tamanho do Software (X)

Gráfico 2 - Dispersão dos defeitos da amostragem por tamanho de Software

Usando o método dos mínimos quadrados, podemos facilmente chegar à equação da
reta que melhor se ajusta ao conjunto dos dados amostrais fornecidos.

Esta equação tem sua forma geral, para dados de uma amostra, conforme apresentado
pela Eq.2.2.2.

Y = a + b.X Eq.2.2.2

Onde,

Y é o valor estimado da variável dependente, dado um valor específico da
variável independente X;

a é o ponto onde a reta de regressão linear intercepta o eixo Y;

b é a declividade da reta de regressão;

X é o valor específico da variável independente.

A distância entre cada ponto e a reta são os erros de predição no qual o modelo tenta
se ajustar. Sabendo que a relação entre X e Y é linear, as equações usadas para cálculo dos

24

valores de “a” e “b”, com a finalidade de satisfazer os critérios dos mínimos quadrados é
demonstrado através das equações Eq.2.2.3 e Eq.2.2.4.

∑ଡ଼.ଢ଼ – ୬.µଡ଼.µଢ଼
b= Eq.2.2.3
∑ଡ଼² – ୬.µଡ଼²

a = µY – b. µX Eq.2.2.4

Onde,

µX é a média dos valores referentes ao tamanho do software medido em pontos
de função, da amostra;

µY é a média dos valores de defeitos (Y) da amostra;

n é o número de amostras.

Atribuindo os valores das amostragens nas equações Eq.2.2.3 e Eq.2.2.4, os seguintes
valores para “a” e “b” são computados.

ଶଷ଴଼ଶ଴଴ – ଻.(ଽ଴଻,ଵସ).(ଶଵଶ,଼଺)
b= = 0,12
ଵଷ଺ହଶହ଴଴ –(଻).(ଽ଴଻,ଵସ)²

a = 212,86 – (0,12). (907,14) = 104,01

Aplicando os resultados calculados para “a” e “b”, temos a equação da reta Eq.2.2.5.

Y = 104,01 + 0,12X Eq. 2.2.5

O Gráfico 3 apresenta a dispersão dos defeitos da amostragem da Tabela 2 e a reta da
equação Eq2.2.5.

25

# Defeitos(Y)
600

500

400
# Defeitos

300
# Defeitos(Y)
200
Linear (# Defeitos(Y))
100

0
0 1000 2000 3000 4000
Tamanho do Software (X)

Gráfico 3 – Equação de ajuste aos pontos da reta

Com a equação da reta ajustada, podemos estimar a quantidade de defeitos a serem
encontrados em um novo ciclo. Suponhamos que temos um novo ciclo onde a estimativa
calculada para tamanho do software, seja de 6400 (em pontos de função). Queremos, então,
determinar o número de defeitos esperados no software.

Na equação da reta ajustada, atribuiremos o número do tamanho do software X=6400
e encontrar o valor de Y, que será o número de defeitos esperado.

Y = 104,01 + 0,12.(6400) = 872 defeitos esperados.

Através dessa técnica é possível estimar o número de defeitos que poderão ser
encontrados em um software, porém é um número cheio que leva-nos a considerar que são
defeitos produzidos na codificação apenas, o que não é verdade. Sunita Chulani (Chulani &
Boehm, Modeling Software Defect Introduction and Removal: COQUALMO (COnstructive
QUALity MOdel), 1999), em seu estudo, afirma que defeitos são introduzidos em um projeto
de desenvolvimento de software, tanto nas fases de elaboração de requisitos, quanto no
desenho da arquitetura da solução e na codificação. Portanto, o número de defeitos calculado
usando Regressão Linear nos mostra apenas uma quantidade, porém não especifica em qual
ponto do projeto esses defeitos aparecerão.

26

2.3. Análise por Pontos de Função (APF)

Segundo Carlos Vazquez (Vazquez, Simões, & Machado, 2003) a análise por pontos
de função é atualmente um instrumento utilizado por profissionais da área de sistemas e em
empresas de todos os portes e segmentos da economia brasileira. E ainda continua sendo uma
importante ferramenta de estimativas, utilizada com cada vez mais sucesso, como unidade de
medição de contratos de desenvolvimento de software e como ferramenta da gestão de
projetos.

Essa técnica teve início nos anos 70, na IBM através de Allan Albrecht que foi
incumbido de medir a produtividade de vários projetos de software em desenvolvimento pela
IBM. O intuito proposto para o desenvolvimento dessa nova técnica, foi o de criar uma
alternativa às métricas baseadas em linhas de código e também algo que pudesse ser usado
para estimar o tamanho de um software que fosse independente da linguagem de programação
utilizada.

Devido a um significativo aumento de usuários dessa técnica, culminou-se em 1986,
na fundação do International Function Point Users Group – IFPUG e em 1990 foi lançado o
primeiro manual de práticas de contagem (Counting Practices Manual – CPM). IFPUG
(Group)

2.3.1. O Processo de Contagem

A Figura 2 apresenta de forma resumida um fluxo que oferece uma visão geral do
processo de contagem por pontos de função.

Figura 2 – Visão geral do processo de contagem de pontos de função. (Fonte: Carlos Vazquez
(Vazquez, Simões, & Machado, 2003, p. 47)

27

2.3.2. Determinando o Tipo de Contagem

Nessa fase é determinado o tipo de contagem que será realizada para medir o software,
tanto em nível de processo quanto de produto e pode ser aplicada a qualquer atividade de seu
ciclo de vida. A contagem pode ser associada tanto a aplicações implementadas quanto em
projetos de desenvolvimento, e até mesmo durante procedimentos de manutenção seja ela
evolutiva, corretiva ou adaptativa.

A contagem possui 03(três) classificações:

• Projeto de Desenvolvimento
• Projeto de Melhoria
• Aplicação

Projeto de Desenvolvimento

A contagem dos pontos por função para um projeto de desenvolvimento tem por
objetivo estimar o tamanho do projeto para uma nova aplicação, quantificando funções
solicitadas pelo usuário e podendo abranger eventuais funções de conversão de dados que
possam ser necessárias à implantação da aplicação.

Projeto de Melhoria

A contagem dos pontos de função para um projeto de melhoria tem por objetivo
estimar o tamanho de funções adicionais, modificações ou exclusões de funções inseridas em
uma aplicação previamente instalada, quantificando as melhorias solicitadas pelo usuário e
podendo novamente abranger também eventuais funções de conversão de dados.

É necessário lembrar que em todos os casos em que haja uma contagem dentro dessa
classificação, havendo conclusão do projeto de melhoria, o número de pontos por função da
aplicação deve ser alterado considerando os novos cálculos para as funções atingidas.

Aplicação

A contagem dos pontos por função para uma aplicação tem por objetivo estimar o real
tamanho dessa aplicação, também chamado número de pontos por função instalados ou
baseline, Carlos Vazquez (Vazquez, Simões, & Machado, 2003).

28

O resultado do cálculo nos dá a estimativa da funcionalidade da aplicação sob o ponto
de vista do usuário da aplicação e é realizado ao final da contagem dos pontos de um projeto
de desenvolvimento.

2.3.3. Definindo a Fronteira da Aplicação e o Escopo da Contagem

De acordo com Carlos Vazquez (Vazquez, Simões, & Machado, 2003) a fronteira de
uma aplicação é a interface conceitual que delimita o software que será medido e o mundo
exterior (seus usuários). Em outras palavras é o limite entre a aplicação e o usuário desta
aplicação. É a fronteira determina as funções que deverão ser medidas, Aguinaldo Fernandes
(Fernandes, 1995).

O escopo da contagem nada mais é do que a definição de qual será a abrangência da
contagem, ou seja, contaremos os pontos por função para uma ou mais aplicações, ou até
mesmo para parte dessa aplicação.

2.3.4. Contagem de Função do Tipo DADO

Esse tipo de função representa as funcionalidades fornecidas pela aplicação ao usuário
através de dados internos e externos, atendendo às necessidades de dados, que possuem a
seguinte classificação:

Arquivo Lógico Interno (ALI)

Grupo de dados relacionados logicamente, dentro do limite da fronteira da
aplicação.

Arquivo de Interface Externa (AIE)

Grupo de dados relacionados logicamente, fora do limite da fronteira da
aplicação.

Cada ALI e AIE possui uma complexidade determinada a partir da quantidade do Tipo
de Elemento de Registro (TER) e do Tipo de Elemento de Dado (TED), conforme relação
apresentada na Tabela 3.

29

Tabela 3 – Complexidade ALI e AIE. (Fonte: Fernandes (Fernandes, 1995, p. 123)

Registros Dados
1 a 19 TED 20 a 50 TED 51 ou mais TED
1 TER Baixa Baixa Média
2 a 5 TER Baixa Média Alta
6 ou mais TER Média Alta Alta

Em função da complexidade de cada ALI e AIE, são atribuídos pesos para os cálculos
dos pontos por função não-ajustados conforme Tabela 4.

Tabela 4 – Relação dos pesos de ALI e AIE para determinação dos PF não-ajustados. (Fonte:
Fernandes (Fernandes, 1995, p. 125)

Complexidade Funcional Peso atribuído para ALI Peso atribuído para AIE
Alta 15 10
Média 10 7
Baixa 7 5

2.3.5. Contagem de Função do Tipo TRANSAÇÃO

Esse tipo de função representa as funcionalidades de processamento de dados
fornecidas pela aplicação ao usuário e possuem a seguinte classificação:

Entrada Externa (EE)

Função que realiza o processamento de dados ou informações de controle
oriundas de fora da fronteira da aplicação.

Cada EE possui uma complexidade determinada a partir da quantidade do Tipo de
Arquivo Referenciado (TAR) e do Tipo de Elemento de Dados (TED), conforme Tabela 5.

Tabela 5 – Complexidade de EE. (Fonte: Fernandes (Fernandes, 1995, p. 123)

Arquivos Dados
0 a 1 TAR Baixa Baixa Média
2 TAR Baixa Média Alta
3 ou mais TAR Média Alta Alta

30

Em função da complexidade de cada EE, são atribuídos pesos para os cálculos dos
pontos por função não-ajustados conforme Tabela 6.

Tabela 6 – Relação dos pesos de EE para determinação dos PF não-ajustados. (Fonte:

Complexidade Funcional Peso atribuído para EE
Alta 6
Média 4
Baixa 3

Saída Externa (SE)

Função que realiza o processamento de dados ou informações de controle e os
envia para fora da fronteira da aplicação. O processamento dessa saída deve conter algum tipo
de cálculo, como por exemplo, a criação de dados novos derivados de dados ou informações
existentes.

Cada SE possui uma complexidade determinada a partir da quantidade do Tipo de
Arquivo Referenciado (TAR) e do Tipo de Elemento de Dados (TED), conforme Tabela 7.

Tabela 7 – Complexidade de SE. (Fonte: Fernandes (Fernandes, 1995, p. 123)

Arquivos Dados
2 a 3 TAR Baixa Média Alta

Em função da complexidade de cada SE, são atribuídos pesos para os cálculos dos

Tabela 8 – Relação dos pesos de SE para determinação dos PF não-ajustados. (Fonte:

Complexidade Funcional Peso atribuído para SE
Alta 7
Média 5
Baixa 4

31

Consulta Externa (CE)

Função que realiza o envio de dados ou informações de controle para fora da
fronteira da aplicação através da recuperação simples de dados ou informações de controle.

Cada CE possui uma complexidade determinada, primeiro a partir da a definição da
maior complexidade entre as partes de entrada e saída identificadas separadamente, e segundo
pela quantidade do Tipo de Arquivo Referenciado (TAR) e do Tipo de Elemento de Dados
(TED), juntamente com conforme Tabela 9.

Tabela 9 – Complexidade de CE. (Fonte: Fernandes (Fernandes, 1995, p. 123)

Arquivos Dados
Entradas 1 a 4 TED 5 a 15 TED 16 ou mais TED
2 a 3 TAR Baixa Média Alta
Saídas 1 a 5 TED 6 a 19 TED 20 ou mais TED
2 a 3 TAR Baixa Baixa Alta

Em função da complexidade de cada CE, são atribuídos pesos para os cálculos dos

Tabela 10 – Relação dos pesos de CE para determinação dos PF não-ajustados. (Fonte:

Complexidade Funcional Peso atribuído para CE
Alta 6
Média 4
Baixa 3

2.3.6. Contagem dos Pontos de Função Não-Ajustados (PFNA)

Conforme descrito nas seções “2.3.4. Contagem de Função do Tipo DADO” e “2.3.5.
Contagem de Função do Tipo TRANSAÇÃO”, são funções classificadas e identificadas
conforme sua complexidade funcional, e atribuem pesos para cálculos dos pontos por função.

32

Nesse primeiro cálculo, encontraremos os Pontos por Função Não-Ajustados, ou seja,
pontos por função brutos.

Consideremos que uma aplicação contenha:

• Seis Arquivos Lógicos Internos (ALI), sendo:
o Dois com complexidade ALTA;
o Dois com complexidade MÉDIA;
o Dois com complexidade BAIXA;
• Cinco Arquivos de Interfaces Externos (AIE), sendo:
o Três com complexidade ALTA;
o Um com complexidade MÉDIA;
o Um com complexidade BAIXA;
• Três Entradas Externas (EE), sendo todas elas com complexidade
BAIXA;
• Duas Saídas Externas (SE), sendo:
o Uma com complexidade MÉDIA;
o Uma com complexidade BAIXA;
• Oito Consultas Externas (CE), sendo:
o Duas com complexidade ALTA;
o Quatro com complexidade MÉDIA;
o Duas com complexidade BAIXA.

Para encontrarmos o número bruto de pontos por função, devemos agrupar as funções
e multiplicar a quantidade de cada grupo de funções, pelos pesos correspondentes a cada
complexidade funcional, conforme Tabela 11.

33

Tabela 11 – Determinação dos PFNA (Pontos por Função Não-Ajustados)

Complexidade Peso Total por
Função Qtde
Funcional Atribuído Função
Alta 2 x 15 30
Arquivo Lógico Interno (ALI) Média 2 x 10 20
Baixa 2 x7 14
Total de Pontos de Função para Arquivos Lógicos Internos (ALI) 64
Alta 3 x 10 30
Arquivo de Interface Externo (AIE) Média 1 x7 7
Baixa 1 x5 5
Total de Pontos de Função para Arquivos de Interfaces Externos (AIE) 42
Alta 0 x6 0
Entrada Externa (EE) Média 0 x4 0
Baixa 1 x3 3
Total de Pontos de Função para Entradas Externas (EE) 3
Alta 0 x7 0
Saída Externa (SE) Média 1 x5 5
Baixa 1 x4 4
Total de Pontos de Função para Saídas Externas (SE) 9
Alta 2 x6 12
Consulta Externa (CE) Média 4 x5 20
Baixa 2 x3 6
Total de Pontos de Função para Consultas Externas (CE) 38
Total de Pontos de Função Não-Ajustados 156

2.3.7. Determinar Fator de Ajuste

Para calcularmos o fator de ajuste, é necessário levarmos em consideração 14
características da aplicação para avaliação geral desta, conforme segue.

Características

1. Comunicação de Dados;
2. Processamento de Dados Distribuídos;
3. Desempenho (Performance);
4. Configuração de (Hardware);
5. Volume de Transações;
6. Entrada de Dados Online;
7. Interface com usuário;

34

8. Atualização Online;
9. Processamento Complexo;
10. Reutilização;
11. Facilidade de Instalação;
12. Facilidade Operacional;
13. Múltiplas Instalações;
14. Flexibilidade.

Para cada característica acima citada, é necessário estabelecer o nível de influência
conforme escala baixo.

0 – Não exerce Influência;

1 – Pouca Influência;

2 – Influência Moderada;

3 – Média Influência;

4 – Influência Significativa;

5 – Forte Influência.

Para determinarmos o nível total de influência, utilizaremos os valores descritos na
Tabela 12.

35

Tabela 12 – Determinação do nível total de influência. (Fonte: Fernandes (Fernandes, 1995, p.
126)

Características Nível de Influência
Comunicação de Dados 4
Processamento de Dados Distribuídos 1
Desempenho (Performance) 5
Configuração de (Hardware) 5
Volume de Transações 4
Entrada de Dados Online 3
Interface com usuário 4
Atualização Online 2
Processamento Complexo 1
Reutilização 0
Facilidade de Instalação 3
Facilidade Operacional 2
Múltiplas Instalações 2
Flexibilidade 4
Nível de Influência Total 40

Através da equação 0,65 + (0,01 x NI) = FA (Eq.2.3.7.1), é possível determinar o
Fator de Ajuste (FA) considerando o Nível de Influência Total calculado com os valores de
referência da Tabela 12.

0,65 + (0,01 x 40) = 1,05

2.3.8. Determinar Ponto de Função Ajustado (PFA)

Considerando o Fator de Ajuste calculado, podemos chegar ao número de pontos por
função ajustados. Para tanto, basta multiplicarmos o valor dos Pontos por Função Não-
Ajustados (PFNA) referenciados na Tabela 11, pelo Fator de Ajuste calculado na seção
“2.3.7. Determinar Fator de Ajuste”, conforme segue.

FA x PFNA = 1,05 x 156 = 164 (por arredondamento)

2.3.9. Considerações Finais

Diversas são as aplicações da Análise por Pontos de Função, sendo amplamente
utilizada em projetos de desenvolvimento de software como ferramenta para cálculo do

36

tamanho, produtividade, esforço, prazo e dimensionamento da equipe do projeto. Para
realização desses cálculos são necessárias outras análises, que esse estudo não tem por
objetivo apresentar.

A característica da técnica de análise por pontos de função nos permite medir os
requisitos do usuário, sem nos preocuparmos com a tecnologia a ser empregada no
desenvolvimento. Ela unifica o padrão de medida, amplamente utilizada no meio técnico, e
pode ser utilizada desde o início do ciclo de vida.

No entanto, a indústria do software busca insistentemente algo que a ajude a mensurar
a qualidade dos requisitos, do desenho da arquitetura da solução e do código escrito para a
aplicação, e através da análise por pontos de função, conseguiremos chegar perto desse
objetivo, entretanto ainda não é o suficiente para o atingirmos com exatidão.

2.4. COCOMO II (COnstructive COst MOdel II)
2.4.1. Considerações Iniciais

O modelo COCOMO II (COnstructive COst MOdel), apresentada por Barry Boehm
(Boehm, et al., 2000) estabelece um método de estimativas que visa medir o esforço, prazo,
custo e o tamanho da equipe necessária para um determinado projeto de desenvolvimento de
software. Porém, para chegar a tal conclusão, antes, é necessário ter como premissa a
dimensão desse projeto, estimada através de técnicas de estimativas de tamanho de software,
como a Análise por Pontos de Função, estudada na seção anterior e esta técnica será utilizada
em todas as menções relativas ao tamanho do software neste estudo.

O modelo COCOMO II teve como precursor o modelo COCOMO, conhecido também
como COCOMO 81, Barry Boehm (Boehm, et al., 2000). A idade dos projetos utilizados
como base para a construção deste modelo, aliado à baixa capacidade de lidar com ciclos de
vida interativos e a utilização de componentes Commercial-Off-The-Shelf (COTS), fez com
que o modelo COCOMO 81 se tornasse obsoleto, sendo substituído por sua versão mais atual,
COCOMO II, publicada em 2000, Maurício Aguiar (Aguiar, 2009).

O modelo COCOMO II consegue estimar o custo e o tempo necessário para a
realização de um projeto de desenvolvimento de software, baseando-se no número de
pessoa/mês e meses, respectivamente, determinando a baseline de exigências do produto para

37

que a atividade seja concluída. Prevendo também um adicional de 20% ao tempo calculado,
como margem de erro, Pablo López (López, 2005).

O modelo vem sofrendo refinamentos e constante evolução, pois em se tratando de
modelos de estimativas, é difícil encontrarmos e desenvolver um modelo estável que atenda a
todas as necessidades que envolvem um projeto de software. Barry Boehm (Boehm, et al.,
2000) apresenta alguns dos objetivos do modelo. Esses objetivos baseiam-se em informações
coletadas ao longo dos anos como forma de melhoria do modelo COCOMO 81.

• Fornecer estimativas cada vez mais exatas de custos e prazos para projetos de
softwares atuais e futuros;
• Permitir que as organizações consigam facilmente calibrar e re-calibrar o
modelo COCOMO II adequando cada vez mais suas estimativas à realidade
dos projetos;
• Permitir um fácil entendimento das definições das entradas, saídas e suposições
do modelo;
• Permitir um modelo construtivo, no qual as atividades de estimativas de custo e
prazo ajudem as pessoas a ter um entendimento da natureza do projeto que está
sendo estimado;
• Permitir um modelo padronizado, no qual possibilite a alocação necessária de
recursos para um desenvolvimento efetivo do projeto, que mostre objetivos
irreais relativos a custo e prazo, estabeleça meios para um gerenciamento
controlado, para que projetos de software atuais e futuros possam buscar uma
melhoria contínua;
• Permitir um modelo que esteja sempre em desenvolvimento, e que permita a
adição de novas necessidades mantendo o foco nas práticas de
desenvolvimento de software.
2.4.2. Sub-modelos

Apresentaremos dois sub-modelos descritos pelo modelo COCOMO II, Early Design
e Post-Architecture, Barry Boehm (Boehm, et al., 2000).

38

Early Design (Pré-projeto)

Este sub-modelo é usado nas fases iniciais do projeto. Nessas fases, as
informações disponíveis sobre requisitos, escopo e arquitetura ainda são relativamente
escassas, incompletas e sem um nível de qualidade adequado, e em conseqüência não nos
fornece uma estimativa mais aprofundada, com resultados apenas aproximados. Este sub-
modelo é ideal para a fase de concepção e planejamento do projeto, pois em geral precisa-se
ter uma idéia de quão grande o projeto poderá vir a ser.

André Trindade (Trindade, Pessôa, & Spinola, 1999), chamou este sub-modelo de
Pré-Projeto.

Post-Architecture (Pós-arquitetura)

Este sub-modelo é usado em fases mais avançadas do projeto. Nessas fases, as
informações disponíveis sobre requisitos, escopo e arquitetura, atingiram um nível adequado
de maturidade e qualidade de informações, e em conseqüência é capaz de fornecer uma
estimativa mais aprofundada e próxima da realidade de quão grande será o projeto.

André Trindade (Trindade, Pessôa, & Spinola, 1999), chamou este sub-modelo de
Pós-Arquitetura.

2.4.3. Estimativa de Esforço e Prazo

A medida do esforço calculado através deste modelo é expressa em Pessoa-Mês (PM),
que representa o somatório do tempo que uma pessoa gasta trabalhando no projeto em um
mês. O COCOMO II considera um mês de trabalho equivalente a 152 horas, excluindo
feriados e finais de semana, porém esse valor pode ser alterado conforme desejado pelo
projeto, considerando os ajustes necessários ao modelo para contemplar o ajuste das horas.

Cálculo do Esforço

O cálculo do esforço é dado pela seguinte equação:

Eq.2.4.3.1

39

Onde,

A é uma constante calibrada para o ambiente a ser aplicado o modelo. De
acordo com Pablo López (López, 2005), este é o valor que determina o percentual de
reutilização de código. Após a calibração COCOMO II.2000 feita a partir do histórico de 161
projetos foi atribuído a variável valor A=2,94;

Size é o tamanho do projeto calculado em Linhas de Código SLOC (Source
Line Of Code) ou Pontos por Função Não-ajustados (PFNA). No caso de se usar os pontos por
função não-ajustados, será necessário usar a Tabela 13 de conversão de pontos de função em
SLOC e posteriormente dividir o resultante por mil, pois a unidade Size é dada em kSLOC;

Tabela 13 – Conversão de PFNA para SLOC. (Fonte: Barry Boehm (Boehm, et al., 2000))

SLOC / SLOC /
Linguagem Linguagem
PFNA PFNA
Access 38 Jovial 107
Ada 83 71 Lisp 64
Ada 95 49 Machine Code 640
AI Shell 49 Modula 2 80
APL 32 Pascal 91
Assembly - Basic 320 PERL 27
Assembly - Macro 213 PowerBuilder 16
Basic - ANSI 64 Prolog 64
Basic - Compiled 91 Query – Default 13
Basic - Visual 32 Report Generator 80
C 128 Second Generation Language 107
C++ 55 Simulation – Default 46
Cobol (ANSI 85) 91 Spreadsheet 6
Database – Default 40 Third Generation Language 80
Fifth Generation Language 4 Unix Shell Scripts 107
First Generation Language 320 USR_1 1
Forth 64 USR_2 1
Fortran 77 107 USR_3 1
Fortran 95 71 USR_4 1
Fourth Generation Language 20 USR_5 1
High Level Language 64 Visual Basic 5.0 29
HTML 3.0 15 Visual C++ 34
Java 53

40

E é um expoente do esforço calculado pela equação E = B + 0.01 x ∑SFj (Eq.
2.4.3.2), e incida as economias ou ganhos de escala, onde,

B é uma constante calibrada para o ambiente a ser aplicado o modelo.
Após a calibração COCOMO II.2000 feita a partir do histórico de 161 projetos foi atribuído a
variável valor B=0.91;

J variável com valores na faixa de 1 a 5, que representam os 5 Fatores
de Escala (Scale Factors – SF):

1. PREC – Precedência (Precedentedness);
2. FLEX – Flexibilidade de Desenvolvimento (Development
Flexibility);
3. RESL – Arquitetura/Resolução do Risco (Architecture/Risk
Resolution);
4. TEAM – Coesão da Equipe (Team Cohesion);
5. PMAT – Maturidade do Processo (Process Maturity).

Considerando a calibração COCOMO II.2000 feita a partir de
161 projetos, a Tabela 14 referencia os pesos correspondentes aos SF’s.

41

Tabela 14 – Pesos Calibrados dos SF's. (Fonte: Barry Boehm (Boehm, et al., 2000)

Fatores
de Muito Extra Alto
Baixo Nominal Alto Muito Alto
Escala baixo
(SF)
PREC Extremamente Praticamente Quase sem Pouco Familiar Muito Familiar Extremamente
sem sem Precedentes Familiar
Precedentes Precedentes
SFj 6.20 4.96 3.72 2.48 1.24 0.00
FLEX Rigoroso Relaxamentos Relaxamentos Conformidade Alguma Alta
Ocasionais Periódicos Geral Conformidade Objetividade
SFj 5.07 4.05 3.04 2.03 1.01 0.00
RESL Pouco Algum Frequente Geralmente Na maioria das Completamente
(20%) (40%) (60%) (75%) vezes (100%)
(90%)
SFj 7.07 5.65 4.24 2.83 1.41 0.00
TEAM Alta Alguma Baixa Cooperatividade Cooperatividade Iteração
Dificuldade Dificuldade Dificuldade Alta Muito Alta Completa
nas Iterações nas Iterações nas Iterações
SFj 5.48 4.38 3.29 2.19 1.10 0.00
PMAT SW-CMM SW-CMM SW-CMM SW-CMM SW-CMM SW-CMM
Nivel 1 Nível 1 Nível 2 Nível 3 Nível 4 Nível 5
Baixo Alto
SFj 7.80 6.24 4.68 3.12 1.56 0.00

Os valores encontrados para o expoente E, devem ser analisados
da seguinte forma:

E < 1.0, indica que o projeto apresenta economia de escala;

E = 1.0, indica que as economias e gastos do projeto estão em
equilíbrio;

E > 1.0, indica que o projeto apresenta gastos de escala.

EM, são os multiplicadores de esforço (Effort Multipliers - EM). Dentro do
modelo COCOMO II, contamos com os drivers de custo, que são usados para a captura de
características do desenvolvimento que de alguma forma afetam o esforço para completar o
projeto. Esses drivers possuem medidas que expressam o impacto dos mesmos no
desenvolvimento. Para quantificar essa medida, são atribuídos pesos a cada driver de custo
associado. A este peso damos o nome de Multiplicadores de Esforço EM(Effort Multipliers),

42

Pablo López (López, 2005). Para cada um dos sub-modelos apresentados temos um conjunto
de multiplicadores de esforço.

A Tabela 15 apresenta os 7 drivers de custo referentes ao sub-modelo Early
Design.

Tabela 15 – Drivers de Custo para o Sub-Modelo Early Design (Fonte: COCOMO II Manual
2000)

Sub-Modelo Early Design
Drivers de Custo
Sigla Descrição
RCPX Confiabilidade e Complexidade do Produto (Product Reliability and
Complexity)
RUSE Reutilização (Developed for Reusability)
PDIF Dificuldade da Plataforma (Platform Difficulty)
PERS Capacidade do Pessoal (Personnel Capability)
PREX Experiência do Pessoal (Personnel Experience)
FCIL Facilidades (Facilities)
SCED Cronograma de Desenvolvimento Requerido (Required Development
Schedule)

Em Anexos, a Tabela 24 apresenta os valores de referência dos Multiplicadores
de Esforço para cada driver de custo do sub-modelo Early Design.

A Tabela 16 apresenta os drivers de custo referentes ao sub-modelo Post-
Architecture. São 17 drivers de custo e estão divididos entre os fatores de Produto,
Plataforma, Pessoal e Projeto.

43

Tabela 16 – Drivers de Custo para o Sub-Modelo Post-Architecture (Fonte: COCOMO II
Manual 2000)

Sub-Modelo Post-Architectute
Drivers de Custo
Fator Sigla Descrição
Confiabilidade Requerida do Software (Required Software
RELY
Reliability)
DATA Tamanho da Base de Dados (Data Base Size)
Produto CPLX Complexidade do Produto (Product Complexity)
RUSE Reutilização (Developed for Reusability)
Documentação Associada às Necessidades do Ciclo de Vida
DOCU
(Documentation Match to Life-Cycle Needs)
TIME Restrição do Tempo de Execução (Execution Time Constraint)
Plataforma STOR Restrição de Armazenamento Principal (Main Storage Constraint)
PVOL Volatilidade da Plataforma (Platform Volatility)
ACAP Habilidade do Analista (Analyst Capability)
PCAP Habilidade do Programador (Programmer Capability)
PCON Continuidade do Pessoal (Personnel Continuity)
Pessoal APEX Experiência nas Aplicações (Applications Experience)
PLEX Experiência nas Plataformas (Platform Experience)
Experiência nas Ferramentas e Linguagens (Language and Tool
LTEX
Experience)
TOOL Uso de Ferramentas de Software (Use of Software Tools)
SITE Desenvolvimento em Múltiplos Locais (Multisite Development)
Projeto
Cronograma de Desenvolvimento Requerido (Required
SCED
Development Schedule)

Em Anexos, a Tabela 25 apresenta os valores dos Multiplicadores de Esforço
para cada driver de custo do sub-modelo Post-Architecture.

Considerando o cálculo dos Pontos de Função Não-Ajustados calculado na seção
“2.3.6. Contagem dos Pontos por Função Não-Ajustados”, simularemos o cálculo do esforço
usando o modelo COCOMO II.

O primeiro passo será converter o valor de Pontos por Função Não-Ajustados (PFNA)
em mil Linhas de Código (kSLOC). Para realizarmos esse cálculo, consideraremos que o
projeto será desenvolvido utilizando a linguagem Visual Basic. Consultando a Tabela 13,

44

obteremos o valor do fator de ajuste dos pontos por função calculados, para a linguagem
escolhida, e calculamos o tamanho do projeto, conforme segue.

Size = PFNA x 32 = 156 x 32 = 4992 (dividindo esse valor por mil, temos
aproximadamente 5 kSLOC)

Size = 5 kSLOC

Consideraremos agora que este é um projeto de nível médio, com todos os
multiplicadores de esforços apresentando valores nominais (1.00). Utilizaremos também o
valor de E = 1. Nesse caso estamos considerando que o projeto está em equilíbrio em relação
aos seus gastos e economias de escala. Dessa forma temos o seguinte resultado:

PM = 2.94 x 51.0 x 1.00 = 14.70 pessoa-mês

Cálculo do Prazo

Calculado o esforço para o desenvolvimento do projeto, mostraremos a seguir o
cálculo para estimarmos o prazo de desenvolvimento TDEV (Time To Development). Este
cálculo se dá através da equação Eq.2.4.3.3.

TDEV = C x (PM)(D + 0.2 x (E – B)) Eq. 2.4.3.3

Onde,

C é uma constante calibrada para o ambiente a ser aplicado o modelo.
variável valor C=3.67;

D é uma constante calibrada para o ambiente a ser aplicado o modelo.
variável valor D=0.28;

PM é o resultado do cálculo do esforço para o projeto;

E assume o mesmo valor do resultado da equação para cálculo do
esforço onde consideramos o somatório dos Fatores de Escala;

45

B é uma constante calibrada para o ambiente a ser aplicado o modelo.
variável valor B=0.91;

Aplicando-se os valores obtidos no cálculo do esforço e os valores calibrados pelo
COCOMO II.2000 na equação do cálculo do prazo, temos o seguinte resultado.

TDEV = 3.67 x (14.70)(0.28 + 0.2 x (1.0 – 0.91)

TDEV = 3.67 x (14.70)0.30

TDEV = 8.22 meses

2.4.4. Número Médio da Equipe

De posse dos valores de Esforço e Prazo, facilmente podemos calcular o número
médio da equipe, representado pela letra (P). Obteremos esse resultado dividindo o Esforço
pelo Prazo. O COCOMO II considera, para fins de cálculo de número médio da equipe, 152
horas para um mês de trabalho, excluindo feriados e finais de semana. Entretanto, esse valor
pode ser alterado de acordo com o ambiente em que o projeto será executado.

Determinaremos a equipe média para o projeto em questão através da equação
Eq.2.4.4.1.

P = PM / TDEV Eq.2.4.4.1

P = 14.70 / 8.22 = 1.80 (~2) pessoas

Esse resultado nos diz que, para realizarmos este projeto de desenvolvimento de
software, usando a tecnologia Visual Basic, tendo como 5 mil Linhas de Código, valores
médios em relação a multiplicadores de esforço, teremos seu desenvolvimento realizado em
um prazo estimado de 8.22 meses considerando uma equipe de 2 pessoas trabalhando 152
horas por mês.

46

2.5. Considerações Finais

Observamos que uma vez calculado o tamanho do software usando Análise de Pontos
por Função, o modelo COCOMO II complementa a estimativa em termos de esforço e prazo
para o desenvolvimento do projeto.

Entretanto o uso desses 2 modelos apenas, nos oferece a estimativa de tamanho,
esforço e prazo para execução do projeto. Falta estimar ainda qual nível de qualidade este
projeto terá.

Observando apenas os valores encontrados através dos modelos vistos até agora, por
melhor e real que seja essa estimativa, dificilmente nos dará uma previsão do nível de
qualidade na qual o produto final será entregue.

Podemos conseguir estimar algo em termos de qualidade do produto final, porém
teremos apenas uma noção, pois as informações que serão utilizadas nessa previsão, serão
informações estimadas no passado em outros projetos semelhantes, e que certamente não
condiz com 100% das características do projeto atual. Diante disso, como então estimar a
qualidade do produto a ser entregue?

No Capítulo 3, estudaremos um modelo preditivo de qualidade baseado na injeção e
remoção de defeitos. A proposta desse modelo é nos dar uma forma, baseado em bases
históricas e cálculos matemáticos, uma estimativa da qualidade do produto a ser entregue.
Este modelo terá como base, informações apresentadas nos modelos estudados no Capítulo 2.

47

CAPÍTULO 3 – MODELO DE ESTIMATIVA DE QUALIDADE – COQUALMO
(COnstructive QUALity MOdel)


Quando falamos em projeto de desenvolvimento de software, é necessário levarmos
três fatores em consideração: Custo, Prazo e Qualidade. Para Barry Boehm (Boehm, et al.,
2000) esses fatores estão fortemente correlacionados e formam os três lados de um mesmo
triângulo. Não é muito raro encontrarmos projetos de desenvolvimento de software onde o
lema é aumentar o máximo possível a qualidade sem que isso comprometa o custo e o prazo.
Entretanto, existe uma grande dificuldade em projetos de software em alcançar tal meta.

Para que tenhamos um nível alto de qualidade, é necessário que o custo e o prazo
acompanhem esse mesmo nível.

Projetos de desenvolvimento de software possuem particularidades intrínsecas e que
envolvem variáveis muitas vezes de difícil controle, como a agilidade de uma pessoa em uma
determinada tecnologia. Contudo, apenas conhecer a tecnologia a ser empregada não garante
a agilidade necessária ao desenvolvimento. Aumentar a equipe também não nos dá a certeza
de que o prazo de entrega do projeto poderá ser reduzido, e na maioria das vezes o que ocorre
é justamente o contrário do que se espera. Podemos comprovar esse fato quando Sunita
Chulani (Chulani, Constructive Quality Modeling for Defect Density Prediction:
COQUALMO, 1999) diz que a redução do prazo de desenvolvimento de um projeto de
software, para concluirmos o projeto em menos tempo, certamente provocará impacto
negativo no custo e principalmente na confiabilidade e qualidade do produto produzido. Por
outro lado, sabemos que o uso de técnicas de estimativas de custo, prazo e qualidade, auxilia
os gestores de projetos de software a tomarem, com maior precisão, decisões que impactem
diretamente e positivamente o sucesso de um projeto.

Conforme estudamos nos capítulos anteriores, técnicas e modelos de estimativas de
custo e prazo para projetos de software foram apresentadas, porém faltava um dos lados do
triângulo, comentado por Barry Boehm (Boehm, et al., 2000), a Qualidade.

Reconhecendo a necessidade de se fechar esse triângulo, Barry Boehm (Boehm, et al.,
2000) propôs um modelo de estimativa de qualidade como sendo uma extensão do modelo

48

COCOMO II, chamado COQUALMO (COnstructive QUALity MOdel). Este modelo foi
criado com a finalidade de auxiliar os gestores de projetos de software a determinarem a
qualidade do produto, baseando-se na densidade de defeitos, que por sua vez acaba sendo um
elemento preditivo natural da qualidade e confiabilidade de um software (Chulani, Steece, &
Boehm, Determining Software Quality Using COQUALMO, 2003).

3.2. Introdução

O modelo COQUALMO é uma extensão do modelo COCOMO II e baseia-se nos
modelos de “Injeção de Defeitos de Software” (DI) e “Remoção de Defeitos de Software”
(DR) descrito por Barry Boehm (Boehm, Software Engineering Economics, 1981). Estes
modelos são análogos ao modelo “tanque e duto (tank and pipe)“ proposto por Capers Jones
(Jones, 1975) e representado através da Figura 3.

De forma conceitual, representa o fluxo de defeitos injetados e removidos em um
“tanque” através de “dutos”. Esses defeitos são introduzidos através desses “dutos” e são
estimados através do modelo de “Injeção de Defeitos de Software” (DI – Defect Introduction
Software) e os defeitos removidos através de técnicas como testes e inspeções, são estimados
através do modelo “Remoção de Defeitos de Software” (DR – Defect Removal Software).

De acordo com Sunita Chulani (Chulani & Boehm, Modeling Software Defect
Introduction and Removal:COQUALMO (COnstructive QUALity MOdel), 1999), três são os
tipos de defeitos injetados durante a execução do projeto de software: Defeitos de Requisitos
(Requirements Defects), Defeitos de Desenho da Arquitetura da Solução (Design Defects) e
Defeitos de Codificação (Code Defects). Os defeitos residuais serão tratados posteriormente
na seção “3.4. Modelo de Remoção de Defeitos de Software (Defect Removal Software)
(DR).”

49

Figura 3 – Introdução e Remoção de Defeitos de Software. (Fonte: Sunita Chulani (Chulani,
Steece, & Boehm, Determining Software Quality Using COQUALMO, 2003))

3.3. Modelo de Injeção de Defeitos de Software (Defect Introduction Software) (DI)

Os defeitos podem ser injetados em um produto de software através de diversas
formas durante seu ciclo de vida. No modelo COQUALMO esses defeitos são classificados
da seguinte forma:

• Defeitos de Requisitos
• Defeitos de Desenho da Arquitetura da Solução
• Defeitos de Codificação

O COQUALMO é uma extensão do COCOMO II, e por conseqüência o modelo de
injeção de defeitos utiliza como parâmetros de entrada para cálculos preditivos, o tamanho do
software medido em mil Linhas de Código (Kilo Source Line Of Code – kSLOC), e podem
também ser ajustados no caso de reuso. Assim como utiliza kSLOC, este modelo utiliza os
multiplicadores de esforço de 21 dos 22 drivers de custo utilizados nas estimativas do
COCOMO II, divididos em 4 categorias de drivers, conforme referencia a Tabela 17.

50

Tabela 17 – Drivers do Modelo de Injeção de Defeitos de Software

Drivers de Injeção de Defeitos

Post-Architecture Early Design
Categoria Sigla Descrição Sigla Descrição
Confiabilidade Requerida do Confiabilidade e Complexidade do
RELY RCPX
Software Produto
DATA Tamanho da Base de Dados RUSE Reutilização
Produto CPLX Complexidade do Produto
RUSE Reutilização
Documentação Associada às
DOCU
Necessidades do Ciclo de Vida
Restrição do Tempo de Dificuldade da Plataforma
TIME PDIF
Execução
Plataforma Restrição de Armazenamento
STOR
Principal
PVOL Volatilidade da Plataforma
ACAP Habilidade do Analista PERS Capacidade do Pessoal
PCAP Habilidade do Programador PREX Experiência do Pessoal
PCON Continuidade do Pessoal
Pessoal APEX Experiência nas Aplicações
PLEX Experiência nas Plataformas
Experiência nas Ferramentas e
LTEX
Linguagens
Uso de Ferramentas de Facilidades
TOOL FCIL
Software
Desenvolvimento em Cronograma de Desenvolvimento
SITE SCED
Múltiplos Locais Requerido
Cronograma de
SCED
Projeto Desenvolvimento Requerido
PREC Precedência
Arquitetura/Resolução do
RESL
Risco
TEAM Coesão da Equipe
PMAT Maturidade do Processo

51

A Figura 4 apresenta graficamente a estrutura do modelo de injeção de defeitos.

Figura 4 – Modelo de Injeção de Defeitos de Software. (Fonte: Barry Boehm (Boehm, et al.,
2000))

Para Barry Boehm (Boehm, et al., 2000), a decisão de se usar esses drivers foi baseada
em um extenso trabalho de pesquisa e analisando o comportamento de determinados fatores
que afetam a injeção de defeitos em um projeto de desenvolvimento de software.

Um exemplo está na análise do nível de capacidade de um programador diante de uma
tecnologia, onde quanto mais alto for o nível, a tendência é que menos erros sejam injetados
no produto. A decisão de se usar os mesmos drivers que o modelo COCOMO II não somente
faz com que haja uma total integração entre os modelos, como também simplifica a atividade
de coleta e análise de dados e informações, pois são as mesmas informações.

Este modelo tem como saída uma estimativa da quantidade de defeitos não-triviais
para cada classificação de defeitos apresentada – requisitos, desenho da arquitetura da solução
e codificação – do produto de software, ou seja, defeitos injetados durante o ciclo de vida e
que podem passar sem que a equipe do projeto perceba que eles existam.

Os defeitos estimados através desse modelo, por contemplar apenas os defeitos não-
triviais, possuem a seguinte classificação quanto à sua severidade:

• Crítico (Critical) – Defeitos que causam uma parada total do sistema ou
perda irrecuperável dos dados ou que coloque em risco a integridade
física de pessoas;

52

• Alto (High) – Defeitos em alguma importante função do sistema e que
não se consiga contornar o problema com nenhuma solução existente;
• Médio (Medium) – Defeitos em alguma importante função do sistema,
porém o problema pode ser contornado com a aplicação de uma solução
existente.

O resultado dessa estimativa é calculado através da equação Eq.3.3.1.

Eq.3.3.1

Onde,

j representa as três classificações de Injeção de Defeitos (Requisitos, Desenho
da Arquitetura da Solução e Codificação);

Aj é uma constante calibrada para o ambiente a ser aplicado o modelo, ajustado
de acordo com cada classificação (j). Nos casos onde não existe calibração para ambiente
específico, sugere-se utilizar o valor calibrado para o modelo COCOMO II.2000, mostrado no
“Capítulo 2” seção “2.4.3. Estimativa de Esforço e Prazo”;

Size, é o tamanho do projeto calculado em Linhas de Código SLOC (Source
Line Of Code), Pontos por Função Não-ajustados (PFNA) ou qualquer outra unidade de
tamanho. A sugestão é que se use da mesma forma usada para o COCOMO II, calculando-se
pontos de função e convertendo em Linhas de Código;

B é uma constante equivalente ao expoente E do modelo COCOMO II.2000,
mostrado no “Capítulo 2” seção “2.4.3. Estimativa de Esforço e Prazo”. As taxas de
introdução de defeitos ainda são muito obscuras quanto à determinação de economias e
ganhos de escala. A principal questão é, se o tamanho dobra, isso quer dizer que a taxa
original de injeção de defeitos também aumenta em duas vezes? Caso seja isso de fato, indica
que houve ganhos de escala implicando em B > 1. Por outro lado, caso haja decréscimo de
duas vezes a taxa original de injeção de defeitos, isso indica que houve uma economia de

Estimando qualidade de software com COQUALMO

Estimando qualidade de software com COQUALMO

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Estimando qualidade de software com COQUALMO

Semelhante a Estimando qualidade de software com COQUALMO (20)

Estimando qualidade de software com COQUALMO