XX项目实施管理方案

1.1 项目实施与管理目标

一般项目的管理采用目标管理法。项目管理目标主要包括用户满意度、进度、质量、风险、成本五类，当前重点考虑在满足其它管理目标的前提下取得最大用户满意度。

用户满意目标

用户满意是项目管理追求的首要目标，也是其他目标执行的指导原则。

进度控制目标

遵照招标书要求，严格遵守合同规定，不折不扣地按时完成合同规定的所有工程任务。在工程执行过程中出现任何变化，在保障用户利益的前提下，双方磋商、达成一致，确保合同完成，让用户满意。

质量控制目标

质量是工程建设的基石，没有质量其他目标就没有意义。质量控制在项目管理中是极其重要的，通过建立规范的管理体系、严格的内部管理措施、可靠的工程质量保障机制、明确的验收方式、有效的知识转移培训和完备的售后服务措施，确保项目的顺利实施，不会造成任何形式的返工。

风险控制目标

任何事件的发展都会有一定意外，它的发生是不确定的，这种脱离常规的意外称之为风险。风险存在于任何工程建设项目，风险控制是长期、大型项目管理所必需的管理内容。根据以往经验，重视风险要比风险管理本身更重要。风险不可预测，但可以管理与补救。本项目将从风险因素管理、风险预警与应急管理、风险补救三个方面确保项目风险处于管理控制范围之内。

预算控制目标

项目预算控制反映了项目建设的高效性，考核项目预算是自我监督的重要步骤，目的在于提高项目管理水平。控制项目预算的表现在资源调配的合理、高效，重点在于项目规划设计与组织，难点在于对用户需求把握的准确性和设计的合理性、科学性。

我公司目前自行开发的PMS系统作为专业的项目管理工具。通过该工具的各个模块实现对项目的全面管理。

PMS系统能够为项目经理提供如下帮助：

1）为项目分配人员，并为项目人员编制任务计划，同时对于人员的实际工作地点以及工作任务也能够实时进行跟踪和监督，从而实现项目人员的全面监管；项目团队配置情况页面如下图所示：

项目人员分配

2）利用PMS系统可以对每月项目的费用进行预算，并能实时进行计划值与实际值的对比，为项目经理提供决策支持；项目预算配置页面如下图所示：

项目预算管理

3）在项目的实施与运维过程中，它可以对里程碑任务进行跟踪并使里程碑获得财政审批以确认收入，它使得项目经理能够管理项目中的问题和缺陷，它也可以对审查和流程进行跟踪；项目里程碑配置页面如下图所示：

项目里程碑管理

4）它还有助于项目经理加速报告的进程。

1.2 项目组织机构

1.2.1 项目组织架构

本项目的项目组织架构由XX报社项目组和XX公司项目组共同组成，采用项目领导组领导下的各级项目组长负责制，并明确规范所属各组的职责及组间协调关系。这种组织结构是XX公司在多个大型工程项目采用，并被验证为行之有效的工程组织方案。

整体项目的组织结构如下图所示：

整体项目组织结构图

项目管理采用项目组长负责制，形成内部垂直管理体系。各项目小组之间的工作流程和协作关系如下。

n 项目领导小组

负责该项目的统一领导，在实施过程中进行管理，做出重大决策。

n 项目经理

项目经理是项目的总负责人，对内负责公司内部资源的协调，对外负责与客户的沟通，对项目的决策、需求变更、执行进度等负责。

项目经理是整个项目执行过程中的关键人物，项目经理的更换必须以正式的形式向XX报社项目领导小组申请，在得到批准后方可调换。

n 技术经理

技术经理负责项目的总体设计，指导管理体系梳理、业务架构和技术架构设计、总体技术方案实现以及各地实施方案的设计和评审，指导各小组的设计和开发工作。同时还需要负责技术路线选择、技术架构设计和逻辑结构设计，带领和指导设计团队进行详细的系统设计。

n 需求组

由各模块项目经理及设计师组成，负责进行各模块需求调研，根据调研结果编写需求调研报告。

需求开发组的工作分为两个阶段，第一阶段的任务是框定项目的范围，第二阶段的任务是进行具体的需求调研工作。

需求组需要XX报社集团及其相应部门的相关人员配合。

n 设计组

负责解决系统建设过程中的各种规划和设计问题：负责编写系统建设方案，负责编写系统安装配置手册，负责制定各阶段验收方案。总体设计组由XX公司的系统设计人员和各方面技术专家组成。

n 开发组

负责进行XX报社集成信息门户项目系统的软件开发，输出源程序、目标程序及用户操作指南。开发组由XX公司各级别软件开发工程师组成。

n 测试组

负责对系统进行内部测试。包括功能测试和性能测试。为了严格把关、提高测试效率，项目组将设立专门的测试岗位，派专人完成软件测试工作。并且，邀请用户方委派代表监督测试工作的执行过程。测试组由XX公司技术负责人、业务负责人和用户方代表组成。

n 实施组

实施组负责XX报社集成信息门户项目操作系统、中间件、数据库如搭建、系统的部署和安装工作，以及相关部署文档的整理工作。

n 培训组

培训组负责三个标段模块的使用、管理和配置的现场和远程培训工作。

培训组成员由实施组和部分开发组成员兼任。

n 运维服务组

运维服务组负责软件推广实施后的本项目的技术支持与服务工作，提供给用户及时准确的帮助，包括系统的培训、使用方便的热线咨询、现场服务和故障的修复。运维服务组由XX公司技术服务中心工程师和现场工程师组成。

为确保项目的成功完成，包括设计、开发、实施等在内的所有XX公司项目组的技术人员将在项目经理带领下，组成项目的长期服务机构。

n 商务代表

商务代表负责协调项目的合同及相关软硬件厂商的沟通协调。

1.2.1.1 参加本项目人员汇总表

序号	项目组职务	姓名	资格证明
序号	项目组职务	姓名	证书名称	级别	证号
1	项目经理
2	技术经理
3	高级需求分析师（协同办公）
4	高级需求设计师（人事薪酬）
5	中级需求分析师（协同办公）
6	中级需求设计师（人事薪酬）
7	高级系统设计师
8	中级系统设计师
9	中级系统设计师/数据库设计师
10	中级系统设计师
11	高级开发工程师
12	高级开发工程师
13	高级开发工程师
14	高级开发工程师
15	中级开发工程师
16	中级开发工程师
17	中级开发工程师
18	中级开发工程师
19	中级开发工程师
20	测试工程师
21	测试工程师
22	实施负责人
23	实施工程师
24	实施工程师

1.3 项目实施规划

本项目建设周期为1年，为确保项目实施进度和质量，满足XX报社建设目标，分两组进行并行开发，其中门户和协同办公第一组，人事薪酬第二组。另外，门户和公文管理部分可以在12月份之前快速上线。实施整体规划如下图：

1.4 项目实施计划

招标要求本项目建设周期为1年。XX公司根据1年的建设周期要求提供整体项目实施计划和保障措施，具体实施计划安排如下：（假设本项目于2016年9月10日签订合同）

项目阶段	时间计划		工作内容描述	备注
一、项目启动	2016/9/10~2016/9/15			《项目任务书》《项目总体计划》
1、项目规划	2016/9/10~2016/9/12		成立项目组，确定工作分工和工作方法	成立项目组、对项目范围、目标达成共识、项目启动
			签订项目任务书
			制定项目总体计划
二、需求分析	2016/9/16~2016/12/31			《需求规格说明书》
第一组：门户和协同办公需求调研及分析（2016/9~2016/10）				包括需求调研、需求分析、编写需求规格说明书和需求确认。
1、需求调研	2016/9/16~2016/9/30	搭建试用系统，培训与调研业务流程、管理要求和功能需求
2、需求分析级设计	2016/9/16~2016/10/15	部分界面原型设计、编写《需求规格说明书》
3、需求评审确认	2016/10/16~2016/10/31	组织需求评审完善《需求规格说明书》，需求签字确认
第二组：人事薪酬、集成及广义数据管理需求调研及分析（2016/11~2016/12）
1、需求调研	2016/11/01~2016/11/31	搭建试用系统，培训与调研业务流程、管理要求和功能需求
2、需求分析级设计	2016/11/15~2016/12/15	部分界面原型设计、编写《需求规格说明书》
3、需求评审确认	2016/12/16~2016/12/31	组织需求评审完善《需求规格说明书》，需求签字确认
三、系统设计	2016/10/01~2017/01/31			《系统设计说明书》
第一组：门户和协同办公系统设计（2016/10~2016/11）				系统设计说明书
1、系统设计	2016/10/01~2016/10/31	系统数据库设计、功能设计、接口设计
2、设计评审	2016/11/01~2016/11/15	组织设计评审完善《系统设计说明书》
第二组：人事薪酬、集成及广义数据管理系统设计（2016/11~2017/01）
1、系统设计	2016/11/15~2017/01/15	系统数据库设计、功能设计、接口设计
2、设计评审	2017/01/16~2017/01/31	组织设计评审完善《系统设计说明书》
四、系统开发	2016/10/15~2017/4/30			源代码、《配置管理报告》
第一组：门户和协同办公系统开发（2016/10~2017/02）				代码开发及单元测试
1、PC门户	2016/10/15~2016/11/15	PC门户开发及单元测试
2、移动门户	2016/10/15~2016/11/15	移动门户开发及单元测试
3、信息门户	2016/10/15~2016/11/15	信息门户开发及单元测试
4、协同办公应用	2016/11/01~2017/02/28	公文、事务、会议、车辆、办公用品、知识管理、协同管理、各部门其他协同办公开发及单元测试
第二组：人事薪酬、应用集成开发（2016/12~2017/03）
1、人事薪酬应用	2016/12/01~2017/03/15	人事档案、稿费核算、薪酬管理、考勤、合同、社保福利、干部评议、员工绩效考核、党工团管理开发及单元测试
2、应用集成	2017/03/15~2017/03/31	北大方正采编业务系统2.0版、北大方正采编业务系统二期、金蝶财务系统、审计管理系统、舆情系统、两微端管理系统（包括微博、微视、微信、app客户端）开发及单元测试
3、中经网对接	2017/03/15~2017/03/31	与中国经济网的对接开发及单元测试
五、系统测试	2016/11/1~2017/03/31			源代码和《测试报告》
第一组：门户和协同办公系统测试（2016/11~2017/02）				包括集成测试、联调测试、压力测试
1、制定测试计划	2016/12/1~2016/12/25	制定测试计划和测试方案
2、准备测试环境	2016/12/26~2016/12/31	准备测试环境、测试数据
3、系统测试	2017/01/01~2017/02/28	系统测试、集成测试、性能测试和安全测试
第二组：人事薪酬、应用集成测试（2016/12~2017/03）
1、制定测试计划	2016/12/15~2017/01/15	制定测试计划和测试方案
2、系统测试	2017/01/16~2017/03/31	系统测试、集成测试、性能测试和安全测试
六、系统安装调试	2017/04/01~2017/04/15			《安装维护手册》、《系统操作手册》
1、系统安装调试	2017/04/01~2017/0/15	系统安装系统数据初始化系统调试		《安装维护手册》、《系统操作手册》
七、系统初验	2017/04/15~2017/04/30			《系统初验报告》、《初验文档》
1、验收文档准备	2017/04/16~2017/04/25	准备需求文档、设计文档、测试文档、操作手册等		验收文档
2、系统初验	2017/04/26~2017/04/30	召开验收会议，签字确认系统初验

八、系统上线试运行	2017/5/01~2017/7/30			《系统运行报告》
1、系统试运行	2017/03/16~2017/05/31	用户培训及试运行问题收集系统完善和优化
九、系统终验	2017/08/01~2017/08/31			《终验报告》、《终验文档》
1、验收文档准备	2017/08/01~2017/08/20	准备技术文档、需求文档、测试文档等		验收文档和系统完善
2、系统终验	2017/08/21~2017/08/31	验收申请、组织验收会和签字确认
十、运维服务	2017/09/01~2018/08/31			《服务日志》、《系统运行报告》
1、系统完善和优化	2017/9/01~2018/08/30	根据运行情况进行系统完善和修改
2、技术支持与服务		技术支持与服务

1.5 软件过程管理

软件过程管理的一方面是提高质量，降低成本；另一方面则是软件的工程化开发提供保障。

根据此项目的特点以及公司CMMI5的管理要求，我们在软件过程管理中将在软件原型的基础上采用“渐进生命周期模型”，形成合理的过程管理方法。项目的完整生命周期从立项开始到维护期结束，XX报社集成信息门户项目管理过程分为项目调研与需求管理、系统设计、编码开发、软件测试、集成服务、施工保证、试运行与维护等管理。

1.5.1 项目调研与需求管理

1.5.1.1 概述

项目调研是通过调查与分析，获取XX报社集团的需求，了解XX报社集团的组织结构、确定用户并识别部门关键的业务过程与活动、区分过程和活动的优先级、了解部门现有信息系统及运行状况、了解系统功能/性能接口列表等。

需求管理是在XX报社集团与XX公司之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更，实现对需求的确认、跟踪、变更控制等。

1.5.1.2 项目调研与需求管理步骤

n 项目调研过程

通过调查与分析，获取XX报社集团的需求并定义系统需求，包括需求调查、需求分析、需求定义：

需求调查：在XX报社集团进行访谈式和问卷式调研，通过各种途径获取用户的需求信息（原始材料）。在需求调查时，XX公司应做尽可能详细的记录，回公司整理后，发给需求负责人，项目负责人收集所有记录，形成项目整体的需求记录。另在调研时应注重对调查结果进行整理，并对现有业务流程进行整理（形成用例），以确保被调查业务的完整性。

需求分析：对各种需求信息进行分析，消除错误，刻画细节等。

需求定义：根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《系统需求规格说明书》。系统设计人员将依据《系统需求规格说明书》开展系统设计工作。需求人员要协助测试人员一起制定《系统测试计划》和《系统测试用例》。

n 需求管理过程

项目调研管理包括需求确认、需求跟踪、需求变更控制管理。

需求确认：由XX报社集团和XX公司共同对《系统需求规格说明书》进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。需求确认包括“需求评审”和“需求承诺”。

需求跟踪：比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保“需求－设计－编程－测试”之间的一致性，确保产品依据需求文档进行开发。

需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。

1.5.1.3 交付件

《系统需求规格说明书》

1.5.1.4 完成标准

《系统需求规格说明书》审批通过。

1.5.2 系统设计

1.5.2.1 概述

系统设计覆盖《系统需求规格说明书》的全部内容，并作为程序开发的依据，使系统能够被软件开发小组顺利地实现。

1.5.2.2 系统设计的步骤

n 概要设计

概要设计注重宏观和框架的设计，包括总体结构设计、全局数据库（包括数据结构设计）、外部接口设计、功能部件分配设计、部件间接口设计，覆盖《系统需求规格说明书》中的功能点列表、性能点列表、接口列表。其过程如下：

其中数据库设计包括数据库需求分析—→数据库概念设计—→数据库物理设计三个阶段，其过程如下：

n 详细设计

详细设计覆盖《系统概要设计说明书》的全部内容，注重微观和框架内的设计，是各子系统的公用部件实现设计、专用部件实现设计、存储过程实现设计、触发器实现设计、外部接口实现设计、部门角色授权设计、报表输出模块设计、前台用户界面设计、后台数据处理模块设计、数据传输与接收模块设计等。

在设计阶段后期要重新进行规模、工作量和进度的估算，调整开发计划。进行概要设计的人员要协助测试人员一起制定《系统测试计划》和《系统测试用例》；进行详细设计的人员要制定《系统单元测试计划》和《系统单元测试用例》。

1.5.2.3 交付件

n 《系统概要设计说明书》

n 《系统详细设计说明书》

1.5.2.4 完成标准

《系统概要设计说明书》和《系统详细设计说明书》审批通过。

1.5.3 编码开发

1.5.3.1 概述

软件实现是通过输入《系统详细设计说明书》，输出源程序、目标程序及用户指南，此阶段分为编码、代码静态检查和单元测试三个环节：编码人员根据《编码规范》进行编码；代码静态检查对代码的规范符合度进行检查，质量保证人员也要抽查编码规范的遵守情况；单元测试由编码人员根据详细设计阶段制定的测试用例自行或交叉进行，最终形成《单元测试报告》。

1.5.3.2 编码开发的步骤

1、项目组根据概要设计说明书、详细设计说明书制定系统实现计划

2、有条件的情况下保证开发、测试和生产环境独立。选择软件工具，明确项目成员的职责分工，按照编码规范和详细设计实现软件功能。

3、代码应满足结构良好，清晰易读，且与设计一致，符合编码规范。

4、开发人员需要软件实现过程中编写软件功能说明，源代码说明。软件功能说明文档应说明项目名称、编号、软件名称和版本号，软件功能、主要功能实现过程。源代码说明应说明项目编号、软件名称、功能，全局变量、数据库字典、函数功能、接口。该文档包含在源代码文件中，以注释形式存在。

5、项目组进行单元测试和集成测试。开发人员处理测试人员反馈的测试问题，并以书面形式反馈主要问题及解决办法，直至系统运行稳定。

6、汇总并提交所有相关文档，提交公司备案。

1.5.3.3 交付件

n 系统源代码；

n 《单元测试报告》

1.5.3.4 完成标准

系统编码结束。

1.5.4 软件测试

1.5.4.1 概述

软件测试包括单元测试、集成测试、系统测试、运行与验收测试，其中单元测试在系统实现阶段实现，运行与验收测试在实施与运行阶段实现。测试的内容有接口与路径测试、功能测试、健壮性测试、性能测试、用户界面测试、压力测试、可靠性测试等。

制定系统整体测试方案，将报指定的有资质认证的软件测试中心进行检测。

1.5.4.2 软件测试过程

软件测试过程如下图：

第一步：制定测试计划。

第二步：设计测试用例。

第三步：执行测试。

第四步：撰写测试报告。

第五步：消除软件缺陷。

1.5.4.3 交付件

n 《软件测试计划》

n 《软件测试报告》

1.5.4.4 完成标准

《软件测试报告》审批通过。

1.5.5 集成服务

1.5.5.1 概述

集成包括用户集成、数据集成和数据集成。系统间集成的方式有服务的方式、队列方式、数据库表方式等。本项目的具体集成方式根据XX报社集团的要求来最后确定。

1.5.5.2 集成过程

Ø 确定集成需求

XX公司项目组和甲方、其他相关应用系统开发商一起，对系统集成需求进行调研，主要从应用系统集成需求、应用集成平台需求和基础支撑环境需求三个角度展开对应用系统集成工作的全面调研，明确系统之间的关联关系，以及应用系统与应用集成平台的关联关系，确认整体集成需求，以更好的开展集成设计工作。

Ø 执行集成标准

在集成设计时，规范标准很重要。本系统的集成将按照XX报社集团制定的应用集成规范和标准进行门户、应用和数据集成。确保集成的技术先进，灵活可扩展。

Ø 统一集成设计

有了对需求的全面完成的把握，项目按照SOA架构进行总体设计，并基于构件技术对应用系统进行切分并开发这些构件，最终由总集成商集成在应用集成平台上。

Ø 集成测试实施

集成实施阶段首先需要确认集成环境已经准备继续，然后组织集成的相关系统开发商和业务部门进行集成测试，测试通过进入试运行，试运行期间有问题及时记录、修改并测试验证问题，确保集成顺利实施。

1.5.5.3 交付件

n 《集成设计说明书》

n 《集成测试报告》

1.5.5.4 完成标准

集成测试实施通过。

1.5.6 施工保证

1.5.6.1 概述

在XX报社集团进行的系统的软、硬件安装调试，以及系统管理员培训、业务操作培训、现场培训、数据初始化和数据导入等工作。XX公司对试运行结果和意见进行汇总，提交系统试运行报告，并请XX报社集团进行审核批示，确定需作改进的问题，交付XX公司进行修改，XX公司根据问题汇总制定修改计划，并按时完成软件更新。

1.5.6.2 系统实施过程

系统实施是一项复杂的工作，需要XX报社集团和XX公司做认真细致的准备。进行软件工程过程中发生的各种软件工程管理活动。实施项目计划，最重要的是遵循计划，并完成相关的工作。实施过程包括以下步骤：

1.5.6.2.1 设备与系统检测

检查系统所包含的硬件设备和系统软件是否正常。硬件设备有主机、网络、线路和电源；系统软件主要包括操作系统版本、IE版本、数据库系统、应用服务器、Web服务器等。

1.5.6.2.2 安装应用系统

n 安装数据库，进行初始化；

n 安装、配置中间件平台系统；

n 配置HTTP系统；

n 应用软件的安装。

1.5.6.2.3 运行规划与准备

在本阶段对业务流程进行详细划分，确定并安排每个岗位的职责，确定业务过程的衔接，准备操作员信息表，确定每个操作员的岗位；

进行人员的管理咨询培训和上线准备培训。

1.5.6.2.4 基础数据准备与导入

和XX报社集团进行基础数据编码规划探讨，XX报社集团按照基础数据编码规划填写数据准备表；

基础数据准备好后，在系统中录入数据，进行数据初始化。

1.5.6.2.5 测试应用系统

与XX报社集团协商，制定测试计划；

安排所有业务部门，进行测试及操作培训。

1.5.6.3 交付件

系统实施的交付件有《系统实施计划》、《系统管理员手册》、《用户操作手册》。

1.5.6.4 项目施工保证

按项目实施进度计划安排日程，要求所有实施人员掌握整个项目计划，明确每一个实施人员的权利及义务，对实施人员进行产品及技术培训。

实施《实施人员管理计划》，确保所有人员履行所属责任。每天准时到实施地点报到上班，并分配当天工作任务，在当天工作完后对当天的工作进行总结，并计划分配第二天的工作任务。

项目经理及技术骨干每天按项目实施标准及计划，定时巡视实施现场，确保项目进度如期进行及达到实施标准。如实施环境发生特殊情况，立刻通知项目经理，有需要时同时通知用户，以做出适当处理。

实施组每天应归纳工作中出现的所有问题，做出实施进度情况总结报告，并向负责人提交，并做到对文档资料的及时归档、建档。

项目经理批阅每天有关总结报告后，应快速做出回应，根据实际需要调动人员及调整实施计划，以确保项目的质量及进度。

项目组将按照以下两种方式向甲方提交书面项目进度报告：

1、于每月结束后五个工作日内提交；

2、按照约定的项目进度安排，于每一阶段工作完成后五个工作日内提交。

项目进度报告的内容包括：项目进度、已完成的开发项目、本项目的预期效果、人员配置情况，以及其他与本项目有关的甲方应当知道或其要求知道的情况。

系统实施中应注意：

n 坚持质量第一，确保规范实施；

n 按计划和方案组织实施；

n 严格执行标准实施安装程序和制定的相应技术规范和要求；

n 严格按照标准保证项目的质量，确保可靠性，安全性；

n 必须严肃工作纪律，各级实施人员都不得随意更改方案的内容，如因实施条件变化，方案难以执行，或方案内容不切合实际之处，应逐级上报，经变更确认后，方准执行新规定。

1.5.7 试运行与维护

1.5.7.1 概述

1.5.7.2 试运行与维护过程

1.5.7.2.1 模拟运行

初步测试后，业务部门进行并行操作模拟运行，并随时进行比较，确认系统有效。

1.5.7.2.2 正式运行

在确认基础数据正常后，与XX报社集团确定正式运行日期；录入相关单据，初始化系统。

1.5.7.2.3 问题反馈与改进

确定需作改进的问题，交付XX公司进行修改，XX公司根据问题汇总制定修改计划，并按时完成软件更新。

1.5.7.2.4 系统运行维护

系统需求变更或调整，记录变更原因和软件及源代码的版本控制，按照软件变更要求对系统进行维护。

1.5.7.3 交付件

系统试运行与维护的交付件有《系统试运行报告》。

1.6 进度管理

XX公司通过设定系列时间节点将项目划分成小的阶段管理，由于需要快速响应用户的需求，划分粒度会比里程碑小，均以完成某些功能模块为节点。

项目阶段情况汇报与计划：每周向甲方项目组、乙方管理部门提交项目报告（包括工作汇报、下周计划、存在的问题、需要协调解决的事项等）。

报告内容	频次	作者	收件人
项目周报	每周	XX公司项目经理	双方项目小组
			双方项目领导小组成员

每天进行计划进度与实际进度的比较，及时发现偏离，及时采取措施纠正或者预防；协调项目参与人员之间的进度关系。

每天检查项目小组和项目组成员的工作，并进行充分沟通和分析。

及时制定实施调整与补救措施。根据实际进度情况，对项目计划作必要的修正，使之符合变化的实际情况，以保证项目目标顺利实现。在项目延后时，及时安排项目组成员加班。

项目进度管理主要手段是以项目计划书作为项目进度控制的基准和依据。项目进度监控人员根据项目计划书对项目的阶段成果完成情况进行监控，如果由于某些原因阶段成果提前或延后完成，项目负责人应提前申请并做好开发计划的变更。对于项目进度延后的，应当分析产生进度延后的原因、确定纠正偏差的对策、采取纠正偏差的措施，在确定的期限内消除项目进度与项目计划之间的偏差。项目计划书应当根据项目的进展情况进行调整，以保证基准和依据的新鲜性、有效性。

1. 项目阶段情况汇报与计划，项目负责人按照预定的每个阶段点（根据项目的实际情况可以是每周、每双周、每月、每双月、每季、每旬等等）定期在与项目成员和其他相关人员充分沟通后，向相关管理人员和管理部门提交一份书面项目阶段工作汇报与计划，内容包括：

² 对上一阶段计划执行情况的描述

² 下一阶段的工作计划安排

² 已经解决的问题和遗留的问题

² 资源申请、需要协调的事情及其人员

² 其他需要处理的问题这些汇报将存档，作为对项目进行考核的重要材料。

2. 在计划制定时就要确定项目总进度目标与分进度目标,在项目进展的全过程中，进行计划进度与实际进度的比较，及时发现偏离，及时采取措施纠正或者预防；协调项目参与人员之间的进度关系。

3. 在项目计划执行中，做好这样几个方面的工作：检查并掌握项目实际进度信息。对反映实际进度的各种数据进行记载并作为检查和调整项目计划的依据，积累资料，总结分析，不断提高计划编制、项目管理、进度控制水平。

4. 做好项目计划执行中的检查与分析。通过检查，分析计划提前或拖后的主要原因。项目计划的定期检查是监督计划执行的最有效的方法。

及时制定实施调整与补救措施。调整的目的是根据实际进度情况，对项目计划作必要的修正，使之符合变化的实际情况，以保证项目目标其顺利实现。由于初期编制项目计划时考虑不周，或因其他原因需要增加某些工作时就需要重新调整项目计划中的网络逻辑，计算调整后的各时间参数、关键线路和工期。

1.7 质量管理

1.7.1 目的和依据

1.7.1.1 质量保障的目的

为保证系统能够充分满足用户的质量要求，使系统实现用户要求的功能，我们站在用户立场上来掌握产品质量，我们进行有计划、有组织的系统设计开发活动，依据有关国际国内标准，在需求分析、系统开发、系统测试、人员培训等方面为项目在预定时间内完成并达到用户要求提供保证措施。

1.7.1.2 质量保障的依据

CMM和ISO9000质量体系标准，这些标准已经转化为公司标准和规范，如：《六个统一管理规定》。

XX报社集团相关标准和规范。

其他相关技术标准。

1.7.2 项目质量保障框架

项目质量保障一直是国内应用软件建设项目的难点和软件工程的关注点。北京XX公司根据大量的项目经验，总结出了一套项目质量保障手段，形成了项目质量保障框架。

项目质量保障框架图

1.7.2.1 软件产品质量保障

为了确保软件质量，我们将从以下五个方面确保软件质量。

Ø 需求定位保障

需求调研的完整性与准确性是软件开发质量的首要保证。如果需求调研的结果不能正确反映用户的业务，或者不能全面反映用户的业务，那么后期的软件质量无需谈起。所以，北京XX公司总结经验，提出了严格把握需求质量的管理要求。具体工作包括：

n 需求调研工作必须在用户现场进行；

n 调研过程必须有严格的工作计划，包括与用户交流的时间安排；

n 调研过程中出现的业务问题、调研时间变更问题，必须要在当日反映到项目管理层，由管理层出面解决，并由管理层备案，必要时要反映给整个项目的决策层。

n 调研人员携带录音笔的同时，必须也要有笔记，当日材料当日整理。

n 调研过程中涉及到几个部门的复杂业务问题，必须以书面形式上报项目组长，由项目组长协调、落实解决。一时无法解决的问题，要作为重大业务问题，反映到XX报社集团党组办公会加以协调。

n 调研人员调研表格格式统一印制，但是调研前的调研准备情况，以及调研内容必须充实，项目质量组会对调研人员进行不定期抽查。

n 调研人员编写的《系统需求规格说明书》，必须经过北京XX公司组织的企业内部专家评审，通过后才能提交用户确认。

n 《系统需求规格说明书》必须经过确认，然后才能进入系统设计阶段。

Ø 软件编码质量保障

北京XX公司根据多年的软件开发经验，总结、开发了ResouceOne 软件组建架构，指在完成组建化开发体系。为此，在软件编码的规范上做了详尽的要求，具体体现在：

1) 编码风格上的要求，如类、变量、方法的命名规则。

2) 类定义的规范。

3) 编码注释规范。

4) 接口定义规范。

5) 组件定义规范

ResouceOne 软件组建架构拥有了自己的开发环境与编译环境，以确保规范的落实，提供自己的组件容器，以及组件管理与部署工具，以确保组件的可应用性。

Ø 软件测试质量保障

准确的说明，测试本身就是软件质量保障的重要手段。这包括我们通常所说的白盒测试与黑盒测试。我们组织专门的测试组来确保软件质量。

白盒测试主要是读码测试。我们采用交叉读码，小组讲码的方式进行。根据我们的经验，读码与讲码不仅可以发现软件编码问题，更可以实现细节沟通，优化编码结构，提升软件质量。组织读码与讲码，是公司尽一年来开发软环境建设的重要内容。

黑盒测试的测试方法：是由一些非编码人员根据《系统需求规格说明书》的要求对打包好的软件进行测试环境部署、模仿使用，以发现软件中的问题。黑盒测试包括安装测试、功能测试、组装测试、压力测试、集成环境测试五种。在该项目中，我们组织了专门的测试组来完成黑盒测试。另外，用户验收过程也是一个测试过程，是一个抽测过程。我们会为用户起草验收测试方案。

再有，为了确保测试本身质量得以加强，我们在测试过程中采取了以下手段来加强测试效果，确保测试质量。

1) 采用压力测试工具，发现系统得性能承受能力；

2) 采用测试软件管理整个测试环节；

3) 编写测试案例，规范测试行为，提高测试效率；

4) 编写测试大纲，加强测试组与开发组的沟通；

5) 平台测试，平台是公司已有产品，对平台的改动由独立的测试小组完成

我们的测试方案与测试用例对XX报社集团完全公开，并且需要经过XX报社集团或其委托人审批。测试中系统如有任何部分发生故障，则测试重新开始，整个系统需整体通过测试后才标志测试工作完成，最后提交测试报告。

Ø 软件部署质量保障

软件部署过程包括了系统环境搭建、应用软件安装、数据库搭建、初始数据建设、系统调优和全市联调六个环节。软件部署质量保障关键在于软件部署方案的设计与落实。为此，要有专门的文字材料，要经过总工程师的审阅与用户的认可。

软件部署方案将包括环境要求、建设步骤、参数设置、初始数据内容、以及准确的联调时间，以及联调内容。

Ø 软件应用质量保障

软件应用的效果也是这次项目建设成败一个很关键的工作。具体体现在下面几个方面。

软件应用治疗保障方法

应用效果控制	控制方法
培训质量	培训材料的准备、培训人员对培训内容的理解与掌握，培训口才，培训态度和培训时间
用户配合程度	组织专门的交流会、项目启用动员会，现场技术支持人员的讲解，考核机制
系统易用性	人性化的操作、图形化的界面、非变成化的定制、“拖曳”式的流程定义、手写笔、电子盖章等。

1.7.2.2 技术保障

技术保障包括技术人员数量保障、技术人员素质保障和技术人员培训与考试，因此，根据我们多年相关经验，提出了“六统一”思想。

Ø “六统一”介绍

以下引用自北京XX公司“六统一管理规定”：

为了规范公司软件项目的开发及提交管理，有效的利用项目资源和实现复用并且增强对项目从设计到开发以及交付各个阶段的把关，要实现六个统一：

l 统一文档管理

l 统一build管理

l 统一代码安全管理

l 统一设计review

l 统一代码review

l 统一软件出版管理

其中，统一的文档管理和代码安全管理，主要是通过统一的版本控制工具管理文档和代码的版本和内容；统一的build管理和软件出版管理，是通过统一build工具、过程规范来统一的build来源和软件出版的规范，对开发结果进行统一管理控制和发布；统一review设计和代码，是通过统一的代码和设计review提高开发质量和设计水平，主要包括两方面：第一，项目经理对开发人员代码的review和review后的指导；第二，公司组织对设计review，将设计高度从项目组设计高度提升到公司设计的高度，有效复用。

针对以上的要求，基础技术资源开发与管理部之前提交了一个适用于各个团队内部的项目管理规范：《管理规范》，涵盖了整个软件过程的三条线和八个点的详细管理办法。

三条线：【文档管理】、【源代码控制】、【提交物版本控制】

八个点：【需求】、【总体设计】、【技术设计】、【开发（code）】、【开发（build）】、【测试】、【实施】、【用户验证和使用性测试】

本实施规范站在更高的层面，在各个项目组及团队之间来约束和规定各项目，保证其最新提交物能够提交到公司。不同项目组可以在权限允许的情况下直接获取和参考其他项目的最新成果，并且公司可以集中优势技术资源来对各个项目的关键点进行指导和把关，避免技术方向失误及重复开发，同时也可以此为基础形成相关产品的复用。

Ø 实施“六统一”

1、基础环境

开发工具：R1 Bizfoundation V5.0

开发语言：Java

2、项目定岗信息

根据“六统一管理规定”填写下表：

项目定岗信息

岗位	姓名
总设计师
项目经理
测试经理
文档管理员
代码管理员
Build管理员

3、具体任务和分工

具体任务和分工表

任务	具体内容	责任人
源代码	版本管理环境搭建和维护
	建立和维护工程
	权限分配
	提交（含公司、客户）
	代码Review
文档	文档清单
	文档模版
	文档Review
Build	Ant脚本维护
	版本标签
	修改列表
	提交
测试	测试环境搭建和维护
	权限分配
	单元测试
	集成测试
	用户提交的Bug收集
	测试管理
部署	数据部署和维护
部署	应用部署

Ø 技术人员保障

北京XX公司为了提高所承接项目的质量，为了提高工作效率，在整个项目过程中对内部人员还要针对项目本身组织多次培训，确保每个项目参与人员能够高质量的完成本职工作。

n 项目背景与用户背景讲解。介绍用户的业务、组织，项目的定位、重心等内容，使整个项目团队能够宏观理解整个项目的价值和意义。从而提升团队的战斗协调性，提升团队的价值认同感。

n 需求分析讲解。根据需求调研与分析结果，给团队讲解项目的功能、流程，使各种技术人员都能够全面理解该系统，从而提高工作效率。

n 系统设计培训。根据系统设计结果，给整个团队讲解产品架构。

n 软件编码培训。讲解编码规则、平台关联点、重点注意事项、重点函数与主要API。

n 软件部署与调试培训。讲解部署方案，系统安装过程中的注意事项。

n 技术支持技巧培训。结合XX报社集团的实际情况，给现场运行维护人员、技术支持人员进行业务、技巧培训，做到“人对人贴身服务”。

Ø 开发、测试、管理工具

系统开发工具：

1、Eclipse。是使用最普遍的，最有发展前景的J2EE开发平台软件。

2、Power Designer。是业界数据库建模的最好工具之一。

3、Rational Rose。是业界最好的面向对象的设计工具包。

系统主要工具：

1、Load Runner。是一个强大有力的压力测试工具。它的脚本可以录制生成，自动关联；测试场景可以面向指标，多方监控；测试结果图表显示，拆分组合。主要用来找到系统的性能瓶颈。

2、TestDirector。本项目采用业界流行的测试管理工具-TD辅助进行测试管理。该工具提供了以下主要功能：需求管理、缺陷管理、测试计划管理。

项目管理工具：

采用企业级项目管理方案Microsoft Enterprise Project Management Solution，进行项目进度、人力资源方面的管理，为项目的负责人提供一个全局化的视角，为各部门负责人及项目组成员提供企业级协作平台。

1.7.3 项目质量控制

质量管理控制主要是监督项目执行各阶段的结果，将阶段结果与事先制定的质量标准进行比较，找出其存在的差距，并分析形成这一差距的原因，质量控制同样贯穿于项目管理的全过程。

为了保证项目质量，按项目事前质量控制、事中质量控制、事后质量控制三个阶段进行划分，有关项目质量管理的具体控制措施如下：

1）项目事前质量控制：是指在项目实施前所进行的质量控制，其控制的重点是做好项目的准备工作。主要工作内容有：

n 组织准备：建立项目组织机构及质量保证机制，对项目级成员进行有关项目质量管理方面的培训，使其提高其质量意识和素质，并将项目质量实现岗位责任制；

n 计划制订：制定好各种计划是事前质量控制的重要手段。

项目质量控制表

软件开发阶段	软件开发活动	质量保证活动	活动时间
启动	软件开发计划	计划评审	在生命周期目标里程碑之前和准备期间
	质量保证 (QA) 计划	计划评审	在生命周期目标里程碑之前和准备期间
	风险管理计划	计划评审	在生命周期目标里程碑之前和准备期间
	评测计划	计划评审	在生命周期目标里程碑之前和准备期间
	问题解决计划	计划评审	在生命周期目标里程碑之前和准备期间
	产品验收计划	计划评审	在生命周期目标里程碑之前和准备期间
	。。。。。

n 工具准备：根据项目上有关相关工具的要求，准备各种支持工具；

2）事中质量控制：是指在项目开发和实施过程中所进行的的全面质量控制。

n 阶段评审：按照项目质量保证计划对项目各阶段的成果进行评审，及时发现问题，保证各阶段成果的质量；

n 系统测试：做好系统单元测试、集成测试、性能测试，确保实施过程顺利；

n 项目变更管理：明确项目变更流程，严格控制项目范围的变更；

3）事后质量控制：当项目实施完处于待交接状态时，则需做好质量验收评定与项目转移工作。其项目事后质量控制的重点包括但不限于：

n 质量检查、验收及评定：与客户就服务期内的项目质量进行总体的质量检查、验收与评定；

n 知识转移：针对服务期内的项目实施情况进行总结，并及时移交至客户。

此外，公司接受XX报社集团指定的监理公司对本项目进行监督和管理，接受监理的监督、协调。监理公司按照与XX报社集团签订的监理合同履行监理职责。

1.7.4 项目质量改进

XX公司提交的XX报社集成信息门户项目保证符合招标文件内容，针对在建设过程中出现的质量瑕疵将按照与客户沟通的结果进行改进，由此发生的费用由XX公司承担。

（1）质量改进应坚持全面质量管理的PDCA循环方法。随着质量管理循环的不停进行，原有的问题解决了，新的问题又产生了，问题不断产生而又不断被解决，如此循环不止，每一次循环都把质量管理活动推向一个新的高度。

（2）坚持“三全”管理：“全过程”质量管理指的就是在产品质量形成全过程中，把可以影响工程质量的环节和因素控制起来；“全员”质量管理就是上至项目经理下至一般员工，全体人员行动起来参加质量管理；“全面质量管理”就是要对项目各方面的工作质量进行管理。这个任务不仅由质量管理部门来承担，而且项目的各部门都要参加。

（3）质量改进要运用先进的管理办法、专业技术和数理统计方法。

1.7.5 质量控制的流程

为了高效率、高质量的完成本系统，我方将按以下要点进行控制：

质量控制节点

项目实施阶段

检查项目

需求分析

↓

功能设计

↓

实施计划

↓

开发目的

目标值

开发量（程序、文档）

所需资源

各阶段的产品与作业内容

开发体制

设计

结构设计

↓

数据设计

↓

过程设计

↓

评审量

差错数

捡出差错的内容

评审方法

出错原因、处理及影响

实现

程序编制

↓

单元测试

↓

集成测试

↓

用户测试

产品量（计划量、实际量），目标值完成情况

评审量

检出的差错

出错原因、处理情况及对该阶段的影响

测试环境、测试项目设定、测试用例设计

验收与运行维护

检查、评价

↓

运行、维护

用户文档资料检查；

程序检查（验收测试）

用户使用情况及意见

1.8 项目监控检查

在项目进度管理和质量管理章节中，分别详细介绍了对进度和质量的控制措施，本节重点从管理和交付物的角度进行阐述对项目的监控检查。

1.8.1 管理监控

管理控制涉及项目活动的所有方面，控制活动以会议等方式进行。会议类型包括：

n 项目启动会议：给项目提供一个良好开端，以确保清楚地定义、公布和理解重要词汇的含义（如参照、目标、调整、计划和组织等），并达成一致。

n 月/周进度会议：由项目经理汇报项目当前状况，并提供一个机会让项目指导委员会解决那些项目经理无法解决的项目相关问题，以便及时解决；会议召开的频度由双方决定。

n 里程碑会议：在项目的里程碑节点，由项目经理汇报项目进度和质量状况及存在的影响进度和项目质量的重大问题，由相关负责人协调解决存在的问题。

n 交付物评审会议：项目经理和业务领域专家、技术专家等相关人员一起检查相关交付物，确认项目的技术和业务问题，并按需要采取相应的措施。

n 收尾评估会议：在每个实施阶段的收尾部分进行。

n 开发结项会议：这是开发项目组的最后一个会议，用来确认并接受新开发的系统，并正式宣布本项目的开发阶段结束。

1.8.2 交付物监控

质量和技术监控主要针对特定阶段提交的交付物，而不是针对整个阶段的产品结果。目的是为了在开发阶段尽可能早的确认并改正错误。它通常采用下面控制机制：

n 质量抽查：是指技术、质量保证及用户的相关人员对交付物进行检查，确定它已经完成并符合质量标准和相关的用户需求。

n 变更控制：一个变更是指与一个或多个交付物相关的并且事先未知的需求改变。它需要被记录并应采取适当措施加以控制以防变化扩大化。

n 软件配置管理：提供一个正式的机制用来对交付物进行标记和归档，跟踪开发状态及它们之间的关系。

n 缺陷管理：缺陷是指已被认为正式通过后，发现交付物技术上有异常问题。它需被记录及改正以保持交付产品的完整性。

1.9 项目变更管理

1.9.1 项目需求变更

需求变更管理是组织、控制和文档化需求的系统方法，也是一种建立和维护用户和开发组织对于改变系统功能的协议。需求开发的结果经验证批准就定义了开发工作的需求基线,这个基线在客户和开发人员之间就构筑了一个需求约定，需求管理包括在项目进展过程中维持需求约定一致性和精确性的活动。现在很多商业化的需求管理工具都能很好的支持需求管理活动。这个活动需要完成下面几个任务：

1、确定变更控制过程,确定一个选择、分析和决策需求变更的过程,所有的需求变更都需遵循此流程；

2、建立软件变更控制委员会(SCCB，Software Change Control Board),组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来评估和确定需求变更；

3、进行变更影响分析,评估需求变更对项目进度、资源、工作量和项目范围以及其它需求的影响；

4、跟踪变更影响的产品,当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计文档、源代码和测试用例，这些相关部分可能也需要修改；

5、建立基准和控制版本,需求文档确定一个基线，这是一致性需求在特定时刻的快照，之后的需求变更就遵循变更控制过程即可；

6、维护变更的历史记录,记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等情况；

7、跟踪每项需求的状态,这里状态包括"确定"、"已实现"、"暂缓"、"新增"、"变更"　等。建立一个数据库，其中每一条记录记录一项需求；

8、衡量需求稳定性,记录基线需求的数量和每周或每月的变更(添加、修改、删除)数量。

1.9.2 项目进度变更

由于需求变更、硬件设备到货延迟、资源短缺等原因，可能超出进度安排限度，导致项目进度变更。为避免项目进度变更带来的风险，应加强监控，尽早发现问题，明确项目变更流程，严格控制项目范围的变更，避免后期的变更造成项目成本的大幅提高。

对于调研过程中出现调研时间变更问题，必须要在当日反映到项目管理层，由管理层出面解决，并由管理层备案，必要时要反映给整个项目的决策层。

1.10 项目风险管理

风险管理是指为了最好地达到项目的目标，识别、分配、应对项目生命周期内风险的科学与艺术。项目风险涉及到对问题的理解：项目中可能发生的潜在问题，以及它们如何防碍项目的成功。

风险在字典中的解释是“损失或伤害的可能性”，一般人们对风险的理解是“可能发生的问题”。风险与许多事物都有关联，例如，一个已经投入使用的存有易燃品的仓库，随时会有发生火灾的风险。一个建设中的项目也会面临许多不确定性的风险。风险就像“隐形杀手”一样，不知什么时候会出现。无论人们是否喜欢，风险是不以人的意志为转移的。但这并不意味着风险是无法避免的。比如，人们为了避免“患上重大疾病”，平时会积极参加各种健身活动，增强体质，提高防病能力。可以说，风险的存在要求人们要积极面对风险，做到有备无患，才能将风险的影响减到最小。

在许多方面，风险管理像保险的一种形式。它是为减轻潜在的不利事件对项目的影响而采取的一项活动。

1.10.1 风险管理方法

我司根据多年的项目实施经验，总结了一整套风险管理的方法，包括从哪里找风险，怎么分析风险和如何应对风险。我们的具体做法是：

首先，在思想上保持持续不断的风险意识，积极识别各种风险，但不是事无巨细处处设防。作为项目管理人员应该清楚的认识到，项目从一开始的很多东西，比如项目建议书、可行性报告或项目计划就都是在若干假设、前提、预测的基础上完成的，这些假设、前提、预测在项目实施期间有可能成立，也有可能不成立，而这其中隐藏的问题都会为项目带来风险。

其次，从宏观和项目内部两个方面找出风险的来源。首先在宏观方面，我们从项目周期、控制过程、团队安排和人员技能等方面找出潜在的问题，并采取相应的措施规避项目风险；其次在项目内部，我们以工作分解结构图（WBS）的每个阶段成果作为风险分析的对象，从风险来源——技术性风险、协调性风险（即政企之间形成的矛盾）和执行过程产生的风险，并且结合我们公司多年的经验与教训找出潜在的危害，然后运用概率、分布频率、平均数众数和头脑风暴法等技术手段进行风险的分析和量化，然后制订教育培训、严格执行公司各项规章与规范等相应的措施来规避风险。

第三，不断的进行项目风险分析。随着项目的进展，已识别出的项目干系人的风险逐渐减小，但是未识别的项目干系人的风险却越来越大，而且还有其他预想不到的情况，新情况的出现都会导致新风险的产生。因此我们在项目的实施过程中不断地进行风险分析，以便使之细化。

最后，将风险管理的计划、行动、结果进行整理、汇总和分析，形成风险管理报告，为项目的实施、控制、管理、决策提供信息基础。

1.10.2 风险识别

它是管理风险的第一步，即识别整个项目过程中可能存在的风险。一般是根据项目的性质，从潜在的事件及其产生的后果和潜在的后果及其产生的原因来检查风险。收集、整理项目可能的风险并充分征求各方意见就形成项目的风险列表。

识别风险是理解某特定项目有哪些可能令人不满意的结果的过程。通过理解风险的可能来源，你就可以进一步通过检查表、流程图或访谈等手段，来识别风险。识别风险来源可以帮助识别项目上的可能风险事件与风险症状。

风险识别的常用方法是建立潜在损失一览表。

风险识别的方法：

1、问询法（头脑风暴法、面谈法和德尔菲法等）；

2、财务报表法（各种财务报表和记录）；

3、流程图法（网络图或WBS法）；

4、现场观察；

5、历史资料（索赔记录及其他风险信息）；

6、环境分析法（相关方和社会环境变化趋势，可能变更的法律法规）等。

1.10.3 风险类型

针对本项目，可能产生的风险类型包括：

1、进度延期：由于需求变更、硬件设备到货延迟、资源短缺等原因，可能超出进度安排限度，导致项目进度拖延的风险。

2、管理风险：主要来源于项目人员的组织有效性，项目时间、资源的计划确定性和可控性，以及项目质量监控的力度和立场。

3、多厂家协调：本项目接口，存在多厂家协调的工作，处理不好可能造成互相推卸责任，最终影响项目不能按时交付。

1.10.4 风险分析

确定了项目的风险列表之后，接下来就可以进行风险分析了。风险分析的目的是确定每个风险对项目的影响大小，一般是对已经识别出来的项目风险进行量化估计，这里要注意三个概念：

（1）风险影响：它是指一旦风险发生可能对项目造成的影响大小。如果损失的大小不容易直接估计，可以将损失分解为更小部分再评估它们。风险影响可用相对数值表示，建议将损失大小折算成对计划影响的时间表示。

（2）风险概率：它是风险发生可能性的百分比表示，是一种主观判断。

（3）风险值：它是评估风险的重要参数。“风险值”=“风险概率”×“风险影响”。如：某一风险概率是25%，一旦发生会导致项目计划延长4周，因而，风险值=25%×4周=1周。

1.10.5 风险应对计划编制

完成了风险分析后，就已经确定了项目中存在的风险以及它们发生的可能性和对项目的风险冲击，并可排出风险的优先级。此后就可以根据风险性质和项目对风险的承受能力制定相应的防范计划，即风险应对。制定风险应对策略主要考虑以下四个方面的因素：可规避性、可转移性、可缓解性、可接受性。风险的应对策略在某种程度上决定了采用什么样的项目开发方案。对于应“规避”或“转移”的风险在项目策略与计划时必须加以考虑。

确定风险的应对策略后，就可编制风险应对计划，它主要包括：已识别的风险及其描述、风险发生的概率、风险应对的责任人、风险对应策略及行动计划、应急计划等等。应对风险的三大项基本措施分别为：规避、接受和减轻。风险应对计划制定过程的重要输出包括：风险管理计划、应急计划和应急储备。

1.10.5.1 风险规避

涉及根除某一具体的威胁或风险，通常采用根除其原因的方法。当然所有的风险都是不能根除的，但具体的风险事件可以。

1.10.5.2 风险接收

是指如果风险发生，接受其带来的后果。例如：项目团队在计划一个大型项目审查会议，如果某特定会议场所得不到批准，那么他们会使用一项应急或后备计划，来积极地应对风险。另一方面，他们也可能采用消极的手段，接受组织提供给他们的任何会议设施。

1.10.5.3 风险减轻

通过减少风险事件发生的概率来减轻风险事件的影响。例如：招募胜任的项目管理人员、使用各种分析和验证技术等。

1.10.5.4 应急方案

应急方案是指一项已识别的风险事件发生时，项目团队将采用预先确定的措施。

Ø 应急策略

1、人力保障

公司专门成立领导小组，当重大故障无法预期处理完成时，以组织保障更多资源的投入到处理中。领导小组成员表：

人力保障表

姓名	职务	电话	R-mail
黄海军	总监	13801066091	huanghj@chinasofti.com
崔海鹰	总监	13911556411	cuihaiying@chinasofti.com

2、流程保障

图3. 150 重大故障告知流程

当出现重大故障时，现场服务小组若在1小时内无法解决故障，则通知项目经理以寻求更多资源解决故障；当故障2小时内无法得到有效解决时，项目经理通知服务总监理以协调更多资源解决故障；当故障在3小时内未消除时，服务总监联系领导小组以寻求更多资源，直到故障有效解决。

Ø 硬件类故障应急

发生核心设备硬件故障后，现场服务小组立即确定故障设备及故障原因，并进行先期处置，若故障设备在短时间内无法修复，启动备用设备，保持系统正常运行。故障排除后，在网络空闲时期，替换备用设备；若故障在规定时间内仍然无法排除，立即联系技术支持专家小组寻求解决，若故障仍然无法排除，则按照重大故障告知流程通知相关人员，寻求更多的资源进行解决，最终将故障排除，恢复业务。

当发生设备被盗或有人为损害设备情况时，现场服务小组立即报告客户和现场服务经理或高级服务经理，同时保护好现场。现场服务经理或高级服务经理接报后，通知安全保卫部门及公安部门，一同核实审定现场情况，清点被盗物资或盘查人为损害情况，做好必要的影像记录和文字记录。事件当事人应当积极配合公安部门进行调查，并将有关情况向应急领导小组汇报。现场服务经理或高级服务经理召开会议研讨进一步处理的决策。

Ø 软件类故障应急

发生服务器软件系统故障后，立即启动备份服务器系统，由备份服务器接管业务应用。现场服务小组将故障服务器脱离网络，保存系统状态不变，取出系统镜像备份磁盘，保持原始数据。在确认安全的情况下，重新启动故障服务器系统，重启系统成功，则检查数据丢失情况，利用备份数据恢复；若重启失败，立即联系技术支持专家小组或寻求相关厂商支援，作好技术处理。

系统恢复正常后，在业务间歇时间替换备用设备。

Ø 网络中断与病毒防护

当发生网络中断、路由故障、流量异常、域名系统故障后，现场服务小组应及时通知客户，并及时查清通信网络故障位置，查清原因，同时，隔离故障区域，切断故障区与服务器的网络联接。检测故障区域，逐步恢复故障区与服务器的网络联接，恢复通信网络，保证正常运转。

当发现病毒时，现场服务小组应立即告知客户，在客户允许的情况下断开网线，终止不良信息或网络病毒传播。通告局域网内所有计算机客户防病毒方法，隔离网络，进行杀毒处理，直至网络处于安全状态。

当发现网络被非法入侵、网页内容被篡改，应用服务器上的数据被非法拷贝、修改、删除，或通过入侵检测系统发现有黑客正在进行攻击时，现场服务小组应断开网络，并立即报告客户。在客户允许的情况下，立即关闭服务器或系统，修改防火墙和路由器的过滤规则，封锁或删除被攻破的登陆帐号，阻断可疑客户进入网络的通道。及时清理系统、恢复数据、程序，将系统和网络恢复正常；情况严重的，立即上报现场服务经理或高级服务经理，并联系技术支持专家小组或寻求相关厂商支援，使得网络在最短时间内恢复健康。

Ø 环境类故障应急

发生环境类故障后，现场服务小组在第一时间内通知客户和现场服务经理或高级服务经理，并开展先期处置，及时消除故障。

应急处置工作结束后，现场服务经理或高级服务经理与客户代表组成事件调查组，对事件发生原因、性质、影响、后果、责任及应急处置能力、恢复重建等问题进行全面调查评估，根据应急处置中暴露出的管理、协调和技术问题，改进和完善预案，实施针对性演练，总结经验教训，整改存在隐患组织，恢复正常工作秩序。

Ø 应急演练

现场服务小组每年至少安排一次演练，建立应急预案定期演练制度。通过演练，发现应急工作体系和工作机制存在的问题，不断完善应急预案，提高应急处置能力。

1.10.5.5 应急储备

应急储备是项目发起人为了应付项目范围或质量上可能发生的变更而持有的预备资金。它可用来转移成本风险或进度风险。例如：如果项目因为员工不熟悉一些新技术而导致其偏离既定的轨道，那么项目发起人会从应急储备中提出额外的资金，来聘请公司外的咨询师，培训和指导项目人员采用新技术。

1.10.6 风险应对控制

风险应对控制包括执行风险管理过程和风险管理计划，以应对风险事件。制定了风险防范计划后，风险并非不存在，在项目推进过程中还可能会增大或者衰退。因此，在项目执行过程中，需要时刻监督风险的发展与变化情况，并确定随着某些风险的消失而带来的新的风险。

风险监控包括两个层面的工作：其一是跟踪已识别风险的发展变化情况，包括在整个项目周期内，风险产生的条件和导致的后果变化，衡量风险减缓计划需求。其二是根据风险的变化情况及时调整风险应对计划，并对已发生的风险及其产生的遗留风险和新增风险及时识别、分析，并采取适当的应对措施。对于已发生过和已解决的风险也应及时从风险监控列表调整出去。

最有效的风险监控工具之一就是“前10个风险列表”，它是一种简便易行的风险监控活动，是按“风险值”大小将项目的前10个风险作为控制对象，密切监控项目的前10个风险。每次风险检查后，形成新的“前10个风险列表”。

1.10.7 风险应对措施

针对如上的风险分析，我们提出下面的应对措施：

1、针对进度延期风险的应对：项目经理会严格根据项目执行进度安排各项工作，能根据项目进度安排与厂商的协调工作以及设备到货时间，防止进度拖延现象发生。

2、针对管理风险的应对：首先，加强领导与协调，统一思想，取得对整个项目目标的一致认识，认识到本项目建设的重要性及对未来的深远影响。其次，由用户方选派一名客户代表专门负责进行项目相关的事情。第三，每周召开项目例会，由用户审核需求分析等文档。第四，定期通报项目进展情况，每个阶段的可交付物一定要有用户签收，方可进入下一阶段。第五，要求我们的工作人员经常与用户进行沟通交流，友好相处。

3、针对多厂家协调的应对：单位主管领导大力支持，协助加强各厂商的沟通与协调，统一思想，取得对项目目标的一致认识，支持项目实施过程中各项工作的开展。

1.11 项目沟通管理

沟通管理是项目管理中非常重要的工作，项目经理在项目沟通中起到非常重要的作用。本项目实施过程中的会议分为例会、专题讨论会、协调会及专家评审会等。在本项目中，我们建立以下正式沟通计划，并在工作中保证实现：

类型	沟通内容	参与人员	责任人	时间
项目组首次会议	培训项目管理方法、实施计划	项目组全体成员	项目经理	待定
项目动员大会	明确目标、落实责任、激发热情	全体成员	项目发起人	待定
项目管理例会	分析项目状态，明确	项目管理委员会	项目经理	每月末
阶段评估会议	评估项目阶段的完成情况	项目管理委员会	项目经理	阶段末
项目验收会议	评审项目验收标准的完成	项目委员会	项目经理	项目收尾时
项目组工作例会	汇报各项工作的进度及问题	项目经理	业务组长	每周一
项目变更会议	决议变更需求	项目管理委员会	项目经理	变更产生时
项目通讯	对外宣传项目状况	项目组全体成员	项目管理办公室	每月
项目信息共享	了解项目状态、计划、问题等	项目组全体成员	实施组长	随时
操作状况	了解用户的操作状况	项目成员	最终用户	上线后每日

另外，在项目的实施与运维工作中，有一些沟通属于非正式沟通，例如聚会、交心谈话、技术研讨、能力拓展等，我们会根据项目的需要选择进行。

沟通内容

项目利益相关者之间的信息沟通与交流集中在如下方面：

1）与计划相比，项目工作量完成情况。

2）已完成的工作质量情况。

3）与计划相比，进度情况。

4）与计划相比，实际成本支出情况。

5）项目执行到现在，出现的问题，这些问题的解决方案以及建议采用的方案。

报告形式

1）报告应尽量使用数据、表格、图形等方式，避免纯文字上的长篇大论，例如在作进度情况报告时，常用甘特图、网络图、时间线以及里程碑表等。

2）报告费用情况时，常用直方图、S曲线以及开支表等。

3）报告人员使用情况时，常用直方图、工作负荷分配表等。

1.12 项目交付成果（技术资料和文件）

1.12.1 技术资料和文件要求

XX公司承诺完全满足以下技术资料和文件要求：

一、总则

1. 合同签定完后，XX公司提供一份项目任务书。

2. 项目实施完后，XX公司提供一套完整的项目实施过程中所有涉及到的文档和程序（包括电子版）等。

二、文档范围

1. XX公司提供的文档包括方案、系统技术资料、维护手册、培训资料、项目所需的软件文档和用户手册、联络会议记要、验收报告等。

2. XX公司提供每次维护（包括硬件及软件）的维护报告及技术文档。

三、XX公司的责任

XX公司对所提供的全部文档的准确性和完整性负责。

四、技术文档及相关规范

XX公司承诺提供以下文档（所有文档提供电子文档一份）：

1.《XX报社集成信息门户项目系统需求分析文档》

2.《XX报社集成信息门户项目系统实施文档》

3.《XX报社集成信息门户项目实施工作任务书》

4.《XX报社集成信息门户项目部署手册》

5.《XX报社集成信息门户项目管理员维护手册》

6.《XX报社集成信息门户项目用户操作手册》

7.《XX报社集成信息门户项目培训手册》

8.《XX报社集成信息门户项目工作报告》

1.12.2 项目建设各阶段提交成果

项目建设的各阶段会产生相应的成果，具体见下表：

项目交付物清单

序号	阶段	交付成果名称	交付形式
1	项目启动	《项目任务书》、《项目总体计划》	以纸张和光盘为载体
2	需求分析	《需求规格说明书》	以纸张和光盘为载体
3	系统设计	《系统设计说明书》	以纸张和光盘为载体
4	系统开发	源代码、《配置管理报告》	以纸张和光盘为载体
5	系统测试	源代码、《测试计划》和《测试报告》	以纸张和光盘为载体
6	安装调试	《系统部署手册》、《用户操作手册》《管理员维护手册》	以纸张和光盘为载体
7	系统初验	《系统初验报告》、《初验文档》	以纸张和光盘为载体
8	系统上线试运行	《系统运行报告》、《培训手册》、《项目实施工作任务书》	以纸张和光盘为载体
9	系统终验	《终验报告》、《终验文档》	以纸张和光盘为载体
10	运维服务	《服务日志》、《系统运行报告》	以纸张和光盘为载体
11	项目整个过程	《项目工作报告》（月度、流程被）	以纸张和光盘为载体

1.13 项目验收

项目验收，是整个项目生命周期中最后一个环节。一般来说，软件项目的验收一般来说有2个阶段，第一个阶段是验收测试，当验收测试成功结束后，一般会有一个阶段的试运行阶段，只有当 2个阶段全部结束后，整个项目才算真正结束，该软件也进入其运行维护期。验收测试应按照软件的需求，质量要求进行测试验收，需要甲乙双方共同建立验收小组，或请第三方测试机构进行验收测试，在验收测试之前，开发方应提供一系列的开发设计文档供验收测试使用。

1、验收工作准备，按要求整理项目成果物，打印装订成册，并提交客户方。

2、系统主要使用部门及信息技术部门联合成立项目验收小组，从需求功能及技术需求层面对系统进行综合评估和项目成果物的审核，根据验收情况形成系统验收报告

3、应用部门及信息技术部门负责人根据系统试运行情况签署验收意见。

1.13.1 验收综述

本项目的验收包括系统的初步验收和最终验收。XX公司在每一个验收过程中制定了标准的验收流程，每个步骤都需要进行自验。自验的标准除去常规的技术、业务、需求等要求外，我们还将遵从多年从事项目建设的经验总结出来的工程项目验收评价标准。在每个验收的阶段，我们都会从评审前、评审中和评审后三个阶段进行工作内容的准备。

系统的验收贯彻项目的全过程，对于过程中的重要提交物我们将根据实际情况将进行正式和非正式的评审活动，以便于从项目过程中就确保项目质量，确保项目验收的顺利进行。

1.13.2 验收组织

项目办、专家、用户代表和承建商组成评审委员会进行验收，对评审过程进行指导，并对验收结果进行决议。

项目办负责监督系统开发工作，用户代表负责对应用系统进行试用，项目管理文档和用户使用报告都将作为业主单位对应用系统开发工作验收的重要依据。

我们通过对多个全国性大型工程项目的成功实施验收经验的总结，验收工作的特点，力图从以下三个角度阐述清楚验收的工作内容：

为了指导系统验收工作的顺利进行，验收工作可以划分为验收前、验收中、验收后三个环节，围绕这三个环节工作内容安排如下图所示：

验收环节图

上图也是指导验收工作开展的方法之一，系统验收工作的具体内容如下：

验收前：

1）确定验收方式与周期：

Ø 验收方式包含：召开专家验收会议；用户现场测试等。

Ø 制定每一阶段的验收周期。

2）评审参与单位及确认人：行业用户，专家组，监理。

3）准备提交物（含标准技术规范）：确定各验收阶段的提交物名称和内容。

4）准备验收标准：准备项目验收的评价指标和各阶段验收具体工作的验收要点。

验收中：

1）提交物验收（含标准技术规范）：主要是根据验收的评价指标严格评审提交物的质量。

2）应用系统建设效果验收：主要从应用系统比对合同内容功能和应用系统的部署效果两个方面考察应用系统建设效果。

3）用户使用效果：主要以《用户对系统满意度综合评价报告》和《用户对服务满意度综合评价报告》作为验收工作的参照物考察用户使用效果。

4）验收状态：通过、整改。

验收后：

1）提交物完善：根据验收小组的验收结论，对相应提交物及时完善并提交，视具体情况决定是否再次组织验收会议。

2）验收方案的调整细化：根据项目的整体建设情况，可以对验收方案做出合理的细化工作。

3）确定下一步工作计划：主要指在通过一阶段验收后，承建商必须确定下一步的实施工作内容，验收小组也必须确定下一步验收工作的计划和内容。

1.13.3 验收步骤

1.提出验收申请

根据每个阶段的验收要求，在自验通过后需要由系统承建商提出验收申请，经甲方批准后，方可启动评估。

2.启动验收评估

对于每一个验收阶段，验收前都需要进行验收准备工作，确定验收方法，验收范围，验收标准，细化验收方案等。

3.确定验收涉众

启动验收后，需要细化哪些组织、人员需要参与到验收工作中，需要定义验收组织中的基本角色和各自的职责。

其中，需要确定关键人员是否需要全职进行评估工作，并保证全体参与人员能够正确全面地理解评估流程。

参与评估人员一般包括：

Ø 评估方：1）业务骨干；2）技术骨干

Ø 监理方：1）项目经理；

Ø 专家组：1）技术专家；2）业务专家

Ø 被评估方：1）业务人员；2）项目经理；3）项目架构师；4）开发人员；5）测试人员；6）管理维护人员。

4.评估、验收

由验收人员根据验收方法、验收原则和验收方案对评估范围内的项目进行评估，并对评估结果进行记录和分析。

5.做出验收结论

根据评估结果，确认本次评估是否通过，并对通过／未通过的原因进行总结，做出评估报告。验收结果分为：验收通过、整改两种。符合信息化项目建设标准、系统运行安全可靠、任务按期保质完成、经费使用合理的，视为验收合格；由于提供材料不详难以判断，或目标任务完成不足80%而又难以确定其原因等导致验收结论争议较大的，视为不通过，需要整改。

1）项目凡具有下列情况之一的，按验收不合格处理：

Ø 未按项目考核指标或合同要求达到所预定的主要技术指标的；

Ø 所提供的验收材料不齐全或不真实的；

Ø 项目的内容、目标或技术路线等已进行了较大调整，但未曾得到相关单位认可的；

Ø 实施过程中出现重大问题，尚未解决和做出说明，或项目实施过程及结果等存在纠纷尚未解决的；

Ø 没有对系统或设备进行试运行，或者试运行不合格；

Ø 违反法律、法规的其他行为。

2）验收结论确认和处理

由项目验收组根据验收意见和相关资料得出结论，形成书面意见，提请监理公司审查，并经甲方确认。

3）项目验收结论的处理

Ø 验收结论为验收合格的，承建方将全部验收材料统一装订成册并连同相应的电子文档，正式提交甲方存档。

Ø 验收结论为验收不合格的，要求限期整改，整改后试运行合格的，重新申请验收。

6.项目交接与持续改进

对于通过验收的项目，承建方需要将相关文档、规范以及其他内容等正式提交用户方。

1.13.4 验收内容

验收范围涵盖系统中的各项建设内容。

1.项目调研与需求管理阶段

相关提交物：《系统需求规格说明书》、《项目进度计划》

评审内容：《系统需求规格说明书》

2．系统设计阶段

相关提交物：《系统概要设计说明书》、《系统详细设计说明书》

评审内容：《系统概要设计说明书》、《系统详细设计说明书》

3．软件测试阶段

相关提交物：《系统测试报告》

验收内容：系统初验，验收系统的部署运行情况

4．试运行及终验

相关提交物：《试运行总结报告》、《系统用户手册》、《系统安装手册》、《项目总结报告》及前期各阶段的提交物

验收内容：项目终验，验收系统的整体运行情况

1.13.5 验收标准

1）软件文档

项目	子项目	项目说明
完整性	标识指示	用户文档具有唯一的文档标识，版本的变更要有标准的权限及审批流程
	要求系统	用户文档应明确说明该软件的运行环境
	功能说明	程序中用户可调用的所有功能，都应在用户使用手册中加以完整的描述
	使用手册	用户文档应包含产品使用所需的信息，包括操作说明、安装手册。
正确性	表达正确性	用户文档中所有信息应是正确的，没有歧义和错误的表达
一致性	内容一致	用户文档自身或相互之间不应相互矛盾。
易浏览性	目录索引	用户文档应有目录表或索引表。

2）功能

项目	子项目	项目说明
适合性	功能的充分性	所有测试的功能都应都能正确执行
	功能实现的完整性	程序中应包括需求规格说明中描述的所有功能
	功能实现的覆盖率	需求规格说明中描述的所有功能应都能正确实现
准确性	预期的准确性	针对特定任务设计的测试用例应都能得到合理的预期结果。
	计算的准确性	程序中所有计算的结果应准确无误。
	精度	程序应能按要求的交换格式与其他软件或系统成功进行数据交换。
互操作性	数据的可交换性（基于数据格式）	程序与其他软件或系统每次进行数据交换应都能成功执行。
互操作性	数据的可交换性（基于用户成功尝试）	程序应对所有用户访问系统和数据的操作进行记录。

3）可靠性

项目	子项目	项目说明
成熟性	针对测试用例的失效密度	针对测试需求设计的测试用例的执行都不应引起软件失效。
	故障密度	针对测试需求设计的测试用例的执行都不应引起故障。
	测试覆盖率	针对测试需求设计的测试用例应都能执行。
	测试的成熟性	针对测试需求设计的测试用例应都能成功执行。
容错性	避免死机	在测试过程中，不应出现死机现象。
	避免失效	在测试过程中，不应出现由于软件的故障而导致系统失效的现象。
	抵御误操作	程序应对非法输入或非法的操作模式进行屏蔽处理。

4）易用性

项目	子项目	项目说明
易理解性	描述的完整性	产品功能描述应完整。
	明显的功能	程序界面中所有的功能应易于识别。
	功能的易理解性	程序中所有界面对应的功能应易于理解。
	易理解的输入输出	程序界面中所有的输入输出项应易于理解
易操作性	使用中错误的纠正	在使用软件过程中，用户应能成功撤销其错误操作。
	在使用中功能操作的一致性	程序中功能操作界面的组成应保持一致。
	在使用中消息的一致性	程序中提示的信息应易于指导用户操作。
	使用中默认值的可用性	程序应提供参数值的默认值以方便用户使用。
	使用中消息的可理解性	程序中的提示信息不应导致用户操作停顿与失败。
	在使用中操作错误的易恢复性	程序应对关键数据的操作给出警告或在执行前要求确认。
	（用户错误纠正的）可还原性	程序应提供关键操作的可逆处理，以便用户纠正错误。

5）效率

项目	子项目	项目说明
时间特性	响应时间	获得结果的时间应不大于需求中要求的响应时间。

6）维护性

项目	子项目	项目说明
易分析性	审核追踪能力	程序应记录用户的关键操作，并确保记录完整。
易改变性	参数表示的修改性	软件应提供方便的参数修改手段，以便变更软件适应新的应用。

7）安全性

项目	子项目	项目说明
适应性	访问的可审核性	程序应能对非法操作进行有效控制。
	访问的可控制性	程序应能避免重大和次要的数据讹误事件的发生。
	防止数据讹误	所有测试的功能应都能正确执行。