評審技術在高品質軟體開發中的應用分析（下）

接評審技術在高品質軟體開發中的應用分析（上）

　　三、評審在高品質軟體開發的實際應用

　　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%。

　　最主要的是，我們采用了軟體評審技術，規範了軟體開發過程的标準，并積累了實際的軟體開發過程資料，為後面的項目管理和過程控制提供了寶貴的軟體過程财富。

　　四、總結和展望

　　在實際工作中，我們以前掌握的過程資料不多，基本上一步一步摸索着前進，對于過程資料也在不斷的收集及整理中。對于評審技術而言，其中最重要的一點是采用多種實際工具和手段，如針對每個過程進行評審的《缺陷檢查表》等，我們也在逐漸地完善這套體系和過程資料，進而為我們的過程改進不斷提供支援。