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

《第11章软件质量管理与配置管理.ppt》由会员分享，可在线阅读，更多相关《第11章软件质量管理与配置管理.ppt（44页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第第11章章 软件质量管理软件质量管理 与软件配置管理与软件配置管理 （参考第（参考第24章、第章、第25章）章）n软件质量管理软件质量管理 软件质量软件质量 软件质量标准软件质量标准 复查与审查复查与审查n软件配置管理软件配置管理 有关概念有关概念 变更管理变更管理 版本管理版本管理 系统构建系统构建 发布版本管理发布版本管理1n软件质量管理就是确保软件有较少的缺陷数，并达到软件质量管理就是确保软件有较少的缺陷数，并达到可维护性、可靠性、可移植性、效率等既定标准。可维护性、可靠性、可移植性、效率等既定标准。n质量管理是对软件开发过程进行的独立的检查活动质量管理是对软件开发过程进行的独立的检查

2、活动（如图所示）。应有独立的团队专门负责质量管理。（如图所示）。应有独立的团队专门负责质量管理。D1D2D3D4D5软件开发过程软件开发过程质量管理过程质量管理过程标准和规程标准和规程 质量规划质量规划 质量评审报告质量评审报告 软件质量管理与软件开发的并行过程软件质量管理与软件开发的并行过程11.1 软件质量管理软件质量管理2n软件质量管理由以下三个主要活动构成：软件质量管理由以下三个主要活动构成：质量保量保证 定定义和和选择应用于用于软件开件开发过程和程和软件件产品的品的标准，建立起机构准，建立起机构质量量规程和程和质量量标准准的整体框架，的整体框架，质量量规划划 从从这个框架中个框架中选

3、择适当的适当的规程和程和标准，准，为某一某一软件件项目制定目制定质量量计划。划。质量控制量控制 定定义并并实施施质量管理量管理过程，确保开程，确保开发团队严格遵守格遵守项目目质量量规程和程和标准。准。3n软件质量保证软件质量保证(Software Quality Assurance，SQA)活活动为达到高质量软件提供了一个框架。该活动包括：动为达到高质量软件提供了一个框架。该活动包括：制定制定软件开发过程标准或软件产品标准软件开发过程标准或软件产品标准 采用采用有效的软件工程方法和工具有效的软件工程方法和工具 过程中采用的正式技术评审过程中采用的正式技术评审 一种一种多层次的测试策略多层次的测

4、试策略 对软件文档及其修改的控制对软件文档及其修改的控制 保证规程和标准被严格执行保证规程和标准被严格执行 软件度量及报告机制软件度量及报告机制 等方面的内容。等方面的内容。4n质量规划质量规划在软件过程的早期阶段进行。规划说明产品在软件过程的早期阶段进行。规划说明产品的质量要求以及产品质量的评定方法（规范）。具体的质量要求以及产品质量的评定方法（规范）。具体内容包括：内容包括：产品介品介绍：产品的性品的性质、意向市、意向市场 产品品计划：划：发布日期、布日期、销售及服售及服务计划划 过程描述：程描述：产品开品开发和管理中和管理中应采用的采用的标准准 质量目量目标：鉴定和定和验证产品的关品的关

5、键质量属性量属性 风险和和风险管理：管理：主要主要风险及及应对措施措施 质量控制质量控制就是监督检查整个软件开发过程，确保质量就是监督检查整个软件开发过程，确保质量保证过程和标准被严格执行。保证过程和标准被严格执行。511.1.1 软件质量软件质量 1.软件质量软件质量定义定义 软件质量软件质量是软件产品和过程的一组固有特性满足是软件产品和过程的一组固有特性满足用户和其他相关方要求的程度。用户和其他相关方要求的程度。2.软件质量的特性（属性）：软件质量的特性（属性）：在教材在教材P415图图24-2列出的质量属性有：列出的质量属性有：安全性、信息安全性（保密性）、可靠性、可调节安全性、信息安全

6、性（保密性）、可靠性、可调节性、鲁棒性、可理解性、可测视性、适用性、模块化、性、鲁棒性、可理解性、可测视性、适用性、模块化、复杂度、可移植性、可用性、复用率、效率、可学习性复杂度、可移植性、可用性、复用率、效率、可学习性等。等。6 3.过程程质量量对产品品质量的作用量的作用 软件开发过程的质量直接影响产品的质量，过程软件开发过程的质量直接影响产品的质量，过程相对易于标准化和监控。过程质量的管理和改进能减相对易于标准化和监控。过程质量的管理和改进能减少软件开发中产生的缺陷。少软件开发中产生的缺陷。但软件开发是创造性活动，人的技能和经验对软但软件开发是创造性活动，人的技能和经验对软件质量影响很大件

7、质量影响很大。过程质量管理包括：过程质量管理包括：制定制定过程程标准，包括如何准，包括如何进行行评审、何、何时进行行评审等。等。对开开发过程程进行行监控，确保控，确保过程程标准的准的贯彻执行。行。向向项目管理目管理层和客和客户报告告软件件过程的程的进展情况。展情况。7n软件标准软件标准是对成功实践的认同。标准为开发一个优秀质是对成功实践的认同。标准为开发一个优秀质量的软件提供了坚实的基础。量的软件提供了坚实的基础。n软件标准在软件质量管理中扮演着重要的角色，因为：软件标准在软件质量管理中扮演着重要的角色，因为：1.标准封装了成功的实践经验，可以避免重犯错误。标准封装了成功的实践经验，可以避免重

8、犯错误。2.有助于控制软件质量有助于控制软件质量。通过使用标准，为判断软件通过使用标准，为判断软件是否达到要求的质量水平建立了基础。是否达到要求的质量水平建立了基础。3.有助于开发有助于开发工作的连贯性。都采用相同的做法。工作的连贯性。都采用相同的做法。11.1.2 软件标准软件标准8 在质量在质量管理中。有两类可以定义和使用的的标准管理中。有两类可以定义和使用的的标准：产品标准产品标准 包括文档标准（如需求文档结构）、包括文档标准（如需求文档结构）、文档编写标准（如注释的标准写法）、编码标准等。文档编写标准（如注释的标准写法）、编码标准等。过程标准过程标准 定义软件开发必须遵循的过程（封装定

9、义软件开发必须遵循的过程（封装良好的开发方法）。如描述、设计和有效性验证过程、良好的开发方法）。如描述、设计和有效性验证过程、软件变更控制过程、版本发布过程等。软件变更控制过程、版本发布过程等。911.1.3 复查与审查复查与审查n复查复查（review)和审查（和审查（inspection）是检查项目可交）是检查项目可交付文档的质量的付文档的质量的QA活动，和软件测试一样，作为软活动，和软件测试一样，作为软件检验和有效性验证（件检验和有效性验证（V&V）过程的一部分。）过程的一部分。n质量复查基于软件开发中产生的文档来进行。软件描质量复查基于软件开发中产生的文档来进行。软件描述、设计、代码、

10、过程模型、测试计划、配置管理规述、设计、代码、过程模型、测试计划、配置管理规程、过程标准以及用户指南等都被复查，还应当检查程、过程标准以及用户指南等都被复查，还应当检查文档和代码的一致性、完整性，确保遵循质量标准。文档和代码的一致性、完整性，确保遵循质量标准。10n复查不仅仅是检验与标准的一致性，还帮助发现软件复查不仅仅是检验与标准的一致性，还帮助发现软件和项目文档中的问题和遗漏。复查的结果作为质量管和项目文档中的问题和遗漏。复查的结果作为质量管理过程的一部分被正式记录。理过程的一部分被正式记录。n复查与审查的目的是提升软件的质量复查与审查的目的是提升软件的质量.n质量复查不同与管理过程复查。

11、质量复查不同与管理过程复查。过程复查是将软件开发的实际过程与计划对比，过程复查是将软件开发的实际过程与计划对比，主要关注点是工程是否能够按时并在预算范围内提交主要关注点是工程是否能够按时并在预算范围内提交有用的软件，同时将外部环境因素考虑在内。有用的软件，同时将外部环境因素考虑在内。111.复查过程复查过程n复查过程分为复查过程分为3各阶段各阶段：1）复查前活动：）复查前活动：建立复查团队，安排时间，分发复查文档。复查建立复查团队，安排时间，分发复查文档。复查团队成员需阅读并理解软件、文档及相关标准。团队成员需阅读并理解软件、文档及相关标准。2）复查会议：文档或程序的作者和复查团队成员一起讨论

12、，并记）复查会议：文档或程序的作者和复查团队成员一起讨论，并记录复查决议和要采取的行动。录复查决议和要采取的行动。3）复查后活动：解决提出的问题，修复漏洞，重构软件使它与质）复查后活动：解决提出的问题，修复漏洞，重构软件使它与质量标准相一致。进一步检查是否覆盖了所有的复查意见量标准相一致。进一步检查是否覆盖了所有的复查意见。规划规划团队准备团队准备个人准备个人准备复查会议复查会议错误改正错误改正重构重构跟踪复跟踪复查意见查意见复查前活动复查前活动复查后活动复查后活动软件复查过程活动图软件复查过程活动图12n敏捷开发中的复查过程是非正式的，如敏捷开发中的复查过程是非正式的，如Scrum方方法，在

13、每次的软件迭代完成后有一个复查会议；法，在每次的软件迭代完成后有一个复查会议；极限编程方法中的结对编程。极限编程方法中的结对编程。n敏捷方法依赖于个人主动性来提升和重构代码，敏捷方法依赖于个人主动性来提升和重构代码，通常不考虑标准一致性的问题。通常不考虑标准一致性的问题。132.程序审查程序审查n程序审查是程序审查是“同行评审同行评审”，开发团队成员合作来发现开发团队成员合作来发现程序中的漏洞。不执行程序，所以与测试互补。程序中的漏洞。不执行程序，所以与测试互补。n程序审查涉及不同背景的团队成员，他们需详细检查程序审查涉及不同背景的团队成员，他们需详细检查设计模型和代码。设计模型和代码。n审查

14、时，需使用一份常见错误的检查表（来自书本的审查时，需使用一份常见错误的检查表（来自书本的实例和应用领域的错误经验，见下页表），该表由机实例和应用领域的错误经验，见下页表），该表由机构根据部门标准和实践自己开发，并应经常更新。构根据部门标准和实践自己开发，并应经常更新。nFagan（1986）和）和McConnell（2004）都报告了通过程）都报告了通过程序审查错误检测率可以达到序审查错误检测率可以达到60%以上。以上。14 11.2 软件配置管理软件配置管理 软件配置管理软件配置管理（Software Configuration Management，SCM）是应用于整个软件过程中的庇）是应

15、用于整个软件过程中的庇护性活动。软件护性活动。软件配置是一个软件产品在生存期各个阶配置是一个软件产品在生存期各个阶段的不同形式和不同版本的程序、文档及相关数据的段的不同形式和不同版本的程序、文档及相关数据的集合。集合。SCM是对是对软件开发过程中软件开发过程中的各阶段产品和最终产的各阶段产品和最终产品的演化与变更以及版本与发布管理。是品的演化与变更以及版本与发布管理。是CMMI第二第二级中的关键过程域。它的主要目的是对变更加以控制，级中的关键过程域。它的主要目的是对变更加以控制，将变更对成本、进度和质量影响降到最小。将变更对成本、进度和质量影响降到最小。15软件配置管理的活动软件配置管理的活动

16、系统构建系统构建版本管理版本管理变更管理变更管理发布管理发布管理组件版本组件版本系统版本系统版本系统发布版本系统发布版本变更提议变更提议SCM中四个相关的活动中四个相关的活动161.变更管理变更管理：评估来自客户和开发者的软件变更请求，评估来自客户和开发者的软件变更请求，分析变更的影响，估算变更的费用，决策是否变更，分析变更的影响，估算变更的费用，决策是否变更，何时变更。何时变更。2.版本管理版本管理：跟踪系统组件的多个版本，确保不同开发：跟踪系统组件的多个版本，确保不同开发者对组件做出的变更不会彼此影响。者对组件做出的变更不会彼此影响。3.系统构建系统构建：将系统组件装配成可执行程序的过程。

17、：将系统组件装配成可执行程序的过程。4.发布管理发布管理：决定发布或提交一个系统的时间，准备好：决定发布或提交一个系统的时间，准备好所有待发布的信息（可执行文件、数据文件、配置文所有待发布的信息（可执行文件、数据文件、配置文件和文档等），并为每个系统发布版本编制好文档。件和文档等），并为每个系统发布版本编制好文档。17n配置管理需要工具的支持，工具用来追踪变更提议，配置管理需要工具的支持，工具用来追踪变更提议，存储系统组件的多个版本，从这些组件中构建系统，存储系统组件的多个版本，从这些组件中构建系统，并跟踪系统版本的实际发布。并跟踪系统版本的实际发布。nSCM中的有关术语：中的有关术语：术语术

18、语 解释解释软件配置项软件配置项（SCI）程序、文档、数据、组件等，是软件工程过程中创建程序、文档、数据、组件等，是软件工程过程中创建的信息。配置项会存在多个不同的版本。每个配置项的信息。配置项会存在多个不同的版本。每个配置项都有一个唯一的名字。都有一个唯一的名字。配置控制配置控制对系统和组件的版本进行记录、识别、储存和维护的对系统和组件的版本进行记录、识别、储存和维护的过程，确保变更得到管理。过程，确保变更得到管理。版本版本配置项的一个实例。有一个唯一的标示符（如名字配置项的一个实例。有一个唯一的标示符（如名字+版本号）版本号）18 基线基线开发各阶段不能轻易改变的软件版本（底线）。基线是受

19、控开发各阶段不能轻易改变的软件版本（底线）。基线是受控的，即构成系统的软件版本是不能轻易改变的。的，即构成系统的软件版本是不能轻易改变的。基线作用用于控制变更，禁止开发人员随便修改一个基线作用用于控制变更，禁止开发人员随便修改一个“已已冻结冻结”的工作成果。的工作成果。代码线代码线软件组件以及组件所依赖的其它配置项的集合。软件组件以及组件所依赖的其它配置项的集合。主线主线系统不同版本的基线的序列。系统不同版本的基线的序列。工作空间工作空间一个私有的工作空间中，对软件的修改不会影响其他开发者一个私有的工作空间中，对软件的修改不会影响其他开发者对该软件的使用。对该软件的使用。分支分支从现存的代码线

20、版本中创建一个新的代码线，新代码线和已从现存的代码线版本中创建一个新的代码线，新代码线和已存在的代码线可以并行开发。存在的代码线可以并行开发。合并合并通过合并在不同代码线中的单独版本来创建软件的新版本。通过合并在不同代码线中的单独版本来创建软件的新版本。这些代码线可能由某个代码线先前存在的分支所创建。这些代码线可能由某个代码线先前存在的分支所创建。系统构建系统构建通过链接组件和库中适当版本创建一个可执行的系统版本。通过链接组件和库中适当版本创建一个可执行的系统版本。IEEE对对基线的定义基线的定义：已经通过正式评审和批准的规已经通过正式评审和批准的规约或产品，可以作为进一步开发的基础，并且只能

21、通约或产品，可以作为进一步开发的基础，并且只能通过正式的变更控制规程才能改变它。过正式的变更控制规程才能改变它。19SCISCISCISCISCI配置项库配置项库基线：基线：软件需求规约软件需求规约软件设计规约软件设计规约源代码源代码测试规程测试规程/用例用例可运行的系统可运行的系统存储存储提取提取软件工软件工程任务程任务修改修改正式技正式技术评审术评审批准批准SCM控制控制基线化的基线化的SCI和项目数据库（参考教材和项目数据库（参考教材1）20 A A1.1 A1.2 A1.3 B B1.1 B1.2 B1.3 C C1.1 C1.2C1.3 L1 L2 EX1 EX2代码线（代码线（A）

22、代码线（代码线（B）代码线（代码线（C）库和外部组件库和外部组件 AB1.2C1.1 L1 L2 EX1基线基线-V1 A1.3B1.2C1.2 L1 L2 EX1基线基线-V2代码线、基线、主线代码线、基线、主线主线（基线的序列）主线（基线的序列）2111.2.1 变更管理变更管理n变更管理的任务变更管理的任务 分析变更请求：研究变更的必要性、经济可行分析变更请求：研究变更的必要性、经济可行性（成本效益比，是否合理）和技术可行性。性（成本效益比，是否合理）和技术可行性。记录和追踪变更、评估变更的影响。记录和追踪变更、评估变更的影响。采取措施保证变更在受控状态下进行。采取措施保证变更在受控状态

23、下进行。n变更管理过程变更管理过程 见下图：见下图：22变更管理过程（参考教材变更管理过程（参考教材1）23n变更管理过程从分析变更请求开始，处于开发状态的变更管理过程从分析变更请求开始，处于开发状态的配置项配置项尚未稳定下来，不受尚未稳定下来，不受SCM的控制，对配置项的的控制，对配置项的变更不受限制。变更不受限制。n当开发人员认为工作已告完成，可供其他配置项使用当开发人员认为工作已告完成，可供其他配置项使用时，配置项进入评审状态，若通过评审就作为基线允时，配置项进入评审状态，若通过评审就作为基线允许进入配置项数据库（许进入配置项数据库（check-in)，配置项配置项处于受控状处于受控状态

24、，开发人员不允许随便对其做任何修改态，开发人员不允许随便对其做任何修改。n配置项的状态变化见下图。配置项的状态变化见下图。对配置项的变更控制对配置项的变更控制24两个主要的变更控制因素：两个主要的变更控制因素：访问控制访问控制：管理哪个程序员有权访问和修改：管理哪个程序员有权访问和修改SCI。同步控制同步控制：保证两个不同人员完成的并行变更不会相：保证两个不同人员完成的并行变更不会相互覆盖。互覆盖。访问控制与同步控制流程如下图所示：访问控制与同步控制流程如下图所示：配置项的状态变化配置项的状态变化 评审状态评审状态受控状态受控状态工作状态工作状态开发人员满意开发人员满意通过评审通过评审chec

25、k in未通过评审未通过评审check out25 配置对象的同步存取控制流程配置对象的同步存取控制流程 加锁加锁：使得当前被提取的版本在放回之前别人不能对它使得当前被提取的版本在放回之前别人不能对它 作任何修改（同步控制）。作任何修改（同步控制）。解锁解锁：在经过：在经过SQA和测试后，提交修改后的版本（新的和测试后，提交修改后的版本（新的 基线对象）并被解锁。基线对象）并被解锁。（该变更管理的模式为（该变更管理的模式为 Lock-Modify-Unlock 模式）模式）2611.2.2.版本管理版本管理n版本管理是跟踪软件组件或配置信息由于变更而产生版本管理是跟踪软件组件或配置信息由于变更

26、而产生的不同版本的过程。的不同版本的过程。n一个系统版本就是一个系统的具体实例。版本有内部一个系统版本就是一个系统的具体实例。版本有内部版本和发布版本。一个系统的内部版本要比发布版本版本和发布版本。一个系统的内部版本要比发布版本多得多。系统的内部版本是为内部开发或测试而创建，多得多。系统的内部版本是为内部开发或测试而创建，内部版本趋于稳定后，才决定产生发布版本。内部版本趋于稳定后，才决定产生发布版本。n版本管理也包括确保由不同开发者做出的变更不会彼版本管理也包括确保由不同开发者做出的变更不会彼此影响，因此也看做是管理此影响，因此也看做是管理代码线代码线和和基线基线的过程。的过程。27n基线很重

27、要，开发者常常不得不重建一个完整系统基线很重要，开发者常常不得不重建一个完整系统的特定版本。如，一个产品线需要实例化为不同客的特定版本。如，一个产品线需要实例化为不同客户产生不同的个人系统版本。假如客户报告了系统户产生不同的个人系统版本。假如客户报告了系统中的错误，开发者不得不重建这个版本。中的错误，开发者不得不重建这个版本。n为了支持版本管理，使用版本管理工具（或称版本为了支持版本管理，使用版本管理工具（或称版本管理系统）。提供以下功能或特征（管理系统）。提供以下功能或特征（1-5）：28 有以下基本的标识模式：有以下基本的标识模式：版本版本编号号 每一个版本或每一个版本或组件件对应一个明确

28、的、唯一的一个明确的、唯一的编号，如号，如V1.0、V1.1、V1.2。优点是点是简单。基于属性的基于属性的标识 每个版本或每个版本或组件由名字和相关属性共件由名字和相关属性共同同标识。如：。如：V(Language=Java，Platform=WinNT，Date=Jan1999)优点是便于属性上的多种点是便于属性上的多种查询，如，如查询“最新最新创建的版本建的版本”。面向面向变更的更的标识 关关联到一个或多个到一个或多个变更。如：更。如：V1.0-bugfix 表示版本表示版本V1.0的缺陷修复版本；的缺陷修复版本；V1.0-build-003 表示版本表示版本V1.0开开发过程中生成的第

29、程中生成的第3 次构建。次构建。V1.0-rel01 表示版本表示版本V1.0的第的第1个个发布版本。布版本。V1.0-rel01-p001 表示表示发布版本布版本V1.0-rel01的第的第001号号补丁。丁。1.版本识别：给版本分配标识符。版本识别：给版本分配标识符。29 2.存储管理：为了减少只有少许差异的不同版本所占存储管理：为了减少只有少许差异的不同版本所占存储空间，版本管理系统提供存储管理工具。系统只存存储空间，版本管理系统提供存储管理工具。系统只存储每个版本不同之处的列表（增量），而不是每个版本储每个版本不同之处的列表（增量），而不是每个版本的副本。将这个列表应用到源版本上（通常

30、是被完整地的副本。将这个列表应用到源版本上（通常是被完整地存储的最近的版本），就能重建目标版本。存储的最近的版本），就能重建目标版本。V1.0 V1.1 V1.2V1.3D1D2D3V1.2源源代码代码最近版本最近版本创建日期创建日期使用增量备份的存储管理使用增量备份的存储管理增量备份存储变更增量备份存储变更代码行，并封装重代码行，并封装重建系统版本的指令建系统版本的指令自动创建自动创建30 3.变更历史记录：记录并列出所有对系统或组件做变更历史记录：记录并列出所有对系统或组件做出的变更。可以利用这些有标记的变更选择一个特殊出的变更。可以利用这些有标记的变更选择一个特殊的系统版本。的系统版本。

31、4.独立开发：不同的开发者可能在同一时间正在相独立开发：不同的开发者可能在同一时间正在相同的组件上工作。版本管理系统能跟踪检出的组件，同的组件上工作。版本管理系统能跟踪检出的组件，确保由不同开发者对组件做出的变更不会彼此影响。确保由不同开发者对组件做出的变更不会彼此影响。5.项目支持：版本管理系统可以支持共享组件的多项目支持：版本管理系统可以支持共享组件的多个项目的开发。如个项目的开发。如CVS（Concurrent Versions System）中，可以检入和检出所有与项目相关的文件，）中，可以检入和检出所有与项目相关的文件，而不是一次只能在一个文件上工作。而不是一次只能在一个文件上工作。

32、31n软件开发是一个团队活动，会有不同的团队在同一时间软件开发是一个团队活动，会有不同的团队在同一时间开发同一组件的情况。如果一个开发者从项目容器中检开发同一组件的情况。如果一个开发者从项目容器中检出一个正在被开发的组件时，版本管理系统会通知警告出一个正在被开发的组件时，版本管理系统会通知警告其他开发者该组件已被取出；当放回的组件被修改，系其他开发者该组件已被取出；当放回的组件被修改，系统对不同的版本给出不同的标识符并分开存放。如下图：统对不同的版本给出不同的标识符并分开存放。如下图：ABCXYC Alice工作空间工作空间Bob工作空间工作空间XYABCRQY2.1A1.1PC1.1C2.1

33、项目容器项目容器检出检出检入检入检出检出检入检入版本管理系统对独立开发的支持版本管理系统对独立开发的支持32n相同组件独立开发的一个后果是可能会出现几个独立相同组件独立开发的一个后果是可能会出现几个独立的版本序列。的版本序列。n如果变更发生在代码完全不同的部分，版本管理系统如果变更发生在代码完全不同的部分，版本管理系统会应用代码的增量备份使组件版本自动合并。所做的会应用代码的增量备份使组件版本自动合并。所做的变更可能有重叠，开发者必须检查冲突并修改变更使变更可能有重叠，开发者必须检查冲突并修改变更使它们相兼容。它们相兼容。V1.0V1.1V1.0V2.0V2.1V2.2V2.1.1V2.3V2

34、.1.2V2.4合并合并代码线代码线1分支分支代码线代码线2分支分支代码线代码线2.1分支与合并分支与合并33 系统开发中经常是系统开发中经常是同一产品不同版本之间的并行开发，同一产品不同版本之间的并行开发，即即不同的开发者独立地在不同的源代码版本上工作并以不不同的开发者独立地在不同的源代码版本上工作并以不同的方式做出改变。同的方式做出改变。3.0FCS当前发布版本当前发布版本3.0版本维护分支版本维护分支3.0FCS3.0PBL1维护工维护工作基线作基线3.0PBL2可作补丁程可作补丁程序发布序发布3.0FCS4.0版本开发分支版本开发分支4.0BL0开发工作基线开发工作基线4.0BL14.

35、0BL2Merge使用版本管理系统自动使用版本管理系统自动合并，达到合并，达到“同一缺陷同一缺陷一次修复，永不重现一次修复，永不重现”4.0BL3Create projects例：对于同一产品的维护与开发例：对于同一产品的维护与开发3411.2.3.系统构建系统构建n系统构建是将系统组件装配成一个在目标计算机上的可系统构建是将系统组件装配成一个在目标计算机上的可执行程序的过程。系统构建可能有执行程序的过程。系统构建可能有3种不同的系统平台：种不同的系统平台：开发工具开发工具私有工作空间私有工作空间 可执行系统可执行系统 目标平台目标平台版本管理系统版本管理系统构建服务器构建服务器检入检入检出检

36、出开发系统开发系统目标系统目标系统构建平台构建平台构建可执行的系统构建可执行的系统版本。与版本管理版本。与版本管理系统有交互系统有交互35n系统构建将软件有关的大量信息与它的运行环境组装系统构建将软件有关的大量信息与它的运行环境组装起来起来。如图所示：如图所示：自动构建系统自动构建系统源代码文件源代码文件数据文件数据文件外部的组件库外部的组件库组装的配组装的配 置文件置文件可执行可执行的测试的测试可执行的可执行的目标系统目标系统测试结果测试结果编译器和编译器和其他工具其他工具系统构建的环境系统构建的环境36n一个构建系统（构建工具）提供以下部分或全部功能一个构建系统（构建工具）提供以下部分或全

37、部功能（特征）：（特征）：1.构建脚本生成：解析待构建的程序，给出组件的构建脚本生成：解析待构建的程序，给出组件的信息以及它们之间的依赖关系，指定编译和连接的工信息以及它们之间的依赖关系，指定编译和连接的工具，自动生成构建脚本（配置文件）。构建系统应支具，自动生成构建脚本（配置文件）。构建系统应支持手工创建和编辑构建脚本。持手工创建和编辑构建脚本。2.版本管理系统集成：从版本管理系统中（项目容版本管理系统集成：从版本管理系统中（项目容器）检出需要的组件版本。器）检出需要的组件版本。3.编译量最小化：为减小编译量，需检索是否存在编译量最小化：为减小编译量，需检索是否存在可用的已编译版本。分析哪些

38、组件的源代码需要再编可用的已编译版本。分析哪些组件的源代码需要再编译，然后才进行编译。目标文件一般通过名字和源代译，然后才进行编译。目标文件一般通过名字和源代码文件联系起来（后缀不同）。码文件联系起来（后缀不同）。37 4.创建可执行系统：将编译后的目标代码文件以及创建可执行系统：将编译后的目标代码文件以及其它需要的文件（如外部库文件、配置文件）链接起其它需要的文件（如外部库文件、配置文件）链接起来，创建可执行的系统。来，创建可执行的系统。5.测试自动化：能够使用工具进行自动化测试，检测试自动化：能够使用工具进行自动化测试，检查构建是否被变更所破坏。查构建是否被变更所破坏。6.报告：提供关于构

39、建的运行和测试是否成功的报报告：提供关于构建的运行和测试是否成功的报告。告。7.文档生成：能够生成关于构建和系统帮助页面的文档生成：能够生成关于构建和系统帮助页面的版本注释。版本注释。38敏捷方法中的敏捷方法中的持续集成持续集成n敏捷方法使用自动测试（敏捷方法使用自动测试（“烟雾测试烟雾测试”）执行频繁的）执行频繁的系统构建，是持续集成的过程。步骤：系统构建，是持续集成的过程。步骤：1.将主线系统从版本管理系统检出到开发人员的私将主线系统从版本管理系统检出到开发人员的私有空间。有空间。2.构建主线并运行自动测试确保所构建的系统能够构建主线并运行自动测试确保所构建的系统能够通过所有测试。若没通过

40、，构建终止。通知最后提交通过所有测试。若没通过，构建终止。通知最后提交主线的开发人员，负责修复问题。主线的开发人员，负责修复问题。3.完成系统组件的变更。完成系统组件的变更。4.在私有空间构建系统并重新运行测试。若测试失在私有空间构建系统并重新运行测试。若测试失败，继续编辑。败，继续编辑。39 5.一旦系统通过测试，将它检入到构建平台。一旦系统通过测试，将它检入到构建平台。6.在构建服务器上构建系统并运行测试。（可能在在构建服务器上构建系统并运行测试。（可能在主线检出之后有人修改了构建平台上要调用的组件，主线检出之后有人修改了构建平台上要调用的组件，或者可能用到外部组件或其它配置文件），若测试

41、未或者可能用到外部组件或其它配置文件），若测试未通过，使构建失败的组件还需检出到私有空间编辑并通过，使构建失败的组件还需检出到私有空间编辑并测试通过。测试通过。7.如果系统在构建平台上测试通过，将做出变更的如果系统在构建平台上测试通过，将做出变更的系统主线作为新的系统基线。系统主线作为新的系统基线。该步骤图示见下页。该步骤图示见下页。40版本管理系统版本管理系统私有工作空间私有工作空间检出主线检出主线构建和测构建和测试系统试系统做相应做相应变更变更构建和测构建和测试系统试系统检入到构检入到构建平台建平台构建和测构建和测试系统试系统提交变更版本提交变更版本作为新的基线作为新的基线未通过未通过构建

42、服务器构建服务器通过通过未通过未通过通过通过版本管理系统版本管理系统持续集成的优点：持续集成的优点：尽快发现并修复由不尽快发现并修复由不同开发人员开发的组件交同开发人员开发的组件交互引起的问题。互引起的问题。频繁构建激励组件被频繁构建激励组件被彻底的单元测试。主线中彻底的单元测试。主线中最近的系统是确定的工作最近的系统是确定的工作系统。系统。持续集成图示持续集成图示41软件配置管理工具支持的开发模式软件配置管理工具支持的开发模式工具名称工具名称 说明说明ClearCaseCopy-Modify-Merge 模式模式FireflyCopy-Modify-Merge 模式模式CVSCopy-Mod

43、ify-Merge 模式模式PVCSCheck out-Modify-Check in 模式模式VSSCheck out-Modify-Check in 模式模式软件配置管理工具采用了不同的策略：软件配置管理工具采用了不同的策略：Copy-Modify-Merge（拷贝、修改、合并）的（拷贝、修改、合并）的并并行开发模式行开发模式、Check out-Modify-Check in（检出、修（检出、修改、提交）的改、提交）的独占开发模式独占开发模式。4211.2.4.发布版本管理发布版本管理n系统的发布版本不仅仅是这个系统的可执行代码。还系统的发布版本不仅仅是这个系统的可执行代码。还包括：包括

44、：1.配置文件，定义发布版本如何部署安装配置文件，定义发布版本如何部署安装 2.数据文件，包括错误信息的文件数据文件，包括错误信息的文件 3.安装程序，帮助在目标硬件上安装系统安装程序，帮助在目标硬件上安装系统 4.电子和书面文档，用于系统说明电子和书面文档，用于系统说明 5.包装和相关宣传，为发布版本所做的工作包装和相关宣传，为发布版本所做的工作n发布版本的创建是包含系统发布版本所有组件在内的发布版本的创建是包含系统发布版本所有组件在内的文件和文档集合的过程。文件和文档集合的过程。43 发布管理包括：发布管理包括：决定何时发布一个系统。决定何时发布一个系统。准准备备好所有待好所有待发发布的信息。布的信息。为发为发布版本布版本编编制文档。制文档。44