高级软考论文范文通用模板

摘要

2010 年3 月，我参加XX省XX市的XX移动运营商的集团业务演示系统的开发工作，并在项目开发与实施过程中担任项目经理一职。

该项目力图通过集团业务演示系统的建设， 实现向潜在的企业集团客户展示应用丰富的集团商旅业务与实时体验丰富多彩的移动办公业务，如移动OA，手机小额支付，手机无线远程抄表等，实现业务的推广和潜在客户挖掘的目标， 进而达到提高企业销售额的目的。

2011 年1 月本项目顺利通过了甲方的正式验收。本文结合笔者实践，以XX 省移动运营商集团业务演示系统项目的开发为例，讨论了项目范围管理的相关过程和技术。

包括，项目范围的计划的制定和定义，WBS 的创建，范围核实与控制等。并着重叙述了项目范围定义和WBS创建的方法，并结合项目实践阐述了对项目范围控制的相关过程与技术。最后针对项目范围控制中存在一些不足与缺点，提出了今后的改进思路。

计划阶段做好范围的定义和WBS的分解工作。

项目初期阶段，我带领我的团队根据项目章程和初步的项目范围说明书进行了项目范围管理计划的制定。

我们通过标准的计划表格和模板制定了项目管理计划，并广泛听取了公司内部资深专家的意见， 在项目会议上对项目范围管理计划进行了相关的修订和完善， 经过项目组全员及专家的评审后， 纳入基线。

项目需求的获取和定义阶段， 我主要采取了客户访谈， 小组焦点会议和文档考古的方式进行需求的获取和收集。其中着重采用了用户访谈的方式对用户需求进行了全面的收集。

对于客户访谈，我们主要以客户访谈会议的形式进行，进行多次严肃正规的用户访谈会议，对逐个关键需求和模糊不清的需求进行确认和验证，以防止在需求理解方面出现分歧的现象。

最终我们根据前期收集的所有需求结果进行深入的分析和研讨，形成详细的项目范围说明书后，召集公司内行业专家及客户方代表，技术专家和监理方代表等成员对详细的项目范围说明书进行评审。

在项目的项目范围说明书的评审阶段，我们得到了我司专家及客户方代表和技术专家多方面好的建议和意见， 弥补了我们对事前制定的详细项目范围书里诸多方面的不足和对需求深入理解上的缺失。

经过多次的修改和完善后，通过了所有技术专家及客户代表的的评审，纳入范围基线， 作为项目范围控制与管理的基准，日后所有的变更都要通过严格的变更控制程序进行管理。

在WBS的创建阶段， 详细项目范围说明书是进行项目工作分解的主要一步。

典型的工作分解结构有以下三种方式：

以项目色生命周期为第一层

可交付物为第二层

以项目的可交付为第一层

以子项目为第一层

以可交付物为第二层

结合本项目的规模和特点，本人在创建工作分解结构的时候，主要采用第二种方式，以各模块的可交付为第一层，然后采用自上而下的分解方式，逐个分解。

在创建WBS 的时候，确保每个可交付物的最底层都分解到工作包的程度，且工作包应该是一个人一个工作日到十个工作日内可完成的工作量。

确保每一个工作包都是可管理的，可进行独立资源和时间估算的，每一个工作包都只从属于一个上层对象，避免交叉从属造成工作的混乱。

其中同一层的工作包应该具有相同的性质和属性，针对每个工作包要能确认不同的工作内容和责任人。

比如：远程无线抄表业务模块，分为硬件集成，硬件开发，软件开发，UI 界面设计等。

前端操控模块分为：

一级目录：各个子业务体验的接入接口

二级目录：针对单个业务的概述和介绍

三级目录：为每个子业务具体体验的触发按钮：业务体验按钮，短信互动按钮等。然后各个目录下针对不同的工作量和功能再进行细分。

通过滚动波式计划对项目的近期工作和远期工作进行不同详细程度的分解， 对于近期马上需要实施的工作分解的足够详细，对于周期比较远的工作， 进行粗略的分解和跟踪。

通过以上工作得到本项目的WBS，WBS字典和范围基准。同时基于WBS词典，把分解好的每个工作包都对应到相应的责任人进行管理和监控。

实施阶段定期和客户进行阶段性可交付物的范围确认和核实。

基于本项目的特点， 不同的干系人对项目的期望可能会不一致甚至会产生矛盾，造成客户对需求的变更频繁，因此直接影响到我方软件开发人员与客户需求的理解可能会产生分歧和模糊不清的风险。

基于这些风险， 我采用了在项目实施阶段，定期或者不定期地对项目的可交付成果和客户进行现场确认和核实， 让客户尽早地参与到每一个开发模块中来，尽早发现问题，消除分歧。

如此，通过定期或者不定期检查的方式， 以防止出现对项目范围的理解变差而产生返工的现象。

以此也能及时了解到，在项目各个阶段各干系人对项目的期望，以便作为项目经理的我及时管理干系人期望，调整项目管理策略，尽量满足所有干系人的期望。

如：在无线数据采集模块开发过程中， 及时邀请客户方的技术专家和客户代表莅临现场确认。对于该模块即使我们完成的可交付物和项目范围说明书上描述的完全一致，但是客户代表还是感觉缺少一个过程化的体验。

他觉得无线数据采集在移动终端上的体现，应该是一个过程化的操作， 不应该以一个简单的“数据采集”按钮执行后， 马上就显示出所采集的数据， 而是要尽量体现出数据采集的过程化和真实性。基于客户代表的合理建议，本人立即召集软件开发人员和监理方代表进行讨论了，并以变更申请CR的形式及时走变更控制流程。

把方案调整为，数据采集模块在移动终端上打的体现以只管的进度条加百分比的形式进行详细进度的显示， 提示数据采集完毕后， 显示采集数据。此方案的及时调整很快得到了客户方的认可和赞同。

因此在开发工程中，让客户尽早的参与进行可交付物范围的确认和核实，也大大提升了项目实施的效率，避免后期返工，降低了项目开发成本。

项目整体工程中加强对变更的严格控制与管理。

对于项目实施工程中频繁变更现象，本人吸取了以往项目中的经验和教训。

在项目计划阶段即制定严格的变更控制流程，所有内部外部或或者由客户方发起的变更请求，都必须经过CCB的评审。

通过变更请求的提出，变更影响的分析和评估，然后由变更控制委员会CCB进行是否变更的决策后，方能进行变更的实施，变更在实施以后一定要通过进行变更的验证，然后通过配置管理系统对所有信息进行规范的存档与配置。

通过严谨的变更控制流程， 以防止项目的镀金和项目范围的蔓延。

所有的变更批准以后， 必须通过配置管理系统进行统一的管理和归档，同时更新WBS和WBS词典，调整范围基准，刷新项目管理计划。

如：在业务演示模块的开发过程中， 某开发人员发现对个演示界面增加一个该运营商的LOGO，不仅会增强画面的充实感，而且对提升客户感知度也会起到事半功倍的效果。但是在WBS词典和详细的项目范围说明书里面均没有提及该项功能。

因此此行为属于项目镀金行为，应该明令禁止，及时予以纠正，并通告项目组所有成员引以为戒，以增强全员对项目范围的管理意识，严格以WBS词典和项目详细范围说明书为基准，进行规范的作业施工。对需要更变的需求，均需通过CCB评审决策后方能执行。

结尾：

2011年1 月经过项目组历时9 个月的时间的努力，项目最终成功验收，应用与XX市XX移动运营商的集团业务展示厅，得到了客户方领导和使用人员的高度赞赏和一致好评。

到目前为止系统运行正常。同时由本人带领的团队也获得了公司方面的金牌团队奖励。

综上所述，该项目为一个智能化移动互联网应用集成项目，涉及的项目干系人多，项目范围繁琐而复杂，因此给项目的实施和管理控制工作带来了较大的困难。

项目最终能够保质保量的按期交付，得益于我的项目中有效的范围管理，采用科学的管理方法，工具和技术，为项目带来了事半功倍的效果。

但是在项目的管理工程中还是有一些纰漏，一些不如人意的地方。如，在项目的开发与实施过程中会出现项目镀金的现象，因项目需求的不明确导致后期范围变更的频繁发生，因甲方项目干系人的复杂，导致对项目目标的含糊不定等等问题。

针对这些问题在今后的工作中需要进一步改进，并制定严谨的需求开发与管理机制，加强对需求的管理，防止需求的失控，及严格的变更控制程序，防止项目范围的蔓延。

项目管理是一个长期改进的过程，我会在长期的项目实践工作中总结经验教训，不断学习与提升项目管理能力。