配置項的狀態分為什麼

Ⅰ 配置項的概念

凡是納入配置管理范疇的工作成果都是配置項（CI）；一個純軟體的CIs通常也稱為軟體配置（CSCIs）。
配置項主要有兩大類：
屬於產品組成部分的工作成果；
項目管理和機構支撐過程產生的文檔。
每個配置項的主要屬性有：名稱、標識符文件狀態、版本、作者、日期等。
某報表中配置所顯示的信息的項目

Ⅱ 配置狀態報告應該包括哪些主要內容

配置狀態報告的內容一般包括以下各項。
(1)各變更請求概要:變更請求號、日期、申請人、狀態、估計工作量、實際工作量、發行版本、變更結束日期。
(2)基線庫狀態。
(3)發行信息。
(4)備份信息。
(5)配置管理工具狀態。
(6)配置管理培訓狀態。

Ⅲ 關於項目管理中配置管理的實現過程，配置項的知識請教以及相比版本管理的差異

你的理解更多是「產品集成」的概念，即怎麼把幾個產品模塊或構件組合成一個產品，但這不是配置管理的概念。
配置管理：簡稱CM（Configuration Management的縮寫），標識、控制和管理變更的一種管理活動。它控制配置項的修改和發行；記錄和報告配置項的狀態和變更；保證配置項的完整性、一致性和正確性；以及控制配置項的儲存、裝載和交付。
根據這個定義，配置管理的主要工作包括：
1）配置庫的管理活動。配置庫現在工具非常多，例如GIT、SVN、CVS、VSS等等。通常會根據開發所處的階段，設立開發庫、受控庫與產品庫。
2）標識配置項，即需要定義如何去標識配置項。配置管理中受控制的對象被稱為配置項，是生命周期中創建的信息，包含程序、數據、文檔，分基線配置項和非基線配置項兩類。特別是你的產品最終是如何標識的，比如怎樣定義V1.0.0的規則。
3）基線的管理。是一組經過正式審查並且達成一致的規范或工作產品，是下一階段工作的基礎。怎樣確定、發布基線，怎樣管理基本的變更。
4）配置項變更管理。可以根據不同的配置項、不同的開發周期，明確變更的管理規則。
5）配置項狀態管理與配置審計 。

而產品集成是如何把一個產品逐步的從一個個模塊或組件，最後組合成一個產品的過程。
1）首先產品的技術結構上要能夠支持，如果模塊不能相互獨立和拆解，談不上靈活的組合。
2）在開發實現上，需要有一個集成的策略，哪些先實現，哪些後實現，哪些可以先進行集成
3）需要建立 集成的環境，使開發好的模塊可以在集成環境中進行調試
4）通常開發完成後，需要進行源代碼的編譯，並打包成一個測試包，然後裝在集成環境中，進行調試，以確認各個模塊之前是否可以兼容和運轉，這時通常會進行測試工作。
5）如果你想進行ABC組合，或者AC組合，那麼都需要進行相應的編譯、打包（例如形成EXE）過程，然後在集成環境中進行聯調和測試。

Ⅳ 計算機軟體配置項是什麼樣20

按管理的嚴格程度，配置項一般分3個等級：（1）納入基線管理的配置項納入基線管理的配置項是指變化時要走嚴格變更手續的配置項，需要做變更申請，要審批。審批一般分2種嚴格程度： i) 項目經理或分CCB審批就可以，一般是局部的小的變更。 ii）變更控制委員會（CCB）審批納入基線前，一般要經過評審或測試（稱為驗證）和質量保證。 (2) 沒有納入基線但是也不能隨意變更的配置項，一般稱為受控項這類配置項不需要變更申請，但是要經過配置管理員或項目經理的允許才可以變更。基線項與受控項寫的許可權要唯一，一般是CM或PM有唯一的寫許可權。（3）非受控項對變更不做控制。擬納入基線管理的配置項狀態變化一般是先非受控，然後受控，最後基線化。變更時，先檢出（checkou）進行修改，修改完畢後再檢入（checki）轉為受控，等待驗證（測試或評審），通過驗證後進行基線化。擬納入受控而不入基線的配置項狀態變化一般是先非受控，然後受控。變更時，檢出進行修改，修改完畢後再檢入提交受控。納入基線管理的時機是管理平衡問題，一般是當配置項基本穩定後才納入基線管理，如果處與頻繁的變動之中，納入基線後會增加管理成本，如單元測試通過後一般不形成基線，因為此時代碼並不穩定，但是可以作為受控項，也不能任意變化。這個問題的判斷也和項目組的規模有關系，如果規模很大，涉及到的人員很多，也可能需要建立基線。在系統測試後要形成基線，一般稱為產品基線，此時系統基本穩定了，可以對外發布，為更多的人所了解和使用了。代碼在沒有納入基線但是受控後（提交測試人員測試了），也不能隨便變更了，要經過配置管理員的批准，並通知測試人員。

Ⅳ 配置管理的功能

在項目開發過程中，絕大部分的配置項都要經過多次的修改才能最終確定下來。對配置項的任何修改都將產生新的版本。由於不能保證新版本一定比老版本「好」，所以不能拋棄老版本。版本控制的目的是按照一定的規則保存配置項的所有版本，避免發生版本丟失或混淆等現象，並且可以快速准確地查找到配置項的任何版本。
配置項的狀態有三種：「草稿」、「正式發布」和「正在修改」，本規程制定了配置項狀態變遷與版本號的規則。 在項目開發過程中，配置項發生變更幾乎是不可避免的。變更控制的目的就是為了防止配置項被隨意修改而導致混亂。
修改處於「草稿」狀態的配置項不算是「變更」，無需CCB的批准，修改者按照版本控制規則執行即可。
當配置項的狀態成為「正式發布」，或者被「凍結」後，此時任何人都不能隨意修改，必須依據「申請→審批→執行變更→再評審→結束」的規則執行。 為了保證所有人員（包括項目成員、配置管理員和CCB）都遵守配置管理規范，質量保證人員要定期審計配置管理工作。配置審計是一種「過程質量檢查」活動，是質量保證人員的工作職責之一。