CASE系统软件配置管理计划

《CASE系统软件配置管理计划》由会员分享，可在线阅读，更多相关《CASE系统软件配置管理计划（17页珍藏版）》请在金锄头文库上搜索。

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

2、软件配置管理项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.11 产品基线产品基线是指在软件集成与系统测试阶段

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

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

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

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

9、确定该软件在整个软件生存周期内需要编制的文档； 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) 完成

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

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

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

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