【正文】 2）產(chǎn)品質(zhì)量（遺留缺陷密度）：我們從軟件系統(tǒng)的遺留缺陷率來分析系統(tǒng)的質(zhì)量情況。項目計劃的評審主要由項目經(jīng)理、系統(tǒng)分析員、系統(tǒng)架構(gòu)師、質(zhì)量部主管和部門經(jīng)理等參加，對人力資源、進度和質(zhì)量管控等進行評審。五個九（%）意味著一個系統(tǒng)的宕機時間一年不超過5分26秒。 審查的主要步驟有：1）評審計劃；2）總體會議；3）評審準備；4）評審會議；5）修改、驗證。軟件評審的工作包括：1）檢驗產(chǎn)品是否滿足以前的規(guī)范，如需求或設(shè)計文檔；2）識別產(chǎn)品相對于標準的偏差；3）向作者提出改進建議；4）促進技術(shù)交流和學習?！白R別缺陷”和“消除缺陷”本來是兩個不同的過程，但在這里為了簡便統(tǒng)一用“消除”來代表它們。高質(zhì)量要求的軟件，如電信軟件、銀行證券軟件等，它們對可用性要求非常，因此對軟件質(zhì)量的要求非常嚴格。測試可以識別可執(zhí)行系統(tǒng)中的缺陷，而評審不僅可識別可執(zhí)行系統(tǒng)中的缺陷，且能識別不能被執(zhí)行的文檔或人為產(chǎn)物。在判斷采用哪種評審方法時，需考慮以下風險因素：1）使用了新技術(shù)，方法，工具的組件2）關(guān)鍵的架構(gòu)性的組件3）難以理解，卻又必須準確和優(yōu)化的復(fù)雜邏輯或算法4）具有危險失敗模式的組件，而且是任務(wù)、可靠性、安全性關(guān)鍵的5）具有多個異常條件或失敗模式的組件6）不易測試的異常處理代碼7）打算復(fù)用的組件8）將作為其他組件的模型或模板的組件9）影響產(chǎn)品多個部分的組件10）復(fù)雜的用戶界面11）由缺乏經(jīng)驗的開發(fā)者創(chuàng)建的組件12）具有高度圈復(fù)雜性的代碼模塊13）以往具有很多缺陷或變更的模塊 審查的角色、職責及步驟審查的角色主要分為評審組長、作者、讀者、評審人員、記錄者和驗證者。瀑布模型分為六個階段：系統(tǒng)定義、需求分析、系統(tǒng)設(shè)計、編碼實現(xiàn)、系統(tǒng)驗收測試、運行維護。（圖略） 采用審查的過程采用最嚴格最系統(tǒng)的評審方法——審查的軟件過程有：1）《軟件需求規(guī)格說明書》的評審2）《概要設(shè)計說明書》的評審3）《詳細設(shè)計說明書》的評審4）代碼評審5）《單元測試計劃》的評審6）《集成測試計劃》的評審7）《系統(tǒng)測試計劃》的評審對于文檔評審以文檔頁數(shù)為基數(shù)，要求每頁發(fā)現(xiàn)的缺陷數(shù)有一個目標值，并規(guī)定了上下限的范圍。當然這些項目不太大，同時文檔編寫比較簡單。對于評審技術(shù)而言，其中最重要的一點是采用多種實際工具和手段，如針對每個過程進行評審的《缺陷檢查表》等，我們也在逐步地完善這套體系和過程數(shù)據(jù)，從而為我們的過程改進不斷提供支持。我們實際采用極限編程思想進行了兩個項目（一個內(nèi)部項目和一個外部項目）的開發(fā)，實際上取得了非常好的效果。在軟件過程中，我們定義了以下角色：1）客戶2）銷售人員3）項目經(jīng)理4）系統(tǒng)分析員5）系統(tǒng)架構(gòu)師6）開發(fā)工程師7）質(zhì)量工程師8）技術(shù)支持人員在規(guī)劃質(zhì)量體系時，我們參考PMBOK對項目質(zhì)量管理的要求，將項目質(zhì)量管理過程設(shè)計為三個階段：1）質(zhì)量規(guī)劃——確定質(zhì)量活動的流程和標準，如軟件過程定義，質(zhì)量達標定義等；2）實施質(zhì)量保證——編寫相應(yīng)的測試計劃、執(zhí)行測試和評審活動；3）實施質(zhì)量控制——監(jiān)控質(zhì)量保證活動的結(jié)果，判斷是否達標，如不達標，則采取相應(yīng)的風險防范措施。這些生命周期模型是：1）瀑布模型，2）快速原型模型，3）漸增模型，4）演進模型。就總體而言，軟件評審主要分為六類：審查、小組評審、走查、結(jié)隊編程、同級桌查和輪查、臨時評審。缺陷的識別根據(jù)一些企業(yè)返工度量的報導(dǎo)，缺陷返工率可達到整個開發(fā)工作量的40%~60%。作為一種十分有效值得推廣的評審方法，在軟件過程改