接評審技術在高質量軟體開發中的應用分析（上）
三、評審在高質量軟體開發的實際應用
3.1 高質量軟體開發專案介紹
高質量軟體，如電信軟體、金融**類軟體等，有較嚴格的要求：可用性要求非常高，並且不會因為系統維護和擴充套件而帶來運營中斷；支援使用現有管理工具和標準進行遠端管理；能夠提供更出色的效能以及運營在高可用性集群上的能力，減少任何單點的軟硬體失效現象。五個九（99.999%）意味著乙個系統的宕機時間一年不超過5分26秒。因此高質量軟體專案是一種對可用性、可靠性、穩定性要求非常高的軟體專案，要求軟體能夠每週7*24工作。
因此高質量軟體開發一般採用嚴格的軟體開發過程，明確定義每個階段的質量目標和要求，嚴格專案軟體開發過程控制。
我們在多個高質量軟體開發專案中成功地採用了評審技術，並發揮了巨大的作用。從這些專案的實際開發過程中，我們針對於規模從30人月——300人月，**行數從5萬行——30萬行的運營支撐系統專案制定了專案評審流程和相關要求。
3.2 軟體過程定義
軟體過程主要分為專案立項階段、需求分析階段、設計階段、編碼實現階段、測試階段（包括整合測試、系統測試和使用者驗收測試）、實施階段和維護階段，專案管理工作橫貫於所有的階段。詳細流程見流程圖。
在軟體過程中，我們定義了以下角色：
1）客戶
2）銷售人員
3）專案經理
4）系統分析員
5）系統架構師
6）開發工程師
7）質量工程師
8）技術支援人員
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%。
最主要的是，我們採用了軟體評審技術，規範了軟體開發過程的標準，並積累了實際的軟體開發過程資料，為後面的專案管理和過程控制提供了寶貴的軟體過程財富。
四、總結和展望
在實際工作中，我們以前掌握的過程資料不多，基本上一步一步摸索著前進，對於過程資料也在不斷的收集及整理中。對於評審技術而言，其中最重要的一點是採用多種實際工具和手段，如針對每個過程進行評審的《缺陷檢查表》等，我們也在逐步地完善這套體系和過程資料，從而為我們的過程改進不斷提供支援。
評審技術在高質量軟體開發中的應用分析（下）
接評審技術在高質量軟體開發中的應用分析 上 三 評審在高質量軟體開發的實際應用 3.1 高質量軟體開發專案介紹 高質量軟體，如電信軟體 金融 類軟體等，有較嚴格的要求 可用性要求非常高，並且不會因為系統維護和擴充套件而帶來運營中斷 支援使用現有管理工具和標準進行遠端管理 能夠提供更出色的效能以及運營...
軟體開發中質量與進度的痛
在軟體開發中,質量很重要 這個估計誰都知道 但是很多時候質量看上去卻又不能保證 基於進度壓力下 然後，就亂了 這個情景我想大多數人都經歷著，呵呵。高質量 高口碑的軟體開始於好的分析與設計階段，並不是靠後期的測試與修補來完成的 我就發表下下面這幾個階段會影響質量的地方吧 l 分析與設計階段 l 計畫安...
設計模式 在軟體開發中的應用
論設計模式在軟體開發中的應用 在解決這個論題之前，我們首先要了解設計模式的概念，及其基本的分類。設計模式 這四個字，相信大家在很多地方都會看到，什麼是設計模式呢?乙個設計模式提供一種提煉子系統或軟體系統中的元件的，或者它們之間的關係的綱要設計。設計模式描述普遍存在的在相互通訊的元件中重複出現的結構，...