軟體開發週期估算及探討(轉)

軟體開發週期估算及探討
1.概述

軟體開發週期估算是IT人員經常提到的一個概念，那麼究竟什麼是軟體開發週期估算呢?我們可以把它定義如下：根據軟體的開發內容、開發工具、開發人員等因素對需求調研、程式設計、編碼、測試等整個開發過程所花費的時間做的預測。在這個定義中，“預測”兩個字非常關鍵，它突出體現了估算的含義，同時也隱含表明了結果的不確定性。有效的軟體開發週期估算在軟體開發中是非常困難的工序之一，之所以說困難，是因為軟體開發所涉及的因素不僅多而且異常複雜，即便是及其類似的軟體專案也不能完全照搬，在估算的把握上有一定難度。估算也是軟體開發中很重要的一個環節，如果低估專案週期會造成人力低估、成本預算低估、日程過短，最終人力資源耗盡，成本超出預算，為完成專案不得不趕工，影響專案質量，甚至導致專案失敗。專案週期估計過長表面看來影響不大，但是實際上也會帶來成本估計過高，人力資源利用不充分效率低下的後果。無論哪種情況對於專案經理控制整個專案都會帶來很大影響，週期估算如同蓋樓房中打地基，是後續工作的基礎，它完成質量的好壞所帶來的影響會貫穿整個專案，由此可見開發週期正確估算的重要性。

2.國內外軟體估算比較 國內軟體開發的管理目前正逐步向規範化發展，但是在開發週期的估算上絕大部分還是處於手工作坊的狀態。所謂的手工作坊指兩個方面，一方面是管理人員意識上沒有認識到估算的重要性，認為估算就是一個大概的估計，很多還受限於商業行為，比如為了簽訂合同而不惜減少開發工作量卻未經任何評審；另一方面也沒有專門的工具來輔助估算，或者說沒有專門對它進行研究。一個軟體開發週期究竟要多長基本上是依靠經驗來判斷，不同經驗的人估算出的週期相差很大，而更糟糕的是這種開發週期的判斷由於完全憑藉經驗使得不同意見的人之間很難溝通，因為誰都沒有確切的量化標準來支援自己的判斷，最終的結果往往是以“專家”的估算為準。這就有些類似於中式烹調，放多少作料沒有依據，一般都是“少許”，這個“少許”靠的就是經驗，高階廚師和新手根據這個量炒出的菜味道可能差得很遠；實際上國內的軟體開發需要的正是定量估算，這樣做不僅規範而且精確，十分有助於軟體事業的健康發展以及與國際接軌。

國外已開發國家在軟體估算上比國內要成熟的多，不僅有很多先進方法比如程式碼行估演算法、功能點估演算法、人力估演算法，而且形成了專業化的估算工具來輔助這項工作，比如微軟公司開發的專案管理工具軟體Project，加拿大Software Productivity Center Inc.公司開發的Estimate，都是比較成熟的估算輔助工具。Project採用了自下而上的估演算法，Estimate更是屬於專業化工具，包含常用的各種估算方法、校正方法，使用了Putnam Methodology、Cocomo II和 Monte Carlo Simulation幾種成熟演算法，估算結果除了專案花費時間、人力，還包括十幾種分析報告以及模擬發散圖、計劃編制選項圖、人力圖、預計缺陷圖、缺陷方差圖等等，從各種不同角度輔助管理人員進行分析。

採用輔助工具對軟體開發週期進行估算具有明顯的優勢，這些輔助工具是在大量不同型別專案資料研究的基礎上總結開發出來的，採用的演算法、估算的方法已經很成熟，估算結果的準確性有保障，由於這種估算是可以量化的，並非依據個人經驗直接得出一個結果，在結果的評審上有據可依。長期依靠工具輔助估算可以將大量專案的資料和估算結果積累形成歷史經驗庫，知識成果得以儲存，便於以後利用。

3. 軟體估算中的因素探討
軟體開發是一項非常複雜的工程，不僅包含需求分析、設計、編碼、測試、實施、維護等完整的過程，還涉及到開發工具、開發人員、專案管理、風險等眾多因素，不同因素對估算產生的影響不盡相同，在進行軟體估算時（包括利用工具輔助估算）必須考慮到這些方面，否則最終結果就會和實際結果有很大的偏差，影響專案控制，以下對其中幾個常見的因素做一些探討。

3.1估算與軟體規模
軟體規模通常指的是軟體的大小，這可以通過不同的方式來描述，比如程式程式碼行的長度、功能函式的數量、資料庫中表的數量、資料庫的大小等等。一般而言軟體規模越大，所花費的開發週期就越長，但這並不是一個簡單的線形函式關係，下表詳細列舉了實際開發中的一些資料，開發平臺為Lotus Domino/Notes。

表一
單個模組的開發週期

序號 模組 開發週期（中級程式設計師） 程式碼行長度 資料庫大小(無資料)
1. 辦事指南 0.25人月 300 1170K
2. 名片簿 0.25人月 300 1039K
3. 合同管理 0.25人月 460 2110K
4. 物控管理 0.5人月 850 2560K
5. 組織機構 0.5人月 900 1318K
6. 流程管理 0.8人月 1000 2304K
7. 公告板 0.5人月 1400 2560K
8. 人事管理 1人月 1800 3840K
9. 公文管理 1.8人月 2500 2304K
10. 事務審批 1.5人月 3750 2110K
11. 考勤管理 1.8人月 4800 3840K
12. 資源管理 1.8人月 5800 3840K
13. 會議管理 2.5人月 11000 4608K

表二
軟體專案的開發週期

軟體專案 開發週期 包含的模組 備註
某政府客戶 3個人月 10個 定製開發量較小
某媒體客戶 6個人月 17個 有3個模組完全重新開發
某金融客戶 10個人月 14個 80%完全重新開發
某保險客戶 16個人月 18個 完全重新開發

從表一中可以看出，模組的程式碼行越長，開發週期就越長，對同一開發工具而言基本是一個線形關係，但其中也要考慮程式碼重用問題，比如一個模組程式碼很長，但是可能包含了很多公用函式，那麼在估算時就應適當減少程式碼行數量，表中會議管理就是個例子，這個模組的程式碼行超過一萬行，但其中公共函式很多，去除此因素，真正的程式碼行在9000行左右。

表二是軟體專案的實際開發週期（不考慮系統實施），從普通意義上說軟體專案中包含的功能模組越多、越複雜，或者說軟體越大開發週期增長的就越快，這個時間絕不是模組開發時間的簡單疊加，因為模組功能數量的增加直接帶來了軟模組間相互關聯度、複雜度的成倍增加，這就直接導致了在需求、設計等階段需要花費更多的時間，這比單獨考慮一個模組複雜的多。在表二中隨著模組數量增加，開發週期增加不是特別明顯，這是因為產品化程度高所引起的，由於相當數量的模組可以完全重用，實際開發量大大減少，最後一個例子完全重新開發，開發週期就長的多。

在實際進行軟體開發週期估算的時候，軟體規模肯定是首先考慮的因素，根據我們上面所討論的情況，在考慮軟體規模時一定要去除可重用的部分，由於當今軟體在設計上很重視這點，所以這部分會佔相當的比重。另外軟體功能之間的關聯所造成的複雜性必須足夠重視，這樣在估算上就不會產生重大偏差。

3.2估算與專案風險
任何一個專案都或多或少存在風險，軟體專案開發過程中也避免不了這種情況而且有這類專案自己的特點，最常見的風險有以下幾種：技術風險，專案技術難度很大，花費的時間超過原先的估計；客戶風險，客戶需求不定，增加需求，組織協調不暢；人員風險，開發人員突然更換、離職；管理風險，專案經理管理不善、決策失誤。對於風險控制，在專案管理中通常是提前做風險分析和預測，制定風險應對措施，這樣在風險真的來臨時不至於措手不及，提高整個專案的可控性。

軟體專案的潛在風險對於開發週期的影響在很多情況下是非常大的，當然好的專案控制會最大限度的減少這種影響，絕對避免是不可能的，所以在開發週期估算時專案風險應該適當考慮，尤其是技術風險和客戶風險。

技術風險主要來自於軟體本身的技術難度，如果對於一套成熟的產品，定製開發的技術風險相對非常小，因為重要的技術已經成型，客戶也很少有新的能帶來高難度技術問題的需求，這種風險可以不予考慮。但是對於完全重新開發的專案，或是研發類的專案，技術風險必須特別重視，其中應該考慮的細節主要包括下面幾個。

開發平臺，是否能適合本專案所涉及的軟體開發、能否滿足最終的需求，平臺的錯誤選擇將導致龐大的開發工作量，即便滿足了使用者需求也可能造成系統效率低下，擴充套件性差的致命問題，軟體可能會很快被淘汰。功能實現難度，在切實瞭解需求的基礎上要仔細分析採用的開發工具能否實現其中的難點，是否會耗費大量時間。

在實際估算中，建議技術難度分為十級，每一級在初次估算的程式碼行上增加10%，最終估算程式碼長度=初始估算程式碼長度×(1+0.1×n)。假設模組A的初次估計程式碼行為15000行，但考慮技術難度高的風險，設定技術難度級別為二級，最終程式碼行的估算數量為15000X(1+20%)=18000。

由於技術風險的分析是一項技術性很強的工作，要求做技術風險分析的人必須是技術專家，在相關技術領域有著豐富的經驗，對重大技術風險的分析結果必須要經過評審，保證準確性。

客戶風險存在於客戶化專案中，不同行業的客戶特點不盡相同，技術、理解水平也相差甚遠，在我經歷開發的專案中，80%的專案延期屬於客戶方的原因，而且這種風險可控性很低，對專案影響超過技術風險。在開發週期估算前，專案經理要仔細分析客戶的具體狀況，包括客戶的計算機水平、管理水平、可溝通程度，在此基礎上結合以往的經驗綜合判斷是否會對開發帶來明顯的影響，可以按照上述的技術風險的方式將客戶分級，最終確定開發週期。在這個過程中，專案經理的經驗極其重要，對客戶的分析基本上要依賴經驗做判斷，要求管理人員有大量的客戶經驗和行業分析能力。

3.3估算與人力資源
對於軟體開發專案來說，人力資源是核心力量，因為軟體開發不同於其它型別的專案，除了電腦它不需要利用其它工具，最終結果的產生完全取決於人腦中的知識，這也是知識經濟的最大特點。

人力資源對估算的影響表現在技術水平、理解能力、溝通能力等幾個方面，程式設計水平的高低、速度的快慢、能否適應團隊、能否與各成員保持良好的溝通都會對開發進度產生影響，其中技術水平是最關鍵的因素。評價程式設計師的技術水平可以從程式設計熟練程度、程式設計速度、解決技術問題的能力幾個因素考慮，程式設計熟練程度指的是程式設計師能否很順暢的使用程式設計工具實現軟體的功能，程式設計速度指的是完成某個功能的時間，解決技術問題的能力可以反映程式設計師在遇到技術難點時表現出的技術功底，如果以100%作為總和，這三個因素分別佔70%、15%和15%這樣的比例。

軟體開發週期估算前，應對開發人員定級，建議按新手、初級程式設計師、中級程式設計師、高階程式設計師來劃分，每一級人員再評定上述三個因素，初次估算時可以假定開發人員為中級程式設計師，然後依據專案組實際人員的水平做修正，這樣結果的精確度能大大提高。

4. 歷史資料估演算法的運用
依據歷史資料估算軟體開發週期是一種比較常見的方法，這種方法以歷史軟體開發週期為依據，在估算時把當前軟體專案的情況與歷史資料加以對比，從而得出最終結果。按照歷史資料估算開發週期準確度還是相當高的，但這種方法只適用於對某類軟體的開發，比如某個行業業務系統的開發，當要估算的軟體與歷史軟體相差太多，比如開發工具完全不同，或者型別完全不同，就不能再依賴這種方法，最起碼應該輔助使用其它估演算法。如果沒有歷史資料或是開發一種新領域軟體，可以使用程式碼行或功能點估演算法，在此基礎上再通過其它方法校正。

事實上目前專案管理人員對開發週期的估算大部分屬於人力時間估演算法，憑藉的是自己的經驗，經驗越多估算的結果就越精確，但是大部分專案管理人員對以前很有價值的歷史資料缺乏歸納整理，估算的時候憑藉感覺的成分多一些，所以精確度相對要低很多，所以要求我們的專案管理人員不僅要有大量軟體開發的經驗還要不斷總結積累，歷史專案資料對於以後軟體開發週期的估算是非常有價值的。

在實際使用歷史資料估演算法時，建議專案經理建立一個歷史專案資料庫，在庫中包含以前所有專案的開發週期、專案規模、開發人員狀況、客戶狀況等詳細資料，當估算時根據當前專案的狀況在庫中尋找最類似的歷史專案，然後再比較兩個專案之間在專案規模、專案風險、人力資源之間的區別，我們假定歷史專案開發週期為A當前專案的週期可以依據下列公式得出

B=A×(2×S+R+P+2×C)/6

S：代表軟體規模 R：代表風險 P：代表人力資源 C：代表客戶

以上值均指當前專案與歷史專案的比率。

實際的比較因素應該不止這些，但軟體規模、風險、人力資源及客戶狀況是其中最重要的，對軟體開發的影響也最大，所以這個公式中只考慮了這些因素。其中軟體規模和客戶兩項佔的權重最大，這也是根據專案管理經驗得出的，在實際使用歷史資料估演算法時還可以靈活加入其它因素。

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