软件系统项目管理方案

1.项目管理方案

1.1.项目实施方案

本方案提供的功能解决方案已经包括了单位办公系统需求中的所有的系统

模块。所以，项目实施的重点工作是：在实施过程中要根据单位管理的实际情况

配置和调整现有软件功能。从而能够保证单位整体信息化建设的进度和质量，按

照单位的要求，建设以先进的计算机网络技术为依托，以业务流转为核心，以综

合信息服务为基础，以电子邮件、单位内部信息综合查询服务、日常行政事务管

理等为内容的综合办公管理平台。

1.1.1.项目实施总体原则

协同办公系统一般涉及实施的对象多、范围广，我们应明确项目的实施原则：

(1)“总体规划、分步实施”

根据客户实施应用环境、培训后技能水平、实施力量、数据和应用等方面状

况，既要从整体上安排近期、中期和最终目标，又要在具体上有步骤、有目标、

详细地制订一个执行计划，分模块，有重点地一步一步推进，并且这个计划要滚

动式地、不折不扣地跟踪考核。

(2)“效益驱动，直点突破”

根据客户需求与实施应用环境，确定一个成功应用点，并作为驱动整个系统

应用的突破口。驱动应用点的选定，关系到客户走向管理信息化道路的全面启动

应用。囚此，在选定时，应在容易与复杂、局部与全部、独立与相关等问题上作

些分析与权衡。

(3)“持续改进”

通过试点单位和各单位的使用，我们应不断对该系统进行维护，完善系统功

能，最大限度地满足客户实际业务。

(4)“重点突出、以点带面”

该项目涉及使用单位较多，不可能同时实施该系统。我们可以选择重点地单

位，优先实施该系统。在实施过程中，还应不断总结经验和进行功能改进，为大

面积地系统推广做准咨和经验参考。

(5)“紧密结合、周密计划”

该系统应与客户的需求紧密结合，最大程度的满足实际'业务需求；制定切实

可行的项目计划，同时在项目每个阶段，负责人也制定细化的阶段计划，作为项

目每个阶段的航标，确保项目满足客户要求，按时、高质量提交。

在保证软件实施质量的前提下，侧重提高实施效率、成功率和加速项目实施

速度，大幅度地减少客户费用，缩短实施周期。

1.1.2.项目实施关键因素

(1)严格按实施体系进行实施

对于大型项目，严格按单位的实施体系来实施，以保证项目能在预算范围内

按时按质地完成，并能进一步丰富实施知识库，提升单位的实施能力。单位的实

施体系由三部分组成：实施方法论、实施方法和标准实施文档。

(2)规范试点、加强培训

对于应用同一软件系统的不同单位，我们将建议客户从中选择有代表性、有

影响力的单位作为试点单位进行实施，实施成功后，再将成功应用克隆到其他单

位去，为了加快实施的速度、降低实施的成本并提前和待实施的单位进行接触和

沟通，实施组可以建议客户采取“集中培训、现场辅导”的培训学习方式，如在

对试点单位进行实施的同时，邀请所有需要实施的单位相关人员来参加培训，培

训后相关业务人员需要进一步辅导的，辅导工作在其所在单位进行实施开展。

(3)阶段实施、按时验收

为了保证在实施的过程中有一个阶段的实施直点，实施组应该根据实施主计

划形成阶段实施计戈同时为了让客户和所有参与项目的人员能保持高度的激情

和成就感，应该设立里程碑事件，阶段实施计划和里程碑事件都应该能和合同中

要求的验收条件相一致。

(4)项目管理、团队协作

我们应按项目管理的方法来对项目进行管理，所有我方的项目组成员都应

该掌握项目管理的基本方法、项目经理应该有大型软件系统的实施管理经验，并

能将项目组打造成为富有战斗力和工作激情的团队，使项目项目组成员在圆满完

成项目任务的同时对自身的能力得到提升。

1.1.3,本项目实施方案

由于信息化工作过程中会改变原有的工作方式，流程的合理化与再造过程会

对各级使用者产生比较大的触动，难免会遇到技术和思想上的阻力，所以在实施

过程中需要单位各级领导的参与和支持。在项目的实施中，需要双方建立项目工

作组，并相互配合协调，共同完成办公自动化系统的实施工作。

我们根据单位办公系统总体方案，在今后系统的实施过程中，我们都严格按

照如卜.项目实施方案进行：

3.1.3.1.项目实施原则

坚持“整体规划、分步实施、重点突破”的原则。定义明确的目标、范围和

进度，并运用现代项目管理方法对项目实施计划进行优化和有效的控制，以最短

的时间、最小的投入来实现项目目标。

3.1.3.2.项目实施方法

单位的项目实施主要面向内部办公管理，在实施过程中将内部办公管理和信

息技术有效结合，一方面满足用户的工作目标和需求，另一方面通过由很多步骤

组成的规范化操作过程，实现上述结果。

软件项目实施方法具体描述了单位实施的原则、方法、J2作规范等内容，是

我单位开展项目实施工作的主要理论依据。

3.1.3.3.项目实施主要工作流程

项

目项目实施建议书

前

期确定项目实施主计划

准

备项目启动会议

解

关键用户培训

决

方

需求调研与分析

案

设

项目实施方案书

计

成

用

实

现

系

统

切

换

各阶段验收

项

目

验项目最终验收

收

阶

移交技术支持部门

段

12项目进度控制

项目的跟踪与监控是在项目执行过程所选定的关键点或里程碑上，将工作产

品的实际规模、工作量、成本和进度计划与项目计划列出的相比较，以确定工作

进展情况。其目的是，当项目进程明显偏离计划时，采取相应调整措施或改进过

程运行效能，从而增加项目过程的透明度，使得对项目的管理能够起到切实有效

的作用。

L2.L项目进展跟踪

项目计划跟踪周期性的跟踪任务（含进度和工作量）、费用、资源、工作成果、

风险情况等，及时了解项目的实际进展情况，为持续过程改进提供有价值的数据。

1.2.2.项目例会

项目例会是XXOO公司是常规项目管理过程的一部分。会议指出活动的实

际状态，并与计划相对照，同时要识别问题；对已知的问题、风险、规模和进度

进行跟踪和纠正；识别和记录新的问题和风险；调整后继任务计划并通知受影响

到相关人员。通常每周五下午举行。项目经理每两周邀请卫生局项目组参加或者

直接将例会内容汇报给卫生局。

1.2.3.里程碑评审

在项目的早期阶段，分别在本项目的需求分析完成时、系统设计完成时、编

码完成时、项目完成时来设立关键里程碑，。在每个里程碑处，也就是在项目组

准备进行下一阶段的活动之前，项目经理组织里程碑评审。由朝阳区卫生局和监

理方参与，了解和监督项目的存在的问题，共同判定是否可以进入下一个阶段。

本项目共分为5个里程碑，包括需求设计评审、系统设计评审、系统编码评

审、系统测试和产品发布评审。

124.项目状态报告

由项目经理定期完成《项目状态报告》。状态报告记录了项目的测量数据，通

常包括：标注任务的完成情况、存在问题和重要的项目或配置变更情况。状态报

告同时分发给项目组成员、软件质量保证人员、测试人员等相关人员。

项目经理定期（关键里程碑处）向客户项目组和监理方汇报。

1.2.5.项目度量

为了更好地表现项目的当前状态，更好地为将来的项目管理积累数据，更好

地预测项目，在项目执行过程中，需要收集一些数据（如计划变更所花费的时间）。

数据的收集需要项目经理和其它成员定期进行，收集到的数据由项目经理和软件

工程部进行分析，并产生相应文档。

1.2.6.项目的重估算和重计划

当项目计划与实际情况偏离20%以上时，项目经理需要重新估算任务的规模、

成本和工作量、识别风险、并修改计划或者进度表，修正其它相关文档。修改方

案要经过评审并及时通知相关组。生成《项目il划变更控制报告》。

1.3.项目质量保证

L3.1.项目质量管理标准

XXOO完全遵循GB/T19001,即2000版IS09001国家标准和美国SEICMM质

量管理体系标准.在所有项目中遵循公司的质量方针：项目全程受控，产品科学

可靠，质量持续改进，成果多方满意。实现公司的质量目标：合同执行合格率达

100%,顾客满意率达100%。

以“以顾客为关注焦点，领导作用，全员参与，过程方法，管理的系统方法，持

续改进,基于事实的决策方法,与供方互利的关系”为质量管理的原则，切实履行

“文件控制程序”，“记录控制程序”，“管理评审实施程序”，“合同承诺评审程序”,

“设计开发控制程序”，“采购控制程序”，“项目实施控制程序”等质量管理控制

程序。为项目的质量提供了系统的保障。

1.32项目质量保证的组织管理方法

我们公司在开发项目上按照规范化软件的生产方式进行生产，在生产流程上

采用CMM的标准进行。每个项目除配备了项目开发所需角色外，还专门配备了配

置管理小组、测试小组和质量保证小组确保质量管理的实施，下面针对这三种角

色进行说明：

1.3.2.L配置管理小组职责

配置管理小组是保证项目开发完毕的同时，内部文档和外部文档都同时

完成。内部文档的及时产生和规范，是保证项目开发各小组能够更好的接口

和沟通的重要前提，从另一个方面讲，也是保证T程不被某个关键路径所阻

塞而延滞的前提。如上所述，配置管理小组还是保证质量保证小组得以发挥

作用的基础。配置管理小组的主要职责包括：完善各个部门发送需要存档和

进行版本控制的代码、文档（包括外来文件）和阶段性成果；对代码、文档

等进行单向出入的控制；对所有存档的文档进行版本控制；提供文档规范,

并传达到开发组中。

1.3.2.2.测试小组职责

测试小组作为质量控制的主要手段，负责软件的测试设计和执行工作。

如同软件开发一样，测试在执行之前，同样需要进行测试计划和测试策略的

设计，通常情况下测试可以分为如下几种类型，如：正确性测试、功能性测

试、性能测试、安全测试和系统测试等。而这些测试均需要在测试计划和测

试策略中进行描述用以指导测试小组成员进行测试用例编写和测试执行。程

序员在交给测试人员之前是进行过一定的单元测试，确保程序编译、运行正

确。

测试人员根据详细设计的文档对软件要实现的功能进行一一测试，保证

软件的执行正确的实现设计要求，在此也只证明了软件正确的反映了设计思

想，但是否真正反映了用户的需求仍需要进一步的功能性测试。

测试人员只有根据软件需求规格说明书所提及的功能进行检测，才能确

保项目组开发的软件产品满足用户需求。在正确性测试完成之后，需要测试

的是软件的性能，软件的性能在本项目中占有重要的地位，性能要求有可能

改变软件的设计，为避免造成软件的后期返工，测试在性能上需要较大的侧

重。如果有必要的话，测试小组还需要做安全测试，以确保系统使用安全可

靠。

1.3.23.质量保证小组职责

质量保证小组昨为质量保证的实施小组，主要职责是保证软件透明开发

的主要环节。在项目开发的过程中几乎所有的部门都与质量保证小组有关。

质量保证小组对项目经理提供项目进度与项目真正开发时的差异报告，提出

差异原因和改进方法C

项目进度被延滞或质量保证小组认为某阶段开发质量有问题时，提请项

目经理、项目负责人等必要的相关人员举行质量会议。解决当前存在的和潜

在的问题。质量保证是建立在文档的复审基础之上，因而文档版本的控制，

特别是软件配置管理，直接影响软件质量保证的影响力和力度。

质量保证小组的检测范围包括：

＞系统分析人员是否正确的反映了用户的需求；

＞软件执行体是否正确的实现了分析人员的设计思想；

＞测试人员是否进行了较为彻底的和全面的测试；

＞配置管理员是否对文档的规范化进行的比较彻底，版本控制是否有效。

133.项目质量保证措施

XXOO公司严格遵守在软件开发供应和维护中的使用指南中的计算机软件质

量管理和质量保证标准部分，从管理职责、质量体系、合同评审、设计控制、文

件和资料控制、采购、产品的控制、项目实施控制、不合格品的控制、纠正和预

防措施、质量记录的控制、内部质量审核、和分析改进的实施、培训、服务、统

计系统等方面对软件质量进行了要求和系统管理。

•遵循质量管理的基本原则

以顾客为关注焦点、领导作用、全员参与、过程方法、管理的系统方法、持

续改进、基于事实的决策方法、与供方互利的关系。

•软件质量因素

1）正确性：系统满足规格说明和用户目标的程度，即，在预定环境下能正

确地完成预期功能的程度。

2）健壮性：在硬件发生故障、输入的数据无效或操作错误等意外环境下，

系统能做出适当响应的程度。

3）效率：为了完成预定的功能，系统需要的计算资源的多少。

4）完整性（安全性）：对未经授权的人使用软件或数据的企图，系统能过控

制（禁止）的程度。

5）可用性：系统在完成预定应该完成的功能时另人满意的程度。

6）风险：按预定的成本和进度把系统开发出来，并且为用户所满意的概率。

7）可理解性：理解和使用该系统的容易程度。

8）可维修性：诊断和改正在运行现场发现的错误所需要的工作量的大小。

9）灵活性（适应性）：修改或改进正在运行的系统需要的工作量的多少。

10）可测试性：软件容易测试的程度。

11）可移植性：把程序从一种硬件配置和（或）软件系统环境转移到另一种

配置和环境时：需要的工作量多少。有一种定量度量的方法是：用原来

程序设计和调试的成本除移植时需用的费用。

12）可再用性：再其他应用中该程序可以被再次使用的程度（或范围）。

13）互运行性：把该系统和另一个系统结合起来需要的工作量的多少。

1・3・3・1.项目进度的质量保证

项目进度是项目进行是否顺利的最直观表现。要保证项目进度，首先要保证

项目开发计划尽可能合理。

在项目计划制定初期，由质量保证小组组织召开的项目计划评审会，邀请公

司技术专家、用户以及项目组成员一起讨论项目计划的可行性，会议上各抒己见,

会后由指定的记录员形成质量记录，发送给相关人员，对其计划中不合理的地方

进行修改完善，并由质量保证人员对其结果跟踪，以确保项目计划完整性、可行

性，完善后的计划交由配置管理人员进行版本控制。

然而在计划实施过程中，计划不是“固定化工项目计划以里程碑为界限，将

整个开发周期划分为若干阶段。根据里程碑的完成情况，适当的调整每一个较小

的阶段的任务量和完成的任务时间，这种方式非常有利于整个项目计划的动态调

整。也利于项目质量保证的实施。

实际运作中，当质保小组发现计划实施的差异后，报告项目经理，由项目经

理组织负责对计划进行周期性维护，对于已经变动的计划由质保小组协助配置管

理小组完成版本控制。

1・3・3.2.项目开发各阶段的质量保证

13.3.2.1.编制软件质量保证计划

软件质量保证计划：SoftwareQualityAssurancePlan,简称SQAPo

13.3.2.2.变更控制过程

项Fl成员对已创建或维护的工作产品提出变更请求和管理变更时使用的过程。此过

程促进了变更请求在项日成员之间的沟通，以解决变更请求，已报告的问题，以及被提

出变更的结果存在的不确定性提供了共同的过程。示怠图：

请求变更

挂起

拒绝

结束变更

a.提交《变更申请单》

变更提出者提交《变更申请单》。《需求变更申请单》要发送给SCCB的所有

成员。

b.初步判断变更的可行性

由软件变更控制委员会（SCCB）的核心成员对变更的可行性进行初步分析和

判断，检查变更内容是否合理，描述是否会有歧义。可行性的分析结果为：

A可行：进入下一个流程。

＞不可行：要说明原因。

c.评估需求变更

SCCB的核心成员给SCCB成员发出通知，启动评估活动。评估结果要包含以

下内容：

＞评估的是哪方面的影响。

＞风险。

＞评估工作量时考虑了对哪些配置项的变更。

＞评估的最终结果。

评估结果要提交给SCCB作为决策依据。

d.做出决策

SCCB的核心人员参考评估结果，对是否接受变更进行决定，结果为：

•接受并实施(Accepted-now):完全接受，并在当前版本实施。

•以后实施(Accepted-later)：完全接受但是要留到后续版本才实施

的变更申请。

•拒绝变更(Rejected)：说明拒绝的理由。

•挂起(Suspended)：表示悬而未决的变更申请。SCCB应该定期关注

这种状态的申请。

•部分接受(Accepted-partial)：说明不接受的理由和内容，并给出

SCCB期望的结果。

此外，SCCB的核心人员还要根据变更影响的程度决定是否需要对变更后的

需求进行评审.如果需要评审，通知高级经理，由高级经理组织评审八

最终决策结果要通过邮件通知给所有变更影响人员，并列出下一步的任务和

任务的责任人。

e.变更记录和执行

根据被变更的需求所处的状态，对从需求到当前状态涉及到的所有配置项进行修改，在

当前状态以后的后续任务按照正常的流程执行，不在变更的跟踪范围内。

1.33.2.3.标准、条例和约定

列出软件开发过程中要用到的标准、条例和约定，并列出监督和保证书执行

的措施。

质量管理标准

GB/T19001质量管理体系要求(idtISO9000:2000)

SJ/T11235-2001软件能力成熟度模型(CMM2级)

计算机软件工程规范国家标准

・计算机软件开发规范,软件技术\、标准号：GB8566-88

•软件工程犬语\\、标准号：GB/T11457-95

•软件工程标准分类法'计算机软件'软件技术'分类系统\、标准号：

GB/T15538-95

•计算机软件需求说明编制指南、供应和需求,手册\、标准号：GB9385-

88

•计算机软件产品开发文件编制指南'产品设计'生产'文献'编辑'手

册\、标准号：GB8567-88

・计算机软件开发规范'软件技术\、标准号：GB8566-88

•计算机软件测试文件编制规范\文件结构（计算机）'书写'测量\、标

准号：GB9386-88

•计算机软件质量保证计划规范\、标准号：GB/T12504-90

•计算机软件配置管理计划规范'布置\、标准号：GB/T12505-90

•软件工程标准分类法'计算机软件'软件技术'分类系统'、标准号：

GB/T15538-95

通信行业标准

•防火墙设各技术要求，编号：YD/T1132-2001；

•数据通信名词术语，编号：YD/T1133-2001；

•数字数据网（DDN）节点机技术要求及测试方法，编号：YD/T1135-2001；

•综合业务数字网（ISDN）基本速率终端适配器（TA）技术要求及测试

方法，编号：YD/T1136-2001；

•用于局域网与分组交换公用数据网互连的网桥/路由器入分组交换

公用数据网技术要求和检测方法、标准号：YD/T869-1996；

•公用分组交换数据网工程设计规范、标准号：YD5022-96；

公安部网络安全标准

•GA163-1997计算机信息系统安全专用产品分类原则；

•GB17859-1999计算机信息系统安全保护等级划分准则；

•GB/T17900-1999网络代理服务器的安全技术要求；

•GB/T18018-1999路由器安全技术要求；

•GB/T18019-1999信息技术包过滤防火墙安全技术要求；

•GB/T18020-1999信息技术应用级防火墙安全技术要求。

1.3.3.2.4.评审和检查

XXOO公司规定项目所要进行的技术和管理两方面的评审和检查工作，并编

制或引用有关的评审和检查堆积以及通过与否的技术准则。至少要进行下列各项

评审和检查工作：

软件需求评审sofhvarerequirementsreview

在软件需求分析阶段结束后必须进行软件需求评审，以确保在软件需求规格

说明书中所规定的各项需求的合适性。

概要设计评审preliminarydesignreview

在软件概要设计结束后必须进行概要设计评审，以评价软件设计说明书中所

描述的软件概要设计的总体结构、外部接口、主要部件功能分配、全H数据结构

以及各主要部件之间的接口等方面的合适性。

详细设计评审detaileddesignreview

在软件详细设计阶段结束后必须进行详细设计评审，以确定软件设计说明书

中所描述的详细设计在功能、算法和过程描述等方面的合适性。

软件验证与确认评审softwareverificationandvalidationreview

在制订软件验证与确认计划之后要对它进行评审，以评价软件验证与确认计

划中所规定的验证与确认方法的合适性与完整性。

功能检查functionalaudit

在软件释放前，要对软件进行功能检查，以确认已经满足在软件需求规格说

明书中规定的所有需求。

物理检查physicalaudit

在验收软件前，要对软件进行物理检查，以验证程序和文档已经一致并已做

好了交付的准备。

综合检查comprehensiveaudit

在软件验收时，要允许用户或用户所委托的专家对所要验收的软件进行设计

抽样的综合检查，以验证代码和设计文档的一致性、接口规格说明之间的一致性

（硬件和软件）、设计实现和功能需求的一致性、功能需求和测试描述的一致性。

管理评审managementreviews

要对计划的执行情况定期（或按阶段）进行管理评市：这些评审必须由独立

于被评审单位的机构或授权的第三方一一监理公司来主持进行。

1.3.3.2.5.记录的收集、维护和保存

在项目质量保证的管理过程中，XXOO指明了需要保存的软件质量保证活

动的记录，并指出用于汇总、保护和维护这些记录的方法和设施，并指明要保存

的期限。

1・3・3・3.系统维护的质量保证

在我们公司，技术服务小组的任务一方面是保证对项目客户的跟踪服务，另

一方面是确保该项目其它的开发人员从项目中尽快的解脱出来以便投入到下一

个项目的开发中。所以通常项目技术服务小组成员主要由项目组的少部分开发人

员和专门的客户服务部门人员共同承担完成C他们不仅了解软件的核心内容，而

且与客户也不陌生，以便能够以最快的速度修正错误。对于一般性的错误，如操

作不当等引起的问题，全部由技术服务小组执行完成,但需要用户测试确认上线。

如果较大的修改则需要走变更控制流程，用户或者技术服务人员填写变更申请，

经专家会议讨论分析可行方案在由技术服务小组实施，通过测试后方可提交用户。

1.3.3.4.配置管理

配置管理一一实施软件质量管理的关键。在质量体系的诸多支持活动中，配置管理处在

支持活动的中心位置，它有机地把其它支持活动结合起来，形成一个整体，相互促进，相互

影响，有力地保证了质量体系的实施。

1.33.4.1,配置管理的基本目标

XXOO公司软件配置管理的基本目标：

目标1:软件配置管理的各项工作是有计划进行的。

目标2:被选择的项目产品得到识别，控制并且可以被相关人员获取。

目标3:已识别出的项目产品的更改得到控制。

目标4:使相关组和个人及时了解软件基准的状态和内容。

1.3.3.42软件配置管理内容

软件配置管理（SoftwareConfigurationManagement）的目的是在整个软

件生命周期中建立和维护软件项目中的产品的完整性。它包括标识在给定时间

点上软件的配置，系统地控制对配置的更改，并维护在整个软件生命周期内配置

的完整性和可跟踪性。因此，软件配置管理可以分为两方面的内容，一是配置项

的识别和管理，另一方面是变更管理。

a.配置项管理

软件的配置项管理的基本流程可如《图1＞所示，该流程描述了软件工程组在

进行开发过程中，生成软件工作产品，识别配置项，为配置项创建基线。配置管

理项最显著的特征就是包含版本号或发布日期。实际项目管理经常不知道该如何

识别区分配置项和基线。

项目启动

各类项目活动

_____________________

生成软件工作产品

＜例如；文档、源代码）

基线配置项（如：已完成的\厂非基线配置项（如:一、

工件或通过复审的工件》）（正在开询工件）J

〈图1＞

b.变更管理

上图描述了纳入配置管理的配置项进行变更的完整流程。根据新需求、项目

进度报告、客户意见反馈、软件工作产品复审记录等不同的原因提出变更申请,

由项目小组或软件变更控制委员会（SCCB）分析其影响，确定变更请求的拒绝、

接受或搁置，并根据不同的决定进行不同的处理，一直到变更请求被处理。

一旦采用了严格的变更控制管理流程，才能了解变更造成的影响，所有项目

组成员才了解变更，形成共识，接受变更。缺少对变更有效的控制，往往会造成

配置管理的无序，导致项目返工、延期，甚至失败。

<图2>

1.3・3.4.3.软件配置管理方法

a.项目设定配置管理人员，以VisualSourceSafe为配置管理工具，根据项

目计划拟定项目的配置管理计划文档，以MicrosoftProject拟定项目配置活动

的进度表。

b.项目的配置管理计划包含以下内容：配置管理工具、目录结构、识别配置

项的方法、配置项命名、创建配置管理库、基线管理、配置审计、配置状态报告、

变更管理。

c.在VisualSourceSafe创建项目的VOB（扳本对象库），创建项目小组成

员的工作区和集成区，项目组成员只在各自的工作区Checkin或Checkout操

作，由配置管理人员进行合并，标识出软件配置项。

d.由配置管理人员负责在适当的时机（如:里程碑处或迭代结束）创建基线，

晋升基线，下降基线，并由其负责备份和恢复基线。

e.根据配置管理计划对项目的配置项和基线定期（或里程碑处）进行审计，

以验证其是否与项目配置计划或项目开发计划一致。

f.所有的变更请求首先向配置管理人员提出，由配置管理人员对变更请求进

行分析确定其影响，组织变更评审小组。

g.一旦同意变更，由配置管理人员Checkout需变更的配置项，然后对配置

项进行变更，变更完成后再由配置管理人员Checkin到配置管理库中.

h.由软件质量保证（SQA）人员定期审计配置管理的活动。

1.4.项目风险控制

在项目实施过程中，非常注重项目风险的识别，并根据识别的风险及时采

取各种应对措施，将项目风险消除在萌芽状态，确保能够按时按质交付满意的

系统与服务。

1.4.1.项目风险分析

综合业务上报系统项目的实施过程中，可能存在着技术风险、和管理风险,

风险的具体内容以及对项目的影响详见下表:

影响程

序号风险名称风险分类风险描述风险影响概率风险指数

度

需求开发有局

限，模块范围项目后期反

1需求风险技术类定义不合理，复修改，进0.66036

或模块业务需度、成本增加

求分析不到位

由于测试与修

改组织不利，

2测试风险技术类质量、成本0.63036

造成测试周期

拖延

人力资源项目组人员发项目进度超

3管理类0.54020

风险生变动期

测试修改周

4编码风险技术类代码质量失控0.44016

期延长

公司对项目组

成员增加计划

项目进度延

5计划风险管理类外任务安排，0.53015

期

影响项目组原

定计划的工作

底层关键技术

改造无法在预项目进度延

6开发风险技术类0.53015

订时间内完全期

实现

注：影响程度按人日估计。

L42项目风险对策

根据以上风险分析，采取以下几个方面的措施，确保项目的顺利实施。

序号风险名称风险指数风险应对策略责任人

1需求风险36需求评审、同类产品对比项目经理

优化测试修改工作流程，规范过程

2测试风险36测试负责人

管理

人力资源风确保项目组人员稳定，并招聘备选

320项目部经理

险人员

项目经理、

4编码风险16制定并落实代码互查、走查制度

QA

5计划风险15公司层面避免副总

对关键技术排优先级，根据项目时

6开发风险15项目经理

间要求，分步骤推出可运行版本

1.5.项目应急方案

本方案从国产民机运行故隙事故数据库系统及应用平台项目应急方案的条

款内容、应急计划的制定、执行的环境和条件要求以及应急条款执行时责任和义

务几个方面进行详细的规定。本方案分为数据安全应急方案、系统应用应急方案、

运行环境应急方案。

1.5.1.总流程

L5.1.1.系统出现异常

工作内容：当系统的使用人员和系统技术人员发现系统在使用中出现问题和隐患

时，应立即上报专门的系统管理员。

责任人：使用人员和系统技术人员。

工作成果：必要时可法行书面汇报。

L5.1.2.评估问题和划分

工作内容：当系统管理员接到问题汇报时，应在一定的时限内进行处理，分析系

统出现问题的原因，并将问题进行大体的分类，判断是否启动应急处理流程方案

和启动那一类应急处理方案和流程。

责任人：系统管理员。

工作成果：对问题进行描述和分析。

工作建议：系统管理员如果对问题的评估归类有困难，在项目质保期内可要求项

目乙方帮助处理。

1.5.13.数据安全应急

1.5.L3.1.数据安全问题

工作内容：系统管理员分析系统出现的数据安全诃题，对问题进行具体的定位。

责任人：系统管理员。

工作成果：对问题进一步描述。

工作建议：系统管理员如果对问题的具体定位有困难，在项目质保期内可要求项

目乙方帮助处理。

1.5.1.3.2.启动数据安全应急方案

工作内容：执行数据安全应急处理方案。

责任人：系统管理员。

工作成果：问题已经处理，并对处理过程进行详细记录。

工作建议：系统管理员如果对问题的处理有困难，在项目质保期内可要求项目乙

方帮助处理“

L5.1.4.系统应用应急

1.5.L4.1.系统应用问题

工作内容：系统管理员分析系统出现的系统应用句题，对问题进行具体的定位。

责任人：系统管理员。

工作成果：对问题进一步描述。

工作建议：系统管理员如果对问题的具体定位有困难，在项目质保期内可要求项

目乙方帮助处理。

1.5.1.4.2.启动系统应用应急方案

工作内容：执行系统应用应急处理方案。

责任人：系统管理员。

工作成果：问题已经处理，并对处理过程进行详细记录。

工作建议：系统管理员如果对问题的处理有困难，在项目质保期内可要求项目乙

方帮助处理。

1.5.1.5.运行环境应急

1.5.1.5.L运行环境问题

工作内容：当系统管理员分析系统出现的系统运行环境问题，对问题进行具体的

定位。

责任人：系统管理员。

工作成果：对问题进一步描述。

工作建议：系统管理员如果对问题的具体定位有困难，在项目质保期内可要求项

目乙方帮助处理。

1.5.1.5.2.启动系统应用应急方案

工作内容：执行运行环境应急处理方案。

责任人：系统管理员。

工作成果：问题已经处理，并对处理过程进行详细记录。

工作建议：系统管理员如果对问题的处理有困难，在项目质保期内可要求项目乙

方帮助处理。

L5.1.6,其他情况应急

1.5.L6.1,其他未知问题

工作内容：当系统出现意外的紧急问题时，即本应急方案未制定该问题的事先应

急方案时，系统管理员应对本问题划分为“其他未知问题”，并上报相关主管领

导。

责任人：系统管理员。

工作成果：对问题进行详细的描述。

工作建议：系统管理员如果对问题的具体定位有困难，在项目质保期内可要求项

目乙方协助处理。

1.5.1.6.2.指定临时应急方案

工作内容：针对出现的意外问题制定相应的应急方案。

责任人：相关主管领导。

工作成果：应急方案。

工作建议：在项目质保期内可要求项目乙方帮助处理。

1.5.1.6.3.进行处理

工作内容：执行意外问题应急方案。

责任人：相关主管领导。

工作成果：问题己解决，并对处理过程进行详细」,己录。

工作建议：在项目质保期内可要求项目乙方协助。

L5.1.7.处理结果记录归档管理

工作内容：需要对问题的过程的记录进行归集,对处理结果进行记录并归档管理。

责任人：系统管理员。

工作成果：问题处理过程和结果记录。

1.5.2.数据安全应急方案

1.5.2.1.非法入侵

情况描述：网络管理员或系统管理员发现有非法用户登录系统，登录系统后

非法执行系统功能，并篡改系统数据时，视为紧急情况。

应对方案：

1).如果系统管理员处理此情况有困难，可要求应用软件实施商帮助处

理；

2).如果能够根据系统的相关日志进行针对性恢复，则属上策；

3).否则，将系统恢复到最近的一个备份点；

4).注意：尽量不要整库恢复，一定要将损失降到最低，至少要能定位

到数据表进行恢复；

5).注意：必须将系统数据恢复到应用系统认可的数据同步状态，即恢

复后要进行相关的功能测试。

1.5.2.2.数据崩溃恢复

情况描述：网络管理员或系统管理员发现数据库管理系统遭到严重破坏时,

并且试图进行各种技术处理无法恢复时，视为本紧急情况。

应对方案：

1).如果系统管理员处理此情况有困难，可要求应用软件实施商帮助处

理；

2).重新安装和配置数据库服务器；

3).将系统恢复到最近的一个备份点。

1.5.2.3.远程容灾

情况描述：当发生非常意外情况导致本地数据和设备完全遭到破坏时，视为

本紧急情况。此时启动远程容灾应急方案。

应对方案：

1).应该事先建立异地系统备份机制，否则，本方案无法执行；

2).将系统切换到异地服务器继续运行应用系统；

3).重新建立总部数据中心；

4).根据有关数据库服务协议，要求数据库供应商提供数据恢复技术服

务；

5).应用ORACLE远程备份系统恢复数据库。

1.5.3.系统应用应急方案

1.5.3.1.非法入侵

情况描述：网络管理员或系统管理员发现有非法用户登录系统，或者登录系

统后非法执行系统功能，视为本紧急情况。

应对方案：

1).网络管理员或系统管理员应及时保护操作系统、数据库系统、中间

件系统和应用软件系统的相关日志；

2).检查系统重要数据是否被非法篡改；

3).及时邀请项目的应用软件实施商到现场，进行评估和处理；

4).评估安全问题出现在那个环节，判断问题的严重行，决定是否需要

咨询信息安全专家，并进行处理；

5).评估应用软件实施商应该进行那些系统安全方面的改进；

6).应制定一个临时应对措施。

1.5.3.2.系统崩溃恢复

情况描述：网络管理员或系统管理员发现应用系统遭到严重破坏时，并且试

图进行各种技术处理无法恢复时，视为本紧急情况。

应对方案：

1).如果系统管理员处理此情况有困难，可要求应用软件实施商帮助

处理。

2).重新安装中间件系统；

3).重新配置安装中间件系统：

4）.安装和配置应用系统的中间层组建;

5）.对系统进行全面测试。

1.5.4,运行环境应急方案

L5.4.1.网络紧急情况

情况描述：网络系统，包括保障系统运行的局域网、广域网和相关的网络设

备出现故障或可靠性严重下降时，视为本紧急情况。

应对方案：

在力所能及的职权范围内，启动本管理流程：

推荐采用冗余网络。中心服务器到下属单位的之间平常使用电力城域网

连接，另外可考虑使用电信的ADSL或DD7专线，通过加密的VPN设备

形成第二条辅助的VPN专网。当电力网络繁忙或出现故障时，用户客户端

可通过辅助网络连接。从而不影响正常业务工作。

网络方面如下应急方案：

1）当客户端连接服务器时，经过长时间等待后，报服务连接失败的错

误。此时有可能是网络不通。请安如下步骤操作：

首先请尝试ping本地局域网的其它计算机，如果不通，请联系相关部

门及时处理。如果能连通，请ping总部的应用服务器，如果能通，则可能

属于软件系统的故障，寻求软件实施商的帮助。如果不通，可能是总部网

络故障。请求总部相关的系统管理员解决，并启用备用网络连接。

2）当客户端连接时，出现了数据库连接失败的提示时，请ping数据库

服务器，如果不通，可能是数据库群集的网络出现故障，请求总部相关

的系统管理员解决。如果能连通，可能是数据库故障。

3）要考虑对网络设备的冗余,对网络设备进行备份，主要是对交换机、

防火墙、路由器等设备采用备份策略，解决网络设备的单点故障，保证

网络可靠的运行。

4）根据网络设备的售后服务协议，及时进行维修。

5）如果是线路故障，也要及时通知有关部门进行维修。

L5.4.2,服务器和其他硬件紧急情况

情况描述:数据库服务器、中间件服务器、域控制器等硬件设备出现故障时，

视为本紧急情况。

应对方案：

1).如果是一人硬件服务器出现故障时，系统将瘫痪，如果系统是热备或

群集，当发现出现其中一个硬件服务器出现问题时，系统虽能工作，