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