软件产品评价标准介绍(20051129).ppt.ppt

《软件产品评价标准介绍(20051129).ppt.ppt》由会员分享，可在线阅读，更多相关《软件产品评价标准介绍(20051129).ppt.ppt（96页珍藏版）》请在三一办公上搜索。

1、软件产品评价标准介绍,主讲人：王凌,引言 标准的编制背景基本概念评价过程通用模型开发者用的过程需方用的过程评价者用的过程评价的策划和管理评价模块的文档编制,引言 标准的编制背景,软件工程 产品评价(GB/T18905-2002)标准是2002年批准发布的系列软件工程国家标准，由6个部分组成，它等同采用了ISO/IEC 14598系列国际标准。,标准的基本情况,分别是：第1部分：概述第2部分：策划和管理第3部分：开发者用的过程第4部分：需方用的过程第5部分：评价者用的过程第6部分：评价模块的文档编制,标准的发展概貌,ISO/IEC 9126-1991,9126-1软件质量模型9126-2外部度量

2、9126-3内部度量9126-4使用质量度量（20012004）,新ISO/IEC 9126系列,ISO/IEC 14598系列,14598-1概述14598-2策划和管理14598-3开发者用的过程14598-4需方用的过程14598-5评价者用的过程14598-6评价模块的文档编制（19982001）,信息技术 软件产品评价 质量特性及其使用指南,GB/T 16260-1995,软件产品评价过程的研究兴起于欧洲。由当时欧共体和欧盟自由贸易区的8个国家的十几个研究机构和公司组成一个联盟，共同对“欧洲信息技术研究和开发战略计划”（ESPRIT，1983-1998）下的“软件评估与认证程序”（S

3、COPE）项目开展研究。其主要成果是创立了软件产品的评价过程，从软件质量特性的角度探讨软件产品评价的方法和相关技术。该成果于1996年被ISO/IEC组织采纳为ISO/IEC 14598标准的蓝本。,标准的起源,产品评价过程在软件生存周期过程中的位置,编制目的,本系列标准是为了规范对软件产品质量特性进行评价的过程。它从软件的开发者、软件的需方和软件的独立评价者三种不同的角度分别给出了软件产品评价过程模型，便于使用者选择自己适用的评价过程。,GB/T 18905标准的结构,第1部分：概述（ISO/IEC14598-1：1999）第2部分：策划和管理（ISO/IEC14598-2：2000）第3部

4、分：开发者用的过程（ISO/IEC14598-3：2000）第4部分：需方用的过程（ISO/IEC14598-4：1999）第5部分：评价者用的过程（ISO/IEC14598-5：1998）第6部分：评价模块的文档编制（ISO/IEC14598-6：2001）,GB/T18905标准各部分的关系：,策划和管理,评价模块的文档编制,评价者用的过程,需方用的过程,开发者用的过程,评价：针对项目级的产品评价的管理：针对公司或部门级的组织,GB/T 18905标准的适用人员,开发者用的过程项目管理者、软件设计者、质量保证/控制/审核的负责人、软件维护者、软件的需方需方用的过程项目管理者、系统工程师、开

5、发及维护者、用户、软件的供方评价者用的过程检测实验室、软件的供方、需方、用户、认证机构,引言 标准的编制背景基本概念评价过程通用模型开发者用的过程需方用的过程评价者用的过程评价的策划和管理评价模块的文档编制,1 基本概念,1.1 软件质量和质量特性 1.1.1 软件质量 GB/T11457软件工程术语标准中，“软件质量”被定义为：a软件产品中能满足给定需要的性质和特性的总体。例如，符合规格说明。（软件的过程观点）b软件具有所期望的各种属性的组合程度。(软件的产品观点）c顾客和用户觉得软件满足其综合期望的程度。(软件的价值观点）d确定软件在使用中将满足顾客预期要求的程度。(软件的使用观点）,1.

6、1.2 质量特性（GB/T16260）外部质量和内部质量模型,使用质量模型,1.2 软件产品评价定义：根据特定的规程，对软件产品的一个 或多个特性执行评估的技术操作。按照一定的程序，通过测量、评审等方式确认软件产品与质量要求之间的符合程度。这种符合程度既与对软件产品的明确要求有关，也与隐含的要求有关。通过测量、评审软件产品的内部属性（如对中间产品进行静态测量）、外部属性（如产品执行时对其行为的测量），以及使用质量的特性来评价产品的质量。目的是通过对产品进行的系统性检查，确保产品满足用户明确和隐含的要求，达到产品所需的组合效用。,软件产品评价可与软件生存周期的基本过程结合来进行，作为确保软件质量

7、的一种手段。获取过程需方提出某个定制软件产品的外部质量需求，通过测量产品的外部质量特性来评价与质量需求的符合性，以确定是否验收该软件产品。购买某个产品时，可以通过产品评价来比较几种可替换的产品，以确保所选的软件能满足质量要求供应过程供方可利用产品评价结果来宣称其产品符合规定的质量准则。开发过程标识软件质量需求，评价中间产品以及早发现质量问题，预计中间产品质量，积累开发经验数据。运作和维护过程运行软件系统的组织通过质量评价来确认在不同运行条件下，软件产品满足质量要求的情况，以向维护人员提供对软件更改要求的反馈。,1.3 评价级别 评价级别定义了评价的深度和彻底性。可参照软件完整性级别来确定。信息

8、技术 系统及软件完整性级别（GB/T 18492-2001）根据系统风险的可容忍程度将系统和软件的完整性分为A、B、C、D四个等级。A为最高级，D为最低级。软件产品根据其用途的不同、应用环境的不同，可能会遇到安全、安全保密、经济和环境方面的风险，就会有涉及这些方面的完整性要求。如果给某个供评价的软件产品赋予一个软件完整性级别，那么，就可用完整性级别来选择评价级别。根据评价级别的高低来选择不同的评价技术。,不同方面的评价级别,引言 标准的编制背景基本概念评价过程通用模型开发者用的过程需方用的过程评价者用的过程评价的策划和管理评价模块的文档编制,2 评价过程通用模型,2.1 确立评价需求,输入：软

9、件或系统的质量需求，输出：评价需求。包括三个任务。1）确立评价目的 明确为什么进行评价，结合生存周期的基本过程来确定。,2)标识产品类型,确定要评价的软件是中间产品还是最终产品。这取决于产品所处的生存周期的阶段和评价的目的。,3）规定质量模型,实际上是确定评价需求。即确定要评价的软件产品的质量特性、子特性或质量属性。在需求分析时，既要确定产品的功能需求也要确定产品的质量需求。质量需求是产品评价的依据。这些质量属性的总体构成软件的质量模型。一般用分层树的结构描述。参照GB/T 16260中的质量模型分解质量特性，直到分解为可以测/度量的子特性或质量属性。综合考虑质量特性之间的相互关系和重要程度，

10、给出相应的优先级。,质量特性与权重,2.2 规定评价,输入：评价需求，输出：评价规格说明。包括三个任务。1）选择度量 根据评价的目的、质量特性以及如何既简便又经济地进行测量或度量来选择：内部度量、外部度量、使用质量度量或评价模块。若评价是为了进行比较，则选择的度量应是客观、可再现的和使用有效的标度。参照GB/T 16260给出的度量表或组织中的评价模块选择开发和设计更适用的度量元或评价模块,2）确立度量评定等级,确立质量评定等级是将产品满足质量需求的程度进行分类。分类方式有多种。,达到目标（良好）,最低可接受（合格）,3）确立评估准则,在针对评价需求选择了一组度量元或方法、确立了评定等级之后，

11、应确立对度量结果的判定评估准则。例，,功能性的评估准则,输入：评价规格说明，输出：评价计划。任务：制定具体的评价计划，描述评价所用的方法和评价活动进度表。例：第1章 引言(评价计划的目的、使用者、预期应用)第2章 评价目标（可按业务需要来阐述）第3章 可应用的质量特性（功能性、可靠性）第4章 列出优先级（针对特性的优先级）第5章 质量目标（可以测量的可量化的质量目标）第6章 进度表（里程碑、可交付内容等）第7章 职责(数据收集、任务分析、其他支持需求的实现、报告)第8章 测量类别（产品质量测量（性能、可靠性、可移植性等）、（过程质量测量（标准的有效性、工具的使用等）第9章 使用和分析数据（使用

12、的统计方法、表现技术）第10章 报告（报告的类型、未解决项 的处理）第11章 其他需求（采用的技术/方法、支持工具、依据标准等）,2.3 设计评价,2.4 执行评价,输入：评价计划，输出：评价报告、评价数据。包括三个任务。1）实施评价 记录评价过程和数据。2）与评估准则相比较 将测量值与预期的准则值相比较。3）评估结果 综述评价结果，将该结果与时间、成本等其他方面作比较，做出最终决定（接受/不接受产品、发布/不发布产品）。,引言 标准的编制背景基本概念评价过程通用模型开发者用的过程需方用的过程评价者用的过程评价的策划和管理评价模块的文档编制,3 开发者用的过程,3.1 适用范围 与软件产品的开

13、发同步进行的一种评价过程，一般由开发人员自己来实施。软件组织主要是针对软件项目来实施这一评价过程。评价的结果用来在开发期间监视和控制软件质量或预测最终产品的质量。,3.2 特点质量特性、质量属性的选择，以及在哪些开发活动中实施评价主要以组织和人员的软件开发经验为主；可以比较早地揭示软件产品的质量问题。最好将评价过程产生的数据收集起来，便于产生经验数据，建立数据分析系统。,3.3 开发者用的评价过程的活动,1）确立评价需求 标识产品的总的质量需求时要考虑：用户的要求组织的经验应用领域的经验软件完整性要求相关法律法规和标准的要求需方的其他方面要求如成本、进度约束、组织方面；排他性要求等。以组织和个

14、人经验为主。应确保需求在技术上是可行的、合理的、互补的、可达到的和可验证的。由有关方代表参加，最终总需求清单应征询各有关方的意见以达成共识。,2）规定评价 量化评价需求，生成评价规格说明。,3）设计评价 规定评价计划，该计划规定了要执行的动作规程。包括评价的时间节点、进度和职责、数据收集分析工具、必要的培训、测量精度和统计模型（数据输入要求、抽样策略）、可用的评价模块以及应急措施（如为防止测量结果是不确定的而使用的额外评价）。,4）执行评价,按照评价计划，收集内部（外部）实际测量值并与目标值进行比较。开发者应采取必要的措施保证数据收集的质量，利用收集工具及手工进行检验。充分利用组织在以往项目中

15、的经验。分析实际值，标识离群值，必要时采取应急动作。,5）对组织的反馈,向组织报告评价结果，产生评价报告。收集对本组织有用的数据，以便在其他项目中使用。评审和确认评价过程、指标和度量，改进评价模块。,引言 标准的编制背景基本概念评价过程通用模型开发者用的过程需方用的过程评价者用的过程评价的策划和管理评价模块的文档编制,4 需方用的评价过程,4.1 适用范围 针对现货软件产品（COTS）、定制软件产品或修改现有的软件产品进行的评价。产品可以是单独使用的产品，也可以是大型系统中的部件。4.2 评价目的 是否接受评价的产品，或从几个备选的产品选择某个产品。,4.3 需方用的评价过程需要考虑的问题,4

16、.3.1 确立评价需求时注意的问题 确立评价需求时，要对可能的评价需求的输入，包括系统需求、完整性级别需求、软件需求规格说明，以及可能有的其他方实施的评价结果进行分析。系统需求逐步分解，成为评价需求的主要输入条件；完整性级别需求是确立评价需求的依据，表示软件特性的取值范围，成为确立评价级别的基础；用与用户要求相关的外部质量描述的软件需求规格说明是需方获取需求的基础，也是评价需求的基础；必要时，可以承认由其他方实施的评价，包括：质量体系认证、过程能力评估、产品功能性评价或产品认证、组织内正式或非正式的评价等；其他的评价输入。,4.3.2 设计评价注意的问题 设计评价时，要考虑将软件的评价活动与软

17、件的获取过程结合起来。软件的获取过程包括：启动标识要获取的产品的软件需求、获取计划、验收策略和验收准则 招标（标书）的准备对获取需求制定规格说明和编制文档 合同的准备和更新选择供方、合同的准备和谈判以及合同的更改控制 对供方的监督在合同执行期间实施评价活动，达到软件产品的验收和交付使用 验收和完成在验收和交付最终软件产品的过程中实施的活动,需方在获取软件时要将产品的评价活动纳入到获取过程中。用评价所要求的软件需求规格说明构成标书要求的获取需求的基础；要有单独的初步评价活动以便预选软件产品和供方；评价所用的有关供方及产品信息的需求要在获取需求或在合同准备期间规定；评价活动可在监督合同执行期间，作

18、为要求的评价工作的一部分、产品开发工作的一部分、产品正式验收工作的一部分来执行，或在产品交付后执行。,4.3.3 评价活动的剪裁根据软件规模的不同、软件完整性要求的不同、评价目的的不同，需方用的评价过程可以进行适当剪裁。如：对于一般软件包，可参照GB/T 17544信息技术 软件包 质量要求和测试来评价 对于CASE工具，可以参照GB/T 18234信息技术 CASE工具的评价与选择指南标准来评价 有些软件产品，需进行第三方组织的正式评价 一般消费者只需得到带有少量评价文档、不太正式的评价 某些一般软件只需直接购买，不用准备合同。评价活动应具有灵活性，可参照GB/T8566剪裁指南和完整性级别

19、进行适当剪裁，避免无效劳动。,每个目标软件完整性的评价/获取活动的裁剪示例,评价现货软件产品的活动,1）确立评价需求 其关键任务包括：用GB/T 16260中的质量模型和定义来确立一组软件质量特性；根据质量特性重要程度的不同对确立的质量特性规定适当优先级；确立评价适用的完整性级别的体系基础，包括按照评价活动所要求的严格程度或细节确立需求及评价过程的输入和输出；确立要遵循的获取过程，以及确立如何将评价需求告知供方（招/投标、其他方式）；确立评价范围、用途和目标 考虑软件产品的应用范围、是否曾经做过第二方或第三方评价、是否计划将来实施评价,评价需求的内容包括：,用户及评价目标、任务、特性和产品的用

20、户环境；软件的完整性级别及评价过程要求的严格程度；法律法规需求，如产品标准的依从性；产品边界和接口，包括软件产品的接口需求（如需传递的数据类型、格式、接口访问机制、失效差错处理、计时问题、接口行为问题和接口状态的相关性和转换）；若产品是与其他部件或产品进行集成的较大系统的一部分，标识集成需求；软件质量需求，包括：强制要求的质量需求和可选的质量需求之间的区别；解释或理解需求所需的假设、例外、限制、排除情况或未解决的问题；,所有重要的质量特性及其优先的用户需求（如维护性比较重要，标识维护性需求）；所有设计约束和环境约束；如使用软件可能引起的功能和性能限制；所有管理性约束；如实施评价的资源和专业知识

21、、进度安排和预算、可能有的依存性或风险、关键性的假设，或其他一些假设；使用其他质量模型的理由；要评估的供方服务能力，即支持能力、应用开发能力和培训能力；要评估的特定需求，即技术的可行性或设计实现问题；相互协调并与完整性级别一致的评价需求；产品今后能否复用，文档能否支持今后的产品评价；获取过程，以及招标期间供方应提供的信息；由第二方或第三方实施的评价。,2)规定评价,根据评价需求选择适用的度量和评价方法，产生评价规格说明。评价规格说明的内容应包括：要评价的产品特性；外部度量，与软件质量的可测量方面相关（可根据用户经验来规定实际的阈值验收数量）；“使用质量”的度量，与包含软件的系统质量的用户观点相

22、关；度量准则，描述度量的可接受范围（可依历史数据为质量特性和完整性级别提供合理保证）；所用的评价模块；对评价需求覆盖程度，若认可由其他方完成的评价结论，则此评价需求是必须的；评价用到的检查表；帮助回答问题的示例列表；,要使用的测试用例；要收集和分析的数据及格式；要采用的特定评价方法，例如，评审或评估下列内容的一项或多项：软件产品的用户文档和技术文档（包括联机文档）；基于供方的课程和培训的软件产品评价；软件工程过程，包括中间软件产品；供方的产品运行历史；用户的产品运行历史；12.评估这些评价结果的方法；13.从类似产品中选择某个产品时，对评估结果进行排队的方法14.比较多个软件产品的评级方案。评

23、级方案可以按质量特性的优先级来设定权重。,评价方法有很多，根据评价目的、质量特性等方面的需要进行选择。如：对用户和产品技术文档的评审给予供方课程和评价的评审对软件工程过程的评估对供方产品运行历史的评审对用户运行历史的评审对供方的支持和维护能力及质量体系的评审原形方法对软件结构设计的分析（维护性）软件的故障树分析（安全性、可靠性)检测语法语义正确性的代码动态分析（可靠性）基准测试（效率）代码检查（功能性）可将评价方法进行组合，以确立产品的适用性。注意不要引起评价方法的相互冲突，评价方法的组合应覆盖所需的范围等。还需评审由其他方实施的评价。,3）设计评价设计评价的目的是产生评价计划。评价计划应包括

24、：产品供方或第三方是否愿意或能够提供对文档、设备、工具、软件、课程等内容及对相关专业人员的访问，与此相关的成本是多少访问各种机密或专有信息的条件实施评价所需的专业知识的成本、测试环境的成本可能的预先测试评价职责和进度安排评价方法的限制和各方法的成本评价方法之间的先后顺序评价活动与获取活动的连接点评价技术和规程、输入输出信息和文档及文档的格式要求接受与拒绝准则、例外情况处理遵循的原则评价工具和评价规程,4）执行评价 按照评价计划执行评价活动、记录和分析评价结果、做出评价结论。评价记录应包括：评价的执行步骤（包括所用的数据、安装过程、各种状态信息）、中间评价结果（对问题的解答和答案的出处）、产品版

25、本号 评价的各种限制、约束、缺陷或例外 评价者及他们的资格 各产品版本及相应输入间的差别 对评价缺陷的解决办法 评价结论用报告形式给出，说明该软件产品对特定的系统完整性级别和评价需求，是否适合预期应用，为最终决定是否购买该产品提供依据。,评价现货软件产品的流程图示例,评价定制的软件和修改现有的软件产品的活动,评价定制软件或修改现有软件产品的流程图示例,引言 标准的编制背景基本概念评价过程通用模型开发者用的过程需方用的过程评价者用的过程评价的策划和管理评价模块的文档编制,5 评价者用的过程,5.1 适用范围 一般由独立的第三方产品评价组织来实施 评价可能涉及的各方有：-请求者：软件开发者、供方、

26、需方、用户、系统集成者-评价者：第三方测试实验室、软件生产或分销组织中测试实体、购买或使用组织中的测试实体、系统集成组织中的测试实体、在产品间进行比较的组织,5.2 评价遵循的原则可重复性由同一评价者按同一评价规格说明对同一产品进行重复评价应产生同一种可接受的结果；可再现性由不同评价者按同一评价规格说明对同一产品进行评价应产生同一种可接受的结果；公正性评价应不偏向任何特殊的结果；客观性评价结果应是客观事实，不带有评价者的感情色彩或主观意见。,5.3 评价过程的特点 评价者应请求者的要求实施评价，因而评价需求一般由请求者提出。请求者提供待评价的产品、产品描述和产品组成部件（包括相关文档）。评价者

27、保留评价过程输出（包括评价需求、规格说明、评价计划、评价记录、评价报告等）。评价过程由请求者和评价者共同实施的一组活动构成。评价一般在测评实验室进行，也可以在产品的开发或运行现场进行（要保证评价的公正性）,评价过程各活动之间的信息流,5.4 评价过程的职责要求,请求者的职责要求-对评价的软件产品拥有合法权利-为标识和描述产品提供必要信息-提供初始评价需求-提出对评价信息的保密要求-必要时在开发者与评价者之间起中介作用-必要时向评价者提供对运行设备的访问-必要时确保及时提供软件产品、部件、文档和其他资料及其他必要支持,评价者的职责要求-检查请求者是否拥有对评价产品的合法权利-按要求对请求者的所有

28、信息保密-提供有资格的、经过培训的评价人员实施评价-提供适当的评价工具和技术-按评价需求实施评价-保留所有评价工作记录-及时交付评价报告-按申请者要求的程度使评价过程适当可视 评价者应属于一个组织，该组织的运作体系应满足GB/T 15481-2000的要求，以保证评价活动符合可重复性、可再现性、公正性、客观性的要求。,5.5 评价者用的评价过程的活动,输入：请求者的需求-请求者提出最初的评价需求，说明评价理由和评价的覆盖范围，提供产品描述和相关部件-评价者分析评价原因，描述评价需求，说明保密范围和严格度-评价者与请求者就评价需求达成共识，确定评价需求，并予以批准输出：双方共同认可批准的评价需求

29、,1）确立评价需求,2）规定评价输入：评价需求、产品及部件描述、预先确定的评价规格说明-标识要评价的产品，规定评价范围 请求者将要评价的产品、产品部件及的有关的产品描述文档清单提交评价者，以便评价者了解产品结构和用途-规定评价所用的技术和方法 评价者把评价需求分解到各个产品部件，规定对部件的特性/子特性/属性进行的测量-对照评价需求验证评价规格说明 评价者检查所描述的部件是否提供了执行评价的所有必要信息，规定的测量和验证是否充分满足了评价目标-批准评价规格说明 将评价规格说明作为请求者和评价者之间的联合评审予以批准。输出：双方共同批准的评价规格说明。必要时以合同方式确认。,3）设计评价输入：评

30、价规格说明、评价方法-把评价方法编成文档和起草计划 评价者分析评价规格说明中规定的有关测量或验证的技术约束条件，标识使用的工具或评价方法，或者编制适当的评价模块，标识对测量结果的解释规程，标识可能的产品运行环境-优化评价计划 评审评价计划，避免重复劳动-根据可用资源安排评价动作的进度 考虑人员、工具等资源来安排进度，并与请求者达成一致，规定评价需提交的介质形式、拷贝数量、评价者可能需要的培训等-批准评价计划 将评价计划作为请求者和评价者之间的联合评审予以批准输出：评价计划,4）执行评价输入：评价计划、评价工具、产品部件-按照评价计划，执行评价动作-管理请求者提供的产品部件：登记产品、部件、相关

31、文档-管理评价活动产生的数据：记录中间评价数据-管理评价活动使用的工具：标识和记录评价工具-管理可能的现场评价：保证评价结果和数据的客观、公正和保密-管理可能使用的特定评价技术：记录可能测试配置、环境等输出：评价报告草案、评价记录注：应由不直接参与评价的人员评审评价结果，以保证公正性。,5）做出评价结论输入：评价报告草案、评价记录-联合评审评价报告 评价者将评价报告草案提交请求者，使其有机会提出意见，并将意见记入评价报告的专门章节-提交正式的评价报告-处置评价数据和文档 评价者按保密规定保存评价数据，将供评价的文档退还请求者输出：正式的评价报告,示例：某第三方测试实验室对某软件产品进行评价的报

32、告,评 价 报 告1标识 略。2评价需求2.1 产品应用领域略。2.2 产品用途生命救援方面。2.3 质量需求2.3.1 质量特性及其评价等级,表1 软件质量特性评价等级表,注：该产品只对其功能性、可靠性、效率和可维护性这四个质量特性进行评价，由于它的完整性要求较高，因此评价等级均为A级。,2.3.2 其它质量需求 无。3评价规格说明 略。4评价方法 本节列出评价使用的评价项（特性、子特性等），并描述根据评价对象采用的具体评价方法以及评价的解释。根据公式(1)计算该软件各质量特性及其子特性的测量值，根据测量值确定各质量特性评价等级。,(1),其中，Vi表示第i个质量特性的测量值，Vsij表示第

33、i个质量特性的第j个子特性的测量值，Vijk表示第i个质量特性的第j个子特性的第k个度量项的测量值，Nsi表示第i个质量特性的子特性数量，Nmij表示第i个质量特性的第j个子特性的度量项数量，sij表示第i个质量特性的第j个子特性的加权值，mijk表示第i个质量特性的第j个子特性的第k个度量项的加权值。,这里采用01评分法给出sij和mijk。目前，已经由若干软件质量评测专家给出了软件质量特性及其子特性的评分。再根据公式(2)计算出各质量特性及其子特性的加权系数。其中，K为参加评价人员数。具体计算结果见表2和表3。,（2）,表2 质量特性加权系数表,表3 质量子特性加权系数表,注：根据该产品的

34、用途，专家给出了要评价的质量特性和子特性的加权系数。说明每个特性和子特性均有不同的权重。,5评价结果和建议,表4 软件综合评价表,评价结果雷达图,说明和建议 软件综合评价是从多侧面对软件进行综合性评价。该软件的平均评分为0.935，等级为优。,表5 软件综合评价结论,引言 标准的编制背景基本概念评价过程通用模型开发者用的过程需方用的过程评价者用的过程评价的策划和管理评价模块的文档编制,6 评价的策划和管理,6.1 目的 便于软件产品评价的支持机构（部门）开展评价技术开发、组织管理、资源利用、成果转移等管理工作，有助于在组织和项目两个层面上协助和管理软件产品的评价活动。6.2 主要任务-获取相关

35、的国际国内标准和技术信息，以及必要时专家的支持-制定基于项目需求和组织需求的适当内部标准及工具-制定为评价设立基准的准则-评审软件获取和开发的效益和质量-收集和分析评价结果，并通过组织内的数据库加以分发-基于组织内部和各评价项目的经验，为技术转移提供便利-支持评价项目及各自的项目管理者评价的支持机构可以是评价组织内部的，也可以是外部的一个机构或部门。,6.3 评价的支持机构和评价项目之间的关系,6.4 组织级的管理,包括：-制定和实施改进软件评价及支持技术的整体计划-实施评价技术，将确认的评价模块纳入配置控制下，编制评价模块文档-为技术转移准备培训大纲、工具及环境-评估软件评价的技术-管理评价

36、经验,6.5 项目级的管理,包括：-针对每个项目制定定量的评价计划-研讨评价计划的技术细节-对评价项目的情况适时进行监督-在评价项目结束时收集评价结果备查,引言 标准的编制背景基本概念评价过程通用模型开发者用的过程需方用的过程评价者用的过程评价的策划和管理评价模块的文档编制,7 评价模块的文档编制,7.1 评价模块的术语定义 用于测量软件质量特性、子特性或属性的评价技术包。包括：评价方法和技术、对评价的输入、待测量和待收集的数据、支持规程和工具。7.2 编制评价模块的目的-使评价组织能够一致地进行软件质量的度量-便于评价组织管理评价活动和评价技术-便于评价数据的收集和管理,7.3 评价模块的主

37、要内容,1 前言和引言 提供评价模块的正式信息，介绍评价模块中的评价技术2 范围 标识评价模块可以评价的特性、子特性或属性、评价级别、评价技术和适用范围3 引用文件 提供相关的引用标准4 术语和定义 提供评价模块使用的术语定义5 输入和度量 规定评价需要的输入，使用的度量，定义待收集的数据和待计算的测度6 结果解释 规定测度的含义，测度的映射算法和报告内容附录 应用规程 所需的资源、技术术语、评价细则和产生的内部文档,评价模块的示例：故障密度,1 引言 本评价模块用于确定程序的故障密度。由于软件中存在的潜在故障会引起频繁运行失效和降低产品的可靠性，因此，需要在设计和测试期间检测这些潜在的故障，

38、并在程序投入运行前确保故障密度在规定的阈值以下。通常软件产品中遗留的故障数难以统计。但通过使用模型和故障检测的历史数据，可以估计这个故障数。故障密度即可利用这个估计数计算出来。一般估计规程如下：1）选择一个合适的可靠性增长模型（RGM），例如，采用指数型的RGM和S形的RGM；2）在测试周期的特定时刻，记录所测故障的累积数目；3）要求用可靠性增长模型RGM参数方程拟合一组数据记录的曲线方程；4）当RGM公式中的时间（t）趋于无穷时，可计算出潜在故障的估计数。,2 范围2.1 特性 可靠性 成熟性 故障密度2.2 评价级别 B级。2.3 技术 使用可靠性增长建模技术。最终软件产品中的故障数使用可

39、靠性增长模型作出预测。2.4 适用性 1）通常用在系统测试期间，适用于所有类型的程序设计语言；2）当必须将故障密度值与用不同程序设计语言写的程序中的其他值做比较时，规模值应标准化。3 引用文件,4 术语和定义 下列定义适用于本评价模块：4.1 故障 fault 计算机程序中的不正确的步骤、过程或数据定义。4.2 失效 failure 产品完成所要求功能的能力的终止，或在原先规定的限制内没有能力完成。4.3 LOC（代码行数）(Lines of Code)代码行数。4.4 EEMOC（出错代码行数）(Erroneous Lines Of Code)检测到失效并加以修改的代码行数。,5 输入和度量

40、5.1 评价的输入 下列来源用作评价的输入：1）产品部件：源代码；2）产品信息：程序测试报告、程序评审报告、程序验证报告。5.2 数据元素 为便于应用评价技术，必须收集下列数据元素：1）检测到的故障数（ELOC）；2）每个失效的检测时间。时间的测量方法必须一致，例如，CPU时间或日历时间；3）无注释的代码行数（NCLOC）。5.3 度量和测度 故障密度值用下面公式计算：FDV=(EELOC-ELOC)/NCLOC,6 结果解释6.1 测度的映射 FDV（本例中没有度量映射）。组织内标度的试验性数据源：FDV 10-4 优秀（高于要求）10-4 10-2 不合格（不可接受）注：必须依据应用阶段或

41、软件领域来剪裁阈值。6.2 报告 作为应用评价模块的结果报告下列信息：1）源代码的标识；2）故障密度值：FDV；3）相应的评级（优秀、良好、合格、不合格）。,7 应用规程7.1 所用技术术语的定义 RGM（可靠性增长模型）Reliability Growth Model 可靠性增长模型用于估计出错的代码行数。7.2 需要的资源 使用评价模块时，下列资源必须是可用的：7.2.1 需要的软件工具 1）LOC计数工具；2）改过的代码行的计数工具；3）可靠性数据采集工具和分析工具（可选）。7.2.2 软/硬件平台 无特殊需求。,7.2.3 测试装备或其他设备 无特殊需求，但建议使用可靠性数据采集和分析

42、工具。7.2.4 技能和资格 需要有使用RGM方面的知识。7.2.5 应用的人力方面 大部分工作与对失效进行测试和记录有关。若采用可靠性数据采集工具，则RGM的应用和FDV计算只需要有限的工作。7.2.6 其他特殊资源 无特殊需求。,7.3 评价细则 1）样本的选择 选择样本源代码。采样率应超过一半。2）原始数据的生成 失效数据从测试报告中提取。若测试报告不可用，则进行测试。为了采用可靠性增长模型RGM，需要最 小的测试时间为XXX。对每一个失效，记录其出现的位置和时间。用修改时间计数每个样本的修改的ELOC和总的NCLOC。3）算法 通过使用可靠性增长模型RGM，估计潜在的ELOC数和EEL

43、OC数。计算故障密度值：FDV=(EELOC-ELOC)/NCLOC 注意：这里必须详细解释如何使用RGM模型或工具，或者，必须提供对用于估计的软件工具和手册所做的引用。4）工作和最终文档的保留要求 每周做一次测试，在测试阶段做趋势分析。动作：若故障密度的计算值大于一些规定值（评为不合格），则再次进行源代码评审、重新测试和调试，并且再次计算故障密度。,7.4 评价模块的开发,评价模块的开发可以针对一个或多个质量特性、子特性或质量属性。开发过程通常有五个步骤：标识评价模块的需求 标识和确定评价模块所用的质量模型、要评价的质量特性/子特性/属性、评价的严格 程度和适用范围。确定评价模块的规格说明 确定可用的评价技术和评价输入、可用的度量/测量方法，及需要何种数据元素集合。制定评价规程 结合评价规格说明，考虑如何执行评价、如何解释度量和评价数据、如何验证评价等程序性内容，并估计评价所需的资源。描述评价规程 按照评价模块的格式描述评价规程，形成初步的评价模块文档。确认和验证评价模块 按照评价模块规格说明评审（验证）开发的评价模块。由熟悉评价技术的专家确认。由不同小组的人员在不同的环境下试用评价模块进行验证。将试用得到的经验反馈给开发小组以改进评价模块。,小结：,了解软件产品评价过程通用模型掌握有哪些具体的评价过程理解评价过程与质量模型的关系懂得评价模块的作用,谢谢大家!,