第11章软件质量管理与配置管理

1第11章软件质量管理与软件配置管理（参考第24章、第25章）软件质量管理◆软件质量◆软件质量标准◆复查与审查软件配置管理◆有关概念◆变更管理◆版本管理◆系统构建◆发布版本管理2软件质量管理就是确保软件有较少的缺陷数，并达到可维护性、可靠性、可移植性、效率等既定标准。质量管理是对软件开发过程进行的独立的检查活动（如图所示）。应有独立的团队专门负责质量管理。D1D2D3D4D5软件开发过程质量管理过程标准和规程质量规划质量评审报告…软件质量管理与软件开发的并行过程11.1软件质量管理3软件质量管理由以下三个主要活动构成：•质量保证定义和选择应用于软件开发过程和软件产品的标准，建立起机构质量规程和质量标准的整体框架，•质量规划从这个框架中选择适当的规程和标准，为某一软件项目制定质量计划。•质量控制定义并实施质量管理过程，确保开发团队严格遵守项目质量规程和标准。4软件质量保证(SoftwareQualityAssurance，SQA)活动为达到高质量软件提供了一个框架。该活动包括：•制定软件开发过程标准或软件产品标准•采用有效的软件工程方法和工具•过程中采用的正式技术评审•一种多层次的测试策略•对软件文档及其修改的控制•保证规程和标准被严格执行•软件度量及报告机制等方面的内容。5质量规划在软件过程的早期阶段进行。规划说明产品的质量要求以及产品质量的评定方法（规范）。具体内容包括：•产品介绍：产品的性质、意向市场•产品计划：发布日期、销售及服务计划•过程描述：产品开发和管理中应采用的标准•质量目标：鉴定和验证产品的关键质量属性•风险和风险管理：主要风险及应对措施质量控制就是监督检查整个软件开发过程，确保质量保证过程和标准被严格执行。611.1.1软件质量1.软件质量定义软件质量是软件产品和过程的一组固有特性满足用户和其他相关方要求的程度。2.软件质量的特性（属性）：在教材P415图24-2列出的质量属性有：安全性、信息安全性（保密性）、可靠性、可调节性、鲁棒性、可理解性、可测视性、适用性、模块化、复杂度、可移植性、可用性、复用率、效率、可学习性等。73.过程质量对产品质量的作用软件开发过程的质量直接影响产品的质量，过程相对易于标准化和监控。过程质量的管理和改进能减少软件开发中产生的缺陷。但软件开发是创造性活动，人的技能和经验对软件质量影响很大。过程质量管理包括：•制定过程标准，包括如何进行评审、何时进行评审等。•对开发过程进行监控，确保过程标准的贯彻执行。•向项目管理层和客户报告软件过程的进展情况。8软件标准是对成功实践的认同。标准为开发一个优秀质量的软件提供了坚实的基础。软件标准在软件质量管理中扮演着重要的角色，因为：1.标准封装了成功的实践经验，可以避免重犯错误。2.有助于控制软件质量。通过使用标准，为判断软件是否达到要求的质量水平建立了基础。3.有助于开发工作的连贯性。都采用相同的做法。11.1.2软件标准9在质量管理中。有两类可以定义和使用的的标准：•产品标准包括文档标准（如需求文档结构）、文档编写标准（如注释的标准写法）、编码标准等。•过程标准定义软件开发必须遵循的过程（封装良好的开发方法）。如描述、设计和有效性验证过程、软件变更控制过程、版本发布过程等。1011.1.3复查与审查复查（review)和审查（inspection）是检查项目可交付文档的质量的QA活动，和软件测试一样，作为软件检验和有效性验证（V&V）过程的一部分。质量复查基于软件开发中产生的文档来进行。软件描述、设计、代码、过程模型、测试计划、配置管理规程、过程标准以及用户指南等都被复查，还应当检查文档和代码的一致性、完整性，确保遵循质量标准。11复查不仅仅是检验与标准的一致性，还帮助发现软件和项目文档中的问题和遗漏。复查的结果作为质量管理过程的一部分被正式记录。复查与审查的目的是提升软件的质量.质量复查不同与管理过程复查。过程复查是将软件开发的实际过程与计划对比，主要关注点是工程是否能够按时并在预算范围内提交有用的软件，同时将外部环境因素考虑在内。121.复查过程复查过程分为3各阶段：1）复查前活动：建立复查团队，安排时间，分发复查文档。复查团队成员需阅读并理解软件、文档及相关标准。2）复查会议：文档或程序的作者和复查团队成员一起讨论，并记录复查决议和要采取的行动。3）复查后活动：解决提出的问题，修复漏洞，重构软件使它与质量标准相一致。进一步检查是否覆盖了所有的复查意见。规划团队准备个人准备复查会议错误改正重构跟踪复查意见复查前活动复查后活动软件复查过程活动图13敏捷开发中的复查过程是非正式的，如Scrum方法，在每次的软件迭代完成后有一个复查会议；极限编程方法中的结对编程。敏捷方法依赖于个人主动性来提升和重构代码，通常不考虑标准一致性的问题。142.程序审查程序审查是“同行评审”，开发团队成员合作来发现程序中的漏洞。不执行程序，所以与测试互补。程序审查涉及不同背景的团队成员，他们需详细检查设计模型和代码。审查时，需使用一份常见错误的检查表（来自书本的实例和应用领域的错误经验，见下页表），该表由机构根据部门标准和实践自己开发，并应经常更新。Fagan（1986）和McConnell（2004）都报告了通过程序审查错误检测率可以达到60%以上。1511.2软件配置管理软件配置管理（SoftwareConfigurationManagement，SCM）是应用于整个软件过程中的庇护性活动。软件配置是一个软件产品在生存期各个阶段的不同形式和不同版本的程序、文档及相关数据的集合。SCM是对软件开发过程中的各阶段产品和最终产品的演化与变更以及版本与发布管理。是CMMI第二级中的关键过程域。它的主要目的是对变更加以控制，将变更对成本、进度和质量影响降到最小。16软件配置管理的活动系统构建版本管理变更管理发布管理组件版本系统版本系统发布版本变更提议SCM中四个相关的活动171.变更管理：评估来自客户和开发者的软件变更请求，分析变更的影响，估算变更的费用，决策是否变更，何时变更。2.版本管理：跟踪系统组件的多个版本，确保不同开发者对组件做出的变更不会彼此影响。3.系统构建：将系统组件装配成可执行程序的过程。4.发布管理：决定发布或提交一个系统的时间，准备好所有待发布的信息（可执行文件、数据文件、配置文件和文档等），并为每个系统发布版本编制好文档。18配置管理需要工具的支持，工具用来追踪变更提议，存储系统组件的多个版本，从这些组件中构建系统，并跟踪系统版本的实际发布。SCM中的有关术语：术语解释软件配置项（SCI）程序、文档、数据、组件等，是软件工程过程中创建的信息。配置项会存在多个不同的版本。每个配置项都有一个唯一的名字。配置控制对系统和组件的版本进行记录、识别、储存和维护的过程，确保变更得到管理。版本配置项的一个实例。有一个唯一的标示符（如名字+版本号）19基线开发各阶段不能轻易改变的软件版本（底线）。基线是受控的，即构成系统的软件版本是不能轻易改变的。基线作用用于控制变更，禁止开发人员随便修改一个“已冻结”的工作成果。代码线软件组件以及组件所依赖的其它配置项的集合。主线系统不同版本的基线的序列。工作空间一个私有的工作空间中，对软件的修改不会影响其他开发者对该软件的使用。分支从现存的代码线版本中创建一个新的代码线，新代码线和已存在的代码线可以并行开发。合并通过合并在不同代码线中的单独版本来创建软件的新版本。这些代码线可能由某个代码线先前存在的分支所创建。系统构建通过链接组件和库中适当版本创建一个可执行的系统版本。IEEE对基线的定义：已经通过正式评审和批准的规约或产品，可以作为进一步开发的基础，并且只能通过正式的变更控制规程才能改变它。20SCISCISCISCISCI配置项库基线：软件需求规约软件设计规约源代码测试规程/用例可运行的系统存储提取软件工程任务修改正式技术评审批准SCM控制基线化的SCI和项目数据库（参考教材1）21AA1.1A1.2A1.3BB1.1B1.2B1.3CC1.1C1.2C1.3L1L2EX1EX2代码线（A）代码线（B）代码线（C）库和外部组件AB1.2C1.1L1L2EX1基线-V1A1.3B1.2C1.2L1L2EX1基线-V2代码线、基线、主线主线（基线的序列）2211.2.1变更管理变更管理的任务•分析变更请求：研究变更的必要性、经济可行性（成本－效益比，是否合理）和技术可行性。•记录和追踪变更、评估变更的影响。•采取措施保证变更在受控状态下进行。变更管理过程见下图：23变更管理过程（参考教材1）24变更管理过程从分析变更请求开始，处于开发状态的配置项尚未稳定下来，不受SCM的控制，对配置项的变更不受限制。当开发人员认为工作已告完成，可供其他配置项使用时，配置项进入评审状态，若通过评审就作为基线允许进入配置项数据库（check-in)，配置项处于受控状态，开发人员不允许随便对其做任何修改。配置项的状态变化见下图。对配置项的变更控制25两个主要的变更控制因素：•访问控制：管理哪个程序员有权访问和修改SCI。•同步控制：保证两个不同人员完成的并行变更不会相互覆盖。访问控制与同步控制流程如下图所示：配置项的状态变化评审状态受控状态工作状态开发人员满意通过评审checkin未通过评审checkout26配置对象的同步存取控制流程加锁：使得当前被提取的版本在放回之前别人不能对它作任何修改（同步控制）。解锁：在经过SQA和测试后，提交修改后的版本（新的基线对象）并被解锁。（该变更管理的模式为Lock-Modify-Unlock模式）2711.2.2.版本管理版本管理是跟踪软件组件或配置信息由于变更而产生的不同版本的过程。一个系统版本就是一个系统的具体实例。版本有内部版本和发布版本。一个系统的内部版本要比发布版本多得多。系统的内部版本是为内部开发或测试而创建，内部版本趋于稳定后，才决定产生发布版本。版本管理也包括确保由不同开发者做出的变更不会彼此影响，因此也看做是管理代码线和基线的过程。28基线很重要，开发者常常不得不重建一个完整系统的特定版本。如，一个产品线需要实例化为不同客户产生不同的个人系统版本。假如客户报告了系统中的错误，开发者不得不重建这个版本。为了支持版本管理，使用版本管理工具（或称版本管理系统）。提供以下功能或特征（1-5）：29有以下基本的标识模式：•版本编号每一个版本或组件对应一个明确的、唯一的编号，如V1.0、V1.1、V1.2…。优点是简单。•基于属性的标识每个版本或组件由名字和相关属性共同标识。如：V(Language=Java，Platform=WinNT，Date=Jan1999)优点是便于属性上的多种查询，如查询“最新创建的版本”。•面向变更的标识关联到一个或多个变更。如：V1.0-bugfix表示版本V1.0的缺陷修复版本；V1.0-build-003表示版本V1.0开发过程中生成的第3次构建。V1.0-rel01表示版本V1.0的第1个发布版本。V1.0-rel01-p001表示发布版本V1.0-rel01的第001号补丁。1.版本识别：给版本分配标识符。302.存储管理：为了减少只有少许差异的不同版本所占存储空间，版本管理系统提供存储管理工具。系统只存储每个版本不同之处的列表（增量），而不是每个版本的副本。将这个列表应用到源版本上（通常是被完整地存储的最近的版本），就能重建目标版本。V1.0V1.1V1.2V1.3D1D2D3V1.2源代码最近版本创建日期使用增量备份的存储管理增量备份存储变更代码行，并封装重建系统版本的指令自动创建313.变更历史记录：记录并列出所有对系统或组件做出的变更。可以利用这些有标记的变更选择一个特殊的系统版本。4.独立开发：不同的开发者可能在同一时间正在相同的组件上工作。版本管理系统能跟踪检出的组件，确保由不同开发者对组件做出的变更不会彼此影响。5.项目支持：版本管理系统可以支持共享组件的多个项目的开