《软件质量保证》PPT课件.pptx

第八章软件质量保证,ITANY,本课程的主要内容,软件质量模型ISO9000和CMM/CMMI软件质量铁三角质量保证与SQA,本章目标,理解软件质量模型了解CMM/CMMI和ISO9000理解质量铁三角了解质量保证与SQA,第一部分,质量保证与SQA软件质量模型CMM/CMMI和ISO9000软件质量铁三角,软件质量的定义,“软件质量”（ISO9126）：软件满足规定或潜在用户需求特性的总和。包括“内部质量”、“外部质量”和“使用质量”三部分。“软件质量”（ISO14598）：软件特性的总和，软件满足规定或潜在用户需求的能力。,软件质量的理解,软件质量是一个复杂的概念，不同的人从不同的角度来看待软件质量问题会有不同的理解用户视角：质量就是满足客户的需求开发者的视角：质量就是与需求说明保持一致产品视角：质量就是产品的内在特点价值视角：质量就是客户是否愿意购买项目经理视角：质量就是能“令人满意”地工作以完成预期功能的软件产品,质量保证(QA),质量保证（QA：QualityAssurance）：质量保证的重要工作是通过预防、检查与改进来保证软件质量。QA通过“全面质量管理”和“过程改进”的原理开展质量保证工作虽然在QA的活动中也有一些测试活动，但QA所关注的是对软件质量的检查与度量。QA的工作是对软件生命周期的管理以及验证软件是否满足规定的质量和用户需求，因此主要着眼于软件开发活动中的过程、步骤和产物，而不是对软件剖析，找出问题或评估。QA的注意职责是检查和评价当前软件开发的过程，找出过程改进的方法，已达到防止软件缺陷出现的目标,QA的组织结构,在国内大多数企业，QA组织结构可划分为三类：职能结构、矩阵结构以及两者结合而成的柔性结构。职能结构在职能结构中，各个职能部门设立自己的QA岗位，位于高级经理之下，独立于项目组。QA直接对高级经理负责，但业务上需要向项目经理汇报，属于项目成员。职能结构的优点QA容易融入项目组，易于发现实质性的问题，解决问题也很快捷。职能结构的缺点各职能部门相对独立，部门之间的经验缺乏交流和共享，还可能出现对过程、方法和工具研究的重复性投资。在这种组织结构下，由于高级经理专注于业务的发展，QA的职业发展容易受到忽视，难于接受到应有的培训和提升。,QA的组织结构,矩阵结构在矩阵结构中，设立了专门的QA部门，与各业务职能部门平级。QA隶属于QA部，行政上向QA经理负责，业务上向业务部门的高级经理和项目经理汇报。在这种组织结构中，由QA部经理对QA考评和授权，有利于保证QA的独立性和评价的客观性，也有利于确保组织的长期利益与项目（或个人）的短期利益之间的平衡。QA资源为所有项目所共享，可按照项目优先级动态调配，资源利用更充分，但也可能出现资源竞争冲突。此外，QA部门对QA流程的改进、QA知识的管理、QA人员的发展负责，并可集中资源进行QA平台的建设，以防止重复性的投资。但另一方面，在矩阵结构中，QA难于融入项目组，发现的问题也很少能得到及时有效的解决。柔性结构柔性结构是职能结构和矩阵结构的混合形态，在职能结构的基础上建立了QA组。,QA的岗位职责,在CMMI中，QA的主要工作是过程评审和产品审计。从实践经验来看，QA只完成这两项工作很难体现出QA的价值。为了让QA组织的产出大于组织的投入，实现增值，就应该根据企业需要适当增加QA的职责，比如过程指导、过程度量和过程改进等。过程指导主要是项目前期辅助项目经理制定项目计划（包括辅助定义或修改项目过程和过程模型、协助项目估计、建立项目验收准则、设置质量目标等），对项目成员进行过程和规范的培训以及在过程中进行指导等。过程度量（包括产品度量）在CMMI中已经成为CMMIML2级中一个单独的过程域，但却是对所有过程的一个共性要求。特别是成熟度越高，对度量的要求也越高，难度也越大。这就要求有专业的人员来负责，QA就是一个很好的选择。主要职责包括收集、统计、分析度量数据，以支持管理信息需求。过程改进在CMMI中主要是EPG的职责。但事实上，QA更接近于过程实施的环节，更了解过程运行的情况，也就更容易发现“木桶中最短的那块”。同时，QA也是改进过程实施的重要推动力量。,软件质量保证（SQA）,SQA活动软件质量保证（SQA）是一种应用于整个软件过程的活动，它包含：一种质量管理方法有效的软件工程技术（方法和工具）在整个软件过程中采用的正式技术评审一种多层次的测试策略对软件文档及其修改的控制保证软件遵从软件开发标准度量和报告机制,软件质量保证（SQA）,SQA的工作内容和工作方法计划针对具体项目制定SQA计划，确保项目组正确执行过程。制定SQA计划应当注意如下几点：有重点：依据企业目标以及项目情况确定审计的重点明确审计内容：明确审计哪些活动，那些产品明确审计方式：确定怎样进行审计明确审计结果报告的规则：审计的结果报告给谁审计/证实依据SQA计划进行SQA审计工作，按照规则发布审计结果报告。注意审计一定要有项目组人员陪同，不能搞突然袭击。双方要开诚布公，坦诚相对。审计的内容：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。问题跟踪对审计中发现的问题，要求项目组改进，并跟进直到解决。,软件质量保证（SQA）,SQA的素质以过程为中心：应当站在过程的角度来考虑问题，只要保证了过程，QA就尽到了责任。专业的服务精神：为项目组服务，帮助项目组确保正确执行过程了解过程：深刻了解企业的工程，并具有一定的过程管理理论知识了解开发：对开发工作的基本情况了解，能够理解项目的活动良好的沟通技巧：善于沟通，能够营造良好的气氛，避免审计活动成为一种找茬活动。,软件测试与质量保证,软件测试：关注的是软件开发的产物，以及对软件进行剖析，运行软件，找出问题，报告质量。软件测试是保证软件质量的一个重要环节。测试工作无法遍历软件测试只是质量保证活动中的一个重要环节，而不是唯一环节力图通过测试提高软件的质量如同经常称体重来达到减肥的目的。如果你想减肥，不要买一个新称，而是节食。如果你想提高你软件质量的话，不是更多的测试，而是更好的分析、设计和开发。-SteveMcConnellinCodeComplete,第二部分,质量保证与SQA软件质量模型CMM/CMMI和ISO9000软件质量铁三角,软件质量模型,从测量的角度看，影响软件质量的因素可以分为两大类：可直接测量（如每个功能点的错误）和间接度量（如可用性、可维护性）。每种类型测度都必须发生。早期的软件质量模型是1977年McCall和他的同事建立的，提出了影响质量因素的有用的分类，集中在软件产品的三个重要方面：操作特性（产品运行）、承受可改变能力（产品修订）、新环境适应能力（产品变迁）,MCCall质量模型,Boehm质量模型,1978年Boehm和他的同事们提出了分层结构的软件质量模型，除包含了用户的期望和需要的概念，还包括了McCall模型中没有的硬件特性Boehm模型始于软件的整体效用，从系统交付后涉及不同类型的用户考虑。第一种用户是初始顾客，系统做了顾客所期望的事情。第二种用户是要将软件移植到其他软硬件系统下使用的客户第三种用户是维护系统的程序员这三种用户都希望系统是可靠有效的，因此，Boehm模型反映了对软件质量的理解，即软件做了用户要它做的；有效的使用系统资源；易于学习和使用；易于维护和测试,Boehm质量模型,ISO9126质量模型,20世纪90年代早期，软件工程组织试图将诸多的软件质量模型统一到一个模型中，并把这个模型作为度量软件质量的一个国际标准。国际标准化组织1991年颁布了ISO9126-1991标准软件产品评价-质量特性及其使用指南我国也与1996年颁发了同样的软件产品质量评价标准GB/T16260-1996。它是一个分层质量模型，有6个影响质量的特性。,ISO9126质量模型,第三部分,质量保证与SQA软件质量模型CMM/CMMI和ISO9000软件质量铁三角,能力成熟度模型CMM,CMM（CapabilityMaturityModel）：CMM是由美国软件工程学会(softwareengineeringinstitue,简称SEI)制定的一套专门针对软件产品的质量管理和质量保证标准.CMM全称为(CapabilityMaturityModel),中文名称为能力成熟度模型.CMM最早始于1987年,为了满足美国联邦政府评估软件供应商能力的要求,美国卡内基-梅隆大学的软件工程研究学院SEI牵头,发布了一份能力成熟框架(CapabilityMaturityFramework)以及一个成熟度问卷(MaturityQestionnaire)。四年后(即1991年),SEI将成熟度框架进化为软件能力成熟度模型(CapabilityMaturityModelForSoftware,简称SW-CMM,即CMM1.0)自1991年SW-CMM1.0版本使用两年后,SEI与1993年又推出了CMM1.1版.近几年来,CMM又推出了2.0版本,同时进入了ISO体系,称为ISO/IEC15504或SPICE.CMM定义了5级成熟度级别,共计18个过程域（KPA）,能力成熟度模型CMM,CMMI级初始级：软件开发过程是随意的、混乱的，项目成功依靠个人英雄的行为和运气过程没有通用的计划、监视和过程控制开发软件的时间和费用无法预知，无法预知项目的前景与结果测试过程与其他过程混杂在一起CMMII级可重复的具备项目级的思想使用基本项目管理过程来跟踪项目的进度、功能和质量以前的项目经验可以应用到当前项目中具有一定的组织性，使用了基本的软件测试行为，例如软件测试计划和测试用例关键过程域（KPA）：需求管理,项目策划,项目监督和控制,供方协定管理,测量和分析,过程和产品质量保证,配置管理,能力成熟度模型CMM,CMMIII级定义级：具备组织化的思想，而不仅仅针对某个项目通用管理和过程活动被标准化和文档化标准在项目中采用并得到证实，压力增加时，不会放弃规则测试之前要审查和批准测试文档和计划测试团队和开发团队独立测试结果用于确定软件完成时间关键过程域（KPA）：需求开发,技术解决,产品集成,验证,确认,组织级过程焦点,组织级过程定义,组织培训,集成项目管理,风险管理以及决策分析和决定.CMMIV级可管理的组织过程处于统计的控制之下。产品质量事先以量化的方式指定（例如，产品直到每行代码只有0.5个以下问题才能发布），并且在未达到目标之前不允许发布加强了项目的监督和控制，在整个项目开发过程中，收集开发过程和软件质量的详细情况，经过调整校正偏差，使项目按计划进行关键过程域（KPA）：定量过程管理,软件质量管理,能力成熟度模型CMM,CMMV级不断优化的：从CMMIV级不断提高，尝试新的技术和处理过程，评价结果，采用提高和创新的变动以期达到质量更佳的等级。正当所有人认为已经达到最佳时，新的想法又出现了，再次提高到下一个等级注意：倡导公司提高软开发成熟度不是软件测试员的事情。,能力成熟度模型CMM,CMM的评估：CMM的评估采用CBA-IPI方法(即CMM-BasedAssessmentforInternalProcessImprovement).CBA-IPI方法是一种诊断工具,它借助识别其现行过程的优劣使一个组织能了解其软件开发能力,把这些优缺点与CMM对照起来,安排软件改进计划的优先顺序,并把注意力集中关注到最有利的软件改进上,以及给出其现行过程的成熟度等级和业务目标;此方法是受过培训的专业组对组织的软件过程能力作出评估,该组全体人员作为一个团队一起对评估范围内的CMM关键过程域进行评估和评分.此评估结果是依据所采集的数据作出的,这些数据来自问卷回答文档审核陈述以及与中层经理项目负责人和软件专业人员的深层访谈.,能力成熟度模型集成CMMI,CMMI（CapabilityMaturityModelIntegration）自CMM1.0版本后,SEI又开发了其他成熟度模型,包括:软件工程(SW-CMM),系统工程(SE-CMMsystemengineeringCMM),软件采购(SA-CMM,softwareacquistionCMM),人力资源管理(P-CMM,peopleCMM)和集成产品开发(IPT-CMMintegratedproductteamCMM)等.虽然各个模型针对的专业领域不同,但是彼此之间有一定的重叠;另外,这些模型在表现形工上又有不统一之处:系统工程模型是连续式的,而其它模型采用了分级式.为了整合不同模型的最佳实践,建议统一模型,覆盖不同领域,供企业进行整个组织的全面过程改进,并于2001年正式发布了能力成熟度集成模型(CMMI)1.1版本,这次发布标志着CMMI的正式使用.SEI也正式宣布,将不再维护CMM的CBA-IPI评估方法.SEI并没有废除CMM模型,而是以CMMI的SCAMPI评估方法取代CMM的CBA-IPI评估方法.CMMI定义了5级成熟度级别,共计25个过程,能力成熟度模型集成CMMI,CMMII级初始级:代表了不可预测结果为我自的成熟度.过程包括了一些特别的方法,符号,工作和反应管理,成功主要取决于团队的技能.CMMIII级已管理级:代表了以可重复项目执行为特征的过程成熟度.组织使用基本纪律进行需求管理,项目计划,项目监督和控制,供应商协议管理,产品和过程质量保证,配置管理,以及度量和分析.本级别主要的过程焦点在于项目级的活动和实践.强调级别2的关键过程域的前后一致的、项目级的纪律，以建立组织级的活动和实践。,能力成熟度模型集成CMMI,CMMIII级已管理级:附加的组织级过程域包括：需求开发：多利益相关者的需求发展。技术方案：展开的设计和质量工程。产品集成：持续集成、接口控制、变更控制。验证：保证产品正确建立的评估技术。确认：保证建立正确的产品的评估技术。风险管理：检测、优先级，相关问题和意外的解决方案。组织级培训：建立机制，培养更多熟练人员。组织级过程焦点：为项目过程定义建立组织级框架。决策分析和方案：系统的可选的评估。组织级过程定义：把过程看做组织的持久的发展的资产。集成项目管理：在项目内统一各个组和利益相关者。,能力成熟度模型集成CMMI,CMMIIII级严格定义级：代表了以组织内改进项目执行为特征的过程成熟度.CMMIIV级定量管理级：代表了以改进组织性能为特征的过程成熟度.3级项目的历史结果可用来交替使用,在业务表现的竞争尺度(成本,时间,质量)方面的结果是可预测的.附加的过程域包括:组织级过程执行:为过程执行设定规范和基准.定量的项目管理:以统计质量控制方法为基础实施项目.CMMIV级优化级：代表了可快速进行重新配置的组织性能和定量的,持续的过程改进为牲的过程成熟度.附加过程域包括:因果分析和解决方案:主动避免错误和强化最佳实践组织级改革和实施:建议一个能够有机适应和改进的学习组织.,CMM电子行业协会临时标准(EIA/IS)731;集成产品开发能力成熟模型(IPD-CMMI)V0.98,ISO9000质量管理认证体系,ISO9000是关于质量管理和质量保证的一系列标准，定义了一套基本达标的时间，帮助公司不断的交付符合公司质量要求的产品或服务。ISO9000用的比较好的两个原因就是：它的目标在于开发过程，而不产品ISO9000只决定过程的要求是什么，而不管如何达到注意：一家公司得到了ISO9000认证，表示它在开发过程中达到某种质量控制等级，这不意味着其产品达到了某种质量等级。,ISO9000质量管理认证体系,ISO9000标准中针对软件的部分是ISO9001和ISO9000-3。ISO9001负责设计、开发、生产、安装和服务产品方面的事物ISO9000-3负责开发、供应、安装和维护计算机软件方面的事物,CMM但是2级和4级分别定义为已管理级和定量管理级,这个变化更突出了CMMI定性管理和定量管理的特点.CMMI共有分属于4个类别的25个过程哉,覆盖了4个不同的领域;相对应的CMM共有18个过程域.CMM基本活动的度量方法和瀑布过程的有次序的,基本活动的管理规范有非常密切的联系,更适合瀑布型的开发过程;而CMMI相对CMM更一步支持迭代开发过程和推动组织采用基于结果的方法:开发业务安全,构想和原型方案,细化后纳入基线结构,可用发布,最后确定为现场版本的发布.,CMM在CMMI中,3级有一个独立的KPA叫做需求开发,提出了对如何获取优秀的需求的要求和方法.CMMI对工程活动进行了一定的强化.在CMM中只有3级中的软件产品工程和同行评审两个KPA是与工程过程密切相关的;而在CMMI中,则将需求开发,验证,确认,技术解决方案产品集成这些工程过程活动都作为单独的KPA进行了要求.CMMI3级中单独强调了风险管理,而在CMM中把风险的管理分散在项目计划,项目跟踪与监控中进行要求.,CMMIPI-CBA的评估方法被SCAMPI方法替代.,CMM&CMMI&ISO9000的区别与联系,ISO9000与CMMI的联系及区别:联系:两者都共同着眼于质量和过程管理目前2000版的ISO更多的和CMMI有直接对应的关系,甚至是大量的CMMI4和CMMI5级的要求.区别:CMMI是专门针对软件产品开发和服务,而ISO9000涉及的范围则相当宽.CMMI强调软件开发过程的成熟度,即过程的不断改进和提高.而ISO9000则强调可接收的质量体系的最低标准.,第四部分,质量保证与SQA软件质量模型CMM/CMMI和ISO9000软件质量铁三角,软件质量的铁三角,软件质量的铁三角是流程、技术和组织，技术，流程直接影响软件质量，组织通过影响技术、流程，从而间接影响软件质量。技术是有人来承载的，一个公司，员工的技术高低影响了产品的质量，而员工的技术又可以分为两个方面，一是现有员工的技术，二是以前员工积累下的技术（包括专利、案例，及一些已经平台化、模式化的东西），这两方面有了保证，技术也就有了保证。流程规定了一项活动的基本要素和规则，告诉人们谁什么时候该做什么，如何去做，要得到什么。它驱动着人们的活动，是使活动规范化，从而提高效率。技术和流程的关系，两者相辅相成，缺一不可。组织对技术的影响1.能否保证现有员工技术都是符合要求的。2.能否在制度上保证以前员工积累的经验能够固化下来。组织对流程的影响1.能否制定出符合企业实际情况的流程。2.能否为流程的推行提供制度上的保证。,Q&A,1、（问答题）请说说你对软件质量的理解。2、（问答题）请谈谈你掌握的软件质量模型3、（问答题）请阐述你所了解的ISO和CMM及CMMI4、（问答题）什么是质量保证？试述质量保证与软件测试的关系？5、（问答题）如何理解CMM的五个等级？6、（问答题）什么是软件质量的铁三角？,下节预告,制定软件测试计划如何制定软件测试计划软件测试计划的要素软件测试计划的原则软件测试计划的目的使用5W1H方法制定测试计划测试计划实战,谢谢,结束,