《[软工导论]第13章软件项目管理》由会员分享，可在线阅读，更多相关《[软工导论]第13章软件项目管理（160页珍藏版）》请在金锄头文库上搜索。
1、第13章 软件项目管理,13.1 估算软件规模13.2 工作量估算13.3 进度计划13.4 人员组织13.5 质量保证,13.6 软件配置管理13.7 能力成熟度模型13.8 小结习题,在经历了若干个大型软件工程项目的失败之后，人们才逐渐认识到软件项目管理的重要性和特殊性。事实上，这些项目的失败并不是由于从事软件开发工作的软件工程师无能，正相反，他们之中的绝大多数是当时杰出的技术专家。这些工程项目的失败主要是因为管理不善。所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。,软件项目管理先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。软件
2、项目管理过程从一组项目计划活动开始，而制定计划的基础是工作量估算和完成期限估算。为了估算项目的工作量和完成期限，首先需要估算软件的规模。,代码行技术是比较简单的定量估算软件规模的方法。这种方法依据以往开发类似产品的经验和历史数据，估计实现一个功能所需要的源程序行数。当有以往开发类似产品的历史数据可供参考时，用这种方法估计出的数值还是比较准确的。把实现每个功能所需要的源程序行数累加起来，就可得到实现整个软件所需要的源程序行数。,13.1 估算软件规模 13.1.1 代码行技术,为了使得对程序规模的估计值更接近实际值，可以由多名有经验的软件工程师分别做出估计。每个人都估计程序的最小规模(a)、最大
3、规模(b)和最可能的规模(m)，分别算出这3种规模的平均值,和之后，再用下式计算程序规模的估计值：L=(13.1)用代码行技术估算软件规模时，当程序较小时常用的单位是代码行数（LOC），当程序较大时常用的单位是千行代码数（KLOC）。,代码行技术的主要优点是，代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。代码行技术的缺点是： 源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模似乎不太合理；用不同语言实现同一个软件所需要的代码行数并不相同；这种方法不适用于非过程语言。为了克服代码行技术的缺点，人们又提出了功能点技术。,功能点技术依据对软件信息域特性和软件复杂性的评估结果，
4、估算软件规模。这种方法用功能点（FP）为单位度量软件规模。1. 信息域特性功能点技术定义了信息域的5个特性，分别是输入项数(Inp)、输出项数(Out)、查询数(Inq)、主文件数(Maf)和外部接口数(Inf)。下面讲述这5个特性的含义。,13.1.2 功能点技术,（1） 输入项数： 用户向软件输入的项数，这些输入给软件提供面向应用的数据。输入不同于查询，后者单独计数，不计入输入项数中。（2） 输出项数： 软件向用户输出的项数，它们向用户提供面向应用的信息，例如，报表和出错信息等。报表内的数据项不单独计数。（3） 查询数： 查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。（4
5、） 主文件数： 逻辑主文件（即数据的一个逻辑组合，它可能是大型数据库的一部分或是一个独立的文件）的数目。,（5） 外部接口数： 机器可读的全部接口（例如，磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另一个系统。2. 估算功能点的步骤用下述3个步骤，可估算出一个软件的功能点数（即软件规模）。,（1） 计算未调整的功能点数UFP首先，把产品信息域的每个特性(即Inp、Out、Inq、Maf和Inf)都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数（例如，一个简单级的输入项分配3个功能点，一个平均级的输入项分配4个功能点，而一个复杂级的输入项分配6个功能点）。然后，用
6、下式计算未调整的功能点数UFP： UFP=a1Inp+a2Out+a3Inq+a4Maf+a5Inf其中，ai(1i5)是信息域特性系数，其值由相应特性的复杂级别决定，如表13.1（见书297页）所示。,(2) 计算技术复杂性因子TCF这一步骤度量14种技术因素对软件规模的影响程度。这些因素包括高处理率、性能标准（例如，响应时间）、联机更新等，在表13.2（见书297页）中列出了全部技术因素，并用Fi(1i14)代表这些因素。根据软件的特点，为每个因素分配一个从0（不存在或对软件规模无影响）到5（有很大影响）的值。然后，用下式计算技术因素对软件规模的综合影响程度DI： DI=,技术复杂性因子T
7、CF由下式计算： TCF=0.65+0.01DI因为DI的值在070之间，所以TCF的值在0.651.35之间。（3） 计算功能点数FP用下式计算功能点数FP： FP=UFPTCF功能点数与所用的编程语言无关，看起来功能点技术比代码行技术更合理一些。但是，在判断信息域特性复杂级别和技术因素的影响程度时，存在着相当大的主观因素。,软件估算模型使用由经验导出的公式来预测软件开发工作量，工作量是软件规模（KLOC或FP）的函数，工作量的单位通常是人月（pm)。支持大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的，因此，没有一个估算模型可以适用于所有类型的软件和开发环境。,13.2 工作
8、量估算,这类模型的总体结构形式如下： E=A+B(ev)C其中，A、B和C是由经验数据导出的常数，E是以人月为单位的工作量，ev是估算变量（KLOC或FP）。下面给出几个典型的静态单变量模型。1. 面向KLOC的估算模型(1) Walston_Felix模型E=5.2(KLOC)0.91(2) Bailey_Basili模型E=5.5+0.73(KLOC)1.16,13.2.1 静态单变量模型,(3) Boehm简单模型E=3.2(KLOC)1.05(4) Doty模型（在KLOC9时适用）E=5.288(KLOC)1.0472. 面向FP的估算模型(1) Albrecht & Gaffney
9、模型E=-13.39+0.0545FP(2) Maston,Barnett和Mellichamp模型E=585.7+15.12FP,从上面列出的模型可以看出，对于相同的KLOC或FP值，用不同模型估算将得出不同的结果。主要原因是，这些模型多数都是仅根据若干应用领域中有限个项目的经验数据推导出来的，适用范围有限。因此，必须根据当前项目的特点选择适用的估算模型，并且根据需要适当地调整（例如，修改模型常数）估算模型。,动态多变量模型也称为软件方程式，它是根据从4000多个当代软件项目中收集的生产率数据推导出来的。该模型把工作量看作是软件规模和开发时间这两个变量的函数。动态多变量估算模型的形式如下：
10、E=(LOCB0.333/P)3(1/t)4(13.2)其中，E是以人月或人年为单位的工作量；t是以月或年为单位的项目持续时间；,13.2.2 动态多变量模型,B是特殊技术因子，它随着对测试、质量保证、文档及管理技术的需求的增加而缓慢增加，对于较小的程序（KLOC=515），B=0.16,对于超过70 KLOC的程序，B=0.39;P是生产率参数，它反映了下述因素对工作量的影响： 总体过程成熟度及管理水平；使用良好的软件工程实践的程度；使用的程序设计语言的级别；软件环境的状态；软件项目组的技术及经验；,应用系统的复杂程度。开发实时嵌入式软件时，P的典型值为2000；开发电信系统和系统软件时，P
11、=10000；对于商业应用系统来说，P=28000。可以从历史数据导出适用于当前项目的生产率参数值。从（13.2）式可以看出，开发同一个软件（即LOC固定）的时候，如果把项目持续时间延长一些，则可降低完成项目所需的工作量。,COCOMO是构造性成本模型（constructive cost model)的英文缩写。1981年Boehm在软件工程经济学中首次提出了COCOMO模型，本书第三版曾对此模型作了介绍。1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修订版，它反映了十多年来在成本估计方面所积累的经验。,13.2.3 COCOMO2模型,COCOMO2给出了3个层
12、次的软件开发工作量估算模型，这3个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。这些模型既可以用于不同类型的项目，也可以用于同一个项目的不同开发阶段。这3个层次的估算模型分别是： （1） 应用系统组成模型。这个模型主要用于估算构建原型的工作量，模型名字暗示在构建原型时大量使用已有的构件。（2） 早期设计模型。这个模型适用于体系结构设计阶段。（3） 后体系结构模型。这个模型适用于完成体系结构设计之后的软件开发阶段。,下面以后体系结构模型为例，介绍COCOMO2模型。该模型把软件开发工作量表示成代码行数（KLOC）的非线性函数： E=(13.3)其中，E是开发工作量（以人月为单位），
13、a是模型系数，KLOC是估计的源代码行数（以千行为单位），b是模型指数，fi(i=117)是成本因素。,每个成本因素都根据它的重要程度和对工作量影响大小被赋予一定数值（称为工作量系数）。这些成本因素对任何一个项目的开发工作量都有影响，即使不使用COCOMO2模型估算工作量，也应该重视这些因素。Boehm把成本因素划分成产品因素、平台因素、人员因素和项目因素等4类。表13.3（见书300页）列出了COCOMO2模型使用的成本因素及与之相联系的工作量系数。与原始的COCOMO模型相比，COCOMO2模型使用的成本因素有下述变化，这些变化反映了在过去十几年中软件行业取得的巨大进步。,（1） 新增加了
14、4个成本因素，它们分别是要求的可重用性、需要的文档量、人员连续性（即人员稳定程度）和多地点开发。这个变化表明，这些因素对开发成本的影响日益增加。（2） 略去了原始模型中的2个成本因素（计算机切换时间和使用现代程序设计实践）。现在，开发人员普遍使用工作站开发软件，批处理的切换时间已经不再是问题。而“现代程序设计实践”已经发展成内容更广泛的“成熟的软件工程实践”的概念，并且在COCOMO2工作量方程的指数b中考虑了这个因素的影响。,（3） 某些成本因素（分析员能力、平台经验、语言和工具经验）对生产率的影响（即工作量系数最大值与最小值的比率）增加了，另一些成本因素（程序员能力）的影响减小了。为了确定
15、工作量方程中模型指数b的值，原始的COCOMO模型把软件开发项目划分成组织式、半独立式和嵌入式这样3种类型，并指定每种项目类型所对应的b值（分别是1.05，1.12和1.20）。COCOMO2采用了更加精细得多的b分级模型，这个模型使用5个分级因素Wi(1i5),其中每个因素都划分成从甚低（Wi=5)到特高（Wi=0)的6个级别，然后用下式计算b的数值：,b=(13.4)因此，b的取值范围为1.011.26。显然，这种分级模式比原始COCOMO模型的分级模式更精细、更灵活。COCOMO2使用的5个分级因素如下所述： （1） 项目先例性。这个分级因素指出，对于开发组织来说该项目的新奇程度。诸如开
16、发类似系统的经验，需要创新体系结构和算法，以及需要并行开发硬件和软件等因素的影响，都体现在这个分级因素中。,（2） 开发灵活性。这个分级因素反映出，为了实现预先确定的外部接口需求及为了及早开发出产品而需要增加的工作量。（3） 风险排除度。这个分级因素反映了重大风险已被消除的比例。在多数情况下，这个比例和指定了重要模块接口（即选定了体系结构）的比例密切相关。（4） 项目组凝聚力。这个分级因素表明了开发人员相互协作时可能存在的困难。这个因素反映了开发人员在目标和文化背景等方面相一致的程度，以及开发人员组成一个小组工作的经验。,（5） 过程成熟度。这个分级因素反映了按照能力成熟度模型（见13.7节）度量出的项目组织的过程成熟度。在原始的COCOMO模型中，仅粗略地考虑了前两个分级因素对指数b之值的影响。工作量方程中模型系数a的典型值为3.0，在实际工作中应该根据历史经验数据确定一个适合本组织当前开发的项目类型的数值。,
