• RSS订阅 加入收藏  设为首页
软件规模评估

利用代码行评估软件规模

时间:2015-11-6 20:00:12  作者:曹济  来源:软件成本评估  查看:1016  评论:0
内容摘要:对于功能模块方法,代码行方法在当前的软件规模评估实践中应用更为普遍。实际的情况是,代码行方法是所有软件规模评估方法中出现最早的方法,而这一点和早期的软件开发方式有直接的关系。

功能模块方法因为无法就模块的粒度给出统一的定义,所以单纯用功能模块数量描述软件规模并不是一个被普遍接受的做法。相对于功能模块方法,代码行方法在当前的软件规模评估实践中应用更为普遍。实际的情况是,代码行方法是所有软件规模评估方法中出现最早的方法,而这一点和早期的软件开发方式有直接的关系。

在软件开发的高级语言出现以前,软件开发主要采用机器语言和汇编语言开发,软件开发人员的工作主要表现为一行行所完成的代码。自然的,人们就采用代码行的数量来表示软件开发人员所完成的功能的多少,所以代码行方法可视为各种评估和度量软件规模方法的鼻祖。随着软件开发方式的转变,软件开发语言相比于早期的编程语言,例如Fortran语言、Basic语言等,已经有了天翻地覆的变化。相应地,代码行方法所关注的不单是简单的代码行数和,还要考虑代码的其他特征。

目前软件行业中所应用的代码行方法更多的是基于功能模块方法的细化和延伸,代码行方法进一步将功能模块的数量转换为代码行数量,从而使得所评估的软件规模可信度更高。采用代码行方法评估的软件规模结果如下表所示:


功能模块

功能列表

代码行(行数)

员工管理

员工信息维护

650

员工信息查询

210

员工信息报表

180

工作管理

工作信息维护

750

工作信息查询

280

工作信息报表

270

工作分配管理

维护工作分配信息

1000

工作分配查询

300

工作分配报表

400

合计

9

4040

 

在上表中,功能模块的数量为9,相应的代码行数量为4040(假定此处的开发语言为Java语言)。与功能模块粒度不容易保持一致相比较,人们对于代码行的理解相对容易达成一致,因为一行代码就是一行代码,如果在代码文件中回车另起一行那就意味着增加了一行代码。这样看来,人们对于代码行的理解更容易达成一致。所以在得到功能模块的基础之上,有经验的技术人员就可以针对不同的功能模块评估出对应的代码数量,用这种方法得到的软件代码行规模的可信度也就更高。实际上,可以将代码行方法视为对功能模块的加权处理,因而其准确性比简单的功能模块数量直接相加要更为可信。

但代码行方法在操作过程中还存在一些障碍,例如,代码行算物理行还是算逻辑行?如果算物理行代码,是否考虑代码行的长度?如果算逻辑行代码,注释语句算不算?另外代码行方法还涉及语言类型的问题,例如如何考虑C语言、Java语言或者VB语言各自生成的代码行?如何考虑应用自动生成的代码行?代码行方法目前因为尚无统一的度量标准,所以针对上述的这些问题,不同的评估人员可能会有不同的度量方式。例如有的组织在评估代码行规模时包括注释行,而有的组织则将其派出在外;有的组织一概不考虑自动生成的代码行,有的组织则将自动生成的代码乘以比例系数进行转换。

代码行目前的评估实践导致不同组织甚至不同人员得到的代码行规模数量都会有较大的差异,不同评估人员评估相同软件的代码行数量,其结果差异超出50%的情形屡见不鲜。但也有些组织规定了相对统一的代码行方法标准,从而使得同一组织内部评估的代码行数量更为接近,例如美国DODDepartment Of Defense)所颁布的软件成本评估指南中关于代码行方法的规定,需要说明的是,DOD的代码行方法主要参考了美国卡内基梅隆大学的SEISoftware Engineering Institute)曾于1992年发布过代码行方法的框架指南,另外DOD代码行方法还参考了读者熟知的COCOMOII模型中关于重用代码行的评估规则。DOD的代码行方法也是一种可用性较强的办法,下面对这种代码行方法进行简述,以便为那些应用代码行评估方法的个人和组织提供相应的参考。

DOD所发布的软件成本评估指南中对于代码行方法包括一系列的定义和公式,通过这些公式和定义确保不同评估者所评估的结果尽可能保持一致。该方法首先明确所评估的代码行为源代码行SLOCSource Line Of Code),而非编译过的机器代码行。对于源代码行进一步将其区分为四种类型,依次是逻辑源代码行(Logic SLOC)、物理源代码行(Physical  SLOC)、源代码行总数(Total  SLOC)以及非注释源代码行(Non-commented SLOC)共四种类型。



标签:规模评估 

csan.org.cn 版权所有 csan@csan.org.cn

京ICP备06052862号-2