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月30日

適合

雖然看見閃光還是會心痛。

只是

自由適合目前的自己

暫時不想跨入愛情的牢籠

甜蜜又具有負擔

只想跟朋友好好過

沒有胡思亂想

沒有歇斯底里

沒有暴躁易怒

沒有情緒擺盪

至少，現在的樣子，是我自己喜歡的樣子

已經，沒有期望

那種東西，不會存在我的世界

不是一種絕望

而是，路不通往那個方向


重視人生的人，生活比較複雜一點

重視生命的人，生活比較簡單一點

我想我是重視生命的人

不在乎成就，在乎束縛與自由

存在。就是生命的本質

我在尋求。存在

存在需要做些什麼，抑或不應該做些什麼

不重要。。

就依照內心反映的情感生活吧

只做。想做的事

讓自己。放蕩不羈

On 沒有留言:
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月27日

Rule

扮演自己的角色

如此，而已

人生正處於發現自己的階段

交雜樂觀與悲觀

交雜情感與理智

已經，不再單純了

不在。單純了

。＿。
On 沒有留言:
At：

2009年10月23日

Touch

因為人情

同一件事情

我們站在不同的角度

我的角度

我的觀點

我的想法

根據我的經歷


就像前任的前任

讓他傷的很深

就像前任

對我來說也是段不怎麼愉快的記憶

就是一股勁的

因為想要愛

因為想被愛

而互相傷害

不該這樣下去的


你會站在別人的角度

我的認知上，你就是個認真的人

在我遇過的人裡面

會這樣做的，都是認真的人

我也曾經想過你想過的

只是沒有這麼深入

因為我越想，越無法對自己解釋

是自己挖的坑，然後自己跳

是自己欺騙自己，然後再來嘲笑自己

直到自己說出的話，自己都無法承擔

所以我的立場很保留

對你很保留

我只能說我真正的感覺

其他的，我無能為力

我也承認我的無能，沒辦法走出來是我的懦弱

在愛裡我很認真

所以我向你坦承

過去還牽絆著我

因為我等待過，我也知道等待的感覺

我不想騙你，我不想讓你等

那太痛苦

別把自己困在愛情的小圈圈裡面


我說，你看

又有什麼意義，最後還是兩個認知不同的人在硬碰硬

你的固執，你的倔強

都有屬於你自己的理由

只是

別為了那理由把自己困住
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月21日

科技始終來至於人性

歷經了一段開始

才發現

自己開始害怕戀愛

平淡的結束

並不代表

一切都平淡帶過

多多少少了解你當時無法捨去的原因

卻無法原諒

那份自私與心態

這份矛盾要持續到什麼時候

無法敞開心懷的喜歡一個人

深深害怕陷入愛情的感覺

我得想想

我要的

是什麼



謝謝/抱歉 小雷

你為我帶來了很多

我卻什麼也沒辦法給你
On 沒有留言:
At：

2009年10月15日

Project Management - 專案管理

Case Tools

Computer-aided software engineering

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

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



On 沒有留言:
At：

Criteria for Selecting a Methodology - 選擇開發模型的標準

選擇開發模型的標準

(1) Clarity of User Requirements - 清晰的使用者需求
(2) Familiarity with Technology - 使用技術的嫻熟
(3) System Complexity -  系統複雜度
(4) System Reliability - 系統可靠度
(5) Short Time Schedules - 短暫的開發時程
(6) Schedules Visibility - 計畫表的可見度（計畫是否按照時程進行）



*1 系統分析與設計的同時，就要發展測試計畫，藉由每個階段的測試，獲得較高的系統可靠度
*2 藉由系統雛形做溝通，因此獲得較清楚的使用者需求
*3 因缺乏系統基礎性的考量 （Ex：系統架構，安全，控制上的考量）
*4 因最後會重新撰寫程式，較其他模型適合引進不成熟的技術
*5 系統建立之前，可確定問題，產生比較可靠的系統，而且不忽略基本的基礎架構，安全，控制的需求
*6 因最後需重新撰寫程式，因此耗時較多
*7 因此方法需要使用者，在發展系統時一起工作 ，因此獲得較清楚的使用者需求
*8 因其適用於小專案，複雜度通常不高
*9 因此方法需要使用者，在發展系統時一起工作，客戶需與程式設計師一起定義需求，測試，而這一點常常很難遵守



On 沒有留言:
At：

Extreme programming(XP) - 終極程式


定義：

強調使用者滿意，分工合作
XP 的核心價值：溝通，簡化，回饋，勇氣
三個進行步驟
      (1) 做出 User Stories （使用者故事：用來描述系統該如何做）
      (2) Coding （寫程式）
      (3) Test （測試）
適用小專案（程式設計師 10 人以內）
最後整合所有小系統 -> 完成
沒有回溯線

優點：

XP projects deliver results sooner than even the RAD approaches
比 RAD 的方法更快能產生系統

缺點：

1.  It is not advised for mission-critical
重要的資訊系統多會長時間使用，因此使用 XP 方法的效用受到質疑


2. Since little analysis and design documentation is produced with XP, there is only code documentation
在分析與設計階段，使用 XP 方法，產生的文件很少，只有程式文件而已，因此要維護 XP 所建構的資訊系統幾乎不可能


3. Methodology requires considerable on-site user input, something that is frequently difficult to obtain
此方法需要使用者，在發展系統時一起工作
(1) 定義需求
(2) 客戶測試
這一點常常很難遵守



On 沒有留言:
At：

Throwaway Prototyping - 丟棄雛形法


定義：

當用來做系統雛形的軟體與最系統完成的軟體不一樣時，就要用丟棄雛形法
多了一個整體性分析與整體性的設計可以兼顧系統基礎架構，安全，控制上的問題
Design Prototype 只是一個工作系統而不是最後可執行的系統
此系統雛形可能有很多個（子系統），此多個系統雛形的目的除了與使用者溝通外，主要目的是用來降低風險（確保使用者的需求有被執行）

優點：

1. Using prototypes to refine key issues before a system is built
系統建立之前，可確定問題，產生比較可靠的系統


2. 不忽略基本的基礎架構，安全，控制的需求

缺點：

It may take longer to deliver the final system compared with system prototyping
會比雛形法花更多的時間（因為要做整體性的分析與設計，而且要重新撰寫程式，所以花費較多間）



On 沒有留言:
At：

System Prototyping - 雛形法


定義：

透過系統雛形使使用者初步了解系統
透過軟體工具的幫忙，讓系統分析師與使用者可以在系統分析與設計階段，藉由系統雛形做溝通，以便直接快速的了解使用者的需求
最後的系統是由系統雛形直接寫程式產生的
System Prototype 與 System 的系統軟體通常差不多

優點：

1. Very quickly provides a system for users to evaluate
使用者可以很快拿到一個可以評估的系統，透過此系統雛形使用者可以了解此系統是否為需要的，以便做修正


2. Reassures users that progress is being made
讓使用者可以放心，系統是根據其意見來做改進的

缺點：

1. Is the lack of careful, methodical analysis prior to making design and implementation decisions
缺少系統化的方法來進行分析工作


2. Fundamental deign limitations that are a direct result of an inadequate understanding of the system's true requirements early in the project
缺乏系統基礎性的考量（Ex：系統架構，安全，控制上的考量）



On 1 則留言:
At：

2009年10月9日

。 & Free Life

&


Free


Life
On 沒有留言:
At：

2009年10月8日

Iterative Development - 反覆式開發法


定義：

Version 可直接給使用者測試，系統可先上線
功能累加 Version 1 （基本基礎功能） -> Version 2 （功能增加） -> Version 3 （功能完整）
外面的整合分析階段，要分析出哪些是基本需求，以便在第一個版本中包含進去
第一個版本的系統要包含最重要及最基本的需求

優點：

1. To the user quickly so that business value is provided
使用者可以比較快速拿到一個可用的系統


2. Since user are working with the system, important additional requirements may be identified and incorporated into subsequent versions
使用者比較容易找到額外的重要需求，以便在下一個版本中實現

缺點：

1. The chief disadvantage of iterative development is that users begin to work with a system that is intentionally incomplete
使用者在中間階段拿到的不是完整的系統


2. Most critical requirements of the system will be available in the early versions and must be patient with the repeated introduction of new system versions
如果不能在第一版本中包含最基本與最重要的功能，系統會發生問題



On 沒有留言:
At：

V-model - 軟體測試管理模型


定義：

以程式設計為主的方法
主張在系統分析與設計的同時，就要發展測試計畫
每個階段要產生可接受的測試設計
因為沒有 planning 而被視為軟體測試管理模型，而非一個系統開發模型
在台灣，一般是大型專案會用 V-model 來作系統的驗證與確認
為了解決 Waterfall 到很晚才發現錯誤而又很難回溯解決的問題

優點：

1. The V-model is simple and straightforward
簡單易懂


2. Improves the overall quality of systems through its emphasis on early development of test plans
因為在較早時點（系統分析階段）就引進測試計畫，所以可以改善系統品質（其他是系統程式設計完成時才做測試計畫）

缺點：

1. It's still suffers from the rigidity of the waterfall development process
還是有 Waterfall 方法死板的問題（不太允許回溯）


2. Is not always appropriate for the dynamic nature of the business environment
並不能完全適用於變化莫測的企業環境

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