【正文】 工程師；若驗證不通過，則記錄驗證花費的工作量后返回繼續(xù)修改。 變更 關(guān)閉 配置管理工程師執(zhí)行入庫檢查，確認通過后更新入庫。當所有變更內(nèi)容都入庫后，配置管理工程師升級相關(guān)基線版本，關(guān)閉變更，并通知受影響的相關(guān)人員。 配置管理 對項目的各階段產(chǎn)出進行及時、合理的管理，是確保軟件質(zhì)量的重要手段，也是確保軟件具有強大生命力的重要措施。 項目開發(fā)成員每周五下班前將整合好的工程源代碼版本（必需通過編譯）加密上傳到 XX 公司 FTP 服務器 ； 項目組每兩周以及里程碑階段提供階段軟件版本進行代碼評審； 項目經(jīng)理按照項目計劃按期提交項目相關(guān)文檔等相關(guān)配置項供 DVN 評審； XX 北京研究院的配置管理人員進行配置管理， QA依照配置管理規(guī)范的要求對配置管理員的工作進行監(jiān)督。 項目經(jīng)理、開發(fā)負責人及與會人員總結(jié)上周工作情況，對照《項目開發(fā)計劃》，分析進度、技術(shù)活動、人員和項目軟硬件資源的實際執(zhí)行情況和變化情況，并對于可能帶來的項目風險或項目變更進行討論。項目經(jīng)理與開發(fā)負責人協(xié)商合理安排 本周工作， QA記錄問題到《項目狀態(tài)跟蹤報告》中的相應位置，會議結(jié)束后 QA將記錄完整的《項目狀態(tài)跟蹤報告》發(fā)送給項目相關(guān)人員和相關(guān)領(lǐng)導，并按配置管理相關(guān)要求提交給配置管理工程師存入配置庫中。要保障外包業(yè)務的順利進行，必須建立有效的溝通渠道 。 項目責任與權(quán)利 XX北京研究院 （ 委托方 ） （承包商） 活動 成果 活動 成果 提出并確定項目開發(fā)需求，確保需求可行性和無二義性 ， 遵循變更控制的前提下對需求有補充或變更的決定權(quán) 項目外包合同樣本 《 項目 需求 規(guī)格 說明書》 討論稿、各種技術(shù)及管理規(guī)范 協(xié)助提出和補充需求 應標相關(guān)文件材料 對需求進行技術(shù)評審，對需求定義擁有解釋和決定權(quán) 《 項目 需求 規(guī)格 說明書》 合同稿 對需求進行技術(shù)評審，對需求定義擁有建議權(quán) 無 跟蹤監(jiān)督計劃制定過程 《項目狀態(tài)跟蹤報告》 制定《項目開發(fā)計劃》，包括人力資源計劃、項目進度計劃、 項目資源計劃、風險管理計劃、產(chǎn)品維護計劃等，各階段應明確輸出成果。雙方確定驗收的時間、地點、參加人員等。 驗收測試 驗收人員對交付的產(chǎn)品進行全面測試，確保產(chǎn)品符合需求。 如果工作成果存在嚴重缺陷，則退回給 承包商 。如果給驗收方帶來了損失，應當按合同約定對 承包商 做出相應處罰。 16 成果交付 當所有的工作成果都通過驗收后， 承包商 將其交付給外包管理小組。外包管理 小組項目經(jīng)理 通知 公司商務相關(guān) 人員， 履行 合同 相關(guān)事 宜 。 每期付款由項目負責人 向財務部門提出付款申請，并 填寫 《 銀行請款單 》 時，隨單附以下信息： 1） 承包商 的請款書，內(nèi)容至少包括：截至請款日已完成的工作量，實際進度與原計劃對比表，截至請款日已收到項目款金額，本次申請項目款金額等信息； 2）我司項目負責人出具的請款說明，內(nèi)容至少包括：截至請款日 承包商 已完成的工作量，是否按計劃完成及對 承包商 已完成工作的評價，是否同意按 承包商 的請款要求付款。 涉及到項目金額發(fā)生變 更的，參見 變更控制管理 。 商務管理 部門負責建立和管理所評定合格的 承包商 檔案，合格 承包商 檔案至少應包括以下內(nèi)容： 1) 合格 承包商 評定記錄（如質(zhì)量體系審核等） 2) 合格 承包商 證明材料（如質(zhì)量證書、用戶意見及自然狀況等） 3) 業(yè)務往來材料（項目監(jiān)控等） 定期復評 商務管理 部門 每個年度對已評 定的 承包商 進行定期復評，重新編制 《 合格 承包商 名錄 表》 。 當已評定合格的 承包商 所提供的產(chǎn)品 /服務出現(xiàn)質(zhì)量不穩(wěn)定現(xiàn)象時，應對其進行重新評定，對評定不能通過的 承包商 ，取消合格 承包商 資格。 當評定標準根據(jù)公司規(guī)定進行相應調(diào)整時， 應將情況及時通報合格 承包商 。 項目 籌備 進入準則 公司評審委員會 決策需外包開發(fā)。 在立項階段， XX北京研究院成立外包項目管理小組，負責外包項目相關(guān)事宜， 外包管理小組的主要負責人是 外包項目經(jīng)理， 主要負責 歸口外包項目 所有 工作，總攬技術(shù)把關(guān)，成為 公司開發(fā)部門 及商務相關(guān)與 外包公司的銜接窗口。 除了商務溝通和決策，技術(shù)相關(guān)事宜均由項目經(jīng)理與 外包公司部門技術(shù)主管打交道 和作決定。 承包商 根據(jù)項目需要，組建自己的項目團隊，保證項目執(zhí)行過程中對人員要求的充分必要性。 輸出 無 退出準則 承包商已確定。 輸入 《 項目需求 規(guī)格 說明書》 初稿。 承包商 在實施項目之前 需要跟 XX外包管理小組 進行需求的 深入了解 和溝通 ，對某些不明確的需求 進行 討論，并達成一致，形成項目的最終需求 文檔《項目需求 規(guī)格 說明書》 提交給外包管理小組 。 退出準則 由外包管理小組負責組織雙方召開 需求評審會，《 項目需求 規(guī)格 說明書》 評審通過 。 輸入 《需求規(guī)格說明書》終稿 。 在制定項目計劃的過程中， 承包商 要有 風險管理意識 ， 一定要對項目潛在的風險進行合理的估計和預防，逐項列入《 項目開發(fā)計劃 》的風險管理計劃中。 項目管理計劃模舨可參考附錄 《項目開發(fā)計劃》 模板。 退出準則 由外包管理小組負責組織雙方召開開發(fā)計劃評審會， 《 項目開發(fā)計劃 》評審通過。 系統(tǒng)概要設計 經(jīng)過嚴格的需求評審后，項目團隊已經(jīng)獲得了《 項目 需求規(guī)格說明書》和《項目開發(fā)計劃》。系統(tǒng)概要設計的主要內(nèi)容包括系統(tǒng)結(jié)構(gòu)設計、用戶界面設計、數(shù)據(jù)庫設計等，各部分的設計都需相應的設計評審。 輸入 《需求規(guī)格說明書》終稿、《項目開發(fā)計劃》終稿 系統(tǒng)結(jié)構(gòu)設計 系統(tǒng) 結(jié)構(gòu)設計通常由系統(tǒng)設計師或項目經(jīng)理負責完成，設計完成后整合到《系統(tǒng)概要設計說明書》的系統(tǒng)結(jié)構(gòu)設計部分。 界面原型的設計一般包括以下三個過程： 繪制界面示意圖 項目經(jīng)理或系統(tǒng)設計師首先根據(jù)《 項目 需求規(guī)格說明書》，分析產(chǎn)品需要呈現(xiàn)的用戶界面的需求和用戶的相關(guān)特點，例如：用戶的使用習慣、用戶對界面的喜好偏向、用戶的強制要求、行業(yè) 20 常規(guī)展現(xiàn)方式、用戶提供界面范例等。 制作界面原型 項目經(jīng)理或系統(tǒng)設計師將設計完成的界面原型提交給界面設計人員，并說明界面設計風格要求等，由界面設計人員著手界面設計。 數(shù)據(jù)庫設計 項目經(jīng)理或 系統(tǒng)設計師 根據(jù)系統(tǒng)結(jié)構(gòu)設計思想，對必須的支持數(shù)據(jù)庫 進行設計 ，設計必須確定 數(shù)據(jù)庫 的 環(huán)境說明 、 數(shù)據(jù)庫 的 命名規(guī)則 、 安全性設計 方法、主要的表結(jié)構(gòu)等。 輸出 《系統(tǒng)概要設計說明書》 終稿 退出準則 當 承包商 完成《系統(tǒng)概要設 計說明書》 后 ， 提交 QA，由 QA 召集評審委員會組織召開《系統(tǒng)概要設計 說明書 》評審會 開展系統(tǒng) 概 要 設計 評審。 系統(tǒng)詳細設計 進入準則 概要設計通過評審，足夠支持詳細設計。根據(jù)提取的模塊需求，進行模塊詳細設計。 21 輸出 《系統(tǒng)詳細設計說明書》多個、《系統(tǒng)接口設計說明書》多個。 各部分《詳細設計 說明書 》及 《系統(tǒng)接口設計說明書》 評審全部通過即可退出本階段。 輸入 各部分《詳細設計 說明書 》及 《系統(tǒng)接口設計說明書》。編碼過程中還需提供指導配置管理工程進行代碼編譯的《編譯環(huán)境說明》，以便配置管理工程師對每周五提交的代碼進行編譯檢查。 在該階段還需同步完成的文檔有 《系統(tǒng)部署實施方案》及《產(chǎn)品安裝使用手冊 》 。 退出準則 根據(jù)約定的評審周期及頻率定期組織代碼評審，評審標準遵循合同規(guī)定的相關(guān)技術(shù)規(guī)范說明。 產(chǎn)品測試 驗收 嚴格遵循 《外包項目測試驗收方案》。 輸入 《項目開發(fā)工作總結(jié)》、《系統(tǒng)驗收工作總結(jié)》、《項目管理工作總結(jié)》 輸出《結(jié)項評估報告》、《項目開發(fā)工作總結(jié)》、《系統(tǒng)驗收工作總結(jié)》、《項目管理工作總結(jié)》 過程 驗收評審。 23 附錄 B 相關(guān)參考模板 1．《產(chǎn)品需求說明書 》 詳見附件《產(chǎn)品需求說明書》 .doc 文檔模板。 24 審批意見 3．《項目狀態(tài)跟蹤報告 》 模板 項目進度狀態(tài)跟蹤報告 項目基本情況 項目名稱 報告給 項目經(jīng)理 報告周期 項目成員 報告人 項目階段 報告日期 項目周期 項目進展情況 類別 狀況 備 注 項目進度狀況 進度狀況 : 1：嚴重滯后 2：輕微滯后 3：保持進度 4：稍微超前 5：大幅超前 項目健康狀況 健康狀況 :1：擔憂 2：正常 3：良好 人員任務完成情況 序號 姓名 職責描述 計劃投入 (%) 實際投入 (%) 完成度 (%) 產(chǎn)出 備注 1 2 3 項目任務完成情況 序號 計劃任務 (Y/N) 任務描述 責任人 進度 完成度（ %） 產(chǎn)出 備注 1 2 3 跟蹤問題點 序號 問題優(yōu)先級 (H/M/L) 問題描述 責任人 解決情況 解決措施 需要支持(Y/N) 1 2 3 風險管理 序號 風險描述 影響 發(fā)生率 (%) 處理措施 優(yōu)先級 責任人 當前狀態(tài) 1 2 3 25 其他備注 序號 備注 1 2 3 4．《系統(tǒng)概要設計說明書 》 詳見附件《系統(tǒng)概要設計說明書》 .doc 文檔模板。 6．《系統(tǒng)接口設計說明書 》 詳見附件《系統(tǒng)接口設計說明書》 .doc 文檔模板。 申請人簽字 變更審批 審批結(jié)論 [ √ ] 同意變更 [ ] 拒絕變更 指示： 審批人簽字 執(zhí)行變更 執(zhí)行說明 說明變更內(nèi)容以及相關(guān)技術(shù)。 26 9．《系統(tǒng)部署說明書 》 詳見附件《系統(tǒng)部署說明書》 .doc 文檔模板。 11．《項目周報 》 模板 項目周報 項目基本信息 項目組 項目經(jīng)理 項目階段 項目成員 項目進度 10% 項目狀態(tài) 正常 報告日期 本周工作內(nèi)容 （本周主要工作記錄） 任務 名稱 計劃任務（ Y/N） 實施人 開始時間 結(jié)束時間 任務進度說明 (正常 :說明進度 (%)。拖延 :說明原因 ） 完成情況 正常 /已完成 /拖延） 本周遺留問題及對策 （遇到的問題和對策） 問題項 問題描述 目前狀態(tài) 是否風險 解決 /預防措施 責任人 下周工作計劃 （下周主要工作計劃） 任務名稱 實施人 開始時間 結(jié)束時間 完成量 說明 12．《 工作周報 》 模板 工作周報 基本信息 部門 報告人 報告日期 項目組 項目經(jīng)理 項目階段 本周工作內(nèi)容 （本周主要工作記錄） 任務名稱 計劃任務 實施人 開始時間 結(jié)束時間 任務進度說明 (正常 :說明進 完成情況 27 （ Y/N） 度 (%)。拖延 :說明原因 ） 正常 /已完成 /拖延） 本周遺留問題 （遇到的問題和對策） 問題項 問題描述 目前狀態(tài) 是否風險 解決 /預防措施 責任人 下周工作計劃 （下周主要工作計劃） 任務名稱 實施人 開始時間 結(jié)束時間 完成量 說明 13．《測試用例》模板 系統(tǒng)測試用例 用例名稱 用例編號 用例類型 編寫人 用例描述 測試目的 測試說明 測試環(huán)境 測試數(shù)據(jù) 測試步驟 步驟 操作描述 輸入數(shù)據(jù) 預期結(jié)果 1 2 3 約束條 件 審核意見 審核人 審核日期 14． 《 測試 BUG 列表 》 模板 XXX項目 BUG列表 項目名稱 軟件版本 項目經(jīng)理 創(chuàng)建日期 開發(fā)人員 回歸次數(shù) 項目階段 BUG總數(shù) BUG編號 BUG 類型 用例編號 BUG描述 嚴重 程度 BUG狀態(tài) 測試步驟 缺陷原因 解決 方法 責任人 解決 日期 28