一、选题目的和意义
选题的目的：随着软件行业的逐渐成熟，人们越来越深刻地认识到，必须充分理解技术、方法和有效的应用人力资源。软件估算尤其是成本估算是有效监控软件进度的关键部分之一。软件估算是在软件开发和维护范畴内定性、定量估算指标的定义、收集、整理、分析和呈报。软件成本估算显示了人们对生产率和质量深刻的认识，是在软件问题领域综合应用技巧、技术和方法而取得的成果。对软件人力成本的估算就是基于项目的规模、工作量而对人力成本的估算过程。由于软件本身的特性，很难收集项目的需求和估算。软件作为概念在早期很难确定规模，但估算便是要在早期做出来并确定项目的整个过程。估算开始于对项目需求和项目所处的环境及所作的假设的理解。然后，软件规模要以某种合适的方法进行量化处理。得到产品规模后，工作量以及人力成本的估算便可相应得出。
选题的意义：通过写软件人力成本估算范文使我更加全面的了解和掌握关于有关软件成本估算的知识，并对已有的估算方法提出一些改进，并且希望通过这次的实践来运用所学知识，来培养我的动手能力和合作能力，故选择软件人力成本估算作为我的文档课题。
二、本选题在国内外的研究现状和发展趋势
有许多用于软件成本估算的技术，从早期代码行估算方法发展到以后的功能点度量方法。这期间有代表性的方法有MARK II、IBM模型、普特南模型、COCOMO模型等。本文主要对功能点度量方法作了介绍，并且针对功能点度量方法本身的缺陷提出了两种改进措施，一种是使用UML中的用例建模技术来解决需求的规范化问题；另一种是扩展功能点。扩展功能点从功能角度度量软件的规模，独立于开发所使用的语言。一旦获得了用户功能需求就可以用它来度量规模。最后本文通过比较几种软件成本估算方法的优缺点，提出了一种新的软件成本估算方法：将算法模型、专家小组法和类比估算法结合起来，互相取长补短，由层次分析法得到各种估算法的权重，再由权重合成法得到估算成本。
从现在的需求形式来看，该课题的研究会日趋合理，这方面的研究会不断完善，好的人力成本估算方法应该能够比较准确的估计出软件开发过程中的人力成本。由于估算本身的不确定性，决定了它不可能是百分之百准确无误的。但是，估算结果与实际开发使用的人力成本的接近程度可以作为判断估算方法的优劣的标准。
三、课题设计方案 [主要说明：研究（设计）的基本内容、观点及拟采取的研究途径。]
1.研究的基本内容：
(1)人力成本估算的定义。
(2)软件成本估算中的人力成本。
(3)软件人力成本估算的概述。
(4)软件人力成本估算的规划、对象、策略与方法。
(5)重要估算方法的描述。
(6)对估算方法的改进，新方法的提出。
2.基本观点：
软件开发中的人力成本，是在软件开发过程中为了开发出满足客户要求的产品必须为开发过程中使用的人力资源支付的那一部分资金，它在软件开发成本中占相当大的一部分。对于这一部分成本的估计也就是人力成本估计。这部分成本的估计，首先要估算出软件的规模得出工作量然后根据当前的开发人员的工资水平估计出人力资源成本。
3.方法：
理论研究与实践相结合，把对这个问题的看法以及所应该注意的问题进行有效的阐述和分析，得出可行有效的结果。参考国内外已经取得的研究成果，认真阅读参考资料。
四、计划进度安排 [主要说明：起止时间及分阶段的进度要求。]
阶段 开始时间 结束时间 进度说明
第一阶段 2006.1上旬 2006.2下旬 搜集资料，熟悉相关内容，完成文档设计开题报告。
第二阶段 2006.3上旬 2006.4下旬 对该题目进行综合全面的分析，形成自己的观点和想法，达到对该问题的全面了解和掌握。
第三阶段 2006.5上旬 2006.5下旬 整合汇总，提交
每阶段都给出应的文档，最后整理提交。
五、主要参考文献
[1] Roger S. Pressman.（美）软件工程——实践者的研究方法．第五版．北京：机械工业出版社，2002．
[2] Swapna Kishore ,Rajesh Naik．（印）软件需求与估算．第一版．北京：机械工业出版社，2004．
[3] Frederick P. Brooks，Jr．（美）人月神话．第三版．北京：清华大学出版社，2003．
[4] 陈松乔，任胜兵，王国军等．现代软件工程．第一版．北京：清华大学出版社，2004．
[5] 王强，曹汉平，贾素玲，木林森等．IT软件项目管理．第一版．北京：清华大学出版社，2004．
[6] 李帜，林立新，曹亚波等．功能点分析方法与实践．第一版．北京：清华大学出版社，2005．
指导教师意见及建议
摘要：软件估算，就是结合目前各种实际情况，提供项目中的软件规模、工作量和人力成本的最可能合理的模型。本文主要对功能点度量方法作了介绍，并且针对功能点度量方法本身的缺陷提出了两种改进措施，一种是使用UML中的用例建模技术来解决需求的规范化问题；另一种是扩展功能点。扩展功能点从功能角度度量软件的规模，独立于开发所使用的语言。一旦获得了用户功能需求就可以用它来度量规模。最后本文通过比较几种软件成本估算方法的优缺点，提出了一种新的软件成本估算方法：将算法模型、专家小组法和类比估算法结合起来，互相取长补短，由层次分析法得到各种估算法的权重，再由权重合成法得到估算成本。
关键词：功能点，扩展功能点，用例，用例模型，事务，用户功能需求 ，基本功能块
1 引言
随着软件行业的逐渐成熟和软件工程概念的日益深入人心，人们越来越深刻地认识到软件度量的重要性。软件度量是在软件开发和维护范畴内定性、定量度量指标的定义、收集、整理、分析和呈报。软件度量体系显示了人们对生产率和质量深刻的认识，是在软件问题领域，综合应用技巧、技术和方法而取得的成果。软件度量的根本目的是通过量化的分析与总结，帮助我们提高生产率，提高产品质量，降低成本和产品研发周期。从国际上度量活动的典范来看，度量活动给组织和项目所带来的收益远远大于度量活动所耗费的成本。常用软件度量包括规模度量、成本度量、工作量度量、进度度量、生产率度量、风险度量等，其中对规模的度量和估算是所有度量活动的基础，其结果可作为其它度量的一个主要输入，因此在软件度量活动中具有重要地位。其中的人力成本的估计也需要有以上的度量作为前提数据。随着经济的不断发展，现代经济的经济结构由以生产型为主向科技服务型为主的转变已经成为一种趋势。这一转变使得人力资源在企业生产经营和国家经济发展中所起的作用变得更为关键。加之国际竞争的日渐激烈亦使得人们对人力资源更加重视起来。人力资源是指在一定区域内的人口总体所具有的劳动能力的总和，是存在于人的自然生命机体中的一种国民经济资源。而企业为获得人力资源和优秀的人才，就需要很多的投资，这种投资在企业中就体现为人力资源成本。当前，科学技术突飞猛进，信息革命和网络经济使市场呈现全球化趋势，企业间的竞争日趋激烈，人才便成为不可或缺的驱敌制胜的法宝之一。从而，人才、人力资源、人力资源成本、人力资本被提到了新的议程。在过去相当一段历史时期，中国企业的快速成长和发展，主要依靠“人海战术”和资源的大量投入。而中国经济发展到今天，随着各行业的平均利润率越来越低，竞争越来越白热化，市场空白越来越少。在这种条件下，过去的粗放式人海战术由于其管理成本居高不下已经走到了尽头。所以如何从粗放式的人海战术到精兵强将就成了一个重要的问题。
因为，软件人力成本估算要以对软件的规模估算为基础，即需要先估算出软件的规模或者说需要先估算出开发软件所需要的工作量才能对软件人力成本做一个估算。因此，我们进行软件人力成本估算就是要在先估算出软件规模的基础上得出对软件的人力成本的估算。
2 认识软件估算
虽然估算是一门科学，更是一门艺术，这个重要的活动不能以随意的方式来进行，因为估算是所有其他项目计划活动的基础，而项目计划又提供了通往成功的软件工程的道路图，所以，没有它我们就会搭错车。——Roger S. Pressman 《软件工程——实践者的研究方法》
软件不同于常见的生活用品。开发软件主要用人们的脑子，不需要开工厂，无需原材料，也不需要放到百货商店的柜台上销售。一般地，开发成本和维护成本是软件的主要成本构成。除了软硬件基础设施的成本外，人力资源成本占了开发成本的主要比例。人力资源成本等于雇员的工资乘以工作时间，所以企业招聘员工的理想状态是：以最低的工资招聘恰好满足工作需要的人。另外，设法提高工作效率以减少总的开发时间，从而降低人力资源成本。
2.1 估算前的规划
当我们的办公室内堆满了杂乱无章的文件时，恐怕无法知道对于我们真正有用的文件在哪里，当我们的软件项目中收集了各种需求、意见、问题时，我们也很难从中估算出整个项目的规模、工作量以及成本。因此，在估算之前我们首先要对众多信息进行整理、归类、分析，从而得到一个条理清晰的项目计划，在这个计划提供的框架内，才可能开始正确的估算。精心的规划是任何一个软件开发项目成功与否的关键，有了规划就有如成竹在胸，之后无论风云变幻，都有应对如流的方法。当然只有正确的规划，才能给软件开发指引正确的方向。
软件项目规划的重点是对人员角色、任务进度、经费、设备资源、工作成果等等做出合适的安排，制定出一些计划（包括高层的和细节的），使大家按照计划行事，最终顺利地达到预定的目标。
2.1.1 规划的第一步：确定软件范围
确定软件范围，就是确定目标软件的数据和控制、功能、性能、约束、接口以及可靠性。这项工作和需求分析是很类似的，如果之前已经达成需求分析规约，那么可以直接从《需求分析说明书》中把有用的部分拿来使用。如果还没有开始需求分析，关于确定软件范围的方法方面，我们可以采用许多需求分析技术（如需求诱导），从客户那里得到一个具体的软件范围。当然如果是一次全新的软件边界探索，就应当考虑软件本身可行性问题，包括团队是否具备在技术、财务、时间、资源上有可靠的保障，软件本身在市场上是否有可靠的竞争优势，等等。获得软件范围，最直接最可靠的来源就是用户对软件的需求描述。
2.1.2规划的第二步：确定工作所需资源
软件工作所需资源包括：工作环境（软硬件环境、办公室环境）、可复用软件资源（构件、中间件）、人力资源(包括各种不同角色的人员：分析师、设计师、测试师、程序员、项目经理……)。这三种资源的组成比例，可以看作一个金字塔的模式，最上面是人力资源、其次是可复用软件资源、最下面是工作环境。最上面的是组成比例最小的，最下面的是组成比例最大的部分。
（1） 人力资源
一个项目到底需要多少种职务的人员构成、多少数量的人员总量，才能成为最有创造力的团队呢？这恐怕是最让项目经理头疼的事情了。任何一个软件工程，都必须在确定软件的工作量之后，才能清楚地知道究竟需要多少人力才能以最小成本和最高效率完成任务。在这之前，不能盲目地进行人力扩充，而且绝对不能为了给公司抬高门面，盲目招收高学历。 （2） 可复用软件资源
这是一个容易在计划阶段被忽视的重要资源，很多人总是进入编码阶段才发现可复用资源的价值和存在。经过长期的项目积累或是购买，公司的软件资源库中或许已经积累了大量的可复用资源，但在当前任务中，只能选择有价值的资源。
（3） 环境资源
“工欲善其事，必先利其器”，要得到高效的开发过程，就必须向工作人员提供良好的软硬件环境，包括开发工具、开发设备、工作环境、管理制度。一般管理人员都会购买可以满足需要的软件开发工具和硬件平台，但是工作环境和管理制度往往被忽视。站在人员的角度看，向工作人员提供更轻松自在、安静舒适的办公环境的公司，员工往往比整天在狭小隔间中工作的公司员工产生更高的工作效率。而那些拥有灵活人性化的管理制度的公司，比整天加班的公司更能留住高技术的人才。所以如何在有限资金中，规划一个合理的环境是很重要的事情。
2.2估算的对象
目前为止，一个较为准确的软件项目估算的定义是：在给定公差范围内，对于要开发的软件规模的预测，以及对开发软件所需的工作量、成本和日历事件的预测。这个概念指出了一个事实，即估算是一种大约的估计，是将误差限定在一定范围内的估计。
估算主要包括以下几个重要内容：
（1）规模估算
软件估算首先要将整个工程的规模估算出来，才能进行下面的其他估算。规模，就是一个工程可量化的结果，是用具体数字来体现项目的描述。规模估算的信息来源是清晰、有界限的用户需求。
（2）工作量估算
这是对开发软件所需的工作时间的估算，它和进度估算一起决定了开发团队的规模和构建。通常以人时、人天、人月、人年的单位来衡量，这些不同单位之间可以进行合理的转换。
（3）进度估算
进度时项目自始至终之间的一个时间段。进度以不同阶段的里程碑作为标志。进度估算是针对以阶段为单位的估算，而不是对每一个细小任务都加以估算，对任务的适当分解很重要，分解得越细反而会不准确。因为任何一个软件工程，在各个方面都有与生俱来的不确定性。
（4）成本估算
包括人力、物质、有形的、无形的支出成本估算，其中以人力成本为主要部分。比较容易被忽视的是学习成本、软件培训成本、人员变动风险成本、开发延期成本等，一些潜在成本消耗。
2.3 估算的策略
在软件估算的众多方法中，存在着“自顶向下”和“自底向上”等几种不同的策略，这几种策略的出发点不同，适应于不同的场合使用。自顶向下、自底向上和差别估算法。自顶向下的方法是对整个项目的总开发时间和总工作量做出估算，然后把它们按阶段、步骤和工作单元进行分配；自底向上的方法是分别估算每个工作单元所需的开发时间，然后汇总得出总的工作量和开发时间；差别估算是将开发项目与一个或多个已完成的类似项目进行比较，找出与某个类似项目的若干不同之处，并估算每个不同之处对成本的影响，导出开发项目的总成本。
2.3.1 自顶向下的策略
这是一种站在客户的角度来看问题的策略。它总是以客户的要求为最高目标，任何估算结果都必须符合这个目标。其工作方法是，由项目经理为主的一个核心小组根据客户的要求，确定一个时间期限，然后根据这个期限，将任务分解，将开发工作进行对号入座，以获得一个估算结果。
当然由于这完全是从客户要求出发的策略，而由于软件工程是一个综合项目，几乎没有哪个项目能完全保质保量按照预定工期完工，那么这样一个策略就缺少了许多客观性。但是由于这样完成的估算比较容易被客户，甚至被项目经理所接受，在许多公司我们看到这样一个并不科学的策略仍然被坚定地执行着。
2.3.2 自底向上的策略
与自顶向下的策略完全相反，自底向上的策略是一种从技术、人性的角度出发看问题的策略。在这样一个策略指引下，将项目充分讨论得到一个合理的任务分解。再将每个任务依照任务的难易程度与项目成员的特点、兴趣、特长进行分配，并按要求进行估算。最后将估算加起来就是项目的估算值。
显然自底向上的这种策略具有较为客观的特点，但是它的缺点就是这样一来项目工期就和客户的要求不一致了。而且由于其带来的不确定性，许多项目经理也不会采用这种方法。
2.4 估算的方法
显然估算是建立在客观实际上，对未来尽可能合理的一种预测。那么估算本身的不确定性，决定了它不可能是百分之百准确无误的。在项目刚开始时，人们对产品需求、技术、市场预期、人员素质等因素的了解还远远不够，在这种情况下人们很难做出准确的估计。但是依据某种方法进行估计显然比瞎猜好得多。软件规模度量和估算的根本目的是通过量化的分析与总结，提高软件项目的生产率、提高产品质量、降低成本和产品研发周期，尽可能的减少因错误估算给企业带来的损失。软件项目的规模估算和度量历来是比较复杂的事，因为软件本身的复杂性、历史经验的缺乏、估算工具缺乏以及一些人为错误，导致软件项目的规模估算往往和实际情况相差甚远。估算错误已被列入软件项目失败的四大原因之一。因此对软件项目如何进行准确的规模评估研究是一个重要而迫切的问题。
良好的规模度量方法应该满足以下几点准则:
1)规模度量的有效性与程序开发所要求的时间紧密相关。
2)规模度量必须精密，但不一定精确。
3)应该能够自动计量。
4)应该能够反映各种影响开发成本的环境状况。
5)在规模度量和计数中能够反映新建、复用、删除、修改的代码以及它们的组合。
6)度量必须在整个开发过程中随时能够应用。
7)应对于各种类型的产品元素都能应用。常见的一些元素类型包括程序源代码、文档、报告、菜单、文件等等，但这一点要求非常难以实现。
估算方法有很多，大致分为基于分解的技术和基于经验模型两大类。基于分解的技术的方法包括功能点估算法、LOC估算法、MARK II等；基于经验模型的方法包括IBM模型、普特南模型、COCOMO模型等。分解技术：当一个待解决的问题过于复杂时，可以进一步将其分解，直到分解后的问题容易解决为止。然后分别解决这些分解后的问题，通过综合其解答得到原有问题的解答。这是处理复杂问题的最自然的方法。
2.4.1 FP功能点估算法
功能点估算法是一种在需求分析阶段基于系统功能的一种规模估计方法。通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。这种方法的计算公式是：功能点=信息处理规模×技术复杂度。信息处理规模包括各种输入、输出、查询、内部逻辑文件数、外部接口文件数等等；技术复杂度包括性能复杂度、配置项目复杂度、数据通信复杂度、分布式处理复杂度、在线更新复杂度等等。
2.4.2 LOC估算法
这是一种从技术的角度来估算的方法总称，其中又包含许多方法。这类方法以代码（LOC）作为软件工作量的估算单位，在早期的系统开发中较为广泛使用。LOC是指所有的可执行的源代码行数，包括可交付的语句、数据定义、数据类型声明、等价声明、输入/输出格式声明等。一代码行（1LOC）的价值和人月均代码行数可以体现一个软件生产组织的生产能力，开发组织可以根据对历史项目的审计来核算组织的单行代码价值。基于LOC的估算，既有优点也有缺点。优点在于方便计算、容易监控、能反映程序员的思维能力；缺点在于代码行数的含糊不清，不能正确反映一项工作的难易程度以及代码的效率。因此在传统的LOC方法进行了许多改进。其中不断被使用，且不断演化的方法包括以下：
PERT功能点估算法：PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计，Pert 估计可得到代码行的期望值和标准偏差SD。
类比估算法：类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目评价与分析机制，从而使对历史项目的数据分析是可信赖的。
Delphi估算法：Delphi法是一种专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别。对于需要预测和深度分析的领域，依赖于专家的技术指导，可以获得较为客观的估算。通过专家们的互相讨论，还可以博取众长。
系统分解：将系统分成若干个易于用LOC估算的部分，将其各个估算结果累加就是LOC的总规模。其中关键是建立起SBS（系统分解结构），它描述了系统的不同组件。SBS还被使用在其他重要的地方，如系统设计、系统分析等。在进行分解的时候，可以采用自由讨论的形式，可以获得更合理的SBS构成。
LOC和FP是两个不同的估算技术。但两者有许多共同特性。项目计划人员首先给出一个有界的软件范围的叙述，再由此叙述把软件分解成一些小的可分别独立进行估算的子功能。然后对每一个子功能估算其LOC或FP（即估算变量）。接着，把生产率度量（如LOC／PM或FP／PM）用做特定的估算变量，导出子功能的成本或工作量。将子功能的估算进行综合后就能得到整个项目的总估算。
LOC或FP估算技术对于分解所需要的详细程度是不同的。当用LOC作为估算变量时，功能分解是绝对必要的且需要达到很详细的程度。而估算功能点所需要的数据是宏观的量，当把FP当作估算变量时所需要的分程度不很详细。应注意，LOC可直接估算，而FP要通过估计输入、输出、数据文件、查询和外部接口的数目间接地确定。
项目计划人员可对每一个分解的功能提出一个有代表性的估算值范围。利用历史数据或凭实际经验，对每个功能分别按最佳的、可能的、悲观的三种情况给出LOC或FP估计值，记作a、m、b。当这些值的范围被确定之后，也就隐含地指明了估计值的不确定程度，然后计算LOC或FP的期望值E。
E＝（a＋4m＋b）／6 （加权平均）
一旦确定了估算变量的期望值，就可以用作LOC或FP的生产率数据。
工作量估算是估算任何工程开发项目成本的最普遍使用的技术。每一个项目任务的解决都需要花费若干人日、人月或人年，每一个工作量单位都对应于一定的货币成本，从而可以由此做出成本估算。
类似于LOC或FP技术，工作量估算开始于从软件项目范围抽出软件功能，接着给出为实现每一功能所必须执行的一系列软件工程任务，包括需求分析、设计、编码和测试。最后，计算每一个功能及软件项目的工作量和成本。将工作量估算与LOC估算得到的结果进行比较，如果结果一致则估算是可靠的，否则有必要做进一步的检查与分析。
2.4.3 IBM模型估算法
该模型是Watson和Felix在1977年发布的，是基于IBM联合系统分布负责的60个项目的总结而得到的模型。该模型是一个静态模型，而参考数据只有60多个项目，因此有很大的局限性。
1977年，Watson和Felix总结了IBM的60个项目数据，提出了如下的估算公式：
E＝5.2×L0.91， L是源代码行数（以KLOC计），E是工作量（以PM计）
D＝4.1×L0.36＝2.4×E0.35， D是项目持续时间（以月计）
S＝0.54×E0.6， S是人员需要量（以人计）
DOC＝49×L1.01， DOC是文档数量（以页计）
2.4.4 COCOMO估算法
Boehm在其经典著作“软件工程经济学”(software engineering economics)中，介绍了一种软件估算模型的层次体系，称为COCOMO(构造性成本模型，Constructive Cost Model)，它代表了软件估算的一个综合经验模型。它是一种精确的、易于使用的成本估算方法，它分为基本COCOMO模型和中级COCOMO模型两种类型。基本COCOMO模型是一个静态单变量模型，它用一个已估算出来的源代码行数（LOC）为自变量的经验函数来计算软件开发工作量。中间COCOMO模型则在用LOC为自变量的函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。更详细的COCOMO模型除了包括中间COCOMO模型的所有特性外，还考虑了在需求分析、软件设计等每一步的影响。
COCOMO模型是适用于三种类型的软件项目：(1)组织模式——较小的、简单的软件项目，有良好应用经验的小型项目组，针对一组不是很严格的需求开展工作(如，为一个热传输系统开发的热分析程序)；(2)半分离模式——中等的软件项目(在规模和复杂性上)，具有不同经验水平的项目组必须满足严格的及不严格的需求(如，一个事务处理系统，对于终端硬件和数据库软件有确定需求)；(3)嵌入模式——必须在一组严格的硬件、软件及操作约束下开发的软件项目(如，飞机的航空控制系统)。
2.4.5 软件方程式估算法
软件方程式是一个多变量模型，它假设在软件开发项目的整个生命周期中的一个特定的工作量分布。该模型是从4000 多个当代的软件项目中收集的生产率数据中导出的公式。初期的方程式较为复杂，通过，Putnam 和Myers的努力又提出一组简化的方程式。当然这种方法也是基于长期的参考数据的积累而得到的。
2.4.6 WBS估算法
这是一种基于WBS（工作任务分解）的方法，即先把项目任务进行合理的细分，分到可以确认的程度，如某种材料、某种设备、某一活动单元等。然后估算每个WBS要素的费用。采用这一方法的前提条件或先决步骤是：
对项目需求做出一个完整的限定。
制定完成任务所必需的逻辑步骤。
编制WBS表。
项目需求的完整限定应包括工作报告书、规格书以及总进度表。工作报告书是指实施项目所需的各项工作的叙述性说明，它应确认必须达到的目标。如果有资金等限制，该信息也应包括在内。规格书是对工时、设备以及材料标价的根据。它应该能使项目人员和用户了解工时、设备以及材料估价的依据。总进度表应明确项目实施的主要阶段和分界点，其中应包括长期定货、原型试验、设计评审会议以及其他任何关键的决策点。如果可能，用来指导成本估算的总进度表应含有项目开始和结束的日历时间。
除了以上介绍的几种方法外，还有一些其他的方法：类比估算、推测估算、Standard-component估算法、普特南估算法等。类推估算法是比较科学的一种传统估算方法，它适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。类推估算法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类推估算法的前提条件之一是组织建立起较好的项目后评价与分析机制，使得对历史项目的数据分析是可信赖的。
这种方法的基本步骤是：
整理出项目功能列表和实现每个功能的代码行；
标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方；
通过步骤1和2得出各个功能的估计值；
产生规模估计。
当然不同的方法适用于不同的具体环境，有些方法虽然很好但并不一定适合当前的任务。只有量体裁衣，具体问题具体分析，才能得到尽量合理的估算。
3 重点方法详述及功能点扩展改进方法
以上是对软件估算的综述，以下我们重点讨论功能点估算方法，并针对其缺点提出两种改进措施，在最后还会结合算法模型法、专家小组法和类比估算法提出一种新的度量策略。
规模是软件的一个重要属性，是成本估计和生产率分析的重要参数，对于软件开发和软件项目管理而言，在开发的早期进行规模估计的要求都很迫切。但这时有关软件的信息还很少，没有编码可供度量，因此出现了试图从功能角度度量规模的功能点FP（function points）。但是，功能点固有的缺陷与不足限制了它的使用。在此提出的扩展功能点EFP（extended FP）从根本上解决了功能点方法的缺陷。在此将系统地讨论扩展功能点模型，这是对功能点方法的第一种改进策略。
3.1功能点
Albrecht 于1979年提出了功能点，以求在开发的早期度量软件的规模，而后又于1983年改进了功能点，使的功能点由5个功能分量和一批调整因子组成。这5个功能分量分别是外部输入EI、外部输出EO、外部接口文件EIF、内部逻辑文件ILF和查询EQ。5个功能分量的加权累加就是未调整的功能点，再应用14个调整因子可得到调整的功能点。本文讨论的功能点就是1983年Albrecht改进的功能点。
1986年，SPR改进功能点后得到特征点(feature points)，使其适用于非信息处理领域。1994年，波音公司提出了3维功能点---3DFP，即所谓的三维是指数据、功能处理和控制。
3.2 功能点存在的问题
虽然功能点已取得了广泛的应用，但细心的研究会发现它存在如下一些问题：
（1）功能点的应用领域具有一定的局限性。
功能点主要是针对信息处理系统而设计的，因此其应用领域有很大的局限性。
（2）功能点度量元素不完整，或者说度量元素的概念间存在重叠。
功能点定义系统的用户输入为维护ILF的EI和不维护ILF的输入（简记为UI）两类。功能点明确指出要计算EI，但并没有明确指出要计算UI，只是在计算EQ时提到。这说明可能根本不计算UI，使得功能点度量元素在概念上不完整；也可能是在计算EQ的同时计算了UI，这说明UI是EQ的一个组成部分，因此，功能点元素概念间有重叠。
（3）功能点中ILF和EIF的定义不清晰，不便于实际操作。
什么是文件？什么是数据的逻辑组？这使得ILF和EIF的定义模糊。
（4）实际上往往无法得知某一个外部输入是否出自于另一个系统的内部逻辑文件。
功能点定义EIF必须同时又是另一个应用系统的ILF，而实际上这往往无法验证。
（5）查询被定义为一个处理，却被描述为一个事务。
功能点把外部查询定义为一个映射（I,O）对，也就是一个功能处理，可实际查询时却被描述为事务。
扩展功能点EFP
扩展功能点EFP从功能点角度度量软件的规模，独立于开发所使用的语言，一旦获得了用户功能需求FUR（functional user requirements），就可以用它来度量规模。下面先讨论功能规模度量的特征，然后分析EFP的问题域模型，并从问题域模型中获得EFP的基本功能块BFC（base functional component）类型，同时给出各个BFC类型的定义和度量方法，最后介绍EFP计算模型。
3.4 功能规模度量
ISO/IEC 14143是有关功能规模度量FSM（functional size measurement）的标准，它用于评价某种规模度量方法是否为FSM方法，该标准要求一个FSM方法满足：
基于用户功能需求FUR度量软件的规模；
一旦得到了FUR，就可以应用它来度量规模；
通过对BFC的评价可以得到软件的功能规模。
BFC是FSM方法基于用户功能需求FUR定义的基本单元，它具有以下特征：
· 只描述FUR；
· 不描述任何有关技术需求的信息；
· 不描述任何有关质量需求的信息；
· 任何一个BFC都可以被识别为一个BFC类型，并且只能识别为一个类型。
3.5 EFP 问题域模型
FSM方法从功能角度来度量软件的规模，因此，EFP的问题域就是软件的用户功能。软件对于用户就是一个黑盒，而用户关心的是软件需要用户提供哪些输入，同时能为用户返回哪些输出，软件就是一个把用户输入转换成用户输出的机构，其中用户输入和用户输出都是由用户定义的，因此转换功能也是由用户定义的。有些用户输入对于用户具有特殊的意义，用户希望软件能够将这些数据保存起来，以便更好地实现用户提出的功能。这些数据，我们可称为用户数据实体，虽然保存在软件的内部，但却是由用户提供的，因而由用户维护和使用。由于用户数据实体直接与用户输入、用户输出和用户功能相关，因此它对于软件规模的影响将不能被忽略。这样，我们最终得到EFP问题域的4个元素---用户输入、用户输出、用户功能和用户数据实体。
为了有效的识别用户和软件之间的关系，我们为软件定义一个概念边界。由此，用户输入就是穿过边界去往软件的输入，用户输出就是穿过边界去往用户的软件输出。同理，根据计算机科学理论，用户功能就是用户输入到用户输出的映射，为便于后面的讨论，我们将用户输入和用户输出更名为外部输入和外部输出，所谓“外部”是相对于这个概念边界而言的。这样，我们就得到了如图1和式（1）所示的EFP问题域模型。
EI
Boundary① EO
①边界。
图1 EFP问题域图示模型
Domain = (EI, EO, UP, UDE, Boundary)