要能有效的運用RUP，很重要的一點，是先去了解它的幾個主要目標、每個目標為何重要、以及這些目標如何能結合在一塊運用，來幫助開發團隊生產出符合專案關係人（stakeholders）需求的高品質軟體。    作者：Leslee Probasco (Development Manager/Rational Unified Process Rational Software Canada)         不論是籌畫一場露營之旅，或開發一個軟體專案，先確立出本質都很重要。不久前的一個傍晚，我的鄰居Randy跑來找我幫忙：他正在計畫週末的露營和遠足，並決定要帶哪些家當。他知道我經常參與這類的野外活動並擔任嚮導，而且對於我可以馬上且有效決定出要帶什麼、並塞進包包那有限空間的能力感到印象深刻，他指著我的一份清單上所列的裝備和衣服，問道：『你覺得我可以參考這份清單嗎？』      『當然可以，但恐怕沒多大用處。』我接著解釋：『你瞧，我出門要帶的這些家當，結結實實的有好幾百項，是考量到各種類型的旅遊才訂出來的。從一只簡單包包的徒步旅行及登山、到滑雪、到行走雪地、到登冰山、到乘小艇；時間則從簡單的一日遊到為期數天的『遠征』不等。』      相對於上述比較簡單的這次旅遊計劃而言，我知道，如果沒有某些指導，Randy很可能無法從我那一拖拉古的清單中，理出他真正要帶的東西。       從核心需求開始，然後依需求再加東西        先不看我那份一長串的清單，我的做法是，先把Randy已經快塞爆包包裡的東西一項一項來看：有哪些東西可以不用帶，以減輕他的負擔？又有哪些東西應該要帶，但他卻漏掉了？沒多久，我就確定Randy真正缺乏的，是任何想去野外郊遊都要先了解的『本質需求』。      我撕下一張白紙，列了這十項『本質』：（註一）   1. 地圖 2. 指南針 3. 太陽眼鏡和（防曬油中的）遮光劑 4. 大件的衣服 5. 額外的食物跟飲水  6. 頭燈（headlamp） 7. 急救箱  8. 火種（Fire-starter） 9. 幾個同伴（Matches） 10. 小刀          『哪！Randy，這十項才是你真正需要的，如果你每次旅行都從這十項『基本需求』開始，那其它要帶的東西就會慢慢浮現。』      多年前開始登山時，這十項需求我就背得滾瓜爛熟了，現在，不管碰到任何旅行、也不管要去多久，我都還是會參考這十項需求。      這十項中的每一項都可大可小，看旅遊的性質而定。而一開始少少的列上幾項，然後依需求再加，會比一開始就列出一長串，然後再從中決定哪些不要，來得容易許多。    運用此原則於RUP之上        通常，當我幫助專案團隊從眾多RUP的實施要項中理出頭緒之時，我都會聽到這種問題： 『RUP這麼些的要項中，我怎樣才能決定出當下的專案需要哪些？』 『RUP的東西真的太多了，一定只是給大型專案用的吧---我這種小的專案規模真可以用得上嗎？』       對不熟悉RUP的人而言，上圖呈現出的是RUP循環漸進的本質，其中涵蓋大量軟體開發流程的心法（disciplines），包括各個流程的產物（artifacts）、各種指導方針（guidelines）、每個開發人員所扮演的角色（team member roles）、以及各個要做的動作（activities）。 顯然，對不熟悉RUP的人來說，他們真正需要的，是像我給Randy那樣的『基本需求清單』---可以當作是任何規模專案合理開頭的清單，這份清單會把焦點放在我所謂的RUP、或任何有效率的類似軟體製程的『本質』上。 通常，在所有專案參與成員搞清楚製程的幾個主要的點、並據以準時開發出高品質的產品之前，都會讓自己身陷在某個特定細節的泥沼之中。之後，當進度落後了，就又對那些之前過份強調、或不明瞭其重要性的某個動作交相指責：『你看吧，我早就跟你說了，需求管理（或使用個案、專案各項評量指標的蒐集、組態管理、瑕疵追蹤軟體、進度會議等）會讓我們整個的開發速度變慢！』 而有一套『基本』清單在手，可以讓專案團隊對於整個軟體製程，採用一種更為系統化和整體性的方法。一旦具備這種『製程框架』或『製程架構』（譯註一），團隊成員就可以有效的專注在某些個別的問題點（而通常我會覺得需求管理是首要的議題）。另外，一開始找出明顯的問題及其相關的風險，並排定處理的優先順序，也是很重要的，這樣團隊才能據以在早期就採行必要的策略來降低風險。 RUP的十項本質 那麼，RUP的十項本質有哪些呢？我會選這十項： 發展出一個願景 經營出一個計劃 確立並降低風險 指出並追蹤議題 弄清企業的運作 設計出元件架構 漸進開發及測試 確認並評估成果 管理並控制改變 提供使用者支援 接著，我們就一個一個來看，它們對應到RUP的哪個地方，並了解為何它們可以成就出我的『基本需求清單』。 1. 發展出一個願景 要開發出一個真正符合關係人所需的產品，心中有個清晰的願景至為關鍵。 願景捕捉到了RUP需求流程的本質，亦即分析問題、了解關係人需求、定義系統範圍、以及管理需求的變動。 願景為之後較詳細的技術規格，提供了一種高階的契約式基礎。顧名思義，它是一種觀察專案的清晰且高階的角度，這種角度可以在整個開發期間，讓決策者及開發者都更易於了解系統的內涵。它所捕捉到的高階需求及設計規範，給想了解的人知道系統將會如何發展。願景也為專案是否真要開發提供了資訊，因此跟企業實際的運作也是息息相關的。最後，因為願景所傳達出的，是一種關於專案基本的『為何及本質』的訊息，所以也可以用來驗證之後的決策是否恰當。 願景應該要能夠回答下列的問題，這些問題也可以再各自打散成獨立且更細的項目： · 我們主要用的術語是什麼？（詞彙表） · 我們要解決的問題是什麼？（問題描述）（譯註二） · 我們是為誰發展這套系統？使用者是誰？他們各自的需求又是什麼？ · 系統的功能特色在哪裡？ · 系統的功能性需求是什麼？（使用案例） · 系統的非功能性需求是什麼？（譯註三） · 系統設計上要遵循哪些規範？ 2. 經營出一個計劃 『計劃做得有多好，產品才能做得有多好』（註二） 在RUP裡，軟體開發計劃（Software Development Plan，SDP）統合了管理整個專案所需的一切資訊，也包括了一些在初始階段（Inception phase）就發展出來的獨立工作項目（items）。這些東西在整個製程中，都必須不斷維護和更新。 SDP定出了專案的時程（包括整個專案及個別開發循環的時程）、所需的資源及工具。它也被用來依照既定時程追蹤進度、以及指導其它製程的規劃：像是專案組織、需求管理、組態管理、問題解決、品質保證、測試計劃、測試案例、評估計劃、產品接受度計劃等。 在比較單純的專案中，上述這些計劃內容可能只是短短的一兩句話，例如組態管理可能只是簡單的寫成這樣：『每天要做的最後一件事，是把專案目錄結構給壓縮起來、然後copy到一張有日期標籤的zip磁碟上、標明版本，最後放回中央檔案櫃裡』。 SDP的格式，比不上要把東西做出來的動作、和要表達出的想法來得重要。如同Dwight D. Eisenhower所說：『計劃內容（plan）本身不重要，計劃的過程（planning）才重要』。 『經營出一個計劃』連同我們十項中的第三、四、五、八項，共同捕捉到了RUP裡專案管理流程的本質。該流程牽涉到專案面貌的構築、專案規模與風險的評估、專案的監督與掌控、還有每個階段（譯註四）和每個開發週期（譯註五）的規劃與評估。 3. 確立並降低風險 在專案早期找出最大風險並予以迎頭痛擊，是RUP裡的一個重要定律。每個風險都必須要有個相對應的降低風險計劃。風險清單不止在規劃專案的各個動作時可以用上，它也應該是決定開發週期的一個根本基礎。 4. 指出並追蹤議題 對任何專案而言，把進行中的動作和不斷改變的產品組態所獲得的資訊拿來分析，都是件要緊的事。以RUP來說，經常性的對整個專案做些狀態評估，提供了一種機制，這種機制可以指出、溝通和解決管理與技術上的問題和風險。一旦確立出妨礙專案進行的種種障礙，就可以指定負責的人力限期解決它們，解決的進度應該定期追蹤，並在必要時調整進度。 這些個『專案速寫』（project snapshots）點出了管理階層需要注意的議題，儘管做這些動作的時機跟做多久不一定，但此種經常性的評估，卻能讓經理人捕捉到整個專案的來龍去脈，並移除阻礙專案進度的瓶頸或『石頭』。 5. 弄清企業的運作 企業個案（Business Case）從營運的角度提供了專案是否值得投資的一切資訊，也有助於發展出一個實現願景的經濟方案，它提供了專案存在的理由，並確立出預算上的限制。隨著專案持續的推動，分析人員會用它來精確的估算出該專案的投資報酬率。 企業個案要擘劃出一個讓所有參與專案的人，都能輕易理解和記住的信服理由，而非深入去探究某個特定問題的細節。在專案的某些重要里程碑，經理人應該要回歸到該個案，來評量實際的成本和報酬與當初預估的差多少，然後決定專案還要不要繼續。 6. 設計出元件架構 依照RUP的定義，在某一特定的時間點的軟體系統架構，是由系統大顆粒的關鍵元件經由介面，依次與更小顆粒的元件及介面互動，所構築出來的組織或結構。我們關心的是：主要的元件是什麼？它們又如何搭配在一起運作？ RUP有一套條理化、系統化的方式來設計、開發、及檢驗此一架構，在分析及設計流程中，含括了定義出一個候選架構、逐步琢磨該架構、分析其行為、最後定義出系統要的元件等步驟。 要說出並讓人能理解你的架構，首先要有一個架構的表示法，能描述出架構重要的構面。RUP裡的軟體架構文件（Software Architecture Document）做的就是這件事，它呈現出軟體的多種觀點（亦即構面，譯註六），每個觀點所滿足的，都是開發流程中某些專案關係人所關心的某些事，像是終端使用者、系統設計師、專案經理人、系統工程師、系統管理者等。該文件也有助於促進系統架構設計者與其它專案成員間，對於一些在架構上很重要的專案決策，進行有效的溝通。 7. 漸進開發及測試 RUP裡實作及測試流程的本質，是在專案全程均採漸進式的元件開發及測試方式，初始階段之後的每個開發週期結束時，都會產生一個可以執行的版本。 在規劃階段（elaboration phase）的最後，會有一個可供評估的架構雛形出來，而必要的話，使用者介面雛形也可能在其中。之後，在建造階段（construction phase）的每個開發週期，元件都會被整合到經過測試且可以執行的某號版本之中，逐步形成最終的產品。 在此部分的流程中，持續的組態管理及檢測（review）的動作，也是至為關鍵的。 8. 確認並評估成果 顧名思義，RUP裡的開發週期評估捕捉的是某個開發週期的成果，這決定了該週期到底達成當初定下標準的多少，也包含了該週期所學到的一些教訓，還有之後要實施的製程變動。 依照專案的規模、風險、和該週期的本質，評估結果可以從某個功能示範及其結果的簡單記錄，到完整而正式的測試檢驗記錄。 此處的關鍵，是專注在某些製程及產品的瑕疵上，不然，你落後的愈早，之後要追上進度所花的時間就愈多。 9. 管理並控制改變 在整個專案週期中，每當有變動發生，就是組態及變動管理派上場之時，這個動作的本質，是管理並控制專案在面臨變動之後的規模。其目的，是要能考量到所有專案關係人的需求，並儘可能的予以滿足，而且最後也必須還能準時的交付出高品質的產品。 使用者一拿到產品的初版雛形時（通常甚至比這個更早），他們保證就會要求改這改那，所以，有一套前後一致的提出並管理這種變動的標準流程，是很重要的。 在RUP裡，需求的變動可以用來記錄並追蹤系統的瑕疵、新增的需求、還有以任何形式變動的需求。這種變動提供了一種手段，可用以評估該變動對系統會造成的潛在衝擊、及記錄當初決定接受該項變動的決策歷程，也有助於確認所有的專案成員都能體認到這種衝擊。 10. 提供使用者支援 RUP裡的部署流程本質，是準備把產品包裝起來，連同所有有助於學習、使用、維護該產品上的必要東西，一併交付給使用者。 最低限度，應該要有一套使用者手冊--也許是用線上輔助說明這種方式呈現，也許再加上一個安裝指引和版本說明。而隨著產品複雜度的不同，使用者也許還需要教育訓練的教材。最後，還應該附上一份『物料清單』，清楚的載明哪些東西應該隨產品一併交付。 那需求呢？ 看了我的這份清單後，你們之中可能會有些人極端不同意這些選擇。比方說，你們可能會問，那系統的需求呢？它在你的這份大架構中位於何處？難道它們還不夠『本質』嗎？ 我來告訴你為什麼，因為有時候，我會去問某個專案團隊（特別是搞企業內部專案的團隊）：『你們的需求是什麼？』然後得到這樣的回答：『實際上，我們根本沒什麼需求呀！』 剛開始我還覺得這很誇張（因為我的背景是搞軍方航太系統的嘛），這些人怎麼可以就這樣沒有需求？但當我更深入的跟這些團隊談過之後，我發現，對他們而言，『需求』的意思是外部強加的『要做什麼』、不然專案就根本不會開始的那些聲明。而對內部專案而言，根本不會有這種東西！特別是，如果那個團隊專注的是研發時，在整個專案開發過程中，這種需求還可能不斷演化改變呢。 所以，對於這樣的專案，我順著他們的答案，提出了另一種問法：『好吧！那你們產品的願景又是什麼？』這時，他們的眼睛開始發亮，之後的溝通就容易多了。於是我們把上述第一項本質的每個問題都走了一遍，『需求』很自然的就出來了（譯註七）。 對於那些依照載有特定需求的契約行事的團隊，在他們的本質清單上有條『符合需求』也許是蠻有用的。至於我的清單，也只是想起個頭，拋磚引玉而已。 結論：運用此十項本質 如此，這十項本質的發現，可以為我的目前狀況帶來什麼改變？這裡最後要談的，是這些清單可以運用在幾種不同規模專案的一些方式： 很小的專案 首先，如果有人問我，剛剛才要起步學習軟體製程的團隊，要怎麼把RUP及相關的Rational的開發工具用於某個非常小而簡單的專案上時，我會與他們分享我的這十項輕薄短小的本質，而避免用RUP的所有細節、和Rational整套工具的『強大能量』，把這個專案團隊淹沒。 其實，這十項本質根本可以不用什麼自動化工具來實現，一本筆記本，每項本質用個一小節的篇幅來描述，就管理小型專案而言，已經算是很好的開頭了。（而且我還發現，像『立即貼』這種小玩意，對於小型專案在管理、排定優先順序、以及追蹤需求的變動上，還真是有用！） 成長中的專案 當然，隨著專案的規模跟複雜度與日俱增，很快的，上述那種簡單的方法就會變得難以管理，此時對於自動化工具的需求也就變得較為明顯。但是，我還是鼓勵專案領導者先從這十項本質和RUP的某些最佳實務開始，然後依需求逐步增加工具的使用，而不是馬上就嘗試全面的使用整套的Rational工具。 成熟的專案 對於本身已經有在使用軟體製程和相關工具的較成熟團隊而言，這十項需求可以有助於提供一種快速的方法，去評估製程中幾個關鍵點是否都平衡的考量到了，也有助於找出改進之處，並排定其先後的改進順序。 所有的專案 當然，沒有任兩個專案是全然一樣的，而且似乎也不是每個專案都真的需要把這十項本質都用上，但在這種狀況下，去考慮如果忽略了某項本質會導致何種後果，卻也很重要。比方說，如果專案： 沒有願景：那你可能就會不知道專案要駛向何方，而且也會多走一堆無意義的冤枉路。 沒有計劃：那你就無法追蹤進度。 沒有風險清單：那你的專案目前可能處於專注在錯誤議題的危險之中，而且從現在開始的五個月內，專案都可能被突如其來的地雷給毀掉。 沒有議題清單：對問題如果不能及時分析並解決，小的問題通常會演變成阻礙專案的大『石頭』。 沒有企業個案：那你就是在冒浪費時間跟金錢的風險，而最後資金可能用罄，專案也被迫取消。 沒有元件架構：當問題發生時，你可能無法掌控資料的存取、溝通、以及同步化等問題，另外，在系統的擴充（scaling）及效能上也可能出問題。 沒有產品雛形：你就無法有效的進行測試的動作，並讓客戶因此對產品失去信心。 沒有評估：你就不會知道你距離專案的時限、目標、預算還有多遠。 需求一直都沒變：你就無法評估如果改變的話，潛在的衝擊將有多大；無法在彼此競爭的需求項目上排定先後順序；無法在變動了之後調整整個團隊（的方向）。 沒有支援使用者：那使用者就無法把你的產品發揮到最大的效益，而且你的技術支援部門將被蜂擁而至的求助需求給淹沒。 好啦，我都告訴你這些軟體製程中最根本的東西了，沒有這些心態，開發軟體時可能會很危險。我鼓勵你把這些東西當作一個起頭，並自己決定哪些要加、哪些想改、哪些又想丟掉。最後，不管專案的規模是大還是小，為了能夠準時交貨、不超出預算、並滿足專案關係人真正的需求，你或有必要再加上自己的『本質』清單。 其它的本質 有些組織也發表了一些類似的本質清單，《IEEE Software》雜誌的1997年三/四月號，有刊載一篇由Steve McConnell（譯註八）寫的”軟體開發的十項本質”（Software's Ten Essentials）。軟體專案經理人網路（The Software Project Manager's Network）也在www.spmn.com列了一份”十六項最重要的軟體開發實務”（16 Critical Software Practices）的清單。而軟體工程協會（Software Engineering Institute，SEI）的『能力成熟度模式』（Capability Maturity Model，CMM）包含了軟體製程的幾項關鍵領域（Key Process Areas，KPAs），或許也可以視之為軟體開發的『本質』吧。（請參見www.sei.cmu.edu） [原注] 如果想探究這『十項本質』清單的完整分析，請參閱《Mountaineering: The Freedom of the Hills》一書的第六版，第35至41頁，1997年，Mountaineers of Seattle出版。 引述自Johnson Space Center Shuttle Software Group，”They Write the Right Stuff”，Charles Fishman撰稿，Fast Company，Issue 6，第95頁，1996年12月。 [譯註] 製程架構的概念，《Succeeding with Objects》這本書探討的很詳盡。請注意『架構』一詞的抽象意義。其實，RUP也說自己是一個『製程架構』，而非一套要求IT人員非怎麼幹不可的『固定』製程。它可以針對不同的大環境或需求，因地制宜的調適一番。就像是interface/class只規範出架構，object或subclass當然可以稍事調整一樣，軟體製程所規範的，也只是原則、大架構而已。以此觀之，任何我們看到的軟體製程，都應以process model視之。 管理學之父彼得杜拉克對企業要問的的五大問題，第一個就是：『我們的業務是什麼？它應該是什麼？』 非功能性需求，我看過一位中國大陸學者的解讀，他認為是『性能』，我覺得翻得很棒，因為這些需求都強調什麼性什麼性的，例如『穩定性』、『快速性』、『易用性（上手性）』、『可維護性』、『可測試性』、『可追蹤性』...等『定性』需求，但雖是定性需求，也一樣有『定量』的評量方式，例如穩定性就可以要求『一年當機次數不得超過3次』來評量其是否達成。 還記得嗎？RUP有四個開發階段（phase）。 『開發週期』跟『開發循環』指的都是iteration，我會交互使用。 請參見RUP的4+1 view。觀察或理解一套軟體，可以從很多角度切入，UML中的九種diagram，正是同一套系統的不同構面，它們說的基本上是同一件事。系統分析師如果可以用某幾個觀點（或diagram，不管是否為UML）就讓所有專案關係人了解系統的話，那並不需要『每種diagram都畫出來』。圖，是用來幫助理解，不是用來增加理解負擔或阻礙理解的。 溝通的技巧，如同叫用到他人心中適切的method或procedure一樣，都可以喚起你想要的答案。這種技巧在軟體工業這種純腦力重人際的領域中，值得我們對它付出至少跟開發工具等同的熱情和關心。有時，可能說對或問對了一句話，就能比任何『先進的』CASE Tool，更能大幅而驚人的提高前段製程的生產力。 就是那位寫了好幾本軟體工程好書的人士，其中還有一本獲得Software Development雜誌所頒的JOLT獎，那些書由微軟出版社出版，國內的華彩出版社有出中譯本。 本文轉載自Rational Edge網站：The Ten Essentials of RUP，http://www.therationaledge.com/content/dec_00/f_rup.html ，著作權歸屬於Rational Software公司（www.rational.com）。 本篇文章感謝李潛瑞先生協助編譯、整理。 Levin誕生篇... ============== 程式不是寫來玩的 而是要有價值

------
林壽山
網站: http://superlevin.ifengyuan.tw
mail: superlevin@gmail.com