對這文章發表回應
發表限制: 非會員 可以發表
發表者： 冷日 發表時間： 2008/3/19 7:56:07
| 軟體設計美學之道第6回──統一流程（Unified Process） |
| 為什麼需要流程？ 雖然之前的文章都在談論軟體美學，但是在這篇文章，讓我們暫時先丟開這個浪漫傳說，回頭來看看真實世界的軟體專案。公司接案的最大目的是什麼呢？當然就是要能賺錢，這也許很俗氣，不過卻是事實。 軟體開發的專案有四個重要的變數－成本、時間、品質及規模，如果以企業生存遊戲的角度來看，那成本一定是最難控制的變數，而品質是客戶堅持的，時間是客戶規定的，相對之下，只要能符合客戶的業務需求，最容易控制的，我想就是「規模」了。因此我們可以假設在品質及時間不變的情況之下，若受到規模衝擊的影響變小，則成本也會下降，而在成本越小的情況下，公司的獲利當然也就會越多了。 只要能積極地管理規模變數，團隊及客戶對於其他三個變數的控制能力也能增加。因為通常客戶不會太清楚他們要的是什麼東西，真正的規模到那裡，當然，這不是他們的錯，軟體的本質本來就是恆變的需求，而軟體專案的開發本來就常處於「一寸以前，才是光明的」的狀況，開發團隊必需要協助客戶，幫助客戶找到他們真正的需求，幫助他們釐清可能的風險，一寸一寸地走，一點一點地將整個光明都找出來。 當一個團隊千辛萬苦地將一個軟體專案完成後，最重要的事情除了收錢之外，還有什麼呢？答案是「累積與再利用」，如果你是老闆，你會不會希望看到下次在接到相似類型的專案時，開發團隊可以利用更少的時間完成專案呢？因此，如何讓團隊能夠在每個案子產生一個正向的回饋，讓下次同類型的專案可以減低規模的衝擊，進而減少成本，最後提高專案的利潤，是一個非常重要的課題，而軟體元件重用（Reuse）的技術也就呼之欲出了，這時，以Pattern為基礎，並且以軟體架構為中心的開發方式將是關鍵。這整個過程，勢必需要一個軟體開發流程來指揮協調。 各式軟體開發流程 最常見的軟體開發流程就是線性或「瀑布式」的舊式流程，當然還有相當有名的XP（Extreme Programming）以及我們要討論的UP（Unified Process）等等。 軟體開發的方法論有很多，各有其巧妙及適合的時機，端看開發團隊的能力、專案類型甚至是文化國情。筆者就曾在某大電信公司，遇過某個開發團隊所採用的是「課長流程」（就是以該單位主管心中的喜惡為主的「無定向」開發方式）！相信這在台灣也算是一種流行的開發流程吧。 「瀑布式」的舊式開發流程常見的做法依序是收集需求、系統分析、系統設計，最後根據設計結果來實作。這會衍生出一些職位如系統分析師（SA）、系統設計師（SD）以及「最底層」的程序員（Programmer），因此除了開發步驟的每一個階段是線性的走向之外，時常連開發工作也會依職位的高低而變成官僚作風。有時在同一開發團隊的SA甚至會做出和Programmer實作不同的需求文件，因為真正的需求及設計最後是靠SD，甚至是Programmer以及客戶的「提醒」才找出來的。如此的開發方式，不容易應付恆變需求的軟體專案，更不容易累積可再利用的軟體元件，而開發工作的責任及角色雖然和經驗累積有關，但並不全然和職位的線性關係劃上等號，因為每一種角色都有其專門的責任及技術深度。 UP精神 「統一流程（unified process）」對於「管理規模變數」以及「提高軟體元件的重用」有著不錯的影響，而針對線性流程無法確實掌握需求與實作關係的缺點，也有不錯的解決方式。我們暫時拋開在流程裏常會令人心煩的工作項目及開發階段，先體會一下UP精神，這將有助於UP的實作。 UP精神最主要圍繞在三個方向，分別是Use-Case-Driven、Architecture-Centric以及Iterative & Incremental。以下我先簡述其重要觀念，針對工作流程及項目的協調運作，將在下一篇的文章提及，而關於UP的詳細內容，筆者建議大家閱讀「The Unified Software Development Process」這本書。 所謂的Use Case「Driven」，就是指團隊在執行整個流程時，都是從Use Case開始所有的工作項目。這樣可以讓開發團隊在每次的工作循環裏，以聚焦在客戶的需求為出發點，避免迷失在專案的規模中。Use Case是大家用來發掘並記錄功能性需求的一種技術。換句話說，它的功用在於找出對使用系統的參與者有價值的需求，並且能產生有價值及看的到的結果；例如，買機票、處理退貨、結帳等等。而Use Case也可以幫助我們開發使用者介面，讓客戶清楚他們未來要如何使用系統來完成他們的工作，幫助客戶找出他們真正要的東西，也幫助大家控制「規模變數」。 Architecture-Centric的概念最容易被想要實行UP的開發團隊遺忘。通常大家只會注意到UP所定義出來繁複的工作項目，並拘泥在工作項目的意義及執行時間點，殊不知以軟體架構為中心的開發觀念是UP在執行物件導向專案的支柱。 軟體架構的功用及開發步驟在之前的幾篇文章之中已經提過了，在此我只再強調其對於「提高軟體元件的重用」及「提供穩定的開發基礎」有著重要的影響。在Use Case Driven的觀念下，Architecture的開發是以支撐Use Case需求為目的，而Architecture的建構則會影響到那些Use Case可以被實現。 Iterative & Incremental意謂著透過回饋與調整來擁抱改變。在軟體需求的恆變性之下，我們需要反覆式的開發，讓軟體可以在一連串的建構、回饋與調整的循環之中逐步完成，這是線性式的開發流程所欠缺的。而這種短期、固定時間長度以及小規模的開發循環之下，可以讓軟體開發的複雜性變小，我們也可以用Risk-Driven的觀念，先開發風險比較高的部份，讓早期的進展減緩風險可能帶來的衝擊。 大部份的人也許會覺得UP是一部很笨重的方法論，拿來做研究還不錯，但是對於用在實際的專案上，則是望之卻步。其實在了解UP的精神後，再找出自己團隊或者專案適合的開發活動與工作流程才是真正的關鍵。UP其實可以很敏捷，也可以很繁重，端看團隊真正的需求。 《作者簡介》葉政達 艾群科技研發中心技術經理，中原大學電子工程研究所碩士。曾任職於網際商擎科技、台聯電訊研發工程師等職，專精於OOAD、軟體架構設計、Pattern、J2EE、J2SE、行動運算應用；通過SCEA、SCWCD、SCJP等認證。曾參與電子商務系統、航空即時訂票系統、SNMP網路管理產品開發、亞太電信QMA Image Solution、Sandio Mobile Sync產品設計開發等專案規畫建置。 |