產業觀察

個人軟體程序簡介與部分應用

作者/林猷翔

[發表日期：2010/11/22]
前言

身為軟體開發人員，每天接觸的工作就是開發程式，開發之餘，總想提升自身效率、產出與軟體品質，卻苦無方法了解自己的表現，以及本身開發上最容易遇到的窒礙之處。如果有一套方法可以針對個人開發上的資料及數據進行收集並分析，可以使軟體開發人員了解工作的瓶頸之處，進而突破障礙、提升效率及產品品質。

「個人軟體程序」是美國卡內基美隆大學軟體工程學院(SEI)(註一)Watts S. Humphrey教授提出的軟體流程改善技術(註二)，其為一套系統化的流程改善方法，可以輔助使用者針對軟體開發的各個流程階段進行資訊收集和記錄，並根據獲得的相關資料，如程式碼大小、開發時間、缺陷修正時間等。透過分析和彙整，藉以產生各種分析表格和數據，如良率(yield)、生產力、程式碼檢驗清單(Review Checklist)等，最後透過這些分析來改善軟體開發流程，提昇軟體品質與個人生產力，並可有效減少軟體中缺陷的數目。

個人軟體程序介紹

個人軟體程序是一個循序漸進的改善方法，Humphrey將軟體開發改善程度分為四個階層(level)，分別是個人程序基準(The Baseline Personal Process, PSP0)、個人規劃程序 (Personal Planning Process, PSP1)、個人品質管理(Personal Quality Management, PSP2)、以及循環個人程序(The Cyclic Personal Process, PSP3)，而此四個階層又可以細分為七個定義嚴謹的小流程(PSP0~PSP3)，如圖一所示(註三)。每個流程都有明確的工作項目、應到達的標準(standard)、須填寫的表格(form)、需要收集的資料、工作腳本(script)和模板(template)。個人軟體程序在PSP0 和PSP1 階層將軟體的開發分為六個流程階段(phase)：計畫、設計、開發、編譯(compile)、測試(test)和流程檢驗(postmortem)。而PSP2 和PSP3 階層則分為八個流程階段，在設計階段後多了設計審查階段(design review)，以及在開發階段後多了程式碼審查階段(code review)，其劃分如圖二。其中新增的設計審查與程式碼審查流程階段，有助於改善軟體開發的流程，提高軟體的品質與生產力。

個人軟體程序四階層

個人軟體程序是一個循序漸進的改善方法，因此Humphrey也根據軟體開發改善的程度將個人軟體程序分成四個階層，以下分別就此四個階層進行說明：

一、個人程序基準

本階層主要為建立一個基準，將個人的開發流程固定下來，因為每個開發人員的開發流程不盡相同，並針對固定下來的流程進行資料的收集和量測。即根據開發人員現行的工作流程去做資料的收集與測量，透過這樣的動作去輔助我們了解個人現階段的開發效率(performance)和能力(capability)，並以此作為基準，進而了解流程改善的成效。此外，本階段包含了七個工作，分別為︰定義現階段的流程(define current process)、記錄時間(time recording)、記錄缺陷(defect recording)、缺陷型態標準(defect type standard)、程式碼撰寫標準(coding standard)、程式碼大小量測(size measurement)和流程改善建議表格(Process improvement proposal form, PIP)。以下進行詳細說明：

• 定義現階段的流程


將軟體的開發流程定義為計畫、發展、流程檢驗三個階段，而發展階段又可細分為設計、開發程式碼、編譯程式碼、測試，所以將流程定義為六個階段，並且記錄每個流程階段該收集的資料。


• 記錄時間


記錄每一個階段所耗費的時間，包含階段開始的時間(start time)、階段結束的時間(stop time)以及其中斷的時間(interrupt time)，並藉此求得每一階段的實際工作時間(Delta time, Delta time = stop - start - interrupt)，和階段的名稱，如設計、編譯程式碼、計畫等。


• 記錄缺陷


記錄在開發過程中發生的缺陷資訊，包含缺陷代碼、缺陷植入的階段、缺陷移除的階段、缺陷發現的日期、缺陷的種類、缺陷修正的時間、缺陷的描述等。此外，如果缺陷為修正另一個缺陷後而產生出來的，此時會在該缺陷資訊上加上註記，註明其相關缺陷。


• 缺陷型態標準


將缺陷型態的分類歸納出來，透過統一的標準以區分缺陷的型態種類，以方便日後的分析和改善，主要可以區分為文件(documentation)、語法(syntax)、建立(build)、假設(assignment)、介面(interface)、檢查(checking)、資料(data)、功能(function)、系統(system)和環境(environment)等十大類，並可因需要再進行細分。


• 程式碼撰寫標準


程式碼撰寫標準主要是為了提高程式碼的可閱讀性，將會要求開發人員須列出程式的標頭(headers)和其格式、內容說明、重複使用(reuse)說明、變數(variable)定義格式、註解格式等，透過這樣的標準，使得程式碼不會因開發人員的變動而無法維護和持續開發。


• 程式碼大小量測


量測程式碼的大小所獲得之數據，即程式碼行數。此階段須建立程式碼計算標準(size counting standard)，然後根據此標準去計算產品的程式碼行數，且計算標準可依型態不同分為實體計算(physical)跟邏輯計算(logical)兩種。實體計算為逐行計算，包含註解行等，只要該行有程式或文字即列入計算；而邏輯計算則須訂定標準，將註解、引號、宣告(declaration)、引用(import)、迴圈、條件判斷等依照開發人員或組織的意願選擇計算或不計算，然後根據此標準去計算程式碼行數。


• 流程改善建議表格


此表格會記錄使用者的姓名、日期、專案名稱、專案編號、開發語言、指導者或主管姓名，以及問題描述(problem description)、改善方法描述(proposal description)和其他意見(other notes and comments)。使用者透過此表格描述出開發流程中的問題，並提出可能的解決方式，並於下次專案實行之，以期達到流程改善的目標。

二、個人規劃程序

本階層主要是針對資源和日程表進行規劃並預估程式碼的大小。透過日程的規劃和程式碼大小的預估可以令使用者了解到開發軟體所需時程、應執行之工作、進度是否延宕以及需撰寫的程式大小等資訊，使得軟體產品可以準時交付。本階段同樣包含了兩個小流程，即PSP1和PSP1.1，其中PSP1包含了兩個工作，分別為︰程式碼大小預估(size estimating)、測試報告(test report)，而PSP1.1除了包含上述兩個工作外，又多包含了工作計畫(task planning)、日程表計畫(schedule planning)這兩個工作。而個人認為依現行開發流程，在此階段初步可以考慮只撰寫測試報告，其說明如下:

• 測試報告


測試報告主要是列出本次程式須執行的測試案例的詳細資訊和成果，其包含測試代碼或名稱(test number/name)、測試目的(test objective)、測試描述(test description)、測試條件(test condition)、預期輸出(except result)以及實際輸出(actual result) 。

三、個人品質管理

本階層主要在於提高軟體的品質，透過其所屬之工作，早期檢測出缺陷的存在，並儘早移除，此外，增加了設計樣板和設計覆審以減低設計錯誤的情形，亦增加了程式碼覆審以減少缺陷。本階段包含了兩個小流程，即PSP2和PSP2.1，其中PSP2包含了兩個工作，分別為︰程式碼覆審、設計覆審，而PSP2.1除了包含上述兩個工作外，又多包含了設計樣板(design template)。而因為開發工具的進步，所以建議捨去程式碼覆審之工作，以下就這其他兩個工作進行詳細說明:

• 設計覆審


主要是針對設計上容易產生錯誤的地方進行檢查，例如完整性、邏輯性、功能性等，透過設計覆審降低錯誤設計的可能，避免軟體產品開發完成後不符合客戶需求而須再次修改，減少了成本和無法準時交付的風險。


• 設計樣板


主要是在程式不使用物件導向(object oriented)的情形下，將一些常用的邏輯或功能設計成樣板，再依據專案需要的情況對樣板進行小幅修改，使其符合使用的狀況。這樣的機制可以減少重覆工作的情形，並降低錯誤率，尚可提高其可信度(reliability)。

四、循環個人程序

本階層主要將PSP提升至較大的專案中使用，將專案劃分成幾個階段循環開發，每個階段的開發皆使用PSP2.1去記錄。本階段包含了兩個工作，分別為︰擴展PSP(scaling up)、循環式開發(cyclic development)。而以下就這兩個工作進行詳細說明:

• 擴展PSP


主要是應用PSP至較大的專案，透過對較大的專案進行細分，使得戲分後的每一部份皆可使用個人軟體程序進行開發。


• 循環式開發


主要是將PSP的方法融入循環式開發的流程當中，使得軟體開發的每一個週期都在PSP的量測與記錄之中，透過分析於每個週期都再次的提昇軟體的品質和改善開發流程，其循環流程如下圖三(註四)。



《圖三》PSP3軟體循環開發流程圖(註四)

個人軟體程序所須蒐集的資料

個人軟體程序需要收集流程的相關資料以便進行分析，我們可以將需要收集的資料概分為三大方面，包含程式碼大小(size)、時間資料(time)和缺陷資料(defect)這三大類，並分別說明之︰

一、程式碼大小

在計算程式碼大小方面須計算預估程式碼的大小和實際程式碼的大小兩種，而實際程式碼大小又可以分為︰重複使用的程式碼大小(reuse)、新增的程式碼大小(new add)、修改的程式碼大小(modify)和刪除的程式碼大小(delete)，其組成如圖四，而其意義亦說明如下。

• 重複使用的程式碼大小


從已完成的專案和軟體中截取出部份可用的程式碼，放入至新的專案之中，而此部分的程式碼即稱為重複使用的程式碼，此種程式碼不需耗費開發人員撰寫的時間，而且缺陷發生率極低。


• 新增的程式碼大小


為專案中新撰寫的程式碼行數，其佔了開發時間的絕大比例。


• 修改的程式碼大小


針對重覆使用的程式碼進行修改，使得其更符合專案的要求，而修改過的程式碼行數即稱為修改的程式碼大小。


• 刪除的程式碼大小


將重覆使用的程式碼刪除或者刪除新增的程式碼的行數，此兩種情形即為刪除的程式碼大小。

此外，在計算程式碼大小時，必須以公司或專案規定的程式碼計算標準上的規定來計算，使得同樣的程式碼在不同人員計算下仍可得到相同結果，確保資料的正確和統一性。在使用Visual studio內建的程式碼分析(註六)0可以獲得相同的計算方式，雖然Visual studio內建的計算方式不包含註解的行數，可能會影響到後續的計算，因為註解較多的程式比較容易被重複使用及閱讀，但在此計算標準下將被忽略掉，期待以後能自訂計算標準，而現行的程式碼計算畫面如下：



1.可維護性指數：數字為0～100之間，其中0~9顯示紅燈；10～19顯示黃燈；20～100顯示綠燈。
2.循環複雜度：計算If、Switch Case、Do While、For Loop的數量。
3.繼承深度：繼承階層越多，程式的複雜度越高。
4.類別結合程度：耦合度低，表示比較可能加以再利用。
5.程式碼行數：不包含註解及宣告等，僅計算可執行的程式碼行數。

二、時間資料

時間資料的收集主要根據PSP所設計的時間紀錄表，主要記錄工作的開始時間、中止時間、中斷時間、各階段耗費的時間等。

三、缺陷資料

缺陷資料的收集主要根據PSP所設計的缺陷紀錄表，主要記錄缺陷的編號、缺陷的種類、發生的日期、植入階段等。
透過上列對三種類型資料的描述，我們可以將其歸納整理如圖六。



個人軟體程序資料分析

在個人軟體程序中如何對流程進行改善完全植基於對流程資料的分析之上，因此當我們收集完流程的相關資料之後，便須針對這些資料進行判讀與分析，透過對分析結果的了解，給予開發人員一個明確的方向以便對流程進行改善。而在個人軟體程序中的資料分析主要可分成五大部分，分別為專案彙整分析(Project Plan Summary)、缺陷分析(Defect Analysis)、品質分析(Quality Analysis)、生產力分析(Productivity Analysis)和專案規劃分析(Project Plan Analysis)。而在符合開發人員能輕易掌控的前提之下，筆者建議選取缺陷分析、品質分析和生產力分析來進行資料的分析，其詳細解說如下。

一、缺陷分析

缺陷分析主要為開發人員在專案開發過程所發生的缺陷以及其移除的相關資訊，而其分析的項目有三項，分別為缺陷密度(defect density)、缺陷植入階段(defect inject by each phase)、缺陷移除階段(defect remove by each phase)，以下就此三項分析個別敘述其內容。

• 缺陷密度


將每個專案中累計的缺陷數目與其產品碼的行數大小進行標準化的計算，即該專案每千行程式碼中會出現多少數量的缺陷數，而此數值便稱為缺陷密度。缺陷密度的變動可以提供開發人員了解其缺陷產生的趨勢，配合生產力和其他分析可以了解開發人員流程改善的效益、軟體的品質高低和開發能力的改善。


• 缺陷植入階段


統計專案中的缺陷，累計其在各個流程階段中被植入的數目，透過此項分析可以了解開發人員在何流程階段比較容易產生缺陷，進而對該流程階段進行改善，以便減少缺陷的發生。


• 缺陷移除階段


統計專案中的缺陷，累計其在各個流程階段中被移除的數目，透過此項分析可以了解開發人員在何流程階段的缺陷移除效果不佳，進而對該流程階段進行改善，以便提高缺陷被移除的機率。

透過這三項缺陷分析可以使開發人員明暸其缺陷常發生的階段和分布的趨勢，透過對缺陷資訊的了解可以增加覆審的力度或人數，亦或是測試案例的數目，依照資訊的不同而對症下藥進行改善，進而減少缺陷的產生，以提高軟體品質。同時，因移除缺陷的成本會因時間的不同而倍數增加，開發人員便可透過缺陷分析朝早期移除缺陷的目標邁進，以降低軟體開發的成本。

二、品質分析

專案開發的過程中為了提高軟體的品質，通常會採取一些工作或行為，例如對程式碼的覆審、對程式碼的測試、對設計的覆審等。而品質分析則是針對開發人員在專案開發中執行為了提高軟體品質的這些行為的成效，透過品質分析可以了解到開發人員在提高軟體品質的目的下所做的行為的效益，藉此改善其行為或工作不足之處以提高軟體品質。而此項分析亦包含了三項分析，分別為良率(yield)、品質成本 (cost of quality, COQ)和評鑑與失敗比例(appraisal to failure ratio, A/FR)，以下就這三項分析個別敘述其內容。

• 良率


良率代表的是在開發人員在設計覆審和程式碼覆審等流程階段移除缺陷的效率，其值為該兩階段流程移除的缺陷總數除以專案移除缺陷總數。高良率代表的是開發人員將大多數的錯誤都在設計覆審與程式碼覆審這兩個階段移除了，而遺留至編譯和測試階段的缺陷較少，而這樣的情形會使得開發成本降低；反之，低良率代表開發人員在編譯和測試階段需處理大量的缺陷，使得花費的時間增加，也提高了軟體的開發成本，而這樣的情形下，開發人員必須增加覆審的精細度和時間，以求將良率提高。


• 品質成本


品質成本代表的是開發人員在專案中花費在修正缺陷上的時間佔整體開發時間的百分比，也就是指修正缺陷的時間與整體時間的比值。而此處修正缺陷的時間是指包含設計覆審、程式碼覆審、編譯和測試階段所找到的所有缺陷以及修正時所花費的時間總和。而COQ的數值越高，代表開發人員耗費較多的時間在修正缺陷上，此時就需要了解其原因以便改善流程。


• 評鑑與失敗比例


A/FR所指的是開發人員在設計覆審與程式碼覆審這兩個階段花費的時間與花費在編譯和測試階段的時間的比值。如果A/FR的值大於1，表示開發人員花費在覆審的時間較多，反之則表示時間花費在編譯與測試階段較多。如此一來可明確了解到開發人員花費在各階段的時間與其移除效益。

三、生產力分析

生產力分析主要是將開發人員的軟體產出能力作一個量化的動作，使得開發人員可以跟自己進行比較，以了解流程改善帶來的影響，主要的分析指標有兩項，分別為生產力、生產力與良率和A/FR的交叉比對(productivity V.S. yield V.S. A/FR)，以下就這兩項分析個別敘述其內容。

• 生產力


生產力代表的是開發人員每小時可生產出的程式碼行數，主要是由專案的程式碼總行數除以總時數獲得。生產力可以代表開發人員在每個專案的產出變化，根據變化的不同，調整流程以達到較高的產出。


• 生產力與良率和A/FR的交叉比對


生產力與良率和A/FR的交叉比對是將生產力、良率和A/FR進行交叉比對，可以詳細的了解生產力的變化以及產品品質和覆審效能之間的相互影響，比單單只觀察生產力來說可獲得更客觀的資訊，並藉此改善流程。

除了上述提到的分析，Visual studio 還提供了效能分析，如圖七，透過執行標的程式，可以了解程式在執行上效能的障礙之處，進而針對該部分之程式碼進行改改寫或修正，提高執行速度；亦可選擇不同的函式等狀態來查看分析，並且可以比較原始版本與修改後之版本的效能之差異，提供開發人員做為再次修改之依據。



結語

個人軟體程序對現行的開發工作來講，可能無法完全的實現，但是我們可以擷取部分的資料收集與分析方式進行參考，並實作這些相關部分。透過這些分析提升我們的軟體品質和開發速度，降低缺陷的發生率，使得開發人員付出少量的精神，換取效益極大的改善。建議截取的部分包含缺陷的紀錄、計算、修正時間，與開發時間和程式碼大小的部分，根據缺陷的記錄與分析，我們可以了解到經常出錯的部分，去加強檢查和注意，甚至將其抽出成固定的函式，降低錯誤的發生率；而根據開發時間和程式碼大小，可以了解到個人對不同類型的程式的開發速度的差異，使得開發速度提升，並可加強開發人員不擅長之部分。

CMMI是目前被廣泛應用的標準，前身為美國國防部針對招標的大型專案所訂定與要求的規格，爾後經過不斷的變化，最後衍伸為CMMI，他含有許多的SG跟GG等目標和階段，並提供連續式與階層式兩種應用方式，使得專案的開發時程可以獲得掌控，亦可獲得較佳的軟體品質和提升可維護性等眾多優勢!CMMI跟個人軟體程序雖然都是提升軟體品質的最佳技術之一，但是這兩者並不相同的，CMMI的範圍較大，而且只規定各個CMMI階段該達成何種目標，而每個階層的CMMI的SG和GG底下的SP和GP是可依據需要去選擇與本身企業型態需求相符的先行執行，並依據階段式與連續式的不同，有不同的執行作法，而且CMMI並未規定需要如何去實作；PSP的做法比較類同連續式的CMMI，需要一層一層的往上，但是PSP是針對個人的軟體開發去做改善，對於團隊之間的開發，並沒有去規範到，或者有所著墨，團隊之間的開發由TSP去支援。而對於專案的管理只是做一些簡單的規劃，並沒有如CMMI著墨的那麼多!但是對於個人軟體的每個的階段都有固定的文件格式和記錄表格需填寫，對於新手來說，很容易入門，只需要按著規定的文件逐步執行即可慢慢學習。CMMI與PSP的差異主要來自於著眼的起點不同，PSP是從個人的身上開始去提升軟體的能力，而CMMI則是從宏觀的角度去規範專案的進行，簡而言之，我們可以使用CMMI為整艘船的骨架，以PSP去建造每一個元件，使得專案軟體品質持續提升。

參考資料

註一、Watts S. Humphrey, A Discipline for Software Engineering, Addison Wesley, 1995.

註二、Watts S. Humphrey, “Using A Defined and Measured Personal Software Process,” IEEE Software, vol. 13, no. 3, 1996, pp. 77-88.

註三、Personal Software Process (PSP). http://www.sei.cmu.edu/tsp/psp.html

註四、Watts S. Humphrey, “The Personal Process in Software Engineering,” In Proceedings of the 3rd International Conference on the Software Process, 1994, pp. 69-77.

註五、Carnegie Mellon University, Software Engineering Institute. http://www.sei.cmu.edu/

註六、http://www.ithome.com.tw/itadm/article.php?c=47295&s=5