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

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

2、期模型：增量式模型 实际采用的生命周期模型：增量式模型 在整个项目过程中，项目生命周期模型没有变更。增量模型生命周期适用于本项目开发过程。前期通过DEMO行确认、沟通，使客户对产品有直观的认识，减少 项目风险。项目人员管理组织结构人力投入人员投入计划和实际的比较6543210555需求 概要设计详细设计编码测试交付口计划投入人员实际投入人员培训情况序号课程名称参加人数花费工作量培训效果备注1VSTS5=12*5好2C#编码规卜5=0.5*5良好总计762.5良好培训结果分析VSTS:解决了当前项目管理中遇到的问题，同时更进一步了解VSTS;达到较好效果。C#编码规范：让开发人员熟悉公司的一系列

3、编码规范，便于在开发过程中 的代码走查和组间协调。项目管理成本成本跟踪口初始估计值口当前估计值实际情况成本偏离分析项目总成本为：30万元成本初始估计值为：25万元成本估计偏差为：5万元成本估计偏差的主要原因：1、计算标准不一致；2、没有比较准确的估计参考数据。偏差措施：1、加大跟踪力度。2、进行多次估算，使估算比较符合实际工作量项目工作量偏离原因分析原因主要有以下几点：没有较准确的估计参考数据；项目初期，实习开发人员对工作要求不熟悉；Q雨期没有及时跟踪项目问题；实习开发人员公司过程体系的理解不足，且开发能力稍显不足。 措施：对关键任务，加大跟踪力度。根据项目特点进行2次估算，使估算比较符合实际

4、。生产率总代码行数：110304 LocC# 108954LocJavaScript : 477LocSql: 873Loc代码重用：22061Loc项目总投入：40人月开发人员投入：880小时；美术人员投入：160小时。项目生产率C# 以及JavaScript生产率：802Loc/人大需求管理需求处理情况需求变更情况基线化需求数量已处理需求数量. 需求变更数项目进度项目进度（1）一 年一2005月234&6计划里程碑正加完成05/02/02需求调杳完成咐13彳 I -. . - ,划完成评审）5/02/23概要设计完成05/03/10测试完成需求调杳完成05/02/20详细设计完成编

5、码.单元05/04/14 测试完成05/05/02产品交付05/05/26项目进度（2）阶段完成情况口初始计划口当前计划实际情况项目进度偏离原因分析原因主要有以下几点：没有较准确的估计参考数据；项目初期，实习人员对工作要求不熟悉；Q雨期没有及时跟踪项目问题；项目组对公司过程体系的理解不足，且编码能力稍显不足。 措施：对关键任务，加大跟踪力度。根据项目特点进行2次估算，使估算比较符合实际。评审缺陷分布454035302520151050交付计划评审次数口当前计划次数实际评审次数华划 目策口发现问题数问题处理数评审工作量阶段分布评审工作量的阶段分布情况文档规模文档规模口初始估计 口当前估计 实际值

6、文档规模偏离原因分析?文档总规模为：A页。?初始估计值为：BM。?二次估计值为：CM。?文档初始估计偏差为：（A-B）/A=?文档二次估计偏差为：（A-B）/A=估计偏差的主要原因：1 .使用新的估算模板，估算难度较大；2 .估算人员比较少，没有让较多的人员参与到项目进行估算。措施：1、进行多次估算；2、加大对偏差较大的部分跟踪力度，确认内容有效性，减少不必要的内容代码规模C0TR代码规模o o O o o O6 4 2o o O o o O0 8 6o o O o o O 4 2代码规模偏离原因分析原因在于估计中使用的是有效代码行，而统计时使用的是实际所有代码行，没有比较好的统计有效代码行工

7、具。（如注释，和自动生成的代码）没有参考比例系数（不包括注释和自动生成部分代码比例系数），进行统计 有效代码行。估算人员没有相关估算经验。配置管理SCI基线化COIR代码规模o o O o o O6 4 2o o O o o O0 8 6o o O o o O 4 2初始估计值当前估计值实际情况变更记录CR变更记录CR (1)CR报告紧急 高 口中 口低变更记录CR (2)变更控制号受影响的配置项艾更时间原因分析经验/教训/改进措施基线序号基线名称计划基线形成时间实际基线形成时间123456789测试集成测试已确认问题测试问题报告严重影响系统运行口影响系统运行口不影响系统运行但必须修改口所提建

8、议用例执行情况测试用例执行情况系统测试用例执行情况测试用例执行情况已确认问题测试问题报告严重影响系统运行影响系统运行不影响系统运行但必须修改所提建议测试结果概述、测试问题概述：1 .测试人员第一次参与性能测试，对相应工具不熟悉，边摸索边测试而影响了 测试速度；2 .由于项目前期需求和设计不详细， 未及时指定用户需求号，导致后期无法完 成测试管理工作表中的追溯；3 .由于需求和设计的粗略，无法正常获取设计用例的信息，测试人员需要与开 发人员不断地来回沟通，浪费了大量的时间；4 .项目开发人员在修改缺陷时，经常变换权限等的要求，且没有及时添加到需 求和设计中，且没及时通知相关人员，导致测试时发现系

9、统与需求不一样而又 重新修改已制作测试用例的测试需求，增加不必要的工作；5 .测试人员管理的经验不足，没有及时进行跟踪，导致最后统计数据很费时间。、建议：1、让项目开发人员对过程进行进一步的了解，让开发人员更改系统时有意识要 通知相关人员，并修改相关的文档；6 、测试人员实时跟踪，每天都要记好当天的效率和缺陷等相关信息；3、加强需求设计人员对需求设计文档的分析及设计能力，同时要求项目开发人员能够按照需求和设计文档来实现系统问题分析间遇来理同施等级装率时机卖 第十 弱比例奥 里个 疑比例更 型个禽比例卖3个此比例21.S6K1k瞅操 作 即 比 调10L99.洛10221.96%6159, 80

10、S10.96K一其中£翻但*65. 88X端 吗 惜9694U2K3t辄39H慨读后出焦弊他21.56%B8.如SQA工作汇报问题分布情况问题阶段分布码及单 编140120100806040200问题KPAS勺分布图问题分析产品质量问题主要来源：1 .同行评审中，评审准备不足，作者、评审组长等对于质量把控不严；2 .项目组文档质量把控意识不足，未进行拼写检查和组内走查就开始进行走查；3 .走查时，作者未及时反馈处理结果，且项目经理和QA弋表未及时跟踪处理情 况；活动问题主要来源：1. PDSP开始太晚，模板适用性不足；2. QA代表因经验不足，工作重心出现偏离，如花费大量时间制作和修

11、改模板，对活动的评审与跟踪力度不足。项目经验好的经验序号描述KPAs1周例会：每周五周例会中，除总结本周工作情况和当前项目情况、汇总与分析当前项目问题外，需明确下周任务，使项目成员明确自己下周任 务。2邮件规范化管理：1 .建立专用项目目录和客户目录；2 .邮件分类处理：对处理完的邮件和为处理的邮件分类，可以作 上适当的标记进行区分。3启效沟通：1 .发送邮件后，需及时与接收者联系，以防未及时收到相应邮件（因公司最近邮件服务器总是切换，影响正常使用）；2 .在周例会等场合，为组员提供增强沟通能力的机会，如每周周例会由一到两个组员上台“讲演”项目教训项目中得到的教训序号描述KPAs1确认：前期必

12、须及时与客户确认，确保项目进度；为了减少客户的 确认时间，可以减小确认的内容，或者分类分次进行确认，以检查 表方式记录。2估计：倩计前，需对参加倩计成员进行倩计培训，并统一本次借计 的一些标准，确保估计者以更统一的方式、更准确地借计。在整个 项目过程中，最好进行几次估计，使估计相对准确。项目总评整个开发过程按照公司规范进行， 在 项目开发过程中，全体项目成员克服了项 目中出现的许多困难和问题。如当部分人员因其他项目需要而被调走时，项目组成 员同时完成好几项任务。本项目主要存在如下不足：?规范意识不够；? 编码效率不高，整体技能有待进一步提高；? 沟通协作不够顺畅，反馈机制效率不高；? 对评审与走查中发现的问题，作者未及时修正和反馈，QA弋表未及时跟踪。改进建议厅P描述KPAs1估计表有待进一步改善。2改善项目成员周报模板；改进对PM工作表、CM工作表、 QA工作表、测试管理工作表以及工作量汇报机制，使统计 工作量和分析数据更加容易。3及时更新项目进度表.mpp,并将