软件功能规模度量方法中的软件分层问题分析

徐长梅，杨凤年，尹俊文

(1．长沙学院教务处，湖南 长沙 410022; 2. 湖南格凡安信科技有限公司，湖南 长沙 410008)

1 前言

六十年代的软件危机，引起计算机领域对软件的高度关注，“软件工程”概念应运而生，继而引出了大量与工程相关的管理问题.在软件项目中，质量、成本和时间形成了管理三要素[1]，所有的管理决策以及后续的管理活动都需要对三要素进行估计和测量.

特别是在软件开发项目中，软件开发成本主要取决于人力成本，而人力成本又取决于软件项目周期——时间，粗略地说人力成本等于人数*人均工资*时间，在这个公式中人数*人均工资*时间称为软件开发工作量.

为了测算软件开发工作量，人们发明了模型法、专家法和类比法等诸多方法，在这些方法中，核心的因素只有一个——软件规模.软件规模的度量最直观的方法是代码行(LOC)[2]，但是代码行度量方法存在两个固有的缺点，其一是度量标准不稳定——软件代码行取决于编程人员的经验、技术水平和编程语言；其二是度量标准可能不存在——代码只有在软件开发完成时才是确定的，在软件项目立项、需求分析和设计阶段，代码并不存在.

20世纪70年代，IBM公司的Allan Albrecht引入了软件功能规范中的功能点分析(FPA)思想[3]，提出了一种对软件功能“点”计数模型，从而摆脱了代码行方法对软件开发技术的依赖.Albrecht的模型需要从软件功能规格说明中识别出5种类型的组件：输入、输出、查询、逻辑内部文件和逻辑外部文件，分别对这五个组件进行计数并计算这些计数的加权和，从而得到软件的未调整功能点，最后根据软件的其他因子调整这个加权和，最终生成软件功能规模值.Albrecht模型最终形成了软件功能规模度量方法IFPUG[4].

IFPUG方法出现之后，在20世纪80年代到90年代初期，正值计算机在各行业得到广泛应用的时期，各类管理信息系统(MIS)层出不穷，IFPUG方法在软件项目管理中受到推崇.但是由于软件系统逐渐涵盖更广泛的领域，对软件规模的度量也拓展到软件项目的整个生命周期，度量人员发现IFPUG功能规模度量方法存在若干的问题，这其中包括IFPUG方法不适用于实时系统度量，也不能满足软件项目早期的管理要求，甚至在软件功能复用中存在重复计数的缺陷.虽然在此期间Albrecht模型衍生出了Mk-II度量方法，依然无法掩盖功能规模度量中存在的诸多问题.

在20世纪90年代后期，软件项目管理对功能规模度量方法(FSM)采取了审慎的态度[5]，也催生了更加通用的功能规模度量方法——全功能点(FFP)方法.新一代FSM以COSMIC[6]为代表，包括FiSMA[7]、NESMA[8]等各种ISO标准，它们对软件特性进行了一般化建模，采用了模型+应用指南的模式来指导软件规模度量实践，分别就实时系统、GUI系统、Web系统等提出了自己的解决方案.

尽管新一代FSM对GUI系统、Web系统等多层体系结构系统给出了答案，但是这个答案并不完全，本文就COSMIC、FiSMA、NESMA在软件规模度量实践中存在的问题进行分析，讨论了软件开发的分层问题以及软件分层对功能点重复计数的影响，并提出了一些减少计数重复的若干措施.

2 多层软件系统的FSM

分层是解决复杂软件系统问题的最常见技术[9].分层技术至少有两个不可忽视的优点，一个是重用，下层软件功能可以在上层软件中重复使用，降低了软件复杂度，也减少了质量风险；第二个优点是封装，下层软件可以抹平再下层系统的差异性，为上层软件提供统一的功能接口，从而提高了上层软件的内聚性.

IFPUG FPA和COSMIC FFP所采用的软件模型，抽取目标软件(待度量软件)与外部环境之间的交互特性，通过度量目标软件与外部环境的交互复杂度来计算软件功能规模，因此在FSM中，划定目标软件的外部边界是至关重要的.目标软件的外部边界由人机接口、软硬件接口和软件之间的接口组成.如果目标软件处于一个复杂软件系统的某一层次，那么目标软件的外部环境自然就包括它的上层软件和下层软件.但是如果目标软件本身是一个分层系统，那么在上下层中功能之间的交互该如何度量呢？

Client/Server模型是典型的分层系统，无论是GUI系统还是Web系统都采用了Client/Server模型.Client与Server的分离隔离了人机交互逻辑和业务处理逻辑，但是Client与Server之间的应用程序边界具有独特的特性，因此可能会发生功能重复.

对于使用IFPUG的度量人员来说，是否应该重复计算逻辑事务，从而在Client端复制Server系统事务？TOTALMETRCS认为，前后端是由两个团队独立完成的，因此前后端对同一事务会实现各自自己的功能，为完成同一事务所实现的功能交互应该独立计算.而且“由于应用程序边界的定位，Client系统和Server系统对功能的重复计算已被视为一种务实的解决方案”[10].

COSMIC FFP使用“层(Layer)”概念来解决多层软件的度量问题，试图度量多层软件中每个独立层次的规模.COSMIC FFP不再拘泥于计算整个软件的规模度量，而是采用更灵活的度量方式，可以给出针对每个层次的度量结果.

FiSMA则给出了度量多层体系结构软件的具体指南，就“用户接口-业务逻辑-数据访问”这一典型的三层结构给出了明确的度量规则(集合)，提高了FSM的一致性[11].

综上所述，多层软件系统始终是FSM特别关注的度量对象和实施对象.但是这样的解决方案是不完整的.

新一代FSM力图建立一个与技术无关的度量模型，主要目的是想实现全生命周期的软件规模度量.软件分层是体系结构问题，主要出现在软件设计阶段.上述的解决方案仍然不能解决软件开发早期阶段的问题，特别是在软件项目立项和需求分析阶段.

软件层次的划分在很多的系统中并不明显，而是在分析和设计中逐步演化而来的[12]，要求先划分层次，然后再进行度量，是非常困难的.为了解决一个难题，有可能会引入一个更困难的工作，对于功能管理来说是不可以接受的.

3 案例分析

课程注册系统[13]和网关系统[14]是COSMIC官方提供的两个基准案例，目的是通过对这两个案例的分析指导具体的FSM实践.

课程注册系统一共有登录、添加教授、修改教授、删除教授、选择要教的课程、新增学生、修改学生、删除学生、创建课程表、修改课程表、删除课程表、关闭注册、提交成绩、查看成绩报告卡等14个功能过程，总计功能点为106Cfps.

网关系统则包含登录交易、更改密码、注销交易、定货、列出帐户订单、订单帐户对帐单、显示语句摘要、临时目录命令、冻结登录ID、注册产品类别、删除产品类别、产品类别类别、用户产品类别、获取帐户余额、获取帐号序列号、获取最近的N笔交易、获取产品类别的序列号等17个功能过程，总计功能点为108Cfps.

在课程注册系统中，查询教授、学生和课程表是在删除和修改教授、学生和课程表等功能过程中必须完成的操作.网关系统的获取帐户余额、获取帐号序列号、获取最近的N笔交易、获取产品类别的序列号等功能过程被其他的功能过程调用.

在COSMIC FFP的参考文档中，他们对这些存在公共关系的功能过程或者操作序列采取了“视而不见”的“鸵鸟”策略.这遵循了COSMIC FFP的一般原则，这样的功能过程或者操作序列发生在层(软件)内部，不再识别内部的调用关系.

但是我们认为，这样的功能的功能过程或者操作序列肯定会被程序设计人员识别出来，至少形成一个公共的库(组件)提供给其他人员重用.值得争论的是，这样的库(组件)是否是技术无关的，毕竟新一代FSM力图实现一个与技术无关的度量方法.但是我们的观点是，这样设计公共(通用)零配件(组件)的方法与软件开发技术无关，而应该是一种工程常识，从生产成本和质量控制角度看是一个必须的管理措施.这些公共组件虽然不能称为完全意义的软件层次，但是确实在外部环境和其他功能过程之间建立一种层次关系.

为了能够准确的将公共操作序列抽象为公共功能过程，我们遵循以下规则：

规则一：任何一层至少包含一个功能过程.

规则二：任何识别出来的层次都处于当前层的下一层.

规则三：被调用的功能过程被放置于新的下一层中.

在这样的规则之下，度量过程中使用规则四、规则五和规则六识别重复的操作序列.

规则四：抽取的公共操作序列必须满足功能过程定义.

规则五：重复出现的、并且满足规则四的操作序列识别为功能过程.

规则六：将功能过程中满足规则五的操作序列都替换成功能过程的调用，即以此Entry和Exit.

增加了新的规则之后，则形成了两种不同的度量结果，如表1和表2.两个案例中虽然产生的差异小于10%，但是在并不表明这个差异可以忽略不计[13].

4 结论

我们的方法借鉴了软件分层技术，识别出软件需求中的公共组件，符合工程常识，与COSMIC FFP的常规差别在于软件层次的划分时机，我们认为软件中的层次划分不仅存在于软件设计阶段，在业务分析阶段依然可以识别出软件层次.

相较于COSMIC FFP的常规方法，如果需要给出软件的整体规模，我们的方法存在着重复度量的问题，为此，我们也借鉴了FiSMA的实践指南，采用双向识别、单向计数的规则，这样就可以较好的去除重复的计数.

规则七：度量软件的整体规模时，如果包含多个层次，那么上层功能过程仅仅对功能过程中调用下层功能过程的Exit计数，不对上层功能过程调用下层功能过程的Entry计数.下层功能过程仅仅对Exit计数，也不对Entry计数.

在上述两个案例中，我们的最终结果分别是87Cfps和102Cfps.