软件度量的目的是以定量化的方式帮助人们理解、控制和改进软件的质量，它是项目工作量/成本估算、开发进度追踪、产品复杂性评估、软件质量理解等软件开发活动的基础。

在软件产品的量化方面，主要有规模、复杂性、内聚性和耦合性等度量。在规模度量上，源代码行数（Source Lines Of Code; SLOC）、软件科学法（software science）和功能点度量是代表性的三类度量。SLOC对源代码的规模进行量化，指不包括注释行和空白行在内的代码行数；软件科学法对算法的规模进行量化，由词汇量、长度、容量等一组度量构成；功能点度量在需求分析文档上对软件的功能进行计数，主要用于开发工作量估算。圈复杂度（cyclomatic complexity）对控制流复杂性进行量化，数值上等于线性独立的路径数目。内聚性度量用于量化模块内部各成分之间联系的紧密程度，其中内聚缺乏度（lack of cohesion in methods; LCOM）是最具代表性的内聚性度量。耦合性度量用于量化模块之间的耦合程度，其中之间的耦合对象类（coupling between objects; CBO）是最具代表性的耦合性度量。

在软件开发资源的量化方面，美国软件工程师B.勃姆（Barry Boehm）等人提出的COCOMO模型中将其分为产品、计算机、人力和项目四类特性进行量化。在产品特性上，对软件可靠性、数据库规模和产品复杂性进行量化；在计算机特性上，对执行时间约束、存储大小约束等进行量化；在人力特性上，对分析能力、应用经验、编程能力、虚拟机经验和语言经验进行量化；在项目特性上，对线代编程经验和开发进度等与方法和工具有关的属性进行量化。在2008年，微软研究院对软件开发团队的组织结构提出了一系列量化度量。

在软件开发过程的量化方面，常见的过程度量包括代码churn度量、开发者数目、开发者的开发经验、模块被修订的次数和在先前版本中的缺陷数目等。过程度量是对软件开发过程的各个方面进行度量，目的在于预测过程的未来性能，减少过程结果的偏差，对软件过程的行为进行目标管理，为过程控制、过程评价持续改善提供定量性基础。过程度量与软件开发流程密切相关，具有战略性意义。软件过程质量的好坏会直接影响软件产品质量的好坏，度量并评估过程、提高过程成熟度可以改进产品质量。而且度量并评估软件产品质量还会为提高软件过程质量提供必要的反馈和依据。

软件度量的理论基础是测度论（measurement theory），其过程分为如下四步：第一步，利用度量（metric）将现实世界中的实体属性映射为数值世界中的数值（或者符号）。第二步，在数值上进行统计分析，得到统计量。第三步，对实验结果进行解释。第四步，将所得的解释和现实世界中的经验关系进行对照，验证其正确性。为了得到有用的度量，在第一步中定义的度量需满足表达条件（representation condition），使得实体在特定属性上的经验关系在数值关系中能得到保留。在第二步，需根据度量的刻度类型（scale type）确定度量值上可进行什么样的统计分析。在第三步，需要清楚对分析结果进行什么样的解释是有意义的。在第四步，验证所提出的度量是否真的量化了所想要量化的实体属性。在上述步骤中，第一步是确保得到理论上有效的度量，其前提是需要对实体之间的经验关系（在所关注的属性上）有深刻的认识。然而，人们对软件实体的经验关系的认识程度还很有限，难以设计出满足表达条件的度量。在实践中，当前在软件工程中使用的许多度量并不满足表达条件，在理论上不是有效的度量。

软件度量啟始于20世纪60年代，典型的应用场景包括软件质量评估和开发工作量估算。在1976年，B.勃姆等人在软件度量的基础上提出了软件质量度量的层次式模型，定量地评价软件质量的概念。1978年，G.F.沃尔特斯（Gene F.Walters）和J.麦考尔（Jim McCall）提出了从软件质量要素（factor）、评价准则（criteria）到度量（metric）的三层次式的软件质量度量模型，将软件质量要素降为11个，且给出了各要素的关系。在20世纪80年代，B.勃姆等人在软件度量的基础上提出了COCOMO模型，用于估算软件项目的开发工作量。早期的软件度量大多集中于产品度量，代表性的度量包括T.J.麦卡贝（Thomas J.McCabe）提出的圈复杂性度量和M.H.霍尔斯特德（Maurice H.Halstead）提出的软件科学法度量。在20世纪90年代，对软件复杂性度量、面向对象度量进行了系统的梳理和总结。进入21世纪，研究重点偏向于软件过程度量或开发团队的组织结构度量。在2010年后，随着人工智能技术的发展，研究人员开始探索软件度量的自动化抽取方法，而不是费时费力的人工设计。软件研究人员及从业人员已经提出了上千种软件度量。