系统建置阶段说明.ppt

上传人:牧羊曲112 文档编号:6597662 上传时间:2023-11-16 格式:PPT 页数:61 大小:358KB
返回 下载 相关 举报
系统建置阶段说明.ppt_第1页
第1页 / 共61页
系统建置阶段说明.ppt_第2页
第2页 / 共61页
系统建置阶段说明.ppt_第3页
第3页 / 共61页
系统建置阶段说明.ppt_第4页
第4页 / 共61页
系统建置阶段说明.ppt_第5页
第5页 / 共61页
点击查看更多>>
资源描述

《系统建置阶段说明.ppt》由会员分享,可在线阅读,更多相关《系统建置阶段说明.ppt(61页珍藏版)》请在三一办公上搜索。

1、第9章,系統建置,階段說明,系統建置(system implementation)是系統開發生命週期(SDLC)五個階段中的第四個階段其中將包括應用程式開發、測試、安裝,及評估使用者將每日使用此系統,而你將轉而著重在系統的運行與支援,而此正是 SDLC 的最終階段,學習目標,解釋軟體品質保證和軟體工程的重要性敘述應用程式的開發過程繪製能夠說明由上而下設計、模組化設計、內聚性,和關聯性的結構圖敘述程式碼的撰寫過程並解說程式碼如何產生解說單元測試、整合測試,及系統測試,學習目標,分辨程式、系統、操作、及使用者等文件之差異列出系統安裝與評估過程中的各項主要步驟編寫一個全面培訓計畫,並指出各組參加人員

2、的特定目標、比較內部及外部培訓供廠商,並解說效果良好的培訓技巧,學習目標,說明資料轉換過程指出並解說各種系統轉換方法解釋建置後評估描述向管理當局做最後報告的內容,簡介,系統設計規格就成為建構新系統的藍圖第一個工作就是應用程式開發在能夠移轉之前,該系統必須被小心地測試並建立文件、使用者需要接受培訓、而現有的資料需被轉換完成而在新系統能夠運行之後,對於最終結果的正式評估必須進行而作為對高層管理人員做報告的一部分,軟體品質保證,在今天競爭的企業環境之中,各個企業全都密切關心其產品與服務的品質嚴格的測試將會在最後幾個階段查出一些錯誤,但是還是在開發過程的早期階段糾正錯誤代價較低主要目的就是避免問題或儘

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

4、這些都是資訊系統的基本構成元件你在應用程式開發的第一步是小心地複閱所有既有文件,應用程式開發,文件複閱你將需要來自前面各個 SDLC 階段完備的文件,並建立一套程式的設計以系統文件為藍圖,你將會開發出把系統分割成許多小片段而使程式設計師可將之轉化為程式及模組的各個結構圖,應用程式開發,程式設計必須將系統視為一系列能執行特定任務或功能的模組由上而下設計(top-down design)-分割(partitioning)-模組化設計(modular design)利用專案管理軟體來監控每個模組的進度、預估整體開發時間、估算所需的人力及技術資源,以及計算出專案的要徑結構圖(structure cha

5、rt)結構圖顯示出各程式模組間的關係控制模組(control module)附屬模組(subordinate module),應用程式開發,結構圖(structure chart)模組程式館模組(library module)資料關聯控制關聯(control couple)旗號(flag)一個模組利用旗號來傳送特定情況或動作的訊號給另一個模組,應用程式開發,結構圖(structure chart)條件一個條件(condition)線段表示出按照特定的條件一個控制模組可以決定該呼叫那一個附屬模組迴圈迴圈(loop)指出一個或多個模組的重複執行,應用程式開發,內聚和關聯如果你需要使一個模組更為內聚

6、,你可以將它分割為個別執行單一功能的單元低度關聯(loosely coupled)高度關聯(tightly coupled)由控制模組傳送狀態旗號的方式一般均被視為不好的設計,應用程式開發,結構圖的例子,應用程式開發,繪製結構圖的步驟 第一步:複閱各 DFD 和物件模型檢查其正確性和完整性第二步:指認出各個模組和其關聯性你由全景圖向低層級的圖形進行工作,一邊指認出所有的控制模組和其附屬模組,直到功能元件為止第三步:加上關聯、迴圈,及條件指認出模組間互相傳送的資料元素第四步:分析結構圖、各 DFD、和資料詞典確保該圖充分反映先前所做的文件,且其邏輯均為正確,應用程式開發,其他應用程式開發工具 程

7、式流程圖程式流程圖(program flowcharts)利用一系列的符號以箭頭連接的方式來以圖形表示程式模組的邏輯和彼此之間的互動虛擬碼虛擬碼(pseudo code)是一種表示程式邏輯的技術虛擬碼與第四章所述的結構化英文相似虛擬碼不是專屬於某一個程式語言,所以你可以用一般的英文來描述程式模組而不必依循任何嚴格的語法規則,編寫程式碼(coding),程式撰寫環境每一個 IT 部門都有自己的程式設計環境和標準產生程式碼使用應用系統產生器、報表編寫器、螢幕畫面產生器、第四代語言,和能夠從程式設計規格直接產生程式碼的 CASE 工具有些商業性應用系統能夠直接從巨集功能、鍵擊,或滑鼠動作產生可編輯的

8、程式碼,系統測試,程式碼編寫完成之後,程式設計師必須測試程式,以保證它能夠正確地發揮功能語法錯誤(syntax errors)桌上檢查(desk checking)結構化逐項檢驗(structured walkthrough)或程式碼審查(code review)設計逐項檢驗(design walkthrough),系統測試,單元測試(unit testing)測試資料應當同時包含正確資料及錯誤資料,且應當測試所有可能的情況程式設計師必須在那些與其他程式和檔案互動的程式整合成為一個系統之前逐一地測試殘片測試(stub testing)無論由誰建立測試計畫,專案經理或指定的分析師也會審查最後的測

9、試結果,系統測試,整合測試對於相互依賴的兩個或更多程式的測試稱為整合測試(integration testing)或連結測試(link testing)獨立測試這兩個程式不能保證在它們之間傳遞的資料是正確的整合測試資料必須一併考慮正常與不正常的狀況除非在所有單元測試中全都表現正確,否則測試過程就不應該進入整合測試階段,系統測試,系統測試主要目標是對全部程式執行最後測試保證IT人員擁有正確操作這個系統所需要的文件和說明,而且系統有充分的備份和重新啟動的能力 證明使用者能夠與系統成功地互動驗證所有系統元件都已經正確整合,而實際之作業狀況將得到正確處理確認這個資訊系統能夠以及時且有效率的方式處理預計

10、的資料量,系統測試,系統測試接受測試(acceptance tests)你應該視徹底的測試為提供高品質產品的一種符合成本效益的方法如果出現相衝突的觀點時,管理當局在充分討論完各種可行的方案後會決定是否安裝該系統,文件,程式文件(program documentation)程式文件描述了所有程式模組的輸入、輸出、及處理工作邏輯。程式文件的製作開始於系統分析階段,持續進行到系統建置期間系統分析師在 SDLC 的早期編製總體文件,比如處理工作說明與報表格式之類程式設計人員提供文件的方式是建構一個充分利用內部和外部註解及說明,而便於了解與維護的程式模組,文件,系統文件(system documenta

11、tion)系統文件包括資料詞典中的紀錄、資料流程圖、物件模型、畫面格式、原始文件,與引發本專案的系統申請在系統建置期間,分析師必須審查系統文件,驗證其完整性、準確性,及與現況相符,包括系統建置期間所做的任何變更,文件,操作文件(operations documentation)典型的操作文件包括下列資訊程式、系統分析師、程式設計人員,和系統的識別代號時程安排資訊,比如執行的頻率和最後期限輸入檔案及其來源;以及輸出檔案及其去處報表的配送,文件,操作文件(operations documentation)典型的操作文件包括下列資訊所需要的特別表格給操作人員的錯誤警訊與提示訊息,以及重新啟動的程序特

12、別指示,比如安全要求之類操作文件應當清晰、簡明,並儘可能可以在線上得到。,文件,使用者文件(user documentation)通常程式文件和系統文件是由程式設計師或系統分析師產生你需要某些專精於此道的專家來從事開發,就如同你需要某些專業技能來從事軟體開發一般使用者文件必須要清楚,易懂、而且隨時可供各階層使用者取用,文件,使用者文件(user documentation)包括下列各項清楚說明全部系統主要性能、能力,和限制的系統概述原始文件的內容、製作說明、處理說明,和樣本的說明選單和資料登錄畫面選項、內容和處理提示的概述定期產生或應使用者需求而製作的報表樣本,包括樣張,文件,使用者文件(us

13、er documentation)包括下列各項安全性與稽核軌跡資訊對於特定輸入、輸出,或處理需求所負職責的解說申請變更及報告問題的程序例外和錯誤情況舉例經常提起的問題(FAQs)如何獲得輔助文件,以及更新使用者手冊程序的解說,文件,使用者文件(user documentation)大部分的使用者偏愛線上文件(online documentation)也需要決定該文件是否可在程式中取得或為分離的獨立實體,而形態可以是一套教案、簡報投影片、參考手冊,或網站績效良好的線上文件,是提高生產力的重要工具,文件,使用者文件(user documentation)書面文件也很有價值介於完成軟體程式撰寫到一個

14、完整的套裝包括所有文件能夠發行給使用者的時間,完全取決於文件是否在事前好好地構思,文件,使用者文件(user documentation)忽略使用者文件這個事項,直到所有程式完成之後,經常導致以下兩者之一所有文件會被一起儘快的推出,只為了準時將它們送出門,而很可能並不完備它可以被正確地完成,而產品的發行會延後相當長的時間,管理當局批准,完成系統測試之後,你向管理當局提報各項結果如果系統測試沒有產生技術、經濟,或操作問題,那麼管理當局將決定系統安裝與評估的進度,系統安裝與評估,完成系統建置階段中剩餘的步驟:準備分開的操作及測試環境提供對使用者、經理們,和IT人員的培訓執行資料轉換和系統轉換進行系

15、統的建置後評估對管理當局做最後報告,操作與測試環境,系統實際執行的環境稱為操作環境(operational environment)或生產環境(production environment)分析師和程式設計人員用來開發與維護程式的環境稱為測試環境(test environment)必須有一個分離的測試環境以保持系統安全性和完整性,並保護操作環境,操作與測試環境,使用操作環境的使用只限於使用者,並應該受到嚴格控制資訊系統的測試環境包含全部程式的副本、程序,和測試資料檔經過任何修改之後,你應當重複進行系統開發時進行的接受測試,操作與測試環境,操作環境包括所有硬體和軟體配置和設定、系統公用程式、通訊

16、資源,以及影響系統績效的任何其他元件。由於網路功能在一個主/從環境中非常重要,你在安裝任何應用系統之前,必須驗證網路的連結、規格,和效能如果你必須建立或升級網路資源以支援新的系統,你就必須在開始系統安裝之前嚴格測試這個平台,培訓,培訓計畫(training plan)第一步是確認誰應當接受培訓,和需要什麼樣的培訓三個主要的培訓群組是使用者、經理人,和 IT 人員確認目標後,你必須決定如何提供培訓,培訓,廠商培訓如果系統包含軟體或硬體旳購買,那麼廠商提供的培訓是你應當在你送給可能的廠商的 RFP(建議書要約),RFQ(報價要約)中研究或要求的特性之一廠商培訓常常讓你的培訓值回票價,培訓,外部培訓

17、資源有許多培訓顧問、研究機構,和公司,提供標準的或訂製的培訓套裝計畫你可以直接和培訓提供者聯絡,並且從其客戶那得到側面的評價資訊科技應用中心(CAIT,Center for the Application of Information Technology),培訓,內部培訓 IT 人員和使用者部門往往分擔制定與執行自行開發軟體培訓計畫的責任在製作培訓計畫時,你應當牢記下列各項準則對人員分組培訓,不同的群組各有分別的培訓課程選擇最有效的地點進行培訓提供透過聽、看、做的學習準備有效的培訓教材,包括互動式的教案,培訓,內部培訓 在製作培訓計畫時,你應當牢記下列各項準則。借助先前的受訓人員利用培養教練

18、(train-the-trainer)的策略當培訓完成之後,許多組織執行作為使用者和 IT 支援人員正式演習的全面測試,或模擬(simulation),資料轉換,資料轉換(data conversion)在資料轉換(data conversion)的過程中現有的資料會被載入新系統你應該儘早訂定資料轉換的計畫,而且在測試環境完成之時,資料轉換就應該先做測試,資料轉換,資料轉換策略舊系統或許能夠以新系統能夠接受的格式或是如 ASCII、ODBC 等標準格式將資料匯出(exporting)如果沒有標準格式,你就必須自行開發程式來萃取資料並轉換成可接受的格式新系統經常會需要額外的資料項目,這些還是需要

19、以人工輸入。,資料轉換,資料轉換安全及控制所有系統控制措施在資料轉換期間都必須就緒並能確實執行,以保護資料不受未經批准的存取,並幫助防止錯誤的輸入縱使在細心的資料轉換和輸入控制之下,也會發生某些錯誤雖然其過程會是耗時而又昂貴的,但是在新系統載入正確無誤的資料非常重要。,系統轉換(system changeover),直接切換(direct cutover)比其他轉換方法涉及更多的風險公司常常選擇直接切換方法於商業套裝軟體,因為這些套裝軟體造成整個系統故障的風險較小為了儘量減少需要自兩個不同系統取得資訊,週期性資訊系統通常都採用直接切換方法在一季、日曆年度,或會計年度的開端來作轉換。,系統轉換(

20、system changeover),平行作業(parallel operation)在平行作業之下,會比在直接切換時更容易驗證新系統的正確執行執行兩個系統可能給操作環境增加了負擔,造成處理的遲延如果老系統與新系統在技術上不相容,或若操作環境不能同時支援這兩個系統時,平行作業就不實際了當兩個系統執行不同的功能,或如果新系統涉及新的業務經營方法時,平行作業也是不恰當的,系統轉換(system changeover),試行作業(pilot operation)首先使用新系統的群組稱為試行現場(pilot site)老系統繼續在整個組織中執行當系統在試行現場證明成功之後,才在組織的其餘部分中執行,此

21、時則通常採用直接切換方法是把平行作業與直接切換方法結合起來的一種半平行作業,系統轉換(system changeover),分段作業(phased operation)在分段作業的情況下,你把系統的一部分給予全體使用者錯誤或故障的風險僅僅侷限於所建置的模組分段作業比完全的平行作業較為節省然而,如果系統不能方便地分成一些邏輯模組或段落,分段作業就不可能作到了,系統轉換(system changeover),建置後的各項工作,建置後評估(post-implementation evaluation)典型的評估包括下列各個方面的意見回饋資訊系統輸出的準確性、完整性,和及時性使用者滿意度系統的可靠性和

22、可維護性系統控制與安全措施的充分性硬體的效率和平臺的效能,建置後的各項工作,建置後評估(post-implementation evaluation)典型的評估包括下列各個方面的意見回饋資料庫建置的效益IT小組的績效文件的完整性和品質培訓的品質和效益成本-效益估算和開發進度安排的準確性,建置後的各項工作,建置後評估(post-implementation evaluation)在評估一個系統時,你應當訪問那些管理成員和關鍵使用者觀察使用者和電腦操作人員實際使用新資訊系統從事工作閱讀全部文件和培訓材料,建置後的各項工作,建置後評估(post-implementation evaluation)在

23、評估一個系統時,你應當審查全部原始文件、輸出報表,和螢幕畫面利用問卷調查從大量使用者那裡收集資訊和意見分析維護和求助專櫃的紀錄。可能的話,建置後評估應當由非直接涉及系統開發的人員進行,建置後的各項工作,建置後評估(post-implementation evaluation)如果評估之前等待的時間太長,使用者可能遺忘開發工作的細節希望儘快結束專案的壓力往往造成提早作評估,以便 IT 部門能夠轉而執行其他任務。在理想上,執行建置後評估應該是所有資訊系統專案的標準工作,建置後的各項工作,給管理當局的最後報告 你的報告應當包括下列項目全部系統文件的最後版本已被指認並列入計畫的系統修改和加強所有各項系統開發成本和進度的摘要說明,建置後的各項工作,給管理當局的最後報告你的報告應當包括下列項目實際成本和進度與原本估計的對照建置後評估,如果已經進行的話 對管理當局的最後報告代表著系統開發工作的結束,本章總結,系統建置階段包括應用系統開發及緊接著的新系統安裝與評估分析師還編寫操作文件和使用者文件在安裝期間,你給新的資訊系統建立了一個完全獨立於測試環境之外的操作環境,或說生產環境,本章總結,制定培訓計畫 在安裝一套新資訊系統時常常需要資料轉換系統轉換是使新的資訊系統投入運行的一個過程建置後評估對新系統的品質及專案小組的工作做評估並報告,Chapter 9 Complete,

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 生活休闲 > 在线阅读


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号