6. 使用严格的、基于模型的设计符号。基于模型的方法(例如：UML)支持语意丰富的图形和文本的设计符号。相对于传统的人工评审和纸张文档的特定设计表现的检查，带严格符号和正式的、机器处理语言的可视模型允许更客观的评估。
7. 提供过程的客观质量控制的手段。过程和所有中间产品的生命周期评估必须紧密集成到产品中去，把从展开的工程产品中直接获得的、定义好的度量集成到所有活动和小组中去。
8. 使用中间产品的基于演示的评估。把目前的产品状态的产品(不论是早期原型，基线结构，还是β能力)转换成相关的使用案例的可执行演示，以促进集成转换更早发生，对设计权衡的更切实的理解，以及更早消除产品缺陷。
9. 发布细化的、展开的计划。在系统的操作语境中，软件管理过程的早期的持续的演示是至关重要的，也就是它的使用案例。每个项目的增加和演示都应该反应目前需求和结构的详细水平。使用案例是组织需求、定义叠代内容、评估实施和组织接收测试的重要机制。
10. 建立一个可升级的、可配置的过程。没有哪个过程是适合所有软件开发项目的。现实的说，一个过程框架必须是可配置的，适合大范围的应用软件。为保证经济级别和投资回报，组织必须灌输一个通用过程"精神"，这样所有项目都能集成一系列通用的最好实践，尤其是项目管理、独立于语境的工作流、检查点、度量和产品的最好实践。还应允许各个项目进行剪裁和指定，以便针对项目特定的语境优化过程实施。
CMM和两套管理原则的关系 表1识别出每套原则中各有哪些是直接由 CMM的KPA激发的。这些都是我的判断，结合了Rational公司许多同事的观点，但并没有科学依据。另外，请记住这些原则不仅基于CMM，还基于对默认实践的观察和组织级的惯性。
表1：CMM如何激发软件管理原则
瀑布原则的CMM激发 |
叠代原则的CMM激发 |
| 颜色说明： 绿色：CMM直接激发组织应用这些原则 蓝色：CMM是中性的，即不提供直接激发，也不阻碍组织应用这些原则 红色：CMM阻碍组织应用这些原则 | |
| 1. 设计前冻结需求 2. 详细设计评审前避免编码 3. 使用更高指令的编程语言 4. 集成前完成单位测试 5. 维护所有产品的详细的可跟踪性 6. 文档化并维护设计 7. 由一个度量小组评估质量 8. 全面检查 9. 在项目早期进行全面的精确的计划。 10. 严格控制源代码基线。 |
1. 首先注重结构过程。 2. 用叠代生命周期在早期防御风险。 3. 强调基于构件的开发。 4. 建立变更管理环境。 5. 用循环工程工具使变更更自由。 6. 使用严格的、基于模型的设计符号。 7. 提供过程的客观质量控制的手段。 8. 使用中间产品的基于演示的评估。 9. 发布细化的、展开的计划。 10. 建立一个可升级的、可配置的过程。 |
如表1所示，CMM的关键过程域直接激发了大多数传统原理，但对现代原理几乎没什么影响。在我看来，有些现代原理实际上是和CMM关键过程域相冲突的。我想这张表格会在过程改进的狂热支持者中引发激烈的争论，但我相信最终软件开发项目一线的多数工程师和项目经理都会赞同我的结论的。 CMMI和现代管理原则的联系
现在，让我们看看CMMI。如果我同样地做个粗略的分析，我就会得到表2的结果。
表2：CMMI如何激发叠代软件管理原则
| CMMI和叠代原则的联系 |
| 1. 首先注重结构过程。 2. 用叠代生命周期在早期防御风险。 3. 强调基于构件的开发。 4. 建立变更管理环境。 5. 用循环工程工具使变更更自由。 6. 使用严格的、基于模型的设计符号。 7. 提供过程的客观质量控制的手段。 8. 使用中间产品的基于演示的评估。 9. 发布细化的、展开的计划。 10. 建立一个可升级的、可配置的过程。 |
请注意我的分析依然是基于产业的默认实践的观察，而非CMMI的目的。我们这种和传统方法和组织文化的联系会成为达到CMMI真正目的的障碍，因此我对我的观点持保守态度。显然，我的观点就是：CMMI代表了主要的改进。
文章来源于领测软件测试网 https://www.ltesting.net/
