密級：內部公開
文件編號：vts_pp_regu_jhbggc
版本號：v1.0
專案估算規程
xx****
xx****對本檔案資料享受著作權及其它專屬權利，未經書面許可，不得將該等檔案資料（其全部或任何部分）披露予任何第三方，或進行修改後使用。
檔案更改摘要：
目錄1. 簡介 1
1.1. 目的 1
1.2. 適用範圍 1
1.3. 術語表 1
1.4. 參考資料 1
2. 概述 1
3. 過程描述 1
3.1. 角色與職責 1
3.2. 准入 1
3.3. 輸入 2
3.4. 過程描述 2
3.4.1. 獲取歷史資料 2
3.4.2. 估計軟體規模 2
3.4.3. 估計工作量 3
3.4.4. 估計成本 3
3.4.5. 估計關鍵資源 3
3.4.6. 估計關鍵路徑和關鍵依賴關係 4
3.4.7. 制定進度表 4
3.4.8. 階段詳細估計 4
3.4.9. 形成《專案資料估計表》 4
3.5. 輸出 5
3.6. 准出 5
4. 附錄 5
4.1.1. 歷史資料估計方法 5
4.1.2. delphi 估計方法 6
4.1.3. pert sizing technique估計方法 7
4.1.4. 工作量估計的方法 7
4.2.1. 開發工具係數 9
4.2.2. 規模係數 9
4.2.3. 生產率 9
4.2.4. 軟體工程工作量階段分布 10
1. 簡介
1.1. 目的
本文件的目的是為了描述對專案軟體產品的規模、工作量、成本、關鍵資源和進度等進行估計，描述了估計的步驟和過程。
1.2. 適用範圍
本文件適用於公司的所有軟體專案。
1.3. 術語表
無。1.4. 參考資料
cmmi for development, version 1.2 cmmi product team
2. 概述
每乙個專案都要進行估計，並將估計的結果作為專案計畫的基礎。估計是專案計畫的核心。目的是為專案建立合理的預算，確定合適水平的員工，並為專案承諾提供基礎。
乙個沒有建立在合理估計基礎上的計畫會提供一種錯誤的安全感，可能比根本沒有計畫更糟。
估計的內容通常包括：規模、工作量/成本、關鍵資源、關鍵路徑和關鍵依賴、進度表等。
估計和計畫貫穿了整個專案。在專案的早期階段，使用自上而下（top_down）的方式進行粗略的估計和制定進度表。隨著專案的進展，在每個詳細的計畫階段，使用自下而上（bottom_up）的方法為子階段進行更詳細的計畫。
下一階段的底層wbs元素必須定義，並在wbs中進行記錄。先對wbs的底層元素進行估計，然後彙總到較高層，用來更新總的軟體估計。軟體估計的流程如下：
圖表 1 軟體估計流程
本文提供了幾個估計方法及相關過程，它們主要應用於公司的軟體專案規模、工作量及成本、關鍵計算機資源等的估計。如果這些估計方法不適用於特定的專案，專案經理必須為該專案提出另外的估計方法。
3. 過程描述
3.1. 角色與職責
● 專案經理：組織進行軟體估計。
● 專案組：在專案經理組織下，共同完成專案的各項估計。
● 相關人員：主要是指對本專案情況較熟悉的人員。
3.2. 准入
● 確定了專案範圍
● 完成了專案工作結構分解
3.3. 輸入
● wbs工作結構分解
3.4. 過程描述
4. 獲取歷史資料
為專案估計、度量的量化目標提供支援。詳細參見公司財富庫中歷史資料。
5. 估計軟體規模
規模估計的目的是為了判斷待開發軟體產品的規模，規模是成本估計、進度估計的基礎，為了估計成本和進度，所以必須進行規模估計。wbs是軟體規模估計的基礎。
我們常用的估計整個軟體產品的規模的單位是：
功能點（fp）。
**行（loc）。
其它：如交易數量、表數量等。
有時需要估計個別軟體工作產品的規模，一般採用以下單位：
頁：用於估計技術文件規模。
字數：用於估計技術文件規模。
測試用例的個數：用於估計測試規模。
估計軟體產品的規模主要依靠過去相關的經驗，估計人員應當具有相似系統的開發經驗，利用自上而下（top-down）或者自下而上（bottom-up）方式進行軟體規模的估計。具體步驟如下：
1) 將軟體工作產品拆分成能實現精確估計的較小部分。
2) 分析軟體產品的wbs。
3) 選擇合適的度量單位。
4) 選擇估計方法，結合選擇的技術解決方案（開發工具、語言、平台等），對wbs中的產品功能進行估計。
5) 估計方法可以是歷史資料估計方法，或者delphi法。
6) 在專案策劃過程中，評審和修正有關軟體規模估計的問題，對軟體產品的估計達成一致。
7) 將規模估計的結果記錄到《專案資料估計表》及《專案計畫》中。
6. 估計工作量
完成專案規模估計後，應該確定完成這些工作需要的時間（以工時為單位），專案經理應該使用模型、歷史資料和軟體工作產品大小來確定專案工作量。
工作量估計的內容應當包含以下內容：
1) 軟體開發工作量，包括需求分析、設計、編碼、測試、其它技術文件。
2) 專案管理活動的工作量。
工作量的估計可以按以下步驟進行：
1) 選擇估計方法。
2) 對wbs中的每個任務分別進行估計。
3) 對於軟體開發等工作，可以根據估計的規模和經驗資料值進行換算。
4) 估計cm工作量近似於軟體工作量的 6~10%。
5) 估計qa工作量近似於軟體工作量的 8~12%。
6) 估計出專案管理活動的工作量，近似於軟體工作量的15%~20%。
7) 估計評審工作量近似於軟體工作量的5％。
8) 估計培訓工作量近似於軟體工作量的3％。
9) 將估計的結果記錄到《專案資料估計表》中。
7. 估計成本
估計出工作量（工時）後，應根據公司的財務要求，進行成本的估算。估算的內容有：
人力成本：人力成本（按月）*（工作量/8/22）。
直接費用：直接可以報銷的費用，如培訓費、車費、活動費用等。
8. 估計關鍵資源
專案經理應該明確完成專案所需的關鍵資源，並進行關鍵資源估計。關鍵資源可以是伺服器環境、測試環境、目標環境等，也可以是識別出來的關鍵的專案組內外人力資源等。
估計關鍵資源的步驟如下：
關鍵資源是在軟體開發和操作中受到約束的硬體資源和人力資源，前者如：計算機記憶體、磁碟容量、網路容量、處理器效能等；後者如專案的關鍵人員，包括專案組的，相關組的，以及客戶。專案經理根據專案要求確定關鍵資源的約束。
如果有關鍵資源，則要估計軟體開發或執行中的資源狀況。
與估計的軟體規模、計畫的處理負載、預計的資料量、或其他因素相聯絡，來估計所需的資源的總量，作初始估計。
當初始估計做好後，應對每一項資源建立一定的儲備。
將估計的關鍵資源記錄在《專案計畫》「關鍵資源」列中。
9. 估計關鍵路徑和關鍵依賴關係
專案經理和專案組的相關人員、qa負責人、cm負責人、相關組負責人根據各活動間的關係確定關鍵路徑和關鍵依賴關係。
10. 制定進度表
進度表的制定可以按以下流程進行：
1) 專案經理和各負責人根據估計的工作量和關鍵依賴關係確定每個活動的起止日期。
2) 根據第1步的結果，結合資源的具體情況，專案經理和各負責人調整任務的起始日期、終止日期，甚至是調整某些任務的負責人和關鍵路徑。（如：通過第1步的結果，發現某些專案人員在某個時間段內工作超負荷，而有些人員在某些時間段內工作量不足，這樣就需要調整。
若實在調整不了，就有可能會調整關鍵路徑）。
3) 專案經理在專案進度表中要安排里程碑點（里程碑點一般選在有特定意義的階段點，如重要階段的開始或結束），並形成進度表的草稿。
4) 將形成的project草稿提交給專案組的成員或負責人，得到他們的承諾或根據他們的意見進行修改，直至達成一致。
5) cm人員和qa人員根據達成一致的進度表，確定自己的日程安排。
注意：返工的問題：軟體專案中的返工工作量是較大的，即在發現工作產品缺陷時的修改工作。一般來說，應在每個階段為返工的工作留出時間，做任務安排。
有些專案較緊急，要求專案成員加班進行工作。對於這種情況，制定進度表一定要小心。因為若有特殊情況或某項關鍵任務估計得過於樂觀，會導致專案進度拖延，而無法再用加班的方式進行彌補。
管理活動的時間占用問題：專案經理根據軟體估計中的管理估計和一些技術方面的交流活動的估計，確定專案各成員在各個階段可以真正用於完成技術任務的時間。如：
在編碼階段，某專案成員每週工作40小時，但評審、專案會議以及一些技術方面的交流、培訓就占去了18個小時，那麼在安排該專案成員的技術任務時，只能按照他每週工作22（40－18）個小時去安排。
專案估算表
概算價值 萬元 序號工程或費用名稱 建設費用單項費用 一總建築面積 合計單價或費率備註 二建安工程及室外工程費用1 建築工程 場地平整及土石方工程 專案主體工程2 安裝工程 電氣工程 空調通風工程 給排水及消防工程 電梯工程3室外環境工程 道路廣場工程 環境綠化工程 室外給排水工程 室外電氣工程三建...
軟體專案價格估算辦法
軟體專案 評估書 資訊科技飛速發展,計算機軟體交易市場日趨成熟規範,我方參照 軟體開發和服務專案 構成及評估方法 以及,目前國際上通行的也比較科學的估算方法是採用功能點分析方法,使用此方法能夠真實 準確地計算出計算機軟體的價值以作為市場交易 的參照依據.1.評估公式 專案建設費q 諮詢服務費p 專案...
建設專案投資估算方法分析
key words investment estimate，construction investment interest incurred during construction idc liquidity 投資估算是指在整個投資決策過程中，依據現有的資料和一定的方法，對建設專案的投資額 包括工...