第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 软件项目估算
软件成本及工作量估算永远不会是一门精 确的估算。人员、技术、环境和策略，这些 都影响了软件的最终成本及开发所需的工作 量。
第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
制作人： 时间：202X年X月
目录
第1章 软件项目估算与计划简介 第2章 软件项目估算 第3章 软件项目计划 第4章 软件项目监控与调整 第5章 软件项目管理工具与实践 第6章 软件项目管理的未来发展 第7章 总结与展望
●01
第1章 软件项目估算与计划简介
软件工程概述
效率。
项目估算的方法
基于经验的估算
基于类比的估算
基于参数的估算
项目规模估算
功能点估算方法
基于功能点进行估 算
项目规模估算的工 具与实践
使用工具进行实践 性规模估算
基于工作量的估算 方法
根据工作量进行估 算
项目成本估算
项目成本估算的各个方面
包括人力成本、材料成本等
成本估算的技术指标
以指标为基础进行成本估算
进展
变更管理与控制
里程碑制定与跟踪
管理项目变更，确 保项目方向不偏离
设定关键里程碑， 追踪项目进展
项目调整与变更
项目变更管理流程
识别变更需求 评估变更影响 批准或拒绝变更
变更影响评估
分析变更对项目的影响 评估风险和成本
调整措施与实施
制定调整方案 实施变更控制
项目成果评估与总结
项目交付成果评估是项目成功的重要标志，总结经验教 训有助于提升未来项目管理水平。同时，项目后评估与
项目计划的内容
里程碑计划、资源计划、进度计划、风险计划
软件项目管理概念
项目管理的定义
规划、组织、指导 和控制项目活动
项目管理的方法
项目管理的重要性
敏捷方法、瀑布模 型、迭代开发
确保项目按质、按 时、在预算内交付
●02
第5章 软件工作量估计 - 对外经济贸易大学教学辅助平台
32/59
功能点估计
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
第三节 信息系统工作量估计方法
功能点估计
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=4)，则每个成员的软件生产率 降为350行/人月；
若五个人共同开发(即n=5)，则每个成员的软件生产率 降为250行/人月；
第5章 软件项目成本估算
软件项目的实施离不开软硬件的支撑，例如操作系统、 计算机/服务器、数据库系统和开发工具等，也需要舒适的 办公环境和人性化的管理制度，因此合理规划软件开发所需 的环境资源，有利于保障项目在有限经费的支撑下高效推进。
3. 估算规模和工作量 采用WBS，确定和说明项目包含的工作(任务)，然后借 助软件生产率将其转化为工作量，为下一步估算进度和成本 提供依据。 软件生产率是指软件规模与软件工作量的比值。一般用 代码行/人月、功能点/人月来表示。
第5章 软件项目成本估算
(4) 接口包括：转入(导入)来自一个或多个别的系统？ 转出(导出)至一个或多个别的系统？有用于格式化数据的规 定的方式吗？
(5) 可靠性包括：系统必须检测并隔离故障，失败间隔 的平均时间规定为多少，对一次失败后重启系统的最大时间。
第5章 软件项目成本估算
2. 确定项目的资源需求 如何配置人力资源和环境资源对软件项目的进度和成本 估算有着非常重要的影响。 项目团队的规模和素质关系到开发方能否以最高的效率 和最小的成本完成既定任务和目标，不同水平和责任心的项 目组成员完成同一任务所需的时间和质量有着明显的差异， 所以确定项目可用的人力资源时，需要考虑软件系统的复杂 性、技术的难易度、用户对进度的要求和项目经费的支撑能 力等因素。
第5章 软件项目成本估算
估算意义 O
估算精度 项目进度
图5.2 软件项目估算的意义和精度(估算的意义随项目的进展 逐渐减弱，估算的精度则正好相反)
第5章 软件项目成本估算
因此，软件项目估算具有以下几个特点。 (1) 估算是有误差的。实践证明，大多数项目超过估算 25%到100%，但也有少数的估算准确到10%以内。 (2) 经验(历史)数据非常重要，这种估算大多是利用以 前的代价和经验作为参考而做出的。 (3) 估算可以借助估算工具和数学模型进行，旨在减少 人为误差，但不要过分迷信数学模型。 (4) 软件开发是逐步细化的过程，估算也是随项目的进 行逐步求精的过程，因此项目估算要考虑合适的时间节点。
若五个人共同开发(即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日软件项目估算是软件项目管理的核心所在，通过估算才能得出软件项目的计划，并成为软件项目控制的依据.一个成功的软件项目首先要有一个好的起点，也就是一个合理的项目计划,而一个好的项目计划，离不开一个准确、可信、客观的项目估算。
但是因为软件本身的复杂性、历史经验的可重复性、估算工具的缺乏以及一些人为错误,都会导致软件项目的估算往往和实际情况相差甚远。
软件项目估算的目的在于为软件项目制定一个预算，确定项目目标是否能够实现，从而让项目在可控的状态下达成这个目标，同时为后续的软件质量提供对比依据，从中找出项目中存在的问题和好的经验,促进企业的持续改进.对项目经理来说，合理、有效的项目估算能够让自己在工作中掌握主动权，否则在工作中只能是疲于奔命。
软件项目估算主要包括规模估算、工作量估算和成本估算.软件项目估算一般分为两种应用场景：一是招投标的时候用来估价、报价；二是用来安排进度计划和指导项目具体工作的分配。
前者是为了确定承接项目签合同进行的估算，后者是在项目确定后进一步的细化估算，往往前者的结果可能会影响项目的执行。
一个完全准确地估算基本是不可能的，这主要在于估算本身存在很多困难。
进行软件估算的困难有些是软件本身所固有的，特别是软件的复杂性和不可见性。
在估算一个软件项目时，软件项目经理需要明确以下三点：一是软件本身是非常困难的，但是估算又是必须的。
二是只有准确地估算软件的功能,才能准确地估算出软件的成本，并制定出合理的进度计划。
三是估算终究是估算,一个准确的与实际情况一模一样的估算是不可能的.软件的估算有主观和客观两种估算方法。
主观的估算方法可以通过召集项目团队成员，或者邀请各方面的专家，共同对某个项目的属性进行评估，参与评估的每个人都要单独进行估算,如果发现大家对某个项目属性估算的结果存在较大偏差，那么就需要做进一步的讨论，直到取得共识为止，对个别特殊属性进行主观估算时，一定要有直接干系人的参与.客观的估算方法是利用公司提供的各种度量数据进行估算。
- 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？ 结果？ ……