论城域网综合运维管理平台范围管理

备战明天高项论文，预测会考范围管理，押题！！！献上。

摘要
2011年3月，我作为项目经理，参与了《城域网综合网络运维管理平台》的项目开发。该项目是某市电信相关部门委托我们公司进行开发的，为全市5个区8个县的所有城域网各个环节的网络运维人员提供统一管理平台，系统负责监控城域网中20000多台网络设备；系统主要功能有：全网拓扑管理、设备集中配置审计、告警集中展现、实时监控设备运行状况、运维工单管理等。在项目执行过程中，我通过培训、现场调研、加强干系人识别、采用原型法等方法完成了需求收集和范围定义工作；通过细化需求说明书、利用类比经验法、细化WBS词典等方式确保WBS的顺利制定；通过持续交付、阶段性评审、正式书面记录等手段完成了范围核实；通过建立CCB及变更控制流程、制定项目范围管理计划中变更相关规定的方法完成了项目范围控制。通过采用以上范围管理办法，最终项目按期保质完成，系统运行至今稳定，为用户的运维管理工作带来了极大的便利，得到客户的一致好评。
正文
一、 项目概述
因城域网设备种类繁多，网络拓扑复杂，导致故障定位困难，无法迅速排查并解决故障。为解决该问题，提升网络整体服务水平，某省会城市电信公司于2011年3月启动“城域网综合运维管理平台”项目开发工作。通过该系统的搭建，使运维管理工作标准化、流程化、可视化。
该项目的一个最大特点是效率，要能够快速高效的发现网络中存在的问题，并快速定位到告警源头，将故障事件以最快速度告知相应的维护人员，并提供解决故障的决策方法。系统干系人涉及到全网维护人员，各个层级维护人员所关心的内容都不尽相同，且管理水平层次差别大。因此我们使用了C/S,B/S,手机APP相互混合的架构方式来为客户提供服务。其中C/S架构用于提供集中监视，快速轮询网络设备的各种实时状态。B/S用户事后查看各种报表类数据和工单派送。手机APP用于具体实施人员接受工单，和工单提交，并接收局端发送的解决方案。
因为城域网设备分散各地，我们采用分布式的架构方式来架设通信框架，在项目中我们采用SNMP简单网络管理协议来获取网络设备的各种性能值，使用syslog和snmptrap协议来接受设备发送过来的各种日志信息，对日志进行智能解析判断设备运行状况。使用telnet和ssh协议的数据包分析和转发来实现维护操作集中配置审计。系统主要包括如下重点功能：全网拓扑管理、设备集中配置审计、告警集中展现、实时监控设备运行状况、运维工单管理等。
由于具备比较扎实的技术基础，和丰富的项目管理经验，我有幸担任项目经理参与了该项目的开发管理工作。以下我主要从项目范围管理的角度进行论述。
二、项目范围管理过程及主要工作介绍
项目范围管理是项目成败的关键，是项目管理中至关重要的领域，项目范围包括项目的最终产品或服务以及实现该产品或服务所需要的各种具体工作。项目范围管理包括：范围计划编制、需求分析和范围定义、工作分解WBS、范围确认、范围控制等方面工作。在接到项目后，我制定了各领域的管理计划，其中通过项目章程和项目初步范围说明书制定了项目范围管理计划，以指到各项范围管理工作。以下重点介绍具体实施项目范围管理的一些阶段和所采取的措施。
1.范围定义
软件范围直接和需求相关，如果需求分析不到位，将会导致需求“蔓延”，而需求蔓延是软件开发项目失败的一个主要原因。因此明确需求做好项目范围定义是一个至关重要的因素。
我在接手本项目后，认证分析总结了需求分析的几个特点如下：
（1）课题复杂
 本项目涉及到的维护人员水平差异比较大，需要考虑到各个层级的维护人员的使用需求。网络设备的种类繁多包括各种厂家的路由器、交换机、防火墙、入侵检测系统、EPON设备。他们的管理参数和管理方式都不相同。网络设备分散，设备分散在各个街道、大楼、交接配电箱等等。
（2）专业障碍、技术难度大
 在该项目中我们不仅需要了解网络运维的相关标准，还需要了解网络交互的各种协议。本项目涉及到各种协议的分析和开发，其中telnet和ssh协议是运维人员在维护过程中使用的最多的管理协议，通过telnet或ssh登录到设备上进行命令配置。在项目的一个目标需求中，我们需要集中地管理用户的配置行为，对用户的行为进行操作审计，因此我们需要对telnet和ssh协议的数据包进行分析转发。需要充分理解协议的交互过程，并模拟协议数据包进行数据转发，并充分考虑系统的安全性问题。
 针对以上两大点，我在收集需求和范围定义过程中采取一下几方面措施
（1） 为了减少项目沟通障碍，提高需求分析的效率，首先我组织了运维和网络技术等方面的专家对项目成员进行集训，并让团队成员参与到具体的网络运维管理工作中。从而使项目成员能在短时间内了解运维管理的流程和相关术语和业务特点，是项目成语在需求分析中能与客户在同一个维度上进行沟通和问题讨论。
（2） 为减少需求遗漏的可能性，我加强对干系人的识别工作，并召集各方代表、以及其他重要干系人进行了多次渐进细化的需求分析讨论。不断明晰用户模糊的需求。挖掘和引导用户潜在的需求。从而使项目范围边界不断明确。
（3） 我安排需求工程师使用rational rose画用例图，将分析的需求形成需求说明书和需求跟踪矩阵。在功能和非功能性需求跟用户进行周期性的确认以保证项目团队和用户在需求上的理解一致。最后将已定义的需求整理为项目范围说明书，形成阶段重要可交付物。
（4） 由于用户在ui、性能、稳定性方面没有明细要求，这部分需求往往无法在初期确定，因此我采用原型法，以降低范围定义不完全的风险、介绍相应损失。
2.工作分解WBS
 WBS是进度规划、成本规划等项目管理阶段的输入，wbs的精确度和粒度决定了项目进度和成本规划的准确率。因此，创建wbs是项目管理的一个非常重要的环节。
1）将需求文件做细，形成wbs的一个基本雏形
 WBS依赖于成功的需求分析和范围定义，在项目中的实际操作，我将需求文件做细，将系统划分成30个功能点，每个功能点还有字功能，形成wbs的一个雏形，方便wbs的建立。
2）使用类比经验法进行wbs分解
 由于之前有参与过其他地市运营商运维管理系统的开发管理工作，对该领域的工作有较深入的了解，我们将WBS分解成三级编码结构，最低层的工作包平均16个小时（两工作日）。
3）细化WBS词典
 WBS词典的详细程度直接影响后续工作的开展是否顺利，因此在本项目中，我特别注重wbs词典的详细程度，亲自审核并定稿后专门开会发布。
3.范围确认
 范围确认是项目干系人正式接受已完成的项目范围的过程，范围确认需要审查可交付物的工作成功，以保证项目中所有工作都能正确满意地完成。
 在本项目中，由于采用了原型发、不断迭代、持续交付阶段成果的开发方法，因此范围确认贯穿整个项目始终。在WBS制定后，我确定了多个重要的里程碑，每个里程碑是一个重要的时间节点，我邀请相关干系人参加阶段评审会。评审过程中的偏差和问题都会被记录并马上进行规划解决。评审过程中的意见都会形成评审意见表并请代表签字形成书面记录。
4.范围控制
 范围可以说是最容易产生变更的基线，范围变更一般源于前期需求未被正确识别或后中后期用户新增需求。
在本项目中我采取一下两个措施减少变更频度降低相应不利影响：
1） 建立变更控制委员会与变更控制流程。保证项目内的变更都在CCB的控制和变更控制流程的约束下。
2） 在范围管理计划中对范围变更控制进行规定。在尽量满足用户需求的前提下，缩小变更的幅度，最大限度降低变更的不利影响。避免理解不一致带来的重复变更。
[结束语]
 在项目过程中通过合理的范围管理，本项目于2012年3月顺利上线开始试运行。经历了3个月的试运行，修复实际运行过程中的bug并对系统进行完善，终于在2012年6月顺利完成了项目验收。本项目在范围管理方面总体比较顺利，但是也存在一些问题：在集中配置审计模块的SSH协议分析方面的时间估算方面存在一些偏差，导致资源分配不足，进度有所落后，后面通过赶工和追加资源的方式顺利解决了问题。在项目干系人管理中，由于没有识别出资产管理员也是干系人之一，导致在前期需求分析的时候出现遗漏现象，直到第一次阶段评审才被专家发现并及时弥补。这些问题在以后的项目中会加以改进。