對這文章發表回應
發表限制: 非會員 可以發表
發表者： 冷日 發表時間： 2008/3/14 8:42:48
| ALM專題系列之三 整合式CASE工具自動化精簡開發流程 |
| CASE工具的發展能具體實現軟體開發生命週期，不僅開發過程更自動化，而且已將工具功能逐步結合流程的需求，成為理論轉為實踐的重要關鍵。除了商業版的開發工具，企業也可選擇開放源碼的解決方案，但前者高度整合與技術資源，可免除開發團隊應用工具的技術瓶頸。 實現應用軟體生命週期的CASE工具特性 企業面對CASE工具，常質疑其輔助上的意義，而不是必備的特性，但近來開發工具逐步自動化，卻能減少開發人員處理例行式事務的人力耗費，讓企業體認開發工具的效益。此外，由於敏捷開發方法在反覆增量的過程，更仰賴自動化的輔助，當工具結合流程後，跳脫輔助的角色，便成為開發人員不可或缺的利器。 以往企業面對CASE工具，難以確定應何時導入，以及應用的時機。但現在為了軟體能儘速上市，不僅仰賴工具高度自動化，也必須考量到CASE工具所帶來的成本效益。以下列出目前CASE自動化的主要功能與特色： ●正向工程（程式碼產生） ●逆向工程（由現有程式產生原架構與設計邏輯） ●支援抽象且完整的敏捷式開發流程 ●測試模型與自動化 ●模型與程式碼的雙向、同步開發 ●自動產生文件 ●自動建構版本（Build） ●搭檔開發（Pair Programming） ●支援新的塑模標準與模型轉換技術 ●第4代程式語言（4GLs） ●中央儲存庫（Repository） 其中最重要的是中央儲存庫，扮演著應用軟體生命週期所需的控管中心，可分為兩個主要部分：資訊儲存庫（Information Repository）與資料字典（Data Directory）。在《系統分析與設計：理論與實務應用》（培生出版社）書中對這兩者的定義，「資訊儲存庫結合了企業的資料與其應用程式組合的所有相關資訊，並提供自動化工具，以管理及控制存取儲存庫。而資料字典是一種電腦軟體，用來管理及控制存取資訊儲存庫。它提供工具來記錄、排序與處理各種資料。」 從以上這些特性，我們可歸納出一個重點，工具的演變將許多瑣碎的工作採用自動化的方式執行，猶如一個專屬的秘書（過去大型專案可能編列秘書這角色的預算），讓程式設計師專注於商業邏輯設計上。然而，自動化的工具並無法協助開發人員針對需求變更的溝通，所以工具逐漸加強塑模的功能，並同時採用UML標準。 ALM藉由工具整合朝向廣度流程趨勢 由於應用軟體生命週期已推出多年，帶動CASE工具功能發展更齊全，也因此，各解決方案的供應商也走向更廣泛的流程整合，以凸顯其特色與優勢。 以Borland為例，目前不僅提供支援完整應用軟體生命週期的CASE工具，未來更將進展為SDO(Software Delivery Optimization)，致力於整合軟體專案控管的廣闊度，以及保有自動化管理的特質。至於CA(組合國際)則將應用軟體生命週期整合資訊服務(Information Service)、安全(Security)、儲存(Storage)等應用層面，延伸生命週期，不單僅侷限在軟體開發與維護。此外，鼎新採取完全客製化內部團隊所需的系統與流程，後續將此方法論結合產品，使客戶也獲得應用軟體生命週期所帶來的高品質。 在CASE工具發展上，無論是商用軟體或開放源碼，均以塑模標準的UML作為溝通，並貫穿整個生命週期。由於塑模工具也邁向自動化發展，除了模型與程式碼雙向互動外，也內建模型轉換技術，此作法有助於以視覺化的呈現程式結構與設計邏輯，減少傳統經由文件或程式碼的溝通不良，並降低開發方向偏離的危險。 CASE工具自動化的限制：專案管理涵蓋度仍需加強 首先，「專案經理」角色的功能還有加強的空間。軟體開發專案產出物（Artifacts）可粗略地區分為兩種：技術性文件與管理性文件，前者主要是架構分析、操作說明、源碼等；後者則包括成本、時程、任務分配、風險、人力組織資源等。目前工具尚無法完整地關聯技術性與管理性的文件，以及同步的版本控管。往後專案經理需要重覆運用最佳實務（Best Practice）時，可能需要在文件儲存庫中遍尋各關聯性文件。 Sommerville提到，CASE工具自動化對軟體工程的改善有限，主要原因有兩個： 1.軟體工程基本是以創意為主的設計活動。現有的CASE工具能夠對例行性的活動做自動化，但完整的設計活動還是需要許多人為的介入。簡單地說，CASE 工具並不像是熱狗製造機，將豬肉與佐料放進入口，便可以期待出口是咖哩味的熱狗，它仍然需要結合軟體工程師的領域知識。 2.在大部分的組織中，軟體工程是一項團隊的活動。軟體工程師必須花許多時間與團隊成員溝通。CASE工具畢竟只是協助工具，僅能增加溝通的管道，但無法絕對地提升溝通效率。文⊙張瑞隆 軟體的Alpha測試與Beta測試 可接受度測試為軟體測試中的階段之一，也是我們所熟知的「Alpha測試」，以單一用戶的使用層面測試程式，直到開發者與使用者都認同軟體符合需求即可。接下來便是稱為所謂的「Beta測試」階段，將程式交由更多的使用者使用，並向開發者回報錯誤。程式可能經過多次的「Beta測試」，以及多次的「Release」等版本，之後便是上市販賣。 「歷久彌新」的測試人員 隨著關鍵性任務為主的應用系統日益複雜，企業更重視軟體品質，使得軟體測試成為開發過程中不可或缺的流程之一。企業也意識到，測試越早規畫，以及頻繁地執行，則開發成本下降越大。相對地，當軟體品質問題越晚發現，後續修正所須付出的代價與成本將以指數性成長。 CASE工具的進展已具備測試功能，原因是應用軟體生命週期將測試列為軟體品質保證的最後一關。敏捷式開發流程更提出，在軟體開發前期，便應擬定基於客戶需求的測試計畫（Test Plan），而且測試與開發是交互執行的，貫穿整個生命週期，並不存在嚴格的先後順序。 以軟體測試顧問服務為主的叡揚資訊，其副總陳志雄提出中肯的建議，軟體測試方法乃是基於數學模型與分析，不因資訊技術更新而有所不同。此外，軟體測試需要豐富的領域知識與經驗，以及高度的敏銳性和直覺，這兩點因素使得專業的測試工程師，抵抗資訊技術潮流快速轉變的衝擊，更不因工具自動化或測試外包而減損其價值，這也是與其他開發角色最大的不同處。對於專注於撰寫程式的開發人員，是個可參考的發展方向。 「黑箱測試」與「白箱測試」 在訪談的過程中，叡揚資訊系統工程師吳欣宇提到，測試依使用案例所設計的測試方法，區分為兩種。「黑箱測試（Black Box Testing）」，顧名思義，工程師已知程式或元件的設計規格，將程式視為一個「黑箱」，測試人員輸入資料後，並比對輸出值，如果結果與預期不一致，表示測試結果成功偵測出程式功能運作上的問題。簡單地說，測試人員只關心程式的功能，而不是實作的技術。 「白箱測試（White Box Testing）」則是針對程式或元件產生測試數據，測試工程師必須瞭解程式結構與實作方式，並分析程式碼，以證明各種功能均符合規格書所述的要求。 應用軟體生命週期解決方案整理表 表中分列各家供應商的解決方案步驟、工具、特色說明與模型圖等，我們可以由其中瞭解每個方案的特色與關鍵技術。(詳見220期iThome) |