Fórum Mátricas de Qualidade de Software #388416

Na verdade não creio que as métricas de projeto sejam inadequadas, creio sim que estão sendo mal utilizadas e que devem ser adaptadas a cada projeto. Mas a qualidade de desenvolvimento tem um grande projeto, que normalmente é a etapa de levantamento e analise de projeto, ou a Engenharia de Requisitos. É dificil criar a metrica correta, se não sabe qual o objetivo real do projeto, nem onde devemos chegar. É mais dificil ainda quando nem o cliente sabe o que quer. Ja ha evolução neste processo com a melhoria das tecnicas de Engenharia de Requisitos, ja os medotos de métricas ainda devem sofrer melhorias e se adaptar as novas dimensões do desenvolvimento e as novas técnicas.

As métricas de projeto (por exemplo, Pontos de Função) são boas para medir o tamanho do projeto. Entendamos como tamanho do projeto aquele número que nos informará, em consequência, quanto tempo pode tomar o desenvolvimento do projeto e quanto ele poderá custar, e, em alguns casos, até a complexidade do mesmo - apesar de não ser este o propósito.

Em outras palavras, comparando com a construção civil, construir uma obra de 1.000m2 implica um esforço. Construir outra de 300m2 implica num esforço diferente. Às vezes, 1000m2 pode ser bem mais fácil apesar de ser bem maior.

Medir o projeto permitirá mais à frente, cobrar o projeto.

Medir o projeto não é avaliar a qualidade do projeto. Alias, está muito longe de ter como propósito avaliar a qualidade. Outras ferramentas de avaliação da qualidade devem ser usadas, a medição do projeto não serve para isto.

A métrica de Ponto de Função, por exemplo, é uma métrica consolidada, utilizada mundialmente, e bem aceita em órgãos governamentais. No caso desta métrica, os requisitos já devem estar completos, pois ela necessitará de informações sobre Arquivos (termo lógico - não físico), e dados (o que normalmente entendemos como campos de tabelas). Ou seja, é preciso ter definido: as entradas, as saídas, os procedimentos do projeto (as transformações sobre os dados).

Espero ter ajudado.

Nao ajuda somente a medir desempenho, mas ajuda para mim:   -custo -desempenho / programador -taxas de erros -numeros de processos para realizar uma tarefas (co-dependentes) -estimativa de lucro -serve para compor um orçamento mais adequado e levantar outros pontos que podem ser relevantes ou nao para os envolvidos(stakeholders);   Também acredito que são poucos que utilizam em sua forma correta, digo isso dos pequenos e médios desenvolvedores, uma vez que, infraestruturas mais enxutas, levam ao desenvolvedor o papel de : desenvolvedor-analista-dba-gerente-vendedor...??? 1000 em um.. o que dificulta bastante a discussão interna e padronizacao interna desses metodos.   Att, Carlos Mazzi

Medir a qualidade do software ou processo é algo realmente difícil.
Utilizo o uso de indicadores que são um conjunto de métricas, esses indicadores são identificados através das regras de negócio, natureza, processo, estrutura organizacional utilizados na organização. Com esses indicadores é possível medir o andamento do processo e software (em construção), refletindo na qualidade destes.
O paradigma GQM é bastante utilizado (eu uso) para definir os objetivos do software/processo que por sua vez são desmembrados em questões para respondê-los e destas surgem as métricas que serão utilizadas para a medição.

Espero ter contribuído.

Complementando para exemplificar meu post acima um objetivo seria:

"Melhorar a precisão das estimativas do projeto".