燃气客户管理系统建设投标方案（技术标430页）（2024年修订版）.docx

燃气客户管理系统建设投标方案 目录 第一章 项目实施管理过程 9 第一节 平台系统概述 9 第一条 平台建设背景 9 第二条 平台定位和战略目标 9 第二节 总体计划 10 第三节 项目计划 11 第一条 获取约定 11 第二条 编制项目计划 11 第三条 项目跟踪 12 第四节 软件开发 14 第五节 项目执行与控制 22 第六节 项目验收与结束 25 第一条 系统投入使用验收 25 第二条 系统初验 26 第三条 系统终验 26 第四条 项目结束 27 第七节 软件配置管理 27 第一条 基线库管理 28 第二条 配置管理实施流程 31 第八节 质量保证 36 第九节 风险管理 39 第十节 项目总体进度安排 39 第二章 项目总体方案 42 第一节 技术架构 42 第一条 系统技术原则 42 第二条 系统架构技术原则 43 第三条 基本概念 45 第四条 分层技术架构 49 第五条 基于J2EE的软件层次结构 55 第六条 关键设计考虑 57 第二节 建设思路 69 第三节 系统开发环境 70 第一条 网络环境硬件拓扑图 70 第二条 平台技术开发环境 70 第三条 编程框架 78 第四条 业务封装拓展 79 第五条 系统测试 79 第四节 系统拓扑结构 80 第五节 系统部署 81 第一条 概述 81 第二条 系统拓扑结构 82 第三条 具体系统部署 82 第四条 系统部署的优点 90 第六节 数据库空间规划 92 第七节 点对点详细设计 97 第八节 主要技术选型 99 第一条 遵循国际标准规范协议 99 第二条 利用XML技术实现数据间的传输交换 100 第三章 功能规划方案 101 第一节 预期目标 101 第二节 系统整体架构 102 第三节 功能架构 103 第一条 集团VCC统一门户 103 第二条 VCC统一门户 104 第三条 网上商城 104 第四条 数据挖掘分析 104 第四节 多业务场景数据流转分析 104 第五节 企业端功能规划 105 第一条 用户管理 106 第二条 个人信息查询 107 第三条 业务办理 112 第四条 充值缴费 115 第五条 燃气具商城 117 第六条 咨询与投诉 124 第七条 通知和提醒 125 第八条 网点展示 126 第九条 网上客户服务 127 第十条 积分管理 128 第六节 集团端功能规划和实现 136 第一条 三户模型概念 137 第二条 集团端数据库设计 139 第三条 权限管理 147 第四条 集团端和企业端客户数据交换逻辑 149 第七节 集团端门户统一认证与单点登陆 150 第一条 设备功能说明 151 第二条 接口功能说明 152 第三条 业务流程 153 第四条 用户登出流程 168 第八节 网上商城 171 第一条 基本版功能 171 第二条 升级版功能 172 第九节 数据挖掘 174 第一条 基本版功能 174 第二条 升级版功能 176 第十节 典型业务场景原型设计 179 第一条 网页原型 179 第二条 APP原型 183 第三条 微信原型 187 第四条 统一接口平台 189 第四章 系统运行管理方案 214 第一节 监控管理 214 第一条 IT基础设施监控 214 第二条 应用软件监控 239 第三条 业务监控 248 第四条 监控展现 270 第二节 运维管理 275 第一条 流程引擎 275 第二条 运维管理流程 300 第五章 系统服务实施方案 336 第一节 IC卡在线充值解决方案 336 第一条 概述 336 第二条 读卡器功能和性能介绍 337 第三条 读卡器安装方法 338 第四条 读卡器操作方式 339 第五条 应用系统软件升级 342 第六条 应用级软件故障恢复 342 第七条 性能与容错管理 342 第八条 系统和数据库管理 342 第九条 灾难恢复的规划和试运行 343 第十条 咨询服务 343 第十一条 系统例查 343 第十二条 应用系统业务调整 344 第十三条 应用系统业务增加 344 第十四条 系统维护和故障排除 344 第二节 安全性和数据灾备方案 346 第一条 系统安全性 346 第二条 灾备概述 347 第三节 系统功能测试和质量保证方案 350 第一条 概述 350 第二条 质量管理内容 351 第三条 质量管理责任分配 352 第四条 质量保证措施 354 第四节 系统性能及压力测试方案 359 第一条 系统性能 359 第二条 系统结构及流程 360 第三条 性能测试环境 361 第四条 性能压力测试 362 第五条 测试过程及结果描述 366 第五节 培训计划和培训方案 367 第一条 核心业务支撑系统培训方案 367 第二条 高级培训 368 第三条 初级培训 373 第六章 系统上线实施方案 376 第一节 上线实施方案 376 第一条 建设方 376 第二条 承建方 376 第三条 前言 377 第四条 组织与安排 377 第五条 总体计划 379 第六条 应急处理 380 第二节 系统和数据迁移方案 381 第一条 TCIS数据库生产环境 381 第二条 用户 382 第三条 数据迁移具体流程 382 第三节 系统交付部署和验收方案 383 第一条 系统部署方案 383 第二条 项目验收方案 385 第三条 验收需提交的交付物清单 389 第四节 系统上线后续服务 391 第一条 工程技术维护队伍和机构 391 第二条 支持方式 391 第三条 故障处理 393 第四条 服务流程和服务质量保证 395 第五条 保修 396 第七章 项目应急方案 397 第一节 应急总预案 397 第一条 应急预案编制 397 第二条 救援流程 399 第三条 消防培训演练 400 第四条 常用急救常识培训 402 第五条 应急人员安排 406 第六条 应急指挥安排 408 第七条 其他应急培训演练 415 第二节 设备故障应急预案 423 第一条 准备工作 423 第二条 意外事件处理 423 第三节 火警处理应急预案 424 第一条 制定火警处理应急预案的目的 424 第二条 应急预案管理主体及职责 424 第三条 内部火警分级 425 第四条 消防应急小组及职责 425 第五条 火情报警 428 项目实施管理过程 平台系统概述 平台建设背景 从增强老百姓便捷性，提高客户满意度，提升XX燃气自身信息化水平等多层面出发，需要建设一套网上营业厅系统，我们的目的是实现在网上完成线下实体客户中心可以完成的大部分主体业务，提升用户服务能力，提高客户满意度。 平台定位和战略目标 网上营业厅价值链 1.针对客户不断增加的便民查询，业务受理等实际需求，我们将积极整合国内外人才、技术、产品资源，打造XX最便捷的网上处理平台。在平台建设和运营基础上，持续探索各种创新模式，发展多种 有针对性的衍生技术服务，为企业持续创造节能服务价值。 2.XX网上营业厅平台的建设从起步、发展到系统成熟将经历不 同的战略阶段，公司将本着务实审慎的原则，力求结合XX自身的特点以及市场的成熟，逐步扩展平台服务范围和服务空间，在平台建设和市场发展之间形成良性互动，最大限度地实现资源投入效应最大化。 总体计划 对本项目卖方将采取与买方紧密合作的方式，充分发挥合作双方各自优势完成整个项目的实施。根据项目实施的阶段和任务，邀请买方的工作人员参与到项目管理和技术的每一项工作中来，联合成立相应的组织机构，进行有效的分工。双方共同负责对项目进行组织、实施和控制，并在项目实施的各里程碑到达时召开工程协调会，进行工程的总结、组织、协调工作。 项目启动后，将由卖方项目计划控制小组定期召集工作会议，讨论各阶段任务的执行情况，分析存在的问题，提出改进方法，尤其注重讨论那些潜在的风险，提出相应的风险处理对策，并将会议结果及时通报给买方，由买方进行审核和确认，以确保项目按期高质量地完成。 项目计划 获取约定 项目经理参与项目的准备工作，并且负责与售前项目的交接，获 得项目的《工作说明书》,《工作说明书》是项目与客户及与公司的约定，项目经理还需要获得公司对项目的其他要求。这些信息是项目经理在项目启动阶段需要获取的基本信息，并作为编写项目计划的输入。 编制项目计划 1.确定项目概要：关于项目的编号、名称信息，本项目的工作说明书(SOW),项目建设目标、最终的可交付物，项目计划文档中使用的专业术语解释，制订项目计划过程中使用的参考资料。 2.项目组织结构：项目组织结构描述了项目的人员与组织结构和项目人力资源分配的信息。 3.项目估算：软件产品规模估算、成本估算、工作量估算、工作进度估算、关键资源的估算。 4.制定风险管理计划：描述项目风险承受度的分析和项目组为有效管理风险所要采取的行动。 5.确定项目里程碑和WBS:WBS是项目计划中重要的工作内容，通过对软件开发工作进行分解，并结合估算的进度要求，编写《项目WBS工作表》,表征每项工作任务完成的标志性事件即所谓“里程碑”。 6.资源计划：分析项目的硬件设备需求、软件设备需求，以及工作环境、计划环境要求，并指定相应的责任人。 7.交流沟通计划和培训计划。 8.评审项目计划：项目经理将项目计划发给技术协调小组、买方 相关人员，并组织买方确认工作，买方确认工作采用管理评审的方式 的进行，评审的内容主要针对人员组织、关键依赖、估算中的进度、里程碑、提交物和详细的WBS表、风险管理表等内容。根据评审结果对项目计划进行修订，修订后的项目计划要得到买方项目负责人的确认。 9.发布计划：项目经理将通过评审后的项目计划申请基线化，并通过邮件或会议的方式通知所有项目涉及人员。 项目跟踪 1.任务跟踪：明确项目中任务下达与跟踪的形式，包括了对任务计划、任务安排、任务跟踪这些活动的要求、相应的责任人及输出产物。 2.事务跟踪：明确项目中要进行跟踪的事务类别、跟踪的频度、跟踪采用的方法或工具及相应的责任人，如问题跟踪、缺陷跟踪、需求跟踪、评审缺陷跟踪等。 3.买方反馈：确定项目中对买方反馈、建议，甚至抱怨的应对责任人(比如项目经理或设立专职的客户经理)和记录跟踪的方式。 4.状态报告：确定项目组需要向相关人或组织提交报告的信息，包括报告的对象、频度、报告文件名称。如：买方、卖方的资深管理层的相应报告。 5.项目跟踪和监督需要有下列具体的子活动： (1)每周例会，必要时邀请买方参加。 (2)提交和通报QA周报告、配置状态报告、开发小组工作报告 、 测试小组工作报告和其他。 (3)总结项目的实际进展数据，并在项目周报中体现，主要数据包括项目的当前的工作绩效(产品的完成情况)、进度情况、缺陷总结、需求稳定度分析和变更发生情况。 (4)总结项目组存在的问题和分析项目进展的风险。 (5)对重要问题的日常跟踪回顾。 (6)在必要时出《项目偏差控制报告》。《项目偏差控制报告》是对估算出现偏差的一个总结报告。并决定是否需要修改项目计划。 (7)出会议纪要和项目工作周报。 (8)在必要时提出项目工作月报。 (9)日常监督和跟踪工作、风险管理工作。 (10)对项目周报中的项目问题进行跟踪。 (11)对项目周报中的项目风险问题进行跟踪。 (12)对项目周报中其他事项进行跟踪。 软件开发 软件开发通常需要经过分析、设计、实现和运行维护等几个阶段。为了用工程化方式来有效的管理软件项目的全过程，软件项目生命周期也可以分成几个阶段。对软件项目生命周期的不同划分，形成不同的软件项目工程模型。目前在本软件开发实践中使用的标准软件项目生命周期，都是以下几个阶段的不同排列组合。 项目启动、需求分析、项目设计、核心开发、定制开发、产品发 布、产品交付、初验、终验、维护。 以下分别介绍我们本软件开发中三类典型项目的组织标准软件项目生命周期。 一、组织标准软件项目生命周期-----研发项目 首先，在这里对软件项目生命周期中通用的公共活动进行必要描述： 1.项目启动 序号 关键活动 工作产物/输出 1 项目跟踪与监督 项目周报、项目例会纪要、问题跟踪管理表、风险管理计划 2 软件质量保证 QA审核报告、QA工作周报、不符合报告 3 软件配置管理 配置审计报告、配置状态报告 4 阶段退出 会议纪要、阶段总结报告 2.需求分析 序号 关键活动 工作产物/输出 1 实施项目可行性研究 项目可行性报告 2 召开项目启动会议 3 制定项目计划 项目计划书、项目软件配置管理 计划书、项目软件质量保证计划 书 4 同行评审活动 评审报告、缺陷管理表 3.项目设计 序号 关键活动 工作产物/输出 1 编写需求规格书、需求跟踪矩阵 需求规格书、需求跟踪矩阵 2 细化项目计划 项目计划书、项目软件配置管 理计划书、项目软件质量保证 计划书 3 制定项目测试计划(包括方 案) 测试计划 4 同行评审活动 评审报告、缺陷管理表 4.核心开发阶段 序号 关键活动 工作产物/输出 1 概要设计 概要设计规格书 2 详细设计 详细设计书 3 细化项目测试计划(包括方 案) 测试计划 4 同行评审活动 评审报告、缺陷管理表 5.产品发布 序号 关键活动 工作产物/输出 1 编写代码 代码 2 进行单元测试 单元测试报告 3 持续集成测试 测试状况报告 4 进行系统测试 系统测试报告 5 文档编写 用户手册、操作手册 6 同行评审活动 评审报告、缺陷管理表 6.产品交付 序号 关键活动 工作产物/输出 1 发布版本 版本发布报告 2 项目总结 项目总结报告 二、组织标准软件项目生命周期一工程项目 首先，在这里对软件项目生命周期中通用的公共活动进行必要描述： 序号 关键活动 工作产物/输出 1 项目跟踪与监督 项目周报、项目例会纪要 、 问题跟踪管理表、风险管理计划 2 软件质量保证 QA审核报告、QA工作周报、不符合报告 3 软件配置管理 配置审计报告、配置状态报告 4 阶段退出 会议纪要、阶段总结报告 1.项目启动 序号 关键活动 工作产物/输出 1 召开项目启动会议 2 制定项目计划 项目计划书、项目软件配置管 理计划书、项目软件质量保证 计划书 3 同行评审活动 评审报告、缺陷管理表 2.需求分析 序号 关键活动 工作产物/输出 1 编写需求规格书、需求跟踪矩阵 需求规格书、需求跟踪矩阵 2 细化项目计划 项目计划书、项目软件配置管 理计划书、项目软件质量保证 计划书 3 制定项目测试计划(包括方 案) 测试计划 4 同行评审活动 评审报告、缺陷管理表 3.项目设计 序号 关键活动 工作产物/输出 1 概要设计 概要设计规格书 2 详细设计 详细设计书 3 细化项目测试计划(包括方 案) 测试计划 4 同行评审活动 评审报告、缺陷管理表 4.核心开发阶段 序号 关键活动 工作产物/输出 1 编写代码 代码 2 进行单元测试 单元测试报告 3 持续集成测试 测试状况报告 4 进行系统测试 系统测试报告 5 文档编写 用户手册、操作手册 6 同行评审活动 评审报告、缺陷管理表 5.定制开发阶段 序号 关键活动 工作产物/输出 1 编写代码 代码 2 进行单元测试 单元测试报告 3 持续集成测试 测试状况报告 4 编制用户测试计划 用户测试计划 5 进行系统测试 系统测试报告 6 进行用户测试 用户测试报告 7 文档编写 用户手册、操作手册 8 同行评审活动 评审报告、缺陷管理表 6.产品发布/软件交付阶段 序号 关键活动 工作产物/输出 1 发布版本 版本发布报告 2 编制上线方案 上线方案 3 系统上线 上线总结报告 7.软件维护阶段 序号 关键活动 工作产物/输出 1 确认维护需求(包括BUG) 需求变更申请单/Bug单 2 维护设计、开发 设计书 3 内部测试 修改测试单 4 用户测试 用户测试报告 5 维护需求上线 上线申请与批准报告 6 同行评审活动 评审报告、缺陷管理表 8.初验 序号 关键活动 工作产物/输出 1 编制试运行报告 试运行报告 2 用户验收测试 用户验收报告 3 初验 初验报告 9.终验 序号 关键活动 工作产物/输出 1 编制技术总结报告 技术总结报告 2 编制项目总结报告 项目总结报告 3 用户验收测试 用户测试报告 4 终验 终验报告 三、组织标准软件项目生命周期一维护项目 1.首先，在这里对软件项目生命周期中通用的公共活动进行必要描述： 序号 关键活动 工作产物/输出 1 项目跟踪与监督 项目周报、项目例会纪要 、 问题跟踪管理表、风险管理计划 2 软件质量保证 QA审核报告、QA工作周报、不符合报告 3 软件配置管理 配置审计报告、配置状态报告 4 阶段退出 会议纪要、阶段总结报告 2.项目启动 序号 关键活动 工作产物/输出 1 召开维护交接会议 2 制定维护项目计划 维护项目计划 3 同行评审活动 评审报告、缺陷管理表 3.项目实施 序号 关键活动 工作产物/输出 1 确认维护需求(包括BUG) 需求变更申请单/Bug单 2 维护设计、开发 设计书 3 内部测试 修改测试单 4 用户测试 用户测试报告 5 维护需求上线 上线申请与批准报告 6 同行评审活动 评审报告、缺陷管理表 4.项目结束 序号 关键活动 工作产物/输出 1 提交维护总结报告 维护总结报告 项目执行与控制 一、任务跟踪：明确项目中任务下达与跟踪的形式，包括了对任务计划、任务安排、任务跟踪这些活动的要求、相应的责任人及输出 产物。 二、事务跟踪：明确项目中要进行跟踪的事务类别、跟踪的频度、跟踪采用的方法或工具及相应的责任人，如问题跟踪、缺陷跟踪、需求跟踪、评审缺陷跟踪等。 三、买方反馈：确定项目中对买方反馈、建议，甚至抱怨的应对 责任人(比如项目经理或设立专职的客户经理)和记录跟踪的方式。 四、状态报告：确定项目组需要向相关人或组织提交报告的信息，包括报告的对象、频度、报告文件名称。如：向买方、资深管理层的相应报告。 五、项目跟踪和监督需要有下列具体的子活动：1.每周例会，必要时邀请客户参加。 2.提交和通报QA周报告、配置状态报告、开发小组工作报告、测试小组工作报告和其他。 3.总结项目的实际进展数据，并在项目周报中体现，主要数据包括项目的当前的工作绩效(产品的完成情况)、进度情况、缺陷总结、需求稳定度分析和变更发生情况。 4.总结项目组存在的问题和分析项目进展的风险。5.对重要问题的日常跟踪回顾。 6.在必要时出《项目偏差控制报告》。《项目偏差控制报告》是对估算出现偏差的一个总结报告。并决定是否需要修改项目计划。 7.出会议纪要和项目工作周报。8.在必要时出项目工作月报。 9.日常监督和跟踪工作、风险管理工作。 10.对项目周报中的项目问题进行跟踪。 11.对项目周报中的项目风险问题进行跟踪。12.对项目周报中其他事项进行跟踪。 13.修改项目计划(包括子计划):当项目计划出现偏差时，需 要对项目计划进行及时的调整。引起项目计划变更存在多种可能的因数，如原来的进度估计不准确、发生了没有估计到的问题、项目执行过程中的各种变更等等。 14.项目计划应该定期的被检查，发现可能影响项目计划的变更因数，对这些因素进行分析，并在项目例会中确定是否要对项目计划进行调整。 15.修改项目计划之前，必须首先编写《项目偏差控制报告》,该报告是修改项目计划的直接依据。 16.在项目计划的修改前、修改后，需要通过《项目计划变更控制报告》,要求公司的管理层和买方的管理层签字确认。 17.在修改后的项目计划中，必须体现所有受项目计划变更的影响，并作对应的修改。项目计划修改后在必要时必须通过评审。 18.项目计划变更后，需要通知与项目组相关的人员或组织。 19.项目计划变更的工作流程示意图如下。通过项目计划的变更流程，实施对项目计划文档的控制和管理。 项目验收与结束 系统投入使用验收 (一)验收过程 1.系统投入使用验收申请。 2.系统投入使用验收计划。 3.系统设备验收。 4.文档审查、环境检查。 5.制定投入使用测试大纲和测试方案。6.投入使用测试。 7.制定系统割接计划和割接方案。8.系统上线或割接。 (二)验收标准 系统基本功能已经开发完成，能够满足业务的基本要求，系统功能的进一步开发对已开发完成功能的使用不会造成影响时。 (三)验收成果《上线报告》。 系统初验 (一)验收过程1.系统稳定验证。2.系统初验评审。3.系统初验表决。4.系统移交。 (二)验收标准 系统开发建设完成，满足业务要求后进行的验收。初验完成后，允许系统存在少量遗留问题。 (三)时限要求 上线后3个月内。 (四)验收成果《初验报告》。 系统终验 (一)验收过程1.系统终验评审。2.系统终验表决。3.系统最终移交。 (二)验收标准 统完全符合合同要求，经过试运行，系统调整优化到满足目前各业务要求，且基本满足系统性能要求后进行的验收。 (三)时限要求初验后3个月内。(四)验收成果《终验报告》。 项目结束 按照合同约定免费维护期结束后项目结束。 软件配置管理 软件配置管理是项目运作的一个支撑平台，它将项目所有成员 (包括公司中对项目负责的高层经理)的工作协同起来，实现高效的 团队沟通，使工作成果及时共享。当然，这种支撑是贯穿项目的整个生命周期的。 一、配置管理计划在实现软件配置管理计划的过程中，主要实现以下三个里程碑： (一)建立软件配置管理小组：在项目总体组批准软件配置管理计划之后，立即成立软件配置管理小组。 (二)建立各阶段的配置基线：随着系统及其所属各子系统的任务书的评审和批准，建立起功能基线。随着总体组编写的《软件需求规格说明书》的批准，建立起指派基线。随着工程化软件系统的集成与系统测试的完成，建立起产品基线。 (三)建立软件库：在本项目所属的各个子系统的研制工作的开始，就建立起各个子系统的软件开发库，并在本项目配置管理小组的计算机上建立起有关该系统及其子系统的软件受控库。以后在每个开发阶段的结束，建立各个子系统的新的开发库，同时把这个阶段的阶段产品送入总的软件受控库，并在各个子系统的计算机上建立软件受控库的副本。软件受控库必须以主软件受控库为准。当全部开发工作结束，在配置管理小组的计算机上建立起软件产品库，并在各子系统的计算机上建立软件产品库的副本。 基线库管理 基线是项目每个配置项版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变 更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记 录为一个差值，直到建成下一个基线。 (一)配置项基线化前 1.核心思想：开发人员在每天下班之前将当天工作成果提交到开发库开发区。 2.原则：允许多人对一个文件进行CHECKOUT操作。 3.每天开始开发工作之前，所有开发人员访问开发库开发区将要修改的文件进行CHECKOUT操作。 4.每天下班之前，所有开发人员将当天修改的文件进行CHECKIN操作，以及将当天新增的文件加入开发库开发区中。 5.每天下班之前，配置管理员检查所有开发人员是否已经按要求完成第2步操作。 6.配置管理员将开发库开发区锁住，将当前版本提取至测试区。 7.配置管理员解锁并通知项目组开发人员。 (二)配置项基线化 配置项符合以下任何一项要求，才可将其纳入基线库：1.通过GRB评审或。 2.通过CCB审核或。 3.通过配置经理批准。 4.项目经理/技术经理填写“配置项纳入基线请求单”,配置经理审批，配置管理员建立基线。 (三)配置项基线化后 1.核心思想：配置项基线化后纳入基线库，由配置管理员完全控制。 2.原则：不允许多人对一个文件进行CHECKOUT操作，由配置管 理员对此作严格控制。 3.项目组所有人员需对基线库中的配置项进行变更，必须先填写变更单，该申请必须通过CCB审核。 4.配置管理员根据变更单，将基线库需变更的配置项进行CHECKOUT操作或向变更修改人开放权限。 5.当变更修改人完成变更后，将变更单提交给配置管理员，配置管理员或变更修改人更新基线库。 6.项目经理/技术经理填写“配置项纳入基线请求单”,配置经理审批，配置管理员建立基线。 配置管理实施流程 (一)识别配置项 1.配置项基线化的要求 配置经理确定项目配置项标识规定，配置项以及基线计划，GRB对其进行评审。配置经理在配置管理计划中明确系统版本升级策略。配置项包括： (1)文档类配置项。 (2)软件类配置项。2.配置项标识规定 (1)技术文档表示规定：客户名称一项目名称一文档类型名称。 (2)质量记录标识规定：客户名称一项目名称一文档类型名称-序号。 (3)代码标识规定：项目启动阶段，由项目经理或技术经理负责提供，GRB审核。 3.项目管理文档标识规定： (1)会议纪要：客户名称一项目名称一文档类型名称-开会日期。 (2)项目周报：客户名称一项目名称一文档类型名称-提交日期。 (3)技术讨论记录：客户名称一项目名称一文档类型名称-讨论日期。 4.软件发布标识 (1)内部版本标识：内部版本号：X.Y.Z。 (2)外部版本标识：版本号=VXX.XX.XX燃气，分别为：主版本号+次版本号+补丁号。 (二)版本控制配置库： 开发库，基线库，发布库，这三库的目录结构都是相同的。 项目经理，技术经理，测试经理裁减标准目录结构，共同确定项目目录结构，填写“项目配置管理库建库申请单”,提交至配置经理，将其纳入配置管理计划，配置管理员负责创建。 开发库 开发区 用途 开发阶段：为项目组所有成员提供私有的工作区域。 数据来源 项目组成员提交 权限 项目组所有人员：可读/可写 测试区 用途 开发阶段：存放待测试的代码版本 数据来源 开发区 权限 配置管理员，测试人员：可读/可写其他人员：可读 基线库 用途 存放项目过程中配置项的所有基线版本。 数据来源 开发库 权限 配置管理员：可读/可写 其他人员：可读 变更控制 项目组所有人员需变更该库中的配置项，需按照变更控制流程严格执行。 发布库 用途 存放待发布，已发布的系统版本。 数据来源 基线库 权限 配置管理员：可读/可写 其他人员：可读 发布管理 (三)变更控制1.变更申请 当需要对基线或基线中的配置项修改时，变更申请人提交变更申请至CCB,变更申请工作内容包括： (1)描述变更的需求或来源，说明变更的必要性。 (2)分析需要变更的内容。 (3)说明变更来源： 1)需求变更：新增需求、需求变化、需求分析缺陷。 2)设计变更：设计缺陷。 3)上线系统代码变更：编码缺陷。2.变更评估 (1)变更申请提出以后，CCB评估该变更申请，变更决定的结果要求通知所有相关的人员。 (2)评估人员要求具备