配置管理流程-安

1、山大三元计算机工程有限公司软件系统集成配置管理流程目录1目的 32适用范围 33术语和缩略语 34. 相关责任人 54.1 项目经理( PM， Project Manager )。 54.2 配置管理员( CMO，Configuration Management Officer )。 54.3 软件质量保证员( Software Quality Assurance， SQA) 64.4开发人员( Dev， Developer)。 65 实施流程细则 65.1 成立配置管理小组(CCB明确职责 65.2 确定配置策略 65.2.1 配置策略确定的时机 65.2.2 配置项的范围 65.3 制定配

2、置管理计划 75.3.1 配置管理计划的编制 75.3.2 配置管理计划的内容： 7533配置管理计划由CCB负责审批。75.4 配置项标识规则 75.4.1 配置项标识要求 75.4.2 配置项标识方式 75.5 配置库的建立和管理 95.5.1 配置库( Repository )的分类： 95.5.2 各类库的建立和管理权限 95.5.3 状态标识、版本号控制与配置库管理 95.5.4 分配权限 105.5.5 配置库的操作与管理 105.6 配置项和基线管理 105.6.1 项目启动 105.6.2 需求分析 105.6.3 项目计划 115.6.4 系统设计 115.6.5 编码 11

3、5.6.6 测试 115.6.7 交付与验收 115.6.8 项目总结 115.6.9 相关资料与培训 115.7 配置变更控制 115.7.1 变更的分类 115.7.2 变更的流程 12第一步：变更提出 12第二步 变更评估 12第三步 变更审核 12第四步 变更实施 12第五步 变更确认 13第六步 变更标识 135.8配置状态报告 135.9配置审核 135.9.1 配置审核的类别 135.9.2 SQA配置审核执行的时机 145.9.3 不符合项的处理 145.10 发行管理 145.10.1 版本标识 145.10.2 交付管理 1414软件系统集成配置管理流程1目的规范配置管理活

4、动，确保配置项正确地唯一标识并易于存取，保证基准配置项的更改受控，明确基线状态，在贯穿整个软件生命周期中建立和维护项目产品的完 整性和可追溯性。2适用范围对于不同类别的软件项目，配置管理的流程不同，可在本流程的基础上进行裁减。3术语和缩略语3. 1 项目委托单位 project entrust organization项目委托单位是指为产品开发提供资金并通常也是（但有时也未必）确定产品需求的单位或个人。3. 2 项目承办单位 project undertaking organization项目承办单位是指为项目委托单位开发、购置或选用软件产品的单位或个人。3. 3 软件开发单位 softwar

5、e development organization软件开发单位是指直接或间接受项目委托单位委托而直接负责开发软件的单位 或个人。3. 4 用户 user用户是指实际使用软件来完成某项计算、控制或数据处理等任务的单位或个人。3. 5 软件 software软件是指计算机程序及其有关的数据和文档，也包括固化了的程序。3. 6集成系统集成系统是指产品由软件产品和硬件产品集合成一个整体产品。硬件产品可以是纯设备也可以是具有控制功能的智能设备。3. 7 软件生存周期 software life cycle软件（集成系统）生存周期是指从软件系统（集成系统）设计对软件系统（集 成系统）提出应用需求开始，经

6、过设计开发，产生出一个满足需求的计算机软件 系统（集成系统），然后投入运行，直至该软件系统（集成系统）退役为止。其 间经历系统分析与软件集成系统定义、软件集成系统开发以及系统的运行与维护 等三个阶段。其中软件集成系统开发阶段一般又分成软硬件需求分析、概要设计、 详细设计、编码与单元测试、组装与系统测试以及安装与验收等六个阶段。3. 8开发库（development library ）开发库是指在软件（集成系统）生存周期的每一个阶段期间，存放开发过程中需 要保留的各种信息。存放与该阶段有关的信息的库。3. 9受控库 （son trolled library）也叫基线库受控库是指在软件（集成系统）

7、生存周期的某一个阶段结束时，存放经过评审或测试的阶段产品信息的库，该信息是下一阶段工作的出发点和依据 （基线），是受控制的版本库，也叫基线库，310 产品库( product library ) 产品库是指在软件(集成系统)生存周期的组装与系统测试阶段结束后，存 放最终产品而后交付给用户运行或在现场安装的软件、系统的库。311 接口控制( interface control)接口控制是指描述有关由一个或多个部门提供的两个或两个以上的配置项 接口的所有功能特性和物理特性的过程。 在实现之前， 要确保对这些功能特性和 物理特性所建议的修改已经过评审和批准。312 功能基线( functional

8、baseline)功能基线是指在系统分析与软件定义阶段结束时， 经过正式评审和批准的系统设 计规格说明书中对待开发系统的规格说明； 或是指经过项目委托单位和项目承办 单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明； 或 是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发 软件系统的规格说明。功能基线是最初批准的功能配置标识。313 指派基线 ( allocated baseline)指派基线是指在软件需求分析阶段结束时， 经过正式评审和批准的软件需求 的规格说明。指派基线是最初批准的指派配置标识。314 产品基线 (product baseline) 产品

9、基线是指在软件组装与系统测试阶段结束时，经过正式评审的批准的 有关所开发的软件产品的全部配置项的规格说明。 产品基线是最初批准的产品配 置标识。316 释放( release )释放是指在软件生存周期的各个阶段结束时， 由该阶段向下阶段提交该阶段 产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交 的过程。后面这个过程也中做交付 (delivery) 。3.17 软件配置管理( Software Configuration Management ， SCM) 软件配置管理是对软件修改进行标识、 组织和控制的技术， 用来协调和控制整个 过程。是通过技术或行政手段对软件产品及其

10、开发过程和生命周期进行控制、 规 范的一系列措施。 配置管理的目标是记录软件产品的演化过程， 确保软件开发者 在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。3.18 配置( Configuration ) 配置是在技术文档中明确说明并最终组成软件产品的功能或物理属性。 因此配置 包括了即将受控的所有产品特性，其内容及相关文档、软件版本、变更文档、软 件运行的支持数据，以及其他一切保证软件一致性的组成要素。3.19 配置项( Configuration Item ， CI) 凡是纳入配置管理范畴的工作成果统称为配置项( Configuration Item, CI )， 配置项逻辑上

11、组成软件系统的各组成部分， 一般是可以单独进行设计、 实施和测 试的。配置项主要有两大类：1) 属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例 等；2) 项目管理和机构支撑过程产生的文档。 这些文档虽然不是产品的组成部分， 但 是值得保存。每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所 有配置项都被保存在配置库里， 确保不会混淆、 丢失。配置项及其历史记录反映 了软件的演化过程。3.20 基线( Baseline ) 在配置管理系统中，基线就是一个 CI 或一组 CIS 在其生命周期的不同时间点上 通过正式评审而进入正式受控的一种状态， 这些配置项

12、构成了一个相对稳定的逻 辑实体，而这个过程被称为“基线化” 。每一个基线都是其下一步开发的出发点 和参考点。基线确定了元素(配置项)的一个版本，且只确定一个版本。一般情 况下，基线一般在指定的里程碑( Milestone )处创建，并与项目中的里程碑保 持同步。每个基线都将接受配置管理的严格控制， 基线中的配置项被 “冻结”了， 不能再被任何人随意修改， 对其的修改将严格按照变更控制要求的过程进行， 在 一个软件开发阶段结束时， 上一个基线加上增加和修改的基线内容形成下一个基 线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“ Release”，为内部开发用的基

13、线则称为一个“ Build ”。 建立基线的好处：1) 重现性：及时返回并重新生成软件系统给定发布版的能力， 或者是在项目中的 早些时候重新生成开发环境的能力。 当认为更新不稳定或不可信时， 基线为团队 提供一种取消变更的方法。2) 可追踪性：建立项目工件之间的前后继承关系。 目的是确保设计满足要求、 代 码实施设计以及用正确代码编译可执行文件。3) 版本隔离：基线为开发工件提供了一个定点和快照， 新项目可以从基线提供的 定点之中建立。 作为一个单独分支， 新项目将与随后对原始项目 (在主要分支上) 所进行的变更进行隔离。4. 相关责任人4.1 项目经理( PM， Project Manage

14、r )。 项目经理是整个信息系统开发和维护活动的负责人， 他批准配置管理的各项活动 并控制它们的进程。其具体工作职责如下： 1制定项目的组织结构和配置管理策略； 2批准、发布配置管理计划； 3决定项目起始基线和软件开发工作里程碑；4.2 配置管理员( CMO， Configuration Management Officer)。根据配置管理计划执行各项管理任务，定期向CCB提交报告，并参加CCB勺例会，其具体工作职责如下：1. 软件配置管理工具的日常管理与维护；2. 提交配置管理计划；3. 各配置项的管理与维护；4. 执行版本控制和变更控制方案；5. 完成配置审计并提交报告；6. 对开发人员进

15、行相关的培训；7. 识别开发过程中存在的问题并制定解决方案。4.3 软件质量保证员（ Software Quality Assurance ，SQA）1. 对配置过程进行监督审计2. 对配置问题的处理跟踪检查4.4 开发人员（ Dev，Developer ）。1. 根据项目组织确定的配置管理计划和相关规定，按照配置管理流程完成开发 任务。2. 对产生的基线版本变更提出书面申请。 3按照文档、程序、系统、数据库统一命名的规定命名； 4每次修改执行“提交” - “检出”操作和填写修改信息。5 实施流程细则5.1 成立配置管理小组（CCB明确职责项目立项后由项目经理负责组织成立 CCB人员组成3-7

16、人（奇数），决策 机制为：一般情况下决策执行少数服从多数的原则， 特殊情况由项目经理或用户 决策。一般由下列人员组成：项目经理PM 配置管理员CMO SQA系统负责人；用户代表。配置控制小组（ CCB， Configuration Control Board ）职责： 负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。 其具体工作职责如下1. 批准配置项的标志，以及软件基线的建立；2. 制定访问控制策略；3. 建立、更改基线的设置，审核变更申请；4. 根据配置管理员的报告决定相应的对策。5.2 确定配置策略5.2.1 配置策略确定的时机CCB成立后，由CCBfi织会议根据项

17、目的开发计划确定各个里程碑和开发策略， CMOS责整理确定的项目基线和配置项列表， 并在编制配置管理计划时列明， 按约定的时机收集配置项和建立初始基线。5.2.2 配置项的范围1）技术文档（DocumentS ：项目开发计划、需求分析报告、软件设计书、质量保证计划、概要设计书、详细设计书、测试文档、技术报告、用户手册、总结报 告等；2) 程序(Program)：阶段产品、计算机程序、源程序、释放产品等；3) 工具( Tools )：自动设计工具、开发工具、测试工具、维护工具等；4) 交互文档(Communications):与客户或项目组内交互产生文档，如会谈记录、 E-mail、会议纪要、M

18、SN己录等。5) 管理评审文档：各阶段评审报告、变更记录等。5.3 制定配置管理计划5.3.1 配置管理计划的编制通常情况下，由CMO在项目设计合同签订后，开始编制配置管理计划；如有 特殊需要，根据合同或项目要求，由CMOS项目的某一阶段开始前制定 配置管 理计划。5.3.2 配置管理计划的内容： 模板见配置管理计划模板配置管理计划应包括以下方面的内容：1) 该项目对配置管理的要求；2) 实施配置管理的责任人、组织及其职责；3) 需要开展的配置管理活动及其进度安排；4) 采用的方法和工具等。533配置管理计划由CCB负责审批。5.4 配置项标识规则5.4.1 配置项标识要求1) 合同有明确标识

19、和追踪要求时，由开发人员按合同要求进行标识，以保证满 足合同追踪要求。2) 在开发过程中项目组人员提交的配置项，由项目组人员按照本节相关部分标 识规则进行标识。3) 项目组人员将要标识或已标识的配置项提交给CMO内入配置库统一管理，并填写配置状态报告 。5.4.2 配置项标识方式5.4.2.1 标识项配置项标识属性包括：名称、编号、文件状态、版本、作者、日期等。本文 标识规则对名称、编号、文件状态和版本进行了描述和规定。5.4.2.2 名称、文件状态a. 名称：文件名称的标识按文档模板中统一名称为准 , 一般为：项目编号 + 项目拼音缩写 +文档编号 +文档名称。b. 文档作者、日期：在SVN

20、库中自动生成。c. 状态：文件状态分为“草稿” 、“发布”和“修改”三种。评审前提交的工作成果为 “草稿”状态；测试、评审后提交的工作成果为“发布”状态；发布后要变更修改，通过变更控制程序进行修改时为“修改”状态；修改工作成果通过测试、评审后为“发布” 状态 。5.4.2.3 版本号版本号： V（Version ）：即版本，通常用数字表示版本号文档版本号： V X.Y程序、系统、子系统、模块版本号 :V X.Y.Z. 编译版本号 主版本号（1-9）. 子版本号（0-99） 修正版本号 （0-99）. 编译版本号 示例: 1.21. 22.2345.4.2.4. 版本号管理策略公司软件统一采用

21、Window 下的版本号管理策略当项目初版时 , 版本号为 1.0 ；当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变 ,修正版本号加 1, 版本号为 1.0.1;当项目在原有的基础上增加了部分功能时 , 主版本号不变 , 子版本号加 1, 修正版本号复位为 0, 因而可以被忽略掉 , 版本号为 1.1.0;当项目在进行了重大修改或局部修正累积较多 , 而导致项目整体发生 全局变化时 , 主版本号加 1, 版本号为 2.0另外 , 编译版本号一般是编译器在编译过程中自动生成的 , 我们只定 义其格式 , 并不进行人为的控制 .e. 版本控制：版本控制由配置管理员根据版本控制策

22、略编写主、副版本号变更申请， 项目经理批准后赋值版本号。当开发库中出现“发布”状态工作成果，配置管理员检出，取消文件状 态，编制版本号提交到基线库被 “冻结”，但是要通知开发人员保存的位置， 开发人员可以阅读，按照这个版本基线开展工作，此时任何人都不能随意 修改，要修改必须依据配置变更控制的规则执行，并且根据修改的程度重 新核定版本）5.4.2.5 版本控制标识在版本号后面加入 Alpha, Beta, 等后缀名称，便于对各个版本进行控制。Alpha :内部单元测试版，一般不向外部发布,会有很多Bug. 般只有测试人员使用。Beta :集成测试版，正式版推出之前的测试版本，可能有Bug。Fin

23、al :正式版，修正了 Alpha 版和 Beta 版的 Bug。SR修正版或更新版，修正了正式版推出后发现的Bug。OEM随机版。只能随机器出货，不能零售，只有一面CD和说明书（授权书）。5.4.2.6 基线版本标识（目前暂不执行）内部基线，如计划基线、设计基线等，在版本号前加 Build ，如 Build 1.0 ； 发行产品基线在版本号前加 Release，如Release 2.05.5配置库的建立和管理5.5.1 配置库（Repository ）的分类： 按照项目建库，项目下设三级库一级库：开发库、控制库（基线库）、产品库 二级库：每个一级库分为两类：1）文档库（DocumentLib

24、rary ）:存放程序以外的文档资料（包括图片等）；2）程序库（Program Library ）:存放程序、代码、数据。三级库：根据开发阶段，三级库构成情况不同。5.5.2 各类库的建立和管理权限项目名 称（举例）一级库二级库三级库读写权限备注13SZLX开发库文档软件文档 硬件文档 图形文档当事人读写其余项目组人员 只读如果工作 需，经 过项目经 理批准， 配置管理 员可以临 时改变个 别人读写 权限。程序个人开发库当事人读写其余项目组人员 只读基线库文档评审完的材 料管理员及指定人员负责读写， 其余项目组人员只读程序测试、评审完 的模块、系 统、子系统、 系统集成材 料管理员及指定人员读

25、写，其余 项目组人员只读产品库文档构成版本的 材料管理员读写程序构成版本的 程序、数据 库、源码管理员读写5.5.3 状态标识、版本号控制与配置库管理如文档13SZLX系统需求规格说明-草稿（保存在开发库）;13SZLX系统需求规格说明-发布（保存在开发库）13SZLX系统需求规格说明-V1.0（从开发库建立分支切换保存在基线库）13SZLX系统需求规格说明-修改-V1.1 （在开发库修改发布稿，增加版本号，非 关键项修改，修改成功y增加1;关键项修改，修改成功 X增加1）；13SZLX系统需求规格说明-发布-V1.1 （评审、测试通过后修改状态为发布）;13SZLX系统需求规格说明V1.1

26、（从开发库建立分支切换保存在基线库） 所有文档评审通过，在基线库里集成，保存到产品库中如程序13SZLX电源控制系统-供电控制模块-草稿（保存在开发库）；13SZLX电源控制系统-供电控制模块-发布（评审通过保存在开发库）13SZLX电源控制系统-供电控制模块-V1.0 （从开发库建立分支切换保存在基线 库）13SZLX电源控制系统-供电控制模块-修改-V1.1. 8 （在开发库修改发布稿，根 据修改的程度胚子组确定X.Y值，Z值开发人员每修改测试一次增加1）13SZLX电源控制系统-供电控制模块-发布-V1.1.8.9 （评审通过保存在开发库）13SZLX电源控制系统-供电控制模块-V1.1

27、.8. 9（从开发库建立分支切换保存在基线库）所有测试通过的模块、子系统、系统在基线库里集成，并测试成功，保存到产品 库。5.5.4 分配权限配置管理员为每个项目成员分配配置库操作权限。一般地，项目成员拥有Add、Checkin/Checkout 、Download 等权限，但是不能拥有“删除”权限。配置管理 员的权限最高。5.5.5 配置库的操作与管理5.5.5.1 开发人员根据获得的授权的资源进行项目的研发工作，操作配置库， 例如 Add、 Checkin/Checkout 、Download 等。5.5.5.2 配置管理员根据配置管理计划创建与维护基线， “冻结”配置项， 控制 变更。5

28、.5.5.3 配置库的检出、检入当发生变更且变更评审通过后，或者发现Bug且Bug评审通过后，由配置管理员 将开发库中 CIs- 发布稿检出，编制版本号存入基线库；项目完成后配置管理员 统一将程序、文档的统一版本检入成品库。5.5.5.4 配置管理员定期清除配置库里的垃圾文件。5.5.5.5 配置管理员定期备份配置库。5.6 配置项和基线管理CMOS据配置管理计划，对配置项和基线进行分阶段管理。5.6.1 项目启动配置项包括需求说明、 订单及其评审结果等； 项目立项后应封锁该子项目， 建立 立项基线。5.6.2 需求分析系统调研后开发人员进行系统分析， 并整理需求分析报告。 需求分析报告通过评

29、 审并需取得客户的确定。 在需求分析报告取得客户的确认后， 封锁该子项目， 建 立需求基线。如需升版则必须通过评审并得到客户的确认。5.6.3 项目计划 需求分析完成后即可制定项目的开发计划，包括项目总体进度说明、进度跟踪、 计划修改、配置管理计划、质量保证计划、测试计划等。项目开发计划评审通过 后，封锁该子项目，建立项目计划基线。5.6.4 系统设计 系统设计可分为概要设计、 详细设计和数据库设计等部分。 针对需求分析报告进 行系统设计， 配置时应说明系统设计的版本与需求分析报告版本的对应关系。 设 计书评审通过后，建立设计基线。5.6.5 编码编码按功能模块分子项目， 即每个模块计作一个配

30、置项。 代码基线分别在单元测 试结束后建立 Alpha 版， Alpha 集成测试后建立 Beta 版，在正式发布时建立 Final ：正式版5.6.6 测试 各测试阶段应提供测试计划、 测试用例、 测试结果和测试分析报告， 项目启动后 应提供项目测试计划书， 项目验收结束后应提交项目测试总结报告等。 配置时应 说明测试的版本与编码版本的对应关系。各阶段测试(如单元测试、集成测试) 完成后建立测试基线。5.6.7 交付与验收 在交付前配置审核完成后建立产品基线，产品基线包含程序以及有关文档配置 项，包括交付施工文档、工具等。5.6.8 项目总结 项目总结应经过部门内部评审，包括项目质量报告、测

31、试报告等。5.6.9 相关资料与培训 相关资料与培训也应作为配置项纳入配置管理，此部分包括：1) 相关法律、法规；2) 必须遵照或项目组约定的技术规范；3) 与客户或项目组内部重要的交互信息记录，如 Question Sheet 、会议记录、 会谈记录、e-mail和MSN己录；4) 必要的业务或技术培训等。5.7 配置变更控制5.7.1 变更的分类 软件及其相关文档的变更按照变更的影响范围进行分类：1) A 级：变更会影响系统级需求、外部接口、产品价格或者交付期；这类变更必须经过CCB审核并有客户批准和确认。2) B 级：变更会影响配置项间的功能接口、组件级成本或者项目安排 Schedule

32、； 这类变更必须由CCE批准和认可。3) C 级：变更会影响配置项内部功能的设计和分配；这类变更可以子系统负责人批准。5.7.2 变更的流程 第一步：变更提出由发起者(客户、最终用户或开发部门) 提出变更，填写变更请求 / 评审单， 描述变更原因和变更内容，并提交给 CMO CMO寸填写的申请表是否清晰、明确 和完整性进行审查，若 CMOS现变更不明确或不完整，应返回申请表给发起者。 CMO寸通过审查的变更申请分配变更ID，以便跟踪和记录变更信息。第二步 变更评估CMOI变更请求/评审单发送给项目经理(或者其他授权人员)，由其对变 更进行评估。a) 变更控制的一个重要环节就是变更评估， 变更评

33、估要分析每个变更寸系 统功能、接口、成本、进度以及约定需求的影响，同时还要分析寸软件安全性、 可靠性、可维护性、可移植性和性能的影响。b) 变更评估产生的文档应描述若实施变更必须变更的配置项、 文档和资 源；变更评估文档在完成变更评估后发送给 CMO。c) CMC收到评估后的变更请求/评审单后，更新变更记录，并安排 CCB会议日程。第三步 变更审核a) CCB 寸提交的变更申请进行审核，并根据变更评估确定变更的影响级 别(A级、B级、C级)；CCB审核可能的结果有三种：接受变更；拒绝变更；延 期变更。CCB也可能需更多的变更分析的信息。b) CCB批准的变更，由CMO将变更项目发送到指定的开发

34、人员(Assigner )进行下一步的实施变更工作； 对于拒绝的变更，由CMC将CCB拒绝 变更的原因发送给发起者，并保存变更请求 /评审单 ，更新变更记录，关闭变 更活动；需要进一步分析的，由 CMC将变更项目随同CCB勺Question Sheet发 送给评估分析人员；对于延期的变更，由CMO寸变更的相关文档进行归档，以便 在适当时机提交CCB审核。c) CMO负责整理CCB会议记录，填写变更请求/评审单中相应审核 项；更新变更记录，如果是接受变更，还需将要变更的 CIs 状态改为“修改中”； 将变更文档分发给相关人员。第四步 变更实施a) 变更被批准后，CMOE置管理员负责将要变更的CIs以及相关文档 迁移至变更负责人的分支上， 由变更负责人开始实施变更， 并详细记录变更的 内容；项目管理部门要对变更的实施进行跟踪。b) 对于代码变更，必须修改设计、代码、测试以及变更正确性的验 证。而且与变更相关的文档必须修订，以反映变更。当变更以及测试完成后， 进行合并( Merge)。c) 对于开发计划、配置管理计划发生变更的，项目组人员要按照变更过的开发计划、配置管理计划提交配置项。第五步 变更确认a) 变更后的程序 Merge 后必需经过测试组进行回归测试，以确保变更没有引入新的Bug。不会引起程序变更的文档(如计划文档)的