软件项目度量.docx
- 文档编号:12453320
- 上传时间:2023-04-19
- 格式:DOCX
- 页数:20
- 大小:30.66KB
软件项目度量.docx
《软件项目度量.docx》由会员分享,可在线阅读,更多相关《软件项目度量.docx(20页珍藏版)》请在冰豆网上搜索。
软件项目度量
软件项目度量
3、项目过程的度量
项目过程的度量主要包括进度度量和工作量度量。
(1)进度度量
进度度量主要关注项目执行过程中,项目的实际进度与项目计划的偏差情况,进度度量的主要目的是客户反映项目的真实进展情况,并不剖析进展偏差的原因,对于负责多个项目管理的公司高级主管来说,及时客观掌握项目的真实进度是至关重要的。
进度度量需要项目经理在制定计划的过程中对WBS做认真分析,不仅仅要清晰定义每项任务的工期、投入的资源以及预计的起止时间。
然而目前许多项目计划还远没有达到对每项任务做认真分析的程度,例如,滚动任务计划需要及时计算关键路径,对于非关键路径上的任务实际上起止时间包括两组,分别是最早开始时间和最早结束时间、最晚开始时间和最晚结束时间。
在最早开始时间和最晚开始时间之间的这一段称为"浮动时间",浮动时间对于资源平衡非常重要。
假定上图中每个方框表示一项任务,红色框表示关键路径上的任务,黄色框表示非关键路径上的任务。
那么对于任务F、G、H来说,应该有浮动时间,在浮动时间内完成的任务属于计划内完成的任务。
目前许多项目计划中仅列出"开始时间"、"结束时间",但并没有清晰说明这两个时间的约束性条件,对于进度跟踪和资源平衡非常不利。
对每一项任务的预计开始时间、预计结束时间,以及对实际开始时间、实际结束时间的记录就如同需求度量中的需求变更记录表一样,属于原始细节级的数据,其本身虽然产生度量指标(单项任务的进度偏差),但这些指标只有按照某种规则进行统计汇总之后才具备反映项目总体紧张的能力。
例如很多项目采用里程碑分析方法,对进度偏差进行分析,如下表对某个项目的各个主要阶段的进度偏差进行了统计:
阶段
开始日期(YYYY-MM-DD)
完成日期(YYYY-MM-DD)
工期(天)
工期偏离率%
时间平滑率%
计划
实际
计划
实际
计划
实际
项目计划
2002-1-2
2002-1-20
2002-3-4
2002-3-24
62
64
3.23
32.26
需求分析
2002-4-5
2002-4-5
2002-5-7
2002-5-11
32
36
12.50
12.50
概要设计
2002-5-6
2002-5-9
2002-6-8
2002-6-20
32
41
28.13
37.50
详细设计
2002-6-7
2002-7-7
2002-8-9
2002-8-24
62
47
-24.19
24.19
编码
2002-6-8
2002-6-9
2002-8-10
2002-8-12
62
63
1.61
3.23
单元测试
2002-7-7
2002-7-9
2002-8-19
2002-8-20
42
41
-2.38
2.38
集成测试
2002-9-10
2002-9-10
2002-9-22
2002-9-22
12
12
0.00
0.00
系统测试
2002-9-23
2002-9-24
2002-10-10
2002-10-11
17
17
0.00
5.88
根据这个表格可以输出用于项目分析的进度图表,基于这样的图表,可以对整个项目执行过程中的进度偏差一目了然,对于具有多个项目的组织来说,将多个项目的进度偏差曲线放在一起进行对比分析,可以得出项目的一般性规律,在项目计划改进时这些知识将具有非常高的实用价值。
(2)工作量度量
工作量度量的主要指标是在项目执行过程中各任务或各类任务,或者各个阶段投入的工作量的跟踪指标,以及与计划相比的偏差指标。
工作量度量同样依赖于项目计划中任务分解结构的详细分析,确定的资源投入和成本预算都是经过认真评估,否则会引起计划的可执行性降低,工作量统计也就失去了科学的依据和基准。
工作量度量还需要项目管理制度中明确项目经理或者其他角色对项目计划的全局执行情况保持高度的关注,以保证每项任务的开始时间和结束时间以及投入的资源、产生的成果都能够被记录在案,只有这样,才可能获得真实、全面的工作量度量数据。
工作量度量的数据统计实际上包括了数据收集过程和数据的统计分析过程。
工作量度量指标按照项目中任务的分类包括以下几类:
项目任务活动分类
项目任务细分
项目管理活动工作量
项目估计
项目计划准备
评审项目计划
更新WBS计划
项目启动
项目周例会
项目里程碑会议
项目度量活动
项目月度会议
项目跟踪
项目总结
配置管理活动工作量
配置管理计划准备
评审配置管理计划
修改配置管理计划
配置库维护
发布配置状态报告
配置审计
质量管理活动工作量
质量保证计划准备
评审质量保证计划
修改质保计划
SQA审计
SQA验证活动
为项目组提供培训
项目组公共活动工作量
培训
学习
项目组外活动
请假(休假)
会议
出差
需求分析活动
需求规格说明书准备
需求规格说明书评审
需求规格说明书修改
概要设计活动
概要设计说明书准备
概要设计说明书评审
概要设计说明书修改
详细设计活动
详细设计说明书准备
详细设计说明书评审
详细设计说明书修改
编码活动
编码
代码走查
代码修改
单元测试活动
单元测试计划与用例准备
单元测试计划与用例评审
单元测试计划与用例修改
单元测试执行
集成测试活动
集成测试计划与用例准备
集成测试计划与用例评审
集成测试计划与用例修改
集成测试执行
系统测试活动
系统测试计划与用例准备
系统测试计划与用例评审
系统测试计划与用例修改
系统测试执行
项目结束活动
产品发布
项目验收
项目结项
需要度量的指标并不多,主要包括以下三个:
A.计划工作量(人时数或人日数):
项目计划中某项活动或某类活动预计发生的工作量
B.实际工作量(人时数或人日数,与计划工作量采用同一单位):
截至某点或项目结束后统计得到的某项活动或某类活动实际发生的工作量
C.工作量偏差:
(实际工作量-计划工作量)/计划工作量×100%
工作量度量的数据可以用作比例分析,获得项目执行过程中各种活动的工作的分配情况,例如某个项目各类活动的工作量统计表如下表所示:
俗话说"没有比较就没有鉴别",利用单个项目中各种活动消耗的工作量比例图可以对项目的工作量分配有个清晰的认识,如果将多个项目进行对比,则可以发现各个项目的差异所在。
同时在同一项目的实施过程中,对关键活动的工作量消耗做横向对比,可以发现"学习曲线"的情况,越晚启动的项目执行的效率应该越高,如果违背了这个规律,则需要对项目进行专门分析,剖析原因所在。
(3)项目进度、工作量和成本综合度量(挣值分析法)
挣值分析是在对范围、进度和成本进行综合测量的基础上评价项目绩效的一种方法。
它涉及每项工作的3个关键值:
计划值(PV)在规定的时间内在工作上将要花费的获得批准的成本估算部分
实际成本(AC)在规定时间内完成工作所花费的实际成本(直接和间接成本的总额)
挣值(EV)实际完成工作的价值
这3个值的综合使用可以提供评价工作绩效好坏的尺度。
最常用的尺度是:
成本偏差(CV)=EV-AC
进度偏差(SV)=EV-PV
CV和SV这两个值,可以转化为效率指示器,反映任何工作项的成本与进度计划绩效。
成本绩效指数(CPI)=EV/AC
进度绩效指数(SPI)=EV/PV
CPI被广泛用于预测完工时的项目成本。
SPI有时与CPI一起被用于预测项目完工估算。
完工估算(完成全部工作所需的成本)的计算公式如下:
EAC=总预算/CPIorEAC=AC-(总预算-EV)/CPI
挣值分析具有将进度、工作量和成本综合起来的特点,并且具有可视化的优点,已经在各行业的项目管理中广泛采用,同样,在软件开发项目中,挣值分析也具有非常高的实用价值。
挣值分析的原理和方法本身并不复杂,本文也不会过多讨论如何实现挣值分析,解释挣值分析几个指标的含义,但需要特殊说明的是使用挣值分析的一些必备条件:
A.在挣值分析中,一项任务的状态只有两种,即"完成"、"未完成",这一假设是挣值管理的重要理论基础,但在实际的软件开发项目中,许多任务分解的情况粒度仍然比较粗,在任务执行过程中需要加入一些检查点,但检查点并不输出最终的成果。
在这种情况下,需要计划制定者以及任务分配者将任务分解到"原子"级别,能够比较方便地判断完成与否的状态,否则使用挣值分析法的数据统计结果会有比较大的延迟,反映的项目实际运行状态至少是不及时的。
B.在挣值分析中,要求每项任务状态标准是客户现实的,标志为完成状态的任务如果在后续发现了错误需要重新返工,则挣值分析曲线上会反映出异常的情况,如果这种返工比较频繁的变化,挣值分析曲线则几乎完全反映不了项目的进度情况,当然,在这种情况下,项目的实际进度确实是难以表述,无法说清的。
因此挣值管理得以运用的另外一个重要前提是项目管理得当,项目在进度控制之下进行,也就是说项目管理手段保证了项目任务在沿着计划的大方向在前进。
C.在高度不确定的项目中,例如预研性质的项目,因面临大量的技术难题,或者创新性的任务,这些任务的特点是无法预先估计解决问题的时间,并且一个新的课题中,面临的各种困难很可能互相影响,有可能从进度上看,很长时间处于停滞状态,但突然全部完成。
对于这种项目来说,无论是项目管理制度、方法,还是项目度量方法都应该符合项目的实际特点而作,而一般开发、工程类的项目的项目管理方法和挣值分析法在这类项目中都不适用。
因此,挣值分析法并不是包治百病的灵丹妙药,在实际应用时需要根据项目特点进行选择。
4、项目成本的度量
项目成本包含的因素众多,并不是仅计算项目自身的财务消耗情况就能够全面概括出来的,但财务消耗(预算使用情况)无疑是成本度量的重要指标。
对于不同的项目来说,项目成本的构成要素也有所不同,下面列举两种典型的情况:
(1)产品化开发的软件项目
产品开发项目的特点是开发团队集中,大多采用项目型的组织结构进行管理,项目组成员职责清晰,项目经理对项目组成员的工作有统一的监管,在这种情况下,项目成本比较适合以项目为单位进行成本度量。
产品化开发(项目型组织结构)的项目成本度量主要指标包括:
A.项目成员工资:
在软件开发企业中,项目成本主要体现在人员工资上,在项目型的结构中,项目组成员的工资成本应作为项目成本进行统计;
B.开发环境建设成本:
进行产品开发需要为开发人员配置开发用的设备,根据项目的不同,这项成本可能有很大的差异,但一般情况下开发环境建设成本应该包括开发人员使用的电脑硬件和基本软件费用、开发用服务器的硬件和软件费用、网络设备费用、项目管理软件工具费用等;
C.培训费用:
为提高开发人员的技能,不论大型项目还是小型项目,均有可能需要对开发人员进行相应的技能培训,这种培训不仅包括对开发工具本身的培训,还可能包括对业务领域知识的培训、对项目管理规范的培训等。
这些费用中除包括培训消耗的开发成员的工作量产生的成本之外,还包括聘请培训教师费用、购置培训教材的费用,以及培训场地等培训组织费用。
D.公用费用:
公用费用并没有明确的界限确定要包含哪些科目,但在一个中型或大型项目中,公用费用一般会包括项目团队在项目执行之外的活动组织费用,以及用于与最终用户沟通的费用,以及因调研或其他活动产生的差旅费用等。
需要说明的是,如果大多数项目度量指标一样,成本度量的指标粒度越细越好,对指标的分类越细致,成本分析和成本控制越具有针对性。
在项目型组织结构管理之下的产品化开发项目的成本度量指标表举例如下:
编号
成本类别
成本科目
备注
1
人员工资
1.1
开发人员工资
隶属项目组织的项目成员工资
1.2
项目管理者工资
隶属项目组织的项目管理者工资
1.3
外聘专家&其他人员报酬
与项目开发相关,但不属于项目组织成员的其他人员的报酬
2
开发环境建设成本
2.1
开发人员用硬件设备成本
2.2
开发人员用系统软件
包括Windows等与硬件配套的操作系统软件
2.3
开发人员用的办公软件
包括Office等需要付费购买的软件
2.4
开发人员用开发工具软件
不同的项目会有不同的工具软件,类似VisualStudio、BorlandC++Builder等,以及Case工具
2.5
开发环境公用的服务器硬件
包括服务器主机和存储设备等
2.6
开发环境服务器系统软件
类似Windows2000Server类的服务器操作系统软件
2.7
开发环境服务器应用软件
类似数据库服务器软件、J2EEApplicationServer等
3
培训成本
3.1
培训资料费用
包括为学员购买的培训资料、参考书籍和软硬件等
3.2
培训教师报酬
如果外聘培训教师,则需要列入培训成本中
3.3
培训组织费用
包括培训场地租金,向培训组织者支付的服务性费用等
4
公用成本
4.1
项目活动组织费用
为增强项目团队成员间的非正式沟通和交流而组织的开发外活动发生的费用
4.2
与客户沟通费用
包括通信费用、产生的差旅费用以及商务招待费用、礼品等
4.3
加班费用
加班支付的报酬、额外的交通通信补贴等费用均属此列
(2)工程类项目(采用矩阵结构进行项目管理)
目前有非常多的项目是依照客户的要求进行定制,例如在中国移动通信公司建设的综合经营分析系统是一个数据仓库项目,中国移动总部制定基本框架性的业务规范,但各省分公司按照各自的个性化需求独立进行招标,在这种情况下,承担中国移动多个省分经营分析系统建设的软件开发商面对的多个项目具有相当的共性,同时又有所不同。
在这个例子中,软件开发商承担的多个项目中因具有较强的共性,开发过程中为了复用开发成果和开发人员,采用矩阵式的项目管理看来是顺理成章;同时因各个项目的需求又有所差异,因此软件开发商开发出来的系统产品化程度还不是非常高,因此还需要进行本地化开发,本地化开发一般需要在客户现场进行。
这种开发模式显然比集中式的产品开发复杂程度要高,不但项目管理的复杂性提高,项目成本的度量体系也较产品开发更加复杂,这时项目成员不再专属某个项目,成员工资也不单独由项目组控制,如果仍要以项目为成本核算单位,同时由不与职能部门自身的成本核算体系发生冲突,则需要对成本度量体系进行专门的设计。
在矩阵型管理结构中,如果要对项目成本进行度量,一个重要的前提条件是在任务分派的时候能够清楚明确地说明该项任务属于哪个项目,这样才能将职能部门成员产生的工作量计入项目成本,按照固定的时间周期(例如每月)对每个职能部门成员在各个项目中的工作量进行统计,并对工资成本进行折算,从而得到项目的人力工资成本数据。
矩阵结构中项目成本度量的另外一个前提条件是建立了工作量统计制度,以及项目成本核算体系,这些制度和体系需要有明确职责的人执行,否则项目经理无法获知职能部门中的项目成员发生的成本情况,职能部门经理不能获知项目其他类型的成本,公司的高层管理者也因不同部门报告的成本体系之间的交叉和疏漏而无法得到项目成本的真实数据。
很多公司都会做工作量在各项目中的分配情况的统计,比较常用的一种统计表格如下:
人员
1
2
3
4
5
6
7
上海
北京
辽宁
安徽
江苏
陕西
山东
四川
核定总计
实际总计
A
5
17
22
B
10
12
22
C
22
22
D
9
6
15
E
22
22
F
2
16
18
G
8
10
18
H
8
1
11
20
I
辽宁
5
7
1
9
22
在这个工作量统计表中,可以看到组织内每个成员在不同项目中投入的工作量,借此可以计算项目的人工成本;如果按月进行累计,则可以看到每个月各个项目投入的总工作量。
在本节示例中的项目情况在很多公司存在,因此也非常具有代表性,在这种项目中,项目度量指标体系也与产品开发型的项目有所不同,说明如下:
A.人工工资成本
前面已经论述过有关矩阵结构中项目人工成本的统计计算方法,核心思想是要对矩阵中每个成员的工作量统计到各个项目中去,用于成本核算。
B.项目差旅费
在现场开发的项目成员产生的差旅费用包括交通费用、差旅补贴费用、住宿费用、以及在现场发生的其他费用。
C.项目公用费用
矩阵结构中的项目公用费用与集中式的产品开发中的项目公用费用有所不同,矩阵结构开发模式中的项目公用费用除项目活动经费、加班费用(现场开发还可能不列支加班费用),在现场还包括公司为出差的项目成员日常生活、办公支出的费用项。
D.有关培训成本和开发环境建设成本,在矩阵结构中一般不列为项目成本,因对员工的技能培训不仅仅单独为某个项目服务;同时开发环境建设也属于多个项目公共使用,这些相关费用可以作为组织整体成本进行计算。
矩阵型项目结构中项目成本的度量体系分解可参考以下表格:
序号
费用分类
费用项
说明
1
人员工资
2
项目差旅费
2.1
差旅交通费
2.2
差旅补贴费用
2.3
住宿费用
2.4
其他费用
3
项目公用费用
3.1
项目活动经费
3.2
加班费用
3.3
现场办公场地或宿舍的公共费用
从上面的表格看上去,虽然矩阵型结构的项目管理和成本度量都更加复杂,但成本度量表却比价简单,但这决不意味着矩阵型结构的成本度量很容易,事实上,由于很多成本跨越了多个项目无法摊分,而将成本项目列入了整个组织的成本。
一般情况下,按照这种度量体系进行的成本核算,职能部门经理可以了解各个项目中的人员工资成本;项目经理可以对项目公用费用和差旅费进行核算;而高层经理则可以通过项目经理和职能经理了解各个项目的综合成本以及整个组织内的公共成本。
(3)企业成本的项目摊分
以上虽然已经细致讨论了项目成本的度量体系,但由于项目自身的复杂性和项目与企业整体组织运营的关系,这些指标还不能完全客观真实地反映项目的全部成本,重要的遗漏就是企业成本的摊分。
以项目为业务主体的公司,几乎所有的利润都由项目产生,但并不是所有的支出都用于项目的开发过程,在公司内还有行政部门、财务部门、人力部门、质量部门、市场销售部门的相关的各种配套部门为项目提供支持,这些部门的运营成本,以及企业运营产生的场地租金、水电、办公、营销等费用如果都摊分到项目中去,才算彻底的以项目为企业成本度量体系,在项目预算中才能更加客观地衡量项目支出与预期收入的比例关系,项目预算也才能与企业盈利目标结合起来。
但现实的情况这些摊分的成本指标很少能够进入项目的度量体系中,一方面是因为这些摊分的计算方法本身比较复杂,按照怎样的标准在项目中摊分缺乏科学统一的方法;另一方面这些数据并不在项目经理或职能经理甚至高层主管的控制之下,这些数据可以统一从财务部门进行统计,但鉴于企业的实际运作情况,并不一定将具体的科目和成本数据向其他部门公开。
尽管成本摊分有一定的困难,但还是有一些简单的方法可以纠正项目成本度量体系中存在的这种不足,常用的方法是根据企业总成本(扣除上述方法得到的项目成本之外)按照企业员工数量进行均分,再折算到项目消耗的工时上,即可以对项目成本数据进行初步纠正,使之更加符合实际情况。
计算公式如下:
摊分成本=(单位时间内企业总成本(扣除已计算的项目成本)/企业员工总数)×项目人数×项目历时
5、项目质量的度量
项目质量度量是项目中最常用的度量,这一方面是因为软件质量更加容易被人们所重视;另一方面是因为软件质量度量有很多成熟的方法和工具,在很多公司被普遍使用。
就软件质量度量的重要性来说,虽然质量很重要,但对于项目来说,质量只不过是项目三角形的一个边,因此本文中讨论的项目度量体系中同时讨论进度度量、成本度量和质量度量。
对软件质量的度量标准采用Bug数量作为度量指标的比较多,甚至有很多组织用Bug数量作为质量度量的唯一指标,但这显然是有失科学性的,在现代软件开发项目管理中对质量的定义更加宽泛,已经不再是"bug数"这么简单了。
在国家标准《信息技术软件产品评价质量特性及其使用指南》中对质量的定义如下:
软件质量softwarequality
与软件产品满足明确或隐含需求的能力有关的特征和特性的总和。
这个标准符合业界对软件质量的普遍理解,符合用户需求的软件才能被视为高质量的软件。
从侧面讲,用户满意度高的软件才是高质量的软件,因此客户满意度指标也可以作为软件质量度量体系中的一个参考指标。
对于软件质量的理解目前主要有三种观点,也可以看作对同一问题的三个角度的说法:
1)用户观点
GB/T6583-92中的质量定义反映了用户观点,本标准的特性定义也反映了此观点。
用户主要感兴趣的是使用软件、软件的性能和使用软件的效果。
用户评价软件,对软件内部的各方面或软件是如何开发的情况一无所知。
用户的问题会包括:
--软件是否具有所需求的功能?
--软件的可靠程度如何?
--软件的效率如何?
--软件使用是否方便?
--该软件转移到另一环境是否容易?
2)开发者观点
由于软件质量特性对需求和验收均适用,故开发过程要求用户和开发者使用同样的软件质量特性。
在开发现行软件时,隐含的需求必须反映在质量需求中。
由于开发者负责生产满足质量需求的软件,放他们对中间产品质量以及最终产品质量都感兴趣。
为了在各个开发阶段评价中间产品质量,开发者不得不对同样的特性使用不同的度量。
因同一度量不适用于生存周期的所有阶段。
例如考虑效率时,用户用响应时间,而开发者在设计规格说明中则必须用路径长度、存取时间和等待时间。
一般而言,适用于产品外部接口的度量被那些适用于它的结为的度量达所取代。
开发者的观点还必须体现维护软件者需要的质量特性观点。
3)管理者观点
管理者也许更注重总的质量而不是某一特性,为此须根据商务需求对各个特性赋于权值。
管理者还需要从管理的准则.诸如进度拖延或成本超支。
与质量的提高之间进行权衡。
因为他希望以有限的成本、人力和时间使质量达到优化。
鉴于软件质量度量标准的复杂性,本文讨论的软件质量度量并不重点关注如何发现Bug,并统计Bug,以及跟踪Bug数量的变化等内容,这些内容虽然属于质量范畴,但更多地属于软件测试(Test)的范畴,与质量度量这个主题从内容含义上还是有所区别的。
下面列举某软件公司ISO体系文件中对开发部门提出的质量目标:
1.软件产品发
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 项目 度量