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

人力资源管理系统项目

总结报告

汇 报 人：张咏勤 汇报日期：2009-10—11

修改历史

日期 2009-10—11

版本 1.0 作者 张咏勤 修改内容 修订 评审号 变更控制号

项目基本信息

项目名称 项目代号 产品类别 客户 项目经理 主管高级经理 项目SCM代表 测试经理 SQA代表 测试人员 人力资源管理系统 HRM 软件产品 Comm贸易公司 ProMan Cosmo Robin Sammy Passay Testman、Van 项目基本信息

项目范围与目的 范围

人力资源管理系统(HRM)分为以下几个功能模块 ：人事管理、工资管理、职位变更管理、离职管理、培训管理、辅助系统。

目的

为Comm贸易公司定制的人力资源管理系统。

软件生命周期

计划采用的生命周期模型：增量式模型 实际采用的生命周期模型：增量式模型

在整个项目过程中，项目生命周期模型没有变更。增量模型生命周期适用于本项目开发过程。前期通过DEMO进行确认、沟通，使客户对产品有直观的认识,减少项目风险.

项目人员管理

组织结构

立项申请人高级经理项目经理开发组质量组配置人员分析人员程序员美工测试人员QA

人力投入

人员投入计划和实际的比较653210需求概要设计详细设计编码测试交付33255计划投入人员实际投入人员

培训情况

序课程名称 参加人数 号 花费工作量 培训效果 备注 1 VSTS 5 =12＊5 好 C#编码规2 范 5 =0。5＊5 良好 总计 7 62.5 良好  VSTS：解决了当前项目管理中遇到的问题,同时更进一步了解VSTS；达到较好效果。 培训结果分析  C#编码规范：让开发人员熟悉公司的一系列编码规范，便于在开发过程中的代码走查和组间协调。 项目管理

成本

成本跟踪1000009000080000700006000050000400003000020000100000立项准备需求初始估计值概要详细编码测试交付当前估计值实际情况

成本偏离分析

项目总成本为:30 万元 成本初始估计值为：25万元 成本估计偏差为：5万元

成本估计偏差的主要原因:

1、计算标准不一致;

2、没有比较准确的估计参考数据。 偏差措施：

1、加大跟踪力度.

2、进行多次估算，使估算比较符合实际。

工作量

工作量跟踪30002500人小时2000150010005000段段段段阶段阶阶阶求阶码试计需计编测设要概详细设初始计划当前计划实际情况交付阶段

项目工作量偏离原因分析

原因主要有以下几点：

没有较准确的估计参考数据；

项目初期，实习开发人员对工作要求不熟悉； QA前期没有及时跟踪项目问题;

实习开发人员公司过程体系的理解不足，且开发能力稍显不足。 措施:

对关键任务，加大跟踪力度。

根据项目特点进行2次估算，使估算比较符合实际。

生产率

总代码行数：110304 Loc

C＃: 10Loc

JavaScript： 477Loc Sql: 873Loc 代码重用：22061Loc

项目总投入： 40人月

开发人员投入： 880 小时； 美术人员投入：160 小时。 项目生产率

C＃以及JavaScript生产率：802Loc/人天

需求管理

需求处理情况348347347346344342340339339338337337336334332需求设计编码测试基线化需求数量已处理需求数量需求变更情况3221100需求设计编码测试需求变更数

项目进度 项目进度（1）

项目进度（2）

阶段完成情况050617050528050508050418050329050309050217050128050108041219码划析计计试试编试策分设设测测目求要细成统项需概详集系初始计划当前计划验收测实际情况交付

项目进度偏离原因分析

原因主要有以下几点:

没有较准确的估计参考数据；

项目初期，实习人员对工作要求不熟悉； QA前期没有及时跟踪项目问题；

项目组对公司过程体系的理解不足,且编码能力稍显不足. 措施：

对关键任务，加大跟踪力度。

根据项目特点进行2次估算,使估算比较符合实际。

评审

评审活动跟踪7665443333322211110划析计码付策分设编交目求项需计划评审次数当前计划次数实际评审次数缺陷分布40353025个20151050划求计码付策需设编交目项发现问题数问题处理数

评审工作量阶段分布

评审工作量的阶段分布情况400350300362.9人＊小时2502001.8150100500项目策划需求设计编码交付76.2.528

文档规模

文档规模1400120010001291Page8006004002000SFS概要设计初始估计详细设计当前估计实际值数据库说明书9424425

文档规模偏离原因分析

• • • • •

文档总规模为:A页。 初始估计值为:B页。 二次估计值为:C页.

文档初始估计偏差为:(A-B）/A=

文档二次估计偏差为：（A—B)/A= 估计偏差的主要原因：

1。 使用新的估算模板,估算难度较大；

2. 估算人员比较少，没有让较多的人员参与到项目进行估算。 措施：

1、进行多次估算;

2、加大对偏差较大的部分跟踪力度，确认内容有效性，减少不必要的内容。

代码规模

代码规模160.00140.00120.00100.00KLOC80.0060.0040.0020.000.0010月初始估计值11月当前估计值12月实际情况

代码规模偏离原因分析

• • •

原因在于估计中使用的是有效代码行,而统计时使用的是实际所有代码行，没有比较好的统计有效代码行工具。（如注释，和自动生成的代码） 没有参考比例系数（不包括注释和自动生成部分代码比例系数），进行统计有效代码行。

估算人员没有相关估算经验。

配置管理

SCI基线化

代码规模160.00140.00120.00100.00KLOC80.0060.0040.0020.000.0010月初始估计值11月当前估计值实际情况12月

变更记录CR 变更记录CR（1)

CR 报告1.210.8个110.60.40.200CR总数未关闭数00000紧急高中低

变更记录CR（2)

变更控制号 受影响的配置项 变更时间 原因分析 经验/教训/改进措施 基线

序号 1 2 3 4 5 6 7 8 9 基线名称 计划基线形成时间 实际基线形成时间 测试

集成测试 已确认问题

测试问题报告706050个4030201003392问题报告总数0000未解决问题数严重影响系统运行不影响系统运行但必须修改影响系统运行所提建议

用例执行情况

测试用例执行情况用例总数800746已执行数746通过数未通过数70062560050040030020012110000用例总数已执行数通过数未通过数无法执行数

系统测试 用例执行情况

测试用例执行情况用例总数605150已执行数通过数未通过数4029282220301010用例总数已执行数通过数未通过数无法执行数

已确认问题

测试问题报告1.210.81个0.60.40.20问题报告总数未解决问题数0000000严重影响系统运行不影响系统运行但必须修改影响系统运行所提建议

测试结果概述

一、测试问题概述：

1。 测试人员第一次参与性能测试，对相应工具不熟悉,边摸索边测试而影响了测试速度;

2. 由于项目前期需求和设计不详细，未及时指定用户需求号，导致后期无法完成测试管理工作表中的追溯；

3. 由于需求和设计的粗略,无法正常获取设计用例的信息，测试人员需要与开发人员不断地来回沟通，浪费了大量的时间；

4.项目开发人员在修改缺陷时，经常变换权限等的要求，且没有及时添加到需求和设计中,且没及时通知相关人员，导致测试时发现系统与需求不一样而又重新修改已制作测试用例的测试需求,增加不必要的工作；

5。测试人员管理的经验不足，没有及时进行跟踪,导致最后统计数据很费时间。 二、建议：

1、让项目开发人员对过程进行进一步的了解，让开发人员更改系统时有意识要通知相关人员,并修改相关的文档；

2、测试人员实时跟踪，每天都要记好当天的效率和缺陷等相关信息；

3、加强需求设计人员对需求设计文档的分析及设计能力，同时要求项目开发人员能够按照需求和设计文档来实现系统。

问题分析

SQA

工作汇报

250200150100500活动次数发现问题总数严重问题数轻微问题数问题解决数上报问题数数数数数次数题题决动总问问解活题重微题问严轻问发现上报问题数

问题分布情况

问题阶段分布605040问题KPAs的分布图140120100806040200133个30201006131709009165RMSPPSPTOSSMSCMOPFOPDISMSPETPIC求项备求计试需立准需设试测编码及单元测交付PR

问题分析

产品质量问题主要来源：

1。 同行评审中，评审准备不足，作者、评审组长等对于质量把控不严； 2. 项目组文档质量把控意识不足,未进行拼写检查和组内走查就开始进行走查；

3. 走查时，作者未及时反馈处理结果,且项目经理和QA代表未及时跟踪处理情况;

活动问题主要来源：

1。 PDSP开始太晚，模板适用性不足；

2。 QA代表因经验不足，工作重心出现偏离，如花费大量时间制作和修改模板，对活动的评审与跟踪力度不足。

项目经验

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

项目中得到的教训 序号 描述 KPAs 1 确认:前期必须及时与客户确认,确保项目进度;为了减少客户的确认时间，可以减小确认的内容，或者分类分次进行确认，以检查表方式记录. 2 估计:估计前，需对参加估计成员进行估计培训，并统一本次估计的一些标准，确保估计者以更统一的方式、更准确地估计。在整个项目过程中,最好进行几次估计,使估计相对准确。 项目总评

整个开发过程按照公司规范进行，在 项目开发过程中，全体项目成员克服了项目中出现的许多困难和问题.如当部分人员因其他项目需要而被调走时，项目组成员同时完成好几项任务。

本项目主要存在如下不足：

•

规范意识不够；

• • •

编码效率不高，整体技能有待进一步提高； 沟通协作不够顺畅，反馈机制效率不高；

对评审与走查中发现的问题，作者未及时修正和反馈,QA代表未及时跟踪。

改进建议

序号 1 描述 估计表有待进一步改善. KPAs 2 改善项目成员周报模板；改进对PM工作表、CM工作表、QA工作表、测试管理工作表以及工作量汇报机制，使统计工作量和分析数据更加容易. 及时更新项目进度表。mpp,并将重要内容通过邮件通知相关人员（如里程碑工作产品的走查或评审），相关人员需尽早反馈意见和建议。 WBS细分和调整时，考虑返工工作量，预留一定的缓冲时间（视项目实际周期等情况而定)。 寻找VSS和Sharepoint的同步接口，或Sharepoint快速批量上传的方式,以减少配置工作量. 重要变更或对需求、进度较大调整之后,进行新一轮估计,尽量让项目组人员参与,以更好地确保项目进度。 3 4 5 6