這篇關(guān)于2013項目總結(jié)報告模板的文章，是特地為大家整理的，希望對大家有所幫助！
1.1 目的
[闡明編寫本總結(jié)報告的目的，指出讀者對象。]
1.2 項目背景
[可包括本項目的來源、委托單位、開發(fā)單位和主管部門等。]
1.3 參考資料
2 項目基本情況
2.1 項目基本信息
[包括項目名稱、項目代號、項目負(fù)責(zé)人、項目組成員、報告時間段、項目階段等信息]
項目中文全稱：
項目中文簡稱：
項目英文全稱：
項目英文簡稱：
客戶：
項目組長：
項目主管：
項目實際開始日期：
項目實際結(jié)束日期：
項目成員：
2.2 項目特征
項目所屬類型：
采用的生命周期模型：
硬件平臺：
應(yīng)用領(lǐng)域：
使用工具：
開發(fā)語言：
數(shù)據(jù)庫：
2.3 項目目標(biāo)
客戶目標(biāo)： 〔描述客戶對項目的總體要求，以及需要達到的目標(biāo)。例如：
1. 應(yīng)當(dāng)解決當(dāng)前系統(tǒng)存在的一些問題，尤其是易用性、可靠性的問題;
2. 應(yīng)當(dāng)允許平臺的獨立性;
3. 應(yīng)當(dāng)能從所有的客戶站點方便地進入平臺。〕
組織目標(biāo)： 〔描述清楚組織對項目的總體要求，以及需要達到的目標(biāo)。例如：
1. 應(yīng)當(dāng)在CMMI4級執(zhí)行;
2. 應(yīng)當(dāng)達到和獲得基于Web的移植體系;
3. 應(yīng)當(dāng)產(chǎn)生可重用模型/代碼/設(shè)計思想，定義開發(fā)標(biāo)準(zhǔn);
4. 應(yīng)當(dāng)從Web的應(yīng)用開發(fā)獲得經(jīng)驗;
5. 應(yīng)當(dāng)達到產(chǎn)品化的要求?！?BR> 研究目標(biāo)： 〔對于研究性項目，應(yīng)描述清楚項目的研究目標(biāo)。例如：
1. 應(yīng)當(dāng)產(chǎn)生X篇高水平論文;
2. 應(yīng)當(dāng)產(chǎn)生X本專著;
3. 應(yīng)當(dāng)獲得X專利或軟件著作權(quán)?！?BR> 項目質(zhì)量目標(biāo)： 〔描述產(chǎn)品在交付時期應(yīng)達到的質(zhì)量要求，以及不同階段的缺陷率控制要求。例如：
1. 交付時缺陷密度：0.2缺陷/KLOC;
2. 需求評審缺陷率：10%～15%;
3. ……?！?BR> 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 主要功能和性能
3.3 項目過程
〔描述項目的實際過程，包括管理過程和工程過程，盡量用圖示說明，對裁剪或變更的流程應(yīng)說明裁剪或變更的原因、和裁剪或變更后的情況是什么?！?BR> 3.3.1 項目開發(fā)過程
〔說明本項目采用的開發(fā)過程，包括增加/修改/刪除了什么活動?！?BR> 3.3.2 過程裁剪注釋
遵循的標(biāo)準(zhǔn)過程/活動 裁剪注釋
〔應(yīng)說明增加/修改/刪除了什么活動〕 偏離原因
〔應(yīng)說明增加/修改/刪除了某個活動的原因〕
市場(客戶)調(diào)研階段 需求獲取
項目立項
項目定義階段 項目計劃
需求分析
產(chǎn)品(項目)研制階段 設(shè)計
編碼及單元測試
產(chǎn)品集成測試
評審
產(chǎn)品(項目)測試階段 產(chǎn)品測試
測試
產(chǎn)品(項目)驗收及發(fā)布階段 系統(tǒng)試運行
項目結(jié)項
產(chǎn)品技術(shù)支持及維護階段 產(chǎn)品技術(shù)支持及維護
貫穿項目全周期的過程 項目跟蹤
風(fēng)險管理
需求管理
過程和產(chǎn)品質(zhì)量保證
配置管理
度量與分析
4 項目開發(fā)工作評價
4.1 生產(chǎn)率評價
構(gòu)件/模塊名稱 代碼行(千行) 工作量 代碼行/工作量
甘特圖
過程定義
等等
合計
平均生產(chǎn)率及其評價：
4.2 技術(shù)方案評價
〔總結(jié)該軟件項目或軟件產(chǎn)品開發(fā)時所采用的各項技術(shù)〕
〔以下是示例：〕
對開發(fā)工具的評價：這里主要是對開發(fā)工具PowerBuilder8.0和數(shù)據(jù)庫工具的評價。
對PowerBuilder8.0的評價：在整個項目的開發(fā)過程中，由于此工具引發(fā)了諸多爭議，我認(rèn)為pb在C/S架構(gòu)是由其獨特優(yōu)勢的，就是從開發(fā)成本、B/S和面向?qū)ο髞碚f其也有獨到之處，因此我認(rèn)為開發(fā)工具都有其優(yōu)劣，關(guān)鍵看我們是否精通。
對數(shù)據(jù)庫工具的評價：我們現(xiàn)在用的數(shù)據(jù)庫工具只是停留在表、視圖和存儲過程簡單使用，對數(shù)據(jù)庫的深層研究和SQL語句的優(yōu)化現(xiàn)在做的不夠，當(dāng)然還有表設(shè)計的合理性都需要加強，我建議部門或項目組可以
專門培養(yǎng)往數(shù)據(jù)庫研究和發(fā)展的人員，從而提高我們產(chǎn)品的開發(fā)、運行速度和穩(wěn)定性并可提高整個部門開發(fā)人員的技術(shù)水平。
對框架技術(shù)的評價：從整個框架的整體使用效果來看并為達到預(yù)期的目的，我認(rèn)為主要是由以下原因造成的：
框架本身存在有諸多不完善的地方，需要不斷地進行改進，但在改進的過程中沒有進行嚴(yán)格的控制，導(dǎo)致框架的整體設(shè)計失控;
框架本身有這樣那樣的問題，有些問題是目前無法解決的;
框架是建構(gòu)在PFC的基礎(chǔ)上的，項目組成員對PFC不是足夠的精通，為維護框架帶來難度。
建議：模塊化是產(chǎn)品化的基礎(chǔ)，也是降低成本、提高開發(fā)效率保證軟件質(zhì)量的有效手段，需要有專人設(shè)計和維護框架。
對設(shè)計方法的評價：信息化項目的整體設(shè)計是由項目組全體成員完成的，鑒于我們目前的設(shè)計水平，我看還可繼續(xù)這種方法，對設(shè)計的方法和思路進行廣泛的借鑒，但一定要樹立設(shè)計的權(quán)威性，對設(shè)計的變更要進行嚴(yán)格的控制。
對團隊開發(fā)的評價：從整體上講我們這個團隊的能力還可以，但我認(rèn)為它的生產(chǎn)效率并不高也就是說團隊的整體建設(shè)不好，沒有明確的學(xué)習(xí)方向分工，使整個團隊在這段時間里整體能力沒有太大的提高，我以前很想把我們的團隊培養(yǎng)成那種學(xué)習(xí)型的優(yōu)秀團隊，可惜事與愿違這項工作沒有取得什么實效。
5 項目管理工作評價
5.1 需求管理
5.1.1 需求完成情況
最初建議的需求數(shù)：
納入基線的需求數(shù)：
已實現(xiàn)的需求數(shù)：
已驗證的需求數(shù)：
已刪除的需求數(shù)：
已修訂的需求數(shù)：
新增的需求數(shù)：
5.1.2 需求變更情況
〔總結(jié)項目的不同階段所發(fā)生的需求變更次數(shù)及發(fā)生變更的主要原因?！?BR> 變更發(fā)生的階段 需求變更次數(shù) 變更工作量
(從申請開始到變更結(jié)束發(fā)生的工作量)
用戶需求定義
軟件需求分析
設(shè)計
編碼
測試
維護
需求變更的主要原因：
5.2 計劃管理
5.2.1 計劃變更情況
序號 變更發(fā)生階段 變更原因 變更內(nèi)容 變更是否允許
1
2
3
6 項目重大事件
〔列出項目期間或項目本階段中發(fā)生的重大事件〕
時間 地點 事件 重要參加人員
7 驗收準(zhǔn)備工作
1、 驗收要求：項目經(jīng)理與客戶確定驗收要求
2、 驗收文檔準(zhǔn)備情況：驗收文檔內(nèi)容及完成情況，明確后期可能需要完善的文檔。
8 經(jīng)驗教訓(xùn)
8.1 項目問題/缺陷原因分析
對項目問題進行原因分析
注：總結(jié)項目產(chǎn)生的問題，分析其中可以通過完善過程體系的方法來避免的問題。
對產(chǎn)品缺陷進行原因分析
注：總結(jié)項目產(chǎn)品發(fā)現(xiàn)的缺陷，分析是否可在開發(fā)過程中避免，或通過增加評審檢查單和測試用例檢查單等方法可避免。
8.2 總結(jié)經(jīng)驗教訓(xùn)
8.3 項目推薦工作產(chǎn)品
注：可推薦本
1.1 目的
[闡明編寫本總結(jié)報告的目的，指出讀者對象。]
1.2 項目背景
[可包括本項目的來源、委托單位、開發(fā)單位和主管部門等。]
1.3 參考資料
2 項目基本情況
2.1 項目基本信息
[包括項目名稱、項目代號、項目負(fù)責(zé)人、項目組成員、報告時間段、項目階段等信息]
項目中文全稱：
項目中文簡稱：
項目英文全稱：
項目英文簡稱：
客戶：
項目組長：
項目主管：
項目實際開始日期：
項目實際結(jié)束日期：
項目成員：
2.2 項目特征
項目所屬類型：
采用的生命周期模型：
硬件平臺：
應(yīng)用領(lǐng)域：
使用工具：
開發(fā)語言：
數(shù)據(jù)庫：
2.3 項目目標(biāo)
客戶目標(biāo)： 〔描述客戶對項目的總體要求，以及需要達到的目標(biāo)。例如：
1. 應(yīng)當(dāng)解決當(dāng)前系統(tǒng)存在的一些問題，尤其是易用性、可靠性的問題;
2. 應(yīng)當(dāng)允許平臺的獨立性;
3. 應(yīng)當(dāng)能從所有的客戶站點方便地進入平臺。〕
組織目標(biāo)： 〔描述清楚組織對項目的總體要求，以及需要達到的目標(biāo)。例如：
1. 應(yīng)當(dāng)在CMMI4級執(zhí)行;
2. 應(yīng)當(dāng)達到和獲得基于Web的移植體系;
3. 應(yīng)當(dāng)產(chǎn)生可重用模型/代碼/設(shè)計思想，定義開發(fā)標(biāo)準(zhǔn);
4. 應(yīng)當(dāng)從Web的應(yīng)用開發(fā)獲得經(jīng)驗;
5. 應(yīng)當(dāng)達到產(chǎn)品化的要求?！?BR> 研究目標(biāo)： 〔對于研究性項目，應(yīng)描述清楚項目的研究目標(biāo)。例如：
1. 應(yīng)當(dāng)產(chǎn)生X篇高水平論文;
2. 應(yīng)當(dāng)產(chǎn)生X本專著;
3. 應(yīng)當(dāng)獲得X專利或軟件著作權(quán)?！?BR> 項目質(zhì)量目標(biāo)： 〔描述產(chǎn)品在交付時期應(yīng)達到的質(zhì)量要求，以及不同階段的缺陷率控制要求。例如：
1. 交付時缺陷密度：0.2缺陷/KLOC;
2. 需求評審缺陷率：10%～15%;
3. ……?！?BR> 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 主要功能和性能
3.3 項目過程
〔描述項目的實際過程，包括管理過程和工程過程，盡量用圖示說明，對裁剪或變更的流程應(yīng)說明裁剪或變更的原因、和裁剪或變更后的情況是什么?！?BR> 3.3.1 項目開發(fā)過程
〔說明本項目采用的開發(fā)過程，包括增加/修改/刪除了什么活動?！?BR> 3.3.2 過程裁剪注釋
遵循的標(biāo)準(zhǔn)過程/活動 裁剪注釋
〔應(yīng)說明增加/修改/刪除了什么活動〕 偏離原因
〔應(yīng)說明增加/修改/刪除了某個活動的原因〕
市場(客戶)調(diào)研階段 需求獲取
項目立項
項目定義階段 項目計劃
需求分析
產(chǎn)品(項目)研制階段 設(shè)計
編碼及單元測試
產(chǎn)品集成測試
評審
產(chǎn)品(項目)測試階段 產(chǎn)品測試
測試
產(chǎn)品(項目)驗收及發(fā)布階段 系統(tǒng)試運行
項目結(jié)項
產(chǎn)品技術(shù)支持及維護階段 產(chǎn)品技術(shù)支持及維護
貫穿項目全周期的過程 項目跟蹤
風(fēng)險管理
需求管理
過程和產(chǎn)品質(zhì)量保證
配置管理
度量與分析
4 項目開發(fā)工作評價
4.1 生產(chǎn)率評價
構(gòu)件/模塊名稱 代碼行(千行) 工作量 代碼行/工作量
甘特圖
過程定義
等等
合計
平均生產(chǎn)率及其評價：
4.2 技術(shù)方案評價
〔總結(jié)該軟件項目或軟件產(chǎn)品開發(fā)時所采用的各項技術(shù)〕
〔以下是示例：〕
對開發(fā)工具的評價：這里主要是對開發(fā)工具PowerBuilder8.0和數(shù)據(jù)庫工具的評價。
對PowerBuilder8.0的評價：在整個項目的開發(fā)過程中，由于此工具引發(fā)了諸多爭議，我認(rèn)為pb在C/S架構(gòu)是由其獨特優(yōu)勢的，就是從開發(fā)成本、B/S和面向?qū)ο髞碚f其也有獨到之處，因此我認(rèn)為開發(fā)工具都有其優(yōu)劣，關(guān)鍵看我們是否精通。
對數(shù)據(jù)庫工具的評價：我們現(xiàn)在用的數(shù)據(jù)庫工具只是停留在表、視圖和存儲過程簡單使用，對數(shù)據(jù)庫的深層研究和SQL語句的優(yōu)化現(xiàn)在做的不夠，當(dāng)然還有表設(shè)計的合理性都需要加強，我建議部門或項目組可以
專門培養(yǎng)往數(shù)據(jù)庫研究和發(fā)展的人員，從而提高我們產(chǎn)品的開發(fā)、運行速度和穩(wěn)定性并可提高整個部門開發(fā)人員的技術(shù)水平。
對框架技術(shù)的評價：從整個框架的整體使用效果來看并為達到預(yù)期的目的，我認(rèn)為主要是由以下原因造成的：
框架本身存在有諸多不完善的地方，需要不斷地進行改進，但在改進的過程中沒有進行嚴(yán)格的控制，導(dǎo)致框架的整體設(shè)計失控;
框架本身有這樣那樣的問題，有些問題是目前無法解決的;
框架是建構(gòu)在PFC的基礎(chǔ)上的，項目組成員對PFC不是足夠的精通，為維護框架帶來難度。
建議：模塊化是產(chǎn)品化的基礎(chǔ)，也是降低成本、提高開發(fā)效率保證軟件質(zhì)量的有效手段，需要有專人設(shè)計和維護框架。
對設(shè)計方法的評價：信息化項目的整體設(shè)計是由項目組全體成員完成的，鑒于我們目前的設(shè)計水平，我看還可繼續(xù)這種方法，對設(shè)計的方法和思路進行廣泛的借鑒，但一定要樹立設(shè)計的權(quán)威性，對設(shè)計的變更要進行嚴(yán)格的控制。
對團隊開發(fā)的評價：從整體上講我們這個團隊的能力還可以，但我認(rèn)為它的生產(chǎn)效率并不高也就是說團隊的整體建設(shè)不好，沒有明確的學(xué)習(xí)方向分工，使整個團隊在這段時間里整體能力沒有太大的提高，我以前很想把我們的團隊培養(yǎng)成那種學(xué)習(xí)型的優(yōu)秀團隊，可惜事與愿違這項工作沒有取得什么實效。
5 項目管理工作評價
5.1 需求管理
5.1.1 需求完成情況
最初建議的需求數(shù)：
納入基線的需求數(shù)：
已實現(xiàn)的需求數(shù)：
已驗證的需求數(shù)：
已刪除的需求數(shù)：
已修訂的需求數(shù)：
新增的需求數(shù)：
5.1.2 需求變更情況
〔總結(jié)項目的不同階段所發(fā)生的需求變更次數(shù)及發(fā)生變更的主要原因?！?BR> 變更發(fā)生的階段 需求變更次數(shù) 變更工作量
(從申請開始到變更結(jié)束發(fā)生的工作量)
用戶需求定義
軟件需求分析
設(shè)計
編碼
測試
維護
需求變更的主要原因：
5.2 計劃管理
5.2.1 計劃變更情況
序號 變更發(fā)生階段 變更原因 變更內(nèi)容 變更是否允許
1
2
3
6 項目重大事件
〔列出項目期間或項目本階段中發(fā)生的重大事件〕
時間 地點 事件 重要參加人員
7 驗收準(zhǔn)備工作
1、 驗收要求：項目經(jīng)理與客戶確定驗收要求
2、 驗收文檔準(zhǔn)備情況：驗收文檔內(nèi)容及完成情況，明確后期可能需要完善的文檔。
8 經(jīng)驗教訓(xùn)
8.1 項目問題/缺陷原因分析
對項目問題進行原因分析
注：總結(jié)項目產(chǎn)生的問題，分析其中可以通過完善過程體系的方法來避免的問題。
對產(chǎn)品缺陷進行原因分析
注：總結(jié)項目產(chǎn)品發(fā)現(xiàn)的缺陷，分析是否可在開發(fā)過程中避免，或通過增加評審檢查單和測試用例檢查單等方法可避免。
8.2 總結(jié)經(jīng)驗教訓(xùn)
8.3 項目推薦工作產(chǎn)品
注：可推薦本