https://www.ibm.com/developerworks/cn/devops/1609_liuy_quality/index.html
一、软件质量概览
1.1 Agile 对软件质量的影响
大多数软件质量从业者认为，软件质量衡量的直观标准就是软件存在 bug 的多少，是否具有高性能，以及是否具有高安全性。但实际上并不全面，更准确地说，软件质量的高低是由软件产品对用户产生的价值的高低衡量的。一方面，要体现对用户的需求的满足；另一方面，要体现软件本身的优势和特性。
对于第一方面，体现对用户的需求的满足：
从市场的角度说，用户需要的软件是要带给他们更多的利益。利益由两方面组成，开源和节流。开源就是要创造更多的利润，获得更大的市场；而节流是指，用更少的人力物力财力成本，去解决一个指定的问题。
对于另一方面，体现软件本身的优势和特性：
在满足第一方面的基础上，更少的软件产品缺陷，更好的产品易用性，扩展性，稳定性，安全性等，将从软件本身角度描绘了一个具有强大优势和特性的高质量软件产品。当然，针对不同领域的软件，衡量的标准也会有不同的视角。
以上两方面缺一不可，相辅相成。Agile 采用迭代反馈的方式不断寻求高质量的软件，同时满足了两方面的要求。
图 1.Agile 对软件质量的影响
如图 1 所示，橙色部分表示的需求风险，紫色部分表示产品自身质量风险。Agile 方法更注重客户的需求，在迭代中不断修正需求，尽量减少最终产品不满足用户需求的风险。
但同时也会因为由于过于频繁的需求变化，而导致软件自身质量风险急剧增大。
所以在市场的实践中，需要充分利用 Agile 的优势，并小心抑制随之带来的风险。
1.2 软件质量与成熟度模型
软件能力成熟度模型集成(CMMI)，将现有的实施以及未来的各种能力成熟度模型进行了集成，目的就是增强并改进软件过程，以最低的成本最高的效率，开发出最符合客户需求的高质量软件。
目前通用的成熟度模型有五级：
- 初始级：混乱无序的软件过程，成功与否完全依赖于个人的努力。
- 可重复级：有基本的项目管理过程去跟踪项目进度、成本等。
- 已定义级：具有过程的文档化、标准化。
- 量化管理级：软件质量和过程有的详细度量数据支持，并有定量的控制。
- 优化管理级：过程量化，并定量反馈信息，可持续改进。
从以上分析可以看出，成熟度越高，软件的质量将有更准确的信息去追踪、度量和改进，软件在质量上的风险也就越低。所以对软件过程不断优化，保持较高的成熟度水平，将在早期发现软件弱点，甚至达到预防缺陷的目标，这将从根本提高了软件的质量。
1.3 评估软件质量的方案讨论及意义
在传统的软件质量评估体系中，一般会有测试团队根据测试覆盖率等指标做出的内部质量评估，然后交给部分用户进行 alpha/beta 测试，得到部分外部质量评估后，最终投放市场才能够得到用户使用中质量的评估。而恰恰对于软件质量影响最大的过程是开发过程，很少有质量评估。
在传统的开发模型下，软件开发团队对于软件质量的预测通常根据内部质量评估与外部或者使用中质量评估对比的历史经验进行，与最影响质量的开发过程脱节。 有时，内部质量评估与外部质量最终差异较大，开发团队通常需要等待很长时间才能够得到外部的质量反馈，在此之前，软件产品质量的提升通常靠经验和猜测进行。
在敏捷开发模型下，各个环节的迭代速度明显提升，这给软件开发团队一个机会可以迅速获得开发过程实践与实际使用中质量之间的关系，使得开发过程质量预测和评估更为可行。
所以，我们的目标是建立一个应用在开发过程上的质量预测和评估体系。
图 2. Agile 开发过程的质量预测和评估
我们对敏捷开发的典型开发阶段应用了成熟度模型，为了简单，我们简化了 CMMI 的 5 级模式而使用三级成熟度模型：initial，managed 和 optimized。分别对敏捷开发的 6 个典型阶段，即 Plan，Design，Coding，Testing，Reflection 和 Process 进行成熟度定义。我们针对功能需求（Functional）质量与非功能需求（Structural）质量分别定义了一个初始的成熟度标准范围，并提供了标准成熟度描述的示例。在实际应用中，软件开发团队可以根据自身特点，结合标准的成熟度描述示例来制定自身的成熟度标准。同时，开发团队可以不断的根据外部质量和使用中质量的反馈进行经验迭代，将开发过程中导致质量问题的遗漏点捕捉到，并考虑用更高成熟度标准中的方法来解决这些遗漏点，从而不断提升开发过程的成熟度。
这样，我们就建立了一套软件质量的预测和评估体系，对照质量评估体系中的标准与软件开发过程中的实际行为，即可预测和评估软件质量。同时，这个体系自身也是持续改善的，会随着团队的成长而不断进化，让开发过程的质量预测和评估逐渐接近于外部质量评估和使用中质量评估。
二、基于 Functional 的软件质量评估方法
2.1 计划阶段
图 3.计划阶段各成熟度的要求
- Initial 阶段
要求项目范围明确，时间计划清晰，同时成本可估计。并且人力计划有章可循，风险可控。另外还建立了基本的软件项目计划规程，计划工作有章可循。初步实现标准化，可以较好地按标准计划后续工作。新项目的计划和管理基于过去的实践经验。
- Managed 阶段
这个阶段以可扩展性为典型特征，要求软件具有较高的适应"变化"的能力，比附需求、设计、算法、程序的变化等。
此阶段除了要满足 Initial 阶段的所有要求，还要达到项目计划实现的标准化和文档化。同时需要建立完善的项目计划评审制度以及合理性可度量的项目计划。除此之外，还要建立项目计划数据库，根据数据对比，实现对项目计划风险的准确预测。
- Optimized 阶段
首先要满足可验证性，即可以采用约定的各项量度标准，确保所选计量方法无误。Optimized 阶段也是在基于 Managed 阶段基础上，额外保证能够通过精确的数据统计和分析，合理完成计划的生成。并可以采用自动化工具改善、调整项目计划，预防项目计划盲点，识别项目计划薄弱环节。
2.2 设计阶段
图 4.设计阶段各成熟度的要求
- Initial 阶段
满足可用性（即易用性）以及可操作性（用户仅需花费较少代价即可完成软件的运行和控制）。除此之外，它要求建立基本的软件设计流程，且可以根据软件设计规章原则以及过去的经验，完成标准化模板设计。
- Managed 阶段
要求具有可扩展性、可维护性以及兼容性。这会使纠正一个软件缺陷或软件更改更容易，且多个软件交换信息的能力更强。
在实际操作过程中，为实现以上三个特性，需要遵守以下五点设计原则：
关键点的分离：将应用程序分成清楚的不同元素，使功能的重叠尽可能的少。
单一责任原则：每一个组件或模块应该只负责唯一一个特定的功能。
最少知识原则：组件或对象不需知道其他组件的内部实现细节，只需按照约定法则调用即可。
不要重复自己：一个组件对应提供一个功能，一个功能也只应由一个组件提供。而不能将功能的实现分散到很多其他的组件中去。
避免在前期做大量的设计：如果需求不清晰，就避免在项目前期做大量的设计工作。
Managed 阶段除了要满足 Initial 的所有要求，还要求软件设计实现标准化、文档化且合理性可以用数值度量。同时要求建立软件设计数据库，实现对软件设计缺陷的预测。
- Optimized 阶段
要求满足可修改性（保证对系统修改而不增加原系统的复杂程度）、可移植性（花费较少的工作量去完成软件运行环境转移）以及可伸缩性（软件通过较少的改动或仅仅添置硬件设备，就能实现整个系统处理能力的线性增长）。
Optimized 基于 Managed 阶段基础上，还可以采用自动化工具改进软件设计，并根据数据的统计分析，进行设计上的调整，同时可预防软件缺陷，并增加对外接口的友好性。
2.3 编码阶段
图 5.编码阶段各成熟度的要求
- Initial 阶段
Coding 时要求具有可理解性，即系统结构清晰，能直接反映需求；具有可操作性，即用户操作和运行软件尽可能简易，以及可扩展性。除此之外，满足实现了软件的功能需求，并根据设计规章原则完成了软件开发，且开发过程规范。
- Managed 阶段
要求具有可维护性、可移植性，以及可管理性（保证管理系统的便利）。
在满足 Initial 阶段要求基础上，还要实现标准化、文档化的软件开发过程，完善的软件开发培训制度和评审制度。并且建立开发过程数据库，可预测产品质量趋势以及开发偏差。
- Optimized 阶段
满足互操作性（产品与其它系统可以简易地交换数据和服务）、可修改性、可伸缩性、可靠性（软件可以较长时间地无故障执行的容侵能力）以及可生存性（即使计算机系统受到攻击，然仍能完成关键任务，具有高防侵能力）。同样在基于 Managed 阶段基础上，还可以采用自动化工具实现软件开发的改进，根据有效的数据统计得出最佳开发方法，同时可预防开发的缺陷，自动纠正问题，并保证软件的安全性和高性能。
2.4 测试阶段 Testing
图 6.测试阶段各成熟度的要求
- Initial 阶段
1.开发自测过程：测试过程规范，责任清晰(Peer To Peer)，测试范围和用例文档化并经过评审；
2.开发自测效果(bug)监控： 监控跟踪高严重级别 Severity1/2 的 bug，保证及时修复和验证(via scrum meeting)；
3.开发自测软件质量属性
可测试性：单元测试（UT）用例完备且可重复使用；
可验证性/可用性：FVT，GVT，AVT 通过率指标明确， 测试用例可重复使用；
4.SVT/性能测试软件质量属性
可靠性：保证软件的稳定性，性能指标明确，测试用例可重复使用。
- Managed 阶段
1.开发自测过程：测试过程规范，责任清晰(Peer To Peer)，测试范围和用例文档化，经过评审并借助工具进行管理；
2.开发自测效果(bug)监控： 借助工具监控跟踪高严重级别 Severity1/2 的 bug，保证及时修复和验证；
3.开发自测软件质量属性
可测试性：单元测试（UT）自动化并可周期执行进行回归测试；
可验证性/ 可用性：FVT，GVT，AVT 通过率指标明确， 实现自动化运行；
4.SVT/性能测试软件质量属性
可靠性：保证软件的稳定性，性能指标明确，测试用例自动化并保证周期性运转。
- Optimized 阶段
1.开发自测过程：测试过程规范，责任清晰(Peer To Peer)，测试范围和用例经过评审并借助工具进行管理并可监控测试进度和偏差预警；
2.开发自测效果(bug)监控： Severity1/2 级别的 bug 跟踪借助工具可监控，保证及时修复和验证;预测产品质量趋势，如预测偏差，实现及时纠正设计偏差；
3.开发自测软件质量属性
可测试性：单元测试（UT）自动化并可周期执行进行回归测试，自主完善/调整测试用例，纠正设计偏差和侧重点；
可验证性/ 可用性：FVT，GVT，AVT 通过率指标明确， 实现自动化运行，自主完善/调整测试用例，纠正设计偏差和侧重点；
4.SVT/性能测试软件质量属性
可靠性：保证软件的稳定性，性能指标明确，测试用例自动化并保证周期性运转，自主完善/调整测试用例，纠正设计偏差和侧重点。
2.5 Reflection 阶段
图 7.Reflection 阶段各成熟度的要求
- Initial 阶段
1.过程改进：总结过去的实践经验以用于新项目的计划和管理；具有重复以前成功项目的环境和条件。
2.确认客户反馈：建立有效渠道获得客户反馈， 确保可追踪性：需求->story->work items->客户反馈满足需求。
3.软件质量总结及改进：
可扩展性、可维护性、可修改性、可移植性。
- Managed 阶段
1.过程自改进：总结过去的实践经验以用于新项目的计划和管理;具有重复以前成功项目的环境和条件。借助工具并基于过程数据库数据进行分析，建立并完善新项目的计划，风险管理
2.确立客户联系：建立多方位有效渠道与客户紧密联系：一方面可向客户推送产品新功能和使用指导（公众号，微信群……）；一方面接收客户新需求和客户对已实现功能的反馈，确保可追踪性：需求->story->work items->客户反馈满足需求.借助工具管理客户需求，关注可理解性、可用性。
3.软件质量总结及改进：除前级 level 已关注的 abilities，还兼顾互操作性、可管理性。
- Optimized 阶段
1.过程改进：总结过去的实践经验以用于新项目的计划和管理;具有重复以前成功项目的环境和条件。借助工具并基于过程数据库数据进行分析，建立并完善新项目的计划，风险管理， 可预测过程和产品质量趋势，如预测偏差，实现及时纠正
2.确立客户联系：建立多方位有效渠道与客户紧密联系：一方面可向客户推送产品新功能和使用指导;一方面接收客户新需求和客户对已实现功能的反馈，确认可追踪性：需求->story->work items->客户反馈满足需求.借助工具管理客户需求，并可预测客户需求趋势及时纠正设计偏差
3.软件质量总结及改进：除前级 level 已关注的能力，还兼顾可伸缩性、可生存性。
2.6 Process
图 8.Process 阶段各成熟度的要求
- Initial 阶段
1.项目管理工作：过程、岗位和职责明确，标准化、文档化；
2.质量目标：量化；
3.质量考核制度： 明确；
4.评审制度：design/code/test case 评审过程标准化；
5.培训制度：系统，文档化。
- Managed 阶段
1.项目管理工作： 过程、岗位和职责明确，标准化、借助工具进行过程监控；
2. 过程数据库： 借助工具建立过程数据库并对过程数据（plan 以及 work items 内容及进度）管理监控;
3.质量目标：量化并借助工具可监控（Bug 监控跟踪）；
4.质量考核制度： 借助工具进行监控；
5.评审制度：design/code/test case 评审过程标准化，根据质量目标结果反馈完善改进；
6.培训制度： 培训体系完备系统化，具有培训练习/测验环境。
- Optimized 阶段
1.项目管理工作： 过程、岗位和职责明确，标准化、借助工具进行监控，可预测过程趋势，发现并及时纠正偏差；
2.过程数据库： 借助工具建立过程数据库并对过程数据（plan 以及 work items 内容及进度）管理监控;可收集过程有效性的统计数据，并进一步分析，从而得出最佳方法，优化改进过程；
3.质量目标：量化并借助工具可监控， 可预测过程和产品质量趋势，发现并及时纠正偏差；
4.质量考核制度： 借助工具监控，预警，控制；
5.评审制度：design/code/test case 评审过程标准化， 根据质量目标监控数据得到的反馈完善改进；
6.培训制度： 培训体系完备系统化，具有培训练习/测验环境，吸取培训效果反馈并自主完善调整培训内容和环境。
三、基于 Structural 的软件质量评估方法
软件开发的不同阶段有着各自的质量控制重点， Structural 质量成熟度反映了软件开发团队对于这些重点的控制能力 。
图 9.各阶段对 Structural 质量成熟度的要求
3.1 各阶段达到 Initial 成熟度的标准
简单的说，Initial 成熟度应该是获得可接受软件质量的一个基本标准，或者用"想到"来描述这个成熟度阶段。在这个成熟度中，通常没有成型的、系统化的方法或者方法比较零散。质量控制基本依赖于人力。质量控制的执行效果依赖于参与者的经验或者团队头脑风暴。
图 10. Initial 成熟度对各阶段的要求
3.2 各阶段达到 Managed 成熟度的标准
Managed 成熟度可以简单的用"做好"来概括。这个成熟度中会使用工具和流程来提升质量控制的能力。
图 11. Managed 成熟度对各阶段的要求
3.3 各阶段达到 Optimized 成熟度的标准
Optimized 成熟度可以用"不断做的更好"来概括，这个成熟度引入更多智能化和认知计算的能力，来帮助充分利用已有经验实现质量控制的最优效果。
图 12.Optimized 成熟度对各阶段的要求
四、结束语
软件质量一向是被重点关注的课题，而在更为灵活和快捷的 Agile 的开发模式下，如何把控软件质量就显得更为重要。本文结合软件能力以及成熟度模型对软件质量预测与评估方法进行了探索，建立了一套软件质量的预测和评估体系，并提供了评估标准的示例。对照质量评估体系中的标准与软件开发过程中的实际行为，预测并评估软件质量。对于体系中不同成熟度标准的具体实践，需要软件开发团队结合自身特点，应用最新的技术来进行实施和积累，并不断完善。
参考资源 (resources)
- 查看文章 Agile Maturity Model – 3 Different Approaches，了解更多 AMM 相关信息。
- 参考 Agile software development，获得更多敏捷软件开发内容。
- 参考Measuring Software Product Quality: the ISO 25000 Series and CMMI (SEI site)，获得软件质量评估模型更多内容。
- 参考文章“大型开发组织的敏捷团队中实施 CMMI”，获得实践 CMMI 经验。
- 查看文章“Manifesto for Agile Software Development”，了解更多敏捷开发的内容。
- 参考文章“由外而内看敏捷软件开发”，了解如何从业务角度看敏捷。
- 查看 CMMI 网站，了解更多软件成熟度的内容。
- IBM developerWorks 中国 DevOps 专区：为使用 DevOps 的开发人员准备的技术信息和资料。这里提供产品下载、how-to 信息、支持资源以及免费技术库，包含技术文章、教程、最佳实践、IBM Redbook 和在线产品手册。
- 加入 developerWorks 中文社区，developerWorks 社区是一个面向全球 IT 专业人员，可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区
