1 / 52

第3章

建立需求 模型. 第3章. 階段說明. 系統分析是系統開發生命週期 ( SDLC) 五個階段中的第二階段 在系統分析階段，目標是利用需求模型及企業模型的建立來表示一個新系統 在向下一階段，系統設計階段，推進之前，你也將考量系統開發的各種策略。. 學習目標. 解說系統分析階段的所有活動以及其產出 了解聯合應用系統開發 ( JAD) 及快速應用系統開發 ( RAD) 方法論 解說系統分析師如何使用功能分解圖 ( FDD) 描述統一模型語言 ( UML) 並解說使用情況圖及次序圖的使用方法. 學習目標.

cheyenne-frazier
Télécharger la présentation

第3章

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 建立需求模型 第3章

  2. 階段說明 • 系統分析是系統開發生命週期 (SDLC) 五個階段中的第二階段 • 在系統分析階段，目標是利用需求模型及企業模型的建立來表示一個新系統 • 在向下一階段，系統設計階段，推進之前，你也將考量系統開發的各種策略。

  3. 學習目標 • 解說系統分析階段的所有活動以及其產出 • 了解聯合應用系統開發 (JAD) 及快速應用系統開發 (RAD) 方法論 • 解說系統分析師如何使用功能分解圖 (FDD) • 描述統一模型語言 (UML) 並解說使用情況圖及次序圖的使用方法

  4. 學習目標 • 列出並解說各種系統需求，包括輸出、輸入、處理工作、效率和控制等 • 解說規模彈性在系統設計的重要性 • 使用發現事實的技術，包括訪談、文件查閱、觀察、問卷、抽樣及研究

  5. 學習目標 • 定義總取得成本 (TCO) 並解說其觀念 • 描述如何從事成功的訪談 • 發展有效的文件建立方法以供系統開發時使用

  6. 簡　介 • 本章首先解說系統分析師用來觀察並記錄新系統的需求模型建立技術及團隊方法 (team-based methods) • 本章接著討論系統需求及發現事實的技術，其中包括訪談、文件查閱、觀察、問卷調查、抽樣以及研究

  7. 系統分析階段概述 • 運用各種模型及文件工具來預見並描述所提議的系統 • 系統分析階段的交付標的或產出是一份系統需求文件 (system requirement document) Figure 3-2

  8. 系統分析階段概述 • 系統分析技巧 • 分析技巧 (analytical sikll) • 人際技巧 (interpersonal skill) • 團隊導向方法及技巧 • 聯合應用系統開發 (JAD, joint application development) • 快速應用系統開發 (RAD, rapid application development)

  9. 聯合應用系統開發方法 • 使用者參與 • 使用者在資訊系統中有重大的關聯，而且他們應該在開發過程中完全參與 • 成功的系統必須是使用者導向的，而使用者需要參與系統開發的每一階段

  10. 聯合應用系統開發方法 • JAD參與者及其角色 Figure 3-4

  11. 聯合應用系統開發方法 • 典型的JAD 會議議程如圖 3-5 所示 Figure 3-5

  12. 聯合應用系統開發方法 • JAD 的優缺點 • 成本較高且如果小組相對於專案規模顯得太大時也可能變得繁複 • 讓主要的使用者有機會在需求模型建立的過程中有效的參與 • 當運用得當時，JAD 可以產生更精確的系統需求描述、對共同目標更加了解，以及對新系統的成功提供更強的保證。

  13. 快速應用系統開發 • 是一種能夠加快資訊系統開發速度且產生一個能夠運作的資訊系統的一種以團隊為基礎的系統開發技術 • 非常仰賴雛型的建立及使用者的參與 • 專案小組採用CASE 工具來建立雛型並且產生一系列的文件

  14. 快速應用系統開發 • RAD 各階段及其活動 Figure 3-7

  15. 快速應用系統開發 • RAD 目標 • 藉由使用者在系統開發每一階段的參與來減少開發的費用及時間 • 一個成功的RAD 小組也必須要有IT 資源、技術、及管理者的支持 • 能夠協助一個開發小組設計一個需要高度互動或複雜的使用者介面的系統

  16. 快速應用系統開發 • RAD 的優缺點 • 系統可以在節省大量成本之下快速地被開發出來 • RAD 強調系統本身的機制而不注重公司的策略性業務需要 • 其風險在於短期內系統可能運作良好，但是公司及系統的長期目標不見得相符。 • 另外一個潛在的缺點是加速的週期時間可能導致無暇兼顧品質、一致性，及設計標準

  17. 建立模型的工具及技巧 • CASE 工具 Figure 3-8

  18. 建立模型的工具及技巧 • 功能分解圖 (FDD, functional decomposition diagram) • 是一種由上而下展示企業功能與流程的方法 • 也被稱為結構圖 (structure charts)

  19. 建立模型的工具及技巧 • 功能分解圖 (FDD) Figure 3-9

  20. 建立模型的工具及技巧 • 統一模型語言 (UML, Unified Modeling Language) • 是一種廣受採用於將系統設計視覺化及建立文件的方法 • 提供幾種圖形工具和技術，例如使用情況圖及次序圖

  21. 建立模型的工具及技巧 • 統一模型語言 (UML) Figure 3-10

  22. 建立模型的工具及技巧 • 統一模型語言 (UML) Figure 3-11

  23. 建立模型的工具及技巧 • 統一模型語言 (UML) Sequence Diagram Figure 3-13

  24. 系統需求查核清單 • 系統需求 (system requirement) • 系統需求可分為五大類： • 輸出 • 輸入 • 處理工作 • 績效 • 控制

  25. 未來成長、成本，及利益 • 規模彈性 (scalability) • 一個有彈性的系統有較長的有效壽命，所以對於先前的投資會有較好的回報。 • 評估規模彈性，你需要有關目前及未來所有輸出、輸入，及處理工作的工作量及成長率的資訊

  26. 未來成長、成本，及利益 • 總取得成本 (TCO, total cost of ownership) • 除了直接成本之外，系統開發者必須找出並記錄所有構成總取得成本 (TCO, total cost of ownership) 的間接費用 • 微軟已經開發了一個衡量總成本及效益的方法，稱為快速經濟驗證 (REJ, Rapid Economic Justification)

  27. 發現事實 • 概　述 • 雖然軟體可以幫助你收集與分析事實，但並沒有程式能夠真正地為你做發現事實的工作 • 第一步是確認你所需的資訊

  28. 發現事實 • 誰來做、做什麼、在哪裏做、何時做、如何做 (who, what, where, when, and how) Figure 3-15

  29. 發現事實 • Zachman企業結構體制 (Zachman Framework for Enterprise Architecture) • 是一個在如圖 3-16 的系統開發情境下詢問傳統發現事實的各種問題的模式

  30. 發現事實 Figure 3-16

  31. 訪談 (interview) • 系統分析師有很多時間用在與人會談 • 有許多時間是花在做訪談 • 訪談 (interview) 是一個有計畫的會談，藉由它，你可以從其他人口中獲得資訊 • 訪談的過程由七個步驟組成

  32. 訪談 (interview) • 第 1 步驟：決定訪談對象 • 非正式的架構 (informal structure) • 第 2 步驟：設定訪談目標 • 首先，你必須設定所要談的一般領域 • 然後列出你想要獲得的事實

  33. 訪談 (interview) • 第 3 步驟：發展訪談問題 • 建立一個標準的訪談問題清單幫助你不偏離主題，並避免不必要的一些漫談 • 避免誘導式問題 (leading question) • 開放式問題 (open-ended questions) • 封閉式問題 (closed-ended questions) • 區間回應問題 (range-of-response questions)

  34. 訪談 (interview) • 第 4 步驟：準備訪談工作 • 細心的準備是重要的，因為這可不是一個隨意的閒聊 • 將訪談限制在一個小時以內 • 在會談前幾天就把基本問題的清單送一份給受訪者 • 如果你有一些問題牽涉到文件，可要求受訪者在開會時準備一些樣本

  35. 訪談 (interview) Figure 3-18

  36. 訪談 (interview) Figure 3-19

  37. 訪談 (interview) • 第 5 步驟：實際從事訪談 • 應該對會談定出一個特定的計畫 • 首先你應該介紹自己，描述一下本專案，並解說此次訪談的目標 • 專注傾聽 (engaged listening) • 讓受訪者有充分的時間思考並獲致解答 • 即刻彙整訪談中所提及的重點 • 在訪談之後，你應該彙整訪談的會議記錄並取得參與者的確認

  38. 訪談 (interview) • 第 6 步驟：記錄訪談文件 • 雖然在訪談中做筆記有優點，但一致的看法是應該儘可能的減少 • 在訪談之後，你必須迅速地記下所得到的資訊 • 在訪談之後，記得送一份備忘錄給受訪者對他的時間及合作表示感謝。在備忘錄中，你應該註明日期、時間、地點、訪談目標，及你所提及的主要話題，如此受訪者可以得到一份書面的彙整並且可以據以提出補充或更正

  39. 訪談 (interview) • 第 7 步驟：評估訪談結果 • 除了記錄下訪談中所發現的事實之外，也要試著找出其中可能的偏頗之處 • 不成功的訪談 • 無論你為訪談做的準備多麼好，有些訪談還是不成功

  40. 其他發現事實的技術 • 文件查閱 (document review) • 觀察 (observation) • 觀看運行中的系統可以給你另一種見解及對系統程序更佳的體認 • 預先規劃你的觀察工作 • 留意霍桑效應 (Hawthorne Effect)

  41. 其他發現事實的技術 • 問卷及調查 • 保持問卷的簡潔，且便於回答者使用 • 為所有可能的問題提供明確的指引 • 以合邏輯的順序安排問題，題目由簡易到複雜排列　

  42. 其他發現事實的技術 • 問卷及調查 • 問題的措詞要避免誤解；使用簡單的術語和詞彙 • 儘量不要引導回答或使用暗示預期答案線索的問題 • 少使用不容易製表的開放型問題

  43. 其他發現事實的技術 • 問卷及調查 • 少使用能夠引起關於職務安全的憂慮或其他負面因素的問題 • 在問卷的末尾，包含收集一般意見的段落 • 儘可能在最後定稿並發給大群組之前，在一個小型測試群組中檢驗問卷

  44. 其他發現事實的技術 • 抽樣 (sampling) • 系統抽樣 (systematic sample) • 分層抽樣 (stratified sample) • 隨機抽樣 (random sample) • 任何一個樣本的主要目的都是確保它能夠準確代表總體

  45. 其他發現事實的技術 • 研究 (research) • 新聞群組 (newsgroups) • 現場參訪 (site visits) Figure 3-23

  46. 其他發現事實的技術 • 訪談與問卷調查的比較 • 當你必須向許多人員提出一系列相同的問題時，問卷調查就很有用 • 如果僅從少數人取得資訊，那麼你可能就應當個別訪談每一個人 • 訪談比問卷較為親切且個人化 • 問卷調查給許多人提供意見投入和建議的機會

  47. 文件製作 • 記錄事實的必要性 • 得到資訊立即記錄 • 儘可能採用最簡單的記錄方法 • 以別人能夠了解方式記錄你的發現 • 把你的文件好好整理，使相關的資料文件等可以容易的被找到

  48. 文件製作 • 軟體工具 • CASE 工具 • 文字處理 • 電子試算表 • 資料庫 Figure 3-24

  49. 文件製作 • 軟體工具 • 簡報製圖軟體 • 個人資訊管理軟體

  50. 企業模型建立的預習 • 在需求模型建立完成時，系統開發人員應該清楚地了解企業流程及系統需求 • 下一步是要建立系統的邏輯模型

More Related