人力资源管理系统项目总结报告

1、人力资源治理系统工程总结报告汇报人：张咏勤汇报日期：2022-10-11修改历史日期版本作者修改内容评审号变更限制号2022-10-111.0张咏勤修订工程根本信息顷目名称人力资源治理系统顷目代号HRM主品类别软件产品客户Comm贸易公司顷目经理ProMan主管高级经理Cosmo顷目SCM代表Robin那么试经理SammySQA代表Passay那么试人员Testman、Van工程根本信息工程范围与目的范围:人事治理、工资治理、职位变更治理、人力资源治理系统HRM分为以下几个功能模块 离职治理、培训治理、辅助系统.目的为Comm易公司定制的人力资源治理系统.软件生命周期方案采用的生命周期模型：增

2、量式模型实际采用的生命周期模型：增量式模型在整个工程过程中,工程生命周期模型没有变更.增量模型生命周期适用于本工程开发 过程.前期通过DEMO行确认、沟通,使客户对产品有直观的熟悉,减少工程风险. 工程人员治理组织结构人力投入培训情况课程名称花费工作量培训效果VSTS人员投为讣划和实际的比拟C#编码规=0.5*5良好62.5 5培训缅果VSTSC#编,决了当前可胃理中遇到司白题,同时更进一步了解VSTS;到达较好E列编码标准3便于在开发过程中的代码走3范：让开发熟悉公查和组间协调.举措：本钱本钱偏离分析工程总本钱为：30万元本钱初始估计值为：25万元口当前估计值 实际情况C对关键任务,生产率根

3、据工程特点进行2次估算,使估算比拟符合实际总代码行数：110304 LocC掂108954LocJavaScript : 477LocSql: 873Loc代码重用：22061Loc工程总投入：开发人员投入: 美术人员投入: 工程生产率40人月880小时；160 小时.C# 以及JavaScript生产率：802Loc/人大需求治理 工程进度 工程进度 工程进度(D(2)2022统050508050418050329050309050217求不孰采方案里程 0506170505摘加:工程进度偏离原因分析原因土耍以下几点:"没有较准确w估计参考数据;勺页目初期工室习人员对士作里颂期没有

4、网寸跟踪项根据工程特点进行2次估算,使估算比拟符合实际.评审评审工作量阶段分布文档规模文档规模偏离原因分析?文档总规模为：颂.?初始估计值为：B页.?二次估计值为：C页.?文档初始估计偏差为：A-B/A=?文档二次估计偏差为：A-B/A=估计偏差的主要原因：1.使用新的估算模板,估算难度较大；?2.估算人员比拟少,没有让较多的人员参与到工程进行估算.举措：1、进行屡次估算；2、加大对偏差较大的局部跟踪力度,确认内容有效性,减少不必要的内容.代码规模代码规模偏离原因分析? 原因在于估计中使用的是有效代码行,而统计时使用的是实际所有代码行,没有比 较好的统计有效代码行工具.如注释,和自动生成的代码

5、? 没有参考比例系数不包括注释和自动生成局部代码比例系数,进行统计有效代 码行.?估算人员没有相关估算经验.配置治理SCI基线化变更记录CR变更记录CR 1变更记录CR 2变更限制号受影响的配置项变更时间原因分析经验/教训改良举措序号 基线名称方案基线形成时间实际基线形成时间3456789测试集成测试已确认问题用例执行情况系统测试用例执行情况、口1、30年皿/ 测试用例执行情况口通过数未通过数已确认问题叱、仙小A申*gP用例总数口已执行数测试结果概述74 61 .既0式人第第次参E能测试,对相应工具不熟悉,边摸索边测试而影响了测试速度;2 .由于工程前期需求加设计不详细5未及时指定用户需求号3

6、 .由于需工殳计的俎略无法正臂获取设计用例的信息,导致后期无法完成测试管测试人员需要与开发人员不断解叵同通,4 .项00十国人员大量的时回;在修改缺陷时,经常变换权限等的要求,且没有及时添加到需求和设计中,且没及试用固的利5 .测试“ f 2 00、建议：1、诂项人员,并、员时通 成需 治理知相关的经翳目开发,导致测试时发现系统与需求不一样而又重新修改已制作测力口彳龙嘤的工缺乏,没有及时进行跟踪,导致最后统标数据很费时间.121立程恚行进攵相关的文;当的了解口上开发人员更改系统时有意识要通知相关3、增强需求设计人员对需求设计文档的分析及设计水平,同时要求工程开发人员能够按照需求和设计文档来实现

7、系统.问题分析SQA工作汇报问题分布情况问题分析产品质量问题主要来源：1 .同行评审中,评审准备缺乏,作者、评审组长等对于质量把控不严；2 .工程组文档质量把控意识缺乏,未进行拼写检查和组内走查就开始进行走查；3 .走查时,作者未及时反应处理结果,且工程经理和 QA弋表未及时跟踪处理情况； 活动问题主要来源：1. PDSP开始太晚,模板适用性缺乏；2. QA弋表因经验缺乏,工作重心出现偏离,如花费大量时间制作和修改模板,对活动的 评审与跟踪力度缺乏.工程经验好的经验序号描述KPAs1周例会：每周五周例会中,除总结本周工作情况和当前工程情况、汇总与分析 当前工程问题外,需明确下周任务,使工程成员

8、明确自己下周任务.2邮件标准化治理：1 .建立专用工程目录和客户目录；2 .邮件分类处理：对处理完的邮件和为处理的邮件分类,可以作上适 当的标记进行区分.3有效沟通：1 .发送邮件后,需及时与接收者联系,以防未及时收到相应邮件因 公司最近邮件效劳器总是切换,影响正常使用；2 .在周例会等场合,为组员提供增强沟通水平的时机,如每周周例会 由一到两个组员上台“讲演.工程教训工程中得到的教训序号描述KPAs1确认：前期必须及时与客户确认, 保证工程进度；为了减少客户确实认 时间,可以减小确认的内容,或者分类分次进行确认,以检查表方式记 录.2估计：估计前,需对参加估计成员进行估计培训, 并统一本次估

9、计的一 些标准,保证估计者以更统一的方式、 更准确地估计.在整个工程过程 中,最好进行几次估计,使估计相对准确.工程总评整个开发过程根据公司标准进行,在 工程开发过程中,全体工程成员克服了工程中出 现的许多困难和问题.如当局部人员因其他工程需要而被调走时, 工程组成员同时完成好几 项任务.本工程主要存在如下缺乏：?标准意识不够；? 编码效率不高,整体技能有待进一步提升；? 沟通协作不够顺畅,反应机制效率不高；? 对评审与走查中发现的问题,作者未及时修正和反应,QA弋表未及时跟踪.改良建议厅P描述KPAs1估计表有待进一步改善.2改善工程成员周报模板；改良对PM工作表、CM工作表、 QA工作表、测试治理工作表以及工作量汇报机制, 使统计 工作量和分析数据更加容易.3及时更新工程进度表.mpp,并将重要内容通过邮件通知相 关人员如里程碑工作产品的走查或评审,相关人员需 尽早反应意见和建议