北京雅龙汉正科技有限责任公司
项目管理标准
北京雅龙汉正科技有限公司
2008 年 1 月
更改履历
版本号 修改编号 更改时间
更改的
图表和章节
更改简要描述 更改人 批准人
注：更改人除形成初稿，以后每次修改在未批准确认前均需采用修订的方式进行修
改。
目 录
1. 概述........................................................................................................................................................4
. 编写目的 ........................................................................................................................................4
. 项目背景 ........................................................................................................................................5
. 建设目标 ........................................................................................................................................6
2. 项目计划管理........................................................................................................................................7
. WBS(工作分解结构)分解..............................................................................................................7
. 项目基线计划 ................................................................................................................................9
. 项目基线计划 ........................................................................................................................9
. 基线评审计划 ......................................................................................................................10
. 项目附属计划 ..............................................................................................................................11
. 沟通计划 ..............................................................................................................................11
. 风险管理计划 ......................................................................................................................12
. 配置管理计划 ......................................................................................................................19
. 质量保证计划 ......................................................................................................................30
. 项目阶段计划 ..............................................................................................................................34
. 项目实施采用的平台软件 ..........................................................................................................36
3. 项目实施作业标准..............................................................................................................................37
. 项目实施过程工作项 ..................................................................................................................37
. 项目实施作业标准 ......................................................................................................................39
. 项目启动阶段 ......................................................................................................................39
. 项目策划阶段 ......................................................................................................................46
. 项目开发阶段 ......................................................................................................................49
. 工程实施阶段 ......................................................................................................................51
4. 附件......................................................................................................................................................87
. 测试验收相关附件 ......................................................................................................................87
. 附件 1:《测试结果签字确认授权书》格式......................................................................87
. 附件 2:《最终验收意见》提纲..........................................................................................89
. 附件 3：测试准备工作确认表 ...........................................................................................91
. 附件 4：提交的最终验收材料签收表 ...............................................................................92
1. 概述
编制本计划的目的是用文件的形式，把对于在开发过程中各项工作的负责人员、
开发进度、所需软、硬件条件及可能遇到的问题瓶颈等问题作出的安排记载下来，以
便根据本计划开展和检查本项目的开发与实施工作。
2. 项目计划管理
. WBS(工作分解结构)分解
项目总体目标 2008 年 12 月 30 日完成基础业务系统推广、新建项目试点开发、实施
分类 一级任务 二级任务
设计原型框架
原型框架确认
原型开发
新建系统原型开发
原型确认
需求调研
需求整理(业务差异、实用化需求)
需求分析(差异需求报告)
需求确认(报送监控组审批)
需求调查
需求管理(纳入基线)
设计UE/UI框架
UE/UI框架确认
UE/UI开发
UE/UI设计
UE/UI确认
设计原则讨论
设计原则内部确认
系统总体设计
应用系统概要设计(用例规划设计)
数据库完善设计
应用系统详细设计(用例实现设计和实体类设计)
Activex控件设计
内部评审
系统设计
客户确认
编码和单元测试
代码抽查
软件集成
软件工程
系统实现
集成测试
编写用户手册
测试方案编写
测试计划编写
测试用例编写
测试环境准备(项目现场仿真环境)
执行系统功能测试
系统测试
压力测试
培训
数据移植准备
数据移植
试运行前测试
试点单位开始试运行
试运行
试点单位初步验收
试点单位上线试运行
试点结束
项目推广开始
项目推广单位培训
推广单位数据移植准备
推广单位数据移植
推广单位试运行前测试
推广单位开始试运行
推广单位试运行
项目单位推广阶段
推广结束
项目启动
项目策划
项目监控
项目结项
项目周报和下周计划
内部周例会
网省(自治区)周例会
项目管理 人力外包
项目支持 质量保证
. 项目基线计划
. 项目基线计划
基线产品 1 标设成果原型
基线产品 2 需求
基线产品 3 UE/UI设计
基线产品 4 系统设计
基线产品 5 产品
基线产品 6 文档
产品 任务名称
工期
（天）
开始时间 完成时间
设计原型框架 3
原型框架确认 2
原型开发 21
标 设 成
果原型
原型确认 1
需求调研 14
需求整理 1
需求分析 0
需求确认 1
需 求 调
查
需求管理 0
设计UE/UI 框架
UE/UI框架确认
UE/UI开发 10
UE/UI设
计
UE/UI确认 2
设计原则讨论 1
设计原则内部确认 1
系统总体设计 10
应用系统概要设计 15
数据库完善设计 20
应用系统详细设计 45
Activex控件设计 5
系 统 设
计
内部评审 5
配置管理
变更管理
培训
客户确认 5
系统实现 90
系统测试 20
产品
试点单位上线试运行 60
文档 输出文档 318
备注：
. 基线评审计划
. 基线评审时间计划
基线产品 计划评审时间 主要参加人员 方式
标设成果原型 项目主管、项目经理、质量保证员、项目组成员、
需求 项目主管、项目经理、质量保证员
UE/UI设计 项目主管、项目经理、质量保证员、项目组成员
系统设计 项目经理、质量保证员、项目组成员
产品 项目经理、质量保证员、项目组成员
文档 项目经理、质量保证员、项目组成员
. 基线评审报告模版
项目名称(编号) 会议室
审查日期 预期评审速率 分钟/页
开始时间 结束时间
工作产品信息
序号 名称 作者 版本 大小（页） 检查表 标准
1 有 没有
2
3
4
5
评审人员
检查准备时间（小时）
姓名 角色 缺席
1 2 3 4 5
是
是
相关文档
名称 版本 存档位置
. 项目附属计划
. 沟通计划
. 基于问题的沟通计划
问题类型 沟通对象 方式
需求变更 管理控制组、项目经理、项目主管、公司分管领导 变更委员会会议
总体计划变更 管理控制组、项目经理、项目主管、公司分管领导 会议
基线变更 管理控制组、项目主管、项目经理、配置管理组 变更委员会会议
人员变动 管理控制组、项目主管 书面
. 日常沟通计划
沟通对象 内容 方式 时间
管理控制组、项目组成员 项目进展及问题 周例会 每周
管理控制组、项目主管、公司分管
领导
项目进展及问题 月述职 每月
. 周例会工作计划
单体项目负责人 项目总负责人 报送周期
工作周报 每周五下午 10 点前
每周日中午 12 点前 一级/二级组成立开始，撤销
终止
项目实施经理 总体项目负责人 报送周期
项目日报 每天下午 10 点前 ——
项目启动会开始，合同签订
终止
项目周报 每周五下午 10 点前 每周一中午 12 点前
项目启动开始，项目终止结
束
项目月报 —— 每月最后 1 工作日中午 合同签订开始，项目终止结
12 点前 束
客户周报 每周五下午 10 点前 每周一中午 12 点前
项目启动开始，项目终止结
束
客户月报 ——
每月最后 1 工作日中午
12 点前
项目启动开始，项目终止结
束
. 与内蒙客户的沟通计划
. 时间表
编号 沟通内容 时间 方式
1 项目启动 2008 年 3 月 会议
2 项目整体计划 2008 年 3 月 文档
3 调研计划 2008 年 3 月 文档
4 需求评审 2008 年 4 月 会议
5 数据切换计划 2008 年 6 月 文档
6 系统上线计划 2008 年 9 月 文档
7 系统推广计划 2008 年 11 月 文档
8 系统验收计划 2009 年 10 月 会议
. 风险管理计划
风险管理贯穿与整个项目的全过程，具体的时间计划来源与项目实施的每个时间
点。
风险是一种遭受损失的可能性，这种损失的程度可能导致对项目的伤害直至失败。
风险管理的目的是在风险发生前，识别出潜在的问题，以便在产品或项目的生命周期
中规划风险处理活动，并在需要时启动，以减缓它们对目标的不利影响
. 定义
序号 定义 说明
1 风险
是一种潜在的事件或条件，一旦发生，将会给项目带来一定的负
面影响或导致项目失败。
2 风险管理 风险管理就是在一个项目中通过过程和工具来对风险进行识别,
跟踪和控制的手段。提供了对可能出现的风险进行持续评估，确
定重要的风险以及实施处理风险的策略的一种规范化的环境。合
理的风险管理应尽力减少风险的发生概率；如果发生，则应尽力
缩小其影响程度。
3 风险识别 是要对各个相关领域进行检查，以便发现风险并记录下来。
3 风险分析 是对每一项已识别的风险进行研究，以精确描述风险，分析出风
险产生的原因、概率并确定其产生的影响（成本、进度、技
术）。
4 风险参数 包括风险发生的概率、影响的严重程度，以及风险值；风险值是
概率和影响严重程度的乘积，以上具体参见《风险管理列表》
5 风险类别 按照风险可能导致的影响方面对风险进行的分类。如成本、进度、
质量。
6 问题管理 将已经转化成问题的风险记录到《项目问题管理表》
. 角色与职责
序号 角色 职 责 说明
1 项目经理 负责项目的风险管理计划、风险管理活动的实施和总结
2 项目组成员 在项目经理的带领下，参与风险管理活动
3 项目机构 参加评审风险值≥2 的风险的缓解措施
4 项目组 收集在风险管理活动中的经验教训。
. 流程图
一一一一一一一一
一一一一一一一一
一一一一
一一
一一一一一一、一一、
一一一、一一一一
一一一一一一
一一一一一一
一一一一一一
1一一一一一一
2一一一一一
3一一一一一
一一一一一一一一一一一一一一、一一一一一一一一一、一一一一一、一
一一一一一一一一一一一一一一。
一一一一一一
一
一
一
一
一一一一一
一一一一一
一一一一一
一一一一一/
一一一一一
一一一一一一
一一一一
一一一一一
一一一一
一一一一一一
一一 一一一一
一一
. 风险识别
一般性风险识别
编号 产品规模风险 具体风险描述 现状
分 析
值
风险趋
势后果
缓解
措施
应对
措施
识别
结果
A—01 没有充分估算产品的规模，导致估算的结果缺乏客观依据； 1
A－02
对于估算出的产品规模的不可信或可信度极底，导致规模估
算的结果的偏大或者偏小； 1
A—03
没有以程序、文件或事务处理的数目来估算产品规模，导致
规模估算的结果缺乏客观依据； 1
A－04
估算产品规模与以前产品的规模的平均值存在较大偏差，导
致估算结果可信度低； 0
A—05 产品创建或使用的数据库过大，导致估计的项目规模偏小； 0
A－06 产品的用户数过多，远远超过预期数，导致估计的规模过小； 0
A—07 产品的需求改变太多 ，导致估计的规模不准确； 0
A－08 没有考虑可重用构件的设计开发，导致估计的规模偏大 ； 0
编号 商业影响风险 现状
分 析
值
识 别 结
果
B－01 开发一个没有人真正需要的优秀产品或系统（市场风险）； 1
B－02 开发的产品不再符合公司的整体商业策略（策略风险）； 0
B－03 建造了一个销售部门不知道如何去卖的产品； 0
B－04
由于重点的转移或人员的变动而失去了高级管理层的支持
（管理风险）； 0
B－05 没有得到预算或人力上的保证（预算风险）。 0
B－06 交付期限不合理，导致不合理的开发计划； 0
B－07 政府对本产品开发的约束； 0
B－08 延迟交付所造成的成本消耗是多少； 0
B－09 本产品对公司的收入影响甚小；导致市场推广缺乏动力； 0
B－10 本项目是否有市场部门、产品规划部门的人员的参与； 0
B－11 项目是否受到了市场部门、产品规划部门的关注； 0
B－15 合作方的供货期、技术支持力度等方面存在不足
B－16 1
编号 客户相关风险 现状
分 析
值
识 别 结
果
C－01
没有和该客户合作的经历，导致在需求定义过程中与客户交
流时不顺畅； 1
C－02
客户不是很清楚需要什么、客户没有时间把需求写出来，导
致无法得到客户明确的需求意图； 0
C－03
客户不同意花时间召开正式的需求收集会议，以确定项目范
围，导致项目范围不符合客户实际的想法； 0
C－04
客户不愿意建立与开发者之间的快速通信渠道，导致在开发
过程存在的需求相关的问题无法及时得到客户的帮助； 0
C－05
客户不愿意参加复审工作，导致在项目早期不能发现和客户
的不一致； 0
C－06 客户不具有该产品领域的技术素养，导致提供的需求不准缺； 0
C－07
客户不愿意让项目组的人来做他们的工作，导致项目组无法
真实的体验用户的需求，对客户需求的理解不深刻； 0
C－08
客户不了解软件过程，导致对项目提出不现实的期望；
0
1
编号 过程风险 现状
分 析
值
识 别 结
果
管理过程风险
D－01
高级管理层没有一份已经写好的政策陈述（该陈述中强调了
软件开发标准过程的重要性），导致项目组对软件开发标准
过程的重要性认识不够； 1
D－02
开发组织没有拟定一份已经成文的、用于本项目开发的软件
过程的说明，导致项目组对软件过程定义不清楚，导致软件
过程混乱； 0
D－03
开发人员不同意按照文档所写的开发过程进行开发工作，并
自愿使用它，导致开发过程混乱； 0
D－04 开发过程不可以用于其它项目，导致？； 0
D－05
管理者和开发人员没有接受过一系列的软件工程培训，导致
项目开发过程无法得到良好理解和执行； 0
D－06
没有为每一个软件开发者和管理者提供及时可查询到的工
程标准，导致无法及时查阅标准； 0
D－07
没有为作为软件过程一部分而定义的所有交付物建立文档
概要及示例，导致开发人员无法有效和便利的使用； 0
D－08
没有定期对需求分析报告、设计和编码进行正式的技术复审，
导致所存在的问题没有及时发现，将问题带入到下一个阶段； 0
D－09 没有定期对测试过程和测试情况进行复审，导致； 0
D－10
是否对每一次正式技术复审的结果建立了文档，其中包括发
现的错误及使用的资源； 0
D－11 有什么机制来保证按照软件工程标准来指导工作； 0
D－12
是否使用配置管理来维护系统/软件需求、设计、编码、测试
用例之间的一致性； 0
D－13
是否使用一个机制来控制用户需求的变化及其对软件的影
响； 0
D－14
对于每一个承包出去的子合同，是否有一份文档化的工作说
明、一份软件需求规约和一份软件开发计划； 0
D－15
是否有一个可遵循的规程，来跟踪及复审子合同承包商的工
作； 0
1
技术过程风险
D－50
是否使用方便易用的规格说明技术来辅助客户与开发者之
间的通信； 1
D－51 是否使用特定的方法进行软件分析； 0
D－52 是否使用特定的方法进行数据和体系结构的设计； 0
D－53 是否 90％以上的代码都是使用高级语言编写的； 0
D－54 是否定义及使用特定的规则进行代码编写； 0
D－55 是否使用特定的方法进行测试用例的设计； 0
D－56
是否使用配置管理软件工具控制和跟踪软件过程中的变化
活动； 0
D－57 是否使用工具来创造软件原型； 0
D－58 是否使用软件工具来支持测试过程； 0
D－59 是否使用软件工具来支持文档的生成和管理； 0
D－60 是否收集所有软件项目的质量度量值； 0
D－61 是否收集所有软件项目的生产率度量值； 0
1
编号 技术风险 现状
分 析
值
识
别结果
E－01 该技术对于项目组而言是新的； 1
E－02 客户的需求是否需要创建新的算法或输入、输出技术； 0
E－03 待开发的软件是否需要使用新的或未经证实的硬件接口； 0
E－04
待开发的软件是否需要与开发商提供的未经证实的软件产
品接口； 0
E－05
待开发的软件是否需要与功能和性能均未在本领域得到证
实的数据库系统接口； 0
E－06 产品的需求是否要求采用特定的用户界面； 0
E－07
产品的需求中是否要求开发某些程序构件，这些构件与你的
公司以前开发的构件完全不同； 0
E－08 需求中是否要求采用新的分析、设计、测试方法； 0
E－09 需求中是否要求使用非传统的软件开发方法； 0
E－10 需求中是否有过分的对产品的性能约束； 0
E－11 客户能确定所要求的功能是可行的吗？ 0
1
编号 开发环境风险 现状
分 析
值
识 别 结
果
F－01 没有可用的项目管理工具，导致项目管理工作效率低下； 1
F－02 是否有可用的软件过程管理工具； 0
F－03 没有可用的分析及设计工具，导致分析和设计工作效率低下； 0
F－04 分析和设计工具不适用于待建造产品，导致分析和设计工作 0
无法进行；
F－05 是否有可用的编译器或代码生成器； 0
F－06 是否有可用的测试工具； 0
F－07 是否有可用的软件配置管理工具； 0
F－08 环境是否利用了数据库或数据仓库； 0
F－09 项目组的成员是否接受过每个所使用工具的培训； 0
F－10 是否有专家能够回答有关工具的问题; 0
F－11 工具的联机帮助及文档是否适当； 0
F－12 是否有可用的操作系统； 0
F－13 是否有可用的商用协议栈； 0
1
编号 人员数目及经验相关的风险 现状
分 析
值
识 别 结
果
G－01 是否有合适的人员可用； 是 1
G－02 人员在技术上是否配套； 0
G－03 是否有足够的人员可用； 0
G－04 开发人员是否能够自始至终地参加整个项目的工作； 0
G－05 项目中是否有一些人员只能部分时间工作； 0
G－06 开发人员对自己的工作是否有正确的期望； 0
G－07 开发人员是否接受过必要的培训； 0
G－08 开发人员的流动是否仍能保证工作的连续性； 0
1
项目特定风险识别
编号 项目特定风险 现状
分 析
值
识 别 结
果
H－01 进度计划安排紧张，没有合理的缓冲时间 0
H－02 任务分配可能存在不恰当的情况，有可能会影响进度 0
H－03
需求可能会发生变化，有可能会造成大量返工，从而影响
到项目的进度与质量 0
H－04 0
H－05 0
H－06 0
H－07 0
H－08 0
H－09 0
H－10 0
0
. 配置管理计划
. 配置项定义
. 配置管理工具
采用运行在Windows环境下的Microsoft Visual SourceSafe。按以下步骤搭建配置管理环境：
1. 服务器端的安装
2. 配置帐号
3. 客户端的安装与配置
4. 工具的具体操作
. 配置项标识
过程域 阶段 活动 交付物
需求分析 软件需求规格说明书
需求确认 需求评审报告
需求跟踪表
需求
需求管理
需求变更跟踪表
原型开发 系统原型
原型开发
原型确认
系统设计 系统设计说明书
数据库设计 数据库设计说明书系统设计
设计评审 设计评审报告
源代码
编码和单元测试
测试记录
代码抽查 问题跟踪表
软件集成 内测版本
测试记录
缺陷记录
系统实现
集成测试
测试报告
测试方案编写 测试方案
测试计划编写 测试计划
测试用例编写 测试用例
测试记录
缺陷记录
测试报告
系统测试
执行系统测试
交付版本
上线准备 上线计划及方案
系统上线
系统切换 上线报告
运行维护 运行维护记录
项目文档交付清单
项目成果集验收准备
试运行报告
软
件
工
程
类
试运行
提交验收申请
组织验收评审
验收确认 验收报告
下达项目确认书 项目确认书
项目任命 项目任命书
项目相关资料
项目资料移交
资料清单
项目启动
召开项目启动会议 会议纪要
项目过程定义 项目过程裁剪说明
项目估算 项目估算表
风险识别 风险管理计划
编制项目总体计划 项目总体计划
总体计划评审 计划评审报告
质量保证计划
编制辅助计划
配置管理计划
编制阶段计划 阶段计划
项目策划
编制周计划 周计划
问题跟踪 问题跟踪表
工作量跟踪 项目周报
风险跟踪 风险跟踪表
阶段总结 阶段总结报告
项目监控
周总结 项目周报
项目成果整理 项目成果
项目总结 项目总结报告
提交成果 项目成果交付清单
项
目
管
理
项目结项
结项确认 结项确认书
制定质量保证计划 质量保证计划
质量保证报告 质量保证活动阶段报告
评审问题跟踪 问题跟踪表
问题上报 问题上报单
需求管理检查表
需求活动检查表
系统设计检查表
系统测试检查表
系统上线检查表
验收检查表
项目计划检查表
项目监控检查表
里程碑检查表
质量保证
检查活动
结项检查表
制定配置管理计划 配置管理计划
跟踪配置状态 配置状态报告
配置审计 配置审计报告
配置项变更 变更申请与处理表
配置管理
产品发布
变更申请 变更申请与处理表
变更审批 变更申请与处理表
项
目
支
持
变更管理
变更实施 变更申请与处理表
变更验证 变更跟踪表
度量分析 度量分析报告
决策分析 决策分析报告
. 配置项命名规范
. 使用范围
适用于项目过程中编制的文档的命名。
程序源代码、目标代码、执行程序的文件编制参照相关编程语言的程序命名规范。
. 命名规则
1、 纳入基线前的命名规则：<SGCC>—<项目简称>—<文档名称>—<文
档时间信息>
2、 纳入基线的命名规则：<SGCC>—<项目简称>—<文档名称>—<版本
号>
. 文档时间信息
格式为YYYYMMDD。
在文档没有纳入基线前，要求对文档采纳时间信息。
. 版本定义
1、主版本号
设置时间：本项目中发布的文档产品通过正式评审及正式对外发布时，或未
发布前的初始化
设置人员：配置管理员；
设置规则：
1）新产品发布，主版本号为 1；
2）产品的主体构件进行重大修改，主版本号加 1；
3）产品的主体构件之间的接口协议修改，主版本号加；
4）主版本号变更时，副版本号同时置 0。
2、副版本号
设置时间：产品发布及版本更新时；
设置部门：配置管理员；
设置规则：
1）新产品发布，副版本号为 0；
2）对现有功能模块做重大修改，副版本号加 1；
3）改进现有功能模块，不增加新的功能模块，产品的主体构件未做重大修
改，副版本号加 1；
4）为增加产品功能，在原版本产品上增加新的功能模块，而产品的主体构
件未做重大修改，并且产品的主体构件之间的按口协议也未做修改，副版本号加
1；
5）当主版本号变更时，副版本号同时置 0。
3、版本编号说明
说明：V 是版本标识
X 是主版本号
Y 是副版本号
. 配置库目录结构
在本项目中采用VSS进行文档管理。
. 配置库结构说明
01 参考资料
配置库
02 开发库
03 基线库
04 产品库
01 客户资料
02 前期项目资料
04 其他
01 需求
02 原型开发
03 系统设计
04 系统实现
05 系统测试
06 上线/试运行
01 需求
01 软件产品
02 发布版本程序
03 文档
02 计划
03 设计
03 项目资源
04 测试
07 管理
一级目录名
称
二级目录名
称
三级目
录名称
存放内容 目录变更情况 权限
主要是项目组共同共享、
且是可以经常查询参考
的资料
只要有需要，该目
录下的下层目录
是可以添加的，提
出需求，统一由配
置管理员操作
项目组成
员都有读
的权限、
配置管理
员有添加、
删除和维
护的权限
01 客户资料 存放客户的联系信息，客
户提供的前期的原始资
料
02 前期项目
资料
售前的项目资料
03 项目资源 项目组公共性的资源，
将公共性的内容抽出来
放在这个路径下便于查
询
01 项目
通讯录
包括项目组、客户、监理、
厂商等通讯方式
02 文档
模板
所有项目的文档模板，下
面可以再分子目录
01 参考资料
04 其他 可以存放类别名称不好
定义的公共文档
02 开发库 工程类文档的公共开发
库
下面的子目录可
以根据生命周期
模型的阶段不同
进行调整
配置管理
员有目录
维护、读、
增、删的
权限
项目组都
有读、添
加、删除
文件的权
限
01 需求 需求阶段产生的成果性
文档
01 需求
调研
存放需求调研阶段相关
的资料，以及在需求分析
阶段对需求进行确认的
会议记录，包括有客户参
与的会议记录、评审会议
记录
02 需求
分析
需求分析阶段的成果性
文档，可以是阶段性的成
果，不一定是最终版本。
03 需求
管理
包括需求变更和需求跟
踪的文档
02 原型开发 原型
03 系统设计 存放设计阶段的成果性
文档，包括：数据库设计
说明书、系统设计说明书
等文档。
04 系统实现 安装手册，用户手册
05 系统测试 包括测试计划、测试用例
和测试报告
06 上线/试运
行
上线过程中的文档
07 管理 与项目有关的管理类文
档
03 基线库 操作和维
护权限都
是配置管
理员，其
他的人员
只有读权
限
01 需求 需求得到用户的确认，就
纳入基线管理；如果需求
发生很大的变更需要重
新建立基线，需要以基线
为标准进行跟踪
有配置管理员根
据基线计划进行
跟踪和入库管理
02 计划 经过用户评审并通过的
项目计划需要建立基线，
可以根据基线对项目进
行跟踪
基线都是可以变
更的
03 设计 用户确认后的应用系统
设计说明书
基线都是可以变
更的
04 测试 用户确认的测试计划和
相关文档
基线都是可以变
更的
配置管理
员具有所
有权限，
其他人只
有读权限
01 软件产品 软件发布的可安装软件
产品，发布后如果有大的
改动，再次发布时需要变
换版本号
配置管理员进行
出入库操作，其他
人要取必须提出
申请
02 发布版本
程序
发布版本的源代码 配置管理员进行
出入库操作，其他
人要取必须提出
申请
04 产品库
03 文档 发布时提交给用户的文
档，包括用户使用说明书
配置管理员进行
出入库操作，其他
人要取必须提出
申请
. 操作权限
整个配置管理库由参考资料、开发库、基线库、产品库共 4 个库组成。
参考资料：主要存放大家都经常查看的一些资料，比如客户的资料、项目组的一
些资料，该库的权限大家都有读的权限，但客户的资料和前期项目资料只有配置管理
员和核心组人员有其他一些处理权限。
开发库：存放开发过程中需要保留的各种信息，主要目的方便项目组成员个人使
用。库中的信息可能有较为频繁的修改，无需进行严格的控制。本项目中，各配置项
的责任人具有check in、check out和读权限，其他人员仅有读权限。还存放管理方面的
文档和质量保证员或配置管理员操作的一些支持工作方面的文档。主要操作者是项目
经理或项目核心组人员，其他人员都是可以查看的。如果根据需要项目组的某些人员
需要其他权限，可以先申请进行开通。
基线库：存放已定义的基线，基线必须进行严格的控制，由配置管理员负责管理
与维护。本项目中，配置管理员具有check in、check out和读权限，其他人员均只有读
权限。
产品库：存放需要交付给用户的且经过测试、评审的产品。也需要一定的控制，
由CM员负责管理与维护。本项目中，配置管理员具有check in、check out和读权限，
其他人员均只有读权限。
. 配置项管理活动
. 版本控制
采用开发主线的方式进行版本管理
无需修改的配置项（如部分记录、报告、总结等）
直接提交配置管理服务器相应模块下的工作目录内，由配置管理服务器自动管理
版本，配置项本身不必体现版本号的记录。
可能修改的配置项（大部分的成果性文档、提交客户的文档）
配置项本身必须体现版本号的记录；
对已提交配置管理服务器配置项的修改，必须先从配置管理服务器上检出该配
置项，对检出的配置项进行修改；
检出修改之前，必须先察看是否有人正在操作（修改）此配置项，有人操作时，
不准检出修改；
检出配置项修改后再次提交配置管理服务器时，版本按照前面的版本定义的规
定管理；
本地初次生成版本用时间信息控制；
检出版本 ，检出后本地修改版本用时间信息控制；
未提交配置管理服务器的配置项或文档、资料（即本地的文档及资料），按照
时间信息的方式管理版本；
提交配置管理服务器的配置项（即 vss 上的文档及资料），按照 的方式管
理版本。
. 基线管理
. 基线定义
序
号
基线名称 阶段 基线内容
基线生
成时间
批准人
审核人
（配置管
理员）
1 需求基线 需求阶段
《软件需求规格说明书》
原型
需求基
线评审
通过后
项目经理
配置管理
员
2 计划基线 计划阶段
《项目总体计划》
《进度计划》
《配置管理计划》
《质量保证计划》
计划评
通过审
后
项目经理
配置管理
员
3 设计基线 设计阶段
《应用系统设计说明书》
《数据库设计说明书》
设计基
线评审
通过后
项目经理
配置管理
员
4 测试基线 测试阶段
《测试用例》
《测试报告》
测试基
线评审
通过后
项目经理
配置管理
员
5
产品基线
（存放在产
品库）
上线阶段
软件产品
程序源码
《安装手册》
《用户手册》
用户验
收通过
后
项目经理
配置管理
员
. 配置项审计
配置项审计在配置管理中占很重要的位置，它是项目过程相关的配置项集合的审
查。根据审计内容和审计对象的不同可以把基线审计分为物理审计、功能审计，形成
基线审计报告:
物理审计：主要考察偏差，完整性检查、版本是否正确。参加人员：项目经
理、质量保证员、配置管理员。
功能审计：主要考察功能是否实现。参加人员：项目经理、质量保证员、配
置管理员、测试人员。
进行以下的审计：
审计形式 时间 审计内容 召集人 参与人员
物理审计 每两个月
进行配置检查，看配置内容是
否完整
质量保证员
项目经理、质量保
证员、配置管理员。
功能审计 上线前 考察功能是否实现 质量保证员
项目经理、质量保
证员、配置管理员、
测试人员。
. 配置项状态报告
受控库（基线库和产品库）配置项出入库填写《配置项状态报告》并通过邮件发布出入库通
知。
. 基线变更
参见《变更管理程序》
. 出入库控制
. 入库
受控库（基线库和产品库）配置项入库规程：
1、入库申请
申请人直接或通过邮件向配置管理员提交入库申请，经入库审查之后,由配置管理
员将配置项入库。
2、入库审查
配置管理员对配置项进行完整性、正确性的审查。
3、入库登记与通知
配置管理员执行入库操作，同时填写《配置项状态报告》，通过邮件发布入
库通知。
. 出库
受控库（基线库和产品库）配置项出库规程：
1、出库申请
申请人直接或通过邮件向配置管理员提交出库申请，经出库审查之后,由配置管理
员将配置项出库。
2、出库审查
配置管理员对配置项进行完整性、正确性的审查。
3、出库登记与通知
配置管理员执行出库操作，同时填写《配置项状态报告》，通过邮件发布出库通
知。
. 备份
本项目的配置管理备份方案：
1. 保持配置数据库的大小不超过 5G；
2. 备份频率：每月进行 VSS 库的完全备份，并将备份文件备份至文档服务器指
定目录。
3. 备份检查：不定期进行备份文件的文件恢复测试，确保备份文件的有效性。
. 质量保证计划
. 项目SQA参与的项目活动
项目实施阶段 SQA活动 项目工作产品 过程
计划阶段
项目过程、工作产
品检查;
项目周例会
《项目任务书》、《项目策划跟
踪记录表》、《项目定义软件过
程》、《项目WBS》、《项目开
发计划》、《项目沟通计划》、
《风险管理计划》、《成本控制
计划》、《培训计划》
策划过程
培训过程
同行评审过程
跟 踪 与 监 控 过
程
需求开发与管理阶
段
项目过程、工作产
品检查；
项目周例会
《用户需求调研报告》、《需求
调查表》、
《软件需求规格说明书》、《需
求评审记录、《用例同行评审记
录》
《里程碑评审报告》、《会议记
录》
需求管理过程
策划过程
培训过程
同行评审过程
跟 踪 与 监 控 过
程
SPE (测试)
系统设计阶段
项目过程、工作产
品检查；
项目周例会
《概要设计说明书》、《数据库
设计说明书》、《用户界面设计
说明书》、《详细设计说明书》、
《设计评审记录》、《里程碑评
审报告》、《会议记录》、《用
例同行评审记录》
需求管理过程
策划过程
培训过程
同行评审过程
跟 踪 与 监 控 过
程
SPE(设计、测试)
编码阶段
项目过程、工作产
品检查；
项目周例会
《技术攻关报告》、《软件实现
计划》、《代码审查报告》、《单
元测试计划》、《单元测试用
例》、《单元测试报告》
SPE(编码)
需求管理过程
计划过程
培训过程
同行评审过程
跟 踪 与 监 控 过
程
测试阶段
项目过程、工作产
品检查；
项目周例会
《测试计划(系统、集成)》、《测
试用例(系统、集成)》、、《测试
总结报告》、《BUG跟踪管理
表》、《会议记录》
SPE (测试)
需求管理过程
策划过程
培训过程
同行评审过程
跟 踪 与 监 控 过
程
软件发布
发布产品配置审
计
《软件产品发布审批表》、《项
目联系记录单》、《用户手册》、
《安装维护手册》
SCM过程
SQA过程
SPE (产品发布)
客户培训
过程、工作产品检
查
《培训计划》、《培训签到表》、
《培训考核表》、《培训总结报
告》
TP过程
试运行
过程、工作产品检
查
《试运行计划》、《试运行问题
管理表》、《BUG跟踪管理表》、
《试运行总结》
项目验收 工作产品检查
验收计划、测试大纲，验收测试
报告(草稿)，项目工作报告(草稿)，
验收报告(草稿)、客户验收测试报
告、验收报告
项目总结 工作产品检查 《项目总结报告》
日常记录 工作产品检查 《项目周报》、《数据采集表》
事件驱动
里程碑会议、配置
项发生变更
里程碑会议记录、需求变更分析
报告、需求变更记录表、配置项
变更申请单、配置项出入库单、
配置项变更记录表、配置项变更
通知、配置状态报告、SCM库备
份记录表
. SQA活动计划
质量保证人员的活动计划
活动 活动时机 输出
日常审核 不定期的进行 不一致问题一览表
事件驱动 按照开发计划、项目里程碑点 不一致问题一览表
定期审核 每周两次 不一致问题一览表
. 收集度量数据
项目实施过程 数据项 测量单位 收集时机 责任者
项目周期 日历周 项目结束 项目经理
各阶段周期 日历周 阶段结束 项目经理
工作量 人周 每周 项目成员
人员数 人 每周 项目经理
文档规模 页规模
代码规模 K
每阶段 项目经理
计划和跟踪
与计划相比进度延迟天数 天 每周 项目经理
需求变更请求次数 次 每 月 ／ 每 阶
段
项目经理需求管理
实施变更花费的工作量 人周 每 月 ／ 每 阶
段
项目经理
评审 被评审文档的规模 页 每次评审 项目经理
分类错误数 个
分类缺陷数 个
评审总工作量 人小时
修改错误花费的工作量 人小时
结束
不一致问题数 个
限期未解决的不一致问题数 个
质量保证
直接关闭数 个
每周
项 目 质 量 保
证人员
. 质量活动结果
该部分说明质量保证人员计划做成的质量活动文档
职责
文档
编写 阅读/审核者 备注
软件质量保证计划 项目SQA 项目经理、SQA经理
不一致问题一览表 项目SQA 项目经理、高级管理者
软件质量保证报告 项目SQA SQA经理、高级管理者
. 项目质量保证报告机制
该部分说明项目质量保证报告的对象、时机、频度和报告内容。
时机、频度
报告对象
定期 随时
提交的报告
项目经理 每周例会 遇重大不符合项时 不一致问题报告
高级管理者 每月例会（月报告）
遇重大不能解决的不
符合项时
项目组内不能解决的不一致
问题报告，项目质量保证报告
SQA经理 每月例会（月报告） 项目质量保证报告
. 质量保证计划表
任务号 项目阶段 检查产品 检查时间 负责人 工作量 备注
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
. 项目阶段计划
. 定义
序号 定义 说明
1 基线 已经过正式评审和认可，作为以后进一步开发的基础，并且只有
通过正式的更改控制规程才能进行更改的规格说明或产品。
2 项目 一项要求协同一致努力的任务．它关注开发和或维护一个具体的
产品。产品可以包括硬件、软件或其它成分。一般，一个项目有
其自己的投资、成本核算和交付时间表。
3 项目定义软件过程 对项目所用软件过程的可操作的定义。项目定义软件过程是一个
已很好特征化的和已理解的软件过程，用软件标准、规程、工具
和方法予以描述。通过剪裁组织的标准软件过程以适合项目的具
体特征的方法来制定它。也可参见组织的标准软件过程、有效过
程、和妥善定义的过程。
4 软件生命周期 从软件产品的设想开始到软件不再使用而结束的时间周期。
5 软件过程 有关开发和维护软件及其相关产品（例如：项目计划、设计文档、
代码、测试用例、用户手册等）的活动、方法、实践和变更的集
合。
6 剪裁 为更好地匹配过程要求或产品需求而修改过程、标准或规程。
. 角色与职责
序号 角色 职 责 说明
1 软件工程过程组 批准项目组定义的软件生命周期模型和项目软件
过程。
2 质量保证小组 SQA 在整个软件生命周期中，监督和检验软件过程与
标准的符合性以及软件产品生产规范的符合性。
3 机构领导 DM 提供对项目的承诺和支持，以及对项目的总体控
制。
4 项目经理 PM 对整个项目的总体业务负责；项目经理是指导、
控制、管理和调整项目进行构造软件或硬件/软件
系统工作的个人，项目经理是最终向顾客负责的
个人。
《WBS 分解表》
《项目估算表》
《项目基线计划》
5 客户经理 联系客户，与客户进行沟通和承诺。 《项目基线计划》
的《评审报告》
6 培训管理员 实施培训
7 项目核心组 由机构领导、项目经理、市场人员、技术专家组
成。
8 项目组成员 由业务分析师、系统分析师、程序员、测试员、
配置管理员、质量保证人员组成。
《项目阶段计划》
. 流程图
详细阶段计划参看附件《项目阶段计划表》
. 项目实施采用的平台软件
软件说明 软件名称
数据库 ORACLE10G
数据库开发工具 PL/SQL Developer7
建模 PowerDesigner 12
界面设计工具 AP\Viso\Word\EXCEL
一一一 一 一 一一一
一一一一一一
一一
一一一一WBS
一一一一一一
一
一一一一一一
一一一一、一一一一一
《一一一一一一一一》
《一一一一一一》
《WBS一一一》
一一一一、一一一一一一一
《一一一一一一》
一一
《一一一一》
一一一一、一一一一一
一一一一、一一一一一
一一一一一一
一一
一一一一一一
《一一一一一一》
一 《一一一一》
《一一一一一一一一一一一一》
《一一一一》
《一一一一一一》
《一一一一一一一》
《一一一一一一》
《一一一一一一》
一一一一一、一一一一一
一一一一一
一一一一、一一一一一
一一一一
一一一一、一一一一一、
一一一一一《一一一一一》
一一一一、一一一一一、
一一一一一
界面开发工具 Dreamweaver8
美工开发工具 PhotoShop 7
JAVA 开发工具 +++ WebLogic
业务逻辑开发工具
工作流 自研
单据控件 水晶报表
第三方接口开发工具 VC++\ delphi6
95598 客户端交互开发
工具
Macromedia Flash MX 2004
银联开发工具
源码管理工具 CVS
CVS 客户端版本
应用服务器 WebLogic92
缺陷工具 Bug 管理系统
软件性能测试工具 Load Runner
文档管理工具 Visual
3. 项目实施作业标准
. 项目实施过程工作项
. 项目启动阶段
1、 项目立项
2、 下达项目确认书
3、 项目任命
4、 项目资料移交
5、 组建核心团队
6、 召开项目启动会议
. 项目策划阶段
1、 项目过程定义
2、 工作任务分解
3、 风险识别
4、 计划项目进度
5、 明确项目组织机构和职责
6、 编制总体计划草案
7、 总体计划评审核
8、 总体计划调整并纳入基线
9、 编制辅助计划
10、 辅助计划确认
11、 编制阶段计划
12、 编制周计划
. 项目开发阶段
1、 原型开发
2、 需求调研（贯标）
3、 UE/UI设计
4、 系统设计
5、 接口设计
6、 系统实现
7、 系统单元测试
8、 系统集成测试
9、 系统功能测试
10、 系统压力测试
. 工程实施阶段
1、 工程实施启动与准备
2、 培训环境确认及准备
3、 培训
4、 系统运行环境确认
5、 系统环境测试（软件平台、硬件平台、网络）
6、 系统部署与数据加载测试
7、 试点单位系统切换
8、 试点单位验收
9、 推广
10、 验收
. 项目实施作业标准
. 项目启动阶段
. 项目立项
. 角色与职责
序号 角色 职 责 说明
1 立项申请人 负责《立项申请表》的编制和提交
2 机构领导 负责《立项申请表》、《立项评审报告》的审
阅和批准
3 财务部门 给予《项目合同号》
4 项目经理 负责制定开发项目实施方案和报价
5 销售人员 负责制定开发项目实施方案和报价
6 市场人员 负责市场调研、目标客户调研、竞争对手调研
7 项目核心组人员 责任进行可行性分析，立项评审，项目实施
. 流程图
. 步骤
. 进行可行性分析
编写报告的目的：
项目名称
项目
项目甲方 项目乙方
旧系统流程：
费用开支：
使用人员：
旧系统描述
主要问题和缺陷：
实现的功能（目标）：
新系统概述
对旧系统的主要改进之处：
一一
《一一一一一》
《一一一一一一一》
《一一一一》
《一一一》
一一一一一
一一一一
一一一一一一一
一一一一一
一一一一
一一一一一一
一一一一
一一一一
一一一一一
一一一一
一
一一一一
一一一一一一一
一一一一
一
一一一一
一一一一?
一一
一一
《一一一一一一》
一一一一
开发需要的条件：
投资概要：
收益预测：经济可行性
经济可行性结论： 行 否
新系统的技术要求：
现有技术能否达到要求：技术可行性
技术可行性结论： 行 否
法律、政策：
管理环境：社会环境可行性
社会环境可行性结论： 行 否
立即开发
等待某些条件成熟后再开发可行性结论
不开发
可行性研究中使用的依据文档列表：
编制人： 编制日期：
. 立项申请
详细参看立项目申请报告、可行性分析报告
. 立项评审
详细参看立项目评审报告
. 相关干系人
机构领导
项目经理
项目核心组
. 过程描述
(1)立项评审应按照如下过程进行：
机构领导负责召集成立立项评审组。立项评审组必须包括下列成员：项目经
理、技术骨干、市场人员、并指定评审组组长。
在评审之前，评审组成员应认真阅读《立项可行性分析报告》和《立项申请
表》，并且按照“立项评审检查表的条目进行检查，（《立项评审检查表》在
《立项评审报告中》）评审组成员在进行检查时，可以根据项目的实际情况
对检查的内容进行增加或删减。
机构领导召开立项评审会。
评审组通过讨论形成一致意见，由评审组组长负责填写《立项评审报告》并
签署意见。
《立项评审报告》需要上交机构领导做出最终裁决。
(2) 根据评审结果，项目组织以下后续行动：
批准立项，进入下一阶段。
拒绝立项，立项取消并解散项目核心组。
. 出口准则
立项评审组和机构领导均已在《立项评审报告》上签署意见
. 输出
《立项评审报告》
. 立项发布
. 入口准则
项目已批准立项
. 输入
《立项可行性分析报告》
《立项申请表》
《立项评审报告》
. 相关干系人
项目经理、商务部
. 过程描述
(1) 项目合同双方均已签字确认。
(2) 商务部经过合同确认，给予项目号。
. 出口准则
项目合同已签字确认
项目组获得项目号
. 输出
《项目合同》
. 下达项目确认书
依据内蒙古电力(集团)公司下达的最终项目确认书为标准
. 项目任命书
项目任命书
项目名称 项目号
项目类型 ■ 应用开发项目 □ 产品研发项目 □ 其他
客户名称
联 系 人 及 电
话
项目目标
为确保项目的顺利进行，特委任×××为项目经理
项目经理职责：
项目经理权限：
项目主管 签字/日期：
为确保项目的质量，特委任×××为本项目的 QA。
QA 的职责：
依据项目指导书检查项目工作的相符性。
与项目经理协商不符问题的解决，并跟踪到结束。
QA 的权限：
查阅项目所有的工作产品。
需要时，参加项目所有的评审会议。
负责人 签字/日期：
我已明确此次任务的目标，清楚担负的职责和权限，同意接受任务。
项目（包括子项目）经理 签字/日期：
QA 签字/日期：
部门总经理/副总经理 签字/日期：
. 组建核心团队
参见项目组织体系
. 召开项目启动会议
. 会议准备
1、 会议时间确定
2、 会议地点确定
3、 甲方参会人员
4、 乙方参会人员
5、 会议内容
. 会议内容要求
1、 项目的甲方组织体系
2、 项目的乙方组织体系
3、 项目的进度要求明确
4、 项目的时间计划表确认
5、 项目各个阶段双方的联络人确认
6、 项目各个阶段双方的分工确认
. 会议组织注意事项
1、 在会议召开前提前一个工作周通知甲方会议的相关内容。
2、 会议的后勤保证需要具体的方案。
. 项目启动会议纪要
会议名称 召集人
主持人 记录人
日 期 地 点
参加人员
会议主题
议 程:
会议内容：
序号 问题描述 责任人 跟踪人 承诺解决时间 目前状态
1
2
. 项目策划阶段
. 项目过程定义
依据项目工程定义模版，确认项目过程中的每一个步骤是否在本次项目中采用，
补充针对本次项目的特殊过程。
项目过程 过程活动 是否执行 生产工作产品 是否执行
《软件生命周期》建立项目软件过程
《项目软件过程》
初步分解WBS 《WBS分解表》
项目估算 《项目估算表》
建立项目基线计划 《项目基线计划》
评审项目基线计划 《评审报告》
《沟通计划》
《人力资源及软硬件资源计
划》
《培训计划》
《风险管理计划》
《度量与分析计划》
《配置管理计划》
制定项目附属计划
《质量保证计划》
制定项目阶段计划 《项目阶段计划》
项目计划(PP)
制定项目培训计划 《项目培训计划》
制定需求工程计划 《需求工程计划》
《需求调研问卷》调研产品需求
《需求调研记录》
《需求跟踪矩阵》开发产品需求
《产品需求规格说明书》
《评审报告》评审产品需求
《产品需求规格说明书》
《产品需求规格说明书》
需求工程(RE)
确认产品需求
客户确认说明
发布产品需求 《产品需求规格说明书》
《需求跟踪矩阵》管理需求变更
《产品需求规格说明书》
追溯需求 《需求跟踪矩阵》
制定系统设计计划 《系统设计开发计划》
编制软件架构设计说明书 《软件架构设计说明书》 内蒙标准
评审架构设计 《评审报告》 内蒙标准
《详细设计文档》编制详细设计
《数据库设计文档》 内蒙标准
系统分析与设计
(SAD)
评审详细设计 《评审报告》
制定编码实现计划 《编码实现计划》
实施编码 源程序
实施单元测试 通过测试的代码
评审代码 《评审报告》
编码实现(CD)
实施缺陷管理 缺陷记录
制定测试计划 《测试计划》
编写测试用例 《测试用例》
准备测试环境 《测试环境搭建报告》
《测试总结报告》执行测试
《缺陷记录》
《产品清单》
《用户使用手册》
《测试总结报告》
交付产品
《产品安装手册》
《客户验收报告》验收测试
《缺陷记录》
缺陷记录
测试过程(TP)
实施缺陷管理
《缺陷管理指南》
工程实施启动与确认 《启动报告》
《培训环境确认及准备》
实施培训
《培训记录》
《转换方案》
项目实施（PE）
数据转换
《转换程序测试报告》
《测试环境确认》
环境建设
《运行环境确认》
系统部署与数据加载测试 《测试报告》
《系统切换方案》
试点单位系统切换
《系统切换前确认》
试点单位验收 《系统验收报告》
系统推广 《推广方案》
系统验收 《系统验收报告》
《结项申请表》提交结项申请
项目过程资产
审批结项 《结项申请表》
结项总结 《结项总结报告》
结项目(PCP)
项目资产归档 《项目结项材料归档交接单》
项目周报 《项目周报》
项目例会 《会议纪要》
项目里程碑评审 《项目计划》
项目监控(PMC)
项目基线计划修改 《项目基线计划》
《风险管理计划》制定风险管理计划
风险管理列表
执行风险管理活动-识别 《风险管理列表》
执行风险管理活动-分析 《风险管理列表》
执行风险管理活动-制定缓
解计划
《风险管理列表》
执行风险管理活动-执行缓
解措施
《风险管理列表》
跟踪风险 《风险管理列表》
风险管理(RM)
编制项目风险总结报告 《项目风险总结报告》
指定配置管理员 《立项报告》
定义配置项与基线 《配置项列表》
建配置库及权限分配 《配置状态记录表》
制定配置管理计划 《配置管理计划》
发布基线 《基线发布信息》
记录配置状态 《配置状态记录表》
配置管理（CM）
控制变更 《变更日志》
配置审计 《配置审计报告》
编写质量保证计划 《质量保证计划》
《质量保证检查报告》检查过程和产品质量
《不一致问题报告》
过程与产品
质量保证
（PPQA）
跟踪与处理问题 《不一致问题报告》
制定项目度量计划 《度量与分析计划》
收集项目度量数据 《项目度量数据表》
度量与分析
（MA）
分析项目度量数据 《项目度量数据分析报告》
决策问题发起 《决策分析表》
建立评估标准及权重 《决策分析表》
识别可选解决方案 《决策分析表》
选择打分评估方法 《决策分析表》
评估可选的解决方案 《决策分析表》
选择解决方案 解决方案
决策分析与解决
（DAR）
总结经验教训 《决策分析与解决方案指南》
. 工作任务分解
参见《WBS分解》
. 风险识别
参见《风险管理计划》
. 计划项目进度
项目进度计划在以内蒙古电力(集团)公司招标书中要求的项目实施进度的框架之
内，细化的每周每人具体的工作细节、严格考核。
. 明确项目组织机构和职责
参见《项目组织体系》
. 项目开发阶段
. 原型开发
依据内蒙标设成果中的需求规格说明书等系列文档，使用Axure RP Pro工具，将
系统的基本功能点和辅助功能点可视化，形成系统交互原型。
. 需求调研
需求调研是在针对标准化设计成果的基础上，对实施的网省(自治区)公司从业务
需求、运行现状、原系统情况进行调研，得到项目实施的网省(自治区)公司的业务需
求与标准化设计成果的差异处，同时掌握现有系统的情况及运行情况，为下一步系统
实施做好准备工作。
需求调研计划编写
需求调研工作联系
需求调研会议举行
需求调研原型讲解
需求调研需求规格书讲解
需求调研需求差异了解
需求调研结果整理
需求调研报告
详细参见《调研标准计划书》
. UE/UI设计
在前期制作的系统交互原型的基础上，进行用户体验改进测试和UI设计工作。
. 系统设计
根据UE/UI设计成果、功能精细化设计文档、数据模型设计文档，IT架构设计文
档进行系统用例抽取设计、系统用例实现设计、实体类设计、测试用例设计等。
. 接口设计
根据内蒙一体化集成平台、内蒙功能精细化设计文档、已有系统现状进行与营销
系统相关的接口操作规范设计。
. 系统实现
根据系统设计和接口设计相关文档，进行具体的编码实现。
. 系统单元测试
根据系统测试用例设计文档对已经实现的系统进行单元测试。
. 系统集成测试
根据系统测试用例设计文档对已经实现的系统进行集成测试。
. 系统功能测试
根据系统测试用例设计文档对已经实现的系统进行功能测试。
. 系统压力测试
根据系统测试用例设计文档，使用LoadRuner对已经实现的系统进行压力测试。
. 工程实施阶段
. 工程实施启动与准备
. 实施前与甲方的沟通
实施团队进驻现场前与甲方良好的沟通，是实施工作的顺利开展前提条件，通过
进驻现场前的沟通为项目团队提供一个良好的工作环境与工作氛围，给项目实施工作
的开展带来有利的条件。
进驻现场前与甲方的沟通主要从以下几个方面：
1、 交流进驻现场的时间安排
通过与甲方的沟通，最终形成现场实施人员进驻现场的确定时间，最终形成确认
函，以便项目经理安排人员进驻现场工作。
2、 了解甲方项目实施到位情况
确认甲方的项目实施小组是否成立、是否满足现场实施人员进驻现场的条件。
3、 明确项目实施人员进驻现场的办公条件
明确项目实施团队进驻现场后需要的工作环境及需要甲方配合解决的办公设施。
4、 了解项目实施人员进驻现场的饮食居住条件
了解现场的饮食居住条件，以便项目经理提前安排进驻现场的项目实施人员的后
勤保障工作。
5、 提交项目实施人员的详细职务及分工表
提交项目的实施人员详细的职务、联系方式及分工，以便甲方能提前确定对应的
配合人员。
6、 了解甲方项目实施人员的联系方式
获取甲方项目实施人员的详细职务、联系方式及分工，以便能提前确定对应的配
合人员。
. 实施团队进驻现场
项目实施团队合理的进驻现场，对树立项目团队的管理形象是关键的一个环节，
是整个项目实施的一个良好开端，因此采取何种方式进驻现场应该有严格的管理，项
目团队进驻现场主要从以下几个方面进行考虑。
第一：进驻现场的批次管理
第二：每个批次进驻现场的人员组成管理
第三：每个批次进驻现场的时间管理
第四：每个批次进驻现场的相关事务管理
. 项目团队进驻现场的批次
综合考虑本次项目实施的特点，项目团队进驻现场的分三个批次：
第一批次由项目经理带队，进驻现场的目的为确认现场工作环境、生活环境、搭
建系统测试环境，准备培训环境；同时与甲方领导层进行沟通，对项目实施的计划与
方案达成共识。
第二批次由培训组长带队，进驻现场开始准备数据切割、上线工作等。
第三批次由业务问题诊断负责人带队，对现场处理的业务问题进行确认形成需求
变更，同时对现场实施后出现的问题纳入问题管理业务流程进行管理。
. 每批次进驻现场的人员组成
第一批次：项目经理、系统集成工程师、技术支持工程师、业务支持工程师、培
训工程师。
第二批次：培训组长、系统实施工程师。
第三批次：现场问题接收、反馈人员；业务问题诊断人员。
. 每个批次进驻现场的时间
第一批次：进驻现场时间点为现场环境具备、甲方配合项目实施小组组建完成、
完成系统建设上钱前的外围准备工作。
第二批次：现场外围建设已经完成，进驻现场完成上线前的所有准备工作，预计
时间为xxxx年xx月中旬
第三批次：系统切换前，协助系统上线及上线后的问题收集、整理确认。
. 每个批次进驻现场的相关事务
每个批次进驻现场前需要准备的和落实的事情繁多，必须按照规定的条款逐一落
实到位的情况下才可以进驻现场，否则会使项目从一开始就处理混乱的状态，每个批
次进驻现场前需要落实的事情如下：
项目团队进驻现场前情况核实表
进驻批次 预计出发时间 本批次带队人及
带队人联系电话
与甲方是
否沟通
与项目经理是
否沟通
出差安排是否
通知到每个队员
所乘交通
工具
定票是否有保
障
出差费用是否预
借
本次进驻
总人数量
28 人 现场办公环境
是否满足
后勤保障是否到
位
第一批次可以不考虑
目的地 要去的城
市
现场联系人及
联系方式
预计行程时间
及到达时间点
从公司出
发模式
集体/个人 上车前集合时
间及地点
从目的地到办公
地点如何到达
确认后确定的出发时间
成员情况登记
序号 姓名 性别 联系电话 需要携带的物品 车票位置号
1
2
3
4
5
6
7
8
9
（最终的确认表每个项目组成员每人一份）
. 召开工程实施启动会议
会议按照标准组织形式进行组织，但结合本项目在工程实施会议中需要从以下几
个方面进行准备与考虑。
. 会议准备
会议时间确定
会议地点确定
甲方参会人员
乙方参会人员
会议内容
. 会议内容要求
甲方工程实施管理体系明确
乙方工程实施管理体系明确
工程实施详细进度计划安排
工程实施每项工作双方分工及责任人
工程实施每阶段双方的联络人确认
. 会议组织注意事项
工程实施的会议的后勤保证需要具体的方案
. 可预期准备工作
在工程实施过程中，系统建设工作小组应根据项目整体计划安排，充分利用项目
的各种资源，适时的、合理的组织实施可预期（或提前）完成的工作，提高工程实施
效率，缩短工期，降低项目成本。根据考察或借鉴兄弟单位的系统建设经验，一般可
提前实施的工作有：机房场地装修、设备购置、各种票据印刷、银联方案等单项工程。
. 机房场地建设
机房建设应根据《GB50174-93 计算机机房设计规范》、《GB/T2887-89 计算机
场地技术条件》、《GA/T75-94 安全防范系统工程程序与要求》等技术要求进行，按
照先规范、后设计，先审查、后招标的流程进行，主要事务如下：
（一）场地选择
一般配置中心机房、UPS电源房、座席值班室、会议或接待室、值班人员休息室
等，根据实际情况由系统建设单位（电业局）决定。
（二）场地环境需求
由系统集成商提供有关总需求，如：主要设备布置、场地大小、座席多少、电源
分布情况、电源与通信线路要求、预埋件、空气湿度、温度要求等。设备厂家提供自
身设备尺寸、重量、分布要求、运行环境要求、相关设备要求等。
（三）场地装修
场地装修工作分三步完成，第一步由系统建设单位根据场地环境需求、资质审查
进行议标或招标，选择场地装修单位，签订装修合同。第二步由系统建设单位提出场
地建设要求、企业形象设计资料（标志图、文字等）等，由装修单位进行详细设计，
并提供设计施工图、效果图、材料图等，交系统建设单位审核，根据审核意见修改并
通过。第三步按照合同要求进行场地装修，并按规定时间完成并组织验收。
. 设备购置与安装
系统是运行在软、硬件平台上的应用系统，因此，在项目建设初期系统建设工作
小组应及时组织或主持完成：软、硬件平台采购、到货验收、安装调试等工作。
（一）软、硬件平台采购
按照有关建设规范，对于全统一采购的软硬件平台，系统建设工作小组应根据系
统建设的总体进度按排，确定软硬件采购计划、招标合同（要求保留合同正本 1 份、
副本 1 份）、到位日期等事项，确保系统建设按照计划进行。
（二）软、硬件平台到货验收
软硬件采购订立以后，由系统建设单位和系统集成商按照合同进行到货验收，主
要软硬件平台包括：数据库、中间件、操作系统、网页同步浏览控件、短信服务软件、
小型机、应用服务器等。验收时应进行厂家、型号、规格、技术资料等几个方面的确
认签字。
（三）软、硬件平台安装调试
根据系统建设进度，工作小组应及时督办系统集成商和有关厂家按照国家标准、
行业规范等进行现场软硬件的安装、调试，系统建设单位应监督安装调试质量，并确
保按规定时间完成合同标的。
. 票据印制
在系统运用过程中，将使用全统一的票据格式，如发票、抄表卡等，但由于票据
印刷需经过有关部门（如税务部门）审查、印刷厂排版、印刷、分发、领用等多个环
节，事务多，协调量大，时间长，因此，系统建设工作小组应提前协商财务部门或其
它单位，在系统测试前完成有关工作，以备银行、基层用电单位领用。
. 银联系统前期工作
银行联网是系统重要组成部分，涉及到多加银行，同时每家银行都存在商务协议、
技术方案、业务需求、通道与路由等事务，系统建设工作小组应提前准备并完成如下
主要工作：
(一)银行联网商务协议
1.编制商务协议
由系统建设单位草拟银行联网协议，组织联网银行有关人员进行第一次磋商，并
进行修改完善，形成正式商务协议。
2.签订商务协议
由系统建设单位领导同联网银行领导签订商务协议。
（二）银行联网技术方案
1.编写技术方案
由系统建设单位提供原银行联网技术资料，系统集成商连同系统开发商进行银行
联网现场调研，然后编写技术方案（主要内容包括联网平台（中间件）、数据交换方
式等）、网络方案（主要内容包括通道、路由设备型号、防火墙等）。
2.技术方案讨论
系统建设单位联系联网银行、系统集成商、系统开发商、信息部门、通信部门进
行技术方案讨论，并形成书面结论。
（三）通道与路由建设
1.落实资金
系统建设单位的有关部门进行资金预算，并编制书面资金使用报告，交领导审批。
2.工程实施
根据网络方案，由系统建设单位组织有关部门和联网银行进行现场施工，调试。
为确保工程进度和质量，工程完工以后，由系统建设单位组织验收，形成书面的
工程竣工报告，由联网银行和建设部门签字。
（四）银行联网业务需求
1.系统业务需求
由系统建设单位编写银行联网业务流程、处理标准、票据表单格式等，并组织系
统开发商、联网银行技术人员开会讨论。
2.系统概要设计
由系统开发商编写银行联网系统概要设计说明书，并提供给银行软件开发人员以便进
行银行内部程序开发
. 现有系统厂家联系
现有系统厂家联系主要是为下一步的数据移植工作的开展做好准备。
. 培训环境确认及准备
. 培训计划确认
在系统上线前的操作培训时间的选择是需要综合考虑的一个因素，培训早了到系
统上线前操作方法基本全部忘记，培训晚了没有时间进行测试环境下的演练，合理的
时间计划是提高培训效果的影响因素之一，我院在多年的项目实施培训中总结出最佳
培训时间点选择的原则：
1、 专业培训的时间必须在本专业一个月业务最少的时间段内进行：每个专业人
员在系统上线前都有当月的考核任务与需要及时处理的任务，如果不在业务
最少的时间段培训，势必在培训过程中培训人员不能专心的进行培训。
2、 服务性业务（直接面对客户的岗位）的培训时间在系统切换前两个星期进行，
大概用一个星期的时间人员轮流培训，一个星期的时间轮流在测试环境进行
模拟操作，这样在系统上线后马上能进行操作。
3、 批量集中业务（比如抄表、核算业务）在系统上线前一个礼拜培训，因为这
样的业务在每月集中几天内需要马上完成，但是从系统操作上都比较简单，
集中在上线前一个礼拜培训、模拟操作强化培训，培训结束最好第二天就开
始使用新的系统效果最好。
4、 综合性岗位培训时间最靠前，因为综合新岗位涉及到系统操作的界面多，要
在短时间内想让培训人员全部了解，可以放在最前面培训，培训结束后在后
续的培训中综合性岗位的人员如果有时间也可以参与到后续的培训中，加深
对系统的了解。
当然操作性培训时间计划的制定必须考虑现场的具体环境，在条件允许的情况下
可以进行多次培训，争取能达到培训结束后每个岗位至少有 1 名人员对本岗位的操作
熟练掌握，这样在岗位内可以进行自助培训。
培训性质 领导层培训
开始时间 结束时间
序号 参加人员名单 职务 所属部门
1
2
3
4
培训性质 系统操作人员培训训
开始时间 结束时间
序号 参加人员名单 职务 所属地市局
1
2
3
4
5
培训性质 系统管理人员培训
开始时间 结束时间
序号 参加人员名单 职务 所属于地市局
1
2
3
4
5
6
7
8
9
. 培训环境确认
培训环境是为了让培训人员能实际模拟操作所需要；实际模式操作是培训中把听
到的操作方法自己动手实际执行的过程，在系统上线后的每个业务都是由不同专业的
操作人员实际操作完成，一般听到的和实际操作是有很大的差别的，授课人员是对系
统的操作异常熟练的情况下进行讲课，因此在授课讲解的操作中可能有许多的操作细
节不是很突出，只有第一次操作系统的人员实际的操作一次，才知道哪里学会了哪里
没有学会
服务器部分
序号 产品名称 配置 数量 备注
1
数据库服务
器
UNIX服务器：
1. 4CPU(核心)以上；
2. 8G内存以上；
3. 2 个内置 15K RPM 146GB的热插拔硬盘，
RAID1；
4. 4 块千兆网卡；
5. 2 块 4GB光纤通道卡；
6. Unix操作系统；
7. HA集群软件；
4 开发、测试各两台
2 应用服务器
UNIX服务器：
1. 4CPU(核心)以上；
2. 8G或 16G；
3. 2 个内置 15K RPM 146GB的热插拔硬盘，
RAID1；
4. 2 块千兆网卡；
5. Unix操作系统；
4
3 文件服务器
PC服务器：
1. 2CPU(核心) 以上；
2. 4G内存以上；
3. 2 个内置 15K RPM 146GB的热插拔硬盘，
RAID1；
4. 2 块千兆网卡；
5. WINDOWS操作系统；
2
4
项目管理及
发布服务器
PC服务器：
1. 2CPU(核心) 以上；
2. 4G内存以上；
3. 2 个内置 15K RPM 146GB的热插拔硬盘，
RAID1；
4. 2 块千兆网卡；
5. WINDOWS操作系统；
1
5 客户端 PC机xx台，软件环境WINDOWSXP
6 投影仪 1
7 多媒体教室 具有多功能设备的教室，可容纳 100 人
. 培训实施
对系统操作人员的培训主要目的让每一个岗位的每个人员明白本岗位应该处理的
业务及处理业务的流程和操作方式，确保系统操作人员的培训质量是确保系统正常上
线的前提条件，是减少现场实施人员工作量的一个主要因素。因此对系统操作人员的
培训必须按照计划严格进行，任何一个环节都不能忽视。
在培训计划确认，培训环境确认完，可以组织培训的实施，首先进行培训通知的
下发，由甲方完成。
. 培训签到及教材领取
培训性质
培训地方
培训时间 从 到
序号 姓名 单位 资料领取确认 签到时间
1
2
3
. 培训现场记录
项目名称： 培训地点
受培训人签名：
培训时间 至
培训内容 掌握情况
1、业务受理 □熟练 □一般 □较差
2、业务流程 □熟练 □一般 □较差
3、工程管理 □熟练 □一般 □较差
业扩报装
… □熟练 □一般 □较差
1、表库资产 □熟练 □一般 □较差
2、校验检修 □熟练 □一般 □较差
3、外校记录 □熟练 □一般 □较差
电能计量
… □熟练 □一般 □较差
1、业务管理 □熟练 □一般 □较差
2、抄表管理 □熟练 □一般 □较差
3、应收管理 □熟练 □一般 □较差
电量电费
… □熟练 □一般 □较差
… … …
培训技能 □满意 □一般 □不满意对培训工程师
的评价 工作态度 □满意 □一般 □不满意
备注说明
. 培训评价
项目名称 培训时间 至
培训地点 培训方式 □集中□零散
培训反馈人 反馈时间
反馈内容 反馈结果 备注说明
课程内容安排 □ 合理 □一般 □不合理
课程时间安排 □ 合理 □一般 □不合理
授课方式 □ 合理 □一般 □不合理
讲师授课能力与授课技巧 □很好 □一般 □较差
培训效果 □很好 □一般 □较差
培训保障方面 □满意 □一般 □不满意
教材编写质量 □很好 □一般 □较差
是否很好地回答学员的提问 □很好 □一般 □较差
讲课内容是否丰富，吸引人 □很好 □一般 □较差
所讲内容是否切题 □很好 □一般 □较差
讲解内容掌握得深、理解得透 □很好 □一般 □较差
是否鼓励学员参与课堂教学 □很好 □一般 □较差
整体上对课程的满意程度是 □满意 □一般 □不满意
您个人学习掌握情况反馈
培训内容 个人掌握情况 备注说明
业扩报装 □熟练掌握 □一般 □较差
电能计量 □熟练掌握 □一般 □较差
电量电费 □熟练掌握 □一般 □较差
… …
您的其他
意见或建议
. 培训结论
培训主题 培训开始时间
组织单位
培训单位
培训情况
达到了预期的目的
未达到预期的目的
培训结论
组织单位
负责人
签字
培训单位
培训人员
签字
备注 培训结束时间
. 系统运行环境确认
. 网省(自治区)本部硬件到位情况确认
服务器部分
序号 产品名称 配置 数量 确认结果 是否到位
1
生产数据库
服务器
UNIX服务器：
1. 4CPU(核心)以上；
2. 16G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 4 块千兆网卡；
5. 2 块 4GB光纤通道卡；
6. Unix操作系统；
7. HA集群软件；
2
2
历史数据库
服务器
UNIX服务器：
1. 2CPU(核心) 以上；
2. 8G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 4 块千兆网卡；
5. 2 块 4GB光纤通道卡；
6. Unix操作系统；
7. HA集群软件；
1
3 应用服务器
UNIX服务器：
1. 4CPU(核心)以上；
2. 8G或 16G；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. Unix操作系统；
4
4
银电联网前
置机
UNIX服务器：
1. 2CPU(核心) 以上；
2. 4G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. Unix操作系统；
2
5
电能信息采
集前置机
UNIX服务器：
1. 2CPU(核心) 以上；
2. 4G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. Unix操作系统；
2
6 文件服务器
PC服务器：
1. 2CPU(核心) 以上；
2. 4G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. WINDOWS操作系统；
2
7
视频管理服
务器
PC服务器：
1. 2CPU(核心) 以上；
2. 4G内存以上；
3. 2 个内置 15K RPM 146GB
1
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. WINDOWS操作系统；
8
对 外 网 站
WEB服务器
UNIX服务器：
1. 2CPU(核心) 以上；
2. 4G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. Unix操作系统；
1
9
对外网站应
用服务器
UNIX服务器：
1. 2CPU(核心) 以上；
2. 4G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. Unix操作系统；
1
10
项目管理及
发布服务器
PC服务器：
1. 2CPU(核心) 以上；
2. 4G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. WINDOWS操作系统；
1
11 开发服务器
UNIX服务器：
1. 2CPU(核心) 以上；
2. 4G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. Unix操作系统；
2
12 测试服务器
UNIX服务器：
1. 4CPU(核心) 以上；
内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. Unix操作系统；
2
13 负载均衡器
最大并发会话数：>=1,000,000
SSL支持：内置SSL芯片加速
(可选)
高可用：支持双机热备，双机
切换时间少于 200ms
2
14
备份管理服
务器
UNIX服务器：
1. 2CPU(核心) 以上；
2. 4G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. Unix操作系统；
1
15 CTI服务器
UNIX服务器：
1. 2CPU(核心) 以上；
2. 4G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 4 块千兆网卡；
5. 2 块 4GB光纤通道卡；
6. Unix操作系统；
7. HA集群软件；
2 台
16
短信接口服
务器
PC服务器：
1. 2CPU(核心) 以上；
2. 4G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. WINDOWS操作系统；
1
存储部分
序号 产品名称 配置 数量 确认结果 是否到位
1
SAN磁盘阵
列
1. 需求裸容量≥4T；
2. 控制器数量≥2 个；
3. 存储缓存容量≥4G，后备电
池≥2 小时；
4. 每个控制器至少配置 2 个
光纤通道；
5. 冗余风扇、电源等；
1
2 SAN交换机 16 端口以上光纤交换机 2
3 磁带库
1. 配置容量（非压缩）≥2TB；
2. 驱动器数量≥2，驱动器类
型LTO-4；
3. 槽数（不包括清洁磁带位
置）≥10；
4. 提供与SAN网络联接的光
纤控制端口；
1
容灾部分
序号 产品名称 配置 数量 确认结果 是否到位
1
异地容灾存
储
1. 需求裸容量≥4T；
2. 控制器数量≥2 个；
3. 存储缓存容量≥4G，后备电
池≥2 小时；
4. 每个控制器至少配置 2 个
光纤通道；
5. 冗余风扇、电源等；
1 套
2
数据库服务
器
UNIX服务器：
1. 4CPU(核心)以上；
2. 16G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 4 块千兆网卡；
5. 2 块 4GB光纤通道卡；
6. Unix操作系统；
7. HA集群软件；
2 台
3 应用服务器
UNIX服务器：
1. 4CPU(核心)以上；
2. 8G或 16G；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. Unix操作系统；
2 台
4
银电联网前
置机
UNIX服务器：
1. 2CPU(核心) 以上；
2. 4G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. Unix操作系统；
2 台
95598 接入部分
序号 产品名称 配置 数量 确认结果 是否到位
1 95598 呼 叫 1. 支持 7 号信令、中国 1 号 1 套
接入设备 信令、信令、ISDN、模
拟用户接口等；
2. 主处理器应采用 32 位或
32 位以上的CPU；
3. 支持ACD功能；
4. 交换机主控部分应为双备
份，可在不中断通信的情况下
实现主备倒换；
5. 提 供
1B+D/2B+D,NB+D,30B+D,普
通电话等多种座席语音、数据
通信方式；
2
交互式语言
应答设备
1. 采用E1、LineSide E1 接口
方式；
2. 支持图形化流程定制；
3. 支持各种交换机集成，如
avaya、Simens、Nortel、Alcaltel
等；
4. 支持与CTI中间件的集成，
如 Gensys 、 Quintus 、
CTConnect等；
5. 可通过中间件或接口实现
与数据库或者其他应用的访
问；
6. 支持多种转接功能，包括
IVR到人工坐席的转接、坐席
到IVR的转接；
7. 支持文本转语音（TTS）语
音播放；
1 套
3 传真设备
1. 提供在线/离线方式的传真
接收和传真发送功能；
2. 支持模拟及数字方式的传
真接口；
1 套
3. 支持多种传真应用，例如，
在线传真、传真回复、传真接
收等；
4. 支持多路传真的并发，允
许不同的传真处理应用同时
执行；
5. 可记录传真日志；
4 录音设备
1. 支持模拟方式和数字方式
（E1/T1）的接口；
2. 支持对远程座席的录音，
包括VOIP远程座席方式；
3. 支持的录音通道容量根据
座席数量确定；
4. 支持多通道同时录音；
5. 支持不同格式的录音文件
存储方式（如.wav）；
6. 支持B/S的录音检索和录音
播放功能，可提供如工号、姓
名、主叫/被叫号码、日期、
时间、通话时长等参数进行录
音检索；
7. 提供API调用接口供第三方
应用能够对录音进行控制；
1 套
. 地市供电局硬件到位情况确认
95598 接入部分
序号 产品名称 配置 数量 确认结果 是否到位
1
95598 呼叫
接入设备
1. 支持 7 号信令、中国 1 号
信令、信令、ISDN、模
拟用户接口等；
2. 主处理器应采用 32 位或
32 位以上的CPU；
3. 支持ACD功能；
4. 交换机主控部分应为双备
份，可在不中断通信的情况下
实现主备倒换；
1 套
5. 提 供
1B+D/2B+D,NB+D,30B+D,普
通电话等多种座席语音、数据
通信方式；
2 CTI服务器
PC服务器：
1. 2CPU(核心) 以上 2.
4G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. 2 块 4GB光纤通道卡；
6. Unix/WINDOWS操作系统
7. HA集群软件
2 台
3
交互式语言
应答设备
1. 采用E1、LineSide E1 接口
方式；
2. 支持图形化流程定制；
3. 支持各种交换机集成，如
avaya、Simens、Nortel、Alcaltel
等；
4. 支持与CTI中间件的集成，
如 Gensys 、 Quintus 、
CTConnect等；
5. 可通过中间件或接口实现
与数据库或者其他应用的访
问；
6. 支持多种转接功能，包括
IVR到人工坐席的转接、坐席
到IVR的转接；
7. 支持文本转语音（TTS）语
音播放；
1 套
4 传真设备
1. 提供在线/离线方式的传真
接收和传真发送功能；
2. 支持模拟及数字方式的传
真接口；
3. 支持多种传真应用，例如，
在线传真、传真回复、传真接
收等；
4. 支持多路传真的并发，允
许不同的传真处理应用同时
执行；
5. 可记录传真日志；
1 套
5 录音设备
1. 支持模拟方式和数字方式
（E1/T1）的接口；
2. 支持对远程座席的录音，
包括VOIP远程座席方式；
3. 支持的录音通道容量根据
座席数量确定；
4. 支持多通道同时录音；
5. 支持不同格式的录音文件
存储方式（如.wav）；
1 套
6. 支持B/S的录音检索和录音
播放功能，可提供如工号、姓
名、主叫/被叫号码、日期、
时间、通话时长等参数进行录
音检索；
7. 提供API调用接口供第三方
应用能够对录音进行控制；
6
短信接口服
务器
PC服务器：
1. 2CPU(核心) 以上；
2. 4G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. WINDOWS操作系统；
1
电能信息采集部分
序号 产品名称 配置 数量 确认结果 是否到位
1
电能信息采
集前置机
PC服务器：
1. 2CPU(核心) 以上；
2. 4G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. WINDOWS操作系统；
2
文档存储部分
序号 产品名称 配置 数量 确认结果 是否到位
1 文件服务器
PC服务器：
1. 2CPU(核心) 以上；
2. 4G内存以上；
3. 2 个内置 15K RPM 146GB
的热插拔硬盘，RAID1；
4. 2 块千兆网卡；
5. WINDOWS操作系统；
2
. 软件到位置情况确认
序号 产品名称 配置 数量 确认结果 是否到位
1 数据库 Oracle Database
Enterprise
18cpu
2 应用中间件 Weblogic server
premium edition
24cpu
3 交易中间件 Tuxedo 400 用户
4 消息中间件
5 CTI 7 套
6 TTS 7 套
7 IVR 7 套
8 报表工具 Cognos ReportNet 一套
9 工作流 Sotower BPM 一套
10 系统监控 满 足 标 准 化 设 计 要
求
一套
11 绘图工具 满 足 标 准 化 设 计 要
求
一套
12 复制软件 满 足 标 准 化 设 计 要
求
一套
13 备份软件 满 足 标 准 化 设 计 要
求
一套
. 试点单位系统切换
. 试点切换工作小组确认
实施地市 实施方 原系统供应商 银行 外围厂家 分工
组长 负责总协调
副组长 负责各单位工作协调
工作成员 负责具体工作实施开展
. 系统割接工作小组及联系方式确认
负责人 联系电话 工作人员 联系电话
总指挥
营销部
实施地市
计量所
客户发展中心
计财部
信息中心
调度所
实施方
第三方
. 准备工作确认
序号 内容 工作要求 计划时间
完成标志
完成时间
责任单位 责任人
部署会议
1 上线整体部署会 安排上线前准备工作 营销部及相关各单位
2
系统割接准备会 确认准备工作情况，安排切割
期间工作
营销部及相关各单位
系统上线前必须完成的工作
基础平台
1
网络（主备通道） 主通道
有备用通道，具备自动切换功
能
信息中心、调度所
2 机房 符合省(自治区)公司要求 信息中心
3
服务器、平台软件 各服务器和平台软件安装正
确，运行可靠
信息中心、实施方
4 应用程序 功能完善，为最新版本 实施方
数据清理确认
1 基本数据核对完成 基础数据正确 实施地市、实施方、计量所
2 电费核算完成 电费计算正确 实施地市、实施方
3
欠费数据核对完成 欠费数据正确，明细和总数一
致
实施地市
4
基本信息维护（详细见附件）
维护到位
营销部、客户发展中心、实
施地市、计量所
5
欠费数据转换测试
完成测试
实施方、原系统供应商、实
施地市
培训工作
1
完成培训
所有模块和人员都培训到位
实施方、实施地市、计量所、
客户发展中心
2
培训考核 完成对所有人员培训考核，人
员具备上机操作能力
实施方、实施地市、计量所、
客户发展中心
功能测试
1
功能确认
确认实施方新版程序
实施方、实施地市、计量所、
客户发展中心、营销部
2
功能测试 各单位按照实际业务测试系
统功能
实施方、实施地市、计量所、
客户发展中心、营销部
3
压力测试
完成并发测试
实施方、实施地市、计量所、
客户发展中心、营销部
印刷输出
1 发票印刷 计财部
2 收据印刷 计财部
3 业扩发票印刷
4 发票输出格式测试 实施地市、实施方
5 收据输出格式测试 实施地市、实施方
6 备款单格式 营销部
7 催费单格式 营销部
8 备款单印刷 实施地市
9 催费单印刷 实施地市
10 备款单输出格式测试 实施地市、实施方
11 催费单输出格式测试 实施地市、实施方
12 业扩发票输出格式测试 实施地市、实施方
13 抄表卡印刷 营销部
14 以上表单领用到位 实施地市
外围系统接口
抄表机
1 抄表机厂家程序完成 营销部
2 抄表机数据上传下载测试 实施地市、实施方
3 抄表机内抄表程序测试 实施地市、实施方
校表台
1 校表台的型号确认 计量所
2 校表台厂家接口程序完成 计量所
3 校表台数据上传测试 计量所、实施方
负控系统
1 集成方案制定 营销部、第三方、实施方
2 厂家接口程序完成 营销部、第三方
3 数据采集功能按照集成方案要求测试 营销部、第三方、实施方
4 数据清理核对 营销部、实施地市
远抄系统
1 集成方案制定 营销部、第三方、实施方
2 接口程序完成 营销部、第三方
3 数据采集功能按照集成方案要求测试 营销部、第三方、实施方
4 数据清理核对 营销部、实施地市
。。。
IC 卡系统
1
集成方案制定 营销部、原系统供应商、实
施方
2
厂家接口程序完成 营销部、原系统供应商、实
施方
3
集成方案测试 营销部、原系统供应商、实
施方
。。。
. 基本信息维护确认记录(基础数据、静态数据)
序号 数据项目 局方责任人 实施方责任人 备注
1 部门维护设置
2 岗则维护和设置
3 权限角色维护
4 人员维护与权限设置
5 人员工作设置
6 用户基本信息
7 抄表人员分配
8 抄表本调整与核实
9 抄表计划维护
10 抄表序号维护
11 核算人员分配
12 电费核算及用户电费计算模板
13 用户变压器信息维护
14 电力网络维护(变电站,线路,变压器)
15 电力网络计量点维护(总表)
16 客户配网关系维护
17 台区组维护、台区组责任人、考核指标
18 标准业务环节维护
19 标准业务处理事务维护
20 处理事务对应人员或岗则维护
21 客户号规则维护
22 工程费用维护
23 收费人员维护
24 发票类型维护
25 开户银行维护
26 催费本维护
27 催费客户维护
28 违月金计算天数维护
29 计量管理人员维护
30 计量人员资产权限维护
31 计量未入库的合格可用的资产进行入库
32 高压计量点维护
33 计量标准设备
34 计量标准装置
35 客户电能表正数、小数位
36 客户电表电量类别
37 客户电表电压等级
38 客户电表安装类型
39 客户电表值类型
40 客户电表提比提量信息
41 客户计费线损参数核实
42 客户计费变压器运行记录和参数核实
43 客户计费共用变压器参数维护
44 客户计费电费计算模板选择和维护
。。
. 系统切换工作步骤确认
序号 工作内容（简述） 预计完成时间 完成状态 实际完成时间 责任人
原系统数据备份
新增用户数据倒换
正式应用服务器安装配置（新老系统共用设备的）
备用应用服务器安装配置（新老系统共用设备的）
客户端程序更新到位核对
上月月抄表数据倒换
欠费数据倒换
欠费数据的核对
表计资产信息倒换
人员和权限核对
功能测试（见测试详单）
各个银行银电联网测试
IC卡系统接口测试
. 系统切割期间应急方案
. 存在的风险定义
应急预案的目的主要是防范技术风险，包括网络与平台风险和应用软件风险。其
中，网络与平台风险是常规风险，即每时每刻都存在的风险。软件风险是指应用软件
为适应电费中心改革而进行的软件适应性设计而带来的风险。
. 启动应急方案的标志
在系统上线过程中，当营销管理信息系统发生如下情况时：网络中断、服务器停
机、数据库运行异常、存储设备故障、病毒大面积发作等，应启动网络与平台风险应
急预案。当营销管理信息系统发生业务逻辑严重错误、系统权限管理存在重大问题等
时，应启动软件风险应急预案。就本次交接而言，应急预案的重点是软件风险，防范
这种风险的原则为：当发现升级软件存在重大缺陷时，系统能退回至原有状态，确保
各项业务正常开展。本次交接处在月初，应收风险较低，存在的风险主要是实收，即
交接的首要目的是确保各项收费必须正常进行，这项工作一旦出现意外，即可认为系
统存在重大缺陷，必须采取应急措施。
. 应急方案包括的主要内容
1、做好网络备份，交接前，由技术部门对网络专线、VPN等备份网络进行有效性
测试，确保主要网络发生故障时，备用网络能有效投运。
2、对服务器平台的操作系统、数据库以及存储设备进行重点检查，确保平台稳定
运行。
3、对数据中心的后备电源进行检查，以保证外部电源发生异常时确保数据可用。
4、在系统上线时，首先做好中心数据的物理备份，以保证系统的退回点。
5、上线单位所有人员的应急准备，一旦出现因系统原因导致交接失败，上线单位
的所有操作人员应能回到原始状态开展工作。
. 系统切换后责任确认
相关单位 相关人员 系统切割后一周所坚
守的岗位
电话
营销部
实施地市
实施地市计量所
实施地市客户发展中
心
实施地市计财部
信息中心/实施地市
信息中心
调度所
实施方
第三方
. 试点单位验收
试点单位的验收主要是针对建设的系统在试点单位的运行，分析是否满足标准化
设计成果，是否满足网省公司的管理要求，预测系统运行性能是否能满足全省(自治区)
推广的要求，做为项目的初步验收
. 试点测试验收时间计划
序号 试点点 计划日期 备 注
1
2
3
4
5
6
. 试点测试验收工作程序
本次测试预计需要 3 天时间，具体时间安排如下
日 期 地 点 工作安排 要 求
第一天
1、相关人员赶到相
应电业局。
2、召开验收预备会。
3、检查并确认验收
准备工作已经就绪。
第二天 测试
第三天
1、测试
2、测试报告
. 项目系统测试测评计划表
序
号
任务名称 工期 开始日期 结束日期 验收标准
1 性能测试
2 实用化测试
3 标准化测试
4 平台测试
4．1
. 试点验收结论
试点验收结论中需要包含以下内容：
序
号
验收项目 是否满足 验收结果
性能测试 满足推广的性能要求 可以推广
实用化测试 满足实用化的要求 可以推广
标准化测试 符合标准化设计成果 可以推广
平台测试 平台具备推广的支撑能力 可以推广
1．5 需要改进的地方 在推广的同时改进
. 推广
过程与试点推广的相同，范围扩大而已。
. 最终验收
. 测试验收整体时间计划
序号 项目点 计划日期 备 注
1
2 。。。
3 。。。
4 。。。
5
. 测试验收工作程序
本次测试预计需要 7 天时间，具体时间安排如下
日 期 地 点 工作安排 要 求
第一天
1、相关人员赶到相应电业
局。
2、召开测试预备会。
3、检查并确认测试准备工
作已经就绪。
第二天 测试
第三天 测试
第四天 测试
第五天 测试
第六天 测试
第七天
1、测试
2、测试报告
1、完成现场测试。
2、撰写系统终验意见以及测试问题和建议。
3、将测试结果等材料提交相应单位。
4、按附件的要求向内蒙古电力(集团)公司
提交材料。省(自治区)公司以此确认本次终
验工作完成。
. 项目系统测试测评计划表
序
号
任务名称 工期 开始日期 结束日期 备注说明
1 性能测试
工单《xx 分册》
工单《xx 分册》
工单《xx 分册》
工单《xx 分册》
2 实用化测试
工单《xx 分册》
工单《xx 分册》
3 标准化测试
工单《xx 分册》
工单《xx 分册》
工单《xx 分册》
4 平台测试
4．1 工单《xx 分册》
. 项目系统测试测评分工表
序号 组别 工作任务 姓 名 单 位 职务或职称 签 名
内蒙古电力(集团)公司
电力公司
其它专家
实施方
. 测试工作要求
1、测试小组应具体指定测试过程中的小组组长、副组长、操作、记录、工单保
管、审定人员。
组长：负责主持测试工作，指导操作步骤，并点明记录重点。
操作：负责测试具体操作。
记录：按照工单要求，负责测试过程的详细记录。
审定：对测试记录进行审定。
保管：负责对测试工单和相关材料进行保管。
为确保测试工作顺利进行，特殊操作可由实施方派员担任。在整个测试过程中，
人员与分工无特殊情况不得变动。
2、测试小组应将有关作为测试依据的材料带到测试现场。
3、在整个测试开始前，各测试组组长先将拟开展的测试工作向实施方培训人员
做简短交底。
4、在每项测试开始前，测试小组人员应一起学习测试工单，讨论每个测试项目
的操作步骤，测试过程中可能出现的各种情况、各种结果，测试中需要注意、检查并
记录的重点内容。
5、在测试过程中，应耐心细致听取实施方的有关说明，认真地、客观地记录测
试过程中出现的情况。每张测试工单操作完毕，应对测试过程和现象进行客观描述，
对测试结果进行判断，给出测试结论，各方人员应当场签字。
6、测试工作应按照测试工单顺序逐张进行，一张测试工单完成后方可进行下张
测试工单的测试，所有工单全部测试完毕即视为本次测试任务完成。
7、在测试过程中，如发现规定测试内容以外确有必要测试的内容（如系统的特
色优点、重要问题等），可以现场决定对系统进行随机测试，记录相关情况并形成书
面材料（准备空白测试工单作为书面记录用），视同正式测试工单进行保管。
8、在测试过程中，如出现不可抗力或重大例外事件造成测试中断，其后续测试
应急方案由省(自治区)公司与电业局商讨决定。
9、在测试现场，除测试组工作人员、开发商、以及电业局的配合人员外，其他
人员应不在现场逗留。
. 测试工单管理
1、所有测试材料均由工单保管员专门负责管理，统一进行分发、收回、保
管。
2、测试组工作人员在现场测试完成后，应将在测试过程中形成的相关材料、记
录以及测试工单一并装入档案袋，交工单保管员验收，核对无误后，重新封装，统一
保管。
4. 附件
. 测试验收相关附件
. 附件 1:《测试结果签字确认授权书》格式
. 授权书
测试结果签字确认授权书
致：内蒙古电力(集团)公司
内蒙古电力(集团)有限责任公司_特授权以下人员代表我公司全
权进行系统的测试工作，并即时签字确认全部有关的测试工单、文
件。
我院对被授权人的签名负全部责任。
在撤销授权的书面通知以前，本授权书一直有效。被授权人签
署的所有文件不因授权的撤销而失效。
序 被授权人姓名
1
2
3
4
5
单 位 名 称： (公章)
法 定 代 表 人 ： (签字)
年 月 日
. 项目实施公司授权书
测试结果签字确认授权书
致：内蒙古电力(集团)有限责任公司
（ 厂 商 ） _ 是 中 华 人 民 共 和 国 合 法 企 业 ， 法 定 地 址
_______________。（授权人姓名）特授权以下人员代表我院全权配
合系统的测试工作，并即时签字确认全部有关的测试工单、文件。
我院对被授权人的签名负全部责任。
在撤销授权的书面通知以前，本授权书一直有效。被授权人签
署的所有文件不因授权的撤销而失效。
序 被授权人姓名
1
2
3
4
5
单 位 名 称： (公章)
法 定 代 表 人 ： (签字)
年 月 日
. 附件 2:《最终验收意见》提纲
＿＿＿项目系统建设最终验收意见
本次对 XXX 项目系统在 内蒙古电力(集团)有限责任公司组织相
关专家进行了测试，形成如下验收意见：
一、系统建设基本情况
二、验收原则
三、系统功能评价
四、实施方提供的验收资料
五、最终验收测试发现的问题和提出的建议
见附件《＿＿＿内蒙古电力(集团)有限责任公司XXX项目系统测
试问题和建议》
六、最终验收意见
1、本次验收仅限于内蒙古电力(集团)公司《＿＿＿xxx项目系统
测试工单》所例范围，未尽测试内容，内蒙古电力(集团)公司有权在
认为必要时进行补充测试，实施方仍应对补充测试结果负责，满足
项目系统建设要求。
2、对测试中发现的问题，请 XX 公司在＿＿＿年＿＿月＿＿日
前落实解决，达到标准化设计的要求。
3、在问题解决后，公司根据实施方的申请组织进行针对性测试，
再做验收结论。
验收测试工作组
年 月 日
公司验收负责人（签名）：
公司验收负责人（签名）：
＿＿XXX项目系统测试问题和建议
（以下示例仅作为现场测试记录示范）
序号 测试条款 主 要 问 题 责任单位
. 附件 3：测试准备工作确认表
序号 准备项目 提供方单位/人员签名 确认方单位/人员签名
1
2
3
4
5
. 附件 4：提交的最终验收材料签收表
签字确认
序 材料名称 要求
甲方 乙方 第三方
一在测试前提交的材料
1
2
3
4
二在测试后提交的材料
6
7
8
