評審技術(shù)在高質(zhì)量軟件開發(fā)中的應(yīng)用
郭華

摘要
軟件質(zhì)量和開發(fā)進(jìn)度一直是軟件開發(fā)成功關(guān)鍵的因素，而在實際工作中只有少量項目能按計劃完成，進(jìn)度要求往往迫使開發(fā)組無法保證軟件質(zhì)量，最終許多項目因為質(zhì)量問題無法投入使用。軟件評審作為一種軟件產(chǎn)品驗證的活動，能夠及早地從軟件產(chǎn)品中識別并消除缺陷，從而減少后期的返工，加快開發(fā)進(jìn)度，提高產(chǎn)品質(zhì)量。作為一種十分有效值得推廣的評審方法，在軟件過程改進(jìn)中起到了非常大的作用，同時軟件評審也是CMM等級3的關(guān)鍵過程域。
本文描述了正式和非正式的多種軟件評審技術(shù)，包括臨時評審、桌查、輪查、結(jié)隊編程、走查、小組評審和審查等，并系統(tǒng)地介紹了最正式、最嚴(yán)格、最有效的軟件評審——審查的整個過程，包括制定評審計劃、指定評審角色、做評審準(zhǔn)備、召開評審會議和驗證分析等過程。高質(zhì)量要求的軟件，如電信軟件、銀行證券軟件等，它們對可用性要求非常，因此對軟件質(zhì)量的要求非常嚴(yán)格。作者通過將評審技術(shù)應(yīng)用在高質(zhì)量軟件開發(fā)過程中，在實際開發(fā)過程中確定了評審的質(zhì)量標(biāo)準(zhǔn)和準(zhǔn)入、準(zhǔn)出條件，并針對數(shù)據(jù)采集、分析做了嚴(yán)格的控管，建立了質(zhì)量可預(yù)測的軟件開發(fā)過程體系，為有效地項目評估、質(zhì)量保證和項目管理提供了可靠依據(jù)，從而保證了軟件項目的成功。

關(guān)鍵詞：軟件評審、審查、開發(fā)過程、軟件、質(zhì)量、定量

一、軟件評審
1.1 缺陷的產(chǎn)生
缺陷指軟件工作產(chǎn)品中的一種情況，它將導(dǎo)致軟件產(chǎn)生不令人滿意或非預(yù)期的結(jié)果。在開發(fā)過程中缺陷隨時可能產(chǎn)生，問題在于什么時候發(fā)現(xiàn)它，并為此產(chǎn)生多少糾正成本。。根據(jù)一些企業(yè)返工度量的報導(dǎo)，缺陷返工率可達(dá)到整個開發(fā)工作量的40%~60%。
缺陷在軟件開發(fā)的任何階段都可能會被引入。項目質(zhì)量管理過程包含了許多可以識別缺陷、消除缺陷的過程?！白R別缺陷”和“消除缺陷”本來是兩個不同的過程，但在這里為了簡便統(tǒng)一用“消除”來代表它們。潛在的缺陷越大，用來消除它所花的費用越高。因此成熟的軟件開發(fā)過程在每一個可能會引入潛在缺陷的階段完成之后都會開展質(zhì)量控制活動。這些為了消除缺陷的活動包括：需求評審、設(shè)計評審、代碼走查、單元測試、集成測試、系統(tǒng)測試以及驗收測試等。一個缺陷如果保持沒有被發(fā)現(xiàn)的時間越長，則以后糾正此缺陷的花費越大。
缺陷越早發(fā)現(xiàn)、越早解決，則所花費的成本越低。因此我們應(yīng)該盡量在前期發(fā)現(xiàn)、識別并解決缺陷問題。

2、缺陷的識別
根據(jù)一些企業(yè)返工度量的報導(dǎo)，缺陷返工率可達(dá)到整個開發(fā)工作量的40%~60%。在軟件開發(fā)過程中，軟件評審和軟件測試是保證軟件質(zhì)量的兩種主要手段和方法。
測試可以識別可執(zhí)行系統(tǒng)中的缺陷，而評審不僅可識別可執(zhí)行系統(tǒng)中的缺陷，且能識別不能被執(zhí)行的文檔或人為產(chǎn)物。

測試和評審的比較
1）表現(xiàn)形式
測試的表現(xiàn)形式有：單元測試、集成測試、系統(tǒng)測試、用戶驗收測試
評審的表現(xiàn)形式有：審查、小組評審、走查、結(jié)對編程、同級桌查、輪查、臨時評審
2）工作對象
測試的工作對象為：可執(zhí)行系統(tǒng)（指編譯后可運行的程序）
評審的工作對象為：需求規(guī)格說明書、架構(gòu)（概要）設(shè)計文檔、詳細(xì)設(shè)計文檔、項目計劃、項目過程文檔、源代碼、系統(tǒng)界面、測試計劃、測試用例和數(shù)據(jù)、用戶手冊
3）識別缺陷的階段
測試識別缺陷的階段：測試階段（編碼完成后）
評審識別缺陷的階段：需求階段、設(shè)計階段、編碼階段、測試階段
4）識別缺陷的成效
測試的成效：最多識別軟件所有缺陷中30-35%的缺陷
評審的成效：最多識別軟件所有缺陷中70-75%的缺陷
5）識別缺陷的成本
測試的成本：識別一個重要缺陷平均花費15-25小時
評審的成本：需求階段識別一個重要缺陷平均花費2-3小時；
設(shè)計階段識別一個重要缺陷平均花費3-4小時；
代碼評審階段識別一個重要缺陷3-5小時；
測試計劃評審識別一個重要缺陷3-5小時
6）解決缺陷的成本
測試的成本：消除一個重要缺陷平均花費30-80小時（包括識別缺陷時間）
在開發(fā)后期才能識別缺陷，成本較高
評審的成本：需求及設(shè)計階段消除一個重要缺陷5-10小時；
代碼評審階段消除一個重要缺陷5-15小時
更傾向于在開發(fā)前期識別缺陷，成本較低
7）投入回報比較
（1）航天飛機(jī)搭乘項目：在設(shè)計或代碼評審時消除一個缺陷的成本為1美元，在系統(tǒng)測試時為13美元，交付使用后為92美元（Paulk etal,1995）。即13~92 : 1
（2）電信公司審查發(fā)現(xiàn)和糾正一個缺陷的平均費用為200美元，客戶驗收測試發(fā)現(xiàn)的缺陷平均花費4200美元(Boehm and Basili 2001)。即21 : 1
某研究表明，客戶使用過程中發(fā)現(xiàn)、糾正與需求相關(guān)的缺陷的費用是比需求開發(fā)階段發(fā)現(xiàn)和糾正同樣缺陷的費用的68~110倍(Boehm 1981;Grady 1999)。即 68~110 : 1
（3）印度Infosys公司經(jīng)驗表明：在代碼審查上多花費一天，這個產(chǎn)品就有期望在后期修改缺陷節(jié)省3-6天。即 3~6 : 1

3、軟件評審概念
1.3.1 定義
軟件評審，是指在軟件開發(fā)過程中，由參與評審的人員對軟件開發(fā)文檔或代碼進(jìn)行評審或檢查，幫助查找缺陷和改進(jìn)。
軟件評審的工作包括：
1）檢驗產(chǎn)品是否滿足以前的規(guī)范，如需求或設(shè)計文檔；
2）識別產(chǎn)品相對于標(biāo)準(zhǔn)的偏差；
3）向作者提出改進(jìn)建議；
4）促進(jìn)技術(shù)交流和學(xué)習(xí)。

軟件評審涉及評審的組織機(jī)構(gòu)、管理、準(zhǔn)則、類別、內(nèi)容、文件和要求等。一般要求在軟件研制階段的里程碑點進(jìn)行軟件評審。評審的主要類別有：軟件定義評審、軟件需求評審、概要設(shè)計評審、詳細(xì)設(shè)計評審、軟件實現(xiàn)評審和軟件驗收評審等。

1.3.2 軟件評審的分類
自從25年前，IBM的Michael Fagan提出軟件審查技術(shù)以來，許多組織使用這項技術(shù)得到了非常卓有成效的結(jié)果。這些組織包括IBM、HP、Motorola、Raytheon、Bull HN等。經(jīng)過幾十年的發(fā)展，軟件評審技術(shù)和多種項目管理理論相結(jié)合，已經(jīng)發(fā)展成一個龐大的體系。
就總體而言，軟件評審主要分為六類：審查、小組評審、走查、結(jié)隊編程、同級桌查和輪查、臨時評審。
其中審查是最系統(tǒng)化、最嚴(yán)密的評審技術(shù)，嚴(yán)格規(guī)定了每個階段的角色及各自職責(zé)，在質(zhì)量要求非常高的軟件開發(fā)項目中得到了較廣泛的應(yīng)用。

在判斷采用哪種評審方法時，需考慮以下風(fēng)險因素：
1）使用了新技術(shù)，方法，工具的組件
2）關(guān)鍵的架構(gòu)性的組件
3）難以理解，卻又必須準(zhǔn)確和優(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）以往具有很多缺陷或變更的模塊

1.3.4 審查的角色、職責(zé)及步驟
審查的角色主要分為評審組長、作者、讀者、評審人員、記錄者和驗證者。部分專家認(rèn)為審查的角色還有：評審協(xié)調(diào)人。根據(jù)管理的原則，評審協(xié)調(diào)人的角色應(yīng)歸入評審組長，其職責(zé)由評審組長負(fù)責(zé)。

審查的角色及職責(zé)
1）評審組長
（1）計劃、安排和組織評審活動；
（2）和作者一起選擇評審人，并分配角色；
（3）主持總體會議和評審會議；
（4）提交需評審的產(chǎn)品給每一個評審人；
（5）檢查評審會議的準(zhǔn)備是否充分，從而決定是否召開評審會議；
（6）領(lǐng)導(dǎo)小組確定評審效果；
（7）提交《評審總結(jié)報告》；
（8）維護(hù)每次評審的評審記錄及來自評審總結(jié)報告中的數(shù)據(jù)；
（9）根據(jù)評審數(shù)據(jù)形成報告，提交給管理層、過程改進(jìn)組及評審過程的擁有者。
2）作者
（1）作為被評審產(chǎn)品的作者或維護(hù)者，提交工作產(chǎn)品；
（2）協(xié)助評審組長選擇評審人，并分配角色；
（3）陳述評審目標(biāo)；
（4）初步講解產(chǎn)品；
（5）返工；
（6）向評審組長報告返工時間和缺陷數(shù)；
3）讀者
將工作產(chǎn)品在評審會議上用自己的語言進(jìn)行解說，測試工作產(chǎn)品的可理解性，暴露產(chǎn)品的二義性、隱含假設(shè)等各種缺陷；
4）評審人員
（1）在評審會議之前檢查工作產(chǎn)品，發(fā)現(xiàn)其缺陷，為參加評審會議做準(zhǔn)備；
（2）記錄準(zhǔn)備時間；
（3）參加評審，識別缺陷，提出問題，給出改進(jìn)建議。
5）記錄者
記錄評審會議中提出的問題并分類。
6）驗證者
進(jìn)行跟蹤，確認(rèn)返工工作被正確執(zhí)行。

審查的主要步驟有：
1）評審計劃；
2）總體會議；
3）評審準(zhǔn)備；
4）評審會議；
5）修改、驗證。

二、軟件開發(fā)模型
2.1 軟件生命周期
軟件生命周期指軟件的產(chǎn)生直到報廢的生命周期，周期內(nèi)有系統(tǒng)定義、需求分析、系統(tǒng)設(shè)計、編碼實現(xiàn)、系統(tǒng)/驗收測試、運行維護(hù)到廢棄等階段。
組織軟件開發(fā)過程的規(guī)則，就可以稱為軟件生命周期模型。一個定義良好的軟件生命周期模型，可以很好的指導(dǎo)我們的開發(fā)工作，使漫長的開發(fā)工作易于控制。事實上，我們可以任意定義自己喜歡的軟件生命周期模型。但是，如果生命周期模型定義不合理，卻會制約我們的開發(fā)過程。軟件開發(fā)人員在長期開發(fā)過程已經(jīng)總結(jié)出了幾種常用的軟件生命周期模型，我們可以根據(jù)項目的特點來選擇一個合適的模型，然后在此基礎(chǔ)上再加以裁減。
這些生命周期模型是：
1）瀑布模型，
2）快速原型模型，
3）漸增模型，
4）演進(jìn)模型。
其中瀑布模型是所有生命周期模型的核心和基礎(chǔ)，其他模型都是基于瀑布模型發(fā)展和衍化而來。瀑布模型分為六個階段：系統(tǒng)定義、需求分析、系統(tǒng)設(shè)計、編碼實現(xiàn)、系統(tǒng)驗收測試、運行維護(hù)。
在瀑布模型中每個階段都要有定義、工作、審查、形成文檔以供交流或備查，以提高軟件的質(zhì)量。

2.2 項目開發(fā)V模型
在瀑布模型的基礎(chǔ)上，衍生出了強(qiáng)調(diào)測試活動的V模型。它把瀑布模型的測試階段進(jìn)行細(xì)分，并于前面的階段進(jìn)行對應(yīng)。細(xì)分出來的這些階段分別為：單元測試階段、集成測試階段和系統(tǒng)測試階段。
在V模型中，我們可以知道：
1）在需求分析階段，《系統(tǒng)需求規(guī)格說明書》確認(rèn)后，編寫《系統(tǒng)測試計劃》，準(zhǔn)備系統(tǒng)測試用例、數(shù)據(jù)，對需求進(jìn)行驗證；對應(yīng)的系統(tǒng)測試階段，執(zhí)行系統(tǒng)測試計劃；
2）在概要設(shè)計階段，《概要設(shè)計說明書》確認(rèn)后，編寫《集成測試計劃》，準(zhǔn)備集成測試用例、數(shù)據(jù)等，對概要設(shè)計進(jìn)行驗證；然后在對應(yīng)的集成測試階段，執(zhí)行集成測試計劃；
3）在詳細(xì)設(shè)計階段，《詳細(xì)設(shè)計說明書》確認(rèn)后，編寫《單元測試計劃》，準(zhǔn)備單元測試用例、數(shù)據(jù)等，對詳細(xì)設(shè)計進(jìn)行驗證，然后在對應(yīng)的單元測試階段，執(zhí)行單元測試計劃。

三、評審在高質(zhì)量軟件開發(fā)的實際應(yīng)用
3.1 高質(zhì)量軟件開發(fā)項目介紹
高質(zhì)量軟件，如電信軟件、金融證券類軟件等，有較嚴(yán)格的要求：可用性要求非常高，并且不會因為系統(tǒng)維護(hù)和擴(kuò)展而帶來運營中斷；支持使用現(xiàn)有管理工具和標(biāo)準(zhǔn)進(jìn)行遠(yuǎn)程管理；能夠提供更出色的性能以及運營在高可用性集群上的能力，減少任何單點的軟硬件失效現(xiàn)象。五個九（99.999%）意味著一個系統(tǒng)的宕機(jī)時間一年不超過5分26秒。因此高質(zhì)量軟件項目是一種對可用性、可靠性、穩(wěn)定性要求非常高的軟件項目，要求軟件能夠每周7*24工作。
因此高質(zhì)量軟件開發(fā)一般采用嚴(yán)格的軟件開發(fā)過程，明確定義每個階段的質(zhì)量目標(biāo)和要求，嚴(yán)格項目軟件開發(fā)過程控制。
我們在多個高質(zhì)量軟件開發(fā)項目中成功地采用了評審技術(shù)，并發(fā)揮了巨大的作用。從這些項目的實際開發(fā)過程中，我們針對于規(guī)模從30人月——300人月，代碼行數(shù)從5萬行——30萬行的運營支撐系統(tǒng)項目制定了項目評審流程和相關(guān)要求。

3.2 軟件過程定義
軟件過程主要分為項目立項階段、需求分析階段、設(shè)計階段、編碼實現(xiàn)階段、測試階段（包括集成測試、系統(tǒng)測試和用戶驗收測試）、實施階段和維護(hù)階段，項目管理工作橫貫于所有的階段。詳細(xì)流程見流程圖。
在軟件過程中，我們定義了以下角色：
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ì)量活動的流程和標(biāo)準(zhǔn)，如軟件過程定義，質(zhì)量達(dá)標(biāo)定義等；
2）實施質(zhì)量保證——編寫相應(yīng)的測試計劃、執(zhí)行測試和評審活動；
3）實施質(zhì)量控制——監(jiān)控質(zhì)量保證活動的結(jié)果，判斷是否達(dá)標(biāo)，如不達(dá)標(biāo)，則采取相應(yīng)的風(fēng)險防范措施。

立項及需求階段流程（圖略）


設(shè)計及編碼階段流程（圖略）


集成、系統(tǒng)及驗收測試階段流程（圖略）


實施維護(hù)階段流程（圖略）

3.3 軟件評審過程及標(biāo)準(zhǔn)定義
我們在整體軟件過程中明確定義了需要軟件評審的過程及實施的方法。
（圖略）

3.3.1 采用審查的過程
采用最嚴(yán)格最系統(tǒng)的評審方法——審查的軟件過程有：
1）《軟件需求規(guī)格說明書》的評審
2）《概要設(shè)計說明書》的評審
3）《詳細(xì)設(shè)計說明書》的評審
4）代碼評審
5）《單元測試計劃》的評審
6）《集成測試計劃》的評審
7）《系統(tǒng)測試計劃》的評審
對于文檔評審以文檔頁數(shù)為基數(shù)，要求每頁發(fā)現(xiàn)的缺陷數(shù)有一個目標(biāo)值，并規(guī)定了上下限的范圍。對于代碼評審以代碼行數(shù)為基數(shù)，要求每千行代碼發(fā)現(xiàn)的缺陷數(shù)有一個目標(biāo)值，并規(guī)定了上下限的范圍。這個審查的缺陷數(shù)標(biāo)準(zhǔn)如下表。

軟件過程審查的質(zhì)量目標(biāo)
質(zhì)量目標(biāo) 目標(biāo) 下限 上限
SRS文檔Review缺陷發(fā)現(xiàn)密度（個/頁）： 0.80 0.50 1.10
HLD文檔Review缺陷發(fā)現(xiàn)密度（個/頁）： 0.70 0.50 0.90
LLD文檔Review缺陷發(fā)現(xiàn)密度（個/頁）： 0.43 0.22 0.64
代碼檢視缺陷發(fā)現(xiàn)密度（個/KLOC）： 10.62 7.43 13.81
單元測試計劃Review缺陷發(fā)現(xiàn)密度（個/頁）： 0.43 0.22 0.64
集成測試計劃Review缺陷發(fā)現(xiàn)密度（個/頁）： 0.70 0.50 0.90
系統(tǒng)測試計劃Review缺陷發(fā)現(xiàn)密度（個/頁）： 0.80 0.50 1.10

如果發(fā)現(xiàn)的缺陷密度低于或高于質(zhì)量目標(biāo)范圍，則我們需要分析其原因，然后根據(jù)原因進(jìn)行返工或相應(yīng)處理流程。這要和實際情況相結(jié)合，具體情況具體分析：如某個開發(fā)工程師的水平和素質(zhì)非常高，他的代碼一般很少出錯，這樣他的代碼檢視缺陷密度低是屬于正常的；而另外一個工程師水平一般，但發(fā)現(xiàn)的缺陷密度也很低，但原因是屬于檢視的過程不嚴(yán)格，大家沒有時間來進(jìn)行嚴(yán)格的評審，則此時需要重新進(jìn)行檢視。

3.3.2 采用小組評審的過程
采用小組評審的軟件過程主要包括對客戶需求的評審、項目計劃的評審和維護(hù)計劃的評審。
對客戶需求的評審參加人員有項目經(jīng)理、系統(tǒng)分析員、系統(tǒng)架構(gòu)師、質(zhì)量部主管等。
項目計劃的評審主要由項目經(jīng)理、系統(tǒng)分析員、系統(tǒng)架構(gòu)師、質(zhì)量部主管和部門經(jīng)理等參加，對人力資源、進(jìn)度和質(zhì)量管控等進(jìn)行評審。
維護(hù)計劃由項目經(jīng)理、技術(shù)支持人員、質(zhì)量部主管和客戶服務(wù)人員參加，對人力資源、管控流程等進(jìn)行評審。

3.3.3 采用走查評審的過程
需求分析過程中，系統(tǒng)分析員、系統(tǒng)架構(gòu)師相互之間的走查；
設(shè)計過程中，系統(tǒng)分析員、系統(tǒng)架構(gòu)師相互之間的走查；
在進(jìn)入維護(hù)階段時，作者需和維護(hù)人員進(jìn)行走查，讓維護(hù)人員能夠維護(hù)作者的工作產(chǎn)品。

3.3.4 采用桌查的過程
采用桌查的過程主要集中在代碼提交階段，主要是經(jīng)驗豐富的開發(fā)人員對提交的代碼進(jìn)行檢查，合格的產(chǎn)品才會提交到CVS上面。
具體實施方法為：開發(fā)經(jīng)驗較少（8年以下開發(fā)經(jīng)驗）的開發(fā)人員在提交代碼時，請經(jīng)驗豐富（10年以上開發(fā)經(jīng)驗）的開發(fā)人員進(jìn)行桌查，沒有明顯問題后才允許提交；經(jīng)驗豐富的開發(fā)人員提交代碼時也需另一名經(jīng)驗豐富的開發(fā)人員桌查后方可提交。

3.3.5 采用臨時評審的過程
代碼編寫階段開發(fā)工程師之間的臨時評審；
其他開發(fā)階段，開發(fā)人員相互之間的臨時評審。

3.3.6 采用結(jié)隊編程的過程
針對于需求不明確、采用迭代增量開發(fā)過程的小規(guī)模項目，采用極限編程時，建議采用結(jié)隊編程，但一般不做強(qiáng)制規(guī)定。
我們實際采用極限編程思想進(jìn)行了兩個項目（一個內(nèi)部項目和一個外部項目）的開發(fā)，實際上取得了非常好的效果。開發(fā)人員實際產(chǎn)出值達(dá)到了5000行代碼/人月以上。當(dāng)然這些項目不太大，同時文檔編寫比較簡單。

3.4 審查流程定義
我們規(guī)定了審查流程的定義，其他評審技術(shù)只是采用了其中的流程和管理思想。

審查流程（圖略）


3.5 軟件評審效果分析
我們強(qiáng)化了軟件評審技術(shù)后，在實際過程中取得了非常好的效果。以一個網(wǎng)絡(luò)流量分析的項目為實例，在第一期沒有嚴(yán)格實施軟件評審技術(shù)，而第二期嚴(yán)格實施了軟件評審技術(shù)，其中審查數(shù)據(jù)如下表。

評審過程數(shù)據(jù)及質(zhì)量分析實例
文件/模塊 計算基數(shù)(頁數(shù)/KLOC) 致命 嚴(yán)重 一般 提示 總和 標(biāo)準(zhǔn)(目標(biāo)/下限-上限) 比例 達(dá)標(biāo)與否
SRS 42 1 1 29 10 31 0.8 / 0.5~1.1 0.738 OK
STP 58 22 15 12 37 0.8 / 0.5~1.1 0.638 OK
HLD 34 4 15 29 19 0.7 / 0.5~0.9 0.559 OK
LLD 205 11 59 29 70 0.43 / 0.22~0.64 0.341 OK
UTP 217 15 80 15 95 0.43 / 0.22~0.64 0.438 OK
CodeReview 50 7 372 151 379 10.62 / 7.43~13.8 7.580 OK
SITP 50 6 98 112 30 216 5.65/3.86~8.44 4.320 OK

產(chǎn)生的效果為：
1）產(chǎn)出量：單位開發(fā)人員的產(chǎn)出量由950行代碼/人月（全流程）增長到1320行代碼/人月（全流程），增長量為38.9%。關(guān)鍵原因在于大在減少了項目后期返工的工作量?？紤]由于項目熟悉和學(xué)習(xí)曲線等的原因，實際的產(chǎn)出增長量應(yīng)該超過20%。
2）產(chǎn)品質(zhì)量（遺留缺陷密度）：我們從軟件系統(tǒng)的遺留缺陷率來分析系統(tǒng)的質(zhì)量情況。在半年的維護(hù)時間內(nèi)，第一期代碼行為4萬行，嚴(yán)重缺陷有5個，一般缺陷有32個，嚴(yán)重缺陷發(fā)現(xiàn)密度為0.125個缺陷/千行代碼，總遺留缺陷發(fā)現(xiàn)密度為0.925個缺陷/千行代碼；第二期代碼行數(shù)為5萬行，嚴(yán)重缺陷有1個（屬于客戶需求問題引發(fā)的設(shè)計缺陷），一般缺陷有15個，嚴(yán)重缺陷發(fā)現(xiàn)密度為0.02個缺陷/千行代碼，總遺留缺陷發(fā)現(xiàn)密度為0.32個缺陷/千行代碼。因此嚴(yán)重缺陷發(fā)現(xiàn)密度改進(jìn)了84%，一般缺陷發(fā)現(xiàn)密度改進(jìn)了65.4%。
3）客戶滿意度：第一期客戶嚴(yán)重不滿意，稱我們在做玩具，滿意度只有22%；第二期客戶滿意度大幅上升，稱我們是專業(yè)人士，非常敬業(yè)，為他們所欽佩，滿意度達(dá)到了91%。因此滿意度提高了314%。
最主要的是，我們采用了軟件評審技術(shù)，規(guī)范了軟件開發(fā)過程的標(biāo)準(zhǔn)，并積累了實際的軟件開發(fā)過程數(shù)據(jù)，為后面的項目管理和過程控制提供了寶貴的軟件過程財富。

四、總結(jié)和展望
在實際工作中，我們以前掌握的過程數(shù)據(jù)不多，基本上一步一步摸索著前進(jìn)，對于過程數(shù)據(jù)也在不斷的收集及整理中。對于評審技術(shù)而言，其中最重要的一點是采用多種實際工具和手段，如針對每個過程進(jìn)行評審的《缺陷檢查表》等，我們也在逐步地完善這套體系和過程數(shù)據(jù)，從而為我們的過程改進(jìn)不斷提供支持。


參考文獻(xiàn)：
[1] Karl Wiegers. Seven Deadly Sins of Software Reviews. Software Development. 1997.3
[2] Steve McConnell. Software Quality at Top Speed. Software Development. 1996.8
[3] 沈備軍,宿為民譯. 軟件同級評審. Karl E.Wiegers. Peer Reviews in Software A Practical Guide. 機(jī)械工業(yè)出版社. 2003.4
[4] Watts S. Humphrey. Introduction to the Personal Software Process. 人民郵電出版社. 2002.10
[5] 盧有杰,王勇譯. 項目管理知識體系指南（第三版）. 美國項目管理協(xié)會. A Guide to the Project Management Body of Knowledge, Third Edition(PMBOK Guide). 電子工業(yè)出版社. 2005.1
[6] 胡春哲,張潔等譯. CMM實踐應(yīng)用——Infosys公司的軟件項目執(zhí)行過程. Pearson Education. CMM in Practice: Processes for Executing Software Projects at Infosys. 電子工業(yè)出版社. 2002.8.1

【?發(fā)表評論?0條?】