spm-软件工作量估算

《spm-软件工作量估算》由会员分享，可在线阅读，更多相关《spm-软件工作量估算（59页珍藏版）》请在金锄头文库上搜索。

1、软件工作量估算,软件项目的规模估算,确定了软件项目开发的生命周期模型，进行了工作任务分解，就建立了一个项目任务整体的框架结构。 另外一方面，一个良好的软件项目计划的建立，还必须估算准备开发的软件项目的任务大小、资源情况、投入的成本、限制因素等，进行充分的估算，最后，根据估算，才能制定出合理的项目开发计划。 具体来说，要估算的内容包括： 软件工作产品的规模 软件项目的工作量和成本 软件项目的进度 项目所需要的人员、计算机等资源,什么是软件项目的规模,在一个软件项目中，项目组要完成的工作产品，是规模评估的对象，那么，项目组要完成的工作产品包括些什么？是最后要交付的（向用户和向组织二个方面）程序、文

2、档。 但是，项目组并不是只要完成最后交付的程序和文档，就可以了。在交付前，要进行确认和验证测试，为此，要进行质量控制有关的工作。再往前追述，项目组还必须做配置管理、需求管理，以及项目管理。这些都有工作量。那么，软件规模如何估算？ 现在，常用的办法，是通过对软件程序的规模进行估算的办法，来间接反映软件项目的规模。规模是工作量的一个方面，并不能说规模大，工作量就大。在这方面，并不一定是完全等同的。显然，接口控制程序的程序量可能并不大，但是程序量比较大的报表处理程序的工作量就大。这种不合理性，一般通过相关的程序复杂度、难度，加以调节。这个问题，在相应的评估算法中，采用加权因子的方法，加以调整。同样，

3、程序规模的增长，会带来支持和管理工作成指数规模的增长。因此，这也是需要注意的地方。,用什么来估算软件项目的规模,软件的规模计算，从有软件的一天开始，就是一个没有解决的问题。 没有解决的难题是，现在越来越没有办法给出评价程序量多少的统一尺度。在程序设计的早期，直接的编码量（字节数）是度量程序量的简单办法。但是，没有多久，这个办法就受到了挑战。因为有一个好的算法（例如：好的循环控制），可以节省大量的程序编码，但工作量（设计所花的时间、测试的复杂度）等，反而并没有节省开发的精力和时间。因此，程序量作为工作量的度量标准，显然是不正确的。那么现在，在完全不同的系统、应用环境下，提出统一和易于运用的度量标

4、准，是非常困难的。 为了解决问题，在CMM2的计划管理中，已经提出了一些度量的实例，包括：功能点数、特征点数、编码行数（LOC）、需求数或页数等。还可以有：模块数目，表格数，用户界面屏数，及数据结构等，作为规模评估的参考。 度量软件项目规模的尺度，是一个相对值，而不存在绝对值。,软件项目规模的估算方法LOC法,LOC(Line of Code) 一个衡量软件项目规模最常用的方法： LOC指所有的可执行的源代码行数，包括可交付的工作控制语言（JCL：Job Control Language）语句、数据定义、数据类型声明、等价声明、输入/输出格式声明等。 单位编码行（1LOC）的价值和人月均编码行

5、数可以体现一个软件生产组织的生产能力。组织可以根据对历史项目的审计来核算组织的单行编码价值。,概念说明,LOC NCLOC CLOC LOC=NCLOC+CLOC,例如，某软件公司统计发现该公司每一万行C语言源代码形成的源文件（.c和.h文件）约为250K。某项目的源文件大小为3.75M，则可估计该项目源编码大约为15万行，该项目累计投入工作量为240人月，每人月费用为10000元（包括人均工资、福利、办公费用公滩等），则该项目中单位LOC的价值为： （24010000）/15000016元/LOC 该项目的人月均编码行数为： 150000/240=625LOC/人月,软件项目规模的估算方法D

6、elphi法,Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别，但专家“专”的程度及对项目的理解程度是工作中的难点，尽管Delphi技术可以减轻这种偏差，专家评估技术在评定一个新软件实际成本时通常用得不多，但是，这种方式对决定其它模型的输入时特别有用。 Delphi法的步骤是： 1、协调人向各专家提供项目规格和估计表格； 2、协调人召集小组会各专家讨论与规模相关的因素； 3、各专家匿名填写迭代表格； 4、协调人整理出一个估计总结，以迭代表的形式返回专家； 5、协调人召集小组会，讨论较大的估计差异； 6、专家复查估计总结并在迭

7、代表上提交另一个匿名估计； 7、重复4-6， 直到达到一个最低和最高估计的一致。,软件项目规模的估算方法类比法,类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。类比法估计结果的精确度取决于历史项目数据的完整性和准确度。因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。 类比法的基本步骤是： 1、整理出项目功能列表和实现每个功能的编码行数； 2、标识出每个功能列表与历史项目的相同点和不同点，特别要 注意历史项目做得不够的地方； 3、通过步骤1和2得出各个功能的估计值； 4、产生规模估计。

8、,前面介绍的代码行技术是比较简单的定量估算软件规模的方法。 这种方法依据以往开发类似产品的经验和历史数据，估算实现一个功能所需要的源程序行数。,当有以往开发类似产品的历史数据可供参考时，这种方法估算出的数值还是比较准确的。,代码行技术,代码行技术的优点： 代码是所有软件项目开发都包含的“产品”，而且代码行数很容易计算。 代码行技术的缺点： 源程序仅是软件配置的一个成分，用它的规模代表整个软件规模不太合理； 用不同语言实现同一个软件所需的代码行数并不相同，即它依赖于所使用的编程语言； 不适合于非过程语言。,功能点技术,是为克服代码行技术缺点提出的； 它涉及多种因素的度量方法； 功能点技术根据对软

9、件信息域特性和软件复杂性的评估结果，估算软件规模，所以在系统设计初期就能够估算出软件项目的规模。,信息域特性,产品信息域的5个特性： 输入项数(Inp) 用户向软件输入的项数，这些输入为软件提供了面向应用的数据 输出项数(Out) 软件向用户输出的项数，它们向用户提供面向应用的信息 查询数(Inq) 查询，即一次联机输入，它导致软件以联机输出方式产生某种即时响应。 主文件数(Maf) 逻辑主文件（数据的一个逻辑集合）的数目。 外部接口数(Inf)。 机器可读的全部接口的数量。,功能点技术基本原理,使用5个信息域的“加权和”CT与14个技术因素的“复杂性调节值”Fi来计算功能点FP:,TCF,估

10、算功能点的步骤,1、计算未调整的功能点数CT 首先把信息域的每个特性都分类为简单级、平均级或复杂级，根据等级按下表分配功能点数：,估算功能点的步骤,特性系数,复杂级别,然后用下式计算未调整的功能点数UFP： CT=a1Inpa2Outa3Inqa4Mafa5Inf,估算功能点的步骤,2、计算技术复杂因子TCF 软件复杂度的估算基于14个问题，逐一对各问题做出复杂度估计，其取值范围是0-5。,估算功能点的步骤,“没有影响”取值0 “偶然的”取值1 “适中的”取值2 “普通的”取值3 “重要的”取值4 “极重要的”取值5,系统需要可靠的备份和复原吗？ 需要数据通信吗？ 有分布处理功能吗？ 性能很关

11、键吗？ 系统是否在一个已有的、很实用的操作环境中运行？ 系统需要联机入口吗？ 联机入口需要在多屏幕或多操作之间切换以完成输入？ 系统联机需要更新主文件吗？ 系统的输入、输出、文件或查询很复杂吗？ 系统内部处理复杂吗？ 代码需要被设计成可复用的吗？ 设计中要包括转换及安装吗？ 系统的设计支持不同组织的多次安装吗？ 系统的设计有利于用户修改和使用吗？,功能点技术,功能点技术没有涉及系统本身的算法复杂性。 因此，它仅仅适合算法比较简单的事务处理软件的规模度量；对算法较复杂的大型软件系统并不适应。,工作量估算,软件估算模型使用由经验导出的公式来预测软件开发工作量，其中，工作量是软件规模(LOC或FP)

12、的函数，工作量的单位通常是人月（pm）。 静态单变量模型 动态多变量模型 COCOMO2模型,支持大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的，因此，没有一个估算模型可以适应所有类型的软件和开发环境。,静态单变量模型,静态单变量的总体结构形式如下： 其中，A、B、C是由经验数据导出的常数，E是以人月为单位的工作量，ev是估算变量（KLOC或FP）。,下面给出典型的静态单变量模型： 面向KLOC的估算模型 面向FP的估算模型,面向KLOC的估算模型,Walston_Felix (IBM模型) Bailey_Basili模型 Boehm简单模型 Doty模型(KLOC9时适合),

13、面向FP的估算模型,Albrecht&Gaffney模型 Maston，Barnett和Mellichamp模型,静态单变量的估算模型,从上面可以看出，对于相同的KLOC或LP，用不同的模型估算的结果各不相同。 主要原因： 这些模型都仅仅依据若干领域中有限个项目的经验数据推导出来的，适应范围有限。 因此，必须根据当前项目特点选择适应的估算模型，并依据需要对相应模型作出调整。,动态多变量模型,动态多变量模型，即软件方程式，它是根据4000多个当代软件项目中收集的生产率数据推导出来的。 该模型把工作量看作是软件规模和开发时间的函数，其形式如下：,动态多变量模型,其中： E是以人月或人年为单位的工作

14、量； t是以月或年为单位的项目持续时间； B是特殊因子，它随着对测试、质量保证、文档及管理技术的需求的增加而缓慢增加。对于较小程序(KLOC=515)，B=0.16；而对于超过70KLOC的程序，B=0.39； P是生产率参数，它反映下属因素对工作量的影响： 总体过程成熟度及管理水平； 使用良好的软件工程实践的程度； 使用程序设计语言的级别； 软件环境状态； 软件项目组的经验和技术； 应用系统的复杂性等。,动态多变量模型,P的取值： 开发实时嵌入式软件时，P的典型值为2000； 开发电信系统时，P=10000； 对于商业软件来说，P=28000。 从上式可以看出，开发同一个软件产品（即LOC固

15、定）的时候，如果把项目持续时间延长，则可降低完成项目所需要的工作量。,COCOMO模型,COCOMO模型构造性成本模型 1981年Boehm在软件工程经济学中首次提出了COCOMO模型。 1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型模型的修正版，它反映了十多年来人们在软件成本估算方面所积累的经验。,COCOMO模型,COCOMO模型给出了3个层次的工作量估算模型。这3个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。这些模型既可以用于不同类型的项目，也可以用于同一个项目的不同开发阶段。 这三个层次的估算模型分别是： 基本COCOMO模型 中间COCOM

16、O模型 详细COCOMO模型,COCOMO模型基本原理,COCOMO模型具有以下形式： 其中，MM是开发工作量； KLOC是估计的源代码行数（以千行为单位）； a是模型系数； fi是成本因素,COCOMO模型基本原理,每个成本因素根据它的重要程度和影响大小赋予一定的值，可把这些成本因素划分为： 产品因素 计算机因素 人员因素 项目因素。,基本COCOMO模型,基本COCOMO模型是一个静态单变量模型，它把软件系统所需要的成本看作是程序大小单一变量的函数，用于系统级的粗略估算。,工作量 MM=CKLOCa (人月|人年) 开发时间 D=cEd (月|年),中间COCOMO模型,中间COCOMO模型是一个静态多变量模型，它把软件系统所需要的成本看作是程序大小和一系列成本驱动属性的函数。该模型将软件系统区分为系统和部件两个层次；系统是由部件组成。,详细COCOMO模型,详细COCOMO模型除了包括中级COCOMO模型中所考虑的因素以外，并对工作量调节因子在软件过程中每