【文章內(nèi)容簡介】 質(zhì)量。 雖然國內(nèi)電信企業(yè)在運(yùn)維管理體系的建設(shè)上取得了一定的成績，碩士學(xué)位論文 4 但 目前 仍以過渡型體制為主，在運(yùn)營管 理方面距離國際一流企業(yè)還有一段差距。 主要研究內(nèi)容和意義 江蘇移動(dòng)作為網(wǎng)絡(luò)管理信息化建設(shè)名列前茅的移動(dòng)公司，結(jié)合自身特色，提出了建設(shè)電子運(yùn)行維護(hù)三期系統(tǒng)的要求。 本文立足于江蘇移動(dòng)公司運(yùn)維發(fā)展的現(xiàn)狀，結(jié)合中國移動(dòng)公司運(yùn)維體系的發(fā)展情況， 采用 Rational 統(tǒng)一過程（ RUP）為軟件開發(fā)方法，以統(tǒng)一建模語言（ UML）為分析設(shè)計(jì)描述語言， 開發(fā) 完成了 EOMS 系統(tǒng)三期工程。 通過三期系統(tǒng)的建設(shè)， EOMS 系統(tǒng)以流程體系作為載體，通過建立系統(tǒng)化、標(biāo)準(zhǔn)化的生產(chǎn)管理流程體系以及相關(guān)的 IT 支撐體系，將運(yùn)維集中化的思想落實(shí)到日常生 產(chǎn)管理活動(dòng)中，全面提升網(wǎng)絡(luò)運(yùn)維的“通信保障能力、業(yè)務(wù)提供能力和低成本運(yùn)作能力”，實(shí)現(xiàn)了中國移動(dòng)“質(zhì)量領(lǐng)先、支撐有力、運(yùn)行高效”的戰(zhàn)略目標(biāo)。 EOMS 系統(tǒng)以 Oracle 作為后臺(tái)數(shù)據(jù)庫，使用 Java 語言進(jìn)行開發(fā)，采用了基于工作流的方式，整個(gè)系統(tǒng)分為系統(tǒng)管理、工單管理、報(bào)表管理、作業(yè)計(jì)劃管理和值班管理等八個(gè)模塊。 本文 在介紹了系統(tǒng)總體架構(gòu)和功能架構(gòu)的基礎(chǔ)上，重點(diǎn)講述了作業(yè)計(jì)劃管理模塊的詳細(xì)設(shè)計(jì)與實(shí)現(xiàn)。作業(yè)計(jì)劃管理在運(yùn)維管理系統(tǒng)中占有非常重要的地位，包含模板制定、模板審批、模板修改、模板轉(zhuǎn)派、模板分解、模板執(zhí)行、質(zhì)檢 和月總結(jié)等功能，實(shí)現(xiàn)了對(duì)日常作業(yè)計(jì)劃的制定、執(zhí)行和監(jiān)控的碩士學(xué)位論文 5 流程化管理，擺脫了低效的紙質(zhì)辦公、人工傳遞的狀況，提高了基礎(chǔ)維護(hù)人員的工作效率和工作質(zhì)量，減少了運(yùn)維成本，并能夠?qū)崿F(xiàn)日常維護(hù)工作的可測(cè)量性。 本文的研究意義是： 1. 滿足 了 集團(tuán)卓越運(yùn)維體系的要求； 2. 支撐運(yùn)維業(yè)務(wù)流程端到端的運(yùn)作，實(shí)現(xiàn)業(yè)務(wù)流程化、管理精細(xì)化； 3. 實(shí)現(xiàn)集團(tuán)公司、省公司以及地區(qū)分公司之間的業(yè)務(wù)處理連接，支撐三集中業(yè)務(wù)策略的實(shí)現(xiàn)； 4. 對(duì)運(yùn)維工作、部門、人員進(jìn)行運(yùn)行監(jiān)督、績效考核，實(shí)現(xiàn)工作績效指標(biāo)精確量化，不斷改進(jìn)運(yùn)維工作。 論文的組織結(jié)構(gòu) 全文共分為 五 章。 第一章是緒論，首先介紹了系統(tǒng)的研發(fā)背景，然后對(duì)國內(nèi)外電信企業(yè)運(yùn)維管理的研究情況進(jìn)行了闡述，最后說明了系統(tǒng)的主要研究內(nèi)容和意義。 第二章是 系統(tǒng) 需求分析，主要描述了需求分析的工作模式及工作成果。需求分析的成果具體分為功能性需求和非功能性需求兩部分，本文采用了用例（ User Case）的描述方法來描述功能性需求。 第三、四章是全文的核心內(nèi)容。第三 章是系統(tǒng)的架構(gòu)設(shè)計(jì)部分，碩士學(xué)位論文 6 通過對(duì)系統(tǒng)的總體架構(gòu)、功能架構(gòu) 、邏輯架構(gòu) 和部署架構(gòu) 的設(shè)計(jì)，確定了系統(tǒng)的整體架構(gòu)和核心功能。第四章是系統(tǒng)功能的詳細(xì)設(shè)計(jì) 與實(shí)現(xiàn) ， 在 作業(yè)計(jì)劃管理 需 求分析的基礎(chǔ)上， 著重介紹了模板定制、模板分解、執(zhí)行作業(yè)計(jì)劃、質(zhì)檢、月總結(jié)和配置等幾個(gè)系統(tǒng)功能 的詳細(xì)設(shè)計(jì)與實(shí)現(xiàn) 。 第 五 章是總結(jié)與展望部分，對(duì)本文 的工作 進(jìn)行了總結(jié)，并對(duì)下一步的工作進(jìn)行了展望。 碩士學(xué)位論文 7 第 2章 系統(tǒng) 需求分析 需求分析是軟件開發(fā)過程中非常重要的一項(xiàng)工作，需求分析工作質(zhì)量的好壞將直接決定系統(tǒng)開發(fā)工作的成敗。需求錯(cuò)誤是軟件開發(fā)過程中最容易出現(xiàn)的錯(cuò)誤，也是需要最大代價(jià)進(jìn)行修復(fù)的錯(cuò)誤。如果系統(tǒng)開發(fā)工作建立在一個(gè)錯(cuò)誤的需求基礎(chǔ)上，則無論程序代碼的質(zhì)量多么完美，系統(tǒng)都不會(huì)成功。本章首先對(duì)系統(tǒng)進(jìn)行了簡要的描述， 并 提出了系統(tǒng)的 設(shè)計(jì)目標(biāo)， 然后 對(duì) 系統(tǒng)需求分析過程中的難點(diǎn)進(jìn)行了剖析 ，并從需求獲取模式和需求描述方法兩個(gè)方面進(jìn)行了闡述，在此基礎(chǔ)上完成了系統(tǒng)的需求分析工作。 系統(tǒng)概述 電子運(yùn)維 管理 系統(tǒng)是中國移動(dòng)總部和 31省網(wǎng)絡(luò)運(yùn)維部門協(xié)同工作的紐帶，是運(yùn)維制度和規(guī)程的信息化載體，其以 IT 方式固化了的標(biāo)準(zhǔn)運(yùn)維流程。 EOMS 系統(tǒng) 一期工程于 2020 年建設(shè)，系統(tǒng)主要功能包括故障工單、任務(wù)工單、局?jǐn)?shù)據(jù)工單管理和值班管理，初步實(shí)現(xiàn)了網(wǎng)絡(luò)運(yùn)維工作的電子化管理，從而擺脫低效的紙質(zhì)辦公、人工傳遞的狀況。 EOMS 系統(tǒng) 二期工程于 2020 年建設(shè)，二期系統(tǒng)對(duì)一期 功能進(jìn)行了加強(qiáng)，并新增代維管理、 KPI 呈現(xiàn)、案例庫管理等功能，并通過與各專業(yè)網(wǎng)管、客碩士學(xué)位論文 8 服、 OA 等系統(tǒng)的互聯(lián)，實(shí)現(xiàn)信息在多部門、多系統(tǒng)間的自動(dòng)流轉(zhuǎn)，進(jìn)一步提升了運(yùn)維工作的效率和質(zhì)量。通過二期系統(tǒng)建設(shè)， EOMS 系統(tǒng)的完整功能框架初步建立，運(yùn)維工作初步實(shí)現(xiàn)了規(guī)范化管理。 為了鞏固網(wǎng)絡(luò)運(yùn)維集中化成果、進(jìn)一步推動(dòng)流程標(biāo)準(zhǔn)化、持續(xù)優(yōu)化，江蘇移動(dòng)提出了建設(shè)電子運(yùn)行維護(hù)三期系統(tǒng)的需求 ， 要求 形成統(tǒng)一的工作流管理、統(tǒng)一的信息平臺(tái)、統(tǒng)一的用戶權(quán)限管理等，以進(jìn)一步提高整個(gè)網(wǎng)絡(luò)部各部門內(nèi)部、部門間的電子化管理、協(xié)調(diào)、運(yùn)作效率和能力，進(jìn) 一步加強(qiáng)對(duì)網(wǎng)絡(luò)部各個(gè)專業(yè)系統(tǒng)的整合，進(jìn)一步加強(qiáng)對(duì)網(wǎng)絡(luò)部各項(xiàng)工作的管理、考核、調(diào)度能力，提升江蘇移動(dòng)網(wǎng)絡(luò)部各方面工作的管理水平。 當(dāng)前，中國移動(dòng)提出全面實(shí)施“做世界一流企業(yè)，實(shí)現(xiàn)從優(yōu)秀到卓越的新跨越”戰(zhàn)略。網(wǎng)絡(luò)工作也繼“質(zhì)量領(lǐng)先、運(yùn)行高效、支撐有力”之后提出了“提升網(wǎng)絡(luò)運(yùn)維的標(biāo)準(zhǔn)化水平，打造卓越運(yùn)維體系”的新目標(biāo)。面臨新的機(jī)遇與挑戰(zhàn)， EOMS 系統(tǒng)建設(shè)將在鞏固網(wǎng)絡(luò)運(yùn)維集中化成果、進(jìn)一步推動(dòng)流程標(biāo)準(zhǔn)化、持續(xù)優(yōu)化等方面進(jìn)一步發(fā)揮重要作用。 EOMS 系統(tǒng) 三期建設(shè)的主要目標(biāo)是實(shí)現(xiàn) 集團(tuán) 卓越運(yùn)維梳理的標(biāo)準(zhǔn)化流程的 IT 落地。 根據(jù)這一建設(shè)目標(biāo)， 江蘇移動(dòng)卓越運(yùn)維平臺(tái) （即電子運(yùn)維管理系統(tǒng)） 建設(shè)的 設(shè)計(jì)目標(biāo)是 ：完全滿足集團(tuán)卓越運(yùn)維體系的要求；支撐運(yùn)維業(yè)務(wù)流程端到端的運(yùn)作，實(shí)現(xiàn)業(yè)務(wù)流程化、管理精細(xì)碩士學(xué)位論文 9 化；實(shí)現(xiàn)集團(tuán)公司、省公司以及地區(qū)分公司之間的業(yè)務(wù)處理連接，支撐三集中業(yè)務(wù)策略的實(shí)現(xiàn)；對(duì)運(yùn)維工作、部門、人員進(jìn)行運(yùn)行監(jiān)督、績效考核，實(shí)現(xiàn)工作績效指標(biāo)精確量化，不斷改進(jìn)運(yùn)維工作。 需求獲取模式 IEEE 軟件工程標(biāo)準(zhǔn)詞匯表 (1997 年 )中定義需求為“ (1)用戶解決問題或達(dá)到目標(biāo)所需的條件或權(quán)能 (Capability)。 (2)系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo) 準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權(quán)能。 (3)一種反映上面 (1)或 (2)所描述的條件或權(quán)能的文檔說明”。簡而言之，需求是對(duì)一個(gè)產(chǎn)品的需要或要求的描述。 任何一項(xiàng)工作在開始以前，首先應(yīng)該明確工作的目標(biāo)和工作成果（制品）是什么？如果事先沒有進(jìn)行目標(biāo)和工作成果的定義，則該項(xiàng)工作一定會(huì)發(fā)散而失去約束。按照傳統(tǒng)的軟件工程理論，需求分析的目標(biāo)就是要確定“干什么？”，而不是“怎么干？”。按照 RUP 的理論，需求分析工作的主要目的就是“致力于開發(fā)正確的系統(tǒng)。要做到這一點(diǎn)，就要足夠詳細(xì)地描述系統(tǒng)需求（也就是系統(tǒng)必須達(dá)到 的條件或能力），使客戶（包括用戶）和開發(fā)人員在系統(tǒng)應(yīng)該做什么、不應(yīng)該做什么方面達(dá)成共識(shí)。 【 6】 ” 國外電信企業(yè)對(duì)支撐系統(tǒng)的總體框架及電信運(yùn)營流程的研究比較超前，從最初的 TNM、 TOM、 ETOM 到 NGOSS，已經(jīng)形成標(biāo)準(zhǔn)化模型，對(duì)支撐系統(tǒng)的接口標(biāo)準(zhǔn)有統(tǒng)一的規(guī)范。 碩士學(xué)位論文 10 與國外電信企業(yè)相比， 國內(nèi)電信支撐系統(tǒng)起步 則 比較晚，各運(yùn)營商根據(jù)需求自行開發(fā)或定制軟件，在國內(nèi)沒有一個(gè)標(biāo)準(zhǔn)化的模型，沒有統(tǒng)一的接口，造成各支撐系統(tǒng)間互通困難，成為一個(gè)個(gè)信息孤島。雖然初期能夠滿足需求，提高了運(yùn)維管理的精確化和維護(hù)效率，但隨著各種系統(tǒng)的 不斷增多，信息一致性無法保證，反而造成了混亂和維護(hù)效率的降低。 因此，在需求獲取的過程中，主要存在以下困難： 1. 缺少足夠的用戶參與 理解風(fēng)險(xiǎn)承擔(dān)人（ Stakeholder）和用戶（ User）的需要是開發(fā)一個(gè)正確系統(tǒng)的關(guān)鍵因素，因此 首先需要識(shí)別系統(tǒng)的參與者（ Actor）。參與者是同系統(tǒng)交互的所有事務(wù)，例如人、其他的軟件、硬件設(shè)備、數(shù)據(jù)存儲(chǔ)或者網(wǎng)絡(luò) 【 7】 。每一個(gè)參與者定義一種特定的角色。 中國移動(dòng)網(wǎng)絡(luò)運(yùn)維崗位 的 角色分為流程角色和細(xì)分角色。流程角色是指承擔(dān)了一定流程活動(dòng)職責(zé)的主體，一個(gè)實(shí)際的崗位（或人員）可能承擔(dān)一 個(gè)或者多個(gè)流程角色的職責(zé)。例如，一個(gè)“新業(yè)務(wù)管理崗”可以承擔(dān)“話音類新業(yè)務(wù)接口人”、“數(shù)據(jù)類新業(yè)務(wù)接口人”以及“集團(tuán)客戶類新業(yè)務(wù)接口人”等多個(gè)流程角色，一個(gè)崗位所對(duì)應(yīng)的角色數(shù)量取決于相關(guān)角色的工作量和人員的工作能力和經(jīng)驗(yàn) 。 根據(jù)角色所屬的流程特性，細(xì)分角色為不同專業(yè)、不同系統(tǒng)、不同機(jī)型、不同屬地（省公司或市公司）。在有的流程中，角色是按照業(yè)務(wù)類型劃分的，例如投訴處理流程、新業(yè)務(wù)開通流程；在有的流程中，角色是按照系統(tǒng)碩士學(xué)位論文 11 和機(jī)型劃分的，例如故障處理流程、作業(yè)計(jì)劃執(zhí)行流程。此外，針對(duì)同一流程中不同的角色，專業(yè)、系統(tǒng)劃分 的粗細(xì)程度也不一樣。一般情況下，接口人、管理員或負(fù)責(zé)人的專業(yè)、系統(tǒng)劃分相對(duì)較粗，流程執(zhí)行者的專業(yè)、系統(tǒng)劃分相對(duì)較細(xì)。 在實(shí)際需求獲取的過程中，由于一個(gè)運(yùn)維崗位可以承擔(dān)多種角色的職責(zé)， 而且所對(duì)應(yīng)的角色數(shù)量取決于相關(guān)角色的工作量和人員的工作能力和經(jīng)驗(yàn)，這種角色的劃分方法 給需求的獲取工作帶來一定的困難。其次，運(yùn)維人員和軟件開發(fā)人員處于不同專業(yè)領(lǐng)域、具有不同的背景、思維方式上也有較大的差異，也容易形成交流上的障礙。最后，EOMS 系統(tǒng)的最終用戶遍布全省，有著龐大的用戶群，因此需求分析人員所獲得的需求僅僅是一小部分人的 需求，難以提高需求范圍的覆蓋程度。 2. 用戶需求的不斷變化 由于目前業(yè)界缺乏成熟的、可以借鑒的 支撐 系統(tǒng) 模型 供用戶參考，而且絕大部分用戶不具備計(jì)算機(jī)軟件開發(fā)能力，因此用戶對(duì)系統(tǒng)所能提供的功能缺乏想象力，需求容易“模糊”。直到開發(fā)人員把用戶描述的東西拿給他們，用戶才知道需要什么，“模糊”的需求才會(huì)逐漸清晰起來，從而引發(fā)更多的需求。 另一方面，國內(nèi)電信運(yùn)營商正處于轉(zhuǎn)型期，各種組織結(jié)構(gòu)、流程和 業(yè)務(wù)的新建與變更也使得用戶的需求不斷發(fā)生變化。 碩士學(xué)位論文 12 3. 用戶需求的一致性難以保證 在以往的發(fā)展中，由于經(jīng)濟(jì)發(fā)展水平差異較大，各省市移動(dòng)公司依靠自身的實(shí)踐經(jīng)驗(yàn)、管理能 力來思考和探索各自運(yùn)維體系的發(fā)展，致使各移動(dòng)公司之間的差異較大，在標(biāo)準(zhǔn)化運(yùn)維流程的過程中容易出現(xiàn)分歧。這些用戶從事于不同的運(yùn)維崗位，知識(shí)層次不同、年齡對(duì)象不同，因此當(dāng)需求出現(xiàn)分歧時(shí)一致性難以保證。 通過對(duì)本系統(tǒng)需求工作難點(diǎn)的分析，可以看到如何有效的開展需求分析工作，確保系統(tǒng)的需求 可以準(zhǔn)確、有效的獲得將是一件非常重要的工作。在需求啟發(fā)階段， 要盡可能多的啟發(fā)用戶需求， 因此 選擇一種合適的需求啟發(fā)方法是非常必要的。常用的需求啟發(fā)方法有面談和問卷調(diào)查、需求討論會(huì)、自由討論和主意精簡、情節(jié)串聯(lián) 板的制作、應(yīng)用用例、角色扮演以及原型開發(fā) 【 6】 。 針對(duì)本系統(tǒng)需求分析工作面臨的困難，在實(shí)際的工作中 主要 采用了原型開發(fā)和面談相結(jié)合的方法。 面談是一種最直接、最簡單的需求獲取手段，但是存在如何使用戶或風(fēng)險(xiǎn)承擔(dān)人無偏見或無傾向說出自己需要的問題。通過由開發(fā)人員快速構(gòu)建需求原型，用于讓用戶評(píng)價(jià)對(duì)需求的理解的方法，可以幫助用戶更好的理解需求，不僅有利于雙方的交流，讓“模糊”的需求變得清晰起來，還有利于發(fā)現(xiàn)更多尚未發(fā)現(xiàn)的問題。 客戶和最終用戶都有自己的目標(biāo)（在統(tǒng)一過程中也稱為“需要”）碩士學(xué)位論文 13 并希望計(jì)算機(jī)系統(tǒng)能夠幫助他們實(shí)現(xiàn)這 些目標(biāo)。在多種獲得這些目標(biāo)和系統(tǒng)需求的方法中，較好的方法是簡單而又熟悉的方法，因?yàn)檫@樣可以使目標(biāo)和需求的定義和評(píng)估更加容易，特別是對(duì)客戶和最終用戶來說更是如此。這樣做會(huì)降低未達(dá)到這種目標(biāo)的風(fēng)險(xiǎn)。 在統(tǒng)一過程中，需求按照 FURPS＋模型進(jìn)行分類。在一般使用中，需求則按照功能性（行為的）和非功能性（其他所有的）來分類 【 7】 。雖然后者的分類方式非常泛泛，但是這種方式已被廣泛采用，因此 本文 也按照這種方式對(duì)系統(tǒng)的需求問題進(jìn)行描述。 功能性需求 用例可以為項(xiàng)目相關(guān)人員提供一種簡單而易懂的機(jī)制來了解目標(biāo)和系統(tǒng)需求，寫出用 例是一種最好的理解和描述需求的技巧。使用用例來描述功能性需求的思想是由 Ivar Jacobson 在 1986 年提出的， Ivar Jacobson 是 UML 和 RUP 的主要?jiǎng)?chuàng)始人。這一思想已經(jīng)被廣泛的傳播和接受，簡單和有效是其最主要的優(yōu)點(diǎn)。 應(yīng)該怎樣發(fā)現(xiàn)用例？用例應(yīng)該在什么級(jí)別和范圍 上表述？在用例的識(shí)別和表述上，本文 采用的指導(dǎo)原則是 EBP 用例，即對(duì)計(jì)算機(jī)應(yīng)用進(jìn)行需求分析的時(shí)候，應(yīng)專注于“基本業(yè)務(wù)過程”（ EBP）級(jí)別的用例。EBP 是一個(gè)“業(yè)務(wù)過程工程學(xué)”領(lǐng)域內(nèi)的術(shù)語，它指的是“由一個(gè)人在某個(gè)時(shí)間某個(gè)地點(diǎn)執(zhí)行的一項(xiàng)任務(wù) ，這項(xiàng)任務(wù)是對(duì)某一業(yè)務(wù)事件的反應(yīng)，而且能夠增加可以度量的業(yè)務(wù)價(jià)值，并且能夠保持?jǐn)?shù)據(jù)狀態(tài)的碩士學(xué)位論文 14 一致?！睉?yīng)用 EBP 指導(dǎo)原則，可以避免定義許多過低級(jí)別上的用例，這些用例只相當(dāng)于 EBP 中的一個(gè)簡單步驟、子功能或子任務(wù) 【 7】 。為了清晰地描述系統(tǒng)用例的層次結(jié)構(gòu)，可以采用將系統(tǒng)用例分為不同的包，每一個(gè)包表示一組相關(guān)的系統(tǒng)用例。用例包是用例、主角、關(guān)系、圖和其它包的集合，通過將其劃分為若干個(gè)較小部分來建立用例模型 【 8】 。 為了清晰起見，本文 引入了包圖來將不同的功能用例進(jìn)行分類，每個(gè)包圖作為一個(gè)子系統(tǒng)，如圖 21 所示。 圖 21 系統(tǒng)功能包