软件人力成本估算(一)

《软件人力成本估算(一)》由会员分享，可在线阅读，更多相关《软件人力成本估算(一)（57页珍藏版）》请在装配图网上搜索。

1、软件人力成本估算(一)一、选题目的和意义选题的目的：随着软件行业的逐渐成熟，人们越来越深刻地认识到，必须充分理解技术、方法和有效的应用人力资源。软件估算尤其是成本估算是有效监控软件进度的关键部分之一。软件估算是在软件开发和维护范畴内定性、定量估算指标的定义、收集、整理、分析和呈报。软件成本估算显示了人们对生产率和质量深刻的认识，是在软件问题领域综合应用技巧、技术和方法而取得的成果。对软件人力成本的估算就是基于项目的规模、工作量而对人力成本的估算过程。由于软件本身的特性，很难收集项目的需求和估算。软件作为概念在早期很难确定规模，但估算便是要在早期做出来并确定项目的整个过程。估算开始于对项目需求和

2、项目所处的环境及所作的假设的理解。然后，软件规模要以某种合适的方法进行量化处理。得到产品规模后，工作量以及人力成本的估算便可相应得出。选题的意义：通过写软件人力成本估算论文使我更加全面的了解和掌握关于有关软件成本估算的知识，并对已有的估算方法提出一些改进，并且希望通过这次的实践来运用所学知识，来培养我的动手能力和合作能力，故选择软件人力成本估算作为我的毕业课题。二、本选题在国内外的研究现状和发展趋势有许多用于软件成本估算的技术，从早期代码行估算方法发展到以后的功能点度量方法。这期间有代表性的方法有MARK II、IBM模型、普特南模型、COCOMO模型等。本文主要对功能点度量方法作了介绍，并且

3、针对功能点度量方法本身的缺陷提出了两种改进措施，一种是使用UML中的用例建模技术来解决需求的规范化问题；另一种是扩展功能点。扩展功能点从功能角度度量软件的规模，独立于开发所使用的语言。一旦获得了用户功能需求就可以用它来度量规模。最后本文通过比较几种软件成本估算方法的优缺点，提出了一种新的软件成本估算方法：将算法模型、专家小组法和类比估算法结合起来，互相取长补短，由层次分析法得到各种估算法的权重，再由权重合成法得到估算成本。从现在的需求形式来看，该课题的研究会日趋合理，这方面的研究会不断完善，好的人力成本估算方法应该能够比较准确的估计出软件开发过程中的人力成本。由于估算本身的不确定性，决定了它不

4、可能是百分之百准确无误的。但是，估算结果与实际开发使用的人力成本的接近程度可以作为判断估算方法的优劣的标准。三、课题设计方案 主要说明：研究（设计）的基本内容、观点及拟采取的研究途径。1.研究的基本内容：(1)人力成本估算的定义。(2)软件成本估算中的人力成本。(3)软件人力成本估算的概述。(4)软件人力成本估算的规划、对象、策略与方法。(5)重要估算方法的描述。(6)对估算方法的改进，新方法的提出。2.基本观点：软件开发中的人力成本，是在软件开发过程中为了开发出满足客户要求的产品必须为开发过程中使用的人力资源支付的那一部分资金，它在软件开发成本中占相当大的一部分。对于这一部分成本的估计也就是

5、人力成本估计。这部分成本的估计，首先要估算出软件的规模得出工作量然后根据当前的开发人员的工资水平估计出人力资源成本。3.方法：理论研究与实践相结合，把对这个问题的看法以及所应该注意的问题进行有效的阐述和分析，得出可行有效的结果。参考国内外已经取得的研究成果，认真阅读参考资料。四、计划进度安排 主要说明：起止时间及分阶段的进度要求。阶段开始时间结束时间进度说明第一阶段2006.1上旬2006.2下旬搜集资料，熟悉相关内容，完成毕业设计开题报告。 第二阶段2006.3上旬2006.4下旬对该题目进行综合全面的分析，形成自己的观点和想法，达到对该问题的全面了解和掌握。第三阶段2006.5上旬2006

6、.5下旬整合汇总，提交每阶段都给出应的文档，最后整理提交。五、主要参考文献 1 Roger S. Pressman.（美）软件工程实践者的研究方法第五版北京：机械工业出版社，20022 Swapna Kishore ,Rajesh Naik（印）软件需求与估算第一版北京：机械工业出版社，20043 Frederick P. Brooks，Jr（美）人月神话第三版北京：清华大学出版社，20034 陈松乔，任胜兵，王国军等现代软件工程第一版北京：清华大学出版社，20045 王强，曹汉平，贾素玲，木林森等IT软件项目管理第一版北京：清华大学出版社，20046 李帜，林立新，曹亚波等功能点分析方法与实

7、践第一版北京：清华大学出版社，2005 指导教师意见及建议摘要：软件估算，就是结合目前各种实际情况，提供项目中的软件规模、工作量和人力成本的最可能合理的模型。本文主要对功能点度量方法作了介绍，并且针对功能点度量方法本身的缺陷提出了两种改进措施，一种是使用UML中的用例建模技术来解决需求的规范化问题；另一种是扩展功能点。扩展功能点从功能角度度量软件的规模，独立于开发所使用的语言。一旦获得了用户功能需求就可以用它来度量规模。最后本文通过比较几种软件成本估算方法的优缺点，提出了一种新的软件成本估算方法：将算法模型、专家小组法和类比估算法结合起来，互相取长补短，由层次分析法得到各种估算法的权重，再由权

8、重合成法得到估算成本。关键词：功能点，扩展功能点，用例，用例模型，事务，用户功能需求，基本功能块1 引言随着软件行业的逐渐成熟和软件工程概念的日益深入人心，人们越来越深刻地认识到软件度量的重要性。软件度量是在软件开发和维护范畴内定性、定量度量指标的定义、收集、整理、分析和呈报。软件度量体系显示了人们对生产率和质量深刻的认识，是在软件问题领域，综合应用技巧、技术和方法而取得的成果。软件度量的根本目的是通过量化的分析与总结，帮助我们提高生产率，提高产品质量，降低成本和产品研发周期。从国际上度量活动的典范来看，度量活动给组织和项目所带来的收益远远大于度量活动所耗费的成本。常用软件度量包括规模度量、成

9、本度量、工作量度量、进度度量、生产率度量、风险度量等，其中对规模的度量和估算是所有度量活动的基础，其结果可作为其它度量的一个主要输入，因此在软件度量活动中具有重要地位。其中的人力成本的估计也需要有以上的度量作为前提数据。随着经济的不断发展，现代经济的经济结构由以生产型为主向科技服务型为主的转变已经成为一种趋势。这一转变使得人力资源在企业生产经营和国家经济发展中所起的作用变得更为关键。加之国际竞争的日渐激烈亦使得人们对人力资源更加重视起来。人力资源是指在一定区域内的人口总体所具有的劳动能力的总和，是存在于人的自然生命机体中的一种国民经济资源。而企业为获得人力资源和优秀的人才，就需要很多的投资，这

10、种投资在企业中就体现为人力资源成本。当前，科学技术突飞猛进，信息革命和网络经济使市场呈现全球化趋势，企业间的竞争日趋激烈，人才便成为不可或缺的驱敌制胜的法宝之一。从而，人才、人力资源、人力资源成本、人力资本被提到了新的议程。在过去相当一段历史时期，中国企业的快速成长和发展，主要依靠“人海战术”和资源的大量投入。而中国经济发展到今天，随着各行业的平均利润率越来越低，竞争越来越白热化，市场空白越来越少。在这种条件下，过去的粗放式人海战术由于其管理成本居高不下已经走到了尽头。所以如何从粗放式的人海战术到精兵强将就成了一个重要的问题。因为，软件人力成本估算要以对软件的规模估算为基础，即需要先估算出软件

11、的规模或者说需要先估算出开发软件所需要的工作量才能对软件人力成本做一个估算。因此，我们进行软件人力成本估算就是要在先估算出软件规模的基础上得出对软件的人力成本的估算。2 认识软件估算虽然估算是一门科学，更是一门艺术，这个重要的活动不能以随意的方式来进行，因为估算是所有其他项目计划活动的基础，而项目计划又提供了通往成功的软件工程的道路图，所以，没有它我们就会搭错车。Roger S. Pressman 软件工程实践者的研究方法软件不同于常见的生活用品。开发软件主要用人们的脑子，不需要开工厂，无需原材料，也不需要放到百货商店的柜台上销售。一般地，开发成本和维护成本是软件的主要成本构成。除了软硬件基础

12、设施的成本外，人力资源成本占了开发成本的主要比例。人力资源成本等于雇员的工资乘以工作时间，所以企业招聘员工的理想状态是：以最低的工资招聘恰好满足工作需要的人。另外，设法提高工作效率以减少总的开发时间，从而降低人力资源成本。2.1 估算前的规划当我们的办公室内堆满了杂乱无章的文件时，恐怕无法知道对于我们真正有用的文件在哪里，当我们的软件项目中收集了各种需求、意见、问题时，我们也很难从中估算出整个项目的规模、工作量以及成本。因此，在估算之前我们首先要对众多信息进行整理、归类、分析，从而得到一个条理清晰的项目计划，在这个计划提供的框架内，才可能开始正确的估算。精心的规划是任何一个软件开发项目成功与否

13、的关键，有了规划就有如成竹在胸，之后无论风云变幻，都有应对如流的方法。当然只有正确的规划，才能给软件开发指引正确的方向。软件项目规划的重点是对人员角色、任务进度、经费、设备资源、工作成果等等做出合适的安排，制定出一些计划（包括高层的和细节的），使大家按照计划行事，最终顺利地达到预定的目标。2.1.1 规划的第一步：确定软件范围确定软件范围，就是确定目标软件的数据和控制、功能、性能、约束、接口以及可靠性。这项工作和需求分析是很类似的，如果之前已经达成需求分析规约，那么可以直接从需求分析说明书中把有用的部分拿来使用。如果还没有开始需求分析，关于确定软件范围的方法方面，我们可以采用许多需求分析技术（

14、如需求诱导），从客户那里得到一个具体的软件范围。当然如果是一次全新的软件边界探索，就应当考虑软件本身可行性问题，包括团队是否具备在技术、财务、时间、资源上有可靠的保障，软件本身在市场上是否有可靠的竞争优势，等等。获得软件范围，最直接最可靠的来源就是用户对软件的需求描述。2.1.2规划的第二步：确定工作所需资源软件工作所需资源包括：工作环境（软硬件环境、办公室环境）、可复用软件资源（构件、中间件）、人力资源(包括各种不同角色的人员：分析师、设计师、测试师、程序员、项目经理)。这三种资源的组成比例，可以看作一个金字塔的模式，最上面是人力资源、其次是可复用软件资源、最下面是工作环境。最上面的是组成比

15、例最小的，最下面的是组成比例最大的部分。（1） 人力资源一个项目到底需要多少种职务的人员构成、多少数量的人员总量，才能成为最有创造力的团队呢？这恐怕是最让项目经理头疼的事情了。任何一个软件工程，都必须在确定软件的工作量之后，才能清楚地知道究竟需要多少人力才能以最小成本和最高效率完成任务。在这之前，不能盲目地进行人力扩充，而且绝对不能为了给公司抬高门面，盲目招收高学历。（2） 可复用软件资源这是一个容易在计划阶段被忽视的重要资源，很多人总是进入编码阶段才发现可复用资源的价值和存在。经过长期的项目积累或是购买，公司的软件资源库中或许已经积累了大量的可复用资源，但在当前任务中，只能选择有价值的资源。

16、（3） 环境资源“工欲善其事，必先利其器”，要得到高效的开发过程，就必须向工作人员提供良好的软硬件环境，包括开发工具、开发设备、工作环境、管理制度。一般管理人员都会购买可以满足需要的软件开发工具和硬件平台，但是工作环境和管理制度往往被忽视。站在人员的角度看，向工作人员提供更轻松自在、安静舒适的办公环境的公司，员工往往比整天在狭小隔间中工作的公司员工产生更高的工作效率。而那些拥有灵活人性化的管理制度的公司，比整天加班的公司更能留住高技术的人才。所以如何在有限资金中，规划一个合理的环境是很重要的事情。2.2估算的对象目前为止，一个较为准确的软件项目估算的定义是：在给定公差范围内，对于要开发的软件规

17、模的预测，以及对开发软件所需的工作量、成本和日历事件的预测。这个概念指出了一个事实，即估算是一种大约的估计，是将误差限定在一定范围内的估计。估算主要包括以下几个重要内容：（1）规模估算软件估算首先要将整个工程的规模估算出来，才能进行下面的其他估算。规模，就是一个工程可量化的结果，是用具体数字来体现项目的描述。规模估算的信息来源是清晰、有界限的用户需求。（2）工作量估算这是对开发软件所需的工作时间的估算，它和进度估算一起决定了开发团队的规模和构建。通常以人时、人天、人月、人年的单位来衡量，这些不同单位之间可以进行合理的转换。（3）进度估算进度时项目自始至终之间的一个时间段。进度以不同阶段的里程碑

18、作为标志。进度估算是针对以阶段为单位的估算，而不是对每一个细小任务都加以估算，对任务的适当分解很重要，分解得越细反而会不准确。因为任何一个软件工程，在各个方面都有与生俱来的不确定性。（4）成本估算包括人力、物质、有形的、无形的支出成本估算，其中以人力成本为主要部分。比较容易被忽视的是学习成本、软件培训成本、人员变动风险成本、开发延期成本等，一些潜在成本消耗。2.3 估算的策略在软件估算的众多方法中，存在着“自顶向下”和“自底向上”等几种不同的策略，这几种策略的出发点不同，适应于不同的场合使用。自顶向下、自底向上和差别估算法。自顶向下的方法是对整个项目的总开发时间和总工作量做出估算，然后把它们按

19、阶段、步骤和工作单元进行分配；自底向上的方法是分别估算每个工作单元所需的开发时间，然后汇总得出总的工作量和开发时间；差别估算是将开发项目与一个或多个已完成的类似项目进行比较，找出与某个类似项目的若干不同之处，并估算每个不同之处对成本的影响，导出开发项目的总成本。2.3.1 自顶向下的策略这是一种站在客户的角度来看问题的策略。它总是以客户的要求为最高目标，任何估算结果都必须符合这个目标。其工作方法是，由项目经理为主的一个核心小组根据客户的要求，确定一个时间期限，然后根据这个期限，将任务分解，将开发工作进行对号入座，以获得一个估算结果。当然由于这完全是从客户要求出发的策略，而由于软件工程是一个综合

20、项目，几乎没有哪个项目能完全保质保量按照预定工期完工，那么这样一个策略就缺少了许多客观性。但是由于这样完成的估算比较容易被客户，甚至被项目经理所接受，在许多公司我们看到这样一个并不科学的策略仍然被坚定地执行着。2.3.2 自底向上的策略与自顶向下的策略完全相反，自底向上的策略是一种从技术、人性的角度出发看问题的策略。在这样一个策略指引下，将项目充分讨论得到一个合理的任务分解。再将每个任务依照任务的难易程度与项目成员的特点、兴趣、特长进行分配，并按要求进行估算。最后将估算加起来就是项目的估算值。显然自底向上的这种策略具有较为客观的特点，但是它的缺点就是这样一来项目工期就和客户的要求不一致了。而且

21、由于其带来的不确定性，许多项目经理也不会采用这种方法。2.4 估算的方法显然估算是建立在客观实际上，对未来尽可能合理的一种预测。那么估算本身的不确定性，决定了它不可能是百分之百准确无误的。在项目刚开始时，人们对产品需求、技术、市场预期、人员素质等因素的了解还远远不够，在这种情况下人们很难做出准确的估计。但是依据某种方法进行估计显然比瞎猜好得多。软件规模度量和估算的根本目的是通过量化的分析与总结，提高软件项目的生产率、提高产品质量、降低成本和产品研发周期，尽可能的减少因错误估算给企业带来的损失。软件项目的规模估算和度量历来是比较复杂的事，因为软件本身的复杂性、历史经验的缺乏、估算工具缺乏以及一些

22、人为错误，导致软件项目的规模估算往往和实际情况相差甚远。估算错误已被列入软件项目失败的四大原因之一。因此对软件项目如何进行准确的规模评估研究是一个重要而迫切的问题。良好的规模度量方法应该满足以下几点准则:1)规模度量的有效性与程序开发所要求的时间紧密相关。2)规模度量必须精密，但不一定精确。3)应该能够自动计量。4)应该能够反映各种影响开发成本的环境状况。5)在规模度量和计数中能够反映新建、复用、删除、修改的代码以及它们的组合。6)度量必须在整个开发过程中随时能够应用。7)应对于各种类型的产品元素都能应用。常见的一些元素类型包括程序源代码、文档、报告、菜单、文件等等，但这一点要求非常难以实现。

23、 估算方法有很多，大致分为基于分解的技术和基于经验模型两大类。基于分解的技术的方法包括功能点估算法、LOC估算法、MARK II等；基于经验模型的方法包括IBM模型、普特南模型、COCOMO模型等。分解技术：当一个待解决的问题过于复杂时，可以进一步将其分解，直到分解后的问题容易解决为止。然后分别解决这些分解后的问题，通过综合其解答得到原有问题的解答。这是处理复杂问题的最自然的方法。2.4.1 FP功能点估算法功能点估算法是一种在需求分析阶段基于系统功能的一种规模估计方法。通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。这种方法的计算公式是：功能点=信息处理规模技术复杂度

24、。信息处理规模包括各种输入、输出、查询、内部逻辑文件数、外部接口文件数等等；技术复杂度包括性能复杂度、配置项目复杂度、数据通信复杂度、分布式处理复杂度、在线更新复杂度等等。2.4.2 LOC估算法这是一种从技术的角度来估算的方法总称，其中又包含许多方法。这类方法以代码（LOC）作为软件工作量的估算单位，在早期的系统开发中较为广泛使用。LOC是指所有的可执行的源代码行数，包括可交付的语句、数据定义、数据类型声明、等价声明、输入/输出格式声明等。一代码行（1LOC）的价值和人月均代码行数可以体现一个软件生产组织的生产能力，开发组织可以根据对历史项目的审计来核算组织的单行代码价值。基于LOC的估算，

25、既有优点也有缺点。优点在于方便计算、容易监控、能反映程序员的思维能力；缺点在于代码行数的含糊不清，不能正确反映一项工作的难易程度以及代码的效率。因此在传统的LOC方法进行了许多改进。其中不断被使用，且不断演化的方法包括以下：PERT功能点估算法：PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计，Pert 估计可得到代码行的期望值和标准偏差SD。 类比估算法：类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。类比法估

26、计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目评价与分析机制，从而使对历史项目的数据分析是可信赖的。 Delphi估算法：Delphi法是一种专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别。对于需要预测和深度分析的领域，依赖于专家的技术指导，可以获得较为客观的估算。通过专家们的互相讨论，还可以博取众长。 系统分解：将系统分成若干个易于用LOC估算的部分，将其各个估算结果累加就是LOC的总规模。其中关键是建立起SBS（系统分解结构），它描述了系统的不同组件。SBS还被使用在其他重要的地方，如系

27、统设计、系统分析等。在进行分解的时候，可以采用自由讨论的形式，可以获得更合理的SBS构成。LOC和FP是两个不同的估算技术。但两者有许多共同特性。项目计划人员首先给出一个有界的软件范围的叙述，再由此叙述把软件分解成一些小的可分别独立进行估算的子功能。然后对每一个子功能估算其LOC或FP（即估算变量）。接着，把生产率度量（如LOCPM或FPPM）用做特定的估算变量，导出子功能的成本或工作量。将子功能的估算进行综合后就能得到整个项目的总估算。LOC或FP估算技术对于分解所需要的详细程度是不同的。当用LOC作为估算变量时，功能分解是绝对必要的且需要达到很详细的程度。而估算功能点所需要的数据是宏观的量

28、，当把FP当作估算变量时所需要的分程度不很详细。应注意，LOC可直接估算，而FP要通过估计输入、输出、数据文件、查询和外部接口的数目间接地确定。 项目计划人员可对每一个分解的功能提出一个有代表性的估算值范围。利用历史数据或凭实际经验，对每个功能分别按最佳的、可能的、悲观的三种情况给出LOC或FP估计值，记作a、m、b。当这些值的范围被确定之后，也就隐含地指明了估计值的不确定程度，然后计算LOC或FP的期望值E。E（a4mb）6 （加权平均）一旦确定了估算变量的期望值，就可以用作LOC或FP的生产率数据。工作量估算是估算任何工程开发项目成本的最普遍使用的技术。每一个项目任务的解决都需要花费若干人

29、日、人月或人年，每一个工作量单位都对应于一定的货币成本，从而可以由此做出成本估算。 类似于LOC或FP技术，工作量估算开始于从软件项目范围抽出软件功能，接着给出为实现每一功能所必须执行的一系列软件工程任务，包括需求分析、设计、编码和测试。最后，计算每一个功能及软件项目的工作量和成本。将工作量估算与LOC估算得到的结果进行比较，如果结果一致则估算是可靠的，否则有必要做进一步的检查与分析。2.4.3 IBM模型估算法该模型是Watson和Felix在1977年发布的，是基于IBM联合系统分布负责的60个项目的总结而得到的模型。该模型是一个静态模型，而参考数据只有60多个项目，因此有很大的局限性。1

30、977年，Watson和Felix总结了IBM的60个项目数据，提出了如下的估算公式：E5.2L0.91， L是源代码行数（以KLOC计），E是工作量（以PM计）D4.1L0.362.4E0.35， D是项目持续时间（以月计）S0.54E0.6， S是人员需要量（以人计）DOC49L1.01， DOC是文档数量（以页计）2.4.4 COCOMO估算法Boehm在其经典著作“软件工程经济学”(software engineering economics)中，介绍了一种软件估算模型的层次体系，称为COCOMO(构造性成本模型，Constructive Cost Model)，它代表了软件估算的一个

31、综合经验模型。它是一种精确的、易于使用的成本估算方法，它分为基本COCOMO模型和中级COCOMO模型两种类型。基本COCOMO模型是一个静态单变量模型，它用一个已估算出来的源代码行数（LOC）为自变量的经验函数来计算软件开发工作量。中间COCOMO模型则在用LOC为自变量的函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。更详细的COCOMO模型除了包括中间COCOMO模型的所有特性外，还考虑了在需求分析、软件设计等每一步的影响。COCOMO模型是适用于三种类型的软件项目：(1)组织模式较小的、简单的软件项目，有良好应用经验的小型项目组，针

32、对一组不是很严格的需求开展工作(如，为一个热传输系统开发的热分析程序)；(2)半分离模式中等的软件项目(在规模和复杂性上)，具有不同经验水平的项目组必须满足严格的及不严格的需求(如，一个事务处理系统，对于终端硬件和数据库软件有确定需求)；(3)嵌入模式必须在一组严格的硬件、软件及操作约束下开发的软件项目(如，飞机的航空控制系统)。2.4.5 软件方程式估算法软件方程式是一个多变量模型，它假设在软件开发项目的整个生命周期中的一个特定的工作量分布。该模型是从4000 多个当代的软件项目中收集的生产率数据中导出的公式。初期的方程式较为复杂，通过，Putnam 和Myers的努力又提出一组简化的方程式

33、。当然这种方法也是基于长期的参考数据的积累而得到的。2.4.6 WBS估算法这是一种基于WBS（工作任务分解）的方法，即先把项目任务进行合理的细分，分到可以确认的程度，如某种材料、某种设备、某一活动单元等。然后估算每个WBS要素的费用。采用这一方法的前提条件或先决步骤是：对项目需求做出一个完整的限定。 制定完成任务所必需的逻辑步骤。 编制WBS表。项目需求的完整限定应包括工作报告书、规格书以及总进度表。工作报告书是指实施项目所需的各项工作的叙述性说明，它应确认必须达到的目标。如果有资金等限制，该信息也应包括在内。规格书是对工时、设备以及材料标价的根据。它应该能使项目人员和用户了解工时、设备以及

34、材料估价的依据。总进度表应明确项目实施的主要阶段和分界点，其中应包括长期定货、原型试验、设计评审会议以及其他任何关键的决策点。如果可能，用来指导成本估算的总进度表应含有项目开始和结束的日历时间。 除了以上介绍的几种方法外，还有一些其他的方法：类比估算、推测估算、Standard-component估算法、普特南估算法等。类推估算法是比较科学的一种传统估算方法，它适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。类推估算法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类推估算法的前提条件之一是组织建立起较好的项目后评价与分析机制，

35、使得对历史项目的数据分析是可信赖的。这种方法的基本步骤是：整理出项目功能列表和实现每个功能的代码行；标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方；通过步骤1和2得出各个功能的估计值；产生规模估计。当然不同的方法适用于不同的具体环境，有些方法虽然很好但并不一定适合当前的任务。只有量体裁衣，具体问题具体分析，才能得到尽量合理的估算。3 重点方法详述及功能点扩展改进方法以上是对软件估算的综述，以下我们重点讨论功能点估算方法，并针对其缺点提出两种改进措施，在最后还会结合算法模型法、专家小组法和类比估算法提出一种新的度量策略。规模是软件的一个重要属性，是成本估计和生产率

36、分析的重要参数，对于软件开发和软件项目管理而言，在开发的早期进行规模估计的要求都很迫切。但这时有关软件的信息还很少，没有编码可供度量，因此出现了试图从功能角度度量规模的功能点FP（function points）。但是，功能点固有的缺陷与不足限制了它的使用。在此提出的扩展功能点EFP（extended FP）从根本上解决了功能点方法的缺陷。在此将系统地讨论扩展功能点模型，这是对功能点方法的第一种改进策略。3.1功能点Albrecht 于1979年提出了功能点，以求在开发的早期度量软件的规模，而后又于1983年改进了功能点，使的功能点由5个功能分量和一批调整因子组成。这5个功能分量分别是外部输入

37、EI、外部输出EO、外部接口文件EIF、内部逻辑文件ILF和查询EQ。5个功能分量的加权累加就是未调整的功能点，再应用14个调整因子可得到调整的功能点。本文讨论的功能点就是1983年Albrecht改进的功能点。1986年，SPR改进功能点后得到特征点(feature points)，使其适用于非信息处理领域。1994年，波音公司提出了3维功能点-3DFP，即所谓的三维是指数据、功能处理和控制。3.2 功能点存在的问题虽然功能点已取得了广泛的应用，但细心的研究会发现它存在如下一些问题：（1）功能点的应用领域具有一定的局限性。 功能点主要是针对信息处理系统而设计的，因此其应用领域有很大的局限性。

38、（2）功能点度量元素不完整，或者说度量元素的概念间存在重叠。功能点定义系统的用户输入为维护ILF的EI和不维护ILF的输入（简记为UI）两类。功能点明确指出要计算EI，但并没有明确指出要计算UI，只是在计算EQ时提到。这说明可能根本不计算UI，使得功能点度量元素在概念上不完整；也可能是在计算EQ的同时计算了UI，这说明UI是EQ的一个组成部分，因此，功能点元素概念间有重叠。（3）功能点中ILF和EIF的定义不清晰，不便于实际操作。什么是文件？什么是数据的逻辑组？这使得ILF和EIF的定义模糊。（4）实际上往往无法得知某一个外部输入是否出自于另一个系统的内部逻辑文件。功能点定义EIF必须同时又是

39、另一个应用系统的ILF，而实际上这往往无法验证。（5）查询被定义为一个处理，却被描述为一个事务。功能点把外部查询定义为一个映射（I,O）对，也就是一个功能处理，可实际查询时却被描述为事务。扩展功能点EFP扩展功能点EFP从功能点角度度量软件的规模，独立于开发所使用的语言，一旦获得了用户功能需求FUR（functional user requirements），就可以用它来度量规模。下面先讨论功能规模度量的特征，然后分析EFP的问题域模型，并从问题域模型中获得EFP的基本功能块BFC（base functional component）类型，同时给出各个BFC类型的定义和度量方法，最后介绍EFP

40、计算模型。3.4 功能规模度量ISO/IEC 14143是有关功能规模度量FSM（functional size measurement）的标准，它用于评价某种规模度量方法是否为FSM方法，该标准要求一个FSM方法满足：基于用户功能需求FUR度量软件的规模；一旦得到了FUR，就可以应用它来度量规模；通过对BFC的评价可以得到软件的功能规模。BFC是FSM方法基于用户功能需求FUR定义的基本单元，它具有以下特征： 只描述FUR； 不描述任何有关技术需求的信息； 不描述任何有关质量需求的信息； 任何一个BFC都可以被识别为一个BFC类型，并且只能识别为一个类型。3.5 EFP 问题域模型FSM方法

41、从功能角度来度量软件的规模，因此，EFP的问题域就是软件的用户功能。软件对于用户就是一个黑盒，而用户关心的是软件需要用户提供哪些输入，同时能为用户返回哪些输出，软件就是一个把用户输入转换成用户输出的机构，其中用户输入和用户输出都是由用户定义的，因此转换功能也是由用户定义的。有些用户输入对于用户具有特殊的意义，用户希望软件能够将这些数据保存起来，以便更好地实现用户提出的功能。这些数据，我们可称为用户数据实体，虽然保存在软件的内部，但却是由用户提供的，因而由用户维护和使用。由于用户数据实体直接与用户输入、用户输出和用户功能相关，因此它对于软件规模的影响将不能被忽略。这样，我们最终得到EFP问题域的

42、4个元素-用户输入、用户输出、用户功能和用户数据实体。为了有效的识别用户和软件之间的关系，我们为软件定义一个概念边界。由此，用户输入就是穿过边界去往软件的输入，用户输出就是穿过边界去往用户的软件输出。同理，根据计算机科学理论，用户功能就是用户输入到用户输出的映射，为便于后面的讨论，我们将用户输入和用户输出更名为外部输入和外部输出，所谓“外部”是相对于这个概念边界而言的。这样，我们就得到了如图1和式（1）所示的EFP问题域模型。 EI Boundary EO 边界。 图1 EFP问题域图示模型 Domain = (EI, EO, UP, UDE, Boundary)p; AI Shell 49

43、Forth 64 APL 32 Jovial 105 Assembly (Macro) 320 Lisp 105 ANSI/Quick/Turbo Basic 213 Modula 2 80 Basic-Complied 64 Pascal 91 Basic-Interpreted 91 Prolog 64 C 128 Report Generator 80 C+ 29 Spreadsheet 6 ANSI Cobol 85 91 4 第二种改进方法以上是扩展功能点方法对功能点度量法的改进，下面再介绍一种针对中国软件企业普遍存在需求规格说明书不规范、实施功能点分析非常困难的实际情况,在此提出了

44、一种改进方法,使用UML技术中的用例来生成规范的需求规格说明书，利用用例进行功能点分析。用例模型是对用户功能需求规范化的描述。通过全面定义用例模型，可以把用户对系统的功能需求,用比较规范的形式准确地表达出来。功能点可以认为是系统用例,系统用例模型是从业务用例模型和业务对象模型中提取出来的。业务对象模型提供对每个业务用例的实现，每个业务用例是一个业务的需求，解决一个业务问题或提供一个业务机遇。功能点的完整性实际上就是保证用户确认的业务问题得到解决，业务机遇得到获取的满足程度。需求规格说明书应该列出所有的系统用例，如果这些系统用例达到了上述要求，这个用例列表就是要“提炼”的功能点列表。4.1 先介

45、绍功能点的优缺点使用功能点分析具有以下优点:1)规模可在项目初期确定；2)可作为度量生产率改进的基准；3)独立于开发工具和环境，因而可用于衡量各种工具和环境下的生产率；4)提供各个项目间一致的规模度量方法。其缺点是:1) FPA的使用在RET和GSC的估算上是主观的，因其主观性使估算结果因人而异。2) FPA假设全部是部分的和，也就是说，分解系统的功能性，分别估算，然后用他们的和来反映整个系统。但事实并非如此，这也是任何分解法的弊端。一个复杂的系统采用的分析方法应比其各部分的和复杂得多，因为需要考虑各部分的集成。3)对复杂度重视不够。程序处理逻辑可能包含复杂的算法和计算，这可能耗费大量工作量而

46、且隐含复杂度。该方法极其重视用户所见所得，而用户接触不到的逻辑处理的复杂度和所需工作量都被低估了，因为他们对用户来讲是不可见的。4) FPA只把复杂度粗略的分成三种类型(简单、一般、复杂)，这种描述过于简单，也丢失一些细节。虽然粗略分类使这种方法简单易用，但很不准确，因为忽略了同一类型的较高端和较低端之间的差别。5)这种方法在区分简单、一般、复杂类型的界线是极不妥当的，只要增加一个条目就能使整个系统的估算值变化很多。另一方面，它也很难扩展，因为对于无论多细的类别其最高复杂度的权重都是一样的(所有分类的最高等级都是公开的)。6)功能点不是实际的规模度量，它是在简化系统基础上的静态度量，它取决于分

47、类的定义以及这些定义如何解释，这也是确定功能点计算的定义和解释。与代码行方法相比，功能点度量最大的优势就是可以在项目的早期进行规模度量和估算。理论上，只要有了详尽的需求规格说明书，就能够准确地估算出项目的规模。但是在实践中我们发现，在需求阶段进行功能点度量存在很大困难，主要包括以下几个方面:1)需求规格说明书不规范。在国内许多软件企业中，软件开发过程中的需求分析往往被当作一个可有可无的步骤而不受重视，甚至许多项目根本就不做需求分析，直接进入设计阶段。同时，绝大多数的开发人员都没有受过与需求的抽象、分析、文档、质检有关的教育。另外，也很难找到好的需求可以借鉴学习。尽管大多数的开发都采用了典型场景

48、的方法，但它极少用有效的形式归档。造成有许多项目根本没有需求说明书，有的项目为了应付客户的要求，采取软件开发完毕后补写需求说明书的手段。虽然有些企业比较重视软件工程，在设计之前形成了需求说明书，但内容极不规范，这就给项目的规模度量和估算带来极大困难，也严重影响后续的成本和工作量度量，极易造成项目失控。2)功能分解随意性较大。由于没有统一的规定和约束，在进行功能点度量时如何进行功能分解，成为制约功能点度量的准确性和客观性的一个主要方面。对同一个项目，不同的度量人员往往会得出相差甚远的不同结果。主要原因就在于功能分解的完整性和不重复性很难把握，如何从需求分析说明书中准确提炼出系统的全部功能，并且保

49、证在计算时没有重复计算，在实际操作中存在很大困难。4.2 下面介绍一种利用UML建模技术对功能点度量模型的改进方法针对以上问题，提出一种改进方法，即使用UML中的用例建模技术来解决功能需求的规范化问题，这样，功能点可以认为是系统用例，需求规格说明书中建立的用例列表就是要“提炼” 的功能点列表。通过用例进行功能点分析是因为二者有内在的联系，功能点是从需求的角度度量软件规模，而用例是捕获需求的方法。功能点和用例都试图实现与软件的具体实现技术的无关性，用例可以验证提交的设计是否包含了所有的需求，用例的另一个优点是用例可以在生命周期的早期定义需求。如果用例很早就产生出来，然后进行功能点度量，对项目的估

50、算和度量值就会精确得多。功能点分析将系统分解成更小的部件，以便用户、开发人员、项目经理能够更好地理解系统功能。用例同样采用了分解的方法，而且用例方法也是从用户实际使用系统的角度捕获需求，与系统如何实现这些功能无关。这就意味着通过用例形成的需求文档可以用于功能点分析(规模度量)。使用用例方法，可以在项目生命周期的早期准确度量规模，从而就能更好地估算和度量进度以及成本。另外，如果用例保持更新，功能点分析也保持更新，那么对项目进行的估算和度量也就可以容易地进行更新并对变更进行说明。Meli曾经提出，用例己经变成一个捕获用户需求的一般方法，因为用例是从用户的角度描述功能，他们应该很容易转换成功能点。但

51、他没有给出具体的方法，而且对什么样的用例可以用于功能点分析也没有涉及。本文详细阐述用例如何形成需求，并且提出了只有系统用例才适合用于功能点分析的观点。4.2.1 UML简介：UML是统一建模语言的缩写，是三位最优秀的面向对象方法学的创始人Rumbaugh, Booch和Jacobson合作成果的结晶。UML在己有的三大面向对象方法学的基础上，抽象出表示它们的模型语言，并吸取了其它面向对象开发方法和近30年软件工程的成果。1997年11月被批准成为面向对象开发的行业标准语言。到目前为止，UML已获得了工业界、科技界和应用界的广泛支持，成为可视化建模语言事实上的工业标准。UML是一种通用的可视化建

52、模语言，它支持面向对象的分析设计和从需求分析开始的软件开发的全过程。UML的概念及模型可以分成以下几类:(1)静态结构UML的静态结构描述了系统中的结构成员及其相互关系。系统的结构成员即类元，包括类、用例、构件和节点，为研究系统动态行为奠定了基础。静态视图包括类图、用例图、构件图和部署图。(2)动态行为动态行为描述了系统随时间变化的行为。动态行为又分为两种:一种是一个孤立对象的工作流程及状态的变化，对应的视图分别为活动图和状态机图；另一种是一系列相关对象之间交互作用时的通信，交互视图包括顺序图和协作图。(3)模型组织管理模型组织管理说明了模型的分层组织结构。包是模型的基本组织管理单元，用于存储

53、、访问控制、配置管理及构造包含可重用的模型单元库。模型的组织管理用类图来实现，但又跨越了其它视图并根据系统开发和配置组织这些视图。包之间的依赖关系是对包的组成部分之间的依赖关系的归纳，系统整个架构可以在包之间施加依赖关系。因此，包的内容必须符合包的依赖关系和有关的架构要求。(4)扩展机制UML还包括多种具有扩展能力的组件，这些组件的扩展能力有限但很有用。这些组件包括约束、构造型和标记值，它们适用于所有的视图元素。4.2.2 用例(Use Case)(1)用例模型(Use case model)长期以来，在传统的软件开发和面向对象开发中，人们根据典型的使用情景来了解需求。但是，这些使用情景是非正

54、式的，虽然经常使用，却难以建立正式文档。用例模型由Ivar Jacobson在开发AXE系统中首先使用，并加入由他所倡导的DOSE和Objectory方法中。用例方法引起了面向对象领域的极大关注。自1994年Ivar Jacobson的著作出版后，面向对象领域己广泛接纳了用例这一概念，并认为它是第二代面向对象技术的标志。用例模型抽述的是外部执行者(Actor)所理解的系统功能。用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。首先，它描述了待开发系统的功能需求；其次，它将系统看作黑盒，从外部执行者的角度来理解系统；第三，它驱动了需求分析

55、之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段和UML的各个模型。在UML中，一个用例模型由若干个用例图描述，用例图主要元素是用例和执行者。(2)用例(use case)从本质上讲，一个用例是用户与计算机之间的一次典型交互作用。以字处理软件为例，“将某些正文置为黑体”和“创建一个索引”便是两个典型的用例。在UML中，用例被定义成系统执行的一系列动作，动作执行的结果能被指定执行者察觉到。概括地说，用例有以下特点:用例捕获某些用户可见的需求，实现一个具体的用户目标。用例由执行者激活，并提供确切的值给执行者。用例可大可小

56、，但它必须是对一个具体的用户目标实现的完整描述。(3)执行者(Actor)执行者是指用户在系统中所扮演的角色。其图形化的表示是一个小人。在某些组织中很可能有许多营销人员，但就该系统而言，他们均起着同一种作用，扮演着相同的角色，所以用一个执行者表示。一个用户也可以扮演多种角色(执行者)。例如，一个高级营销人员既可以是贸易经理，也可以是普通的营销人员；一个营销人员也可以是售货员。在处理执行者时，应考虑其作用，而不是人或工作名称，这一点是很重要的。不带箭头的线段将执行者与用例连接到一起，表示两者之间交换信息，称之为通信联系。执行者触发用例，并与用例进行信息交换。单个执行者可与多个用例联系；反过来，一

57、个用例可与多个执行者联系。对同一个用例而言，不同执行者有着不同的作用，他们可以从用例中取值，也可以参与到用例中。需要注意的是，尽管执行者在用例图中是用类似人的图形来表示的，但执行者未必是人。例如，执行者也可以是一个外界系统，该外界系统可能需要从当前系统中获取信息，与当前系统有进行交互。通过实践，我们发现执行者对提供用例是非常有用的。面对一个大系统，要列出用例清单常常是十分困难。这时可先列出执行者清单，再对每个执行者列出它的用例，问题就会变得容易很多。(4)使用和扩展(Use and Extend)还有另外两种类型的连接，用以表示用例之间的使用和扩展关系。使用和扩展是两种不同形式的继承关系。当一

58、个用例与另一个用例相似，但所做的动作多一些，就可以用到扩展关系。例如基本的用例是“进行交易”。交易中可能一切都进行得很顺利，但也可能存在扰乱顺利进行交易的因素。其中之一便是超出某些边界值的情况。例如，贸易组织会对某个特定客户规定最大贸易量，这时不能执行给定用例提供的常规动作，而要做些改动。我们可在“泊7交易”用例中做改动。但是，这将把该用例与一大堆特殊的判断和逻辑混杂在一起，使正常的流程晦涩不堪。将常规的动作放在“进行交易”用例中，而将非常规的动作放置于“超越边界的交易”用例中，这便是扩展关系的实质。当有一大块相似的动作存在于几个用例，又不想重复描述该动作时，就可以用到使用关系。例如，现实中风

59、险分析和交易估价都需要评价贸易，为此可单独定义一个用例，即“评价贸易”，而“风险分析”和“交易估价”用例将使用它。请注意扩展与使用之间的相似点和不同点。它们两个都意味着从几个用例中抽取那些公共的行为并放入一个单独用例中，而这个用例被其他几个用例使用或扩展。但使用和扩展的目的是不同的。4.2.3 实现步骤：用例捕获用户需求（1）捕获执行者利用UML的技术进行功能需求分析时，第一步要做的是确定系统有哪些执行者。获取用例首先要找出系统的执行者，这可以通过用户对开发方所提的一些问题的答案来确定。以下问题可供参考:. 谁将要提供、使用或修改信息?. 谁将用到这些功能?. 谁对某些需求感兴趣?. 系统将交

60、付哪个部门使用?. 谁将负责对系统的支持和维护?. 哪些是系统的外部资源?.要与系统进行交互的其它系统有哪些?（2）捕获用例执行者确定后，下一步的工作是捕获用例。同样，开发方也是通过提出问题的方法来获取用例。不同的是，这一次的问题主要由执行者来回答。主要的问题如下：. 执行者要求系统提供哪些功能(执行者需要做什么)?. 执行者需要读、产生、删除、修改或存储哪些信息?. 执行者要通知系统突发的、外部的事件有哪些?. 系统要通知执行者的事件有哪些?. 执行者是否要负责系统的启动和关闭?还有一些不针对具体执行者问题(即针对整个系统的问题)。. 系统需要何种输入/输出?输入从何处来?输出到何处?. 当

61、前运行系统(也许是一些手工操作而不是计算机系统)的主要问题?. 已定义的用例集是否已包括系统的所有功能?需要注意的是：最后两个问题并不是指没有执行者也可以有用例，只是获取用例时尚不知道执行者是什么。一个用例必须至少与一个执行者关联。还需要注意的是，不同的设计者对用例的利用程度也不同。重要的是：在捕获用例时，心中一直所想的应该是系统要做什么，而不是系统应该怎么做。2、建立用例模型用例模型是使用UML进行功能需求分析的最终结果，是以用例图的方式来显示的。用例模型表示了系统与外界环境的交互及系统的主要功能。在这个阶段，为了画出用例图，可以考虑开发界面原型以定义边界。在用例图中，除了标志执行者与用例之

62、间的联系外，还要标志用例之间的关系。3、利用用例建立需求规格说明书用例模型有两种基本风格：业务用例模型和系统用例模型。业务用例模型，通常称为基本或抽象用例模型，对行为需求的与技术无关的视图建模。而系统用例模型，也称为具体用例模型或详细用例模型，为行为需求的分析建模，详细描述用户将如何使用系统，同时它还提及系统用户接口方面的问题。在建立需求规格说明书的过程中，用例模型要经过由基本模型向系统模型的转换，它是分步骤、分层次的，大致过程如下表7:表7 需求细化级别 步骤 需求 1 业务需求最初很低级别的用例 2 界面规格说明书引入界面绑定时的级别 3 更多细节更多级别上的用例 4 完整的详细规格说明书用例的最终级别 由表中可以看出，在建立需求规格说明书的过程中，用例的粒度级别是逐渐细化的。也就是说，首先编写业务用例作为所需的构思工作的一部分，然后在分析期间，将它们发展成系统用例。4、系统用例还是业务用例？下面对系统用例和业务用例进行对比分析。二者有以下一些区别:系统用例嵌入了很多细节。系统用例提及屏幕和报告。因为业务规则反映系统必须实现的域的基本特征，所以两种版本都引用业务规则定义。系统用例的步骤比业务用例的步骤多。实际上，每个用例步骤应该只反映一个步骤。这样做有几个优点：用例