指标体系框架-度量质量

1、内部质量

“唯一的现实存于我们的內在。让大多数人生活得如此虚伪和没有价值的原因，是他们错误地把外在形象看作现实，却从不允许內在世界发言。”

——赫尔曼·黑塞（1877—1962）

ISO/IEC 25010 产品质量模型

提升内部质量的动力来源于：

（1）对于生命周期较长的产品，降低其持续开发的成本；

（2）对于当前版本来说，提高开发进度的可靠性，降低后端测试周期长度和工作量的不确定性。

主要是技术债。

2、外部质量

2.1 度量产品质量

2.1.1 用户满意度

用户直接使用之后的感觉和反应，通常有直接和间接两种方式来度量。

2.1.2 产品可靠性

可靠性是指在特定的使用场景下、特定的环境中、特定时间段内，系统不出故障的概率。

可靠性和缺陷密度之间存在很强的正相关关系。观察一个软件系统潜在缺陷，通常是用缺陷密度（Defect Density）的历史数据，一个例子是千行代码缺陷数（Defects per KLOC）。

2.1.3 故障成本

故障的统计指标可以包含：发布后1周，1个月，一年，二年，三年……的缺陷的数量、严重程度、解决周期、解决累计成本（时间）。

另一类统计指标是缺陷影响到的用户、用户群的数量或比例，以及用户的优先级。

2.2 提升开发过程质量

2.2.1 缺陷防范

可能防范的缺陷主要来自3个方面：

（1）由于技术或是业务能力不足而引入的缺陷，通过学习、能力提升来防范。

（2）不必要的复杂度提高了引入问题的可能性，降低复杂度，就可以减少人们犯错的机会。

（3）在沟通中，信息的丢失或是误解也是造成问题的主要原因。

对于这类问题的防范手段主要有：

◆包含多种角色参加的分析、设计Workshop；

◆各种将分析、设计结果具象化的手段，比如：手绘概念原型，高、低解析度的设计原型，验证性的代码和测试；

◆使用系统化的分析、设计方法：比如：用户旅程（User Jour-ney），结构化的需求分析技术，架构设计技术（比如风险驱动的架构设计）；

◆使用ATDD，Specification by Example等手段，及早引入测试人员。

缺陷防范反馈图

2.2.2 更早发现缺陷

迭代开发模型的一个重要意图就是缩短从问题产生到发现到排除的时间，从而降低成本和项目的风险.

迭代开发模型的问题反馈机制

团队层面的质量保障活动：

•TDD/单元测试——功能代码完成的同时，达成接近全面的单元测试覆盖；

•结对编程——持续的代码走读过程，实时的反馈；

•团队代码走读——发现跨模块、跨特性问题的手段之一，但又是知识共享的过程，在团队范围内对质量达成共识的机会；

•用户故事验收测试——在用户故事DoD层面的缺陷排除；

•回归测试——在迭代或是版本发布DoD层面的缺陷排除。

多层质量保护网 用DoD牵引质量保障活动的提前

2.2.3 减少回归缺陷

自动化的单元测试，功能测试和集成测试。

3 小结

度量帮助组织和团队观察开发过程中实际发生的活动，并将观察结果跟计划或预期相对照，了解行动的有效性。通过这样的一个正向反馈，持续学习，持续改进我们的开发方法。