XXX軟件系統項目實施方案.doc

精選資料 可修改編輯 XXX 系系統統軟軟件件實實施施方方 案案 項項目名稱：目名稱：XXX 系系統軟統軟件件 實實施施單單位：位：XXXXXXXXX 時時 間間： ：XXXX 年年 XX 月月 XX 日日 精選資料 可修改編輯 目目 錄錄 1、 、項項目目總總體體實實施方案施方案 4 1.1工程實施原則.4 1.2項目總體推進計劃.5 1.3系統實施過程的質量保證活動說明.5 1.3.1需求分析階段6 1.3.2總體設計階段6 1.3.3詳細設計階段7 1.3.4系統開發(fā)階段7 1.3.5系統實施和試運行階段7 1.3.6項目驗收階段9 1.3.7系統正式運行及維護階段9 1.3.8各階段輔助文檔9 1.3.9實施過程提交文件匯總10 1.4項目實施計劃.11 1.4.1數據實施步驟12 1.4.2項目進度安排12 2、 、項項目管理方案目管理方案 13 2.1項目管理組織結構.13 2.1.1項目各方角色與責任13 2.1.2任務分工14 2.2項目范圍管理.16 2.3項目進度管理.16 2.4項目風險管理.16 2.4.1技術風險16 2.4.2需求風險17 2.4.3協調與溝通風險17 2.4.4項目人員風險18 2.5質量管理計劃.18 2.5.1質量管理體系標準18 2.5.2質量控制過程18 2.5.3質量評定計劃18 2.5.4質量管理措施19 2.5.5軟件質量控制19 2.6項目協調與合作計劃.21 2.6.1協調與合作管理方案22 2.6.2協調手段22 2.7配置管理.23 2.7.1配置管理和版本控制23 2.7.2變更管理的方法24 2.8文檔管理.25 精選資料 可修改編輯 2.9人員管理.25 2.10保密管理.25 3、 、測試計測試計劃劃 26 3.1測試工作準備.26 3.2軟件開發(fā)測試.26 3.2.1模塊測試27 3.2.2功能測試27 3.2.3性能測試27 3.2.4分系統測試27 3.2.5全系統測試28 3.2.6容量測試28 3.2.7壓力測試28 3.2.8災難恢復測試28 3.3設計測試用例和數據.29 3.3.1建立測試環(huán)境29 3.3.2測試執(zhí)行30 4、 、驗驗收收計計劃劃 31 4.1驗收組織.31 4.2驗收內容.31 4.3軟件系統的驗收.31 3.用用戶戶方已方已經認經認可可測試測試數據數據 32 5、培、培訓訓方案方案 33 5.1培訓目標.33 5.2培訓方式.33 5.3培訓對象.33 5.4培訓地點與環(huán)境.33 5.5培訓計劃及內容.34 5.5.1用戶培訓34 5.5.2系統管理人員培訓34 6、技、技術術支持和售后服支持和售后服務務 36 6.1技術支持與售后服務政策.36 6.1.1技術后援支持36 6.1.2技術后援支持方式37 6.1.3保修及系統維護服務37 精選資料 可修改編輯 1 、 、項項目目總總體體實實施方案施方案 建設 XXXxxx 軟件采購是一項復雜、長期的系統工程，為保證工程能夠順 利地進行實施，必須要制定科學、合理、切實可行的實施計劃。一方面要從組織 上進行落實，成立強有力的項目領導小組和經驗豐富的項目實施隊伍；另一方面 要制定嚴格的時間進度表，明確各里程碑的時間。同時還要制定工作原則，以指 導項目的全面實施。 1.1 工程工程實實施原施原則則 1用戶方項目小組的成員，爭取參與項目的全過程 用戶方成立領導親自掛帥的項目小組，在調研、設計、編碼、安裝調試、測試、 培訓、運行、驗收、售后服務等項目的各個階段，配合系統開發(fā)方的工作，一方面 可以培訓自己的技術維護隊伍，為系統的使用保駕護航；另一方面，在開發(fā)過程 中，協調用戶方和開發(fā)方的關系，保證項目的順利進行，及時發(fā)現問題，并對項 目進度和質量進行監(jiān)督。 2采用“兩手抓”的方針，一手抓開發(fā)、一手抓使用 對于軟件項目，之所以稱為一個工程，很大程度上是因為軟件項目的建設， 除了技術因素外，還有很多的非技術因素需要考慮，并且必須被得到重視。衡量 一個軟件項目是否成功，很大程度上不是看這個軟件項目采用了多么先進的技 術，而是軟件對用戶來說是否實用，是否能夠幫助用戶解決許多預期的問題。國 內很多軟件項目的失敗，很大程度上是使用抓得不夠。建議在項目的試運行過程 中，在抓系統維護的同時，也要狠抓系統的使用，開發(fā)方和用戶方齊心協力幫助 精選資料 可修改編輯 業(yè)務人員從原來的手工處理轉到計算機輔助處理上來，在業(yè)務人員適應計算機 輔助業(yè)務處理的過程中，盡可能早發(fā)現系統中存在的問題，從而最大可能地使系 統保質保量的按時完成。 3數據同程序同等重要 該系統的建設，數據位于首要的地位，程序的編寫完成，僅僅意味著系統完 成了一半，數據的收集、整理、錄入，對系統的建設來說同等重要。在項目實施過 程中，一定要重視系統中數據的錄入工作，充分估計數據處理的難度，在系統建 設之初，就將數據工作提到議事日程上來，安排相應的資金、時間等，將數據工 作落到實處，只有這樣才能爭取系統早日達到實用化。 1.2 項項目目總總體推體推進計進計劃劃 為了有效地保證系統開發(fā)的質量，整個系統建設的全過程劃分為準備、設計、 開發(fā)、實施和運行階段，每個階段完成相應的任務，確保信息系統的建設。 如下圖所示： 精選資料 可修改編輯 1.3 系系統實統實施施過過程的程的質質量保量保證證活活動說動說明明 在實施過程中將發(fā)生的重大質量保證活動或由此將產生的質量記錄和產品， 項目管理與開發(fā)階段劃分密切相關，因此主要按照項目實施的具體階段劃分說 明。 1.3.1 需求分析需求分析階階段段 首先需要經雙方協調，形成需求調研計劃及需求調研大綱，確定準備工 作、需求調研的內容、方法方式以及人員和日程安排等內容，經雙方同意后按此 計劃開始調研。調研正式開始前項目開發(fā)組應檢查所有必要的準備工作已經圓 精選資料 可修改編輯 滿完成。 項目開發(fā)組根據調研中系統實際技術需求和各個子系統的業(yè)務需求，編寫 并向工程領導小組提交符合 CMM LEVEL 3 規(guī)范要求的系統需求分析報告， 并由項目組評審，不合格的部分進一步完善調研；評審通過后由雙方共同簽署評 審意見，并正式生效。 對于軟件生產過程而言，需求階段是整個過程中最重要的階段，需求分析成 果的好壞將直接導致項目的成功與否，因此合作雙方在此階段多投入是值得的。 而且一旦評審通過并生效，則需求報告將成為系統的設計、開發(fā)、測試、實施試 運行和項目驗收的基本依據之一，因此原則上用戶需求將不再因為其它因素的 改變而變更，如需進行此種變更，需經雙方項目負責人協商確定。 1.3.2 總總體體設計階設計階段段 項目開發(fā)組通過對系統的功能、運行和性能要求加以分析，產生一個高層次 的系統結構、軟件結構、接口和數據格式的設計，并向工程領導小組提交系統設 計報告（其中包括數據庫設計），組織評審并簽署評審意見。對其中評審不合格 的部分進一步完善和重新策劃，評審通過后由雙方共同簽署評審意見，并正式生 效，作為后續(xù)軟件開發(fā)和測試的基礎。 該報告內容的變更由雙方的現場實施負責人、技術負責人進行交流即可確 定，并需向工程領導小組匯報。 1.3.3 詳細設計階詳細設計階段段 項目開發(fā)組在系統設計報告的基礎上，對功能和性能要求進一步加以分 精選資料 可修改編輯 析和細化并且把軟件的詳細設計文檔化，向工程領導小組提交系統詳細設計報 告，并由項目組組織評審并簽署評審意見。對其中評審不合格的部分進一步完 善和重新策劃，評審通過后由雙方共同簽署評審意見，并正式生效，作為后續(xù)軟 件開發(fā)和測試的基礎。 該報告內容的變更由雙方的現場實施負責人、技術負責人進行交流即可確 定，并需向工程領導小組匯報。 1.3.4 系系統統開開發(fā)階發(fā)階段段 根據前面的設計結果，由雙方的現場實施負責人、技術負責人討論確定詳細 的開發(fā)計劃，并向工程領導小組提交項目開發(fā)計劃；工程領導小組對項目開 發(fā)計劃進行審查，由雙方簽字后正式生效，并將作為軟件開發(fā)階段的項目管理 和監(jiān)控依據，項目開發(fā)小組要嚴格據此計劃控制項目進度，按時向工程領導小組 匯報工作進展。 為了使用戶能夠及時獲知項目的進展情況，開發(fā)小組需要每周向用戶相關 領導提交項目客戶周報，用戶項目組可以隨時對項目的工作情況進行檢查。 1.3.5 系系統實統實施和施和試試運行運行階階段段 首先需要經雙方交流協調，形成項目實施計劃，確定現場實施的準備工作、 人員和日程安排、培訓計劃、階段目標等內容，經雙方負責人簽字后生效，按此 計劃開始現場實施。正式開始現場實施前項目開發(fā)組應檢查所有必要的準備工 作是否已經完成。 現場工作首先要進行軟件在服務器端的安裝和調試，包括數據庫中各類對 精選資料 可修改編輯 象的生成，初始化數據，原有系統的重要數據的轉換導入，前后臺軟件的安裝， 配置參數調整等工作；完成后需向系統維護人員提交數據庫安裝目錄， 軟件安 裝方法文件，并協助用戶進行軟件安裝。 軟件安裝完成并確認可在系統正常運行后，開始相關業(yè)務人員的培訓；在培 訓開始之前需要由雙方協商形成培訓計劃，明確培訓環(huán)境、條件及方式，參加 人員，課程課時等詳細內容，由雙方現場實施負責人簽字后生效，并分別開始著 手準備，在既定時間內完成。 培訓過程中由工程師提供培訓考勤記錄，培訓應該脫產、集中、封閉進行， 并要求所有參加人每日必須兩次考勤；培訓完成后由雙方共同進行培訓總結， 針對培訓效果確定是否達到目標，是否再增加培訓課程；對以上內容用戶項目組 須進行必要的考核和獎懲，培訓工程師有權對參加培訓人員進行客觀評價。 培訓順利完成后將開始軟件在試點部門試用，將向用戶提交編譯后的前后 臺軟件， 軟件使用操作手冊， 軟件功能清單，這兩種文檔將詳細描述軟件的使 用過程，軟件所包含的全部系統功能模塊。 軟件試用期內用戶的主要工作是根據軟件功能清單所列的系統功能模塊， 檢查公司所提交的軟件是否滿足系統需求分析報告、 系統設計報告的規(guī)定， 列出未完成及含有較嚴重、明顯錯誤的模塊清單形成軟件問題及修改記錄并 提交給公司繼續(xù)完善；此段時間可以對軟件的細節(jié)性問題進行測試、驗證，但主 要精力還是應放在模塊級功能的檢查上，如果所有模塊都已開發(fā)并可以進入試 運行，其設計方法、技術可行性也都能夠滿足最終軟件的需要，則用戶各相關業(yè) 務負責人、現場實施負責人需要簽署各子系統的軟件交付書，表明軟件已在現 場安裝、調試、培訓完成，基本可以進入軟件試運行；此后在軟件功能模塊一級上 精選資料 可修改編輯 不應再發(fā)生大的變化，如需要修改功能模塊設計，則需由雙方項目負責人協商解 決。 試運行期內用戶負責組織針對軟件功能清單所列的系統功能模塊進行現 場的系統測試，包括新舊兩套系統并行工作一段時間進行驗證，使每個功能模塊 都得到基本確認；對于其中發(fā)現的問題和軟件的細節(jié)性修改意見，需以軟件問 題及修改記錄的書面形式提交給公司；公司修改完成后立即提交到現場，用戶 負責組織立即對軟件進行確認回歸測試，如驗證問題已修改需要在軟件問題及 修改記錄中予以說明。通過試運行及修改后證明已經基本完成的模塊，用戶應 組織相關的業(yè)務負責人在軟件功能清單中逐項確認。 1.3.6 項項目目驗驗收收階階段段 在試運行期內系統存在一定的細節(jié)性問題是工程項目不可避免的問題，特 別是隨著用戶應用的逐漸深入，此類需求會逐級提出，此類問題不屬于系統的致 命性錯誤；因此當試運行期內所發(fā)現的真正的“問題和錯誤”收斂到一定數目以下 時，各業(yè)務子系統經過一段時間的并行工作新系統已基本可靠，就可以切換到正 式運行階段，開始正式運行。 正式運行后，由用戶提出驗收要求，雙方共同制定項目驗收計劃，組成項 目驗收小組，共同進行項目驗收。此時公司將向用戶提交驗收的各類文檔，包括 對系統開發(fā)過程進行總結的項目總結， 項目技術報告，最終的完整的數據庫 字典等。 驗收工作將由用戶組織的專家組對系統進行全面的驗收和鑒定，并出具項 目驗收小組領導簽字的項目驗收報告，并簽署驗收意見，公司在此過程中將全 程參與，在現場進行驗收前的維護工作。 精選資料 可修改編輯 1.3.7 系系統統正式運行及正式運行及維護階維護階段段 公司承諾對系統軟件提供服務保證期，在保證期內提供免費的軟件升級和 維護服務；在保證期外，公司繼續(xù)為系統的維護提供技術支持，對于軟件升級提 供優(yōu)惠服務。 維護期的具體工作方式請見售后服務承諾部分，所有維護工作，包括軟件出 現問題修改、細節(jié)性功能的增強，用戶都要以軟件問題及修改記錄的書面形式 提交給公司，修改完成后用戶應組織相關的業(yè)務負責人進行確認，并在軟件功 能清單中說明；如遇緊急情況可事后補齊。 1.3.8 各各階階段段輔輔助文檔助文檔 現場工作日程安排計劃，在實施中的各階段，對于所發(fā)生的需要在現場進 行較長時間工作的情況，如果在需求調研計劃、 項目開發(fā)計劃、 項目實施計劃 、 培訓計劃等工作計劃中未包含，則需要在工作開始前雙方共同制訂好現場工 作日程安排計劃，并嚴格據此執(zhí)行，需要雙方現場實施負責人簽字生效。 現場工作周報，在現場實施工作中，為了把階段性的工作任務具體落實完 成，需要合作雙方每周一之前由公司實施工程師與用戶組共同制定本周的工作 計劃，給出每個工作日上、下午的工作內容，以及雙方的準備工作。計劃制定完 成后用戶項目組向所有相關部門和領導發(fā)布，開始執(zhí)行；實施中雙方互相監(jiān)督按 照原計劃開展工作；周五時雙方負責人共同對本周計劃執(zhí)行情況進行總結，對原 計劃填寫工作總結，詳細描述各項計劃的完成情況，未完成的部分應寫明未完成 原因和責任歸屬，必要時雙方協商一起進行加班處理，力爭按時完成；對于不能 按時完成的必須調整到下周計劃中進行。 精選資料 可修改編輯 用戶項目報告，對于實施中各階段較長時間不在用戶現場進行的，或項目 處于用戶試運行、維護期的情況，為了使用戶能夠及時獲知項目的進展情況和公 司開發(fā)小組的工作情況，公司將在開發(fā)階段每周向用戶相關領導提交此報告，維 護期內每月至少提交一次。 階段評估報告，實施中當某一階段性目標實現后，公司將對該階段雙方聯 合開發(fā)組的工作情況進行總結，編寫該報告并向工程領導小組提交，及時總結經 驗教訓，為下階段工作打好基礎。 1.3.9 實實施施過過程提交文件程提交文件匯總匯總 以下是對上面的實施過程中將產生的文件匯總說明： 階階段段名稱名稱作用作用評審級別評審級別變變更控制更控制 需求調研計劃 需求調研大綱 確定需求調研的準備工作、 內容、方法方式及人員和日 程安排 雙方現場實施 負責人 雙方現場實施 負責人 需求需求 調調研研 系統需求分析報告明確用戶業(yè)務需求 雙方項目負責 人 雙方項目負責 人 系統設計報告（其中 包括數據庫設計） 描述整個系統軟件的模塊 設計，詳細設計，數據庫設 計，供開發(fā)編碼使用 雙方項目負責 人 雙方現場實施 負責人設計設計 系統詳細設計報告 軟軟件件 開開發(fā)發(fā) 項目開發(fā)計劃 軟件開發(fā)的日程進度，分工， 檢查點設置，提交成果等計 劃 雙方現場實施 負責人 雙方項目負責 人 軟軟件件 測試測試 測試計劃 測試問題卡 測試總結報告 符合 ISO9000 質量保證體 系規(guī)定的功能測試、同行間 測試文檔 軟軟件件 現場現場 實實施施 項目實施計劃 確定現場實施準備工作、人 員和日程安排、培訓計劃、 階段目標等 雙方現場實施 負責人 雙方項目負責 人 系系統統 培培訓訓 培訓計劃 培訓考勤記錄 培訓總結 明確培訓環(huán)境條件及方式， 參加人員，課程課時等要求 培訓記錄，培訓效果總結， 是否達到目標 雙方現場實施 負責人 雙方現場實施 負責人 精選資料 可修改編輯 系系統統 安裝安裝 數據庫安裝目錄 軟件安裝方法 軟件使用操作手冊 現場安裝、調試和提交軟件 的相關文檔 軟件功能清單 所提交軟件全部模塊結構 劃分，功能描述 用戶系統人員 軟件交付書 軟件已在現場安裝、調試、 培訓完成，基本可以進入試 運行證明 用戶系統負責 人 軟件問題及修改記錄 實施中發(fā)現的軟件問題和 用戶提出的具體修改意見， 以及對其所作修改和確認 記錄 項項目目 驗驗收收 驗收計劃 驗收報告 項目總結 項目技術報告 數據庫字典 開發(fā)過程項目總結，技術總 結，數據庫設計字典等驗收 相關文檔 日常日常 工作工作 現場工作日程安排計 劃 需在現場進行較長時間的 一般工作日程安排 雙方現場實施 負責人 雙方現場實施 負責人 用戶項目報告 較長時間不在用戶現場時 向用戶信息服務系統匯報 項目進展和工作情況， 現場工作周報現場工作周計劃 雙方現場實施 負責人 雙方現場實施 負責人 階段評估報告 某階段性目標實現后進行 總結，向工程領導小組提交， 為下階段打好基礎 1.4 項項目目實實施施計計劃劃 XXXxxx 軟件采購的建設是一項龐大而復雜的信息化應用基礎工程，需要 分任務、分階段組織建設，逐步實現總體目標。 1.4.1 數據數據實實施步施步驟驟 1基礎信息 協調相關部門，采集基礎信息。 2公共信息 精選資料 可修改編輯 公共信息是多個業(yè)務部門共用的公共信息，包括人員、單位、信息、基礎設 施等。 3專用信息 專用信息是公章等信息。 1.4.2 項項目目進進度安排度安排 系統建設分階段進行， 第一階段至合同簽訂后 10 天，完成如下工作： （1）組織數據的采集 （2）硬件環(huán)境的搭建 第二階段，合同簽訂后 20 天，完成如下工作： （1）XXXxxx 軟件采購的搭建將部署 （2）二次開發(fā) 第三階段，合同簽訂后 30 天內，完成如下工作： （系統開始正式試運行 （BUG 修改 （系統性能調優(yōu) （系統培訓 （系統驗收 精選資料 可修改編輯 2 、 、項項目管理方案目管理方案 2.1 項項目管理目管理組織結組織結構構 2.1.1 項項目各方角色與目各方角色與責責任任 需要明確的是，該系統是一個由用戶、系統供應商、其他系統供應商、設備 提供商等多方面共同組成的項目組實施。而這個項目組是由項目管理辦公室領 導。 項目管理辦公室是由用戶和系統供應商的高層領導人組成，這樣可以充分 保證項目實施能被正確的指導和推動，可以迅速解決在實施過程中出現的不可 預測的原則性問題。 項目管理辦公室中的用戶成員有責任推動相關工作人員密切配合項目實施， 對中心內部各部門所要達到的項目目標有清楚的定義，明確責、權、利關系，與 項目組一起做好工作。 項目經理必須隨時向項目管理辦公室報告整個項目進展情況，向項目管理 辦公室負責，采取正確的實施行動來完成項目實施工作。 雙方在項目中的角色和責任如下： 單位責任 用戶業(yè)務系統的現狀調查、分析； 提出項目需求； 組織方案驗收 系統供應商項目管理 負責系統連接或軟件部署、配置、軟件開發(fā)等技術文件； 負責項目實施；提出項目測試計劃， 配合項目驗收 精選資料 可修改編輯 產品提供商提供產品的技術支持服務 在客戶特別指明時提供產品安裝調試服務 2.1.2 任任務務分工分工 在項目的實施過程中，如果沒有明確的任務分工，將會造成“職責不清”的混 亂局面，使工作關系與任務分配陷入多種的關聯交叉狀態(tài)，導致項目人員“不知 所措、不知何往”，這將嚴重影響對項目的反應能力與控制能力，最終影響實施的 進度與實施的質量。 所以要完成好一個項目，建立起一個完善的組織架構后，組織中必須要有明 確的分工，做到“各負其責”，但同時需要有統一、有效的領導機構，作到“協調一 致”，才能保證整個項目的實施。XXXxxx 針對本項目的具體分工如下： （1）項目管理辦公室： 將由用戶項目部領導以及 XXXxxx 管理層的相關負責人構成，建議與決定 項目管理組人員的組成，接受項目管理組的匯報，指導與監(jiān)督項目管理組工作， 對重大問題作出決定，確保項目實施所需要的資源。 該小組在宣布中標后成立，項目驗收后結束。 （2）專家顧問組： 將由用戶、XXXxxx、高級專家顧問組成，在整個項目執(zhí)行過程中起顧問咨 詢等作用。 該小組在宣布中標后成立，項目驗收后結束。 （3）項目管理組： 接受項目管理辦公室的領導與監(jiān)督，向項目管理辦公室匯報；由用戶、 XXXxxx 的項目管理人員組成，XXXxxx 指派一名項目經理任組長。該組負責協 精選資料 可修改編輯 調各相關單位的關系，處理所出現的各種問題；組織各個專業(yè)小組，制定項目總 的實施進度計劃，推進項目進度，解決工程中出現的各種問題。 該組在項目管理辦公室成立后設立，項目驗收后結束。 （4）商務組： 接受項目管理組的領導，向項目管理組匯報，制定詳細的商務計劃，負責商 務投標，合同的簽署，按照合同定貨，跟蹤；處理合同執(zhí)行過程中由于合同條款的 修改與變動而帶來的各種問題。 該組在項目管理組成立后設立，項目驗收后結束。 （5）財務組： 接受項目管理組的領導，向項目管理組匯報，制定資金運作計劃，負責財務 成本核算、成本控制、財務審計等，保證整個合同過程中各個階段、各個方面的 資金需要。 該組在項目管理組成立后設立，項目驗收后結束。 （6）培訓組： 接受項目管理組的領導，向項目管理組匯報，制定詳細的培訓計劃，負責協 調與實施所有的培訓工作，完成培訓的組織、培訓內容的審定、培訓人員的落實、 培訓場地的聯系、培訓過程的組織、培訓結業(yè)考試的組織、培訓工作總結，按照 合同規(guī)定完成所有培訓工作。 該組在合同簽署后設立，全部培訓工作完成后結束。 （7）文檔組： 接受項目管理組的領導，向項目管理組匯報，制定詳細的文檔遞交計劃，負 責收集與整理各個階段的技術文檔，按照合同規(guī)定完成所有的文檔遞交工作。 精選資料 可修改編輯 該組在項目管理組創(chuàng)立后設立，驗收完畢，文檔全部遞交后結束。 （8）技術核心組（架構設計組）： 接受項目管理組的領導，向項目管理組匯報，由用戶與 XXXxxx 的技術核 心人員組成。 負責制定詳細系統設計、完成模型實驗與測試報告、終端設備參數修改測試 報告，并對系統實施過程中遇到的突發(fā)技術問題給予研究解決。 該組在項目管理組創(chuàng)立后設立，驗收完畢后結束。 （8）設計施工組（開發(fā)組）： 接受項目管理組的領導，向項目管理組匯報。 主要工作包括負責項目實施的技術細節(jié)方案設計、設備精確配置、精確物理 連接圖及設備位置安排等工作；給出詳細設計的文檔、圖紙、資料及工程安裝手 冊；完成文檔、圖紙和技術資料的質量審核；勘查施工現場環(huán)境；軟件安裝調試的 細節(jié)方案設計、協調組織現場軟件安裝調試；軟件集成所需的功能定制開發(fā)、接 口定制開發(fā)。 該組在合同簽署后設立，測試驗收工作全部完畢后結束。 （9）驗收組： 接受項目管理組的領導，向項目管理組匯報，負責現場實施的質量控制，以 確保工程高質量、高效率地完成；制定詳細的驗收計劃，負責編寫測試驗收手冊、 對安裝后的系統進行測試與預驗收、進行驗收準備工作、配合用戶驗收小組對系 統進行最終驗收，按照合同規(guī)定完成所有的測試與驗收工作。 該組在安裝調試工作開始后前設立，驗收完畢后結束。 精選資料 可修改編輯 2.2 項項目范目范圍圍管理管理 項目管理范圍包括本項目建設周期內各個階段以及所有相關的建設單位、 設備、軟硬件、場地等內容，從軟硬件采購、需求分析、系統設計、軟件開發(fā)、系 統集成、測試、驗收、試運行、系統維護的全過程都包括在內，如項目啟動、項目 范圍內容、項目范圍變更等項，具體內容在項目實施前經詳細討論確定。 2.3 項項目目進進度管理度管理 針對本項目的進度管理從任務分解、時間進度安排到資源分配，每個階段都 有里程碑標志，每個階段都須嚴格按照工期要求按時、保質完成，項目經理負責 項目進度控制。 2.4 項項目目風險風險管理管理 通過對大量的風險事件進行分析，在本項目中下列事件出現的概率最大，影 響也是最大的。如何使得將上述事件對項目造成的影響降低到最小，是項目風險 管理的主要工作。首先需要預防上述事件的發(fā)生，其次當事件發(fā)生不可避免之后， 應當采取必要的、事先準備好的措施進行工作，將風險對項目目標的影響降低到 可以容忍的程度。 2.4.1 技技術風險術風險 XXXxxx 軟件采購是一個采用先進的信息技術，在建設過程中需要與各個 業(yè)務單位、多個技術支撐系統、多個業(yè)務系統之間接口。系統需要采集的數據量 大、涉及的相關系統范圍廣，需要比較高的信息管理的專業(yè)知識。因此系統建設 精選資料 可修改編輯 存在一定的技術風險，需要業(yè)主和系統建設方從系統開始建設之初，就要充分認 識到該項目的技術難度，在系統調研、系統設計階段就要進行反復的論證，在系 統構架的時候盡可能采用國際上成熟的產品，借鑒相關的成功經驗，同時系統的 建設分步驟、分階段進行，將技術難點逐個突破，力求將技術風險降至最低。 2.4.2 需求需求風險風險 XXXxxx 軟件采購的建設是一個項目周期較長、涉及相關部門較多、數據量 大、系統功能要求高的復雜系統，只能在建設過程中與多家業(yè)務部門進行溝通， 才能逐步明晰系統的需求。同時，由于 GIS 專業(yè)性較強，有些需求各業(yè)務部門人 員根本不可能明確地提出，需要系統建設方根據已有的系統建設經驗進行用戶 需求的引導。這些狀況容易造成系統的需求不明確，或者系統的需求變更頻繁， 使得項目進展嚴重滯后，最后造成項目的失敗。 為了能夠減少該項目需求不清和需求頻繁變更的風險，需要用戶和公司在 項目初期做好充分的需求調研，切實理解各個業(yè)務部門在信息方面的業(yè)務需求， 盡可能避免對需求的誤解和片面性。同時，在系統建設過程中，嚴格遵守項目管 理的規(guī)章制度，對項目需求變更進行嚴格的審核與控制，以保障項目的質量和進 度。 2.4.3 協調協調與溝通與溝通風險風險 在系統建設過程中公司需要協調多個部門，與這些部門的溝通與協調可能 直接影響到本項目的質量與進度。因此，建立高效的協調與溝通機制，減少相互 之間的誤解與拖延，是保障本項目成功實施的關鍵點之一。這需要各相關單位充 分理解項目溝通管理的重要性，嚴格遵守項目管理的各項規(guī)章制度，提高協調溝 精選資料 可修改編輯 通的效率，降低項目協調與溝通的風險。 2.4.4 項項目人目人員風險員風險 由于 XXXxxx 軟件采購項目周期較長，技術難度大，因此項目人員壓力會 隨著項目的進展逐漸加大，工作效率也可能會隨著項目的進展逐漸降低，造成工 作效率低下，甚至會造成項目成員的不穩(wěn)定。這就需要用戶與公司相互理解，明 確共同的目標，發(fā)揮團隊精神，同時要合理規(guī)劃項目進度，作到勞逸結合，提高 項目人員的積極性，降低項目人員的風險。 2.5 質質量管理量管理計計劃劃 2.5.1 質質量管理體系量管理體系標標準準 本項目實施應采用先進的質量管理模式和科學的質量管理體系和流程，并 根據項目自身特點選用合適的質量控制規(guī)程。 目前，XXXxxx 主要采用 ISO9001 質量標準和軟件成熟度模型（CMM）兩種 控制規(guī)程。針對本項目，公司將采用 GB/T 19001-2000ISO9001:2000 質量體系 標準，同時遵循 SSE-CMM 的安全實施標準，并在項目實施的過程中嚴格執(zhí)行這 些質量標準。 2.5.2 質質量控制量控制過過程程 本項目中，由項目經理制訂質量控制計劃，項目質量控制組進行審核。審核 方面包括：質量控制措施是否足夠、各個成員的質量責任是否明確合理，測試方 法是否適用。 精選資料 可修改編輯 2.5.3 質質量量評評定定計計劃劃 為了加強項目質量管理和界定產品質量標準，本公司將制訂適應于項目的 檢查驗收規(guī)定和質量評定標準，確保工程質量。 本項目中，應實行兩級檢查、兩級驗收制度。一級檢查、二級檢查和一級驗 收由本公司實施小組組織完成；二級驗收由用戶組織實施。各級檢查驗收嚴格按 項目實施中制訂的相應的檢查驗收規(guī)定和質量評定標準執(zhí)行。對實施和驗收過 程中出現的重大技術問題，將上報用戶協調處理，對一般質量問題的處理應予以 書面記錄。 2.5.4 質質量管理措施量管理措施 在項目實施過程中還將采取如下措施保障項目實施質量： （1）產品到貨后，對所有硬件設備應進行加電檢測，同時對所有軟件產品進 行安裝、產品授權驗證。 （2）在項目實施前后對網絡性能進行評估。 （3）在系統部署完成后要在實際環(huán)境中進行網絡連通性測試、安全策略驗證 和應用系統測試。 （4）配合應用系統做好壓力測試，根據壓力測試結果調整系統配置。 （5）項目實施后要進行一定時間的試運行，在試運行期間要重點監(jiān)控網絡環(huán) 境的運行情況、安全策略的驗證和業(yè)務應用系統運行情況，若出現的問題要及時 查找原因并加以修正。 （6）在試點實施過程中驗證方案的可行性和正確性。 精選資料 可修改編輯 2.5.5 軟軟件件質質量控制量控制 2.5.5.1階階段性段性評審評審 軟件質量保證過程包括對軟件過程質量控制和軟件產品質量控制。我公司 在本系統項目組織中，由質量控制組負責質量控制和管理，采用軟件度量過程采 集信息對軟件過程和軟件產品的質量進行管理。 對軟件過程質量的控制通過量化并提取軟件過程信息實現對軟件過程的目 標管理，量化的主要內容包括：產品質量、項目進度和資源占用。軟件過程控制一 般采用軟件開發(fā)過程的節(jié)點控制的方法。 軟件開發(fā)過程的節(jié)點控制是提高軟件開發(fā)的計劃性和成功經驗的可重復應 用的重要支持手段。我公司在開發(fā)本系統的過程中，將充分利用該方法，確保本 系統的高質、準時完成。在本系統的開發(fā)過程中，把涉及軟件開發(fā)、應用的人員 分為甲方、乙方，甲方代表各種層次的軟件系統的用戶，乙方代表軟件開發(fā)商中 各組織、各層次人員。軟件系統的最終成功基于甲乙雙方對軟件開發(fā)過程的共同 控制與管理，甲方側重“需求” 與“監(jiān)督”職能，乙方側重“供求”與“控制”職能。甲 乙雙方實現職能的基礎是軟件開發(fā)過程的可視性，即從甲乙雙方角度得到軟件 開發(fā)過程的可見性。如下圖所示： 精選資料 可修改編輯 圖（a）表示一個對甲乙雙方可見性極差的過程，甲方給出需求后，經過乙方 的開發(fā)過程得到的是最終結果，甲方對軟件開發(fā)過程沒法參與。乙方中只有具體 的開發(fā)人員了解局部的軟件過程，高層管理人員沒法得到開發(fā)過程中具體的過 程狀態(tài)信息，不能根據過程狀態(tài)做出決策。 圖（b）表示一個對甲乙雙方可見性較好的軟件過程，在軟件開發(fā)過程的特定 階段設置階段控制點（也稱為里程碑），甲乙雙方依據階段成果，從各自的角度提 出過程改善與修改意見，控制軟件系統生產的質量、開發(fā)過程的效率及項目資源 消費。 2.5.5.2測試測試 測試是確保本系統質量的重要手段，不經過認真測試的系統是不能被用于 生產的。雖然，對各階段的文檔的審核也可認為是測試，但本項目所指的測試是 指對應用軟件的測試。做好測試是測試組的責任，測試組是與開發(fā)組相互獨立的 兩組，且需要相當的技術和經驗，對業(yè)務的理解要十分透徹。為保證測試的效率 和質量需要主意以下幾點： 1建立高效合理的測試流程，包括： 建立盡量模擬真實環(huán)境的業(yè)務數據模型（即運行業(yè)務的初始環(huán)境）； 精選資料 可修改編輯 對測試案例的設計要有深度和廣度； 特別在系統測試和驗收測試階段，安排好項目組的全體人員的任務和責任； 做好測試階段文檔和源程序的版本控制； 做好測試中發(fā)現的 BUGS 的記錄及存檔工作； 對發(fā)現的任何 BUGS 都要做好原因分析并記錄歸檔； 做好回歸測試； 防止對程序的修改而引起的其他問題。 軟件測試是一個過程，涉及到軟件生命周期的各個階段。下圖描述了軟件測 試過程模型： 測試過程是與開發(fā)過程并行的，軟件測試的實施過程是與改錯過程既是交 錯的、同時又是并行進行的。在集成測試階段中，測試一般應當由獨立的軟件測 試人員來實施。這種方法一方面可以有效地壓縮測試的總周期，但更重要的是可 以避免開發(fā)者自身的思維局限，更加客觀全面地進行有效的測試。 精選資料 可修改編輯 2.6 項項目目協調協調與合作與合作計計劃劃 對項目實施中的溝通是項目完成的順利與否的重要因素，所以在整個項目 實施的過程中要有一套完善的溝通機制。 2.6.1 協調協調與合作管理方案與合作管理方案 在項目實施中，將以項目經理為核心，實現全面、有效的溝通管理。其中： （1）項目經理從始至終控制整個項目的工作進展與步驟，是信息的收集者和 發(fā)送者。 （2）項目經理要密切聯系了解各干系人信息，及時傳達給項目組其他成員。 （3）項目經理要每周與項目領導小組交換項目工作進展情況，確保項目按計 劃有步驟地進行，并提交全部項目管理報告給項目領導小組。 （4）項目經理要每周組織項目組成員召開會議，了解項目進展情況，分派工 作，了解項目實施中的問題，及時解決。 （5）項目主管定期聯系用戶負責人，傾聽用戶對項目的建議和意見，并采取 相應的措施，最大程度保證用戶滿意度。 （6）銷售人員和用戶保持正常通暢的溝通渠道，及時接受用戶反饋意見。 2.6.2 協調協調手段手段 作為溝通的手段，采用如下方式進行項目的交流： （1）進程報告（工程簡報）：工程實施期間，各實施人員每天向項目經理報告 工作進展；項目經理按照 ISO9000 質量管理體系的要求每周向公司提交項目進 展報告；同時，項目經理每周向用戶單位提交項目進展文件。 精選資料 可修改編輯 （2）周例會：必要時參加由項目管理組、用戶方在每周共同召開的周例會，會 議將對一周以來的工作進展進行回顧，總結問題點，分析原因，并確定解決方案。 對下一階段的工作任務進行部署。會議結果由項目管理組發(fā)布會議紀要。 （3）工程階段總結：在實施的每一個階段，進行工程階段總結，評估上一階段 工作得失，為下階段的工作進行必要的預溝通，解決隱患問題； （4）多種形式的交流：項目經理與項目領導小組、用戶、其它廠商之間、以及 項目隊伍成員之間保持通信聯絡，以傳真、電話、電子郵件等方式進行溝通。 2.7 配置管理配置管理 2.7.1 配置管理和版本控制配置管理和版本控制 公司采用相應的配置控制程序來管理新系統的各個部分，包括文檔，需求， 設計，數據庫設計，編碼，文件和數據。并在項目實際實施時制定配置管理計劃， 并委任一名配置管理員。 配置控制的目的是控制系統的物理和功能特性，確保整個系統的完整性。配 置控制既是技術活動又是管理活動，它的過程包括： 配置項目發(fā)現和保存 每個配置項目要有一個編號，用來區(qū)別有不同需求和實施要求的其它項目。 它還有一個版本號，用來標明該項目所處的階段，在配置項目修改時，版本號要 更新。配置系統要能夠容納新的配置項目，不必修改現存項目。 配置項目要保存在軟件庫里面。為確保足夠的安全以及對所有可交付軟件 項目的控制必須建立如下典型的軟件庫： 名稱狀態(tài) 精選資料 可修改編輯 開發(fā)庫動態(tài)的 主庫控制的 靜態(tài)庫靜態(tài)的 開發(fā)庫是軟件作為一系列模塊進行開發(fā)和測試的動態(tài)庫。主庫是一個被控 制的庫，項目的放入和取出必須按規(guī)定并以一定的控制方式進行。例如，在單元 測試成功之后，模塊可以被轉入到系統主庫，然后供系統集成和系統測試。任何 經過以上測試需要修改模塊都要放回開發(fā)庫，以供測試。 當主庫達到一定程度的穩(wěn)定后，就可以將它合成一個基準。每當基準發(fā)布以 后，相關主庫都要進行拷貝產生靜態(tài)庫。之所以叫做靜態(tài)庫，因為以后不再更新， 并且歸檔。 2配置變動控制 只有當項目已經成為基準的一部分時，軟件配置控制才能夠進行，它主要控 制： 評估對配置項目的變動 協調批準的變動 在本項目的執(zhí)行過程中，項目經理將與用戶一起定義處理配置變動以及變 動授權管理方法。作為對于已經通過的單元，系統的驗收測試項目的變動，需要 更高級別的授權。 3配置狀態(tài)記錄 配置狀態(tài)記錄包括所有配置項目跟蹤報告，并且貫穿整個系統開發(fā)周期中， 配置項目狀態(tài)將通過配置管理員來跟蹤和控制。 為有效進行配置狀態(tài)記錄，應該詳細記錄以下信息： 每個基準版的日期，版本和問題； 精選資料 可修改編輯 每份問題審閱以及文檔修改的日期狀態(tài)； 每份軟件問題報告、修改請求、和修改報告的日期和狀態(tài)； 每個配置項目的總結描述。 軟件版本 公司將在版本文檔內記錄軟件的版本，后續(xù)版本要附一個版本說明。該說明 列出了版本內的配置項目，并且說明其安裝步驟。而且，所有已經修改的錯誤和 已經合并的新的需求都要有記錄。要在提交新版本之前重新測試修改過的軟件。 對于每個版本公司保證文檔和代碼的一致性，而且保存舊版本。 2.7.2 變變更管理的方法更管理的方法 產品的完整性需要通過變更管理來維持。用戶需求的變化、系統需求的變化 和系統設計的變化都被監(jiān)控和跟蹤，從而了解被批準變動的實施狀態(tài)?？刂谱兏?的目的是為了確保只有經過批準的變更才能實施，確保變更情況傳達到了相應 的有關方面，提供它們考慮和獲得它們的批準。 用戶需求、系統需求和系統設計文檔在通過評審并批準后將作為基準。當一 個文檔變?yōu)榛鶞室院螅妥詣舆M入變更控制范圍。任何變動都需要提交變更請求。 變更管理由以下四個部分組成：變更請求、變更評估、變更批準、變更實施和跟蹤。 2.8 文檔管理文檔管理 文檔必須真實地反映實際工程狀態(tài)。 文檔的驗收，不能是在項目驗收時統一移交給用戶單位，而應當根據項目實 施的不同階段，分批移交，在項目準備階段就需要制定一個文檔移交計劃，在規(guī) 精選資料 可修改編輯 定的時間里移交事先規(guī)定格式、內容的文檔。 2.9 人人員員管理管理 人員的管理遵循幾條原則：本項目中的參與人員在無特殊情況且未經用戶 同意不進行調換；系統保障期人員均安排參加此項目建設的主要技術人員；本項 目的項目管理人員安排具有同類項目豐富項目管理經驗的人員。 2.10保密管理保密管理 考慮本系統的保密要求，公司承諾按照涉及國家秘密計算機系統要求進行 系統建設的保密管理，并和用戶簽署保密協議，嚴格履行保密義務。 精選資料 可修改編輯 3 、 、測試計測試計劃劃 3.1 測試測試工作準工作準備備 為保證項目的質量，XXXxxx 將成立專門的項目測試小組，在項目經理的統 一領導之下，完成本次項目的測試工作，首先，在項目開始時，測試小組要完成 測試的準備工作，測試準備工作的重點主要包括以下幾個主要方面： 對整個項目情況進行調研與了解，以熟悉整個系統的整體架構和實現功能 等相關情況，制定出初步的測試計劃； 確定測試管理工具的實施方案，對測試管理工具根據項目的特點進行合理 規(guī)劃；包括根據各個項目子系統的特點，制定相應的缺陷跟蹤方案、版本提交計 劃等。 保證測試人員的到位，并對測試人員進行測試管理工具和測試相關基礎技 術的培訓，要求相關系統測試人員先進行相關系統體系結構和功能的了解，為后 期的設計測試用例奠定基礎。 3.2 軟軟件開件開發(fā)測試發(fā)測試 本項目采用的測試種類包括：模塊測試、功能測試、性能測試、分系統測試、 全系統測試、容量測試、壓力測試、災難恢復測試等。 在進行測試前，需要編寫詳實的測試方案，其中包括測試時間安排、測試準 則、測試用例、測試范圍、測試目標、測試人員、出錯處理流程及處理結果等內容。 在測試案例中應包含對異常情況處理的測試，如數據不全、數據類別有誤、數據 不合法等。 精選資料 可修改編輯 各種類型的測試都是采用循環(huán)往復的“測試改進”操作，以確保問題得到 完整、充分的解決的過程。 3.2.1 模模塊測試塊測試 每個應用程序模塊完成后，進行模塊測試。模塊測試的目的在于通過大量、 反復的測試，盡可能地捕獲程序編寫時的編碼及應用處理上的錯誤，并加以改正， 使程序編寫時的錯誤在這一測試環(huán)節(jié)得到控制。 3.2.2 功能功能測試測試 功能測試是對項目實現的功能進行測試。功能測試可細分為：獨立測試和連 續(xù)測試兩部分。 獨立測試是將本項目開發(fā)實現的功能一一進行獨立測試。在測試過程中，將 針對每一個功能制定相應的測試個案，進行嚴格的功能測試。如測試結果與實現 要求不符，將由開發(fā)人員進行改進及完善，最終達到功能要求。 測試中發(fā)生問題時，編程人員會改動程序以便解決問題。系統將在修改后進 行重新測試。此時其進行的測試不僅針對改動部分，還應對原已通過獨立測試的 部分進行重新測試。 3.2.3 性能性能測試測試 系統的性能是一個很重要的參數，本項目所指的系統性能包括系統的效率、 響應時間及處理能力。在測試中，為每個應用設置響應時間、處理速度量度，評 估系統的最高處理能力，在發(fā)現系統的性能不滿足要求進，需進行相應措施對系 統的性能進行調整。 精選資料 可修改編輯 3.2.4 分系分系統測試統測試 針對各個分系統，根據不同的測試方案，按照測試方案中的測試步驟進行測 試，進行測試結果分析，得出測試結論，對分系統的配置給出建議意見。 最終對每一個分系統做出一個分系統測試報告，主要內容為測試結果，結果 分析，建議。對系統功能、性能、安全、可靠和擴展等每一方面都需有明確的結論 和意見。 3.2.5 全系全系統測試統測試 在分系統測試完畢的基礎上，對整個硬件平臺進行測試，主要針對各分系統 的結合部，以及總體功能。與分系統測試方案一樣，全系統測試也是根據測試方 案按照測試方案中的測試步驟進行，最終做出系統測試報告，主要包含：系統功 能、性能、安全、可靠和擴展等各個方面能否達到設計要求的結論，出現問題，建 議解決問題方案。 3.2.6 容量容量測試測試 項目在投產前，建議進行容量測試，以找出項目投產后可處理的最大處理容 量，確保能夠平滑地過渡或避開業(yè)務處理高峰期。與此同時，通過對業(yè)務處理高 峰期時系統硬件資源情況的占有量的獲取，能夠有效地調配系統資源。 通過容量測試，得知系統承載量，并結合業(yè)務發(fā)展增長量，可以推算出需要 更換相關硬件的時間，以便用戶可以提前做好應對準備。 精選資料 可修改編輯 3.2.7 壓壓力力測試測試 壓力測試的目的是希望能夠通過測試，得知在極短時間內對網站進行大量 并發(fā)訪問，是否會對系統造成瞬間無法承受的壓力沖擊，致使其運行異常甚至崩 潰。壓力測試可以獲知系統的耐壓程度，在必要時采取適當的緊急防護措施，如 控制、分散等措施，減低緩解系統瞬間壓力，防止尖峰時刻的出現，使系統得以 穩(wěn)定地運行。 3.2.8 災災難難恢復恢復測試測試 災難恢復測試是指在模擬災難事故發(fā)生的情況下，對系統的恢復情況進行 測試及彩排。要盡可能地找出可能發(fā)生的災難性事故，并一一進行模擬，查看系 統的恢復情況。災難恢復測試能夠反映出系統備份的準確性及完整性，以及自動 恢復功能的強弱，出具不同災難恢復所需的時間數據，以此可以估算出在災難發(fā) 生時對用戶所造成的影響及忍受程度。 3.3 設計測試設計測試用例和數據用例和數據 測試用例和數據準備的目的是幫助用戶在不熟悉實際環(huán)境的時候，能正常 的測試系統并對系統做出正確的評價。 測試用例和數據的準備是一項枯燥和費時間的工作。為了提高工作效率可 以從以下幾方面著手： 將信息放在一個指定的位置，便于反復利用，降低變化產生的影響； 一次完成一個步驟，避免冗余和額外的工作； 盡早盡可能完成多個步驟。 精選資料 可修改編輯 為了保證每一個業(yè)務流程準備測試用例和數據的正確性，在測試計劃中應 遵循下列過程，并完成以下步驟： 確定要測試的業(yè)務情況類型 確定每個要求的測試用例 合并所有的測試用例，生成測試大綱 編制測試腳本，包括必要的系統輸入信息和期望的輸出結果 檢查信息保證每一步的準確性和完整性（即，確定業(yè)務情況類型、確定測試 用例、生成測試大綱和編制測試腳本）。 3.3.1 建立建立測試環(huán)測試環(huán)境境 為了預防出現問題，如數據損壞或對系統資源的爭用，需要建立一個獨立的 測試環(huán)境。在進行測試之