avaliação de medições realizadas por ferramentas de qualidade

Transcrição

BRUNO CARVALHO SILVA LUZ
AVALIAÇÃO DE MEDIÇÕES
REALIZADAS POR FERRAMENTAS DE
QUALIDADE INTERNA DE PRODUTOS
DE SOFTWARE
LAVRAS - MG
2014
BRUNO CARVALHO SILVA LUZ
AVALIAÇÃO DE MEDIÇÕES
REALIZADAS POR FERRAMENTAS DE
QUALIDADE INTERNA DE PRODUTOS
DE SOFTWARE
Monografia de graduação apresentada
ao Departamento de Ciência da
Computação da Universidade Federal de
Lavras como requisito parcial para
obtenção do título de Bacharel em
Sistemas de Informação.
Orientador
Dr. Antônio Maria Pereira de Resende
Coorientador
Dr. André Luiz Zambalde
LAVRAS - MG
2014
RESUMO
A Engenharia de Software tem como principal objetivo obter software de
qualidade. Uma das formas de medir a qualidade de um software é através das
métricas de produto. Ao utilizá-las é possível estimar projetos, ajudando a
identificar as características e prevenir falhas. Muitas métricas têm sido
propostas, mas as ferramentas que as aplicam não possuem descrições
suficientes que explicam como foram implementados os cálculos das mesmas.
Diante desse contexto, este trabalho teve como objetivo realizar uma análise
quantitativa de métricas de produto e suas ferramentas para identificar se há
diferenças significativas entre os valores gerados por essas ferramentas, e quais
fatores influenciam essas diferenças. As métricas analisadas foram: Número de
métodos, Proporção de comentários e Complexidade ciclomática média. Para a
consecução dos objetivos foi realizada a medição de 3 versões de 107 softwares,
com diferentes ferramentas de coleta. Foi utilizada a técnica de diferença entre
médias para saber se existe diferenças significativas entre as ferramentas. Os
resultados sugerem que todas as métricas analisadas possuem diferenças
significativas entre diferentes ferramentas e que tais diferenças são provocadas
por fatores como tipos de métodos, classes e estruturas de controle. Com isso,
conclui-se que as ferramentas nem sempre medem o que prometem, tornando
complicado o uso dessas ferramentas para estimar projetos de software.
Palavras-chave: Métricas de software. Qualidade de software.
ABSTRACT
The Software Engineering aims to obtain quality software. One way to measure
the quality of software is by means of product metrics. The use of metrics allows
estimating projects, helping to identify the features and prevent failure. Many
product metrics have been proposed, but the tools that implement these metrics
do not have enough descriptions that explain how the calculations of these
metrics were implemented. Given this context, this work aims to perform a
quantitative analysis of product metrics and tools to identify whether there are
significant differences between the values generated by these tools, and what
factors influence these differences. The following metrics were analyzed:
number of methods, Proportion of comments and average cyclomatic
complexity. To achieve the goals, 3 versions of 107 softwares were measured by
different collection tools. The technique of differences between means was used
to find out if there is significant differences between the tools. The results
suggest that all the metrics considered have significant differences when
measured by different tools and such differences are caused by factors such as
kinds of methods, classes, and control structures. Thus, it is concluded that the
tools do not always measure what they promise, making it difficult to use these
tools to estimate software projects.
Keywords: Software metrics. Software quality.
LISTA DE FIGURAS
Figura 1 Tipos de pesquisa............................................................................... 29
Figura 2 Classes de um software com NOM = 11.....................................33
Figura 3 Método G1.......................................................................................... 34
Figura 4 Método G2.......................................................................................... 34
Figura 5 Código-fonte de uma classe .............................................................. 35
Figura 6 Boxplot da métrica NOM para versão de software 1.....................40
Figura 9 Boxplot da métrica CR para versão de software 1.........................48
Figura 10 Boxplot da métrica CR para versão de software 2.......................49
Figura 11 Boxplot da métrica CR para versão de software 3.......................50
Figura 12 Boxplot da métrica ACC para versão de software 1.....................54
LISTA DE QUADROS
Quadro 1 Métricas de Halstead........................................................................24
Quadro 2 Relação entre métricas e ferramentas de medição........................35
Quadro 3 Testes das ferramentas na métrica NOM......................................38
Quadro 4 Estatística da métrica NOM para versão de software 1...............39
Quadro 7 Teste de Friedman na métrica NOM..............................................45
Quadro 8 Testes das ferramentas na métrica CR..........................................46
Quadro 9 Diferenças entre comentários..........................................................46
Quadro 10 Estatística da métrica CR para versão de software 1.................47
Quadro 13 Teste de Friedman na métrica CR................................................51
Quadro 14 Testes das ferramentas na métrica ACC......................................52
Quadro 15 Estatística da métrica ACC para versão de software 1..............53
Quadro 18 Teste de Friedman na métrica ACC.............................................58
LISTA DE SIGLAS
ACC
Average cyclomatic complexity (Complexidade ciclomática média)
CBO
Coupling between object classes (Acoplamento entre classes de objetos)
CC
Cyclomatic complexity (Complexidade ciclomática)
CR
Comments ratio (Proporção de comentários)
CS
Class size (Tamanho da classe)
DIT
Depth of the inheritance tree (Profundidade da árvore de herança)
FP
Function points (Pontos por função)
LCOM Lack of cohesion in methods (Falta de coesão em métodos)
LOC
Lines of code (Linhas de código)
NOA
Number of operations added by a subclass (Número de operações
adicionadas por uma subclasse)
NOC
Number of children (Número de filhos)
NOM Number of Methods (Número de métodos)
NOO
Number of operations overriden by a subclass (Número de operações
redefinidas por uma subclasse)
RFC
Response for a class (Resposta de uma classe)
SI
Specialiation index (Índice de especialização)
WMC Weight methods per class (Métodos ponderados por classe)
SUMÁRIO
1 INTRODUÇÃO ................................................................................... 10
1.1 Problema e objetivos ........................................................................ 11
1.2 Estrutura do trabalho ...................................................................... 12
2 REFERENCIAL TEÓRICO .............................................................. 13
2.1 Qualidade de software ..................................................................... 13
2.2 Medições, medidas e métricas ......................................................... 15
2.3 Escalas de medição ........................................................................... 16
2.4 Métricas de software ........................................................................ 18
2.5 Classificação das Métricas ............................................................... 19
2.5.1 Métricas de produto ...................................................................... 19
2.5.2 Métricas de processo ..................................................................... 20
2.5.3 Métricas de projeto ....................................................................... 20
2.6 Métricas tradicionais........................................................................ 21
2.6.1 Métricas orientadas ao tamanho .................................................. 21
2.6.1.1 Linhas de Código (LOC)............................................................ 21
2.6.1.2 Pontos por função (FP) .............................................................. 22
2.6.2 Métricas de complexidade ............................................................ 22
2.6.2.1 Complexidade ciclomática (CC) ............................................... 23
2.6.2.2 Métricas de Halstead .................................................................. 24
2.6.3 Métricas orientadas a objetos....................................................... 25
2.6.3.1 Métricas de Chidamber e Kemerer .......................................... 25
2.6.3.2 Métricas de Lorenz e Kidd ........................................................ 27
2.7 Valores de referência ....................................................................... 28
3 METODOLOGIA ............................................................................... 30
3.1 Classificações da pesquisa ............................................................... 30
3.2 Desenvolvimento da pesquisa .......................................................... 31
4 RESULTADOS E DISCUSSÕES ...................................................... 38
4.1 Número de métodos .......................................................................... 38
4.1.1 Testes nas ferramentas que calculam a métrica NOM .............. 38
4.1.2 Estatística descritiva da métrica NOM ....................................... 39
4.1.3 Testes estatísticos da métrica NOM ............................................. 45
4.2 Proporção de comentários ............................................................... 46
4.2.1 Testes nas ferramentas que calculam a métrica CR .................. 47
4.2.2 Estatística descritiva da métrica CR ........................................... 48
4.2.3 Testes estatísticos da métrica CR ................................................. 52
4.3 Complexidade ciclomática média ................................................... 53
4.3.1 Testes nas ferramentas que calculam a métrica ACC ............... 53
4.3.2 Estatística descritiva da métrica ACC ........................................ 54
4.3.3 Testes estatísticos da métrica ACC .............................................. 58
5 CONCLUSÕES ................................................................................... 60
REFERÊNCIAS ..................................................................................... 61
APÊNDICE ............................................................................................. 64
10
1 INTRODUÇÃO
O principal objetivo da Engenharia de Software é produzir software
de qualidade. Empresas que desenvolvem software com qualidade são mais
requisitadas, podem oferecer um serviço melhor, e com preços mais
competitivos. Quanto mais cedo um erro na construção do software for
identificado, menos recursos precisarão ser alocados para resolver o
problema.
Um ponto chave da Engenharia é a medição e, através desta,
podemos avaliar a qualidade dos sistemas a serem desenvolvidos. Ao
contrário de outras Engenharias, a Engenharia de Software não é baseada em
medidas absolutas, ou seja, há dificuldade em saber o que exatamente medir.
Uma forma de medir a qualidade de um software é através do uso de
métricas de software. Sommerville (2007) as define como qualquer tipo de
medição que se refira a um sistema de software, processo ou documentação
relacionada. As mesmas permitem entender o comportamento e o
funcionamento do software, avaliar e controlar, determinando padrões, metas
e critérios de aceitação do software, e também ajudam na prevenção de
falhas.
Diferentes tipos de métricas estão presentes na literatura. Um dos
tipos mais comuns são as métricas de produto, que têm como objetivo
quantificar características internas de um software, como por exemplo a
quantidade de linhas de código produzidas.
Entretanto, essas métricas ainda não são muito aceitas, pois sem os
valores de referência, e com as ferramentas medindo a mesma métrica, mas
11
considerando diferentes fatores, não é possível saber em qual nível de
qualidade está um software.
1.1 Problema e objetivos
As métricas de produto foram propostas há um bom tempo, mas devido
à dificuldade de aprendizado, os altos custos para manter um profissional
especializado na equipe e a falta de valores de referência, elas ainda não têm
sido amplamente aceitas e usadas. Além disso, as ferramentas de coleta que
medem essas métricas não descrevem adequadamente, ou não possuem
documentação suficiente que permitam saber o que foi implementado e como foi
implementado o cálculo das métricas. Exemplificando, é possível que duas
ferramentas A e B calculem uma métrica X que leva em consideração o número
de métodos de um software em seu cálculo. Entretanto, pode acontecer de a
ferramenta A contabilizar em seu resultado métodos na interface e a ferramenta
B ignorar esses métodos em sua contagem, ou seja, os valores apresentados
pelas duas ferramentas para a métrica X serão diferentes.
Diante desse contexto, o objetivo principal deste trabalho é realizar uma
análise quantitativa das seguintes métricas de produto: Número total de métodos,
Proporção de comentários e Complexidade ciclomática média.
Tal análise leva em consideração diferentes ferramentas de coleta que
calculam essas métricas para verificar se existem diferenças entre os valores
gerados por essas ferramentas. Caso existam e sejam significativas, será
comprovado que as ferramentas medem coisas diferentes do que são descritas
por elas.
Os resultados dessa análise ajudarão a esclarecer o que cada ferramenta
está medindo e também poderão servir como base para determinar valores de
12
referência para essas métricas, fazendo com que os mesmos sejam capazes de
ajudar profissionais da área de Engenharia de Software a interpretar
corretamente os resultados e melhorar a qualidade do software que está sendo
desenvolvido.
Para que o objetivo principal pudesse ser alcançado, os seguintes
objetivos foram propostos:
1. Revisão bibliográfica e levantamento de métricas de produto.
2. Levantamento de ferramentas de coleta que apliquem as métricas
encontradas.
3. Seleção de softwares desenvolvidos na linguagem JAVA para serem
medidos pelas ferramentas de coleta encontradas.
4. Medir os softwares através das ferramentas de coleta encontradas.
5. Análise das ferramentas de coleta para verificar o que cada uma está
realmente medindo.
6. Análise estatística das medidas para verificar se existem diferenças
significativas que influenciam os valores encontrados pelas métricas.
1.2 Estrutura do trabalho
Este trabalho está estruturado em cinco capítulos apresentados da
seguinte forma: o Capítulo 2 contêm os conceitos necessários e relacionados a
métricas de software para a compreensão da pesquisa. O Capítulo 3 descreve o
tipo de pesquisa realizada e os métodos que foram empregados. No Capítulo 4
são apresentados os resultados obtidos e também discussões sobre os mesmos.
No Capítulo 5 são descritas as conclusões referentes ao trabalho desenvolvido.
Ao fim são apresentadas as Referências Bibliográficas e Anexos.
13
2 REFERENCIAL TEÓRICO
Neste capítulo são apresentados os conceitos relacionados a métricas de
software que são necessários para a compreensão deste trabalho.
2.1 Qualidade de software
Com o crescente aumento do uso da tecnologia, um dos principais
desafios dos gerentes de projeto tem sido entregar projetos de software dentro
dos prazos estipulados e com a qualidade esperada pelo cliente. Empresas que
cumprem os prazos e entregam o software com qualidade, conseguem obter uma
grande vantagem competitiva em relação aos seus concorrentes.
Entretanto, garantir a qualidade não é algo simples. Muitas empresas
gastam uma grande quantidade de tempo corrigindo erros, em vez de dedicá-lo a
implementação de novas soluções. Este é um dos motivos que fazem com que a
Qualidade de software seja frequentemente estudada.
A Qualidade de software é uma área da Engenharia de Software que tem
como principal objetivo garantir a qualidade do software. Na literatura estão
presentes várias definições formais sobre a mesma. Cada definição possui
abordagens e pontos de vista diferentes, mas todas visam obter um produto que
satisfaça às expectativas do cliente.
A norma ISO/IEC 9126:1991 define a Qualidade de software como a
totalidade de características de um produto de software que lhe confere a
capacidade de satisfazer necessidades explícitas e implícitas. As necessidades
explícitas são aquelas informadas pelos usuários, já as necessidades implícitas
são necessidades subjetivas dos usuários, ou seja, aquelas que não são
14
informadas, mas que são consideradas óbvias e importantes no desenvolvimento
e manutenção do produto de software.
Rocha et al. (2001) destaca que a Qualidade de software pode ser vista
como um conjunto de características que devem ser atingidas em um
determinado grau para que o produto atenda às necessidades de seus usuários.
Para Pressman (2006), a mesma é definida como a satisfação de
requisitos funcionais e de desempenho explicitamente declarados, normas de
desenvolvimento explicitamente documentadas e características implícitas
esperadas em todo software desenvolvido profissionalmente. O mesmo ainda
destaca três pontos importantes:
1. Os requisitos de software são a base a partir da qual a qualidade é
medida. A falta de conformidade com os requisitos resulta em falta de
qualidade.
2. Normas especificadas definem um conjunto de critérios de
desenvolvimento que orientam a maneira segundo a qual o software
passa pelo trabalho de engenharia. Se as mesmas não forem seguidas, as
chances de se obter um produto sem qualidade serão enormes.
3. Existe um conjunto de requisitos implícitos que frequentemente não
são mencionados na especificação. Se tais requisitos não são satisfeitos,
a qualidade do software será duvidosa.
Desenvolver um produto geralmente passa por um processo complexo e
que envolve uma série de etapas, e a qualidade do produto está diretamente
relacionada com a qualidade do processo de desenvolvimento. Dessa forma, as
características
de
qualidade
devem
estar
bem
definidas
antes
do
15
desenvolvimento, pois dificilmente será possível incorporar a qualidade no
produto final.
2.2 Medições, medidas e métricas
Segundo Pressman (2006), a medição é um ponto extremamente
importante nas Engenharias, inclusive na Engenharia de Software. Uma das
formas de verificar o processo de desenvolvimento de um software se dá através
da medição.
De acordo com Fenton e Pfleeger (1998), medição é o processo pelo
qual números ou símbolos são atribuídos a atributos de entidades no mundo real
de tal forma a descrevê-los de acordo com regras claramente definidas.
Através de uma visão quantitativa, medições podem ser usadas para
compreender características e avaliar a qualidade de um produto ou processo,
permitindo gerenciar e identificar quais caminhos devem ser seguidos para
solucionar um problema.
Medir um produto ou processo pode ser possível através do uso das
métricas. A ISO/IEC 9126 (1991) define uma métrica como a composição de
procedimentos para medição e escalas medidas. Yanaze et al. (2010) afirma que
uma métrica é um sistema de mensuração que quantifica uma tendência, uma
dinâmica ou uma característica. Portanto, as métricas são usadas para explicar
fenômenos, diagnosticar causas, compartilhar descobertas, estimar custos e
projetar os resultados de eventos futuros.
Pressman (2006) ressalta que apesar de os termos medida, medição e
métrica serem frequentemente usados de forma sem distinção, é importante
destacar algumas diferenças entre eles:
Medida: fornece uma indicação quantitativa da extensão, quantidade,
16
dimensão, capacidade ou tamanho de algum atributo de um processo ou
produto.
Medição: é o ato de determinar uma medida.
Métrica: é a quantificação de um atributo.
Ainda de acordo com Pressman (2006), medidas são coletadas e
métricas são desenvolvidas, fornecendo assim indicadores. Um indicador
caracteriza-se por ser uma métrica ou uma combinação de métricas que
fornecem uma visão mais aprofundada e que permite ajustar o processo, projeto,
ou produto.
2.3 Escalas de medição
Segundo Kan (2003), as medições podem ser classificadas em quatro
tipos de escala: escala nominal, escala ordinal, escala de intervalo e escala de
taxa.
Escala nominal: uma variável de escala nominal classifica as unidades
em classes ou categorias quanto à característica que representa, sem estabelecer
qualquer relação de grandeza ou ordem. É denominada nominal porque a
diferenciação entre quaisquer categorias é feita apenas pelo nome.
Se o máximo que pode ser dito sobre um objeto é que ele é diferente de
outros, então a escala é nominal. São exemplos de variáveis expressas na escala
nominal: matrículas de automóveis, código civil e sexo.
Escala ordinal: uma variável de escala ordinal classifica as unidades em
classes ou categorias quanto à característica que representa, estabelecendo uma
relação de ordem entre as unidades pertencentes a categorias distintas. Qualquer
17
conjunto de valores que preservem a ordem são válidos para essa variável,
tornando a escala ordinal invariante sob transformações que preservem a ordem.
Se o máximo que pode ser dito sobre um objeto é que ele é, por
exemplo, maior ou melhor que outro, então a escala é ordinal. São exemplos de
variáveis expressas na escala ordinal: escalão social e escalão salarial.
Escala de intervalo: uma variável de escala de intervalo, além de
ordenar as unidades quanto à característica mensurada, possui uma unidade de
medida constante. No entanto, a origem dessa escala é arbitrária. A escala de
intervalo aproxima-se da concepção comum de medida, pois possui uma unidade
de medida constante. Alguns exemplos de escala de intervalo são as escalas de
temperatura Celsius e Fahrenheit.
A escala de intervalo permite inferências referentes a diferenças entre
unidades a serem medidas. Por exemplo, a mensuração da temperatura de
unidades permite determinar quanto uma é mais quente do que a outra.
Se o máximo que pode ser dito sobre um objeto, que ele é tantas
unidades maior que outro, então a escala é intervalar.
Escalas de taxa: uma variável de escala de taxa, também conhecida
como escala de razão, ordena as unidades quanto à característica mensurada,
possui uma unidade de medida constante e uma origem única. A escala de taxa é
a mais elaborada das escalas de medida, pois permite todas as operações
aritméticas. Essa escala possui um ponto zero único, além de unidade de medida
constante. É a escala de medida mais comum nas ciências físicas, tais como as
escalas para a medida de comprimento ou peso, por exemplo.
Se o máximo que pode ser dito que um objeto é tantas vezes maior ou
mais pesado que outro, então a escala é de taxa.
18
2.4 Métricas de software
A Engenharia de Software fornece algumas ferramentas que servem de
auxílio nas medições de um projeto de software. As métricas de software são
umas destas ferramentas.
Sommerville (2007) as define como algum tipo de medição que faz
referência a um sistema de software, processo ou documentação relacionada. A
partir desta, é possível identificar a quantidade de esforço, os custos e atividades
necessárias para um determinado projeto e medir a qualidade e produtividade de
um produto.
Guarizzo (2008) ressalta que as métricas de software têm como princípio
especificar as funções de coleta de dados de avaliação e desempenho, atribuindo
essas responsabilidades a toda a equipe envolvida no projeto, e analisar os
históricos dos projetos anteriores.
De acordo com Mills (1988), Fenton e Pfleeger (1998), o ideal é que as
métricas possuam as seguintes características:

Simplicidade: deve estar claro o que se propõe a medir.

Objetividade: a métrica deve ser formalmente definida, seu valor
deve estar atrelado ao objeto medido, independente de quem o
obtenha.

Fácil obtenção: deve ser possível obter seu valor rapidamente e com
baixo custo.

Validade: a métrica deve medir efetivamente o proposto.

Robustez: pequenas mudanças no software não podem causar
grandes mudanças no valor obtido.
19

Linearidade de escala: há formas de mapeamento para o
entendimento do comportamento das entidades através da
manipulação dos números obtidos.

Independência da linguagem utilizada.
2.5 Classificação das Métricas
As métricas de software podem ser classificadas em diversas categorias,
tais como: métricas diretas e indiretas Berghout e Sollingen (1999) e métricas
objetivas e subjetivas Humphrey (1989). Neste trabalho, a classificação utilizada
será a adotada por Fenton e Pfleeger (1998), Kan (2003) e Pressman (2006), que
destacam três tipos de métricas de software: métricas de produto, métricas de
processo e métricas de projeto.
2.5.1 Métricas de produto
Segundo Sommerville (2007), as métricas de produto são as que
quantificam características internas do software. São exemplos de atributos:
tamanho, acoplamento entre componentes, coesão de um componente,
complexidade e desempenho. Sommerville (2007) ainda classifica as métricas de
produto em dois tipos: métricas de produto dinâmicas e métricas de produto
estáticas.
As métricas dinâmicas servem de auxílio para avaliar a eficiência e a
confiabilidade de um programa. São coletadas por medições realizadas durante a
execução do programa, e estão diretamente relacionadas com os atributos de
qualidade do software. Determinar o número de falhas de um sistema é um
exemplo de métrica de produto dinâmica.
20
Já as métricas estáticas: servem de auxílio para avaliar a complexidade,
a facilidade de compreensão e a facilidade de manutenção de um sistema de
software. São coletadas por medições realizadas na documentação de projeto ou
código fonte do programa, e possuem um relacionamento indireto com atributos
de qualidade. Determinar o número de funções que chamam uma determinada
função é um exemplo de métrica de produto estática.
2.5.2 Métricas de processo
De acordo com Sommerville (2007), um processo pode ser definido com
um conjunto de atividades e resultados associados que produzem um produto de
software.
As métricas de processo, segundo Pressman (2006), fornecem
indicadores que permitem à organização avaliar o processo empregado, como o
modelo e as tarefas do mesmo. De acordo com Kan (2003), as métricas de
processo são utilizadas para aprimorar o desempenho e a manutenção do plano
de desenvolvimento, e também como indicadores de qualidade para defeitos
encontrados e o esforço necessário para sua correção e a eficiência da remoção
de defeitos.
2.5.3 Métricas de projeto
Para Kan (2003), as métricas de projeto representam as características
do projeto e a sua execução, tais como recursos, custo e cronograma, permitindo
avaliar o estado do projeto, monitorar riscos potenciais, ajustar tarefas e
controlar a qualidade da equipe de trabalho. Fenton e Pfleeger (1998)
denominam esse tipo de métrica como métricas de recurso, sendo que tais
21
recursos podem ser associados a recursos humanos, recursos materiais,
ferramentas, e métodos.
2.6 Métricas tradicionais
Nesta seção são descritas de forma sucinta algumas das métricas mais
encontradas na literatura. As métricas estão classificadas quanto a sua
orientação, que são: por tamanho, complexidade e objetos.
2.6.1 Métricas orientadas ao tamanho
As métricas orientadas ao tamanho são medidas diretas do software que
quantificam o tamanho do mesmo. Entre as que mais aparecessem na literatura
estão a LOC (Lines of code – Linhas de Código) e FP (Function points – Pontos
por função).
2.6.1.1 Linhas de Código (LOC)
A métrica LOC (Lines of code – Linhas de código) é uma das métricas
mais antigas e simples que existem, visto que ela apenas quantifica a contagem
do número de linhas de código de um sistema.
Apesar de sua simplicidade, a LOC não é amplamente aceita, pois
segundo Kan (2003), esta métrica possui o problema da ambiguidade da
contagem efetiva.
Na linguagem de programação Assembly, em que cada linha de código
corresponde a uma instrução, a definição desta métrica é clara. Com a chegada
das linguagens de alto nível, a contagem de linhas de código pode ser
22
influenciada pela consideração ou não de comentários, linhas em branco e outros
fatores que fazem com que tal contagem sofra diferenças significativas em seu
resultado final. Essas diferenças fazem com que a métrica LOC apresente
diversas variações, tornando sua definição não muito clara.
2.6.1.2 Pontos por função (FP)
Segundo Pressman (2006), a métrica FP (Function points - Pontos por
função) pode ser usada efetivamente como uma forma para medir a
funcionalidade entregue por um sistema. Proposta por Albrecht (1979), e usando
dados históricos, a mesma pode ser usada para:
1. Estimar o custo ou esforço necessário para projetar, codificar e
testar o software;
2. Prever o número de erros que vão ser encontrados durante o teste;
3. Prever o número de componentes e/ou o número de linhas de código
projetadas no sistema implementado;
Azevedo (1999) ressalta que esta métrica está baseada na visão externa
do usuário, sendo independente da linguagem utilizada, permitindo calcular o
esforço de programação e auxiliando o usuário final a melhorar o exame e
avaliação de projetos. É devido a esses e outros fatores que segundo Kan (2003),
ao longo dos anos essa métrica vem sendo aceita e usada no desenvolvimento de
sistemas tanto em termos de produtividade quanto em qualidade.
2.6.2 Métricas de complexidade
De acordo com McCabe e Watson (1994), métricas de complexidade
podem ser usadas para prever informação crítica sobre confiabilidade e
23
manutenibilidade de sistemas de software a partir da análise automática do
código-fonte.
As métricas de complexidade mais utilizadas são: Complexidade
ciclomática e Métricas de Halstead.
2.6.2.1 Complexidade ciclomática (CC)
Proposta por McCabe (1976), a CC (Cyclomatic complexity Complexidade ciclomática) é a métrica de complexidade mais utilizada. Tem
como objetivo medir a quantidade de caminhos de execução independentes
em um sistema. A ideia é representar em um grafo a sequência que um
programa pode seguir com todos os possíveis caminhos. A complexidade
encontrada fornecerá um número informando o quão complexo é um sistema.
Conforme Pressman (2006), essa métrica pode ser calculada por três
maneiras fundamentadas pela teoria dos grafos:
1. O número de regiões corresponde à complexidade ciclomática.
2. Dado um grafo de fluxo G, a complexidade ciclomática, V(G), é
definida como:
V(G) = A-N+2
Em que,
A é igual ao número de arestas do grafo de fluxo
N é igual ao número de nós.
3. Dado um grafo de fluxo G, a complexidade ciclomática, V(G),
também pode ser definida como:
V(G) = P+1
24
Em que,
P é o número de nós predicados contidos no grafo de fluxo G.
A complexidade ciclomática pode ser aplicada a funções, módulos,
métodos ou classes individuais de um programa, auxiliando também em
casos de teste.
2.6.2.2 Métricas de Halstead
Propostas por Halstead (1977), as métricas de complexidade de
Halstead foram desenvolvidas com o objetivo de determinar uma medida
quantitativa da complexidade diretamente a partir dos operadores e os
operandos presentes no código fonte de um sistema.
Interpretar estatisticamente o código-fonte como uma sequência de
operadores e operandos é a essência das métricas de Halstead.
De acordo com Halstead (1977), os seguintes parâmetros são
contabilizados na interpretação:
n1: Número de operadores distintos
n2: Número de operandos distintos
N1: Número total de operadores
N2: Número total de operandos
Através desses parâmetros são determinadas as métricas presentes no
Quadro 1.
25
Quadro 1 Métricas de Halstead
Métrica
Fórmula
n (Vocabulary - Vocabulário)
n = n1 + n2
N (Length - Tamanho)
N = N1+N2
V (Volume)
D (Difficulty - Dificuldade)
E (Effort - Esforço)
V = N x log2 n
n1/2 x N2/n
E=VxD
T (Time - Tempo de teste)
T = E/18
B (Bugs - Erros)
B = V/3000
2.6.3 Métricas orientadas a objetos
Na literatura estão presentes algumas métricas relacionadas ao contexto
de orientação a objetos, como o conjunto de métricas de Chidamber e Kemerer,
propostas em Chidamber e Kemerer (1994), e também o de Lorenz e Kidd,
propostas em Lorenz (1994).
2.6.3.1 Métricas de Chidamber e Kemerer
Um conjunto de seis métricas que permitem a análise quantitativa dos
artefatos de software orientado a objetos foram propostas por Chidamber e
Kemerer (1994). As mesmas possuem como objetivo identificar as classes que
possuem maior número de defeitos, orientando onde devem ser aplicados os
esforços de teste. Tais métricas são:
26
1. WMC (Weight methods per class – Métodos ponderados por
classe): representa a complexidade da classe por meio de seus métodos. O
cálculo desta métrica é dado pelo somatório das complexidades dos métodos que
constituem a classe. Se algumas classes apresentar um alto WMC, significa que
tende ser específica, ou seja, destinando-se a necessidades individuais, o que
restringe sua reutilização.
2. DIT (Depth of the inheritance tree – Profundidade da árvore de
herança): representa o número máximo de superclasses acima da classe
analisada, ou seja, indica a posição de uma classe na árvore de herança, que é
calculada pela distância máxima da classe até a raiz da árvore. Quanto maior a
profundidade, mais complexo pode ser um projeto, pois pode indicar que a
classe herdou muitas características comuns a outras classes, tornando-a mais
difícil de entender.
3. NOC (Number of children – Número de filhos): representa o
número de subclasses posicionadas imediatamente abaixo da classe analisada.
Um NOC alto pode indicar que uma superclasse possui muitos filhos que
necessitaram implementar características próprias, demonstrando baixo nível de
abstração. É também um indicador da importância de uma classe, pois quanto
mais sub-classes possuir uma classe, maior a importância de seu teste no
sistema.
4. CBO (Coupling between object classes – Acoplamento entre classes
de objetos): representa o nível de acoplamento entre as classes. O acoplamento
entre duas classes existe quando métodos de uma delas usa métodos ou variáveis
de instância da outra. Um CBO alto indica que a classe possui um número alto
de relacionamentos, o que torna mais difícil sua reutilização e aumenta sua
complexidade, pois a classe torna-se dependente de outras para efetuar suas
operações.
27
5. LCOM (Lack of cohesion in methods – Falta de coesão em
métodos): mede o quanto os métodos de uma classe acessam atributos em
comum. Quanto maior o LCOM, menos coesa é a classe. A coesão em métodos
é a capacidade dos métodos realizarem apenas a função a que são destinados e,
para isso devem acessar apenas atributos essenciais ao seu funcionamento.
Assim, dois métodos de uma classe são coesos se compartilham variáveis de
instância desta classe.
6. RFC (Response for a class – Resposta de uma classe): representa o
número de métodos que podem ser executados em resposta a uma mensagem
recebida por um objeto da classe. Esta representação é dada pela contagem do
número de métodos da classe mais o número de métodos chamados pela classe.
Um RFC alto indica uma maior possibilidade de a classe atender às suas
funções. Entretanto, quanto maior o RFC, mais complexa será a classe.
2.6.3.2 Métricas de Lorenz e Kidd
Outro conjunto de métricas que permitem a análise quantitativa dos
artefatos de software orientado a objetos foram propostos em Lorenz (1994). Tal
conjunto consiste de quatro métricas, e é denominado como Métricas de Lorenz
e Kidd. São elas:
1. CS (Class Size – Tamanho da Classe): mede o tamanho de uma
classe através de uma contagem do número total de operações e número total de
atributos que estão encapsulados nesta classe. Um CS alto indica que a classe
pode ser muito específica, dificultando sua reutilização, e que também possui
alta complexidade.
2. NOO (Number of operations overriden by a subclass – Número de
operações redefinidas por uma subclasse): mede o número de operações
28
substituídas por uma subclasse. Os métodos herdados de uma superclasse podem
ser redefinidos em subclasses com o objetivo de tornar sua funcionalidade mais
específica. Um alto NOO pode significar problemas na estruturação, visto que
muitas subclasses do projeto possuem métodos redefinidos e provavelmente
estão mal projetadas.
3. NOA (Number of operations added by a subclass – Número de
operações adicionadas por uma subclasse): mede o número de métodos e
atributos adicionados por uma subclasse. Um alto NOA indica que
possivelmente há o afastamento da abstração da superclasse, gerando problemas
de estruturação, o que dificulta a reutilização, e também um aumento de
complexidade.
4. SI (Specialization index – Índice de especialização): mede o número
de métodos adicionados, excluídos ou modificados em uma classe. É obtida
através do resultado da NOO multiplicado pelo nível da árvore hierárquica onde
se encontra a subclasse. O valor obtido é dividido pelo número total de métodos
da classe. Um alto SI indica um problema de estruturação de classes, afetando a
reutilização.
2.7 Valores de referência
Ao longo do tempo, muitas métricas de software vêm sendo propostas.
Entretanto, a maioria das métricas não apresentam valores de referência
confiáveis, gerando um impacto negativo nas medições, e fazendo com que seu
uso não seja amplamente aceito. Autores como Ferreira (2011) e Lanz (2006)
vêm tentando quebrar esse paradigma, propondo valores de referência para
algumas métricas de software existentes.
29
De acordo com Lanza e Marinescu (2006), valores de referência
dividem o espaço do valor de uma métrica em regiões, e dependendo da região
que o valor da métrica se encontra, é possível fazer uma avaliação da unidade
medida. O autor ainda destaca que existem duas formas para propor valores de
referência para métricas de software: com base na experiência e na análise
estatística.
Os valores de referência baseados na experiência são os menos
confiáveis, pois dependem da experiência de um profissional, sendo difícil
generalizar ou reproduzir. Benlarbi et al. (2000) afirma que muitos valores de
referência foram estabelecidos com base na experiência, mas como não foram
validados empiricamente, tais valores geram certa desconfiança. Uma métrica
que obteve seu valor de referência estabelecido com base na experiência foi a
Complexidade ciclomática, proposta por McCabe (1976) e descrita na Seção
2.6.2.1 deste trabalho. McCabe (1976) considerou que o valor de referência
médio para essa métrica é 10.
Já os valores de referência baseados na análise estatística demonstram
ser mais confiáveis. Os mesmos são derivados a partir da análise dos dados de
uma população ou amostra, e utilizam técnicas como média, desvio padrão,
variância, dentre outros. Segundo Lanza e Marinescu (2006), esses valores são
úteis principalmente para métricas de tamanho, onde apenas com o uso da
estatística, é possível obter valores frequentes ou incomuns.
30
3 METODOLOGIA
Neste capítulo são descritas as classificações da pesquisa com base nas
classificações propostas em Jung (2004), e também os métodos utilizados no
desenvolvimento da mesma.
3.1 Classificações da pesquisa
De acordo Jung (2004), a pesquisa pode ser classificada quanto à
natureza, objetivos, abordagem e procedimentos. A Figura 1 mostra os tipos de
pesquisa existentes. A área em amarelo indica as classificações de pesquisa deste
trabalho.
Figura 1 Tipos de pesquisas
Fonte: Adaptado de Jung (2004)
31
A pesquisa desenvolvida neste trabalho está classificada da seguinte
forma:
Quanto à Natureza: Pesquisa aplicada. O trabalho tem como objetivo
realizar uma análise de ferramentas que aplicam métricas de software, ou seja,
produzir conhecimento para aplicação de seus resultados, com o objetivo de
contribuir com fins práticos.
Quanto aos objetivos: Descritiva, pois realiza-se o estudo, a análise, o
registro, e a interpretação dos dados das medições sem a interferência do
pesquisador.
Quanto à abordagem: Quantitativa. A pesquisa pode ser classificada
como quantitativa porque as variáveis a serem medidas são objetivas e medidas
em escalas numéricas. Como o objetivo do trabalho é analisar estatisticamente
algumas métricas de software, o uso de dados estatísticos e medidas intervalares
são utilizados.
Quanto aos procedimentos: Experimental. Este trabalho realiza testes
estatísticos utilizando dados de medições de software com a finalidade de
comparar os resultados e verificar se há diferença significativa entre os mesmos.
3.2 Desenvolvimento da pesquisa
Para que os objetivos pudessem ser atingidos, o desenvolvimento do
trabalho consistiu de sete etapas: revisão bibliográfica, seleção de ferramentas,
seleção de softwares, medição dos softwares, escolha das métricas, análise das
ferramentas e análise estatística.
1. Revisão bibliográfica: foi realizado um levantamento de livros e
artigos sobre métricas de produto para aprimorar os conhecimentos sobre o
32
tema.
2. Seleção de ferramentas: foram pesquisadas e selecionadas
ferramentas de coleta que utilizam métricas de produto para mensurar a
qualidade de um software. Tais ferramentas deveriam ser gratuitas ou possuir
licença acadêmica.
As seguintes ferramentas foram selecionadas:

Analizo

Code Analyzer

CodePro Analytix

Connecta

Krakatau

Simple Code Metrics
Diferentemente das outras, a ferramenta Krakatau não é gratuita.
Entretanto, foi disponibilizada uma licença acadêmica válida por tempo limitado
com o desenvolvedor.
3. Seleção de softwares: para que as métricas pudessem ser analisadas
era necessário ter a disposição uma quantidade significativa de projetos de
softwares a fim de garantir a confiabilidade e qualidade esperadas. Desta forma,
alguns critérios foram estabelecidos. Cada software deveria obedecer as
seguintes regras:

Possuir código aberto.

Desenvolvimento na linguagem JAVA.

Possuir três versões de desenvolvimento disponíveis.

Disponibilidade de código fonte.

Disponibilidade de bytecode.
33
Foram selecionadas três versões de 107 softwares de código livre. Tais
softwares foram baixados do maior portal de código aberto existente,
denominado SourceForge.net. O mesmo caracteriza-se por ser um repositório de
código fonte utilizado por desenvolvedores do mundo todo para gerenciar o
desenvolvimento de softwares open source. Os softwares foram organizados por
versão e domínio de aplicação, e em seguida foram preparados para serem
medidos. A fim de facilitar a compreensão dos dados, foi definido que a versão
mais antiga de cada software seria denominada como versão 1, a versão
intermediária como versão 2, e a última versão lançada como versão 3.
A lista com os 107 softwares estão no Apêndice A deste trabalho.
4. Medição dos softwares: cada versão dos softwares foi medida pelas
ferramentas encontradas. Os dados gerados pelas medições foram tabulados e
organizados. Os mesmos passaram por uma rigorosa inspeção com o objetivo de
verificar sua confiabilidade. Inconsistências encontradas foram tratadas e
corrigidas.
5. Escolha das métricas: após as medições da amostra, foram
escolhidas três métricas de produto para serem analisadas estatisticamente. Tal
escolha baseou-se nos seguintes critérios: ser medida por no mínimo duas
ferramentas automáticas e falta de valores de referência consistentes na
literatura. As métricas escolhidas foram: Número de métodos (NOM),
Complexidade ciclomática média (ACC) e Proporção de comentários (CR).
A métrica Número de métodos (NOM) consiste basicamente de uma
contagem do número de métodos que um software possui. Cada classe é
analisada, e à medida que um método é encontrado, o mesmo é contabilizado no
valor total.
34
A Figura 2 representa um software com um conjunto de três classes com
NOM = 11.
Figura 2 Classes de um software com NOM = 11
A métrica Complexidade ciclomática média (ACC) nada mais é do que
um valor determinado pela média da Complexidade ciclomática de McCabe
(1976) encontrada em cada um dos métodos de um software. É calculada da
seguinte forma:
ACC = CCT / NOM, em que:
ACC = Complexidade ciclomática média.
CCT = Soma das Complexidades ciclomáticas de cada método.
NOM = Número total de métodos do software.
35
Aplicando a fórmula da complexidade ciclomática (V(G) = A-N+2) para
os caminhos de execução dos métodos representados nas Figuras 3 e 4 temos:
V(G1) = 6-5+2 = 3
V(G2) = 10-8+2 = 4
NOM = 2
Figura 3 Método G1
Figura 4 Método G2
Desta forma, a Complexidade ciclomática média (ACC) é definida por:
ACC = 3+4/2
ACC = 3,5
A métrica Proporção de comentários é definida como a relação entre o
número de linhas comentadas e o número de linhas de código de um software. É
calculada da seguinte forma:
Proporção de comentários = Linhas comentadas / Linhas de código.
De acordo com o código-fonte da figura 5, temos os seguintes dados:
36
Linhas comentadas = 3
Linhas de código = 8
Desta forma, a Proporção de comentários é determinada pela razão entre
os dados obtidos:
Proporção de comentários = 3 / 8 = 0,375.
Figura 5 Código-fonte de uma classe
O Quadro 2 apresenta a relação das métricas escolhidas com as
ferramentas de medição encontradas.
Quadro 2 Relação entre métricas e ferramentas de medição.
Métricas
NOM
ACC
CR
Ferramentas
Analizo
X
Code Analyzer
CodePro Analytix
X
X
X
Connecta
Krakatau
X
X
Simple Code Metrics
X
X
37
6. Análise das ferramentas: cada ferramenta de coleta que mede as
métricas escolhidas foi analisada para verificar o que estava realmente medindo,
ou seja, identificar tipos de métodos, classes, comentários ou estruturas de
controle que são levados em consideração nos resultados apresentados por suas
métricas. Tal análise é importante porque as ferramentas não possuem
descrições adequadas em suas documentações. É possível que uma ferramenta
possa, por exemplo, considerar em suas medições métodos dentro da interface.
Pode ser que outra ferramenta não considere tais métodos, fazendo com que os
resultados apresentados pelas duas ferramentas sejam diferentes.
7. Análise estatística: nesta etapa os dados gerados pelas medições das
métricas de produto selecionadas foram analisados estatisticamente com o
objetivo de verificar se haviam diferenças significativas entre os dados gerados
pelas ferramentas. Para cada uma das métricas foi verificado:
a) Se existe diferença significativa entre as médias de cada software,
independentemente da versão, para cada uma das métricas escolhidas.
b) O mesmo raciocínio acima, mas verificando se há diferença
significativa entre as versões de um mesmo software, isto é, se de uma versão
para outra houve uma mudança significativa na média.
38
4 RESULTADOS E DISCUSSÕES
Neste capítulo são apresentados e discutidos os resultados
encontrados nas medições das seguintes métricas de produto: Número de
métodos, Proporção de comentários e Complexidade ciclomática média. Para
cada métrica foi realizado testes em todas as ferramentas com o objetivo de
verificar o que cada ferramenta estava realmente medindo. Em seguida foi
gerada uma estatística descritiva para descrever e sumarizar os dados. Por
fim, testes de comparação de médias foram aplicados para verificar se há
diferença significativa entre as mesmas. Todos os dados são anormais e o
valor de significância utilizado nos testes de comparação de médias foi igual
a 0,05. A estatística descritiva e os testes de comparação entre médias foram
gerados pela ferramenta XLSTAT, que é um software de análise de dados
estatísticos para o Microsoft Excel.
4.1 Número de métodos
Nesta seção são apresentados os resultados dos testes das
ferramentas, a estatística descritiva, e os resultados dos testes de comparação
de média para a métrica Número de métodos.
4.1.1 Testes nas ferramentas que calculam a métrica NOM
A métrica Número de métodos foi medida pelas seguintes
ferramentas: Analizo, CodePro Analytix, Krakatau e Simple Code Metrics.
Nos testes foram utilizados 32 métodos de diferentes tipos, tais como: public,
39
private, static, final, dentre outros.
Conforme o Quadro 3, a métrica Número de métodos apresentou valores
exatamente iguais nas ferramentas Analizo e Krakatau. O “X” indica o que cada
ferramenta considera. O número de métodos encontrados nas ferramentas
Simple Code Metrics e na CodePro Analytix foram menores porque na primeira
não são considerados construtores, e a segunda não considera métodos em classe
dentro de classe, métodos na interface e nem construtores.
Quadro 3 Testes nas ferramentas da métrica NOM
Ferramenta
Métodos
utilizados
Métodos
encontrados
Interface
Classes
internas
Herança
Construtores
Analizo
32
32
X
X
X
X
CodePro
Analytix
32
30
X
X
X
Krakatau
32
32
X
X
X
Simple Code
Metrics
32
25
X
X
Todas as ferramentas consideraram em sua contagem métodos public,
private, protected, métodos com static, abstract, synchronized, final, e também
gets e sets criados automaticamente.
4.1.2 Estatística descritiva da métrica NOM
A estatística descritiva para a métrica Número de métodos é apresentada
nos Quadros 4, 5 e 6. Cada quadro corresponde a uma versão das ferramentas,
40
que vai de 1 até 3. As Figuras 6, 7 e 8 sumarizam os dados em gráficos do tipo
BoxPlot.
De acordo com o Quadro 4 é possível identificar que, para a versão de
software número 1, há uma certa discrepância entre os valores da ferramenta
Krakatau e as demais ferramentas, pois a média dos valores apresentada para
essa ferramenta foi bem menor do que para as demais. O 1º Quartil indica que
75% dos valores estão acima de 300 para todas as ferramentas, com exceção da
Krakatau, que estão com 75% dos valores acima de 182. O 3º Quartil indica que
25% dos valores estão acima de 1865 para a ferramenta Krakatau, e acima de
2400 para as outras ferramentas.
Quadro 4 Estatística descritiva da métrica NOM para versão de software 1
Analizo
Média
2258,636
CodePro
Analytix
2045,651
Krakatau
1561,009
Simple Code
Metrics
1801,421
Moda
199
2704
7
NA
1º Quartil
398,500
347,500
182,000
329,500
Mediana
1180,000
916,000
730,000
977,000
3º Quartil
3162,000
2675,750
1865,000
2491,500
Amplitude
11687,000
13435,000
11158,000
9095,000
Soma dos quadrados
763586824,8
745084212,1
483332171
448430380,1
Variância
7203649,290
7096040,115
4559737,462
4230475,284
Desvio padrão
2683,961
2663,839
2135,354
2056,812
Através do gráfico Boxplot é possível sumarizar as seguintes medidas:
média, 1º Quartil, Mediana e 3º Quartil, valores mínimos e máximos. Segundo
Braga (2010), o gráfico Boxplot é usado para identificar onde estão localizados
50% dos valores mais prováveis, a mediana e os valores extemos. Também
identifica a existência de outliers, que representam os valores extremamente
altos ou baixos, ou seja, valores discrepantes. O BoxPlot é interpretado da
seguinte forma:
41
O eixo vertical representa a variável analisada.
A caixa (box) propriamente contém 50% dos dados. O limite superior da
caixa indica o percentil de 75% dos dados e o limite inferior da caixa indica o
percentil de 25%. A distância entre esses dois quartis é chamada de interquartil.
A linha na caixa indica o valor da mediana dos dados. Se a linha não é
equidistante dos extremos, então os dados são assimétricos.
Os extremos do gráfico representados pelos pontos Minimum e
Maximum indicam os valores mínimo e máximo. Os pontos fora do gráfico são
os outliers.
De acordo com a Figura 6, percebe-se que os dados para todas as
ferramentas são assimétricos, pois a linha mediana dentro da caixa não é
equidistante dos extremos. Percebe-se também (através dos outliers) a existência
de vários valores discrepantes. Os BoxPlots lado a lado deixam claro a grande
diferença da Krakatau para as demais ferramentas.
Figura 6 Boxplot da métrica NOM para versão de software 1
42
Assim como na versão 1, a média dos valores encontrados na ferramenta
Krakatau para a versão 2 também apontam uma grande diferença em relação as
outras ferramentas. De acordo com o Quadro 5, a média dos valores para essa
ferramenta também foi bem menor do que para as demais. O 1º Quartil indica
que 75% dos valores estão acima de 450 para todas as ferramentas. A Krakatau
novamente é exceção, pois 75% dos seus valores estão acima de 171. O 3º
Quartil indica que 25% dos valores estão acima de 2535 para a ferramenta
Krakatau, e acima de 3400 para as outras ferramentas.
Analizo
CodePro
Analytix
Krakatau
Simple Code
Metrics
Média
3350,093
2657,337
1832,925
2463,037
Moda
253
502
101
NA
1º Quartil
702,500
472,000
171,000
543,000
Mediana
1986,000
1195,000
634,000
1719,000
3º Quartil
4751,000
3469,000
2535,000
3524,500
Amplitude
24044,000
17637,000
13461,000
12541,000
Soma dos quadrados
1615768270
1160939674
688612663,4
728575683,9
Variância
15234721,029
11162881,477
6496345,881
6873355,508
Desvio padrão
3903,168
3341,090
2548,793
2621,709
De acordo com a Figura 7 percebe-se que os dados para todas as
ferramentas são assimétricos e também há a existência de vários valores
discrepantes para todas as ferramentas. Novamente percebe-se a grande
diferença da ferramenta Krakatau para as demais ferramentas.
43
Considerando as versões de número 3, e conforme o Quadro 6,
percebe-se que a média dos valores encontrados pela ferramenta Krakatau
também foi bem menor do que para as demais. O 1º Quartil indica que 75%
dos valores estão acima de 500 para todas as ferramentas, com exceção da
Krakatau, que estão com 75% dos valores acima de 151. O 3º Quartil indica
que 25% dos valores estão acima de 1711 para a ferramenta Krakatau, e
acima de 3800 para as demais.
44
Analizo
Média
Moda
1º Quartil
Mediana
3º Quartil
Amplitude
Soma dos quadrados
Variância
Desvio padrão
4342,308
NA
1045,000
2180,000
5511,500
42710,000
3586568848
33807213,215
5814,397
CodePro
Analytix
3281,471
NA
548,500
1475,000
3859,500
40596,000
2720198366
26409692,873
5139,036
Krakatau
1660,729
14
151,000
736,000
1711,000
16692,000
732017893,1
6905829,181
2627,894
Simple Code
Metrics
3275,804
NA
778,000
1766,000
4180,000
24924,000
1726960963
16292084,555
4036,345
Conforme a Figura 8 percebe-se que os dados para todas as ferramentas
são assimétricos e também há a existência de vários valores discrepantes para
todas as ferramentas. Mais uma vez percebe-se a grande diferença da ferramenta
Krakatau para as demais ferramentas.
45
4.1.3 Testes estatísticos da métrica NOM
Para verificar se existe diferença significativa entre as médias de cada
software, independentemente da versão, foi utilizado o teste de Friedman, pois
segundo Siegel (2006) é útil para realizar testes não paramétricos para mais de
duas amostras emparelhadas.
Hipóteses:
H0: Não há diferenças significativas entre as médias.
H1: Há diferenças significativas entre as médias.
Os resultados do teste foram os seguintes:
N = 107
Q = 171,778
P-valor < 0,0001
Como P-valor < 0,0001, a hipótese H0 é rejeitada e a hipótese H1 aceita,
ou seja, há diferença significativa entre as médias de cada software.
Através do teste post-hoc de Nemenyi (NEMENYI, 1963) é possível
realizar comparações múltiplas pareadas para identificar quais ferramentas
apresentam diferenças significativas entre as médias de cada software.
O teste constatou que as ferramentas Analizo e CodePro Analytix
apresentam diferenças significativas entre si, e também em relação a todas as
outras. As ferramentas Krakatau e Simple Code Metrics não apresentam
diferenças significativas entre si.
A fim de verificar se existe diferença significativa entre as versões de
um mesmo software, isto é, se houve uma mudança significativa na média de
uma versão para outra, novamente foi utilizado o teste de Friedman. As
hipóteses foram as mesmas para as quatro ferramentas:
46
O Quadro 7 mostra os resultados obtidos no teste de Friedman.
Quadro 7 Teste de Friedman na métrica NOM
Analizo
CodePro Analytix
Krakatau
Simple Code Metrics
N = 107
N = 107
N = 107
N = 107
Q = 146,70
Q = 89,348
Q = 2,093
Q = 146,70
P-valor < 0,0001
P-valor < 0,0001
P-valor = 0,351
P-valor < 0,0001
A única ferramenta para qual não foi rejeitada a hipótese H0 foi a
Krakatau, pois P-valor > 0,05. Dessa forma, não houve diferença significativa
entre as médias de uma versão para esta ferramenta.
As demais ferramentas apresentaram P-valor < 0,05, ou seja, a hipótese
H0 é rejeitada. Aplica-se então o teste post-hoc de Nemenyi para verificar quais
versões apresentaram diferença significativa.
O teste de Nemenyi demonstrou que existem diferenças significativas
entre todas as versões nas ferramentas Analizo, CodePro Analytix e Simple
Code Metrics, ou seja, existem diferenças entre as versões de software 1, 2 e 3.
4.2 Proporção de comentários
Nesta seção são apresentados os resultados dos testes das ferramentas, a
estatística descritiva, e os resultados dos testes de comparação de média para a
métrica Proporção de comentários.
47
4.2.1 Testes nas ferramentas que calculam a métrica CR
A métrica Proporção de comentários é medida pelas seguintes
ferramentas: CodePro Analytix e Krakatau. Foram testados comentários do tipo
/*/ e //.
De acordo com o Quadro 8, os valores encontrados nas duas ferramentas
divergem porque a ferramenta CodePro Analytix considera comentários do tipo
/*comentário*/ como apenas 1 comentário, diferentemente da Krakatau que a
cada quebra de linha soma 1 ao número de comentários encontrados.
Quadro 8 Testes nas ferramentas da métrica CR
Valores
Ferramenta
encontrados
Interface
Classes
internas
Herança
Construtores
CodePro Analytix
0,042
X
X
X
X
Krakatau
0,07
X
X
X
X
O Quadro 9 ilustra bem a diferença entre os tipos de comentários
considerados em cada ferramenta.
Quadro 9 Diferenças entre comentários
CodePro Analytix
Krakatau
Comentários do tipo:
Comentários do tipo:
/*comentário
/*comentário
comentário
comentário
comentário*/
comentário*/
é considerado como 1 comentário
é considerado como 3 comentários
Outro fator que pode influenciar no valor desta métrica é que a
ferramenta Krakatau arredonda os valores encontrados em cada classe. Por
48
exemplo, se em uma classe a proporção de comentários encontrada foi de
0,20833, a ferramenta arredondará este valor para 0,21. Um projeto com um
grande número de classes poderá apresentar maiores discrepâncias entre os
valores das duas ferramentas.
O número de linhas de código encontrado nas duas ferramentas foram
exatamente iguais, não afetando assim o valor da métrica Proporção de
comentários.
4.2.2 Estatística descritiva da métrica CR
A estatística descritiva para a métrica Proporção de comentários é
apresentada nos Quadros 10, 11 e 12. Cada quadro corresponde a uma versão
das ferramentas, que vai de 1 até 3. As Figuras 9, 10 e 11 sumarizam os dados
em gráficos do tipo BoxPlot.
software número 1, há discrepância entre os valores das ferramentas CodePro
Analytix e Krakatau, pois a diferença entre as médias dos valores apresentados
pelas mesmas é grande. A discrepância também é observada através da diferença
entre o 1º Quartil e 3º Quartil das ferramentas.
Quadro 10 Estatística descritiva da métrica CR para versão de software 1
Média
Moda
1º Quartil
Mediana
3º Quartil
Amplitude
Soma dos quadrados
Variância
Desvio padrão
CodePro Analytix
0,148
0,19
0,090
0,130
0,190
0,780
1,081584
0,010
0,101
Krakatau
0,613
0,643
0,306
0,473
0,687
4,792
3328603,662
0,361
0,601
49
Conforme a Figura 9 percebe-se que os dados da ferramenta CodePro
Analytix são assimétricos, pois a linha mediana dentro da caixa não é
equidistante dos extremos. Diferentemente da CodePro, os dados da Krakatau
aparentam ser simétricos. Percebe-se também (através dos outliers) a existência
de vários valores discrepantes. Os BoxPlots lado a lado deixam claro a diferença
entre as ferramentas CodePro Analytix e Krakatau.
Figura 9 Boxplot da métrica CR para versão de software 1
Conforme o Quadro 11, também nota-se uma grande diferença entre as
médias das ferramentas CodePro Analytix e Krakatau para as versões de
software de número 2. Tal diferença também é observada entre o 1º Quartil e 3º
Quartil das ferramentas.
50
Média
Moda
1º Quartil
Mediana
3º Quartil
Amplitude
Soma dos quadrados
Variância
Desvio padrão
CodePro Analytix
0,235
0,12
0,090
0,130
0,200
7,000
48,58161333
0,467
0,683
Krakatau
0,642
0,674
0,322
0,522
0,710
4,957
5595437,847
0,354
0,595
De acordo com a Figura 10 é possível notar que os dados da CodePro
Analytix são assimétricos e os da Krakatau são simétricos. Novamente percebese a existência de valores discrepantes e também a diferença entre as
ferramentas.
51
De acordo com o Quadro 12, e assim como nas versões anteriores, notase também uma grande diferença entre as médias das ferramentas CodePro
Analytix e Krakatau para as versões de software de número 3. Tal diferença
também é observada entre o 1º Quartil e 3º Quartil das ferramentas.
Média
CodePro Analytix
0,163
Krakatau
0,603
Moda
0,12
0,59
1º Quartil
0,090
0,311
Mediana
0,135
0,475
3º Quartil
0,190
0,720
Amplitude
1,000
4,244
Soma dos quadrados
2,037175962
2902818,052
Variância
0,020
0,276
Desvio padrão
0,141
0,526
Conforme a Figura 11 é possível notar que os dados das duas
ferramentas são assimétricos, diferentemente das versões anteriores em que os
dados da Krakatau aparentavam ser simétricos. Mais uma vez percebe-se a
existência de valores discrepantes e também a diferença entre as ferramentas.
52
4.2.3 Testes estatísticos da métrica CR
software, independentemente da versão, o teste de Wilcoxon foi utilizado, pois
segundo Siegel (2006) é útil para realizar testes não paramétricos para duas
amostras emparelhadas.
Hipóteses:
Os resultado do teste foi o seguinte:
N = 107
V = 215
P-valor < 0,0001
Como P-valor < 0,05 é rejeitada a hipótese de igualdade entre médias,
implicando em uma diferença significativa entre as ferramentas CodePro
Analytix e Krakatau.
uma versão para outra, foi utilizado o teste de Friedman. As hipóteses foram as
mesmas para as duas ferramentas:
Os resultados do teste de Friedman é apresentado no Quadro 13.
Quadro 13 Teste de Friedman na métrica CR
CodePro Analytix
Krakatau
N = 107
N = 107
Q = 0,699
Q = 0,352
P-valor = 0,705
P-valor = 0,839
53
Como P-valor > 0,05 a hipótese H0 não é rejeitada nas duas ferramentas.
Assim, não foi encontrada diferença significativa entre versões nas ferramentas
CodePro Analytix e Krakatau.
4.3 Complexidade ciclomática média
Nesta seção são apresentados os resultados dos testes nas ferramentas, a
estatística descritiva, e os resultados dos testes de comparação de média para a
métrica Complexidade ciclomática média.
4.3.1 Testes nas ferramentas que calculam a métrica ACC
A métrica Complexidade ciclomática média é medida pelas seguintes
ferramentas: CodePro Analytix e Simple Code Metrics. Nos testes foram
utilizados 32 métodos de diferentes tipos. Dentro dos métodos haviam
declarações condicionais como "if", "for", "while" e "try catch".
Conforme o Quadro 14, os valores encontrados nas duas ferramentas são
diferentes porque a ferramenta Simple Code Metrics não considera métodos na
Interface e nem métodos em Classes internas. Além disso, a estrutura Try Catch
e construtores afetam o valor da complexidade na ferramenta CodePro Analytix,
o que não acontece na Simple Code Metrics, pois a mesma não considera
construtores e nem a estrutura Try Catch.
Quadro 14 Testes nas ferramentas da métrica ACC
Ferramenta
CodePro
Analytix
Simple
Code
Metrics
Valores
encontrados
Interface
Classes
internas
Herança
Construtores
Estrutura
Try
Catch
1,46
X
X
X
X
X
1,36
X
54
4.3.2 Estatística descritiva da métrica ACC
A estatística descritiva para a métrica Número de métodos é apresentada
nos Quadros 15, 16 e 17. Cada quadro corresponde a uma versão das
ferramentas, que vai de 1 até 3. As Figuras 12, 13 e 14 sumarizam os dados em
gráficos do tipo BoxPlot.
software número 1, não há discrepância entre os valores das ferramentas
CodePro Analytix e Simple Code Metrics, pois a diferença entre as médias dos
valores apresentados pelas mesmas é pequena. A diferença entre os valores do 1º
Quartil e 3º Quartil das ferramentas também não é grande.
Quadro 15 Estatística descritiva da métrica ACC para versão de software 1
CodePro Analytix
Simple Code Metrics
Média
2,419
2,345
Moda
1,83
NA
1º Quartil
1,713
1,679
Mediana
2,020
2,054
3º Quartil
2,753
2,725
Amplitude
14,370
7,645
Soma dos quadrados
311,728946
129,2418876
Variância
2,969
1,219
Desvio padrão
1,723
1,104
De acordo com a Figura 12 percebe-se que os dados da ferramenta
CodePro Analytix e Simple Code Metrics são assimétricos, pois a linha mediana
55
dentro da caixa não é equidistante dos extremos. Percebe-se também (através
dos outliers) a existência de alguns valores discrepantes. Os BoxPlots lado a
lado deixam claro que há pouca diferença entre as duas ferramentas.
Figura 12 Boxplot da métrica ACC para versão de software 1
Conforme o Quadro 16, também nota-se que não há grande diferença
entre as médias das ferramentas CodePro Analytix e Simple Code Metrics para
as versões de software de número 2. O 1º Quartil e 3º Quartil das ferramentas
também não apresentam grandes diferenças.
56
CodePro Analytix
Simple Code Metrics
Média
2,528
2,419
Moda
1,78
NA
1º Quartil
1,780
1,701
Mediana
2,090
2,065
3º Quartil
2,720
2,788
Amplitude
19,400
8,284
Soma dos quadrados
479,7714248
140,0308639
Variância
4,613
1,321
Desvio padrão
2,148
1,149
De acordo com a Figura 13 é possível notar que os dados das duas
ferramentas são assimétricos. Novamente percebe-se a existência de poucos
valores discrepantes e também a pouca diferença entre as ferramentas.
57
Assim como nas versões anteriores, e de acordo com o Quadro 17, não
há uma grande diferença entre as médias das ferramentas CodePro Analytix e
Simple Code Metrics para as versões de software de número 3. Grandes
diferenças também não são observadas entre o 1º Quartil e 3º Quartil das
ferramentas.
CodePro Analytix
Simple Code Metrics
Média
2,534
2,383
Moda
1,95
NA
1º Quartil
1,780
1,761
Mediana
2,000
2,066
3º Quartil
2,783
2,652
Amplitude
23,170
6,756
Soma dos quadrados
550,5027385
107,1737517
Variância
5,345
1,011
Desvio padrão
2,312
1,006
De acordo com a Figura 14 é possível notar que os dados das duas
ferramentas são assimétricos. Assim como nas versões anteriores, mais uma vez
percebe-se a existência de poucos valores discrepantes e também a pouca
diferença entre as ferramentas.
58
4.3.3 Testes estatísticos da métrica ACC
software, independentemente da versão, o teste de Wilcoxon foi utilizado.
Hipóteses:
Os resultado do teste foi o seguinte:
N = 107
V = 2835,500
P-valor = 0,970
59
Como P-valor > 0,05, a hipótese de igualdade entre médias não é
rejeitada, fazendo com que as ferramentas CodePro Analytix e Simple Code
Metrics não apresentem diferença significativa.
uma versão para outra, foi utilizado o teste de Friedman.
Hipóteses:
Os resultados do teste são visualizados no Quadro 18.
Quadro 18 Teste de Friedman na métrica ACC
CodePro Analytix
Simple Code Metrics
N = 107
N = 107
Q = 14,259
Q = 8,283
P-valor = 0,001
P-valor = 0,016
Como P-valor < 0,05 a hipótese H0 é rejeitada nas duas ferramentas, ou
seja, há diferenças significativas. Dessa forma, aplica-se o teste post-hoc de
Nemenyi para identificar quais versões apresentam diferenças significativas.
O teste demonstrou que as versões 1 e 3 apresentam diferenças
significativas entre si tanto na ferramenta Code Pro Analytix quanto na
ferramenta Simple Code Metrics.
60
5 CONCLUSÕES
Este trabalho buscou realizar uma análise entre métricas de produto
levando em consideração diferentes ferramentas de coleta. As métricas
analisadas foram: Número de métodos, Proporção de comentários e
Complexidade ciclomática média.
Um conjunto de 107 softwares, com 3 versões cada, foram medidos por
essas ferramentas a fim de verificar se existem diferenças entre as mesmas.
Diferenças foram encontradas e testes estatísticos utilizando a técnica de
diferença entre médias verificaram se as diferenças eram significativas ou não.
Os resultados mostraram que, para todas as métricas, os valores gerados
pelas ferramentas apresentaram diferenças significativas entre si. Essas
diferenças são explicadas pela forma em que são implementadas as ferramentas,
ou seja, fatores como tipos de métodos, tipos de classes, tipos de comentários e
tipos de estruturas de controle influenciam no cálculo dos valores determinados
pelas mesmas. Também foi verificado que as versões de um software
influenciam no cálculo de tais valores, pois diferenças significativas entre
versões foram encontradas.
Dessa forma, fica claro que as ferramentas de coleta, apesar de
descreverem a mesma coisa, acabam medindo coisas diferentes, gerando tais
diferenças e tornando complicado o uso dessas ferramentas para estimar projetos
de software.
A partir da análise estatística realizada neste trabalho, e como trabalhos
futuros, sugere-se tentar determinar valores de confiança para as métricas
analisadas e, consequentemente, o desenvolvimento de uma ferramenta que
atenda às necessidades dos desenvolvedores de software.
61
REFERÊNCIAS
ALBRECHT, A. J. Measuring Application Development Productivity. New
York: IBM, 1979.
AZEVEDO, D. J. P. Análise de pontos por função para aplicações
orientadas a documentos. Porto Alegre: CPGCC da UFRGS, 1999.
BENLARBI, S. et al. Thresholds for object-oriented measures. ln:
International Symposium on Software Reliability Engineering, 11., 2000, San
Jose. Anais... San Jose: IEEE Computer Society, 2000. p. 24-38.
BRAGA, L. P. V. Compreendendo Probabilidade e Estatística. 1. ed. Rio
de Janeiro: E-PAPERS, 2010
CHIDAMBER, S. R.; KEMERER, C. F. A metrics suite for object oriented
design. IEEE Transactions on Software Engineering, v. 20, n. 6, p. 476493, jun. 1994.
FENTON, N. E; PFLEEGER, S. L. Software Metrics: A Rigorous and
Practical Approach. 2. ed. Course Technology, 1998.
FERREIRA, K. A. M. Um modelo de predição de amplitude da
propagação de modificações contratuais de software orientado por
objetos. Belo Horizonte: UFMG, 2011.
GUARIZZO, K. Métricas de Software. Jaguariúna: FAJ, 2008.
HALSTEAD, M. H. Elements of software science. New York: Elsevier
Science Inc., 1977.
HUMPHREY, W.S. Managing the software process. 1. ed. AddisonWesley, 1989
62
ISO/IEC 9126. The international organization for standardization.
Software engineering Product quality. 1991.
JUNG, C. F. Metodologia Para Pesquisa & Desenvolvimento. Rio de
Janeiro: Axcel Books, 2004.
KAN, S. H. Metrics and Models in Software Quality Engineering. 2. ed.
Boston: Addison-Wesley, 2003.
LANZA, M.; MARINESCU, R. Object-oriented metrics in practice: Using
software metrics to characterize, evaluate, and improve the design of objectoriented systems. New York: Springer, 2006.
LORENZ, M.; KIDD, J. Object-Oriented Software Metrics. Prentice Hall,
1994.
MCCABE, T. J. A complexity measure. IEEE Transactions on Software
Engineering, v. 2, n. 4, p. 308-320, 1976.
MCCABE, T. J.; WATSON, A. H. Software Complexity, Crosstalk, v. 7, n.
12, p. 5-9, dez. 1994.
MILLS, E. E. Software Metrics. Pittsburgh: SEI - Carnegie Mellon
University, 1988.
NEMENYI, P. Distribution-free multiple comparisons. New Jersey:
Princeton University, 1963.
PRESSMAN, R. S. Engenharia de Software. 2. ed. São Paulo: McGrawHill, 2006.
ROCHA, A. R. C. et al. Qualidade dos produtos de software: teoria e
prática. São Paulo: Prentice Hall, 2001.
BERGHOUT, E.; SOLLINGEN, R. The Goal/Question/Metric Method: a
practical guide for quality improvement of software development. London:
McGraw-Hill. 1999
63
SIEGEL, S. Estatística Não-Paramétrica para
Comportamento. 2. ed. Porto Alegre: Artmed, 2006.
Ciências
do
SOMMERVILLE, I. Engenharia de Software. 8. ed. São Paulo: Pearson,
2007.
YANAZE, M. H. et al. Retorno de invesimentos em comunicação. 1. ed.
São Caetano do Sul: Difusão, 2010.
64
APÊNDICE
APÊNDICE A – Softwares medidos
Nome do software
aTunes
Subsonic
Impro-Visor
StreamRipStar
Music Box
Weka
Jenes - Genetic Algorithms
for Java
Meka
Observation Manager
Parallel Spectral
Deconvolution
JDEread
Daylight Chart
Java TreeView
VarScan
TRMSim-WSN
Versões
3.0
2.0
1.0
4.0
3.0
2.0
4.07
5.10
5.16
0.3.0
0.5.6
0.6.4
1.01
1.04
1.07
3.0.6
3.3.6
3.6.10
1.2.0
2.0.0
2.1.0
0.85
1.0
1.3.0
0.114
0.717
1.221
1.9
1.11
1.12
1.0
1.2
1.4
1.0
2.0
3.3
1.1.0
1.1.4
1.1.6r4
2.2
2.2.10
2.3.6
0.2
0.3.1
0.5
Data do
lançamento
15/12/2012
20/04/2010
22/08/2006
12/05/2010
22/03/2007
27/02/2005
09/11/2009
07/03/2012
14/05/2012
26/07/2008
16/12/2009
25/10/2012
08/02/2010
08/04/2010
08/09/2012
15/02/2002
17/04/2006
31/07/2013
09/02/2009
07/04/2012
08/01/2013
02/09/2011
04/05/2012
08/03/2013
16/07/2006
30/05/2008
10/03/2013
25/04/2009
27/08/2009
19/09/2013
12/03/2009
20/05/2010
26/07/2013
16/04/2007
26/08/2007
08/09/2012
28/09/2006
08/09/2009
23/08/2013
27/04/2010
23/03/2012
29/07/2013
15/05/2009
20/07/2009
25/03/2012
Domínio de aplicação
Audio e Video
Audio e Video
Audio e Video
Audio e Video
Audio e Video
Artificial Intelligence
Astronomy
Astronomy
Astronomy
Astronomy
Bio-Informatics
Bio-Informatics
Bio-Informatics
65
DavMail
Freeplane
jBPM
Rapidminer
PDF Split and Merge
GridSim
JGroups
JPPF
Jacob
Azureus/Vulze
Dbunit
Hibernate
JabRef
Universal Password Manager
c3p0 JDBC Data Sources
Json-lib
4.1.0
3.0.0
2.0.0
1.1.0
1.1.3
1.2.20
5.0
4.0
3.0
5.0
4.0
3.0
2.2.1
2.0
1.0
5.2
5.0
4.1
3.2.6
3.0
2.2
3.2.2
2.1.1
1.0
1.9
1.13
1.17
4.8.1.2
3.0.5.2
2.1.0
2.4.9
2.4.5
2.4.0
4.0
3.0
2.0
2.9.2
2.0
1.0
1.1
1.6
1.12
0.8.5.1
0.9.0
0.9.2
1.0
2.0
2.4
26/09/2012
12/02/2009
10/12/2008
20/10/2012
06/12/2010
26/06/2010
04/02/2011
11/07/2009
24/06/2005
09/08/2010
31/07/2007
11/07/2005
31/01/2013
12/04/2010
29/06/2008
25/11/2010
24/09/2009
01/09/2007
17/01/2013
17/11/2011
15/09/2003
27/01/2013
04/05/2010
27/12/2007
26/02/2005
06/10/2007
03/08/2013
04/02/2013
29/05/2008
18/07/2003
30/09/2012
22/05/2009
27/11/2008
15/12/2012
31/03/2005
10/06/2003
12/01/2013
30/01/2006
30/11/2003
16/08/2011
16/08/2011
06/06/2013
02/03/2005
11/07/2005
09/02/2013
12/02/2007
20/07/2007
14/12/2010
Business
Business
Business
Business
Business
Clustering
Clustering
Clustering
Clustering
Communication
DataBase
DataBase
DataBase
DataBase
DataBase
Development
66
PMD
VRaptor
Lightweight Java Game
Library
JUnit
JHotDraw
JEdit
iReport
Im4Java
Eclipse
DrJava
Code Generation Library
Joda Time
jPDF Tweak
ProGuard
RText
5.0.2
4.3
4.1
3.4.1
3.3.0
3.0.1
2.8.5
2.4
2.0
4.10
4.5
4.0
7.0.6
6.0
5.2
5.0
4.0
3.0
5.0.1
4.0.0
3.6.0
1.0.0
1.2.0
1.4.0
4.2.1
4.2
3.7.1
20120818-r5686
20100816-r5366
20090821-r5004
2.2.3
2.2
2.1.3
1.0
1.6
2.3
0.9
1.0
1.1
1.0
3.5
4.10
1.0.0
2.0.0
2.0.7
03/02/2013
04/11/2011
17/11/2007
10/04/2012
01/02/2011
22/10/2009
04/11/2012
11/04/2010
13/10/2008
14/11/2012
19/08/2008
16/02/2006
06/09/2011
01/02/2004
19/02/2001
22/11/2012
12/04/2002
25/12/2000
08/01/2013
10/01/2011
02/09/2009
22/03/2010
01/09/2011
27/12/2012
28/09/2012
28/06/2012
12/12/2011
18/08/2012
16/08/2010
21/08/2009
27/07/2012
26/05/2008
13/10/2005
22/02/2005
28/10/2008
16/08/2013
10/09/2007
27/12/2010
19/12/2011
06/06/2002
24/01/2006
29/07/2013
04/12/2009
16/01/2012
03/05/2013
Development
Development
Development
Development
Development
Development
Development
Development
Development
Development
Development
Development
Development
Development
Development
67
Sahi
Checkstyle
Cobertura
Demoiselle
xmlsh
OmegaT
Gate
Java Neural Network
Framework Neuroph
LaTeXDRAW
FreeMarker
iText
Liferay
Wireless Universal Resource
File
Jmol
jMusic
Logisim
V2-20090521
V3-20101103
V44-20130429
4.4
5.2
5.6
1.0
1.5
2.0
1.1.0
2.0.0
2.3.0
1.1.8
1.2.0
1.2.3
1.8.1
2.3.0
2.6.3
5.0
6.0
7.0
2.1
2.4
2.7
1.0.2
1.9.3
2.0.8
2.3.19
2.3.9
2.03
5.3.5
5.1.0
5.0.0
6.0
5.0
4.0
1.3.1
1.4.1
1.4.4.1
13.0
12.0
11.0
1.6.4
1.5
1.2
2.7
2.4
2.0
21/05/2009
03/11/2010
29/04/2013
16/12/2007
25/09/2010
18/09/2012
12/02/2005
05/08/2005
29/05/2013
11/01/2010
30/12/2010
31/10/2012
24/01/2012
14/06/2012
22/03/2013
01/10/2009
28/04/2012
17/07/2013
29/05/2009
11/11/2010
13/02/2012
07/04/2009
08/06/2010
18/11/2012
02/01/2006
24/06/2007
15/03/2010
01/03/2012
23/01/2007
12/06/2002
19/12/2012
06/05/2011
08/12/2009
04/06/2010
09/04/2008
02/06/2006
24/08/2011
15/08/2012
11/01/2013
25/01/2013
04/10/2011
08/05/2007
05/02/2013
24/03/2004
26/11/2001
07/03/2011
30/07/2010
31/10/2005
Development
Development
Development
Development
Development
Development
Development
Development
Development
Dynamic Content
Dynamic Content
Dynamic Content
Dynamic Content
Education
Education
Education
68
Cabra
Biogenesis
JStock
OpenBravoPos
Buddi
FreeCol
KoLmafia
RoboCode
Hodoku
Vassal Engine
TikiOne Steam Cleaner
PCGen
FFGenie
Art of Illusion
FreeMind
Jasper Reports
0.4.2
0.6.0
0.7.0
0.2.1
0.5
0.8
1.0.6z
1.0.5v
1.0
2.3
2.2
2.0
1.0.0
2.6.3.0
3.4.1.7
0.10
0.9
0.8
15.0
14.0
13.0
1.8.0.0
1.7.0.2
1.6.0.0
1.0
2.0.1
2.2.0
3.1.2
3.2.6
3.2.8
1.0.1
2.0.0
2.2.0
5.10.2
5.14.0
6.00.1
2008.2
2010.2
2013.4
1.0
2.0
2.9.1
0.0.2
0.6.0
0.9.0
5.0
4.0
3.0
20/03/2011
23/10/2011
29/10/2012
17/05/2006
12/11/2007
20/12/2010
01/01/2013
24/11/2010
16/11/2008
03/11/2010
29/08/2008
25/02/2008
23/06/2006
08/09/2007
17/04/2013
11/06/2011
01/01/2010
14/01/2009
20/01/2012
19/03/2010
05/03/2009
30/01/2013
15/02/2009
01/05/2008
30/01/2009
14/04/2010
29/07/2012
02/09/2012
23/05/2013
28/07/2013
28/01/2012
06/03/2013
20/06/2013
11/03/2007
08/06/2008
23/08/2013
26/08/2008
31/03/2010
26/04/2013
11/02/2002
08/03/2005
19/02/2012
27/06/2000
01/02/2003
18/02/2011
19/11/2012
10/01/2011
19/05/2008
Education
Education
Financial
Financial
Financial
Games
Games
Games
Games
Games
Games
Games
Games
Graphics
Graphics
Graphics
69
JFreeChart
Euclide
VietOCR
JChart2D
FractalToy
ForceFeedback Joystick
Driver
Prime
Mobile Atlas Creator
GeoAPI
IP Monitor
Java Network Browser
SoapUI
Yet Another Java Service
Wrapper
jNetPcap
Kalender
Jasypt
1.0.14
1.0.9
1.0.0
0.2.0
0.5.3
0.6.6
1.0
2.0
3.0
2.0.0
3.0.0
3.2.2
0.1.2
0.2.0
0.2.1
0.5
0.8
0.8.3
1.0
3.0
3.5
1.9
1.9.7
1.9.14
1.0.0
2.0.0
3.0.0
0.04
0.03
0.01
1.56
1.28
1.0
4.0
3.0
2.0
11.4
10.4
9.4
1.0
1.2
1.4
1.1_svn583
1.6_svn731
2.0_svn972
1.4.1
1.7
1.9.0
20/11/2011
04/01/2008
02/12/2005
14/03/2007
04/08/2009
14/04/2012
18/07/2009
06/02/2011
03/10/2010
31/05/2006
01/06/2008
24/09/2011
24/08/2010
05/01/2012
19/11/2012
07/11/2009
18/01/2010
19/11/2011
18/03/2010
19/07/2010
06/02/2012
18/08/2011
16/05/2012
29/07/2013
18/05/2004
08/06/2005
03/06/2011
27/03/2010
20/03/2008
28/08/2007
30/05/2012
10/05/2003
23/02/2003
14/06/2011
09/07/2009
12/12/2007
11/01/2013
10/10/2010
19/09/2009
26/12/2007
19/03/2009
21/08/2013
09/06/2012
08/09/2012
31/05/2013
16/01/2008
29/10/2010
18/12/2011
Graphics
Graphics
Graphics
Graphics
Graphics
Hardware
Hardware
Mapping
Mapping
Networking
Networking
Networking
Networking
Networking
Scheduling
Security
70
JSch
JXplorer
JFileCrypt
Areca Backup
DocFetcher
JeeObserver
Zephyr
DataCrow
FileBot
Med's movie
Google2SRT
Java YouTube video
Downloader
ZK Simply Ajax and Mobile
0.1.49
0.1.25
0.1.0
3.3.02
3.2
3.0
0.1.2
0.2.0
0.3.0
5.0
6.1
7.3.7
0.8.0
1.0
1.0.3
2.0.0
2.1.2
3.1.2
2.3.2
2.7
2.8
3.9.20
3.2
2.4
3.3
2.65
2.0
2.9
2.3
1.70
0.1
0.3
0.6
V20101219
V20110829
V20130506
5.0.3
6.0.0
7.0.0
11/10/2012
16/02/2006
11/02/2003
10/11/2012
03/03/2007
03/11/2003
03/01/2006
24/09/2006
13/06/2010
26/05/2007
20/12/2008
31/08/2013
22/08/2007
12/05/2009
18/03/2010
15/12/2009
02/06/2010
16/03/2012
30/10/2007
23/09/2009
11/09/2012
02/02/2013
24/03/2008
16/07/2006
18/01/2013
24/06/2012
15/09/2011
31/01/2010
22/04/2006
24/02/2005
31/08/2008
31/08/2008
11/08/2013
19/12/2010
29/08/2011
06/05/2013
30/06/2010
14/02/2012
13/08/2013
Security
Security
Storage
Storage
Storage
Test and Measurement
Test and Measurement
Utilities
Utilities
Utilities
Video
WWW/HTTP
Protocols/AJAX

avaliação de medições realizadas por ferramentas de qualidade

Transcrição

Documentos relacionados

1. Monitoramento – Nesse mercado em constante e rápida evolução

a relevância dos dados de rádio em uma plataforma fácil e

Baixar este arquivo PDF

SCAMTEC: SISTEMA DE AVALIAÇÃO DE

http://www.blogdocallcenter.com 1 3 Passos para um Programa de

EasyCyclomaticComplexity Tool: Uma ferramenta de apoio ao

Manual - Parte 6

Evolução de Software

INSTRUTOR DE ARTES - CORTE E COSTURA

Categoria Actual