項目總結(jié)報告模板

1、文件編號：版本號： 1.0<項目名稱 >項目總結(jié)報告部門：編寫：審核：批準：日期：公司文件修訂記錄時間作者主要修訂內(nèi)容YYYY .MM.DDXX 項目總結(jié)報告版本： X.X目錄1 .21.1目的 .1.2項目背景 .1.3參考資料 .2 項目基本情況 .2.1項目基本信息.2.2項目特征 .2.3項目目標 .3 項目執(zhí)行結(jié)果 .3.1交付產(chǎn)品 .3.2主要功能和性能.3.3項目遺留問題.3.4項目性能數(shù)據(jù).3.5可推行復用的軟件技術(shù)成果.4 項目開發(fā)工作評價.4.1產(chǎn)品質(zhì)量評價.4.2技術(shù)方法評價.5 項目管理工作評價5.1需求管理 .5.2計劃管理 .6 經(jīng)驗教訓 .6.1項目成

2、功經(jīng)驗.6.2項目失敗教訓.6.3項目組建議 .引言22222233334466667788888Page 1 of 10XX 項目總結(jié)報告版本：X.X1 引言1.1 目的 闡明編寫本總結(jié)報告的目的，指出讀者對象。1.2 項目背景 可包括本項目的來源、委托單位、開發(fā)單位和主管部門等。1.3 參考資料2 項目基本情況2.1 項目基本信息項目中文全稱：客戶：項目經(jīng)理：項目開始日期：項目結(jié)束日期：項目成員：2.2 項目特征項目所屬類型：采用的生命周期模型：硬件平臺：應用領(lǐng)域：使用工具：開發(fā)語言：數(shù)據(jù)庫：Page 2 of 10XX 項目總結(jié)報告版本：X.X2.3 項目目標客戶目標：描述客戶對項目的總

3、體要求，以及需要達到的目標。例如：1.應當解決當前系統(tǒng)存在的一些問題，尤其是易用性、可靠性的問題；2. 應當允許平臺的獨立性；3. 應當能從所有的客戶站點方便地進入平臺。項目質(zhì)量目標：描述產(chǎn)品在交付時期應達到的質(zhì)量要求，以及不同階段的缺陷率控制要求。例如：1. 交付時缺陷密度： 0.2 缺陷 /KLOC ；2.需求評審缺陷率：10% 15% ；3. ? 。3 項目執(zhí)行結(jié)果3.1 交付產(chǎn)品項目的主要交付產(chǎn)品列表：產(chǎn)品名稱產(chǎn)品規(guī)模規(guī)模單位完成日期是否通過驗收需求規(guī)格說明書25頁系統(tǒng)設(shè)計說明書72頁源代碼KLOC可執(zhí)行代碼用戶手冊頁3.2 主要功能和性能研發(fā)項目專用。Page 3 of 10XX 項

4、目總結(jié)報告版本：X.X3.3 項目遺留問題3.4 項目性能數(shù)據(jù)3.4.1進度里程碑計劃日期實際日期差異項目開始2004年3月15日2004年3月15日0需求基線2004年4月30日2004年5月24日-24系統(tǒng)架構(gòu)設(shè)計2004年5月26日2004年5月21日5系統(tǒng)分析和設(shè)計基線2004年6月11日2004年6月7日4V2.5測試代碼基線2004年7月12日2004年7月28日-16V2.5版系統(tǒng)發(fā)布2004 年8月1日客戶中期檢查和驗收2004年9月30日材料V3.0測試代碼基線2004年10月4日V3.0系統(tǒng)發(fā)布2004 年 11 月 17日項目結(jié)束2004 年 11 月 30日工作量工作量

5、分布工作量分布：可參考階段報告里的工作量分布圖規(guī)模研發(fā)項目專用，描述項目各階段計劃規(guī)模與實際規(guī)模的對比情況，并分析發(fā)生偏差的原因Page 4 of 10XX 項目總結(jié)報告版本：X.X階段里程碑軟件估計規(guī)模軟件實際規(guī)模(功能點 )（功能點）計劃軟件計劃評審通過-需求需求規(guī)格說明書評審通過-設(shè)計系統(tǒng)設(shè)計說明書評審通過-編碼源代碼評審通過-測試系統(tǒng)測試完成-發(fā)布產(chǎn)品發(fā)布完成-缺陷描述項目各階段發(fā)現(xiàn)的缺陷數(shù)，下面的例子是針對研發(fā)項目的，實施和維護項目可以根據(jù)各自項目的特點設(shè)置檢查點。檢查點缺陷發(fā)現(xiàn)數(shù)目用戶需求評審軟件需求評審架構(gòu)設(shè)計評審設(shè)計評審代碼評審測試缺陷分布4035302520缺陷分布15105

6、0計劃需求設(shè)計編碼測試實施圖示分析：根據(jù)分析圖進一步分析現(xiàn)狀發(fā)生的原因。Page 5 of 10XX 項目總結(jié)報告版本：X.X主要問題和風險可以參考項目的問題列表和風險列表的格式3.5 可推行復用的軟件技術(shù)成果4 項目開發(fā)工作評價4.1 產(chǎn)品質(zhì)量評價缺陷數(shù)嚴重缺陷數(shù)嚴重缺陷比率缺陷密度發(fā)布時目標值產(chǎn)品質(zhì)量評價：4.2 技術(shù)方法評價總結(jié)該軟件項目或軟件產(chǎn)品開發(fā)時所采用的各項技術(shù)以下是示例：對開發(fā)工具的評價：UBS-HotBilling使用 TT 作為內(nèi)存數(shù)據(jù)庫，提高了應用處理的性能。試點割接上線后正常運行，并且為OCS 系統(tǒng)上線提供了實踐依據(jù)，并積累了實施開發(fā)經(jīng)驗。對框架技術(shù)的評價：從整個框架的

7、整體使用效果來看并為達到預期的目的，我認為主要是由以下原因造成的：框架本身存在有諸多不完善的地方，需要不斷地進行改進，但在改進的過程中沒有進行嚴格的控制，導致框架的整體設(shè)計失控；框架本身有這樣那樣的問題，有些問題是目前無法解決的；框架是建構(gòu)在PFC 的基礎(chǔ)上的，項目組成員對PFC 不是足夠的精通，為維護框架帶來難度。建議：模塊化是產(chǎn)品化的基礎(chǔ)，也是降低成本、提高開發(fā)效率保證軟件質(zhì)量的有效手段，需要有專人設(shè)計和維護框架。對設(shè)計方法的評價：信息化項目的整體設(shè)計是由項目組全體成員完成的，鑒于我們目前的設(shè)Page 6 of 10XX 項目總結(jié)報告版本：X.X計水平，我看還可繼續(xù)這種方法，對設(shè)計的方法和

8、思路進行廣泛的借鑒，但一定要樹立設(shè)計的權(quán)威性，對設(shè)計的變更要進行嚴格的控制。對團隊開發(fā)的評價：從整體上講我們這個團隊的能力還可以，但我認為它的生產(chǎn)效率并不高也就是說團隊的整體建設(shè)不好，沒有明確的學習方向分工，使整個團隊在這段時間里整體能力沒有太大的提高，我以前很想把我們的團隊培養(yǎng)成那種學習型的優(yōu)秀團隊，可惜事與愿違這項工作沒有取得什么實效。5 項目管理工作評價5.1 需求管理研發(fā)項目專用需求完成情況最初的需求數(shù)：已實現(xiàn)的需求數(shù)：已刪除的需求數(shù)：已修訂的需求數(shù)：新增的需求數(shù)：需求變更情況總結(jié)項目的不同階段所發(fā)生的需求變更次數(shù)及發(fā)生變更的主要原因。變更發(fā)生的階段需求變更次數(shù)變更工作量（從申請開始到變更結(jié)束發(fā)生的工作量）用戶需求定義軟件需求分析設(shè)計編碼