软考高级论文《论信息系统项目的范围管理》不会写？一篇模板来参考！

相信不少备考软考高级的考生们都或多或少的在苦恼，软考高级的论文到底该怎么写？有没有一篇模板作为参考告诉我应该怎么写？不急不急，小编这就为大家准备了一篇《论信息系统项目的范围管理》的论文模板，供各位考生参考：

论信息系统项目的范围管理

【摘要】

2021 年 3 月，我作为项目经理，参与了XX 省沿海城市港口散货码头信息化系统项目的建设工作，该项目总投资 900 万，建设工期为 1 年。通过该项目的建设，实现了港口现场管理信息化的扩展，提高了港口装卸效率，减少了工作中人为因素的影响，各部门之间步调一致，简化了工作程序。在充分调研国内外散杂货理货业务最新作业模式的基础上，结合港口的实际情况，实现码头现场电子理货生产作业。该项目于 2022 年 4 月，通过了业主方的验收，赢得了用户的好评。本文结合作者的实际经验，以该项目为例，讨论了信息系统项目建设过程中的范围管理，主要从如下几个方面进行了阐述：规划范围管理、收集需求、范围定义、创建 WBS、范围确认、范围控制。

【正文】

该项目建设分三部分：散货装卸管理系统改造部分、无线理货系统部分、其他部分。散货装卸管理系统包括调度管理，商务管理，理货管理，库场港存管理， 统计系统等几个主要模块，负责装卸现场的作业计划，调度，管理，统计分析等工作;无线理货系统部分是这次项目建设的主要工作，实现模式：电子理货系统通过中间层服务，获取作业任务和配工调度信息，并以内存数据库形式存储。现场使用手持终端，完成现场的业务操作，通过多线程运行，利用 5G 网络自动上传到电子理货中间层，同时将理货指令中行驶指示传递到倒运车辆 GPS 终端设备，指示倒运司机前往指定目的地，并且同步其他相关指令到理货其他环节如计量、外理等系统中并执行指令完整性校验;其他部分包括计量系统及各系统之间接口等，根据理货指令，独立执行计量后信息自动传送到中间服务层。由于该项

目的顺利上线涉及到业务考核，因此，在本项目组中范围管理尤为重要，在本项目中，我作为项目经理除了对其余管理领域进行克制恪守的管理外，特别对范围管理从如下几个方面进行了管理

一、规划范围管理

一个好的项目管理规划，是项目能否成功的重要前提。在项目成立初期，我就组织了相关人员对项目管理计划、项目章程进行了研究讨论，通过研究过往的组织过程资产，并多次召集各相关干系人召开会议进行讨论，最终形成了一份详细的范围管理计划。用于指导如何定义、分解以及确认、控制范围。

二、收集需求

一个项目的成功，应该只需完成项目所需的全部工作。为了保证这一点，就必须在项目的初期，就要有一个明确的范围。在完成了范围规划后，我带领我的团队，到客户现场查勘了该项目的每一个工作组织流程，之后我又组织了客户的IT 部门，维护运营部门，质量控制等部门的项目负责人，通过访谈、焦点小组、引导式研讨会等多种方式，多次商讨项目的范围。在收集需求的过程中，客户有时候对需求的描述不清楚，造成了双方对需求理解有歧义，通过不断的接触，我也发现部分干系人对自己的需求其实也不清楚。针对这种情况，我采用原型法将收集到的需求，先做成模型供客户参考，充分挖掘用户的需求，并基于自身的经验及团队专业水平，对客户的需求进行引导。并形成需求分析、需求跟踪矩阵供参考

三、定义范围

基于范围管理计划、项目章程、需求文件，我召集了项目的主要干系人进行引导式研讨会，同时邀请了该信息系统主要的使用维护人员(包括甲方的信息管

理人员、现场一线人员、网管操作人员等)对系统的功能进行了评价，通过用户的角度，去发现问题并解决问题，最终形成了完整的范围说明书，包括 1、项目的范围描述。2、可交付成果。3、验收标准。4、项目的除外责任。5、项目制约因素 6、项目的假设条件。7、项目的目标、预算、资源以及主要里程碑等。

四、创建 WBS

基于项目的范围说明书，我和团队成员开始对项目范围进行了分解，一份优秀的 WBS 能够让范围模糊，不具体的工作变得清晰明了，使得管理有依有据。由于 WBS 分解后，涉及到各项工作的实施，我让我的项目团队各模块的主要负责人和骨干都参与了该项目的分解，分解主要有以下的原则：1、各层次上保持项目的完整性，我将该项目涉及的各模块都一一列出，避免遗漏。2、一个工作单位只从属于某个上层单元。3、相同层次的工作单元应有相同性质。4、工作单元应能分开不同的责任者和不同的工作内容。5、工作包一般不大于 80 小时。对于该项目的每个工作包，都指定唯一的负责人负责相应的工作内容。

同时，我也与我的团队强调，WBS 分解不可能一步到位，根据滚动式规划， 逐步达到项目的需求。因此我们的 WBS 分成四层，第一层是按照子系统划分的， 包括十四个子系统和项目管理;第二层是按定义需求、设计、编码、测试、验收等生命周期来划分的;第三层是对第二层的进一步细化，比如定义需求又分成需求调研、需求分析、需求定义和需求验证等;第四层是对第三层的进一步细分， 比如需求调研又分成客户现场访谈、会议、建立原型等。对于 WBS 中工作单元的细节信息，我们在 WBS 字典中加以描述。WBS 分解是一项很重要的工作， 在这一过程中我们发现《项目范围说明书》中存在较多不明确的方面，通过 WBS 分解而得到明确。WBS 分解工作完成后，项目范围基准就确定了。

五、确认范围

确认范围不是一件容易的事，在与客户的沟通上，我们希望客户尽快确认上一阶段的成果，以便能尽快进入下一阶段的开发。但是客户认为，我需要的是一个完整的信息系统，没有实现最终的效果，怎么去进行确认呢?针对这种情况， 我在提交文档给各干系人后，重点对 IT 部门人员进行了沟通培训，详细介绍了我们这个项目系统的设计，然后再通过 IT 部门的人员分别对其公司内部其它部门的人员进行解释沟通，这样更有助于其它部门的人员便于理解。同时，我也告知了 IT 部门人员，确认范围后，尽量不再对范围基准进行变更，但如果对项目有好的建议或者在项目范围内的变更，可以提交正式的变更流程，经过变更管理委员会批准后，是可以进行变更的。经过努力，得到了客户的认可，之后客户的一些需求，也提交了标准的变更控制流程

六、控制范围

控制范围就是监督范围的状态，管理好变更，做好控制范围管理工作，避免出现范围“蔓延”，做好控制范围能够避免项目不停的出现变更，也能够控制干系人对该系统不停出现新的模块需求。在该系统的实现过程中，我和我的团队， 通过分析工作绩效数据，对照范围基准，找出范围偏差，并及时进行分析并纠偏。例如，在该项目的统计系统模块功能下，IT 部门的总负责人为了不出现大面的修改，向我提出了屏蔽批量修改功能，我也将此需求写入了范围说明书内。但是其它模块的开发人员在检查该模块时，发现批量修改功能出现在了该系统中，我查询了变更日志，未有类似的变更记录。于是我调取了项目的责任分配矩阵，找到负责该模块的负责人张工并询问原因，他告诉我，他增加此项功能的原因是因为该公司的监控部门负责人觉得批量修改有助于提高生产效率向其提出的，张工

也并未经过变更流程就进行了变更。我向张工强调了范围基准以及变更流程的重要性。其次针对多出来的这个功能，我也要求张工提交正式的变更申请，走正常的变更控制流程。我也多次向团队成员强良好的变更能带来项目效率的提升。任凭项目范围蔓延，带来的结果可能是工期的延长，无法在规定时间调，内完成项目的交付。

【结尾语】

经过我们团队的不懈努力，历时 1 年，本项目终于于 2022 年 4 月，通过了业主方组织的验收，实现了港口现场管理信息化的扩展，提高了港口装卸效率， 减少了工作中人为因素造成的不良影响，各部门之间工作协调更加流程，简化了工作程序，获得了业主以及使用者的好评。本项目的成功，得益于我的范围管理。当然，在本项目中，还有一些不足处，比如，在项目的实施过程中，对用户提出的部分变更，未与客户确认即进行了变更，不过，经过我后期的纠偏，并没有多项目产生什么影响。在后续的工作和学习中，我将不断的充电和学习，和同行进行交流，提升自己的业务和管理水平，力争为我国信息化建设做出自己的努力。

以上就是论信息系统项目的范围管理的论文模板，小编附上了该论文模板的电子文档，各位有需要的考生可以下载保存。