顯示具有 System Analysis and Design 標籤的文章。 顯示所有文章
顯示具有 System Analysis and Design 標籤的文章。 顯示所有文章

2009年10月31日

系統分析與設計筆記

目前筆記完成度100%

請大家幫忙除錯，感謝

老人家，難免打錯字。。。


章節大綱

第一章：

系統分析與設計 - Start -
The Systems Development Life Cycle(SDLC) 系統開發生命週期
SDLC 五階段 - 概觀
System Request - 系統需求申請書
Feasibility Analysis - 可行性分析
Cost - Benefit Analysis - 成本-效益分析圖

第二章：

Project Selection
Project Methodology Options 概觀
Waterfall Development - 瀑布式開發法
Parallel Development - 並行開發法
V-model - 軟體測試管理模型
Iterative Development - 反覆式開發法
System Prototyping - 雛形法
Throwaway Prototyping - 丟棄雛形法
Extreme programming(XP) - 終極程式
Criteria for Selecting a Methodology - 選擇開發模型的標準
Project Management - 專案管理

第三章：

System Analysis - 系統分析階段
系統分析策略 概觀
BPA - Problem Analysis - 問題分析
BPA - Root Cause Analysis(RCA) - 根本原因分析
BPI - Duration Analysis - 時間分析
BPI - Activity-Based Costing - ABC 分析
BPI - Informal Benchmarking - 非正式標竿法
BPR - Outcome Analysis - 結果分析
BPR - Technology Analysis - 技術分析
BPR - Activity Elimination - 作業消除
Comparing Analysis Techniques - 比較分析策略
Requirements-Gathering Techniques - 需求收集技術
Interviews - 訪談
Joint Application Development (JAD) - JAD 會談
Questionnaires - 問卷調查
Document Analysis - 文件分析
Observation - 觀察法
Comparison of Requirements-Gathering Techniques - 比較需求收集技術

On 1 則留言:
At：

2009年10月29日

Comparison of Requirements-Gathering Techniques - 比較需求收集技術

比較需求收集技術的六大角度

Type of information - 資訊的類型
Depth of information - 資訊的深度
Breadth of information - 資訊的廣度
Integration of information - 資訊的整合度
User involvement - 使用者涉入程度
Cost - 成本 

比較圖：





閱讀上一篇（Requirements-Gathering Techniques - 需求收集技術）

期中考到此

On 沒有留言:
At：

Observation - 觀察法

概觀：

直接觀察企業運作流程
多用於了解舊的資訊系統
尤其用於「管理者」無法直接口述他的作業流程

觀察法常常與面談合併使用
  • 利用訪談的機會，到受訪者的辦公室，觀察其陳設，言談，以及行動（他如何做事情，發現怎麼樣可以幫助他做的更好） 



On 沒有留言:
At：

Document Analysis - 文件分析

概觀：

通常用來了解舊系統
分析舊系統所留下來的文件
缺點：舊系統沒有留下文件或文件維護不完整時，無法使用此方法
         （現在可以使用逆向工程的軟體輔助，了解舊系統）

文件種類：
  • 表格 
  • 報表 
  • 政策文件
  • 組織圖 
  •  用來描述公司正規化或沒正規化的系統



On 沒有留言:
At：

Questionnaires - 問卷調查

三種會使用問卷調查的時機：

* 當需要從很多人那邊收集資料的時候

* 當收集資料的來源是組織外的人的時候

* 當要從企業分散於各地的員工收集資料的時候

四步驟：

  (1) Selecting Participants - 選擇參加者

從母體裡抽取樣本（兩個方法：隨機抽樣，方便抽樣）

  (2) Designing the Questionnaire - 設計問卷

問卷的問題要文字簡潔，意思清楚
問卷所問的問題大多都是封閉式的問題
  • 原則：分清楚什麼是事實，什麼是意見 
  •          同一類的問題放在一起

  (3) Administering the Questionnaire - 管理問卷調查

選擇填答者，並確保問卷回答完可以回收的回來
所有的問題都要被回答（否則為無效問卷）
利用方法提高問卷回收的效率（Ex：催收，給小禮物）

  (4)  Questionnaire Follow-up - 問卷後續行動

完成問卷報告，送給填答者過目（統計過後的結果）



On 沒有留言:
At：

Joint Application Development (JAD) - JAD 會談

概觀：

1977年，由 IBM 公司所發明
三方會談：「MIS人員」＋「高階主管」＋「使用者」
被發明出來為了解決不同階層不同部門的人，資料不一致的情況
以使用者為核心，以管理者為主導，再由資訊人員提供技術支援的方法
E - JAD （JAD 視訊會談）
會談時間：幾個小時或幾天或幾週，直到達成共識，收集完整資料為止

IBM 建議：
  • 不要在公司舉行
  • 密集的開會
  • 閉門會議 

優點：讓彼此了解彼此立場

缺點：容易有人主導回答問題，而非全部的人都回答

五步驟： 

  (1) Selecting Participants - 選擇參加者

每個層級都要有人參加

  (2) Designing the JAD Session - 設計 JAD 會議

大部份的會議在三週中找 5 - 10 天來進行
E - JAD：一州內選擇 1 - 4 天完成
JAD 會議所問的問題都是開放式問題或追根究底式問題
JAD 會議的所問的問題結構都是由上而下的（簡略 -> 精確）

  (3) Preparing for the JAD Session - 準備 JAD 會議

要讓參與者了解，我們希望他們準備什麼樣的資料
MIS 人員也要根據此次 JAD 會議的目的，準備相關資料

  (4) Conducting the JAD Session - 進行 JAD 會議

JAD 會議的三個原則：
  • 尊重其他人的意見
  • 接受不同意的意見 
  • 確保同時間只有一個人發言 

JAD 會議主持人的三個主要功能 ：
  • 照議程進行
  • 幫助大家了解專業術語（包括商業的，技術的）
  • 紀錄所有討論的資訊 

  (5) Post-JAD Follow-up - JAD 的後續行動

完成 JAD 會談的會談報告（要有結論），傳給參加者確認



On 沒有留言:
At：

Interviews - 訪談

概觀：

面談是用來做資料收集最常用的方法
不一定是面對面，還有 E-Interviews  （視訊訪談）
不一定是一對一，也可能是一對多（同部門）

五大步驟：

(1) Selecting Interviewees - 選擇受訪者

除了選擇受訪者外， 還要確定訪談的目的，時間，地點
訪談人員必須包括組織各層級的人（各層級可提供不同的資料）
不同層級的人員，會問他們不一樣的問題
  • 資深管理人員：策略性資料
  • 中階主管：廣泛的資料 （關於企業的流程） 
  • 低階主管以及工作人員：工作上的細節
詢問順序：高階 -> 中階 -> 低階 -> 中階 -> 高階（確認問題）

(2) Designing Interview Questions - 設計面談問題

三大類面談問題：

  • Closed-Ended Questions - 封閉式問題 
  •    必須要明確答案的問題（選擇題，是非題） 
  •    較常使用 
  •   優點：做統計分析很容易，比較能控制訪談的進行 
  •   缺點：訪談者無法暢所欲言，收集到的資料會有所失真，限制

  • Open-Ended Questions - 開放式問題 
  •    可以得到比較豐富的內容（填充題，簡答題） 
  •    優點：可以挖掘更多資料 
  •    缺點：統計分析困難（內容龐雜）

  • Probing Questions - 追根究底的問題 
  •    當對有些問題不太了解時，以及想要了解更多更詳細的時候，就會使用（問答題，申論題） 
  •    不常使用

問題深入的程度共分為三個

  • High-level ： Very General - 非常一般性的問題 
  • Medium-level：Moderately Specific - 介於一般與精確之間 
  •  Low-level：Very Specific - 非常精確特定的問題

架構訪談問題的兩個方法

  • Top-Down：由上而下的問題問法，適用於大部份的受訪者 
  •  Bottom-Up：由下而上方法適用於兩種情況 
  • (1) 當分析者已經收集到很多資訊，只是需要再補一些沒有收集到的資料細節的時候
  • (2) 低階人員無法回答高層事情的時候

(3) Preparing for the Interview - 準備面談事宜

一般來說，通常結構性的面談（定好目的） ，會用封閉式的問題

(4) Conducting the Interview - 進行面談

將所有受訪者所提供的資訊紀錄下來
一定要問清楚不了解，聽不懂的內容，不要怕問笨問題
最後要分清楚什麼是事實，什麼是意見
要讓受訪者有自由表達的時間
要說明接下來的步驟，不可以輕易承諾有什麼功能，什麼時候完成
要感謝受訪者，讓受訪者感覺對系統有幫助

(5) Post-interview Follow-up - 面談後續行動

要完成 Interview Report （訪談報告）
把訪談報告送給受訪者做確認


正在閱讀（Interviews - 訪談）

On 沒有留言:
At：

Requirements-Gathering Techniques - 需求收集技術

需求分析包括

收集資料
資料分析 （第四章）

收集資料的五種方法


1. Interviews - 訪談（最常使用）

2. Joint Application Development (JAD) - JAD 會談 （聯合應用系統發展方法）

3. Questionnaires - 問卷調查

4. Document Analysis - 文件分析

5. Observation - 觀察法



On 沒有留言:
At：

2009年10月22日

Comparing Analysis Techniques - 比較分析策略

Potential Business Value - 潛在的商業價值

BPR > BPI > BPA

Project Cost - 計畫成本

BPR > BPI > BPA

Breadth of Analysis - 分析的幅度

BPR > BPI > BPA

Risk - 風險

BPR > BPI > BPA



On 沒有留言:
At：

BPR - Activity Elimination - 作業消除

定義：

找出多餘的活動或步驟，將之刪除，看看會有什麼影響

方法：

使用施壓配合的方式去測試所有的可能性

" force-fit " - 施壓配合

此為消極做法



On 沒有留言:
At：

BPR - Technology Analysis - 技術分析

定義：

在可用的新技術中找到可以為企業帶來利益的技術

做法：

列出一系列的新技術表單，包含重要的，和有利益的技術，然後一一分析，如果引用的話，可以為企業帶來什麼利益


On 沒有留言:
At：

BPR - Outcome Analysis - 結果分析

定義：

焦點在於提供價值給顧客的基本原則是什麼？包含明顯以及不明顯的

做法：

假裝是顧客，思考顧客所要的價值是什麼以及能為他們做什麼來提升價值




On 沒有留言:
At：

BPI - Informal Benchmarking - 非正式標竿法

先介紹標竿法


Benchmarking - 標竿法
定義：
找到榜樣，然後想辦法迎頭趕上

Informal Benchmarking - 
非正式標竿法

定義：
以企業管理角度：
  • 找非相同產業的標竿企業做比較

以系統分析角度：
  • 從顧客的角度來做標竿法

做法： 
假裝顧客，到選定的標竿企業拜訪，看他們是如何做的（偷學）




On 沒有留言:
At：

BPI - Activity-Based Costing - ABC 分析

定義：

以成本為單位，做流程的動作分析

做法：

(1) 計算流程中每一個步驟要多少成本
(2) 同時考慮直接和間接成本
(3) 將焦點放在最花錢的步驟，然後去改善它

「效益」提升 



On 沒有留言:
At：

BPI - Duration Analysis - 時間分析

定義：

仔細檢查舊資訊系統中每一段流程所需的時間
以時間為單位，做流程的動作分析

做法：

步驟整合（減少不必要多餘的動作）
步驟並行（同時處理）

「效率」提升



On 沒有留言:
At：

BPA - Root Cause Analysis(RCA) - 根本原因分析

定義：

將焦點放在問題，而不是解決方法，請使用者將舊資訊系統的問題列出來，並依重要性排列，然後針對最重要的問題，將其所有可能的根本原因列出來

以倒推方式找出問題所在以改善系統

又稱回溯性成因分析

Ex：






On 沒有留言:
At：

BPA - Problem Analysis - 問題分析

定義：

詢問使用者舊的資訊統有什麼問題，以及在新系統如何解決或改進這些問題

適用：

改善「系統效率」
以及「系統易用性」


正在閱讀（Problem Analysis - 問題分析 ）


On 沒有留言:
At：

系統分析策略 概觀

Business Process Automation (BPA) - 企業流程自動化


小的改變，追求「效率」
包含：

Business Process Improvement (BPI) - 企業流程改善

因為新的技術帶來新的機會
模仿競爭對手的行為
中等改變，追求「效率」與「效益」
包含：

Business Process Reengineering (BPR) - 企業流程再造

因為引進新的技術和科技，對組織做根本性的改變
根本性改變，從劇烈改變中獲得大的利益
包含：

On 沒有留言:
At：

System Analysis - 系統分析階段

The system development life cycle (SDLC) 的過程之一，讓組織
Moves From 
As-Is system - 舊系統（不一定電腦化）
To
To-Be system - 正打算要做的系統（基於現在的需求）
and Have
System Proposal - 系統計劃書（系統分析階段所要做出來的文件，就是系統計劃書）（用來表達系統需求是什麼）

什麼是需求！？

(1) 系統一定要做什麼

(2) 焦點：使用者需求什麼

(3) Change over time - 過段時間就改變需求

Functional Requirement - 功能性需求（與資訊處理相關的需求）

(1) 此系統應包含哪些流程

(2) 此系統應包含哪些資訊

Nonfunctional  Requirement - 非功能性需求

(1) Operational - 操作性

(2)  Performance - 效率

(3) Security - 安全性

(4) Cultural and Political - 文化和政治

Requirements Definition - 需求定義書 

用文字敘述來定義系統範圍

系統分析階段的三個步驟 

(1) Understand the "As-Is" system - 了解現在系統

(2) Identify improvement opportunities - 找出待改進的地方

(3) Develop the "To-Be" system concept - 定義新系統的需求


系統分析階段可採用的三種策略


節省人力，時間


 把有問題的或錯誤的流程進行改善


整個系統翻新重做 
可能與原本系統幾乎完全不同




On 沒有留言:
At：

2009年10月15日

Project Management - 專案管理

Case Tools

Computer-aided software engineering

是一種軟體，用來幫助系統開發過程可以自動化的軟體

* I - CASE ( Integrated - CASE ) 整合行系統開發輔助工具
        整合了： Upper - CASE （分析階段用的輔助工具）
                      Lower - CASE （設計階段用的輔助工具）



On 沒有留言:
At：
訂閱： 文章 (Atom)