计算机与现代化2011年第7期总第191期激SUAN激YUXIANDAIHUA:1006-2475(2011)07-0121-05基于专家经验和随机抽样的早期快速估算方法朱安江，何鸿君，尹俊文，刘庆和，周鹏，买新晖(国防科学技术大学计算机学院，湖南长沙410073)摘要:项目立项阶段由于评审时间有限，需要采用快速近似估算方法获取软件的规模以确定经费预算。本文提出基于专家经验和随机抽样的快速估算方法，将软件分解为不同的软件模块，由开发组织对不同的模块规模和成本进行预估并申报经费，估算人员利用专家经验以及对软件组件随机抽样进行详细度量，再利用快速近似估算方法估算出软件项目的整体规模，进而得到软件整体成本。实际应用表明，该方法是可行的。关键词:软件;经费预算;规模估算;快速估:TP311．5文献标识码:Adoi:10．3969/j．issn．1006-2475．2011．07．034EarlyandQuickEstimationBasedonExpertExperienceandRandomSamplingZHUAn-激ang，HEHong-jun，YINJun-wen，LIUQing-he，ZHOUPeng，MAIXin-huiAbstract:Intheproject-approvalphase，duetoconstrainedtimeforreview，itneedsquickandapproximateestimatemethodsforobtainingsoftwaresizetodeterminethebudgets．Thispaperputsforwardaquickestimationbasedonexpertexperienceandran-domsampling，bywhichestimatorfirstdecomposessoftwareintodifferentsoftwaremodules，thedevelopmentorganizationpre-es-timatessizeandcostofthesedifferentmodulestodeclarefunds，thenestimatorperformsadetailmeasurementwithexpertexperi-enceandrandomsamplingofsoftwarecomponents，andestimatesthetotalsoftwareprojectsizebyquickandapproximatesesti-matemethodinordertogetthetotalsoftwarecost．Applicationshowsthatthismethodisfeasible．［1］法，并对其进行改进以适应项目评审阶段应用的方法。首先，要求乙方根据自己单位的历史经验和承研的软件项目情况对软件进行预估，将软件分解成模块，并进行预估，将预估的结果提交评审组然后，评审组抽取软件模块样本，要求乙方对抽取到的样本再做详细的功能分解。评审组人员针对乙方提供的样本资料估算样本规模，并与乙方提供的预估值进行比较，测算出其平均虚报比例，并利用该比例得出其余模块的规模，最终得出软件的整0引言软件规模估算是项目立项阶段确定软件成本的重要依据，本文提出基于专家经验和随机抽样的快速估算方法来确定软件的规模。立项评审时项目尚处在早期阶段，缺乏详细的需求说明书，因而采用标准的功能点方法并不合适，同时项目的立项评审往往采用评审会的形式，时间非常有限，即使采用标准的快速近似估算方法，也不能很好适应这种时限要求。项目主管部门(甲方)和开发组织(乙方)之间存在利益冲突，乙方往往会夸大软件的规模来申报经费，作为第三方评审组的估算人员如何利用一种快速的估算方法得出软件规模，为甲、乙双方签署合约时达成一致提供依据尤为关键。为此，本文提出基于专家经验和随机抽样的快速估算方法来解决这种矛盾，该方法是基于E＆Q方该方法已经应用于某大型软件项目的立项评审，不仅快速准确地得出了软件的规模，而且为甲乙双方迅速达成一致提供了有效支持。早期快速估算方法简介必要性在软件项目的早期阶段，项目管理人员往往受到11．1收稿日期:2011-04-08作者简介:朱安江(1980-)，男，甘肃金昌人，国防科学技术大学计算机学院硕士研究生，研究方向:软件工程，软件估算;何鸿君(1968-)，男，副教授，博士，研究方向:信息安全，软件工程经济学;尹俊文(1969-)，男，副教授，博士，研究方向:操作系统，软件工程，多媒体技术。指，早期阶段项目未正式开始，花太多工作量进行项目详细估算并不现实，因为项目还不一定是自己中标的。而标准的估算方法往往需要软件的需求规格说明书或软件设计说明书作为输入，这在软件项目的早期阶段尤其在立项评审阶段是无法完整提供的，要达到标准度量规则的标准，意味着很大一部分工作已经完成了，从项目管理的角度来说，这是不合适的，功能规格说明书或需求规格说明书的工作占用了15%到40%的工作量［3］。Meli指出:在早期没有足够的详细信息的...