第6章质量管理

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