IT行業(yè)模板集萃

1、模版集萃綜述：在程序員的日常工作中，除了編寫代碼之外，還免不了需要編寫各種技術文檔。一個編寫良好的技術文檔在項目中能夠很好地建立溝通與協(xié)作，起到很積極的作用。因此，編寫技術文檔也就成為了程序員技能提升的很重要的一面。為此，我們特意收集了一些在項目開發(fā)過程中經(jīng)常用到的文檔模板，這些模板包括格式和簡單的寫作說明，相信能夠幫助大家編寫出更加高效、實用的技術文檔。在收集過程中，我們十分注重其實用性，以確保每個模板的價值，而且對于一些重要的文檔提供了多個模板。為了方便大家查找，我們將收錄的57模板分為以下幾類：1） 項目及開發(fā)管理類：包括立項前的分析，立項后的計劃、以及進度跟蹤、風險控制方面的文檔模板，

2、共計16個；2） 需求分析類：明確清晰的需求，是項目成功的基礎，在此收集了在需求分析過程中所將使用到的文檔模板，共計14個；3） 系統(tǒng)分析與設計類：包括體系結(jié)構(gòu)設計、高層設計、詳細設計、數(shù)據(jù)庫設計等6個相關文檔模板；4） 軟件質(zhì)量保證類：軟件測試是質(zhì)量保證的關鍵活動，在此收集了軟件測試相關的11個文檔模板；5） 其它類：除此之外，還收集了關于用戶手冊、軟件維護等方面的10個文檔模板，其中還有一個軟件過程規(guī)范的示例。另外，值得說明的是，文檔模板只是為文檔的編寫提供一個基礎，在實際的編寫過程中，你可以根據(jù)自己的需要進行必要的剪裁和增補。一、 項目及開發(fā)管理類可行性研究報告(ISO標準)編者說明：

3、在立項時，應該對項目進行綜合分析，探討項目的經(jīng)濟、社會、技術可行性，從而為決策提供基礎。該模板為ISO標準文檔模板，其不僅適用于軟件項目，對于其它的系統(tǒng)項目也適用。1. 引言1.1 編寫目的編寫本可行性研究報告的目的，指出預期的讀者。1.2 背景a.所建議開發(fā)的軟件系統(tǒng)的名稱；b.本項目的任務提出者、開發(fā)者、用戶及實現(xiàn)該軟件的計算站或計算機網(wǎng)絡；c.該軟件系統(tǒng)同其他系統(tǒng)或其他機構(gòu)的基本的相互來往關系。1.3 定義 列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。1.4 參考資料 列出用得著的參考資料。2. 可行性研究的前提 說明對所建議開發(fā)的軟件的項目進行可行性研究的前提。2.1 要

4、求 說明對所建議開發(fā)的軟件的基本要求。2.2 目標 說明所建議系統(tǒng)的主要開發(fā)目標。 2.3 條件、假定和限制 說明對這項開發(fā)中給出的條件、假定和所受到期的限制。2.4 進行可行性研究的方法說明這項可行性研究將是如何進行的，所建議的系統(tǒng)將是如何評價的，摘要說明所使用的基本方法和策略。2.5 評價尺度 說明對系統(tǒng)進行評價時所使用的主要尺度。3. 對現(xiàn)有系統(tǒng)的分析 這里的現(xiàn)有系統(tǒng)是指當前實際使用的系統(tǒng)，這個系統(tǒng)可能是計算機系統(tǒng)，也可能是一個機械系統(tǒng)甚至是一個人工系統(tǒng)。 分析現(xiàn)有系統(tǒng)的目的是為了進一步闡明建議中的開發(fā)新系統(tǒng)或修改現(xiàn)有系統(tǒng)的必要性。3.1 處理流程和數(shù)據(jù)流程說明現(xiàn)有系統(tǒng)的基本的處理流程和

5、數(shù)據(jù)流程。此流程可用圖表即流程圖的形式表示，并加以敘述。3.2 工作負荷 列出現(xiàn)有系統(tǒng)所承擔的工作及工作量。3.3 費用開支 列出由于運行現(xiàn)有系統(tǒng)所引起的費用開支。3.4 人員 列出為了現(xiàn)有系統(tǒng)的運行和維護所需要的人員的專業(yè)技術類別和數(shù)量。3.5 設備 列出現(xiàn)有系統(tǒng)所使用的各種設備。3.6 局限性 列出本系統(tǒng)的主要局限性。4. 所建議的系統(tǒng)4.1 對所建議系統(tǒng)的說明概括地說明所建議系統(tǒng)，并說明在第2條中列出的那些要求將如何得到滿足，說明所使用的基本方法及理論根據(jù)。4.2 處理流程和數(shù)據(jù)流程。 給出所建議系統(tǒng)的處理流程式和數(shù)據(jù)流程。4.3 改進之處 按2.2條中列出的目標，逐項說明所建議系統(tǒng)相對

6、于現(xiàn)存系統(tǒng)具有的改進。4.4 影響 說明新提出的設備要求及對現(xiàn)存系統(tǒng)中尚可使用的設備須作出的修改。4.4.1.對設備的影響 說明新提出的設備要求及對現(xiàn)存系統(tǒng)中尚可使用的設備須作出的修改4.4.2.對軟件的影響 說明為了使現(xiàn)存的應用軟件和支持軟件能夠同所建議系統(tǒng)相適應，而需要對這些軟件所進行的修改和補充。4.4.3.對用戶單位機構(gòu)的影響 說明為了建立和運行所建議系統(tǒng)，對用戶單位機構(gòu)、人員的數(shù)量和技術水平等方面的全部要求。4.4.4.對系統(tǒng)運行過程的影響 說明所建議系統(tǒng)對運行過程的影響。4.4.5.對開發(fā)的影響 說明對開發(fā)的影響。4.4.6.對地點和設施的影響 說明對建筑物改造的要求及對環(huán)境設施的

7、要求。4.4.7.對經(jīng)費開支的影響 扼要說明為了所建議系統(tǒng)的開發(fā)，統(tǒng)計和維持運行而需要的各項經(jīng)費開支。4.5 技術條件方面的可能性本節(jié)應說明技術條件方面的可能性5. 可選擇的其他系統(tǒng)方案 扼要說明曾考慮過的每一種可選擇的系統(tǒng)方案，包括需開發(fā)的和可從國內(nèi)國外直接購買的，如果沒有供選擇的系統(tǒng)方案可考慮，則說明這一點。5.1 可選擇的系統(tǒng)方案1 說明可選擇的系統(tǒng)方案1，并說明它末被選中的理由。5.2 可選擇的系統(tǒng)方案2 按類似5。1條的方式說明第2個乃至第n個可選擇的系統(tǒng)方案。 6. 投資及效益分析6.1 支出對于所選擇的方案，說明所需的費用，如果已有一個現(xiàn)存系統(tǒng)，則包括該系統(tǒng)繼續(xù)運行期間所需的費用

8、。6.1.1 基本建設投資 包括采購、開發(fā)和安裝所需的費用。6.1.2 其他一次性支出 6.1.3 非一次性支出 列出在該系統(tǒng)生命期內(nèi)按月或按季或按年支出的用于運行和維護的費用。6.2 收益對于所選擇的方案，說明能夠帶來的收益，這里所說的收益，表現(xiàn)為開支費用的減少或避免、差錯的減少、靈活性的增加、動作速度的提高和管理計劃方面的改進等，包括：6.2.1 一次性收益 說明能夠用人民幣數(shù)目表示的一次性收益，可按數(shù)據(jù)處理、用戶、管理和支持等項分類敘述。6.2.2 非一次性收益 說明在整個系統(tǒng)生命期內(nèi)由于運行所建議系統(tǒng)而導致的按月的、按年的能用人民幣數(shù)目表示的收益，包括開支的減少和避免。6.2.3 不可

9、定量的收益 逐項列出無法直用人民幣表示的收益。6.3 收益/投資比 求出整個系統(tǒng)生命期的收益/投資比值。6.4 投資回收周期 求出收益的累計數(shù)開始超過支出的累計數(shù)的時間。6.5 敏感性分析是指一些關鍵性因素與這些不同類型之間的合理搭配、處理速度要求、設備和軟件的配置等變化時，對開支和收益的影響最靈敏的范圍的估計。7. 社會因素方面的可能性7.1.法律方面的可行性7.2.使用方面的可行性8. 結(jié)論在進行可行性研究報告的編制時，必須有一個研究的結(jié)論軟件項目商業(yè)性分析頁：4 注，改寫自RUP模板中的商業(yè)理由編者說明：隨著市場經(jīng)濟的不斷發(fā)展，一個項目的商業(yè)價值、市場價值往往是衡量項目價值的最大依據(jù)。該

10、文檔模板十分適用于產(chǎn)品型項目，當你提出一個新的產(chǎn)品開發(fā)方向時，一份商業(yè)性分析是說服管理層的一個很好工具。當然，如果是一些內(nèi)部項目，也是可以借鑒該文檔模板來論證該項目的商業(yè)價值。1.  文檔概述該部分主要描述該文檔的目的、范圍、術語以及參考資料等方面的內(nèi)容。1.1 目的說明該文檔的作用。 1.2  范圍簡要說明該與文檔相關的其它事物與資料。1.3 術語列出所有將出現(xiàn)于本文檔的新術語、縮略語等。1.4  參考資料在此應列出項目計劃中引用的文檔列表，對于引用的每個文檔都應該列出其標題、文檔編號、日期，并且指出這些文檔的來源，以方便該計劃的閱

11、讀者查找。1.5  概述 本小節(jié)說明該文檔所包括的內(nèi)容，以及它的組織方式。2.系統(tǒng)說明在此簡要地說明將要開發(fā)的系統(tǒng)，包括其名稱、系統(tǒng)所解決的問題以及它的開發(fā)價值等，從而使得讀者能夠有一個直接的了解。并且在這處還應列出與在本文檔中出現(xiàn)的縮略詞的解釋，以便讀者更好地閱讀。3.業(yè)務環(huán)境這一小節(jié)主要說明要開發(fā)的系統(tǒng)所處于的業(yè)務環(huán)境。它包括系統(tǒng)所面向的領域、用戶。也可以在此指出它是產(chǎn)品型項目，還是用戶定制型項目，同時如果該項目與原有的項目有緊密的聯(lián)系，在此也應該把這些聯(lián)系列出來。4.產(chǎn)品目標這一小節(jié)則用于深入說明為什么要開發(fā)該系統(tǒng)，它有什么價值。最好還應對進度計劃、進度風險做一些評估。一個明確

12、確定、表述清晰、可以度量的目標將為今后系統(tǒng)的開發(fā)工作打下堅實的基礎。 5. 財務預測如果是產(chǎn)品型項目，那么其輸出就是一個商業(yè)軟件產(chǎn)品。對于這樣的項目，在此應該包括對該項目的財務預測，最主要應該得出投資回報（ROI）指標。在做ROI分析時，應該針對不同的完成時間做出不同的預測，以讓系統(tǒng)開發(fā)者對于進度延遲對投資回報的損傷有一個直觀的了解。在財務預測中，有一個基點就是對項目工作量、資源使用的估算，在這里還應給出估算的基礎技術，當然這里的估算會隨著項目的進展而逐步精化，應該這里還是應該估算出一個合理的范圍。6.  約束任何事有利就有弊，在本小節(jié)則主要列舉執(zhí)行該項目時會遇到

13、的一個諸如外部接口、標準、認證、特殊的技術等約束，這些約速將會對項目帶來很大的執(zhí)行風險，可能對項目的成本也帶來巨大的影響。軟件開發(fā)項目立項表編者說明：在許多開發(fā)組織中，開發(fā)立項請求通常來自市場部門，該表格的設計就是為了更好地理順兩個部門之間的溝通與協(xié)調(diào)，也使得開發(fā)立項流程化，你可以根據(jù)自己公司的實際情況，對該表格的格式做一些修改。項目名稱(暫定)：項目編號（開發(fā)部填寫）項目申請人：申請日期：項目優(yōu)先級：最遲完成時間：問題/機會：項目目標及成功標準：目標描述：假設、風險及障礙：客戶名單：項目提出人：項目決策人：項目相關人員：審批人意見：簽名： 日期：軟件項目計劃(ISO標準)編者說明： 拿破侖說

14、過：“沒有一場戰(zhàn)役是按照計劃打的，而勝利的戰(zhàn)役沒有一個是沒有計劃的?！?，戰(zhàn)役尚且如此，軟件項目也不例個。一個經(jīng)過周密考慮，團隊協(xié)作共同制訂的項目計劃是成功的關鍵。本文檔模板是ISO標準模板，雖然時間有點久遠，但還是十分有參考價值的。1. 引言1.1 編寫目的說明編寫這份項目開發(fā)計劃的目的，并指出預期的讀者。1.2 背景a.待開發(fā)軟件系統(tǒng)的名稱；b.本項目的任務提出者、開發(fā)者、用戶及實現(xiàn)該軟件的計算中心或計算機網(wǎng)絡；c.該軟件系統(tǒng)同其他系統(tǒng)或其他機構(gòu)的基本的相互來往關系。1.3 定義 列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。1.4 參考資料 列出用得著的參考資料。2. 項目概述

15、2.1 工作內(nèi)容 簡要地說明在本項目的開發(fā)中須進行的各項主要工作。 2.2 主要參加人員 扼要地說明參加本項目開發(fā)工作的主要人員的情況，包括他們的技術水平。2.3 產(chǎn)品2.3.1 程序 列出需移交給用戶的程序的名稱、所用的編程語言及存儲程序的媒體形式，并通過引用有關文件。逐項說明其功能和能力。2.3.2.文件 列出需移交給用戶的每種文件的名稱及內(nèi)容要點。2.3.3.服務 列出需向用戶提供的各項服務。 2.3.4.非移交的產(chǎn)品 說明開發(fā)集體應向本單位交出但不必向用戶移交的產(chǎn)品。 2.4 驗收標準 對于上述這些應交出的產(chǎn)品和服務，逐項說明或引用資料說明驗收標準。2.5 完成項目的最遲期限2.6 本

16、計劃的批準者和批準日期3. 實施計劃3.1 工作任務的分解與人員分工對于項目開發(fā)中需完成的各項工作，從需求分析、設計、實現(xiàn)、測試直到維護，包括文件的編制、審批、打印、分發(fā)工作，用戶培訓工作，軟件安裝工作等，按層次進行分解，指明每項任務的負責人和參加人員。3.2 接口人員 說明負責接口工作的人員及他們的職責。3.3 進度對于需求分析、設計、編碼實現(xiàn)、測試、移交、培訓和安裝等工作，給出每項工作任務的預定的開始日期、完成日期及所需資源，規(guī)定各項工作任務完成的先后順序以及表征每項工作任務完成的標志性事件。3.4 預算 逐項列出本開發(fā)項目所需要的勞務以及經(jīng)費的預算和來源。3.5 關鍵問題逐項列出能夠影響

17、整個項目成敗的關鍵問題、技術難點和風險，指出這些問題對項目的影響。4.支持條件 說明為支持本項目的開發(fā)所需要的各種條件和設施。4.1 計算機系統(tǒng)支持逐項列出開發(fā)中和運行時所需的計算機系統(tǒng)支持，包括計算機、外圍設備、通訊設備、模擬器、編譯程序、操作系統(tǒng)、數(shù)據(jù)管理程序包、數(shù)據(jù)存儲能力和測試支持能力等，逐項給出有關到貨日期、使用時間的要求。4.2 需由用戶承擔的工作 逐項列出需要用戶承擔的工作和完成期限，包括需由用戶提供的條件及提供時間。4.3 需由外單位提供的條件 逐項列出需要外單位分合同承包者承擔的工作和完成的時間。5.專題計劃要點說明本項目開發(fā)中需制訂的各個專題計劃的要點。軟件項目計劃模板(2

18、)編者說明： 大家可能都發(fā)現(xiàn)了ISO標準的項目計劃缺少實用性，那是因為其未能很好地與WBS、甘特圖技術實現(xiàn)良好的結(jié)合。該文檔模板則充分考慮到這一點，其簡單、實用，適用于中小規(guī)模項目。1.引言 1.1 計劃的目的 1.2 項目的范圍和目標 1.2.1 范圍描述 1.2.2 主要功能 1.2.3 性能 1.2.4 管理和技術約束 2.項目估算 2.1 使用的歷史數(shù)據(jù) 2.2 使用的評估技術 2.3 工作量、成本、時間估算 3. 風險管理戰(zhàn)略 3.1 風險識別 3.2 有關風險的討論 3.3 風險管理計劃 3.3.1 風險計劃 3.3.2 風險監(jiān)視 3.3.3 風險管理 4.日程 4.1 項目工作分

19、解結(jié)構(gòu) 4.2 時限圖(甘特圖) 4.3 資源表 5.項目資源 5.1 人員 5.2 硬件和軟件 5.3 特別資源 6.人員組織 6.1 組織結(jié)構(gòu) 6.2 管理報告 7.跟蹤和控制機制 7.1 質(zhì)量保證和控制 7.2 變化管理和控制 8.附錄 軟件項目計劃模板頁：8 注，來源于軟件項目管理一書。(3)編者說明： 如果項目規(guī)模較大，除了上一個模板中的內(nèi)容之外，還應該加入許多分支內(nèi)容，包括過程計劃、組織計劃、測試計劃、變更及管理計劃、文檔計劃等各多方面的問題，將這些內(nèi)容的細化，將使項目計劃更全面、更周密。第1部分 概述1.1 目標 這部分的目標是總結(jié)整個項目計劃。1.2 概述簡要描述要做的工作。給

20、出所有理解工作環(huán)境所需的背景。然后闡述在合同下的項目任務。緊接著，說明項目如何組織。然后，在項目的基礎上列出假設和約束。1.3 詳述說明項目的總體時間進度。包括項目中的所有主要工作，無論是你能控制的還是不能控制的。如果你計劃發(fā)布多個版本，要說明如何安排進度。第2部分 過程計劃2.1 目標這部分的目標是對用一系列稱為“過程”的時間段對開發(fā)活動加以定義，也就是確定該項目的開發(fā)將選用什么樣的過程模型。2.2 概述定義你的開發(fā)生命周期，并且簡要說明生命周期的每個過程。2.3 詳述2.3.1 定義過程主要目標：分析問題、制作項目計劃、定義接收標準、選擇項目工具。次要目標：尋找人員、了解客戶、形成試驗性的

21、設計思想。2.3.2 設計過程主要目標：設計操作性程序、設計支持性程序、改進項目計劃、進行項目評審。次要目標：準備集成環(huán)境、建立變更管理、制作模擬模型、為下一個過程尋找人員、準備程序員培訓、出版程序員手冊、初步準備系統(tǒng)測試、驗收測試、現(xiàn)場測試、建立項目資料庫。2.3.3 編碼過程主要目標：詳細設計/編碼和模塊測試、模塊集成、文檔建立。次要目標：詳細地準備系統(tǒng)測試、驗收測試、現(xiàn)場測試，準備客戶培訓、準備移植。2.3.4 系統(tǒng)測試過程主要目標：根據(jù)問題說明書進行系統(tǒng)測試、盡可能地“實況”測試、通過非程序開發(fā)人員測試。次要目標：完成驗收測試準備、培訓客戶、更新描述性文檔、完成用戶文檔、再次分配人員。

22、2.3.5 驗收過程主要目標：執(zhí)行和分析驗收測試、簽署正式的接收協(xié)議。次要目標：完成客戶培訓、清理文檔。2.3.6 移植過程主要目標：協(xié)助進行數(shù)據(jù)轉(zhuǎn)換、建立數(shù)據(jù)轉(zhuǎn)換標準、建立全面恢復計劃、定義移植順序、協(xié)助接入。次要目標：與受影響組進行聯(lián)系、支持評審過程。2.3.7 運行過程主要目標：協(xié)助初期運行。次要目標：現(xiàn)場測試、繼續(xù)維護和調(diào)整、評價項目。第3部分 組織計劃3.1 目標這部分的目標是定義項目的組織以及責任分配。 3.2 概述說明建立組織的基本原因，畫出組織內(nèi)部的主要工作流程圖，從問題的分析和設計開始，包括編碼、測試、制作文檔和交付。 3.3 詳述在每個子部分中，列出基于組織章程的部分以及每

23、個部分的責任，然后再說明在每個過程中組織的結(jié)構(gòu)圖。3.3.1 部門及責任分析和設計部：編寫問題說明書、設計說明書、變更管理、數(shù)據(jù)控制、模擬模型、制作用戶文檔、協(xié)作集成測試。編程部：詳細設計、編碼、模塊測試、集成測試、描述性文檔。測試部：制作系統(tǒng)測試說明書、制作驗收和現(xiàn)場測試說明書、收集和制造測試數(shù)據(jù)、選擇和獲得測試工具、建立測試資料庫、安排測試資源進度、執(zhí)行測試、分析測試結(jié)果、制作測試結(jié)果文檔。行政部：資料管理、計算機時間控制、計劃和安裝終端和PC、發(fā)放程序員手冊、培訓、特殊技術協(xié)助、技術聯(lián)絡、文檔控制、報告控制、合同變更管理、提供雜務支持、維護項目歷史信息。3.3.2 組織章程第4部分 測試

24、計劃4.1 目標 這部分的目標是定義對軟件系統(tǒng)的所有級別測試的工具、過程和責任。4.2 概述 簡要定義每個測試級別，并說明在一個測試層次上，不同級別如何組合在一起。 4.3 詳述4.3.1 單元測試在與其它功能模塊集成之前，針對單個程序模塊的測試。在此應列出單元測試的目標、責任、過程、工具。4.3.2 集成測試逐步將通過測試的模塊集成為更加復雜的集合，并且測試這些集合，直到整個軟件都被集合在一起。在此應列出集成測試的目標、責任、過程、工具。4.3.3 系統(tǒng)測試在盡可能真實的環(huán)境下，重新測試完成的軟件系統(tǒng)，應由非編程人員完成。在此應列出系統(tǒng)測試的目標、責任、過程、工具。4.3.4 驗收測試在用戶

25、認可的條件下，試運行系統(tǒng)以驗證系統(tǒng)滿足了客戶的需求。在此應列出驗收測試的目標、責任、過程、工具。4.3.5 現(xiàn)場測試在不同的運行環(huán)境下測試軟件系統(tǒng)，以確保運行準備就緒，這并不是每個項目都需要的。在此應列出現(xiàn)場測試的目標、責任、過程、工具。4.3.6 共同測試設備描述在幾個或者所有級別的測試中共同的設備和工具，其中包括系統(tǒng)資料、計算機設備、桌面系統(tǒng)、操作系統(tǒng)、特殊語言、CASE工具、仿真器。4.3.7 測試支持程序第5部分 變更管理計劃5.1 目標 這部分的目標是定義在軟件系統(tǒng)開發(fā)過程中，變更控制的過程。5.2 概述描述建立你和客戶都能夠接受的關鍵基線文檔以及控制與這些基線變化相關事件的需求。無

26、論何時發(fā)生問題，基線文檔都是參考的關鍵。 5.3 詳述5.3.1 基線定義哪些文檔在你的項目中是基線。5.3.2 變更申請列出可能會提出變更的人員類別，以及提供相應的變更申請文檔。5.3.3 研究變更申請5.3.4 變更的類型根據(jù)變更的基線影響的程序，設置不同的變更類型。5.3.5 變更管理會議明確變更管理會議的組成成員、召開時間以及具體的操作辦法。5.3.6 建議類型定義變更建議的類型，通常包括接受和拒絕兩種。5.3.7 執(zhí)行變更定義執(zhí)行變更的具體方法，通常包括評估變更成本、對變更進行審批、制作變更文檔、對變更后的進度進行重新安排、測試變更結(jié)果。第6部分 文檔計劃6.1 目標這部分的目標是定

27、義出版周期所要求過程與資源，以及列出基礎項目文檔組的框架結(jié)構(gòu)。6.2 概述強調(diào)所有的項目文檔在這部分都列出結(jié)構(gòu)框架。6.3 詳述6.3.1 發(fā)布過程和責任通常包括準備和批準、打字輸入、校對和編輯、翻印、發(fā)放、電子存儲等。 6.3.2 項目文檔大綱每個文檔的都包括以下部分： a.項目標志：用于標識項目文檔之用；b.文檔名稱：標識主題，如問題說明書、設計說明書c.文檔編號：由項目資料員分配給文檔的唯一標識；d.批準：在作為正式版本之前，文檔所需批準人的姓名。當然也不是所有文檔都需要經(jīng)過批準。e.發(fā)行日期f.文檔主體：文檔的內(nèi)容。6.3.3 文檔內(nèi)容列出在該項目中將要使用的文檔模板的結(jié)構(gòu)性內(nèi)容。 軟

28、件項目計劃模板(4頁：11 注，對RUP模板的修改)編者說明： 隨著現(xiàn)代軟件工程思想的普及，迭代的、增量的開發(fā)生命周期已經(jīng)被認識并付諸實踐，針對這樣的生命周期，其項目計劃的格式也需要做出相應的調(diào)整。1. 文檔概述在此對整個文檔進行概要性描述，另外還應列出該計劃的目標、范圍、定義、術語、參考資料等內(nèi)容。1.1 目標在此描述本項目計劃的目標。1.2 范圍 簡要說明該計劃所覆蓋的范圍，以及與其相關的項目，與該文檔有聯(lián)系的事物。1.3 定義與術語在此列出在該計劃中所涉及的所有術語、定義、縮寫詞的解釋，這些信息也可以引用項目詞匯表來提供。1.4 參考資料在此應列出項目計劃中引用的文檔列表，對于引用的每個

29、文檔都應該列出其標題、文檔編號、日期，并且指出這些文檔的來源，以方便該計劃的閱讀者查找。1.5 概述 說明該計劃其它部分所包含的內(nèi)容，以及文檔的組織方式。2. 項目概述2.1 項目目標指出該項目將會交付什么樣的產(chǎn)品，能夠幫助客戶達到什么目標。2.2 假設與約束列舉出制定該計劃時所做的所有假設，以及列舉出對該項目的解決方案的約束性要求，如特定的操作系統(tǒng)平臺、特定的時間、特定的經(jīng)費范圍等。2.3 項目交付物具體列出該項目完成后，將交付哪些東西，并可以列出每個交付時間。2.4 項目計劃更新總結(jié)建議采用表格的形式，將計劃的修訂過程列出來。3. 項目組織3.1 項目組織結(jié)構(gòu)建議使用組織結(jié)構(gòu)圖的形式，將整

30、個項目團隊成員之間的關系與職責明確下來，甚至可以包括管理人員、各種委員會等。3.2 外部聯(lián)系人列出開發(fā)組織之外的，所有與項目相關的外部人員的姓名、聯(lián)系電話等資料。3.3 角色與職責明確項目開發(fā)各個任務的負責人或小組。4. 項目管理計劃4.1 項目估計給出關于項目成本、進度的估計值，這些估計值將是項目計劃制定的基礎，也是今后重新評估、修改計劃的基礎。你可以采用任何估算技術。4.2 項目計劃4.2.1 階段計劃主要包括工作結(jié)構(gòu)分解（WBS）、顯示各個階段或迭代時間安排的甘特圖、主要里程碑與其驗收標準。4.2.2 迭代目標如果你采用的是迭代式的開發(fā)方法，那么在此列出每次迭代的計劃，以及每次迭代計劃實

31、現(xiàn)的目標。4.2.3 發(fā)行計劃列出軟件開發(fā)過程中各個中間版本的發(fā)行時間，包括演示版、Alpha版、Beta版等。4.2.4 項目進度表使用甘特圖或PERT圖等方法，表示出該項目的進度計劃。4.2.5 項目資源計劃 在此處應列出項目所需的人員、設備等資源情況。應指明所需人員的數(shù)量、技能要求，以及如何獲取這些資源，是否要對人員進行必要的培訓等。4.2.6 項目預算根據(jù)WBS和階段計劃分配成本，得到本項目的財務預算。4.3 迭代計劃根據(jù)4.2.2小節(jié)的目標，具體列出每次迭代的詳細計劃。該部分可以視需要將其單列為專題計劃。4.3.1 迭代一 4.3.1.1 計劃 列出此次迭代的時間線、小型里程碑等。

32、4.2.1.2 資源 列出此次迭代所需的人力、財力、設備等資源。 4.2.1.3 用例 列出此次迭代將要實現(xiàn)的用例。4.2.1.4 評估標準 列出此次迭代的各項評測標準，包括功能、性能、容量、質(zhì)量等。4.4 項目監(jiān)督與控制4.4.1 需求管理計劃有針對性對制定各類需求元素的管理與跟蹤辦法。該部分可以視需要將其單列成為專題計劃。4.4.2 進度控制計劃說明如何對項目計劃執(zhí)行情況進行監(jiān)控，將采用什么措施與管理手段。4.4.3 預算控制計劃說明如何對項目的財務預算進行控制，以保證成本最小化。4.4.4 質(zhì)量控制計劃說明如何保證項目的質(zhì)量，以及一些應急的應對措施。該部分可以視需要將其單列成為專題計劃。

33、4.4.5 報告計劃說明項目開發(fā)過程中，整個項目團隊的報告機制，什么時候、誰、報送什么數(shù)據(jù)，從而形成規(guī)則。4.4.6 評測計劃制定項目開發(fā)過程中將要度量與評測的指標，說明如何評測，如何應對。該部分可以視需要將其單列成為專題計劃。4.5 風險管理計劃該部分可以視需要將其單列為專題計劃。 4.5.1 風險總述對項目所涉及的風險進行一個概要性描述。 4.5.2 風險管理任務簡要地說明在該項目中，風險管理所涉及的內(nèi)容，可以包括用來確定風險的方法、對風險列表進行分析和確定優(yōu)先級的方式、將采用的風險管理策略、對最嚴重的風險所計劃的降低/規(guī)避或預防的策略、監(jiān)測風險狀態(tài)的方式、風險復審的時間表。 4.5.3

34、風險管理的組織和職責列出與風險管理相關的個人或小組，并對其職責進行描述。 4.5.4 工具與技術列出與風險管理將采用的工具軟件或技術。 4.5.5 納入管理的風險項列出主要的風險項，并描述其影響以及應急措施。具體可以參考后面的風險條目跟蹤表模板。4.6 收尾計劃列出在項目后期將要做的事，包括材料存檔、匯報總結(jié)等。5. 相關技術5.1 開發(fā)案例給出本項目將采用的軟件生命周期模型、過程規(guī)范等，從而對開發(fā)過程給予明確的指導。該部分可以視需要將其單列為一個專題文件。5.2 方法、工具和技術列出本項目中將運用的方法、工具和技術，并給出適當?shù)墓ぷ髦改虾驼f明。5.3 產(chǎn)品驗收計劃列出本項目驗收工作的一些細節(jié)

35、計劃，本部分內(nèi)容可以視需要將其單列為一個專題計劃。6其它支持過程管理6.1 配置管理計劃在此列出該項目所采用的配置管理過程，通常是單列為一個專題。6.2 評估計劃列出本項目評估時所使用的技術、標準、指標和過程。這里的評估包括走查、檢查和復審。6.3 文檔計劃6.4 質(zhì)量保證計劃6.5 分包商管理計劃7.其他計劃8.附錄9.索引風險條目跟蹤表模板編者說明： 對于中型以上的項目，風險控制的意義就猶為突出。要控制風險，就應該找到風險，并將風險記錄下來，確定相關責任人，對于風險性高的、可能性大的還需要制訂相關的應對措施。而最好的方法就是整理成為本模板中的表格，為每個潛在風險備個案。序列號<順序號

36、>確定日期<風險被識別出的日期>撤消日期<撤消風險確定日期>描述<以"條件-結(jié)果"的形式描述風險>可能性<風險轉(zhuǎn)變?yōu)閱栴}的可能性> 注：可用0.1(極不可能)1.0(肯定發(fā)生)來表示影響 <如果風險變成了事實獎造成的損失> 注：可用1(無甚么影響)10(有很深、很大的影響)來表示危害值<可能性影響>降低風險計劃<一種或多種用來控制、避免、最小化及降低風險的方法>負責人<解決風險的責任承擔者>截止日期<完成降低風險措施的截止日期>進度計劃風險列表頁：14 注，來源

37、于快速軟件開發(fā)一書。編者說明： 準確來說，本列表不是一個文檔模板，而是一個參考文章。由于風險識別許多人都覺得無從入手，下面就是列出了與進度相關的風險條目，對于風險識別有很大的參考價值。1.最常見的進度計劃風險1） 功能無限蔓延；2） 需求鍍金或開發(fā)人員鍍金；3） 質(zhì)量不定4） 計劃過于樂觀5） 設計欠佳6） 銀彈綜合癥7） 研發(fā)導向開發(fā)8） 人員薄弱9） 簽約商失?。?0）研發(fā)人員與客戶的磨擦。2.進度計劃風險完整列表2.1 計劃編制風險1） 計劃、資源和產(chǎn)品定義全憑客戶或上層領導口頭指令，并且不完全一致；2） 計劃是優(yōu)化的，是“最佳狀態(tài)”；3） 計劃忽略了必要的任務；4） 計劃基于使用特定的

38、小組成員，而那個小組成員其實指望不上。5） 在限定的時間內(nèi)無法建成已定規(guī)模大小的產(chǎn)品；6） 產(chǎn)品規(guī)模比估計的要大一些；7） 工作量大于估算數(shù)；8） 進度已經(jīng)拖延的項目在重新評估時過于優(yōu)化或忽視項目歷史；9） 過度的進度壓力造成生產(chǎn)率下降；10）目標日期提前，但沒有相應地調(diào)整產(chǎn)品范圍或可用資源；11）一個任務的延遲導致相關任務的連鎖反應；12）涉足不熟悉的產(chǎn)品領域，花費在設計和實現(xiàn)上的時間比預期的要多。2.2 組織和管理1） 項目缺乏一個有凝聚力的最高領導人；2） 由于前期乏力，項目長時間被擱置；3） 解雇和削減開支導致項目小組能力下降；4） 僅由管理層或市場人員進行技術決策，導致計劃進度延長；

39、5） 低效的項目組結(jié)構(gòu)降低生產(chǎn)率；6） 管理層審查/決策的周期比預期時間長；7） 預算削減打亂項目計劃；8） 管理層做出了打擊項目組織積極性的決定；9） 非技術的第三方的工作比預期延長（如審批，采購等）；10）計劃性太差，無法適應期望的開發(fā)速度；11）項目計劃由于壓力而放棄，導致開發(fā)混亂、低效；12）管理層強調(diào)英雄主義，而忽視客觀確切的狀態(tài)報告，這會降低發(fā)現(xiàn)和改正問題的能力。2.3 開發(fā)環(huán)境1） 設施沒有及時到位；2） 設施到位，但不配套；3） 設施擁擠、雜亂或者破損；4） 開發(fā)工具未能及時到位；5） 開發(fā)工具不如期望那樣有效，開發(fā)人員需要時間創(chuàng)建工作環(huán)境或切換新的工具；6） 開發(fā)工具的選擇不

40、是基于技術需求，不能提供計劃要求的性能；7） 新開發(fā)工具的學習期比預期的長，內(nèi)容繁多。2.4 最終用戶1） 最終用戶堅持新的需求；2） 最終用戶對于最后交付的產(chǎn)品不滿意，要求重新設計和重做；3） 最終用戶不買進項目產(chǎn)品，無法提供后續(xù)支持；4） 最終用戶的意見未被采納，造成產(chǎn)品最終無法滿足用戶期望，而必須重做。2.5 客戶1） 客戶堅持新的需求；2） 客戶對規(guī)劃、原型和規(guī)格的審核/決策周期比預期長；3） 客戶沒有或不能參與規(guī)劃、原型和規(guī)格階段的審核，導致需求不穩(wěn)定和耗時的重復；4） 客戶答復的時間比預期長（如回答需求中需澄清的問題）；5） 客戶堅持技術決策而導致進度計劃延長；6） 客戶對開發(fā)進度

41、管理過細，導致實際進展變慢；7） 客戶提供的組件無法與開發(fā)的產(chǎn)品匹配，導致額外的設計和集成工作；8） 客戶提供的組件質(zhì)量欠佳，導致額外的測試、設計和集成工作，以及額外的客戶關系管理工作；9） 客戶要求的支持工具和環(huán)境不兼容、性能差或者功能不完善，導致生產(chǎn)率降低；10）客戶不接受交付的軟件，盡管它滿足了所有的規(guī)格；11）客戶期望的開發(fā)速度是開發(fā)人員無法達到的。2.6 承包商1） 承包商沒有按承諾交付組件；2） 承包商遞交的組件質(zhì)量低下無法接收，必須花時間改進質(zhì)量；3） 承包商沒有買進項目開發(fā)需要的工具，進而無法提供需要的性能水平。2.7 需求1） 需求已經(jīng)成為項目基準，但變化還在繼續(xù)；2） 需求

42、定義欠佳，而進一步的定義會擴展項目范疇；3） 添加額外的需求；4） 產(chǎn)品定義含混的部分比預期需要更多的時間。2.8 產(chǎn)品1） 錯誤發(fā)生率高的模塊需要比預期更多的測試、設計和實現(xiàn)工作；2） 校正質(zhì)量低下不可接受的產(chǎn)品，需要比預期更多的測試、設計和實現(xiàn)工作。3） 在一個或多上新興領域推廣計算機技術使得計劃進度的延長不可預期；4） 由于軟件功能的錯誤，需要重新設計和實現(xiàn)；5） 開發(fā)額外不需要的功能（鍍金）延長了計劃進度；6） 要滿足產(chǎn)品規(guī)格與速度要求，需比預期更多時間，包括重新設計和實現(xiàn)的時間；7） 嚴格要求與現(xiàn)有系統(tǒng)兼容，需要進行比預期更多的測試、設計和實現(xiàn)工作；8） 要求與其他系統(tǒng)、復雜系統(tǒng)或不

43、受本項目控制的系統(tǒng)相連，導致無法預料的設計、實現(xiàn)和測試工作。9） 要求在不同操作系統(tǒng)下運行將花費比預期更長的時間；10）在不熟悉或未經(jīng)檢驗的軟（硬）件環(huán)境中運行產(chǎn)生未預料的問題；11）開發(fā)一種對組織全新的模塊將比預期花費更長的時間；12）依賴正在開發(fā)中的技術將延長計劃進度。2.9 外部環(huán)境1） 產(chǎn)品依賴政府規(guī)章，而規(guī)章的改變將是不可預期的；2） 產(chǎn)品依賴草擬中的技術標準，而最后的標準將是不可預期的。2.10 人員1） 招聘人員所花時間比預期的長；2） 作為先決條件的任務不能按時完成（如培訓、其它項目）；3） 開發(fā)人員和管理層之間關系不佳導致決策緩慢，影響全局；4） 項目組成員沒有全身心投入項目

44、，進而無法達到需要的產(chǎn)品性能水平；5） 缺乏激勵措施，士氣低下，降低了生產(chǎn)能力；6） 缺乏必要的規(guī)范，增加了工作失誤與重復工作；7） 某些人需要更多時間適應不熟悉的軟件工具和環(huán)境、硬件環(huán)境、編程語言；8） 項目結(jié)束前，合同制人員離開團隊，或雇員辭職；9） 項目后期加入新的開發(fā)人員，額外的培訓和溝通降低現(xiàn)有成員的效率；10）項目組成員不能有效地一起工作；11）由于項目組成員間的沖突，導致溝通不暢、設計欠佳、接口錯誤和額外的重復工作；12）有問題的成員沒有調(diào)離項目組，損害了項目組其他成員的積極性；13）項目的最佳人選未加入項目組；14）項目的最佳人選已加入項目組，但因其他原因未能合理使用；15）沒

45、有找到項目急需的具有特定技能的人；16）關鍵人物只能兼職參與；17）項目人員不足；18）任務的分配與人員技能不匹配；19）人員工作的進展比預期的慢；20）項目管理人員怠工導致計劃和進度失效；21）技術人員怠工導致工作遺漏或質(zhì)量低下，工作需要重做。2.11 設計與實現(xiàn)1） 設計過于簡單，無法確定主要事件，并導致重新設計和實現(xiàn)；2） 設計過于復雜，導致一些不必要的工作，影響實現(xiàn)效率；3） 設計質(zhì)量低下，導致重復設計和實現(xiàn)4） 使用不熟悉的方法，導致額外的培訓時間，并重犯前期使用這種方法時導致的錯誤；5） 產(chǎn)品采用低級語言來實施，導致生產(chǎn)率比預期的低；6） 一些必要的功能無法使用現(xiàn)有的代碼和庫實現(xiàn)，

46、開發(fā)人員必須使用新庫或自選開發(fā)所要的功能；7） 代碼和庫質(zhì)量低下，導致需要額外的測試、錯誤修正或重做；8） 過高估計了增強型工具對計劃進度的節(jié)省量；9） 分別開發(fā)的模塊無法有效集成，需要重新設計或重做。2.12 過程1） 大量的紙面工作導致進程比預期的慢；2） 進程跟蹤不準確，導致無法預知項目是否已落后于計劃進度；3） 前期的質(zhì)量保證行為不真實，導致后期的重復工作；4） 質(zhì)量跟蹤不準確，導致無法得知影響進度的質(zhì)量問題；5） 太不正規(guī)，導致溝通不足，質(zhì)量問題和工作重做；6） 過于正規(guī)，導致過多耗時無用的工作；7） 向管理層撰寫進度報告占用的開發(fā)人員的時間比預期的多；8） 風險管理粗心，導致沒有發(fā)

47、現(xiàn)重大的項目風險；9） 軟件項目風險管理花費的時間比預期的多。開發(fā)進度月報(ISO標準)編者說明： 計劃需要跟蹤進度來進行適當?shù)恼{(diào)整，因此在開發(fā)組織內(nèi)應該形成良好的進度匯報機制，ISO標準模板也對這一塊提供了參考。這一文檔格式十分全面，不過也略顯繁瑣，適合于中型以上項目。l標題 開發(fā)中的軟件系統(tǒng)的名稱和標識符分項目名稱和標識符分項目負責人簽名本期月報編寫人簽名本期月報的編號及所報告的年月2工程進度與狀態(tài)2.1 進度 列出本月內(nèi)進行的各項主要活動，并且說明本月內(nèi)遇到的重要事件，這里所說的重要事件是指一個開發(fā)階段（即軟件生存周期內(nèi)各個階段中的某一個，例如需求分析階段）的開始或結(jié)束，要說明階段名稱及

48、開始（或結(jié)束）的日期。2.2 狀態(tài) 說明本月的實際工作進度與計劃相比，是提前了、按期完成了、或是推遲了？如果與計劃不一致，說明原因及準備采取的措施。3資額耗用與狀態(tài)3.1 資額耗用主要說明本月份內(nèi)耗用的工時與機時。 3.1.1 工時 分為三類： a. 管理用工時 包括在項目管理（制訂計劃、布置工作、收集數(shù)據(jù)、檢查匯報工作等）方面耗用的工時； b. 服務用工時 包括為支持項目開發(fā)所必須的服務工作及非直接的開發(fā)工作所耗用的工時；c. 開發(fā)用工時 要分各個開發(fā)階段填寫。3.1.2 機時 說明本月內(nèi)耗用的機時，以小時為單位，說明計算機系統(tǒng)的型號。3.2 狀態(tài)說明本月內(nèi)實際耗用的資源與計劃相比，是超出了

49、、相一致、還是不到計劃數(shù)？如果與計劃不一致，說明原因及準備采取的措施。4 經(jīng)費支出與狀態(tài) 4.1 經(jīng)費支出 4.1.1 支持性費用 列出本月內(nèi)支出的支持性費用，一般可按如下七類列出，并給出本月支持費用的總和： a. 房租或房屋折舊費； b. 員工工資、獎金、補貼； c. 培訓費包括給教師的酬金及教室租金； d. 資料費包括復印及購買參考資料的費用； e. 會議費召集有關業(yè)務會議的費用； f. 旅差費； g. 其他費用。4.1.2 設備購置費 列出本月內(nèi)支出的設備購置費，一般可分如下三類：a. 購買軟件的名稱與金額；b. 購買硬設備的名稱、型號、數(shù)量及金額；c. 已有硬設備的折舊費。4.2 狀態(tài)

50、 說明本月內(nèi)實際支出的經(jīng)費與計劃相比較，是超過了。相符合、還是不到計劃數(shù)？如果與計劃不一致，說明原因及準備采取的措施。5下個月的工作計劃6建議 本月遇到的重要問題和應引起重視的問題以及因此產(chǎn)生的建議。開發(fā)任務卡編者說明： 項目中應該實現(xiàn)責任到人，項目的進度應該是每個項目成員個人進度表的總匯集，而開發(fā)任務卡則是項目與項目成員的約定，也是項目管理的一個好辦法。大家可以根據(jù)自己的實際情況來修改該模板。項目名： 模塊/類名： 安排時間： 任務承擔人： 相關模塊/類情況： 模塊/類名負責人開始時間完成時間狀態(tài)任務描述：估計完成時間：_ 批準人：_個人開發(fā)進度月報編者說明： 表格式的進度報表能夠節(jié)省制作時間，縮短進度誤差。對于中型以上項目，特別是成員的任務超過了1個月，那么讓每個開發(fā)人員填寫進度月報就是一個