配置管理流程-安.doc

山大三元计算机工程有限公司软件系统集成配置管理流程目录1目的32适用范围33术语和缩略语34.相关责任人64.1 项目经理（PM，Project Manager）。64.2 配置管理员（CMO，Configuration Management Officer）。64.3 软件质量保证员（Software Quality Assurance，SQA）64.4 开发人员（Dev，Developer）。65实施流程细则65.1 成立配置管理小组（CCB）明确职责65.2确定配置策略75.2.1配置策略确定的时机75.2.2配置项的范围75.3制定配置管理计划75.3.1配置管理计划的编制75.3.2配置管理计划的内容：75.3.3配置管理计划由CCB负责审批。75.4配置项标识规则75.4.1配置项标识要求75.4.2配置项标识方式85.5配置库的建立和管理95.5.1配置库（Repository）的分类：95.5.2各类库的建立和管理权限95.5.3 状态标识、版本号控制与配置库管理105.5.4分配权限105.5.5配置库的操作与管理105.6配置项和基线管理115.6.1项目启动115.6.2需求分析115.6.3 项目计划115.6.4系统设计115.6.5编码115.6.6测试115.6.7交付与验收115.6.8项目总结115.6.9相关资料与培训115.7配置变更控制125.7.1变更的分类125.7.2变更的流程12第一步：变更提出12第二步变更评估12第三步 变更审核12第四步变更实施13第五步变更确认13第六步 变更标识135.8配置状态报告135.9配置审核145.9.1配置审核的类别145.9.2SQA配置审核执行的时机145.9.3不符合项的处理145.10发行管理145.10.1版本标识145.10.2交付管理14软件系统集成配置管理流程1目的规范配置管理活动，确保配置项正确地唯一标识并易于存取，保证基准配置项的更改受控，明确基线状态，在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。2适用范围对于不同类别的软件项目，配置管理的流程不同，可在本流程的基础上进行裁减。3术语和缩略语31项目委托单位 project entrust organization项目委托单位是指为产品开发提供资金并通常也是（但有时也未必）确定产品需求的单位或个人。32 项目承办单位 project undertaking organization项目承办单位是指为项目委托单位开发、购置或选用软件产品的单位或个人。33 软件开发单位 software development organization软件开发单位是指直接或间接受项目委托单位委托而直接负责开发软件的单位或个人。34 用户 user用户是指实际使用软件来完成某项计算、控制或数据处理等任务的单位或个人。35 软件 software软件是指计算机程序及其有关的数据和文档，也包括固化了的程序。36集成系统集成系统是指产品由软件产品和硬件产品集合成一个整体产品。硬件产品可以是纯设备也可以是具有控制功能的智能设备。37 软件生存周期 software life cycle 软件（集成系统）生存周期是指从软件系统（集成系统）设计对软件系统（集成系统）提出应用需求开始，经过设计开发，产生出一个满足需求的计算机软件系统（集成系统），然后投入运行，直至该软件系统（集成系统）退役为止。其间经历系统分析与软件集成系统定义、软件集成系统开发以及系统的运行与维护等三个阶段。其中软件集成系统开发阶段一般又分成软硬件需求分析、概要设计、详细设计、编码与单元测试、组装与系统测试以及安装与验收等六个阶段。38开发库（development library）开发库是指在软件（集成系统）生存周期的每一个阶段期间，存放开发过程中需要保留的各种信息。存放与该阶段有关的信息的库。39受控库 （sontrolled library）也叫基线库 受控库是指在软件（集成系统）生存周期的某一个阶段结束时，存放经过评审或测试的阶段产品信息的库，该信息是下一阶段工作的出发点和依据（基线），是受控制的版本库，也叫基线库，310产品库（product library） 产品库是指在软件（集成系统）生存周期的组装与系统测试阶段结束后，存放最终产品而后交付给用户运行或在现场安装的软件、系统的库。311 接口控制（ interface control） 接口控制是指描述有关由一个或多个部门提供的两个或两个以上的配置项接口的所有功能特性和物理特性的过程。在实现之前，要确保对这些功能特性和物理特性所建议的修改已经过评审和批准。312 功能基线（ functional baseline）功能基线是指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标识。313 指派基线( allocated baseline) 指派基线是指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标识。314 产品基线(product baseline) 产品基线是指在软件组装与系统测试阶段结束时，经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标识。316 释放（release） 释放是指在软件生存周期的各个阶段结束时，由该阶段向下阶段提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也中做交付(delivery)。3.17软件配置管理（Software Configuration Management，SCM）软件配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。3.18配置（Configuration）配置是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此配置包括了即将受控的所有产品特性，其内容及相关文档、软件版本、变更文档、软件运行的支持数据，以及其他一切保证软件一致性的组成要素。3.19配置项（Configuration Item，CI）凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item, CI），配置项逻辑上组成软件系统的各组成部分，一般是可以单独进行设计、实施和测试的。配置项主要有两大类：1)属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等；2)项目管理和机构支撑过程产生的文档。这些文档虽然不是产品的组成部分，但是值得保存。每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。3.20基线（Baseline）在配置管理系统中，基线就是一个CI或一组CIS在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素（配置项）的一个版本，且只确定一个版本。一般情况下，基线一般在指定的里程碑（Milestone）处创建，并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制，基线中的配置项被“冻结”了，不能再被任何人随意修改，对其的修改将严格按照变更控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。建立基线的好处：1)重现性：及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的早些时候重新生成开发环境的能力。当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。2)可追踪性：建立项目工件之间的前后继承关系。目的是确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。3)版本隔离：基线为开发工件提供了一个定点和快照，新项目可以从基线提供的定点之中建立。作为一个单独分支，新项目将与随后对原始项目（在主要分支上）所进行的变更进行隔离。4.相关责任人4.1 项目经理（PM，Project Manager）。项目经理是整个信息系统开发和维护活动的负责人，他批准配置管理的各项活动并控制它们的进程。其具体工作职责如下：1制定项目的组织结构和配置管理策略；2批准、发布配置管理计划；3决定项目起始基线和软件开发工作里程碑；4.2 配置管理员（CMO，Configuration Management Officer）。根据配置管理计划执行各项管理任务，定期向CCB提交报告，并参加CCB的例会，其具体工作职责如下：1. 软件配置管理工具的日常管理与维护；2. 提交配置管理计划；3. 各配置项的管理与维护；4. 执行版本控制和变更控制方案；5. 完成配置审计并提交报告；6. 对开发人员进行相关的培训；7. 识别开发过程中存在的问题并制定解决方案。4.3 软件质量保证员（Software Quality Assurance，SQA） 1. 对配置过程进行监督审计 2. 对配置问题的处理跟踪检查4.4 开发人员（Dev，Developer）。1. 根据项目组织确定的配置管理计划和相关规定，按照配置管理流程完成开发任务。2. 对产生的基线版本变更提出书面申请。3按照文档、程序、系统、数据库统一命名的规定命名；4每次修改执行“提交”-“检出”操作和填写修改信息。5实施流程细则5.1 成立配置管理小组（CCB）明确职责项目立项后由项目经理负责组织成立CCB，人员组成3-7人（奇数），决策机制为：一般情况下决策执行少数服从多数的原则，特殊情况由项目经理或用户决策。一般由下列人员组成：项目经理PM； 配置管理员CMO； SQA；系统负责人；用户代表。配置控制小组（CCB，Configuration Control Board）职责：负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。其具体工作职责如下1. 批准配置项的标志，以及软件基线的建立；2. 制定访问控制策略；3. 建立、更改基线的设置，审核变更申请；4. 根据配置管理员的报告决定相应的对策。5.2确定配置策略5.2.1配置策略确定的时机CCB成立后，由CCB组织会议根据项目的开发计划确定各个里程碑和开发策略，CMO负责整理确定的项目基线和配置项列表，并在编制配置管理计划时列明，按约定的时机收集配置项和建立初始基线。5.2.2配置项的范围1) 技术文档（Documents）：项目开发计划、需求分析报告、软件设计书、质量保证计划、概要设计书、详细设计书、测试文档、技术报告、用户手册、总结报告等；2) 程序（Program）：阶段产品、计算机程序、源程序、释放产品等；3) 工具（Tools）：自动设计工具、开发工具、测试工具、维护工具等；4) 交互文档（Communications）：与客户或项目组内交互产生文档，如会谈记录、E-mail、会议纪要、MSN记录等。5）管理评审文档：各阶段评审报告、变更记录等。5.3制定配置管理计划5.3.1配置管理计划的编制通常情况下，由CMO在项目设计合同签订后，开始编制配置管理计划；如有特殊需要，根据合同或项目要求，由CMO在项目的某一阶段开始前制定配置管理计划。5.3.2配置管理计划的内容：模板见配置管理计划模板配置管理计划应包括以下方面的内容：1) 该项目对配置管理的要求；2) 实施配置管理的责任人、组织及其职责；3) 需要开展的配置管理活动及其进度安排；4) 采用的方法和工具等。5.3.3配置管理计划由CCB负责审批。5.4配置项标识规则5.4.1配置项标识要求1) 合同有明确标识和追踪要求时，由开发人员按合同要求进行标识，以保证满足合同追踪要求。2) 在开发过程中项目组人员提交的配置项，由项目组人员按照本节相关部分标识规则进行标识。3) 项目组人员将要标识或已标识的配置项提交给CMO纳入配置库统一管理，并填写配置状态报告。5.4.2配置项标识方式5.4.2.1标识项配置项标识属性包括：名称、编号、文件状态、版本、作者、日期等。本文标识规则对名称、编号、文件状态和版本进行了描述和规定。5.4.2.2名称、文件状态a.名称：文件名称的标识按文档模板中统一名称为准,一般为：项目编号+项目拼音缩写+文档编号+文档名称。b.文档作者、日期：在SVN库中自动生成。c.状态：文件状态分为“草稿”、“发布”和“修改”三种。l 评审前提交的工作成果为 “草稿”状态；l 测试、评审后提交的工作成果为“发布”状态；l 发布后要变更修改，通过变更控制程序进行修改时为“修改”状态；l 修改工作成果通过测试、评审后为“发布” 状态 。5.4.2.3版本号版本号：V（Version）：即版本，通常用数字表示版本号l 文档版本号：V X.Yl 程序、系统、子系统、模块版本号:V X.Y.Z. 编译版本号主版本号(1-9). 子版本号(0-99) 修正版本号(0-99).编译版本号 示例: 1.21. 22.2345.4.2.4.版本号管理策略 公司软件统一采用Window 下的版本号管理策略l 当项目初版时, 版本号为 1.0； l 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变, 修正版本号加 1, 版本号为 1.0.1;l 当项目在原有的基础上增加了部分功能时, 主版本号不变, 子版本号加 1, 修正版本号复位为 0, 因而可以被忽略掉, 版本号为 1.1.0; l 当项目在进行了重大修改或局部修正累积较多, 而导致项目整体发生全局变化时, 主版本号加 1, 版本号为 2.0 l 另外, 编译版本号一般是编译器在编译过程中自动生成的, 我们只定义其格式, 并不进行人为的控制. e.版本控制：l 版本控制由配置管理员根据版本控制策略编写主、副版本号变更申请，项目经理批准后赋值版本号。l 当开发库中出现“发布”状态工作成果，配置管理员检出，取消文件状态，编制版本号提交到基线库被“冻结”，但是要通知开发人员保存的位置，开发人员可以阅读，按照这个版本基线开展工作，此时任何人都不能随意修改，要修改必须依据配置变更控制的规则执行，并且根据修改的程度重新核定版本）5.4.2.5版本控制标识在版本号后面加入 Alpha, Beta,等后缀名称，便于对各个版本进行控制。Alpha：内部单元测试版，一般不向外部发布,会有很多Bug.一般只有测试人员使用。Beta：集成测试版，正式版推出之前的测试版本，可能有Bug。Final：正式版，修正了Alpha版和Beta版的Bug。SR：修正版或更新版，修正了正式版推出后发现的Bug。OEM：随机版。只能随机器出货，不能零售，只有一面CD和说明书(授权书)。5.4.2.6基线版本标识（目前暂不执行）内部基线，如计划基线、设计基线等，在版本号前加Build，如Build 1.0；发行产品基线在版本号前加Release，如Release 2.0。5.5配置库的建立和管理5.5.1配置库（Repository）的分类：按照项目建库，项目下设三级库l 一级库：开发库、控制库(基线库)、产品库l 二级库：每个一级库分为两类：1) 文档库（Document Library）：存放程序以外的文档资料（包括图片等）；2) 程序库（Program Library）：存放程序、代码、数据。l 三级库：根据开发阶段，三级库构成情况不同。5.5.2各类库的建立和管理权限项目名称（举例）一级库二级库三级库读写权限备注13SZLX开发库文档软件文档硬件文档图形文档当事人读写其余项目组人员只读如果工作需要，经过项目经理批准，配置管理员可以临时改变个别人读写权限。程序个人开发库当事人读写其余项目组人员只读基线库文档评审完的材料管理员及指定人员负责读写，其余项目组人员只读程序测试、评审完的模块、系统、子系统、系统集成材料管理员及指定人员读写，其余项目组人员只读产品库文档构成版本的材料管理员读写程序构成版本的程序、数据库、源码管理员读写5.5.3 状态标识、版本号控制与配置库管理如文档13SZLX系统需求规格说明-草稿（保存在开发库)；13SZLX系统需求规格说明-发布 （保存在开发库）13SZLX系统需求规格说明-V1.0(从开发库建立分支切换保存在基线库）13SZLX系统需求规格说明-修改- V1.1（在开发库修改发布稿，增加版本号，非关键项修改，修改成功y增加1；关键项修改，修改成功X增加1）；13SZLX系统需求规格说明-发布- V1.1（评审、测试通过后修改状态为发布）；13SZLX系统需求规格说明V1.1（从开发库建立分支切换保存在基线库）所有文档评审通过，在基线库里集成，保存到产品库中如程序13SZLX电源控制系统-供电控制模块-草稿（保存在开发库)；13SZLX电源控制系统-供电控制模块-发布（评审通过保存在开发库)13SZLX电源控制系统-供电控制模块- V1.0（从开发库建立分支切换保存在基线库)13SZLX电源控制系统-供电控制模块- 修改-V1.1. 8（在开发库修改发布稿，根据修改的程度胚子组确定X.Y值，Z值开发人员每修改测试一次增加1)13SZLX电源控制系统-供电控制模块-发布-V1.1.8. 9（评审通过保存在开发库)13SZLX电源控制系统-供电控制模块-V1.1.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.5.5.3配置库的检出、检入当发生变更且变更评审通过后，或者发现Bug且Bug评审通过后，由配置管理员将开发库中CIs-发布稿检出，编制版本号存入基线库；项目完成后配置管理员统一将程序、文档的统一版本检入成品库。5.5.5.4配置管理员定期清除配置库里的垃圾文件。5.5.5.5配置管理员定期备份配置库。5.6配置项和基线管理CMO根据配置管理计划，对配置项和基线进行分阶段管理。5.6.1项目启动配置项包括需求说明、订单及其评审结果等；项目立项后应封锁该子项目，建立立项基线。5.6.2需求分析系统调研后开发人员进行系统分析，并整理需求分析报告。需求分析报告通过评审并需取得客户的确定。在需求分析报告取得客户的确认后，封锁该子项目，建立需求基线。如需升版则必须通过评审并得到客户的确认。5.6.3 项目计划需求分析完成后即可制定项目的开发计划，包括项目总体进度说明、进度跟踪、计划修改、配置管理计划、质量保证计划、测试计划等。项目开发计划评审通过后，封锁该子项目，建立项目计划基线。5.6.4系统设计系统设计可分为概要设计、详细设计和数据库设计等部分。针对需求分析报告进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。5.6.5编码编码按功能模块分子项目，即每个模块计作一个配置项。代码基线分别在单元测试结束后建立Alpha版，Alpha集成测试后建立Beta版，在正式发布时建立Final：正式版5.6.6测试各测试阶段应提供测试计划、测试用例、测试结果和测试分析报告，项目启动后应提供项目测试计划书，项目验收结束后应提交项目测试总结报告等。配置时应说明测试的版本与编码版本的对应关系。各阶段测试（如单元测试、集成测试）完成后建立测试基线。5.6.7交付与验收在交付前配置审核完成后建立产品基线，产品基线包含程序以及有关文档配置项，包括交付施工文档、工具等。5.6.8项目总结项目总结应经过部门内部评审，包括项目质量报告、测试报告等。5.6.9相关资料与培训相关资料与培训也应作为配置项纳入配置管理，此部分包括：1) 相关法律、法规；2) 必须遵照或项目组约定的技术规范；3) 与客户或项目组内部重要的交互信息记录，如Question Sheet、会议记录、会谈记录、e-mail和MSN记录；4) 必要的业务或技术培训等。5.7配置变更控制5.7.1变更的分类软件及其相关文档的变更按照变更的影响范围进行分类：1) A级：变更会影响系统级需求、外部接口、产品价格或者交付期；这类变更必须经过CCB审核并有客户批准和确认。2) B级：变更会影响配置项间的功能接口、组件级成本或者项目安排Schedule；这类变更必须由CCB批准和认可。3) C级：变更会影响配置项内部功能的设计和分配；这类变更可以子系统负责人批准。5.7.2变更的流程第一步：变更提出由发起者（客户、最终用户或开发部门）提出变更，填写变更请求/评审单，描述变更原因和变更内容，并提交给CMO。CMO对填写的申请表是否清晰、明确和完整性进行审查，若CMO发现变更不明确或不完整，应返回申请表给发起者。CMO对通过审查的变更申请分配变更ID，以便跟踪和记录变更信息。第二步变更评估CMO将变更请求/评审单发送给项目经理（或者其他授权人员），由其对变更进行评估。a) 变更控制的一个重要环节就是变更评估，变更评估要分析每个变更对系统功能、接口、成本、进度以及约定需求的影响，同时还要分析对软件安全性、可靠性、可维护性、可移植性和性能的影响。b) 变更评估产生的文档应描述若实施变更必须变更的配置项、文档和资源；变更评估文档在完成变更评估后发送给CMO。c) CMO收到评估后的变更请求/评审单后，更新变更记录，并安排CCB会议日程。第三步 变更审核a) CCB对提交的变更申请进行审核，并根据变更评估确定变更的影响级别（A级、B级、C级）；CCB审核可能的结果有三种：接受变更；拒绝变更；延期变更。CCB也可能需更多的变更分析的信息。b) CCB批准的变更，由CMO将变更项目发送到指定的开发人员（Assigner）进行下一步的实施变更工作；对于拒绝的变更，由CMO将CCB拒绝变更的原因发送给发起者，并保存变更请求/评审单，更新变更记录，关闭变更活动；需要进一步分析的，由CMO将变更项目随同CCB的Question Sheet发送给评估分析人员；对于延期的变更，由CMO对变更的相关文档进行归档，以便在适当时机提交CCB审核。c) CMO负责整理CCB会议记录，填写变更请求/评审单中相应审核项；更新变更记录，如果是接受变更，还需将要变更的CIs状态改为“修改中”；将变更文档分发给相关人员。第四步变更实施a) 变更被批准后，CMO配置管理员负责将要变更的CIs以及相关文档迁移至变更负责人的分支上，由变更负责人开始实施变更，并详细记录变更的内容；项目管理部门要对变更的实施进行跟踪。b) 对于代码变更，必须修改设计、代码、测试以及变更正确性的验证。而且与变更相关的文档必须修订，以反映变更。当变更以及测试完成后，进行合并（Merge）。c) 对于开发计划、配置管理计划发生变更的，项目组人员要按照变更过的开发计划、配置管理计划提交配置项。第五步变更确认a) 变更后的程序Merge后必需经过测试组进行回归测试，以确保变更没有引入新的Bug。不会引起程序变更的文档（如计划文档）的变更不需经过测试。b) 通过Merge后测试后，S