产品集成指南Word文档格式.docx
《产品集成指南Word文档格式.docx》由会员分享,可在线阅读,更多相关《产品集成指南Word文档格式.docx(7页珍藏版)》请在冰豆网上搜索。
修改人
变更摘要
备注
V1.0
2014-04-03
A
刘丹
第一次正式发布
1目的
本文件规定了软件集成应遵循的步骤和原则,明确集成中各方职责,确保集成阶段的顺利进行,保证项目的软件集成目标与要求能够实现。
2适用范围
适用于项目实施过程中的软件集成阶段。
3职责
Ø
项目负责人:
负责提出集成目标和要求,并对集成阶段进行跟踪;
集成负责人:
对项目的软件集成负责,负责继承的设计和实施,负责集成测试的实施;
集成小组:
参与集成的设计和实施,并按照集成测试方案及用例进行集成测试。
构建小组:
负责向集成小组提供可供集成的工作产品,并对集成小组提出的缺陷进行修正;
QA:
参与集成过程的监督与跟踪。
4定义与说明
4.1集成
集成就是指在每一个模块都能单独工作的很好的情况下,把模块放在一起以构成完整的目标系统。
集成主要通过以下几个步骤实现:
1)项目组按照预定的集成策略进行集成的设计,形成《软件集成计划》;
2)集成构造,也称为build;
3)集成测试;
4)集成是一个反复循环的过程,项目组按照集成计划回到第2)步继续循环进行,直至集成完成。
当一个新的模块被当作集成进来时,软件发生改变,新的数据流路径建立,新的I/O操作出现,可能激活新的控制逻辑,这些改变可能使原本工作正常的功能产生错误。
因此集成主要关注以下几个方面:
模块之间的接口(数据可能在集成时通过接口丢失);
模块之间的相互关系(一个模块在集成后可能对另一个模块产生无法预料的副作用;
当子函数被联在一起时,可能不能达到期望中的功能);
全局数据结构(集成后全局数据结构可能存在问题);
错误或缺陷的被放大(在单个模块中可以接受的不精确性在集成后可能会扩大到无法接受的程度);
集成的策略;
关键模块的集成测试;
等等;
4.2集成构造
集成构造即build,是指按照预先设计的集成策略和顺序对模块进行组合,形成具有一定功能的子系统,该子系统可提交进行集成测试。
4.3集成测试
详见《集成测试指南》
4.4集成策略
集成分为增量集成和非增量集成两种策略。
非增量集成是一种理想化的集成策略,增量集成又分为自顶向下和自底向上的集成。
一般在程序结构的高层使用自顶向下的集成策略,在下面的较低层使用自底向上的集成策略。
4.4.1非增量集成
非增量集成是一种较为理想化的集成策略,即采用一步到位的方法来构造程序。
所有模块都预先结合在一起,整个程序作为一个整体来进行测试,这种集成策略往往会导致程序的结构混乱不堪,程序中存在较多的缺陷,要在整个程序中分离处缺陷的位置非常困难,因此对缺陷的修正也非常困难,一旦这些缺陷被修正后,容易引起新的缺陷产生。
4.4.2增量集成
增量集成即分布集成,将一个大的系统分为多个子系统,对子系统进行构造和测试,这时缺陷比较容易分离和修正,接口也更容易进行彻底的测试,而且可使用一种系统化的测试方法。
增量集成一般采用以下几种方法:
4.4.2.1自顶向下集成
自顶向下集成,模块的集成顺序是首先集成主控模块或主程序,然后按照控制层次结构向下进行集成,隶属于(或间接隶属于)主控模块的模块按照深度优先或广度有限的方式集成到整个结构中去。
自顶向下集成的整个过程由下列五个步骤完成:
1)首先对主控模块及隶属于主控模块的模块进行集成组合;
2)根据集成的实现方法(深度或广度优先),对下一层的模块分布进行集成组合;
3)在每个模块组合进来的时候都要进行集成测试;
4)在完成了每一次集成测试后,才进行下一步的集成构造;
5)可以用回归测试来保证没有引进新的错误;
整个过程回到第2)步继续循环进行,直至系统结构被构造完成。
优点
自顶向下的集成策略主要侧重于在测试过程的早期验证控制和决策点,尽早发现主控中存在的缺陷。
缺点
在实践中可能会出现逻辑上的问题,最普遍发生的问题如:
高层测试需要首先对较低层次的足够测试完成后才能进行。
在自顶向下的测试开始时,由于底层的模块的分布集成,因此,在程序结构中不会有重要的数据向上传递,测试者只有以下三种选择:
1)把测试推迟到底层模块集成组合之后再进行;
这种方法可能导致在特定测试和特定模块组合之间的对应控制;
2)开发能够实现有限功能的对底层模块的模拟;
这种方法会引起较大的开销,模拟部分会变得越来越复杂;
3)从层次结构的最底层向上来对软件进行集成,即自底向上的集成。
4.4.2.2自底向上集成
自底向上集成是从原子模块(在程序结构最底层的模块)开始进行构造和测试的。
自底向上集成主要由以下几个步骤完成:
1)底层模块组合成为能够实现软件特定子功能的子系统;
2)写一个驱动程序(一个供测试用的控制程序)来协调测试用例的输入输出;
3)对子系统进行集成测试;
4)移走驱动程序,沿着程序结构的层次向上对子系统进行组合集成。
4.5关键模块
在集成过程中,关键模块应尽早进行测试,回归测试也应集中在关键模块的功能上,关键模块主要符合下列要求:
1)与多个软件需求相关;
2)含有高层控制;
3)本身复杂或容易出错;
4)含有确定性的性能需求;
4.6集成过程
集成阶段可包含多次集成过程,每次集成过程都是针对指定的构建阶段提交的工作产品进行的,每次集成过程的结束以集成测试结束为前提,对在集成测试中发现的问题和缺陷根据《问题和缺陷处理指导》进行记录并反馈至相关人员处。
根据《软件集成计划》,在上次集成过程结束后,当需要组合进新的子系统,增加新的功能时,需要进行再一次的集成,启动下次集成过程。
5流程描述
5.1集成阶段的进入和完成条件
集成阶段进入的条件:
构建阶段提交可供集成的工作产品。
集成阶段完成的标志:
软件系统结构被构造完成;
提交可供系统测试的完整的工作产品。
集成目标被实现,即《软件集成计划》被执行;
5.2编制《软件集成计划》
在项目的计划阶段,项目负责人和集成负责人以及集成小组应对项目的软件集成编制《软件集成计划》,参见《软件集成计划》模版,软件集成计划应含以下主要内容:
集成的目标和范围
集成的角色安排及职责
集成策略
按照集成策略实施时,计划的代码单元的开发顺序(考虑关键性、难度、集成和测试的问题),以及相对应的build(构造)顺序,以及每个build中所含的子系统;
每个build的结构组成和验收标准;
每个build的集成测试描述,包含为执行并测试build的安装和启动顺序,包含集成测试的方案、用例及预期的测试结果;
《软件集成计划》在需求阶段结束后形成初稿,在概要设计阶段结束后经过评审,形成基线。
5.3构造(build)
按照《软件集成计划》实施软件子系统的构造。
每次build完成后,buildno号加1。
5.4集成测试
集成小组依据指定的需求文档和设计文档的指定版本,制定《集成测试方案》及集成测试用例,负责需求、设计、系统测试及验收测试的人员,应对集成测试方案及用例进行评审,集成小组按照通过评审后的集成测试方案及用例进行集成测试。
参见《测试指导》中有关集成测试部分内容。
5.5计划跟踪与集成总结
对《软件集成计划》的执行情况进行跟踪,在集成阶段结束时对集成阶段进行总结。