经验 以前完成项目中有用的信息 当仅存在定性的数据时进行定量测量的勇气
项目的不确定性
对项目计划中的不确定性产生重大影响的因素
复杂性 项目的规模 结构不确定性的程度 历史信息的可用程度
项目计划的目标
项目计划的目标是提供一个框架，使得管理者能 够对资源、成本及进度进行合理的估算，并随着 项目的进展不断更新 项目计划的目标是通过一个信息发现的过程实现 的
面向功能的度量
每个功能点（FP）的错误数 每个功能点（FP）的缺陷数 每个功能点（FP）的成本 每个功能点（FP）的文档页数 每个人月完成的功能点（FP）数
扩展的功能点度量
测量元素 内部数据结构 外部数据 用户输入数 用户输出数 用户查询数 变换 变迁 3D函数点指数
复杂度加权因子
低
平均
高
□ *7 + □*10 + □*15 =
在软件项目管理中，主要关心生产率和质量的度 量
过去的项目中软件开发生产率如何 生产的软件质量如何
测度、度量和指标
项目指标可使我们：
1）评估正在进行的项目的状态 2）跟踪潜在的风险 3）在问题造成不良影响之前发现问题 4）调整工作流程或任务 5）评估项目组控制软件工程工作质量的能力
过程度量和过程改进
改进过程的唯一合理的方法是测量过程的特定属性，基 于这些属性开发一组有意义的度量，进而使用这组度量 来提供引导改进战略的指标。 软件过程度量对于一个组织提高其总体的过程成熟度， 能够提供很大的帮助。但注意不要误用。
“软件度量规则”
Grady提出了一组“软件度量规则”如下：
解释度量数据时使用通用的观念，并考虑组织的感受性 对收集测量和度量的个人及小组提供定期的反馈 不要使用度量来评价个人 与开发者和小组一起设定清晰的目标及达到这些目标的度量 不要用度量威胁个人或小组 指出某个问题的度量数据不应该被看成是“否定的”含义。这
软件测量
产品的直接测量，包括产生的代码行（line of code LOC)、执行速度、内存大小及某段时间 内报告的缺陷。 产品的间接测量，包括功能、质量、复杂性、有 效性、可靠性、可维护性等。
面向规模的度量
每千行代码（KLOC）的错误数 每千行代码（KLOC）的缺陷数 每行代码（LOC）的成本 每千行代码（KLOC）的文档页数 每人月错误数 每人月代码行（LOC） 每页文档的成本
将估算拖延到项目的最后阶段。 基于已经完成的类似的项目进行估算。 使用简单的“分解技术”来进行项目成本及工作量
的估算。 使用一个或多个经验模型进行软件成本及工作量的
估算。
软件项目估算
软件项目估算的准确性取决于以下因素：
计划者是否适当地估算待建造产品规模的程度。 把规模估算转换成人的工作量、时间及成本的能力 项目计划反映软件项目组能力的程度 产品需求的稳定性及支持软件工程工作的环境
些数据仅仅是过程改进的指标。不要被某个与其他重要度量不 符合的度量迷惑。 Grady提出一种鱼骨图
项目度量
软件过程度量主要是用于战略目的。软件项目度量则是 战术性目的。
项目度量的目的是双重的。 首先，这些度量能够指导进行一些必要的调整以避免延 迟，并减少潜在问题及风险，从而使得开发时间减到最 少。 其次，项目度量可在项目进行的基础上评估产品质量， 并且可在必要时修改技术方法以改进质量。
软件的范围
软件项目计划的第一个活动是确定软件范围 软件范围包括：功能、性能、约束条件、接口及 可靠性
资源
软件计划的第二个任务是估算完成软件开发工作 所需的资源：
开发环境：硬件及软件工具 可复用构件 人员
软件项目估算
软件成本及工作量的估算永远不会是一门精确 的科学。人员、技术、环境、策略等是影响软 件最终成本及开发所需工作量的主要因素。 为了可靠地估算成本及工作量：
标准构件法要点：
软件由若干不同的“标准构件”组成 估算出每个标准构件的出现次数 使用历史数据来确定每个标准构件交付时的大小
修改法要点：
项目中包含对已有软件的使用，但该软件必须做某种 程度的修改。
项目管理内容
有效的项目管理集中于四个P上，
人员 产品 过程 项目
软件项目管理
软件项目的度量 软件项目计划 软件项目的风险管理 进度安排及跟踪 软件配置管理 项目经理的工作
软件项目的度量
测度、度量和指标
软件度量是计算机软件中范围广泛的测度。
是在一个连续的基础上改进软件过程 辅助估算、质量控制、生产率评估及项目控制
□ *5 + □* 7 + □*10 =
□ *3 + □* 4 + □* 6 =
□ *4 + □* 5 + □* 7 =
□ *7 + □* 4 + □* 6 =
□ *3 + □*10 + □*15 =
□ *n/a+ □*n/a + □*n/a=
软件项目计划
项目估算
估算是一门科学，也是一门艺术 估算软件开发工作的资源、成本及进度需要：
软件规模估算
四种估算问题规模的方法（由Putnamt Myers 92年提出)：
“模糊逻辑”法 功能点法 标准构件法 修改法
“模糊逻辑”法
要点：
计划者必须说明应用软件的类型 建立其定性的规模估算 在最初的范围内精化该估算 利用个人的经验和项目历史数据库
功能点法：
标准构件法与修改法
面向功能的度量
பைடு நூலகம்
测量参数 用户输入数 用户输出数 用户查询数 文件数 外部界面数 总计数值
计数
□
*
□
*
□
*
□
*
□
*
加权因子
简单 平均 复杂
3
4
5
=
4
5
7
=
3
4
6
=
7
10 15 =
5
7
10 =
FP=总计数值*（0.65+0.01*∑Fi) 其中Fi(i=1到14） 取值0-5
面向功能的度量
Fi:
1.系统需要可靠的备份和复原吗? 2.需要数据通信吗? 3.有分布处理功能吗? 4.性能很关键吗? 5.系统是否在一个已有的、很实用的操作环境中运行? 6.系统需要联机数据项吗? 7.联机数据项是否需要在多屏幕或多操作之间切换以完成输入? 8.需要联机更新主文件吗? 9.输入、输入、文件或查询很复杂吗？ 10.内部处理复杂吗? 11.代码需要被设计成可复用的吗? 12.设计中需要包括转换及安装吗? 13.系统的设计支持不同组织的多次安装吗? 14.应用的设计方便用户修改和使用吗?