8.1 软件项目管理概念

8.1.1 软件项目管理的定义

• 计划、协调、度量、监控、控制及报告等管理方法在软件开发和维护中的具体应用，以保证整个过程是系统的、有原则的、可量化的(IEEE610.12-90)。

• 软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员（People）、产品（Product）、过程（Process）和项目(Project)（也就是4P要素）进行分析和管理的活动

8.1.2 软件项目管理的4P要素

• 人员：招聘、选拔、绩效管理、培训、薪酬、职业发展、组织和工作设计、团队/文化的发展
• 客户：阐述需求的人
• 项目管理者：计划、组织、控制项目开发人员的人
• 开发人员：具有开发产品以及应用软件所需技能的人
• 最终用户：最终使用软件或者与软件进行交互的人
• 高级管理者：定义业务问题的人
• 团队，下面给出团队的组织方式
• 封闭式：按照权利层次来组织团队
• 做过去类似项目有优势；难以承担创新型项目
• 随机式：松散、专家组合型团队
• 有创新优势难以承担有次序执行的项目
• 开放式：封闭式+随机式
• 适合解决有次序又有创新的复杂项目效率可能不是太高
• 同步式：根据项目分解进行分工
• 适合松散耦合子系统项目项目；集成可能会遇到问题

• 产品：策划一个项目以前，应当建立产品的目标和范围，考虑可选的解决方案
• 确定软件范围
• 系统环境（产品是搭在什么环境上的）
• 系统大环境/业务环境
• 环境有哪些约束
• 信息目标（产品在信息方面需要做到什么）
• 需要输出哪些用户可见对象
• 需要以哪些数据作为输入
• 功能性能（产品需要有哪些功能和性能）
• 如何把输入变为输出（功能）
• 需要考虑哪些特殊性能（性能）
• 功能分解（对产品的功能进行分解，而不是通过过程来分解。这里就应该是划分子系统而不是划分阶段）

• 过程：软件过程提供一个框架，在此框架下可以制定项目开发的综合计划（实际上就是第二章里面说的那个软件过程模型中的过程）
• 根据项目特征选择合适的过程模型
• 根据过程模型对项目进行分解（这个时候就是分解为可行性分析、需求分析等）

• 项目：理解成功项目管理的关键因素，掌握项目计划、监控和控制的一般方法
• 采用确保软件团队能够成功的方式来组织项目
• 项目处于危险的信号
• 不了解客户需求
• 产品范围定义不清楚
• 变更管理不好
• 最后期限不切实际
• 客户抵制

8.2 软件度量概念

8.2.1 软件度量的目的

• 软件项目的成熟化也需要度量和数字化，目的是为了持续改进软件过程，并用于项目估算，质量控制以及生产率评估

8.2.2 软件度量的内容

• 软件度量的内容：行业和组织的历史数据（根据历史数据才能知道一些元素之间的关系）是进行软件项目度量的基础
• 生产率度量
• 项目工作量
• 项目周期
• 项目成本等
• 质量度量
• 软件发布前发现的缺陷数
• 软件发布后用户反馈的缺陷数
• 软件运行速度等

8.2.3 软件度量的方法

• 面向规模的度量（重点）

• 面向功能点的度量（重点）

• 面向对象的度量

• 面向用例的度量

8.3 面向规模的度量

8.3.1 面向规模度量的相关概念

• 面向规模的度量：是通过对质量和生产率的测量进行规范化得到的，这些测量是根据之前开发的软件的规模得到的

• 千行代码（ KLOC ）： 这些代码指的是源代码，通过源代码的行数来直观度量一个软件程序有多大规模

• 生产率（PM）：：PM = L / E（单位：千行/人月）， L表示代码总量（单位：KLOC），E表示软件工作量（单位：人月）。表示的是每人每月能写多少行代码

• 每千行代码的平均成本（ CKL ）：CKL = S / L（单位：万元/千行） ，S为软件项目总开销，单位一般是万元；L表示代码总量（单位：千行）

• 代码出错率（EQRl）：EQRL = Ne / L（单位：行/千行） ，Ne表示代码出错的行数，L表示代码总量

• 文档与代码比（Dl）：Dl = Pd / L（单位：页/千行），Pd表示文档页数， L表示代码总量(单位：KLOC)

8.3.2 面向规模的度量的优点

• 简单易行，自然直观

8.3.3 面向规模的度量的缺点

• 依赖于程序设计语言的表达能力以及功能

• 项目初期难以估算最终软件的代码行数

• 对精巧的软件项目不适用

8.4 面向功能点的度量

8.4.1 面向功能度量的概念

• 用软件的功能表示软件的规模

• 应用最广泛的是功能点（Function Point, FP）法

• 项目开发初期就可估算出（对比面向规模的度量。面向规模的度量在项目初期很难估算软件的代码函数）

• 功能点计算目前主要基于经验公式

8.4.2 功能点法计算公式

• 功能点计算公式如下：FP = UFC×TCF = UFC × (0.65 + 0.01×ΣFi)

• 其中：
• UFC (Unadjusted Function Component) : 未调整功能点计数, 5个信息量的“加权和”
• TCF (Technical Complexity Factor): 技术复杂度因子
• Fi: 14个因素的“复杂性调节值” (i =1..14)
• 0.65, 0.01都是经验常数，现在由国际组织根据大量项目跟踪分析获得。（就是使用了统计学方法）

8.4.3 UFC相关五类组件

• 内部逻辑文件（ILF, Internal Logical Files ）
• 一个用户可识别的逻辑相关的数据组，它在应用程序边界内，由用户输入来维护
• 它可能是某个大型数据库的一部分或是一个独立的文件

• 外部接口文件（EIF, External Interface Files）
• 一个用户可识别的逻辑相关的数据组，但只能被引用，且数据完全存于软件外部，由另一个应用程序进行维护
• 是机器可读的全部接口（如磁盘或磁带上的数据文件）
• 是另一个应用程序的内部逻辑文件

• 外部输入（EI, External Input）
• 来自于软件外部的数据输入
• 控制信息(比如开关软件，不更新ILF) / 业务逻辑信息（比如使用软件的具体功能，更新ILF）
• 可来自于一个数据输入屏幕或其他应用程序。

• 外部输出（EO, External Output）
• 经过处理的数据，由程序内部输出到外部
• 从ILF、EIF中取出数据经过一定的组合、计算后得出的输出数据, 如生成报表, 派生数据（所以表格是一个外部输出）, 可能更新ILF

• 用户查询（EQ, External Query）
• 一个输入输出的组合过程，从一个或多个ILF、EIF中取出数据输出到程序外部
• 输入过程不更新ILF，输出过程不进行任何数据处理

8.4.4 复杂性调节因素

• 14个复杂性调节因素Fi（了解一下即可，没必要背下来。如果某一条很重要，那么该条的值就是5）
1. 系统需要可靠的备份和复原吗？
2. 系统需要数据通信吗？
3. 系统有分布处理功能吗？
4. 性能很关键吗？
5. 系统是否运行在既存的、高度实用化的操作系统环境中？
6. 系统需要联机数据项吗？
7. 联机数据项是否在多屏幕或多操作之间进行切换？
8. 需要联机更新主文件吗？
9. 输入、输出、查询和文件很复杂吗？（针对EI、EO、EQ）
10. 内部处理复杂吗？（针对ILF）
11. 代码需要被设计成可重用吗？
12. 设计中需要包括转换和安装吗？
13. 系统的设计支持不同组织的多次安装吗？
14. 应用的设计方便用户修改和使用吗？

• 复杂性调节因素值Fi
• 0-没有影响
• 1-偶有影响
• 2-轻微影响
• 3-平均影响
• 4-较大影响
• 5-严重影响

8.4.5 面向功能的度量优缺点

• 面向功能度量的优点
• 与程序设计语言无关, 在开发前就可以估算出软件项目的规模（因为计算的是功能点数，这个只跟软件项目本身有关；后期可以根据使用的程序设计语言来转换成代码量）

• 面向功能度量的缺点
• 没有直接涉及算法的复杂度（这里只考虑了项目本身的复杂度，并没有考虑代码实现的复杂度），不适合算法比较复杂的软件系统
• 功能点计算主要靠经验公式，主观因素比较多

8.4. 软件项目估算

8.4.1 软件项目估算概念

• 软件项目估算的概念：项目启动之前，软件团队应该估算将要做的工作、所需要的资源、成本、从开始到完成的时间，也即是对这些内容进行预测

• 策略
• 项目度量方法为项目估算提供了依据与有效输入
• 尽量把估算推迟到项目的后期进行
• 根据已经完成的项目进行估算

• 软件项目估算的方法
• 基于问题分解的估算（基于分解技术的项目估算方法）
• 基于LOC（代码行数）
• 基于功能点FP
• 基于过程分解的估算（基于分解技术的项目估算方法）
• 基于回归分析的经验估算模型（基于经验的项目估算方法）
• 基于LOC
• 基于功能点FP
• COCOMO模型

8.4.2 基于问题分解的项目估算

• 估算期望值：估计期望值=(最大值＋4×最可能值＋最小值) / 6

• 估算期望值计算示例如下：

• 基于LOC的估算：估算出各个子系统的代码行（注意是跟软件项目度量有区别的。软件项目度量是度量整个软件项目的一些特性，而基于问题分解的项目估算就是把项目的问题进行分解，然后根据软件度量提供的数据，来对每一个问题，或者说子系统进行估算。说白了就是，软件项目估算是软件度量的细化）

• 下面就软件度量和软件项目估算举一个例子：



这里合计就需要参考软件度量产生的数据，而子系统的代码行就是通过基于问题分解的估算中的基于LOC的估算得到的
基于LOC的项目估算示例如下（注意要使用三点期望法）：



接下来就可以根据代码行来计算其他的信息，如工作量以及成本等，如下图：

• 基于功能点估算
• 首先需要计算UFC的值，如下图（同样注意，由于未调整功能点是不确定的，所以需要使用三点期望法。计算出估计期望之后再使用功能点计算的公式，也就是加权平均，进行UFC的计算）：
• 其次需要计算复杂度调节值，如下图（由于影响程度是客观的，确定的，所以不需要进行三点期望了）：
• 运用面向功能点度量中功能点的计算公式来进行项目总功能点的估算

8.4.3 基于过程分解的项目估算

8.4.4 基于经验的项目估算

基于回归分析的经验估算模型

• 基于回归分析的经验估算模型：通过对以往软件项目中搜集的数据进行回归分析而导出

• 基于回归分析的经验估算模型：E=A+B×(ev ) C（注意C是次方）
• 其中A、B、C是经验常数，E是工作量（人月），ev是估算变量（LOC或功能点）。所以经验估算模型就是通过某一些估算变量来计算软件项目的总工作量
• 基于LOC（也就是估算变量采用LOC）的经验估算模型（根本不用背，了解一下即可）：
• E=5.2×(KLOC)0.91——Walston-Felix模型
• E=5.5+0.73×(KLOC)1.16——Bailey-Basili模型
• E=3.2×(KLOC)1.05——Boehm简单模型
• E=5.288×(KLOC)1.047——Doty模型，用于KLOC>9的情况
• 基于功能点（也就是估算变量采用功能点）的经验估算模型（同样不用背，了解一下即可）：
• E=-91.4+0.355FP——Albrecht和Gaffney模型
• E=-37+0.96FP——Kemerer模型
• E=-12.88+0.405FP——小型项目回归模型

基本COCOMO模型公式及计算方法

• COCOMO模型概述
• COCOMO是指COnstructive COst MOdel，构造性成本模型，Boehm于1981年提出，用于对软件开发项目的规模、成本、进度等方面进行估算
• COCOMO模型是一个综合经验模型，模型中的参数取值来自于经验值，并且综合了诸多的因素、比较全面的估算模型
• 在欧盟国家应用较为广泛

• COCOMO模型层次（COCOMO模型区分不同层次是为了支持不同阶段的估算。还记得软件项目估算的策略不，尽量将软件项目估算放到项目的后期，这样软件项目估算就有可能贯穿很多个阶段，所以COCOMO模型为了做适配，就分了层次）
• 基本COCOMO模型：系统开发的初期，估算整个系统的工作量(包括维护)和软件开发和维护所需的时间（这个就有点像前面的软件度量了。这并不矛盾，虽然说是估算模型，但是也是基于经验，也就是组织行业内的历史数据，所以是能在初期进行的）
• 中间COCOMO模型：估算各个子系统的工作量和开发时间
• 详细COCOMO模型：估算独立的软构件，如各个子系统的各个模块的工作量和开发时间
• 所以实际上COCOMO模型的层次就是一步步将软件产品进行功能上的细化了

• 基本COCOMO模型（这个公式就要背一下了捏）
• E = a*(KLOC)^b ; E是工作量(人月) ，a和b是经验常数（现根据经验计算工作量）
• D = c*E^d ;D是开发时间(月) ，c和d是经验常数（再根据工作量计算开发时间）
• 其中，a,b,c,d为经验常数，其取值见下表（这个取值不用管）

中间COCOMO模型公式及计算方法

• 中间COCOMO模型（这个公式也要背一下捏）
• E = a(KLOC)^b\EAF（这里计算出来的应该就是子系统的工作量了捏。下面的表一样不用记）
• 其中，E表示工作量(人月)，EAF表示工作量调节因子（前面的Fi叫复杂度调节值），a,b为经验常数，其取值见下表

• EAF的取值，下面列出EAF的15个影响因素
• 软件产品属性(3个)
• 软件可靠性
• 软件复杂性
• 数据库的规模
• 计算机属性(4个)
• 程序执行时间
• 程序占用内存大小
• 软件开发环境的变化
• 软件开发环境的响应速度
• 人员属性(5个)
• 分析员能力
• 程序员能力
• 领域经验
• 开发环境的经验
• 程序设计语言的经验
• 项目属性(3个)
• 软件开发方法的能力
• 软件工具的数量和质量
• 软件开发的进度要求
• EAF的取值以及计算(范围)
• 很低、低、正常、高、很高、极高
• Boehm建议取值范围[0.70-1.66]
• EAF的计算＝πFi ( i=1..15)（注意：前面计算功能点的时候只有14个复杂度调节值并且是求和；这里是有15个并且是累乘）
• 调节因子及其取值由统计结果和经验决定，不同的软件开发组织在不同的时期可能会有不同的取值（就说明这个EAF的影响因素以及其取值是不用背的了，因为不是固定的）

• COCOMO模型例题（实际上就是库库背公式罢了）：

8.4.5 软件项目估算与软件度量的异同

• 相同点
• 软件项目估算和软件度量的输出是相似的，如软件项目的规模等
• 软件项目估算和软件度量的方法是相似的，比如基于功能点的问题分解的度量方法就都是使用功能点的计算公式

• 不同点
• 执行时间：软件项目度量是在项目初期进行的，而软件项目估算是需要尽量在软件项目后期进行的
• 测量结果：软件项目度量计算出来的值是不准确的，而软件项目估算计算出来的值是比较准确的
• 具体方法：软件项目度量不需要进行三点期望法估计，而软件项目估算需要
• 估算或度量的依据：软件项目度量只能依据组织的历史数据，对当前软件项目的针对性差；而软件项目估算是以软件项目度量的结果为依据，并且根据已完成的部分项目进行估算，对当前软件项目的针对性强
• 本质：软件度量本质是将软件项目进行数字化（可能就是定义一些单位什么的），而软件项目估算就是针对具体的软件项目进行估算了

8.5 项目进度计划

8.5.1 项目进度计划概念

• 项目进度计划概念：对项目进行任务划分，定义任务之间的依赖关系，并进行时间估算和资源分配，确保以最佳的时间与成本输出满足质量要求的产品。所以编制项目计划本质是一个优化问题
• 项目进度与成本之间是一个非线性关系
• 最低成本的交付时间应该为正常交付时间的两倍左右

• 项目进度计划的价值
• 有序、可控制地对软件项目进行管理
• 确保员工保持高生产率
• 及时交付软件产品
• 降低软件开发成本
• 提高客户满意度
• 及时发布产品新版本

8.5.2 甘特图

• 甘特图的作用
• 显示基本的任务信息
• 定义并查看任务的工期、开始时间和结束时间
• 定义并查看任务所分配的资源的信息
• 可定义任务间的前后关系

• 甘特图的示例如下：

8.5.3 里程碑

• 里程碑显示项目进展中的重大工作完成

• 里程碑与活动的区别（活动主要是指一个宽泛的目标，是需要花费资源去实现的）
• 活动是需要消耗资源的
• 里程碑仅仅表示事件的标记

8.6 WBS分解与任务网络图

8.6.1 项目进度计划编制过程

• 编制项目计划的步骤
• 定义项目任务（在这一步需要使用到项目分解结构，也就是WBS）
• 估算任务所需要的时间与成本
• 定义任务间时序关系，形成任务网络
• 为项目任务分配资源（人员、设备等）（这里因为已经给任务分配资源了，所以是可以通过甘特图来表示的）
• 关键路径评估与监控

8.6.2 WBS分解

• WBS分解的两种模式（实际上就是分解技术的适用）
• 基于功能的分解（就是把系统分解成了子系统，然后再将子系统分解为一个个功能）
• 如下图：
• 基于过程的分解（实际上就是直接按照软件开发过程，或者说软件的生命周期来进行分解）
• 如下图：

• WBS构建应该注意的原则
1. 一个任务只应该在WBS中的一个地方出现（分解不重复）
2. WBS中某项任务的内容是其下所有WBS项的总和（需要是一种任务的分解，不能遗漏也不能变多）
3. 一个WBS项只能由一个人责任，其他人只能是参与者
4. WBS必须与实际工作中的执行方式一致（如果做基于功能分解实际开发过程中就要面向对象；做基于过程分解就需要面向过程）
5. 应让项目团队成员积极参与创建WBS，以确保WBS的一致性（生成一个大家都认同的WBS）
6. 每个WBS项都必须文档化，以确保准确理解已包括和未包括的工作范围
7. WBS可以根据需求进行必要变更维护

8.6.3 任务网络图

• 任务网络图的定义：任务网络图是项目所有任务（活动）及其之间逻辑关系（依赖关系）的一个图解表示，并从左到右来表示项目的时间顺序。（任务网络图是在编制项目进度计划的第三步进行的，而第三步就是确定任务之间的先后关系或者说依赖关系）

• 任务网络图的作用
• 可以分解任务（任务网络图中的分叉就表示任务的分解）以及各项任务所需要耗费的时间及成本
• 可以显式的描绘各个任务间的时序依赖关系

• 任务网络图的构成
• 任务网络图是一个有向权重网络图，一般用节点表示事件，弧表示任务（活动） ，弧上的权值表示任务（活动）耗费的时间，如下图（这个图的WBS显然就是基于过程的分解了）：



在每一个弧上都标上了时间，这样就可以计算关键路径了

8.7 关键路径

8.7.1 概念

• 在任务网络图中，从项目开始到项目完成有许多条路径，路径上所有弧权重之和最大的路径（路径最长）叫关键路径

• 示例如下：

8.7.2 意义

• 关键路径上任何任务（活动）的延长都会导致整个项目周期的延长

• 如果想缩短项目周期，就必须缩短关键路径的长度

• 项目经理应该随时关注关键路径上任务（活动）的完成情况以及关键路径是否发生了变化

• 对WBS中任务的串行与并行安排方式有指导意义（指导了任务的执行顺序）

8.7.3 可用资源对关键路径的影响