面向对象软件度量方法
面向对象的软件度量方法
【摘要】面向对象度量方法成为面向对象技术研究的一个热点，本文分析和比较目前流行的方法应用背景和优缺点。
【关键字】软件度量，软件结构，面向对象语言，软件重用
Object-oriented software metrics methods
Abstract: Object-oriented software metrics methods are becoming hot point in object-oriented technology. In this paper, I will introduce and compare some of the popular object-oriented software metrics methods.
Key words:software measurement, software architecture, OO programming language, software reuse
1.引言
今天，计算机在我们生活的每个领域几乎都扮演了非常重要的角色。在计算机上运行的软件也越来越重要。因此，可预测、可重复、准确地控制软件开发过程和软件产品已经非常重要。软件度量就是衡量软件品质的一种手段。软件度量或者说软件工程度量领域是一个在过去30多年研究非常活跃的软件工程领域。随着面向对象技术的广泛应用，面向对象软件度量的理论研究和实践应用已成为软件工程领域的研究热点之一，先后出现了一批有效的面向对象的软件度量方法。
2.软件度量概述
2.1.软件度量定义
软件度量（software measurement）是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制和改善。没有软件度量，就不能从软件开发的暗箱中跳将出来。通过软件度量可以改进软件开发过程，促进项目成功，开发高质量的软件产品。度量取向是软件开发诸多事项的横断面，包括顾客满
意度度量、质量度量、项目度量、以及品牌资产度量、知识产权价值度量，等等。度量取向要依靠事实、数据、原理、法则；其方法是测试、审核、调查；其工具是统计、图表、数字、模型；其标准是量化的指标。
2.2.软件度量的目标
软件开发正在经受一场危机。费用超支（特别是在维护阶段的花费太大）、生产率低下、以及质量不高等问题正困扰着它。简言之，软件开发经常处于失控状态。软件之所以失控是因为没有度量。Tom Demarco曾经说过："没有度量就不能控制。"这种说法是好的，但不完全。并不能说为了获得控制必须进行度量。度量活动必须有明确的目标或目的，而正是这决定着我们选择哪种属性和实体进行度量。这个目标与软件开发、使用时所涉及的人的层次有关。
以下主要从管理者和软件工程师两种角度来考虑，为了达到各种目标所要进行的度量工作。
对管理者而言：
1.需要度量软件开发过程中的不同阶段的费用。例如：度量开发整个软件系统的费用（包括从需求分析阶段到发布之后的维护阶段）。必须清楚这个费用以决定在保证一定的利润的情况下的价格。
2.为了决定付给不同的开发小组的费用，需要度量不同小组职员的生产率。
3.为了对不同的项目进行比较、对将来的项目进行预测、建立基线以及设定合理的改进目标等，需要度量开发的产品的质量。
4.需要决定项目的度量目标。例如：应达到多大的测试覆盖率、系统最后的可靠性应有多大等。
5.为了找出是什么因素影响着费用和生产率，需要反复测试某一特定过程和资源的属性。
6.需要度量和估计不同软件工程方法和工具的效用，以便决定是否有必要把它们引入到公司中。
对软件工程师而言：
1.需要制定过程度量以监视不断演进的系统。这包括设计过程中的改动、在不同的回顾或测试阶段发现的错误等等。
2.需使用严格的度量的术语来指定对软件质量和性能的要求，以便使这些要求是可测试的。例如：系统必须"可靠"，可用如下的更具体的文字加以描述："平均错误时间必须大于15个CPU时间片。"
3.为了合格需要度量产品和过程的属性。例如：看一个产品是否合
格要看产品的一些可度量的特性如"β测试阶段少于20个错误。"，"每个模块的代码行不超过100行。"，和开发过程的一些属性如"单元测试必须覆盖90%以上的用例。"等。
4.需要度量当前已存在的产品和过程的属性以便预测将来的产品。例如：
通过度量软件规格说明书的大小来预测目标的大小。
通过度量设计文档的结构特性来预测将来维护的"盲点"。
通过度量测试阶段的软件的可靠性来预测软件今后操作、运行的可靠性。
2.3.软件度量的信息模型
度量信息模型是将已定义的信息需要与实际要度量的项目软件过程、产品和实体联系起来的机制。它为相关的度量概念建立了一个已定义的结构，而且为在组织内准确地交流度量结果提供了基础。下图是有关度量信息模型的关系。
一般情况软件度量的信息需求可分为七类：
进度和进展，这个信息分类是针对项目里程碑的实现以及个人工作单元的完成。落后于进度的项目要想满足它的交付目标，通常只能削减功能或是牺牲产品质量。
资源和成本，这个信息分类是关于在被执行的工作与分配给项目的人力资源之间的平衡。超出预算工作量的项目通常只能通过削减软件功能或牺牲产品质量来进行补偿和恢复。
产品规模和稳定性，这个信息分类针对功能的稳定性阻及要求的软件能力。该信息分类还与交付的用来提供所需能力的软件容量有关。稳定性包括功能范围或数量的变更。软件规模的增长通常要求增加所用的资源或是延长项目的进度计划。
产品质量，这个信息分类针对已交付的软件产品无故障地支持用户需
要的能力。若交付了低质量的产品，则使其正常运转的责任通常落在负责维护的组织身上。
过程性能，这个信息分类涉及与项目需要相关的供应商的能力。缺乏软件开发过程或低生产率的供应商，可能难以满足积极进取的项目进度和成本目标。
技术有效性，这个信息分类针对所建议的技术方法的可行性。它针对工程方法，如软件复用、商业软件构件的使用、对高级软件开发过程的依赖以发通用软件构架的实现。如果已提出的技术方法中的关键元素无法实现，则可能导致成本的增加和进度的拖延。
客户满意度，这个信息分类针对项目交付的产品与服务满足客户期望的程度。满意度的指示器可以从客户的反馈和所要求的客户支持的级别获得。
下表给出了信息需求与可测量概念的对应关系。
3. 面向对象软件度量的常用方法
近年来面向对象技术的兴起，在面向对象分析、设计、面向对象程序设计语言（OOPL ）和工具上发展很快，且已得到广泛应用。面向对象技术采用数据抽象、封装、继承、多态性、信息隐藏、重用机制等，为提高软件的可重用性，增强可维护性、可靠性，提高生产效率等方面提供了可能。这些机制在传统的软件开发中是不完善的或缺少的。面向对象系统强调的是对等实体之间的关系而不是传统控制流所决定的层次分解关系。传统的度量有一定的局限性，而且对某些面向对象特性根本无法度量，因此需要新的度量来反映。目前比较常用的面向对象的软件度量的方法有：c ＆K 度量方法、Chen & Liu 度量方法、M00D 度量方法。
3.1. C&K 度量方法
Metric 1：每个类的加权方法数WMC(weighted Methods per Class) 定义：设类C1有方法M1?Mn ，C1?Cn 分别为M1?Mn 的复杂度则
WMC=i n
i C ∑=1
这里具体方法中的复杂度是用传统的软件设计中复杂度来计算的。WMC 揭示了开发和维护类的时问和精力。类的WMC 越大对子类的可能影响越大，其通用性和可复用性就越差。
Metric 2 ：继承树的深度DIT(Depth of Inheritance)
定义:DIT 指对象所属类在继承树中的深度(层次)，其中树根为0。类的DIT 大，表示它的可能继承方法数日大，复用程度高，但预测它的行为将更困难，同时设计复杂性大。
Metric 3：孩子数目NOC(Number 0f Children)
定义：NOC=继承树中的一十类的直接孩子的数目。类的NOC 越大，重用越好，表示该类在设计中有很大影响，此类应成为测试重点。
Metric 4：对象类之间耦合CBO(Coupling Between Object classes) 定义：一个类的CBO 是它与别的类有耦合关系的类的数目。
对象类间过多的耦合对模块化设计和重用是有害的。一个类越独立，它就越容易被另一个应用重用。类的CBO 越大，设计中对另一部分的敏感越大，因此，维护越难。
Metric 5：一个类的响应集合RFC(Response For a Class)
定义：RFC=|RS|，RS 是该类的响应集合。类的RFC 越大，该类测试和调试将更复杂，复杂度越大。
Metric 6：类内聚缺乏度LCOM(Lack of Cohesion in Methods)
定义：类C1有n 个方法M1?Mn ，设{Ii} = 被方法Mi 使用的实例变量集合P={(Ii ，Ij)|Ii ∩Ji=Ф)，Q={(Ii ，Ij)|Ii ∩Ij ≠Ф)，则LCOM=|P|—|Q|，当|P|>|Q|时，如果Ii ∩Ij=Ф，方法Mi 和Mj 为无关方法对，否则为相关方法方法对。
设计中希望类的内聚度越大越好，因为这样可以提高封装度。类的LCOM 越大，意味着类可以分裂成两个或更多的子类。类的LCOM 大会增加类复杂度，在开发过程中出话的可能性加大。
3.2. Chen 和Liu 方法
1. 操作复杂性度量(operation complexity metric)：定义为类中各操作
的复杂性之和。
2. 操作参数复杂性度量(operation argument complexity metric)：定义
为∑)(i P ，这里P(i)是类中每个操作的操作参数i 的值。
3. 属性复杂性度量(attribute complexity metric)：定义为∑)(i R ，
这里R(i)是类中属性i 的值。
4. 操作耦合度量(operation coupling metric)：度量该类的操作与其
它类的操作的耦合度。
5. 类继承性度量(class hierarchy metric)：此度量是从下面4个方面度
量的。
类在继承树中的深度；
该类的超类的数量；
该类直接超类的数量；
该类通过继承或在本地定义的操作的数量。
6. 内聚度量(cohesion metric)：度量类的内聚性。
7.类耦合度量(classic coupling metric)：此度量是从下面三个方面度
量。
可以存取别的类的数量；
可被别的类存取的数量；
可以互操作类的数量。
8.重用度量(reuse metric)：该度量是考察该类是否为重用的类。
Chen和Liu提出的度量指标考虑了面向对象技术的特点，由于没有给出形式化定义，缺乏可操作性，没有引起学术界的重视。
3.3.M00D度量方法
M00D度量方法是从封装、继承、耦合、多态性四个方面提出了6个度量指标。
3.3.1.封装
MOOD对封装的度量提出了两个指标：方法隐藏因子MHF(Method Hiding Factor)和属性隐藏因子AHF(Attribute Hiding Factor)。
MHF的定义如下：
这里Md(Ci)是类中定义的方法数目，Tc是类的总数目。
对于系统中所有类，c1，c2。?，cn，假如方法可以被别的类使用，记为o，不能就记为I。系统中不被其它类调用的方法数除以系统中定义的方法总数耳，就得出系统内隐藏的方法的百分比。
AHF也是以同样的方法定义的，只是使用属性，而不是方法。
数据封装(简单地说封装)经常被用于衡量一个语言隐藏具体实现的能力。通常我们可以用信息隐藏来定义。度量信息隐藏的属性是代码的可见性(code visibility)。AHF和MHF使用类的属性和方法对其它类的代码的可见性来度量信息隐藏。
3.3.2.继承
MOOD度量方法中对继承的度量使用了两个指标：方法
继承因子(AIF)和属性继承因子(MIF)。定义如下：
计算MIF时，对于系统中每一个类c1，c2?cn，假如方法不是继承的记为0，是继承的记为1。系统中总的继承方法数目除以系统中总的方法数目就得出了MIF的值。AIF也是用同样的方法来定义的。
3.3.3.藕合
M00D方法中使用耦合因子(CF)来度量类之间的耦合，CF定义如下：
CF的计算考虑到了所有可能的类对集合，判断每对类之间是否存在通过消息传递或通过语义联系(一个类的方法或属性被另一个类引用)产生的耦合,就耦合来说。这两种耦合关系是相等的。
一个系统的CF的值，对于衡量系统的复杂性、封装性，可重用性、可理解性和可维护性具有重要意义。我们可以凭直觉判断出CF值越大，系统的封装性越差，重用的可能性越低，可理解程度越低，维护的困难越大。但我们很难说，耦合度越高。系统变得越复杂。例如，我们很容易构造一
个耦合度很高的的简单系统。大量的经验数据在这方面可能会有助于我们分析CF值的范围对于这些外在属性的影响。
3.3.
4.多态
MOOD度量方法中用多态园子(PF)来度量系统中存在多态的可能性。PF定义如下：
PF的计算是重新定义继承的方法数目除以可能出现多态情况(子孙类的新方法是重载的)的量大方法数目得出的。因而，PF反映了一十系统的动态连接(dynamic binding)情况。Brito和Abreu从系统级提出了度量指标并给出了形式化定义。很显然，该方法是符合上述11条标准的。
3.4.小结
目前，使用C＆K度量指标开发的度量工具已有广泛的应用。DIT、NOC 反映了继承程度，CBO、RFC提供了耦合度量指标，LCOM可以反映类的封装性。但C＆K度量指标没有多态性度量指标，是令人遗憾的方面。
MOOD从继承、耦合、封装和多态4个方面直接给出了度量值。可以看出两者都反映出面向对象技术的特点，并给出了形式化的度量公式，都具有很好的可操作性。但考虑的角度是有区别的。例如，耦合性度量(CBO 和CF)非常相似。CBO提供了从类一级考虑的耦合，但CF则是系统级的观点。从两种度量指标的定义，我们认为C&K度量指标是从类一级出发考虑的，它对系统设计和开发大有帮助。而MOOD度量指标提供了对一个系统的判断。它将对工程管理者较为有用。这些指标的有效性还有待于进一步的验证，尤其是这些度量指标(即度量元)与系统的外在质量属性方面的因果联系，例如与复杂性、可靠性、可维护性、可测试性等质量特性的形式化的关系到目前为止还没有建立。这方面的研究对于软件度量学的发展具有重要意义。
4.总结
面向对象的软件度量学经过多年的发展，在理论与实践方面都取得了很大的进步，但也必须看到它依然存在不少的问题，主要表现在以下几个方面, 面向对象软件度量学缺乏坚实的理论; 目前的研究还是度量体系的第三层，即度量元的研究，如何在此基础上建立软件度量体系，需要运用统计学知识与神经元网络研究成果; 如何在实际开发中应用软件度量学成果指导整个软件开发过程，目前还只能做到定性的分析。
参考文献
[1]《面向对象度量方法》，《小型微型计算机系统》，2001年11期邢大红，管菅，曹佳冬，刘宗田，李心科
[2]《基于度量的软件过程管理方法与分析技术的研究》，2006 西北大学：计算机软件与理论，侯红
[3]《软件度量学综述》，《计算机工程与应用》2001年1期邢大红，曹佳冬，汪和才，刘宗田，Xing Dahong，Cao Jiadong，Wang Hecai，Liu Zongtian [4] Learning a Metric for Code Readability，IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 36, NO. 4, JULY/AUGUST 2010，546-558
[5] Using Software Dependencies and Churn Metrics to Predict Field Failures: An Empirical Case Study，Empirical Software Engineering and Measurement，Nachiappan Nagappan，Thomas Ball
面向对象方法题库1-0-5
面向对象方法题库1- 0-5
问题： [单选]当（）时，用例是捕获系统需求最好的选择。 A.系统具有很少的用户 B.系统具有很少的接口 C.系统算法复杂，功能单一 D.系统有很多参与者 用例描述的是系统的执行者（参与者）与系统的交互，同时也是开发人员与用户进行交流的工具，可用来很好地定义系统的边界。所以，当执行者较多的时候，用例是捕获系统需求最好的选择。
问题： [单选]对OO系统的技术度量的识别特征，Berard定义了导致特殊度量的特征。其中（）抑制程序构件的操作细节，只有对访问构件必需的信息被提供给其他希望访问的构件。 A.局部化 B.封装 C.信息隐藏 D.继承 面向对象的软件和用传统方法开发的软件有本质的不同，为此，对OO系统的技术度量必须调整以适应那些区别OO和传统软件的特征。Berard定义了5个导致特殊度量的特征，分别是局部化、封装、信息隐蔽、继承和对象抽象技术。 （1）局部化。局部化是软件的一个特征，它指明信息在程序中被集中的方式，例如，针对功能分解的传统方法围绕功能局部化信息，它们典型地以过程模块来实现。数据驱动方法围绕特定的数据结构局部化信息。在OO语境中，信息是通过封装数据和处理在类或对象的边界内而集中的。因为传统软件强调函数为局部化机制，软件度量着重于函数的内部结构或复杂性（例如，模块长度、内聚性或环路复杂性等）或函数间相互连接的方式（例如，模块耦合）。因为类是OO系统的基本单位，所以，局部化是基于对象的，因此，度量应该应用于作为一个完全实体的类（对象）。此外，在操作（函数、方法）和类间的关系不必要是一对一的。因此，反应类协作方式的度量必须能够适应一对多和多对一的关系。
软件度量总结(精)
软件度量总结 这次总结的结构比较简单,就是按照五个章节分别阐述了自己的理解。 一.软件度量的应用范围。 经过这一阶段的学习,我认为想要明白软件度量,首先要分清度量和测量的区别。度量具有前置性,它提供了一种定量研究软件问题的方法;测量具有实时性或后置性,主要集中在给度量提供数据或者处理数据的方法上。由于软件工程强烈的不确定性,使得软件工程的精确测量困难重重,但软件度量主要研究的是可能性的规律,通过概率和统计学的研究,寻找事物内在的规律。其并不具备 1+1=2的特征, 而是研究在多大可能性上这个结论是合理的,因为软件的主体是人,具有概率属性,设备和材料容易度量,但人很难度量。软件度量的主要作用是评估状况、跟踪进展情况、评价产品有效性和改进设计和过程的质量。定性分析可以提供迅速地判断能力,但定性分析终究需要定量分析的验证与支持,否则其结果很可能成为无目之本,出现错误。 软件度量的方法体系主要包括 5个方面:1. 项目度量,目的在于度量项目规模、成本、进度、顾客满意度等,辅助项目管理进行项目控制; 2. 规模度量,主要依靠经验和经验的模型,是决定项目成败的重要原因之一,是估算工作量、成本预算及策划项目进度的基础; 3. 成本度量, 4。产品度量,实质上是软件质量的度量,软件的质量由一系列质量要素组成,每个质量要素又由一些衡量标准组成,主要肚量方法是McCabe 复杂性度量法; 5,过程度量,对软件开发过程的个各方面进行度量,目的在于预测过程的未来属性,减少结果的偏差,主要包括成熟度度量(例如 CMMI, GJB5000A、管理度量(主要包括里程碑管理、风险度量等项目管理度量,审查度量、质量保证度量等质量管理度量,变更控制、版本管理度量等配置管理度量、生命周期度量三个大的方面。 不同层次的人员对软件度量有不同的需求。高级管理人员,如 CEO 、 COO ,关注点在上市时间、客户满意度、费用的节省等商业策略的组成部分上;中级管理层,如部门经理、总监等,则主要关注生产力、成本控制、效率等,他们更多的是着眼于
软件度量复习要点、考点_daisy
软件度量考试复习 测量定义：用数字或符号来表示真实世界中实体属性从而根据定义的规则来表示实体的过程。度量定义：由用户和设计者一同设想的用来在可信和有意义的方式中显露出的的选择的特性。软件度量的定义：用来量化软件产品，软件开发资源和/或软件开发过程的度量。包括可直接测量的对象如代码行，也包括通过测量计算得到的对象如软件质量。 1．测量有哪些尺度类型？各有何区别？ 答：测量有标定尺度、类型尺度、序列尺度、间隔尺度、比例尺度、绝对尺度。标定和类型尺度属于语言尺度(Linguistic)。标定尺度给出了唯一且不含糊的概念名称并且定义技术也属于标定尺度；类型尺度识别实体中已经定义且命名的类型或种类（categories），也叫绝对标定尺度。序列尺度估计已测量的实体的值并将他们按顺序重组排列，值和顺序均表达为字符或符号。间隔尺度、比例尺度和绝对尺度属于定量尺度。间隔尺度用于发现增长间隔而不是比例，没有不合理的0间隔（后半句话翻译不好）；比例尺度允许比例的计算并且允许合理的0参考点；绝对尺度用于计数(count)，只有一种可能的绝对属性测量。 测量作为一个过程，有哪些阶段？ 答：测量作为过程，有3个阶段：感知(Cognitive)、语义(Semantic)、数字化(Quantitative)。2．软件度量的实体有哪些？如何采用GQM定义度量框架？GQM中如何描述目标？ 答：软件度量的实体类型： ①过程（process）：软件开发中活动的集合。不同的软件开发模式中，所采用的流程和活动也不一样； ②产品（product）：软件过程活动的结果，可以是一个程序、一个软件文档或其他任何 交付物； ③资源（resource）：实施这些活动所需要的对象，可能是人力、设备、时间等。 GQM定义度量框架： 1。确定目标；2。细化感兴趣的问题列表；3。定义需要回答这些问题的度量标准；4。 开发数据收集和分析的工具和机制；5。收集并验证数据；6。通过事后剖析的方式分析数据以评估是否与目标一致，并为其后的改善提供意见；7。为利益相关者提供反馈信息。 GQM中如何描述目标： GQM中目标有4个部分：一个感兴趣的对象（一个实体）、一个意图、一个观点、一个对环境和约束的描述。 3．在度量数据的频域分析中，如何描述测量数据的散步度？ 答：散步度描述了被测量（观察）数据在数据集中是怎样分布的。主要通过以下3个参数来反映：极差是资料组（数据集）中最高和最低值之差；方差测量观察值的波动范围；标准差是方差的平方根。 4．什么是功能点分析？特征点、对象点、和功能点有何不同？ 答：功能点分析是对产品中为调整的函数数量(UFC)及值调整因子(VAF)的分析计算。 FP=UFC*VAF。生产率=FP/人月。文档=文档页数/FP。 特征点分析扩展了功能点计数到实时和TLC环境(MIS&RT&SC)。当应用的算法数量及逻辑数据文件数相同时，功能点和特征点产生相同的结果；应用于MIS项目时，结果通常完全相同；当应用于更复杂的系统软件形态时，特征点的计数要高的显著的多。
软件开发度量及考核方法精修订
软件开发度量及考核方 法 集团标准化工作小组 #Q8QGGQT-GX8G08Q8-GNQGJ8-MHHGN#
本人觉得如果要提高软件开发人员的开发质量，必须有相应的考核制度，有了制度后才能推动开发人员想方设法改善自已的开发质量。虽然目前很多公司有这方面的绩效考核，但是大多数没有对软件开发的过程进行细粒度的度量，所以不能依据有效的度量数据来考核开发人员的工作绩效，大部份只是凭考核人主观意志来考核，不能形成对被考核人有效的说服力。以下文档是本人根据以前经验和相关的资料所编写的度量方法和考核方法，希望能对公司改善考核制度有用。由于时间有限，有不足之处，请各位仁兄多提意见，谢谢！ 1 目的 对软件开发的过程所产生的软件项的质量和过程进行定量的评价，用评价的结果指导软件的开发过程，不断地提高软件开发质量水平，并依据度量记录来考核软件开发人员的工作绩效。 2 软件项包括 1）技术文档：参照公司"软件工程产品集"，所确定的配置项；主要包括：可行性分析报告、需求分析报告、软件功能规格说明、开发计划、质量计划、系统设计报告、测试文档、技术报告、用户手册、总结报告等； 2）计算机程序。 3 度量数据的来源 1）项目计划； 2）评审报告； 3）测试报告； 4）问题报告； 5）软件维护记录； 4 质量度量 度量指标 主要根据各类软件项检查表的检查指标来确定，例如，软件需求规格说明书检查表（见附录1），有10个检查指标，则根据具体项目检查侧重点不同，可从中选择相应的检查指标作为度量指标。 质量等级 1）软件项的质量等级的确定根据度量综合指标进行。 2）度量综合指标计算公式为：Total = ∑QiMi。 3）其中i=1,2,...n代表指标数量； 4）Q代表度量的指标； 5）M代表度量的指标Q在整个指标体系中所占的权重系数，对不同的开发项目可能不同，此系数根据开发的不同着重点给出。 度量指标权重系数表： 序号指标权重 1 指标1 权数1 2 指标2 权数2 3 指标3 权数3 4 指标4 权数4 5 指标5 权数5 加权平均分 6）质量评价：一般地，根据度量综合指标值，有以下评分标准。 质量评价计分标准表 序号得分质量评价 1 ～优质
如何进行有效的软件度量
- 如何进行有效的软件度量 什么是软件度量 软件度量（Software Measurement）是通过各种不同的量度(metric)对软件生命周期中的各个元素进行度量(Measure)，它能够为项目管理者提供有关项目的各种重要信息，同时也是进行大多评估活动的基础。 "软件度量"是一个包含很多完全不同的活动的术语。它主要包括：费用和工作量估计模型和度量、生产率度量模型和标准、质量控制和保证、数据收集、质量模型和度量、可靠性模型、性能评价和模型、算法/计算复杂性度量、结构和复杂性度量、GQM法(Goal/Question/Metric)、其他等。 通常度量程序是由一些软件工程组在组织中进行实施，而这种用于量化软件过程的决策手段实际上能为所有涉及软件的人或部门带来好处： 1.项目经理得益于在计划及控制软件项目时作出相关决策； 2.项目成员能聚焦于工作的改进； 3.软件配置管理组能关注于产品的完整性； 4.软件质量保证组则能专注于过程的保证； 5.当然用户则关于软件产品的最终使用； 6.除此以外，其他涉及并关心软件过程及产品的职能部门都能以此作出相关决策。为什么需要软件度量 在软件开发中，软件度量的根本目的是为了管理的需要，利用度量来改进软件过程。 在软件开发的历史中，我们可以意识到，在60年代末期的大型软件所面临的软件危机反映了软件开发中管理的重要性。而对于管理层人员来说：没有对软件过程的可见度就无法管理;而没有对见到的事物有适当的度量或适当的准则去判断、评估和决策，也无法进行优秀的管理。 我们说软件工程的方法论主要在提供可见度方面下工夫。但仅仅是方法论的提高并不能使其成为工程学科，这就需要使用度量。 度量是一种可用于决策的可比较的对象。度量已知的事物是为了进行跟踪和评估。对于未知的事物，度量则用于预测。 事实上现在在软件工程的主流里度量却被忽略了。现在的情况是： ■当我们在设计和开发软件产品的时候，我们并未能制定出度量的目标。例如：我们保证说我们将使用户界面友好、可靠、易于维护;而并未使用度量的术语来详细说明它们的具体含义。Gilb曾经说过：所谓模糊目标定理，就是没有明确目标的项目将不能明确地达到它的目标。 ■我们未能对构成软件项目实际费用的各个不同的部分进行有效的度量。譬如：通常我们并不知道，和测试阶段相比，设计阶段花费时间多大。 ■我们并未试图使我们开发的产品的各种质量合格。因此我们未能使用术语(如：在一段时间里使用故障的可能性、把产品安装到新环境中需花费的工作量等)向潜在的用户说明产品的可靠性很高。 ■我们总是试图说服自己使用另一种新的革新的开发技术和方法进行软件开发 事实上，我们在软件度量方面做的工作很少很少，而且所作的度量方面的工作也与一般科学意义上的度量相分离。我们经常会看到诸如此类的话："软件的费用有80%花费在维护上。"或"软件每一千行程序中平均有55个Bugs。"。但是这些话并没有告诉我们这样的结果是怎样产生的、试验是怎样设计、执行的、度量的是那个实体、及错误的框架是什么等等。没有这些东西，我们就不能在我们自己的环境中客观地进行反复度量，重现度量的结果
基于CMMI的软件过程度量
摘要：CMMI为软件产品及软件过程提供了一套定量的表示和分析，即软件度量的模型。有效的软件度量过程能促进组织的软件过程能力的改进。文章结合国内应用特点，介绍了基于CMMI的多层架构软件产品的度量模型，并着重讨论了基于CMMI的软件过程度量，总结了软件过程度量的工作方法和思路，提出了解决国内软件度量的一般性方法，为软件过程改进提供了可行的方法和实践。 关键词：CMMI；软件度量；软件过程能力；度量项；门限值 0引言 软件度量的目的是为项目管理提供项目的执行情况的充分可见性，并使项目管理者了解项目实际进展与项目计划之间的偏差，以便采取纠正行动，保证项目的顺利进行。有效的软件度量过程促进组织的软件过程能力的改进。软件度量是软件特性的定量表示和分析方法；软件度量可分为软件产品度量和软件过程度量两类。软件产品度量(定量表示和分析软件产品特性)是独立于产品生产过程的度量；软件过程度量(定量表示和分析软件过程特性)是为管理者提供产品生产过程的状态信息和指导依据。 软件产品度量的要素为质量要素、评价准则、度量元。这里软件过程度量主要通过需求度量、规模度量、进度度量、工作量度量、风险管理度量、质量保证度量来分析。 1三层架构软件产品度量 1．1质量要素 软件质量可分解成六个要素，这六个要素是软件的基本特征。功能性：软件所实现的功能满足用户需求的程度；可靠性：在规定的时间和条件下，软件所能维持其性能水平的程度；易用性：对于一个软件，用户学习、操作、准备输入和理解输出时所做努力的程度；效率：在指定的条件下，软件实现某种功能使用计算机资源(包括时间)的有效程度；可维修性：为了满足用户需求、环境改变或发生软件错误时，对软件进行相应修改所需的努力程度；可移植性：软件从一个计算机系统或环境转移到另一个计算机系统或环境的难易程度。 1．2评价准则 评价准则包括：精确性、健壮性、安全性、通信有效性、处理有效性、设备有效性、可操作性、培训性、完备性、一致性、可追踪性、可见性、硬件系统无关性、软件系统无关性、可扩充性、公用性、模块性、清晰性、自描述性、简单性、结构性、产品文件完备性。 1．3度量元 根据软件的需求分析、概要设计、详细设计、实现、组装测试、确认测试和维护与使用七个阶段，制定针对每一个阶段的度量元。 2基于CMMI软件过程度量 从软件企业的观点出发，软件度量(software Measurement)是通过各种不同的量度对软件生命周期中的各个元素进行度量(Measure)，为项目管理者提供有关项目的各种重要信息，也是进行软件评估活动的基础。 Carnegie Mellon大学的SEI提出了以下的一个软件度量过程体系结构图：
软件开发度量及考核方法
软件开发度量及考核方法 一、引言 如果要提高软件开发人员的开发质量，必须有相应的考核制度，有了制度后才能推动开发人员想方设法改善自已的开发质量。虽然目前很多公司有这方面的绩效考核，但是由于软件开发行业的特殊性，大多数公司没有对软件开发的过程进行细粒度的度量，所以不能依据有效的度量数据来考核开发人员的工作绩效，大部份只是凭考核人主观意志来考核，不能形成对被考核人有效的说服力。所以根据以前经验和相关的资料编写了适用于本部门的度量和考核方法。该考核方法是技术支持部软件开发人员和测试人员的试行版本。 二、目的 对软件开发的过程所产生的软件项的质量和过程进行定量的评价，用评价的结果指导软件的开发过程，不断地提高软件开发质量水平，并依据度量记录来考核软件开发人员的工作绩效。 三、考核实施办法 1、定义 1.1 、软件项包括 1）、技术文档："软件工程产品集"所确定的配置项。主要包括：用户需求文档、需求分析文档、概要设计文档、详细设计文档、开发计划、测试文档、用户手册、总结报告等。 2）、计算机程序。 1.2 、度量数据的来源 1）、项目计划：过程度量中及时度考核数据的主要依据。 2）、测试文档：计算机程序质量考核数据主要依据。 3）、软件维护记录：主要是指软件产品投入用户使用后产生的软件维护记录。
2、质量度量 2.1度量指标 主要根据各类软件项检查表的检查指标来确定。例如，详细设计说明书检查表有10个检查指标，则根据具体项目检查侧重点不同，可从中选择相应的检查指标作为度量指标。（本文末尾附了各工作阶段的考核检查指标表） 2.2质量等级 1）软件项的质量等级的确定根据度量综合指标进行。 2）度量综合指标计算公式为： Total =刀QiMi。 3）其中i=1,2,...n 代表指标数量； 4）Q代表度量的指标； 5）M代表度量的指标Q在整个指标体系中所占的权重系数，对不同的开发项目可能不同，此系数根据开发的不同着重点给出。
软件过程度量数据
Metric 度量Definition 定义 Baseline 基线 LCL 下限 UCL 上限 Allocated Requirements Stability Index 分配需求稳定性指数(%) (1 ? (number of allocated requirements modified, added or deleted / total number of initial allocated requirements)) * 100 (1 ? (修改、增加 或删除的分配需 求数 / 初始的分 配需求数)) * 100 96 88 100 Software Requirements Stability Index 软件需求稳定指数(%) (1 ? (number of software requirements modified, added or deleted / total number of initial software requirements)) * 100 (1 ? (修改、增加 或删除的软件需 求数 / 初始的软 件需求数)) * 100 90 70 100 Duration Variance 持续时间偏差(%) ((actual duration ? planned duration) / planned duration) * 100 ((实际持续时间－ 计划持续时间) / 计划持续时间) * 100 23 11 35 Schedule Slippage 进度偏移 (%) ((actual end date ? planned end date) / planned duration) * 100 ((实际结束时间－ 计划结束时间) / 计划持续时间) * 100 14 2 26
软件项目量化管理方法
软件项目量化管理方法 摘要：本文在对软件企业量化管理应用常见问题分析的基础上，以解决可操作性、可比性等问题为着眼点，识别出了量化管理中必须明确的四要素，表述了企业在量化四要素上采用的常见做法。 本文采用80/20原则，说明了企业在识别度量对象时应避免的问题；采用持续改进的理论，说明了企业在量化管理应遵循的客观规律。在结合平衡记分卡与目标驱动组合式的量化管理方法理论基础上，提出了软件企业的量化管理的具体应用步骤。 关键词：量化管理四要素80/20原则持续改进GQ(I)M 1.引言 如今，很多国内软件企业选择采用能力成熟度系列模型（Capa bilityMaturityModel,CMM）或其它模型来建立本企业的软件过程规范，欲通过提升软件过程的能力达到提高产品质量、降低开发风险、减少开发成本、保证产品按时交付等目的。将软件过程规范的一个目的就是使软件过程可视化，这个可视化则要求了
对软件过程的量化；而产品质量是否提高、开发风险是否降低、开发成本是否减少、项目延期是否缩短，对这些问题的回答则要求了对软件项目的量化；软件过程改进与量化管理息息相关。不少企业在将识别出的量化管理方法应用于软件项目管理过程时，发现不少问题。最为常见的是： 量化工作的可操作性不强，如：部分量化数据难以收集、难以统计投入的成本没有得到预期的产出。如：量化工作投入了成本，但形成的量化结果参考价值不高提供给管理层用于决策的支持数据也不够，数据缺乏可比性量化结果不是管理层所关心的，达不到管理层预期的过程可视化程度 针对此类问题，本文识别出了在量化管理中必须要考虑的四个方面，即：量化四要素，并从量化四要素对量化管理方法进行了分析，建议了软件企业采用的量化管理方法。 2.量化四要素 “只有通过对产品、过程的度量，才能描述、评价、提高产品与过程”。
软件开发度量及考核方法
0 引言 本人觉得如果要提高软件开发人员得开发质量,必须有相应得考核制度,有了制度后才能推动开发人员想方设法改善自已得开发质量。虽然目前很多公司有这方面得绩效考核,但就是大多数没有对软件开发得过程进行细粒度得度量,所以不能依据有效得度量数据来考核开发人员得工作绩效,大部份只就是凭考核人主观意志来考核,不能形成对被考核人有效得说服力。以下文档就是本人根据以前经验与相关得资料所编写得度量方法与考核方法,希望能对公司改善考核制度有用。由于时间有限,有不足之处,请各位仁兄多提意见,谢谢！ 1 目得 对软件开发得过程所产生得软件项得质量与过程进行定量得评价,用评价得结果指导软件得开发过程,不断地提高软件开发质量水平,并依据度量记录来考核软件开发人员得工作绩效。 2 软件项包括 1)技术文档:参照公司"软件工程产品集",所确定得配置项;主要包括:可行性分析报告、需求分析报告、软件功能规格说明、开发计划、质量计划、系统设计报告、测试文档、技术报告、用户手册、总结报告等; 2)计算机程序。 3 度量数据得来源 1)项目计划; 2)评审报告; 3)测试报告; 4)问题报告; 5)软件维护记录; 4 质量度量 4、1 度量指标 主要根据各类软件项检查表得检查指标来确定,例如,软件需求规格说明书检查表(见附录1),有10个检查指标,则根据具体项目检查侧重点不同,可从中选择相应得检查指标作为度量指标。 4、2 质量等级 1)软件项得质量等级得确定根据度量综合指标进行。 2)度量综合指标计算公式为: Total = ∑QiMi。 3)其中i=1,2,、、、n代表指标数量; 4)Q代表度量得指标; 5)M代表度量得指标Q在整个指标体系中所占得权重系数,对不同得开发项目可能不同,此系数根据开发得不同着重点给出。 度量指标权重系数表: 序号指标权重 1 指标1 权数1 2 指标2 权数2 3 指标3 权数3 4 指标4 权数4 5 指标5 权数5 加权平均分1、0 6)质量评价:一般地,根据度量综合指标值,有以下评分标准。 质量评价计分标准表 序号得分质量评价 1 9、0～10、0 优质 2 8、0～8、9 良好 3 6、0～7、9 合格
软件过程度量方法
软件过程度量方法 摘要:近年来,过程越来越受到重视,但过程是否行之有效,不得而知,于是度量过程成为过程管理中的重要一环。本文主要论述了软件过程度量的方法! 关键词:过程度量调和不同度量的方法度量计划采集数据 测度对于任何工程学科而言都是基本的,软件工程也不例外。软件度量是指计算机软件中范围广泛的测度。测度可以应用于软件过程中,目的是在一个连续的基础上改进它。测度也可以用于整个软件项目中,辅助估算、质量控制、生产率评估、及项目控制。最后,软件工程师使用测度能够帮助评估技术工作产品的质量,且在项目进行中辅助决策。 1、管理与度量过程行为 软件过程,它是指一个软件项目或部门所使用的任何过程或子过程。一个过程行为度量的框架:(1)阐明商业目标:弄清商业目标、目的、政策、计划是怎样与软件过程发生联系。基于功能、成本、面世时间,以及质量的商业目标都存在项目和过程问题,要为客户提供有竞争力的产品和服务,能兑现对客户的承诺,则必须着力解决这些问题。(2)确定问题并安排优先次序:确定关键问题,调查研究的首选过程是那些以前出现过问题的或有过争议的过程,或者是第一次执行的过程。(3)选择和定义度量:选择有助于刻画过程或产品的度量,为选择的度量定义一个可操作的定义。(4)采集、验证和保留数据:采集数据,目的在于使过程可视化或分析可归属的原因和寻找可能的改进措施。(5)分析过程行为:用适当的计算(根据数据)在控制图上画出度量数据。(6)估算过程性能:在分析了过程性能的度量后的三种结果之一:排除可确定可归属的原因、变更过程,或继续改进过程。 2、度量计划 度量软件过程从制定计划开始。制定度量计划过程可分为三个阶段:(1)确定过程管理问题;(2)选择和定义相应的产品和过程度量;(3)把最终的度量活动集成到组织当前的软件过程中。 经验表明,确定关键因素很重要,因为这些因素影响过程达到既定目标。我们称关键因素为问题,问题不一定是难题,它们描述了需要关注的情况,标识过程问题需要首先阐明商业目标和目的,确定关键过程,然后列出每一个关键过程的目标,列出与过程有关的待解决的问题领域,最后把列出的代解决问题归到公共的领域或不同的专题中。每个过程都至少有3~4个共有的特性,其中这些相同点,与过程有关的问题有4个,是每一个参与过程管理人员都要考虑的:(1)产品质量(规格说明、规定公差、使用限制和缺陷);(2)过程时间或持续时间;(3)产品交付和过程成本。 3、采集数据
软件开发度量及考核方法
0 引言 本人觉得如果要提高软件开发人员的开发质量，必须有相应的考核制度，有了制度后才能推动开发人员想方设法改善自已的开发质量。虽然目前很多公司有这方面的绩效考核，但是大多数没有对软件开发的过程进行细粒度的度量，所以不能依据有效的度量数据来考核开发人员的工作绩效，大部份只是凭考核人主观意志来考核，不能形成对被考核人有效的说服力。以下文档是本人根据以前经验和相关的资料所编写的度量方法和考核方法，希望能对公司改善考核制度有用。由于时间有限，有不足之处，请各位仁兄多提意见，谢谢！ 1 目的 对软件开发的过程所产生的软件项的质量和过程进行定量的评价，用评价的结果指导软件的开发过程，不断地提高软件开发质量水平，并依据度量记录来考核软件开发人员的工作绩效。 2 软件项包括 1）技术文档：参照公司"软件工程产品集"，所确定的配置项；主要包括：可行性分析报告、需求分析报告、软件功能规格说明、开发计划、质量计划、系统设计报告、测试文档、技术报告、用户手册、总结报告等；2）计算机程序。 3 度量数据的来源 1）项目计划； 2）评审报告； 3）测试报告； 4）问题报告； 5）软件维护记录； 4 质量度量 4.1 度量指标 主要根据各类软件项检查表的检查指标来确定，例如，软件需求规格说明书检查表（见附录1），有10个检查指标，则根据具体项目检查侧重点不同，可从中选择相应的检查指标作为度量指标。 4.2 质量等级 1）软件项的质量等级的确定根据度量综合指标进行。 2）度量综合指标计算公式为：Total = ∑QiMi。 3）其中i=1,2,...n代表指标数量； 4）Q代表度量的指标； 5）M代表度量的指标Q在整个指标体系中所占的权重系数，对不同的开发项目可能不同，此系数根据开发的不同着重点给出。 度量指标权重系数表： 序号指标权重 1 指标1 权数1 2 指标2 权数2 3 指标3 权数3 4 指标4 权数4 5 指标5 权数5 加权平均分1.0 6）质量评价：一般地，根据度量综合指标值，有以下评分标准。 质量评价计分标准表 序号得分质量评价 1 9.0～10.0 优质 2 8.0～8.9 良好
软件项目-度量过程-模板
度量过程版本：V1.0
度量过程 目录 1介绍 (1) 1.1目的 (1) 1.2范围 (1) 1.3参考文档 (1) 2术语表 (1) 3角色和职责 (1) 4过程概述 (2) 4.1简要说明 (2) 4.2流程图 (3) 5过程详述 (3) 5.1MA010定义度量集 (3) 5.2MA020制定度量计划 (4) 5.3MA030记录数据 (4) 5.4MA040审核数据 (5) 5.5MA050分析并发布度量数据 (5) 5.6MA060分析并发布组织度量数据 (6)
度量过程1 介绍 1.1 目的 本文件定义了公司实施度量活动所要遵循的过程，为进行过程和产品的度量分析提供了指导框架，确保所进行的度量与分析活动的有效性。 1.2 范围 适用于公司项目组、质量保证组、配置管理组、组织级培训组以及过程改进活动在内的所有过程活动以及其相应工作产品的度量与分析活动。 1.3 参考文档 [说明本文件的参考文档。] 2 术语表 3 角色和职责
度量过程4 过程概述 4.1 简要说明 度量过程分为两条主线：组织级度量和项目级度量。 ●组织级度量主要包括定义组织度量集、分析并发布组织度量数据2个活动； ?定义度量集：明确组织度量目标、定义度量项，并结合组织工作环境标准，制定项目和组织 两个层面的度量数据收集和分析的方法，是项目制定度量计划的基础 ?分析并发布组织度量数据：通过收集多个项目的度量数据，分析组织过程性能，发布过程数 据，建立和维护过程数据库，用于指导项目的策划活动 ●项目级度量主要包括制定度量计划、收集度量数据、审核度量数据、分析并发布度量数据4个活 动 ?制定度量计划：结合组织的度量集定义，明确项目的度量项，以及度量数据的收集时间、责 任人、收集方法等； ?收集度量数据：依据计划进行度量数据的收集； ?审核度量数据：对数据的正确性进行检查，确保度量结果的客观有效性； ?分析并发布度量数据：对度量数据进行分析，并发布给项目组、管理层、EPG，为项目及高 层提供客观量化的项目信息。
软件过程的质量度量(二)
一、实验目的 了解软件过程，了解软件过程的质量度量方法，掌握软件过程不同阶段中度量的侧重点及其各自的度量方法，重点了解软件测试阶段的过程度量内容。 二、实验时间 2课时 三、实验内容 1.依据网络资源，了解软件过程度量中的相关内容，重点了解软件测试过程的质量度量内 容。 2.以测试过程为主要内容，展开对软件测试过程的质量度量方法的综述。 四、实验要求 1.根据实验要求，撰写有关软件测试过程的质量度量方法的综述报告，报告中实验内容部 分要做到内容准确详尽，逻辑清楚，中心内容突出，文字表达通顺，且不少于3000字。 2.实验报告排版符合要求，不得相互抄袭或拷贝，否则一律不合格。 五、实验总结 软件测试是软件质量保证的关键步骤，软件开发生命周期受到关注最多的就是测试。在大部分软件开发活动中，软件测试被认为是基础，它对软件的成功是至关重要的。发布有缺陷的软件将导致顾客的不满意，而且会损害成产该软件的公司声誉。 软件测试过程度量的作用主要体现在：通过度量对过程、产品、资源和环境进行分析和理解，在此基础上建立过程基线；通过评价比较实际软件过程与标准或计划间的差异；通过度量所反映的产品状态信息、项目状态信息和过程状态信息，可以帮助制定合理的管理控制措施，使产品偏离度、项目偏离度和过程偏离度在可控制的范围内，使项目过程的性能表现稳定，并且项目过程性能满足需求；历史度量数据的积累能帮助预测当前项目的相关属性数据，有助于计划和决策的制定；度量并不能直接改进过程，但基于度量的理解和评价为过程改进提供了有效的线索。根据这些线索再结合度量所记录的过程场景信息分析过程偏差的原因，帮助过程改进制定有效的变更措施。过程改进既是度量的结果，又是度量的动因。 对软件测试过程的度量是对软件测试过程特性的一种描述，不同的描述类型决定了不同的度量内容、度量的表达方式、度量数据的采集手段、度量数据的分析方法。根据不同的描述类型主要划分为： 1.客观度量和主观度量:客观度量是过程或产品的实际结果，主观度量是人的主观判断 结果，也可以是在客观数据基础上的分析结果。 2.绝对度量和相对度量：绝对度量其度量值的取得没有参照物或没有其他属性之间的依 赖关系，相对度量是指其度量值的取得具有参照物或与其他属性之间有依赖关系，比
软件的复杂性度量方法概述
2.软件的复杂性度量方法概述 根据软件的生命周期，Halstead复杂性度量和McCabe圈复杂度度量都属于可以应用在软件测试阶段的度量技术。 在基于程序体积的复杂性度量算法中，最具影响力的是20世纪70年代由Halstead提出的软件科学度量理论[2]。Halstead从统计学和心理学的角度研究软件复杂性，把程序看成由可执行的代码行词汇(操作符和操作数)组成的符号序列。Halstead在其度量理论中采用一些基本的度量值来确定软件开发中的一些定量规律，这些度量值通常在程序产生之后得出，或者设计完成之后算出。Halstead的重要结论之一是：程序实际的Halstead长度值N可以由代码行词汇n算出。 McCabe于1976年指出：应该用程序流图的圈数(Cycloramic number)来测量程序的复杂性，并基于程序控制论和图论提出了经典的McCabe圈复杂性度量理论。McCabe控制流图是一种简化的程序流程图，如果把流程图中的每个基本框抽象为一个点，略去每个框的具体信息，就产生一个由结点和弧（或称为分支）组成的图，称为控制流图。控制流图是有向图，可用G =
E：If Seoer>80 F：Then Print(‘withdistinetion’) G：End 图1 程序及其流程图 为了讨论的方便，以下给出图论中的几个术语定义： 强连通图：在有向图G中，任意两个结点x和y，都有一条从x到y的路径，反之亦然。 回路：指开始和终止于相同结点的路径。 圈：指一个回路，其中所有结点(不包括开始结点)最多只出现一次。 线性独立集：如果在一个集合中，任何一条路经都不是其他路径的线性组合，则称该集合为线性独立集。 圈的基集：即圈的最大线性独立集。在含有e条边和n个结点的图中，基集有e – n + 1个圈。 如果能够合理的编写程序，则总能够使控制流图中存在从开始结点(如图1中的结点A)到达图中的其他每个结点的路径。一般来说，控制流图不是强连通的，因为不可能从其较低的一些结点到达较高的一些结点，但是，如果程序结构中有一个包含整个程序的外循环，则存在一条从其中任意结点到开始结点的“出口→入口”弧(如图1中的弧GA)，该弧使控制流图变成强连通的，因为：①从开始结点能够到达程序图中的任意结点；②从任意结点经“出口→入口”弧均可回到开始结点。 McCabe的圈复杂性度量就是考虑控制流图的圈的基集，因为在原始流图中加了一条边，所以对于一个流图为G的程序模块，如果G有e条边和n个结点，那么该程序模块的圈复杂度为：v(G) = e - n + 2。更简单地说，设d是G中的判定结点数，则v(G) = d + l。 软件工程的实践人员和研究人员一致认为：模块的圈数，即模块复杂度，与模块中所存在的软件错误数或缺陷数，以及为了发现并改正它们所需的时间之间存在着明显的联系。McCabe曾经指出：根据以往的经验，当一个模块的v超过10时，这个模块可能就会出问题。Grady和他的研究小组关于v的结论是：模块
软件质量度量方法比较分析
软件质量度量方法比较分析 摘要：常用的软件质量度量是以软件功能点数或代码行为基础的，采用不同度量方法，结果不尽相似。本文以介绍软件功能点为主，展开之后再对二者加以比较。 关键词：软件质量度量 一、概述 软件质量评价需要使用质量度量，现在最常用的质量度量是软件每单位功能点缺陷数和单位代码行缺陷数。同样的软件采用不同的度量方法，结果不尽相似。究其原因，则在于软件的功能点和软件的代码行数，表面上虽有关联，实质上存在重大差别。用代码行作为评价质量的载体，比较简单和直观。功能点度量法，则涉及更多的软件工程技术内容。本文以介绍软件功能点为主要内容展开。 软件功能点并非软件质量专用度量方法，具有比质量度量更加广泛的用途。它实质上是软件工程界经多年的知识积累，精心设计的一种软件规模大小的基本度量。可以用来估计软件产品规模，软件开发投入和工作量，安排软件进度，估算软件寿命周期费用。用来表示软件质量的“单位功能点缺陷数”是其应用的一个重要方面。 软件功能点分析方法已经有30多年的历史，它是在上世纪70年代末期由IBM首先开发，此后由国际功能点用户协会（IFPUG）推广。本世纪初，获两大国际标准化机构ISO和IEC的认可，成为国际标准。其发展过程如下： 1979年，IBM的Allan Albrecht在发表的文章中提出FP（Function Points）方法； 1984年，IBM正式发布FP使用指南； 1988年，国际功能点协会（IFPUG）的《功能点实践手册》2.0版发布； 1990年，国际功能点协会的《功能点实践手册》3.0版发布； 1994年，国际功能点协会的《功能点实践手册》4.0版发布； 1999年，国际功能点协会的《功能点实践手册》4.1版发布； 2003年，ISO/IEC 20926：2003《软件和系统工程——软件测量-IFPUG功能规模测量法2003》发布； 2009年，ISO/IEC 20926-2009《软件和系统工程——软件测量
软件测试度量指标
软件测试度量指标 1、测试度量的目的 测试度量活动首要考虑的是目的，测试中的度量一般有如下目的： ● 判断测试的有效性 ● 判断测试的完整性 ● 判断工作产品的质量 ● 分析和改进测试过程 2、度量内容 度量的数据构成一个层次化的体系，就是度量框架。框架的上层是度量指标(Factor)，下层是直接度量(Metrics)。度量指标表示产品或过程的特征，需要从直接度量计算而来。而直接度量是可以直接收集到的数据。下面分别说明系统测试中需要测量的度量内容，注意区分其中的度量指标和直接度量。 1）进度（时间）度量 a) 计划的测试开始、结束时间 b) 实际的测试开始、结束时间 c) 执行测试用例的时间。 2）成本度量 a) 计划投入测试的工作量（人时） b) 计划投入测试的资金 c) 实际投入测试的工作量（人时） d) 实际投入测试的资金 e) 评审投入的工作量（人时） f) 缺陷修正成本（提交缺陷、研究缺陷、改正缺陷、验证等所需时间） g) 累积测试时间。对每一个发布的版本，累积测试时间等于该版本在演变过程中经历的所有测试的测试时间之和。包括完整测试、验证测试和回归测试。 3）规模度量 a) 被测对象的规模（功能点、代码行（有效代码行，注释行）等） b) 系统需求数目 c) 测试用例数目（总用例数、计划执行数、实际执行数） 4）测试质量（效率）度量 a) 测试覆盖率
需求覆盖率：需求覆盖率=至少被测试用例覆盖一次的需求数/系统总需求数 测试用例覆盖率：测试用例覆盖率=计划执行的测试用例数/测试用例总数 测试用例执行率：测试用例执行率=实际执行的测试用例数/计划执行的测试用例数 测试用例通过率：测试用例通过率＝(实际执行的测试用例数-测试执行不通过的测试用例数)/实际执行的测试用例数b) 缺陷检测率对某一版本，某一个环节（阶段）的缺陷检测率＝(A/(A+B))*100％。 其中： 测试人员查找出的不包括重复缺陷的数量。 用户（包括下一环节的部门）报告的不包括重复缺陷的数量。 c) 测试过程能力 单位缺陷开销＝测试投入的工作量（人时）/缺陷总数 5）产品质量度量 a) 版本发布前缺陷数 b) 版本发布后缺陷数 c) 评审发现的缺陷数 d) 缺陷修正率：缺陷修正率＝发布前已修正的缺陷数/发布前已知的缺陷总数。 e) 缺陷密度：千行代码缺陷率＝测试和评审中发现的缺陷数/被测目标的代码的规模（KL）