软件错误估算（共7篇）
软件错误估算 篇1
1 引言 (Introduction)
当前, 随着互联网时代的蓬勃发展, 各类软件层出不穷, 数不胜数的软件在互联网这趟高速列车上蜂拥而至。并且, 随着用户需求的不断增加, 软件设计和开发过程中的复杂性不断增高。为了确保软件质量[1,2], 应该开展更加行之有效的软件测试[3,4]。计算机之父图灵认为软件测试是软件正确性确认的一种方法。因此, 软件测试应尽力找出软件设计的失败与不足之处, 并加以纠正, 确保软件最终设计目标的实现, 以此不断地提高软件质量。1983年, IEEE对软件测试给出了如下的定义:使用人工或自动手段来运行和测定某个系统的过程, 其目的在于检验它是否满足规定的需求或是确定预期的结果与实际的结果之间的差别[5]。但在测试之前需使用良好的软件错误估算方法[6], 帮助测试人员发现错误, 使预期结果和实际结果之间的距离不断缩小, 是软件工程过程有更好的可控性。
软件中错误数量的估算不准, 对软件质量的改善就越不确定, 人们发现一个错误越晚, 修正的难度越大, 造成的损失也就越大。所以软件的测试工作越早开始越好, 软件错误数的估算越准确越好。因而, 良好的错误估算模型对于提升软件质量犹如“银弹”般至关重要。
回首过往, 自软件行业诞生以来, 测试人员寻找良好的估算错误方法的脚步一直没有停下来。从20世纪70年代开始到80年代中期是软件可靠性建模技术的快速发展时期, 这段时间产生了上百种的软件可靠性模型。1972年Mills将种子模型 (Seeding-Model) 运用到了软件错误数估算中[7]。在过去, 种子模型是估计软件错误数量的重要手段之一, 该方法模仿估算池塘中鱼尾数的方式, 在开始排错以前被测软件中含有的错误数x。在不让排错程序人员知道的情况下, 在程序中置入y个错误 (相当于为y条鱼尾作标记后放回池中) 。经过一段时间的软件测试, 所测得的软件错误可以分成两类, 一类是属于置入的错误X, 另一类是非置入的错误Y。通过构造其比例关系式, 来成功的估算出全部的错误数量。该方法具有简单直观的优点。但是该方法全过程不能自动实现, 并且, 无法保证人为置入的软件错误的规律与软件内实际存在的软件错误的规律一样或相似。后来, Hyman改进了Mills的估算错误的方法[8], 该方法可以运用蒙特卡罗 (Monte-Carlo) 模拟方法[9]快速计算来解决这一问题, 因而, 这一模型被软件行业广泛应用。近来, 苗洋[7]通过对Hyman估算公式的变形, 构造出估错数量与时间之间的函数, 但是, 该方法由于其较难操作, 很难应用于实际的软件估错当中。
事实上, 软件测试中估算错误数量的过程会受到诸多外界因素的干扰。比如, 当两组测试人员不独立且高度相关时 (这也是经常出现的情形) , 其测得的相同错误数会偏低, 从而使估算值比真实值偏高。并且, 这种相关性越强, 估算值的偏离程度越大。
为了尽可能缩减这一偏差, 改善Hyman估算方法的质量, 我们提出一种相似度系数 (p-值修正法) 来改善估算值的准确性。该方法通过度量测试人员之间的相关程度, 运用“惩罚”的思想, 修正估算结果, 对软件中的错误数做出更加精准的判断。为此, 我们在文中引入对Hyman法的概率推导过程[6], 帮助读者更好的理解p值修正法的整体思想。
2 估算软件中错误数量的方法 ( Method of estimating software error number)
2.1 Hyman估算法
假设A组和B组两组测试人员互相独立地对某个软件进行测试, 我们记A组人员和B组人员测得的错误数分别为i和j个, 两组测试人员共同测试出的错误数为k, 软件错误数的估算值与这三个量的关系如下:
式 (1) 即为著名的Hyman估错方法表达式。该模型简单易懂, 但在排错人员进行软件测试之前, 通常要做如下几个假设:
(1) 两组测试人员之间是相互独立的, 并且在测试过程中没有相互交流。
(2) 排错时, 不再引入新的错误。
(3) 排错的过程随机进行。
(4) 在排错过程中错误特性不变。
(5) 所有软件缺陷的触发概率都是相等的。
如果上述某条假设不成立, 均会在一定程度上降低最终结果的准确性。下面我们用概率模型的手段分析该问题。
一方面, 由于实际生产生活当中, 估算软件错误数目带有未知性和不确定性, 因此, 我们可以将这一过程抽象为一种概率问题;另一方面, 这为了更好地帮助理解本文提出的优化方法, 引入针对Hyman法问题求解的概率模型, 记事件Z为“A组人员和B组人员检测出的相同错误的数量恰好为个”, 所以可有:
其中n为估算个数, 也就是说我们希望找到最佳的, 令, 研究函数的单调性。若, 则函数单调递增;若, 则函数递减。
将 (2) 式带入当中, 推得
即当, 函数递增;当, 函数递减, 即, 这也证明了采用Hyman估错的可靠性。
但是, 当两组测试人员具有较高的相关性时, Hyman方法会有较大的估算误差, 如下面场景。
场景1:假设M公司的某款软件中存在100个错误, A组和B组两组测试人员在对该软件中测试时, 分别得到了i=20和j=20个错误。理想情况下, 如果两组测试人员之间完全独立, 则测出的共同错误数k的理论值为4, 此时用式 (1) 估算的结果为100恰好与实际值相等;但如果两组测试人员之间不独立且有正相关性, 则检测出的共同错误数k大于4, 比如k=4。此时根据公式 (1) 的估算值为40, 与实际只有较大偏差。可以看出, 独立性越差, 偏差就越大。
经过对软件测试行业现状的分析和以往软件测试的经验, 我们发现场景1中出现的测试人员的相关性问题会在很大程度上左右最终的估算结果, 从而导致了较大的估算误差。人员相关因素与人员的背景密切相关。例如, 长时间共事的两组测试人员, 他们在纠错认知方面势必具有相似之处, 这将在一定程度上破坏Hyman模型中的假设, 使估算值向低偏离真实值。
从场景1的结果也进一步看到, 当A组和B组人员之间的相关性越小时, 越能提高估算结果的精确性。然而, 由于两组测试人员得到的共同测试错误的数量已经是一个定数且不能改变, 因此, 我们需要找出一种策略去弥补这种不足。基于上述考虑, 本文提出了p值度量法 (用p值来惩罚相关程度) 来改进Hyman测试法。
2.2 改进Hyman法 (p-值修正法)
p值修正法以人员之间的相似程度等一些外在因素为度量依据, 能够在一定程度上提升软件错误数量估计值的准确度。决策人员可以根据测试人员之间的不同特性, 来及时的更换p值 (结合“专家意见法”[10]对人员相关因素的相关程度进行打分) 的大小, 这将对最终估算结果的正确性起到巨大的帮助。
为了让当前软件错误数量的估算值更加接近错误数量的真实值n, 我们有必要重新确定一个估计值, 它可以被如下定义
其中, 1>p>0, 观察 (4) 式, 可以看到p值其实就是一个在0—1的惩罚系数, 这个惩罚的思想便是p值修正法的核心思想, 该思想旨在消除两组人员不独立造成的影响, 在干扰和估值之间做一个平衡。使获得的新估算值较好的接近软件错误数的真实值。其算法流程如图1所示。
本文认为, 在实际软件测试当中, 测试人员的先决条件 (人员相关程度) 能够影响测试过程中测出的共同错误数量。这些先决条件包括测试人员的学习经历和工作背景等情况, 具体而言, 对于衡量这个先决条件, 主要通过几个方面进行:
第一, 测试人员之间的相关性与测试人员之前所处的环境 (地点) 有关。例如, 两组人员之中存在长期共事的情况, 因为他们现今共同工作, 对某一些类型的错误具有相同认识, 使得测试结果中共同检测出的错误数量变多。再比如, 两组人员中存在毕业同一院校的, 他们之前的学习氛围相近, 受到的同种技巧教育的影响偏深, 也会提高对软件中某几类错误具有共同认识的可能性, 从而也导致共同检测错误数量值变大。
第二, 人员相关性施加于某项因素的时间相关。时间越长, 相关性越大。
因此, 我们立足于当前软件行业的发展现状和趋势, 并模拟“专家意见这一过程”, 总结出测试人员相关性的主要类别, 分别是:
(a) 测试人员共事年限长短。
(b) 测试人员工作年限相似度。
(c) 测试人员毕业院校相似度。
(d) 测试人员学历相似度。
采用低、中、高作为相关程度的衡量标准, 并且经由“专家意见法”, 针对人员相关因素的相关程度进行打分, 其取值如表1所示。
具体地, 针对相关因素类型Qi而言, 分为情况si (如表2所示) , 并且每种情况si用相应的相关程度值pi来权衡。表中的各类情况si随值i的增加, 其相关程度也在增加。
本模型规定, 在评价测试人员相关性时, 如果组内存在相关因素类型Qi的复合情况时, 只保留相关程度值最大的一种, 这称为复合情况保留策略。相应地, pi为si的对应值。
在上述讨论的基础上, 我们将p值修正法应用于场景1描述的问题中。当M公司A、B两个小组各自测得的错误数和共同测得的错误数分别为20、20和10时, 根据Hyman估算法得到了总错误数的估算值40, 与真实值100有较大的偏差。
但通过对测试人员内部的评价, 可获得A、B两个小组人员的信息。其中相关类型Q1出现了情况s1、s2、s3 (两组人员中共事年限最长为5年, 根据复合情况的保留策略, 取最相关情况s3, 后同) ;相关类型为Q2出现了情况s1、s2 (两组人员中从业年限差最小为1.5年, 取最相关情况s2) ;相关类型为Q3出现了情况s1、s2 (两组人员中无共同院校毕业, 但有相似院校毕业情况, 取最相关情况s2) , 相关类型为Q4出现了情况s2、s3 (两组人员中有同为硕士毕业的情况, 即学历差为0, 取最相关情况s3) 。那么, {Q1, Q2, Q3, Q4}分别保留了情况{s3, s2, s2, s3}, 对应了相关程度值{p3, p2, p2, p3}={0.8, 0.4, 0.4, 0.8}, 最终的p值为
上述结果带入 (4) 式, 得到p值修正法的估算结果为2.5 =100。可以看出, 这个结果比较接近真实的软件错误数估算结果。
通过表1中的p值惩罚系数, 能够将Hyman估算法的偏离值复原, 得到的数据也就更加可靠。另一方面, 通过“专家意见法”, 不同公司可以根据自己的实际情况, 调整表2的赋值, 使得p值更加符合公司和企业的状况, 降低因错误数估算偏离造成的软件工程风险。
3 结论 (Conclusion)
软件测试是软件工程中至关重要的环节, 而软件错误数的估算是实施有效的软件测试的前提。估值过高或估值过低都会影响软件工程的工期, 造成资源投入的不足或浪费。我们提出的p值修正法是对传统的Hyman估算法的改进, 克服其因人员的相关性而造成的估值偏差。该方法通过简单的p值修正即可使估算值与真实值之间的偏差大幅下降, 并具有简单易懂、实施方便和高效快捷等优点, 为降低软件工程风险、保证软件工程顺利实施提供了良好的估算机制。
摘要：软件内部错误数估算是降低软件工程风险、保证软件工程顺利实施的重要途径。在当前软件测试中, 项目管理人员采用传统的估算策略, 但是估算效果往往受制于测试人员独立性等诸多因素的干扰。其中, 具有相似背景的测试人员对于测试过程会具有相似认知, 这种不独立性使软件错误数的模型估算值往往比真实值偏低。类似潜在因素在软件错误数估算中大量存在, 降低了估算准确性。因此, 本文基于传统的Hyman估算法提出了一种改进的度量方法 (p-值修正法) , 该方法能有效排除组间人员相关性对Hyman模型的干扰, 能在很大程度上提高估算的准确性。同时, 该方法易于用户理解、简便易行、可靠性高, 可降低软件工程风险, 对决策人员有很大帮助, 适合普遍推广。
关键词：软件测试,软件错误估算,Hyman估算法,p-值修正法
参考文献
[1]聂芸.基于CMMI的软件质量保证过程管理[J].软件工程师, 2015, 18 (8) :10-11.
[2]Baker E R, Fisher M J.Software quality program organization[M].Prentice Hall PTR, 1998:115-145.
[3]赵丽莉, 金学军.软件性能测试面面观[J].软件工程师, 2006 (11) :40-42.
[4]陈明.软件工程学教程[M].北京:科学出版社, 2002.
[5]IEEE Standard Glossary, IEEE Std 729-1983.
[6]李世慧, 惠韶文.计算机软件中错误数量的一种估算方法[J].佛山科学技术学院学报:社会科学版, 1995, 13 (2) :52-53.
[7]苗扬.软件可靠性测试与评估方法的改进[D].上海交通大学, 2010.
[8]刘继华.基于风险的Web应用软件测试方案研究与应用[D].太原理工大学, 2006.
[9]马海云, 党建武.基于蒙特卡罗的软件测试技术的研究与实现[J].郑州大学学报 (工学版) , 2007, 28 (4) :55-58.
[10]戴怡, 等.面向数控系统可靠性评估的先验信息融合方法—专家打分法[J].天津职业技术师范大学学报, 2012, 22 (3) :6-8.
软件成本估算研究 篇2
关键词：软件成本估算,工作量
1 引言
我们需要明确为什么要做软件项目预算。首先随着软件技术的快速改进，软件系统规模也不断扩大，其复杂程度也相应地日趋加大，大量的软件项目进度延期、预算超支和质量缺陷成为典型的软件危机。软件项目是不同于一般工程项目的项目类型。受用户需求，开发方式的影响很大。没有明确的预算，会导致软件开支的不可控制，随着项目的进行，开发放要承担的风险也会增加。另外如果没有预算，更不可能与客户达成开发协议。没有人会委托别人做一个自己都不知道要花多少钱才能完成的项目。
2 软件成本估算的内容
软件项目的生命周期包括需求分析、概要设计、详细设计、编码、软件测试、软硬件安装调试、软件培训和软件运行维护等阶段。软件项目的成本估算以整个周期的花费为依据，所以软件项目成本估算主要包括软件开发成本估算和软件维护成本估算两部分内容。
2.1 软件开发成本
项目属性是软件开发成本估算中的重要信息，而且包含许多因素。主要是估算所需投入的经费开支，包括建立开发环境所需的软件和硬件成本以及支付项目参与者的工资
1)硬件的购置费
如服务器、PC机、网络交换机等。
2)软件的购置费
软件购入费用即购入作为基本构造的软件开发支援工具时的通用模块，以及同其他软件共享所付出的费用，均属于软件购入费用。如操作系统软件、数据库系统软件、开发工具软件等。
3)人工成本
直接人工费用包括系统分析员、程序员、系统工程师等，他们承担系统实施的具体技术工作，是软件工作量的主要构成部分主要是项目组成员所花费的工作量及企业正常发展的必要支出。如软件的分析/设计费(含系统调研、需求分析、系统设计)、实施费(含编程/测试、硬件购买与安装、系统软件购置、数据收集);税务、质量成本等。
4)专有技术购置费
5)商务费用
这些费用包含项目的管理人员、勤务人员等费用支出，这部分费用可根据投入的人数、及人员平均工资计算，也可根据经验系数由直接费用计算得出，另外也可包括其他应分摊在该项目上的费用如办公费、差旅费、会议费、交通费、培训费等。
6)其它不可预见费用
这些费用都是在项目确定后，根据具体情况和以往经验而确定的直接消耗在该项目上的费用，一般与软件的开发工作量无关或关系不密切如咨询费、工期延误费等。
另外，从项目整体来看，好的项目预算应该包括团体预算与小组或个人预算两部分，好的项目经理应该了解自己的团队，对突发事件等的考虑应该放在项目预算之中，然后将项目的开支细化到小组乃至个人，这一点看似多余，但是却很有必要。比如在实际的开发过程中，由于为了缩短工期而招收新的程序员，这就需要对新程序员进行培训。新程序员消耗的团队成本是要考虑在内的。这也就是传统意义上的peron-monthes所不能完全表达的部分。
2.2 软件维护成本
由运行费、管理服务费及维护费(纠错性维护费和适应性维护费)构成。
软件成本估算是对将要开发的软件项目所需的工作量和工作进度做出预测，不是仅仅停留在资金上。在软件开发项目中，除固定资产投资外，人的智力因素是主要部分;软件成本在很大程度上是支付给开发人员脑力劳动的费用，而这部分成本因开发进度不同存在相当大的差别。
3 软件成本估算常用的方法
最早的软件成本估算可以追溯到20世纪60年代，到现在已历经了40多年的发展，各个方面的研究都已经比较深入，产生了很多种估算方法，目前普遍应用的有以下几种方法：
3.1 专家估算法
专家判定技术，包括从毫无辅助的直觉到有历史数据、过程指引、清单等支持的专家判断，是根据已有的类似项目经验以及该领域的专家经验知识进行估算，由多位专家进行估算后取平均值，估算的结果比较准确，目前应用得最为广泛。常用的专家判定技术有Delphi技术和作业分解结构技术(Work Breakdown Structure，简称WBS)。专家估算法的优点是简便，缺点是对专家水平太过依赖，易造成较大误差。专家判断是一个非常普遍的方法，其主要判断标准是，估算工作由一个被认为是该任务专家的人来控制，并且估算过程的很大一部分是基于不清晰、不可重复的推理过程。
3.2 算法模型法
基于模型估算技术大多数是采用经验公式来预测软件项目计划所需的成本、工作量和进度。直接利用经验模型(如Putnam、COCOMO)预测工作量、进度数据和成本。但目前没有一种估算模型能够适用于所有的软件类型和开发环境，这些模型对每个不同的环境都需要进行校正，而且即使校验后，还存有大量的可变精度级别因此最好慎用此法的估算结果。
3.3 类比估算法
类比方法通过对一个或多个已完成的项目与新的类似项目的对比来预测当前项目的成本与进度。通过将项目与已完成的类似项目进行比较，找到对应处的差别，并估算各个差别造成的影响，从而导出开发项目的总成本。该方法的优点是可以提高估算的准确度，缺点是差别难以界定。
3.4 自顶向下估算法
估算人员参照经验估算要开发的软件的总成本，然后按步骤和工作单元将之进行分配，称为自顶向下估算方法。它的优点是估算量小，速度快;缺点是估算成本准确性不高，易造成遗漏。
3.5 自底向上估算法
切分开发任务，估算每一个子任务所需花费，然后相加算出总数。估算结果往往偏低。
3.6 动态分析方法
不同于其它估算技术，它认为软件项目工作量和成本因子在软件开发过程中不是静态的而是动态变化的，它主要应用于一些软件工程的成本估算模型中
4 结束语
由于软件成本估算中诸多因素相互影响，对成本作用的机理和定量关系上无法给出的问题，因此对于成本的估计准确性不定。尤其是我国软件业仍处于发展的相对初级阶段，影响因素更为复杂。另一方面，作为一个软件项目不但要考虑其成本，还要考虑其收益，而目前关于软件收益分析方面的研究较少。软件成本收益(投资回报率)分析的研究已开始逐渐引起软件研究人员和商业分析研究人员的重视，这不仅有助于进一步提高成本估算和效益分析的准确性，而且有助于进一步提高软件项目管理的效率。因此，软件开发成本估算与软件收益分析技术以及软件能力成熟度模型CMM研究的结合成为软件估算技术的发展方向之一。
参考文献
[1]Kishore S,Naik R.软件需求与估算[M].姜路,丁一夫,柳剑,译.北京:机械工业出版社,2004.
[2]Wittig G E,Finnie G R.Using Artificial Neural Networksand Function Point s to Estimate4GL Software Develop2ment Effort[J].Aust ralian Journal of Information Systems,1994,1(2):87294.
[3]石柱.软件工程标准手册[S].北京:中国标准出版社,2004.
[4]张海藩.软件工程导论[M].4版.北京:清华大学出版社,2003.
[5]Forrester J W.Indust rial Dynamics[M].Cambridge,MA:MIT Press,1961.
[6]王强军.基于类比方法的软件成本估算[J].中国科技信息,2008(5).
[7]甘早斌.软件开发成本估算技术综述[J].计算机工程与科学,2005(6).
基于WBS的软件项目成本估算 篇3
随着信息技术的突飞猛进, 软件产业的规模也越来越大, 软件的价格越来越高, 因此软件成本的估算受到相关人员的重视。 软件成本管理的目的是确保在批准的预算范围内完成项目所需要的各项任务。 软件价格的估算不是一门精确的学科, 它受到许多因素的影响, 包括技术影响、环境影响和变更的程度等等。 因此, 软件项目如果要开发成功, 关键在于要使用科学准确的软件成本估算方法。
二、关于软件项目的成本估算方式
估算软件项目的成本是对开发新的软件项目进行总的成本统计和工作量预测的过程, 能够计划和预估整个软件项目将花费的资金。 估算软件项目的成本可以通过多种途径, 主要的估算方式有以下几种:
1.专家鉴别法:专家鉴别法主要是运用于软件的开发前期, 是依靠领域里面相关专家的经验, 对软件的开发成本估算后, 从而实施打分。 相关专家对软件估算得出多个数值, 再想办法将多个值综合成最后的一个估算值。 该方式的优点在于预测速度快、成本花费低, 而缺点在于得出的估算值不准确, 与实际相差较大。
2.比较类推法:比较类推方法在评估同历史项目的应用范围和环境方面类似度较高的项目中运用较多, 开发的新软件通过和历史项目进行比较后, 推算出大致估算值。 它具有简单易行、花费少的优势, 但具有一定的局限性, 评估结果准确性差。
3.从顶至下:从顶至下进行估算指的是从整体开始, 对整个软件项目估算, 运用曾经的项目完成工作经验, 对项目的总费用和总工作量进行计算和预测, 从而根据一定比例发放到局部的组成中。 自顶向下估算路线虽然简单, 但估算精度较差, 通常在项目的初期或信息不足时进行。
4.从底至顶:从底至顶的估算过程指的是逐渐细化有待开发的项目软件, 细化到具体的工作量, 由专门的负责人对工作量进行估计, 给出估算值, 把局部工作量统加为总工作量。 该方法所得的结果比较精确, 并且项目所设计的活动资源的数量更清楚, 缺点在于估算工作量大。
5.算法模型:算法模型成本估算主要采用经验公式来预测软件项目计划所需的规模、工作量和进度, 进而估算开发所需的成本, 它为决策者提供指导。 没有任何一种模型能完全反映软件组织及项目的特点、实际开发环境和相关人员的因素, 因而使用模型估算成本时要谨慎。
三、WBS-工作分解结构
软件规模是软件成本的主要因素, 是成本估算的基础, 软件规模的估计开始于软件的分解。 WBS中文即工作分解结构, 是通过规定的原则和方法来分解一个软件项目, 层层分解, 分解至无法分解, 先把项目分解变成任务, 任务往下细化为工作, 再往下把一个个具体工作派发给工作人员的普通生活中。 最后的结构是细化成“可交付成果”, 该组织确定了项目的整个范围。
不管用怎样的方式对软件项目实施估算, 都应建立在具体掌握了工作量的基础上, 最佳的方法是采用WBS-工作分解结构。 不同的工作分解将得到不同的项目成本, 如果工作分解不合理将使得工作效率无法提高, 项目的运营成本居高不下。 项目的开发费用受软件的难度影响, 同时项目管理方法及人员的能力也直接影响开发成本的高低。
WBS的原则性分解: 对一个主体性的软件项目分步骤细化, 原则上必须要把项目分解至无法继续分解, 细化至把一个个具体工作派发给每一位工作者的生活中执行。 每个工作要具体把人员以及资金、时间安排好。 WBS的每一项都只有一个人负责, WBS必须与工作任务的实际执行过程一致。
四、基于WBS的成本预测
项目的成本预测是基于WBS分解的基础, 借助WBS的分解方法对一个抽象不具体的软件项目分步骤合理细分, 细化至把具体工作时间、工作量派发给每一位执行, 在运用WBS后估算成本。 “超市管理系统”是一个典型的在运用WBS的基础上进行成本估算的软件项目, 具有很高的探究价值。
“超市管理系统” 的需求: 用户提到的需求比较抽象, 通常给出该系统需要完成的目标。 这种项目目标并不能帮助完成成本的预估和系统开发工作。 首要任务是要做好WBS分解, 接着确定好工作包, 最后才能实施成本的估算工作。 在软件项目中, 对需求做好详细分析是必不可少的, 要编写需求规格说明书, 该说明书中将详细地描述实现该软件系统的所有功能需求。 例如:销售信息管理功能, 在需求规格说明书中将描述出该功能模块完成的功能;销售信息管理所包括的商品名称、类型、数量、出售价格、销售人员等相关信息。
描述好实现该软件系统所有功能需求只能代表我们弄清了要完成的任务, 而最重要的任务是要在需求规格说明书确定后深入分析怎么完成任务的问题。 如何通过软件系统实现文字上的描述, 如何对功能模块进行准确设计, 然后转变为系统管理体系结构图。 根据用户需求得出的超市管理系统结构图, 如图1 所示。
WBS的分解要素包括功能模块和功能点这两个子系统。 WBS分解奠定于需求规格说明书、系统结构图这两种基础上。 按照以前对项目的分解经验, 可以对功能模块的具体工作量做出估算, 在此基础上计算出系统里所包含的总的工作量。 首先, 可以根据项目的特征对超市管理系统进行自上而下的、WBS的第一层分解。 具体的分解流程包括五个阶段, 即需求分析阶段、结构设计阶段、编码阶段、测试阶段和安装与维护阶段。 第一层的分解结构如表1 所示。
通过第一层的WBS分解, 已经把系统的功能设计方面细化到子系统的具体范畴中, 每一个子系统又可以细分, 细分至功能模块, 继而细分成特定的功能点。 如果我们从第一层分解继续细化, 依据以往项目经验数据很容易估算出每一个功能模块的工作量。 第二层WBS分解如表2 所示。
通过WBS分解, 得到工作量信息、进度日期和人员分配等信息。
从上面的分解图不难发现, 开发这个系统总共需要60 个工作日, 开发该系统的人员如果支出每月4000 元的成本, 那么可以计算出该项目成本预算至少为8000 元。
五、结语
软件项目规模估算是软件项目成本估算的基础, 规模估算应基于WBS工作分解。 正确和合理地分解任务能提高成本估算值, 让估算更加准确。
摘要：由于软件商品的无形性、无损耗性和易复制性, 软件商品的价格不易确定, 软件项目的成本不易被估算。软件价格估算的准确度直接影响项目的盈利。本文以“超市管理系统”为例, 重点介绍基于WBS的成本估算方法, 以此提高成本估算能力。
关键词：WBS,成本估算,软件成本
参考文献
[1]覃征, 徐文华, 韩颖, 唐晶.软件项目管理 (第2版) [M].北京:清华大学出版社, 2009.
软件错误估算 篇4
随着信息化浪潮的到来,软件逐渐渗透到社会的各个行业,同时,软件的规模也是越来越大,越来越复杂。
在实施CMM的软件开发过程的改进中,软件估算是很重要的一步。可以通过开展软件估算工作来提高项目管理水平和改进开发管理过程,并提升企业的产品服务素质[1]。目前,通过对大量数据的调查发现,造成许多项目延期和超出预算的一个重要的原因就是估算不准。只有在正确的软件规模估算基础上才能得出正确的成本估算,进而使项目在我们的可控范围之内[2]。
2 软件规模估算的方法
2.1 几种软件规模估算方法
软件规模估算是贯穿项目整个生命周期的一种活动[3]。软件规模估算根据其实施的周期阶段性可以分为:初期规模估算、中期规模估算、后期规模估算三个阶段。
2.1.1 LOC估算方法
LOC(Line Of Code)代码行数是指所有的可执行的源代码行数,是软件开发者最早进行规模估算的方法之一。LOC方法是一种技术度量,因为它从开发者的技术观点出发而不是从用户的观点出发来度量软件。基于规模估算的LOC方法通常采用系统分解结构法、类比法和Delphi的Wideband法。
2.1.2 FPA估算方法
IBM的Albrecht于1979年提出了功能点FP (Function Points)方法。功能点分析(FPA)方法是从用户的角度出发,以软件功能性为尺度来度量和估算应用软件规模的一种流行方法。功能点方法的度量是所需功能性的数量,这些功能是根据用户需求和高层逻辑设计提供给用户的。
2.1.3 其他功能点拓展方法
软件估算的其他方法还有:Mark II FPA方法[4,5],COSMIC-FFP方法[6],NESMA估算方法,对象点方法,近似功能点,快速FPA计数,特征点方法,3D功能法等。
2.2 FPA与其他方法的比较
FPA、Mark II、COSMIC-FFP、3D功能点、Feature Points、对象点方法、近似功能点、快速FPA计数、NESMA估算方法都是以功能点作为规模估算的基本单位,而且都是在FPA的基础上进行改进和创新而得到的。因此,它们都是属于功能点阵营。目前的软件估算领域的两大阵营:一是LOC代码行估算方法的阵营,另一个是功能点估算方法的阵营。
2.3 FPA的计算方法
FPA(Function Points Analysis)是一种能够估算出软件项目规模的方法。用FPA估算的最终结果是若干个功能点(FP) 。FPA估算一个系统的规模的一般步骤如下:
3 软件规模估算模型改进
3.1 估算模型的改进
改进后的计算规则如表1所示:
3.2 对估算流程的改进
改进的估算流程图如图2所示:
4 估算服务模型的设计与实现
4.1 估算模型在Web 服务上的工作流程
Web 服务是一个软件接口,它描述了一组可以在网络上通过标准化的 XML 消息传递访问的操作。它使用基于 XML 语言的协议来描述要执行的操作或者要与另一个 Web 服务交换的数据。在面向服务的体系结构(Service-Oriented Architecture,SOA)中,一组以这种方式交互的 Web 服务定义了特定的 Web 服务应用程序。
本文将一个UML类图转化成符合自定义的抽象语法树规范的XML文件,因此,将面向对象功能点的计算作为一种服务是完全可行的。估算服务申请方与提供方之间的信息交换如图3所示:
4.2 服务模型架构图
图4为面向对象的功能点服务系统,主要提供基于Use Case和Class Diagram的软件规模估算的服务。而本文作为其中一个子系统,旨在将一个以UML类图为研究对象的软件规模估算模型置于Web Service上,使其整合成一个估算服务。
图5是基于类图的软件规模估算服务CDFPA(Class Diagram Function Analysis Point)的架构图,也是本文研究内容的实现形式。实现后的系统有三个特点:面向对象、自动估算、面向服务。
4.3 实验用类图
为达到验证的目的,本文设计一个类图6,该图包含UML的依赖、泛化、关联、聚合、实现等各种关系,是一个良好的实验用图。
其中,BaseClass的base3属性是private的;baseMethod2()是抽象类型。
为了验证该服务的准确性和有效性,在使用系统之前,我们先人工计算该类图所具有的功能点数,而后再跟实际运行的结果进行对比。数据处理功能部分结果如表2所示:
事务处理功能部分结果如表3所示:
其中,BaseClass 的baseMethod2()方法由于是抽象类型,本身没有具体的实现内容,而是由继承它的类去实现,因此该方法无功能点。
最后我们可以手工计算出该类图的UFP为:60.3功能点。
5 结束语
本文从传统的软件规模估算方法——功能点(FPA)方法出发,结合当前OOA、OOD环境,选取一种面向对象的功能点方法,以UML类图为输入对象,设计了基于UML类图的功能点自动估算模型,实现了无需人为手工输入各项参数的自动估算功能。实现了方法、自动估算、服务三者的整合。
虽然本文提出并实现了基于类图的软件规模估算服务模型,但仍有许多亟需改进之处:缺乏工业数据的校正;需要对历史经验数据的提取、反馈处理工作做进一步的细致研究,以增强模型的适用性。
摘要：本文从流行的规模估算方法中,将最为优秀的FPA方法作原型,结合当前面向对象的设计开发环境的特点,选取分析了一种将UML类图与FPA结合起来使用的估算方法,并针对其不足做出了改进。本文还提出了从UML类图到功能点的自动估算模型,并在此基础上进行了设计与实现。最后,本文提出估算服务模型,将估算作为一种Web服务。
关键词：功能点,软件规模估算,类图,Web服务
参考文献
[1]Roger S.Pressman著.梅宏译.软件工程:实践者的研究方法.北京:机械工业出版社,2005.
[2]唐德权.深度精耕———日本软件企业精义解读.北京:清华大学出版社,2004.
[3]Swapna Kishore,Rajesh Naik著.江路,丁一夫,柳剑锋译.软件需求与估算.北京:机械工业出版社,2004.
[4]http://ourworld.compuserve.com/homepages/softcomp/fpfaq.html.
[5]http://www.softwaremetrics.com/articles/Tichenor.htm.
浅谈软件项目的工作量和进度估算 篇5
1.1 软件项目工作量的度量
软件开发项目的工作量主要是指软件开发各过程中所花费的工作量。这与传统的其他行业不同, 软件的成本基本可以不考虑原材料和能源的消耗, 主要是人力劳动的消耗。另外软件也没有一个明显的制造过程, 它的开发过程具有明显的一次性开发过程的特征。因此, 软件开发工作量的估算, 应从软件计划、需求分析、设计、编码、单元测试、系统集成测试到验证测试整个开发过程所花费的工作量, 作为工作量测算的依据。
采用什么样的生命周期模型, 对使用什么样的工作量估算方法有很大的影响。实际上有些算法适合某一模型, 有些适合另一模型。采用面向对象技术为主的开发与传统的开发技术, 在工作量的估算上当然也不同。这些都需要我们根据软件开发的具体特点进行选择。
软件工作量估算的结果是项目任务的人力和需要的时间周期。在工作量估算时, 度量的任务需要时间是讨论以任务元素、子任务、项目任务为单位任务的需时, 它是计算成本、制度进度计划的依据。而在进度估算时, 单位任务的需时又是时间进度计划安排的基本数据来源。
1.2 软件项目工作量的估算方法
软件工作量的估算可以采用不同的操作方法, 以下是几种常用的方法。
(1) 自顶向下估算法。
首先对整个系统进行总工作量的估算, 在考虑子系统, 把总工作量逐步分解为各组成部分的工作量, 并考虑到开发该软件所需的资源、人员、质量保证、系统集成安装等的工作量。
这种估算方法的优点是估算工作量小, 速度快;缺点是对项目中的特殊困难估计不足, 估算出来的工作量盲目性大, 有时会遗漏被开发软件的某些部分。
(2) 自底向上估算法。
先对开发各子系统或每个模块的工作量进行估算, 在逐步相加, 这是一种常见的估算方法。
这种估算的方法优点是估算各个部分的准确性高;缺点是缺少各项子任务之间相互联系所需的工作量, 还缺少许多与软件开发有关的系统级工作量 (配置管理、质量管理、项目管理) 。所有往往估算值偏低, 必须用其他方法进行检验和校正。
(3) 相似比较估算法。
把开发项目的工作分割到一定的程度, 和过去的工作进行比较, 对其中相同的或相近的部分用已有的数据进行估算, 对不同的部分在用其他的方法估算。
这种估算方法的优点是可以提高估算的准确程度;缺点是不容易明确“类似”的界限。
(4) Delphi估算法。
请多位项目经理、系统分析员或其他专家, 利用专家的经验来评估软件的开发成本。
这种估算法的优点是可以摒弃无根据的估算值;缺点是一些参加评估的成员可能会受到其他因素的影响。
1.3 工作量估算的计算
工作量的评估是对项目有关工作以人时、人月、人年为单位进行的计算, 它是成本和预算的依据。工作量估计的结果一般是多少个人的多少历时。
项目工作量估算的依据是项目的WBS分解, 有了任务分解, 就可以对分解后获得的任务单元的性质、需要的人力资源素质、需要的工作持续时间进行估算。例如, 是概要设计、架构设计, 还是接口设计等。估算就是按照需要分配不同级别的人力资源, 并估计在这样 (或不是这样) 的人力资源条件下的任务历时时间。
下面是一个例子, 说明对一个移动开发项目综合营业系统的工作量估算的计算过程。
经过采用Delphi方法测算, 开发移动综合营业系统的工作量估计是244个人月。其中, 系统设计师为24个人月、系统构架师为2个人月、高级程序员为54个人月、初级程序员为64个人月、测试工程师为32个人月、高级测试工程师为8个人月、文档编辑为40个人月、项目经理20个人月。
表1-3-1是根据项目任务的WBS汇总获得的项目人力资源计划表, 它成为项目工作量测算的依据。
如果244个人月在24个月内进行安排, 人力资源曲线如图1-3-2所示。对软件开发项目来说, 这是一个比较理想的曲线。
1.4 软件项目工作量估算的其他构成因素
我们在软件项目工作量估算的时候, 可能会比较集中地考虑需求分析、设计、编码、测试等的工作量, 往往会忽略以下一些工作量。
(1) 用于各模块、子系统、软件系统与硬件/网络系统之间集成的测试、调试等的工作量。
(2) 用于编写用户文档和设计文档的工作量。
(3) 用于需求管理、配置管理、质量管理、风险管理等支持过程的工作量。
(4) 用于项目管理的工作量。
有关这些工作量的度量, 目前还没有看到比较系统、适用的度量和估算方法的介绍。因为作为项目管理, 其工作本身就是全过程、随时性和零碎的, 因此, 对于它们的工作度量, 确实更为困难。但是, 这部分的工作又是非常关键和不可或缺, 工作量也是比较大的。因此, 如何规范地估算是项目管理的一个重要课题。
1.5 软件项目工作量估算的其他影响因素
在做软件项目工作量的估计时, 应考虑到以下几个影响的因素:项目复杂度、人为因素和工程因素、意外事件等。
(1) 复杂度包括问题领域、算法复杂度性、程序设计语言、软件复用量、可靠性等性能要求、系统平台复杂度、资源的限制等。
(2) 人为因素包括开发人员的能力、经验、稳定性、开发的组织管理能力、用户的配合等。
(3) 工程因素包括开发技术的难度、进度的紧迫度、项目团队的凝聚力、多地点开发等。
意外事件也是一个影响的因素。
1.6 综合修正
为了减少误差, 需对估算值进行修正和调整。通常采用三个时间估计法:估计工作执行的三个时间, 乐观时间A、悲观时间B、正常时间M, 对应于PERT网络, 期望时间T= (A+4M+B) /6。
举一个例子如下:
假设某一开发项目正常的情况下历时30天, 在最有利的情况下历时是18天, 在最不利的情况下历时是36天, 那么该工作的最可能完成的时间是多少呢?
最可能的时间T= (18+4*30+36) /6=29天
在考虑了其他因素之后, 把以上因素作为加权值, 对估算值进行修正, 修正公式为:
2 软件项目的进度估算
2.1 项目进度表
项目进度表是组织规范项目组进度计划管理最基本的工具, 除非在客户需求中有特殊的说明, 否则组织要求组织内的所有项目。都应该采用公司所建议使用的工具和项目进度表模板来定制进度表。
作为一个大型的综合性的开发项目, 进度计划可能涉及到许多方面, 例如供货计划、硬件和网络安装测试计划、软件开发计划、项目管理计划等。它们的时间是相互配合相互衔接的。
计划模板包括以下内容:
(1) 项目实施总计划:
(2) 项目管理计划:
(3) 交付计划:
(4) 软件技术实施计划:
(5) 硬件技术实施计划:
在采用标准模板的时候, 可以删除模板中一些项目不需完成的工作。
2.2 对每一项任务估算时间
在模板中实际上已经为我们分解和定义了项目任务, 按照模板, 项目进度的估算可以按以下步骤进行。
(1) 按分解的任务确定责任人。任务进度表中, 必须表明任务责任人或部门, 根据这个任务表, 任务将会分配到一个人或一个小组。比较粗的计划可能以小组为单位, 或不确定的人。但详细计划将明确到个体的人。因为不同的人, 担负相同的任务, 其时间历时可能差距巨大。人员的不确定使计划的真实性和准确性没有保证。
为了让项目组各负其责, 以文字形式确定他们的项目组里, 分担的责任是很重要的。比较有效的方法是绘制责任矩阵表。在项目开始时, 要恰当配置好人员、技术和工作任务。随着项目的进展, 有可能把已分的工作再细分或进行新的调整, 为此项目经理应该清楚的了解项目组成成员各自掌握的技术。
(2) 估算任务单元的可支配时间。根据具体任务承担人的能力、资源、条件等, 通过估算, 输入完成每一项已分配的任务所需要时间的估算值, 也是该任务责任人的可支配时间。
(3) 考虑任务估算的制约和影响因素。用户对完成任务的时间要求通常是倒计时的, 即限定什么时间内必须完成。
项目内部配合上对时间的要求:任务是相互衔接的, 因此上一任务的完成可能是下一任务开始的前提条件, 因此项目整体对具体一个任务的完成时间是有要求的。
资源的限制、质量标准和规范的限制、应付变更和不确定因素等, 这些制约, 有些直接反映到项目任务的时间进度上。
3 对估算的总结
估算值并不是一个简单的人月数字, 例如20个人年的工作量, 不可能要一个人干20年来完成。
有一些经典的计算公式告诉你软件开发的某类工作, 工作量应该是多少。但是, 可能这些公式的普遍实用性并不高。
在Brooks的《人月神话》一书中提到, 许多负责软件开发的管理者依然坚定一个普遍的神话存在, 即:如果进度拖后, 我们可以在后期靠增加人手的办法来赶上。不幸的是, 在项目后期增加的人手, 通常会产生破坏性的影响, 结果是项目进一步的拖后延期, 因此我们在项目开发过程中, 应该把估算作为重要的一环来加以重视。
参考文献
[1][美国]Chris F.Kemerer.软件项目管理:阅读和案例.上海:上海财经大学出版社, 2004.
[2]张家浩.软件项目管理.北京:机械工业出版社, 2005.
[3][美国]布鲁克斯.人月神话.北京:中国电路出版社, 2003.
[4]白思俊主编.现代项目管理.北京:机械工业出版社, 2002.
[5]周小桥著.突出重围──项目管理实战.北京:清华大学出版社, 2003.
软件相似度在成本估算中的应用 篇6
中国项目管理研究委员会在其网站上发表评论指出:2004年, 首届“国际软件行业项目管理论坛”发布的数据, 国内某些软件企业的项目计划完成率不过70%, 全球软件开发项目中只有16%能按计划完成。并且指出, 造成这种现象的主要原因在于没有做好项目控制和管理[1]。软件开发成本估算是制定软件项目开发计划的重要依据, 并且随着软件项目规模的日益扩大和投资的增加, 软件开发成本估算的重要性日益突出。常用的成本估算模型可以分为3类:专家估算法, 算法模型估算及类比法[2,3]。专家估算法是由一个被认为是该任务专家的人来控制, 并且估算过程的很大一部分是基于不清晰、不可重复的推理过程, 专家的个人偏好、经验差异与专业局限性都可能为估算的准确性带来风险。算法模型估算通过分析影响软件成本的各种因素, 根据各因素对成本的影响关系建立数学模型进行软件成本进行估算的方法, 例如构造性成本模型 (COCOMO) 就是一种典型的算法估算法[4,5]。该类方法客观、高效、可重复, 且能利用以前的项目经验进行校准;但是难以用在没有前例的场合。类比 (analogy) 法是基于实例推理CBR (case-based reasoning) 的一种形式, 即通过对一个或多个已完成的项目与新的类似项目的对比来预测当前项目的成本[6,7]。该方法的准确性依赖于相似项目的选择。不管是那一种类型的估算方法, 都与相似项目的选择有着直接或间接的关系, 因此, 相似项目的选择对成本估算有着重要的影响, 鉴于此, 本文对项目之间的相似度计算进行研究。
1 相似度计算方法介绍
对象间的相似度是度量对象间的相似程度, 与距离相反, 相似度的值越小, 说明个体间相似度越小, 差异越大。常用的计算对象相似度的方法有欧几里得距离、余弦相似度、Jaccard相似系数及调整余弦相似度等[8]。
欧几里得距离
欧氏距离度量了在m维空间中两个点之间的真实距离, 体现了个体数值特征的绝对差异。具体的计算方法为:
余弦相似度
余弦相似度用向量空间中两个向量夹角的余弦值来衡量对象间的差异。与距离度量相比, 余弦相似度更加注重对象在方向上的差异, 而非距离或长度上, 具体的计算方法为:
Jaccard相似系数
Jaccard系数主要用于计算符号度量或布尔值度量的个体间的相似度。它只关心对象间共同具有的特征是否一致这个问题, 具体的计算方法为:
调整余弦相似度
虽然余弦相似度对对象间存在的偏见可以进行一定程度的修正, 但是因为只能分辨对象在维之间的差异, 没法衡量每个维数值的差异, 就出现了调整余弦相似度, 具体的计算方法为:
其中, xi和yi表示项目i的评分, 分别表示所有项目的平均评分。
2 软件的相似度计算
为了说明相似度, 首先给出一个定义:
定义1 历史项目集DB定义为一个三元组 (P, A, R) , 其中:P表示项目集, P={p1, p2, …, pm}表示具有m个历史项目的集合;A表示描述项目的属性集合, A={a1, a2, …, an}表示描述项目n个方面特征的集合;R表示项目P的属性A的取值, R={aj (pi) }表示第i个项目的第j个属性的取值。
若将项目作为文档, 属性作为文档的特征, 那么计算文档相似度的方法即可应用于计算软件的相似度, 首先计算各属性间的相似度Asim, 然后根据属性相似度计算项目相似度Psim。由于属性取值类型的不同, 应采用不同的方法计算属性间的相似度;而且项目集中存在的缺失值也会影响计算的准确性, 因此, 应该考虑如何对其进行处理。具体的计算过程分为两个步骤:计算属性相似度和计算项目相似度。
2.1 计算属性相似度
由于项目的相似度是由描述它的属性集确定的, 但是, 描述项目的各个属性的类型不同, 它们可能是数值、集合、范围、模糊值、向量或布尔类型等, 例如:项目的规模是一个具体的数值, 项目的开发语言可能是{html, php, sql}, 团队的开发经验是[1, 10], 项目的复杂程度等级是低, 使用到了CASE集成工具, 因此该值的1, 项目的功能是70%的内部处理, 10%的数据输入, 10%的输出, 10%数据库查询操作, 不涉及文件查询, 那么, 可表示为 (0.7, 0.1, 0.1, 0.1, 0) 。对于不同类型的属性, 使用不同的方法计算它们的相似度。本文中Asim (ak (pi) , ak (pj) ) 表示项目i与项目j的第k个属性间的相似度, 并且它满足Asim (ak (pi) , ak (pj) ) ∈[0, 1]。具体情况如下:
a) 如果属性是数值型, 那么使用欧式距离作为计算相似度的依据, 距离的计算采用式 (5) 进行, 然后运用式 (7) 计算属性相似度。
其中:ak (pi) 表示项目i的第k个属性;ak (pj) 表示项目j的第k个属性;
其中:Pk表示所有项目的第k个属性的取值, max (Pk) 和min (Pk) 分别表示第k个属性值中的最大值和最小值。
b) 若属性值是布尔类型, 采用式 (8) 计算属性相似度。
c) 若属性值是集合, 采用Jaccard系数计算属性相似度, 具体计算方法参照式 (9) 。
其中:表示项目i和j的第k个属性集中相同元素的个数, 表示项目i和j的第k个属性集中不重复元素的个数。
d) 若属性是模糊型, 首先将该模糊值按照程度次序转化为有序的连续整数值, 然后采用数值类型进行计算。
e) 若属性是范围 (在此不区分闭区间, 开区间和半开半闭区间) , 那么假定ak (pi) 的取值范围为〈lik, hik〉, 假定ak (pj) 的取值范围为〈ljk, hjk〉, 然后根据式 (10) 计算相似度。
其中:min (hik, hjk) 表示项目i与j的第k个属性取值范围上界的最小值, max (lik, ljk) 表示项目i与j的第k个属性取值范围下界的最大值, max (hik, hjk) 表示项目i与j的第k个属性取值范围上界的最大值, min (lik, ljk) 表示项目i与j的第k个属性取值范围下界的最小值。
f) 若属性的取值为有序的数值集合, 例如前面描述功能所用的方法, 可以将其看作向量, 然后, 运用向量的余弦值计算其相似度, 采用式 (11) 进行计算。
上面讨论了在没有属性缺失的情况下属性间相似度的计算方法, 但是由于各种因素导致的数据缺失是不可避免的, 那么, 如何计算含有缺失值的属性间的相似度也应该考虑。常用的缺失值处理方法可分为删除存在缺失值的个案和缺失值插补[9]。本文采用了四种计算含有缺失值的属性相似度计算方法:删除有缺失值的列, 补0法, 补1法和补均值法。
删除有缺失值的列:仅对所有项目中都有的属性信息进行计算;
补0法:在计算含有缺失值的属性相似度时, 根据下面的方法进行处理:
补1法:在计算含有缺失值的属性相似度时, 所有的局部相似度计算结果均为1, 即Asim (ak (pi) , ak (pj) ) =1。
补均值法:若缺失值是数值, 则使用本列数值的均值对缺失值进行填充;若缺失值不是数值, 则Asim (ak (pi) , ak (pj) ) =0.5。
2.2 计算项目pi和pj的相似度Psim (pi, pj)
本文采用文档相似度的计算方法, 即计算出每个特征的相似度以后, 然后根据该特征对文档的影响程度计算文档之间的相似度, 本文在计算项目之间的相似度采用该方法进行, 具体的计算依据为:
其中:qk表示第k个属性的权值, 并且所有属性的权值之和为1, 即满足表示项目i和j的第k个属性的相似度。
由于各个属性对成本的影响程度难以确定, 因此, 本文认为所有属性具有同等的重要性, 因此项目的相似度依据为:
其中:表示属性的数量。
为了说明该方法的有效性, 在计算出项目间的相似度以后, 使用文献[10]中的方法来估算待评项目的开发成本。常用的评估指标采用平均绝对偏差MAE。
平均绝对偏差MAE通过计算所有评估项目的预测成本与实际成本之间的偏差与实际成本比值的平均值来度量估算的准确性, MAE的值越小, 估算结果越准确, 具体的计算方法为:
其中:E (pi) 表示项目pi的实际成本, 表示项目pi的估算成本。
3 实验
本文以USP05-FT项目集为例, 采用均值对缺失值进行处理, 分别以相似度值0.72, 0.76, 0.80, 0.84, 0.88及0.92来选择近邻, 文献[10]中的方法进行成本的估算, 以MAE来评估估算结果的准确性, 结果如图1所示。
从实验结果来看, 随着相似度的增加, 平均绝对偏差减少, 说明越相似的项目近邻集, 估算结果越准确。从图1来看, 估算的平均准确率可以达到85%以上。
另外, 从USP05-FT项目集中抽取了8个项目数据作为实例来评估处理缺失值的四种不同方法。在本文中将项目1作为待评估成本的项目, 其他的项目作为历史项目集, 采用了前文介绍的四种方法处理含有缺失值的属性间的相似度计算, 最终计算的各项目与项目1的相似度结果如表1所示。
若采用相似度0.8进行近邻的选择, 仅有一个项目被选择, 导致估算结果完全一致, 无法比较四种处理缺失值方法的优劣。因此, 本文选择2个相似度最大的项目作为近邻进行成本的估算, 结果表明:补0法在本次估算中的效果最好, 补1法的评估结果与实际值偏差最大。
4 结语
软件成本估算是项目管理的重要内容, 本文将计算文档相似度的方法应用于软件的相似度。由于项目数据中缺失值的存在, 本文首先采用的四种不同的方法进行处理, 并针对属性取值类型的不同采用不同的方法来计算属性间的相似度。然后将各属性的相似度进行加权平均得出项目间的相似度, 根据计算结果在历史项目集中确定待评估项目的近邻集, 根据近邻集中项目的成本即可确定待评估项目的成本。将该方法应用于USP05-FT的项目实例, 实验结果表明:采用不同的相似度来选择近邻, 评估的准确性可以达到85%以上。并将四种缺失值的处理方法应用于部分项目, 结果表明:补0法在本次估算中的效果最好, 补1法的评估结果与实际值偏差最大。各属性的权值以及不同的近邻选择方法都会对估算结果的准确性产生影响, 这将是下一步要解决的问题。
参考文献
[1]李明树, 何梅, 杨达, 等.软件成本估算方法及应用[J].软件学报, 2007 (4) :776-777.
[2]Hareton Leung, Zhang Fan.Software Cost Estimation[EB/OL].2012-10-15.https://www.st.cs.uni-saarland.de/edu/empirical-se/2006/PDFs/leung.pdf.
[3]Li Y F, Xie M.A study of project selection and feature weighting for analogy based software cost estimation[J].Journal of Systems and Software, 2009, 2:242-245.
[4]Boehm B W, Valerdi R, Lane J, et al.COCOMO suite methodology and evolution[J].The Journal of Defense Software Engineering, 2005, 18 (4) :20-25.
[5]Roger S Pressman.软件工程:实践者的研究方法[M].机械工业出版社, 2010:510.
[6]Li Y F, Xie M.A study of the non-linear adjustment for analogy based software cost estimation[J].springer Empirical Software Engineering, 2009, 12:610-615.
[7]Shepperd M, Schofield C.Estimating software project effort using analogies[J].IEEE Trans.on Software Engineering, 1997, 23 (12) :736-743.
[8]许海玲, 吴潇, 李晓东, 等.互联网推荐系统比较研究[J].软件学报, 2009, 20 (2) :350-362.
[9]Patrick Royston, Cancer Division.Multiple imputation of missing values[EB/OL].2013-3.http://hbanaszak.mjr.uw.edu.pl/Temp Txt/Royston_2004_Multiple%20Imputation%20of%20Missing%20Values.pdf, 2013, 3.
软件错误估算 篇7
随着软件测试逐渐从软件开发过程分离,成为一个独立的软件过程,对软件测试的成本估算的研究提出了迫切的需求。早期的软件开发模型认为软件测试仅仅是软件开发生命周期中的一个阶段,这种认识造成了软件规模估算方法缺乏对软件测试规模估算的研究。估算偏低造成了软件测试不充分,测试时间仓促;估算偏高又会造成投资浪费。在软件测试工作开展以前,恰当地估算软件测试的规模及成本,为软件测试项目分配合适的人力资源及测试时间,将使软件产品的质量得到大幅提高。
目前,软件测试规模及成本的估算研究和应用还比较少,相比较而言,软件规模及成本的估算方法可谓种类繁多,主要的软件规模度量方式有代码行、功能点及其扩展方式、对象点以及用例点,以及软件成本估算模型COCOMO 81、COCOMO II模型等。
1 软件功能测试成本分析
影响软件功能测试核心成本的要素包括两个方面:被测系统的功能规模和测试效率。软件功能测试规模与软件的功能规模密切相关,在估算出软件的功能规模后,考虑对软件功能测试规模产生影响的因素,并用其对软件的功能规模进行处理,得到软件的功能测试规模。对功能测试规模有影响的因素包括:功能复杂性、用户重要性、使用频度、可复用程度。在对软件功能测试规模有一个预估之后,考虑影响测试成本的另一个因素:测试效率。对测试效率产生影响的因素有很多,具体可以分为以下一些方面:项目先例性、团队凝聚力、风险控制能力、测试工具、文档完整性等。在此基础上建立相应的软件测试成本的计算方法及其模型,即可得到软件功能测试的成本。
2 软件功能测试成本估算模型
本节提出了软件功能测试成本估算模型STCEM(Software testing cost estimation model),模型分别对软件功能测试的规模以及影响软件测试的效率进行了估算及定义,并基于算法估算模型,给出估算公式,以此得到软件功能测试的估算成本,基本流程如图1所示。
STCEM利用Mark II方法估算软件规模,利用规模调整因子进行修正,得到功能测试规模,并结合项目的效率因子,最终得出软件功能测试成本。
2.1 估算软件规模(FP)
软件规模是测试规模的直接决定因素,在各种软件规模的估算方法中,功能点分析法由于其突出的特点在近年得到了比较广泛的应用。典型的方法包括IFPUG方法、Mark II方法等,IFPUG方法比较复杂,Mark II方法基于逻辑事物进行功能点分析,相对比较简单,无需对组件的复杂程度进行分类,并且可以直接对逻辑事物进行规模因子调整,获得功能测试点。本模型中采用Mark II方法方法来估算软件的规模。
2.2 定义规模因子(SF)
在计算出每一个逻辑事务Lj的功能规模FP后,从测试角度出发,考虑会对功能测试规模产生影响的因素,如功能复杂性、用户重要性、使用频度、可复用程度,定义为规模因子SF,通过其对功能点进行调整,得到每一个逻辑事务的测试点。各规模因子的定义为:
· 功能复杂性(FC) 从模块输入输出元素数量的角度度量;
· 用户重要性(UI) 相比其他模块,用户认为某一模块的重要程度;
· 使用频度(UF) 某模块被用户使用的频率以及使用该模块的用户规模;
· 可复用程度(RD) 测试的复用与否。
其中可复用程度根据是否复用取值分别为0.7(可复用)和1(不可复用),功能复杂性、用户重要性、使用频度分为低、中、高等级,取值由表1 所示。
在对功能复杂性、用户重要性、使用频度、可复用程度进行定义之后,每一逻辑事物Lj的规模因子SFj采用公式进行计算:
其中,公式中的数值15为各规模因子取等级为“中”时对应的取值之和。
2.3 计算测试规模(TP)
为每一个逻辑事务Lj估算出功能规模及定义其规模因子之后,可以利用公式得到该逻辑事物的功能测试规模,计算公式为:
TPj=FPj×SFj (2)
被测系统总的功能测试规模为各逻辑事务功能测试规模之和:
2.4 定义效率因子(CF)
对测试效率产生影响的因素包括:项目先例性、团队凝聚力、风险控制能力、测试工具、文档完整性等,定义如下:
· 项目先例性(Pp) 对于测试项目的新奇程度。需考虑因素:对软件测试目标有组织级的理解、对类似软件系统的测试工作经验;
· 团队凝聚力(Ga) 项目相关人员适应他人的能力及意愿,团队内部的沟通渠道及频繁程度,团队为成员的成长与发展、自我价值的实现提供的条件;
· 风险控制能力(Rc) 项目组识别风险、控制及预防风险的能力,以及风险的危险程度;
· 测试工具(Tt) 功能测试工具是否被使用及使用的程度;
· 文档完整性(Di) 开发小组提供的文档的完整程度及质量。
各效率因子等级分别为低、中、高,取值定义由表2 所示。
总效率因子的计算公式为:
CF=Pp×Ga×Rc×Tt×Di=∏ CFi (4)
2.5 计算测试成本
测试总成本通常包括计划和管理成本、测试准备成本、测试核心成本、测试后成本。各种成本占软件测试总成本的比例根据测试阶段,测试类型不同而不同,并且,针对不同的测试组织,所占比例也可能不同。一般的,测试的核心成本会占到总成本的70-80%,计划和管理成本占10%左右,准备成本占5%左右,测试后成本根据是否包括回归测试部分占到总成本的5-15%左右。
在估算出软件功能测试的规模并定义了影响测试成本的效率因子后,采用基于算法模型的通用形式计算功能测试的核心成本。
基于算法模型的基本思想是:找到软件工作量的各种成本影响因子,判定它对工作量所产生影响的程度是可加的、乘数的还是指数的,其通用形式为:
PM=A×(∑Size)∑B×∏ EM (5)
其中,PM为工作量,通常表示为人月;A为校准因子;Size为对工作量呈可加性影响的软件模块的功能尺寸的度量;B为对工作量呈指数或非线性影响的比例因子;EM为影响软件开发工作量的工作量乘数。
基于算法模型的通用形式,功能测试核心成本的估算公式定义为:
PD=a×TPb×∏ CFi=a×(∑FPj×SFj)b×∏ CFi (6)
其中PD为工作量,以人日为单位(一个人日为8个小时,一个人月通常为22个人日);a、b为常量参数;TP为功能测试规模;FPj为某一逻辑处理事务的功能点;SFj为该逻辑事物的规模因子;CFi为效率因子。
根据测试核心成本所占测试总成本的比例,相应可计算测试总成本:
PDt=PD÷p (7)
其中PDt为测试总成本,PD为测试核心成本,p为测试核心成本占测试总成本的比例。
在公式(6)中,a、b为常量参数,SFj、CFi为变化因子,取值在模型中定义。为了使各参数取值更贴近自身情况,各企业可根据自己的历史经验数据对a、b、SFj、CFi进行校准。由于在模型中,SFj取值分散于各个逻辑事务中,如对其进行校准工作量巨大,所以,只对a、b、CFi等参数进行校准,校准模型采用常用的多元线性回归分析方法。某测试机构基于有限的项目经验数据对相关参数校准的结果为:a =6.23,b=0.46,CFi的校准值由表3所示。
带入参数校准值后的测试核心成本估算公式为:
PD=6.23×TP0.46×∏ CFi (8)
3 应用案例
软件功能测试成本估算模型STCEM在某第三方测试机构多个项目进行了应用,取得了较好的效果。本节以某培训系统测试项目为例,利用STCEM进行了成本估算,并对其有效性进行评估分析。测试启动时,该软件的开发以及内部测试已经完成,形成了比较完整的需求文档、设计文档以及用户手册。系统的主要功能包括培训信息浏览、培训课程、网上作业、交流论坛、个人信息、管理员界面。该系统为B/S架构,规模为中小型,测试类型为功能测试,采用黑盒测试方法,未使用到测试工具,符合功能测试成本估算模型的特点。
3.1 估算测试规模
首先,使用Mark II功能点法估算被测系统的软件规模。经过估算,软件的规模约为208个功能点,具体如表4所示。
对每一个逻辑事务定义规模因子等级,赋予相应等级的取值,得到该项目测试点数约为186个,具体如表5所示。
3.2 定义效率因子
通过对该项目的分析,将其效率因子“项目先例性(Pp)”、“团队凝聚力(Ga)”、“风险控制能力(Rc)”、“测试工具(Tt)”和“文档完整性(Di)”分别定义为:“高”、“中”、“高”、“中”和“低”,得到效率因子定义由表6所示。
总的效率因子为:
CF=Pp×Ga×Rc×Tt×Di=1.054 (9)
3.3 计算测试成本
将TP及CF值代入公式(8)得:
PD=6.23×TP0.46×CF=6.23×1860.46×1.054=72.66 (10)
即该测试项目的核心成本为72.66人日。
由于该项目将对发现的缺陷进行回归测试,根据经验将测试核心成本占总成本的比例设为75%,代入公式(7):
PDt=PD÷p=PD÷75%=96.88 (11)
即该项目的测试成本估计为96.88人日。
3.4 结果评估
项目采用STCEM预估的工作量为96.88个人日,而实际项目由4个人用了一个半月的时间完成,也就是约132个人日,预估的工作量偏差为26.6%。对偏差原因进行分析发现,首先风险控制方面,预估中对项目风险进行了比较详细的评估,也提出了相应的解决方案,但部分风险发生后的排除造成额外的时间延迟。其次,预估中认为项目小组成员均有比较高的项目经验,实际情况是项目小组在项目开始后作了一次调整,由一名新毕业的学生代替了一名具有较丰富经验的测试人员,造成了一定的测试进度滞后。
4 总 结
本文提出一种基于算法模型的软件功能测试成本估算模型STCEM,该模型分别对软件功能测试的规模、影响软件测试的效率进行了定义,得到功能测试核心成本及总成本。文中对模型中的参数进行了初步校准,给出了相应参数的取值。实践证明估算模型STCEM对测试工作的开展及测试计划的制定具有一定的指导意义。另外,由于历史经验数据有限,对模型中参数的校准可能不够准确,因此,需要长时间积累项目数据,持续对模型中的参数进行校准。同时,模型中的规模因子以及效率因子也需要随着理论和实践知识的发展作进一步的调整和补充。
参考文献
[1]杨根兴,蔡立志,陈昊鹏,等.软件质量保证、测试与评价[M].北京:清华大学出版社,2007.
[2]李明树,何梅,杨达,等.软件成本估算方法及应用[J].软件学报,2007,18(4):776-795.
[3]ISO/IEC.20926,IFPUG4.1 Function point counting practices manual[R].2002.
[4]ISO/IEC.20968,Software engineering—Mk II Function Point Analy-sis—Counting Practices Manual[R].2002.
[5]李帜,林立新,曹亚波,等.软件工程项目管理:功能点分析方法与实践[M].北京:清华大学出版社,2005.