计算机应用研究
APPLICATION RESEARCH OF COMPUTERS
2000 Vol.17 No.3 P.52-54




软件成本模型的理论研究与工具开发
徐克奇
摘　要：首先研究和分析了Function Point Analysis的特点，FPA是一种软件成本功能度量方法，可很好地运用于信息管理系统(Management Information System，MIS)领域，但是FPA不能很好地捕获作高强度处理的应用程序的功能特性，比如实时软件的动态与控制功能。随后围绕着如何改进FPA，使其也适用于实时控制系统展开论述。另外，文中提出了两种Metrics结合的方法，即FPA和COCOMO结合，并给出一个实例：建立软件成本模型后，在Web Server上开发一个成本估算工具(SCET)。
关键词：成本模型 FPA 信息管理系统 实时系统 软件工具 数据库系统
　　随着计算机应用的普及和发展，计算机软件已成为整个计算机系统中的开发费用最昂贵部分。软件开发者和应用者越来越重视和关心软件成本问题，尤其是美国、德国等一些技术先进和经济发达的国家特别重视。他们先后推出了许多软件成本估算的方法，“Function Point Analysis”是其中的一种。
1　Function Point Analysis简述
　　FPA是一种软件成本的功能度量方法，是对计算机应用软件以及制作它们的工程项目大小的度量，其大小由项目的功能或用户的观点来衡量。计算FPA的第一步是定义计算边界，即需标识要度量的应用程序或项目与外部应用程序和用户区域的边界。边界的建立可确定哪些是属于FPA的计算范围。图1表明了一个要度量的应用软件与用户及其它应用程序之间的边界的例子。下一步要确定未校准的FP(UFP)的数目，反映在由项目或应用程序所提供的具体可计算的功能性。它划分为五种功能类型(见图1)。

图1　FPA component
　　内部逻辑文件(ILF)：应用程序边界内部的可由用户确认的逻辑关联的数据组或控制信息。外部接口文件(EIF)：其它应用程序边界内部的由用户确认的逻辑关联的数据组或控制信息，本应用程序仅可参考或使用这些数据，而不能维护。
　　外部输入(EI)：来自于应用程序边界外部的数据或控制信息输入的基本处理。
　　外部输出(EO)：EO是一个产生数据或控制信息并发送到应用程序边界外的基本处理。
　　外部查询(EQ)：EQ是一个由完成数据检索的输入输出结合所构成的基本处理，输出端不含派生数据。
　　这五种功能类型按照它们的复杂程度(低、中和高)用一套规范的标准各自进行分类。分类后，则按预先规定的权重计算UFP。最后一步还要对项目或应用程序环境与处理过程的复杂程度进行总体的估算，从而得到了校准的FP。
2　改进的Function Point Analysis
2.1　FPA对实时控制软件的缺陷
2.1.1 数据的缺陷
　　一般来说控制数据结构有两种：多事件逻辑组和单事件逻辑组。多事件逻辑组有多个同类型的记录，单事件逻辑组就是有而且仅有一个记录。MIS系统的数据信息大都是多事件逻辑组，这些数据有一个相同的结构，多事件逻辑组很适合用内部逻辑文件ILF和外部接口文件来描述，但是，典型的实时软件系统有着大量的难以与ILF或EIF组合的单事件逻辑组，即一种事件对应于一种数据类型，因此需要有扩展的ILF/EIF规则来充分地度量单事件逻辑组。
2.1.2　处理的缺陷
　　通常实时软件过程有一个独特的处理特征：子过程的个数大不相同。在功能度量时，必须重视某些过程只含有几个子过程，而另一些过程则有大量的子过程。如：一个发动机温度控制过程，它包含3个子过程：输入当前温度，当前温度与阈值温度比较以及一个开启信号，发动机的温度控制过程仅仅是发动机控制应用程序中许多过程之一，当所有的温度控制子过程完成之后，这时应用程序才处于一致状态，因此，程序中只有一个基本处理，根据FPA的规则，只看作一个处理功能点；又如有一个发动机诊断过程含31个子过程：15个不同的传感器数据读入子过程，15个与阀值比较子过程，一个报警子过程。同温度控制过程一样，也只有一个基本处理，由于处理功能点只基于基本处理的数量而不是子过程的数量，因此，对于上述两例，FPA算出来处理功能点差不多的，但是实际上的软件工作量却大相径庭。
　　也就是说，FPA对于实时软件的度量并不符合实际情况，因为它没有考虑到实时软件中子过程数量对总工作量的影响会远远超过普通软件。
2.2　改进的Function Point Analysis
　　鉴于上述的分析，在FPA基础上引入了附加的数据和处理功能类型。新的FPA是标准的FPA技术的扩展，它由两部分组成：管理Function Point (MFP)和控制Function Point(CFP)。
　　管理方面MFP相同于标准的FPA，但在计算MFP过程中，要滤去一些控制信息。控制方面CFP定义为6个新的功能类型(计算边界由图2表示)。

　　内部控制逻辑组(ICLG)：ICLG是一组逻辑上相关联的，由要计算的应用程序更新的控制数据。
　　外部控制逻辑组(ECLG)：ECLG是一组逻辑上相关联的，被要计算的应用程序使用，但不更新的控制数据。
　　外部控制输入(ECE)：ECE是一个独特的子过程。ECE过程控制来自应用程序边界以外的数据，它是对一组数据最低级别的操作。因此输入两组数据就需要两个ECE。ECE并不更新数据。
　　外部控制输出(ECX)：ECX是一个独特的子过程。ECX过程控制送出应用程序边界的数据，它是对一组数据最低级别的操作。因此输出两组结构不同的数据就需要两个ECX。ECX不读取数据。
　　内部控制读取(ICR)：ICR是一个独特的子过程。ICR读取控制数据，它是对一组数据最低级别的操作。因此读取两组数据就需要两个ICR。
　　内部控制写入(ICW)：ICW是一个独特的子过程。ICW写入控制数据，它是对一组数据最低级别的操作。因此写入两组数据就需要两个ICR。
　　为了计算FP，每个定义的功能类型应当给予一个功能复杂程度，MFP的功能复杂度权值是由数据元素类型(DETs)、记录元素类型(RETs)和参考文件类型(FTRs)的数目所决定的，CFP的控制数据若为多事件逻辑组则与MFP的ILF和EIF结构相同，即可用相同方法计算，其余的则由而且仅由数据元素类型(DET)的数目决定。有了权值，就可以通过以下的公式来计算FP：

其中nl，n2分别为MFP，CFP的功能数，ci，c'i分别为MFP，CFP功能复杂度的权值。同时应当考虑软件项目或应用程序开发环境及开发过程复杂性因素即14条总体的系统特征(GSCs)和相应的校准因子值，每个校准因子的范围为0～5，总的校准因子值(VAF)可以由下列公式得到：

校准的FP为：
FP=FFP_total．VAF
2.3　Function Point Analysis和COCOMO结合
　　通常总是直接寻找开发工作量和算出的Function Point数目之间的关系，一旦同类环境、同类项目或应用程序的历史数据库建立后，这不失为一种可行的方法，只要运用回归分析技术可得到两者之间的关系。不幸的是要建立这样的历史数据库很难，它需要时间和精力，另外简单地将一个项目或应用程序分为商用、管理、军事等类也是不合适的。这里，将利用两种Metrics结合(Function Point Analysis，COCOMO)来推算软件开发工作量，首先将FP的数目转换成等价的程序代码行[4]，然后运用COCOMO技术来评估。这种方法不仅不需要大规模的历史数据库，而且可以利用Function Point未考虑到的，又是很重要的，COCOMO的成本因素，去正确估算不同开发条件的软件开发成本。可以按以下公式计算程序代码行：
KLOC=AdFP．LOC/1000
其中AdFP是调整后的FP数，LOC为每个FP对应的程序代码行，KLOC是以千行为单位的程序代码行数。
　　COCOMO模型是将软件开发工作量表示成估计应该开发的项目的程序代码行数的非线性函数：

其中PM是开发工作量，α、β分别是模型系数和指数，ai为项目的15个成本因素的调整因子。
　　α、β取决于COCOMO模型系统和开发项目的类型，表1是Boehm所采用的系数值。
表 1　Intermediate COCOMO Coefficient Value

Modeαβγδ
Mode3.21.052.50.38
Organic3.01.122.50.35
Semi-detached2.81.202.50.32

　　COCOMO模型在估算出软件开发工作需要的工作量(以人月为单位)基础上，可以推算开发软件所用的时间和开发所需的人数，Boehm给出的计算应为： 

其中，TDEV为开发时间(以月为单位)，N表示开发人数。γ，δ同样取决于COCOMO模型系统和开发项目的类型。
3　软件成本估算工具的开发
　　软件成本估算工具(SCET)是专为协助估算软件项目成本而设计的，开发一个既方便又合理的工具去帮助估算软件成本是很有必要的，它将有助于广大软件项目投资者、项目经理和设计者在软件开发生命期的不同阶段估算软件开发的成本。本工具开发步骤为：(1)功能说明；(2)设计；(3)实现；(4)测试。
3.1　功能说明
　　从应用的角度划分，SCET工具应当具有两个主要的工作模式：Metrics管理和Metrics应用。SCET工具包含两种Metrics：改进的Function Point Analysis和COCOMO。程序设计语言代码行转换表作为FPA产生的结果和COCOMO输入条件(KLOC)联系的桥梁。Metrics管理主要由四个基本功能组成：输入、修改、删除、查询。所谓Metrics应用就是用户运用上述Metrics对开发的软件项目进行成本估算的过程。Metrics应用提供六个基本功能，它们是：输入、修改、删除、查询、估算和修正。
3.2　设计
　　SCET工具是一个典型的数据库处理系统，设计过程由两部分组成：数据模型和结构设计。SCET工具的数据模型是借助ER(Entity-Relationship Model)方法建立的。ER模型由P.Chen提出，是一个面向问题的概念性数据模型，它用简单的图形方式(ER图)描述现实中的数据，而不涉及这些数据在数据库系统中将如何实现的问题。
　　SCET工具的结构设计是采用了层次模块化设计原理，第一层是用户注册，第二层包含两个工作模式：Metrics管理模式和Metrics应用模式。Metrics管理模式由4个子模块组成，它们是“输入”、“更新”、“删除”和“查询”组成，这些子模块分别对Metrics数据和用户信息进行处理。Metrics应用模式由“输入”、“更新”、“查询”、“删除”、“计算”和“修正”6个子模块组成。模块的设计采用了当今国外较流行的面向数据流的设计方法，即以数据流图表示。
3.3　实现
　　笔者完成了对SCET工具的开发和初步的测试工作。SCET工具的开发所采用的系统配置为：服务器端操作系统为Windows NT 4.0，数据库系统为ORACLE 8.0，ORACLE Web Server 3.0 作为Web服务器。
　　Web开发的应用程序的用户界面是由一系列Web页组成，每个Web页是由一个PL/SQL块创建的。SCET工具的主页一般是客户的最初入口，当一个客户要求访问页面时，Oracle Web Server服务器将向用户询问口令，并核对口令以决定是否允许客户访问。定位、按钮或图象用于Web页的相互联系SCET工具运用HTML的框架(Frame)。窗体(Form)和表格(Table)来实现数据的输入和输出，下拉列表框(Pop list item)、单选按钮(Radio group)和复选框(Check box)用于减少数据的输入量，美化用户界面。由于SCET工具是面向全球的，在工具的入口处加上了口令，以防被非法访问。任何想要使用SCET工具的用户，首先必须提出申请(E-mail)，申请的权限大致有这些：(1)本人项目估算；(2)查看他人项目的估算结果；(3)对他人项目的估算等。一个在现实世界中能够应用的软件工具面对用户在使用时发生的某些错误应具备一定的容忍程度。毫不例外，SCET工具也具有一定的容错性。通过使用Oracle的异常处理器来处理正常执行过程中未预料的事件。
3.4　测试
　　SCET工具的测试工作应对每个模块的每个功能、采用按路径覆盖的原则选择多组参数进行测试，对数据的不同输入方式也需要进行全面的测试，从而找出软件中的错误，保证软件的质量。对SCET工具的测试方法采用的是简单而实用的黑盒法。
4　结束语
　　以上SCET工具是笔者在德国作访问学者时开发的。本文所论述的软件成本模型是根据国外有关资料和一些实践相结合的首次研究，这一模型的建立只是一种初步尝试，有待于继续进行探讨，使得软件成本模型更完善，更具有一致性。
徐克奇(上海轻工业高等专科学校 上海 200433)
参考文献
1 International Function Point Users Group(IFPUG): Function Point FAQ Updated June25, 1997, Copyright l996～1997 by Software Composition Technologies. INC.
2 Denis St-Pierre, Marcela Maya, Alain Abran, Jean-Marc Desharnais. Full Function Points: Function Points Extension for Real-time Software Concepts and Definitions, Technical Report 1997-03
3 Capers Jones, Chairman. Programming Languages Table Release 8.2, March l996 Software Productivity Research, INC.
4 张海藩著. 软件工程导论. 北京：清华大学出版社
5 Oracle Web Application Server Handbook Dynamic Information System, LLC
收稿日期：1999年10月1日
