Comentário a respeito de métricas de software
O mundo que conhecemos não seria possível sem a utilização de medidas. A realização de medidas pressupõe a existência de métricas. No entanto, há uma situação em que utilizam-se métricas, e não se consegue medir algo: há métricas para distâncias astronômicas, realizam-se medidas de distâncias astronômicas, mas não se tem uma medida de tamanho do Universo.
Quanto à área de software, as métricas existem, e normalmente não se mede. Em alguns casos contam-se arquivos, programas, linhas de código, tabelas, componentes, interfaces, telas, condições lógicas, mensagens, classes etc. É sempre possível achar algo para quantificar. O problema é muitas dessas medidas não servem para comparar situações, não servem para gerenciar, para controlar, ou para tomar decisões.
Uma célebre “filosofia” diz: não se pode gerenciar o que não se pode medir; não se pode medir o que não se pode descrever. O caminho é descrever->medir->gerenciar. A métrica corresponderia ao componente “descrever” da “filosofia”. A métrica é anterior ao medir, é necessária à realização da medida, diz qual é o objetivo de medir, e como medir.
Para que uma métrica seja útil, o seu entendimento tem de ser comum. É sempre possível criar métricas por conta própria. Estas normalmente farão (ou parecerão fazer) sentido.
Por volta de 1990, numa software house em que atuei, estimava-se o tamanho e complexidade dos sistemas que seriam desenvolvidos com base em quantidade de "tabelas principais", quantidade de "tabelas intermediárias", quantidade de "tabelas de apoio" (do tipo Código - Descrição), quantidade de menus, quantidade de itens em cada menu, quantidade de "programas CRUD", quantidade de "programas não-CRUD", fator de complexidade (usado em alguns sistemas para a área de Engenharia), e alguns outros elementos. Estimava-se os esforço de desenvolvimento com base num Diagrama de Fluxo de Dados, um Diagrama de Entidades e Relacionamentos, um Diagrama de