网络是软件层面的，它不同于网络设备、链路的实施，它属于逻辑部件而非物理部件，缺乏“可见性”。在软件的程序代码正式上机试运行之前，网管软件开发过程的进展情况较难衡量，质量难以评估。这个问题在需要对商品化软件进行的过程中尤为突出。

几乎所有的软件应用系统都不同程度地存在软件危机问题，以中石油的网络管理系统为例，在它的运行环境中也曾出现过“网管系统不好用，该报的不报，不该报的乱报”、“网管系统能发挥一些作用，但在应用系统运维监控上还有待提高”等来自最终用户的抱怨。

中国石油信息化建设十一五规划自2004年启动中国石油广域网建设项目以来，已形成了异常庞大而复杂的中国石油广域网基础设施架构，它依托11个区域网络中心、覆盖173家地区公司，以RPR2.5G核心环网和跨地域的双核心路由设备、双链路为特点构建。其网络结构具有范围广、规模大、应用系统需求多、链路带宽需求高、链路质量保证要求高等诸多业务特点。自2004年伴随网络建设同期实施网络管理信息系统以来，中国石油在总部和10个区域中心已经成功构建了层次化架构的网络管理系统，并建立了相关的网络管理制度。作为一个以成熟产品为核心引擎，进行个性化、特色化定制的软件二次客户化开发项目，如何有条不紊地精心设计、满足最终用户的实际运维需求，如何规范化、较为系统地进行网络管理开发工作就成为一个较大的问题摆在了管理层面上。其设计、实施的每一步都相互关联相互制约，对中国石油这么一张令思科、华为等众多著名厂家都头痛的网管系统的建设，可以看做一个典型的将软件工程理论应用于网管软件的案例。

纵观这些年中国石油网管开发的过程，网络由单链路发展到双链路、路由从单核心发展到双核心，加上大批基层单位接入的种种外在因素的影响，给网络管理带来很大挑战。根据经验，在网管系统软件开发时需审视几个问题。

一审—需求是否清晰

如果开发者对用户群体的需求没有完整准确的认识，或者对同样问题的理解存在差异，而实际操作中也未能及时沟通规避这种差异带来的潜在风险，将导致网管系统急于求成。设计者在对用户需求未能完全正确认识的情况下就着手编写相关代码，在最终功能实现上就容易与期望值有所偏差。再加上网络基础环境在建设期变化较为频繁等诸多因素，需求分析更显得尤其重要。

需求分析阶段研究的对象是软件项目的用户要求。一方面，必须全面理解用户的各项要求，但又不能漫无目的地全盘接受所有的要求;另一方面，要准确地表达用户要求。只有经过确切描述的软件需求才能成为软件设计的基础。由于存在对邮件系统、视频会议、门户系统等各项专业系统的管理，许多情况下参与调研的技术人员与用户本身在专业知识上存在较大差异，这种对专业知识的不均衡性，导致对目标呈现的预期也有较大的差异。所以在需求文档上必须有一个广泛认同的预期实现目标描述。

过多的需求变更是一个报警信号，意味着问题并未真正弄清楚，项目范围并未很好地确定下来或是政策变化较大，所以二次开发项目一定要把控好项目的范围变化。

二审—开发实施文档是否完备

开发各阶段的配套文档不齐全，将导致系统先实施后补文档，缺乏完善的计划性。由于开发者考虑问题过于简单，缺乏技术环节的充分讨论，与用户之间对同一问题的认知有偏差，导致最终实施结果与用户已经变化了的需求无法吻合，这个时候更应该在技术实现环节加强文档规范化的约束。

三审—测试环节的地位

由于软硬件、人员等诸多因素的欠缺，技术人员忽视了开发过程中的测试环节，往往是在匆匆忙忙简单测试之后就将结果提交给了用户，导致系统漏洞百出又总是修修补补，这样大量的精力和时间没有利用在真正的开发环节上，反而消耗在了重复性的工作环节当中。

用户需求和功能需求是系统测试的重要参考。如果未说明产品在多种多样条件下的期望值，系统测试者将很难明确正确的测试内容。反过来说，系统测试是一种方法，可以验证开发计划中所列的功能是否按预期要求实现了;同时，也验证了用户任务是否能正确地执行。

四审—有无版本控制管理

没有引入版本控制管理概念，会导致用户提什么需求维护人员就盲目地“打补丁”满足，缺乏对阶段性关键点的把控，对问题的处理未能实现按紧迫程度、实施难度、技术手段障碍等因素排序。没有版本控制管理就无法将开发工作按合理的时间段划分，什么阶段应该干什么、下一阶段的版本应该展现什么都得不到明确清晰的定位。

五审—分工是否完备

由于网管整体项目不但涉及网络链路、路由交换设备的状态、性能、流量、丢包率等参数指标的监控，而且还涉及应用系统的服务器性能指标、专业应用的服务可用性、关键进程的监控等众多参数的提取和阀值监控。这些工作需要项目组成员进行不同分工、协同工作、相互配合，尤其需要各应用系统的协调。而在这方面由于经验的欠缺和方法学、管理工具的匮乏，致使管理不善，工作人员忙没有忙到点子上。

六审—软件二次开发不是简单修补

软件的二次开发有别于单纯软件的新建开发，它必须在对原有系统深入了解的基础上，充分考虑具体实现的功能在实际中能对原有系统提升多少、功能完善健全多少;而且要考虑到各子系统之间的集成，使最终的产品展现能有一个质的变化。

七审—开发接口是否统一

项目之间、项目组各功能小组之间是通过一定的接口与软件开发队伍联系的，这些接口对项目需求活动起着重要作用。为保证能顺利进行这些接口操作，设计人员要与其他领域的合作者多交流，让他们知道应改进想法和调整计划。

综上所述，为保证网络正常安全运行及信息在各层次架构之间的实时传输，仅靠单纯的人工管理，被动式的检查维护已无法满足整个系统良好运转的需要。对于大规模的网络环境和复杂的专业应用系统，必须对其进行有效的监控管理，及时处理网络中众多设备发出的事件报告，当网络中出现故障时系统能在最短时间内侦测到源故障点，及时有效地告知运维人员，减少问题的发生和排障响应时间，提高系统的可用性，而其基础就是将软件工程理论应用于网管软件的开发。（郭以东刘晓

网络管理信息系统是软件层面的，它不同于网络设备、链路的实施，它属于逻辑部件而非物理部件，缺乏“可见性”。在软件的程序代码正式上机试运行之前，网管软件开发过程的进展情况较难衡量，质量难以评估。这个问题在需要对商品化软件进行二次开发的过程中尤为突出。

几乎所有的软件应用系统都不同程度地存在软件危机问题，以中石油的网络管理系统为例，在它的运行环境中也曾出现过“网管系统不好用，该报的不报，不该报的乱报”、“网管系统能发挥一些作用，但在应用系统运维监控上还有待提高”等来自最终用户的抱怨。

中国石油信息化建设十一五规划自2004年启动中国石油广域网建设项目以来，已形成了异常庞大而复杂的中国石油广域网基础设施架构，它依托11个区域网络中心、覆盖173家地区公司，以RPR2.5G核心环网和跨地域的双核心路由设备、双链路为特点构建。其网络结构具有范围广、规模大、应用系统需求多、链路带宽需求高、链路质量保证要求高等诸多业务特点。自2004年伴随网络建设同期实施网络管理信息系统以来，中国石油在总部和10个区域中心已经成功构建了层次化架构的网络管理系统，并建立了相关的网络管理制度。作为一个以成熟产品为核心引擎，进行个性化、特色化定制的软件二次客户化开发项目，如何有条不紊地精心设计、满足最终用户的实际运维需求，如何规范化、较为系统地进行网络管理开发工作就成为一个较大的问题摆在了管理层面上。其设计、实施的每一步都相互关联相互制约，对中国石油这么一张令思科、华为等众多著名厂家都头痛的网管系统的建设，可以看做一个典型的将软件工程理论应用于网管软件的案例。

纵观这些年中国石油网管开发的过程，网络由单链路发展到双链路、路由从单核心发展到双核心，加上大批基层单位接入的种种外在因素的影响，给网络管理带来很大挑战。根据经验，在网管系统软件开发时需审视几个问题。

一审—需求是否清晰

如果开发者对用户群体的需求没有完整准确的认识，或者对同样问题的理解存在差异，而实际操作中也未能及时沟通规避这种差异带来的潜在风险，将导致网管系统急于求成。设计者在对用户需求未能完全正确认识的情况下就着手编写相关代码，在最终功能实现上就容易与期望值有所偏差。再加上网络基础环境在建设期变化较为频繁等诸多因素，需求分析更显得尤其重要。

需求分析阶段研究的对象是软件项目的用户要求。一方面，必须全面理解用户的各项要求，但又不能漫无目的地全盘接受所有的要求;另一方面，要准确地表达用户要求。只有经过确切描述的软件需求才能成为软件设计的基础。由于存在对邮件系统、视频会议、门户系统等各项专业系统的管理，许多情况下参与调研的技术人员与用户本身在专业知识上存在较大差异，这种对专业知识的不均衡性，导致对目标呈现的预期也有较大的差异。所以在需求文档上必须有一个广泛认同的预期实现目标描述。

过多的需求变更是一个报警信号，意味着问题并未真正弄清楚，项目范围并未很好地确定下来或是政策变化较大，所以二次开发项目一定要把控好项目的范围变化。

二审—开发实施文档是否完备

开发各阶段的配套文档不齐全，将导致系统先实施后补文档，缺乏完善的计划性。由于开发者考虑问题过于简单，缺乏技术环节的充分讨论，与用户之间对同一问题的认知有偏差，导致最终实施结果与用户已经变化了的需求无法吻合，这个时候更应该在技术实现环节加强文档规范化的约束。

三审—测试环节的地位

由于软硬件、人员等诸多因素的欠缺，技术人员忽视了开发过程中的测试环节，往往是在匆匆忙忙简单测试之后就将结果提交给了用户，导致系统漏洞百出又总是修修补补，这样大量的精力和时间没有利用在真正的开发环节上，反而消耗在了重复性的工作环节当中。

用户需求和功能需求是系统测试的重要参考。如果未说明产品在多种多样条件下的期望值，系统测试者将很难明确正确的测试内容。反过来说，系统测试是一种方法，可以验证开发计划中所列的功能是否按预期要求实现了;同时，也验证了用户任务是否能正确地执行。

四审—有无版本控制管理

没有引入版本控制管理概念，会导致用户提什么需求维护人员就盲目地“打补丁”满足，缺乏对阶段性关键点的把控，对问题的处理未能实现按紧迫程度、实施难度、技术手段障碍等因素排序。没有版本控制管理就无法将开发工作按合理的时间段划分，什么阶段应该干什么、下一阶段的版本应该展现什么都得不到明确清晰的定位。

五审—分工是否完备

由于网管整体项目不但涉及网络链路、路由交换设备的状态、性能、流量、丢包率等参数指标的监控，而且还涉及应用系统的服务器性能指标、专业应用的服务可用性、关键进程的监控等众多参数的提取和阀值监控。这些工作需要项目组成员进行不同分工、协同工作、相互配合，尤其需要各应用系统的协调。而在这方面由于经验的欠缺和方法学、管理工具的匮乏，致使管理不善，工作人员忙没有忙到点子上。

六审—软件二次开发不是简单修补

软件的二次开发有别于单纯软件的新建开发，它必须在对原有系统深入了解的基础上，充分考虑具体实现的功能在实际中能对原有系统提升多少、功能完善健全多少;而且要考虑到各子系统之间的集成，使最终的产品展现能有一个质的变化。

七审—开发接口是否统一

项目之间、项目组各功能小组之间是通过一定的接口与软件开发队伍联系的，这些接口对项目需求活动起着重要作用。为保证能顺利进行这些接口操作，设计人员要与其他领域的合作者多交流，让他们知道应改进想法和调整计划。

综上所述，为保证网络正常安全运行及信息在各层次架构之间的实时传输，仅靠单纯的人工管理，被动式的检查维护已无法满足整个系统良好运转的需要。对于大规模的网络环境和复杂的专业应用系统，必须对其进行有效的监控管理，及时处理网络中众多设备发出的事件报告，当网络中出现故障时系统能在最短时间内侦测到源故障点，及时有效地告知运维人员，减少问题的发生和排障响应时间，提高系统的可用性，而其基础就是将软件工程理论应用于网管软件的开发。（ccw-2008年01月14日第02期C8）