软件项目规模度量与实际应用

一. 软件规模度量的必要性

软件项目规模的度量,是软件项目中相当重要的一环.

只有相对合理和相对准确地度量软件规模,才能对项目的计划进度安排,资源分配,等等各个环节进行合理的部署.这样才能尽可能地保证软件项目的进度和质量.

原因是:

1. 软件项目与其它项目,例如建筑工程项目,汽车制造项目等,都有可以通过加大资源投入而获得更大生产力的特点.比如增加一条汽车生产线,生产能力能马上提高一倍.(当然其中仍包括一些工业生产线上的一些如何最大化流水线的技巧理论问题,但从总体上来说,软件生产不具备这样的特点),当加大软件开发资源的时候,如果管理不善,会出现生产力下降的情况.尽管其它的工业生产也可能发生这样的情况,但软件生产发生的概率要大很多.

2. 有90%的软件项目难以预测,只有10%的软件项目能在够在预定的费用和进度下交付.从这个角度看,能否准确地度量软件的规模,成为软件项目成功的重要矛盾点.

3. 软件项目规模的相对准确度量,能为项目计划,为项目的甲乙双方的资源分配调动提供有力的招引,尽管软件项目的度量是不可能完全精确的.有目的性地进行度量,能让项目组对软件开发的整个过程中出现的各种问题和风险有预先的估计,避免盲目从而能在实际上有效的提高软件项目的生产水平.

二.软件项目规模度量的相关方法及其局限

比较流行的软件规模度量的方法是代码行(LOC)和功能点(FP)两种

l 代码行度量的方法

代码行度量的方法,是通过各种手段,统计出软件项目的代码行.从而按代码行的数量为单位度量出软件的规模.

一般使用代码行度量自动化工具来进行度量,要度量的文件类型包括软件项目中交付用户使用的各种文件. 一般来说,如果项目的配置管理是使用CVS的话,可以使用StatCVS进行代码行度量.

LOC方法的优点是:

1. 度量工作容易进行,而且自动化度量工具非常多,即使自行开发难度也不高

2. 代码行数是比较公认的软件规模的标准,容易在项目的甲乙双方中取得共识.

规模度量的方法缺点是非常明显的.

1. 很难在项目分析论证和计划阶段就对软件的规模进行相对准确的度量. 即使进行度量

2. 即使进行度量,也必须依靠于评估人员的经验所得.虽然只要评估人员经验足够,可以获得比较准确的度量结果,但是这对评估人员的能力要求比较强,并而且难以由第三方对评估人员的工作偏差作出修正.

3. 不同软件项目使用的技术不一样,这一点,非常影响到软件规模的度量.例如同一个功能,使用JAVA语言和使用Ruby语言所涉及的代码行相差数十行,甚至数百行. 即使同为JAVA语言,使用不用的框架所需要编写的代码行也不一样.

总体来说,LOC方法很适合软件业初期,使用比较简单的程序开发语言的项目进行规模度量,但是随着软件工业的发展,LOC方法进行度量的难度越来越大,而准确和可操性在逐渐降低.L

l 功能点(FP)度量的方法

功能点法是一种面向功能的软件度量方法。一般来说，功能点法的计算根据软件需求规格说明书进行计算，在计算过程中需要充分利用DFD、E-R或UseOase图等提供的信息。

面向功能的软件度量是对软件和软件开发过程的间接度量。面向功能度量的关注点在于程序的“功能性”和“实用性”，而不是对LOC计数。一种典型的生产率度量法叫做功能点度量，该方法利用软件信息域中的一些计数度量和软件复杂性估计的经验关系式而导出功能点FPs（Function Points）。

功能点通过。首先确定五个信息域的特征，并在表格中相应位置给出计数。信息域的值以如下方式定义：

用户输入数：各个用户输入是面向不同应用的输入数据，对它们都要进行计数。输入数据应有别于查询数据，它们应分别计数。

用户输出数：各个用户输出是为用户提供的面向应用的输出信息，它们均应计数。这里的输出是指报告，屏幕信息，错误信息等，在报告中的各数据项不应再分别计数。

用户查询数：查询是一种联机输入，它导致软件以联机输出的方式生成某种即时的响应。每一个不同的查询都要计数。

文件数：每一个逻辑主文件都应计数。这里的逻辑主文件，是指逻辑上的一组数据，它们可以是一个大的数据库的一部分，也可以是一个单独的文件.

外部接口数：对所有被用来将信息传送到另一个系统中的机器可读写的接口(即磁带或磁盘上的数据文件)均应计数。

通过对上面几个重要信息域的收集,可能定义出软件项目的功能点的数量,再使用如下的关系式：

FP ＝总计数×〔0.65＋0.01×SUM（Fi）〕

(其中，总计数是由表2所得到的所有加权计数项的和；Fi（i = 1到14）是复杂性校正值，它们应通过逐一回答表2所提问题来确定。SUM（Fi）是求和函数。上述等式中的常数和应用于信息域计数的加权因数可经验地确定。Fi是对影响产品规模的14个因素进行分析确定的“复杂度调整值”，取值范围是0-5)

就可以计算出FP的数量

FP方法的优点

放弃了依赖于技术细节的LOC方法简单线性标准,通过功能点来进行估计,这样一来甲方对发包产品的成本估算、乙方对自身开发成本的预测提供了便利, 比如，A软件项目的规模是100功能点，我们根据行业基准（Benchmarking）知道平均成本是5000元/功能点，那么本项目的成本预测就是50万元；我们又根据行业基准知道平均生产率为1功能点/人天，则计算得到项目需要投入100个人天的工作量，这些计算的结果将成为签定合同的依据和软件项目管理的基础

其缺点,仍然是没有考虑到不同的开发项目团队和开发条件下的不同状况,只是从一些平均普遍的方法上去进行度量,因为和实际项目的差距,造成了这种方法的缺陷.

三.软件规模度量的目标的再次明确

软件规模度量的目标,是为了在项目初期能对软件项目的整个过程进行估计,预先制定好比较合理的软件项目管理计划,制定合理的软件项目的风险处理机制,最终保证软件项目的顺利完成.

脱离了这个目标,笔者认为,再好的软件度量方法也是没有意义的.因为软件开发的过程,受到影响的因素太多,包括开发人员的熟练程序,水平,配置管理环境的完善与否,所使用的技术和设计方案合理与否,测试机制合理与否,都有关系.

而这些因素,每个软件项目开发的团队都是不一样的,这些因素本身就难以度量.

传统的功能点和代码行的度量方法.在实际的开发中,往往脱离了对实际项目环境,因此盲目的使用传统的度量方法进行度量工作,往往是白费的.

四.软件项目度量在实际项目中的认识.

l 软件项目度量是软件开发团队的能力和素质,是需要长期培养的生产力.

不同的开发团队,由于其开发软件项目所熟练和精通使用的技术不同,因为软件项目的度量,必须要以这些团队自身特长的技术作为基础,如果使用通用的度量方法,是必然会引起偏差的.

l 不同软件项目的度量,必须要以开发团队的开发历史数据为基础.才能获得更准确的估计结果. 由于每个开发团队使用的技术,开发环境,配置管理环境,等等这些因素,是会极大的影响软件开发的进度的.例如,配置管理,部署发布的自动化程度. 因此

l 软件开发团队的人员稳定,并且改善开发技术,保存项目度量的历史数据,对软件规模的度量有着重要的作用.

五.软件项目度量在实际项目中的手段 :

1.建立软件规模度量的历史数据库(面向团队).这个数据库必须由团队每一个成员共同维护,每个项目的分任务完成后,要将完成的时间,所使用的资源记录在数据库中.特别是要记录任务的使用条件.例如,完成任务一使用的是Hiberante技术,而完成任务二使用的是ibatis技术等.完成任务三使用的是loadrunner工具(测试),完成任务四是使用jmeter工具等.

有了这些数据,就能比较清晰的知道,使用不同工具完成任务的大致时间.

2.在项目计划中,进行任务分解的时候,一定要注意任务的粒度不能太大,一般要求在三天到一周之内.如果任务粒度太大,会增加规模度量的误差.同一个任务,当开发人没的熟练程度改变时, 就能引入误差,而粒度越大,引入的误差也会越大.

同样地. 记录于历史数据库中的任务粒度,也要保持三天到一周的标准

3.软件规模的度量要集合全体团队成员一起进行.团队成员中每人有自己的特长,要因应其特长进行估算,才能获得最大效果.

4.度量的时候,一定要将所有的度量单位,转化为时间人力成本和固定投资成本两种单位,只有这样,才能使软件规模的度量,贴合到甲乙方的生产资源利用的实际情况,才能保证项目的顺利完成.

5.必须要将软件生产中,硬生产内容和软生产内容所占用的时间都计算在度量范围内

硬生产内容,是指软件项目的设计,编码,调试,测试等内容,这些内容生产出来的成品,是可以交付给甲方的.属于最终产品的一部分.

软件生产内容,是指软件开发过程中,乙方硬件配备,开发环境的搭建,配置管理环境的搭建等,开发必不可少,但又不会有成品产生交付给甲方的工作内容.但这些内容,也实际占用了软件开发的时间,因此是必须将其纳入度量范围,才能更准确度量出软件项目的规模.

6.必须每周都要根据项目的实际情况,进行新的度量,如果度量的结果和预计有偏差,应该向要让甲乙双方所有项目参与人员通报,并制定相应的方案.

7.由于缺陷(Bugs)的清除,通常会占项目开发时间30%以上,因此缺陷(Bugs)的度量在整个项目的规模度量中,是占最重要的位置的.许多项目的度量忽视了对缺陷量和程度度量,往往会造成了项目时间和成本度量的巨大偏差.

六.总结

软件规模的度量,能够项目的成本预算估计,可行性分析,项目计划提供坚实的工作基础.建议不同的软件项目,都根据实际的情况,进行尽量准确的规模度量.

规模的度量,一定要将度量的结果,转化为时间人力成本和资源资金成本,才能为项目提供最直接的预测支持.

软件规模度量结果需要在项目过程中不断修正的.

软件规模度量,是软件开发团队要持续改善的能力.

参考资料: 软件产品的规模度量-功能点与代码行 [肖鹏]

《功能点分析方法与实践》李帜等编著清华大学出版社 2005

功能点法在软件项目早期规模估算中的运用 [陈兵]

软件项目规模度量与实际应用相关推荐

软件项目规模估算的3种方法---Loc估算法、FP估算法、PERT估算法
软件项目规模估算的方法 Loc估算法 FP估算法 PERT估算法软件规模是软件工作量的主要影响因素,常用的软件规模度量方法有三种,分别是Loc估算法.FP估算法.PERT估算法. Loc估算法 ...
软件项目规模评估方法之软件源代码行法
软件项目规模的评估方法有很多,我们近期会把这些方法一一进行梳理然后发布出来供大家学习了解.今天我们来说说软件项目规模评估方法中的软件源代码行法. 软件源代码行法(SLOC)是以软件的源代码行数量来计算 ...
软件项目的规模、工作量和成本是如何进行估算的
1. 基于代码行和功能点的估算软件项目的规模是影响软件项目成本和工作量的主要因素.在基于代码行(loc,line of code)和功能点(function point)的估算方法中,利用代码行和功 ...
快速学习COSMIC软件规模度量方法
转载:快速学习COSMIC软件规模度量方法 – 绿盟科技技术博客最近与某运营商开展合作项目时,客户需要我方输出一份COSMIC软件规模度量数据用于评估项目预算,由于此前未接触过COSMIC软件规模度 ...
关于软件项目工作量估算的若干问题
作者:张克强软件项目工作量估算从估算依据上看可以分成如下两类: 1,基于规模估算 2,基于工作量估算基于规模估算的情况下,需要估算软件项目的规模.本文首先来看规模方面的问题. 问题1:如何表达规模 ...
第五章软件项目成本管理
软件项目的成本管理,就是为了确保项目在既定预算内按时.按质.经济.高效地实现项目目标所开展的一种项目管理过程. 项目的成本管理包括成本估算.成本预算和成本控制. 本章内容提要 5.1 软件项目成本管理 ...
软件项目工作量评估方法简述之COSMIC功能点方法
(一) 简介 COSMIC 是通用软件度量国际联盟的简写(Common Software Measurement International Consortium,COSMIC),它成立于1998 年 ...
软件项目量化管理（QPM）及根因分析实践总结（CMMI高成熟度访谈）
1.前言软件项目量化管理是CMMI高成熟度的标志,也是项目管理及软件工程的难点.本人做为项目经理,在CMMI4和5的试点和实施过程中,体会到量化管理是上述高成熟度项目管理的核心.本文重点是量化管理应 ...
软件项目测试报告怎么做？详细测试方案模板参考
从一个软件项目立项到研发最后上线要经过很多环节,其中软件测试也是其中重要的环节之一,做软件项目测试就不可避免的牵涉到项目测试报告了.一份完整明确的软件项目测试报告能够帮助软件开发人员更好的完善产品质量 ...

软件项目规模度量与实际应用

软件项目规模度量与实际应用相关推荐

最新文章

热门文章