信息化校園項目實施計劃

第一節(jié)實施開發(fā)計劃 1一、總體思路 1二、實施開發(fā)計劃 2第二節(jié)質(zhì)量計劃 5第三節(jié)異常計劃 7一、風險管理 7二、風險管理樣本表 8第四節(jié)系統(tǒng)風險分析 9一、需求階段 10二、設(shè)計階段 11三、編碼階段 12四、測試階段 13五、實施階段 14六、全過程 15第五節(jié)項目控制 16一、管理控制 16二、交付控制 17三、缺陷管理 18四、質(zhì)量保證管理(QA) 22五、文檔管理 31第六節(jié)系統(tǒng)測試 37一、測試任務(wù)與步驟 37二、影響驗收的其他因素 44三、工程系統(tǒng)集成測試 46第七節(jié)系統(tǒng)驗收 50一、遞交成果的簽署 50二、遞交成果的拒絕 52三、軟件系統(tǒng)的驗收 52第八節(jié)實施過程協(xié)調(diào)方案 54一、協(xié)調(diào)人員工作的重要性 54二、工程實施過程中的協(xié)調(diào)管理措施 55第一節(jié)實施開發(fā)計劃一、總體思路實施計劃將根據(jù)應(yīng)用系統(tǒng)建設(shè)的情況，科學的安排人力、物力和資金的投入，在用戶要求的時間段內(nèi)，通過可伸縮的人員配置計劃，有步驟分階段的實現(xiàn)應(yīng)用，同時考慮對用戶投資的保護。我們建議項目規(guī)劃為三個階段進行：第一階段：建設(shè)基礎(chǔ)軟件支撐平臺建設(shè)學生綜合管理與服務(wù)（除本科教務(wù)、研究生綜合管理和成人教育管理）教職工綜合管理與服務(wù)綜合業(yè)務(wù)綜合管理與服務(wù)（除數(shù)據(jù)倉庫及統(tǒng)計決策系統(tǒng)）第二階段：本科教務(wù)系統(tǒng)和研究生綜合管理系統(tǒng)資產(chǎn)綜合管理與服務(wù)第三階段：建設(shè)數(shù)據(jù)倉庫及統(tǒng)計決策系統(tǒng)成人教育管理系統(tǒng)二、實施開發(fā)計劃實施開發(fā)計劃主要是描述整個項目過程中的不同階段的任務(wù)進度計劃，以及要達到的目標。里程碑標志是各個任務(wù)所對應(yīng)的階段性成果，同時也是下一階段開始的檢查點。技術(shù)實施計劃主要關(guān)注項目交付物及確保這些交付物能及時提交的項目任務(wù)。技術(shù)計劃在一個項目開始的時候建立，它描述了項目的主要任務(wù)。它是項目資源計劃預(yù)測項目總的時間、成本，及衡量項目的總體進度的基本材料。實施開發(fā)計劃的執(zhí)行由項目經(jīng)理控制，并根據(jù)項目情況制定不同的階段性計劃，資源計劃和質(zhì)量計劃，通過對里程碑的檢查點的監(jiān)控，來控制整個項目的實施，以確保整個項目在質(zhì)量控制和進度控制規(guī)定的范圍內(nèi)。根據(jù)學校對本期項目工期的時間要求，我們在編排項目實施計劃時，充分考慮了項目的特殊性及項目中基礎(chǔ)平臺和業(yè)務(wù)系統(tǒng)的實際實施情況，根據(jù)我公司的實施經(jīng)驗，在時間的控制上進行了合理的安排，以確保項目能夠在學校規(guī)定的時間內(nèi)順利完成。第一階段進度安排基礎(chǔ)軟件支撐平臺（2010年4月至2010年12月）主要活動和安排時間跨度（月）主要工作需求調(diào)研1.5需求調(diào)研、頁面原型制作、集成標準系統(tǒng)設(shè)計1概要設(shè)計、詳細設(shè)計編碼、測試1.5編碼、單元測試壓力測試和集成測試、集成平臺搭建實施2.5現(xiàn)場功能測試、系統(tǒng)交付、兩次迭代、系統(tǒng)培訓(xùn)等試運行2系統(tǒng)試運行、試運行記錄驗收0.5系統(tǒng)驗收學生綜合管理與服務(wù)（除本科教務(wù)、研究生和成人）（2010年4月至2011年7月）主要活動和安排時間跨度（月）主要工作需求調(diào)研3需求調(diào)研、頁面原型制作、集成標準系統(tǒng)設(shè)計4概要設(shè)計、詳細設(shè)計編碼、測試3.5編碼、單元測試壓力測試和集成測試、集成平臺搭建實施3現(xiàn)場功能測試、系統(tǒng)交付、兩次迭代、系統(tǒng)培訓(xùn)等試運行2系統(tǒng)試運行、試運行記錄驗收0.5系統(tǒng)驗收教職工綜合管理與服務(wù)（2010年4月至2010年12月）主要活動和安排時間跨度（月）主要工作需求調(diào)研2需求調(diào)研、頁面原型制作、集成標準系統(tǒng)設(shè)計1.5概要設(shè)計、詳細設(shè)計編碼、測試1.5編碼、單元測試壓力測試和集成測試、集成平臺搭建實施2.5現(xiàn)場功能測試、系統(tǒng)交付、兩次迭代、系統(tǒng)培訓(xùn)等試運行1系統(tǒng)試運行、試運行記錄驗收0.5系統(tǒng)驗收綜合業(yè)務(wù)綜合管理與服務(wù)（除數(shù)據(jù)倉庫及決策系統(tǒng)）（2010年4月至2010年10月）主要活動和安排時間跨度（月）主要工作需求調(diào)研1需求調(diào)研、頁面原型制作、集成標準系統(tǒng)設(shè)計1.5概要設(shè)計、詳細設(shè)計編碼、測試1編碼、單元測試壓力測試和集成測試、集成平臺搭建實施2現(xiàn)場功能測試、系統(tǒng)交付、兩次迭代、系統(tǒng)培訓(xùn)等試運行1系統(tǒng)試運行、試運行記錄驗收0.5系統(tǒng)驗收第二階段進度安排本科教務(wù)系統(tǒng)（2011年3月至2012年3月）主要活動和安排時間跨度（月）主要工作需求調(diào)研2需求調(diào)研、頁面原型制作、集成標準系統(tǒng)設(shè)計2.5概要設(shè)計、詳細設(shè)計編碼、測試2編碼、單元測試壓力測試和集成測試、集成平臺搭建實施3現(xiàn)場功能測試、系統(tǒng)交付、兩次迭代、系統(tǒng)培訓(xùn)等試運行2系統(tǒng)試運行、試運行記錄驗收0.5系統(tǒng)驗收研究生綜合管理系統(tǒng)（2011年3月至2012年3月）主要活動和安排時間跨度（月）主要工作需求調(diào)研2需求調(diào)研、頁面原型制作、集成標準系統(tǒng)設(shè)計2.5概要設(shè)計、詳細設(shè)計編碼、測試2編碼、單元測試壓力測試和集成測試、集成平臺搭建實施3現(xiàn)場功能測試、系統(tǒng)交付、兩次迭代、系統(tǒng)培訓(xùn)等試運行2系統(tǒng)試運行、試運行記錄驗收0.5系統(tǒng)驗收lll資產(chǎn)綜合管理與服務(wù)（2011年3月至2011年12月）主要活動和安排時間跨度（月）主要工作需求調(diào)研2需求調(diào)研、頁面原型制作、集成標準系統(tǒng)設(shè)計2概要設(shè)計、詳細設(shè)計編碼、測試1.5編碼、單元測試壓力測試和集成測試、集成平臺搭建實施2.5現(xiàn)場功能測試、系統(tǒng)交付、兩次迭代、系統(tǒng)培訓(xùn)等試運行1.5系統(tǒng)試運行、試運行記錄驗收0.5系統(tǒng)驗收第三階段進度計劃數(shù)據(jù)倉庫及統(tǒng)計決策系統(tǒng)（2011年11月至2012年3月）主要活動和安排時間跨度（月）主要工作需求調(diào)研0.5需求調(diào)研、頁面原型制作、集成標準系統(tǒng)設(shè)計1概要設(shè)計、詳細設(shè)計編碼、測試1編碼、單元測試壓力測試和集成測試、集成平臺搭建實施1現(xiàn)場功能測試、系統(tǒng)交付、兩次迭代、系統(tǒng)培訓(xùn)等試運行1系統(tǒng)試運行、試運行記錄驗收0.5系統(tǒng)驗收成人教育管理系統(tǒng)（2011年11月至2012年3月）主要活動和安排時間跨度（月）主要工作需求調(diào)研0.5需求調(diào)研、頁面原型制作、集成標準系統(tǒng)設(shè)計1概要設(shè)計、詳細設(shè)計編碼、測試1編碼、單元測試壓力測試和集成測試、集成平臺搭建實施1現(xiàn)場功能測試、系統(tǒng)交付、兩次迭代、系統(tǒng)培訓(xùn)等試運行1系統(tǒng)試運行、試運行記錄驗收0.5系統(tǒng)驗收注：以上只是初步計劃，具體實施計劃時間表在中標后與學校商定。第二節(jié)質(zhì)量計劃在計劃階段需要采取步驟確保項目是完全按用戶要求提供的交付物。每一個交付物的質(zhì)量標準將被明確定義，用來制訂質(zhì)量保障計劃。在質(zhì)量計劃中必須考慮抽查和定稿的流程，抽查的活動必須依據(jù)技術(shù)方案嚴格定義并記錄成文檔。因而進行的質(zhì)量計劃活動必須同技術(shù)計劃集成在一起。在質(zhì)量計劃過程中，質(zhì)量保證經(jīng)理必須以獨立的身份參與項目活動，以確保產(chǎn)品的質(zhì)量。以下為質(zhì)量管理過程中的主要行為，它是具體的質(zhì)量計劃制定和執(zhí)行的依據(jù)，在項目實施過程中根據(jù)項目情況制定詳細的計劃。質(zhì)量計劃主要的行為包括：項目提交物的定義和進度安排合約條款的回顧審查提交項和檢查點的回顧審查系統(tǒng)測試錯誤管理和跟蹤在執(zhí)行質(zhì)量計劃的主要任務(wù)過程中，我們有以下各項內(nèi)容。文檔規(guī)范：程序和編程規(guī)范設(shè)計規(guī)范技術(shù)回顧審查程序：文檔的回顧審查過程編碼和檢查點的回顧審查系統(tǒng)規(guī)格說明書的回顧審查系統(tǒng)設(shè)計和詳細設(shè)計的回顧審查源代碼的回顧審查測試程序：測試過程編制測試計劃設(shè)計測試案例執(zhí)行測試記錄測試結(jié)果檢查測試完成情況系統(tǒng)集成測試用戶接受測試第三節(jié)異常計劃在成本和時間進度已經(jīng)偏離原來的計劃，或偏離的程度已經(jīng)超出了項目委員會所建立的容忍程度，必須執(zhí)行異常計劃。作為風險管理中的重要一項，在具體的項目實施過程中必須詳細描述異常偏離計劃的原因、偏離的結(jié)果、建議改正的措施。本節(jié)的異常計劃是從風險管理角度來說明異常出現(xiàn)的處理方法和依據(jù)。一、風險管理建立風險管理“前10位風險表”，它是在給定的時間內(nèi)項目可能所面對的最高風險列表。風險列表將有助于項目負責人隨時注意風險管理?！丁扒?0位”風險模版表》優(yōu)先級(當前的)優(yōu)先級(前一周)風險描述風險所有人風險管理計劃123..10在項目初期，項目負責人會準備一份初步風險列表，在項目過程中不斷更新并保留至項目結(jié)束。在項目發(fā)展過程中，更多的細節(jié)風險將會被界定并增加到風險列表中。列表是不是一定要有10項并不重要。列表內(nèi)可有5項甚至是15項風險。最重要的是必須定期地保持列表更新。項目負責人將每月回顧“前10位風險表”。他們會更新風險表，重新排列風險優(yōu)先次序，并更新風險管理計劃。這將有利于強迫他們定期地考慮到風險，并注意風險重要性的轉(zhuǎn)變。有了項目范圍內(nèi)可見度的支持，風險列表可應(yīng)用在全體項目人員上。下列是一份風險管理樣本表，是我們風險管理中重要的一項內(nèi)容。二、風險管理樣本表《風險管理樣本表》風險表述:需求清晰性第二階段的需求沒有清楚列明優(yōu)先級:2風險所有人:XXX發(fā)生的可能性:高影響范圍:時間表，費用，質(zhì)量影響級別（如果沒有風險管理）高風險管理將會分為兩個級別:減低風險我們會在轉(zhuǎn)變控制下把所有需求列在標書的范圍外。如果有由這些轉(zhuǎn)變因素引起的費用發(fā)生，額外的預(yù)算將被提出在設(shè)計與開發(fā)階段開始前，我們將確認需求，這些需求都必須經(jīng)XXX界定及認定的。我們會開發(fā)一個靈活及可升級系統(tǒng)設(shè)計來減少需求更改的影響在每個設(shè)計階段的開始，我們將用原型來確保系統(tǒng)設(shè)計完全符合使用者的確切要求。我們會確保是根據(jù)當前版本的優(yōu)先級需求詳細的設(shè)計和編碼破壞控制和容錯計劃在項目交付前，在按計劃交付所有性能的前提下，要求項目負責人尋求客戶的允許，首先交付高優(yōu)先級的需求；并將低優(yōu)先權(quán)需求的交付延遲至下一開發(fā)階段任何延遲的合理需求更改所需的額外的時間和資源的重要性和利用必須完全合理；否則，我們將拒絕需求更改或安排到下一版本影響級別(有風險管理):中第四節(jié)系統(tǒng)風險分析依據(jù)項目管理的相關(guān)規(guī)定，結(jié)合我們在以往項目的成功和失敗的經(jīng)驗，我們進行了細致的分析，提出了大學的風險管理與質(zhì)量保證計劃。我們詳細分析了整個開發(fā)過程，針對大學項目的要求，在半年的時間里實現(xiàn)校園網(wǎng)基礎(chǔ)平臺及業(yè)務(wù)系統(tǒng)的運行，在這個過程中會產(chǎn)生什么樣的風險，并且闡述了我們是如何規(guī)避和應(yīng)對這些風險的。同時介紹了我們以往的一些高校項目在執(zhí)行過程中遇到的風險和問題，以及遇到問題后我們的應(yīng)對措施。一、需求階段（一）學校用戶難以界定產(chǎn)品功能范圍，希望要一個在任何平臺、任何情況下都適用的產(chǎn)品?！巴昝馈笔遣淮嬖诘?，導(dǎo)致雙方不斷確定、更改相應(yīng)文檔。應(yīng)對措施：1.對用戶進行軟件需求的培訓(xùn)；2.項目初期明確方向，界定范圍；3.使用原型開發(fā)；4.給用戶演示已結(jié)束的類似項目，獲取用戶需求。（二）隨著用戶對項目產(chǎn)品的不斷了解（通過各種渠道），不斷提出新的或者更加有難度的需求，造成頻繁變更。應(yīng)對措施：1.需求分析結(jié)果客戶簽字確認，如要更改已確認的需求，需雙方進行聯(lián)合評審，評估變更風險后方可實施；2.設(shè)計采用松耦合設(shè)計，降低非預(yù)期變更帶來的影響范圍；3.對于新需求，由雙方溝通，采用非技術(shù)手段解決，或者留在以后版本處理；（三）開發(fā)中途變更產(chǎn)品的硬件環(huán)境要求，導(dǎo)致軟、硬件接口出現(xiàn)問題。應(yīng)對措施：1.對于硬件環(huán)境的變更必須及時評估對于設(shè)計的影響；2.設(shè)計方案應(yīng)有較大彈性，以適應(yīng)硬件環(huán)境的變化。二、設(shè)計階段（一）階段交付/迭代開發(fā)模型帶來的風險迭代法雖然能減少軟件系統(tǒng)的后期維護費用，降低因需求不明確帶來的項目風險，但是初期交付原型本身功能設(shè)置不齊全、性能不好，會導(dǎo)致原型的設(shè)計和使用超出預(yù)期的花費和時間，并且使客戶產(chǎn)生項目是否能夠?qū)崿F(xiàn)的疑慮。應(yīng)對措施：1.設(shè)立階段目標；2.給客戶進行設(shè)計及實現(xiàn)過程講解，使客戶要求的階段交付目標盡量與階段實現(xiàn)的目標相一致。（二）在系統(tǒng)設(shè)計時為考慮軟件平臺的應(yīng)用范圍，不斷修改設(shè)計，進行討論，反復(fù)評審，始終拿捏不定，導(dǎo)致設(shè)計時間過長。應(yīng)對措施：1.尋求有經(jīng)驗、有判斷權(quán)的領(lǐng)導(dǎo)作為項目組的核心力量，短時間內(nèi)判斷適用技術(shù)，確定模塊性能；2.項目前期與用戶充分交流，多調(diào)研需求，后快速開發(fā)，之后再進行升級；（三）不像桌面程序的開發(fā)，發(fā)展時間長，已逐漸形成了一套規(guī)范，而WEB應(yīng)用剛剛發(fā)展不長時間，很多東西仍延用桌面程序的要求，但桌面程序與WEB程序的不同導(dǎo)致這些規(guī)范不可能完全適用，甚至大部分的都不適用。而且WEB的表現(xiàn)形式?jīng)Q定了界面布局有著自己的特點，依賴程序員之間自發(fā)的保持界面一致很難達到希望的效果。應(yīng)對措施：提供學校一套WEB界面設(shè)計規(guī)范；（四）項目規(guī)模估計不足，不能在預(yù)定時間交付系統(tǒng)。應(yīng)對措施：1.細化需求分析，做好任務(wù)分解；2.掌握先進估計方法，使用估計工具；3.聘請專家進行估計或參與策劃評審；4.設(shè)定彈性任務(wù)；（五）開發(fā)任務(wù)未細化，任務(wù)遺漏，導(dǎo)致最終需求沒有完成。應(yīng)對措施：使用任務(wù)分解和需求跟蹤矩陣技術(shù)（公司內(nèi)的開發(fā)跟蹤工具）；（六）根據(jù)以往經(jīng)驗，對于系統(tǒng)性能的要求，各高校均有所差異，這種差異會給軟件設(shè)計帶來較大的影響。應(yīng)對措施：1.向客戶展示過去完成的較為成功的設(shè)計及實現(xiàn)的功能模塊，說明已完成項目功能齊備、性能優(yōu)異；2.通過平臺及數(shù)據(jù)庫的優(yōu)化（我們是IBM及ORACLE的合作伙伴，廠商支持力度大）。三、編碼階段（一）由于修改代碼時會涉及他人編寫的代碼，而且由于代碼封裝的不好，容易在某人的代碼修改后給他人的代碼代來影響。應(yīng)對措施：1.明確模塊之間的相互依賴關(guān)系，對于依賴性較強的模塊加強詳細設(shè)計：2.明確人員溝通渠道，對于發(fā)現(xiàn)問題確保有合理的問題關(guān)閉機制；（二）團體配合能力差，有些模塊間接口定義不明確而導(dǎo)致開發(fā)返工。應(yīng)對措施：1.詳細定義模塊間接口聯(lián)系；2.加強開發(fā)規(guī)范的管理，在編碼前再次強化開發(fā)規(guī)范管理的培訓(xùn)；四、測試階段（一）測試設(shè)備陳舊落后，導(dǎo)致測試進展緩慢或者測試中得到的數(shù)據(jù)對用戶意義不大。應(yīng)對措施：確認測試環(huán)境，提前借用或購置設(shè)備；（二）測試用例不完善。測試人員測試不全面，考慮不周，導(dǎo)致程序仍存在很多問題，無法結(jié)束項目。應(yīng)對措施：1.測試人員參加需求評審或由PSM對測試人員進行軟件需求的培訓(xùn)；2.加強測試用例評審；（三）對項目開發(fā)版本控制不力，在后期開發(fā)測試階段出現(xiàn)版本錯誤，測試的版本不是最新的，導(dǎo)致無效工作。應(yīng)對措施：1.編碼結(jié)束后進行配置審計；2.測試過程中由測試人員控制配置庫中的代碼版本更新；五、實施階段（一）對實施人員和客戶培訓(xùn)不到位，實施難度大。應(yīng)對措施：1.項目任務(wù)緊張時也要求形成《技術(shù)報告》和《用戶手冊》作為培訓(xùn)資料；2.可以由實施人員和客戶共同參與系統(tǒng)測試，達到一定培訓(xùn)效果；（二）客戶對開發(fā)人員依賴感過強，遲遲不肯驗收。應(yīng)對措施：1.做好領(lǐng)導(dǎo)層的工作；2.宣傳講解服務(wù)范圍和公司服務(wù)管理的規(guī)范性；3.做好用戶基層人員的培訓(xùn)工作；4.做好實施準備，確保規(guī)范性，確保每步實施完成的工作階段性得到確認；（三）測試不充分，實施中發(fā)現(xiàn)從未遇到的問題，推遲驗收。應(yīng)對措施：測試人員加強對業(yè)務(wù)的了解，測試用例聽取多方意見，包括各層次、水平的操作人員；（四）現(xiàn)場與公司開發(fā)人員有多個版本接口，造成版本混亂，拖延溝通時間。應(yīng)對措施：統(tǒng)一版本控制接口，專人發(fā)放程序；（五）銷售人員定義的合同存在二義性。應(yīng)對措施：簽訂合同時技術(shù)人員參與，明確主要需求，并確定提出新需求不能超過需求的30％，否則另外收費；六、全過程（一）人力資源分配不當，無法充分考慮項目組成員的個人喜好和對開發(fā)語言的熟悉程度，以及個人工作能力和工作任務(wù)的分配，導(dǎo)致人員的抵觸情緒。應(yīng)對措施：1.項目負責人充分了解成員具體特點，調(diào)查人員意愿，分配任務(wù)前取得人員的認可；2.對于能力較差的人員負責的模塊細致分析該模塊的邏輯，確定不清晰的問題，增加人員參與該模塊的編碼；（二）項目組重要成員流失或項目進行到一半，有些人員要出差去解決以前項目的問題，導(dǎo)致其負責的模塊暫停。應(yīng)對措施：1.日常保證文檔質(zhì)量和工作日志，使項目本身具備抗風險能力，弱化對人員的依賴性；2.安排相對穩(wěn)定的人員參與項目，與開發(fā)人員加強溝通，幫助解決生活等方面問題，團結(jié)開發(fā)隊伍；3.對于關(guān)鍵技術(shù)要保證至少兩個人參與，可以由兩個人負責兩個模塊的配對開發(fā)，既提高效率，降低接口復(fù)雜度，也避免人員變動的風險。第五節(jié)項目控制項目控制是對整個項目進行過程中的各種情況進行控制的一種手段，通過對項目進度、項目質(zhì)量、項目的提交等控制和管理，以確保項目能夠在不超出預(yù)算的前提下按時保質(zhì)保量完成。本節(jié)主要從管理控制、交付控制、缺陷管理、質(zhì)量管理、文檔管理和變更管理等方面進行描述。一、管理控制管理控制涉及項目活動的所有方面，控制活動以項目指導(dǎo)委員會會議、項目保證小組會議和其他的項目會議方式來進行。會議類型包括：項目啟動會議–提供一個項目的良好開端，以確保如參照、目標、承諾、調(diào)整、計劃和組織等詞匯被清楚的定義、公布、理解并達成一致。進度會議–這是一個常規(guī)會議。在會議中，項目經(jīng)理將匯報項目當前狀況，并提供一個契機，讓項目指導(dǎo)委員會解決那些項目經(jīng)理無法解決的項目問題。會議召開的頻度由雙方?jīng)Q定。最后階段的評估–它在每個實施階段的收尾部分進行。開發(fā)結(jié)案會議–這是項目指導(dǎo)委員會的最后一個會議，用來確認并接受新開發(fā)的系統(tǒng)，并正式宣布相關(guān)的開發(fā)階段結(jié)束。關(guān)鍵點檢查–這是一個定時進行的會議。項目經(jīng)理檢查相關(guān)交付物，確認項目的技術(shù)問題，并按需要采取相應(yīng)的措施。二、交付控制質(zhì)量和技術(shù)控制主要針對特定階段提交的交付物，而不是針對整個階段的產(chǎn)品結(jié)果。目的是為了在開發(fā)階段盡可能早的確認并改正錯誤。它通常采用下面的控制機制：質(zhì)量抽查－每一次質(zhì)量抽查，是指技術(shù)、質(zhì)量保證及用戶的相關(guān)人員對交付物進行檢查，確定它已經(jīng)完成、符合對它的描述、符合質(zhì)量標準和相關(guān)的用戶需求。變更控制–一個變更是指與一個或多個交付物相關(guān)的并且事先未知的需求改變。它需要被記錄并應(yīng)采取適當措施加以控制以防變化擴大化。軟件配置管理–軟件配置管理提供一個正式的機制用來對交付物進行標記和歸檔，跟蹤開發(fā)狀態(tài)及它們之間的關(guān)系。缺陷管理–缺陷是指已被認為正式通過后的交付物發(fā)現(xiàn)技術(shù)上的異常問題。它需要被記錄及改正以保持交付產(chǎn)品的完整性。風險管理–這個控制機制用來識別、評估、監(jiān)控項目風險，使項目風險對項目的破壞程度降到最小。三、缺陷管理缺陷管理是管理在系統(tǒng)驗收測試中發(fā)現(xiàn)的、新系統(tǒng)運行過程中發(fā)現(xiàn)的錯誤的修改工作。發(fā)現(xiàn)的缺陷將被記錄，而且修正過程需要被嚴格監(jiān)控。缺陷是指新運行系統(tǒng)與開發(fā)前確定需求規(guī)格的差異（即接收到的需求與完成的產(chǎn)品之間的差別），包括文檔，用戶界面，功能，以及性能。非偏離需求規(guī)格而引起的變動叫“變動請求”（CR）。CR將被按照變動管理的方法去報告和處理。詳細描述見“變動管理”部分。（一）缺陷跟蹤系統(tǒng)為在系統(tǒng)開發(fā)過程中，能夠即時提交缺陷，管理缺陷，分配、更新缺陷跟蹤記錄，必須建立缺陷跟蹤系統(tǒng)。缺陷的管理包括：1.缺陷發(fā)現(xiàn)2.缺陷提交3.缺陷分級4.缺陷分配5.解決缺陷6.再測試7.發(fā)布和完成（二）缺陷狀態(tài)每個缺陷將被分配一個狀態(tài)。缺陷的處理過程可以通過觀察每個缺陷的狀態(tài)來完成缺陷監(jiān)控?？赡艹霈F(xiàn)的狀態(tài)有：《項目缺陷狀態(tài)表》狀態(tài)說明活動的缺陷已經(jīng)輸入，還沒有實施解決措施已解決缺陷已經(jīng)分配，問題正在解決，等待再測試。已完成缺陷已經(jīng)測試過了，沒有碰到更多問題重復(fù)屬于重復(fù)性的缺陷優(yōu)先缺陷比其它系統(tǒng)缺陷要優(yōu)先處理（三）缺陷發(fā)現(xiàn)大部分缺陷是在測試階段發(fā)現(xiàn)的，如先前所講，缺陷是文檔中描述的需求與完成產(chǎn)品之間的差異。而系統(tǒng)改進方面的請求應(yīng)按照“變動管理”方法處理。（四）缺陷提交每個項目組成員都可以提交缺陷，通常，大部分缺陷都是在系統(tǒng)測試階段發(fā)現(xiàn)的。在這種情況下，缺陷要報告給項目經(jīng)理，并且登記到缺陷管理系統(tǒng)。所有的缺陷將進入缺陷管理系統(tǒng)，它們應(yīng)該包含以下信息：1.缺陷所在系統(tǒng)模塊2.缺陷的詳細描述3.如果是功能缺陷，說明是否缺陷會再產(chǎn)生，以及再產(chǎn)生的步驟。4.嚴重度根據(jù)發(fā)現(xiàn)問題的性質(zhì)，缺陷的重要程度可以分為：《缺陷重要程度表》PRIVATE嚴重度適用于S1防礙系統(tǒng)能力的發(fā)揮S2防礙運行和重要任務(wù)的完成，但是其他功能仍然可以用S3影響運行和重要任務(wù)完成，而且沒有解決措施S4影響運行和重要任務(wù)完成，已經(jīng)發(fā)現(xiàn)解決辦法S5使操作員使用不方便和煩惱，但是不影響運行和關(guān)鍵任務(wù)處理使操作員使用不方便和煩惱，但不妨礙任務(wù)的完成S6其他影響缺陷一旦被接收，分配一個唯一編碼，其狀態(tài)為“活動”（五）缺陷優(yōu)先級缺陷管理長官要每天監(jiān)控缺陷提交。根據(jù)缺陷的嚴重度和性質(zhì)對缺陷分配一個優(yōu)先級：高-缺陷必須盡快改正 中-應(yīng)該盡快修正。但是，可以在所有高優(yōu)先級別的缺陷修正之后做。低-缺陷可以以后再改，不會影響系統(tǒng)運行。（六）缺陷分配缺陷將按以下順序分配給開發(fā)者去改正：高，中，低。在軟件開發(fā)和內(nèi)部測試階段，分配和解決缺陷可能不必獲得項目經(jīng)理的批準。軟件開發(fā)者可以分配和解決所有必要的缺陷。然而，一旦一個版本已經(jīng)選為基本版本，項目經(jīng)理要進行影響分析，確定是否要解決該缺陷。在版本選擇階段，任何缺陷的修改必須獲得配置管理員和項目經(jīng)理的批準。（七）解決缺陷當開發(fā)者收到缺陷時，要分析缺陷的成因，并分析原因和提出解決方案。其直接領(lǐng)導(dǎo)要立刻批準對應(yīng)的分析和解決方法。批準之后，項目經(jīng)理要分配時間去解決問題。為修改程序，需要從版本控制系統(tǒng)中借出源文件。對缺陷要做單元測試，以免影響系統(tǒng)其他部分。當缺陷改正后，有關(guān)文件要還回版本控制系統(tǒng)。在還回時，記錄缺陷的編號和簡要描述。在缺陷管理系統(tǒng)里面，要更新缺陷的信息，加入缺陷分析和解決措施，以及修改過的文件。缺陷的狀態(tài)應(yīng)標為“正在解決中”，并分配給測試組進行重新測試。所有會影響文檔的修補，如用戶文檔，要通知項目經(jīng)理，以便采取響應(yīng)行動。（八）測試，布置和結(jié)束缺陷處于“正在解決中”狀態(tài)，而且被發(fā)回測試組時，將進行再測試。測試組根據(jù)標準測試方法測試。如果再測試成功，將修改部分布置到生產(chǎn)系統(tǒng)中，要求用戶再進行測試。如果沒有問題，缺陷的狀態(tài)就可以標志為“已完成”。如果缺陷仍然存在，或碰到新問題，缺陷要被發(fā)回負責處理的人。返回的缺陷要包含返回的原因和碰到的問題。返回的缺陷要被再評估，這個過程要不斷重復(fù)直到缺陷解決為止。（九）缺陷跟蹤和監(jiān)控為確保一系列行動被執(zhí)行，并且在要求時間內(nèi)完成，缺陷應(yīng)該由項目經(jīng)理親自進行跟蹤和監(jiān)控。四、質(zhì)量保證管理(QA)質(zhì)量保證是一個有計劃和系統(tǒng)化的質(zhì)量管理過程，提供項目或產(chǎn)品遵守技術(shù)的需求的足夠的信心。我們將依據(jù)質(zhì)量法則來建立一套軟件質(zhì)量保證計劃，來確保項目的標準和流程具有足夠的質(zhì)量水平，并將它貫穿在項目的始終。（一）質(zhì)量法則質(zhì)量不僅僅是指軟件產(chǎn)品的測試，它在軟件的生產(chǎn)過程之中被不斷建立。我們的質(zhì)量保證的方法基于下列的質(zhì)量法則：預(yù)防錯誤的產(chǎn)生確保錯誤盡可能早的被發(fā)現(xiàn)增加方式的設(shè)計、開發(fā)和測試，以減少無謂的錯誤根據(jù)需求，獨立的開展測試工作1.預(yù)防我們通過下列方式避免在開發(fā)過程中產(chǎn)生錯誤：采用適當?shù)能浖こ痰臉藴屎土鞒酞毩⒌臏y試，確保滿足項目的功能性和技術(shù)性的需求清晰地界定人員的角色、責任和交流的渠道高質(zhì)量的輸入，包括軟件工具受過相應(yīng)培訓(xùn)和有經(jīng)驗的人員2.獨立的檢查和確認（質(zhì)量控制）采用預(yù)先防范的策略可以大大減少錯誤的數(shù)量，但是錯誤并不能完全消除。因而，我們將采用第二種防范手段，盡可能早的把開發(fā)過程中產(chǎn)生的錯誤檢查出來并加以糾正。錯誤發(fā)現(xiàn)的越晚，糾正錯誤的代價就越高。我們將采用質(zhì)量控制，例如技術(shù)審查（正式和非正式），在軟件開發(fā)周期的各個階段，在產(chǎn)品開發(fā)的各個關(guān)鍵點，需求、設(shè)計、文檔和編碼，而不僅僅把質(zhì)量控制留在測試階段。在這個階段，糾正主要的錯誤已經(jīng)太遲了，糾正的成本也太高了。3.技術(shù)審查我們將在所有主要的文檔和軟件模塊提交之前，進行技術(shù)審查。審查的目的是為了評估一個特定的元素是否遵守下列規(guī)定：遵守規(guī)范符合相應(yīng)的項目標準和流程以納入變動控制的管理，因而所有的變動都能被正確的實現(xiàn)，并僅僅影響在變動描述所確定的地方技術(shù)審查包括在質(zhì)量保證計劃中，包括檢查點的審查，同事間相互審查，預(yù)演和代碼級的檢查。4.測試測試是指通過手工或自動的方式，對系統(tǒng)或系統(tǒng)中的組件執(zhí)行檢查或評估，它包括：確認滿足指定的需求確認期望的和實際的結(jié)果之間的差異我們在系統(tǒng)驗收測試之前，要對所有的軟件進行系統(tǒng)集成測試。通過一個獨立的測試團隊來進行內(nèi)部測試，從保證公平的角度來說是很有必要的。質(zhì)量保證的職責每個項目組的成員在開發(fā)和測試中都要遵循一個既定的流程。我們分配一個以獨立身份出現(xiàn)的質(zhì)量保證者（以下簡稱QAM）來定義這樣一個流程。一個標準的流程是由書面的標準和流程組成并被定義在軟件開發(fā)的環(huán)境中。質(zhì)量不僅僅體現(xiàn)在項目產(chǎn)生的產(chǎn)品上，每一個參與項目的員工都要為他們自己的工作質(zhì)量負責，項目經(jīng)理為整個項目的質(zhì)量負責。質(zhì)量保證的行為我們分配一個獨立的QAM來定義所有必需的軟件質(zhì)量保證的行為，包括在質(zhì)量保證計劃中。總的來說，這個QA的方案包括下列的行為：管理對管理的結(jié)構(gòu)進行分析本身就是一種QA的行為，會影響到軟件本身的質(zhì)量。我們將為項目建立一個相應(yīng)的管理結(jié)構(gòu)，結(jié)構(gòu)中的每個角色都有清晰定義的任務(wù)和職責。文檔QAM分析項目中的文檔計劃，確定與同類計劃的相關(guān)標準的差異，并從項目管理的角度討論這些差異。標準和實踐QAM將監(jiān)控所有的標準（如編程標準）和流程（如質(zhì)量審查）并貫穿項目的始終。審查和稽核QAM將檢查對項目審查和稽核工作的安排，確保它們對項目來說是充分的和必要的。測試運行軟件并對軟件進行測試，是軟件開發(fā)質(zhì)量控制的重要一部分。QAM將檢查QA的這些行為相關(guān)的計劃或報告，如測試計劃，測試方案，測試數(shù)據(jù)和測試報告，為測試做好充分的準備。編碼、文檔和媒介控制QAM將檢查所有的軟件工程中使用到的流程、方法的正確行，以及文檔和其他媒介（如CD）是否在管理、存儲、安全和版本控制方面被正確使用。五、變更管理（一）配置管理和版本控制企業(yè)公司采用相應(yīng)的配置控制程序來管理新系統(tǒng)的各個部分，包括文檔，需求，設(shè)計，數(shù)據(jù)庫設(shè)計，編碼，文件和數(shù)據(jù)。并在項目實際實施的時候制定配置管理計劃，并委任一名配置管理員。配置控制的目的是控制系統(tǒng)的物理和功能特性，確保整個系統(tǒng)的完整性。配置控制即是技術(shù)活動又是管理活動，它的過程包括：發(fā)現(xiàn)并定義系統(tǒng)中的配置項目；控制配置項目的版本和變動；記錄和報告配置項目的狀態(tài)；確認配置項目的完成和正確配置項目發(fā)現(xiàn)和保存每個配置項目要有一個編號，用來區(qū)別有不同需求和實施要求的其它項目。它還有一個版本號，用來標明該項目所處的階段，在配置項目修改時，版本號要更新。配置系統(tǒng)要能夠容納新的配置項目，不必修改現(xiàn)存項目。配置項目要保存在軟件庫里面。為確保足夠的安全以及對所有可交付軟件項目的控制必須建立如下典型的軟件庫：名稱狀態(tài)開發(fā)庫動態(tài)的主庫控制的靜態(tài)庫靜態(tài)的開發(fā)庫是軟件作為一系列模塊進行開發(fā)和測試的動態(tài)庫。主庫是一個被控制的庫，項目的放入和取出必須按規(guī)定并以一定的控制方式進行。例如，在單元測試成功之后，模塊可以被轉(zhuǎn)入到系統(tǒng)主庫，然后供系統(tǒng)集成和系統(tǒng)測試。任何經(jīng)過以上測試需要修改模塊都要放回開發(fā)庫，以供測試。當主庫達到了一定程度的穩(wěn)定后，就可以將它合成一個基準。每當基準發(fā)布以后，相關(guān)主庫都要進行拷貝生產(chǎn)靜態(tài)庫。之所以叫做靜態(tài)庫，因為以后不再更新，并且歸檔。配置變動控制只有當項目已經(jīng)成為基準的一部分時，軟件配置控制才能夠進行，它主要控制：評估對配置項目的變動協(xié)調(diào)批準的變動在本項目的執(zhí)行過程中，項目經(jīng)理將與大學一起定義處理配置變動以及變動授權(quán)管理方法。作為對于已經(jīng)通過的單元，系統(tǒng)的驗收測試項目的變動，需要更高級別的授權(quán)。配置狀態(tài)記錄配置狀態(tài)記錄包括所有配置項目跟蹤報告，并且貫穿整個系統(tǒng)開發(fā)周期中，配置項目狀態(tài)將通過配置管理員來跟蹤和控制：為有效進行配置狀態(tài)記錄，應(yīng)該記錄以下信息：每個基準版的日期，版本和問題； 每份文檔審閱以及文檔修改的日期狀態(tài)；每份軟件問題報告、修改請求、和修改報告的日期和狀態(tài)；每個培置項目的總結(jié)描述。軟件版本企業(yè)公司要在版本文檔內(nèi)記錄軟件的版本。后續(xù)版本要附一個版本說明。該說明列出了版本內(nèi)的配置項目，并且說明其安裝步驟。而且，所有已經(jīng)修改的錯誤和已經(jīng)合并的新的需求都要有記錄。企業(yè)公司要在提交新版本之前重新測試修改過的軟件。對于每個版本，本公司保證文檔和代碼的一致性，而且保存舊版本。（二）變動管理的方法產(chǎn)品的完整性需要通過變動管理來維持。用戶需求的變化、系統(tǒng)需求的變化和系統(tǒng)設(shè)計的變化都被監(jiān)控和跟蹤，從而了解被批準變動的實施狀態(tài)?？刂谱儎拥哪康氖菫榱舜_保只有經(jīng)過批準的變動才能實施，確保變動情況傳達到了相應(yīng)的有關(guān)方面，提供它們考慮和獲得它們批準。用戶需求、系統(tǒng)需求和系統(tǒng)設(shè)計文檔在通過評審并批準后將作為基準。當一個文檔變?yōu)榛鶞室院?，就自動進入變動控制范圍。任何變動都需要提交變動請求。變動管理由以下四部分組成：變動請求變動評估變動批準變動實施和跟蹤任何變動都要通過變動請求（CR）提出并提交到項目指導(dǎo)委員會進行批準。CR并不意味現(xiàn)存產(chǎn)品有任何錯誤。提出CR可能的理由有：用戶希望修改系統(tǒng)某一特性發(fā)現(xiàn)了新的需求項目組成員針對系統(tǒng)某一特性提出了一個改良的建議（1）變動請求當有變動需要時，請求者將填表格，表格要包含以下信息：變動所影響的模塊和系統(tǒng)變動的描述變動的理由變動細節(jié)預(yù)計的影響收到CR后，項目經(jīng)理將其編號，召開會議討論。（2）變動評估和批準當項目指導(dǎo)委員會收到CR后，要決定是批準還是否決。任何變動都要在會議之前做好研究。項目服務(wù)控制人員將考慮請求的重要性，并進行影響分析。調(diào)查者要寫影響分析報告，并發(fā)給項目指導(dǎo)委員一份。變動的種類根據(jù)影響分析報告，變動將被分為以下幾類：類別1，變動影響到基準文檔或者引起成本和進度變動。類別2，變動不影響基準文檔，并且對于成本和進度影響可以忽略。如果委員會認為變動屬于類別2，變動自動獲批準，不要進一步行動。如果變動屬于類別1，必須給出如何處理的建議。有兩種可能性：-接受變動并建議變動何時實施拒絕請求影響分級根據(jù)“影響分析報告”，變動的影響可以分為以下級別：《變動影響級別表》狀態(tài)說明高變動的實施非常重要，比如為符合合同的要求中很有必要實施，比如影響到運行效率低沒有大的好處和影響，比如文檔的修改裝飾性改動很小，對系統(tǒng)的作用不可測量，例如修改操作手冊的樣式。根據(jù)CR的優(yōu)先級和其他項目因素（比如，可用時間和資源），委員會可以決定是否建議實施變動。影響分析影響分析是要確定對產(chǎn)品進行變動所需要的資源，時間，成本，以及風險。研究者應(yīng)該準備“影響分析報告”。報告中應(yīng)包含以下項目：提出者和其單位所建議的達到變化的簡要方法技術(shù)優(yōu)點評估潛在副作用評價總結(jié)對其他配置項目和系統(tǒng)功能的總體影響必須考慮的限制預(yù)計對于項目成本和時間的變動評審和監(jiān)督的標準建議可以采取的方法和不能采取的方法（3）變動的批準變動請求應(yīng)該有以下六狀態(tài)：《變動請求表》未處理未有決定否決已決定不變動延后決定不在此項目中修改，留待以后去做同意批準實施進展中正在實施變動完成已經(jīng)完成變動并經(jīng)過審核在會議結(jié)束，CR應(yīng)該處于以下狀態(tài)之一：未處理，否決，延后，或批準。獲得批準并且開始了實施工作，狀態(tài)應(yīng)為：進展中。所有工作完成，CR將處于“完成”狀態(tài)。會議中請求的列表應(yīng)記錄在文檔中，并且標明審批的狀態(tài)，最后要委員會簽署。在項目結(jié)束時，所有的CR應(yīng)處于“否決”，“延后”，“完成”三種狀態(tài)之一。（4）變動實施和跟蹤根據(jù)委員會對變動的建議，有兩種的行動可能發(fā)生。如果委員會建議是否決，將請求的狀態(tài)記錄為“完成”，如果委員會建議接受并批準了書面的對計劃和成本的影響，本公司要實施變動的處理。五、文檔管理（一）主要文檔的描述文檔是指在項目實施過程中以及軟硬件安裝、操作、使用、測試、控制和維護過程中，參與項目的人員用來計劃、設(shè)計、編輯、發(fā)布和維護所產(chǎn)生的紙質(zhì)、電子和程序文件。在整個軟件生存期中，各種半成品或成品文檔被不斷地生成、修改或補充。文檔可被人和計算機閱讀，它起到開發(fā)團隊、用戶之間起到橋梁作用，使項目能夠進行控制、實施和評價，使項目得以順利完成。根據(jù)項目實施過程，將提交下列內(nèi)容：1.總體規(guī)劃階段：項目任務(wù)書、項目開發(fā)實施計劃、開發(fā)人員安排、項目質(zhì)量計劃、質(zhì)量保證計劃、總體工程計劃、階段工作計劃、文檔編寫計劃、項目啟動文檔等2.需求分析階段：業(yè)務(wù)模型說明書、問題陳述書、USECASE模型、USECASE說明書、用戶界面設(shè)計說明書、用戶界面模型、術(shù)語表、系統(tǒng)需求規(guī)范、需求說明書、用戶手冊（系統(tǒng)功能說明）、硬件設(shè)備安裝調(diào)試指南等；3.系統(tǒng)設(shè)計階段：系統(tǒng)設(shè)計報告、系統(tǒng)結(jié)構(gòu)分析說明書、軟件構(gòu)架說明書、子系統(tǒng)設(shè)計說明書、類設(shè)計說明書、數(shù)據(jù)庫設(shè)計說明書、系統(tǒng)數(shù)據(jù)字典、應(yīng)用系統(tǒng)接口規(guī)范、系統(tǒng)測試方案、規(guī)范和預(yù)期結(jié)果、功能設(shè)計文檔、設(shè)計評審報告等；4.系統(tǒng)測試：測試計劃、測試規(guī)范、缺陷分析報告、測試環(huán)境核校驗、代碼審查表、測試方案、測試記錄、測試驗證表、測試報告、測試問題報告——問題部分、測試問題報告——解決部分、測試總結(jié)報告、系統(tǒng)安裝報告、內(nèi)部測試報告、系統(tǒng)操作手冊、培訓(xùn)教材、系統(tǒng)測試結(jié)果、系統(tǒng)維護手冊、系統(tǒng)維護流程、備份流程等；5.用戶測試：系統(tǒng)發(fā)布說明書、上線計劃、上線及運行報告、系統(tǒng)培訓(xùn)教材、用戶使用手冊、系統(tǒng)管理員手冊、系統(tǒng)驗收報告等6.系統(tǒng)試運行：系統(tǒng)維護手冊（軟、硬件）、系統(tǒng)故障診斷書、最終驗收測試報告、應(yīng)用軟件源代碼、相關(guān)圖表、用戶問題報告等7.項目管理：項目計劃、資源計劃、變更控制計劃、風險管理計劃《各文件內(nèi)容說明表》文檔名稱項目啟動文檔(PID)目的記錄推薦的項目組織，項目計劃和項目控制方法。它應(yīng)該包含本項目的有效管理的基本的信息。主要內(nèi)容PID的內(nèi)容包括：簡介、項目定義、業(yè)務(wù)案例、組織、項目計劃、項目控制文檔名稱項目計劃書目的記錄本項目各個階段的活動主要內(nèi)容項目計劃的內(nèi)容包括：計劃的描述、計劃的前提條件、任務(wù)的關(guān)系、風險分析、質(zhì)量方案、技術(shù)方案、資源方案、變更控制文檔名稱系統(tǒng)需求規(guī)范目的提供目標系統(tǒng)的系統(tǒng)設(shè)計，功能定義的詳細內(nèi)容描述目標系統(tǒng)的網(wǎng)絡(luò)物理設(shè)計主要內(nèi)容系統(tǒng)結(jié)構(gòu)、網(wǎng)絡(luò)配置設(shè)計、用戶程序說明、定制說明、數(shù)據(jù)轉(zhuǎn)換說明、接口說明文檔名稱需求分析文檔目的提供系統(tǒng)需求分析的詳細內(nèi)容主要內(nèi)容業(yè)務(wù)模型說明、USECASE模型、USECASE說明、用戶界面設(shè)計說明、用戶界面模型、術(shù)語表、需求說明文檔名稱數(shù)據(jù)庫設(shè)計文檔目的描述數(shù)據(jù)模型和定義主要內(nèi)容數(shù)據(jù)模型、數(shù)據(jù)文件/數(shù)據(jù)庫表定義、數(shù)據(jù)庫設(shè)計說明、系統(tǒng)數(shù)據(jù)字典文檔名稱功能設(shè)計文檔目的提供目標系統(tǒng)的功能定義的詳細內(nèi)容主要內(nèi)容功能描述、用戶接口設(shè)計、數(shù)據(jù)的邏輯校驗、外部接口清單文檔名稱軟件設(shè)計文檔目的提供軟件設(shè)計的詳細內(nèi)容主要內(nèi)容類圖、順序圖、系統(tǒng)設(shè)計報告、系統(tǒng)結(jié)構(gòu)分析說明、軟件構(gòu)架說明、子系統(tǒng)設(shè)計說明、類設(shè)計說明書文檔名稱系統(tǒng)測試計劃文檔目的提供軟件測試相關(guān)的詳細內(nèi)容主要內(nèi)容測試計劃、測試規(guī)范、缺陷分析報告、測試方案、測試記錄、測試驗證表、測試問題報告、測試總結(jié)報告文檔名稱系統(tǒng)測試方案，規(guī)范和預(yù)期的結(jié)果目的定義驗收測試的測試類型、定義測試數(shù)據(jù)的需求建立測試數(shù)據(jù)，使得系統(tǒng)能按計劃和規(guī)范中的要求進行測試主要內(nèi)容系統(tǒng)測試方案、測試方法、捕獲測試數(shù)據(jù)的方法、系統(tǒng)測試工具每種活動定義的職責、系統(tǒng)測試規(guī)范、測試的目的、測試數(shù)據(jù)描述、系統(tǒng)測試結(jié)果文檔名稱用戶測試文檔目的提供用戶測試相關(guān)說明主要內(nèi)容系統(tǒng)發(fā)布說明、上線計劃、上線及運行報告、測試報告文檔名稱系統(tǒng)試運行維護文檔目的提供系統(tǒng)試運行期間產(chǎn)生的報告等信息主要內(nèi)容系統(tǒng)維護手冊（軟、硬件）、系統(tǒng)故障診斷書、最終驗收測試報告、應(yīng)用軟件源代碼、相關(guān)圖表、用戶問題報告文檔名稱操作手冊目的提供計算機操作的相關(guān)指令和信息主要內(nèi)容計算機系統(tǒng)信息、計算機操作流程、系統(tǒng)維護流程、備份流程、系統(tǒng)操作和維護（二）文檔控制文檔控制是指對項目實施過程中所產(chǎn)生的文檔進行的管理控制行為，是為了讓文檔管理要作到及時、真實、符合規(guī)范，應(yīng)按以下要求來制定文檔模版和組織實施。及時指的是文檔制作要及時，歸檔要及時。真實指的是文檔中的數(shù)據(jù)必須是真實有效的。符合標準指的是文檔的格式和填寫必須規(guī)范。此外，根據(jù)大學項目特點，文檔管理要遵循以下原則：文檔名與文檔編號規(guī)范、文檔存貯策略；文檔質(zhì)量要求，文檔質(zhì)量體現(xiàn)在：針對性、精確性、清晰性、完整性、靈活性、可追溯性等方面；文檔管理計劃；建立連續(xù)控制機制；設(shè)計文檔標準；編寫文檔管理；發(fā)布文檔管理；維護文檔管理；開發(fā)管理；文檔傳遞流程；訪問控制；版本控制。根據(jù)本項目的特點，現(xiàn)主要說明下列幾點：項目庫為了管理整個項目，所有文檔都要記錄在項目庫中。項目庫是一個存放所有項目相關(guān)文檔硬拷貝的地方。文檔的軟拷貝必須被保存到一個預(yù)定義的網(wǎng)絡(luò)目錄，為了安全目的每個用戶的訪問都被控制。按照文檔的不同屬性分成幾類，建立集中的日志系統(tǒng)如：文件概要文件編號文件名稱和描述存儲的位置文檔傳遞流程項目庫中的文檔可以被項目組成員有目的的借出，項目庫管理員會寫一條記錄，用于跟追文檔和確保文檔在使用后歸還。為了便于項目庫的管理，對一個特定的版本只保存1份拷貝。當文檔不再具有使用價值的時候，文檔應(yīng)該被作廢。訪問控制所有文檔應(yīng)該保密。由客戶項目負責人決定讀寫權(quán)限。版本控制無論一個文檔的新版本什么時候發(fā)布，項目庫的集中日志系統(tǒng)都應(yīng)該更新以反映交付物的最新的變更。為了版本控制的管理，每個文檔都應(yīng)有一個修訂版。在文檔發(fā)布后，文檔的發(fā)布編號應(yīng)隨修訂而增加。采用版本控制的工具，以確保項目組中的所有成員都可以對任何一個交付物的當前版本進行操作。第六節(jié)系統(tǒng)測試一、測試任務(wù)與步驟系統(tǒng)測試是衡量產(chǎn)品質(zhì)量的重要過程。建立詳細的測試計劃是測試工作保質(zhì)保量完成的前提。而一個詳細的測試計劃需要依據(jù)項目的實際實施中發(fā)生的活動和系統(tǒng)需求來編制，我們將在項目實施過程中根據(jù)需要而制訂詳細、切實可行的測試計劃。本項目進行測試的主要任務(wù)有：制訂測試計劃、測試標準及測試風險評估和避免措施設(shè)計測試過程、用例和數(shù)據(jù)測試執(zhí)行評價商業(yè)情況的準確性利用測試結(jié)果，監(jiān)控和改進測試過程分析測試結(jié)果，給出測試報告，確定系統(tǒng)的可用性驗收測試過程包含以下步驟：制定測試策略和過程設(shè)計測試用例和數(shù)據(jù)準備測試環(huán)境測試執(zhí)行測試總結(jié)制定測試策略和過程：在測試過程中，客戶對遞交的系統(tǒng)進行測試和評估，確信系統(tǒng)滿足規(guī)定的驗收標準，確定系統(tǒng)是否能夠提高工作效率?？蛻魧ο到y(tǒng)的各個方面進行評估。制定一個好的測試范圍是成功進行驗收測試的關(guān)鍵。下面提出系統(tǒng)測試的主要范圍：用戶界面測試：驗證用戶界面符合標準。要求的測試數(shù)量取決于開發(fā)過程中為保證一致性所采用的工具，一般在測試剛開始時進行；功能測試：保證系統(tǒng)的運行滿足功能需求，使用工具BugBase；接口測試：保證與其它系統(tǒng)或子系統(tǒng)的接口工作正常；兼容性測試：保證系統(tǒng)在各種可能的用戶群眾都可以正常使用，如，不同的操作系統(tǒng)、瀏覽器、數(shù)據(jù)庫等；負載測試：保證系統(tǒng)在最大設(shè)計負載下運行平穩(wěn)，一個好的測試經(jīng)驗是讓系統(tǒng)在超過最大設(shè)計負載25%的數(shù)據(jù)和處理負載下運行；恢復(fù)測試：保證備份和恢復(fù)程序工作正常，以及當系統(tǒng)遇到突發(fā)事件如斷電、網(wǎng)絡(luò)連接中斷時對數(shù)據(jù)的正確處理。一般來說，恢復(fù)程序的基本測試在系統(tǒng)測試開始時進行，然后在系統(tǒng)測試結(jié)束之前再進行進一步的恢復(fù)測試；安全測試：驗證系統(tǒng)安全滿足要求，必須是系統(tǒng)的合法用戶才能登錄并進行允許的相關(guān)操作。由于安全是系統(tǒng)的基本功能，所以安全測試通常安排在系統(tǒng)測試的開始；轉(zhuǎn)換測試：驗證現(xiàn)有的數(shù)據(jù)能進行正確的轉(zhuǎn)換。通常情況下，在處理測試過程中轉(zhuǎn)換的數(shù)據(jù)與新數(shù)據(jù)一起使用來驗證數(shù)據(jù)轉(zhuǎn)換的正確性；文檔測試：驗證系統(tǒng)的用戶手冊、安裝手冊、幫助信息等說明性文檔的內(nèi)容是否符合功能及易讀、易理解；性能測試：驗證系統(tǒng)滿足性能標準（例如響應(yīng)時間）。使用工具loadrunner驗收測試工作通常由不同的用戶來進行（例如：業(yè)務(wù)人員測試系統(tǒng)功能，技術(shù)人員測試系統(tǒng)性能等）。有些情況下，一些測試工作可以合并在一個測試中完成。為協(xié)調(diào)各類測試人員的工作，做好周密的計劃是非常重要的。設(shè)計測試用例和數(shù)據(jù)測試用例和數(shù)據(jù)準備的目的是幫助用戶在不熟悉實際環(huán)境的時候，能正常的測試系統(tǒng)并對系統(tǒng)做出正確的評價。測試用例和數(shù)據(jù)的準備是一項枯燥和費時間的工作。為了提高工作效率可以從以下幾方面著手：將信息放在一個指定的位置，便于反復(fù)利用，降低變化產(chǎn)生的影響；一次完成一個步驟，避免冗余和額外的工作；盡早盡可能完成多個步驟。為了保證每一個業(yè)務(wù)流程準備測試用例和數(shù)據(jù)的正確性，在測試計劃中應(yīng)遵循下列過程，并完成以下步驟：確定要測試的業(yè)務(wù)情況類型確定每個要求的測試用例合并所有的測試用例，生成測試大綱編制測試腳本，包括必要的系統(tǒng)輸入信息和期望的輸出結(jié)果檢查信息保證每一步的準確性和完整性（即，確定業(yè)務(wù)情況類型、確定測試用例、生成測試大綱和編制測試腳本）。（1）確定業(yè)務(wù)情況類型確定實際商業(yè)環(huán)境中出現(xiàn)的業(yè)務(wù)情況類型是非常重要的。每一種業(yè)務(wù)情況類型都對應(yīng)一個實際商業(yè)業(yè)務(wù)。業(yè)務(wù)情況類型可以被表達成多種狀況（例如，簡單情況、或需要進行復(fù)雜處理的例外情況）。（2）確定測試用例對每一條規(guī)定驗收要求，確定測試用例。每個測試用例包括測試條件（包括生成測試條件需要的測試數(shù)據(jù)類型）和期望的結(jié)果。每個測試用例都應(yīng)該是唯一確定的（例如，賦一個數(shù)值）。（3）生成測試大綱對每一種業(yè)務(wù)情況類型，生成盡可能多的測試用例來完善測試大綱。為了保證測試大綱包含所有的測試用例，將測試用例的條件映射為測試大綱是非常必要的。測試大綱中測試用例的順序安排是非常重要的，它應(yīng)考慮多種方面的因素，主要考慮的因素：按照系統(tǒng)產(chǎn)生的數(shù)據(jù)，在測試大綱中安排測試用例的順序，使得一個測試的結(jié)果作為另一個測試前提。按以下順序編制測試大綱：確定唯一的標識（例如，測試大綱編號）確定業(yè)務(wù)情況類型對每種業(yè)務(wù)情況類型進行測試之前，列出成功完成測試必需的測試用例數(shù)目對每個測試用例按照測試進行的順序給出測試用例編號（4）編制測試腳本在了解系統(tǒng)構(gòu)造的情況下，將測試大綱概要作為編制測試腳本的指導(dǎo)。根據(jù)系統(tǒng)輸入指導(dǎo)測試人員如何進行測試。例如，編寫詳細的測試步驟或給出如何進行數(shù)據(jù)輸入的說明（如已經(jīng)填好數(shù)據(jù)的屏幕實例）。即使沒有相應(yīng)的測試，也要包括每一個必要的測試步驟以便確定測試條件。確定進行測試的時間（例如，進行輸入的模擬日期和期望觀察輸出結(jié)果的模擬日期，或?qū)ρh(huán)測試，對測試大綱進行測試的邏輯上的天數(shù)、周數(shù)、月數(shù)和年數(shù)要相當于兩個月的實際時間）（5）檢查測試每步測試完成后，需要利用測試計劃中確定的處理步驟對測試過程進行檢查（例如，檢查業(yè)務(wù)情況類型、測試用例、業(yè)務(wù)情況和測試腳本）建立測試環(huán)境為了預(yù)防出現(xiàn)問題，如數(shù)據(jù)損壞或?qū)ο到y(tǒng)資源的爭用，需要建立一個獨立的測試環(huán)境。在進行測試之前，根據(jù)測試計劃中確定的時機建立一個獨立的測試環(huán)境。其準備工作包括：技術(shù)活動：如建立不同的服務(wù)器或在一臺服務(wù)器上建立多個數(shù)據(jù)庫實例，將相應(yīng)的程序遷移到適當?shù)某绦驇熘校粩?shù)據(jù)準備活動：包括加載數(shù)據(jù)表，建立用戶訪問權(quán)限；建立版本控制程序，保證有效的控制對系統(tǒng)的修改；建立文檔控制程序，保證隨著系統(tǒng)的修改，有效地控制文檔的修改（如，培訓(xùn)文檔、聯(lián)機幫助和用戶手冊）。測試執(zhí)行測試執(zhí)行的目的是發(fā)現(xiàn)不滿足用戶要求的任何問題，在真實的環(huán)境中，客戶的工作人員按照準備好的測試大綱來對系統(tǒng)進行測試。測試過程中的測試結(jié)果是非常重要的。文檔可用于：檢查測試的進度；確定測試過程是否需要改進；分析系統(tǒng)是否準備就緒。（1）集成測試集成測試用來確認新系統(tǒng)中所有程序以及新系統(tǒng)與所有外部接口通信準確無誤。集成測試還必須證明新系統(tǒng)能按功能說明書上的需求進行工作，且在運行環(huán)境下有效發(fā)揮功能，而不會對其他系統(tǒng)造成影響。（2）檢查驗收測試的進度隨著測試地進行，定期的（一般每周）收集數(shù)據(jù)。將驗收進度與初始指定的測試計劃進度進行比較，一旦發(fā)現(xiàn)測試計劃進度的延遲，就需要馬上解決。（3）確定驗收測試過程是否需要改進測試小組內(nèi)部應(yīng)定期進行交流與共享在測試過程中得到的經(jīng)驗，應(yīng)善于接受改進建議，監(jiān)測過程變化，保證達到正確的結(jié)果。驗收測試小組可以定期召開小組會議或采用其它方法進行溝通。項目經(jīng)理和團隊成員必須以統(tǒng)一的方式檢查每一周期的測試結(jié)果。在隨后的測試周期再檢查詳細測試結(jié)果，確認在正常和非正常條件下每項功能是否正常執(zhí)行。這在回歸測試階段尤為重要，因為同樣的代碼要用數(shù)據(jù)不斷進行測試和再測試，直到確認所有詳細測試結(jié)果正常無誤。（4）用戶認可測試用戶認可測試模擬新系統(tǒng)的實際運行環(huán)境，包括用戶手冊和程序。用戶應(yīng)廣泛參與測試，用戶可以在操作新系統(tǒng)方面得到非常有價值的培訓(xùn)。同時程序員和設(shè)計人員還可以了解到用戶對新程序的反應(yīng)。這種聯(lián)合參與行為有助于用戶和操作人員對系統(tǒng)評估達成一致意見。（5）分析系統(tǒng)是否準備就緒測試狀態(tài)報告表明了系統(tǒng)準備的狀態(tài)。項目管理人員通過經(jīng)常檢查未解決的問題類型狀態(tài)，從而保證沒有重大的問題影響系統(tǒng)的實現(xiàn)。如果判定系統(tǒng)未準備好，可根據(jù)測試結(jié)果來改進測試計劃，改正的錯誤報告和改正計劃必須詳細說明。二、影響驗收的其他因素1.驗收風險分析影響驗收的風險：由于項目可能持續(xù)時間較長，原來需求組的成員可能會離開項目組，新的成員對需求的理解可能不同，這會延長驗收過程。在項目過程中，業(yè)務(wù)需求的改變是不可避免的。如果改變不能得到適當?shù)墓芾恚到y(tǒng)可能會滿足不了用戶期望，也會影響驗收。如果在測試后期（負載測試和容量測試）階段發(fā)現(xiàn)系統(tǒng)不能滿足系統(tǒng)性能要求，這會影響驗收進度安排。2.額外費用的控制方法控制方法有以下三項：保證需求描述明確地反映了要求。由于驗收是根據(jù)需求描述來進行的，所以會降低由于驗收小組的變化帶來的影響；所有的變化都必須得到有效的管理，從而保證驗收計劃得到相應(yīng)的調(diào)整，滿足客戶的需求；如果系統(tǒng)性能不能滿足性能要求，可以增加更多的或增加處理能力更強的硬件來提高性能。3.管理組織與控制為了使系統(tǒng)驗收測試過程順利進行，需要建立一個獨立的系統(tǒng)驗收測試委員會。下圖示提出的系統(tǒng)驗收測試委員會的組織機構(gòu)圖：《系統(tǒng)驗收測試委員會結(jié)構(gòu)圖》學校代表學校代表企業(yè)公司項目經(jīng)理IT代表用戶代表測試工程師測試人員系統(tǒng)驗收測試委員會驗收測試小組制定詳細的驗收計劃來說明進行系統(tǒng)驗收測試計劃的各個細節(jié)，以保證每個新的系統(tǒng)或相應(yīng)的成果與需求描述相一致。為了有效進行驗收，遞交的成果應(yīng)包括文檔資料（測試計劃、測試用例、測試報告），在有關(guān)系統(tǒng)完成之日交給大學。建立驗收測試委員會以便于用戶和開發(fā)人員的溝通，主要體現(xiàn)在企業(yè)公司項目經(jīng)理與大學負責人之間的驗收接口關(guān)系，以確保項目經(jīng)理在項目整個過程中的橋梁作用，以及有效的控制項目的變更管理。三、工程系統(tǒng)集成測試1.功能測試系統(tǒng)的功能通過功能測試進行驗證。在功能測試過程中發(fā)現(xiàn)的問題根據(jù)其嚴重程度進行分類。下表列出了功能測試問題的分類?！豆δ軠y試問題嚴重程度分類》PRIVATE嚴重程度問題說明Aa.不能提供任何系統(tǒng)能力b.不能完成操作或基本任務(wù)能力，但其它功能仍然可用c.影響操作完成或基本任務(wù)能力，沒有替代方案B影響操作完成或基本任務(wù)能力，有替代方案Ca.給用戶或操作者帶來不便或厭煩，但不影響要求的操作成或基本任務(wù)能力b.給支持人員帶來不便或厭煩，但不影響工作的執(zhí)行D任何其它影響或所提建議

開始功能測試接受驗收尋找解決方案用戶按照測試用例測試系統(tǒng)將驗收表交還項目協(xié)調(diào)人開始功能測試接受驗收尋找解決方案用戶按照測試用例測試系統(tǒng)將驗收表交還項目協(xié)調(diào)人項目協(xié)調(diào)人簽署遞交的成果項目協(xié)調(diào)人將簽署的標交給本公司項目經(jīng)理存在關(guān)鍵或嚴重的問題?模塊遞交測試已經(jīng)2周?解決問題已經(jīng)采取糾正措施?問題升級到驗收委員會進行解決采取糾正措施YYYNNN《系統(tǒng)功能測試驗收流程圖》

《功能測試表》測試標準測試成果驗收標準將測試結(jié)果與測試計劃和功能描述進行對照檢查，確定系統(tǒng)滿足功能描述的要求新系統(tǒng)可執(zhí)行程序功能描述接口描述操作手冊不存在B及以上級別的問題2.可靠性測試

下圖顯示了系統(tǒng)可靠性測試驗收流程圖功能測試完成功能測試完成接受驗收尋找解決方案用戶按照測試用例測試系統(tǒng)將驗收表交還項目協(xié)調(diào)人項目協(xié)調(diào)人簽署遞交的成果項目協(xié)調(diào)人將簽署的標交給企業(yè)公司項目經(jīng)理存在關(guān)鍵或嚴重的問題?超過2周期限?解決問題問題得到解決?問題升級到驗收委員會進行解決采取糾正措施YYYNNN延長1周測試期限Y《系統(tǒng)可靠性測試驗收流程圖》

《可靠性測試表》測試標準測試成果驗收標準將系統(tǒng)需求與功能描述進行對照檢查，確定系統(tǒng)是否滿足功能要求。通過分析系統(tǒng)資源消耗來檢查系統(tǒng)是否有效運行。新系統(tǒng)可執(zhí)行程序功能描述接口描述操作手冊不存在B及以上級別的問題3.系統(tǒng)集成部分的測試這里的系統(tǒng)集成部分指除了軟件部分的其他項目，例如主機、網(wǎng)絡(luò)、安全等方面的測試；由于這部分的內(nèi)容非常龐大。因此這里主要說明主機和網(wǎng)絡(luò)的測試方法?！吨鳈C測試方案示例表》測試項目測試內(nèi)容測試階段主機1．主機系統(tǒng)配置檢查主機系統(tǒng)配置檢查

(CPU、內(nèi)存、硬盤、DVD-ROM、網(wǎng)卡、光纖通道卡、磁帶機等)2．操作系統(tǒng)的安裝工具軟件以及系統(tǒng)補丁的安裝清單3．硬盤卷組內(nèi)置硬盤卷組設(shè)置、邏輯卷與交換分區(qū)設(shè)置4．磁盤陣列磁盤陣列與設(shè)置檢查(控制卡、磁盤容量)5．磁帶庫磁帶庫的安裝設(shè)置與邏輯卷的劃分6．系統(tǒng)安全主機系統(tǒng)安全與client訪問測試第七節(jié)系統(tǒng)驗收一、遞交成果的簽署（一）簽署的目的簽署指的是評審人在驗收文檔上簽字，表明評審人已對遞交的成果進行了評閱，并認為遞交的成果滿足要求，同時成果遞交者已解決評審人對遞交成果提出的意見。（二）評審和簽署程序本公司提出了以下評審和簽署程序在評審過程中，評審人將完成以下各項程序:檢查遞交的成果是否滿足要求在意見表中填寫評審意見在評審之后，評審人將意見表交給我公司項目經(jīng)理。如果評審人對遞交的成果提出重要意見或需求，需要對遞交的成果進行修改。遞交的成果修改之后，評審人將重新進行評審。對于每個評審循環(huán)，評審人將完成上述的步驟1到2。評審人將對遞交的成果進行完整的