Você não
A qualidade do software é realmente difícil de medir objetivamente. Difícil o suficiente para que não haja uma solução. Eu estou me abstendo nesta resposta de me perguntar se pode haver uma solução, mas simplesmente aponto por que definir uma seria realmente difícil.
Raciocínio por status quo
Como Kilian Foth apontou, se houvesse uma medida simples para um software "bom", todos nós o estaríamos usando e todos exigiriam.
Existem projetos nos quais os gerentes decidiram aplicar determinadas métricas. Às vezes funcionava, às vezes não. Não tenho conhecimento de nenhuma correlação significativa. O software de sistemas especialmente crítico (pense em aviões, carros etc.) possui muitos requisitos de métricas para "garantir" a qualidade do SW - não tenho conhecimento de nenhum estudo que mostre que esses requisitos realmente resultem em maior qualidade e tenho experiências pessoais com o contrário.
Raciocínio por contra-inteligência
Também sugerido por Kilian, e mais geralmente expresso como "todas as métricas podem e serão reproduzidas".
O que significa reproduzir uma métrica? É um jogo divertido para desenvolvedores: você garante que os valores das métricas pareçam realmente bons, enquanto faz coisas realmente de merda.
Digamos que você mede defeitos por LOC. Como eu vou tocar isso? Fácil - basta adicionar mais código! Crie um código estúpido que resulte em uma não operação de mais de 100 linhas e, de repente, você terá menos defeitos por LOC. O melhor de tudo: você realmente diminuiu a qualidade do software dessa maneira.
As falhas da ferramenta são abusadas, as definições são esticadas ao máximo, formas completamente novas são inventadas .. basicamente, os desenvolvedores são pessoas realmente inteligentes e você deve ter apenas um desenvolvedor em sua equipe que se diverte jogando métricas, então suas métricas serão questionáveis.
Isso não quer dizer que as métricas sejam sempre ruins - mas a atitude da equipe em relação a essas métricas é crucial. Em particular, isso implica que não funcionará bem em nenhum relacionamento de subcontratado / fornecedor terceirizado.
Raciocínio por segmentação incorreta
O que você deseja medir é a qualidade do software. O que você mede é uma ou mais métricas.
Há uma lacuna entre o que você mede e o que você acredita que isso lhe dirá. Essa diferença é meio que enorme.
Isso acontece o tempo todo em todos os tipos de empresas ao nosso redor. Você já viu decisões baseadas em KPIs (principais indicadores de desempenho)? É exatamente o mesmo problema - você quer que uma empresa se dê bem, mas mede outra coisa.
Raciocínio por quantificabilidade
Métricas podem ser medidas. Qual é a única razão pela qual lidamos com eles. A qualidade do software, no entanto, estende-se muito além dessas entidades mensuráveis e é muito difícil quantificá-la: Qual é a legibilidade do código-fonte? Quão extensível é o seu design? Quão difícil é a integração de novos membros da equipe? etc etc.
Julgar a qualidade do software apenas por métricas e fechar os olhos para as partes da qualidade que você não pode quantificar certamente não vai funcionar bem.
editar:
Sumário
Deixe-me salientar que o exposto acima é sobre objetivamente julgar se o software é bom ou ruim com base em métricas. Isso significa que não está dizendo nada sobre se e quando você deve aplicar métricas.
De fato, essa é uma implicação unidirecional: métricas ruins implicam código incorreto. Unidirecional significa que um código incorreto não garante métricas ruins, nem boas métricas garantem um código bom. Por outro lado, isso por si só significa que você pode aplicar métricas para julgar um software - quando você mantiver essa implicação em mente.
Você mede o software A e as métricas ficam muito ruins. Então você pode ter certeza de que a qualidade do código é ruim. Se você mede o software B e as métricas estão corretas, não tem idéia da qualidade do código. Não se iluda pensando em "métricas boas = código bom" quando realmente é apenas "código bom => métricas boas".
Em essência, você pode usar métricas para encontrar problemas de qualidade, mas não a própria qualidade.