第3章
DESCRIPTION
建立需求 模型. 第3章. 階段說明. 系統分析是系統開發生命週期 ( SDLC) 五個階段中的第二階段 在系統分析階段,目標是利用需求模型及企業模型的建立來表示一個新系統 在向下一階段,系統設計階段,推進之前,你也將考量系統開發的各種策略。. 學習目標. 解說系統分析階段的所有活動以及其產出 了解聯合應用系統開發 ( JAD) 及快速應用系統開發 ( RAD) 方法論 解說系統分析師如何使用功能分解圖 ( FDD) 描述統一模型語言 ( UML) 並解說使用情況圖及次序圖的使用方法. 學習目標. - PowerPoint PPT PresentationTRANSCRIPT
22
階段說明
● 系統分析是系統開發生命週期 (SDLC) 五個階段中的第二階段
● 在系統分析階段,目標是利用需求模型及企業模型的建立來表示一個新系統
● 在向下一階段,系統設計階段,推進之前,你也將考量系統開發的各種策略。
33
學習目標
● 解說系統分析階段的所有活動以及其產出● 了解聯合應用系統開發 (JAD) 及快速應用系
統開發 (RAD) 方法論● 解說系統分析師如何使用功能分解圖 (FDD) ● 描述統一模型語言 (UML) 並解說使用情況圖
及次序圖的使用方法
66
簡 介
● 本章首先解說系統分析師用來觀察並記錄新系統的需求模型建立技術及團隊方法 (team-based methods)
● 本章接著討論系統需求及發現事實的技術,其中包括訪談、文件查閱、觀察、問卷調查、抽樣以及研究
77
系統分析階段概述
● 運用各種模型及文件工具來預見並描述所提議的系統
● 系統分析階段的交付標的或產出是一份系統需求文件 (system requirement document)
Figure 3-2
88
系統分析階段概述
● 系統分析技巧 – 分析技巧 (analytical sikll) – 人際技巧 (interpersonal skill)
● 團隊導向方法及技巧 – 聯合應用系統開發 (JAD, joint application
development)
– 快速應用系統開發 (RAD, rapid application development)
1212
聯合應用系統開發方法
● JAD 的優缺點 – 成本較高且如果小組相對於專案規模顯得太大時也可能變得繁複
– 讓主要的使用者有機會在需求模型建立的過程中有效的參與
– 當運用得當時, JAD 可以產生更精確的系統需求描述、對共同目標更加了解,以及對新系統的成功提供更強的保證。
1313
快速應用系統開發
● 是一種能夠加快資訊系統開發速度且產生一個能夠運作的資訊系統的一種以團隊為基礎的系統開發技術
● 非常仰賴雛型的建立及使用者的參與● 專案小組採用 CASE 工具來建立雛型並且產
生一系列的文件
1515
快速應用系統開發
● RAD 目標 – 藉由使用者在系統開發每一階段的參與來減少開發的費用及時間
– 一個成功的 RAD 小組也必須要有 IT 資源、技術、及管理者的支持
– 能夠協助一個開發小組設計一個需要高度互動或複雜的使用者介面的系統
1616
快速應用系統開發
● RAD 的優缺點 – 系統可以在節省大量成本之下快速地被開發出來
– RAD 強調系統本身的機制而不注重公司的策略性業務需要
– 其風險在於短期內系統可能運作良好,但是公司及系統的長期目標不見得相符。
– 另外一個潛在的缺點是加速的週期時間可能導致無暇兼顧品質、一致性,及設計標準
1818
建立模型的工具及技巧
● 功能分解圖 (FDD, functional decomposition diagram)
– 是一種由上而下展示企業功能與流程的方法
– 也被稱為結構圖 (structure charts)
2020
建立模型的工具及技巧
● 統一模型語言 (UML, Unified Modeling Language)
– 是一種廣受採用於將系統設計視覺化及建立文件的方法
– 提供幾種圖形工具和技術,例如使用情況圖及次序圖
2525
未來成長、成本,及利益
● 規模彈性 (scalability)
– 一個有彈性的系統有較長的有效壽命,所以對於先前的投資會有較好的回報。
– 評估規模彈性,你需要有關目前及未來所有輸出、輸入,及處理工作的工作量及成長率的資訊
2626
未來成長、成本,及利益
● 總取得成本 (TCO, total cost of ownership) – 除了直接成本之外,系統開發者必須找出並記錄所有構成總取得成本 (TCO, total cost of ownership) 的間接費用
– 微軟已經開發了一個衡量總成本及效益的方法,稱為快速經濟驗證 (REJ, Rapid Economic Justification)
2929
發現事實
● Zachman 企業結構體制 (Zachman Framework for Enterprise Architecture)
– 是一個在如圖 3-16 的系統開發情境下詢問傳統發現事實的各種問題的模式
3131
訪談 (interview)
● 系統分析師有很多時間用在與 人會談● 有許多時間是花在做訪談● 訪談 (interview) 是一個有計畫的會談,藉
由它,你可以從其他人口中獲得資訊● 訪談的過程由七個步驟組成
3232
訪談 (interview)
● 第 1 步驟:決定訪談對象– 非正式的架構 (informal structure)
● 第 2 步驟:設定訪談目標– 首先,你必須設定所要談的一般領域– 然後列出你想要獲得的事實
3333
訪談 (interview)
● 第 3 步驟:發展訪談問題– 建立一個標準的訪談問題清單幫助你不偏離主題,並避免不必要的一些漫談
– 避免誘導式問題 (leading question)– 開放式問題 (open-ended questions)– 封閉式問題 (closed-ended
questions) – 區間回應問題 (range-of-response
questions)
3434
訪談 (interview)
● 第 4 步驟:準備訪談工作– 細心的準備是重要的,因為這可不是一個隨意的閒聊
– 將訪談限制在一個小時以內– 在會談前幾天就把基本問題的清單送一份給受訪者
– 如果你有一些問題牽涉到文件,可要求受訪者在開會時準備一些樣本
3737
訪談 (interview)
● 第 5 步驟:實際從事訪談– 應該對會談定出一個特定的計畫– 首先你應該介紹自己,描述一下本專案,並解說此次訪談的目標
– 專注傾聽 (engaged listening) – 讓受訪者有充分的時間思考並獲致解答– 即刻彙整訪談中所提及的重點– 在訪談之後,你應該彙整訪談的會議記錄
並取得參與者的確認
3838
訪談 (interview)
● 第 6 步驟:記錄訪談文件– 雖然在訪談中做筆記有優點,但一致的看法是應
該儘可能的減少– 在訪談之後,你必須迅速地記下所得到的資訊– 在訪談之後,記得送一份備忘錄給受訪者對他的
時間及合作表示感謝。在備忘錄中,你應該註明日期、時間、地點、訪談目標,及你所提及的主要話題,如此受訪者可以得到一份書面的彙整並且可以據以提出補充或更正
3939
訪談 (interview)
● 第 7 步驟:評估訪談結果– 除了記錄下訪談中所發現的事實之外,也
要試著找出其中可能的偏頗之處● 不成功的訪談
– 無論你為訪談做的準備多麼好,有些訪談還是不成功
4040
其他發現事實的技術
● 文件查閱 (document review) ● 觀察 (observation)
– 觀看運行中的系統可以給你另一種見解及對系統程序更佳的體認
– 預先規劃你的觀察工作– 留意霍桑效應 (Hawthorne Effect)
4343
其他發現事實的技術
● 問卷及調查– 少使用能夠引起關於職務安全的憂慮或其他負面因素的問題
– 在問卷的末尾,包含收集一般意見的段落– 儘可能在最後定稿並發給大群組之前,在
一個小型測試群組中檢驗問卷
4444
其他發現事實的技術
● 抽樣 (sampling) – 系統抽樣 (systematic sample)– 分層抽樣 (stratified sample) – 隨機抽樣 (random sample) – 任何一個樣本的主要目的都是確保它能夠準確代表總體
4646
其他發現事實的技術
● 訪談與問卷調查的比較– 當你必須向許多人員提出一系列相同的問題時,問卷調查就很有用
– 如果僅從少數人取得資訊,那麼你可能就應當個別訪談每一個人
– 訪談比問卷較為親切且個人化– 問卷調查給許多人提供意見投入和建議的機會
5151
本章總結
● 系統分析階段包括了四個主要活動:建立需求模型、建立資料及處理工作模型、建立物件模型,以及過渡到系統設計階段
● 其總目標在於了解所提議的專案,確認它將會支援企業需求,並為後續的系統設計階段奠下穩固的基礎
● 發現事實的步驟包括訪談、文件查閱、觀察、問卷調查、抽樣及研究