配置项包括但不限于哪些

Ⅰ 什么是配置

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

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

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

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

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

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

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

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

Ⅱ 电脑配置包括哪些内容

主板 内存 硬盘 CPU 显卡 电源 键盘鼠标 显示器 音响

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

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

Ⅳ 好多合同条款里的“包括但不限于”是什么意思

合同条款里面为了严谨可能都会写到包括，但不限于这样的词汇，这个到底是什么意思？其实它是一种范围的扩大。因为它后面加了一个等它列举了一些事项，但并不代表仅包括这些事项，差了一个等，差了包括但不限于，那最终表达的意思就不一样了。

这个词汇可不能随便使用的，因为它是一种范围的扩大，对于违约责任被违约方的权益保护起到了非常好的作用，但是如果你不注意的话，它也有可能成为侵犯你合法权益的一个东西，因为它扩大你的工作职责并不算违法，但你不注意的话。因为这个和公司发生扯皮，到时候你再去走劳动仲裁或者是提起诉讼，维护自己的合法权益，这就会很困难。

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

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

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

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

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

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

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

Ⅵ 关于项目管理中配置管理的实现过程，配置项的知识请教以及相比版本管理的差异

你的理解更多是“产品集成”的概念，即怎么把几个产品模块或构件组合成一个产品，但这不是配置管理的概念。
配置管理：简称CM（Configuration Management的缩写），标识、控制和管理变更的一种管理活动。它控制配置项的修改和发行；记录和报告配置项的状态和变更；保证配置项的完整性、一致性和正确性；以及控制配置项的储存、装载和交付。
根据这个定义，配置管理的主要工作包括：
1）配置库的管理活动。配置库现在工具非常多，例如GIT、SVN、CVS、VSS等等。通常会根据开发所处的阶段，设立开发库、受控库与产品库。
2）标识配置项，即需要定义如何去标识配置项。配置管理中受控制的对象被称为配置项，是生命周期中创建的信息，包含程序、数据、文档，分基线配置项和非基线配置项两类。特别是你的产品最终是如何标识的，比如怎样定义V1.0.0的规则。
3）基线的管理。是一组经过正式审查并且达成一致的规范或工作产品，是下一阶段工作的基础。怎样确定、发布基线，怎样管理基本的变更。
4）配置项变更管理。可以根据不同的配置项、不同的开发周期，明确变更的管理规则。
5）配置项状态管理与配置审计 。

而产品集成是如何把一个产品逐步的从一个个模块或组件，最后组合成一个产品的过程。
1）首先产品的技术结构上要能够支持，如果模块不能相互独立和拆解，谈不上灵活的组合。
2）在开发实现上，需要有一个集成的策略，哪些先实现，哪些后实现，哪些可以先进行集成
3）需要建立 集成的环境，使开发好的模块可以在集成环境中进行调试
4）通常开发完成后，需要进行源代码的编译，并打包成一个测试包，然后装在集成环境中，进行调试，以确认各个模块之前是否可以兼容和运转，这时通常会进行测试工作。
5）如果你想进行ABC组合，或者AC组合，那么都需要进行相应的编译、打包（例如形成EXE）过程，然后在集成环境中进行联调和测试。

Ⅶ 什么是配置项管理

按管理的严格程度，配置项一般分3个等级：
（1）纳入基线管理的配置项
纳入基线管理的配置项是指变化时要走严格变更手续的配置项，需要做变更申请，要审批。审批一般分2种严格程度：
i) 项目经理或分CCB审批就可以，一般是局部的小的变更。
ii）变更控制委员会（CCB）审批
纳入基线前，一般要经过评审或测试（称为验证）和质量保证。
(2) 没有纳入基线但是也不能随意变更的配置项，一般称为受控项
这类配置项不需要变更申请，但是要经过配置管理员或项目经理的允许才可以变更。
基线项与受控项写的权限要唯一，一般是CM或PM有唯一的写权限。
（3）非受控项
对变更不做控制。

拟纳入基线管理的配置项状态变化一般是先非受控，然后受控，最后基线化。变更时，先检出（checkou）进行修改，修改完毕后再检入（checki）转为受控，等待验证（测试或评审），通过验证后进行基线化。

拟纳入受控而不入基线的配置项状态变化一般是先非受控，然后受控。变更时，检出进行修改，修改完毕后再检入提交受控。

纳入基线管理的时机是管理平衡问题，一般是当配置项基本稳定后才纳入基线管理，如果处与频繁的变动之中，纳入基线后会增加管理成本，如单元测试通过后一般不形成基线，因为此时代码并不稳定，但是可以作为受控项，也不能任意变化。这个问题的判断也和项目组的规模有关系，如果规模很大，涉及到的人员很多，也可能需要建立基线。在系统测试后要形成基线，一般称为产品基线，此时系统基本稳定了，可以对外发布，为更多的人所了解和使用了。代码在没有纳入基线但是受控后（提交测试人员测试了），也不能随便变更了，要经过配置管理员的批准，并通知测试人员。

Ⅷ 软件配置项包括哪些内容

软件配置项包括：①与合同、过程、计划和产品有关的文档和资料；②源代码、目标代码和可执行代码；③相关产品，包括软件工具、库内的可重用软件、外购软件及顾客提供的软件等

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

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

2、软件配置项包括：

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

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

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

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

(9)配置项包括但不限于哪些扩展阅读：

1、软件配置相关

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

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

(1)标识变更；

(2)控制变更；

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

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

Ⅹ 如何从 Oracle Solaris 10 实时安装到 Oracle Solaris 11 11/11

为新安装的 Oracle Solaris 11 11/11 系统（存档系统）中的根池及其关联数据集创建 ZFS 存档。创建存档时，可以将其保存在本地可移动介质中，如 USB 驱动器，也可以通过网络将其发送到一个文件服务器以便稍后从中检索。需要使用存档时，执行以下高级步骤：
在将要迁移到 Oracle Solaris 11 11/11 的 Oracle Solaris 10 系统（迁移系统）上启动一个具有超级用户权限的 shell。
选择并配置一个引导磁盘设备，创建新的 ZFS 根池。
在新池中恢复存档的 ZFS 数据集。
执行最终配置，然后重新启动迁移系统。
迁移系统必须是运行 Oracle Solaris 10 的主机，并且其 ZFS 版本与存档系统兼容。对于将要迁移到新磁盘或系统的 ZFS 存档，确保满足以下要求：
存档系统和迁移系统为同一型号（如 SPARC T 系列）并且满足 Oracle Solaris 11 11/11 的最低要求。
迁移系统运行 Oracle Solaris 10 8/11 或更高版本，这是必须的，这样才能具有与 Oracle Solaris 11 11/11 兼容的 ZFS 版本。
如果迁移系统运行的是 Oracle Solaris 10 8/11，请在尝试恢复存档之前应用以下 ZFS 补丁。没有这个补丁，任何恢复存档的尝试都将失败。对于 Oracle Solaris 10 以后的任何版本，无需此补丁。
注：应用补丁之后，必须重新启动迁移系统。
补丁 147440-11 或更高版本，用于基于 SPARC 的系统
补丁 147441-11 或更高版本，用于基于 x86 的系统
确保将要存放新 ZFS 池的磁盘的总容量至少与存档池中分配的空间一样大。准备一节将更详细地讨论这一方面。
您必须同时拥有存档系统和迁移系统上的根权限。存档将包含所存档 ZFS 数据集中包含的所有软件和配置信息。注意，不支持通过系统存档迁移区域。迁移完成之后，您可以使用另外的过程（不在本文讨论范围之内）将 Oracle Solaris 10 区域迁移到 solaris10 标记区域。还要注意，在 Oracle Solaris 11 系统上无法运行 Oracle Solaris 8 或 Oracle Solaris 9 区域。有关如何将 Oracle Solaris 10 区域迁移到solaris10 标记区域的详细信息，请参见 Oracle Solaris 管理：Oracle Solaris 区域、Oracle Solaris 10 区域和资源管理。
所创建的存档不会具有期望的系统配置，因为我们将在一台主机上创建存档，最终将在另一台主机上运行该存档，这是两台不同的主机。第 4 阶段介绍（迁移之后）存档的配置。有必要在迁移完成后、引导 Oracle Solaris 11 11/11 之前，重新配置存档中的每个引导环境。为此，存档应只包含一个引导环境 (BE)。有关系统配置的详细信息，请参见安装 Oracle Solaris 11 系统 第 6 章“取消配置或重新配置 Oracle Solaris 实例”。
存档映像中不包含任何硬件特定的配置数据。不随备份一起转移的硬件特定的系统特性包括但不限于以下内容：
磁盘容量和配置（包括 ZFS 池配置）
硬件以太网地址
已安装的硬件外围设备
第 1 阶段：创建 Oracle Solaris 11 11/11 存档
图 1 说明创建 Oracle Solaris 11 11/11 存档时所发生的情况。

图 1. 创建 Oracle Solaris 11 11/11 存档
准备
为准备迁移，记下迁移系统上根池的磁盘拓扑结构和 ZFS 池配置。和存档系统上的磁盘一样地对迁移系统上的目标磁盘进行配置，并相应调整新 ZFS 池的大小。分配的池的大小（以下所示的 zpool list 输出中的 ALLOC 列）至少需要确保有充足的空间来在迁移系统上恢复数据集。
# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
rpool 68G 51.6G 16.4G 75% 1.00x ONLINE -

如果任何存档池的容量（如 CAP 列所示）超过 80%，最佳实践要求应扩大迁移池以规划容量。根据其他配置元素和负载的不同，增加池中的空间余量还可能有益于性能。有关如何管理 ZFS 文件系统及相关性能的更多信息，请参阅 Oracle Solaris 管理：ZFS 文件系统 指南。
为准备稍后的迁移，将各种命令的输出保存到一个文件，与存档一起保存以供迁移期间参考。清单 1 中所示命令只是最低建议，根据系统配置的不同，其他配置信息也可能有用。清单 1 中显示的命令与示例输出仅针对 rpool。
# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
rpool 68G 51.6G 16.4G 75% 1.00 ONLINE -

# zpool get all rpool
NAME PROPERTY VALUE SOURCE
rpool size 68G -
rpool capacity 75% -
rpool altroot - default
rpool health ONLINE -
rpool guid 18397928369184079239 -
rpool version 33 default
rpool bootfs rpool/ROOT/snv_175a local
rpool delegation on default
rpool autoreplace off default
rpool cachefile - default
rpool failmode wait default
rpool listsnapshots off default
rpool autoexpand off default
rpool depditto 0 default
rpool depratio 1.00x -
rpool free 16.4G -
rpool allocated 51.6G -
rpool readonly off -

# zpool status
pool: rpool
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c5t0d0s0 ONLINE 0 0 0

errors: No known data errors

# format c5t0d0s0
selecting c5t0d0s0
[disk formatted]
/dev/dsk/c5t0d0s0 is part of active ZFS pool rpool. Please see zpool(1M).

FORMAT MENU:
disk - select a disk
type - select (define) a disk type
partition - select (define) a partition table
current - describe the current disk
format - format and analyze the disk
repair - repair a defective sector
label - write label to the disk
analyze - surface analysis
defect - defect list management
backup - search for backup labels
verify - read and display labels
save - save new disk/partition definitions
inquiry - show disk ID
volname - set 8-character volume name
!<cmd> - execute <cmd>, then return
quit
format> p
PARTITION MENU:
0 - change `0' partition
1 - change `1' partition
2 - change `2' partition
3 - change `3' partition
4 - change `4' partition
5 - change `5' partition
6 - change `6' partition
7 - change `7' partition
select - select a predefined table
modify - modify a predefined partition table
name - name the current table
print - display the current table
label - write partition map and label to the disk
!<cmd> - execute <cmd>, then return
quit
partition> p
Current partition table (original):
Total disk cylinders available: 14087 + 2 (reserved cylinders)
Part Tag Flag Cylinders Size Blocks
0 root wm 1 - 14086 68.35GB (14086/0/0) 143339136
1 unassigned wm 0 0 (0/0/0) 0
2 backup wu 0 - 14086 68.35GB (14087/0/0) 143349312
3 unassigned wm 0 0 (0/0/0) 0
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 0 0 (0/0/0) 0
6 unassigned wm 0 0 (0/0/0) 0
7 unassigned wm 0 0 (0/0/0) 0

partition> ^D
#

清单 1. 各种命令的输出
将清单 1 所示的来自存档系统的信息以及迁移期间可能有用的任何其他信息置于一个文件中，并将该文件与存档文件保存在同一位置以便稍后在迁移过程中使用。
也可以使用 Oracle Explorer Data Collector 收集所有系统配置信息以供稍后参考。有关 Oracle Explorer Data Collector 及其相关文档的信息可在 Oracle Services Tools Bundle for Sun Systems 网站中找到。
有关 ZFS 管理和容量规划的其他信息，请参阅 Oracle Solaris 管理：ZFS 文件系统 指南。
创建存档
要存档根池并包括所有快照，需要创建 ZFS 复制流。为此，首先从池的顶级创建递归快照，如下所述。同样，可以对需要存档并传给迁移主机的其他池进行存档。
注意，rpool 是默认的根池名称，但在任何给定系统上根池可能有不同的名称。可以使用 beadm list -d 确定 BE 驻留在哪个池。在本文的其余部分，将使用默认名称 rpool 引用根池。
使用以下命令创建根池的递归快照。快照名称（本例中为 archive）可以基于日期或您需要的任何其他描述性标签。
# zfs snapshot -r rpool@archive

接下来，删除交换和转储设备快照，因为它们可能不包含任何相关数据，删除它们通常会显着降低存档的大小。
注：关于转储设备，尽管可能性不大，但转储设备也有可能有数据尚未被提取到 /var 数据集（以核心存档的形式）。如果是这种情况，且应保存转储设备的内容，则在删除转储设备快照之前将内容转储输出到文件系统。详情参见 mpadm(1M)。
以下命令将删除默认命名的交换和转储设备快照，虽然主机上可能部署了其他快照。要确定是否存在默认命名设备之外的其他设备，可使用swap(1M) 和 mpadm(1M) 分别列出交换和转储设备的名称。
# zfs destroy rpool/swap@archive
# zfs destroy rpool/mp@archive

既然快照已经准备好，下一步是将其发送到文件进行存档。如果要存档多个 ZFS 池，每个池将有一个快照，每个快照需要发送到自己的存档文件。以下步骤主要是创建根池的存档。不过，可用同样的方式对系统上的任何其他池进行存档。
要将快照发送到文件，请通过管道将 zfs send 命令的结果输出到 gzip 命令（如下所示），结果产生一个压缩文件，其中包含池快照的存档。创建此存档文件时，一个好的主意是，使用反映主机名、日期或其他有助于稍后确定存档内容的描述性词语的唯一命名方法。
您可以将存档文件保存在本地以便稍后进行重定位，也可以在可移动介质上创建存档文件。存储存档文件的位置应是定期备份的文件系统。同时，尽管使用了压缩，文件系统上仍应有足够的可用存储空间。一个好的经验是有足够的空间容纳 zpool list 报告的 ALLOC 量的总和。
使用以下命令在本地创建存档文件。存档文件名可以是任何有助于识别此存档以便稍后使用的字符串。通常的选择可能是使用主机名加日期，如以下示例所示。
# zfs send -Rv rpool@archive | gzip > /path/to/archive_$(hostname)_$(date +%Y%m%d).zfs.gz

现在，将存档文件移到文件服务器以便稍后检索，如图 2 所示。

图 2. 确保可访问 Oracle Solaris 11 11/11 存档
还可以选择将存档文件直接写入挂载 NFS 的路径，如下所示：
# zfs send -Rv rpool@archive | gzip > /net/FILESERVER/path/to/archive_$(hostname)_$(date +%Y%m%d).zfs.gz

类似地，可以通过 ssh 以流方式将存档文件发送到文件服务器：
# zfs send -Rv rpool@archive | gzip | ssh USER@FILESEVER "cat> /path/to/archive_$(hostname)_$(date +%Y%m%d).zfs.gz"

注意，如果通过网络以流方式传送存档，ssh 传输不支持任何一种断点续传功能。因此，如果网络连接中断，将需要重新启动整个命令。
迁移存档文件已创建，现在可以使用以下命令删除本地快照：
# zfs destroy -r rpool@archive

第 2 阶段：准备配置 Oracle Solaris 11 11/11 系统
在引导迁移的 Oracle Solaris 11 11/11 实例之前，可通过从运行 Oracle Solaris 10 的迁移系统收集所有相关系统配置参数来准备迁移。需要收集的系统配置项包括但不限于以下内容：
主机名
时区
区域设置
根口令
管理员用户信息
主网络接口（如果不是自动配置）
名称服务信息
有关所需数据的信息，请参见安装 Oracle Solaris 11 系统 第 6 章“取消配置或重新配置 Oracle Solaris 实例”。
在恢复存档时须重新生成系统配置信息。可以这样来完成这一任务：在运行中的 Oracle Solaris 11 11/11 系统上生成 SC (System Configuration) 配置文件，然后将该配置文件复制到恢复的 Oracle Solaris 11 11/11 存档以便在第一次引导时自动应用。
sysconfig 的 create-profile 子命令调用 SCI Tool 接口，向您询问系统配置信息，然后生成一个 SC 配置文件，您稍后可以用它来配置系统。
使用以下命令在本地创建 SC 配置文件。配置文件名可以是任何有助于识别该配置文件以便稍后使用的字符串。以下示例使用附有日期信息的 config。
# sysconfig create-profile -o /path/to/config_$(date +%Y%m%d).xml

然后将 SC 配置文件移到文件服务器以便稍后检索。
还可以选择创建 SC 配置文件并将其直接写入挂载 NFS 的路径，如下所示。
# sysconfig create-profile -o /net/FILESERVER/path/to/config_$(date +%Y%m%d).xml