软件度量综述.ppt

《软件度量综述.ppt》由会员分享，可在线阅读，更多相关《软件度量综述.ppt（68页珍藏版）》请在三一文库上搜索。

1、1,软件度量综述,2,软件度量（software measurement）,软件度量（software measurement）：对软件开发项目、过程及其产品进行定量化的过程，目的在于对其加以理解、预测、评估、控制和改善。 度量取向：软件开发的诸多事项，涉及项目、产品和过程多方面，包括规模、成本、进度、可靠性、功能性、易用性、缺陷、生产率、生命周期等等。 度量取向的依据是：事实、数据、原理、法则； 度量取向的方法是：测试、审核、调查； 度量取向的工具是：统计、图表、数字、模型； 度量取向的标准是：量化的指标。,3,度量与量度,software measurement 和 software me

2、trics分别译成软件度量和软件量度，目前学界还没有明确这两个术语的区别，从文献上看，这两个术语是同义词。大多数人采用软件度量（software measurement）。,4,软件度量的发展历程,5,软件度量流程,6,软件度量三维度 (考试),7,项目度量,项目度量是针对软件开发项目的特定度量，目的在于度量项目规模、项目成本、项目进度、顾客满意度等。 项目度量目的：辅助项目管理、进行项目控制。,8,规模度量,规模度量(size measurement)是估算软件项目工作量、编制成本预算、策划合理项目进度的基础。 软件规模的估算方法： 代码行(LOC：lines of code) 功能点分析(

3、FPA：function points analysis) 德尔菲法(Delphi technique) COCOMO模型 特征点(feature point) 对象点(object point) 3-D功能点(3-D function points) Bang度量(DeMarcos bang metric) 模糊逻辑(fuzzy logic) 标准构件法(standard component)等，,9,代码行(LOC：lines of code),代码行(LOC)：所有可执行源代码行数，包括可交付的工作控制语言(JCL：job control language)语句、数据定义、数据类型声明、

4、等价声明、输入/输出格式声明等。 一代码行(1LOC)的价值和人月均代码行数可以体现一个软件组织的生产能力。 可以根据对历史项目的审计来核算单行代码价值。 代码行LOC常用于源代码的规模估算，常使用的单位有： SLOC (single line of code) KLOC (thousand lines of code) LLOC (logical line of code) PLOC (physical line of code) NCLOC (non-commented line of code) DSI (delivered source instruction)。,10,面向LOC的估

5、算模型,Walston-Felix模型 E=5.2*(KLOC)0.91 Bailey-Basili模型 E=5.5+0.73*(KLOC)1.16 Boehm模型 E=3.2*(KLOC)1.05 Doty模型 E=5.288*(KLOC)1.047,11,功能点分析法(FPA：function point analysis),功能点分析法(FPA)是在需求分析阶段基于系统功能的一种规模估算方法，是基于应用软件的外部、内部特性以及软件性能的一种间接的规模测量。 FPA法由IBM的工程师艾伦艾尔布策(Allan Albrech)于20世纪70年代提出，随后被国际功能点用户协会(IFPUG：Th

6、e International Function Point Users Group)提出的IFPUG方法继承。,12,成为国际标准的功能点估算方法： 加拿大人艾伦艾布恩(Alain Abran)等人提出的全面功能点法(full function points)； 英国软件度量协会(UKSMA：United Kingdom Software Metrics Association)提出的IFPUG 功能点法(IFPUG function points)； 英国软件度量协会提出的Mark II FPA功能点法(Mark II function points)； 荷兰功能点用户协会(NEFPUG：

7、Netherlands Function Point Users Group)提出的NESMA 功能点法； 软件度量共同协会(COSMIC：the COmmon Software Metrics Consortium)提出的COSMIC-FFP方法； ,13,功能点分析的主要步骤,14,功能点分析法的基本计数 外部输入数(EI：external input)：计算每个用户输入，它们向软件提供面向应用的数据。输入应该与查询区分开来，分别计算。 外部输出数(EO：external output)：计算每个用户输出，它们向软件提供面向应用的信息。这里，输出是指报表、屏幕、出错信息，等等。一个报表中的

8、单个数据项不单独计算。 外部查询数(EQ：external query)：一个查询被定义为一次联机输入，它导致软件以联机输出的方式产生实时的响应。每一个不同的查询都要计算。 内部逻辑文件(ILF：internal logical file)：计算每个逻辑的主文件，如数据的一个逻辑组合，它可能是某个大型数据库的一部分或是一个独立的文件。 外部接口文件(EIF：external interface file)：计算所有机器可读的接口，如磁带或磁盘上的数据文件，利用这些接口可以将信息从一个系统传送到另一个系统。,15,面向FP的估算模型,Albrecht 和Gaffney E=-13.39+0.05

9、45FP Kemerer E=60.62*7.728*10(-8)*FP3 Maston、Barnett和 Mellichamp E=585.7+5.12FP,16,德尔菲法(Delphi technique),德尔菲法的步骤是： (1)协调人向各专家提供项目规格和估算表格； (2)协调人召集小组会和各专家讨论与规模相关的因素； (3)各专家匿名填写迭代表格； (4)协调人整理出一个估算总结，以迭代表的形式返回给专家； (5)协调人召集小组会，讨论较大的估算差异； (6)专家复查估算总结并在迭代表上提交另一个匿名估算； (7)重复46，直到最低估算和最高估算一致。,17,德尔菲法(Delphi

10、)是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来、新技术与特定程序之间的差别，但专家“专”的程度及对项目的理解程度是工作中的难点，尽管德尔菲技术可以减轻这种偏差，在评定一个新软件实际成本时通常用得不多，但是，这种方式对决定其他模型的输入时特别有用。,18,Expert judgment专家评估（判断） Analogy类推 Proportion预测（x悲观+4y乐观+z可能)/6 Delphi technique Delphi 技术 Wolverton model Wolverton 模型,19,构造性成本模型(COCOMO：constructive cost mo

11、del),构造性成本模型(COCOMO)是一种精确、易于使用的基于模型的成本估算方法，最早由勃姆(Boehm)于1981年提出。 COCOMO模型具有估算精确、易于使用的特点。 该模型按其详细程度分为3级： 基本COCOMO模型 中级COCOMO模型 高级COCOMO模型,20,基本COCOMO模型 是一个静态单变量模型，它用一个已估算出来的源代码行数(LOC)为自变量的函数来计算软件开发工作量。 中级COCOMO模型 在用LOC为自变量的函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算 高级COCOMO模型 包括中级COCOMO模型的所有特

12、性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中分析、设计等各步骤的影响。,21,COCOMO模型中使用的基本量有以下几个： (1)DSI(源指令条数)，定义为代码行数，包括除注释行以外的全部代码。若一行有两个语句，则算做一条指令。 (2)MM(度量单位为人月)表示开发工作量。 (3)TDEV(度量单位为月)表示开发进度，由工作量决定。 (4)COCOMO模型重点考虑15种影响软件工作量的因素，并通过定义乘法因子，从而准确、合理地估算软件的工作量。,22,成本度量,软件开发成本度量主要指软件开发项目所需的财务性成本的估算。主要方法如下： 类比估算法 细分估算法 周期估算法,2

13、3,类比估算法： 类比估算法是通过比较已完成的类似项目系统来估算成本，适合评估一些与历史项目在应用领域、环境和复杂度方面相似的项目。其约束条件在于必须存在类似的具有可比性的软件开发系统，估算结果的精确度依赖于历史项目数据的完整性、准确度以及现行项目与历史项目的近似程度。,24,细分估算法： 细分估算法是将整个项目系统分解成若干个小系统，逐个估算成本，然后合计起来作为整个项目的估算成本。细分估算法通过逐渐细化的方式对每个小系统进行详细的估算，可能获得贴近实际的估算成本。其难点在于，难以把握各小系统整合为大系统的整合成本。,25,周期估算法： 周期估算法是按软件开发周期进行划分，估算各个阶段的成本

14、，然后进行汇总合计。周期估算法基于软件工程理论对软件开发的各个阶段进行估算，很适合瀑布型软件开发方法，但是需要估算者对软件工程各个阶段的作业量和相互间的比例具有相当的了解。,26,顾客满意度度量,顾客满意度指标(CSI：customer satisfaction index)以顾客满意研究为基础，对顾客满意度加以界定和描述。 项目的顾客满意度度量 确定各类信息、数据、资料来源的准确性、客观性、合理性、有效性，并以此建立产品、服务质量的衡量指标和标准。 企业的顾客满意度度量 标准会因为各企业的经营理念、经营战略、经营重点、价值取向、顾客满意度调查结果等因素而有所不同。,27,美国专家斯蒂芬(St

15、ephen H.Kan)在软件质量工程的度量与模型(Metrics and Models in Software Quality Engineering)中给出的企业的顾客满意度要素：,28,作为企业的顾客满意度的基本构成单位，项目的顾客满意度会受到项目要素的影响 ，可以细分为如表所示的度量要素：,29,产品度量,软件产品质量的生命周期及其度量 软件产品度量用于对软件产品进行评价，并在此基础之上推进产品设计、产品制造和产品服务优化。 软件产品的度量实质上是软件质量的度量，而软件的质量度量与其质量的周期密切相关，如图所示：,30,31,软件产品质量度量模型,软件产品的度量主要针对作为软件开发成果

16、的软件产品的质量而言，独立于其过程。 软件的质量由一系列质量要素组成，每一个质量要素又由一些衡量标准组成，每个衡量标准又由一些量度标准加以定量刻划。 质量度量贯穿于软件工程的全过程以及软件交付之后。 在软件交付之前的度量主要包括程序复杂性、模块的有效性和总的程序规模 在软件交付之后的度量则主要包括残存的缺陷数和系统的可维护性方面。一般情况下，可以将软件质量特性定义成分层模型。,32,勃姆(Barry W. Boehm)在软件风险管理(Software Risk Management)中第一次提出了软件质量度量的层次模型。 麦考尔(McCall)等人将软件质量分解至能够度量的层次，提出FCM 3

17、层模型： 软件质量要素(factor) 衡量标准(criteria) 量度标准(metrics) 包括11个标准，分为产品操作(product operation)、产品修正(product revision)和产品转移(product transition)。 ISO 9126将软件质量总结为6大特性，每个特性包括一系列副特性，其软件质量模型包括3层： 高层：软件质量需求评价准则(SQRC)； 中层：软件质量设计评价准则(SQDC)； 低层：软件质量度量评价准则(SQMC)。,33,软件质量度量FCM模型,34,软件质量模型之比较,35,软件质量度量方法,(1)Halstead复杂性度量法，

18、基本思路是根据程序中可执行代码行的操作符和操作数的数量来计算程序的复杂性。操作符和操作数的量越大，程序结构就越复杂。 (2)McCabe复杂性度量法，其基本思想是程序的复杂性很大程度上取决于程序控制流的复杂性，单一的顺序程序结构最简单，循环和选择所构成的环路越多，程序就越复杂。,36,Evaluating models评估模型,Mean magnitude of relative error (MMRE)相对误差平均值 absolute value of mean of (actual - estimate)/actual goal: should be .25 or less Pred(x/

19、100): percentage of projects for which estimate is within x% of the actual估计在实际值x%范围内的项目的百分比 goal: should be .75 or greater for x = .25,37,38,过程度量,过程度量是对软件开发过程的各个方面进行度量，目的在于预测过程的未来性能，减少过程结果的偏差，对软件过程的行为进行目标管理，为过程控制、过程评价持续改善提供定量性基础。 过程度量与软件开发流程密切相关，具有战略性意义。软件过程质量的好坏会直接影响软件产品质量的好坏，度量并评估过程、提高过程成熟度可以改进产品

20、质量。相反，度量并评估软件产品质量会为提高软件过程质量提供必要的反馈和依据。,39,软件过程性能的度量模型,40,软件过程度量的内容,成熟度度量(maturity metrics) 主要包括组织度量、资源度量、培训度量、文档标准化度量、数据管理与分析度量、过程质量度量等等 管理度量(management metrics)， 主要包括项目管理度量(如里程碑管理度量、风险度量、作业流程度量、控制度量、管理数据库度量等)、质量管理度量(如质量审查度量、质量测试度量、质量保证度量等)、配置管理度量(如式样变更控制度量、版本管理控制度量等) 生命周期度量(life cycle metrics) 主要包括

21、问题定义度量、需求分析度量、设计度量、制造度量、维护度量等。,41,软件过程度量流程,软件过程度量的一般流程主要包括： 确认过程问题； 收集过程数据； 分析过程数据； 解释过程数据； 汇报过程分析； 提出过程建议； 实施过程行动； 实施监督和控制。,42,OO度量,OO度量的特性 局域性（局部化） 封装性 信息隐藏 继承性 抽象,43,局域性(Localization)是指信息被集中在一个程序内的方式。 （1）传统方法：数据与过程分离，功能分解和功能信息局域化。其典型的实现形式为过程模块，工作时用数据驱动功能。 此时的量度放在功能内部结构和复杂性上（如模块规模、聚合度、环路复杂性等）或放在该功

22、能与其他功能（模块）的耦合方式上。 （2）OO方法：局域性基于对象，因为类是OO系统的基本单元，对象封装数据和过程，因此应把类（对象）作为一个完整实体来量度。 另外，操作（功能）和类之间的关联是一对一的。因此，在考虑类合作中的量度时，必须能适应一对多和多对一的关联。,44,封装(Encapsulation)是指一个项集合的包装 （1）传统方法：记录、数组，只有数据没有过程，为低层次的封装；过程、函数、子例程和段，则只有过程没有数据，为中层次的封装。其量度的重点分别在代码行的数据和环路的复杂性。 （2）OO方法：OO系统封装拥有类的职责（操作），包括类的属性、操作和特定的类属性值定义的类（对象）

23、的状态。其量度和重点不是单一的模块，而是包含数据（属性）和过程（操作）的包。,45,信息隐藏(Information hiding)是指隐藏（删除）了程序构件操作的细节，只将访问该构件所必要的信息提供给访问该构件的其他构件。 在这一点上，OO方法和传统方法基本一致。因此，OO系统应支持信息隐藏，除提供隐藏等级说明的量度外，还应提供OO设计质量指标。,46,继承性(Inheritance)是指一个对象的属性和操作能够传递给其他对象的机制。继承性的发生贯穿于一个类的所有层次。 一般来说，传统软件不支持这种特性。而对OO系统来说，继承性是一个关键性的特性。因此，很多OO系统的量度都以此为重点，如子的

24、数量（类的直接实例数量），父的数量（直接上一代数量），以及类的嵌套层次（在一个继承层次中，类的深度）。,47,抽象(Abstraction)使设计者只关心一个程序构件的主要细节（数据和过程两者），而不考虑底层的细节。 抽象是一种相对概念，在OO和传统开发方法中都被采用。如处于抽象的较高层次时，我们可忽略更多的细节，当处于抽象的较低层次时，可以引入更多的细节，即提供一个关于概念或项的更详细的看法。 OO量度可用一个类度量的项来表示抽象，如每个应用类的实例化的数量、每个应用类被参数化的数量，以及类被参数化与未被参数化的比例等。,48,面向类的度量,类是OO系统的基本单元。类、类的层次和类的合作的度

25、量，对软件工程设计质量的评价是十分重要的。,49,1. LK度量方法,LK度量组是由Lorenz和Kidd提出的，他们把基于类的量度分为四种类型：规模、继承、内部和外部特性。 LK度量是侧重于规模的度量 基于规模的度量，主要集中在单一类的属性和操作的数量，以及作为整个OO系统的平均值； 基于继承的度量，关注的是贯穿于类层次的操作被重用的方式； 类的内部特性的度量是考察聚合和代码问题； 外部特性的度量则是检查耦合和重用问题。,50,度量体系的样本如下,类大小（CS）： 可通过被封装在类中的操作的总数和属性的数量来测度。 由子类重载的操作数量（NOO）： 若NOO大，则导致了弱的类层次和可能难于测

26、试和修改的OO软件。 由子类加入的操作的数量（NOA）： 当NOA值增大时，子类漂离超类隐含的抽象。当继承树的深度变大时，在层次中低层的NOA值将下降。 特例化指标（SI）： 特例化可通过加入或删除或覆写来达到，SI=(NOO*层次)/(总的类方法数)，SI值越高，越有可能类层次中包含了更多不遵从超类抽象的类。,51,LK度量方法可用于开发的不同阶段,1、作为规模度量标准：用以评估模型预测项目的工作或持续时间 2、作为测试实例评估：有助于测试小组准备测试用例以及将资源分配给将来的测试活动,52,2. CK度量方法,CK度量组由Chidamber和Kemerer提出，他们建议使用6种基于类设计的

27、度量，通称为CK度量组。 每个类的加权方法(WMC) 继承树的深度(DIT) 子女的数量(NOC) 对象类之间的耦合(CBO) 对类的响应(RFC) 方法中缺少内聚 (LCOM) CK度量是侧重于设计的度量，可以看做是对LK度量的补充。,53,(1) 每个类的加权方法WMC (weighed Methods per Class) WMC=Ci (i=1n) 其中，Ci为一个类的各个方法（或操作或服务）的复杂性，相当于传统方法中的环路复杂性，Ci可相加。方法的数量和它们的复杂性是用来实现和测试一个类工作量总量的指示器。方法的数量越大，继承树（所有子类都继承父类的方法）就越复杂。对一个给定的类，随

28、着方法的数量增大，其应用很可能变得越来越专门化，由此将限制其可能的重用。所以，WMC的值应当合理。,54,(2) 继承树的深度DIT (Depth of the Inheritance Tree) 这种量度被定义为从结点到树根的最大长度。 DIT的值越大，复杂性就越高。因为随着DIT的增大，层次的类可能会继承许多方法。当试图预测一个类行为时，困难不仅会增大，而且会增加设计的复杂性。当然DIT较大时，则表示有许多方法被重用，这是其好的一方面。,55,(3) 子的数量NOC (Number of children) 子类在类的层次内，子类可以最直接地从属于一类。随着子类数量的增大，重用也增加了。但

29、父类抽象的表示可能减少，即一些子类可能不是父类真正的成员，同时，测试数量（用来检查每个子类在操作前后的要求）也将增加。,56,(4) 对象类间的耦合CBO CBO(Coupling Between Object Classes)是指一个类合作（即相关）的数量。当CBO增大时，不仅降低了可重用性，而且使其修改和修改后的测试变得复杂。所以，每个类的CBO值应当保持合理。这与在传统软件中减少耦合的一般原则是一致的。,57,(5) 对一个类的响应RFC (Response for a Class) 一个类的响应设置是一组方法，它可能被执行，用来响应接收到的类对象的消息，RFC被定义为响应设置方法的数量

30、。 RFC增加，测试序列增加，测试工作量也将增加。由此可以得出，当RFC增大时，类的设计复杂性也将增大。,58,(6) 方法中聚合的不足LCOM (Lack of Cohesion in Methods) 一个类内的每种方法访问一个或多个属性（也称实例变量）。LCOM是访问一个或多个相同属性方法的数量。 如果LCOM很大，则说明方法可以通过属性与其他方法耦合，这就增加了类设计的复杂性。通常，对LCOM值很大的类，可以把它分为两个或多个单独的类，这样每个类能的设计更方便。 这里讲的耦合和聚合与传统软件中所讲的是一样的。我们希望高聚合和低耦合，即保持低的LCOM。但在某些情况下，LCOM值很大也是

31、合理的。,59,不同开发阶段CK度量的应用,60,MOOD度量方法,度量样本如下： 方法继承因子（MIF） 耦合因子（CF） 多态因子（PF）,61,方法继承因子（MIF）:OO系统的类体系结构针对方法（操作）和属性而使用继承的程度被定义为：,MIF=Mi(Ci)/Ma(Ci) 对i从1到TC求和 其中TC为在体系结构中的类的总数，Ci是在体系结构中 的一个类。且： Ma(Ci)=Md(Ci)+Mi(Ci) 其中Ma(Ci)为可在和Ci关联中被调用的方法的数量， Md(Ci)为在类Ci中声明的方法的数量，Mi(Ci)为在类Ci 中继承（未被覆写的）的方法的数量。 MIF值提供了继承对OO软件的

32、影响的指示。,62,耦合因子（CF）： CF=ijis_client(Ci,Cj)/(TC-TC) 这里针对I从1到TC和j从1到TC求和。函数 is_client=1, 当且仅当在客户端类Cc和服务器类Cs 间存在关系，且CcCs时 is_client=0, 否则 当CF值增加时，OO软件的复杂性也将增加，而可理解性、可维护性和复用潜力都将受到影响。,63,多态因子（PF）：重新定义被继承方法的方法数量，除以可能的不同多态情形的最大数量这样，PF是对系统中的动态绑定相对数量的间接测量。 PF=iMo(Ci)/iMn(Ci)*DC(Ci) 这里对i从1到TC求和。且 Md(Ci)=Mn(Ci)

33、+Mo(Ci) 其中，Mn(Ci)为新方法的数量，Mo(Ci)为覆写方法的数量，DC（Ci）为后代计数（某基类的后代类的数量）,64,面向操作的量度,根据Lorenz和Kidd的建议，有三种基本量度： (1) 平均操作规模OSavg (Average Operation Size) 虽然代码行数可以成为操作规模的指示器，但代码行数的度量与传统软件一样有许多问题。因此，在OO软件中，由操作所传送的消息数量提供了一个对操作规模度量可选的方法。操作规模增大，表示操作所传送的消息数量增加，数量越大，说明越复杂。 (2) 操作复杂性OC (Operation Complexity) 一个操作的复杂性可以

34、用传统软件所使用的任何复杂性量度进行计算。因为操作限于特定的职责，所以设计人员应使OC尽可能的小。 (3) 每个操作参数的平均数NPavg (Average Number per Operation) 操作参数的数量越大，对象间的合作就越复杂。所以，NPavg 一般应尽可能的小。,65,OO测试的量度,1. 封装性 (1) 方法（操作与服务）中聚合的不足LCOM LCOM的值越高，表示更多的状态必须进行测试，才能保证方法不产生副作用。 (2) 公共与私有的百分比PAP (Percent Public and Protected) 公共属性从其他类继承，所以这些类是可见的。私有属性是专属的，为一

35、特定子类所拥有。这种量度说明类的公共属性的百分比，PAP的值高就可能增加类间的副作用。 (3) 数据成员的公共访问PAD (Public Access to Data Member) 这种量度说明可访问其他类属性的类的数量，即一种封装的破坏。PAD的值高可能导致类间的副作用。所以，测试的设计必须保证每一种这样的副作用能够被发现。,66,2. 继承性 (1) 根类的数量NOR (Number of Root Classes) 这种量度是在设计模型中，描述性质各不相同的类层次数量的计算方法。对每一个根类及其子类的层次必须开发相应的测试序列。随着NOR的增大，测试工作量也相应增加。 (2) 扇入FI

36、N (Fan In) 当扇入用于OO情况时，扇入是一种多重继承的指标。FIN大于1 ，说明一个类不只从属一个根类，而是继承更多的根类的属性和操作。 (3) 子的数量NOC (Number of Children)和继承树的深度DIT (Depth of the Inheritance Tree) 正如在OO测试中讨论的，超类的方法（操作、服务）将不得不为每个子类进行重新测试。,67,OO项目的量度,项目管理人员的任务就是计划、协调、跟踪和控制一个软件项目的进行。其中主要问题就是对软件的实现规模进行估算。因为规模与工作量和开发时间成正比。 (1) 脚本的数量NSS (Number of Scenario Scripts) 脚本的数量或使用用例与满足需求所要求的类的数量、每个类的状态的数量，以及方法（操作）、属性和合作的数量成正比。所以，NSS是程序规模的重要指标。,68,脚本的数量NSS、关键类的数量NKC和子系统的数量NSUB的量度还可以用来收集与过去OO项目及其整个项目和单个过程活动（如OOA、OOD、OOP和OOT）相关的工作的花费。这些数据也可以与前面讨论过的设计量度一起用来计算生产率量度，如每个开发人员开发类的平均值等。总之，这些量度可以用于估算当前项目的工作量、开发时间、使用人员和其他信息。,