高级软件工程管理讲解

《高级软件工程管理讲解》由会员分享，可在线阅读，更多相关《高级软件工程管理讲解（140页珍藏版）》请在金锄头文库上搜索。

1、软件工程管理 1. 估算软件规模 2. 工作量估算 3. 进度计划 4. 人员组织 5. 质量保证 6. 软件配置管理 7. 能力成熟度模型 8. 小结 1 n大型软件项目的失败并不是由于软件工程师 的无能，其主要原因是管理不善。 n管理就是通过计划、组织和控制等一系列活 动，合理地配置和使用各种资源，以达到既定 目标的过程。 2 n软件项目管理先于任何技术活动之前开始， 并且贯穿于软件的整个生命周期之中。 n软件项目管理过程从一组项目计划活动开始 ，而制定计划的基础是工作量估算和完成期限 估算。 n为了估算项目的工作量和完成期限，首先需 要估算软件的规模。 3 1 估算软件规模 1.1 代码

2、行技术 n代码行技术是简单的定量估算软件规模的方 法。 n它依据开发类似产品的经验和历史数据，估 计实现一个功能所需要的源程序行数。 n在有大量数据时，这种方法估计出的数值还 是比较准确的。 n把实现每个功能所需要的源程序行数累加起 来，就可得到实现整个软件所需要的源程序行 数。 4 1.1 代码行技术 n为了使得对程序规模的估计值更接近实际值，可 以由多名有经验的软件工程师分别做出估计。 n分别估计程序的最小规模(a)、最大规模(b)和最 可能的规模(m)，算出这3种规模的平均值之后，再 用下式计算程序规模的估计值： L=(1) n当程序较小时常用的单位是代码行数（LOC）， 当程序较大时常

3、用的单位是千行代码数（KLOC）。 5 1.1 代码行技术 n代码行技术的优点是，代码是所有软件开发 项目都有的“产品”，而且很容易计算代码行数 。 n代码行技术的缺点是： n源程序仅是软件配置的一个成分，用它的规模代表 整个软件的规模似乎不太合理； n用不同语言实现同一个软件所需要的代码行数并不 相同； n这种方法不适用于非过程语言。 6 1.2 功能点技术(自学) n功能点技术依据对软件信息域特性和软件复 杂性的评估结果，估算软件规模。 n这种方法用功能点（FP）为单位度量软件规 模。 1. 信息域特性 n功能点技术定义了信息域的5个特性 u输入项数(Inp) u输出项数(Out) u查询

4、数(Inq) u主文件数(Maf) u外部接口数(Inf) 7 1.2 功能点技术 （1） 输入项数：用户向软件输入的项数，这些输入给软 件提供面向应用的数据。输入不同于查询，后者单独计数 ，不计入输入项数中。 （2） 输出项数：软件向用户输出的项数，它们向用户提 供面向应用的信息，例如，报表和出错信息等。报表内的 数据项不单独计数。 （3） 查询数：查询即是一次联机输入，它导致软件以联 机输出方式产生某种即时响应。 （4） 主文件数：逻辑主文件（即数据的一个逻辑组合， 它可能是大型数据库的一部分或一个独立的文件）的数目 。 （5） 外部接口数： 机器可读的全部接口（例如，磁盘 或磁带上的数据

5、文件）的数量，用这些接口把信息传送给 另一个系统。 8 1.2 功能点技术 2. 估算功能点的步骤 n用下述3个步骤，可估算出一个软件的功能点 数。 nStep1: 计算未调整的功能点数UFP nStep2: 计算技术复杂性因子TCF nStep3: 计算功能点数FP 9 1.2 功能点技术 （1） 计算未调整的功能点数UFP n把产品信息域的每个特性(即Inp、Out、Inq、Maf和 Inf)都分类为简单级、平均级或复杂级，并根据其等级 为每个特性分配一个功能点数。 n例如，一个简单级的输入项分配3个功能点，一个平均 级的输入项分配4个功能点，而一个复杂级的输入项分配 6个功能点。 n用下

6、式计算未调整的功能点数UFP： UFP=a1Inp+a2Out+a3Inq+a4Maf+a5Inf，其中 ，ai(1i5)是信息域特性系数，其值由相应特性的复 杂级别决定，如下表所示。 10 1.2 功能点技术 复杂级别 特性系数简单平均复杂 输入系数a1 346 输出系数a2 457 查询系数a3 346 文件系数a4 71015 接口系数a5 5710 11 1.2 功能点技术 (2) 计算技术复杂性因子TCF n度量14种技术因素对软件规模的影响程度。这些因素 包括高处理率、性能标准（例如，响应时间）、联机 更新等，并用Fi(1i14)代表这些因素。根据软件 的特点，为每个因素分配一个从

7、0（不存在或对软件规 模无影响）到5（有很大影响）的值。然后，用下式计 算技术因素对软件规模的综合影响程度DI： n DI= 12 1.2 功能点技术 n技术复杂性因子TCF由下式计算： TCF=0.65+0.01DI n因为DI的值在070之间，所以TCF的值在0.651.35之间。 （3） 计算功能点数FP n用下式计算功能点数FP： FP=UFPTCF n功能点数与所用的编程语言无关，似乎更合理一些。但是 ，在判断信息域特性复杂级别和技术因素的影响程度时，存 在着相当大的主观因素。 13 2 工作量估算 n软件估算模型使用由经验导出的公式来预测 软件开发工作量，工作量是软件规模（KLOC

8、或 FP）的函数，工作量的单位通常是人月（pm)。 n没有一个估算模型可以适用于所有类型的软 件和开发环境。 n要根据项目的特点选择合理的估算模型。 14 2.1 静态单变量模型 n这类模型的总体结构形式如下 E=A+B(ev)C n其中，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 (3) Boehm简单模型 E=3.2(K

9、LOC)1.05 (4) Doty模型（在KLOC9时适用） E=5.288(KLOC)1.047 15 2.1 静态单变量模型 2. 面向FP的估算模型（自学） (1) Albrecht nP生产率参数，它反映了下述因素对工作量的影 响： n总体过程成熟度及管理水平； n使用良好的软件工程实践的程度； n使用的程序设计语言的级别； n软件环境的状态； n软件项目组的技术及经验； n应用系统的复杂程度。 18 2.2 动态多变量模型 n开发实时嵌入式软件时，P的典型值为2000； 开发电信系统和系统软件时，P=10000；对于商 业应用系统来说，P=28000。 n可以从历史数据导出适用于当前

10、项目的生产 率参数值。 n开发同一个软件（即LOC固定）的时候，如果 把项目持续时间延长一些，则可降低完成项目 所需的工作量。 和时间 成反比 19 2.3 COCOMO2模型（自学） nCOCOMO是构造性成本模型（constructive cost model)的英文缩写。 n1981年Boehm在软件工程经济学中首次提 出了COCOMO模型。 n1997年Boehm等人提出的COCOMO2模型，是原 始的COCOMO模型的修订版，它反映了十多年来 在成本估计方面所积累的经验。 20 2.3 COCOMO2模型 nCOCOMO2给出了3个层次的软件开发工作量估 算模型。 n这3个层次的模型

11、在估算工作量时，对软件细 节考虑的详尽程度逐级增加。 n这些模型既可以用于不同类型的项目，也可 以用于同一个项目的不同开发阶段。 21 2.3 COCOMO2模型 n这3个层次的估算模型分别是： （1） 应用系统组成模型。它主要用于估算构建原型 的工作量，模型名字暗示在构建原型时大量使用已 有的构件。 （2） 早期设计模型。这个模型适用于体系结构设计 阶段。 （3） 后体系结构模型。这个模型适用于完成体系结 构设计之后的软件开发阶段。 22 2.3 COCOMO2模型 n以后体系结构模型为例，介绍COCOMO2模型。 该模型把软件开发工作量表示成代码行数（ KLOC）的非线性函数： n E=(

12、3) nE是开发工作量（以人月为单位），a是模型 系数，KLOC是估计的源代码行数（以千行为单 位），b是模型指数，fi(i=117)是成本因素。 23 2.3 COCOMO2模型 n工作量方程中模型系数a的典型值为3.0，在实 际工作中应该根据历史经验数据确定一个适合 本组织当前开发的项目类型的数值。 24 2.3 COCOMO2模型 n为了确定工作量方程中模型指数b的值，原始的COCOMO 模型把软件开发项目划分成组织式、半独立式和嵌入式 这样3种类型，并指定每种项目类型所对应的b值（分别 是1.05，1.12和1.20）。 nCOCOMO2采用了更加精细得多的b分级模型，这个模型 使用5

13、个分级因素Wi(1i5),其中每个因素都划分成 从甚低（Wi=5)到特高（Wi=0)的6个级别，然后用下式 计算b的数值： nb= nb的取值范围为1.011.26。这种分级模式比原始 COCOMO模型的分级模式更精细、更灵活。 25 2.3 COCOMO2模型 nCOCOMO2使用的5个分级因素如下所述： （1） 项目先例性。该因素指出，对于开发组织来说 该项目的新奇程度。诸如开发类似系统的经验，需要 创新体系结构和算法，以及需要并行开发硬件和软件 等因素的影响，都体现在这个分级因素中。 （2） 开发灵活性。这个分级因素反映出，为了实现 预先确定的外部接口需求及为了及早开发出产品而需 要增加

14、的工作量。 26 2.3 COCOMO2模型 （3） 风险排除度。这个分级因素反映了重大风险已 被消除的比例。在多数情况下，这个比例和指定了重 要模块接口（即选定了体系结构）的比例密切相关。 （4） 项目组凝聚力。这个分级因素表明了开发人员 相互协作时可能存在的困难。这个因素反映了开发人 员在目标和文化背景等方面相一致的程度，以及开发 人员组成一个小组工作的经验。 （5） 过程成熟度。这个分级因素反映了按照能力成 熟度模型度量出的项目组织的过程成熟度。 27 2.3 COCOMO2模型 n每个成本因素都根据它的重要程度和对工作量影响大 小被赋予一定数值（称为工作量系数）。这些成本因 素对任何一

15、个项目的开发工作量都有影响，即使不使 用COCOMO2模型估算工作量，也应该重视这些因素。 nBoehm把成本因素划分成产品因素、平台因素、人员 因素和项目因素等4类。 n与原始的COCOMO模型相比，COCOMO2模型使用的成本 因素有下述变化： 28 2.3 COCOMO2模型 （1） 新增加了4个成本因素。即可重用性、需要的文档量 、人员连续性（即人员稳定程度）和多地点开发。这个变 化表明，这些因素对开发成本的影响日益增加。 （2） 略去了原始模型中的2个成本因素（计算机切换时间 和使用现代程序设计实践）。并且在COCOMO2工作量方程的 指数b中考虑了这个因素的影响。 （3） 调整成本

16、因素的影响力。某些成本因素（分析员能 力、平台经验、语言和工具经验）对生产率的影响（即工 作量系数最大值与最小值的比率）增加了，另一些成本因 素（程序员能力）的影响减小了。 29 3 进度计划 n实际软件项目中，在实现一个大目标之前往往 必须完成数以百计的小任务。 n一些任务处于“关键路径”之外，其完成时间如 果没有严重拖后，都不会影响项目的完成时间； n另一些任务处于“关键路径”之中，如果这些“关 键任务”的进度拖后，则整个项目的完成日期就 会拖后。 n管理人员应该高度关注关键任务的进展情况。 30 3 进度计划 n一个有效的软件过程应该定义一个适用于当前项目的 任务集合。一个任务集合包括一组软件工程工作任务 、里程碑和可交付的产品。 n为一个项目所定义的任务集合，必须包括为获得高质 量的软件产品而应该完成的所有任务，但是同时又不 能让项目组承担不必要的工作