4. 功能列表法
5. 其他
检验分解结果的标准：
1. 最底层的要素是否是实现目标的充分必要条件 2. 最底层要素是否有重复的
3. 每个要素是否清晰完整定义
4. 最底层要素是否有定义清晰的责任人,是否可以进行成本估算和进度安排
WBS意义：
? 提供了项目范围基线,是范围变更的重要输入 ? 为评估和分配任务提供具体的工作包 ? 进行估算和编制项目进度的基础
? 对整个项目成功的集成和控制起到非常重要的作用 WBS步骤：
1. 确认并分解项目的组成要素 2. 确定分解标准
3. 确定分解是否详细 4. 确定项目交付成果
5. 验证分解的正确性(建立编号)
成本管理过程：
? 资源计划编制:
? 确定项目需要的资源种类和数量
? 成本估算：中心环节
? 编制一个为完成项目各活动所需要的资源成本的近似估算
? 成本预算：项目进度
? 将总成本估算分配到各单项工作活动上
? 成本控制：项目跟踪
? 控制项目预算的变更 成本估算定义：
? 对完成项目所需费用的估计和计划
? 包括预测开发一个软件系统所需要的总工作量的过程。 ? 是一种量化的结果 ? 可以有一些误差
? 成本估算不同于项目定价
贯穿于软件的生存周期
直接成本
? 与具体项目相关的成本
? 包括开发成本、管理成本等。
比如：人员的工资、材料费、外包外购成本等 间接成本：
? 不能具体到某个项目中的成本，
? 可以分摊到各个具体项目中的成本，例如：
? 培训 ? ? ? ?
房租水电 员工福利 市场费用 管理费
? 其他等等
估算的基本方法：
1. 代码行、功能点、对象点 2. 类比 (自顶向下)估算法 3. 自下而上估算法 4. 参数法估算法 5. 专家估算法
代码行：
? 从软件程序量的角度定义项目规模。
? 要求功能分解足够详细的
? 有一定的经验数据（类比和经验方法）
? 与具体的编程语言有关
? 对代码行没有公认的可接受的标准定义，
? 代码行数量依赖于所用的编程语言和个人的编程风格。
? 在项目早期，需求不稳定，设计不成熟，实现不确定的情况下很难准确的估算代码
量。 功能点：
? 用系统的功能数量来测量其规模
? 与实现产品所使用的语言和技术没有关系的 ? 两个评估
? 内部基本功能 ? 外部基本功能
? 加权和量化
? 公式：FP =UFC*TCF ? UFC：未调整功能点计数 ? TCF：技术复杂度因子 对象点：
? 对象点是基于对象的软件产品规模估算。 ? 著名的Probe方法---Watts Humphrey
n 采用这种方法估算产品规模，需要企业开发一个历史数据库，存储实现各种类型和
复杂性的对象和方法所需要的代码行数。 Probe算法的具体步骤：
1. 基于产品需求构建体系结构和概要设计
2. 对设计中的每个类（面向对象方法中的Class）的输入和交互，标识所设计的对象属于表中哪类方法并估算其复杂性
3. 将上述标识的结果构造成一个如表形式的矩阵，然后将这个矩阵中的值与表中对应的值相乘
4. 将上述所有相乘结果相加求和，产生估算结果 类比（自顶向下的方法）定义：
? 从项目的整体出发，进行类推，即估算人员根据以往的完成类似项目所消耗的总成
本（或工作量），来推算将要开发的软件的总成本（或工作量），然后按比例将它分配到各个开发任务单元中。使用场景：
? 有类似的历史项目数据
? 信息不足（要求不是非常精确)的时候
? 在合同期和市场招标时 ? 在高层对任务的总的评估
特点：
? 简单易行,花费少 ? 具有一定的局限性
? 不能适用于早期规模等数据都不确定的情况
? 应用一般集中于已有经验的狭窄领域，不能垮领域应用。
? 难以适应新的项目中约束条件、技术、人员等发生重大变化的情况。
? 准确性差,可能导致项目出现困难
自下而上的方法：
? 利用任务分解结构图,对各个具体工作包进行详细的成本估算,然后将结果累加起来
得出项目总成本。 n 准确度较好
n 在进入项目开始以后，WBS以后的开发阶段
n 需要进行准确估算的时候
n 这种方法准确。它的准确度来源于每个任务的估算情况 n 非常费时,估算本身也需要成本支持 n 可能发生虚报现象 估算方法总结：
? 初期
? 类比
? 专家估算
? 计划阶段
? 自下而上 ? 参数模型
? 实施阶段（包括变更发生）
? 自下而上 ? 参数模型
成本估算方法综述：
? 主要考虑三种模型:类比法,自下而上法,参数法. ? 自下而上法费时费力,参数法比较简单 ? 自下向上法与参数法的估计精度相似
? 各种方法不是孤立的,应该注意相互的结合使用 ? 类比法通常用来验证参数法和自下而上法的结果 实用软件估算模型：
是一种自下而上和参数法的结合模型,步骤如下:
1. 对任务进行分解
2. 估算每个任务的成本Ei
3. 直接成本=E1+E2+……+ Ei+……+ En
4. 项目总估算成本= 直接成本+间接成本 5. 项目总报价=项目总估算成本+风险利润
1. 风险利润=利润+风险基金+税
估算不准的原因：
? 基础数据不足
? 企业有足够的以往项目的经验数据作为估算的基础
? 缺乏经验的估算人员
? 过分乐观、考虑不周、方法不一致等
? 签约前后不连贯
? 签约前，销售人员夸大承诺，削减价格 ? 签约后，项目经理无法成功
? 低劣的推测技术
? 估算对需求的敏感性
? 必须对项目的需求理解到很深的程度。 避免低劣估算：
1. 避免无准备的估算
2. 留出估算的时间，并做好计划 3. 使用以前的项目数据
4. 使用以开发人员为基础的估算 5. 分类法估算
6. 详细的较低层次上的估算
7. 使用软件估算工具
8. 使用几种不同估算技术，并比较它们的结果 处理低劣估算带来的后果：
? 通过数据说明资源不足,争取更多资源
? 强化变更管理程序 ? 确定目标的优先次序
质量成本（CoQ）
? 质量成本是由于产品的第一次工作不正常而衍生的附加花费，包括两部分
? 预防成本：为确保质量成本而进行预防工作所耗费的费用。
? 缺陷成本：为确保项目质量而修复缺陷工作所耗费的费用。
预防成本
n 评估费用
l 使项目符合要求检测缺陷所衍生的成本
l
质量审计、测试等等
n 预防费用
l 使项目符合所提要求预防失败所衍生的成本 l
缺陷成本：
用户满意确定、改进等。
n 内部费用
l 是对不能符合所提要求，尚未发行的软件（返工）所衍生的费用 l 缺陷标记、返工、重新测试等
