DSS的统分析与设计.pptVIP

DSS的系統分析與設計 本章大綱 第一節 導論 第二節 ROMC系統分析法 第三節 反覆設計法 第四節 雛型(prototyping)系統設計法 第五節 使用者自建系統 第六節 物件導向程式設計法 第七節 UML技術 第八節 結論 學習目標 決策支援系統的分析步驟 分析決策問題的範圍與流程分析。 確認系統的需求。 決策支援系統的設計方法 反覆設計的方法與應用。 雛型法的設計方式與應用。 使用者自建系統的意義與應用。 物件導向技術與UML模組語言。 圖9-1 資訊系統開發建立的過程 ROMC系統分析法 四大構成元素 表達方式(Representations) 分析決策過程中必要資訊的表達形式是決策支援需求分析的首要工作。 運算(Operations) 指的是對資料所做的各種操作。 輔助記憶(Memory Aids) 決策支援系統能將有用的中間結果加以儲存，以備後面再使用。 ROMC系統分析法（續） 控制機制(Control Mechanisms) DSS控制機制是協助決策者依他個人的風格、技巧和知識，利用表達、運算及記憶來組合出一個決策程序。 ROMC分析程序 找出決策各階段的主要活動 針對每個活動找出系統的可能支援功能 建置ROMC要素 圖9-2 放款評估DSS的控制流程 ROMC應用實例 購車決策系統 情報蒐集—資料瀏覽 設計比較—比較車型與可行方案 做出決策—決定購買的車型 反覆設計法的步驟 找出重要的次問題(Subproblems) 由決策者或使用者和系統建立者共同找出次問題。愈是時間短的專案或問題反而特別適用於DSS的反覆設計法。 發展一個小而實用的系統來協助決策者 系統建立者和使用者共同迅速且小規模地完成系統發展過程。這個雛型系統經由不斷地修改測試，將發展成一個完整的決策支援系統。 反覆設計法的步驟（續） 反覆地精製、擴充並修改系統 系統初步完成後，便可以反覆地經由使用者評估與回饋來修正系統的功能，而得到新的版本。事實上，每個修改週期事實上都進行了「分析—設計—實施—使用—評估」等所有階段。 雛型(Prototyping)系統設計法 步驟 找出決策者做決策的資訊需求 和SDLC不同之處在於，雛型法並不要求將所有的需要一次完整地找出來。 建立雛型系統來檢驗決策者的需求 雛型法要求根據前面所找出的初步需求，很快就做出一個雛型系統 。 修改雛型 讓使用者在試用過雛型系統後，能明確地知道自己的需求 。 雛型(Prototyping)系統設計法（續） 依據雛型來開發完整的系統 「暫時雛型」經過持續的修改之後，成為有用的系統，則將這種雛型稱為「演進雛型」。 使用者自建系統的優點 交貨時間短 使用者在需要時便開發自用系統，因為他不需要經過申請、核准經費等手續，所以不需配合資訊部門的時間，可以立即進行開發而不會錯過時效。 較能滿足使用者的需求 因為是由使用者自行設計所需的系統，使用者和設計者間的溝通問題完全消失，理論上便能夠設計出一個充分滿足使用者需求的系統。 使用者自建系統的優點（續） 減少系統實施的阻力 因為系統是使用者自行設計建置，必然願意使用系統，因此可以消除使用者對資訊部門所設計的新系統的抗拒或不適應情況。 使用者自建系統的缺點 績效不彰 管理不易 使用者自行開發系統的目的往往是為了解決眼前的個別問題，所以在開發過程中無法審慎考量，也多半不會對系統作評估。一旦使用者離職，接任者可能完全無法使用該系統。另外，不同的使用者也可能重複開發功能相同的系統，造成資源的浪費而不自知，這些問題都使資訊資源的管理變得困難。 使用者自建系統的缺點（續） 角色衝突 使用者本身的主要任務並非開發系統，若他們花費太多時間與精力在自行開發系統上，可能會因此疏忽了他們本來的職責，造成本末倒置的現象，甚至與資訊部門的角色相衝突，這是必須要避免的問題。 EUC的管理策略 必須有一明確的EUC策略，配合整體政策和標準，在符合標準的情況下，讓使用者自行選擇，而不以嚴格的成本效益作為控制手段。 必須明確界定資訊部門和使用者雙方的權責，並鼓勵發展合夥關係。 必須顧及全體，不能只關注少數幾個使用者；讓使用者之間彼此分享資訊、程式與經驗。 全面持續推廣使用者教育訓練，讓使用者電腦知識能不斷充實、更新。 EUC的管理策略（續） 成立資訊中心，向EUC使用者提供下列服務 電腦入門訓練 電話諮詢服務 硬體和軟體標準的訂定 安全控管 編寫主機與PC的連線介面軟體 提供新軟體的安裝與試用報告 擔任EUC的系統專案經理人 EUC成功實施的重要條件 功能完整而且熱心的資訊服務中心，可對EUC的發展提供較佳的規劃、教育訓練、支援服務與管制措施。 擁有高素質的員工，員工大多數具高學歷，學習能力強。 公司擁有高度電腦化的環境，以及豐富電腦化的