Use métricas de projeto adequadas: garanta a qualidade de projeto orientado a objeto

métricas de projeto

Software é, atualmente, um dos produtos mais utilizados e valorizados no mercado. A preocupação com a qualidade tem se tornado requisito imprescindível e tem constituído a orientação básica para garantir a funcionalidade do software com o mínimo de erros, defeitos e maior satisfação das expectativas de qualidade.

Apesar da dificuldade em se medir qualidade, sua ausência é facilmente percebida. Assim, ela tem sido alvo de busca na maioria das atividades que envolvem produtos, e o também deve ter uma garantia de qualidade objetiva e eficiente.

Na tentativa de medir a qualidade de um software é possível identificar índices por meio de métricas, que têm sido apontadas eficazes como forma quantitativa de avaliar a qualidade, porque permitem comparações.

Este artigo apresenta um estudo de como melhorar a medição da qualidade do gerenciamento de projetos de desenvolvimento de software orientado a objeto por intermédio de métricas.

Introdução

O gerenciamento de projeto de desenvolvimento de software vem se constituindo peça fundamental na geração de produto com qualidade e ainda para que o projeto seja produtivo, ou seja, software que aumente a rentabilidade pela redução de custos em falhas internas e externas e com aumento da satisfação do cliente.

A utilização de métricas vem aumentando consideravelmente e a principal causa é a dificuldade de gerenciar projetos sem a dimensão do que se está gerenciando. Por meio da utilização de métricas consegue-se calcular, com mais precisão e confiabilidade, o tamanho do projeto do software.

A medição é a primeira etapa que leva ao controle. Se você não mede algo, não pode entender o processo. Se você não entende o processo, não o controla. Se você não o controla, não consegue aperfeiçoá-lo.

O objetivo deste artigo é recomendar a adoção de métricas para auxiliar a medição da qualidade de projetos de desenvolvimento de software orientado a objeto.

O artigo está dividido em tipos de métricas, apresentando as métricas mais adotadas e algumas conclusões.

governança de projetos

Tipos de Métricas de Projeto de TI

Métrica pode ser definida como um atributo mensurável de uma entidade. No caso de um projeto, uma métrica pode ser, por exemplo, o seu tamanho, uma vez que o tamanho pode ser medido.

Uma métrica pode ser obtida da própria entidade, por leitura direta. Nesse caso, a métrica é chamada métrica primitiva. O atributo mensurável, que é obtido por cálculo a partir de métricas primitivas, é conhecido como métrica derivada.

O atributo mensurável que é obtido por cálculo a partir de métricas primitivas é conhecido como métrica derivada.

Normalmente, são coletadas métricas medidas diretamente, mas de pouco significado numa interpretação isolada. O número de classes de um modelo, analisado isoladamente, tem pouca relevância. Contudo, pode ser feita estimativa do tamanho do sistema se for combinado, por exemplo, o número de classes com o número de operações e atributos de cada classe.

Isso reflete a necessidade de interpretação e indica as várias abordagens para a medição. Segundo Pressman (1995, apud RIEDER, 2003), as métricas têm como princípios específicos:

  1. Coletar dados para avaliação de desempenho atribuindo essas responsabilidades a toda equipe envolvida no projeto.
  2. Reunir dados de desempenho relativos à complementação do software.
  3. Analisar os históricos de projetos anteriores para determinar o efeito desses fatores, prevenindo erros para projetos futuros.

Ainda de acordo com Pressman (1995 apud RIEDER, 2003), os principais benefícios das métricas são:

  1. Constatar a qualidade do produto.
  2. Avaliar a produtividade das pessoas.
  3. Ter uma base de estimativas (baseline).
  4. Justificar pedidos de recursos e treinamento adicional, entre outros.

As métricas podem ser divididas em: métricas de qualidade, métricas de produtividade, métricas orientadas à função e métricas orientadas ao objeto.

As métricas de qualidade e de produtividade são independentes do tipo de modelagem e análise aplicada no projeto de desenvolvimento. Todavia, as métricas orientadas à função e as orientadas ao objeto normalmente são aplicadas de acordo com o tipo de modelagem e análise do projeto.

Métricas de Qualidade

Qualidade pode ser definida como conformidade com as especificações e atendimento das necessidades ou expectativas dos clientes.

Feigenbaum (1994, apud MAIA, 2001) define os custos da qualidade como aqueles associados à definição, criação e controle da qualidade, assim como avaliação e realimentação de conformidade com exigências em confiabilidade, segurança e também custos associados às conseqüências provenientes de falha em atender essas exigências, tanto na fábrica como no cliente.

Podem-se definir Custos da Qualidade como aqueles incorridos para garantir e assegurar a qualidade, bem como aqueles decorrentes das perdas, quando essa qualidade não é obtida. O custo da qualidade, segundo Ostrenga (1991, apud MAIA, 2001) constitui uma metodologia que aplica custos para atividades, e outros recursos consumidos em:

  • Conformidade coma especificação da qualidade e redução de variações.
  • Custo da não conformidade.
Leia também  GTD: Aprenda a priorizar suas tarefas com o método Getting Things Done

Os custos de prevenção e de avaliação são custos voluntários, e podem ser controlados, por decisão da empresa. Normalmente são incorridos durante a pesquisa e desenvolvimento, planejamento e desenho do produto. Esses custos são considerados custos de conformidade.

Os custos de falhas internas e externas, denominados custos involuntários, ocorrem na fase de produção e vendas.

Os custos da qualidade podem ser adotados como métricas da qualidade. A expectativa é pela redução de custos com eventuais não-conformidades (falhas internas e externas).

Pode-se definir retrabalho como o esforço consumido com mudanças, isso é, a carga de trabalho realizado para analisar, implementar e testar novamente as alterações no software . A expectativa é pela diminuição do retrabalho.

Se a tendência do retrabalho é aumentar, pode ser interpretado como um mau sinal sobre a manutenibilidade futura do software.

Defeitos no projeto

A primeira impressão que se tem ao se falar em defeitos é o número absoluto de defeitos que um software possui. Esses defeitos apresentam-se como falhas na operação ou são descobertos durante as atividades de testes.

Falha é o não cumprimento dos resultados esperados, tanto por comparação aos requisitos como por interrupção no funcionamento.

Defeito é a imperfeição na especificação técnica, no projeto de um componente ou na codificação de um software, que, em determinadas condições, causa a falha observada.

Assim, ao longo do tempo vão aparecendo falhas que constituem a curva de detecção de falhas. Por sua vez, os defeitos também podem ser analisados construindo curva de detecção de defeitos e curva de densidade de defeitos.

Como, geralmente, os defeitos mais fáceis de detectar são os primeiros a ser encontrados, o trabalho de testes fica mais difícil na medida em que avança. Novas interações ou manutenções freqüentemente introduzem novos defeitos.

Esse padrão de comportamento deve ser observado minuciosamente pelo gerente de projetos para verificar se há tendência em direção à qualidade.

Vale salientar que os valores absolutos são menos importantes do que a tendência, porque uma tendência a zero, mesmo partindo de patamares mais altos, significa um processo que está fazendo o seu trabalho de depuração.

Uma forma de medir a maturidade de um produto é determinar o tempo médio entre falhas (MTBF Mean Time Between Failures), que reflete a taxa de descoberta de defeitos quando certas condições de operação são satisfeitas. Portanto, essa métrica fornece uma maneira de estabelecer e acompanhar o nível de confiabilidade do software.

Gestão de Tempo em Projetos: 4 dicas essenciais

Métricas de Produtividade

Todo projeto deve ser produtivo. Para medir a produtividade de um projeto de software podem ser adotadas métricas, como por exemplo, o número de horas por homem, que aborda a produtividade da mão-de-obra aplicada, tendo também o objetivo de reduzir os custos do projeto.

Outra abordagem de produtividade pode ser considerada a métrica de número de horas por produto gerado (deliverables), que no caso da engenharia de software, é denominado de artefato. Portanto, pode-se medir o número de horas por artefato.

Com o apoio de uma base de informações históricas sobre projetos, podem ser estabelecidas metas para aumentar a produtividade, isto é, reduzir o número de horas por homem ou número de horas por artefato.

A fim de monitorar a produtividade pode ser adotada a métrica de custos, que visa comparar, ao longo do tempo do projeto, o custo planejado com o realizado, através do controle executado pelo gerente de projeto.

Métricas de Produtividade

O FPA (Function Point Analisys), ou análise de ponto por função, determina o tamanho e a complexidade de um software. Ao invés de contar as linhas de código, essa métrica concentra-se na quantificação da funcionalidade do software. Ponto por função baseia-se na visão do usuário e mede o que é um sistema, o seu tamanho funcional. Também pode medir a relação do sistema com usuários e com outros sistemas.

A contagem dos pontos por função se dá sobre cinco elementos funcionais básicos de um sistema modelado:

  • Arquivos Lógicos Internos (ALI).
  • Arquivos de Interfaces Externas (AIE).
  • Entradas Externas (EE).
  • Consultas Externas (CE).
  • Saídas Externas (SE).

Para essa contagem deve ser considerada a complexidade de cada elemento funcional. A complexidade dos Arquivos Lógicos Internos e dos Arquivos de Interfaces Externas leva em consideração o número de registros lógicos e o número de itens de dados referenciados.

A complexidade das Entradas Externas, Saídas Externas e Consultas Externas é baseada no número de arquivos referenciados e no número de itens de dados referenciados. No manual de práticas de contagem de pontos por função do International Function Point Users Group (IFPUG) são apresentadas tabelas e diretrizes para a determinação da complexidade dos elementos funcionais.

Leia também  Sponsor do projeto #2: o que faz um patrocinador de projeto?

Os elementos funcionais são totalizados para a obtenção dos pontos por função não ajustados (PFNA).

O fator de ajuste de pontos por função (FAPF) é calculado a partir 14 (quatorze) características gerais de que permitem uma avaliação do nível de influência das funcionalidades do software:

  1. Comunicação de dados.
  2. Processamento distribuído.
  3. Desempenho.
  4. Utilização do equipamento.
  5. Volume de transações.
  6. Entrada de dados on-line.
  7. Atualização de dados on-line.
  8. Procesamento complexo.
  9. Reutilização de código.
  10. Facilidade de implantação.
  11. Facilidade operacional.
  12. Eficiência do usuário final.
  13. Multiplicidade de locais.
  14. Facilidade demudanças.

A cada característica atribui-se um peso de 0 (zero) a 5 (cinco), conforme o nível de influência no software. Somando-se o nível de influência de cada caracterísitica, obtem-se o nível de influência geral no software (NIGS).

Segundo (PINHEIRO, 1998) apud (MIRANDA, 2002) essas características influenciam em até 35% o tamanho do projeto de software, ou seja, o projeto pode variar de 0,65 até 1,35.

O fator de ajuste de pontos por função é obtido pela fórmula:

FAPF = VTPS + (NIGS * 0,01)

O total de pontos por função ou pontos por função ajustados (PFA) é o resultado da multiplicação do número de pontos por função não ajustados (PFNA) pelo fator de ajuste de pontos por função:

PFA = PFNA * FAPF

Assim, alguns softwares que a princípio parecem pequenos, quando em desenvolvimento, mostram-se muitas vezes maiores do que o inicialmente previsto, podendo afetar drasticamente o gerenciamento do projeto.

Métricas Orientadas ao Objeto

  • Software: orientado a objeto é baseado na composição e interação entre diversas unidades chamadas objetos.
  • Objeto: é uma instância de uma classe. Um objeto é capaz de armazenar estados através de seus atributos e reagir a mensagens enviadas a ele, assim como se relacionar e enviar mensagens a outros objetos. Classe representa um conjunto de objetos com características afins. Uma classe define o comportamento dos objetos, através de métodos, e quais estados ele é capaz de manter, através de atributos.
  • Classe: representa um conjunto de objetos com características afins. Uma classe define o comportamento dos objetos, por meio de métodos, e quais estados ele é capaz de manter, através de atributos.
  • Mensagem: constitui uma chamada a um objeto para invocar um de seus métodos, ativando um comportamento descrito por sua classe, podendo mudar o valor de um ou mais atributos, alterando o estado de um objeto.
  • Método: é uma rotina que é executada por um objeto ao receber uma mensagem. Ele pode ser público, quando é utilizado por vários aplicativos (software) ou privados, quando criado ou utilizado pelo aplicativo (software) do projeto.
  • Atributo: significa o elemento que define a estrutura de uma classe. Os atributos também são conhecidos como variáveis de classe, e podem ser divididos em dois tipos básicos: atributos de instância e de classe. Os valores dos atributos de instância determinam o estado de cada objeto. Um atributo de classe possui um estado que é compartilhado por todos os objetos de uma classe.

Conforme Gomes (2001), existem várias propostas para métricas orientadas ao objeto que consideram as características e interações do sistema. Tais métricas baseiam-se na análise detalhada do do sistema.

Para efetivação de uma métrica orientada a objetos, é essencial o acréscimo de um peso às características das classes, o qual produzirá um fator de ajuste de complexidade orientado a objeto (FACOO), assim como se faz com os parâmetros de métrica de ponto por função.

Deve-se dar uma maior importância às características de reusabilidade de código produzido, assim como considerar a utilização de componentes pré-implementados, quando da definição das bases para o fator de ajuste de complexidade orientado a objeto. A maioria das medidas examina atributos em termos dos conceitos de Orientação a Objeto, como herança, polimorfismo e encapsulamento.

  • Herança: constitui o mecanismo pelo qual uma classe pode estender outra classe, aproveitando seus comportamentos (métodos) e estados possíveis (atributos).
  • Polimorfismo: é a ação que permite a um objeto se comportar de acordo com sua classe. Dessa forma, é possível se relacionar com objetos de classes diferentes, enviar mensagens iguais e deixar o objeto se comportar de acordo com sua classe.
  • Encapsulamento: consiste na separação de aspectos internos e externos de um objeto. Esse mecanismo é amplamente utilizado para impedir o acesso direto ao estado de um objeto, disponibilizando externamente apenas os métodos que alteram esses estados.

O número de pontos por função orientados a objeto (PFOO) pode ser obtido aplicando-se a fórmula:

PFOO = PFNA x (VTPS + FACOO x 0,01))

Ressalta-se que é fundamental realizar medições em um número significativo de softwares já desenvolvidos, selecionando as classes, os métodos e os atributos desejáveis para a obtenção dos dados históricos necessários ao embasamento das estimativas dos próximos softwares a serem desenvolvidos. É possível que seja mais fácil colher os dados durante os projetos atuais de desenvolvimento, do que tentar obtê-los de softwares desenvolvidos anteriormente.

Leia também  Pontos importantes para gerenciar projetos de inovação

É interessante saber como o projeto está se comportando no tempo, com o objetivo de averiguar se o produto será concluído no prazo planejado. Para avaliar o progresso do projeto, deve-se medir quanto de trabalho é realizado em relação ao programado.

Para isso, podem ser aplicadas as seguintes métricas:

  • Número de classes.
  • Número de casos de uso.
  • Pontos por casos de uso.
  • Número de casos de teste.
  • Número demétodos.
  • Média demétodos por classe.
  • Média de linhas de código pormétodos.
  • Relação existente entremétodos públicos e privados, entre outros.

Conclusões

As medições e as métricas permitem um melhor entendimento do processo utilizado para desenvolver um produto, assim como uma melhor avaliação do projeto e do próprio produto. As medições podem permitir melhorias no processo, aumentando a produtividade e comparações entre projetos de desenvolvimento.

Constata-se que a partir da utilização de um planejamento de garantia de qualidade que contenha o estabelecimento de métricas, adquire-se um histórico e, por meio dele, a qualidade e produtividade do projeto irá aumentar, diminuindo assim a margem de erros.

A princípio, é necessário determinar o que se quer medir, definindo como os dados serão coletados. Essas decisões devem ser compatíveis com o projeto de desenvolvimento.

Um modelo de métrica não vai solucionar de imediato os problemas do desenvolvimento, no entanto, as métricas devem ser utilizadas para tornar possível o entendimento do processo, para facilitar a previsão de suas fases e mostrar como controlá-las.

Verifica-se, então, que não existem modelos consistentes de métricas para aplicação orientada a objeto. Uma prática comum é aplicar as métricas de tamanho e complexidade que foram desenvolvidas para softwares procedimentais, tratando métodos da mesma forma que procedimentos, adequando a utilização à orientação a objeto.

Recomenda-se não adotar apenas métricas primitivas, mas estabelecer métricas derivadas com a composição de várias métricas obtendo, assim, uma abordagem mais específica, de acordo com a necessidade do projeto, com vistas à criação de uma base histórica para poder realizarem-se comparações entre os projetos.

É conveniente realizar a coleta das métricas ao longo do desenvolvimento do projeto. Então, deve-se eleger a abrangência da coleta, isto é, estabelecer se as métricas serão coletadas por semana, por mês, por iteração, por módulo do sistema, por equipe etc. É indicada a adoção da coleta por iteração para o monitoramento do projeto e a coleta por módulo ou por classe para avaliação da qualidade do produto.

Vale salientar que quando se adota um processo iterativo, a coleta e a interpretação das métricas não deve ser feita da maneira usada num processo cascata para não gerar problemas e preocupações desnecessárias. Num processo cascata, para se medir o progresso do projeto, a disciplina de requisitos deve estar completa quando o projeto estiver com 25% de seu tempo. Essa realidade não é aplicada em um processo iterativo, uma vez que a disciplina de requisitos fica completa somente na última iteração. Fato que normalmente não ocorre na marca de 25% do tempo do projeto.

É proposta a utilização da medição dos custos da qualidade, número de não conformidades do processo por FPA, número de horas por classe, número de horas de retrabalho por FPA ou por método, tempo médio entre falhas, número de defeitos por classe, método ou FPA, número de solicitações de mudança por FPA ou classe (para medir as alterações de escopo), número de classes privadas por classes públicas e percentual de reutilização de métodos/componentes, entre outros.

Conclui-se que existe a preocupação com a qualidade dos projetos de desenvolvimento de software orientado a objeto e que as métricas são ferramentas que o gerente de projeto deve utilizar para diagnosticar e corrigir o rumo do projeto. Portanto, deve-se por em prática a adoção de métricas orientadas a objeto, combinadas com os demais tipos de métricas.

Por se tratar de mudança de paradigma, essas métricas ainda não estão consistentes, entretanto, o exercício constante das medições formará uma base para os ajustes necessários no modelo adotado.

Aproveite para aprender também sobre a gestão de performance com indicadores (KPIs).

melhores indicadores projeto

Rafael Correa

Sócio diretor da Euax, graduado em Economia pela Univille, possui mais de 16 anos de experiência em projetos de desenvolvimento e implantação de software. É certificado PMP, ITIL Foundation e Lean IT.

Deixe uma resposta

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

onze − seis =

Consultoria Conduzimos gestores e suas equipes à conquista de resultados! Outsourcing Alocação de profissionais especializados e de alta maturidade Capacitação Treinamentos In Company