什麼是配置項

❶ 什麼是配置

什麼是軟體配置項？一般認為：軟體生存周期各個階段活動的產物經審批後即可稱之為軟體配置項。
軟體配置項包括：

–①與合同、過程、計劃和產品有關的文檔和資料；

–②
源代碼、目標代碼和可執行代碼；

–③相關產品，包括軟體工具、庫內的可重用軟體、外購軟體及顧客提供的軟體等。

在軟體建立時變更是不可避免，而變更更回劇了項目中軟體工程師間的混亂。之所以產生混亂，是因為在進行變更前沒有仔細分析，或沒進行變更控制。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）轉為受控，等待驗證（測試或評審），通過驗證後進行基線化。擬納入受控而不入基線的配置項狀態變化一般是先非受控，然後受控。變更時，檢出進行修改，修改完畢後再檢入提交受控。納入基線管理的時機是管理平衡問題，一般是當配置項基本穩定後才納入基線管理，如果處與頻繁的變動之中，納入基線後會增加管理成本，如單元測試通過後一般不形成基線，因為此時代碼並不穩定，但是可以作為受控項，也不能任意變化。這個問題的判斷也和項目組的規模有關系，如果規模很大，涉及到的人員很多，也可能需要建立基線。在系統測試後要形成基線，一般稱為產品基線，此時系統基本穩定了，可以對外發布，為更多的人所了解和使用了。代碼在沒有納入基線但是受控後（提交測試人員測試了），也不能隨便變更了，要經過配置管理員的批准，並通知測試人員。