配置管理实施细则

3 实施细则
3.1 成立CCB小组
在项目发启后由项目经理或高层经理组织成立CCB小组。
CCB成员人数在3～8人范围内（具体组成视实际情况而定），一般包括：
1) 项目经理PM；
2) 项目总监
3) 高层经理
4) 组织级CM；
5) QA人员；
6) 测试主管；
7) 顾客代表；
8) 开发主管等。
CCB小组的决策原则：寻求CCB成员的一致意见。若不能达成一致，可采取由顾客代表做出决策；或采取少数服从多数的原则，由CCB成员投票确定，投票超过半数即为通过。
3.2 配置管理人员确定
在项目发启时，由项目总监确定该项目组织级CM，负责项目配置计划的制定和整体项目的配置管理。
3.3 制定配置管理计划
3.3.1 配置管理计划的约束条件
1） 配置管理计划必须以项目开展的工作为基础；
2） 配置管理计划的编写必须以公司的流程为模版，与项目开发计划、质量保证计划以及度量计划相一致；
3） 配置管理计划能够指导未来的配置管理工作，配置管理工作必须以配置管理计划为基准；
4） 配置管理计划必须经过最终的评审通过，才能够发布；
5） 如配置管理计划不能满足未来配置管理工作的需要，可以再增加配置管理工作计划作为配置管理计划的辅助，指导未来的配置管理工作。
3.3.2 编制配置管理计划
1） 制定计划
在项目立项初期，组织级CM要参考项目计划书并与相关人员协商制定配置管理计划，规划未来的配置管理工作，通常情况下，由组织级CM在项目计划书完成后，开始编制《配置管理计划》；如有特殊需要，根据合同或项目要求，由组织级CM在某一项目或项目的某一阶段开始前制定《配置管理计划》。
《配置管理计划》应包括以下方面的内容：
A. 实施配置管理的相关责任人、组织及其职责；
B. 配置管理需要的软硬件环境；
C. 开发工具和方法；
D. 配置项计划和基线计划以及其进度安排，立项初期组织级CM要和项目经理讨论，确定出项目的配置项，并确定基线的组成和发布时间点。
E. 配置库备份计划。
2） 规范配置管理环境
配置管理计划制定结束后，组织级CM要依据计划实施配置管理的前期工作。首先必须规范配置管理的环境，实现项目组内的专机专用，与项目经理协商，开发用机、测试用机、配置用机的情况，并最终生成配置管理环境维护清单，便于后期对环境的维护。
3） 确定配置项的范围
CCB成立后，由CCB组织会议根据项目的开发计划确定各个里程碑和开发策略，组织级CM负责整理确定的项目基线和配置项列表，并在编制《配置管理计划》时列明，按约定的时机收集配置项和建立初始基线。结合公司项目目前的情况，过程中主要的配置项包括：
 项目计划：项目开发计划，wbs计划、风险管理计划、质量保证计划、配置管理计划、总体测试计划（依据项目的不同，或者还包括性能测试计划）等；
 需求阶段：业务需求说明、业务蓝图、软件需求说明，需求跟踪矩阵、调研大纲、调研资料；
 设计阶段：设计文档（包括概要设计和详细设计），模型设计、原型设计（包括数据库、BI模型等）；
 开发阶段：程序源代码、数据、可执行文件、数据库部分、介质（对于数据中心项目程序源代码部分包括ETL部分、cognos部分、框架部分等） 、工具、基准库
 测试阶段：测试用例、测试计划和测试数据、测试报告、测试方案、测试总结；
 实施阶段：实施计划、实施方案、实施总结
 发布阶段：发布的程序版本（主要包括可运行程序和数据库，其中可运行程序部分对于数据中心类项目主要包括ETL部分、BI部分和程序，数据库部分主要包括资料库和增量数据，属于该阶段的配置项还应该包括用户文档，但是把用户的文档作为项目的管理文档进行管理，组内的配置管理人员对此不做管理）；
 其余的配置项包括：会议纪要、项目周报、风险记录、项目计划、培训记录、会议纪要、质量保证过程文档等。
3.3.3 审批配置管理计划
《配置管理计划》的由项目经理负责审批、给出审批意见，审批未通过必须由组织级CM重新编写，直到审批通过为止。
3.4 配置库的建立
所有项目应建立配置库，以便管理各配置项，组织级CM负责组织建立配置库。配置库统一由组织级CM管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。
3.4.1配置项标识要求
 合同有明确标识和追踪要求时，由相关人员按合同要求进行标识，以保证满足合同追踪要求。
 在开发过程中由项目组人员提交的配置项，由项目组人员按照标识规则进行标识。
 项目组人员将要标识或已标识的配置项提交给组织级CM纳入配置库统一管理，组织级CM做好配置项管理记录，并填写详细的备注信息。
3.4.2配置项标识规则
1. 项目命名
产品标识是在项目开始立项时就确定下来的，由项目管理部门分配的，根据组织内当年项目的先后顺序，依次产生。
1) 项目的名称由客户和开发部门协商确定，一般以项目所实现的系统功能来命名。
2) 项目编号则用代号表示为：“AA-BBBB-XXYYYY-ZZ”。各符号位的含义如下：
 “AA”为客户所在省份，如陕西为“SX”
 “BBBB”为客户单位名称，2~4皆可。
 “XX”为产品类别号，用两位英文字母表示，在产品产生的过程中定义，按产品分类（生产类（SC），办公自动化（OA），数据中心（DC），企业门户（EP），服务外包（FW），档案（DA））。
 “YYYY”为项目立项年份代号，用四位数字表示。例如，2001年记为“2001”。
 “ZZ”为顺序号，用两位数字表示：“01~99”。按立项的先后顺序编号。

示例：SX-DL-EP2009-02为2009年第02号项目为陕西电力的企业门户项目。
2. 文件标识
文件标识主要由三部分组成：项目名称（英文字母缩写）+文件名称（英文字母缩写）+版本号，其表现形式为：中文文件名（项目名称（英文字母缩写）_文件名称（英文字母缩写），版本信息在文件内的版本说明中进行体现。举例：宁夏数据中心二期建设项目需求规格说明书（NXDL_DC_SR），其版本号在文档内部的版本记录中表现。

3.5 管理配置库
3.5.1 配置库目录结构
SVN配置库主要分为代码区和文档区两个部分。其中，代码区包括：开发区、构建区、测试区和发布区。文档区分为：个人工作区、缓冲区、基线区和管理文档区。上述区域由组织级CM统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进
3.5.1.1 代码区
编码区：代码区的编码区对应的是开发团队的公共空间。凡是要为同组人员共享的配置项都从该分支获得。即各开发人员必须将私有工作空间中的开发成果归并（Merge）到该分支后才能进入下一个开发活动。所有涉及多人协调的开发工作（如集成测试等）都必须工作在这一空间中。该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限。该分支的管理工作由项目级CM及相关指定人员负责。
构建区：构建区是项目级CM的工作空间，只有项目级CM对该区有读写权限， 组织级CM和QA人员该区有只读权限，项目组其他人员无权操作。该区域主要是对送测程序进行产品集成并对程序源码按版本进行备份（如：系统的一个大的模块）。
测试区：测试区也是项目级CM的工作空间，只有项目级CM对该区有读写权限， 组织级CM、QA人员、测试人员对该区有只读权限。项目级CM将集成好的程序进行编译后，提交到测试区以供测试人员对程序进行验证。（该区域不包含程序的源代码）
发布区：组织级CM对该区有读写权限，QA人员、实施人员对该区有只读权。即该区域保存通过测试验证并正式发布的程序文件。每次发布组织级CM要对发布的程序进行版本控制，并向项目组发送产品发布通知。
3.5.1.2 文档区
个人工作区：代码区的个人工作区对应的是项目组成员的私有开发空间。项目组成员根据任务分工获得对相应配置项的操作许可之后，他即在自己的私有开发分支上工作，他的所有工作成果体现为在该配置项的私有空间上的版本的推进，除该项目组成员以及组织级CM外，其他人员均无权操作该私有空间中的元素。
缓存区：主要用于放置项目过程中的各个阶段（包括：需求阶段、设计阶段、测试阶段、实施阶段）产生了的一些临时性文档，如需求阶段需求人员收集的一些和用户需求相关的资料、业务需求说明书、需求规格说明书（未经过评审或在创建、修改过程中）。缓冲区由组织级CM授权的相应人员进行相关操作，具体操作权限可见3.5.2配置库各目录权限说明。
基线区：基线区是整个SVN配置库管理的重点，只有组织级CM有写入权限，项目组其他人员有可读权限。基线区存放软件生命周期各个阶段产生的重要工作产品，基线区的配置项是一般是稳定版本或者趋于稳定的产品版本，不能轻易变更，如需要变更，必须走变更流程（可参见3.7变更控制）。
管理文档区：管理文档区主要用来存放软件开发过程中，产生的管理文档或支持文档，包括：计划、周报、评审记录、会议纪要、风险记录、出差记录、配置记录、质量保证等工作产品。该区域同基线区一样只有组织级CM有写入权限，项目组其他人员有可读权限。

I. 编码人员按照工作计划，根据获得的授权的资源进行项目的研发工作，操作配置库完成相应的编码工作，由编码的相关人员编写送测说明，提交给项目级CM（公司现有开发组长兼任该职位，或由开发组长授权其他编码人员）。
II. 项目级CM根据送测说明，提取相应的代码文件，搭建系统环境，对程序进行集成并编译，将集成好的程序提交到配置库的构建区以作为下步开发的基础程序。
III. 由项目级CM将构建区对应的程序编译后的程序提交到测试区提供测试进行测试（测试区的程序不应该包含源代码）。
IV. 测试人员在收到开发组长的送测说明后，从测试区检出相应的程序，进行测试、验证。
V. 通过测试验证后，测试负责人要对该版本进行发布，同时，组织级CM做好发布记录，即发布区对应的和构建区程序以及发布版本对应的需求、设计。（目前该部分工作缺少模板）
VI. 组织级CM根据配置管理计划创建与维护基线，“冻结”配置项，控制变更。
VII. 当发生变更且变更评审通过后，或者发现Bug且Bug评审通过后，由项目级CM从构建区将中相关程序检出至开发人员的编码区上，供开发人员进行变更。
VIII. 当变更实施结束或Bug修正和测试结束，并通过配置审核后，由项目级CM将变更后的文件检入到构建区打上版本标识并做好版本记录。
IX. 项目级CM定期清除配置库（编码区、构建区、测试区）里的垃圾文件，并做好项目级的基线备份。
X. 组织级CM在整个过程中，维护管理配置库、发布基线、以及各类文档的管理并定时向CCB发布配置状态报告。
3.6 配置项和基线管理
组织级CM根据配置管理计划，对配置项和基线进行分阶段管理。
3.6.1项目启动
配置项包括项目方案、技术协议、项目合同、业务需求说明书等；项目立项后创建项目的发启基线。
3.6.2需求分析
系统调研后需求人员进行系统分析，并整理需求分析报告。需求分析报告通过评审并需取得客户的确认。在需求分析报告取得客户的确认后，建立需求基线。如需修改则必须通过变更流程、通过评审并得到客户的确认。
3.6.3项目计划
需求分析完成后即可制定项目的开发计划，包括项目计划书、风险列表、配置管理计划、质量保证计划、测试计划、度量计划等。项目开发计划评审通过后，封锁该子项目，建立项目计划基线。（公司目前没有将项目计划纳入基线管理~~~~）
3.6.4系统设计
系统设计可分为概要设计、详细设计和数据库设计等部分。针对需求分析报告进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。
3.6.5 编码
编码按功能模块分子项目，即每个模块计作一个配置项。代码基线分别在单元测试结束后建立最初（Alpha）版，最初版（Alpha）测试后建立试用（Beta）版，在完成集成测试后建立发布（Merge）版。在代码基线生成时，组织级CM注意维护源代码清单。
3.6.6 测试
各测试阶段应提供测试计划、测试结果和测试分析报告，项目启动后应提供项目测试计划书，项目验收结束后应提交项目测试总结报告等。配置时应说明测试的版本与编码版本的对应关系。各阶段测试（如单元测试、集成测试）完成后建立测试基线。
3.6.7 项目验收与运维
项目在交付前配置审核完成后建立产品基线，产品基线包含程序以及有关文档配置项，包括交付施工文档、工具等。在运维过程中，对这里配置项进行管理，在一定的情况下（比如增加新功能），建立其版本分支。
3.6.8 项目总结
项目结项过程项目经理需要向CCB提交项目总结，项目总结应经过部门内部评审，包括项目总结报告、QA总结报告、测试总结报告、配置总结报告等。
3.6.9 产品部署
部署时应包括用户操作手册、安装维护手册、维护文档以及必要的业务和技术培训文档。
3.6.10 相关资料
相关资料和培训记录也被纳入配置管理，这些资料包括：项目周报、会议纪要、评审记录、培训记录、出差记录、风险记录、配置记录、质量保证等。
3.7 变更控制
3.7.1 变更的分类
软件以及与其相关的文档的变更主要分为两大类：
1、重大变更：变更会影响系统级需求、外部接口、产品价格、交付日期、配置项间的功能接口、组件级成本等；
2、普通变更：变更会影响配置项内部功能的设计和分配；
对于重大的变更，当事人必须提交向CCB小组变更申请，由CCB审批并经过客户同意后才能进行变更，组织级CM做好变更记录。
对于普通级别的变更，由项目经理和组织级CM协商并达成一致方能进行变更，同时组织级CM要做好变更记录。
3.7.2 变更流程
1） 由变更申请人，填写《变更申请单》，分析变更对项目造成的影响描述变更原因和变更内容，并提交给组织级CM和QA。
2） QA人员对填写的申请表是否清晰、明确和完整性进行审查，若发现变更不明确或不完整，应返回申请表给申请者。
3） 组织级CM将通过审查的《变更申请单》发送给项目经理（或者其他授权人员），由相关组协同CCB对变更进行评估。变更评估是变更控制管理的一个重要的环节。变更评估要分析每个变更对系统功能、接口、成本、进度以及约定需求的影响，同时还要分析对软件安全性、可靠性、可维护性、可移植性和性能的影响。
4） 项目经理将评估后的《变更申请单》发送给QA人员，由QA人员发送给CCB小组成员对变更进行审核并批准变更。
5） 通过审核后，项目经理负责指定变更执行人进行变更，由变更执行人开始实施变更，并详细记录变更的内容；QA人员要对变更的实施进行跟踪。
6） 对于代码变更，必须修改设计、代码、测试以及变更正确性的验证。而且与变更相关的文档必须修订，以反映变更。
7） 变更后的程序后必需经过测试组进行回归测试，以确保变更没有引入新的Bug。不会引起程序变更的文档（如计划文档）的变更不需经过测试。
8） 版本变更后，组织级CM负责收集所有变更信息归档，修改变更的记录，并发布新的版本，变更结束。
3.8 配置状态报告
3.8.1 发布方式
配置状态报告是为了让项目组成员、公司领导及客户清楚、及时地记载软件配置的变化，不致于到后期造成贻误，需要对开发的过程作出系统的记录，以反映开发活动的历史情况。配置状态报告一般包括：
1、基础信息：
    配置库名称、管理工具名称、配置管理员等等
2、配置项记录:
    配置项名称、正式发布日期、版本变化历史、作者
3、基线记录：
    基线名称、版本、创建日期、包含的配置项等等
4、配置库备份记录
    批次、备份日期、备份内容、说明、备份到何处、责任人
5、配置库重要操作日志（配置管理员记录自己和他人对配置库的重要操作，例如删除文件等。）
配置状态报告发布方式包括两种：时间驱动和事件驱动，目的是记录和报告整个软件生命周期演化状态。
 时间驱动：即在一定的时间段（或时间点），由组织级CM向项目组所有成员发布配置状态报告。
 事件驱动：基线生成时或者重要配置项发生变更或增加时都由组织级CM向项目组全体成员发布配置状态报告。
3.8.2 配置状态报告内容
1) 软件和文档的标识；
2) 目前状态；
3) 基线演化状态；
4) 变更状态；
5) 版本交付信息等
3.9 配置审计
3.9.1 配置审计类别
1) 功能配置审计：审核软件功能是否与需求一致，并符合基线文档要求；通常要审查测试方法、流程、报告和设计文档等。
2) 物理配置审计：审核要交付的组成项是否存在，是否包含所有必需的项目，如正确版本的源代码、资源、文档、安装说明等。
3.9.2 配置审计的时机
通常选择以下几种情况由质量保证人员负责实施配置审计：
1) 软件产品交付或是软件产品正式发行前；
2) 软件开发的阶段工作结束后；
3) 在产品维护工作中，定期地进行。
3.9.3不符合项的处理
对配置审核中发现的不符合现象，QA进行记录，并交由责任部门限期进行纠正，QA负责纠正措施的验证。直到所有的不符合项报告均关闭后，才能发布新版本。
3.10 交付管理
这里“交付”是指从配置库中提取配置项，交付给客户或项目外的人员。交付出去的配置项必须有据可查，避免发生混乱。流程如下：
1)“索取人”向CCB提出交付申请。
2) CCB审批该申请。如果该申请不合法（合理），则拒绝交付配置项。如果同意交付，CCB应给出详细的交付清单。
3) 组织级CM依据CCB的批示，从配置库中提取配置项交付给“索取人”。
4)“索取人”验收后签字。