软件质量管理与测试SQA课件

软件质量管理与测试软件质量管理与测试软件质量保证软件质量保证软件质量保证p 概述p SQA人员素质p 基本目标p 工作内容p 工作方法p 软件配置管理p 评审及检查软件质量保证-概述 软件质量保证（Software Quality Assur-ance，SQA）是建立一套有计划，系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。软件质量保证-概述QA的由来：我们知道，国外很多的大公司，QA 的职责就是测试测试（主要是系统测试），比如IBM、CA、PeopleSoft 等。其实在最初，几乎所有的公司都是这样的。后来，由于缺乏有效的项目计划和项目管理，留给系统测试的时间很少；并且需求变化太快，没有完整的需求文档，测试人员就只能根据自己的想象来测试。这样一来，测试就很难保障产品的质量，事先预防的QA职能就应运而生。事先预防其实是借鉴了全面质量管理（TotalQualityManagement，TQM）的思想，而且也符合软件工程“缺陷越早发现越早修改越经济”的原则。软件质量保证-概述QA的现在 目前，实施能力成熟度模型（Capability Maturity Model，CMM）的企业越来越多。CMM模型就要求建立QA角色。这里的QA类似于过程警察，主要职责是检查开发和管理活动是否与已定的过程策略、标准和流程一致，检查工作产品是否遵循模板规定的内容和格式。在这些企业中，一般还要求QA 独立于项目组，以保障评价的客观性。从国内来看，多数的QA没有技术技术背景，检查出的偏差多为鸡毛蒜皮，再加上自己没有令人信服的背景，领导也不支持，当然做起来就很困难了。因此，QA工作本身要求QA人员具有软件工程的知识、软件开发软件开发的知识、行业背景的知识、数理统计的知识、项目管理的知识、质量管理质量管理的知识等等。软件质量保证-概述QA的未来：从某种程度上说，独立的QA审查机制是瀑布模型的产物。随着现代软件开发技术的演变，螺旋模型和迭代模型的兴起，QA机制正在悄然发生变化。这种变化就是从 独立专职的QA向贯穿过程的兼职QA演变。为什么会发生这种改变呢？无论是何种先进的方法论都是先产生架构，然后再增量开发，直到完成。这种模式中，需求和设计缺陷在各个迭代周期被尽早发现和修复，质量也内建于架构和过程中，项目的成本和进度也得到保障。到那时，是不是独立的QA就不复存在了呢？有些成熟度较低的企业还是需要的，主要是保证过程执行的有效性和评价的客观性。软件质量保证-概述QA和QC：QC：检验产品的质量，保证产品符合客户的需求，是产品质量检查者。QA：审计过程的质量，保证过程被正确执行，是过程质量审计者。检查：就是我们常说的找茬，是挑毛病的；审计：确认项目按照要求进行的证据；QC进行质量控制，向管理层反馈质量信息；QA则确保QC按照过程进行质量控制活动，按照过程将检查结果向管理层汇报。QA检查项目按照过程进行了某项活动没有，产出了某个产品没有；而QC来检查产品是否符合质量要求。软件质量保证-SQA人员素质1.SQA人员人员(简称简称SQA)要有很强的沟通能力要有很强的沟通能力。SQA不在项目中，是独立于软件项目的第三方，但要了解项目的开发过程和进度，捕捉项目中不符合要求的问题，这就要求SQA能够深入项目，和软件开发经理以及项目组开发人员保持很好的沟通，这样才能及时获得真实的项目情况。2.SQA要熟悉软件开发过程要熟悉软件开发过程。作为SQA，既然要确保项目组制定的计划、标准和规程要符合项目组要求，那么，SQA自己就要了解软件项目开发过程以及企业内部已有的开发过程规范。3.SQA本身要有很强的计划性本身要有很强的计划性。SQA一方面要监督软件项目组编写计划，另一方面SQA自身工作也要有计划。软件质量保证-SQA人员素质4.SQASQA要能应对繁杂的工作要能应对繁杂的工作。作为SQA，在跟踪项目进行过程的时候要对项目组的很多工作产品进行审计，而且会参与项目组中的多种活动。同时一个SQA还有可能会面对多个项目组，所以任务相对繁杂细碎，这就要求SQA在处理这些事物的时候要耐心细致。5.SQASQA要客观，有责任心要客观，有责任心。作为第三方对项目过程进行监督，SQA要能保持自己的客观性，不能一味讨好项目经理，也不能成为项目组中的宪兵，否则会影响工作的开展。对于项目组中多次协调解决不了的问题，能够向项目的高层经理进言，完成SQA的使命。软件质量保证-主要目标1、通过监控开发过程保证产品质量。2、确保产品及开发过程不符合问题得到处理，必 要时将问题反映给高级管理者。3、确保产品及开发过程符合相关标准与规程。4、确保项目组制定的计划、标准、规程适合项目组要求，同时满足评审及审计需要。5、收集好的实施方法、发现实施不利的原因，以便持续改进。软件质量保证-工作内容1、为项目准备SQA计划。该计划在制定项目计划时确定，由所有感兴趣的相关部门评审。包括：需要进行的审计和评审、项目可采用的标准、错误报告和跟踪的规程、由SQA小组产生的文档、向软件项目组提供的反馈数量。2、参与开发项目的软件过程描述。评审过程描述以保证该过程与组织政策、内部软件标准、外界标准以及项目计划的其他部分相符。3、评审各项软件工程活动，对其是否符合定义好的软件过程进行核实。记录、跟踪与过程的偏差。软件质量保证-工作内容4、审计指定的软件工作产品，对其是否符合事先定义好的需求进行核实。对产品进行评审，识别、记录和跟踪出现的偏差；对是否已经改正进行核实；定期将工作结果向项目管理者报告。5、确保软件工作及产品中的偏差已记录在案，并根据预定的规程进行处理。6、记录所有不符合的部分并报告给高级领导者。7、收集新方法，提供持续改进的依据。软件质量保证-工作方法软件质量保证-工作方法1、计划针对具体项目制定 SQA计划，确保项目组正确执行过程。制定SQA计划应当注意如下几点：有重点：依据企业目标及项目情况确定审计重点明确审计内容：明确审计哪些活动，那些产品明确审计方式：确定怎样进行审计明确审计结果报告的规则：审计的结果报告给谁2、做 执行计划 软件质量保证-工作方法3、检查（审计/证实）依据 SQA计划进行SQA审计工作，按照规则发布审计结果报告。注意审计一定要有项目组人员陪同，不能搞突然袭击。双方要开诚布公，坦诚相对。审计的内容：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。4、实施（问题跟踪）对审计中发现的问题，要求项目组改进，并跟进直到解决。软件质量保证-软件配置管理p 概述p 配置项p 基线 p 版本控制p 变更控制p 软件配置管理系统p 实施流程软件配置管理-概述p软件配置管理的概念软件配置管理的概念SCM（SoftwareConfigurationManagement）简单而言就是管理软件的变化，应用于软件工程过程，通常由相应的工具、过程和方法学组成。在整个软件的开发活动中占有很重要的位置。p软件配置管理的目的与益处软件配置管理的目的与益处有效的软件配置管理可以解决一些常见的问题；有效的软件配置管理可以节约用户资金；有效的软件配置管理可以提高软件开发管理的水平；有效的软件配置管理可以保护企业的知识财富。软件配置管理-配置项 p配置项定义配置项定义p 软件配置控制软件配置控制p 配置项标识配置项标识软件配置管理-配置项的定义o 所有在软件开发过程中产生的信息，总称为软件配置项，主要包括：计算机程序（源代码和可执行程序）计算机程序描述文档（对技术开发者和用户）数据（包含在程序内部或外部）软件配置管理-配置项内容配置项包含内容项目管理过程文档项目任务书；项目计划；项目周报；个人日报和周报；项目会议纪要；培训记录和培训文档；QA过程文档QA不符合报告；QA周报；评审记录；工作产品需求文档；设计文档；代码；测试文档；软件说明书和手册；项目中使用的第三方产品例如：Oracle,Java等软件配置管理-软件配置控制配置控制是配置管理的核心工作。配置控制主要包括：配置控制是配置管理的核心工作。配置控制主要包括：存取控制存取控制：设定了软件开发人员对软件基准库的存取权限，保证软件开发过程及软件产品的安全性；版本控制版本控制：是配置管理的基本要求，使得组织在任何时刻都可以获得配置项的任何一个版本；变更控制变更控制：为软件产品变更提过了一个明确的流程，要求任何进行配置管理的软件产品变更都要经过相应的授权与批准才能实施；产品发布产品发布：保证了提交给客户的软件产品是完整的、正确的。软件配置管理-配置项标识软件配置项标识是管理配置的前提。标识包括文件名和版本。软件配置项标识是管理配置的前提。标识包括文件名和版本。p确定配置项确定配置项：软件项目在开发过程中会产生成千上百个配置项，那么确定配置项是很重要的；p明确配置项标识的要求明确配置项标识的要求：项目组人员按照标识规则对配置项进行标识，最后提交给配置管理员纳入配置库统一管理；p配置项命名：(1)唯一性：在一个项目内不能出现重名，以避免混淆；(2)可追溯性：系统的要求，即名字应能体现相邻配置项之间的关系。软件配置管理-基线o常用软件基线：系统工程需求分析软件设计代码测试系统规格说明书软件需求规格说明书设计规格说明书源代码测试计划过程/数据可操作的系统软件配置管理-基线属性与优点基线是软件生存期各开发阶段末尾的特定点，也称里程碑。基线是软件生存期各开发阶段末尾的特定点，也称里程碑。n基线的属性：基线的属性：通过正式评审过程建立；存在于基线库，对基线的变更接受更高权限的控制；基线是进一步开发和修改的基准和出发点；进入基线前，不对变化进行管理；进入基线后，对变化进行有效管理；不会变化的内容不纳入基线，变化对其它无影响的也不纳入基线；基线具有名称、标识符、版本、日期等属性；交付给客户的基线成为一个Release，内部开发用的基线为一个Build。n基线的优点基线的优点重现性：当更新不稳定或不可信时，基线提供一种取消变更的方法；可追溯性：建立项目工件之间的前后继承关系；版本隔离：新项目与随后对原始项目所进的变更进行隔离。软件配置管理-基线种类o功能基线(Functional Baseline)指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标识。o指派基线(Allocated Baseline)指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标识。o产品基线(Production Baseline)指在软件组装与系统测试阶段结束时，经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标识。软件配置管理-软件过程中的配置基线需求分析设计编码测试计划基线需求基线设计基线编码基线测试基线计划项目开发计划用户手册需求规格分析详细设计说明书概要设计说明书源代码测试报告软件配置管理-版本控制o版本的访问与同步控制o版本分支和合并o版本的历史记录软件配置管理-版本的控制与同步控制l l 版本的访问控制版本的访问控制版本的访问控制版本的访问控制 工作区域中的源文件是从库中恢复得到的一个复制文件，它可以是工作区域中的源文件是从库中恢复得到的一个复制文件，它可以是可可“写写”的，也可以是可的，也可以是可“读读”的。一般有两种工作模式：的。一般有两种工作模式：一是在工作区域一旦有一是在工作区域一旦有“读读”请求，就做一次恢复操作，获得复制请求，就做一次恢复操作，获得复制文件，当文件，当“读读”操作结束，该复制文件被删除；操作结束，该复制文件被删除；二是仅当软件库中的内容发生更改时，才发生交互，而不是每次二是仅当软件库中的内容发生更改时，才发生交互，而不是每次“读读”操作都与软件库中的文件发生交互。操作都与软件库中的文件发生交互。l l 版本的同步控制版本的同步控制版本的同步控制版本的同步控制 同步控制实际上是版本的检入检出控制：同步控制实际上是版本的检入检出控制：检入：将软件配置项从用户的工作环境存入到软件配置库的过程；检入：将软件配置项从用户的工作环境存入到软件配置库的过程；检出：将软件配置项从软件配置库中取出的过程。检出：将软件配置项从软件配置库中取出的过程。软件配置管理-访问和同步控制的流程图 软件工程师软件配置库检入检出访 问控 制配置对象（修改版本）配置对象（基线版本）审计信息解锁拥有者信息加锁配置对象（基线版本）配置对象（提取版本）软件配置管理-版本分支和合并l 版本分支版本分支版本分支版本分支 版本分支人工方法就是从主版本复制一份文件，做上标记；实版本分支人工方法就是从主版本复制一份文件，做上标记；实行版本控制之后，版本的分支是一份复制文件，这时的复制过程和行版本控制之后，版本的分支是一份复制文件，这时的复制过程和标记动作由版本系统自动完成。标记动作由版本系统自动完成。l l 版本合并版本合并版本合并版本合并 版本合并是通过对文件的比较来进行合并。有两种途径：版本合并是通过对文件的比较来进行合并。有两种途径：一种是将版本一种是将版本A A的内容附加到版本的内容附加到版本B B中；中；另一种是合并另一种是合并A A和和B B的内容，形成新的的内容，形成新的C C；后一种途径更容易理解，也符合软件开发的思路。后一种途径更容易理解，也符合软件开发的思路。软件配置管理-版本的历史记录文件和目录的版本演化的历史可以形象的表示为图形化的版本树；版本树由版本依次连接形成，每个结点代表一个版本，根结点是初始版本，叶结点代表最新的版本；典型的软件系统包含多个文件和目录，每个文件和目录都有自己的版本树；版本的历史记录有助于对软件配置项进行审计，有助于追踪问题的来源；版本的历史记录应该包含版本号、修改时间、修改者、修改描述这些最基本的内容。软件配置管理-版本树o o最简单的版本树只有一个分支，就是版本树的枝干；复杂的版本树除了主干外，还可以包含很多的分支，分支可以进一步包含子分支。V1.0V1.1V1.2V1.3V2.0V1.4V2.1V1.1.1V1.1.2软件配置管理-变更控制o变更类型o变更请求管理o变更管理的实施步骤软件配置管理-变更机制变更请求CCB评估修改测试或验证关闭变更请求接受提交拒绝CCB：变更控制委员会Change Control Board 软件配置管理-变更类型l 功能变更l 功能变更是为了增加或者删除某些功能、或者为了完成某个功能的方法而需要的变更；这类变更必须经过某种正式的变更评价过程，以估计变更需要的成本和其对软件系统其他部分的影响。l 缺陷变更l 缺陷修补是为了修复漏洞需要进行的变更。在项目前期，它是必须进行的，通常不需要从管理角度对这类变更进行审查和批准。在项目后期，如果发现错误的阶段在造成错误的阶段的后面，则必须遵照标准的变更控制过程来进行。软件配置管理-变更请求管理l变更请求通常分为两个大类：增强请求：增强请求指系统的新增特征或对系统增强请求指系统的新增特征或对系统“预定设计预定设计”行为的变行为的变更。更。缺陷：指存在于一个已交付产品中的异常现象或缺陷。指存在于一个已交付产品中的异常现象或缺陷。变更请求管理过程：变更请求提交变更请求提交变更请求接收变更请求接收变更请求评估变更请求评估变更请求决策变更请求决策变更请求实现变更请求实现变更请求验证变更请求验证变更请求完成变更请求完成软件配置管理-变更请求管理流程批准变更请求?拒绝记录变更请求批准指派给相应的开发人员检出变更请求评估评估向SCM提交并验证变更请求验证相关责任人提出变更请求请求变更实现实现验证正确的变更请求检入验证变更请求关闭关闭通知相关责任人关闭变更需变更需求求软件增强缺陷软件配置管理-变更管理的实施步骤变更请求提交 缺陷和增强请求通常在请求起源和收集信息类型上不同。缺陷和增强请求通常在请求起源和收集信息类型上不同。变更请求接收 项目必须建立接收提交的变更请求并进行跟踪的机制。指项目必须建立接收提交的变更请求并进行跟踪的机制。指定接收和处理变更请求的责任人，确认变更请求。定接收和处理变更请求的责任人，确认变更请求。变更请求评估 大多数机构根据请求的类型是缺陷还是增强而使用不同的大多数机构根据请求的类型是缺陷还是增强而使用不同的评估过程。评估过程。变更请求决策 决策阶段是当选择实现一个变更请求时所做出的决定，如决策阶段是当选择实现一个变更请求时所做出的决定，如推迟此次实施或者永远不进行实施等。缺陷和增强请求几乎总推迟此次实施或者永远不进行实施等。缺陷和增强请求几乎总是以不同方式进行处理。是以不同方式进行处理。软件配置管理-变更管理的实施步骤变更请求实现 增强请求实现较之缺陷实现需要更多的设计工作，这是因为增强请求实现较之缺陷实现需要更多的设计工作，这是因为增强请求经常涉及新特性或新功能。另一方面，缺陷修复需要建增强请求经常涉及新特性或新功能。另一方面，缺陷修复需要建立一个环境，在该环境中可以对缺陷进行重现并测试相应的解决立一个环境，在该环境中可以对缺陷进行重现并测试相应的解决方案。方案。变更请求验证o 验证发生在最终测试及文档制作阶段。增强请求的测试通常验证发生在最终测试及文档制作阶段。增强请求的测试通常涉及验证所做变更是否满足该增强请求的需要。缺陷测试则简单涉及验证所做变更是否满足该增强请求的需要。缺陷测试则简单的验证开发人员的修复是否真正消除了该缺陷。的验证开发人员的修复是否真正消除了该缺陷。变更请求完成 完成是变更请求的最终阶段，这可能是完成了一项请求或者完成是变更请求的最终阶段，这可能是完成了一项请求或者决定不实现某一请求。在完成阶段的主要步骤是由提交请求的原决定不实现某一请求。在完成阶段的主要步骤是由提交请求的原有请求者中止这一循环过程。有请求者中止这一循环过程。软件配置管理-软件配置管理系统p软件配置标准p并发版本系统（CVS）pIBM-Rational的ClearCasep基于构件复用的配置管理系统JBCM软件配置管理-系统功能l 并行开发系统l 修订版管理l 版本控制l 产品发布管理l 建立管理l 过程控制l 变更请求管理l 代码共享软件配置管理-软件配置标准标志和指南简要描述EIAStandardIS-649NationalConsensusStdforConfigurationManagement,Aug.1995给出基本的给出基本的CM规则，和业界最好的实践经验来规则，和业界最好的实践经验来指导标识产品配置并进行高效、有条理的软硬件指导标识产品配置并进行高效、有条理的软硬件产品管理。产品管理。IEEEStd1042-1987,GuidetoSoftwareConfigurationManagement(ANSI)描述描述CM规则在软件工程项目中的应用。包括规则在软件工程项目中的应用。包括4个个完整的完整的SCM计划的例子。计划的例子。IEEEStd828-1990,StandardforSoftwareConfigurationManagementPlans(ANSI)确定确定SCM计划最少需要哪些内容，是计划最少需要哪些内容，是IEEEStd1042-1987的补充。应用于重要软件的整个生命的补充。应用于重要软件的整个生命周期，也适用于非重要软件和已开发的软件。周期，也适用于非重要软件和已开发的软件。IEEE/EIA12207.0-1996,IndustryImplementationofInternationalStandardISO/IEC12207:1995(ISO/IEC12207)StandardforInformationTechnologySoftwareLifecycleProcesses,Mar1998用明确的术语定义了软件生命周期的一个公共框用明确的术语定义了软件生命周期的一个公共框架。包括在系统软件、独立软件产品、软件服务架。包括在系统软件、独立软件产品、软件服务的获取过程和软件产品供应、开发、操作、维护的获取过程和软件产品供应、开发、操作、维护中的过程、活动和任务。中的过程、活动和任务。软件配置标准和指南标志和指南简要描述IEEE/EIA12207.1-1996,Lifecycledata,April1998给出了在给出了在IEEE/EIA12207.01996中的活动和中的活动和任务执行过程中哪些数据可以记录的指导。对任务执行过程中哪些数据可以记录的指导。对记录内容、记录位置、格式、和记录介质没有记录内容、记录位置、格式、和记录介质没有限定。限定。IEEE/EIA12207.2-1996,ImplementationConsiderations,April1998给出了实现给出了实现IEEE/EIA12207.0过程要求的指导。过程要求的指导。目的是总结软件业在目的是总结软件业在ISO/IEC12207的过程结构的过程结构环境方面最好的实践经验。环境方面最好的实践经验。ISO9000-3:1991(E),QualityMgmt&QualityAssuranceStds-Part3:GuidelinesfortheapplicationofISO9001tothedevelopment,supplyandmaintenanceofsoftware为应用为应用ISO9001的开发、供应、维护软件的组的开发、供应、维护软件的组织提出的指导方针。目的是在合同双方需要供织提出的指导方针。目的是在合同双方需要供应方开发、支持和维护软件产品能力的证明时应方开发、支持和维护软件产品能力的证明时提供指导。提供指导。MIL-HDBK-61,ConfigurationManagementGuidance提供了提供了DoD采购经理、后勤管理员和其他个人采购经理、后勤管理员和其他个人已指派的已指派的CM职责方面的指导和信息。为国防系职责方面的指导和信息。为国防系统和其配置项的所有生命周期阶段的实践活动统和其配置项的所有生命周期阶段的实践活动制订计划并有效实现制订计划并有效实现DoDCM活动提供帮助。活动提供帮助。软件配置管理-并发版本系统（CVS）o CVS是并发版本系统（Concurrent Versions System）的意思，主流的开放源码，网络透明的版本控制系统。它的客户机/服务器存取方法使得开发者可以从任何因特网的接入点存取最新的代码。它的无限制的版本管理检出模式避免了通常因为排它检出模式而引起的人工冲突。它的客户端工具可以在绝大多数的平台上使用。软件配置管理-CVS基本概念oCVS基本概念：仓库：它是它是CVSCVS服务器的根目录，所有的工作都保存在这个仓库；服务器的根目录，所有的工作都保存在这个仓库；模块：模块里面放的是一个项目的所有文件；模块里面放的是一个项目的所有文件；导入：将本地软件项目导入到将本地软件项目导入到CVS仓库中；仓库中；导出：将仓库中的一个模块中的东西导到本地工作目录下；将仓库中的一个模块中的东西导到本地工作目录下；提交修改：将本地修改的文件提交到将本地修改的文件提交到CVS仓库；仓库；同步：从从CVS下载修改过的文件来更新本地文件；下载修改过的文件来更新本地文件；文件版本：指的是单个文件版本；指的是单个文件版本；发行版本：整个产品的版本；整个产品的版本；标签：对一个文件或多个文件给的符号名。对一个文件或多个文件给的符号名。软件配置管理-CVS简单命令集oCVS简单命令集：检出源文件检出源文件提交命令提交命令删除删除增加文件增加文件提交源文件提交源文件软件配置管理-CVS文件状态状态状态描述 Up-to-date Up-to-date 与仓库中最新版本一致与仓库中最新版本一致 Locally modified Locally modified 已修改但未检入仓库已修改但未检入仓库 Locally added Locally added 已用已用addadd加入但未检入仓库加入但未检入仓库 Locally removed Locally removed 已用已用remove remove 删除但未检入仓库删除但未检入仓库 Needs checkout Needs checkout 有人修改，但未检出有人修改，但未检出 Needs patch Needs patch 与上面相似但与上面相似但CVSCVS只发送补丁只发送补丁 Needs merge Needs merge 他人检入新版本，也做了修改他人检入新版本，也做了修改 conflicts on merge conflicts on merge 与上面相似，但上一个与上面相似，但上一个updateupdate命令产生过冲突命令产生过冲突 软件配置管理-使用CVS进行版本控制检出 小组成员从小组成员从CVSCVS服务器上检出各自负责的模块进行开发。结束后把服务器上检出各自负责的模块进行开发。结束后把文件提交到文件提交到CVSCVS服务器；服务器；提交新文件 在项目中有新的文件加入，要提交到服务端；在项目中有新的文件加入，要提交到服务端；提交修改文件 只有一个小组成员对文件进行修改的情况；只有一个小组成员对文件进行修改的情况；两个或两个以上的小组成员对同一个文件的不同部分进行修改；两个或两个以上的小组成员对同一个文件的不同部分进行修改；两个或两个以上的小组成员对同一个文件的相同部分进行修改。两个或两个以上的小组成员对同一个文件的相同部分进行修改。标记分支管理软件配置管理-IBM-Rational的ClearCaselRational Rose公司推出的软件配置管理工具ClearCase提供了比较全面的配置管理支持，包括：版本控制 工作空间管理 建立管理 过程控制软件配置管理-ClearCase版本控制 ClearCaseClearCase的核心功能是版本控制的核心功能是版本控制支持广泛的文件类型支持广泛的文件类型在版本树中观察构件发展的过程在版本树中观察构件发展的过程对目录和子目录进行版本控制对目录和子目录进行版本控制使用常见的检出使用常见的检出/编辑编辑/检入范例检入范例丰富的数据信息丰富的数据信息自动的比较和版本间的归并自动的比较和版本间的归并软件配置管理-ClearCase工作空间管理空间管理：即保证开发人员拥有自己独立的工作环境，拥有自空间管理：即保证开发人员拥有自己独立的工作环境，拥有自己的私人存储区，同时可以访问成员间的共享信息。己的私人存储区，同时可以访问成员间的共享信息。ClearCaseClearCase给每一位开发者提供了一致、灵活的工作空间域。给每一位开发者提供了一致、灵活的工作空间域。版本间的透明访问。开发人员不必进入版本间的透明访问。开发人员不必进入ClearCaseClearCase界面就可以直界面就可以直接完成相关操作。接完成相关操作。通过规则试图选择并显示版本通过规则试图选择并显示版本从没有安装从没有安装ClearCaseClearCase的主机平台进行视图访问的主机平台进行视图访问软件配置管理-ClearCase过程控制oClearCaseClearCase为团队通信、质量保证、变更管理提供了非常有效的为团队通信、质量保证、变更管理提供了非常有效的过程控制和策略控制机制：过程控制和策略控制机制：为对象分配属性为对象分配属性 超级链接超级链接 历史记录历史记录 定义事件触发机制定义事件触发机制 访问控制访问控制 查询功能查询功能软件配置管理-基于构件复用的配置管理系统JBCMo青鸟软件配置管理系统（简称青鸟软件配置管理系统（简称JBCMJBCM系统）系统）是一套在软件开发中用于配置管理的系统，可用于是一套在软件开发中用于配置管理的系统，可用于管理软件开发过程中的各种产品，帮助管理软件开发中管理软件开发过程中的各种产品，帮助管理软件开发中出现的各种变化和演变方向，跟踪软件开发的过程，保出现的各种变化和演变方向，跟踪软件开发的过程，保存软件开发过程中待开发软件系统的状态，供用户随时存软件开发过程中待开发软件系统的状态，供用户随时提取，简化开发过程的管理工作，有助于软件开发和维提取，简化开发过程的管理工作，有助于软件开发和维护工作的有序进行。护工作的有序进行。JBCM的软件开发模型项目/构件结构o在在JBCMJBCM系统中，软件开发主要分为两个层次：项目和构件。系统中，软件开发主要分为两个层次：项目和构件。项目指的是一个可以独立开发的软件系统。项目指的是一个可以独立开发的软件系统。构件是构件是JBCMJBCM系统进行版本管理的基本单位。一个项目可以含有一系统进行版本管理的基本单位。一个项目可以含有一个或多个构件。个或多个构件。创建项目和构件创建项目和构件文件的版本结构，它以版本树的结构跟踪记录文件的变化。文件的版本结构，它以版本树的结构跟踪记录文件的变化。构件的版本结构，也是以版本树来表示。但是它引入了分支的概构件的版本结构，也是以版本树来表示。但是它引入了分支的概念，每个分支有自己的版本变化树，反映构件的一个变化方向。念，每个分支有自己的版本变化树，反映构件的一个变化方向。文件版本和构件版本之间的关系文件版本和构件版本之间的关系JBCM的软件开发模型构件划分方法JBCM的软件开发模型JBCM中构件的版本树o 版本1.0版本1.1版本1.2版本1.1.1版本1.1.1.0版本1.1.1.1JBCM的软件开发模型主要功能 用户管理用户管理 用户管理是用户管理是JBCMJBCM的重要部分，分为：系统级、项目级、构件级。的重要部分，分为：系统级、项目级、构件级。版本管理版本管理 版本管理是配置管理的核心。在版本管理是配置管理的核心。在JBCMJBCM系统中，文件的版本管理隐系统中，文件的版本管理隐藏在构件版本管理之下。藏在构件版本管理之下。构件管理构件管理 配置管理是构件版本管理基础上的高层应用功能。配置管理是构件版本管理基础上的高层应用功能。团队管理团队管理 JBCMJBCM系统系统的控制，可以明确的检出各用户的工作状态与工作资源。的控制，可以明确的检出各用户的工作状态与工作资源。JBCM的软件开发模型用户权限JBCM的软件开发模型文件的操作权限模式模式说明说明只读只读用户只是从配置库中读取指定文件的内容，而不准备用户只是从配置库中读取指定文件的内容，而不准备对文件加以修改。只读的文件不必检入。对文件加以修改。只读的文件不必检入。排他写（独占排他写（独占写）写）用户打算对文件加以修改，而且规定自己在修改时，用户打算对文件加以修改，而且规定自己在修改时，其他用户不能修改此文件。排他写的文件应该检入，其他用户不能修改此文件。排他写的文件应该检入，但用户如果对此次修改不满意，可以取消检出。但用户如果对此次修改不满意，可以取消检出。共享写共享写用户打算对文件加以修改，但允许其他用户也同时修用户打算对文件加以修改，但允许其他用户也同时修改此文件。共享写的文件可以检入，也可以取消检出。改此文件。共享写的文件可以检入，也可以取消检出。检入时，如果另一个修改此文件的用户先于自己检入检入时，如果另一个修改此文件的用户先于自己检入了，则系统会将此文件的这两个版本自动合并。了，则系统会将此文件的这两个版本自动合并。软件配置管理-实施流程软件配置管理-实施流程软件配置管理-实施流程o配置管理计划 1、软件开发者在制定开发计划的同时制定，包括：项目的内容，基线定义及管理要素，组织结构，配置标识、控制、状态记录、核查及认证。2、成立配置控制小组。o做（同变更控制）o检查1、保持纳入基线的软件状态并使其可见。2、验证配置过程是否按计划执行。3、验证变更请求文档是否包含要求的信息，是否已按要求更新。o实施形成报告，分析问题，持续改进。软件评审o为什么需要评审o软件评审的角色和职能o评审的内容o评审的方法和技术o准备评审会议o召开评审会议o跟踪和分析评审结果o如何实施成功的评审软件评审-为什么需要评审o从成本上来衡量 缺陷发现得越晚纠正费用越高，而软件评审的重要目的就是通过软件评审尽早的发现产品中的缺陷，减少大量的后期返工。软件评审-为什么需要评审从技术上来衡量 前一阶段的错误自然会导致后一阶段的工作结果中有相应的错误，而且错误会逐渐累积，越来越多。软件评审-软件评审的角色和职能 协调人（负责人）作者评审员专家用户代表质量保证代表 记录员其它相关方软件评审-评审的内容o管理评审o技术评审o文档评审o过程评审软件评审-管理评审 由最高管理者就质量方针和目标对质量体系的现状和适应性进行正式评价。软件评审-管理评审 质量管理体系运行状况 内、外部审核结果 改进、预防和纠正措施的状况 上次管理评审提出的改进措施实施情况及验证信息管理评审管理评审 质量体系的总体评价 质量管理体系及其过程的改进 产品是否符合要求的评价，有关产品的改进 新资源的需求的决定和措施 输入输入输出输出对质量体系进行回顾和总结并确保其适宜性、有效性和充分性适宜性、有效性和充分性 软件评审-技术评审 评审的目的 评审的内容 评审检查单 其他必需文档技术评审技术评审技术评审报告会议的基本信息 存在的问题和建议措施评审结论和意见问题跟踪表技术评审问答记录 输入输入输出输出软件评审-文档评审o正确性o完整性o一致性o有效性o易测性o模块化-系统和文档描述必须深入到模块。模块化即模块的独立性o清晰性o可行性o可靠性o可追溯性软件评审-过程评审o 过程评审的目的：评估主要的质量保证流程考虑如何处理/解决评审过程中发现的不符合问题总结和共享好的经验指出需要进一步完善和改进的地方o 评审结束后，评审小组需要提交一份评审报告，其中包括：评审记录评审后，对现有流程的说明和注释评审小组的建议 软件评审过程评审流程软件评审-评审的方法和技术o评审的方法o评审的技术软件评审-评审的方法临时评审（Ad hoc review）轮查（Pass-round）走查（Walkthrough）小组评审（Group Review）审查（Inspection）最不正式最不正式最正式最正式临时评审临时评审轮查轮查走查走查小组评审小组评审审查审查软件评审-评审的方法o审查、小组评审和走查异同点比较表 角色/职责审查小组评审走查主持者主持者评审组长评审组长或作者或作者作者作者材料材料陈述者述者评审者者评审组长作者作者记录员是是是是可能可能专门的的评审角色角色是是是是否否检查表表是是是是否否问题跟踪和分析跟踪和分析是是可能可能否否产品品评估估是是是是否否评审方法计划准备会议修正确认审查有有有有有有有有有有小小组评审有有有有有有有有有有走走查是是无无有有有有无无软件评审-评审的方法如何选择正确的评审方法？n选择评审方法最有效的标准是：选择评审方法最有效的标准是：“对于最可能产生风险的工作成果，要采用对于最可能产生风险的工作成果，要采用最正式的评审方法。最正式的评审方法。”n例如：核心代码的失效也会带来很严重的后果，例如：核心代码的失效也会带来很严重的后果，所以也应该采用审查或小组评审的方法进行评审，所以也应该采用审查或小组评审的方法进行评审，而一般的代码则可以采用临时评审、同桌评审等比而一般的代码则可以采用临时评审、同桌评审等比较随意的评审方法。较随意的评审方法。软件评审-评审的技术缺陷检查表它列出了容易出现的典型错误，是评审的一个重要组成部分。规则集类似于缺陷检查表，通常是业界通用的规范或者企业自定义的各种规则的集合。评审工具的使用合理的利用工具，如NASA开发的ARM（自动需求度量）从不同角色理解不同的角色对产品/文档的理解是不一样的。场景按照用户使用场景对产品/文档进行评审。软件评审-准备评审会议o 评审计划 各阶段评审计划的内容包括：各个阶段的评审时间、评审方式、评审组成员等。SQA在其提交的质量保证计划中，应根据各个阶段的评审计划，制定相应的评审检查点。软件评审-准备评审会议o 组建评审组 项目组提出评审组长和评审组成员名单建议，质量组根据项目组的建议，与相关部门或人员（如外协单位负责人）进行协商确定。选定评审组长对评审来说是非常重要的，评审组长需要和作者一起，策划和组织整个评审活动。软件评审-准备评审会议o 准备评审材料 基础性和早期的文档，如需求说明和原型等 与重大决策有关的文档，如体系结构模型 对如何做没有把握的部分，如一些挑战性模块，他们实现了不熟悉的或复杂的算法，或涉及复杂的商业规则等 将不断被重复使用的部件软件评审-准备评审会议o 发送审查包 将被审查的可交付产品/文档，其中指明了需要审查的部分 定义了可交付产品的前期文档 相关标准或其他参考文档 参与者需要的所有表格 有助于审查者发现缺陷的工具/文档：如缺陷检查表，相关规则等 用于验证可交付产品的测试文档软件评审-准备评审会议o 制定活动进程表 评审会议之前，评审组长还需要制定相应的活动进度表，安排会议房间，并将活动、日程、次数和地点通知评审组成员 软件评审-召开评审会议o评审的主要步骤：1、由评审员/作者进行演示或说明。2、评审员会就不清楚或疑惑的地方与作者进行沟通。3、协调人或记录员在会议过程中完成会议记录。软件评审-召开评审会议o评审结果：接受，评审内容不存在大的缺陷，可以通过评审内容不存在大的缺陷，可以通过有条件接受，评审内容不存在大的缺陷，修订其中评审内容不存在大的缺陷，修订其中的一些小缺陷后，可以通过的一些小缺陷后，可以通过不能接受，评审内容中有较多的缺陷，作者需要对评审内容中有较多的缺陷，作者需要对这些缺陷进行修改，并在修改之后重新进行评审。这些缺陷进行修改，并在修改之后重新进行评审。评审未完成，由于某种原因，评审未能完成，还需由于某种原因，评审未能完成，还需要后续会议要后续会议软件评审-召开评审会议o评审中的注意事项：人身攻击 在评审过程中，所有的参与人都应该将矛在评审过程中，所有的参与人都应该将矛盾集中于评审内容本身，而不能针对特定的参与人。盾集中于评审内容本身，而不能针对特定的参与人。无休止的争论 通常对于某些问题，评审组很难达成通常对于某些问题，评审组很难达成一致意见，这时，可以把问题记录下来，而如何认定则留一致意见，这时，可以把问题记录下来，而如何认定则留给作者自己决定。给作者自己决定。偏离会议主题 在实际会议中，会议常常会发生偏离，在实际会议中，会议常常会发生偏离，如转到政治话题的讨论。如转到政治话题的讨论。鼓励所有人发言 鼓励不擅言辞的参与者就评审内容鼓励不擅言辞的参与者就评审内容发表自己的看法，比如按照座位顺序轮流发表意见。发表自己的看法，比如按照座位顺序轮流发表意见。软件评审-跟踪和分析评审结果o评审结果的跟踪评审结果为有条件接受评审结果为不接受 o评审结果的分析有效性效率和成本软件评审-如何实施成功的评审o解决不成功评审的主观因素：1.对所有的工程师进行评审的培训，使评审深入人心对所有的工程师进行评审的培训，使评审深入人心2.预防个人冲突，尽量避免对作者有人身攻击的工程师预防个人冲突，尽量避免对作者有人身攻击的工程师加入评审小组加入评审小组3.将评审活动加入到项目计划中，并为评审分配足够的将评审活动加入到项目计划中，并为评审分配足够的资源资源4.收集以前的评审数据，了解哪一种评审方法最为有效收集以前的评审数据，了解哪一种评审方法最为有效5.将评审列入个人的时间表中，确保评审员有充分的时将评审列入个人的时间表中，确保评审员有充分的时间为评审做准备和参加评审间为评审做准备和参加评审软件评审-如何实施成功的评审o解决不成功评审的客观因素：异步评审-如共享文档、邮件评审如共享文档、邮件评审分布式评审-如视频会议如视频会议地点时间相同不同相同传统的评审方式传统的评审方式 异步评审异步评审 不同分布式评审分布式评审 异步评审异步评审 SQASQA不关心不关心不关心不关心产品最终质量产品最终质量产品最终质量产品最终质量