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).