關鍵字：面向對象 結構化方法
對很多老板來說，這些東西就跟用來殺狼人的純銀子彈一樣，可以讓專案所面臨的所有.問題都順利解決。所以每次聽到一個比較新潮的理論，就會想要叫屬下用用這么神奇的.理論。而這些東西看起來是這么的有連貫性，從OOA開始進行需求分析，到使用OOD.進行系統設計，接著再用OOP來開發程序，在開發過程中，都依循RUP的規范，再使用.共同的UML語言。只有依照這樣完美的方法，才可以確保整個項目的品質，并且開發出.可以被重復使用的軟件組件。
老板的思考的確比較單純，然而不少信徒也吃這一套，于是乎根本就不管三七二十一，.直接就狠狠地給他用在項目上，絲毫沒有考慮中國社會的特色，應該要先想想師夷之長.技以制夷，要盡量中學為體，西學為用才對啊。結果當然是撞的滿頭包。
還好對于信徒來說，通常他們還可以自我安慰：『美國這么先進的國家都采用這么新穎.的方法來開發，跟著世界趨勢走，一定不會錯�，F在的問題，一定是因為我們的人資質.太過魯鈍，沒有完全依照大師的指示來做。下一次，我們一定要按照大師精辟的理論來.開發，一定不會遇到什么問題�！�
然后這些信眾們，就會繼續抱著眾人皆醉我獨醒的悲壯，繼續努力下去。一邊做的時候，.一邊為自己又累積一些OOAD的開發經驗而自豪。
當然，我個人也覺得，大師一定不會錯，一定是我們資質比較魯鈍，又缺乏經驗，所以.沒有正確地體悟大師的講法以及采取正確的做法，才會導致這樣的結果。只是除了我們.比較笨以外，總也要找一些理由，把責任推給大師們，不然鐵定會被客戶砍頭。大師既.然要濟世救人，就只好請你們抱持著我不入地獄，誰入地獄的決心啰。
所以我會針對我觀察到的幾個因為采用OOAD，以及RUP在臺灣做案子所發生的幾個問.題，提出我個人的看法。幾個我觀察到的主要問題如下：
-沒有依據項目的特性來選擇項目開發方式。
-使用者或者是客戶的信息人員，看不懂相關的文件。
-信息人員本身不了解UML, OOAD以及RUP。
-Relational Database
以下我會針對這些問題，進行我個人的看法。
沒有依據項目的特性來選擇項目開發方式
臺灣的軟件項目，通常規模都不是很大，除非你將人力外包給企業使用，否則一般的軟.件項目，價格則多半是在一開始就定下來了，項目進行的過程里，通常沒什么機會可以.調整金額。
項目成員人數，多半在二十人以下。所以如果你要采用RUP來開發項目，你的第一個問.題會是，你湊不到足夠的人頭，來擔任每一個RUP所介紹的角色。
此外，你通常也沒有那樣的預算，可以讓每個角色，都把他們該做的文件都做出來。所.以你會省略一些流程。每次有人跑RUP跑的不順，他們第一個想法就是：『RUP的體系.博大精深，這是多少前人智能的結晶，一定是因為我省略了XX步驟，這次才會走的不.順利，下回一定要…』
RUP的另一個問題是，它是iterative的開發方式，也就是說，因為項目一定會有變更需求.發生，所以它預期沒有辦法一次就開發出使用者所要的東西。因此在開發時，會重復來.個好幾回。每次都會要求使用者提出評估。
這怎么會是個問題呢?實時取得使用者的響應是一件功德無量的事情啊。問題在于臺灣.的使用者通常都有正職在身，他們多半是利用農閑時進行專案的開發。所以他們的時間.非常寶貴，有機會跟你談一次需求，他就認為這是非常大的恩惠。
文章來源于領測軟件測試網 http://www.kjueaiud.com/