軟體項目計畫（Software Project Planning）是一個軟體項目進入系統實施的啟動階段，主要進行的工作包括：確定詳細的項目實施範圍、定義遞交的工作成果、評估實施過程中主要的風險、制定項目實施的時間計畫、成本和預算計畫、人力資源計畫等。
簡介,計畫內容,範圍,資源,進度安排,工程規範,成本估算,估算方法,估算模型,風險分析,進度安排,計畫制定,編制方針,計畫模板,
簡介
在軟體項目管理過程中一個關鍵的活動是制定項目計畫，它是軟體開發工作的第一步。 項目計畫的目標是為項目負責人提供一個框架，使之能合理地估算軟體項目開發所需的資源 、經費和開發進度，並控制軟體項目開發過程按此計畫進行。 在做計畫時，必須就需要的人力、項目持續時間及成本作出估算。這種估算大多是參考 以前的花費作出的。軟體項目計畫包括二個任務：研究和估算。即通過研究確定該軟體 項目的主要功能、性能和系統界面。
軟體項目計畫
軟體項目計畫計畫內容
軟體項目計畫內容如下：
範圍
對該軟體項目的綜合描述，定義起所要做的工作以及性能限制，它包括：
軟體項目計畫
軟體項目計畫(1)項目目標。
(2)主要功能。
(3)性能限制。
(4)系統接口。
(5)特殊要求。
(6)開發概述。
資源
(1)人員資源。
(2)硬體資源。
(3)軟體資源。
(4)其他。
進度安排
進度安排的好壞往往會影響整個項目的按期完成，因此這一環節是十分重要的。制定軟體進度與其他工程沒有很大的區別 ，其方法主要有：
(1)工程網路圖。
(2)Gantt圖。
(3)任務資源表。
(4)成本估算。
(5)培訓計畫。
工程規範
對軟體工程管理來說，軟體工程規範的制定和實施是不可少的，它與軟體項目計畫一樣重要 。軟體工程規範可選用現成的各種規範，也可自己制定。軟體工程規範可分為三級：
軟體項目計畫
軟體項目計畫(1)國家標準與國際標準。
(2)行業標準與工業部門標準。
(3)企業級標準與開發小組級標準。
成本估算
估算方法
自頂向下估算方法
估算人員參照以前完成的項目所耗費的總成本，來推算將要開發的軟體的總成本，然後把它們按階段、步驟和工作單元進行 分配，這種方法稱為自頂向下估算方法。
它的優點是對系統級工作的重視，所以估算中不會遺漏系統級的諸如集成、用戶手冊和配置管理之類的事務的成本估算，且估算工作量小、 速度快。它的缺點是往往不清楚低級別上的技術性困難問題，而往往這些困難將會使成本上升。
自底向上估算方法
自底向上估算方法是將待開發的軟體細分，分別估算每一個子任務所需要的開發工作量，然後將它們加起來 ，得到軟體的總開發量。這種方法的優點是對每個部分的估算工作交給負責該部分工作的人來做，所以估算 較為準確。其缺點是其估算往往缺少與軟體開發有關的系統工作級工作量，所以估算往往偏低。
差別估算方法
差別估算是將開發項目與一個或多個已完成的類似項目進行比較，找到與某個相類似項目的若干 不同之處，並估算每個不同之處對成本的影響，導出開發項目的總成本。該方法的優點是可以提高估算的準確度， 缺點是不容易明確“差別”的界限。
其他
除上三種還有：
(1)專家估算法。
(2)類推估算法。
(3)算式估算法。
估算模型
COCOMO估算模型
機構性成本模型COCOMO（Constructive Cost Mode）是最精確、最易於使用的成本估算方法之一。
該模型分為：基本COCOMO模型，是一個靜態單變數模型，它是對整個軟體系統進行估算；中級COCOMO模型，是一個靜態多變數模型；詳細COCOMO模型，將軟體系統模型分為系統、子系統和模組三個層次。
①基本COCOMO模型估算公式：
E=ab(KLOC)exp(bb)
D=cb(E)exp(db)
式中E為開發所需的人力（人/月）。D為所需的開發時間（月）。KLOC為估計提交的代碼行。
ab、bb、cb和db是指不同軟體開發方式的值。
②中級COCOMO模型。
其估算公式為：E=ai(KLOC)exp(bi)×乘法因子，ai，bi
Putnam成本估算經驗模型
Putnam估算模型是一種動態多變模型，它是假設在軟體開發的整個生存期中工作量的分布。如下圖：
根據曲線導出關於提交的代碼行數L，人力K（人/年）和時間td（年）之間估算公式：
式中Ck是技術狀況有關的常數，它的典型值如下：
對於差的開發環境 Ck=2500
對於好的開發環境 Ck=10000
對於有的開發環境 Ck=12500
由上述公式可以得到所需開發工作量的公式：
風險分析
風險分析對於軟體項目管理是決定性的，然而目前現在還是有很多項目不考慮風險就著手進行。
進度安排
軟體項目的進度安排與任何一個工程的進度安排沒有實質上的不同。首先識別一組項目任務，建立任務間的相互關聯，然後估計各個任 務的工作量，分配人力和其他資源，指定進度時序。
軟體開發任務的並行性
若軟體項目有多人參加時，多個開發者的活動將並行進行。
Gantt圖
Gantt圖常用水平線段來描述把任務分解成子任務，以及每個子任務的進度按排，該圖表示方法簡單易懂， 一目了然，動態反映軟體開發進度情況。如下表：
進程計畫時間表
工程網路圖
工程網路圖是一種有向圖，該圖中用圓表示事件，有向弧或箭頭表示子任務的進行，箭頭上的數字稱為權，該權表示此子任務的持續時間，箭頭下面括弧中的數字表示該任務的機動時間，圖中的圓表示與某個子任務開始或結束事件的時間點。如下圖：
軟體質量保證 軟體質量保證是軟體工程管理的重要內容，軟體質量保證應作好以下幾個方面的工作：
(1)採用技術手段和工具。
(2)組織正式技術評審。
(3)加強軟體測試。
(4)推行軟體工程規範（標準）。
(5)對軟體的變更進行控制。
計畫制定
項目計畫詳細說明了所需軟體工作及如何實現。它定義了每一個主要任務，並估算其所需時間和資源，同時為管理層的評估和控制提供了一個框架。項目計畫也提供了一種很有效的學習途徑。如果能合理建檔，它便是一個與實際運行效能比較的基準。這種比較可以使計畫者看到他們的估算誤差，從而提高其估算精確度。
我們著重強調對項目規模和資源的估算，是因為低質量的項目資源估算將不可避免地造成資源短缺，進度延遲和預算超支。又由於項目資源估算是從軟體規模估算中直接衍生出來的，所以低質量的規模估算是造成許多軟體項目問題的根本原因。
項目計畫應在項目開始初期制定出，並隨著工程的進展不斷地加以精化。起初，由於軟體需求通常是模糊而又不完整的，我們的工作重點應在於明確該項目需要哪些領域的知識，並且如何獲取這些知識。如果不遵循這一指導原則，程式設計師們通常會積極地投入到那部分已知的工作中去，而把未知部分留滯到以後。這種工作方式通常會產生很多問題，因為未知部分具有最高的風險係數。軟體項目計畫的邏輯如下所述 ：
由於軟體需求在初始階段是模糊而又不完整的，質量計畫只能建立在對客戶需求的大致而不確切的理解之上。因此，項目計畫應該從找出含糊不確切與準確恰當的軟體需求間的映射關係入手。
接著建立一種概念設計。項目初始架構的建立要十分謹慎，因為它通常標定了產品模組的分割線，同時描述了這些模組所實現的功能及所有模組間的關係。這就為項目計畫和項目實施提供了組織框架，因此一個低質量的概念設計是不能滿足要求的。
在每一次後續的需求精化時，也應同時精化資源映射，項目規模估算和工程進度。
軟體項目計畫-制訂軟體項目計畫的方法與策略
制訂軟體項目計畫的目的在於建立並維護軟體項目各項活動的計畫，軟體項目計畫其實就是一個用來協調軟體項目中其它所有計畫，指導項目組對項目進行執行和監控的檔案。一個好的軟體項目計畫可為項目的成功實施打下堅實的基礎。
軟體項目有其特殊性，不確定因素多，工作量估計困難，項目初期難於制定一個科學、合理的項目計畫。我曾主持和參與過大大小小的軟體項目十餘項，下面我將把我制訂軟體項目計畫的經驗分享給大家。
1.注重項目計畫的層次性
軟體項目計畫的層次及其關係如下圖所示。
高級計畫，是項目的早期計畫。高級計畫應當是粗粒度的，主要是進行項目的階段劃分，確定重大的里程碑，所需相關的資源，包括人力資源、設備資源、資金資源，即所謂的人、財、物三個要素。
大的階段交替之前，應做好下一階段的詳細計畫，我們稱之為二級計畫。詳細計畫要確定各項任務的負責人，開始時間，結束時間，任務之間的依賴關係，設備資源，小的事件點（即里程碑）。
如果項目規模相對較大，可以有多級的計畫，比如說，一個項目組可能分為幾個開發組，二級計畫是各開發組制訂的適合的自己小組的計畫。如果開發組還分了小組，可以有小組的三級計畫。
開發人員的個人計畫是低級計畫，由開發人員根據自己的任務自行制定，要把任務細化到人·日。
一般的，軟體項目計畫至多有四級就夠了，過多的等級將會引發效率的瓶頸。大的項目不見得要有龐大的組織和人員數量來支撐，合理的劃分小組，減少組織的層次，有利於項目計畫的制訂和實施。較小的軟體項目由於工期不長，人員較少，有二級計畫（高級計畫與低級計畫）也是可行的。
2.重視與客戶的溝通
與客戶的溝通是很重要的。不必害怕客戶知道我們的開發計畫，特別是項目進度情況，應當和客戶共享這些信息。
首先，客戶會提出一些對項目時間、進度、效果上的要求，這個指標往往經不起推敲，有的還帶有較強的政策性。如：在我主持的一個某單位人nnerlink>MIS系統的開發中就發現，客戶方對時間上的約束是有成形的檔案的，是他們單位領導們開會的決定。客戶給出的從項目啟動到驗收的時間只有三個月，但是，經過我們認真的需求調研，做出項目進度的粗計畫和部分的二級計畫後，發現三個月的時間是難於實現的。我們把做出的調研文檔和項目計畫擺出來和和客戶討論，最終使項目的開發時間延長為六個月。站在為了科學地分析和解決問題的立場上來看，項目組和客戶的目的是一致的，所以對於合理的項目進度客戶是會理解與支持的。
其次，我們有義務要讓客戶知道項目的計畫。這樣才能讓客戶和用戶主動、積極參與項目，達到項目的最終目標。項目計畫取得雙方簽字認可是一種好的習慣。客戶可能不願意簽正式的檔案，那么在文檔的封面上籤上雙方負責人的姓名、聯繫方式也行，雖然是非正式的，但留下了項目工作的痕跡。有必要想辦法讓客戶清楚簽字意味著什麼。這就意味說雙方有了一個約定，既讓用戶感覺心裡踏實，也讓自己的項目組有了責任感，有一種督促和促進的作用。
3.該詳細的詳細，該簡略的就簡略
軟體項目計畫就如同軟體項目本身一樣有它特殊性，一個三五個人花兩三個月就可以完工的小項目，可能項目計畫就四五頁紙，包括一個WBS（工作分解結構）和一個Gantee圖（甘特圖）。一個需要五六十個人甚至上百人，要花上半年或更長時間的大型軟體項目則會有更多的項目計畫內容。我們得按照項目的的特定情況量體裁衣。
如下表表1所示，這是我主持的一個某高校教務辦公信息系統項目的風險管理計畫表。項目較小，我們只用了兩個月的時間就開發完工，通過驗收。正因如此，我們在項目計畫中大量的採用了這種表格來制訂人員計畫、培訓計畫、風險計畫、成本估計、文檔大小估計、進度計畫，一目了然，責任到人，其效果和效益是很明顯的。
項目的工作安排一定要責任到人，這點是要詳細的。如果是多個人共同完成的任務也要指定一位主要負責人，否則開發人員會操作不便，甚至互相推卸責任。
4.制訂的項目計畫要現實
軟體項目中的項目經理和系統分析員大都是從程式設計師成長起來的，我亦是如此，擔任項目經理之前我寫了五年的VB、Java和資料庫SQL代碼。項目經理和系統分析員做出來的項目計畫最終要能夠被項目組成員所實現。
制訂項目計畫僅靠“個人經驗”是不夠的，不可能面面俱到，不要期希望於“個人經驗”。解決的辦法有兩個方面。
一是充分鼓勵、積極接納項目干係人（包括客戶、公司高層領導、項目組成員）來參與項目計畫的制定。
可以邀請客戶和公司高層領導來共同討論高級計畫的制訂。客戶會樂意參與的，因為追求項目的成功是大家的共同目標。公司高層領導的支持是項目組的堅強後盾，項目組需要獲取必要的資源，需要及時獲取對項目特殊要的審批，需要在領導事務上得到適當的指導和幫助，有些事項有時是需要公司高層領導加入才能解決的，如契約款項的按期支付。
制訂二級、三級項目計畫要與項目組成員互動。當規劃由一個人做出而由另一個人實施時，如果項目沒有按時完成，會使得他們懷疑項目計畫的可行性，也會影響開發人員的士氣。與項目組內部人員的溝通亦很重要。軟體程式員平時通常表現得內向、清高，作為項目經理應當學會調節工作中的氣氛，在輕鬆的氛圍中去融合開發人員的意見。
可以讓開發人員對自己職責範圍內的事提出建議的時間和資源，再作討論約定。這樣開發人員在主觀上會更加投入工作。客觀上，開發人員的能力很難用時間及工作量來衡量，一名熟練的Java程式設計師比一名初學Java的程式設計師開發效率可能快上四五倍，因而安排的時間周期、任務量當然要不一樣。我比較傾向於召開一次專題討論會，事先寫出一個初稿，再各抒已見，最後作出結論。
二是要充分利用一些歷史數據。歷史數據是寶貴的財富，是可復用的資源。不僅要注意積累這些數據，也要學會從中提煉出可以為我所用的數據。如，項目計畫的模板，計畫的資源數據等。
5.運用過程化的思想指導開發
CMM2共有6個KPA，它們是：需求管理、軟體項目計畫、項目跟蹤和監控、軟體轉包契約管理、軟體質量保證、軟體配置管理。一個軟體組織如果達到了CMM2的各個過程方面的全部目標，就表明這個組織的軟體能力達到了第2級成熟度等級。
這也可以是針對一個項目而言。通常需要根據項目的進展情況對項目計畫進行修改，以便應付需求和承諾的變更、不夠準確的估計、糾正措施和過程更改等。在策劃和重新策劃中涉及的活動，都包含在這個過程方面里。
6.利用成熟的項目管理工具
Microsoft Project 2000（或更高的版本）是一款公認的功能強大、操作方便的項目管理工具軟體。它自帶了一個叫做“軟體開發”的模板，可以用它來生成大體的框架，再作細節方面的改動，也可以自己製作一個符合自己公司軟體項目運作流程的模板。
Microsoft Project 2000的操作面版中可以安排任務，並設定開始時間、結束時間、前置任務、資源名稱等參數，它能自動生成Gantt圖、Pert圖，找出項目中的關鍵路徑。
7.結束語
軟體項目計畫分為高級計畫、二次計畫、三級計畫和低級計畫，制訂軟體項目計畫應注意及時與客戶溝通，該詳細的詳細，該簡略的就簡略，制出來的計畫要是現實的，可以運用CMM2的思想指導計畫的制訂，Microsoft Project是倍受推薦的項目計畫軟體工具。願我們多做出高質量的軟體計畫，從而打造軟體精品。
編制方針
軟體項目計畫編制的目的是制定一個合理的實施軟體工程及管理軟體項目的計畫。軟體項目計畫編制著重於對要實施的工作進行估計，建立必要的承諾並定義工作計畫。
包括以下要點：
1. 將用於編制軟體項目計畫及跟蹤軟體項目的工作文檔化。
2. 對於軟體項目的實施採用文檔化的承諾。
3. 相關的機構或個人認可他們對軟體項目的承諾。
4. 指定軟體項目負責人負責落實軟體項目的承諾並制定項目的軟體開發計畫。
5. 確保軟體項目存在一份文檔化的、並被認可的工作陳述。
6.軟體開發計畫要指定人員角色分工，明確責任。
7. 對軟體項目所需要的適當的資源及資金作出計畫。
8. 對軟體項目負責人、軟體工程師及其它與軟體項目計畫編制有關人員進行適合其職責範圍的培訓。
9. 成立相關軟體項目組及相關的方案論證小組。
10. 軟體項目組及相關的方案論證小組在整個項目生命期內參加全部的項目計畫編制工作。
11. 按照書面流程與高級管理人員或企業外部機構軟體項目的承諾進行複審。
12. 明確劃分為預先定義的、規模可管理的階段的軟體生命周期。
13. 按照書面流程開發項目的軟體開發計畫。
14. 將軟體項目計畫文檔化。
15. 確定軟體項目需要建立及維護控制的軟體產品。
16. 按照書面流程獲得對軟體產品規模的估計（或軟體產品規模的改變）。
17. 按照書面流程獲得對軟體項目工作量及費用的估計。
18. 按照書面流程獲得對項目所需要的關鍵計算機資源的估計。
19. 按照書面流程獲得項目的軟體開發進度。
20. 識別、評估與費用、資源、進度及項目的技術方面相關的軟體風險，並文檔化。
21. 準備項目的軟體工程機制及支撐工具的計畫。
22. 記錄軟體計畫編制數據。
23. 制定並使用度量方法以確定軟體計畫活動的狀態。
24. 定期與高級管理人員對軟體項目計畫活動進行複審。
26. 與軟體質量保證人員對軟體項目計畫活動及工作產品進行回顧及審核，並將結果文檔化。
計畫模板
_________項目開發計畫
1. 概述
1.1 編寫目的
本文檔是__________（開發單位名稱）根據__________ 項目 的初步需求，並對_______ 項目 的各項需求進行全面分析之後，做出的軟體開發計畫，可供支持項目組內部及信息技術部內部的研發工作。
1.2 項目背景
系統名稱： 【 列出系統名稱 】
英文名稱： 【 列出系統英文名稱 】
產品代號： 【 列出系統產品代號 】
委託單位： 【 列出委託單位 】
開發單位： 【 列出開發單位 】
開發日期： 【 開始時間 ---- 預計收尾完工時間 】
版權資訊： 【Version X.X】
1.3 定義
【 列出本檔案中用到的專門術語的定義和外文首字母組詞的原詞組。 】
1.4 參考資料
【 逐條列出所參考的文檔名稱與作者。 】
2. 項目過程定義
2 .1軟體開發生命周期模型
【 列出採用的軟體開發生命周期模型，並說明採用的理由。 】
2 ．2 開發工具與平台
【 列出採用的開發工具、作業系統及平台軟體。 】
3 ．計畫
3.3 資源計畫
【 逐項列出項目開發過程中所需的各種資源。 】
3.4 關鍵計算機資源估計
【 逐條列出所需各種計算機資源的類型、配置及數量等內容。 】
4.項目管理
4.1 人員與角色
【 逐項列出項目組的角色分配及已可供調配的人員。 】
4.2 人員計畫
【 逐條列出本項目所需各種角色人員的起始與結束時間，人數，技能方面的要求等內容。 】
4.3風險管理計畫
【 逐條列出各項風險的影響因素、發生機率、嚴重性、負責人、預期日期、預防及補救方案等內容。 】
4.4 培訓計畫
【 逐條列出主題（技能、領域、工具、方法）、人數、計畫日期、提供者等內容。 】
4.5 成本估計
【 逐條列出成本的類型及金額，並計算估計的總本。 】
5. 進度跟蹤
5.1 項目會議
【 列出項目會議組織的辦法。 】
5.2 項目里程碑
【 列出項目里程碑，即 項目進度的關鍵點 。 】
5.3 進度表
【 給出項目進度表。 】
5.4 人員任務分配
【 給出人員任務分配表，包括了任務內容、開始時間、完成時間、工時估計等內容。 】
附：
【 給出用 MS Project 製作的項目計畫 MPP】
