對網管軟體開發的一點感悟

本人在畢業後不長的工作時間裡，大多數時間從事的都是電信網管軟體的開發，期間經曆了大小不同的公司，也有幸從頭到尾做過一些大型的網管軟體的開發，甚至還不自量力的要去做一些網管開發平台。

  我個人的背景，主要是在EMS（網元管理層）網管的開發，對NMS層有一些接觸，對裝置的開發也有些接觸，但都屬於隔靴騷癢，看著別人爽，文中提到的方法和思路，雖然多為通用的，但具體的一些方法對於其他類型的軟體未必適合。
 
  傳統的TMN裡，EMS網管只是其中一小塊，借用TMN的方法論，就EMS網管本身，用介面劃分的方式，網管有如下三個大的介面：

  G介面
：為網管提供給操作營運人員的人機介面(MMI)，一般有基於BS技術的Web形態，基於CS技術的Java Swing, Delphi，基於命令列的CLI也是一種人機介面，這個G字可能需要再廣義一點。

  F介面
：為網管內部介面，主要在網管的伺服器和各類用戶端之間的介面，網管一般採用集中式部署的模式，
網管伺服器對裝置一般充當了Manager的角色，它的用戶端有多種形態，包括各種G介面的實現，甚至可以將網管與上級網管之間的北向介面也作為一種客戶
端，F介面就是這些用戶端和伺服器之間的介面。

  Q介面
：為網管和被管裝置之間的介面，它是一種機機介面

  G介面代表了網管的管理需求(Managing Requirements)，Q介面代表了網管的被管需求(Managed Requirements)，而F介面代表了網管的開發需求(Development Requirements)。

  在我從事的很多網管項目的開發，由於團隊中開發的角色較多，對網管的認識不足，產生了一些誤區，概括的來講，就是：
  1、從F介面入手：因為在開發人員佔主導，或者具有較深開發背景的佔主導的團隊中，大家往往最能想清楚的就是開發的這麼點破事，所以，最容易先抓住F介面不放，設計各種模型，服務；

 
2、忽視Q介面：忽視Q介面的理由很多，有裝置方面的問題，諸如裝置沒有定稿，裝置不在自己掌握範圍之內，裝置介面不規範，總是能找到一大堆理由，但忽視
了Q介面這一點很致命，一個網管，如果在開發過程的始終都沒有搞清楚自己管的東西，如何成為一個"正確"的網管，如果連正確都做不到，這個產品或者項目就
免談成功了.

  3、隨意指定G介面：G介面的隨意化，也是有多種原因
  首先就是需求管理的不嚴格，不規範，國內現在很多軟體公司，呆在家裡三言兩拍就可以為使用者想好需求，隨後設計介面和互動流程（就是G介面）；
  其次也有現在項目團隊組成過於複雜的原因，從使用者到產品經理、系統工程師，設計人員、開發人員，各種測試人員，實施人員，一個原始的需求，經過若干個部門和流程上的環節，傳導到真正開發這裡的時候，已經是面目全非，時間也滯後了很多。

  實際上，以上的三個介面有其各自的特點：
  G介面：形態多樣化，需求變化較快，雖然網管的介面需求變化趕不上業務系統的變化，但由於這個介面是面向具體的人，其需求的變化是最難以琢磨的，但各種介面元素、流程其中的可複用度又是非常之高。
  F介面：實現技術多樣(WebServcie, Java RMI, Corba...可以列舉一大堆)，實現方式多樣(各種設計模式都可以在這裡一展身手)，彈性十足，高水平的網管和低水平的網管，其F介面的設計和實現很容易有雲泥高下之分。
  Q介面：相比較為穩定，無論從介面資訊本身，還是從介面的實現技術(Snmp,TL1,Q3,Corba,各大廠商的私人協議...)，往往都比較穩定。

 
而我以上所提到的錯誤的網管開發思路，其主要錯誤就在於一開始抓住的是一個具有多種實現方案，不該被固化的F介面，而忽略了一個可以被“固化”的Q介面，
隨後而來對G介面的開發的錯誤也自然而然，甚至有一些更錯誤的方式是先定義G介面上各種介面，而後為每個介面定義一套F介面上的服務和模型，在我看來，這
更像是一種過程式的開發思路。

  寫了這麼多，好的方法在哪裡？我個人認為，好的步驟是：
  1、深挖Q介面，整理出其中的資訊模型和介面、主要商務程序
  2、詳列G介面，將所有的介面都預先通過Screen Design(介面設計)，Interactive Process Design(互動流程設計)的方式列舉出來，找出其中共用的介面組件、互動流程。
  3、歸納F介面，F介面本質上是為G介面服務的，當G介面被詳細列舉之後，其中共用或者類似的組件，流程，所調用的F介面往往都是類似的，這些介面就是可歸納的，而不需要每個模組，每個對象都重新定義一套模型和服務。