如何利用元件化技術快速開發J2EE應用系統？

臺灣是否有軟體產業？如果答案是有，競爭優勢在哪裡？這幾年CMMI（Capability Maturity Model Integration）話題甚囂塵上，也引發元件化開發模式的探討。由若彼鄰網路科技主辦，iThome電腦報周刊和美商瑞理國際（Rational）、美商商渠協辦，「如何利用元件化技術快速開發J2EE應用系統」研討會，從發展趨勢和應用面討論以元件化開發應用系統的議題。

首先，由若彼鄰總經理陳哲雄發表對於「大中華區軟體產業的趨勢與未來」的看法，他認為，大陸軟體公司多如牛毛，臺灣軟體產業走向元件化開發模式是必然趨勢，如此才能取得立足之地；美商瑞理國際總經理吳佳惠則分享「落實元件化軟體發展理想」的主題，美商商渠林維志說明「元件化技術如何能快速開發J2EE應用」。

以下為陳哲雄、吳佳惠、林維志在研討會中發表演說的內容整理：

陳哲雄：最近業界在討論幾個問題，例如軟體人才都到電子業，臺灣軟體有沒有希望？中國軟體市場看似蓬勃，但是否已經建立產業結構？有人說從市場規模來看，臺灣沒有軟體產業。

若以中國經濟發展分析，1979年經濟開放到2000年，大陸經貿跳躍性成長，逐漸形成中產階級。根據IDC分析，中國的軟體發展包括軟體和服務，到2005年，內需市場仍大於輸出，不像印度是個軟體輸出國。不過，大陸政府推動軟體工業的決心，具體實踐於十個五年計畫中，將軟體列為主要發展產業，2005年目標產值要到2500億元，其中輸出要達50億元。

在鼓勵的環境下，大陸解決方案和工具市場快速成長，已經有一萬多家軟體公司，且競爭非常激烈，幾家臺灣上市的商用軟體公司在當地也屢遭險阻。IDC也預估未來大陸軟體市場將快速成長。中國政府發展產業沒有歷史包袱，最大的問題是市場過大。2001年外商紛紛進駐中國，世界級的軟體廠商林立，市場競爭程度不可同日而語。

過去這幾年軟體發展技術走向元件化，這已經不是新觀念，平常通用的函式庫、network computing等都是元件化表現。過去沒有共同標準的平臺，沒有標準的生命週期管理機制，巧婦難為無米之炊，無法落實軟體元件理想。從企業眼光來看，架構在平臺上不見得都是元件化，有些垂直產業的技術元件，或廠商發揮本身優勢建立軟體元件庫，都可以視為軟體元件化的實踐。

臺灣多數資訊大廠紛紛西進，如何用IT技術串起兩岸未來經濟命脈，利用既有優勢佔有一席之地，軟體元件化是為廠商建立灘頭堡的一劑妙方。

吳佳惠：把整個軟體經濟發展切割成三大塊，從1960年到現在2002年，每20年作為一區格。第一期從1960到1980年，這期間的軟體發展尚未有經濟規模，沒有運作出循環模式，更沒有reuse、元件或軟件工程觀念。開發應用軟體曠日費時且相當昂貴，常是超過預算或不按計畫進行。

1980到2000年之間已經有軟體或技術工程的概念出現，軟體工業的經濟模式尚未成熟。1990年代晚期開始成熟，企業需要導入ERP改善作業流程，希望要求資訊人員控制IT預算並如期交差，在這樣的要求下，IT負責人開始有專案的管理和控制需要。多數公司對流程或元件化開發基礎並沒有很清楚的了解。

2000年之後主要趨勢是企業e化，這個時候的應用系統有個特性：要求多人同時上線、能連接很多裝置、有行動通訊應用，環境比過去複雜，需要銜接很多技術，講求ROI、品質、產品上市時間，讓資訊人員很為難。軟體開發是搬磚頭的工程，要求生產力又要求品質，常常讓CIO陷入兩難，加上e化需求殷切，導入快速有效率的軟體工程是必要的。

事實上，99％的專案需要靠元件來完成。但要如何做到？Roadmap是什麼呢？透過專案不斷執行開發流程，產生模組、框架、特徵或元件，建立標準化基礎，儲存這些開發資源以便於再利用。元件化觀念已經喊了很多年，為什麼至今還不普遍？主要是當時標準尚未成形，到1995年才有標準作為依歸。

再利用的觀念架構在大規模的專案開發環境，在這個環境下可以依循標準，累積過去經驗，整合成元件以便重複使用。如此循環下去，必然可以做出高品質的應用系統。重新使用原始碼只是再利用觀念的一環，開發經驗累積還包括作業流程、框架、使用者介面、指導方針等，都是可以重複使用的資產。

以摩托羅拉為例，全球通過CMMI第五級認證的企業有40多個，它更是屬於早期通過的團隊。摩托羅拉在大中華地區的IT研發團隊，產出千百個軟體元件累積成一個大資料庫，做到手機完成上市，應用軟體馬上推出的地步，新的軟體開發只要花一個星期。

要滿足元件化開發流程，必須具備三個條件：第一是全面標準化，無論是Java或Cobol等，遵循共通標準和國際接軌，產生架構或機制管理陸續完成的元件，形成資產，接下來如何給其他夥伴使用？如何紀錄這個元件修改情形？修改後如何評估這個新的版本適合性？整個架構需要整合性的管理工具。

再利用的資產可視為元件，遵循共通標準格式，任何開發行為皆具體化透明化，並且建立類別，詳細標示每一個類別的內涵和功能，類似圖書管理員，先行編排，告知如何使用、元件之間的關聯性等訊息，以容易使用為前提，不是要和自己挑戰，主要價值和生產力是在於不斷地被專案重複使用。

十年前會以為這個觀念很新，當時標準都不成熟，Java出現是加值，讓物件導向技術更成熟。由於軟體開發要花很多時間提高品質和生產力，成本相當高，廠商為了增加競爭力、爭取生存空間，必然走向能提高效率和生產力的道路，其中有許多方法論。

摩托羅拉從1983年開始走物件導向，1985年建立專家系統（Expert System）。首先專案經理集中使用者需求，針對需求連結到專家系統，再去尋找以前的模組，挑出需要的元件，再進行20％到30％的客製化，把修改過的部分放回去，後端資料庫累積非常多元件，是公司最有價值的資產。

林維志：電子商業時代來臨，軟體開發變得更複雜，MIS面對的不只是單一系統，無論B2B或B2C，一定要考慮到自動化派送機制。此時，應用軟體要更有彈性，如果業務流程改變，不用再大費周章修改，節省開發時間和成本。

Gartnet估計，2003年有30％專案是元件化開發，2004年用元件化開發的專案，生產力會比別人提高10倍。另外，IDC預言，1999年以來，元件化的營收每年以40％成長，元件化和再利用讓企業省25萬美金，省數百個開發時數，還減少6000個工程師。

為什麼過去沒有成功的元件化開發模式？第一個原因是缺乏共通的語言。第二是缺乏標準的流程。第三則是缺乏元件的交易市集（marketplace）或社群。如果都要自己開發，大多都會沒有效率。第四、內部或外部使用元件要集中並且可以很快找到。第五、要有可依循的框架或架構。第六、其他平臺也遵循標準。

如何能夠成功地落實J2EE元件開發基礎？首先，建立架構，工程師在寫應用軟體時，要設計一套應用軟體，否則不知道如何界定什麼需要再利用。有了這些應用軟體後，就知道需求在哪裡，元件需求自然出現。第三，藍圖設計完如業務或文件管理很難用元件表現，就可用工具軟體來解決。