第9章 系統建置.

Presentation on theme: "第9章 系統建置."— Presentation transcript:

1 第9章 系統建置

2 階段說明 系統建置 (system implementation) 是系統開發生命週期 (SDLC) 五個階段中的第四個階段
其中將包括應用程式開發、測試、安裝，及評估 使用者將每日使用此系統，而你將轉而著重在系統的運行與支援，而此正是 SDLC 的最終階段

3 學習目標 解釋軟體品質保證和軟體工程的重要性 敘述應用程式的開發過程 繪製能夠說明由上而下設計、模組化設計、內聚性，和關聯性的結構圖
敘述程式碼的撰寫過程並解說程式碼如何產生 解說單元測試、整合測試，及系統測試 3

4 學習目標 分辨程式、系統、操作、及使用者等文件之差異 列出系統安裝與評估過程中的各項主要步驟
編寫一個全面培訓計畫，並指出各組參加人員的特定目標、比較內部及外部培訓供廠商，並解說效果良好的培訓技巧 3

5 學習目標 說明資料轉換過程 指出並解說各種系統轉換方法 解釋建置後評估 描述向管理當局做最後報告的內容

6 簡 介 系統設計規格就成為建構新系統的藍圖 第一個工作就是應用程式開發
簡　介 系統設計規格就成為建構新系統的藍圖 第一個工作就是應用程式開發 在能夠移轉之前，該系統必須被小心地測試並建立文件、使用者需要接受培訓、而現有的資料需被轉換完成 而在新系統能夠運行之後，對於最終結果的正式評估必須進行而作為對高層管理人員做報告的一部分 4

7 軟體品質保證 在今天競爭的企業環境之中，各個企業全都密切關心其產品與服務的品質
嚴格的測試將會在最後幾個階段查出一些錯誤，但是還是在開發過程的早期階段糾正錯誤代價較低 主要目的就是避免問題或儘早查出問題

8 軟體品質保證 軟體工程 大學的軟體工程研究所 (SEI, Software Engineering Institute) 是軟體工程界的領導者 SEI 設計了功能成熟度模型 (CMM, Capability Maturity Model) 來提高品質、縮短開發時間，並削減成本。 國際標準組織ISO 在 1991 年 ISO 建立了一套能夠為軟體的開發及維護提供品質保證的指導方針，被稱為 ISO ISO 要求公司遵循一個特定的開發計畫，其中列出將使用者需求轉變為完成產品的逐步程序

9 應用程式開發 應用程式開發 (application development) 是建構各種程式及程式碼模組的過程，而這些都是資訊系統的基本構成元件 你在應用程式開發的第一步是小心地複閱所有既有文件

10 應用程式開發 文件複閱 你將需要來自前面各個 SDLC 階段完備的文件，並建立一套程式的設計
以系統文件為藍圖，你將會開發出把系統分割成許多小片段而使程式設計師可將之轉化為程式及模組的各個結構圖

11 應用程式開發 程式設計 結構圖 (structure chart) 必須將系統視為一系列能執行特定任務或功能的模組
由上而下設計 (top-down design) -- 分割 (partitioning) -- 模組化設計 (modular design) 利用專案管理軟體來監控每個模組的進度、預估整體開發時間、估算所需的人力及技術資源，以及計算出專案的要徑 結構圖 (structure chart) 結構圖顯示出各程式模組間的關係 控制模組 (control module) 附屬模組 (subordinate module) 

12 應用程式開發 結構圖 (structure chart) 模組 資料關聯 控制關聯 (control couple)
程式館模組 (library module) 資料關聯 控制關聯 (control couple) 旗號 (flag) 一個模組利用旗號來傳送特定情況或動作的訊號給另一個模組

13 應用程式開發 結構圖 (structure chart) 條件 迴圈
一個條件 (condition) 線段表示出按照特定的條件一個控制模組可以決定該呼叫那一個附屬模組  迴圈 迴圈 (loop) 指出一個或多個模組的重複執行

14 應用程式開發 內聚和關聯 如果你需要使一個模組更為內聚，你可以將它分割為個別執行單一功能的單元 低度關聯 (loosely coupled)
高度關聯 (tightly coupled) 由控制模組傳送狀態旗號的方式一般均被視為不好的設計

15 應用程式開發 結構圖的例子

16 應用程式開發 繪製結構圖的步驟 第一步：複閱各 DFD 和物件模型 第二步：指認出各個模組和其關聯性 第三步：加上關聯、迴圈，及條件
檢查其正確性和完整性 第二步：指認出各個模組和其關聯性 你由全景圖向低層級的圖形進行工作，一邊指認出所有的控制模組和其附屬模組，直到功能元件為止 第三步：加上關聯、迴圈，及條件 指認出模組間互相傳送的資料元素 第四步：分析結構圖、各 DFD、和資料詞典 確保該圖充分反映先前所做的文件，且其邏輯均為正確

17 應用程式開發 其他應用程式開發工具 程式流程圖 虛擬碼
程式流程圖　 程式流程圖 (program flowcharts) 利用一系列的符號以箭頭連接的方式來以圖形表示程式模組的邏輯和彼此之間的互動 虛擬碼 虛擬碼 (pseudo code) 是一種表示程式邏輯的技術 虛擬碼與第四章所述的結構化英文相似 虛擬碼不是專屬於某一個程式語言，所以你可以用一般的英文來描述程式模組而不必依循任何嚴格的語法規則

18 編寫程式碼 (coding) 程式撰寫環境 產生程式碼 每一個 IT 部門都有自己的程式設計環境和標準
使用應用系統產生器、報表編寫器、螢幕畫面產生器、第四代語言，和能夠從程式設計規格直接產生程式碼的 CASE 工具 有些商業性應用系統能夠直接從巨集功能、鍵擊，或滑鼠動作產生可編輯的程式碼

19 系統測試 程式碼編寫完成之後，程式設計師必須測試程式，以保證它能夠正確地發揮功能 語法錯誤 (syntax errors)
桌上檢查 (desk checking) 結構化逐項檢驗 (structured walkthrough) 或程式碼審查 (code review) 設計逐項檢驗 (design walkthrough)

20 系統測試 單元測試 (unit testing) 測試資料應當同時包含正確資料及錯誤資料，且應當測試所有可能的情況
程式設計師必須在那些與其他程式和檔案互動的程式整合成為一個系統之前逐一地測試 殘片測試 (stub testing) 無論由誰建立測試計畫，專案經理或指定的分析師也會審查最後的測試結果

21 系統測試 整合測試 對於相互依賴的兩個或更多程式的測試稱為整合測試 (integration testing) 或連結測試 (link testing) 獨立測試這兩個程式不能保證在它們之間傳遞的資料是正確的 整合測試資料必須一併考慮正常與不正常的狀況 除非在所有單元測試中全都表現正確，否則測試過程就不應該進入整合測試階段

22 系統測試 系統測試 主要目標是︰ 對全部程式執行最後測試
保證IT人員擁有正確操作這個系統所需要的文件和說明，而且系統有充分的備份和重新啟動的能力 證明使用者能夠與系統成功地互動 驗證所有系統元件都已經正確整合，而實際之作業狀況將得到正確處理 確認這個資訊系統能夠以及時且有效率的方式處理預計的資料量

23 系統測試 系統測試 接受測試 (acceptance tests) 你應該視徹底的測試為提供高品質產品的一種符合成本效益的方法
如果出現相衝突的觀點時，管理當局在充分討論完各種可行的方案後會決定是否安裝該系統

24 文 件 程式文件 (program documentation)
文　件 程式文件 (program documentation) 程式文件描述了所有程式模組的輸入、輸出、及處理工作邏輯。程式文件的製作開始於系統分析階段，持續進行到系統建置期間 系統分析師在 SDLC 的早期編製總體文件，比如處理工作說明與報表格式之類 程式設計人員提供文件的方式是建構一個充分利用內部和外部註解及說明，而便於了解與維護的程式模組

25 文 件 系統文件 (system documentation)
文　件 系統文件 (system documentation) 系統文件包括資料詞典中的紀錄、資料流程圖、物件模型、畫面格式、原始文件，與引發本專案的系統申請 在系統建置期間，分析師必須審查系統文件，驗證其完整性、準確性，及與現況相符，包括系統建置期間所做的任何變更

26 文 件 操作文件 (operations documentation) 典型的操作文件包括下列資訊︰
文　件 操作文件 (operations documentation) 典型的操作文件包括下列資訊︰ 程式、系統分析師、程式設計人員，和系統的識別代號 時程安排資訊，比如執行的頻率和最後期限 輸入檔案及其來源；以及輸出檔案及其去處 報表的配送

27 文 件 操作文件 (operations documentation) 典型的操作文件包括下列資訊︰
文　件 操作文件 (operations documentation) 典型的操作文件包括下列資訊︰ 所需要的特別表格 給操作人員的錯誤警訊與提示訊息，以及重新啟動的程序 特別指示，比如安全要求之類 操作文件應當清晰、簡明，並儘可能可以在線上得到。

28 文 件 使用者文件 (user documentation) 通常程式文件和系統文件是由程式設計師或系統分析師產生
文　件 使用者文件 (user documentation) 通常程式文件和系統文件是由程式設計師或系統分析師產生 你需要某些專精於此道的專家來從事開發，就如同你需要某些專業技能來從事軟體開發一般 使用者文件必須要清楚，易懂、而且隨時可供各階層使用者取用

29 文 件 使用者文件 (user documentation) 包括下列各項︰ 清楚說明全部系統主要性能、能力，和限制的系統概述
文　件 使用者文件 (user documentation) 包括下列各項︰ 清楚說明全部系統主要性能、能力，和限制的系統概述 原始文件的內容、製作說明、處理說明，和樣本的說明 選單和資料登錄畫面選項、內容和處理提示的概述 定期產生或應使用者需求而製作的報表樣本，包括樣張

30 文 件 使用者文件 (user documentation) 包括下列各項︰ 安全性與稽核軌跡資訊
文　件 使用者文件 (user documentation) 包括下列各項︰ 安全性與稽核軌跡資訊 對於特定輸入、輸出，或處理需求所負職責的解說 申請變更及報告問題的程序 例外和錯誤情況舉例 經常提起的問題 (FAQs) 如何獲得輔助文件，以及更新使用者手冊程序的解說

31 文 件 使用者文件 (user documentation) 大部分的使用者偏愛 線上文件 (online documentation)
文　件 使用者文件 (user documentation) 大部分的使用者偏愛 線上文件 (online documentation) 也需要決定該文件是否可在程式中取得或為分離的獨立實體，而形態可以是一套教案、簡報投影片、參考手冊，或網站 績效良好的線上文件，是提高生產力的重要工具

32 文 件 使用者文件 (user documentation) 書面文件也很有價值
文　件 使用者文件 (user documentation) 書面文件也很有價值 介於完成軟體程式撰寫到一個完整的套裝──包括所有文件──能夠發行給使用者的時間，完全取決於文件是否在事前好好地構思

33 文 件 使用者文件 (user documentation) 忽略使用者文件這個事項，直到所有程式完成之後，經常導致以下兩者之一︰
文　件 使用者文件 (user documentation) 忽略使用者文件這個事項，直到所有程式完成之後，經常導致以下兩者之一︰ 所有文件會被一起儘快的推出，只為了準時將它們送出門，而很可能並不完備 它可以被正確地完成，而產品的發行會延後相當長的時間

34 管理當局批准 完成系統測試之後，你向管理當局提報各項結果 如果系統測試沒有產生技術、經濟，或操作問題，那麼管理當局將決定系統安裝與評估的進度

35 系統安裝與評估 完成系統建置階段中剩餘的步驟: 準備分開的操作及測試環境 提供對使用者、經理們，和IT人員的培訓 執行資料轉換和系統轉換
進行系統的建置後評估 對管理當局做最後報告

36 操作與測試環境 系統實際執行的環境稱為操作環境 (operational environment) 或生產環境 (production environment) 分析師和程式設計人員用來開發與維護程式的環境稱為測試環境 (test environment) 必須有一個分離的測試環境以保持系統安全性和完整性，並保護操作環境

37 操作與測試環境 使用操作環境的使用只限於使用者，並應該受到嚴格控制 資訊系統的測試環境包含全部程式的副本、程序，和測試資料檔
經過任何修改之後，你應當重複進行系統開發時進行的接受測試

38 操作與測試環境 操作環境包括所有硬體和軟體配置和設定、系統公用程式、通訊資源，以及影響系統績效的任何其他元件。由於網路功能在一個主 / 從環境中非常重要，你在安裝任何應用系統之前，必須驗證網路的連結、規格，和效能 如果你必須建立或升級網路資源以支援新的系統，你就必須在開始系統安裝之前嚴格測試這個平台

39 培 訓 培訓計畫 (training plan) 第一步是確認誰應當接受培訓，和需要什麼樣的培訓
培　訓 培訓計畫 (training plan) 第一步是確認誰應當接受培訓，和需要什麼樣的培訓 三個主要的培訓群組是使用者、經理人，和 IT 人員 確認目標後，你必須決定如何提供培訓

40 培　訓 廠商培訓 如果系統包含軟體或硬體旳購買，那麼廠商提供的培訓是你應當在你送給可能的廠商的 RFP (建議書要約)，RFQ (報價要約) 中研究或要求的特性之一 廠商培訓常常讓你的培訓值回票價

41 培 訓 外部培訓資源 有許多培訓顧問、研究機構，和公司，提供標準的或訂製的培訓套裝計畫
培　訓 外部培訓資源 有許多培訓顧問、研究機構，和公司，提供標準的或訂製的培訓套裝計畫 你可以直接和培訓提供者聯絡，並且從其客戶那得到側面的評價 資訊科技應用中心 (CAIT, Center for the Application of Information Technology)

42 培 訓 內部培訓 IT 人員和使用者部門往往分擔制定與執行自行開發軟體培訓計畫的責任 在製作培訓計畫時，你應當牢記下列各項準則
培　訓 內部培訓 IT 人員和使用者部門往往分擔制定與執行自行開發軟體培訓計畫的責任 在製作培訓計畫時，你應當牢記下列各項準則 對人員分組培訓，不同的群組各有分別的培訓課程 選擇最有效的地點進行培訓 提供透過聽、看、做的學習 準備有效的培訓教材，包括互動式的教案

43 培 訓 內部培訓 在製作培訓計畫時，你應當牢記下列各項準則。
培　訓 內部培訓 在製作培訓計畫時，你應當牢記下列各項準則。 借助先前的受訓人員 利用培養教練 (train-the-trainer) 的策略 當培訓完成之後，許多組織執行作為使用者和 IT 支援人員正式演習的全面測試，或模擬 (simulation)

44 資料轉換 資料轉換 (data conversion) 在資料轉換 (data conversion) 的過程中現有的資料會被載入新系統
你應該儘早訂定資料轉換的計畫，而且在測試環境完成之時，資料轉換就應該先做測試

45 資料轉換 資料轉換策略 舊系統或許能夠以新系統能夠接受的格式或是如 ASCII、ODBC 等標準格式將資料匯出 (exporting)
如果沒有標準格式，你就必須自行開發程式來萃取資料並轉換成可接受的格式 新系統經常會需要額外的資料項目，這些還是需要以人工輸入。

46 資料轉換 資料轉換安全及控制 所有系統控制措施在資料轉換期間都必須就緒並能確實執行，以保護資料不受未經批准的存取，並幫助防止錯誤的輸入
縱使在細心的資料轉換和輸入控制之下，也會發生某些錯誤 雖然其過程會是耗時而又昂貴的，但是在新系統載入正確無誤的資料非常重要。

47 系統轉換 (system changeover)
直接切換 (direct cutover) 比其他轉換方法涉及更多的風險 公司常常選擇直接切換方法於商業套裝軟體，因為這些套裝軟體造成整個系統故障的風險較小 為了儘量減少需要自兩個不同系統取得資訊，週期性資訊系統通常都採用直接切換方法在一季、日曆年度，或會計年度的開端來作轉換。

48 系統轉換 (system changeover)
平行作業 (parallel operation) 在平行作業之下，會比在直接切換時更容易驗證新系統的正確執行 執行兩個系統可能給操作環境增加了負擔，造成處理的遲延 如果老系統與新系統在技術上不相容，或若操作環境不能同時支援這兩個系統時，平行作業就不實際了 當兩個系統執行不同的功能，或如果新系統涉及新的業務經營方法時，平行作業也是不恰當的

49 系統轉換 (system changeover)
試行作業 (pilot operation) 首先使用新系統的群組稱為試行現場 (pilot site) 老系統繼續在整個組織中執行 當系統在試行現場證明成功之後，才在組織的其餘部分中執行，此時則通常採用直接切換方法 是把平行作業與直接切換方法結合起來的一種半平行作業

50 系統轉換 (system changeover)
分段作業 (phased operation) 在分段作業的情況下，你把系統的一部分給予全體使用者 錯誤或故障的風險僅僅侷限於所建置的模組 分段作業比完全的平行作業較為節省 然而，如果系統不能方便地分成一些邏輯模組或段落，分段作業就不可能作到了

51 系統轉換 (system changeover)

52 建置後的各項工作 建置後評估 (post-implementation evaluation) 典型的評估包括下列各個方面的意見回饋︰
資訊系統輸出的準確性、完整性，和及時性 使用者滿意度 系統的可靠性和可維護性 系統控制與安全措施的充分性 硬體的效率和平臺的效能

53 建置後的各項工作 建置後評估 (post-implementation evaluation) 典型的評估包括下列各個方面的意見回饋︰
資料庫建置的效益 IT小組的績效 文件的完整性和品質 培訓的品質和效益 成本-效益估算和開發進度安排的準確性 

54 建置後的各項工作 建置後評估 (post-implementation evaluation) 在評估一個系統時，你應當︰
訪問那些管理成員和關鍵使用者 觀察使用者和電腦操作人員實際使用新資訊系統從事工作 閱讀全部文件和培訓材料

55 建置後的各項工作 建置後評估 (post-implementation evaluation) 在評估一個系統時，你應當︰
審查全部原始文件、輸出報表，和螢幕畫面 利用問卷調查從大量使用者那裡收集資訊和意見 分析維護和求助專櫃的紀錄。 可能的話，建置後評估應當由非直接涉及系統開發的人員進行

56 建置後的各項工作 建置後評估 (post-implementation evaluation)
如果評估之前等待的時間太長，使用者可能遺忘開發工作的細節 希望儘快結束專案的壓力往往造成提早作評估，以便 IT 部門能夠轉而執行其他任務。 在理想上，執行建置後評估應該是所有資訊系統專案的標準工作

57 建置後的各項工作 給管理當局的最後報告 你的報告應當包括下列項目︰ 全部系統文件的最後版本 已被指認並列入計畫的系統修改和加強
所有各項系統開發成本和進度的摘要說明

58 建置後的各項工作 給管理當局的最後報告 你的報告應當包括下列項目︰ 對管理當局的最後報告代表著系統開發工作的結束
實際成本和進度與原本估計的對照 建置後評估，如果已經進行的話 對管理當局的最後報告代表著系統開發工作的結束

59 本章總結 系統建置階段包括應用系統開發及緊接著的新系統安裝與評估 分析師還編寫操作文件和使用者文件
在安裝期間，你給新的資訊系統建立了一個完全獨立於測試環境之外的操作環境，或說生產環境 49

60 本章總結 制定培訓計畫 在安裝一套新資訊系統時常常需要資料轉換 系統轉換是使新的資訊系統投入運行的一個過程
建置後評估對新系統的品質及專案小組的工作做評估並報告 49

61 Chapter 9 Complete