Dissertação - Medição de Software

Segundo Dumke (2010), medição é o processo pelo qual números ou símbolos são atribuídos a propriedades de entidades do mundo real de forma a descrevê-las. Ao longo das atividades de engenharia de software, diversas medições podem ser realizadas visando à obtenção de informações relevantes, como, por exemplo, o tamanho dos projetos, os custos de desenvolvimento e a quantidade de defeitos.

No contexto de projetos de software, a medição pode auxiliar a elaboração de planos realísticos e pode prover informações úteis ao acompanhamento do alcance aos objetivos, à identificação de problemas e à tomada de decisões informadas (McGARRY et al., 2002). No contexto organizacional, a medição pode auxiliar na análise do desempenho dos processos e apoiar o estabelecimento de metas factíveis, bem como a identificação de ações que visem melhorar a competitividade da organização (TARHAN e DEMIRORS, 2006).

Embora os benefícios obtidos a partir da implementação da medição sejam muitos, realizar medição demanda esforço e, consequentemente, há custos envolvidos. Similar a outras atividades de controle, estima-se que a medição corresponda de 0.3% a 1% do esforço desprendido no desenvolvimento. Sendo que, no início do uso da medição pela organização, essa porcentagem é mais elevada devido à estruturação inicial requerida: realização de treinamentos, elaboração de templates, definição dos mecanismos de coleta e implantação de ferramentas (DUMKE e EBERT, 2010).

Dumke e Ebert (2010) defendem que a eficiência da medição de software está fortemente relacionada ao apoio de ferramentas associadas a todo o processo de medição. Card et al. (2008), por sua vez, afirmam que apesar de ferramentas serem muito importantes para apoiar a realização do processo de medição, o uso delas não garante o sucesso de um programa de medição. Segundo McGarry et al. (2002), o sucesso de um programa de medição está diretamente relacionado a dois fatores: (i) a coleta, análise e divulgação dos resultados das medições devem estar diretamente relacionadas às informações requeridas para as tomadas de decisão; e (ii) o processo de medição deve ser bem estruturado e repetível.

Existem diversos padrões que orientam sobre o processo de medição de software, dentre eles: a ISO/IEC 15939 (ISO/IEC, 2007), a ISO/IEC 12207 (ISO/IEC, 2008), o Std. 1061 (IEEE, 1998), o PSM – Practical Software Measurement (McGARRY et al., 2002), o CMMI (SEI, 2010) e o MR-MPS-SW (SOFTEX, 2012). Em linhas gerais, o processo de medição de software inclui as seguintes atividades: planejamento da medição, execução da medição e avaliação da medição (ISO/IEC, 2008), conforme ilustra a Figura 2.1.

Figura 2.1 - Atividades gerais do processo de medição de software.

No planejamento da medição, com base nos objetivos e necessidades da organização, são definidas as entidades (processos, produtos, etc.) que serão consideradas para medição, quais de suas propriedades (custos, defeitos, etc.) serão mensuradas e quais medidas serão utilizadas. Para cada medida deve ser estabelecida uma definição operacional, que detalha aspectos relacionados à coleta e análise de dados. Nesse contexto, Dumke e Ebert (2010) destacam a importância de se ter definições operacionais precisas, buscando-se evitar que pessoas diferentes entendam a medida de maneiras diferentes e realizem medições inconsistentes. Os resultados do planejamento da medição são registrados no Plano de Medição.

Existem alguns métodos que auxiliam as organizações no planejamento da medição, visando à identificação de medidas que sejam realmente úteis. De acordo com BASILI e Green (1994) a definição de medidas úteis depende da identificação dos fatores críticos que são capazes de determinar se os objetivos de negócio serão ou não alcançados. Nesse sentido, uma das abordagens mais conhecidas é o GQM (Goal Question Metric) (BASILI et al., 1994), que considera que, para cada objetivo estabelecido, é possível determinar questões cujas respostas estão associadas a medidas.  Algumas variações desse método são o GQ(I)M (Goal Question (Indicator) Measure) (GOETHERT e FISHER, 2003), que,  baseado no entendimento de que identificar questões e medidas sem visualizar um indicador muitas vezes não é suficiente, propõe o alinhamento de medidas e indicadores com os objetivos, e o GQM*Strategies (BASILI et al., 2007), que acrescenta um conjunto de extensões no topo do método GQM, tornando explícitos os objetivos de negócio, as estratégias e os objetivos de software.

Após ser planejada, a medição pode ser executada. A execução consiste em coletar e armazenar os dados para as medidas definidas, de acordo com suas definições operacionais especificadas na etapa de planejamento.

Em relação ao armazenamento dos dados da medição Braungarten et al. (2005) afirmam que ele pode ser feito em planilhas eletrônicas, bancos de dados ou repositórios. De acordo com os autores, devido à simplicidade e baixo custo, as planilhas são usadas em grande parte das organizações. No entanto, elas não são adequadas a médio ou longo prazo, pois a consistência estrutural não pode ser assegurada e o acesso aos dados pode ser dificultado quando novas medidas ou mais dados são necessários. Bancos de dados são mais eficientes que planilhas, especialmente quando se trata de um grande volume de dados. Apesar dessa vantagem, tipicamente requerem maior investimento para construção e manutenção. Além disso, às vezes, organizações utilizam vários bancos de dados para tratarem diferentes aspectos da medição, o que pode levar ao comprometimento da integridade dos dados e a redundâncias que podem afetar a obtenção de informações corretamente. Repositórios, por sua vez, consideram uma visão mais ampla da medição do que bancos de dados e podem lidar com questões de integração de dados para permitir armazenamento e acesso adequados. Em contrapartida, a construção e o gerenciamento de repositórios costumam exigir esforço ainda maior que o empregado nos bancos de dados.

Com os dados coletados e armazenados, diferentes análises podem ser realizadas. A análise dos dados fornece informações para a tomada de decisão, favorecendo a identificação e execução de ações apropriadas. Durante a análise, frequentemente os dados são representados graficamente, a fim de propiciar uma melhor visualização e favorecer a análise dos dados. Gráficos podem representar tendências de dados, variações e tornar as relações entre diferentes medidas mais claras. Segundo McGarry et al. (2002), os gráficos mais comumente utilizados na medição de software são o gráfico em linha, usado para medidas ao longo do tempo, o gráfico em barras, usado para contagem de um grupo de componentes ou eventos,  e o gráfico de dispersão, usado para relação entre dois fatores. Como resultado das análises algumas ações podem ser identificadas, como, por exemplo, estender prazos, adicionar recursos, mudar a abordagem de desenvolvimento e realocar recursos (McGARRY et al., 2002).

Modelos de maturidade, tais como o CMMI (SEI, 2010) e MR-MPS-SW (SOFTEX, 2012) incluem medição como um dos processos fundamentais para a melhoria de processos. No CMMI a medição é introduzida no nível 2, enquanto que no MR-MPS-SW isso ocorre no nível F. A medição realizada nesses níveis é dita medição tradicional e tem como principal objetivo apoiar o gerenciamento de projetos e processos por meio da comparação entre valores planejados e valores realmente praticados. Nos níveis mais elevados de maturidade (níveis 4 e 5 do CMMI e níveis B e A do MR-MPS-SW) a medição tradicional não é mais suficiente. Nesses níveis é necessário realizar o controle estatístico dos processos críticos, a fim de conhecer seu comportamento, determinar seu desempenho em execuções anteriores e prever seu desempenho em projetos em curso e futuros, verificando se são capazes de alcançar os objetivos estabelecidos. Essa medição é chamada medição em alta maturidade (BARCELLOS et al., 2013).