獨孤木專欄之三＞ UML, OOAD and RUP （上）-ZT

 

獨孤木專欄之三＞ UML, OOAD and RUP （上）

如果你沒聽過UML，容我在此做個解釋。這三個字就是U Must Learn的縮寫，指的就是你一定得學(you must learn)，如果有下一句，應該是You Must Pay。這是幾個大師級的人物，爲了要把學術理論順利轉化成現金，所想出來的好點子。基本的想法是，如果可以弄出一套理論，讓全世界想要學軟件開發的人都得要來學習，那他們光賣這套理論的教育訓練、認證、顧問諮詢、以及難用的開發工具，就可以讓公司上市，變成億萬富翁。

開玩笑的。

這是三位對象導向軟件工程界的大師(Grady Booch, James Rumbaugh, Ivar Jacobson)，爲了濟世救人所整合出來的一種模型語言，稱爲Unified Modeling Language。算是把三個人的東西，切成小塊以後煮一煮，放在碗裏面用湯匙攪一攪，整合成一個大雜燴…嗯，不是，是把三個人的理論去蕪存菁，所整理出來的結果。

UML主要的目的，在於讓所有進行系統分析設計的工程師，可以有一個共同的圖形化語言，來描述他們所想要建立的系統。至於讓公司上市，以及讓所有學習UML的工程師，可以有比較顯赫的履歷表，則算是產品附加價值，不算是主要的目的。

因爲這個語言，現在正流行，算是當紅炸子雞，所以許多軟件公司，莫不努力地往這個方向發展，期望引進UML，可以爲軟件開發，帶來前所未有的助益。很多人的想法，當然還是圍繞着可以做出被重複使用(reuse)的軟件組件，以加速系統開發爲核心。

吉娜：布魯斯，老闆問我什麼是UML？他說他到研討會裏聽到，超人公司已經在採用這個東西了，聽說有非常好的成果。他覺得我們所有的工程師也應該學習這種新的skill，這到底是什麼東西？

布魯斯：這是幾個對象導向分析設計界的大師，所共同建立的新的Modeling Language。

吉娜：Modeling language是什麼東西？算了，我不需要知道這些detail。既然老闆已經說需要引進這種新的趨勢，這就是我們今年的目標。你先找一些人去上課，然後回來我們拿幾個項目開始試試這種新的方法。

既然這只是一種語言，其實並沒有好壞的問題。這就像中文是否比英文優秀一樣，每個人會有不同的看法。只要在使用的時候，它可以發揮它的用處，可以讓看到文件的每個人，都很清楚瞭解你想描述的模型，我覺得它就發揮了這個模型的功用。

然而大師或是大師的徒子徒孫們，不會光把UML這三個字從頭到尾念一遍就了事，他們除了介紹這個語言，還會講其它的理論。這些話，就跟着UML的推廣，跟着被信衆們奉爲圭臬，當作是神諭。例如引進UML的團隊，通常會採用Use Case Driven的OOAD(對象導向分析設計)，也通常會想要採用大師建議的開發流程：RUP(Rational Unified Process)，來開發項目。

對很多老闆來說，這些東西就跟用來殺狼人的純銀子彈一樣，可以讓專案所面臨的所有問題都順利解決。所以每次聽到一個比較新潮的理論，就會想要叫屬下用用這麼神奇的理論。而這些東西看起來是這麼的有連貫性，從OOA開始進行需求分析，到使用OOD進行系統設計，接着再用OOP來開發程序，在開發過程中，都依循RUP的規範，再使用共同的UML語言。只有依照這樣完美的方法，纔可以確保整個項目的品質，並且開發出可以被重複使用的軟件組件。

老闆的思考的確比較單純，然而不少信徒也吃這一套，於是乎根本就不管三七二十一，直接就狠狠地給他用在項目上，絲毫沒有考慮中國社會的特色，應該要先想想師夷之長技以制夷，要儘量中學爲體，西學爲用纔對啊。結果當然是撞的滿頭包。

還好對於信徒來說，通常他們還可以自我安慰：『美國這麼先進的國家都採用這麼新穎的方法來開發，跟着世界趨勢走，一定不會錯。現在的問題，一定是因爲我們的人資質太過魯鈍，沒有完全依照大師的指示來做。下一次，我們一定要按照大師精闢的理論來開發，一定不會遇到什麼問題。』

然後這些信衆們，就會繼續抱着衆人皆醉我獨醒的悲壯，繼續努力下去。一邊做的時候，一邊爲自己又累積一些OOAD的開發經驗而自豪。

當然，我個人也覺得，大師一定不會錯，一定是我們資質比較魯鈍，又缺乏經驗，所以沒有正確地體悟大師的講法以及採取正確的做法，纔會導致這樣的結果。只是除了我們比較笨以外，總也要找一些理由，把責任推給大師們，不然鐵定會被客戶砍頭。大師既然要濟世救人，就只好請你們抱持着我不入地獄，誰入地獄的決心囉。

所以我會針對我觀察到的幾個因爲採用OOAD，以及RUP在臺灣做案子所發生的幾個問題，提出我個人的看法。幾個我觀察到的主要問題如下：

-沒有依據項目的特性來選擇項目開發方式。

-使用者或者是客戶的信息人員，看不懂相關的文件。

-信息人員本身不瞭解UML, OOAD以及RUP。

-Relational Database

以下我會針對這些問題，進行我個人的看法。

沒有依據項目的特性來選擇項目開發方式

臺灣的軟件項目，通常規模都不是很大，除非你將人力外包給企業使用，否則一般的軟件項目，價格則多半是在一開始就定下來了，項目進行的過程裏，通常沒什麼機會可以調整金額。

項目成員人數，多半在二十人以下。所以如果你要採用RUP來開發項目，你的第一個問題會是，你湊不到足夠的人頭，來擔任每一個RUP所介紹的角色。

此外，你通常也沒有那樣的預算，可以讓每個角色，都把他們該做的文件都做出來。所以你會省略一些流程。每次有人跑RUP跑的不順，他們第一個想法就是：『RUP的體系博大精深，這是多少前人智能的結晶，一定是因爲我省略了XX步驟，這次纔會走的不順利，下回一定要…』

RUP的另一個問題是，它是iterative的開發方式，也就是說，因爲項目一定會有變更需求發生，所以它預期沒有辦法一次就開發出使用者所要的東西。因此在開發時，會重複來個好幾回。每次都會要求使用者提出評估。

這怎麼會是個問題呢？實時取得使用者的響應是一件功德無量的事情啊。問題在於臺灣的使用者通常都有正職在身，他們多半是利用農閒時進行專案的開發。所以他們的時間非常寶貴，有機會跟你談一次需求，他就認爲這是非常大的恩惠。

在臺灣，進行使用者需求訪談，就像在火車站把一個要趕着去搭車的人攔下來進行問卷調查差不多。一開始，他可能還會基於禮貌，填寫問卷。當他需要第四次還是第五次回答同一張問卷的話，他會覺得你是否聽不懂人類所說的語言，還是存心找他麻煩。如果你開發一個系統，得要使用者評估個好幾回的話，God bless you。

就算使用者對你十分仁慈，沒有把你轟出去，採用iterative的做法會有的另外一個問題，其實是在於你的系統是一個iteration，一個iteration慢慢調整，逐漸形成的。所以到底什麼算是在系統的範圍(scope)裏面，其實很難界定。所以如果使用者覺得這個iteration的成品，與他原始需求還有距離，你大概都會被迫再多幾個iteration。而這幾個iteration，是收不到錢的。這跟以前的所謂螺線型的開發方式，在臺灣遇到的困難是一樣的。客戶不會因爲你多做了幾個循環(cycle)，而多給你錢。然而，你會因爲多做了幾個cycle，投入超出預期的人力與時間。

事情多做了，可是賺不到錢，這怎麼划算呢？要知道，開發項目跟開發產品是不同的。開發項目，就是要在最少的資源之下，提供給客戶一個可以接受的爛貨。可以花100萬就讓客戶願意結案，絕對不要花101萬，讓客戶擁有一個比較好用的系統。越好用的東西越難做，出槌的機率也越高，爲什麼要這樣做呢？

除非今天客戶是人力外包，花錢買你的人月，去幫他開發。這個時候，當然是儘量選擇可以做得長長久久的方式來開發囉。

所以我覺得應該要以項目的特性來選擇項目開發方式。大部分的項目，應該用傳統的軟件生命週期開發方式來開發。  (待續)