房地產(chǎn)項(xiàng)目管理軟件
當(dāng)前位置：工程項(xiàng)目OA系統(tǒng) > 房地產(chǎn)OA系統(tǒng) > 相關(guān)系統(tǒng) > 房地產(chǎn)項(xiàng)目管理軟件
評審技術(shù)在高質(zhì)量軟件開發(fā)中的應(yīng)用
評審技術(shù)在高質(zhì)量軟件開發(fā)中的應(yīng)用
郭華
摘要
軟件質(zhì)量和開發(fā)進(jìn)度一直是軟件開發(fā)成功關(guān)鍵的因素，而在實(shí)際工作中只有少量項(xiàng)目能按計(jì)劃完成，進(jìn)度要求往往迫使開發(fā)組無法保證軟件質(zhì)量，最終許多項(xiàng)目因?yàn)橘|(zhì)量問題無法投入使用。軟件評審作為一種軟件產(chǎn)品驗(yàn)證的活動(dòng)，能夠及早地從軟件產(chǎn)品中識別并消除缺陷，從而減少后期的返工，加快開發(fā)進(jìn)度，提高產(chǎn)品質(zhì)量。作為一種十分有效值得推廣的評審方法，在軟件過程改進(jìn)中起到了非常大的作用，同時(shí)軟件評審也是CMM等級3的關(guān)鍵過程域。
本文描述了正式和非正式的多種軟件評審技術(shù)，包括臨時(shí)評審、桌查、輪查、結(jié)隊(duì)編程、走查、小組評審和審查等，并系統(tǒng)地介紹了最正式、最嚴(yán)格、最有效的軟件評審——審查的整個(gè)過程，包括制定評審計(jì)劃、指定評審角色、做評審準(zhǔn)備、召開評審會議和驗(yàn)證分析等過程。高質(zhì)量要求的軟件，如電信軟件、銀行證券軟件等，它們對可用性要求非常，因此對軟件質(zhì)量的要求非常嚴(yán)格。作者通過將評審技術(shù)應(yīng)用在高質(zhì)量軟件開發(fā)過程中，在實(shí)際開發(fā)過程中確定了評審的質(zhì)量標(biāo)準(zhǔn)和準(zhǔn)入、準(zhǔn)出條件，并針對數(shù)據(jù)采集、分析做了嚴(yán)格的控管，建立了質(zhì)量可預(yù)測的軟件開發(fā)過程體系，為有效地項(xiàng)目評估、質(zhì)量保證和項(xiàng)目管理提供了可靠依據(jù)，從而保證了軟件項(xiàng)目的成功。
關(guān)鍵詞：軟件評審、審查、開發(fā)過程、軟件、質(zhì)量、定量
一、軟件評審
1.1 缺陷的產(chǎn)生
缺陷指軟件工作產(chǎn)品中的一種情況，它將導(dǎo)致軟件產(chǎn)生不令人滿意或非預(yù)期的結(jié)果。在開發(fā)過程中缺陷隨時(shí)可能產(chǎn)生，問題在于什么時(shí)候發(fā)現(xiàn)它，并為此產(chǎn)生多少糾正成本。。根據(jù)一些企業(yè)返工度量的報(bào)導(dǎo)，缺陷返工率可達(dá)到整個(gè)開發(fā)工作量的40%~60%。
缺陷在軟件開發(fā)的任何階段都可能會被引入。項(xiàng)目質(zhì)量管理過程包含了許多可以識別缺陷、消除缺陷的過程?！白R別缺陷”和“消除缺陷”本來是兩個(gè)不同的過程，但在這里為了簡便統(tǒng)一用“消除”來代表它們。潛在的缺陷越大，用來消除它所花的費(fèi)用越高。因此成熟的軟件開發(fā)過程在每一個(gè)可能會引入潛在缺陷的階段完成之后都會開展質(zhì)量控制活動(dòng)。這些為了消除缺陷的活動(dòng)包括：需求評審、設(shè)計(jì)評審、代碼走查、單元測試、集成測試、系統(tǒng)測試以及驗(yàn)收測試等。一個(gè)缺陷如果保持沒有被發(fā)現(xiàn)的時(shí)間越長，則以后糾正此缺陷的花費(fèi)越大。
缺陷越早發(fā)現(xiàn)、越早解決，則所花費(fèi)的成本越低。因此我們應(yīng)該盡量在前期發(fā)現(xiàn)、識別并解決缺陷問題。
2、缺陷的識別
根據(jù)一些企業(yè)返工度量的報(bào)導(dǎo)，缺陷返工率可達(dá)到整個(gè)開發(fā)工作量的40%~60%。在軟件開發(fā)過程中，軟件評審和軟件測試是保證軟件質(zhì)量的兩種主要手段和方法。
測試可以識別可執(zhí)行系統(tǒng)中的缺陷，而評審不僅可識別可執(zhí)行系統(tǒng)中的缺陷，且能識別不能被執(zhí)行的文檔或人為產(chǎn)物。
測試和評審的比較
1）表現(xiàn)形式
測試的表現(xiàn)形式有：單元測試、集成測試、系統(tǒng)測試、用戶驗(yàn)收測試
評審的表現(xiàn)形式有：審查、小組評審、走查、結(jié)對編程、同級桌查、輪查、臨時(shí)評審
2）工作對象
測試的工作對象為：可執(zhí)行系統(tǒng)（指編譯后可運(yùn)行的程序）
評審的工作對象為：需求規(guī)格說明書、架構(gòu)（概要）設(shè)計(jì)文檔、詳細(xì)設(shè)計(jì)文檔、項(xiàng)目計(jì)劃、項(xiàng)目過程文檔、源代碼、系統(tǒng)界面、測試計(jì)劃、測試用例和數(shù)據(jù)、用戶手冊
3）識別缺陷的階段
測試識別缺陷的階段：測試階段（編碼完成后）
評審識別缺陷的階段：需求階段、設(shè)計(jì)階段、編碼階段、測試階段
4）識別缺陷的成效
測試的成效：最多識別軟件所有缺陷中30-35%的缺陷
評審的成效：最多識別軟件所有缺陷中70-75%的缺陷
5）識別缺陷的成本
測試的成本：識別一個(gè)重要缺陷平均花費(fèi)15-25小時(shí)
評審的成本：需求階段識別一個(gè)重要缺陷平均花費(fèi)2-3小時(shí)；
設(shè)計(jì)階段識別一個(gè)重要缺陷平均花費(fèi)3-4小時(shí)；
代碼評審階段識別一個(gè)重要缺陷3-5小時(shí)；
測試計(jì)劃評審識別一個(gè)重要缺陷3-5小時(shí)
6）解決缺陷的成本
測試的成本：消除一個(gè)重要缺陷平均花費(fèi)30-80小時(shí)（包括識別缺陷時(shí)間）
在開發(fā)后期才能識別缺陷，成本較高
評審的成本：需求及設(shè)計(jì)階段消除一個(gè)重要缺陷5-10小時(shí)；
代碼評審階段消除一個(gè)重要缺陷5-15小時(shí)
更傾向于在開發(fā)前期識別缺陷，成本較低
7）投入回報(bào)比較
（1）航天飛機(jī)搭乘項(xiàng)目：在設(shè)計(jì)或代碼評審時(shí)消除一個(gè)缺陷的成本為1美元，在系統(tǒng)測試時(shí)為13美元，交付使用后為92美元（Paulk etal,1995）。即13~92 : 1
（2）電信公司審查發(fā)現(xiàn)和糾正一個(gè)缺陷的平均費(fèi)用為200美元，客戶驗(yàn)收測試發(fā)現(xiàn)的缺陷平均花費(fèi)4200美元(Boehm and Basili 2001)。即21 : 1
某研究表明，客戶使用過程中發(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、軟件評審概念
1.3.1 定義
軟件評審，是指在軟件開發(fā)過程中，由參與評審的人員對軟件開發(fā)文檔或代碼進(jìn)行評審或檢查，幫助查找缺陷和改進(jìn)。
軟件評審的工作包括：
1）檢驗(yàn)產(chǎn)品是否滿足以前的規(guī)范，如需求或設(shè)計(jì)文檔；
2）識別產(chǎn)品相對于標(biāo)準(zhǔn)的偏差；
3）向作者提出改進(jìn)建議；
4）促進(jìn)技術(shù)交流和學(xué)習(xí)。
軟件評審涉及評審的組織機(jī)構(gòu)、管理、準(zhǔn)則、類別、內(nèi)容、文件和要求等。一般要求在軟件研制階段的里程碑點(diǎn)進(jìn)行軟件評審。評審的主要類別有：軟件定義評審、軟件需求評審、概要設(shè)計(jì)評審、詳細(xì)設(shè)計(jì)評審、軟件實(shí)現(xiàn)評審和軟件驗(yàn)收評審等。
1.3.2 軟件評審的分類
自從25年前，IBM的Michael Fagan提出軟件審查技術(shù)以來，許多組織使用這項(xiàng)技術(shù)得到了非常卓有成效的結(jié)果。這些組織包括IBM、HP、Motorola、Raytheon、Bull HN等。經(jīng)過幾十年的發(fā)展，軟件評審技術(shù)和多種項(xiàng)目管理理論相結(jié)合，已經(jīng)發(fā)展成一個(gè)龐大的體系。
就總體而言，軟件評審主要分為六類：審查、小組評審、走查、結(jié)隊(duì)編程、同級桌查和輪查、臨時(shí)評審。
其中審查是最系統(tǒng)化、最嚴(yán)密的評審技術(shù)，嚴(yán)格規(guī)定了每個(gè)階段的角色及各自職責(zé)，在質(zhì)量要求非常高的軟件開發(fā)項(xiàng)目中得到了較廣泛的應(yī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）不易測試的異常處理代碼
7）打算復(fù)用的組件
8）將作為其他組件的模型或模板的組件
9）影響產(chǎn)品多個(gè)部分的組件
10）復(fù)雜的用戶界面
11）由缺乏經(jīng)驗(yàn)的開發(fā)者創(chuàng)建的組件
12）具有高度圈復(fù)雜性的代碼模塊
13）以往具有很多缺陷或變更的模塊
1.3.4 審查的角色、職責(zé)及步驟
審查的角色主要分為評審組長、作者、讀者、評審人員、記錄者和驗(yàn)證者。部分專家認(rèn)為審查的角色還有：評審協(xié)調(diào)人。根據(jù)管理的原則，評審協(xié)調(diào)人的角色應(yīng)歸入評審組長，其職責(zé)由評審組長負(fù)責(zé)。
審查的角色及職責(zé)
1）評審組長
（1）計(jì)劃、安排和組織評審活動(dòng)；
（2）和作者一起選擇評審人，并分配角色；
（3）主持總體會議和評審會議；
（4）提交需評審的產(chǎn)品給每一個(gè)評審人；
（5）檢查評審會議的準(zhǔn)備是否充分，從而決定是否召開評審會議；
（6）領(lǐng)導(dǎo)小組確定評審效果；
（7）提交《評審總結(jié)報(bào)告》；
（8）維護(hù)每次評審的評審記錄及來自評審總結(jié)報(bào)告中的數(shù)據(jù)；
（9）根據(jù)評審數(shù)據(jù)形成報(bào)告，提交給管理層、過程改進(jìn)組及評審過程的擁有者。
2）作者
（1）作為被評審產(chǎn)品的作者或維護(hù)者，提交工作產(chǎn)品；
（2）協(xié)助評審組長選擇評審人，并分配角色；
（3）陳述評審目標(biāo)；
（4）初步講解產(chǎn)品；
（5）返工；
（6）向評審組長報(bào)告返工時(shí)間和缺陷數(shù)；
3）讀者
將工作產(chǎn)品在評審會議上用自己的語言進(jìn)行解說，測試工作產(chǎn)品的可理解性，暴露產(chǎn)品的二義性、隱含假設(shè)等各種缺陷；
4）評審人員
（1）在評審會議之前檢查工作產(chǎn)品，發(fā)現(xiàn)其缺陷，為參加評審會議做準(zhǔn)備；
（2）記錄準(zhǔn)備時(shí)間；
（3）參加評審，識別缺陷，提出問題，給出改進(jìn)建議。
5）記錄者
記錄評審會議中提出的問題并分類。
6）驗(yàn)證者
進(jìn)行跟蹤，確認(rèn)返工工作被正確執(zhí)行。
審查的主要步驟有：
1）評審計(jì)劃；
2）總體會議；
3）評審準(zhǔn)備；
4）評審會議；
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)收測試、運(yùn)行維護(hù)到廢棄等階段。
組織軟件開發(fā)過程的規(guī)則，就可以稱為軟件生命周期模型。一個(gè)定義良好的軟件生命周期模型，可以很好的指導(dǎo)我們的開發(fā)工作，使漫長的開發(fā)工作易于控制。事實(shí)上，我們可以任意定義自己喜歡的軟件生命周期模型。但是，如果生命周期模型定義不合理，卻會制約我們的開發(fā)過程。軟件開發(fā)人員在長期開發(fā)過程已經(jīng)總結(jié)出了幾種常用的軟件生命周期模型，我們可以根據(jù)項(xiàng)目的特點(diǎn)來選擇一個(gè)合適的模型，然后在此基礎(chǔ)上再加以裁減。
這些生命周期模型是：
1）瀑布模型，
2）快速原型模型，
3）漸增模型，
4）演進(jìn)模型。
其中瀑布模型是所有生命周期模型的核心和基礎(chǔ)，其他模型都是基于瀑布模型發(fā)展和衍化而來。瀑布模型分為六個(gè)階段：系統(tǒng)定義、需求分析、系統(tǒng)設(shè)計(jì)、編碼實(shí)現(xiàn)、系統(tǒng)驗(yàn)收測試、運(yùn)行維護(hù)。
在瀑布模型中每個(gè)階段都要有定義、工作、審查、形成文檔以供交流或備查，以提高軟件的質(zhì)量。
2.2 項(xiàng)目開發(fā)V模型
在瀑布模型的基礎(chǔ)上，衍生出了強(qiáng)調(diào)測試活動(dòng)的V模型。它把瀑布模型的測試階段進(jìn)行細(xì)分，并于前面的階段進(jìn)行對應(yīng)。細(xì)分出來的這些階段分別為：單元測試階段、集成測試階段和系統(tǒng)測試階段。
在V模型中，我們可以知道：
1）在需求分析階段，《系統(tǒng)需求規(guī)格說明書》確認(rèn)后，編寫《系統(tǒng)測試計(jì)劃》，準(zhǔn)備系統(tǒng)測試用例、數(shù)據(jù)，對需求進(jìn)行驗(yàn)證；對應(yīng)的系統(tǒng)測試階段，執(zhí)行系統(tǒng)測試計(jì)劃；
2）在概要設(shè)計(jì)階段，《概要設(shè)計(jì)說明書》確認(rèn)后，編寫《集成測試計(jì)劃》，準(zhǔn)備集成測試用例、數(shù)據(jù)等，對概要設(shè)計(jì)進(jìn)行驗(yàn)證；然后在對應(yīng)的集成測試階段，執(zhí)行集成測試計(jì)劃；
3）在詳細(xì)設(shè)計(jì)階段，《詳細(xì)設(shè)計(jì)說明書》確認(rèn)后，編寫《單元測試計(jì)劃》，準(zhǔn)備單元測試用例、數(shù)據(jù)等，對詳細(xì)設(shè)計(jì)進(jìn)行驗(yàn)證，然后在對應(yīng)的單元測試階段，執(zhí)行單元測試計(jì)劃。
三、評審在高質(zhì)量軟件開發(fā)的實(shí)際應(yīng)用
3.1 高質(zhì)量軟件開發(fā)項(xiàng)目介紹
高質(zhì)量軟件，如電信軟件、金融證券類軟件等，有較嚴(yán)格的要求：可用性要求非常高，并且不會因?yàn)橄到y(tǒng)維護(hù)和擴(kuò)展而帶來運(yùn)營中斷；支持使用現(xiàn)有管理工具和標(biāo)準(zhǔn)進(jìn)行遠(yuǎn)程管理；能夠提供更出色的性能以及運(yùn)營在高可用性集群上的能力，減少任何單點(diǎn)的軟硬件失效現(xiàn)象。五個(gè)九（99.999%）意味著一個(gè)系統(tǒng)的宕機(jī)時(shí)間一年不超過5分26秒。因此高質(zhì)量軟件項(xiàng)目是一種對可用性、可靠性、穩(wěn)定性要求非常高的軟件項(xiàng)目，要求軟件能夠每周7*24工作。
因此高質(zhì)量軟件開發(fā)一般采用嚴(yán)格的軟件開發(fā)過程，明確定義每個(gè)階段的質(zhì)量目標(biāo)和要求，嚴(yán)格項(xiàng)目軟件開發(fā)過程控制。
我們在多個(gè)高質(zhì)量軟件開發(fā)項(xiàng)目中成功地采用了評審技術(shù)，并發(fā)揮了巨大的作用。從這些項(xiàng)目的實(shí)際開發(fā)過程中，我們針對于規(guī)模從30人月——300人月，代碼行數(shù)從5萬行——30萬行的運(yùn)營支撐系統(tǒng)項(xiàng)目制定了項(xiàng)目評審流程和相關(guān)要求。
3.2 軟件過程定義
軟件過程主要分為項(xiàng)目立項(xiàng)階段、需求分析階段、設(shè)計(jì)階段、編碼實(shí)現(xiàn)階段、測試階段（包括集成測試、系統(tǒng)測試和用戶驗(yàn)收測試）、實(shí)施階段和維護(hù)階段，項(xiàng)目管理工作橫貫于所有的階段。詳細(xì)流程見流程圖。
在軟件過程中，我們定義了以下角色：
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對項(xiàng)目質(zhì)量管理的要求，將項(xiàng)目質(zhì)量管理過程設(shè)計(jì)為三個(gè)階段：
1）質(zhì)量規(guī)劃——確定質(zhì)量活動(dòng)的流程和標(biāo)準(zhǔn)，如軟件過程定義，質(zhì)量達(dá)標(biāo)定義等；
2）實(shí)施質(zhì)量保證——編寫相應(yīng)的測試計(jì)劃、執(zhí)行測試和評審活動(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)收測試階段流程（圖略）
實(shí)施維護(hù)階段流程（圖略）
3.3 軟件評審過程及標(biāo)準(zhǔn)定義
我們在整體軟件過程中明確定義了需要軟件評審的過程及實(shí)施的方法。
（圖略）
3.3.1 采用審查的過程
采用最嚴(yán)格最系統(tǒng)的評審方法——審查的軟件過程有：
1）《軟件需求規(guī)格說明書》的評審
2）《概要設(shè)計(jì)說明書》的評審
3）《詳細(xì)設(shè)計(jì)說明書》的評審
4）代碼評審
5）《單元測試計(jì)劃》的評審
6）《集成測試計(jì)劃》的評審
7）《系統(tǒng)測試計(jì)劃》的評審
對于文檔評審以文檔頁數(shù)為基數(shù)，要求每頁發(fā)現(xiàn)的缺陷數(shù)有一個(gè)目標(biāo)值，并規(guī)定了上下限的范圍。對于代碼評審以代碼行數(shù)為基數(shù)，要求每千行代碼發(fā)現(xiàn)的缺陷數(shù)有一個(gè)目標(biāo)值，并規(guī)定了上下限的范圍。這個(gè)審查的缺陷數(shù)標(biāo)準(zhǔn)如下表。
軟件過程審查的質(zhì)量目標(biāo)
質(zhì)量目標(biāo) 目標(biāo) 下限 上限
SRS文檔Review缺陷發(fā)現(xiàn)密度（個(gè)/頁）： 0.80 0.50 1.10
HLD文檔Review缺陷發(fā)現(xiàn)密度（個(gè)/頁）： 0.70 0.50 0.90
LLD文檔Review缺陷發(fā)現(xiàn)密度（個(gè)/頁）： 0.43 0.22 0.64
代碼檢視缺陷發(fā)現(xiàn)密度（個(gè)/KLOC）： 10.62 7.43 13.81
單元測試計(jì)劃Review缺陷發(fā)現(xiàn)密度（個(gè)/頁）： 0.43 0.22 0.64
集成測試計(jì)劃Review缺陷發(fā)現(xiàn)密度（個(gè)/頁）： 0.70 0.50 0.90
系統(tǒng)測試計(jì)劃Review缺陷發(fā)現(xiàn)密度（個(gè)/頁）： 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)的缺陷密度也很低，但原因是屬于檢視的過程不嚴(yán)格，大家沒有時(shí)間來進(jìn)行嚴(yán)格的評審，則此時(shí)需要重新進(jìn)行檢視。
3.3.2 采用小組評審的過程
采用小組評審的軟件過程主要包括對客戶需求的評審、項(xiàng)目計(jì)劃的評審和維護(hù)計(jì)劃的評審。
對客戶需求的評審參加人員有項(xiàng)目經(jīng)理、系統(tǒng)分析員、系統(tǒng)架構(gòu)師、質(zhì)量部主管等。
項(xiàng)目計(jì)劃的評審主要由項(xiàng)目經(jīng)理、系統(tǒng)分析員、系統(tǒng)架構(gòu)師、質(zhì)量部主管和部門經(jīng)理等參加，對人力資源、進(jìn)度和質(zhì)量管控等進(jìn)行評審。
維護(hù)計(jì)劃由項(xiàng)目經(jīng)理、技術(shù)支持人員、質(zhì)量部主管和客戶服務(wù)人員參加，對人力資源、管控流程等進(jìn)行評審。
3.3.3 采用走查評審的過程
需求分析過程中，系統(tǒng)分析員、系統(tǒng)架構(gòu)師相互之間的走查；
設(shè)計(jì)過程中，系統(tǒng)分析員、系統(tǒng)架構(gòu)師相互之間的走查；
在進(jìn)入維護(hù)階段時(shí)，作者需和維護(hù)人員進(jìn)行走查，讓維護(hù)人員能夠維護(hù)作者的工作產(chǎn)品。
3.3.4 采用桌查的過程
采用桌查的過程主要集中在代碼提交階段，主要是經(jīng)驗(yàn)豐富的開發(fā)人員對提交的代碼進(jìn)行檢查，合格的產(chǎn)品才會提交到CVS上面。
具體實(shí)施方法為：開發(fā)經(jīng)驗(yàn)較少（8年以下開發(fā)經(jīng)驗(yàn)）的開發(fā)人員在提交代碼時(shí)，請經(jīng)驗(yàn)豐富（10年以上開發(fā)經(jīng)驗(yàn)）的開發(fā)人員進(jìn)行桌查，沒有明顯問題后才允許提交；經(jīng)驗(yàn)豐富的開發(fā)人員提交代碼時(shí)也需另一名經(jīng)驗(yàn)豐富的開發(fā)人員桌查后方可提交。
3.3.5 采用臨時(shí)評審的過程
代碼編寫階段開發(fā)工程師之間的臨時(shí)評審；
其他開發(fā)階段，開發(fā)人員相互之間的臨時(shí)評審。
3.3.6 采用結(jié)隊(duì)編程的過程
針對于需求不明確、采用迭代增量開發(fā)過程的小規(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í)文檔編寫比較簡單。
3.4 審查流程定義
我們規(guī)定了審查流程的定義，其他評審技術(shù)只是采用了其中的流程和管理思想。
審查流程（圖略）
3.5 軟件評審效果分析
我們強(qiáng)化了軟件評審技術(shù)后，在實(shí)際過程中取得了非常好的效果。以一個(gè)網(wǎng)絡(luò)流量分析的項(xiàng)目為實(shí)例，在第一期沒有嚴(yán)格實(shí)施軟件評審技術(shù)，而第二期嚴(yán)格實(shí)施了軟件評審技術(shù)，其中審查數(shù)據(jù)如下表。
評審過程數(shù)據(jù)及質(zhì)量分析實(shí)例
文件/模塊 計(jì)算基數(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)鍵原因在于大在減少了項(xiàng)目后期返工的工作量?？紤]由于項(xiàng)目熟悉和學(xué)習(xí)曲線等的原因，實(shí)際的產(chǎn)出增長量應(yīng)該超過20%。
2）產(chǎn)品質(zhì)量（遺留缺陷密度）：我們從軟件系統(tǒng)的遺留缺陷率來分析系統(tǒng)的質(zhì)量情況。在半年的維護(hù)時(shí)間內(nèi)，第一期代碼行為4萬行，嚴(yán)重缺陷有5個(gè)，一般缺陷有32個(gè)，嚴(yán)重缺陷發(fā)現(xiàn)密度為0.125個(gè)缺陷/千行代碼，總遺留缺陷發(fā)現(xiàn)密度為0.925個(gè)缺陷/千行代碼；第二期代碼行數(shù)為5萬行，嚴(yán)重缺陷有1個(gè)（屬于客戶需求問題引發(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)重不滿意，稱我們在做玩具，滿意度只有22%；第二期客戶滿意度大幅上升，稱我們是專業(yè)人士，非常敬業(yè)，為他們所欽佩，滿意度達(dá)到了91%。因此滿意度提高了314%。
最主要的是，我們采用了軟件評審技術(shù)，規(guī)范了軟件開發(fā)過程的標(biāo)準(zhǔn)，并積累了實(shí)際的軟件開發(fā)過程數(shù)據(jù)，為后面的項(xiàng)目管理和過程控制提供了寶貴的軟件過程財(cái)富。
四、總結(jié)和展望
在實(shí)際工作中，我們以前掌握的過程數(shù)據(jù)不多，基本上一步一步摸索著前進(jìn)，對于過程數(shù)據(jù)也在不斷的收集及整理中。對于評審技術(shù)而言，其中最重要的一點(diǎn)是采用多種實(shí)際工具和手段，如針對每個(gè)過程進(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àng)目管理知識體系指南（第三版）. 美國項(xiàng)目管理協(xié)會. 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í)行過程. Pearson Education. CMM in Practice: Processes for Executing Software Projects at Infosys. 電子工業(yè)出版社. 2002.8.1
郭華
摘要
軟件質(zhì)量和開發(fā)進(jìn)度一直是軟件開發(fā)成功關(guān)鍵的因素，而在實(shí)際工作中只有少量項(xiàng)目能按計(jì)劃完成，進(jìn)度要求往往迫使開發(fā)組無法保證軟件質(zhì)量，最終許多項(xiàng)目因?yàn)橘|(zhì)量問題無法投入使用。軟件評審作為一種軟件產(chǎn)品驗(yàn)證的活動(dòng)，能夠及早地從軟件產(chǎn)品中識別并消除缺陷，從而減少后期的返工，加快開發(fā)進(jìn)度，提高產(chǎn)品質(zhì)量。作為一種十分有效值得推廣的評審方法，在軟件過程改進(jìn)中起到了非常大的作用，同時(shí)軟件評審也是CMM等級3的關(guān)鍵過程域。
本文描述了正式和非正式的多種軟件評審技術(shù)，包括臨時(shí)評審、桌查、輪查、結(jié)隊(duì)編程、走查、小組評審和審查等，并系統(tǒng)地介紹了最正式、最嚴(yán)格、最有效的軟件評審——審查的整個(gè)過程，包括制定評審計(jì)劃、指定評審角色、做評審準(zhǔn)備、召開評審會議和驗(yàn)證分析等過程。高質(zhì)量要求的軟件，如電信軟件、銀行證券軟件等，它們對可用性要求非常，因此對軟件質(zhì)量的要求非常嚴(yán)格。作者通過將評審技術(shù)應(yīng)用在高質(zhì)量軟件開發(fā)過程中，在實(shí)際開發(fā)過程中確定了評審的質(zhì)量標(biāo)準(zhǔn)和準(zhǔn)入、準(zhǔn)出條件，并針對數(shù)據(jù)采集、分析做了嚴(yán)格的控管，建立了質(zhì)量可預(yù)測的軟件開發(fā)過程體系，為有效地項(xiàng)目評估、質(zhì)量保證和項(xiàng)目管理提供了可靠依據(jù)，從而保證了軟件項(xiàng)目的成功。
關(guān)鍵詞：軟件評審、審查、開發(fā)過程、軟件、質(zhì)量、定量
一、軟件評審
1.1 缺陷的產(chǎn)生
缺陷指軟件工作產(chǎn)品中的一種情況，它將導(dǎo)致軟件產(chǎn)生不令人滿意或非預(yù)期的結(jié)果。在開發(fā)過程中缺陷隨時(shí)可能產(chǎn)生，問題在于什么時(shí)候發(fā)現(xiàn)它，并為此產(chǎn)生多少糾正成本。。根據(jù)一些企業(yè)返工度量的報(bào)導(dǎo)，缺陷返工率可達(dá)到整個(gè)開發(fā)工作量的40%~60%。
缺陷在軟件開發(fā)的任何階段都可能會被引入。項(xiàng)目質(zhì)量管理過程包含了許多可以識別缺陷、消除缺陷的過程?！白R別缺陷”和“消除缺陷”本來是兩個(gè)不同的過程，但在這里為了簡便統(tǒng)一用“消除”來代表它們。潛在的缺陷越大，用來消除它所花的費(fèi)用越高。因此成熟的軟件開發(fā)過程在每一個(gè)可能會引入潛在缺陷的階段完成之后都會開展質(zhì)量控制活動(dòng)。這些為了消除缺陷的活動(dòng)包括：需求評審、設(shè)計(jì)評審、代碼走查、單元測試、集成測試、系統(tǒng)測試以及驗(yàn)收測試等。一個(gè)缺陷如果保持沒有被發(fā)現(xiàn)的時(shí)間越長，則以后糾正此缺陷的花費(fèi)越大。
缺陷越早發(fā)現(xiàn)、越早解決，則所花費(fèi)的成本越低。因此我們應(yīng)該盡量在前期發(fā)現(xiàn)、識別并解決缺陷問題。
2、缺陷的識別
根據(jù)一些企業(yè)返工度量的報(bào)導(dǎo)，缺陷返工率可達(dá)到整個(gè)開發(fā)工作量的40%~60%。在軟件開發(fā)過程中，軟件評審和軟件測試是保證軟件質(zhì)量的兩種主要手段和方法。
測試可以識別可執(zhí)行系統(tǒng)中的缺陷，而評審不僅可識別可執(zhí)行系統(tǒng)中的缺陷，且能識別不能被執(zhí)行的文檔或人為產(chǎn)物。
測試和評審的比較
1）表現(xiàn)形式
測試的表現(xiàn)形式有：單元測試、集成測試、系統(tǒng)測試、用戶驗(yàn)收測試
評審的表現(xiàn)形式有：審查、小組評審、走查、結(jié)對編程、同級桌查、輪查、臨時(shí)評審
2）工作對象
測試的工作對象為：可執(zhí)行系統(tǒng)（指編譯后可運(yùn)行的程序）
評審的工作對象為：需求規(guī)格說明書、架構(gòu)（概要）設(shè)計(jì)文檔、詳細(xì)設(shè)計(jì)文檔、項(xiàng)目計(jì)劃、項(xiàng)目過程文檔、源代碼、系統(tǒng)界面、測試計(jì)劃、測試用例和數(shù)據(jù)、用戶手冊
3）識別缺陷的階段
測試識別缺陷的階段：測試階段（編碼完成后）
評審識別缺陷的階段：需求階段、設(shè)計(jì)階段、編碼階段、測試階段
4）識別缺陷的成效
測試的成效：最多識別軟件所有缺陷中30-35%的缺陷
評審的成效：最多識別軟件所有缺陷中70-75%的缺陷
5）識別缺陷的成本
測試的成本：識別一個(gè)重要缺陷平均花費(fèi)15-25小時(shí)
評審的成本：需求階段識別一個(gè)重要缺陷平均花費(fèi)2-3小時(shí)；
設(shè)計(jì)階段識別一個(gè)重要缺陷平均花費(fèi)3-4小時(shí)；
代碼評審階段識別一個(gè)重要缺陷3-5小時(shí)；
測試計(jì)劃評審識別一個(gè)重要缺陷3-5小時(shí)
6）解決缺陷的成本
測試的成本：消除一個(gè)重要缺陷平均花費(fèi)30-80小時(shí)（包括識別缺陷時(shí)間）
在開發(fā)后期才能識別缺陷，成本較高
評審的成本：需求及設(shè)計(jì)階段消除一個(gè)重要缺陷5-10小時(shí)；
代碼評審階段消除一個(gè)重要缺陷5-15小時(shí)
更傾向于在開發(fā)前期識別缺陷，成本較低
7）投入回報(bào)比較
（1）航天飛機(jī)搭乘項(xiàng)目：在設(shè)計(jì)或代碼評審時(shí)消除一個(gè)缺陷的成本為1美元，在系統(tǒng)測試時(shí)為13美元，交付使用后為92美元（Paulk etal,1995）。即13~92 : 1
（2）電信公司審查發(fā)現(xiàn)和糾正一個(gè)缺陷的平均費(fèi)用為200美元，客戶驗(yàn)收測試發(fā)現(xiàn)的缺陷平均花費(fèi)4200美元(Boehm and Basili 2001)。即21 : 1
某研究表明，客戶使用過程中發(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、軟件評審概念
1.3.1 定義
軟件評審，是指在軟件開發(fā)過程中，由參與評審的人員對軟件開發(fā)文檔或代碼進(jìn)行評審或檢查，幫助查找缺陷和改進(jìn)。
軟件評審的工作包括：
1）檢驗(yàn)產(chǎn)品是否滿足以前的規(guī)范，如需求或設(shè)計(jì)文檔；
2）識別產(chǎn)品相對于標(biāo)準(zhǔn)的偏差；
3）向作者提出改進(jìn)建議；
4）促進(jìn)技術(shù)交流和學(xué)習(xí)。
軟件評審涉及評審的組織機(jī)構(gòu)、管理、準(zhǔn)則、類別、內(nèi)容、文件和要求等。一般要求在軟件研制階段的里程碑點(diǎn)進(jìn)行軟件評審。評審的主要類別有：軟件定義評審、軟件需求評審、概要設(shè)計(jì)評審、詳細(xì)設(shè)計(jì)評審、軟件實(shí)現(xiàn)評審和軟件驗(yàn)收評審等。
1.3.2 軟件評審的分類
自從25年前，IBM的Michael Fagan提出軟件審查技術(shù)以來，許多組織使用這項(xiàng)技術(shù)得到了非常卓有成效的結(jié)果。這些組織包括IBM、HP、Motorola、Raytheon、Bull HN等。經(jīng)過幾十年的發(fā)展，軟件評審技術(shù)和多種項(xiàng)目管理理論相結(jié)合，已經(jīng)發(fā)展成一個(gè)龐大的體系。
就總體而言，軟件評審主要分為六類：審查、小組評審、走查、結(jié)隊(duì)編程、同級桌查和輪查、臨時(shí)評審。
其中審查是最系統(tǒng)化、最嚴(yán)密的評審技術(shù)，嚴(yán)格規(guī)定了每個(gè)階段的角色及各自職責(zé)，在質(zhì)量要求非常高的軟件開發(fā)項(xiàng)目中得到了較廣泛的應(yī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）不易測試的異常處理代碼
7）打算復(fù)用的組件
8）將作為其他組件的模型或模板的組件
9）影響產(chǎn)品多個(gè)部分的組件
10）復(fù)雜的用戶界面
11）由缺乏經(jīng)驗(yàn)的開發(fā)者創(chuàng)建的組件
12）具有高度圈復(fù)雜性的代碼模塊
13）以往具有很多缺陷或變更的模塊
1.3.4 審查的角色、職責(zé)及步驟
審查的角色主要分為評審組長、作者、讀者、評審人員、記錄者和驗(yàn)證者。部分專家認(rèn)為審查的角色還有：評審協(xié)調(diào)人。根據(jù)管理的原則，評審協(xié)調(diào)人的角色應(yīng)歸入評審組長，其職責(zé)由評審組長負(fù)責(zé)。
審查的角色及職責(zé)
1）評審組長
（1）計(jì)劃、安排和組織評審活動(dòng)；
（2）和作者一起選擇評審人，并分配角色；
（3）主持總體會議和評審會議；
（4）提交需評審的產(chǎn)品給每一個(gè)評審人；
（5）檢查評審會議的準(zhǔn)備是否充分，從而決定是否召開評審會議；
（6）領(lǐng)導(dǎo)小組確定評審效果；
（7）提交《評審總結(jié)報(bào)告》；
（8）維護(hù)每次評審的評審記錄及來自評審總結(jié)報(bào)告中的數(shù)據(jù)；
（9）根據(jù)評審數(shù)據(jù)形成報(bào)告，提交給管理層、過程改進(jìn)組及評審過程的擁有者。
2）作者
（1）作為被評審產(chǎn)品的作者或維護(hù)者，提交工作產(chǎn)品；
（2）協(xié)助評審組長選擇評審人，并分配角色；
（3）陳述評審目標(biāo)；
（4）初步講解產(chǎn)品；
（5）返工；
（6）向評審組長報(bào)告返工時(shí)間和缺陷數(shù)；
3）讀者
將工作產(chǎn)品在評審會議上用自己的語言進(jìn)行解說，測試工作產(chǎn)品的可理解性，暴露產(chǎn)品的二義性、隱含假設(shè)等各種缺陷；
4）評審人員
（1）在評審會議之前檢查工作產(chǎn)品，發(fā)現(xiàn)其缺陷，為參加評審會議做準(zhǔn)備；
（2）記錄準(zhǔn)備時(shí)間；
（3）參加評審，識別缺陷，提出問題，給出改進(jìn)建議。
5）記錄者
記錄評審會議中提出的問題并分類。
6）驗(yàn)證者
進(jìn)行跟蹤，確認(rèn)返工工作被正確執(zhí)行。
審查的主要步驟有：
1）評審計(jì)劃；
2）總體會議；
3）評審準(zhǔn)備；
4）評審會議；
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)收測試、運(yùn)行維護(hù)到廢棄等階段。
組織軟件開發(fā)過程的規(guī)則，就可以稱為軟件生命周期模型。一個(gè)定義良好的軟件生命周期模型，可以很好的指導(dǎo)我們的開發(fā)工作，使漫長的開發(fā)工作易于控制。事實(shí)上，我們可以任意定義自己喜歡的軟件生命周期模型。但是，如果生命周期模型定義不合理，卻會制約我們的開發(fā)過程。軟件開發(fā)人員在長期開發(fā)過程已經(jīng)總結(jié)出了幾種常用的軟件生命周期模型，我們可以根據(jù)項(xiàng)目的特點(diǎn)來選擇一個(gè)合適的模型，然后在此基礎(chǔ)上再加以裁減。
這些生命周期模型是：
1）瀑布模型，
2）快速原型模型，
3）漸增模型，
4）演進(jìn)模型。
其中瀑布模型是所有生命周期模型的核心和基礎(chǔ)，其他模型都是基于瀑布模型發(fā)展和衍化而來。瀑布模型分為六個(gè)階段：系統(tǒng)定義、需求分析、系統(tǒng)設(shè)計(jì)、編碼實(shí)現(xiàn)、系統(tǒng)驗(yàn)收測試、運(yùn)行維護(hù)。
在瀑布模型中每個(gè)階段都要有定義、工作、審查、形成文檔以供交流或備查，以提高軟件的質(zhì)量。
2.2 項(xiàng)目開發(fā)V模型
在瀑布模型的基礎(chǔ)上，衍生出了強(qiáng)調(diào)測試活動(dòng)的V模型。它把瀑布模型的測試階段進(jìn)行細(xì)分，并于前面的階段進(jìn)行對應(yīng)。細(xì)分出來的這些階段分別為：單元測試階段、集成測試階段和系統(tǒng)測試階段。
在V模型中，我們可以知道：
1）在需求分析階段，《系統(tǒng)需求規(guī)格說明書》確認(rèn)后，編寫《系統(tǒng)測試計(jì)劃》，準(zhǔn)備系統(tǒng)測試用例、數(shù)據(jù)，對需求進(jìn)行驗(yàn)證；對應(yīng)的系統(tǒng)測試階段，執(zhí)行系統(tǒng)測試計(jì)劃；
2）在概要設(shè)計(jì)階段，《概要設(shè)計(jì)說明書》確認(rèn)后，編寫《集成測試計(jì)劃》，準(zhǔn)備集成測試用例、數(shù)據(jù)等，對概要設(shè)計(jì)進(jìn)行驗(yàn)證；然后在對應(yīng)的集成測試階段，執(zhí)行集成測試計(jì)劃；
3）在詳細(xì)設(shè)計(jì)階段，《詳細(xì)設(shè)計(jì)說明書》確認(rèn)后，編寫《單元測試計(jì)劃》，準(zhǔn)備單元測試用例、數(shù)據(jù)等，對詳細(xì)設(shè)計(jì)進(jìn)行驗(yàn)證，然后在對應(yīng)的單元測試階段，執(zhí)行單元測試計(jì)劃。
三、評審在高質(zhì)量軟件開發(fā)的實(shí)際應(yīng)用
3.1 高質(zhì)量軟件開發(fā)項(xiàng)目介紹
高質(zhì)量軟件，如電信軟件、金融證券類軟件等，有較嚴(yán)格的要求：可用性要求非常高，并且不會因?yàn)橄到y(tǒng)維護(hù)和擴(kuò)展而帶來運(yùn)營中斷；支持使用現(xiàn)有管理工具和標(biāo)準(zhǔn)進(jìn)行遠(yuǎn)程管理；能夠提供更出色的性能以及運(yùn)營在高可用性集群上的能力，減少任何單點(diǎn)的軟硬件失效現(xiàn)象。五個(gè)九（99.999%）意味著一個(gè)系統(tǒng)的宕機(jī)時(shí)間一年不超過5分26秒。因此高質(zhì)量軟件項(xiàng)目是一種對可用性、可靠性、穩(wěn)定性要求非常高的軟件項(xiàng)目，要求軟件能夠每周7*24工作。
因此高質(zhì)量軟件開發(fā)一般采用嚴(yán)格的軟件開發(fā)過程，明確定義每個(gè)階段的質(zhì)量目標(biāo)和要求，嚴(yán)格項(xiàng)目軟件開發(fā)過程控制。
我們在多個(gè)高質(zhì)量軟件開發(fā)項(xiàng)目中成功地采用了評審技術(shù)，并發(fā)揮了巨大的作用。從這些項(xiàng)目的實(shí)際開發(fā)過程中，我們針對于規(guī)模從30人月——300人月，代碼行數(shù)從5萬行——30萬行的運(yùn)營支撐系統(tǒng)項(xiàng)目制定了項(xiàng)目評審流程和相關(guān)要求。
3.2 軟件過程定義
軟件過程主要分為項(xiàng)目立項(xiàng)階段、需求分析階段、設(shè)計(jì)階段、編碼實(shí)現(xiàn)階段、測試階段（包括集成測試、系統(tǒng)測試和用戶驗(yàn)收測試）、實(shí)施階段和維護(hù)階段，項(xiàng)目管理工作橫貫于所有的階段。詳細(xì)流程見流程圖。
在軟件過程中，我們定義了以下角色：
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對項(xiàng)目質(zhì)量管理的要求，將項(xiàng)目質(zhì)量管理過程設(shè)計(jì)為三個(gè)階段：
1）質(zhì)量規(guī)劃——確定質(zhì)量活動(dòng)的流程和標(biāo)準(zhǔn)，如軟件過程定義，質(zhì)量達(dá)標(biāo)定義等；
2）實(shí)施質(zhì)量保證——編寫相應(yīng)的測試計(jì)劃、執(zhí)行測試和評審活動(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)收測試階段流程（圖略）
實(shí)施維護(hù)階段流程（圖略）
3.3 軟件評審過程及標(biāo)準(zhǔn)定義
我們在整體軟件過程中明確定義了需要軟件評審的過程及實(shí)施的方法。
（圖略）
3.3.1 采用審查的過程
采用最嚴(yán)格最系統(tǒng)的評審方法——審查的軟件過程有：
1）《軟件需求規(guī)格說明書》的評審
2）《概要設(shè)計(jì)說明書》的評審
3）《詳細(xì)設(shè)計(jì)說明書》的評審
4）代碼評審
5）《單元測試計(jì)劃》的評審
6）《集成測試計(jì)劃》的評審
7）《系統(tǒng)測試計(jì)劃》的評審
對于文檔評審以文檔頁數(shù)為基數(shù)，要求每頁發(fā)現(xiàn)的缺陷數(shù)有一個(gè)目標(biāo)值，并規(guī)定了上下限的范圍。對于代碼評審以代碼行數(shù)為基數(shù)，要求每千行代碼發(fā)現(xiàn)的缺陷數(shù)有一個(gè)目標(biāo)值，并規(guī)定了上下限的范圍。這個(gè)審查的缺陷數(shù)標(biāo)準(zhǔn)如下表。
軟件過程審查的質(zhì)量目標(biāo)
質(zhì)量目標(biāo) 目標(biāo) 下限 上限
SRS文檔Review缺陷發(fā)現(xiàn)密度（個(gè)/頁）： 0.80 0.50 1.10
HLD文檔Review缺陷發(fā)現(xiàn)密度（個(gè)/頁）： 0.70 0.50 0.90
LLD文檔Review缺陷發(fā)現(xiàn)密度（個(gè)/頁）： 0.43 0.22 0.64
代碼檢視缺陷發(fā)現(xiàn)密度（個(gè)/KLOC）： 10.62 7.43 13.81
單元測試計(jì)劃Review缺陷發(fā)現(xiàn)密度（個(gè)/頁）： 0.43 0.22 0.64
集成測試計(jì)劃Review缺陷發(fā)現(xiàn)密度（個(gè)/頁）： 0.70 0.50 0.90
系統(tǒng)測試計(jì)劃Review缺陷發(fā)現(xiàn)密度（個(gè)/頁）： 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)的缺陷密度也很低，但原因是屬于檢視的過程不嚴(yán)格，大家沒有時(shí)間來進(jìn)行嚴(yán)格的評審，則此時(shí)需要重新進(jìn)行檢視。
3.3.2 采用小組評審的過程
采用小組評審的軟件過程主要包括對客戶需求的評審、項(xiàng)目計(jì)劃的評審和維護(hù)計(jì)劃的評審。
對客戶需求的評審參加人員有項(xiàng)目經(jīng)理、系統(tǒng)分析員、系統(tǒng)架構(gòu)師、質(zhì)量部主管等。
項(xiàng)目計(jì)劃的評審主要由項(xiàng)目經(jīng)理、系統(tǒng)分析員、系統(tǒng)架構(gòu)師、質(zhì)量部主管和部門經(jīng)理等參加，對人力資源、進(jìn)度和質(zhì)量管控等進(jìn)行評審。
維護(hù)計(jì)劃由項(xiàng)目經(jīng)理、技術(shù)支持人員、質(zhì)量部主管和客戶服務(wù)人員參加，對人力資源、管控流程等進(jìn)行評審。
3.3.3 采用走查評審的過程
需求分析過程中，系統(tǒng)分析員、系統(tǒng)架構(gòu)師相互之間的走查；
設(shè)計(jì)過程中，系統(tǒng)分析員、系統(tǒng)架構(gòu)師相互之間的走查；
在進(jìn)入維護(hù)階段時(shí)，作者需和維護(hù)人員進(jìn)行走查，讓維護(hù)人員能夠維護(hù)作者的工作產(chǎn)品。
3.3.4 采用桌查的過程
采用桌查的過程主要集中在代碼提交階段，主要是經(jīng)驗(yàn)豐富的開發(fā)人員對提交的代碼進(jìn)行檢查，合格的產(chǎn)品才會提交到CVS上面。
具體實(shí)施方法為：開發(fā)經(jīng)驗(yàn)較少（8年以下開發(fā)經(jīng)驗(yàn)）的開發(fā)人員在提交代碼時(shí)，請經(jīng)驗(yàn)豐富（10年以上開發(fā)經(jīng)驗(yàn)）的開發(fā)人員進(jìn)行桌查，沒有明顯問題后才允許提交；經(jīng)驗(yàn)豐富的開發(fā)人員提交代碼時(shí)也需另一名經(jīng)驗(yàn)豐富的開發(fā)人員桌查后方可提交。
3.3.5 采用臨時(shí)評審的過程
代碼編寫階段開發(fā)工程師之間的臨時(shí)評審；
其他開發(fā)階段，開發(fā)人員相互之間的臨時(shí)評審。
3.3.6 采用結(jié)隊(duì)編程的過程
針對于需求不明確、采用迭代增量開發(fā)過程的小規(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í)文檔編寫比較簡單。
3.4 審查流程定義
我們規(guī)定了審查流程的定義，其他評審技術(shù)只是采用了其中的流程和管理思想。
審查流程（圖略）
3.5 軟件評審效果分析
我們強(qiáng)化了軟件評審技術(shù)后，在實(shí)際過程中取得了非常好的效果。以一個(gè)網(wǎng)絡(luò)流量分析的項(xiàng)目為實(shí)例，在第一期沒有嚴(yán)格實(shí)施軟件評審技術(shù)，而第二期嚴(yán)格實(shí)施了軟件評審技術(shù)，其中審查數(shù)據(jù)如下表。
評審過程數(shù)據(jù)及質(zhì)量分析實(shí)例
文件/模塊 計(jì)算基數(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)鍵原因在于大在減少了項(xiàng)目后期返工的工作量?？紤]由于項(xiàng)目熟悉和學(xué)習(xí)曲線等的原因，實(shí)際的產(chǎn)出增長量應(yīng)該超過20%。
2）產(chǎn)品質(zhì)量（遺留缺陷密度）：我們從軟件系統(tǒng)的遺留缺陷率來分析系統(tǒng)的質(zhì)量情況。在半年的維護(hù)時(shí)間內(nèi)，第一期代碼行為4萬行，嚴(yán)重缺陷有5個(gè)，一般缺陷有32個(gè)，嚴(yán)重缺陷發(fā)現(xiàn)密度為0.125個(gè)缺陷/千行代碼，總遺留缺陷發(fā)現(xiàn)密度為0.925個(gè)缺陷/千行代碼；第二期代碼行數(shù)為5萬行，嚴(yán)重缺陷有1個(gè)（屬于客戶需求問題引發(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)重不滿意，稱我們在做玩具，滿意度只有22%；第二期客戶滿意度大幅上升，稱我們是專業(yè)人士，非常敬業(yè)，為他們所欽佩，滿意度達(dá)到了91%。因此滿意度提高了314%。
最主要的是，我們采用了軟件評審技術(shù)，規(guī)范了軟件開發(fā)過程的標(biāo)準(zhǔn)，并積累了實(shí)際的軟件開發(fā)過程數(shù)據(jù)，為后面的項(xiàng)目管理和過程控制提供了寶貴的軟件過程財(cái)富。
四、總結(jié)和展望
在實(shí)際工作中，我們以前掌握的過程數(shù)據(jù)不多，基本上一步一步摸索著前進(jìn)，對于過程數(shù)據(jù)也在不斷的收集及整理中。對于評審技術(shù)而言，其中最重要的一點(diǎn)是采用多種實(shí)際工具和手段，如針對每個(gè)過程進(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àng)目管理知識體系指南（第三版）. 美國項(xiàng)目管理協(xié)會. 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í)行過程. Pearson Education. CMM in Practice: Processes for Executing Software Projects at Infosys. 電子工業(yè)出版社. 2002.8.1