個人軟體過程(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、缺陷預測
引入缺陷是人類的正常現象，所有的工程師都會引入缺陷。是以所有的工程師都應該了解自己引入缺陷的類型和資料。
在開發過程中，總是可再進行一輪測試或代碼複查，決定是否這樣做的唯一方法就是分析缺陷資料。通過分析曆史資料，可以估計出程式中缺陷的個數。通過把目前項目的資料和估計資料相比較，就能大概知道正在開發的程式的品質情況。這樣就能決定是否需要增加一些缺陷排除步驟。
缺陷率的預測。當開發一個新的程式時，可能會覺得很難估計你将引入多少缺陷，理由是缺陷的個數因程式的不同而不 同。缺陷個數不穩定是有以下幾個原因造成 的。首先使經驗問題，個人的技能是在不斷提高的。開始程式設計式時，要面臨着很多以前沒有碰到過的問題。往往不能确定有些過程和函數是如何執行的，可能是語言 的結構不清楚或者可能會遇到新的編譯器或程式設計環境的問題。這些問題都會引起開發時間和缺陷路的波動。有了經驗後，你将逐漸克服這些問題，犯的錯誤就減少 了。這既減少缺陷的總數又減少缺陷數目的波動。缺陷的減少起初是由于經驗的增加和對語言熟練程度的提高。經過這最初的提高後，就需要收集和分析缺陷資料來 進一步改進了。
缺陷路波動的第二個原因是個體過程不穩定。當開始學習寫程式時你也同時開始學習使用新的過程和方法。你的過程将随着實際的經驗不斷的發展，這就會引起完成不同程式任務的時間和引入缺陷的資料的波動。
最後，缺陷本身也是這種變化的原因，引入的缺陷越多，修複這些缺陷所花時間就越長。修複缺陷所花的時間越長，引入新的缺陷的幾率也就會增加。是以缺陷的修改時間變動幅度很大。是以，很難對一個引入很多缺陷的過程進行預測。
随着開發過程的改進，過程會逐漸穩定下來。這種穩定将提高缺陷預測的準确性。試驗證明，如果在代碼複查方面花了足夠的時間，你的過程會迅速穩定下來。一旦你的過程相當穩定，缺陷也将容易預測。
根據對最近的程式跟蹤每千行引入和排除的缺陷數，就可估計出在将來的程式中可能引入和排除的缺陷數。