Chapter-23-Product-MetricsPPT课件

《Chapter-23-Product-MetricsPPT课件》由会员分享，可在线阅读，更多相关《Chapter-23-Product-MetricsPPT课件（53页珍藏版）》请在装配图网上搜索。

1、1Chapter 23nProduct MetricsSlide Set to accompanySoftware Engineering: A Practitioners Approach, 7/e by Roger S. PressmanSlides copyright 1996, 2001, 2005, 2009 by Roger S. PressmanFor non-profit educational use onlyMay be reproduced ONLY for student use at the university level when used in conjunct

2、ion with Software Engineering: A Practitioners Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author.All copyright information MUST appear if these slides are posted on a website for student use.2第23章：产品度量3McCalls Triangle of QualityMaintaina

3、bilityMaintainabilityFlexibilityFlexibilityTestabilityTestabilityPortabilityPortabilityReusabilityReusabilityInteroperabilityInteroperabilityCorrectnessCorrectnessReliabilityReliabilityEfficiencyEfficiencyIntegrityIntegrityUsabilityUsabilityPRODUCT TRANSITIONPRODUCT TRANSITIONPRODUCT REVISIONPRODUCT

4、 REVISIONPRODUCT OPERATIONPRODUCT OPERATION4麦考尔的质量三角型架构 可维护性灵活性可测性产品调整产品调整可移植性可重用性互操作性产品转换产品转换产品操作产品操作正确性可应用性效率可靠性完整性5A Comment6评价7Measures, Metrics and IndicatorsnA measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a product or proce

5、ssnThe IEEE glossary defines a metric as “a quantitative measure of the degree to which a system, component, or process possesses a given attribute.”nAn indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself 8测量，度量和指标

6、 9Measurement PrinciplesnThe objectives of measurement should be established before data collection begins;nEach technical metric should be defined in an unambiguous manner;nMetrics should be derived based on a theory that is valid for the domain of application (e.g., metrics for design should draw

7、upon basic design concepts and principles and attempt to provide an indication of the presence of an attribute that is deemed desirable);nMetrics should be tailored to best accommodate specific products and processes Bas8410测量原则n测量目标应该建立在数据收集开始之前;n每项技术的度量应以一个明确的方式来定义;n度量应该是根据一个在应用领域有效的理论派生出来的（例如，设计标

8、准应借鉴基本的设计概念和原则，试图来提供一个认为可取的属性存在的迹象）;n为了最好地容纳具体产品和进程，应适当裁剪度量Bas84 11Measurement ProcessnFormulation. The derivation of software measures and metrics appropriate for the representation of the software that is being considered.nCollection. The mechanism used to accumulate data required to derive the fo

9、rmulated metrics.nAnalysis. The computation of metrics and the application of mathematical tools.nInterpretation. The evaluation of metrics results in an effort to gain insight into the quality of the representation.nFeedback. Recommendations derived from the interpretation of product metrics transm

10、itted to the software team.12测量过程n制定。软件测量和度量的引出，是与正在审议的软件的代表相适应的。n收集。用于累积数据的机制需要得到制定好的标准。n分析。度量的计算和数学工具的应用。n解读。对获得代表质量的洞察力的衡量结果的评价。n反馈。将产品度量的解释转交给软件开发团队后得到的建议。13Goal-Oriented Software MeasurementnThe Goal/Question/Metric Paradigmn(1) establish an explicit measurement goal that is specific to the pro

11、cess activity or product characteristic that is to be assessedn(2) define a set of questions that must be answered in order to achieve the goal, and n(3) identify well-formulated metrics that help to answer these questions.nGoal definition templatenAnalyze the name of activity or attribute to be mea

12、sured nfor the purpose of the overall objective of the analysis nwith respect to the aspect of the activity or attribute that is considered nfrom the viewpoint of the people who have an interest in the measurement nin the context of the environment in which the measurement takes place.14面向目标的软件测量n目标

13、/问题/度量范例n（1）建立一个明确的测量目标，可以是具体的进程活动或者待评估的产品特点。n（2）定义一系列为实现目标而必须回答的问题，并n（3）识别有助于回答这些问题而制定好的度量。n目标定义模板n分析活动名称或将被测量的属性n以分析的总体目标为宗旨n关于活动方面或被考虑的属性n以谁在测量方面有兴趣的观点n从测量发生的环境的方面。15Metrics AttributesnSimple and computable. It should be relatively easy to learn how to derive the metric, and its computation shoul

14、d not demand inordinate effort or timenEmpirically and intuitively persuasive. The metric should satisfy the engineers intuitive notions about the product attribute under considerationnConsistent and objective. The metric should always yield results that are unambiguous. nConsistent in its use of un

15、its and dimensions. The mathematical computation of the metric should use measures that do not lead to bizarre combinations of unit. nProgramming language independent. Metrics should be based on the analysis model, the design model, or the structure of the program itself. nEffective mechanism for qu

16、ality feedback. That is, the metric should provide a software engineer with information that can lead to a higher quality end product16度量属性n简单，可计算。它应该是比较容易学会如何得到度量的，其计算不应该要求过多精力或时间n实际和直观的说服力。度量应满足工程师对产品被考虑的属性的直观概念n一致，客观。度量产生的结果应该是明确的。n一致的使用单位和尺寸。度量的数学计算所使用的标准，不应产生怪异组合单元。n与编程语言无关。度量应根据分析模型，设计模型，或者是程序

17、本身的结构。n质量反馈的有效机制。也就是说，度量应提供一个可以使最终产品的质量更高的信息化软件工程师。17Collection and Analysis PrinciplesnWhenever possible, data collection and analysis should be automated;nValid statistical techniques should be applied to establish relationship between internal product attributes and external quality characteristi

18、cs nInterpretative guidelines and recommendations should be established for each metric18收集和分析原则n只要有可能，数据收集和分析应自动进行;n有效的统计方法应适用于建立内部产品属性和外部质量特征之间的关系n应为每个度量建立解释性的准则和建议19Metrics for the Requirements ModelnFunction-based metrics: use the function point as a normalizing factor or as a measure of the “si

19、ze” of the specificationnSpecification metrics: used as an indication of quality by measuring number of requirements by type20需求模型的度量n基于功能的度量：将功能点作为一种正常化因素或作为一种规格的“范围”的标准n规格度量：作为用于衡量类别的若干规定的质量指标。21Function-Based MetricsnThe function point metric (FP), first proposed by Albrecht ALB79, can be used ef

20、fectively as a means for measuring the functionality delivered by a system.nFunction points are derived using an empirical relationship based on countable (direct) measures of softwares information domain and assessments of software complexitynInformation domain values are defined in the following m

21、anner:nnumber of external inputs (EIs)nnumber of external outputs (EOs)nnumber of external inquiries (EQs)nnumber of internal logical files (ILFs)nNumber of external interface files (EIFs)22基于功能的度量n功能点度量（FP）是首先由 Albrecht ALB79提出的，可用作测量系统交付功能的有效手段n利用基于软件信息域可数（直接）的度量和软件复杂性评估的经验关系来计算功能点。n信息域值以下列方式定义：n外

22、部输入的数量（EIs）n外部输出数（EOs）n外部查询数（EQs）n内部逻辑文件数（ILFs）n外部接口文件数（EIFs）23Function PointsI In nf fo or rm ma at ti io on n D Do om ma ai in n V Va al lu ue eC Co ou un nt ts si im mp pl le e a av ve er ra ag ge e c co om mp pl le ex xW We ei ig gh ht ti in ng g f fa ac ct to or rExternal Inputs ( EIs )External

23、 Outputs (EOs )External Inquiries (EQs)Internal Logical Files (ILFs )External Interface Files (EIFs)346457346710155710=Count total3333324功能点25Architectural Design MetricsnArchitectural design metricsnStructural complexity = g(fan-out)nData complexity = f(input & output variables, fan-out)nSystem com

24、plexity = h(structural & data complexity) nHK metric: architectural complexity as a function of fan-in and fan-outnMorphology metrics: a function of the number of modules and the number of interfaces between modules26建筑学设计度量n建筑学设计度量n结构复杂度=g（扇出）n数据复杂度= f（输入和输出变量，扇出）n系统复杂度=h（结构和数据的复杂性）nHK度量：将建筑的复杂性作为一

25、种扇入和扇出的功能n形态度量：一个模块数量和模块之间的接口数的函数27Metrics for OO Design-InWhitmire Whi97 describes nine distinct and measurable characteristics of an OO design:nSizeSize is defined in terms of four views: population, volume, length, and functionalitynComplexityHow classes of an OO design are interrelated to one an

26、othernCouplingThe physical connections between elements of the OO designnSufficiency“the degree to which an abstraction possesses the features required of it, or the degree to which a design component possesses features in its abstraction, from the point of view of the current application.”nComplete

27、nessAn indirect implication about the degree to which the abstraction or design component can be reused28面向对象设计的度量-1nWhitmireWhi97描述了面向对象设计的9个独特的，可测量的特点：n规模n规模可以从四个方面定义：总数量、容量、长度和功能n复杂性n一个面向对象的类是如何彼此相互联系的n耦合性n面向对象设计的成分间的物理连接n充分性n“从当前应用的角度看，一个抽象拥有其所需特征的程度，或一个设计构件拥有其抽象特征的程度”n完备性n间接隐含了抽象或设计构件可以复用的程度29M

28、etrics for OO Design-IInCohesion The degree to which all operations working together to achieve a single, well-defined purposenPrimitiveness Applied to both operations and classes, the degree to which an operation is atomicnSimilarity The degree to which two or more classes are similar in terms of t

29、heir structure, function, behavior, or purposenVolatility Measures the likelihood that a change will occur30面向对象设计的度量-2n内聚性n使所有操作一起工作，以实现单一的，明确的目标n原始性n同时适用于操作和类，是指一个操作的原子性程度n相似性n两个或多个类在其结构、功能、行为或目的方面的相似程度n易变性n测量将发生改变的可能性31Distinguishing CharacteristicsnLocalizationthe way in which information is con

30、centrated in a programnEncapsulationthe packaging of data and processingnInformation hidingthe way in which information about operational details is hidden by a secure interfacenInheritancethe manner in which the responsibilities of one class are propagated to anothernAbstractionthe mechanism that a

31、llows a design to focus on essential detailsBerard Ber95 argues that the following characteristics require that special OO metrics be developed:32显著特点Bernard Ber 95认为，以下几个特点需要制定特殊的面向对象度量：n本地化信息集中在一个程序里的方式n封装数据和进程的包装n信息隐藏关于操作的细节信息由安全接口隐藏的方法n继承其中一种类的责任传播到另一种的方式n抽象化允许设计专注于必要的细节的机制33Class-Oriented Metri

32、csnweighted methods per classndepth of the inheritance treennumber of childrenncoupling between object classesnresponse for a classnlack of cohesion in methods34面向类的度量由由ChidamberChidamber和和KemererCHI94KemererCHI94提出：提出：n每个类的加权方法n继承树的深度n子女数量n对象类之间的耦合n对类的响应n方法中缺少内聚35Class-Oriented Metricsnclass sizenn

33、umber of operations overridden by a subclassnnumber of operations added by a subclassnspecialization index36面向类的度量由由n类的规模n由子类重写的操作量n由子类加入的操作量n专业化指数37Class-Oriented MetricsnMethod inheritance factornCoupling factornPolymorphism factorHar98b:38面向类的度量MOOD MOOD 度量集度量集 Har98b:Har98b:n方法继承因子n耦合因子n多态因子39Op

34、eration-Oriented Metricsnaverage operation sizenoperation complexitynaverage number of parameters per operation40面向操作的度量由由n平均操作规模n操作复杂性n每个操作参数的平均数41Component-Level Design MetricsnCohesion metrics: a function of data objects and the locus of their definitionnCoupling metrics: a function of input and

35、output parameters, global variables, and modules callednComplexity metrics: hundreds have been proposed (e.g., cyclomatic complexity)42构件级设计度量n内聚性度量：一个数据对象和它们定义的轨迹的功能n耦合度量：一个输入和输出参数、全局变量、模块调用的功能n复杂性度量：多种建议（例如，环复杂度）43Interface Design MetricsnLayout appropriateness: a function of layout entities, the

36、geographic position and the “cost” of making transitions among entities44接口设计度量n布局适当：一个实体布局、地理位置以及实体之间转换“成本”的功能45Design Metrics for WebAppsnDoes the user interface promote usability?nAre the aesthetics of the WebApp appropriate for the application domain and pleasing to the user?nIs the content desi

37、gned in a manner that imparts the most information with the least effort?nIs navigation efficient and straightforward?nHas the WebApp architecture been designed to accommodate the special goals and objectives of WebApp users, the structure of content and functionality, and the flow of navigation req

38、uired to use the system effectively?nAre components designed in a manner that reduces procedural complexity and enhances the correctness, reliability and performance?46面向Webapp的度量n是否促进了用户界面的可用性？nWebApp美学适应于应用领域并且能使用户满意吗？n内容的设计是按照用最小努力传送最多信息的方法吗？n导航是高效而简单的吗？n以适应WebApp用户的特殊目标、内容和功能结构以及流动导航为目的的WebApp架构

39、设计，能够有效使用该系统吗？n组件的设计方法能降低程序的复杂性并提高正确性、可靠性和性能吗？47Code MetricsnHalsteads Software Science: a comprehensive collection of metrics all predicated on the number (count and occurrence) of operators and operands within a component or programnIt should be noted that Halsteads “laws” have generated substanti

40、al controversy, and many believe that the underlying theory has flaws. However, experimental verification for selected programming languages has been performed (e.g. FEL89).48代码度量nHalstead的软件科学：一个对所有前提在一个组件或程序中的操作符和操作数的数量（计数和发生）度量的全面收集n应该指出的是，Halstead的“定律“已经产生了重大争议，许多人认为该基础理论存在缺陷。然而，对于选择编程语言，目前已进行了实

41、验验证（例如，FEL89）。49Metrics for TestingnTesting effort can also be estimated using metrics derived from Halstead measuresnBinder Bin94 suggests a broad array of design metrics that have a direct influence on the “testability” of an OO system. nLack of cohesion in methods (LCOM). nPercent public and prot

42、ected (PAP). nPublic access to data members (PAD). nNumber of root classes (NOR). nFan-in (FIN). nNumber of children (NOC) and depth of the inheritance tree (DIT). 50面向测试的度量n使用从Halstead标准中得到的度量也可以估算出测试工作nBinderBin94提供了一组对面向对象系统的“可测性”具有直接影响的设计度量。n方法中缺少内聚（LCOM）。n共有与保护属性的百分比（PAP）。n对数据成员的共有访问（PAD）。n根类的数

43、量（NOR）。n扇入（FIN）。n子女数（NOC）和继承树的深度（DIT）。51Maintenance MetricsnIEEE Std. 982.1-1988 IEE94 suggests a software maturity index (SMI) that provides an indication of the stability of a software product (based on changes that occur for each release of the product). The following information is determined: M

44、T =the number of modules in the current release Fc =the number of modules in the current release that have been changed Fa =the number of modules in the current release that have been added Fd =the number of modules from the preceding release that were deleted in the current releasenThe software mat

45、urity index is computed in the following manner: SMI = MT - (Fa + Fc + Fd)/MTnAs SMI approaches 1.0, the product begins to stabilize.52维护的度量nIEEE Std.982.1-1988IEE94提出了一种软件成熟度指数（SMI），它提供了对软件产品稳定性的指示（根据每个产品发布的变更）。可以确定以下信息： MT =当前发布的模块数量 Fc =当前发布中已变更的模块数量 Fa =当前发布中已增加的模块数量 Fd =当前发布中已删除前一发布中的模块数量n软件成熟度指数用下列方程计算: SMI = MT - (Fa + Fc + Fd)/MTn当SMI值接近1.0时，产品开始趋于稳定。部分资料从网络收集整理而来，供大家参考，感谢您的关注！