|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
配置状态报告也称配置状态说明与报告，它是配置管理的一个组成部分，目的是及时、准确地给出软件配置项的当前情况，供相关人员了解，以加强配置管理工作。
|
|
|
|
配置状态报告就是要在某个特定的时刻观察当时的配置状态，也就是要对动态演化着的配置项取“快照”，以利于在状态报告信息分析的基础上更好地进行控制。
|
|
|
|
|
|
配置状态报告应定期进行，报告中需跟踪的主要方面有产品描述记录、每个受控软件组件的状态、每个构建版发布的内容和状态、每个基线的内容、配置验证记录、变更状态记录和所有位置的所有配置项的安装状态等。
|
|
|
|
|
|
.各份变更申请概要：变更申请号、日期、申请人、状态、估计工作量、实际工作量、发行版本、变更结束日期。
|
|
|
|
.基线库状态：库标识、至某日预计库内配置项数、实际配置项数。
|
|
|
|
.发行信息：发行版本、计划发行时间、实际发行日期、说明。
|
|
|
|
|
|
|
|
|
|
|
|
配置状态报告应着重反映当前基线配置项的状态，以作为对开发进度报告的参照。为了说明项目变更情况，也应该对变更状态进行报告。变更状态说明的信息可通过变更申请和故障报告得到，变更状态可分为活动态（正在实施变更）、完成态（已完成变更）和未列入变更三种。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
变更请求是关于修改任何文档、可交付成果或基准的正式提议。变更请求被批准之后将会引起对相关文档、可交付成果或基准的修改，也可能导致对项目管理计划其他相关部分的更新。其他变更请求包括必要的预防措施或纠正措施，用来防止以后的不利后果。变更请求可以是直接或间接的，可以由外部或内部提出，可能是自选或由法律/合同所强制的。
|
|
|
|
|
|
.纠正措施：为使项目工作绩效重新与项目管理计划一致而进行的有目的的活动。
|
|
|
|
.预防措施：为确保项目工作的未来绩效符合项目管理计划而进行的有目的的活动。
|
|
|
|
.缺陷补救：为了修正不一致的产品或产品组件而进行的有目的的活动。
|
|
|
|
.更新：对正式受控的项目文件或计划等进行的变更，以反映出修改或增加的意见或内容。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
基线（baseline）是项目生存期各开发阶段末尾的特定点，也称为里程碑（milestone），在这些特定点上，阶段工作已结束，并且已经形成了正式的阶段性产品。
|
|
|
|
建立基线的概念是为了把各开发阶段的工作划分得更加明确，使得本来连续开展的开发工作在这些点上被分割开，从而更加有利于检验和肯定阶段工作的成果，同时有利于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成果，并且认为建立了里程碑，有些完成的阶段成果已被冻结。
|
|
|
|
作为阶段工作的正式产品，基线应该是稳定的，如作为设计基线的设计规格说明应该是通过评审的。如果还只是设计草稿，就不能作为基线，不能被冻结。
|
|
|
|
如果把软件看作是系统的一个组成部分，以下3种基线最受人们关注的：功能基线、分配基线、产品基线。
|
|
|
|
（1）功能基线：指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志。
|
|
|
|
（2）分配基线（指派基线）：指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标志。
|
|
|
|
（3）产品基线：指在软件组装与系统测试阶段结束时，经过正式评审批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。
|
|
|
|
另外，交付给外部顾客的基线一般称为发行基线，内部使用的基线称为构造基线。释放是指在软件生存周期的各个阶段结束时，由该阶段向下阶段提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也称为交付。
|
|
|
|
：提出基线的概念本来是为了更好地实现变更控制，但如果把每个基线都当成一个整体来看待会造成麻烦。因为一个变更很可能只涉及基线的很小部分。例如，假定某个大型软件中的一个模块修改了，如果将这一变更当做整个软件产品基线的变更，就很不方便。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
随着信息系统软件版本不断变化，开发时间的紧迫以及多平台开发环境的采用，使得软件开发、维护面临越来越多的问题，其中包括对当前多种软件的开发和维护、保证产品版本的精确、重建先前发布的产品、加强开发政策的统一和对特殊版本需求的处理等等。
|
|
|
|
信息系统软件配置管理是一种应用于整个软件工程过程的标识、组织和控制修改的围绕软件资产的管理技术。界定软件的组成项目，对每个项目的变更进行管控（版本控制），并维护不同项目之间的版本关联，以使软件在开发过程中任一时间的内容都可以被追溯。其关键活动包括：配置管理计划、配置项管理、版本控制、变更控制、配置审计、状态报告等。
|
|
|
|
|
|
根据信息系统软件运维制度和规范、标准，制定配置管理计划，主要包括以下内容。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性，及其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素。
|
|
|
|
为了方便对“配置”进行管理，“配置”经常被划分为各类配置项，这类划分是进行软件配置管理的基础和前提。配置项是一组软件功能或者物理属性的组合，在配置管理过程中，配置项被作为一个单一的实体对待。配置项包括各种管理文档和技术文档，源程序与目标代码，以及运行所需的各种数据等。同时，应该建立配置库来管理所有的配置项。
|
|
|
|
|
|
版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加，修改或删除，配置项的版本随之演变。应当记录每个软件配置项的所有历史记录，并记录该软件配置项由何人创建，何人在何时因何原因进行了修改等信息，以及对这些软件配置项版本的进行检索和信息查询等活动。
|
|
|
|
|
|
变更在信息系统软件运维过程中是不可避免的。变更控制是配置管理的一个重要组成部分，包含评估、协调、批准／拒绝、实施对配置项的变更。
|
|
|
|
|
|
配置审计是对配置管理的独立的查检过程，确认受控软件配置项满足需求并就绪。其内容如下。
|
|
|
|
（1）功能审计：配置项的变更控制是否和配置管理计划中的描述相一致。
|
|
|
|
（2）物理审计：配置项的完整性、正确性、一致性和可跟踪性。
|
|
|
|
|
|
状态报告用来记录和报告有效管理配置所需要的必要信息。这些信息包括一个已批准的配置标识清单，变更请求当前的处理状态，以及批准的变更的实现情况。配置状态报告可以跟踪对软件的更改的过程，它保证对正在进行和已完成的变更进行记录、监视并通报给相关人员。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
随着虚拟化和云计算的发展，导致了企业内外需要加以管理的服务器数量大幅增长。配置管理工具主要用于配置和维护数十台、数百台、乃至数千台服务器。目前，主要的服务器配置管理工具包括Ansible、Chef、Puppet、SaltStack等。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GB/T 11457—2006对配置项的定义为：“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。”配置项的例子有：交付的软件产品和数据，用于创建或支持软件产品的支持工具，供应商提供的软件和客户提供的设备/软件，各类文档，源代码，可执行代码，测试用例，运行软件所需的各种数据等。
|
|
|
|
在信息系统的开发过程中需加以控制的配置项可以分为基线配置项和非基线配置项两类。例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。所有配置项的操作权限应由CMO（配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
状态报告用来记录和报告有效管理配置所需要的必要信息。这些信息包括一个已批准的配置标识清单，变更请求当前的处理状态，以及批准的变更的实现情况。配置状态报告可以跟踪对软件的更改的过程，它保证对正在进行和已完成的变更进行记录、监视并通报给相关人员。
|
|
|
|
|
|
|
|
|
|
|
|
|
