專案規劃
前言
專案規劃（即擬訂計畫）是軟體發展過程的第一步，正如所有任務的執行，都必須要有個計畫指引一樣。專案規劃的主要目的有二，一是事先評估整個專案所需的人力資源與時程，一是製訂整個專案執行的過程。而本文的目的，便是用來說明如何擬訂一個有效的軟體專案發展計畫。
邱奕南，2009/9/24
一、專案目標
每一個專案的成立，都有其確立的目標，亦即專案所應呈現的結果，因此軟體發展管理者的首要工作，便是了解整個專案的成立背景、原因，將目標一項一項地明確標示出來。目標標示得愈清楚詳盡，計畫所引導的方向愈不易有所偏差。通常目標中，除了明確寫出客戶所想要達成的目的外，最好也標示出專案軟體所必須達成的品質特性，這些品質特性共計有２４項，並可區分成下列六大類：
其他如可測試性、可行性、必要性等品質特性，多為必要特性，此處無需列出。
二、專案範圍
目標確立之後，接下來便要訂定專案的範圍，亦即專案所應完成的內容，因為之後人力、資源、時程、成本的評估，都必須靠專案的範圍來加以限制。範圍愈不明確，評估的結果便愈不準。不幸的是，在未經過需求收集與分析的階段，專案範圍通常都是模糊不清的，以致評估的結果往往會有很大的誤差。在一般的情況下，我們可以將專案計畫延至需求分析階段結束後再加以擬訂，也就是軟體發展計畫中同時包含了需求規格書的內容，此時因為需求已相當的明確，評估的結果也比較正確些。只是並非所有的專案計畫都可以延至需求分析階段完成時才擬訂的，尤其在大型專案上，需求分析階段也必須配予適當的人員、資源和時程，此時便必須在還沒展開需求收集與分析前，即先行擬訂出軟體發展計畫。
由於在需求收集與分析階段完成時，還必須再依據需求分析的結果，做一次更精確的人力、資源、時程、成本估算，因此在本文中，我們便假設在擬訂軟體發展計畫時，其需求範圍並不明確。在這種情況下，我們只能就現有資料進行初步與概括性的範圍定義，不過至少應包括系統所應具備的功能，以及系統執行時所要求的軟硬體環境、語系等。如果有任何已知可能的需求，最好都列在計畫範圍之中，若需求限制不明確，便儘量以最大範圍定義之，因為在經驗上，實際需求往往都比預期需求都還來得大。
三、專案過程
製訂整個軟體專案的發展過程，是專案計畫中的一項重頭大戲，因為在計畫擬訂之後，整個專案組織便會開始依照計畫中的過程運作起來，而這個過程一旦變更，往往會牽動整個專案組織與任務的變動，其影響是頗為深遠的，因此在製訂發展過程時，一定要謹慎熟慮。
製訂專案發展過程通常有兩個步驟，第一是挑選軟體發展過程模式，第二是仔細訂出各個過程階段所要執行的任務。挑選軟體發展過程模式，必須視專案的性質而定，不過大部份都會採用下列的過程模式：
決定過程模式之後，便要訂出過程中各工作階段以及其任務內容。製訂的愈詳細，在專案管理與人力時程評估上便更容易精確。一般多採用過程分解法，將較大的過程逐步細分成較小的過程，而逐漸定義出應執行的任務內容。不過對於專案過程中有許多不確定因素，如緊急任務岔斷、技術可行性不明確等，這時要在專案初期即決定各工作階段之詳細任務內容，事實上是有困難的。在這種情況下，我們可運用螺旋模式，將整個過程區分成數個螺旋循環階段，而當各螺旋循環階段進入其計畫任務區時，便開始計畫訂出整個螺旋循環階段，所應執行的詳細任務。這種做法，其實便是將專案計畫所應訂出的詳細過程與任務，分散到數個可分割的工作階段計畫中，不過必須輔以適當的風險評估與管理，以免這種延後處理機制導致專案失控。
舉例來說，假設有一個需求不十分明確的軟體產品專案，同時可運用技術尚不成熟或暫時無法評估其可行性，則可利用螺旋模式＋瀑布模式，將整個開發過程分成收集需求範圍、確立功能架構、軟體產出等三個螺旋循環階段，每個螺旋循環階段再分成計畫、風險評估、製作、審核等四個任務區：
又假設這個產品專案有時程的壓力，則可將軟體產出的螺旋循環階段再拆成多個，分批產出各種版本的軟體產品（螺旋模式＋階段性交付模式）。不過要注意專案計畫中的過程，並不僅限於軟體的開發過程，舉凡與專案相關的過程，如軟硬體的採購、外包管理、輔導上線、教育訓練、包裝、驗收等等都必須納入。
四、人員組織
五、資源
在專案計畫中，除了人力資源外，還必須列出要完成專案所需的環境資源，包括軟體、硬體及工具。如果有任何可再用的資源，也應該加以列出，例如可直接使用的軟體元件、和本專案具有相同經驗的文件或軟體、和本專案有部份相同經驗可供參考的文件或軟體等。
六、預估時程
時程的預估，是整個專案計畫中最難的部份，因為精確的開發時程和專案內容與參與人員（包括客戶）都有關，其中又以人的因素最不可控制。如果再加上沒有明確的需求規格（即專案內容），整個時程估算出來的結果便會有相當大的誤差。但是不管有多大的誤差，時程與成本都還是必須加以估算，以做為計畫執行時的一個參考基準，因為有許多相關的作業都必須基植在這個預估時程上。不過愈精確的時程預估，其價值愈高，因為許多後續的作業，例如產品的發表與促銷、下個專案的啟動等等，都必須靠這個預估時程來準備安排。誤差愈大的時程，所造成的後續影響與銜接成本便愈高。因此我們所要做的，便是儘量將預估時程的誤差，控制在一定的比例範圍以內，同時也要把這個誤差比例值估算出來。
時程的預估，必須儘量基植在可理解的數理運算上。例如假設整個專案的工作量（或稱複雜度）為jc，所有專案人員每日產值總和為ed（即工作量／日），則整個專案所需的時程便是jc/ed。這個例子所使用的預估方式其實是很粗糙的，因為整個專案過程中，並非所有人員都會同時投入，但從中我們大略知道，要準確預估出一個專案的時程，首先便必須準確預估出整個專案的工作量，以及每位參與人員的平均產值，任何一邊有所誤差，都會影響到預估所得結果。以下我們便開始介紹各種預估時程的方法。不過在說明前應先了解，各種數量的評估應結合統計學的方法來減少誤差，最常用的方式便是三點評估法：
期望值 = (樂觀值 + 4*最有可能值 + 悲觀值) / 6
（一）以程式大小進行預估
也就是以預估的程式行數來估算時程，適合在功能與技術都不複雜、而程式撰寫階段特別耗工的專案上。這種方式的優點是容易估算，而且有相當多的文獻和資料可供參考，缺點是易受不同的程式語言與技術複雜度所影響，準確率較低。
要精確預估出專案的程式行數，是需要有許多經驗值做參考的。一般的做法是將各種不同的細項需求或功能模組予以歸納分類，再以某種定性描述決定複雜等級，之後便是在歷史專案中統計出每一細項需求或功能模組，使用同一種程式語言所需的程式行數（必須包括最小值、最大值與平均值），如此當新的專案要估算程式大小時，便可到歷史資料庫中比對相同等級的需求功能，找出合適的程式行數來。如果沒有任何歷史資料可供參考，便只能憑藉自己的經驗法則來預測，只是這樣一來，它的正確性便會大打折扣。
預估出程式行數後，便要採用某種經驗評估模式來計算所需的人力月。以下便是最典型方式：
E = a + b*KLOC^c
其中
E = 專案所需人力月
KLOC = 程式行數（Line of Code），以千行為單位
a, b, c = 經驗參數，由歷史資料推得修正，每種專案類型應有一組經驗參數對於尚無歷史資料的情況下，也可先套用別人已分析出來的經驗參數值，不過因專案類型會有某種程度的誤差（即使是下列已被提出的各種模式，其結果相同的情況也是極少）：
- Walston-Felix模式：E = 5.2*KLOC^0.91
- Bailey-Basili模式：E = 5.5 + 0.73*KLOC^1.16
- Boehm simple模式：E = 3.2*KLOC^1.05
- Doty模式：E = 5.288*KLOC^1.047，其中KLOC > 9
其他還有軟體方程式模式、建構成本模式（Constructive Cost Mode，簡稱COCOMO模式）等經驗評估模式。COCOMO模式較為複雜，在本文中便略而不提，以下只提出一個軟體方程式模式的例子供做參考：
t = 8.14*(LOC/P) ^0.43，t>6
E = 180*B*(t/12)^3，E>=20其中
B = 特殊技能因素。KLOC<=15時，B=0.16；15<KLOC<=70時，B=0.28；KLOC>70時，B=0.39。
P = 生產力參數。即時性嵌入軟體，P=2000；電訊或系統軟體，P=10000；科學軟體，P=12000；商用軟體，P=28000。不過使用這些已被提出的經驗評估模式時要有個認知，那就是必須經由自己控管的歷史專案結果，來導出更適合自己研發團隊的經驗參數值，否則評估出來的時程，誤差仍然會很大。
（二）以功能複雜度進行預估
這種預估方式，是將功能的複雜度以某種計算方式，轉換成功能分數，然後再依功能分數來預估時程。它的好處是在沒有太多歷史資料的前提下，仍能有效地估算出來，缺點是估算的結果較為主觀，而且在專案完成後，很難計算得到精準的功能分數，做為回溯分析使用，以改善下次的評估結果。
功能分數的計算，有基本型、特徵分數（feature points）、和3D功能分數等多種，其中基本型的功能分數最常被使用，也存有許多現行可用的經驗評估模式，但3D功能分數則較為精確。以下首先說明基本型的功能分數算法。它是針對軟體所需的功能，依照功能處理時，所需的資料輸入數（number of user inputs）、資料查詢數（number of user inquiries）、資料輸出數（number of user outputs）、檔案數（number of files）、外部界面數（number of external interfaces）等五個部份，依其複雜度分別乘上一個數字，最後再加總起來，便是該功能的功能計數。其中所應乘的倍數如下：
- 資料輸入數：簡單時x3，一般時x4，複雜時x6。
- 資料查詢數：簡單時x3，一般時x4，複雜時x6。
- 資料輸出數：簡單時x4，一般時x5，複雜時x7。
- 檔案數：簡單時x7，一般時x10，複雜時x15。
- 外部界面數：簡單時x5，一般時x7，複雜時x10。
將功能計數換算成功能分數（Function Points，簡稱FP），則以下列公式計算：
FP = 功能計數*(0.65+0.01*ΣF(i))
其中F(i)的值是回答下列14個問題所得的複雜度調整值，每個問題由值0到5，分別表示無影響、偶有影響、少量影響、中度影響、重要的影響、本質上的影響：
- 系統是否需要可信賴的支援及復原？
- 是否需要資料通訊？
- 是否有分散式的過程？
- 效能是否不足？
- 系統是否在一個現有的、高使用率的作業環境下執行？
- 系統是否需要線上資料？
- 所需的線上資料的輸入互動是否建立在多重螢幕或操作上？
- 主檔是否可以線上更新？
- 輸入、輸出、檔案或需求是否複雜？
- 內部過程是否複雜？
- 程式碼是否規劃為可再用形式？
- 轉換及安裝是否包括於規劃內？
- 系統是否規劃為可供不同的組織進行多重安裝？
- 應用程式是否被規劃為能讓使用者易於改變及使用？
得到FP以後，我們便可以使用前述最典型的經驗評估模式來計算所需的人力月：
E = a + b*FP^c
以下則為一些已被提出的模式：
- Albrecht及Gaffney模式：E = -13.39+0.0545*FP
- Kemerer模式：E = 60.62*(7.728*10^-8)*FP^3
- Matson、Barnett及Mellichamp模式：E = 585.7+15.12*FP
由於基本型的功能分數主要都是考慮資料的處理部份，因此3D功能分數便改以資料維度（data dimension）、功能維度（function dimension）、控制維度（control dimension）來計算功能分數：
- 資料維度：和基本型的功能計數方式完全一樣，只是直接將功能計數視為功能分數。
- 功能維度：指輸入處理成輸出的步驟數目，依步驟的複雜程度與數量，決定功能維度的複雜度。簡單時x7，一般時x10，複雜時x15。
- 控制維度：指計算時，狀態轉換的次數，不必乘上任何值。
將上述三個維度計算所得的值相加，即為該功能的3D功能分數。
（三）以經驗與能力對比模式進行預估
這種方式主要是利用專案人員的經驗來預估時程，由於主觀性較強，且各人的能力亦有強弱，故必須再經由能力對比模式進行修正。首先由一到多位專案人員評估由他自己單獨來完成該工作時需要多少天，然後乘上該專案人員的產能值，得到該工作的預估工作量，最後除以實際執行人員的產能值，即為預估的時程。當專案完成後，須再按實際執行的天數反推並修正各人員的產能值。
能力對比模式亦可結合至實際的研發管理，達到精確量化控管時程的目標，並可使預估的時程更加準確。其中主要的兩個數據，其意義為：
- 工作量：每件工作都賦予一個預估工作量。可利用多人評估，取其期望值，以減少預估工作量的誤差。
- 產能值：即人員每天可完成的工作量。可取一季或一年，各人員的平均產能值，回饋做為其新的產能值，以削減預估誤差。
其中的產能值，即為人員的績效，在工作進展的過程中，可隨時進行統計，以產生人員／團隊／部門每日績效走勢圖，供做管理與獎懲的參考。當專案人員變動時，也很容易重算出新的時程。
除了前述兩個數據外，還有一個管理用的數據：產值比，亦即各人員每單位薪資每日可完成的工作量。理論上，各人員的產值比應儘量相等，以達到做得多領得多、做得少領得少的目標，減少同工不同酬的爭議。
此種以量化績效為導向的管理模式，可以簡化許多管理的工作，不必去考量人員是否遲到早退、加班、懶散等問題，只看人員是否達成績效即可。此外，當人員因某些因素干擾工作，導致績效突然大幅滑落，也容易從績效走勢圖中看出，提醒主管應主動去關心。在作者的實戰經驗裡，已驗證確實是一種相當良好的管理模式。
（四）由過程任務預估
這是目前最常用的時程評估方式。它主要針對專案的整個開發過程，區分成多個細項任務，然後再針對各細項任務，評估所需的時程，最後再加以總和起來。估算的方法可以使用前面三種預估方法進行，若各方法預估的結果有著合理的近似程度，便表示該評估結果的可信度很高。 或是利用統計學原理取其期望值，以降低評估誤差的比率，提高評估結果的可信度。
七、估算成本
如果前面時程的評估結果精確的話，那麼將它拿來估算人力成本，便很容易了，只要將人力工作月乘上專案人員月成本即可。不過由於每個專案人員的成本都不同，因此利用過程任務所得時程來估算，會比較正確些。
在估算成本時，並不單只是專案人員薪資而已，還包括他的社會福利支出、辦公室租金、電費水費、器材耗損費、交通費，以及專案中所需的材料費、人事管理成本、採購成本、前置作業成本等等，最後還有專案所應得的獲利與營業稅。這些都必須估算進去，否則將會損失而不自知。一般比較簡單的估算方法，便是將人員薪資乘上2～3倍做為人員月成本，這是經由統計出來最可能的成本範圍。
參考文獻