第11章软件项目管理

1、1第第11章章 软件项目管理软件项目管理第11章 软件项目管理2软件项目管理软件项目管理l在经历了几个像操作系统开发这样的大型软件工程项目的失败以在经历了几个像操作系统开发这样的大型软件工程项目的失败以后，人们才逐渐认识到软件管理中的独特问题。事实上，这些工后，人们才逐渐认识到软件管理中的独特问题。事实上，这些工程项目的失败并不是由于从事开发工作的软件工程师无能，正相程项目的失败并不是由于从事开发工作的软件工程师无能，正相反，他们之中的绝大多数是当时杰出的技术专家。这些工程项目反，他们之中的绝大多数是当时杰出的技术专家。这些工程项目的失败主要是由于使用的管理技术不适当。的失败主要是由于使用的管

2、理技术不适当。l总结历史经验教训，逐渐形成了软件工程这门新学科，它包括方总结历史经验教训，逐渐形成了软件工程这门新学科，它包括方法、工具和管理等广泛的研究领域。十几年来已经研究出一些用法、工具和管理等广泛的研究领域。十几年来已经研究出一些用于软件规格说明、设计、实现和验证的先进方法学，对软件管理于软件规格说明、设计、实现和验证的先进方法学，对软件管理的认识也有一定进步。但是，在软件管理方面的进步远比在设计的认识也有一定进步。但是，在软件管理方面的进步远比在设计方法学和实现方法学方面的进步小，至今还提不出一套管理软件方法学和实现方法学方面的进步小，至今还提不出一套管理软件开发的通用指导原则。开发

3、的通用指导原则。l软件经理（管理人员）的责任是制定软件开发工程的计划，监督软件经理（管理人员）的责任是制定软件开发工程的计划，监督和检查工程进展情况，保证工程按照要求的标准，准时在预算成和检查工程进展情况，保证工程按照要求的标准，准时在预算成本内完成。虽然目前好的管理还不一定能保证工程成功，但是坏本内完成。虽然目前好的管理还不一定能保证工程成功，但是坏的管理或不适当的管理技术却一定会导致工程失败的管理或不适当的管理技术却一定会导致工程失败软件交付软件交付使用的日期将大大拖后，成本可能比预计成本高几倍，而且最终使用的日期将大大拖后，成本可能比预计成本高几倍，而且最终的软件产品很难维护。的软件产品

4、很难维护。第11章 软件项目管理311.1 成本估算成本估算第11章 软件项目管理411.1.1 参数方程参数方程 静态单变量静态单变量 静态单变量模型的一般形式如下：静态单变量模型的一般形式如下： 资源资源C1(估计的特点估计的特点)*exp(C2) 其中其中“资源资源”通常是人力（即开发工作需要的工作量，通常是人力（即开发工作需要的工作量，以人月或人日、人年为单位），也可以是工程期限，以人月或人日、人年为单位），也可以是工程期限，需要的人数或文档数量等等，常数需要的人数或文档数量等等，常数C1和和C2根据历史经根据历史经验数据得出；验数据得出；“估计的特点估计的特点”通常是源代码的行数。通

5、常是源代码的行数。 例如，例如，Doty提出的估算开发工作量的算法列在表。提出的估算开发工作量的算法列在表。 表中表中MM是开发（包括分析、设计、编码、测试和调是开发（包括分析、设计、编码、测试和调试等工作）需要用的人力（以人月为单位）；试等工作）需要用的人力（以人月为单位）；I是估计是估计的程序长度，表内中间一列是用目标指令数度量长度，的程序长度，表内中间一列是用目标指令数度量长度，右边一列是用源代码行数度量长度，长度单位是千条右边一列是用源代码行数度量长度，长度单位是千条（或千行）。（或千行）。第11章 软件项目管理511.1.1 参数方程参数方程估算开发工作量的算法估算开发工作量的算法应

6、用范围应用范围目标代码目标代码源代码源代码全部全部命令和控制命令和控制科学计算科学计算商业商业实用程序实用程序MM = 4.079IMM = 4.079I0.9910.991MM = 4.573IMM = 4.573I1.2281.228MM = 4.495IMM = 4.495I1.0581.058MM = 2.895IMM = 2.895I0.7840.784MM = 12.039IMM = 12.039I0.7190.719MM = 5.528IMM = 5.528I1.0571.057MM = 4.089IMM = 4.089I1.2631.263MM = 7.054IMM = 7.0

7、54I1.0191.019 MM = 4.495IMM = 4.495I0.7810.781MM = 10.078IMM = 10.078I0.8110.811第11章 软件项目管理611.1.1 参数方程参数方程 静态多变量静态多变量 静态多变量模型也是根据历史数据导出静态多变量模型也是根据历史数据导出经验公式，公式的典型形式如下：经验公式，公式的典型形式如下： 资源资源c11e1exp(c12)+c21e2exp(c22)+ 其中其中ei是软件的第是软件的第i个特点，个特点，ci1和和ci2是与是与第第i个特点有关的经验常数。个特点有关的经验常数。第11章 软件项目管理711.1.1 参数

8、方程参数方程 动态多变量动态多变量 这类模型把资源需求看作是开发时间的函数。例如，根据大型软件工程这类模型把资源需求看作是开发时间的函数。例如，根据大型软件工程项目项目(总工作量总工作量30人年以上人年以上)的数据导出的的数据导出的Putnam模型如下：模型如下： (1)其中其中 L是源代码行数；是源代码行数； K是开发需用的人力（以人年为单位）；是开发需用的人力（以人年为单位）； td是开发需用的时间（以年为单位）；是开发需用的时间（以年为单位）； Ck是技术水平常数，它的典型值如下：是技术水平常数，它的典型值如下： 对于差的开发环境对于差的开发环境2500； 对于好的开发环境对于好的开发环

9、境10000； 对于优越的开发环境对于优越的开发环境12500。 从方程从方程(1)可以解出开发需要的工作量：可以解出开发需要的工作量：3/43/1dktKCL 433dktCLK第11章 软件项目管理811.1.2 标准值法标准值法 这种方法主要使用开发各类程序的标准生产率估计开发工程的总这种方法主要使用开发各类程序的标准生产率估计开发工程的总工作量。标准生产率根据以往的开发经验导出。主要从下述几个工作量。标准生产率根据以往的开发经验导出。主要从下述几个方面划分程序开发类型：方面划分程序开发类型： 使用的程序设计语言。使用的程序设计语言。 处理方式（批处理，实时处理等）。处理方式（批处理，实

10、时处理等）。 程序难易程度。程序难易程度。 技术人员的水平。技术人员的水平。 开发范围（从需求分析到测试，或者从程序设计到测试）。开发范围（从需求分析到测试，或者从程序设计到测试）。 使用标准值法估算开发工作量，首先需要确定程序的开发类型，使用标准值法估算开发工作量，首先需要确定程序的开发类型，并且估计程序的规模。为了使程序规模的估计值更接近实际值，并且估计程序的规模。为了使程序规模的估计值更接近实际值，可以请几名有经验的软件工程师分别作出计。每个人都应该估计可以请几名有经验的软件工程师分别作出计。每个人都应该估计程序的最小规模程序的最小规模(a)，最大规模，最大规模(b)和最可能的规模和最可

11、能的规模(m)，分别求让，分别求让这三种规模的平均值，这三种规模的平均值，a、b和和m之后，再用下式计算程序规模的之后，再用下式计算程序规模的估计值：估计值：64bmaK第11章 软件项目管理911.1.2 标准值法标准值法l 然后使用开发该类程序的标准生产率和适当然后使用开发该类程序的标准生产率和适当的修正系数估算开发工作量：的修正系数估算开发工作量：l 工作量工作量 修正系数修正系数 l 其中标准生产率的单位通常是每人日可以开其中标准生产率的单位通常是每人日可以开发的程序长度（源程序行数或目标指令条数）；发的程序长度（源程序行数或目标指令条数）；修正系数反映其他因素对开发工作量的影响，修正

12、系数反映其他因素对开发工作量的影响，当考虑从需求分析直到测试的开发过程时，它当考虑从需求分析直到测试的开发过程时，它的算法是：的算法是：l 修正系数修正系数 1 + 0.1 * n l 其中其中n是符合下列条款的数目：是符合下列条款的数目：标准生产率程序长度第11章 软件项目管理1011.1.2 标准值法标准值法 目标系统情况目标系统情况 修改文档不完备的程序修改文档不完备的程序 需求中有不明确的或尚未决定的内容需求中有不明确的或尚未决定的内容 系统规模较大系统规模较大 工作带有试探性质（需多次试探）工作带有试探性质（需多次试探） 系统接口不明确或接口复杂系统接口不明确或接口复杂 联机实时系统

13、（测试困难）联机实时系统（测试困难） 数据库需要复杂的安全措施数据库需要复杂的安全措施第11章 软件项目管理1111.1.2 标准值法标准值法 项目管理和人员组成情况项目管理和人员组成情况 中途改变项目管理人中途改变项目管理人 项目组不协调（人事关系不好）项目组不协调（人事关系不好） 新手或初级人员比例较高新手或初级人员比例较高 需要培训程序员需要培训程序员 项目管理人没有数据处理经验项目管理人没有数据处理经验 项目管理人没有应用领域经验项目管理人没有应用领域经验 系统分析员没有应用领域经验系统分析员没有应用领域经验 系统设计员没有应用领域经验系统设计员没有应用领域经验 程序员没有应用领域经验

14、程序员没有应用领域经验第11章 软件项目管理1211.1.2 标准值法标准值法 用户情况用户情况 用户对计算机数据处理知之甚少用户对计算机数据处理知之甚少 系统需要在不同场合使用系统需要在不同场合使用 系统需满足使用部门的标准或手续系统需满足使用部门的标准或手续 使用部门提供的测试数据没经过验证使用部门提供的测试数据没经过验证 使用部门不同意开发计划使用部门不同意开发计划 开发过程中用户需求发生了变化开发过程中用户需求发生了变化 使用部门负责人变动使用部门负责人变动第11章 软件项目管理1311.1.2 标准值法标准值法 开发环境情况开发环境情况 现有的操作系统功能不足现有的操作系统功能不足

15、将来预定使用的计算机尚未测试将来预定使用的计算机尚未测试 工作场所分散工作场所分散 主存和辅存受限制主存和辅存受限制 计算机使用时间不能充分保障计算机使用时间不能充分保障 计算机机房管理不善计算机机房管理不善 工作中途中断工作中途中断第11章 软件项目管理1411.1.3 COCOMO模型模型 所谓所谓COCOMO模型就是模型就是Boehm提出的构造性成本模型提出的构造性成本模型（Constructive Cost Model）。在这种模型中，软件）。在这种模型中，软件开发工作量表示成据估计应该开发的代码行数的非线开发工作量表示成据估计应该开发的代码行数的非线性函数：性函数： 其中其中 MM是

16、开发工作量（以人月为单位），是开发工作量（以人月为单位）， 是模型系数，是模型系数， KLOC是估计的代码行数（以千行为单位），是估计的代码行数（以千行为单位）， a是模型指数，是模型指数， fi（i1到到15）是成本因素。）是成本因素。1511iiafkLOCCMM第11章 软件项目管理1511.1.3 COCOMO模型模型表表 1515种影响软件工作量的因素种影响软件工作量的因素fi的等级分类的等级分类工作量因素工作量因素fi非常低非常低 低低 正常正常 高高 非常高非常高 超高超高产品产品因素因素软件可靠性软件可靠性数据库规模数据库规模产品复杂性产品复杂性0.75 0.88 1.00 1

17、.15 1.400.75 0.88 1.00 1.15 1.40 0.94 1.00 1.08 1.16 0.94 1.00 1.08 1.160.70 0.85 1.00 1.15 1.30 1.650.70 0.85 1.00 1.15 1.30 1.65计算机计算机因素因素执行时间限制执行时间限制存储限制存储限制虚拟机虚拟机* *易变性易变性环境周转时间环境周转时间 1.00 1.11 1.30 1.661.00 1.11 1.30 1.66 1.00 1.06 1.21 1.56 1.00 1.06 1.21 1.56 0.87 1.00 1.15 1.30 0.87 1.00 1.1

18、5 1.30 0.87 1.00 1.07 1.15 0.87 1.00 1.07 1.15人员的人员的因素因素分析员能力分析员能力应用领域实际检验应用领域实际检验程序员能力程序员能力虚拟机虚拟机* *使用经验使用经验程序语言使用经验程序语言使用经验 1.46 1.00 0.861.46 1.00 0.861.29 1.13 1.00 0.91 0.711.29 1.13 1.00 0.91 0.711.42 1.17 1.00 0.86 0.821.42 1.17 1.00 0.86 0.821.21 1.10 1.00 0.90 0.701.21 1.10 1.00 0.90 0.701.

19、41 1.07 1.00 0.951.41 1.07 1.00 0.95项目项目因素因素现代程序设计技术现代程序设计技术软件工具的使用软件工具的使用开发进度限制开发进度限制1.24 1.10 1.00 0.91 0.821.24 1.10 1.00 0.91 0.821.24 1.10 1.00 0.91 0.831.24 1.10 1.00 0.91 0.831.23 1.08 1.00 1.04 1.101.23 1.08 1.00 1.04 1.10 * * 虚拟机是指为完成某一个任务所使用硬、软件的结合。虚拟机是指为完成某一个任务所使用硬、软件的结合。第11章 软件项目管理1611.1

20、.3 COCOMO模型模型lCOCOMO模型是层次型模型，按详细程度分成模型是层次型模型，按详细程度分成3级。级。最上层是对各种规模软件的宏观估计模型；最下层是最上层是对各种规模软件的宏观估计模型；最下层是微观模型，它具有任务分解结构和一系列阶段敏感因微观模型，它具有任务分解结构和一系列阶段敏感因子。下面简单介绍中层子。下面简单介绍中层COCOMO模型。模型。l软件开发项目可以分成组织式、半独立式和嵌入式三软件开发项目可以分成组织式、半独立式和嵌入式三种模式。对组织式软件的要求通常不苛刻，开发人员种模式。对组织式软件的要求通常不苛刻，开发人员经验丰富，而且对软件的使用环境很熟悉（通常是为经验丰

21、富，而且对软件的使用环境很熟悉（通常是为自己所在的组织开发软件），程序规模一般不大（小自己所在的组织开发软件），程序规模一般不大（小于于50000行代码）。行代码）。 基本基本COCOMOCOCOMO模型的工作量和进度公式模型的工作量和进度公式总体类型总体类型 工工 作作 量量 进进 度度组组 织织 型型半独立型半独立型嵌嵌 入入 型型 MM=2.4(KDSI)MM=2.4(KDSI)1.051.05 TDEV=2.5(MM) TDEV=2.5(MM)0.380.38 MM=3.0(KDSI) MM=3.0(KDSI)1.121.12 TDEV=2.5(MM) TDEV=2.5(MM)0.35

22、0.35 MM=3.6(KDSI) MM=3.6(KDSI)1.201.20 TDEV=2.5(MM) TDEV=2.5(MM)0.320.32第11章 软件项目管理1711.1.3 COCOMO模型模型【例】一个规模【例】一个规模10KDSI的商用微机远程通信的的商用微机远程通信的嵌入型软件，使用中间嵌入型软件，使用中间COCOMO模型进行软模型进行软件成本估算。件成本估算。 程序名义工作量程序名义工作量MM 2.8(10)1.20=44.38(MM) 程序实际工作量程序实际工作量MM =44.38 =44.381.17=51.9(MM) 开发所用时间开发所用时间TDEV =2.5(51.9

23、)0.32=8.8(月月) 如果分析员与程序员的工资都按每月如果分析员与程序员的工资都按每月6000美圆美圆计算，则该项目的开发人员的工资总额为：计算，则该项目的开发人员的工资总额为： 51.96000=311400(美圆美圆)51iif151iif第11章 软件项目管理1811.1.3 COCOMO模型模型影响负责量因素影响负责量因素fi取值表取值表影响工作量因素影响工作量因素fifi 情情 况况 取值取值1 1软件可靠性软件可靠性 只用于局部地区，恢复问题不严重只用于局部地区，恢复问题不严重 1.00(1.00(正常正常) )2 2数据库规模数据库规模 2000020000字节字节 0.9

24、4(0.94(低低) )3 3 产品复杂性产品复杂性 用于远程通信处理用于远程通信处理 1.30(1.30(很高很高) )4 4 时间限制时间限制 使用使用70%70%的的CPUCPU时间时间 1.10(1.10(高高) )5 5 存储限制存储限制 64KB64KB中使用中使用45KB 1.06(45KB 1.06(高高) )6 6 机器机器 使用商用微处理机使用商用微处理机 1.00(1.00(额定值额定值) )7 7 周转时间周转时间 平均平均2 2小时小时 1.00(1.00(额定值额定值) )8 8 分析员能力分析员能力 优秀人才优秀人才 0.86(0.86(高高) )9 9 工作经验

25、工作经验 远程通信工作远程通信工作3 3年年 1.10(1.10(低低) )10 10 程序员能力程序员能力 优秀人才优秀人才 0.86(0.86(高高) )11 11 工作经验工作经验 微型机工作微型机工作6 6个月个月 1.00(1.00(正常正常) )12 12 语言使用经验语言使用经验 1212个月个月 1.00(1.00(正常正常) )13 13 使用现代程序设计技术使用现代程序设计技术 1 1年以上年以上 0.91(0.91(高高) )14 14 使用软件工具使用软件工具 基本的微型机软件基本的微型机软件 1.10(1.10(低低) )15 15 工期工期 9 9个月个月 1.00

26、(1.00(正常正常) )第11章 软件项目管理1911.1.3 COCOMO模型模型l现在用一水平较低的开发人员现在用一水平较低的开发人员,其工资为其工资为每月每月5000美圆美圆,但人员的水平的两个调节但人员的水平的两个调节因子从因子从0.86调高到调高到1.00,则整个调节因子从则整个调节因子从原来的原来的1.17上升到上升到1.58,其开发成本为其开发成本为: 500044.381.58=350602第11章 软件项目管理2011.2 进度计划进度计划 第11章 软件项目管理21进度计划进度计划l管理复杂的工程项目非常困难，最好的办法是管理复杂的工程项目非常困难，最好的办法是把它分解成

27、一系列比较容易管理的子任务。但把它分解成一系列比较容易管理的子任务。但是分解后也容易只注意对各个子任务的管理，是分解后也容易只注意对各个子任务的管理，以致忽略了对工程总体情况的了解和管理。因以致忽略了对工程总体情况的了解和管理。因此需要有某种工具既支持把项目分解成较小的此需要有某种工具既支持把项目分解成较小的子任务子任务(又称为作业又称为作业)，又能帮助管理人员保持，又能帮助管理人员保持对工程总体情况的洞悉和管理。对工程总体情况的洞悉和管理。l通常的做法是按工程项目分解成许多逻辑步骤通常的做法是按工程项目分解成许多逻辑步骤(作业作业)，然后安排这些作业的顺序，确定每项，然后安排这些作业的顺序，

28、确定每项作业需要用的时间，以及作业开始和终止的时作业需要用的时间，以及作业开始和终止的时间。这也就是制定进度计划的任务。间。这也就是制定进度计划的任务。Gantt图图和工程网络图是制定进度计划时常用的两个图和工程网络图是制定进度计划时常用的两个图形工具。形工具。第11章 软件项目管理2211.2.1 工程网络图工程网络图l 工程网络是制定进度计划时一种常用的图形工具，它工程网络是制定进度计划时一种常用的图形工具，它能描绘任务分解情况以及每项作业的开始时间和结束能描绘任务分解情况以及每项作业的开始时间和结束时间，此外，它还显式地描绘各个作业彼此间的依赖时间，此外，它还显式地描绘各个作业彼此间的依

29、赖关系。因此，工程网络是系统分析和系统设计的强有关系。因此，工程网络是系统分析和系统设计的强有力的工具。力的工具。l系统分析员就可以借助它的帮助估算工程进度了。为系统分析员就可以借助它的帮助估算工程进度了。为此需要在工程网络上增加一些必要的信息。此需要在工程网络上增加一些必要的信息。l首先，把每个作业估计需要使用的时间写在表示该项首先，把每个作业估计需要使用的时间写在表示该项作业的箭头上方。注意，箭头长度和它代表的作业持作业的箭头上方。注意，箭头长度和它代表的作业持续时间没有关系，箭头仅表示依赖关系；它上方的数续时间没有关系，箭头仅表示依赖关系；它上方的数字才表示作业的持续时间。字才表示作业的

30、持续时间。l其次，为每个事件计算下述两个统计数字：最早时刻其次，为每个事件计算下述两个统计数字：最早时刻EET和最迟时刻和最迟时刻LET。这两个数字将分别写在表示事。这两个数字将分别写在表示事件的圆圈的右上角和右下角。件的圆圈的右上角和右下角。 第11章 软件项目管理2311.2.1 工程网络图工程网络图l事件的最早时刻是该事件可以发生的最早时间。事件的最早时刻是该事件可以发生的最早时间。通常工程网络中第一个事件的最早时刻定义为通常工程网络中第一个事件的最早时刻定义为零，其他事件的最早时刻在工程网络上从左至零，其他事件的最早时刻在工程网络上从左至右按事件发生顺序计算。计算最早时刻右按事件发生顺

31、序计算。计算最早时刻EET使使用下述三条简单规则：用下述三条简单规则： 考虑进入该事件的所有作业；考虑进入该事件的所有作业； 对于每个作业都计算它的持续时间与起始对于每个作业都计算它的持续时间与起始事件的事件的EET之和；之和； 选取上述和数中的最大值作为该事件的最选取上述和数中的最大值作为该事件的最早时刻早时刻EET。 第11章 软件项目管理2411.2.1 工程网络图工程网络图第11章 软件项目管理2511.2.1 工程网络图工程网络图l 事件的最迟时刻是在不影响工程竣工时间的前事件的最迟时刻是在不影响工程竣工时间的前提下，该事件最晚可以发生的时刻。按惯例，提下，该事件最晚可以发生的时刻。

32、按惯例，最后一个事件（工程结束）的员迟时刻就是它最后一个事件（工程结束）的员迟时刻就是它的最早时刻。其他事件的员迟时刻在工程网络的最早时刻。其他事件的员迟时刻在工程网络上从右至左按逆作业流的方向计算。计算最迟上从右至左按逆作业流的方向计算。计算最迟时刻时刻LET使用下述三条规则：使用下述三条规则： 考虑离开该事件的所有作业；考虑离开该事件的所有作业； 从每个作业的结束事件的最迟时刻中减去从每个作业的结束事件的最迟时刻中减去该作业的持续时间；该作业的持续时间； 选取上述差数中的最小值做为该事件的最选取上述差数中的最小值做为该事件的最迟时刻迟时刻LET。第11章 软件项目管理2611.2.2 关键

33、路径关键路径 l有几个事件的最早时刻和最迟时刻相同，这些有几个事件的最早时刻和最迟时刻相同，这些事件定义了关键路径，在图中关键路径用粗线事件定义了关键路径，在图中关键路径用粗线箭头表示。关键路径上的事件（关键事件）必箭头表示。关键路径上的事件（关键事件）必须准时发生，组成关键路径的作业（关键作业）须准时发生，组成关键路径的作业（关键作业）的实际持续时间不能超过估计的持续时间，否的实际持续时间不能超过估计的持续时间，否则工程就不能准时结束。则工程就不能准时结束。l 工程项目的管理人员应该密切注视关键作业工程项目的管理人员应该密切注视关键作业的进展情况，如果关键事件出现的时间比预计的进展情况，如果

34、关键事件出现的时间比预计的时间晚，则会使最终完成项目的时间施后；的时间晚，则会使最终完成项目的时间施后；如果希望缩短工期，只有往关键作业中增加资如果希望缩短工期，只有往关键作业中增加资源才会有效果。源才会有效果。第11章 软件项目管理2711.2.3 机动时间机动时间l 不在关键路径上的作业有一定程度的机不在关键路径上的作业有一定程度的机动余地动余地实际开始时间可以比预定时实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预间晚一些，或者实际持续时间可以比预计的持续时间长一些，而并不影响工程计的持续时间长一些，而并不影响工程的结束时间。一个作业可以有的全部机的结束时间。一个作业可以有的全

35、部机动时间等于它的结束事件的最迟时刻减动时间等于它的结束事件的最迟时刻减去它的开始事件的最早时刻，再减去这去它的开始事件的最早时刻，再减去这个作业的持续时间：个作业的持续时间： 机动时间机动时间(LET)结束结束 - (LET)开始开始 - 持续时间持续时间第11章 软件项目管理2811.2.4 Gantt图（甘特图）图（甘特图） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15活活动动负负责责人人分分析析测测试试计计划划设设计计编编码码测测试试软软件件测测试试数数据据产产品品测测试试文文档档第11章 软件项目管理2911.3 人员组织人员组织第11章 软件项目管理30l

36、 传统的管理结构是层次结构。在层次结构内，每一级传统的管理结构是层次结构。在层次结构内，每一级人员向其上级报告工作并且管理下一级的人员。典型人员向其上级报告工作并且管理下一级的人员。典型地，一个经理管理地，一个经理管理12-25个下级人员。管理软件开发通个下级人员。管理软件开发通常也采用层次结构，但是，软件工程项目的管理很复常也采用层次结构，但是，软件工程项目的管理很复杂，因此每个经理一般只直接管理杂，因此每个经理一般只直接管理6名下级人员。名下级人员。 在在同时从事多个软件开发项目的大型软件开发组织中，同时从事多个软件开发项目的大型软件开发组织中，管理结构可能如同图管理结构可能如同图13.5

37、描绘的那样。软件经理负责描绘的那样。软件经理负责管理软件开发部门，在各个项目间分配和协调各种资管理软件开发部门，在各个项目间分配和协调各种资源。项目经理管理一个具体的开发项目的各个方面源。项目经理管理一个具体的开发项目的各个方面（计划、进度、审查和复审、用户界面等等），领导（计划、进度、审查和复审、用户界面等等），领导1-6个程序设计小组，每个小组负责项目的一部分开发个程序设计小组，每个小组负责项目的一部分开发工作（一个子系统的开发或系统开发的某些阶段）。工作（一个子系统的开发或系统开发的某些阶段）。审查小组从事质量保证活动，在项目开发的里程碑审查小组从事质量保证活动，在项目开发的里程碑（例如

38、，生命周期每个阶段结束之前）进行技术审查（例如，生命周期每个阶段结束之前）进行技术审查和管理复审。和管理复审。第11章 软件项目管理3111.3.1 程序设计小组的组织程序设计小组的组织 l 程序设计小组的人数不能太多，否则组员间彼此通信程序设计小组的人数不能太多，否则组员间彼此通信的时间将多于程序设计时间。此外，通常不能把一个的时间将多于程序设计时间。此外，通常不能把一个软件系统划分成大量独立的单元，因此，如果程序设软件系统划分成大量独立的单元，因此，如果程序设计小组人数太多，则每个组员所负责开发的程序单元计小组人数太多，则每个组员所负责开发的程序单元与系统其他部分的界面将是复杂的，不仅出现

39、接口错与系统其他部分的界面将是复杂的，不仅出现接口错误的可能性增加，而且软件测试将既困难又费时间。误的可能性增加，而且软件测试将既困难又费时间。l 一般说来，程序设计小组的规模应该比较小，以一般说来，程序设计小组的规模应该比较小，以2-8名成员为宜。如果项目规模很大，用一个小组不能在名成员为宜。如果项目规模很大，用一个小组不能在预定时间内完成开发任务，则应该使用多个程序设计预定时间内完成开发任务，则应该使用多个程序设计小组，每个小组承担工程项目的一部分任务，在一定小组，每个小组承担工程项目的一部分任务，在一定程度上独立自主地完成各自的任务。系统的总体设计程度上独立自主地完成各自的任务。系统的总

40、体设计应该能够保证由各个小组负责开发的各部分之间的接应该能够保证由各个小组负责开发的各部分之间的接口是良好定义的，并且是尽可能简单的。口是良好定义的，并且是尽可能简单的。第11章 软件项目管理3211.3.1 程序设计小组的组织程序设计小组的组织l小组规模小，不仅可以减少通信问题，而且还有其他好处。例如，小组规模小，不仅可以减少通信问题，而且还有其他好处。例如，容易确定小组的质量标准，而且用民主方式确定的标准更容易被容易确定小组的质量标准，而且用民主方式确定的标准更容易被大家遵守；组员间关系密切，能够互相学习等等。大家遵守；组员间关系密切，能够互相学习等等。l小型的程序设计小组通常采用非正式的

41、组织方式，也就是说，虽小型的程序设计小组通常采用非正式的组织方式，也就是说，虽然名义上有一个组长，但是他和组内其他成员完成同样的任务。然名义上有一个组长，但是他和组内其他成员完成同样的任务。在这样的小组中，由全体讨论决定应该完成的工作，并且根据每在这样的小组中，由全体讨论决定应该完成的工作，并且根据每个人的能力和经验分配适当的任务。个人的能力和经验分配适当的任务。l如果组内多数成员是经验丰富技术熟练的程序员，那么上述非正如果组内多数成员是经验丰富技术熟练的程序员，那么上述非正式的组织方式可能会非常成功。在这样的小组内组员享有充分民式的组织方式可能会非常成功。在这样的小组内组员享有充分民主，通过

42、协商，在自愿的基础上作出决定，因此能够增强团结、主，通过协商，在自愿的基础上作出决定，因此能够增强团结、提高工作效率。但是，如果组内多数成员技术水平不高，或是缺提高工作效率。但是，如果组内多数成员技术水平不高，或是缺乏经验的新手，那么这种非正式的组织方式也有严重缺点：由于乏经验的新手，那么这种非正式的组织方式也有严重缺点：由于没有明确的权威指导开发工程的进行，组员间将缺乏必要的协调，没有明确的权威指导开发工程的进行，组员间将缺乏必要的协调，最终可能导致工程失败。最终可能导致工程失败。l为了使少数经验丰富、技术高超的程序员在软件开发过程中能够为了使少数经验丰富、技术高超的程序员在软件开发过程中能

43、够发挥更大作用，程序设计小组也可以来用下一小节中介绍的另外发挥更大作用，程序设计小组也可以来用下一小节中介绍的另外一种组织形式。一种组织形式。第11章 软件项目管理3311.3.2 主程序员组主程序员组 美国美国IBM公司在公司在70年代初期开始采用主程序员组的组年代初期开始采用主程序员组的组织方式。采用这种组织方式主要出于下述几点考虑；织方式。采用这种组织方式主要出于下述几点考虑； 软件开发人员多数比较缺乏经验；软件开发人员多数比较缺乏经验； 程序设计过程中有许多事务性的工作，例如，大量程序设计过程中有许多事务性的工作，例如，大量信息的存储和更新；信息的存储和更新； 多渠道通信很费时间，将降

44、低程序员的生产率。多渠道通信很费时间，将降低程序员的生产率。 主程序员组用经验多、技术好、能力强的程序员作为主程序员组用经验多、技术好、能力强的程序员作为主程序员，同时，利用人和计算机在事务性工作方面主程序员，同时，利用人和计算机在事务性工作方面给主程序员提供充分支待，而且所有通信都通过一两给主程序员提供充分支待，而且所有通信都通过一两个人进行。这种组织方式类似于外科手术小组的组织：个人进行。这种组织方式类似于外科手术小组的组织：主刀大夫对手术全面负责，并且完成制；订手术方案、主刀大夫对手术全面负责，并且完成制；订手术方案、开刀等关键工作，同时又有麻醉师、护士长等技术熟开刀等关键工作，同时又有

45、麻醉师、护士长等技术熟练的专门人员协助和配合他的工作。练的专门人员协助和配合他的工作。第11章 软件项目管理3411.3.2 主程序员组主程序员组 主程序员组的核心有主程序员组的核心有3个人：个人： 主程序员是经验丰富能力强的高级程序员，主程序员是经验丰富能力强的高级程序员，全面负责系统的设计、编码、测试和安装。全面负责系统的设计、编码、测试和安装。 辅助程序员也应该技术熟练而且富于经验，辅助程序员也应该技术熟练而且富于经验，他协助主程序员工作并且在必要时能代替主程他协助主程序员工作并且在必要时能代替主程序员。他的主要任务是设计测试方案和分析测序员。他的主要任务是设计测试方案和分析测试结果，以

46、验证主程序员的工作。试结果，以验证主程序员的工作。 程序管理员完成和项目有关的全部事务性程序管理员完成和项目有关的全部事务性工作，例如，提交上机程序，保存运行记录，工作，例如，提交上机程序，保存运行记录，进行软件配置管理等。进行软件配置管理等。第11章 软件项目管理3511.3.2 主程序员组主程序员组l 根据应用规模和类型，可能需临时或长期地往组内增加一些其他根据应用规模和类型，可能需临时或长期地往组内增加一些其他方面的专门人员，例如：方面的专门人员，例如：l 项目管理员，负责行政后勤方面的管理事务。项目管理员，负责行政后勤方面的管理事务。l 工具员，负责开发必要的软件工具。工具员，负责开发

47、必要的软件工具。l 文档编辑，负责对主程序员或辅助程序员书写的文档进行文档编辑，负责对主程序员或辅助程序员书写的文档进行编辑加工。编辑加工。l 语言和系统专家，他对正在使用的程序设计语言和系统的语言和系统专家，他对正在使用的程序设计语言和系统的特点比较熟悉，他的任务是给主程序员提建议，以便更好地利用特点比较熟悉，他的任务是给主程序员提建议，以便更好地利用这些特点。这些特点。l 测试员，任务是提出具体的测试方案，编写测试驱动程序测试员，任务是提出具体的测试方案，编写测试驱动程序和存根程序，并且进行测试以验证主程序员的工作。和存根程序，并且进行测试以验证主程序员的工作。l 一个或多个后援程序员，他

48、们的任务是按照主程序员的设一个或多个后援程序员，他们的任务是按照主程序员的设计去编码。当项目规模很大，主程序员和辅助程序员无力独立完计去编码。当项目规模很大，主程序员和辅助程序员无力独立完成详细的程序设计工作时，需在组内增加后援程序员。成详细的程序设计工作时，需在组内增加后援程序员。第11章 软件项目管理3611.4 项目计划项目计划第11章 软件项目管理37l 对软件项目的有效管理取决于对项目的对软件项目的有效管理取决于对项目的全面计划。根据美国联邦政府的调查统全面计划。根据美国联邦政府的调查统计，因软件计划不当而造成的项目失败计，因软件计划不当而造成的项目失败数占失败总数的一半以上。制订计

49、划时数占失败总数的一半以上。制订计划时应该预见到可能发生的问题，并且预先应该预见到可能发生的问题，并且预先准备好试探性的解决办法。下面讨论的准备好试探性的解决办法。下面讨论的计划适用于大型软件系统，这样的系统计划适用于大型软件系统，这样的系统需要多个小组同时参加工作，才能在给需要多个小组同时参加工作，才能在给定时间内完成项目开发任务。定时间内完成项目开发任务。第11章 软件项目管理3811.4.1 项目计划的内容项目计划的内容 为大型软件开发项目所制定的计划通常包括下列基本内容：为大型软件开发项目所制定的计划通常包括下列基本内容： 概述概述 一般性地叙述开发项目，描述计划组织，并且概述这个文档

50、其余部分的内一般性地叙述开发项目，描述计划组织，并且概述这个文档其余部分的内容。容。 阶段计划阶段计划 讨论项目开发周期讨论项目开发周期需求分析阶段，总体设计阶段，详细设计阶段等等。需求分析阶段，总体设计阶段，详细设计阶段等等。详细说明每个阶段应该完成的日期，并且指出不同阶段可以互相重叠的详细说明每个阶段应该完成的日期，并且指出不同阶段可以互相重叠的时间等等。时间等等。 组织计划组织计划 规定从事这个开发项目的每个小组的具体责任。规定从事这个开发项目的每个小组的具体责任。 测试计划测试计划 概述应进行的测试和需要的工具，以及完成系统测试的过程和分工。在这概述应进行的测试和需要的工具，以及完成系

51、统测试的过程和分工。在这一节中并不包括具体的测试方案。一节中并不包括具体的测试方案。 变动控制计划变动控制计划 确定在系统开发过程中需求变动时的管理控制机制。确定在系统开发过程中需求变动时的管理控制机制。 文档计划文档计划 这一节的目的是定义和管理与项目有关的文档。这一节的目的是定义和管理与项目有关的文档。第11章 软件项目管理39 培训计划培训计划 培训从事开发工作的程序员和使用系统的用户的计划。培训从事开发工作的程序员和使用系统的用户的计划。 复审和报告计划复审和报告计划 讨论如何报告项目的状况，并且确定对项目进展情况进行正式复讨论如何报告项目的状况，并且确定对项目进展情况进行正式复审的计

52、划。审的计划。 安装和运行计划安装和运行计划 描述在用户现场安装该系统的过程。描述在用户现场安装该系统的过程。 资源和配置计划资源和配置计划 概述关键的细节计划概述关键的细节计划进度、里程碑和按合同规定应该交付的进度、里程碑和按合同规定应该交付的系统配置成分。系统配置成分。 索引索引 上述项目计划内容大部分已经在前面的章节中详细讨论过，本节上述项目计划内容大部分已经在前面的章节中详细讨论过，本节只讨论项目报告和变动控制两个问题。只讨论项目报告和变动控制两个问题。第11章 软件项目管理4011.4.2 项目报告项目报告l 定期把有关项目进展情况的信息，反馈给管理人员是极端重要的。定期把有关项目进

53、展情况的信息，反馈给管理人员是极端重要的。应该报告的信息通常包括：在这段时间内已经完成的工作；下阶应该报告的信息通常包括：在这段时间内已经完成的工作；下阶段计划要完成的工作；问题范围；到目前为止已经用掉的成本；段计划要完成的工作；问题范围；到目前为止已经用掉的成本；项目预算执行情况及其他有关的信息。没有这些信息管理人员就项目预算执行情况及其他有关的信息。没有这些信息管理人员就失掉了对项目的控制，也不能及时修正成本估计和进度计划。失掉了对项目的控制，也不能及时修正成本估计和进度计划。l为项目制定计划时，应该确立一系列里程碑。在每个里程碑，开为项目制定计划时，应该确立一系列里程碑。在每个里程碑，开

54、发人员都应该把正式的进展报告提交给管理人员。如果不能毫不发人员都应该把正式的进展报告提交给管理人员。如果不能毫不含糊地判断是否计划中确定的里程碑已经到达，那么这样的里程含糊地判断是否计划中确定的里程碑已经到达，那么这样的里程碑就是毫无意义的。应该使一个里程碑代表项目开发过程中一个碑就是毫无意义的。应该使一个里程碑代表项目开发过程中一个独特阶段的顶峰。好里程碑的特点通常是完成了某个文档，例如，独特阶段的顶峰。好里程碑的特点通常是完成了某个文档，例如，“完成了总体设计完成了总体设计”或或“正式提出了测试计划正式提出了测试计划”等。相反，像等。相反，像“完成了完成了80编码工作编码工作”这样的里程碑

55、是不好的，因为很难准确这样的里程碑是不好的，因为很难准确断定什么时候完成了断定什么时候完成了80的编码工作。的编码工作。第11章 软件项目管理4111.4.3 变动控制变动控制 l 任何软件开发都是迭代过程，也就是说，任何软件开发都是迭代过程，也就是说，在设计软件时会发现需求说明中的问题，在设计软件时会发现需求说明中的问题，在实现过程中又会暴露出设计中的错误，在实现过程中又会暴露出设计中的错误，如此等等。因此，变动既是必要的，又如此等等。因此，变动既是必要的，又是不可避免的。但是，变动也很容易失是不可避免的。但是，变动也很容易失去控制，因此，对于管理人员来说，预去控制，因此，对于管理人员来说，

56、预先计划控制变动的机制，建立评价变动先计划控制变动的机制，建立评价变动的影响和把发生的变动记入文档的过程，的影响和把发生的变动记入文档的过程，就是十分重要的了。就是十分重要的了。第11章 软件项目管理4211.4.3 变动控制变动控制 l变动通常可以分为两类：变动通常可以分为两类：l第一类是为了改正小错误需要的变动，第二类第一类是为了改正小错误需要的变动，第二类是为了增加或删掉某些功能，或者为了改变完是为了增加或删掉某些功能，或者为了改变完成某个功能的方法而需要的变动。第一类变动成某个功能的方法而需要的变动。第一类变动是必须进行的，通常不需要从管理角度对这类是必须进行的，通常不需要从管理角度对这类变动进行审查和批准。但是，如果发现错误的变动进行审查和批准。但是，如果发现错误的阶段在造成错误的阶段的后面（例如，在实现阶段在造成错误的阶段的后面（例如，在实现阶段发现了