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

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

2、件生命周 期计划采用的生命周期模型：增量式模型实际采用的生命周期模型：增量式模型在整个项目过程中，项目生命周期模型没有变更。增量模型生命周期适用于本项目开发过程。前期通过 DEMO进行确认、沟通，使客户对产品有直观的认识，减少项目风险。项目人员管 理组织结 构立项申请人高级经理项目经理开发组质量组配置人员分析人员程序员美工测试人员QA人力投 入人员投入计划和实际的比较6555543332210需求概要设计详细设计编码测试交付计划投入人员实际投入人员培训情 况序课程名称参加人数花费工作 量培训效果备注号1VSTS5=12*5好C#编码规25=0.5*5良好范总计762.5良好VSTS：解决了当前

3、 项目管理中遇到的 问题，同时更进一步 了解 VSTS；达到较好效 果。培训结果 分析C#编码规范 :让开发人员熟悉公 司的一系列编码规范 ，便于在开发过程 中的代码走 查和组间协调。项目管理成本成本跟踪1000009000080000700006000050000400003000020000100000立项准备需求概要详细编码测试交付初始估计值当前估计值实际情况成本偏 离分析项目总成本为： 30万元成本初始估计值为： 25万元成本估计偏差为： 5万元成本估计 偏差的主要原因：1、计算标准不一致；2、没有比较准确的估计参考数据。偏差措施 ：1、加大跟踪力度。2、进行多次估算，使估算比较符合实

4、际。工作量工作量跟踪30002500时 2000小人 150010005000初始计划当前计划实际情况项目工 作量偏离原 因分析原因主要 有以下几点：没有较准确的估计参考数据；项目初期，实习开发人员对工作要求不熟悉；QA前期没有及时跟踪项目问题；实习开发人员公司过程体系的理解不足，且开发能力稍显不足。措施：对关键任务，加大跟踪力度。根据项目特点进行 2次估算，使估算比较符合实际。生产率总代码行 数： 110304LocC#：108954LocJavaScript ：477LocSql:873Loc代码重用 ：22061Loc项目总投 入：40人月开发人员 投入： 880 小时；美术人员 投入：

5、160小时。项目生产 率C#以及 JavaScript 生产率： 802Loc/ 人天需求管 理3 4 83 4 63 4 43 4 23 4 03 3 83 3 63 3 43 3 2需求处理情况需求变更情况34 73 4 73223 3933933733 71100需求设计编码测试需求设计编码测试基线化需求数量已处理需求数量需求变更数项目进 度项目进 度（1）项目进 度（2）阶段完成情况050617050528050508050418050329050309050217050128050108041219初始计划当前计划实际情况项目进 度偏离原因 分析原因主要 有以下几点：没有较准确的估计

6、参考数据；项目初期，实习人员对工作要求不熟悉；QA前期没有及时跟踪项目问题；项目组对公司过程体系的理解不足，且编码能力稍显不足。措施：对关键任务，加大跟踪力度。根据项目特点进行 2次估算，使估算比较符合实际。评审评审活动跟踪76655544443333322211110计划评审次数当前计划次数实际评审次数缺陷分布4540353025个 20151050发现问题数问题处理数评审工 作量阶段分 布评审工作量的阶段分布情况400350300250时小 200362.9154.8人 15010076.65042.5280项目策划需求设计编码交付文档规 模文档规模1400129112001000e800

7、ga600P40024420094250SFS概要设计详细设计数据库说明书初始估计 当前估计实际值文档规 模偏离原因 分析? 文档总规模为： A页。? 初始估计值为： B页。? 二次估计值为： C页。? 文档初始估计偏差为： (A-B)/A=? 文档二次估计偏差为： (A-B)/A= 估计偏差 的主要原因：1. 使用新的估算模板，估算难度较大；2. 估算人员比较少，没有让较多的人员参与到项目进行估算。措施：1、进行多次估算；2、加大对偏差较大的部分跟踪力度，确认内容有效性，减少不必要的内容。代码规 模代码规模160. 00140. 00120. 00100. 00CO80. 00LK 60.

8、0040. 0020. 000. 001 0月1 1 月1 2 月初始估计值当前估计值实际情况代码规 模偏离原因 分析?原因在于估计中使用的是有效代码行，而统计时使用的是实际所有代码行，没有比较好的统计有效代码行工具。（如注释，和自动生成的代码）没有参考比例系数（不包括注释和自动生成部分代码比例系数），进行统计有效代码行。估算人员没有相关估算经验。配置管理SCI 基线化代码规模160 . 00140 . 00120 . 00100. 00CO80. 00LK 60. 0040. 0020. 000. 0010月11月12月初始估计值当前估计值实际情况变更记 录 CR变更记 录 CR（1）CR

9、报告1.21110.8个 0.6 0.40.20000000CR总数未关闭数紧急高中低变更记 录 CR（2）变更控制 号受影响的 配置项变更时间原因分析经验 / 教训 / 改进措施基线序号基线名称计划基线 形成时间实际基线 形成时间123456789测试集成测 试已确认 问题测试问题报告706460504033个 3020910200000问题报告总数未解决问题数 影严重影响系统运行响系统运行不影响系统运行但必须修改所提建议用例执 行情况测试用例执行情况用例总数已执行数通过数未通过数无法执行数80 07 4 67 4670 06 2 560 050 040 030 020 01 2 110 0

10、00例例例例例例例例例 例 例例例例例例例例例例系统测 试用例执 行情况测试用例执行情况用例总数已执行数通过数未通过数无法执行数6051504030201029282210例例例例例例例例例例例例例例例例例例例例已确认 问题测试问题报告1.2110.8个 0.60.40.200000000问题报告总数未解决问题数严重影响系统运行影响系统运行不影响系统运行但必须修改所提建议测试结 果概述一、测试 问题概述：1. 测试人员第一次参与性能测试，对相应工具不熟悉，边摸索边测试而影响了测试速度；2. 由于项目前期需求和设计不详细，未及时指定用户需求号，导致后期无法完成测试管理工作表中的追溯；3. 由于需

11、求和设计的粗略，无法正常获取设计用例的信息，测试人员需要与开发人员不断地来回沟通，浪费了大量的时间；1. 项目开发人员在修改缺陷时，经常变换权限等的要求，且没有及时添加到需求和设计中，且没及时通知相关人员，导致测试时发现系统与需求不一样而又重新修改已制作测试用例的测试需求，增加不必要的工作；2. 测试人员管理的经验不足，没有及时进行跟踪，导致最后统计数据很费时间。二、建议 ：1、让项目开发人员对过程进行进一步的了解 , 让开发人员更改系统时有意识要通知相关人员 , 并修改相关的文档；2、测试人员实时跟踪，每天都要记好当天的效率和缺陷等相关信息；3、加强需求设计人员对需求设计文档的分析及设计能力

12、，同时要求项目开发人员能够按照需求和设计文档来实现系统。问题分 析SQA工作汇 报2 5 02 0 01 5 01 0 05 00活动次数发现问题总数 严重问题数 轻微问题数 问题解决数 上报问题数问题分 布情况问题阶段分布问 题 KP As 的 分 布 图601 4 01 3 3501 2 01 0 0408 0个 306 0204 061 31 79962 0000151000M POMMFDMEPCRR PTS C PPSPTIPSPSSOOISS问题分 析产品质量 问题主要来源：1. 同行评审中，评审准备不足，作者、评审组长等对于质量把控不严；2. 项目组文档质量把控意识不足，未进行拼

13、写检查和组内走查就开始进行走查；3. 走查时，作者未及时反馈处理结果，且项目经理和 QA代表未及时跟踪处理情况；活动问题 主要来源：1. PDSP开始太晚，模板适用性不足；2. QA代表因经验不足，工作重心出现偏离，如花费大量时间制作和修改模板，对活动的评审与跟踪力度不足。项目经验好的经验序号描述KPAs1周例会：每周五周例会中，除总结本周工作情况和当前项目情况、汇总与分析当前项目问题外，需明确下周任务，使项目成员明确自己下周任务。2邮件规范化管理：1. 建立专用项目目录和客户目录；2. 邮件分类处理：对处理完的邮件和为处理的邮件分类，可以作上适当的标记进行区分。3有效沟通：1. 发送邮件后，

14、需及时与接收者联系，以防未及时收到相应邮件（因公司最近邮件服务器总是切换，影响正常使用）；2. 在周例会等场合，为组员提供增强沟通能力的机会，如每周周例会由一到两个组员上台“讲演 ”。项目教训项目中得 到的教训序号描述KPAs1确认： 前期必须及时与客户确认，确保项目进度；为了减少客户的确认时间，可以减小确认的内容，或者分类分次进行确认，以检查表方式记录。2估计： 估计前，需对参加估计成员进行估计培训，并统一本次估计的一些标准，确保估计者以更统一的方式、更准确地估计。在整个项目过程中，最好进行几次估计，使估计相对准确。项目总评整个开发过程按照公司规范进行，在 项目开发过程中，全体项目成员克服了项目中出现的许多困难和问题。如当部分人员因其他项目需要而被调走时，项目组成员同时完成好几项任务。本项目主 要存在如下不足：? 规范意识不够；?编码效率不高，整体技能有待进一步提高；沟通协作不够顺畅，反馈机制效率不高；对评审与走查中发现的问题，作者未及时修正和反馈， QA代表未及时跟踪。改进建议序号描述KPAs1估计表有待进一步改善。2改善项目成员周报模板；改进对 PM 工作表、 CM 工作表、 QA 工作表、测试管理工作表以及工作量汇报机制，使