【国家标准(GB)】 软件工程 产品评价 第4部分: 需方用的过程

ICS35.080
中华人民共和国国家标准
GB/T 18905.4—2002/ISO/IEC 14598-4:1999软件工程
产品评价
第4部分：需方用的过程
Software engineering---Product evaluationPart 4:Process for acquirers(ISO/IEC 14598-4:1999,Information technologySoftware product evaluation-Part 4 : Process for acquirers,IDT)2002-12-04发布
中华人民共和国
国家质量监督检验检疫总局
2003-05-01实施
GB/T 18905. 4—2002/ISO/IEC 14598-4:1999言
GB/T18905—2002《软件工程
产品评价》分为六个部分：
第1部分：概述；
第2部分：策划和管理；
一第3部分：开发者用的过程；
第4部分：需方用的过程；
一第5部分：评价者用的过程；
-第6部分：评价模块的文档编制。本部分为GB/T18905--2002的第4部分，等同采用ISO/IEC14598-4：1999《软件工程产品评价
第4部分：需方用的过程》（英文版），附录A、附录B、附录C、附录D和附录E是资料性附录。本部分由中华人民共和国信息产业部提出。本部分由中国电子技术标准化研究所归口。本部分起草单位：北京信息工程学院、中国电子技术标雅化研究所。本部分主要起草人：王凌、冯惠、罗锋盈、陈莹。423
GB/T18905.4—2002/IS0/IEC14598-4：1999引言
软件已经变得日益普及。由于更多的过程能自动利用计算机的能力来进行，因而增加软件的功能、完善软件产品的要求也在不断增长。今天现代化系统如此复杂，没有软件就无法实现其功能。随着可利用的软件产品种类的不断增加，加速了现货软件产品的商业应用，同时软件工程技术的迅速发展也减少了对定制软件的依赖。面向对象的开发方法是基于对现存的自包含单元程序库的扩展来进行应用系统的开发，也减少了对用户定制软件的需求。这就使重点转向了软件产品质量或自包含软件单元的质量上。
定制软件的开发倾向于重新编写程序，其结果不能满足用户的需求。使用定制软件会在调配、实施、培训和维护支持活动方面比预期要付出更多的人力和物力。获取商业现货软件产品或者复用内部现有的软件产品也不是没有风险。因为现货软件产品可能也需要客户化（即按用户要求进行修改）；测试和分析的需求量可能很大；当产品过时或需要修正时，产品维护和支持会有问题；将软件产品集成到大型系统中可能比较困难；产品的质量可能与目标系统的质量需求不一致等等，因此问题可能会很多。商业现货软件产品的种类繁多。包括：a）独立使用的产品（即工资单、会计软件，消费软件，或压缩软件[即字处理软件，报表软件})；b）作为部件集成到由其他软件和硬件部件构成的大型系统中（即操作系统，关系数据库管理系统，图形用户界面［GUII）：
嵌人到硬件中（即通信数据链接，可编程阵列逻辑[PAL})；c）
d）作为用于开发特定应用的可配置的软/硬件系统的嵌人部分（即分布式控制系统）；e）用作支持软件开发和维护过程的CASE工具（即编译程序，配置管理工具）。独立使用的软件产品中的差错能影响生产率，造成资金流失，或导致不必要的重复工作。软件部件会难于集成，会影响整个系统的可靠性，或不符合系统的目标。CASE工具可能会把错误引入到开发的产品中或是难于使用。
因此关键是在获取软件产品或决定复用一一个现存的软件产品或部件时，能评价软件产品的质量。评价可用来接受或拒绝一个单独的产品，或者从众多可选产品中选择一个满足日标应用所确立的质量需求的产品。评价过程的严格级别必须与产品完整性需求相对应。对用于关键性业务的软件产品进行评价时，其严格程度应是最高的。424
1范围
GB/T18905.4—2002/IS0/IEC14598-4:1999软件工程产品评价
第4部分：需方用的过程
GB/T18905的本部分包含了在获取现货软件产品、定制的软件产品或修改现有的软件产品时，对软件产品质量进行系统地测量，评估和评价的需求、建议和指南。它使用了ISO/IEC9126-1中描述的软件质量模型，扩展了GB/T18905.1中定义的软件质量评价的通用过程，以及使用了GB/T8566中定义的获取过程。它能与GB/T17544、GB/T18905.2、GB/T18905.3和GB/T18905.6-起使用。本部分与GB/T18905.5中的评价过程的步骤相类似，但两者使用的环境完全不同。对于委托第二方或第三方进行评价的情况，需采用GB/T18905.5。对于需要按照包的质量需求对软件包进行第三方测试的情况，可以应用GB/T17544。本部分所描述的评价过程还有助于满足决定是接受一种单一的产品，还是从备选产品中选择一项产品的目标。评价过程可以根据应用的性质和完整性级别加以剪裁。这样也能以节约成本的方式充分灵活地适应各种形式和用途的软件产品。本部分旨在为计划获取软件产品的项目管理者、系统工程师、开发及维护软件的工程人员和最终用户，以及提供这类产品的供方所用，但不只限于他们。在本部分中，评价过程的目标软件产品可以作为部件集成到较大的系统中，也可以单独使用。这些软件产品分为下面几类：
a）商业现货软件产品；
：b）为其他应用或范围更广的普通应用而开发或获取的现有软件产品；c）定制的软件产品或对现有软件产品的修改。本部分中定义的评价过程也适用于CASE工具。由于在GB/T18234中专门对CASE工具的评价进行了阐述，所以本部分不讨论CASE工具。本部分旨在与其他标准一起使用。对具有较高完整性需求的系统，可以在本部分所描述的评价过程中包含附加需求，这些标准源自部门专用的标准，例如：IEC880、DOA-167A、MOD-55等等。2致性
由于建议的通用性给用户提供了选择的自由，所以依从于本部分的简单声明是无效的。任何强制使用本部分作为贸易条件的组织负责规定和公开满足6.1.1中规定的强制性目标要求。这个规定的评价过程为本部分的给定应用制定依从性条款。第6章和第7章的全部活动都应视为具有适用性。对评价过程的需求也能在执行获取过程期间以合同的形式建立，因而，建立依从本部分所描述的评价过程也比较容易。
3规范性引用文件
下列文件中的条款通过本部分的引用而成为本部分的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。425
HTTKAONTKAa
GB/T18905.4--2002/IS0/IEC14598-4:1999GB/T8566--2001信息技术软件生存周期过程（idtISO/IEC12207：1995）GB/T18492--2001信息技术系统和软件完整性级别（idtISO/IEC15026：1998）GB/T18905.1-—2002软件工程产品评价第1部分：概述（ISO/IEC14598.1：1999IDT）GB/T18905.5-2002软件工程产品评价第5部分：评价者用的过程（ISO/IEC14598.5：1998，IDT)
ISO/IEC9126-1软件工程产品质量第1部分：质量模型4术语和定义
本部分采用下列定义。为便于引用，本部分所用到的其他标准的关键定义在附录A中重新给出。4.1
商业现货软件commercial-off-shelf software（CoTs)根据市场驱动的需要定义的、通过商业方式提供的、其适用性已经得到范围广泛的商业用户证实的软件。
注：可参见IEEEStd1062-1993中的定义。4.2
定制软件custom software
根据用户的需求规格说明，为某个特定应用开发的软件。4.3
现有软件existing software
已经开发并且可以得到的软件；可以“原样”使用，也可以经修改后使用；由供方、需方或第三方提供。
注：亦可参见GB/T8566对现货产品的定义。5软件产品评价的一般考虑
5.1评价过程和获取过程间的相互关系下面概括的获取过程的活动（在GB/T8566中定义）与第6章和第7章中的一般评价过程的活动（在GB/T18905.1中定义）相互结合起来。第6章的重点在获取COTS产品的过程中评价最终产品质量的应用方面。第7章的重点是获取定制的软件或修改现有软件过程中评价过程的应用。a）启动一—一确定要获取的产品的软件需求、获取计划、验收策略和验收准则；招标（标书)的准备--一获取需求的规格说明和编制文档；b)
合同的准备和更新一—一选择供方、合同的准备和谈判，以及合同变化的控制；c)
监督供方·-在合同执行期间实施评价活动，以期达到软件产品的验收和交付使用；d)
验收和完成一—一在验收和交付最终软件产品的过程中实施的活动。e)
注意：GB/T18905.1定义的一般评价过程未作为GB/T8566中的个过程来定义，但作为等同于策划一实施一检查一改进（PDCA)循环中的“检查”部分的一项基本功能，它在每一个生存周期过程中都将被执行。不过，一般评价过程也可以在任何GB/T8566的过程（即开发、维护、获取、确认）中执行，因此它与GB/T8566中所用的“过程”含义的抽象程度不同。在实施一般的评价过程时，了解这种区别是很重要的。获取者需要定义在评价期间要遵循的以达到评价需求的评价和获取过程。在大型系统的开发环境中，要遵循的获取和评价活动需要与其他开发和集成活动结合起来，并在如GB/T18905.2规定的项目测量计划中加以确定；也就是说，为评价所考虑的具体获取实施的内容包括以下几方面：·评价所要求的软件需求规格说明能构成用于招标（标书)所要求的获取需求的基础；·需要独立的初步评价活动以便预选软件产品和供方；426
GB/T18905.4—2002/ISO/IEC14598-4:1999·用于评价的供方及产品信息需求需要在获取需求中或在合同准备期间予以规定；·评价活动可在监督合同的执行期间作为部分要求的评价工作、部分产品的开发工作、或部分产品的正式验收工作来执行，或者在产品交付后执行。5.2评价过程的输入
5.2.1系统需求
对目标软件确定评价需求开始于对整个系统的需求。系统需求确定了用户、用户目标、任务及特性，包括产品的使用环境，以及产品或系统的功能需求和其他需求。它们构成了随后的系统结构设计、软件需求规格说明和软件结构设计的基础。由于相关的法律和法规对获取过程和评价过程的严谨性和形式化程度有影响，因此，在此阶段还需要说明法律和法规的需求。在对系统需求进行分解和设计期间，这些需求被分配为硬件配置项和软件配置项，还分配为包含系统规程的用户操作。系统开发生存周期内的设计活动会产生后来的获取或复用“现货”软件产品的决定。由于某些评价活动在形成决定的过程中起作用，因而，实际上，它们是这些设计活动的一部分。对要获取的软件产品的评价是单独进行的，在对最终产品进行系统集成和测试期间，软件配置项要与其他的软件和硬件配置项（参照GB/T8566）集成起来。图1示出了用于评价和获取的大型系统工程环境。本部分使用和获取的候选产品是能作为部件与大型系统进行集成，或是能独立使用的软件产品。其分类如下：
a）商业现货软件产品；
b）为其他应用或范围更广的普通应用而开发或获取的现有软件产品；c）定制的软件产品或对现有软件产品的修改版本。对于要集成到大型系统的软件配置项，需要对每一配置项定义软件需求。而在其它情况下，系统与软件配置项是一致的，并且可认为是等效的。要获取的硬件配置项可能包含软件，如，驻存在固件中的操作系统（即ROM、PROM）。当现有软件以这种方式构成硬件的一个完整部分时，通常需要与硬件配置项一起评价。5.2.2完整性级别需求
如果在可以接受的限制内，在包含系统的安全性、保密安全性、金融风险、环境风险以及社会风险等很重要的方面，软件是关键性的，就必须在获取和评价之前建立软件所要求的完整性级别，并形成文件。GB/T18492-2001中给出了完整性级别确定过程的指南。所确定的完整性级别决定了如何在评价过程中处置软件。
5.2.3软件需求规格说明
应使用一个适当的定义良好的质量模型来规定软件需求。为此，除非有特殊原因需要使用另一个模型外，宜使用ISO/IEC9126-1中的质量模型和定义。该模型定义了应用中软件的六种特性：功能性、可靠性、易用性、效率、可维护性和可移植性。这些特性能进一步分解为具有可测量或可评估属性的子特性。
宜按照直接与用户需要相关的外部度量（外部度量在ISO/IEC9126-2中定义）来定义需求，并编制成需求规格说明文档。将用户的需要编成文档包括制定非正式的功能需求和性能需求的清单，以便为产品（或系统，如果产品是嵌入式的)准备一个完整的产品需求规格说明。那么，需求规格说明可以构成在获取过程的招标步骤中所用的获取需求的基础，也可以构成随后执行的产品评价的基础。5.2.4由其他方实施的评价
只要评价结果是值得信赖的，那么，通过使用第二方或第三方实施的评价活动的结果可以缩小当前评价过程的范围。这种评价活动可以由预先存在的认证活动、产品评价活动和（或）过程评估来组成。例如：
·对用于产品开发的软件工程过程可实施标准化，以满足GB/T8566、GB/T19000.3或其他具体行业标雄的需求；www.bzxz.net
HTTKAONTKAa
GB/T 18905.4--2002/IS0/IEC 14598-4:1999·软件开发所遵循的供方的质量体系可由第三方根据GB/T19001的要求进行认证；·可由第二方或第三方对照GB/T18905.5或GB/T17544中的要求对软件产品进行评价；·开发可接受产品的供方的软件过程能力可由第三方根据ISO15504-8（在制定中）予以评估；软件可作为大型系统开发阶段的一部分进行功能性评价；·软件产品可能原先已经被具有不同完整性需求的另一个应用评价过；·可能已经在组织内被其他方通过非正式或正式的评价活动实施过产品评价。为获得和解释用于目标应用的外部评价结果，要求的附加成本和时间可能影响该方法的可行性。为了充分信任其它方的评价结果，仍有必要与评价者或供方进行协商。注：对供方的软件工程过程、供方的质量体系或供方的单独能力等方面的评价结果还不足以证明软件产品包含了所需的质量特性，还需要实施其他产品评价方法（例如那些专门测量与最终用户需求对应的质量要素和质量属性的评价方法）。
初始要求
系统需求的捕获和系
统设计
·用户目标和环境
·功能需求和其他需求
完整性级别
计算机子系统工程
人机工程
学和人为
因囊工程
产品评价
和获取
非计算机的
子系统工程
系统规程
子系统集成
和系统确认
系统操作
图1评价和获取软件产品的系统工程环境5.3剪裁
评价过程能用于范围广泛的获取需求、完整性需求和评价者目标。例如：·软件包的获取者可能希望只使用GB/T17544来评价软件包；·软件产品的获取者可利用GB/T18905.5来实施独立评价；·一个小的或单独的获取者可能要求带有最少文档的、不是很正式的评价过程；·对于消费类软件，评价过程的目标可以仅仅是从大量类似的产品中选择、测试和获取一种产品。正式的获取过程则简化到直接购买，而不需包括推备合同。评价过程宜具有灵活性以适应每种应用的独特性，避免不必要的工作或无价值的工作，这是树立软件的必要信心的一个实际手段。软件所要求的完整性级别极大地确立了评价过程的严格性和正规性。利用GB/T8566中给出的剪裁指南和要获取的特定软件产品所要求的完整性级别，按照评价过程428
GB/T18905.4-2002/IS0/IEC14598-4:1999来剪裁获取过程。对具有较高完整性需求的完整软件系统，通常会调用一整套获取活动和任务，包括GB/T8566中规定的供应过程对应的活动和任务。通常，随着完整性级别的提高，获取过程的精确度、与获取过程相关的活动和任务的数目也随之增加。附录B中的表B.1给出了一个按照月标软件完整性需求剪裁的集成获取过程和评价过程活动的例子。6获取现货软件产品期间的评价
GB/T18905.1中定义的通用软件产品的评价过程由四个主要步骤组成。在本部分对现货产品的获取过程中，这四个步骤特别体现和细化在强调对最终产品质量的评价上。然而，这并不排除针对特定的质量特性进行的对中间产品的评价。因此，这些步骤的具体实现细节与GB/T18905.1中所描述的略有不同，但并非不一致。表1将按照评价过程的步骤和关键任务，以及输人和输出四个方面对评价过程加以概括。
获取现货产品期间的评价过程
系统/软件需求
评价需求规格
评价规格说明
评价计划
评价步骤
确立评价需求
规定评价
设计评价
执行评价（6.4）
6.1第1步确立评价需求
6.1.1确立评价的目的和范围
评价过程应：
关键任务
规定目标、用途和范围。规定评价的精确度。确定评价的输入。确定要实施的评价，或由其他方实施的评价。确定要遵循的获取过程及如何将评价输人需求传达给供方。
选择与软件产品特性相关的度量。确立评定等级选择一组最有效的评价方法。确立对不同质量特性的评价结果以及有助于在特殊环境下对软件产品进行质量评估的其他方面加以概括的规程。准备一份描述评价方法及评价进度的评价计划。确定评价活动和获取活动的结合点。执行选择的评价活动，分析和记录确定软件产品适合度的结果。分析已发现的缺陷的影响和调整产品用途的选项。对产品是否可接受以及最终决定是否购买做出结论。
评价需求
规格说明
规格说明
评价计划
评价记录
和结果
a）按照能否客观评价软件产品的适用性，利用ISO/IEC9126-1中的质量模型和定义来确立-组软件质量需求；
b）对软件质量特性确立适当的优先级；确立适用的完整性级别的评价体系基础，包括确立评价活动中的精确度级别或细节需求，以及c）
评价过程的输人和输出；
注：图2给出了一个软件产品评价过程的概貌。它给出了从获取者的角度看到的，评价过程的输人和输出的不同看法。
d）确立要遵循的获取过程，以及如何将评价输入需求传达给供方；注：见附录C图C.1中组合的评价和获取过程的实例。e）考虑下列内容后确立评价范围、用途和目标：1）软件产品是否用于某个特定的应用、一组特定的应用或某一通用范围内的应用；2）第二方或第三方是否曾做过评价，或是否计划将来实施某种评价活动；429
GB/T 18905.4—2002/ISO/IEC 14598-4: 1999评价输入的视角
产品视角
用户和技术文档
质量体系、
工程过程
维护过程
满足质量需求
的必需的可信
度级别
软件质量需求
评价过程
确立评价需求
规定评价
设计评价
执行评价
产品使用的约束
评价结果的视角
成本评估
操作历史
失效信息
原型设计/测试
所要求的其
他验证活动
图2从获取者的视角看到的软件产品评价过程的概貌6.1.2规定评价需求
评价的需求规格说明宜：
确定用户及其目标、任务、特性及产品的用户环境；a）
确定软件应用的完整性级别（软件出错引起的风险），以及评价过程所需的精确度级别：确定规章制度方面的需求[需要给立法方（或任何需要的各方）提供产品质量保证方面的文档］（见ISO9126-1中的一致性），
确定产品的边界和接口，包括对软件产品的接口需求（即指通过接口传递的数据类型、数据格式、接口访问机制、失效/差错处理、计时问题、接口行为问题和接口状态的相关性和转换）（见ISO9126-1中的互操作性）；
如果产品是要求与其他部件或产品进行集成的较大系统的一部分，要确定集成需求；e）
确定软件的质量需求，包括：
强制性需求和可选的需求之间的区别；1）
解释或理解需求所需的假设、例外、限制、排除情况或未解决的问题；所有重要的质量特性以及优先级方面的用户需求（即，如果认为可维护性重要，就规定特3）
定的可维护性需求）；
所有设计约束和环境约束；即，软件产品的使用造成的功能和性能限制，以及软件产品与4）
用户应用中其他现有软件、定制软件和硬件集成的级别和复杂性引起的功能和性能限制；5）
所有项目管理约束：即，实施评价活动的资源和专业知识、进度安排和预算限额、可能有的依赖性或风险、关键性的假设，或有关评价工作本身的一些假设；使用不同于ISO/IEC9126-1中定义的质量模型的理由；6）
确定要评估的供方服务；即支持能力、应用开发能力和培训能力；g）
确定要评估的特定需求：即特定的技术可行性问题或设计实现问题；h)
确定被此一致（即无冲突需求)的、并与应用的完整性级别一致的评价需求；确定在未来应用中是否要复用产品，文档是否必须支持任何未来的产品评价；）
GB/T 18905.4—2002/IS0/1EC 14598-4:1999k）确定获取过程，以及招标期间供方应提供的信息；1）确定能减少产品评价工作的由第二方或第三方实施的评价，注：评价的需求规格说明的详细和完整程度直接影响着评价的完整性级别，即，尽管评价的结果可能被用来指导其它阶段的下一步工作，预见问题，或者排除某些软件产品或供方，但仅仅基于初步需求的评价不能被认为是完整的评价。作为适当的设计或计划活动的一部分，这些工作通常会在主要的评价活动之前进行。在最终确定需求之前可能也需要一些评价工作。6.2第2步规定评价
评价规格说明宜编成文档，从而使具有相当资格的人员能重复评价过程并得到相应的结果。6.2.1选择度量
评价规格说明宜确定：
要评价的产品的特性；
b）使用软件时，与质量的可测量方面相关的外部度量（附录B的表B.2表示一个外部度量的例子和可能的验收准则。注意：由于没有方便有效的规则可用，因此，可由用户根据经验来规定实际的验收数量值）；
“使用质量”的度量与用户对含有软件的系统的质量看法有关（见附录B表B.3的使用度量的c）
示例)；
对可接受范围的度量推则的有效描述（例如，必须有多少操作历史为给定的质量特性和给定d)
的完整性级别提供一个合理的保证程度（见附录D.4和D.5中操作历史的具体细节））；e)
任何打包的评价模块；
与评价需求相关的覆盖级别，在对原先由其他方完成的评价进行评审之后该评价需求是必须的；
评价要回答的检查表：
有助于回答问题的示例清单：
要使用的测试用例；
要收集和分析的数据及格式
k）要采用的特定评价方法，包括评审或评估下列内容的一项或多项：1）软件产品的用户和技术文档（包括在线文档)（见附录D.1)；2）基于供方的课程和培训的软件产品评价（见附录D.2）；3）
软件工程过程，包括中间软件产品（见附录D.3）：4）
供方的产品操作历史（见附录D.4)；5）
用户的产品操作历史（见附录D.5）6）
供方的能力、支持和质量体系（见附录D.6)；7）
原型或其他评价方法（见附录D.7）；8）产品缺陷清单和相关信息（通常在万维网上找到）；1）评估这些评价结果的方法；
m）对评估结果进行评级的合适的方法，以便从相似的产品中选择一项产品；用于比较多个软件产品的评级方案。评级方案可以按质量特性的优先级来设定权重。n）
选择评价方法
宜规定评价方法的某种组合，以允许选择产品或确立产品的适用性。要评价的领域包括：a）某些考虑的事项是否可能相互冲突（例如，“所选择的[评估}方法的成本是否在预算之内？”可能和“收集的方法是否表达了所有评价需求？”不相兼容）。在这种情况下，由评价者根据评价需求的优先顺序进行必要的权衡；注：附录B中的表B.4给出了从成本和有效性两方面对软件质量特性的评价方法进行评级的例子。431
HTTKANTKAca
GB/T18905.4--2002/IS0/IEC14598-4:1999b）评价是否在组合所选的方法方面提供足够的覆盖区域或范围，这要考虑如下问题：1）怎样证明软件满足了它的规格说明；各方法覆盖范围的重叠，以提供额外的信任度；2）
这组活动作为…个整体，是否提供了一种可接受的保证级别，保证它完全覆盖了人们所关3）
心的那些软件质量特性；
这些方法的互补程度：
说明针对各种特性时，每种方法的有效性和客观性：评价方法之间各种不同的途径（如，基于各种方法的评审、分析和测试）：6）
因对应用所进行的评价活动取得信任，这些评价活动最终是整个系统开发周期的一部分7
活动；
8）相信由其他方完成的评价。
为了缩小功能上认为适合进一步评价的产品的选择范围，使用“非正式”的初步评价活动，如评c）
审、调查或同行/用户经验、刊物对产品的评述、可查阅的产品用户文档、或产品评审的数据存储库等。
由其他方实施的评价
在相信由其他方实施的评价之前，宜考虑下列情况：用精确度等级来说明评价需求的评价是否与应用的完整性级别一致？a）
评价报告是否指出了要评估的软件产品的版本、评价的范围、所用的判定准则和评价结论？b)
评价报告是否指出了软件产品或软件工程过程中的缺陷？是否提出了对那些缺陷的纠正措施c）
和建议？以及这些纠正措施是否落实？d)
评价者是否有适当的专业知识，包括：1）实施评价和分析的经验；
2）与国际公认的标准有关的软件质量方面的经验；3）软件工程方面的专业知识；
4）与供方的完全独立性。
6.3第3步设计评价
产品评价计划宜确定：
供方或第三方是否愿意或能够提供对所需文挡、设备，工具、软件、课程和（或）培训以及与此相关的成本等内容的访问；
与访问各种机密或专有信息相关的条件；b)
供方和第三方是否愿意或能够提供对具有相当专业知识的人员的访问，以便回答问题，与此相c）
关的成本是什么，包括差旅成本；根据评价需求，评价者开展评价所需的专业知识，以及获得这类特殊专业知识的成本：d)
为使产品适于全面测试所需要的预先测试；e）
为实施评价而提供测试环境（如测试硬件、支持设备和工具、专业人员）所需的成本；f）
评价的职责和所要求的进度安排；g）
在提供质量保证的评价方法中的任何限制和缺陷，以及这些限制和缺陷是否在计划中的其它h)
地方已经提到；例如，评价方法无法囊括一个特定质量特性的所有子特性；所用的各种评价方法之间的任何相互依赖性，即，建立评价方法的最佳顺序的顺序相关性（从i）
一项测试中获取的信息可能在另一个测试中有用）；必要的资源、总的评价成本以及每一种评价方法的成本；j）
k）评价活动和获取活动之间的连接点（见附录C中图C.1评价过程和获取过程的组合示例）；1）评价过程的决策点，它确定何时、因何原因认为评价是究成了（即接受或拒绝准则），并宜停止432
评价；
m）下列是计划的各项评价活动：1）宜遵循的规程和技术；
2）所要求的信息输人/输出和文档；3）对生成的文档的任何格式和内容需求；GB/T 18905. 4-2002/ISO/1EC 14598-4: 1999定义评价计划时做出任何例外或异常决定的背后所遵循的依据、理由及假设要形成文档；n)
o）评价工具；
p）开发和验证度量的规程，以及评价过程、度量和测量的标准化规程。注1：GB/T18905.6定义了评价模块的概念，该评价模块系统地收集应用某一特定评价技术或方法对质量特性的指定方面进行评价所必需的信息。注2：在安排评价方法的进度时，重要的是要认识到在各种不同的评价方法之间存在着高度的相互依赖性。也就是说，从一种方法获取的信息可能影响对另：种方法的理解。因为评价的本质是可重复的，在信息被获取时，可以再次考察这些问题。因此在进行评价时，评价计划可能会改变。举例来说，·旦进行评价，通常认为不必进行更详细程度的评价，或只作为一项附加需求。注3：软件产品的评价可以在一个开发生存期中不同时间点分阶段进行，或在生存周期的某一时间点同时进行。不同的团体或个人可以负责评价的不同部分。当评价分阶段进行时，在每个阶段都重复评价活动的步骤，直到不需进行进一步的工作为止（见附录E中分阶段的评价过程的示例）。6.4第4步执行评价
6.4.1执行评价的方法
a）宜执行评价、编写评价文档及分析评价，以便：建立能使该软件产品满足评价需求的适当的可信度等级；1)
确定各种关于评价需求的具体缺陷和任何确定这些缺陷范围所需的附划评价；确定应用软件产品的各种特殊限制或条件；3）
确定评价自身的弱点或遗漏以及要求的附加评价；4）
确定任何未被评价覆盖的软件产品的应用选项；b）评价的执行记录宜标识：
按照评价计划中规定的规程执行评价；评价规程的执行步骤（包括所用的数据、安装过程和任何状态信息）、评价结果（对所有问2）
题的解答和对答案来源的引用），以及软件产品的版本号；某个评价活动的任何限制、约束、缺陷或例外，包括它们对过期的软件产品在使用、配置、3）
修改或日常维护中的影响；
评价者和他们的资格；
要评估的产品版本和相应评价输入的不同，即文档编制或课程间的任何区别；缺陷事件中的解决方案或“变通的工作”。6）
6.4.2分析评价结果
分析评价活动的记录宜标识，
a）每个缺陷、任何相关分析以及每个缺陷是如何解决的。缺陷的解决情况可以包括：1）任何一种其他评价方法已保证该缺陷不是主要缺陷；例如，大量的操作历史可能弥补有缺陷的软件工程过程；
能找到满意的“变通办法”以减轻缺陷的影响：如，对产品的修改，禁用或删除不需要的功2）
能，用逆向工程的方式重新生成遗漏的设计需求；初始的需求不是强制性的，且缺陷是能够接受的；3
4）只要软件产品的使用受到特定条件或限制的控制，则缺陷是可接受的；需要附加的评价工作以解决评价缺陷或差距。5）
TKAoNrKAa
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。