现代（叠代）软件管理的十大原理

1. 首先注重结构过程。这要求在组织承诺全面开发的充足资源之前，平衡操作需求、对结构而言很重要的设计决策、以及生命周期计划。

2. 用叠代生命周期在早期防御风险。需要一个叠代过程来更好地理解问题，形成有效的方案和有效的计划，以保证平衡对待所有利益相关者目标。应在早期提出主要的风险以提高可预测性，避免为随后的问题和返工付出大的代价。

3. 强调基于构件的开发。为了减少人工合成源代码和习惯开发的数量，项目组必须在现存的结构框架内从代码行思想转移到基于构件的思想。构件是已经存在的代码行的附着部分，有已定义的接口和行为，存在于源代码中或可执行格式中。

4. 建立变更管理环境。叠代开发的动力学包括并发的工作流，因为不同的工作组都为共享产品工作。这需要客观控制的基线供所有项目成员参阅。

5. 用循环工程工具使变更更自由。循环工程提供了各种不同格式（如：需求说明书、设计模型、源代码和可执行代码）的自动工程和同步工程信息所必需的环境支持。如果不使用实质的自动操作，把叠代周期简化为可管理的，允许并鼓励变更的时间框架是很困难的。叠代过程中产品变更自由是必需的，因为它清除了工程组摩擦的一个主要来源。

6. 使用严格的、基于模型的设计符号。基于模型的方法（例如：UML）支持语意丰富的图形和文本的设计符号。相对于传统的人工评审和纸张文档的特定设计表现的检查，带严格符号和正式的、机器处理语言的可视模型允许更客观的评估。

7. 提供过程的客观质量控制的手段。过程和所有中间产品的生命周期评估必须紧密集成到产品中去，把从展开的工程产品中直接获得的、定义好的度量集成到所有活动和小组中去。

8. 使用中间产品的基于演示的评估。把目前的产品状态的产品（不论是早期原型，基线结构，还是β能力）转换成相关的使用案例的可执行演示，以促进集成转换更早发生，对设计权衡的更切实的理解，以及更早消除产品缺陷。

9. 发布细化的、展开的计划。在系统的操作语境中，软件管理过程的早期的持续的演示是至关重要的，也就是它的使用案例。每个项目的增加和演示都应该反应目前需求和结构的详细水平。使用案例是组织需求、定义叠代内容、评估实施和组织接收测试的重要机制。

10. 建立一个可升级的、可配置的过程。没有哪个过程是适合所有软件开发项目的。现实的说，一个过程框架必须是可配置的，适合大范围的应用软件。为保证经济级别和投资回报，组织必须灌输一个通用过程"精神"，这样所有项目都能集成一系列通用的最好实践，尤其是项目管理、独立于语境的工作流、检查点、度量和产品的最好实践。还应允许各个项目进行剪裁和指定，以便针对项目特定的语境优化过程实施。

CMM和两套管理原则的关系 表1识别出每套原则中各有哪些是直接由 CMM的KPA激发的。这些都是我的判断，结合了Rational公司许多同事的观点，但并没有科学依据。另外，请记住这些原则不仅基于CMM，还基于对默认实践的观察和组织级的惯性。

表1：CMM如何激发软件管理原则

如表1所示，CMM的关键过程域直接激发了大多数传统原理，但对现代原理几乎没什么影响。在我看来，有些现代原理实际上是和CMM关键过程域相冲突的。我想这张表格会在过程改进的狂热支持者中引发激烈的争论，但我相信最终软件开发项目一线的多数工程师和项目经理都会赞同我的结论的。CMMI和现代管理原则的联系

现在，让我们看看CMMI。如果我同样地做个粗略的分析，我就会得到表2的结果。

注释：表2的颜色说明同表1。

Table 2: How the CMMI Motivates Iterative Software Management Principles

表2：CMMI如何激发叠代软件管理原则

请注意我的分析依然是基于产业的默认实践的观察，而非CMMI的目的。我们这种和传统方法和组织文化的联系会成为达到CMMI真正目的的障碍，因此我对我的观点持保守态度。显然，我的观点就是：CMMI代表了主要的改进。