FUNDAÇÃO INSTITUTO DE ADMINISTRAÇÃO – FIA      MBA EM GESTÃO DA TECNOLOGIA DE INFORMAÇÃO                          TURMA 14...
DEDICATÓRIADedico este trabalho primeiramente a Deus, pois sem Ele não seria possível atingir essa meta.Aos meus grandes e...
AGRADECIMENTOSAos meus colegas de turma, com quem compartilhei as aulas durante a semana, manhãs desábado, noites no MSN c...
RESUMO        A utilização de modelos e técnicas de estimativas de projetos de software auxilia nabusca contínua por proje...
ABSTRACT        The use of software projects models and techniques estimation assists in thecontinuous search for cohesion...
ÍNDICEÍNDICE DE FIGURAS .....................................................................................................
3.5.      CALIBRAÇÃO DO MODELO ........................................................................................ 62...
ÍNDICE DE FIGURASFIGURA 1 – MODELO DE CONFIGURAÇÃO DE DADOS. (FONTE: FERNANDES (FERNANDES, 1995, P.    117)..................
ÍNDICE DE TABELASTABELA 1 – AMOSTRAGEM DE DEFEITOS ..........................................................................
TABELA 26 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER RELY.   (FONTE: SUNITA CHULANI (CHULANI, RESU...
TABELA 40 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER TOOL.   (FONTE: SUNITA CHULANI (CHULANI, RESU...
ÍNDICE DE GRAFICOSGRÁFICO 1 – DISPERSÃO DOS DEFEITOS DA AMOSTRAGEM ..........................................................
ACRÔNIMOS E ABREVIAÇÕESCOCOMO     Constructive Cost ModelCOQUALMO   Constructive Quality ModelIFPUG      International Fun...
PERS   Personnel CapabilityPREX   Personnel ExperienceFCIL   FacilitiesSCED   Required Development SchedulePREC   Preceden...
15CAPÍTULO 1 – INTRODUÇÃO1.1.   Considerações Iniciais        “Os alertas começaram a mais de uma década antes do evento, ...
16       Aguinaldo Fernandes (Fernandes, 1995) contextualiza a “crise do software” àrealidade brasileira quando cita em no...
17       O processo de evolução de um software e o nível de exigência de quem os usa crescede forma exponencial. Não basta...
18O Capítulo 4 – Aplicação dos Modelos e Técnicas de Estimativas Apresentados – apresentaum exemplo de aplicação integrada...
19CAPÍTULO 2 – MODELOS E TÉCNICAS DE ESTIMATIVAS2.1.   Considerações Iniciais       Citado por Fernandes (Fernandes, 1995)...
20Figura 1 – Modelo de configuração de dados. (Fonte: Fernandes (Fernandes, 1995, p. 117)       Cada técnica exige um conj...
21um modelo de previsão dos valores de Y a partir dos valores de X. Em estatística esse tipo demodelo é chamado de Regress...
22                                             Defeitos(Y)                  500                  450                  400 ...
23       O Gráfico 2 apresenta a dispersão dos defeitos da amostragem da Tabela 2.                                        ...
24valores de “a” e “b”, com a finalidade de satisfazer os critérios dos mínimos quadrados édemonstrado através das equaçõe...
25                                           # Defeitos(Y)                      600                      500              ...
262.3.     Análise por Pontos de Função (APF)         Segundo Carlos Vazquez (Vazquez, Simões, & Machado, 2003) a análise ...
272.3.2.      Determinando o Tipo de Contagem         Nessa fase é determinado o tipo de contagem que será realizada para ...
28         O resultado do cálculo nos dá a estimativa da funcionalidade da aplicação sob o pontode vista do usuário da apl...
29Tabela 3 – Complexidade ALI e AIE. (Fonte: Fernandes (Fernandes, 1995, p. 123)         Registros                        ...
30       Em função da complexidade de cada EE, são atribuídos pesos para os cálculos dospontos por função não-ajustados co...
31         Consulta Externa (CE)               Função que realiza o envio de dados ou informações de controle para fora da...
32       Nesse primeiro cálculo, encontraremos os Pontos por Função Não-Ajustados, ou seja,pontos por função brutos.      ...
33Tabela 11 – Determinação dos PFNA (Pontos por Função Não-Ajustados)                                            Complexid...
34              8. Atualização Online;              9. Processamento Complexo;              10. Reutilização;             ...
35Tabela 12 – Determinação do nível total de influência. (Fonte: Fernandes (Fernandes, 1995, p.126)               Caracter...
36tamanho, produtividade, esforço, prazo e dimensionamento da equipe do projeto. Pararealização desses cálculos são necess...
37que a atividade seja concluída. Prevendo também um adicional de 20% ao tempo calculado,como margem de erro, Pablo López ...
38         Early Design (Pré-projeto)                Este sub-modelo é usado nas fases iniciais do projeto. Nessas fases, ...
39               Onde,               A é uma constante calibrada para o ambiente a ser aplicado o modelo. Deacordo com Pab...
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 ...
41Tabela 14 – Pesos Calibrados dos SFs. (Fonte: Barry Boehm (Boehm, et al., 2000) Fatores   de           Muito            ...
42Pablo López (López, 2005). Para cada um dos sub-modelos apresentados temos um conjuntode multiplicadores de esforço.    ...
43Tabela 16 – Drivers de Custo para o Sub-Modelo Post-Architecture (Fonte: COCOMO IIManual 2000)                          ...
44obteremos o valor do fator de ajuste dos pontos por função calculados, para a linguagemescolhida, e calculamos o tamanho...
45                         B é uma constante calibrada para o ambiente a ser aplicado o modelo.Após a calibração COCOMO II...
462.5.    Considerações Finais       Observamos que uma vez calculado o tamanho do software usando Análise de Pontospor Fu...
47CAPÍTULO 3 – MODELO DE ESTIMATIVA DE QUALIDADE – COQUALMO(COnstructive QUALity MOdel)3.1.   Considerações Iniciais      ...
48COCOMO II, chamado COQUALMO (COnstructive QUALity MOdel). Este modelo foicriado com a finalidade de auxiliar os gestores...
49Figura 3 – Introdução e Remoção de Defeitos de Software. (Fonte: Sunita Chulani (Chulani,Steece, & Boehm, Determining So...
50Tabela 17 – Drivers do Modelo de Injeção de Defeitos de Software Drivers de Injeção de Defeitos                    Post-...
51       A Figura 4 apresenta graficamente a estrutura do modelo de injeção de defeitos.Figura 4 – Modelo de Injeção de De...
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO DE DEFEITOS
Upcoming SlideShare
Loading in …5
×

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

626 views

Published on

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).

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
626
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
27
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1. FUNDAÇÃO INSTITUTO DE ADMINISTRAÇÃO – FIA MBA EM GESTÃO DA TECNOLOGIA DE INFORMAÇÃO TURMA 14MODELO 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
  2. 2. DEDICATÓRIADedico 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 emnenhum momento deixaram de dar um incondicional apoio, carinho, compreensão ecompanheirismo 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 tantocontribuíram para minha formação pessoal e profissional. Sem vocês, realmente nada dissoseria possível ser concretizado. “É na simplicidade das coisas que encontramos a verdadeira felicidade.” Edwagney Luz
  3. 3. AGRADECIMENTOSAos meus colegas de turma, com quem compartilhei as aulas durante a semana, manhãs desábado, noites no MSN compartilhando informações, enfim, deixo meus sincerosagradecimentos pelo companheirismo, amizade, convivência e confiança durante todos essesmeses.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 quempassei a maior parte do meu tempo e que me ensinam a ser um profissional e uma pessoamelhor 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 eupudesse atingir essa meta.Ao professor Aguinaldo Aragon pela ajuda e confiança dispensada, mesmo com o poucotempo 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 umprofissional e ser um profissional ético com valores bem equalizados e definidos, eprincipalmente ensinamentos de como ser um grande ser humano, e pelo apoio e incentivo nodesenvolvimento deste trabalho.A minha amiga Virgínia Elizabeth, pelo incentivo, ajuda na revisão deste trabalho e confiançadispensada, mesmo com o pouco tempo de convivência. Meus sinceros agradecimentos.Enfim, reservo este especial agradecimento à minha diretora Marise De Luca e aos meusgerentes Koki Sakai e Maria Beatriz Kerber por sempre acreditarem em mim e na minhacapacidade profissional na condução dos projetos, e principalmente por me darem aoportunidade 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
  4. 4. RESUMO A utilização de modelos e técnicas de estimativas de projetos de software auxilia nabusca contínua por projetos cada vez mais coesos, que terminem dentro do prazo e orçamentoprevisto. Estimativas de tamanho, esforço e prazo são baseadas em uma vasta quantidade devariáveis que ajudam a atingirmos um valor próximo do real. Entretanto, atualmente asorganizações buscam não apenas melhorar a estimativa de seus projetos em relação atamanho, esforço e prazo. É necessário que o produto apresente qualidade dentro de um nívelaceitável e solicitado pelo cliente. Como estimar essa qualidade? Baseado em quais variáveis conseguiremos estimar aqualidade de um produto? Pesquisas de satisfação junto ao cliente é uma boa saída, porém somente funcionaquando 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, eessa foi uma das finalidades desse estudo. Encontrar um modelo preditivo de qualidade, quepossa 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ãodo modelo COCOMO II (COnstructive COst MOdel), que tem por finalidade estimar aqualidade de um projeto de software baseado na predição de defeitos, usando característicasespecíficas do projeto já levantadas através do modelo COCOMO II, auxiliando gerentes deprojetos a determinar a qualidade do produto baseado na densidade de defeitos que por suavez é um excelente modo de identificar a confiabilidade do produto. Este modelo é oCOQUALMO (COnstructive QUALity MOdel).
  5. 5. ABSTRACT The use of software projects models and techniques estimation assists in thecontinuous search for cohesion projects that finish on time and budget determined. Estimatesof size, effort and time are based on a great amount of variable that helps to reach an almostreal 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 acceptableand requested level for the customer. How to estimates this quality? Which variable we will get used to estimate of theproduct quality? Research of satisfaction with the customer is a good idea, however it will only giveresulted when the project was delivered and the product is in use by customer. To find amodel adjusted, of easy calibration and that has the correct variable, is the challenge of themany companies and this is the one of the reasons of this study. To find a predictive qualitymodel, 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 theCOCOMO II (COnstructive COst MOdel), that is has the purpose to estimate the projectquality of software based on defects prediction, using specific characteristic of the projectthrough the model COCOMO II, helping project managers to determine the quality of theproduct based of the defects density that in turn is early predictor of software reliability. Thismodel is called COQUALMO (COnstructive QUALity MOdel).
  6. 6. ÍNDICEÍNDICE DE FIGURAS ............................................................................................................ 8ÍNDICE DE TABELAS ........................................................................................................... 9ÍNDICE DE GRAFICOS ....................................................................................................... 12ACRÔNIMOS E ABREVIAÇÕES ....................................................................................... 13CAPÍTULO 1 – INTRODUÇÃO .......................................................................................... 15 1.1. CONSIDERAÇÕES INICIAIS......................................................................................... 15 1.2. OBJETIVO .................................................................................................................. 17 1.3. ESTRUTURA ............................................................................................................... 17CAPÍTULO 2 – MODELOS E TÉCNICAS DE ESTIMATIVAS ..................................... 19 2.1. CONSIDERAÇÕES INICIAIS......................................................................................... 19 2.2. REGRESSÃO LINEAR .................................................................................................. 20 2.3. ANÁLISE POR PONTOS DE FUNÇÃO (APF) ................................................................ 26 2.3.1. O Processo de Contagem ................................................................................... 26 2.3.2. Determinando o Tipo de Contagem .................................................................. 27 2.3.3. Definindo a Fronteira da Aplicação e o Escopo da Contagem ....................... 28 2.3.4. Contagem de Função do Tipo DADO ............................................................... 28 2.3.5. Contagem de Função do Tipo TRANSAÇÃO .................................................. 29 2.3.6. Contagem dos Pontos de Função Não-Ajustados (PFNA) .............................. 31 2.3.7. Determinar Fator de Ajuste .............................................................................. 33 2.3.8. Determinar Ponto de Função Ajustado (PFA) ................................................ 35 2.3.9. Considerações Finais ........................................................................................ 35 2.4. COCOMO II (CONSTRUCTIVE COST MODEL II) .................................................... 36 2.4.1. Considerações Iniciais ....................................................................................... 36 2.4.2. Sub-modelos ....................................................................................................... 37 2.4.3. Estimativa de Esforço e Prazo........................................................................... 38 2.4.4. Número Médio da Equipe ................................................................................. 45 2.5. CONSIDERAÇÕES FINAIS ........................................................................................... 46CAPÍTULO 3 – MODELO DE ESTIMATIVA DE QUALIDADE – COQUALMO(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
  7. 7. 3.5. CALIBRAÇÃO DO MODELO ........................................................................................ 62CAPÍTULO 4 – APLICAÇÃO DOS MODELOS E TÉCNICAS DE ESTIMATIVASAPRESENTADOS .................................................................................................................. 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 ............................................................................................ 68CAPÍTULO 5 – CONCLUSÃO E TRABALHOS FUTUROS........................................... 70REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 72ANEXOS ................................................................................................................................. 74
  8. 8. ÍNDICE DE FIGURASFIGURA 1 – MODELO DE CONFIGURAÇÃO DE DADOS. (FONTE: FERNANDES (FERNANDES, 1995, P. 117).................................................................................................................................... 20FIGURA 2 – VISÃO GERAL DO PROCESSO DE CONTAGEM DE PONTOS DE FUNÇÃO. (FONTE: VAZQUEZ (VAZQUEZ, SIMÕES, & MACHADO, 2003, P. 47) ................................................ 26FIGURA 3 – INTRODUÇÃO E REMOÇÃO DE DEFEITOS DE SOFTWARE. (FONTE: SUNITA CHULANI (CHULANI, STEECE, & BOEHM, DETERMINING SOFTWARE QUALITY USING COQUALMO, 2003)) ................................................................................................................................ 49FIGURA 4 – MODELO DE INJEÇÃO DE DEFEITOS DE SOFTWARE. (FONTE: BARRY BOEHM (BOEHM, ET AL., 2000)) ..................................................................................................... 51FIGURA 5 – MODELO DE REMOÇÃO DE DEFEITOS DE SOFTWARE. (FONTE: BARRY BOEHM (BOEHM, ET AL., 2000)) ..................................................................................................... 57
  9. 9. ÍNDICE DE TABELASTABELA 1 – AMOSTRAGEM DE DEFEITOS ................................................................................... 21TABELA 2 – AMOSTRAGEM DE DEFEITOS POR TAMANHO DE SOFTWARE ..................................... 22TABELA 3 – COMPLEXIDADE ALI E AIE. (FONTE: FERNANDES (FERNANDES, 1995, P. 123) ..... 29TABELA 4 – RELAÇÃO DOS PESOS DE ALI E AIE PARA DETERMINAÇÃO DOS PF NÃO-AJUSTADOS. (FONTE: FERNANDES (FERNANDES, 1995, P. 125) .............................................................. 29TABELA 5 – COMPLEXIDADE DE EE. (FONTE: FERNANDES (FERNANDES, 1995, P. 123) ............ 29TABELA 6 – RELAÇÃO DOS PESOS DE EE PARA DETERMINAÇÃO DOS PF NÃO-AJUSTADOS. (FONTE: FERNANDES (FERNANDES, 1995, P. 125) .............................................................. 30TABELA 7 – COMPLEXIDADE DE SE. (FONTE: FERNANDES (FERNANDES, 1995, P. 123) ............ 30TABELA 8 – RELAÇÃO DOS PESOS DE SE PARA DETERMINAÇÃO DOS PF NÃO-AJUSTADOS. (FONTE: FERNANDES (FERNANDES, 1995, P. 125) .............................................................. 30TABELA 9 – COMPLEXIDADE DE CE. (FONTE: FERNANDES (FERNANDES, 1995, P. 123) ............ 31TABELA 10 – RELAÇÃO DOS PESOS DE CE PARA DETERMINAÇÃO DOS PF NÃO-AJUSTADOS. (FONTE: FERNANDES (FERNANDES, 1995, P. 125) .............................................................. 31TABELA 11 – DETERMINAÇÃO DOS PFNA (PONTOS POR FUNÇÃO NÃO-AJUSTADOS) ............... 33TABELA 12 – DETERMINAÇÃO DO NÍVEL TOTAL DE INFLUÊNCIA. (FONTE: FERNANDES (FERNANDES, 1995, P. 126) ................................................................................................ 35TABELA 13 – CONVERSÃO DE PFNA PARA SLOC. (FONTE: BARRY BOEHM (BOEHM, ET AL., 2000)) ................................................................................................................................ 39TABELA 14 – PESOS CALIBRADOS DOS SFS. (FONTE: BARRY BOEHM (BOEHM, ET AL., 2000).. 41TABELA 15 – DRIVERS DE CUSTO PARA O SUB-MODELO EARLY DESIGN (FONTE: COCOMO II MANUAL 2000) .................................................................................................................. 42TABELA 16 – DRIVERS DE CUSTO PARA O SUB-MODELO POST-ARCHITECTURE (FONTE: COCOMO II MANUAL 2000) ............................................................................................ 43TABELA 17 – DRIVERS DO MODELO DE INJEÇÃO DE DEFEITOS DE SOFTWARE .......................... 50TABELA 18 – PCAP CAPACIDADE DO PROGRAMADOR – ESCALA DE TAXAS DA INJEÇÃO DE DEFEITOS. (FONTE: BARRY BOEHM (BOEHM, ET AL., 2000)) ............................................. 55TABELA 19 – CLASSIFICAÇÃO DOS TIPOS DE REMOÇÃO DE DEFEITOS. (FONTE: BARRY BOEHM (BOEHM, ET AL., 2000)) ..................................................................................................... 60TABELA 20 – DENSIDADE DE DEFEITOS RESIDUAIS DOS VALORES DAS FRAÇÕES DE REMOÇÃO DE DEFEITOS. (FONTE: BARRY BOEHM (BOEHM, ET AL., 2000)) ........................................ 61TABELA 21 – CARACTERÍSTICAS DO PROJETO, MULTIPLICADORES DE ESFORÇO E INJEÇÃO DE DEFEITOS ........................................................................................................................... 64TABELA 22 – CLASSIFICAÇÃO DOS TIPOS DE REMOÇÃO DE DEFEITOS NO PROJETO..................... 64TABELA 23 – DENSIDADE RESIDUAL DE DEFEITOS ..................................................................... 69TABELA 24 – VALORES DOS EM PARA O SUB-MODELO EARLY DESIGN (FONTE: COCOMO II MANUAL 2000 (USC, 2000)) ............................................................................................. 74TABELA 25 – VALORES DOS EM PARA O SUB-MODELO POST-ARCHITECTURE (FONTE: COCOMO II MANUAL 2000 (USC, 2000)) ....................................................................... 74
  10. 10. 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)) ................................................................................. 75TABELA 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)) ................................................................................. 75TABELA 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)) ................................................................................. 75TABELA 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)) ................................................................................. 76TABELA 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)) ................................................................................. 76TABELA 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)) ................................................................................. 76TABELA 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)) ................................................................................. 77TABELA 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)) ................................................................................. 77TABELA 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)) ................................................................................. 77TABELA 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)) ................................................................................. 78TABELA 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)) ................................................................................. 78TABELA 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)) ................................................................................. 78TABELA 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)) ................................................................................. 79TABELA 39 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER LTEX. (FONTE: SUNITA CHULANI (CHULANI, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997)) ................................................................................. 79
  11. 11. 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)) ................................................................................. 79TABELA 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)) ................................................................................. 80TABELA 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)) ................................................................................. 80TABELA 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)) ................................................................................. 80TABELA 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)) ................................................................................. 81TABELA 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)) ................................................................................. 81TABELA 46 – ÍNDICES DOS MULTIPLICADORES DE INJEÇÃO DE DEFEITOS PARA O DRIVER PMAT. (FONTE: SUNITA CHULANI (CHULANI, RESULTS OF DELPHI FOR THE DEFECT INTRODUCTION MODEL, 1997)) ................................................................................. 81
  12. 12. ÍNDICE DE GRAFICOSGRÁFICO 1 – DISPERSÃO DOS DEFEITOS DA AMOSTRAGEM ........................................................ 22GRÁFICO 2 - DISPERSÃO DOS DEFEITOS DA AMOSTRAGEM POR TAMANHO DE SOFTWARE .......... 23GRÁFICO 3 – EQUAÇÃO DE AJUSTE AOS PONTOS DA RETA ......................................................... 25GRÁ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
  13. 13. ACRÔNIMOS E ABREVIAÇÕESCOCOMO Constructive Cost ModelCOQUALMO Constructive Quality ModelIFPUG International Function Point Users GroupAPF Análise por Pontos de FunçãoCPM Counting Practices ManualFPNA Pontos de Função Não-AjustadosPFA Pontos de Função AjustadosCOTS Commercial-Off_The_ShelfkSLOC Kilo Source Lines Of CodeSLOC Source Lines Of CodeDI Defect Introduction SoftwareDR Defect Removal SoftwareQAF Quality Adjustment FactorDIR Defect Introduction RateDRR Defect Removal RateDRF Defect Removal FractionPM Person-MonthsTDEV Time to DevelopmentSF Scale FactorEM Effort MultiplicationRELY Required Software ReliabilityDATA Data Base SizeCPLX Product ComplexityRUSE Developed for ReusabilityDOCU Documentation Match to Life-Cycle NeedsTIME Execution Time ConstraintSTOR Main Storage ConstraintPVOL Platform VolatilityACAP Analyst CapabilityPCAP Programmer CapabilityPCON Personnel ContinuityAPEX Applications ExperiencePLEX Platform ExperienceLTEX Language and Tool ExperienceTOOL Use of Software ToolsSITE Multisite DevelopmentSCED Required Development ScheduleRCPX Product Reliability and ComplexityRUSE Developed for ReusabilityPDIF Platform Difficulty
  14. 14. PERS Personnel CapabilityPREX Personnel ExperienceFCIL FacilitiesSCED Required Development SchedulePREC PrecedentednessFLEX Development FlexibilityRESL Architecture/Risk ResolutionTEAM Team CohesionPMAT Process Maturity
  15. 15. 15CAPÍTULO 1 – INTRODUÇÃO1.1. Considerações Iniciais “Os alertas começaram a mais de uma década antes do evento, mas ninguém prestoumuita atenção. Há menos de dois anos da data, os meios de comunicação publicaram ahistória. Depois, representantes do governo manifestaram sua preocupação, liderançasempresariais empenharam vastos recursos financeiros e, finalmente, sérios alertas decatástrofes iminentes penetraram a consciência do público. O Software, por causa agora doinfame erro do milênio, iria falhar e como resultado pararia o mundo, tal como então oconhecemos.” 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 deprojetos de software era tratado anos atrás. Observando mais a fundo, não será difícilpercebermos que não era um problema meramente técnico, mas sim gerencial, deplanejamento. Alguns anos antes de tomar-se conhecido e consequentemente divulgação do maiorerro da história do software, o chamado “bug do milênio”, discutia-se a crise do software. Oaumento da demanda por software provocava o conseqüente aumento da complexidade dosproblemas a serem resolvidos e aliado à falta de técnicas e métodos para desenvolvimento fezcom que ao final dos anos 60 e início dos anos 70, esse termo fosse usado em umaconferê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ústriado software, levou muitos a questionarem o termo crise de software. Isso pelo fato dessaindú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 quegrande parte desse sucesso vem do uso contínuo dos modelos, métodos e ferramentasdisponíveis para a melhoria de um projeto de desenvolvimento de software, o que comprovaque o uso de métodos e ferramentas aumenta consideravelmente a capacidade de se produzirsoftwares que, cada vez mais se enquadrem quantitativamente no prazo e orçamentoprevistos.
  16. 16. 16 Aguinaldo Fernandes (Fernandes, 1995) contextualiza a “crise do software” àrealidade brasileira quando cita em no prefácio de seu livro, que “a crise é eminentementegerencial, com raízes culturais, caracteristicamente brasileiras, onde o pragmatismo e ocomportamento imediatista não têm atingido os objetivos pretendidos.” Diante disso, mesmo tendo uma grande quantidade de sucessos na indústria desoftware, concluímos que ainda estamos no interior da chamada crise. Não é difícilobservarmos cada vez mais projetos ultrapassando o prazo e orçamento previstos, pouca ounenhuma qualidade inerente ao processo e/ou produto, ingerência nos projetos, dificuldade demanutençã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 umprojeto, transcende as responsabilidades do gerente do projeto de software, pois sem opatrocínio para a realização das mudanças necessárias, muito provavelmente a implantação deum 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 precisamosconsiderar para melhorar a atual situação da produção de software explanado no parágrafoanterior. É nesse cenário que se propõe o uso de modelos para medição de projetos desoftware, os quais possuem o objetivo de nos auxiliar na definição e coleta de métricas quecompõe uma base de informações de projetos de software, que nos permite responder algumasquestõ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á onível de qualidade possível na entregar o produto de um determinado projeto dedesenvolvimento de software? A resposta à última pergunta, no entanto, traduz o principal objetivo quandorealizamos 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 deforma qualitativa.
  17. 17. 17 O processo de evolução de um software e o nível de exigência de quem os usa crescede forma exponencial. Não basta mais entregarmos um produto no prazo e dentro doorçamento planejado, mas também entregá-lo em um nível de qualidade que supera asexpectativas.1.2. Objetivo Este trabalho tem por objetivo estudar e apresentar um modelo para medição deprojeto de software para estimar qualitativamente um projeto de desenvolvimento desoftware. O modelo a ser apresentado baseia-se na predição de defeitos inerentes ao processo dedesenvolvimento e foi inicialmente proposto por Sunita Chulani e Berry Boehm (Chulani &Boehm, Modeling Software Defect Introduction and Removal: COQUALMO (COnstructiveQUALity 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 destetrabalho, 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 maisconhecidas de estimativas de projetos de softwares. A identificação dos modelos para usoneste trabalho foi baseado na aplicação das melhores práticas em termos de estimativa deprojetos de software.O Capítulo 3 – Modelo de Estimativa de Qualidade COQUALMO (COnstructive QUALityMOdel) - apresenta detalhadamente o modelo de estimativa de qualidade COQUALMO, bemcomo o descritivo do passos a ser seguido para se medir qualitativamente o projeto utilizandoeste modelo, e os pontos onde esse tipo de estimativa pode auxiliar um projeto de software aatingir um melhor nível de qualidade.
  18. 18. 18O Capítulo 4 – Aplicação dos Modelos e Técnicas de Estimativas Apresentados – apresentaum exemplo de aplicação integrada dos modelos apresentados neste trabalho, considerandopara 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 arealização deste trabalho e uma breve proposta de trabalhos futuros como extensão desteestudo.
  19. 19. 19CAPÍTULO 2 – MODELOS E TÉCNICAS DE ESTIMATIVAS2.1. Considerações Iniciais Citado por Fernandes (Fernandes, 1995) e de acordo com Norman Fenton (Fenton,1991), os principais modelos de predição de projetos de softwares são desenvolvidos apósanálises de um conjunto de dados e amostras específicas, onde certamente incluem parâmetrosdifíceis de serem determinados no início de um projeto. Dessa forma, teremos a necessidadede calibração desses modelos de forma a adequá-los à realidade da organização e do ambienteno qual o modelo de estimativa será aplicado. A coleta dessas informações não é trivial, pois exige esforço e disciplina para que searmazene de cada projeto uma base histórica de informações desses projetos. Considerandoessa base histórica de dados, coletam-se as informações necessárias para se alimentar osparâ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 osresultados dela obtidos terão um maior nível de exatidão. Esse raciocínio é apresentado na Figura 1.
  20. 20. 20Figura 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 seescolher 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 deestimativas de projetos de software. Essas técnicas e modelos foram escolhidos baseados emmelhores 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 projetode desenvolvimento de software, precisaremos tomar conhecimento de algumas técnicas deestimativas de tamanho, esforço e prazo. Esse conhecimento é necessário para melhorentendermos 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 preditivaque envolve duas variáveis, uma dependente(Y) e outra independente(X). É uma análiserealizada a partir de uma correlação linear entre essas duas variáveis, buscando estabelecer
  21. 21. 21um modelo de previsão dos valores de Y a partir dos valores de X. Em estatística esse tipo demodelo é 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 serencontrado 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 aconsiderar, 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. 22. 22 Defeitos(Y) 500 450 400 350 # Defeitos 300 250 200 Defeitos(Y) 150 100 50 0 0 1 2 3 4 5 6 7 8 CicloGrá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 medidoem pontos de função – no contexto do cenário em questão, conforme Tabela 2.Tabela 2 – Amostragem de defeitos por tamanho de software Tamanho do Software em Ciclo Defeitos (Y) Pontos de Função (X) 1 50 8 2 100 48 3 200 159 4 400 218 5 800 294 6 1600 308 7 3200 455 Média 907,14 212,86
  23. 23. 23 O Gráfico 2 apresenta a dispersão dos defeitos da amostragem da Tabela 2. # Defeitos(Y) 500 450 400 350 # Defeitos 300 250 200 150 # Defeitos(Y) 100 50 0 0 500 1000 1500 2000 2500 3000 3500 Tamanho do Software (X)Gráfico 2 - Dispersão dos defeitos da amostragem por tamanho de Software Usando o método dos mínimos quadrados, podemos facilmente chegar à equação dareta que melhor se ajusta ao conjunto dos dados amostrais fornecidos. Esta equação tem sua forma geral, para dados de uma amostra, conforme apresentadopela 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 davariá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 tentase ajustar. Sabendo que a relação entre X e Y é linear, as equações usadas para cálculo dos
  24. 24. 24valores 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 pontosde 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 seguintesvalores 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 daequação Eq2.2.5.
  25. 25. 25 # Defeitos(Y) 600 500 400 # Defeitos 300 # Defeitos(Y) 200 Linear (# Defeitos(Y)) 100 0 0 1000 2000 3000 4000 Tamanho do Software (X)Gráfico 3 – Equação de ajuste aos pontos da reta Com a equação da reta ajustada, podemos estimar a quantidade de defeitos a seremencontrados em um novo ciclo. Suponhamos que temos um novo ciclo onde a estimativacalculada 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=6400e 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 serencontrados em um software, porém é um número cheio que leva-nos a considerar que sãodefeitos produzidos na codificação apenas, o que não é verdade. Sunita Chulani (Chulani &Boehm, Modeling Software Defect Introduction and Removal: COQUALMO (COnstructiveQUALity MOdel), 1999), em seu estudo, afirma que defeitos são introduzidos em um projetode desenvolvimento de software, tanto nas fases de elaboração de requisitos, quanto nodesenho da arquitetura da solução e na codificação. Portanto, o número de defeitos calculadousando Regressão Linear nos mostra apenas uma quantidade, porém não especifica em qualponto do projeto esses defeitos aparecerão.
  26. 26. 262.3. Análise por Pontos de Função (APF) Segundo Carlos Vazquez (Vazquez, Simões, & Machado, 2003) a análise por pontosde função é atualmente um instrumento utilizado por profissionais da área de sistemas e emempresas de todos os portes e segmentos da economia brasileira. E ainda continua sendo umaimportante ferramenta de estimativas, utilizada com cada vez mais sucesso, como unidade demedição de contratos de desenvolvimento de software e como ferramenta da gestão deprojetos. Essa técnica teve início nos anos 70, na IBM através de Allan Albrecht que foiincumbido de medir a produtividade de vários projetos de software em desenvolvimento pelaIBM. O intuito proposto para o desenvolvimento dessa nova técnica, foi o de criar umaalternativa às métricas baseadas em linhas de código e também algo que pudesse ser usadopara estimar o tamanho de um software que fosse independente da linguagem de programaçãoutilizada. 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 oprimeiro 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 doprocesso 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. 27. 272.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 seuciclo de vida. A contagem pode ser associada tanto a aplicações implementadas quanto emprojetos de desenvolvimento, e até mesmo durante procedimentos de manutenção seja elaevolutiva, 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 porobjetivo estimar o tamanho do projeto para uma nova aplicação, quantificando funçõessolicitadas pelo usuário e podendo abranger eventuais funções de conversão de dados quepossam 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 objetivoestimar o tamanho de funções adicionais, modificações ou exclusões de funções inseridas emuma aplicação previamente instalada, quantificando as melhorias solicitadas pelo usuário epodendo 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 dessaclassificação, havendo conclusão do projeto de melhoria, o número de pontos por função daaplicaçã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 realtamanho dessa aplicação, também chamado número de pontos por função instalados oubaseline, Carlos Vazquez (Vazquez, Simões, & Machado, 2003).
  28. 28. 28 O resultado do cálculo nos dá a estimativa da funcionalidade da aplicação sob o pontode vista do usuário da aplicação e é realizado ao final da contagem dos pontos de um projetode 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 deuma aplicação é a interface conceitual que delimita o software que será medido e o mundoexterior (seus usuários). Em outras palavras é o limite entre a aplicação e o usuário destaaplicaçã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 dacontagem, 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árioatravés de dados internos e externos, atendendo às necessidades de dados, que possuem aseguinte classificação: Arquivo Lógico Interno (ALI) Grupo de dados relacionados logicamente, dentro do limite da fronteira daaplicação. Arquivo de Interface Externa (AIE) Grupo de dados relacionados logicamente, fora do limite da fronteira daaplicação. Cada ALI e AIE possui uma complexidade determinada a partir da quantidade do Tipode Elemento de Registro (TER) e do Tipo de Elemento de Dado (TED), conforme relaçãoapresentada na Tabela 3.
  29. 29. 29Tabela 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álculosdos 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 52.3.5. Contagem de Função do Tipo TRANSAÇÃO Esse tipo de função representa as funcionalidades de processamento de dadosfornecidas 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 controleoriundas de fora da fronteira da aplicação. Cada EE possui uma complexidade determinada a partir da quantidade do Tipo deArquivo 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. 30. 30 Em função da complexidade de cada EE, são atribuídos pesos para os cálculos dospontos 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 osenvia para fora da fronteira da aplicação. O processamento dessa saída deve conter algum tipode cálculo, como por exemplo, a criação de dados novos derivados de dados ou informaçõesexistentes. Cada SE possui uma complexidade determinada a partir da quantidade do Tipo deArquivo Referenciado (TAR) e do Tipo de Elemento de Dados (TED), conforme Tabela 7.Tabela 7 – Complexidade de SE. (Fonte: Fernandes (Fernandes, 1995, p. 123) Arquivos Dados 1 a 5 TED 6 a 19 TED 20 ou mais TED 0 a 1 TAR Baixa Baixa Média 2 a 3 TAR Baixa Média Alta 4 ou mais TAR Média Alta Alta Em função da complexidade de cada SE, são atribuídos pesos para os cálculos dospontos por função não-ajustados conforme Tabela 8.Tabela 8 – Relação dos pesos de SE para determinação dos PF não-ajustados. (Fonte:Fernandes (Fernandes, 1995, p. 125) Complexidade Funcional Peso atribuído para SE Alta 7 Média 5 Baixa 4
  31. 31. 31 Consulta Externa (CE) Função que realiza o envio de dados ou informações de controle para fora dafronteira 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 damaior complexidade entre as partes de entrada e saída identificadas separadamente, e segundopela quantidade do Tipo de Arquivo Referenciado (TAR) e do Tipo de Elemento de Dados(TED), juntamente com conforme Tabela 9.Tabela 9 – Complexidade de CE. (Fonte: Fernandes (Fernandes, 1995, p. 123) Arquivos Dados Entradas 1 a 4 TED 5 a 15 TED 16 ou mais TED 0 a 1 TAR Baixa Baixa Média 2 a 3 TAR Baixa Média Alta 4 ou mais TAR Média Alta Alta Saídas 1 a 5 TED 6 a 19 TED 20 ou mais TED 0 a 1 TAR Baixa Baixa Média 2 a 3 TAR Baixa Baixa Alta 4 ou mais TAR Média Alta Alta Em função da complexidade de cada CE, são atribuídos pesos para os cálculos dospontos por função não-ajustados conforme Tabela 10.Tabela 10 – Relação dos pesos de CE para determinação dos PF não-ajustados. (Fonte:Fernandes (Fernandes, 1995, p. 125) Complexidade Funcional Peso atribuído para CE Alta 6 Média 4 Baixa 32.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 identificadasconforme sua complexidade funcional, e atribuem pesos para cálculos dos pontos por função.
  32. 32. 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çõese multiplicar a quantidade de cada grupo de funções, pelos pesos correspondentes a cadacomplexidade funcional, conforme Tabela 11.
  33. 33. 33Tabela 11 – Determinação dos PFNA (Pontos por Função Não-Ajustados) Complexidade Peso Total por Função Qtde Funcional Atribuído Função Alta 2 x 15 30 Arquivo Lógico Interno (ALI) Média 2 x 10 20 Baixa 2 x7 14 Total de Pontos de Função para Arquivos Lógicos Internos (ALI) 64 Alta 3 x 10 30 Arquivo de Interface Externo (AIE) Média 1 x7 7 Baixa 1 x5 5 Total de Pontos de Função para Arquivos de Interfaces Externos (AIE) 42 Alta 0 x6 0 Entrada Externa (EE) Média 0 x4 0 Baixa 1 x3 3 Total de Pontos de Função para Entradas Externas (EE) 3 Alta 0 x7 0 Saída Externa (SE) Média 1 x5 5 Baixa 1 x4 4 Total de Pontos de Função para Saídas Externas (SE) 9 Alta 2 x6 12 Consulta Externa (CE) Média 4 x5 20 Baixa 2 x3 6 Total de Pontos de Função para Consultas Externas (CE) 38 Total de Pontos de Função Não-Ajustados 1562.3.7. Determinar Fator de Ajuste Para calcularmos o fator de ajuste, é necessário levarmos em consideração 14caracterí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. 34. 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ênciaconforme 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 naTabela 12.
  35. 35. 35Tabela 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 oFator de Ajuste (FA) considerando o Nível de Influência Total calculado com os valores dereferência da Tabela 12. 0,65 + (0,01 x 40) = 1,052.3.8. Determinar Ponto de Função Ajustado (PFA) Considerando o Fator de Ajuste calculado, podemos chegar ao número de pontos porfunçã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 amplamenteutilizada em projetos de desenvolvimento de software como ferramenta para cálculo do
  36. 36. 36tamanho, produtividade, esforço, prazo e dimensionamento da equipe do projeto. Pararealização desses cálculos são necessárias outras análises, que esse estudo não tem porobjetivo apresentar. A característica da técnica de análise por pontos de função nos permite medir osrequisitos do usuário, sem nos preocuparmos com a tecnologia a ser empregada nodesenvolvimento. Ela unifica o padrão de medida, amplamente utilizada no meio técnico, epode ser utilizada desde o início do ciclo de vida. No entanto, a indústria do software busca insistentemente algo que a ajude a mensurara qualidade dos requisitos, do desenho da arquitetura da solução e do código escrito para aaplicação, e através da análise por pontos de função, conseguiremos chegar perto desseobjetivo, 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 desoftware. Porém, para chegar a tal conclusão, antes, é necessário ter como premissa adimensã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á utilizadaem todas as menções relativas ao tamanho do software neste estudo. O modelo COCOMO II teve como precursor o modelo COCOMO, conhecido tambémcomo COCOMO 81, Barry Boehm (Boehm, et al., 2000). A idade dos projetos utilizadoscomo base para a construção deste modelo, aliado à baixa capacidade de lidar com ciclos devida interativos e a utilização de componentes Commercial-Off-The-Shelf (COTS), fez comque 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 arealização de um projeto de desenvolvimento de software, baseando-se no número depessoa/mês e meses, respectivamente, determinando a baseline de exigências do produto para
  37. 37. 37que 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 demodelos de estimativas, é difícil encontrarmos e desenvolver um modelo estável que atenda atodas 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çõescoletadas 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 Designe Post-Architecture, Barry Boehm (Boehm, et al., 2000).
  38. 38. 38 Early Design (Pré-projeto) Este sub-modelo é usado nas fases iniciais do projeto. Nessas fases, asinformações disponíveis sobre requisitos, escopo e arquitetura ainda são relativamenteescassas, incompletas e sem um nível de qualidade adequado, e em conseqüência não nosfornece 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-seter uma idéia de quão grande o projeto poderá vir a ser. André Trindade (Trindade, Pessôa, & Spinola, 1999), chamou este sub-modelo dePré-Projeto. Post-Architecture (Pós-arquitetura) Este sub-modelo é usado em fases mais avançadas do projeto. Nessas fases, asinformações disponíveis sobre requisitos, escopo e arquitetura, atingiram um nível adequadode maturidade e qualidade de informações, e em conseqüência é capaz de fornecer umaestimativa 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 dePó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 ummês. O COCOMO II considera um mês de trabalho equivalente a 152 horas, excluindoferiados e finais de semana, porém esse valor pode ser alterado conforme desejado peloprojeto, 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. 39. 39 Onde, A é uma constante calibrada para o ambiente a ser aplicado o modelo. Deacordo com Pablo López (López, 2005), este é o valor que determina o percentual dereutilização de código. Após a calibração COCOMO II.2000 feita a partir do histórico de 161projetos foi atribuído a variável valor A=2,94; Size é o tamanho do projeto calculado em Linhas de Código SLOC (SourceLine Of Code) ou Pontos por Função Não-ajustados (PFNA). No caso de se usar os pontos porfunção não-ajustados, será necessário usar a Tabela 13 de conversão de pontos de função emSLOC e posteriormente dividir o resultante por mil, pois a unidade Size é dada em kSLOC;Tabela 13 – Conversão de PFNA para SLOC. (Fonte: Barry Boehm (Boehm, et al., 2000)) SLOC / SLOC / Linguagem Linguagem PFNA PFNA Access 38 Jovial 107 Ada 83 71 Lisp 64 Ada 95 49 Machine Code 640 AI Shell 49 Modula 2 80 APL 32 Pascal 91 Assembly - Basic 320 PERL 27 Assembly - Macro 213 PowerBuilder 16 Basic - ANSI 64 Prolog 64 Basic - Compiled 91 Query – Default 13 Basic - Visual 32 Report Generator 80 C 128 Second Generation Language 107 C++ 55 Simulation – Default 46 Cobol (ANSI 85) 91 Spreadsheet 6 Database – Default 40 Third Generation Language 80 Fifth Generation Language 4 Unix Shell Scripts 107 First Generation Language 320 USR_1 1 Forth 64 USR_2 1 Fortran 77 107 USR_3 1 Fortran 95 71 USR_4 1 Fourth Generation Language 20 USR_5 1 High Level Language 64 Visual Basic 5.0 29 HTML 3.0 15 Visual C++ 34 Java 53
  40. 40. 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 avariável valor B=0.91; J variável com valores na faixa de 1 a 5, que representam os 5 Fatoresde 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 de161 projetos, a Tabela 14 referencia os pesos correspondentes aos SF’s.
  41. 41. 41Tabela 14 – Pesos Calibrados dos SFs. (Fonte: Barry Boehm (Boehm, et al., 2000) Fatores de Muito Extra Alto Baixo Nominal Alto Muito Alto Escala baixo (SF) PREC Extremamente Praticamente Quase sem Pouco Familiar Muito Familiar Extremamente sem sem Precedentes Familiar Precedentes Precedentes SFj 6.20 4.96 3.72 2.48 1.24 0.00 FLEX Rigoroso Relaxamentos Relaxamentos Conformidade Alguma Alta Ocasionais Periódicos Geral Conformidade Objetividade SFj 5.07 4.05 3.04 2.03 1.01 0.00 RESL Pouco Algum Frequente Geralmente Na maioria das Completamente (20%) (40%) (60%) (75%) vezes (100%) (90%) SFj 7.07 5.65 4.24 2.83 1.41 0.00 TEAM Alta Alguma Baixa Cooperatividade Cooperatividade Iteração Dificuldade Dificuldade Dificuldade Alta Muito Alta Completa nas Iterações nas Iterações nas Iterações SFj 5.48 4.38 3.29 2.19 1.10 0.00 PMAT SW-CMM SW-CMM SW-CMM SW-CMM SW-CMM SW-CMM Nivel 1 Nível 1 Nível 2 Nível 3 Nível 4 Nível 5 Baixo Alto SFj 7.80 6.24 4.68 3.12 1.56 0.00 Os valores encontrados para o expoente E, devem ser analisadosda 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 emequilíbrio; E > 1.0, indica que o projeto apresenta gastos de escala. EM, são os multiplicadores de esforço (Effort Multipliers - EM). Dentro domodelo COCOMO II, contamos com os drivers de custo, que são usados para a captura decaracterísticas do desenvolvimento que de alguma forma afetam o esforço para completar oprojeto. Esses drivers possuem medidas que expressam o impacto dos mesmos nodesenvolvimento. Para quantificar essa medida, são atribuídos pesos a cada driver de custoassociado. A este peso damos o nome de Multiplicadores de Esforço EM(Effort Multipliers),
  42. 42. 42Pablo López (López, 2005). Para cada um dos sub-modelos apresentados temos um conjuntode multiplicadores de esforço. A Tabela 15 apresenta os 7 drivers de custo referentes ao sub-modelo EarlyDesign.Tabela 15 – Drivers de Custo para o Sub-Modelo Early Design (Fonte: COCOMO II Manual2000) 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 Multiplicadoresde 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. 43. 43Tabela 16 – Drivers de Custo para o Sub-Modelo Post-Architecture (Fonte: COCOMO IIManual 2000) Sub-Modelo Post-Architectute Drivers de Custo Fator Sigla Descrição Confiabilidade Requerida do Software (Required Software RELY Reliability) DATA Tamanho da Base de Dados (Data Base Size) Produto CPLX Complexidade do Produto (Product Complexity) RUSE Reutilização (Developed for Reusability) Documentação Associada às Necessidades do Ciclo de Vida DOCU (Documentation Match to Life-Cycle Needs) TIME Restrição do Tempo de Execução (Execution Time Constraint) Plataforma STOR Restrição de Armazenamento Principal (Main Storage Constraint) PVOL Volatilidade da Plataforma (Platform Volatility) ACAP Habilidade do Analista (Analyst Capability) PCAP Habilidade do Programador (Programmer Capability) PCON Continuidade do Pessoal (Personnel Continuity) Pessoal APEX Experiência nas Aplicações (Applications Experience) PLEX Experiência nas Plataformas (Platform Experience) Experiência nas Ferramentas e Linguagens (Language and Tool LTEX Experience) TOOL Uso de Ferramentas de Software (Use of Software Tools) SITE Desenvolvimento em Múltiplos Locais (Multisite Development) Projeto Cronograma de Desenvolvimento Requerido (Required SCED Development Schedule) Em Anexos, a Tabela 25 apresenta os valores dos Multiplicadores de Esforçopara 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çousando 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 oprojeto será desenvolvido utilizando a linguagem Visual Basic. Consultando a Tabela 13,
  44. 44. 44obteremos o valor do fator de ajuste dos pontos por função calculados, para a linguagemescolhida, e calculamos o tamanho do projeto, conforme segue. Size = PFNA x 32 = 156 x 32 = 4992 (dividindo esse valor por mil, temosaproximadamente 5 kSLOC) Size = 5 kSLOC Consideraremos agora que este é um projeto de nível médio, com todos osmultiplicadores de esforços apresentando valores nominais (1.00). Utilizaremos também ovalor de E = 1. Nesse caso estamos considerando que o projeto está em equilíbrio em relaçãoaos 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êsCálculo do Prazo Calculado o esforço para o desenvolvimento do projeto, mostraremos a seguir ocálculo para estimarmos o prazo de desenvolvimento TDEV (Time To Development). Estecálculo se dá através da equação Eq.2.4.3.3. TDEV = C x (PM)(D + 0.2 x (E – B)) Eq. 2.4.3.3 Onde, C é uma constante calibrada para o ambiente a ser aplicado o modelo.Após a calibração COCOMO II.2000 feita a partir do histórico de 161 projetos foi atribuído avariável valor C=3.67; D é uma constante calibrada para o ambiente a ser aplicado o modelo.Após a calibração COCOMO II.2000 feita a partir do histórico de 161 projetos foi atribuído avariá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 doesforço onde consideramos o somatório dos Fatores de Escala;
  45. 45. 45 B é uma constante calibrada para o ambiente a ser aplicado o modelo.Após a calibração COCOMO II.2000 feita a partir do histórico de 161 projetos foi atribuído avariável valor B=0.91; Aplicando-se os valores obtidos no cálculo do esforço e os valores calibrados peloCOCOMO 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 meses2.4.4. Número Médio da Equipe De posse dos valores de Esforço e Prazo, facilmente podemos calcular o númeromédio da equipe, representado pela letra (P). Obteremos esse resultado dividindo o Esforçopelo Prazo. O COCOMO II considera, para fins de cálculo de número médio da equipe, 152horas para um mês de trabalho, excluindo feriados e finais de semana. Entretanto, esse valorpode 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çãoEq.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 desoftware, usando a tecnologia Visual Basic, tendo como 5 mil Linhas de Código, valoresmédios em relação a multiplicadores de esforço, teremos seu desenvolvimento realizado emum prazo estimado de 8.22 meses considerando uma equipe de 2 pessoas trabalhando 152horas por mês.
  46. 46. 462.5. Considerações Finais Observamos que uma vez calculado o tamanho do software usando Análise de Pontospor Função, o modelo COCOMO II complementa a estimativa em termos de esforço e prazopara 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 esteprojeto terá. Observando apenas os valores encontrados através dos modelos vistos até agora, pormelhor e real que seja essa estimativa, dificilmente nos dará uma previsão do nível dequalidade na qual o produto final será entregue. Podemos conseguir estimar algo em termos de qualidade do produto final, porémteremos apenas uma noção, pois as informações que serão utilizadas nessa previsão, serãoinformações estimadas no passado em outros projetos semelhantes, e que certamente nãocondiz com 100% das características do projeto atual. Diante disso, como então estimar aqualidade do produto a ser entregue? No Capítulo 3, estudaremos um modelo preditivo de qualidade baseado na injeção eremoção de defeitos. A proposta desse modelo é nos dar uma forma, baseado em baseshistó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. 47. 47CAPÍTULO 3 – MODELO DE ESTIMATIVA DE QUALIDADE – COQUALMO(COnstructive QUALity MOdel)3.1. Considerações Iniciais Quando falamos em projeto de desenvolvimento de software, é necessário levarmostrê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 mesmotriângulo. Não é muito raro encontrarmos projetos de desenvolvimento de software onde olema é 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 prazoacompanhem esse mesmo nível. Projetos de desenvolvimento de software possuem particularidades intrínsecas e queenvolvem variáveis muitas vezes de difícil controle, como a agilidade de uma pessoa em umadeterminada tecnologia. Contudo, apenas conhecer a tecnologia a ser empregada não garantea agilidade necessária ao desenvolvimento. Aumentar a equipe também não nos dá a certezade 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 SunitaChulani (Chulani, Constructive Quality Modeling for Defect Density Prediction:COQUALMO, 1999) diz que a redução do prazo de desenvolvimento de um projeto desoftware, para concluirmos o projeto em menos tempo, certamente provocará impactonegativo no custo e principalmente na confiabilidade e qualidade do produto produzido. Poroutro lado, sabemos que o uso de técnicas de estimativas de custo, prazo e qualidade, auxiliaos gestores de projetos de software a tomarem, com maior precisão, decisões que impactemdiretamente e positivamente o sucesso de um projeto. Conforme estudamos nos capítulos anteriores, técnicas e modelos de estimativas decusto e prazo para projetos de software foram apresentadas, porém faltava um dos lados dotriâ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. 48. 48COCOMO II, chamado COQUALMO (COnstructive QUALity MOdel). Este modelo foicriado com a finalidade de auxiliar os gestores de projetos de software a determinarem aqualidade do produto, baseando-se na densidade de defeitos, que por sua vez acaba sendo umelemento 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 nosmodelos 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). Estesmodelos 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ãoestimados através do modelo de “Injeção de Defeitos de Software” (DI – Defect IntroductionSoftware) e os defeitos removidos através de técnicas como testes e inspeções, são estimadosatravés do modelo “Remoção de Defeitos de Software” (DR – Defect Removal Software). De acordo com Sunita Chulani (Chulani & Boehm, Modeling Software DefectIntroduction and Removal:COQUALMO (COnstructive QUALity MOdel), 1999), três são ostipos 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) eDefeitos de Codificação (Code Defects). Os defeitos residuais serão tratados posteriormentena seção “3.4. Modelo de Remoção de Defeitos de Software (Defect Removal Software)(DR).”
  49. 49. 49Figura 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 diversasformas durante seu ciclo de vida. No modelo COQUALMO esses defeitos são classificadosda 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 deinjeção de defeitos utiliza como parâmetros de entrada para cálculos preditivos, o tamanho dosoftware medido em mil Linhas de Código (Kilo Source Line Of Code – kSLOC), e podemtambém ser ajustados no caso de reuso. Assim como utiliza kSLOC, este modelo utiliza osmultiplicadores de esforço de 21 dos 22 drivers de custo utilizados nas estimativas doCOCOMO II, divididos em 4 categorias de drivers, conforme referencia a Tabela 17.
  50. 50. 50Tabela 17 – Drivers do Modelo de Injeção de Defeitos de Software Drivers de Injeção de Defeitos Post-Architecture Early Design Categoria Sigla Descrição Sigla Descrição Confiabilidade Requerida do Confiabilidade e Complexidade do RELY RCPX Software Produto DATA Tamanho da Base de Dados RUSE Reutilização Produto CPLX Complexidade do Produto RUSE Reutilização Documentação Associada às DOCU Necessidades do Ciclo de Vida Restrição do Tempo de Dificuldade da Plataforma TIME PDIF Execução Plataforma Restrição de Armazenamento STOR Principal PVOL Volatilidade da Plataforma ACAP Habilidade do Analista PERS Capacidade do Pessoal PCAP Habilidade do Programador PREX Experiência do Pessoal PCON Continuidade do Pessoal Pessoal APEX Experiência nas Aplicações PLEX Experiência nas Plataformas Experiência nas Ferramentas e LTEX Linguagens Uso de Ferramentas de Facilidades TOOL FCIL Software Desenvolvimento em Cronograma de Desenvolvimento SITE SCED Múltiplos Locais Requerido Cronograma de SCED Projeto Desenvolvimento Requerido PREC Precedência Arquitetura/Resolução do RESL Risco TEAM Coesão da Equipe PMAT Maturidade do Processo
  51. 51. 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 baseadaem um extenso trabalho de pesquisa e analisando o comportamento de determinados fatoresque 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 umatecnologia, onde quanto mais alto for o nível, a tendência é que menos erros sejam injetadosno produto. A decisão de se usar os mesmos drivers que o modelo COCOMO II não somentefaz com que haja uma total integração entre os modelos, como também simplifica a atividadede 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-triviaispara cada classificação de defeitos apresentada – requisitos, desenho da arquitetura da soluçãoe codificação – do produto de software, ou seja, defeitos injetados durante o ciclo de vida eque 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;

×