工作量的评估方法

工作量的评估方法
工作量的评估方法

工作量的评估方法

1.软件开发价格估算方法

软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便于计算,给出一个计算公式:

软件开发价格=开发工作量×开发费用/人·月

1.1开发工作量

软件开发工作量与估算工作量经验值、风险系数和复用系数等项有关:

软件开发工作量=估算工作量经验值×风险系数×复用系数

1.1.1估算工作量经验值(以A来表示)

软什开发工作量的计算,曾有人提出以源代码行或功能点来计算,这些方法实施起来均有不少难度。目前国际上仍旧按以往经验的方式加以计算,国内各软件企业也是采用经验的方式加以估算工作量。

为了更好地规范估算方法,建议可按照国家标准“GB/T8566-2001软件生存周期过程”所规定的软件开发过程的各项活动来计算工作量。

工作量的计算是按一个开发工作人员在一个月内(日历中的月,即包括国家规定的节假日)能完成的工作量为单位,也就是通常所讲的“人·月”。

特别要提醒的是软件开发过程中既包括了通常所讲的软件开发,也应包括各类软件测试的活动。

1.1.2风险系数(以σ来表示)

估算工作量经验值亦会存在较大风险,造成软件危机的因素很多,这也是一个方面的因素。特别当软件企业对该信息工程项目的业务领域不熟悉或不太熟悉,而且用户又无法或不能完整明白地表达他们的真实的需求,从而造成软件企业需要不断地完善需求获取,修改设计等各项工作。因此:

l≤风险系数≤1.5

根据我们对软件企业的了解,超过估算工作量经验值的一半,已是不可接受,所以我们确定“1.5”为极限值。当然这既要看企业的能力,也要看用户能接受的程度。

1.1.3复用系数(以τ来表示)

估算工作量经验值是软件企业承担一般项目来估算的,但如果软件企业已经采用“基于构件的开发方法”,并己建立起能够复用的构件库(核心资产库),或者已有一些软件产品,仅作二次开发,从而使软件开发工作量减少。因此:

0.25≤复用系数≤1

根据国内外软件企业在实施基于构件开发方法(软件产品线)的经验数据,提高工作效率达到25%(最高值)。

1.2开发费用/人·月

软件企业的商务成本、国家税收、企业利润、管理成本和质量成本。均可摊分到各个软件开发人员头上。

开发费用/人·月=(P+Q+R)×S×τ

1.2.1P(人头费)

人头费主要是员工的工资、奖金和国家规定的各项按人计算的费用。其总量在软件企业中的商务成本占70%-80%。

P=B×1.476

国家规定的公积金7%,医疗保险金12%,养老金22%,失业金2%(即通常所说的四金),另外还有按工资总额计征的工伤保证金0.5%,生育保证金0.5%,残

疾基金1.6%,工会基金2%,累计为47.6%。

B为平均工资,即企业支付给员工的工资、奖金、物质奖励等多项总和,除以企业员工数,分摊到每个月。

1.2.2Q(办公费)

办公费包括企业办公房屋租赁费和物业管理费、通信费、办公消耗品、水电空调费、设备折旧、差旅费,另外也包括企业对员工的在职培训所支付的费用,其总量在软件企业中的商务成本占20%-30%。

Q=B/3

此处办公费用按商务成本的25%计算。

1.2.3R(国家税收和企业利润)

由于国家实施发展软件产业的优惠政策,故不单独列出计算,但软件企业仍需承担缴纳国家税收的义务,可一并与企业利润一起考虑。

另外,软件企业的员工不可能全年满负荷地工作,即使一年十二个月都安排工作,但也需抽出时间进行在职培训和提职的岗前培训。据我们的了解,软件企业的员工一年能有10个月到11个月的工作也是正常的。

R=B/3

此处为我们的建议方案,各软件企业可视情况加以变更。

1.2.4S(管理系数)

通常每个机构的管理人员都会有一定的比例,参考一些机构的做法,按每十个软件人员配备两个管理人员即管理成本:

1≤S≤1.2

1.2.5T(优质系数)

提高软件质量,必然有所开支,即质量成本,对于不同的软件企业来说,其质量成本不尽相同。

软件企业与其他企业一样,也有诚信和品牌等诸多因素,从而增加企业的开支。

目前我们可以按通过ISO9000质量体系认证和CMM或CMMI的认证来确定,分别取值1.05、1.1、1.15、1.2。

今后建议可对软件企业的资质分为四级。由软件行业协会根据CMMI的认证、品牌、诚信程度等各种因素加以确定。此体系建设还有待进一步探索。

据此,我们综合上述各点:

开发费用/人·月=(B×1.476+B/3+B/3)×l.2×T

=B×(1.476+2/3)×1.2×T

=B×2.575×T

=B×λ

当T=1.05时,λ=2.7

当T=1.2时,λ=3.09

因此,2.7≤λ≤3.09

对于承接国外软件外包业务,一方面员工的工资较高,另外工作的安排也较难满负荷工作,用此建议R=B/2。因此

开发费用/人·月=B(1.476+1/3+1/2)×1.2×T

=B×2.767×T

=B×λ

当T=1.05时,λ=2.906

当T=1.2时,λ=3.32

因此,2.9≤λ≤3.32

结论:

软件开发价格=A×σ×τ×B×λ

A:估算工作量经验值

B:软件企业的平均工资/人·月

Q:风险系数l≤Q≤1.5

T:复用系数0.25≤τ≤1

λ:综合系数2.7≤λ≤3.09

2.软件(系统)维护收费价格估算方法

在完成信心工程项目的系统集成和应用软件开发,并交付用户正式运行的一年内,对软件(系统)实行免费维护服务一年。

在正式运行一年后,软件企业应与用户签定软件(系统)维护合同。该合同属技术转让合同,也可属技术开发合同。

根据不同的用户要求,可分四种级别进行软件(系统)维护。

2.1A级

软件企业派出技术人员常驻用户,解决日常运行中发生的问题。

2.1.1U(系统建设投资额)

用户需要软件企业维护的系统,该系统建设的投资额。如用户只需要软件企业维护其所开发的应用软件,U就是该应用软件开发费;如用户需要软件企业维护整个系统,包括计算机硬件、软件、网络和应用软件,则U就是该信息工程项目的总投资额。

2.1.2N(技术人员数)

软件企业派出N个技术人员,常驻用户,因此:

软件(系统)维护费/年=U×15%或B×λ×N×12

B、λ参见1.

2.2B级

软件企业每周七天,每天24小时(即7×24小时)响应,2小时到现场,且每天派技术人员到现场进行软件(系统)性能调试,使之运行处于良好状态。

软件(系统)维护费/年=U×10%

2.3C级

软件企业7×24小时响应,2小时到场。

软件(系统)维护费/年=U×5%

2.4D级

用户的信息工程系统或应用软件发生问题,由原承担的软件企业派人维护。

2.4.1B’

这种维护方式要求软件企业需要保存所有的技术档案,更需要软件企业抽出专人来不断熟悉和全面掌握该软件(系统)的各项技术细节。因此,软件企业的这项支出必然要在维护费用收入中得到回报。

以1.1.3节中的B作为参数,将其人·月单位改为人·天,以B’表示。

2.4.2τ’

软件企业如果采用基于构件开发方法,并建立起构件库,则会大大提高软件维护的效率。另外,如果有多家用户运行的系统大致类似,也可有所提高效率。

以1.1.3节中的τ作为参数,以τ’来表示。因此:

软件(系统)维护费/次=B’×τ’×n

此次n表示所需要的人·天数。τ’的取值是0.2≤τ’≤1。

3.系统集成价格的估算方法

将整个系统所涉及到的设备、软件、网络整和起来,并能正常地运行,其运行的结果能达到用户建立该系统的目标。这就是系统集成的含义。因此,可以理解为单纯的设备采购和供应并不涉及系统集成,以及单纯的应用软件开发也并不涉及系统集成。

系统集成费应与整个系统的规模、整个系统的复杂程度等项有关。

系统规模往往与系统建设费用密切相关。为了简便计算,以系统建设费用(以U来表示)为参考坐标。复杂程度(以α来表示)可分四种级别来区分。

系统集成费=U×α×T

T参见1.2.5节

3.1A级

整个系统涉及到计算机硬件、软件、局域网络,且体系结构在三层次以下(含三层次)。

5%≤α≤8%

3.2B级

整个系统涉及到计算机硬件、软件、局域网络、互联网,且体系结构在三层以上(含三层次)。

7%≤α≤10%

3.3C级

整个系统涉及到计算机硬件、软件、局域网络、互联网以及多种网络接口。

8%≤α≤12%

3.4D级

整个系统涉及到计算机硬件、软件、网络、通信以及各种数据采集设备接口或者与用主系统有接口。

10%≤α≤15%

4.系统解决方案费用估算方法

根据用户所提出的初步需求,软件企业根据以往的经验为之提供整个系统建设的方案,包括需购买的计算机硬件、软件、网络设备和应用软件开发的大体设想、费用估算、进度初步安排、信息化所涉及到的规章制度的一些规划,有时还会涉及信息中心的建设等等。这就是系统解决方案所要完成的工作。

目前国内市场对于系统解决方案是一种智力劳动成果的认识不足,以及国内多数招标公司并不熟悉信息技术,从而更加使得系统解决方案收费变得困难。因此,目前的收费处于过渡阶段。

系统解决方案费用与整个系统的规模、复杂程度等项有关。

系统规模往往与系统建设费用密切相关,为了简便计算,以系统建设的总投资(以U来表示)为参考坐标。

复杂程度就是用户的功能、性能要求复杂性、信息接口的类型和数量有关,以β来表示。

解决方案费用=U×β×T

T参见1.2.5节

关于β我们参照第3节所列各级。

A级:0.7%≤β≤1.2%

B级:1%≤β≤1.8%

C级:1.5%≤β≤2.2%

D级:2%≤β≤3%

秋风词三五七言秋风清,秋月明,

相亲相见知何日,此时此也难为情。

岗位工作量测评分析报告(模板)

岗位工作量测评分析报告 一、目的 为适应汽车产销下滑的行业形势,相应配合上级单位对于合理配置人力资源的总体要求,同时为了解员工的实际工作情况,提高员工工作效率,优化组织架构,合理利用人工成本,特开展此项工作。 二、测评范围 公司职能及辅助岗位。 三、测评时间 *年*月*日-*年*月*日。 四、采用方法 工作量化分析法,即根据各岗位所写的岗位说明书,将职责细化为日常的工作步骤,对工作步骤完成的时间进行统计,与预先设计好的岗位工作判定标准进行对比,结合岗位任职人员的能力素质,对各岗位的工作量进行评估判断。 五、基本情况 1.测评部门 综合管理部(食堂、司机除外)、财务部、采购部、质量部、技术部(行政专员)、制造部(技能岗位除外),测评人员共计52人。 2.结合工作情况,将工作分为日常性、阶段性、突发性工作;年岗位工作量统计,1天按8小时,1周按5天,一年按250天计算,即50周。 3.本月共31天,周六、周日放假合计8天,本月实际出勤天数23天(按标准工作时间计算),共10166H。 六、公司整体数据分析 总体来说,本次员工岗位工作量测评虽有些方面不尽人意,但作为推行的一项管理措施,基本上没遇到较大的抵触,测评人员也算比较配合。 (一)工作日志完成情况 工作内容:通过近半个月的工作日志的核对,工作内容与岗位说明书一致。 (二)岗位工作结构占比 1.职能岗位工作结构 图标 2.辅助岗位工作结构 图标 根据部门评定后的数据可看出职能岗位日工作量饱满度范围为:50%-100%,日常工作量占总工作量比例范围为:48.92%-89.85%;辅助岗位日工作量饱满度范围为:71.25%-133.75%,日常工作量占总工作量比例范围为:55.30%-95.19%;测评岗位主要以日常性工作为主。 (三)工作日志数据、岗位测评填报数据与考勤数据对比

工作量评估方法完整版.完整版.docx

关于工作量评估方法 为能清楚阐明论点。先举两个例子。 大家一定都听说过“龟兔赛跑”的故事,故事里乌龟是正面人物,而兔子作为反面人物受人讥讽,其中的寓意教育人们做事要像乌龟一样有坚忍不拔的精神。如果换个角度分析这个故事。则会有不同的结论。兔子在整个赛跑过程中做了两件事,那就是赛跑和睡觉;乌龟则仅做了一件事,就是不停地赛跑。如果我们试把时间延长(即看看它们在赛后又做了什么),可以想象乌龟由于比赛的疲劳,而跑回家呼呼大睡了;兔子呢?由于比赛中同时也保养了精神,赛后可以做其它更多自己想做的事。由此,不难得出整个过程兔子的效率更高。另外,乌龟并不擅长跑步,却安排它去参加这场比赛,其效率必然极低,把这种现象映射到企业管理中去,也颇发人深思。 试看一个说明工作效率与工作饱和相矛盾的例子:某工厂的一位计算机技术人员,现场发生了微机故障,从他的办公室到达故障点的方式有两种选择,其一是步行,需要10分钟;其二是骑自行车,只需2分钟。我们设步行到现场的为甲,骑车到现场的为乙,最后统计:两人去处理同样的一个工作,甲用了30分钟,而乙只用了15分钟,(这里是假设两人故障的修复时间相同,但事实上甲这类人在故障修复中要花更多的时间)。乙在剩下的15分钟又可以做其它更多的事情,单从这点出发,甲与乙在工作成效上就不仅是1:2的差距了,而是1:N(即甲做一件事的时间,乙做了N件事)的差距。但在现实中,甲往往成了“工作量饱满、劳动模范”的象征;而乙却常常恰好相反,这是管理人员认识上的一大误区,长此下去必然带来管理上的一系列问题。 工作效率由员工的自身因素决定,但如何激励员工提高工作效率,目前仍是管理上的问题。首先是工作分配的合理化,它直接影响工作的效率,让乌龟去赛跑,显然是不合理,所以对工作的合理分配是提高效率的首要条件,这与管理人员的工作密不可分,要求管理人员不仅清楚了解管辖范围内的工作内容,而且要对被管理人的基本情况有清楚的认识。 工作分配合理后,那如何主动去提高每个员工的工作效率呢?竞争是个好方法,奖惩也是个好方法,另一种就是让员工自身有好的素质,拥有正确的人生观及世界观,提高效率便成为很自然的事。前两种方法是被动的,也是目前企业管理中普遍采用的方法,而第三种方法突出了“人自身的因素,希望通过发挥主观能动性来提高工作效率。因为当一个人具有一定知识水平(包括综合知识和技能知识),拥有正确的人生观及世界观,那么我们说,从主观上他会自觉主动地提高效率,从效率中求饱和,再从饱和中追求效率。这样看来采用这种方法,不仅仅能提高效率,而且同时无形中也解决了效率与饱和间的矛盾。 由此可见,通过主观能动性来提高效率,关键就是如何提高员工的综合素质问题,这个素质并非仅仅指的员工的技术知识水平,更重要的还包含道德修养、情操和理想等一些深层次东西。目前企业对员工的素质教育,仅仅是偏重于技能知识的教育,认为员工只要有好的技术和熟练的操作,便有了效率,这是远远不够的。因此,素质的提高在于两方面:①个人专业技能及社会知识要丰富,这是效率的基本前提;②同时应丰富其它的各类知识,如自然知识及人文知识等等。企业管理中在对提高员工素质方面应该投人更多,这样可以更快的从被动地提高工作效率转变为主动地提高工作效率。 以上谈了工作效率问题。现在再来看看工作量问题。评价一个人工作饱和度高不高(注意这里是针对同一个工作),答案就只有两种:低效率饱和度高;高效率饱和度低。可见效率与饱和度存在着矛盾。而“工作饱和”的含义应该是指员工的有效工作时间与规定的劳动时间相等或近似相等,这里的工作时问是指有效的工作时间,强调“有效”二字,“有效”就包含效率和成效的意思。这又体现了效率与饱和度有统一的一面。而在现实的管理工作中,管理人员常常忽略“有效”的重要性,虽然这种“忽略”往往并不是有意的,自然也就无法正确评价如何才算是工作饱和,于是便出现了“整天忙个不停的员工就一定是个好员工”的谬论。所以如何科学地去看待工作饱和度其实也是管理上的问题,它要求管理人员自身具有好的素质及高的效率,这样才谈得上被管理的人有好的素质及高的效率。

几种测试工作量的估算方法

在测试项目管理中或编写测试计划时,经常需要对某个测试工作进行工作量的预算,很多时候都是凭个人的工作经验进行估算的,如能结合一些常规的估算方法,有助于估算的精确度。 以下是网上找到的一些常规的估算测试工作量的方法: 1、Ad-hoc方法 这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者,一直到用完了预算的经费。 这种情况普遍存在于非常不成熟的组织,并且时常有100%的错误差数。 2、开发时间的百分比法Percentage of development time。 这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先,开发工作量使用例如LOC或FP方法被估算出来,然后使用一些探索性的方法来限制测试的工作量。 这种方法变化比较大而且通常基于以前的经验。 通常预留项目的总花费时间的35%给测试。?5-7%给组件和集成测试?18-20%给系统测试?10%给接收测试(或回归测试等) 3、类比法(经验值法或历史数据法) 根据以前或相似项目(主要在项目性质,领域,规模上有相似)所积累的经验或历史数据来估算工作量。类比法估计结果的精确度取决于历史项目数据的完整性和准确度,因此,用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制,对历史项目的数据分析是可信赖的。需要收集以下相关的历史数据:?在设计和实现阶段花费的时间?测试工作的规模,例如用户需求的数量,页面数,功能点?数据样式,例如实体,字段的数量?屏幕或字段数量?测试对象的规模,例如KLOC 4、WBS(work breakdown structure)估算法 将项目或产品分解为具体的工作,然后分别对各个工作进行时间估算,最终求和得出项目或产品的测试工作量/时间。 5、Delphi法 Delphi法是最流行的专家评估技术,在没有历史数据的情况下,这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术,要求有多种相关经验人的参与,互相说服对方…… Delphi法的步骤是:1、协调人向各专家提供项目规格和估计表格;2、协调人召集小组会各专家讨论与规模相关的因素;3、各专家匿名填写迭代表格;4、协调人整理出一个估计总结,以迭代表的形式返回专家;5、协调人召集小组会,讨论较大的估计差异;6、专家复查估计总结并在迭代表上提交另一个匿名估计;7、重复4-6,直到达到一个最低和最高估计的一致。 6、PERT估计法 PERT对各个项目活动的完成时间按三种不同情况估计:一个产品的期望规模,一个最低可能估计,一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计。Pert 估计可得到代码行的期望值E,和标准偏差SD

工作量考核方案

工作量考核方案 工 作 量 考 核 方 案 (拟定稿) 说明: 一.本包括考核制度和考核量表两部分。. 二.考核量表主要是测评教务处学生助理员的绩效,同时作为教 务处学生助理工作组工资发放的参考依据。 三.附考核流程图如下: 四、本制度每学期期末考试周前接受所有老师和教助意见并及时完 善,制度完善并施行前应专门召开集体会议,公开解释制度具体细节的构建理由和含义。最终解释权归教务处学生助理工作量评估小组。 五、本制度提交华中师范大学教务处学生助理工作组备案。

教务处学生助理考核制度 第一章 第一条总则考核的目的是通过客观评价教务助理的工作能力、态度,优化教务 处助理队伍,并客观合理地安置教务助理,做到人岗匹配,并以考 核结果为参考,发放教助的年终薪酬。 第二条本规定中使用的专业术语定义如下: (一)能力考核---------通过工作行为,观察、分析、评价教助具有的工作能力。 (二)态度考核---------通过对教助的工作努力情况和工作热情进行观察和评 价。 (三)业绩考核---------对教助分担的工作完成情况进行观察、分析和评价。(四)360度考核法----即全视角绩效考核法,通过不同的考核者(老师、同学、 其他教助等)从不同的角度来全方位考核教助工作情况。 (五)KPI法------------即关键业绩指标,选取一些关键的、与教助队伍目标实 现关系比较紧密的工作内容作为考核项目。 (六)考核者-------------老师、同学以及其他教助。 (七)被考核者----------2007-2008学年度教务助理。

(八)考核执行者--------教务助理工作组。 第三条考核原则 (一)考核标准尽可能量化; (二)考核标准的制定以教助管理条例为依据,按照教务 处的标准制定。 第四条每位教务助理一学期工资标准在400元左右浮动,教务助理最后所 得工资根据考评结果而定。 第五条考核方法是360度考核法,由教务助理所在办公室老师,其他办公室 教助(即同事)共同参与,实行打分制,考核表由教务助理所在办公室老师填写,同时参考其他办公室教助(即同事)意见,运用KPI法确定绩效考核标准。 第二章考核流程与实施 第一条教务助理工作组开会讨论确定最终考核制度; 第二条由教助工作量评估小组整理制度材料,交给教务 助理工作组审核, 最后上交教务助理管理老师审批; 第三条制度执行,由各办公室老师对本办公室教助进行 考核; 第四条由教助工作量评估小组进行汇总,按分数列出等级,确定薪酬;

如何做好岗位工作量调查

如何做好岗位工作量调查 岗位工作量调查,也称为“岗位工作饱满度测试”,它是公司领导和人力资源管理部门了解本单位在岗员工工作状况的主要手段,同时也是各单位进行定岗定编的重要依据,它对各单位的人力资源管理工作具有较强的现实意义。而很多单位在开展这项工作时往往感觉非常棘手,经常因推行困难而不了了之或半途而废。归纳起来,主要有以下几方面的问题:一是缺乏科学有效的操作方法,导致调查结果形式各异,无法比较;二是缺乏明确的衡量标准,对调查结果不能进行有效判别;三是受制于本单位人员能力素质和管理制度的制约,调查结果没有反映岗位真实情况。以上问题如果得不到有效解决,岗位工作量调查就难以达到预期的效果,对人力资源管理的指导意义也就大打折扣。笔者根据以前项目上的经验,总结出一套岗位工作调查的方法,在实际运用中可以较好地应对以上提到的问题,并得到了客户认可,现提出来与大家分享。 这套方法是从工作分析入手,首先明确岗位的具体工作职责,并将职责细化为日常的工作步骤,然后对这些工作步骤的完成时间进行统计,与预先设计好的岗位工作判定标准进行对比,结合岗位任职人员的能力素质,对各岗位的工作量进行评估判断,最后根据本单位实际情况和未来经营目标,对岗位设置合理性进行评判,对相关岗位职责提出调整以及对岗位编制提出建议。在上述步骤中,明确岗位工作职责是属于工作分析的范畴,在很多文章中均有阐述,因此不作为本文讨论的重点,本文是从岗位工作职责明晰以后入手,重点讨论如何进行岗位工作量调查。 一、设定岗位工作量化判定标准 岗位工作量化判定标准从岗位工作量、岗位工作结构和岗位工作强度入手,根据经验数据,确定相应标准,以此作为判断岗位设置依据是否充分以及岗位是否需要调整的依据。如下表所示:

人力资源如何进行岗位工作量调查

如何进行岗位工作量调查 岗位工作量调查,也称为岗位工作饱满度测试,是企业领导和人力资源管理部门了解在岗员工工作状况的主要手段,也是企业进行定岗定编的重要依据。但很多企业在开展这项工作时感觉非常棘手,往往半途而废。归纳起来,主要有以下几方面的原因: 一是缺乏科学有效的操作方法,导致调查结果形式各异,无法比较: 二是缺乏明确的衡量标准,对调查结果不能进行有效判别: 三是受制于本单位人员能力素质和管理制度,调查结果不能反映岗位真实情况。 笔者根据多年的咨询管理经验,总结出一套容易操作的岗位工作量调查方法,能够较好地应对以上问题。这套方法首先是从工作分析入手,明确岗位的具体工作职责,并将职责细化为日常的工作步骤,然后对这些工作步骤的完成时间进行统计,与预先设计好的岗位工作判定标准进行对比,结合岗位任职人员的能力素质,对各岗位的工作量进行评估判断,最后根据本单位实际情况和未来经营目标,对岗位设置合理性进行评判,提出相关岗位职责调整方案以及岗位编制建议。本文重点讨论岗位工作职责明晰以后如何进行岗位工作量调查。 岗位工作量化判定标准 岗位工作量化判定标准是根据岗位工作量、岗位工作结构和岗位工作强度来确定相应标准,以此作为判断岗位设置是否充分以及岗位是否需要调整的依据。岗位工作量化判定标准如下: 1、岗位工作量标准工作量百分比法:工作量饱满度=岗位有效工作时间/平均正常工作时间×100% 统计工作时间一般以日、周、月或年为单位,如岗位年实际工作饱满度=岗位年实际工作日/年有效工作日×100%。一般饱满度达到70%以上时,说明岗位工作量饱满。 岗位工作量饱满度判别标准如下 很饱满:90%以上; 饱满:70%-90%: 基本饱满:50%-70%, 不饱满:50%以下。 2、岗位工作结构标准 按照日常性、阶段性和临时性工作划分,日常性工作是指依据现有组织目标和职能展开的工作,日常性工作量/总工作量×100%,比值在50%以上,说明岗位设置依据充分,一般

软件评估报告

德米萨ERP评估报告

目录 1 评估描述 (3) 1.1评估目标 (3) 1.2软件供应商简介 (3) 2项目可用性 (4) 2.1业务单据基本流程 (4) 2.2操作性 (4) 2.3交互功能 (4) 2.4定制化 (4) 3软件成本 (5)

1 评估描述 1.1评估目标 公司新项目需求,Iphone二手手机翻新销售项目,为了能使用符合业务流程的软件ERP应用功能,考察了德米萨进销存旗舰版ERP套件,主要评估业务上是否够正常处理Iphone项目的业务流程。 1.2软件供应商简介 上海德米萨信息科技有限公司(上海幻仙石软件有限公司)是经中华人民共和国工业和信息化部以及上海市经济和信息化委员会评定和审核的双软企业,是国家重点支持的软件企业。公司按照国际先进管理模式和制度组建,公司创始团队最早于2002年从事政府机构软件定制开发与服务,从2007年起专注企业管理软件的研究与开发,陆续推出“德米萨”系列智能办公管理软件,并于2009年起开始正式面市销售,迄今已积累各行各业大量客户群。公司拥有一支具备国际化视野和多年实战经验的团队,集合了一批世界上优秀的技术人才和资深的企业管理专家以及信息安全专家,公司高层领导及骨干员工均从事软件行业十余年,公司成立以来,一直专注于企业管理软件的开发和服务,在中国企业信息化的浪潮下,德米萨信息科技逐渐走向成熟,规模日趋壮大。公司高层管理人员及骨干员工均有多年从事政府机构、事业单位及大型企业管理软件研发、实施等从业经历,具有丰富的管理咨询和技术服务经验,近90%的员工从事软件开发、系统集成、应用维护、技术咨询和信息安全工作。

工作量的评估方法

工作量的评估方法 1.软件开发价格估算方法 软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便于计算,给出一个计算公式: 软件开发价格=开发工作量×开发费用/人·月 1.1开发工作量 软件开发工作量与估算工作量经验值、风险系数和复用系数等项有关: 软件开发工作量=估算工作量经验值×风险系数×复用系数 1.1.1估算工作量经验值(以A来表示) 软什开发工作量的计算,曾有人提出以源代码行或功能点来计算,这些方法实施起来均有不少难度。目前国际上仍旧按以往经验的方式加以计算,国内各软件企业也是采用经验的方式加以估算工作量。 为了更好地规范估算方法,建议可按照国家标准“GB/T8566-2001软件生存周期过程”所规定的软件开发过程的各项活动来计算工作量。 工作量的计算是按一个开发工作人员在一个月内(日历中的月,即包括国家规定的节假日)能完成的工作量为单位,也就是通常所讲的“人·月”。 特别要提醒的是软件开发过程中既包括了通常所讲的软件开发,也应包括各类软件测试的活动。 1.1.2风险系数(以σ来表示) 估算工作量经验值亦会存在较大风险,造成软件危机的因素很多,这也是一个方面的因素。特别当软件企业对该信息工程项目的业务领域不熟悉或不太熟悉,而且用户又无法或不能完整明白地表达他们的真实的需求,从而造成软件企业需要不断地完善需求获取,修改设计等各项工作。因此: l≤风险系数≤1.5 根据我们对软件企业的了解,超过估算工作量经验值的一半,已是不可接受,所以我们确定“1.5”为极限值。当然这既要看企业的能力,也要看用户能接受的程度。 1.1.3复用系数(以τ来表示) 估算工作量经验值是软件企业承担一般项目来估算的,但如果软件企业已经采用“基于构件的开发方法”,并己建立起能够复用的构件库(核心资产库),或者已有一些软件产品,仅作二次开发,从而使软件开发工作量减少。因此: 0.25≤复用系数≤1 根据国内外软件企业在实施基于构件开发方法(软件产品线)的经验数据,提高工作效率达到25%(最高值)。 1.2开发费用/人·月 软件企业的商务成本、国家税收、企业利润、管理成本和质量成本。均可摊分到各个软件开发人员头上。 开发费用/人·月=(P+Q+R)×S×τ 1.2.1P(人头费) 人头费主要是员工的工资、奖金和国家规定的各项按人计算的费用。其总量在软件企业中的商务成本占70%-80%。 P=B×1.476 国家规定的公积金7%,医疗保险金12%,养老金22%,失业金2%(即通常所说的四金),另外还有按工资总额计征的工伤保证金0.5%,生育保证金0.5%,残

软件开发工作量估算和报价

1.软件开发价格估算方法 软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便于计算,给出一个计算公式: 软件开发价格=开发工作量×开发费用/人·月 开发工作量 软件开发工作量与估算工作量经验值、风险系数和复用系数等项有关: 软件开发工作量=估算工作量经验值×风险系数×复用系数 软什开发工作量的计算,曾有人提出以源代码行或功能点来计算,这些方法实施起来均有不少难度。目前国际上仍旧按以往经验的方式加以计算,国内各软件企业也是采用经验的方式加以估算工作量。 为了更好地规范估算方法,建议可按照国家标准“GB/T8566-2001软件生存周期过程”所规定的软件开发过程的各项活动来计算工作量。 工作量的计算是按一个开发工作人员在一个月内(日历中的月,即包括国家规定的节假日)能完成的工作量为单位,也就是通常所讲的“人·月”。 特别要提醒的是软件开发过程中既包括了通常所讲的软件开发,也应包括各类软件测试的活动。 估算工作量经验值亦会存在较大风险,造成软件危机的因素很多,这也是一个方面的因素。特别当软件企业对该信息工程项目的业务领域不熟悉或不太熟悉,而且用户又无法或不能完整明白地表达他们的真实的需求,从而造成软件企业需要不断地完善需求获取,修改设计等各项工作。因此:

l≤风险系数≤ 根据我们对软件企业的了解,超过估算工作量经验值的一半,已是不可接受,所以我们确定“”为极限值。当然这既要看企业的能力,也要看用户能接受的程度。 估算工作量经验值是软件企业承担一般项目来估算的,但如果软件企业已经采用“基于构件的开发方法”,并己建立起能够复用的构件库(核心资产库),或者已有一些软件产品,仅作二次开发,从而使软件开发工作量减少。因此: ≤复用系数≤1 根据国内外软件企业在实施基于构件开发方法(软件产品线)的经验数据,提高工作效率达到25%(最高值)。 开发费用/人·月 软件企业的商务成本、国家税收、企业利润、管理成本和质量成本。均可摊分到各个软件开发人员头上。 开发费用/人·月=(P+Q+R)×S×τ 人头费主要是员工的工资、奖金和国家规定的各项按人计算的费用。其总量在软件企业中的商务成本占70%-80%。 P=B× 国家规定的公积金7%,医疗保险金12%,养老金22%,失业金2%(即通常所说的四金),另外还有按工资总额计征的工伤保证金%,生育保证金%,残疾基金%,工会基金2%,累计为%。B为平均工资,即企业支付给员工的工资、奖金、物质奖励等多项总和,除以企业员工数,分摊到每个月。

如何评估测试工作量

场景一:合同前的工作量估算 场景描述: 软件开发网 (1)没有实施过CMMI2级 (2)合同未签,需要给客户报价 (3)有客户的概要需求,有类似的项目数据可供参考 (4)需要估计整个项目的总工作量,以便于估算总成本,给客户报价 软件开发网 估算步骤: (1)寻找类似的历史项目,进行项目的类比分析,根据历史项目的工作量凭经验估计本项目的总工作量; (2)进行WBS分解,力所能及地将整个项目的任务进行分解; (3)参考类似项目的数据,采用经验法估计WBS中每类活动的工作量; (4)汇总得到项目的总工作量; (5)与第(1)步的结果进行印证分析,根据分析结果,确定估计结果。 场景二:基于详细需求的经验估计 场景描述: (1)只有详细需求,没有历史数据 估算步骤: (1)WBS分解,将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。 (2)采用经验法估计每个活动的工作量; (3)汇总得到:每个阶段的工作量、项目的总工作量。 其他说明: 在该场景下,只使用了经验法,无法对结果进行印证,难以判断结果的合理性。 场景三:由编码估算整体 场景描述: (1)有类似项目的历史数据 (2)有编码活动的生产率数据 (3)有详细需求 (4)实施了CMMI2级,但是没有积累历史项目的工作量分布数据软件开发网 估算步骤: (1)产品分解,将系统分为子系统,子系统分解为模块; (2)WBS分解,将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要

识别出所有的交付物、项目管理活动、工程活动等。 (3)建立WBS分解中的活动与产品元素的映射关系,识别出WBS中哪些活动可以采用模型法估算; (4)估计产品元素的规模,可以采用代码行法或功能点法,并估计每个产品元素的复杂度、复用率等; (5)根据历史的编码阶段的生产率数据和产品元素的规模估计、复杂度、复用率等采用模型法计算每个产品元素的编码工作量; (6)根据历史的类似项目的数据及估算人的经验估计其他活动的工作量,可以采用经验法。(7)汇总得到:每个阶段的工作量、项目的总工作量。 其他说明: 在该场景下,混合使用了经验法与模型法,这2种方法互相补充,而不是互相印证。 场景四:由总体印证基于WBS的估计 场景描述: (1)有类似项目的历史数据 (2)有类似项目的全生命周期的生产率数据(含管理工作量) (3)有详细需求 (4)实施了CMMI2级,但是没有积累历史项目的工作量分布数据 估算步骤: (1)产品分解,将系统分为子系统,子系统分解为模块; (2)估计产品元素的规模,可以采用代码行法或功能点法; (3)累计出整个产品的总规模,并估计产品总体的复杂度、复用率等; (4)根据类似项目的全生命周期的生产率数据和产品的总规模、复杂度、复用率等采用模型法计算总的开发工作量; (5)WBS分解,将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。 (6)根据历史的类似项目的数据及估算人的经验估计所有活动的工作量,可以采用经验法。(7)汇总得到:每个阶段的工作量、项目的总工作量。 (8)与第(4)步得出的工作量进行比较印证,如果偏差不大,则以第(7)步的结果为准,如果偏差比较大,要仔细分析原因,可能的原因举例如下: 类似项目的生产率数据不适合本项目; WBS分解的颗粒度不够详细; 估算专家的经验不适合本项目; 具体任务的估计不合理; 针对原因,对估算的结果进行调整,使其趋向合理。 其他说明: 在该场景下,对于项目的总工作量有2个结果或者多个结果,这些结果可以互相印证,以发现估算过程中的不合理之处,是估计更加合理。

常规估算测试工作量的方法(精)

常规估算测试工作量的方法 作为一个管理者,你是否被询问到某个项目要花多少时间,多少人力测试;或是作为一个普通的测试员,你是否被询问到要花多少时间来完成某个任务或是一次回归测试?我想大多数在软件行业的人或多或少都会碰到这样的关于工作量估计的询问。那么你是怎么回答的呢?你对你自己的回答有信心吗?你是否最终发现实际上花去的时间和原本估计的时间大相径庭呢? 不同的人会使用许多不同的方法来估算及安排他们的测试工作量。不同的组织根据项目的类型,项目的内在风险,涉及的技术等而使用不同的方法。但是大多数时候测试工作量是和开发工作量合在一起的,没有一个单独的数字。 首先让我们来看看一些常规的估算测试工作量的方法: 1. Ad-hoc方法 这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者,一直到用完了预算的经费。 这种情况普遍存在于非常不成熟的组织,并且时常有100%的错误差数。 2.开发时间的百分比法Percentage of development time. 这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先,开发工作量使用例如LOC或FP方法被估算出来,然后使用一些探索性的方法来限制测试的工作量。这种方法变化比较大而且通常基于以前的经验。 通常预留项目的总花费时间的35%给测试。5-7%给组件和集成测试,18-20%给系统测试,10%给接收测试(或回归测试等) 3.类比法(经验值法或历史数据法) 根据以前或相似项目(主要在项目性质,领域,规模上有相似)所积累的经验或历史数据来估算工作量。类比法估计结果的精确度取决于历史项目数据的完整性和准确度,因此,用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制,对历史项目的数据分析是可信赖的。需要收集以下相关的历史数据:在设计和实现阶段花费的时间?测试工作的规模,例如用户需求的数量,页面数,功能点。 4.WBS(work breakdown structure)估算法 将项目或产品分解为具体的工作,然后分别对各个工作进行时间估算,最终求和得出项目或产品的测试工作量/时间。

企业如何进行岗位工作量调查

企业如何进行岗位工作量调查 岗位工作量调查,也称为岗位工作饱满度测试,是企业领导和人力资源管理部门了解在岗员工工作状况的主要手段,也是企业进行定岗定编的重要依据。但很多企业在开展这项工作时感觉非常棘手,往往半途而废。归纳起来,主要有以下几方面的原因: 一是缺乏科学有效的操作方法,导致调查结果形式各异,无法比较: 二是缺乏明确的衡量标准,对调查结果不能进行有效判别: 三是受制于本单位人员能力素质和管理制度,调查结果不能反映岗位真实情况。 笔者根据多年的咨询管理经验,总结出一套容易操作的岗位工作量调查方法,能够较好地应对以上问题。这套方法首先是从工作分析入手,明确岗位的具体工作职责,并将职责细化为日常的工作步骤,然后对这些工作步骤的完成时间进行统计,与预先设计好的岗位工作判定标准进行对比,结合岗位任职人员的能力素质,对各岗位的工作量进行评估判断,最后根据本单位实际情况和未来经营目标,对岗位设置合理性进行评判,提出相关岗位职责调整方案以及岗位编制建议。本文重点讨论岗位工作职责明晰以后如何进行岗位工作量调查。 岗位工作量化判定标准 岗位工作量化判定标准是根据岗位工作量、岗位工作结构和岗位工作强度来确定相应标准,以此作为判断岗位设置是否充分以及岗位是否需要调整的依据。岗位工作量化判定标准如下: 1、岗位工作量标准工作量百分比法:工作量饱满度=岗位有效工作时间/平均正常工作时间×100% 统计工作时间一般以日、周、月或年为单位,如岗位年实际工作饱满度=岗位年实际工作日/年有效工作日×100%。一般饱满度达到70%以上时,说明岗位工作量饱满。 岗位工作量饱满度判别标准如下 很饱满:90%以上; 饱满:70%-90%: 基本饱满:50%-70%, 不饱满:50%以下。 2、岗位工作结构标准 按照日常性、阶段性和临时性工作划分,日常性工作是指依据现有组织目标和职能展开的工作,日常性工作量/总工作量×100%,比值在50%以上,说明岗位设置依据充分,一般日常性工作应占总工作量的60%以上。如果日常性工作低于50%,说明岗位工作量不稳定,会出现时而饱满,时而不饱满的情况。 3、岗位工作强度分布标准 如果岗位工作量在一段时间内的总量正常,但主要集中某段时间,造成这段时间工作量出现了波峰(一天工作量达到10小时以上),而其余时间出现了波谷(一天的工作量不足4小时):或者持续每天工作时间在10小时以上,且这样的工作日占全年有效日的30%以上,应认为工作强度分布不均。 进行岗位工作量调查 一般来说,每个岗位的工作可以划分为日常性:工作、阶段性:工作和临时性工作。日常性工作指每天重复做的工作,阶段性工作指每周/月/季/年做的工作,临时性工作指上级单位/领导或相关部门临时安排或突发性的工作。根据岗位工作职责,填写工作调查问卷,将岗位职责细化为日常的工作步骤,对每一工作步骤进行现场观察并统计完成每一步工作所耗费的时间,对照岗位工作量化判定标准,对岗位工作饱满度进行初步判断。以某公司产品调运计划岗为例,如表1所示。

软件工作量评估报告

XXXX软件成本评估 1. 概述 我们认真地阅读了软件的用户指南,与XXXX电脑部有关技术人员进行了深入的交流,并查看了软件的操作界面。在此基础上,我们对软件的功能进行了归纳和整理,并根据以往的经验对每个功能模块所需的编码工作量进行估算,再进一步地以此为依据,推算出整个软件生命期的工作量。 2. 编码工作量估算 本次评估的软件有两个,分别是《X软赠券电脑发放管理系统》和《X软联销资源管理系统》。为了更准确的估算出软件的工作量,我们对每一个软件功能模块所需工作量给出了三个估计值,分别是:1)悲观工作量(Epi):这是一个最保守的估计,可能在编程人员技术不熟练,对业务理解不够,或有其他影响其正常工作的因素存在的情况上发生。 2)正常工作量(Eni):这是一个正常的程序员可能付出的工作量估计。 3)乐观工作量(Esi):这种情况可能在程序员技术相当熟练,对业务相当了解,且以前可能有类似项目开发经验的情况下所需的工作量。

针对每一项功能模块,其最终的工作量估算值按以下公式计算:Ei = (Epi + 4 × Eni + Esi)/ 6 下面的表1是对X软赠券电脑发放管理系统的编码阶段的工作量估算,表2是对X软联销资源管理系统的编码阶段的工作量估算。 表1:X软赠券电脑发放管理系统的编码阶段工作量清单 表2:X软联销资源管理系统的编码阶段工作量清单

上述两个软件的编码阶段的工作量合计为: Ec = Ec1 + Ec2 = 151.67 + 1631.67 = 1783.34(人.小时) 3. 软件生命期工作量估算 为便于估算,我们假定《X软赠券电脑发放管理系统》和《X软联销资源管理系统》均按照瀑布模型开发。 瀑布模型将整个软件生命期划分为计划与需求、产品设计、详细设计、编码与单元测试、集成与测试、移交等六个阶段,各阶段所占工作量如表3所示。 表3:瀑布模型阶段分布百分比 根据上表,编码与单元测试阶段仅占全部工作量的24%,因此《X

工作量考核方案范文

工作量考核方案范文 工 作 量 考 核 方 案 (拟定稿) 说明: 一.本方案包括考核制度和考核量表两部分. 二.考核量表主要是测评教务处学生助理员的绩效同时作为教 务处学生助理工作组工资发放的参考依据 三.附考核流程图如下: 四、本制度每学期期末考试周前接受所有老师和教助意见并及时完 善制度完善并施行前应专门召开集体会议公开解释制度具体细节的构建理由和含义最终解释权归教务处学生助理工作量评估小组 五、本制度提交华中师范大学教务处学生助理工作组备案 教务处学生助理考核制度 第一章

第一条总则考核的目的是通过客观评价教务助理的工作能力、态度优化教务 处助理队伍并客观合理地安置教务助理做到人岗匹配并以考 核结果为参考发放教助的年终薪酬 第二条本规定中使用的专业术语定义如下: (一)能力考核通过工作行为观察、分析、评价教助具有的工作能力 (二)态度考核通过对教助的工作努力情况和工作热情进行观察和评 价 (三)业绩考核对教助分担的工作完成情况进行观察、分析和评价 (四)360度考核法即全视角绩效考核法通过不同的考核者(老师、同学、 其他教助等)从不同的角度来全方位考核教助工作情况 (五)KPI法即关键业绩指标选取一些关键的、与教助队伍目标实 现关系比较紧密的工作内容作为考核项目 (六)考核者老师、同学以及其他教助 (七)被考核者XX-xx学年度教务助理 (八)考核执行者教务助理工作组 第三条考核原则 (一)考核标准尽可能量化;

(二)考核标准的制定以教助管理条例为依据按照教务处的标准制 定 第四条每位教务助理一学期工资标准在400元左右浮动教务助理 最后所 得工资根据考评结果而定 第五条考核方法是360度考核法,由教务助理所在办公室老师,其 他办公室 教助(即同事)共同参与实行打分制考核表由教务助理所在办公 室老师填写同时参考其他办公室教助(即同事)意见运用KPI法确定绩效考核标准 第二章考核流程与实施 第一条教务助理工作组开会讨论确定最终考核制度; 第二条由教助工作量评估小组整理制度材料交给教务助理工作组 审核 最后上交教务助理管理老师审批; 第三条制度执行由各办公室老师对本办公室教助进行考核; 第四条由教助工作量评估小组进行汇总按分数列出等级确定薪酬; 第五条召开全体教务助理大会宣布考核结果评定小组接受质询; 第六条合格者由教务处发放工资 第三章薪酬的确定方法 P1:所在办公室老师打分的平均分; P2:教务助理工作组打分的平均分;

工作量的评估方法

羀工作量的评估方法 肄1.软件开发价格估算方法 袅软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便 于计算,给出一个计算公式: 膂软件开发价格=开发工作量×开发费用/人·月 螇1.1开发工作量 莇软件开发工作量与估算工作量经验值、风险系数和复用系数等项有关: 芄软件开发工作量=估算工作量经验值×风险系数×复用系数 羂1.1.1估算工作量经验值(以A来表示) 螈软什开发工作量的计算,曾有人提出以源代码行或功能点来计算,这些方法 实施起来均有不少难度。目前国际上仍旧按以往经验的方式加以计算,国内各软件企业也是采用经验的方式加以估算工作量。 蒅为了更好地规范估算方法,建议可按照国家标准“GB/T8566-2001软件生存周期过程”所规定的软件开发过程的各项活动来计算工作量。 蚄工作量的计算是按一个开发工作人员在一个月内(日历中的月,即包括国家 规定的节假日)能完成的工作量为单位,也就是通常所讲的“人·月”。 蚃特别要提醒的是软件开发过程中既包括了通常所讲的软件开发,也应包括各 类软件测试的活动。 袀1.1.2风险系数(以σ来表示) 袇估算工作量经验值亦会存在较大风险,造成软件危机的因素很多,这也是一 个方面的因素。特别当软件企业对该信息工程项目的业务领域不熟悉或不太熟 悉,而且用户又无法或不能完整明白地表达他们的真实的需求,从而造成软件企业需要不断地完善需求获取,修改设计等各项工作。因此: 肃l≤风险系数≤1.5 蒃根据我们对软件企业的了解,超过估算工作量经验值的一半,已是不可接受,所以我们确定“1.5”为极限值。当然这既要看企业的能力,也要看用户能接受 的程度。

软件开发实施项目工作量评估明细表

项目工作量统计表 项目名称:推进OA系统应用,强化业务整合 一、推进OA流程应用工作量 序号阶段工作内容人员 配备 人·日 1 项目准备现有系统配置情况检查 系统相关模块的基本数据情况检查 制定实施阶段计划,约定每个阶段的时长,准 确划分各阶段时间节点 预定培训实施期间培训日期安排 3 9 2 系统配置建立相关组织结构 建立相关角色 调整全局配置项 建立权限分配方案 2 12 3 流程调研落实需要上线的流程列表,这些流程主要包 括:党委发文流程、纪委发文流程、公司发文 流程、部门发文流程(报告、函、请示、通知)、 公司收文流程,以及:用印申请流程、出差申 请流程、会议管理流程等 培训流程图的标准画法 收集流程图,交流流程信息、修改流程图、流 程图定稿 4 36 4 设定流程建立流程,谁提交,谁批准,谁执行 建立流程表单,及相应说明 建立流程处理签 建立存档管理,配置相关归档目录 建立权限管理 5 85 5 模拟调试对所有流程进行模拟测试,特别是各个重要公 文流程,必须进行遍历测试 根据模拟测试发现的情况,对流程设置进行检 讨和调整 4 72 6 管理员培训对流程管理员进行培训,使其掌握流程异常情 况处理、流程微调技巧 2 8 7 用户培训根据项目实际整理培训资料 落实培训人员、场地、时间安排 三场用户培训,需用户积极配合协调 2 8 8 系统启用建立起与系统运行相适应的管理规章制度 发布正式启用系统的通知 系统检查与实施补充 问题收集、反馈、调整 2 12 9 项目收尾项目回顾 权限收回 2 2 合计244

二、新功能开发工作量 序号阶段工作内容人员 配备 人·日 1 需求调研、分析了解用户业务,获取用户对功能、性能等方面 的需求 4 20 2 需求确认用户方、开发方对需求进行审核确认 这些功能包括:安全认证、电子印章、规章制 度管理、业务整合 2 10 3 总体设计系统初步设计 2 10 4 总体设计评审用户方、开发方对总体设计审核确认 2 2 5 详细设计对系统功能、操作界面、处理逻辑、数据库、 代码体系等进行详细设计 2 20 6 详细设计评审开发组对详细设计方案审核确认 1 3 7 编程、单元测试编写程序、单元测试 系统管理(设置,备份还原) 操作人员管理及权限管理 2 24 安全认证 2 70 电子印章 2 64 规章制度管理 3 81 业务整合(初步) 2 20 业务整合(深入) 4 120 8 集成测试系统集成测试、系统测试,编程与测试可以交 叉进行 4 24 9 安装调试到用户现场安装调试开发好的系统,并与用户 一起试走业务流程,对系统进行功能确认测试 3 21 10 系统初始化将系统初始化;准备业务基础数据并录入系 统; 2 12 11 用户培训对用户操作人员、系统管理人员进行详细培训 1 4 12 项目跟踪与总 结 系统bug控制,操作指导 2 12 合计517 工作量总计:761人·日

常用的工作量评估方法

常用的工作量评估方法在测试项目管理中或编写测试计划时,经常需要对某个测试工作进行工作量的预算,很多时候都是凭个人的工作经验进行估算的,如能结合一些常规的估算方法,有助于估算的精确度。 以下是网上找到的一些常规的估算测试工作量的方法: 1、Ad-hoc方法 这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者,一直到用完了预算的经费。这种情况普遍存在于非常不成熟的组织,并且时常有100%的错误差数。 2、开发时间的百分比法Percentage of development time。 这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先,开发工作量使用例如LOC或FP方法被估算出来,然后使用一些探索性的方法来限制测试的工作量。这种方法变化比较大而且通常基于以前的经验。 通常预留项目的总花费时间的35%给测试。?5-7%给组件和集成测试?18-20%给系统测试?10%给接收测试(或回归测试等) 3、类比法(经验值法或历史数据法) 根据以前或相似项目(主要在项目性质,领域,规模上有相似)所积累的经验或历史数据来估算工作量。类比法估计结果的精确度取决于历史项目数据的完整性和准确度,因此,用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制,对历史项目的数据分析是可信赖的。需要收集以下相关的历史数据:?在设计和实现阶段花费的时间?测试工作的规模,例如用户

需求的数量,页面数,功能点?数据样式,例如实体,字段的数量?屏幕或字段数量?测试对象的规模,例如KLOC 4、WBS(work breakdown structure)估算法 将项目或产品分解为具体的工作,然后分别对各个工作进行时间估算,最终求和得出项目或产品的测试工作量/时间。 5、Delphi法 Delphi法是最流行的专家评估技术,在没有历史数据的情况下,这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术,要求有多种相关经验人的参与,互相说服对方…… Delphi法的步骤是:1、协调人向各专家提供项目规格和估计表格;2、协调人召集小组会各专家讨论与规模相关的因素;3、各专家匿名填写迭代表格; 4、协调人整理出一个估计总结,以迭代表的形式返回专家; 5、协调人召集小组会,讨论较大的估计差异; 6、专家复查估计总结并在迭代表上提交另一个匿名估计; 7、重复4-6,直到达到一个最低和最高估计的一致。 6、PERT估计法 PERT对各个项目活动的完成时间按三种不同情况估计:一个产品的期望规模,一个最低可能估计,一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计。Pert 估计可得到代码行的期望值E,和标准偏差SD 1.软件开发价格估算方法 软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便于计算,给出一个计算公式:

员工工作量的评估和管理

POLICY NO: 5.6.17 EV ALUATION AND MANAGEMENT OF STAFF WORKLOAD OBJECTIVE To ensure that all employees has access and opportunity to liaise with management in relation to their workload if they perceive it to be excessive. POLICY STATEMENT The Town acknowledges that excessive workload, whether real or perceived can be a contributing factor in stress related psychological illness. Date Adopted: 21 December 2004 Date Amended: - Date Reviewed: - Date of Next Review: December 2009

GUIDELINES AND POLICY PROCEDURES FOR EVALUATION AND MANAGEMENT OF EMPLOYEE WORK LOAD – POLICY NO 5.6.17 The Town is committed to affording all employees the opportunity for review of workload on request and will take appropriate action should intervention be required. Employees are encouraged to discuss workload issues with their line management, but if they are unable to resolve the issues, a formal process will be undertaken. This action can be initiated by any employee providing they are willing to fully participate in the workload evaluation and subsequent processes. Those unable to participate in the process for any reason, must submit a written outline of issues pertaining to workload and reasons why they perceive the load excessive. They may also nominate a peer to represent their interests. Employees may also raise workload issues with their supervisor or Executive Manager, the Occupational Safety and Health representative, or directly with the CEO if they feel unable to address the issue with the above channels. The Town's Managers and Supervisors will ensure that those who seek workload evaluation will not be victimised or compromised in any way by their actions. The workload reviews will be supervised by the Manager Human Resources and the results and actions required will be forwarded to the CEO for ratification. Action will be taken against any level of management who is found to be discouraging or preventing employees from accessing an independent workload review. As a matter of course, all employee duty statements and workloads will be reviewed annually as part of the performance appraisal process. Workload Evaluation Process A review of the Job Purpose, Duties, Key Performance Indicators (KPIs) and Performance Measures will be carried out by a manager or supervisor from a different division, section or team as deemed appropriate and approved by the CEO. The employee will keep a work diary for two weeks (or longer if deemed appropriate) relating to tasks carried out, phone calls, meetings and customers interfaces. This will be evaluated against the job purpose, KPIs and Duty statements. An audit of the skills and training required to undertake the identified tasks and actions will be carried out at this stage, including interpersonal skills in dealing with customers and peers.

相关文档
最新文档