Paulo Roberto Miranda Meirelles

Levantamento de Mtricas de Avaliao de e ca Projetos de Software Livre

Orientador: Prof. Dr. Fabio Kon

Durante a elaborao deste trabalho, o autor teve apoio nanceiro do Projeto Qualipso e CNPq ca

So Paulo, Dezembro de 2008 a

Sumrio a
1 Introduo ca 2 Mtricas de Software e 2.1 2.2 2.3 Classicao das Mtricas de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . ca e Escalas de Medio para Mtricas de Software . . . . . . . . . . . . . . . . . . . . . . . . ca e Mtricas de Software Tradicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 2.3.1 Mtricas Objetivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Mtricas de Dimenso de Software . . . . . . . . . . . . . . . . . . . . . . . . . . e a Mtricas de Halstead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Mtricas de Complexidade de Software . . . . . . . . . . . . . . . . . . . . . . . . e Mtricas de Qualidade de Software . . . . . . . . . . . . . . . . . . . . . . . . . . e 2.3.2 2.4 Outras Mtricas Tradicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Mtricas de Classes e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mtricas de Orientao a Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e ca Mtricas de Mtodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e e Mtricas de Acoplamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Mtricas de Herana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e c 2.5 Mtricas do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Medidas Aplicadas aos Mtodos Ageis . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 1 3 4 4 5 6 6 7 9 10 12 14 14 16 16 16 17 18 20 20

3 Aspectos Relevantes e Mtricas de Qualidade para Adoo de um Software Livre e ca 3.1 Mtricas e Aspectos Selecionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e

4 Resultados do Levantamento de Mtricas de Avaliao de Projetos de Software e ca Livre 4.1 4.2 Perl dos Entrevistados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resultados das Mtricas e Aspectos Pesquisados . . . . . . . . . . . . . . . . . . . . . . e 4.2.1 Aspectos e Mtricas mais Relevantes . . . . . . . . . . . . . . . . . . . . . . . . . e 28 28 41 56 59

5 Consideraes Finais co A Questionrio de Levantamento de Aspectos Relevantes e Mtricas de Qualidade a e para Adoo de um Software Livre ca Referncias Bibliogrcas e a

60 69

Resumo Tradicionalmente, qualidade de Software comumente atribu ao processo de desenvolvimento do e da software que teoricamente leva ` conformidade com os requisitos elencados. O surgimento e a adoo a ca de metodologias geis, procurando desburocratizar o processo de desenvolvimento, e o crescimento a do impacto do software livre na indstria demonstram que, em muitos casos, o cdigo-fonte de um u o determinado programa passa a ser o principal e/ou unico artefato ao nal de sua construo. Assim, ca as mtricas convencionais de qualidade que tm como base a documentao do processo de software e e ca j no podem ser consideradas sucientes para a avaliao de muitas aplicaes dispon a a ca co veis. Desse modo, este trabalho pretende investigar, dentro do estado-da-arte e de um ampla pesquisa realizada com especialistas em desenvolvimento de software, as mtricas e os aspectos baseados no cdigo-fonte, e o testes, manutenibilidade, comunidade, entre outros apresentados neste trabalho, capazes de determinar caracter sticas da qualidade do software, ajudando na escolha de adoo de um software livre. ca

Cap tulo 1

Introduo ca
A indstria de software incorporou ao longo do tempo a idia de que qualidade de software u e e composta, em resumo, por qualidade do processo de desenvolvimento, qualidade do projeto e qualidade do produto (Rocha, Maldonado e Weber, 2001). De acordo com essa viso, ela denida como a a e conformidade do software desenvolvido com os requisitos e caracter sticas impl citas que so esperadas a do software (Pressman, 1995). Ou seja, 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 usurios a a (Rocha, Maldonado e Weber, 2001). Dessa forma, muitas das mtricas comumente usadas so baseadas e a na documentao gerada no processo de desenvolvimento. ca As metodologias geis, como a Programao eXtrema (XP) (Beck e Fowler, 2000; Beck e Andres, a ca 2004), surgem como um contraponto aos mtodos tradicionais de desenvolvimento de software, de mae neira que os recursos e tempo de desenvolvimento priorizam a construo de cdigo-fonte de qualidade. ca o Isso similar ` forma de desenvolvimento de software adotada pelas comunidades de desenvolvedores e a de software livre, ou seja, software que tem como uma de suas caracter sticas ser de cdigo aberto. o O impacto e a utilizao dos programas de cdigo aberto na indstria de software tm aumentado ca o u e gradativamente nas ultimas dcadas e tais programas j inuenciam signicativamente a economia e a global (Benkler, 2006). No entanto, h empresas e governos ainda relutantes em adotar software livre a devido a dvidas legais, incertezas comerciais, questes culturais ou falta de conana tanto na qualidade u o c do produto (cdigo produzido) quanto no suporte para esse tipo de software. Por outro lado, por o suas caracter sticas, os programas de cdigo aberto apresentam um enorme potencial para melhorar a o produtividade, competitividade e agilidade da indstria de software brasileira, hoje ainda muito aqum u e das possibilidades do pa s. Uma melhor explorao dos problemas relacionados ` qualidade do software de cdigo aberto pode ca a o apontar o quo pertinente um estudo aprofundado das mtricas para a avaliao da qualidade de a e e ca software baseada no cdigo-fonte e caracter o sticas e aspectos como testes, atividades das comunidades, canais de distribuio, licenas, ferramentas entre outros tambm apresentados neste trabalho. Tal ca c e estudo ser focado no desenvolvimento de mtricas que permitiro a anlise de aspectos como segurana, a e a a c exibilidade, clareza, modularidade, manutenibilidade, portabilidade do software e que possam ser levantadas automaticamente por ferramentas criadas e/ou adaptadas para prover tais informaes. co Embora haja centenas de empresas e governos interessados em utilizar mais amplamente componentes de software livre em suas infra-estruturas de tecnologia da informao, eles muitas vezes podem se ca perder diante da enorme quantidade de opes dispon co veis e da falta de critrios objetivos para avaliar e

a conabilidade das opes existentes. Nesse contexto, como poss medir a qualidade do software co e vel para ajudar na escolha da adoo de um desses programas ou bibliotecas livres dispon ca veis? Quais so a as mtricas de qualidade? Como medir essas mtricas? Como comparar os programas de forma a e e embasar uma escolha entre vrias alternativas semelhantes? Como automatizar e avaliar a aplicao a ca dessas mtricas?. Este presente trabalho o ponto inicial para se obter algumas dessas respostas. e e Ao contrrio do software proprietrio, cujo cdigo-fonte normalmente no dispon para seus a a o a e vel clientes e usurios, o software livre permite a anlise de seu cdigo e mesmo a execuo de testes do tipo a a o ca caixa branca, onde os mdulos internos do software so avaliados. Quando se tem acesso ao cdigoo a o fonte, poss realizar medies sobre a sua estrutura e organizao interna de forma a avaliar sua e vel co ca qualidade. Em estudos recentes (Henderson-Sellers, 1996; Fenton e Peeger, 1998; Sato, Goldman e Kon, 2007), enfatizado o fato das mtricas de cdigo-fonte permitirem a anlise de dados relacionados aos e e o a erros, exibilidade, complexidade, legibilidade, manutenibilidade, segurana e portabilidade do cdigo, c o que so fatores para a aceitao de um produto de software. Alm dessa anlise do cdigo-fonte, em a ca e a o boa parte dos projetos de software livre tambm poss acessar seu sistema de controle de verses, e e vel o lista de participantes e desenvolvedores e base de dados de erros e correes (Gousios et al., 2007). A co partir desses dados seria poss obter informaes sobre a agilidade da equipe de desenvolvimento e vel co comunidade de um projeto em atender as necessidades de seus usurios, sobre a rapidez com que os a erros reportados so corrigidos, sobre o quo ativa a comunidade de usurios, entre outras. Um estudo a a e a sistematizado sobre esses dados poderia ajudar empresas e governos na deciso sobre qual alternativa a adotar, uma vez que eles poderiam ter uma idia sobre a qualidade do suporte oferecido pela comunidade e por trs de um determinado software livre. a Esses novos conceitos, maneiras de desenvolver software e questes sobre a adoo dos software o ca de cdigo aberto exigem tambm uma alterao ou adaptao na forma de avaliao da qualidade do o e ca ca ca software, tendo como base o cdigo-fonte, mtricas objetivas e aspectos da equipe de desenvolvimento o e e comunidade envolvida, e no uma nfase na documentao ou o processo de desenvolvimento. Dessa a e ca forma, o presente trabalho prev a abordagem de trs tpicos: (i) no Cap e e o tulo 2, a investigao do ca estado-da-arte em mtricas de software com o intuito de conhecer os primeiros estudos e acompanhar a e evoluo e as mudanas de contextos nas ultimas dcadas; (ii) no Cap ca c e tulo 3, uma seleo de aspectos e ca mtricas objetivas e subjetivas com uma abordagem diferente em relao ao que qualidade de software; e ca e (iii) no Cap tulo 4, os resultados de uma pesquisa sobre os aspectos e mtricas para adoo de software e ca livre, que alm dos dados sobre relevncia dos aspectos e mtricas, tem um levantamento do perl e a e dos entrevistados, da atuao dos mesmos em projetos de software livre e participao e relao das ca ca ca organizaes e empresas, que os entrevistados pertencem, com os sistemas livres dispon co veis. Sero a apresentados, de forma resumida, as opinies dos especialistas em desenvolvimento de software sobre o os 106 aspectos e mtricas elencados no questionrio dispon na e a vel ntegra no Anexo A deste trabalho.

Cap tulo 2

Mtricas de Software e
O objetivo das mtricas de software, de acordo com o seu conceito original, a identicao e medio e e ca ca dos principais parmetros que afetam o desenvolvimento de software (Mills, 1998). A necessidade das a mtricas de software teve maior ateno quando se constatou a chamada crise do software, como bem e ca argumentado em (Arthur, 1985). Outro fator que corroborou essa necessidade foi a constatao de uma ca gerncia inecaz durante o desenvolvimento da maior parte das solues de software, uma vez que o e co desenvolvimento de software complexo e no se tinha medidas bem denidas e viveis para a avaliao e a a ca do software e seu desenvolvimento. Porm, estimativas precisas e ecazes, planejamento e controle so e a aspectos dif ceis de se concretizar em conjunto (Mills, 1998). Assim, com as mtricas de software, se e prope uma melhoria do processo de gesto com a identicao, medio e controle dos parmetros o a ca ca a essenciais do software. Mtricas de software tm sido propostas e usadas faz algum tempo como citado no trabalho de e e (Wolverton, 1974; Perlis, Sayward e Shaw, 1981). Uma mtrica, segundo denio da ISO 9126 e ca (ISO/IEC9126-1, 2001), a composio de procedimentos para medio e escalas de medidas. O e ca ca Instituto de Engenharia de Software (SEI - Software Engineering Institute) deniu o termo mtricas e de software como um conjunto de medidas de um processo ou produto de software, onde um produto de software pode ser visto como um objeto abstrato que evolui de uma instruo inicial para o sistema ca de software nalizado, incluindo o cdigo-fonte e variadas formas de documentao produzidas durante o ca o desenvolvimento (Mills, 1998). Ento, mtricas so utilizadas para estimar um cronograma e custos a e a de desenvolvimento do software e medir a produtividade e qualidade do produto. Mtricas que facilitam o desenvolvimento de modelos capazes de estimar o processo e/ou os parmee a tros do software so consideradas boas mtricas, sendo ideal terem as seguintes caracter a e sticas (Mills, 1998):
Simplicidade: o signicado da mtrica para a avaliao claro; e ca e Objetividade; Fcil obteno: o custo de obteno da mtrica no excessivo; a ca ca e a e Validade: a mtrica efetivamente mede o que se prope a medir; e o Robustez: a mtrica no sofre grandes desvios com pequenas mudanas no processo e no software; e a c Linearidade de escala: h formas de mapeamento para o entendimento do comportamento das a

entidades atravs da manipulao dos nmeros obtidos (Fenton e Peeger, 1998). e ca u 3

2.1

Classicao das Mtricas de Software ca e

Mtricas de software podem ser classicadas quanto ao objeto das mtricas, ou seja, o mbito da e e a sua aplicao, quanto ao critrio utilizado na sua determinao e quanto ao mtodo de obteno da ca e ca e ca medida. A maneira mais ampla de classic-las quanto ao objeto da mtrica, subdividindo-as em mtricas a e e e de produtos, que medem a complexidade e tamanho nal do programa ou sua qualidade (conabilidade, manutenibilidade etc.), e em mtricas de processo, que referem-se ao processo de concepo e desenvole ca vimento do software, medindo, por exemplo, o processo de desenvolvimento, tipo de metodologia usada e tempo de desenvolvimento (Mills, 1998). Quanto aos critrios, as mtricas so diferenciadas em mtricas objetivas e mtricas subjetivas. As e e a e e objetivas so obtidas atravs de regras bem denidas, sendo a melhor forma de possibilitar comparaes a e co posteriores consistentes. Assim, os valores obtidos por elas deveriam ser sempre os mesmos, independentemente do instante, condies ou indiv co duo que os determinam. A obteno dessas mtricas ca e e pass de automatizao, como por exemplo nmero de linhas de cdigo (LOC) (Conte, Dunsmore e vel ca u o Shen, 1986). As subjetivas podem partir de valores, mas dependem de um julgamento que tambm e e um dado de entrada para ser levantadas, como por exemplo o modelo de estimativa de custo (Boehm, 1981), que depende da classicao do tipo de software (se o software embarcado, distribu etc.). ca e do Outra maneira de classicar as mtricas de software, quanto ao mtodo de obteno, dividi-las e e ca e em primitivas ou compostas (Grady e Caswell, 1987). As mtricas primitivas so aquelas que podem e a ser diretamente observadas em uma unica medida, como o nmero de linhas de cdigo, erros indicados u o em um teste de unidade ou ainda o total de tempo de desenvolvimento de um projeto. As mtricas e compostas so as combinaes de uma ou mais medidas como o nmero de erros encontrados a cada a co u mil linhas de cdigo ou ainda o nmero de linhas de teste por linha de cdigo. o u o Existem ainda classicaes que combinam as maneiras e caracter co sticas apresentadas para atribuir um tipo as mtricas. Neste trabalho vamos usar como parmetro de classicao a distino entre e a ca ca mtricas objetivas e subjetivas e consideraremos algumas mtricas de produto tambm como mtricas e e e e objetivas.

2.2

Escalas de Medio para Mtricas de Software ca e

As mtricas de software precisam ser coletadas em um modelo de dados espec e co que pode envolver clculos ou anlise estat a a stica subjetiva. Para isso, importante considerar o tipo de informao obtida. e ca Assim, quatro tipos de dados de medidas foram reconhecidos por estat sticos para as mtricas de softe ware (Conte, Dunsmore e Shen, 1986; Fenton e Peeger, 1998). A tabela abaixo mostra resumidamente o conceito e as diferenas entre os tipos de escalas de medio. c ca
Nominal: existe um nome ou um valor para um atributo; no entanto, a ordem dos valores no a

tem nenhum signicado para a sua interpretao; ca

Ordinal: os resultados esto em uma determinada ordem (ascendente ou descendente), mas a a

distncia entre os pontos dessa escala no tem signicado; a a

Intervalo: preserva a importncia da ordem dos resultados e possui informaes sobre o tamanho a co

dos intervalos que separaram os pontos da escala, mas as relaes entre valores no so necessarico a a 4

Tipo de Dados Nominal Ordinal Intervalo Racional

Operaes co =,!= <,> +, /

Descrio ca Categorias Classicao ca Diferenas c Zero Absoluto

Exemplo Dados do programa, Sistema Operacional N de experincia dos programadores vel e Complexidade Ciclomtica a Linhas de Cdigo (LOC) o

Tabela 2.2: Tipo des Escalas de Medio ca amente vlidas. Por exemplo, um programa com complexidade de valor 6 mais complexo em 4 a e unidades do que um programa com a complexidade de valor 2, mas isso no muito signicativo a e para dizer que o primeiro programa 3 vezes mais complexo do que o segundo; e
Racional: semelhante ` escala de intervalo, mas representando tambm as propores entre as a e co

entidades e possuindo um zero absoluto. Um programa de 2000 linhas pode razoavelmente ser interpretado como sendo duas vezes maior que um programa de 1000 linhas, e obviamente os programas podem ter comprimento zero, de acordo com essa medida. As escalas de medio devem estar associadas a uma dada mtrica. Muitas mtricas propostas tm ca e e e valores a partir de um intervalo, um ordinal, ou mesmo uma escala nominal. Mtricas associadas a uma e escala racional podem ser prefer veis, uma vez que uma escala racional tem mais dados que permitem aplicar operaes matemticas de forma mais signicativa. No entanto, segundo (Mills, 1998), os valores co a de vrios parmetros essenciais ao processo de desenvolvimento de software no esto associados com a a a a uma escala racional.

2.3

Mtricas de Software Tradicionais e

As mtricas de software tradicionais existentes, geralmente aplicadas de forma isolada, vm sendo e e consideradas insatisfatrias h dcadas (Mills, 1998). No passado, muitas mtricas e uma srie de o a e e e processos foram propostos (Mohanty, 1981; Kafura e Canning, 1985; Kemerer, 1987; Rubin, 1987), mas a maioria das mtricas denidas no possuem uma base terica suciente e/ou uma signicativa e a o validao experimental. Em sua maioria, cada uma delas foi denida por um indiv ca duo e, em seguida, testada e utilizada em apenas um ambiente, provavelmente limitado. Segundo (Mills, 1998), em alguns casos, exitem relatos signicativos de validao ou de aplicao dessas mtricas. No entanto, outros ca ca e testes ou o seu uso em ambientes diferentes tm produzido resultados no esperados. Essas diferenas e a c no so surpreendes, uma vez que faltam denies claras e hipteses de testes bem denidas. a a co o Assim, existe um grande nmero de mtricas, mas apenas algumas tm sido amplamente utilizau e e das ou aceitas. Mesmo nos casos das mtricas amplamente estudadas, como o nmero de linhas de e u cdigo (LOC), mtricas de Halstead e Complexidade Ciclomtica, no so universalmente medidas de o e a a a comum acordo. Estudos relatam experincias que tentam correlacionar as mtricas com um nmero e e u de propriedades de software, incluindo o tamanho, complexidade, conabilidade, nmero de erros e u manutenibilidade (Curtis et al., 1979; Curtis, Sheppard e Milliman, 1979; Kafura e Canning, 1985; Li e Cheung, 1987; Potier et al., 1982; Woodeld, Shen e Dunsmore, 1981). Outras mtricas que podem ser relevantes, como o tipo de produto e o n de conhecimento do e vel programadores, so exemplos de mtricas subjetivas, porm dif a e e ceis de se especicar e com problemas ligados ` avaliao de fatores individuais. a ca 5

Outro obstculo vem do fato de que dif interpretar e comparar resultados das mtricas, esa e cil e pecialmente se elas envolvem diferentes ambientes, linguagens, aplicaes e/ou metodologias de deco senvolvimento. Como consequncia, no existem processos ou modelos de aplicao de mtricas com e a ca e bases tericas relevantes. A maioria baseada na combinao de intuio, caracter o e ca ca sticas particulares e anlise estat a stica de dados emp ricos (Mills, 1998). Mais um problema ocorre quando se usa mtricas simples, como as que envolvem linhas de cdigo e o (LOC), pois diferenas tcnicas, como diferentes linguagens de programao, inuem na contagem e c e ca podem impossibilitar a comparao dos resultados (Jones, 1986). ca Entretanto, mesmo com os problemas levantados, ponderadamente, quando se tem mtodos de e aplicao de mtricas de software em um ambiente limitado, poss auxiliar, de forma signicativa, na ca e e vel melhoria da qualidade do software e da produtividade (Basili e Rombach, 1987; Grady e Caswell, 1987). Em muitos casos, mtricas relativamente simples, como linhas de cdigo e complexidade ciclomtica e o a foram relativamente bons preditores de outras caracter sticas, como nmero de erros, esforo total e u c manutenibilidade (Grady e Caswell, 1987; Li e Cheung, 1987; Rombach, 1987). Embora uteis, essas mtricas no podem ainda ser utilizadas indiscriminadamente, mas a aplicao cuidadosa de algumas e a ca das mtricas e modelos dispon e veis podem produzir resultados uteis, se de acordo com o ambiente espec co (Mills, 1998).

2.3.1

Mtricas Objetivas e

Boa parte das mtricas objetivas, conforme a denominao deste trabalho, tratam caracter e ca sticas do cdigo-fonte. Uma srie de trabalhos deu in `s abordagens como tamanho do programa e complexio e cio a dade do software (Troy e Zweben, 1981; Henry e Kafura, 1984; Yau e Collofello, 1985). Existe uma boa quantidade de mtricas desses tipos; por exemplo, so referidas e comparadas 31 mtricas de complee a e xidade diferentes em (Li e Cheung, 1987) e foram propostas novas mtricas de complexidade em (Card e e Agresti, 1988; Harrison e Cook, 1987). Um nmero de mtricas objetivas mais referenciadas e conheu e cidas do estado da arte de mtricas de software ser tratado nas subsees a seguir. Sero discutidas e a co a as mtricas que reetem as reas em que a maioria dos trabalhos sobre mtricas foram realizados. e a e Mtricas de Dimenso de Software e a Algumas mtricas de software foram desenvolvidas para tentar quanticar o tamanho do software e e auxiliar as medies na fase de concepo do software, ou seja, partindo dos princ co ca pios de um processo de desenvolvimento tradicional.
Linhas de Cdigo (LOC) o

Possivelmente a mais usada para medir o tamanho do programa. Aparentemente de fcil dee a nio e preciso; entretanto, h uma srie de pontos particulares para o nmero de linhas de ca a a e u cdigo em um determinado programa. Essas particularidades de tratamento envolvem linhas em o branco, linhas de comentrio, trechos no-executveis, mltiplas declaraes por linha e vrias a a a u co a linhas por declarao, assim como a questo das linhas de cdigo repetidas ou reusadas. O conca a o ceito mais comum de LOC parte do princ pio de contar qualquer linha que no seja linha em a branco ou comentrio, independentemente do nmero de declaraes por linha (Boehm, 1981; a u co Jones, 1986), s podendo ser comparados valores diferentes dessa mtrica caso elas se referirem ` o e a mesma linguagem e se o estilo de programao estiver normalizado (Jones, 1991). ca 6

LOC foi atribu como preditor de complexidade do software, esforo total de desenvolvimento e da c desempenho do programa (depurao e produtividade). Estudos tentaram validar esses relacionaca mentos, como (Woodeld, Shen e Dunsmore, 1981) comparando LOC, complexidade ciclomtica a e mtricas de Halstead (os dois ultimo sero tratados nas prximas subsees) como indicadores e a o co de esforo de programao, assim como em (Curtis et al., 1979; Curtis, Sheppard e Milliman, c ca 1979), usando LOC para comparao com outras mtricas como indicadores de desempenho do ca e programador. Outro estudo (Levitin, 1986) concluiu que LOC uma medida de tamanho de e software mais pobre que o comprimento de programa de Halstead.
Pontos de Funo (FP) ca

Baseado nos modelos e ciclos de vida tradicionais de desenvolvimento de software foi proposta uma medida de tamanho de software que pode ser estimada no in cio do desenvolvimento. A mtrica calcula o valor total Pontos de Funo para o projeto (Albrecht e Ganey, 1983), que tem e ca com parmetros o nmero de entradas do usurio, as consultas, sa a u a das e os principais arquivos. O valor dos FP a soma desses valores individuais, com as seguintes ponderaes aplicadas: e co Entradas = 4; Sa das = 5; Consultas = 4; Principais Arquivos = 10. Entretanto, cada parmetro pode ser ajustado dentro de um intervalo de 35% de acordo com o a projecto (Albrecht e Ganey, 1983). Essa mtrica foi validada em alguns trabalhos, comparando o e LOC e PF como preditores de esforo de desenvolvimento (Albrecht e Ganey, 1983) e relacionam c PF com a produtividade em um ambiente desenvolvimento (Behrens, 1983). Mas outro estudo analisou o conjunto de dados usados no primeiro trabalho citado e concluiu que PF por si s o insucientemente precisa para a predio de esforo de desenvolvimento de software (Kna e e ca c Sacks, 1986).
System Bag

E uma medida de dimenso total de um software determinada a partir das funcionalidades desa critas em especicaes formais (DeMarco, 1982). O algoritmo de clculo se difere por se aplicar co a a sistemas orientados por dados ou orientados por processos. Um dos objetivos dessa mtrica e e maximizar o quociente Bag/Custo total no desenvolvimento do projeto. Mtricas de Halstead e E um conjunto de mtricas baseadas na teoria da informao, consideradas as primeiras mtricas e ca e com fundamentao terica comum, tambm chamada de Software Science (Halstead, 1972, 1977). Esca o e sas mtricas se aplicam a vrios aspectos do software, diferentemente da maior parte das mtricas, que e a e tratam um aspecto particular, e tambm so usadas para avaliar o esforo global de desenvolvimento e a c do software. O Vocabulrio (n), Comprimento (N) e Volume (V) so mtricas que aplicam-se especia a e camente ao software nal. Tambm foram especicadas frmulas para calcular o esforo total (E) e e o c tempo de desenvolvimento (T) de software. 7

 Vocabulrio do Programa a

O software pode ser visualizado com uma seqncia de s ue mbolos (tokens), sendo cada s mbolo classicado em operadores ou operandos. Assim, o vocabulrio do programa (n) denido como: a e n = n1 + n2 , onde n1 o nmero de operadores unicos e n2 o nmero de operandos unicos do programa. e u e u
Comprimento do Programa

Enquanto o vocabulrio a soma dos s a e mbolos (tokens) diferentes, o comprimento do programa (N ) a soma do total de operadores e operandos, sendo dado como: e N = N1 + N2 , onde N1 o nmero total de operadores e N2 o nmero total de operandos do programa. e u e u Porm, a distino entre operadores e operandos no muito clara (Halstead, 1977). Ento o e ca a e a valor N pode ser estimado como: N = n1 log(n1 ) + n2 log(n2 ) Sendo N uma medida que pode ser observada ao nal do desenvolvimento do cdigo, diferenteo mente de N que pode ser calculada em funo dos atuais ou estimados valores de n1 e n2 . Estudos ca emp ricos demonstram a validade da equao mostrada (Elsho, 1976; Halstead, 1977). Outros ca estudos relacionaram N e N com outras mtricas, como complexidade (Potier et al., 1982) e e nmero de erros (Elsho, 1976; Halstead, 1977; Shen et al., 1985; Levitin, 1986; Li e Cheung, u 1987). E defendido que a mtrica de comprimento mais objetiva e eciente que o LOC (Lassez e e et al., 1981).
Volume do Programa

O volume de um programa, medido em bits, dado em funo do seu comprimento e do seu e ca vocabulrio: a V = N log(n). Determinar o volume no dif pois no envolve anlise semntica. Porm, a soma do volume a e cil, a a a e dos mdulos de um programa diferente em relao ` soma total do volume do software, devido o e ca a a variao do vocabulrio. H anlises sobre a abrangncia da medida do volume do software, ca a a a e destacando a independncia em relao ` linguagem de programao utilizada (Shen, Conte e e ca a ca Dunsmore, 1983). Foram apresentadas evidncias emp e ricas de que as mtricas de comprimento e e de volume de Halstead esto linearmente relacionadas com a LOC (Li e Cheung, 1987; Christensen, a Fitsos e Smith, 1981).

Mtricas de Complexidade de Software e Assim como as mtricas de dimenso de software, as mtricas de complexidade foram pensadas de e a e acordo com os modelos tradicionais de desenvolvimento e podem ser computadas no in do ciclo de cio desenvolvimento de software, para o maior sucesso na gerncia do processo de software. e
Complexidade Ciclomtica (v(G)) a

Parte do princ pio que a complexidade depende do nmero de condies (caminhos), corresponu co dendo ao nmero mximo de percursos linearmente independentes em um software. A proposta u a e que se possa medir a complexidade do programa, assim orientando o desenvolvimento e os testes do software (McCabe, 1976). Essa mtrica pode ser representada atravs de um grafo de uxo e e de controle, onde os ns representam uma ou mais instrues seqenciais e os arcos orientados o co u indicam o sentido do uxo de controle entre vrias instrues. A complexidade ciclomtica de um a co a determinado grafo pode ser calculada atravs de uma frmula da teoria dos grafos: e o v(G) = e n + 2 onde e o nmero de arestas e n o nmero de ns do grafo. e u e u o Um estudo concluiu que a produtividade diminui de forma no linear proporcionalmente ao aua mento da densidade dos pontos condicionais (Ganey, 1979). A complexidade ciclomtica tambm a e foi relacionada com os esforos de depurao e manuteno, podendo ser utilizada para estimar c ca ca custos a partir do projeto detalhado dos mdulos (Curtis, Sheppard e Milliman, 1979; Woodeld, o Shen e Dunsmore, 1981; Harrison et al., 1982). Surgiram propostas de extenses e alteraes no clculo dessa mtrica para melhorar a sua validade o co a e (Myers, 1977; Stetter, 1984). Myers observou que complexidade ciclomtica mede a complexidade a do software, mas no consegue diferenciar a complexidade de alguns casos simples, em especial a que envolvam uma unica condio. Para melhorar a frmula original, foi sugerido: ca o v(G) = [l : u] onde l e u so limites inferiores e superiores, respectivamente, para a complexidade, sendo mais a satisfatrios para os casos vericados por Myers. Por outro lado, Stetter props que o grafo fosse o o expandido para incluir declaraes e referncias de dados, mostrando uma complexidade mais co e completa. Nesse grafo do uxo do programa (H), geralmente, tem mltiplos ns de entradas e u o sa das. Assim, as irregularidades vericadas por Myers so eliminadas por uma funo f (h). a ca Uma correlao entre a complexidade ciclomtica e as mtricas de Halstead foi apresentada em ca a e (Henry, Kafura e Harris, 1981). O interesse na mtrica de complexidade ciclomtica levou ` sua e a a normalizao (McCabe, 1982). Posteriormente, McCabe deniu outras cinco mtricas: complexica e dade da unidade real, complexidade essencial, complexidade do projeto de mdulos, complexidade o total do projeto e complexidade de integrao (McCabe e Butler, 1989). Essas mtricas foram utica e lizadas para identicar e minimizar a complexidade em cdigos no estruturados, decidindo sobre o a o nmero de testes necessrios para uma cobertura total das poss u a veis execues, eliminando a co redundncia e restringindo a complexidade de mdulos produzidos a um n aceitvel (Mannino, a o vel a Stoddard e Sudduth, 1990). 9

 Nmero de Ns u o

Corresponde ao nmero de ns em um grafo de uxo de controle que representa a sequncia de u o e controle de execuo de instrues num programa (Woodward, Hennell e Hedley, 1979). Um n ca co oe denido como uma passagem necessria das linhas direcionais no grafo, sendo assim uma proposta a de mtricas de complexidade de software. e
Fluxo de Informaao c

Foi proposto que os uxos de informaes na estrutura de um programa so medidas de compleco a xidade de software (Kafura e Henry, 1981), sendo comparadas com a complexidade ciclomtica e a mtricas de Halstead. Esse mtodo conta o nmero de parmetros de entradas (fan-in) e sa e e u a das (fan-out), sendo denido como: c = [tamanhoM etodo] [f an in f an out]2 Uma experincia de validao dessa mtrica foi realizada na concepo e desenvolvimento de e ca e ca um ncleo para o sistema operacional UNIX (Henry e Kafura, 1984). Experincias combinando a u e utilizao de uxo de informao com vrias outras mtricas foram realizadas tambm em (Kafura ca ca a e e e Canning, 1985; Kafura e Reddy, 1987). Alm disso, uxo de informao tambm permite estimar e ca e com uma certa preciso o esforo de manuteno (Rombach, 1987). a c ca Mtricas de Qualidade de Software e Corretude, ecincia, portabilidade, conabilidade, usabilidade, modularidade, grau de reutilizao e ca e facilidade de manuteno (manutenibilidade) so caracter ca a sticas ligadas ` qualidade de software (Boa ehm, Brown e Lipow, 1976; McCall, Richards e Walters, 1977; Basili, 1980). Provavelmente, em alguns casos, algumas dessas medidas se sobrepem ou so antagnicas, como a ecincia e a portabilidade o a o e Mills (1998). Para se ter portabilidade pode-se abrir mo da ecincia, e exemplos como esse mostram a e que dif encontrar uma mtrica que quantique a qualidade globalmente. Mtricas para a qualie cil e e dade na fase de projeto tambm foram propostas h dcadas (Myers, 1975; Yin e Winchester, 1978). e a e Qualidade uma caracter e stica que, nos modelos tradicionais de desenvolvimento de software, pode ser medida em cada fase do ciclo de desenvolvimento de software (Cerino, 1986), mas no sero abordadas a a mtricas espec e cas do processo de desenvolvimento neste trabalho. Os primeiros estudos sobre mtricas demonstram mais relatos e experincias com mtricas de die e e menso e complexidade; posteriormente algumas reas que tratam as caracter a a sticas de qualidade de software citadas foram investigadas. A seguir sero apresentados alguns desse estudos: a
Mtricas de Funcionalidade e

Um estudo relevante na dcada passada sobre caracter e sticas da funcionalidade de software foi realizado pelo SUMI (Software Usability Measurement Inventory) (Kirakowski, Porteus e Corbett, 1992), denindo funcionalidade como a capacidade de um software ser usado com ecincia e e satisfao para atingir objetivos espec ca cos em um determinado ambiente. Pode-se destacar as seguintes caracter sticas sobre a funcionalidade do software: Facilidade de aprendizagem: capacidade de um usurio atingir rapidamente um grau de a procincia elevada; e 10

 Usabilidade: capacidade do software interagir amigavelmente com os usurios; a Controle: capacidade de um produto em responder de uma forma natural e consistente aos comandos e entradas de dados fornecidos; Utilidade: capacidade de resolver ou ajudar a resolver problemas para os quais o software foi proposto; Ecincia: capacidade de resolver problemas de forma rpida e econmica. e a o Uma questo em aberto nesse tipo de mtrica como obter uma escala de medio com valores a e e ca absolutos, o que as torna medidas com um grau de subjetividade.
Mtricas de Manuteno Corretiva e ca

Erros encontrados no sistema e a sua eliminao rpida so pontos sens ca a a veis na avaliao da ca qualidade do software. Mtricas foram denidas para medir ou prever a manutenibilidade do e software (Yau e Collofello, 1980, 1985), e tambm foram estudadas as possibilidades das mtricas e e de Halstead e complexidade ciclomtica para prever complexidade das tarefas de manuteno de a ca software (Curtis et al., 1979; Harrison et al., 1982; Rombach, 1987; Kafura e Reddy, 1987) Entre os resultados esto tanto o fato de as mtricas de complexidade poderem ser utilizadas de forma a e ecaz para explicar ou prever a manuteno de software em sistemas distribu ca dos quanto a relao ca observada entre 7 diferentes mtricas de complexidade para medir as atividades de manuteno em e ca um sistema que evoluiu durante 3 anos. Nesse segundo experimento foram observadas 3 verses o diferentes do mesmo software, medindo-se a complexidade interna dos mdulos de software e a o complexidade das inter-relaes entre os mdulos de software. Entre as mtricas objetivas citadas co o e esto: a Nmero de erros detectados no cdigo; u o Nmero de erros detectados por aplicao de uma bateria de testes; u ca Nmero de erros detectados pelos usurios; u a Tempo mdio de resposta na resoluo de problemas detectados; e ca Nmero de mudanas de projeto; u c Nmero de alteraes no cdigo fonte. u co o
Mtricas de Conabilidade e

So mtricas para estimar e dimensionar o esforo de depurao, como, por exemplo, a quantidade a e c ca de testes a aplicar, partindo das mtricas de manuteno corretiva (Ruston, 1979; Basili, 1980; e ca Musa, Iannino e Okumoto, 1987). Mtricas t e picas desse tipo so: a MTTF - Mean Time To Fail : a probabilidade de uma falha ocorrer num intervalo de tempo especicado; MTBF - Medium Time Between Failures: o tempo mdio entre falhas. e Existem modelos para descrever a ocorrncia de erros em funo do tempo, permitindo denir a e ca conabilidade e o MTTF. Partindo dos pressupostos: 11

 Entradas de teste so exemplos aleatrios de entradas no sistema; a o Todos os erros de software so observados; a Intervalos de erros so independentes uns dos outros; a MTBF exponencialmente distribu e do. Assim, a seguinte equao foi denida: ca d(t) = D(1 (e)exp(bct)) onde: D o total de nmero de erros; e u b e c so constantes determinadas pelo tipo de software ou de um software similar; a d(t) o nmero total de erros detectados no tempo t: e u M T T F (t) = ((e)exp(bct))/cD Determinar b, c e D, que no uma tarefa bvia, pode estabelecer o sucesso da aplicao desse a e o ca modelo de mtrica de conabilidade (Ruston, 1979; Basili, 1980; Musa, Iannino e Okumoto, 1987). e Tambm existem estudos relacionando a conabilidade com mtricas de dimenso e complexidade, e e a como as de Halstead e de complexidade ciclomtica (Potier et al., 1982; Shen et al., 1985). Os a trabalhos mais clssicos nessa rea relacionam as mtricas de complexidade com a manuteno a a e ca (Curtis et al., 1979; Harrison et al., 1982; Rombach, 1987), medindo a complexidade em cada mdulo e as inter-relaes entre eles. A correlao entre a complexidade e a manuteno pode ser o co ca ca assim explorada no sentido de conseguir a reduo dos custos de manuteno (Yau e Collofello, ca ca 1980, 1985; Kafura e Reddy, 1987; Brown et al., 1989; Takahashi e Kamayachi, 1989; Gorla, Benander e Benander, 1990).

2.3.2

Outras Mtricas Tradicionais e

Existem ainda outras mtricas de software tradicionais razoavelmente difundidas alm das mencioe e nadas; elas no sero abordadas neste trabalho em detalhes porque se aproximam conceitualmente de a a alguma das anteriores detalhadas, ou ainda so corelacionadas como prescursoras de algumas mtricas a e que sero apresentadas dentro do contexto de orientao a objetivos na prxima seo. As mais comuns a ca o ca entre elas so: a
Dados Compartilhados (BAM - Binding Among Modules): mede o volume de dados compartilha-

dos entre diferentes mdulos do programa (Basili e Turner, 1975; Henry e Kafura, 1981). o
Tamanho Mdio dos Mdulos (AML - Average Module Length): mede o tamanho mdio dos e o e

mdulos que compem o programa (Boehm et al., 1978). o o

Condies e Operaes (COC - Conditions and Operations Count): contabiliza os pares de todas co co

condies e laos nas operaes (Hansen, 1978). co c co 12

 Razo de Coeso (CRM - Cohesion Ratio Metrics): mede a relao entre o nmero de mdulos a a ca u o

com coeso funcional e o nmero total de mdulos (Yourdon e Constantine, 1979; Macro e Buxton, a u o 1987; Bieman e Ott, 1994).
Uso de Varivel (LVA - Live Variables): mede o per a odo em que cada varivel usada (Dunsmore a e

e Gannon, 1979).
Menor Nmero de Caminho (MNP - Minimum Number of Paths): mede o menor nmero de u u

caminhos em um programa e seu alcance em qualquer n (Schneidewind e Homann, 1979). o

Mtricas Morfolgicas (MOR - Morphology metrics): mede caracter e o sticas morfolgicas de um o

mdulo, como tamanho, profundidade, largura e razo entre aresta e n. (Yourdon e Constantine, o a o 1979).
Complexidade de Fluxo de Controle e de Dados (CDF - Control ow complexity and Data Flow

complexity): combinao de mtricas baseadas na denio de variveis e de referncias cruzadas ca e ca a e (Oviedo, 1980).
Nmero de Funes (FCO - Function Count): mede o nmero de funes e as linhas de cdigo u co u co o

das funes (Smith, 1980). co

Mtrica de Complexidade Composta (SSC - composite metric of Software Science and Cyclomatic e

complexity): combina as mtricas de Halstead com Complexidade Ciclomtica (Baker e Zweben, e a 1980).
Instrues no Cdigo (DSI - Delivered Source Instructions): Conta declaraes separadas numa co o co

mesma linha como distintas e ignora linhas de comentrios (Boehm, 1981). a

Equivalncia entre Mdulos (ESM - Equivalent Size Measure): mede o percentual de modicaes e o co

num mdulo reutilizado (Boehm, 1981). o

Declaraes Executveis (EST - Executable Statements): contabiliza declaraes separadas em co a co

uma linha de cdigo como distintas, ignorando comentrios, declaraes de variveis e cabealhos o a co a c (Boehm, 1981).
N veis de Aninhamento (NLE - Nesting Levels): mede a complexidade pela profundidade de

aninhamentos (Zolnowski e Simmons, 1981).

Mtricas de Peso Espec e co (SWM - Specication Weight Metrics): mede funes primitivas num co

diagrama de uxo de dados (DeMarco, 1982). Distncia de Arvore (TRI - Tree Impurity): determina o quanto um grafo se distanciou de uma a a rvore (Ince e Hekmatpour, 1988).
Modularidade Global (GLM - Global Modularity): descrio da modularidade global em termos ca

de vrias vises espec a o cas de modularidade (Hausen, 1989).

Relao de Acoplamento (COR - Coupling Relation): sinaliza uma relao de todo par de mdulos ca ca o

segundo o tipo de acoplamento (Fenton e Melton, 1990).

13

 Extenso de Reuso (ERE - Extent of Reuse): classica um mdulo segundo o grau de reuso a o

(Ganey, Felber e Erling, 1995).

2.4

Mtricas de Orientao a Objetos e ca

Alm das mtricas anteriormente discutidas, existem mtricas voltadas especicamente a aspectos e e e relevantes no contexto da programao orientada a objetos. As mtricas apresentadas nesta seo foram ca e ca selecionadas a partir de uma anlise das mtricas propostas para orientao a objetos especicamente a e ca uma parte das mais conhecidas mtricas, divididas 5 em categorias simples para (Xenos et al., 2000). E e um melhor entendimento do conceito das mesmas: mtricas de classe, mtricas de mtodos, mtricas e e e e de herana, mtricas de acoplamento e mtricas do sistema (caracter c e e sticas gerais do software orientado a objetos). Mtricas de Classes e
Encapsulamento dos Atributos (AHF - Attribute Hiding Factor): razo entre a soma de todos os a

atributos herdados de todas as classes do sistema em considerao ao nmero total de atributos ca u das classes dispon veis (Morris, 1988).
Mtodos Reusados (PMR - Percent of Potential Method uses actually Reused): percentual de e

reuso dos mtodos da classe (Morris, 1988). e

Coeso de Classe (CCO - Class Cohesion): mede a relao entre as classes (Chidamber e Kemerer, a ca

1991).
Nmero de Ancestrais (NOA - Number Of Ancestors): nmero total de ancestrais de uma classe u u

(Kolewe, 1993).
Ponderao do Tamanho da Classe (WCS - Weighted Class Size): nmero de ancestrais mais o ca u

tamanho total de mtodos da classe (Kolewe, 1993). e

Respostas para uma Classe (RFC - Response For a Class): nmero de mtodos dentre todos os u e

mtodos que podem ser invocados em resposta a uma mensagem enviada por um objeto de uma e classe (Sharble e Cohen, 1993).
Linhas de comentrio por Mtodo (CLM - Comment Lines per Method): mede o percentual de a e

comentrios no mtodo (Lorenz e Kidd, 1994). a e

Porcentagem de Mtodos Comentados (PCM - Percentage of Commented Methods): percentual e

de mtodos com comentrios em uma classe (Lorenz e Kidd, 1994). e a

Cdigo Orientado a Funo (FOC - Function Oriented Code): mede o percentual de cdigo no o ca o a

orientado a objeto usado no programa (Lorenz e Kidd, 1994).

Nmero de Mtodos de Classe em uma Classe (NCM - Number of Class Methods in a class): u e

mede os mtodos dispon e veis em uma classe, mas no em suas instncias (Lorenz e Kidd, 1994). a a
Nmero de Variveis de Instncia em uma Classe (NIV - Number of Instance Variables in a class): u a a

mede a relao de uma classe com outro objeto do programa (Lorenz e Kidd, 1994). ca 14

 Falta de Coeso entre Mtodos (LCM - Lack of Cohesion between Methods): indica o n a e vel de

coeso entre os mtodos (Chidamber e Kemerer, 1994). a e

Privacidade Interna (INP - Internal Privacy): refere-se ao uso de funes de acesso ` classe, co a

incluindo as chamadas da prpria classe (Chidamber e Kemerer, 1994) . o

Dados Pblicos (PDA - Public Data): contabiliza o nmero de acessos aos dados protegidos e u u

pblicos de uma classe (McCabe, Dreyer e Watson, 1994). u

Percentual de Dados Pblicos (PPD - Percentage of Public Data): o percentual de dados pblicos u e u

de uma classe (McCabe, Dreyer e Watson, 1994).

Mtodos ponderados por Classe (WMC - Weighted Methods per Class): soma ponderada de todos e

os mtodos da classe (McCabe e Associates, 1994). e

Nmero de Parmetros por Mtodos (NPM - Number of Parameters per Method): nmero mdio u a e u e

de parmetros por mtodo (Bansiya e Davi, 1997). a e

Entropia de Complexidade da Classe (CEC - Class Entropy Complexity): mede a complexidade

da classe, baseada no contedo de suas informaes (Bansiya e Davi, 1997). u co

Mtrica de Acesso aos Dados (DAM - Data Access Metric): razo do nmero de atributos privados e a u

em relao ao nmero total de atributos declarados na classes (Bansiya e Davi, 1997). ca u

Medida de Abstrao dos Atributos (MAA - Measure of Attribute Abstraction): razo do nmero ca a u

de atributos herdados por uma classe em relao ao nmero total de atributos na classes (Bansiya ca u e Davi, 1997).
Medida de Abstrao das Funes (MFA - Measure of Functional Abstraction): razo entre o ca co a

nmero de mtodos herdados por uma classe em relao ao nmero total de mtodos acess u e ca u e veis na classe (Bansiya e Davi, 1997) .
Nmero de Tipos de Dados Abstratos (NAD - Number of Abstract Data types): nmero de objetos u u

denidos pelo usurio como atributos de uma classe que so necessrios para instanciar um objeto a a a da referida classe (Bansiya e Davi, 1997).
Nmero de Atributos Pblicos (NPA - Number of Public Attributes): contabiliza o nmero de u u u

atributos declarados como pblicos em uma classe (Bansiya e Davi, 1997). u

Nmero de Referncias como Atributo (NRA - Number of Reference Attributes): contabiliza o u e

nmero de ponteiros e referncias passadas como atributos de uma classe (Bansiya e Davi, 1997). u e
Encapsulamento dos Mtodos (MHF - Method Hiding Factor ): razo entre a soma de todos os e a

mtodos invis e veis em todas as classes em relao ao nmero total de mtodos denidos em um ca u e determinado sistema (Harrison, 1998).

15

Mtricas de Mtodos e e
Mdia de Complexidade dos Mtodos (AMC - Average Method Complexity): soma da complexie e

dade ciclomtica de todos os mtodos dividido pelo nmero total de mtodos (Morris, 1988). a e u e
MAG (MAX V(G)): complexidade ciclomtica mxima dos mtodos de uma classe (McCabe, a a e

Dreyer e Watson, 1994).

Mdia do Tamanho dos Mtodos (AMS - Average Method Size): mede o tamanho mdio dos e e e

mtodos do programa (Lorenz e Kidd, 1994). e

Complexidade do Mtodo (MCX - Method Complexity): relaciona a complexidade com o nmero e u

de mensagens (Lorenz e Kidd, 1994). Mtricas de Acoplamento e

Acoplamento Aferente (AC - Aerent Coupling): nmero total de classes externas de um pacote u

que dependem de classes de dentro desse pacote. Quando calculada no n da classe, essa medida vel tambm conhecida como Fan-in da classe, medindo o nmero de classes das quais a classe e e u e derivada e, assim, valores elevados indicam uso excessivo de herana mltipla (McCabe, Dreyer e c u Watson, 1994).
Acoplamento Eferente (EC- Eerent Coupling ou EC): nmero total de classes dentro de um u

pacote que dependem de classes externas ao pacote. Quando calculada no n vel da classe, essa medida tambm conhecida como Fan-out da classe, ou como Acoplamento entre Objetos (CBO e e - Coupling Between Objects) na fam de mtricas de CK (Chidamber-Kemerer) (Chidamber e lia e Kemerer, 1994).
Acoplamento de Classe (CP - Class Coupling): mede as relaes entre as classes com base em co

suas trocas de mensagens (Basili, Briand e Melo, 1996).

Fator de Acoplamento (CFA - Coupling Factor): razo entre o nmero mximo poss de acoa u a vel

plamentos no sistema e o nmero atual de acoplamento poss u veis por herana (Harrison, 1998). c Mtricas de Herana e c
Construo Efetiva (FEF - Factoring Eectiveness): nmero de mtodos unicos dividido pelo ca u e

nmero total de mtodos (Morris, 1988). u e

Potencial de Mtodos Sobrescritos (PMO - Percent of Potential Method uses Overridden): pere

centual de mtodos sobrescritos utilizados (Morris, 1988). e

N vel de Aninhamento Hierrquico da Classe (HNL - Class Hierarchy Nesting Level): mede a a

profundidade de hierarquia em que cada classe est localizada (Lorenz, 1991). a

Mtricas de Reuso de Mtodo (MRE - Method Reuse metrics): indica o n de reuso dos mtodos e e vel e

(Abreu e Carapuca, 1994).

Nmero de Mtodos Herdados (NMI - Number of Methods Inherited): mede o nmero de mtodos u e u e

que uma classe herda (Lorenz e Kidd, 1994). 16

 Medida de Polimorsmo (PFA - Polymorphism Factor ): razo entre o nmero atual de possibia u

lidades de polimorsmo diferentes de uma classe e o nmero mximo de poss u a veis polimorsmos distintos da referida classe (Abreu, 1994).
Nmero de Mtodos Sobrescritos (NMO - Number of Methods Overridden): nmero de mtodos u e u e

redeclarados pela classe herdeira (Lorenz e Kidd, 1994).

Tipo de Especializao (SIX - Specialisation Index): indica o tipo de especializao (Lorenz e ca ca

Kidd, 1994).
Medida de Herana de Atributos (AIF - Attribute Inheritance Factor): razo entre a soma dos c a

atributos herdados em todas as classes do sistema e o nmero total de atributos dispon u veis na classe (Basili, Briand e Melo, 1996). Profundidade da Arvore de Herana (DIT - Depth of Inheritance Tree): mede o nmero de c u ancestrais de uma classe (Shih et al., 1997).
Nmero de Filhos (NOC - Number Of Children): nmero total de lhos de uma classe (Rosenberg u u

e Hyatt, 1997).
Proporo de Reuso (RER - Reuse Ratio): razo entre o nmero de superclasses dividida pelo ca a u

nmero total de classes (Rosenberg e Hyatt, 1997). u

Proporo de Especializao (SPR - Specialisation Ratio): razo entre o nmero de subclasses ca ca a u

dividido pelo nmero de superclasses (Rosenberg e Hyatt, 1997). u

Medida de Herana de Mtodo (MIF - Method Inheritance Factor): razo entre a soma dos c e a

mtodos herdados em todas as classes e o nmero total de mtodos dispon e u e veis em todas as classes (Harrison, 1998).
Proporo entre Profundidade e Largura (RDB - Ratio between Depth and Breadth): razo entre ca a

a profundidade e a largura da hierarquia de classes (Bellin, Tyagi e Tyler, 1999). Mtricas do Sistema e
Granularidade da Aplicao (APG - Application Granularity): nmero total de objetos dividido ca u

pelo nmero total de pontos de funo (Morris, 1988). u ca

Ecincia da Biblioteca de Objeto (OLE - Object Library Eectiveness): razo entre o nmero e a u

total de objetos reusados e o nmero total de objetos da biblioteca (Morris, 1988). u

Complexidade Associada (ASC - Association Complexity): mede a complexidade da estrutura

associada ao sistema (Kolewe, 1993).

Nmero de Hierarquias (NOH - Number Of Hierarchies): nmero de hierarquias distintas do u u

sistema (Kolewe, 1993).

Reuso de Classe (CRE - Number of time a Class is Reused): mede as referncias a uma classe e e

o nmero de aplicaes que reusam tal classe (Abreu e Carapuca, 1994). u co

17

 Nmero de Rejeio de Classe (NCT - Number of Classes Thrown away): mede o nmero de u ca u

vezes que uma classe rejeitada at que seja aceita (West, 1992; Lorenz e Kidd, 1994). e e
Problemas Relatados por Classe (PRC - Problem Reports per Class): mede os relatos de erros da

classe (Lorenz e Kidd, 1994).

Reuso do Sistema (SRE - System Reuse): percentual de reuso de classes (Abreu e Carapuca,

1994).
Categorizao (CAN - Category Naming): divide as classes em um conjunto semanticamente ca

signicativo (Chidamber e Kemerer, 1994).

Profundidade Mdia de Herana (ADI - Average Depth of Inheritance): diviso entre a soma de e c a

n veis de aninhamento de todas as classes pelo nmero de classes (Bansiya e Davi, 1997). u
Mdia de Ancestrais (ANA - Average Number of Ancestors): determina o nmero mdio de e u e

ancestrais de todas as classes (Bansiya e Davi, 1997).

Densidade Funcional (FDE - Functional Density): razo entre o nmero de linhas de cdigo e a u o

pontos de funo (Fenton e Peeger, 1998). ca

Modicao de Objetos Reusados (PRO - Percent of Reused Objects Modied): percentual de ca

objetos reusados que foram modicados (Bellin, Tyagi e Tyler, 1999).

2.5

Medidas Aplicadas aos Mtodos Ageis e

Foram listadas e denidas algumas medida para auxiliar o acompanhamento de uma equipe gil a (Sato e Goldman, 2007), de acordo com abordagens para escolha das melhores mtricas possam ser e utilizadas nas matodologias geis. Entre mtricas apresentadas esto exemplos das que podem ser a e a coletadas de forma automatizada, por serem compostas de medidas quantitativas e objetivas. Dessas, algumas j foram explicadas neste trabalho, como: a
Linhas de Cdigo; o Complexidade Ciclomtica; a Mtodos Ponderados por Classe; e Falta de Coeso dos Mtodos; a e

Profundidade da Arvore de Herana; c

Nmero de Filhos; u Acoplamento Aferente; Acoplamento Eferente.

Outras medidas objetivas, no citadas neste trabalho, foram apresentadas em (Sato e Goldman, a 2007)como uteis prover o uso ecaz de mtricas de software no desenvolvimento com metodologias e a geis, como a seguir: 18

 Total de Linhas de Cdigo de Teste (TLCT): representa o nmero total de pontos de teste do o u

sistema (Dubinsky et al., 2005). Um ponto de teste considerado como um passo do cenrio de um a teste de aceitao, automatizado ou como uma linha de cdigo de teste de unidade automatizado, ca o descartando linhas em branco e comentrios. a
Nmero de Linhas Alteradas: representa o nmero de linhas (no apenas cdigo-fonte) adicionau u a o

das, removidas e atualizadas no Repositrio de Cdigo Unicado. o o

Nmero de Commits representa o nmero de commits efetuados no Repositrio de Cdigo Uniu u o o

cado.
Estimativas Originais: representa o total de pontos (ou horas) originalmente estimadas pela equipe

para todas as Histrias da iterao. o ca

Estimativas Finais: representa o total de pontos (ou horas) efetivamente reportadas como gastas

para implementar as Histrias da iterao. o ca

Nmero de Histrias Entregues: representa o nmero total de Histrias implementadas e aceitas u o u o

pelo cliente.
Nmero de Pontos Entregues: representa o nmero total de pontos implementados e aceitos pelo u u

cliente.
Tempo: utilizado no clculo de diversas mtricas, pode ser utilizado como durao (em meses, a e ca

semanas, dias, etc.) ou como nmero de iteraes. u co

Tamanho da Equipe: geralmente utilizado no clculo de mtricas, representa a quantidade de a e

pessoas na equipe.
Esforo: uma medida que leva em conta o tamanho da equipe durante um certo intervalo de c

tempo, geralmente medido em pessoas-ms ou pessoas-ano. e

19

Cap tulo 3

Aspectos Relevantes e Mtricas de e Qualidade para Adoo de um Software ca Livre

Com o objetivo de realizar uma ampla pesquisa foram elencados 106 aspectos e mtricas que podem e inuenciar na avaliao da qualidade de um software livre no momento de adot-lo em uma organizao. ca a ca A seleo dessas mtricas foi baseada no estudo do estado da arte de mtricas de software (apresentado ca e e no cap tulo 2), em relatrios de pesquisas sobre mtricas e artefatos que inuenciam a conabilidade da o e indstria de software europia na adoo de software de cdigo aberto (Bianco et al., 2007, 2008,?,?) u e ca o e tambm uma triagem inicial com especialistas em desenvolvimento de software, mestres e doutores e na rea de desenvolvimento de sistemas, principalmente os envolvidos com as metodologias geis e o a a software livre.

3.1

Mtricas e Aspectos Selecionados e

Para que a medio seja efetiva, torna-se necessrio foc-la nos objetivos a serem alcanados (Basili, ca a a c Caldiera e Rombach, 1994), sendo preciso deixar claras as necessidades para poder melhor conhecer os objetivos das medies (Peeger, 2000). O uso de modelos pode guiar a denio de aplicao de co ca ca medies a serem realizadas (Peeger, 2000), um modelo comumente utilizado o GQM Goal Question co e Metrics (Basili, Caldiera e Rombach, 1994). A abordagem do mtodo GQM baseada na premissa e e de que para medir deve primeiro especicar os seus prprios objetivos e os objetivos de seus projetos, o ento deve-se traar os objetivos para os dados que os denem operacionalmente, e nalmente prover a c um arcabouo para interpretao dos dados, respeitando os objetivos estabelecidos (Basili, Caldiera e c ca Rombach, 1994). O GQM considera um modelo com 3 n veis:
Conceitual n no qual so denidos os objetivos de medio. O objetivo denido para um vel a ca e

objeto (produto, processo ou recurso).

Operacional n no qual so denidas questes para caracterizar um caminho para alcanar vel a o c

um determinado objetivo.
Quantitativo n no qual so denidas as mtricas que usam um conjunto de dados (objetivos vel a e

ou subjetivos) associados com cada questo de forma quantitativa. a 20

A fases de denio do GQM so (Soligen e Berghout, 1999): ca a

Planejamento: fase na qual denida a equipe GQM, escolhida a rea de melhoria e so preparadas e a a

e motivadas as pessoas envolvidas.

Denio: fase na qual so denidos e documentados os objetivos, questes e mtricas; ca a o e Coleta de dados: fase na qual os dados so coletados; a Interpretao: fase na qual os dados coletados so processados em relao `s mtricas denidas, ca a ca a e

gerando os resultados da medio, que provem respostas para as questes denidas e posteriorca e o mente os objetivos podem ser avaliados. O mtodo GQM foi usado pelos trabalhos de levantamento de mtricas para adoo de software de e e ca cdigo aberto (Bianco et al., 2007, 2008,?,?), a abordagem no foi replicada nesse trabalho, uma vez o a que foi detalhadamente descritas nos relatrios citados. As demais mtricas elencadas fazem parte do o e contexto das mtricas software tradicionais e novos aspectos considerados relevantes por experientes e especialistas e colaboradores de projeto de software livre. Na prximas sees sero apresentados os aspectos e mtricas selecionados para se obter opinio de o co a e a especialistas em desenvolvimento de software. Sero apresentados em 16 grupos, de acordo com suas a caracter sticas. Cdigo-Fonte o Mtricas de cdigo-fonte, em sua maioria, so objetivas e passivas de automatizao. Elas tm o e o a ca e intuito de medir os detalhes de implementao do software e as relaes entre seus mdulos (classes ca co o etc). Foram elencadas 24 mtricas de cdigo-fonte neste trabalho: e o 1. Nmero total de linhas de cdigo u o 2. Nmero de classes (ou arquivos ou mdulos) u o 3. Nmero de mtodos ou funes u e co 4. Nmero de linhas de teste u 5. Nmero de testes por linha de cdigo u o 6. Nmero de testes por mtodo ou funo u e ca 7. Cobertura dos testes 8. N de acoplamento (dependncia entre os mdulos/classes) vel e o 9. N de coeso entre mdulos/classes do sistema vel a o 10. Complexidade Ciclomtica a 11. Existncia de cdigo duplicado: existindo cdigo duplicado no fonte do sistema, pode indicar proe o o blemas na modelagem do sistema, denio das classes, mtodos ou externar a falta de experincia ca e e do desenvolvedor. 21

12. Separao em Mdulos ca o 13. Estruturas de dados utilizadas 14. Estilo uniforme de indentao ca 15. Nmero de colunas por linha no muito grande: por exemplo, ausncia de linhas com mais de 120 u a e colunas. 16. Nmero de linhas em cada mtodo u e 17. Nmero de linhas em cada classe u 18. Nmero de mtodos em cada classe u e 19. Nmero de atributos em cada classe u 20. Nmero de variveis locais em cada mtodo u a e 21. Padres de nomenclatura usados uniformemente o 22. Uso de bons nomes para classes, mtodos, variveis, etc. e a 23. Existncia de comentrios no cdigo (cobertura e distribuio no cdigo) e a o ca o 24. Mdulo para conguraes (sem conguraes hard-coded e limites espalhados pelo cdigo): o o co co o sistema deve possuir um mdulo de congurao de maneira a agrupar e possibilitar conguraes. o ca co Deixando o software mais ex e de mais fcil manuteno, por permitir reconguraes. vel a ca co Testes Testes um conjunto de atividades j bem difundidas nos processos de desenvolvimento de software, e a ganhando mais nfase nos mtodos geis. A natureza dessas atividades buscam mecanismos de autoe e a matizao para melhor garantir e segurana dos resultados dos testes. Foram selecionados 11 mtricas ca c e e aspectos de testes neste trabalho: 1. Existncia de testes automatizados e 2. Uso de um arcabouo de testes (ex: JUnit, CPPUnit, Selenium, TestNG, DejaGNU, etc.) c 3. Publicao dos resultados dos testes ca 4. Existncia de um subgrupo (comunidade ou pessoa) especializado em testes e 5. Tipos de teste dispon veis (unidade, funcional, desempenho, estresse, estrutural, etc.) 6. Testes de mutao: so constru ca a das verses do software com falhas para saber se uma determinada o bateria de testes vai identicar tais falhas. 7. Testabilidade do cdigo (facilidade de escrever testes): capacidade de observar e controlar os o testes. 8. Existncia de testes de desempenho (benchmarks) e 22

9. Estudo sistemtico sobre o tempo de resposta a 10. Estudo sobre o consumo de recursos (disco, memria, etc.) o 11. Artigos e relatos dos experimentos de desempenho Manutenibilidade A manutenibilidade a facilidade de se dar manuteno em um software. A manuteno composta e ca ca e por um conjunto de atividades requeridas para prover suporte de custo efetivo para um sistema de software. A mtricas envolvem aspectos que podem ser automatizados e outros que necessitam de e uma abordagem subjetiva. Assim, foram elencados 11 aspectos e mtricas de manutenibilidade neste e trabalho: 1. Orientaes documentadas para adaptao/extenso co ca a 2. Documentao/descrio da arquitetura ca ca 3. Uso de padres de projeto e arquiteturais o 4. Uso de boa prticas de desenvolvimento (documentadas ou difundidas) a 5. Existncia de verses/atualizaes de manuteno e o co ca 6. Existncia de organizao/empresa fornecedora de suporte e ca 7. Tipo de manuteno/suporte oferecida ca 8. Linguagem de programao usada ca 9. Paradigma de programao (procedimental, orientado a objetos, etc.) ca 10. Nmero de linguagens usadas u 11. Ambiente (plataforma) de desenvolvimento Interoperabilidade A interoperabilidade uma caracter e stica que atribui a capacidade do sistema em se integrar e comunicar com outros sistemas e criao de novos e/ou adaptao de novos componentes que se inca ca tegram com o mesmo software em questo. Neste trabalho foram pensados em 3 aspectos ligados ` a a interoperabilidade. 1. Capacidade de comunicao/integrao com outros sistemas ca ca 2. Suporte a extenso atravs de plug-ins a e 3. Uso de padres da indstria e protocolos bem disseminados o u

23

Portabilidade A portabilidade a possibilidade e capacidade de um software funcionar em diferentes ambientes e ou plataformas. O conceito no contexto de software livre pode ganhar mais amplitude uma vez que a prpria comunidade regula as suas necessidades, mantendo determinado software para as plataformas o requeridas pelos prprios membros da comunidade. Foram elencados 2 aspectos de portabilidade: o 1. Lista de ambientes para os quais oferecido suporte e 2. Linguagem facilmente portvel a Usabilidade Neste trabalho conceituamos a usabilidade com o esforo necessrio do usurio utilizar o software, c a a desde a sua instalao at como obter ajuda para aprender a lidar com as funcionalidades do software. ca e Foram selecionados 5 aspectos relacionados com a usabilidade: 1. Facilidade de instalao e congurao ca ca 2. Clareza da interface do usurio a 3. Assistentes e ajuda ao usurio embutidos no software a 4. Diferentes opes de uso (linha de comando, modo grco, acesso Web, etc.) co a 5. Suporte a localizao/internacionalizao (adio de novas l ca ca ca nguas) Ferramentas A comunidade de software livre distribu e necessita de ferramentas de apoio ao desenvolvimento e da de software. Foram elencados 4 aspectos referentes as caracter sticas de ferramentas: 1. Integrao com ferramentas automatizadas de desenvolvimento ca 2. Scripts para congurao do processo de build ca 3. Possibilidade de personalizao j integrada ca a 4. Controle de verses com commits pequenos e documentados (comentrios nos commits) o a Independncia e Um conceito aplicado aos sistemas de software livre a separao em mdulos e a criao de e ca o ca pacotes de software. Os mesmos mantm um n e vel de dependncias entre seus outros mdulos e/ou e o outras aplicaes. Da mesma forma, um pacote de software deve se integrar ao ambiente onde ser co a inserido. Foram pensados 2 aspectos relacionados ` independncia de um software livre. a e 1. Dependncias bem documentadas e 2. No requer instalao de outros pacotes/sistemas a ca

24

Comunidade Um grupo de usurios, desenvolvedores, mantenedores entre outros formam uma comunidade de a um software livre. Essas comunidades trabalham de maneira que poss se observar caracter e vel sticas e medidas para se medir as atividades de uma determinada comunidade de software livre, podendo ser aspectos importantes na escolha de adoo de um determinado sistema. Foram pensados 12 aspectos e ca mtricas relacionadas a comunidade: e 1. Tamanho atual da comunidade de usurios do software a 2. Nmero total de componentes de atualizaes (patches) e verses (releases) u co o 3. Nmero de componentes de atualizaes (patches) e verses (releases) recentes u co o 4. Tempo de vida do projeto 5. Nmero de contribuies da comunidade u co 6. Existncia de diferentes grupos na comunidade e 7. Existncia de lista de e-mail ou Frum de usurios e o a 8. Atividade recente na lista de e-mail ou Frum da comunidade o 9. Lista de e-mail ou Frum de desenvolvedores o 10. Nmero de mensagens que j foram mandadas para fruns, listas, blogs, etc. u a o 11. Nmero de desenvolvedores u 12. Reputao dos desenvolvedores ca Aspectos de Conana c O conceito de conana neste trabalho est vinculado `s dinmicas das comunidade de software c a a a livre na soluo de problemas e disponibilizao de informaes. Foram pensados em 6 aspectos de ca ca co conana neste trabalho. c 1. Estgio do desenvolvimento/maturidade a 2. Informaes sobre a complexidade do software co 3. Disponibilizao de atualizaes cr ca co ticas (patch releases) 4. Nmeros de erros (bugs) cr u ticos reportados 5. Tempo de soluo de erros cr ca ticos (bugs) 6. Reputao do software ca

25

Funcionalidades A idia de funcionalidade neste trabalho no est restrita a uma lista de requisitos de software, e a a mas sim aos mecanismos de validao do software e uso em ambiente de produo. Foram pensados 5 ca ca aspectos ligados ao quo funcional est um determinado software livre: a a 1. Disponibilidade de uma lista bem denida de funcionalidades 2. Informaes/descries sobre cada nova verso (p.ex., changelog) co co a 3. Prottipo/exemplo/demo do software o 4. Existncia de comparaes documentadas com produtos similares e co 5. Existncia de produtos derivados e Satisfao de Usurios/Clientes ca a O retorno das opinies dos usurios de um determinado de software livre interfere diretamente na o a reputao e recomendao do sistema. Assim, foram pensados 4 aspectos relacionados com a satisfao ca ca ca dos usurios/clientes do software: a 1. Existncia de lista de organizaes que o utilizam e testemunho de usurios e co a 2. Existncia de estudos de casos documentados e histrico de uso e o 3. Prmios ganhos pelo software e 4. Empresas oferecendo servios tendo o software como base c Documentao ca A documentao no contexto deste trabalho no est vinculado aos artefatos do processo de desenca a a volvimento de software, estando mais relacionadas aos manuais e documentao tcnica do software. ca e Assim, foram elencados 6 tipos de documentao de software. ca 1. Manual do usurio a 2. Manual tcnico e 3. FAQ para usurios a 4. FAQ tcnico e 5. Documentao tcnica (p.ex., Javadoc) ca e 6. Guia de instalao ca

26

Suporte O suporte est vinculado aos aspectos de correo do erros. Assim, foram pensados 4 mtricas a ca e ligadas ao suporte de um software livre: 1. Nmero de correes de erros (bugs) disponibilizadas u co 2. Acompanhamento de erros (bug tracking) 3. Processo denido para correo de erros (bug worow ) ca 4. Tempo de resposta quando detectado um erro pelo usurio (comunidade e/ou desenvolvedores) a Treinamento Foram pensando 2 aspectos de treinamento vinculados a um determinado software livre: 1. Disponibilidade de treinamentos, tutoriais e outros materiais de aprendizagem 2. Curso ocial de treinamento Canais de Distribuio e Licena ca c Os meios de acesso ao software e ao cdigo-fonte e as licenas de um determinado software podem o c inuenciar na deciso de adoo de um determinado software livre. Assim, foram selecionados 5 aspectos a ca ligados aos canais de distribuio e as licenas de software: ca c 1. Acesso ao repositrio o 2. Download do cdigo-fonte e binrios o a 3. Disponibilizao em formato f ca sico (CD/DVD) 4. Principal licena usada c 5. Possibilidade de identicar uma lista de todas as licenas de todos os componentes (rvore de c a licenas) c

27

Cap tulo 4

Resultados do Levantamento de Mtricas de Avaliao de Projetos de e ca Software Livre

A pesquisa sobre os aspectos e mtricas para adoo de software livre obteve, alm dos dados e ca e sobre relevncia dos aspectos e mtricas, um levantamento do perl dos entrevistados, da atuao dos a e ca mesmos em projetos de software livre e participao e relao das organizaes e empresas, que os ca ca co entrevistados pertencem, com os sistemas livres dispon veis. Neste cap tulo sero apresentados o perl a dos especialistas em desenvolvimento de software, vinculados ou no aos projetos de software livre, e a o resumos de suas opinies sobre os 106 aspectos e mtricas elencados no questionrio dispon o e a vel na ntegra no Anexo A deste trabalho. Nem todas as perguntas e itens eram indicados como obrigatrios o de respostas, podendo ocorrer variaes no nmero absolutos de respostas. co u

4.1

Perl dos Entrevistados

Os especialistas em desenvolvimento de software convidados para responder o questionrio so a a desenvolvedores reconhecidos por sua atuao em projeto de software livre; mestres, doutores e pesquica sadores na rea de sistemas de software das mais reconhecidas universidades brasileiras; e prossionais a de empresas de desenvolvimento de software. Foi levada em considerao para o convite a reputaca o dos desenvolvedores perante os demais prossionais e comunidade de software livre e acadmica, ca e dependendo do contexto de atuao de cada indiv ca duo. Atuao Prossional em Relao ao Desenvolvimento de Software ca ca Foi perguntado aos especialistas em desenvolvimento de software qual era o tipo de atuao prosca sional na rea de desenvolvimento de software, independente de ser livre ou proprietrio, para se ter a a conhecimento das diversas experincias de atuao dos entrevistados. A Figura 4.1 mostra o resumo das e ca respostas, sendo poss assinalar mais de um tipo de atuao. Destacam-se como as mais indicadas a vel ca atuao como desenvolvedor, usurio, l ca a der de projeto e mantenedor.

28

Figura 4.1: Atuao prossional em relao ` software ca ca a Foram 34 pessoas que responderam este item, resultando nos seguintes nmeros absolutos e relativos u listados abaixo:
Usurio foi assinalado por 17 pessoas, correspondendo a 50%; a Mantenedor marcado por 12 pessoas, correspondendo a 35%; Desenvolvedor indicado por 30 pessoas, correspondendo a 88%; Analista de negcio marcado por 3 pessoas, correspondente a 9%; o Vendedor com nenhuma indicao de resposta; ca L der de equipe de desenvolvimento assinalado por 13 pessoas, corresponde a 38%; Gerente indicado por 2 pessoas, corresponde a 6%; Diretor/Presidente marcado por 4 pessoas, corresponde a 12% das respostas; Outros foi indicado por 7 pessoas, corresponde a 21%. Entre as outras opes de resposta esto co a

Consultor e Analista de Testes. Participao em Projetos de Software Livre ca Tambm foi perguntando aos especialistas em desenvolvimento de software de qual maneira que j e a participou de algum projeto de software livre. A Figura 4.2 mostra o resumo das respostas, podendo ser assinalada mais de uma resposta. Usurio e Desenvolvedor foram os tipos de participao mais a ca indicados como resposta.

29

Figura 4.2: Tipo de participao em projeto de software livre ca O total de pessoas que responderam este item foram 34, sendo os valores absolutos e relativos conforme mostrado abaixo:
Usurio foi indicado por 31 pessoas, correspondendo a 91%; a Desenvolvedor marcado por 27 pessoas, correspondendo a 79%; Tradutor indicado por 17 pessoas, corresponde a 50%; Mantenedor assinalado por 15 pessoas, correspondente a 44%; Disseminador indicado por 16 pessoas, corresponde a 47%; Outros foi marcado por 3 pessoas, corresponde a 9%. Entre os outros tipo de participao est o ca a

de Gerente de Projeto e Testador. Formao ca O n formao escolar e acadmica dos entrevistados tambm foi levantado. A Figura 4.3 aprevel ca e e sentada o resumo das respostas, indicando uma variao de formao entre superior incompleta ao ca ca doutorado.

Figura 4.3: N de formao dos entrevistados vel ca As 34 respostas em relao ` formaao apresentam os seguintes valores absolutos e relativos: ca a c
Fundamental, Segundo Grau e Outras Opes no tiveram indicaes. co a co Superior incompleto foi marcado por 9 pessoas, corresponde a 26%;

30

 Superior Completo indicado por 15 pessoas, corresponde a 44%; Mestrado Completo indicado por 9 26%, corresponde a 26%; Doutorado Completo foi marcado 1 pessoa, corresponde a 3%;

Tempo de Experincia Prossional com Software e Tambm foi perguntado aos especialistas em desenvolvimento de software qual a experincia e e e prossional na rea de desenvolvimento de software, independente de ser livre ou proprietrio, para se a a ter conhecimento das diversas experincias de mercado dos entrevistados. A Figura 4.4 mostra o resumo e das respostas, sendo poss a indicao de um unico intervalo de tempo em anos. Todos indicam pelo vel ca menos 3 anos de experincia com desenvolvimento de software, mas a maioria com mais de 5 anos. e

Figura 4.4: Experincia prossional (em anos) e Os valores absolutos e relativos das 34 respostas indicadas foram como a seguir:
Nenhuma experincia e 1 a 2 anos no foram marcadas como resposta; e a 3 a 5 anos de experincia foi indicado por 6 pessoas, corresponde a 18%; e 5 a 10 anos de experincia foi indicado por 16 pessoas, corresponde a 47%; e 10 a 20 anos de experincia foi indicado por 8 pessoas, correspondente a 24%; e mais de 20 anos de experincia foi indicado por 4 pessoas, corresponde a 12%. e

N mero de Projetos de Software Livre Participante u Tambm foi perguntado aos especialistas em desenvolvimento de software qual o nmero de proe e u jetos de software livre que participa ou participou at o momento. A Figura 4.5 mostra o resumo das e respostas, sendo poss a indicao de um unico intervalo de unidades. Alguns indicaram nenhuma vel ca participao direta, mas a maioria indicou que participou de pelo menos 3 projeto. ca

31

Figura 4.5: Nmero de projeto de software livre participante u Foram 34 resposta para este item, sendo os valores absolutos e relativos como detalhados abaixo:
3 pessoas indicaram nenhuma participao direta em projetos de software livre, ou seja 9%; ca 1 a 2 projetos foi indicado por 11 pessoas, corresponde a 32%; 3 a 5 projetos foi indicado por 12 pessoas, corresponde a 35%; 5 a 10 projetos foi indicado por 3 pessoas, corresponde a 9%; 10 a 20 projetos foi indicado por 3 pessoas, corresponde a 9%; mais de 20 projetos foi indicado por 2 pessoas, correspondente a 6%.

Tempo de Atuao em Projetos de Software Livre ca Tambm foi perguntado aos especialistas em desenvolvimento de software qual o tempo de expee e rincia e atuao em projetos de software livre. A Figura 4.6 mostra o resumo das respostas, sendo e ca poss a indicao de um unico intervalo de tempo em anos. Alguns indicaram nenhuma participao vel ca ca direta, mas a maioria indicou pelo menos 3 anos de participao. ca

Figura 4.6: Tempo de participao em projetos de software livre (em anos) ca Foram obtidas 34 respostas, conforme detalhadas abaixo:
5 pessoas nunca participaram de um projeto de software livre diretamente, correspondem a 15%; 1 a 2 anos de participao em projetos foi indicado por 6 pessoas, corresponde a 18%; ca

32

 3 a 5 anos de participao em projetos foi indicado por 6 pessoas, correspondente a 18%; ca 5 a 10 anos de participao em projetos foi indicado por 15 pessoas, corresponde a 44%; ca 10 a 20 anos de participao em projetos foi indicado por 2 pessoas, corresponde a 6%; ca mais de 20 anos de participao em projetos no foi assinalada como resposta. ca a

Tempo de Existncia do Projeto de Software Livre e N mero de Participantes e u Aos especialistas em desenvolvimento de software que atuam em um projeto de software livre, foi solicitado a indicao do nome do principal projeto que colabora, o tempo de existncia do projeto, o ca e nmero total de participantes e o nmero de desenvolvedores que o especialistas interage. A Figura 4.7 u u mostra o resumo das respostas em relaao ao tempo de existncia do projeto que participa. c e

Figura 4.7: Tempo de existncia do software livre participante e Foram 29 respostas para este item, com valores absolutos e relativos conforme abaixo:
menos de 1 ano de existncia foi indicado por 2 pessoas, corresponde a 7%; e 1 a 2 anos de existncia foi indicado por 5 pessoas, corresponde a 17%; e 3 a 5 anos de existncia foi indicado por 10 pessoas, corresponde a 34%; e 5 a 10 anos de existncia foi indicado por 4 pessoas, corresponde a 14%; e 10 a 20 anos de existncia foi indicado por 8 pessoas, corresponde a 28%; e mais de 20 anos de existncia no foi assinalado como resposta. e a

O nmero de participantes do projeto e o nmero de desenvolvedores que os especialistas interagem u u foram resumidos na Tabela 4.1. Participantes do Projeto 1a2 3 a 10 11 a 50 51 a 100 101 a 500 mais de 500 Total (votos) 3 8 5 1 5 7 % 10% 28% 17% 3% 17% 24% Interagem (votos) 5 12 7 1 3 1 % 17% 41% 24% 3% 10% 3%

Tabela 4.1: Nmeros correspondentes aos participantes do projeto u 33

A Tabela 4.1 indica que a maioria dos entrevistados colaboram com projetos com 3 a 10 participantes e tambm interagem em mdia com esse intervalo de participantes. e e N mero de usurios u a Foi perguntado aos entrevistados o nmero de usurios do principal projeto de software livre que u a colabora. A Figura 4.8 resume as respostas para este item, destacando a indicao de milhares de ca usurios para a maioria dos projetos em questo. a a

Figura 4.8: Nmero de usurios do software u a Os valores absolutos e relativos das 29 respostas para este item foram:
1 a 10 usurios do projeto foi indicado por 3 pessoas, corresponde a 10%; a Dezenas de usurios do projeto foi indicado por 5 pessoas, corresponde a 17%; a Centenas de usurios do projeto foi indicado por 3 pessoas, corresponde a 10%; a Milhares de usurios do projeto foi indicado por 10 pessoas, corresponde a 34%; a Centenas de milhares de usurios do projeto foi indicado por 8 pessoas, corresponde a 28%. a

N mero de Downloads u Tambm foi perguntado aos entrevistados o nmero de downloads do principal projeto de software e u livre que colabora. A Figura 4.9 resume as respostas para este item, destacando a indicao de centenas ca de milhares de downloads para a maioria dos projetos em questo. a

Figura 4.9: Nmero de downloads u Foram 28 respostas para este item, conforme detalhado abaixo:
1 a 10 downloads foi indicado por 3 pessoas, correspondendo a 11%;

34

 Dezenas de downloads foi indicado por 1 pessoa, corresponde a 4%; Centenas de downloads foi indicado por 2 pessoas, correspondendo a 7%; Milhares de downloads foi indicado por 10 pessoas, corresponde a 36%; Centenas de milhares de downloads foi indicado por 12 pessoas, corresponde a 43%.

Tempo de Participao no Projeto de Software Livre ca Foi pedido aos especialistas a indicao do tempo de participao, em anos, do principal projeto de ca ca software livre que colabora. A Figura 4.10 mostra as respostas, destacando a opo de pelo menos 3 ca anos de participao no referido projeto. ca

Figura 4.10: Tempo participao (em anos) ca As 30 respostas para este item tiveram os seguintes valores relativos e absolutos:
menos de 1 ano de participao foi indicado por 4 pessoas, corresponde a 13%; ca 1 a 2 anos de participao foi indicado por 9 pessoas, corresponde a 30%; ca 3 a 5 anos de participao foi indicado por 12 pessoas, corresponde a 40%; ca 5 a 10 anos de participao foi indicado por 5 pessoas, corresponde a 17%; ca 10 a 20 anos de participao no foi assinaladas como resposta. ca a mais de 20 anos de participao no foi assinalado com resposta. ca a

N mero de Horas Semanais Dedicadas ao Projeto u Tambm foi pedido aos especialistas a indicao do nmero horas dedicadas ao principal projeto de e ca u software livre que colabora. A Figura 4.11 mostra as respostas, destacando a opo de pelo menos 20 ca horas semanais com a segunda mais indicada.

35

Figura 4.11: Mdia de horas semanais dedicadas e Foram 30 respostas para este item, sendo os seguintes valores absolutos e relativos:
1 a 2 horas indicada por 10 pessoas, corresponde a 33%; 3 a 5 horas indicada por 3 pessoas, corresponde a 10%; 5 a 10 horas indicada por 4 pessoas, corresponde a 13%; 10 a 20 horas indicada por 3 pessoas, corresponde a 10%; 20 a 40 horas indicada por 7 pessoas, corresponde a 23%; mais de 40 horas indicada por 3 pessoas, corresponde a 10%.

Sistema Operacional de Desenvolvimento Informaes sobre o ambiente de desenvolvimento tambm foram obtidas. A Figura 4.12 indicar o co e resultado sobre o Sistema Operacional do ambiente de desenvolvimento do principal software livre que os especialistas colaboram.

Figura 4.12: S.O. do ambiente de desenvolvimento do software Dentre as respostas para este item, podendo ser indicada mais de um sistema operacional, os valores absolutos e relativos so: a
Linux indicado por 28 pessoas, corresponde a 97%;

36

 OpenSolaris indicado por 1 pessoa, corresponde a 3%; FreeBSD indicado por 1 pessoa, corresponde a 3%; Solaris no foi indicado como resposta; a Windows indicado por 6 pessoas, corresponde a 21%; MAC OS indicado por 11 pessoas, corresponde a 38%;

Linguagem de Programao Usada ca Informaes sobre a linguagem de programao usada para o desenvolvimento do software livre co ca tambm foram obtidas, conforme os resultados resumidos na Figura 4.13. e

Figura 4.13: Linguagem de programao usada na implementao ca ca Os detalhes para as respostas deste item, podendo ser assinalada mais de uma opo de linguagem ca de programao, est como a seguir: ca a
Java obteve 12 respostas, correspondendo a 40%; C++ obteve 8 respostas, correspondendo a 27%; C obteve 14 respostas, correspondendo a 47%; Python obteve 12 respostas, correspondendo a 40%; Ruby obteve 5 respostas, correspondendo a 17%; Perl obteve 5 respostas, correspondendo a 17%; Smalltalk obteve 1 resposta, correspondendo a 3%; PHP obteve 3 respostas, correspondendo a 10%; C# obteve 1 resposta, correspondendo a 3%; Outras opes foram indicadas por 8 pessoas, correspondendo a 27%. Entre as outras citadas co

esto Shell Script e Lua. a 37

Sistema Operacional de Funcionamento Informaes sobre o ambiente de funcionamento do software tambm foram obtidas. A Figura 4.12 co e indicar o resultado sobre o Sistema Operacional do ambiente de funcionamento do principal software livre que os especialistas colaboram.

Figura 4.14: S.O. em que funciona o software Dentre as respostas para este item, podendo ser indicada mais de um sistema operacional, os valores absolutos e relativos so: a
Linux foi indicado por 29 pessoas, correspondendo a 100%; OpenSolaris foi indicado por 10 pessoas, corresponde a 34%; FreeBSD foi indicado por 12 pessoas, corresponde a 41%; Solaris foi indicado por 9 pessoas, corresponde a 31%; Windows foi indicado por 19 pessoas, corresponde a 66%; MAC OS foi indicado por 16 pessoas, corresponde a 55%; Outras opes foram indicadas por 3 pessoas, correspondendo a 10%. Entre os outros indicados co

esto Palm OS, OLPC e Symbian. a Ferramentas de Desenvolvimento Informaes sobre as ferramentas usadas no desenvolvimento de software tambm foram obtidas, co e conforme os resultados resumidos na Figura 4.15. Destacando o Vi como o principal ambiente de desenvolvimento usado pelos especialistas.

38

Figura 4.15: Ferramentas usada no desenvolvimento Os detalhes para as respostas deste item, podendo ser assinalada mais de uma opo de ambiente ca de desenvolvimento, est como a seguir: a
Eclipse foi indicado por 15 pessoas, corresponde a 54%; NetBeans foi indicado por 3 pessoas, corresponde a 11%; KDevelope foi indicado por 2 pessoas, corresponde a 7%; Vi foi indicado por 19 pessoas, corresponde a 68%; Emacs foi indicado por 9 pessoas, corresponde a 32%; Squeak e Visual Studio no foi assinalado como respostas; a Outros ambientes foram indicados por 3 pessoas, correspondendo a 11%. Entre os outros esto a

Dit e o TextMate. Perl de Organizao que Trabalham ca Os especialistas em desenvolvimento de software tambm responderam sobre o perl da organizao e ca na qual tem v nculo prossional. O tipo de organizao, nmero de funcionrios, rea de atuao e ca u a a ca relaes com a produo e uso de software livre foram levantados. A Figura 4.16 ilustra um grco que co ca a mostra qual o tipo de organizao que a maioria dos especialistas trabalham, destacando as empresas ca privadas.

Figura 4.16: Tipo de organizao que tm v ca e nculo 39

Os detalhes das respostas para este item so: a

Privada foi o tipo indicado por 24 pessoas, correspondendo a 73%; Pblica foi o tipo indicado por 5 pessoas, correspondendo a 15%; u ONG sem ns lucrativos foi o tipo indicado por 3 pessoas, corresponde a 9% Outros tipos foi indicado por 1 pessoa, correspondendo a 3%. O outro tipo indicado foi organizao ca

privada sem ns lucrativos. Dentre as reas de negcio das organizaes esto o desenvolvimento de software, educao a Distncia, a o co a ca a gesto de projetos e consultoria, fertilizantes, CMS (Content Management System), Internet, servios a c de TI, turismo, ensino, indstria de telecom, Ensino etc. u Em relao ao nmero de funcionrios os valores obtidos foram: ca u a
1 a 5 funcionrios foi indicado por 8 especialistas, correspondendo a 24%; a 6 a 15 funcionrios foi indicado por 5 especialistas, correspondendo a 15%; a 16 a 50 funcionrios foi indicado por 5 especialistas, correspondendo a 15%; a 51 a 100 funcionrios foi indicado por 2 especialistas, correspondendo a 6%; a 101 a 500 funcionrios foi indicado por 3 especialistas, correspondendo a 9%; a mais de 500 funcionrios foi indicado por 10 especialistas, correspondendo a 30%. a

A indicao do tipo de relao das organizaes com os sistemas e aplicaes livre esto resumidas na ca ca co co a Tabela 4.2, destacando o fato de todas as organizaes usarem software livre e quando colaboram a co maioria indicou a personalizao como atividades. ca Relao ca Produz software livre? Usa software livre? Colabora com um software livre? (sugere modicaes, relata problemas, etc.) co Adiciona funcionalidades em um software livre? Personaliza/congura um software livre existente para o seu contexto? Sim 19 33 25 24 26 % 58% 100% 76% 73% 79% No a 14 0 8 9 7 % 42% 0% 24% 27% 21%

Tabela 4.2: Relao das organizaes com projetos de software livre ca co Em relao ao uso de software livre pelas organizaes dos especialistas em desenvolvimento, foram ca co levantados alguns dados que esto resumidos na Tabela 4.3. Chamando a ateno o uso de software a ca livre para aux no desenvolvimento de software e ao processo interno do negcio da empresa. lio o

40

Relao ca Usa para aux no desenvolvimento de software? lio Como parte de outro produto? Personalizao/congurao do software livre como forma de servio? ca ca c Para aux ao processo interno do negcio da empresa (ou seu)? lio o Usado para prover servios para clientes? c

Sim 34 30 19 32 26

% 100% 88% 58% 94% 76%

No a 0 4 14 2 8

% 0% 12% 42% 6% 24%

Tabela 4.3: Relao das organizaes ao uso de software livre ca co

4.2

Resultados das Mtricas e Aspectos Pesquisados e

Os especialistas em desenvolvimento de software indicaram quais aspectos e mtricas levam em e considerao para avaliar a qualidade de um software a m de determinar se deve adot-lo em sua ca a empresa/organizao. Tais aspectos e mtricas foram apresentadas em sub-grupos, como denidos no ca e cap tulo anterior. Os especialistas indicaram a relevncia de cada um dos 106 itens listados como a mtricas no questionrio (Anexo A) numa escala de 1 a 10, onde 1 considerado irrelevante e 10 e a e e relevante. Nesta seo sero apresentados os grcos com as mdias obtidas e as tabelas comparativas ca a a e com os valores das mdias e desvio padro de cada uma das mtricas. e a e Cdigo-Fonte o A Figura 4.17 apresenta o grco com as mdias obtidas da relevncia que os entrevistados deram a e a aos aspectos e mtricas de cdigo-fonte. Dentre as 24 mtricas as que mais se destacaram foram mdulo e o e o para congurao, separaes em mdulos e uso de bons nomes como as mais signicativas. J mtricas ca co o a e clssicas como complexidade ciclomtica e nmero de linhas de cdigo no foram consideradas muito a a u o a signicativas.

Figura 4.17: Grco com as mdias obtidas em relao ` relevncia das mtricas de cdigo-fonte a e ca a a e o A Tabela 4.4 apresenta os resultados das mdias e valores de desvio padro em relao ` relevncia e a ca a a considerada para as mtricas de cdigo-fonte. A tabela, assim como o grco, est ordenada em ordem e o a a decrescente, de acordo com os valores das mdias obtidas. Observando os valores de desvio padro, e a

41

atribuindo um desvio padro igual a 3, tm-se 10 mtricas apresentando desvio padro maior que 3, a e e a assim podendo considerar que houve discordncia entre as opinies nestes casos. Porm, as 3 primeira, a o e indicadas como mais signicativas, e as 5 ultimas, consideradas menos signicativas, no indicam um a alto grau de discordncia de acordo com esse critrio de desvio padro aceitvel. a e a a Mtrica e Mdulo para conguraes o co Separao em Mdulos ca o Uso de bons nomes Padres de nomenclatura o Existncia de comentrios e a Cobertura dos testes N de acoplamento vel Estruturas de dados Cdigo duplicado o Coeso entre mdulos/classes a o Estilo uniforme de indentao ca Testes por mtodo ou funo e ca Testes por linha de cdigo o Linhas em cada mtodo e Mtodos em cada classe e Linhas de testes Linhas em cada classe Atributos em cada classe Colunas por linha Complexidade Ciclomtica a Variveis locais em cada mtodo a e Nmero de mtodos ou funes u e co Nmero de classes u Total de linhas de cdigo o Mdia e 8,5 7,3 7,3 6,9 6,8 6,5 6,3 6,3 6,2 6,2 6,0 5,7 4,9 4,7 4,7 4,5 4,3 4,3 4,2 4,0 3,5 2,8 2,7 2,4 Desvio Padro a 2,1 2,9 2,9 3,1 2,8 3,4 3,2 3,2 3,1 3,0 3,2 3,3 3,5 2,9 2,9 3,2 2,8 2,8 3,0 2,5 2,5 2,1 2,2 1,9

Tabela 4.4: Mdias e desvio padro das mtricas de cdigo-fonte e a e o Testes A Figura 4.18 apresenta o grco com as mdias obtidas da relevncia que os entrevistados deram a e a aos aspectos e mtricas de testes. Dentre as 11 mtricas as que mais se destacaram foram testes e e automatizados, teste de desempenho e testabilidade do cdigo como as mais signicativas. J teste de o a mutao no foi considerado como signicativo, conforme se observa no grco. ca a a

42

Figura 4.18: Grco com as mdias obtidas em relao ` relevncia das mtricas de testes a e ca a a e A Tabela 4.5 apresenta os resultados das mdias e valores de desvio padro em relao ` relevncia e a ca a a considerada para as mtricas de testes. A tabela, assim como o grco, est ordenada em ordem decrese a a cente, de acordo com os valores das mdias obtidas. Observando os valores de desvio padro, atribuindo e a um desvio padro igual a 3, tm-se 5 mtricas apresentando desvio padro maior que 3, assim podendo a e e a considerar que houve discordncia entre as opinies nestes casos. Dessas, com um desvio padro alto, a o a est testes automatizados, que tem maior mdia de relevncia. Outras mtricas consideradas no muito a e a e a signicativas, como publicao dos resultados dos testes e sub-grupo especializado em testes, tambm ca e tm um desvio padro maior que 3. e a Mtrica e Testes automatizados Testes de Desempenho Testabilidade do Cdigo o Consumo de recursos Relatos dos experimentos de desempenho Arcabouo de testes c Tipos de teste dispon veis Estudo sobre o tempo de resposta Publicao dos resultados dos testes ca Subgrupo especializado em testes Testes de mutao ca Mdia e 7,2 6,8 6,6 6,4 6,2 5,8 5,8 5,7 5,4 4,5 3,8 Desvio Padro a 3,3 2,3 2,8 2,6 2,6 3,7 3,4 2,9 3,3 3,2 2,6

Tabela 4.5: Mdias e desvio padro das mtricas de testes e a e Manutenibilidade A Figura 4.19 apresenta o grco com as mdias obtidas da relevncia que os entrevistados deram a e a aos aspectos e mtricas de manutenibilidade. Dentre as 11 mtricas as que mais se destacaram foram e e 43

verses/atualizao de manuteno, documentao/descrio da arquitetura, uso de boas prticas de o ca ca ca ca a desenvolvimento e linguagem de programao como as mais signicativas. O aspecto de ter uma orgaca nizao/empresa fornecedora de suporte foi considerada a menos signicativa, mas com uma mdia de ca e relevncia quase 5. a

Figura 4.19: Grco com as mdias obtidas em relao ` relevncia das mtricas de manutenibilidade a e ca a a e A Tabela 4.6 apresenta os resultados das mdias e valores de desvio padro em relao ` relevncia e a ca a a considerada para os aspectos e mtricas de manutenibilidade. A tabela, assim como o grco, est e a a ordenada em ordem decrescente, de acordo com os valores das mdias obtidas. Observando os valores e de desvio padro, atribuindo um desvio padro igual a 3 como o limite de discordncia, tm-se apenas a a a e 3 mtricas apresentando desvio padro maior que 3, assim podendo considerar que houve discordncia e a a entre as opinies nestes casos. De qualquer forma, os primeiros aspectos e mtricas apresentam um o e desvio padro menor que 3, assim como organizao/empresa fornecedora de suporte, considerada a a ca menos signicativa. Mtrica e Verses/atualizaes de manuteno o co ca Documentao/descrio da arquitetura ca ca Uso de boa prticas de desenvolvimento a Linguagem de programao ca Orientaes documentadas para adaptao/extenso co ca a Padres de projeto e arquiteturais o Ambiente de desenvolvimento Nmero de linguagens usadas u Paradigma de programao ca Tipo de manuteno/suporte ca Organizao/empresa fornecedora de suporte ca Mdia e 8,4 7,7 7,6 7,2 6,9 6,4 6,4 6,2 6,0 5,0 4,9 Desvio Padro a 1,9 2,3 2,2 2,8 2,4 2,7 3,4 3,2 3,1 3,0 2,7

Tabela 4.6: Mdias e desvio padro das mtricas de manutenibilidade e a e

44

Interoperabilidade A Figura 4.20 apresenta o grco com as mdias obtidas da relevncia que os entrevistados deram a e a aos aspectos e mtricas de interoperabilidade. Todas as 3 mtricas tiveram mdias altas de relevncia, e e e a destacando os padres da indstria e protocolos bem disseminados como o mais signicativo. o u

Figura 4.20: Grco com as mdias obtidas em relao ` relevncia das mtricas de Interoperabilidade a e ca a a e

A Tabela 4.7 apresenta os resultados das mdias e valores de desvio padro em relao ` relevncia e a ca a a considerada para os aspectos e mtricas de interoperabilidade. A tabela, assim como o grco, est e a a ordenada em ordem decrescente, de acordo com os valores das mdias obtidas. Os valores de desvio e padro, de acordo com a conveno usada neste trabalho de desvio padro at 3, podem ser considea ca a e rados baixo, principalmente os dois primeiros aspectos apresentados na tabela - padres da indstria e o u protocolos bem disseminados e capacidade de integrao com outros sistemas - com desvio padro de ca a at 1,5. e Mtrica e Padres da indstria e protocolos bem disseminados o u Capacidade de integrao com outros sistemas ca Suporte a extenso atravs de plug-ins a e Mdia e 9,1 8,7 7,9 Desvio Padro a 1,3 1,5 2,3

Tabela 4.7: Mdias e desvio padro das mtricas de interoperabilidade e a e Portabilidade A Figura 4.21 apresenta o grco com as mdias obtidas da relevncia que os entrevistados deram a e a aos aspectos e mtricas de portabilidade. As 2 mtricas tiveram mdias boas de relevncia, destacando e e e a lista de ambientes suportados como a mais signicativa.

45

Figura 4.21: Grco com as mdias obtidas em relao ` relevncia das mtricas de Portabilidade a e ca a a e A Tabela 4.8 apresenta os resultados das mdias e valores de desvio padro em relao ` relevncia e a ca a a considerada para os aspectos e mtricas de portabilidade. A tabela, assim como o grco, est ordenada e a a em ordem decrescente, de acordo com os valores das mdias obtidas. Os valores de desvio padro, de e a acordo com a conveno usada neste trabalho de desvio padro at 3, podem ser considerados normais ca a e por estarem um pouco abaixo de 3. Mtrica e Lista de ambientes suportados Linguagem facilmente portvel a Mdia e 7,3 7,0 Desvio Padro a 2,8 2,9

Tabela 4.8: Mdias e desvio padro das mtricas de portabilidade e a e Usabilidade A Figura 4.22 apresenta o grco com as mdias obtidas da relevncia que os entrevistados deram aos a e a aspectos e mtricas de usabilidade. Todas as 5 mtricas tiveram boas mdias de relevncia, destacando e e e a clareza da interface do usurio e facilidade de instalao e conguraao como as mais signicativas, a ca c com mdias acima de 8. e

46

Figura 4.22: Grco com as mdias obtidas em relao ` relevncia das mtricas de usabilidade a e ca a a e A Tabela 4.9 apresenta os resultados das mdias e valores de desvio padro em relao ` relevncia e a ca a a considerada para os aspectos e mtricas de usabilidade. A tabela, assim como o grco, est ordenada e a a em ordem decrescente, de acordo com os valores das mdias obtidas. Os valores de desvio padro, de e a acordo com a conveno usada neste trabalho de desvio padro at 3, podem ser considerados normais ca a e por variarem entre 2,2 a 2,6. Mtrica e Clareza da interface do usurio a Facilidade de instalaao e congurao c ca Suporte a internacionalizao ca Diferentes opes de uso co Ajuda ao usurio embutidos no software a Mdia e 8,4 8,0 7,0 6,9 5,4 Desvio Padro a 2,2 2,4 2,6 2,3 2,5

Tabela 4.9: Mdias e desvio padro das mtricas de usabilidade e a e Ferramentas A Figura 4.23 apresenta o grco com as mdias obtidas da relevncia que os entrevistados deram a e a aos aspectos e mtricas de ferramentas. Os 4 aspectos tiveram boas mdias de relevncia, com mdias e e a e maior que 5, destacando scripts para congurao do processo de build e controle de verses de commits ca o como os mais signicativos.

47

Figura 4.23: Grco com as mdias obtidas em relao ` relevncia das mtricas de ferramentas a e ca a a e A Tabela 4.10 apresenta os resultados das mdias e valores de desvio padro em relao ` relevncia e a ca a a considerada para os aspectos e mtricas de ferramentas. A tabela, assim como o grco, est ordenada e a a em ordem decrescente, de acordo com os valores das mdias obtidas. Os valores de desvio padro, de e a acordo com a conveno usada neste trabalho de desvio padro at 3, podem ser considerados normais ca a e por variarem entre 2,3 a 2,9. Mtrica e Scripts para congurao do processo de build ca Controle de verses com commits o Possibilidade de personalizao j integrada ca a Integrao com ferramentas automatizadas de desenvolvimento ca Mdia e 7,8 7,5 7,2 5,4 Desvio Padro a 2,7 2,7 2,3 2,9

Tabela 4.10: Mdias e desvio padro das mtricas de ferramentas e a e Independncia e A Figura 4.24 apresenta o grco com as mdias obtidas da relevncia que os entrevistados deram a e a aos aspectos e mtricas de independncia. Os 2 aspectos tiveram boas mdias de relevncia com mdias e e e a e maior que 5, destacando dependncias bem documentadas como os mais signicativos, com mdia acima e e de 8.

Figura 4.24: Grco com as mdias obtidas em relao ` relevncia das mtricas de independncia a e ca a a e e 48

A Tabela 4.11 apresenta os resultados das mdias e valores de desvio padro em relao ` relevncia e a ca a a considerada para os aspectos e mtricas de independncia. A tabela, assim como o grco, est ordenada e e a a em ordem decrescente, de acordo com os valores das mdias obtidas. Observando os valores de desvio e padro, atribuindo um desvio padro igual a 3 como o limite de discordncia, tem-se apenas 1 aspecto a a a - no requer instalao de outros pacotes/sistemas - apresentando desvio padro um pouco maior que a ca a 3, assim podendo considerar que houve discordncia entre as opinies neste caso. a o Mtrica e Dependncias bem documentadas e No requer instalao de outros pacotes/sistemas a ca Mdia e 8,1 6,4 Desvio Padro a 2,5 3,1

Tabela 4.11: Mdias e desvio padro das mtricas de independncia e a e e Comunidade A Figura 4.25 apresenta o grco com as mdias obtidas da relevncia que os entrevistados deram a e a aos aspectos e mtricas de comunidade. Dentre as 12 mtricas as que mais se destacaram foram lista e e de e-mail ou frum de usurios, lista de e-mail ou frum dos desenvolvedores e atividades recentes na o a o lista de e-mail como as mais signicativas. De qualquer forma, todos os aspectos e mtricas foram e considerados signicativos, apresentando mdias maiores que 5. e

Figura 4.25: Grco com as mdias obtidas em relao ` relevncia das mtricas de comunidade a e ca a a e A Tabela 4.26 apresenta os resultados das mdias e valores de desvio padro em relao ` relevncia e a ca a a considerada para os aspectos e mtricas de comunidade. A tabela, assim como o grco, est ordenada e a a em ordem decrescente, de acordo com os valores das mdias obtidas. Observando os valores de desvio e padro, atribuindo um desvio padro igual a 3 como o limite de discordncia, tm-se apenas 2 aspecto, a a a e os dois indicados com menos signicativos, apresentam desvio padro um pouco maior que 3, assim a podendo considerar que houve discordncia entre as opinies nestes casos. a o 49

Mtrica e lista de e-mail ou Frum de usurios o a Lista de e-mail ou Frum de desenvolvedores o Atividade recente na lista de e-mail Tamanho atual da comunidade de usurios a componentes de atualizaes e verses recentes co o Reputao dos desenvolvedores ca Tempo de vida do projeto Contribuies da comunidade co Componentes de atualizaes e verses co o Mensagens que j foram mandadas para fruns etc a o Nmero de desenvolvedores u Existncia de diferentes grupos na comunidade e

Mdia e 8,1 7,9 7,8 7,6 7,5 7,1 7,0 7,0 6,6 6,4 5,5 5,4

Desvio Padro a 2,4 2,5 2,8 2,5 2,7 2,6 2,7 2,8 3,0 3,0 3,1 3,1

Figura 4.26: Mdias e desvio padro das mtricas de comunidade e a e Aspectos de Conana c A Figura 4.27 apresenta o grco com as mdias obtidas da relevncia que os entrevistados deram a e a aos aspectos e mtricas de conana. Dentre as 6 mtricas, as que mais se destacaram foram tempo e c e de soluo de erros cr ca ticos, reputao do software e disponibilizao de atualizaes cr ca ca co ticas, como as mais signicativas, com mdias maiores que 8. De qualquer forma, todos os aspectos e mtricas foram e e considerados signicativos, apresentando mdias maiores que 5. e

Figura 4.27: Grco com as mdias obtidas em relao ` relevncia dos aspectos de conana a e ca a a c A Tabela 4.12 apresenta os resultados das mdias e valores de desvio padro em relao ` relevncia e a ca a a considerada para os aspectos e mtricas de conana. A tabela, assim como o grco, est ordenada e c a a em ordem decrescente, de acordo com os valores das mdias obtidas. Os valores de desvio padro, de e a acordo com a conveno usada neste trabalho de desvio padro at 3, podem ser considerados normais ca a e por variarem entre 1,5 a 2,4.

50

Mtrica e Tempo de soluo de erros cr ca ticos Reputao do software ca Disponibilizao de atualizaes cr ca co ticas Nmeros de erros cr u ticos reportados Estgio do desenvolvimento/maturidade a Informaes sobre a complexidade do software co

Mdia e 8,5 8,4 8,4 7,8 7,6 6,4

Desvio Padro a 1,8 1,5 2,1 2,2 2,3 2,4

Tabela 4.12: Mdias e desvio padro das mtricas de aspectos de conana e a e c Funcionalidades A Figura 4.28 apresenta o grco com as mdias obtidas da relevncia que os entrevistados deram a e a aos aspectos e mtricas de funcionalidade. Dentre as 5 mtricas as que mais se destacaram foram e e disponibilidade de uma lista bem denida de funcionalidade e prottipo do software como as mais sigo nicativas. O aspecto considerado menos signicativo foi existncia de produtos derivados, com mdia e e de relevncia menor que 5. a

Figura 4.28: Grco com as mdias obtidas em relao ` relevncia dos aspectos de funcionalidade a e ca a a A Tabela 4.13 apresenta os resultados das mdias e valores de desvio padro em relao ` relevncia e a ca a a considerada para os aspectos e mtricas de funcionalidade. A tabela, assim como o grco, est ordenada e a a em ordem decrescente, de acordo com os valores das mdias obtidas. Os valores de desvio padro, de e a acordo com a conveno usada neste trabalho de desvio padro at 3, podem ser considerados normais ca a e por variarem entre 2,5 a 2,7. Mtrica e Disponibilidade de uma lista bem denida de funcionalidades Prottipo/exemplo/demo do software o Informaes/descries sobre cada nova verso (p.ex., changelog) co co a Existncia de comparaes documentadas com produtos similares e co Existncia de produtos derivados e Mdia e 7,8 7,6 7,5 6,5 4,7 Desvio Padro a 2,6 2,7 2,6 2,5 2,7

Tabela 4.13: Mdias e desvio padro das mtricas de funcionalidade e a e 51

Satisfao do Usurio/Cliente ca a A Figura 4.29 apresenta o grco com as mdias obtidas da relevncia que os entrevistados deram a e a aos aspectos e mtricas de satisfao do usurio. As 4 mtricas obtiveram boas mdias de relevncia, e ca a e e a mas nenhuma chegou a relevncia 7. a

Figura 4.29: Grco com as mdias obtidas em relao ` relevncia dos aspectos de satisfao do a e ca a a ca usurio a A Tabela 4.14 apresenta os resultados das mdias e valores de desvio padro em relao ` relevncia e a ca a a considerada para os aspectos e mtricas de satisfao do usurio. A tabela, assim como o grco, est e ca a a a ordenada em ordem decrescente de acordo com os valores das mdias obtidas. Os valores de desvio e padro, de acordo com a conveno usada neste trabalho de desvio padro at 3, podem ser considerados a ca a e normais por variarem entre 2,3 a 2,8. Mtrica e Empresas oferecendo servios tendo o software como base c Testemunho de usurios a Existncia de estudos de casos documentados e Prmios ganhos pelo software e Mdia e 6,9 6,7 6,4 5,4 Desvio Padro a 2,7 2,3 2,8 2,8

Tabela 4.14: Mdias e desvio padro das mtricas de satisfao do usurio e a e ca a Documentao ca A Figura 4.30 apresenta o grco com as mdias obtidas da relevncia que os entrevistados deram a e a aos aspectos e mtricas de documentao. Todas as 6 mtricas obtiveram boas mdias de relevncia, e ca e e a cando com mdias maiores que 7, destacando o FAQ Tcnico como a mais relevante com mdia maior e e e que 8.

52

Mtrica e FAQ tcnico e FAQ para usurios a Guia de instalao ca Manual tcnico e Manual do usurio a Documentao tcnica ca e

Mdia e 8,1 7,9 7,9 7,8 7,6 7,3

Desvio Padro a 2,5 2,4 2,6 2,4 2,5 2,9

Tabela 4.15: Mdias e desvio padro das mtricas de documentao e a e ca

Figura 4.30: Grco com as mdias obtidas em relao ` relevncia dos aspectos de documentao a e ca a a ca A Tabela 4.15 apresenta os resultados das mdias e valores de desvio padro em relao ` relevncia e a ca a a considerada para os aspectos e mtricas de documentao. A tabela, assim como o grco, est ordenada e ca a a em ordem decrescente, de acordo com os valores das mdias obtidas. Os valores de desvio padro, e a conforme a conveno usada neste trabalho de desvio padro at 3, podem ser considerados normais ca a e por variarem entre 2,4 a 2,9. Suporte A Figura 4.31 apresenta o grco com as mdias obtidas da relevncia que os entrevistados deram a e a aos aspectos e mtricas de suporte. As 4 mtricas obtiveram boas mdias de relevncia, destacando o e e e a tempo de resposta quando detectado um erro pelo usurio e o acompanhamento de erros, como as mais a signicativas, com mdias de relevncia maiores que 8. e a

53

Mtrica e Tempo de resposta quando detectado um erro pelo usurio a Acompanhamento de erros Correes de erros disponibilizadas co Processo denido para correo de erros ca

Mdia e 8,2 8,1 7,1 6,5

Desvio Padro a 2,0 2,2 2,6 3,2

Tabela 4.16: Mdias e desvio padro das mtricas de suporte e a e

Figura 4.31: Grco com as mdias obtidas em relao ` relevncia dos aspectos de suporte ao software a e ca a a

A Tabela 4.16 apresenta os resultados das mdias e valores de desvio padro em relao ` relevncia e a ca a a considerada para os aspectos e mtricas de suporte. A tabela, assim como o grco, est ordenada em e a a ordem decrescente de acordo com os valores das mdias obtidas. O aspecto menos signicativo (processo e denido para correo de erros), porm com uma boa mdia de relevncia, apresenta discordncia das ca e e a a opinies do entrevistados, de acordo com a conveno usada neste trabalho de desvio padro at 3. o ca a e Treinamento A Figura 4.32 apresenta o grco com as mdias obtidas da relevncia que os entrevistados deram a e a aos aspectos e mtricas de treinamento. Dos 2 aspectos analisados, um (disponibilidade de treinamentos, e tutoriais e outros materiais de aprendizagem) apresenta uma boa mdia de relevncia; e outro (curso e a ocial de treinamento) apontado como pouco signicativo, por ter mdia de relevncia prxima a 4. e e a o

54

Figura 4.32: Grco com as mdias obtidas em relao ` relevncia dos aspectos de treinamento a e ca a a A Tabela 4.17 apresenta os resultados das mdias e valores de desvio padro em relao ` relevncia e a ca a a considerada para os aspectos e mtricas de documentao. A tabela, assim como o grco, est ordenada e ca a a em ordem decrescente, de acordo com os valores das mdias obtidas. Os valores de desvio padro, de e a acordo com a conveno usada neste trabalho de desvio padro at 3, podem ser considerados normais ca a e por variarem entre 2,6 a 2,9. Mtrica e Disponibilidade de treinamentos, tutoriais e outros materiais de aprendizagem Curso ocial de treinamento Mdia e 6,8 4,1 Desvio Padro a 2,9 2,6

Tabela 4.17: Mdias e desvio padro das mtricas de treinamento e a e Canais de Distribuio e Licenas ca c A Figura 4.33 apresenta o grco com as mdias obtidas da relevncia que os entrevistados deram a e a aos aspectos e mtricas de canais de distribuio e licenas. Dentre as 5 mtricas, a que mais se destaca e ca c e download do cdigo-fonte e binrios, como a mais signicativa, com mdia de relevncia maior que 9. e o a e a J o aspecto sobre a disponibilizao em formato f a ca sicos no foi considerado muito signicativo. a

55

Figura 4.33: Grco com as mdias obtidas em relao ` relevncia dos Aspectos de Canais de Distria e ca a a buio e Licenas ca c A Tabela 4.18 apresenta os resultados das mdias e valores de desvio padro em relao ` relevncia e a ca a a considerada para os aspectos e mtricas de canais de distribuio e licenas. A tabela, assim como o e ca c grco, est ordenada em ordem decrescente de acordo com os valores das mdias obtidas. Um dos a a e aspectos (possibilidade de identicar rvore de licenas), mesmo com uma boa mdia de relevncia, a c e a apresenta discordncia das opinies do entrevistados, de acordo com a conveno usada neste trabalho a o ca de desvio padro at 3. a e Mtrica e Download do cdigo-fonte e binrios o a Acesso ao repositrio o Principal licena usada c Possibilidade de identicar rvore de licenas a c Disponibilizao em formato f ca sico Mdia e 9,2 8,1 7,8 6,5 3,4 Desvio Padro a 1,8 2,7 2,7 3,3 2,9

Tabela 4.18: Mdias e desvio padro das mtricas de canais de distribuio e licenas e a e ca c

4.2.1

Aspectos e Mtricas mais Relevantes e

A Tabela 4.19 apresenta os resultados das mdias e valores de desvio padro considerados para e a os aspectos e mtricas mais relevantes entre todos os pesquisados. A tabela est ordenada em ordem e a decrescente, de acordo com os valores das mdias obtidas. Os valores de desvio padro, de acordo com e a a conveno usada neste trabalho de desvio padro at 3, podem ser considerados normais por variarem ca a e entre 1,3 a 2,8, apresentando para todas as 26 mtricas listadas pequenos e ndices de discordncia. O a objetivo era elencar os 20 aspectos e mtricas com melhores mdias de relevncia, porm do 20 ao 26 e e a e na classicao dos mesmos possu ca am os mesmo valor de mdia. e

56

Mtrica e Download do cdigo-fonte e binrios o a Uso de padres da indstria e protocolos bem disseminados o u Capacidade de comunicao/integrao com outros sistemas ca ca Tempo de soluo de erros cr ca ticos Mdulo para conguraes o co Clareza da interface do usurio a Reputao do software ca Existncia de verses/atualizaes de manuteno e o co ca Disponibilizao de atualizaes cr ca co ticas Tempo de resposta quando detectado um erro pelo usurio a Dependncias bem documentadas e Acompanhamento de erros Acesso ao repositrio o FAQ tcnico e Existncia de lista de e-mail ou Frum de usurios e o a Facilidade de instalao e congurao ca ca FAQ para usurios a Lista de e-mail ou Frum de desenvolvedores o Guia de instalao ca Suporte a extenso atravs de plug-ins a e Disponibilidade de uma lista bem denida de funcionalidades Principal licena usada c Nmeros de erros cr u ticos reportados Atividade recente na lista de e-mail ou Frum da comunidade o Manual tcnico e Scripts para congurao do processo de build ca

Mdia e 9,2 9,1 8,7 8,5 8,5 8,4 8,4 8,4 8,4 8,2 8,1 8,1 8,1 8,1 8,1 8,0 7,9 7,9 7,9 7,9 7,8 7,8 7,8 7,8 7,8 7,8

Desvio Padro a 1,8 1,3 1,5 1,8 2,1 2,2 1,5 1,9 2,1 2,0 2,5 2,2 2,7 2,5 2,4 2,4 2,4 2,5 2,6 2,3 2,6 2,7 2,2 2,8 2,4 2,7

Tabela 4.19: Mdias e valores de desvio padro das mtricas mais relevantes e a e A Figura 4.34 apresenta o grco com as mdias obtidas da relevncia que os entrevistados deram a e a aos mais signicativos aspectos e mtricas, segundo eles mesmo. Dentre as 26 mtricas apresentadas, e e as que mais se destacaram foram download do cdigo-fonte e uso de padres da indstria e protocolos o o u de bem disseminados, com as maiores diferenas do valor da mdia em relao `s demais. c e ca a

57

Figura 4.34: Grco das mdia das mtricas mais relevantes a e e

58

Cap tulo 5

Consideraoes Finais c
Este trabalho apresentou um amplo estudo sobre o estado da arte em mtricas de software que vai e guiar as pesquisas de doutorado, em cincia da computao, em avaliao automtica da qualidade de e ca ca a cdigo-fonte. o Outro objetivo e etapa do trabalho foi elencar um conjuntos de aspectos e mtricas com o intuito de e realizar uma pesquisa com especialistas em desenvolvimento de software, ajudando tambm nas escolhas e de quais mtricas e aspectos sero focados na tentativa de automatizao da avaliao de qualidade de e a ca ca um software livre. A referida pesquisa foi realiza com 34 especialistas em desenvolvimento de software at o momento. e Os resultados foram apresentados neste trabalho, mas no analisados com o rigor estat a stico necessrio, a sendo precipitado constar uma concluso no atual andamento das pesquisas. Uma mestre em estat a stica j comeou a trabalha na anlise dos dados apresentados. Assim, pretende-se em um curto prazo a c a apresentar concluses efetivas e que possam ajudar na evoluo do tema de doutorado proposto. o ca Esta monograa se concretiza como de extrema importncia para os demais passos da mencionada a pesquisa de doutorado, ajudando para que em um mdia prazo se tenha resultados que possam ser e satisfatrios do ponto de vista prtico. o a

59

Apndice A e

Questionrio de Levantamento de a Aspectos Relevantes e Mtricas de e Qualidade para Adoo de um Software ca Livre
Paulo Meirelles (doutorando) Prof. Fabio Kon (orientador) Departamento de Cincia da Computao e ca IME / USP Caro especialista em desenvolvimento de software, Gostar amos de solicitar cerca de 20 minutos do seu tempo para o preenchimento do questionrio a a seguir que faz parte de uma pesquisa de doutoramento no Departamento de Cincia da Computao e ca do IME/USP. Assim que a anlise dos dados estiver completa, voc ter acesso em primeira mo aos a e a a resultados obtidos. Observaao: os dados pessoais coletados so para uso exclusivo do pesquisador e seu orientador e c a sero mantidos em total sigilo. Apenas informaes totalizadas e anonimizadas sero divulgadas como a co a resultado desta pesquisa.

1. Informaoes Pessoais c
a)Nome:
...

b)E-mail:
...

c)Prosso/Ocupao: a ca 60

 ...

d)Como voc caracterizaria sua atuao prossional em relao ` software: e ca ca a

( ) usurio, ( ) mantenedor, ( ) desenvolvedor, ( ) analista de negcios, ( ) consultor, ( ) vendedor, a o

( ) l der de equipe de desenvolvimento, ( ) gerente, ( ) diretor/presidente, ( ) outros (especicar): e)J participou em projeto(s) de software livre como: a
( ) usurio, ( ) desenvolvedor, ( ) tradutor, ( ) mantenedor, ( ) disseminador, ( ) outros (especicar): a

f)Formao: ca
( ) Fundamental ( ) 2o Grau ( ) Superior incompleto ( ) Superior Completo ( ) Mestrado Completo

( ) Doutorado Completo g)Anos de experincia prossional com software: e

( ) 0 ( ) 1 a 2 ( ) 3 a 5 ( ) 5 a 10 ( ) 10 a 20 ( ) mais de 20.

h)De quantos projetos de software livre voc participa ou participou? e

( ) 0 ( ) 1 a 2 ( ) 3 a 5 ( ) 5 a 10 ( ) 10 a 20 ( ) mais de 20.

i)Caso pertinente: tempo, em anos, em que atua em projeto(s) de software livre:

( ) 0 ( ) 1 a 2 ( ) 3 a 5 ( ) 5 a 10 ( ) 10 a 20 ( ) mais de 20.

2. Informaoes sobre o principal projeto de Software Livre de que c participa:

a)Nome do software/projeto:
...

b)Anos de existncia do projeto: e

( ) 0 ( ) 1 a 2 ( ) 3 a 5 ( ) 5 a 10 ( ) 10 a 20 ( ) mais de 20.

c)Nmero de participantes: u
( ) 1-2 ( ) 3-10 ( ) 11 a 50 ( ) 51-100 ( ) 101-500 ( ) mais de 500.

d)Nmero de participantes que interagem com voc: u e

( ) 1-2 ( ) 3-10 ( ) 11 a 50 ( )51-100 ( ) 101-500 ( ) mais de 500.

e)Nmero de usurios: u a
( ) 1-10 ( ) dezenas ( ) centenas ( ) milhares ( ) centenas de milhares

61

f)Nmero de Downloads: u
( ) 1-10 ( ) dezenas ( ) centenas ( ) milhares ( ) centenas de milhares

g)Anos de participao neste projeto: ca

( ) menos de 1 ( ) 1 a 2 ( ) 3 a 5 ( ) 5 a 10 ( ) 10 a 20 ( ) mais de 20.

h)Motivao para participar do projeto: ca

...

i)Nmero de horas semanais, em mdia, dedicadas ao projeto: u e

( ) 1 a 2 ( ) 3 a 5 ( ) 5 a 10 ( ) 10 a 20 ( ) 20 a 40 ( ) mais de 40.

j)Em qual sistema operacional o projeto desenvolvido? e

( ) Linux ( ) OpenSolaris ( )FreeBSD ( )Solaris ( )Windows ( ) Outros (especicar):

k)Qual linguagem de programao usada na implementao? ca e ca

( )Java ( )C++ ( )C ( ) Python ( ) Ruby ( )Perl ( )Smalltalk ( )PHP ( )C# ( )Outros (especicar):

l)Em qual sistema o software pode ser usado?

( ) Linux ( ) OpenSolaris ( )FreeBSD ( )Solaris ( )Windows ( ) Outros (especicar):

m)Qual ferramenta de desenvolvimento usada no projeto ? e

( )Eclipse ( )NetBeans ( )KDeveloper ( )Vi ( )Emacs ( )Squeak ( )Visual Studio ( ) Outros

(especicar):

3.

Caso esteja atuando prossionalmente, em relao ` Emca a

presa/Organizao em que trabalha indique: ca

a)Tipo de organizao: ca
( ) Privada ( ) Pblica ( ) ONG sem ns lucrativos ( ) Outros (especicar): u

b)Area do negcio da organizao: o ca

...

c)Nmero de funcionrios: u a
( ) 1-5 ( ) 6 a 15 ( )16-50 ( ) 51-100 ( )101-500 ( ) mais de 500

62

4. Participao da empresa/organizao em projetos de Software Lica ca vre:

a)Produz software livre?
( )Sim ( )No a

b)Usa software livre?

( )Sim ( )No a

c)Colabora com um software livre? (sugere modicaes, relata problemas, etc.) co

( )Sim ( )No a

d)Adiciona funcionalidades em um software livre?

( )Sim ( )No a

e)Personaliza/congura um software livre existente para o seu contexto?

( )Sim ( )No a

4.1 De que forma software livre util para a empresa/organizao (ou para voc): e ca e
a)Para aux no desenvolvimento de software? lio
( )Sim ( )No a

b)Como parte de outro produto?

( )Sim ( )No a

c)Personalizao/congurao do software livre como forma de servio? ca ca c

( )Sim ( )No a

d)Para aux ao processo interno do negcio da empresa (ou seu)? lio o

( )Sim ( )No a

e)Usado para prover servios para clientes? c

( )Sim ( )No a

5. Quais aspectos e mtricas voc leva em considerao para avaliar e e ca a qualidade de um software a m de determinar se deve adot-lo em a sua empresa/organizao? ca
Por favor, indique a relevncia de cada item para voc com um valor entre 1 e 10, onde 1=irrelevante a e e 10=essencial. 63

 CODIGO-FONTE:
( ) Nmero total de linhas de cdigo u o ( ) Nmero de classes (ou arquivos ou mdulos) u o ( ) Nmero de mtodos ou funes u e co ( ) Nmero de linhas de teste u ( ) Nmero de testes por linha de cdigo u o ( ) Nmero de testes por mtodo ou funo u e ca ( ) Cobertura dos testes ( ) N de acoplamento (dependncia entre os mdulos/classes) vel e o ( ) N de coeso entre mdulos/classes do sistema vel a o ( ) Complexidade Ciclomtica a ( ) Existncia de cdigo duplicado e o ( ) Separao em Mdulos ca o ( ) Estruturas de dados utilizadas ( ) Estilo uniforme de indentao ca ( ) Nmero de colunas por linha no muito grande (p.ex.: ausncia de linhas com mais de 120 u a e

colunas)
( ) Nmero de linhas em cada mtodo u e ( ) Nmero de linhas em cada classe u ( ) Nmero de mtodos em cada classe u e ( ) Nmero de atributos em cada classe u ( ) Nmero de variveis locais em cada mtodo u a e ( ) Padres de nomenclatura usados uniformemente o ( ) Uso de bons nomes para classes, mtodos, variveis, etc. e a ( ) Existncia de comentrios no cdigo (cobertura e distribuio no cdigo) e a o ca o ( ) Mdulo para conguraes (sem conguraes hard-coded e limites espalhados pelo cdigo) o co co o

64

TESTES:
( ) Existncia de testes automatizados e ( ) Uso de um arcabouo de testes (ex: JUnit, CPPUnit, Selenium, TestNG, DejaGNU, etc.) c ( ) Publicao dos resultados dos testes ca ( ) Existncia de um subgrupo (comunidade ou pessoa) especializado em testes e ( ) Tipos de teste dispon veis (unidade, funcional, desempenho, estresse, estrutural, etc.) ( ) Testes de mutao ca ( ) Testabilidade do cdigo (facilidade de escrever testes) o ( ) Existncia de testes de desempenho (benchmarks) e ( ) Estudo sistemtico sobre o tempo de resposta a ( ) Estudo sobre o consumo de recursos (disco, memria, etc.) o ( ) Artigos e relatos dos experimentos de desempenho

MANUTENIBILIDADE:
( ) Orientaes documentadas para adaptao/extenso co ca a ( ) Documentao/descrio da arquitetura ca ca ( ) Uso de padres de projeto e arquiteturais o ( ) Uso de boa prticas de desenvolvimento (documentadas ou difundidas) a ( ) Existncia de verses/atualizaes de manuteno e o co ca ( ) Existncia de organizao/empresa fornecedora de suporte e ca ( ) Tipo de manuteno/suporte oferecida ca ( ) Linguagem de programao usada ca ( ) Paradigma de programao (procedimental, orientado a objetos, etc.) ca ( ) Nmero de linguagens usadas u ( ) Ambiente (plataforma) de desenvolvimento

INTEROPERABILIDADE:
( ) Capacidade de comunicao/integrao com outros sistemas ca ca ( ) Suporte a extenso atravs de plug-ins a e ( ) Uso de padres da indstria e protocolos bem disseminados o u

65

PORTABILIDADE:
( ) Lista de ambientes para os quais oferecido suporte e ( ) Linguagem facilmente portvel a

USABILIDADE:
( ) Facilidade de instalao e congurao ca ca ( ) Clareza da interface do usurio a ( ) Assistentes e ajuda ao usurio embutidos no software a ( ) Diferentes opes de uso (linha de comando, modo grco, acesso Web, etc.) co a ( ) Suporte a localizao/internacionalizao (adio de novas l ca ca ca nguas)

FERRAMENTAS:
( ) Integrao com ferramentas automatizadas de desenvolvimento ca ( ) Scripts para congurao do processo de build ca ( ) Possibilidade de personalizao j integrada ca a ( ) Controle de verses com commits pequenos e documentados (comentrios nos commits) o a

INDEPENDENCIA:
( ) Dependncias bem documentadas e ( ) No requer instalao de outros pacotes/sistemas a ca

COMUNIDADE:
( ) Tamanho atual da comunidade de usurios do software a ( ) Nmero total de componentes de atualizaes (patches) e verses (releases) u co o ( ) Nmero de componentes de atualizaes (patches) e verses (releases) recentes u co o ( ) Tempo de vida do projeto ( ) Nmero de contribuies da comunidade u co ( ) Existncia de diferentes grupos na comunidade e ( ) Existncia de lista de e-mail ou Frum de usurios e o a ( ) Atividade recente na lista de e-mail ou Frum da comunidade o ( ) Lista de e-mail ou Frum de desenvolvedores o

66

 ( ) Nmero de mensagens que j foram mandadas para fruns, listas, blogs, etc. u a o ( ) Nmero de desenvolvedores u ( ) Reputao dos desenvolvedores ca

ASPECTOS DE CONFIANCA:
( ) Estgio do desenvolvimento/maturidade a ( ) Informaes sobre a complexidade do software co ( ) Disponibilizao de atualizaes cr ca co ticas (patch releases) ( ) Nmeros de erros (bugs) cr u ticos reportados ( ) Tempo de soluo de erros cr ca ticos (bugs) ( ) Reputao do software ca

FUNCIONALIDADES:
( ) Disponibilidade de uma lista bem denida de funcionalidades ( ) Informaes/descries sobre cada nova verso (p.ex., changelog) co co a ( ) Prottipo/exemplo/demo do software o ( ) Existncia de comparaes documentadas com produtos similares e co ( ) Existncia de produtos derivados e

SATISFACAO DE USUARIOS/CLIENTES:
( ) Existncia de lista de organizaoes que o utilizam e testemunho de usurios e c a ( ) Existncia de estudos de casos documentados e histrico de uso e o ( ) Prmios ganhos pelo software e ( ) Empresas oferecendo servios tendo o software como base c

DOCUMENTACAO:
( ) Manual do usurio a ( ) Manual tcnico e ( ) FAQ para usurios a ( ) FAQ tcnico e ( ) Documentao tcnica (p.ex., Javadoc) ca e ( ) Guia de instalao ca

67

SUPORTE:
( ) Nmero de correes de erros (bugs) disponibilizadas u co ( ) Acompanhamento de erros (bug tracking) ( ) Processo denido para correo de erros (bug worow) ca ( ) Tempo de resposta quando detectado um erro pelo usurio (comunidade e/ou desenvolvedores) a

TREINAMENTO:
( ) Disponibilidade de treinamentos, tutoriais e outros materiais de aprendizagem ( ) Curso ocial de treinamento

CANAIS DE DISTRIBUICAO E LICENCA:

( ) Acesso ao repositrio o ( ) Download do cdigo-fonte e binrios o a ( ) Disponibilizao em formato f ca sico (CD/DVD) ( ) Principal licena usada c ( ) Possibilidade de identicar uma lista de todas as licenas de todos os componentes (rvore de c a

licenas) c # Por favor, citar e/ou descrever outros aspectos ou mtricas de cdigo-fonte no citadas acima que e o a so usadas por voc ao avaliar a qualidade de um software. Use quanto espao for necessrio. a e c a

68

Referncias Bibliogrcas e a
Abreu, F. Mood - metrics for object-oriented design. In: OOPSLA 94. [S.l.: s.n.], 1994. Abreu, F.; Carapuca, R. Candidate metrics for object oriented software within a taxonomy framework. Journal of Systems and Software, v. 26, n. 1, 1994. Albrecht, A. J.; Gaffney, J. E. Software function, source lines of code, and development eort prediction: A software science validation. IEEE Transactions on Software Engineering, v. 9, n. 6, p. 628648, November 1983. Arthur, Lowell Jay. Measuring Programmer Productivity and Software Quality. New York: WileyInterscience, 1985. 292 p. Baker, A.L.; Zweben, S.H. A comparison of measures of control ow complexity. IEEE Transactions on Software Engineering, v. 6, n. 6, p. 506512, 1980. Bansiya, J.; Davi, C. Using qmood++ for object-oriented metrics. Dr. Dobbs Journal, December 1997. Basili, V. R.; Caldiera, G.; Rombach, H. D. Goal question metric paradigm.

http://www.cs.umd.edu/projects/SoftEng/ESEG/papers/gqm.pdf, 1994. Basili, V. R.; Rombach, H. D. TAME: Integrating Measurement into Software Environments. University of Maryland, Computer Science Department, 1987. Basili, Victor R. Tutorial on models and metrics for software management and engineering. IEEE Computer Society Press, EHO-167, p. 7, 1980. Basili, V.R.; Briand, L.C.; Melo, W.L. A validation of object-oriented design metrics as quality indicators. IEEE Transactions on Software Engineering, v. 10, n. 22, 1996. Basili, V.R.; Turner, A.J. Iterative enhancement: a practical technique for software development. IEEE Transactions on Software Engineering, v. 4, n. 1, p. 390396, 1975. Beck, Kent; Andres, Cynthia. Extreme Programming Explained: Embrace Change. 2nd edition ed. [S.l.]: Addison-Wesley, 2004. Beck, Kent; Fowler, Martin. Planning Extreme Programming. [S.l.]: Addison-Wesley Professional, 2000. Behrens, C. A. Measuring the productivity of computer systems development activities with function points. IEEE Transactions Software Engineering, v. 9, n. 6, p. 648652, November 1983. 69

Bellin, D.; Tyagi, M.; Tyler, M. Object Oriented Metrics: An Overview. 1999. Web Publication. Benkler, Yochai. The Wealth of Networks: How Social Production Transforms Markets and Freedom. [S.l.]: Yale University Press, 2006. Bianco, V. del et al. How European software industry perceives OSS trustworthi-

ness and what are the specic criteria to establish trust in OSS. [S.l.], October 2007. Http://qualipso.semanticdesktop.org/xwiki/bin/view/Wiki/WP51. Bianco, V. del et al. Analysis of relevant open-source projects and artifacts - Working document wd 5.2.1, Version 0.1. [S.l.], February 2008. Bianco, V. del et al. Denition of trustworthiness of software products and artefacts - Working document wd 5.3.1 - version 1.0. [S.l.], June 2008. Bianco, V. del et al. Identication of factors that inuence the trustworthiness of software products and artefacts - Working document wd 5.3.2, Version 2.0. [S.l.], October 2008. Bieman, J.M.; Ott, L.M. Measuring functional cohesion. IEEE Transactions on Software Engineering, v. 8, n. 20, p. 254259, 1994. Boehm, B. W. Software Engineering Economics. N. J.: Prentice-Hall, 1981. Boehm, B. W.; Brown, J. R.; Lipow, M. Quantitative evaluation of software quality. In: 2nd Intl. Conf. on Software Engineering. Long Beach, California: IEEE Computer Society, 1976. p. 592605. Boehm, B.W. et al. Characteristics of Software Quality (TRW series of software technology. 1st edition ed. [S.l.]: Elsevier, 1978. 210 p. Brown, David B. et al. A cost model for determining the optimal number of software test cases. IEEE Transactions on Software Engineering, v. 15, n. 2, p. 218221, 1989. Card, D. N.; Agresti, W. W. Measuring software design complexity. Jornal of Systems and Software, v. 8, n. 3, p. 185197, June 1988. Cerino, D. A. Software quality measurement tools and techniques . In: COMPSAC 86. Washington, D. C: IEEE Computer Society, 1986. p. 160167. Chidamber, R. S.; Kemerer, C. F. Towards a metrics suite for objectAoriented design. In: Proceedings of the OOPSLA 91 Conference. [S.l.: s.n.], 1991. p. 197211. Chidamber, S.R.; Kemerer, C.F. A metrics suite for object oriented design. IEEE Transactions on Software Engineering, v. 20, n. 6, p. 476493, 1994. Christensen, K.; Fitsos, G. P.; Smith, C. P. A perspective on software science. BM Systems Journal, v. 20, n. 4, p. 372387, 1981. Conte, S. D.; Dunsmore, H. E.; Shen, V. Y. Software Engineering Metrics and Models. California: Benjamin-Cummings, 1986.

70

Curtis, B.; Sheppard, S. B.; Milliman, P. Third time charm: Stronger prediction of programmer performance by software complexity metrics. In: 4th Int. Conf. on Software Engineering. New York: [s.n.], 1979. p. 356360. Curtis, B. et al. Measuring the psychological complexity of software maintenance tasks with the halstead and mccabe metrics. IEEE Transactons Software Engineering, v. 5, n. 2, p. 96104, March 1979. DeMarco, T. Controlling Software Projects: Management, Measurement & Estimation. New York: Yourdon Press, 1982. Dubinsky, Yael et al. Agile metrics at the israeliair force. In: Agile 2005 Conference. [S.l.: s.n.], 2005. p. 1219. Dunsmore, H.E.; Gannon, J.D. Data referencing: an empirical investigation. IEEE Computer, v. 12, p. 5059, 1979. Elshoff, J. L. Measuring commercial pl/i programs using halsteads criteria. ACM SIGPLAN Notices, v. 11, n. 5, p. 3846, May 1976. Fenton, N.E.; Melton, A. Deriving structurally based software measures. Journal of Systems and Software, v. 12, p. 177187, 1990. Fenton, Norman E.; Pfleeger, Shari Lawrence. Software Metrics: A Rigorous and Practical Approach. 2 edition ed. [S.l.]: Course Technology, 1998. 656 p. Gaffney, J. Program control complexity and productivity. In: Software Models. [S.l.: s.n.], 1979. p. 140. Gaffney, John E.; Felber, Henry D.; Erling, Richard W. The Software Measurement Guidebook (Management Information Systems) (Paperback). [S.l.], January 1995. Gorla, N.; Benander, A. C.; Benander, B. A. Debugging eort estimation using software metrics. IEEE Transactions on Software Engineering, v. 16, n. 2, p. 223231, Febuary 1990. Gousios, Georgios et al. Software quality assesment of open source software. In: 11th Panhellenic Conference on Informatics. May: [s.n.], 2007. Grady, R. B.; Caswell, D. R. Software Metrics: Establishing a Company-Wide Program. N. J: Prentice-Hall, 1987. Halstead, M. H. Natural laws controlling algoritmic structure? ACM SIGPLAN Notices, v. 7, n. 2, p. 19 26, Febuary 1972. Halstead, M. H. Elements of Software Science. New York: Elsevier North-Holland, 1977. Hansen, W.J. Measurement of program complexity by the pair (cyclomatic number, operation count). ACM SIGPLAN Notices, v. 3, n. 13, p. 2933, 1978. Harrison, R. An evaluation of the mood set of object-oriented software metrics. IEEE Transactions on Software Engineering, v. 24, n. 6, 1998. 71 Proceedings of the IEEE Workshop on Quantitative

Harrison, W.; Cook, C. A micro/macro measure of software complexity. Jornal of Systems and Software, v. 7, n. 3, p. 213219, September 1987. Harrison, W. et al. Applying software complexity metrics to program maintenance. Computer, v. 15, p. 6579, 1982. Hausen, H.L. Yet another software quality and productivity modeling-yaquapmo system sciences. In: Proceedings of the Twenty-Second Annual Hawaii International Conference on. [S.l.: s.n.], 1989. v. 2, p. 978987. Henderson-Sellers, Brian. Object-Oriented Complexity. [S.l.]: Prentice-Hall, 1996. Henry, S.; Kafura, D. Software structure metrics based on information ow. IEEE Transactions on Software Engineering, v. 5, n. 7, p. 510518, 1981. Henry, S.; Kafura, D. The evaluation of software systems structure using quantitative software metrics softwarepractice and experience. Software - Practice and Experience, v. 14, n. 6, p. 561 573, June 1984. Henry, S.; Kafura, D.; Harris, K. On the relationships among three software metrics. Performance Evaluation Rev., v. 10, n. 1, p. 8188, 1981. Ince, D.C.; Hekmatpour, S. An approach to automated software design based on product metrics. Software Engineering Journal, v. 3, n. 2, p. 5356, 1988. ISO/IEC9126-1. Software engineering - Product quality - Part 1: Quality Model. 2001. Jones, T. C. Programming Productivity. New York: McGraw-Hill, 1986. Jones, T. C. Applied Software Measurement: Assuring Productivity and Quality. New York: McGrawHill, 1991. Kafura, D.; Canning, J. A validation of software metrics using many metrics and two resources. In: 8th Intl. Conf. on Software Engineering. [S.l.]: IEEE Computer Society Press, 1985. p. 378385. Kafura, D.; Henry, S. Software quality metrics based on interconnectivity. Journal of Systems and Software, v. 2, n. 2, p. 121131, June 1981. Kafura, D.; Reddy, G. R. The use of software complexity metrics in software maintenance. IEEE Transations Software Engineering, v. 13, n. 3, p. 335343, March 1987. Kemerer, C. F. An empirical validation of software cost estimation models. Communications ACM, v. 30, n. 5, p. 416429, May 1987. Kirakowski, J.; Porteus, M.; Corbett, M. How to use the software usability measurement inventory: the users view of software quality. In: 3rd European Conference on Software Quality. Madrid: [s.n.], 1992. Knafl, G. J.; Sacks, J. Software development eort prediction based on function points. In: COMPSAC. Washington, D. C.: IEEE Computer Society Press, 1986. p. 319325.

72

Kolewe, R. Metrics in object-oriented design and programming. Software Development, October 1993. Lassez, J. L. et al. A critical examination of software science. Jornal of Systems and Software, v. 2, n. 2, p. 105112, June 1981. Levitin, A. V. How to measure software size, and how not to. In: C.: IEEE Computer Society Press, 1986. p. 314318. Li, H. F.; Cheung, W. K. An empirical study of software metrics. IEEE Transactions Software Engineering, v. 13, n. 6, p. 697708, June 1987. Lorenz, M. Real world reuse. Journal of object-oriented programming, v. 6, 1991. Lorenz, M.; Kidd, J. ObjectAOriented Software Metrics. [S.l.]: Prentice Hall, 1994. Macro, A.; Buxton, J. The Craft of Software Engineering. [S.l.]: Addison-Wesley, 1987. Mannino, Phoebe; Stoddard, Bob; Sudduth, Tammy. The mccabe software complexity analysis as a design and test tool. Texas Instruments Technical Journal, v. 7, n. 2, p. 4154, 1990. McCabe; Associates. McCabe Object-Oriented Tool Users Instructions. [S.l.], 1994. McCabe, T. J. A complexity measure. IEEE Transactions Software Engineering, v. 2, n. 4, p. 308320, December 1976. McCabe, T. J. Structured Testing: A Software Testing Methodology Using the Cyclomatic Complexity Metric. [S.l.], December 1982. McCabe, T. J.; Butler, C. Design complexity measurement and testing. Communications of the ACM, v. 32, p. 14151425, December 1989. McCabe, T.J.; Dreyer, L. A.; Watson, A. H. Testing an object-oriented application. Journal of the Quality Assurance Institute, v. 8, n. 4, p. 2127, October 1994. McCall, J. A.; Richards, P. K.; Walters, G. F. Factors in Software Quality. N. Y.:Rome Air Development Center, 1977. RADC-TR-77-369. Mills, Everald E. Software Metrics. Software Engineering Institute/SEI - Carnegie Mellon University, 1998. Mohanty, S. N. Software cost estimation: Present and future. Software-Practice and Experience, v. 11, n. 2, p. 103121, Febuary 1981. Morris, K.L. Metrics for Object-Oriented Software Development Environments. Dissertao (Mesca trado) M.I.T., 1988. Musa, J. D.; Iannino, A.; Okumoto, K. Software Reliability: Measurement, Prediction, Application. New York: McGraw-Hill, 1987. Myers, G. Reliable Software Through Composite Design. New York: Petrocelli/Charter, 1975. COMPSAC 86. Washington, D.

73

Myers, G. J. An extension to the cyclomatic measure of program complexity. ACM SIGPLAN Notices, v. 12, n. 10, p. 6164, October 1977. Oviedo, E.I. Control ow, data ow and program complexity. In: Proceedings of the IEEE Computer Software and Applications Conference. [S.l.: s.n.], 1980. p. 146152. Perlis, A.; Sayward, F.; Shaw, M. Software Metrics: An Analysis and Evaluation. Cambridge, Mass: MIT Press, 1981. Pfleeger, S. Use realistics, eective software measurement. In: Software - Software Quality Institute, 2000. cap. 8. Potier, D. et al. Experiments with computer software complexity and reliability. In: 6th Intl. Conf. on Software Engineering. New York: IEEE, 1982. p. 94103. Pressman, Roger S. Engenharia de Software. [S.l.]: Makron Books, 1995. Rocha, A. R. C.; Maldonado, J. C.; Weber, K. C. Qualidade de software - Teoria e prAtica. SAo Paulo: Prentice Hall, 2001. Rombach, H. D. A controlled experiment on the impact of software structure on maintainability. IEEE Transaction Software Engineering, v. 13, n. 3, p. 344354, March 1987. Rosenberg, L.H.; Hyatt, L.E. Software quality metrics for object-oriented environments. Crosstalk Journal, 1997. Rubin, H. A. A comparison of software cost estimation tools. System Development, v. 7, n. 5, p. 13, May 1987. Ruston, H. Quantitative software models for reliability, complexity and cost: An assessment of the state of the art. In: Workshop on Quantitative Software Models for Reliability, Complexity and Cost. New York: IEEE, 1979. Sato, Danilo; Goldman, Alfredo. Uso Ecaz de Mtricas em Mtodos Ageis de Desenvolvimento de e e Software. Dissertao (Mestrado) IME-USP, So Paulo, Agosto 2007. ca a Sato, Danilo; Goldman, Alfredo; Kon, Fabio. Danilo sato, alfredo goldman, and fabio kon. tracking the evolution of object oriented quality metrics. In: Proceedings of the 8th International Conference on Extreme Programming and Agile Processes in Software Engineering (XP 2007). [S.l.: s.n.], 2007. p. 8492. Schneidewind, N.F.; Hoffmann, H. An experiment in software error data collection and analysis. IEEE Transactions on Software Engineering, v. 3, n. 5, p. 276286, 1979. Sharble, R.; Cohen, S. The object-oriented brewery: A comparison of two object-oriented development methods. Software Engineering Notes, v. 18, n. 2, p. 6073, 1993. Shen, V. Y.; Conte, S. D.; Dunsmore, H. E. Software science revisited: A critical analysis of the theory and its empirical support. IEEE Transations on Software Engineering, v. 9, n. 2, p. 155165, March 1983. 74 . [S.l.]: Constructing Superior

Shen, V. Y. et al. Identifying error-prone software - an empirical study. IEEE Transactions Software Engineering, v. 11, n. 4, p. 317324, April 1985. Shih, T.K. et al. Decomposition of inheritance hierarchy dags for object-oriented software metrics. In: Workshop on Engineering of Computer-Based Systems (ECBS 97). [S.l.: s.n.], 1997. p. 238. Smith, C.P. A software science analysis of programming size. In: Computer Conference. [S.l.: s.n.], 1980. p. 179185. Soligen, R.; Berghout, E. The goal question metric method - A pratical guide for quality improvement of software development. Cambridge, Great Britain: McGraw-Hill, 1999. Stetter, F. A measure of program complexity. Computer Languages, v. 9, n. 3-4, p. 203208, 1984. Takahashi, M.; Kamayachi, Y. An empirical study of a model for program error prediction. IEEE Transactions on Software Engineering, v. 15, n. 1, p. 8286, January 1989. Troy, D. A.; Zweben, S. H. Measuring the quality of structured designs. J. Syst. and Software, v. 2, n. 2, p. 113120, June 1981. West, M. An investigation of c++ metrics to improve c++ project estimation, ibm internal paper. IBM internal paper. 1992. Wolverton, R. W. The cost of developing large-scale software. IEEE Transactions Computers, C-23, n. 6, p. 615636, June 1974. Woodfield, S. N.; Shen, V. Y.; Dunsmore, H. E. A study of several metrics for programming eort. J. Syst. and Software, v. 2, p. 97103, June 1981. Woodward, M. R.; Hennell, M. A.; Hedley, D. A measure of control ow complexity in program text. EEE Transactions. Software Engineering, v. 5, n. 1, p. 4550, January 1979. Xenos, M. et al. Object-oriented metrics - a survey. In: Proceedings of the FESMA 2000 - Federation of European Software Measurement Associations. Madrid, Spain: [s.n.], 2000. v. 6. Yau, S. S.; Collofello, J. S. Some stability measures for software maintenance. IEEE Transactions Software Engineering, v. 6, n. 6, p. 545552, November 1980. Yau, S. S.; Collofello, J. S. Design stability measures for software maintenance. IEEE Transantions Software Engineering, v. 11, n. 9, p. 849856, September 1985. Yin, B.; Winchester, J. The establishment and use of measures to evaluate the quality of software designs. In: Actas da Software Quality and Assurance Workshop. New York: Association for Computing Machinery, 1978. Yourdon, E.; Constantine, L.L. Structured Design. [S.l.]: Prentice Hall, 1979. Zolnowski, J.C.; Simmons, D.B. Taking the measure of program complexity. In: Proceedings of the National Computer Conference. [S.l.: s.n.], 1981. p. 329336. Proceedings of the ACM national

75