可以在软件产品中测量各种类型的质量，例如适用性（例如最终用途），可维护性，效率。其中一些在某种程度上是主观的或领域特定的（例如，良好的GUI设计原则可能因文化不同或依赖于使用环境，考虑军事用户和消费者使用）。
我感兴趣的是与类型的网络（或图形）及其相互关联相关的更深层次的质量形式，即每种类型所指的类型，是否存在明显可识别的互连关联集群到一个适当的分层架构，或相反，有一个类型引用的大'球'（'单片'代码）。此外，每种类型和/或方法的大小（例如，以Java字节代码或.Net IL的数量来衡量）应该给出一些指示，表明大型复杂算法已作为整体代码块实现，而不是分解为更易于管理/维护的块。
基于这些想法的分析可能能够计算至少代表质量的指标。高质量和低质量之间的确切阈值/决策点我怀疑是主观的，例如因为可维护性是指人类程序员的可维护性，因此功能分解必须与人类思维的工作方式兼容。因此，我想知道在所有可能的场景中是否可以存在超越所有可能软件的数学上纯粹的软件质量定义。
我也想知道这是一个危险的想法，如果质量的客观代理变得流行，那么业务压力将导致开发人员以牺牲整体质量（代理人未衡量的质量方面）为代价来追求这些指标。 / p>
ADDENDUM：另一种思考质量的方法是从熵的角度出发。熵是系统从有序状态恢复到无序状态的趋势。任何从事现实世界，中型到大型软件项目的人都会理解代码库的质量随着时间的推移会降低的程度。业务压力通常导致关注新功能的变化（除非质量本身是主要卖点，例如在航空电子软件中），并且通过回归问题和“鞋子function”功能的劣化，其中它不适合质量和维护的角度。那么，我们可以测量软件的熵吗？如果是这样，怎么样？