江苏移动电子运维管理系统的设计与实现

江苏移动电子运维管理系统的设计与实现内容摘要：

质量。 虽然国内电信企业在运维管理体系的建设上取得了一定的成绩，硕士学位论文 4 但 目前 仍以过渡型体制为主，在运营管 理方面距离国际一流企业还有一段差距。 主要研究内容和意义 江苏移动作为网络管理信息化建设名列前茅的移动公司，结合自身特色，提出了建设电子运行维护三期系统的要求。 本文立足于江苏移动公司运维发展的现状，结合中国移动公司运维体系的发展情况， 采用 Rational 统一过程（ RUP）为软件开发方法，以统一建模语言（ UML）为分析设计描述语言， 开发 完成了 EOMS 系统三期工程。 通过三期系统的建设， EOMS 系统以流程体系作为载体，通过建立系统化、标准化的生产管理流程体系以及相关的 IT 支撑体系，将运维集中化的思想落实到日常生 产管理活动中，全面提升网络运维的“通信保障能力、业务提供能力和低成本运作能力”，实现了中国移动“质量领先、支撑有力、运行高效”的战略目标。 EOMS 系统以 Oracle 作为后台数据库，使用 Java 语言进行开发，采用了基于工作流的方式，整个系统分为系统管理、工单管理、报表管理、作业计划管理和值班管理等八个模块。 本文 在介绍了系统总体架构和功能架构的基础上，重点讲述了作业计划管理模块的详细设计与实现。 作业计划管理在运维管理系统中占有非常重要的地位，包含模板制定、模板审批、模板修改、模板转派、模板分解、模板执行、质检 和月总结等功能，实现了对日常作业计划的制定、执行和监控的硕士学位论文 5 流程化管理，摆脱了低效的纸质办公、人工传递的状况，提高了基础维护人员的工作效率和工作质量，减少了运维成本，并能够实现日常维护工作的可测量性。 本文的研究意义是： 1. 满足 了 集团卓越运维体系的要求； 2. 支撑运维业务流程端到端的运作，实现业务流程化、管理精细化； 3. 实现集团公司、省公司以及地区分公司之间的业务处理连接，支撑三集中业务策略的实现； 4. 对运维工作、部门、人员进行运行监督、绩效考核，实现工作绩效指标精确量化，不断改进运维工作。 论文的组织结构 全文共分为 五 章。 第一章是绪论，首先介绍了系统的研发背景，然后对国内外电信企业运维管理的研究情况进行了阐述，最后说明了系统的主要研究内容和意义。 第二章是 系统 需求分析，主要描述了需求分析的工作模式及工作成果。 需求分析的成果具体分为功能性需求和非功能性需求两部分，本文采用了用例（ User Case）的描述方法来描述功能性需求。 第三、四章是全文的核心内容。 第三 章是系统的架构设计部分，硕士学位论文 6 通过对系统的总体架构、功能架构 、逻辑架构 和部署架构 的设计，确定了系统的整体架构和核心功能。 第四章是系统功能的详细设计 与实现 ， 在 作业计划管理 需 求分析的基础上， 着重介绍了模板定制、模板分解、执行作业计划、质检、月总结和配置等几个系统功能 的详细设计与实现。 第 五 章是总结与展望部分，对本文 的工作 进行了总结，并对下一步的工作进行了展望。 硕士学位论文 7 第 2章 系统 需求分析 需求分析是软件开发过程中非常重要的一项工作，需求分析工作质量的好坏将直接决定系统开发工作的成败。 需求错误是软件开发过程中最容易出现的错误，也是需要最大代价进行修复的错误。 如果系统开发工作建立在一个错误的需求基础上，则无论程序代码的质量多么完美，系统都不会成功。 本章首先对系统进行了简要的描述， 并 提出了系统的 设计目标， 然后 对 系统需求分析过程中的难点进行了剖析 ，并从需求获取模式和需求描述方法两个方面进行了阐述，在此基础上完成了系统的需求分析工作。 系统概述 电子运维 管理 系统是中国移动总部和 31省网络运维部门协同工作的纽带，是运维制度和规程的信息化载体，其以 IT 方式固化了的标准运维流程。 EOMS 系统 一期工程于 2020 年建设，系统主要功能包括故障工单、任务工单、局数据工单管理和值班管理，初步实现了网络运维工作的电子化管理，从而摆脱低效的纸质办公、人工传递的状况。 EOMS 系统 二期工程于 2020 年建设，二期系统对一期 功能进行了加强，并新增代维管理、 KPI 呈现、案例库管理等功能，并通过与各专业网管、客硕士学位论文 8 服、 OA 等系统的互联，实现信息在多部门、多系统间的自动流转，进一步提升了运维工作的效率和质量。 通过二期系统建设， EOMS 系统的完整功能框架初步建立，运维工作初步实现了规范化管理。 为了巩固网络运维集中化成果、进一步推动流程标准化、持续优化，江苏移动提出了建设电子运行维护三期系统的需求 ， 要求 形成统一的工作流管理、统一的信息平台、统一的用户权限管理等，以进一步提高整个网络部各部门内部、部门间的电子化管理、协调、运作效率和能力，进 一步加强对网络部各个专业系统的整合，进一步加强对网络部各项工作的管理、考核、调度能力，提升江苏移动网络部各方面工作的管理水平。 当前，中国移动提出全面实施“做世界一流企业，实现从优秀到卓越的新跨越”战略。 网络工作也继“质量领先、运行高效、支撑有力”之后提出了“提升网络运维的标准化水平，打造卓越运维体系”的新目标。 面临新的机遇与挑战， EOMS 系统建设将在巩固网络运维集中化成果、进一步推动流程标准化、持续优化等方面进一步发挥重要作用。 EOMS 系统 三期建设的主要目标是实现 集团 卓越运维梳理的标准化流程的 IT 落地。 根据这一建设目标， 江苏移动卓越运维平台 （即电子运维管理系统） 建设的 设计目标是 ：完全满足集团卓越运维体系的要求；支撑运维业务流程端到端的运作，实现业务流程化、管理精细硕士学位论文 9 化；实现集团公司、省公司以及地区分公司之间的业务处理连接，支撑三集中业务策略的实现；对运维工作、部门、人员进行运行监督、绩效考核，实现工作绩效指标精确量化，不断改进运维工作。 需求获取模式 IEEE 软件工程标准词汇表 (1997 年 )中定义需求为“ (1)用户解决问题或达到目标所需的条件或权能 (Capability)。 (2)系统或系统部件要满足合同、标 准、规范或其它正式规定文档所需具有的条件或权能。 (3)一种反映上面 (1)或 (2)所描述的条件或权能的文档说明”。 简而言之，需求是对一个产品的需要或要求的描述。 任何一项工作在开始以前，首先应该明确工作的目标和工作成果（制品）是什么。 如果事先没有进行目标和工作成果的定义，则该项工作一定会发散而失去约束。 按照传统的软件工程理论，需求分析的目标就是要确定“干什么。 ”，而不是“怎么干。 ”。 按照 RUP 的理论，需求分析工作的主要目的就是“致力于开发正确的系统。 要做到这一点，就要足够详细地描述系统需求（也就是系统必须达到 的条件或能力），使客户（包括用户）和开发人员在系统应该做什么、不应该做什么方面达成共识。 【 6】 ” 国外电信企业对支撑系统的总体框架及电信运营流程的研究比较超前，从最初的 TNM、 TOM、 ETOM 到 NGOSS，已经形成标准化模型，对支撑系统的接口标准有统一的规范。 硕士学位论文 10 与国外电信企业相比， 国内电信支撑系统起步 则 比较晚，各运营商根据需求自行开发或定制软件，在国内没有一个标准化的模型，没有统一的接口，造成各支撑系统间互通困难，成为一个个信息孤岛。 虽然初期能够满足需求，提高了运维管理的精确化和维护效率，但随着各种系统的 不断增多，信息一致性无法保证，反而造成了混乱和维护效率的降低。 因此，在需求获取的过程中，主要存在以下困难： 1. 缺少足够的用户参与 理解风险承担人（ Stakeholder）和用户（ User）的需要是开发一个正确系统的关键因素，因此 首先需要识别系统的参与者（ Actor）。 参与者是同系统交互的所有事务，例如人、其他的软件、硬件设备、数据存储或者网络 【 7】。 每一个参与者定义一种特定的角色。 中国移动网络运维岗位 的 角色分为流程角色和细分角色。 流程角色是指承担了一定流程活动职责的主体，一个实际的岗位（或人员）可能承担一 个或者多个流程角色的职责。 例如，一个“新业务管理岗”可以承担“话音类新业务接口人”、“数据类新业务接口人”以及“集团客户类新业务接口人”等多个流程角色，一个岗位所对应的角色数量取决于相关角色的工作量和人员的工作能力和经验。 根据角色所属的流程特性，细分角色为不同专业、不同系统、不同机型、不同属地（省公司或市公司）。 在有的流程中，角色是按照业务类型划分的，例如投诉处理流程、新业务开通流程；在有的流程中，角色是按照系统硕士学位论文 11 和机型划分的，例如故障处理流程、作业计划执行流程。 此外，针对同一流程中不同的角色，专业、系统划分 的粗细程度也不一样。 一般情况下，接口人、管理员或负责人的专业、系统划分相对较粗，流程执行者的专业、系统划分相对较细。 在实际需求获取的过程中，由于一个运维岗位可以承担多种角色的职责， 而且所对应的角色数量取决于相关角色的工作量和人员的工作能力和经验，这种角色的划分方法 给需求的获取工作带来一定的困难。 其次，运维人员和软件开发人员处于不同专业领域、具有不同的背景、思维方式上也有较大的差异，也容易形成交流上的障碍。 最后，EOMS 系统的最终用户遍布全省，有着庞大的用户群，因此需求分析人员所获得的需求仅仅是一小部分人的 需求，难以提高需求范围的覆盖程度。 2. 用户需求的不断变化 由于目前业界缺乏成熟的、可以借鉴的 支撑 系统 模型 供用户参考，而且绝大部分用户不具备计算机软件开发能力，因此用户对系统所能提供的功能缺乏想象力，需求容易“模糊”。 直到开发人员把用户描述的东西拿给他们，用户才知道需要什么，“模糊”的需求才会逐渐清晰起来，从而引发更多的需求。 另一方面，国内电信运营商正处于转型期，各种组织结构、流程和 业务的新建与变更也使得用户的需求不断发生变化。 硕士学位论文 12 3. 用户需求的一致性难以保证 在以往的发展中，由于经济发展水平差异较大，各省市移动公司依靠自身的实践经验、管理能 力来思考和探索各自运维体系的发展，致使各移动公司之间的差异较大，在标准化运维流程的过程中容易出现分歧。 这些用户从事于不同的运维岗位，知识层次不同、年龄对象不同，因此当需求出现分歧时一致性难以保证。 通过对本系统需求工作难点的分析，可以看到如何有效的开展需求分析工作，确保系统的需求 可以准确、有效的获得将是一件非常重要的工作。 在需求启发阶段， 要尽可能多的启发用户需求， 因此 选择一种合适的需求启发方法是非常必要的。 常用的需求启发方法有面谈和问卷调查、需求讨论会、自由讨论和主意精简、情节串联 板的制作、应用用例、角色扮演以及原型开发 【 6】。 针对本系统需求分析工作面临的困难，在实际的工作中 主要 采用了原型开发和面谈相结合的方法。 面谈是一种最直接、最简单的需求获取手段，但是存在如何使用户或风险承担人无偏见或无倾向说出自己需要的问题。 通过由开发人员快速构建需求原型，用于让用户评价对需求的理解的方法，可以帮助用户更好的理解需求，不仅有利于双方的交流，让“模糊”的需求变得清晰起来，还有利于发现更多尚未发现的问题。 客户和最终用户都有自己的目标（在统一过程中也称为“需要”）硕士学位论文 13 并希望计算机系统能够帮助他们实现这 些目标。 在多种获得这些目标和系统需求的方法中，较好的方法是简单而又熟悉的方法，因为这样可以使目标和需求的定义和评估更加容易，特别是对客户和最终用户来说更是如此。 这样做会降低未达到这种目标的风险。 在统一过程中，需求按照 FURPS＋模型进行分类。 在一般使用中，需求则按照功能性（行为的）和非功能性（其他所有的）来分类 【 7】。 虽然后者的分类方式非常泛泛，但是这种方式已被广泛采用，因此 本文 也按照这种方式对系统的需求问题进行描述。 功能性需求 用例可以为项目相关人员提供一种简单而易懂的机制来了解目标和系统需求，写出用 例是一种最好的理解和描述需求的技巧。 使用用例来描述功能性需求的思想是由 Ivar Jacobson 在 1986 年提出的， Ivar Jacobson 是 UML 和 RUP 的主要创始人。 这一思想已经被广泛的传播和接受，简单和有效是其最主要的优点。 应该怎样发现用例。 用例应该在什么级别和范围 上表述。 在用例的识别和表述上，本文 采用的指导原则是 EBP 用例，即对计算机应用进行需求分析的时候，应专注于“基本业务过程”（ EBP）级别的用例。 EBP 是一个“业务过程工程学”领域内的术语，它指的是“由一个人在某个时间某个地点执行的一项任务 ，这项任务是对某一业务事件的反应，而且能够增加可以度量的业务价值，并且能够保持数据状态的硕士学位论文 14 一致。 ”应用 EBP 指导原则，可以避免定义许多过低级别上的用例，这些用例只相当于 EBP 中的一个简单步骤、子功能或子任务 【 7】。 为了清晰地描述系统用例的层次结构，可以采用将系统用例分为不同的包，每一个包表示一组相关的系统用例。 用例包是用例、主角、关系、图和其它包的集合，通过将其划分为若干个较小部分来建立用例模型 【 8】。 为了清晰起见，本文 引入了包图来将不同的功能用例进行分类，每个包图作为一个子系统，如图 21 所示。 图 21 系统功能包。