第5章 软件估算讲义-6-2010
软件工程第05讲
第5章 软件项目计划
LOC和FP 估算技术在分解所要求的详细程度上 及划分的目标上有所差别。基于LOC的估算 要求功能分解尽可能的详细，分解的程度越 高，就越能建立合理的准确的代码。
对于FP估算，分解则是不同的，他集中于功能 上，而是要估算每一个信息域特性—输入、 输出、数据文件、查询和外部接口以及十四 个复杂度的调整值。
其他功能类似。
第5章 软件项目计划
（1）用户界面及控制机制 （2）二维几何分析 （3）三维几何分析 （4）数据库管理 （5）计算机图形显示机制 （6）外设控制 （7）设计分析模块 总代码行数估算
2 300 5 300 6 800 3 350 4 950 2 100 8 400 33 200
第5章 软件项目计划
第5章 软件项目计划
5.3.2 一个范围定义的例子
与用户通信使得我们可以定义数据、功能、必 须实现的行为、性能、约束及相关信息。如， 假定要开发驱动一个传送带分类系统的软件， 范围说明如下：
传送带分类系统（CLSS）将沿传送带移动的盒 子进行分类。每一个盒子由一个包含零件号 的条形码来标识，并在传送带末端分送到六 个箱子中的一个。这些盒子要通过一个由条 形码阅读器及一台PC所组成的分类站。分类 站的PC 连接到一个分流器上，他把盒子分送
第5章 软件项目计划
（2）具有完全经验的构件 （3）具有部分经验的构件 （4）新构件 5.4.3 环境资源 支持软件项目的环境通常被成为软件工程环境。
集成了硬件及软件两大部分。 5.5 软件项目估算
软件成本及工作量估算永远不会是一门精 确的估算。人员、技术、环境和策略，这些 都影响了软件的最终成本及开发所需的工作 量。
软件项目估算指南
项目估算指南Version 1.1文档名称：CMMI5-项目估算指南-V1.1.doc修订历史记录版本号修改人核准人修改说明日期1 2 3 45 6目录目的 (4)范围 (4)术语、缩写词 (4)估算过程 (4)4.1 简要说明 (4)4.2 流程图 (5)4.2.1 自顶向下的方法 (5)4.2.2 自底向上的方法 (6)4.3 估算规程 (6)4.4 裁剪指南 (7)估算方法 (7)5.1 UCP估算算法 (7)5.1.1 估算UUCP (8)5.1.2 估算TCF调整因子 (8)5.1.3 估算EF调整因子 (9)5.1.4 估算UCP (10)5.1.5 估算工作量 (10)5.1.6 估算进度 (10)5.1.7 估算成本 (10)附录 (11)6.1 生产率数据来源 (11)6.2 进度估算数据来源 (11)项目估算指南目的本文用于估算软件项目的规模、进度、工作量、成本，以指导项目作出合理的估算。
范围本文件包括软件项目估算的各个方面，包括规模、进度、工作量、成本，并包括其在项目的中 的分布估算。
本文件合用于公司所有项目。
术语、缩写词UCP估算过程简要说明准确的估算是最大可能加快开辟速度的基础，没有准确的进度估算，再有效的进度计划也无从 谈起。
不切实际的估算、不正确的期望是带来项目问题的主要原因。
估算是一个不断改进的过程，惟独当详细地理解了每一个功能，你才有可能准确估算出软件开辟 的进度和成本。
因此，能够提前做出的决策越多，估算的精确度就越高。
准确的估算可以更好的控制项目的规模、进度、成本。
工作量和进度估算通常在提交建议书及 制定项目计划时进行，在项目实施过程中，也可能要对工作量和进度重新估计。
对于软件规模的估算主要有三种方法：代码行，功能点，用例点。
本公司现在主要使用用例点 方法。
对于工作量的估计，主要有两种方法：自顶向下的方法(Top-down approach )，用一个简单的方程从估计的规模求出估计的总工作量，各阶段的工作量可以根据它们占总工作量的百分比而得到。
软件工程中的项目估算与计划
制作人： 时间：202X年X月
目录
第1章 软件项目估算与计划简介 第2章 软件项目估算 第3章 软件项目计划 第4章 软件项目监控与调整 第5章 软件项目管理工具与实践 第6章 软件项目管理的未来发展 第7章 总结与展望
●01
第1章 软件项目估算与计划简介
软件工程概述
效率。
项目估算的方法
基于经验的估算
基于类比的估算
基于参数的估算
项目规模估算
功能点估算方法
基于功能点进行估 算
项目规模估算的工 具与实践
使用工具进行实践 性规模估算
基于工作量的估算 方法
根据工作量进行估 算
项目成本估算
项目成本估算的各个方面
包括人力成本、材料成本等
成本估算的技术指标
以指标为基础进行成本估算
进展
变更管理与控制
里程碑制定与跟踪
管理项目变更，确 保项目方向不偏离
设定关键里程碑， 追踪项目进展
项目调整与变更
项目变更管理流程
识别变更需求 评估变更影响 批准或拒绝变更
变更影响评估
分析变更对项目的影响 评估风险和成本
调整措施与实施
制定调整方案 实施变更控制
项目成果评估与总结
项目交付成果评估是项目成功的重要标志，总结经验教 训有助于提升未来项目管理水平。同时，项目后评估与
项目计划的内容
里程碑计划、资源计划、进度计划、风险计划
软件项目管理概念
项目管理的定义
规划、组织、指导 和控制项目活动
项目管理的方法
项目管理的重要性
敏捷方法、瀑布模 型、迭代开发
确保项目按质、按 时、在预算内交付
●02
第5章 软件工作量估计 - 对外经济贸易大学教学辅助平台
功能点估计
EI: External Input外部输入 更新计算机系统内部的 输入事务。 如：录入订单、修改订 单、删除订单
33/59
功能点估计
EO: External Output外部输出 输出数据给用户的事务。特点 a) 原子性（Elementary process） b) 来自边界外（cross boundary） c) 运算后输出 对内部的数据进行处理之后输出的结果 （如sum之后打印）
17/59
第二节 工作量估计
三、何处需要进行估计
项目估算类型 1. 初步量级估算
项目初期，属于自顶向下估算，误差较大，-25%~75%
2. 预算级估算
项目计划过程中，属于自顶向下估算，误差-10%~25%
3. 定义级估算
项目计划过程后，属于自底向上估算，误差-5%~10%
18/59
第三节 信息系统工作量估计方法
由底向上、自顶向下、类比、专家判断、算法 模型。 单位：SLOC，KLOC，人· 天 一、估计方法 1. 由底向上估计
估计人员将项目分解成任务，任务进一步分解成子 任务，直到子任务能被一个人在1-2周内完成 为止（活动资源估计）。然后对各子任务的工 作量进行估计、汇总，计算出项目总工作量。 适合项目后期的更详细的项目策划。
28/59
功能点估计
ILF(Internal Logical File)内部逻辑文件 是指一组以用户角度识别的，在应用程序边界 内且被维护的逻辑相关数据或控制信息。 ILF的主要目的是通过应用程序的一个或多个 基本处理过程来维护数据。
29/59
一个外贸订单系统只包含录入、修改、删除、查询和统计
25/59
第三节 信息系统工作量估计方法
第5章 软件估算讲义-6-2010
软件估算步骤
Software Estimation
1. 确定软件范围
2. 确定工作所需资源
3. 确定估算内容
4. 估算改进
软件估算步骤
确定软件范围
Software Estimation
确定软件估算范围，就是确定目标 软件的数据和控制，功能，性能， 约束，接口以及可靠性。
软件估算步骤
确定工作所需资源
确定工作所需资源
Software Estimation
可重用软件资源可分为以下几种：
能够从第三方厂商获得或已经在 以前的项目中使用过的软件，这 些构件已经经过验证及确认，且 可以直接用在当前的项目中。 、以前在类似项目中建立的规约， 设计，代码或测试数据，在本项 目中需做修改。 、以前在类似项目中建立的规约， 设计，代码或测试数据，在本项 目中需做实质上的修改。
案例（续）
Case Study
Software Estimation
——凭直觉的项目估算
Carl的团队努力地工作着，进展稳定，但需求分析的时间比期望的要长。预定6个月 要完成的项目已经过去4个月了。“2个月无论如何也做不完剩下的工作。”他只好告诉 Bill，项目需要延长2个月，总共需要8个月时间。 几个星期后Carl意识到设计进度也不像期望的那么快。“先做容易的部分，”他告诉 项目组成员，“其余的部分遇到时再考虑。” Carl再次向监督委员会汇报：“8个月的项目已经过去7个月，详细设计基本完成，工 作卓有成效，但是8个月内还是无法完成。”Carl通报了第2次进度拖延，并将完成时间定 为10个月。Bill对拖延产生了抱怨，并要求Carl想办法仍将进度安排在8个月左右。 第9个月，项目组完成了详细设计，但部分模块的编码还没有开始。Carl第3次要求要 求延期——12个月。Bill? 编码进行顺利，但一些地方需要重新设计和重新实现，而这些地方项目组没有把详细 设计调整好，一些实现过程相互冲突。在第11个月的项目监督委员会上，Carl宣布了第4 次项目延期——13个月。Bill？ 结果？ ……
软件项目管理5 软件估算
实际工作量
• MM= A*(kDSI)B*(f1*f2*…….*f15)
• 成本驱动因子 P96
例：一个规模为10KDSI的商用微 机远程通信嵌入软件，使用中 间COCOMO模型进行软件成本估算. 则： • 程序名义工作量
MM=3.2*(10)1.20=50.72(MM) •程序实际工作量
MM=50.72* f1 * f2 * f3…… * f15=50.72*1.17=59.34(MM)
初始的 批准的 需求 产品设计 详细设计 产品 产品定义 产品定义 说明书 说明书 说明书 完工
Software Estimation
Software Estimation & Measurement
5.2.3，5.3 估算内容与方法
1. 估算产品规模（代码行或功能点） 2. 估算工作量（人月） 3. 估算进度（日历月份）
5.1The Software-Estimation Story ——软件开发是一个改进的过程
盖一幢房子要花多少钱呢？这取决于房子本身。一个新的计费系 统要花多少钱呢？这也取决于计费系统本身！
和建筑相比，软件设计没有可参考的准确的标准数据，评价估 算准确度的最常见标准：一个良好的估算方法应该在75%的时间内都 能提供与实际结果相差不超过25%的估算结果。
Software Estimation
Software Estimation & Measurement
Input： 需求说明书 系统设计 对象设计 变更请求
Output： 软件规模 工作量 进度
Software Estimation
5.1 Introduction
Software Estimation & Measurement
软件项目管理第5章 软件项目成本估算
若五个人共同开发(即n=5)，则每个成员的软件生产率 降为250行/人月；
第5章 软件项目成本估算
软件项目的实施离不开软硬件的支撑，例如操作系统、 计算机/服务器、数据库系统和开发工具等，也需要舒适的 办公环境和人性化的管理制度，因此合理规划软件开发所需 的环境资源，有利于保障项目在有限经费的支撑下高效推进。
3. 估算规模和工作量 采用WBS，确定和说明项目包含的工作(任务)，然后借 助软件生产率将其转化为工作量，为下一步估算进度和成本 提供依据。 软件生产率是指软件规模与软件工作量的比值。一般用 代码行/人月、功能点/人月来表示。
第5章 软件项目成本估算
(4) 接口包括：转入(导入)来自一个或多个别的系统？ 转出(导出)至一个或多个别的系统？有用于格式化数据的规 定的方式吗？
(5) 可靠性包括：系统必须检测并隔离故障，失败间隔 的平均时间规定为多少，对一次失败后重启系统的最大时间。
第5章 软件项目成本估算
2. 确定项目的资源需求 如何配置人力资源和环境资源对软件项目的进度和成本 估算有着非常重要的影响。 项目团队的规模和素质关系到开发方能否以最高的效率 和最小的成本完成既定任务和目标，不同水平和责任心的项 目组成员完成同一任务所需的时间和质量有着明显的差异， 所以确定项目可用的人力资源时，需要考虑软件系统的复杂 性、技术的难易度、用户对进度的要求和项目经费的支撑能 力等因素。
第5章 软件项目成本估算
估算意义 O
估算精度 项目进度
图5.2 软件项目估算的意义和精度(估算的意义随项目的进展 逐渐减弱，估算的精度则正好相反)
第5章 软件项目成本估算
因此，软件项目估算具有以下几个特点。 (1) 估算是有误差的。实践证明，大多数项目超过估算 25%到100%，但也有少数的估算准确到10%以内。 (2) 经验(历史)数据非常重要，这种估算大多是利用以 前的代价和经验作为参考而做出的。 (3) 估算可以借助估算工具和数学模型进行，旨在减少 人为误差，但不要过分迷信数学模型。 (4) 软件开发是逐步细化的过程，估算也是随项目的进 行逐步求精的过程，因此项目估算要考虑合适的时间节点。
软件项目估算
软件项目估算学院：数学与计算机科学学院专业：计算机科学与技术(软件工程方向）班级：软件12学号:1060612014049姓名:邓茂记时间：2014年5月10日软件项目估算是软件项目管理的核心所在，通过估算才能得出软件项目的计划，并成为软件项目控制的依据.一个成功的软件项目首先要有一个好的起点，也就是一个合理的项目计划,而一个好的项目计划，离不开一个准确、可信、客观的项目估算。
但是因为软件本身的复杂性、历史经验的可重复性、估算工具的缺乏以及一些人为错误,都会导致软件项目的估算往往和实际情况相差甚远。
软件项目估算的目的在于为软件项目制定一个预算，确定项目目标是否能够实现，从而让项目在可控的状态下达成这个目标，同时为后续的软件质量提供对比依据，从中找出项目中存在的问题和好的经验,促进企业的持续改进.对项目经理来说，合理、有效的项目估算能够让自己在工作中掌握主动权，否则在工作中只能是疲于奔命。
软件项目估算主要包括规模估算、工作量估算和成本估算.软件项目估算一般分为两种应用场景：一是招投标的时候用来估价、报价；二是用来安排进度计划和指导项目具体工作的分配。
前者是为了确定承接项目签合同进行的估算，后者是在项目确定后进一步的细化估算，往往前者的结果可能会影响项目的执行。
一个完全准确地估算基本是不可能的，这主要在于估算本身存在很多困难。
进行软件估算的困难有些是软件本身所固有的，特别是软件的复杂性和不可见性。
在估算一个软件项目时，软件项目经理需要明确以下三点：一是软件本身是非常困难的，但是估算又是必须的。
二是只有准确地估算软件的功能,才能准确地估算出软件的成本，并制定出合理的进度计划。
三是估算终究是估算,一个准确的与实际情况一模一样的估算是不可能的.软件的估算有主观和客观两种估算方法。
主观的估算方法可以通过召集项目团队成员，或者邀请各方面的专家，共同对某个项目的属性进行评估，参与评估的每个人都要单独进行估算,如果发现大家对某个项目属性估算的结果存在较大偏差，那么就需要做进一步的讨论，直到取得共识为止，对个别特殊属性进行主观估算时，一定要有直接干系人的参与.客观的估算方法是利用公司提供的各种度量数据进行估算。
软件工程中的软件项目估算教程
制作人： 时间：202X年X月
目录
第1章 简介 第2章 项目估算的基本概念 第3章 项目估算工具与技术 第4章 项目估算实践与案例分析 第5章 项目估算的挑战与解决方案 第6章 总结与展望
●01 第1章 简介
项目估算概述
项目估算是软件工程中非常重要的一环，涉及项目的成 本、时间和资源预测。准确的估算有助于制定合理计划，
专家判断法
依赖专家经验判断 适用于小型项目
类比估算法
参数化估算法
基于类似项目的历史数据 用于大型项目估算
根据参数模型进行估算 适用于复杂项目
自下而上估算法
从细化任务开始估算 适用于详细项目计划
结尾
软件项目估算是软件工程中的关键环节，通过本教程，希望 您能更深入了解项目估算的重要性和方法，提升项目管理能
自动化估算
借助人工智能和大数据技术，实现软件项目估算的自动化
数据驱动决策
基于数据分析结果，提供决策支持，优化项目规划和执行
敏捷方法应用
采用敏捷开发模式，灵活应对项目需求的变化
软件项目估算的价值
软件项目估算是软件工程中的重要环节，它能够帮助管理者、 开发人员和利益相关者更好地理解和规划项目，确保项目按 时交付、在预算内完成，并达到高质量的标准。因此，深入 学习和实践软件项目估算，对提升软件工程水平和项目管理
数据分析工具
Excel - 数据处理和分析 SPSS - 统计分析 Tableau - 数据可视化
敏捷估算方法
游戏形式促进团队合作 通过投票提高估算准确性 专家逐轮评估确定估算值
机器学习应用
分析大量项目数据 预测项目成本、时间和资源需 求 提高估算准确性和效率
总结
软件价格估算方法
软件价格估算方法1．软件开发价格估算方法软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。
为了便于计算，给出一个计算公式：软件开发价格＝开发工作量×开发费用／人•月1.1开发工作量软件开发工作量与估算工作量经验值、风险系数和复用系数等项有关：软件开发工作量＝估算工作量经验值×风险系数×复用系数。
1.1.1估算工作量经验值（以A来表示）软件开发工作量的计算，曾有人提出以源代码行或功能点来计算，这些方法实施起来均有不少难度。
目前国际上仍旧按以往经验的方式加以计算，国内各软件企业也是采用经验的方式加以估算工作量。
为了更好地规范估算方法，建议可按照国家标准“GB／T 8566-2001软件生存周期过程”）所规定的软件开发过程的各项活动来计算工作量。
工作量的计算是按一个开发工作人员在一个月内（日历中的月，即包括国家规定的节假日）能完成的工作量为单位，也就是通常所讲的“人•月”。
特别要提醒的是软件开发过程中既包括了通常所讲的软件开发，也应包括各类软件测试的活动。
1.1.2风险系数（以σ来表示）估算工作量经验值亦会存在较大风险，造成软件危机的因素很多，这也是一个方面的因素。
特别当软件企业对该信息工程项目的业务领域不熟悉或不太熟悉，而且用户又无法或不能完整明白地表达他们的真实的需求，从而造成软件企业需要不断地完善需求获取，修改设计等各项工作。
因此：l ≤风险系数≤1.5根据我们对软件企业的了解，超过估算工作量经验值的一半，已是不可接受，所以我们确定“1.5”为极限值。
当然这既要看企业的能力，也要看用户能接受的程度。
1.1.3复用系数（以τ来表示）估算工作量经验值是软件企业承担一般项目来估算的，但如果软件企业已经采用“基于构件的开发方法”，并己建立起能够复用的构件库（核心资产库），或者已有一些软件产品，仅作二次开发，从而使软件开发工作量减少。
因此：0.25 ≤复用系数≤1根据国内外软件企业在实施基于构件开发方法（软件产品线）的经验数据，提高工作效率达到25%（最高值）。
lecture5(工作量估算)
外部输入：更新内部计算机文件的输入事务。 外部输出：给用户输出数据的面向应用的信息 内部逻辑文件：系统使用的可以访问的一组数据 外部接口文件：与其它系统交换信息 外部查询：提供信息的用户引发的事务，用户输入 信息以得到需要的信息。
工程硕士
功能点方法
标出系统中每个外部用户类型的每个实例，分类为高、 中、低三种复杂度；每种复杂度区的每个外部用户类 型的数目乘以指定的权重，得到功能点数，相加得到 总的功能点数，表示系统的规模。
工程硕士
功能点方法：复杂性判定
如何判定功能的复杂度？ 国际功能点用户小组（IFPUG)制定了用于判断复杂度 的规则。
例如：内部逻辑文件、外部接口文件
例如：外部输入文件
工程硕士
功能点方法：复杂度判定
例如：外部输出文件
工程硕士
案例
例：一个内部逻辑文件包含订单的数据，订单用两种 记录类型表示，分别记录订单的信息和订单项的信息。 其中订单包括：订单号，供应商名称，订单日期，订 单项包括商品号，价格和数目。 记录个数为2，数据类型是6，根据下表可以确定该功 能点复杂性为低。
工程硕士
练习
外部输入：无 外部输出：报表，1 内部逻辑文件：会计系统输入文件，1 外部接口文件：工资文件，人员文件，课程文件， 会计系统输入文件，4 外部查询：无
考虑加权：
外部输入：无；外部输出：1×7＝7；内部逻辑文 件：1×10＝10；外部接口文件：4×7＝28；外部 查询：无； 总功能点数(系统规模)：1×7+ 1×10+ 4×7=45
工程硕士
工作度量
软件估算ppt
估算方法-功能点
代码需要设计为可复用的吗？ 安装方便吗？ 操作方便吗？（如启动、备份、恢复等是否高效） 系统是否需要为不同的组织进行设计、开发、安装 在多个地方吗？ 系统是否专门设计成适应并支持变化吗？
TPCA SEPG
2019/4/25
37
估算方法-功能点
• 面向功能的软件估算，通过对软件所提供的功
能的度量作为规范化值。 • “功能“不能直接度量，所以引入功能点，允 许以标准单位对软件规模进行度量。 • 说明
功能点是度量软件的一种单位，如同小时用于度量
时间，公里度量距离，属于序数单位。 完全从功能角度出发，与语言等具体技术无关。 提供跟踪和监控项目范围的变化。
估算方法-功能点
信息流动
• 信息从系统边界之外进入 系统
EI： External Inputs ILF：Internal Logical File
TPCA SEPG
2019/4/25
21
估算方法-功能点
信息流动（续）
• 信息从系统边界内 部流向外部
EO： External Outputs
2019/4/25 32
TPCA SEPG
估算方法-功能点
文件类型参照（FTRs）
• 一个FTR表示被一个事务引用的文件类型，它同 时一定是一个内部逻辑文件或外部接口文件 • 例如：
一个外部输入更新一个内部逻辑文件,但是同时引 用一个 “安全性文件”以保证某个用户具有适当 的权限，此时存在两个FTR’s
注：进度和费用可以依据工作量和工资得到
TPCA SEPG 2019/4/25 16
软件项目估算方法
估算方法-概述
软件估算规程
文件编号：CMMI/09错误！未找到引用源。
软件估算规程V4.0起草部门：品管部管理部门：品管部撰写人：审核人： EPG批准人： EPG发布日期:软件估算规程目录1目的 (3)2适用范围 (3)3术语定义 (4)4估算时机和参与人员 (4)5估算原则 (6)6估算流程图 (7)7估算前准备工作 (8)8编码与单元测试工作量估算 (8)8.1 D ELPHI估算过程 (9)8.2 功能点估算过程 (9)9项目总工作量估算 (16)9.1 估算过程描述 (16)9.2 工作产品 (17)10代码规模估算 (17)11进度估算 (17)12缺陷估算........................................................................................................... 错误！未定义书签。
13估算差异分析.. (18)14度量 (18)15附录一：PERT法介绍 (18)16附录二：功能点计算场景示例 (20)1目的软件估算的目的是通过对软件项目开发规模和工作量的估算，确认项目开发的成本、开发周期，以作为项目投标、立项的依据，并指导项目进度计划、资源规划及项目成本控制。
给软件开发中的活动、工作产品以及各种角色（包括用户）建立适当的预期。
以达到支持产品需求、本组织的需求、顾客的需求以及达到他们对该项目提出的目标，确保交付质量合格的产品。
软件项目的估算不是一次估算过程，通常会对项目估算多次。
例如在项目立项时，通过估算，项目组与公司达成成本承诺；在项目需求分析阶段，通过估算以确定项目的初步开发计划；在项目概要设计阶段，通过功能点明细估算确定项目的明细开发计划；在需求变更时，变更内容的估算与需求保持一致，尽可能满足项目的进度安排和预算。
对项目的估算通常包括对软件规模（代码行）、工作量（人天）、成本和关键计算机资源的估算。
软件估算方法
软件规模估算方法软件成本及工作量估算永远不会是一门精确的科学。
太多的变化一一人员、技术、环境、策略一一影响了软件的最终成本及开发所需的工作量。
不过，软件项目估算可以从神秘的技巧向一系列系统化的步骤的转变的过程中，估算出可接受的风险。
现在世界上比较流行的软件估算方法有：模糊逻辑”法，功能点法，标准构件法，修改法，基于代码行(LOC)的估算方法，基于功能点(FP)的估算方法，基于过程的估算方法，基于COCOM模型的估算方法，基于软件方程式的估算方法。
今天，一个软件成本估算模型如果能够达到以下结果就相当不错了：估算的软件开发成本与实际的成本相差不到20%，时间估算相差不到70%，而且是在它自己的地盘上(即，是它适用的项目类型)……这可能不象我们所期望的那么精确，但已经足以在软件工程经济分析及决策中提供很大的帮助了。
为了可靠地估算成本及工作量，结合雁联公司项目历史数据比较缺少的特点。
我们建议采用基于功能点(FP)的估算方法来估算工作量。
以下是基于功能点(FP)估算方法的估算流程及估算例子。
基于FP估算的分解是集中于信息域值，而不是软件功能。
根据功能点计算方法原理，项目经理要从软件的输入、输出、报表、接口、内部处理及其他六方面进行估算。
为了达到这个估算目的，我们假设复杂度加权因子都是平均的。
项目经理根据自己的经验，按要求填写好基于功能点(FP)估算方法的工作量估算表格说明：1、功能点分解说明3、表格中估算计数为估算变量(规模)的期望值即EV(expected value)，可以通过乐观值(S opt)、可能值(S m)、及悲观值(S pess)估算的加权平均值来计算：EV=(S opt+4S+S pess)/6 (公式)其中给予可能值”估算以最大的权重，并遵循B概率分布。
4、表格中加权因子由估算人员根据其经验对软件的输入、输出、查询、文件、及外部接口五方面功能点复杂度和所花时间的加权。
建议加权因子取值范围为整数(0-10)5、其中公式E (工作量)二FP estimated /a中系数a为生产率。
软件项目估算过
目录1.目的12.范围23.估算过程23.1规模和工作量估算23.1.1 单元复杂度定义33.1.2 工程的单元分解33.1.3 规模和工作量估算33.1.4 工程整体开发工作量估计33.2进度估算43.3风险的估算43.4关键计算机资源估算53.5工程成本及报价参见〈工程估算表〉63.5.1人力成本63.5.2非人力成本63.5.3工程成本63.5.4工程报价64.估算方法65.工程估算评审76.参考资料71.目的软件估算的目的是通过对软件工程经管和开发工作量的估算, 确认工程开发的成本, 开发周期以作为工程投标、立项的依据. 对工程的估算通常还包括对软件大小(Size) 、软件工程风险和关键计算机资源的估算等.对软件的估算很难以精确或准确来衡量, 相反以其合理性来评估. 工程的估算通常和市场价格、商务目标、工程经验和开发成员的工作弹性相关并是上述方面的综合反映.2.范围软件工程的估算不是一次估算过程. 通常会对工程估算多次. 例如在商务过程中, 通过估算进行报价和投标。
在工程计划过程中, 通过估算以确定工程开发计划。
在里程碑评审和变更过程, 通过估算和归纳总结调整工程计划.3.估算过程3.1规模和工作量估算在估算过程中，根据工程的类型、技术、语言和其他属性，尽可能地参照以往工程的数据，基于以往工程的历史数据，对指定工程的程序单元进行划分和确认。
如果没有可供参照的历史数据，使用Delphi等方法进行估算。
3.1.1单元复杂度定义软件工程经理根据以下表格并结合工程的历史数据，确定本工程的单元复杂度规范。
（下表列出了制定复杂度规范时参考的因素，具体到各工程，需要软件工程经理3.1.2工程的单元分解•软件工程经理组织相关人员参照定义的规范进行系统分解，以确认系统的程序单元以及程序单元的复杂度。
3.1.3规模和工作量估算在确认完成简单、中等和复杂后，软件工程经理可以参照历史数据或用Delphi 法对工作量或规模进行估算，并把结果登记到程序单元估算表中。
软件工程估算
软件工程估算1、引言本章节介绍软件工程估算文档的目的、范围和背景。
1.1 目的1.2 范围本文档适用于软件开发过程的估算，包括但不限于需求分析、设计、编码、测试和部署等各个阶段。
1.3 背景软件工程估算是在软件开发过程中确定工作量、时间和成本等重要参数的过程。
准确的估算能够帮助项目经理和团队制定合理的计划和预算，从而提高项目的成功率和效率。
2、估算方法本章节介绍软件工程估算的常用方法和技术。
2.1 单纯经验法单纯经验法通过根据过去类似项目的经验数据进行估算，结合专业知识和直觉进行调整和修正。
2.2 参数估算法参数估算法根据项目的特征和需求，选择相应的参数进行估算。
参数可以是人天、工作量、功能点等。
2.3 模型估算法模型估算法使用数学模型和统计分析等方法，根据项目的特征和历史数据等进行估算。
2.4 混合估算法混合估算法是综合以上方法的组合，根据具体情况选择合适的估算方法。
3、估算过程本章节详细描述软件工程估算的流程和步骤。
3.1 需求分析在需求分析阶段，收集和分析项目需求，并根据需求特征选择合适的估算方法。
3.2 估算参数确定在估算参数确定阶段，确定估算所需的参数，如工作量、时间、人力资源等。
3.3 估算方法选择根据项目的特点和要求，选取合适的估算方法，如单纯经验法、参数估算法、模型估算法或混合估算法。
3.4 估算计算根据选定的估算方法，进行具体的估算计算。
可以使用电子表格工具或专业估算软件进行辅助计算。
3.5 估算结果分析分析估算结果的合理性和可行性，并与项目经理和团队进行讨论和确认。
4、结果和报告本章节介绍软件工程估算的结果和报告的内容和格式。
4.1 估算结果总结将估算结果进行总结和归纳，包括工作量、时间、成本等重要参数。
4.2 报告撰写撰写估算报告，包括具体的估算方法、结果和参数，以及讨论和分析。
4.3 报告审核报告由项目经理和团队成员进行审核，确认估算结果的准确性和可行性。
4.4 报告发布发布估算报告，使得相关人员能够查阅和参考。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
有些估算做的很仔细，而有些却只 是凭直觉的猜测。大多数项目超过估算 进度25%到100%，但也有少数一些组织 的进度估算准确到10%以内，能控制在 5%之内的还没有听说（Jones,1994)。
介绍
Software Estimation
软件项目估算是项目计划的依据，但是大多数 软件开发组织没有意识到软件估算的重要性。调 查结果表明：
用估算算法，如功能点方法，特征点，对象点，模糊逻辑，标 准构件法，Delphi方法，PERT方法等。 用规模估算软件。 如果参与过类似的项目，并知道它的规模，那么按百分比形式 估算新系统每个主要部分与旧系统相似部分的规模。每部分的规 模加起来是总规模。
软件估算步骤
工作量估算
Software Estimation
软件估算
Software Estimation
The Software-Estimation Story ——可能细化的数量
项目成本 （工作量和成本） 项目进度
估 算 收 敛 图
4.0x
1.6x 1.25x 1.15x 1.1x 1.0x 0.9x 0.85x 0.8x 0.6x 初始的 批准的 产品定义 产品定义 需求 产品设计 详细设计 产品 说明书 说明书 说明书 完工
对软件所需的工作时间的估算，通常以人时，人天， 人月，人年等单位来衡量。 工作量估算可以采用以下方法进行：
使用估算软件直接从规模估算得出 使用组织中的历史数据确定具有已估算规模的先前的项目花了 多少工作量。 使用COCOMO模型或其他模型将代码行估算转换成工作量估算。 采用Delphi方法，PERT方法等直接进行工作量估算。
确定工作所需资源
Software Estimation
可重用软件资源可分为以下几种：
能够从第三方厂商获得或已经在 以前的项目中使用过的软件，这 些构件已经经过验证及确认，且 可以直接用在当前的项目中。 、以前在类似项目中建立的规约， 设计，代码或测试数据，在本项 目中需做修改。 、以前在类似项目中建立的规约， 设计，代码或测试数据，在本项 目中需做实质上的修改。
第六讲
软件估算
软件估算
Software Estimation
Input： 需求说明书 系统设计 对象设计 变更请求 Output： 软件规模 工作量 进度
软件估算
Software Estimation
The Software-Estimation Story Estimation-Process Overview Size Estimation Effort Estimation Schedule Estimation Estimate Refinement
定义
Software Estimation
估算的通常定义：对未来事实非零可能 性的最乐观的预测。
软件项目估算是指以准确的调查资料和 项目信息(如人员和设备信息)为依据，从估 算对象的历史，现状及其规律性出发，运用 科学的方法，对估算对象的规模，所需工作 量和成本进行的测定。
介绍
Software Estimation
35%的组织没有对软件开发的成本和时间作估算。 50%的组织没有记录任何正在进行的项目的相关数据。 57%的组织没有使用成本会计。 80%的项目在成本或时间上超出预算。 超出成本和时间的项目里仅有50%的是有意义的超出。 进行了成本估算的组织里，62%的组织是基于感觉和经 验，仅仅16%的组织使用了正式的估算方法，如成本估 算模型。
盖一幢房子要花多少钱呢？这取决于房子本身。一个新 的计费系统要花多少钱呢？这也取决于计费系统本身！ 一些组织希望在需求定义投入前就把成本估算的误差 控制在10%以内，尽管项目估算的精确程度越早达到越好， 但理论上是不可能实现的。如果真能那么早实现，精确度 可以控制在2%以内。 软件开发是一个逐步细化的过程，在每个阶段，都可 能做出影响最终项目成本与进度的决策。
功能趋于与可用的资源相匹配 资源趋于与想得到的功能相匹配
产品 规模
功能 资源 项目的演变
产品 规模
功能 资源
项目的演变
期望的功能与可用的资源 大多数软件项目在开始时，期望的功能与可用的资源之间不匹配，但随着项 目的进展，功能或资源（或两者）必定要互相匹配
软件估算
Software Estimation
进度估算方法
经验估算方法
月进度=3.0*人月(1/3) 例：65人月的工作量，进度= 3.0*65(1/3) 1. 12个月 2. 5-6人（65/12） 3.0,4.0,2.5
Software Estimation
进度估算方法
Jones的一阶估算准则
Software Estimation
由功能点计算进度的幂次
2.0x 1.5x 1.25x 1.0x 0.8x 0.67x
0.5x 0.25x
软件估算
Software Estimation
The Software-Estimation Story ——可能细化的数量
基于项目阶段的估算误差系数
工作量和规模 进度
阶段
初始产品定义 批准的产品定义 需求说明书 产品设计说明书 详细设计说明书
软件估算步骤
缺陷数估算
Software Estimation
包括需求，设计，代码中的缺陷，缺陷数 影响项目的工作量，进度估算。 通常以千行代码缺陷数等表示。 缺陷数估算往往需要使用组织中的历史数 据。
软件估算方法
Software Estimation
功能点估算（1984IBM方法）
1. 2. 3. 4. 5. 输入 输出 查询 内部逻辑文件 外部接口文件
乐观
0.25 0.50 0.67 0.80 0.90
悲观
4.0 2.0 1.50 1.25 1.10
乐观
0.60 0.80 0.85 0.90 0.95
悲观
1.60 1.25 1.15 1.10 1.05
软件估算
Software Estimation
The Software-Estimation Story ——估算与控制
案例
Case Study
Software Estimation
——凭直觉的项目估算
Carl负责Gaga-safe公司库存控制系统1.0版本的开发（ICS），在参加项目监督委员会 第一次会议的时候，他对期望的功能已经有了总体设想。Bill是监督委员会的领导，他问： “Carl，ICS1.0需要多长时间？” Carl回答：“大概要9个月，不过这只是粗略的估算。” “不行，”Bill说，“我真希望你说3或4个月，我们一定要在6个月内拿出系统，能完成 吗？” “我不能肯定，”Carl坦白地说，“我还得仔细研究一下，不过我相信可以找到办法在 6个月内完成。” “那么把6个月当成项目完成的目标，”Bill说，“无论如何我们都必须这样做。”委 员会的其他人一致同意了这个决定。 到第五周的时候，又增加了一些产品概要设计工作，这使Carl更确信项目的时间更接 近9个月而非6个月，然而他还是认为运气好的话有可能在6个月内完成项目。他不想被看 作惹麻烦的人，所以决定等等再说。
The Software-Estimation Story ——合作
表达你合作的意愿 估算既不要过高也不要过低，应该正好与费用相符。估算的 目标是寻找估算与实际情况的交汇点。 精确与准确：航班时刻通常精确到分，但不准确。可能的最 短软件开发进度是通过建立最可能的准确估算而不是最精确的估 算达到的。如果想获得最快的开发速度，就要避免错误的精确。
按上表计算未调整的功能点总数 然后根据14个对程序有影响的因素计算“影响系数”，这些因素包括数据通 信、联机数据条目、处理复杂性和安装容易度等。影响系数在0.65到1.35之间。
软件估算方法
Software Estimation
功能点估算（1984IBM方法）
计算功能点数的例子
功能点 程序功能 一般复杂 中等复杂 很复杂
软件估算与建筑预算
Software Estimation
The Software-Estimation Story ——软件与建筑
一年的时间建这样一幢房子？ 没问题！
太好了，那我们赶快开工吧！
软件估算
Software Estimation
The Software-Estimation Story ——软件开发是一个改进的过程
功能趋于与可用的资源相匹配
Software Estimation
资源趋于与想得到的功能相匹配
产品 规模
功能 资源 项目的演变
产品 规模
功能 资源
项目的演变
期望的功能与可用的资源 大多数软件项目在开始时，期望的功能与可用的资源之间不匹配，但随着项 目的进展，功能或资源（或两者）必定要互相匹配
软件估算步骤
案例（续）
Case Study
Software Estimation
——凭直觉的项目估算
Carl的团队努力地工作着，进展稳定，但需求分析的时间比期望的要长。预定6个月 要完成的项目已经过去4个月了。“2个月无论如何也做不完剩下的工作。”他只好告诉 Bill，项目需要延长2个月，总共需要8个月时间。 几个星期后Carl意识到设计进度也不像期望的那么快。“先做容易的部分，”他告诉 项目组成员，“其余的部分遇到时再考虑。” Carl再次向监督委员会汇报：“8个月的项目已经过去7个月，详细设计基本完成，工 作卓有成效，但是8个月内还是无法完成。”Carl通报了第2次进度拖延，并将完成时间定 为10个月。Bill对拖延产生了抱怨，并要求Carl想办法仍将进度安排在8个月左右。 第9个月，项目组完成了详细设计，但部分模块的编码还没有开始。Carl第3次要求要 求延期——12个月。Bill? 编码进行顺利，但一些地方需要重新设计和重新实现，而这些地方项目组没有把详细 设计调整好，一些实现过程相互冲突。在第11个月的项目监督委员会上，Carl宣布了第4 次项目延期——13个月。Bill？ 结果？ ……