什么是配置项

❶ 什么是配置

什么是软件配置项？一般认为：软件生存周期各个阶段活动的产物经审批后即可称之为软件配置项。
软件配置项包括：

–①与合同、过程、计划和产品有关的文档和资料；

–②
源代码、目标代码和可执行代码；

–③相关产品，包括软件工具、库内的可重用软件、外购软件及顾客提供的软件等。

在软件建立时变更是不可避免，而变更更回剧了项目中软件工程师间的混乱。之所以产生混乱，是因为在进行变更前没有仔细分析，或没进行变更控制。Babich曾经这样说过：“协调软件开发使得混乱达到最小的技术叫配置管理。配置管理是一种标识、组织和控制修改的技术，目的是使错误达到最小并最有效地提高生长率。

软件配置管理，叫SCM，它应用于整个软件工程过程。因为变更在任何时刻都可能发生，因此SCM活动的目标就是为了(1)标识变更；(2)控制变更；(3)确保变更正确地实现(4)向其他有关的人员报告变更。

软件配置管理是贯穿整个软件生存周期的一项技术。它的主要功能是控制软件生存周期中软件的改变，减少各种改变所造成的影响，确保软件产品的质量。正确应用软件配置管理是开发高质量软件所不可缺少的。软件配置管理的过程是软件开发过程中质量管理的精髓。

所谓硬件配置文件，是指在启动计算机时告诉Windows应该启动哪些设备，以及使用每个设备中的哪些设置的一系列指令。

❷ 易语言写配置项和读配置项的具体做法是什么

文件名称 update.ini

测试内容

[1]
1-1=V1-1
1-2=V1-2
1-3=V1-3
1-4=V1-4
1-5=V1-5
1-6=V1-6
[2]
2-1=V2-1
2-2=V2-2
2-3=V2-3
2-4=V2-4
2-5=V2-5
2-6=V2-6

测试代码

.版本 2
.支持库 spec

.局部变量 配置文件名, 文本型
.局部变量 节计数器1, 整数型
.局部变量 配置项计数器1, 整数型

配置文件名 ＝ 取运行目录 () ＋ “serverupdate.ini”
.变量循环首 (1, 2, 1, 节计数器1)
.变量循环首 (1, 6, 1, 配置项计数器1)
调试输出 (读配置项 (配置文件名, 到文本 (节计数器1), 到文本 (节计数器1) ＋ “-” ＋ 到文本 (配置项计数器1), “”))
.变量循环尾 ()
.变量循环尾 ()

既然能输出来所有的数据，怎么利用这个更新文件其实很简单

1-文件更新肯定要先知道服务器上的配置文件目录和文件，这个直接写在程序路径就OK

2-获取要更新文件的数量，格式嘛，就按照我这里大概的思路了，节名称[1] 代表第一个文件，以此类推

获取1-1 这个可以存储需要更新的列表文件名称 1-2 可以存储 配置项名称 1-3 存储 配置项对应的 val值

用于本地INI的配置高还原和灵活性

本地的ini被整理出来的格式

文件名称：V1-1 -> update.ini

V1-2 ->[节名称1]

V1-3->配置项名称

V1-4->配置项值

。

。

。

这个方法自己总结的，效果还不错，应对大批量，要使用同一个文件名称不同更新的问题，这个就很好解决的方案

❸ IT运维服务中的配置管理一般使用什么工具什么是配置管理数据库中的配置项、配置项的组成部件

是用的SITEVIEW的ITSM服务管理系统不，可以直接找他们IT运维管理系统项目组的工程师解决

❹ 配置项测试是指什么

配置测试主要是针对硬件而言，其测试过程是测试目标软件在具体硬件配置情况下，出不出现问题，为的是发现硬件配置可能出现的问题，大体来讲硬件配置分为以下几类：
一：PC
二：组件
三：外围设备
四：接口
五： 选项和内存
六： 设备驱动

❺ 软件测试中什么是配置项测试具体定义和具体工作是什么

配置项测试的理解，我觉得得先清楚两个概念：

①软件配置项：我认为软件配置项就是一个开发完成的,已经进入配置管理的,准备提供给客户的产品。可以是可执行代码，也可以是产品文档。

②软件需求规格说明书：软件需求规格说明书是在项目前期进行需求分析的时候得到的一份文档，这份文档中描述了用户的需求，是初始阶段甲乙双方对项目的共同理解，比如一些界面设计，流程描述，这个是整个开发工作的基础。

那么配置项测试，就可以理解成是对软件配置项的一种检查，检查它与软件需求规格说明书是否一致。比如对可执行代码进行功能测试，关注它的功能是否与软件需求规格说明书中要求的一致。或者对一份产品文档进行文档审查，关注是否已经按照软件需求规格说明书中要求，描述了安装步骤，或者文档中描述的接口是否与软件需求规格说明书中的相同。

所以配置项测试，需要在单元测试和集成测试之后进行。

我理解的测试顺序应该是：单元测试->集成测试->配置项测试->系统测试->确认测试，如果项目存在变更，还需要进行回归测试。当然，这个只是帮助理解，实际中肯定不会是按顺序做的。

❻ 软件配置管理中的配置项是什么样

配置项主要有两大类：属于产品组成部分的工作成果；
项目管理和机构支撑过程产生的文档。
每个配置项的主要属性有：名称、标识符文件状态、版本、作者、日期等。

❼ 配置项是什么

不定期用于配置管理正在配置管理过程中作为单个实体对待的硬件集合、软件集合或硬软件集合

❽ 计算机软件配置项是什么

1、软件配置项（SCI）：软件生存周期各个阶段活动的产物经审批后即可称之为软件配置项。

2、软件配置项包括：

（1）与合同、过程、计划和产品有关的文档和资料；

（2）源代码、目标代码和可执行代码；

（3）相关产品，包括软件工具、库内的可重用软件、外购软件及顾客提供的软件等。

3、软件配置项是作为配置项识别活动的产出物，CMMI中要求有文档化的配置项识别准则，根据准则来进行配置项识别，列出配置项列表，给与配置项唯一的编号、名称等，并标明配置项的一些重要属性，如：它的存储位置、它的负责人、对应源码语言、受控级别等。

(8)什么是配置项扩展阅读：

1、软件配置相关

Babich曾经这样说过：“协调软件开发使得混乱达到最小的技术叫配置管理。配置管理是一种标识、组织和控制修改的技术，目的是使错误达到最小并最有效地提高生长率。

软件配置管理，叫SCM，它应用于整个软件工程过程。因为变更在任何时刻都可能发生，因此SCM活动的目标就是为了：

(1)标识变更；

(2)控制变更；

(3)确保变更正确地实现;

(4)向其他有关的人员报告变更。

❾ 常见的软件配置项有哪些

csci是计算机软件配置项(computer
software
configuration
item)简称，在软件设计文档中经常用到。
配置与配置项
在配置管理中，“配置”和“配置项”是重要的概念，“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所
有产品特性，其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素，相对与硬件类配置，软件产品的“配置”
包括更多的内容并具有易变性。
受控软件经常被划分为各类配置项（configuraion
items,
cis），这类划分是进行软件配置管理的基础和前提，cis是逻辑上组成软件系统的各组成部分。比如一个软件产品包括几个程序模块，每个
程序模块及其相关文档和支撑数据可能被命名为一个ci。一个系统包括的cis的数目是一个与设计密切相关的问题，关于怎样将一个软件系统划分为不同的
cis将在以下有关章节中阐述，注意如果一个产品同时包括硬件和软件部分，一般一个ci也同时包括软件和硬件部分，一个纯软件的ci通常也称之为软件配置
项（csci）。本规范的ci一般指csci，软硬件的配置管理有一些相通的地方，但因为软件更易于修改，所以软件配置管理是一个更应该系统化的过程。
基线与基线管理
各cis随软件开发活动的进展，会有越来越多的部件进入受控状态。一般地，软件开发过程从概念演绎和需求分析开始，然后是设计，各cscis的编码或写
作，集成测试，最后是用户手册的编写等。软件配置管理包括了在软件生命周期的时间分散点上对各cis进行标识并对对他们的修改进行控制的过程。在一个开发
阶段结束或一组功能开发完成后，要对相应的cis进行基线化并形成各类基线。在配置管理系统中，基线就是一个ci或一组cis在其生命周期的不同时间点上
通过正式评审而进入正式受控的一种状态，而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。
每个基线都将接受配置管理的严格控制，对其的修改将严格按照变更控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线，这就是“基线管理”的过程，因此基线具有以下属性：
通过正式的评审过程建立
基线存在于基线库中，对基线的变更接受更高权限的控制
基线是进一步开发和修改的基准和出发点。
一般地，第一个基线包含了通过评审的软件需求，因此称之为“需求基线”，通过建立这样一个基线，受控的系统需求成为进一步软件开发的出发点，对需求的变更被正式初始化、评估。受控的需求还是对软件进行功能评审的基础。

❿ 计算机软件配置项是什么样20

按管理的严格程度，配置项一般分3个等级：（1）纳入基线管理的配置项纳入基线管理的配置项是指变化时要走严格变更手续的配置项，需要做变更申请，要审批。审批一般分2种严格程度： i) 项目经理或分CCB审批就可以，一般是局部的小的变更。 ii）变更控制委员会（CCB）审批纳入基线前，一般要经过评审或测试（称为验证）和质量保证。 (2) 没有纳入基线但是也不能随意变更的配置项，一般称为受控项这类配置项不需要变更申请，但是要经过配置管理员或项目经理的允许才可以变更。基线项与受控项写的权限要唯一，一般是CM或PM有唯一的写权限。（3）非受控项对变更不做控制。拟纳入基线管理的配置项状态变化一般是先非受控，然后受控，最后基线化。变更时，先检出（checkou）进行修改，修改完毕后再检入（checki）转为受控，等待验证（测试或评审），通过验证后进行基线化。拟纳入受控而不入基线的配置项状态变化一般是先非受控，然后受控。变更时，检出进行修改，修改完毕后再检入提交受控。纳入基线管理的时机是管理平衡问题，一般是当配置项基本稳定后才纳入基线管理，如果处与频繁的变动之中，纳入基线后会增加管理成本，如单元测试通过后一般不形成基线，因为此时代码并不稳定，但是可以作为受控项，也不能任意变化。这个问题的判断也和项目组的规模有关系，如果规模很大，涉及到的人员很多，也可能需要建立基线。在系统测试后要形成基线，一般称为产品基线，此时系统基本稳定了，可以对外发布，为更多的人所了解和使用了。代码在没有纳入基线但是受控后（提交测试人员测试了），也不能随便变更了，要经过配置管理员的批准，并通知测试人员。