NMDLGC工程实施流程规范

北京雅龙汉正科技有限责任公司
项目管理标准
北京雅龙汉正科技有限公司
2008年1月
更改履历
改。

目录
1.概述
编制本计划的目的是用文件的形式，把对于在开发过程中各项工作的负责人员、开发进度、所需软、硬件条件及可能遇到的问题瓶颈等问题作出的安排记载下来，以便根据本计划开展和检查本项目的开发与实施工作。

2.项目计划管理
2.1.WBS(工作分解结构)分解
2.2.项目基线计划2.2.1.项目基线计划
2.2.2.基线评审计划2.2.2.1.基线评审时间计划
2.2.2.2.基线评审报告模版
2.3.项目附属计划
2.3.1.沟通计划
2.3.1.1.基于问题的沟通计划
2.3.1.2.日常沟通计划
2.3.1.2.1.周例会工作计划
2.3.1.3.与内蒙客户的沟通计划2.3.1.3.1.时间表
2.3.2.风险管理计划
风险管理贯穿与整个项目的全过程，具体的时间计划来源与项目实施的每个时间点。

风险是一种遭受损失的可能性，这种损失的程度可能导致对项目的伤害直至失败。

风险管理的目的是在风险发生前，识别出潜在的问题，以便在产品或项目的生命周期中规划风险处理活动，并在需要时启动，以减缓它们对目标的不利影响
2.3.2.1.定义
2.3.2.2.角色与职责
2.3.2.3.流程图
2.3.2.4.风险识别
2.3.3.配置管理计划
2.3.3.1.配置项定义
2.3.3.1.1.配置管理工具
采用运行在Windows环境下的Microsoft Visual SourceSafe。

按以下步骤搭建配置管理环境：
1.服务器端的安装
2.配置帐号
3.客户端的安装与配置
4.工具的具体操作
2.3.3.1.2.配置项标识
2.3.3.1.3.配置项命名规范
2.3.3.1.3.1.使用范围
适用于项目过程中编制的文档的命名。

程序源代码、目标代码、执行程序的文件编制参照相关编程语言的程序命名规范。

2.3.3.1.3.2.命名规则
1、纳入基线前的命名规则：<SGCC>—<项目简称>—<文档名称>—<文档时间
信息>
2、纳入基线的命名规则：<SGCC>—<项目简称>—<文档名称>—<版本号>
2.3.3.1.3.3.文档时间信息
格式为YYYYMMDD。

在文档没有纳入基线前，要求对文档采纳时间信息。

2.3.3.1.3.4.版本定义
1、主版本号
设置时间：本项目中发布的文档产品通过正式评审及正式对外发布时，或未发布前的初始化
设置人员：配置管理员；
设置规则：
1）新产品发布，主版本号为1；
2）产品的主体构件进行重大修改，主版本号加1；
3）产品的主体构件之间的接口协议修改，主版本号加；
4）主版本号变更时，副版本号同时置0。

2、副版本号
设置时间：产品发布及版本更新时；
设置部门：配置管理员；
设置规则：
1）新产品发布，副版本号为0；
2）对现有功能模块做重大修改，副版本号加1；
3）改进现有功能模块，不增加新的功能模块，产品的主体构件未做重大修改，副版本号加1；
4）为增加产品功能，在原版本产品上增加新的功能模块，而产品的主体构件未做重大修改，并且产品的主体构件之间的按口协议也未做修改，副版本号加1；
5）当主版本号变更时，副版本号同时置0。

3、版本编号说明
VX.Y
说明：V 是版本标识
X 是主版本号
Y 是副版本号
2.3.3.1.4.配置库目录结构
在本项目中采用VSS进行文档管理。

2.3.3.1.5.配置库结构说明
2.3.3.1.6.操作权限
整个配置管理库由参考资料、开发库、基线库、产品库共4个库组成。

参考资料：主要存放大家都经常查看的一些资料，比如客户的资料、项目组的一些资料，该库的权限大家都有读的权限，但客户的资料和前期项目资料只有配置管理员和核心组人员有其他一些处理权限。

开发库：存放开发过程中需要保留的各种信息，主要目的方便项目组成员个人使用。

库中的信息可能有较为频繁的修改，无需进行严格的控制。

本项目中，各配置项的责任人具有check in、check out和读权限，其他人员仅有读权限。

还存放管理方
面的文档和质量保证员或配置管理员操作的一些支持工作方面的文档。

主要操作者是项目经理或项目核心组人员，其他人员都是可以查看的。

如果根据需要项目组的某些人员需要其他权限，可以先申请进行开通。

基线库：存放已定义的基线，基线必须进行严格的控制，由配置管理员负责管理与维护。

本项目中，配置管理员具有check in、check out和读权限，其他人员均只有读权限。

产品库：存放需要交付给用户的且经过测试、评审的产品。

也需要一定的控制，由CM员负责管理与维护。

本项目中，配置管理员具有check in、check out和读权限，其他人员均只有读权限。

2.3.3.2.配置项管理活动
2.3.3.2.1.版本控制
采用开发主线的方式进行版本管理
无需修改的配置项（如部分记录、报告、总结等）
直接提交配置管理服务器相应模块下的工作目录内，由配置管理服务器自动管理版本，配置项本身不必体现版本号的记录。

可能修改的配置项（大部分的成果性文档、提交客户的文档）
配置项本身必须体现版本号的记录；
对已提交配置管理服务器配置项的修改，必须先从配置管理服务器上检出该配置项，对检出的配置项进行修改；
检出修改之前，必须先察看是否有人正在操作（修改）此配置项，有人操作时，不准检出修改；
检出配置项修改后再次提交配置管理服务器时，版本按照前面的版本定义的规定管理；
本地初次生成版本用时间信息控制；
检出版本vx.y，检出后本地修改版本用时间信息控制；
未提交配置管理服务器的配置项或文档、资料（即本地的文档及资料），按照时间信息的方式管理版本；
提交配置管理服务器的配置项（即vss上的文档及资料），按照vx.y的方式管理版本。

2.3.3.2.2.基线管理
2.3.3.2.2.1.基线定义
2.3.3.2.2.2.配置项审计
配置项审计在配置管理中占很重要的位置，它是项目过程相关的配置项集合的审查。

根据审计内容和审计对象的不同可以把基线审计分为物理审计、功能审计，形成基线审计报告:
物理审计：主要考察偏差，完整性检查、版本是否正确。

参加人员：项目经理、质量保证员、配置管理员。

功能审计：主要考察功能是否实现。

参加人员：项目经理、质量保证员、配置管理员、测试人员。

进行以下的审计：
2.3.3.2.2.3.配置项状态报告
受控库（基线库和产品库）配置项出入库填写《配置项状态报告》并通过邮件发布出入库通知。

2.3.3.2.2.4.基线变更
参见《变更管理程序》
2.3.3.2.3.出入库控制
2.3.3.2.3.1.入库
受控库（基线库和产品库）配置项入库规程：
1、入库申请
申请人直接或通过邮件向配置管理员提交入库申请，经入库审查之后,由配置管理员将配置项入库。

2、入库审查
配置管理员对配置项进行完整性、正确性的审查。

3、入库登记与通知
配置管理员执行入库操作，同时填写《配置项状态报告》，通过邮件发布入库通知。

2.3.3.2.3.2.出库
受控库（基线库和产品库）配置项出库规程：
1、出库申请
申请人直接或通过邮件向配置管理员提交出库申请，经出库审查之后,由配置管理员将配置项出库。

2、出库审查
配置管理员对配置项进行完整性、正确性的审查。

3、出库登记与通知
配置管理员执行出库操作，同时填写《配置项状态报告》，通过邮件发布出库通知。

2.3.3.3.备份
本项目的配置管理备份方案：
1.保持配置数据库的大小不超过5G；
2.备份频率：每月进行VSS库的完全备份，并将备份文件备份至文档服务器指定目录。

3.备份检查：不定期进行备份文件的文件恢复测试，确保备份文件的有效性。

2.3.4.质量保证计划
2.3.4.1.项目SQA参与的项目活动
2.3.4.2.SQA活动计划
质量保证人员的活动计划
2.3.4.3.收集度量数据
2.3.4.4.质量活动结果
该部分说明质量保证人员计划做成的质量活动文档
2.3.4.5.项目质量保证报告机制
该部分说明项目质量保证报告的对象、时机、频度和报告内容。

2.3.4.6.质量保证计划表
2.4.项目阶段计划2.4.1.1.定义
2.4.1.2.角色与职责
2.4.1.
3.流程图
详细阶段计划参看附件《项目阶段计划表》2.5.项目实施采用的平台软件
3.项目实施作业标准
3.1.项目实施过程工作项3.1.1.1.项目启动阶段
1、项目立项
2、下达项目确认书
3、项目任命
4、项目资料移交
5、组建核心团队
6、召开项目启动会议
3.1.1.2.项目策划阶段
1、项目过程定义
2、工作任务分解
3、风险识别
4、计划项目进度
5、明确项目组织机构和职责
6、编制总体计划草案
7、总体计划评审核
8、总体计划调整并纳入基线
9、编制辅助计划
10、辅助计划确认
11、编制阶段计划
12、编制周计划
3.1.1.3.项目开发阶段
1、原型开发
2、需求调研（贯标）
3、UE/UI设计
4、系统设计
5、接口设计
6、系统实现
7、系统单元测试
8、系统集成测试
9、系统功能测试
10、系统压力测试
3.1.1.
4.工程实施阶段
1、工程实施启动与准备
2、培训环境确认及准备
3、培训
4、系统运行环境确认
5、系统环境测试（软件平台、硬件平台、网络）
6、系统部署与数据加载测试
7、试点单位系统切换
8、试点单位验收
9、推广
10、验收
3.2.项目实施作业标准3.2.1.项目启动阶段
3.2.1.1.项目立项
3.2.1.1.1.角色与职责
3.2.1.1.2.流程图
3.2.1.1.3.步骤
3.2.1.1.3.1.进行可行性分析
3.2.1.1.3.2.立项申请
详细参看立项目申请报告、可行性分析报告
3.2.1.1.3.3.立项评审
详细参看立项目评审报告
3.2.1.1.3.3.1.相关干系人
机构领导
项目经理
项目核心组
3.2.1.1.3.3.2.过程描述
(1)立项评审应按照如下过程进行：
机构领导负责召集成立立项评审组。

立项评审组必须包括下列成员：项目经理、技术骨干、市场人员、并指定评审组组长。

在评审之前，评审组成员应认真阅读《立项可行性分析报告》和《立项申请表》，并且按照“立项评审检查表的条目进行检查，（《立项评审检查表》
在《立项评审报告中》）评审组成员在进行检查时，可以根据项目的实际情况对检查的内容进行增加或删减。

机构领导召开立项评审会。

评审组通过讨论形成一致意见，由评审组组长负责填写《立项评审报告》并签署意见。

《立项评审报告》需要上交机构领导做出最终裁决。

(2)根据评审结果，项目组织以下后续行动：
批准立项，进入下一阶段。

拒绝立项，立项取消并解散项目核心组。

3.2.1.1.3.3.3.出口准则
立项评审组和机构领导均已在《立项评审报告》上签署意见
3.2.1.1.3.3.
4.输出
《立项评审报告》
3.2.1.1.3.
4.立项发布
3.2.1.1.3.
4.1.入口准则
项目已批准立项
3.2.1.1.3.
4.2.输入
《立项可行性分析报告》
《立项申请表》
《立项评审报告》
3.2.1.1.3.
4.3.相关干系人
项目经理、商务部
3.2.1.1.3.
4.4.过程描述
(1)项目合同双方均已签字确认。

(2)商务部经过合同确认，给予项目号。

3.2.1.1.3.
4.
5.出口准则
项目合同已签字确认
项目组获得项目号
3.2.1.1.3.
4.6.输出
《项目合同》
3.2.1.2.下达项目确认书
依据内蒙古电力(集团)公司下达的最终项目确认书为标准3.2.1.3.项目任命书
项目任命书
3.2.1.
4.组建核心团队
参见项目组织体系
3.2.1.5.召开项目启动会议
3.2.1.5.1.会议准备
1、会议时间确定
2、会议地点确定
3、甲方参会人员
4、乙方参会人员
5、会议内容
3.2.1.5.2.会议内容要求
1、项目的甲方组织体系
2、项目的乙方组织体系
3、项目的进度要求明确
4、项目的时间计划表确认
5、项目各个阶段双方的联络人确认
6、项目各个阶段双方的分工确认
3.2.1.5.3.会议组织注意事项
1、在会议召开前提前一个工作周通知甲方会议的相关内容。

2、会议的后勤保证需要具体的方案。

3.2.1.5.
4.项目启动会议纪要
3.2.2.项目策划阶段
3.2.2.1.项目过程定义
依据项目工程定义模版，确认项目过程中的每一个步骤是否在本次项目中采用，补充针对本次项目的特殊过程。

3.2.2.2.工作任务分解
参见《WBS分解》
3.2.2.3.风险识别
参见《风险管理计划》
3.2.2.
4.计划项目进度
项目进度计划在以内蒙古电力(集团)公司招标书中要求的项目实施进度的框架之内，细化的每周每人具体的工作细节、严格考核。

3.2.2.5.明确项目组织机构和职责
参见《项目组织体系》
3.2.3.项目开发阶段
3.2.3.1.原型开发
依据内蒙标设成果中的需求规格说明书等系列文档，使用Axure RP Pro工具，将系统的基本功能点和辅助功能点可视化，形成系统交互原型。

3.2.3.2.需求调研
需求调研是在针对标准化设计成果的基础上，对实施的网省(自治区)公司从业务需求、运行现状、原系统情况进行调研，得到项目实施的网省(自治区)公司的业务需求与标准化设计成果的差异处，同时掌握现有系统的情况及运行情况，为下一步系统实施做好准备工作。

需求调研计划编写
需求调研工作联系
需求调研会议举行
需求调研原型讲解
需求调研需求规格书讲解
需求调研需求差异了解
需求调研结果整理
需求调研报告
详细参见《调研标准计划书》
3.2.3.3.UE/UI设计
在前期制作的系统交互原型的基础上，进行用户体验改进测试和UI设计工作。

3.2.3.
4.系统设计
根据UE/UI设计成果、功能精细化设计文档、数据模型设计文档，IT架构设计文档进行系统用例抽取设计、系统用例实现设计、实体类设计、测试用例设计等。

3.2.3.5.接口设计
根据内蒙一体化集成平台、内蒙功能精细化设计文档、已有系统现状进行与营销系统相关的接口操作规范设计。

3.2.3.6.系统实现
根据系统设计和接口设计相关文档，进行具体的编码实现。

3.2.3.7.系统单元测试
根据系统测试用例设计文档对已经实现的系统进行单元测试。

3.2.3.8.系统集成测试
根据系统测试用例设计文档对已经实现的系统进行集成测试。

3.2.3.9.系统功能测试
根据系统测试用例设计文档对已经实现的系统进行功能测试。

3.2.3.10.系统压力测试
根据系统测试用例设计文档，使用LoadRuner对已经实现的系统进行压力测试。

3.2.
4.工程实施阶段
3.2.
4.1.工程实施启动与准备
3.2.
4.1.1.实施前与甲方的沟通
实施团队进驻现场前与甲方良好的沟通，是实施工作的顺利开展前提条件，通过进驻现场前的沟通为项目团队提供一个良好的工作环境与工作氛围，给项目实施工作的开展带来有利的条件。

进驻现场前与甲方的沟通主要从以下几个方面：
1、交流进驻现场的时间安排
通过与甲方的沟通，最终形成现场实施人员进驻现场的确定时间，最终形成确认函，以便项目经理安排人员进驻现场工作。

2、了解甲方项目实施到位情况
确认甲方的项目实施小组是否成立、是否满足现场实施人员进驻现场的条件。

3、明确项目实施人员进驻现场的办公条件
明确项目实施团队进驻现场后需要的工作环境及需要甲方配合解决的办公设施。

4、了解项目实施人员进驻现场的饮食居住条件
了解现场的饮食居住条件，以便项目经理提前安排进驻现场的项目实施人员的后勤保障工作。

5、提交项目实施人员的详细职务及分工表
提交项目的实施人员详细的职务、联系方式及分工，以便甲方能提前确定对应的配合人员。

6、了解甲方项目实施人员的联系方式
获取甲方项目实施人员的详细职务、联系方式及分工，以便能提前确定对应的配合人员。

3.2.
4.1.2.实施团队进驻现场
项目实施团队合理的进驻现场，对树立项目团队的管理形象是关键的一个环节，是整个项目实施的一个良好开端，因此采取何种方式进驻现场应该有严格的管理，项目团队进驻现场主要从以下几个方面进行考虑。

第一：进驻现场的批次管理
第二：每个批次进驻现场的人员组成管理
第三：每个批次进驻现场的时间管理
第四：每个批次进驻现场的相关事务管理
3.2.
4.1.2.1.项目团队进驻现场的批次
综合考虑本次项目实施的特点，项目团队进驻现场的分三个批次：
第一批次由项目经理带队，进驻现场的目的为确认现场工作环境、生活环境、搭建系统测试环境，准备培训环境；同时与甲方领导层进行沟通，对项目实施的计划与方案达成共识。

第二批次由培训组长带队，进驻现场开始准备数据切割、上线工作等。

第三批次由业务问题诊断负责人带队，对现场处理的业务问题进行确认形成需求变更，同时对现场实施后出现的问题纳入问题管理业务流程进行管理。

3.2.
4.1.2.2.每批次进驻现场的人员组成
第一批次：项目经理、系统集成工程师、技术支持工程师、业务支持工程师、培训工程师。

第二批次：培训组长、系统实施工程师。

第三批次：现场问题接收、反馈人员；业务问题诊断人员。

3.2.
4.1.2.3.每个批次进驻现场的时间
第一批次：进驻现场时间点为现场环境具备、甲方配合项目实施小组组建完成、完成系统建设上钱前的外围准备工作。

第二批次：现场外围建设已经完成，进驻现场完成上线前的所有准备工作，预计时间为xxxx年xx月中旬
第三批次：系统切换前，协助系统上线及上线后的问题收集、整理确认。

3.2.
4.1.2.4.每个批次进驻现场的相关事务
每个批次进驻现场前需要准备的和落实的事情繁多，必须按照规定的条款逐一落实到位的情况下才可以进驻现场，否则会使项目从一开始就处理混乱的状态，每个批次进驻现场前需要落实的事情如下：
项目团队进驻现场前情况核实表
3.2.
4.1.3.召开工程实施启动会议
会议按照标准组织形式进行组织，但结合本项目在工程实施会议中需要从以下几个方面进行准备与考虑。

3.2.
4.1.3.1.会议准备
会议时间确定
会议地点确定
甲方参会人员
乙方参会人员
会议内容
3.2.
4.1.3.2.会议内容要求
甲方工程实施管理体系明确
乙方工程实施管理体系明确。