【国家标准(GB)】 软件工程 产品评价 第3部分: 开发者用的过程

ICS35.080
中华人民共和国宝家标准
GB/T 18905.3-2002/IS0/IEC 14598-3:2000软件工程
产品评价
第3部分：开发者用的过程
Software engineering--Product evaluation--Part 3: Process for developers(ISO/IEC14598-3:2000IDT)
2002-12-04发布
中华人民共和国銀
国家质量监督检验检疫总局
2003-05-01实施
GB/T18905.3-2002/IS0/IEC14598-3:2000前言
GB/T18905--2002《软件工程产品评价》分为六个部分：第1部分：概述；
第2部分：策划和管理；
第3部分：开发者用的过程；
第4部分：需方用的过程；
—第5部分：评价者用的过程；
一第6部分：评价模块的文档编制。本部分为GB/T18905-—2002的第3部分，等同采用ISO/IEC14598-3：2000《软件工程产品评价第3部分：开发者用的过程》（英文版）。本部分的附录A是资料性附录。
本部分由中华人民共和国信息产业部提出。本部分由中国电子技术标准化研究所归口。本部分由中国电子技术标准化研究所负责起草。本部分主要起草人：罗锋盈、陈莹、王凌、冯惠。407
TKAoNT KAa-
GB/T18905.3—2002/IS0/IEC14598-3:2000引言
本部分旨在供软件开发期间使用。它适用于所有需要严格要求过程的软件开发活动。本部分特别有助于测量和评价软件质量。
本部分提供了指南，包括阐明质量需求，实施并分析软件质量测量。它适用于所有软件和开发生存周期的所有阶段。其重点在于选择并报告一组指标，这些指标对于通过测量中间产品的质量来预言最终产品质量是有用的。它的重点还在于测量最终产品质量。408
1范围
GB/T 18905. 3-2002/ISO/IEC 14598-3:2000软件工程产品评价
第3部分：开发者用的过程
当评价与开发同步进行并由开发者实施时，本部分提供了对软件产品评价的惯例实现的需求和建议。特别是，使用本部分时还可采用ISO/IEC9126的第1、第2和第3部分，以及GB/T18905.1、GB/T18905.2和GB/T18905.6中描述的概念。本部分描述的过程定义了分析评价的需求，规定、设计和执行评价的行动，以及为任何软件产品的评价作结论所需要的各种活动。这里设计的评价过程旨在与开发同时使用。评价过程须与软件开发过程同步进行，实体在交付时须予以评价。
本部分可供下列人员使用：
·项目管理者，用于阐明质量需求，在开发期间监督和控制软件质量，以及为确保需要的质量成为软件的内在组成部分做出决定；·软件设计者，用来标识应内置于软件的具体特征或为满足质量需求而变更的具体特征；·质量保证、控制、审核负责人，用于评价是否满足质量需求；，维护者，为变更的实现和重(再)设计做出决定；，软件的需方。当不需要独立评价时，需方是获取软件时（如外购软件开发产品的情况）与开发者达成的协议的一部分。需方可以是采购人员、外购部分软件产品的开发者或是最终用户。需方的作用取决于与开发者所签的协议。GB/T18905.4描述了按需方的角度的评价。本部分旨在项目级的应用。为了从本部分全面获益，组织应当介人。GB/T18905.2包括了这方面的内容。
本部分既未规定具体的指标或计量，也未规定任何特殊的开发方法。2致性
为符合本部分，组织应评审第6章的所有需求和建议，以识别哪些是适用的，并声明哪些需求尚未实现。
3规范性引用文件
下列文件中的条款通过本部分的引用而成为本部分的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。GB/T8566-—2001信息技术软件生存周期过程（idt1SO/1EC12207：1995）GB/T18905.1—2002软件工程产品评价第1部分：概述（ISO/IEC14598-1：1999，IDT）GB/T18905.2-2002软件工程产品评价第2部分：策划和管理（ISO/IEC14598-2：2000，IDT)
GB/T18905.6一2002软件工程产品评价第6部分：评价模块的文档编制（ISO/1EC14598-6:2001.IDT
ISO/IEC9126-1软件工程产品质量第1部分：质量模型409
HTTKANTKA
GB/T 18905. 3--2002/IS0/IEC 14598-3:20004术语和定义
GB/T18905.1中已给出的定义，以及下列定义适用于本部分。4.1
计量原则 counting rule
获取测量值所依据的条件和规程。4.2
external attribute
外部性
实体的可测量的性质，它仅可由实体与环境的关系导出。注：外部属性指与需求相关(软件的外部特性)，仅可由所属系统的操作行为导出。4.3
内部属性
internal attribute
实体的可测量的特性，它可能纯粹由实体本身导出。注：内部属性与软件及其开发的内部组织相关。4.4
单位unit
作为测量标准而采用的一个量。注：每个单位都有一个相关联的标度。5评价概念
5.1总则
软件产品的质量可根据质量特性加以描述。注：在ISO/IEC 9126-1中定义了一组质量特性。一般地，对这些特性直接赋予测量值并不实际，而是对软件产品选择一组质量属性来代表特性的主要方面是比较可行的。这些属性的测量值给出了软件产品质量的定量表示。本部分的重点在支持开发者在开发生存周期期间实施软件测量和评估。这要通过识别中间产品和开发活动的属性以及通过测量这些属性来实现。本部分提供了在开发过程期间定量监控开发中的软件产品质量的方法。其目的是识别出问题，尽可能早地达到开发过程中所期望的质量。当前对软件测量和软件评价的认识水平不能证明所推荐的一组单独的属性，可以应用于每种软件产品和每个软件开发组织。因此，软件产品的属性、中间产品的属性以及开发活动的选择是以组织的软件开发经验为基础的。
5.2用户需要
用户需要的标识是建立总的质量需求的个重要方面。这要通过标识用户对特殊使用环境中使用质量的需求来实现。这些总的需求本质上是非正式的，需要正式化。通过对使用质量进行度量来加以量化和评价。
注：-组使用度量的质量在ISO/IEC 9126-4中摘述。本部分采用的方法是按外部属性公式化总的（质量）需求。5.3外部性
外部质量属性代表了软件产品的质量特性，用于定量地表示外部质量需求。这些需求通过对每个属性分配目标测量值来实现。
开发软件产品时，收集属性的实际测量值，从而为软件质量特性提供定量的表示。通过将实际测量值和所有属性的目标值进行比较来实现质量评价。注：一组软件质量外部度量在IS)/IEC9126-2中提供。410
5.4内部属性
GB/T 18905.3—2002/IS0/IEC 14598-3:2000为了在开发期间监控软件质量，把外部质量需求转化成对中间产品和开发活动的需求。这要通过把软件产品的外部属性的目标测量值转化为对中间产品和开发活动的内部属性的目标测量值来实现。选择内部属性和把外部目标值转化为内部目标值是一项重要的活动。它主要依靠个人经验，除非开发者提供收集和分析以前已完成项目经验的基础设施。此时，靠开发者的个人经验能支持这一活动。注1，组织方面在GB/T18905.2中描述。在开发期间测量内部属性的实际值。将该值同自标值进行比较。它提供了开发期间对软件质量的控制。
内部属性可用于识别异常值或离群值（即偏离于正常情况下所期望的属性值）。一般经验证明，需要对这些实体进行更密切的审查。当定期（例如每周）测量内部属性时，一些内部属性可用于监督开发的进展。进展的测量能较早识别问题，包括产品和开发过程的问题。注2：ISO/IEC9126-3提供了-组内部度量。5.5质量指标
内部质量属性可用作质量指标。特别是，内部属性经常用作外部属性的指标；但是尚未确认质量指标和外部质量属性间一般的直接关系。然而，普遍认为质量指标提供了谨慎使用时有用的使用指南。质量指标的使用使软件开发者在开发中及早识别可能存在的质量问题并立即采取纠正措施。不存在适合于一切软件开发工作的通用质量指标集。实际应用、开发方法和工具以及项目组织都存在差异，还存在一些文化差异。因此，对某个组织有用的指标在另一个组织中不一定有用。5.6评价过程
本部分描述的评价过程由开发者执行的一组活动组成。这些活动在开发过程期间获得的测量值的基础上执行。
注1：一般评价过程在GB/T18905.1中描述。注2：评价的组织方面在GB/T18905.2中描述。评价过程由下列五个活动组成：一确立评价需求：根据一个已商定的质量模型，由识别总的质量需求组成。该活动的描述见6.2；一一规定评价的规格说明：由确定外部度量和目标测量值（评价准则）组成。该活动的描述见6.3.1。规格说明还包括确定内部度量和目标测量值（评价准则）。该活动的描述见6.3.2；一设计评价：由策划的数据收集行动组成。该活动的描述见6.4.1和6.4.2；一———执行评价：由开发期间收集内部测量值并将它们同目标值（开发期间的评价）进行比较组成。内部属性值（质量指标）用于估计最终产品质量。这在6.5.1中描述。当存在外部测量值时，该活动也包括收集外部测量值，当它们变为可用时，将它们同目标值（产品质量的评价）进行比较。该活动的描述见6.5.2。
对组织的反馈：基于对评价结果的评审。该活动的描述见6.6。5.7评价与生存周期过程间的关系软件产品的评价可在任何生存周期过程中进行。注1：软件生存周期过程在GB/T8566一2001中定义。本部分主要涉及开发过程。
注2：开发过程在GB/T8566--2001的5.3中规定。如GB/T8566--2001所述，它也喻示着有必要考虑维护过程（5.5）、支持生存周期过程（6）和组织的生存周期过程（7)。当本部分用于外购软件的开发时，如GB/T8566一2001的5.1和5.2所述，它也涉及获取过程和供应过程。6评价过程需求
6.1总需求
HTTKANTKAa
GB/T 18905.3—2002/IS0/IEC 14598-3:2000本章涉及组织的和项目特定的需求。6.1.1组织需求
开发者应建立基础结构，从而允许在数据分析基础上进行数据收集和过程修改。注：评价的组织方面在GB/T18905.2中描述。6.1.2项目需求
开发者应遵循严格规定的开发过程开发软件，允许计划并实施软件测量和评价。注1：生存周期过程在GB/T8566—2001中描述，其中开发在5.3中描述。注2：软件产品评价综述见GB/T18905.1。开发者应协调评价活动与支持过程及活动。注3：支持过程在GB/T8566-2001中描述，特别包括质量保证过程（6.3）、验证过程（6.4)、确认过程（6.5)和审核过程（6.7)。
许多数据分析方法需要先前在类似条件和可比质量需求下开发的项目中的数据。因此，开发者应采用开发者的组织在以前的项目中已使用的类似的开发模型。在项目中还应使用同样的属性集，以便进行数据分析。
6.2确立评价需求
本条涉及总质量需求的建立及其可行性的分析。6.2.1质量需求的标识
开发者应确保确定了应用于软件系统的一般质量需求。当标识一般需求时，宜考虑用户的需要、组织的经验、应用领域的经验、软件的完整性需求、所要求的标准、法规和法律等。注1：软件的完整性级别在GB/T18492--2001中描述。开发者应确保已商定的质量模型用于结构化质量需求。注2：质量模型在ISO/IEC9126-1中描述。应列出一些可能影响质量需求可行性的其他系统需求（清单）。还宜考虑需方的问题，如成本和进度约策，许可证和组织方面的问题。还宜考愿解决排他性的需求。注3：重点宜放在产品的外部属性。创建和使用软件系统的各方宜参与或派代表参加到确定质量需求的过程中。宜与参与的各方讨论需求的相对优先级。每个小组根据其他系统需求和约束来权衡质量需求。宜：考虑各方面的观点。
识别的质量需求可能是互相矛盾的，也可能是相互配合的。应解决需求间的矛盾。另外，如果质量需求的选择与成本、进度或系统功能性冲突，则应变更其中的儿项。开发者应进行质量需求的可行性分析。应考虑开发者组织在以前执行的具有类似的质量需求的项自的经验。
开发者应确保需求在技术上是可行的，合理的，互补的，可达到的和可验证的。按商定的质量模型，质量需求应分解为单一组质量需求。列出最终总需求的协议宜征求所有各方的意见。
6.3评价的规格说明
本条涉及质量需求的量化。对每个需求，选择一个或多个外部属性来代表。赋子的目标值作为需求的量化表示（评价准则）。
对每个外部需求，选择一个或多个内部属性代表开发期间的需求。对内部属性赋予的目标值用来控制开发期间的质量。
6.3.1外部质量需求
开发者应定义在哪些生存周期过程和活动中将实现测量和评价。注1：外部属性的测量和评价通常在完成开发之后进行。412
开发者应定义测量和评价哪些实体。GB/T 18905. 3--2002/IS0/IEC 14598-3:2000注2：这些实体通常是最终产品的一部分（例如：运行系统或用户手册）。开发者应定义测量哪些外部属性。开发者应标识每个质量需求所用的度量（根据定义的外部属性和实体）。开发者应定义对每个度量的目标值。注3；目标值给出了质量需求的定量表示。注4：目标值用做评价准则。
开发者应定义执行测量的条件。也即标识其属性值能影响测量的其他属性，并定义这些属性的值开发者应对质量需求执行细化的可行性分析。宜考虑开发组织在以前执行的具有类似质量需求的项目中的经验。
开发者应确保需求在技术上是可行的、合理的、互补的、可达到的和可验证的。外部属性值可能依赖于其他属性值。应具体规定这些条件，以使测量值有意义。注5：例如，系统的响应时间取决于硬件、操作系统、系统中运行的其他程序、用户概况等6.3.2内部质量置幕求
并发者应定义在哪些生存周期和活动中将实现内部属性的测量和评价。注1：内部属性的测量和评价通常在开发过程期间进行。开发者应定义测量和评价哪些实体。注2：已选择的实体通常是中间产品和活动。开发者应定义测量哪些内部属性。注3：不同的中间产品可需要不同的属性。开发者应为属性和实体的每种组合识别度量。开发者应定义的内部属性集，使其：覆盖每个相应的中间产品和活动；一适合于应用领域和开发中所用的方法；覆盖已识别的产品和开发风险。注4：开发风险的例子包括规格说明不能稳定、识别的问题未着手解决、进度滞后于进度表等宜纳入适当的趋势度量。
注5：当定期采用趋势度量时，有些度量对于确定软件开发过程的趋势是有用的。这种趋势度量的例子有：“已完成的模块数”、“已解决的问题数”、“已更改的需求数”等。开发者应定义一组与所有外部属性（即所有质量需求)有关的内部属性。这些属性用作质量指标。注6：宜分析有关中间产品并收集内部测量数据，其目的如下：一评价中间产品的质量，以发现质量需求满足（或不满足）情况的指示；一得到最终产品质量的指示（预测）。注7：ISO/IEC9126-3可用作选择指标的指南。对于已定义的质量指标，即指标和外部质量属性间的关系，开发者应描述预测模型。注8：指标不需要与试图要测量的质量属性形成严格的一对一关系。但是宜明确定义指标和有关的质量属性之间的联系。
为有效地管理使用，指标数目不宜过多。宜把优先级给予那些可由在现有过程（如配置管理过程或集成测试过程)期间已收集的数据支持的指标。适当时，并发者应对内部属性设筐自标值。开发者应定义要执行的测量条件，即标识其属性值能影响测量的其他属性并定义这些属性的值。注9：依据定义，内部属性值的测量可独立于其他属性。6.4评价的设计
HTTKANTKAa
GB/T18905.3-2002/IS0/IEC14598-3:2000本条涉及评价的设计。外部评价关系到外部质量需求，内部评价关系到开发期间的内部质量监控。注：对定量评价计划的引用见GB/T18905.2。6.4.1策划外部评价
为获得每个外部度量的实际值，开发者应规定要执行的数据收集措施（规程）。包括时间进度表、职责以及运用的数据收集和分析工具的规格说明。如需对人员进行特殊培训，也宜列人计划。开发者应定义测量精确度。所采用的所有统计模型都应予规定，包括输人数据需求、抽样策略等。注：如果开发者的组织已定义了一组评价模块，则该活动也包括选择评价模块。评价模块的文档编制在GB/T18905.6中描述。
6.4.2°策划内部评价
为获得每个内部度量的实际值，开发者应规定要执行的数据收集措施（规程）。包括时间进度表、职责以及运用的数据收集和分析工具的规格说明。如需对人员进行特殊培训，也宜列人计划。开发者应定义测量精确度。所采用的所有统计模型都应予规定，包括数据需求，抽样策略等。开发者应规定应急措施，如额外评价，以防测量结果不能做出结论或是警告性的开发者应考虑对软件开发活动的各种影响。测量集通过数据采集需求可隐含在开发过程中的更改。
注1：为实施测量有时必须对硬件或软件工具进行定位、评价、获取、适配或者开发。测量集可能隐含了用来产生软件系统的组织性结构的更改。质量保证与控制组织或整个开发小组可能需要接受有关应用测量与数据收集规程方面的培训。如果在开发过程中测量的实施引起了更改，则开发小组可能需要接受有关更改方面的教育。
注2.：如果开发者组织已定义了一组评价模块，则该活动也包括选择评价模块。评价模块的文档编制在GB/T 18905.6中描述。
6.5评价的执行
本条涉及按计划收集质量数据并与目标值（评价准则)进行比较。6.5.1内部评价
质量的监督和控制在开发期间进行。收集内部属性的实际值。对非期望值分析原因，使开发者能了解问题并解决问题。
开发者应根据已定义的数据收集措施，为已定义的内部属性收集实际测量值。如果质量需求有变化，则开发者应重新考惠评价规格说明（6.3)和评价设计（6.4）。开发者应采取必要的措施以保证收集数据的质量。适当时，这些措施宜包括确认数据收集用的自动工具，并通过手工步骤检查数据。当指定目标值时，开发者应将它们与实际值加以比较。开发者宜使用已定义指标的实际值来估计最终产品质量。宜考虑开发组织在先前具有类似质量需求的项目中的经验。
注：质量预测依赖于已确认的指标。开发组织首先要为几个项目收集指标值和产品测量值，以得到一组确认的指标。
为识别开发风险，开发者宜使用实际值以监控发展趋势。开发者应分析实际值以识别离群值。离群值通常表示出了问题或非正常情况。宜始终寻求对离群值的解释。有时对离群值有合理的解释。在此情况下，就不必采取纠正措施。必要时应采取应急措施。
6.5.2最终产品的评价
软件产品的质量评价在完成开发时进行。要收集外部属性的实际值。注1：如有可能，软件构件可在开发完成前进行测量。开发者应根据定义的数据收集措施，为已定义的外部属性收集实际测量值。如质量需求有更改，开414
发者应重新考虑评价规格说明（6.3)和评价设计（6.4）。GB/T 18905.3—2002/IS0/IEC 14598-3:2000开发者应采取必要的措施以保证收集数据的质量。适当时，这些措施宜包括确认数据收集用的自动工具，并通过手工步骤检查数据。开发者应将实际值和目标值（评价准则)加以比较。注2：在本部分中描述的评价过程由开发者实施。GB/T18905.5描述了个独立的评价过程。开发者应对评价结果做出评估。为支持有关开发结果（例如，改进产品、评审需求等）所作的决策，宜对实际值做汇总，并与其他值（如时间和成本）进行比较。开发者宜将评价结果编成文档。6.6质量评价的评审和对组织的反馈开发者应收集对组织有用的数据，以便在其他开发项目中使用。开发者应评审评价结果和对所采用的评价过程、指标和度量的确认。宜使用评审反馈，以改进评价过程和评价模块。当必须改进评价模块时，宜纳入对额外指标的数据收集，以便在以后的使用中加以验证。
注：质量评价评审和反馈在GB/T18905.2中描述。415
HTKoirKAa
GB/T18905.3—-2002/IS0/IEC14598-3:2000附录A
（资料性附录）
选自其他标准中的定义
除另行注明者外，下列定义均选自GB/T18905.1。A.1
需方acquirer
从供方获得或获取系统、软件产品或软件服务的组织。[GB/T8566-—2001]bzxZ.net
属性 attribute
实体的可测量的物理或抽象的性质。注：属性可以是内部的或外部的。A.3
开发者developer
在软件生存周期过程中执行开发活动（包括需求分析、设计、测试直至验收)的组织。[GB/T 8566—2001]
direct measure
直接量测
不依赖于任何其他属性度量的一种对属性的度量。A.5
evaluation module
评价模块
针对特定软件质量特性或子特性的评价技术包。注：该评价技术包概括了评价方法和技术、要评价的输入、要测量和收集的数据，以及支持规程和工具。A.6
外部度
external measure
通过对系统行为的度量得出的对产品的一种间接量测，其中产品是系统的一部分。注1：系统包括任何相关的硬件、软件（定制的软件或现货软件）和用户。注2：在测试中发现的故障数量是对程序中的故障数量的外部度量，因为故障的数量是在计算机系统运行程序的过程中计算的。
注3：外部度量可以用来评价更接近于最终设计目标的质量属性。A.7
外部质 external quality
产品在特定条件下使用时，满足明确或隐含要求的程度。A.8
失效 failure
产品完成所需功能的能力的终止，或在原先规定的限制内没有能力完成。A.9
故障fault
计算机程序中的不正确的步骤，过程或数据定义。注：该定义取自IEEE610.12-1990。416
隐含的要求implied needs
GB/T 18905.3—2002/IS0/IEC 14598-3:2000当实体用于特定条件下时，尚未说明但又是实际需要的要求。注：隐含的要求是未形成文档的真实要求。A.11
指标indicator
能用来估计或预计另一度量的一种度量。注1：预计的度量可以有相同或不同的软件质量特性。注2：指标可用来估计软件质量的属性和开发过程的属性，它们是对属性的不精确的间接量测。A.12
间接测量indirect measure
从一个或一个以上的其他属性的度量得出的一种对属性的度量。注：对计算机系统属性（例如对用户输入的响应时间)的外部度量就是对软件属性的一种间接量测，因这种量测要受计算环境的属性和软件属性的影响。A.13
intermediate software product软件中间产品
软件开发过程中的产品，用作对软件开发过程另一阶段的输人。注：在某些情况下，中间产品也可以是殿终产品。A.14
internal measure
内部度量
对产品本身的一种度量，或是直接的或是间接的。注：代码行数、复杂度度量、在走查和Fog索引中发现的故障数都是对产品本身进行的内部度量。A.15
内部质量internalquality
产品属性的总和，决定了产品在特定条件下使用时，满足明确和隐含要求的能力。注1；在GB/T18905中，与术语“外部质量”对应的\内部质量”基本上与GB/T6583一1994中\质量\的含义相同。注2：术语“属性”与4.21中术语“特性”的含义相同，而术语\特性”在ISO/IEC9126中有更具体的含义。A.16
维护者maintainer
执行维护活动的组织。
[GB/T 8566-2001]
measure (verb)
执行一次测量。
measure (noun)
通过执行一次测量赋予实体属性的数字或类别。A.19
measurement
使用一种度量，把标度值(可以是数字或类别)赋予实体的某个属性。注：使用类别时，测量可以是定性的。如软件产品的一些重要属性，例如源程序语言（ADA，C,COBOL等）就是定性的类别。
HTKOrKAa-
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。