人力资源管理系统项目总结报告.docx
《人力资源管理系统项目总结报告.docx》由会员分享，可在线阅读，更多相关《人力资源管理系统项目总结报告.docx（19页珍藏版）》请在冰豆网上搜索。
人力资源管理系统项目总结报告
人力资源管理系统工程
总结报告
汇报人：
张咏勤
汇报日期：
2009-10-11
修改历史
日期
版本
作者
修改内容
评审号
变更控制号
2009-10-11
张咏勤
修订
工程根本信息
工程名称
人力资源管理系统
工程代号
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
良好
培训结果分析
◆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
重要变更或对需求、进度较大调整之后，进行新一轮估计，尽量让工程组人员参与，以更好地确保工程进度。
升级会员 