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

《《软件质量保证》PPT课件.pptx》由会员分享，可在线阅读，更多相关《《软件质量保证》PPT课件.pptx（44页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第八章第八章 软件质量保证软件质量保证ITANY22本课程的主要内容l软件质量模型软件质量模型lISO9000和和CMM/CMMIl软件质量铁三角软件质量铁三角l质量保证与质量保证与SQA33本章目标l理解软件质量模型理解软件质量模型l了解了解CMM/CMMI和和ISO9000l理解质量铁三角理解质量铁三角l了解质量保证与了解质量保证与SQA44第一部分l质量质量保证与保证与SQASQAl软件质量模型软件质量模型lCMM/CMMICMM/CMMI和和ISO9000ISO9000l软件软件质量铁三角质量铁三角55软件质量的定义“软件质量软件质量”（ISO9126）：软件满足规定或潜在用户需求特性

2、的总和。包括“内部质量内部质量”、“外部质量外部质量”和“使用质量使用质量”三部分。“软件质量软件质量”（ISO14598）：软件特性的总和，软件满足规定或潜在用户需求的能力。66软件质量的理解软件质量是一个复杂的概念，不同的人从不同的角度来看软件质量是一个复杂的概念，不同的人从不同的角度来看待软件质量问题会有不同的理解待软件质量问题会有不同的理解用户视角：用户视角：质量就是满足客户的需求 开发者的视角：开发者的视角：质量就是与需求说明保持一致产品视角：产品视角：质量就是产品的内在特点价值视角：价值视角：质量就是客户是否愿意购买项目经理视角：项目经理视角：质量就是能“令人满意”地工作以完成预期

3、功能的软件产品77质量保证(QA)质量保证（质量保证（QA：Quality Assurance）：）：质量保证的重要工作是通过预防预防、检查检查与改进改进来保证软件质量。QA通过“全面质量管理全面质量管理”和“过程改进过程改进”的原理开展质量保证工作虽然在QA的活动中也有一些测试活动，但QA所关注的是对软件质量的检查检查与度量度量。QA的工作是对软件生命周期的管理对软件生命周期的管理以及验证软件是否满足规定的验证软件是否满足规定的质量和用户需求质量和用户需求，因此主要着眼于软件开发活动中的过程、步骤软件开发活动中的过程、步骤和产物和产物，而不是对软件剖析，找出问题或评估。QA的注意职责是检查和

4、评价当前软件开发的过程，找出过程改进的方法，已达到防止软件缺陷出现的目标88QA的组织结构在国内大多数企业，QA组织结构可划分为三类：职能结构职能结构、矩阵结构矩阵结构以及两者结合而成的柔性结构柔性结构。职能结构职能结构在职能结构中，各个职能部门设立自己的QA岗位，位于高级经理之下，独立于项目组。QA直接对高级经理负责，但业务上需要向项目经理汇报，属于项目成员。职能结构的优点职能结构的优点QA容易融入项目组，易于发现实质性的问题，解决问题也很快捷。职能结构的缺点职能结构的缺点各职能部门相对独立，部门之间的经验缺乏交流和共享，还可能出现对过程、方法和工具研究的重复性投资。在这种组织结构下，由于高

5、级经理专注于业务的发展，QA的职业发展容易受到忽视，难于接受到应有的培训和提升。99QA的组织结构矩阵结构矩阵结构在矩阵结构中，设立了专门的QA部门，与各业务职能部门平级。QA隶属于QA部，行政上向QA经理负责，业务上向业务部门的高级经理和项目经理汇报。在这种组织结构中，由QA部经理对QA考评和授权，有利于保证QA的独立性和评价的客观性，也有利于确保组织的长期利益与项目（或个人）的短期利益之间的平衡。QA资源为所有项目所共享，可按照项目优先级动态调配，资源利用更充分，但也可能出现资源竞争冲突。此外，QA部门对QA流程的改进、QA知识的管理、QA人员的发展负责，并可集中资源进行QA平台的建设，以

6、防止重复性的投资。但另一方面，在矩阵结构中，QA难于融入项目组，发现的问题也很少能得到及时有效的解决。柔性结构柔性结构柔性结构是职能结构和矩阵结构的混合形态，在职能结构的基础上建立了QA组。1010QA的岗位职责在CMMI中，QA的主要工作是过程评审过程评审和产品审计产品审计。从实践经验来看，QA只完成这两项工作很难体现出QA的价值。为了让QA组织的产出大于组织的投入，实现增值，就应该根据企业需要适当增加QA的职责，比如过程指导过程指导、过程度量过程度量和过程改进过程改进等。过程指导过程指导主要是项目前期辅助项目经理制定项目计划（包括辅助定义或修改项目过程和过程模型、协助项目估计、建立项目验收

7、准则、设置质量目标等），对项目成员进行过程和规范的培训以及在过程中进行指导等。过程度量过程度量（包括产品度量）在CMMI中已经成为CMMI ML2级中一个单独的过程域，但却是对所有过程的一个共性要求。特别是成熟度越高，对度量的要求也越高，难度也越大。这就要求有专业的人员来负责，QA就是一个很好的选择。主要职责包括收集、统计、分析度量数据，以支持管理信息需求。过程改进过程改进在CMMI中主要是EPG的职责。但事实上，QA更接近于过程实施的环节，更了解过程运行的情况，也就更容易发现“木桶中最短的那块”。同时，QA也是改进过程实施的重要推动力量。1111软件质量保证（SQA）SQA活动活动软件质量保

8、证（SQA）是一种应用于整个软件过程的活动，它包含：一种质量管理方法有效的软件工程技术（方法和工具）在整个软件过程中采用的正式技术评审一种多层次的测试策略对软件文档及其修改的控制保证软件遵从软件开发标准度量和报告机制1212软件质量保证（SQA）SQA的工作内容和工作方法的工作内容和工作方法 计划计划 针对具体项目制定 SQA计划，确保项目组正确执行过程。制定SQA计划应当注意如下几点：有重点：依据企业目标以及项目情况确定审计的重点 明确审计内容：明确审计哪些活动，那些产品 明确审计方式：确定怎样进行审计 明确审计结果报告的规则：审计的结果报告给谁 审计审计/证实证实 依据 SQA计划进行SQ

9、A审计工作，按照规则发布审计结果报告。注意审计一定要有项目组人员陪同，不能搞突然袭击。双方要开诚布公，坦诚相对。审计的内容：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。问题跟踪问题跟踪 对审计中发现的问题，要求项目组改进，并跟进直到解决。1313软件质量保证（SQA）SQA的素质的素质 以过程为中心以过程为中心：应当站在过程的角度来考虑问题，只要保证了过程，QA就尽到了责任。专业的服务精神专业的服务精神：为项目组服务，帮助项目组确保正确执行过程 了解过程了解过程：深刻了解企业的工程，并具有一定的过程管理理论知识 了解开发了解开发：对开发工作的基本情况了解，能够理解项目的活动

10、 良好的沟通技巧良好的沟通技巧：善于沟通，能够营造良好的气氛，避免审计活动成为一种找茬活动。1414软件测试与质量保证软件测试：软件测试：关注的是软件开发的产物，以及对软件进行剖析，运行软件，找出问题，报告质量。软件测试是保证软件质量的一个重要环节。测试工作无法遍历软件测试只是质量保证活动中的一个重要环节，而不是唯一环节力图通过测试提高软件的质量如同经常称体重来达到减肥的目的。如果你想减肥，不要买一个新称，而是节食。如果你想提高你软件质量的话，不是更多的测试，而是更好的分析、设计和开发。-Steve McConnell in Code Complete1515第二部分l质量保证与质量保证与SQ

11、ASQAl软件质量模型软件质量模型lCMM/CMMICMM/CMMI和和ISO9000ISO9000l软件软件质量铁三角质量铁三角1616软件质量模型从测量的角度看，影响软件质量的因素可以分为两大类：可直接测量可直接测量（如每个功能点的错误）和间接度量间接度量（如可用性、可维护性）。每种类型测度都必须发生。早期的软件质量模型是1977年McCall和他的同事建立的，提出了影响质量因素的有用的分类，集中在软件产品的三个重要方面：操作特性（产品运行）操作特性（产品运行）、承受可改变能力承受可改变能力（产品修订）（产品修订）、新环境适应能力（产品变迁）新环境适应能力（产品变迁）1717MCCALL质

12、量模型1818BOEHM质量模型1978年Boehm和他的同事们提出了分层结构的软件质量模型，除包含了用户的期望和需要的概念，还包括了McCall模型中没有的硬件特性Boehm模型始于软件的整体效用，从系统交付后涉及不同类型的用户考虑。第一种用户是初始顾客初始顾客，系统做了顾客所期望的事情。第二种用户是要将软件移植到其他软硬件系统下使用的客户要将软件移植到其他软硬件系统下使用的客户第三种用户是维护系统的程序员维护系统的程序员这三种用户都希望系统是可靠有效的，因此，Boehm模型反映了对软件质量的理解，即软件做了用户要它做的软件做了用户要它做的；有效的使用系统资源有效的使用系统资源；易于学习和使

13、用易于学习和使用；易于维护和测试易于维护和测试1919BOEHM质量模型2020ISO9126质量模型20世纪90年代早期，软件工程组织试图将诸多的软件质量模型统一到一个模型中，并把这个模型作为度量软件质量的一个国际标准。国际标准化组织1991年颁布了ISO9126-1991标准软件产品评价-质量特性及其使用指南我国也与1996年颁发了同样的软件产品质量评价标准GB/T 16260-1996。它是一个分层质量模型，有6个影响质量的特性。2121ISO9126质量模型2222第三部分l质量保证与质量保证与SQASQAl软件质量模型软件质量模型lCMM/CMMICMM/CMMI和和ISO9000I

14、SO9000l软件软件质量铁三角质量铁三角2323能力成熟度模型CMMCMM（Capability Maturity Model）：）：CMM是由美国软件工程学会美国软件工程学会(software engineering institue,简称SEI)制定的一套专门针对软件产品的质量管理针对软件产品的质量管理和质量保证标准质量保证标准.CMM全称为(Capability Maturity Model),中文名称为能力成熟度模型能力成熟度模型.CMM最早始于1987年,为了满足美国联邦政府评估软件供应商能力的要求,美国卡内基-梅隆大学的软件工程研究学院SEI牵头,发布了一份能力成熟框架(Capa

15、bility Maturity Framework)以及一个成熟度问卷(Maturity Qestionnaire)。四年后(即1991年),SEI将成熟度框架进化为软件能力成熟度模型(Capability Maturity Model For Software,简称SW-CMM,即CMM1.0)自1991年版本使用两年后,SEI与1993年又推出了版.近几年来,CMM又推出了版本,同时进入了ISO体系,称为ISO/IEC15504或SPICE.CMM定义了5 5级成熟度级别级成熟度级别,共计1818个过程域（个过程域（KPAKPA）2424能力成熟度模型CMMCMM I级级 初始级：初始级：

16、软件开发过程是随意的、混乱的，项目成功依靠个人英雄的行为和运气过程没有通用的计划、监视和过程控制开发软件的时间和费用无法预知，无法预知项目的前景与结果测试过程与其他过程混杂在一起CMM II级级 可重复的可重复的具备项目级的思想使用基本项目管理过程来跟踪项目的进度、功能和质量以前的项目经验可以应用到当前项目中具有一定的组织性，使用了基本的软件测试行为，例如软件测试计划和测试用例关键过程域（KPA）：需求管理,项目策划,项目监督和控制,供方协定管理,测量和分析,过程和产品质量保证,配置管理2525能力成熟度模型CMMCMM III级级 定义级：定义级：具备组织化的思想，而不仅仅针对某个项目通用管

17、理和过程活动被标准化和文档化标准在项目中采用并得到证实，压力增加时，不会放弃规则测试之前要审查和批准测试文档和计划测试团队和开发团队独立测试结果用于确定软件完成时间关键过程域（KPA）：需求开发,技术解决,产品集成,验证,确认,组织级过程焦点,组织级过程定义,组织培训,集成项目管理,风险管理以及决策分析和决定.CMM IV级级 可管理的可管理的组织过程处于统计的控制之下。产品质量事先以量化的方式指定（例如，产品直到每行代码只有个以下问题才能发布），并且在未达到目标之前不允许发布加强了项目的监督和控制，在整个项目开发过程中，收集开发过程和软件质量的详细情况，经过调整校正偏差，使项目按计划进行关键

18、过程域（KPA）：定量过程管理,软件质量管理2626能力成熟度模型CMMCMM V级级 不断优化的：不断优化的：从CMM IV级不断提高，尝试新的技术和处理过程，评价结果，采用提高和创新的变动以期达到质量更佳的等级。正当所有人认为已经达到最佳时，新的想法又出现了，再次提高到下一个等级注意：注意：倡导公司提高软开发成熟度不是软件测试员的事情。2727能力成熟度模型CMMCMM的评估：的评估：CMM的评估采用CBA-IPI方法方法(即CMM-Based Assessment for Internal Process Improvement).CBA-IPI方法是一种诊断工具,它借助识别其现行过程的

19、优劣使识别其现行过程的优劣使一个组织能了解其软件开发能力一个组织能了解其软件开发能力,把这些优缺点与这些优缺点与CMM对照起来对照起来,安排软件改进计划的优先顺序安排软件改进计划的优先顺序,并把注意力集中关注到最有利的把注意力集中关注到最有利的软件改进上软件改进上,以及给出其现行过程的成熟度等级给出其现行过程的成熟度等级和业务目标业务目标;此方法是受过培训的专业组受过培训的专业组对组织的软件过程能力作出评估,该组全体人员作为一个团队一起对评估范围内的CMM关键过程域进行评估和评分.此评估结果是依据所采集的数据作出的,这些数据来自问卷回答来自问卷回答文档审核文档审核陈述以及与中层经理陈述以及与中

20、层经理项目负责人和软件专业人员的深项目负责人和软件专业人员的深层访谈层访谈.2828能力成熟度模型集成CMMICMMI （Capability Maturity Model Integration）自版本后,SEI又开发了其他成熟度模型,包括:软件工程软件工程(SW-CMM),系统工程系统工程(SE-CMM system engineering CMM),软件采购软件采购(SA-CMM,software acquistion CMM),人力资源管理人力资源管理(P-CMM,people CMM)和集成产品开发集成产品开发(IPT-CMM integrated product team CMM)

21、等.虽然各个模型针对的专业领域不同,但是彼此之间有一定的重叠;另外,这些模型在表现形工上又有不统一之处:系统工程模型是连续式的,而其它模型采用了分级式.为了整合不同模型的最佳实践,建议统一模型,覆盖不同领域,供企业进行整个组织的全面过程改进,并于2001年正式发布了能力成熟度集成模型版本,这次发布标志着CMMI的正式使用.SEI也正式宣布,将不再维护CMM的CBA-IPI评估方法.SEI并没有废除CMM模型,而是以CMMI的SCAMPI评估方法取代CMM的CBA-IPI评估方法.CMMI定义了5级成熟度级别,共计25个过程2929能力成熟度模型集成CMMICMMI I级级 初始级初始级:代表了

22、不可预测结果为我自的成熟度.过程包括了一些特别的方法,符号,工作和反应管理,成功主要取决于团队的技能.CMMI II级级 已管理级已管理级:代表了以可重复项目执行为特征的过程成熟度.组织使用基本纪律进行需求管理,项目计划,项目监督和控制,供应商协议管理,产品和过程质量保证,配置管理,以及度量和分析.本级别主要的过程焦点在于项目级的活动和实践.强调级别2的关键过程域的前后一致的、项目级的纪律，以建立组织级的活动和实践。3030能力成熟度模型集成CMMICMMI II级级 已管理级已管理级:附加的组织级过程域包括：附加的组织级过程域包括：需求开发：需求开发：多利益相关者的需求发展。技术方案：技术方

23、案：展开的设计和质量工程。产品集成：产品集成：持续集成、接口控制、变更控制。验证：验证：保证产品正确建立的评估技术。确认：确认：保证建立正确的产品的评估技术。风险管理：风险管理：检测、优先级，相关问题和意外的解决方案。组织级培训：组织级培训：建立机制，培养更多熟练人员。组织级过程焦点：组织级过程焦点：为项目过程定义建立组织级框架。决策分析和方案：决策分析和方案：系统的可选的评估。组织级过程定义：组织级过程定义：把过程看做组织的持久的发展的资产。集成项目管理：集成项目管理：在项目内统一各个组和利益相关者。3131能力成熟度模型集成CMMICMMI III级级 严格定义级：严格定义级：代表了以组织

24、内改进项目执行为特征的过程成熟度.CMMI IV级级 定量管理级：定量管理级：代表了以改进组织性能为特征的过程成熟度.3级项目的历史结果可用来交替使用,在业务表现的竞争尺度(成本,时间,质量)方面的结果是可预测的.附加的过程域包括附加的过程域包括:组织级过程执行:为过程执行设定规范和基准.定量的项目管理:以统计质量控制方法为基础实施项目.CMMI V级级 优化级：优化级：代表了可快速进行重新配置的组织性能和定量的,持续的过程改进为牲的过程成熟度.附加过程域包括附加过程域包括:因果分析和解决方案:主动避免错误和强化最佳实践组织级改革和实施:建议一个能够有机适应和改进的学习组织.3232CMM&C

25、MMI&ISOCMMI的评估：的评估：CMMI的评估采用SCAMPI方法(即Standard CMMI Appraisal Method for Process Improvement)SCAPMPI评估方法是一种诊断工具,支持和推动组织对过程改进支持和推动组织对过程改进进行承诺进行承诺.通过确认组织一个或多个确认组织一个或多个CMMI模型相关的现有过程模型相关的现有过程的强的强/弱项弱项,SCAMPI能够帮助组织对它自身的过程能力或组织成帮助组织对它自身的过程能力或组织成熟度有一个全面的了解熟度有一个全面的了解.CMMI的源模型:软件CMM 2.0;电子行业协会临时标准(EIA/IS)731

26、;集成产品开发能力成熟模型3333ISO9000质量管理认证体系ISO9000 是关于质量管理和质量保证的一系列标准，定义了一套基本达标的时间，帮助公司不断的交付符合公司质量要求的产品或服务。ISO 9000用的比较好的两个原因就是：用的比较好的两个原因就是：它的目标在于开发过程，而不产品ISO 9000只决定过程的要求是什么，而不管如何达到注意：注意：一家公司得到了ISO 9000认证，表示它在开发过程中达到某种质量控制等级，这不意味着其产品达到了某种质量等级。3434ISO 9000质量管理认证体系ISO 9000标准中针对软件的部分是ISO 9001和ISO 9000-3。ISO 900

27、1负责设计、开发、生产、安装和服务产品方面的事物ISO 9000-3 负责开发、供应、安装和维护计算机软件方面的事物3535CMM&CMMI&ISO9000的区别与联系CMM与与CMMI的联系：的联系：CMMI即CMM集成，是系统工程和软件工程的集成成熟度模型，CMMI更适合于信息系统集成企业。CMMI是在CMM基础上发展起来的，它继承并发扬了CMM的优良特性，借鉴了其他模型的优点，融入了新的理论和实际研究成果。它不仅能够应用在软件工程领域，而且可以用于系统工程及其他工程领域。3636CMM&CMMI&ISO9000的区别与联系CMM与与CMMI的区别的区别从等级划分上看从等级划分上看1,3,

28、5级的名称没有变化,均是初始级,已定义和优化;但是2级和4级分别定义为已管理级和定量管理级,这个变化更突出了CMMI定性管理定性管理和定量管理定量管理的特点.CMMI共有分属于4个类别的25个过程哉,覆盖了4个不同的领域;相对应的CMM共有18个过程域.CMM基本活动的度量方法和瀑布过程的有次序的,基本活动的管理规范有非常密切的联系,更适合瀑布型的开发过程更适合瀑布型的开发过程;而CMMI相对CMM更一步支持支持迭代开发过程迭代开发过程和推动组织采用基于结果的方法:开发业务安全,构想和原型方案,细化后纳入基线结构,可用发布,最后确定为现场版本的发布.3737CMM&CMMI&ISO9000的区

29、别与联系CMM与与CMMI的区别的区别从等级划分上看从等级划分上看CMMI比CMM进一步强化了对需求的重视强化了对需求的重视.在CMM中,关于需求只有需求管理这一个KPA,也就是说强调对有质量的需求进行管理,而如何获取需求则没有提出明确的要求;在CMMI中,3级有一个独立的KPA叫做需求开发,提出了对如何获取优秀的需求的要求和方法.CMMI对工程活动进行了一定的强化对工程活动进行了一定的强化.在CMM中只有3级中的软件产品工程和同行评审两个KPA是与工程过程密切相关的;而在CMMI中,则将需求开发,验证,确认,技术解决方案产品集成这些工程过程活动都作为单独的KPA进行了要求.CMMI3级中单独

30、强调了风险管理级中单独强调了风险管理,而在CMM中把风险的管理分散在项目计划,项目跟踪与监控中进行要求.3838CMM&CMMI&ISO9000的区别与联系CMM与与CMMI的区别的区别从评估方法上看从评估方法上看随着CMM过渡到CMMI,其CAF(CMM,Assessment Frame-work)框架变成评估需求(ARC:appraisal requirements for CMMI);IPI-CBA 的评估方法 被 SCAMPI方法替代.3939CMM&CMMI&ISO9000的区别与联系ISO9000与与CMMI的联系及区别的联系及区别:联系联系:两者都共同着眼于质量和过程管理目前20

31、00版的ISO更多的和CMMI有直接对应的关系,甚至是大量的CMMI4和CMMI5级的要求.区别区别:CMMI是专门针对软件产品开发和服务,而ISO9000涉及的范围则相当宽.CMMI强调软件开发过程的成熟度,即过程的不断改进和提高.而ISO9000则强调可接收的质量体系的最低标准.4040第四部分l质量保证与质量保证与SQAl软件质量模型软件质量模型lCMM/CMMI和和ISO9000l软件软件质量铁三角质量铁三角4141软件质量的铁三角软件质量的铁三角是流程流程、技术技术和组织组织，技术，流程直接影响软件质量，组织通过影响技术、流程，从而间接影响软件质量。技术技术是有人来承载的，一个公司，

32、员工的技术高低影响了产品的质量，而员工的技术又可以分为两个方面，一是现有员工的技术，二是以前员工积累下的技术（包括专利、案例，及一些已经平台化、模式化的东西），这两方面有了保证，技术也就有了保证。流程流程规定了一项活动的基本要素和规则，告诉人们谁什么时候该做什么，如何去做，要得到什么。它驱动着人们的活动，是使活动规范化，从而提高效率。技术和流程的关系，两者相辅相成，缺一不可。组织组织对技术技术的影响1.能否保证现有员工技术都是符合要求的。2.能否在制度上保证以前员工积累的经验能够固化下来。组织组织对流程流程的影响1.能否制定出符合企业实际情况的流程。2.能否为流程的推行提供制度上的保证。424

33、2Q&A1、（问答题）、（问答题）请说说你对软件质量的理解。2、（问答题）、（问答题）请谈谈你掌握的软件质量模型3、（问答题）、（问答题）请阐述你所了解的ISO和CMM及CMMI4、（问答题）、（问答题）什么是质量保证？试述质量保证与软件测试的关系？5、（问答题）、（问答题）如何理解CMM的五个等级？6、（问答题）（问答题）什么是软件质量的铁三角？4343下节预告l制定软件测试计划制定软件测试计划l如何制定软件测试计划如何制定软件测试计划l软件测试计划的要素软件测试计划的要素 l软件测试计划的原则软件测试计划的原则l软件测试计划的目的软件测试计划的目的l使用使用5W1H方法制定测试计划方法制定测试计划l测试计划实战测试计划实战4444谢谢谢谢结束