精編人力資源管理系統(tǒng)項目總結(jié)報告

1、人力資源管理系統(tǒng)項目總結(jié)報告匯 報 人：張詠勤匯報日期： 2009-10-11修改歷史日期版本作者修改內(nèi)容評審號變更控制號2009-10-111.0張詠勤修訂項目基本信息項目名稱人力資源管理系統(tǒng)項目代號HRM產(chǎn)品類別軟件產(chǎn)品客戶Comm 貿(mào)易公司項目經(jīng)理ProMan主管高級經(jīng)理Cosmo項目 SCM 代表Robin測試經(jīng)理SammySQA代表Passay測試人員Testman、 Van項目基本信息項目范圍與目的范圍人力資源管理系統(tǒng) (HRM)分為以下幾個功能模塊 ：人事管理、工資管理、職位 變更管理、離職管理、培訓(xùn)管理、輔助系統(tǒng)。目的為Comm貿(mào)易公司定制的人力資源管理系統(tǒng)。軟件生命周期計劃采

2、用的生命周期模型：增量式模型 實際采用的生命周期模型：增量式模型在整個項目過程中，項目生命周期模型沒有變更。增量模型生命周期適用于本 項目開發(fā)過程。前期通過 DEM進O 行確認、溝通，使客戶對產(chǎn)品有直觀的認識，減少 項目風(fēng)險。項目人員管理組織結(jié)構(gòu)人力投入人員投入計劃和實際的比較6543210555332需求 概要設(shè)計 詳細設(shè)計 編碼測試交付計劃投入人員 實際投入人員培訓(xùn)情況序號課程名稱參加人數(shù)花費工作量培訓(xùn)效果備注1VSTS5=12*5好2C#編碼規(guī)范5=0.5*5良好總計762.5良好培訓(xùn)結(jié)果分析VSTS：解決了當(dāng)前項目管理中遇到的問題，同時更進一步了解VSTS；達到較好效果。C#編碼規(guī)范

3、:讓開發(fā)人員熟悉公司的一系列編碼規(guī)范，便于在開發(fā)過程中 的代碼走查和組間協(xié)調(diào)。項目管理成本成本跟蹤100000900008000070000600005000040000300002000010000成本偏離分析項目總成本為： 30 萬元 成本初始估計值為： 25萬元 成本估計偏差為： 5萬元成本估計偏差的主要原因：1、計算標準不一致； 2、沒有比較準確的估計參考數(shù)據(jù)。偏差措施：1、加大跟蹤力度。2、進行多次估算，使估算比較符合實際工作量工作量跟蹤項目工作量偏離原因分析原因主要有以下幾點：沒有較準確的估計參考數(shù)據(jù)； 項目初期，實習(xí)開發(fā)人員對工作要求不熟悉； QA前期沒有及時跟蹤項目問題； 實習(xí)

4、開發(fā)人員公司過程體系的理解不足，且開發(fā)能力稍顯不足。 措施：對關(guān)鍵任務(wù)，加大跟蹤力度。根據(jù)項目特點進行 2次估算，使估算比較符合實際。生產(chǎn)率總代碼行數(shù)： 110304 LocC#： 108954LocJavaScript ： 477LocSql: 873Loc 代碼重用： 22061Loc項目總投入： 40 人月開發(fā)人員投入： 880 小時；美術(shù)人員投入： 160 小時。 項目生產(chǎn)率C# 以及JavaScript 生產(chǎn)率： 802Loc/ 人天需求管理需 求 處 理 情 況基 線 化 需求 數(shù) 量 已 處 理需 求 數(shù) 量需求變 更情 況3需求變更數(shù)項目進度項目進度（ 1）項目進度（ 2）階段

5、完成情況初始計劃當(dāng)前計劃實際情況項目進度偏離原因分析原因主要有以下幾點：沒有較準確的估計參考數(shù)據(jù)； 項目初期，實習(xí)人員對工作要求不熟悉； QA前期沒有及時跟蹤項目問題； 項目組對公司過程體系的理解不足，且編碼能力稍顯不足。 措施：對關(guān)鍵任務(wù)，加大跟蹤力度。根據(jù)項目特點進行 2次估算，使估算比較符合實際。評審評審活動跟蹤缺陷分布454035302520151050需求編碼設(shè)計交付計劃評審次數(shù) 當(dāng)前計劃次數(shù) 實際評審次數(shù)目策劃發(fā)現(xiàn)問題數(shù)問題處理數(shù)評審工作量階段分布評審工作量的階段分布情況文檔規(guī)模文檔規(guī)模初始估計 當(dāng)前估計 實際值文檔規(guī)模偏離原因分析? 文檔總規(guī)模為： A頁。 ? 初始估計值為： B

6、頁。? 二次估計值為： C頁。? 文檔初始估計偏差為： (A-B)/A=? 文檔二次估計偏差為： (A-B)/A= 估計偏差的主要原因：1. 使用新的估算模板，估算難度較大；2. 估算人員比較少，沒有讓較多的人員參與到項目進行估算。 措施：1、進行多次估算；2、加大對偏差較大的部分跟蹤力度， 確認內(nèi)容有效性， 減少不必要的內(nèi)容代碼規(guī)模160. 00140. 00120. 00100. 0080. 0060. 0040. 0020. 000. 00初始估計值 當(dāng)前估計值 實際情況代碼規(guī)模代碼規(guī)模偏離原因分析原因在于估計中使用的是有效代碼行，而統(tǒng)計時使用的是實際所有代碼行，沒有比較好的統(tǒng)計有效代碼

7、行工具。（如注釋，和自動生成的代碼）沒有參考比例系數(shù) （不包括注釋和自動生成部分代碼比例系數(shù)） ，進行統(tǒng)計 有效代碼行。估算人員沒有相關(guān)估算經(jīng)驗。配置管理SCI 基線化COL0020代碼規(guī)模000000000000初始估計值 當(dāng)前估計值 實際情況變更記錄 CR變更記錄 CR（ 1）CR 報告CR總數(shù)未關(guān)閉數(shù)高中低緊急變更記錄 CR（ 2）變更控制號受影響的配置項變更時間原因分析經(jīng)驗 /教訓(xùn) / 改進措施基線序號基線名稱計劃基線形成時間實際基線形成時間123456789測試集成測試已確認問題測試問題報告嚴重影響系統(tǒng)運行影響系統(tǒng)運行不影響系統(tǒng)運行但必須修改所提建議用例執(zhí)行情況測試用例執(zhí)行情況系統(tǒng)測

8、試用例執(zhí)行情況測試用例執(zhí)行情況已確認問題測試問題報告未解決問題數(shù)問題報告總數(shù)嚴重影響系統(tǒng)運行影響系統(tǒng)運行不影響系統(tǒng)運行但必須修改所提建議測試結(jié)果概述、測試問題概述：1. 測試人員第一次參與性能測試， 對相應(yīng)工具不熟悉， 邊摸索邊測試而影響了 測試速度；2. 由于項目前期需求和設(shè)計不詳細， 未及時指定用戶需求號， 導(dǎo)致后期無法完 成測試管理工作表中的追溯；3. 由于需求和設(shè)計的粗略， 無法正常獲取設(shè)計用例的信息， 測試人員需要與開 發(fā)人員不斷地來回溝通，浪費了大量的時間；4. 項目開發(fā)人員在修改缺陷時，經(jīng)常變換權(quán)限等的要求，且沒有及時添加到需 求和設(shè)計中，且沒及時通知相關(guān)人員，導(dǎo)致測試時發(fā)現(xiàn)系統(tǒng)

9、與需求不一樣而又 重新修改已制作測試用例的測試需求，增加不必要的工作；5. 測試人員管理的經(jīng)驗不足， 沒有及時進行跟蹤， 導(dǎo)致最后統(tǒng)計數(shù)據(jù)很費時間。 、建議：1、讓項目開發(fā)人員對過程進行進一步的了解 , 讓開發(fā)人員更改系統(tǒng)時有意識要 通知相關(guān)人員 , 并修改相關(guān)的文檔；2、測試人員實時跟蹤，每天都要記好當(dāng)天的效率和缺陷等相關(guān)信息；3、加強需求設(shè)計人員對需求設(shè)計文檔的分析及設(shè)計能力， 同時要求項目開發(fā)人 員能夠按照需求和設(shè)計文檔來實現(xiàn)系統(tǒng)。問題分析SQA工作匯報250200150100500活動次數(shù) 發(fā)現(xiàn)問題總數(shù) 嚴重問題數(shù) 輕微問題數(shù) 問題解決數(shù) 上報問題數(shù)問題分布情況問題階段分布140120

10、6 13 17 9 960 0 01 6 5ESP TP IC PR問題KPAs的分布圖133100806040200問題分析產(chǎn)品質(zhì)量問題主要來源：1. 同行評審中，評審準備不足，作者、評審組長等對于質(zhì)量把控不嚴；2. 項目組文檔質(zhì)量把控意識不足，未進行拼寫檢查和組內(nèi)走查就開始進行走 查；3. 走查時， 作者未及時反饋處理結(jié)果， 且項目經(jīng)理和 QA代表未及時跟蹤處理情 況；活動問題主要來源：1. PDSP開始太晚，模板適用性不足；2. QA 代表因經(jīng)驗不足，工作重心出現(xiàn)偏離，如花費大量時間制作和修改模板， 對活動的評審與跟蹤力度不足。項目經(jīng)驗好的經(jīng)驗序號描述KPAs1周例會：每周五周例會中，

11、除總結(jié)本周工作情況和當(dāng)前項目情況、 匯總與分 析當(dāng)前項目問題外， 需明確下周任務(wù)， 使項目成員明確自己下周任 務(wù)。2郵件規(guī)范化管理：1. 建立專用項目目錄和客戶目錄；2. 郵件分類處理：對處理完的郵件和為處理的郵件分類，可以作 上適當(dāng)?shù)臉擞涍M行區(qū)分。3有效溝通：1. 發(fā)送郵件后，需及時與接收者聯(lián)系，以防未及時收到相應(yīng)郵件 （因公司最近郵件服務(wù)器總是切換，影響正常使用） ；2. 在周例會等場合，為組員提供增強溝通能力的機會，如每周周 例會由一到兩個組員上臺“講演” 。項目教訓(xùn)項目中得到的教訓(xùn)序號描述KPAs1確認： 前期必須及時與客戶確認，確保項目進度；為了減少客戶的 確認時間，可以減小確認的內(nèi)

12、容，或者分類分次進行確認，以檢查 表方式記錄。2估計： 估計前，需對參加估計成員進行估計培訓(xùn)，并統(tǒng)一本次估計 的一些標準，確保估計者以更統(tǒng)一的方式、更準確地估計。在整個 項目過程中，最好進行幾次估計，使估計相對準確。項目總評整個開發(fā)過程按照公司規(guī)范進行， 在 項目開發(fā)過程中， 全體項目成員克服了項 目中出現(xiàn)的許多困難和問題。如當(dāng)部分人員因其他項目需要而被調(diào)走時，項目組成 員同時完成好幾項任務(wù)。本項目主要存在如下不足：? 規(guī)范意識不夠；? 編碼效率不高，整體技能有待進一步提高；? 溝通協(xié)作不夠順暢，反饋機制效率不高；? 對評審與走查中發(fā)現(xiàn)的問題，作者未及時修正和反饋， QA代表未及時跟 蹤。改進建議序號描述KPAs1估計表有待進一步改善。2改善項目成員周報模板；改進對 PM 工作表、 CM 工作表、 QA 工作表、測試管理工作表以及工作量匯報機制， 使統(tǒng)計 工作量和分析數(shù)據(jù)更加容易。3及時更新項目進度表 .mpp ，并將重要內(nèi)容通過郵件