情景3.1软件项目管理

《情景3.1软件项目管理》由会员分享，可在线阅读，更多相关《情景3.1软件项目管理（89页珍藏版）》请在金锄头文库上搜索。

1、情景3.1 软件项目管理,2,大型软件工程项目的失败 - 才使人们逐渐认识到软件项目管理的重要性和特殊性。 失败的原因 - 不是软发工程师无能，而主要是管理不善。 所谓管理 - 就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。 软件项目管理 - 先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。 软件项目管理 - 从一组项目计划活动开始，其基础是工作量估算和完成期限估算。,3,13.1 估算软件规模,13.1.1 代码行技术 代码行技术是比较简单的定量估算软件规模的方法。 为了使得对程序规模的估计值更接近实际值，可以由多名有经验的软件工程师分别做

2、出估计。每个人都估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)，分别算出这3种规模的平均值，再用下式计算程序规模的估计值 L = 单位是代码行数（LOC），或是千行代码数（KLOC）,4,代码行技术的主要优点：代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。 代码行技术的缺点： 源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模似乎不太合理；用不同语言实现同一个软件所需要的代码行数并不相同；这种方法不适用于非过程语言。 为了克服代码行技术的缺点，人们又提出了功能点技术。,5,13.1.2 功能点技术 功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算

3、软件规模。这种方法用功能点（FP）为单位度量软件规模。 1. 信息域特性 功能点技术定义了信息域的5个特性： （1） 输入项数(Inp) ： 用户向软件输入的项数，这些输入给软件提供面向应用的数据。输入不同于查询，后者单独计数，不计入输入项数中。 （2） 输出项数(Out) ： 软件向用户输出的项数，它们向用户提供面向应用的信息，例如，报表和出错信息等。报表内的数据项不单独计数。 （3） 查询数(Inq) ： 查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。 （4） 主文件数(Maf) ： 逻辑主文件（即数据的一个逻辑组合，它可能是大型数据库的一部分或是一个独立的文件）的数目。

4、 （5） 外部接口数(Inf) ： 机器可读的全部接口（例如，磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另一个系统。,6,2. 估算功能点的步骤 （1） 计算未调整的功能点数UFP 首先，把产品信息域的每个特性(即Inp、Out、Inq、Maf和Inf)都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数（例如，一个简单级的输入项分配3个功能点，一个平均级的输入项分配4个功能点，而一个复杂级的输入项分配6个功能点）。 然后，用下式计算未调整的功能点数UFP： UFP=a1Inp+a2Out+a3Inq+a4Maf+a5Inf 其中，ai(1i5)是信息域特性系数，

5、其值由相应特性的复杂级别决定，如表13.1（见书297页）所示。,7,(2) 计算技术复杂性因子TCF 这一步骤度量14种技术因素对软件规模的影响程度。这些因素包括高处理率、性能标准（例如，响应时间）、联机更新等，在表13.2（见书297页）中列出了全部技术因素，并用Fi(1i14)代表这些因素。根据软件的特点，为每个因素分配一个从0（不存在或对软件规模无影响）到5（有很大影响）的值。然后，用下式计算技术因素对软件规模的综合影响程度DI： DI= 技术复杂性因子TCF由下式计算： TCF=0.65+0.01DI 因为DI的值在070之间，所以TCF的值在0.651.35之间。,8,（3） 计算

6、功能点数FP 用下式计算功能点数FP： FP=UFPTCF 功能点数与所用的编程语言无关，看起来功能点技术比代码行技术更合理一些。但是，在判断信息域特性复杂级别和技术因素的影响程度时，存在着相当大的主观因素。,9,13.2 工作量估算 软件估算模型使用由经验导出的公式来预测软件开发工作量，工作量是软件规模（KLOC或FP）的函数，工作量的单位通常是人月（pm)。 支持大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的，因此，没有一个估算模型可以适用于所有类型的软件和开发环境。,10,13.2.1 静态单变量模型 这类模型的总体结构形式如下： E=A+B(ev)C 其中，A、B和C是

7、由经验数据导出的常数，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(KLOC)1.05 (4) Doty模型（在KLOC9时适用）: E=5.288(KLOC)1.047,11,2. 面向FP的估算模型 (1) Albrecht & Gaffney模型 E=-13.39+0.0545FP (2) Maston,Barn

8、ett和Mellichamp模型 E=585.7+15.12FP 从上面列出的模型可以看出，对于相同的KLOC或FP值，用不同模型估算将得出不同的结果。主要原因是，这些模型多数都是仅根据若干应用领域中有限个项目的经验数据推导出来的，适用范围有限。因此，必须根据当前项目的特点选择适用的估算模型，并且根据需要适当地调整（例如，修改模型常数）估算模型。,12,13.2.2 动态多变量模型 动态多变量模型也称为软件方程式，它是根据从4000多个当代软件项目中收集的生产率数据推导出来的。该模型把工作量看作是软件规模和开发时间这两个变量的函数。动态多变量估算模型的形式如下： E=(LOCB0.333/P)

9、3(1/t)4 (13.2) 其中， E是以人月或人年为单位的工作量； t是以月或年为单位的项目持续时间； B是特殊技术因子，它随着对测试、质量保证、文档及管理技术的需求的增加而缓慢增加，对于较小的程序（KLOC=515），B=0.16,对于超过70 KLOC的程序，B=0.39;,P是生产率参数，它反映了下述因素对工作量的影响： 总体过程成熟度及管理水平； 使用良好的软件工程实践的程度； 使用的程序设计语言的级别； 软件环境的状态； 软件项目组的技术及经验； 应用系统的复杂程度。 开发实时嵌入式软件时，P的典型值为2000；开发电信系统和系统软件时，P=10000；对于商业应用系统来说，P=

10、28000。可以从历史数据导出适用于当前项目的生产率参数值。 从（13.2）式可以看出，开发同一个软件（即LOC固定）的时候，如果把项目持续时间延长一些，则可降低完成项目所需的工作量。,13,13.2.3 COCOMO2模型,COCOMO是构造性成本模型（constructive cost model)的英文缩写。 1981年Boehm在软件工程经济学中首次提出了COCOMO模型。 1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修订版，它反映了十多年来在成本估计方面所积累的经验。,COCOMO2给出了3个层次的软件开发工作量估算模型，这3个层次的模型在估算工作量时

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

12、码行数（以千行为单位）， B 是模型指数， fi(i=117) 是成本因素。 每个成本因素都根据它的重要程度和对工作量影响大小被赋予一定数值（称为工作量系数）。这些成本因素对任何一个项目的开发工作量都有影响，即使不使用COCOMO2模型估算工作量，也应该重视这些因素。Boehm把成本因素划分成产品因素、平台因素、人员因素和项目因素等4类。 表13.3（见书300页）列出了COCOMO2模型使用的成本因素及与之相联系的工作量系数。,15,13.3 进度计划,项目管理者的目标是定义全部项目任务，识别出关键任务，跟踪关键任务的进展状况，以保证能及时发现拖延进度的情况。为达到上述目标，管理者必须制定一

13、个足够详细的进度表，以便监督项目进度并控制整个项目。 软件项目的进度安排是通过把工作量分配给特定的软件工程任务并规定完成各项任务的起止日期，从而将估算出的项目工作量分布于计划好的项目持续期内。 进度计划将随着时间的流逝而不断演化。在项目计划的早期，首先制定一个宏观的进度安排表，标识出主要的软件工程活动和这些活动影响到的产品功能。随着项目的进展，把宏观进度表中的每个条目都精化成一个详细进度表，从而标识出完成一个活动所必须实现的一组特定任务，并安排好了实现这些任务的进度。,16,软件开发小组人数与软件生产率的关系,当几个人共同承担软件开发项目中的某一任务时，人与人之间必须通过交流来解决各自承担任务

14、之间的接口问题，即所谓通信问题。通信需花费时间和代价，会引起软件错误增加，降低软件生产率。,17,若两个人之间需要通信，则称在这两个人之间存在一条通信路径。如果一个软件开发小组有 n 个人，每两人之间都需要通信，则总的通信路径有 n(n-1)/2 (条)。,18,设一个人单独开发软件，生产率是5000行人年。若 4 个人组成一个小组共同开发这个软件，则需要 6条通信路径。若在每条通信路径上耗费的工作量是 250 行人年。则小组中每个人的软件生产率降低为 500062504 = 5000375 = 4625 行人年。,19,从上述分析可知，一个软件任务由一个人单独开发，生产率最高；而对于一个稍大

15、型的软件项目，一个人单独开发，时间太长。因此软件开发小组是必要的。 但是，开发小组不宜太大，成员之间避免太多的通信路径。 在开发进程中，切忌中途加人，避免太多的生产率损失。,20,任务的确定与并行性,当参加同一软件工程项目的人数不止一人的时候，开发工作就会出现并行情形。 软件开发进程中设置许多里程碑。里程碑为管理人员提供了指示项目进度的可靠依据。 软件工程项目的并行性提出了一系列的进度要求。,21,22,因为并行任务是同时发生的，所以进度计划表必须决定任务之间的从属关系，确定各个任务的先后次序和衔接，确定各个任务完成的持续时间。 项目负责人应注意构成关键路径的任务，即若要保证整个项目能按进度要

16、求完成，就必须保证这些任务要按进度要求完成。,23,制定开发进度计划,402040规则 在整个软件开发过程中，编码工作量仅占 20，编码前工作量占40，编码后工作量占 40。 402040 规则只应用来做为 一个指南。实际的工作量分配比例必须按照各项目的特点来决定。,24,估算开发时间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/3 其中， E是开发工作量（以人月为单位）， T是开发时间（以月为单位）。,25,进度安排的方法,可以把用于一般开发项目的进度安排的技术和工具应用于软件项目。 为监控软件项目的进度计划和工作的实际进展情况，为表现各项任务之间进度的相互依赖关系，需要采用图示的方法。 在图示方法中，必须明确标明：,26,各个任务的计划开始时间