软件配置管理标准规范作业流程.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)交付人验收后签字。