软件配置管理规范流程样本.docx

1 概述1.1 目本文档重要目在于规范项目配备管理活动，保证配备项对的地唯一标记并且易于存取，保证基线配备项更改受控，明确基线状态，在整个软件生命周期中建立和维护项目产品完整性和可追溯性。1.2 合用范畴本文档合用于不同类别软件产品和软件项目开发工程配备管理活动，针对项目不同在流程上作恰当删减。配备管理可采用各种工具及手工办法，本文献以CVS（并行版本系统）配备管理工具为例，规定公司配备管理办法，使用其她工具时也可相应本文献规定参照执行。1.3 术语和缩略语1.3.1 软件配备管理（Software Configuration Management，SCM）软件配备管理是对软件修改进行标记、组织和控制技术，用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范一系列办法。配备管理目的是记录软件产品演化过程，保证软件开发者在软件生命周期中各个阶段都能得到精准不同版本产品配备。1.3.2 配备项（Configuration Item，CI）凡是纳入配备管理范畴工作成果统称为配备项，配备项逻辑上构成软件系统各构成某些，普通是可以单独进行设计、实行和测试。每个配备项重要属性有：名称、标签、文献状态、版本、作者、日期等。所有配备项都被保存在配备库里，保证不会混淆、丢失。配备项及其历史记录反映了软件演化过程。1.3.3 基线（Baseline）在配备管理系统中，基线就是一种配备项或一组配备项在其生命周期不同步间点上通过正式评审而进入正式受控一种状态，这些配备项构成了一种相对稳定逻辑实体，而这个过程被称为“基线化”。每一种基线都是其下一步开发出发点和参照点。基线拟定了元素（配备项）一种版本，且只拟定一种版本。普通状况下，基线普通在指定里程碑处创立，并与项目中里程碑保持同步。每个基线都将接受配备管理严格控制，基线中配备项被“冻结”了，不能再被任何人随意修改，对其修改要严格地按照变更控制过程进行。在一种软件开发阶段结束时，上一种基线加上增长和修改基线内容形成下一种基线。基线重要属性有：名称、标签、版本、日期等。1.4 权限与职责1.4.1 研发总经理助理1） 审核变更祈求。1.4.2 项目经理（Project Manager，PM）1) 审核批准配备管理筹划；2) 接受或回绝小范畴变更申请；3) 召集评估变更；4) 提出配备管理建议和规定；5) 配合配备管理员工作。1.4.3 配备管理员（Configuration Management Officer，CMO）1) 编写配备管理筹划；2) 执行版本控制和变更控制方案；3) 制定访问控制方略；4) 负责项目配备管理工作，涉及搭建环境、权限分派、配备库建立、配备项控制等；5) 配备管理工具寻常管理与维护；6) 配备库寻常操作和维护；7) 负责配备审核并提交报告；8) 依照配备布置表单编译发布版本，并维护版本；9) 对开发人员进行有关培训；10) 对配备审核中发现不符合项，拟订纠正办法，规定有关负责人进行纠正。11) 监督项目构成员规范执行状况。1.4.4 开发人员（Developer）1) 依照拟定配备管理筹划和有关规定，提交配备项和基线；2) 负责项目组内部测试；3) 负责软件集成和版本生成；4) 按照软件配备管理工具使用模型来完毕开发任务。2 实行细则2.1 配备项管理2.1.1 配备项范畴软件配备可涉及如下几方面：开发文档，代码，第三方控件、插件，参照资料，测试文档，顾客文档，项目管理文档，验收文档等。l 项目文档重要指：立项建议书、可行性分析报告、技术建议书、顾客需求阐明书、项目筹划、项目进度筹划、项目阶段性筹划、产品需求规格阐明书、概要设计报告、详细设计、数据库设计、界面设计、顾客操作手册、顾客安装手册、培训文档、验收报告以及上述文档评审记录。l 代码重要指：源代码等。l 工具重要指：脚本文献、插件、第三方控件等。2.1.2 配备项基线管理结合SPP和ISO9000有关规定，配备管理员依照配备管理规范及配备管理筹划，对配备项进行分阶段管理，每一阶段正式评审通过后纳入受控库，作为该项目一种基线。l 项目启动：配备项涉及技术建议书、可行性分析报告、顾客需求阐明书等立项阶段产生文档，评审或审批通过后建立发布基线。l 需求阶段：系统调研后开发人员进行需求分析，并整顿产品需求规格阐明书。产品需求规格阐明书通过客户确认后，建立需求基线。如需升级版本则必要通过评审或审批并得到客户确认。l 项目筹划：需求分析完毕后即可制定项目开发筹划，涉及项目筹划和重要下属筹划。涉及项目进度筹划、配备管理筹划、质量保证筹划、测试筹划、项目阶段性筹划。项目开发筹划评审通过后，建立项目筹划基线。l 设计：系统设计可分为概要设计、详细设计、数据库设计、数据库字典、界面设计。针对顾客需求规格阐明书进行系统设计，配备时应阐明系统设计版本与需求分析报告版本相应关系。设计阐明书评审或审批通过后，建立设计基线。l 编码（设计实现）：编码按功能模块分子项目，即每个模块记作一种配备项。代码在提交项目组系统测试时建立Beta版本，系统测试产品正式发布后建立Version版本。l 测试：单元测试和系统测试。单元测试通过提交单元测试报告，项目启动后应提交系统测试筹划，系统测试完毕后应提交系统测试报告。配备时应阐明测试版本与编码版本相应关系。系统测试完毕后建立测试基线。l 版本发布：项目组提交布置表单，CMO依照布置表单进行编译，发布测试服务器上，并对版本进行维护。同步将发布版本上传到文档服务器上备份。l 交付与验收：在交付前配备审核完毕后建立产品基线，产品基线包括程序以及关于文档配备项，涉及交付文档、代码、工具等。l 产品布置：布置时应涉及操作手册、安装维护手册、维护文档以及必要业务和技术培训文档。l 有关资料：有关资料也应作为配备项纳入配备管理，此某些涉及：1) 有关法律、法规；必要遵循或项目组商定技术规范；2) 与客户或项目组内部重要交互信息记录，如会议记录、会谈记录、e-mail和MSN记录等；2.2 版本控制2.2.1 文档版本控制所有文档管理纳入配备管理库，用版本控制工具进行统一管理。文档版本控制重要通过文档名称、文档控制页及版本控制工具标签来实现，重要分为如下几类：2.2.1.1 版本变化型文档命名方式：文档名称+子系统名称（可选）合用文档：项目筹划、配备管理筹划、质量保证筹划、项目进度筹划、顾客需求规格阐明书、产品需求规格阐明书、体系构造设计报告、数据库设计报告、详细设计报告、顾客操作维护手册、测试用例等。示例：项目筹划.doc 详细设计_SP门户.doc标签构造：大版本 + 子系统简称 + 版本号 + 日期 （标签控制阐明版本信息）l 大版本： 可选 ，表达同一项目为不同顾客定制版本。l 子系统简称： 可选，当一种项目有各种子系统时，为区别不同子系统而设立。l 版本号：采用Vs_x_y形式。l 日期：纳入基线管理日期，用8位表达，如1031阐明：a. 文档发布名称采用文档名+ Vs_x_y形式，文档版本号应当和版本控制工具中相应标签上版本号一致。b. 对文档修改需要从配备管理库中取到本地进行。c. 对于文档小修改，如文字错误，格式调节，变更Vs_x_y中y来区别（如：V1_0_1）。d. 文档内容没有大增长和删节，意思表述没有发生重大变化，版本标记通过版本工具中加上x标签来表达（如：V1_1_0），以及在文档内部控制页标注变化来表达。e. 文档有重大增长和删节，意思表述有重大变化，版本标记通过在相应文档加上s标签来表达（如：V2_0_0）。f. 对于纳入基线库文档修改需要提交变更申请，经批准才干进行修改，并且修改内容要经再次评审才干重新纳入基线库，作为后续阶段参照文档。2.2.1.2 时间区别型文档命名方式：文档名称撰写时间合用文档：文档名称有明确含义，需要用时间标记寻常性文档。如周例会会议纪要，项目月筹划，项目月总结,阶段性筹划等等。示 例：周例会会议纪要0901.doc2.2.1.3 时间序号型文档命名方式：文档名称+人员姓名（拼音）+撰写时间+序列号合用文档：测试报告示例：单元测试报告_lixiaohong_1112_01.dco2.2.1.4 其她文档：对于不能按照前四种类型进行命名文档会议纪要：会议纪要YYYYMMDD ( )示 例：9月9日召开项目启动会命名为：会议纪要0909(项目启动).doc评审报告：评审报告YYYYMMDD ( )同”会议纪要”规定一致。示 例：10月9日召开项目总体方案评审命名为：评审报告0910(总体方案).doc2.2.2 发行版本表达发行版本采用标签阐明，构造如下：大版本 + 版本类型 + 版本号 + 子系统简称(拼音)+日期 +序号大版本： 可选 ，表达同一项目为不同顾客定制版本。子系统简称： 可选，当一种项目有各种子系统时，为区别不同子系统而设立。版本类型：分为3种Beta表达项目组内部测试，标签：B1_0_0-1015-01Release系统测试，标签：Release1_0_0-SPmenhu-1112-01Version正式发行版，标签：Version1_0_0-SPmenhu-1112-01版本号 对于Version正式发行版 是必要要注明，而其他可选。发行产品基线在版本号前加Version，如 Version_1, Version_2, Version_3.表达分支；Version_1_0，Version_1_1，Version_1_2 表达在分支Version_1上标签；Version_0_0，Version_0_1，Version_0_2 表达在主线上标签。2.3 配备库管理2.3.1 配备库分类配备库统一由配备管理员负责管理，服务器端使用cvsnt2.0.4，客户端重要使用乌龟CVS。配备库目录构造如下：2.3.2 配备库建立所有项目应建立配备库，以便管理各配备项，配备管理员组织建立配备库。程序库重要通过设立版本分支来实现对配备项权限管理： 1)开发库：开发人员相对比较自由存储空间，开发人员可以在自己权限范畴内任意取出提交。2)基线库：配备管理员有最高权限，别的有关人员均为读权限，发生变更时变更人员须提交变更申请后方可修改基线库内配备项。 文档评审通过后，文档严格受控。由配备管理员将通过评审后文档移植到基线库里同步将该配备项从开发库移除。 代码普通在移送系统测试时纳入基线库受控，可依照项目详细状况设立基线。3)产品库：产品库产品均出自于基线库，产品库存储产品用于交付和存档。配备三库统一由配备管理员管理，依照各开发阶段实际状况定制相应版本选用规则，来保证开发活动正常运作。在变更发生时，应及时做好基线推动。2.3.3 分派权限项目开始后配备管理员编写配备库目录构造表明确项目构成员以及有关人员权限。在wincvs里有三种权限，读（r）、写（w）、添加删除（c）权限。在开发库内，文档某些项目构成员有rcw权限，其她有关人员只r权限；代码某些项目构成员有rcw权限，其她有关人员没有任何权限。在基线库内，项目构成员仅有r权限，其她有关人权限视状况而定。在产品库内，所有人没有任何权限。配备管理员在三库内均拥有最高权限。2.4 配备变更控制2.4.1 变更分类软件及其有关文档变更按照变更影响范畴进行分类：1)A级：变更会影响系统级需求、外部接口、产品价格或者交付期；此类变更必要通过配备管理委员会审核并有客户批准和确认。2)B级：变更会影响配备项间功能接口、内部功能设计、组件；此类变更必要由项目经理或配备管理委员会批准和承认。3) C级：变更只会影响配备项内部或对BUG问题解决；此类变更可以由配备项管理人员负责批准。 系统测试前变更控制流程： 系统测试完毕发布release版本后变更控制流程图2 变更控制流程2.4.2 变更祈求提出a 由技术支撑中心汇集顾客意见，影响到需求变更则填写配备项变更控制报告，并提交给配备管理员。b 配备管理员对申请表与否清晰、明确和完整性进行审查，若发现变更不明确或不完整，应返回申请者。对通过审查变更申请分派变更ID，以便跟踪和记录变更信息。2.4.3 评估变更a 配备管理员将配备项变更控制报告发送给项目经理（或者其她授权人员），由项目经理负责对变更进行评估。b 项目经理对变更进行分解，普通BUG修正不需要审批直接由项目经理决定与否需要变更。新增功能或对整个项目影响重大变更必要由研发总助审批通过后方可变更。变更评估文档在完毕变更评估后发送给配备管理员。2.4.4 变更实行和确认a 变更被批准后，项目经理提交变更实行进度筹划，开发人员开始实行变更，并详细记录变更内容；质量部对变更实行进行跟踪。b 对于代码变更，必要进行回归测试，以保证变更没有引入新Bug。此外与变更有关文档必要修订，以反映变更。当变更以及测试完毕后，进行提交。c 通过测试后，质保人员需对变更进行审核，审核范畴普通涉及如下方面：测试记录；变更祈求；配备项检入及检出；文献命名；版本编号。a 审核后，由配备管理员更新到基线库中。2.5 配备状态报告2.5.1 目记录和报告整个软件生命周期演化状态。2.5.2 记录内容配备状态报告记录内容涉及：1) 软件和文档标记；2) 当前状态；3) 基线演化状态；4) 变更状态；5) 版本交付信息等。2.5.3 生成报告配备管理报告自第一种基线创立时建立，由配备管理系统生成，及时反映当前配备状态。2.6 配备审核2.6.1 类别配备审核分为：1)功能配备审核（Functional Configuration Audit，FCA）：审核软件功能与否与需求一致，并符合基线文档规定，普通要审查测试文档等。2) 物理配备审核（Physical Configuration Audit，PCA）：审核要交付构成项与否存在，与否包括所有必须项目，如对的版本源代码、资源、文档、安装阐明等等。2.6.2 执行时机普通选取如下几种状况由质量保证人员负责实行配备审核：1)软件产品交付或是软件产品正式发行前；2)软件开发阶段工作结束后；3)在产品维护工作中，定期地进行。2.6.3 不符合项解决对配备审核中发现不符合现象，配备管理员进行记录，并交由责任部门限期进行纠正，配备管理员负责纠正办法验证。所有不符合项报告均关闭后，才干发布新版本。2.7 发行管理通过配备审核后，经项目经理批准，由配备管理员负责生产新版本。2.7.1.1 交付管理这里“交付”是指从配备库中提取配备项，交付给客户或项目外人员。交付出去配备项必要有据可查，避免发生混乱。流程如下：1)交付人向质量部申请；2)质量部如果不批准交付，则回绝交付配备项。如果批准交付，配备管理员应给出详细交付清单；3)交付人验收后签字。