Kenmingの鮮思維

現代越形複雜資訊系統的開發，尤以要應付快速變動性的議題，幾乎所有的主流開發流程，包括 UP (Unified Process), XP (eXtreme Programming), Agile 等不論重、輕量型的流程方法論，均一致強調反覆 (Iteration) 與 漸增 (Incremental) 開發的必要性。 關於反覆式與傳統瀑布式 (WaterFall) 開發的比較說明，請參考先前我寫過的一篇：「從軟體架構師(Architect)的觀點來看軟體開發流程」。

I&I (Iteration and Incremental) 的開發模式，已逐漸成為軟體開發的最佳實務 (Best Practice)。 但是， I&I 開發模式的實踐與否，只有在軟體開發團隊的內部才知道；對於客戶單位，他們是不知道，也不可能瞭解委外軟體廠商，內部是運用什麼樣的開發模式。

所以，外包的委外軟體開發專案，若是使用 Iteartion 的開發模式，該如何計價收費？ 或者，某大型公司的 IT 單位，規範了外包軟體廠商，必然要遵循該公司所制定的開發流程綱要。 這兩個可以說都是相當奇怪、卻也常見的問題與現象。

我先說明第二個那個怪現象‧‧‧

IT 單位規範外包廠商的開發模式，一點意義都沒有。 因為，客戶根本看不到委外廠商內部是如何開發的。 即使你強調希望委外單位能走 I&I 的模式，但是，他要掛羊頭賣狗肉，你也沒轍，因為，從最終產出 (Artifacts)來說，你根本無法知道委外單位是採取何種開發模式來完成的。 客戶單位只能要求說，委外單位要能在毎一個議定的階段時間，要能達成分次交付的產出甚或可以早些釋出 (release)、可以完整被執行的功能案例。

客戶單位所制定每一個該付交產出的階段時間，這個應該是稱之為 "Milestone (里程碑)"，完成每一個階段的交付，也可以及早瞭解委外單位的釋出品質，或作為下一次交付的回饋 (Feedback)：而若是要求儘早能看到可被執行的部分功能案例(或模組)，這稱之為 "及早釋出(Early Release)"。

再回來討論第一個問題，採用 "Iteration" 開發模式該如何計價？

繼續閱讀 »

上個月我在「工研院」授課時，其中一位較為資深的程式開發人員問的問題： 我感覺不到寫好使用案例 (Use Case) 有什麼好處？

別誤會，這位年輕的開發人員並沒有惡意，我也認識他一陣子了。他的確是有感而發，覺得在工作上，從以前透過一般的需求規格書，到現在開發時導入 使用案例 的分析需求技術，但是，他並沒有感受到因為這樣而有加快程式撰寫的速度，反而還覺得縛手綁腳，經常需要受到規範。

這個問題，可比想像得還難以回答。 是為了可以有效保存需求分析的資產？ 還是為了系統的彈性 (flexibility)？ 前者似乎有道理，但如此對現在正進行的開發專案好像沒有說服力，甚至開發人員還覺得為了要補足這些需求文件，反而拖累了開發的速度；後者的系統彈性問題，我則是很確定與寫得好需求分析文件沒什麼直接的關係，彈性度的考量，與軟體的結構設計 (structure desgin)才是更主要的關鍵。

思考許久，我是以為，寫的好使用案例最直接的關鍵是： 影響到專案開發整個流程的節奏！

以使用案例為導向 (use case driven)的開發模式，我的體會是越來越能感受到那個所謂的 "driven" 這個字眼。 短線專案的特性，幾乎是偏以需求為優先。而使用案例的分析，其本質上仍是屬於功能 (functional)性的分析。只是有別於模組化的功能樹分析模式，後者的功能模組，耦合性 (coupling) 太重，容易牽一髮而動全身，所以在需求分析階段，會耗費許多時間在分析共用模組的考量；而使用案例，是一種目標導向 (goal-oriented)的功能分析方式。 每一個使用案例，都可以看待成是系統在某一段期間 (session)，可以滿足使用者使用系統的目的。 所以每一個使用案例，是可以個別被獨立開發，也就是說，UC-A 與 UC-B 甚至可以交付給不同團隊並行開發。而至於兩者若有共用性的議題的考量，則是延宕到結構設計階段再來討論即可。因為在需求分析階段，不用花太多時間在共用議題的考量上，所以可以很快速地實現 (realize)功能需求。

能抓得好與定義得好一個一個的橢圓使用案例，就能以該使用案例為開發單位。 這麼說好了，甚至可以把該使用案例就當成是一個迷你系統，然後來串連出整個開發的程序與產出。 例如，針對一個使用案例，就會設計一個位於中間層 (middleware)的控制型物件 (control object)，並從使用案例的敘述 (use case description)中，找出該物件應承擔的行為 (behavior)，然後再轉化成更詳細規格、程式語言的方法 (method)。 定義好控制物件與其應有的行為，就可以知道需求分析是容易並可以無縫式地轉移到實做階段，並快速地界定出程式碼的骨架 (sketletion)，再來就是補足細節、實做邏輯、連結資料庫或外部系統 等等…。

繼續閱讀 »

近日有位來自大陸對岸，就讀軟體工程的同學 Email 來信問了我關於需求獲取的問題。 很難得，並不算是問我 How-to 的問題，而我也覺得他問的問題還挺有意思的，所以也把我個人對其的回覆公佈分享出來。

2009/3/24 cnlogn

王克明老師，您好。
　　我是一個初學軟件工程的學生，正學到需求獲取。因為仰慕佛教的無遮大會的問答機制，又無意間撞到濛濛的秘密基地，發現了前輩（有緣分），於是冒昧請教。
　　我知道需求信息來源，獲取方法/技術。那麼什麼是需求獲取策略？
　　我知道需求三個層次分別是業務需求，用戶需求和功能需求（非功能需求）。那麼什麼是客戶需求？什麼是產品需求？
　　為什麼把領域分析和業務建模放在需求獲取階段？此致
敬禮

2009-03-24

Cnlogn 同學您好：

1. 與其說需求獲取的方法/技術 是一種策略(strategy)，倒不如說是一種態度。 什麼態度呢？ 因為知道不可能一次就能很明確地從使用者端得到正確詳細的需求，所以，需求分析師 (Requirement Analyst, RA)不會也不應該一開始就想要得到所謂正確的需求，而會是以漸增、漸進的方式 (Iteration and Incremental)，從一個所謂的功能單位(例如 Use Case)，逐步地從目標框架，往精確度要求。 所以這是一種目標導向的作法，先確立目標，再來往細節調整。
2. 我覺得是不應該去硬背那個什麼三個層次的需求。應該是說，需求會透過多種不同的角度，理解與紀錄各個不同使用者角色的需求。 包括整體性的業務流程面、包括操作員 (Operator)對系統的局部功能要求、包括整體使用者對系統關於穩定、效能、彈性等非功能性的滿意度需求… 等等。 需求的面向 (View)是很多面的，RA 要能擅長透過多種不同的觀點來看待需求面。
3. 我不會硬性定義所謂的領域分析與業務建模是放在需求獲取階段。 關於分析、設計、乃至實做測試等工作，會是快速跑過一整個循環 (Iteration)，再取得回饋 (feedback)來持續修正調整的。 軟體工程把製程 (Process)固定下來的前提是需求穩定不變，問題是，軟體又不同於其它成熟產業領域的關鍵就在於，需求一直持續地變化。

我曾經寫過一篇：「從軟體架構師(Architect)的觀點來看軟體開發流程」，您可參考看看的。

Best Regards.
Kenming.

副標題：敏捷的開發首重的是人與人的共同合作、自我組織良好的團隊。人不是如同組成系統的元件，可以隨意被抽換的。

敏捷軟體開發：原則、樣式及實務 Agile Software Development: Principles, Patterns, and Practices ———————————– 作者／Robert C.Martin /著, 林昆穎、吳京子 /譯 出版社／碁峰 ISBN／986-154-148-9 Amazon 評鑑：五顆星

內容簡介
暢銷書作者及舉世聞名的軟體開發專家Robert C. Martin展示了當今軟體開發者、專案經理與軟體專案領導者如何解決眼前最具挑戰性的難題。這是既全面又實用的敏捷開發與極致編程的教學，由敏捷開發創始人之一所撰寫。教導軟體開發者和專案經理如何使用敏捷開發的威力，讓軟體專案如期完成又能符合預算。

* 使用真實的個案研究來展示如何運用極致編程進行規劃、測試、重整、以及搭檔編程。
* 包括豐富而可復用的C++和JavaTM程式碼。
* 專注於使用統一建模語言（UML）與設計樣式（Design Patterns）來解決以客戶為導向的系統問題。

前言

本書原著在 Amazon 評鑑是極為罕見的五顆星滿分！ 書籍也是少見的厚，有近 700 頁之多。 如此深厚的內容，可不像坊間一堆可拿來當枕頭的所謂 OOP 入門書一般，盡是充斥著圖形設定教學與程式碼，沒啥內容。 套一句 John Vissides (Design Patterns 之一作者)在引言上所推薦的：「這也許是第一本將敏捷方法 (agile methods)、樣式 (patterns)，以及現代軟體開發方法交織成連貫的整體。當 Bob Martin 開口，你最好洗耳恭聽。」 六年！ 是作者在這麼多年來所深刻體會到的軟體設計和開發經驗，而本書也可說是反應了作者自身的學習成果。

本書描述了軟體開發議程的三個主題：設計原則 (principle)、設計樣式(pattern)，與開發實務(practice)。當軟體開發人員面對的是需求快速變動時，如何具備迅速的應變能力，而表現在開發的過程中，即為敏捷性的開發；為了達成敏捷性，所以開發團隊要能有某種程度的共識以及具回饋 (feedback)的實務作法；利用專家與前人所提供的設計原則，使得軟體能具有彈性與易於維護；而如何平衡這些設計原則，所以也會瞭解到在特定一再重覆的問題上應用設計樣式。作者就是嘗試著要把這三種觀念成有一個有效的整體。 我覺得書中最大的特色就是，會藉由許多案例研究來說明與示範如何應用上述三種觀念，而且這些案例並非是最終的完成品而已，而是正在進行中的開發，所以讀者也會看到這些設計者所犯下的錯誤，然後他們又如何發現錯誤，進而改正錯誤。

軟體開發的關鍵在於人，而不是製程

本書的目錄綱要編排，正是反映了上述作者想傳達的三種觀念，所以分為六個篇幅，第一、二篇論及的是軟體開發流程的最佳實務與能符合最佳實務的敏捷設計原則；後四篇則是藉三個案例研討 (薪資、氣象臺、教育測驗服務)，如何應用設計樣式，來解決一些特定的實務問題。再來就是四個附錄。前兩個附錄算是對於 UML 的語法說明；而附錄C (兩家公司的諷斥)，挺特別的寫作方式，每一頁是個別描述兩家公司各自不同的開發方式，一個採需求凍結的瀑布開發、另一個採敏捷的反覆漸增開發。是一篇挺有趣的寓言式寫實故事；附錄D則是摘錄 Jack Reeves 的一篇論文：「原始碼即設計」。我覺得該篇論文真的可以精讀，可以引導與觸發讀者思考，什麼叫做軟體設計。

每一大篇，都可以各自拆開獨立閱讀。軟體開發人員，若想對樣式作個一般性的學習，可以閱讀敏捷的設計原則；而想知道作者是如何應用書中所介紹的設計樣式，則可以參考書內的三個案例研討；而若是專案經理甚或老闆，專心研讀第一篇關於敏捷式的開發流程，絕對會對現實的專案開發與管理的議題上，有很多的體會與啟發。

尤其一開始本書所揭露出來的敏捷軟體開發宣言，我覺得是相當務實地揭露出軟體開發的本質— 流程和技術是影響專案結構的次要原因，人方是關鍵要素。 太多老闆與專案經理們總是常會把他們總是很關心人的永續成長之類的話掛在嘴邊，但是又往往想要創造或導入出一套流程，藉由許多管理工具與各階段的製程產品，用來約束開發人員的活動。而靠一些約束與產出(通常是大量的文件)，但錯誤仍持續不斷發生時，管理人員卻又在某些地方設定更多的約束和產出 …，這種造成負回饋的循環，使得軟體人員過度負荷了龐大笨重的流程，而嚴重妨礙了完成工作的能力，並因而喪失了軟體的創意設計能力。

奉勸許多老闆與專案經理們，不能再自欺欺人了，仔細審思敏捷宣言所揭露出來的價值觀吧：
o 個人及互動勝於流程與工具。
o 可用的軟體勝於詳盡的文件。
o 與客戶合作勝於合約談判。
o 回應變更更勝於墨守計畫。

敏捷開發的主張—程式碼即為設計本身？

本書在“敏捷式的設計”一篇中，所引用自附錄D Jack Reeves 所主張的：「真正能符合工程設計標準的唯一軟體文件就是源碼的列表”。本來我還以為敏捷開發的主張是將程式碼當作是設計的一切，這我當然是無法認同，這可是會給一些程式設計人員藉口，只寫程式卻不需要有其它的設計文件。 我是一直覺得，程式碼既是設計(沒錯)，但同時也是設計最現實有效的產出 (artifacts)。而程式碼的呈現是綜合了包括多個觀點與層面的設計，諸如需求、結構，甚或架構，而這些是需要透過其它如設計圖，突顯出設計的焦點而隱藏了程式碼不必要的細節。還好，後來我很用力地研讀並思考 Reeves 論文的意涵，他應該指的是，程式碼本身就是一種設計。是的，這一點我是相當認同的，還有就是千萬不要認為 “設計就是一組與程式碼分離開來的 UML 圖示。”這麼說好了，我是一直這麼認為： UML 設計圖與程式碼都是設計，是軟體系統的一體兩面。”所以，個人一直主張，設計圖要作少、作精，不要作不必要的文件，且必然要時刻在開發的過程中保持與程式碼的一致性。

對於開發人員而言，要能看得懂本書所介紹的設計樣式，那就要先瞭解本書所揭露的設計原則，書中介紹了五種設計原則—SRP, OCP, LSP, DIP, ISP 等，全名與細節我就略過不提了。其實這些就是所謂物件導向式軟體設計的基本功與思維，諸如物件的責任分派、封裝的設計、相依性的分析、多型與介面的設計等。還有，讀者要瞭解，這些設計原則不是為了協助你把東西做出來，而是讓你消除程式碼的壞味道，設計壞味是一種症狀，是某種可以被主觀而非客觀量測的東西，會讓系統僵化而難以維護。不過適可而止就好，設計原則並非可以在系統中任意地到處噴灑的香水，過度遵從原則會導致不必要的複雜度的設計壞味。

書本雖然厚，討論的主題涵蓋也廣，但是內容還蠻淺顯易懂的，翻譯的品質也是相當不錯。每一個章節前頭又有很棒很炫的插圖，甚至還有作者引以自豪，是其女兒散佈在各章節裝飾性插圖的可愛作品。還有若是像我不是那麼珍惜書本完整性的話，甚至也可以將各篇分開拆下來，這樣外出攜帶時閱讀就不會那麼厚重。 看到如此言之有物的專業書籍，又不難懂，可以說是生命的喜樂之一。

上上個星期，應國防某單位要求，希望由我們利用 EA(Enterprise Archiect) UML 工具，藉由一個案例，來展示在順應 DoDAF 規格下，如何從架構規劃、到依循每一個包括 Operation 與 System View 的設計圖，以及又該如何導出到實作，尤以後者，對他們很困擾，一直不知道該如何將 DoDAF 設計與實作順利地橋接在一起。

其實原來是上個月初過去介紹的是 EA 的 UML 工具，因為 EA 其中一個 Plugin 產品，稱為 MDG for DoDAF-MODAF，兩者的搭配，應用的是 UML Profile 機制，可以充分完整支援 DoDAF 1.5 的設計規格。 說真的，工具沒啥好介紹的，況且席間諸多長官與教授們問最多的問題就是有沒有 "自動化" 的機制，可以從某一個 View 的設計圖，自動轉化到另外一個 View 的設計圖。這個… 我總覺得他們研究的方向會不會有問題？ 我只能反問：1. 如果規則明確，例如 OV-2(作業節點連結) 轉 OV-5(作業活動流程)有很明確轉換規格的話，那麼工具當然可以支援。 (可想而知的答案是，當然沒有那種必然明確的規則) 2.能不能轉到程式碼？ 這些我都覺得都不是問題耶，前提是有沒有那種確定的規則？ 有趣的是，他們用來比較 EA UML 工具的是另一套 T牌、要價 100 萬的工具，也沒有支援他們 "心目中" 的自動化啊。 所以我開玩笑的說，好吧，把那個 T牌與 EA (EA+DoDAF Plugin 才 1萬初頭)的差價，用來委託我們開發那個自動化的 Transform 機制，保證可以幫你們生的出來，不過前提是要能給我們明確的轉換規則。

我可不會想賺工具的錢啦，要能懂得設計符合 DoDAF 架構規格的系統，要具備的是軟體設計基礎功夫的底子；要能有整體性的架構觀，要知道什麼時候該封裝、什麼時候該打開，分析系統的內部；要懂得如何把一個看起來好像很大的系統(關於系統的定義，可不一定指軟體系統，在這種大格局下，包括企業單位，都可能是一個系統)，該如何大題小作；又懂得那個時候該具焦在某一個焦點上，然後小題大作。 這一種整體性的設計思維，正是架構規劃與設計箇中的竅門之所在。

我想要傳達的是，我們可以協助國防某單位，如何具備能具有規劃 DoDAF 架構設計的技能(Skill)，與相關軟體設計的基礎功夫，以及所該具有的技術實作能力。當然就是以顧問輔導與教育訓練為主，如果可以的話，規劃成一個外包的專案更是好，然後從實作的過程中帶著學習，作中學的效果會更好的。 不過前提是，我們總是要能先證明我們懂得如何規劃這類超大格局符合 DoDAF 規格的系統，一般當然就是出個題目了，這一向是我個人最為意願的了，比較容易在短時間內取得雙方之間彼此的信賴與共識；也比較現實，會就會，不會的話早一點出局，最不囉唆了。 喔，還有，這是繼我十餘年前從志願役中尉預官退伍後，再一次能回到軍中，為國效勞的好機會呢，哈。

由於國防某單位最近忙了些，等了幾星期，還是沒拿出案例讓我們來演練，所以只好我們團隊內部自行構思一個與軍事相關的案例。 所以呢，這個案例是沒有與軍事任何單位有關連(正因如此，才能拿出來公開分享)，完全是充滿想像；也沒有軍事專家的協助，所以需求必然是謬誤百出。不過這也不是什麼困擾，因為我們要做的是如何能捕捉出 DoDAF 的架構規劃與橋接到實做階段的那個精髓之所在。只要未來能有軍事領域專家的協助，那麼就很容易可以調整修正，來符合正確的需求了。

整整花了四天的時間，投入了約 2.3 個人力，以一個我們所想像創造出來的案例，也算是規劃了一個類似 C4ISR(Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) 的聯合作戰指揮系統，透過偵測與防衛系統，發現到敵人即將進軍來襲時，是如何即時協同陸、海、空三軍暨後勤補給中心，來達成防衛作戰的目標。 包括了 Operation、System View 共約 17 張設計圖、再加上利用 .NET 程式碼來模擬諸多系統間的即時互動(透過 Web-Service)。 喔，甚至連那個表達 OV-1 的概念視圖，都還是請美工畫出來的呢，效果十足！ 老實說，個人對我們團隊能在如此短的時間內，就能規劃出如此大的架構格局，甚至還產出程式碼來驗證架構的完整性。藉此而能解開 DoDAF 這個算是軍中資訊人員們的 "潘朵拉密盒"，可說是成就感十足，也算頗引以為傲。

圖 1、 利用 EA-DoDAF 開發的 SV-1 設計圖

所完成的案例在上上星期至國防某單位的 Seminar 展示效果相當不錯！ 在座許多高級長官以及教授們在會後的許多問題透過我們的解說，也算能得到合理的解釋。也讓許多中、上尉的資訊官們，見識到我們是如何從某一些 View 再轉到微觀(Micro)的實做階段。 由於沒有軍事機密等的問題存在(案例全都是想像的)，所以到是可以藉由公開發表這一個案例，除了展示是如何實現 DoDAF 規格，並大概解釋一下每一個 View 的 精要(essential)設計意涵為何，同時也算是藉由此，來看看這種偏多個節點(Node)、多個資訊系統是如何做架構規劃的。

繼續閱讀 »

統一流程入門 第二版 — The Rational Unified Process An Introduction 2nd ———————————– 作者／Phillippe Kruchten/著 譯者／趙光正/譯 出版社／維科圖書有限公司 出版 ISBN／957-8675-79-8

內容簡介
這本書非常簡潔,裡面快速介紹Rational統一流程(Rational Unified Process ,RUP)的一些概念、結構、內容和動機。RUP是一個具備網際網路功能的軟體工程流程,它強化團隊的生產力並提供成員最好的軟體實務經驗。RUP非常特別,開發團隊可以透過它了解統一模型語言(Unified Modeling Language , UML)、軟體自動化和業界最佳實務經驗的所有優點。

Rational統一流程統一整個軟體開發團隊的工作,並且讓每位成員達到最高生產力,因為它為大家帶來了成千上萬個專業與頂尖業界領導者的經驗。想在可預期時程內、用合理預算、輕易完成為品質軟體嗎?快拿本書當作你的指導手冊吧!本書作者與你分享他最深層的流程相關知識,並且把焦點放在RUP的關鍵點,讓你很快就能專精RUP這個已被證實過、確實可行的軟體開發解決方案。

本書第二版主要根據最新版的Rational統一流程更新以符合最新內容。事實上,完整的RUP2000裡’還包括:
1.更多的e-開發指引
2.一份學習地圖,教你如何把流程應用到各式各樣的專案和技術上
3.擴充過的測試分析,現在它會橫跨整個產品生命週期
4.改良過的應用程式介面設計範園一特別針對如何開發有效的網際網路應用程式
5.針對及時與互動系統,提供更詳盡的說明
6.深入淺出介紹如何用樣式和框架來設計系統

Philippe Kruchten是Rational統一流程產品的首席架構設計師。他有超過25年的大型、軟體密集式系統開發經驗,這些系統的領域包括通訊、安全防禦、太空、交通和軟體開發工具。他並擁有Ecole Centralc de Lyon(法國)的機械工程學位和French Institute of Telecommunications的電腦科學博士學位。

前言

RUP (Rational Unified Process) 是由 IBM Rational 所研發並推廣的軟體開發流程。它是一套流程框架 (Process Framework)，可根據開發團隊的需求去調整或擴充，自訂的流程描述不外乎包括了四項元素：誰(Who)做了什麼(What)，如何做(How)和什麼時候(When)做；它也是一套產品，由 Rational 所研發和維護，並整合在該公司的 Rational Suite Enterprise 套裝軟體內。安裝好該光碟產品，便可以把這份產品當成 RUP 的虛擬電子教練 (e-coach)，它提供一個完整的超鏈結網頁，以 HTML 格式來描述流程，並附有各種格式的樣版(Template)，如 HTML、RTF、PDF…等，及一個簡單的 Case Study：Rational Project Web Example；而 RUP本身更是一種軟體工程流程(Software Engineering Process)，它提供研發單位一個嚴謹的方法，分配軟體開發工作和責任，目的是確保在可預期的時程和預算內，開發出符合使用者需求的高品質軟體。

本書不到 300 頁的內容，是將RUP 作一個整體介紹，算是一個縮影。作者是由 RUP 的首席架構師 Kruchten 所著，事實上，第一章是由軟體三巨頭之一的 Grady Booch 所撰寫的論文，是本書最有價值的地方；而第二至第六章則涵蓋了 RUP 的流程框架介紹，包括了靜態結構的流程描述與動態的流程行為說明。最能代表 RUP 的是一張看起來像是鯨魚的二維流程結構圖，水平軸代表時間和流程開始後的各個生命週期，也就是分為初始、詳述、建構、轉移等四個開發階段；以及垂直軸代表的是核心工作流程，也就是把活動按照本質加以分類的結果。諸如企業塑模、需求、分析與設計、實作等活動，也稱之為規程 (discipline)。七至十七章則是第二部分的工作流程介紹，是由 RUP 流程開發團隊的工程師們所撰寫的，諸如專案管理的工作流程、需求的工作流程等，包括了工作流程的目的、定義主要的概念、工作人員與工作成果、活動與輔助工具等。這一部份的內容看看參考就好，因為工作流程不外乎是談及什麼人在某個時間點做了什麼事 (產出)，以及如何串接等，每一個專案的開發都會是不一樣的，沒有必要也不可能採取統一制式的工作流程。

最佳的軟體開發實務經驗

Grady Booch 在第一章的論文中，揭露出軟體的價值何在，以及所衍生出在軟體開發時經常發生問題的症狀，諸如無法處理需求的變動、模組間無法配合、軟體很難維護與擴充、太慢發現專案的嚴重瑕疵 (Defect) …等。同時也提及了專案雖然有不同的失敗原因，但最主要的原因包括了：不精確的溝通方式、脆弱的架構 (Architecture)、很難處理的複雜性、不一致的需求、設計和實作、測試不足、沒有客服風險等。

從根本問題找解決方案，並應用在商業上證實可行並廣為業界的成功組織所採用的軟體開發方式，而成為 RUP 的關鍵性精髓，也可以說是軟體開發最佳的實務經驗 (Best Practices)，包括了：以反覆式 (Iterative)方式開發軟體、管理需求、以元件為基礎 (Component-based)的架構、以視覺化方式製作軟體模型 (Visually Model Software)、持續驗證軟體品質、控制軟體的改變。

當然，這些實務經驗可非一蹴可幾，是需要經過軟體組織持續不斷的學習與摸索，並建立紮實的本質素養方可的。舉個例，光是以元件為基礎的架構這一部份，要能瞭解什麼是元件，要如何適切地切割元件的大小，要如何定義出元件的介面，也可以說就是 Design for Interface，把善變的部分封裝在元件內部，這些可不是容易的事；再則以反覆式的開發方法，聽起來有道理，但做起來卻相當難執行，因為人們一般很難忍受不確定性，尤以專案經理時常抗拒這種開發方式，因為它看起來像是永無止境、無法控制的脫序行為。事實上，反覆式在 RUP 的規範中，是可以被控制的，每次反覆都是以編號、週期和目標妥善計畫。只是因為這一些會衍生出專案管理的其它議題，才使得專案管理人員喜歡循序的瀑布(Waterfall) 開發方法，每一個開發階段都定義了很明確的產出。問題是，我在前兩期介紹 XP 時，也曾提及了，軟體的根本問題在於風險。而瀑布式太晚把風險揭露出來，這在現今多變的需求開發中是早已證實不可行的。若反覆式是證實才能解決軟體開發的根本問題，那麼，無論過程遇到一些阻礙，還是應該堅持來達成。 ”Do the Right thing”後，才能“Do the thing Right”！

本書特別在第四章中，介紹了 RUP 的動態結構即為反覆式的開發方式。這也說明了一件事，那些把 RUP 當作僵化官僚的開發模式的軟體組織，實在沒有去用心體認 RUP 的關鍵精髓，擷取其成功的實務經驗，而只是把它拿來當作應付階層式組織各級主管的工具而已，因為很容易產出美美的文件，用它來交差應付。我在許多比較大型的組織中，的確看到很多這樣的現象，這麼多的軟體開發人才，卻一直在那裡空轉著，浪費太多不必要的資源，殊為可惜。

以架構為中心及使用案例驅動的開發流程

本書第五、六章，揭露出“4+1”的架構觀點，及以使用案例驅動 (Use case driven)的開發流程。架構可不容易被解釋與認知，RUP 是嘗試利用觀點 (View)來解釋架構，以讓軟體開發人員瞭解這些觀點的主要產出 (artifacts)，以及如何調和這些產出，並仍能維持有一致性的全貌與見解。

“4+1”共五個觀點，包括了邏輯觀點、實作觀點、程序觀點、配置觀點，還有一個擺在中間的使用案例觀點，利用它來驗證其它觀點，也可以就是利用需求功能來驗證各個階段的開發產出。每一個觀點都有相關角色的開發人員職掌，例如需求分析師會專注在使用案例觀點、結構分析/設計師會專注在邏輯觀點，而程式設計師當然就是著重在實作觀點了。

RUP 是強調“Use Case driven”，但卻不是 “Use Case First”的。兩者的差異在於前者是利用功能需求驗證架構的一致性、結構的彈性、以及實作的完整性等；而後者則是純然以需求作為涵蓋整個系統的建構，卻忽略了其它的觀點，而使得系統不具彈性、延展與可重用性等。國內短線的專案開發生態經常是如此，而導致軟體人員只重視需求的功能面與實作的技術面，卻忽略了軟體的主結構，也使得系統不具應變的特性了。

我為什麼要介紹 RUP？ 我不是輕量型 (lightweight)的敏捷式 (Agile)開發流程的擁護者嗎？ RUP 給一般軟體人員的印象是僵化、官僚、受控制的重型 (heavyweight)開發流程，事實上，我在熟讀本書之後，更確定了，RUP 的本質精髓與其它所謂敏捷式的開發流程根本就是一樣的，它們均強調反覆式的開發、需求導向、以及對測試的重視，只是作法 (how-to)不一樣而已。而 RUP 被視為是高度儀式化的重型開發製程，這也是被那些崇尚軟體工程的專案管理人員給濫用了，卻忽略了軟體也包括了心理學、哲學與藝術的成分存在，而不是只有工程學而已 [Kruchten 2002]。另外，要注意的是，UML 可以是國際標準，但是流程卻沒有所謂的標準，它充其量只是範本 (Template)、一種框架而已。這麼說好了，團隊開發成員之間可以講相同的語言(UML)，以利相互的溝通；但每個團隊要如何達成目標，則各有其方法與程序(Process)來達成任務。程序是“How-to”，每個團隊的“How-to” 是不會完全一樣的。