第十三章 資訊管理的系統開發觀點

1. 第十三章　資訊管理的系統開發觀點

2. 本章大綱 • 13.1 資訊系統不同的開發方法 • 13.2 系統開發生命週期法與雛型開發法 • 13.3 快速的系統開發法：RAD、CBD與Web Service • 13.4 使用者自建系統與Enterprise 2.0 • 13.5 資訊系統的委外分析 • 13.6 資訊系統的租用與採購 • 13.7 CMMI：軟體開發能力與成熟度模式

3. 資訊系統不同的開發方法 • 至於是由組織內部開發或組織外部獲取？則需考慮企業所面臨的情形，簡單的說，例如： • 外部獲取vs.內部開發：若不是企業的策略核心、沒有機密性，且企業的資訊資源缺乏或不足以自行開發系統時，就可選擇組織外部的委外方案或直接購買市面上已有的套裝軟體。 • SDLC vs. Prototype：組織內部開發有許多不同的方法，若系統需設計嚴謹、規模龐大或效率(Efficiency)要求很高時，則可採用SDLC的方法。 • 資訊部門vs.使用者：如僅支援個人使用、規模較小的系統，因系統發展容易，而且使用者亦最容易瞭解自身需求，因此可採用使用者自建系統(EUC)，或讓使用者創意自由的應用Web 2.0。

4. 圖13-1 IS主要不同的獲取方法

5. 系統開發生命週期法與雛型開發法(1/9) • SDLC的分析 • SDLC方法論的主要特色 • 整個生命週期的階段定義分明 • 原則上，前一階段完成後，方能開始下一階段的工作，所以亦稱作瀑布模式，取義自瀑布一層一層流下的概念，而雛型開發法則無明顯的階段劃分。

6. 系統開發生命週期法與雛型開發法(2/9) • SDLC的主要步驟

7. 系統開發生命週期法與雛型開發法(3/9) • 三種主要測試方法，說明如下： • 單元測試：或稱程式測試，其主要目的是在測試組成一個資訊系統的眾多程式或模組單元其「本身」內部運算是否正確。 • 系統測試：其主要目的是在測試把所有的程式（模組）整合起來以後，整個系統是否如預期的運作，因為每個單元正確，如果彼此呼叫啟動、傳遞資訊、協調配合不對的話，系統仍然會有問題，此方面的測試準則包括：反應時間快慢、處理尖峰負載的容量大小、回覆機制、重新啟動及人工配合系統的程序等。 • 接受測試：技術面的測試結束後，接著就是由使用單位來測試此系統合不合乎其實際的使用需求，並由管理單位來審查，因為系統最終還是在支援使用者。

8. 系統開發生命週期法與雛型開發法(4/9) • 系統導入(System Implementation) • 直接法：決定在某個時點開始啟用新系統、停用舊系統，兩個系統沒有重疊，優點是成本最省，缺點是如果新系統出問題並無其他替代方案，風險最高。 • 平行法：為目前使用最多的方法，例如3個月內新舊系統平行使用，避免直接法的缺點。但成本最高，使用者要同時使用兩套系統來處理交易。 • 階段性轉換：此法指的是針對系統內的某部分功能（例如：訂單功能）先進行轉換，穩定以後在逐步擴大到其他功能。 • 漸進法：例如剛開始交易量的30%使用新系統，70%使用舊系統；在穩定後調為50%、50%；最後完全穩定後，才100%使用新系統。

9. 系統開發生命週期法與雛型開發法(5/9) • 先導性研究法：先選擇由一個部門，或其中一家分公司執行，可避免在全面使用、系統不穩定所造成的損失。 • 以上方法各有優缺點，視系統對營運的關鍵性、時間的急迫性、系統的複雜度、新穎性、風險性以及轉換成本高低的不同因素而定。 • SDLC的優缺點 • SDLC的主要優點 • 嚴謹的專案與資源的管理，清楚的里程碑與系統文件，較周全的系統分析與設計，較完整的系統測試規劃，開發的系統效率、可靠度、穩定度與安全性較高。

10. 系統開發生命週期法與雛型開發法(6/9) • SDLC的主要缺點 • 發展時間冗長、使用者參與程度少、SDLC的前段沒有實際的系統雛型可供使用者試驗學習來釐清瞭解其真正的需求、使用者測試評估僅在資訊系統上線的最後階段，錯誤發現太晚、修改成本太高。 • SDLC進行的時機 • 當組織所需要的是大型且複雜的IS時，此時需要對作業流程進行嚴謹的規劃、分析，因此適合用SDLC來進行開發。除此之外，若系統本身傾向結構化，或是系統運作時注重效率、處理的交易量大（如公司基本的交易處理系統），並且對品質管制及系統正確性、穩定度、安全性要求高時，SDLC開發方式亦是最好的選擇。

11. 系統開發生命週期法與雛型開發法(7/9) • 雛型開發法

12. 系統開發生命週期法與雛型開發法(8/9) • 雛型開發法的主要特點與優勢 • 快速驗證需求 • 利用實際IS來掌握需求 • 使用者參與高 • 可早期發現錯誤 • 重複發展彈性高 • 實做中學習、接受程度高

13. 系統開發生命週期法與雛型開發法(9/9) • 雛型開發法的缺點 • 嚴謹度不夠 • 文件不完備 • 太早交貨的問題 • 觀念的抗拒 • 雛型開發法的適用時機 • 資訊需求不清楚：當問題本身、使用者、開發人員、系統及外部環境等因素造成資訊需求不明確時 • 對使用者需求必須檢定(Validation)：當高成本系統、高風險系統及新科技應用下，無法在真正投資後才發現不可行，此時應使用Prototype。

14. 快速的系統開發法：RAD、CBD與Web Service(1/5) • 快速應用系統開發法(RAD) • 是指企業利用物件導向的工具，以及所謂非程序導向的第四代語言，例如報表產生器等，藉由Prototype的方式，以便不斷地與使用者互動，接續地測試各種主要功能的雛型，接著再運用電腦輔助軟體工程(CASE Tool)的程式產生器自動的依據需求規格，產生程式碼來快速的建構資訊系統。 • 元件為基礎的開發方法(CBD) • 是指一種經由快速組合各種可重複使用的物件模組來整合成一個新的、獨特的應用系統，例如整合使用者互動介面、訂單等多個物件模組而形成一個簡單的交易處理系統，此外如在EC上整合產品目錄、購物車等物件而建構一個EC上的銷售系統。

15. 快速的系統開發法：RAD、CBD與Web Service(2/5) • Web Service的基本概念 • Web Service是CBD概念的延伸，也是能實際支援CBD的一個架構標準。即：資訊系統的模組化、再利用化、互相操作性、整合化及平台與語言的獨立化這些資訊系統的特性。 • Web Service的基本定義 • 是指「一個能在Web環境上，讓各種不同的平台與程式語言的軟體元件，能彈性、動態地快速整合、彼此互通、呼叫的一種開放性的結構與標準。」

16. 快速的系統開發法：RAD、CBD與Web Service(3/5) • Web Service的主要標準與架構 • XML：可延伸標記語言(XML)是一種通用、標準的資料結構描述語言，透過這種標準，各種不同的程式間彼此可快速地溝通、傳遞、交換與解讀這些標準化的資料，而不需經過轉換。 • UDDI：此為提供一個註冊與搜尋Web Service資訊的一個標準，Web Service的提供者可在UDDI上註冊，並以XML的格式描述其企業、產業別及所提供軟體物件的技術資訊。 • WSDL：此標準亦即利用一個XML的文件來描述Web Service上各軟體元件所能執行的功能，並定義使用這些功能的程式介面，讓需求者讀取、瞭解並使用這些服務。 • SOAP：此為一種在網路上交換結構化資訊的簡易通訊協定，其描述了軟體間彼此如何傳遞訊息，為一種跨平台的標準。

17. 快速的系統開發法：RAD、CBD與Web Service(4/5) • Web Service標準協定的架構與互動流程

18. 快速的系統開發法：RAD、CBD與Web Service(5/5) • Web Service的主要問題 • Web Service目前仍存在安全上的問題 • 由於Web Service能讓訊息的傳遞穿透防火牆，且UDDI、WSDL、SOAP等標準皆未包含安全的機制，因此在此開放性的環境下，Web Service的安全性仍是個問題。 • 高階的資料標準仍未建立 • 雖然XML定義了標準的基本資料格式，但B2B間高階的資訊標準仍未建立，例如銀行與銀行間所傳遞的文件，其標準的格式與所應包含的內容、標準，仍未普遍建立，這也是為何Web Service大都運用在企業內部，而未普及為跨組織間B2B運用的主要原因。

19. 使用者自建系統與Enterprise 2.0(1/3) • Web Service雖有上述的問題，但不可否認的，其是AP開發的新典範，目前主要的軟體廠商無不大力提倡及支援Web Service，例如微軟的.NET平台，Java集團的J2EE開發平台，都內建了支援Web Service的架構與工具。 • 使用者自建系統 • 是指「使用者自行利用易學、容易上手的軟體（例如4GL），由資訊人員扮演支援協助的角色，進行開發、維護自己所需要的應用程式。」例如使用者利用Excel自行開發顧客帳戶管理系統，此法的優點在於使用者自己開發系統因此沒有溝通問題、沒有抗拒問題、降低MIS負擔、提升創意、沒有等待的問題。缺點在於系統沒有文件、品質不良、沒有安全控管、無法整合、很難維護與重複開發、浪費資源等。

20. 使用者自建系統與Enterprise 2.0(2/3) • 企業2.0：Web 2.0在企業內部的應用 • 如前所述Web 2.0是目前一般網民應用得很普遍的工具，當然其有很大的潛力可利用在企業內部，此方面的應用稱之為企業2.0(Enterprise 2.0)。 • 此方面的研究首推McAfee(2006)所推出的企業2.0的架構，其提出一個稱之為SLATES的架構來建議Enterprise 2.0所需的六個主要科技特性，簡介如圖13-5： • 搜尋：Enterprise 2.0上必須具備有良好的搜尋功能，例如在平台上運用Google的關鍵字搜尋與Page Rank的方式以網頁的鏈結數來排列搜尋結果的重要性與相關性，以此科技來支援員工更有效的搜尋資訊與知識。

21. 使用者自建系統與Enterprise 2.0(3/3) • 鏈結：Intranet內應該開放給員工建立鏈結的權利，如此將使企業網站透過更多的鏈結，形成更豐富複雜的人際網路與知識網路，產生更多的價值。 • 發表：企業內部要推展Blog與Wiki的觀念，提供員工方便的工具來發表自己獨特的見解、經驗、知識。 • 標籤：透過員工Tags的自創與分享，員工除可方便的整理、組織自己的知識，另可透過別人相關的Tag來搜尋、探索新的相關知識，串連新的社群，延伸自己知識不足的部分。 • 延伸：員工除了Tags外可透過例如Amazon內的讀者評論、協同過濾等機制，可獲得相同興趣的員工對這個相關領域知識的評價與新知識的推薦來延伸自己知識的領域與廣度。 • 訊息：員工還可透過RSS的機制，自動的來獲取其有興趣的新資訊。

22. 圖13-5 企業2.0的SLATES的架構

23. 資訊系統的委外分析(1/6) • 資訊系統委外的基本概念 • 基本上指的是「企業把部分或全部的資訊系統功能，以契約的方式委託外部的資訊系統供應商來發展、管理或提供」。一般而言根據資策會的歸類，主要包括軟體開發與維護、企業整體資訊規劃、網路服務、資訊設施管理、資料登錄與處理、系統整合、資料庫建置、顧問諮詢、訓練推廣、系統稽核、軟體驗證。幾乎MIS任何的功能都可以委外給供應商，只是企業要依自己不同的需求來做選擇。

24. 資訊系統的委外分析(2/6) • 委外的優點 • 資源與能力方面 • 核心能力的專注 • 提升IS的品質 • 解決資源不足的問題 • 成本與風險方面 • 形成經濟規模 • 減低投資風險 • 產生節約意識，避免不必要的花費 • 減少長期資本投資

25. 資訊系統的委外分析(3/6) • 委外的缺點 • 內部知識與能力方面 • 打擊員工士氣 • 阻礙內部的科技升級及組織學習 • 失去自主能力，易受委外承包商控制 • 彈性應變能力較弱 • 委外承包商品質與能力方面 • 委外承包商對企業策略機密安全保護的問題 • 委外承包商的IT技術過時而沒有升級的風險

26. 資訊系統的委外分析(4/6) • 雙方的合作方面 • 需求溝通的問題 • 品質不確定性高 • 雙方文化、經營理念不契合的問題 • 委外的時機與範圍 • 當系統具備下列特性時，較不適合委外，包括：(1)競爭優勢的核心能力；(2)高專屬性與獨特性；(3)高策略機密性；(4)高交易成本與不確定性。 • 美國主要的IS委外項目，大都集中於一般低競爭優勢、低策略性、低不確定性、低獨特性、高成熟、高標準化、高安全性、高開發穩定性的資訊系統。

27. 資訊系統的委外分析(5/6) • 委外的關鍵成功因素

28. 資訊系統的委外分析(6/6) • 委外承包商的選擇

29. 資訊系統的租用與採購 • 資訊系統的租用：ASP • 電子化委外，亦可稱作應用軟體租賃(ASP)，指的是「透過網路，業者集中管理應用軟體，並以租賃的方式提供承租者軟體服務」。基本上，其與傳統的委外有下列特性上的不同： • 服務標的物只限是應用軟體，而非硬體設備與人力資源。 • 服務方式為租賃非購買。 • 透過Internet傳送。 • 標準套裝化。 • 委外的經營模式為一對多。 • 軟體管理方式為ASP廠商集中管理。 • 主要目標市場為中小型企業。

30. 表13-3 傳統的委外與ASP的比較

31. 資訊系統的租用與採購(1/4) • 套裝軟體的引進 • 套裝軟體引進的主要概念與特點 • 套裝軟體的引進是指，對於某些標準化、非策略性的一般功能運用而言，例如會計、薪資、訂單處理、存貨控制、CAD/CAM等，以直接向外採購的方式引進組織，其有下列特點： • 直接運用套裝軟體 • 不需由組織內部的資訊部門來開發 • 此外，目前的套裝軟體已經發展到所謂的企業系統，例如ERP、SCM、CRM，軟體內含標準的作業流程，內建最佳實務，並且以此來搭配企業進行BPR。

32. 資訊系統的租用與採購(2/4) • 套裝軟體引進的主要優缺點 • 套裝軟體的優點包括：成本低、錯誤較少、節省時間以及系統優良等。 • 套裝軟體的缺點包括：並非完全適用、量身訂製以及修改後成本高、維護方面不易控制、不確定性高、彈性低、自己無法掌握IT方向。

33. 資訊系統的租用與採購(3/4)

34. 資訊系統的租用與採購(4/4)

35. CMMI：軟體開發能力與成熟度模式(1/9) • 企業開發軟體系統時，應包括哪些重要的流程？這些流程內應有哪些關鍵的活動？此活動應達到何種程度的目標？企業應該用何種架構來衡量及改善自己本身的軟體開發能力？又應如何來評估軟體委外承包商的軟體開發能力？有何標準？這些問題一直是企業資訊系統開發最核心的關鍵議題，而所謂的軟體能力成熟度整合模式(SW-CMMI)就是針對上述問題所發展出來的一個指導性的標準架構。

36. CMMI：軟體開發能力與成熟度模式(2/9) • CMM的基本概念 • CMM的定義與簡介 • CMM是指一個評估企業軟體開發能力成熟度的認證模式，其是1986年11月美國卡內基美隆大學的軟體工程學院(SEI)基於美國國防部對軟體品質的要求，在Mitre公司的協助下，發展出一個評估企業軟體開發能力的模式，國防部即利用CMM模式對軟體委外承包商進行其軟體開發能力的評估，以決定合作的對象。 • CMM的主要利用目的 • 企業本身軟體開發能力的評估與改善：由CMM的標準架構指導，企業可用來評估其軟體開發程序的品質與能力。 • 企業用以評估合作軟體委外承包商的能力：CMM提供了一個如ISO般的標準認證模式，企業可以依此認證的等級來評估其潛在的軟體委外承包商。

37. CMMI：軟體開發能力與成熟度模式(3/9) • CMMI的主要架構 • CMMI的五個成熟度層級 • CMMI將企業的軟體開發能力，依其執行的承諾度(Commitment)、品質與能力成熟度，分成下列五個層級： • 初始層級(Initial)，其主要特徵如下： • 軟體開發程序：此程序未被清楚定義，流程充滿了不確定性及混亂無章的狀態(Chaotic)。 • 主要角色：軟體的成敗主要靠幾個核心人物的聰明才智與努力，充滿個人英雄主義。 • 重複層級(Repeatable)，其主要特徵如下： • 軟體開發程序：具備基本的專業管理能力，對於專案的成本、時程及功能都有追蹤與管理。 • 概念的複製：已有能力依據以前的成功經驗與程序來複製開發類似的應用系統。

38. CMMI：軟體開發能力與成熟度模式(4/9) • 定義層級(Defined)，其主要特徵如下： • 軟體開發程序：整個軟體開發週期的每一個階段與每一個流程活動都已經清楚的文件化與標準化。 • 管理層級(Managed)，其主要特徵如下： • 量化的評估：此階段主要特點在於能以客觀、明確的量化指標，來清楚衡量軟體開發的活動與品質。 • 軟體品質保證：此階段強調透過量化評估資料的蒐集與分析，來善製造流程與品質，因此此階段品質保證團隊扮演極重要的角色。

39. CMMI：軟體開發能力與成熟度模式(5/9) • 最佳層級(Optimizing)，其主要特徵如下： • 持續的改善：此階段主要特點在於利用量化評估資料的回饋，來分析成敗的原因與解決方案，並能持續地改善軟體開發的各流程及預防錯誤的發生。 • 組織創新的能力：此階段已可利用實驗性的先導計畫(Pilot Project)來嘗試新的開發方法。

40. CMMI：軟體開發能力與成熟度模式(6/9)

41. 表13-5 CMMI四大層級的KPA

42. CMMI：軟體開發能力與成熟度模式(7/9) • CMMI的引申意涵 • CMMI對企業的好處 • 提高軟體開發的生產力與品質 • 軟體開發程序的制度化、透明化與標準化。 • 避免工作的重複 • 避免錯誤的再犯

43. CMMI：軟體開發能力與成熟度模式(8/9) • CMMI的現況 • 2007年8月統計資料顯示，目前全台灣CMMI：軟體開發能力與成熟度模式已有超過120個軟體組織導入CMMI，而且通過CMMI各Level評鑑之家數已達74個，躍居全球第7位。目前參與CMMI導入之公司，包括半導體、高科技製造商、電子媒體、電信公司、遊戲軟體開發商、銀行證券、政府、學校、服務業、電子製造業等領域，可見台灣整體高軟體品質水準已普及至各行各業，而台灣高軟體品質之形象亦逐漸被全球主要國家市場所認同。

44. CMMI：軟體開發能力與成熟度模式(9/9) • CMMI與軟體開發工具 • 為了支援CMMI，軟體公司亦將CMMI的規範整合入其軟體開發工具內，例如微軟在2005年就宣布與SEI合作，透過其軟體解決方案架構(MSF)與軟體管理工具－－Visual Studio 2005 Team System的整合，提供一個符合CMMI的團隊軟體開發流程工具，此工具除了有各種開發工具整合的特性外，並將支援CMMI的各種KPA與規範。