CASE系统软件配置管理计划

CASE系统软件配置管理程序1概要1.1创建目的为确保CASE系统软件配置管理项目的完整性、明确性和可追溯性及其状态的可控性，制定本规定。 本规定适用于CASE系统软件的生存周期的全过程。该系统的项目和子项目包括：管理系统对象管理系统数据管理系统接口管理系统工具集程序编译工具集程序调试工具集程序测试工具集程序维护工具集1.2参考资料1.3术语和缩写1.3.1软件构成软件产品是不同时期的组合，这种组合随着开发的进展而不断变化。1.3.2软件配置项目Software Configuration Item专为独立的配置管理(技术状态管理)而设计，可满足最终用户功能的一组软件。1.3.3软件配置管理项目softwareconfigurationmanagementitem与配置控制下的软件配置项目相关的软件配置部件。 包括各种文档、源程序及其目标代码、执行所需的系统软件和支持软件，以及各种数据。1.3.4软件配置管理软件配置管理识别和确定系统中的软件配置管理项的过程在软件生命周期中控制这些软件配置管理项的版本和更改，记录和报告配置状态和更改要求，以验证配置的完整性和准确性。1.3.5软件开发库Software Development Library软件开发库是指在软件生存周期的某个阶段存储与该阶段的软件开发工作相关的计算机可读信息和人工可读信息的库。1.3.6软件管理库软件控制库软件管理库是存储计算机可读信息和人工可读信息的库，这些信息是在软件生存周期结束时作为逐步产品发布的软件开发工作。 由于软件配置管理可以管理软件管理库中的各个软件项目，因此软件管理库也称为软件配置管理库。1.3.7软件产品库软件产品库软件产品库是一个软件库，用于在软件生命周期组装和系统测试阶段结束后存储最终产品并提供给用户或安装到现场。1.3.8基线Baseline一个或多个正式或固定的配置id文件，在配置项的生存期限的特定时间点。1.3.9功能基线Functional Baseline功能基线是指在系统分析和软件定义阶段结束时，正式审查和批准的系统设计规格书中关于软件系统的规格说明，或者， 指项目委托方和项目承包方双方签署同意的协议书或合同中规定的软件系统的规格说明，或者经下级同意，或者直接上级提交的项目任务书中规定的软件系统的规格说明。 功能基线是第一个批准的功能配置id。1.3.10基线分配分配基线是指软件需求分析阶段结束时正式审核、批准的软件需求规格的说明。 分配基线是第一个批准的分配配置id。1.3.11产品基线产品基线是指软件集成和系统测试阶段结束时经过正式审核和批准开发的软件产品的所有配置项目的规格说明。 产品基线是第一个批准的产品配置id。1.3.12发行版本是指在软件生命周期的每个阶段结束时，将产品从该阶段提交到下一个阶段的过程。 它还指向用户提供在集成和系统测试阶段结束时获得的最终产品的过程。2管理2.1机构软件配置管理组织包括：a .在软件系统开发期间，各项及其所属各子项目应建立适当的软件配置管理组织，专业负责配置管理工作。 组织名称是软件组织管理委员会和软件组织管理小组，以下统称为软件组织管理组织b .软件构成管理组织负责管理库和产品库，开发库通常由各项目开发组自行管理c .各软件配置管理组织应在工程实施全过程中履行职责。2.2任务软件配置管理的任务是指定配置管理项目的功能特性和物理特性，制作文件，确立配置管理项目的显示体制，控制这些特性的变更，进行变更处理和执行状态的记录，报告制作结构的审计和重新审视等。2.3责任职责包括用户和软件配置管理组织职责。用户的主要职责是参与各阶段的测试和审核，完成评估文档。软件配置管理组织的主要职责包括：a .制定软件配置管理计划，规划软件生存期内的软件配置管理活动b .确定并执行软件开发过程中使用的软件构成管理相关标准、规定或约定c .本机构实际选择并使用适当的软件配置管理工具d .通过其特性识别各软件配置管理项目，以便于管理e .确定基线。 必须为每个基线指定要提交的文档和程序、每个基线的审查和批准以及检查标准f .制定并执行变更控制程序、文件变更程序，实施构成控制g .编制和执行部署状态记录和报告程序，实施部署状态报告h .实施组成审计和审查I .规定控制承包方的管理程序，控制承包方。 使承包商提供的软件能够满足规定的软件配置管理要求j .收集、维护和保存软件配置管理文档l .提交发行清单并根据发行清单向利益相关者提交部署状态报表。 特别是，如果某些配置管理项目的状态发生更改，则必须提交它们。2.4接口控制根据系统的要求，分配各模块的功能，最后整合各模块，各模块必须满足接口的要求。 否则，最后系统无法正常工作。2.5实现采用软件施工方法，实施项目经理责任制，下级按模块分为几个项目组，由项目经理直接管理各组领导。2.6适用的标准、规章或约定该系统必须符合ISO9000对该行业的规定，符合该行业的操作规程和术语约定。尽可能使用可重复使用的代码，关于可重复使用的代码的制作，变量命名等由项目经理统一调整，分发给各组。3软件配置管理活动3.1构成显示3.1.1建立基线建立基线的要点如下：a .各系统根据软件开发的重要性确定软件级别。 根据开发软件的水平，按照CPZX/GL 1-2001，确定软件生存期间需要制作的文件b .每个系统在实际工程中基于诸如软件等级的因素沿着软件的生存周期确定若干基线，即，对应的具体定时和软件部署管理项目c .基线的设置应与软件开发人员协商，履行一定的批准手续d .在软件生存期间，主要有三个基线：功能基线、分配基线和产品基线。 必须为每条基线指定以下内容(一)列入构成管理的各构成管理项目；(二)有关各基线的审查和批准事项及检查标准；(3)建立基线过程中用户和开发者的参与情况。例如，在产品基准线中，您可以在定义的内容中包括产品名称和命名约定，例如产品标识号安装说明已知的缺陷和故障软件介质或介质标志。 对于新发布的版本，提出版本的发布编号、新变更的说明、发布方法的变更、支持软件的变更要求。3.1.2识别软件配置管理项目要确定软件配置管理项目，请注意以下事项a .在创建每个基线时，基线管理的软件实体被标识为软件配置管理项目，并且给予每个软件配置管理项目唯一的标识符b .确定所有文档的格式、内容和控制机制，以便在配置管理中跟踪c .提供有关软件配置管理项的信息，以便分配适当的标识号码给所有产品文档和媒体d .显示方案有利于软件配置管理项目的状态控制，使得易于增加、删除和改变e .软件配置管理项目的id必须包括文档id、程序id和数据id。3.1.2.1文件id识别文档时，请注意以下事项a .受管文档必须以清晰易懂的方式确定有条不紊的文档体系结构b .使用的标识法必须反映“谁何时改变了什么”。3.1.2.2程序标志识别程序的要点如下：a .必须制定统一的程序命名规则(1)命名反映其功能和特性，含义明确，易于理解(2)命名必须是唯一的(3)命名须易于管理。b .应统一程序版本号的设置和修订规则。c .进入每个源程序的配置管理时，请在其开头创建“程序标题”。 在计划开始时，至少应提供以下信息：(1)标识符：该程序的标识符(2)名称：该程序的名称(3)作用：简述该程序的作用(4)语言：该程序中使用的编程语言(5)作者：该程序的作者(6)完成日期：该方案的完成日期(7)修正：上次变更该程序的人的姓名、日期及其原因。3.1.2.3数据标志用于软件项目开发和使用的各种参考参数值、系统数据等必须识别为软件结构管理项目。 这些数据包括：a .本模型任务的基准数据b .与本软件项目有关的其他系统、子系统的设定值c .本软件项目的外部接口数据等等。3.2构成控制3.2.1入库控制入库控制有五个要点：a .必须作为管理对象的软件配置管理项目存储在管理对象库中b .只有作为满足要求的产品提供给用户的软件配置管理项目从控制库转入产品库c .各基线发生阶段的产品，入库前可由软件构成管理者审核，确认合格后入库(一)文件标准化审查，必须验证是否符合相应文件的编制规范，是否有审查结论，审查程序是否完善(2)对于程序，验证是否有被认可的相应阶段的测试报告书、测试用例和测试程序等。d .考虑到工程的机密性，对进入管理对象库的软件实施安全控制，对被授权访问这些软件的人赋予各自的权限(例如，对指定的软件构成管理项目的读取、写入、删除、执行、变更等权限)。e .安全控制(1)媒体认证-进出管理库的媒体最好是专用的，带有防伪标记。 此库的管理工具必须提供身份验证功能。(2)病毒检测-对每个入库的媒体进行病毒检测。 如果发现病毒，必须拒绝接受或杀死所有病毒后再接受。3.2.2变更控制变更控制要点如下a .在软件生存期间，进入管理库或产品库的软件构成管理项目的变更都必须履行正规批准手续。b .如果需要更改某个软件配置管理项目，通常相关人员应该申报“软件问题报告”，详细说明问题的症状、性质和预期的影响范围(这次更改可能与哪些软件相关，可能落后于开发进度，经过多长时间上述“有关人员”与发现问题的阶段有关。 程序设计过程中发现设计错误而需要更改设计文档时，程序员应与设计者合作申报“软件问题报告”测试中发现程序或文档错误时，程序员应与测试人员合作申报维护阶段的程序c .软件配置管理员与“软件问题报告”申报人合作提交“软件变更申请”，提出要变更的软件配置管理项目的当前配置状态、此次变更的类型(纠错、改进、扩展)、与变更有关的程序、文档、数据、系统功能和性能、变更的必要性和可行性、预期的变更战略软件变更申请的形式见附录b。d .根据软件级别和程序规模，决定是否设立“变更审查组”。 本组织的组成人员应包括软件组成项目的管理员、技术负责人、总体设计人员、软件质量保证人和软件组成管理人员。 构成人数的各部门根据实际情况适当决定。 变更审查组系的临时机构。 不建立变更审核群组的，由变更核准者负责。e .“变更审查组”在收到“软件变更申请”后，应考虑该变更的必要性、技术的可行性和其他变更战略和方法、相关的软件构成管理项目、软件构成项目的功能和性能影响(利益损失权衡)、变更所需资源是否合理以及对工程进展和经费的影响等f .变更核准人在收到“变更审查组”提出的关于是否实施变更的意见后，应立即决定是否实施变更。g .经批准的“软件变更申请”将退回开发组或维护组，开发组或维护组实施相应的变更，完成必要的回归测试，制作软件变更单。h .变更后的软件构成管理项目与对应的软件变更一起，提交给软件构成管理者，再次履行入库手续。I .无论更改的软件实体是程序还是文档，相关程序和文档都必须同时完成更改和回归测试，以确保软件配置管理项目“语句匹配，语句匹配”。j .软件更改包括准确性更改、适应性更改和完整性更改，更改级别定义如下第1级：影响需求规格说明的变化、安全和系统功能的完成二级：概述设计文档的变化，影响本软件功能的实现和系统的重要性能变化级别3 :级别1、级别2以外的更改。软件更改的级别由配置管理组织决定。软件改变批准者必须与配置管理项目的原始批准者匹配。k .如果软件配置管理项目从托管库发生更改，则必须锁定托管库中的文件，以指示软件配置管理项目正在更改。 确保每个用户从托管库中检索到的软件配置管理项目始终正确有效，以防止其他用户在修改期间使用正在修改的版本。l .如果需要更改产品库中的产品，必须将该产品从产品库移动到管理库，并执行与管理库中的软件配置管理项目相同的更改管理过程。 完成并批准此更改后，可以将其保存在产品库中以供使