软件度量常用方法

① 什么是软件度量

软件度量是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制和改善。没有软件度量，就不能从软件开发的暗箱中跳将出来。通过软件度量可以改进软件开发过程，促进项目成功，开发高质量的软件产品。度量取向是软件开发诸多事项的横断面，包括顾客满意度度量、质量度量、项目度量、以及品牌资产度量、知识产权价值度量，等。度量取向要依靠事实、数据、原理、法则；其方法是测试、审核、调查；其工具是统计、图表、数字、模型；其标准是量化的指标。

② 软件度量的原则和软件度量实施的方法

原则：不要为了考核开发者而度量，度量是为了解现状，牵引能力提升；
方法：关键KPI，一般从质量、效率、成本三个方面设置度量指标；

③ 软件测试中对软件质量进行度量的指标常用的有哪些

你好！

有N多种指标：
缺陷统计数据的度量(I)
所有缺陷数量的时间走势或趋势统计 (Bug Trends By Time)
未被处理的缺陷按照严重程度的统计 (Active Bugs By Severity)
未被处理的缺陷按照优先程度的统计 (Active Bugs By Priority)
未被处理的缺陷数量的时间走势或趋势统计 （Active Bugs Over Time）
已发现缺陷的数量和已修复的缺陷的数量的比率 (Fixed/Found)。也被称为修改率或纠错率(Fix Rate)
未处理的缺陷数量和已处理的的缺陷数量的比率 (active/resolved)
已处理的被修复的缺陷数量和已处理的缺陷数量的比率（Resolved as Fixed/resolved）
重新被激活的已修复的缺陷数量(Bug re-activation rate)
通过测试找到的缺陷的统计(Bugs opened by testing activity)
所有的缺陷按照严重程度的统计(All Bugs By Severity)
新被发现的缺陷按严重程度的统计 (Opened Bugs By Severity)
已处理的缺陷按照严重程度的统计 (Resolved Bugs By Severity)
被修复的缺陷按照严重程度的统计 (Fixed By Severity)
不同语言版本缺陷数量的统计(Bugs opened by Language version)
被报告存在缺陷的各功能统计(Where your bugs were found)
处理缺陷的平均时间的统计(Average Time to Resolve)
关闭缺陷的平均时间的统计(Average Time to Close)
被处理缺陷的不同结论统计(Resolved Bugs By Resolution)

详细的信息你可以留下邮箱，我发给你文件！

④ 软件质量属性的度量方法

随着软件的复杂性日益增长， 软件开发的周期以及费用也日益增长，软件质量的保证与提高越来越成为了人们高度重视的问题。软件质量的度量的理论和研究也随之发展起来，好的度量模型和标准能够有效地提高软件开发效率和软件质量。本文主要介绍软件质量的概念和度量模型以及软件质量度量的方法，并对未来的发展趋势做一些展望

⑤ 度量的软件度量标准

1.软件研发成本度量规范简介
本标准规定了软件研发成本度量方法、过程及原则，包括软件研发成本的构成、软件研发成本度量过程、软件研发成本度量的应用。本标准适用于度量成本与功能规模密切相关的软件研发项目的成本。本标准不涉及软件定价，但相关各方可依据本标准明确研发成本，从而为软件定价提供重要依据。
2.标准研制背景
长期以来，如何度量和评估软件研发项目的成本一直是产业界的难题。目前我国尚无科学统一的软件研发项目成本度量标准体系以指导、规范、管理软件项目的研发成本，较大程度导致做预算时无据可依，造成极大浪费；在软件项目招评标过程中，由于无法界定软件工程项目的合理成本范围，常常出现恶意低价或超高价格竞标现象；软件开发商在项目实施过程中，由于缺乏成本控制的科学依据，也经常出现时间滞后、费用远远超出最初估算水平的情况。
3.标准研制过程
在国家工业和信息化部软件服务业司领导下，从2010年开始启动我国软件成本度量标准体系的研制工作。中国软件行业协会系统与软件过程改进分会 （以下简称 “过程改进分会”）和中国电子技术标准化研究院（以下简称“电子四所”）围绕软件研发成本度量标准体系建设开展了基础性研究工作，梳理了标准体系。核心标准《软件研发成本度量规范》于2010年12月正式立项，计划号为2010-3194T-SJ，由过程改进分会和电子四所共同牵头起草，组织产、学、研、 用约40家单位共同参与，历时3年，为软件项目预算、立项审批、招投标、项目计划、变更管理等工作提供“科学依据”。
4.标准的价值
1、倡导使用统一的国际功能点方法度量软件规模，使度量结果可比对；
2、倡导使用基准数据估算软件工期和成本，使估算结果更科学；
3、倡导使用一致的估算过程和公式，使估算过程透明化、估算结果可追溯。
5.标准试点应用
《软件研发成本度量规范》从2012年开始试点应用。海关总署、中国人民银行、东软集团等单位都参与了试点工作，分别在预算审批、项目立项、招投标、项目计划等场景进行应用，取得了很好的效果。截至2013年年底，共有约2000人参加CCEP培训，近1500人通过考试并成为国内首批CCEP（软件成本估算专家）。采用标准规定的方法后，极大的解决了试点企业长期以来面临的问题。
6.标准发布
行业标准《软件研发成本度量规范》（SJ/T11463-2013） 由中华人民共和国工业和信息化部于2013年10月17日正式发布，并于2013年12月1日开始正式实施。
7.最新进展
经推荐，该标准由中关村智联软件服务业质量创新联盟 牵头，正在申请升级为国家标准，于2015年7月31日正式下达计划号：20151553-T-469 1.规范研制背景
北京作为全国软件与信息服务业之都，产业规模一直位居全国前列，并且保持着较快的增长水平，软件和信息服务业在全市经济发展中也占有越来越重要的地位。随着十二五规划的逐步实施，北京市各行各业信息化建设投资也不断加大，仅全市每年属于市级财政拨款范畴的信息化项目就可达700至800个，金额总量可达三十多亿元，涉及上千家企事业单位。然而本市一直没有科学统一的标准以支撑、规范、管理信息化项目软件开发费用的测算，这大大制约了北京软件产业的健康可持续发展。由于相关标准的缺失，如何测算信息化项目软件开发的合理费用一直都是北京软件产业发展中的难点，因而常常导致软件项目预算审批无依据、恶意竞标等问题的发生。
2.规范的价值
由北京市经济和信息化委员会归口指导，北京软件和信息服务交易所、北京软件行业协会过程改进分会联合制订的北京市首个软件成本度量地方标准《信息化项目软件开发费用测算规范》将于今年11月起正式实施，这标志着我市信息化项目软件开发工作拥有了科学、标准的费用评估方法，有助于规范行业市场、推动软件企业提升生产效率，提升产业增长质量。 1.编制背景
长期以来，如何度量软件研发成本一直是产业界的难题，尤其是在预算、招投标、项目计划等活动中因为缺失科学统一的软件研发成本度量标准，较大程度导致项目做预算时无据可依，进而造成预算浪费或预算不足；在软件项目招投标过程中，因为缺乏软件研发成本度量依据，恶意竞标、低价中标现象频频发生；开发方在项目实施过程中，由于缺乏成本控制的科学依据，也经常出现时间滞后，费用远远超出最初预算的情况。科学统一的软件研发成本度量标准既是有效进行软件项目管理的重要依据，也是当前软件产业发展的迫切需要。
为此，工业与信息化部软件服务业司委托中国软件行业协会系统与软件过程改进分会牵头组织编制了《软件研发成本度量规范》。标准中规定了软件研发成本度量的方法及过程，包括软件研发成本的构成、软件研发成本度量的过程、软件研发成本度量的应用。其目的是帮助软件研发涉及各方科学、一致地进行成本度量。但标准中没有包含软件研发成本度量过程中所需要的估算模型、行业基准数据及其在不同场景进行成本估算的详细步骤和方法，因此需要制订标准的应用指南，以便相关各方针对不同的应用场景、正确使用行业数据和模型，有效开展软件研发成本度量相关工作。
2.编制目的与范围
本指南是《软件研发成本度量规范》系列应用指南之一，针对预算场景。
《软件研发成本度量规范》中的成本度量，特指对软件研发成本的预计值进行估算或对实际值进行测量、分析的过程。而《软件研发成本度量规范》中，预算是指根据项目成本估算的结果确定预计项目费用的过程。因此，本指南主要描述在预算场景下如何开展成本估算工作，而不涉及编制预算的其他方面。
在《软件研发成本度量规范》及本指南中，软件研发过程包括从项目立项开始到项目完成验收之间的需求分析、设计、编码、集成、测试、验收交付活动及相关的项目管理、支持活动。因此，本指南中软件研发成本仅包括软件研发过程中的所有直接成本和间接成本，但不包括数据迁移、软件维护等成本。本指南中所涉及工作量、工期也仅为软件研发过程所用工作量、工期。
本指南编制的主要目的是指导预算活动相关各方，基于《软件研发成本度量规范》有效开展成本估算工作，并为确定软件项目预算提供科学依据。
本指南明确了基于《软件研发成本度量规范》和基准数据开展成本估算相关活动的步骤与方法，并通过示例，明确了典型情况的估算及调整方法；对于其他特殊情况，相关人员应根据本指南及《软件研发成本度量规范》中的相关原则，结合项目特点，选择适当的估算方法或对估算结果进行合理调整。
对于与预算类似的其他早期估算应用场景，相关人员也可参照本指南的相关原则与方法，开展项目估算活动。

⑥ 软件缺陷度量方法简述

1.原则上来讲，我们更希望一种规范化开发的体系来规正这个命题，不需要为此伤脑筋。但在里程碑或计划的截止时间点能结束测试对大多数的软件项目仅仅是一种期望，而不是既定的现实。理想的情况下，我们可以严格执行计划，然后在计划要求的deadline或者里程碑点上提交交付件，以确认该里程碑是否达到要求，是否可以进行下一阶段的工作——但正如前提所言，这个仅仅是理想情况
2.现在让我们现实一点。我们为什么会有这样的问题(一个软件如何确定测试结束点)？往往就是因为我们不知道何时可以结束一个软件的测试。不管教科书上如何说明一个软件只要还在生命周期内，就无法结束测试，但现实要求我们在某一个时间点上，结束对软件某一阶段的测试。那么，这个问题实际上就已经转化为确定该阶段测试的结束点的方法了。这个方法可能是一种规范，一套流程，一些交付件，一些评审，一些由统计学原理得出的收敛曲线或者仅仅只是一些确认而已。而个人认为，无论这个方法是何种形式的，其基本的要求就是能达成一种协议，确认该协议生效——那么这个阶段的测试就结束了，至于这个点在什么时间，我想就是完成所有要求的这些确认的时间而已。
在软件消亡之前，如果没有测试的结束点，那么软件测试就永无休止，永远不可能结束。软件测试的结束点，要依据自己公司具体情况来制定，不能一概而论！个人认为测试结束点由以下几个条件决定：：
1.基于“测试阶段”的原则：
每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段，我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标准后，再进行后面一个阶段的测试。举个例子来说：单元测试，我们要求测试结束点必须满足“核心代码100%经过Code Review”、“功能覆盖率达到100%”、“代码行覆盖率不低于80%”、“不存在A、B类缺陷”、“所有发现缺陷至少60%都纳入缺陷追踪系统且各级缺陷修复率达到标准”等等标准。集成测试和系统测试的结束点都制定相关的结束标准，当然也是如此。
2.基于“测试用例”的原则：
测试设计人员设计测试用例，并请项目组成员参与评审，测试用例一旦评审通过，后面测试时，就可以作为测试结束的一个参考标准。比如说在测试过程中，如果发现测试用例通过率太低，可以拒绝继续测试，待开发人员修复后再继续。在功能测试用例通过率达到100%，非功能性测试用例达到95%以上，允许正常结束测试。但是使用该原则作为测试结束点时，把握好测试用例的质量，非常关键。
3.基于“缺陷收敛趋势”的原则：
软件测试的生命周期中随着测试时间的推移，测试发现的缺陷图线，首先成逐渐上升趋势，然后测试到一定阶段，缺陷又成下降趋势，直到发现的缺陷几乎为零或者很难发现缺陷为止。我们可以通过缺陷的趋势图线的走向，来定测试是否可以结束，这也是一个判定标准。
4.基于“缺陷修复率”的原则：
软件缺陷在测试生命周期中我们分成几个严重等级，它们分别是：严重错误、主要错误、次要错误、一般错误、较小错误和测试建议6种。那我们在确定测试结束点时，严重错误和主要错误的缺陷修复率必须达到100%，不允许存在功能性的错误；次要错误和一般错误的缺陷修复率必须达到85%以上，允许存在少量功能缺陷，后面版本解决；对于较小错误的缺陷修复率最好达到60%~70%以上。对于测试建议的问题，可以暂时不用修改。
5.基于“验收测试”的原则：
很多公司都是做项目软件，如果这种要确定测试结束点，最好测试到一定阶段，达到或接近测试部门指定的标准后，就递交用户做验收测试。如果通过用户的测试验收，就可以立即终止测试部门的测试；如果客户验收测试时，发现了部分缺陷，就可以针对性的修改缺陷后，验证通过后递交客户，相应测试也可以结束。
6.基于“覆盖率”的原则：
对于测试“覆盖率”的原则，个人觉的只要测试用例的“覆盖率”覆盖了客户提出全部的软件需求，包括行业隐性需求、功能需求和性能需求等等，只要测试用例执行的覆盖率达到100%，基本上测试就可以结束。如“单元测试中语句覆盖率最低不能小于80%”、“测试用例执行覆盖率应达到100%”和“测试需求覆盖率应达到100%”都可以作为结束确定点。如果你不放心，非得要看看测试用例的执行效果，检查是否有用例被漏执行的情况，可以对常用的功能进行“抽样测试” 和“随机测试”。对于覆盖率在单元测试、集成测试和系统测试，每个阶段都不能忽略。
7.基于“项目计划”的原则：
大多数情况下，每个项目从开始就要编写开发和测试的Schele，相应的在测试计划中也会对应每个里程碑，对测试进度和测试结束点做一个限制，一般来说都要和项目组成员(开发，管理，测试，市场，销售人员)达成共识，团队集体同意后制定一个标准结束点。如果项目的某个环节延迟了，测试时间就相应缩短。大多数情况下是所有规定的测试内容和回归测试都已经运行完成，就可以作为一个结束点。很多不规范的软件公司，都是把项目计划作为一个测试结束点，但是如果把它作为一个结束点，测试风险较大，软件质量很难得到保证。
8.基于“缺陷度量”的原则：
这个原则也许大家用的不是很多，了解比较少。我们可以对已经发现的缺陷，运用常用的缺陷分析技术和缺陷分析工具，用图表统计出来，方便查阅，分时间段对缺陷进行度量。我记得以前zhuzx在这个论坛上提出过缺陷分析技术这个问题，我不再重复讲述。我们也可以把 “测试期缺陷密度”和 “运行期缺陷密度”作为一个结束点。当然，最合适的测试结束的准则应该是“缺陷数控制在一个可以接受的范围内”。比如说：一万行代码最多允许存在多少个什么严重等级的错误，这样比较好量化，比较好实施，成为测试缺陷度量的主流。
9.基于“质量成本”的原则：
一个软件往往要从“质量/成本 /进度”三方面取得平衡后就停止。至于这三方面哪一项占主要地位，就要看是什么软件了。比如说是：人命关天的航天航空软件，那还是质量重要些，就算多花点钱、推迟一下进度，也要测试能保证较高质量以后才能终止测试，发布版本。如果是一般的常用软件，由于利益和市场的原因，哪怕有bug，也必须得先推出产品，没办法呀。一般来说，最主要的参考依据是：“把找到缺陷耗费的代价和这个缺陷可能导致的损失做一个均衡”。具体操作的时候，可以根据公司实际情况来定义什么样的情况下算是“测试花费的代价最划算、最合理”，同时保证公司利益最大化。如果找到bug的成本比，用户发现bug的成本还高，也可以终止测试。
10.基于“测试行业经验”的原则：
很多情况下，测试行业的一些经验，也可以为我们的测试提供借鉴。比如说测试人员对行业业务的熟悉程度，测试人员的工作能力，测试的工作效率等等都会影响到整个测试计划的执行。如果一个测试团队中，每个人都没有项目行业经验数据积累，拿到一个新的项目，自然是一头雾水，不知道从何处开始，测试质量自然不会很高。因此通过测试者的经验，对确认测试执行和结束点也会起到关键性的作用

⑦ 哪些软件适合使用功能点方法进行度量

软件规模度量分为：代码行技术和功能点技术等
代码行技术优点和缺点分别是：
优点：用软件代码行数估算软件规模简单易行。
缺点：代码行数的估算依赖于程序设计语言的功能和表达能力；
采用代码行估算方法会对设计精巧的软件项目产生不利的影响；
在软件项目开发前或开发初期估算它的代码行数十分困难；
代码行估算只适用于过程式程序设计语言，对非过程式的程序设计语言不太适用等等。
功能点技术的优点和缺点是：
优点：比代码行更为合理。
缺点：在某些计算上，主观意识较为强烈！

⑧ 软件度量的方法体系

项目度量
项目度量是针对软件开发项目的特定度量，目的在于度量项目规模、项目成本、项目进度、顾客满意度等，辅助项目管理进行项目控制。
规模度量
软件开发项目规模度量(size measurement)是估算软件项目工作量、编制成本预算、策划合理项目进度的基础。规模度量是软件项目失败的重要原因之一。一个好的规模度量模型可以解决这一问题。有效的软件规模度量是成功项目的核心要素：基于有效的软件规模度量可以策划合理的项目计划，合理的项目计划有助于有效地管理项目。规模度量的要点在于：由开发现场的项目成员进行估算；灵活运用实际开发作业数据；杜绝盲目迎合顾客需求的“交期逆推法”。
软件规模度量有助于软件开发团队准确把握开发时间、费用分布以及缺陷密度等等。软件规模的估算方法有很多种，如：功能点分析(FPA：function points analysis)、代码行(LOC：lines of code)、德尔菲法(Delphi technique)、COCOMO模型、特征点(feature point)、对象点(object point)、3-D功能点(3-D function points)、Bang度量(DeMarco's bang metric)、模糊逻辑(fuzzy logic)、标准构件法(standard component)等，这些方法不断细化为更多具体的方法。
成本度量
软件开发成本度量主要指软件开发项目所需的财务性成本的估算。主要方法如下：
类比估算法。类比估算法是通过比较已完成的类似项目系统来估算成本，适合评估一些与历史项目在应用领域、环境和复杂度方面相似的项目。其约束条件在于必须存在类似的具有可比性的软件开发系统，估算结果的精确度依赖于历史项目数据的完整性、准确度以及现行项目与历史项目的近似程度。
细分估算法。细分估算法是将整个项目系统分解成若干个小系统，逐个估算成本，然后合计起来作为整个项目的估算成本。细分估算法通过逐渐细化的方式对每个小系统进行详细的估算，可能获得贴近实际的估算成本。其难点在于，难以把握各小系统整合为大系统的整合成本。
周期估算法。周期估算法是按软件开发周期进行划分，估算各个阶段的成本，然后进行汇总合计。周期估算法基于软件工程理论对软件开发的各个阶段进行估算，很适合瀑布型软件开发方法，但是需要估算者对软件工程各个阶段的作业量和相互间的比例具有相当的了解。
顾客满意度度量
顾客满意是软件开发项目的主要目的之一，而顾客满意目标要得以实现，需要建立顾客满意度度量体系和指标对顾客满意度进行度量。顾客满意度指标(CSI：customer satisfaction index)以顾客满意研究为基础，对顾客满意度加以界定和描述。项目顾客满意度量的要点在于：确定各类信息、数据、资料来源的准确性、客观性、合理性、有效性，并以此建立产品、服务质量的衡量指标和标准。企业顾客满意度度量的标准会因为各企业的经营理念、经营战略、经营重点、价值取向、顾客满意度调查结果等因素而有所不同。比如：NEC于2002年12月开始实施的CSMP 活动的度量尺度包括共感性、诚实性、革新性、确实性和迅速性，其中，将共感性和诚实性作为CS活动的核心姿态，而将革新性、确实性和迅速性作为提供商品和服务中不可或缺的尺度。每个尺度包括两个要素，各要素包括两个项目，共计5大尺度、10个要素和20个项目。例如，共感性这一尺度包括“了解顾客的期待”、“从顾客的立场考虑问题”这两个要素；“了解顾客的期待”这一要素又包括“不仅仅能胜任目前的工作还能意识到为顾客提供价值而专心投入”、“对顾客的期望不是囫囵吞枣而是根据顾客的立场和状况来思考‘顾客到底需要什么’并加以应对”这两个项目。
美国专家斯蒂芬(Stephen H.Kan)在《软件质量工程的度量与模型》(Metrics and Models in Software Quality Engineering)中认为，企业的顾客满意度要素如表7-1所示： 顾客满意度要素 顾客满意度要素的内容 技术解决方案 质量、可靠性、有效性、易用性、价格、安装、新技术 支持与维护 灵活性、易达性、产品知识 市场营销 解决方案、接触点、信息 管理 购买流程、请求手续、保证期限、注意事项 交付 准时、准确、交付后过程 企业形象 技术领导、财务稳定性、执行印象 作为企业的顾客满意度的基本构成单位，项目的顾客满意度会受到项目要素的影响，主要包括：开发的软件产品、开发文档、项目进度以及交期、技术水平、沟通能力、运用维护等等。具体而言，可以细分为如表7-2所示的度量要素，并根据这些要素进行度量。
顾客满意度项目 顾客满意度度量要素
软件产品 功能性、可靠性、易用性、效率性、可维护性、可移植性
开发文档 文档的构成、质量、外观、图表以及索引、用语
项目进度以及交期 交期的根据、进度迟延情况下的应对、进展报告
技术水平 项目组的技术水平、项目组的提案能力、项目组的问题解决能力
沟通能力 事件记录、式样确认、Q&A
运用维护 支持、问题发生时的应对速度、问题解决能力

⑨ 软件规模估算有哪些方法

现实中常见的软件成本估算方法包括经验法（专家法）、类推法，类比法、方程法，交叉验证法。除估算方法外，还需要估算数据库的支持才能继续度量分析，从而得出估算目标。估算数据基础可以是企业历史数据库，也可以是行业基准数据库。
《软件研发成本度量规范》中软件成本估算的思路分三步骤：规模估算、工作量估算、成本估算。

⑩ 简述软件度量GQM方法的基本步骤。

GQM的实施过程大致分为七个阶段：先期调研，制定目标，产生计划，产生测量计划，收集和整理数据，数据分析，打包。其中GQM的核心是GQM目标（Goal）和GQM计划，所谓GQM计划就是用一组问题(Question)来定义GQM目标，再对每个问题给出一组度量（Metric）。