個體軟件過程(Personal Software Process，PSP)是一種可用于控制、管理和改進個人工作方式的自我持續改進過程，是一個包括軟件開發表格、指南和規程的結構化框架。PSP與具體的技術（程序設計語言、工具或者設計方法）相對獨立，其原則能夠應用到幾乎任何的軟件工程任務之中。PSP能夠說明個體軟件過程的原則； 幫助軟件工程師作出準確的計劃；確定軟件工程師為改善產品質量要采取的步驟；建立度量個體軟件過程改善的基準；確定過程的改變對軟件工程師能力的影響。
隨著軟件工程知識的普及，軟件工程師都知道，要開發高質量的軟件，必須改進軟件生產的過程。目前，業界公認由CMU/SEI開發的軟件能力成熟度模型SW-CMM是當前最好的軟件過程，并且CMM已經成為事實上的軟件過程工業標準。但是，CMM雖然提供了一個有力的軟件過程改進框架，卻只告訴我們"應該做什么"，而沒有告訴我們"應該怎樣做"，并未提供有關實現關鍵過程域所需要的具體知識和技能。為了彌補這個欠缺，Humphrey又主持開發了個體軟件過程(Personal Software Process，PSP)。
在CMM1.1版本的18個關鍵過程域中有12個與PSP有關，據統計，軟件項目開發成本的70%取決于軟件開發人員個人的技能、經驗和工作習慣。因此，一個單位的軟件開發人員如能接受PSP培訓，對該單位軟件能力成熟度的升級是一個有力的保證。CMM側重于軟件企業中有關軟件過程的宏觀管理，面向軟件開發單位，PSP則側重于企業中有關軟件過程的微觀優化，面向軟件開發人員。二者互相支持，互相補充，缺一不可。
按照PSP規程，改進軟件過程的步驟首先需要明確質量目標，也就是軟件將要在功能和性能上滿足的要求和用戶潛在的需求。接著就是度量產品質量，有了目標還不行，目標只是一個原則性的東西，還不便于實際操作和判斷，因此，必須對目標進行分解和度量，使軟件質量能夠"測量"。然后就是理解當前過程，查找問題，并對過程進行調整。最后應用調整后的過程，度量實踐結果，將結果與目標做比較，找出差距，分析原因，對軟件過程進行持續改進。
就象CMM為軟件企業的能力提供一個階梯式的進化框架一樣，PSP為個體的能力也提供了一個階梯式的進化框架，以循序漸進的方法介紹過程的概念，每一級別都包含了更低一級別中的所有元素，并增加了新的元素。這個進化框架是學習PSP過程基本概念的好方法，它賦予軟件人員度量和分析工具，使其清楚地認識到自己的表現和潛力，從而可以提高自己的技能和水平。
一、個體度量過程PSP0和PSP0.1
PSP0的目的是建立個體過程基線，通過這一步，學會使用PSP的各種表格采集過程的有關數據，此時執行的是該軟件開發單位的當前過程，通常包括計劃、開發（包括設計、編碼、編譯和測試）以及后置處理三個階段，并要作一些必要的試題，如測定軟件開發時間，按照選定的缺陷類型標準、度量引入的缺陷個數和排除的缺陷個數等，用作為測量在PSP的過程中進步的基準。
PSP0.1增加了編碼標準、程序規模度量和過程改善建議等三個關鍵過程域，其中過程改善建議表格用于隨時記錄過程中存在的問題、解決問題的措施以及改進過程的方法，以提高軟件開發人員的質量意識和過程意識。
應該強調指出，在PSP0階段必須理解和學會使用不合格進行規劃和度量的技術。設計一個好的表格并不容易，需要在實踐中積累經驗，以準確地滿足期望的需求，其中最重要的是要保持數據的一致性、有用性和簡潔性。
二、個體規劃過程PSP1和PSP1.1
PSP1的重點是個體計劃，引入了基于估計的計劃方法PROBE（PROxy Based Estimating），用自己的歷史數據來預測新程序的大小和需要的開發時間，并使用線性回歸方法計算估計參數，確定置信區間以評價預測的可信程度。PSP1.1增加了對任務和進度的規劃。
在PSP1階段應該學會編制項目開發計劃，這不僅對承擔大型軟件的開發十分重要，即使是開發小型軟件也必不可少。因為，只有對自己的能力有客觀的評價，才能作出更加準確的計劃，才能實事求是地接受和完成客戶（顧客）委托的任務。
三、個體質量管理過程PSP2和PSP2.1
PSP2的重點是個體質量管理，根據程序的缺陷善建立檢測表，按照檢測表進行設計復查和代碼復查（有時也稱"代碼走查"），以便及早發現缺陷，使修復缺陷的代價最小。隨著個人經驗和技術的積累，還應學會怎樣改進檢測表以適應自己的要求。PSP2.1則論述設計過程和設計模板，介紹設計方法，并提供了設計模板、但PSP并不強調選用什么設計方法，而強調設計完備性準則和設計驗證技術。
實施PSP的一個重要目標就是學會在開發軟件的早期實際地、客觀地處理由于人們的疏忽所造成的程序缺陷問題。人們都期盼獲得高質量的軟件，但是只有高素質的軟件開發人員并遵循合適的軟件過程，才能開發出高質量的軟件，因此，PSP2引入并著重強調設計復查和代碼復查技術，一個合格的軟件開發人員必須掌握這兩項基本技術。
四、個體循環過程PSP3
PSP3的目標是把個體開發小程序所能達到的生產效率和生產質量，延伸到大型程序；其方法是采用螺旋式上升過程，即迭代增量式開發方法，首先把大型程序分解成小的模塊，然后對每個模塊按照PSP2.1所描述的過程進行開發，最后把這些模塊逐步集成為完整的軟件產品。
應用PSP3開發大型軟件系統，必須采用增量式開發方法，并要求每一個增量都具有很高的質量。在這樣的前提下，在新一輪開發循環中，可以采用回歸測試的方法，集中力量考察新增加的這個（這些）增量是否符合要求。因此，要求在PSP2中進行嚴格的設計復查和代碼復查，并在PSP2.1中努力遵循設計結束準則。
從對個體軟件過程框架的概要描述中，可以清楚地看到，如何作好項目規劃和如何保證產品質量，是任何軟件開發過程中最基本的問題。
PSP可以幫助軟件工程師在個人的基礎上運用過程的原則，借助于PSP提供的一些度量和分析工具，了解自己的技能水平，控制和管理自己的工作方式，使自己日常工作的評估、計劃和預測更加準確、更加有效，進而改進個人的工作表現，提高個人的工作質量和產量，積極而有效地參與高級管理人員和過程人員推動的組織范圍的軟件工程過程改進。
PSP軟件工程規程為軟件工程師提供了發展個人技能的結構化框架和必須掌握的方法。在軟件行業，開發人員如果不經過PSP培訓，就只能靠在開發中通過實踐逐步掌握這些技能和方法，這不僅周期很長，要付出很大的代價，而且有越來越大的風險。 培訓的方式有很多，既可以到專門的學校進修，也可以進行自學和參加培訓班，例如：CMM網校中就有個體軟件過程的課程。
五、個體軟件過程PSP之過程改進
PSP是一個需要逐步改進的過程。
Watts S. Humphrey服兵役的時候，必須學會機槍射擊。開始訓練時用獵槍打泥鴿子，Watts的成績非常差，并且努力訓練還是沒有提高。教官對Watts進行了一段觀察后，建議他用左手射擊。作為一個習慣右手的人，開始Watts很不習慣，但練了幾次后，Watts的成績幾乎總是接近優秀。
這個事例說明了幾個問題。首先，要通過測量來診斷一個問題，通過了解Watts擊中了幾只鴿子和脫靶的情況，很容易看出必須對Watts做些調整。然后，必須客觀的分析測量的數據，通過觀察Watts的射擊，教官就可以分析Watts射擊的過程—上膛、就位、跟蹤目標、瞄準，最后射擊。教官的目的就是發現Watts哪些步驟存在問題，找到問題所在，于是建議目的就是發現用左手射擊。
最后，也是最重要的，就是自身的變化。過程改進是非常困難的，因為人們很多時候不愿意嘗試新事物。他們傳統的習慣看起來很自然，以至于不相信改變會有什么幫助。Watts總是使用右手，從來沒有想過左手射擊會是什么樣子。但是自Watts采納了教官的建議，他的成績就提高了。
定義測量方法不是件容易的事情，但它總是可能的。首先定義測量方法。規定了測量方法后，就必須收集和分析數據。如果需要作些改進，接下來就要分析工作過程，看看什么地方需要改進。最后要想真正的改進，必須切實做出改進。
如果Watts不改進他的射擊過程，它的成績幾年后都不會有什么變化，也不會成為一個優秀的槍手。僅僅進行測量并不會產生什么提高，僅僅靠努力也不會有什么提高。在很大程度上工作方式決定了所得到的結果。如果還是按照老辦法工作，得到的結果還會是老樣子。
改進工作方式與Watts學習射擊的步驟一樣。它們并不復雜，如圖1所示：
六、個體軟件過程PSP之時間管理
1、時間管理的邏輯原理
人們很可能像上星期那樣安排這星期的時間。當然，隨著工作的不同，也有很多例外的情況。
為了制定切實可行的計劃，必須對所用的時間進行跟蹤。如果問上周的時間是怎么利用的，一般人都認為很容易所出每項工作花了多少時間，但是當看到實際的數據時，很可能感到十分驚訝：花在編程上的時間比估計的少得多，花在消遣的時間比預期的多得多；樂意做的事情做的特別快，用的時間也似乎特別少，令人頭疼的事情占用的時間似乎比實際花費的時間多得多。要搞清楚時間都用在什么地方，必須對時間進行跟蹤，保留一份準確的記錄。
為了檢查時間估計和計劃的準確性，必須把它們寫成文檔并在今后與實際情況進行比較。做計劃是一種技能，學習制定好的計劃，第一步就是要先做計劃，然后把該計劃寫下來，以便今后與實際數據相比較。
為了制定出更準確的計劃，需要知道以前的計劃中存在哪些錯誤，哪些地方可以進行改進。當按照計劃進行工作時，記錄下所花費的時間。通過比較文檔化的計劃和實際的結果，就可以發現計劃中存在哪些錯誤以及如何改進做計劃的過程。制定準確計劃的關鍵就是要堅持制定計劃，并把每個計劃與實際結果相比較，然后就會知道如何才能制定出更好的計劃。
為了管理好時間，首先制定時間分配計劃，然后按照計劃去做。制作計劃容易，但真正實施計劃是困難的。特別開始的時候，按照計劃進行工作可能比較困難，你可能會有很多借口，最常見的就是這份計劃制作的不好。但只有按照計劃去做，你才能知道它的優劣。
按照計劃進行工作有三點好處：第一，了解計劃存在哪些問題，有助于更好的計劃下一個項目。第二，按照好的計劃完成工作。這看起來不重要，但是事實上軟件工程中的許多錯誤都是由于考慮不周、粗心大意或是不注意的小細節而造成的，按照好的計劃工作是避免這些錯誤的最好途徑。另一個更加微妙的好處就是它實際上在改變你的工作方式，有了計劃就不用浪費時間去考慮下一步要干什么，它會幫助你把精力集中在所中的事情上，很少分心，從而提高了工作效率。
2.了解時間的使用情況
將主要活動分類。在開始分配時間時，你會發現大部分時間都用在相對很少的幾個活動上。
記錄每項主要活動所花費的時間。堅持記錄時間需要很強的自我約束能力，要想進行精確的記錄，必須記錄下每件主要工作開始和結束的時間。除非你知道自己實際上用了多少時間，否則就不可能管理好使用時間的方式。
用標準的方法記錄時間。必須使用標準的時間日志。因為需要采集的時間數據的數量增加得很快，如果不認真記錄和存儲這些數據，它們很可能丟失或變得混亂，這樣很不利于查找或對它們進行解釋。如果不打算對這些數據進行適當的整理、歸納，就根本不必要去收集數據。
以分鐘為測量單位。工程是在完成任務中不間斷工作的時間一般都少于1小時，因此以小時為單位對工作時間進行測量不能提供用以計劃和管理工作所需要的詳細數據，而用分鐘跟蹤時間容易得多。一旦決定進行時間跟蹤，用分鐘作為測量單位將比用小時更恰當。
處理中斷時間。采用表2.1跟蹤時間時，一個常見的問題就是中斷。電話、聊天、偶爾的煩惱以及必要的休息打斷的次數多得令人吃驚。中斷的時間不是有效的工作時間，并且變化幅度很大，如果不對它進行測量，實際上就在時間記錄中加入了一個隨機數，也就很難使用時間數據來計劃和管理時間了。事件日志中的數據能幫助你了解工作被打斷的頻率。多數中斷不僅浪費時間，還會打斷你的思路，導致效率降低和錯誤的產生，因此了解被打斷的頻率有助于提高工作的質量和效率。
將時間數據保存在合適的地方。記錄時間花費情況值得推薦的方法就是用工程記事本來記錄時間以及其他的事情。對一個軟件專業人員，工程記事本用途很多，可以記錄時間日志、程序設計方案以及運算結果，可以作為你所遵循正確的工程實施方案的憑證，可以記錄下腦子里面一閃而過的想法。推薦的方法是從工程記事本的第一頁開始向后記錄主要活動及其所花費的時間，最后一頁開始向前記錄時間日志。記錄主要活動及其所花費的時間，最后一頁開始向前記錄時間日志。
周活動總結表。通過采用時間日志收集時間數據后，你就能漸漸明白自己是如何支配時間的。但是時間日志中的數據過于詳細，需要用一種更有用的表格來總結這些數據，周活動總結表能夠很好的完成這個任務。當然我們關心的時間不會只有一周這么短，還需要一段時間內在各類任務上花費的平均時間、最大時間和最小時間。因此采用表2.2所示格式。周活動總結表中的數據可以幫助你了解時間都用在那些地方，還可以使用這些書對以后的幾周進行計劃。例如，有了這些數據就能判斷出一個大的任務所需要的時間可能接近總結表中的最長時間，而一個簡單的任務需要的時間可能接近最短時間。
記錄時間的提示。隨時準備好工程記事本；當偶爾忘了記錄開始時間、結束事件或中斷時間，憑記憶盡早作出估計；及時總結記錄的時間數據。
七、個體軟件過程PSP之制訂計劃
1、如何制定階段計劃
這里介紹兩種計劃：階段計劃和產品計劃。階段計劃是關于這段時間內對時間的安排，產品計劃是關于制作產品活動期間的時間安排。以讀一本書為例來說明階段計劃和產品計劃的區別。為了計劃這項工作，首先估計出整個任務應花費多少時間。例如，你可能希望用20小時閱讀全書20章的內容。對于這個任務來說，產品計劃就是以20小時讀完全部書為目標，階段計劃就是每周安排1小時讀書這種方式。下圖表示了業務領域中產品計劃和階段計劃的關系。
為了制定階段計劃，必須清楚時間的使用情況。根據上一章介紹的周活動總結表，我們就可以跟蹤記錄自己是如何支配時間的。在制訂下一周的計劃時，就可以參考最近的周活動總結表。根據以前各個任務花費的時間，就能判斷出下一周將在這些任務上花費多少時間。制定這種計劃最簡單的方法就是假設將要使用的時間與過去平均使用的時間相同。一種較為精確的方法就是首先考慮下周將要做的工作內容，然后根據以前的最長和最短時間來估計出一個合適的時間。
2、如何制定產品計劃
當工程師在項目小組中工作時，就需要計劃個人的工作。計劃是按期完成承諾的任務的可靠基礎，可以在工程師合作開發產品過程中協調他們的工作，可以幫助工程師了解項目的狀態。做計劃是軟件工程師工作的一個重要部分，要成為一個有才干的工程師，就必須知道如何制訂準確的計劃，也需要知道如何將這些計劃與實際結果相比較，從而學會制定更好的計劃。
制定產品計劃是可以通過事件加以提高的一種技能。從現在開始對每個產品制訂計劃，產品可以是一個可制定的程序、一個程序設計方案或是一個測試計劃，并在以后的項目中繼續這樣做下去。
收集歷史項目數據。對于工程人員，一個產品計劃包含產品規模、工作時間和進度三方面的估計。最基本的產品計劃只包括對任務或作業所需時間的估計。通過收集以前不同任務所用時間的數據，就能夠估計將來類似的任務大概所需要的時間。表3.1是為了記錄每個項目估計時間和實際時間而設計的作業編號日志，參考這些歷史項目數據，我們可以方便、準確地作出估計。準確的估計是做好計劃的關鍵。
估算程序規模。產品計劃的第一步是要估計產品的規模。對于程序來說，可以使用代碼行測量方法估計新程序的規模。為了準確的估計，需要用到以前的規模數據，因此把以前的規模數據按照功能分類是有幫助的。首先查看新程序的需求，估計各類代碼有多少行，然后與以前統計的數字進行比較，可以得出開發新程序需要多少時間完成。隨著所積累的數據越來越多，作出的估計就會越來越準確。作業編號日志作為記錄大量的歷史的規模和效率數據提供了一種簡便的方法，還可以使用表3.2記錄不功能類型的程序歷史數據，并按照規模排列。
規模測量的方法很多，應該根據不同的對象使用不同的估計方法，即使對程序來說，代碼行測量方法也不能覆蓋所有的情況。沒有任何方法可以保證估計的結果一定準確，作出好的規模估計的關鍵是要有大量的歷史數據，要進行多次規模估計，并且要定期的將實際結果與估計值進行比較。
3、管理好時間
可以按照如下步驟管理時間：
1. 分析自己使用時間的歷史記錄；
2. 制定時間安排表，決定如何使用時間；
3. 對照制定的安排表跟蹤使用時間的方式；
4. 決定應該改變什么意思自己的行動達到所作安排的要求。
復查時間的分類情況。周活動總結表給出了每周用在各個活動上的平均時間、最大時間和最小時間。檢查一下這些活動的分類，是否有些類別包含的范圍過大了，而另一些有分得過細。時間管理的重點放在那些站用大部分時間的少數幾項活動上。
作出時間安排。時間安排表是如何使用時間的計劃，根據以前如何使用時間的數據，就可以作出計劃，分配以后活動所需要的時間，如表3.3所示。
找出更多的時間。管理好時間的關鍵是逐步對使用時間的方式進行反復平衡，因為時間每天24小時是固定的。如果希望以后在某些任務多用一些時間，除非能夠在另外一些任務中少用一些時間，否則，這常常只是一個愿望而已。
制定基本規則。我們在做許多事情是都是按照一定的規則去做的。為了對時間進行有效管理，也需要有規則可循。不同的是前些規則是別人制作的，而時間管理必須自己制定這些規則。實際上，時間管理的安排就是為管理自己的時間而制定的規則。時間管理的基本規則：已經決定如何使用時間，就必須切實的按照預定的方式去做；為了切實按照預定的安排去做，就必須有非常具體的計劃。表3.4就是位置到每天活動制定的每天時間安排表。
設定時間分配的優先級。有些時間是固定不點的，如每周例會，可以把這些時間稱為固定時間。進行其他活動的時間就是可變動的時間，只要有時間就可以去做這些活動。可變時間又分成需要完成的任務和自行斟酌的任務。需要的活動如編程、讀書，雖然是需要的活動，但它們的時間是可變動的，因為無論如何找出時間都可做這些事情，并且每周在這些活動上所用的時間是不同的。自行斟酌的活動就是要做的所有其他的事情：吃飯、睡覺、社交、觀看電視及其其他的娛樂活動。
當作出全面的時間安排時，固定時間的安排是沒有什么問題，最常見的問題是分配可變動的時間。列出需要盡快做的事情，首先努力完成最重要的任務。重要的任務推此時，你會不自覺的為這些任務擔心，立刻處理這些事情常常是更有效的，并且也將給人們帶來一種完成任務的成就感。此外，記住一旦開始了一項令人生畏的任務，就很少會感到象你想象中的那么困難。
可以考慮從自行斟酌的活動中抽出那些額外的時間，但是這需要合理的安排，對個人是否真愿意按照這時間安排來執行。沒有休息的時間會導致人們將管理好時間的想法推翻。做時間安排以及跟蹤時間是重要的，但是時間安排一定要是自己實際愿意接受的。
執行時間安排表。按照時間安排表工作的能力很大程度上取決于個人的自覺性，但是它還取決于要做的工作的數量和它們的優先次序。預料不到的時間是生活中很自然并且是很正常的一部分，特別是在軟件工程中。危機常常會打破人們的計劃，因此不得不作出調整。
在第一次使用時間安排表時，可能會感到它不是很有用，這是正常的，不要因為第一次沒有起作用就放棄對時間安排的過程，而是要考慮所發生的事情，看看是否存在一些不可能再發生的反常時間、或者存在對有正常事件引起人而意外花費了很多時間？如果是緊急的情況，不必對時間安排做大的調整，下一周再試著用它，然后復查結果。如果一些經常發生的事情擾亂了安排，應考慮對安排進行改動，為以后類似事情提前做好準備。
最后，按照時間安排表跟蹤實施的性能，要繼續收集時間數據。根據經驗復查時間安排表，在根據需要和經驗修改安排，要逐步的作出改變。在改變時間安排表時，要保存以前的版本。
時間管理的目標。收集時間是為了幫助自己管理時間。如果收集的數據被證明是沒有用的，就需要重新考慮自己收集時間數據的方法。但是，只有在已經實踐了安排的時間之后再這樣做。記事作了時間安排表，如果由于一些原因對時間安排變化很大，那么也應該收集更多的數據，知道自己明白當前是如何使用時間為止。
八、個體軟件過程PSP之缺陷管理
1、什么是缺陷
缺陷是指程序中存在的錯誤，例如語法錯誤、標點符號錯誤或者是一個不正確的程序語句，是任何影響程序完整而有效的滿足用戶要求的東西，是可以表示、描述和統計的客觀事物。
有人把缺陷稱為Bug，這是不正確的。當成為Bug時，令人想到的是那些令人討厭的小蟲子，應該把它們拍死或者不予理睬。這會使一些重要的問題被視為瑣碎小事，會養成一種錯誤的態度。缺陷并不像無足輕重的Bug，更像是定時炸彈。大家可能會覺得有些夸大其詞，絕大部分細小的缺陷沒有引起嚴重后果。然而不幸的是，很小一部分看起來無關緊要的缺陷卻能引起嚴重問題。雖然現在缺陷對你來說還不是一個嚴重問題，但很快就會成為一個重要的問題。
設計錯誤的復雜性和所導致的缺陷的影響沒有之間關系，一些微小的編碼錯誤卻可能引起嚴重的系統問題。事實上，絕大多數軟件缺陷都源于程序員的疏忽大意。
為了減小缺陷，就必須進行缺陷管理，研究已經引入的缺陷，確定引起這些缺陷的原因，并學會在將來如何避免重復同樣的錯誤。
缺陷分類。在分析缺陷時，將缺陷進行分類是有幫助的。通過缺陷分類，可以迅速找出哪一類缺陷的問題最大，然后集中精力預防和排除這一類缺陷，這就是缺陷管理的關鍵。把精力集中到最容易引起問題的幾類缺陷上，一旦這幾類缺陷得到控制，在進一步找到新的容易引起問題的幾類缺陷上。表4.1是Chillarege和他的IBM研究院的工作成果。
不要急于把10種類型的每一類細分出若干子類，直到你已經搜集到大量程序的缺陷數據。那時，才能夠看出哪里需要更詳細以及補充什么樣的信息才是最有用的。
統計缺陷個數。采用缺陷記錄日志，記錄那些當你完成初始設計或編碼后仍然留在產品中的缺陷。人們很容易對缺陷辯解，但是要管理好缺陷，就必須收集有關缺陷的準確數據。如果原諒缺陷，那只會自欺欺人。如果你這樣做的話，就別指望有所提高。
2、缺陷查找技術
為什么要盡早發現缺陷。不要期望一個簡單拼湊出來的滿是缺陷的程序，經過修改可以成為一個合格的產品。一旦生產出一個有缺陷的程序，它將永遠是有缺陷的。雖然你可以修復所有已知的問題，并且讓它通過所有的測試，但它還是一個有許多不定的有缺陷的程序。如果工程師能寬容有缺陷的工作，他將生產出低質量的產品。“我們忙，以后在修補吧”，這樣的態度不可能出產出優質產品。
發現和修復缺陷的費用。在典型項目中，產品被分成很多小的模塊，由不通的工程師負責開發。在模塊設計、實現、編譯后，工程師作初始的單元測試；單元測試后，多個模塊組成一些大組件進行集成測試；經過各種級別的組件測試后，這些組件集成為產品進行產品設計；最后，將產品集成到系統中進行系統測試。隨著系統的規模和復雜程度不同，單元測試、集成測試、組件測試、產品測試、系統測試的類型、持續時間、復雜程度有所不同，但幾乎所有規模的軟件產品，都需要這個過程。
研究證明，開發過程每前進一步，發現和修復缺陷的平均代價要增長10倍。盡管缺陷的修復時間變化很大，但平均時間總是遵循這樣的規律，而與缺陷的類型無關。
發現和修復缺陷的方法。盡管沒有辦法不引入缺陷，但是在開發過程中盡早發現和修復缺陷還是可能的。有多種發現程序中的缺陷的方法，基本上都包括以下步驟：表示缺陷征兆；從征兆中推斷出缺陷的位置；確定程序中的錯誤；決定如何修復缺陷；修復缺陷；驗證這個修復是否已經解決了這個問題。
有多種工具和輔助手段來幫助完成這些步驟，工程師最常用的工具是編譯器，它能夠表示出大部分語法缺陷。但是編譯器最基本的任務是生成目標代碼，并且可能會在源程序有缺陷的情況下生成代碼。因此，不能檢查出所有的拼寫、標點符號或其他不符合語法的缺陷。一般編譯器僅提供了缺陷的征兆，你必須自己對問題定位，并確定是什么問題，通常很快能夠做到這一點，但偶爾也需要較長的時間
另外一種常用方法就是上面講述的測試。測試的質量是由測試用例覆蓋所有程序功能的程度決定的。測試可以用來驗證程序幾乎所有的功能，但有自己的缺點：同編譯器一樣只能滿足缺陷派出的第一個步驟，你仍必須從缺陷征兆找出問題的根源，然后才能修復；隨著項目規模的擴大，全面的測試會花費大量的時間，要進行完全測試幾乎不可能的。
最有效的發現和修復缺陷的方法是個人復查源程序清單。這種方法是負很難徹底清除程序中的缺陷，但事實證明，這是最快而且最有效的方法。
3、代碼復查
代碼復查就是研究源代碼，并從中發現錯誤。代碼復查更有效的原因是：在復查時看到的是問題本身而不是征兆。從頭到尾復查代碼時，考慮的是程序應該做什么。因此，當看到某些地方不正確時，就可以看到可能的問題是什么，并立即去驗證代碼。復查的缺點是：非常耗時，而且很難恰當的進行；復查時一種技能，當然可以通過學習和實踐來提高。
代碼復查的第一步是了解自己引入的缺陷的種類，這是收集缺陷數據的主要原因。因為在下一個程序中引入的缺陷種類一般會與前面的基本類似，只要采用同樣的軟件開發方法，情況會一直如此。另一方面來說，當你有了技能和經驗或改變了過程，缺陷的類型和數目會隨之變化。但是到了一定程度后，改進就變得非常困難了。這是，就必須研究缺陷，這可以幫助你找到更好的發現和修復缺陷的方法。
如何進行代碼復查。代碼復查的目標是在軟件過程中盡可能早和盡可能多的發現缺陷，缺陷發現時間越少越好。采用表4.3描述的一個有序的檢查方法，在編譯之前進行代碼復查，是完成目標最好的方法。
編譯之前進行復查。有幾個原因說明應在編譯之前進行代碼復查：不論編譯前或編譯后，進行完整的代碼復查的時間大約相同；不論編譯前或編譯后，對檢查語法有效性的效果是一樣的；先做復查將節省大量編譯時間，若不做代碼復查，一般要花12％～15％的開發時間進行編譯，一旦使用代碼復查后，編譯時間可以縮短至3％或更少；編譯程序后，代碼一般復查很難徹底的進行； 經驗證明，在編譯階段有大量的缺陷時，一般在測試階段也有許多缺陷。
建立個人代碼復查檢查表。如果想發現和改正程序中的每一個缺陷，就必須遵照一個精確的規程。檢查表可以確保遵循這個規程，它包括一系列程式的步驟。按照檢查表去作時，就知道如何進行代碼復查。
如果能夠正確使用檢查表，還能知道每個步驟發現了多少缺陷。這樣就能測量出復查過程的效率，并進一步改進檢查表。檢查表包括了個人的經驗。通過不斷的使用和改進個人檢查表，就可以幫助你用較少的時間發現這些缺陷。表4.4是一個C++程序代碼復查表的范例。
定期更新檢查表。隨著時間的推移，檢查表自然的要變大。但是，檢查表的主要作用是幫助你把注意力集中在關鍵的方面。太大以后，你將失去重點。所以要定期復查缺陷數據，刪除那些不能找到問題的表項。
從個人檢查表的方法可以認識到，每個工程師都有各自的特點，某個工程師的實踐經驗對別人不一定適用。因而要設計出適合自己的檢查表，并定期的對它進行檢查以保證檢查表更有效。只要你在代碼復查中還遺漏缺陷，就要不斷尋找改進檢查表的方法。
進展是很緩慢的。最初，你發現缺陷的能力隨著每次復查都有所提高。此后，提高將變得很困難。要堅持收集和分析缺陷數據，并堅持思考如何才能預防缺陷的產生或怎樣更好的找到缺陷。只要堅持不斷的做下去，就能在代碼復查中不斷進步，不斷提高自己編寫程序的質量。
編碼標準。編碼標準是被廣泛接受的、能夠作為工作樣板的編碼實踐集。良好的編碼標準將有效地幫助您避免開發有潛在危險的代碼，有助于預防缺陷。例如，可以在編碼標準中列出那些應該避免使用的方法，規定號循環入口或在說明是初始化變量，避免不良的變量命名等。編碼標準還能有效地統一和規范整體開發活動。當其他開發人員加入到項目中來時，他們能夠很好地適應這一切。代碼也將變得更規范更易維護。
其他種類的代碼復查。在軟件組織中，一種常用的方法是同行評審，就是幾個工程師彼此復查程序。組織良好的同行評審一般會發現程序中50％～70％的缺陷。互查雖然需要很多時間，但是可以有效發現缺陷，因為工程師往往難于發現自己的設計錯誤。他們創作這個設計，直到程序應該完整什么，即使概念有瑕疵、作了錯誤的設計或實現假定，他們往往很難發現。檢查這可以幫助他們克服這些問題。對一個大的項目，最佳檢查策略是，先做個人代碼復查再進行編譯，然后在任何測試前進時行同行檢查。
細心工作是有回報的。當工程師覺得對自己開發的程序附有質量責任時，他就不會依賴于編譯器或其他工具來發現缺陷。全面的代碼復查要花費時間，但是他們節省出來的時間比花費的時間多得多，并能夠生產出更好的產品。
4、缺陷預測
引入缺陷是人類的正常現象，所有的工程師都會引入缺陷。因此所有的工程師都應該了解自己引入缺陷的類型和數據。
在開發過程中，總是可再進行一輪測試或代碼復查，決定是否這樣做的唯一方法就是分析缺陷數據。通過分析歷史數據，可以估計出程序中缺陷的個數。通過把當前項目的數據和估計數據相比較，就能大概知道正在開發的程序的質量情況。這樣就能決定是否需要增加一些缺陷排除步驟。
缺陷率的預測。當開發一個新的程序時，可能會覺得很難估計你將引入多少缺陷，理由是缺陷的個數因程序的不同而不同。缺陷個數不穩定是有以下幾個原因造成的。首先使經驗問題，個人的技能是在不斷提高的。開始編程序時，要面臨著很多以前沒有碰到過的問題。往往不能確定有些過程和函數是如何執行的，可能是語言的結構不清楚或者可能會遇到新的編譯器或編程環境的問題。這些問題都會引起開發時間和缺陷路的波動。有了經驗后，你將逐漸克服這些問題，犯的錯誤就減少了。這既減少缺陷的總數又減少缺陷數目的波動。缺陷的減少起初是由于經驗的增加和對語言熟練程度的提高。經過這最初的提高后，就需要收集和分析缺陷數據來進一步改進了。
缺陷路波動的第二個原因是個體過程不穩定。當開始學習寫程序時你也同時開始學習使用新的過程和方法。你的過程將隨著實際的經驗不斷的發展，這就會引起完成不同程序任務的時間和引入缺陷的數據的波動。
最后，缺陷本身也是這種變化的原因，引入的缺陷越多，修復這些缺陷所花時間就越長。修復缺陷所花的時間越長，引入新的缺陷的幾率也就會增加。因此缺陷的修改時間變動幅度很大。所以，很難對一個引入很多缺陷的過程進行預測。
隨著開發過程的改進，過程會逐步穩定下來。這種穩定將提高缺陷預測的準確性。試驗證明，如果在代碼復查方面花了足夠的時間，你的過程會迅速穩定下來。一旦你的過程相當穩定，缺陷也將容易預測。
根據對最近的程序跟蹤每千行引入和排除的缺陷數，就可估計出在將來的程序中可能引入和排除的缺陷數。