Ⅰ 軟體配置管理過程包括哪些活動
創建配置管理計劃、創建配置庫、基線管理、版本控制、發布管理、配置庫審計、日常維護和監管。
Ⅱ 基線（配置管理）
基線」是一個很常見的術語，在配置管理和項目管理裡面都能看到，而且還有很多衍生的術語，例如基線提升、基線化、基線審計，等等等等。 我個人以前對微軟的那套開發流程（就是proct cycle model）以及PSP、TSP了解比較多一些，這些流程裡面對「基線」的概念提的不多。但接觸RUP、MSF以及項目管理以後，看到到處都有baseline，就覺得迷惑了。 經過我自己的理解，以及和幾個同事的討論，現在我覺得我們通常看到的「基線」這個術語有兩個意思： 1）代表多個源代碼文件的一組版本。 比如有三個文件，aaa.c、bbb.c和ccc.h。可以對這三個文件做一個基線，取aaa.c的版本1.1，取bbb.c的版本1.3，取ccc.h的版本1.0。(1.1,1.3,1.0)就是一個基線。換句話說，通常在vss和cvs裡面做label，就是在做基線。 這種基線對「構建審計」特別有用：在做build的時候，可以先對所有源文件做一個label，取名為"Build2394"，然後再編譯、集成。這樣，以後如果要找到和build 2394對應的原文件，只需要到vss或者cvs裡面把所有文件對應label Build2394的版本取回來就可以了。 2）代表文檔的一個穩定狀態。 比如有一個項目設計文檔，當設計基本完成，開發即將開始的時候，需要把這個文檔固定下來，內容不能再頻繁改變，否則開發人員就無所適從了，可能導致每個人所參照的文檔並不是同一個文檔。用一句上海這里的生活用語來說，就叫做要把這個文檔「敲定」。 一個文檔如果經過討論被通過了，被固定了，就可以說這個文檔被「基線化」了，然後所有人就可以在這個「基線」的基礎上工作。 當然，文檔不可能一成不變，所以當對文檔的修改仍然會不斷進行，但這種修改並不會隨時隨地的添加到被「基線化」了的文檔中去。因為既然是「基線」，就不能隨便動。 但是到了一定時候，修改積累到一定程度，就需要把很多修改合並到原來的文檔中去了，並生成一個新版本的文檔作為團隊中所有的人的參考標准，並把老的版本淘汰掉。這就叫做「基線提升」。 以上就是我個人對「基線」這個術語的兩種不同含義的理解，大家可以討論討論看，是不是差不多就是這個意思。
Ⅲ 配置管理流程
制定配置管理計劃
配置管理員制定《配置管理計劃》，主要內容包括配置管理軟硬體資源、配置項計劃、基線計劃、交付計劃、備份計劃等。CCB審批該計劃。
配置庫管理
配置管理員為項目創建配置庫，並給每個項目成員分配許可權。各項目成員根據自己的許可權操作配置庫。配置管理員定期維護配置庫，例如清除垃圾文件、備份配置庫等。
版本控制
在項目開發過程中，絕大部分的配置項都要經過多次的修改才能最終確定下來。對配置項的任何修改都將產生新的版本。由於不能保證新版本一定比老版本「好」，所以不能拋棄老版本。版本控制的目的是按照一定的規則保存配置項的所有版本，避免發生版本丟失或混淆等現象，並且可以快速准確地查找到配置項的任何版本。
配置項的狀態有三種：「草稿」、「正式發布」和「正在修改」，本規程制定了配置項狀態變遷與版本號的規則。
變更控制
在項目開發過程中，配置項發生變更幾乎是不可避免的。變更控制的目的就是為了防止配置項被隨意修改而導致混亂。
修改處於「草稿」狀態的配置項不算是「變更」，無需CCB的批准，修改者按照版本控制規則執行即可。
當配置項的狀態成為「正式發布」，或者被「凍結」後，此時任何人都不能隨意修改，必須依據「申請→審批→執行變更→再評審→結束」的規則執行。
配置審計
為了保證所有人員（包括項目成員、配置管理員和CCB）都遵守配置管理規范，質量保證人員要定期審計配置管理工作。配置審計是一種「過程質量檢查」活動，是質量保證人員的工作職責之一。
Ⅳ 管理配置的基本操作有哪些三種
管理配置的基本操作有這三種：1.事前控制、2.即時控制、3..事後控制。
事前控制是指一個組織，在一項活動正式開始之前所進行的管理上的努力。
即時控制是在某項活動或工作過程中進行的控制。
事後控制即發生在行動或任務終了之後的控制。
制定配置管理計劃
配置管理員制定《配置管理計劃》，主要內容包括配置管理軟硬體資源、配置項計劃、基線計劃、交付計劃、備份計劃等。CCB審批該計劃。
配置庫管理
配置管理員為項目創建配置庫，並給每個項目成員分配許可權。各項目成員根據自己的許可權操作配置庫。配置管理員定期維護配置庫，例如清除垃圾文件、備份配置庫等。
Ⅳ 軟體開發中,LE基線,LA基線,還有SOM分別是什麼意思
基線(baseline)——經過正式審查和認可作為以後進一步演進的基礎，並且只有通過正式的更改控制規程才能進行更改的規格說明或產品。[IEEE—STD—610]
註：很多資料寫為進一步開發的基礎，但我覺著演進這個詞比較貼切。維基這樣定義基線：In configuration management, a "baseline" is an agreed-to description of the attributes of a proct, at a point in time, which serves as a basis for defining change. A "change" is a movement from this baseline state to a next state. The identification of significant changes from the baseline state is the central purpose of baseline identification. 意為：在配置管理中，「基線」是一個被認可的產品屬性的描述，這個時間點作為基礎服務於定義的變化。「變化」是基線狀態移動到下一狀態的運動過程。基線識別的中心目的是通過基線狀態的顯著變化進行的。）
軟體基線庫(software baseline library)——
用以存放配置項和相應的記錄的倉庫的內容。基線配置管理(baseline configuration management)——建立經正式審查和認可並作為進一步開發工作的基礎的基線。有些軟體工作產品，如軟體設計和代碼，應該有在預定點上建立的基線，並且對這些基線應該施加嚴格的更改控制過程。當與顧客打交道時，這些基線提供控制和穩定性。
基線管理(baseIine management)——在配置管理中，運用技術和行政指令指定一些文檔和對這些文檔的更改，這些文檔在配置項的生存期內的某些特定時刻，正式標識出和建立起基線。[IEEE—STD—610]
基線的分類
基線分類：按照線性過程開發的軟體工作產品分為Allocate、Requirement、Design、Coding、Integration、Test等階段，可以相應的把基線分為需求基線、設計基線、產品基線等。（註：曾經見過有公司把基線分為十幾個類的，感覺實無此必要，徒增繁重的工作，也沒有見到管理上有什麼優勢。以老張的實際經驗，分為需求基線和產品/項目基線兩類就夠用了，無論開發模式是線性或者敏捷、迭代、螺旋，這兩類都游刃有餘了。
概念漂移」來自數據挖掘，這樣說的：概念漂移(concept drift)通常是指隱含內容(hidden context)的改變會或多或少從根本上導致目標概念(target concepts)的改變。真是形象而且精煉啊。
Ⅵ 管理員應在什麼時候建立網路基線
建立網路基線，前期准備工作包括以下幾個部份：
1) 網路拓撲結構圖：在結構圖里，要力求完整展示網路的物理結構，詳細標識出網路中路由器、交換機、防火牆、伺服器類型、管理設備的位置；甚至數據流向等；
2) 了解網路現有的管理策略，網路配置情況，對哪些服務、訪問做了優化和管理；
3) 掌握確定網路的繁忙時段、業務高峰時段、空閑時段等；
4) 將上述3點形成翔實的文檔。 確定范圍和目標 建立網路基線最重要的就是要確定基線的范圍和目標（基線參數）。網路是復雜的，我們不可能也很難將所有設備、主機或鏈路的信息全部加入到基線里來，這就需要管理者按其重要程度對網路進行劃分，然後確定建立基線的范圍； 而且不同的設備、主機或鏈路所關注的參數也不盡相同，比如伺服器更多的是關注安全和性能，網路則是流量、利用率等，這些都需要管理員在錄入基線數據之前就確定好。
Ⅶ 軟體配置管理的過程描述
一個軟體研發項目一般可以劃分為三個階段：計劃階段、開發階段和維護階段。然而從軟體配置管理的角度來看，後兩個階段所涉及的活動是一致，所以就把它們合二為一，成為「項目開發和維護」階段。 一個項目設立之初PM首先需要制定整個項??研發計劃之後，軟體配置管理的活動就可以展開了，因為如果不在項目開始之初制定軟體配置管理計劃，那麼軟體配置管理的許多關鍵活動就無法及時有效的進行，而它的直接後果就是造成了項目開發狀況的混亂並註定軟體配置管理活動成為一種「救火」的行為。所以及時制定一份軟體配置管理計劃在一定程度上是項目成功的重要保證。
在軟體配置管理計劃的制定過程中，它的主要流程應該是這樣的：
CCB根據項目的開發計劃確定各個里程碑和開發策略；
CMO根據CCB的規劃，制定詳細的配置管理計劃，交CCB審核；
CCB通過配置管理計劃後交項目經理批准，發布實施。 這一階段是項目研發的主要階段。在這一階段中，軟體配置管理活動主要分為三個層面：
⑴主要由CMO完成的管理和維護工作；
⑵由SIO和DEV具體執行軟體配置管理策略；
⑶變更流程。這三個層面是彼此之間既獨立又互相聯系的有機的整體。
在這個軟體配置管理過程中，它的核心流程應該是這樣的：
⑴CCB設定研發活動的初始基線；
⑵CMO根據軟體配置管理規劃設立配置庫和工作空間，為執行軟體配置管理計劃做好准備；
⑶開發人員按照統一的軟體配置管理策略，根據獲得的授權的資源進行項目的研發工作；
⑷SIO按照項目的進度集成組內開發人員的工作成果，並構建系統，推進版本的演進；
⑸CCB根據項目的進展情況，審核各種變更請求，並適時的劃定新的基線，保證開發和維護工作有序的進行。
這個流程就是如此循環往復，直到項目的結束。當然，在上述的核心過程之外，還涉及其他一些相關的活動和操作流程，下面按不同的角色分工予以列出：
各開發人員按照項目經理發布的開發策略或模型進行工作；
SIO負責將各分項目的工作成果歸並至集成分支，供測試或發布；
SIO可向CCB提出設立基線的要求，經批准後由CMO執行；
CMO定期向項目經理和CCB提交審計報告，並在CCB例會中報告項目在軟體過程中可能存在的問題和改進方案；
在基線生效後，一切對基線和基線之前的開發成果的變更必須經CCB的批准；
CCB定期舉行例會，根據成員所掌握的情況、CMO的報告和開發人員的請求，對配置管理計劃作出修改，並向項目經理負責。
綜上所述，配置管理的工作流程如圖1所示：
Ⅷ CMMI中的的配置管理是什麼
配置管理是CMMI模型中一個支撐過程域。
配置管理是指：應用技術和管理手段來識別和記錄配置項的功能和物理特性，控制其變更，記錄和報告變更的過程和實現狀態，並檢查與項目需求之間的符合度；通過配置管理可以有效的管理工作產品與工作產品之間的一致性，合理的控制和實施變更以維護對項目范圍與邊界條件的一致的理解。
一般CM過程描述了配置管理活動的內容、規范和方法，以建立和維護軟體開發過程中各種產品的完整性和一致性。
CM使用到以下幾個重要的術語：
配置項：處於配置管理之下的軟體或/和硬體的集合體。這個集合體在配置管理過程中作為一個實體出現。
基線： 已經通過正式復審和批準的某規約或產品，它因此可以作為進一步開發的基礎，並且只能通過正式變更控制過程來改變；基線有一組配置組成，這些配置構成了一個相對穩定的狀態，不能再被任何人隨意修改。
配置標識：識別產品的結構、產品的構件及其類型，為其分配唯一的標識符，並以某種形式提供對它們的存取。
控制：通過建立產品基線，控制軟體產品的發布和在整個軟體生命周期中對軟體產品的修改。
狀態統計：記錄並報告構件和修改請求的狀態，並收集關於產品構件的重要統計信息。
配置審計：通過第三方（例如：軟體質量保證工程師）來確認產品的完整性並維護構件間的一致性，即確保產品是一個嚴格定義的構件集合；
配置管理員：根據本過程的規定，在本公司內部具體實施與操作本過程的人員/角色。根據實施的層級的不同，配置管理員可以區分為「產品配置管理員」和「項目配置管理員」兩個角色，一般產品配置管理員是專職的，項目配置管理員有項目成員兼職。
Ⅸ 配置管理中的配置基線如何理解
論壇專家長河觀點：基線，baseline，就是基準的意思，但如何記錄這個事實上的基準呢，就是打一個快照，然後，定義這個快照為某個狀態的基線