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

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

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

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

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

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

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

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

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

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

在判斷采用哪種評(píng)審方法時(shí)，需考慮以下風(fēng)險(xiǎn)因素：
1）使用了新技術(shù)，方法，工具的組件
2）關(guān)鍵的架構(gòu)性的組件
3）難以理解，卻又必須準(zhǔn)確和優(yōu)化的復(fù)雜邏輯或算法
4）具有危險(xiǎn)失敗模式的組件，而且是任務(wù)、可靠性、安全性關(guān)鍵的
5）具有多個(gè)異常條件或失敗模式的組件
6）不易測(cè)試的異常處理代碼
7）打算復(fù)用的組件
8）將作為其他組件的模型或模板的組件
9）影響產(chǎn)品多個(gè)部分的組件
10）復(fù)雜的用戶界面
11）由缺乏經(jīng)驗(yàn)的開發(fā)者創(chuàng)建的組件
12）具有高度圈復(fù)雜性的代碼模塊
13）以往具有很多缺陷或變更的模塊

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

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

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

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

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

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

3.2 軟件過(guò)程定義
軟件過(guò)程主要分為項(xiàng)目立項(xiàng)階段、需求分析階段、設(shè)計(jì)階段、編碼實(shí)現(xiàn)階段、測(cè)試階段（包括集成測(cè)試、系統(tǒng)測(cè)試和用戶驗(yàn)收測(cè)試）、實(shí)施階段和維護(hù)階段，項(xiàng)目管理工作橫貫于所有的階段。詳細(xì)流程見流程圖。
在軟件過(guò)程中，我們定義了以下角色：
1）客戶
2）銷售人員
3）項(xiàng)目經(jīng)理
4）系統(tǒng)分析員
5）系統(tǒng)架構(gòu)師
6）開發(fā)工程師
7）質(zhì)量工程師
8）技術(shù)支持人員

在規(guī)劃質(zhì)量體系時(shí)，我們參考PMBOK對(duì)項(xiàng)目質(zhì)量管理的要求，將項(xiàng)目質(zhì)量管理過(guò)程設(shè)計(jì)為三個(gè)階段：
1）質(zhì)量規(guī)劃——確定質(zhì)量活動(dòng)的流程和標(biāo)準(zhǔn)，如軟件過(guò)程定義，質(zhì)量達(dá)標(biāo)定義等；
2）實(shí)施質(zhì)量保證——編寫相應(yīng)的測(cè)試計(jì)劃、執(zhí)行測(cè)試和評(píng)審活動(dòng)；
3）實(shí)施質(zhì)量控制——監(jiān)控質(zhì)量保證活動(dòng)的結(jié)果，判斷是否達(dá)標(biāo)，如不達(dá)標(biāo)，則采取相應(yīng)的風(fēng)險(xiǎn)防范措施。

立項(xiàng)及需求階段流程（圖略）

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

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

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

3.3 軟件評(píng)審過(guò)程及標(biāo)準(zhǔn)定義
我們?cè)谡w軟件過(guò)程中明確定義了需要軟件評(píng)審的過(guò)程及實(shí)施的方法。
（圖略）

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

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

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

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

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

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

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

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

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

審查流程（圖略）

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

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

四、總結(jié)和展望
在實(shí)際工作中，我們以前掌握的過(guò)程數(shù)據(jù)不多，基本上一步一步摸索著前進(jìn)，對(duì)于過(guò)程數(shù)據(jù)也在不斷的收集及整理中。對(duì)于評(píng)審技術(shù)而言，其中最重要的一點(diǎn)是采用多種實(shí)際工具和手段，如針對(duì)每個(gè)過(guò)程進(jìn)行評(píng)審的《缺陷檢查表》等，我們也在逐步地完善這套體系和過(guò)程數(shù)據(jù)，從而為我們的過(guò)程改進(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] 沈備軍,宿為民譯. 軟件同級(jí)評(píng)審. 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àng)目管理知識(shí)體系指南（第三版）. 美國(guó)項(xiàng)目管理協(xié)會(huì). A Guide to the Project Management Body of Knowledge, Third Edition(PMBOK Guide). 電子工業(yè)出版社. 2005.1
[6] 胡春哲,張潔等譯. CMM實(shí)踐應(yīng)用——Infosys公司的軟件項(xiàng)目執(zhí)行過(guò)程. Pearson Education. CMM in Practice: Processes for Executing Software Projects at Infosys. 電子工業(yè)出版社. 2002.8.1

QQ在線咨詢