GB T 18905.1-2002 软件工程 产品评价 第1部分;概述.pdf

《GB T 18905.1-2002 软件工程 产品评价 第1部分;概述.pdf》由会员分享，可在线阅读，更多相关《GB T 18905.1-2002 软件工程 产品评价 第1部分;概述.pdf（16页珍藏版）》请在麦多课文档分享上搜索。

1、ICS 35.080 L77 人民共国国标GB/T 18905. 1-2002jISO/IEC 14598-1: 1999 4 软件工程产晶评价第1部分:概述Software engineering Product evaluation Part 1: General overview CISO/IEC 14598-1: 1999 , Information technology-Software product envaluation-Part 1: General overview , IDT) 2002-12-04发布378 中华人民共和国国家质量监督检验检痊总局2003-05-01实施

2、发布GB/T 18905. 1-2002/ISO/IEC 14598-1: 1999 前言主FE司GB/T 18905-2002(软件工程产品评价分为六个部分z第1部分z概述:一一第2部分2策划和管理;第3部分z开发者用的过程;第4部分g需方用的过程g一一第5部分=评价者用的过程s一一第6部分z评价模块的文档编制。本部分为GBIT18905-2002的第1部分，等同采用ISO/IEC14598-1: 1999(英文版。本部分由中华人民共和国信息产业部提出。本部分由中国电子技术标准化研究所归口。本部分起草单位.北京信息工程学院、中国电子技术标准化研究所。本部分主要起草人:王凌、冯惠、罗锋盈、陈莹

3、。379 GB/T 18905. 12002/ISO/IEC 14598-1: 1999 百ltR 随着信息技术应用的不断增长，关键的计算机系统的数量也在增长。这些系统包括2安全、生活、经济以及保密方面的关键系统。这些系统的软件质量尤其重要啕因为软件的故障可能导致非常严重的后果。纵观整个软件工程的历史，提高软件质量已成为最重要的目标。评价软件产品的质量对获取和开发满足质量需求的软件是不可缺少的囚各种软件质量特性的相关重要性取决于作为整体一部分的系统的任务和目标，需要评价软件产品以判断其相关的质量特性是否满足系统的需求。软件质量评价的基本部分包括:质量模型、评价方法、软件的测量和支持工具。要想开

4、发好的软件，宜规定质量需求，宜策划、实现和控制软件质量保证过程，宜评价中间产品和最终产品。要达到评价软件质量的目的.宜用有效的度量方法进行测量软件的质量属性。术语度量在软件工程出版物中有多种含义，在本部分中被定义为用于测量的一种量化的标度和方法。名词度量用来指测量的结果。GS/T J8905系列标准为软件产品质量的测量、评估和评价提供了方法。它所描述的既不是软件生产过程的评价方法，也不是预算成本的方法软件产品的质量测量当然可以用于这两个目的)。380 GB/T 18905. 1-2002!ISO/IEC 14598-1: 1999 1 范围软件工程产品评价第1部分:概述GB/T 18905的本

5、部分介绍G8/T 18905的其他部分。它给出了其他部分的概述，解释了G8/T18905与ISO/IEC9126标准中质量模型的关系。本部分还定义了其他部分用到的技术术语，包含了软件质量规格说明和评价的一般需求.闲明了一般概念。此外，它还提供了一个评价各种类型的软件产品质量的框架，说明了软件产品测量与评价方法的需求。GB!T 18905旨在提供给软件的开发者、软件的需方和独立的评价者使用，特别是供那些负责软件产品评价的人员使用。应用G8/T18905所产生的评价结果可供管理者、开发者或维护者测量软件是否符合需求，并在必要的地方F以改进。分析人员可用评价结果来建立内部度量与外部度量间的关系。过程

6、改进人员可用评价结果来确定如何通过研究和检杏项目的产品质量信息来改进过程。传:GB!T 18905中的大多数指南并不特别针对软件.也适用于其他的复杂产品。2 一致性如果使用了第6章中的过程和8.:l中要求的质量模型，软件的规格说明和评价就与G8/T18905 A致。与GB/T18905整体上致成意味着叮G8!T18905所有己公布的部分一致。3 规范性引用文件下列文件中的条款通过本部分的.，1用向成为本部分的条款。凡是注H期的引用文件，其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最

7、新版本适用于本部分。GI:l!T 527 1. 1-2000信息技术词汇第1部分2基本术语(idtISO/IEC 2382 1: 1993) GI:l/丁6583-1994质量管理和质量保证词汇(idtISO 8402: 1994) GB/T 8566一2001信息技术软件生存周期过程。dtISO/IEC 12207: 1995) ISO/IEC 9126- 软件工程产品质量第1部分z质量模型4 术语和定义4. 1 4.2 下列术语和定义适用于GB!T1890S的所有部分。需方acquirer 从供方获得或采购系统、软件产品或软件服务的组织。GI:l/T 8566-2001 J 属性attri

8、bule 实体的可以测量的物用或理论上的性质。注:属性可以是内部的或外部的。381 GB/T 18905. 1-2002/ISO/IEC 14598-1: 1999 4.3 开发者developer 在软件生存周期过程中执行开发活动(包括需求分析、设计、测试直至验收)的组织EGB/T 8566-2001J 4.4 4. 5 4.6 4. 7 4.8 4.9 4. 10 4. 11 4. 12 4. 13 直接量测direcl measure 不依赖于任何其他属性度量的一种对属性的度量。评价模块evaluation module 针对特定软件质量特性或子特性的评价技术包。注:该评价技术包概括了评

9、价方法初技术、要评价的输入、要测量和收集的数据，以及支持规程和工具。外部测量exlernal measure 通过对系统行为的测量得出的对产品的种间接量测，其中产品是系统的部分。注1:系统包括任何相关的硬件、软件(定制的软件或现货软件和用户。注22在测试中发现的失效数量是对程序中的故障数量的外部度量，因为失效的数量是在计算机系统运行程序的过程中计算的。注3:外部测量可以用来评价更接近于最终设计目标的质量属性.外部质量extemal quaJity 产品在特定条件下使用时，满足明确或隐含要求的程度。失效failure 产品完成所需功能的能力的终止，或在原先规定的限制内没有能力完成。故障fault

10、 计算机程序中的不正确的步骤、过程或数据定义。注.该定义取自IEEE610. 12 -19900 隐含的要求implied needs 当实体用在特定条件下时，尚未说明但又是实际需要的要求。注隐含的要求是未形成文挡的真实要求。指标indicator 能用来估计或预计另一度量的一种度量。注1，预计的度量可以有相同或不同的软件质量特性。注2，指标可用来估计软件质量的属性和开发过程的属性，它们是对属性的不精确的间接测量。间接量测indirecl m姐姐阳从一个或一个以上的其他属性的测量得出的一种对属性的测量。注对计算机系统属性例如对用户输入的响应时间)的外部测量就是对软件属性的种J接测量.因这种测量

11、要受计算环境的属性和软件属性的影响软件中间产晶intermediale software product 382 4. 14 4. 15 4. 16 4. 17 4. 18 GB/T 18905. 1-2002/ISO/IEC 14598-1: 1999 软件开发过程中的产品，用作软件开发过程另阶段的输入。注.在某些情况下，中间产品也可以是最终产品。内部度量internaJ me田ure对产品本身的一种度量，或是直接的或是间接的。注代码行数、复杂度度量、在走查和Fog索引中发现的故障数都是对产品本身进行的内部度量2内部质量iulerual qualily 产品属性的总和，决定了产品在特定条件下

12、使用时，满足明确和隐含要求的能力。注1，在GB/T18905中.与术语外部质量丁f应的内部质量基本上与G!l/T6583 1994中质量的含义相同e注2:术语属性与4.21中术语特性的含义相同.而术语特性在ISO/IEC9 j 26中有更具体的含义。维护者maintainer 执行维护活动的组织。GB/T 8566-2001J 量测measure(四rbl执行一次测量。度量measure(noun) 通过执行一次测量赋予实体属性的数字或类别。4. 19 4.20 4.21 4 22 测量m崎sure皿ent使用一种度量.把标度值(可以是数字或类别)赋予实体的某个属性。注使用类别时.测量可以是定

13、性的。如软件产品的二些重要属性，例如源程序语言ADA，C，COBCL等就是定性的类别。度量(体制)melric 定义的测量方法和测量标度。注1:度量体制可以是内部的或外部的，可以是直接的或间接的。注L度量(体制包括把定性数据进行分类的直法。质量qualily 实体特性的总和，表示实体满足明确或隐含要求的能力。注1.在某种契约的环挽或在某个受控的环境中，如核安全领域，要求是明确规定的.而在真他环境中，宜确定和定义隐含的要求(GB/T65831994，注1)。注2.在GB/T18905中相关的实体是指软件产品。GB/T 6583-1994J 质量评价qualty evaluation 对实体能满足

14、特定需求的程度的系统检测。注:当按照合同为某个特定用户开发产品时，其需求是正式规定的s当产品是为非特定用户开发时，如消费软件，其需求自开友组织来规定;当用户为比较和选择的目的评价产品时，需求可以是更般的。383 GB!T 18905. 1-2002/ISO/IEC 14598-1: 1999 GB/T 6583 1991J 4.23 使用质量quality in use 特定用户使用产品满足其要求的程度，以达到在特定应用环境中的有效性、生产率和满意度等特定目标。4.24 4.25 4.26 4.27 4. 28 4. 29 4.30 4.31 4.32 注2这种使用质量的定义类似于150924

15、1-11中可用性的定义。在GB/T18905中术谓可用性用来指在150/1EC 9126中描述的软件质量特征。质量模型quality model 一组特性及特性之间的关系，它提供规定质量需求和评价质量的基础。评级rating 把测量值映射到相应的评定等级的活动，用于确定与软件某一质量特性相关的等级。评定等级rating level 在有序标尺上的某个刻度，用于分类某一测量的标度。注l评定等级能使软件按照明确或隐含的要求进行分类(评定)(见10.2)。注2:相应的评定等级与质量的不同角度在关，如用户、管理者或开发者的角度。标度scale 具有特性定义的组值。注:标度类型的例于有:与组类别对应的标

16、称标度、与一组有序刻度对应的序数标度、与组等距的有序刻度对应的间隔标度，以及既有等距刻度啕也具有绝对零度的比例标度。使用标称标度或序数标度的度量体制产生定性的数据，而使用间隔标度和比例标度的度量(体制)产生定量的数据6软件software 信息处理系统的部分或全部程序、规程、规则及相关的文挡。注z软件是独立于所记录媒体的智力创作。GB/T 527 1. 1-2000J 软件产品software product 一组计算机程序、规程以及时能有的相关文档和数据。注:产品包括中间产品和打算由丹发者和维护者等用户使用的产品。 GB/T 8566-2001J 供方supplier 同需方签订合同，并按合

17、同的规定提供系统、软件产品或软件服务的组织gGB/T 8566 - 2001J 系统system 由一个或多个过程、硬件、软件、设施和人员组成的集合体，提供满足明确要求或目标的能力。GB/T 8566-2001J 用户user 384 GB/T 18905 1-2002/ISO/IEC 14598 1:1999 4. 33 4.34 使用软件产品执行特定功能的个人。注:用户可以包括操作者、软件结果的接受者或软件的开发者或维护者。确认validation 通过检查和提供客观证据证实某一规定预期用途的特殊需求已经满足。注1在设计和开发中，确认关系到检查产品是否符合用户要求的过程;注2，确认一般是在

18、规定的操作条件下对最终产品进行的。在早期阶段，这样做是必要的，注3z确认过的一词用来表示相应的状况g注4，如果有几种不同的预期用途，可进行多种确认。GB!T 6583一1994J验证verficaton 通过检查和提供客观证据证实规定的需求已经满足。注1，在设计和开发中，验证是指对某项指定活动的结果进行检查的过程，以确定该活动是否符合明确的需求。注2:验证过的一词用来表示相应的状况。GB/T 6583-1994J 5 GB/T 18905及ISO/IEC9126的概述5. 1 GB/T 18905及ISO/IEC9126的结构ISO/IEC 9126标准定义了个通用的质量模型和质量特性，给出了

19、度量的例子。GB/T18905概述了软件产品评价的过程，提供了评价需求和指南。GB!T18905.2和GB/T18905.6与公司或部门级的评价管理和支持有关.GB/T18905.3、GR/T18905.4和GB/T18905. 5给出了项目级的评价需求和指南。图1和图2示出了这些标准和技术报告之间的关系。5.2 评价过程GB/T 18905给出了在3种不同情况下评价过程的需求和指南z 开发(增强)(GB/T 18905. :3); 获取(GB/T18905.4); 独立评价(包括第三方评价)(GB/T 18905.白。5. 2. 1 开发者用的过程计划开发新产品或增强现有的产品，以及打算利用

20、他们自己的技术人员进行产品评价的组织宜使用GB/T18905.30这部分主要强调使用那些能预测最终产品质量的指标，这些指标将通过度量在牛存期期间开发的中间产品来得到。5.2.2 需方用的过程计划获取或复用某个己有的软件产品或预先开发的软件产品的组织宜使用GB/T18905. 4。该部分可用来决定接受产品或者从众多可选产品中选择某个产品。(产品可以是自包含的，或是系统的一部分，或者是较大产品的一部分。)5. 2. 3 评价者用的过程对软件产品执行独立评估的评价者宜使用GB/T18905.50这种评价是应开发者、需方或其他方的请求来进行的。这部分将由那些执行独立评价的人员使用，他们通常为第二方组织

21、进行工作。5.3 对评价的支持上述每个评价过程的标准都能与GB/T18905. 2(策划和管理和GB/T1895. 6 (评价模块的文档编制)结合起来使用(图1)。385 GB/T 18905. 1-2002/ISO!IEC 14598-1: 1999 评价支持2.策划和管理6.评价模快的主档镰制评价过程3开发者用的过程4.需方用的过程5.评价者用的过程图1评价过程与评价支持标准的关系5. 3. 1 策划和管理GB/T 18905. 2 策划和管理部分包含对软件产品评价的支持功能的需求和指南。这种支持与策划和管理软件评价过程及相关的活动有关，包括组织内评价专业知识的开发、获取、标准化、控制、转

22、换和反馈e本部分可供管理者制定一个定量的评价计划。5.3.2 评价模块GB/T 18905. 6为编制评价模块的文档提供指南。这些模块包括质量模型的规范(llP特性、子特性和相应的内部或外部度量)、与模型计划的应用有关的数据和信息和与模型的实际应用有关的信息。每种评价均应选择适当的评价模块e对某些情况，还有必要开发新的评价模块。本部分可供组织用来产生新的评价模块。5.4 软件质量特性和度量GB/T 18905的各个部分宜与ISO/IEC9126中描述软件质量特性和度量的下列部分一起使用2 质量特性和予特性(IS0/IEC9126-1) , 外部度量(IS0!IEC9126-2) , 内部度量(

23、IS0/IEC9126-3)。ISO/IEC 9126-1定义了质量特性、相关的子特性以及ISO/IEC9126质量模型上面三层之间的关系。ISO/IEC9126-2和ISO!IEC9126-3确定f每种度量(外部和内部的)与其相应的特性和子特性之间的关系(见图2)。注意，某些内部度量有对应的外部度量。1.质量特性和于特性2外部度量忏-1 3内部度量图2ISO/IEC 9126软件质量特性和度量5.4.1 质量特性和子特性ISO/IEC 9126-1定义了一组质量特性和相应的子特性。当把软件作为计算机系统的一部分来使用时，这些子特性表现为外部子特性，并作为软件内部属性的一个结果。ISO/IEC

24、9126 J用作构造质量模型上面三层的基础。从用户的角度看，质量的总目标为使用质量。5.4.2 外部度量ISO/IEC 9126-2C在制定中)描述了使用软件时代表软件质量外部特征的那些度量。在使用软件时的某个预定义阶段采用外部度量，如类似时间和工作量等量化值用作这些度量的基础。这些度量应用于测试和运行阶段。当在测试阶段使用时，运行该软件，就意味着这些度量将成为所期望的质量等级的初始预测值。这些度量一般说来代表与用户相关的质量。5.4.3 内部度量ISO/IEC 9126-3(在制定中)描述了测量有关设计和代码等软件内部属性的那些度量。旦测试和运行软件系统，这些初期的度量就用作预测期望达到的指

25、标。因此，对开发管理者来说，内部度暨是最重要的，因为它是预先防范出现连带问题的有效方法。用内部度量来预测相应的外部度量值，ISO/ 386 GB!T 18905. 1-2002!ISO!IEC 14598-1 ,1999 IEC 9216-3显示了哪些内部度量有对应的外部度量。6 评价过程要评价软件的质量，首先要确立评价需求，然后规定、设计和执行评价(见图3)。每个步骤都在指定的章节中有更详细的描述。本部分给出了对整个过程的概述。GB!T18905的其他部分解释了如何在不同情况下应用该过程。确t评价需事规定评价设计评价执行评价7 确立评价需求7. 1 确立评价目的7. 1. 1 概述确立评价目

26、的(7.1) 确定产品类型(7.2)指定质量模型(7.3) 选择度量侣。建立度量评定等级(8.2)确立评估准则(8.3)制定评价计划(9.。进行度量(10.1) 与评估准则相比校(10.2)评估结果(10.3)一-9卧l质量特性| 9126 -2 外部度量- 9126-3 内部度量GB.厅18905.6评价穰块固3评价过程软件质量评价的目的是为了直接支持开发和获得能满足用户和消费者要求的软件。最终目标是保证产品能提供所要求的质量，即满足用户(包括操作者、软件结果的接受者，或软件的维护者)明确和隐含的要求。评价中间产品质量的目的是: 决定(是否)接受分包商交付的中间产品; 决定某个过程的完成，以

27、及何时把产品送交下)个过程 预计或估计最终产品的质量p 收集中间产品的信息以便控制和管理过程。评价最终产品质量的目的是2 决定(是否)接受产品: 决定何时发布产品s387 GB/T 18905, 1-2002!ISO/IEC 14598-1: 1999 与相互竞争的产品进行比较g 从众多可选的产品中选择-种产品p 使用产品时评估产品的积极和消极的影响; 诀定何时增强或替换该产品。评价软件的质量可以在一个已经定义的质量结构中进行，这种质量结构将涉及在GB/T8566中定义的产品开发和获取生存周期的全过程。7 , 1, 2 获取当获取某个客户制造的软件产品时，宜由需方确立外部质量需求，规定对供方的

28、需求，并在获得产品之前对照这些需求来评价潜在的购买。开发某个产品时，规定质量需求的目的是为了确保该产品符合用户的明确和隐含的要求(见GB/T18905，3)。购买某个软件产品时，可以通过评价来比较几种替代的产品，并确保所选的产品能满足质量需求(见GB!T18905.4:需方用的过程.GB/T18905.5:评价者用的过程，包括第五方的评价需求)。7 1. 3 供应供方可以利用软件产品的评价结果来保证产品满足所需的质量准则，这一准则由需方来确定，或通过与其他产品进行比较来确定。7. 1. 4 开发软件产品的需求表达了用户考虑的对软件产品的要求，这些要求在开发之前走义。当软件产品被分解成几个主要部

29、件时，对整个产品的需求相对于不同的部件可能是不同的，需要不同的评价准则。在评价质量之前，宜根据质量特性和子特性规定质量需求(见JSO/IEC9126-1)。在评价的是初阶段，宜研究和确定针对策划评价和实施评价的质量需求。开发者宜对每个相关的质量特性确立外部质量需求.宜评价这些质量需求规格说明的完整性和正确性，以确保所有必要的需求都已规定，所有不必要的需求都被排除。开发者需要在产品交付之前根据这些需求评价其产品。为了达到必须满足的明确和隐含的质量需求，重要的是要检查所有相关质量特性的隐含要求是否规定得非常详细。如果有可能，宜由中介方或购买方来评估需求，由最终用户来评估隐含的要求。用户对原型产品的

30、使用经验会有利于更准确地描述使用质量需求。宜由开发者来确定内部质量需求。使用内部质量需求时，开发者宜采用将内部质量需求与外部质量需求相对应的质量模型来确定这些内部质量需求，并在开发过程中使用内部需求来验证中间产品的质量。宜通过对开发过程中的中间产品规定内部质量需求的方式，使软件评价能用来预计和验证开发过程中的质量。而针对具体用途的完整产品的外部质量则可以根据最初的需求进行评价(见GB/T 18905. 3.开发者用的评价过程)。软件质量评价的结果可被用来获得使用不同的开发过程、不同的设计方法或不同的CASE工具，从而满足不同程度的质量需求的反馈。7, 1. 5运行运行软件系统的组织可以通过软件

31、质量的评价来确认在不同操作条件下满足质量需求的情况，并且对那些负责维护的人员提供对修改要求的反馈。7. 1. 6 维护维护软件系统的组织可以通过软件的评价来确认是否仍然满足质量需求，以及确认是否达到可维护性和叮移植性的需求。7.2 确定要评价产晶的类型要评价的中间或最终软件产品的类型取决于所处的生存周期的阶段和评价的目的(见图剧。388 GB/T 18905 1 2002/ISO/IEC 14598-1: 1999 稿革要求使用质量操作真实世界使用井反馈外部度量确定姐格说明革镜集成和测试 矗绕行为外部质量外部度量确定确认指示设t才和开发内部质量要求内部质量软件属性内部度量验证圈4软件生存周期中

32、的质量其目标是当用户实际使用该软件产品时，它能满足明确和隐含的要求。只能针对包含该软件产品的整个硬件或软件系统评估其外部质量。执行该软件时应用外部度量。由于外部度量值不只是依赖于软件，所以软件必须作为某个工作系统的一部分来评价。使用质量是针对特定用户(可以是最终用户、操作者或维护者的关于质量特性的综合效应。具有使用质量的软件必须能满足用户的要求，以便能在特殊的硬件和软件环境中执行特定的任务。在某种环境中能顺利执行任务的软件，在另一种环境中可能会出故障。因此对质量特性的外部评价宜在尽可能准确地模拟期望使用的那些条件下进行，即使不可能模拟真实的使用条件(如网络环境和用户特性), 也要在编码完成时对

33、特性进行外部度量，因为外部度量经常只作为实际使用质量的指标。如果未达到外部质量的需求，则评价结果可被用作修改软件特性的反馈，以便提高外部质量，从而支持个循环反复的改进过程。为进-步开发，要定义能使中间产品质量得到确认的内部质量需求。软件的内部特性(如规格说明或源代码)可利用内部度量来测量。在开发过程中，最有意义的是内部度量。内部度量能用作外部属性的指标。模块化和可追溯性是两个能被测量的内部属性的例子。达到所要求的内部质量会有助于满足应用软件的外部需求。因此，可以把对软件内部质量的度量用作评估使用质量的指标(见图5)。例如，响应时间是评价软件易用性和效率的一项重要的度量，但响应时间不能在开发期间

34、测量。为了在开发过程中评价产品效率，可根据中间产品或规格说明来测量路径的长度，该长度可用作在某种条件下粗略计算响应时间的一个指标。将软件的内部质量属性与外部质量需求相关联是十分重要的，使得开发中的软件产品(中间和最终的软件产品)的质量特性可以根据最终系统使用质量需求来进行评估。内部度量的值很低，除非有证据表明它与外部质量有关。389 GB/T 18905. 1-. 2002/ISO/IEC 14598-1: 1999 软件的外部度量实际使用的度量测量使用质量计算机矗统的外部性质号指示软件的内部度量l测量软件的内部性质图5度量之间的关系与最终质量有关的特定属性取决于所要求的使用条件。对于交互产品

35、，这将取决于实际最终用户和任务的需要。其他影响软件产品质量需求的方面包括2购买产品还是开发产品，产品的开发阶段，产品要用到的硬件、软件和网络环境等。对计算机系统的外部度量也可用作对软件内部质量的间接测量。因此，计算机系统的响应时间可被用来测量软件在特定计算环境中的效率。7.3 规定质量模型软件评价的第一步是选择相关的质量特性，使用个将软件质量分解成几种不同特性的质量模型。软件评价所用的质量模型通常代表软件质量属性的总体，这些质量属性用特性和子特性的分层树结构进行分类。该结构的最高级由质量特性构成，最低级由软件质量属性构成。ISO/IEC9216-1提供了一个通用模型，它定义了6种软件质量特性，

36、包括:功能性、可靠性、易用性、效率、可维护性和可移植性。这些特性还能进一步被分解为具布可测量属性的子特性。在特定的使用环境f.质量特性的组合效应被定义为使用质量。软件产品的内部质量属性是软件产品的可测量性质，这些性质影响产品的满足明确和隐含要求的能力。可以用一个或更多的属性来评估一个特定的软件质量特性或子特性(见图们。X X 性J性属、甜、X X , 内部属性特性外部属性圈6质量特性、子特性和属性宜对每个要求的子特性确定其足够的内部属性和外部属性。与任何特殊情况有关的实际特性和子特性将取决于评价的目的，宜通过对质量需求的研究来确定。ISO/IEC 9216-1中的特性和子特性提供了-个有用的、

37、关于质量的问题检查表，但是质量分类的其他方法可能更适用于某些特定的环境。注:个例于是IEC60050(191).它把可信性定义为用户时以合理地依靠系统所提供服务的依赖程度。这种程度又分为可靠性、可用性相可维护性等特性6还可以包括易用性、可恢复性、安全性、可扩展性和保密性.390 GB/T 18905. 1一2002/ISO/IEC14598-1: 1999 8 规定评价8. 1 选择度量重要的是软件产品的测量要能既简单又经济地进行，而且测量结果要易于使用口对许多软件的测量可以方便地用某种工具来进行，也可以打包成一个评价模块(GB!T18905.们。质量特性的定义方式不允许对它们进行直接测量。需

38、要建立与软件产品特性相关的度量。与某个质量特性相关的每个可量化的软件内部属性和每个可量化的软件外部属性与其软件环境进行相互作用能被确立为-种度量。度量可以随环境和应用度量的开发过程阶段的不同而有所区别。用在开发过程的度量宜与用户观点的度量有关，因为从用户视角出发的度量是至关重要的。注度量的例于以及如何为每个子特性选择和概括度量的解释说明见ISO/IEC912日的第2和第2部分(在制定中)。8. 1. 1 测量的种类评价有两个主要目的: 确定问题以便解决问题; 与可替换的产品进行比较，或对照需求比较产品质量(可以包括认证人所需的测量种类取决于评价的目的。如果主要目的是为了了解和纠E缺陷.叫以对软

39、件采取多种测量，以便监视和控制改进。为此而进行广泛的测量是有用的，比如检查表和专家意见等。主要需求是正确地测量以确定软件的任何改变对质量的影响。需要更严格的度量以便进行可以信赖的比较，这种比较可以在产品间进行，也吁以与标准值进行比较。测量规程宜测量软件质量的特性(或子特性)，规程要求用有效精度进行测量，以便允许设定准则并进行比较。评价规格说明为每种度量规定个精确的质量模型、测量方法、测量标度和评定等级是很重要的。当用不同的属性进行产品比较时，出自检查表和专家意见的数据可能不太可靠。应允许存在由测量工具或人工差错可能引起的测量误差。8. 1. 2 测量的隔求内部度量宜具有可预见的有效性，即它们宜

40、与一些需求的外部准则有关。例如，某个特定软件属性的内部度量宜与软件使用时质量的某些可测量方面有关。重要的是这些测量应分配与常规期望(fl自)一致的数值2例如，如果测量建议产品是高品质的，那么这一测量宜与满足特定用户要求的产品-致。有关测量需求的更多信息可参见ISO/IEC9126-1。8.2 确立度量评定等级可量化的特征可以用度量质量的方法进行定量的测量。其结果是，将测量值映射到某一标度上。这个值本身并不表示满意的等级，因此，这一标度必须根据需求的不同满意度级别分成不同的范围。例如: 将标度分成两类z满意和不满意; 将标度分成四类:llP针对已有产品或可替换产品的当前级、最差级和计划级。定义当

41、前级是为控制新系统不因当前状况而恶化。计划级是指一旦资源可利用，产品即可获得。最差级是指万-产品不符合计划级时用户的可接受边界(图门。8. 3 确立评估准则软件质量需求规格说明应使用定义良好的适当的质量模型来表示。为此.宜使用ISO/IEC9126-1 中的质量模型和定义，除非有特殊原因需使用其他模型。为了评估产品质量，需要总结针对不同特性的评价结果。评价者宜为此准备一个规程，其中对不同的质量特性使用不同的评价准则，每个质量特性又以数个子特性或子特性的加仪纯合来说明巳规程通常还包括如时间和成本等有助于在特定环境下评估软件产品质量的其他方面。391 GB/T 18905. 12002/ISO/I

42、EC 14598-1: 1999 超出要求计划级目标班回满意当前提可接受的最低限度, 最差情况不可接受不精童测量标度评定等组图7度量的等级9 设计评价9. 1 制定评价计划j评价计划描述了评价方法和评价者活动的进度表(见GB/T18905. 3、GB!T18905.4或GB/T 18905. 5)。评价计划宜与测量计划(GB/T18905.2)相一致。10 执行评价10. 1 实施测量为进行测量，应对软件产品使用所选择的度量。其结果为度量标尺上的值。10.2 与准则相比较在评级步骤中，测量的值要与预定的准则(如图7所示进行比较。10.3 评估结果评估是软件评价过程的最后一步，将对一组己评定的等

43、级进可概括。其结果是对软件产品满足质量需求程度的一个综述。然后将总结的质量与时间和成本等其他方面进行比较。最后，根据管理准则做出一个管理决策。结果是决策层做出的接受或拒绝、发布或不发布该软件产品的决定。评价结果对软件开发生存周期的下一步决定十分重要。例如，需求是否须改动?或开发过程是否需要更多的资源?11 支持过程支持评价的活动包括2收集有关评价工具和方法的信息、开发和确认度量、标准化评价过程、度量和测量。GB/T18905.2包含了软件产品评价的支持过程的需求和指南等。392 GB/T 18905. 1-2002/ISO/IEC 14598-1: 1999 参考文献国际标准IJ 2J 3J

44、4J IEC 60050-191 :1 990 国际电子技术词汇IEEE 610. 12-1990 软件工程术语标准服务的依赖性和质量ISO/IEC 9126-2 ISO!IEC 9126-3 软件工程产品质量第2部分2外部度量软件工程产品质量第3部分z内部度量5J ISO 9241-11:1998 其他参考书目办公用视觉显示终端(VDTs)的人类工效学要求第11部分:可用性指南6J Arthur, J. D. and Nance, R. E. , Developing an automated procedure for evaluating software de-velopment me

45、thodologies and associated products-A final report, Technical report SRC-87-007 , Systems Research Center and Virginia Tech, 1987. 7J Azuma，M(Edito吵，SoftwareQuality Evaluation Guide Book(Japanese) ,JISA , 1994. 8J Azuma , M. Software Products Evaluation System: Quality Models. Met口csand Processes-In

46、ter national Standards and Japanese Practice.lnformation and Software Technology. Vo1. No. , 1996 , Elsevier. 9J Basili.V. R. and Rombach , H. D. , The TAME Project:Towards improvement oriented softwarc environments ,IEEE Trans. Software engineering,June 1998. 10J Bevan N Measuring usability as qual

47、ity in use. 10urnal of Software Quali飞y，4，p.115-30，1995.11J Bevan N and Azuma M0997l Quality in use: Incorporating human factors into the software en gineering lifecycle. In: Proceedings of the Third IEEE international Software Engineering Standards Sympo目umand Forum(lSESS97) ,p. 169-179. 12J Boehm,

48、B. w. , et al. ,Quantitative evaluation of software quali巧，Proc.ICSE 1976. 13J Bush, M and Russel , M. .Software Engineering Measurement:A Modular Course ,Proc. COMP SAC91 P571-576. 14J Dumke , R. Softwareentwicklung nach Masz(German) , Vieweg. 1992. 15J Fenton NE and P f1eeger SL, Software Metrics:

49、A Rigorous and Practical Approach.lnternation a Thomson Computer Press. 1996. 16 J McCabe. T. j. A Software Compexity Measure.IEEE Transaction on Software Engineering, Vol. 2 , No. 6.1976. 17J McCall et a1. ,Rome Air Develop Center Report. TR-77 369 , 1977. 18J Moller, K. H. and Paulish ,D. J. Software Metrics. Chapman &. HallOEEE Press). 1993. 19 Miyoshi , Togashi an