1、ICS 35.080 L 77 人民、和国国标GBjT 18905. 3-2002jISOjIEC 14598-3 :2000 软件工程产品评价第3部分:开发者用的过程Software engineering-Product evaluation一Part 3: Process for developers CISO/IEC 14598-3: 2000 , IDT) 2002-12-04发布2003-05-01实施406 中华国家质人民共和国监督检验检疫总局发布GB/T 18905, 3一-2002/ISO/IEC14598-3 :2000 -= E司GB/T 18905-2002(软件工程产
2、品评价分为六个部分=第1部分:概述;第2部分2策划和管理;-一一第1部分2开发者用的过程g第4部分z需方用的过程;第5部分z评价者用的过程;-一第6部分=评价模块的文档编制。木部分为GRjT18905-2002的第3部分，等同采用ISO/IEC14598-3: 2000(软件工程产品评价第3部分:开发者用的过程以英文版。本部分的附录A是资料性附录。本部分由中华人民共和国信息产业部提出。本部分由中国电子技术标准化研究所归口。本部分由中国电子技术标准化研究所负责起草。本部分主要起草人z罗锋盈、陈莹、王凌、冯惠。407 GB/T 18905. 3-2002/ISO/IEC 14598-3: 2000
3、 召l自本部分旨在供软件开发期间使用。它适用于所有需要严格要求过程的软件开发活动。本部分特别有助于测量和评价软件质量。本部分提供了指南，包括阐明质量需求，实施并分析软件质量测量。它适用于所有软件和开发生存周期的所有阶段。其重点在于选择并报告-组指标，这些指标对于通过测量中间产品的质量来预言最终产品质量是有用的回它的重点还在于测量最终产品质量。408 GB/T 18905. 3-2002/ISO/IEC 14598-3:2000 1 范围软件工程产品评价第3部分z开发者用的过程当评价与开发同步进行并由开发者实施时，本部分提供了对软件产品评价的惯例实现的需求和建议。特别是，使用本部分时还可采用IS
4、O/IEC9126的第1、第2和第3部分，以及GB/T18905. 1、GB/T 18905. 2和GB/T18905. 6中描述的概念。本部分描述的过程定义了分析评价的需求，规定、设计和执行评价的行动，以及为任何软件产品的评价作结论所需要的各种活动。这里设计的评价过程旨在与开发同时使用。评价过程须与软件开发过程同步进行，实体在交付时须予以评价。本部分可供下列人员使用z项目管理者，用于阐明质量需求，在开发期间监督和控制软件质量，以及为确保需要的质量成为软件的内在组成部分做出决定;软件设计者，用来标识应内置于软件的具体特征或为满足质量需求而变更的具体特征3.质量保证、控制、审核负责人，用于评价是
5、否满足质量需求;维护者，为变更的实现和重(再)设计做出决定z软件的需方。当不需要独立评价时，需方是获取软件时(如外购软件开发产品的情况与开发者达成的协议的一部分。需方可以是采购人员、外购部分软件产品的开发者或是最终用户。需方的作用取决于与开发者所签的协议。GB!T18905.4描述了按需方的角度的评价.本部分旨在项目级的应用。为了从本部分全面获益，组织应当介入GB!T 18905. 2包括了这方面的内容。本部分既未规定具体的指标或计量，也未规定任何特殊的开发方法。2 -敖性为符合本部分，组织应评审第6章的所有需求和建议，以识别哪些是适用的，并声明哪些需求尚未实现。3 规范性引用文件下列文件中的
6、条款通过本部分的引用而成为本部分的条款。凡是注日期的引用文件，其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。GB!T 85662001信息技术软件生存周期过程。dtISO/IEC 12207: 1995) GB/T 18905. 2002软件王程产品评价第1部分z概述(lSO/IEC14598-1: 1999 , IDT) GB/T 18905. 22002软件工程产品评价第2部分z策划和管理ISO/IEC14598-2: 2000 , IDT) GB/T 18
7、905. 62002软件工程产品评价第6部分z评价模块的文档编制ISO/IEC14598 6:2001.IDT) ISO/IEC 9126- 软件工程产品质量第1部分z质量模型409 GB/T 18905. 3-2002/ISO/IEC 14598-3:2000 4 术语和定义GB/T 18905. 1中已给出的定义，以及下列定义适用于本部分。4. 1 计量原1II1Jcounting rule 获取测量值所依据的条件和规程。4.2 外部属性extemal aUrlbute 实体的可测量的性质，它仅可由实体与环境的关系导出。注2外部属性指与需求相关(软件的外部特性)，仅可由所属系统的操作行为导
8、出。4. 3 4. 4 内部属性intemal aUribute 实体的可测量的特性，它可能纯粹由实体本身导出.注2内部属性与软件及某开发的内部组织相关.单位unit 作为测量标准而采用的一个量。注2每个单位都有一个相关联的标度。5 评价慨念5. 1 总则软件产品的质量可根据质量特性加以描述。注2在lSO/IEC9126-1中定义了一组质量特性.一般地，对这些特性直接赋予测量值并不实际，而是对软件产品选择一组质量属性来代表特性的主要方面是比较可行的。这些属性的测量值给出了软件产品质量的定量表示。本部分的重点在支持开发者在开发生存周期期间实施软件测量和评估。这要通过识别中间产品和开发活动的属性以
9、及通过测量这些属性来实现。本部分提供了在开发过程期间定量监控开发中的软件产品质量的方法。其目的是识别出问题，尽可能早地达到开发过程中所期望的质量。当前对软件测量和软件评价的认识水平不能证明所推荐的一组单独的属性，可以应用于每种软件产品和每个软件开发组织。因此，软件产品的属性、中间产品的属性以及开发活动的选择是以组织的软件开发经验为基础的。5.2 用户需要用户需要的标识是建立总的质量需求的A个重要方面。这要通过标识用户对特殊使用环境中使用质量的需求来实现。这些总的需求本质上是非正式的，需要正式化。通过对使用质量进行度量来加以量化和评价。注24组使用度量的质量在ISO/IEC9126-4中描述本部
10、分采用的方法是按外部属性公式化总的(质量)需求。5. 3 外部属性外部质量属性代表了软件产品的质量特性，用于定量地表示外部质量需求。这些需求通过对每个属性分配目标测量值来实现。开发软件产品时，收集属性的实际测量值，从而为软件质量特性提供定量的表示。通过将实际测量值和所有属性的目标值进行比较来实现质量评价。注:组软件质量外部度量在ISO/IEC9126-2中提供囚410 GB(T 18905. 3-2002(ISO(IEC 14598-3: 2000 5.4 内部属性为了在开发期间监控软件质量，把外部质量需求转化成对中间产品和开发活动的需求这要通过把软件产品的外部属性的目标测量值转化为对中间产品
11、和开发活动的内部属性的目标测量值来实现。选择内部属性和把外部目标值转化为内部目标值是一项重要的活动。它主要依靠个人经验，除非开发者提供收集和分析以前已完成项目经验的基础设施。此时，靠开发者的个人经验能支持这一活动。注1，组织方面在GB/T18905.2中描述。在开发期间测量内部属性的实际值将该值同目标值进行比较。它提供了开发期间对软件质量的控制。内部属性可用于识别异常值或离群值(即偏离于正常情况下所期望的属性值)。一般经验证明，需要对这些实体进行更密切的审查。当定期(例如每周测量内部属性时，一些内部属性可用于监督开发的进展。进展的测量能较早识别问题，包括产品和开发过程的问题。注2，1段)/IE
12、C9126-3提供了一组内部度量.5. 5 质量指标内部质量属性可用作质量指标。特别是，内部属性经常用作外部属性的指标;但是尚未确认质量指标和外部质量属性问-般的直接关系。然而，普遍认为质量指标提供了谨慎使用时有用的使用指南。质量指标的使用使软件开发者在开发中及早识别可能存在的质量问题并立即采取纠正措施。不存在适合于一切软件开发工作的通用质量指标集。实际应用、开发方法和工具以及项目组织都存在差异，还存在一些文化差异。因此，对某个组织有用的指标在另一个组织中不一定有用。5. 6 评价过程本部分描述的评价过程由开发者执行的一组活动组成。这些活动在开发过程期间获得的测量值的基础上执行。注1，一般评价
13、过程在GB/T18905. t中描述。注2，评价的组织方面在GB/T18905. 2中描述。评价过程由下列五个活动组成z一确立评价需求:根据一个已商定的质量模型，由识别总的质量需求组成。该活动的描述见6.2: 一规定评价的规格说明E由确定外部度量和目标测量值(评价准则组成。该活动的描述见6. 3. 1。规格说明还包括确定内部度量和目标测量值(评价准则。该活动的描述见6.3. 2; 一一设计评价2由策划的数据收集行动组成。该活动的描述见6.4. 1和6.4. 2; 执行评价:由开发期间收集内部测量值并将它们同目标值(开发期间的评价)进行比较组成。内部属性值(质量指标)用于估计最终产品质量。这在6
14、.5. 1中描述。当存在外部测量值时，该活动也包括收集外部测量值，当它们变为可用时，将它们同目标值(产品质量的评价)进行比较。该活动的描述见6.5. 20 对组织的反馈:基于对评价结果的评审。该活动的描述见6.6。5. 7 评价与生存周期过程间的关系软件产品的评价可在任何生存周期过程中进行。注1软件生存周期过程在GB/T8566-2001中寇义.本部分主要涉及开发过程。注2z开发过程在GB/T8566-2001的5.3中规定.如GB/T8566-2001所述.它也喻示着有必要考虑维护过程(5. 5)支持生存周期过程(的和组织的生存周期过程(7)。当本部分用于外购软件的开发时，如GB/T 856
15、6-2001的s.1和5.2所述，它也涉及获取过程和供应过程。6 评价过程幡求6. 1 总需求411 GB/T 18905. 3-2002/ISO/IEC 14598-3: 2000 本章涉及组织的和项目特定的需求。6. 1. 1 组织需求开发者应建立基础结构，从而允许在数据分析墓础上进行数据收集和过程修改。注t评价的组织方困在GBIT18905.2中描述a6. 1. 2 项目糟求开发者应遵循严格规定的开发过程开发软件，允许计划并实施软件测量和评价。注1，生存周期过程在GB/T8566-2001中描述，其中开发在5.3中描述。注2软件产品评价综述见GB/T18905. 1。开发者应协调评价活动
16、与支持过程及活动。注3t支持过程在GBIT8566-2001中描述，特别包括质量保证过程(6.3)、验证过程刊，的、确认过程(6.5)和审核过程(6.7)。许多数据分析方法需要先前在类似条件和可比质量需求下开发的项目中的数据。因此，开发者应采用开发者的组织在以前的项目中已使用的类似的开发模型。在项目中还应使用同样的属性集，以便进行数据分析。6.2 确立评价需求本条涉及总质量需求的建立及其可行性的分析。6. 2. 1 质量需求的标识开发者应确保确定了应用于软件系统的一般质量需求。当标识一般需求时，宜考虑用户的需要、组织的经验、应用领域的经验、软件的完整性需求、所要求的标准、法规和法律等。注1软件
17、的完整性级别在GB/T18492. .2001中描述自开发者应确保已商定的质量模型用于结构化质量需求。注2.质量模型在IS/1EC9126-1中描述。应列出一些可能影响质量需求可行性的其他系统需求(清单)。还宜考虑需方的问题.如成本和迸度约束、许可证和组织方面的问题。还宜考虑解决排他性的需求。注3:重点宜放在产品的外部属性。创建和使用软件系统的各方宜参与或派代表参加到确定质量需求的过程中。宜与参与的各方讨论需求的相对优先级。每个小组根据其他系统需求和约束来权衡质量需求。宜考虑各方面的观点。识别的质量需求可能是互相矛盾的电也可能是相互配合的。应解决需求间的矛盾。另外，如果质量需求的选择与成本、进
18、度或系统功能性冲突，则应变更其中的几项。开发者应进行质量需求的可行性分析。应考虑开发者组织在以前执行的具有类似的质量需求的项目的经验。开发者应确保需求在技术上是可行的、合理的、互补的、可达到的和可验证的。按商定的质量模型，质量需求应分解为单一组质量需求。列出最终总需求的协议宜征求所有各方的意见。6 3 评价的规格说明本条涉及质量需求的量化。对每个需求，选择一个或多个外部属性来代表。赋予的目标值作为需求的量化表示(评价准则)。对每个外部需求，选择一个或多个内部属性代表开发期间的需求。对内部属性赋予的目标值用来控制开发期间的质量。6. 3. 1 外部质量需求开发者应定义在哪些生存周期过程和活动中将
19、实现测量和评价。注1外部属性的测量和评价通常在完成开发之后进行.412 GB/T 18905 3-2002/ISO/IEC 14598-3: 2000 开发者应定义测量和评价哪些实体。注2z这路实体通常是最终产品的部分(例如运行系统或用户于册)。开发者应定义测量哪些外部属性。开发者应标识每个质量需求所用的度量(根据定义的外部属性和实体)。开发者应定义对每个度量的目标值。注3，目标值给出了质量需求的定量表示a注4，目标值用做评价准则。开发者应运义执行测量的条件。也即标识其属性值能影响测量的其他属性.并定义这些属性的值。开发者应对质量需求执行细化的可行性分析。宜考虑开发组织在以前执行的具有类似质量
20、需求的项目中的经验。开发者应确保需求在技术上是可行的、合理的、豆补的、可达到的和可验证的。外部属性值可能依赖于其他属性值。应具体规定这些条件，以使测量值有意义。注5例如，系统的响应时间取决于硬件、操作系统、系统中运行的其他程序、用户概况等。6.3.2 内部质量需求开发者应定义在哪些生存周期和活动中将实现内部属性的测量和评价。注1，内部属性的测量和评价通常在开发过程期间进行开发者应定义测量和评价哪些实体。注25己选择的实体通常是中间产品和活动。开发者w定义测量哪些内部属性。注32不同的中间产品可需要不同的属性。开发者应为属性和实体的每种组合识别度量。开发者应定义的内部属性集，使其=一覆盖每个相应
21、的中间产品和活动g一适合于应用领域和开发中所用的方法;一一覆盖己识别的产品和开发风险。注4，开发风险的例子包括规格说明不能稳定、识别的问题未着于解决、进度滞后于进度表等。宜纳入适当的趋势度量。注5当定期采用趋势度量时.有些度量时于确定软件开发过程的趋势是有用的。这种趋势度量的例子有己完成的模块数f已解决的问题数、己更改的需求数等。开发者应定义二组与所有外部属性(即所1质量需求)有关的内部属性。这些属性用作质量指标。注62宜分析有关中间产品井收集内部测量数据，其目的如下:评价中间产品的质量，以发现质量需求满足(或不满足)情况的指示p得到最终产品质量的指示(预测。注7，1旦)/IEC9126.3可
22、用作选择指标的指南。对于已定义的质量指标，即指标和外部质量属性间的关系，开发者应描述预测模型。注8指标不需要与试图要测量的质量属性形成严格的对一关系。但是宜明确定义指标和自关的质量属性之间的联系。为有效地管理使用，指标数目不宜过多。宜把优先级给予那且可由在现有过程(如配置管理过程或集成测试过程)期间已收集的数据支持的指标。适当时，开发者应对内部属性设定目标值。开发者应定义要执行的测量条件，即标识其属性值能影响测量的其他属性并定义这些属性的值。注9，依据定义，内部属性值的测量可姐立于其他属性6. 4 评价的设计413 G/T 18905. 3-2002/ISO/IEC 14598-3: 2000
23、 本条涉及评价的设计。外部评价关系到外部质量需求，内部评价关系到开发期间的内部质量监控。注对定量评价计划的引用见GB/T18905. 20 6.4.1 策划外部评价为获得每个外部度量的实际值，开发者应规定要执行的数据收集措施(规程)。包括时间进度表、职责以及运用的数据收集和分析工具的规格说明。如需对人员进行特殊培训，也宜列入计划。开发者应定义测量精确度。所采用的所有统计模型都应予规定，包括输入数据需求、抽样策略等。注2如果开发者的组织已寇义了一组评价模块，则该活动也包括选择评价模块。评价模块的文档编制在GB/T 18905. 6中描述。6.4.2 策划内部评价为获得每个内部度量的实际值，开发者
24、应规定要执行的数据收集措施(规程)。包括时间迸度表、职责以及运用的数据收集和分析工具的规格说明。如需对人员进行特殊培训，也宜列入讨划。开发者应定义测量精确度。所采用的所有统计模型都应予规定，包括数据需求、抽样策略等。开发者应规定应急措施，直口额外评价，以防测量结果不能做出结论或是警告性的。开发者应考虑对软件开发活动的各种影响e测量集通过数据采集需求可隐含在开发过程中的更改。注1，为实施测量有时必须对硬件或软件工具进行定位、评价、获取、适配或者开发。测量集可能隐含了用来产生软件系统的组织性结构的更改。质量保证与控制组织或整个开发小组可能需要接受有关应用测量与数据收集规程方面的培训。如果在开发过程
25、中测量的实施引起了更改，因l开发小组可能需要接受有关更改方面的教育。注2.，如果开发者组织己定义了一组评价模块，则该活动也包括选择评价模块。评价模块的文档编制在GBjT 18905. 6中描述。6.5 评价的执行本条涉及按计划收集质量数据并与目标值(评价准则)进行比较。6. 5. 1 内部评价质量的监督和控制在开发期间进行。收集内部属性的实际值曰对非期望值分析原因，使开发者能了解问题并解决问题。开发者应根据已定义的数据收集措施，为己定义的内部属性收集实际测量值。如果质量需求有变化，则开发者应重新考虑评价规格说明(6.3)和评价设计(6.4)。开发者应采取必要的措施以保证收集数据的质量。适当时，
26、这些措施宜包括确认数据收集用的自动工具，并通过于工步骤检查数据。当指定目标值时，开发者应将它们与实际值加以比较。开发者宜使用已定义指标的实际值来估计最终产品质量。宜考虑开发组织在先前具有类似质量需求的项目中的经验。注:质量预测依赖于已确认的指标。开发组织首先要为几个项目收集指标值和产品测量值，以得到，组确认的指标。为识别开发风险，开发者宜使用实际值以监控发展趋势。开发者应分析实际值以识别离群值。离群值通常表示出了问题或非正常情况E宜始终寻求对离群值的解释。有时对离群值有合理的解释。在此情况下，就不必采取纠正措施。必要时应采取应急措施。6.5.2 最终产品的评价软件产品的质量评价在完成开发时进行
27、。要收集外部属性的实际值。注1，如有可能，软件构件可在卅发完成前进行测量。开发者应根据定义的数据收集措施，为已定义的外部属性收集实际测量值。如质量需求有更改，开414 GB/T 18905. 3-2002/ISO/IEC 14598-3 ,2000 发者应重新考虑评价规格说明(6.3)和评价设计(6.4)。开发者应采取必要的措施以保证收集数据的质量。适当时，这些措施宜包括确认数据收集用的自动工具，并通过手工步骤检查数据。开发者应将实际值和目标值(评价准则)加以比较。注2在本部分中描述的评价过程由开发者实施。GB/T18905. 5描述了个独立的评价过程。开发者应对评价结果做出评估。为支持有关开
28、发结果(例如，改进产品、评审需求等)所作的决策，宜对实际值做汇总，并与其他值(如时间和成本)进行比较。开发者宜将评价结果编成文挡。6.6 质量评价的评审和对组织的反馈开发者应收集对组织有用的数据，以便在其他开发项目中使用。开发者应评审评价结果和对所采用的评价过程、指标和度量的确认。宜使用评审反馈，以改进评价过程和评价模块。当必须改进评价模块时，宜纳入对额外指标的数据收集，以便在以后的使用中加以验证。注2质量评价评审和反馈在GB/T18905.2中描述。415 GB/T 18905. 3-2002/ISO/IEC 14598-3: 2000 A. 1 A.2 A.3 A.4 A.5 A.6 A.
29、7 A.8 A.9 附录A(资料性附录)选自其他标准中的定义除另行注明者外.下列定义均选自GBiT18905. 1。需方acquirer 从供方获得或获取系统、软件产品或软件服务的组织。因BiT8566-2001J 属性aUribule 实体的可测量的物理或抽象的性质。注2属性可以是内部的或外部的a开发者developer 在软件生存周期过程中执行开发活动包括需求分析、设计B测试直至验收)的组织。GB/T 8566-200J 直接量测direct measure 不依赖于任何其他属性度量的一种对属性的度量。评价模块evaluation module 针对特定软件质量特性或子特性的评价技术包。注
30、-该评价技术包概括了评价方法和技术、要评价的输入、耍测量和收集的数据，以及支持规程和工具外部度量external measure 通过对系统行为的度量得出的对产品的一种间接量测，其中产品是系统的部分U注lt系统包括任何相关的锺件、软件定制的软件或现货软件)利用户。注2.在测试中发现的故障数量是对程序中的故障数量的外部度量，因为故障的数量是在计算机系统运行程序的过程中计算的。注32外部度量可以用来评价更接近于最终设计目标的质量属性G外部质量external quality 产品在特定条件下使用时，满足明确或隐含要求的程度。失效failure 产品完成所需功能的能力的终止，或在原先规定的限制内没有
31、能力完成。故障fault 计算机程序中的不正确的步骤、过程或数据定义。注:该定义取自IEEE610. 12-1990, 416 GB/T 18905. 3-2002/ISO/IEC 14598-3: 2000 A. 10 隐含的要求implied needs 当实体用于特定条件下时，尚未说明但又是实际需要的要求。注2隐含的要求是未形成文档的真实要求。A. 11 指标indicator 能用来估计或预计另一度量的-种度量。注1，预讨的度量可以有相同或不同的软件质量特性。注2，指标可用来估计数件质量的属性和开发过程的属性，它们是对属性的不精确的间接量测。A. 12 间接测量indirect mea
32、snre 从一个或4个以上的其他属性的度量得出的一种对属性的度量。注:对计算机系统属性(例如对用户输入的响应时间)的外部度量就是对软件属性的种间接量测，因这种量测要受计算环境的属性和软件属性的影响。A. 13 软件中闰产品intermediate software prodnct 软件开发过程中的产品，用作对软件开发过程另一阶段的输入。注:在某些情况下中间产品也可以是最终产品。A. 14 内部度量internal measure 对产品本身的一种度量，或是直接的或是间接的。注.代码行数、复杂度度量、在走查和Fog索引中发现的故障数都是对产品本身进行的内部度量。A. 15 同相义吉的义宣府咱阴阳
33、Th中具寸/4窑，、能川割的中比W内向dpo甘习82要仍旧含厅宽隐Bm和LVm明山二UUM44 足基唯满量咱们仁质语E部术用内而dbp刀斗川剧同类问应相或向对义字条V吉数定量的的特部性性比呐咐属可语语体i产术术了与中)刊明定hmuLbElEter衍箩Ui-r哑阳tMJHl幽缸mmM量四时和mm一剧的吼叫BJh测mM总川性-E动U量配次mw的初咀刷刷活阳跚测幽一跚量性G语护8m次回行m质属在术者维4执部口阳LU乙护行且一测行量过量内产注注6维执K7量执8度通9测AAAA 使用-种度量，把标度值(可以是数字或类别)赋予实体的某个属性。注2使用类别时，测量可以是定性的。如软件产品的一些重要属性.例如
34、源程序语言(ADA , C, COBOL等)就是定性的类剔。417 GB/T 18905. 3-2002/ISO/IEC 14598-3 ,2000 A.20 度量(体制)metric 定义的测量方法和测量标度。注1，度量(体制可以是内部的或外部的，可以是直接的或间接的曰注2度量(体制)包括把定性数据进行分类的方法回A.21 质量quality 实体特性的总和，表示实体满足明确或隐含要求的能力。注1，在某种契约的环境或在某个受控的环境中，如核安全领域，要求是明确规定的，而在其他环境中，宜确定和定义隐含的要求(GB/T6583 -1994，注口。注22在GB/T18905中相关的实体是指软件产品
35、回GB/T 6583-1994J A.22 质量评价quality evaluation 对实体能满足特定需求的程度的系统检测。注z当按照合同为某个特定用户开发产品时，其需求是正式规定的;当产品是为非特定用户开发时，如消费软件.其需求由开发组织来规定g当用户为比较和选择的目的评价产品时，需求可以是更一般的。GB/T 6583一1994JA.23 使用质量quality in use 特定用户使用产品满足其需求的程度，以达到在特定应用环境中的有效性、生产率和满意度等特定目标。注:这种使用质量的定义类似于ISO9241-11中可用性的定义.在GB/T18905中术语可用性用来指在ISO/IEC 9
36、126-1中描述的软件质量特征。A.24 质量模型quality m创el一组特性及特性之间的关系，它提供规定质量需求和评价质量的基础。A.25 评级rating 把测量值映射到相应的评定等级的活动，用于确定与软件某一质量特性相关的等级。A.26 评定等级rating level 在有序标尺上的某个刻度，用于分类某一测量的标度。注1，评定等级能使软件按照明确或隐含的要求进行分类(评定)(见10.2), 注2相应的评定等级与质量的不同角度有关，如用户f管理者或开发者的角度。A.27 标度scale 具有特性定义的一组值。注:标度类型的例于有z与一组类别对应的标称标度、与一组有序刻度对应的序数标度
37、、与组等距的有序刻度对应的间隔标度，以及既有等距刻度，也具有绝对零度的比例标度.使用标称标度或序数标度的度量(体制)产生定性的数据，丽使用间隔标度相比例标度的度量(体制产生定量的数据。A.28 软件software 信息处理系统的部分或全部程序、规程、规则及相关的文档。418 GB/T 18905. 3-2002/ISO/IEC 14598号:2000注:软件是独立于所记录媒体的智力创作。GB/T 527 1. 1-2000J A.29 软件产晶software product 一组计算机程序、规程以及可能有的相关文档和数据。注:产品包括中间产品和打算由开发者和维护者等用户使用的产品回GB/T
38、 8566-2001J A.30 供方supplier A.31 同需方签订合同，并按合同的规定提供系统、软件产品或软件服务的组织。GB/T 8566- 2001J 系统system 由一个或多个过程、硬件、软件、设施和人员组成的集合体，提供满足明确要求或目标的能力。GB/T 8566-2001J A.32 用户user 使用软件产品执行特定功能的个人。注s用户可以包括操作者、软件结果的接受者或软件的开发者或维护者。A.33 确认validation 通过检查和提供客观证据证实某一规定预期用途的特殊需求已经满足。注l在设计和开发中，确认关系到检查产品是否符合用户要求的过程$注2，确认一般是在规
39、定的操作条件下对最终产品进行的。在早期阶段，这样做是必要的:注3确认过的一词用来表示相应的状况;注4，如果有几种不同的预期用途，可进行多种确认。GB/T 6583-1994J A.34 验证verification 通过检查和提供客观证据证实规定的需求已经满足。注1，在设计和开发中，嘘证是指对某项指定活动的结果进行检沓的过程.以确定该活动是否符合明确的需求。注2:验证过的词用来表示相应的状况。GB/T 6583-1994J 419 G/T 18905. 3-2002/ISO/IEC 14598-3: 2000 参考文献1J ISO/IEC 9126-2软件工程产品质量外部度量2J ISO/IEC 9126-3软件工程产品质量内部度量3J ISO/IEC 9126-4软件工程产品质量使用质量的度量4J GB/T 8566一2001信息技术软件生存周期过程5J GS/T 18492-2001 信息技术系统及软件完整性级别420
