软件工程课件8软件项目管理

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

1、第13章 软件项目管理,孙 剑,13.1 软件项目管理概述 13.2 软件度量 13.3 进度计划 13.4 人力资源管理 13.5 质量管理 13.6 软件配置管理 13.7 软件过程管理,第13章 软件项目管理,13.1 软件项目管理概述,是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。,第13章 软件项目管理,软件项目管理的重要性,对软件项目的成功至关重要 软件项目涉及大量的人员和活动，有进度和资金限制，并会遇到各种变化、风险和矛盾，必须有良好的管理才能成功。 美国Standish Group于2003年的统计报告：分析了1

2、3522个项目，只有1/3成功，82%的项目延期，43%的项目超出预算。 导致项目失败的原因通常都与项目管理有关。,13.1 软件项目管理概述,软件项目管理的重要性,对提高软件开发人员的专业素质必不可少 适应团队开发 理解项目计划并胜任管理工作,理解软件项目在进度、成本、质量、人员等方面的计划和相应的措施，从而更有效地工作并为所在企业创造价值。 在管理岗位上更是需要项目管理能力,13.1 软件项目管理概述,项目管理的主要内容,美国项目管理协会(PMI)开发的项目管理知识体系指南将项目管理划分为9个知识领域：,13.1 软件项目管理概述,7,5个标准化过程组,13.1 软件项目管理概述,IT项目

3、的生命周期,对成本和工作人员的需求最初比较少，在向后发展过程中需要越来越多，当项目要结束时又会剧烈的减少。,时间,耗费,成本与时间的关系曲线,13.1 软件项目管理概述,各项指标与时间的关系曲线,早期投入对项目而言具有更高的价值 尽可能地先做技术难度高的事-辛苦在前，轻松在后 项目计划的重要性,时间,变更的成本,风险和 不确定性,增值的机会,13.1 软件项目管理概述,13.1 软件项目管理概述 13.2 软件度量 13.3 进度计划 13.4 人力资源管理 13.5 质量管理 13.6 软件配置管理 13.7 软件过程管理,第13章 软件项目管理,13.2 软件度量,软件度量（softwar

4、e measurement）是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制和改善。 软件规模的估计 工作量估算,第13章 软件项目管理,13.2.1 软件规模的估计,软件规模度量(size measurement)是估算软件项目工作量、编制成本预算、策划合理项目进度的基础。 规模度量是软件项目失败的重要原因之一。 软件规模的估算方法有很多种，如：功能点分析、代码行、德尔菲法、COCOMO模型、特征点、对象点、3-D功能点、标准构件法等，这些方法不断细化为更多具体的方法。,13.2 软件度量,代码行技术,代码行技术是比较简单的定

5、量估算软件规模的方法。 为了对程序规模的估计更接近实际值，可以由多名有经验的软件工程师分别做出估计。每个人都估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)，分别算出这3种规模的平均值，再用下式计算程序规模的估计值 单位是代码行数(LOC)，或是千行代码数(KLOC),13.2.1 软件规模的估计,代码行技术的优缺点,优点：代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。 缺点：源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模似乎不太合理；用不同语言实现同一个软件所需要的代码行数并不相同；这种方法不适用于非过程语言。 为克服代码行技术的缺点，提出了功能点技术

6、。,13.2.1 软件规模的估计,功能点技术,功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法用功能点（FP）为单位度量软件规模。,13.2.1 软件规模的估计,功能点技术,1. 信息域特性 功能点技术定义了信息域的5个特性： （1）输入项数(Inp) ：用户向软件输入的项数，这些输入给软件提供面向应用的数据。输入不同于查询，后者单独计数，不计入输入项数中。 （2）输出项数(Out) ：软件向用户输出的项数，它们向用户提供面向应用的信息，例如，报表和出错信息等。报表内的数据项不单独计数。 （3）查询数(Inq) ： 查询即是一次联机输入，它导致软件以联机输出方式产生

7、某种即时响应。,13.2.1 软件规模的估计,功能点技术,信息域特性 （4） 主文件数(Maf) ：逻辑主文件（即数据的一个逻辑组合，它可能是大型数据库的一部分或是一个独立的文件）的数目。 （5） 外部接口数(Inf) ：机器可读的全部接口（例如，磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另一个系统。,13.2.1 软件规模的估计,估算功能点的步骤,（1）计算未调整的功能点数UFP 首先把信息域的各特性(即Inp、Out、Inq、Maf和Inf)都分为简单级、平均级或复杂级，并根据等级为每个特性分配功能点数（例：简单级输入项分配3个功能点，平均级输入项分配4个功能点，而复杂级输入项

8、分配6个功能点）。 然后，用下式计算未调整的功能点数UFP： UFP=a1Inp+a2Out+a3Inq+a4Maf+a5Inf 其中，ai(1i5)是信息域特性系数，其值由相应特性的复杂级别决定，如表13.1（见书307页）所示。,13.2.1 软件规模的估计,估算功能点的步骤,(2) 计算技术复杂性因子TCF 这一步骤度量14种技术因素对软件规模的影响程度。这些因素包括高处理率、性能标准（如响应时间）、联机更新等，在表13.2（P307）中列出了全部技术因素，并用Fi(1i14)代表这些因素。根据软件特点，为每个因素分配一个从0（不存在或对软件规模无影响）到5（有很大影响）的值。然后，用下

9、式计算技术因素对软件规模的综合影响程度DI： 技术复杂性因子TCF由下式计算： TCF=0.65+0.01DI 因为DI的值在070之间，所以TCF的值在0.651.35之间。,13.2.1 软件规模的估计,估算功能点的步骤,（3）计算功能点数FP 用下式计算功能点数FP： FP=UFPTCF 功能点数与所用的编程语言无关，看起来功能点技术比代码行技术更合理一些。但是，在判断信息域特性复杂级别和技术因素的影响程度时，存在着相当大的主观因素。,13.2.1 软件规模的估计,13.2.2 工作量估算,软件估算模型使用由经验导出的公式来预测软件开发工作量，工作量是软件规模（KLOC或FP）的函数，工

10、作量的单位通常是人月（pm)。 支持大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的，因此，没有一个估算模型可以适用于所有类型的软件和开发环境。,13.2 软件度量,1) 静态单变量模型,模型总体结构： 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 (3) Boehm简单模型: E=3.2(KLOC)1.05 (4)

11、Doty模型(在KLOC9时适用): E=5.288(KLOC)1.047,13.2.2 工作量估算,1) 静态单变量模型,2. 面向FP的估算模型 (1)Albrecht & Gaffney模型: E=-13.39+0.0545FP (2)Maston,Barnett和Mellichamp模型: E=585.7+15.12FP 从上述模型可看出，对于相同的KLOC或FP值，用不同模型估算将得出不同结果。主要原因是，这些模型多数都是仅根据若干应用领域中有限个项目的经验数据推导出来的，适用范围有限。因此，必须根据当前项目的特点选择适用的估算模型，并且根据需要适当地调整（如修改模型常数）估算模型。

12、,13.2.2 工作量估算,2) 动态多变量模型,也称为软件方程式，它根据从4000多个当代软件项目中收集的生产率数据推导而来。该模型把工作量看作是软件规模和开发时间这两个变量的函数。动态多变量估算模型的形式如下： E=(LOCB0.333/P)3(1/t)4 (13.2) 其中， E是以人月或人年为单位的工作量； t是以月或年为单位的项目持续时间； B是特殊技术因子，它随着对测试、质量保证、文档及管理技术的需求的增加而缓慢增加，对于较小的程序（KLOC=515），B=0.16,对于超过70 KLOC的程序，B=0.39;,13.2.2 工作量估算,2) 动态多变量模型,E=(LOCB0.33

13、3/P)3(1/t)4 (13.2) P是生产率参数，它反映了下述因素对工作量的影响： 总体过程成熟度及管理水平； 使用良好的软件工程实践的程度； 使用的程序设计语言的级别； 软件环境的状态； 软件项目组的技术及经验； 应用系统的复杂程度。 开发实时嵌入式软件时，P的典型值为2000；开发电信系统和系统软件时，P=10000；对于商业应用系统来说，P=28000。可以从历史数据导出适用于当前项目的生产率参数值。 从（13.2）式可以看出，开发同一个软件（即LOC固定）的时候，如果把项目持续时间延长一些，则可降低完成项目所需的工作量。,13.2.2 工作量估算,26,3) COCOMO2模型,C

14、OCOMO是构造性成本模型（constructive cost model)的英文缩写。 1981年Boehm在软件工程经济学中首次提出了COCOMO模型。 1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修订版，它反映了十多年来在成本估计方面所积累的经验。,13.2.2 工作量估算,COCOMO2给出了3个层次的软件开发工作量估算模型，这3个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。该模型既可以用于不同类型的项目，也可以用于同一个项目的不同开发阶段。这3个层次的估算模型分别是 （1）应用系统组成模型。该模型主要用于估算构建原型的工作量，模型名字暗

15、示在构建原型时大量使用已有的构件。 （2）早期设计模型。该模型适用于体系结构设计阶段。 （3）后体系结构模型。该模型适用于完成体系结构设计之后的软件开发阶段。,13.2.2 工作量估算,3) COCOMO2模型,下面以后体系结构模型为例，介绍COCOMO2模型。该模型把软件开发工作量表示成代码行数（KLOC）的非线性函数： (13.3) 其中: E 是开发工作量（以人月为单位）， A 是模型系数， KLOC 是估计的源代码行数（以千行为单位）， B 是模型指数， fi(i=117) 是成本因素。,13.2.2 工作量估算,3) COCOMO2模型,29,每个成本因素都根据它的重要程度和对工作量

16、影响大小被赋予一定数值（称为工作量系数）。这些成本因素对任何一个项目的开发工作量都有影响，即使不使用COCOMO2模型估算工作量，也应该重视这些因素。Boehm把成本因素划分成产品因素、平台因素、人员因素和项目因素等4类。 表13.3（见书310页）列出了COCOMO2模型使用的成本因素及与之相联系的工作量系数。,13.2.2 工作量估算,3) COCOMO2模型,13.1 软件项目管理概述 13.2 软件度量 13.3 进度计划 13.4 人力资源管理 13.5 质量管理 13.6 软件配置管理 13.7 软件过程管理,第13章 软件项目管理,13.3 进度计划,进度管理概述 软件项目任务分解 活动定义和排序 活动历时估计 制定进度计划 进度控制（项目跟踪）,第13章 软件项目管理,13.3.1 进度管理概述,进度是对执行的活动和里程碑所制定的工作计划日期表。 进度管理是为了确保项目按期完成所需要的管理过程。,13.3 进度计划,进度管理的重要性和复杂性,按时完成项目是项目经理最大