人力资源管理系统项目总结报告.docx
《人力资源管理系统项目总结报告.docx》由会员分享，可在线阅读，更多相关《人力资源管理系统项目总结报告.docx（15页珍藏版）》请在冰豆网上搜索。
人力资源管理系统项目总结报告
人力资源管理系统项目
总结报告
汇报人：
张咏勤
汇报日期：
2009-10-11
修改历史
日期
版本
作者
修改内容
评审号
变更控制号
2009-10-11
1.0
张咏勤
修订
项目基本信息
项目名称
人力资源管理系统
项目代号
HRM
产品类别
软件产品
客户
Comm贸易公司
项目经理
ProMan
主管高级经理
Cosmo
项目SCM代表
Robin
测试经理
Sammy
SQA代表
Passay
测试人员
Testman、Van
项目基本信息
项目范围与目的
范围
人力资源管理系统（HRM）分为以下几个功能模块：
人事管理、工资管理、职位变更管理、离职管理、培训管理、辅助系统。
目的
为Comm贸易公司定制的人力资源管理系统。
软件生命周期
计划采用的生命周期模型：
增量式模型
实际采用的生命周期模型：
增量式模型
在整个项目过程中，项目生命周期模型没有变更。
增量模型生命周期适用于本项目开发过程。
前期通过DEMO进行确认、沟通，使客户对产品有直观的认识，减少项目风险。
项目人员管理
组织结构
人力投入
培训情况
序号
课程名称
参加人数
花费工作量
培训效果
备注
1
VSTS
5
=12*5
好
2
C#编码规范
5
=0.5*5
良好
总计
7
62.5
良好
培训结果分析
◆VSTS：
解决了当前项目管理中遇到的问题，同时更进一步了解VSTS；达到较好效果。
◆C#编码规范:
让开发人员熟悉公司的一系列编码规范，便于在开发过程中的代码走查和组间协调。
项目管理
成本
成本偏离分析
项目总成本为：
30万元
成本初始估计值为：
25万元
成本估计偏差为：
5万元
成本估计偏差的主要原因：
1、计算标准不一致；
2、没有比较准确的估计参考数据。
偏差措施：
1、加大跟踪力度。
2、进行多次估算，使估算比较符合实际。
工作量
项目工作量偏离原因分析
原因主要有以下几点：
没有较准确的估计参考数据；
项目初期，实习开发人员对工作要求不熟悉；
QA前期没有及时跟踪项目问题；
实习开发人员公司过程体系的理解不足，且开发能力稍显不足。
措施：
对关键任务，加大跟踪力度。
根据项目特点进行2次估算，使估算比较符合实际。
生产率
总代码行数：
110304Loc
C#：
108954Loc
JavaScript：
477Loc
Sql:
873Loc
代码重用：
22061Loc
项目总投入：
40人月
开发人员投入：
880小时；
美术人员投入：
160小时。
项目生产率
C#以及JavaScript生产率：
802Loc/人天
需求管理
项目进度
项目进度
（1）
项目进度
（2）
项目进度偏离原因分析
原因主要有以下几点：
没有较准确的估计参考数据；
项目初期，实习人员对工作要求不熟悉；
QA前期没有及时跟踪项目问题；
项目组对公司过程体系的理解不足，且编码能力稍显不足。
措施：
对关键任务，加大跟踪力度。
根据项目特点进行2次估算，使估算比较符合实际。
评审
评审工作量阶段分布
文档规模
文档规模偏离原因分析
•文档总规模为：
A页。
•初始估计值为：
B页。
•二次估计值为：
C页。
•文档初始估计偏差为：
（A-B）/A=
•文档二次估计偏差为：
（A-B）/A=
估计偏差的主要原因：
1.使用新的估算模板，估算难度较大；
?
2.估算人员比较少，没有让较多的人员参与到项目进行估算。
措施：
1、进行多次估算；
2、加大对偏差较大的部分跟踪力度，确认内容有效性，减少不必要的内容。
代码规模
代码规模偏离原因分析
•原因在于估计中使用的是有效代码行，而统计时使用的是实际所有代码行，没有比较好的统计有效代码行工具。
（如注释，和自动生成的代码）
•没有参考比例系数（不包括注释和自动生成部分代码比例系数），进行统计有效代码行。
•估算人员没有相关估算经验。
配置管理
SCI基线化
变更记录CR
变更记录CR
（1）
变更记录CR
（2）
变更控制号
受影响的配置项
变更时间
原因分析
经验/教训/改进措施
基线
序号
基线名称
计划基线形成时间
实际基线形成时间
1
2
3
4
5
6
7
8
9
测试
集成测试
已确认问题
用例执行情况
系统测试
用例执行情况
已确认问题
测试结果概述
一、测试问题概述：
1.测试人员第一次参与性能测试，对相应工具不熟悉，边摸索边测试而影响了测试速度；
2.由于项目前期需求和设计不详细，未及时指定用户需求号，导致后期无法完成测试管理工作表中的追溯；
3.由于需求和设计的粗略，无法正常获取设计用例的信息，测试人员需要与开发人员不断地来回沟通，浪费了大量的时间；
4.项目开发人员在修改缺陷时，经常变换权限等的要求，且没有及时添加到需求和设计中，且没及时通知相关人员，导致测试时发现系统与需求不一样而又重新修改已制作测试用例的测试需求，增加不必要的工作；
5.测试人员管理的经验不足，没有及时进行跟踪，导致最后统计数据很费时间。
二、建议：
1、让项目开发人员对过程进行进一步的了解,让开发人员更改系统时有意识要通知相关人员,并修改相关的文档；
2、测试人员实时跟踪，每天都要记好当天的效率和缺陷等相关信息；
3、加强需求设计人员对需求设计文档的分析及设计能力，同时要求项目开发人员能够按照需求和设计文档来实现系统。
问题分析
SQA
工作汇报
问题分布情况
问题分析
产品质量问题主要来源：
1.同行评审中，评审准备不足，作者、评审组长等对于质量把控不严；
2.项目组文档质量把控意识不足，未进行拼写检查和组内走查就开始进行走查；
3.走查时，作者未及时反馈处理结果，且项目经理和QA代表未及时跟踪处理情况；
活动问题主要来源：
1.PDSP开始太晚，模板适用性不足；
2.QA代表因经验不足，工作重心出现偏离，如花费大量时间制作和修改模板，对活动的评审与跟踪力度不足。
项目经验
好的经验
序号
描述
KPAs
1
周例会：
每周五周例会中，除总结本周工作情况和当前项目情况、汇总与分析当前项目问题外，需明确下周任务，使项目成员明确自己下周任务。
2
邮件规范化管理：
1.建立专用项目目录和客户目录；
2.邮件分类处理：
对处理完的邮件和为处理的邮件分类，可以作上适当的标记进行区分。
3
有效沟通：
1.发送邮件后，需及时与接收者联系，以防未及时收到相应邮件（因公司最近邮件服务器总是切换，影响正常使用）；
2.在周例会等场合，为组员提供增强沟通能力的机会，如每周周例会由一到两个组员上台“讲演”。
项目教训
项目中得到的教训
序号
描述
KPAs
1
确认：
前期必须及时与客户确认，确保项目进度；为了减少客户的确认时间，可以减小确认的内容，或者分类分次进行确认，以检查表方式记录。
2
估计：
估计前，需对参加估计成员进行估计培训，并统一本次估计的一些标准，确保估计者以更统一的方式、更准确地估计。
在整个项目过程中，最好进行几次估计，使估计相对准确。
项目总评
整个开发过程按照公司规范进行，在项目开发过程中，全体项目成员克服了项目中出现的许多困难和问题。
如当部分人员因其他项目需要而被调走时，项目组成员同时完成好几项任务。
本项目主要存在如下不足：
•规范意识不够；
•编码效率不高，整体技能有待进一步提高；
•沟通协作不够顺畅，反馈机制效率不高；
•对评审与走查中发现的问题，作者未及时修正和反馈，QA代表未及时跟踪。
改进建议
序号
描述
KPAs
1
估计表有待进一步改善。
2
改善项目成员周报模板；改进对PM工作表、CM工作表、QA工作表、测试管理工作表以及工作量汇报机制，使统计工作量和分析数据更加容易。
3
及时更新项目进度表.mpp，并将重要内容通过邮件通知相关人员（如里程碑工作产品的走查或评审），相关人员需尽早反馈意见和建议。
4
WBS细分和调整时，考虑返工工作量，预留一定的缓冲时间（视项目实际周期等情况而定）。
5
寻找VSS和Sharepoint的同步接口，或Sharepoint快速批量上传的方式，以减少配置工作量。
6
重要变更或对需求、进度较大调整之后，进行新一轮估计，尽量让项目组人员参与，以更好地确保项目进度。
升级会员 