個體軟體過程

PSP(Personal Software Process,個體軟體過程）是一個過程描述、測度和方法的結構化集合，能夠幫助軟體工程師改善其個人效能。通過採用一些表格、指令碼和標準，可幫助軟體工程師估算和計劃其工作，從而體現了定義過程及測量其質量和生產率的意義。

　　一個基本的PSP原則是：每個人都是不同的，對於某個工程師有效的方法不一定適合另一個，PSP幫助工程師測量和跟蹤他們自己的工作，使得他們能夠找到最適合自己的方法。

　　軟體工程師在做專案的開發計劃時，或是由經驗而來，或是由使用者需求而定，往往存在計劃與實際相差比較大的情況，或者是前鬆後緊，遺漏過多，造成維護量的增加。如何減少這種情況的發生？就需要把經驗量化並做出分析。通過記錄專案的估算情況與實際情況，並進行比較分析，則既利於有經驗的軟體工程師提高以後專案的預測率，也利於新手軟體開發人員參考其他工程師的經驗。 專案的開發成本是一個很重要的問題。通過記錄專案的估算成本與實際成本，提高軟體開發人員對專案成本估算的準確度，這對在專案早期就有一個清楚的認識大有幫助，以利於以後工作的規劃與開展。

　　通過記錄軟體工程師在專案設計及編寫程式碼階段出現的錯誤及解決辦法，以及記錄測試與維護階段出現的錯誤、缺陷及解決辦法，併產生報告，列出經常出現的錯誤及錯誤型別，可把錯誤儘量控制在交付使用者使用前，並儘量減少錯誤的發生。

　　需要注意的是，PSP的目的是為了改善軟體工程師的開發效能，而提高效能在於早期對專案有一個比較準確的把握。專案評估的準確度依賴於歷史資料的積累，只有正確的歷史資料越來越充分，在評估新專案時所採用的指標數才會越準確。在專案進展過程中，還需要根據影響因素的變化不斷調整估算指標。

　　專案估算

　　現在軟體在大多數基於計算機的系統中已成為最昂貴的部分，如果軟體成本估算的誤差很大，就會使盈利變成虧損。 軟體專案估算是一種解決問題的形式，在多數情況下，要解決的問題非常複雜，想一次性整體解決比較困難。因此，對問題進行分解，把其分解成一組較小的接近於最終解決的可控的子問題，再定義它們的特性。

　　估算技術一般有程式碼行(LOC)和功能點(FP)估演算法，這是兩種不同的估算技術，但有許多共同特性。專案計劃人員首先給出一個有界的軟體範圍的敘述，再由此嘗試著把軟體分解成一些小的可分別獨立進行估算的子功能。然後對每一個子功能估算其LOC或FP(即估算變數)。接著，把基線生產率度量用做特定的估算變數，匯出子功能的成本或工作量。將子功能的估算進行綜合後就能得到整個專案的總估算。

　　LOC或FP估算技術對於分解所需要的詳細程度是不同的。當用LOC作為估算變數時，功能分解是絕對必要的且需要達到很詳細的程度。而估算功能點所需要的資料是巨集觀的量，當把FP當做估算變數時所需要的分解程度可以不很詳細。LOC是直接估算的，而FP是通過估計輸入、輸出、資料檔案、查詢和外部介面的數目，以及複雜性校正值間接地確定的。除去所用到的估算變數，專案計劃人員必須對每一個分解的功能提出一個有代表性的估算值範圍。利用歷史資料或憑實際經驗，計劃人員對每個功能分別按樂觀的、可能的、悲觀的三種情況給出LOC或FP估計值。

　　為了反映開發特性的影響，應當隨時修正平均生產率。1 LOC(Lines of Code,程式碼行）估算程式碼尺寸

　　把專案劃分為若干個功能，分別計算每個功能的程式碼長度，所有功能程式碼行之和即專案的程式碼長度。

　　LOC估算表包括：

　　每個功能的程式碼長度估算值=（樂觀值+4*可能值+悲觀值）/6

　　估算工作量=程式碼總估算長度/估算生產率

　　估算總成本=日薪*估算工作量

　　估算行成本=估算總成本/估算程式碼長度

　　估算生產率由經驗獲得

　　2 FP(功能點）估算程式碼尺寸　

　　專案的功能點數是幾個測量引數(使用者輸入數、使用者輸出數、使用者查詢數、檔案數、外部介面數）的功能點之和。

　　使用者輸入數：計算每個使用者輸入，它們向軟體提供面向應用的資料。輸入應該與查詢區分開來，分別計算。

　　使用者輸出數：計算每個使用者輸出，它們向軟體提供面向應用的資訊。這裡，輸出是指報表、螢幕、出錯資訊，等等。一個報表中的單個資料項不單獨計算。

　　使用者查詢數：一個查詢被定義為一次聯機輸入，它導致軟體以聯機輸出的方式產生實時的響應。每一個不同的查詢都要計算。

　　檔案數：計算每個邏輯的主檔案（如資料的一個邏輯組合，它可能是某個大型資料庫的一部分或是一個獨立的檔案）。 外部介面數：計算所有機器可讀的介面（如磁帶或磁碟上的資料檔案），利用這些介面可以將資訊從一個系統傳送到另一個系統。

　　FP估算表包括：

　　每個測量引數的估算FP計數=估算值*加權因子

　　專案估算FP=各引數FP計數之和*複雜度調整因子

　　估算生產率由經驗獲得

　　估算工作量=專案估算FP/估算生產率

　　估算總成本=日薪*估算工作量

　　單個FP估算成本=估算總成本/估算FP

　　專案測量

　　專案測量的目的是雙重的。首先，這些度量能夠指導進行一些必要的調整以避免延遲，並減少潛在問題及風險，從而使得開發時間減到最少。其次，專案度量可在專案進行的基礎上評估產品質量，並且可在必要時修改技術方法以改進質量。

　　隨著質量的提高，錯誤會減到最小，而隨著錯誤數的減少，專案中所需的修改工作量也會降低，就導致整個專案成本的降低。

　　軟體測量可分為直接測量和間接測量。軟體工程過程的直接測量，包括花費的成本和工作量。產品的直接測量，包括產生的程式碼行、執行速度、記憶體大小及某段時間內報告的缺陷。產品的間接測量，包括功能、質量、複雜性、有效性、可靠性、可維護性及其他能力。

　　測量技術有LOC測量和FP測量法，LOC測量是直接測量，FP測量是間接測量。

　　1 LOC(Lines of Code,程式碼行）測量程式碼尺寸

　　把專案劃分為若干個功能，分別計算每個功能的程式碼長度，所有功能程式碼行之和即專案的程式碼長度。

　　LOC測量表包括：

　　實際工作量由選單項“專案實際進展”中的資訊得到。

　　實際總成本=日薪*實際工作量

　　實際行成本=實際總成本/實際程式碼長度

　　實際生產率=實際程式碼長度/實際工作量

　　2 FP(功能點）測量程式碼尺寸

　　專案的功能點數是幾個測量引數(使用者輸入數、使用者輸出數、使用者查詢數、檔案數、外部介面數）的功能點之和。

　　使用者輸入數：計算每個使用者輸入，它們向軟體提供面向應用的資料。輸入應該與查詢區分開來，分別計算。

　　使用者輸出數：計算每個使用者輸出，它們向軟體提供面向應用的資訊。這裡，輸出是指報表、螢幕、出錯資訊，等等。一個報表中的單個資料項不單獨計算。

　　使用者查詢數：一個查詢被定義為一次聯機輸入，它導致軟體以聯機輸出的方式產生實時的響應。每一個不同的查詢都要計算。

　　檔案數：計算每個邏輯的主檔案（如資料的一個邏輯組合，它可能是某個大型資料庫的一部分或是一個獨立的檔案）。

　　外部介面數：計算所有機器可讀的介面（如磁帶或磁碟上的資料檔案），利用這些介面可以將資訊從一個系統傳送到另一個系統。

　　FP測量表包括：

　　每個測量引數的實際FP計數=實際值*加權因子

　　專案實際FP=各引數FP計數之和*複雜度調整因子

　　實際工作量由選單項“專案實際進展”中的資訊得到。

　　實際總成本=日薪*實際工作量

　　單個FP成本=總成本/FP計數

　　實際生產率=實際FP計數/實際工作量

　　專案進度　

　　無論有經驗的軟體工程師還是新手軟體開發人員，在開始開發專案之前，都會有一個或粗或細的開發計劃，如何使計劃更接近實際？

　　為了更精確地制訂計劃，可以把專案劃分為若干個小任務，分別制定每個任務的完成計劃。 工作量的安排可參考LOC估算工作量或FP估算工作量，通過LOC估算表或FP估算表，可以檢視估算工作量的值。

　　錯誤記錄　

　　記錄專案各個階段的錯誤及解決辦法，不僅可以檢視每個專案出現的錯誤列表，而且可對所有專案中的錯誤按型別分類檢視。

　　軟體工程師們都知道，缺陷排除效率(DRE)是軟體質量度量的指標之一。當把一個專案作為一個整體來考慮時，DRE按如下方式定義：

　　DRE=E/(E+D)

　　其中E=軟體交付給終端使用者之前所發現的錯誤數
　　D=軟體交付之後所發現的缺陷數

　　最理想的DRE值是1，即軟體中沒有發現缺陷。但現實中，D會大於0，如何把錯誤發現的階段儘量控制在軟體交付使用前？PSP能改善這一點。

　　使用PSP詳細記錄了錯誤的型別、出錯次數、出錯原因、錯誤說明及解決辦法，使開發人員可以隨時檢視以前所犯的錯誤。把錯誤直觀集中地顯示出來，能夠起到經常提醒開發人員的作用，以減少犯同樣錯誤的機會，把錯誤儘量限制在交付使用前。

　　專案報告

　　對比分析與專案有關的資料，使軟體人員對估算、實際資料認識更深，提高以後的預測率。

　　從報告中，可以對每一個專案清楚地比較其估算工作量、計劃工作量與實際工作量的值，它們的比值越接近1，說明估算、計劃越準確。

　　還可以對LOC、FP的估算實際生產率做比較。同時報告還應提供專案中出現的錯誤數、出錯最多的錯誤名稱及錯誤型別等。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-621752/，如需轉載，請註明出處，否則將追究法律責任。