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

1、文件編號：版本號： 1.0 工程總結(jié)報(bào) 告 告 部 門： 編 寫： 日 期： 公司文件修訂記錄時(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ā)工作評價(jià) 64.1 產(chǎn)品質(zhì)量評價(jià) 64.2 技術(shù)方法評價(jià) 65 工程管理工作評價(jià) 75.1 需求管理 75.2 方案管理 86 經(jīng)驗(yàn)教訓(xùn) 86.1

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

3、進(jìn)入平臺。工程質(zhì)量目標(biāo)：描述產(chǎn)品在交付時(shí)期應(yīng)到達(dá)的質(zhì)量要求，以及不同階段的缺陷率控制要求。例如：1. 交付時(shí)缺陷密度：0.2缺陷/KLOC ；2. 需求評審缺陷率：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í)行代碼用戶手冊頁3.2主要功能和性能研發(fā)工程專用。3.3項(xiàng)目遺留問題3.4項(xiàng)目性能數(shù)據(jù)進(jìn)度里程碑方案日期實(shí)際日期差異工程開始2004年3月 15日2004 年 3 月 15 日0需求基線2004 年 4 月 30 日2004 年 5 月 24 日-24系

4、統(tǒng)架構(gòu)設(shè)計(jì)2004 年 5 月 26 日2004 年 5 月 21 日5系統(tǒng)分析和設(shè)計(jì)基線2004年6月 11日2004 年 6 月 7 日4V2.5測試代碼基線2004 年 7 月 12 日2004 年 7 月 28 日-16V2.5版系統(tǒng)發(fā)布2004年8月1日客戶中期檢查和驗(yàn)收材料2004 年 9 月 30 日V3.0測試代碼基線2004年10月4日V3.0系統(tǒng)發(fā)布2004年11月 17日工程結(jié)束2004 年 11 月 30 日342工作量342.1 工作量分布工作量分布：可參考階段報(bào)告里的工作量分布圖規(guī)模研發(fā)工程專用，描述工程各階段方案規(guī)模與實(shí)際規(guī)模的比照情況，并分析發(fā)生偏差的原因階段里

5、程碑軟件估計(jì)規(guī)模功能點(diǎn)軟件實(shí)際規(guī)模功 能點(diǎn)方案軟件方案評審?fù)ㄟ^-需求需求規(guī)格說明書評審?fù)ㄟ^-設(shè)計(jì)系統(tǒng)設(shè)計(jì)說明書評審?fù)ㄟ^-編碼源代碼評審?fù)ㄟ^測試系統(tǒng)測試完成發(fā)布產(chǎn)品發(fā)布完成-344缺陷描述工程各階段發(fā)現(xiàn)的缺陷數(shù)，下面的例子是針對研發(fā)工程的，實(shí)施和維護(hù)工程可以根據(jù)各自工程的特點(diǎn)設(shè)置檢查點(diǎn)。檢查點(diǎn)缺陷發(fā)現(xiàn)數(shù)目用戶需求評審軟件需求評審架構(gòu)設(shè)計(jì)評審設(shè)計(jì)評審代碼評審測試方案需求設(shè)汁編碼測試實(shí)施缺陷分布4035302520151050圖示分析：根據(jù)分析圖進(jìn)一步分析現(xiàn)狀發(fā)生的原因。主要問題和風(fēng)險(xiǎn)可以參考工程的問題列表和風(fēng)險(xiǎn)列表的格式3.5可推行復(fù)用的軟件技術(shù)成果4工程開發(fā)工作評價(jià)4.1產(chǎn)品質(zhì)量評價(jià)缺陷數(shù)嚴(yán)重缺

6、陷數(shù)嚴(yán)重缺陷比率缺陷密度發(fā)布時(shí)目標(biāo)值產(chǎn)品質(zhì)量評價(jià):4.2技術(shù)方法評價(jià)總結(jié)該軟件工程或軟件產(chǎn)品開發(fā)時(shí)所采用的各項(xiàng)技術(shù)以下是例如：對開發(fā)工具的評價(jià)：UBS-HotBilling使用TT作為內(nèi)存數(shù)據(jù)庫，提高了應(yīng)用處理的性能。 試點(diǎn)割接上線后正常 運(yùn) 行，并且為 OCS系統(tǒng)上線提供了實(shí)踐依據(jù)，并積累了實(shí)施開發(fā)經(jīng)驗(yàn)。對框架技術(shù)的評價(jià)：從整個(gè)框架的整體使用效果來看并為到達(dá)預(yù)期的目的，我認(rèn)為主要是由以下原因造成的：框架本身存在有諸多不完善的地方，需要不斷地進(jìn)行改進(jìn)，但在改進(jìn)的過程中沒有進(jìn)行 嚴(yán)格的控制，導(dǎo)致框架的整體設(shè)計(jì)失控；框架本身有這樣那樣的問題，有些問題是目前無法解決的；框架是建構(gòu)在PFC的根底上的，

7、工程組成員對 PFC不是足夠的精通，為維護(hù)框架帶來 難 度。建議：模塊化是產(chǎn)品化的根底，也是降低本錢、提高開發(fā)效率保證軟件質(zhì)量的有效手段，需要有專人設(shè)計(jì)和維護(hù)框架。對設(shè)計(jì)方法的評價(jià)：信息化工程的整體設(shè)計(jì)是由工程組全體成員完成的，鑒于我們目前的設(shè)計(jì)水平，我看還可繼續(xù)這種方法，對設(shè)計(jì)的方法和思路進(jìn)行廣泛的借鑒， 但一定要樹立設(shè)計(jì) 的權(quán)威性，對設(shè)計(jì)的變更要進(jìn)行嚴(yán)格的控制。對團(tuán)隊(duì)開發(fā)的評價(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工程管理工作評價(jià)5.1需求管理研發(fā)工程專用需求完成情況最初的需求數(shù)：已實(shí)現(xiàn)的需求數(shù)：已刪除的需求數(shù)：已修訂的需求數(shù)：新增的需求數(shù)：需求變更情況總結(jié)工程的不同階段所發(fā)生的需求變更次數(shù)及發(fā)生變更的主要原因。變更發(fā)生的階段需求變更次數(shù)變更工作量從申請開始到變更結(jié)束發(fā)生