配置管理流程

配置管理流程文件属性机密等級普级发行方式公司发行文件编写马海坡文件批准研发管理部版权宣告本文內容涉及公司商业秘密，著作权属汉柏科技有限公司所有，非经准许不得以任何形式复制、传播及使用Allrightsreserved.ByOPZOON

文件名称配置管理流程页数11/17文件编号OPZOONCMPROCESS版本号1.1版本历史版本作者审批者发布日期修改内容1.0马海坡许文新初始版本1.1魏珍马海坡2012-4-261、 增加文件编号2、 调整页眉页脚3、 增加版本历史目录TOC\o"1-5"\h\z\o"CurrentDocument"简介 1\o"CurrentDocument"1.1目的 1\o"CurrentDocument"1.2适用范围 1\o"CurrentDocument"1.3引用文件 1\o"CurrentDocument"1.4术语和缩略语表 1\o"CurrentDocument"过程总体描述 3\o"CurrentDocument"2.1过程概述 3\o"CurrentDocument"2.2过程流程图 4\o"CurrentDocument"过程活动描述 5\o"CurrentDocument"3.1步骤1：创建配置库 5\o"CurrentDocument"3.2步骤2：制定配置管理计划 5\o"CurrentDocument"3.3步骤3：评审通过？ 6\o"CurrentDocument"3.4步骤4：完成工作产品 7\o"CurrentDocument"3.5步骤5：配置库管理 8\o"CurrentDocument"3.6步骤6：配置项控制 9\o"CurrentDocument"3.7步骤7：基线管理 12\o"CurrentDocument"3.8步骤8：报告配置状态 13\o"CurrentDocument"附录 14\o"CurrentDocument"附录A配置管理模板 14\o"CurrentDocument"附录B公司标准目录结构 141简介目的配置管理是一种标识、组织和控制修改的技术，目的是使软件开发过程中的错误降为最小并最有效的提高生产效率。通过对开发过程进行有效的管理和控制，完整、明确的记载开发过程中的历史变更，形成规范化的文档。使日后的维护和升级得到保证，保护代码资源，积累软件财富，提高软件重用率，加快投资回报。适用范围汉柏科技有限公司引用文件无术语和缩略语表SCM:软件配置管理，是一套规范、高效的软件开发基础结构。通过对软件开发过程的各种输出物进行管理，保证开发的完整性、正确性及可追溯性。配置项:配置管理的对象，简单来讲它符合以下任意一个特点:它会被两个或两个以上的项目成员共同使用；它会随着项目的开展而发生变化；对项目重要的工作产品；一些工作产品之间的关系非常紧密，一个变化其他的就会受到影响。基线:项目存储库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准；简单来讲就是将一组配置项拿“线”穿起来作为一个整体进行统一命名。检入：将文档或代码通过配置管理工具从本地提交到服务器的动作。不同的配置管理工具检入的命令不同，如：SVN的检入命令叫：SVNCommit,汉柏研发中心使用SVN作为配置管理工具；Clearcase的命令叫：Checkin。2过程总体描述过程概述配置管理主要包括配置项标识，版本管理，变更管理，报告配置状态和发布管理等活动。本流程将项目的配置管理活动分为三个主要的阶段：配置管理策划，配置库管理和发布管理。配置管理策划主要是在项目初期进行配置管理活动的整体计划，项目的配置管理策略，配置管理活动的执行周期在计划中确定；配置库管理是贯穿于项目的整个过程的，它主要包括了配置标识及版本管理，变更管理，配置状态报告等内容，主要目的是为了保持配置库的正确，完整和可追溯性；

过程流程图配置管理流程输入制控置配配置管理计划一项目过程定义--项目计划配置管理员输入制控置配配置管理计划一项目过程定义--项目计划配置管理员创建配置库配置项控制① 配置项报告配置状态J状态表图2-1配置管理过程流程图3过程活动描述3.1步骤1：创建配置库名称（What）创建配置库责任人（Who）配置管理员时间(When)Charter评审通过后输入（Input）无输出(Output)项目配置库方法(How)1、 项目经理通知配置管理员建立项目的配置库，通知中需包括配置库的名称，需开通权限人员；如需为项目定制单独的配置库结构，需提供目录结构并向研发管理部经理申请。获得批准后方可建立；如此目录结构适用于某类项目，研发管理部经理可考虑将其加入到公司标准目录结构中。2、 配置管理员按照公司标准目录结构建立配置库，并邮件通知项目经理及已开通权限人员。注解(Comments)公司标准目录结构参见附录B步骤2：制定配置管理计划名称（What）制定配置管理计划责任人（Who）配置管理员时间(When)项目启动阶段，确定TR1-TR2的《配置管理计划》项目计划阶段，输出完整的《配置管理计划》输入（Input）项目过程定义项目计划

输出（Output）配置管理计划方法(How)1、 配置管理员根据配置管理计划模板制定配置管理计划，主要内容：配置项标识：基于项目过程定义中定义的输出物丄确定本项目的配置项，原则上需要后续进行维护和修改的工作产品可作为配置项；丄确定管理级别，如对于需求文档需要加大管理力度，而对于报告类的文档则无需花费太多时间。基线计划，确定各基线的建立时间按照工作产品单个入基，逐步完善的原则建立基线。如设计基线包括：概要设计、详细设计等文档。当完成概要设计评审后可先入基线，然后详细设计完成后再入基，最终形成设计基线。汇报机制及计划+配置项状态报告的时间点。分支集成策略Trunk分支及Branch分支如何集成，何时集成的策略。2、 完成配置管理计划的编制后，发送给项目经理进行审批。注解(Comments)步骤3：评审通过？名称（What）评审通过？责任人（Who）项目经理时间(When)TR1-TR2输入（Input）配置管理计划输出（Output）配置管理计划方法(How)1、将本计划同项目各计划一同进行评审。

如评审通过，则进行后续活动；如不通过，则修改直到通过为止。注解(Comments)步骤4：完成工作产品名称（What）完成工作产品责任人（Who）项目组时间(When)TR1-TR6输入（Input）项目计划输出（Output）工作产品方法(How)1、 项目组按完成工作产品具体的时间点参考项目计划中规定的时间点。2、 个人对工作产品的配置管理文档：丄建议开始编写时就检入到文档库的规定位置，每次修改后进行提交，这样可以随时获取之前的版本，防止误操作丢失，也更方便其他人查看；丄最低要求在发出评审前将工作产品的初稿检入到SVN的文档库中进行管理，以保证文档的版本受控；丄文档入基后，后续的工作以基线文档为准。不能再以开发区中的文档作为参考；丄入基后的文档不能随意修改，如需修改一定是由于变更引起的，变更的管理请参考《变更管理流程》代码：丄代码分为开发分支和集成分支；丄开始编码时将代码检入到开发分支；

丄代码经过单兀测试和CodeReview后检入到集成分支；丄向集成分支检入文件需要经过研发组长同意。注解(Comments)项目成员母次检入时，需要在comments中填写说明，说明内谷包括：修改了哪些内容，为什么修改等内容。特别是为了解BUG而修改代码时，需要写明BUG的ID步骤5：配置库管理名称（What）配置库管理责任人（Who）配置管理员时间(When)TR1-TR6输入（Input）配置管理计划输出（Output）无方法(How)1、配置库结构01—项目管理：丄存放项目管理相关的一次性输出的配置项的初稿及过程版本，如：项目通知，立项报告书等；丄存放周期性输出物，如度量数据，变更控制报告。02—硬件：存放硬件的输出物，开发组长可根据需要增加目录；03—软件：右存放软件的文档输出物的过程版本，如SRS、系统设计说明书；丄存放代码，包括开发分支、集成分支以及build好的版本。04—测试：存放测试的过程文档及参考资料等；05—质量保证：存放QA的审计记录，流程提醒等输出；06里程碑：作为项目的基线库，母个里程碑的输出物入基后放到本目录下；

07_会议纪要：存放项目的各种会议纪要;08_项目周报：存放项目组周报，QA周报及项目状态报告。2、权限管理01_07_会议纪要：存放项目的各种会议纪要;08_项目周报：存放项目组周报，QA周报及项目状态报告。2、权限管理01_项目管理02—硬件03_软件04—测试05_质量保证06_里程碑07_会议纪要08项目周报项目经理WRRRRWWW硬件开发RWRRRRWW软件开发RRWRRRWW测试人员RRRWRRWW架构师RWWRRRWWQARRRRWRWWCMWWWWWWWW3、配置库备份公司级配置管理员需要定期将SVN数据库备份到XXX机器上，备份的周期为每月备份一次。注解(Comments)步骤6：配置项控制名称（What）配置项控制责任人（Who）配置管理员时间(When)TR1-TR6输入（Input）配置管理计划输出（Output）无方法(How)1方法(How)源码类配置项：丄开发源码：源码文件，可按照子系统或模块目录为单位标识；丄测试源码：测试程序、测试框架、测试脚本、测试数据等。文档类配置项：丄项目管理文档：项目计划、测试计划、项目周报、项目状态报告等；丄工程开发文档：需求文档、设计文档、测试方案、评审报告、测试报告、参考资料等；丄配置管理文档：配置管理计划、配置状态报告等；丄质量保证文档：质量保证计划、SQA审计周报等；丄会议纪要文档：工作产品评审会议纪要、项目例会会议纪要、项目里程碑评审会议纪要等。2、配置项命名规则文档配置项命名规则：丄项目名称—相应工作产品名称。以下划连线“_”分开各名称域。如：卩06_软件需求规格说明书.doc;丄文档版本号在文档的修订历史中表明，不在文件命名中体现，从而确保在SVN配置库中仅保留有一个最新版本的文件存在；丄文档命名，应以文档模板的命名为基准，如有特殊需求无法按照命名规则进行，需要进行说明。代码命名规则：丄名称由英文单词或字母缩写构成，应能标识出代码的功能特性；丄名称中可以有两个或三个单词组成，但不应多于三个;丄名称中可以包括合法的英文大小写字母、减号、下划线；丄可以使用前缀或后缀来进一步区分，如function_usermanage、page_login等；会议和报告类文档命名规则：丄项目名称—报告名称—日期，日期形式为yyyymmdd;对于会议纪要类的文档，日期为会议召开日期；对于报告类文档，日期为报告提交日期。丄此类文档不必标识其版本，若发现问题修改后只需重新提交，不必更新其标识。3、 配置项的状态：“草稿”（Draft），配置项刚建立时；“正式发布”（Released），配置项通过评审（或审批）后；“正在修改"（Changing），正式发布后的配置项，变更过程中为此状态。当配置项修改完毕并重新通过评审（或审批）时，其状态又变为“正式发布”4、 配置项版本号规则：配置项的版本号与配置项的状态紧密相关：处于“草稿”状态的配置项的版本号格式为：0.Y；丄Y数字范围为1-99;丄随着草稿的不断完善，“Y”的取值应递增。“Y”的初值和增幅由用户自己把握。处于“正式发布"状态的配置项的版本号格式为：X.Y;丄X为主版本号，取值范围为1-9。Y为次版本号，取值范围为1-9；丄配置项第一次“正式发布”时，版本号为1.0；丄如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。只有当配置项版本升级幅度比较大时，才允许

增大X值。发布版本号规则：*构建版本号命名规则：v*.*.*.*（patch）_*,即前二位是项目版本号，第四位是Build号，再接下来*是Alpha号或Beta号，例如:vl.0.0.1010_alpha2,vl.O.O.lOlOpatch1_alpha1,vl.0.0.1010_Betai等。注解(Comments)步骤7：基线管理名称（What）基线管理责任人（Who）配置管理员时间(When)TR1-TR6输入（Input）配置管理计划输出（Output）基线方法(How)1、 定义基线：在配置管理计划中定义出项目过程中的基线。2、 建立基线：文档基线：每个里程碑（TR1-TR6）建立一条基线，基线内容包括本阶段的主要输出物，配置管理员在本阶段的里程碑评审前发出基线状态报告给项目组；代码基线：在项目的编码阶段，配置管理员在每个版本上打一个标佥，建立条基线。3、 基线变更：当项目出现变更时，可能会引起基线的变化，此时依据《变更管理流程》执行，执行完成后，配置管理员要检杳基线的状态，并出具基线状态报告。注解(Comments)

步骤8：报告配置状态名称（What）报告配置状态责任人（Wh