項目總結報告模板

1、文件編號：版本號：<項目名稱 >項目總結報告部 門：編 寫：審 核：批 準：日 期：公司文件修訂記錄時間作者主要修訂內容目錄1 引言錯誤 !未定義書簽。目的 錯誤 !未定義書簽。項目背景 錯誤 !未定義書簽。參考資料 錯誤 !未定義書簽。2 項目基本情況 錯誤 ! 未定義書簽。項目基本信息 錯誤 !未定義書簽。項目特征 錯誤 !未定義書簽。項目目標 錯誤 !未定義書簽。3 項目執(zhí)行結果 錯誤 ! 未定義書簽。交付產品 錯誤 !未定義書簽。主要功能和性能 錯誤 !未定義書簽。項目遺留問題 錯誤 !未定義書簽。項目性能數據 錯誤 !未定義書簽?？赏菩袕陀玫能浖夹g成果 . 錯誤 !未定

2、義書簽。4 項目開發(fā)工作評價 錯誤 ! 未定義書簽。產品質量評價 錯誤 !未定義書簽。技術方法評價 錯誤 !未定義書簽。5 項目管理工作評價 錯誤 ! 未定義書簽。需求管理 錯誤 !未定義書簽。計劃管理 錯誤 !未定義書簽。6 經驗教訓 錯誤 ! 未定義書簽。項目成功經驗 錯誤 !未定義書簽。項目失敗教訓 錯誤 !未定義書簽。項目組建議 錯誤 !未定義書簽。1 引言1. 1 目 的 闡明編寫本總結報告的目的，指出讀者對象。 1.2 項目背景 可包括本項目的來源、委托單位、開發(fā)單位和主管部門等。1. 3 參 考資 料2 項目基本情況2. 1 項 目基 本信 息項目中文全稱：客戶：項目經理：項目開

3、始日期：項目結束日期：項目成員：2.2 項目特征項目所屬類型：采用的生命周期模型：硬件平臺：應用領域：使用工具：開發(fā)語言：數據庫：2. 3 項 目目 標客戶目標：描述客戶對項目的總體要求， 以及需要達到的目標。 例如：1.2.3.應當解決當前系統存在的一些問題， 尤其是易用 性、可靠性的問題； 應當允許平臺的獨立性； 應當能從所有的客戶站點方便地進入平臺。項目質量目標：描述產品在交付時期應達到的質量要求，以及不同階段的缺陷率控制要求。例如：1.交付時缺陷密度：缺陷 /KLOC；2.需求評審缺陷率： 10% 15%；3.。3 項目執(zhí)行結果3.1 交付產品項目的主要交付產品列表產品名稱產品規(guī)模規(guī)模

4、單位完成日期是否通過驗收需求規(guī)格說明書25頁系統設計說明書72頁源代碼KLOC可執(zhí)行代碼用戶手冊頁3. 2 主 要功 能和 性能研發(fā)項目專用。 3.3 項目遺留問題3.4 項目性能數據進度里程碑計劃日期實際日期差異項目開始2004 年 3 月 15 日2004 年 3 月 15 日0需求基線2004 年 4 月 30 日2004 年 5 月 24 日-24系統架構設計2004 年 5 月 26 日2004 年 5 月 21 日5系統分析和設計基線2004 年 6 月 11 日2004 年 6月 7 日4測試代碼基線2004 年 7 月 12 日2004 年 7 月 28 日-16版系統發(fā)布20

5、04 年 8 月 1 日客戶中期檢查和驗收材料2004 年 9 月 30 日測試代碼基線2004 年 10 月 4 日系統發(fā)布2004 年 11 月 17 日項目結束2004 年 11 月 30 日3.4. 2工作量工作量分布工作量分布：可參考階段報告里的工作量分布圖規(guī)模研發(fā)項目專用，描述項目各階段計劃規(guī)模與實際規(guī)模的對比情況，并分析發(fā)生偏差的原因階段里程碑軟件估計規(guī)模（功能點）軟件實際規(guī)模（ 功能點 ）計劃軟件計劃評審通過-需求需求規(guī)格說明書評審通過-設計系統設計說明書評審通過-編碼源代碼評審通過-測試系統測試完成-發(fā)布產品發(fā)布完成-3.4. 4缺陷描述項目各階段發(fā)現的缺陷數，下面的例子是針

6、對研發(fā)項目的，實施和維護項目可以根據各自項目的特點設置檢查點。 檢查點缺陷發(fā)現數目用戶需求評審軟件需求評審架構設計評審設計評審代碼評審測試缺陷分布圖示分析：根據分析圖進一步分析現狀發(fā)生的原因。3.4. 5主要問題和風險可以參考項目的問題列表和風險列表的格式3. 5 可 推行 復用 的軟件技 術成 果4 項目開發(fā)工作評價4. 1 產 品質 量評 價缺陷數嚴重缺陷數嚴重缺陷比率缺陷密度發(fā)布時目標值產品質量評價：4. 2 技 術方 法評 價總結該軟件項目或軟件產品開發(fā)時所采用的各項技術以下是示例：對開發(fā)工具的評價：UBS-HotBilling 使用 TT作為內存數據庫，提高了應用處理的性能。 試點割

7、接上線后正常 運行，并且為 OCS系統上線提供了實踐依據，并積累了實施開發(fā)經驗。對框架技術的評價：從整個框架的整體使用效果來看并為達到預期的目的，我認為主要是由 以下原因造成的：框架本身存在有諸多不完善的地方，需要不斷地進行改進，但在改進的過程中沒有進行 嚴格的控制，導致框架的整體設計失控； 框架本身有這樣那樣的問題，有些問題是目前無法解決的；框架是建構在 PFC的基礎上的，項目組成員對 PFC不是足夠的精通，為維護框架帶來難度。 建議：模塊化是產品化的基礎，也是降低成本、提高開發(fā)效率保證軟件質量的有效手段， 需要有專人設計和維護框架。對設計方法的評價：信息化項目的整體設計是由項目組全體成員完

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