第13章软件项目管理.pptxVIP

第13章 软件项目管理;目标;项目失败：72% 失败的主要表现： 32%项目开始后不久取消 40%项目延期，超支等 项目失败的主要原因 需求不清晰 项目规模估计不足 进度计划安排不合理 没有进行很好的质量保证;管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。 软件项目管理先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。;13.1.1 代码行技术 13.1.2 功能点技术;用历史类似产品估计某一个功能需要的代码行数。 把实现每个功能所需要的源程序???数累加起来，就可得到实现整个软件所需要的源程序行数。 为了使得对程序规模的估计值更接近实际值，可以由多名有经验的软件工程师分别做出估计。;每个人都估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)，分别算出这3种规模的平均值、和之后，再用下式计算程序规模的估计值： L= (13.1) ;优点：代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。 缺点： 源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模似乎不太合理； 用不同语言实现同一个软件所需要的代码行数并不相同；这种方法不适用于非过程语言。为了克服代码行技术的缺点，人们又提出了功能点技术。;CAD系统经过分解, 识别出下列主要软件功能： 用户界面和控制功能 二维几何分析 三维几何分析 数据库管理 计算机图形显示功能 外设控制PC 设计分析模块 通过分解，可得到如下估算表;估算表;功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法用功能点（FP）为单位度量软件规模。 信息域特性 输入项数(Inp) 输出项数(Out) 查询数(Inq) 主文件数(Maf) 外部接口数(Inf);估算功能点的步骤 计算未调整的功能点数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.2.1 静态单变量模型 13.2.2 动态多变量模型 13.2.3 COCOMO2模型;面向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.047;面向FP的估算模型 (1) Albrecht Gaffney模型 E=-13.39+0.0545FP Maston,Barnett和Mellichamp模型 E=585.7+15.12FP;动态多变量模型是根据从4000多个当代软件项目中收集的生产率数据推导出来的。 该模型把工作量看作是软件规模和开发时间这两个变量的函数。动态多变量估算模型的形式如下： E=(LOC×B0.333/P)3×(1/t)4 E是以人月或人年为单位的工作量； t是以月或年为单位的项目持续时间； B是特殊技术因子 P是生产率参数;COCOMO是构造性成本模型（constructive cost model)的英文缩写。 1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修订版，它反映了十多年来在成本估计方面所积累的经验。;COCOMO2给出了3个层次的软件开发工作量估算模型，这3个层次的估算模型分别是： 应用系统组成模型。用于估算构建原型的工作量 早期设计模型。用于体系结构设计阶段。 后体系结构模型。用于完成体系结构设计之后的软件开发阶段。;下面以后体系结构模型为例，介绍COCOMO2模型。该模型把软件开发工作量表示成代码行数（KLOC）的非线性函数： E= (13.3) E是开发工作量（以人月为单位）， a是模型系数， KLOC是估计的源代码行数（以千行为单位）， b是模型指数， fi(i=1~17)是成本因素。(表13.3（见书300页）);Boehm把成本因素划分成产品因素、平台因素、人员因素和项目因素等4类。 COCOMO2模型的变化 新增加了4个成本因素：分别是要求的可重用性、需要的文档量、人员连续性和多地点开发。 略去了原始模型中的2个成本因素 某些成本因