之前的文章中，我们谈到过CMMI结构中的四个类别（执行分类、管理分类、实现分类和改进分类）。这一期让我们了解一下CMMI模型中能力域和实践域之间的关系。并围绕CMMI DEV视图展开讲述。

我们如何能确定构建和交付给客户的是满足预期质量的？确保质量能力域中的实践域向我们提供了相关的指导。

需求开发和管理 – 了解客户的期望是非常重要的。想要搞清楚这个问题，我们需要收集需求。有时客户只有一个概念，还没有准备好需求。遇到这种棘手的情况，业务分析人员需要运用专业知识，使用各种启发技术从客户那里挖掘信息，从而引导出需求。

过程质量保障– 为了交付产品或服务，公司所建立的工作过程是需要被遵循的。因为，结果是通过过程得到的。因此，公司需要客观检查工作过程，才能确保最后的结果符合预期。这种检查需要包含对工作过程和已定义的工作过程的标准的执行检查，对过程性能和产出的工作产品的检查。

验证和确认 – 要强制确定交付给客户的产品或服务是满足其需求，而且是符合客户端的使用目的的。为达到这一点，需要检查两个方面。第一，是否进行了正确的构建？第二，是否构建了正确的东西？验证是为了在完成工作的过程中，检查团队是否做了正确的事情。这样的检查会覆盖开发生命周期的每一个阶段，以测试、分析、检查、演示或模拟的形式存在。确认是为了保障正确的解决方案得到构建。通常来说，最终用户和干系人会参与道确认活动中来。

同行评审 – 是验证活动的一个部分。在CMMI v1.3模型中，就是将同行评审纳入到验证活动中的。现在的CMMI v2.0将之独立出来成为一个实践域，足以见得同行评审的重要性。执行同行评审的是参与该工作活动的同行或主题专家。他们通过审查、结构性走查、审计等技术来井然有序地客观检查工作产品。这样的检查有助于在早期阶段发现和消除问题。

公司如何证明其设计能力，及其将设计开发为符合客户需求的产品或服务的能力？以下实践域，将在产品工程设计和开发能力域范畴给出指导。

技术解决方案 – 为了向客户交付产品或服务，公司需要在架构和设计方面发力以满足客户需求。需求是设计和构建解决方案的一项输入活动。这些活动执行于设计产品或产品组件，服务、服务系统或服务组件的各个层面。设计必须满足客户需求、功能性需求和质量方面的需求。公司在评价完多种适合的备选方案后，将之转变为现实，并把通过评估的设计生产为产品、服务或组件。

产品集成 – 一旦产品或解决方案的设计完成后，执行活动便会开始了。各式各样的组件在设计框架中被开发出来，并集成为最终的解决方案。如同很多生产型企业一样，制造并装配组件，最终形成产品。所有这些集成都要满足客户对于功能性和质量属性的要求。公司为了做好集成，则需要依据复杂性定义集成策略——一次性集成，或持续构建并验证和确认每次构建和装配的组件。