軟體工程方法論與IT政策

 

作者 : Fred F.M. Wang  原作日期 : 2004/08/12

企業在進行一項軟體專案除了專案管理方法外還會引用一套軟體工程方法(Methodology)來完成應用軟體的開發或實作。而採用的方法往往會與使用的技術或專案的特性相關，而專案管理方法也可能與採用的實作方法相關。例如: SAP ERP導入會採用SAP的ASAP Methodology, 而J2EE Project業界流行的是RUP或XP, 而RUP及XP各有一套專案管理的方法，也各有適用的狀況，RUP以Process為主體，XP以人為主體，RUP適用於60人以上的專案而XP適合於現有系統的改善或小型的專案。

企業在方法的選擇及使用的技術會根據其管理的角度訂定IT Policy，而不同管理層面的考慮的優先順序將對企業的成本與效益帶來不同程度的影響。

軟體工程方法論的採用及選擇

筆者在二十多年前研究所階段就以軟體工程方法論的研究為主，最早的軟體工程方法論源於工業工程方法，由於軟體技術的演進及軟體應用層面的擴大，傳統的方法論以經無法適用於各種應用的開發，因此衍生出許多現代的方法論。而這些方法論無非是用來解決應用需求轉換為軟體系統的問題，協助軟體專案從需求定義，系統建構，上線等過程提供系統方法來完成專案。採用軟體工程方法論的目的整理如下:

• 使用者，分析師，與程式設計師等專案人員有共同的語言
• 一致的程序及交付項目
• 以系統的方法增加成功的機率
• 提昇專案品質
• 提高專案的可預測性，及早發現問題
• 成功經驗可以經過文件加以傳承
• 提高專案的效能

如同軟體工程方法論的演進史，不同的方法論是因應不同種類的應用才產生出來的，因此IT Policy應該制定選擇方法論的程序，而非限定單一方法論的使用。

應用系統架構程序

大型與複雜的系統往往無法用單一技術元件完成，特別是近年來J2EE的專案，因Internet而盛行，J2EE Project往往會牽涉多種技術，因此在架構系統的過程更形重要，Architect需在專案範圍，風險，專案時程及資源預算等限制下訂出應用系統的架構，此架構可能包含應開發的元件組合, 選用產品及APIs等，當然IT Policy也是限制之一。由於專案的內外部限制已經很多，因此IT Policy在產品或平台的選擇方面，若過於僵化將使專案的進行更形艱難。

最佳軟體方案(Best of Breed)，單一供應商與自行開發的決策

企業在選擇軟體系統解決方案，會有三種可能的選擇最佳軟體方案(Best of Breed)，單一供應商與自行開發，而這三種方案的決策會受下面的條件的影響:

• 企業現況及需求，包含企業規模，組織，需求的範圍及條件等
• 預算與投資
• 技術或產品的成熟度與市場的趨勢
• 資訊人員的技術能力

以SCM Solution為例, 此三種方案比較如下表:

(另外, 近年使用Open Source或租用則不列入比較 – 2011/11/11)

由上表可知，若政策上要求企業需求適用性為第一考量，則會以Best of Breed及自行開發為主。

不同企業採用的策略不同，年營業額七億以上的Starbucks以Oracle ERP為主幹，再以Best of Breed的方式選入其他產品作為該企業SCM Solution。而年營業額七千四百萬的Green Mountain Coffee Roasters則採用單一廠商產品的解決方案。但是Wal-Mart仍採用自行開發的方式。

以特有與創新的經營管理模式取得市場優勢的公司，往往無法在市場找到適合於此模式的產品，因此傾向於自行開發，如Wal-Mart，其條件是需擁有專業的資訊科技部門。

由於許多較具規模的企業，其業務型態較為複雜，資訊科技於商業應用領域也較為廣泛，因此單一產品往往無法滿足於各項應用，因此也會傾向於採取Best of Breed的方式，如Starbucks等，來滿足快速成長的商業應用，但是業務型態單純及規模較小的企業容易選擇合適的產品以完成企業的需求此時將傾向於選擇單一套裝軟體以減低IT人力成本及整合成本。

因此IT政策在解決方案策略的訂定，應該優先從企業規模及商業需求為優先考慮，以因應企業快速變化的需求，例如，可以制定選擇解決方案的優先順序或不同狀況及不同條件下該採用何種解決方案。

不同產品的適用領域與架構設計師

不同的產品、API或Solutions各有其適用領域，根據筆者的經驗，一個具備一般WCM功能網站用WCM產品與採用Jakarta Struts framework開發的時程差異為一比九。而Document Management System及Workflow System上Lotus Notes優於SAP，Transaction Process則SAP優於Lotus Notes，而開發平台上Domino Designer的彈性優於SAP ABAP Workbench，但SAP Workbench開發速度較快。若某項需求適合用Lotus Notes完成，卻錯誤的選擇用SAP開發，那麼開發時程可能就需花費如上面九倍或更長的時間。

軟體架構設計師(Software Architect)在此的角色，就相當重要，軟體架構設計師是計劃並監督建構過程的軟體技術設計人員，主要的任務就在規劃與系統架構層次相關的事務，評估可能的風險與成本，並有效運用有限的人力、物力 資源達成系統層次的需求，因此除了是資深技術人員，通常也是策略制定、組織協調好手、稱職的顧問與領導者。

一位好的架構設計師通常具有以下專業領域的技術素養：

• 企業需求
• 硬體與軟體架構
• 分析、設計與開發
• 產品支援
• 效能、安全性、容量規劃(capacity planning)、網路

架構設計師在專案過程中的角色:

• 研擬最初的高階架構藍圖(blueprint)並列出影響架構可能因素的清單。
• 審慎評估付諸實施的專案計劃對系統既有基礎結構(infrastructure) 與架構的衝擊，以及計算可能付出的成本與所帶來的效益而訂定。
• 制定專案的架構決策與其優先順序的判斷基準、定義問題領域 (Problem Domain)、決定可能解決方案的限制條件、確認有關可能解決作法的假設狀況以及辨識模組重用的可能性。
• 負責確保需求的達成，以及硬體、軟體、基礎結構、效能、安全性、容量、可用性和系統運作、管理與維護等等屬於系統層次相關技術之間的協調與平衡。
• 構建架構時期，預先列出這些可能的風險，然後在後續的開發時期配合開發人員予以適當地處理與解決。
• 領導開發團隊，保持與其它成員的良好互動，確保開發人員是根據架構藍圖來構建系統。

因此企業應重視軟體架構師的人才培育與投資。在政策上也應訂定正確的方法來進行軟體開發專案。