Métricas no Desenvolvimento de Sistemas de Informação

É comummente aceite que qualquer actividade de engenharia e, de um modo geral, qualquer actividade de base científica deve, de algum modo, poder ser quantificada para que possa ser controlada, verificada, comunicada e repetida. As actividades de engenharia de software não serão certamente excepção e, dentro destas, as actividades de concepção e desenvolvimento de sistemas de informação não serão, por mais que não fosse, pela péssima reputação que ainda têm relativamente a derrapagens nos prazos, nos custos e mesmo na conformidade face às necessidades que visa endereçar.

A quantificação tão indispensável é obtida precisamente com medição e, neste contexto, as métricas são a quantificação de uma dada característica ( do produto, do processo, etc.), obtida através de um ou mais atributos mensuráveis.

Tipos de métricas

O processo de concepção e desenvolvimento de sistemas de informação ocorre, na esmagadora maioria dos casos, no âmbito de um projecto, sendo assim possível distinguir três tipos primários de métricas:

1. Do produto

Estas métricas são aquelas que mais facilmente nos vêm à memória quando este tema é citado. Estão normalmente muito ligadas às características observáveis do produto, que é o principal output de todo o processo e projecto. No nosso caso, é o produto de software. As métricas do produto podem ser directas ou indirectas. São directas se quantificarem directamente uma característica do produto (por exemplo, linhas de código escritas, ou LOC).

São indirectas se quantificarem atributos que, não sendo os que desejamos, nos permitem, por algum método, quantificar através deles os que desejamos, mas não podemos medir directamente (por exemplo, o número de defeitos existente não é mensurável directamente - caso contrário eliminávamo-los - pelo que é vulgar medir a quantidade de defeitos encontrados por unidade de tempo e por linha de código, procurando avaliar se o "encontrar defeitos" está a desacelerar, podendo assim indicar que o seu número estará a diminuir).

As métricas indirectas são frequentemente e incorrectamente designadas por subjectivas. A subjectividade não decorre da directividade ou indirectividade de uma observação, mas antes da ausência de um processo definido (repetível e verificável) para a obter. Serão primitivas (ou elementares) quando resultam da medição de um único atributo (por exemplo, linhas de código). Serão compostas (ou calculadas) se resultarem da composição da medição de vários atributos (por exemplo, número de defeitos por milhar de linhas de código).

2. Do processo

São métricas que podem ser utilizadas na grande maioria dos processos, mesmo que muito diferentes dos de engenharia de software. São métricas do processo porque se destinam a controlar ou observar tendências relativamente aos componentes do processo propriamente dito (actividades, tarefas, produtos de trabalho), independentemente do projecto no qual decorre e do produto que deverá ser produzido.

São exemplo destas métricas a quantidade de produtos de trabalho das tarefas, a sua complexidade e/ou o tamanho individual, o número de produtos de trabalho revistos e aprovados e reprovados e o número de repetições de execução de actividades ou tarefas. As métricas do processo medem assim características do processo.

Não expressando directamente características do produto, estas métricas são, contudo, de inestimável valor para estimar indirectamente a quantificação de métricas do produto, principalmente quando ainda não é possível medir directamente a característica desejada, pelo simples facto do produto ainda não estar completo. A estimação indirecta das métricas do produto a partir das do processo, permite detectar tendências atempadamente e tomar as acções preventivas e/ou correctivas adequadas.

3. Do projecto

São métricas comuns a praticamente todos os projectos, sejam eles de engenharia de software, de engenharia civil, de realização de um evento social, ou qualquer outro. São métricas cujo objectivo é monitorizar os desvios nas actividades da gestão de projecto e nos factores que lhes estão directamente ligados (custos, prazos, utilização dos recursos humanos e outros). Expressam, por isso, características do projecto.

Mais uma vez, não expressando características do produto, as métricas do projecto poderão, indirectamente, auxiliar na estimação de métricas indirectas e representar assim sinais de alerta que, surgindo cedo, poderão ser interpretados e originar acções adequadas.

Classes de métricas

Tratando o tema das métricas de uma forma global, é possível encontrar várias classes de métricas:

1. De tamanho

Como o nome indicia, estas métricas quantificam características ligadas à dimensão. São provavelmente as mais utilizadas, principalmente porque é a partir delas que se obtêm as métricas mais comuns de produtividade. As métricas de tamanho têm sido proposta por muitos autores e em grandes quantidades. Poderemos destacar as seguintes:

• LOC (número de linhas de código. É a métrica mais vilipendiada, mas continua a ser a mais utilizada.
• FP (número de pontos de função). É uma métrica muito divulgada e foi muito utilizada em grande variedade de projectos. Juntamente com a LOC, é a métrica que mais se encontra nos estudos e estatísticas dos últimos 40 anos. Tal como a LOC, é muito utilizada para derivar métricas mais complexas (por exemplo, Backfired
• FP, Functional Size Index).
• Artefactos (número de artefactos). A selecção da granularidade dos artefactos é determinante no impacto da utilização desta métrica, pelo que aparece normalmente associada à métrica dimensão individual de artefacto.
• Dimensão individual de artefacto. Procura sistematizar a classificação da granularidade dos artefactos de modo a que os resultados possam ser transitivos.
  

2. De complexidade

Destinam-se a quantificar a o grau de complexidade e, juntamente com as métricas de tamanho, fornecem a maior parte da informação utilizada na prática para gerir os projectos de desenvolvimento nos últimos anos. Destacaria as seguintes, por serem as mais estudadas e documentadas por inúmeras obras e autores:

• McCabe - Cyclomatic Complexity. A complexidade ciclomática é a métrica mais difundida do número de classes de software estático. Introduzida em 1976 por Thomas McCabe, mede o número de caminhos linearmente independentes ao longo de um módulo. Esta medida resulta num único número ordinal que pode ser comparado com a complexidade de outros programas. A complexidade ciclomática é muitas vezes referida como simplesmente a complexidade de um programa ou como complexidade McCabe. É frequentemente utilizada em conjunto com outras métricas. Como uma das métricas de software mais difundidas e aceites, é o mais independente possível da linguagem e do formato da linguagem.
• Halstead - Volume de Halstead. Foi proposta por Maurice Halstead em 1977 e procura traduzir a dimensão e a complexidade de um dado módulo recorrendo à medida da participação de "elementos" determinados:
  Volume = Comprimento * LOG2 Vocabulário
  O comprimento representa o total de "elementos" utilizados e o vocabulário representa o número de "elementos" diferentes utilizados. Vários estudos (Christensen, 1981 e Curtis, 1979) defendem que esta métrica é efectivamente aplicável a ambientes muito heterogéneos por ser razoavelmente independente (por exemplo, da linguagem de programação). Contudo, outro estudo (Li, 1987) demonstra que as métricas de Halstead estão linearmente relacionadas com a LOC.
• Artifact Coupling. A medida do acoplamento entre artefactos traduz uma medida da complexidade de um sistema e, em particular, permite medir a dificuldade em alterar uma parte do sistema devido às interdependências entre artefactos. Cada elemento é classificado de baixo a muito alto acoplamento (Loosely Coupled a Strongly Coupled). É uma das métricas mais utilizadas para a derivação de métricas de avaliação do impacto de alterações na manutenção (evolutiva e correctiva) de sistemas de informação.
  

3. De qualidade

São métricas que procuram quantificar factores tidos como indicadores do nível de conformidade do sistema com normas, regras ou práticas que deverão ser observadas. Na classe de métricas de qualidade destacam-se as que se seguem:

• Standards Violation. Procura expressar o grau de adesão a regras standard de arquitectura e codificação (arquitectura, performance, documentação de código, naming conventions, boas práticas, etc.).
• Usabilidade. É definida pela capacidade de um produto ser utilizado com eficácia, eficiência e satisfação para atingir os fins para o qual foi concebido e construído.
• Fiabilidade. São métricas que se destinam a representar a capacidade de um produto para manter o grau de usabilidade desejado - MTTF (Mean Time to Fail) e MTBF (Mean Time Between Fails).
  

Conclusão

Aceitando como boa a asserção segundo a qual a engenharia de software não é mais complexa do que qualquer outra disciplina das engenharias, parece claro que deve ser disciplinada, regrada e quantificada como qualquer outra. Veja-se que o argumento frequentemente invocado da juventude da engenharia de software (alguns mais cépticos duvidam mesmo se será já uma engenharia?) para justificar as derrapagens dos custos e dos prazos dos projectos, cai pela base quando observamos os inúmeros exemplos das obras públicas, nas quais a engenharia civil (provavelmente a mais antiga e regrada das engenharias, com cerca de 5 a 10 mil anos de actividades e registos) derrapa sistematicamente nos prazos e nos custos dos respectivos projectos.

Há um ponto no qual a maioria dos autores concorda: o urgente estabelecimento de um programa de métricas a nível organizacional que seja capaz de ser instanciado de modo sensível e adequado às características e aos objectivos de cada projecto. Um plano de métricas bem estruturado e seleccionado segundo os objectivos específicos dos vários produtos, processos e projectos é um passo essencial no caminho da qualidade total.

Naturalmente que as actividades de recolha, tratamento e registo das métricas num projecto de dimensão média apresentam um desafio não desprezável em termos dos recursos a empenhar. Um dos factores críticos de sucesso de qualquer progarama de métricas organizacional é assegurar o suporte de ferramentas especializadas para cumprir com as exigências que os sistemas de SQA (Software Quality Assurance) colocam à gestão de projectos de concepção e desenvolvimento de sistemas de informação actualmente.

Eurico Santos, administrador da Sinfic.

Produzido em 2005