一. 软件规模度量的必要性
软件项目规模的度量,是软件项目中相当重要的一环. 只有相对合理和相对准确地度量软件规模,才能对项目的计划进度安排,资源分配,等等各个环节进行合理的部署.这样才能尽可能地保证软件项目的进度和质量. 原因是:
1. 软件项目与其它项目,例如建筑工程项目,汽车制造项目等,都有可以通过加大资源投入而获得更大生产力的特点.比如增加一条汽车生产线,生产能力能马上提高一倍.(当然其中仍包括一些工业生产线上的一些如何最大化流水线的技巧理论问题,但从总体上来说,软件生产不具备这样的特点),当加大软件开发资源的时候,如果管理不善,会出现生产力下降的情况.尽管其它的工业生产也可能发生这样的情况,但软件生产发生的概率要大很多.
2. 有90%的软件项目难以预测,只有10%的软件项目能在够在预定的费用和进度下交付.从这个角度看,能否准确地度量软件的规模,成为软件项目成功的重要矛盾点.
3. 软件项目规模的相对准确度量,能为项目计划,为项目的甲乙双方的资源分配调动提供有力的招引,尽管软件项目的度量是不可能完全精确的.有目的性地进行度量,能让项目组对软件开发的整个过程中出现的各种问题和风险有预先的估计,避免盲目从而能在实际上有效的提高软件项目的生产水平.
二.软件项目规模度量的相关方法及其局限
比较流行的软件规模度量的方法是代码行(LOC)和功能点(FP)两种
代码行度量的方法
代码行度量的方法,是通过各种手段,统计出软件项目的代码行.从而按代码行的数量为单位度量出软件的规模.
一般使用代码行度量自动化工具来进行度量,要度量的文件类型包括软件项目中交付用户使用的各种文件. 一般来说,如果项目的配置管理是使用CVS的话,可以使用StatCVS进行代码行度量.
LOC方法的优点是:
1. 度量工作容易进行,而且自动化度量工具非常多,即使自行开发难度也不高
2. 代码行数是比较公认的软件规模的标准,容易在项目的甲乙双方中取得共识.
规模度量的方法缺点是非常明显的.
1. 很难在项目分析论证和计划阶段就对软件的规模进行相对准确的度量. 即使进行度量
2. 即使进行度量,也必须依靠于评估人员的经验所得.虽然只要评估人员经验足够,可以获得比较准确的度量结果,但是这对评估人员的能力要求比较强,并而且难以由第三方对评估人员的工作偏差作出修正.
3. 不同软件项目使用的技术不一样,这一点,非常影响到软件规模的度量.例如同一个功能,使用JAVA语言和使用Ruby语言所涉及的代码行相差数十行,甚至数百行. 即使同为JAVA语言,使用不用的框架所需要编写的代码行也不一样.
总体来说,LOC方法很适合软件业初期,使用比较简单的程序开发语言的项目进行规模度量,但是随着软件工业的发展,LOC方法进行度量的难度越来越大,而准确和可操性在逐渐降低.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的数量 [本文共有 2 页，当前是第 1 页] <<上一页 下一页>>
您的位置：
