[IT认证]软件工程讲义-9.ppt

《[IT认证]软件工程讲义-9.ppt》由会员分享，可在线阅读，更多相关《[IT认证]软件工程讲义-9.ppt（101页珍藏版）》请在三一文库上搜索。

1、软件工程,1,软件工程 第九章 软件质量,9.1 软件质量和质量模型 9.2 软件质量保证 9.3软件配置管理,软件工程,2,9.1 软件质量与质量模型,9.1.1 软件质量的概念,ANSI/IEEE Std 729-1983定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。 ISO 8402-1994定义软件质量为“反映实体满足明确和隐含需要的能力的特性的总和”。此处，实体是“可以单独描述和研究的事物”，如产品，活动，过程，组织和体系等。,软件工程,3,由此可知，质量是产品、体系或过程的一组固有特性，反映的是满足顾客和其他相关方面要求的程度。 David Gar

2、vin提出，“质量是一个复杂的多层面的概念”： 从先验论角度看，质量是可以识别出来的，但不能明确定义的。 从用户角度看，质量是对目标的满足程度。 从制造角度看，质量是对规范的符合程度。 从产品角度看，质量是产品的内在特征。,软件工程,4,从基于价值的角度看，质量依赖于顾客愿意出多少钱购买。 按用户角度定义质量，J.M.Juran 提出“满足使用要求的基础是质量特征”。 下面是一些有关质量的术语： 软件质量管理是对软件在质量方面指挥和控制组织的协调活动。通常包括制定质量方针和质量目标以及质量策划、质量控制、质量保证和质量改进。 质量方针是由组织的最高管理者正式发布的该组织总的质量宗旨和方向。,软

3、件工程,5,质量目标是在质量方面所追求的目的。 质量策划是质量管理的一部分，致力于制定质量目标并规定必要的运行过程和相关资源以实现质量目标。 质量控制是质量管理的一部分，致力于满足质量要求。 质量保证是质量管理的一部分，致力于保障质量会得到满足的信任度。 质量改进是质量管理的一部分，致力于增强满足质量要求的能力。,软件工程,6,9.1.2 软件质量模型,为满足软件的各项精确定义的功能、性能需求，符合文档化的开发标准，需要相应地给出或设计一些质量特性及其组合。 如果这些质量特性及其组合都能在产品中得到满足，则这个软件产品质量就是高的。 软件质量是各种特性的复杂组合。它随着应用的不同而不同，随着用

4、户提出的质量要求不同而不同。 软件质量特性，反映软件的本质。讨论一个软件的质量，归结到定义软件的质量特性。,软件工程,7,定义一个软件的质量，就等价于为该软件定义一系列质量特性。 人们通常把影响软件质量的特性用软件质量模型来描述。 软件质量特性定义成分层模型。最基本的叫做基本质量特性，它可以由一些子质量特性定义和度量。这些子特性在必要时又可由它的一些子特性定义和度量。 1976年 Boehm质量模型 1979年 McCall质量模型 1985年 ISO质量模型,软件工程,8,Boehm质量模型,软件工程,9,McCall质量模型,可维护性(Maintainability) 可测试性(Testa

5、bility) 灵活性(Flexibility),正确性(Correctness) 可靠性(Reliability) 可使用性(Usability) 效率(Efficiency) 完整性(Integrity),互连性(Interoperability) 可移植性(Portability) 复用性(Reusability),软件工程,10,ISO的软件质量评价模型,按照1991年 ISO发布的 ISO/IEC 9126 质量特性国际标准 ，软件质量度量模型由三层组成 软件质量特性 软件质量子特性 软件质量度量评价准则 高层和中层建立国际标准，低层可由各使用单位视实际情况制定。,软件工程,11,软

6、件质量,功能性,可靠性,可维护性,效率,可使用性,可移植性,适合性,准确性,互操作性,依从性,安全性,成熟性,容错性,易恢复性,易理解性,易学习性,易操作性,时间特性,资源特性,易分析性,稳定性,易变更性,易测试性,易安装性,易替换性,适应性,遵循性,质量特性,质量子特性,质量度量准则,使 用 单 位 自 行 规 定,ISO 9126 质量模型,软件工程,12,其中， 表示有利影响， 表示不利影响。,质量特性之间的竞争,软件工程,13,1994年对ISO/IEC 9126开始进行修正，将原标准修订为两个序列标准： ISO/IEC 9126信息技术 软件产品质量，描述新的软件质量模型，分为 4

7、个部分： 质量模型 (9126-1) 内部质量 (9126-2) 外部质量 (9126-3) 使用质量 (9126-4) ISO/IEC 14598信息技术 软件产品评价，详细描述软件质量评价的方法，分为 6 个部分：,软件工程,14, 概述 (14598-1) 策划和管理 (14598-2) 开发方过程 (14598-3) 获取方过程 (14598-4) 评价方过程 (14598-5) 评价模块的文档 (14598-6) 修订版保留了 6 个质量特性，但明确了它们与内部度量和外部度量的关系，并解释了这些特性与使用质量之间的关系。 修订版还给出了一个质量模型的规格说明，引入了使用质量。,软件工

8、程,15,ISO/IEC 9126与ISO/IEC 14598之间的关系,软件工程,16,内部质量和外部质量的质量模型,外部质量是软件产品在规定条件下使用时，满足规定的和隐含的要求的程度。外部质量是从外部观点看软件产品的全部特性。 内部质量是软件产品在规定条件下使用时，决定其满足规定的和隐含的要求的能力的产品属性的全体。内部质量是从内部的观点看软件产品的全部特性。 在质量模型中有 6 个软件质量特性，这些特性按用户观点描述软件的外部质量，每个质量特性按开发者的观点又分解为子特性。,软件工程,17,外部和内部质量的质量模型,软件工程,18,使用质量的质量模型,使用质量是软件产品在规定的使用环境中

9、，规定的用户能实现规定目标的要求，并具有有效性、生产率、安全性和满意度的能力。 使用质量是从软件所处的环境的观点，用软件在这个环境中的使用绩效来测量的，而不是依靠软件本身的特性来测量。,软件工程,19,在生存周期中各种质量特性的使用,软件的生存周期可以划分为三个大的阶段。 在软件需求定义阶段要定义软件的质量要求；在软件产品开发阶段要使得软件产品具有要求的质量；在软件运行和维护阶段要测量软件是否达到了用户的质量要求并维护软件的性能水平。 用户质量要求可以用使用质量度量、外部质量度量表达，有时也可以用内部质量度量来表达。用这些度量表达的要求将作为产品确认的准则。,软件工程,20,软件工程,21,外

10、部质量要求从外部的观点规定要求的质量级别，包括从用户质量要求导出的要求。 外部质量要求用作各开发阶段的确认目标，在质量要求规格说明中用外部质量度量规定，并应当转换为内部质量要求。 内部质量要求从内部的观点规定要求的质量级别，用于说明中间产品的特性。 内部质量要求可以用作各开发阶段的确认目标，也可以用于定义开发策略和开发期间评价和验证的准则。 内部质量要求用内部度量数据定量地规定。,软件工程,22,软件产品质量评价,软件产品质量在开发过程中形成，在使用中表现。,软件工程,23,软件产品质量可通过测量 内部质量特性（中间产品的静态测量数据） 外部质量特性（代码执行的行为） 使用质量特性（使用此软件

11、的系统行为） 来评价。目的是使产品在具体使用环境中具有要求的效能。 为了满足开发者、维护者、获取者和最终用户的要求，软件产品的质量要求通常包括内部质量、外部质量和使用质量的评价准则。,软件工程,24,可依赖性 dependability,对于某些高可靠性系统，质量特性“可依赖性”显得非常重要，它有四个主要方面： 可用性 (Availability)：系统在任何时间都能得到并能够执行有用服务的可能性。 可靠性 (Raliability)：系统在给定的时段内能提供希望的服务的可能性。 安全性或防护性 (Safety)：系统防止发生给人和环境造成伤害的失效的可能性。 安全性或保密性 (Securit

12、y)：系统能够抵抗意外或蓄意的入侵的可能性。,软件工程,25,可依赖性的层次,软件工程,26,9.1.3 提高质量的方法 - 原型化方法,软件需求是度量软件质量的基础。不符合需求的软件就不具备质量。它是各种特性的复杂组合。它随着应用的不同而不同，随着用户提出的质量要求不同而不同。 因此与用户的交流成为提高软件质量的关键。在系统开发中，与用户进行交流的基本技术是原型化方法。 系统原型是软件系统的初始版本，用于展示设计选择、发现问题和给出可能的解决方案。,软件工程,27,软件原型支持需求工程的两项活动： 需求获取 需求有效性验证 其他用途： 用户培训 系统测试 主要分类： 进化式原型开发 抛弃式原

13、型开发,软件工程,28,1. 进化式原型开发,基本思路是：先给出一个系统的最初实现，让用户去使用和评价，不断进行细化和改善，经过多次这样的反复过程后形成最终的完善的系统。,软件工程,29,2. 抛弃式原型开发,基本思路是：原型的根本作用是弄清楚需求和为风险评估提供补充信息。通过评估后，原型被抛弃，重新规划和实施系统的开发。,软件工程,30,9.1.4 软件质量的度量和评价,软件质量特性度量有两类：预测型和验收型。 预测度量是利用定量或定性的方法，估算软件质量的评价值，以得到软件质量的比较精确的估算值。 验收度量是在软件开发各阶段的检查点，对软件的要求质量进行确认性检查的具体评价值，它对开发过程

14、中的预测进行评价。,软件工程,31,预测度量有两种。 第一种叫做尺度度量，这是一种定量度量。它适用于一些能够直接度量的特性，例如，出错率定义为：错误数KLOC单位时间。 第二种叫做二元度量，这是一种定性度量。它适用于一些只能间接度量的特性，例如，可使用性、灵活性等等。,软件工程,32,尺度度量检查表,软件工程,33,二元度量检查表,软件工程,34,通过对照检查项目，确定一种质量特性的有无。 例如，在设计和编码阶段的复杂性度量，利用尺度度量方法来做。对模块复杂性的度量采用McCabe 环路度量。 对于二元度量，可针对检查表中每一项都应给以记分，指定信息存在时记 “1”，否则记 “0”。表中所有各

15、项的分数相加，即得度量结果。,软件工程,35,9.2 软件质量保证 9.2.1 质量保证的概念,什么是质量保证？ISO/IEC 12207 : 1995 指出：质量保证是一个有计划、有组织的活动，它向所有相关的人提供证据，以证明质量功能正在按质量要求运行的信心。 质量保证的目的是 内部质量保证：在组织内部向管理者提供信任保证； 外部质量保证：向顾客或第三方认证提供信任保证；,软件工程,36,9.2.2 软件质量保证过程与活动,ISO/IEC 12207:1995指出：软件质量保证过程（SQA）是恰当保证为项目生存周期中的软件产品和过程符合规定需求和已制定计划提供足够保证的过程。 软件质量保证过

16、程包括4方面的活动： 过程实施 产品质量保证 过程质量保证 质量保证体系的质量保证,软件工程,37,1. 美国SEI推荐的软件质量保证活动,为项目制定SQA计划 该计划规定了软件开发小组和质量保证小组需要执行的质量保证活动。 SQA计划的要点包括： 需要进行哪些评价？ 需要进行哪些审计和评审？ 项目采用的标准； 错误报告的要求和跟踪过程； SQA小组应产生哪些文档？ 向软件项目组提供的反馈数量等。,软件工程,38,参与开发该软件项目的软件过程描述 软件开发小组为开发活动选择软件过程，SQA 小组评审过程说明，确保该过程与组织政策、内部、外界标准及软件项目计划的其他部分相符。 评审各项软件工程活

17、动 评审各项软件工程活动，核实其是否符合已定义的软件过程。为此，SQA小组必须识别、记录和跟踪所有偏离过程的偏差，核实其是否已经改正。,软件工程,39,审核指定的软件工作产品 审核指定的软件工作产品，核实其是否符合已定义的软件过程中的相应部分。 记录软件工作及软件工作产品的偏差 确保软件工作及工作产品中的偏差已被记录在案，并根据预定规程进行处理。 跟踪问题的解决 记录所有不符合部分，向管理部门报告。跟踪不符合的部分直到问题得到解决。 协调变更的控制与管理。 帮助收集和分析软件度量的信息。,软件工程,40,2. 微软提出的软件质量保证检查表,你识别出对你的项目很重要的质量特性了吗？ 你让其他人都

18、知道项目的目标了吗? 你对外部质量特性（正确性、可用性、有效性、可靠性、完整性、适用性、精确性和健壮性）和内部质量特性（可维护性、灵活性、可移植性、可复用性、可读性、可测试性和可理解性）作了区分吗? 有没有想过有些特性是冲突的，而有些是互补的？,软件工程,41,你的项目有没有采用几种不同的缺陷发现技术来分析不同类型的错误？ 你的项目计划中有没有包括在软件开发不同阶段进行质量保证的步骤？ 质量有没有测量，以便于了解什么地方质量提高了，什么地方质量下降了？ 管理层是否了解质量保证在（开发）前期增加成本而在后期节省成本？,软件工程,42,3.日本软件质量管理协会提出的 质量保证活动,用户要求定义 熟

19、练掌握正确定义用户要求的技术。 熟练使用和指导他人使用定义软件需求的支持工具。 重视领导全体开发人员收集和积累有关用户业务领域的各种业务的资料和技术技能。 力争不重复劳动 考虑哪些既有软件可以复用。,软件工程,43,在开发过程中，随时考虑所生产软件的复用性。 掌握开发新软件的方法 在开发新软件的过程中大力使用和推行 软件工程中所介绍的开发方法和工具。 使用先进的开发技术：如结构化技术、面向对象技术。 使用数据库技术或网络化技术。 应用开发工具或环境。 改进开发过程。,软件工程,44,组织外部力量协作的方法 一个软件自始至终由同一个软件组织开发是最理想的。但在现实中常常难以做到。 改善对外部协作

20、部门的开发管理。必须明确规定进度管理、质量管理、交接检查、维护体制等各方面要求，建立跟踪检查体制。 排除无效劳动 一种无效劳动是因需求规格说明有误、设计有误而造成的返工。定量记录返工工作量，收集和分析返工劳动花费数据，采取措施减少返工。,软件工程,45,另一种无效劳动是重复劳动，即相似的软件在几个地方同时开发。建立互相交流、信息往来通畅、具横向交流特征的信息流通网。 发挥每个开发者的能力 软件生产是人的智能生产活动，它依赖于人的能力和开发组织团队的能力。 开发者必须有学习各专业业务知识、生产技术和管理技术的能动性。 管理者或产品服务者要制定技术培训计划、技术水平标准，及适用于将来需要的中长期技

21、术培训计划。,软件工程,46,7) 提高软件开发的工程能力 要想生产出高质量的软件产品必须有高水平的软件工程能力。在软件开发环境或软件工具箱的支持下，运用先进的开发技术、工具和管理方法开发软件的能力。 提高计划和管理质量能力 项目开发初期计划阶段的项目计划评价。计划执行过程中对计划完成报告的评价。 将评价、评审工作在工程实施之前就列入整个开发工程的工程计划中。 提高软件开发项目管理的精确度。,软件工程,47,9.2.3 软件质量保证体系,软件的质量保证活动，是涉及各个部门的部门间的活动。 为顺利开展质量保证活动，必须事先明确部门间的质量保证业务，确立部门间的联合与协作的机构，这个机构就是质量保

22、证体系。 必须明确反馈途径。 必须明确各部门的职责。 必须确定保证系统运行的方法、工具、有关文档资料，以及系统管理的规程和标准。,软件工程,48,必须明确决定是否可向下一阶段进展的评价项目和评价准则。 必须不断地总结系统管理的经验教训，能够修改系统。 软件质量保证规程和技术准则 规定在项目的哪个阶段进行评审及如何评审； 规定在项目的哪个阶段应当产生哪些报告和计划； 规定产品各方面测试应达到的水平；,软件工程,49,规定在每次评审和测试中发现的错误如何修正； 描述希望得到的质量度量； 说明各种软件人员的职责，规定为了达到质量目标他们必须进行哪些活动； 建立 在各阶段中执行质量评价的质量评价和质量

23、检查系统。 有效运用质量信息的质量信息系统，并使其运行。,软件工程,50,建立和实施质量管理体系的方法和步骤： 确定顾客和其他相关方的需求和期望； 建立组织的质量方针和质量目标； 确定为实现质量目标必须的过程和职责； 确定和提供实现质量目标必须的资源； 规定测量每个过程的有效性和效率的方法； 应用这些测量方法确定每个过程的有效性和效率； 确定防止不合格并消除产生原因的措施； 建立和应用持续改进质量管理体系的过程。,软件工程,51,9.2.4 质量保证的实施,软件质量保证的实施需要从纵向和横向两个方面展开。 要求所有与软件生存期有关的人员都要参加 要求对产品形成的全过程进行质量管理 这要求整个软

24、件部门齐心协力，不断完善软件的开发环境。此外还需要与用户共同合作。,软件工程,52,1. 质量目标与度量,为了开发高质量的软件，需要明确软件的功能，明确软件应达到什么样的质量标准，即质量目标。 为了达到这个目标，在开发过程中的各个阶段进行检查和评价。 在做质量评价时，需要有 对质量进行度量的准则和方法； 在软件生存期中如何使用这些准则和方法的质量保证步骤； 提高该项作业效率的工具。,软件工程,53,2. 质量保证活动的实施步骤,Target：以用户要求和开发方针为依据，对质量需求准则、质量设计准则的各质量特性设定质量目标。 Plan：设定适合于被开发软件的评测检查项目 （质量评价准则）。 研讨

25、实现质量目标的方法或手段。 Do：制作高质量的规格说明和程序。在接受质量检查前先做自我检查。 Check：以Plan阶段设定的质量评价准则进行评价。计算结果用质量图的形式表示出来。比较,软件工程,54,评价结果的质量得分和质量目标，看其是否合格。 Action：对评价发现的问题进行改进活动，如果实现并达到了质量目标就转入下一个工程阶段。这样重复“Plan”到“Action”的过程，直到整个开发项目完成。,软件工程,55,软件工程,56,软件工程,57,软件工程,58,9.3 软件配置管理,在软件建立时变更是不可避免的，因为在进行变更前没有仔细分析，或没有进行变更控制，变更加剧了项目中软件人员之

26、间的混乱。 协调软件开发使得混乱减到最小的技术叫做配置管理。 配置管理是一组标识、组织和控制修改的活动，目的是使错误达到最小并最有效地提高生产率。,9.3.1 软件配置管理的定义,软件工程,59,ISO 9000-3:1997 的定义：配置管理是一个管理学科，它对配置项（包括软件项）的开发和支持生存周期给以技术上和管理上的指导。配置管理的应用取决于项目的规模、复杂程度和风险的大小。 W.Babich的解释：软件配置管理能够协调软件的开发，使混乱减少到最小。软件配置管理是一种标识、组织和控制修改的技术，目的是最有效地提高生产率。,软件工程,60,GB/T 11457:1995软件工程术语定义：

27、表示和确定系统中配置项的过程，在系统整个生存周期内控制这些配置项的投放和变更，记录并报告配置的状态和变更要求，验证配置项的完整性和正确性。 对下列工作进行技术和行动指导与监督的一套规范。 对配置项的功能特性和物理特性进行标识和文档编制工作。 控制这些特性的变更情况。,软件工程,61,记录并报告对这些变更进行的处理和实现的状态。 软件配置管理的任务 制定软件配置管理计划 确定配置标识的规则 实施变更控制 报告配置状态 进行配置审核 进行版本管理和发行管理,软件工程,62,软件配置项,按照ISO 9000-3的说明，软件配置项可以是： 与合同、过程、计划和产品有关的文档和数据； 源代码、目标代码和

28、可执行代码； 相关产品，包括软件工具、库内的可复用软件、外购软件及用户提供的软件。 随着软件工程过程的进展，软件配置项(SCI) 数目快速增加。,软件工程,63,9.3.2 基线 (Baseline),基线是软件生存期中各开发阶段末尾的特定点，又称里程碑。 由正式的技术评审而得到的 SCI 协议和软件配置的正式文本才能成为基线。 基线的作用是把各阶段工作的划分更加明确化，以便于检验和肯定阶段成果。,软件工程,64,软件开发各阶段的基线,软件工程,65,项目数据库,一旦一个SCI成为基线，就把它存放到项目数据库中。 当软件组织成员想要对基线SCI进行修改时，把它从项目数据库中复制到该工程师的专用

29、工作区中。 例如，把一个名为B的SCI从项目数据库复制到工程师的专用工作区中。工程师在B（B的副本）上完成要求的变更，再用B来更新B。,软件工程,66,软件工程,67,9.3.3 软件配置标识,一方面随着软件生存期的向前推进，SCI 的数量不断增多。整个软件生存期的软件配置就象一部不断演变的电影，而某一时刻的配置就是这部电影的一个片段。 为了对软件配置的各个片段（SCI）进行控制和管理，不致造成混乱，首先应给它们命名。 在实现软件配置管理时，通常，把软件配置项 （SCI）组织成配置对象，在项目数据库中用一个单一的名字来组织它们。,软件工程,68,配置对象的类型有： 基本对象：是由软件工程师在分

30、析、设计、编码和测试时所建立的文本单元。例如，基本对象可能是需求规格说明中的一节，一个模块的源程序清单、一组用来测试一个等价类的测试用例。 复合对象：是基本对象或其它复合对象的一个集合。 一个配置对象有一个名字和一组属性，并通过某些联系“连接”到其它对象。,软件工程,69,每个对象与其它对象的联系用箭头表示。单向箭头指明了一种构造关系。双向箭头则表明一种相互关系。 对象间的层次关系：一个对象可以是一个复合对象的一个成分，用联系标识。 E-R diagram 1.4 data model; data model Design Specification; 就可以建立SCI的一个层次。 对象的相互

31、关联关系：对象跨越对象层次的分支相互关联。这些交叉的结构联系表达方式如,软件工程,70,下： data model data flow model; (两个复合对象之间的相互联系) data model test case class m; (一个复合对象与一个特定的基本对象之间的相互联系） 对象标识： （名字、描述、资源、实现） 对象的名字明确地标识对象。 对象描述包括：SCI类型（如文档、程序、数据）、项目标识、变更和或版本信息。,软件工程,71,软件工程,72,资源包括由对象产生的、处理的、引用的或其它需要的一些实体。 基本对象的实现是指向文本单元的指针，复合对象的实现为NULL。 实施

32、软件配置管理要做的事情至少有： 制定配置管理计划 在软件工程项目制定开发计划时，应使开发计划中包括配置管理计划。在配置管理计划中规定:,9.3.4 软件配置管理的过程,软件工程,73,配置标识的规则 如何建立项目数据库 如何将软件配置项置于配置管理之下 配置管理人员的职责和配置管理活动 采用什么配置管理工具、技术和方法 实施变更控制 许多软件工程项目没有变更控制措施导致出现混乱。 实施版本管理和发行管理 它应当解决下列一些问题：,软件工程,74,采用什么方式来标识和管理许多已存在程序(和它们的文档)的各种版本？ 在软件交付用户之前和交付之后如何控制变更？ 谁有权批准和对变更安排优先级？ 如何保

33、证变更得以正确地实施？ 利用什么办法来估计变更可能引起的其他问题？ 这些问题归结到软件配置管理的 5 个任务，即配置标识、版本管理、变更控制、配置审核和配置报告。,软件工程,75,9.3.5 版本控制,版本控制是SCM的基础，它管理并保护开发者的软件资源。 版本控制管理在软件工程过程中建立起配置对象的不同版本。 版本管理可以把一些属性结合到各个软件版本上。 通过描述所希望的属性集合来确定（或构造）所想要的配置。 使用演变图来表示系统的不同版本。,软件工程,76,整个软件工程过程中所涉及的软件对象都必须加以标识。 在对象成为基线以前可能要做多次变更，在成为基线之后也可能需要频繁地变更。 对于每一

34、配置对象都可以建立一个演变图，用演变图记叙对象的变更历史。 图中的各个结点都是复合对象，是一个完全的软件版本。 软件的每一版本都是 SCI（源代码、文档、数据）的一个集合，且各个版本都可能由不同的变种组成。,软件工程,77,软件工程,78,例如，一个简单的程序版本由 1、2、3、4 和5 等部件组成。其中部件 4 在软件使用彩色显示器时使用，部件 5 在软件使用单色显示器时使用。因此，可以定义版本的两个变种。 在某些工具中，当前保持的是最初版本的完全副本。为了得到某一时期(文档或程序)的版本，可以从最初版本出发，沿到达该时期的版本分支，逐个 “提取” 出 (由工具编目的) 变更，使得该时期当前

35、配置直接可用，并使得其它版本也可用。,软件工程,79,版本管理的主要任务,集中管理档案，安全授权机制 版本管理的操作将开发组的档案集中地存放在服务器上，经系统管理员授权给各个用户。 用户通过检入 (check in) 和检出 (check out) 的方式访问服务器上的文件，未经授权的用户无法访问服务器上的文件。 软件版本升级管理 每次检入时，在服务器上都会生成新的版本。,软件工程,80,软件工程,81,任何版本都可以随时检出编辑，同一应用的不同版本可以像树枝一样向上增长。,软件工程,82,加锁功能 目的是在文件更新时保护文件，避免不同用户更改同一文件时发生冲突。 某一文件一旦被检入，锁即被解

36、除，该文件可被其它用户使用。 在更新一个文件之前锁定它，避免变更没有锁定的项目源文件。 在文件检入和检出时，需要注意检入和检出的使用 当需要修改某个小缺陷时，应只检出完成工作必需的最少文件；,软件工程,83,需要对文件变更时，应检入它并加锁，保留对每个变更的记录； 应避免长时间地锁定文件。如果需要长时间工作于某个文件，最好能创建一个分支，并在分支上做工作。 如果需要做较大的变更，可有两种选择： 将需要的所有文件检出并加锁，然后正常处理； 为需要修改的所有分支创建分支，把变更与主干“脱机”，然后把结果合并回去。,软件工程,84,软件工程,85,9.3.6 变更控制,软件生存期内全部的软件配置是软

37、件产品的真正代表，必须使其保持精确。 软件工程过程中某一阶段的变更，均要引起软件配置的变更，这种变更必须严格加以控制和管理，保持修改信息。 变更控制包括建立控制点和建立报告与审查制度。 在此过程中，首先用户提交书面的变更请求，详细申明变更的理由、变更方案、变更的影响范围等。,软件工程,86,然后由变更控制机构确定控制变更的机制、评价其技术价值、潜在的副作用、对其它配置对象和系统功能的综合影响以及项目的开销、并把评价的结果以变更报告的形式提交给变更控制负责人（最终决定变更状态和优先权的某个人或小组）。 对每个批准了的变更产生一个工程变更顺序（ECO），描述进行的变更、必须考虑的约束、评审和审计的

38、准则等。 要做变更的对象从项目数据库中检出 (check out)，对其做出变更，并实施适当的质量保证活,软件工程,87,活动。然后再把对象检入 (check in) 到数据库中并使用适当的版本控制机制建立软件的下一版本。 软件变更有两类不同情况： 为改正小错误需要的变更。它是必须进行的，通常不需要从管理角度对这类变更进行审查和批准。但是，如果发现错误的阶段在造成错误的阶段的后面，例如在实现阶段发现了设计错误，则必须遵照标准的变更控制过程，把这个变更正式记入文档，把所有受这个变更影响的文档都做相应的修改。,软件工程,88,软件工程,89,软件工程,90,为了增删某些功能、或为了改变完成某个功能

39、的方法而需要的变更。这类变更必须经过某种正式的变更评价过程，以估计变更需要的成本和它对软件系统其它部分的影响。 如果变更的代价较小且对软件系统其它部分没有影响，或影响很小，通常应批准这个变更。 如果变更的代价较高，或者影响较大，必须权衡利弊，决定是否变更。如果同意这种变更，需要进一步确定由谁支付变更所需的费用。如果是用户要求的变更，则用,软件工程,91,户应支付这笔费用；否则，必须完成某种成本效益分析，以确定是否值得做这种变更。 这种变更报告和审查制度，对变更控制来说起了一个安全保证作用。 在一个SCI成为基线之前，可以对所有合理的项目和技术申请进行非正式的变更； 一旦某个 SCI 经过正式的

40、技术评审并得到批准，它就成为基线。以后如果需要对它变更，就必须得到项目负责人的批准，或者必须得到变更控制负责人的批准。,软件工程,92,9.3.7 配置状态报告,为了清楚、及时地记载软件配置的变化，需要对开发的过程做出系统的记录，以反映开发活动的历史情况。这就是配置状态登录的任务。 登录主要根据变更控制小组会议的记录，并产生配置状态报告。 对于每一项变更，记录： 发生了什么？ 为什么会发生？ 对谁做的？ 什么时侯发生的？ 会有什么影响？,软件工程,93,配置状态报告信息流,软件工程,94,每次新分配一个 SCI，或更新一个已有 SCI的标识，或一项变更申请被变更控制负责人批准，并给出了一个工程

41、变更顺序时，在配置状态报告中就要增加一条变更记录条目。 一旦进行了配置审核，其结果也应该写入报告之中。 配置状态报告可以放在一个联机数据库中，以便软件开发人员或者软件维护人员可以对它进行查询或修改。此外在软件配置报告中新登录的变更应当及时通知给管理人员和软件工程师。,软件工程,95,配置状态报告对于大型软件开发项目，能够避免出现可能的不一致和冲突。 软件的完整性，是指开发后期的软件产品能够正确地反映用户要求。 软件配置审核的目的就是要 证实整个软件生存期中各项产品在技术上和管理上的完整性。 确保所有文档的内容变动不超出当初确定的软件要求范围。使得软件配置具有良好的可,9.3.8 配置审核,软件

42、工程,96,跟踪性。 软件配置审核是软件变更控制人员掌握配置情况、进行审批的依据。软件的变更控制机制通常只能跟踪到工程变更顺序产生为止。 为确认变更是否正确完成? 一般可以用以下两种方法去审查： 正式技术评审 软件配置审计 正式的技术评审着重检查已完成修改的软件配置项的技术正确性。评审者评价软件配置项，,软件工程,97,决定它与其它软件配置项的一致性，是否有遗漏或可能引起的副作用。 正式技术评审应对所有的变更进行，除了那些最无价值的变更之外。 软件配置审核作为正式技术评审的补充，评价在评审期间通常没有被考虑的SCI的特性。 软件企业实施配置管理分为两个层次。 定义组织级的标准软件配置管理过程,

43、9.3.9 软件组织的软件配置管理过程,软件工程,98,定义组织级的标准软件配置管理过程 规程：配置管理计划制定规程、变更管理规程、配置审核规程。 模板或表单：配置管理计划模板、变更请求表、配置审核检查表、配置审核不符合报告表。 准则：规程剪裁准则、配置库结构准则、配置说明与报告准则、配置管理培训准则、软件配置管理工具选择与使用准则。 项目级软件配置过程 定义过程,软件工程,99,依据组织的标准软件配置管理过程并参考用户及项目的特点，策划项目级配置管理过程，取得项目配置计划。 实施过程 确定项目软件配置管理人员职责； 选用或开发适用的配置管理工具； 对项目人员进行有关规程、模板使用及工具的培训； 按照配置管理计划开展配置管理工作。,软件工程,100,软件工程,101,作业:名词解释,1、软件质量 2、质量保证 3、软件配置项 4、基线,