1、文件編號：版本號：1.0項目名稱項目總結(jié)報告部 門： 編 寫： 審 核： 批 準(zhǔn)： 日 期：YYYY.M M.DD公司文件修訂記錄時間作者主要修訂內(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ā)工作評價64.1 產(chǎn)品質(zhì)量評價64.2 技術(shù)方法評價 65 項目管理工作評價75.1 需求管理75.2 計劃管理86 經(jīng)驗教訓(xùn)8

2、6.1 項目成功經(jīng)驗86.2 項目失敗教訓(xùn)86.3 項目組建議81引言1.1目的闡明編寫本總結(jié)報告的目的，指出讀者對象。1.2項目背景可包括本項目的來源、委托單位、開發(fā)單位和主管部門等。1.3參考資料2項目基本情況2.1項目基本信息項目中文全稱：客戶：項目經(jīng)理：項目開始日期：項目結(jié)束日期：項目成員：2.2項目特征項目所屬類型：采用的生命周期模型：硬件平臺：應(yīng)用領(lǐng)域：使用工具：開發(fā)語言：數(shù)據(jù)庫：2.3項目目標(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)品在交付時期應(yīng)達(dá)到的質(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ā)項目專用。3.3項目遺留問題3.4項目性能數(shù)據(jù)3.4.1進(jìn)度里程碑計劃日期實(shí)際日期差異項目開始2004年3月15日2004年3月15日0需求基線2004年4月30日2004年5月24日-24系統(tǒng)架構(gòu)設(shè)計2004年5月26

4、日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日3.4.2工作量342.1 工作量分布工作量分布：可參考階段報告里的工作量分布圖3.4.3規(guī)模研發(fā)項目專用，描述項目各階段計劃規(guī)模與實(shí)際規(guī)模的對比情況，并分析發(fā)生偏差的原因階段里程碑軟件估計規(guī)模（功能點(diǎn)）軟件實(shí)際規(guī)模（功能點(diǎn)）計劃軟件計劃評審?fù)ㄟ^-需求需求規(guī)格說明書

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

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

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