接評審技術在高質量軟件開發中的應用分析（上）
三、評審在高質量軟件開發的實際應用
3.1 高質量軟件開發項目介紹
高質量軟件，如電信軟件、金融證券類軟件等，有較嚴格的要求：可用性要求非常高，并且不會因為系統維護和擴展而帶來運營中斷；支持使用現有管理工具和標準進行遠程管理；能夠提供更出色的性能以及運營在高可用性集群上的能力，減少任何單點的軟硬件失效現象。五個九（99.999%）意味著一個系統的宕機時間一年不超過5分26秒。因此高質量軟件項目是一種對可用性、可靠性、穩定性要求非常高的軟件項目，要求軟件能夠每周7*24工作。
因此高質量軟件開發一般采用嚴格的軟件開發過程，明確定義每個階段的質量目標和要求，嚴格項目軟件開發過程控制。
我們在多個高質量軟件開發項目中成功地采用了評審技術，并發揮了巨大的作用。從這些項目的實際開發過程中，我們針對于規模從30人月——300人月，代碼行數從5萬行——30萬行的運營支撐系統項目制定了項目評審流程和相關要求。
3.2 軟件過程定義
軟件過程主要分為項目立項階段、需求分析階段、設計階段、編碼實現階段、測試階段（包括集成測試、系統測試和用戶驗收測試）、實施階段和維護階段，項目管理工作橫貫于所有的階段。詳細流程見流程圖。
在軟件過程中，我們定義了以下角色：
1）客戶
2）銷售人員
3）項目經理
4）系統分析員
5）系統架構師
6）開發工程師
7）質量工程師
8）技術支持人員
在規劃質量體系時，我們參考PMBOK對項目質量管理的要求，將項目質量管理過程設計為三個階段：
1）質量規劃——確定質量活動的流程和標準，如軟件過程定義，質量達標定義等；
2）實施質量保證——編寫相應的測試計劃、執行測試和評審活動；
3）實施質量控制——監控質量保證活動的結果，判斷是否達標，如不達標，則采取相應的風險防范措施。
3.3 軟件評審過程及標準定義
我們在整體軟件過程中明確定義了需要軟件評審的過程及實施的方法。
3.3.1 采用審查的過程
采用最嚴格最系統的評審方法——審查的軟件過程有：
1）《軟件需求規格說明書》的評審
2）《概要設計說明書》的評審
3）《詳細設計說明書》的評審
4）代碼評審
5）《單元測試計劃》的評審
6）《集成測試計劃》的評審
7）《系統測試計劃》的評審
對于文檔評審以文檔頁數為基數，要求每頁發現的缺陷數有一個目標值，并規定了上下限的范圍。對于代碼評審以代碼行數為基數，要求每千行代碼發現的缺陷數有一個目標值，并規定了上下限的范圍。這個審查的缺陷數標準如下表。
軟件過程審查的質量目標
質量目標 目標 下限 上限
SRS文檔Review缺陷發現密度（個/頁） 0.80 0.50 1.10
HLD文檔Review缺陷發現密度（個/頁） 0.70 0.50 0.90
LLD文檔Review缺陷發現密度（個/頁） 0.43 0.22 0.64
代碼檢視缺陷發現密度（個/KLOC） 10.62 7.43 13.81
單元測試計劃Review缺陷發現密度（個/頁） 0.43 0.22 0.64
集成測試計劃Review缺陷發現密度（個/頁） 0.70 0.50 0.90
系統測試計劃Review缺陷發現密度（個/頁） 0.80 0.50 1.10
如果發現的缺陷密度低于或高于質量目標范圍，則我們需要分析其原因，然后根據原因進行返工或相應處理流程。這要和實際情況相結合，具體情況具體分析：如某個開發工程師的水平和素質非常高，他的代碼一般很少出錯，這樣他的代碼檢視缺陷密度低是屬于正常的；而另外一個工程師水平一般，但發現的缺陷密度也很低，但原因是屬于檢視的過程不嚴格，大家沒有時間來進行嚴格的評審，則此時需要重新進行檢視。
3.3.2 采用小組評審的過程
采用小組評審的軟件過程主要包括對客戶需求的評審、項目計劃的評審和維護計劃的評審。
對客戶需求的評審參加人員有項目經理、系統分析員、系統架構師、質量部主管等。
項目計劃的評審主要由項目經理、系統分析員、系統架構師、質量部主管和部門經理等參加，對人力資源、進度和質量管控等進行評審。
維護計劃由項目經理、技術支持人員、質量部主管和客戶服務人員參加，對人力資源、管控流程等進行評審。
3.3.3 采用走查評審的過程
需求分析過程中，系統分析員、系統架構師相互之間的走查；
設計過程中，系統分析員、系統架構師相互之間的走查；
在進入維護階段時，作者需和維護人員進行走查，讓維護人員能夠維護作者的工作產品。
3.3.4 采用桌查的過程
采用桌查的過程主要集中在代碼提交階段，主要是經驗豐富的開發人員對提交的代碼進行檢查，合格的產品才會提交到CVS上面。
具體實施方法為：開發經驗較少（8年以下開發經驗）的開發人員在提交代碼時，請經驗豐富（10年以上開發經驗）的開發人員進行桌查，沒有明顯問題后才允許提交；經驗豐富的開發人員提交代碼時也需另一名經驗豐富的開發人員桌查后方可提交。
3.3.5 采用臨時評審的過程
代碼編寫階段開發工程師之間的臨時評審；
其他開發階段，開發人員相互之間的臨時評審。
3.3.6 采用結隊編程的過程
針對于需求不明確、采用迭代增量開發過程的小規模項目，采用極限編程時，建議采用結隊編程，但一般不做強制規定。
我們實際采用極限編程思想進行了兩個項目（一個內部項目和一個外部項目）的開發，實際上取得了非常好的效果。開發人員實際產出值達到了5000行代碼/人月以上。當然這些項目不太大，同時文檔編寫比較簡單。
3.4 審查流程定義
我們規定了審查流程的定義，其他評審技術只是采用了其中的流程和管理思想。
3.5 軟件評審效果分析
我們強化了軟件評審技術后，在實際過程中取得了非常好的效果。以一個網絡流量分析的項目為實例，在第一期沒有嚴格實施軟件評審技術，而第二期嚴格實施了軟件評審技術，其中審查數據如下表。
評審過程數據及質量分析實例
文件/模塊 計算基數（頁數/KLOC） 致命 嚴重 一般 提示 總和 標準（目標/下限-上限） 比例 達標與否
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
產生的效果為：
1）產出量：單位開發人員的產出量由950行代碼/人月（全流程）增長到1320行代碼/人月（全流程），增長量為38.9%。關鍵原因在于大在減少了項目后期返工的工作量。考慮由于項目熟悉和學習曲線等的原因，實際的產出增長量應該超過20%。
2）產品質量（遺留缺陷密度）：我們從軟件系統的遺留缺陷率來分析系統的質量情況。在半年的維護時間內，第一期代碼行為4萬行，嚴重缺陷有5個，一般缺陷有32個，嚴重缺陷發現密度為0.125個缺陷/千行代碼，總遺留缺陷發現密度為0.925個缺陷/千行代碼；第二期代碼行數為5萬行，嚴重缺陷有1個（屬于客戶需求問題引發的設計缺陷），一般缺陷有15個，嚴重缺陷發現密度為0.02個缺陷/千行代碼，總遺留缺陷發現密度為0.32個缺陷/千行代碼。因此嚴重缺陷發現密度改進了84%，一般缺陷發現密度改進了65.4%。
3）客戶滿意度：第一期客戶嚴重不滿意，稱我們在做玩具，滿意度只有22%；第二期客戶滿意度大幅上升，稱我們是專業人士，非常敬業，為他們所欽佩，滿意度達到了91%。因此滿意度提高了314%。
最主要的是，我們采用了軟件評審技術，規范了軟件開發過程的標準，并積累了實際的軟件開發過程數據，為后面的項目管理和過程控制提供了寶貴的軟件過程財富。
四、總結和展望
在實際工作中，我們以前掌握的過程數據不多，基本上一步一步摸索著前進，對于過程數據也在不斷的收集及整理中。對于評審技術而言，其中最重要的一點是采用多種實際工具和手段，如針對每個過程進行評審的《缺陷檢查表》等，我們也在逐步地完善這套體系和過程數據，從而為我們的過程改進不斷提供支持。
相關鏈接：
評審技術在高質量軟件開發中的應用分析（上）