软件质量度量方法比较分析
软件质量度量方法比较分析
摘要：常用的软件质量度量是以软件功能点数或代码行为基础的，采用不同度量方法，结果不尽相似。本文以介绍软件功能点为主，展开之后再对二者加以比较。
关键词：软件质量度量
一、概述
软件质量评价需要使用质量度量，现在最常用的质量度量是软件每单位功能点缺陷数和单位代码行缺陷数。同样的软件采用不同的度量方法，结果不尽相似。究其原因，则在于软件的功能点和软件的代码行数，表面上虽有关联，实质上存在重大差别。用代码行作为评价质量的载体，比较简单和直观。功能点度量法，则涉及更多的软件工程技术内容。本文以介绍软件功能点为主要内容展开。
软件功能点并非软件质量专用度量方法，具有比质量度量更加广泛的用途。它实质上是软件工程界经多年的知识积累，精心设计的一种软件规模大小的基本度量。可以用来估计软件产品规模，软件开发投入和工作量，安排软件进度，估算软件寿命周期费用。用来表示软件质量的“单位功能点缺陷数”是其应用的一个重要方面。
软件功能点分析方法已经有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《软件和系统工程——软件测量
-IFPUG功能规模测量法2009》发布。
二、软件功能点分析方法流程
具体步骤包括：
1）确定功能点计数类型。
2）识别计数范围及应用系统边界。
3）数据功能点计数。
4）事务处理功能点计数。
5）确定调整系数值。
6）计算调整后功能点数。
图1 软件功能点分析步骤图
（一）确定功能点计数分析项目的类型
1）开发项目：这种类型的分析，为用户提供在软件第一次安装时，该软件具有的功能点数量。
2）升级项目：这种类型的分析，为用户提供项目升级后，原有系统的功能经过修改、增加和删除后系统的功能点数量。
3）应用：应用的功能点计数，是度量已经安装运行的系统提供给用户的功能点数量。
（二）识别项目的范围和边界
识别边界的时候必须应用如下规则：
1）边界的定义必须基于用户的视角，边界必须是用户能够理解和描述的。
2）相关应用间的边界是由用户看到的不同功能区域来划分，而不是由技术考虑来划分。
3）应用之间的初始边界不会因为功能点分析而改变。
（三）数据功能计数
1、数据功能
数据功能是指向用户提供的，满足内部或者外部数据需求的功能。数据功能有两类，内部逻辑文件ILF和外部接口文件EIF。这里所谓的文件不是传统数据处理意义上的文件，而是指一组逻辑上相互关联的数据。其中：
1）ILF：是一组在应用边界内可识别的，且被应用维护的逻辑相关数据或者控制信息。其主要目的是通过应用的一个或几个基本处理过程维护数据。
2）EIF：是一组在应用边界内被查询，但在其他应用中被维护的，用户可识别的逻辑相关数据或者控制信息。EIF的主要目的是使数据在应用边界内，通过一个或几个基本处理过程得以查询。
2、数据功能点计算
一个ILF或者EIF“未经调整的功能点数”是由它的复杂度和贡献度直接决定的。每一个ILF或者EIF都必须有一个复杂度与它相关联。其复杂度又是由这个ILF或者EIF的数据元素类型（DET）数和记录元素类型（RET）数决定的。其中：
1）DET：是一个唯一的用户可认知的、不重复的数据域；
2）RET：是一个ILF或EIF内用户可认知的数据元素子集。
ISO/IEC 20926-2009标准中规定了确定复杂度、贡献度和关联度的ILF或者EIF“未经调整的功能点数”的测算方法。
（四）事务处理功能计数
1、事务功能
事务功能是指向用户提供的用来处理数据的功能。包括：
1）外部输入（External Inputs（EI））
EI是指一个处理来自本应用边界之外的一组数据或者控制信息的基本处理过程。外部输入的基本目的是维护一个内部逻辑文件（ILF）或者改变系统的行为。
2）外部输出（External Output（EO））
EO是向应用边界之外发送数据或控制信息的基本处理过程。其主要目的是通过逻辑处理方式向用户展示信息，而不只是直接恢复数据或控制信息。该处理逻辑必须包含至少一个数学公式或计算过程，并生成衍生数据。一个EO可能维护一个或多个ILF和改变系统行为。
3）外部查询（External Query（EQ））
EQ是向应用边界之外发送数据或控制信息的基本处理过程，主要目的是向用户展示信息。该处理逻辑不包括数学公式或计算过程，不会生成衍生数据。EQ处理过程中既不会维护任何ILF，也不会改变系统行为。
4）EI、EO、EQ都是逻辑处理
逻辑处理指的是用户提出的完成某个处理的请求。逻辑处理的例子包括：数据验证；数学公式和计算；数据过滤和选择；分析适用条件；更新一个或多个ILF；引用一个或多个ILF或EIF；运用现有数据生成衍生数据；改变系统行为；向应用范围之外显示数据；接受进入系统边界的数据或者控制信息；恢复和重新整理数据。
2、事务功能点计算
根据EI、EO、EQ的复杂度和贡献度来计算，EI、EO、EQ的复杂度和贡献度取决于以下两种元素的数量：
1）引用文件类型（File Types Referenced（FTR））
FTR是一个被事务功能读取或者维护的内部逻辑文件，或者是一个被数据功能读取的外部接口文件。
2）数据元素类型（Data Element Types（DET））
DET是一个唯一的用户可认知的、不重复的数据域。
ISO/IEC 20926-2009标准中规定了确定复杂度、贡献度和EI、EO、EQ的“未经调整的功能点数”的测算方法。
（五）确定调整系数
调整系数（V alue Adjustment Factor（V AF））反映的是应用给用户提供的功能的概况。V AF包含14个基本系统特征（GSC），每一个特征都有特定的规则描述来帮助使用者确定该特征对本应用影响的大小。这些影响值从0到5，分别表示对系统从无影响到具有强烈影响的程度。
1、通用系统特性及其影响程度的评定
通用系统特性包括如下14个：
1）数据通讯（Data Communications）
2）分布式数据处理（Distributed Data Processing）
3）性能（Performance）
4）使用强度高的配臵（Heavily Used Configuration）
5）事务处理速度（Transaction Rate）
6）在线数据输入（Online Data Entry）
7）最终用户的效率（End-User Efficiency）
8）线更新（Online Update）
9）复杂处理（Complex Processing）
10）重用性（Reusability）
11）安装简易性（Installation Ease）
12）运行简易性（Operational Ease）
13）多场地（Multiple Sites）
14）易于变更（Facilitate Change）
2、影响程度及其级别
每个特征因子的影响程度分为6个级别：
1）第一级：毫无影响，影响程度赋值0；
2）第二级：偶然影响，影响程度赋值1；
3）第三极：较小影响，影响程度赋值2；
4）第四级：一般影响，影响程度赋值3；
5）第五级：重要影响，影响程度赋值4；
6）第六级：强烈影响，影响程度赋值5。
每个特征因子的影响程度都有自己的判定规则。
（六）计算经过调整的功能点
经过调整的功能点（Adjusted Function Point）是针对不同类型的应用（开发、升级、应用）使用不同的公式计算得来的。ISO/IEC 20926-2009标准中规定了“经过调整的功能点数”的详细算法。
三、软件规模度量的比较
（一）功能点方法简评
功能点方法以用户需求作为分析的基础，项目需求基本明确时即可进行功能点预估，开发过程中需求可能发生变更和细化，导致项目规模减缩或扩展。因此项目结束时还需要重新进行测算，这时测算的结果才能准确反映项目的规模。
1、优点
1）有标准可供遵循，具有可操作性；
2）系统规模具有可比性；
3）基于需求，在项目早期即可进行估计；
4）独立于软件开发语言，与技术平台无关；
5）与软件实现人员无关，能够减少估算人员人为因素的影响；
6）国际主流测算方法，适合甲乙双方谈判沟通。
2、缺点
1）估算与度量人员需要经过专门的培训；
2）结果不够直观。
（二）代码行数度量特征
软件规模的代码行数度量，是开发方从技术角度反映软件规模的一种度量方法。代码行的单位可以是：KLOC（千代码行）、KSLOC （千源代码行）、ESLOC（可执行源代码行）。所以需要明确定义代码行的含义，例如说明是否含有注释行，是否含有空行，是逻辑行还是物理行，是否包含开发平台自动生成的代码。
1、优点
1）人员不需要专门的培训，简单易行；
2）在有历史数据积累的情况下，可以在开发前期提出可信的预计；
3）结果直观易读；
4）在测试和维护阶段，得出的质量度量将具有客观性和可比性。
2、缺点
1）早期估计结果误差大；
2）同一个系统不同的技术平台下估算出的规模不同；
3）规模与开发语言关系密切；
4）不同人员对系统规模的估计可能有很大差别；
5）不同系统之间的规模比较意义不大。
（三）单位代码行度量缺点案例
单位代码行缺陷数通常用于比较软件产品之间的质量水平，但是同样类型、同样功能的产品，如果采用不同的语言编写，采用单位代码行缺陷度量加以比较，往往导致误判，容易对优秀的高级语言造成伤害。Capers Jones提供了下面的案例。
表1案例比较
表1中的软件产品A和B，是同样类型、同样功能的产品，功能点数相同，分别用JA V A语言和C语言编写。产品A和B的每千代码行缺陷数也相同。如果用它作为判断标准，二者应该具有相同的质量水平。但是由于JA V A语言具有更加精练的表达能力，案例A的中代码行数较少，总的缺陷数也少，在软件的生存期中，从缺陷维护费用来看，就可节约$105，000元。显然案例A比案例B具有更高的质
量水平。
浅析软件质量指标度量
软件质量指标度量 V 1.0 2012.3
目录 1综述 (3) 1.1编写目的 (3) 1.2阅读指南 (3) 2软件质量指标 (4) 2.1需求功能点覆盖率 (4) 2.2用例执行覆盖率 (4) 2.3缺陷修复率（截至于**年*月*日） (5) 2.4缺陷遗留个数（截至于**年*月*日） (5) 2.5缺陷分布统计（模块缺陷率） (5) 2.6缺陷分布统计（严重缺陷率） (6) 2.7缺陷密度及收敛 (7) 3测试过程质量指标 (9) 3.1缺陷探测率 (9) 3.2有效缺陷率 (9) 3.1用例执行效率 (10) 3.2缺陷发现率 (10) 4交付质量指标 (12) 4.1加载回退率 (12) 4.2故障回退率 (12) 5版本说明 (13)
1综述 1.1 编写目的 本文档主要为测试经理、测试组长/测试人员、技术负责人、项目经理、开发人员等提供软件质量、测试质量、交付质量等衡量依据。通过不同指标的目标设定、过程跟踪、结果分析，为当期被测产品的质量提供可参考的数据，也为后续测试提供数据的基础积累，并作为制定方法流程的依据。 1.2 阅读指南 ●软件测试质量指标主要针对研发项目、商务项目被测产品出具数据 度量。 ●测试过程质量指标主要为测试经理、测试组长对测试人员的测试执 行质量出具数据度量。 ●交付质量主要为新需求的交付质量出具数据度量。 三者可单独使用，也可结合使用。
2软件质量指标 2.1 需求功能点覆盖率 【需求覆盖率】：计算测试用例总数之和除以与之一一对应的功能点数之和，主要查看是否有功能点遗漏测试的情况。 【公式】：∑测试用例数（个）/ ∑功能点（个） 说明：用例覆盖需求矩阵，一个需求对应多个功能点。 【数据来源】：《联通集中集团客户业务支撑系统销售管理用户需求说明书》《联通集中集团客户业务支撑系统销售管理需求跟踪矩阵》 【计算结果】需求覆盖率=113/8=14.13 2.2 用例执行覆盖率 【用例执行覆盖率】：计算测试用例执行总数除以与之一一对应的测试数之和，主要查看是否有测试用例执行遗漏或有效的情况。 【公式】：∑执行的测试用例个数（个）/ ∑测试用例个数（个）*100% 【数据来源】：《iSMS测试进度跟踪表》 【计算结果】：用例执行覆盖率=100%
软件评价指标
软件评价指标 Last updated at 10:00 am on 25th December 2020
我们常说某某软件好用，某软件功能全、结构合理、层次分明。这些表述很含糊，用来评价软件质量不够确切，不能作为企业选购软件的依据。对于企业来说，开发单位按照企业的需求，开发一个应用软件系统，按期完成并移交使用，系统正确执行用户规定的功能，仅仅满足这些是远远不够的。因为企业在引进一套软件过程中，常常会出现如下问题： ● 定制的软件可能难于理解，难于修改，在维护期间，企业的维护费用大幅度增加； ● 企业对外购的软件质量存在怀疑，企业评价软件质量没有一个恰当的指标，对软件可靠性和功能性指标了解不足； ● 软件开发商缺乏历史数据作为指南，所有关于进度和成本的估算都是粗略的。因为没有切实的生产率指标，没有过去关于软件开发过程的数据，企业无法精确评价开发商的工作质量。 为此，有必要先了解软件的质量评价体系。美国的.Ｂoehm和先后提出了三层次的评价度量模型：软件质量要素、准则、度量。随后提出了自己的软件质量度量SQM技术，波音公司在软件开发过程中采用了SQM技术，日本的NEC公司也提出了自己的SQM工具，即SQMAT，并且在成本控制和进度安排方面取得了良好的效果。 第一层是软件质量要素，软件质量可分解成六个要素，这六个要素是软件的基本特征：
1. 功能性：软件所实现的功能满足用户需求的程度．功能性反映了所开发的软件满足用户称述的或蕴涵的需求的程度，即用户要求的功能是否全部实现了。 2. 可靠性：在规定的时间和条件下，软件所能维持其性能水平的程度。可靠性对某些软件是重要的质量要求，它除了反映软件满足用户需求正常运行的程度，且反映了在故障发生时能继续运行的程度。 3. 易使用性：对于一个软件，用户学习、操作、准备输入和理解输出时，所做努力的程度。易使用性反映了与用户的友善性，即用户在使用本软件时是否方便。 4. 效率：在指定的条件下，用软件实现某种功能所需的计算机资源（包括时间）的有效程度。效率反映了在完成功能要求时，有没有浪费资源，此外＂资源"这个术语有比较广泛的含义，它包括了内存、外存的使用，通道能力及处理时间。 5. 可维修性：在一个可运行软件中，为了满足用户需求、环境改变或软件错误发生时，进行相应修改所做的努力程度。可维修性反映了在用户需求改变或软件环境发生变更时，对软件系统进行相应修改的容易程度。一个易于维护的软件系统也是一个易理解、易测试和易修改的软件，以便纠正或增加新的功能，或允许在不同软件环境上进行操作。 6. 可移植性：从一个计算机系统或环境转移到另一个计算机系统或环境的容易程度。 第二层是评价准则，可分成22点。包括精确性（在计算和输出时所需精度的软件属性）；健壮性（在发生意外时，能继续执行和恢复系统的软件属性）；安全性（防止软件受到意外或蓄意的存取、使用、修改、毁坏或泄密的软件属性）；以及通信有效
浅谈软件系统可靠性
浅谈软件系统可靠性 1 概述 近年来，随着计算机在军用与民用产品上的应用日益增多，软件缺陷所引发的产品故障，甚至灾难性事故也越来越严重，软件故障已成为高新技术产品发展的瓶颈。在这种情况下，一旦计算机系统发生故障，则其效益就会大幅度地消减，甚至完全丧失，从而使社会生产和经济活动陷入不可收拾的混乱状态。因此可以说，计算机系统的高可靠性是实现信息化社会的关键。 计算机系统硬件可靠性方面已有六十余年的发展历史，冗余技术、差错控制、故障自动检测、容错技术和避错技术等可靠性设计技术已经成熟。相比之下，软件可靠性的研究只有三十几年的发展历史，加上软件生产基本上仍处于作坊式的手工制作，其提高软件可靠性的技术与管理措施还处于十分不完善的状况。20 世纪70 年代末至80 年代初，软件可靠性的研究集中于对软件可靠性模型进行比较和选择。90 年代以来，软件可靠性研究工作进展较快，主要集中在软件可靠性设计、软件可靠性测试与管理以及软件可靠性数据的收集这三个方面。 2 软件可靠性的基本概念 2.1 软件可靠性的定义 1983年，美国IEEE计算机学会软件工程技术委员会对软件可靠性的定义如下： a）在规定的条件下，在规定的时间内，软件不引起系统失效的概率，该概率是系统输入和系统使用的函数，也是软件中存在的错误的函数；系统输入将确定是否会遇到已存在的错误。 b）在规定的时间周期内，在所述条件下程序执行所要求的功能的能力。 软件可靠性定义中提到的“规定的条件”和“规定的时间”，在工程中有重要的意义。 定义中的“时间”有3种度量。第一种是日历时间，指日常生活中使用的日、周、月和年等计时单元；第二种是时钟时间，指从程序运行开始到运行结束所用的时、分、秒；第三种是执行时间，指计算机在执行程序时实际占用的CPU 时间。 定义中所指的“条件”，是指环境条件，包括了与程序存储、运行有关的计算机及其操作系统。 2.2 影响软件可靠性的主要因素 软件可靠性表明了一个程序按照用户的需求和设计的目标，执行其功能的正确程度。这要求一个可靠的程序应是正确的、完整的、一致的和健壮的。软件可靠性的决定因素是与输入数据有关的软件差错，正是因为软件中的差错引起了软件故障，使软件不能满足需求。影响软件可靠性的因素主要包括： 1、软件开发的支持环境； 2、软件的开发方法；
软件开发度量及考核方法精修订
软件开发度量及考核方 法 集团标准化工作小组 #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 ～优质
软件项目量化管理方法
软件项目量化管理方法 摘要：本文在对软件企业量化管理应用常见问题分析的基础上，以解决可操作性、可比性等问题为着眼点，识别出了量化管理中必须明确的四要素，表述了企业在量化四要素上采用的常见做法。 本文采用80/20原则，说明了企业在识别度量对象时应避免的问题；采用持续改进的理论，说明了企业在量化管理应遵循的客观规律。在结合平衡记分卡与目标驱动组合式的量化管理方法理论基础上，提出了软件企业的量化管理的具体应用步骤。 关键词：量化管理四要素80/20原则持续改进GQ(I)M 1. 引言 如今，很多国内软件企业选择采用能力成熟度系列模型（Capa bility Maturity Model, CMM）或其它模型来建立本企业的软件过程规范，欲通过提升软件过程的能力达到提高产品质量、降低开发风险、减少开发成本、保证产品按时交付等目的。将软件过程规范的一个目的就是使软件过程可视化，这个可视化则要求了对软件过程的量化；而产品质量是否提高、开发风险是否降低、开发成本是否减少、项目延期是否缩短，对这些问题的回答则要求了对软件项目的量化；软件过程改进与量化管理息息相关。
不少企业在将识别出的量化管理方法应用于软件项目管理过程时，发现不少问题。最为常见的是： 量化工作的可操作性不强，如：部分量化数据难以收集、难以统计投入的成本没有得到预期的产出。如：量化工作投入了成本，但形成的量化结果参考价值不高提供给管理层用于决策的支持数据也不够，数据缺乏可比性量化结果不是管理层所关心的，达不到管理层预期的过程可视化程度 针对此类问题，本文识别出了在量化管理中必须要考虑的四个方面，即：量化四要素，并从量化四要素对量化管理方法进行了分析，建议了软件企业采用的量化管理方法。 2. 量化四要素 “只有通过对产品、过程的度量，才能描述、评价、提高产品与过程”。 笔者认为，要度量，就要明确度量的对象；要度量对象，就要明确标识度量对象的计量单位；要产生度量结果，就要明确度量方法，包括度量技术和数据收集的方法；要评价度量对象，就要明确用于比对的基准指标，即表征度量对象目前情况的标尺，通过该标尺与度量结果的比对，得出对度量对象的评价。而度量对象（Object）、计量单位（Unit）、度量方法（Method）、基准指标（Benchmark），这就是笔者所说的量化四要素。
软件质量度量指标v1.0
软件质量指标度量 1综述 (2) 1.1编写目的 (2) 1.2阅读指南 (2) 2软件质量指标 (3) 2.1需求功能点覆盖率 (3) 2.2用例执行覆盖率 (3) 2.3缺陷修复率（截至于**年*月*日） (4) 2.4缺陷遗留个数（截至于**年*月*日） (4) 2.5缺陷分布统计（模块缺陷率） (4) 2.6缺陷分布统计（严重缺陷率） (5) 2.7缺陷密度及收敛 (5) 3测试过程质量指标 (8) 3.1缺陷探测率 (8) 3.2有效缺陷率 (8) 3.1用例执行效率 (9) 3.2缺陷发现率 (9) 4交付质量指标 (11) 4.1加载回退率 (11) 4.2故障回退率 (11) 5版本说明 (12)
1综述 1.1编写目的 本文档主要为测试经理、测试组长/测试人员、技术负责人、项目经理、开发人员等提供软件质量、测试质量、交付质量等衡量依据。通过不同指标的目标设定、过程跟踪、结果分析，为当期被测产品的质量提供可参考的数据，也为后续测试提供数据的基础积累，并作为制定方法流程的依据。 1.2阅读指南 ●软件测试质量指标主要针对研发项目、商务项目被测产品出具数据 度量。 ●测试过程质量指标主要为测试经理、测试组长对测试人员的测试执 行质量出具数据度量。 ●交付质量主要为新需求的交付质量出具数据度量。 三者可单独使用，也可结合使用。
2软件质量指标 2.1需求功能点覆盖率 【需求覆盖率】：计算测试用例总数之和除以与之一一对应的功能点数之和，主要查看是否有功能点遗漏测试的情况。 【公式】：∑测试用例数（个） / ∑功能点（个） 说明：用例覆盖需求矩阵，一个需求对应多个功能点。 【数据来源】：《联通集中集团客户业务支撑系统销售管理用户需求说明书》《联通集中集团客户业务支撑系统销售管理需求跟踪矩阵》 【计算结果】需求覆盖率=113/8=14.13 2.2用例执行覆盖率 【用例执行覆盖率】：计算测试用例执行总数除以与之一一对应的测试数之和，主要查看是否有测试用例执行遗漏或有效的情况。 【公式】：∑执行的测试用例个数（个） / ∑测试用例个数（个）*100% 【数据来源】：《iSMS测试进度跟踪表》 【计算结果】：用例执行覆盖率=100%
IEEE软件可靠性系列标准分析
IEEE软件可靠性系列标准分析 摘要：对IEEE软件可靠性系列标准进行分析，总结了IEEE制定软件可靠性标准的经验，以及软件可靠性发展趋势。同时，结合我国软件可靠性标准化工作现状，提出软件可靠性标准的制定及相关标准修订的可借鉴之处。关键词：软件可靠性标准；软件可靠性度量；软件可靠性评估过程；软件可靠性模型 随着计算机技术的快速发展，现代航电系统大量使用软件系统，其中某些软件系统在保证航空系统安全、可靠完成任务时起到了至关重要的作用，但这些软件的失效可能导致灾难性后果。为了提高软件可靠性，相关领域的学者展开了广泛的软件可靠性研究，特别是全球最大的专业学术组织IEEE，更是在这方面作出了卓越的成绩。IEEE在开展软件可靠性研究的同时，也非常重视相关标准的制定工作。1988年，IEEE制定了第一份关于软件可靠性度量体系方面的标准[1]以及该标准的实施指南[2]。2005年，IEEE对软件可靠性度量体系标准进行了修订[3]。2008年，IEEE对R-013-1992标准进行修订 [4]，R-013-1992标准是AIAA(美国航空与航天学会)在1992年制定的关于软件可靠性评估的标准[5]，这也说明IEEE在软件可靠性方面的成绩是国际公认的。IEEE主要制定了软件可靠性度量体系和评估两方面的标准。本文将对IEEE制定的软件可靠性标准进行介绍和分析，总结IEEE制定软件可靠性标准的经验，以及软件可靠性发展趋势，结合我国软件可靠性标准现状，提出可靠性标准的制定及相关标准修订的可以借鉴之处。1 IEEE软件可靠性标准分析1.1 标准简介IEEE软件可靠性标准主要包括软件可靠性度量体系和软件可靠性评估两方面。其中，软件可靠性度量体系由IEEE Std 982.1-2005(软件可信性度量词典)和IEEE Std 982.2-1988(软件可靠性度量实施指南)组成，IEEE Std 982.1-2005是IEEE Std 982.1-1988的修订版；软件可靠性评估主要包括IEEE Std 1633-2008(软件可靠性操作规程)，它发布于2008年，替代了AIAA/ANSI R-013-1992(软件可靠性操作规程)。在IEEE软件可靠性标准体系中，IEEE Std 982.1-2005主要回答了使用哪些参数对软件可靠性进行度量的问题，即用户可以通过哪些方面对软件质量、特别是软件的可靠性进行了解和评价。与IEEE Std 982.1-1988相比，IEEE Std 982.1-2005作出了较大程度的修改。1988版关于软件可靠性属性有39个不同的度量参数，而2005版中只有12个，并且其中75%的度量参数是新增或修改的。IEEE Std 982.2-1988主要回答了如何使用这些度量参数对软件可靠性进行度量的问题，但是该标准主要是针对IEEE Std 982.1-1988度量参数体系的，而IEEE Std 982.1-2005中有75%的度量参数和IEEE Std 982.1-1988不一样。因此，对于当前的软件可靠性度量参数体系，该标准实际上已经失去了指导意义。IEEE Std 1633-2008主要解决了如何进行软件可靠性评估的问题，包括软件可靠性评估过程和软件可靠性评估模型两方面。其中，软件可靠性评估过程包含13个步骤，这些步骤不是全部必需的，可根据软件特点和当前所处的软件生命周期阶段进行删减；软件可靠性评估模型方面推荐了三个模型，这三个模型都是在实际工程中表现优异的评估模型。1.2 软件可靠性度量参数体系IEEE Std 982.1-2005是IEEE Std 982.1-1988的修订版，它体现了软件可靠性作为软件质量重要属性在软件质量控制方面的新方法和新趋势。与1988版相比，2005版作出了较大程度的修改。1988版关于软件的可靠性属性有39个不同的度量参数，而2005版删除了其中的32个度量参数，并对剩余度量参数中4个进行了修改，只有3个得到完全保留，同时新增了5个度量参数。即可靠性度量参数由原来的39个变更为12个，其中有75%的度量参数是新增或修改的。可以说2005版基本上重新定义了软件可靠性的度量体系，新度量参数体系如表1所示。IEEE在选取度量参数建立软件可靠性度量参数体系时，有如下准则：(1)该参数是否得到了学术界和工业界的公认；(2)该参数是否能有效地反映出软件可靠性的真实情况；(3)该参数是否过于复杂，以至难于使用和理解；(4)该参数适用情况是否过于狭小。从IEEE选取度量参数的准则可以看出，软件可靠性度量的发展
软件可靠性的评价准则
软件可靠性的评价准则 迄今为止,尚无一个软件可靠性模型对软件的不同特性和不同使用环境都有效。已公开发表的100余种软件可靠性模型,表达形式不同,适应性各异,与实际的软件开发过程有较大差异。而且,新模型还在不断发表。因此,在进行软件可靠性预计、分析、分配、评价和设计之前,对软件可靠性模型进行评价及选择与软件项目相符或相近的模型非常重要。通过建立有效的评价准则,在考虑它们与各种软件的关系的基础上,对拟评价的可靠性模型就有效性、适应性和模型能力等进行评价,判定它们的价值,比较它们的优劣,然后选择有效的软件可靠性模型。另一方面,在可接受的模型之间无法做出明确的选择时,可根据模型的使用环境等,在模型评价准则的基础上,进行模型择优。当然,软件可靠性模型的评价不仅依赖于模型的应用,还依赖于理论的支持和丰富的、高质量可靠性数据的支持。软件可靠性模型的评价最早始于1984年Iannino、Musa、Okumoto和Littlewood所提出的原则。根据这一原则,结合后人的工作,形成了基本的软件可靠性评价准则集。它们是软件可靠性模型比较、选择和应用的基础。 准则一:模型预测有效 软件可靠性模型最重要的评价指标是模型预测的有效性。它根据软件现在和过去的故障 行为,用模型预测软件将来的故障行为和可靠性水平。它主要通过能有效描述软件故障随机过程特性的故障数方式对模型进行描述与评价。基于软件故障时间特性的随机过程也是一种常用的方法,而且这两种方法相互重叠。 要确定软件可靠性模型预测的有效性,首先要比较模型预测质量。这种比较通常通过相 对误差法、偏值、U图法、Y图法、趋势法等方法进行。故障数度量是一种在工程上被广泛应 用的方法。此外,还可以通过比较不同数据集合所做出的中位线图形来评价模型预测的有效性。如果一个模型产生的曲线最接近于0,则该模型是最优的。而且,这种有效性测定方法有效地克服了规范化图形评价与具体软件项目之间的联系,保证了它的独立性。 用给定可靠性数据对软件可靠性模型进行比较时,必须考察拟合模型与观察数据的一致 性和符合性。当然,根据拟合模型进行采样,是否可以获得足够的观察数据非常重要。拟合优度检验是一种系统地表达并证明观察数据和拟合模型之间全局符合性的方法,使用最广泛的是x2检验。 1.准确性 软件可靠性模型预测的准确性可用前序似然函数来测定。设观察到的失效数据对应于软 件相继失效之间的时间序列t1,t2,..,ti-1,并用这些数据来预测软件在未来可能的Ti,即希 望得到Ti的真实概率密度函数Fi(t)的最优估计值。假设以t1,t2,...,ti-1为基础预测Ti的 分布Fi(t)的概率密度函数 @@42D11000.GIF;表达式1@@ 对Ti+1,Ti+2,...,Ti+n的这种向前一步预测,即进行了n+1次预测之后的前序似然函数为 @@42D11001.GIF;表达式2@@ 由于这种度量常常接近于0,所以常用其自然对数进行比较。假定比较的两个软件可靠性 模型分别为A和B,则对它们进行n次预测之后的前序似然比为 @@42D11002.GIF;表达式3@@
软件质量度量分析与研究
龙源期刊网 https://www.wendangku.net/doc/f517728755.html, 软件质量度量分析与研究 作者：余为峰,黄松 来源：《电脑知识与技术》2010年第18期 摘要:随着软件的复杂性日益增长, 软件开发的周期以及费用也日益增长,软件质量的保证与提高越来越成为了人们高度重视的问题。解释了软件质量的概念和质量模型的发展阶段,分析 了软件质量度量的过程以及度量的验证与预测,提出了几种针对软件质量的度量方法,最后对软件质量的度量做了相关的展望。 关键词:软件质量;度量;质量度量模型;度量验证 中图分类号:TP311文献标识码:A文章编号:1009-3044(2010)18-5106-03 Analysis and Research of Software Quality Metrics YU Wei-feng, HUANG Song (Software Test and Evaluation Center for Military Training, Institute of Command Automation, PLA University of Science & Technolog, Nanjing 210007, China) Abstract: As the complexity of software is increasing, the cycle of software development and cost are also increasing. And people have paid more and more attention to the question that how to assure and improve the software quality. This paper not only explains the definition of software quality and developing phases of quality model, but also analyses the process of software quality metrics and validation of quality metrics. At the same time, it introduces several methods of software quality metrics. Finally, related future trends of research in this field is listed. Key words: software quality; metrics; quality metrics model; metrics validation 在过去几十年里,因为软件的质量问题而导致整个系统发生失效的事例屡见不鲜,进而给人类生命安全和环境造成了巨大的损失。20世纪80年代,美国有两个系统,耗资5600万美元的Univac联合航空订票系统和耗资2.17亿美元的高级后勤系统都因在交付使用后发现不满足要求而被迫进行重新研制[1];而在1996年6月,在阿丽亚娜5号火箭首次发射后不到一分钟的时间内,就因为软件故障问题致使火箭发生了爆炸,导致了巨大的经济损失和相应计划的延迟[2]。因此软件的质量问题已引起了人们的极度重视,软件质量的度量问题自然也得到重视。
软件质量国家标准GB(质量管理度量)
软件质量国家标准GB-T8566--2001G,软件质量要素: 1.功能性-与一组功能及其指定性质有关的一组属性,这里的功能是满足明确或隐含的需求的那些功能.包含: a.完备性-软件功能完整,齐全有关的软件属性. b.正确性-能否得到正确或相符结果或效果有关的软件属性 2.可靠性-在规定的一段时间和条件下,与软件维持其性能水平的能力有关的一组属性.包含: a.可用度-软件运行后在任一随机时刻需要执行规定任务或完成规定功能时,软件处于可使用状态的概率. b.初期故障率-软件在初期故障期(一般为软件交付用户后的3个月)内单位时间(100小时)的故障数. c.偶然故障率-软件在偶然故障期(一般为软件交付用户后的4个月以后)内单位时间的故障数. d.平均失效前时间(MTTF)-软件在失效前正常工作的平均统计时间. e.平均失效间隔时间(MTBF)-软件在相继两次失效之间正常工作的平均统计时间.一般民用软件大体在1,000小时左右. f.缺陷密度(FD)-软件单位源代码(1,000行无注释)中隐藏的缺陷数量.典型统计表明,开发阶段平均50-60个缺陷/千行源码, 交付后平均15-18个缺陷/千行源码. g.平均失效恢复时间(MTTR)-软件失效后恢复正常工作所需的平均统计时间. 3.易用性-由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性.包含: a.易理解性-用户认识软件的逻辑概念及其应用范围所花的努力有关的软件属性. b.易学习性-用户为学习软件(运行控制,输入,输出等)所花的努力有关的软件属性. c.易操作性-用户为操作和运行控制所花的努力有关的软件属性 4.效率性-与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性.包含: a.输出结果更新周期-软件相邻两次输出结果的间隔时间. b.处理时间-软件完成某项功能(辅助计算或决策)所用的处理时间(不含人机交互的时间). c.吞吐量-单位时间软件的信息处理能力(各种目标的处理批数). d.代码规模-软件源程序的行数(不含注释), 属于软件的静态属性 5.可维护性-与进行指定的修改所需的努力有关的一组属性 6.可移植性-与软件从一个环境转移到另一个环境的能力有关的一组属性. 影响软件系统质量的4个关键技术要素 1.技术平台的寿命 2.试运行期 3.对于现有系统的迁移 4.技术扩展
可靠性定义及其度量指标
可靠性定义及其度量指标 【大纲考试内容要求】： 1、了解机械失效三个阶段和维修度、有效度、平均无故障工作时间； 2、熟悉可靠性、故障率、可靠性预计、人机界面设计要点。 【教材内容】： 第四节机械的可靠性设计与维修性设计 一、可靠性定义及其度量指标 (一)可靠性定义 所谓可靠性是指系统或产品在规定的条件和规定的时间内，完成规定功能的能力。 这里所说的规定条件包括产品所处的环境条件(温度、湿度、压力、振动、冲击、尘埃、雨淋、日晒等)、使用条件(载荷大小和性质、操作者的技术水平等)、维修条件(维修方法、手段、设备和技术水平等)。在不同规定条件下，产品的可靠性是不同的。 规定时间是指产品的可靠性与使用时间的长短有密切关系，产品随着使用时间或储存时间的推移，性能逐渐劣化，可靠性降低。所以，可靠性是时间的函数。这里所规定的时间是广义的，可以是时间，也可以用距离或循环次数等表示。 (二)可靠性度量指标 1．可靠度 可靠度是可靠性的量化指标，即系统或产品在规定条件和规定时间内完成规定功能的概率。可靠度是时间的函数，常用R(t)表示，称为可靠度函数。 产品出故障的概率是通过多次试验中该产品发生故障的频率来估计的。例如，取N个产品进行试验，若在规定时间t内共有Nf(t)个产品出故障，则该产品可靠度的观测值可用下式近似表示：R(t)≈[N—Nf(t)]／N (4—7) 与可靠度相反的一个参数叫不可靠度。它是系统或产品在规定条件和规定时间内未完成规定功能
的概率，即发生故障的概率，所以也称累积故障概率。 不可靠度也是时间的函数，常用F(t)表示。同样对N个产品进行寿命试验，试验到瞬间的故障数为Nf(t)，则当N足够大时，产品工作到t 瞬间的不可靠度的观测值(即累积故障概率)可近似表示为： F(t)≈Nf(t)／N (4—8) 可靠度数值应根据具体产品的要求来确定，一般原则是根据故障发生后导致事故的后果和经济损失而定。 2．故障率(或失效率) 故障率是指工作到t 时刻尚未发生故障的产品，在该时刻后单位时间内发生故障的概率。故障率也是时间的函数，记为γ(t)，称为故障率函数。 产品的故障率是一个条件概率，它表示产品在工作到t 时刻的条件下，单位时间内的故障概率。它反映t 时刻产品发生故障的速率，称为产品在该时刻的瞬时故障率且γ(t)，习惯称故障率。故障率的观测值等于N个产品在t时刻后单位时间内的故障产品数△Nf(t)／△t与在t时刻还能正常工作的产品数Ns(t)之比，即： γ(t)＝△Nf(t)／[Ns(t)·△t] (4——9) 故障率(失效率)的常用单位为(1／106h)。 产品在其整个寿命期间内各个时期的故障率是不同的，其故障率随时间变化的曲线称为寿命的曲线，也称浴盆曲线，如图4—6所示。 由图可见，产品的失效过程可分为以下3个阶段：
5个常用的软件质量指标
5 个常用的软件质量指标 在软件开发中，软件质量是衡量软件是否符合需求、标准的重要体现。除了代码质量外，影响软件整体质量的因素还有很多。因此，要确保软件的整体质量，就需要在各个环节严格控制。 本文列出了衡量软件质量的5个最常用的指标。 1、SLOC（Source Lines of Code，源代码行） 计算代码行数可能是最简单的衡量指标，主要体现了软件的规模，并为项目增长和规划提供了相关数据。例如，如果每月统计一次代码的行数，就可以绘制一个项目发展概览图。当然，由于存在项目重构或是设计阶段等因素，这种方式并不太可靠，但是可以为项目的发展提供一个视角。 可以只统计逻辑代码行（Source Logical Line of Code，SLLOC），这样可以获得稍准确的信息。逻辑代码行不包含空行、单个括号行和注释行。可以使用Metrics 工具来统计。 代码行数不应该用来评估开发者的效率，否则，可能会产生重复、不可维护的或不专业的代码。 2、每个代码段/模块/时间段中的bug数 要想实现更好的测试以及更高的可维护性，bug 跟踪是必不可少的。每个代码段、模块或时间段（天、周、月等）内的 bug 可以很容易通过工具统计出来（如 Mantis）。这样，可以及早发现并及时修复。 Bug 数可以作为评估开发者效率的指标之一，但必须注意，如果过分强调这种评估方法，软件开发者和测试者可能会成为敌人。在生产企业中，要保证员工彼此之间的凝聚力。 为了更好的实现评估，可以根据重要性和解决成本将 bug 划分为低、中、高三个级别。 3、代码覆盖率 在单元测试阶段，代码覆盖率常常被拿来作为衡量测试好坏的指标，也用来考核测试任务完成情况。可以使用的工具也有很多，如 Cobertura 等。 代码覆盖率并不能代表单元测试的整体质量，但可以提供一些测试覆盖率相关的信息，可以和其他一些测试指标一起来使用。 此外，在查看代码覆盖率时，还需注意单元测试代码、集成测试场景和结果等。
软件质量度量指标v
软件质量度量指标V ?
作者:日期:
4.1 加载回退率 错误!未定义书签。 软件质量指标度量 错误!未定义书签。 2软件质量指标 2 .1?需求功能点覆盖率？错误 味定义书签。 2 .2?用例执行覆盖率潴误味定义书签。 2 .3?缺陷修复率（截至于**年*月*日）?错误!未定义书签。 2.4?缺陷遗留个数（截至于* *年*月*日）?错误 味定义书签。 27?缺陷密度及收敛 3测试过程质量指标？错误!未定义书签。 3. 1 缺陷探测率 3 .2?有效缺陷率11? 4. 2 故障回退率 1综述 1.1 编写目的？错误!未定义书签。 1.2 阅读指南？错误!未定义书签。 错误!未定义书签。 2 .5?缺陷分布统计（模块缺陷率） 错误!未定义书签。 2.6 缺陷分布统计（严重缺陷率 ） 错误!未定义书签。 错误!未定义书签。 错误!未定义书签。 3.1 用例执行效率 错误!未定义书签。 3.2 缺陷发现率12? 4?交付质量指标 错误!未定义书签。 错误!未定义书签。
5?版本说明?错误!未定义书签。 作者:
1综述 1.1编写目的 本文档主要为测试经理、测试组长/测试人员、技术负责人、项目经 理、开发人员等提供软件质量、测试质量、交付质量等衡量依据。通过不同指标的目标设定、过程跟踪、结果分析，为当期被测产品的质量提供可参考的数据，也为后续测试提供数据的基础积累，并作为制定方法流程的依据。 1.2阅读指南 软件测试质量指标主要针对研发项目、商务项目被测产品出具数据度量。 测试过程质量指标主要为测试经理、测试组长对测试人员的测试执行质量出具数 据度量。 交付质量主要为新需求的交付质量出具数据度量。 三者可单独使用，也可结合使用。
软件开发度量及考核方法
软件开发度量及考核方法 一、引言 如果要提高软件开发人员的开发质量，必须有相应的考核制度，有了制度后才能推动开发人员想方设法改善自已的开发质量。虽然目前很多公司有这方面的绩效考核，但是由于软件开发行业的特殊性，大多数公司没有对软件开发的过程进行细粒度的度量，所以不能依据有效的度量数据来考核开发人员的工作绩效，大部份只是凭考核人主观意志来考核，不能形成对被考核人有效的说服力。所以根据以前经验和相关的资料编写了适用于本部门的度量和考核方法。该考核方法是技术支持部软件开发人员和测试人员的试行版本。 二、目的 对软件开发的过程所产生的软件项的质量和过程进行定量的评价，用评价的结果指导软件的开发过程，不断地提高软件开发质量水平，并依据度量记录来考核软件开发人员的工作绩效。 三、考核实施办法 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在整个指标体系中所占的权重系数，对不同的开发项目可能不同，此系数根据开发的不同着重点给出。
软件质量度量指标v2.0
软件质量指标度量 V 2.0 2014.12
目录 1综述 (3) 1.1编写目的 (3) 1.2阅读指南 (3) 2 ...................................................................................... 软件质量指标 4 2.1需求功能点覆盖率 (4) 2.2用例执行覆盖率 (4) 2.3缺陷修复率（截至于**年*月*日） (5) 2.4缺陷遗留个数（截至于**年*月*日） (5) 2.5缺陷分布统计（模块缺陷率） (5) 2.6缺陷分布统计（严重缺陷率） (6) 2.7缺陷密度及收敛 (7) 3 ..........................................................................测试过程质量指标 9 3.1缺陷探测率 (9) 3.2有效缺陷率 (9) 3.1用例执行效率 (10) 3.2缺陷发现率 (10) 4 ...................................................................................... 交付质量指标
12 4.1加载回退率 (12) 4.2故障回退率 (12) 5 .................................................................................................. 版本说明 13
1综述 1.1编写目的 本文档主要为测试经理、测试组长/测试人员、技术负责人、项目经理、开发人员等提供软件质量、测试质量、交付质量等衡量依据。通过不同指标的目标设定、过程跟踪、结果分析，为当期被测产品的质量提供可参考的数据，也为后续测试提供数据的基础积累，并作为制定方法流程的重要依据。 1.2阅读指南 软件测试质量指标主要针对研发项目、商务项目被测产品出具数据度量。 测试过程质量指标主要为测试经理、测试组长对测试人员的测试执行质量出具数据度量。 交付质量主要为新需求的交付质量出具数据度量。 三者可单独使用，也可结合使用。
Web应用测试方法与可靠性度量
报告人：开金宇导 师：缪淮扣教授1 多实例部署模式下 面向用户的服务系统可靠性分析
1.背景介绍 2.方法介绍 3.可靠性分析步骤 4.组件多实例部署的一个例子 5.实验与讨论
可靠性是软件系统一个非常重要的服务质量属性，对软件系统的可靠性分 析一直是一个研究热点。 cheung认为：可靠性是一种运行中的质量表现，采用面向用户的系统可靠性分析能更真实地体反映软件系统的可靠性。 之后的许多研究扩展了cheung提出的面向用户的软件可靠性分析模型。但这些面向用户的可靠性分析模型都是面向软件系统的设计阶段，假定软件系统中的组件是单实例部署运行的。
当前，面向服务的系统开发方法已经成为系统开发的新泛型。 面向服务的系统开发方法其特点是：构成服务系统的组件服务分布更加独立；服务系统的开发更加灵活快捷；使从idea到product到market的过程更加迅速。 随着服务系统的访问量的增大，单实例部署模式已经不能满足用户访问需求，这就需要通过组件服务或组合服务（即，服务系统）的多实例部署实现服务系统的可扩展性。
服务系统的组件服务及组合服务的部署的灵活，使得传统的面向设计阶段、 假定软件系统为单实例部署的面向用户的可靠性分析方法不能准确地分析多实例部署下面向用户的服务系统的可靠性，因此，有必要研究多实例部署模式下面向用户的服务系统的可靠性。
提出了一种多实例部署下面向用户的服务系统可靠性分析方法，在传统的面向用户系统可靠性分析方法的基础上，采用向量的方式表示服务系统中多实例部署的组件服务的可靠性，通过用户使用剖面与多实例部署的组件服务的可靠性相结合，构建了多实例部署下服务系统可靠性分析模型，从而完成对多实例部署下的服务系统的可靠性分析。
软件评价指标
软件评价指标 文件管理序列号：[K8UY-K9IO69-O6M243-OL889-F88688]
我们常说某某软件好用，某软件功能全、结构合理、层次分明。这些表述很含糊，用来评价软件质量不够确切，不能作为企业选购软件的依据。对于企业来说，开发单位按照企业的需求，开发一个应用软件系统，按期完成并移交使用，系统正确执行用户规定的功能，仅仅满足这些是远远不够的。因为企业在引进一套软件过程中，常常会出现如下问题： ● 定制的软件可能难于理解，难于修改，在维护期间，企业的维护费用大幅度增加； ● 企业对外购的软件质量存在怀疑，企业评价软件质量没有一个恰当的指标，对软件可靠性和功能性指标了解不足； ● 软件开发商缺乏历史数据作为指南，所有关于进度和成本的估算都是粗略的。因为没有切实的生产率指标，没有过去关于软件开发过程的数据，企业无法精确评价开发商的工作质量。 为此，有必要先了解软件的质量评价体系。美国的B.W.Ｂoehm和R.Brown 先后提出了三层次的评价度量模型：软件质量要素、准则、度量。随后G.Mruine 提出了自己的软件质量度量SQM技术，波音公司在软件开发过程中采用了SQM 技术，日本的NEC公司也提出了自己的SQM工具，即SQMAT，并且在成本控制和进度安排方面取得了良好的效果。 第一层是软件质量要素，软件质量可分解成六个要素，这六个要素是软件的基本特征： 1. 功能性：软件所实现的功能满足用户需求的程度．功能性反映了所开发的软件满足用户称述的或蕴涵的需求的程度，即用户要求的功能是否全部实现了。 2. 可靠性：在规定的时间和条件下，软件所能维持其性能水平的程度。可靠
软件可靠性设计规范
软件可靠性设计规范
1.建立以可靠性为核心的质量标准 在软件项目规划和需求分析阶段就要建立以可靠性为核心的质量标准。这个质量标准包括实现的功能、可靠性、可维护性、可移植性、安全性、吞吐率等等，虽然还没有一个衡量软件质量的完整体系，但还是可以通过一定的指标来指定标准基线。 软件质量从构成因素上可分为产品质量和过程质量。 产品质量是软件成品的质量，包括各类文档、编码的可读性、可靠性、正确性，用户需求的满足程度等。 过程质量是开发过程环境的质量，与所采用的技术、开发人员的素质、开发的组织交流、开发设备的利用率等因素有关。 还可把质量分为动态质量和静态质量。静态质量是通过审查各开发过程的成果来确认的质量，包括模块化程度、简易程度、完整程度等内容。动态质量是考察运行状况来确认的质量，包括平均故障间隔时间(MTBF)、软件故障修复时间(MTRF)、可用资源的利用率。在许多实际工程中，人们一般比较重视动态质量而忽视静态质量。 所定的质量标准度量，至少应达到以下两个目的: (1).明确划分各开发过程(需求分析过程，设计过程，测试过程，验收过程)，通过质量检验的反馈作用确保差错及早排除并保证一定的质量。 (2).在各开发过程中实施进度管理，产生阶段质量评价报告，对不合要求的产品及早采取对策。 确定划分的各开发过程的质量度量： (1).需求分析质量度量 需求分析定义是否完整、准确(有无二义性)，开发者和用户间有没有理解不同的情况，文档完成情况等，要有明确的可靠性需求目标、分析设计及可靠性管理措施等。 (2).设计结果质量度量 设计工时，程序容量和可读性、可理解性，测试情况数，评价结果，文档完成情况等。