CASE系统软件配置管理计划

1、CASE系统软件配置管理计划1概述1.1 编写目的为了确保CASE系统软件配置管理项的完备、清晰和可追溯性及 其状态的可控制性，特制定本规定。本规定适用于CASE系统软件生 存周期的全过程。该系统的项目与子项目如下：管理系统对象管理系统数据管理系统界面管理系统工具集程序编译工具集程序调试工具集程序测试工具集程序维护工具集1.2 参考资料1.3 术语与缩写词1.3.1 软件配置软件产品在不同时期的组合，该组合随着开发工作的进展而不断 变化。1.3.2 软件配置项 Software Configuration Item为独立的配置管理（技术状态管理）而设计的并且能满足最终用 户功能的一组软件。1.

2、3.3 软件配置管理项 Software Configuration Management Item置于配置控制之下的软件配置项的有关软件成分。包括各类文档、源程序及其目标码、运行所需的系统软件和支持软件，以及各种 数据。1.3.4 软件配置管理 Software Configuration Management标识和确定系统中软件配置管理项的过程， 在整个软件生存周期 内控制这些软件配置管理项的发放和更改， 记录并报告配置的状态和 更改要求，验证配置的完整性和正确性。1.3.5 软件开发库 Software Development Library软件开发库是指在软件生存周期的某一个阶段期间，

3、存放与该阶段软件开发工作有关的计算机可读信息和人工可读信息的库。1.3.6 软件受控库 Software Controlled Library软件受控库是指在软件生存周期的某一个阶段结束时，存放作为 阶段产品而发放的、与软件开发工作有关的计算机可读信息和人工可 读信息的库。软件配置管理就是对软件受控库中的各个软件项进行管 理，因此软件受控库也叫做软件配置管理库。1.3.7 软件产品库 Software Product Library软件产品库是指在软件生存周期的组装与系统测试阶段结束后， 存放最终产品而后交付给用户运行或在现场安装的软件的库。1.3.8 基线 Baseline在配置项生存周期的

4、某一特定时间内，一个或一组正式指定或固 定下来的配置标识文件。1.3.9 功能基线 Functional Baseline功能基线是指在系统分析与软件定义阶段结束时，经过正式评审 和批准的系统设计规格说明书中关于软件系统的规格说明；或是指经 过项目委托单位和项目承办单位双方签字同意的协议书或合同中所 规定的关于软件系统的规格说明；或是指由下级申请经上级同意或直 接由上级下达的项目任务书中所规定的关于软件系统的规格说明。功能基线是最初批准的功能配置标识。1.3.10 分配基线分配基线是指在软件需求分析阶段结束时，经过正式评审和批准 的软件需求规格说明。分配基线是最初批准的分配配置标识。1.3.1

5、1 产品基线产品基线是指在软件集成与系统测试阶段结束时，经过正式评审 和批准的所开发软件产品的全部配置项的规格说明。产品基线是最初 批准的产品配置标识。1.3.12 发放发放是指在软件生存周期的各个阶段结束时， 由该阶段向下阶段 提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得 的最终产品向用户提交的过程。2管理2.1 机构软件配置管理的组织机构如下：a.在软件系统整个开发期间，各项目及其所属各子项目均应建 立相应的软件配置管理组织，专门负责配置管理工作。组织名称为软 件配置管理委员会和（或）软件配置管理小组，以下统称软件配置管 理组织；b.软件配置管理组织负责管理受控库和产品库，

6、开发库通常由 各项目开发组自行管理；c.各软件配置管理组织应在工程实施的全过程中履行职责。2.2 任务软件配置管理的任务包括：指明配置管理项的功能特性和物理特 性，编制文档，并建立配置管理项的标识体制；控制对这些特性的更 改；记录、报告更改处理以及执行状态；对配置进行审计和评审等。2.3 职责职责涉及用户与软件配置管理组织的职责。用户的主要职责是：参与各个阶段的测试与评审，帮助完成测评 文档。软件配置管理组织的主要职责有：a.制订软件配置管理计划，以规划整个软件生存周期中的软件配置管理活动；b.确定并执行软件开发过程中要用到的与软件配置管理有关的 标准、规定或约定；c.根据本单位实际选择并使用

7、合适的软件配置管理工具；d.对每个软件配置管理项按其特性进行标识，以利于管理；e.确定基线。对于每个基线，必须指明应交付的文档和程序、与每个基线有关的评审和审批事项以及验收标准；f.制定并执行更改控制程序、文档更改程序，实施配置控制；g.制定并执行配置状态记录和报告程序，实施配置状态报告；h.实施配置的审计和评审；1 .规定对分承办单位进行控制的管理程序， 实施对分承办单位的 控制。以便使分承办单位所交付的软件能够满足规定的软件配置 管理要求；j.收集、维护、保存软件配置管理文档；1.开列发放清单并及时按发放清单向有关人员发放配置状态报告。特别是当某些配置管理项状态发生变更时，必须发放。2.4

8、 接口控制按照系统的要求，分配各个模块功能，最后将各模块统一起来， 每个模块必须符合接口要求，否则，最后会导致系统无法正常工作。2.5 实现采用软件工程的方法，实行项目经理负责制，下级按模块分成若 干项目小组，由项目经理直接管理各小组组长。2.6 适用的标准、规程或约定该系统须符合ISO9000中关于该行业的规定，符合该行业的操作规程及术语约定。尽最大可能使用可重用的代码，关于可重用代码的编制，变量命 名等由项目经理统一协调，并下发给各小组。3软件配置管理活动3.1 配置标识3.1.1 确立基线确立基线的要点有：a.各系统根据开发软件的重要性，确定软件的级别。依据开发 软件的级别，按照CPZX

9、/GL 1-2001确定该软件在整个软件生存周期 内需要编制的文档；b.各系统根据各自工程实际、软件等级等因素沿整个软件生存 周期确定若干基线，亦即确定具体的时机和相应的软件配置管理项；c.基线的设置应与软件开发人员协商并履行一定的审批手续；d.在软件生存周期中，主要有三种基线，即功能基线、分配基线和产品基线。对于每个基线应该指明：(1) 应进入配置受控的每个配置管理项；(2)与每个基线有关的评审与批准事项以及验收标准；(3)在建立基线的过程中用户和开发者的参与情况。例如，在产品基线中，要定义的内容可以包括：产品名字和命名 规则；产品标识编号；安装说明；已知的缺陷和故障；软件介质和介 质标识等

10、。对一个新交付的版本，要给出版本交付号、新更改的描述、 更改交付的方法和对支持软件的更改要求。3.1.2 标识软件配置管理项标识软件配置管理项应注意：a.在制定每一基线时，把基线要求受控的软件实体标识为软件 配置管理项，并为每个软件配置管理项赋予唯一的标识符；b.要确定全部文档的格式、内容和控制机制，以便在配置管理 中可追溯；c.用一种编号法提供软件配置管理项的信息，以便对全部产品 文档和介质指定合适的标识号；d.标识方式要有利于软件配置管理项的状态控制，便于增、删 和更改;e.软件配置管理项标识应包括文档标识、程序标识和数据标识。3.1.2.1 文档标识对文档进行标识时应注意：a.受控文档应

11、以易理解的方式确定一个有条理的文档体系结 构；b.所用标识法应反映：“谁于何时因何故对何物作何更改”。3.1.2.2 程序标识对程序进行标识的要点有：a.应制定统一的程序命名规则(1)命名应反映其功能与特性，含义明确，易于理解：(2) 命名必须唯一；(3) 命名应便于管理。b.应统一规定程序版本号的设置与修订规则。c.每个源程序进入配置管理时，应在其前部建立一个“程序首 部”。在程序首部至少应给出下列信息：(1)标识符：该程序的标识符(2)名 字：该程序的名称(3)作用：简述该程序的作用(4)语 言：该程序所用的编程语言(5)作者：该程序的编写者(6)完成日：该程序的完成日期(7)修 改：上次

12、更改该程序的人员姓名、日期及其原因。3.1.2.3 数据标识在软件项目开发和使用过程中用到的各种基准参数值、系统数据等均应作为软件配置管理项予以标识。这些数据如：a.本型号任务的基准数据；b.本软件项目所涉及的其它系统、子系统的设置值；c.本软件项目的外部接口数据；毕毕寻寻O3.2 配置控制3.2.1 入库控制入库控制包含下面五个要点：a.作为受控的软件配置管理项必须存入受控库；b.当且仅当满足要求的作为产品交付给用户使用的软件配置管理项，才从受控库转入产品库；c.各基线所产生的阶段产品，入库前均需经软件配置管理员审计，确认合格后才可入库：(1)对文档需验证其是否经标准化审查，是否符合相应文档

13、的 编制规范，是否有评审结论，审批手续是否齐备；(2)对程序需验证是否有经过批准的相应阶段的测试报告、测试用例和测试程序等。d.鉴于工程的密级，应对进入受控库的软件实施安全控制， 为被 允许存取这些软件的人员分别赋予相应的权限(例如，对指定的软件 配置管理项的读、写、删、执行、更改等的权限）。e.安全控制（1）介质鉴别一建议入/出受控库的介质最好是专用的、附有防 伪标志的。本库的管理工具应对此提供鉴别功能。（2）病毒检测一每次入库的介质均应先做病毒检测。若发现有 病毒应拒绝接收，或杀灭所有病毒后才接收。3.2.2更改控制更改控制的要点如下：a.在软件生存周期中，对已进入受控库或产品库的任一软件

14、配 置管理项的任何更改都必须履行正规的审批手续。b. 一旦需要更改某一软件配置管理项，通常应由有关人员申报“软件问题报告”，详细说明问题的症状、性质、预计的影响范围（本 次更改可能涉及哪些软件，对开发进度可能有多大延误，可能需追加 多少经费等）。上述“有关人员”与发现问题时所处阶段有关。若在 编程时发现设计有误需更改设计文档，则编程员应协同设计人员一起 申报“软件问题报告”；若在测试时发现程序或文档有误，则编程员 应协同测试人员申报；若在维护阶段发现程序有误，则应由软件维护 者和用户申报。c.软件配置管理员应协同“软件问题报告”申报人员一起提出 “软件更改申请”，详细说明欲改的软件配置管理项的

15、现行配置状态，此次更改的类型（纠错、改进、扩充一），更改会涉及的程序、文档、 数据、系统功能和性能，更改的必要性和可行性，预想的更改策略, 以及更改所需的时间和额外的经费支持等。 软件更改申请的格式参见 附录B。d.根据软件的级别和程序规模决定是否建立“更改评审组”。该 组织的构成人员应包括该软件配置项的管理人员，技术负责人员，总体设计人员，软件质量保证人员，软件配置管理人员。组成人数各单 位可视实际情况酌定。更改评审组系临时性的机构。若不建立更改评 审组时，由更改审批人负责。e. “更改评审组”收到“软件更改申请”后，分析此更改的必 要性、技术可行性并权衡其它的更改策略和方法、所涉及的有关软

16、件 配置管理项、对软件配置项的功能和性能的影响 （利弊得失的权衡）、 更改所需的资源是否合理、充分、以及对整个工程进度和经费的影响 等，提出是否实施此次更改的意见，提交给更改审批人。f.更改审批人接到“更改评审组”提交的关于是否实施更改的意 见后，应及时作出决策，是否实施更改。g.获准的“软件更改申请”退送至开发组或维护组，由开发组或 维护组实施相应的更改，以及完成必要的回归测试，并写出软件更改 单。h.更改后的软件配置管理项连同相应的软件更改单一并提交给 软件配置管理员，重新履行入库手续。i.不论所更改的软件实体是程序还是文档， 必须确保相关程序和 文档均同时完成相应的更改和回归测试，以便确

17、保软件配置管理项“文实相符，文文一致”。j.软件的更改包括正确性更改、适应性更改和完善性更改，更改 的级别定义如下：1级：涉及需求规格说明的变化、影响安全和影响系统功能的完成；2级：涉及概要设计文档的变化、影响本软件功能的实现和系统 的重要性能变化；3级：非1、2级更改。软件更改的级别由配置管理组织确定。软件更改审批人应该与配置管理项的原审批人一致。k.当某个软件配置管理项从受控库中取出进行更改时，必须对此软件配置管理项在受控库中的文件加锁， 以指示该软件配置管理项 正在被更改中，禁止其他用户在此更改期间使用更改中的版本， 确保 每个用户从受控库中所得到的软件配置管理项总是正确、有效的。1.当

18、需更改产品库中的产品时，应将此产品自产品库中移至受控 库，履行上述对受控库中软件配置管理项相同的更改控制手续。此更改完成并经审批同意后才可再存入产品库交付使用。3.3 软件配置管理状态的记录与报告软件配置状态报告的目的是提供开发过程的历史记录，因此在报告中应指明各软件配置管理项的现行状态，何时因何故发生了何事（入库、更改等）。例如，在配置状态记录和报告中，通常要描述的信息有：规格说明的状态，设计说明的状态，更改申请的状态，更改批准的报告，产 品版本或其更改版的状态，安装、更新或交付的实现报告，用户提供 的产品(如操作系统)的状态，以及有关开发项目历史的报告等内容。为了便于管理和让各类人员及时了解配置状态，除定期提交报告 外，还可按要求随时提供配置状态报告，其格式见附录Do3.4 软件配置管理的审计与评审审计与评审的要点有：a.应对软件进行功能配置审计(以验证软件的功能和接口与软 件需求规格说明的一致性)和物理配置审计(以检查程序与文档的一 致性、文档与文档的一致性、交付的产品与任务书要求的一致性、以 及与标准规范的一致性)；b.在每次审计与评审时要做到：(1)明确本次审计与评审时所包含的配置管理项；(2)验证配置管理项对前一基线相应项的可追溯性；(3)确认配置管理项正确反映了软件需求；(4)确保在任何时候任何情况下都满足“文实相符、文文一致”； c.在整个软件生存周期中，应定期进