DSS的規劃、設計與建置 資訊管理系 王淑卿
本章學習重點 Nolan 的階段成長理論 Bowman, Davis, & Wetherbe 三階段理論 IBM的企業系統規劃(BSP) 關鍵成功因素法(CSF) ROMC系統分析法 雛型法 生命週期法
使用者少，基本應用 使用者增加，缺乏整體規劃 建立組織控制 應用系統整合及控制 Nolan 的資訊系統成長四階段理論
Nolan 的資訊系統成長六階段理論 (資料庫技術加入)
Bowman, Davis, & Wetherbe三階段理論
McFarlan & McKenney的策略方格(Strategy Grid) 沒有不能工作，但無法提供競爭優勢 影響程度高 過渡 影響程度低 McFarlan & McKenney的策略方格(Strategy Grid)
IBM的企業系統規劃(Business System Planning, BSP)
關鍵成功因素法的內涵 關鍵成功因素(Critical Success Factors, CSF)是由Rockart (1982)所創的一套界定組織資訊需求的策略資訊規劃方法，目的是為幫助管理者定義資訊需求 它不同於BSP之處在於關鍵因素，而非企業整體流程。 資訊系統規劃者定義CSF 的兩大步驟為： 針對管理者所負責考量的因素，決定企業策略目標 再決定達成這些目標的關鍵因素
關鍵成功因素法的規劃步驟 1.訪問高階主管 2.分析並整合個人的關鍵成功因素 3.發展並認同公司的關鍵成功因素 4.確認關鍵成功因素 5.利用關鍵成功因素，開發資訊系統
關鍵成功因素法的優點 時間短、耗費少、容易達成 各經理人因能針對自己的需求，參與程度與興趣都會較高 有利於DSS 與EIS等高層次資訊系統的發展，提高資訊系統的支援層次 可在CSF 的推論中，重新思考企業的經營架構 不會有資訊超載的問題發生
關鍵成功因素法的缺點 涵蓋不完整，只重視主管決策與關鍵因素 變動性大，資訊架構不穩定，常因人而異 沒有標準的作業程序方法、結構低，依賴優秀的規劃及訪談人員的溝通技巧 只重視目前的重要問題，較無長遠方向的考慮與規劃 沒有包括實際的系統開發計劃
利用關鍵成功因素，開發資訊系統
使用關鍵成功因素法的注意事項 關鍵成功因素法為業務導向而非科技導向 專案經由上而下設計過程產生企業的關鍵成功因素法。一旦所有人員瞭解並接受公司關鍵成功因素法後，才能發展決策模型 高階主管必須強力支持。這必須由高階主管去推動，其他人才會重視 在訪談組織成員前，應教育其關鍵成功因素法概念，否則，訪談將產生無用資訊 在初始訪談中，關鍵成功因素法不應明顯地和資訊需求、電腦應用，或其他要素連結。應先從概括的公司業務或個人活動中確認關鍵成功因素法，從中產生資訊需求
企業資訊系統開發考量因素
決策支援系統的系統發展過程
決策支援系統的設計需求可分為六大層次
ROMC系統分析法 Sprange & Carlson (1982)提出ROMC法(Representation、Operation、Memory Aids、Control Mechanism)，用以評估一個特定決策支援系統是否能滿足系統設計的需求
ROMC系統分析法 ROMC統分析法主要是配合決策者的要求與決策支援系統的能力，由四方面進行分析。 1. 表達方式(Representation) ：說明問題或決策(使用者界面) 2. 運算(Operation)：處理問題的作業 3. 記憶輔助(Memory Aids) ：儲存永久性及暫時性的資料 4. 控制機制(Control Mechanism)：有兩大功能： 建立DSS使用程序與技巧的規範，例如選單或功能鍵 提供DSS使用者必要時的「協助」(Help)功能
運用ROMC分析法來分析決策支援系統，基本上可分為三個步驟 找出決策中，「情報」、「設計」、「選擇」、「執行」這四個階段的主要活動 針對每一個活動找出DSS系統需要提供的支援功能 建置「情報」、「設計」、「選擇」、「執行」這四個階段的ROMC元素
建置決策制定四階段的ROMC元素
雛型法(Prototyping) 雛型開發法是透過快速建立低成本的系統雛型，以提供使用者對系統的試用與評估，而幫助使用者對於資訊需求能更為了解，並進而提供系統開發者改進建議以改進系統
雛型開發法的步驟
雛型開發法的優點 雛型法特別適用於設計資訊系統的使用者介面，即使用者與電腦的人機互動媒介，例如：線上顯示畫面、資料輸入、報表或網頁等等。 雛型法可鼓勵使用者直接與新系統互動，增加使用者的參與感，減少使用者未來教育訓練時間，也可降低使用者抗拒。 雛型法較適合小型的系統。大系統則可將之分割為數個小型系統，並使用雛型法一次建立一部分。
雛型開發法的優點 協助快速發展完整的系統：雛型法能在系統發展中掩飾了一些必要的步驟(例如，相關文件的建立)，可加快系統的發展。 降低資訊系統完成後，無法滿足使用者需求的危機。開發過程早期提供一個可操作的系統模型來協助辨認正確的系統需求，彌補生命週期模式(SDLC)最大缺點，降低往後階段的風險。 使用雛型開發法，可以降低某些的系統開發成本。 當需求不確定時，雛型開發法是最有用的
雛型開發法的缺點與限制 容易忽略系統文件的撰寫 嚴謹度相對於SDLC比較不足 使用者容易誤認為雛型系統，就是完整的系統 雛型開發須經常修改雛型，可能會對使用者帶來學習困擾
系統開發生命週期法 (System Development Life Cycle：SDLC) 系統開發生命週期法將資訊系統的發展分成六個階段： 初步評估 可行性分析 系統分析 系統設計 系統建構 系統維護 每個階段都需在專案管理的控制及驗證下循序進行，若有發生任何問題，必須回到影響所及之上一個階段，以進行維護或修改，方能進入下一個步驟。系統開發生命週期法因圖形類似梯形瀑布，因此又稱為瀑布模式(Waterfall Model)
系統開發生命週期法(SDLC)
系統開發生命週期法的優點 系統開發生命週期法提供全面性的觀點，可幫助企業確定目標、策略及使用資訊科技解決問題或掌握機會，進而爭取競爭優勢的方法 十分嚴謹
系統開發生命週期法的缺點 開發時間冗長 使用者參與度較低 使用者只要在上線前的測試階段才有機會觸到系統，若有發現重大問題，常常為時已晚 若使用者的需求不確定時，系統開發生命週期法很難開發