中国日报社中国对外政务信息服务平台主题服务建设采购项目中标公告

第十六章项目管理方案

16.1评分应答

序分

项目评审因素应答页码

号值

第1.项投标人提出针对本项目要求的实施0我方根据项目相关要求制定了请详

七目管管理方案，满足需求且方案完善合详细的实施管理方案及实施进见：

部理方理得2分，基本满足需求得1分，2度计划。P2-P3

分案部分满足或不满足需求得0分。实施管理方案包括但不限于：项4

项目服务内容、进度管理、质量保

目证、配置管理、文档管理、风险

管识别及控制措施、人员控制、沟

理通管理等必要管理计划。

方实施进度计划兼顾到需求调研、

案政府合作、咨询梳理、程序开发、

测试调优、培训、上线、运维等

各里目过程及其工作安排，对整

体项目进度进行控制。同时设置

了可落地的里程碑及相关文档

管理交付方案。

16.2实施进度安排

实期

*号工作任狗■1

X二个月1•三个月■BtH*六*八X八小月I«t个月|Mt-二个H六年

1需求调研蹇求调研与业务分析

2政府合＜乍洽改

—

18务.政策幻相

关知0桅理映

射关系建立

3主题服务梳理规划四大知五医黄梳

八大海源库设计

形成针对性的涉

外加服务现划

用户分析

规划设计

技术选型

4E

功崎&讦

—

数据再设.t

投费业务场!1设

田子皿美第5!友

5业务场事设计

旅游业务场费设

工作业务场及没★

运sr报多方察制

6版务运官规划

运ST耀务方富评

7政务孩务65用接入开发

眠若应用£f理开

—

用户请求管理开

工单管理产发

服务进度出与

照务路由枢纽设

8质量好发

计开发tf

服务商管理开发

市核与分发腑

OJ定S1化廿M升

实施开发发

国家兀苜取也表

阳芳登口优化

区域史源sae场

9露好窗口优化

服务出口优化

中国便车加8道

阪芬酸口优化

专收分析HS开

10加分析与管理优/数至模型tt叁开

数空主动分制

场景优《■

大府业若甘接

11主SE服务迭代完善

女询类限务登入

腼max

迭代完S!4000人天

基叱烫丽尤化

12运皆支撑迭代克善

支博系统"/七完

产SS群设十

13广晶形造困反西

产SJ群开及

流・优化

敢抵挖55分析

14服务运首

用户研究St理

网站苫用

15系统测试

测试上建

16笈猊上战

17项目培训顼目培训

18项目捡收完成项目终绘♦

19售后想保后服若与运维

20项目结束维保完成.项目结束★

实施进度计划表

实施进度分为规划设计、实施开发、迭代完善、服务运营、测试上线、项目

培训、项目验收、项目运维、项目结束等九个阶段。

＞需求调研

完成系统整体的需求调研工作及业务分析工作。

＞规划设计

与对接的政府机构持续洽谈，同时完成主题服务梳理规划、服务路由枢纽设

计、业务场景设计、服务运行规划，形成成熟的方案，通过用户的审核。

＞实施开发

完成政务服务接入开发、服务路由枢纽开发、服务窗口优化、数据分析与管

理优化等系统开发工作。

＞迭代完善

提供不少于4000人天服务，以保障本期项目对政务平台的优化完善与新业

务开发的需求。对招标方已接入和本期新接入的政务主题服务，以及开放平台的

迭代完善。整合社会资源和智力融合服务，以涉外政务服务为牵引，融合串接推

荐国内各地区优质中介机构、服务平台等服务资源，充分发挥社会资源，加快对

外政务服务方式、方法、手段迭代创新。

＞服务运营

提供运营团队，且团队中的每个人都有自己专长的领域，根据政务平台的建

设目标，依照政务平台的运营计划，组织实施、控制和改进C

＞测试上线

本项目建设开发完成的所有政务服务、场景优化完善服务、系统新功能等均

需要按照合理的质量控制管理流程完成开发团队的自测试，并在发布上线前通过

全面可靠的第三方测试检查，包括用户案例测试及其异常操作测试、安全测试、

兼容性测试、性能测试等。该测试需由有CNAS资质的第三方测试机构进行相关

仝面测评，并提交测评报告，该测评报告将作为系统验收的重要依据。完成测试

后系统上线运行。

＞项目培训

拓尔思公司将针对中国日报社对外政务信息服务平台主题建设服务采购项

目的不同用户分别设计不同的培训课程对相关人员进行全方位多层次的培训课

程，负责对中国日报社的相关人员分别组织业务培训和技术培训，根据项目的业

务内容和技术建设，提供不少丁100小时培训课程，具体的培训时间由甲方与拓

尔思公司就项目进展情况协商确定。

＞项目验收

根据招标人需求完成本期项目的主题服务梳理与规划、政务服务应用接入与

优化开发的工作，并完成阶段性验收。

＞项目运维

为用户提供售后服务阶段基本的系统运行维尹和技术支持服务。提供六年免

费质保与技术支持服务。免费维保期内，根据招标方安全检查、服务器升级等运

维要求，提供免费的配合服务。

＞项目结束

16.3里程碑

严格按照招标文件中的要求进行项目实施，本次项目进度计划中，共设置五

个里程碑，分别为：

里程碑一：项目启动会召开。完成与甲方的对接，完成对团队的组建，完成

需求调研及业务分析工作。

里程碑二：完成系统设计，完成对《项目管理计划书》、《需求规格说明书》、

《系统概要设计说明书》、《系统详细设计说明书》、《数据库设计说明书》等文档

的制订与评审。进入系统建设阶段。

里程碑三：系统的软硬件建设实施完工，完成本项目的产品部署、子系统定

制、调试等工作，系统可上线。

里程碑四：完成所有软硬件集成和调试，同时编制系统的操作手册、用户手

册等文档。进行项目知识转移、用户培训，项目最终验收。进入为期六年的免费

售后服务期。

里程碑五：完成六年免费售后运维服务期。

16.4项目管理

1641项目服务内容

16.4.1.1主题服务梳理与规划

结合政务平台己有建设基础和本期政务服务应用接入方案，以服务拓展和平

台优化为目标，根据主题服务梳理结果对政务平台业务场景和服务窗口进行整体

优化设计和技术完善指导，为合理融入市场资源、提升政务平台服务能力设计完

成服务路由枢纽，同时为保障政务平台服务建设能够长期有效地服务于用户需形

成可落地的服务运营规划和数据分析管理规划。

16.4.1.2政务服务应用接入与优化开发

提供应用接入与优化开发工作方案，以指导技术实施团队根据确认的政务服

务应用接入方案完成政务服务应用的开发接入、应用的测试调优与发布管理，并

根据主题服务梳理和业务场景设计规划成果完成政务平台的服务窗口优化。根据

设计要求进行数据分析与管理优化

16.4.1.3主题服务迭代完善

对招标方已接入和本期新接入的政务主题服务，以及开放平台的迭代完善。

整合社会资源和智力融合服务，以涉外政务服务为牵引，融合串接推荐国内各地

区优质中介机构、服务平台等服务资源，充分发挥社会资源，加快对外政务服务

方式、方法、手段迭代创新。

提供不少于4000人天的稳定团队服务，以保障本期项目对政务平台的优化

完善与新业务开发的需求。完成主题服务迭代完善、运营支撑迭代完善、产品形

态迭代完善。

提供科学、合理、可落地的政务主题服务迭代完善方案，指导迭代开发持续

交付团队对开放平台按照需要进行功能性优化、对政务数据库进行完善优化，以

完成本期对主题服务迭代完善建设要求。

16.4.1.4咨询服务

为本项目配备具有互联网和电子政务行业工作经验的团队，进行项目的合作、

咨询和服务设计规划等工作，包括但不限于：利用政府资源沟通协调完成服务接

入，确定并形成本期政务应用接入方案，结合政务平台已有资源完成服务梳理和

业务场景设计，并为政务平台完成对应的服务运营规划。

16.4.1.5迭代开发服务

提供具有迭代开发能力和经验的团队进行本次项目的迭代开发工作。根据政

务平台服务规划和运营完善过程中的业务决策，以产品设计和用户体验为导向，

提供需求分析、设计、实现与测试服务，并结合招标方和用户的反馈进行迭代优

化，对政务平台进行逐步完善。

16.4.1.6运营服务

配备专业的运营团队，且团队中的每个人都有自己专长的领域，根据政务平

台的建设目标，提供政务平台的运营计划、并组织实施、控制和改进。运营成效

需与主题服务建设和政务平台完善保持整体一致。

16.4.1.7第三方测试服务

本项目建设开发完成的所有政务服务、场景优化完善服务、系统新功能等均

需要按照合理的质量控制管理流程完成开发团队的自测试，并在发布上线前通过

全面可靠的第三方测试检杳，包括用户案例测试及其异常操作测试、安全测试、

兼容性测试、性能测试等。该测试需由有CNAS资质的第三方测试机构进行相关

全面测评，并提交测评报告，该测评报告将作为系统验收的重要依据。招标方有

权进行相关抽测与检查，并有权要求更换不合格的第三方测试机构。

1642项目管理架构

本项目以标准规范体系为依托，采用项目管理工具，在对工程程序进行严格

界定的基础上，以成熟稳定的项目组织作保障，利用PMI组织发布的项目管理

知识体系并结合Scrum开发模式，对整个项目过程进行管理。整体项目实施管理

框架如下图：

组织保障目群管理

"特点

1.成熟稳定.

有大型项日开发

集成

及集成经验的技

项目

术服务队伍

管理

2.专门的平台

内容

技术支持组

3.I业的业务

技术人员

标

准

工

试

测

规

范软件工

大型匚程项II程

理

程项目管

体

系模板

项目建设管理程

法

文档«|办文档

管理办法办法序

规例制规范

项目管理架构

16.43项目管理工作内容

结合对项目管理目标的分析和理解，本次项目需要完成以下的管理工作：

1、采用敏捷开发（Scrum）模式进行项目开发和管理；

2、制定详细的项目进度计划，提供全面的进度控制方案，对整体项目进度

和各分项目进度进行控制，保证项目按时提交；

3、制定整体项目目标、分阶段目标和分项目目标，并制定各类目标相应的

考核计划，规避各类项目风险保证项目质量：

4、管理项目团队的组织和人员，为项目提供组织保障；

针对以上项目管理目标和工作内容，我们制定了以下详细全面的项目管理方

案，确保各项工作的顺利开展，并达到预期的效果。

16.4.4范围管理

项目是为完成产品或服务所做的一次性努力。因此，范围的概念包含两方面:

一个是产品范围，即产品或服务所包含的特征或功能；另一个是项目范围，却为

交付具有规定特征和功能的产品或服务所必须完成的工作。在确定范围时首先要

确定最终产生的是什么，它具有哪些可清晰界定的特性。要注意的是特性必须要

清晰，以认可的形式表达出来，比如文字、图表或某种标准，能被项目参与人理

解，绝不能含含糊糊、模棱两可，在此基础之上才能进一步明确需要做什么工作

才能产生所需要的产品。也就是说产品范围决定项目范围。

范围管理保证项目包含了所有要做的工作而且只包含要求的工作，它主要涉

及定义并控制哪些是项目范畴内的，哪些不是。范围管理的基本内容包括：项目

启动、范围定义、范围核定、范围变更控制等等。下面所讨论的是其中比较重要

的部分一一范围定义及跟踪。

“工欲善其事，必先利其器”。要想真正管理好项目范围，没有必要的技术

和方法是肯定不行的。国外曾经有人对项目失败原因进行调查，其中计划被放到

了首位，可见它在项目管理中的重要性。

首先就是周密地做好范围计划编制。范围计划编制是将产生项目产品所需进

行的项目工作（项目范围）渐进明细和归档的过程。做范围计划编制工作是需要

参考很多信息的，比如产品描述，首先要清楚最终产品的定义才能规划要做的工

作，项目章程（典型的例子是合同）也是非常主要的依据，通常它对项目范围已

经有了粗线条的约定，范围计划在此基础上进一步深入和细化。不同的计划详尽

程度自然不一样，作为本项目集成控制，对于各子项的范围说明和范围管理计划

必须包含在内。

范围说明在项目参与人之间确认或建立了一个项目范围的共识，作为未来项

目决策的文档基准。范围说明中至少要说明项目论证、项目产品、项目可交付成

果和项目目标。项目论证是商家的既定目标，要为估算未来的得失提供基础；项

目产品是产品说明的简要概况；项目可交付成果一般要列一个子产品级别概括表,

如：为一个软件开发项目设置的主要可交付成果可能包括程序代码、工作手册、

人机交互学习程序等。任何没有明确要求的结果，都意味着它在项目可交付成果

之外;项目目标是要考虑到项目的成功性，至少要包括成本、进度表和质量检测。

项目目标应该有标志（如：成本、单位）和绝对的或相对的价值（如：少于1S0

万元等）。不可量化的目标（如：“客户的满意程度”）要承担很高的风险。

范围管理计划是描述项目范围如何进行管理,项目范围怎样变化才能与项目

要求相一致等问题的。它也应该包括一个对项目范围预期的稳定而进行的评估

（比如：怎样变化、变化频率如何及变化了多少）。范围管理计划也应该包括对

变化范围怎样确定，变化应归为哪一类（当产品特征仍在被详细描述的时候，做

到这点特别困难，但绝对必要）等问题的清楚描述。

16.4.5风险管理

本次项目是一个复杂的、长期的项目，实施具有一定风险，如何在项目实施

中有效地管理风险、控制风险，已经成为了项目实施成功的必要条件。

风险管理所关注的是项目风险的确定，分析及对策。包括风险识别，风险评

估、风险和风险对策实施控制。项目风险管理实际上就是贯穿在项目开发过程中

的一系列管理步骤，其中包括风险识别、风险估计、风险管理策略、风险解决和

风险监控。它能让风险管理者主动“攻击”风险，进行有效的风险管理。

风险管理实际上是对风险识别、风险分析、风险评估量化以及风险管理控制

的循环管理过程。在作风险识别时，应该现对风险进行分类。不同类别的风险因

素，将会有不同的应市措施。

16.4.5.1涉众分析

1、承建单位：

•按照工程标准，确定风险管理机制；

•提供项目进展的风险信息；

•编制风险管理计划；

•执行风险缓解行动。

2、监理单位：

•协助业主单位提出、分析和制定风险计划；

•提供项目进展的风险信息；

•督促承建单位执行缓解行动。

3、业主代表：

•批准风险计划，进行风险管理活动；

•实施和监督风险缓解行动的执行。

16.4.5.2风险识别

对本工程的软件开发风险进行评估，首先就要对风险因素进行辨识。风险因

素是指增加、减少损失或损害发生频率和大小的主、客观条件，包括转化条件和

触发条件。风险因素是风险事件发生的潜在原因，分为造成损失或损害的内在或

外部原因。如果消除了所有风险因素，则损失或损害就不会发生。因此，风险因

素辨识是对软件开发过程中可能产生风险的因素所进行的归类和细化的工作。

16.4.5.3风险分析

尽早进行风险分析，能够减少项目实行过程中的不确定性。它不仅使各层次

的项目管理者建立风险意识，重视风险问题，防范于未然，而且在各个阶段、各

个方面实施有效的风险控制，形成一个前后连贯的管理过程。作为面对项目风险

的有效手段，全面风险管理强调风险的事先分析与评价，风险因素分析是确定一

个项目的风险范围，并将这些风险因素逐一列出以作为全面风险管理的对象。罗

列风险因素通常要从多角度、多方位进行，形成对项目系统的全方位的透视。

从总体上可以将该项目的风险分为宏观和微观两部分，宏观方面的风险指针

对该项0的特点而使项a的实施具有的风险，微观风险则指在软件开发过程中会

出现的风险。

16.4.5,4量化分析

对每项风险发生的概率和对项目和有关业务的影响进行量化。对于每项风险

要划分优先级，这要按照概率和影响的等级，并清楚的标明低、中、高的优先级。

1、风险概率

标题评分描述

很低20不大可能发生；但是仍要监督。因为一定的状况可能会导致风险在

项目期间变得可能。

低40根据当前的信息，不大可能发生，当状况一旦触发，风险有可能发

生。

中等60对项目有可度量的影响，例如，项目范围、到截止日期的进度、项

目预算有5—10%的偏离。

高80对项目有明显的影响，项目范围、到截止日期的进度、项目预算有

10-25%的偏离。

很高100对项目有很大影响，项目范围、到截止日期的进度、项目预算

有＞25%的偏离。

2、风险影响

标题评分描述

很低20对项目无明显影响。由于太小，对项目的影响无法度量。

低40对项目影响较小，例如，项目范围、到截止日期的进度、项目预算

有＜5%的偏离。

中等6060对项目有可度量的影响，例如，项目范围、到截止日期的进度、

项目预算有5-10%的偏离。

高80对项目有明显的影响，项目范围、到截止日期的进度、项目预算有

10-25%的偏离。

很高100对项目有很大影响，项目范围、到截止日期的进度、项目预算

有＞25%的偏离。

3、风险优先级

通过识别风险发生的概率以及它对项口的影响，确定每项风险的优先级。一

旦分配了概率和影响，优先级的评分将按照以下的方式计算出：

优先级=（概率+影响）/2。

16.4.5.5风险控制

1、风险对策

任何项目都存在不同的风险，风险的承担者应对不同的风险有着不同的准备

和对策，这应把它列入计划中的一部分，只有在项目的运营过程中，对产生1勺不

同风险采取相应的风险对策，才能进行良好的风险控制，尽可能地减小风险可能

产生的危害，以确保效益。

通常的风险对策为：

采取先进的技术措施和完善的组织措施，以减小风险产生的可能性和可能产

生的影响。如选择有弹性的、抗风险能力强的技术方案，进行预先的技术模拟试

验，采用可靠的保护和安全措施。对管理的项目选派得力的技术和管理人员，采

取有效的管理组织形式，并在实施的过程中实行严密的控制，加强计划工作，抓

紧阶段控制和中间决策等。

2、实施中的全面风险控制

工程实施中的风险控制贯穿于项目控制（进度、成本、质量、合同控制等）

的全过程中，是项目控制中不可或缺的重要环节，也影响项目实施的最终结果.

加强风险的预控和预警工作。在工程的实施过程中，要不断地收集和分析各

种信息和动态，捕捉风险的前奏信号，以便更好地准备和采取有效的风险对策,

以抗可能发生的风险。

在风险发生时，及时采取措施以控制风险的影响，这是降低损失，防范风险

的有效办法。

在风险状态下，依然必须保证工程的顺利实施，如迅速恢复生产，按原计划

保证完成预定的目标，防止工程中断和成本超支，唯有如此才能有机会对已发生

和还可能发生的风险遂行良好的控制，并争取获得风险的赔偿，如向保险单位、

风险责任者提出索赔，以尽可能地减少风险的损失。

16.4.6成本管理

项目成木管理包括以下过程：成木规划，成木估算，成木预算和成木控制过

程，其目的是为了保证项目在预算范围内完成。

成本估算：为了完成项目的任务，形成项目需要的初步总体资源成本；

成本预算：把项目的每个任务或者工作包估算的成本汇总起来，建立项目的

成本基线；

成本控制：关注项目过程中造成成本偏差的因素，控制项目预算的变更。

项目成本管理主要关注完成项目任务所需要的资源消耗的成本。成本管理也

关注如何对待项目产品(含服务或者其它结果)应用、维护和支持所带来的成本。

比如，减少项目的设计评审次数可以降低项目成本，但是会提高客户使用产品的

操作成本，广义上的项目成本管理也叫做“全生命周期成本”(life-cyclecosting),

该参数结合价值工程技术(valueengineeringtechniques),可以有效的支持决策

模型(dicision-making),达到降低项目成本和执行周期，同时也提高项目产出物

的质量和性能。

项目成本管理需要关注项目风险公担人的信息需求，不同的风险公担人用不

同的方法、在不同的时间测量项目成本。比如，当确认某些项目后发成本项是应

该支出的，可以记录这些成本，当该成本项已经发生，需要根据财务会计的需要

承担和记录实际的成本。

成本管理的三个过程虽然没有被表现为一个独立的过程，但是项目管理团队

需要先做相当的计划过程投入，然后才执行项目成本管理的二大过程C这个投入

是开发项目管理计划过程的组成部分，这个过程形成成本管理计划，定义项目成

本计划，构建，估算，预算和控制各方面的格式和建立的条件。在不同的应用领

域，成本管理过程以及相关的工具和技术是有差别的，这些选择往往是在定义项

目生命周期模型中形成，并文档化在成本管理计划中。

比如，成本管理计划可以建立以下内容：

成本精度：项目任务成本会用预先定义得成本精度(比如100元为单位，1000

元为单位)来表达，精度级别依据任务的范围和项目的规模，也可能包含项目成

本储备量。

测量单位：需要定义每一种资源的测量单位，比如人时、人日、人周、

(lumpsum)等。

组织规程关联:在WBS中用于成本控制的组件叫成本控制点(controlaccount,

CA),每一个CA都有自己的编码，并直接关联执行组织的会计科目系统。如果

在控制点描述中包括了项目计划任务(planningpackages)的成本估算，和成本

预算相关的计划任务的方法也需要包括。

控制阈(范围)：在项目整个周期中预先定义的不同监控点，成本偏差的范

围(上限和下限)或者其它指标的阈值，需要预先定义。

挣得值管理规则：看以下说明：

1）用于到完成时估算（estimatetocomplete）的挣得值管理公式和算法需

要预先定义下来。

2）建立挣得值的度量标准（比如0—100,0-50-100）o

3）定义挣得值管理技术在WBS的哪个层次执行。

汇报格式：各种不同的成本报表格式需要预先定义；

过程描述：各个成本管理过程的描述需要文档化。

以上各项内容都需要包含在成本管理计划中，可以是正式文本，也可能是附

件条目。成本管理计划是项目管理计划的一个组成部分（子计划），可以是正式

的，或者是非正式的；可以是详细的，或者是概括的。根据项目的实际需要。

成本管理在计划上的早期投入，并设定了各个成本管理过程的框架流程，可

以使过程的执行会更加高效和流畅。

16.4.7进度管理

我方将从中标之E起12个月内根据招标人需求完成本期项目的主题服务梳

理与规划、政务服务应用接入与优化开发的工作，并完成阶段性验收。

16.4.7.1项目时间管理

项目时间管理是为确保项目各部分工作按时完成所需要的一系列过程。包括

活动定义、排序、时间估算、进度计划和时间控制等。这里特别要提请注意的是，

进度计划的层次性。在项目启动之初，有项目主计划，在规划、设计阶段，要制

定较详细的计戈九在实施阶段，要有具体执行计划。在具体制定计戈iJ时，应根据

项目所处阶段和目标任务的规模，确定计划的时间粒度，在具体实施时，必须根

据规划阶段的粗粒度计划再细化，制定具体的实施计划。

我们建议采用MSProject进行项目时间管理。

1、项目活动定义

定义活动涉及确认和描述一些特定的活动，完成了这些活动意味着完成了

WBS结构中的项目细目和子细目。通过定义活动这一过程可使项目目标体现出

来。

2、项目活动排序

活动排序过程包括确认且编制活动间的相关性.活动必须被正确地加以排序

以便今后制订可行的进度计划。

3、项目活动时间估计

活动时间估计指预计完成各活动所需时间长短，在项目团队中熟悉该活动特

性的个人和小组可对活动所需时间作出估计。

4、项目进度安排

进度编制要决定项目活动的开始和结束日期，若开始和结束日期是不现实的,

项目不可能按计划完成。进度编制、时间估计、成本估计等过程交织在一起，这

些过程反复多次，最后才能确定项目进度。

5、项目进度控制

进度控制是指：

（1）改变某些因素使进度朝有利方向改变；

（2）确定原有的进度已经发生改变：

（3）当实际进度发生改变时要加以控制；

（4）进度计划控制必须和其它控制过程结合。

16.4.7.2项目进度跟踪

在项目的实施过程中，还要对项目的实施情况进行跟踪，确保项目的实施符

合计划的要求。跟踪的方法可分为正规跟踪和非正规跟踪，正规跟踪就是定期召

开项目进展情况汇报会、提交项目进展报告等，从而使项目利益相关者了解项目

的执行情况。根据进展报告，与会者讨论项目遇到的问题，分析并找出问题的原

因，研究、确定应对方案和预防措施，为控制项目提供依据。

非正规跟踪则是项目经理频繁地到项目现场，通过观察、与现场人员交谈、

收集数据等方式了解情况，发现问题。在项目管理过程中，非正规跟踪比正规跟

踪更加有效，原因是：

•了解的情况真实、及时；

•缩小了项目经理与现场成员之间的距离，使之关系更融洽，问题更易解决；

•现场的执行人员更容易沟通；

•项目经理更能亲身体会现场的工作气宓，掌握团队的士气；

•更容易获取解决问题的答案。

项目任务进度的度量：首先把每项工作分解到工期在一周以内，每周末进行

进度评估，我们采取工时提交原则，即提交工作任务的完成工时。

项目进度跟踪的工具可以使用MSProjecto

项目进度信息采集的方式：项目周报、项目例会、阶段性评审、挣值法。

（1）项目周报：

项目实施小组每周向项目经理提交每周的工作汇报，包括存在问题。

（2）项目例会：

项目组定期举行工作会议，分析项目状态，落实下一步工作，其中包括对现

有的问题进行讨论并解决。

（3）阶段性评审：

在项目的阶段最后，召开项目小组成员、项目指导委员会、外部项目质量保

证等人员对项目的阶段工作进行评审，包括进度、交付物的质量、阶段里程碑、

项目中的重大问题、项目风险、分析项目中的好的方法等c

16.4.7.3项目进度分析

挣值法：这种方法提供了三个数据来跟踪项目的执行情况：计划做什么、实

际做什么、以及做完的工作花了多少费用。这种方法交计划需完成的工作同实际

己完成的工作进行比较，确定项目在费用支出与时间进度方面是否符合原计划的

要求，从而跟踪项目执行的好坏。

164.74项目进度控制

项目计划只是根据预测而对未来做出的安排，由于在编制计划时事先难以预

见的问题很多，在计划执行过程中往往会发生或大或小的偏差，这就要求项目经

理及其他管理人员对计划做出调整，消除与计划不符的偏差，以使预定目标按时

和在预算范围内得以实现。

项目计划的控制就是要经常对每项工作进度进行监督，然后，对那些出现“偏

差”的工作采取必要措施，以保证项目按照原定计划进度执行，使预定目标按时

和在预算范围内实现。

按照不同管理层次对进度控制的要求分为三类：

1、项目总进度控制：项目指导委员会对项目中各里程碑事件的进度控

制C

2、项目主进度控制：项目经理针对项目进度计划中的关键路径进行控制，

保证总进度的如期完成。

3、项目详细进度控制：主要是各作业部门对各具体作业进度计划的控制。

这是进度控制的基础，只有详细进度得到较强的控制才能保证主进度的按计划进

行，最终保证项目总进度，使项目目标得以顺利实现。

进度控制的依据主要有：项目进度表、项目进展报告、变更请求等。项目进

度的控制方法如下所示：

（1）把能力强的成员放在关键路径的工作上，把新手放在时差大，不重

要的工作上；

（2）赶工期，包括通过加班加点来缩短关铤路径上单项任务的持续时间；

调整关键路径上活动之间的逻辑关系，变FS为SS；

（3）重新谈判，即与项目利益相关者讨论增加预算或者延长时间基线：

（4）缩小项目范围，以便减少费用、节省时间；

（5）投入更多的资源，看看可否增加人力、设备到工作中。这需要平衡

费用与进度孰重孰轻；

（6）接受替补方案，看看能否制定一个更省钱、更现实的方案；

（7）寻求其他资源；

（8）接受部分交时物，看看能否先接受部分交付物，使项目能继续进行；

（9）提供奖金，看看能否提供奖金或其他激励措施，促使按时完成任务；

（10）进度控制的结果包括：项目时间表更新、补救的行动、经验教训。

16.4.8人员管理

在本项目的执行过程中，项目经理和系统架构师专职于本项目，核心技术人

员百分之百地投入到木项目中，并且整个项目团队的人员相对稳定。

按照工程建设对项目实施的要求，配置相应的项目管理、系统设计、开发、

测试、集成、培训、质量保证等人员，在项目组织中明确各岗位的职责，确保工

程顺利实施。

参与此项目的核心技术人员拥有承担过相关软件开发和相关项目建设的经

验，能够与报社用户进行良好的沟通，掌握报社的相关基础知识，具备相关产品

集成、应用和开发的能力。参与此项目的技术人员具有强烈的服务意识和高度的

责任感。

16.4.9沟通管理

本系统涉及到的项目干系方非常多，在这种复杂的组织结构下，保证有效、

良好的沟通对于项目的成功是至关重要的。因此从项目承建商的角度来看项目中

的沟通包括以下管理的方案：汇报关系、沟通计划、问题管理、会议管理、信息

共享等。

16.4.9.1汇报管理

建立有效的汇报组织机构是实现有效沟通的前提和保证。汇报关系基于对本

项目组织机构定义，通过层级的划分明确了项目承建商的定位和职责，以及项目

汇报路径。

16.4.9.2沟通管理

项目实施是•个团队任务，信息不畅容易导致工作偏离目标，或者是成员之

间产生误解，所以项目经理要在信息沟通中起到非常重要的作用。对于信息的发

布，一定要保证版本的有效性，对于通过电子邮件发布的重要信息，一定要让对

方反馈接收与否的信息。对于规模较大的项目，有时信息需要群发或多人讨论,

这时需要建立专用的信息沟通平台，例如利用微信群、邮件组、QQ群等。

16.4.9.3沟通计划

在本项目中，我们建立以下正式沟通计划，并在工作中保证实现:

类型沟通内容参与人员责任人时间

项目组首次会议培训项目管理方法、实施计划项目组全体成员项目经理待定

项目动员大会明确目标、落实责任、激发热全体成员项目发起待定

情人

项目管理例会分析项目状态，明确项目管理委员会项目经理每月末

阶段评估会议评估项目阶段的完成情况项目管理委员会项目经理阶段末

项目验收会议评审项目验收标准的完成项目管理委员会项目经理项目收

尾时

项目组工作例会汇报各项工作的进度及问题项目经理项目经理每周一

项目变更会议决议变更需求项目管理委员会项目经理变更产

生时

项目通讯对外宣传项目状况项目组全体成员项目管理每月

办公室

项目信息共享了解项目状态、计划、问题等项目组全体成员实施组长随时

操作状况了解用户的操作状况项目成员最终用户上线后

每日

另外，在项目的实施工作中，有一些沟通属于非正式沟通，例如聚会、交心

谈话、技术研讨、能力拓展等，我们会根据项目的需要选择进行。

16.4.9.4沟通内容

在项目实施阶段，项目利益相关者之间的信息沟通与交流集中在如下方面:

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

2、已完成的工作质量情况；

3、与计划相比，进度情况；

4、与计划相比，实际成本支出情况；

5、项目执行过程中出现的问题，这些问题的解决方案以及建议采用的方案。

16.4.9.5报告形式

1、报告应尽量使用数据、表格、图形等方式，避免纯文字上的长篇大论。

例如在作进度情况报告时，常用甘特图、网络图、时间线以及里程碑表等。

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

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

16.4.9.6相关文档

相关文档包括：

1、《会议纪要》

2、《项目周报》

3、《项目月度状态报告》

4、《项目阶段评估报告》

5、《项目总结报告》

16.4.10质量管理

项目质量管理是确保项目及其交付结果符合相关质量标准要求的过程。项目

质量一方面指项目能否在规定的时间内、在批准的预算内、在规定的范围内完成

项目，另一方面，是指项目所提交的产品服务是否符合客户技术性能的要求。

通过我们多年的实践经验，IT项目的质量管理很难，因为很多客户都是在项

目初期很难对系统有一个具体的描述，在实施的过程中随着对系统的认识加深,

又会提出很多自认为合理的需求。所以在项目初期，加强对客户关键用户的系统

培训，不断与客户方法行质量要求的沟通，对以后项目质量控制起到预防作用。

另外，通过项目章程，对质量规定一个基线是非常必要的。

组织保障平台保障

政务应用开放平台安全稳定、

配备商务洽谈、技术支持、

开发者手册完备

运营服务等多方面人员；具

备政务服务应用接入经验.

可彳帮分析

区域保障进度保障

所选地区政务服务成熟度高、一边规划、一边接入，

自贸区建设基础良好建立进度控制计划

政务服务应用接入保障措施

1、确定基本的质量需求：

（1）对文档性交芍物的质量需求：规范性、完整性、可读性等；

（2）对系统运行的质量需求：稳定性、可操作性、响应速度、安全性、功

能满足性、扩展性、可维护性等；

（3）对知识转移的质量需求：是否建立一支用于系统后期优化、改进的队

伍等。

2、确定质量控制方法

（1）建立内部质量控制组，定期进行质量评测（质量保证计划）；

（2）采用检测表及评估表的方式；

（3）进行阶段评估及分步验收的方式；

（4）实施管理过程采用戴明质量管理体系（PDCA）；

（5）定制开发过程采用我们公司的CMMI5体系。

16.4.11软件版本控制计划

16.4.11.1版本管理

16.4.11.1.1版本标示方法

为了使工作规范化、统一化，研发本部各部门实行的版本标识管理方法。

16.4.11.1.1.1正式版本

软件版本号由I四部分组成，X.Y.Z.DATA—希腊字母，

X：主版本号，用来表示提供给客户的产品功能的主要增强。在一个极端的

例子中，主版本号的上升用来说明产品现在已经拥有了一个全新的功能类。从市

场和许可权的角度来看，主版本号的升级相当于购买一个完全独立的产品。从开

发者角度来看，一个主扳本号的迭代差不多总是反映了一个新的独立分支或是其

主干还可以延续主版本的生命期。

Y：特征版本号，用来表示产品新增了一些特征，或者是在原来文档中描述

的特征上作了重要的修改。用来确定特征版本号什么时候需要修改的一个衡量标

准就是产品功能说明书。产品的特征版本升级是在主版本之间保持产品竞争力的

一种重要机制。

Z：缺陷修复版木号，用来表示在该版木上所做的缺陷维护行为的等级。版

修复版本是稳定市场和最小化客户技术支持费用负担的一种重要机制。

Alpha版：此版本表示该软件在此阶段主要是以实现软件功能为主，通常只

在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。

Beta版：该版本相对于a版已有了很大的改进，消除了严重的错误，但还是

存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软

件的Ulo

RC版：该版本己经相当成熟了，基本上不存在导致错误的BUG,与即将发

行的正式版相差无几。

Release版：该版本意味〃最终版本〃，在前面版本的一系列测试版之后，终归

会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。

一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。

例如：1.1.1.051021beta.第一个1为主版本号,第二个1为子版本号,第三个L

为阶段版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有

5种,分别为:base、alpha、beta>RC、release0

16.4.11.1.2目录结构

由于各部门的实际情况不同，目录结构很难统一，但为了能更好地管理各部

门部文档，建议可将被管理的配置项分为三大类：文档类、源码类及安装盘类,

这样存放比较清晰，有利于版本管理。具体目录如下表格所示：

根目录一级目录二级目录三级目录

集成代码代码的合并

第一个模块代码

源代码(SRC)第二个模块代码

数据库SQL

公共开发包代码

立项文档立项计划书立项申请书

项目计划项目JT发计划

需求文档需求规格说明书

项目名称+设计文档设计概要说明书数据库设计说明书

版本号界面布局原型界面动态页面

文档(DOC)

参考资料项目一些参考资料

验收文档验收资料

测试文档测试计划测试报告测试用例

试用信息

测试部署部署材料

SETUP

发布(RELEASE)RELEASE

发布文档

16.4.11.1.3文档的存放

16.4.11.1.3.1开发文档的存放

文档归档流程:

16.4.11.1.3.2源代码的存放

16.4.11.1.3.3SQL的语句存放

各子系统SQL文件放入.....\….…\SQL下，对于不同的数据库，分别建立不同

的子目录，如WAT、SYB、MSS、ORC、DB2等。公共SQL文件直接放入...\SQL下

即可，不同数据库的特殊SQL分别放入对应的子目录下。

16.4.11.1.3.4发行文档的存放

发行文档是指产品交付用户使用所必须的文件。包括：产品可执行文件，用

户使用说明书，联机帮助（HLP）；资源文件（BMP,ICO等），环境配置文件等。

16.4.11.1.4配置管理流程

配置管理流程

流程说明：

开发人员完成所负责代码模块的编写任务后，提交到项目经理处；

项目经理向测试部提交测试任务；

配置管理员准备测试所需环境；

测试员开始测试并提供实时测试BUG；

开发人员处理测试人员提供的BUG,并提交测试员进行回归测试，直至BUG

关闭；

测试完成后，测试人员提供测试报告；

根据项目情况决定是否发布新版本；

配置管理员与各成员确定好新版本的各项信息；

配置管理员发布新版本。

16.4.11.1.5权限控制的管理

为保障文档的安全性，一致性，以及防止意外修改，必须对不同的文档设置

不同的访问权限。

文档权限类别：只读权限，读写权限。

文档类别：DOC,SRD,RELEASEo

用户类别：开发人员、测试人员、分析设计人员、部门经理、配置管理员、

安装盘制作人员、问题及需求管理人员、用户文档编写人员等。

为了控制不同的使用权限，根据要求在服务器上分别建立不同的用户，针对

不同的配置项所在目录分配不同的权限。

为了便于各部门的管理，应以表格的形式列出人员与管理对象的访问关系

（用户权限清单）。

16.4.11.2更新管理

16.4.11.2.1源程序的修改

源程序修改流程

当开发小组在开发同一产品时，应能保障：各成员间的修改不会互相覆盖;

程序员的修改能及时反映到产品的最新版本中。

建议首先在相应子系统的下一级建一目录，如checkout,存放正在修改的文

档及修改登记表。当某个程序员要修改某一文档时，遵循以下程序：

接收维护任务；

查看需要修改的文件（如PBL及SQL等）是否正在被其它人员修改（检查

checkout目录下是否存在要修改的文件或后缀己改为该程序员姓名简写）；

如果有人在修改该文件，等待或与相应的开发员联系，重复2。否则继续;

将该文件复制到checkout目录下，在修改登记表中登记；或将该文件的后

缀改为本人姓名简写；

将该文件拷贝到自己的私有目录；

根据要求修改源文件；

根据要求测试，并进行相关项的回归测试；

交测试人员测试，如未通过，重复6,如通过则继续；

在checkout目录中删除该文件，并在修改登记表中标注修改完成；

将修改完毕的文件通过电子邮件或其它手段送交版本管理员，版本管理员将

文件复制到相应的路径；如遇特殊情况(版本管理员出差)，程序员可将修改完

毕的文件复制到相应的路径下，或将后缀改回正式。

回复下达者，报告维护任务完成。

16.4.11.2.2版本升级

16.4.11.2.2.1版本升级原则

版本升级应严格纳入版本管理的控制之下。应当谨慎地控制版本的升级，保

障高版本的向下兼容性，或提供严格定义的升级方法。

主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构

发生变化。此版本号由项目决定是否修改。

子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加

自定义视图等功能。此版本号由项目决定是否修改。

阶段版本号(1)：一般是Bug修复或是一些小的变动，要经常发布修汇版,

时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理

决定是否修改。

日期版本号(140606):用于记录修改项目的当前日期，每天对项目的修改都需

要更改日期版本号。此版本号由开发人员决定是否修改。

希腊字母版本号(beta):此版本号用于标注当前版本的软件处于哪个开发阶

段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修

改。

每次版本升级，要填写版本升级记录表,

记录表样例如下