『業務電腦化 設計自動化』這是大家一直想做的事 ，但是真的做到的呢?在軍中九個月，每次都得在最短 的時間內做出符合上級需求的系統。還是得一個個元件 拖拉、設定來的。於是想聽聽大家的意見，心中的CASE Tool功能到底是那些，也許在軍中可以做出來~ 大家來談談心目中的CASE Tool功能! 程式不是寫來玩的 而是要創造價值

------
林壽山
網站: http://superlevin.ifengyuan.tw
mail: superlevin@gmail.com

http://www.kensystem.com.tw/ken/html/report/case21.htm 引言 自從Internet興起後， IT環境巨幅地改變著，加上電子商務的出現，造成需求變更的速度加快，說是朝令夕改也不為過；然而以往軟體開發的方式，是否能因應需求快速改變的環境，及其日益多樣化的SDLC (軟體發展生命週期：Software Development Life Cycle) 呢？以及對IT產業又有什麼樣的影響呢？也許我們回顧一下台灣十年前，排名前十名的軟體公司裡，在今天有那些已更上層樓？或改弦更張？或愈做愈小？或消失在物換星移裡？也許我們能從上述問題裡，兜出一份IT如何因應環境改變的拼圖。TOP 需求與SDLC 曾經有家電信服務業的IT部門主管，與我談到他們在SDLC上所面臨的問題，譬如：他們有些軟體專案只有一到二週的SDLC，也就是說從軟體需求產生起，歷經分析、設計、建構、測試、系統維運、到軟體下架廢止等各個階段的時間，全部僅有一到二星期的時間。在如此短暫的時程壓縮裡，除了造成IT人員極度地負擔與壓力外，和需求單位間的歧見、衝突，也是與日俱增，因此他們正積極地評估與選擇CASE Tool(軟體工程電腦輔助工具；Computer Aid Software Engineering)，希望能幫助他們解決，在需求快速變動下，所衍生出的一些相關問題如： ■ 每一專案都是重頭做起 ■ 沒有時間了解完整的需求內涵 ■ 缺乏增長有效溝通的方法及工具 ■ 無法即時反應需求改變下，所造成SDLC內的連鎖反應 ■ 在不同型態的軟體專案裡，均使用同一種SDLC來開發及管理， ■ 為及時交付軟體，而無法兼顧軟體品質 ■ 專案成員間及專案之間，缺乏共通開發標準 ■ 專案開發的知識與經驗，無法累積與分享 後來，他們採用了一系列的CASE Tools，分別來處理在SDLC各階段的自動化工作，到現在已快二年了，據那位IT主管說：以前那些每次漏夜趕工、嘶吼溝通與被上面刮鬍子等場景，已不復再見了。TOP SDLC與CASE Tool 到底CASE Tool是什麼？真的有用嗎？OK！CASE Tool就如其中文名稱所示，是軟體工程的電腦輔助工具，它必需依循軟體工程裡特定的方法論，譬如IDEF、UML等，進而將SDLC各階段工作自動化的軟體，其中對階段的定義包含有(以IEEE STD 1012對SDLC定義為例)： ■ 概念規劃 ■ 需求分析 ■ 設計 ■ 程式建置 ■ 測試 ■ 安裝與簽出 ■ 運作與維護等七個階段 在上述的七個階段裡，CASE Tool分別透過下列技術方法與管理機制，來達成SDLC工作自動化的目標： ■ 標準化的方式，來提高效率(譬如：各種Standard, Template) ■ 知識化的方式，來累積及分享，開發的經驗與知識(譬如：Repository) ■ MDA(Model Driven Architecture模型導向架構)作為增長有效溝通的方法與工具 ■ MDD(Model Driven Development模型導向開發)作為可重覆利用的開發方法與工具 ■ 依所採用的方法論，檢測是否遵循方法論的遊戲規則 ■ 提供不同型態的SDLC樣板，給各式不同型態的軟體專案使用 ■ 變更管理的機制，來控管需求變更所衍生的相關程序與問題 ■ 型態管理的機制，來管理SDLC各階段自動化整合的問題 ■ 安全管理機制，來管理與監控任務與使用的權限 ■ 各種業界標準，如XML等，來與它牌CASE Tool整合 綜觀以上，CASE Tool的功能是非常寬廣的，簡單說來：『從需求產生到軟體下架停用為止』，CASE Tool提供了我們，一個在SDLC各階段的自動化工作中，所需之技術與管理的平台，也可以當成是軟體發展的基礎工程。TOP CASE Tool 分類 一般而言CASE Tool可依技術及管理的面向，來分為四種類別： 1. 專案生命週期管理 2. 軟體生命週期管理 3. 軟體分析、設計、建構、測試之管理 4. 需求管理 ■ 管理專案生命週期的CASE Tool，其中包含有： ＊ 專案流程樣板工具 ＊ 流程管理工具 ＊ 專案管理工具 ＊ 資源維護工具 ＊ 預測與實際工作時程回饋工具 ＊ 專案狀態與統計分析報表等工具 ■ 管理軟體生命週期的CASE Tool，其中包含有： ＊ 變更管理工具(Change Management) ＊ 型態管理工具(Configuration Management) ＊ 編譯與連結管理工具(Complier and Link) ■ 軟體分析、設計、建構及測試的CASE Tool，其中包含有(以MDA為例)： ＊ 流程模型工具(Process Model) ＊ 資料模型工具(Data Model) ＊ 元件模型工具(Component Model) ＊ 資料模型檢測工具(Data Model Validation) ＊ 模型管理工具(Model Manager) ＊ 程式產生器(Code Generator) ＊ 測試工具 在這部份另有一種以程式建置為分水嶺來作為工具的分類 ＊ Upper CASE Tool：處理程式建置前，所有分析、設計工作，屬於Logical ＊ Lower CASE Tool：處理程式建置起，所有的其它工作，屬於Physical ■ 需求管理的CASE Tool，其中包含： ＊ 需求定義 ＊ 需求討論 ＊ 需求樹 ＊ 需求變更衝擊分析 ＊ 需求與專案資源、程式、資料、程序間之矩陣圖 然CASE Tool雖分為上述四大類，但彼此間仍可透過管理工具，來達成垂直整合的縱效，而同一類裡的工具，則透過產業標準、或是同步化機制與介面，來完成橫向整合需求，使得CASE Tool能因應任何規模的軟體專案。TOP 如何導入CASE Tool 在大致上認識CASE Tool後，再來談一個大家常有的誤會，『採用了CASE Tool之後，就一切OK!』，但實際的情況是，『必需有配合與執行適當的導入計劃』，才能達成您當初的目標與願景。因為CASE Tool區分為管理及技術等不同層面，所以在導入前必需考量到，所將牽扯影響到的各種內部面向，譬如公司文化、管理制度、開發技術、開發能力與開發工具等，舉簡單的例子來看： ■ 有關專案生命週期部份，必需考慮的因素如： ＊ 是否已有專案管理制度存在？如有的話，缺失在那？ ＊ 現有專案管理能力如何？是符合ISO？或是CMMI的？或有PMP (Project Management Professional專案管 理師) 在專司其責呢？ ＊ 我們專案管理的目標是什麼？在成本、資源、管理等各方面的目標？ ■ 有關軟體生命週期部份，必需考慮的因素如： ＊ 現有的需求變更處理制度？ ＊ 需求變更處理的目標？ ＊ 可有型態管理制度存在？如有的話，困難在那？ ＊ 對於型態管理的目標是什麼？ ＊ 是否存在自動編譯、連結與派送軟體的需求？ ■ 有關分析、設計、建構等部份，必需考慮的因素如： ＊ 您所使用的方法論是什麼？ ＊ 您使用幾種方法論？如果不只一種的話，為什麼？ ＊ 您理想中的方法論，與目前所使用的是否相同？如不同的話，為什麼？ ＊ 可有方法論整合的計劃？如何將目前過度到與未來接軌？ 以上僅是一般基本考量，針對不同企業、產業，所需的思考層級，亦不盡相同，畢竟導入CASE Tool，不僅是攸關技術面向的問題，更深深地牽動著企業文化、管理制度等人文面向，能否相互磨合出，一份久服輕身，陸地成仙的秘方。TOP 結語 CASE Tool發展至今，至少也三十多年了，未曾大紅大紫過，但在IT環境因為Internet及電子商務的興起後，造成『快速改變的需求與技術，且相互間在以更快的速度在影響生成著』，因此IT莫不企求因應之道，而其中以軟體發展的基礎工程著手而言，是一條最佳途徑，因為大環境與大趨勢的改變下，只有二條因應之道，一是本身產生相當的質變來繼續生存，一是無動於衷地，隨著物換星移而去，不知您的看法如何，是否想進一步了解CASE Tool呢？TOP