項(xiàng)目總結(jié)報(bào)告模板

1、文件編號(hào)：版本號(hào)：1.0工程名稱工程總結(jié)報(bào)告部 門： 編 寫： 日 期：YYYY.M M.DD公司文件修訂記錄時(shí)間作者主要修訂內(nèi)容YYYY .MM.DD目 錄1 引言21.1 目的21.2 工程背景21.3 參考資料22 工程根本情況22.1 工程根本信息22.2 工程特征22.3 工程目標(biāo) 33 工程執(zhí)行結(jié)果 33.1 交付產(chǎn)品33.2 主要功能和性能 33.3 工程遺留問題43.4 工程性能數(shù)據(jù)43.5 可推行復(fù)用的軟件技術(shù)成果 64 工程開發(fā)工作評(píng)價(jià)64.1 產(chǎn)品質(zhì)量評(píng)價(jià)64.2 技術(shù)方法評(píng)價(jià) 65 工程管理工作評(píng)價(jià)75.1 需求管理75.2 方案管理86 經(jīng)驗(yàn)教訓(xùn)86.1 工程成功經(jīng)驗(yàn)

2、86.2 工程失敗教訓(xùn)86.3 工程組建議81引言1.1目的說明編寫本總結(jié)報(bào)告的目的，指出讀者對(duì)象。1.2工程背景可包括本工程的來源、委托單位、開發(fā)單位和主管部門等。1.3參考資料2工程根本情況2.1工程根本信息工程中文全稱：客戶：工程經(jīng)理：工程開始日期：工程結(jié)束日期：工程成員：2.2工程特征工程所屬類型：采用的生命周期模型：硬件平臺(tái)：應(yīng)用領(lǐng)域：使用工具：開發(fā)語言：數(shù)據(jù)庫：2.3工程目標(biāo)客戶目標(biāo)：描述客戶對(duì)工程的總體要求，以及需要到達(dá)的目標(biāo)。 例如：1.2.3.應(yīng)當(dāng)解決當(dāng)前系統(tǒng)存在的一些問題，尤其是易用性、可靠性的問題；應(yīng)當(dāng)允許平臺(tái)的獨(dú)立性；應(yīng)當(dāng)能從所有的客戶站點(diǎn)方便地進(jìn)入平臺(tái)。工程質(zhì)量目標(biāo)：

3、描述產(chǎn)品在交付時(shí)期應(yīng)到達(dá)的質(zhì)量要求，以及不冋階段的缺陷率控制要求。例如：1.交付時(shí)缺陷密度：0.2缺陷/KLOC ;2.需求評(píng)審缺陷率：10%15%;3.。3工程執(zhí)行結(jié)果3.1交付產(chǎn)品工程的主要交付產(chǎn)品列表產(chǎn)品名稱產(chǎn)品規(guī)模規(guī)模單位完成日期是否通過驗(yàn)收需求規(guī)格說明書25頁系統(tǒng)設(shè)計(jì)說明書72頁源代碼KLOC可執(zhí)行代碼用戶手冊(cè)頁3.2主要功能和性能研發(fā)工程專用。3.3工程遺留問題3.4工程性能數(shù)據(jù)進(jìn)度里程碑方案日期實(shí)際日期差異工程開始2004年3月15日2004年3月15日0需求基線2004年4月30日2004年5月24日-24系統(tǒng)架構(gòu)設(shè)計(jì)2004年5月26日2004年5月21日5系統(tǒng)分析和設(shè)計(jì)基線

4、2004年6月11日2004年6月7日4V2.5測(cè)試代碼基線2004年7月12日2004年7月28日-16V2.5版系統(tǒng)發(fā)布2004年8月1日客戶中期檢查和驗(yàn)收材料2004年9月30日V3.0測(cè)試代碼基線2004年10月4日V3.0系統(tǒng)發(fā)布2004年11月17日工程結(jié)束2004年11月30日工作量3.4.2.1 工作量分布工作量分布：可參考階段報(bào)告里的工作量分布圖規(guī)模研發(fā)工程專用，描述工程各階段方案規(guī)模與實(shí)際規(guī)模的比照情況，并分析發(fā)生偏差的原因階段里程碑軟件估計(jì)規(guī)模功能點(diǎn)軟件實(shí)際規(guī)模功能點(diǎn)方案軟件方案評(píng)審?fù)ㄟ^-需求需求規(guī)格說明書評(píng)審?fù)ㄟ^-設(shè)計(jì)系統(tǒng)設(shè)計(jì)說明書評(píng)審?fù)ㄟ^-編碼源代碼評(píng)審?fù)ㄟ^-測(cè)試系統(tǒng)

5、測(cè)試完成-發(fā)布產(chǎn)品發(fā)布完成-缺陷描述工程各階段發(fā)現(xiàn)的缺陷數(shù)，下面的例子是針對(duì)研發(fā)工程的，實(shí)施和維護(hù)工程可以根據(jù)各自工程的特點(diǎn)設(shè)置檢查點(diǎn)。檢查點(diǎn)缺陷發(fā)現(xiàn)數(shù)目用戶需求評(píng)審軟件需求評(píng)審架構(gòu)設(shè)計(jì)評(píng)審設(shè)計(jì)評(píng)審代碼評(píng)審測(cè)試缺陷分布圖示分析：根據(jù)分析圖進(jìn)一步分析現(xiàn)狀發(fā)生的原因。主要問題和風(fēng)險(xiǎn)可以參考工程的問題列表和風(fēng)險(xiǎn)列表的格式3.5可推行復(fù)用的軟件技術(shù)成果4工程開發(fā)工作評(píng)價(jià)4.1產(chǎn)品質(zhì)量評(píng)價(jià)缺陷數(shù)嚴(yán)重缺陷數(shù)嚴(yán)重缺陷比率缺陷密度發(fā)布時(shí)目標(biāo)值產(chǎn)品質(zhì)量評(píng)價(jià):4.2技術(shù)方法評(píng)價(jià)總結(jié)該軟件工程或軟件產(chǎn)品開發(fā)時(shí)所采用的各項(xiàng)技術(shù)以下是例如：對(duì)開發(fā)工具的評(píng)價(jià)：? UBS-HotBilling使用TT作為內(nèi)存數(shù)據(jù)庫，提高了

6、應(yīng)用處理的性能。試點(diǎn)割接上線后正常 運(yùn)行，并且為OCS系統(tǒng)上線提供了實(shí)踐依據(jù)，并積累了實(shí)施開發(fā)經(jīng)驗(yàn)。對(duì)框架技術(shù)的評(píng)價(jià)：從整個(gè)框架的整體使用效果來看并為到達(dá)預(yù)期的目的，我認(rèn)為主要是由 以下原因造成的：? 框架本身存在有諸多不完善的地方，需要不斷地進(jìn)行改進(jìn)，但在改進(jìn)的過程中沒有進(jìn)行 嚴(yán)格的控制，導(dǎo)致框架的整體設(shè)計(jì)失控；? 框架本身有這樣那樣的問題，有些問題是目前無法解決的；? 框架是建構(gòu)在PFC的根底上的，工程組成員對(duì)PFC不是足夠的精通，為維護(hù)框架帶來 難度。? 建議：模塊化是產(chǎn)品化的根底，也是降低本錢、提高開發(fā)效率保證軟件質(zhì)量的有效手段， 需要有專人設(shè)計(jì)和維護(hù)框架。對(duì)設(shè)計(jì)方法的評(píng)價(jià)：信息化工程

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