Métricas de processo e projeto de software

Métrica é um conjunto de medidas. Medição existe em qualquer processo de construção de qualquer coisa. A medição é realizada não apenas na Engenharia de Software. É fundamental para qualquer atividade, principalmente de engenharia. Seu propósito é avaliar alguma coisa. A partir dela, podemos ter o entendimento da eficácia de algumas situações, como do processo de software.

Por exemplo, para avaliar se o processo pelo qual uma empresa produz software é bom ou ruim, como se faz? O CMM é um modelo para avaliar a qualidade do processo. Ele se baseia em medidas como tempo, número de erros, de linhas de código, de manutenções, etc., para saber se o processo está funcionando bem. Não é possível avaliar algo sem alguma medição.

Os processos que estão no nível máximo do CMM têm um melhoramento contínuo, o que significa que eles são constantemente medidos. As métricas são aqui quantitativas (números).

Medidas de qualidade e medidas de produtividade são extraídas do processo de software.

A medição, além de ajudar na avaliação do processo de software, ajuda ainda nas estimativas, por exemplo, para estimar quanto tempo é necessário para a produção de um sistema. Atualmente erra-se muito nessas estimativas por não se ter muito conhecimento ou medição do processo. Com a medição, aperfeiçoamentos reais podem ser conseguidos ao longo do tempo.

Então, as razões para medir processos, produtos e recursos de software podem ser:

  • para caracterizar;
  • para avaliar;
  • para prever;
  • para aperfeiçoar.

Um engenheiro de software realiza medidas e desenvolve métricas de modo a obter indicadores.

Medida é um valor real, quantidade, dimensão, capacidade ou tamanho de algum atributo. Ex. número de erros encontrados.

Métrica é um conjunto de medidas tentando obter algum sentido. Ex. erros encontrados por pessoa-hora empregada. Traz alguma informação que pode ser útil.

Indicador é uma métrica, ou conjunto de métricas, que fornece compreensão de um processo de software, de um projeto de software ou do produto propriamente dito. Ex. comparando duas métricas, chega-se a uma conclusão que permite embasar uma tomada de decisão.

Exemplos

1. O que é medida, métrica e indicador?

Vide acima.

2. Defina duas medidas, uma métrica e um indicador para avaliar um carro.

Medidas: potência, peso bruto;

Métrica: potência por peso bruto;

Indicador: comparando-se a potência por peso bruto de dois carros, pode-se concluir qual é mais veloz.

3. O que são métricas do processo? E do projeto? Qual a principal diferença entre elas?

Métricas do processo e do projeto de software são medidas quantitativas que permitem ao pessoal de software ter idéia da eficácia do processo de software. Indicadores de projeto permitem à organização de engenharia de software ter idéia da eficácia de um determinado processo existente, enquanto os indicadores de processo tentam identificar problemas que atingem a produção de todos os projetos na empresa.

Métricas de Processo e Projeto de Software

  • A medição é fundamental para qualquer atividade de engenharia.
  • A medição nos permite obter entendimento nos dando um mecanismo para avaliação objetiva.
  • A medição pode ser aplicada ao processo de software, com o objetivo de melhorá-lo continuamente.
  • Métricas do processo e do projeto de software são medidas quantitativasque permite ao pessoal de software ter idéia da eficácia do processo de software.
    • Dados básicos de qualidade e de produtividade são coletados.
  • Com medições, as tendências (boas ou más) podem ser detectadas, melhores estimativas podem ser feitas e aperfeiçoamentos reais podem ser conseguidos ao longo do tempo.
  • Há quatro razões para medir processos, produtos e recursos de software: para caracterizar, para avaliar, para prever ou para aperfeiçoar.
  • Medidas, Métricas e Indicadores
    • Uma medida fornece uma indicação quantitativa da extensão, quantidade, dimensão, capacidade ou tamanho de algum atributo de um produto, ou de um processo.
    • A IEEE define métricas como “medida quantitativa de grau em que um sistema, componente ou processo possui um determinado atributo”.
    • Quando dados de um único ponto são coletados (por exemplo, quantidade de erros descobertos na revisão de um único módulo, pessoas-horas gastas na revisão de um único módulo, etc…), uma medida é estabelecida. Um medição ocorre como resultado da coleta de um ou mais pontos.
    • Uma métrica de software relaciona as medidas individuais de alguma forma (por exemplo, um número médio de erros encontrados por revisão ou um número médio de erros encontrados por pessoa-hora, emprega nas revisões).
    • Um engenheiro de software realiza medidas e desenvolve métricas de modo a obter indicadores.
    • Um indicador é uma métrica, ou combinação de métricas, que fornece compreensão de um processo de software, de um projeto de software, ou do produto propriamente dito.
  • Exemplo:
    • Quatro equipes de software estão trabalhando em um grande projeto de software. Cada equipe precisa conduzir revisões de projeto, mas pode selecionar o tipo de revisão que irá usar. Pelo exame da métrica, erros encontrados por pessoa-hora empregada, o gerente de projeto nota que duas equipes que estão usando métodos de revisão mais formais, exibem um valor para os erros encontrados por pessoa-hora empregada, que é 40% maior do que o valor das outras equipes.
    • Considerando todos os outros parâmetros iguais, isso, para o gerente de projeto, é um indicador de que os métodos de revisões formais podem fornecer um retorno maior do investimento em tempo que outra abordagem de revisão menos formal. Este pode, então, decidir sugerir que todas as equipes usem a abordagem menos formal.
  • A métrica pode fornecer compreensão ao gerente de um projeto. E compreensão leva a uma tomada de decisão mais precisa.
  • A medição é comum no mundo da engenharia. Medimos consumo de energia, peso, dimensões físicas, temperatura, voltagem, relação entre sinal e ruído…..
  • Na engenharia de software a medição é muito menos comum – temos dificuldade em concordar quanto ao que medir e dificuldade em avaliar as medidas que são coletadas.
  • Métricas devem ser coletadas de modo que os indicadores de processo e de produto possam ser determinados.

Métricas de Processo

  • Indicadores de processo permitem à organização de engenharia de software ter idéia da eficácia de um processo existente.
  • Elas permitem aos gerentes e profissionais avaliarem o que funciona e o que não funciona.
  • Métricas de processo são coletadas ao longo de todos os projetos e durante longos períodos.
  • Seu objetivo é fornecer indicadores que levem ao aperfeiçoamento do processo de software a longo prazo.

Métricas de Projeto

  • Indicadores de Projeto permitem ao gerente de projeto de software:
    1. Avaliar o status de um projeto em andamento;
    2. Acompanhar riscos potenciais;
    3. Descobrir áreas-problemas antes que elas se tornem críticas;
    4. Ajustar o fluxo de trabalho ou tarefas;
    5. Avaliar a capacidade da equipe de projeto e controlar a qualidade dos produtos do trabalho de software.
  • Em alguns casos, as mesmas métricas de software podem ser usadas para determinar indicadores de projeto e de processo de software.

Métricas de Processo e aperfeiçoamento do processo de software

Medimos a eficácia de um processo de software indiretamente – originamos um conjunto de métricas, baseadas nas saídas que podem ser derivadas do processo.

As saídas incluem – medidas de erros descobertos antes da entrega do software, defeitos entregues aos usuários finais e por ele relatados, produtividade dos produtos de trabalho entregues, esforço humano despendido, tempo gasto, cumprimento de cronograma e outras medidas.

Algumas dessas medidas, tais como defeitos entregues aos usuários finais, só podem ser utilizadas para avaliar o processo, enquanto que outras, tais como erros descobertos antes da entrega do software, podem ser utilizados para avaliar tanto o processo quanto um projeto em específico.

As métricas de processo de software podem fornecer benefícios significativos, à medida que a organização trabalha para aperfeiçoar seu nível gerencial de maturidade de processo.

Todavia, essas métricas podem ser mal utilizadas, criando mais problemas do que conseguem resolver.

Grady (1992) sugere uma etiqueta de métricas de software, que é apropriada tanto para os gerentes quanto para os profissionais, quando eles instituem um programa de métricas de processo:

Use bom senso e sensibilidade empresarial quando interpretar dados de métricas.

Forneça regularmente realimentação aos indivíduos e equipes que coletam medidas e métricas.

  • Não use métricas para avaliar indivíduos.
  • Trabalhe com profissionais e equipes para estabelecer metas claras e métricas que devem ser usadas para alcançá-las.
  • Nunca use métricas para ameaçar indivíduos ou equipes.
  • Dados de métricas que indicam uma área problemática não devem ser considerados “negativos”. Esses dados são meramente um indicador para melhoria do processo.
  • Não fique obcecado com uma única métrica em detrimento de outras métricas importantes.

À medida que uma organização sente-se mais confortável, coletando e usando métricas de processo, a derivação de indicadores simples dá lugar a uma abordagem mais rigorosa, chamada melhoria estatística de processo de software – statistical software process improvement (SSPI).

A SSPI usa a análise de falhas de software para coletar informação sobre todos os erros e defeitos encontrados à medida em que uma aplicação, sistema ou produto é desenvolvido e usado.

Erro – falha num produto de trabalho de engenharia de software, ou resultado a ser produzido, que é encontrado por engenheiros de software antes do software ser entregue ao usuário final.

Defeito – falha encontrada depois da entrega ao usuário final. A análise de falhas funciona da seguinte maneira:

  1. Todos os erros e defeitos são categorizados por origem (por exemplo: falha na especificação, falha de lógica, não atendimento à padrões)
  2. O custo para corrigir cada erro e defeito é registrado.
  3. A quantidade de erros e defeitos de cada categoria é contada e ordenada de forma decrescente.
  4. O custo total de erros e defeitos de cada categoria é calculado.
  5. Os dados resultantes são analisados, para descobrir as categorias que produzem um maior custo para a organização.
  6. São desenvolvidos planos para modificar o processo, com o objetivo de eliminar (ou reduzir a frequência das) classes de erros e defeitos que são mais dispendiosas.

Métricas de Projeto

Métricas de processo de software são usadas com finalidade estratégica.

Medidas de projeto de software são táticas – métricas de projeto e indicadores derivados delas são usados por um gerente de projeto e por uma equipe de software, para adaptar o fluxo de trabalho e as atividades técnicas do projeto.

A primeira aplicação das métricas de projeto, na maioria dos projetos de software, ocorre durante as estimativas. Métricas coletadas de projetos anteriores são usadas como base, a partir da qual as estimativas de esforço e de tempo são feitas para o trabalho atual de software.

À medida que o projeto prossegue, medidas de esforço e de tempo despendidos são comparadas com as estimativas originais – o gerente de projeto usa esses dados para monitorar e controlar o progresso.

À medida que o trabalho técnico se inicia, outras métricas de projeto começam a ter importância, como:

  • Taxa de produção – representada em termos de páginas de documentação, horas de revisão, pontos-por-função e linhas de código fonte entregue.

O objetivo das métricas de projeto é duplo:

  • Primeiro essas métricas são usadas para minimizar o cronograma de desenvolvimento, fazendo os ajustes necessários para evitar atrasos e problemas, e riscos em potencial.
  • Métricas de projeto são usadas para avaliar a qualidade do produto durante sua evolução e, quando necessário modificar a abordagem técnica para aperfeiçoar a qualidade.

À medida que a qualidade é aperfeiçoada, os defeitos são minimizados, e, à medida que a contagem de defeitos decresce, a quantidade de retrabalho durante o projeto é também reduzida.

Isto leva à diminuição do custo total do projeto.

Métricas Orientadas ao Tamanho

Métricas orientadas ao tamanho são originadas pela normalização das medidas de qualidade e/ou produtividade, considerando o tamanho do software que foi produzido.

Se uma organização de software mantém registros simples, uma tabela de medidas orientadas ao tamanho, pode ser criada.

Medidas orientadas ao tamanho

A tabela lista cada projeto de software desenvolvido e as correspondentes medidas daqueles projetos.

Deve-se notar que o esforço e o custo registrados na tabela referem-se a todas as atividades de engenharia de software (análise, projeto, codificação e teste), não apenas à codificação.

Para o desenvolvimento de métricas foi escolhida uma medida base da tabela anterior – LOC (Linhas de Código-Fonte)

A partir dos dados “rudimentares”, contidos na tabela anterior, um conjunto de métricas simples orientadas a tamanho pode ser desenvolvido para cada projeto.

  • Erros por KLOC (milhares de Linhas de Código Fonte);
  • Defeitos por KLOC;
  • R$ por LOC (estimado…);
  • Páginas de documentação por KLOC;

Adicionalmente, outras métricas interessantes podem ser calculadas:

  • Erros por pessoa-mês;
  • LOC por pessoa-mês;
  • $ por página de documentação (estimado…);

Métricas orientadas a tamanho não são universalmente aceitas como o melhor modo de medir o processo de desenvolvimento de software.

A maior parte da controvérsia gira em torno do uso de linhas de código fonte como medidas-chave.

Adeptos da medida de linhas de código fonte alegam que LOC é um artefato de todos os projetos de desenvolvimento de software, que pode ser facilmente contado e que muitos modelos de estimativa usam tal artefato.

Por outro lado, os oponentes argumentam que as medidas de LOC:

  • São dependentes da linguagem de programação.
  • Penalizam programas curtos, mas bem projetados.
  • Não podem acomodar facilmente linguagens não procedimentais e que seu uso na estimativa requer um nível de detalhes que pode ser difícil de alcançar, ou seja, significa que o planejador deve estimar o LOC a ser produzido, muito antes que a análise e o projeto tenham sido completados.

Métricas Orientadas a Função

Métricas de software orientadas a função usam uma medida da funcionalidade entregue pela aplicação como valor da normalização.

Como funcionalidade não pode ser medida diretamente, deve ser originada indiretamente usando outras medidas diretas.

Métricas orientadas a função foram inicialmente propostas por Albrecht em 1979 que sugeriu uma medida chamada pontos-por-função.

Pontos-por-função – derivadas a partir da contagem (direta) do domínio da informação do software e avaliação da complexidade do software.

São calculados completando a tabela apresentada a seguir.

Cinco características do domínio da informação são determinadas e as contagens são registradas nos lugares próprios da tabela.

Quantidades de entradas do usuário – cada entrada do usuário, que fornece dados distintos orientados à aplicação do software, é contada. Entradas devem ser distinguidas de consultas, que são contadas separadamente.

Quantidade de saídas do usuário – cada saída do usuário, que fornece informação orientada à aplicação para o usuário, é contada. Nesse contexto, saída refere-se a relatórios, telas, mensagens de erro, etc. Itens de dados individuais dentro de um relatório não são contados separadamente.

Novas consultas do usuário – uma consulta é definida como uma entrada on- line, que resulta na geração de alguma resposta imediata do software sob forma de saída on-line. Cada consulta distinta é contada.

Quantidade de arquivos – cada arquivo lógico (isto é, grupo de dados lógicos que pode ser parte de uma base de dados maior ou um arquivo separado) é contado.

Quantidade de interfaces externas – todas as interfaces que são usadas para transmitir informação a outro sistema, são contadas.

Uma vez coletados esses dados, um valor de complexidade é associado com cada contagem.

Organizações que usam os métodos de pontos por função desenvolvem critérios para determinar se uma instância particular é simples, média ou complexa. No entanto, esta determinação é um tanto subjetiva.

Para determinar os pontos por função é usada a seguinte relação:
FP = contagem total X [0,65 + 0,01 X ? (Fi)]

Os Fi (i=1 a 14) são valores de ajuste de complexidade, baseados nas respostas às seguintes perguntas:

  1. O sistema requer salvamento (backup) e recuperação (recovery)
  2. Comunicações de dados são necessárias?
  3. Há funções de processamento distribuídas?
  4. O desempenho é crítico?
  5. O sistema vai ser executado em um ambiente operacional existente, intensivamente utilizado?
  6. O sistema requer entrada de dados on-line?
  7. A entrada de dados on-line, exige que a transação de entrada seja construída através de várias telas ou operações?
  8. Os arquivos mestre são atualizados on-line?
  9. As entradas, saídas, arquivos ou consultas são complexas?
  10. O processamento interno é complexo?
  11. O código é projetado para se reusado?
  12. A conversão e a instalação estão incluídas?
  13. O sistema está projetado para instalações múltiplas em diferentes organizações?
  14. A aplicação está projetada para facilitar modificações e para facilidade de uso pelo usuário?

Cada uma destas questões é respondida usando uma escala que varia entre:
0 – não importante e não aplicável
5 – absolutamente essencial

Os valores na equação e os fatores de peso da tabela, foram determinados empiricamente.

Uma vez calculados, os pontos por função são usados de modo análogo à LOC, como forma de normalizar medidas de produtividade, qualidade e outros atributos de software. Tais como:

  • Erros por FP
  • Defeitos por FP
  • $ por FP
  • Páginas de documentação por FP
  • FP por mês.

Fonte: http://www.fag.edu.br/professores/elielder/materias/esiii/04_metricas_de_processo_e_projeto_de_software.pdf

Sou bacharel em Sistemas de Informação pela Estácio de Sá (Alagoas), especialista em Gestão Estratégica da Tecnologia da Informação pela Univ. Gama Filho (UGF) e pós-graduando em Gestão da Segurança da Informação pela Univ. do Sul de Santa Catarina (UNISUL). Certificações que possuo: EC-Council CEH, CompTIA (Security+, CySA+ e Pentest+), EXIN (EHF e ISO 27001), MCSO, MCRM, ITIL v3. Tenho interesse por todas as áreas da informática, mas em especial em Gestão e Governança de TI, Segurança da Informação e Ethical Hacking.

One Response to “Métricas de processo e projeto de software”

  1. Sergio disse:

    Caro Diego,
    Parabéns pela matéria.
    Trabalhamos com métricas organizacionais e as aplicamos em diversas disciplinas da gestão.
    Também estamos no inicio de desenvolvimento de um trabalho grande (outro tema) em plataforma web
    Quando tiver alguma aplicação no âmbito de resultado de empresas, nos participe.
    Grato,

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *