項目總結(jié)報告總結(jié)歸納

1、文件編號:V項目名稱項目總結(jié)報告部 門: 編 寫: 審 核: 批 準(zhǔn): 日 期：公司文件修訂記錄時間作者主要修訂內(nèi)容1引言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.2.3.)應(yīng)當(dāng)解決當(dāng)前系統(tǒng)存在的一些問題，尤 其是易用性、可靠性的

2、問題；應(yīng)當(dāng)允許平臺的獨立性；應(yīng)當(dāng)能從所有的客戶站點方便地進(jìn)入 平臺。項目質(zhì)量目標(biāo)：（描述產(chǎn)品在交付時期應(yīng)達(dá)到的質(zhì)量要求，以 及不同階段的缺陷率控制要求。例如：1. 交付時缺陷密度：0.2缺陷/KL0C；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)度里程碑計劃日期實際日期差異項目開始2004 年 3 月 15n2004 年 3 月

3、15日0需求基線2004 年 4 月 30n2004 年 5 月 24日-24系統(tǒng)架構(gòu)設(shè)計2004 年 5 月 262004 年 5 月 21日5系統(tǒng)分析和設(shè)計 基線2004 年 6 月 11n2004年6月7日4V2.5測試代碼基 線2004 年 7 月 12n2004 年 7 月 28日-16V2. 5版系統(tǒng)發(fā)布2004年8月1n客戶中期檢查和驗收材料2004 年 9 月 30nV3.0測試代碼基 線2004 年 10 月 4V3.0系統(tǒng)發(fā)布2004年11月17日項目結(jié)束2004年11月30日3. 4.2工作量34. 2. 1工作量分布工作量分布：（可參考階段報告里的工作量分布圖）3. 4

4、. 3規(guī)模并分析發(fā)（研發(fā)項目專用，描述項目各階段計劃規(guī)模與實際規(guī)模的對比情況,生偏差的原因）階段里程碑軟件估計規(guī)模（功能點）軟件實際規(guī)模（功能點）計劃軟件計劃評審?fù)ㄟ^需求需求規(guī)格說明書評審?fù)ㄟ^設(shè)計系統(tǒng)設(shè)計說明書評審?fù)ㄟ^編碼源代碼評審?fù)ㄟ^測試系統(tǒng)測試完成發(fā)布產(chǎn)品發(fā)布完成項階段現(xiàn)的陷數(shù),面的3. 4. 4缺子是針對研發(fā)項目的,實施和維護項目可以根據(jù)各自項目的特點設(shè)置檢查點。檢查點缺陷發(fā)現(xiàn)數(shù)目用戶需求評審軟件需求評審架構(gòu)設(shè)計評審設(shè)計評審代碼評審測試圖示分析：1根據(jù)分析圖進(jìn)一步分析現(xiàn)狀發(fā)生的原因。）3. 4. 5主要問題和風(fēng)險（可以參考項目的問題列表和風(fēng)險列表的格式）3.5可推行復(fù)用的軟件技術(shù)成果4項

5、目開發(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ù)）（以下是示例:）對開發(fā)工具的評價: 1勺0詣訂口屈使用玖作為內(nèi)存數(shù)據(jù)庫,提高了應(yīng)用處理的性能。試 點割接上線后正常運行,并且為OCS系統(tǒng)上線提供了實踐依據(jù),并積累 了實施開發(fā)經(jīng)驗。對框架技術(shù)的評價:從整個框架的整體使用效果來看并為達(dá)到預(yù)期的目的, 我認(rèn)為主要是由以下原因造成的:框架本身存在有諸多不完善的地方,需要不斷地進(jìn)行改進(jìn),但在改進(jìn)的過程中沒有進(jìn)行嚴(yán)格的控制,導(dǎo)致框架的整體設(shè)計失控;框架本身有這樣那樣的問題,有些問題是目前無法

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