改进的PROBE方法模型的在软件项目规模估算中的应用*

杨　勇

(湖北省襄阳职业技术学院　襄阳　441050)



改进的PROBE方法模型的在软件项目规模估算中的应用*

杨勇

(湖北省襄阳职业技术学院襄阳441050)

结合在实际项目中的经验对PROBE方法进行改进,并提出一个改进的PROBE方法模型。模型以改进PROBE方法为核心,分理解需求分析并进行概念设计、产生规模相关表、确定新增部件规模、确定基础和重用部件规模、估算非编程任务、选取合适的proxy、选择规模估算规程方法、根据线性回归方程确定项目规模等八个阶段对部件如何获取,如何编写与组织,何时进入估算,估算的具体过程给出了全面的指导。

PROBE方法; 部件规模; 软件规模; 线性回归

Class NumberTP391

1　引言

目前,软件规模估算思想和方法层出不穷,其中围绕功能点分析展开的各种研究占据了前沿的位置,但是功能点分析只是软件规模估算的程序规模因子如何切割和度量的一个研究焦点,软件规模估算视角还涉及如何利用历史数据、如何建立准确的评价体系、如何设定各因子的评分系数、如何将软件规模估算契合到先进的软件团队开发流程中、如何在功能点分析这个理念指导下划分规模因子、如何结合技术人员的技术能力和程序员心理度量软件规模。本文提出基于改进的PROBE方法的软件规模估算方法与PSP的计划这一层次下软件规模估算的关注视角相吻合,在其模型的基础上改进多个关键因素,创建一个PSP背景下的新的软件规模估算方法,并用实例进行验证其效果。

2　PROBE方法改进要素的研究

PROBE方法在计划中的地位如图1所示。在这个计划框架中,用PROBE方法做估算时,需要比较这项工作和以前工作的历史数据。在每一次估算前,要保证所使用的历史数据是来自于类似项目的。

图1　PROBE方法估算流程

2.1设计模式视角改进

目前PROBE方法在提到概念设计的时候,只是简单地提到要进行部件分解为具体项目用于后续proxy的确定。如何在概念设计阶段划分出真实可用的部件,就要结合设计模式思想、UML和前面提到的功能点法来分解部件。

首先要根据需求确定系统的边界。通过UML工具建立用例图,用例图展示了系统外部行为者与系统所提供的用例之间的联系。第二步是计算文件数,进行基于类图的ILF和EIF计数,根据内部逻辑文件(ILF)和外部接口文件(ElF)的特点,它们的计数主要由UML的类图计算出来。第三步进行基于交互图的El、EO和EQ计数。部件的用例图描述了系统提供的功能,也描述了系统的边界,因此事务(外部输入EI、外部输出EO和外部查询EQ)的个数可以由用例图中的用例来确定。第四步对部件进行复杂度的判定。事务的复杂度值由数据元素类型DET和引用文件类型FIR决定,文件的复杂度值由数据元素类型DET和记录元素类型RET决定。

2.2估算数据约束

PROBE方法重要的一个步骤是利用线性回归方法和统计方法估算计划新增和修改的规模或时间,这个线性方程如下表示:

计划新增和修改的规模或时间:P=β0+β1*E。β0表示初始时间,β1表示平均开发每个类或数据库元素等项目所需的时间。关键就是如何利用数据求得β0和β1的值。这要看数据的质量以决定如何使用PROBE方法。

理想的情况是有四个以上估算代理规模以及满足相关性r>0.7的实际新增和修改规模的数据点,暂且把这种情况下采取的PROBE方法叫做PROBE 1方法；其次情况是估算代理规模没有4个以上,但是有计划新增和修改的数据点以及满足相关性r>0.7的实际新增和修改规模的数据点各4个以上,暂且把这种情况下采取的PROBE方法叫做PROBE 2方法；在差的情况是在PROBE 2方法的情况下,满足要求的数据点不在4个以上,其数据相关性也无法满足r>0.7,暂且把这种情况下采取的PROBE方法叫做PROBE 3方法；最差的情形是什么可用的数据都没有,实际上没有做预测而仅仅是猜测一个值作为计划新增和修改的规模或者开发时间输入到项目计划中去,暂且把这种情况下采取的PROBE方法叫做PROBE 4方法。

在PROBE方法的概念设计、部件附加、确定基础部件和重用部件规模阶段,接下来的规模估算要按照上述的情形进行细化。对于PROBE 1方法使用线性回归方法,根据估算代理规模和实际新增和修改规模的数据,计算参数β0和β1；如果β0的绝对值不接近于0(小于新程序的预计规模的25%),或者β1不接近1.0,即在[0.5,2.0]区间之外,使用PROBE 2方法。此时同样对于PROBE 2方法使用线性回归方法,根据计划新增和修改规模以及实际新增修改规模的数据计算参数β0和β1；如果β0的绝对值不接近于0(小于新程序的预计规模的25%),或者β1不接近1.0,即在[0.5,2.0]区间之外,使用PROBE 3方法。对于PROBE 3方法,β0=0,β1=累计实际新增和修改规模/累计计划新增和修改规模。

2.3人员心理要素

应用PROBE方法的过程,除了上述技术要素的改进之外,还应该考虑人员的心理要素。这个心理要素包括两方面,其一是估算人员的心理因素。另外一种是项目开发人员的心理因素。前者是影响PROBE方法的一个内在变量,后者是PROBE方法应用时需要考虑的外部变量。

项目开发人员的心理因素是由于双重身份引起的。在估算过程中的个体在后续的项目进程中扮演不同的角色。高级程序员由于侧重于概念设计的具体工作,因此对于PROBE方法针对编码元素的估算会显得乐观,做出的规模估算往往小于实际值；项目管理人员为了控制进度,保证项目的按时完成,有意识地压缩时间进度,在估算时对部件的估算也会相应偏小；而编码人员由于负责做这些部件的具体实现工作,希望能在尽可能长的时间完成单位工作,故在估算的时候有意识地将部件规模估计偏大以在后续的时间安排中排出更多的时间计划。

2.4激励要素

在PROBE方法开始实行的初期,目的在于培养个体良好的软件过程习惯。在这个阶段,应该激励那些严格按照PROBE方法流程进行个体改进的人员,而不必在意估算结果如何精确。当软件工程师接受这个过程后,就习惯接受计划规划的思想,在概念设计阶段会考虑软件的局部架构,带动个体软件设计能力的提高以及相关技术和工具的使用,不经意间极大提高个体生产效率,这时就可以迫使那些最后接受PROBE方法的人为了追赶平均绩效,不得不采取这种方法。在接下去的第三阶段,当PROBE方法开始普遍使用后,才将注意力集中到规模估算的准确性上来,对于提供有效估算部件、对PROBE方法提出改进意见的人员实行激励。

3　改进的PROBE方法模型

通过上述的研究,最终建立一个改进的PROBE方法模型,具体示意如图2所示。

图2　改进的PROBE方法模型

1) 概念设计。根据设计模式思想,利用UML工具标识类之间的关系；利用数据库设计工具标识数据库元素；明确文档内容和文档之间的关系。并将这些类(或者细分到类的方法)、数据库元素、文档进行部件编号。

2) 获取满足五个标准要求的proxy,并产生规模相关表。规模等级的产生如下所叙。

(1)将部分规模除以该部分包含的项目数得到每个项的规模；

(2)将这些项规模分成各个功能类别的规模；

(3)对于每一个规模值,算出它的对数:ln(Xi);

(4)计算这些对数的平均值ln(Xi)avg；

(5)由平均值得出各个对数值之间的差:

Var=[1/(n-1)]Sum[ln(Xi)-ln(Xi)avg]2

(6)得出标准差σ；

(7)计算对数范围:ln(VS)=ln(Xi)avg-2σ,ln(S)=ln(Xi)avg-σ,

ln(M)=ln(Xi)avg,ln(L)=ln(Xi)avg+σ,ln(VL)=ln(Xi)avg+2σ

(8)计算规模范围:VS=eln(VS),S=eln(S),M=eln(M),L=eln(L),VL=eln(VL)

3) 新增部件规模。输入部件的名字、项的数目和相关的规模。对于每一个部件,从相应的规模表中取得每项的规模,用这个值乘以项数,并输入到估算规模中；在任何新可重用的附加的估算规模后加上星号。开发之后,度量并输入每个新部件或新部件项的实际规模和新部件的项数。

4) 基础和重用部件规模。对于基础部件,度量并输入基础规模,估算并输入对基础程序的删除、修改和新增的规模开发之后,度量并输入基础程序和任何删除、修改或新增的实际规模。对于重用部件输入每个不修改的重用部件的名字和每个不修改的重用部件的规模,开发后输入每一个不修改的重用部件的实际规模。

5) 估算非编程任务。这已在前面专门叙述,这里不再展开。

选取的proxy需要满足前面叙述的五个标准,就是合格的proxy。

6) 选择规模估算规程方法。

(1)确定新增规模A=新增基础代码BA+部件附加PA；

(2)估算代理规模E=A+修改代码M；

(3)确定规模估算规程方法:分析有用的数据并选择合适的PROBE估算方法。

7) 根据线性回归方程确定项目规模。

(1)如果选择的是前面提到的PROBE 1方法或者PROBE 2方法,计算相系数r；

(2)按照PROBE规程计算β0,β1的值；

(3)使用规模回归参数和估算代理规模计算计划新增和修改规模P=β0+β1*E；

(4)计算总的估算规模T=P+B-D-M+R；

(5)估算总的新的可重用的规模NR,用*号表示；

(6)计算并输入预测区间；

(7)计算预测区间的上限UPI和下限LPI；

(8)列出计算预测区间的可能性百分比(70%或者90%)。

4　改进的PROBE方法模型的实证分析

项目是某储运公司委托开发的信息系统,系统构架采用B/S和C/S的混合构架模式客户端系统是个以财务为核心,以业务为导向的运输管理信息系统,实现企业信息管理、车辆信息管理、车辆维修管理、司机信息管理、薪酬管理、运输业务管理、货代业务管理、事务提醒、业务数据汇总统计和报表打印、参数设置、数据库备份还原、用户权限管理十二大块功能。

4.1确定设计模式

目前有五个历史项目在功能和规模上都是相近的,其中前四个采取的项目开发方法是一样的,看起来似乎选取它们中的最后一个是最理想的选择。但是观察发现,最后一个项目与前四个项目不同的原因是组织内在这个项目之前发起变革,为了解决代码复用性和开发流程的规范化,对系统的架构进行了彻底改变,当然包括业务层的类发生了巨大的变化。基于上述原因,采用这个项目作为历史数据的依据。核心部分即业务操作部分的UML活动图与类、方法的关系如图3所示,部件被清晰地分解,考察部件的复杂图也有了依据。

图3　UML活动图

4.2获取proxy并产生规模相关表

首先考察(规模,时间(小时))的关系。根据历史数据选取15组,分别如下:

(50,1.50),(125,5.00),(223,9.92),(297,11.25),(426,13.75);

(342,7.33),(652,16.67),(465,15.25),(93,3.50),(514,14.50);

(143,4.67),(347,13.50),(537,16.50),(378,12.25),(165,5.50)。

又∑xi=4757,∑yi=151.09；求得相关性r=0.86。

显著性t=|r|sqrt(n-2)/sqrt(1-r*r)=6.31,在t分布表中查询95%一列,因为n=15,自由度d=13,6.31>2.182,所以显著性小于0.05。

由此说明时间和规模是显著相关的。

然后考察估算规模与实际规模的关系。如果历史数据即上述基于相同设计模式的项目的估算规模与实际规模存在显著的相关关系,结合前面得出时间和规模显著相关的结论,则认为这些proxy是符合标准的。需要注意的是由于设计模式保持严格的一致性,因此现有项目24个部件与之前项目的16个部件在系统中的功能地位是近似的,因此可以作为对照,所得的结论才有参照意义。

选取历史数据(估算规模,实际规模)的数据如下:

(20,28),(25,37),(55,78),(35,25),(45,62)；

(60,73),(55,74),(30,27),(60,47),(15,21)；

(40,58),(35,48),(30,51),(55,82),(30,41),(20,35)。

表1　相关性计算数据表

表2　相关性计算数据表

又∑xi=610,∑yi=787；求得相关性r=0.83；同理显著性小于0.05。

PROBE估算方法将历史规模数据根据工作类型划分成多个类别,这样如果知道所有之前开发的关于某部件的规模,就能够推测出类似的某部件的规模,制定一张规模相关表(表3),将规模数据划分为很小(VS)、小(S)、中等(M)、大(L)、很大(VL),这样可以为判断部件规模提供一个初始结构。

表3　部件规模表

4.3确定新增部件

经过分析,发现主框架、数据基础访问层、数据持久层等通用类的基础部件共计代码1445行,都无需新增和删除,需要在主框架修改12行。重用部件是关于报表操作的类。基础和重用部件如表4～表6所示。

表4　基础部件估算值

表5　基础部件实际值

表6　重用部件估算值和实际值

在本项目中存在已定义的过程、过程度量和历史数据,因此不需要考虑非编程任务。在本项目中有估算代理规模和实际程序规模,且r>0.7,因此采取PROBE 1方法。

根据上述分析得出的数据,可以利用PROBE 2方法的线性回归方法计算规模,如表7所示。

表7　PROBE方法计算规模

从这个实证中可以看出,PROBE方法利用历史数据进行软件规模的估算,在下次的估算中这次的实际值将影响下次的估算值,不断重复迭代,使线性回归方程日趋合理,不断提高软件规模估算的准确度。

5　结语

PROBE是一种简单的基于代理的软件规模估算方法,它是基于软件工程逻辑和统计方法之上提出的,本文对一般的PROBE方法进行了改进。改进的PROBE方法简单易用,能够在较短的时间内,利用方法对软件规模进行估算,得到规模估算的结果。

[1] 胡云龙.软件规模度量方法介绍[J].计算机时代,2006(7):17-18.

HU Yunlong. Introduction to Software Scale Measurement Method[J]. Computer Era,2006(7):17-18.

[2] ZHANG Junguang, ZHAO Yumei. Study on Top-Down Estimation Method of Software Project Planning[J]. The Journal of China Universities of Posts and Telecommunications,2006,13(2):108-111.

[3] 刘泽星,李建华,费耀平.软件规模评估方法的研究与应用[J].计算机工程,2002,28(12):113-114.

LIU Zexing, LI Jianhua, FEI Yaoping. Research and Application of Software Scale Assessment Method[J]. Computer Engineering,2002,28(12):113-114.

[4] 唐林燕.COCOMO估算模型改进研究[J].微电子学与计算机,2006,23(12):58-60.

TANG Linyan. Research on COCOMO Estimating Model Improvement[J]. Microeconomics & Computer,2006,23(12):58-60.

[5] 张维明,刘忠,肖卫东,等.信息系统建模[M].北京:电子工业出版社,2002:160-176.

ZHANG Weiming, LIU Zhong, XIAO Weidong. Information System Modeling[M]. Beijing: Publishing House of Electronics Industry,2002:160-176.

[6] 王宏宇,党齐民.面向对象软件项目估算方法的研究[J].计算机与数字工程,2005,33(7):338.

WANG Hongyu, DANG Qimin. Research on Object-oriented Software Project Estimation Method[J]. Computer Technology and Development,2005,33(7):338.

[7] 周杨,吴海涛, 张栋伟.扩展的用例点估算方法[J].计算机技术与发展,2006,16(12):64-66.ZHOU Yang, WU Haitao, ZHANG Dongwei. Extended Use Case Point Estimation Method[J]. Computer Technology and Development,2006,16(12):64-66.

[8] 夏正煜,孙蕾.面向对象软件规模估算方法的研究[J].电脑知识与技术,2005(15):12-15.

XIA Zhengyu, SUN Lei. Research of Object-oriented Software Size Estimation Method[J]. Computer Knowledge and Technology,2005(15):12-15.

[9] Costagliola G, Tortora G. Class Point: An Approach for the Size Estimation of Object—Orinted Systems[J]. IEEE Transactions on software engineering,2005,31(1):52-74.

[10] Kenneth E.Kendall, Julie E.Kendall. System Analysis and Design[M]. Six Edition. Beijing: Tsinghua University Press,2006:580-593.

[11] 魏永合,张力争.软件规模估算在RAD系统中的应用与改进[J].2003,22(3):36-38.

WEI Yonghe, ZHANG Lizheng. An Application and Improvement of Estimating Software Size in RAD System[J]. Journal of Shenyang Institute of Technology,2003,22(3):36-38.

[12] 魏蔚,石柱,邹军.软件项目估算与测量的工程实践[J].航天控制,2006,24(5):58-62.

WEI Wei, SHI Zhu, ZOU Jun. Practices of Software Project Estimation and Measurement[J]. Aerospace Control,2006,24(5):58-62.

[13] 刘克青,廖建新,张俊光.软件项目策划中的工作量估算方法探讨[J].计算机工程与应用,2004,27:90-92.

LIU Keqing, LIAO Jianxin, ZHANG Junguang. Study on Effort Estimation Methods in Software Project PLanning[J]. Computer Engineering and Applications,2004,27:90-92.[14] Asutina S, NewtonB A, Steeleb J, et al. Modeling and managing project complexity[J]. International Journal of Project Management,2002,20(3):191-198.

[15] Abdomerrovic M, Blakemore G. Project process interactions[J]. International Journal of ProJect Management. 2002, 20(3):31323.

Application of Improved PROBE Method Model in Software Project Scale Estimation

YANG Yong

(Xiangyang Vocational and Technical College, Xiangyang441050)

In combination with the experience in the actual project to improve the PROBE method, and an improved PROBE method model is put forward. Model takes improving the PROBE method as the core to understand the needs analysis and conceptual design, scale related tables, determine the size of the new parts, determine the basis and reuse of parts size, estimate the non programming tasks, select the appropriate proxy, select the size of the standard method, according to the linear regression equation to determine the project size and other eight stages of how to get, how to write and organize, when to enter the estimate, the specific process gives a comprehensive guide.

PROBE method, component size, software size, linear regression

2016年4月17日,

2016年5月28日

杨勇,男,讲师,研究方向：网络综合布线和物联网。

TP391

10.3969/j.issn.1672-9722.2016.10.008