還少一本書：The Unified Software Development Process

Feb. 22 22:41~ Feb. 23 00:16

昨天介紹了對於了解與實做 CMMI 有助益的 Managing the Software Process 這本書，今天就順便介紹一下 The Unified Software Development Process 這一本。本書的作者也是鼎鼎大名的三巨頭 Ivar Jacobson, Grady Booch, James Rumbaugh。如果說昨天介紹的 Watts S. Humphrey 博士是 CMMI 之父，那麼今天介紹這三位 (Jacobson, Booch, Rumbaugh) 可以說是 UML 之父了。

這邊先澄清一個觀念，就好像常常有人會說：『我們團隊使用 CMMI 流程來開發軟體』這種錯誤觀念（CMMI 並不是一種開發流程，原因請參考昨天內容），也常常會聽到有人說『我們使用 UML 來分析軟體專案』或是『我們使用 UML 來開發軟體』這樣的錯誤說法。哪裡錯了？

• UML 的全名是 Unified Modeling Language，這邊偷用一下 wikipedia 的解釋 『UML includes a set of graphic notation techniques to create visual models of software-intensive systems.』所以常常有人說 UML 『只是』一種『畫圖（講好聽一點就叫做 visual modeling）』的表示法而已。了解這一些標準的『畫圖表示法』，例如 Class diagram, Sequence diagram, Activity diagram, Use case diagram 等等，並不能說你就知道要如何『分析』軟體。就好比知道各種幾何圖形並不表示你知道要如何畫出一幅好的圖畫一樣。這是兩件事情。
• 你可以用 UML 來表達軟體設計，但是你不能用 UML 來『開發軟體』。你可能會不服氣的說，可以啊，書上有說，UML 圖畫好之後按下『Code Generation』就把程式自動產生好了，還可以選要產生 Java, C# 或是 VB.NET 各種不同的語言喔，連一行程式都不用。也許有一天大家真的可以用這種方式來『開發軟體』，但不是今天。

明明是要介紹 Unified Software Development Process (簡稱 Unified Process, UP) 為什麼 Teddy 又扯到 UML... 因為 UP 和 UML 的作者都是同一批人，而且在看 UP 書籍或相關資料的時候，又經常看到一堆有的沒的 UML diagrams ，所以鄉民們很容易就會 UP, UML 傻傻分不清楚。

再幫鄉民們問一個問題，那沒事幹麼學 UP，不是用 SCRUM 或 XP 這種 agile methods 就好了？答案也很簡單：

• 現實世界中，專案的大小，型態各異，多了解幾種軟體開發流程可以讓自己面對到不同的專案時，有多一點的選擇。就好像一個 programmers 不可能只會一種 programming language 一樣。就算你覺的 Java 是全世界最棒的語言，如果你真的傻傻的一輩子就只會 Java，那是很危險滴。
• 和別人（『兵』）吵架的時候，多知道一點東西比較不會被唬的一愣一愣的。有人說『知識就是力量』，Teddy 說，『知識就是吵架本（吵架的本錢）』。

***

Teddy 的部落格都是『當天現撈的』，常常一不小心寫太晚搞得 Teddy 晚上失眠。接下來以大易輸入法的方式快速介紹一下本書重點。

UP 的三大支柱：

• Use-Case Driven：這一點其實很有趣，如果了解 Scrum 的人把 Use-Case Driven 換成 Story Driven 這樣就可以了解這一點的含意。在 Scrum 中，軟體開發流程是在每一個 sprint 中挑選若干個 story 來開發，最後在第  N 個 sprint 的時候把軟體做完。所以我們也可以說 Scrum 是 story driven (story 『驅動』著 Scrum 流程的每一項活動)。在 UP 中，這樣的精神是很類似的，只是 UP 用來紀錄需求的單位是一個 Use Case。
• Architecture-Centric：這一條解釋起來比較難一點，大體的精神是在軟體開發的『較早階段』，利用先『實做』最重要 5%～10% Use Cases 的機會建構起 software architecture 的『雛型』。日後隨著越來越多的 Use Cases 的內容被釐清與實做，這個 architecture 逐漸『轉大人 成熟』。
• Iterative and Incremental：這一點就比較沒什麼好解釋，UP 和現代主流的軟體開發流程一樣，都是支援 IID 的流程 (Iterative and Incremental Development Process)。

其實這本書的重點 Teddy 已經講完了，了解這三點之後，是很有幫助的。有時候 Teddy 甚至懷疑自己在採行 Scrum 的時候都有被 UP 『附身』而渾然不知的情況。鄉民們仔細想一下，想不起來的 Teddy 再幫各位複習一下，其實 Scrum 這個框架可以很簡單的用下面幾點表示：

• Role：Product Owner, Scrum Master, Team (Developer)
• Activity：Sprint Planning Meeting, Daily Scrum, Sprint Review Meeting, Retrospective Meeting
• Artifact：Story, Sprint Backlog, Sprint Backlog, Task Board, Release Plan

那... 對於要如何『開發軟體（分析，設計，實做，測試，佈署...etc）』Scrum 是沒有規範的。往好的方面來講這樣是『很有彈性』，從壞的方面來講這樣是『太有彈性以至於不知道要怎麼進行』（怎麼評價端看你是汎藍還是汎綠的...XD）。所以，無論是採用哪種流程，基本的『分析與設計能力』還是要有的。不管你使用傳統的『結構化分析與設計』或是目前主流的『物件導向分析與設計』，在不同的流程中都是必備的技能。關於這些分析與設計的技巧，在 Scrum 是不管你的（Scrum 內心獨白：給你彈性啊），在 UP 中就提的比較多。所以，這本書介紹完 Use-Case Driven， Architecture-Centric，Iterative and Incremental 這三個觀念之後，緊接著就介紹 UP 所謂的『core workflows』：

• Requirements Capture
• Capturing the Requirements as Use Cases
• Analysis
• Design
• Implementation
• Test

鄉民可以把這些介紹 『core workflows』的章節當作學習某種『分析與設計方法』。說真的雖然當年 Teddy 為了考資格考不得已將這些『core workflows』很認真的讀了好幾遍，但是到現在早就忘的差不多了。耶，Teddy 還是活的好好地，所以應該.... 沒看也沒關係。Teddy 覺的這本書介紹的 『core workflows』 過於『正規』了一點，光是為了搞懂這些『表示方法』所花的時間與在實做上所帶來的真正好處相比，C/P 值似乎太低了一點。如果要學分析設計方法，還不如直接去看 Crain Larman 的 Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development 這本書就好了（書名還真是長）。

像是書中介紹 Use Case Realization 這個概念，Teddy 曾經聽說有公司在面試工程師的時候還拿來當考題...說真的，現在 Teddy 也答不上來。不過再強調一次，Use-Case Driven， Architecture-Centric，Iterative and Incremental 這三句話一定要熟記，非常有用的觀念。Teddy 在採用 Scrum 開發專案的時候，其實內心裡一直默背這三句『口訣』，尤其是 Architecture-Centric 的精神如果可以掌握，對於避免『不要因為採用逐步成長的開發流程就讓軟體長壞掉』這件事佔有重要的地位（當然 refactoring 與自動化測試也是必須的）。

***

友藏內心獨白：不要以為 Teddy 只會  Scrum 喔... 啊，還是寫太晚了。