软件工程

工程项目的失败主要不是技术和经验，是因为管理不善软件项目管理。所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。软件项目管理过程从一组项目计划活动开始，而制定计划的基础是工作量估算和完成期限估算。为了估算项目的工作量和完成期限，首先需要估算软件的规模。第13章软件项目管理第13章软件项目管理13.1估算软件规模13.2工作量估算13.3进度计划13.4人员组织13.5质量保证13.6软件配置管理13.7能力成熟度模型13.1估算软件规模13.1.1代码行技术代码行技术是比较简单的定量估算软件规模的方法。这种方法依据以往开发类似产品的经验和历史数据，估计实现一个功能所需要的源程序行数。当有以往开发类似产品的历史数据可供参考时，用这种方法估计出的数值还是比较准确的。把实现每个功能所需要的源程序行数累加起来，就可得到实现整个软件所需要的源程序行数。为了使得对程序规模的估计值更接近实际值，可以由多名有经验的软件工程师分别做出估计。(13.1)每个人都估计：a~程序的最小规模、b~最大规模；m~最可能的规模。再用上式计算程序规模的估计值。用代码行技术估算软件规模时，当程序较小时常用的单位是代码行数（LOC），当程序较大时常用的单位是千行代码数（KLOC）。13.1.1代码行技术64bmaL代码行技术的主要优点：容易计算行数。代码行技术的缺点是：源程序代表整个软件的规模不太合理；代码行数于实现的语言有关；不适用于非过程语言。为了克服代码行技术的缺点，人们又提出了功能点技术。13.1.1代码行技术根据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法用功能点（FP）为单位度量软件规模。1.信息域特性功能点技术定义了信息域的5个特性，分别是输入项数(Inp)、输出项数(Out)、查询数(Inq)、主文件数(Maf)和外部接口数(Inf)。下面讲述这5个特性的含义。上述5项的含义见教材。13.1.2功能点技术2.估算功能点的步骤用下述3个步骤，可估算出一个软件的功能点数（即软件规模）：（1）第1步：计算未调整的功能点数UFP把产品信息域的每个特性(Inp、Out、Inq、Maf、Inf)都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数（例如：一个简单级的输入项分配3个功能点，一个平均级的输入项分配4个功能点，一个复杂级的输入项分配6个功能点）。13.1.2功能点技术然后，用下式计算未调整的功能点数UFP：UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf其中，ai(1≤i≤5)是信息域特性系数，其值由相应特性的复杂级别决定，如表13.1所示。13.1.2功能点技术(2)第2步：计算技术复杂性因子TCF度量对软件规模有影响的14种技术因素：如高处理率、性能标准（例响应时间）、联机更新等（见表13.2中列出了全部技术因素），用Fi(1≤i≤14)代表这些因素。根据软件的特点，为每个因素分配一个从0~5的值（0为不存在或对软件规模无影响，5有很大影响），然后用下式计算技术因素对软件规模的综合影响程度DI：141iiFDI13.1.2功能点技术计算技术复杂性因子TCF：TCF=0.65+0.01×DI因为DI的值在0~70之间，所以TCF的值在0.65~1.35之间。（3）第3步：计算功能点数FPFP=UFP×TCF功能点数与所用的编程语言无关。优点：功能点技术比代码行技术更合理一些；缺点：在判断信息域特性复杂级别和技术因素的影响程度时，存在着相当大的主观因素。13.1.2功能点技术13.2工作量估算工作量是软件规模（KLOC或FP）的函数，工作量的单位通常是人月(pm)。工作量估算模型只适应于特定的软件项目，没有一个估算模型可以适用于所有类型的软件和开发环境。具体选优那种模型，视软件类型而定。这类模型的总体结构形式如下：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.1613.2.1静态单变量模型(3)Boehm简单模型E=3.2×(KLOC)1.05(4)Doty模型（在KLOC9时适用）E=5.288×(KLOC)1.0472.面向FP的估算模型(1)Albrecht&Gaffney模型E=-13.39+0.0545FP(2)Maston,Barnett和Mellichamp模型E=585.7+15.12FP13.2.1静态单变量模型从上面各模型，对于相同的KLOC或FP值，不同模型估算将得出不同的结果。原因：这些模型多数都是仅根据若干应用领域中有限个项目的经验数据推导出来的，适用范围有限。因此，必须根据当前项目的特点选择适用的估算模型，并且根据需要适当地调整（例如，修改模型常数）估算模型。13.2.1静态单变量模型动态多变量模型也称为软件方程式，该模型把工作量(E)看作是软件规模(LOC)和开发时间(t)这两个变量的函数：E=(LOC×B0.333/P)3×(1/t)4(13.2)E~以人月或人年为单位的工作量；t~以月或年为单位的项目持续时间；B~特殊技术因子，它随着对测试、质量保证、文档及管理技术的需求的增加而缓慢增加，对于较小的程序（KLOC=5~15），B=0.16，对于超过70KLOC的程序，B=0.39;13.2.2动态多变量模型P是生产率参数，它反映了下述因素对工作量的影响：总体过程成熟度及管理水平；使用良好的软件工程实践的程度；使用的程序设计语言的级别；软件环境的状态；软件项目组的技术及经验；应用系统的复杂程度。13.2.2动态多变量模型开发实时嵌入式软件时，P的典型值为2000；开发电信系统和系统软件时，P=10000；对于商业应用系统来说，P=28000。可以从历史数据导出适用于当前项目的生产率参数值。从（13.2）式可以看出，开发同一个软件（即LOC固定）的时候，如果把项目持续时间延长一些，则可降低完成项目所需的工作量。13.2.2动态多变量模型13.2.3COCOMO2模型COCOMO~COnstructiveCOstMOdel，构造性成本模型。1981年Boehm在《软件工程经济学》中首次提出了COCOMO模型，1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修订版，它反映了十多年来在成本估计方面所积累的经验。本教材在介绍COCOMO2模型时，比较COCOMO模型进行。13.2.3COCOMO2模型COCOMO2给出了3个层次的软件开发工作量估算模型，在估算工作量时，对软件细节考虑的详尽程度逐级增加。3个层次的估算模型分别是：（1）应用系统组成模型这个模型主要用于估算构建原型的工作量，模型名字暗示在构建原型时大量使用已有的构件。（2）早期设计模型这个模型适用于体系结构设计阶段。（3）后体系结构模型这个模型适用于完成体系结构设计之后的软件开发阶段。13.2.3COCOMO2模型以后体系结构模型为例介绍COCOMO2模型:将软件开发工作量(E)表示成代码行数(KLOC)的非线性函数：(13.3)E~开发工作量(以人月为单位)a~模型系数KLOC~千行源代码b~模型指数fi(i=1~17)~成本因素。171iibfKLOCaE13.2.3COCOMO2模型每个成本因素都根据它的重要程度和对工作量影响大小被赋予一定数值（称为工作量系数）.这些成本因素对任何一个项目的开发工作量都有影响，成本因素包括：产品因素、平台因素、人员因素和项目因素等4类。表13.3列出了COCOMO2模型使用的成本因素及与之相联系的工作量系数。与原始的COCOMO模型相比，COCOMO2模型使用的成本因素有变化，反映了在过去十几年中软件行业取得的巨大进步。13.2.3COCOMO2模型（1）新增加了4个成本因素：可重用性、需要的文档量、人员连续性（即人员稳定程度）和多地点开发。这个变化表明，这些因素对开发成本的影响日益增加。（2）略去了原始模型中的2个成本因素（计算机切换时间和使用现代程序设计实践）。现在，开发人员普遍使用工作站开发软件，批处理的切换时间已经不再是问题。而“现代程序设计实践”已经发展成内容更广泛的“成熟的软件工程实践”的概念，并且在COCOMO2工作量方程的指数b中考虑了这个因素的影响。13.2.3COCOMO2模型（3）某些成本因素（分析员能力、平台经验、语言和工具经验）对生产率的影响（即工作量系数最大值与最小值的比率）增加了，另一些成本因素（程序员能力）的影响减小了。为了确定工作量方程中模型指数b的值：COCOMO模型：把软件开发项目划分成组织式、半独立式和嵌入式这样3种类型，并指定每种项目类型所对应的b值(分别是1.05,1.12,1.20);COCOMO2模型：使用5个分级因素Wi(1≤i≤5),每个因素都划分成从甚低（Wi=5)到特高（Wi=0)的6个级别，然后用下式计算b的数值：13.2.3COCOMO2模型b=(13.4)b的取值范围为1.01~1.26。这种分级模式比原始COCOMO模型的分级模式更精细、更灵活。5101.101.1iiW13.2.3COCOMO2模型COCOMO2使用的5个分级因素如下所述：（1）项目先例性反映项目的新奇程度。诸如开发类似系统的经验，需要创新体系结构和算法，以及需要并行开发硬件和软件等因素的影响，都体现在这个分级因素中。（2）开发灵活性反映出为了实现预先确定的外部接口需求及为了及早开发出产品而需要增加的工作量。13.2.3COCOMO2模型（3）风险排除度反映了重大风险已被消除的比例。（4）项目组凝聚力表明了开发人员相互协作时可能存在的困难。这个因素反映了开发人员在目标和文化背景等方面相一致的程度，以及开发人员组成一个小组工作的经验。5）过程成熟度反映了按照能力成熟度模型（见13.7节）度量出的项目组织的过程成熟度。13.3进度计划任何工作均可分为若干个小任务，有一些任务处于“关键路径”（13.3.5）之外，对整个项目的完成时间影响小；一些任务处于关键路径之中，对整个项目的完成日期影响大。项目管理者的目标识别并跟踪关键任务的进展状况，以保证能及时发现拖延进度的情况。为达到上述目标，管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。进度是需要随着项目进展不断细化、完善的。估算总工作量之后需要回答：项目的开发时间？对于一个估计工作量为20人月的项目，可能想出下列几种进度表：1个人用20个月完成该项目；4个人用5个月完成该项目；20个人用1个月完成该项目。不现实，软件开发时间与人数之间并不是简单的反比关系。13.3.1估算开发时间通常，成本估算模型也同时提供了估算开发时间T的方程。例如：(1)Walston_Felix模型T=2.5E0.35(2)原始的COCOMO模型T=2.5E0.38(3)COCOMO2模型T=3.0E0.33+0.2×(b-1.01)(4)Putnam模型T=2.4E1/3E~开发工作量（以人月为单位），T~开发时间（以月为单位）。13.3.1估算开发时间为了缩短开发时间应该增加从事开发工作的人数。但是，经验告诉我们，随着开发小组规模扩大，个人生产率将下降，以致开发时间与从事开发工作的人数并不成反比关系。出现上述现象主要有下述两个原因：当小组变得更大时，每个人需要用更多时间与组内其他成员讨论问题、协调工作，因此增加了通信开销。13.3.1估算开发时间如果在开发过程中增加小组人员，则最初一段时间内项目组总生产率不仅不会提高反而会下降。这是因为新成员在开始时不仅不是生产力，而且在他们学习期间还需要花费小组其他成员的时间。综合上述两个原因，存在被称为Brooks规律的下述现象：向一个已经延期的项