Atenção: esse artigo tem um vídeo complementar. Clique e assista!

De que se trata o artigo

Este artigo pretende contribuir para a análise da qualidade e complexidade do código OO, assim como auxiliar no entendimento dos benefícios das métricas.

Para que serve

A gerência de um produto de software atinge um determinado estado de qualidade e precisão se existirem medidas que tornem possível a administração através dos aspectos do sistema. A métrica de software é uma medida de propriedades do sistema que podem ser definidas como caminhos para determinar quantitativamente a dimensão em que o produto, a sequencia e o projeto de software têm certas características.

Em que situação o tema útil

Para gerenciar produtividade e qualidade é necessário saber se ambas estão melhorando ou piorando. Isto implica na necessidade de métricas que indiquem as inclinações do desenvolvimento de sistema

Para gerenciar produtividade e qualidade é necessário saber se ambas estão melhorando ou piorando. Isto implica na necessidade de métricas que indiquem as inclinações do desenvolvimento de sistema. Assim, a gerência de um produto de software atinge um determinado estado de qualidade e precisão se existirem medidas que tornem possível a administração através dos aspectos do sistema. A métrica de software é uma medida de propriedades do sistema que podem ser definidas como caminhos para determinar quantitativamente a dimensão em que o produto, a sequencia e o projeto de software têm certas características.

Neste contexto, o processo de software estará sob controle se for adotada uma política de coleta de dados e documentação durante o desenvolvimento do projeto. O objetivo da mensuração é abastecer engenheiros e gerentes de produtos com um grupo de informações palpáveis para se projetar, gerenciar, controlar, estimar e melhorar os projetos com maior eficácia [20]. Segundo Côrtes e Chiossi (2001), quando são calculadas métricas, pretende-se obter dados que irão proporcionar opções para uma melhoria. Este é o objetivo da métrica de software, o estudo dos fatores que influenciam o rendimento através da qualificação dos projetos de desenvolvimento de software.

Entre as principais inquietações nas fábricas de software encontra-se a possibilidade de se criar um sistema de uma maneira mais rápida e a um custo mais baixo. As práticas baseadas em objetos tendem a simplificar o projeto de softwares complexos. Para Amber (1998), as organizações escolhem a orientação a objetos (OO) porque querem dar às suas aplicações mais qualidade, as quais querem implementar sistemas seguros, com um menor custo e menor tempo.

Este artigo pretende contribuir para a análise da qualidade e complexidade do código OO, assim como auxiliar no entendimento dos benefícios das métricas. Para isso, será apresentado o desenvolvimento de uma ferramenta capaz de efetuar a coleta de métricas de software OO a partir da análise de códigos fontes escrita em linguagem C# e Java.

Origem do Sistema Métrico

As métricas originaram-se da execução prática de avaliação para quantificar indicadores sobre o processo de desenvolvimento de um sistema, sendo adotados a partir de 1970. Existem quatro tendências desta área que são:

a) Medida da complexidade do código: criada em meados de 1970, os conjuntos métricos foram fáceis de atingir desde que fossem calculados pelo próprio código automatizado;

b) Estimativa do custo de um projeto de software: esta técnica foi desenvolvida em meados de 1970, estimando o trabalho e o tempo gasto para se desenvolver um software, baseando-se além de outros fatores, no número de linhas de código utilizados na implementação do sistema;

c) Garantia da qualidade do software: a melhoria destas técnicas teve maior repercussão entre os anos de 1970 e 1980, dando-se destaque à identificação de informações faltantes, durante as etapas do ciclo de vida do software;

d) Processo de desenvolvimento do software: o projeto de software ganhou importância e complexidade, sendo que a necessidade de se administrar este processo foi emergencial. O processo incluiu a definição do ciclo de vida do software através da definição da seqüência das fases do desenvolvimento, dando mais destaque ao gerenciamento e controle de recursos deste projeto.

A partir do aparecimento destas tendências, os desenvolvedores de sistema começaram a usar métricas no propósito de adequar o processo de desenvolvimento de software.

Importância das Medições

Se não é conhecida a complexidade de um software não se pode saber o caminho a seguir e nem mesmo o que fazer para solucionar um problema. Uma das maneiras de se controlar o desenvolvimento de um sistema é a utilização da medição de software. As métricas podem medir cada estágio do desenvolvimento e diversos aspectos do produto. Métricas ajudam a compreender o processo utilizado para a implementação de um sistema. De acordo com Pressman, o processo é medido com o propósito de melhorá-lo e o produto é mensurado com o intuito de ampliar sua qualidade.

Medidas são necessárias para examinar a qualidade e o rendimento do processo de desenvolvimento e manutenção do produto de software implementado. Assim, “as empresas devem estabelecer métricas apropriadas e manter procedimentos para monitorar e medir as características de suas operações que possam causar impacto significativo na qualidade de seus produtos” [5].

Objetivos da utilização de métricas

A utilidade das métricas deve ser traçada desde o início da implantação de métricas para avaliação de software. Há várias características importantes associadas com o emprego das métricas de software. Sua escolha requer alguns pré-requisitos:

a) Os objetivos que se pretende atingir com a utilização das métricas;

b) As métricas devem ser simples de atender e de serem utilizadas para verificar atendimentos de objetivos e para subsidiar processos de tomadas de decisão;

c) As métricas devem ser objetivas, visando reduzir ou minimizar a influência do julgamento pessoal na coleta, cálculo e análise dos resultados.

Para Ambler (1998), as métricas podem ser utilizadas para:

a) Estimar projetos: baseado em experiências anteriores pode-se utilizar métricas para estimar o tempo, o esforço e o custo de um projeto;

b) Selecionar as ferramentas;

c) Melhorar a abordagem de desenvolvimento.

Em uma organização que se dedica ao desenvolvimento de software, seja como atividade-fim seja como de suporte para uma empresa, há vários objetivos que se busca atingir, dependendo do estágio de maturidade em que se encontram essas atividades. Alguns dos objetivos perseguidos geralmente se enquadram na seguinte relação:

a) Melhorar a qualidade do planejamento do projeto;

b) Melhorar a qualidade do processo de desenvolvimento;

c) Melhorar a qualidade do produto resultante do processo;

d) Aumentar a satisfação dos usuários e clientes do software;

e) Reduzir os custos de retrabalho no processo;

f) Reduzir os custos de falhas externas;

g) Aumentar a produtividade do desenvolvimento;

h) Aperfeiçoar continuamente os métodos de gestão do projeto;

i) Aperfeiçoar continuamente o processo e o produto;

j) Avaliar o impacto de atributos no processo de desenvolvimento, tais como novas ferramentas;

k) Determinar tendências relativas a certos atributos do processo.

Um dos aspectos que deve ser observado quando da implementação de iniciativas de utilização de métricas é quanto a sua utilidade no contexto de um projeto ou do ambiente como todo, além dos tipos e categorias de métricas, usuários das métricas, pessoas para as quais os resultados das métricas são destinados e os seus níveis de aplicação.

O processo de medição e avaliação requer um mecanismo para determinar quais os dados que devem ser coletados e como os dados coletados devem ser interpretados [7]. O processo requer um mecanismo organizado para a determinação do objetivo da medição. A definição de tal objetivo abre caminho para algumas perguntas que definem um conjunto específico de dados a serem coletados. Os objetivos da medição e da avaliação são consequências das necessidades da empresa, que podem ser a necessidade de avaliar determinada tecnologia, a necessidade de entender melhor a utilização dos recursos para melhorar a estimativa de custo, a necessidade de avaliar a qualidade do produto para poder determinar sua implementação ou a necessidade de avaliar as vantagens e desvantagens de um projeto de pesquisa.

Assim, o objetivo primário de se realizar medições no desenvolvimento de software é obter níveis cada vez maiores de qualidade, considerando o projeto, o processo e o produto, visando à satisfação plena dos clientes ou usuários a um custo economicamente compatível.

Métricas tradicionais

A partir de agora serão apresentados alguns exemplos de métricas tradicionais.

Constructive Const Model

O modelo COCOMO é calculado a partir do número de linhas de código fonte entregue ao usuário [7]. Este modelo foi desenvolvido por Barry Boehm e resulta em estimativas de esforço, prazo, custo e tamanho da equipe para um projeto de software. O COCOMO é um conjunto de submodelos hierárquicos, que pode ser dividido em submodelos básicos, intermediários ou detalhados.

Linhas de Código

O modelo LOC, é a técnica de estimativa mais antiga. Ela pode ser aplicada para estimar o custo do software ou para especificar igualdade de analogia. Há muitas discussões e especulações sobre esta técnica. Primeiramente, a definição de linhas de código não é muito clara.

Um exemplo simples seria o caso de ser colocado ou não um comentário ou uma linha em branco como LOC. Alguns autores consideram estes comentários, no entanto, outros não. No caso de programas recursivos, essa técnica falha, porque a recursividade torna o programa mais curto. O sistema LOC é uma técnica genérica e superficial [11].

Outro problema da técnica LOC é que esta técnica é fortemente ligada à linguagem de programação utilizada, impossibilitando a utilização de dados históricos para projetos que não utilizam a mesma linguagem.

As vantagens do uso de LOC são [7]:

a) É fácil de ser obtido;

b) É utilizado por muitos modelos de estimativa de software como valor básico de entrada;

c) Existe farta literatura e dados sobre este sistema de métrica.

As desvantagens são:

a) Dependência de linguagem: não é possível comparar diretamente projetos que foram desenvolvidos em linguagens diferentes. Como exemplo, pode-se verifica a quantidade de tempo gasto para gerar uma instrução em uma linguagem de alto nível comparado com uma linguagem de baixo nível;

b) Penalizam programas bem projetados: quando um programa é bem projetado o mesmo utiliza poucos comandos para execução de uma tarefa;

c) Difíceis de estimar no início do projeto de software: é praticamente impossível estimar o LOC necessário para um sistema saindo da fase de levantamento de requisitos ou da fase de modelagem.

Com estas colocações, nota-se que a métrica LOC não é uma métrica a ser utilizada por si só, ela deveria ser utilizada em conjunto com outras métricas, efetuando um comparativo de resultados. Deste modo, uma métrica poderia completar a outra, fornecendo informações que são pertinentes às características de cada uma.

Medida de Ciência do Software

Halstead identificou a Ciência de Software – originalmente chamada de Física do Software – como uma das primeiras manifestações sobre métrica de código baseada num modelo de complexidade do software [18]. A idéia principal deste modelo é a compreensão de que software é um processo de manipulação mental dos símbolos de seus programas.

Estes símbolos podem ser caracterizados como operadores (em um programa executável verbos como: IF, DIV, READ, ELSE e os operadores propriamente ditos) ou operandos (variáveis e constantes), visto que a divisão de um programa pode ser considerada como uma seqüência de operadores associados a operandos.

Para Shepperd (1993), a ciência do software atraiu consideravelmente o interesse das pessoas em meados de 1970 por ser uma novidade na metrificação do software. Além disso, as entradas básicas do software são todas facilmente extraídas. Após o entusiasmo inicial da ciência do software, foram encontrados sérios problemas. Os motivos podem ser relatados em função da dificuldade que os pesquisadores encontraram na comparação dos trabalhos e evolução da métrica. Outro motivo seria a não associação correta entre o esforço requerido para manipulação do programa e o tempo exigido para conceber o programa e também por tratar um sistema como um simples módulo.

Métrica da complexidade ciclomática

Este método foi proposto por McCabe, que estava particularmente interessado em descobrir o número de caminhos criado pelos fluxos de controle em um módulo do software, desde que fosse relacionada à dificuldade de teste e na melhor maneira de dividir software em módulos.

A idéia é desenhar num grafo a sequencia que um programa pode tomar com todos os possíveis caminhos. A complexidade calculada fornecerá um número designando o quão complexo é um programa (ou seqüência).

Para possibilitar o cálculo desta métrica, os programas são inicialmente representados por grafos dirigidos representando o fluxo de controle. De um grafo G, pode ser extraída a complexidade ciclomática v(G). O número de caminhos dentro de um grafo pode ser dado como: o conjunto mínimo de caminhos os quais podem ser utilizados para a construção de outros caminhos através do grafo. A complexidade ciclomática é também equivalente ao número de decisões adicionais dentro de um programa:

...
Quer ler esse conteúdo completo? Tenha acesso completo