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

1、人力資源管理系統(tǒng)項目總結報告匯報人：張詠勤匯報日期：2009-10-11修改歷史日期版本作者修改內容評審號變更控制號2009-10-11張詠勤修訂項目基本信息項目名稱人力資源管理系統(tǒng)項目代號HRM產品類別軟件產品客戶Comnl!易公司項目經理ProMan主管高級經理Cosmo項目SCM弋表Robin測試經理SammySQA代表Passay測試人員Testman、Van項目基本信息項目范圍與目的范圍人力資源管理系統(tǒng)（HRM命為以下幾個功能模塊：人事管理、工資管理、職位變更管理、離職管理、培訓管理、輔助系統(tǒng)目的為Comm易公司定制的人力資源管理系統(tǒng)軟件生命周期計劃采用的生命周期模型：增量式模型實際

2、采用的生命周期模型：增量式模型在整個項目過程中，項目生命周期模型沒有變更。增量模型生命周期適用于本項目開發(fā)過程 前期通過DEMO行確認、溝通，使客戶對產品有直觀的認識，減少項目風險。項目人員管理組織結構人力投入培訓情況人員投入計劃和實際的比較項目管理成本成本偏離分析成本跟蹤100000勰 00總成本為:80B初始7撤 0 估土思備估1、50000 .2、130萬元估計值為：25萬元偏差為：5萬元_偏差的主要原因:_聲標準不一致；一“ce 殳有比較準確的估計參考數(shù)據詳細準備 需求加大跟蹤丈度C進行多次仕尊,300001、200吟、10000工作雖測試 交付口當前估計值實際情況口初始估計值項目工作

3、雖偏離原雨赫*一原因主要有以下幾點：沒有較準確的估計參考數(shù)據；項目初期，實習開發(fā)人員對工作要求不熟悉；Q僦期沒有及時跟蹤項目問題；實習開發(fā)人員公司過程體系的理解不足，且開發(fā)能力稍顯不足。 措施：對關鍵任務，加大跟蹤力度。根據項目特點進行2次估算，使估算比較符合實際。生產率總代碼行數(shù):110304 LocC掛108954LocJavaScript : 477LocSql: 873Loc代碼重用：22061Loc項目總投入：40人月開發(fā)人員投入：880小時;美術人員投入：160小時4項目生產率C#以及JavaScript生產率:802Loc/人天需求管理項目進度 項目進度(1)項目進度(2)評審工

4、咋H黯口當前計劃實際情況文檔規(guī)模文檔規(guī)模偏離原因分析?文檔總規(guī)模為：A頁。?初始估計值為：B貞。?二次估計值為：C貞。?文檔初始估計偏差為：(A-B)/A=?文檔二次估計偏差為：(A-B)/A=估計偏差的主要原因：1.使用新的估算模板，估算難度較大；2.估算人員比較少，沒有讓較多的人員參與到項目進行估算。措施：1、進行多次估算；2、加大對偏差較大的部分跟蹤力度，確認內容有效性，減少不必要的內容代碼規(guī)模代碼規(guī)模偏離原因分析原因在丁估計中使用的是有效代碼行，而統(tǒng)計時使用的是實際所有代碼行，沒有比較好的 統(tǒng)計有效代碼行工具。(如注釋，和自動生成的代碼)沒有參考比例系數(shù)(不包括注釋和自動生成部分代碼比

5、例系數(shù))，進行統(tǒng)計有效代碼行。估算人員沒有相關估算經驗。配置管理SCI基線化變更記錄CR變更記錄CR( 1)變更記錄CR( 2)變更控制號受影響的配置項變更時間原因分析經驗/教訓1/改進措施基線4I 5I 6781 9測試集成測試已確認問題用例執(zhí)行情況、四試用例執(zhí)行情況系統(tǒng)測誠用例總數(shù)口已執(zhí)行數(shù) 口通過數(shù) 口未通過數(shù)來回溝通，浪費了大量的時間；4.項目開發(fā)人員在修改缺陷時，經常變換權限等的要求，且沒有及時添加到需求和設計中，且 沒及時通知相關人員，導致測試時發(fā)現(xiàn)系統(tǒng)與需求不一樣而乂重新修改已制作測試用例的測試 需求，增加不必要的工作；5.測試人員管理的經驗不足，沒有及時進行跟蹤，導致最后統(tǒng)計數(shù)

6、據很費時間。、建議：1、讓項目開發(fā)人員對過程進行進一步的了解，讓開發(fā)人員更改系統(tǒng)時有意識要通知相關人員并修改相關的文檔；2、測試人員實時跟蹤，每天都要記好當天的效率和缺陷等相關信息；3、加強需求設計人員對需求設計文檔的分析及設計能力，同時要求項目開發(fā)人員能夠按照需 求和設計文檔來實現(xiàn)系統(tǒng)。問題分析SQA工作匯報問題分布情況問題分析產品質量問題主要來源：1.同行評審中，評審準備不足，作者、評審組長等對丁質量把控不嚴；2.項目組文檔質量把控意識不足，未進行拼寫檢查和組內走查就開始進行走查；3.走查時，作者未及時反饋處理結果，且項目經理和QA弋表未及時跟蹤處理情況； 活動問題主要來源：1. PDSP

7、開始太晚，模板適用性不足；2. QA代表因經驗不足，工作重心出現(xiàn)偏離，如花費大量時間制作和修改模板，對活動的評審 與跟蹤力度不足。項目經驗好的經驗序號描述KPAs1周例會：每周五周例會中，除總結本周工作情況和當前項目情況、匯總與分析當前項目問題外，需明確下周任務，使項目成員明確自己下周任 務。2郵件規(guī)范化管理：1.建立專用項目目錄和客戶目錄；2.郵件分類處理：對處理完的郵件和為處理的郵件分類，可以作 上適當?shù)臉擞涍M行區(qū)分。3有效溝通：1.發(fā)送郵件后，需及時與接收者聯(lián)系，以防未及時收到相應郵件（因公司最近郵件服務器總是切換，影響正常使用）；2.在周例會等場合，為組員提供增強溝通能力的機會，如每周

8、周 例會由一到兩個組員上臺“講演”。項目教訓項目中得到的教訓序號描述KPAs1確認：前期必須及時與客戶確認，確保項目進度；為了減少客戶的 確認時間，可以減小確認的內容，或者分類分次進行確認，以檢查 表萬式記錄。2估計：估計前，需對參加估計成員進行估計培訓，并統(tǒng)一本次估計 的一些標準，確保估計者以更統(tǒng)一的方式、更準確地估計。在整個 項目過程中，最好進行幾次估計，使估計相對準確。項目總評整個開發(fā)過程按照公司規(guī)范進行，在 項目開發(fā)過程中，全體項目成員克服了項目中出現(xiàn)的許 多困難和問題。如當部分人員因其他項目需要而被調走時，項目組成員同時完成好幾項任務。本項目主要存在如下不足：?規(guī)范意識不夠；? 編碼效率不高，整體技能有待進一步提高；? 溝通協(xié)作不夠順暢，反饋機制效率不高；? 對評審與走查中發(fā)現(xiàn)的問題，作者未及時修正和反饋，QA弋表未及時跟蹤改進建議）丁與描述KPAs1估計表有彳寸進少改善。2改善項目成員周報模板；改進對PM、ChT作表、QA工作表、測試管理工作表以及工作量匯報機制，使統(tǒng)計工 作量和分析數(shù)據更加容易。3及時更新項目進度表.mpp,并將重要內容通過郵件通知相 關人員（如里程碑工作廣品的走查或評審），相關人員需 盡早反饋意見和建議。4WB融分和調整