5.软件工作量估计
软件的开发报价(含软件的开发项目的工作量及报价实用模板)地计算方法
软件开发报价的计算方法1．软件开发价格估算方法软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。
为了便于计算，给出一个计算公式：软件开发价格＝开发工作量× 开发费用／人·月1.1开发工作量软件开发工作量与估算工作量经验值、风险系数和复用系数等项有关：软件开发工作量＝估算工作量经验值× 风险系数× 复用系数估算工作量经验值〔以A来表示〕软什开发工作量的计算，曾有人提出以源代码行或功能点来计算，这些方法实施起来均有不少难度。
目前国际上仍旧按以往经验的方式加以计算，国内各软件企业也是采用经验的方式加以估算工作量。
为了更好地规X估算方法，建议可按照国家标准“GB／T 8566-2001软件生存周期过程〞所规定的软件开发过程的各项活动来计算工作量。
工作量的计算是按一个开发工作人员在一个月内〔日历中的月，即包括国家规定的节假日〕能完成的工作量为单位，也就是通常所讲的“人·月〞。
特别要提醒的是软件开发过程中既包括了通常所讲的软件开发，也应包括各类软件测试的活动。
1.1.2风险系数〔以σ来表示〕估算工作量经验值亦会存在较大风险，造成软件危机的因素很多，这也是一个方面的因素。
特别当软件企业对该信息工程项目的业务领域不熟悉或不太熟悉，而且用户又无法或不能完整明白地表达他们的真实的需求，从而造成软件企业需要不断地完善需求获取，修改设计等各项工作。
因此：l ≤ 风险系数≤ 1.5根据我们对软件企业的了解，超过估算工作量经验值的一半，已是不可接受，所以我们确定“1.5〞为极限值。
当然这既要看企业的能力，也要看用户能接受的程度。
复用系数〔以τ来表示〕估算工作量经验值是软件企业承担一般项目来估算的，但如果软件企业已经采用“基于构件的开发方法〞，并己建立起能够复用的构件库〔核心资产库〕，或者已有一些软件产品，仅作二次开发，从而使软件开发工作量减少。
因此：0.25 ≤ 复用系数≤ 1根据国内外软件企业在实施基于构件开发方法〔软件产品线〕的经验数据，提高工作效率达到25%〔最高值〕。
软件项目工作量评估方法
工作量评估1概述我们认真地阅读了软件的相关需求文档和设计文档后，对软件的功能进行了归纳和整理，并根据以往的经验对每个功能模块所需的编码工作量进行估算，再进一步地以此为依据，推算出整个软件生命期的工作量。
工作量推算后组织主要项目干系人和相关专家进行工作量评审。
2常见的估算方法2.1Ad-hoc方法这种方法下的测试工作量不基于任何确定的期限。
工作一直继续直到达到一些由管理或市场人员预先定下的时间表。
或者，一直到用完了预算的经费。
这种情况普遍存在于非常不成熟的组织，并且时常有100%的错误差数。
2.2开发时间的百分比法Percentage of development time。
这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。
首先，开发工作量使用例如LOC或FP方法被估算出来，然后使用一些探索性的方法来限制测试的工作量。
这种方法变化比较大而且通常基于以前的经验。
通常预留项目的总花费时间的35%给测试, 5-7%给组件和集成测试,18-20%给系统测试, 10%给接收测试（或回归测试等）2.4类比法（经验值法或历史数据法）根据以前或相似项目（主要在项目性质，领域，规模上有相似）所积累的经验或历史数据来估算工作量。
类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。
需要收集以下相关的历史数据：在设计和实现阶段花费的时间，测试工作的规模，例如用户需求的数量，页面数，功能点，数据样式，例如实体，字段的数量, 屏幕或字段数量,测试对象的规模，例如KLOC2.5 WBS（work breakdown structure）估算法将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的测试工作量/时间。
2.6 Delphi法Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。
软件工程试题及答案
1. 软件生命期各阶段的任务是什么？答:软件生命期分为7个阶段:1、问题定义：要解决的问题是什么2、可行性研究：确定问题是否值得解，技术可行性、经济可行性、操作可行性3、需求分析:系统必须做什么4、总体设计：系统如何实现,包括系统设计和结构设计5、详细设计:具体实现设计的系统6、实现：编码和测试7、运行维护:保证软件正常运行。
2、软件重用的效益是什么？答:1、软件重用可以显著地改善软件的质量和可靠性。
2、软件重用可以极大地提高软件开发的效率。
3、节省软件开发的成本，避免不必要的重复劳动和人力、财力的浪费.3、自顶而下渐增测试与自底而上渐增测试各有何优、缺点？答：①自顶而下渐增测试优点：不需要测试驱动程序，能够在测试阶段的早期实现并验证系统的主要功能,而且能够尽早发现上层模块的接口错误。
缺点:需要存根程序，底层错误发现较晚.②自底而上渐增测试优点与缺点和自顶而下渐增测试相反.4 、提高可维护性的方法有哪些?答：在软件工程的每一阶段都应该努力提高系统的可维护性，在每个阶段结束前的审查和复审中，应着重对可维护性进行复审。
在需求分析阶段的复审中，应对将来要扩充和修改的部分加以注明.在讨论软件可移植性问题时,要考虑可能要影响软件维护的系统界面。
在软件设计的复审中,因从便于修改、模块化和功能独立的目标出发，评价软件的结构和过程，还应对将来可能修改的部分预先做准备。
在软件代码复审中，应强调编码风格和内部说明这两个影响可维护性的因素。
在软件系统交付使用前的每一测试步骤中都应给出需要进行预防性维护部分的提示。
在完成每项维护工作后，都应对软件维护本身进行仔细认真的复审.为了从根本上提高软件系统的可维护性，人们正试图通过直接维护软件规格说明来维护软件,同时也在大力发展软件重用技术。
简述软件测试要经过哪几个步骤，每个步骤与什么文档有关.【解答】测试过程按4 个步骤进行，即单元测试(模块测试）、集成测试（子系统测试和系统测试）、确认测试（验收测试）和平行运行。
第5章 IT项目时间管理
1．项目进度计划编制的步骤
（1）选择模板。 （2）确定任务。 （3）确定时间值。 （4）进行资源分配计划评审。 （5）画出网络计划图。
2．制订项目进度计划的方法
（1）系统分析法。 （2）资源平衡法。 （3）项目管理软件是广泛应用于项目工 期计划编制的一种辅助方法。
5.6.3 计划编制技术
1．甘特图
5.7.2 进度控制的工具和方法
1．各种进度控制报告和报表
（1）项目执行状态报告。 （2）重大突发性事件或例外报告。
（3）特别分析报告。 （4）关键点检查报告。 （5）项目变更申请报告。 （6）项目管理报告。 （7）项目进度控制总结等。
2．甘特图检查法 3．S形曲线检查法
（1）实际工程进展速度。 （2）项目实际进度超前或拖后的时间。 （3）工程量的完成情况。 （4）后续工程进度预测。
5.7 IT项目进度控制
5.7.1 IT项目进度控制
项目组内控制 企业控制 用户方控制 第三方控制
1．项目进度控制的依据
（1）项目进度计划文件。 （2）项目工期计划实施情况报告。 （3）项目变更的请求。 （4）项目进度管理的计划安排。
2．项目计划进度控制的流程
图5-12 项目计划进度控制流程图
活动历时估算：估计完成单项计划活动开展 的具体活动时间。 项目进度安排：分析计划活动顺序、计划活 动持续时间、资源要求和进度制约因素，制 订项目进度表的过程。 项目进度控制：控制项目进度变更的过程。
5.1.4 IT项目时间管理的特点
（1）时间管理是一个动态过程。 （2）项目进度计划和控制是一个复杂的系 统工程。 （3）时间管理有明显的阶段性。 （4）时间管理风险性大。
3．项目执行信息的收集
软件工作量评估方法
软件工作量评估方法软件工作量评估是指根据软件开发项目的要求和规模，对开发任务的工作量进行估算的过程。
正确的工作量评估可以帮助项目团队制定合理的计划和资源分配，避免项目进度延迟或质量问题。
以下是常用的软件工作量评估方法：1. 方法1：基于工作量历史数据的模型这种方法使用历史数据作为参考，根据过去的类似项目的工作量和进度进行估算。
可以使用线性回归等统计方法，建立工作量和项目规模之间的关系模型，通过输入项目规模来预测工作量。
2. 方法2：基于功能点的模型功能点是对软件功能的衡量单位，根据软件需求规格说明书，将不同功能点的工作量进行量化评估。
可以使用功能点估算法，如IFPUG（International Function Point Users Group）方法，根据功能点的类型和复杂程度来评估工作量。
3. 方法3：专家评估法这种方法依赖于项目团队成员的经验和专业知识，根据开发任务的复杂程度、技术难度等因素进行主观评估。
可以通过开展专家评审会议或个人访谈等方式，让团队成员根据自己的经验对工作量进行评估。
4. 方法4：三点估算法三点估算法是一种基于概率的评估方法，将工作量估算看作是一个随机变量，考虑到不确定性因素。
通过对开发任务的最佳、最坏和最可能的工作量进行估算，结合概率统计方法，计算出工作量的期望值和标准差。
无论使用哪种方法，软件工作量评估都需要考虑以下几个因素：1. 项目规模：根据软件的功能需求、复杂程度等，确定开发任务的规模。
2. 开发人员的技能和经验：考虑到开发人员的技术水平和经验，对工作量进行调整。
3. 开发环境和工具：考虑到开发环境和所使用的工具对工作效率的影响，进行工作量的调整。
4. 风险因素：考虑到项目风险和不确定性因素，对工作量进行合理的缓冲。
总之，软件工作量评估是一个复杂的过程，需要综合考虑多个因素。
选择合适的工作量评估方法，并结合实际情况进行调整和优化，可以提高估算的准确性和可靠性，为项目成功提供有力支持。
《软件工程》试题及参考答案(第5套)
厦门理工软件学院2011 –2012 学年度下期《软件工程》试题(第5套)第一部分选择题一、单项选择题（本大题共20小题，每小题1分，共20分）在每小题列出的四个备选项中只有一个是符合题目要求的，请将其代码填写在题后的括号内。
错选、多选或未选均无分。
１、（）是软件生存期中的一系列相关软件工程活动的集合，它由软件规格说明、软件设计与开发、软件确认、软件改进等活动组成。
A 软件过程B 软件工具C 质量保证D 软件工程2、在各种不同的软件需求中，功能需求描述了用户使用产品必须要完成的任务，可以在用例模型或方案脚本中予以说明，（）是从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求。
A 业务需求B 功能要求C 非功能需求D 用户需求3、软件测试计划开始于需求分析阶段，完成于（）阶段。
A 需求分析B 软件设计C 软件实现D 软件测试4．下面关于面向对象方法中消息的叙述，不正确的是( )。
A. 键盘、鼠标、通信端口、网络等设备一有变化，就会产生消息B．操作系统不断向应用程序发送消息，但应用程序不能向操作系统发送消息C. 应用程序之间可以相互发送消息D．发送与接收消息的通信机制与传统的子程序调用机制不同5．美国卡内基—梅隆大学SEI提出的CMM模型将软件过程的成熟度分为5个等级，以下选项中，属于可管理级的特征是( )。
A．工作无序，项目进行过程中经常放弃当初的计划B．建立了项目级的管理制度C．建立了企业级的管理制度D．软件过程中活动的生产率和质量是可度量的6．在McCall软件质量度量模型中，（）属于面向软件产品修改。
A．可靠性 B．可重用性 C．适应性 D．可移植性7．软件生命周期中所花费用最多的阶段是（）A．详细设计 B．软件编码 C．软件测试 D．软件维护8．需求分析阶段的任务是确定（）A．软件开发方法B．软件开发工具C．软件开发费D．软件系统的功能9．如果某种内聚要求一个模块中包含的任务必须在同一段时间内执行，则这种内聚为( )。
七种场景下的软件工作量估算步骤
可以采用经验法。
（7）汇总得到：每个阶段的工作量、项目的总工作量。
其他说明：在该场景下，混合使用了经验法与模型法，这2种方法互相补充，而不是互相印证。
场景四：由总体印证基于WBS的估计场景描述：（1）有类似项目的历史数据（2) 有类似项目的全生命周期的生产率数据（含管理工作量）（3）有详细需求（4）实施了CMMI2级，但是没有积累历史项目的工作量分布数据估算步骤：（1）产品分解，将系统分为子系统，子系统分解为模块；（2）估计产品元素的规模，可以采用代码行法或功能点法；（3）累计出整个产品的总规模，并估计产品总体的复杂度、复用率等；（4）根据类似项目的全生命周期的生产率数据和产品的总规模、复杂度、复用率等采用模型法计算总的开发工作量；（5）WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度；WBS 分解时要识别出所有的交付物、项目管理活动、工程活动等。
（6）根据历史的类似项目的数据及估算人的经验估计所有活动的工作量，可以采用经验法。
（7）汇总得到：每个阶段的工作量、项目的总工作量。
（8）与第（4）步得出的工作量进行比较印证，如果偏差不大，则以第（7）步的结果为准，如果偏差比较大，要仔细分析原因，可能的原因举例如下：类似项目的生产率数据不适合本项目；WBS分解的颗粒度不够详细；估算专家的经验不适合本项目；具体任务的估计不合理；针对原因，对估算的结果进行调整，使其趋向合理。
其他说明：在该场景下，对于项目的总工作量有2个结果或者多个结果，这些结果可以互相印证，以发现估算过程中的不合理之处，是估计更加合理。
场景五：三维印证基于WBS的估计场景描述：（1）有类似项目的历史数据（2) 有类似项目的全生命周期的生产率数据（含管理工作量）（3）有详细需求（4）实施了CMMI3级，有历史项目的工作量分布数据（阶段分布、工种分布）估算步骤：（1）产品分解，将系统分为子系统，子系统分解为模块；（2）估计产品元素的规模，可以采用代码行法或功能点法；（3）累计出整个产品的总规模，并估计产品总体的复杂度、复用率等；（4）根据类似项目的全生命周期的生产率数据和产品的总规模、复杂度、复用率等采用模型法计算总的开发工作量；（5）根据历史项目的工作量分布数据及第（4）步估算的项目总工作量，计算：每个阶段的工作量每个工种的工作量（6）WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度；WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
五点法工作量评估
五点法工作量评估是一种软件开发工作量估算方法，也称为初步功能点法。
它是根据确定的内部文件（ILF）、外部文件（EIF）、用户输入（EI）、用户输出（EO）、用户查询（EQ）的个数来计算工作量的。
具体计算公式为：*FP=∑(15ILF+10EIF+4EI+5EO+4EQ)**。
其中，FP 表示功能点数，ILF表示内部文件，EIF表示外部文件，EI表示用户输入，EO表示用户输出，EQ表示用户查询。
这种方法纳入了五要素，并给予了不同的权重，比快速功能点法更进了一步，评估工作量变大，评估结果通常更准确一些。
五点法工作量评估的优点是简单易行，可以快速估算软件开发工作量。
但是，由于它是基于功能点来计算的，因此可能无法考虑到一些非功能性需求，如性能、安全性等方面的要求。
此外，五点法工作量评估还需要根据项目的实际情况进行调整和修正，以确保评估结果的准确性。
软件开发项目工作量估算
软件开发项目工作量估算
软件开发项目工作量的估算是一个重要的任务，它有助于确定项目的规模、资源需求和计划安排。
以下是一些常用的软件开发项目工作量估算方法：
1.功能点估算法：该方法通过将软件的功能划分为不同的模块，并根据每个模块的复杂程度和所需的工作量，进行估算。
功能点的数量可以根据需求分析文档来确定，然后根据之前类似项目的实际情况，估算每个功能点所需的开发时间。
2.任务分解法：该方法将项目的各个任务分解为更小的子任务，然后对每个子任务进行详细的估算。
这种方法的优势在于可以更准确地估算每个任务的工作量，但需要花费更多的时间和精力来确定子任务的细节。
3.专家判断法：该方法依赖于经验丰富的开发人员的判断和估算。
通过和开发团队讨论，根据过去类似项目的经验，以及项目的目标和约束，估算项目的工作量。
不论使用哪种方法，都需要对项目的需求和目标有清晰的了解，并与开发团队充分合作和沟通。
同时，需要考虑到不同的风险和不确定因素，例如技术复杂度、项目环境等。
最终得出的工作量估算应
该是一个合理的、可靠的和可执行的计划，可以为项目的成功实施提供有力的支持。
七种场景下的软件工作量估算步骤
七种场景下的软件工作量估算步骤软件工作量估算是软件开发过程中非常关键的一步，能够帮助开发团队合理安排资源和时间，确保项目的顺利进行。
在不同的场景下，软件工作量估算的步骤可能会有所差异。
下面将具体介绍七种场景下的软件工作量估算步骤。
1.新项目启动在启动一个新项目时，软件工作量的估算是必要的。
步骤如下：1.1确定项目目标：明确项目的目标和范围，包括项目的规模与功能等。
1.2划分工作包：根据项目目标和范围，将项目工作划分为不同的阶段或模块。
1.3评估工作包：对每个工作包进行评估，考虑开发的难度、复杂度、所需资源等因素。
1.4组织工作包：将评估结果整理并组织为项目工作量估算的总体计划。
2.升级与改进在软件的升级与改进过程中，也需要进行工作量的估算。
步骤如下：2.1确定升级与改进的目标：明确升级与改进的目标和范围，包括需要增加哪些功能或改进哪些功能等。
2.2评估功能变更：对每个功能变更进行评估，考虑开发的难度、所需资源等因素。
2.3评估改进项：对每个改进项进行评估，考虑改进的难度、所需资源等因素。
2.4组织评估结果：将评估结果整理并组织为升级与改进工作量估算的总体计划。
3.项目延期当项目面临延期时，需要重新评估工作量，确保能够在新的时间限制下完成。
步骤如下：3.1确定新的时间限制：根据项目的实际情况，确定新的时间限制。
3.2评估工作量：根据新的时间限制，重新评估项目的工作量，考虑是否需要放缓开发速度或增加开发资源。
3.3调整计划：根据评估结果，进行项目计划的调整，并与相关人员沟通以确保能够满足新的时间限制。
4.技术风险当项目面临技术风险时，需要进行工作量的估算以便更好地应对风险。
步骤如下：4.1确定技术风险：明确项目面临的技术风险，并对其进行分类和排序。
4.2评估变更工作量：对需要进行技术改进的工作进行评估，考虑技术改进的难度、所需资源等因素。
4.3组织评估结果：将评估结果整理并组织为技术风险应对工作量估算的总体计划。
项目管理-2-软件工作量估算
练习
学生要求每学期写一篇有关IT的报告，如果你想建立一个估算学生完成这样一份报告的模型，你用什么来衡量报告的大小，什么因素会影响学生完成报告的难度？ 字数 材料能否获取 对主题的熟悉程度 宽度/深度 技术难度
该方法特别是在对原由系统进行替换时有用，评估者对影响的代码的比例进行分析，从而得到工作量评估。
5
软件工作量估算困难的原因
1
某些人试图建立一个过去项目的全软件业的数据库，但是许多词汇意义的不明确使得这种努力没有效果，例如“测试”阶段究竟包括哪些活动就不明确。
2
估计的主观性：人们容易低估小项目的工作量，而过分夸大大项目的工作量
3
估计的政治因素：不同的人有不同的目标，如项目经理会高估项目工作量，许多机构采用独立的估算小组，但是将项目经理和项目成员吸收进估算小组，能够增强他们的责任感。
自下而上：各个部分的工作量先估算出来，然后进行合成
软件工作量估计技术
该方法首先将项目分成部件任务，然后估算每个任务所需的工作量。
01
在大型的项目中，分解任务的过程是一个叠代的过程，直到最下面的任务不可分解，产生WBS。
02
该方法适合于项目规划的后期。如果应用在前期，那么必须对最终的系统作出一些假设，例如对软件模块的数量和大小进行假设。
特征点（Feature Points):除了考虑普通功能点的内容外，还考虑了算法的特征（矩阵转换，字符串解析，处理中断等都是算法的例子）
功能点的其它扩展
功能点转化为工作量
对于原来的项目，计算生产率： 生产率＝功能点数目/工作量（人日） 则，对于新项目，功能点计算出来后，工作量为： 工作量＝功能点数目/生产率 更复杂的方法：最小二乘法 即工作量＝系数1＋功能点数×系数2
第六讲软件工作量估计 PPT
External inquiry (EQ) types 外部查询类型 – user initiated transactions which provide information but do not update puter files、 Normally the user inputs some data that guides the system to the information the user needs、
unlikely to change (RESL is high with a score 2、83)、 The team is tightly knit (TEAM has high score of 2、
19), but processes are informal (so PMAT is low and scores 6、24)
The COO 81 Constants
System type
Organic (broadly, information systems)
c 2、4
Semi-detached
3、0
Embedded (broadly, real- 3、6 time)
k 1、05
1、12 1、20
k exponentiation – ‘to the power of…’ adds disproportionately more effort to the larger projects takes account of bigger management overheads
开发工作量评估模板
开发工作量评估模板
在软件开发项目中，对工作量进行准确评估是非常重要的。
开
发工作量评估模板是一种用于帮助团队成员评估项目工作量的工具。
它可以帮助团队成员更好地理解项目的复杂性和需要投入的时间，
从而更好地规划和管理项目进度。
一个典型的开发工作量评估模板包括以下几个方面：
1. 任务描述，列出需要完成的具体任务或功能模块。
2. 预估工作量，对每个任务或功能模块进行工作量估算，通常
以小时或天为单位。
3. 负责人，指定负责完成每个任务或功能模块的团队成员。
4. 优先级，确定任务或功能模块的优先级，以便在资源有限的
情况下进行合理分配。
5. 完成日期，设定每个任务或功能模块的预期完成日期。
开发工作量评估模板的使用可以帮助团队成员更好地了解项目
的需求和复杂性，从而更好地规划和分配工作。
同时，它也可以帮
助项目经理或团队领导更好地监控项目进度，及时发现和解决问题。
在实际使用开发工作量评估模板时，团队成员应该尽可能准确
地估算工作量，同时也要考虑到可能出现的风险和不确定性因素。
此外，评估模板也应该根据项目的实际情况进行调整和优化，以确
保其有效性和实用性。
总之，开发工作量评估模板是软件开发项目管理中的重要工具，它可以帮助团队更好地规划和管理项目工作，提高项目的成功率和
质量。
软件开发工作量估算方法
软件开发工作量估算方法软件开发工作量估算是项目管理和规划中的重要环节。
虽然准确估算工作量是一项具有挑战性的任务，但采用合适的方法和技术可以提高估算的准确性。
下面介绍几种常见的软件开发工作量估算方法：1. 经验估算：经验估算是基于过去项目的经验数据和类似项目的历史记录进行工作量估算的方法。
根据相似项目的开发时间、人力资源投入和成果，结合开发团队成员的经验和专业知识，对新项目进行估算。
这种方法适用于有足够可比性和历史数据的项目，能够提供相对准确的估算结果。
2. 类比估算：类比估算是根据类似的已完成项目来估算新项目的工作量。
通过找到与当前项目类似的项目，比较其规模、复杂度和功能特性，然后将类比项目的工作量和成本应用到新项目中。
这种方法需要找到合适的类比项目，并进行适当的调整以适应新项目的特点。
3. 参数化估算：参数化估算是利用数学模型和统计数据来估算工作量的方法。
通过建立数学模型，将项目的规模、功能点数、复杂性等因素转化为工作量的估算指标。
这种方法需要收集和分析大量的历史数据，建立合适的模型，并根据项目的特征和参数进行估算。
4. 专家评估：专家评估是依靠项目团队成员或领域专家的意见和经验来估算工作量的方法。
通过专家的判断和主观评估，结合对项目需求、技术复杂度和开发过程的理解，进行工作量估算。
这种方法适用于项目团队具有丰富经验和专业知识的情况下，但结果可能受到主观因素的影响。
5. 顶层估算：顶层估算是在项目初期进行的高层次估算，通常基于项目的整体目标和范围。
通过对项目需求、业务规模和技术复杂度的初步分析，结合类似项目的经验数据，给出一个大致的工作量估算范围。
这种方法可以在项目启动阶段提供一个初步的决策依据。
无论采用哪种方法，软件开发工作量估算都需要考虑多个因素，如项目规模、需求复杂性、技术特点、团队成员的技能水平、开发工具和方法等。
需要强调的是，软件开发工作量估算永远不是完美的，但通过结合不同的估算方法、经验数据和专业判断，可以提高估算的准确性和可靠性。
软件开发成本估算与工作量计算例题
软件开发成本估算与工作量计算例题摘要：I.软件开发成本估算的重要性A.成本控制B.项目评估C.资源分配II.软件开发成本的构成A.人力成本B.硬件成本C.培训成本D.维护成本III.软件开发工作量的计算A.代码行数B.功能点分析C.人工时数IV.成本估算方法A.类比估算B.参数估算C.专家评审V.成本估算工具A.Microsoft ProjectB.Primavera P6C.JIRAVI.结论A.成本估算与工作量计算的关系B.提高成本估算的准确性C.对项目成功的促进作用正文：I.软件开发成本估算的重要性软件开发成本估算在项目管理中具有重要作用。
合理的成本估算可以帮助项目管理人员控制项目成本，确保项目在预算范围内完成。
此外，成本估算也是项目评估和资源分配的基础。
通过成本估算，项目经理可以了解项目的可行性，为项目决策提供依据。
II.软件开发成本的构成软件开发成本主要包括人力成本、硬件成本、培训成本和维护成本。
其中，人力成本是软件开发过程中最大的支出，包括开发人员、测试人员、项目经理等人员的工资和福利。
硬件成本包括计算机设备、网络设备等。
培训成本是为了提高员工的技能和知识水平而进行的培训。
维护成本包括软件上线后的修复、更新和升级等。
III.软件开发工作量的计算软件开发工作量的计算有多种方法，如代码行数、功能点分析和人工时数。
代码行数是一种简单的方法，但容易受到代码质量、编程风格等因素的影响。
功能点分析是通过分析软件的功能需求来计算工作量，更加准确。
人工时数是根据开发人员的技能水平和工作效率来计算的，适用于对项目进度有严格要求的场景。
IV.成本估算方法成本估算方法包括类比估算、参数估算和专家评审。
类比估算是一种基于历史数据和经验的估算方法，适用于项目类型和规模相似的情况。
参数估算是通过分析项目的各项参数，如代码行数、功能点等，来计算成本。
专家评审是邀请具有相关经验的专家对项目成本进行评估。
V.成本估算工具成本估算工具可以帮助项目经理更加高效地完成成本估算。
SPM-软件工作量估算
因此，必须根据当前项目特点选择适应的估算
模型，并依据需要对相应模型作出调整。
动态多变量模型
动态多变量模型，即软件方程式，它是根据
4000多个当代软件项目中收集的生产率数据推 导出来的。 该模型把工作量看作是软件规模和开发时间的 函数，其形式如下：
Eห้องสมุดไป่ตู้ ( LOC B
0.333
/ P) (1/ t )
简单 3 4 3 7 5
平均 4 5 4 10 7
复杂 5 7 6 15 10
然后用下式计算未调整的功能点数UFP： CT=a1×Inp＋a2×Out＋a3×Inq＋a4×Maf＋a5×Inf
估算功能点的步骤
2、计算技术复杂因子TCF 软件复杂度的估算基于14个问题，逐一对各问题做
出复杂度估计，其取值范围是0-5。
当有以往开发类似产品的历史数据可供参考时，这种方 法估算出的数值还是比较准确的。
代码行技术
代码行技术的优点：
代码是所有软件项目开发都包含的“产品”，而且
代码行数很容易计算。
代码行技术的缺点：
源程序仅是软件配置的一个成分，用它的规模代表
整个软件规模不太合理； 用不同语言实现同一个软件所需的代码行数并不相 同，即它依赖于所使用的编程语言； 不适合于非过程语言。
功能点技术
是为克服代码行技术缺点提出的； 它涉及多种因素的度量方法； 功能点技术根据对软件信息域特性和软件复杂
性的评估结果，估算软件规模，所以在系统设 计初期就能够估算出软件项目的规模。
信息域特性
产品信息域的5个特性：
输入项数(Inp) 输出项数(Out)
软件向用户输出的项数，它们向用户提供面向应用的信息
第六讲_软件工作量估计
attribute values effort attribute values effort attribute values effort
Select case with closet attribute values
信息科学与技术学院
2014年3月25日
类比估计的步骤
如何描述实例特征
通过选取合适的相似度、相异度的表达式，评 价相似程度
2014年3月25日
信息科学与技术学院
COSMIC-FFP
The following are counted: Entries 进入: movement of data into software component from a higher layer or a peer component Exits 退出: movements of data out
[2. Stop when you get to what one person can do in one/two weeks] 3. Estimate costs for the lowest level activities
4. At each higher level calculate estimate by adding estimates for lower levels
2014年3月25日
信息科学与技术学院
权：构件的复杂度
External user types Low complexity Medium complexity High complexity
EI
EO EQ LIF EIF
3
4 3 7 5
4
5 4 10 7
6
7 6 15 10
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
类比估算的优缺点
不能使用于早期规模不确定的情况。 一般在已经有经验的狭窄领域。 难于适应新项目中约束条件、技术、人 员等发生重大变化的情况。
5.8 Albrecht功能点分析
功能点发进行估算的时候具体过程是： 1.对估算功能单元的类型进行识别 2.计算每种类型的复杂度． 3.计算总体的调整前的功能点数 4.根据调整因子对功能点数进行调整
5.4 软件估计基础 需要历史数据 工作的度量：SLOC/KLOC 复杂性：取决于估计人员的主观判 断
5.5 软件工作量估计技术
算法模型 专家判断 类比 帕金森法 嬴的价格 自顶向下 自底向上
5.5.1 由底向上估计
估计人员将项目分解成构件任务，然后估 计执行每个任务需要多少工作量。 由底向上法最适合于后期的更详细项目策 划阶段。 如果一个项目完全是新颖的或者没有可用 的历史数据，那么建议估计人员最好使用 由底向上方法。
5.12.1 基本COCOMO模型
E = ab(KLOC)exp(bb) D = cb(E)exp(db) 式中E为开发所需的人月，D为所需的开发 时间（月），KLOC为估计提交的代码行。 ab、bb 、 cb 、 db是指不同软件开发方式 的值。具体见下表：
5.12.1 基本COCOMO模型
生产率 = （KLOC）/E（代码行/人月） 人员数 = E/D
对付误差的方法
避免低劣估算 表达方式技巧
加减限定表示 范围表示 风险量化 分情况阐述
处理低劣估算带来的结果
功能点计算公式
FP = UFC *TCF 其中， UFC表示未调整的功能点计数； TCF表示技术复杂度因子。
5.8 Albrecht功能点分析
Albrecht复杂度因子（主观）
5.8 Albrecht功能点分析
技术复杂度因子
TCF=0.65+0.01（sum（Fi）） TCF范围：0.65—1.35
5.5.2 自顶向下法和参数模型
自顶向下法通常和参数模型相关。参数模型 公式如下：工作量 = 系统规模×生产率 预测软件开发工作量的模型有两个关键构件： 第一个是评估要承担的软件开发任务的规模 的方法；第二个是评估做每项任务的效率。
5.6 专家评判
专家评判往往是使用已标识的来自过去类
综合结果后，再次填写表格，比较估算 偏差，找出原因。 重复多次，最终获得一个多数认可的软 件规模。
5.7 类比估计
即基于案例的推理。估计人员从已经完成的项 目中找出与新项目有类似特征的项目，然后将 匹配的源案例已经记录的工作量作为目标案例 的估计基础。然后对新项目进行估计。 项目间的接近程度计算方法：
5.10 对象点
5.11 面向过程代码的方法
设想在最终系统中程序的数据和类型 估计每个已标识程序的SLOC 估计工作内容、考虑复杂度和技术难度 计算工作量（工作天数）
5.12 COCOMO模型
COCOMO：Constructive Cost Mode
分为基本COCOMO模型，和中级 COCOMO模型两种，前者是一个静态单 变量模型，对整个软件系统进行估算；后 者是一个静态多变量模型，将软件系统模 型分为系统和部件两个层次，系统是有部 件组成的。
软件的新颖应用 变更技术 缺乏同类项目的经验 估计的主观特性 角色因素
5.2 在何处进行估计
战略策划 可行性研究 系统规格说明 评价供应商建议书 项目策划
5.3 估计过高和估计过低的问题
帕金森定律：工作总是用完所有可以利用 的时间。 布鲁克斯定律：在一项延迟的工作上投入 更多的人，可能导致该项工作更加延迟。 估计实际上不是预测，而是一个管理目标。
例子：假设技术复杂度为平均水平
简单
外部输入 6
一般
2
复杂
3
外部输出
外部查询
7
0
7
2
0
4
外部文件
内部文件
5
9
2
0
32Biblioteka 1. 计算UFC简单
外部输入 6*3
一般
2*4
复杂
3*6
外部输出
外部查询
7*4
0*3
7*5
2*4
0*7
4*6
外部文件
内部文件
5*5
9*7
2*7
0*10
3*10
2*15
UFC=301
134
功能单元的类型
外部输入类型：通过界面等的输入，插入更新等 操作都是典型外部输入 外部输出类型：仅仅输出，入导出，报表，打印 等输出 内部逻辑文件类型：可以理解为业务对象，可能 对应多个数据表 外部接口文件类型：其它应用提供的接口数据 外部查询类型：先要输入数据，在根据输入数据 计算输出，如查询
似项目的非正式的类比法和由底向上估计 法相结合的方法。
Deiphi方法
组织者发给每位专家一份规格说明和记录表格， 请专家估算。 每位专家提出3个规模的估计值。
最小值ai 最可能值mi 最大值bi
组织者整理，计算每位专家的平均值 Ei = （ ai +4 mi + bi ）/6 计算期望值：E = (E1+……+En)/n
方式 有机 半有机 嵌入
ab
2.4 3.0 3.6
bb
1.05 1.12 1.2
cb
2.5 2.5 2.5
db
0.38 0.35 0.32
对于工作量E的公式, 当项目复杂性从有机向嵌入方式 转变时, 参数ab、bb 的取值逐步增加, 这反映了人力 的增长, 说明项目越复杂就需要越多的开发工作量。 而开发工期D的公式则不存在这种相应递增的关系, 即 随着项目复杂性的增加, 参数cb、db 并不相应增大, 这是由于开发部门对于复杂的大项目往往投入较强的 技术力量, 因此实际工期并不一定延长 这里需要指出的是上述参数取值仅仅是在63 个开发项 目的基础上用曲线拟合方法得到的, 因而只能作为一 种大致的测算公式。
165
102
2. 计算TCF
TCF = 0.65 + 0.01*(14*3) =1.07
3. 计算功能点FP
FP = UFC*TCF =301*1.07=322
5.9 MarkⅡ功能点
5.9 MarkⅡ功能点
对于每个事务，为调整的功能点的计算方 法： Wi × (输入数据元素类型数) + We × (引用的实体类型数) + Wo × (输出数据元素类型数)
5.13 代码行的成本估算方法
求期望值Le和偏差Ld
a 4m b Le 6
ba Ld i 1 6
n 2
式中n表示软件功能数量
5.13 代码行的成本估算方法 根据经验数据，确定各子功能的代码 成本行 计算各子功能的成本和工作量 计算开发时间 对结果进行分析比较
5.13 软件生产率
软件生产率是指每个人一个月所能生产的 有效源代码行数。 对软件生产率影响的因素很多，要得到准 确结果并不容易。其影响因素为： 人的因素、问题因素、过程因素、生 产因素、资源因素。
5.13 代码行的成本估算方法
确定功能
首先将功能反复分解，直到可以对为实现该功 能所要求的源代码行数做出可靠的估算为止。 然后可以给出极好、正常和较差三种情况下的 源代码估算行数的期望值，分别用a、m、b 表示。
估算的误差度
类型
量级估计：合 同前 预算估计：合 同期 确定性估计： WBS之后
准确度
-25%---+75% -10%---+25% -5%---+10%
说明
概念和启动阶 段 初步计划 详细计划
估算不准的主要原因
基础数据不足 对需求理解的程度 软件项目的不确定 缺乏经验的估计人员 签约前后不连贯和低劣的推测技术
第5章 软件工作量估计
本章目的
避免不现实估计的危险 了解可以使用的估计方法的适用范围 使用由底向上的方法估计项目 计算系统的功能点和对象点 估计使用过程编程语言实现软件所需要的 工作量 了解开发工作量模型COCOMO方法
5.1 引言
成功项目的一个定义是系统能够按时和在 预算内交付，并能满足要求的质量。 估计过程的困难：
欧几里得距离：[(目标参数1-源参 数1)2+ … +(目标参数n-源参数n)2]1/2
类比估算要解决的问题：
如何描述实例特征。 通过选取合适的相似度、相异度的表达 式，评价相似程度。 如何用相似的项目数据得到最终估算值。
例子：
假定比较的案例基于两个参数。即构建 系统的输入数和输出数。已知新项目有7 个输入和15个输出。过去有一个项目A有 8个输入和17个输出。项目B有5个输入和 10个输出。求欧几里得距离，判断项目A 和B那个更接近新项目。
5.12.2 中级COCOMO模型
基本模型考虑了软件开发方式和软件规模 这两个重要因素, 为了提高测算精度，采 用中级COMOCO模型。 先产生一个与基本COCOMO模型一样形 式的估算公式，然后对15个“成本驱动属 性”进行打分，定出“乘法因子”，对公 式进行休整。 产品属性 计算机属性 人员属性 项目属性