1、软件项目管理概念

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

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

1.1 软件项目管理内容

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

人员

1. 客户：阐明软件需求的人员。
2. 项目管理者：计划、激励、组织和控制软件开发人员。
3. 高级管理者：负责定义业务问题。
4. 开发人员：拥有开发产品或应用程序所需技能的人员。
5. 最终用户：直接使用或者与软件产品交互的人。

• 团队类型
  1. 封闭式：按照权利层次来组织团队，做过去类似项目有优势，难以承担创新性项目。
  2. 随机式：松散。专家组合型团队。有创新优势，难以承担有次序执行的项目。
  3. 开放式：封闭式+随机式。适合解决有次序又有创新的复杂项目，效率可能不是太高。
  4. 同步式：根据项目分解进行分工，适合松散耦合子系统项目，项目集成可能会遇到问题。

产品

过程

项目

2、软件项目度量

2.1 软件项目度量定义及度量方法

当你能够度量你所说的事物，并能用数字表达它时，你就对它有了一定了解;反之，如果不能测量他，也不能用数字表达，就说明你对它的了解还不深入，不能令人满意。

软件项目管理的成熟化也需要度量与数字化，目的是持续改进软件过程，并用于项目估算、质量控制、生产率评估等。

• 软件项目度量内容

  1. 生产率度量：项目工作量、项目周期、项目成本
  2. 质量度量：产品发布之前发现的缺陷数；产品发布后用户报告的缺陷数；产品的运行速度
     行业及组织的历史数据是软件项目度量的基础。

• 软件项目度量的方法：面对规模的度量；面向功能点的度量；面向对象的度量；面向用例的度量

2.2 面对规模的度量

通过对质量和(或)生产率的测量进行规范化而得到的，这些测量是根据开发过的软件的规模得到的。

1. 干行代码(KLOC):这些代码指的是源代码，通过源代码的行数来直观度量一个软件程序有多大规模。
2. 生产率(PM):PM=L/E,L表示代码总量(单位:KLOC)，E表示软件工作量(单位:人月)
3. 每干行代码的平均成本(CKL):CKL=S/L，S为软件项目总开销，L表示代码总量(单位:KLOC)
4. 代码出错率(EQRI):EQRI=Ne/L，Ne表示代码出错的行数，L表示代码总量(单位:KLOC)
5. 文档与代码比(DI):DI=Pd/L，Pd表示文档页数，L表示代码总量(单位:KLOC)

• 优点：简单易行，自然直观
• 缺点：依赖于程序设计语言的表达能力和功能；软件开发初期很难估算出最终软件的代码行数；对精巧的软件项目不合适。

2.3 面对功能的度量

用软件的功能表示软件规模，应用最广泛的是功能点（Function Pointment，FP）法。
项目开发初期就可估算出。功能点计算目前主要基于经验公式。

UFC相关的五类组件

1. ·内部逻辑文件(ILF,Internal Logical Files )
   • 一个用户可识别的逻辑相关的数据组，它在应用程序边界内，由用户输入来维护。
   • 它可能是某个大型数据库的一部分或是一个独立的文件。
2. 外部接口文件(EIF,External Interface Files)
   • ·一个用户可识别的逻辑相关的数据组但只能被引用，且数据完全存于软件外部，由另一个应用程序进行维护
   • 是机器可读的全部接口(如磁盘或磁带上的数据文件)
   • 是另一个应用程序的内部逻辑文件
3. 外部输入(El,ExternalInput)
   • 来自于软件外部的数据输入
   • 控制信息(不更新ILF)/业务逻辑信息(更新ILF)
   • 可来自于一个数据输入屏幕或其他应用程序。
4. 外部输出(EO,External Output)
   • 经过处理的数据，由程序内部输出到外部
   • 从ILF、EIF中取出数据经过一定的组合、计算后得出的输出数据,如生成报表,派生数据,可能更新ILF
5. 用户查询(EQ.External Query)
   • 一个输入输出的组合过程，从一个或多个ILF、EIF中取出数据输出到程序外部
   • 输入过程不更新ILF，输出过程不进行任何数据处理

• UFC计算
  
  

14个复杂性调节因素$F_i$

• 优点:与程序设计语言无关,在开发前就可以估算出软件项目的规模
• 不足:没有直接涉及算法的复杂度，不适合算法比较复杂的软件系统；功能点计算主要靠经验公式，主观因素比较多。

一个功能点开发代码行数

2.4 软件估算

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

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

• 项目估算方法
  1. 基于分解技术的项目估算方法：基于问题分解的估算（基于LOC、基于功能点FP）；基于过程分解的估算
  2. 基于经验的项目估算方法：基于回归分析的经验估算模型（基于LOC、基于功能点FP）；COCOMO模型

三点期望值法

在基于问题的分解估算方法中，通过估计最大值，最小值，最可能值的加权平均值作为期望值来估算。
$$估计期望值=(最大值+4\times 最可能值+最小值)/6$$

例如:如果估计系统X规模的最大值为100KLOC，最小值为50KLOC，最可能值为60KLOC，则其估计期望规模为$$(100+4x60+50)/6=65KLOC$$

案例分析

• 基于LOC的估算
  
• 基于功能点的估算
  
  
  

基于过程分解的估算

基于经验的软件估算

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

COCOMO经验估算模型

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

• COCOMO模型的层次：支持不同的阶段

  1. 基本COCOMO摸型：系统开发的初期，估算整个系统的工作量(包括维护)和软件开发和维护所需的时间
     
     

  2. 中间COCOMO模型：估算各个子系统的工作量和开发时间
     

     • EAF的取值(考虑15个因素)：
       1. 软件产品属性(3):软件可靠性，软件复杂性，数据库的规模
       2. 计算机属性(4):程序执行时间，程序占用内存大小，软件开发环境的变化，软件开发环境的响应速度
       3. 人员属性(5):分析员能力，程序员能力，领域经验，开发环境的经验，程序设计语言的经验
       4. 项目属性(3):软件开发方法的能力，软件工具的数量和质量，软件开发的进度要求
     • EAF的取值(范围)：很低、低、正常、高、很高、极高；Boehm建议取值范围[0.70-1.66]；·EAF的计算=ПF:(i=1…15)
     • 调节因子及其取值由统计结果和经验决定，不同的软件开发组织在不同的时期可能会有不同的取值

  3. 详细COCOMO摸型：估算独立的软构件，如各个子系统的各个模块的工作量和开发时间

3、软件项目计划

3.1 项目进度计划概念与可视化

对项目进行任务划分，定义任务之间的依赖关系，并进行时间估算和资源分配，确保以最佳的时间与成本输出满足质量要求的产品。

编制项目计划本质是一个优化问题。

• 表示软件项目工作量（成本）与开发时间之间的PNR曲线
  

• 项目进度计划的价值

  1. 有序、可控制地对软件项目进行管理；
  2. 确保员工保持高生产率；
  3. 及时交付软件产品；
  4. 降低软件开发成本；
  5. 提高客户满意度；
  6. 及时发布产品新版本。

• 项目进度计划的可视化

  1. 甘特图
     
     工具：微软的Project软件，可以显示进度条模式
     

• 里程碑
  里程碑显示项目进展中重大工作完成。里程碑不同于活动，活动是需要消耗资源的，里程碑仅仅表示事件的标记。
  

3.2 WBS分解与任务网络图

编制项目进度计划的步骤

WBS工作分解结构

工作分解结构（Work Breakdown Structure）是将项目按照功能或过程进行逐层分解，直到划分为若干内容单一、便于组织管理的单项工作，最终形成的树型结构示意图。

• 作用：

  1. 相关成员可直观了解软件项目中的各项任务（活动）；
  2. 将项目分解为可管理的任务（活动）；
  3. 作为项目计划与跟踪的基础。

• 分解模式
  

• WBS构建应该注意的原则

  1. 一个任务只应该在WVBS中的一个地方出现
  2. WVBS中某项任务的内容是其下所有VVBS项的总和
  3. 一个WBS项只能由一个人责任，其他人只能是参与者
  4. WBS必须与实际工作中的执行方式一致
  5. 应让项目团队成员积极参与创建VVBS，以确保WVBS的一致性
  6. 每个WVBS项都必须文档化，以确保准确理解已包括和未包括的工作范围
  7. WBS可以根据需求进行必要变更维护

• 任务网络图
  

关键路径计算

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

在整个任务网络图中非最长的路径都叫非关键路径。

关键路径的意义：关键路径上任何任务（活动）的延长都会导致整个项目周期的延长；如果缩短项目周期，就必须缩短关键路径的长度；项目经理应该随时关注关键路径上任务（活动）的完成情况以及关键路径是否发生了变化；对WBA中任务的串行和并行安排方式有指导意义。

• 可用资源对项目计划与关键路径的影响
  实例:
  有一个停车管理软件需要开发，包含三个功能:停车位管理、停车收费管理、人员管理
  每个功能都需要经过三个活动:需求分析、系统设计、系统开发，假定这三个功能在这三个活动上花费的时间分别为(5天、4天、3天)，(5天、4天、4天)，(4天、5天、5天)。
  有三个工程师:一个需求分析员、一个软件设计师、一个程序员。如何安排此项目活动比较好?