解读CMMI—产品集成（一）

为产品集成正名：

在介绍产品集成之前，我不得不说，在前几年我对产品集成理解和管理方面有了几个误区。

首先，原来我将集成与产品整体编译混为一谈，而实际上它不只是次编译，它还可能包括：编译、评审、测试、部署等工作，一次集成是将模块（整体）代码编译并进行验证产品模块（整体）可以运行的过程。当然这个定义也远远超出了下面我要讲解的CMMI的产品集成范畴。

其次，我原来一直认为产品集成只有和测试一同进行才有效果，尤其是持续集成和自动化测试更是如此，只做持续集成没有任何意义。后来事实证明我的想法是错误的，当然我也受到了一些“惩罚”。有些同事在修改BUG时，改动了代码结构，但是因为变更他认为微小，所以没有走变更流程。在产品发布测试的最后期限编译时才发现这个问题，造成了测试、对外发布的延误。如果我们当时小阶段或每日进行编译也许会尽早的发现和解决这个问题。

产品编译我认为有如下作用：

+验证所提交的代码是否可以协调工作。

+方便找到编译错误的位置

+在编译过程中可以统计代码量等。

+有效验证部分代码进行的变更是否有效

+明确代码开发进度

+自动编译成功后可以自动触发自动化测试，减少人工出错率和人工成本。

产品集成的目的是将产品组件组合成为产品，确保已集成的产品可以正常运行和交付。

产品集成的关键是产品和产品组件内部接口的定（这些定义应在上一个过程域：产品集成方案中制定并确认）从而确保接口间的兼容。

对于某一产品的集成不一定只执行一次，也可以分阶段、迭代进行。每次只集成部分组件，逐步增量集成。如果一个产品只在最后才做集成，那就和只在发布前做测试一样，可能发现问题时已经晚了，我们没有时间来修正问题，发布只能延迟。我建议即使我们使用传统瀑布开发模式时也能分多个阶段进行集成从而及早地发现问题、解决问题（即使有不用编译的产品也是如此，因为集成并不只是编译）。每一次持续的集成都包括：编译、测试、评估、改进的过程。

SG1准备产品集成

完成产品集成的准备工作。

准备产品、组件集成，包含建立并维护集成的活动和活动顺序、搭建集成环境、执行集成程序。

准备产品集成这个特定目标包含三个特定实践：

SP1.1确定集成顺序

SP1.2确定用来完成的产品

SP1.3开发产品与产品组件集成的程序标准。

SP1.1确定集成顺序

确定产品组件的集成顺序

需要集成的产品组件包括：交付产品的一部分、测试设备、测试程序、以及其他配件等的一个综合体。

产品的集成顺序与确定技术解决方案是一致的，对于复杂的产品而言，集成应该是渐进式的，并且运用“集成－一评价－一集成”的迭代过程。集成支持产品组件渐进式组装和评价，为进一步纳入其他可用产品组件奠定良好的基础，或者是为高风险产品组件的原型设计奠定良好的基础。

具体执行步骤：

1、确定待集成产品组件。

这个需要注意的是，产品组件还要考虑数据库部分的集成。由于数据库设计与其他功能组件的设计不同，所以往往有专门的数据库人员来设计和维护，所以在产品集成时数据库的集成多数将成为忽略点或是难点。数据库的构架建设最好能自动化执行，因为有时数据库持续集成时可能删除原来数据库，重新自动创建数据库也许是最快捷的方法。

2、利用产品组件接口间的定义，对待集成组件进行验证和确定。

3、确定组件集成的顺序（可以为多种集成顺序方案）。还应包含明确在这些集成的顺序中的一些测试设备、测试软件、支撑产品等

4、确定最佳集成顺序。

5、定期检查集成顺序，必要时进行修改。因为在随着变更，集成顺序也会变更。另外，在集成时还要评估集成、测试环境和实际运行环境的差距，不断调整集成环境，有时集成顺序会变更。

6、记录制订产品集成方案（包括一些被否决的原因）

产品集成方案可以包含的（但不局限）内容有：

+ 待集成的组件

+ 产品集成顺序

+ 要做的活动

+ 每项活动的责任和所要求的资源

+ 应予满足的进度

+ 应予遵循的规程

+ 所需要的工具

等

注：这里所说的待集成的组件可能还包括数据库，数据库集成有时也是产品集成的一部分重要内容。

未完待续

更多分享

敬请关注

IT平行世界