信息系统项目管理师论文-范围管理

范围管理

2012年12月，XX公司作为系统集成项目的总包商承接

了XX发电集团所委托的远程智能维护系统开发项目，我作为项目经理全程管理该项目。该项目的主要目标是对发电机组实现远程监测、诊断并主动修复，使设备达到近乎零故障的目的。该项目成立了三个子项目，历时一年，交付一套智能维护系统，实现对火力、水力和风力三种发电机组进行远程诊断修复。

本文结合作者的实践经验，从以下几个过程对项目的

范围管理进行论述：在需求分析阶段要求项目组成员细致分析需求并且逐条和相关干系人进行确认，项目未出现由于需求理解错误而造成的变更；在项目中制定了详细的WBS，工作包分解到每人每周的工作量，通过WBS项目成员对自己的工作目标有清晰的认识；成立了项目变更控制委员会，有效的控制了项目过程中可能出现的需求变更，保证了项目按时保质完成。

正文 24 × 25

据某发电集团数据统计显示，设备的

60%

的维护费用

是由突然故障停机引起的，而且设备停机所带来的损失更为巨大，进口设备的维护问题则更为复杂和困难，远距离跨国维修的方式既费时又昂贵，加上发电厂地域分布广泛，如何快速解决设备故障问题成为当务之急，于是该发电集团提出建设基于

Internet

的远程智能维护系统，也是我国智

能电网建设和发展的战略要求。

2012年12月，XX公司作为系统集成项目的总包商承接

了XX发电集团所委托的远程智能维护系统开发项目，我有幸作为项目经理全程负责项目管理工作。该项目以XX发电集团旗下

ABC

三个省的火力、水力和风力三种共24组发电

机组为标的，进行远程智能维护试点。基于主动维护模式（PAP）理念的智能维护系统（IMS），重点在于信息分析、性能衰退过程预测、维护优化、应需式监测的技术开发与应用，设备的维护体现了预防性要求，结合infotronics技术（融合互联网、非接触式通讯技术、嵌入式智能电子技术），智能维护系统可通过Web驱动的Device to Business（

D2B

）信息平

台对设备进行不间断的监测诊断和性能的退化评估，并在设备出现故障之前作出维护决策，将其修复到正常状态，从而使发电机组设备达到近乎零故障（Near Zero Breakdown）的目的。

该项目涉及到3种不同类型的发电机组及配套的相关

设备，按照技术相关性成立了三个子项目。从2012年12月正式开工到2013年11月结束，历时一年，时间质量和成本24 × 25

均达到项目要求，项目顺利通过验收。到目前为止，系统运行效果良好，期间系统所监测的发电机组将要出现的故障（系统有故障临界提示），全部由智能系统自动修复，达到项目预期，赢得各方高度好评。以下就本项目为例，从需求分析等几个方面来论述项目范围管理：

一、

细致的需求分析和确认

项目的需求分析的偏差和理解不透彻是导致项目后期

范围做变更的最主要原因，针对此点，在项目的需求分析阶段我要求分析人员对项目范围中的所有特性进行详细的需求分析，包括写作需求分析文档，硬件支持情况分析、环境分析等，这些报告完成后，我们组织需求分析人员对这些特性需求逐条和相关干系人进行确认，其中发现了3条需求理解上的不一致，经过充分的沟通后，确认是项目成员对需求理解出现偏差，并及时进行了纠正，减少了项目后期出现需求理解偏差而可能的大规模返工。由于智能维护系统需要处理大量数据，功能特性的实现依赖数据通道上各环节的高速传输，通过对硬件分析发现一款用于系统和设备之间的接口模块的性能不能满足数据流的需求，这个情况及时反馈给相关干系人，经评估认为该需求是必须实现的，于是用更高性能的接口模块来满足这个需求。

通过对需求的细致分析，提前发现了需求理解的问题

以及需求可能无法满足而造成系统功能无法实现等风险，对项目范围的控制起到了很好的作用，通过项目验收测试进行的范围确认，全部实现了项目范围的要求。 24 × 25

二、

创建工作分解结构和需求跟踪矩阵

依据项目范围说明书，按照以下步骤来创建工作分解

结构（WBS）：识别和分析可交付成果及相关工作；确定工作分解结构的结构和编排方法；自上而下逐层细化分解；为工作分解结构组成部分制定和分配标志编码；核实工作分解的程度是必要且充分的。

经过项目前期的需求调研和功能分析，系统确定开发

火力、水力和风力三个子系统的智能维护系统，根据子系统的领域，分别制定了三个子项目的WBS，采用公司的标准WBS模板的表格形式，以项目开发阶段为划分单位，每一个阶段都包括各子系统的开发内容，采用自上而下逐层分解的方法，第一层是三个子系统，第二层是数据收集、对比和处理功能，第三层是子特性，第四层是每个子特性的需求分析、设计、编码和测试工作。为了便于工作的跟踪，将工作包的粒度控制在每名开发人员一周的工作量。项目成员以WBS为开发工作的依据，在项目所有阶段都是有据可循的，有效避免了项目范围的蔓延以及由此而造成的工作量增加。

我们采用了需求跟踪矩阵的工具，对项目需求和设计、

编码、测试各阶段的输出物进行双向跟踪。需求跟踪矩阵以需求分析的编号为索引，每一个需求对应概要设计和详细设计文档中设计点的编号，对应代码的函数名称以及测试用例的编号，实现了每个阶段输出物都有需求的来源，同时每个需求都有对应的输出物。需求跟踪矩阵在项目的24 × 25

每个阶段结束前，由开发人员进行填写并确认项目的范围得到实现并且没有超过项目范围的要求。

三、

严格控制项目范围的变更

项目开发过程的范围变更对项目的进度、质量、成本

都将构成很大的威胁，我们在项目范围管理计划中明确制定了项目的变更控制方法：1、项目的需求分析文档基线化；2、对需求基线的变更需要走变更控制流程；3、成立项目CCB对项目的变更进行控制；4、CCB裁决通过的变更需要做基线的修改，并由CCB成员跟踪变更的完成情况；5、范围变更对项目后续阶段产生影响的，需要及时进行项目计划的调整。

项目需求分析文档评审通过后在

SVN

配置库上形成了

需求基线，该文档的修改通过变更控制流程严格控制。项目进行到中后期，干系人提出两个新的需求，我们根据需求变更流程，将这两个需求提交给了项目CCB进行裁决。经过CCB成员的正式会议，决议是支持一个合理的需求，否决了一个商业价值低、严重影响进度的需求。事实证明，CCB能够非常有效的控制项目需求的蔓延，抑制不适合的项目变更，有效地控制了项目范围。

结语

经过一年的项目开发建设，针对三种发电机组设备的

远程智能维护系统建成运行，到目前为止系统运行良好，达到项目预期效果，得到各方高度评价。这些成绩是和良好的项目范围管理分不开的，尤其是深入的需求分析，细24 × 25

致的WBS分解以及严格的变更控制管理，使这个技术难度高，工作量大，进度紧张的项目以很高的质量按时完成。但是项目也存在一些失误和教训：在项目中后期，项目开发人员工作量很大，对此期间变更的需求不如前期那样分析深入，造成了其中一点理解出现偏差，幸好及时发现，在项 …… 此处隐藏：1438字，全部文档内容请下载后查看。喜欢就下载吧 ……