IT行業(yè)模版集萃

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

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

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

4、2.2條中列出的目標，逐項說明所建議系統(tǒng)相對于現存系統(tǒng)具有的改進。4.4 影響說明新提出的設備要求與對現存系統(tǒng)可使用的設備須作出的修改。4.4.1.對設備的影響 說明新提出的設備要求與對現存系統(tǒng)可使用的設備須作出的修改4.4.2.對軟件的影響 說明為了使現存的應用軟件和支持軟件能夠同所建議系統(tǒng)相適應，而需要對這些軟件所進行的修改和補充。4.4.3.對用戶單位機構的影響 說明為了建立和運行所建議系統(tǒng)，對用戶單位機構、人員的數量和技術水平等方面的全部要求。4.4.4.對系統(tǒng)運行過程的影響 說明所建議系統(tǒng)對運行過程的影響。4.4.5.對開發(fā)的影響 說明對開發(fā)的影響。4.4.6.對地點和設施的影響 說

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

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

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

8、型項目，當你提出一個新的產品開發(fā)方向時，一份商業(yè)性分析是說服管理層的一個很好工具。當然，如果是一些部項目，也是可以借鑒該文檔模板來論證該項目的商業(yè)價值。1.文檔概述該部分主要描述該文檔的目的、圍、術語以與參考資料等方面的容。1.1目的說明該文檔的作用。 1.2 圍簡要說明該與文檔相關的其它事物與資料。1.3 術語列出所有將出現于本文檔的新術語、縮略語等。1.4參考資料在此應列出項目計劃中引用的文檔列表，對于引用的每個文檔都應該列出其標題、文檔編號、日期，并且指出這些文檔的來源，以方便該計劃的閱讀者查找。1.5 概述 本小節(jié)說明該文檔所包括的容，以與它的組織方式。2.系統(tǒng)說明在此簡要地說明將要開

9、發(fā)的系統(tǒng)，包括其名稱、系統(tǒng)所解決的問題以與它的開發(fā)價值等，從而使得讀者能夠有一個直接的了解。并且在這處還應列出與在本文檔中出現的縮略詞的解釋，以便讀者更好地閱讀。3.業(yè)務環(huán)境這一小節(jié)主要說明要開發(fā)的系統(tǒng)所處于的業(yè)務環(huán)境。它包括系統(tǒng)所面向的領域、用戶。也可以在此指出它是產品型項目，還是用戶定制型項目，同時如果該項目與原有的項目有緊密的聯系，在此也應該把這些聯系列出來。4.產品目標這一小節(jié)則用于深入說明為什么要開發(fā)該系統(tǒng)，它有什么價值。最好還應對進度計劃、進度風險做一些評估。一個明確確定、表述清晰、可以度量的目標將為今后系統(tǒng)的開發(fā)工作打下堅實的基礎。 5.財務預測如果是產品型項目，那么其輸出就是一

10、個商業(yè)軟件產品。對于這樣的項目，在此應該包括對該項目的財務預測，最主要應該得出投資回報（ROI）指標。在做ROI分析時，應該針對不同的完成時間做出不同的預測，以讓系統(tǒng)開發(fā)者對于進度延遲對投資回報的損傷有一個直觀的了解。在財務預測中，有一個基點就是對項目工作量、資源使用的估算，在這里還應給出估算的基礎技術，當然這里的估算會隨著項目的進展而逐步精化，應該這里還是應該估算出一個合理的圍。6.約束任何事有利就有弊，在本小節(jié)則主要列舉執(zhí)行該項目時會遇到的一個諸如外部接口、標準、認證、特殊的技術等約束，這些約速將會對項目帶來很大的執(zhí)行風險，可能對項目的成本也帶來巨大的影響。軟件開發(fā)項目立項表編者說明：在許

11、多開發(fā)組織中，開發(fā)立項請求通常來自市場部門，該表格的設計就是為了更好地理順兩個部門之間的溝通與協調，也使得開發(fā)立項流程化，你可以根據自己公司的實際情況，對該表格的格式做一些修改。項目名稱(暫定)：項目編號（開發(fā)部填寫）項目申請人：申請日期：項目優(yōu)先級：最遲完成時間：問題/機會：項目目標與成功標準：目標描述：假設、風險與障礙：客戶：項目提出人：項目決策人：項目相關人員：審批人意見：簽名： 日期：軟件項目計劃(ISO標準)編者說明： 拿破侖說過：“沒有一場戰(zhàn)役是按照計劃打的，而勝利的戰(zhàn)役沒有一個是沒有計劃的。”，戰(zhàn)役尚且如此，軟件項目也不例個。一個經過周密考慮，團隊協作共同制訂的項目計劃是成功的關

12、鍵。本文檔模板是ISO標準模板，雖然時間有點久遠，但還是十分有參考價值的。1. 引言1.1 編寫目的說明編寫這份項目開發(fā)計劃的目的，并指出預期的讀者。1.2 背景a.待開發(fā)軟件系統(tǒng)的名稱；b.本項目的任務提出者、開發(fā)者、用戶與實現該軟件的計算中心或計算機網絡；c.該軟件系統(tǒng)同其他系統(tǒng)或其他機構的基本的相互來往關系。1.3 定義列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。1.4 參考資料列出用得著的參考資料。2. 項目概述2.1 工作容簡要地說明在本項目的開發(fā)中須進行的各項主要工作。 2.2 主要參加人員 扼要地說明參加本項目開發(fā)工作的主要人員的情況，包括他們的技術水平。2.3 產

13、品2.3.1 程序 列出需移交給用戶的程序的名稱、所用的編程語言與存儲程序的媒體形式，并通過引用有關文件。逐項說明其功能和能力。2.3.2.文件 列出需移交給用戶的每種文件的名稱與容要點。2.3.3.服務 列出需向用戶提供的各項服務。 2.3.4.非移交的產品 說明開發(fā)集體應向本單位交出但不必向用戶移交的產品。 2.4 驗收標準 對于上述這些應交出的產品和服務，逐項說明或引用資料說明驗收標準。2.5 完成項目的最遲期限2.6 本計劃的批準者和批準日期3. 實施計劃3.1 工作任務的分解與人員分工對于項目開發(fā)中需完成的各項工作，從需求分析、設計、實現、測試直到維護，包括文件的編制、審批、打印、分

14、發(fā)工作，用戶培訓工作，軟件安裝工作等，按層次進行分解，指明每項任務的負責人和參加人員。3.2 接口人員說明負責接口工作的人員與他們的職責。3.3 進度對于需求分析、設計、編碼實現、測試、移交、培訓和安裝等工作，給出每項工作任務的預定的開始日期、完成日期與所需資源，規(guī)定各項工作任務完成的先后順序以與表征每項工作任務完成的標志性事件。3.4 預算逐項列出本開發(fā)項目所需要的勞務以與經費的預算和來源。3.5 關鍵問題逐項列出能夠影響整個項目成敗的關鍵問題、技術難點和風險，指出這些問題對項目的影響。4.支持條件 說明為支持本項目的開發(fā)所需要的各種條件和設施。4.1 計算機系統(tǒng)支持逐項列出開發(fā)中和運行時所

15、需的計算機系統(tǒng)支持，包括計算機、外圍設備、通訊設備、模擬器、編譯程序、操作系統(tǒng)、數據管理程序包、數據存儲能力和測試支持能力等，逐項給出有關到貨日期、使用時間的要求。4.2 需由用戶承擔的工作逐項列出需要用戶承擔的工作和完成期限，包括需由用戶提供的條件與提供時間。4.3 需由外單位提供的條件逐項列出需要外單位分合同承包者承擔的工作和完成的時間。5.專題計劃要點說明本項目開發(fā)中需制訂的各個專題計劃的要點。軟件項目計劃模板(2)編者說明： 大家可能都發(fā)現了ISO標準的項目計劃缺少實用性，那是因為其未能很好地與WBS、甘特圖技術實現良好的結合。該文檔模板則充分考慮到這一點，其簡單、實用，適用于中小規(guī)模

16、項目。1.引言 1.1 計劃的目的 1.2 項目的圍和目標 1.2.1 圍描述 1.2.2 主要功能 1.2.3 性能 1.2.4 管理和技術約束 2.項目估算 2.1 使用的歷史數據 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 項目工作分解結構 4.2 時限圖(甘特圖) 4.3 資源表 5.項目資源 5.1 人員 5.2 硬件和軟件 5.3 特別資源 6.人員組織 6.1 組織結構 6.2 管理報告 7.跟蹤和控制

17、機制 7.1 質量保證和控制 7.2 變化管理和控制 8.附錄 軟件項目計劃模板(3)編者說明： 如果項目規(guī)模較大，除了上一個模板中的容之外，還應該加入許多分支容，包括過程計劃、組織計劃、測試計劃、變更與管理計劃、文檔計劃等各多方面的問題，將這些容的細化，將使項目計劃更全面、更周密。第1部分 概述1.1 目標這部分的目標是總結整個項目計劃。1.2 概述簡要描述要做的工作。給出所有理解工作環(huán)境所需的背景。然后闡述在合同下的項目任務。緊接著，說明項目如何組織。然后，在項目的基礎上列出假設和約束。1.3 詳述說明項目的總體時間進度。包括項目中的所有主要工作，無論是你能控制的還是不能控制的。如果你計劃

18、發(fā)布多個版本，要說明如何安排進度。第2部分 過程計劃2.1 目標這部分的目標是對用一系列稱為“過程”的時間段對開發(fā)活動加以定義，也就是確定該項目的開發(fā)將選用什么樣的過程模型。2.2 概述定義你的開發(fā)生命周期，并且簡要說明生命周期的每個過程。2.3 詳述2.3.1 定義過程主要目標：分析問題、制作項目計劃、定義接收標準、選擇項目工具。次要目標：尋找人員、了解客戶、形成試驗性的設計思想。2.3.2 設計過程主要目標：設計操作性程序、設計支持性程序、改進項目計劃、進行項目評審。次要目標：準備集成環(huán)境、建立變更管理、制作模擬模型、為下一個過程尋找人員、準備程序員培訓、出版程序員手冊、初步準備系統(tǒng)測試、

19、驗收測試、現場測試、建立項目資料庫。2.3.3 編碼過程主要目標：詳細設計/編碼和模塊測試、模塊集成、文檔建立。次要目標：詳細地準備系統(tǒng)測試、驗收測試、現場測試，準備客戶培訓、準備移植。2.3.4 系統(tǒng)測試過程主要目標：根據問題說明書進行系統(tǒng)測試、盡可能地“實況”測試、通過非程序開發(fā)人員測試。次要目標：完成驗收測試準備、培訓客戶、更新描述性文檔、完成用戶文檔、再次分配人員。2.3.5 驗收過程主要目標：執(zhí)行和分析驗收測試、簽署正式的接收協議。次要目標：完成客戶培訓、清理文檔。2.3.6 移植過程主要目標：協助進行數據轉換、建立數據轉換標準、建立全面恢復計劃、定義移植順序、協助接入。次要目標：與

20、受影響組進行聯系、支持評審過程。2.3.7 運行過程主要目標：協助初期運行。次要目標：現場測試、繼續(xù)維護和調整、評價項目。第3部分 組織計劃3.1 目標這部分的目標是定義項目的組織以與責任分配。 3.2 概述說明建立組織的基本原因，畫出組織部的主要工作流程圖，從問題的分析和設計開始，包括編碼、測試、制作文檔和交付。 3.3 詳述在每個子部分中，列出基于組織章程的部分以與每個部分的責任，然后再說明在每個過程中組織的結構圖。3.3.1 部門與責任分析和設計部：編寫問題說明書、設計說明書、變更管理、數據控制、模擬模型、制作用戶文檔、協作集成測試。編程部：詳細設計、編碼、模塊測試、集成測試、描述性文檔

21、。測試部：制作系統(tǒng)測試說明書、制作驗收和現場測試說明書、收集和制造測試數據、選擇和獲得測試工具、建立測試資料庫、安排測試資源進度、執(zhí)行測試、分析測試結果、制作測試結果文檔。行政部：資料管理、計算機時間控制、計劃和安裝終端和PC、發(fā)放程序員手冊、培訓、特殊技術協助、技術聯絡、文檔控制、報告控制、合同變更管理、提供雜務支持、維護項目歷史信息。3.3.2 組織章程第4部分 測試計劃4.1 目標 這部分的目標是定義對軟件系統(tǒng)的所有級別測試的工具、過程和責任。4.2 概述 簡要定義每個測試級別，并說明在一個測試層次上，不同級別如何組合在一起。 4.3 詳述4.3.1 單元測試在與其它功能模塊集成之前，針

22、對單個程序模塊的測試。在此應列出單元測試的目標、責任、過程、工具。4.3.2 集成測試逐步將通過測試的模塊集成為更加復雜的集合，并且測試這些集合，直到整個軟件都被集合在一起。在此應列出集成測試的目標、責任、過程、工具。4.3.3 系統(tǒng)測試在盡可能真實的環(huán)境下，重新測試完成的軟件系統(tǒng)，應由非編程人員完成。在此應列出系統(tǒng)測試的目標、責任、過程、工具。4.3.4 驗收測試在用戶認可的條件下，試運行系統(tǒng)以驗證系統(tǒng)滿足了客戶的需求。在此應列出驗收測試的目標、責任、過程、工具。4.3.5 現場測試在不同的運行環(huán)境下測試軟件系統(tǒng)，以確保運行準備就緒，這并不是每個項目都需要的。在此應列出現場測試的目標、責任、

23、過程、工具。4.3.6 共同測試設備描述在幾個或者所有級別的測試中共同的設備和工具，其中包括系統(tǒng)資料、計算機設備、桌面系統(tǒng)、操作系統(tǒng)、特殊語言、CASE工具、仿真器。4.3.7 測試支持程序第5部分 變更管理計劃5.1 目標 這部分的目標是定義在軟件系統(tǒng)開發(fā)過程中，變更控制的過程。5.2 概述描述建立你和客戶都能夠接受的關鍵基線文檔以與控制與這些基線變化相關事件的需求。無論何時發(fā)生問題，基線文檔都是參考的關鍵。 5.3 詳述5.3.1 基線定義哪些文檔在你的項目中是基線。5.3.2 變更申請列出可能會提出變更的人員類別，以與提供相應的變更申請文檔。5.3.3 研究變更申請5.3.4 變更的類型

24、根據變更的基線影響的程序，設置不同的變更類型。5.3.5 變更管理會議明確變更管理會議的組成成員、召開時間以與具體的操作辦法。5.3.6 建議類型定義變更建議的類型，通常包括接受和拒絕兩種。5.3.7 執(zhí)行變更定義執(zhí)行變更的具體方法，通常包括評估變更成本、對變更進行審批、制作變更文檔、對變更后的進度進行重新安排、測試變更結果。第6部分 文檔計劃6.1 目標這部分的目標是定義出版周期所要求過程與資源，以與列出基礎項目文檔組的框架結構。6.2 概述強調所有的項目文檔在這部分都列出結構框架。6.3 詳述6.3.1 發(fā)布過程和責任通常包括準備和批準、打字輸入、校對和編輯、翻印、發(fā)放、電子存儲等。 6.

25、3.2 項目文檔大綱每個文檔的都包括以下部分： a.項目標志：用于標識項目文檔之用；b.文檔名稱：標識主題，如問題說明書、設計說明書c.文檔編號：由項目資料員分配給文檔的唯一標識；d. 在作為正式版本之前，文檔所需批準人的。當然也不是所有文檔都需要經過批準。e.發(fā)行日期f.文檔主體：文檔的容。6.3.3 文檔容列出在該項目中將要使用的文檔模板的結構性容。 軟件項目計劃模板(4)編者說明： 隨著現代軟件工程思想的普與，迭代的、增量的開發(fā)生命周期已經被認識并付諸實踐，針對這樣的生命周期，其項目計劃的格式也需要做出相應的調整。1. 文檔概述在此對整個文檔進行概要性描述，另外還應列出該計劃的目標、圍、

26、定義、術語、參考資料等容。1.1 目標在此描述本項目計劃的目標。1.2 圍 簡要說明該計劃所覆蓋的圍，以與與其相關的項目，與該文檔有聯系的事物。1.3 定義與術語在此列出在該計劃中所涉與的所有術語、定義、縮寫詞的解釋，這些信息也可以引用項目詞匯表來提供。1.4 參考資料在此應列出項目計劃中引用的文檔列表，對于引用的每個文檔都應該列出其標題、文檔編號、日期，并且指出這些文檔的來源，以方便該計劃的閱讀者查找。1.5 概述 說明該計劃其它部分所包含的容，以與文檔的組織方式。2. 項目概述2.1 項目目標指出該項目將會交付什么樣的產品，能夠幫助客戶達到什么目標。2.2 假設與約束列舉出制定該計劃時所做

27、的所有假設，以與列舉出對該項目的解決方案的約束性要求，如特定的操作系統(tǒng)平臺、特定的時間、特定的經費圍等。2.3 項目交付物具體列出該項目完成后，將交付哪些東西，并可以列出每個交付時間。2.4 項目計劃更新總結建議采用表格的形式，將計劃的修訂過程列出來。3. 項目組織3.1 項目組織結構建議使用組織結構圖的形式，將整個項目團隊成員之間的關系與職責明確下來，甚至可以包括管理人員、各種委員會等。3.2 外部聯系人列出開發(fā)組織之外的，所有與項目相關的外部人員的、聯系等資料。3.3 角色與職責明確項目開發(fā)各個任務的負責人或小組。4. 項目管理計劃4.1 項目估計給出關于項目成本、進度的估計值，這些估計值

28、將是項目計劃制定的基礎，也是今后重新評估、修改計劃的基礎。你可以采用任何估算技術。4.2 項目計劃4.2.1 階段計劃主要包括工作結構分解（WBS）、顯示各個階段或迭代時間安排的甘特圖、主要里程碑與其驗收標準。4.2.2 迭代目標如果你采用的是迭代式的開發(fā)方法，那么在此列出每次迭代的計劃，以與每次迭代計劃實現的目標。4.2.3 發(fā)行計劃列出軟件開發(fā)過程中各個中間版本的發(fā)行時間，包括演示版、Alpha版、Beta版等。4.2.4 項目進度表使用甘特圖或PERT圖等方法，表示出該項目的進度計劃。4.2.5 項目資源計劃在此處應列出項目所需的人員、設備等資源情況。應指明所需人員的數量、技能要求，以與

29、如何獲取這些資源，是否要對人員進行必要的培訓等。4.2.6 項目預算根據WBS和階段計劃分配成本，得到本項目的財務預算。4.3 迭代計劃根據4.2.2小節(jié)的目標，具體列出每次迭代的詳細計劃。該部分可以視需要將其單列為專題計劃。4.3.1 迭代一 4.3.1.1 計劃 列出此次迭代的時間線、小型里程碑等。 4.2.1.2 資源 列出此次迭代所需的人力、財力、設備等資源。 4.2.1.3 用例 列出此次迭代將要實現的用例。4.2.1.4 評估標準 列出此次迭代的各項評測標準，包括功能、性能、容量、質量等。4.4 項目監(jiān)督與控制4.4.1 需求管理計劃有針對性對制定各類需求元素的管理與跟蹤辦法。該部

30、分可以視需要將其單列成為專題計劃。4.4.2 進度控制計劃說明如何對項目計劃執(zhí)行情況進行監(jiān)控，將采用什么措施與管理手段。4.4.3 預算控制計劃說明如何對項目的財務預算進行控制，以保證成本最小化。4.4.4 質量控制計劃說明如何保證項目的質量，以與一些應急的應對措施。該部分可以視需要將其單列成為專題計劃。4.4.5 報告計劃說明項目開發(fā)過程中，整個項目團隊的報告機制，什么時候、誰、報送什么數據，從而形成規(guī)則。4.4.6 評測計劃制定項目開發(fā)過程中將要度量與評測的指標，說明如何評測，如何應對。該部分可以視需要將其單列成為專題計劃。4.5 風險管理計劃該部分可以視需要將其單列為專題計劃。 4.5.

31、1 風險總述對項目所涉與的風險進行一個概要性描述。 4.5.2 風險管理任務簡要地說明在該項目中，風險管理所涉與的容，可以包括用來確定風險的方法、對風險列表進行分析和確定優(yōu)先級的方式、將采用的風險管理策略、對最嚴重的風險所計劃的降低/規(guī)避或預防的策略、監(jiān)測風險狀態(tài)的方式、風險復審的時間表。 4.5.3 風險管理的組織和職責列出與風險管理相關的個人或小組，并對其職責進行描述。 4.5.4 工具與技術列出與風險管理將采用的工具軟件或技術。 4.5.5 納入管理的風險項列出主要的風險項，并描述其影響以與應急措施。具體可以參考后面的風險條目跟蹤表模板。4.6 收尾計劃列出在項目后期將要做的事，包括材料

32、存檔、匯報總結等。5. 相關技術5.1 開發(fā)案例給出本項目將采用的軟件生命周期模型、過程規(guī)等，從而對開發(fā)過程給予明確的指導。該部分可以視需要將其單列為一個專題文件。5.2 方法、工具和技術列出本項目中將運用的方法、工具和技術，并給出適當的工作指南和說明。5.3 產品驗收計劃列出本項目驗收工作的一些細節(jié)計劃，本部分容可以視需要將其單列為一個專題計劃。6其它支持過程管理6.1 配置管理計劃在此列出該項目所采用的配置管理過程，通常是單列為一個專題。6.2 評估計劃列出本項目評估時所使用的技術、標準、指標和過程。這里的評估包括走查、檢查和復審。6.3 文檔計劃6.4 質量保證計劃6.5 分包商管理計劃

33、7.其他計劃8.附錄9.索引風險條目跟蹤表模板編者說明：對于中型以上的項目，風險控制的意義就猶為突出。要控制風險，就應該找到風險，并將風險記錄下來，確定相關責任人，對于風險性高的、可能性大的還需要制訂相關的應對措施。而最好的方法就是整理成為本模板中的表格，為每個潛在風險備個案。序列號確定日期撤消日期描述可能性 注：可用0.1(極不可能)1.0(肯定發(fā)生)來表示影響 注：可用1(無甚么影響)10(有很深、很大的影響)來表示危害值降低風險計劃負責人截止日期進度計劃風險列表編者說明： 準確來說，本列表不是一個文檔模板，而是一個參考文章。由于風險識別許多人都覺得無從入手，下面就是列出了與進度相關的風險

34、條目，對于風險識別有很大的參考價值。1.最常見的進度計劃風險1） 功能無限蔓延；2） 需求鍍金或開發(fā)人員鍍金；3） 質量不定4） 計劃過于樂觀5） 設計欠佳6） 銀彈綜合癥7） 研發(fā)導向開發(fā)8） 人員薄弱9） 簽約商失?。?0）研發(fā)人員與客戶的磨擦。2.進度計劃風險完整列表2.1 計劃編制風險1） 計劃、資源和產品定義全憑客戶或上層領導口頭指令，并且不完全一致；2） 計劃是優(yōu)化的，是“最佳狀態(tài)”；3） 計劃忽略了必要的任務；4） 計劃基于使用特定的小組成員，而那個小組成員其實指望不上。5） 在限定的時間無法建成已定規(guī)模大小的產品；6） 產品規(guī)模比估計的要大一些；7） 工作量大于估算數；8） 進

35、度已經拖延的項目在重新評估時過于優(yōu)化或忽視項目歷史；9） 過度的進度壓力造成生產率下降；10）目標日期提前，但沒有相應地調整產品圍或可用資源；11）一個任務的延遲導致相關任務的連鎖反應；12）涉足不熟悉的產品領域，花費在設計和實現上的時間比預期的要多。2.2 組織和管理1） 項目缺乏一個有凝聚力的最高領導人；2） 由于前期乏力，項目長時間被擱置；3） 解雇和削減開支導致項目小組能力下降；4） 僅由管理層或市場人員進行技術決策，導致計劃進度延長；5） 低效的項目組結構降低生產率；6） 管理層審查/決策的周期比預期時間長；7） 預算削減打亂項目計劃；8） 管理層做出了打擊項目組織積極性的決定；9）

36、 非技術的第三方的工作比預期延長（如審批，采購等）；10）計劃性太差，無法適應期望的開發(fā)速度；11）項目計劃由于壓力而放棄，導致開發(fā)混亂、低效；12）管理層強調英雄主義，而忽視客觀確切的狀態(tài)報告，這會降低發(fā)現和改正問題的能力。2.3 開發(fā)環(huán)境1） 設施沒有與時到位；2） 設施到位，但不配套；3） 設施擁擠、雜亂或者破損；4） 開發(fā)工具未能與時到位；5） 開發(fā)工具不如期望那樣有效，開發(fā)人員需要時間創(chuàng)建工作環(huán)境或切換新的工具；6） 開發(fā)工具的選擇不是基于技術需求，不能提供計劃要求的性能；7） 新開發(fā)工具的學習期比預期的長，容繁多。2.4 最終用戶1） 最終用戶堅持新的需求；2） 最終用戶對于最后交

37、付的產品不滿意，要求重新設計和重做；3） 最終用戶不買進項目產品，無法提供后續(xù)支持；4） 最終用戶的意見未被采納，造成產品最終無法滿足用戶期望，而必須重做。2.5 客戶1） 客戶堅持新的需求；2） 客戶對規(guī)劃、原型和規(guī)格的審核/決策周期比預期長；3） 客戶沒有或不能參與規(guī)劃、原型和規(guī)格階段的審核，導致需求不穩(wěn)定和耗時的重復；4） 客戶答復的時間比預期長（如回答需求中需澄清的問題）；5） 客戶堅持技術決策而導致進度計劃延長；6） 客戶對開發(fā)進度管理過細，導致實際進展變慢；7） 客戶提供的組件無法與開發(fā)的產品匹配，導致額外的設計和集成工作；8） 客戶提供的組件質量欠佳，導致額外的測試、設計和集成工

38、作，以與額外的客戶關系管理工作；9） 客戶要求的支持工具和環(huán)境不兼容、性能差或者功能不完善，導致生產率降低；10）客戶不接受交付的軟件，盡管它滿足了所有的規(guī)格；11）客戶期望的開發(fā)速度是開發(fā)人員無法達到的。2.6 承包商1） 承包商沒有按承諾交付組件；2） 承包商遞交的組件質量低下無法接收，必須花時間改進質量；3） 承包商沒有買進項目開發(fā)需要的工具，進而無法提供需要的性能水平。2.7 需求1） 需求已經成為項目基準，但變化還在繼續(xù)；2） 需求定義欠佳，而進一步的定義會擴展項目疇；3） 添加額外的需求；4） 產品定義含混的部分比預期需要更多的時間。2.8 產品1） 錯誤發(fā)生率高的模塊需要比預期更

39、多的測試、設計和實現工作；2） 校正質量低下不可接受的產品，需要比預期更多的測試、設計和實現工作。3） 在一個或多上新興領域推廣計算機技術使得計劃進度的延長不可預期；4） 由于軟件功能的錯誤，需要重新設計和實現；5） 開發(fā)額外不需要的功能（鍍金）延長了計劃進度；6） 要滿足產品規(guī)格與速度要求，需比預期更多時間，包括重新設計和實現的時間；7） 嚴格要求與現有系統(tǒng)兼容，需要進行比預期更多的測試、設計和實現工作；8） 要求與其他系統(tǒng)、復雜系統(tǒng)或不受本項目控制的系統(tǒng)相連，導致無法預料的設計、實現和測試工作。9） 要求在不同操作系統(tǒng)下運行將花費比預期更長的時間；10）在不熟悉或未經檢驗的軟（硬）件環(huán)境中

40、運行產生未預料的問題；11）開發(fā)一種對組織全新的模塊將比預期花費更長的時間；12）依賴正在開發(fā)中的技術將延長計劃進度。2.9 外部環(huán)境1） 產品依賴政府規(guī)章，而規(guī)章的改變將是不可預期的；2） 產品依賴草擬中的技術標準，而最后的標準將是不可預期的。2.10 人員1） 招聘人員所花時間比預期的長；2） 作為先決條件的任務不能按時完成（如培訓、其它項目）；3） 開發(fā)人員和管理層之間關系不佳導致決策緩慢，影響全局；4） 項目組成員沒有全身心投入項目，進而無法達到需要的產品性能水平；5） 缺乏激勵措施，士氣低下，降低了生產能力；6） 缺乏必要的規(guī)，增加了工作失誤與重復工作；7） 某些人需要更多時間適應不

41、熟悉的軟件工具和環(huán)境、硬件環(huán)境、編程語言；8） 項目結束前，合同制人員離開團隊，或雇員辭職；9） 項目后期加入新的開發(fā)人員，額外的培訓和溝通降低現有成員的效率；10）項目組成員不能有效地一起工作；11）由于項目組成員間的沖突，導致溝通不暢、設計欠佳、接口錯誤和額外的重復工作；12）有問題的成員沒有調離項目組，損害了項目組其他成員的積極性；13）項目的最佳人選未加入項目組；14）項目的最佳人選已加入項目組，但因其他原因未能合理使用；15）沒有找到項目急需的具有特定技能的人；16）關鍵人物只能兼職參與；17）項目人員不足；18）任務的分配與人員技能不匹配；19）人員工作的進展比預期的慢；20）項目

42、管理人員怠工導致計劃和進度失效；21）技術人員怠工導致工作遺漏或質量低下，工作需要重做。2.11 設計與實現1） 設計過于簡單，無法確定主要事件，并導致重新設計和實現；2） 設計過于復雜，導致一些不必要的工作，影響實現效率；3） 設計質量低下，導致重復設計和實現4） 使用不熟悉的方法，導致額外的培訓時間，并重犯前期使用這種方法時導致的錯誤；5） 產品采用低級語言來實施，導致生產率比預期的低；6） 一些必要的功能無法使用現有的代碼和庫實現，開發(fā)人員必須使用新庫或自選開發(fā)所要的功能；7） 代碼和庫質量低下，導致需要額外的測試、錯誤修正或重做；8） 過高估計了增強型工具對計劃進度的節(jié)省量；9） 分別

43、開發(fā)的模塊無法有效集成，需要重新設計或重做。2.12 過程1） 大量的紙面工作導致進程比預期的慢；2） 進程跟蹤不準確，導致無法預知項目是否已落后于計劃進度；3） 前期的質量保證行為不真實，導致后期的重復工作；4） 質量跟蹤不準確，導致無法得知影響進度的質量問題；5） 太不正規(guī)，導致溝通不足，質量問題和工作重做；6） 過于正規(guī)，導致過多耗時無用的工作；7） 向管理層撰寫進度報告占用的開發(fā)人員的時間比預期的多；8） 風險管理粗心，導致沒有發(fā)現重大的項目風險；9） 軟件項目風險管理花費的時間比預期的多。開發(fā)進度月報(ISO標準)編者說明： 計劃需要跟蹤進度來進行適當的調整，因此在開發(fā)組織應該形成良

44、好的進度匯報機制，ISO標準模板也對這一塊提供了參考。這一文檔格式十分全面，不過也略顯繁瑣，適合于中型以上項目。l標題 開發(fā)中的軟件系統(tǒng)的名稱和標識符分項目名稱和標識符分項目負責人簽名本期月報編寫人簽名本期月報的編號與所報告的年月2工程進度與狀態(tài)2.1 進度 列出本月進行的各項主要活動，并且說明本月遇到的重要事件，這里所說的重要事件是指一個開發(fā)階段（即軟件生存周期各個階段中的某一個，例如需求分析階段）的開始或結束，要說明階段名稱與開始（或結束）的日期。2.2 狀態(tài) 說明本月的實際工作進度與計劃相比，是提前了、按期完成了、或是推遲了？如果與計劃不一致，說明原因與準備采取的措施。3資額耗用與狀態(tài)3

45、.1 資額耗用主要說明本月份耗用的工時與機時。 3.1.1 工時 分為三類：a. 管理用工時 包括在項目管理（制訂計劃、布置工作、收集數據、檢查匯報工作等）方面耗用的工時； b. 服務用工時 包括為支持項目開發(fā)所必須的服務工作與非直接的開發(fā)工作所耗用的工時；c. 開發(fā)用工時 要分各個開發(fā)階段填寫。3.1.2 機時 說明本月耗用的機時，以小時為單位，說明計算機系統(tǒng)的型號。3.2 狀態(tài)說明本月實際耗用的資源與計劃相比，是超出了、相一致、還是不到計劃數？如果與計劃不一致，說明原因與準備采取的措施。4 經費支出與狀態(tài) 4.1 經費支出 4.1.1 支持性費用 列出本月支出的支持性費用，一般可按如下七類

46、列出，并給出本月支持費用的總和： a. 房租或房屋折舊費；b. 員工工資、獎金、補貼；c. 培訓費包括給教師的酬金與教室租金；d. 資料費包括復印與購買參考資料的費用；e. 會議費召集有關業(yè)務會議的費用；f. 旅差費；g. 其他費用。4.1.2 設備購置費 列出本月支出的設備購置費，一般可分如下三類：a. 購買軟件的名稱與金額；b. 購買硬設備的名稱、型號、數量與金額；c. 已有硬設備的折舊費。4.2 狀態(tài) 說明本月實際支出的經費與計劃相比較，是超過了。相符合、還是不到計劃數？如果與計劃不一致，說明原因與準備采取的措施。5下個月的工作計劃6建議 本月遇到的重要問題和應引起重視的問題以與因此產生

47、的建議。開發(fā)任務卡編者說明： 項目中應該實現責任到人，項目的進度應該是每個項目成員個人進度表的總匯集，而開發(fā)任務卡則是項目與項目成員的約定，也是項目管理的一個好辦法。大家可以根據自己的實際情況來修改該模板。項目名： 模塊/類名：安排時間： 任務承擔人：相關模塊/類情況： 模塊/類名負責人開始時間完成時間狀態(tài)任務描述：估計完成時間：_ 批準人：_個人開發(fā)進度月報編者說明： 表格式的進度報表能夠節(jié)省制作時間，縮短進度誤差。對于中型以上項目，特別是成員的任務超過了1個月，那么讓每個開發(fā)人員填寫進度月報就是一個很好的管理辦法。當然，如果成員的任務都較小，則無需使用該文檔，只需對工作任務卡進行檢查就可以

48、了。1標題項目名稱與標識：子項目名稱與標識：開發(fā)階段：報告時間：年月日至年月日報告人：簽名2進度2.1 任務任務：任務描述：狀態(tài)： 完成 未完成與計劃比較： 提前 按期 推遲推遲原因：3資源耗費總用工時：加班時間：機時：上網時間：硬件平臺：軟件環(huán)境和工具：4.下個月工作計劃任務：任務描述：任務所屬項目或子項目：性質： 新 續(xù)上月5.建議項目開發(fā)進度月報編者說明： 項目進度月報是必須的管理機制，而長篇大論不僅浪費了大家的時間，而且也使得進度的收集與實際情況有一些時間上的誤差，因而可以采用表格化的報表格式。1.標題項目名稱與標識：子項目名稱與標識：本期月報編寫人：簽名子項目負責人：簽名本期月報編號

49、：月報日期： 年 月 日2.進度2.1 任務任務：任務描述：狀態(tài)： 完成 未完成與計劃比較： 提前 按期 推遲推遲原因：2.2 事件事件：事件標志：與計劃比較： 提前 按期 推遲推遲原因：3.資源耗費 3.1 工時管理用工時：服務用工時：開發(fā)用工時：總 計： 3.2 機時計算機類型：用時：計算機類型：用時：計算機類型：用時：總 計：用時：4.經費支出 4.1 支持性經費支出工資、獎金、補貼：培訓費：資料費：會議費：差旅費：總計： 4.2 設置購置費設備名稱型號數量單價金額總計金額：5.下個月工作計劃 5.1 任務任務：任務描述：開發(fā)階段：性質： 新 續(xù)上月 5.2 事件事件：事件標志：性質： 新 舊 6.建議項目進度周報編者說明： 月報通常需要較詳細，而周報則應該更簡潔，每周讓項目經理花上1-2分鐘將一周的項目進度情況做一個通報是很必要的。本文檔模板就是一個例子，供大家參考。周期：2003年_月_日2003年_月_日項目名稱：_ 項目編號：_項目經理：