項目的地地總結(jié)報告材料實用模板

1、實用標準文案文件編號：項目總結(jié)報告部門：編寫：審核：批準：日期：YYYY.MM.DD公司精彩文檔實用標準文案文件修訂記錄時間作者主要修訂內(nèi)容YYYY.MM.DD精彩文檔實用標準文案目錄1 .引言21.1目的 .21.2項目背景 .21.3參考資料 .22項目基本情況 .22.1項目基本信息 .22.2項目特征 .22.3項目目標 .33項目執(zhí)行結(jié)果 .33.1交付產(chǎn)品 .33.2主要功能和性能 .33.3項目遺留問題 .43.4項目性能數(shù)據(jù) .43.5可推行復用的軟件技術(shù)成果 . .64項目開發(fā)工作評價 .64.1產(chǎn)品質(zhì)量評價 .64.2技術(shù)方法評價 .65項目管理工作評價 .75.1需求管理

2、 .75.2計劃管理 .86經(jīng)驗教訓 .86.1項目成功經(jīng)驗 .86.2項目失敗教訓 .86.3項目組建議 .8精彩文檔實用標準文案1 引言1. 1 目的 闡明編寫本總結(jié)報告的目的，指出讀者對象。1. 2 項目背景 可包括本項目的來源、委托單位、開發(fā)單位和主管部門等。1. 3 參考資料2 項目基本情況2. 1 項目基本信息項目中文全稱：客戶：項目經(jīng)理：項目開始日期：項目結(jié)束日期：項目成員：2. 2 項目特征項目所屬類型：采用的生命周期模型：硬件平臺：應用領域：使用工具：開發(fā)語言：數(shù)據(jù)庫：精彩文檔實用標準文案2. 3 項目目標客戶目標：描述客戶對項目的總體要求，以及需要達到的目標。例如：1.應當

3、解決當前系統(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)設計說明書72頁源代碼KLOC可執(zhí)行代碼用戶手冊頁3. 2 主要功能和性能研發(fā)項目專用。 精彩文檔實用標準文案3. 3 項目遺留問題3. 4 項目性能數(shù)據(jù)3. 4

4、.1進度里程碑計劃日期實際日期差異項目開始2004年3月15日2004年3月15日0需求基線2004年4月30日2004年5月24日-24系統(tǒng)架構(gòu)設計2004年5月26日2004年5月21日5系統(tǒng)分析和設計基線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日3. 4. 2工作量3.4.2.1工作量分布工作量分布：可參考階段報告里的工

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

6、圖進一步分析現(xiàn)狀發(fā)生的原因。精彩文檔實用標準文案3. 4. 5主要問題和風險可以參考項目的問題列表和風險列表的格式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、造成的：框架本身存在有諸多不完善的地方，需要不斷地進行改進，但在改進的過程中沒有進行嚴格的控制，導致框架的整體設計失控；框架本身有這樣那樣的問題，有些問題是目前無法解決的；框架是建構(gòu)在 PFC的基礎上的，項目組成員對PFC不是足夠的精通，為維護框架帶來難度。建議：模塊化是產(chǎn)品化的基礎，也是降低成本、提高開發(fā)效率保證軟件質(zhì)量的有效手段，需要有專人設計和維護框架。對設計方法的評價：信息化項目的整體設計是由項目組全體成員完成的，鑒于我們目前的設精彩文檔實用標準文案計水平，我看還可繼續(xù)這種方法，對設計的方法和思路進行廣泛的借鑒，但一定要樹立設計的權(quán)威性，對設計的變更要進行嚴格的控制。對團隊開發(fā)的評價：從整體上講我們這個團隊的能力還可以，但我認為它的生產(chǎn)效率并不高也就是說團隊的整體建設不好，沒有明確的學習方向分工，使整個團隊在這段時間里整體能力沒有太大的提高，我以前很想把我們的團隊培養(yǎng)成那種學習型的優(yōu)秀團隊，可惜事與愿違這項工作沒有取得什么實效。5 項目管理工作評價5. 1 需求管理研發(fā)項目專用5. 1. 1需求完成情況最初的需求數(shù)：已實現(xiàn)的需求數(shù)：已刪除的需求數(shù)：已修訂的需求數(shù)：新增的需求數(shù)：5. 1. 2需求變更情況總結(jié)項目的不同階段所發(fā)生的需求變更次數(shù)及發(fā)生變更的主要原因。變更發(fā)生的階段需求變更次數(shù)變更工作量（從申請開始到變更結(jié)束發(fā)生的工作量）用戶需求