软件工程第16章课件

第16章

软件配置管理

即：SoftwareConfigurationManagement，简称SCM软件配置管理——对正在被某个项目组建造的软件的修改进行标识、组织和控制的技术，用来协调和控制整个系统过程。目标——通过最大限度地减少错误来最大限度地提高软件生产率。软件配置管理是包括从软件项目计划到软件退役为止——贯穿整个软件工程过程活动中的所有追踪和控制软件变动的保护性活动。第16章 软件配置管理即：SoftwareConfigu116.1

软件配置管理概念

软件开发过程的最终结果包括三类信息：计算机程序（源程序和目标程序）；描述程序的文档（面向技术人员和面向用户）；数据结构（包括程序内部和外部定义两部分）。组成上述信息的所有项目构成一个软件配置，其中每一项称为一个软件配置项（SoftwareConfigurationItem，简称SCI），它是配置管理的基本单位。一个SC中最早的SCI是系统规格说明书。SCM要解决的主要问题就是保证软件的质量。16.1软件配置管理概念软件开发过程的最终结果包括三类216.1.1基线技术

基线（baseline）的原意是棒球场的边线，在软件开发过程中，为了有效地控制变动，软件配置管理引入基线的概念。IEEE组织对于基线的定义——“已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能遵循正式的变化控制过程得到改变”。根据这个定义，基线标志软件开发过程的各个里程碑，任一SCI（例如，设计说明书），一旦形成文档并复审通过，即成为一个基线，它标志开发过程中一个阶段的结束。对于已成为基线的SCI，虽然可以修改，但必须按照一个特殊的、正式的过程进行评估，确认每一处修改。相反，对于未成为基线的SCI，可以进行非正式修改。16.1.1基线技术基线（baseline）的原意是棒3图16-1-1基线系统工程需求分析软件设计编码测试系统规格说明书软件需求规格说明书设计规格说明书源代码测试计划/过程/数据可操作的系统发布图16-1-1基线系统工程需求分析软件设计编码测416.1.1基线技术某个SCI一旦成为基线，随即被放入项目数据库（projectdatabase）。此后，若开发小组中某位成员希望改动SCI，首先要将它拷贝到私有工作区并在项目数据库中锁住，不允许他人使用。在私有工作区中完成修改控制过程并复审通过之后，再把修改后的SCI推出并回送到项目数据库，同时解锁。16.1.1基线技术某个SCI一旦成为基线，随即被放入项516.1.2软件配置项

一般软件配置需包括下列SCI：1．系统规格说明书2．软件项目规划3．需求分析结果1）软件需求规格说明书2）可执行的或“纸样”原型4．初步用户手册16.1.2软件配置项一般软件配置需包括下列SCI：616.1.2软件配置项5．设计规格说明书1）数据设计描述2）总体结构设计描述3）模块设计描述4）界面设计描述5）对象描述（若采用面向对象技术）6．源代码清单7．测试规格说明书1）测试计划和过程2）测试用例和实验结果16.1.2软件配置项5．设计规格说明书716.1.2软件配置项8．操作和安装手册9．可执行程序1）每个模块的可执行代码2）连接到一起的代码10．数据库描述1）数据模型和文件结构2）初始化映象11．联机用户手册12．维护文档1）软件问题报告单2）维护申请单3）预计变动的顺序13．软件工程的标准和过程16.1.2软件配置项8．操作和安装手册816.1.2软件配置项有时把SCM活动也列入配置管理的范畴。还应当建立组织的过程基线和软件财富基线，以便在整个组织中共享过程和软件财富。作为过程基线，应当将组织的质量体系、过程文件、工程操作指南、文档模板、工作样表、历史度量数据等进行统一管理、集中维护、控制发放和深入分析。软件财富基线主要包括各类可复用的软件构件。同时，把软件开发中选用的编辑器、编译器和CASE工具等作为软件配置的一部分，当配置中其他SCI发生变化时，同时考虑这些软件工具是否与之适应和匹配。16.1.2软件配置项有时把SCM活动也列入配置管理的范916.1.2软件配置项用面向对象的方法组织项目数据库，将每个SCI看作一个配置对象，有自己的名字和一组属性，各SCI之间的联系用对象间的关系表示。以图16-1-2为例，五个配置对象，对象之间的关系用有向连线表示。有向曲线——对象的部分—整体关系。例如，“数据模型”和“模块N”都是“设计规格说明书”的组成部分。双向连线——对象间的关联联系。例如，一个模块的源代码一旦变动，对应的测试用例亦需修改，随之需要重新执行测试过程。16.1.2软件配置项用面向对象的方法组织项目数据库，将10图16-1-2配置对象设计规格说明书数据设计总体结构设计模块设计界面设计测试规格说明书测试计划测试过程测试用例数据模型源代码模块N图16-1-2配置对象设计规格说明书测试规格说明书数据模1116.2软件配置管理任务

软件配置管理主要任务是控制软件的修改，主要包括：1．标识软件配置中各种对象；2．管理软件的各种版本；3．控制对软件的修改；4．审计配置；5．报告配置情况。16.2软件配置管理任务软件配置管理主要任务是控制软件1216.2.1标识配置对象

所有SCI都应按面向对象的方式命名并组织起来。对象命名是为了能够根据名称提取对象；而通过组织对象并描述其间的关系则着眼于在对象变更时能够清楚地了解变更的影响范围。基本对象——在分析、设计、编码或测试阶段由开发人员创建的某个“文本单元”（unitoftext）。例如，需求说明书中某一节，某个模块的源代码，或按等价分类法制定的一套测试用例；复合对象——由若干基本对象和复合对象组合而成的对象，是一个递归的概念。例如，“设计规格说明书”是复合对象，它由“数据模块”和“模块N”等基本对象组合而成。16.2.1标识配置对象所有SCI都应按面向对象的方式1316.2.1标识配置对象每个配置对象都拥有名字、描述、资源列表和实际存在体四个部分：1.对象名一般为无二义字符串；2.对象描述包括若干数据项，它们指明对象的类型（例如，文档、程序还是数据）、所属工程项目的标志及变动和版本的有关信息；3.资源列表给出该对象要求、引用、处理和提供的所有实体，如数据类型、特殊函数等，有时变量也被看作资源；4.只有基本对象才有实际存在体，它是指向该对象“单元正文描述”的一个指针；对于复合对象，此项取null值。16.2.1标识配置对象每个配置对象都拥有名字、描述、资1416.2.1标识配置对象除了标识配置对象外，还必须指明对象之间的关系，一个对象可标识为另一个复合对象的一部分，即此两对象之间存在一个<part‑of>关系。若干<part‑of>关系可定义出对象之间的分层结构。例如：“E‑R图”<part‑of>“数据模型”“数据模型”<part‑of>“设计规格说明书”因一个配置对象可能与其他多个对象有关系，所以SCI的分层结构不一定是简单的树状结构，而是更一般的网状结构。16.2.1标识配置对象除了标识配置对象外，还必须指明对1516.2.1标识配置对象在标识对象时还应考虑对象随着开发过程的深入不断演进的因素。为此，可为每个对象创建一个进化图，它概述某对象演化的历史，图中每个结点都是SCI的一个版本。obj1.0obj1.1.1obj1.1obj1.2obj1.3obj2.0obj2.1obj1.1.2obj1.1.3图16-2-1进化图16.2.1标识配置对象在标识对象时还应考虑对象随着开发1616.2.2版本控制

为了适应不同环境特点和满足不同用户的个性需求，往往一个项目保存多个版本。配置管理的版本控制主要解决下列问题：1）根据不同用户的需要配置不同的系统；2）保存系统老版本，为以后调查问题使用；3）建立一个系统新版本，使它包含某些决策而抛弃另一些；4）支持两位以上工程师同时在一个项目中工作；5）高效存储项目的多个版本。16.2.2版本控制为了适应不同环境特点和满足不同用户1716.2.2版本控制版本控制系统都为配置对象的每个版本设置一组属性，这组属性既可以是简单的版本号，也可以是一串复杂的布尔变量（即开关值），用以说明该版本功能上的变化。进化图也可用于描述一个软件系统的不同版本。图中每个结点都是软件的一个完整版本，它由所有协调一致的软件配置项组成（源代码，文档和数据）。此外，一个版本还允许有多种变形（Variant）。例如，一个程序的某个版本由A、B、C、D、E五个部件组成，部件D仅在系统配有彩色显示器时使用，部件E则适用于单显，那么该版本就有两种变形，一种由A、B、C、D四个部件组成，另一种由A、B、C、E四个部件组成。16.2.2版本控制版本控制系统都为配置对象的每个版本设1816.2.3修改控制

在大型软件开发过程中，无控制地修改会迅速导致混乱。所谓修改控制，即把人的努力与自动工具结合起来，建立一套机制，有意识地控制软件修改。16.2.3修改控制在大型软件开发过程中，无控制地修改19图16-2-2修改控制过程用户认识到有修改的必要用户提出“修改申请”开发者评估产生“修改报告单”提交修改控制机构决策修改请求被拒绝通知申请者(用户)此修改申请入等待队列排队，同时产生“工程变动命令”将欲修改的各配置对象明确分工到人从项目数据库中提出配置对象图16-2-2修改控制过程用户认识到有修改的必要用户提出20图16-2-2修改控制过程（续）实施修改复审修改（审计）将修改后的配置项放回项目数据库建立基线准备测试进行所有质量保证和测试活动提示即将推出的下一个版本中已做的修改构造一个完整的新版本复审对所有配置项所做修改推出新版本图16-2-2修改控制过程（续）实施修改复审修改（审计）2116.2.3修改控制当一个“修改申请”提出后，开发者依据技术指标和潜在的副作用，对其他配置对象和系统功能可能造成的影响以及项目成本等诸多因素进行评估。评估的结果将形成一个“修改报告单”，提交给修改控制机构CCA决策。CCA一旦同意修改，应立即提供一个“工程变动命令”ECO。它指明修改任务、需遵守的限制和复审标准。然后从项目数据库中“提出”待修改对象，经修改后再“推出”更新版本。这一对动作是项目数据库访问控制和同步控制要求的。访问控制决定哪些人员有权访问或修改某个配置对象；而同步控制则保证并行修改时不因互相重写而造成丢失修改。16.2.3修改控制当一个“修改申请”提出后，开发者依据2215.4.4保存维护记录访问和同步控制流可用图16-2-3说明。软件开发人员根据ECO从项目数据库中提出待修改对象，访问控制机构，核实该开发人员是否有此特权，而同步控制机构则及时锁住待修改对象，不允许其他开发人员再做修改，直至该对象的新版本推出。加锁期间，其他工程人员仍可提取该对象的副本（称为提取版本）使用。图16-2-2所示的修改控制用于已交给用户的软件产品，称为正式修改控制。若欲修改的SCI虽已为基线版本，但尚未交付用户，此时修改控制称为工程级的修改控制，它除了不涉及用户外，其他步骤与正式的修改控制大致相同。若SCI并未成为基线版本，只需进行非正式的修改控制，则在不影响系统需求的前提下，该SCI的开发者可随意改动。15.4.4保存维护记录访问和同步控制流可用图16-2-23图16‑2‑3修改过程中的同步和访问控制提出访问控制推出软件工程师项目数据库访问请求特权信息解锁加锁配置对象（提取版本）配置对象（基线版本）配置对象（基线版本）配置对象（修改版本）审计信息图16‑2‑3修改过程中的同步和访问控制提出访问推出软件2416.2.4配置审计

对于变更工作，必须通过正式的技术复审和软件配置审计工作来验证被核准进行变更的对象是否进行了必要的、正确的变更，并得到了重新的配置。正式的技术复审着重考虑所修改对象在技术上的正确性，复审人员应对该对象是否与其他SCI协调以及在修改中可能产生的疏忽和副作用进行全面的评估。16.2.4配置审计对于变更工作，必须通过正式的技术复2516.2.4配置审计软件配置审计作为正式复审的一种补充措施，主要考虑下列在正式技术复审中未被考虑的因素：1．ECO中指定的修改是否都已完成？有无进行未经指定的其他附加变更？2．是否做过正式技术复审？3．是否严格遵守软件工程标准？4．是否对修改过的SCI进行了强调说明？修改的日期和执行修改的人员是否已经注明？该SCI的属性是否能够反映本次修改的结果？5．是否遵循了标注变更、记录变更和报告变更的SCM工作规程？6．所有相关的SCI是否已一并修改？16.2.4配置审计软件配置审计作为正式复审的一种补充措2616.2.5配置状况报告

建立并发布配置状况报告（ConfigurationStatusReporting，简称CSR）是软件配置管理的一项任务.CSR主要概述下列问题：发生了什么事情；谁做的；何时发生的；有什么影响。CSR的时机与图16-2-2所述过程紧密相关:当某个SCI被赋予新标记或更新标记时;或CCA批准一项修改申请（产生一个ECO）时;或配置审计完成时。CSR的输出可放在联机数据库中，供开发人员和维护人员随时按关键字查询。16.2.5配置状况报告建立并发布配置状况报告（Con2716.3软件配置管理标准

有若干种SCM标准：较早的标准主要用于美国军界：MIL‑STD‑483；DOD‑STD‑480A；MIL‑STD‑1521A。后来公布的ANSI/IEEE标准，如828‑1983，1042‑1982和1028‑1988等。16.3软件配置管理标准有若干种SCM标准：2816.4配置管理的CASE工具

一个配置管理工具——DSEE（DomainSoftwareEngineeringEnvironment）的组成：历史管理程序（historymanager）；配置管理程序（configurationmanager）；任务管理程序（taskmanager）；监控管理程序（monitormanager）。历史管理程序负责在库中存储管理配置项的各个版本；配置管理程序的主要功能是定义和建立配置；任务和监控管理程序则主要负责控制软件修改过程。这里重点讨论配置管理部分。16.4配置管理的CASE工具一个配置管理工具——DS2916.4配置管理的CASE工具使用DSEE建立一个配置（在此泛指系统或某个配置项）需涉及下面三个概念：1．系统模型（systemmodel）——欲导出此配置项所需的源项、工具（DSEE中称为翻译器）和过程；“系统模型”描述组成系统各分量之间的关系，即系统构成。它包括每一个分量的形式（分为原子和聚合的），分量之间的依赖关系，以及每一个分量将被什么翻译器处理等。。16.4配置管理的CASE工具使用DSEE建立一个配置（3016.4配置管理的CASE工具2．配置依据（configurationthread）——推导配置项版本时所用的一组规则、工具和工具中的选件（options）；“配置依据”主要描述对于一次具体的配置建立，源项的哪些版本和翻译器的哪些选件将被使用。因此涉及到版本和选件的命名与确定。为此，DSEE引入一套专用语言，描述“系统模型”的“配置依据”。16.4配置管理的CASE工具2．配置依据（config3116.4配置管理的CASE工具3．导出项缓冲池（derivedelementpool）每一配置项建立后都放入缓冲池中，它可以同时存放某配置项的几个版本。因此缓冲池中每项均附一个BCT（BoundConfigurationThread，捆绑配置依据），它列出推导此配置项所用的各源项和工具的版本及工具选件。16.4配置管理的CASE工具3．导出项缓冲池（deri32首先根据“系统模型”和“配置依据”确定此次欲推导配置项的“BCT”，然后在缓冲池中查找那些可直接用于推导新配置项的配置项。通过遍历项目依赖图，确定所有凡是其所依赖的项在其建立之后从未改变过的项，直接使用它们，而不重新建立。如果在“导出缓冲池”中能找到某个配置项，其BCT与欲推导配置项的BCT匹配，则DSEE立即重用它，不再重新推导。DSEE的一个优点就是允许各配置尽可能共享已经导出的配置项。建立规格说明（即为所要求配置项建立BCT）源库翻译器导出项缓冲池系统模型配置依据图16-4-1用DSEE建立一配置首先根据“系统模型”和“配置依据”确定此次欲推导配置项的“B33图16-4-2用DSEE并行建立某编译器前端DSEE建立编译器前端PARSER.O计算服务器B文件服务器D…建立PARSER.C导出项缓冲池源库工作站ALEX.O…建立LEX.ASSLEX.ASSPARSER.CCONSTAXTS.LNC…工作站E工作站C图16-4-2用DSEE并行建立某编译器前端DSEE建立3416.4配置管理的CASE工具DSEE可以在网络环境下工作，此时建立配置的工作可在多个CPU上并行完成，如图16-4-2说明了并行建立机制。假设某用户在工作站A上要求DSEE建立某编译程序前端（指词法分析与语法分析部分）DSEE确定需要分别建立彼此独立的LEX.ASS和PARSER.C，选择结点B、C完成此项任务。这两个结点独立地从结点D的库中取所需源项，又将已建立完成的项目送到结点E的缓冲池中。16.4配置管理的CASE工具DSEE可以在网络环境下工35第16章

软件配置管理

即：SoftwareConfigurationManagement，简称SCM软件配置管理——对正在被某个项目组建造的软件的修改进行标识、组织和控制的技术，用来协调和控制整个系统过程。目标——通过最大限度地减少错误来最大限度地提高软件生产率。软件配置管理是包括从软件项目计划到软件退役为止——贯穿整个软件工程过程活动中的所有追踪和控制软件变动的保护性活动。第16章 软件配置管理即：SoftwareConfigu3616.1

软件配置管理概念

软件开发过程的最终结果包括三类信息：计算机程序（源程序和目标程序）；描述程序的文档（面向技术人员和面向用户）；数据结构（包括程序内部和外部定义两部分）。组成上述信息的所有项目构成一个软件配置，其中每一项称为一个软件配置项（SoftwareConfigurationItem，简称SCI），它是配置管理的基本单位。一个SC中最早的SCI是系统规格说明书。SCM要解决的主要问题就是保证软件的质量。16.1软件配置管理概念软件开发过程的最终结果包括三类3716.1.1基线技术

基线（baseline）的原意是棒球场的边线，在软件开发过程中，为了有效地控制变动，软件配置管理引入基线的概念。IEEE组织对于基线的定义——“已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能遵循正式的变化控制过程得到改变”。根据这个定义，基线标志软件开发过程的各个里程碑，任一SCI（例如，设计说明书），一旦形成文档并复审通过，即成为一个基线，它标志开发过程中一个阶段的结束。对于已成为基线的SCI，虽然可以修改，但必须按照一个特殊的、正式的过程进行评估，确认每一处修改。相反，对于未成为基线的SCI，可以进行非正式修改。16.1.1基线技术基线（baseline）的原意是棒38图16-1-1基线系统工程需求分析软件设计编码测试系统规格说明书软件需求规格说明书设计规格说明书源代码测试计划/过程/数据可操作的系统发布图16-1-1基线系统工程需求分析软件设计编码测3916.1.1基线技术某个SCI一旦成为基线，随即被放入项目数据库（projectdatabase）。此后，若开发小组中某位成员希望改动SCI，首先要将它拷贝到私有工作区并在项目数据库中锁住，不允许他人使用。在私有工作区中完成修改控制过程并复审通过之后，再把修改后的SCI推出并回送到项目数据库，同时解锁。16.1.1基线技术某个SCI一旦成为基线，随即被放入项4016.1.2软件配置项

一般软件配置需包括下列SCI：1．系统规格说明书2．软件项目规划3．需求分析结果1）软件需求规格说明书2）可执行的或“纸样”原型4．初步用户手册16.1.2软件配置项一般软件配置需包括下列SCI：4116.1.2软件配置项5．设计规格说明书1）数据设计描述2）总体结构设计描述3）模块设计描述4）界面设计描述5）对象描述（若采用面向对象技术）6．源代码清单7．测试规格说明书1）测试计划和过程2）测试用例和实验结果16.1.2软件配置项5．设计规格说明书4216.1.2软件配置项8．操作和安装手册9．可执行程序1）每个模块的可执行代码2）连接到一起的代码10．数据库描述1）数据模型和文件结构2）初始化映象11．联机用户手册12．维护文档1）软件问题报告单2）维护申请单3）预计变动的顺序13．软件工程的标准和过程16.1.2软件配置项8．操作和安装手册4316.1.2软件配置项有时把SCM活动也列入配置管理的范畴。还应当建立组织的过程基线和软件财富基线，以便在整个组织中共享过程和软件财富。作为过程基线，应当将组织的质量体系、过程文件、工程操作指南、文档模板、工作样表、历史度量数据等进行统一管理、集中维护、控制发放和深入分析。软件财富基线主要包括各类可复用的软件构件。同时，把软件开发中选用的编辑器、编译器和CASE工具等作为软件配置的一部分，当配置中其他SCI发生变化时，同时考虑这些软件工具是否与之适应和匹配。16.1.2软件配置项有时把SCM活动也列入配置管理的范4416.1.2软件配置项用面向对象的方法组织项目数据库，将每个SCI看作一个配置对象，有自己的名字和一组属性，各SCI之间的联系用对象间的关系表示。以图16-1-2为例，五个配置对象，对象之间的关系用有向连线表示。有向曲线——对象的部分—整体关系。例如，“数据模型”和“模块N”都是“设计规格说明书”的组成部分。双向连线——对象间的关联联系。例如，一个模块的源代码一旦变动，对应的测试用例亦需修改，随之需要重新执行测试过程。16.1.2软件配置项用面向对象的方法组织项目数据库，将45图16-1-2配置对象设计规格说明书数据设计总体结构设计模块设计界面设计测试规格说明书测试计划测试过程测试用例数据模型源代码模块N图16-1-2配置对象设计规格说明书测试规格说明书数据模4616.2软件配置管理任务

软件配置管理主要任务是控制软件的修改，主要包括：1．标识软件配置中各种对象；2．管理软件的各种版本；3．控制对软件的修改；4．审计配置；5．报告配置情况。16.2软件配置管理任务软件配置管理主要任务是控制软件4716.2.1标识配置对象

所有SCI都应按面向对象的方式命名并组织起来。对象命名是为了能够根据名称提取对象；而通过组织对象并描述其间的关系则着眼于在对象变更时能够清楚地了解变更的影响范围。基本对象——在分析、设计、编码或测试阶段由开发人员创建的某个“文本单元”（unitoftext）。例如，需求说明书中某一节，某个模块的源代码，或按等价分类法制定的一套测试用例；复合对象——由若干基本对象和复合对象组合而成的对象，是一个递归的概念。例如，“设计规格说明书”是复合对象，它由“数据模块”和“模块N”等基本对象组合而成。16.2.1标识配置对象所有SCI都应按面向对象的方式4816.2.1标识配置对象每个配置对象都拥有名字、描述、资源列表和实际存在体四个部分：1.对象名一般为无二义字符串；2.对象描述包括若干数据项，它们指明对象的类型（例如，文档、程序还是数据）、所属工程项目的标志及变动和版本的有关信息；3.资源列表给出该对象要求、引用、处理和提供的所有实体，如数据类型、特殊函数等，有时变量也被看作资源；4.只有基本对象才有实际存在体，它是指向该对象“单元正文描述”的一个指针；对于复合对象，此项取null值。16.2.1标识配置对象每个配置对象都拥有名字、描述、资4916.2.1标识配置对象除了标识配置对象外，还必须指明对象之间的关系，一个对象可标识为另一个复合对象的一部分，即此两对象之间存在一个<part‑of>关系。若干<part‑of>关系可定义出对象之间的分层结构。例如：“E‑R图”<part‑of>“数据模型”“数据模型”<part‑of>“设计规格说明书”因一个配置对象可能与其他多个对象有关系，所以SCI的分层结构不一定是简单的树状结构，而是更一般的网状结构。16.2.1标识配置对象除了标识配置对象外，还必须指明对5016.2.1标识配置对象在标识对象时还应考虑对象随着开发过程的深入不断演进的因素。为此，可为每个对象创建一个进化图，它概述某对象演化的历史，图中每个结点都是SCI的一个版本。obj1.0obj1.1.1obj1.1obj1.2obj1.3obj2.0obj2.1obj1.1.2obj1.1.3图16-2-1进化图16.2.1标识配置对象在标识对象时还应考虑对象随着开发5116.2.2版本控制

为了适应不同环境特点和满足不同用户的个性需求，往往一个项目保存多个版本。配置管理的版本控制主要解决下列问题：1）根据不同用户的需要配置不同的系统；2）保存系统老版本，为以后调查问题使用；3）建立一个系统新版本，使它包含某些决策而抛弃另一些；4）支持两位以上工程师同时在一个项目中工作；5）高效存储项目的多个版本。16.2.2版本控制为了适应不同环境特点和满足不同用户5216.2.2版本控制版本控制系统都为配置对象的每个版本设置一组属性，这组属性既可以是简单的版本号，也可以是一串复杂的布尔变量（即开关值），用以说明该版本功能上的变化。进化图也可用于描述一个软件系统的不同版本。图中每个结点都是软件的一个完整版本，它由所有协调一致的软件配置项组成（源代码，文档和数据）。此外，一个版本还允许有多种变形（Variant）。例如，一个程序的某个版本由A、B、C、D、E五个部件组成，部件D仅在系统配有彩色显示器时使用，部件E则适用于单显，那么该版本就有两种变形，一种由A、B、C、D四个部件组成，另一种由A、B、C、E四个部件组成。16.2.2版本控制版本控制系统都为配置对象的每个版本设5316.2.3修改控制

在大型软件开发过程中，无控制地修改会迅速导致混乱。所谓修改控制，即把人的努力与自动工具结合起来，建立一套机制，有意识地控制软件修改。16.2.3修改控制在大型软件开发过程中，无控制地修改54图16-2-2修改控制过程用户认识到有修改的必要用户提出“修改申请”开发者评估产生“修改报告单”提交修改控制机构决策修改请求被拒绝通知申请者(用户)此修改申请入等待队列排队，同时产生“工程变动命令”将欲修改的各配置对象明确分工到人从项目数据库中提出配置对象图16-2-2修改控制过程用户认识到有修改的必要用户提出55图16-2-2修改控制过程（续）实施修改复审修改（审计）将修改后的配置项放回项目数据库建立基线准备测试进行所有质量保证和测试活动提示即将推出的下一个版本中已做的修改构造一个完整的新版本复审对所有配置项所做修改推出新版本图16-2-2修改控制过程（续）实施修改复审修改（审计）5616.2.3修改控制当一个“修改申请”提出后，开发者依据技术指标和潜在的副作用，对其他配置对象和系统功能可能造成的影响以及项目成本等诸多因素进行评估。评估的结果将形成一个“修改报告单”，提交给修改控制机构CCA决策。CCA一旦同意修改，应立即提供一个“工程变动命令”ECO。它指明修改任务、需遵守的限制和复审标准。然后从项目数据库中“提出”待修改对象，经修改后再“推出”更新版本。这一对动作是项目数据库访问控制和同步控制要求的。访问控制决定哪些人员有权访问或修改某个配置对象；而同步控制则保证并行修改时不因互相重写而造成丢失修改。16.2.3修改控制当一个“修改申请”提出后，开发者依据5715.4.4保存维护记录访问和同步控制流可用图16-2-3说明。软件开发人员根据ECO从项目数据库中提出待修改对象，访问控制机构，核实该开发人员是否有此特权，而同步控制机构则及时锁住待修改对象，不允许其他开发人员再做修改，直至该对象的新版本推出。加锁期间，其他工程人员仍可提取该对象的副本（称为提取版本）使用。图16-2-2所示的修改控制用于已交给用户的软件产品，称为正式修改控制。若欲修改的SCI虽已为基线版本，但尚未交付用户，此时修改控制称为工程级的修改控制，它除了不涉及用户外，其他步骤与正式的修改控制大致相同。若SCI并未成为基线版本，只需进行非正式的修改控制，则在不影响系统需求的前提下，该SCI的开发者可随意改动。15.4.4保存维护记录访问和同步控制流可用图16-2-58图16‑2‑3修改过程中的同步和访问控制提出访问控制推出软件工程师项目数据库访问请求特权信息解锁加锁配置对象（提取版本）配置对象（基线版本）配置对象（基线版本）配置对象（修改版本）审计信息图16‑2‑3修改过程中的同步和访问控制提出访问推出软件5916.2.4配置审计

对于变更工作，必须通过正式的技术复审和软件配置审计工作来验证被核准进行变更的对象是否进行了必要的、正确的变更，并得到了重新的配置。正式的技术复审着重考虑所修改对象在技术上的正确性，复审人员应对该对象是否与其他SCI协调以及在修改中可能产生的疏忽和副作用进行全面的评估。16.2.4配置审计对于变更工作，必须通过正式的技术复6016.2.4配置审计软件配置审计作为正式复审的一种补充措施，主要考虑下列在正式技术复审中未被考虑的因素：1．ECO中指定的修改是否都已完成？有无进行未经指定的其他附加变更？2．是否做过正式技术复审？3．是否严格遵守软件工程标准？4．是否对修改过的SCI进行了强调说明？修改的日期和执行修改的人员是否已经注明？该SCI的属性是否能够反映本次修改的结果？5．是否遵循了标注变更、记录变更和报告变更的SCM工作规程？6．所有相关的SCI是否已一并修改？16.2.4配置审计软件配置审计作为正式复审的一种补充措6116.2.5配置状况报告

建立并发布配置状况报告（ConfigurationStatusReporting，简称CSR）是软件配置管理的一项任务.CSR主要概述下列问题：发生了什么事情；谁做的；何时发生的；有什么影响。CSR的时机与图16-2-2所述过程紧密相关:当某个SCI被赋予新标记或更新标记时;或CCA批准一项修改申请（产生一个ECO）时;或配置审计完成时。CSR的输出可放在联机数据库中，供开发人员和维护人员随时按关键字查询。16.2.5配置状况报告建立并发布配置状况报告（Con6216.3软件配置管理标准

有若干种SCM标准：较早的标准主要用于美国军界：MIL‑STD‑483；DOD‑STD‑480A；MIL‑STD‑1521A。后来公布的ANSI/IEEE标准，如828‑1983，1042‑1982和1028‑1988等。16.3软件配置管理标准有若干种SCM标准：6316.4配置管理的CASE工具

一个配置管理工具——DSEE（DomainSoftwareEngineeringEnvironment）的组成：历史管理程序（historymanager）；配置