卷号DEPLOY卷内编号DEPLOY005密级组内HD20090917SR005通用型行政审批服务协同管理平台配置管理计划1.2项目承担部门：java第四组撰写人（签名）：区允文完成日期：2010年8月4日本文档使用部门：■主管领导■项目组□客户（市场）□维护人员□用户评审负责人（签名）：江威龙评审日期：2010/8/4目录1.简介41.1目的41.2范围41.3定义、首字母缩写词和缩略语41.4参考资料41.5概述42.项目配置42.1组织结构42.2职责和接口52.3工具、环境和基础设施53.配置管理活动63.1配置库63.1.1配置库架构63.1.2权限分配73.1.3配置库层次及开发活动说明：83.2配置标识93.2.1标识方法93.2.2项目基线103.3配置项113.4配置和变更控制113.4.1变更请求的处理和审批113.4.2变更控制委员会 (CCB)113.4.3变更过程中的活动113.4.4变更过程中的变更请求状态123.4.5保存变更历史记录133.4.6变更请求中受影响配置项的变更133.5配置状态统计143.5.1项目介质存储和发布进程143.5.2报告和审计144.里程碑155.培训和资源156.分包商和厂商软件控制157.附录15配置管理计划1.简介1.1目的为了使项目相关的各种资源便于查看，修改，不至于凌乱；为了让各个开发人员方便高效地协同合作；为了项目的版本便于管理，作出此配置管理计划。
1.2范围项目进行中所得出的所有工件都要遵守此计划，包括文档以及源代码，以及硬件。
1.3定义、首字母缩写词和缩略语CM：配置管理。
CCB：变更控制委员会。
CI：配置项。
包含文档、程序。
Baseline：基线。
CR：变更请求。
PCA：物理审计。
FCA：功能审计。
1.4参考资料《华南农业大学软件学院实训讲义》《华南农业大学项目阶段评审工件》1.5概述此文档对项目开发过程中的配置方面作出约束，开发以及变更都要按照要求来做。
2.项目配置2.1组织结构2.2职责和接口2.3工具、环境和基础设施管理工具：svn1.6.10使用阶段：先启、精化、构建、产品化阶段原因：高效，稳定产品数据量的预期大小：我们期望本项目至少有500个文件，150M的磁盘空间。
产品团队的分配：6台计算机，其中4台手提电脑，全部使用双核cpu，windows xp以上的操作系统。
JDK:1.6集成开发环境：myeclipse 8.5Jdbc：sql_jdbc_3.0.1301.101_chs3.配置管理活动3.1配置库3.1.1配置库架构配置库架构如图所示：通用型行政审批协同服务管理平台开发库受控库基线库变更区如上图所示，有4个配置库。
分别为：开发库、受控库、基线库、变更区3.1.2权限分配开发库权限：3.1.3配置库层次及开发活动说明：1.确定角色分配2.确定某人A所要做的工件3.A根据当前情况，一个工件可以分给其他人做，每个人都把自己做好的工件放在自己的工作区4.A把其他人做的工件集成5.修改完毕后评审6.评审通过则放在开发库相应目录7.如果没有权限，则通知配置经理，置其于受控库或基线库。
否则自己上传。
8.要放进基线库的工件必须参考受控库的工件9.文件的命名规则请参考“配置标识”因此，有三个层次：开发―――受控―――基线注意：文档规定谁做就谁做，不能随便更改别人的文档，文档一旦评审完毕放上受控或基线后，要更改必须提交变更申请。
3.2配置标识3.2.1标识方法把项目文档分为6类以下是每类文档的卷号说明：开发类：DEVELOP配置管理类：DEPLOY需求管理类：DEMAND测试类：TEST质量保证类：QUALITY项目监督与控制类：SUPERVISE卷内编号＝以上单词加下面号码，说明：如有其他新文档，本配置计划会更新，到时留意。
项目开发计划:001甘特图:002同行评审报告:003项目问题跟踪表:004配置管理计划:005质量保证计划:006词汇表:007角色描述:008用例描述：000，说明，用例的圈内编号＝以上的单词＋工号＋自己定义不重复的3位数软件需求规约:009软件实现规约:010同行评审报告:011需求基线:012配置库:013配置管理项目清单:014基线建立申请单:015需求基线状态报告:016需求基线审计报告:017配置状态报告:018基线审计报告019PPQA检查单:020PPQA阶段报告:021测试计划:022阶段评审报告:023阶段总结报告:024系统构架设计：025数据库设计说明书：026集成测试用例：027系统测试用例：028测试用例：029测试日志：030单元测试结果报告：031集成测试计划：032缺陷跟踪表：033测试分析报告：034项目开发总结报告：035用户手册：036周例会纪要：037项目周报：038项目工作日志：039项目问题跟踪表：040不符合问题跟踪表：041需求跟踪矩阵：042变更申请汇总表：043项目编号：HD20090917SR005项目名称：通用型行政审批服务协同管理平台项目工作日志：workDiary + 员工号 + 该日志最后的日期文档编号及模块单词缩写：参照《CMMI3过程域简称》说明：文档名字前面的项目名称改为SCAU-JAVA4 加上模块缩写如配置就写-CM，再加上编号，如配置计划就加-301，开发库和工作区的文档在名字后面加上版本号。
千万不要分工作日期的文件夹。
否则集成时可能集成的是老版本的。
3.2.2项目基线1、在先启阶段、精化阶段、构建阶段和产品化阶段结束时建立2、在各阶段内评审完成时建立3、在各阶段内，由构架分析员或项目经理决定需建立基线时建立4、当某一个工件的功能基本完成时或经过一定的改动时，其状态就达到基线水平。
5、基线内容应该包含：版本、功能。
3.3配置项见《配置管理项目清单》3.4配置和变更控制3.4.1变更请求的处理和审批软件配置的变更管理适用于本项目的所有文档和代码，其中包括本项目的各个运行软件，也包括为本项目专门开发的支持软件。
3.4.2 变更控制委员会 (CCB)1.职责：CCB 的基本任务是明确产品的基线、复审对基线的变更、最后批准、否决变更或延期执行。
2.选择成员标准：从用户、开发人员、测试小组、项目管理中选择。
3.项目的CCB成员为：区允文、江威龙、梁旖倩、钟文辉、陈玮珊、陈理经。
B 主席：江威龙5.处理变更请求和确认的过程：CCB以事触发为主要工作方式，必须定期(每个阶段结束时)按需召开会议。
确保变更提议及时得到了复审和处理。
拟定变更复审通知协议。
确保变更请求提交后，各有关人员都得到了通知，决定由谁复审各种工件。
传达给同事和团队负责人，以及变更提议的接受者，并让他们有机会复审并参与意见。
3.4.3变更过程中的活动变更过程中的活动(活动图)：3.4.4变更过程中的变更请求状态3.4.5保存变更历史记录如果工件为Word文档，则在文档的修订文档历史记录。
如果工件为其他工件，必须在相应的记录中保存变更历史记录。
3.4.6变更请求中受影响配置项的变更在变更请求中受影响配置项需要变更时，首先由CCB协调员通知受影响配置项的变更人员，其次被通知人员按照标准变更流程进行变更。
3.5配置状态统计3.5.1项目介质存储和发布进程1.备份机制及保留策略：1)每天下班时将主服务器的数据备份到U盘中。
2)U盘保留最新的数据。
2.事故处理和恢复机制：如果出现事故(如：主服务器当机、遭病毒、硬件损坏等)，采用U盘上的数据进行恢复。
3.防病毒/杀毒机制：1)杀毒/防病毒软件：瑞星2010。
2)频率：每周末杀毒。
3)负责人：系统管理员(区允文)。
介质保留方式：介质保留方式：联机。
类型：磁盘（硬盘）。
格式：ntfs。
3.5.2报告和审计目的：让项目经理确定需要报告哪些产品的相关变更数据，以及报告人和报告频率。
频率：每个里程碑进行报告。
报告人：配置管理经理。
1.工作版本报告。
工作版本报告中列出了构成软件某一特定版本的一个工作版本的所有文件、它们的位置以及已并入的变更。
2.审计。
包含功能审计和物理审计。
1)功能审计：核实软件配置项的实际性能是否符合它的需求。
2)物理审计：验证在配置管理系统中建立基线的工件是否为“正确”版本。
3.配置状态报告（见《配置状态报告》）4.里程碑每个阶段结束建立一个里程碑。
1.初始阶段结束时是第一个重要的里程碑：生命周期目标(Lifecycle Objective)里程碑。
生命周期目标里程碑评价项目基本的生存能力。
2.细化阶段结束时第二个重要的里程碑：生命周期结构(Lifecycle Architecture)里程碑。
生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。
此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。
3. 构建阶段结束时是第三个重要的里程碑：初始功能(Initial Operational)里程碑。
初始功能里程碑决定了产品是否可以在测试环境中进行部署。
此刻，要确定软件、环境、用户是否可以开始系统的运作。
此时的产品版本也常被称为“beta”版。
4. 在交付阶段的终点是第四个里程碑：产品发布(Product Release)里程碑。
此时，要确定目标是否实现，是否应该开始另一个开发周期。
在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。
5.培训和资源软件工具：svn人员：区允文培训：6.分包商和厂商软件控制把项目打包为war文件，移植的时候只需解压缩就行了。
7.附录变更请求申请书：见“变更申请单模板.xls”。