《第八章 软件质量保证复习课程》由会员分享，可在线阅读，更多相关《第八章 软件质量保证复习课程（44页珍藏版）》请在金锄头文库上搜索。
1、第八章 软件质量保证,ITANY,本课程的主要内容,软件质量模型 ISO9000和CMM/CMMI 软件质量铁三角 质量保证与SQA,本章目标,理解软件质量模型 了解CMM/CMMI和ISO9000 理解质量铁三角 了解质量保证与SQA,软件质量的定义,“软件质量”（ISO9126）：软件满足规定或潜在用户需求特性的总和。包括“内部质量”、“外部质量”和“使用质量”三部分。 “软件质量”（ISO14598）：软件特性的总和，软件满足规定或潜在用户需求的能力。,软件质量的理解,软件质量是一个复杂的概念，不同的人从不同的角度来看待软件质量问题会有不同的理解 用户视角：质量就是满足客户的需求 开发者
2、的视角：质量就是与需求说明保持一致 产品视角： 质量就是产品的内在特点 价值视角：质量就是客户是否愿意购买 项目经理视角：质量就是能“令人满意”地工作以完成预期功能的软件产品,质量保证 (QA),质量保证（QA：Quality Assurance）： 质量保证的重要工作是通过预防、检查与改进来保证软件质量。 QA通过“全面质量管理”和“过程改进”的原理开展质量保证工作 虽然在QA的活动中也有一些测试活动，但QA所关注的是对软件质量的检查与度量。 QA的工作是对软件生命周期的管理以及验证软件是否满足规定的质量和用户需求，因此主要着眼于软件开发活动中的过程、步骤和产物，而不是对软件剖析，找出问题或
3、评估。 QA的注意职责是检查和评价当前软件开发的过程，找出过程改进的方法，已达到防止软件缺陷出现的目标,QA的组织结构,在国内大多数企业，QA组织结构可划分为三类：职能结构、矩阵结构以及两者结合而成的柔性结构。 职能结构 在职能结构中，各个职能部门设立自己的QA岗位，位于高级经理之下，独立于项目组。 QA直接对高级经理负责，但业务上需要向项目经理汇报，属于项目成员。 职能结构的优点 QA容易融入项目组，易于发现实质性的问题，解决问题也很快捷。 职能结构的缺点 各职能部门相对独立，部门之间的经验缺乏交流和共享，还可能出现对过程、方法和工具研究的重复性投资。 在这种组织结构下，由于高级经理专注于业
4、务的发展，QA的职业发展容易受到忽视，难于接受到应有的培训和提升。,QA的组织结构,矩阵结构 在矩阵结构中，设立了专门的QA部门，与各业务职能部门平级。QA隶属于QA部，行政上向QA经理负责，业务上向业务部门的高级经理和项目经理汇报。 在这种组织结构中，由QA部经理对QA考评和授权，有利于保证QA的独立性和评价的客观性，也有利于确保组织的长期利益与项目（或个人）的短期利益之间的平衡。 QA资源为所有项目所共享，可按照项目优先级动态调配，资源利用更充分，但也可能出现资源竞争冲突。 此外，QA部门对QA流程的改进、QA知识的管理、QA人员的发展负责，并可集中资源进行QA平台的建设，以防止重复性的投
5、资。 但另一方面，在矩阵结构中，QA难于融入项目组，发现的问题也很少能得到及时有效的解决。 柔性结构 柔性结构是职能结构和矩阵结构的混合形态，在职能结构的基础上建立了QA组。,QA的岗位职责,在CMMI中，QA的主要工作是过程评审和产品审计。从实践经验来看，QA只完成这两项工作很难体现出QA的价值。 为了让QA组织的产出大于组织的投入，实现增值，就应该根据企业需要适当增加QA的职责，比如过程指导、过程度量和过程改进等。 过程指导主要是项目前期辅助项目经理制定项目计划（包括辅助定义或修改项目过程和过程模型、协助项目估计、建立项目验收准则、设置质量目标等），对项目成员进行过程和规范的培训以及在过程
6、中进行指导等。 过程度量（包括产品度量）在CMMI中已经成为CMMI ML2级中一个单独的过程域，但却是对所有过程的一个共性要求。特别是成熟度越高，对度量的要求也越高，难度也越大。这就要求有专业的人员来负责，QA就是一个很好的选择。主要职责包括收集、统计、分析度量数据，以支持管理信息需求。 过程改进在CMMI中主要是EPG的职责。但事实上，QA更接近于过程实施的环节，更了解过程运行的情况，也就更容易发现“木桶中最短的那块”。同时，QA也是改进过程实施的重要推动力量。,软件质量保证（SQA）,SQA活动 软件质量保证（SQA）是一种应用于整个软件过程的活动，它包含： 一种质量管理方法 有效的软件
7、工程技术（方法和工具） 在整个软件过程中采用的正式技术评审 一种多层次的测试策略 对软件文档及其修改的控制 保证软件遵从软件开发标准 度量和报告机制,软件质量保证（SQA）,SQA的工作内容和工作方法 计划 针对具体项目制定 SQA计划，确保项目组正确执行过程。制定SQA计划应当注意如下几点： 有重点：依据企业目标以及项目情况确定审计的重点 明确审计内容：明确审计哪些活动，那些产品 明确审计方式：确定怎样进行审计 明确审计结果报告的规则：审计的结果报告给谁 审计/证实 依据 SQA计划进行SQA审计工作，按照规则发布审计结果报告。 注意审计一定要有项目组人员陪同，不能搞突然袭击。双方要开诚布公
8、，坦诚相对。 审计的内容：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。 问题跟踪 对审计中发现的问题，要求项目组改进，并跟进直到解决。,软件质量保证（SQA）,SQA的素质 以过程为中心：应当站在过程的角度来考虑问题，只要保证了过程， QA就尽到了责任。 专业的服务精神：为项目组服务，帮助项目组确保正确执行过程 了解过程：深刻了解企业的工程，并具有一定的过程管理理论知识 了解开发：对开发工作的基本情况了解，能够理解项目的活动 良好的沟通技巧：善于沟通，能够营造良好的气氛，避免审计活动成为一种找茬活动。,软件测试与质量保证,软件测试：关注的是软件开发的产物，以及对软件进行剖析
9、，运行软件，找出问题，报告质量。软件测试是保证软件质量的一个重要环节。 测试工作无法遍历 软件测试只是质量保证活动中的一个重要环节，而不是唯一环节 力图通过测试提高软件的质量如同经常称体重来达到减肥的 目的。如果你想减肥，不要买一个新称，而是节食。如 果你想提高你软件质量的话，不是更多的测试，而是更好的 分析、设计和开发。-Steve McConnell in Code Complete,第二部分,质量保证与SQA 软件质量模型 CMM/CMMI和ISO9000 软件质量铁三角,软件质量模型,从测量的角度看，影响软件质量的因素可以分为两大类：可直接测量（如每个功能点的错误）和间接度量（如可用性
10、、可维护性）。每种类型测度都必须发生。 早期的软件质量模型是1977年McCall和他的同事建立的，提出了影响质量因素的有用的分类，集中在软件产品的三个重要方面：操作特性（产品运行）、承受可改变能力（产品修订）、新环境适应能力（产品变迁）,MCCall质量模型,Boehm质量模型,1978年Boehm和他的同事们提出了分层结构的软件质量模型，除包含了用户的期望和需要的概念，还包括了McCall模型中没有的硬件特性 Boehm模型始于软件的整体效用，从系统交付后涉及不同类型的用户考虑。 第一种用户是初始顾客，系统做了顾客所期望的事情。 第二种用户是要将软件移植到其他软硬件系统下使用的客户 第三种
11、用户是维护系统的程序员 这三种用户都希望系统是可靠有效的，因此，Boehm模型反映了对软件质量的理解，即软件做了用户要它做的；有效的使用系统资源；易于学习和使用；易于维护和测试,Boehm质量模型,ISO9126质量模型,20世纪90年代早期，软件工程组织试图将诸多的软件质量模型统一到一个模型中，并把这个模型作为度量软件质量的一个国际标准。 国际标准化组织1991年颁布了ISO9126-1991标准软件产品评价-质量特性及其使用指南 我国也与1996年颁发了同样的软件产品质量评价标准GB/T 16260-1996。它是一个分层质量模型，有6个影响质量的特性。,ISO9126质量模型,第三部分,
12、质量保证与SQA 软件质量模型 CMM/CMMI和ISO9000 软件质量铁三角,能力成熟度模型CMM,CMM （ Capability Maturity Model ）： CMM是由美国软件工程学会(software engineering institue,简称SEI)制定的一套专门针对软件产品的质量管理和质量保证标准. CMM全称为(Capability Maturity Model),中文名称为能力成熟度模型. CMM最早始于1987年,为了满足美国联邦政府评估软件供应商能力的要求,美国卡内基-梅隆大学的软件工程研究学院SEI牵头,发布了一份能力成熟框架(Capability Matu
13、rity Framework)以及一个成熟度问卷(Maturity Qestionnaire)。四年后(即1991年),SEI将成熟度框架进化为软件能力成熟度模型(Capability Maturity Model For Software,简称SW-CMM,即CMM1.0) 自1991年SW-CMM1.0版本使用两年后,SEI与1993年又推出了CMM1.1版. 近几年来,CMM又推出了2.0版本,同时进入了ISO体系,称为ISO/IEC15504或SPICE. CMM定义了5级成熟度级别,共计18个过程域（KPA）,能力成熟度模型CMM,CMM I级 初始级： 软件开发过程是随意的、混乱的
14、，项目成功依靠个人英雄的行为和运气 过程没有通用的计划、监视和过程控制 开发软件的时间和费用无法预知，无法预知项目的前景与结果 测试过程与其他过程混杂在一起 CMM II级 可重复的 具备项目级的思想 使用基本项目管理过程来跟踪项目的进度、功能和质量 以前的项目经验可以应用到当前项目中 具有一定的组织性，使用了基本的软件测试行为，例如软件测试计划和测试用例 关键过程域（KPA）：需求管理,项目策划,项目监督和控制,供方协定管理,测量和分析,过程和产品质量保证,配置管理,能力成熟度模型CMM,CMM III级 定义级： 具备组织化的思想，而不仅仅针对某个项目 通用管理和过程活动被标准化和文档化
15、标准在项目中采用并得到证实，压力增加时，不会放弃规则 测试之前要审查和批准测试文档和计划 测试团队和开发团队独立 测试结果用于确定软件完成时间 关键过程域（KPA）：需求开发,技术解决,产品集成,验证,确认,组织级过程焦点,组织级过程定义,组织培训,集成项目管理,风险管理以及决策分析和决定. CMM IV级 可管理的 组织过程处于统计的控制之下。 产品质量事先以量化的方式指定（例如，产品直到每行代码只有0.5个以下问题才能发布），并且在未达到目标之前不允许发布 加强了项目的监督和控制，在整个项目开发过程中，收集开发过程和软件质量的详细情况，经过调整校正偏差，使项目按计划进行 关键过程域（KPA
16、）：定量过程管理,软件质量管理,能力成熟度模型CMM,CMM V级 不断优化的： 从CMM IV级不断提高，尝试新的技术和处理过程，评价结果，采用提高和创新的变动以期达到质量更佳的等级。 正当所有人认为已经达到最佳时，新的想法又出现了，再次提高到下一个等级 注意： 倡导公司提高软开发成熟度不是软件测试员的事情。,能力成熟度模型CMM,CMM的评估： CMM的评估采用CBA-IPI方法(即CMM-Based Assessment for Internal Process Improvement). CBA-IPI方法是一种诊断工具,它借助识别其现行过程的优劣使一个组织能了解其软件开发能力,把这些优缺点与CMM对照起来,安排软件改进计划的优先顺序,并把注意力集中关注到最有利的软件改进上,以及给出其现行过程的成熟度等级和业务目标; 此方法是受过培训的专业组对组织的软件过程能力作出评估,该组全体人员作为一个团队一起对评估范围内的CMM关键过程域进行评估和评分. 此评估结果是依据所采集的数据作出的,这些数据来自问卷回答文档审核陈述以及与中层经理项目负责人和软件专业人员的深层访谈.,能
