modelo de estimativa da qualidade em projeto de software baseado na prediÇÃo de defeitos

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.


INTRODUCTION MODEL, 1997)) ................................................................................. 75 TABELA 29 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER DOCU.


INTRODUCTION MODEL, 1997)) ................................................................................. 76 TABELA 30 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER CPLX.


INTRODUCTION MODEL, 1997)) ................................................................................. 76 TABELA 31 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER TIME.


INTRODUCTION MODEL, 1997)) ................................................................................. 76 TABELA 32 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER STOR.


INTRODUCTION MODEL, 1997)) ................................................................................. 77 TABELA 33 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PVOL.


INTRODUCTION MODEL, 1997)) ................................................................................. 77 TABELA 34 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER ACAP.


INTRODUCTION MODEL, 1997)) ................................................................................. 77 TABELA 35 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PCAP.


INTRODUCTION MODEL, 1997)) ................................................................................. 78 TABELA 36 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PCON.


INTRODUCTION MODEL, 1997)) ................................................................................. 78 TABELA 37 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER APEX.


INTRODUCTION MODEL, 1997)) ................................................................................. 78 TABELA 38 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PLEX.


INTRODUCTION MODEL, 1997)) ................................................................................. 79 TABELA 39 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER LTEX.


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.


INTRODUCTION MODEL, 1997)) ................................................................................. 80 TABELA 42 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER SCED.


INTRODUCTION MODEL, 1997)) ................................................................................. 80 TABELA 43 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PREC.


INTRODUCTION MODEL, 1997)) ................................................................................. 80 TABELA 44 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER RESL.


INTRODUCTION MODEL, 1997)) ................................................................................. 81 TABELA 45 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER TEAM.


INTRODUCTION MODEL, 1997)) ................................................................................. 81 TABELA 46 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PMAT.


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


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


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


Tabela 8 – Relação dos pesos de SE para determinação dos PF não-ajustados. (Fonte: 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


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


Tabela 10 – Relação dos pesos de CE para determinação dos PF não-ajustados. (Fonte: 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


Total de Pontos de Função para Arquivos de Interfaces Externos (AIE) 42

Entrada Externa (EE) Alta 0 x 6 0


Total de Pontos de Função para Entradas Externas (EE) 3

Saída Externa (SE) Alta 0 x 7 0


Total de Pontos de Função para Saídas Externas (SE) 9

Consulta Externa (CE) Alta 2 x 6 12


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.


variável valor C=3.67;

D é uma constante calibrada para o ambiente a ser aplicado o modelo.


variável valor D=0.28;

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

E assume o mesmo valor do resultado da equação para cálculo do

esforço onde consideramos o somatório dos Fatores de Escala;

45

B é uma constante calibrada para o ambiente a ser aplicado o modelo.


variável valor B=0.91;

Aplicando-se os valores obtidos no cálculo do esforço e os valores calibrados pelo

COCOMO II.2000 na equação do cálculo do prazo, temos o seguinte resultado.

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

TDEV = 3.67 x (14.70)0.30

TDEV = 8.22 meses

2.4.4. Número Médio da Equipe

De posse dos valores de Esforço e Prazo, facilmente podemos calcular o número

médio da equipe, representado pela letra (P). Obteremos esse resultado dividindo o Esforço

pelo Prazo. O COCOMO II considera, para fins de cálculo de número médio da equipe, 152

horas para um mês de trabalho, excluindo feriados e finais de semana. Entretanto, esse valor

pode ser alterado de acordo com o ambiente em que o projeto será executado.

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

Eq.2.4.4.1.

P = PM / TDEV Eq.2.4.4.1

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

Esse resultado nos diz que, para realizarmos este projeto de desenvolvimento de

software, usando a tecnologia Visual Basic, tendo como 5 mil Linhas de Código, valores

médios em relação a multiplicadores de esforço, teremos seu desenvolvimento realizado em

um prazo estimado de 8.22 meses considerando uma equipe de 2 pessoas trabalhando 152

horas por mês.

46

2.5. Considerações Finais

Observamos que uma vez calculado o tamanho do software usando Análise de Pontos

por Função, o modelo COCOMO II complementa a estimativa em termos de esforço e prazo

para o desenvolvimento do projeto.

Entretanto o uso desses 2 modelos apenas, nos oferece a estimativa de tamanho,

esforço e prazo para execução do projeto. Falta estimar ainda qual nível de qualidade este

projeto terá.

Observando apenas os valores encontrados através dos modelos vistos até agora, por

melhor e real que seja essa estimativa, dificilmente nos dará uma previsão do nível de

qualidade na qual o produto final será entregue.

Podemos conseguir estimar algo em termos de qualidade do produto final, porém

teremos apenas uma noção, pois as informações que serão utilizadas nessa previsão, serão

informações estimadas no passado em outros projetos semelhantes, e que certamente não

condiz com 100% das características do projeto atual. Diante disso, como então estimar a

qualidade do produto a ser entregue?

No Capítulo 3, estudaremos um modelo preditivo de qualidade baseado na injeção e

remoção de defeitos. A proposta desse modelo é nos dar uma forma, baseado em bases

históricas e cálculos matemáticos, uma estimativa da qualidade do produto a ser entregue.

Este modelo terá como base, informações apresentadas nos modelos estudados no Capítulo 2.

47

CAPÍTULO 3 – MODELO DE ESTIMATIVA DE QUALIDADE – CO QUALMO

(COnstructive QUALity MOdel)


Quando falamos em projeto de desenvolvimento de software, é necessário levarmos

três fatores em consideração: Custo, Prazo e Qualidade. Para Barry Boehm (Boehm, et al.,

2000) esses fatores estão fortemente correlacionados e formam os três lados de um mesmo

triângulo. Não é muito raro encontrarmos projetos de desenvolvimento de software onde o

lema é aumentar o máximo possível a qualidade sem que isso comprometa o custo e o prazo.

Entretanto, existe uma grande dificuldade em projetos de software em alcançar tal meta.

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

acompanhem esse mesmo nível.

Projetos de desenvolvimento de software possuem particularidades intrínsecas e que

envolvem variáveis muitas vezes de difícil controle, como a agilidade de uma pessoa em uma

determinada tecnologia. Contudo, apenas conhecer a tecnologia a ser empregada não garante

a agilidade necessária ao desenvolvimento. Aumentar a equipe também não nos dá a certeza

de que o prazo de entrega do projeto poderá ser reduzido, e na maioria das vezes o que ocorre

é justamente o contrário do que se espera. Podemos comprovar esse fato quando Sunita

Chulani (Chulani, Constructive Quality Modeling for Defect Density Prediction:

COQUALMO, 1999) diz que a redução do prazo de desenvolvimento de um projeto de

software, para concluirmos o projeto em menos tempo, certamente provocará impacto

negativo no custo e principalmente na confiabilidade e qualidade do produto produzido. Por

outro lado, sabemos que o uso de técnicas de estimativas de custo, prazo e qualidade, auxilia

os gestores de projetos de software a tomarem, com maior precisão, decisões que impactem

diretamente e positivamente o sucesso de um projeto.

Conforme estudamos nos capítulos anteriores, técnicas e modelos de estimativas de

custo e prazo para projetos de software foram apresentadas, porém faltava um dos lados do

triângulo, comentado por Barry Boehm (Boehm, et al., 2000), a Qualidade.

Reconhecendo a necessidade de se fechar esse triângulo, Barry Boehm (Boehm, et al.,

2000) propôs um modelo de estimativa de qualidade como sendo uma extensão do modelo

48

COCOMO II, chamado COQUALMO (COnstructive QUALity MOdel). Este modelo foi

criado com a finalidade de auxiliar os gestores de projetos de software a determinarem a

qualidade do produto, baseando-se na densidade de defeitos, que por sua vez acaba sendo um

elemento preditivo natural da qualidade e confiabilidade de um software (Chulani, Steece, &

Boehm, Determining Software Quality Using COQUALMO, 2003).

3.2. Introdução

O modelo COQUALMO é uma extensão do modelo COCOMO II e baseia-se nos

modelos de “Injeção de Defeitos de Software” (DI) e “Remoção de Defeitos de Software”

(DR) descrito por Barry Boehm (Boehm, Software Engineering Economics, 1981). Estes

modelos são análogos ao modelo “tanque e duto (tank and pipe)“ proposto por Capers Jones

(Jones, 1975) e representado através da Figura 3.

De forma conceitual, representa o fluxo de defeitos injetados e removidos em um

“tanque” através de “dutos”. Esses defeitos são introduzidos através desses “dutos” e são

estimados através do modelo de “Injeção de Defeitos de Software” (DI – Defect Introduction

Software) e os defeitos removidos através de técnicas como testes e inspeções, são estimados

através do modelo “Remoção de Defeitos de Software” (DR – Defect Removal Software).

De acordo com Sunita Chulani (Chulani & Boehm, Modeling Software Defect

Introduction and Removal:COQUALMO (COnstructive QUALity MOdel), 1999), três são os

tipos de defeitos injetados durante a execução do projeto de software: Defeitos de Requisitos

(Requirements Defects), Defeitos de Desenho da Arquitetura da Solução (Design Defects) e

Defeitos de Codificação (Code Defects). Os defeitos residuais serão tratados posteriormente

na seção “3.4. Modelo de Remoção de Defeitos de Software (Defect Removal Software)

(DR).”

49

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

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

Os defeitos podem ser injetados em um produto de software através de diversas

formas durante seu ciclo de vida. No modelo COQUALMO esses defeitos são classificados

da seguinte forma:

• Defeitos de Requisitos

• Defeitos de Desenho da Arquitetura da Solução

• Defeitos de Codificação

O COQUALMO é uma extensão do COCOMO II, e por conseqüência o modelo de

injeção de defeitos utiliza como parâmetros de entrada para cálculos preditivos, o tamanho do

software medido em mil Linhas de Código (Kilo Source Line Of Code – kSLOC), e podem

também ser ajustados no caso de reuso. Assim como utiliza kSLOC, este modelo utiliza os

multiplicadores de esforço de 21 dos 22 drivers de custo utilizados nas estimativas do

COCOMO II, divididos em 4 categorias de drivers, conforme referencia a Tabela 17.

50

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

Drivers de Injeção de Defeitos

Post-Architecture Early Design Categoria Sigla Descrição Sigla Descrição

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


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


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



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


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


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


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


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



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



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



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



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



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



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



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



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



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



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



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



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



modelo de estimativa da qualidade em projeto de software baseado na prediÇÃo de defeitos

Documents