估计重要性：是“软件项目在满足质量要求的条件下，按时和在预算内交付”的前提
估计的复杂性
- 原因
- 软件的复杂性和不可见性
- 其他因素
- 估计的主观特性
- 不同角色的人有不同估计偏好
- 技术的变更
- 项目经验缺乏一致性
错误估算的危害
- 过高估计危害
- Parkinson法则
- 给的时间越多，工作花费的时间也越多
- Brook法则
- 当人数增加后，项目所需的时间不成比例地减少，当团队规模变大后，由于管理、协调和通信的增加，导致总工作量增加
- Parkinson法则
- 过低估计危害
- 质量降低
- Weinberg可靠性零法则
- 如果系统不要求可靠，那它可满足任何目标
工作量估算的影响
- 对职员影响
- 如果能够完成目标，他们将受到鼓舞
- 如果根本不能完成目标，他们的激情将受到极大损害
- 对企业影响
- 成本
- 收益
- 对软件项目影响
- 质量
- 进度
应用场景
- 项目经理评估各软件工程师的生产率
- 根据客户需求和公司现有资源来估计项目的工作量和成本
目标问题
- 如何为某个项目分配合理的人力、时间和相关资源
- 要完成该项目需要多少工作量（人力）？
- 要完成一个项目或任务需要多长有效时间？
- 项目或任务的总成本是多少？
含义
- 一种量化衡量方法,使得人们可以理解和把握软件项目的(生产)效率(或者所需要的劳动量)
目的
- 描述（项目和过程）
- 评估（状态和质量）
- 预测（为计划）
- 改进（产品质量和过程性能）
软件生产率测量
- 直接测量：如在一个特定时间内产生的代码行数
- 一定时间产生的代码行数（LOC）
- 执行速度
- 文件页数
- 错误和缺陷数
- 间接测量 ：如一个给定时间内生产出的功能点和目标点
- 功能性
- 可靠性
- 可维护性
- 复杂性
- 效率
- 其它质量指标
面向规模的度量标准
- 每KLOC（千行代码）的错误数，即总错误数除以总KLOC
- 每KLOC（千行代码）的缺陷数，即总缺陷数除以总KLOC
- 每KLOC（千行代码）的文档页数，即总文档页数除以总KLOC
优点
- LOC、KLOC和相关度量容易计算
- 许多现有的软件估算模型都使用LOC和KLOC作为一项重要输入
- 有大量的关于LOC的文献和数据
缺点
- LOC依赖于使用的语言，这对短小精悍的程序不利
- 不太适用于非过程化语言
- LOC是由在设计完成时候才能计算，估算需要一定程度的细节，而这些细节可能很难获得，例如，项目计划人员难于在分析和设计完成之前估算LOC
功能点数从直接度量软件信息域和评估软件复杂性的经验量化关系中获得
五个信息域值（功能点）
- 用户输入的数量
- 用户输出的数量
- 用户查询的数目
- 文件数量
- 外部接口的数量
计算功能点（FP ） $$ FP=(total_counts)\times(0.65+0.01\times\sum{F_i}) $$ 功能点计算
- 每FP的错误数：总的错误数除以总的FP数
- 每FP的缺陷数：总的缺陷数除以总的FP数
- 每FP的文档页数：总的文档页数除以总的FP数
- 每人月的FP数：总的FP数除以总的人月数
基于LOC度量和基于FP度量的关系
代码行数和功能点之间的关系依赖于编程语言
算法成本模型—基于经验的度量
- 基于案例的推理
- 专家判断
- 适合于有相关类似项目的情况
- 注意事项：参考历史数据时需考虑不同的环境，如编程语言、软件工具、标准和人员经验
通过任务分解度量项目工作量
- 自顶向下方法
- 适合于全新的项目
通过目前可用的资源估算项目工作量
- 特点
- 方法简单
- 只考虑项目现有的可用资源（时间和人力）而忽略了其它因素
- 实例
- 一个项目需要12个月和5个人（其他人忙于别的项目），则项目总的工作量是60人月
- 避免无准备的估算：不要随口说出一个估算
- 留足估算时间，做好计划
- 开发人员参与估算
- 不要忽略日常普通任务
- 使用多种估算技术，并比较他们的结果
- 集体讨论估算结果
计划被开发人员抛弃，开发人员盲目开发
试图在关键阶段节省时间，结果在后续阶段加倍补偿
分散了管理者的注意力：需要不断调整计划
客户关系恶化：项目一拖再拖，客户失去耐心
仓促收尾，质量低下
- 开发人员知道系统存在的问题但未修改
- 开发文档缺乏
- 开发文档与实际项目不一致
超负荷的进度压力
- 降低开发质量
- 赌博心理导致风险管理的忽略
- 激励效应不再起作用
- 精疲力竭：后续项目没有热情
- 中途退出：通常为有能力的人
- 开发人员与管理人员关系恶化
- 不切实际的进度压力使开发人员失去了对管理人员的尊重
解决进度矛盾：有原则的谈判
- 探求双赢的解决方案
- 从困境中解脱
- 站在他人立场上加以考虑（各人有各人的难处）
- 以合作的态度改善与管理人员和客户的关系
- 不要针锋相对
- 关注共同利益，不要过分强调立场
- 有时需要让步
- 说服理由：提高开发速度、增加成功机会、引用以前类似项目失败教训
提出多种备选方案
- 与产品相关的灵活变通
- 有些功能放在下一版本实现
- 分阶段交互产品
- 去掉一些费时的功能特性
- 有些特性不必精雕细琢
- 采用其他现有商业组件实现
- 与进度计划相关的灵活变通
- 提进度目标，但不设确切期限
- 探讨缩短开发时间的方法
- 先给出大概范围，后续再逐步精确
- 与项目资源相关的灵活变通
- 初期要求增加更多开发人员、领域专家、测试人员
- 提高开发支持力度，更快的计算机或更好的开发环境
- 提高用户参与度，最好有能最终拍板的用户
- 提高主管人员的参与度
- 其他
- 额外支持：供餐、洗衣、清洁等
- 激励措施：休假旅游、加班工资等