第6章质量管理.doc

第6章 软件质量管理本章目录 一、 课程大纲与内容二、 练习三、 可扩展知识点和练习一、课程大纲与内容6、软件质量管理6.1 ISO标准6.1.1 GB/T162606.1.2 GB/T189056.1.3 GB/T155326.2 CMMI6.3配置管理6.4风险分析6.4.1软件测试与商业风险6.4.2什么是软件风险6.4.3 软件风险分析6.4.4 软件测试风险6.5软件测试成本管理6.5.1 测试费用有效性6.5.2 测试成本控制6.5.3 质量成本6.5.4 缺陷探测率-6、软件质量管理6.1 ISO标准标准：为在一定的范围内获得最佳秩序，对活动或其结果规定共同的和重复使用的规则或特性的文件，称为标准。该文件经协商一致并经一个公认机构的批准。标准应以科学、技术和经验的综合成果为基础，以促进最佳社会效益为目的。标准化机构是指制定、发布和管理各种标准的国际组织区域性组织、政府或非政府组织、行业组织等。如：国际标准化组织（ISO）、国际电工委员会（IEC）、国际电信联盟（ITU）。在信息技术领域，电气电子工程师学会（IEEE）、Internet协会（ISOC）、国际Web联盟（W3C）。标准一般可分为国际标准、行业标准、区域标准和企业标准等。国际标准：是指由国际联合机构制定和发布，提供各国参考的标准。国家标准：是指由政府或国家级的机构制定或批准，适用于全国范围的标准。行业标准：是指由行业机构、学术团体或国防机构制定，并适用于某个业务领域的标准。区域/地方标准：是指有区域性国际联合机构制定和发布，提供区域内各国参考和执行的标准。企业标准：是指一些大型企业或机构，由于工作需要制定的适用于本企业或机构的标准。我国在国家标准管理办法中规定国家标准实施5年内要进行复审，即国家标准有效期一般为5年。现阶段，在我国软件测试领域使用的标准是：GB/T 16260-2006 软件工程 产品质量GB/T 18905-2002 软件工程产品评价GB/T 15532-2008 计算机软件测试规范6.2 CMM/CMMI/TCMM软件过程与软件开发能力的概念密不可分。软件过程是指人们用于开发和维护软件机器相关产品的一系列活动，包括软件工程过程和软件管理过程。软件开发能力是指一个特定的软件机构通过遵循其软件过程能够实现预期结果的程度。软件过程管理的目的就是要提高软件开发能力，为此，应首先了解软件能力成熟度模型。6.2.1 软件能力成熟度模型软件过程和软件开发能力的评估，通常采用软件能力成熟度模型（Capability Capability Model）。自从1994年SEI正式发布软件CMM以来，相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。虽然这些模型在许多组织都得到了良好的应用，但对于一些大型软件企业来说，可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。这时他们会发现存在一些问题：1、不能集中其不同过程改进的能力以取得更大成绩2、要进行一些重复的培训、评估和改进活动，因而增加了许多成本3、遇到不同模型中有一些对相同事物说法不一致，或活动不协调，设置抵触于是希望整合不同CMM模型的需求产生了。能力成熟度模型集成（Capability Maturity Model Integration）CMM软件评估模型是从近代质量管理理论与实践基础上发展起来的。CMM把软件开发过程的成熟度由低到高分为5级，即初始级、可重复级、已定义级、已管理级和优化级。随着CMM等级的提高，它逐步降低了软件开发风险，缩短了开发时间，降低了软件开发的人力物力成本，降低了灾难性错误发生率，提高了软件质量。CMM评估等级的提升会大幅度提高软件开发能力，有助于客户特别是大公司对该软件企业建立信心，并向该软件企业下订单采购软件产品。CMM的每个等级由不同的关键过程域（Key Process Area）组成，每个关键过程域包括一系列的关键实践。关键过程域是指互相关联的若干软件实践活动和有关基础设施的一个集合。关键实践则是指对关键过程域的实践其关键作用的方针、规程、措施、活动，以及相关基础设施的建立。等级特征关键过程域（KPA）1、初始级软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式（消防式）的2、可重复级建立了基本的项目管理过程来跟踪费用、进度、功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功需求管理软件项目计划软件项目跟踪和监控软件子合同管理软件质量保证软件配置管理3、已定义级已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、裁剪的标准软件过程来开发和维护软件组织级过程焦点组织级过程定义培训大纲集成软件管理软件产品工程组间协调同行评审4、已管理级收集对软件过程和产品质量的详细度量，对软件过程和产品都有定量的理解与控制定量过程管理软件质量管理5、优化级进程的量化反馈和先进的新思想、新技术促使过程不断改进缺陷预防技术变更管理过程变更管理CMM作为评估软件过程成熟度的依据，为软件过程评估和软件能力成熟度评估建立了一个共同的参考框架。6.2.2 软件过程与软件能力成熟度评估软件过程评估的目的是确定一个软件机构的当前软件过程的状态，找出机构所面临的急需解决的与软件过程有关的问题，进而有步骤地实施软件过程改进，使机构的过程能力不断提高。软件开发能力评估的目的是识别合格的、能够完成软件工程项目的承制方，或者监控承制方现有的软件工作中软件过程的状态，进而提出承制方应该改进之处。软件过程与软件能力成熟度评估的具体步骤如下。l 建立评估组。评估组的成员应当是具有丰富软件工程和管理知识的专业人员，并且应当接受CMM基本概念和评估方法细节方面的培训。l 填写提问单。让待评估单位的代表完成能力成熟度提问单的填写和其他诊断工具的要求。l 响应分析。评估组对提问单进行统计分析，定义必须做进一步探查的区域。待探查的区域与CMM的关键过程域相对应。l 现场考察。响应分析之后，评估组应考察被评估单位的现场，以便了解该现场所遵循的软件过程。CMM中的关键过程域和关键实践对评估组成员在提问、倾听、复审和综合各种信息方面提供指导。评估组运用专业性的判断确定现场关键过程域的实施是否满足相关的关键过程域的目标。l 提出关键过程域剖面图。对于软件过程评估，该调查发现清单和KPA剖面图可以作为提出过程改进建议的基础；对于软件能力成熟度评估，该调查发现清单和KPA剖面图可以作为软件采购单位所做风险分析的一部分。TCMM等级特征初始级：测试处于一个混乱的状态，缺乏成熟的测试目标，测试处于可有可无的地位还不能把测试同调试分开；编码完成后才进行测试工作；测试的目的是表明程序没有错；缺乏相应的测试资源 阶段定义级：测试目标是验证软件符合需求，会采用基本的测试技术和方法测试被看做是有计划的活动测试同调试分开在编码完成后才进行测试工作 集成级：测试不再是编码后的一个阶段，而是贯穿在整个软件生命周期中。测试建立在满足用户或客户的需求上 具有独立的测试部门；根据用户需求设计测试用例；有测试工具辅助进行测试工作；没有建立起有效的评审制度；没有建立起质量控制和质量度量标准 管理和度量级：测试是一个度量和质量的控制过程。在软件生命周期中评审被作为测试和软件质量控制的一部分 进行可靠性、可用性和可维护性等方面的测试；采用数据库来管理测试用例；具有缺陷管理系统并划分缺陷的级别；还没有建立起缺陷预防机制，且缺乏自动地对测试中产生的数据进行收集和分析的手段 优化级：具有缺陷预防和质量控制的能力；已经建立起测试规范和流程，并不断地进行测试改进 运用缺陷预防和质量控制措施；选择和评估测试工具存在一个既定的流程；测试自动化程度高；自动收集缺陷信息；有常规的缺陷分析机制 6.3 配置管理软件配置管理是在软件的整个生命周期内管理变化的一组活动，这组活动用来：1）标识变化2）控制变化3）确保适当地实现变化4）向需要知道这类信息的人报告变化软件配置管理的目标就是，使变化更正确且更容易被适应，在必须变化时减少所需花费的工作量。软件配置管理活动主要包括5项任务：对象标识、版本控制、变化控制、配置审计、配置报告。1. 对象标识为了控制和管理软件配置项，必须单独为每个配置项命名，然后用面向对象方法组织它们。在设计标识软件对象的方式时，必须认识到对象在整个生命周期中一直都在演化，因此，设计的标识方式必须能无歧义地标识每个对象的不同版本。2. 版本控制版本控制是指联合使用规程和工具，以管理在软件工程过程中所创建的配置对象的不同版本。借助于版本控制技术，用户能够通过选择适当的版本来指定软件系统的配置。3. 变化控制对于大型软件开发项目来说，无控制的变化将迅速导致混乱。变化控制把人的规程和自动工具结合起来，以提供一个控制变化的机制。4. 配置审计配置审计作为对正式技术复审的补充，主要审计配置对象的哪些通常不再技术俯身中考虑的特征。5. 配置报告配置状态变化对大型软件开发项目的成功有重大影响。软件配置变化报告用于加强相关人员的通信与协调。6.4 风险分析风险是指可能发生的损失、损害及危险。开发任何工程项目都可能存在风险，软件项目的开发也是如此。软件开发中应当考虑到与风险有关的以下问题：1）风险是否会导致软件项目的失败2）用户需求、开发技术、环境、目标机器、时间、成本等因素的改变对风险有什么影响3）采取什么措施才可以减少或避免风险软件项目中的风险需求风险l 已经纳入基线的需求在继续变更l 需求定义不准确，进一步的定义会扩展项目范畴l 增加额外的l 产品定义含糊的部分比与预期需要更多的时间l 在做需求中客户参与不够l 缺少有效地需求变化管理过程计划编制风险l 计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致l 计划是优化的，是“最佳状态”，但计划不现实，只能算是“期望状态”l 计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上l 产品规模（代码行数、功能点、与前一产品规模的百分比）比估计的要大l 完成目标日期提前，但没有相应地调整产品范围或可用资源l 涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多组织和管理风险l 仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长l 低效的项目组结构降低生产率l 管理层审查、决策的周期比预期的时间长l 预算削减，打乱了项目计划l 管理层作出了打击项目组积极性的决定l 缺乏必要的规范，导致工作失误与重复工作l 非技术的第三方的工作（预算批准、设备采购批准、法律方面的审查、安全保证等）时间比预期的延长人员风险l 作为先决条件的任务（如培训及其他项目）不能按时完成l 开发人员和管理层之间关系不佳，导致决策缓慢，影响全局l 缺乏激励措施，士气低下，降低了生产能力l 某些人员需要更多的时间适应还不熟悉的软件工具和环境l 项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低l 由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作l 不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性l 没有找到项目急需的具有特定技能的人开发环境风险l 设施未及时到位l 设施虽然到位，但不配套，如没有电话、网线、办公用品等l 设施拥挤、杂乱或者破损l 开发工具未及时到位l 开发工具不如预期的那样有效，开发人员需要时间创建工作环境或者切换新的工具l 新的开发工具的学习期比预期的长，内容繁多客户风险l 客户对于最后交付的产品不满意，要求重新设计和重做l 客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做l 客户对规划、原型和规格的审核决策周期比预期的要长l 客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更l 客户答复的时间（如回答或澄清与需求相关问题的时间）比预期长l 客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作产品风险l 矫正质量地下的不可接受的产品，需要比预期更多的测试、设计和实现工作l 开发额外的不需要的功能，延长了计划进度l 严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作l 要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作l 在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题l 开发一种全新的模块比预期花费更长的时间l 依赖正在开发中的技术将延长计划进度设计和实现风险l 设计质量低下，导致重复设计l 一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能l 代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作l 过高估计了增强型工具对计划进度的节省量l 分别开发的模块无法有效集成，需要重新设计或制作过程风险l 大量的纸面工作导致进程比预期的慢l 前期的质量保证行为不真实，导致后期的重复工作l 太不正规（缺乏对软件开发策略和标准的遵循），导致沟通不足，质量欠佳，甚至需要重新开发l 过于正规（教条地坚持软件按开发策略和标准），导致过多耗时与无用的工作l 向管理层撰写进程报告占用开发人员的时间预期的多l 风险管理粗心，导致未能发现重大的项目风险风险管理已经称为软件工程项目管理的一项重要内容，其主要活动包括风险识别、风险分析（风险估算与评价）、风险应对（风险防范）和风险控制等。l 风险识别首先要识别风险来源，由此可以预测风险事件的发生并识别风险症状。从宏观上来看，风险可以分为项目风险、技术风险、商业风险。项目风险包括潜在的设计、实现、接口、检验和维护方面的问题，而商业风险主要来源于市场。风险识别的重要工作就是将潜在的风险找到，并在文档中体现出来。l 风险估计风险分析就是估算与评价风险的过程，其目标是帮助项目管理人员决定在具体的风险面前采取什么态度：应对、接受、忽略。对于风险应分析其发生的可能性和其可能带来的破坏性。l 风险应对风险应对包括确定风险策略和制定风险应对计划。风险策略是指应对某种具体风险的策略，如规避风险、减轻风险或接受风险等。风险应对计划主要包括风险管理计划和应急计划等。l 风险控制风险控制活动主要包括以下任务：随时追踪风险已经、正在和将要发生的变化；预测和判断风险的应对是否会引起更新的风险发生；对用于风险管理的资源配置进行调整；调整风险应对计划；采取临时紧急应变措施等。6.5 成本管理有效的测试方法可以识别和评价软件的各种风险，能把这些防线缩小到测试范围内，我们可以承受的风险，并制定测试计划实现这个目标。6.5.1 测试费用有效性“太少的测试是犯罪，而太多的测试是浪费”对风险测试得过少，会造成软件的缺陷和系统的瘫痪；而对风险测试得过多，就会使本来没有缺陷的系统进行没有必要的测试，或者是对轻微缺陷的系统所花费的费用远远大于他们给系统造成的损失。测试费用的有效性，可以用测试费用质量曲线来表示。随着测试费用的增加，发现的缺陷也会越多，两线相交的地方是过多测试开始的地方，这时，排除缺陷的测试费用超过了缺陷给系统造成的损失费用。6.5.2 测试成本控制测试工作的主要目标是使测试产能最大化，也就是，要使通过测试找出错误的能力最大化，而检测次数最小化。测试的成本控制目标是使测试开发成本、测试实施成本和测试维护成本最小化。作为产品发布每一新版本而进行的重复性的测试所需要的成本是主要考虑的问题。测试实施成本组成部分包括：测试准备成本、测试执行成本和测试结束成本。1、测试准备成本控制测试准备成本控制的目标是使时间消耗总量、劳动力总量，尤其是准备工作所需要的熟练劳动力总量最小化。准备工作一般包括：硬件配置、软件配置、测试环境建立，以及测试环境的确定等。2、测试执行成本控制测试执行成本控制的目标是使总执行时间和所需要的测试专用设备尽可能地减少。执行时间要求操作和用户进行手工操作执行测试时间应尽量减少，同时对劳动力和所需的技能也要尽量减少。3、测试结束成本控制测试结束成本的控制是进行测试结果分析和测试报告编制、测试环境的清除与恢复原环境所需的成本，使所需的时间和熟练劳动力总量减少到最低限度。