Politique de couverture

Uma métrica de software é um tipo de medição relacionado a um sistema, documento ou até mesmo ao processo de desenvolvimento de software (SOMMERVILLE, 2007). Uma medição consiste da derivação de um valor numérico ou símbolo a um atributo (seja ele de processo ou produto) comparando-o a padrões de qualidade ou regras claramente definidas, visando prover e identificar melhorias ou identificar não conformidades. (SOMMERVILLE, 2007; PRESSMAN, 2006). Apesar de serem utilizados sob o mesmo contexto, os termos medida, medição, métrica e indicador possuem diferenças. Pressman (2006) descreve medida como “uma indicação quantitativa da extensão, quantidade, dimensão, capacidade ou tamanho de algum atributo de um produto ou processo”. Para o autor, o termo medição é o ato de determinar uma medida e o termo métrica é o relacionamento de medidas individuais para se avaliar o grau em que um sistema se encontra em relação a um determinado atributo. Por fim, um indicador é uma métrica ou uma combinação de métricas que visa fornecer informações para compreensão do processo, produto ou projeto.

Uma medição de acordo com o Guia de Implementação do MPS.BR Nível F (2007) tem como principal objetivo, coletar, analisar e relatar dados relativos aos produtos, projetos e processos de uma organização. Para tal, o processo de medição deve ser bem planejado. Segundo Kosciansky e Soares (2007) as métricas devem considerar alguns critérios para que os resultados sejam precisos e bem aproveitáveis. O modelo SQuaRE (Scalet et. al, 1999) descreve tais critérios da seguinte forma: as métricas devem ter significância ( resultados encontrados devem agregar a avaliação da organização); as métricas devem ter custo e

complexidade de aplicação validados (não devem ser aceitas métricas custosas e tão pouco complexas que possam tornar o processo de medição inviável); as métricas devem ser repetíveis (aplicáveis a vários projetos) e reproduzíveis (possuir resultados iguais para avaliadores diferentes). Além disso, as métricas devem ser objetivas (claras e de consenso das pessoas envolvidas), imparciais (deve existir um padrão definido para realização das avaliações) e devem prover evidências para sua validação, a fim de garantir a confiabilidade dos dados levantados.

De acordo com o padrão IEEE 1061 – 1998 Standard for a Software Quality Metrics

Methodology (Padrão de Metodologias para Métricas da Qualidade de Software) dois métodos

podem ser úteis para o planejamento do trabalho de medição. São eles: o Método GQM (Goal-Question-Metrics) e o Método PSM (Practical Software Measurement). O Guia de Implementação do MPS.BR Nível F (2007), também os destaca argumentando ser as abordagens de medição mais utilizadas atualmente.

O método GQM organiza o planejamento de uma medição em etapas. Tal método prevê inicialmente o estabelecimento e a definição dos objetivos da medição. Posteriormente, devem ser definidas as questões (metas) que serão utilizadas para realização da medição, especificando e categorizando as medidas a serem coletadas. Por fim, deve-se desenvolver mecanismos para a coleta dos dados e análise/interpretação dos resultados obtidos provendo um feedback para tomada de decisões.

Já o método PSM visa obter informações objetivas sobre os projetos em andamento. Basicamente, o método se preocupa em especificar formalmente as medidas a serem utilizadas e a condução do processo de medição. O foco do método é estabelecer medições baseadas nas necessidades principais de um projeto (custos, cronograma, tamanho do produto, recursos, satisfação do cliente, entre outros). Para tal, essas medidas são identificadas e definidas inicialmente de forma clara e, são atribuídos indicadores que a partir do andamento do projeto são verificados e conduzem à tomada de decisões. Posteriormente, as medições são executadas e avaliadas provendo informações para os gerentes de projeto, para que as metas de prazo, custo e qualidade dos projetos sejam atingidas.

O Guia de Implementação do MPS.BR Nível F (2007) na descrição dos resultados esperados do processo de medição cita que os aspectos a serem medidos para Garantia da Qualidade de software devem envolver os processos (atividade relacionadas com o software), produtos (resultados da execução dos processos) e os recursos (elementos atuantes nos processos e responsáveis pelo desenvolvimento dos produtos). Devido à diferença destes aspectos, métricas distintas são definidas para a medição de produtos e processos. Os recursos

por estarem envolvidos em ambos os aspectos não serão tratados a parte. Tais métricas são listadas a seguir.

3.3.1 Métricas de Processo

São utilizadas para obter dados quantitativos sobre o processo de software (Sommerville, 2007). Pressman (2006) acrescenta tal definição, destacando que a medição de um processo de software além de visar à melhoria do processo, pode ser utilizada ao longo dos projetos de software auxiliando na estimativa, avaliação de produtividade e controle de qualidade dos projetos.

As métricas do processo geralmente quantificam atributos relacionados ao tempo (medição para identificar em quanto tempo atividades são concluídas), esforço (recursos necessários para um processo específico) e número de ocorrências (incidências de eventos específicos)(Sommerville, 2007). São exemplos de métricas de processo a serem utilizadas: percentual de erros descobertos antes da entrega ao usuário, percentual de defeitos entregues aos usuários, eficiência na remoção dos defeitos, esforço humano despendido, produtividade, cumprimento do cronograma, taxa de variação entre os processos planejados para avaliação e os realmente avaliados, entre outros. Pressman(2006) destaca que à medida que cresce a maturidade da organização na utilização de métricas de processo a abordagem de melhoria estatística do processo de software (statistical software process improvement) pode ser utilizada. Tal abordagem utiliza a análise de falhas de software para a coleta de informações sobre todos os erros e defeitos encontrados ao longo do ciclo de vida do software.

3.3.2 Métricas de Produto

As métricas de produto visam obter dados quantitativos acerca das características do próprio software. Para Sommerville (2007), as métricas de produtos dividem-se em duas classes: dinâmicas (coletadas por medições realizadas em um programa em execução) e estáticas (coletas por medições realizadas em documentos ou representações sem a necessidade de execução de programas). Tais métricas avaliam diferentes atributos de qualidade. As dinâmicas avaliam a eficiência e a confiabilidade de um programa. Por sua vez, as estáticas visam avaliar a complexidade e facilidade de compreensão e manutenção do sistema. Para facilitar a identificação das métricas a serem utilizadas sob o produto, Pressman

(2006) destaca que estas devem levar em consideração as fases do ciclo de vida do produto. Para tal, ele sugere métricas relativas às fases de análise, construção e testes do produto.

Na fase de análise, devem ser utilizadas métricas para a medição da qualidade da especificação de requisitos (atividade chave desta fase). São exemplos de métricas: percentual de modificações de requisito durante o projeto, percentual de erros de requisito, entre outras. Na fase de construção do produto as medições geralmente utilizadas envolvem o código- fonte. São exemplos de métricas: métrica de Halstead (utilizada para medir o esforço para construção do código baseado em seu tamanho), complexidade ciclomática e métricas baseadas no fluxo de dados. Por fim, na fase de testes do produto, indicadores de cobertura podem fornecer dados importantes sobre o percentual de produto de software que realmente foi testado ou ainda medir o percentual sobre os requisitos a serem testados. Bartié (2002) sugere a utilização das seguintes métricas: cobertura do planejamento dos testes, cobertura da execução dos testes, eficiência dos testes, entre outras.

Com a utilização das métricas torna-se possível mensurar e obter indicadores que remetem a qualidade daquilo que se está produzindo. Entretanto, para a coleta destes dados bem como a definição das técnicas a serem utilizadas para execução das atividades de SQA, entre outras atividades, inúmeras dificuldades podem surgir. Na seção a seguir é descrito um estudo que cita as principais dificuldades encontradas para execução das atividades de SQA por organizações que já possuem o processo implementado.