modelo de estimativa da qualidade em projeto de software baseado na prediÇÃo de defeitos
DESCRIPTION
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).TRANSCRIPT
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.1. CONSIDERAÇÕES INICIAIS ......................................................................................... 19 2.2. REGRESSÃO L INEAR .................................................................................................. 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 – CO QUALMO (CONSTRUCTIVE QUALITY MODEL) ........................................................................... 47
3.1. CONSIDERAÇÕES INICIAIS ......................................................................................... 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 ES TIMATIVAS 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.
(FONTE: FERNANDES (FERNANDES, 1995, P. 125) .............................................................. 30 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.
(FONTE: FERNANDES (FERNANDES, 1995, P. 125) .............................................................. 30 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.
(FONTE: FERNANDES (FERNANDES, 1995, P. 125) .............................................................. 31 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.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 75 TABELA 28 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER RUSE.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 75 TABELA 29 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER DOCU.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 76 TABELA 30 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER CPLX.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 76 TABELA 31 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER TIME.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 76 TABELA 32 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER STOR.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 77 TABELA 33 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PVOL.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 77 TABELA 34 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER ACAP.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 77 TABELA 35 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PCAP.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 78 TABELA 36 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PCON.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 78 TABELA 37 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER APEX.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 78 TABELA 38 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PLEX.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 79 TABELA 39 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER LTEX.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 79
TABELA 40 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER TOOL. (FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 79 TABELA 41 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER SITE.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 80 TABELA 42 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER SCED.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 80 TABELA 43 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PREC.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 80 TABELA 44 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER RESL.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 81 TABELA 45 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER TEAM.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 81 TABELA 46 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PMAT.
(FONTE: SUNITA CHULANI (CHULANI , RESULTS OF DELPHI FOR THE DEFECT
INTRODUCTION MODEL, 1997)) ................................................................................. 81
Í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
2.1. Considerações Iniciais
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
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
Ciclo Tamanho do Software em
Pontos de Função (X) Defeitos (Y)
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
0
50
100
150
200
250
300
350
400
450
500
0 1 2 3 4 5 6 7 8
# D
efe
ito
s
Ciclo
Defeitos(Y)
Defeitos(Y)
23
O Gráfico 2 apresenta a dispersão dos defeitos da amostragem da Tabela 2.
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
0
50
100
150
200
250
300
350
400
450
500
0 500 1000 1500 2000 2500 3000 3500
# D
efe
ito
s
Tamanho do Software (X)
# Defeitos(Y)
# Defeitos(Y)
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
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.
0
100
200
300
400
500
600
0 1000 2000 3000 4000
# D
efe
ito
s
Tamanho do Software (X)
# Defeitos(Y)
# Defeitos(Y)
Linear (# Defeitos(Y))
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 1 a 4 TED 5 a 15 TED 16 ou mais TED
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: Fernandes (Fernandes, 1995, p. 125)
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 1 a 5 TED 6 a 19 TED 20 ou mais TED
0 a 1 TAR Baixa Baixa Média 2 a 3 TAR Baixa Média Alta
4 ou mais TAR Média Alta Alta
Em função da complexidade de cada SE, são atribuídos pesos para os cálculos dos
pontos por função não-ajustados conforme Tabela 8.
Tabela 8 – Relação dos pesos de SE para determinação dos PF não-ajustados. (Fonte: Fernandes (Fernandes, 1995, p. 125)
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 0 a 1 TAR Baixa Baixa Média 2 a 3 TAR Baixa Média Alta
4 ou mais TAR Média Alta Alta Saídas 1 a 5 TED 6 a 19 TED 20 ou mais TED
0 a 1 TAR Baixa Baixa Média 2 a 3 TAR Baixa Baixa Alta
4 ou mais TAR Média Alta Alta
Em função da complexidade de cada CE, são atribuídos pesos para os cálculos dos
pontos por função não-ajustados conforme Tabela 10.
Tabela 10 – Relação dos pesos de CE para determinação dos PF não-ajustados. (Fonte: Fernandes (Fernandes, 1995, p. 125)
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)
Função Complexidade
Funcional Qtde
Peso Atribuído
Total por Função
Arquivo Lógico Interno (ALI) Alta 2 x 15 30
Média 2 x 10 20 Baixa 2 x 7 14
Total de Pontos de Função para Arquivos Lógicos Internos (ALI) 64
Arquivo de Interface Externo (AIE) Alta 3 x 10 30
Média 1 x 7 7 Baixa 1 x 5 5
Total de Pontos de Função para Arquivos de Interfaces Externos (AIE) 42
Entrada Externa (EE) Alta 0 x 6 0
Média 0 x 4 0 Baixa 1 x 3 3
Total de Pontos de Função para Entradas Externas (EE) 3
Saída Externa (SE) Alta 0 x 7 0
Média 1 x 5 5 Baixa 1 x 4 4
Total de Pontos de Função para Saídas Externas (SE) 9
Consulta Externa (CE) Alta 2 x 6 12
Média 4 x 5 20 Baixa 2 x 3 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))
Linguagem SLOC / PFNA
Linguagem SLOC / 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
Escala (SF)
Muito baixo
Baixo Nominal Alto Muito Alto Extra Alto
PREC Extremamente sem
Precedentes
Praticamente sem
Precedentes
Quase sem Precedentes
Pouco Familiar Muito Familiar Extremamente Familiar
SFj 6.20 4.96 3.72 2.48 1.24 0.00 FLEX Rigoroso Relaxamentos
Ocasionais Relaxamentos
Periódicos Conformidade
Geral Alguma
Conformidade Alta
Objetividade SFj 5.07 4.05 3.04 2.03 1.01 0.00 RESL Pouco
(20%) Algum (40%)
Frequente (60%)
Geralmente (75%)
Na maioria das vezes (90%)
Completamente (100%)
SFj 7.07 5.65 4.24 2.83 1.41 0.00 TEAM Alta
Dificuldade nas Iterações
Alguma Dificuldade nas Iterações
Baixa Dificuldade nas Iterações
Cooperatividade Alta
Cooperatividade Muito Alta
Iteração Completa
SFj 5.48 4.38 3.29 2.19 1.10 0.00 PMAT SW-CMM
Nivel 1 Baixo
SW-CMM Nível 1
Alto
SW-CMM Nível 2
SW-CMM Nível 3
SW-CMM Nível 4
SW-CMM Nível 5
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
Produto
RELY Confiabilidade Requerida do Software (Required Software Reliability)
DATA Tamanho da Base de Dados (Data Base Size) CPLX Complexidade do Produto (Product Complexity) RUSE Reutilização (Developed for Reusability)
DOCU Documentação Associada às Necessidades do Ciclo de Vida (Documentation Match to Life-Cycle Needs)
Plataforma TIME Restrição do Tempo de Execução (Execution Time Constraint) STOR Restrição de Armazenamento Principal (Main Storage Constraint) PVOL Volatilidade da Plataforma (Platform Volatility)
Pessoal
ACAP Habilidade do Analista (Analyst Capability) PCAP Habilidade do Programador (Programmer Capability) PCON Continuidade do Pessoal (Personnel Continuity) APEX Experiência nas Aplicações (Applications Experience) PLEX Experiência nas Plataformas (Platform Experience)
LTEX Experiência nas Ferramentas e Linguagens (Language and Tool Experience)
Projeto
TOOL Uso de Ferramentas de Software (Use of Software Tools) SITE Desenvolvimento em Múltiplos Locais (Multisite Development)
SCED Cronograma de Desenvolvimento Requerido (Required 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.
Após a calibração COCOMO II.2000 feita a partir do histórico de 161 projetos foi atribuído a
variável valor C=3.67;
D é 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 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.
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;
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 – CO QUALMO
(COnstructive QUALity MOdel)
3.1. Considerações Iniciais
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
Produto
RELY Confiabilidade Requerida do Software
RCPX Confiabilidade e Complexidade do Produto
DATA Tamanho da Base de Dados RUSE Reutilização CPLX Complexidade do Produto RUSE Reutilização
DOCU Documentação Associada às Necessidades do Ciclo de Vida
Plataforma
TIME Restrição do Tempo de Execução
PDIF Dificuldade da Plataforma
STOR Restrição de Armazenamento Principal
PVOL Volatilidade da Plataforma
Pessoal
ACAP Habilidade do Analista PERS Capacidade do Pessoal PCAP Habilidade do Programador PREX Experiência do Pessoal PCON Continuidade do Pessoal APEX Experiência nas Aplicações PLEX Experiência nas Plataformas
LTEX Experiência nas Ferramentas e Linguagens
Projeto
TOOL Uso de Ferramentas de Software
FCIL Facilidades
SITE Desenvolvimento em Múltiplos Locais
SCED Cronograma de Desenvolvimento Requerido
SCED Cronograma de Desenvolvimento Requerido
PREC Precedência
RESL Arquitetura/Resolução do 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
53
escala e consequentemente em B < 1? Diante dessas análises, para o modelo COQUALMO
sugere-se usar inicialmente o valor 1 para essa constante;
(DI – driver)ij são os multiplicadores de esforço referentes aos drivers de
Injeção de Defeitos, onde j representa as classificações de Injeções de Defeitos e i os fatores.
Simplificando a equação Eq.3.3.1, considerando que, para cada classificação j, a
definição de um novo parâmetro QAFj (Quality Adjustment Factor), chegamos à equação
Eq.3.3.2.
Eq.3.3.2
Aplicando a equação Eq.3.3.2 na Eq.3.3.1, temos que o total de número de defeitos
injetados será calculado através da equação Eq.3.3.3.
Eq.3.3.3
Desmembrando a Eq.3.3.3 para cada classificação j, obteremos outras três equações,
conforme segue.
Defeitos de Requisitos Injetados (DI req) = Areq x (Size)Breq x QAFreq Eq.3.3.4
Defeitos de Arquitetura Injetados (DI arq) = Aarq x (Size)Barq x QAFarq Eq.3.3.5
Defeitos de Codificação Injetados (DI cod) = Acod x (Size)Bcod x QAFcod Eq.3.3.6
Impacto dos Drivers na Injeção de Defeitos
Barry Boehm (Boehm, et al., 2000) e Sunita Chulani (Chulani, Steece, & Boehm,
Determining Software Quality Using COQUALMO, 2003) apresentam como exemplo uma
análise comportamental de como os drivers afetam diretamente o número de defeitos
injetados e consequentemente a qualidade do produto.
54
Tendo por base as informações da Tabela 18, que foram determinados utilizando o
Método Delphi1 durante um workshop com foco em COQUALMO realizado em conjunto
com o 13º Fórum Internacional em COCOMO e Modelagem do Custo de Software, Barry
Boehm (Boehm, et al., 2000).
Para o caso do índice de injeção de defeitos apresentar um valor DI > 1, mostra um
impacto negativo com um volume maior de defeitos injetados e consequentemente provocará
um baixo nível de qualidade no produto de software. Por outro lado, caso o índice apresente
um valor DI < 1, mostra um menor volume de defeitos injetados, o que consequentemente
provocará um maior nível de qualidade no produto de software.
Analisando os dados da Tabela 18 e considerando um projeto de software onde os
programadores possuem um alto nível de capacidade e habilidade na tecnologia empregada, o
índice DI nesse caso será de 0.76. Isso nos diz que apenas 76% dos defeitos nominais serão
injetados no produto de software durante o processo de codificação. Por outro lado, seguindo
raciocínio análogo, no caso dos programadores possuírem um nível muito baixo de
capacidade e habilidade na tecnologia, o índice será de 1.32, ou seja, indica que 132% dos
defeitos nominais serão injetados no produto de software durante a fase de codificação. Isso
faria com que a faixa de injeção de defeitos seja o resultado da razão entre o maior índice do
PCAP pelo menor índice, ou seja, 1.32/0.76, que seria igual a 1.74.
1 Método sistemático e interativo de estimativa que se baseia na experiência independente de vários
especialistas cuidadosamente selecionados pela sua experiência e respondem a um questionário em um ou
mais ciclos (Wikipédia, http://pt.wikipedia.org/wiki/M%C3%A9todo_Delphi, 2009).
55
Tabela 18 – PCAP Capacidade do Programador – Escala de Taxas da Injeção de Defeitos. (Fonte: Barry Boehm (Boehm, et al., 2000))
Nível PCAP Requisitos Arquitetura Codificação
Muito Alto (Very High) (VH) N/A
Menor número de defeitos no desenho da arquitetura da solução devido à facilidade de interação com as pessoas
envolvidas no projeto; Menor número de defeitos
injetados na fase de correção de defeitos.
Menor número de defeitos de codificação devido ao alto nível de detalhamento na fase de desenho da arquitetura,
menos desentendimentos conceituais e menos de
erros de codificação 1.00 0.85 0.76
Nominal 1.00
Muito Baixo (Very Low) (VL) N/A
Maior número de defeitos no desenho da arquitetura da
solução devido à dificuldade de interação com as pessoas
envolvidas no projeto; Maior número de defeitos
injetados na fase de correção de defeitos.
Maior número de defeitos de codificação devido ao
baixo nível de detalhamento na fase de desenho da arquitetura, mais desentendimentos conceituais e mais de erros de codificação
1.00 1.17 1.32 Delphi – Faixa das Taxas de Injeção de Defeitos
1.00 1.38 1.75
PCAP Muito Baixo (Very Low)
Baixo (Low)
Nominal Alto
(High) Muito Alto (Very High)
15% 35% 55% 75% 90%
Nos anos 70 foram usados alguns dados recolhidos de afiliados à USC’s2 COCOMO II, para o cálculo das taxas de injeção de defeitos (DIR – Defect Introduction Rates). Esses dados foram re-calibrados nos anos 90 para valores nominais, que representam o número de defeitos injetados (DI) por mil linhas de código (KSLOC) estimado sem que haja impacto no fator de ajuste da qualidade (QAF). Os valores nominais estimados foram DIRrequisitos = 10, DIRarquitetura = 20 e DIRcodificação = 30. Esse cálculo é realizado entre a razão do número de defeitos introduzidos pelo tamanho do projeto em kSLOC.
2 University of Southern California (CSSE, 1993)
56
O Gráfico 4 apresenta as escalas de Injeção de Defeitos de Codificação (DIR).
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))
Diante desse exemplo, não é difícil identificar a importância dos drivers nos cálculos
da quantidade de defeitos injetados em um produto de software. Em Anexos, pode ser
encontrado as demais tabelas com os valores de referência dos índices multiplicadores de
Injeção de Defeitos (DI) para cada driver de injeção de defeitos apresentados nesta seção.
57
3.4. Modelo de Remoção de Defeitos de Software (Defect Removal Software) (DR)
Este modelo tem por objetivo estimar o número de defeitos removidos baseando-se em
três tipos de remoção de defeitos:
• Remoção através de Análise Automatizada (Automated Analisys)
• Remoção através de Inspeções (Peer Reviews)
• Remoção através de Testes e Ferramentas para Execução (Executing Testing
and Tools)
Cada um desses três tipos de remoção de defeitos é responsável pela eliminação dos
defeitos introduzidos através da classificação dos três meios pelos quais um defeito é injetado
em um produto de software, conforme vimos seção “3.3. Modelo de Injeção de Defeitos de
Software (Defect Introduction Software) (DI)” – requisitos, desenho da arquitetura da solução
e codificação.
O modelo define uma classificação de seis níveis de capacidade de remoção de
defeitos para cada tipo de remoção utilizado, conforme pode ser visto através da Tabela 19.
A Figura 5 apresenta graficamente a estrutura do modelo de injeção de defeitos.
Figura 5 – Modelo de Remoção de Defeitos de Software. (Fonte: Barry Boehm (Boehm, et al., 2000))
58
O resultado da estimativa que nos dá o número residual de defeitos após o uso das
técnicas de remoção, é calculado através da equação Eq.3.4.1.
Eq.3.4.1
Onde,
j representa as três classificações de Injeção de Defeitos (Requisitos,
Arquitetura e Codificação);
DResEst,j número estimado de defeitos residuais para cada classificação de
injeção de defeitos (j);
Cj constante calibrada por artefato (j);
DIEst,j número estimado de injeção de defeitos encontrado para cada
classificação de injeção de defeitos (j);
i representa os três tipos de remoção de defeitos (Análise Automatizada,
Inspeções e Testes e Ferramentas de Execução). A faixa de valores atribuída à variável é de 1
a 3;
DRFij fração de remoção do defeito para cada tipo de remoção de defeito (i) e
classificação de injeção de defeitos (j). Os valores atribuídos à DRF foram obtidos durante o
Delphi, conforme mencionado na seção “3.3. Modelo de Injeção de Defeitos de Software
(Defect Introduction Software) (DI)” sub-seção “Impacto dos Drivers na Injeção de Defeitos”.
Maiores detalhes poderão ser encontrados em (Boehm, et al., 2000). Os valores dos DRF’s
calculados estão referenciados através da Tabela 20.
Dentre as atividades realizadas na aplicação da Análise Automatizada para remoção de
defeitos, algumas atividades como análise de código, analise sintática e semântica,
verificações nos requisitos e códigos, na consistência do desenho da arquitetura da solução e
rastreabilidade de informações, modelos de verificações formais como o V&V (Verificação &
Validação), dentre outros.
59
Em relação à atividade de Inspeção, tem-se a responsabilidade de revisar e inspecionar
todos os artefatos, processos e atividades inerentes ao projeto de desenvolvimento de software
com o objetivo de remover possíveis defeitos. Dependendo do nível de inspeção que se
deseja, o envolvimento do cliente/usuário é necessário para que se atinja o nível adequado e
solicitado de remoção de defeitos.
Por fim, a atividade de Testes e Ferramentas para Execução, tem a responsabilidade de
executar os testes necessários, através de ferramentas ou não, para a remoção dos defeitos de
software injetados. O nível normal que se espera dessa atividade é que ocorra no mínimo a
execução dos tipos de teste de Unidade, Integração e Sistema, baseado em uma lista de casos
e cenários de teste previamente elaborada, inclusive contendo o controle dos dados
necessários para a execução do teste.
60
Tabela 19 – Classificação dos Tipos de Remoção de Defeitos. (Fonte: Barry Boehm (Boehm, et al., 2000))
Classificação (Níveis)
Análise Automatizada Inspeção Teste e Ferramentas para
Execução Muito Baixo Compilação para simples
verificação da sintaxe. Nenhuma inspeção Nenhum teste
Baixo Análise básica de código para alguns módulos e compilação para simples verificação da sintaxe
Inspeções locais e informais. Preparação mínima. Nenhum follow-up.
Teste local e correção de defeitos. Realização de testes básicos usando apenas ferramentas de debugger.
Nominal Análise básica de código para todos os módulos e análise sintática. Verificação básica da consistência do desenho da solução, requisitos e rastreabilidade de informações.
Sequência de preparação e inspeção bem definidas. Follow-up mínimo. Inspeção informal em regras e procedimentos.
Execução básica de processo de testes de unidade, integração e sistema. Gerenciamento básico de dados para teste e rastreabilidade de defeitos. Critérios de teste baseados em checklists.
Alto Análise sintática e semântica para todos os módulos. Verificação básica da consistência do desenho da solução, requisitos e rastreabilidade de informações.
Inspeções formais em regras com inspetores treinados e procedimentos aplicados a todos os produtos usando checklist básico. Realizar follow-up.
Sequência de execução de teste bem definida e elaborada pela organização (aceitação/alfa/beta, etc). Uso de algumas ferramentas para auxílio e suporte ao teste. Gerenciamento básico do processo de teste.
Muito Alto Verificação mais elaborada da consistência do desenho da solução, requisitos e rastreabilidade de informações. Processamento distribuído básico e análise temporal, execução simbólica e análise de modelos.
Inspeções formais em regras com inspetores treinados e procedimentos aplicados a todos os produtos, artefatos e mudanças. Revisão básica de checlists e análise da origem da causa. Realizar follow-up formal. Uso de dados históricos sobre taxas de inspeção, preparação e densidade de falhas.
Uso avançado de ferramentas para execução e suporte de teste, e preparação de dados para teste. Análise e monitoração distribuída do teste. Coleta de métricas baseadas no gerenciamento do processo de teste.
Extra Alto Formalização de especificações e verificações. Processamento distribuído avançado e análise temporal, execução simbólica e análise de modelos.
Inspeção formal de regras e procedimentos para correções e controle de mudanças. Inspeções extensivas em checklists. Analises da origem da causa. Revisão contínua para melhoria do processo. Envolvimento do usuário/cliente, controle estatístico do processo.
Uso altamente avançado de ferramentas para execução e suporte ao teste. Análise e monitoração distribuída do teste. Análise automatizada da integração e das ferramentas de teste. Modelo baseado no gerenciamento de processo de teste.
61
Usando os valores nominais das Taxas de Injeção de Defeitos (DIR) e das Frações de
Remoção de Defeitos (DRF), foi possível chegar aos valores da densidade de defeitos
residuais, para cada tipos de remoção de defeitos, considerando as seis classificações de níveis
apresentadas na Tabela 19, conforme observamos através da Tabela 20.
Tabela 20 – Densidade de Defeitos Residuais dos Valores das Frações de Remoção de Defeitos. (Fonte: Barry Boehm (Boehm, et al., 2000))
Análise
Automatizada (DRF)
Inspeção (DRF)
Testes e Ferramentas de Execução
(DRF)
Produtório (1 – DRFij )
DI / kSLOC
DRes / kSLOC
Muito baixo
0.00 0.00 0.00 1.00 10.00(Req) 10.00 0.00 0.00 0.00 1.00 20.00(Arq) 20.00 0.00 0.00 0.00 1.00 30.00(Cod) 30.00
Total 60.00
Baixo 0.00 0.25 0.23 0.58 10.00(Req) 5.80 0.00 0.28 0.23 0.55 20.00(Arq) 11.00 0.10 0.30 0.38 0.39 30.00(Cod) 11.70
Total 28.50
Nominal 0.10 0.40 0.40 0.32 10.00(Req) 3.20 0.13 0.40 0.43 0.30 20.00(Arq) 6.00 0.20 0.48 0.58 0.17 30.00(Cod) 5.10
Total 14.30
Alto 0.27 0.50 0.50 0.18 10.00(Req) 1.80 0.28 0.54 0.54 0.15 20.00(Arq) 3.00 0.30 0.60 0.69 0.09 30.00(Cod) 2.70
Total 7.50
Muito Alto
0.34 0.58 0.57 0.14 10.00(Req) 1.40 0.44 0.70 0.65 0.06 20.00(Arq) 1.20 0.48 0.73 0.78 0.03 30.00(Cod) 0.90
Total 3.50
Extra Alto
0.40 0.70 0.60 0.07 10.00(Req) 0.70 0.50 0.78 0.70 0.03 20.00(Arq) 0.60 0.55 0.83 0.88 0.009 30.00(Cod) 0.27
Total 1.57
Para melhor entendimento de como ler os valores da Tabela 20, consideremos o nível
de classificação Alto. Observando a coluna “DI/kSLOC”, temos um valor de 10 defeitos de
requisito injetados a cada 10 mil linhas de código. Os valores das colunas “Análise
Automatizada (DRF)”, “Inspeção DRF” e “Testes e Ferramentas de Execução DRF”
62
representam a quantidade de defeitos removidos por essas ferramentas, que tem o percentual
fixado em 27%, 50% e 50% respectivamente, deixando um lote residual de defeitos de 18%,
conforme mostra a coluna representativa do Produtório(1 – DRF). Assim o valor DI/kSLOC é
ajustado em 18%, deixando 1.8 defeitos residuais (DR) por mil linhas de código (kSLOC).
3.5. Calibração do Modelo
A calibração do modelo COQUALMO é feita através de aproximação Bayesiana. Esse
método é utilizado por ser uma análise muito bem definida e um rigoroso processo de
raciocínio indutivo que permite ao investigador usar dados amostrais e informações prévias
(baseados na experiência de especialistas) de uma maneira logicamente consistente de se fazer
inferências.
Através do uso do Teorema de Bayes, os valores dos dados baseados na experiência
dos especialistas, são transformados para posterior distribuição em modelos paramétricos.
Essa transformação pode ser encarada como um processo de aprendizado, pois a distribuição
é determinada pelas variações dos dados prévios e dados da amostra. Caso a variação dos
dados prévios seja menor que a variação dos dados da amostra, é atribuído um peso maior aos
dados prévios. De forma análoga, caso a variação da amostra seja menor do que a variação
dos dados prévios, é atribuído um peso maior aos dados da amostra. Com isso consegue-se
fazer com que a estimativa extraída através dos dados prévios fique o mais próximo possível
dos dados amostrais.
Maiores detalhes poderão ser encontrados no artigo de Sunita Chulani, Steece e
Boehm (Chulani, Steece, & Boehm, Determining Software Quality Using COQUALMO,
2003).
63
CAPÍTULO 4 – APLICAÇÃO DOS MODELOS E TÉCNICAS DE ES TIMATIVAS
APRESENTADOS
Agora que temos em mãos informações sobre o modelo COQUALMO e como usá-lo,
demonstraremos seu uso com base nas informações relatadas neste estudo e informações de
algumas referências bibliográficas usadas para compor este estudo. Alguns valores serão
obtidos por inferência, apenas como forma didática para melhor apresentar a aplicação prática
do modelo, não sendo recomendado o uso desses valores resultantes para fins profissionais
práticos. Exceto valores extraídos de referências utilizadas para compor este trabalho e os
valores de referência das tabelas do Capítulo Anexos, que foram calculados baseados no
histórico de outros projetos.
Com a finalidade de mostrarmos a integração entre os modelos apresentados neste
estudo, primeiramente estimamos o tamanho do projeto usando Análise por Pontos de
Função, posteriormente calculamos o Esforço e Prazo usando o modelo COCOMO E
finalmente aplicamos o modelo para predição de qualidade COQUALMO.
Usaremos como referência o valor do Ponto de Função calculado neste estudo, os
valores de referência dos multiplicadores de drivers do Capítulo Anexos, e as características
do projeto apresentadas na Tabela 21 e a classificação dos tipos de remoção de defeitos
apresentados através da Tabela 22. Parte das classificações foi extraída de Sunita Chulani,
Steece e Boehm (Chulani, Steece, & Boehm, Determining Software Quality Using
COQUALMO, 2003).
64
Tabela 21 – Características do Projeto, Multiplicadores de Esforço e Injeção de Defeitos
Drivers Classificação Multiplicador
de Esforço (Post-Architecture)
Multiplicador Requisitos
Multiplicador Arquitetura
Multiplicador Codificação
RELY Alto 1.10 0.84 0.83 0.83 DATA Nominal 1.00 1.00 1.00 1.00 RUSE Muito Alto 1.15 1.02 1.02 1.00 DOCU Nominal 1.00 1.00 1.00 1.00 CPLX Nominal 1.00 1.00 1.00 1.00 TIME Alto 1.11 1.03 1.06 1.06 STOR Alto 1.05 1.03 1.06 1.05 PVOL Nominal 1.00 1.00 1.00 1.00 ACAP Alto 0.85 0.87 0.91 0.95 PCAP Alto 0.88 1.00 0.92 0.87 PCON Alto 0.90 0.91 0.89 0.88 APEX Muito Alto 0.81 0.81 0.82 0.88 PLEX Alto 0.91 0.95 0.93 0.93 LTEX Nominal 1.00 1.00 1.00 1.00 TOOL Muito Baixo 1.17 1.09 1.10 1.25 SITE Alto 0.93 0.94 0.94 0.95 SCED Muito Baixo 1.43 1.18 1.19 1.19 PREC Baixo 4.96 1.20 1.16 1.11 RESL Nominal 4.24 1.00 1.00 1.00 TEAM Alto 2.19 0.91 0.93 0.95 PMAT Nominal 4.68 1.00 1.00 1.00 FLEX Nominal 3.04 - - -
Tabela 22 – Classificação dos tipos de remoção de defeitos no projeto
Tipo de Remoção Classificação Fração de Remoção do Defeito (DRF)
Análise Automatizada
Baixo Requisitos 0.00 Arquitetura 0.00 Codificação 0.10
Inspeção Entre
Alto e Muito Alto
Requisitos (0.50+0.58)/2 = 0.54 Arquitetura (0.54+0.70)/2 = 0.62 Codificação (0.60+0.73)/2 = 0.67
Teste e Ferramentas de Execução
Alto Requisitos 0.50 Arquitetura 0.54 Codificação 0.69
65
4.1. Estimando o tamanho do projeto
Considerando os dados calculados através da Tabela 11, o tamanho do projeto foi
estimado com uso da técnica da análise por pontos de função não-ajustados (PFNA), cujo
valor encontrado foi:
PFNA = 156
Considerando um projeto desenvolvido usando a linguagem Visual Basic, utilizaremos
a Tabela 13 como referência do valor do fator de ajuste para a linguagem escolhida para o
projeto. Dessa forma, nossa estimativa de esforço é a seguinte.
Size = PFNA x 32 = 156 x 32 = 4992 SLOC,
Dividindo este resultado por mil encontraremos aproximadamente 5 kSLOC,
que é o valor do tamanho do projeto que procuramos, pois a unidade Size se dá em kSLOC.
Size = 5 kSLOC
4.2. Estimando o Esforço para Realização do Projeto
Usaremos a equação Eq.2.4.3.2 para encontrarmos o valor do expoente E, onde para o
valor da constante B, adotaremos o valor calibrado em COCOMO II.2000 (B = 0.91), e os
valores dos Fatores de Escala (SF), usaremos os valores calibrados em COCOMO II.2000 de
acordo com a Tabela 21, coluna “Multiplicador de Esforço Post-Architecture”.
E = B + 0.01 x ∑SFj
E = 0.91 + 0.01 x 19.11
E = 1.10
Aplicaremos a equação Eq.2.4.3.1 para cálculo do esforço do modelo COCOMO II,
onde para o valor da constante A, adotaremos o valor calibrado em COCOMO II.2000 (A =
2.94).
66
PM = 2.94 x 51.10 x 1.14 = 19.71 pessoas-mês
4.3. Estimando o Prazo para a Realização do Projeto
Para estimarmos o prazo do projeto, aplicaremos a equação Eq.2.4.3.3, usando o
modelo COCOMO II, onde para os valores das constantes C, D e B adotaremos os valores
calibrados em COCOMO II.2000 (B = 0.91, C = 3.67, D = 0.28).
TDEV = C x (PM)(D + 0.2 x (E – B))
TDEV = 3.67 x (19.71)(0.28 + 0.2 x (1.10 – 0.91) = 9.54 meses
4.4. Estimando o Tamanho da Equipe do Projeto
Seguindo o modelo COCOMO II, consideraremos que o projeto tenha 152 horas/mês
de trabalho, excluindo feriados e finais de semana. Aplicaremos a equação Eq. 2.4.4.1 para
estimarmos o tamanho da equipe necessária para o projeto.
P = PM / TDEV
P = 19.71 / 9.54 = 2 pessoas
4.5. Estimando a Qualidade do Projeto
4.5.1. Estimando a Quantidade de Defeitos Injetados
Para estimarmos a quantidade de defeitos injetados, aplicaremos antes a equação Eq.
3.3.2 para calcularmos o fator de ajuste da qualidade (QAF) para cada uma das três
classificações de formas de injeção de defeitos em um projeto (Requisitos, Arquitetura e
Codificação). Os valores de DI-driver a serem usados são os calibrados em (Chulani,
RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997) de acordo
com a Tabela 21, colunas “Multiplicador de Requisitos”, “Multiplicador de Arquitetura” e
“Multiplicador de Codificação”.
QAFReq = 0.73
67
QAFArq = 0.72
QAFCod = 0.82
Aplicaremos as equações Eq.3.3.4, Eq.3.3.5 e Eq.3.3.6 para estimarmos a quantidade
de defeitos injetados para cada uma das três classificações de formas de injeção de defeitos
em um projeto (Requisitos, Desenho da Arquitetura da Solução e Codificação). Os valores das
constantes AReq, AArq e ACod, adotaremos o valor calibrado em COCOMO II.2000 (A = 2.94),
e os valores das constantes BReq, BArq e BCod, assumiremos o mesmo valor calculado para o
expoente E = 1.10.
DI req = Areq x (Size)Breq x QAFreq
DI req = 2.94 x 51.10 x 0.73 = 12.62 (~13) defeitos de requisitos injetados
DI arq = Aarq x (Size)Barq x QAFarq
DI arq = 2.94 x 51.10 x 0.72 = 12.44 (~13) defeitos de arquitetura injetados
DI cod = Acod x (Size)Bcod x QAFcod
DI cod = 2.94 x 51.10 x 0.82 = 14.18 (~14) defeitos de codificação injetados
Calculando o índice de defeitos injetados (DIR) por kSLOC.
DIRRes = DIRes / kSLOC = 13/5 = 2.6
DIRArq = DIArq / kSLOC = 13/5 = 2.6
DIRCod = DICod / kSLOC = 14/5 = 2.8
4.5.2. Estimando a Quantidade de Defeitos Residuais
Baseado nas informações da Tabela 22 podemos calcular o Produtório(PROD) para
cada classificação de injeção de defeitos, considerando as frações de remoção de defeitos para
cada técnica de remoção.
PRODReq(1 – DRF) = 0.23
PRODArq (1 – DRF) = 0.17
68
PRODCod(1 – DRF) = 0.09
Calculado o Produtório(PROD), aplicaremos a equação Eq. 3.4.1 para estimarmos a
quantidade de defeitos residuais do projeto após uso das técnicas de remoção de defeitos
(Análise Automatizada, Inspeção, Teste e Ferramentas para Execução), para cada uma das
três classificações de injeção de defeitos. Adotaremos como valor da constante C = 1.
DResReq = CReq x DIReq x ProdutórioReq(1 – DRF)
DResReq = 1 x 13 x 0.23 = 2.99
DResArq = CArq x DIArq x ProdutórioArq(1 – DRF)
DResArq = 1 x 13 x 0.17 = 2.21
DResCod = CCod x DICod x ProdutórioCod(1 – DRF)
DResCod = 1 x 14 x 0.09 = 1.26
Calculando o índice residual de defeitos (DRes) por kSLOC
DRRReq = DResReq / kSLOC = 2.99/5 = 0.60
DRRArq = DResArq / kSLOC = 2.21/5 = 0.44
DRRCod = DResCod / kSLOC = 1.26/5 = 0.25
4.6. Considerações finais
Considerando as características do projeto e usando os modelos e técnicas de
estimativas (Análise por Ponto de Função e COCOMO II), estimamos que este projeto terá
duração de 9.54 meses considerando 2 pessoas trabalhando 152 horas por mês.
Usando o modelo COQUALMO estimamos também a qualidade no qual o produto
terá após implementação. Estimativa essa baseada no número de defeitos injetados e
removidos do produto de software. Após os cálculos e análises estimamos que, para este
projeto teremos uma quantidade total de 40 defeitos injetados, sendo que desses, 13 defeitos
69
de requisitos, 13 de desenho da arquitetura da solução e 14 de codificação, a um índice de 2.6,
2.6 e 2.8 defeitos injetados por mil linhas de código (kSLOC), respectivamente. Calculadas as
frações de defeitos residuais, conforme mostra a Tabela 22 e o grau de utilização das técnicas
de remoção de defeitos a ser aplicada neste projeto, pudemos também estimar uma quantidade
residual de 6.4 defeitos, sendo que destes, 2.99 defeitos de requisitos, 2.21 de desenho da
arquitetura da solução e 1.2 de codificação, a um índice residual de 0.60, 0.41 e 0.25 defeitos
por mil linhas de código (kSLOC), respectivamente, conforme ilustra a Tabela 23.
Tabela 23 – Densidade residual de defeitos
Artefato de Injeção de
Defeito
Análise Automatizada
Inspeção Teste e
Ferramentas de Execução
Produtório (1 – DRF)
DI/ kSLOC
DRes/ kSLOC
Requisito 0.00 0.54 0.50 0.23 2.60 0.60 Arquitetura 0.00 0.62 0.54 0.17 2.60 0.44 Codificação 0.10 0.67 0.69 0.09 2.80 0.25
70
CAPÍTULO 5 – CONCLUSÃO E TRABALHOS FUTUROS
Atualmente o uso de modelos e técnicas de estimativas de projetos de software
encontra certa resistência por parte das organizações. A justificativa é o fato de serem
complexas e demoradas demais para serem implementadas, e os projetos não podem esperar
esse tempo para se adequarem.
Em parte existe certa coerência na justificativa, entretanto não podemos nos esquecer
que, para atingirmos um nível adequado de maturidade em qualquer que seja a área ou
processo, precisamos antes adquirir conhecimento acerca dessa área ou processo,
armazenando periodicamente o histórico de informações sobre fatos e acontecimentos da área
ou processo. A partir daí podermos cruzar dados, estabelecer métricas e analisar os resultados
obtidos. Somente depois desse trabalho é que poderemos, enfim, predizer com um grau muito
próximo da realidade como e de que forma um determinado projeto poderá ser conduzido e
quão grande ele será.
Analisando com foco estratégico, uma boa estimativa certamente dará subsídios para
que seja possível antecipar certas decisões para a organização, pois o resultado dessa
estimativa pode revelar dados que podem não condizer com a estratégia traçada pela empresa
naquele momento e levar a decisão de não aprovar a execução do projeto, o que caso fosse
aprovado, provocaria um gasto desnecessário e que não traria nenhum tipo de benefício à
organização. A contrapartida também é verdadeira, a decisão de apostar em um projeto que
trará retorno benéfico e estratégico para a organização. A diferença é apostar de olho no alvo
e não no escuro, como ocorre em diversas organizações.
O modelo preditivo de qualidade COQUALMO soma-se aos modelos de estimativa de
tamanho, esforço e prazo apresentados neste estudo. O cuidado tomado na seleção dos
modelos e técnicas de estimativas foi com foco no uso das melhores práticas na área de
estimativas e mostrar que é possível utilizar esses modelos conhecidos e aceitos pelo
mercado, utilizando as mesmas variáveis e consequentemente a mesma base histórica de
informações que o modelo preditivo da qualidade de um projeto. Ficou claro que o uso
conjunto desses modelos e técnicas auxilia na composição de informações que subsidiam
fortemente os líderes dos projetos e melhoram suas tomadas de decisão, tanto para tamanho,
71
esforço, custo e prazo de um projeto, e agora também da qualidade do produto que ainda será
entregue ao cliente.
Esse conjunto de informações agrega uma vantagem altamente estratégica e
competitiva às organizações, principalmente em um mercado globalizado onde cada vez mais
os clientes buscam entregar seus projetos a empresas que possuem e mostam a capacidade de
entregar um produto de baixo custo, dentro do prazo e orçamento, e principalmente com o
melhor nível de qualidade possível. A organização que conseguir aliar todas essas
informações e evoluir continuamente esse processo, certamente estarão prontas para os
desafios do novo milênio quando o assunto for oferecer produtos e serviços de software de
baixo custo, dentro do prazo e com alto nível de qualidade.
Como sugestão de continuidade desse estudo e trabalhos futuros, realizaremos uma
aplicação prática do uso conjunto dos modelos e técnicas apresentados neste trabalho.
Utilizando Análise Por Pontos de Função para estimar o tamanho do projeto, o modelo
COCOMO II para estimar o esforço e prazo para execução do projeto e o modelo
COQUALMO para estimar a qualidade do projeto, executando a calibração desses modelos
de acordo com a base histórica de projetos escolhidos para essa finalidade. Por fim,
analisaremos os resultados comparando-os a evolução do processo frente a projetos estimados
sem o uso dos modelos e técnicas de estimativas de projetos de desenvolvimento de software.
72
REFERÊNCIAS BIBLIOGRÁFICAS
Aguiar , M. (01 de 08 de 2009). http://www.metricas.com.br. Acesso em 25 de 07 de 2009, disponível em TI Métricas: http://www.metricas.com.br/downloads/Estimando_Projetos_COCOMO_II.pdf
Boehm, B. W. (1981). Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall.
Boehm, B. W., Abts, C., Brown, A. W., Chulani, S., Clark, B. K., Horowitz, E., et al. (2000). Software Cost Estimation with COCOMO II. New Jersey: Prentice Hall PTR.
Chulani, S. (1999). Constructive Quality Modeling for Defect Density Prediction: COQUALMO.
Chulani, S. (s.d.). Modeling Software Defect Introduction. Los Angeles, CA, USA.
Chulani, S. (30 de 06 de 1997). RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL.
Chulani, S., & Boehm, B. (1999). Modeling Software Defect Introduction and Removal: COQUALMO (COnstructive QUALity MOdel). Los Angeles, CA, USA.
Chulani, S., & Boehm, B. (1999). Modeling Software Defect Introduction and Removal:COQUALMO (COnstructive QUALity MOdel). Los Angeles, CA, USA.
Chulani, S., Steece, B. M., & Boehm, B. (2003). Determining Software Quality Using COQUALMO. In: W. R. Blischke, & D. N. Murthy, Case Studies in Reliability and Maintenance (pp. 293 - 311). New Jersey: Wiley-Interscience.
CSSE, U. . (1993). http://csse.usc.edu/csse/index.html. Acesso em 10 de 07 de 2009, disponível em USC - Center for Systems and Software Engineering: http://csse.usc.edu/csse/index.html
Fenton, N. E. (1991). Software metrics: a rigorous approach. Londres: Chapman & Hall.
Fernandes, A. A. (1995). Gerência de Software Através de Métricas: garantindo a qualidade do projeto, processo e produto. São Paulo: Atlas.
Group, I. -I. (s.d.). http://www.ifpug.org/. Acesso em 10 de 07 de 2009, disponível em http://www.ifpug.org/
Jones, C. J. (1975). "Programming Defect Removal," Proceedings, GUIDE 40, 1975.
López, P. A. (2005). COCOMO II, Um modelo para estimativa de custos de projetos de software. São Leopoldo, RS, Brasil.
73
Madachy, R., & Boehm, B. (2008). ODC COQUALMO: A Software Defect Introduction and Removal Model using Orthogonal Defect Classification. Los Angeles, CA, USA.
Pressman, R. S. (2002). Engenharia de Software, 5ª Edição. Rio de janeiro: McGraw-Hill.
Sommerville, I. (2003). Engenharia de Software, 6ª Edição. São Paulo: Addison Wesley.
Trindade, A. L., Pessôa, M. S., & Spinola, M. d. (1999). COCOMO II uma compilação de informações sobre a nova métrica. São Paulo, SP, Brasil.
USC, C. f. (2000). COCOMO II - Model Definition Manual. Los Angeles, CA, USA.
Vazquez, C. E., Simões, G. S., & Machado, R. (2003). Análise de Pontos de Função: medição, estimativas e gerenciamento de projetos de software. São Paulo: Érica.
Wikipédia , a. e. (29 de 06 de 2009). http://pt.wikipedia.org/wiki/Crise_do_software. Acesso em 22 de 07 de 2009, disponível em Wikipédia, a enciclopédia livre: http://pt.wikipedia.org/wiki/Crise_do_software
Wikipédia , a. e. (2009). http://pt.wikipedia.org/wiki/M%C3%A9todo_Delphi. Acesso em 08 de 08 de 2009, disponível em Wikipédia, a enciclopédia livre: http://pt.wikipedia.org/wiki/M%C3%A9todo_Delphi
74
ANEXOS
Tabela 24 – Valores dos EM para o Sub-Modelo Early Design (Fonte: COCOMO II Manual 2000 (USC, 2000))
Drivers de Custo
Multiplicadores de Esforço Extra Baixo
Muito Baixo
Baixo Nominal Alto Muito Alto
Extra Alto
RCPX 0.49 0.60 0.83 1.00 1.33 1.91 2.72 RUSE - - 0.95 1.00 1.07 1.15 1.24 PDIF - - 0.87 1.00 1.29 1.81 2.61 PERS 2.12 1.62 1.26 1.00 0.83 0.63 0.50 PREX 1.59 1.33 1.22 1.00 0.87 0.74 0.62 FCIL 1.43 1.30 1.10 1.00 0.87 0.73 0.62 SCED - 1.43 1.14 1.00 1.00 1.00 -
Tabela 25 – Valores dos EM para o Sub-Modelo Post-Architecture (Fonte: COCOMO II Manual 2000 (USC, 2000))
Fator Drivers de
Custo
Multiplicadores de Esforço Extra Baixo
Muito Baixo
Baixo Nominal Alto Muito Alto
Extra Alto
Produto
RELY - 0.82 0.92 1.00 1.10 1.26 - DATA - - 0.90 1.00 1.14 1.28 - CPLX - 0.73 0.87 1.00 1.17 1.34 1.74 RUSE - - 0.95 1.00 1.07 1.15 1.24 DOCU - 0.81 0.91 1.00 1.11 1.23 -
Plataforma TIME - - - 1.00 1.11 1.29 1.63 STOR - - - 1.00 1.05 1.17 1.46 PVOL - - 0.87 1.00 1.15 1.30 -
Pessoal
ACAP - 1.42 1.19 1.00 0.85 0.71 - PCAP - 1.34 1.15 1.00 0.88 0.76 - PCON - 1.29 1.12 1.00 0.90 0.81 - APEX - 1.22 1.10 1.00 0.88 0.81 - PLEX - 1.19 1.09 1.00 0.91 0.85 - LTEX - 1.20 1.09 1.00 0.91 0.84 -
Projeto TOOL - 1.17 1.09 1.00 0.90 0.78 - SITE - 1.22 1.09 1.00 0.93 0.86 0.80 SCED - 1.43 1.14 1.00 1.00 1.00 -
75
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))
RELY Classificação
Requisitos Arquitetura Codificação
Extra Alto - - - Muito Alto 0.70 0.69 0.69 Alto 0.84 0.83 0.83 Nominal 1.00 1.00 1.00 Baixo 1.20 1.20 1.20 Muito baixo 1.43 1.45 1.45
Tabela 27 – Índices dos Multiplicadores de Injeção de Defeitos para o driver DATA. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
DATA Classificação
Requisitos Arquitetura Codificação
Extra Alto - - - Muito Alto 1.07 1.10 1.15 Alto 1.03 1.05 1.05 Nominal 1.00 1.00 1.00 Baixo 0.93 0.91 0.91 Muito baixo - - -
Tabela 28 – Índices dos Multiplicadores de Injeção de Defeitos para o driver RUSE. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
RUSE Classificação
Requisitos Arquitetura Codificação
Extra Alto 1.05 1.02 1.02 Muito Alto 1.02 1.02 1.00 Alto 1.02 1.00 1.00 Nominal 1.00 1.00 1.00 Baixo 0.95 0.98 0.98 Muito baixo - - -
76
Tabela 29 – Índices dos Multiplicadores de Injeção de Defeitos para o driver DOCU. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
DOCU Classificação
Requisitos Arquitetura Codificação
Extra Alto - - - Muito Alto 0.86 0.85 0.85 Alto 0.93 0.92 0.92 Nominal 1.00 1.00 1.00 Baixo 1.08 1.09 1.09 Muito baixo 1.16 1.18 1.18
Tabela 30 – Índices dos Multiplicadores de Injeção de Defeitos para o driver CPLX. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
CPLX Classificação
Requisitos Arquitetura Codificação
Extra Alto 1.32 1.41 1.41 Muito Alto 1.15 1.19 1.19 Alto 1.10 1.12 1.12 Nominal 1.00 1.00 1.00 Baixo 0.87 0.84 0.84 Muito baixo 0.76 0.71 0.71
Tabela 31 – Índices dos Multiplicadores de Injeção de Defeitos para o driver TIME. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
TIME Classificação
Requisitos Arquitetura Codificação
Extra Alto 1.08 1.20 1.20 Muito Alto 1.04 1.10 1.10 Alto 1.03 1.06 1.06 Nominal 1.00 1.00 1.00 Baixo - - - Muito baixo - - -
77
Tabela 32 – Índices dos Multiplicadores de Injeção de Defeitos para o driver STOR. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
STOR Classificação
Requisitos Arquitetura Codificação
Extra Alto 1.08 1.18 1.15 Muito Alto 1.04 1.09 1.07 Alto 1.03 1.06 1.05 Nominal 1.00 1.00 1.00 Baixo - - - Muito baixo - - -
Tabela 33 – Índices dos Multiplicadores de Injeção de Defeitos para o driver PVOL. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
PVOL Classificação
Requisitos Arquitetura Codificação
Extra Alto - - - Muito Alto 1.16 1.20 1.22 Alto 1.08 1.11 1.10 Nominal 1.00 1.00 1.00 Baixo 0.86 0.83 0.82 Muito baixo - - -
Tabela 34 – Índices dos Multiplicadores de Injeção de Defeitos para o driver ACAP. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
ACAP Classificação
Requisitos Arquitetura Codificação
Extra Alto - - - Muito Alto 0.75 0.83 0.90 Alto 0.87 0.91 0.95 Nominal 1.00 1.00 1.00 Baixo 1.15 1.10 1.05 Muito baixo 1.33 1.20 1.11
78
Tabela 35 – Índices dos Multiplicadores de Injeção de Defeitos para o driver PCAP. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
PCAP Classificação
Requisitos Arquitetura Codificação
Extra Alto - - - Muito Alto 1.00 0.85 0.76 Alto 1.00 0.92 0.87 Nominal 1.00 1.00 1.00 Baixo 1.00 1.08 1.15 Muito baixo 1.00 1.17 1.32
Tabela 36 – Índices dos Multiplicadores de Injeção de Defeitos para o driver PCON. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
PCON Classificação
Requisitos Arquitetura Codificação
Extra Alto - - - Muito Alto 0.82 0.80 0.77 Alto 0.91 0.89 0.88 Nominal 1.00 1.00 1.00 Baixo 1.10 1.12 1.14 Muito baixo 1.22 1.25 1.30
Tabela 37 – Índices dos Multiplicadores de Injeção de Defeitos para o driver APEX. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
APEX Classificação
Requisitos Arquitetura Codificação
Extra Alto - - - Muito Alto 0.81 0.82 0.88 Alto 0.90 0.91 0.94 Nominal 1.00 1.00 1.00 Baixo 1.11 1.10 1.06 Muito baixo 1.24 1.22 1.13
79
Tabela 38 – Índices dos Multiplicadores de Injeção de Defeitos para o driver PLEX. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
PLEX Classificação
Requisitos Arquitetura Codificação
Extra Alto - - - Muito Alto 0.90 0.86 0.86 Alto 0.95 0.93 0.93 Nominal 1.00 1.00 1.00 Baixo 1.05 1.08 1.08 Muito baixo 1.11 1.17 1.16
Tabela 39 – Índices dos Multiplicadores de Injeção de Defeitos para o driver LTEX. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
LTEX Classificação
Requisitos Arquitetura Codificação
Extra Alto - - - Muito Alto 0.93 0.88 0.82 Alto 0.96 0.94 0.91 Nominal 1.00 1.00 1.00 Baixo 1.03 1.06 1.10 Muito baixo 1.07 1.13 1.22
Tabela 40 – Índices dos Multiplicadores de Injeção de Defeitos para o driver TOOL. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
TOOL Classificação
Requisitos Arquitetura Codificação
Extra Alto - - - Muito Alto 0.92 0.91 0.80 Alto 0.96 0.95 0.89 Nominal 1.00 1.00 1.00 Baixo 1.04 1.05 1.12 Muito baixo 1.09 1.10 1.25
80
Tabela 41 – Índices dos Multiplicadores de Injeção de Defeitos para o driver SITE. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
SITE Classificação
Requisitos Arquitetura Codificação
Extra Alto 0.83 0.83 0.85 Muito Alto 0.91 0.91 0.92 Alto 0.94 0.94 0.95 Nominal 1.00 1.00 1.00 Baixo 1.10 1.10 1.09 Muito baixo 1.20 1.20 1.18
Tabela 42 – Índices dos Multiplicadores de Injeção de Defeitos para o driver SCED. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
SCED Classificação
Requisitos Arquitetura Codificação
Extra Alto - - - Muito Alto 0.85 0.84 0.84 Alto 0.92 0.92 0.92 Nominal 1.00 1.00 1.00 Baixo 1.09 1.09 1.09 Muito baixo 1.18 1.19 1.19
Tabela 43 – Índices dos Multiplicadores de Injeção de Defeitos para o driver PREC. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
PREC Classificação
Requisitos Arquitetura Codificação
Extra Alto 0.84 0.75 0.81 Muito Alto 0.89 0.87 0.90 Alto 0.70 0.91 0.93 Nominal 1.00 1.00 1.00 Baixo 1.20 1.16 1.11 Muito baixo 1.43 1.34 1.24
81
Tabela 44 – Índices dos Multiplicadores de Injeção de Defeitos para o driver RESL. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
RESL Classificação
Requisitos Arquitetura Codificação
Extra Alto 0.76 0.70 0.71 Muito Alto 0.87 0.84 0.84 Alto 0.91 0.89 0.89 Nominal 1.00 1.00 1.00 Baixo 1.15 1.20 1.19 Muito baixo 1.32 1.43 1.41
Tabela 45 – Índices dos Multiplicadores de Injeção de Defeitos para o driver TEAM. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
TEAM Classificação
Requisitos Arquitetura Codificação
Extra Alto 0.75 0.80 0.85 Muito Alto 0.87 0.90 0.92 Alto 0.91 0.93 0.95 Nominal 1.00 1.00 1.00 Baixo 1.16 1.12 1.09 Muito baixo 1.34 1.26 1.18
Tabela 46 – Índices dos Multiplicadores de Injeção de Defeitos para o driver PMAT. (Fonte: Sunita Chulani (Chulani, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997))
PMAT Classificação
Requisitos Arquitetura Codificação
Extra Alto 0.73 0.61 0.63 Muito Alto 0.85 0.78 0.79 Alto 0.90 0.85 0.86 Nominal 1.00 1.00 1.00 Baixo 1.17 1.28 1.26 Muito baixo 1.38 1.65 1.58