第13章 软件项目管理

第13章软件项目管理13.1估算软件规模13.2工作量估算13.3进度计划13.4人员组织13.5质量保证13.6软件配置管理13.7能力成熟度模型目标估算软件规模估算开发工作量安排进度计划人员安排理解质量保证体系描述软件配置管理理解能力成熟度模型项目失败：72%失败的主要表现：32%项目开始后不久取消40%项目延期，超支等项目失败的主要原因需求不清晰项目规模估计不足进度计划安排不合理没有进行很好的质量保证软件项目管理(I)管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。软件项目管理先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。软件项目管理(II)13.1.1代码行技术13.1.2功能点技术13.1估算软件规模用历史类似产品估计某一个功能需要的代码行数。把实现每个功能所需要的源程序行数累加起来，就可得到实现整个软件所需要的源程序行数。为了使得对程序规模的估计值更接近实际值，可以由多名有经验的软件工程师分别做出估计。13.1.1代码行技术(I)每个人都估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)，分别算出这3种规模的平均值、和之后，再用下式计算程序规模的估计值：L=(13.1)64bma13.1.1代码行技术(II)优点：代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。缺点：源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模似乎不太合理；用不同语言实现同一个软件所需要的代码行数并不相同；这种方法不适用于非过程语言。为了克服代码行技术的缺点，人们又提出了功能点技术。13.1.1代码行技术(III)CAD系统经过分解,识别出下列主要软件功能：用户界面和控制功能二维几何分析三维几何分析数据库管理计算机图形显示功能外设控制PC设计分析模块通过分解，可得到如下估算表13.1.1代码行技术(IV)估算表功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法用功能点（FP）为单位度量软件规模。信息域特性输入项数(Inp)输出项数(Out)查询数(Inq)主文件数(Maf)外部接口数(Inf)13.1.2功能点技术(I)估算功能点的步骤计算未调整的功能点数UFPUFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf计算技术复杂性因子TCFDI=Fi在表13.2（见书297页）中列出了全部技术因素TCF=0.65+0.01×DI计算功能点数FPFP=UFP×TCF功能点数与编程语言无关，看起来功能点技术比代码行技术更合理一些。但判断信息域特性复杂级别和技术因素的影响程度时，存在着相当大的主观因素。13.1.2功能点技术(II)141iiF软件估算模型使用由经验导出的公式来预测软件开发工作量支持大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的13.2.1静态单变量模型13.2.2动态多变量模型13.2.3COCOMO2模型13.2工作量估算面向KLOC的估算模型Walston_Felix模型E=5.2×(KLOC)0.91Bailey_Basili模型E=5.5+0.73×(KLOC)1.16Boehm简单模型E=3.2×(KLOC)1.05Doty模型（在KLOC9时适用）E=5.288×(KLOC)1.04713.2.1静态单变量模型(I)面向FP的估算模型(1)Albrecht&Gaffney模型E=-13.39+0.0545FPMaston,Barnett和Mellichamp模型E=585.7+15.12FP13.2.1静态单变量模型(II)动态多变量模型是根据从4000多个当代软件项目中收集的生产率数据推导出来的。该模型把工作量看作是软件规模和开发时间这两个变量的函数。动态多变量估算模型的形式如下：E=(LOC×B0.333/P)3×(1/t)4E是以人月或人年为单位的工作量；t是以月或年为单位的项目持续时间；B是特殊技术因子P是生产率参数13.2.2动态多变量模型COCOMO是构造性成本模型（constructivecostmodel)的英文缩写。1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修订版，它反映了十多年来在成本估计方面所积累的经验。13.2.3COCOMO2模型(I)COCOMO2给出了3个层次的软件开发工作量估算模型，这3个层次的估算模型分别是：应用系统组成模型。用于估算构建原型的工作量早期设计模型。用于体系结构设计阶段。后体系结构模型。用于完成体系结构设计之后的软件开发阶段。13.2.3COCOMO2模型(II)下面以后体系结构模型为例，介绍COCOMO2模型。该模型把软件开发工作量表示成代码行数（KLOC）的非线性函数：E=(13.3)E是开发工作量（以人月为单位），a是模型系数，KLOC是估计的源代码行数（以千行为单位），b是模型指数，fi(i=1~17)是成本因素。(表13.3（见书300页）)171iibfKLOCa13.2.3COCOMO2模型(III)Boehm把成本因素划分成产品因素、平台因素、人员因素和项目因素等4类。COCOMO2模型的变化新增加了4个成本因素：分别是要求的可重用性、需要的文档量、人员连续性和多地点开发。略去了原始模型中的2个成本因素某些成本因素对生产率的影响增加了，另一些成本因素的影响减小了。13.2.3COCOMO2模型(IV)COCOMO2采用了更加精细得多的b分级模型，使用5个分级因素Wi，然后用下式计算b的数值：b=(13.4)b的取值范围为1.01~1.26。COCOMO2使用的5个分级因素如下所述：项目先例性。开发灵活性。风险排除度。项目组凝聚力。过程成熟度。13.2.3COCOMO2模型(V)5101.101.1iiW13.3.1估算开发时间13.3.2Gannt图13.3.3工程网络图13.3进度计划(I)目标是定义全部项目任务，识别出关键任务，跟踪关键任务的进展状况，以保证能及时发现拖延进度的情况。必须制定一个详细的进度表，以便监督项目进度并控制整个项目。进度安排通过把工作量分配给特定的软件工程任务并规定完成各项任务的起止日期，从而将估算出的项目工作量分布于计划好的项目持续期内。13.3进度计划(II)成本估算模型也同时提供了估算开发时间T的方程。例如：Walston_Felix模型T=2.5E0.35原始的COCOMO模型T=2.5E0.38COCOMO2模型T=3.0E0.33+0.2×(b-1.01)Putnam模型T=2.4E1/313.3.1估算开发时间(I)随着开发小组规模扩大，个人生产率将下降，以致开发时间与从事开发工作的人数并不成反比关系。主要有下述两个原因：增加了通信开销。新成员在开始时在学习期间还需要花费小组其他成员的时间。Brooks规律：向一个已经延期的项目增加人力，只会使得它更加延期。Boehm根据经验指出，软件项目的开发时间最多可以减少到正常开发时间的75%。如果要求一个软件系统的开发时间过短，则开发成功的概率几乎为零。13.3.1估算开发时间(II)Gantt（甘特）图是历史悠久、应用广泛的制定进度计划的工具。例：13.3.2Gantt图(I)p314-315假设有一座陈旧的矩形木板房需要重新油漆，分三步：1.首先刮掉旧漆2.然后刷上新漆3.最后清除溅在窗户上的油漆假设一共分配了15名工人完成这项工作，但工具都很有限：5把刮旧漆用的刮板，5把刷新漆用的刷子，5把清除溅在窗户上的油漆用的小刮刀。工序墙壁刮旧漆刷新漆清理1或32312或4462图13.1旧木板房刷漆工程的Gantt图13.3.2Gantt图(II)p314-315Gantt图也有3个主要缺点：不能显式地描绘各项作业彼此间的依赖关系；进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象；计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费。13.3.3工程网络(I)工程网络同样能描绘任务分解情况以及每项作业的开始时间和结束时间，它还描绘各个作业彼此间的依赖关系。工程网络是系统分析和系统设计的强有力的工具。在工程网络中用箭头表示作业用圆圈表示事件(一项作业开始或结束时间点)虚线箭头，它们表示虚拟作业，也就是事实上并不存在的作业。引入虚拟作业是为了显式地表示作业之间的依赖关系。13.3.3工程网络(II)13.3.3工程网络(III)12354768109111-2刮墙1旧漆；2-3刮墙2旧漆；3-5刮墙3旧漆；5-8刮墙4旧漆；2-4刷墙1新漆；4-6刷墙2新漆；6-8刷墙3新漆；8-10刷墙4新漆；4-7清理墙1；7-9清理墙2；9-10清理墙3；10-11清理墙4；虚拟作业：3-4；5-6；6-7；8-9把每个作业估计需要使用的时间写在表示该项作业的箭头上方。为事件计算最早时刻EET和最迟时刻LET计算最早时刻EET使用下述3条简单规则：考虑进入该事件的所有作业；每个作业都计算持续时间与起始事件EET之和；选取上述和数中最大值为该事件最早时刻EET。事件的最迟时刻是在不影响竣工时间的前提下，该事件最晚可以发生的时刻。其他事件的最迟时刻在工程网络上从右至左按逆作业流计算。计算最迟时刻LET使用下述3条规则：考虑离开该事件的所有作业；从每个作业的结束事件最迟时刻中减去该作业持续时间选取上述差数中的最小值作为该事件的最迟时刻LET。13.3.4估算工程进度(I)图13.3旧木板房刷漆工程的完整的工程网络13.3.4估算工程进度(II)图13.3中有几个事件的最早时刻和最迟时刻相同，这些事件定义了关键路径。关键路径上的事件必须准时发生，组成关键路径的作业的实际持续时间不能超过估计的持续时间，最早时刻和最迟时刻相同。工程项目的管理人员应该密切注视关键作业的进展情况，如果关键事件出现的时间比预计的时间晚，则会使最终完成项目的时间拖后；如果希望缩短工期，只有往关键作业中增加资源才会有效果。13.3.5关键路径一个作业可以有的全部机动时间等于它的结束事件的最迟时刻减去它的开始事件的最早时刻，再减去这个作业的持续时间：机动时间=(LET)结束-(EET)开始-持续时间对于前述油漆旧木板房的例子，计算得到的非关键作业的机动时间列在表13.6（见书318页）中。13.3.6机动时间结论：在制定进度计划时仔细考虑和利用工程网络中的机动时间，往往能够安排出既节省资源又不影响最终竣工时间的进度表。工程网络图PK甘特图：工程网络图可显式地定义事件及作业之间的依赖关系；而甘特图只能隐含表示这种关系。甘特图的形式比工程网络更简单更直观。可相互结合使用13.3.6机动时间（续）13.3.7项目计划(I)概述一般性地叙述开发项目，描述计划组织，并概述该文档其余部分的内容；阶段计划讨论项目开发周期——需求分析阶段、总体设计阶段、详细设计阶段等。详细说明每个阶段应完成的日期，并指出不同阶段可以互相重叠的时间等。组织计划规定从事该开发项目的每个小组的具体责任。测试计划概述应进行的测试和需要的工具，以及完成系统测试的过程和分工。变动控制计划确定在系统开发过程中需求变动时的管理控制机制。13.3.7项目计划(II)文档计划定义和管理与项目有关的文档。培训计划培训从事开发工作的程序员和使用系统的用户的计划。复审和报告计划讨论如何报告项目的状况，并确定对项目进展情况进行正式复审的计划。安装和运行计划描述在用户现场安装该系统的过程。资源和配置计划概述关键的细节计划——进度、里程碑和按合同规定应该交付的系统配置成分。定期把有关项目进展情况的信息反馈给管理人