個人軟體過程(個人軟體過程的英文縮寫)

個人軟體過程(Personal Software Process，PSP)是一種可用於控制、管理和改進個人工作方式的自我持續改進過程，是一個包括軟體開發表格、指南和規程的結構化框架。PSP與具體的技術（程式設計語言、工具或者設計方法）相對獨立，其原則能夠套用到幾乎任何的軟體工程任務之中。PSP能夠說明個體軟體過程的原則； 幫助軟體工程師作出準確的計畫；確定軟體工程師為改善產品質量要採取的步驟；建立度量個體軟體過程改善的基準；確定過程的改變對軟體工程師能力的影響。

基本介紹

• 中文名：個人軟體過程
• 外文名：Personal Software Process
• 簡稱：PSP 
• 作用：確定過程的改變 影響

概述

隨著軟體工程知識的普及，軟體工程師都知道，要開發高質量的軟體，必須改進軟體生產的過程。目前，業界公認由CMU/SEI開發的軟體能力成熟度模型SW-CMM是當前最好的軟體過程，並且CMM已經成為事實上的軟體過程工業標準。但是，CMM雖然提供了一個有力的軟體過程改進框架，卻只告訴我們"應該做什麼"，而沒有告訴我們"應該怎樣做"，並未提供有關實現關鍵過程域所需要的具體知識和技能。為了彌補這個欠缺，Humphrey又主持開發了個體軟體過程(Personal Software Process，PSP)。

在CMM1.1版本的18個關鍵過程域中有12個與PSP有關，據統計，軟體項目開發成本的70%取決於軟體開發人員個人的技能、經驗和工作習慣。因此，一個單位的軟體開發人員如能接受PSP培訓，對該單位軟體能力成熟度的升級是一個有力的保證。CMM側重於軟體企業中有關軟體過程的巨觀管理，面向軟體開發單位，PSP則側重於企業中有關軟體過程的微觀最佳化，面向軟體開發人員。二者互相支持，互相補充，缺一不可。

PSP過程改進模型

按照PSP規程，改進軟體過程的步驟首先需要明確質量目標，也就是軟體將要在功能和性能上滿足的要求和用戶潛在的需求。接著就是度量產品質量，有了目標還不行，目標只是一個原則性的東西，還不便於實際操作和判斷，因此，必須對目標進行分解和度量，使軟體質量能夠"測量"。然後就是理解當前過程，查找問題，並對過程進行調整。最後套用調整後的過程，度量實踐結果，將結果與目標做比較，找出差距，分析原因，對軟體過程進行持續改進。

就象CMM為軟體企業的能力提供一個階梯式的進化框架一樣，PSP為個體的能力也提供了一個階梯式的進化框架，以循序漸進的方法介紹過程的概念，每一級別都包含了更低一級別中的所有元素，並增加了新的元素。這個進化框架是學習PSP過程基本概念的好方法，它賦予軟體人員度量和分析工具，使其清楚地認識到自己的表現和潛力，從而可以提高自己的技能和水平。

個體度量過程PSP0和PSP0.1

PSP0的目的是建立個體過程基線，通過這一步，學會使用PSP的各種表格採集過程的有關數據，此時執行的是該軟體開發單位的當前過程，通常包括計畫、開發（包括設計、編碼、編譯和測試）以及後置處理三個階段，並要作一些必要的試題，如測定軟體開發時間，按照選定的缺陷類型標準、度量引入的缺陷個數和排除的缺陷個數等，用作為測量在PSP的過程中進步的基準。

CMM/TSP/PSP關係模型

PSP0.1增加了編碼標準、程式規模度量和過程改善建議等三個關鍵過程域，其中過程改善建議表格用於隨時記錄過程中存在的問題、解決問題的措施以及改進過程的方法，以提高軟體開發人員的質量意識和過程意識。

應該強調指出，在PSP0階段必須理解和學會使用表格進行規劃和度量的技術??經驗，以準確地滿足期望的需求，其中最重要的是要保持數據的一致性、有用性和簡潔性。

個體規划過程PSP1和PSP1.1

PSP1的重點是個體計畫，引入了基於估計的計畫方法PROBE（PROxy Based Estimating），用自己的歷史數據來預測新程式的大小和需要的開發時間，並使用線性回歸方法計算估計參數，確定置信區間以評價預測的可信程度。PSP1.1增加了對任務和進度的規劃。

PSP計畫示意圖

在PSP1階段應該學會編制項目開發計畫，這不僅對承擔大型軟體的開發十分重要，即使是開發小型軟體也必不可少。因為，只有對自己的能力有客觀的評價，才能作出更加準確的計畫，才能實事求是地接受和完成客戶（顧客）委託的任務。

個體質量管理過程PSP2和PSP2.1

PSP2的重點是個體質量管理，根據程式的缺陷善建立檢測表，按照檢測表進行設計複查和代碼複查（有時也稱"代碼走查"），以便及早發現缺陷，使修復缺陷的代價最小。隨著個人經驗和技術的積累，還應學會怎樣改進檢測表以適應自己的要求。PSP2.1則論述設計過程和設計模板，介紹設計方法，並提供了設計模板、但PSP並不強調選用什麼設計方法，而強調設計完備性準則和設計驗證技術。

實施PSP的一個重要目標就是學會在開發軟體的早期實際地、客觀地處理由於人們的疏忽所造成的程式缺陷問題。人們都期盼獲得高質量的軟體，但是只有高素質的軟體開發人員並遵循合適的軟體過程，才能開發出高質量的軟體，因此，PSP2引入並著重強調設計複查和代碼複查技術，一個合格的軟體開發人員必須掌握這兩項基本技術。

個體循環過程PSP3

PSP3的目標是把個體開發小程式所能達到的生產效率和生產質量，延伸到大型程式；其方法是採用螺旋式上升過程，即疊代增量式開發方法，首先把大型程式分解成小的模組，然後對每個模組按照PSP2.1所描述的過程進行開發，最後把這些模組逐步集成為完整的軟體產品。

套用PSP3開發大型軟體系統，必須採用增量式開發方法，並要求每一個增量都具有很高的質量。在這樣的前提下，在新一輪開發循環中，可以採用回歸測試的方法，集中力量考察新增加的這個（這些）增量是否符合要求。因此，要求在PSP2中進行嚴格的設計複查和代碼複查，並在PSP2.1中努力遵循設計結束準則。

從對個體軟體過程框架的概要描述中，可以清楚地看到，如何作好項目規劃和如何保證產品質量，是任何軟體開發過程中最基本的問題。

PSP可以幫助軟體工程師在個人的基礎上運用過程的原則，藉助於PSP提供的一些度量和分析工具，了解自己的技能水平，控制和管理自己的工作方式，使自己日常工作的評估、計畫和預測更加準確、更加有效，進而改進個人的工作表現，提高個人的工作質量和產量，積極而有效地參與高級管理人員和過程人員推動的組織範圍的軟體工程過程改進。

PSP軟體工程規程為軟體工程師提供了發展個人技能的結構化框架和必須掌握的方法。在軟體行業，開發人員如果不經過PSP培訓，就只能靠在開發中通過實踐逐步掌握這些技能和方法，這不僅周期很長，要付出很大的代價，而且有越來越大的風險。 培訓的方式有很多，既可以到專門的學校進修，也可以進行自學和參加培訓班，例如：CMM網校中就有個體軟體過程的課程。

過程改進

PSP是一個需要逐步改進的過程。

Watts S. Humphrey服兵役的時候，必須學會機槍射擊。開始訓練時用獵槍打泥鴿子，Watts的成績非常差，並且努力訓練還是沒有提高。教官對Watts進行了一段觀察後，建議他用左手射擊。作為一個習慣右手的人，開始Watts很不習慣，但練了幾次後，Watts的成績幾乎總是接近優秀。

這個事例說明了幾個問題。首先，要通過測量來診斷一個問題，通過了解Watts擊中了幾隻鴿子和脫靶的情況，很容易看出必須對Watts做些調整。然後，必須客觀的分析測量的數據，通過觀察Watts的射擊，教官就可以分析Watts射擊的過程—上膛、就位、跟蹤目標、瞄準，最後射擊。教官的目的就是發現Watts哪些步驟存在問題，找到問題所在，於是建議目的就是發現用左手射擊。

最後，也是最重要的，就是自身的變化。過程改進是非常困難的，因為人們很多時候不願意嘗試新事物。他們傳統的習慣看起來很自然，以至於不相信改變會有什麼幫助。Watts總是使用右手，從來沒有想過左手射擊會是什麼樣子。但是自Watts採納了教官的建議，他的成績就提高了。

定義測量方法不是件容易的事情，但它總是可能的。首先定義測量方法。規定了測量方法後，就必須收集和分析數據。如果需要作些改進，接下來就要分析工作過程，看看什麼地方需要改進。最後要想真正的改進，必須切實做出改進。

如果Watts不改進他的射擊過程，它的成績幾年後都不會有什麼變化，也不會成為一個優秀的槍手。僅僅進行測量並不會產生什麼提高，僅僅靠努力也不會有什麼提高。在很大程度上工作方式決定了所得到的結果。如果還是按照老辦法工作，得到的結果還會是老樣子。

改進工作方式與Watts學習射擊的步驟一樣。它們並不複雜，如圖1所示：

時間管理

時間管理的邏輯原理

人們很可能像上星期那樣安排這星期的時間。當然，隨著工作的不同，也有很多例外的情況。

為了制定切實可行的計畫，必須對所用的時間進行跟蹤。如果問上周的時間是怎么利用的，一般人都認為很容易所出每項工作花了多少時間，但是當看到實際的數據時，很可能感到十分驚訝：花在編程上的時間比估計的少得多，花在消遣的時間比預期的多得多；樂意做的事情做的特別快，用的時間也似乎特別少，令人頭疼的事情占用的時間似乎比實際花費的時間多得多。要搞清楚時間都用在什麼地方，必須對時間進行跟蹤，保留一份準確的記錄。

為了檢查時間估計和計畫的準確性，必須把它們寫成文檔並在今後與實際情況進行比較。做計畫是一種技能，學習制定好的計畫，第一步就是要先做計畫，然後把該計畫寫下來，以便今後與實際數據相比較。

為了制定出更準確的計畫，需要知道以前的計畫中存在哪些錯誤，哪些地方可以進行改進。當按照計畫進行工作時，記錄下所花費的時間。通過比較文檔化的計畫和實際的結果，就可以發現計畫中存在哪些錯誤以及如何改進做計畫的過程。制定準確計畫的關鍵就??較，然後就會知道如何才能制定出更好的計畫。

為了管理好時間，首先制定時間分配計畫，然後按照計畫去做。製作計畫容易，但真正實施計畫是困難的。特別開始的時候，按照計畫進行工作可能比較困難，你可能會有很多藉口，最常見的就是這份計畫製作的不好。但只有按照計畫去做，你才能知道它的優劣。

按照計畫進行工作有三點好處：第一，了解計畫存在哪些問題，有助於更好的計畫下一個項目。第二，按照好的計畫完成工作。這看起來不重要，但是事實上軟體工程中的許多錯誤都是由於考慮不周、粗心大意或是不注意的小細節而造成的，按照好的計畫工作是避免這些錯誤的最好途徑。另一個更加微妙的好處就是它實際上在改變你的工作方式，有了計畫就不用浪費時間去考慮下一步要乾什麼，它會幫助你把精力集中在所中的事情上，很少分心，從而提高了工作效率。

了解時間的使用情況

將主要活動分類。在開始分配時間時，你會發現大部分時間都用在相對很少的幾個活動上。

記錄每項主要活動所花費的時間。堅持記錄時間需要很強的自我約束能力，要想進行精確的記錄，必須記錄下每件主要工作開始和結束的時間。除非你知道自己實際上用了多少時間，否則就不可能管理好使用時間的方式。

用標準的方法記錄時間。必須使用標準的時間日誌。因為需要採集的時間數據的數量增加得很快，如果不認真記錄和存儲這些數據，它們很可能丟失或變得混亂，這樣很不利於查找或對它們進行解釋。如果不打算對這些數據進行適當的整理、歸納，就根本不必要去收集數據。

以分鐘為測量單位。工程是在完成任務中不間斷工作的時間一般都少於1小時，因此以小時為單位對工作時間進行測量不能提供用以計畫和管理工作所需要的詳細數據，而用分鐘跟蹤時間容易得多。一旦決定進行時間跟蹤，用分鐘作為測量單位將比用小時更恰當。

表2.1——了解時間的使用情況

處理中斷時間。採用表2.1跟蹤時間時，一個常見的問題就是中斷。電話、聊天、偶爾的煩惱以及必要的休息打斷的次數多得令人吃驚。中斷的時間不是有效的工作時間，並且變化幅度很大，如果不對它進行測量，實際上就在時間記錄中加入了一個隨機數，也就很難使用時間數據來計畫和管理時間了。事件日誌中的數據能幫助你了解工作被打斷的頻率。多數中斷不僅浪費時間，還會打斷你的思路，導致效率降低和錯誤的產生，因此了解被打斷的頻率有助於提高工作的質量和效率。

將時間數據保存在合適的地方。記錄時間花費情況值得推薦的方法就是用工程記事本來記錄時間以及其他的事情。對一個軟體專業人員，工程記事本用途很多，可以記錄時間日誌、程式設計方案以及運算結果，可以作為你所遵循正確的工程實施方案的憑證，可以記錄下腦子裡面一閃而過的想法。推薦的方法是從工程記事本的第一頁開始向後記錄主要活動及其所花費的時間，最後一頁開始向前記錄時間日誌。記錄主要活動及其所花費的時間，最後一頁開始向前記錄時間日誌。

周活動總結表。通過採用時間日誌收集時間數據後，你就能漸漸明白自己是如何支配時間的。但是時間日誌中的數據過於詳細，需要用一種更有用的表格來總結這些數據，周活動總結表能夠很好的完成這個任務。當然我們關心的時間不會只有一周這么短，還需要一段時間內在各類任務上花費的平均時間、最大時間和最小時間。因此採用表2.2所示格式。周活動總結表中的數據可以幫助你了解時間都用在那些地方，還可以使用這些書對以後的幾周進行計畫。例如，有了這些數據就能判斷出一個大的任務所需要的時間可能接近總結表中的最長時間，而一個簡單的任務需要的時間可能接近最短時間。

記錄時間的提示。隨時準備好工程記事本；當偶爾忘了記錄開始時間、結束事件或中斷時間，憑記憶儘早作出估計；及時總結記錄的時間數據。

制訂計畫

如何制定階段計畫

這裡介紹兩種計畫：階段計畫和產品計畫。階段計畫是關於這段時間內對時間的安排，產品計畫是關於製作產品活動期間的時間安排。以讀一本書為例來說明階段計畫和產品計畫的區別。為了計畫這項工作，首先估計出整個任務應花費多少時間。例如，你可能希望用20小時閱讀全書20章的內容。對於這個任務來說，產品計畫就是以20小時讀完全部書為目標，階段計畫就是每周安排1小時讀書這種方式。下圖表示了業務領域中產品計畫和階段計畫的關係。

為了制定階段計畫，必須清楚時間的使用情況。根據上一章介紹的周活動總結表，我們就可以跟蹤記錄自己是如何支配時間的。在制訂下一周的計畫時，就可以參考最近的周活動總結表。根據以前各個任務花費的時間，就能判斷出下一周將在這些任務上花費多少時間。制定這種計畫最簡單的方法就是假設將要使用的時間與過去平均使用的時間相同。一種較為精確的方法就是首先考慮下周將要做的工作內容，然後根據以前的最長和最短時間來估計出一個合適的時間。

如何制定產品計畫

當工程師在項目小組中工作時，就需要計畫個人的工作。計畫是按期完成承諾的任務的可靠基礎，可以在工程師合作開發產品過程中協調他們的工作，可以幫助工程師了解項目的狀態。做計畫是軟體工程師工作的一個重要部分，要成為一個有才幹的工程師，就必須知道如何制訂準確的計畫，也需要知道如何將這些計畫與實際結果相比較，從而學會制定更好的計畫。

制定產品計畫是可以通過事件加以提高的一種技能。從現在開始對每個產品制訂計畫，產品可以是一個可制定的程式、一個程式設計方案或是一個測試計畫，並在以後的項目中繼續這樣做下去。

收集歷史項目數據。對於工程人員，一個產品計畫包含產品規模、工作時間和進度三方面的估計。最基本的產品計畫只包括對任務或作業所需時間的估計。通過收集以前不同任務所用時間的數據，就能夠估計將來類似的任務大概所需要的時間。表3.1是為了記錄每個項目估計時間和實際時間而設計的作業編號日誌，參考這些歷史項目數據，我們可以方便、準確地作出估計。準確的估計是做好計畫的關鍵。

表3.1——制定產品計畫

估算程式規模。產品計畫的第一步是要估計產品的規模。對於程式來說，可以使用代碼行測量方法估計新程式的規模。為了準確的估計，需要用到以前的規模數據，因此把以前的規模數據按照功能分類是有幫助的。首先查看新程式的需求，估計各類代碼有多少行，然後與以前統計的數字進行比較，可以得出開發新程式需要多少時間完成。隨著所積累的數據越來越多，作出的估計就會越來越準確。作業編號日誌作為記錄大量的歷史的規模和效率數據提供了一種簡便的方法，還可以使用表3.2記錄不功能類型的程式歷史數據，並按照規模排列。

表3.2——制定產品計畫

規模測量的方法很多，應該根據不同的對象使用不同的估計方法，即使對程式來說，代碼行測量方法也不能覆蓋所有的情況。沒有任何方法可以保證估計的結果一定準確，作出好的規模估計的關鍵是要有大量的歷史數據，要進行多次規模估計，並且要定期的將實際結果與估計值進行比較。

管理好時間

可以按照如下步驟管理時間：

1. 分析自己使用時間的歷史記錄；

2. 制定時間安排表，決定如何使用時間；

3. 對照制定的安排表跟蹤使用時間的方式；

4. 決定應該改變什麼意思自己的行動達到所作安排的要求。

複查時間的分類情況。周活動總結表給出了每周用在各個活動上的平均時間、最大時間和最小時間。檢查一下這些活動的分類，是否有些類別包含的範圍過大了，而另一些有分得過細。時間管理的重點放在那些站用大部分時間的少數幾項活動上。

作出時間安排。時間安排表是如何使用時間的計畫，根據以前如何使用時間的數據，就可以作出計畫，分配以後活動所需要的時間，如表3.3所示。

找出更多的時間。管理好時間的關鍵是逐步對使用時間的方式進行反覆平衡，因為時間每天24小時是固定的。如果希望以後在某些任務多用一些時間，除非能夠在另外一些任務中少用一些時間，否則，這常常只是一個願望而已。

制定基本規則。我們在做許多事情是都是按照一定的規則去做的。為了對時間進行有效管理，也需要有規則可循。不同的是前些規則是別人製作的，而時間管理必須自己制定這些規則。實際上，時間管理的安排就是為管理自己的時間而制定的規則。時間管理的基本規則：已經決定如何使用時間，就必須切實的按照預定的方式去做；為了切實按照預定的安排去做，就必須有非常具體的計畫。表3.4就是位置到每天活動制定的每天時間安排表。

表3.4——每天時間安排表

設定時間分配的優先權。有些時間是固定不點的，如每周例會，可以把這些時間稱為固定時間。進行其他活動的時間就是可變動的時間，只要有時間就可以去做這些活動。可變時間又分成需要完成的任務和自行斟酌的任務。需要的活動如編程、讀書，雖然是需要的活動，但它們的時間是可變動的，因為無論如何找出時間都可做這些事情，並且每周在這些活動上所用的時間是不同的。自行斟酌的活動就是要做的所有其他的事情：吃飯、睡覺、社交、觀看電視及其其他的娛樂活動。

當作出全面的時間安排時，固定時間的安排是沒有什麼問題，最常見的問題是分配可變動的時間。列出需要儘快做的事情，首先努力完成最重要的任務。重要的任務推此時，你會不自覺的為這些任務擔心，立刻處理這些事情常常是更有效的，並且也將給人們帶來一種完成任務的成就感。此外，記住一旦開始了一項令人生畏的任務，就很少會感到象你想像中的那么困難。

可以考慮從自行斟酌的活動中抽出那些額外的時間，但是這需要合理的安排，對個人是否真願意按照這時間安排來執行。沒有休息的時間會導致人們將管理好時間的想法推翻。做時間安排以及跟蹤時間是重要的，但是時間安排一定要是自己實際願意接受的。

執行時間安排表。按照時間安排表工作的能力很大程度上取決於個人的自覺性，但是它還取決於要做的工作的數量和它們的優先次序。預料不到的時間是生活中很自然並且是很正常的一部分，特別是在軟體工程中。危機常常會打破人們的計畫，因此不得不作出調整。

在第一次使用時間安排表時，可能會感到它不是很有用，這是正常的，不要因為第一次沒有起作用就放棄對時間安排的過程，而是要考慮所發生的事情，看看是否存在一些不可能再發生的反常時間、或者存在對有正常事件引起人而意外花費了很多時間？如果是緊急的情況，不必對時間安排做大的調整，下一周再試著用它，然後複查結果。如果一些經常發生的事情擾亂了安排，應考慮對安排進行改動，為以後類似事情提前做好準備。

最後，按照時間安排表跟蹤實施的性能，要繼續收集時間數據。根據經驗複查時間安排表，在根據需要和經驗修改安排，要逐步的作出改變。在改變時間安排表時，要保存以前的版本。

時間管理的目標。收集時間是為了幫助自己管理時間。如果收集的數據被證明是沒有用的，就需要重新考慮自己收集時間數據的方法。但是，只有在已經實踐了安排的時間之後再這樣做。記事作了時間安排表，如果由於一些原因對時間安排變化很大，那么也應該收集更多的數據，知道自己明白當前是如何使用時間為止。

缺陷管理

什麼是缺陷

缺陷是指程式中存在的錯誤，例如語法錯誤、標點符號錯誤或者是一個不正確的程式語句，是任何影響程式完整而有效的滿足用戶要求的東西，是可以表示、描述和統計的客觀事物。

有人把缺陷稱為Bug，這是不正確的。當成為Bug時，令人想到的是那些令人討厭的小蟲子，應該把它們拍死或者不予理睬。這會使一些重要的問題被視為瑣碎小事，會養成一種錯誤的態度。缺陷並不像無足輕重的Bug，更像是定時炸彈。大家可能會覺得有些誇大其詞，絕大部分細小的缺陷沒有引起嚴重後果。然而不幸的是，很小一部分看起來無關緊要的缺陷卻能引起嚴重問題。雖然現在缺陷對你來說還不是一個嚴重問題，但很快就會成為一個重要的問題。

設計錯誤的複雜性和所導致的缺陷的影響沒有直接關係，一些微小的編碼錯誤卻可能引起嚴重的系統問題。事實上，絕大多數軟體缺陷都源於程式設計師的疏忽大意。

為了減小缺陷，就必須進行缺陷管理，研究已經引入的缺陷，確定引起這些缺陷的原因，並學會在將來如何避免重複同樣的錯誤。

缺陷分類。在分析缺陷時，將缺陷進行分類是有幫助的。通過缺陷分類，可以迅速找出哪一類缺陷的問題最大，然後集中精力預防和排除這一類缺陷，這就是缺陷管理的關鍵。把精力集中到最容易引起問題的幾類缺陷上，一旦這幾類缺陷得到控制，在進一步找到新的容易引起問題的幾類缺陷上。表4.1是Chillarege和他的IBM研究院的工作成果。

表4.1——缺陷分類

不要急於把10種類型的每一類細分出若干子類，直到你已經蒐集到大量程式的缺陷數據。那時，才能夠看出哪裡需要更詳細以及補充什麼樣的信息才是最有用的。

統計缺陷個數。採用缺陷記錄日誌，記錄那些當你完成初始設計或編碼後仍然留在產品中的缺陷。人們很容易對缺陷辯解，但是要管理好缺陷，就必須收集有關缺陷的準確數據。如果原諒缺陷，那只會自欺欺人。如果你這樣做的話，就別指望有所提高。

缺陷查找技術

為什麼要儘早發現缺陷。不要期望一個簡單拼湊出來的滿是缺陷的程式，經過修改可以成為一個合格的產品。一旦生產出一個有缺陷的程式，它將永遠是有缺陷的。雖然你可以修復所有已知的問題，並且讓它通過所有的測試，但它還是一個有許多不定的有缺陷的程式。如果工程師能寬容有缺陷的工作，他將生產出低質量的產品。“我們忙，以後在修補吧”，這樣的態度不可能出產出優質產品。

發現和修復缺陷的費用。在典型項目中，產品被分成很多小的模組，由不通的工程師負責開發。在模組設計、實現、編譯後，工程師作初始的單元測試；單元測試後，多個模組組成一些大組件進行集成測試；經過各種級別的組件測試後，這些組件集成為產品進行產品設計；最後，將產品集成到系統中進行系統測試。隨著系統的規模和複雜程度不同，單元測試、集成測試、組件測試、產品測試、系統測試的類型、持續時間、複雜程度有所不同，但幾乎所有規模的軟體產品，都需要這個過程。

研究證明，開發過程每前進一步，發現和修復缺陷的平均代價要增長10倍。儘管缺陷的修復時間變化很大，但平均時間總是遵循這樣的規律，而與缺陷的類型無關。

發現和修復缺陷的方法。儘管沒有辦法不引入缺陷，但是在開發過程中儘早發現和修復缺陷還是可能的。有多種發現程式中的缺陷的方法，基本上都包括以下步驟：表示缺陷徵兆；從徵兆中推斷出缺陷的位置；確定程式中的錯誤；決定如何修復缺陷；修復缺陷；驗證這個修復是否已經解決了這個問題。

有多種工具和輔助手段來幫助完成這些步驟，工程師最常用的工具是編譯器，它能夠表示出大部分語法缺陷。但是編譯器最基本的任務是生成目標代碼，並且可能會在源程式有缺陷的情況下生成代碼。因此，不能檢查出所有的拼寫、標點符號或其他不符合語法的缺陷。一般編譯器僅提供了缺陷的徵兆，你必須自己對問題定位，並確定是什麼問題，通常很快能夠做到這一點，但偶爾也需要較長的時間

另外一種常用方法就是上面講述的測試。測試的質量是由測試用例覆蓋所有程式功能的程度決定的。測試可以用來驗證程式幾乎所有的功能，但有自己的缺點：同編譯器一樣只能滿足缺陷派出的第一個步驟，你仍必須從缺陷徵兆找出問題的根源，然後才能修復；隨著項目規模的擴大，全面的測試會花費大量的時間，要進行完全測試幾乎不可能的。

最有效的發現和修復缺陷的方法是個人複查源程式清單。這種方法是負很難徹底清除程式中的缺陷，但事實證明，這是最快而且最有效的方法。

代碼複查

代碼複查就是研究原始碼，並從中發現錯誤。代碼複查更有效的原因是：在複查時看到的是問題本身而不是徵兆。從頭到尾複查代碼時，考慮的是程式應該做什麼。因此，當看到某些地方不正確時，就可以看到可能的問題是什麼，並立即去驗證代碼。複查的缺點是：非常耗時，而且很難恰當的進行；複查時一種技能，當然可以通過學習和實踐來提高。

代碼複查的第一步是了解自己引入的缺陷的種類，這是收集缺陷數據的主要原因。因為在下一個程式中引入的缺陷種類一般會與前面的基本類似，只要採用同樣的軟體開發方法，情況會一直如此。另一方面來說，當你有了技能和經驗或改變了過程，缺陷的類型和數目會隨之變化。但是到了一定程度後，改進就變得非常困難了。這是，就必須研究缺陷，這可以幫助你找到更好的發現和修復缺陷的方法。

如何進行代碼複查。代碼複查的目標是在軟體過程中儘可能早和儘可能多的發現缺陷，缺陷發現時間越少越好。採用表4.3描述的一個有序的檢查方法，在編譯之前進行代碼複查，是完成目標最好的方法。

表4.3——代碼複查

編譯之前進行複查。有幾個原因說明應在編譯之前進行代碼複查：不論編譯前或編譯後，進行完整的代碼複查的時間大約相同；不論編譯前或編譯後，對檢查語法有效性的效果是一樣的；先做複查將節省大量編譯時間，若不做代碼複查，一般要花12%～15%的開發時間進行編譯，一旦使用代碼複查後，編譯時間可以縮短至3%或更少；編譯程式後，代碼一般複查很難徹底的進行； 經驗證明，在編譯階段有大量的缺陷時，一般在測試階段也有許多缺陷。

建立個人代碼複查檢查表。如果想發現和改正程式中的每一個缺陷，就必須遵照一個精確的規程。檢查表可以確保遵循這個規程，它包括一系列程式的步驟。按照檢查表去作時，就知道如何進行代碼複查。

如果能夠正確使用檢查表，還能知道每個步驟發現了多少缺陷。這樣就能測量出複查過程的效率，並進一步改進檢查表。檢查表包括了個人的經驗。通過不斷的使用和改進個人檢查表，就可以幫助你用較少的時間發現這些缺陷。表4.4是一個C++程式代碼複查表的範例。

定期更新檢查表。隨著時間的推移，檢查表自然的要變大。但是，檢查表的主要作用是幫助你把注意力集中在關鍵的方面。太大以後，你將失去重點。所以要定期複查缺陷數據，刪除那些不能找到問題的表項。

從個人檢查表的方法可以認識到，每個工程師都有各自的特點，某個工程師的實踐經驗對別人不一定適用。因而要設計出適合自己的檢查表，並定期的對它進行檢查以保證檢查表更有效。只要你在代碼複查中還遺漏缺陷，就要不斷尋找改進檢查表的方法。

進展是很緩慢的。最初，你發現缺陷的能力隨著每次複查都有所提高。此後，提高將變得很困難。要堅持收集和分析缺陷數據，並堅持思考如何才能預防缺陷的產生或怎樣更好的找到缺陷。只要堅持不斷的做下去，就能在代碼複查中不斷進步，不斷提高自己編寫程式的質量。

編碼標準。編碼標準是被廣泛接受的、能夠作為工作樣板的編碼實踐集。良好的編碼標準將有效地幫助您避免開發有潛在危險的代碼，有助於預防缺陷。例如，可以在編碼標準中列出那些應該避免使用的方法，規定號循環入口或在說明是初始化變數，避免不良的變數命名等。編碼標準還能有效地統一和規範整體開發活動。當其他開發人員加入到項目中來時，他們能夠很好地適應這一切。代碼也將變得更規範更易維護。

其他種類的代碼複查。在軟體組織中，一種常用的方法是同行評審，就是幾個工程師彼此複查程式。組織良好的同行評審一般會發現程式中50%～70%的缺陷。互查雖然需要很多時間，但是可以有效發現缺陷，因為工程師往往難於發現自己的設計錯誤。他們創作這個設計，直到程式應該完整什麼，即使概念有瑕疵、作了錯誤的設計或實現假定，他們往往很難發現。檢查這可以幫助他們克服這些問題。對一個大的項目，最佳檢查策略是，先做個人代碼複查再進行編譯，然後在任何測試前進時行同行檢查。

細心工作是有回報的。當工程師覺得對自己開發的程式附有質量責任時，他就不會依賴於編譯器或其他工具來發現缺陷。全面的代碼複查要花費時間，但是他們節省出來的時間比花費的時間多得多，並能夠生產出更好的產品。

缺陷預測

引入缺陷是人類的正常現象，所有的工程師都會引入缺陷。因此所有的工程師都應該了解自己引入缺陷的類型和數據。

在開發過程中，總是可再進行一輪測試或代碼複查，決定是否這樣做的唯一方法就是分析缺陷數據。通過分析歷史數據，可以估計出程式中缺陷的個數。通過把當前項目的數據??的質量情況。這樣就能決定是否需要增加一些缺陷排除步驟。

缺陷率的預測。當開發一個新的程式時，可能會覺得很難估計你將引入多少缺陷，理由是缺陷的個數因程式的不同而不同。缺陷個數不穩定是有以下幾個原因造成的。首先使經驗問題，個人的技能是在不斷提高的。開始編程式時，要面臨著很多以前沒有碰到過的問題。往往不能確定有些過程和函式是如何執行的，可能是語言的結構不清楚或者可能會遇到新的編譯器或編程環境的問題。這些問題都會引起開發時間和缺陷路的波動。有了經驗後，你將逐漸克服這些問題，犯的錯誤就減少了。這既減少缺陷的總數又減少缺陷數目的波動。缺陷的減少起初是由於經驗的增加和對語言熟練程度的提高。經過這最初的提高后，就需要收集和分析缺陷數據來進一步改進了。

缺陷路波動的第二個原因是個體過程不穩定。當開始學習寫程式時你也同時開始學習使用新的過程和方法。你的過程將隨著實際的經驗不斷的發展，這就會引起完成不同程式任務的時間和引入缺陷的數據的波動。

最後，缺陷本身也是這種變化的原因，引入的缺陷越多，修復這些缺陷所花時間就越長。修復缺陷所花的時間越長，引入新的缺陷的幾率也就會增加。因此缺陷的修改時間變動幅度很大。所以，很難對一個引入很多缺陷的過程進行預測。

隨著開發過程的改進，過程會逐步穩定下來。這種穩定將提高缺陷預測的準確性。試驗證明，如果在代碼複查方面花了足夠的時間，你的過程會迅速穩定下來。一旦你的過程相當穩定，缺陷也將容易預測。

根據對最近的程式跟蹤每千行引入和排除的缺陷數，就可估計出在將來的程式中可能引入和排除的缺陷數。