軟件項目管理全套模板

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

2、個；需求分析類：明確清楚的需求,是工程成功的根底,在此收集了在需求分析過程中所將使用到的文檔模板,共計14個；系統(tǒng)分析與設計類：包括體系結構設計、高層設計、詳細設計、數(shù)據(jù)庫設計等6個相關文檔模板；軟件質量保證類：軟件測試是質量保證的關鍵活動,在此收集了軟件測試相關的11個文檔模板；其它類：除此之外,還收集了關于用戶手冊、軟件維護等方面的10個文檔模板,其中還有一個軟件過程標準的例如.另外,值得說明的是,文檔模板只是為文檔的編寫提供一個根底,在實際的編寫過程中,你可以根據(jù)自己的需要進行必要的剪裁和增補.一、工程及開發(fā)治理類1.1可行性研究報告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)或其他機構的根本的相互來往關系.1.3 定義列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組.1.4 參考資料列出用得著的參考資料.2 .可行性研究的前提說明對所建議開發(fā)的軟件的工程進行可行性研究的前提.2.1 要求說明對所建議開發(fā)的軟件的根本要求.2.

4、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)的根本的處理流程和數(shù)據(jù)流程.此流程可用圖表即流程圖的形式表示,并加以表達

5、.3.2 工作負荷列出現(xiàn)有系統(tǒng)所承當?shù)墓ぷ骷肮ぷ髁?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 改良之處4.4 .2條中列出的目標,逐項說明所建議系統(tǒng)相對于現(xiàn)存系統(tǒng)具有的改良.4.5 影響說明新提出的設備要求及對現(xiàn)存系

6、統(tǒng)中尚可使用的設備須作出的修改.說明新提出的設備要求及對現(xiàn)存系統(tǒng)中尚可使用的設備須作出的修改說明為了使現(xiàn)存的應用軟件和支持軟件能夠同所建議系統(tǒng)相適應,而需要對這些軟件所進行的修改和補充.說明為了建立和運行所建議系統(tǒng),對用戶單位機構、人員的數(shù)量和技術水平等方面的全部要求.說明所建議系統(tǒng)對運行過程的影響.說明對開發(fā)的影響.說明對建筑物改造的要求及對環(huán)境設施的要求.扼要說明為了所建議系統(tǒng)的開發(fā),統(tǒng)計和維持運行而需要的各項經(jīng)費開支.4.6 技術條件方面的可能性本節(jié)應說明技術條件方面的可能性5 .可選擇的其他系統(tǒng)方案扼要說明曾考慮過的每一種可選擇的系統(tǒng)方案,包括需開發(fā)的和可從國內國外直接購置的,如果沒有

7、供選擇的系統(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ù)運行期間所需的費用.6.1.1 根本建設投資包括采購、開發(fā)和安裝所需的費用.6.1.2 其他一次性支出6.1.3 非一次性支出列出在該系統(tǒng)生命期內按月或按季或按年支出的用于運行和維護的費用.6.2 收益對于所選擇的方案,說明能夠帶來的收益,這里所說的收益,表現(xiàn)為開支費用的減少或預防、過失的減少、

8、靈活性的增加、動作速度的提升和治理方案方面的改良等,包括:6.2.1 一次性收益說明能夠用人民幣數(shù)目表示的一次性收益,可按數(shù)據(jù)處理、用戶、治理和支持等項分類表達.6.2.2 非一次性收益說明在整個系統(tǒng)生命期內由于運行所建議系統(tǒng)而導致的按月的、按年的能用人民幣數(shù)目表示的收益,包括開支的減少和預防.6.2.3 不可定量的收益逐項列出無法直用人民幣表示的收益.6.3 收益/投資比求出整個系統(tǒng)生命期的收益/投資比值.6.4 投資回收周期求出收益的累計數(shù)開始超過支出的累計數(shù)的時間.6.5 敏感性分析是指一些關鍵性因素與這些不同類型之間的合理搭配、處理速度要求、設備和軟件的配置等變化時,對開支和收益的影響

9、最靈敏的范圍的估計.7 .社會因素方面的可能性7.1 法律方面的可行性7.2 使用方面的可行性8 .結論在進行可行性研究報告的編制時,必須有一個研究的結論1.2軟件工程商業(yè)性分析編者說明：隨著市場經(jīng)濟的不斷開展,一個工程的商業(yè)價值、市場價值往往是衡量工程價值的最大依據(jù).該文檔模板十分適用于產(chǎn)品型工程,當你提出一個新的產(chǎn)品開發(fā)方向時,一份商業(yè)性分析是說服治理層的一個很好工具.當然,如果是一些內部工程,也是可以借鑒該文檔模板來論證該工程的商業(yè)價值.1 .?文檔概述該局部主要描述該文檔的目的、范圍、術語以及參考資料等方面的內容.1.1 ?目的說明該文檔的作用.1.2 ?范圍簡要說明該與文檔相關的其它

10、事物與資料.1.3 術語列出所有將出現(xiàn)于本文檔的新術語、縮略語等.1.4 ?修考資料在此應列出工程方案中引用的文檔列表,對于引用的每個文檔都應該列出其標題、文檔編號、日期,并且指出這些文檔的來源,以方便該方案的閱讀者查找.1.5 ?概述本小節(jié)說明該文檔所包括的內容,以及它的組織方式.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)品型工程,

11、還是用戶定制型工程,同時如果該工程與原有的工程有緊密的聯(lián)系,在此也應該把這些聯(lián)系列出來.4 .產(chǎn)品目標這一小節(jié)那么用于深入說明為什么要開發(fā)該系統(tǒng),它有什么價值.最好還應對進度方案、進度風險做一些評估.一個明確確定、表述清楚、可以度量的目標將為今后系統(tǒng)的開發(fā)工作打下堅實的根底.5.?財務預測如果是產(chǎn)品型工程,那么其輸出就是一個商業(yè)軟件產(chǎn)品.對于這樣的工程,在此應該包括對該工程的財務預測,最主要應該得出投資回報ROD指標.在做ROI分析時,應該針對不同的完成時間做出不同的預測,以讓系統(tǒng)開發(fā)者對于進度延遲對投資回報的損傷有一個直觀的了解.在財務預測中,有一個基點就是對工程工作量、資源使用的估算,在這

12、里還應給出估算的根底技術,當然這里的估算會隨著工程的進展而逐步精化,應該這里還是應該估算出一個合理的范圍.6.?勺束任何事有利就有弊,在本小節(jié)那么主要列舉執(zhí)行該工程時會遇到的一個諸如外部接口、標準、認證、特殊的技術等約束,這些約速將會對工程帶來很大的執(zhí)行風險,可能對工程的本錢也帶來巨大的影響.1.3 軟件開發(fā)工程立項表編者說明：在許多開發(fā)組織中,開發(fā)立項請求通常來自市場部門,該表格的設計就是為了更好地理順兩個部門之間的溝通與協(xié)調,也使得開發(fā)立項流程化,你可以根據(jù)自己公司的實際情況,對該表格的格式做一些修改.工程名稱暫定：工程編號開發(fā)部填寫：工程申請人：申請日期：工程優(yōu)先級：最遲完成時間：問題/

13、時機：工程目標及成功標準：目標描述：假設、風險及障礙：客戶名單：工程提出人：工程決策人：工程相關人員：審批人意見：簽名：日期：1.4 軟件工程方案ISO標準編者說明：拿破侖說過：“沒有一場戰(zhàn)役是根據(jù)方案打的,而勝利的戰(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.該軟件系

14、統(tǒng)同其他系統(tǒng)或其他機構的根本的相互來往關系.1.3 定義列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組.1.4 參考資料列出用得著的參考資料.2 .工程概述2.1 工作內容簡要地說明在本工程的開發(fā)中須進行的各項主要工作.2.2 主要參加人員扼要地說明參加本工程開發(fā)工作的主要人員的情況,包括他們的技術水平.2.3 產(chǎn)品2.3.1 程序列出需移交給用戶的程序的名稱、所用的編程語言及存儲程序的媒體形式,并通過引用有關文件.逐項說明其功能和水平.列出需移交給用戶的每種文件的名稱及內容要點.列出需向用戶提供的各項效勞.說明開發(fā)集體應向本單位交出但不必向用戶移交的產(chǎn)品.2.4 驗收標準對于上述這

15、些應交出的產(chǎn)品和效勞,逐項說明或引用資料說明驗收標準.2.5 完成工程的最遲期限2.6 本方案的批準者和批準日期3 .實施方案3.1 工作任務的分解與人員分工對于工程開發(fā)中需完成的各項工作,從需求分析、設計、實現(xiàn)、測試直到維護,包括文件的編制、審批、打印、分發(fā)工作,用戶培訓工作,軟件安裝工作等,按層次進行分解,指明每項任務的負責人和參加人員.3.2 接口人員說明負責接口工作的人員及他們的責任.3.3 進度對于需求分析、設計、編碼實現(xiàn)、測試、移交、培訓和安裝等工作,給出每項工作任務的預定的開始日期、完成日期及所需資源,規(guī)定各項工作任務完成的先后順序以及表征每項工作任務完成的標志性事件.3.4 預

16、算逐項列出本開發(fā)工程所需要的勞務以及經(jīng)費的預算和來源.3.5 關鍵問題逐項列出能夠影響整個工程成敗的關鍵問題、技術難點和風險,指出這些問題對工程的影響.4 .支持條件說明為支持本工程的開發(fā)所需要的各種條件和設施.4.1 計算機系統(tǒng)支持逐項列出開發(fā)中和運行時所需的計算機系統(tǒng)支持,包括計算機、外圍設備、通訊設備、模擬器、編譯程序、操作系統(tǒng)、數(shù)據(jù)治理程序包、數(shù)據(jù)存儲水平和測試支持水平等,逐項給出有關到貨日期、使用時間的要求.4.2 需由用戶承當?shù)墓ぷ髦痦椓谐鲂枰脩舫挟數(shù)墓ぷ骱屯瓿善谙?包括需由用戶提供的條件及提供時間.4.3 需由外單位提供的條件逐項列出需要外單位分合同承包者承當?shù)墓ぷ骱屯瓿傻臅r間

17、.5 .專題方案要點說明本工程開發(fā)中需制訂的各個專題方案的要點.1.5軟件工程方案模板(2)編者說明：大家可能都發(fā)現(xiàn)了ISO標準的工程方案缺少實用性,那是由于其未能很好地與WBS、甘特圖技術實現(xiàn)良好的結合.該文檔模板那么充分考慮到這一點,其簡單、實用,適用于中小規(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

18、 風險監(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 .跟蹤和限制機制7.1 質量保證和限制7.2 變化治理和限制8 .附錄1.6軟件工程方案模板3編者說明：包括過如果工程規(guī)模較大,除了上一個模板中的內容之外,還應該參加許多分支內容,程方案、組織方案、測試方案、變更及治理方案、文檔方案等各多方面的問題,將這些內容的細化,將使工程方案更全面、更周密.第1局部概述1.1 目標這局部的目標是總結整個工程方案.1.2 概述簡要描述要做的工作.給出所有

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

20、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ā)人員測試.次要目標：完成驗收測試準備、培訓客戶、更新描述性文檔、完成用戶文檔、再次分配人員.2.3.5

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

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

23、部的目標是定義對軟件系統(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 驗收測試在用戶認可的條件下,試運行系統(tǒng)以

24、驗證系統(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 概述描述建立你和客戶都能夠接受的關鍵基線文檔以及限制與這些基線變化相關事件的需求.無論何時發(fā)生問題,基線文檔都是參

25、考的關鍵.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í)行變更的具體方法,通常包括評估變更本錢、對變更進行審批、制作變更文檔、對變更后的進度進行重新安排、測試變更結果.第6局部文檔方案6.1 目標這局部的目標是定義出版周期所要求過程與資源,以及列

26、出根底工程文檔組的框架結構.6.2 概述強調所有的工程文檔在這局部都列出結構框架.6.3 詳述6.3.1 發(fā)布過程和責任通常包括準備和批準、打字輸入、校對和編輯、翻印、發(fā)放、電子存儲等.6.3.2 工程文檔大綱每個文檔的都包括以下局部：a.工程標志：用于標識工程文檔之用；b.文檔名稱：標識主題,如問題說明書、設計說明書c.文檔編號：由工程資料員分配給文檔的唯一標識；d. 在作為正式版本之前,文檔所需批準人的姓名.當然也不是所有文檔都需要經(jīng)過批準.e.發(fā)行日期f.文檔主體：文檔的內容.6.3.3 文檔內容列出在該工程中將要使用的文檔模板的結構性內容.1.7軟件工程方案模板(4)編者說明：隨著現(xiàn)代

27、軟件工程思想的普及,迭代的、增量的開發(fā)生命周期已經(jīng)被熟悉并付諸實踐,針對這樣的生命周期,其工程方案的格式也需要做出相應的調整.注：一個符合現(xiàn)代軟件工程思想的版本1 .文檔概述在此對整個文檔進行概要性描述,另外還應列出該方案的目標、范圍、定義、術語、參考資料等內容.1.1 目標在此描述本工程Tf劃的目標.1.2 范圍簡要說明該方案所覆蓋的范圍,以及與其相關的工程,與該文檔有聯(lián)系的事物.1.3 定義與術語在此列出在該方案中所涉及的所有術語、定義、縮寫詞的解釋,這些信息也可以引用工程詞匯表來提供.1.4 參考資料在此應列出工程方案中引用的文檔列表,對于引用的每個文檔都應該列出其標題、文檔編號、日期,

28、并且指出這些文檔的來源,以方便該方案的閱讀者查找.1.5 概述說明該方案其它局部所包含的內容,以及文檔的組織方式.1 .工程概述1.1 工程目標指出該工程將會交付什么樣的產(chǎn)品,能夠幫助客戶到達什么目標.1.2 假設與約束列舉出制定該方案時所做的所有假設,以及列舉出對該工程的解決方案的約束性要求,如特定的操作系統(tǒng)平臺、特定的時間、特定的經(jīng)費范圍等.1.3 工程交付物具體列出該工程完成后,將交付哪些東西,并可以列出每個交付時間.1.4 工程方案更新總結建議采用表格的形式,將方案的修訂過程列出來.2 .工程組織2.1 工程組織結構建議使用組織結構圖的形式,將整個工程團隊成員之間的關系與責任明確下來,

29、甚至可以包括治理人員、各種委員會等.2.2 外部聯(lián)系人列出開發(fā)組織之外的,所有與工程相關的外部人員的姓名、聯(lián)系 等資料.2.3 角色與責任明確工程開發(fā)各個任務的負責人或小組.3 .工程治理方案3.1 工程估計給出關于工程本錢、進度的估計值,這些估計值將是工程方案制定的根底,也是今后重新評估、修改方案的根底.你可以采用任何估算技術.3.2 工程方案3.2.1 階段方案主要包括工作結構分解WBS、顯示各個階段或迭代時間安排的甘特圖、主要里程碑與其驗收標準.3.2.2 迭代目標如果你采用的是迭代式的開發(fā)方法,那么在此列出每次迭代的方案,以及每次迭代方案實現(xiàn)的目標.3.2.3 發(fā)行方案列出軟件開發(fā)過程

30、中各個中間版本的發(fā)行時間,包括演示版、Alpha版、Beta版等.3.2.4 工程進度表使用甘特圖或PERT圖等方法,表示出該工程的進度方案.3.2.5 工程資源方案在此處應列出工程所需的人員、設備等資源情況.應指明所需人員的數(shù)量、技能要求,以及如何獲取這些資源,是否要對人員進行必要的培訓等.3.2.6 工程預算根據(jù)WBS和階段方案分配本錢,得到本工程的財務預算.3.3 迭代方案根據(jù)4.2.2小節(jié)的目標,具體列出每次迭代的詳細方案.該局部可以視需要將其單列為專題方案.3.3.1 迭代一列出此次迭代的時間線、小型里程碑等.資源列出此次迭代所需的人力、財力、設備等資源.用例列出此次迭代將要實現(xiàn)的用

31、例.評估標準列出此次迭代的各項評測標準,包括功能、性能、容量、質量等.3.4 工程監(jiān)督與限制3.4.1 需求治理方案有針對性對制定各類需求元素的治理與跟蹤方法.該局部可以視需要將其單列成為專題方案.3.4.2 進度限制方案說明如何對工程方案執(zhí)行情況進行監(jiān)控,將采用什么舉措與治理手段.3.4.3 預算限制方案說明如何對工程的財務預算進行限制,以保證本錢最小化.3.4.4 質量限制方案說明如何保證工程的質量,以及一些應急的應對舉措.該局部可以視需要將其單列成為專題方案.3.4.5 報告方案說明工程開發(fā)過程中,整個工程團隊的報告機制,什么時候、誰、報送什么數(shù)據(jù),從而形成規(guī)那么.3.4.6 評測方案制

32、定工程開發(fā)過程中將要度量與評測的指標,說明如何評測,如何應對.該局部可以視需要將其單列成為專題方案.4.5 風險治理方案該局部可以視需要將其單列為專題方案.4.5.1 風險總述對工程所涉及的風險進行一個概要性描述.4.5.2 風險治理任務簡要地說明在該工程中,風險治理所涉及的內容,可以包括用來確定風險的方法、對風險列表進行分析和確定優(yōu)先級的方式、將采用的風險治理策略、對最嚴重的風險所方案的降低/躲避或預防的策略、監(jiān)測風險狀態(tài)的方式、風險復審的時間表.4.5.3 風險治理的組織和責任列出與風險治理相關的個人或小組,并對其責任進行描述.4.5.4 工具與技術列出與風險治理將采用的工具軟件或技術.4

33、.5.5 納入治理的風險項列出主要的風險項,并描述其影響以及應急舉措.具體可以參考后面的?風險條目跟蹤表模板?.4.6 收尾方案列出在工程后期將要做的事,包括材料存檔、匯報總結等.4.相關技術5.1 開發(fā)案例給出本工程將采用的軟件生命周期模型、過程標準等,從而對開發(fā)過程給予明確的指導.該局部可以視需要將其單列為一個專題文件.5.2 方法、工具和技術列出本工程中將運用的方法、工具和技術,并給出適當?shù)墓ぷ髦改虾驼f明.5.3 產(chǎn)品驗收方案列出本工程驗收工作的一些細節(jié)方案,本局部內容可以視需要將其單列為一個專題方案.6 .其它支持過程治理6.1 配置治理方案在此列出該工程所采用的配置治理過程,通常是單

34、列為一個專題.6.2 評估方案列出本工程評估時所使用的技術、標準、指標和過程.這里的評估包括走查、檢查和復審.6.3 文檔方案6.4 質量保證方案6.5 分包商治理方案7 .其他方案8 .附錄9 .索引1.8 風險條目跟蹤表模板編者說明：對于中型以上的工程,風險限制的意義就猶為突出.要限制風險,就應該找到風險,并將風險記錄下來,確定相關責任人,對于風險性高的、可能性大的還需要制訂相關的應對舉措.而最好的方法就是整理成為本模板中的表格,為每個潛在風險備個案.序列號順序號確定日期風險被識別出的日期撤消日期撤消風險確定日期描述以條件-結果"的形式描述風險可能性風險轉變?yōu)閱栴}的可能性注：可用

35、0.1極不可能卜1.0肯定發(fā)生來表不影響如果風險變成了事實獎造成的損失注：可用1尢甚么影響10有很深、很大的影響來表不危害值可能性*影響降低風險方案一種或多種用來限制、預防、最小化及降低風險的方法負責人解決風險的責任承當者截止日期完成降低風險舉措的截止日期1.9 進度方案風險列表編者說明：準確來說,本列表不是一個文檔模板,而是一個參考文章.由于風險識別許多人都覺得無從入手,下面就是列出了與進度相關的風險條目,對于風險識別有很大的參考價值.1 .最常見的進度方案風險1功能無限蔓延；2需求鍍金或開發(fā)人員鍍金；3質量不定4方案過于樂觀5設計欠佳6銀彈綜合癥7研發(fā)導向開發(fā)8人員薄弱9簽約商失?。?0研

36、發(fā)人員與客戶的磨擦.2 .進度方案風險完整列表2.1 方案編制風險1方案、資源和產(chǎn)品定義全憑客戶或上層領導口頭指令,并且不完全一致；2方案是優(yōu)化的,是“最正確狀態(tài)；3方案忽略了必要的任務；4 方案基于使用特定的小組成員,而那個小組成員其實指望不上.5 在限定的時間內無法建成已定規(guī)模大小的產(chǎn)品；6 產(chǎn)品規(guī)模比估計的要大一些；7 工作量大于估算數(shù)；8 進度已經(jīng)拖延的工程在重新評估時過于優(yōu)化或無視工程歷史；9 過度的進度壓力造成生產(chǎn)率下降；10目標日期提前,但沒有相應地調整產(chǎn)品范圍或可用資源；11一個任務的延遲導致相關任務的連鎖反響；12涉足不熟悉的產(chǎn)品領域,花費在設計和實現(xiàn)上的時間比預期的要多.2

37、.2組織和治理1工程缺乏一個有凝聚力的最高領導人；2由于前期乏力,工程長時間被擱置；3解雇和削減開支導致工程小組水平下降；4僅由治理層或市場人員進行技術決策,導致方案進度延長；5低效的工程組結構降低生產(chǎn)率；6治理層審查/決策的周期比預期時間長；7預算削減打亂工程方案；8治理層做出了打擊工程組織積極性的決定；9非技術的第三方的工作比預期延長如審批,采購等；10方案性太差,無法適應期望的開發(fā)速度；11工程方案由于壓力而放棄,導致開發(fā)混亂、低效；12治理層強調英雄主義,而無視客觀確切的狀態(tài)報告,這會降低發(fā)現(xiàn)和改正問題的水平.2.3開發(fā)環(huán)境1設施沒有及時到位；2設施到位,但不配套；3設施擁擠、雜亂或者

38、破損；4開發(fā)工具未能及時到位；5 開發(fā)工具不如期望那樣有效,開發(fā)人員需要時間創(chuàng)立工作環(huán)境或切換新的工具；6 開發(fā)工具的選擇不是基于技術需求,不能提供方案要求的性能；7 新開發(fā)工具的學習期比預期的長,內容繁多.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 客戶答復的時間比

39、預期長如答復需求中需澄清的問題；5 客戶堅持技術決策而導致進度方案延長；6 客戶對開發(fā)進度治理過細,導致實際進展變慢；7 客戶提供的組件無法與開發(fā)的產(chǎn)品匹配,導致額外的設計和集成工作；8 客戶提供的組件質量欠佳,導致額外的測試、設計和集成工作,以及額外的客戶關系治理工作；9 客戶要求的支持工具和環(huán)境不兼容、性能差或者功能不完善,導致生產(chǎn)率降低;10 客戶不接受交付的軟件,盡管它滿足了所有的規(guī)格；11 客戶期望的開發(fā)速度是開發(fā)人員無法到達的.2.6承包商1承包商沒有按承諾交付組件；2 承包商遞交的組件質量低下無法接收,必須花時間改良質量；3 承包商沒有買進工程開發(fā)需要的工具,進而無法提供需要的性

40、能水平.2.7需求1需求已經(jīng)成為工程基準,但變化還在繼續(xù)；2 需求定義欠佳,而進一步的定義會擴展工程范疇；3 添加額外的需求；4 產(chǎn)品定義含混的局部比預期需要更多的時間.2.8產(chǎn)品1錯誤發(fā)生率高的模塊需要比預期更多的測試、設計和實現(xiàn)工作；2 校正質量低下不可接受的產(chǎn)品,需要比預期更多的測試、設計和實現(xiàn)工作.3 在一個或多上新興領域推廣計算機技術使得方案進度的延長不可預期；4 由于軟件功能的錯誤,需要重新設計和實現(xiàn)；5 開發(fā)額外不需要的功能鍍金延長了方案進度；6要滿足產(chǎn)品規(guī)格與速度要求,需比預期更多時間,包括重新設計和實現(xiàn)的時間；7嚴格要求與現(xiàn)有系統(tǒng)兼容,需要進行比預期更多的測試、設計和實現(xiàn)工作

41、；8要求與其他系統(tǒng)、復雜系統(tǒng)或不受本工程限制的系統(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工程組成員沒有全身心投入工程,進而無法

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

43、人；16關鍵人物只能兼職參與；17工程人員缺乏；18任務的分配與人員技能不匹配；19人員工作的進展比預期的慢；20工程治理人員怠工導致方案和進度失效；21技術人員怠工導致工作遺漏或質量低下,工作需要重做.2.11設計與實現(xiàn)1設計過于簡單,無法確定主要事件,并導致重新設計和實現(xiàn)；2設計過于復雜,導致一些不必要的工作,影響實現(xiàn)效率；3設計質量低下,導致重復設計和實現(xiàn)4使用不熟悉的方法,導致額外的培訓時間,并重犯前期使用這種方法時導致的錯誤；5 產(chǎn)品采用低級語言來實施,導致生產(chǎn)率比預期的低；6 一些必要的功能無法使用現(xiàn)有的代碼和庫實現(xiàn),開發(fā)人員必須使用新庫或自選開發(fā)所要的功能；7 代碼和庫質量低下,

44、導致需要額外的測試、錯誤修正或重做；8 過高估計了增強型工具對方案進度的節(jié)省量；9 分別開發(fā)的模塊無法有效集成,需要重新設計或重做.2.12過程1大量的紙面工作導致進程比預期的慢；2 進程跟蹤不準確,導致無法預知工程是否已落后于方案進度;3 前期的質量保證行為不真實,導致后期的重復工作；4 質量跟蹤不準確,導致無法得知影響進度的質量問題；5 太不正規(guī),導致溝通缺乏,質量問題和工作重做；6 過于正規(guī),導致過多耗時無用的工作；7 向治理層撰寫進度報告占用的開發(fā)人員的時間比預期的多；8 風險治理粗心,導致沒有發(fā)現(xiàn)重大的工程風險；9 軟件工程風險治理花費的時間比預期的多.1.10開發(fā)進度月報ISO標準

45、編者說明：方案需要跟蹤進度來進行適當?shù)恼{整,因此在開發(fā)組織內應該形成良好的進度匯報機制,ISO標準模板也對這一塊提供了參考.這一文檔格式十分全面,不過也略顯繁瑣,適合于中型以上工程.l.標題2.工程進度與狀態(tài)2.1 進度列出本月內進行要事件是指一個開發(fā)陟開發(fā)中的軟件系統(tǒng)的名稱和標識符分工程名稱和標識符分工程負責人簽名的春蝴轆猜動人簽名并且說明本月內遇至用珠期岬馳網(wǎng)中的某一的開始或結束,要說明階段名稱及開始或結束的日期2.2狀態(tài)j重要事件,這里所說的重個,例如需求分析階段說明本月的實際工作進度與方案相比,與方案不一致,說明原因及準備采取的舉措.3.資額耗用與狀態(tài)3.1 資額耗用主要說明本月份內耗

46、用的工時與機時.3.1.1 工時分為三類：a.治理用工時包括在工程治理報工作等方面耗用的工時；是提前了、按期完成了、或是推遲了如果制訂方案、布置工作、收集數(shù)據(jù)、檢查匯b.效勞用工時包括為支持工程開發(fā)所必須的效勞工作及非直接的開發(fā)工作所耗用的工時；c.開發(fā)用工時要分各個開發(fā)階段填寫.3.1.2 機時說明本月內耗用的機時,以小時為單位,說明計算機系統(tǒng)的型號.3.2 狀態(tài)說明本月內實際耗用的資源與方案相比,是超出了、相一致、還是不到方案數(shù)如果與方案不一致,說明原因及準備采取的舉措.4經(jīng)費支出與狀態(tài)1.1 經(jīng)費支出1.1.1 支持性費用列出本月內支出的支持性費用,一般可按如下七類列出,并給出本月支持費

47、用的總和：a.房租或房屋折舊費；b.員工工資、獎金、補貼；c.培訓費包括給教師的酬金及教室租金；d.資料費包括復印及購置參考資料的費用；e.會議費召集有關業(yè)務會議的費用；f.旅差費；g.其他費用.1.1.2 設備購置費列出本月內支出的設備購置費,一般可分如下三類：a.購置軟件的名稱與金額；b.購置硬設備的名稱、型號、數(shù)量及金額；c.已有硬設備的折舊費.1.2 狀態(tài)說明本月內實際支出的經(jīng)費與方案相比擬,是超過了.相符合、還是不到方案數(shù)?如果與方案不一致,說明原因及準備采取的舉措.5 .下個月的工作方案6 .建議本月遇到的重要問題和應引起重視的問題以及因此產(chǎn)生的建議.1.11開發(fā)任務卡編者說明：工

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

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

50、:月報日期：年月日2 .進度2.1 任務任務：任務名任務描述：狀態(tài)：口完成口未完成與方案比擬:提前口按期口推遲推遲原因：2.2 事件事件：事件名一事件標志：與方案比擬：口提前口按期口推遲推遲原因：3 .資源消耗3.1工時治理用工時效勞用工時開發(fā)用工時總計：3.2機時計算機類型：用時：計算機類型：用時：計算機類型：用時：總計：用時：4 .經(jīng)費支出4.1 支持性經(jīng)費支出工資、獎金、補貼：培訓費：一資料費：6.建議1.14 工程進度周報編者說明：月報通常需要較詳細,而周報那么應該更簡潔,每周讓工程經(jīng)理花上1-2分鐘將一周的項目進度情況做一個通報是很必要的.本文檔模板就是一個例子,供大家參考.周期：2

51、003年月日2003年月日工程名稱：工程編號：工程經(jīng)理：工程發(fā)起人：工程成員：工程方案開始時間：工程實際開始時間：工程預計完成時間：現(xiàn)在預計完成時間：工程處于：初步方案階段需求分析階段開發(fā)階段工程狀態(tài)：按方案進度超方案進度進度延遲工程預計投入人力：人/日現(xiàn)在已投入人力：人/日預計共需投入人力：人/日工程遇到的困難和要解決的問題:1.15 工程開發(fā)總結報告GB標準編者說明：在工程中犯錯誤是正常的,但是犯同樣的錯誤那么是不可原諒的.因此,我們應該善于在工程中總結、在實踐中總結.在工程結束的時候,所有的成員聚集在一起,回憶一下工程的過程,總結出錯誤,找到解決的方法,總結出經(jīng)驗,將這些經(jīng)驗復用到下一個工程中.然后形本錢文檔,共享給大家.1 .引言1.1 編寫目的說明編寫這份工程開發(fā)總結報告的目的,指出預期的閱讀范圍.1.2 背景說明：a.本工程的名稱和所開發(fā)出來的軟件系統(tǒng)的名稱；b.此軟件的任務提出者、開發(fā)者、用戶及安裝此軟件的計算中央.1.3 定義列出本文件中用到的專門術語的定義和外文首字母組詞的原