谈产品集成-重温CMMI的PI过程域

发表于:2012-05-22来源:新浪博客作者:人月神话点击数: 标签:cmmi
什么是产品集成?简单的说就是把组成产品的所有软件组件组装起来,使之运行在目标环境上,产品集成包括软件组件之间的集成、软件与硬件的集成、软件基础数据的录入、调试等。系统越复杂,集成就显得越发重要。微软的每日构建,极限开发中的持续集成,都是对

  什么是产品集成?简单的说就是把组成产品的所有软件组件组装起来,使之运行在目标环境上,产品集成包括软件组件之间的集成、软件与硬件的集成、软件基础数据的录入、调试等。系统越复杂,集成就显得越发重要。微软的每日构建,极限开发中的持续集成,都是对产品集成的基本原则,其基本道理就是随时保证组成最终产品接口一致,能顺畅运行,能随时拿得出可运行的版本。

  要注意,产品集成的内容远远大于集成测试,集成测试只是软件生命周期中的一个阶段,而产品集成思想从规划,设计,实施,评估,贯穿整个软件生命周期。只能讲集成测试是产品集成中的一个关键步骤或环节。存在产品集成的原因是由于我们进行了组件化或模块化开发,一个软件产品由原来的全集中可能变化为了能力分散化提供,导致产品集成越来越重要。

  SG1 Preparation for product integration is conducted.准备产品的集成。

  SP1.1 Determine the product-component integration sequence.决定产品组件的集成顺序。

  可以讲这是产品集成的一个核心内容,大型软件系统组件和组件之间是存在相互依赖情况的,不是简单的按顺序集成。一个组件,一反面是消费外部接口,一方面是本身暴露能力和接口,而集成重点就是这些接口间组装。对于SCA组件化架构思路正是体现了组件间的集成重点。

  集成顺序分两个方面来谈,首先对于组件可以分为纯技术层面组件,公共平台层组件和业务组件,其集成顺序为由下向上,即技术组件到平台组件,平台组件到业务组件。这个是纵向的集成顺序。对于业务组件本身又分为多个业务模块,业务模块一般又分为基础数据层面和核心业务层面,这时候集成仍然是数据先行,再集成数据层上面的核心业务模块。对于核心业务模块,由于本身存在相互依赖,在选择集成顺序上是存在一定困难的,至少我们给出的大思路是按核心业务生命周期顺序进行横向集成,比如资产系统按资产新增,资产变更,资产废弃顺序进行集成等。

  SP 1.2 Establish and maintain the environment needed to support the integration of the product components.建立和维护用于支持产品组件集成的环境。这些环境包括硬件环境、网络环境、数据环境等。

  后续谈下产品持续集成。其一是单个版本内的每日构建和持续集成,其二是一个产品分多个版本迭代开发,多个版本间的多次迭代式的集成。如果谈产品集成环境,具体应该包括配置管理环境,自动化编译和构建环境,自动化冒烟测试环境,这三个环境为必备环境。

  按照每日构建和持续集成的思路,首先在开发人员check in代码后,在配置管理环境自动获取和更新到最新的代码版本,然后运行自动化构建脚本进行版本的自动构建。(自动构建中本身也包含了自动构建和编译顺序的问题,需要重点考虑清楚,因为组件间有依赖,前置组件没有编译通过后置组件无法编译成功。),在自动构建完成后需要进行自动部署和发布,部署发布完成后运行自动化测试脚本进行冒烟测试,对于冒烟测试问题通过各种报表方式进行持续发布和通知。

  SP 1.3 Establish and maintain procedures and criteria for integration of the product components.

  建立和维护产品组件集成的过程及标准。

  这个里面有太多内容,按道理我们在讨论产品集成的时候,最先就需要考虑产品集成的流程,产品集成的规范和标准等一系列问题。具体考虑需要前期确定和建立的内容包括,产品集成的流程,进行产品集成的组件接口标准,产品集成的入口准则和出口准则,开发团队,配置团队,集成测试团队各自分工和协同。集成顺序分析方法,集成方案和集成规程,集成测试设计准则和方法,集成测试的过程和方法,集成评估的方法等。

  SG2 The product-component interfaces,both internal and external,are compatible.产品组件的接口,包括内部和外部的,都是兼容。

  SP2.1 Review interface description for coverage and completeness.检查接口描述,保证覆盖性和完整性。通常我们通过评审接口说明的办法来检查接口的完整性、覆盖性。

  按照标准架构设计的思路,只有开始进行组件和模块划分,接口设计的时候,如果所有组件都按照标准的接口规范和契约进行设计和实现,那么组件间是一定可以最终集成起来的。按SOA思路包括了服务契约和服务接口,有明确的服务接口定义和设计,那么所有组件都必须遵从规则进行设计。这里的检查和接口评审则是需要检查各个组件是否遵从了相应的接口标准进行设计和实现。同时要意识到对于组件的接口实现,可以进行合规性测试,可以对组件接口进行单元测试自动化测试,所有目的都是保证接口的规范性和完整性。

  SP2.2 Manage internal and external interface definitions,designs,and changes for products and product components.管理产品和产品组件的内部和外部接口的定义、设计及变更。各组件之间是有关系的,我们需要对这些关系进行管理,保证组件间保持一致。

  每个接口有唯一的提供方,但是却存在多个消费方。组件间的交互和关系通过接口衔接起来。因此应该有一张组件间接口关系表来描述清楚组件间的接口关系。这些接口关系是我们后续确定集成顺序,对组件间进行集成测试的重要参考。

  SG3 Verified product components are assembled and the integrated,verified,and validated product is delivered.验证产品组件被装配和集成,经过验证和确认的产品被交付。

  SP3.1 Confirm,prior to assembly,that each product component requiredto assemble the product has been properly identified,functionsaccording to its description,and that the product-component interfacescomply with the interface descriptions.在装配之前,确认每一个被装配的产品组件已经被清楚定义,各功能符合描述要求、产品组件接口符合接口描述的要求。简单的说就是在集成前,做全面的检查工作,保证各部分符合既定的要求。

  SP3.2 Assemble product components according to the product integration sequence and available procedures.根据产品集成顺序和相关过程集成产品组件。

原文转自:http://www.ltesting.net