软件度量综述.ppt

上传人:s****8 文档编号:82707477 上传时间:2023-03-26 格式:PPT 页数:68 大小:513.50KB
返回 下载 相关 举报
软件度量综述.ppt_第1页
第1页 / 共68页
软件度量综述.ppt_第2页
第2页 / 共68页
点击查看更多>>
资源描述

《软件度量综述.ppt》由会员分享,可在线阅读,更多相关《软件度量综述.ppt(68页珍藏版)》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

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

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

3、ts analysis)l德尔菲法(Delphi technique)lCOCOMO模型l特征点(feature point)l对象点(object point)l3-D功能点(3-D function points)lBang度量(DeMarcos bang metric)l模糊逻辑(fuzzy logic)l标准构件法(standard component)等,8代码行(LOC:lines of code)代码行(LOC):所有可执行源代码行数,包括可交付的工作控制语言(JCL:job control language)语句、数据定义、数据类型声明、等价声明、输入/输出格式声明等。一代码行

4、(1LOC)的价值和人月均代码行数可以体现一个软件组织的生产能力。可以根据对历史项目的审计来核算单行代码价值。代码行LOC常用于源代码的规模估算,常使用的单位有:lSLOC(single line of code)lKLOC(thousand lines of code)lLLOC(logical line of code)lPLOC(physical line of code)lNCLOC(non-commented line of code)lDSI(delivered source instruction)。9面向LOC的估算模型Walston-Felix模型lE=5.2*(KLOC)0

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

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

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

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

9、、Barnett和 Mellichamp lE=585.7+5.12FP15德尔菲法(Delphi technique)德尔菲法的步骤是:l(1)协调人向各专家提供项目规格和估算表格;l(2)协调人召集小组会和各专家讨论与规模相关的因素;l(3)各专家匿名填写迭代表格;l(4)协调人整理出一个估算总结,以迭代表的形式返回给专家;l(5)协调人召集小组会,讨论较大的估算差异;l(6)专家复查估算总结并在迭代表上提交另一个匿名估算;l(7)重复46,直到最低估算和最高估算一致。16德尔菲法(Delphi)是最流行的专家评估技术,在没有历史数据的情况下,这种方式适用于评定过去与将来、新技术与特定程序

10、之间的差别,但专家“专”的程度及对项目的理解程度是工作中的难点,尽管德尔菲技术可以减轻这种偏差,在评定一个新软件实际成本时通常用得不多,但是,这种方式对决定其他模型的输入时特别有用。17Expert judgment专家评估(判断)lAnalogy类推lProportion预测(x悲观+4y乐观+z可能)/6lDelphi technique Delphi 技术lWolverton model Wolverton 模型18构造性成本模型(COCOMO:constructive cost model)构造性成本模型(COCOMO)是一种精确、易于使用的基于模型的成本估算方法,最早由勃姆(Boeh

11、m)于1981年提出。COCOMO模型具有估算精确、易于使用的特点。该模型按其详细程度分为3级:l基本COCOMO模型l中级COCOMO模型l高级COCOMO模型19基本COCOMO模型l是一个静态单变量模型,它用一个已估算出来的源代码行数(LOC)为自变量的函数来计算软件开发工作量。中级COCOMO模型l在用LOC为自变量的函数计算软件开发工作量的基础上,再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算高级COCOMO模型l包括中级COCOMO模型的所有特性,但用上述各种影响因素调整工作量估算时,还要考虑对软件工程过程中分析、设计等各步骤的影响。20COCOMO模型中使用

12、的基本量有以下几个:l(1)DSI(源指令条数),定义为代码行数,包括除注释行以外的全部代码。若一行有两个语句,则算做一条指令。l(2)MM(度量单位为人月)表示开发工作量。l(3)TDEV(度量单位为月)表示开发进度,由工作量决定。l(4)COCOMO模型重点考虑15种影响软件工作量的因素,并通过定义乘法因子,从而准确、合理地估算软件的工作量。21成本度量 软件开发成本度量主要指软件开发项目所需的财务性成本的估算。主要方法如下:l类比估算法l细分估算法l周期估算法22类比估算法:l类比估算法是通过比较已完成的类似项目系统来估算成本,适合评估一些与历史项目在应用领域、环境和复杂度方面相似的项目

13、。其约束条件在于必须存在类似的具有可比性的软件开发系统,估算结果的精确度依赖于历史项目数据的完整性、准确度以及现行项目与历史项目的近似程度。23细分估算法:l细分估算法是将整个项目系统分解成若干个小系统,逐个估算成本,然后合计起来作为整个项目的估算成本。细分估算法通过逐渐细化的方式对每个小系统进行详细的估算,可能获得贴近实际的估算成本。其难点在于,难以把握各小系统整合为大系统的整合成本。24周期估算法:l周期估算法是按软件开发周期进行划分,估算各个阶段的成本,然后进行汇总合计。周期估算法基于软件工程理论对软件开发的各个阶段进行估算,很适合瀑布型软件开发方法,但是需要估算者对软件工程各个阶段的作

14、业量和相互间的比例具有相当的了解。25顾客满意度度量 顾客满意度指标(CSI:customer satisfaction index)以顾客满意研究为基础,对顾客满意度加以界定和描述。项目的顾客满意度度量l确定各类信息、数据、资料来源的准确性、客观性、合理性、有效性,并以此建立产品、服务质量的衡量指标和标准。企业的顾客满意度度量l标准会因为各企业的经营理念、经营战略、经营重点、价值取向、顾客满意度调查结果等因素而有所不同。26美国专家斯蒂芬(Stephen H.Kan)在软件质量工程的度量与模型(Metrics and Models in Software Quality Engineerin

15、g)中给出的企业的顾客满意度要素:企业的顾客满意度要素:顾顾客客满满意度要素意度要素顾顾客客满满意度要素的内容意度要素的内容技术解决方案质量、可靠性、有效性、易用性、价格、安装、新技术支持与维护灵活性、易达性、产品知识市场营销解决方案、接触点、信息管理购买流程、请求手续、保证期限、注意事项交付准时、准确、交付后过程企业形象技术领导、财务稳定性、执行印象27作为企业的顾客满意度的基本构成单位,项目的顾项目的顾客满意度客满意度会受到项目要素的影响,可以细分为如表所示的度量要素:要素:顾顾客客满满意度意度项项目目顾顾客客满满意度度量要素意度度量要素软件产品功能性、可靠性、易用性、效率性、可维护性、可

16、移植性开发文档文档的构成、质量、外观、图表以及索引、用语项目进度以及交期交期的根据、进度迟延情况下的应对、进展报告技术水平项目组的技术水平、项目组的提案能力、项目组的问题解决能力沟通能力事件记录、式样确认、Q&A运用维护支持、问题发生时的应对速度、问题解决能力28产品度量产品度量 软件产品质量的生命周期及其度量软件产品度量用于对软件产品进行评价,并在此基础之上推进产品设计、产品制造和产品服务优化。软件产品的度量实质上是软件质量的度量,而软件的质量度量与其质量的周期密切相关,如图所示:2930软件产品质量度量模型 软件产品的度量主要针对作为软件开发成果的软件产品的质量而言,独立于其过程。软件的质

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

18、teria)l量度标准(metrics)l包括11个标准,分为产品操作(product operation)、产品修正(product revision)和产品转移(product transition)。ISO 9126将软件质量总结为6大特性,每个特性包括一系列副特性,其软件质量模型包括3层:l高层:软件质量需求评价准则(SQRC);l中层:软件质量设计评价准则(SQDC);l低层:软件质量度量评价准则(SQMC)。32软件质量度量FCM模型 层 级名 称内 容第一层质量要素:描述和评价软件质量的一组属性功能性、可靠性、易用性、效率性、可维护性、可移植性等质量特性以及将质量特性细化产生的副

19、特性第二层衡量标准:衡量标准的组合反映某一软件质量要素精确性、稳健性、安全性、通信有效性、处理有效性、设备有效性、可操作性、培训性、完备性、一致性、可追踪性、可见性、硬件系统无关性、软件系统无关性、可扩充性、公用性、模块性、清晰性、自描述性、简单性、结构性、文件完备性等第三层度量标准:可由各使用单位自定义根据软件的需求分析、概要设计、详细设计、编码、测试、确认、维护与使用等阶段,针对每一个阶段制定问卷表,以此实现软件开发过程的质量度量33度量度量标标准准/目目标标麦麦 考考 尔尔勃勃 姆姆ISO 9126ISO 9126正确性(Correctness)XX可维护性可靠性(Reliability

20、)XXX完整性(Integrity)XX可用性(Usability)XXX效率性(Efficiency)XXX可维护性(Maintainability)XXX可测试性(Testability)X可维护性互操作性(Interoperability)X适应性(Flexibility)XX可重用性(Reusability)XX可移植性(Portability)XXX明确性(Clarity)X可变更性(Modifiability)X可维护性文档化(Documentation)X恢复力(Resilience)X易懂性(Understandability)X有效性(Validity)X可维护性功能性(Fu

21、nctionality)X普遍性(Generality)X经济性(Economy)X软软件件质质量量模模型型之之比比较较 34软件质量度量方法(1)Halstead复杂性度量法,基本思路是根据程序中可执行代码行的操作符和操作数的数量来计算程序的复杂性。操作符和操作数的量越大,程序结构就越复杂。(2)McCabe复杂性度量法,其基本思想是程序的复杂性很大程度上取决于程序控制流的复杂性,单一的顺序程序结构最简单,循环和选择所构成的环路越多,程序就越复杂。35Evaluating models评估模型Mean magnitude of relative error(MMRE)相对误差平均值labso

22、lute value of mean of(actual-estimate)/actuallgoal:should be.25 or lessPred(x/100):percentage of projects for which estimate is within x%of the actual估计在实际值x%范围内的项目的百分比lgoal:should be.75 or greater for x=.2536Summary of model performance.ModelPRED(0.25)MMREWalston-Felix0.300.48Basic COCOMO0.270.60In

23、termediate COCOMO0.630.22Intermediate COCOMO(variation)0.760.19Bailey-Basili0.780.18Pfleeger0.500.29SLIM0.06-0.240.78-1.04Jensen0.06-0.330.70-1.01COPMO0.38-0.630.23-5.7General COPMO0.780.2537过程度量过程度量 过程度量是对软件开发过程的各个方面进行度量,目的在于预测过程的未来性能,减少过程结果的偏差,对软件过程的行为进行目标管理,为过程控制、过程评价持续改善提供定量性基础。过程度量与软件开发流程密切相关,具

24、有战略性意义。软件过程质量的好坏会直接影响软件产品质量的好坏,度量并评估过程、提高过程成熟度可以改进产品质量。相反,度量并评估软件产品质量会为提高软件过程质量提供必要的反馈和依据。38软件过程性能的度量模型 39软件过程度量的内容 成熟度度量(maturity metrics)l主要包括组织度量、资源度量、培训度量、文档标准化度量、数据管理与分析度量、过程质量度量等等管理度量(management metrics),l主要包括项目管理度量(如里程碑管理度量、风险度量、作业流程度量、控制度量、管理数据库度量等)、质量管理度量(如质量审查度量、质量测试度量、质量保证度量等)、配置管理度量(如式样变

25、更控制度量、版本管理控制度量等)生命周期度量(life cycle metrics)l主要包括问题定义度量、需求分析度量、设计度量、制造度量、维护度量等。40软件过程度量流程 软件过程度量的一般流程主要包括:l确认过程问题;l收集过程数据;l分析过程数据;l解释过程数据;l汇报过程分析;l提出过程建议;l实施过程行动;l实施监督和控制。41OOOO度量度量OO度量的特性l局域性(局部化)l封装性l信息隐藏l继承性l抽象42局域性(Localization)是指信息被集中在一个程序内的方式。l(1)传统方法:数据与过程分离,功能分解和功能信息局域化。其典型的实现形式为过程模块,工作时用数据驱动功

26、能。l此时的量度放在功能内部结构和复杂性上(如模块规模、聚合度、环路复杂性等)或放在该功能与其他功能(模块)的耦合方式上。l(2)OO方法:局域性基于对象,因为类是OO系统的基本单元,对象封装数据和过程,因此应把类(对象)作为一个完整实体来量度。l另外,操作(功能)和类之间的关联是一对一的。因此,在考虑类合作中的量度时,必须能适应一对多和多对一的关联。43封装(Encapsulation)是指一个项集合的包装l(1)传统方法:记录、数组,只有数据没有过程,为低层次的封装;过程、函数、子例程和段,则只有过程没有数据,为中层次的封装。其量度的重点分别在代码行的数据和环路的复杂性。l(2)OO方法:

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

28、来说,继承性是一个关键性的特性。因此,很多OO系统的量度都以此为重点,如子的数量(类的直接实例数量),父的数量(直接上一代数量),以及类的嵌套层次(在一个继承层次中,类的深度)。46抽象(Abstraction)使设计者只关心一个程序构件的主要细节(数据和过程两者),而不考虑底层的细节。l抽象是一种相对概念,在OO和传统开发方法中都被采用。如处于抽象的较高层次时,我们可忽略更多的细节,当处于抽象的较低层次时,可以引入更多的细节,即提供一个关于概念或项的更详细的看法。l OO量度可用一个类度量的项来表示抽象,如每个应用类的实例化的数量、每个应用类被参数化的数量,以及类被参数化与未被参数化的比例等

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

30、量(NOO):l若NOO大,则导致了弱的类层次和可能难于测试和修改的OO软件。由子类加入的操作的数量(NOA):l当NOA值增大时,子类漂离超类隐含的抽象。当继承树的深度变大时,在层次中低层的NOA值将下降。特例化指标(SI):l特例化可通过加入或删除或覆写来达到,SI=(NOO*层次)/(总的类方法数),SI值越高,越有可能类层次中包含了更多不遵从超类抽象的类。50LK度量方法可用于开发的不同阶段Lorenz and Kidd metrics collection in different phases of development.PhaseMetricRequirementsDescri

31、ptionSystem DesignProgram DesignCodingTestingNumber of scenarioscripts XNumber of key classesXXNumber of support classesXAverage number ofsupport classes per keyclassXNumber of subsystemsXXClass sizeXXXNumber of operationsoverridden by a subclassXXXXNumber of operationsadded by a subclassXXXSpeciali

32、zation indexXXXX1、作为规模度量标准:、作为规模度量标准:用以评估模型预测项目的工作或持续时间2、作为测试实例评估:、作为测试实例评估:有助于测试小组准备测试用例以及将资源分配给将来的测试活动512.CK度量方法 CK度量组由Chidamber和Kemerer提出,他们建议使用6种基于类设计的度量,通称为CK度量组。1.每个类的加权方法(WMC)2.继承树的深度(DIT)3.子女的数量(NOC)4.对象类之间的耦合(CBO)5.对类的响应(RFC)6.方法中缺少内聚(LCOM)CK度量是侧重于设计设计的度量,可以看做是对LK度量的补充。52(1)每个类的加权方法WMC(weig

33、hed Methods per Class)WMC=Ci(i=1n)其中,Ci为一个类的各个方法(或操作或服务)的复杂性,相当于传统方法中的环路复杂性,Ci可相加。方法的数量和它们的复杂性是用来实现和测试一个类工作量总量的指示器。方法的数量越大,继承树(所有子类都继承父类的方法)就越复杂。对一个给定的类,随着方法的数量增大,其应用很可能变得越来越专门化,由此将限制其可能的重用。所以,WMC的值应当合理。53(2)继承树的深度DIT(Depth of the Inheritance Tree)这种量度被定义为从结点到树根的最大长度。DIT的值越大,复杂性就越高。因为随着DIT的增大,层次的类可能

34、会继承许多方法。当试图预测一个类行为时,困难不仅会增大,而且会增加设计的复杂性。当然DIT较大时,则表示有许多方法被重用,这是其好的一方面。54(3)子的数量NOC(Number of children)子类在类的层次内,子类可以最直接地从属于一类。随着子类数量的增大,重用也增加了。但父类抽象的表示可能减少,即一些子类可能不是父类真正的成员,同时,测试数量(用来检查每个子类在操作前后的要求)也将增加。55(4)对象类间的耦合CBO CBO(Coupling Between Object Classes)是指一个类合作(即相关)的数量。当CBO增大时,不仅降低了可重用性,而且使其修改和修改后的测

35、试变得复杂。所以,每个类的CBO值应当保持合理。这与在传统软件中减少耦合的一般原则是一致的。56(5)对一个类的响应RFC(Response for a Class)一个类的响应设置是一组方法,它可能被执行,用来响应接收到的类对象的消息,RFC被定义为响应设置方法的数量。RFC增加,测试序列增加,测试工作量也将增加。由此可以得出,当RFC增大时,类的设计复杂性也将增大。57(6)方法中聚合的不足LCOM(Lack of Cohesion in Methods)一个类内的每种方法访问一个或多个属性(也称实例变量)。LCOM是访问一个或多个相同属性方法的数量。如果LCOM很大,则说明方法可以通过属

36、性与其他方法耦合,这就增加了类设计的复杂性。通常,对LCOM值很大的类,可以把它分为两个或多个单独的类,这样每个类能的设计更方便。这里讲的耦合和聚合与传统软件中所讲的是一样的。我们希望高聚合和低耦合,即保持低的LCOM。但在某些情况下,LCOM值很大也是合理的。58不同开发阶段CK度量的应用Chidamber and Kemerer metrics collection in different phases of development.PhaseMetricSystem DesignProgram DesignCodingTestingWeighted methods perclassXX

37、XDepth of inheritanceXXXNumber of childrenXXXCoupling between objectsXXResponse for a classXXLack of cohesion ofmethodsXXX59MOOD度量方法度量样本如下:1.方法继承因子(MIF)2.耦合因子(CF)3.多态因子(PF)60方法继承因子(方法继承因子(MIFMIF):OO系统的类体系结构针对方法(操作)和属性而使用继承的程度被定义为:MIF=Mi(Ci)/Ma(Ci)对i从1到TC求和其中TC为在体系结构中的类的总数,Ci是在体系结构中的一个类。且:Ma(Ci)=Md(C

38、i)+Mi(Ci)其中Ma(Ci)为可在和Ci关联中被调用的方法的数量,Md(Ci)为在类Ci中声明的方法的数量,Mi(Ci)为在类Ci中继承(未被覆写的)的方法的数量。MIF值提供了继承对OO软件的影响的指示。61耦合因子(耦合因子(CFCF):):CF=ijis_client(Ci,Cj)/(TC-TC)这里针对I从1到TC和j从1到TC求和。函数is_client=1,当且仅当在客户端类Cc和服务器类Cs 间存在关系,且CcCs时is_client=0,否则当CF值增加时,OO软件的复杂性也将增加,而可理解性、可维护性和复用潜力都将受到影响。62多态因子(多态因子(PFPF):):重新定

39、义被继承方法的方法数量,除以可能的不同多态情形的最大数量.这样,PF是对系统中的动态绑定相对数量的间接测量。PF=iMo(Ci)/iMn(Ci)*DC(Ci)这里对i从1到TC求和。且Md(Ci)=Mn(Ci)+Mo(Ci)其中,Mn(Ci)为新方法的数量,Mo(Ci)为覆写方法的数量,DC(Ci)为后代计数(某基类的后代类的数量)63面向操作的量度 根据Lorenz和Kidd的建议,有三种基本量度:(1)平均操作规模OSavg(Average Operation Size)l虽然代码行数可以成为操作规模的指示器,但代码行数的度量与传统软件一样有许多问题。因此,在OO软件中,由操作所传送的消息

40、数量操作所传送的消息数量提供了一个对操作规模度量可选的方法。操作规模增大,表示操作所传送的消息数量增加,数量越大,说明越复杂。(2)操作复杂性OC(Operation Complexity)l一个操作的复杂性可以用传统软件所使用的任何复杂性量度进行计算。因为操作限于特定的职责,所以设计人员应使OC尽可能的小。(3)每个操作参数的平均数NPavg(Average Number per Operation)l操作参数的数量越大,对象间的合作就越复杂。所以,NPavg 一般应尽可能的小。64OO测试的量度 1.封装性 l(1)方法(操作与服务)中聚合的不足LCOM LCOM的值越高,表示更多的状态必

41、须进行测试,才能保证方法不产生副作用。l(2)公共与私有的百分比PAP(Percent Public and Protected)公共属性从其他类继承,所以这些类是可见的。私有属性是专属的,为一特定子类所拥有。这种量度说明类的公共属性的百分比,PAP的值高就可能增加类间的副作用。l(3)数据成员的公共访问PAD(Public Access to Data Member)这种量度说明可访问其他类属性的类的数量,即一种封装的破坏。PAD的值高可能导致类间的副作用。所以,测试的设计必须保证每一种这样的副作用能够被发现。652.继承性 l(1)根类的数量NOR(Number of Root Class

42、es)这种量度是在设计模型中,描述性质各不相同的类层次数量的计算方法。对每一个根类及其子类的层次必须开发相应的测试序列。随着NOR的增大,测试工作量也相应增加。l(2)扇入FIN(Fan In)当扇入用于OO情况时,扇入是一种多重继承的指标。FIN大于1,说明一个类不只从属一个根类,而是继承更多的根类的属性和操作。l(3)子的数量NOC(Number of Children)和继承树的深度DIT(Depth of the Inheritance Tree)正如在OO测试中讨论的,超类的方法(操作、服务)将不得不为每个子类进行重新测试。66OO项目的量度 项目管理人员的任务就是计划、协调、跟踪和

43、控制一个软件项目的进行。其中主要问题就是对软件的实现规模进行估算。因为规模与工作量和开发时间成正比。(1)脚本的数量NSS(Number of Scenario Scripts)脚本的数量或使用用例与满足需求所要求的类的数量、每个类的状态的数量,以及方法(操作)、属性和合作的数量成正比。所以,NSS是程序规模的重要指标。67脚本的数量NSS、关键类的数量NKC和子系统的数量NSUB的量度还可以用来收集与过去OO项目及其整个项目和单个过程活动(如OOA、OOD、OOP和OOT)相关的工作的花费。这些数据也可以与前面讨论过的设计量度一起用来计算生产率量用来计算生产率量度度,如每个开发人员开发类的平均值等。总之,这些量度可以用于估算当前项目的工作量、开发时间、使用人员和其他信息。68

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 生活休闲 > 生活常识

本站为文档C TO C交易模式,本站只提供存储空间、用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。本站仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知淘文阁网,我们立即给予删除!客服QQ:136780468 微信:18945177775 电话:18904686070

工信部备案号:黑ICP备15003705号© 2020-2023 www.taowenge.com 淘文阁