軟體工程與大型整合專案—以WiMAX整合型計畫為例 (1/3)

以往學生在學軟體工程時，總覺得這門課就是在「寫文件」，對於為什麼要寫文件，以及文件的用途，不甚了解，甚至覺得寫文件是很枯燥乏味的一件事。的確，為了交作業而寫文件，我想沒有人會認為寫文件是有用的，特別是對於一個虛擬的軟體專案而言，即使必須開發對應的軟體，充其量也是一個小品，而且一個學期的時間又很有限，所以不是文件品質不好就是軟體沒寫好，更別提要維護了， 而學生無法對軟體跟專案產生情感，自然無法體會文件的意義。

過去三年，筆者因為主持國科會整合型計畫「WiMAX 無線通訊系統軟體與工具開發(I),(II),(III)」的關係，需要主導撰寫其Light-weight CMMI文件，剛開始的第一年，參與計畫的學生們也是哀鴻遍野，學生們即便已經參加過國科會舉辦的Light-weighted CMMI研討會，寫出來的文件，和實際的軟體設計仍有一段很大的落差，一直到第二年，需要開始維護第一年的軟體時，學生才慢慢體會到軟體工程要的不只是文件，而是文件所帶來的價值：溝通與管理。

有一個經常被提到的問題是「軟體流程」？我們的WiMAX整合行計畫到底有多大呢？是否真的需要軟體工程或是完善的軟體流程才能完成呢？這裡先簡單描述一下我們的案子，大家都知道WiMAX被視為M-Taiwan重點發展項目，WiMAX(802.16e)是一個相當複雜的通訊協定，而我們的目標是開發一套完整的「WiMAX網路模擬軟體」，由於WiMAX由上到下包含許多子層，而各子層又各須非常專業的知識，因此，這個案子需要軟體工程加入，才能有效地整合各種跨領域的知識，構成一個完整的系統。也因此我們(北科大軟體研發中心)才提出這個跨領域的整合型計畫，希望開發出WiMAX網路模擬軟體，以開放原始碼的方式貢獻給業界作為WiMAX參考模型，並分享我們的開發經驗。

在WiMAX的案子中分成三個主要項目：「應用」、「協定」與「輔助工具」，應用有「即時視訊傳輸應用」與「適地性資訊服務」；協定負責WiMAX通訊協定的所有子層包含媒體存取控制、安全加密、實體層編碼、實體層調變與通道模擬；輔助工具則提供通訊軟體模型建構工具與持續整合等輔助。由此可知，計畫規模頗大，最多曾經有12個子計畫。軟體流程不能保證專案如期完工，但能用來監控時程與進度，如果沒有流程，進度落後或是超前，都無法掌握，那軟體勢必是無法順利開發與整合的。

有了第一年的經驗後，為了減輕學生的負擔，並提升效率，除了國科會定期舉辦的研討會外，我們內部每年更是舉辦了多次的教育訓練，讓新加入的成員，能更快速進入狀況，另外，我們也採取了一些策略提昇子計畫間溝通、整合、測試的能力，以提昇計畫產出的軟體品質。這些訓練包含了文件、開發環境與測試等，在接下來二年的計畫期間有不錯的效果，因此我們將這些經驗整理出來和大家分享。本文(以及以這個主題陸續發表的文章)是筆者與博士班學生杜秉穎(總計畫的Project Manager)這三年來的經驗，接下來的幾週，將依序分享下列主題：

1. 溝通工具(Communication)—第二年起，在溝通子計畫介面時，最常使用的溝通工具是UML的使用者案例(Use Case)與循序圖(Sequence Diagram)，特別是循序圖，簡單易懂，銜接了不同專業領域的開發人員。
2. 教育訓練(Education)—在我們連續三年的專案期間，不斷有碩士班學生畢業是無法避免的，為了讓新進人員快速進入狀況，教育訓練是必要的，因此，過去二年，每年都會舉辦教訓訓練包含多項主題，這些主題都會在之後的文章中提到。
3. 程式碼檢閱(Code Review)—即使有教育訓練，不同領域的開發人員，因為他們過去的背景，會讓他們以各種不同的想法採用特殊的程式設計，因此需要進一步去檢閱程式碼，去除不同想法所產生的錯誤與差異。
4. 測試(Testing)—一個龐大的軟體，如果沒有足夠的測試是很難整合的，所以測試是需要經過設計跟訓練的，在不同階段需要不同的測試，在過去三年，我們使用了單元測試(Unit Test)、迴歸測試(Regression Test)與測試驅動開發(Test Driven Development)等技巧減少錯誤，利於整合。
5. 軟體架構評估(Software Architecture Evaluation)—其實軟體架構在大型軟體中是非常重要的，而且會完全影響到後續的設計，因此軟體架構應該是第一個談論到的主題，但沒有前面的說明作背景，冒然進入軟體架構的主題，其實是無法帶給讀者深刻體會的，因此，我們把軟體架構留到最後再分享。

作者：陳偉凱、杜秉穎

如何使用Use Case
WiMAX整合型計畫在第一年結束後歸納出一些問題，其中最大的問題在於模擬的方式和監控，第一年的設計以簡單快速為優先，因此即時視訊傳輸應用與模擬環境直接整合在一起(透過專屬的API進行傳輸)，然而，這樣的設計導致其他應用軟體無法使用模擬環境。另外，WiMAX通訊協定之間的運作情形無法直接監控，這與我們一般對於模擬軟體的認知不太一樣。

為了改善這些問題，我們在第二年加入「虛擬網路」的觀念。我們把模擬的網路稱為WiMAX虛擬網路，並為虛擬網路安裝「虛擬WiMAX網路卡」驅動程式到Linux OS中。因此，任何應用程式只要使用標準的TCP/IP協定，即可透過虛擬WiMAX網路卡，使用模擬環境。此外，我們也在虛擬WiMAX網路卡驅動程式中加入監控的機制。但是，問題來了，這是一個全新的需求，我們應該如何釐清系統架構呢？新的系統應該是什麼模樣呢？而使用者又如何使用新的系統呢？其實這些問題環環相扣，應該先從那個問題下手呢？

套一句商場的名言：「顧客永遠是對的」，因此，我們從使用者的想法下手。目前大多數的網路模擬軟體，都能夠模擬多個網路節點，用以觀察在大規模使用者或是節點的網路效能表現，或是觀察距離與無線傳輸品質的關係等，因此，我們使用了「佈署(Deployment)」的觀念，讓使用者可以自行佈署(建構)一個WiMAX無線網路的環境，以進行模擬並觀察其表現，因此，我們歸納出幾個重要的使用案例(Use Case)，畫出使用案例圖(圖1)：

圖 1 使用案例圖(Use Case Diagram)

有了使用案例圖，事情就結束了嗎？其實不然，使用案例圖對系統的設計沒有幫助，這張圖只是做大架構的溝通而已，真正重要的是使用案例的內容，為了顧及篇幅，表1是一個簡化後的使用案例 。

表 1 使用案例：開始模擬

從使用案例能看出什麼呢？系統事件(System Events)。也就是系統如何與使用者互動，於是我們將每個使用案例畫成如圖2的系統循序圖(System Sequence Diagram; SSD)，然後用使用案例和SSD，找出是否有遺漏的地方，或是操作流程可以改善或簡化的空間，重要的是，除了正常的流程之外，也需要考慮例外處理的方式，例如表1的Extension中就列出了可能遭遇的例外，但很明顯地，目前還沒有任何處理的措施，原因很簡單，設計不是一次到位的，此時還沒有系統架構，當架構不同時，所使用的例外處理措施也跟著不同，但至少我們已經將可能的例外考慮進去了！

有了Use Case和SSD後，我們將進入更細節的設計，下個單元我們將會System Event展開成細部的Sequence Diagram，此時我們就能夠看到每個子系統在一個系統事件觸發時，如何跟其他子系統相互運作，完成一個使用者要求的任務。

圖 2 System Sequence Diagram

作者：陳偉凱、杜秉穎

如何使用Sequence Diagram溝通
有了SDD(System Sequence Diagram)以後，系統架構的設計漸漸成型(以後會再介紹系統架構的設計)。由於我們希望能同時模擬許多基地台(Base Station，簡稱BS)與行動用戶(Mobile Station，簡稱MS)，而BS與MS實體層的模擬又需耗費很多運算資源，因此，我們採用分散式設計，使用一個節點(電腦)模擬一個BS或MS，並在每個節點都安裝WiMAX虛擬網卡與代理人(Agent)程式，利用代理人在背景進行模擬。節點之間則以實體網路與主控台連接，透過主控台(Console)決定實際參與模擬的節點數量、節點扮演的角色，以及其他佈署所需的參數。

代理人是一個有限狀態機，會聆聽並執行Console從網路上傳過來的指令，切換本身的狀態。如圖1所示，代理人一共有四個主要狀態：閒置(Idle)、基地台(Base Station)、行動用戶(Mobile Station)與閘道器(Gateway)，每個狀態中又分成若干個子狀態，例如基地台狀態下，又可分成尚未開始模擬(Not Simulating)、模擬中(Simulating)以及模擬並監控中(Simulating & Monitoring)三個子狀態，不論是哪個子狀態，一旦收到Console送來的重置(Reset)事件，代理人都回到Idle狀態。

圖 1 代理人的四個主要狀態


圖 2 Base Station的三個子狀態

那麼當代理人切換狀態時要做些甚麼準備動作呢？此時我們將SSD中對MS發送的Initialize系統事件展開成更詳細的流程。由圖2可以看出，Console對代理人(節點)送出「Initialize(MS)」的系統事件後，代理人根據訊息的內容，得知BS的實際網路位置，建立與BS的連線，並傳送自己的WiMAX Basic Connection ID給扮演BS的代理人，接著BS和MS都將ID與連線建立配對，待之後查詢使用，最後代理人切換狀態為MS，並告知Console已正確完成初始化。

圖 3 Inialize系統事件的Sequence Diagram

至此為止都還是代理人的狀態轉換，與WiMAX的協定運作還沒有太大的關聯。WiMAX協定相當複雜，BS與MS之間的訊號傳遞依時間切割為若干個Frame，而每個Frame又將BS送資料給MS的時間稱為下行(Downlink)，反之稱為上行(Uplink)，因此，當開始模擬後，程式就進入一個迴圈(代理人使用多個執行緒負責網路、指令與模擬)，不斷地重複下行、上行以及一些為了模擬而必須進行的額外運算，例如計算行動用戶與基地台的距離等。

若只有單一的代理人，則這樣的敘述已經足夠了，但是，真正在模擬的時候，其實是多個基地台和多個行動用戶端同時運作的，那麼，我們怎麼檢視這樣的設計是否完善呢？此時，循序圖又可以幫上忙了，循序圖對於多個程式實體的運作，以及時間順序的表達能力相當優異，圖4顯示一個WiMAX Frame中，多個代理人(二個基地台、二個行動用戶和一個閘道器)是如何協同運作的，透過圖4我們可以清楚的了解程式的運作，並且找出是否有遺漏的地方，有助於了解設計的完整度。

圖 4 用循序圖了解多個代理人的協同運作

談了這麼多，圖4仍為非常高階的互動關係，主要是代理人與代理人之間的互動，那麼子系統與子系統之間的互動呢？其實圖4已經清楚地標示出子系統運作的時間點了，我們只要把各別的函式再展開就能看到子系統的互動了，就像是洋蔥一樣一層層剝開。圖5是將圖4的downlink()函式展開，從圖5可以看到代理人如何從Driver取得網路封包、如何使用CS子系統進行封包分類、如何使用QoS子系統進行封包排程、使用Security子系統加密、如何使用PHY1子系統進行編碼和使用PHY2子系統進行調變，最後透過實體網路送給另一個代理人。

當另一個代理人收到調變過後的無線訊號，再利用Channel子系統加入無線訊號在空氣傳遞的衰減等模擬現象，然後使用PHY2子系統解調變、用PHY1子系統解碼、用Security解密，最後代理人根據封包內容進行路由(Routing)的配送。一整個Downlink流程在這一張循序圖就可以完整的呈現。

其實圖5的重點是「溝通」。這一張張複雜的循序圖是經由許多個月，所有子系統的負責人透過會議慢慢討論出來的，開會時，只需要一張白板，一個人主持會議，在白板上畫上多個子系統後，就可以開始討論，每一條線都視為一個函式，即使沒有學過UML或是物件導向分析與設計的學生，還是相當容易上手，能以最快的速度加入討論，討論的結果也有助於程式設計，相較於使用案例圖、類別圖，我們發現循序圖可以說是這個整合型計畫中，通訊領域學生最能接受的溝通工具。

圖 5 下行(Downlink)展開後的循序圖

作者：陳偉凱、杜秉穎

開發環境與教育訓練
有了簡單的設計後，可以開始開發程式(Programming)了。事實上，大多數的學生喜歡寫程式勝過設計(Design)，總是先寫了再說，等問題發生後再回頭找原因。但是，對於大型的專案而言，寫的太快有時是不好的，因為架構性的問題常常在開始寫程式之後才漸漸暴露出來，如果一開始就沒有適當的規劃，程式的規模和品質是很難提升的，這也是為什麼我們在第二年花了這麼多時間，用各種不同的溝通工具做討論和設計，目的就是希望能在初期找出關鍵性的問題。

第一年在討論子系統的外部界面後，總計劃就放心讓子計畫成員開始開發程式。但問題不斷地浮現，別說是整合，光是讓程式能夠順利編譯，就常常得花費一番工夫。在程式開發了約二個月後，總計劃發現子計畫團隊間的開發環境並不完全一致，雖然目標都是Linux，但是，由於開發成員來自不同領域，慣用的Linux版本不同，而且有的團隊慣用Dev C++，有的團隊慣用Visual C++，有的團隊慣用Eclipse；有的團隊自己寫Makefile控制編譯的過程和結果，有的團隊則讓IDE控制這一切，這讓不同團隊的程式整合在一起編譯時，造成很大的困擾。當然，作業系統也影響到程式的開發，在Linux不同的Distribution之間或Microsoft Windows上開發程式，難免會用到一些OS-dependent的Library，或是路徑上的差異，這些都是問題。

發現問題後，在一次計畫整合會議中決定，為了符合Open Source的精神，所有總計畫以及子計畫的程式都一律在Linux上開發，而且Linux的Distribution以及IDE均由總計劃團隊決定。感覺上似乎事情很快就會被解決，然而事實上卻不然，總計劃團隊花了若干時間討論Linux Distribution的差異，最後選擇Fedora Core 6，IDE則是使用Open Source的Eclipse搭配CDT與Subclipse套件，GUI函式庫則使用GTK+，另外再加上CppUnit及ImageMagic函式庫，至於關鍵的Makefile，則是由總計劃團隊編寫一個泛用的版本，讓其他子計畫團隊成員不需擔心其他細節，只需將要編譯的檔案加入即可，於是一個完整的開發環境被訂定下來並公布給所有子計畫團隊成員。

不料，公布了開發環境後不久，相同的問題又重複發生了。主要的原因是大多數學生都只有一台電腦，礙於其他課程需要用到特定的軟體，不可能把Windows移除，安裝Fedora Core 6，加上大部分學生還是習慣用終端機(Console)的輸出來除錯(Debug)，泛用的Makefile無法讓子計畫成員產生他們所需要的可執行檔，這些因素讓許多子計畫團隊成員不願意使用總計劃所制定的開發環境。結果當然是第一年整合的非常辛苦。

為了解決這個問題，在第二年開始之前，總計劃提出一個對策：「使用虛擬機器(Virtual Machine)」。總計劃將新版本的Fedora 8和Eclipse安裝在虛擬機器中，並燒錄成光碟，讓團隊成員不需要移除自己電腦裡的Windows，只需安裝虛擬機器，並執行光碟中的映像檔，即可使用總計畫規範的開發環境開發程式。這個作法獲得高度的成功，一方面是虛擬機器的效能表現能符合開發所需，另一方面是，總計畫在子計劃開始寫程式前，主持了一系列的教育訓練，教導子計劃團隊成員如何使用共同的開發方式，包含：

1. 如何使用虛擬機器中的開發環境：虛擬機器的安裝、啟動開發環境和開發環境的使用。 
2. 開發環境的版本控管：由於部分程式需要root權限才能執行，所以教育訓練中也提到Linux、Eclipse或是函式庫的更新，該如何處理。
3. 程式開發的規定：由於新版Eclipse在自動產生Makefile的部分改善很多，唯一缺乏的是對多個建置目標的支援，為此，總計劃將自動化測試加到主程式中，透過參數(-test [target])的設定，同樣的程式就能執行所有的測試或是指定的子計畫測試。也教導如何將傳統的除錯方式改寫成自動化測試，如此子計畫對Makefile的依賴度就更低了。

上述教育訓練的教材也都被納入版本控管中，當新的團隊成員加入時，可以在每年計劃開始之前就進行訓練，讓成員更替的影響降低。從第二年開始，子計畫使用統一的開發環境比例相當高，只有少部分的成員因為電腦較舊，採用二階段的方式：平時自己開發時用Windows的機器，要上傳到Subversion之前才將程式移到虛擬機器裡的開發環境中測試後再上傳。第三年起總計劃撥出一間獨立的研究室給專案成員使用，並將閒置的舊電腦裝上原生的Fedora，建構出更完善的開發環境，不論是軟體的環境還是實體的環境，都讓團隊成員更樂意使用統一的開發環境，這讓總計劃在第三年後，對於開發環境帶來的困擾降到最低。

作者：陳偉凱、杜秉穎

CMMI文件整合

最近正好是國科會自由軟體計畫繳交系統需求規格書(Requirement Specification Document)與專案計畫執行書(Project Execution Plan)的時間，相信有許多人正在趕工寫文件。我們當然也不例外，正在處理文件的整合，只是文件整合工作越到繳交截止日反倒是稍微輕鬆點，主要是我們有一個制式的流程，讓每個子計畫知道什麼時候該做什麼事。

這套流程並不是憑空出現的。以前執行個別型自由軟體計畫時，文件只需要自己對自己負責即可，沒有整合問題，但是整合型計畫就完全不同了，如果放任子計畫自由撰寫文件，總計畫只是將文件「拼湊」起來，則不但文件內容不會連貫，甚至連文件格式都無法一致。三年前我們第一次接觸「整合型計畫」，在整合文件時大吃苦頭，摸索一整年才慢慢找出一些方法，並在往後的二年以及今年使用，目前效果還不錯，因此和大家分享。如表 1所示，文件整合流程從開始到結束大約需要10個星期，主要分成5個階段：事前準備、教育訓練、文件撰寫、形式審查跟文件整合。

表 1 文件產出流程

準備階段：為了讓後續的整合能更加順利，事前準備相當重要。此外，一份文件的好壞，其「格式」往往扮演相當關鍵的角色，一份井然有序、格式一致的文件，給人的第一印象就是舒服跟專業，所以在準備階段，總計畫的主要工作便是替每個子計畫製作文件範本，就像使用PowerPoint的範本一樣，子計畫成員專注在內容的撰寫，格式則由範本決定。所有的範本都有一致的格式，包含紙張邊界、封面、字型、文字大小、章節編號、自動編號(用於標示介面跟需求)、頁首與頁尾等，使得子計畫產出的文件格式能統一，便於整合。最後，總計畫還要針對不同的文件準備教材(由於國科會文件的要求變化不大，若是多年期計畫，可以沿用或修改舊教材)。

• 教育訓練階段：學生大多不喜歡寫文件，而且我們的團隊中有部分子計劃對於軟體工程領域並不熟悉，對於國科會要求的Light-Weighted CMMI文件更是一籌莫展。所以在開始撰寫文件的第2週，總計畫即召開教育訓練，教導子計畫成員如何撰寫文件，重點放在文件內容的說明，如文件裡每個章節的重點和為何需要寫這些內容等，讓非軟體工程領域的團隊了解寫文件不是交差了事，而是讓文件輔助計畫的進行。
• 文件撰寫階段：教育訓練結束後，便進入文件的撰寫，但事實上長達5個星期的時間，討論執行計畫、系統需求、設計和測試的方法，才是重點，文件不過是這些討論後記錄下來的副產品，因此總計畫在這段時間召開多次的討論會議，探討文件所需的內容，讓文件不是「交差用」的，而是與計畫的執行相輔相成的。
• 形式審查階段：文件由子計畫成員負責撰寫，其內容與格式難免會出現瑕疵，因此，我們安排了近3個禮拜進行內部審查，除檢查格式是否有問題外，主要是檢查內容是否有短少、錯誤，以及繪圖(尤其是UML圖)語法是否正確。由於子計畫內容是否錯誤會牽涉到不同專業領域的知識，因此總計畫通常只能檢查子計畫內容是否符合討論的共識，更細部的內容則是由子計畫的主持人自行檢查。我們的內部形式審查使用2年多來，讓我們在國科會審查後被要求修改的比率大幅降低，通常總計畫與多數子計畫都不需要再修改文件。
• 整合階段：第一年文件的整合讓總計畫大吃苦頭。主因是各子計畫的Word檔案在合併時，其自動編號、章節編號或是格式常常會變得亂七八糟，於是總計畫在合併了10份Word文件後，只好重頭到尾重新調整格式和自動編號，這是相當痛苦的，而且當部份子計畫又有內容必須調整時，往往格式又得重調，非常浪費時間。第二年起，我們決定不直接合併Word檔案，而是先將Word檔轉為PDF檔，然後將PDF檔合併，如此，文件的合併變得容易多了，只需在事前準備時，將所有的自動編號和章節編號處理好，先將各別子計畫的文件輸出成PDF檔，然後再依序合併PDF檔即可，唯一還需要人工的部分則是目錄，不過卻輕鬆很多，只須到各子計畫輸出的PDF文件中，將目錄以純文字方式複製到總計畫的目錄裡，然後將目錄輸出成PDF後與其他PDF文件合併，即可完成一份整合的文件。

國科會有固定的文件繳交週期，雖然這個週期比較接近Waterfall模型，但是，並不表示專案的執行就得是Waterfall模型，一樣可以用Iteration或是Incremental等模型。我們WiMAX計畫採用的是Light-weight RUP模型，我們只須將Iteration的精神融入上述每次文件的10個星期執行時間中(也可以將10個星期拆散到不同的Iteration中)，一樣可以讓專案順利進行，準時繳交國科會要求的文件，重點在於如何讓文件融入到專案並輔助專案順利地執行。

作者：陳偉凱、杜秉穎


軟體工程與大型整合專案—以WiMAX整合型計畫為例 (2/3)