非功能性需求对COSMIC软件预估方法的影响研究

汪福明

摘要摘要：COSMIC功能点度量算法作为IFPUG度量算法的扩展，在软件项目早期预估中起着非常重要的作用，同时软件项目对早期度量精度和准确度的要求也越来越高。针对早期功能点度量算法COSMIC方法在预估过程中准确性不足的缺点，提出通过增加调整因子来提高软件项目度量的准确性。该方法通过增加复杂度、可重用性和效能3个调整因子来调整实际度量的功能点总数，提高度量的准确性，避免了因功能点数不足带来的误差。

关键词关键词：早期快速预估；软件度量；COSMIC方法；非功能性需求

DOIDOI：10.11907/rjdk.162292

中图分类号：TP302文献标识码：A文章编号文章编号：16727800（2017）001001104

0引言

项目规模预估作为软件项目管理过程中非常重要的环节，它是后续项目计划编制和人员预算安排的重要依据和基础。在一些研发型的软件项目或者是软件项目的立项评审阶段，由于软件项目目标的不准确性、需求的多变性和项目功能的渐近性，只能粗略地定义项目需求[1]，同时标准的估算方法此时并不适用在项目的早期阶段，而且在项目的早期进行标准的度量往往也是不经济、合算的[2]。因而需要一种有效、快速并相对精确的项目估算方法来进行软件项目规模的度量。

软件项目规模的度量主要有定量预估方法和定性预估方法，包括DELPHI法、类比法、功能点分析方法、经验法、COCOMO法、代码行评估法等。目前对软件规模度量的主流方法是功能点方法，功能点方法根据软件项目的功能性需求来度量软件的规模大小[3]。功能点早期估算方法在软件早期规模度量中占有重要地位。

主流早期功能点方法包含COSMIC估算方法、NESMA方法、IFPUG方法、Mark Ⅱ方法、FISMA方法等。不同的方法适用范围不同，根据相关国际标准中的方法适用范围声明，IFPUG适用于所有类型软件系统；NESMA与IFPUG非常类似，但对功能点计数作了分级，以便在测算的不同时期选择不同精度的方法进行度量，MK Ⅱ方法适用于逻辑事务能被确定的软件系统。FISMA方法可用于度量所有类型的软件，与其它功能点方法的不同之处在于它是面向服务而非面向过程的。

相比其它功能点估算方法，COSMIC方法适用的项目类型更多样，它为业务应用软件或MIS软件、实时软件、基础设施软件以及一些科学或工程软件提供了一种度量软件功能规模的标准方法。它计数规则相对简单、学习成本低，可以在项目早期比较快速地对项目规模进行度量[4]。但是COSMIC方法不适合复杂算法系统和连续变量系统的处理，比如天气预报、声音和图像处理系统等。

本文研究分析了非功能性需求对度量规模的影响，通过增加重用率、效能、复杂度调整因子对功能模组进行加权处理来改进COSMIC方法，提高估算的准确性。并通过一些项目的数据，验证该方法确实提高了软件度量的有效性和准确性。

1COSMIC方法简介

COSMIC方法又叫全功能点方法，是由从Alain Abran博士的“全功能点”方法演化而来，并结合了Charles Symon的MarkⅡ功能点方法的一些思想，是IFPUG功能点方法的一种扩展。COSMIC方法是通过国际标准协会认证的5种标准度量方法之一。

COSMIC包含了应用一组模型、原则、规则和过程来度量给定软件块的功能性用户需求（Function User Requirement，简FUR）的方法。ISO定义的功能性用户需求包含数据传输、数据变换、数据存储和数据检索[5]。1.1基本原理

COSMIC方法将软件系统分解为若干功能过程并通过“数据移动”进行度量。本质上看，功能过程就是一个唯一的、内聚的、独立并且可执行的数据移动集合。一个数据移动是一个数据组的传输，一个数据组是一个可区分的、非空的、无序且无冗余的数据属性的集合。数据移动分为4种类型：数据入（Entry）、数据出（Exit）、读（Read）和写（Write），一个数据移动即为一个COSMIC功能点。

数据输入是指功能用户跨越被度量系统的边界传输到系统内部的过程，这里的功能用户是指与被度量的系统进行交互的自然人或物，可以是使用系统的终端用户，也可以是其它系统和硬件设备；数据输出是指一个数据组从一个功能过程移动到其他功能用户；读是指从持久性设备读取数据组；写是指将数据组写到持久性设备。

一个功能过程至少从一个可识别出来的功能用户需求（FUR）派生出来。功能用户通过触发事件作用于功能过程。当一个触发事件发生时，一个功能过程就被执行。在COSMIC方法中，一个功能过程至少由两个数据移动组成，比如一个数据输入（Entry）加上一个数据输出（Exit）。该方法的估算模型如图1所示。

1.2度量过程

该方法度量过程分为三大阶段，度量策略阶段、映射阶段和度量阶段。度量策略阶段主要用来阐述软件功能4个关键的规模度量参数：度量目的、度量范圍、识别功能用户和粒度级别。在映射阶段，通过度量策略阶段所完成的工作以及被度量软件的功能用户需求相关文档，识别功能过程，进而识别数据组和数据属性。COSMIC度量阶段的主要任务是，根据COSMIC通用软件模型所表示的功能用户需求，识别数据移动及其数量，汇总所有数据移动的数量从而得到被度量软件的功能规模。1.3功能点计算汇总

在COSMIC方法模型里，一个数据移动被认为是一个COSMIC功能点（Cosmic Function Point，CFP），CFP是COSMIC方法模型中标准的度量单位。通过计算软件项目中所有“数据移动”的数量得到整个项目的功能规模[6]。在为每一个功能过程找到所有数据移动之后，将它们累加在一起就可以得到该功能过程的规模，如式（1）：

Size（FPi）=Size（Entryi）+Size（Exiti）+Size（Readi）+Size（Writei）（1）

将所有功能过程的大小数值加以累计就可以得到整个软件系统的度量规模。

度量功能过程时需要从FUR的角度进行，不同的角度度量的规模大小会不一致，用户角度和开发人员角度所度量出来的结果是不一致的[7]。

1.4COSIMIC在具体软件项目中的运用

对笔者参与过的8个软件项目运用COSMIC方法进行软件规模度量，这8个项目历时3～6个月，开发团队成员在2～6人，这8个项目中，调整了由于中途的需求变更带来的CFP追加和减少的部分，并基于邻近度的离群点检测处理掉离群点[8]偏离比较大的项目，最后实际进入规模度量范围的为5个项目。

对软件进行规模度量时将总的CFP数转换为实际的人月数，公式为：总人月数=总的CFP数/（生产率*每月工作日），生产率取值为0.8个功能点/人日，生产率从历史数据中获取。

统计学中，常用的误差为相对误差（ Magnitude of Relative Error，简称MRE）。针对工作量估算，其计算方式为估算误差绝对值除以实际工作量，如式（2）：

MRE=|Effortactual-Effortestimated|/Effortactual（2）

其中，Effortestimated是改进后的估算方法得出的工作量值， Effortactual是实际工作量[9]。

登陆用户名和密码输入用户名和密码数据入1从数据库读取用户名和密码信息用户名和密码读1登陆成功进入指定界面数据出1显示用户名和密码错误数据出1记录登陆日志用户名和密码写1从表2中对比可以看出，预估出来的度量工作量与实际工作量误差较大，通过对偏差原因进行分析，发现同等粒度的每个功能点由于代码模组重用率、不同复杂度和不同效能的要求引起实际所花费的工作量与预估的工作量偏差较大。

COSMIC方法是对软件功能规模的间接性度量。其基础是软件功能需求分析，COSMIC方法度量的功能规模被设计成只与被度量软件的FUR有关，而不依赖于实现FUR的需求和限制。因此它所度量的软件规模是只反映了与软件系统功能相关的那一部分，不包括系统的非功能性需求部分（Nonfunctional Requirement，简称NFR）[10]。

在实际软件项目开发过程中，FUR被映射为COSMIC软件模型前，度量者需要从软件相关文档提取FUR。实际发现，能够从软件相关文档（如需求文档、设计文档）中将FUR与其它需求清楚地区分开并且表示成一种适合于直接度量的形式是比较难的。

研究表明，一些最初呈现为系统NFR的需求（如质量约束、环境约束）会随着项目的进展演化为在软件功能中可以实现并可以当作功能性需求度量的混合需求，比如要求更高的执行效率。特别是对质量和环境约束而言，这些在项目初期藏在NFR中的软件功能，一旦被识别，就可以像对待别的软件功能一样，用COSMIC方法度量其规模。软件规模会随着项目进展不断增长的原因之一就是没有识别出这些隐藏的功能规模。NFR处理不当会导致项目失败，或者导致相当大的延迟，其结果是成本的大幅增加[11]。在非业务软件系统领域，NFR工作量能够占到整个项目工作量的50%[12]。

2基于非功能性需求引入调整因子的改进预估模型2.1基本思路

在功能点方法的其它方法中，通过调整因子来对系统进行非功能性需求处理，COSMIC与IFPUG、MarkⅡ计算规则[1314]的对比如表3所示。

本研究结合ISO/IEC TR 14143-3：200质量标准[15]，通过追加几个调整因子来建立一个改进模型。

目前存在较多的调整因子被加入到预估模型中并已经被证明对预估结果有改进效果，这些调整因子包含了团队规模、程序语言类型、组织类型、业务领域类型、应用程序类型以及开发平台[16]。在基于IFPUG和MarkⅡ评估方法中，调整因子是基于基础组件进行加权处理[17]。在该改进模型中，为了评估的准确性和一致性，评估的粒度也是基于基础组件层面即COSMIC的功能过程。

2.2应用验证

运用新的CFP计算公式（3），对5个项目重新计算，每个功能模组按基础组件里CFP分别进行加权处理。首先按功能模组计算功能点数（见表1），然后对功能模组按基础组件分别运用调整因子计算加权值（见表5），最后累加所有功能模组的功能点数即为优化后的功能点总数，并比对未调整前的功能点数（见表6）。具体运用规则举例如表5所示。

运用以上优化规则，重新计算5个项目的预估工作量，并汇总计算结果；同时分析运用调整因子和未运用调整因子的工作量偏差原因，并对比结果，如表6所示。

通过对功能模组CFP加权后，总的CFP数有所增加，而这部分增加的CFP则是从非功能性需求分析中的重用率、复杂度和效能识别出来的，并转换为可以度量其规模的功能点。

根据表6的偏差结果分析可知，CFP基数比较大的项目由于重用率大、相对较大的復杂度以及在效能方面更多的要求，引入调整因子后，工作量预估结果的相对偏差有明显降低。这符合越大的项目在复杂度、效能以及重用率上的影响会更大，从非功能需求中转换而产生的新功能点总数也会相应增加。

本文分析了非功能性需求部分对功能性需求的影响，并基于COSMIC方法增加了3个调整因子来改善软件项目工作量预估偏差，3个调整因子从单个功能过程的粒度将功能过程的非功能性需求转换为可以度量的功能点数，并且通过功能过程中数据入、数据出、读和写4个方面，能够较为精确地控制和评估这些调整因子对功能过程的影响程度。相对于系统级评估调整因子对所有功能过程的影响，其准确度更高。

通过笔者实际参与的项目论证了调整因子对预估有一定的改善作用。但目前调整因子只使用了重用性、复杂性和效能3个影响系统的非功能需求因子，还未能覆盖其它权重的因子。这是需要今后逐步改善和在实际软件项目中继续论证的部分。参考文献参考文献：

[1]卢向南.项目计划与控制[M].北京：机械工业出版社，2009.

[2]朱安江.早期阶段软件规模估算方法研究与应用[D].长沙：国防科技大学，2011.

[3]蒋辉.COSMIC方法客观性风险评估方法的研究与应用[D].长沙：国防科技大学，2008.

[4]罗怀勇.COSMIC方法研究及度量过程改进[D].长沙：国防科技大学，2010.

[5]方小龙.I F P U G功能点分析方法的研究与应用[D].长沙：国防科技大学，2007.

[6]SOUMAYA BARKALLAH，ABDELOUAHED GHERBI，ALAIN ABRAN.COSMIC functional size measurement using UML models[C].ASEA/DRBC/EL 2011， CCIS 25，Berlin Heidelberg：SpringerVerlag，2011：137146.

[7]王昕渝，侯红，郝克刚.COSMICFFP方法的研究及应用[J].计算机应用与软件，2008，25（10）：1113.

[8]王茜，杨正宽.一种基于加权KNN的大数据集下离群检测算法[J].计算机科学，2011，38（10）：177180.

[9]SHEPPERD，M J MACDONELL S G.Evaluating prediction systems in software project estimation[J].Information & Software Technology，2012，54（8）：820827.

[10]ISO/IEC 14143/1：2011.Software engineeringCOSMIC：a functional size measurement method[EB/OL].www.iso.org.

[11]MOHAMAD KASSAB，OLGA ORMANDJIEVA，MAYA DANEVA，et al.Nonfunctional requirements size measurement method（NFSM） with COSMICFFP[C].IWSMmensura 2007，LNCS 4895，Berlin Heidelberg：SpringerVerlag，2008：168182.

[12]LUIGI BUGLIONE，OLGA ORMANDJIEVA，and MAYA DANEVA.Using PSU for early prediction of COSMIC size of functional and nonfunctional requirements[C].IWSM/MetriKon/Mensura 2008，LNCS 5338，Berlin Heidelberg：SpringerVerlag，2008：352361.

[13]ISO/IEC IS 20926.Software engineeringifpug 4.1 unadjusted functional size measurement methodcounting practices manual，international organization for standardization[Z].2003.

[14]ISO/IEC IS 20968.Software engineeringMK II function point analysiscounting practices manual，international organization for standardization[Z].2002.

[15]ISO/IEC TR 141433.Information technologysoftware measurementfunctional size measurementpart 3：verification of functional size measurement methods[EB/OL].www.iso.org.

[16]LUIGI BUGLIONE，CIGDEM GENCEL.Impact of base functional component types on software functional size based effort estimation[C].PROFES 2008， LNCS 5089，Berlin Heidelberg：SpringerVerlag，2008：7589.

[17]蔣辉，尹俊文，何鸿君.功能点方法的分析与比较[J].计算机工程与科学，2009（31）：8789.

责任编辑（责任编辑：孙娟）