Transcript Chapter 5 Instructor Slides

Systems Analysis & Design
5th Edition
第5章
開發策略
學習目標
● 描述軟體發展趨勢，包括視軟體為一種服務的
觀念
● 解說軟體取得的替代方案，包括傳統以及以網
站為基礎的軟體開發策略
● 描述軟體委外的選擇，包括服務供應商的角色
● 解說在公司內自行開發軟體相較於其他替代方
案的優缺點
2
學習目標
● 解說成本效益分析及財務分析工具
● 解說建議書要約 (RFP) 與報價要約 (RFQ) 之間
的區別
● 描述系統需求文件的內容
3
學習目標
● 解說從系統分析到系統設計的過渡期以及邏
輯模型與實體模型之間的差異
● 解說過渡到系統設計及建立雛型的重要性
● 討論系統設計的準則並解說適切運用代碼的
重要性
4
簡
介
● 第五章則描述系統分析階段剩餘的一些活動
● 包括了評估替代的解決方案、準備系統需求
文件，以及向管理當局簡報系統需求文件
● 本章同時描述了如何過渡到系統設計、雛型
的建立、設計指導方針，以及使用代碼來表
示數值及簡化資料登錄
5
開發策略概述
● 選擇最佳的開發方式是一個重要的決策，因
此需要公司考量三個關鍵議題
– Web 為基礎的軟體趨勢
– 軟體委外的各種選擇
– 內部自行開發軟體的替代方案
6
WEB 為基礎的軟體趨勢
● Internet 已經引發企業營運方式及操作的重
大改變，而軟體的取得也不例外
● 本節討論視軟體為一種服務的趨勢、改變中
的軟體市場，以及 Web (網站) 為基礎的開
發方式與傳統方式的比較
7
WEB 為基礎的軟體趨勢
● 軟體是一種服務
– 軟體及資訊產業協會 (SIIA, Software and
Information Industry Association) 是一個以數位
經濟為主的產業團體
– SIIA 相信「軟體是一種服務」的觀念正重新定義
公司開發及部署其資訊系統的方式
8
WEB 為基礎的軟體趨勢
● 改變中的軟體市場
– 在傳統模式中，軟體廠商開發應用套裝軟體再銷
售給客戶
– 除了傳統廠商之外，市場上目前也包括許多委外
的形式，其中包括了應用系統服務供應商及提供
網際網路業務服務的公司
9
WEB 為基礎的軟體趨勢
● 網際網路對系統開發的衝擊
– 開發者將轉而著重在Web為基礎的應用系統開發
(Web-based application development) ，其中會將
全球資訊網建入應用系統中，而不是以其他的方
式
– 兩個以 Web 為基礎的開發環境是
• IBM 的 WebSphere
• Microsoft 的 .NET
10
WEB 為基礎的軟體趨勢
● 網際網路對系統開發的衝擊
– 傳統開發方式
• 系統設計受到相容性議題
• 系統被設計在區域或廣域的公司網路上執行
• 系統經常利用 Internet 連結和資源，但是以 Web 為基礎
的功能被視為功能的加強而不是設計的核心元件。
11
WEB 為基礎的軟體趨勢
● 網際網路對系統開發的衝擊
– Web為基礎的開發方式
• 系統是在一個以 Internet 為基礎的架構，如 .NET 或
WebSphere，之下開發並交付
• 以 Internet 為基礎的開發方式以 Web 為平台，而不只是
一個通訊頻道
• 以 Web 為基礎的軟體通常需要額外的一層，稱為中間體
(middleware) ，來與現有的軟體及老舊系統溝通
12
軟體委外的選擇
● 委外 (Outsourcing) 是指將資訊系統的開發、運
行，或維護以支付費用的方式暫時或長期地轉
移給提供這些服務的公司
● 委外可以是小規模的程式撰寫，也可以是從服
務供應商租用軟體，或是處理公司全部的 IT 功
能
13
軟體委外的選擇
● 委外的成長
– 傳統上，公司把 IT 業務委外當作是控制成本及
對付科技快速變化的方法
– 今日，委外成了形塑企業整體 IT 策略的重大事
項
– 最重要的因素是節省營運成本的潛力
14
軟體委外的選擇
● 委外的成長
– 一個提供委外解決方案的公司被稱為服務供應商
(service provider)
– 應用系統服務供應商 (ASP, application service
provider)
– 網際網路業務服務業者(IBS, Internet business
services)
• 亦稱代管服務 (managed hosting)
15
軟體委外的選擇
● 委外費用
– 各種費用結構目前有幾種模式，包括固定費用、
預訂費，及使用量或交易件數
• 固定費用模式 (fixed fee model) 採用一套基於特定服務或
使用者支援水準的費用組合
• 預訂費模式 (subscription model) 有一套基於取用該應用軟
體的使用者或工作站數量而有不同的費用
• 使用量模式 (usage model) 或交易件數模式 (transaction
model) 基於交易件數或該應用軟體所執行的操作量而收
取不同的費用
16
軟體委外的選擇
● 委外應考量的事項及疑慮
– 重大任務的 IT 系統只有在其結果是符合公司長
期經營策略，其有成本優勢、可靠的解決方案時
才可委外
– 委外也會影響日常公司運作而會引發一些疑慮
17
軟體委外的選擇
● 委外應考量的事項及疑慮
– 一個公司必須對委外小心規劃以避免損失收益、
增加費用，及潛藏的爭訟
– 此種解決方案所能達到的也完全受限於提供該項
服務的委外廠商
– 對於那些業務量起伏大的公司委外是一項吸引人
的選擇
– 委外主要的一項缺點是它會提高員工對工作保障
的疑慮
18
自建軟體開發選擇
● 公司可以選擇自行開發一套系統、或購買、也
可能修改，或建置套裝軟體
● 最主要的考量是總取得成本 (TCO) 的觀念
● 公司也可以使用各種隨處可得的商業套裝軟體
19
自建軟體開發選擇
● 自製或購買的決定
– 在決定自行開發或是購買軟體之間的抉擇經常被
稱為自製或購買 (make or buy，或是build or
buy) 的決定
– 所謂自製就是由公司的 IT 部門負責建一套或做
一套自建軟體 (in-house software)
– 所謂的購買套裝軟體 (software package) 則是由
某個廠商或 ASP 取得
20
自建軟體開發選擇
● 自製或購買的決定
– 開發軟體販賣的公司則被稱為軟體廠商
(software vendors)
– 附加價值零售商 (VAR, value-added reseller)
– 縱向應用軟體 (vertical application)
– 橫向應用軟體 (horizontal application)
21
自建軟體開發選擇
● 自行開發軟體
–
–
–
–
–
滿足企業的特殊需求
儘可能降低企業程序及政策的改變
為了順應現有系統的限制
為了順應目前科技的限制
為了發展內部資源和能力
22
自建軟體開發選擇
● 購買套裝軟體
–
–
–
–
–
–
成本較低
建置時間較短
經過驗證的可靠性和績效標竿
需要的技術開發人員較少
由供應商提供未來的升級
能夠利用那些已採用該系統的公司做借鏡
23
自建軟體開發選擇
● 修改套裝軟體
你可以購買一個廠商願意為你客製化，以符合你
的需求的基本套裝
2. 你可以直接與軟體供應商洽談。支付額外的費用
，要求他們做一些加強來滿足你的需求
3. 你可以購買套裝軟體自行修改
1.
24
自建軟體開發選擇
● 建立使用者應用軟體
– 使用者應用軟體 (user application) 是利用標準的
商用軟體
– 求助專櫃 (help desk) ，或資訊中心 (IC,
information center)
– 螢幕產生器 (screen generator)
– 報表產生器 (report generator)
– 唯讀的 (read-only properties)
25
系統分析師的角色
● 在選擇硬體及軟體時，系統分析師常常擔任
評選小組 (evaluation and selection team) 的
成員
● 以小組的方式保證不致忽略一些關鍵因素，
而能夠做出周延的選擇
26
系統分析師的角色
● 評選小組的主要任務是排除那些不會成功的
方案，把可行的方案做評比排列，然後將最
後幾項重要的方案呈給管理當局做最後的裁
定
27
成本效益分析
● 財務分析工具
– 回收分析 (payback analysis)
– 投資報酬率 (ROI)
– 淨現值 (NPV) 、
28
成本效益分析
● 成本效益分析查核清單
– 列出每個考慮過的開發策略。
– 指出每個方案的所有成本和效益。要確實指出每個
成本將發生及每個效益會實現的時間。
– 考量未來成長及對規模彈性的需求。
– 包含對硬體及軟體的支援成本。
29
成本效益分析
● 成本效益分析查核清單
– 分析各種軟體授權的選項，包括固定費用及以使
用者數量或交易量為基礎的計算公式。
– 將財務分析工具應用在每一個方案。
– 研究其結果並準備向管理當局做報告。
30
獲取軟體的例子
● 步驟1：評估資訊系統需求
–
–
–
–
–
–
指出系統的關鍵性能
考量網路及網站相關事宜
估計工作量及未來的成長
詳細說明任何硬體，軟體、及人員限制
準備一份建議書要約 (RFP) 或報價要約 (RFQ)
Prepare a request for proposal or quotation
• 建議書要約 (RFP, request for proposal)
• 評估模式 (evaluation model)
• 報價要約 (RFQ, request for quotation)
31
獲取軟體的例子
● 步驟2：指認可能的廠商或委外選擇
– Internet 是所有 IT 產品和服務的主要市集
– 另一種方法是與顧問公司合作
– 另外一個有用的資源是 Internet 上的 BBS，其中
有數千個討論區，叫做新聞群組 (newsgroups)
32
獲取軟體的例子
● 步驟3：評估各替代方案
–
–
–
–
現有使用者
試用
標竿測試
把每一種套裝軟體與 RFP 性能逐項比對而排列
出可選擇的項目
33
獲取軟體的例子
● 步驟4：進行成本效益分析
– 為你考量的每種選項指出並計算 TCO
– 當你購買軟體時，通常並不是擁有它──你所購
買的只是軟體使用執照 (software license)
– 如果你購買套裝軟體，你應該考慮制定維護合約
(maintenance agreement)
34
獲取軟體的例子
● 步驟5：準備一份建議
– 你應該準備一份建議書，其中包括你的建議並列
出各種替代方案和其成本、效益、優點，及缺點
– 在此時，你或許需要交一份正式的系統需求文件
並做簡報
35
獲取軟體的例子
● 步驟6：執行解決方案
– 實際執行的工作視你選擇的解決方案而定
– 在新軟體運行之前，你必須完成所有建置步驟，
包括軟體的載入、設定，及測試；使用者培訓；
並且把資料檔案轉換成為新系統的格式
36
完成系統分析的工作
● 系統需求文件 (system requirements
document)
– 系統需求文件 (system requirements document)
或稱軟體需求規格 (software requirements
specification) ，其中包括對新系統的需求、說明
曾經考慮過的方案，並向管理當局做出明確的建
議
– 就好像是一個合同
– 以使用者能夠了解的語言來撰寫，使得他們能夠
提出意見、建議一些改進，並認可最後的版本
37
完成系統分析的工作
● 向管理當局簡報
– 簡報一開始先簡要概述系統專案的目的和主要目
標
– 彙整主要的可行方案。對於每一個方案，說明其
成本、優點和缺點。
38
完成系統分析的工作
● 向管理當局簡報
– 解釋評選小組為什麼選擇所推薦的方案。
– 預留討論和提出問題及答覆的時間。
– 取得管理當局的最後決定，或核准這個發展過程
中下一個步驟的時間表
39
完成系統分析的工作
● 向管理當局簡報
•
對管理當局做簡報的目的，是取得對系統開發
的批准，並得到管理當局的充分支援，其中包
括所需的財務資源。管理當局可能選擇以下五
種方案之一：
1.
2.
3.
4.
5.
開發內部系統
修改現有系統
購買或訂製套裝軟體
進行其他系統分析工作
完全停止進一步的工作
40
過渡到系統設計
● 如果管理當局決定自行開發這個系統，那麼
就可以開始過渡到系統設計階段
● 準備各項系統設計工作
– 當系統設計開始時，你必須擁有準確且易於了解
的系統需求文件
41
過渡到系統設計
● 邏輯與實體設計間的關聯性
– 邏輯設計 (logical design) 定義出系統的功能及特
色以及其元件之間的關係
– 相對於邏輯設計，一個資訊系統的實體設計
(physical design) 是實際建置該系統的計畫
42
系統設計準則
● 分析師在開始任何一個成分的實體設計之前
，必須了解整個系統的邏輯設計
– 資料設計
– 使用者介面
– 系統設計規格
43
系統設計準則
● 系統設計的目標
– 系統設計 (systems design) 的目標是建立一個有
效益、可靠，而且易於維護的系統
– 如果系統能夠適當地處理各種錯誤，那它就是可
靠的
– 如果系統設計良好，有彈性，並且在開發時考慮
到了未來的修改，它就是一個易於維護的系統
44
系統設計準則
● 系統設計 (systems design) 的目標
– 使用者考量
• 仔細考慮任何一個使用者從系統中得到輸出，或向系
統輸入的發生點
• 預計使用者、系統，和組織未來的需求
• 提供彈性
• 參數 (parameter) 預設值 (default)
– 資料考量
• 資料應當在它產生的地點即刻輸入系統，因為遲延會
引起資料的錯誤
• 資料應該在輸入時即刻核驗，以便立即發現錯誤
45
系統設計準則
● 系統設計 (systems design) 的目標
– 資料考量
• 儘可能採用自動化的資料輸入方法
• 存取資料項目應當受到控制，對重要資料值的所有輸入
和變更，都應當提出報告 -- 稽核軌跡 (audit trails)
• 應當記錄每一次資料的輸入與改變
• 資料應當只輸入系統一次
• 應當避免資料的重複
46
系統設計準則
● 系統設計 (systems design) 的目標
– 架構考量
• 使用模組化設計
• 設計執行單一功能的模組較容易了解、建置，及維護
47
系統設計準則
● 設計上的取捨
– 設計目標經常互相衝突
– 大多數你將面對的設計取捨決策，都能夠歸納為
品質與成本之間的基本衝突
– 避免那些將會產生短期節省，但是可能意味著以
後較高成本的決定
48
建立雛型 (prototyping)
● 雛型的建立是在開發初期對所提議的資訊系
統以快速的方法建立的一個可運作的版本，
稱為雛型 (prototype)
● 雛型的建立允許使用者檢視一個能夠正確地
展示出系統輸出、輸入、介面，及處理工作
的模型
49
建立雛型 (prototyping)
● 雛型建立方法
–系統式雛型建立 (system prototyping)
–設計式雛型建立 (design prototyping)
–拋棄式雛型建立 (throwaway prototyping)
50
建立雛型 (prototyping)
● 雛型建立方法
– 雛型的建立有許多優點
• 可避免使用者與系統開發人員的誤會
• 經理人可以比用紙張書寫的規格更有效地經由可運作
的模型來評估
– 也該留意以下潛在的問題
• 發展的速度快，可能會產生品質上的問題，而這些問
題往往要到完成的系統開始運作之後才被發現
• 對於非常複雜的系統，雛型會變得無法掌握而且難以
管理
51
建立雛型 (prototyping)
● 雛型建立的各種工具
– 系統分析師可以利用各種強而有力的工具來產生
雛型
•
•
•
•
•
CASE 工具
應用系統產生器
報表產生器
螢幕畫面產生器
第四代語言 (4GL, fourth-generation languages)
52
建立雛型 (prototyping)
● 雛型的限制
– 雛型只是能運作的系統，但其工作效率遠低於完
全開發的系統
– 系統開發人員還是可以藉由加入必須的功能將雛
型提升為最後完整的資訊系統
– 否則，雛型就可以拾棄
53
建立雛型 (prototyping)
● 其他模型建立的工具
– 系統流程圖 (system flowchart)
– 美國國家標準局 (ANSI, American National
Standard Institute)
54
在系統設計時使用代碼
● 代碼的概述
– 因為代碼常常用來代表資料，你在日常生活中經
常看到它們
– 它們能夠節省儲存空間和成本，減少資料傳輸的
時間，縮短資料輸入的時間
– 能減少資料輸入的錯誤
55
在系統設計時使用代碼
● 代碼類型
1. 順序代碼 (sequence codes)
2. 分段順序代碼 (block sequence codes)
3. 字母代碼 (alphabetic codes)
a. 分類代碼 (category codes)
b. 縮寫代碼 (abbreviation codes)
56
在系統設計時使用代碼
● 代碼類型
–
–
–
–
–
有意義的數字代碼 (significant digit codes)
推導代碼 (derivation codes)
加密代碼 (cipher codes)
行動代碼 (action codes)
自核代碼 (self-checking codes)
57
在系統設計時使用代碼
● 發展一套代碼
1.
2.
3.
4.
5.
6.
使代碼簡明
允許擴充
保持代碼穩定
編寫獨特的代碼
採用可排序 (sortable) 的代碼
避免代碼混淆
58
在系統設計時使用代碼
● 發展一套代碼
7. 使代碼有意義
8. 使用單一用途的代碼
9. 保持代碼的一致性
59
本章總結
● 本章敘述了系統開發的各種策略、系統需求文
件的準備和向管理當局簡報，以及過渡到
SDLC的系統設計階段
● 一個重要的趨勢將軟體看待成一種服務而不是
一種產品，這產生了新的軟體取得的選擇
● 系統分析師必須考量一些以網站為基礎的開發
環境
60
本章總結
● 系統分析師在軟體開發過程的角色視各種開發
策略而定
● 選擇開發策略的最重要因素是總取得成本
(TCO)
● 取得軟體的過程包含一系列的步驟
– 評估系統需求、考量網路及Web相關議題、指認可
能的軟體廠商或委外選擇，評估各替代方案、執行
成本效益分析、準備建議書、及實作解決方案
61