Durante a história da engenharia de software muitas métricas surgiram e passaram a ser utilizadas para mensurar software, bem como suas derivações de esforço, tempo, custo e qualidade. Dentre estas métricas destacarei: linhas de código, hora/homem, UCP e APF.
Linhas de Código
Por muito tempo utilizou-se o método linhas de código (LoC – Lines of Code) como medição de complexidade ou tamanho de um software. Como o próprio nome sugere, a mensuração é realizada contabilizando o número de linhas de código produzidas para desenvolver o software a ser mensurado.
É um método simples de mensurar software, introduzido em cerca de 1960, sendo considerado o método mais antigo de mensuração de software.
Possui duas variações: Lógico (LLoC) e Físico. (PLoC). A diferença entre as duas opções é basicamente considerar ou não comentários e linhas em branco, e fisicamente as linhas de código ao invés de “statments“. O que isso quer dizer?
for (i = 0; i < 10; i++) printf("hello world"); /*Quantas linhas de código temos aqui?*/
No cenário acima temos:
PLoC: 1
LLoC: 2
/*Quantas linhas de código temos aqui?*/
for (i = 0; i < 10; i++)
{
printf("hello world");
}
Já no segundo cenários temos:
PLoC: 5
LLoC: 2
Pelos cenários acima expostos podemos perceber que utilizar o método lógico soa mais “justo”. Entretanto, o método LoC em si possui alguns problemas evidentes. Vejamos:
Um software com 15 mil linhas de código é necessariamente mais complexo que um software com apenas 5 mil linhas de código? E se esses softwares forem desenvolvidos por equipes distintas cuja maturidade de código seja diferente? E se no software de 5 mil linhas tenham sido utilizados padrões de qualidade não utilizados no código de 15 mil linhas? Conseguiu perceber que linhas de código não reflete proporcionalmente a complexidade de um software, não é mesmo?
Se houvesse uma padronização única de codificação para cada linguagem de programação, talvez global, regido por um documento referencial, essas discrepâncias pudessem ser reduzidas. Entretanto, esse controle atualmente não funciona a contento.
Durante a vida de um software, linhas de código são adicionadas e removidas, por conta de melhorias, inclusões ou remoções de funcionalidades, refactors, ou correções de bugs. Grande parte dessas mudanças (especificamente provenientes de refactoring) não correspondem à aumento ou diminuição do tamanho do software propriamente dito. Nestes casos em que, por exemplo, a diminuição das linhas de código se deu através de atividades de refactoring, o método LoC é falho, já que se adotado, o resultado será que o software “diminuiu” de tamanho, o que é uma inverdade, tendo em vista que o tamanho não sofreu impacto, mas sim a qualidade do código.
Apesar da técnica LoC não ser uma boa métrica para mensuração de tamanho do software, a mesma pode contribuir positivamente na perspectiva de métrica de qualidade ou boas práticas de desenvolvimento de software, utilizando como indicador de que o código do software analisado necessita de refactoring, por exemplo.
Hora/Homem
Ainda hoje, muitas empresas utilizam o método horas técnicas ou hora/homem para realizar as mensurações de software. Essa técnica também é muito simples, utiliza base histórica e opinião especializada para a mensuração do trabalho. É aplicado não apenas a desenvolvimento de software, mas a outras atividades como por exemplo suporte.
Entretanto, vamos analisar o seguinte cenário: dizer que um software ou funcionalidade vai custar (tempo) 30h/h enquanto outra funcionalidade (talvez desenvolvida por outra equipe) custará 50h/h, não quer dizer necessariamente que o segundo cenário é mais complexo. Há muitas variáveis que podem estar envolvidas, como a própria experiência da equipe envolvida. Primeiramente, se tratando de um método utilizado tanto para mensuração de tempo e esforço, como de custo, é justo que o cliente pague mais pelo desenvolvimento de um software realizado por uma equipe menos experiente que consequentemente vai precisar de mais h/h para concluir o projeto? Percebe que está métrica, assim como a primeira apresentada, não é parametrizável?
UCP
Criado por Gustav Karner em 1994, o método UCP além de avaliar o modelo de casos de uso, também considera fatores de complexidade técnica e fatores ambientais.
Iniciamos o assunto falando de casos de uso, que é o principal insumo para a mensuração utilizando a técnica UCP. Apesar da UML ser uma técnica bastante disseminada e popular, a escrita de casos de uso, a granularidade dos detalhes e passos, não é padronizada. Há grande variação destes itens de acordo com a necessidade de cada projeto, e da percepção de cada analista. Há diretrizes, melhores práticas, mas não regras padronizadas.
O que isso quer dizer? Quer dizer que, se a especificação de casos de uso é o principal insumo para essa mensuração, e a concepção desse insumo não é padronizada, logo, como auditar? Como garantir que o resultado não foi feito de pouco ou demasiado detalhamentos dos passos dos fluxos? Como garantir que o mesmo software especificado por uma equipe terá a mesma quantidade de pontos por caso de uso que o mesmo software especificado por outra equipe? Atualmente isso ainda não é possível.
APF
Surgiu em meados da década de 70, e seu uso tem sido muito crescente dentre organizações no mundo todo. É muito utilizado por órgãos públicos, devido ao fato de permitir auditoria.
O método é reconhecido e utilizado internacionalmente, possui um manual (CPM – Manual de Práticas de Contagem) que promove a interpretação consistente da medição funcional de software, estando em conformidade com a ISO/IEC 14143-1:2007.
A métrica objetiva mensurar o software quantificando as tarefas e serviços oferecidos ao usuário, com base em seu projeto lógico.
A unidade de medida resultante deste método de medição de software é o Ponto de Função. Para derivar a medida buscando determinar esforço, tempo, custo e qualidade, deve-se utilizar base histórica.
Como insumo para este método podem ser utilizados diversos artefatos, como, documento de especificação de requisitos, protótipos de tela, modelo conceitual, modelo de classes, modelagem de dados, entre outros, desde que, tomando o devido cuidado para levar sempre em consideração a visão do usuário.
APF está em vantagem frente aos outros métodos de mensuração tendo em vista que é suficientemente simples de ser aplicada objetivando minimizar o esforço adicional introduzido pela prática; é uma medida consistente entre diversos projetos e organizações; além de possuir um manual de práticas de contagem (já citado CPM).
Quanto a simplicidade mencionada acima, a APF possui três níveis de detalhamento para mensuração do software: contagem indicativa, contagem estimativa, e contagem detalhada. Para cada fase da engenharia em que se encontra o software no momento da mensuração, há um nível adequado para a mensuração.
Exemplo:
- Durante a fase de iniciação, onde é conhecido apenas o escopo macro do software, pode-se utilizar a contagem indicativa.
- Enquanto na fase de planejamento, após a realização de algumas reuniões de entendimento do escopo, pode-se utilizar a contagem estimativa.
- Já a contagem detalhada, é aplicada quando os requisitos estão completamente detalhados (campos e regras de negócio).
É possível perceber alguns padrões que facilitam a mensuração APF de um software analisando sua especificação de requisitos. Pode-se adotar estratégias de escrita dos requisitos finais do software respeitando os critérios que determinam o processo elementar, sendo assim, um requisito funcional do software poderia corresponder a um processo elementar, e com isso, a uma função de transação. Essas estratégias podem simplificar e agilizar mais ainda o processo de mensuração do software.
Analisando os diferenciais e características da APF, se o mesmo software for medido pela equipe A e pela equipe B, os resultados desta mensuração em pontos de função serão os mesmos. Além disto, caso necessário (é um recurso muito utilizado em licitações públicas) o processo de medição do desenvolvimento de um software contratado pode ser auditado, buscando validar o resultado da mensuração.
Além de utilizar como métrica para mensuração do software na perspectiva tempo, esforço e custo, é possível determinar outras derivações, como: velocidade da equipe (quantos PF cada equipe desenvolve por mês), custo do time versus custo do PF contribuindo para tomada de decisão, entre outros cenários.
Ficou claro que utilizar APF além de simples é mais seguro se comparado às demais métricas apresentadas?
Referências
JONES, Capers. (2008) A Short History of Lines of Code (LOC) Metrics.
CELEPAR (2006) Plataforma de Desenvolvimento Pinhão Paraná: Métrica para Estimativa de Projetos – UCP.
IFPUG (2011). Manual de Práticas de Contagem de Pontos de Função: versão 4.3.1.