前言：中文期刊網精心挑選了配置管理與變更管理范文供你參考和學習，希望我們的參考范文能激發你的文章創作靈感，歡迎閱讀。
配置管理與變更管理范文1
【關鍵詞】中小企業、配置管理流程
【中圖分類號】C29【文獻標識碼】A【文章編號】1672-5158（2013）07-0492-02
一、 引言
軟件配置管理的發展在國內雖然是21世紀的事，但是發展比較迅速，得到了軟件公司的普遍認可。但是對于中小公司，由于重視不夠或缺少相關知識，在實際使用中存在一些問題。中小公司照搬大公司流程存在也不切合實際。
二、 配置管理流程
2.1制定配置管理計劃
在《項目開發計劃》完成后，配置管理員（SCME）參考項目經理制定的《項目開發計劃》完成《配置管理計劃》，《配置管理計劃》中需要明確項目的基線配置項計劃，以及基線計劃等信息。
不同的項目，配置管理計劃的內容可以不同。主要受以下方面影響：
項目的大小和復雜性會影響到配置管理計劃。特別簡單的項目可能只需要一個配置管理工具，簡單管理一下源代碼；但是大項目、復雜的項目則需要詳細的配置計劃。
特殊的項目需要更詳細的計劃。舉例來說，如果企業中絕大多數產品都是完整獨立開發，而某產品使用了開源代碼。那么在該項目的配置計劃中，此點就要考慮。
2.2 項目配置庫的建立
項目立項后，項目經理通知配置管理員建立項目的配置庫，同時為項目組人員開放配置庫權限。
2.3 配置識別
配置識別的目的是識別配置項和基線。
配置項是指處于配置管理之下的軟件或/和硬件的集合體。這個集合體在配置管理過程中作為一個實體出現。
基線是已經通過正式復審和批準的某規約或產品，它因此可以作為進一步開發的基礎，并且只能通過正式的變更控制過程來改變。
配置識別活動包括以下幾個內容：
* 配置項識別
配置項可以分為基線配置項和非基線配置項。基線配置項包括所有的技術類文檔和源程序等；非基線配置項包括項目的各類計劃和報告等。
配置管理工作的關注重點是基線配置項。配置項識別由SCME參照項目開發計劃中的交付物，同項目經理共同識別基線配置項，以及配置項間的依賴關系。配置管理員需要完成《配置管理計劃》中的配置項計劃。
* 配置項標識
配置項的標識，版本等規則，參見企業標識規范。
* 基線建立
一般在項目的不同階段有對應的基線。
> 基線建立
當基線包含的配置項穩定后，由項目經理通知SCME建立基線?；€建立后一般不允許隨意更改。SCME需要對基線庫的權限進行設置。
> 基線變更
當基線建立后，如果基線配置項經過若干次變更，在配置項穩定后，項目經理認為有必要進行變更（再等），或者基線不穩定，需要回朔到上一基線，由項目經理通知SCME對基線進行變更。
2.4 版本控制
版本控制能夠簡單、明確地重現軟件系統的歷史版本。一般的配置工具都能自動保存配置項的版本歷史，但是大多時候，針對項目不同階段需要整體化的標識。以下是整體化版本控制的方法：
* 標簽
如果項目只有一個主干，只需要通過打標簽的方式，來辨明當前的整體版本。這樣將來搜索所有的以這個整體版本命名的標簽，就能找到這個整體版本對應的所有文件的正確版本，包括源代碼。
* 分支
不同的客戶，基本需求一定，但是有不同的差別，此時就需要用到分支。使用分支，能夠有效地實現隔離，也實現共享。但是分支是有管理成本的。如果標準版的比較頻繁，而客戶又要求變體的跟上標準版的話，那么需要頻繁創建分支。另一方面，如果變體所在的分支上，包含了一些應該共享的改動，那么應該合并到主干。這樣，相應管理成本也會提高。
2.5變更控制
在項目開發過程中，配置項發生變更幾乎是不可避免的。變更控制的目的就是為了防止配置項被隨意修改而導致混亂。
在瀑布模型的管理中：修改處于“草稿”狀態的配置項不算是“變更”。當配置項的狀態成為“正式”，或者被“凍結”后，此時任何人都不能隨意修改，必須依據變更的規則執行。
以下為變更規則：
1） 變更請求
2） 變更審核
3） 配置項出庫
4） 變更實施
5） 變更驗證
6） 配置項入庫
SCME負責實施配置項入庫，確保配置項處于“正式”狀態，并且版本正確。并通知項目經理，項目組人員，質量保證人員等變更已經完成。
但是還有兩種情況，可能不需要嚴格的變更流程：
1） 功能小變動：把程序已有的功能，稍微增強或改變一下。特點是：數量多容易丟，改動量不太大。對這類請求的管理，建議像對缺陷的管理，進行分別跟蹤、處理，直至解決。
2） 迭代模型中管理變更
迭代開發把一個大項目在時間軸上分解成很多小項目，每個小項目被稱作一個迭代。幾乎每次迭代，都會包含需求分析，系統設計、代碼實現，以及集成和測試。這樣就不必刻意走變更流程，只要通過基線或標簽的方式就可以對配置項進行識別。但是在每一個迭代中，出現的對正式的配置項進行修改，還需要走變更流程。
2.6配置審計
配置審計是對交付的軟件基線進行檢驗，以驗證其中包含了所有必需的內容，并且這些內容本身都是經過驗證而滿足了需求。配置審計分為功能審計和物理審計兩種：
1） 功能審計是一種驗證審核，它驗證配置項的開發是否完全滿足特定的性能和功能特性，并且所有的操作和支持文檔是齊備的。功能審計主要方法有評審、測試等。一般由研發人員和測試人員來做。
2） 物理審計的目的是為了驗證配置項是按照技術文檔中的規定構建的。
物理審計工作主要由配置管理人員定期（每月）執行。也可因事件驅動進行，比如配置項，新版本等。
主要進行以下內容：
> 審核配置項一致性，具體檢查點如下：
* 參照配置管理計劃檢查配置項是否按時提交；
配置項是否滿足配置管理相關規定，如配置項標識，版本，狀態，版式等；
配置項信息是否正確；
配置項評審記錄、變更記錄是否完備等。
審核配置項版本一致性：檢查配置管理工作表中配置項版本信息與配置庫中配置項版本信息是否一致，以免工作疏漏造成不一致情況。
審核基線一致性：檢查配置管理工作表中基線內容與配置庫中基線信息是否一致。
審核結構權限一致性：檢查配置庫結構權限是否合理，是否滿足安全適用需要。
2.7配置狀態報告
配置狀態報告工作主要由SCME定期執行。也可因事件驅動進行，比如階段總結，階段評審等。
常用的配置狀態報告分為：
> 周報告
周報告每周進行，主要內容為本周開展的關于SCM的活動總結，以及對SCM工作發現的問題的跟蹤。周報告的審閱人為項目經理、質量部經理。
> 總結報告
總結報告主要用于項目結束時，或者因事件驅動而對SCM工作的當前狀態進行概括總結?？偨Y報告的審閱人為項目經理、質量部經理。
2.8 配置中止
當項目結束時，由項目經理確認此項目已不會再有配置管理方面的變更，由項目經理通知配置管理員項目關閉。
配置管理員關閉該項目的所有讀寫權限，并將項目基準庫內容移入產品庫中。該項目配置管理活動中止。
三、 結束語
本文對配置管理各環節都根據實際進行了簡化變通，或提供了方法，對中小企業的配置工作有一定的借鑒意義。
參考文獻
配置管理與變更管理范文2
針對軟件開發平臺應用的相關內容，對軟件開發平臺中配置管理應用的具體策略進行研究。先介紹了軟件配置過程中KPA的相關內容，并對其中存在的問題進行研究；再結合軟件開發平臺的實際技術內容，對其具體應用進行研究，以進一步提高軟件配置管理能力，為提高軟件開發能力奠定基礎。
【關鍵詞】
軟件開發平臺；配置管理；應用
隨著現代科學技術的進一步發展，軟件開發平臺開始受到社會的普遍關注，對相關人員而言，如何實現軟件開發過程中的高質量、低成本成為其工作的主要內容。CMMI（軟件能力成熟度模型集成）的出現有效的滿足了人們的要求，其主要分為5個成熟度，每個成熟度級別都包含若干個關鍵過程域（KPA），而軟件配置管理就是其中的一個重要KPA。在本次研究中，主要針對軟件開發平臺中配置管理應用的相關問題進行研究，希望洋酒內容能對相關學者研究有所幫助。
1軟件配置管理過程KPA
1.1配置管理的必要性裴樹軍等通過研究認為，隨著軟件規模不斷擴大，導致軟件研發過程中的中間產品數量不斷增多，嚴重增加了管理難度。而對整個軟件開發而言，配置管理是軟件開發的核心內容之一，若不做好配置管理工作，則勢必會引發一系列問題，具體表現為以下幾點：
1.1.1同時更新的問題當兩個或多個人員同時研發一種軟件時，同時更新現象會損害他人工作，影響了工作的整體進程。
1.1.2通用代碼問題在一些特殊的大型系統中，如果相關人員已經根據相關要求修改了軟件的部分功能，則會導致所有將該內容告知所有人員；如果不能及時的告知每一個軟件開發人員，則會導致部分出現嚴重的系統操作失誤問題。
1.1.3版本沖突問題從當前部分大型軟件的開發過程來看，其主要通過增量式的方式實現開發的。在這種背景下，一個大型系統可能涵蓋諸多活動版本，這樣很容易產生沖突現象，不利于保證軟件正常運行。對相關人員而言，若不能有效處理上述問題，將會造成嚴重的混亂現象，因此做好配置管理工作十分重要。
1.2軟件配置管理分析
配置管理過程是整個軟件生命周期過程中的重要元素內容之一，這在CMMI中，配置管理目標主要分為三種包括，建立基線、控制變更、跟蹤等。一般認為，建立基線主要存在三種特定的實踐內容：
（1）保證標示能在配置管理的配置項中，并建立一個能滿足配置管理的系統，完成基線創建等基礎過程。
（2）在使用一個配置管理系統后，所有的變更都能在第二個目標結束之前實現被跟蹤與控制。
（3）保持配置項的記錄，并按照基線的相關內容開展配置審計。
2配置管理研究
2.1配置管理的基本工具
當前在開展配置管理中，常用的工具包括：
2.1.1Starteam該工具提供了真正的協同工作，保證整個開發環境內外的所有團隊與功能模塊都能參與到目標活動中，保證了配置工作的順利開展。因此可以認為，Starteam是一個集合了版本控制、缺陷跟蹤等多種功能于一體的軟件。
2.1.2CC該工具是ROSE構建的主要組成部分，常被應用在復雜產品開發等特殊環境中，能有效解決多種產品開發與維護的要求，具有良好的應用價值。CC的主要功能包括建立管理體系、明確過程控制等，是實現配置管理的主要工具。
2.1.3VSS該工具能將所有項目原文件給進行管理，并通過特有的方式將原文件進行儲存。但在操作過程中需要注意的是，相關人員不能直接修改數據庫中的文件，而是需要通過該版本管理器，對項目項目的源程序進行控制，將其拷貝到成員自己的目錄中進行修改，再講修改結果提交給VSS，之后才能完成數據資料修改。
2.2軟件配置管理的基本流程
有項目經理負責監督整個項目配置管理的實際情況，重點研究配置管理中存在的問題，并根據問題提出相應的解決措施；項目組成員協助開展配置管理工作。在上述工作內容的基礎上，配置管理人員根據既定的項目目標計劃，在項目經理的指引下參與制定《配置管理計劃》并在日后工作中始終按照《計劃》的相關內容展開工作，并按照相關要求調諧《配置狀態報告》，做好相應的資料備份工作。在配置工作結束之后，資產管理人員收集組織資產資料，并維護組織資料庫。
2.3版本控制
總體而言，版本控制是實現軟件配置管理的核心內容，其主要目的就是根據具體的軟件管理規則保存配置項目的版本資料，以降低發生版本丟失的概率。一般認為，在確定配置項過程中，常見的狀態如圖1所示。在整個配置項最初建立過程中，其產生的狀態為“編輯”。在這種狀態下，開發人員能編制整個配置項。在編輯結束后，經過編輯的配置項進入“評審”狀態，此時若顯示評審通過，則會將配置項的狀態改變為“正式”；而評審未通過，則進入調試狀態，對配置項進行二次修改，直至成為“正式”狀態。
2.4變更控制
在整個軟件配置管理過程中，變更控制的主要內容是創建產品基線，并以此為核心，在整個產品生存周期的過程進行變更，最終建立一整套完成的軟件控制修改的機制，確保其質量能滿足運行的要求。從其應用過程來看，需要變更的軟件首先會處在“待修改”的狀態，并由具體的操作人員將其分配到具體人員的手中。在經過相關人員的修改并結束后，變更軟件將會改變為“關閉”狀態，此時由系統進行評審，若評審結果顯示無法修改，則會將其設置為“不修改狀態”。而如果認定為不需要進行修改，也能將其關閉，避免過度處理現象發生。3結束語主要研究了軟件開發平臺中配置管理的相關內容，并對其應用進行詳細的研究。總體而言，軟件配置管理在軟件研發中發揮著重要作用，因此對相關人員而言，在工作中要正確認識到軟件配置的實際要求，并提出針對性的管理措施，為保證軟件開發工作順利進行奠定基礎。
參考文獻
[1]裴樹軍，陳德運，陳曉雪.軟件配置管理在軟件開發平臺中的應用[J].哈爾濱理工大學學報,2010,01:28-32.
[2]李向蔚.嵌入式系統軟件開發平臺配置管理技術的研究與實現[D].電子科技大學,2005.
配置管理與變更管理范文3
關鍵詞：軟件配置管理；軟件開發；配置管理工具；ClearCase
中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2008)35-2212-02
Study on SCM & ClearCase
ZHANG Yue
(Tongji University,Shanghai 200092,China)
Abstract: Software development management is necessary for software to be developed in high efficiency and low cost,and Software configuration management (SCM) is the key of software development management,so SCM is also necessary for software development. Day by day,automatic tools for SCM are becoming more and more required.Besides,in this essay,I also state my views of ClearCase,which is widely used in SCM.
Key words: SCM;software development;CMT;clearCase
1 軟件配置管理概述
1.1 軟件配置管理背景
在開發軟件代碼時，軟件公司都會有各自遵循的開發過程，來試圖達到同樣的目的：以最低的生產成本完成高質量的軟件。特別是隨著軟件團隊人員的增加，軟件版本不斷變化，開發時間的緊迫以及多平臺開發環境的采用，使得軟件開發面臨越來越多的問題，其中包括對當前多種產品的開發和維護，保證產品版本的精確，重建先前的產品，加強開發政策的統一和對特殊版本需求的處理等等，解決這些問題的唯一途徑是加強管理，即軟件開發管理（Software Development Management）。而軟件配置管理，簡稱SCM（Software Configuration Management）是軟件開發管理的核心所在。
1.2 軟件配置管理淺析
軟件配置管理是指一套管理軟件開發和軟件維護及其中各種中間軟件產品的方法和規則，配置管理通過在特定的時刻選擇軟件配置，系統的控制對配置的修改，并在整個軟件生命周期中維護配置的完整性和可追蹤性，簡單而言就是管理軟件的變化。管理變化使得控制成為了SCM的目標，其控制內容包括：
1) 源文件版本，即版本控制――版本控制是指在某些有意義的時刻制作數據副本，以便日后必要時返回到那些時間點；
2) 配置與交付，即配置管理――與版本控制相比，蘊涵著更高層次的抽象。SCM工具必須要對一套組件的哪些版本包含了某一特定配置有所了解；
3) 過程管理，即過程管理――在整個軟件開發生命周期內對軟件資產的版本進行分組和處理。通常包括變更管理、審批級別和流程控制；
4) 問題追蹤，即將增強、變更請求或缺陷報告記錄下來，并將它們與相應的解決方案關聯起來。這將包括變更所涉及的源代碼清單。然后可以用這些代碼變更集合來創建只包含所需特性或修復補丁的再版產品。
既然軟件配置管理作為軟件開發過程的必要環節和軟件開發管理的基礎，那么就要有效地實施軟件配置管理，由于軟件配置管理過程十分繁雜，管理對象錯綜復雜，如果是采用人工的辦法不僅費時費力，還容易出錯，產生大量的廢品。因此，引入一些自動化工具是十分有裨益的，這也是做好配置管理的必要條件。
2 ClearCase的研究
2.1 ClearCase的優點
Rational 公司推出的軟件配置管理工具ClearCase特別適用于跨越復雜環境（如Unix、Windows系統）進行復雜項目開發的團隊。因其提供了相對比較全面的配置管理功能――包括版本控制、工作空間管理、建立管理和過程控制，并且在Rational 公司被IBM收購后，ClearCase有了更可靠的售后服務保障，所以使其在現階段成了使用比較廣泛的軟件配置管理工具之一。下面簡單介紹下ClearCase具有的主要功能。
2.1.1 版本控制
ClearCase的核心功能是版本控制，它是對軟件開發進程中一個文件或一個目錄發展過程進行追蹤的手段。ClearCase可對所有文件系統對象（包括文件、目錄和鏈接）進行版本控制，同時還提供了先進的版本分支和歸并功能用于支持并行開發。
支持較廣泛的文件類型：ClearCase不僅可以對軟件組件的版本進行維護和控制，也可以對一個非文本文件、目錄的版本進行維護。用戶可以定義自己的元件類型，也可以使用ClearCase中的預定義類型。
通過版本樹觀察元件發展過程：在ClearCase中，文件版本的組織體現在版本樹結構中。每個文件都可以通過checkout－edit－checkin的命令形成多個版本，還可以包含多層分支和子分支。
對目錄和子目錄進行版本控制：ClearCase允許開發者對其數據的組織發展過程進行追蹤。目錄版本對一些改變進行控制，如建立一個新文件、修改文件名、建立新的子目錄或在目錄間移動文件等。
版本對象庫中（VOB）：ClearCase把所有版本控制的數據存放在一個永久、安全的存儲區中，這個存儲區被稱為版本對象庫（Version Object Bases）。項目團隊（或管理者）可以決定它們所需要的VOB數量，可以決定什么樣的目錄或文件需要被維護。VOB不僅是一個可連接的文件系統，而且也是網上的資源，主機可以連接任意個VOB。當然，ClearCase的操作（如checkout、checkin和版本歸并）可以建立時間記錄，這些記錄被存儲在VOB數據庫中，主要描述該操作的屬性，包括“who, what, when, where & why”等等。
2.1.2 工作空間管理
空間管理，即保證開發人員擁有自己獨立的工作環境，擁有自己的私人存儲區，同時可以訪問成員間的共享信息。ClearCase給每位開發者提供了一致、靈活的可重用工作空間域，通過設定不同的視圖配置規格，幫助程序員選擇特定任務的每一個文件或目錄的適當版本，并使開發者能在資源代碼共享和私有代碼獨立的不斷變更中達到平衡。
版本間的透明訪問：通過VOB機制（包含文件或目錄的多個版本），ClearCase可以讓開發者和應用者以一種標準文件目錄樹的形式訪問VOB。
從其他主機平臺訪問視圖：在局域網中，未安裝ClearCase的機器也可使用ClearCase所控制的數據。例如，一臺ClearCase Unix主機通過一種特殊的視圖輸出VOB，網上其他主機則可通過NFS機制連接它，從而使開發人員能在未安裝ClearCase的主機平臺上讀寫視圖。但是有一點必須注意，未安裝ClearCase的主機必須重新注冊或使用安裝了ClearCase的Unix主機上的X－Windows系統進行檢入、檢出操作。
2.1.3 Build管理
使用ClearCase，構造軟件的處理過程可以和傳統的方法兼容。對ClearCase控制的數據，既可以使用自制腳本也可使用本機提供的make程序，但ClearCase的建立工具clearmake（支持Unix）和omake（支持NT）為構造提供了重要的特性：自動完成任務、保證重建的可靠性、存儲時間和支持并行的分布式結構的建立。此外，ClearCase還可以自動追蹤、建立產生永久性的資料清單。
2.1.4 過程控制
ClearCase為團隊通信、質量保證、變更管理提供了過程控制和策略控制機制，體現在以下幾方面：
1) 為對象分配屬性：例如，Codequality屬性可有A、B、 C、D或F五個值。其查詢工具允許用戶查找各種版本的文件。
2) 超級鏈接：超級鏈接可追溯到所有的元素變量、特定的版本（需求追蹤也同樣需要）、或者對象中的某一 部分。
3) 歷史記錄：ClearCase自動記錄下重要的狀態信息，當對象發生變更時，它會收集“who, when, why”、 用戶注釋、以及其他的重要數據。系統也會保留創建、釋放項目時的類似信息。
4) 定義事件觸發機制：事件預觸發機制監視每一種特定 ClearCase操作或操作類的使用。觸發可要求在執行某個操作命令之前對它進行檢查，并據此判斷是繼續執行、還是取消操作。事件后觸發機制會在某個命令執行后或給某個對象賦予屬性后，把這些動作通知給用戶。
5) 訪問控制：控制數據讀、寫、執行權限；同時，它還對文件系統之下的物理存儲施加保護，制止那些試圖逃避ClearCase破壞原始操作系統存儲的動作。
6) 查詢功能：ClearCase中有一個find命令，使得開發能獲知當前項目的狀態。
2.2 ClearCase的缺點
每款產品必有其缺點所在，這才會使得開發商有改進其的必要，社會生產才能前進。下面我就略談下ClearCase的瑕疵所在：
1) 價格不菲：若說ClearCase的最大的缺點，那就是它的價格。每個客戶端用戶許可證大約需要幾千美金，所以這也使得它在國內的應用群體有限。
2) 易用性：ClearCase的安裝、配置和使用相對較復雜，需要進行專門的培訓，才能成為一個合格的ClearCase的系統管理員。此外，ClearCase提供命令行和圖形界面的操作方式，但從ClearCase的圖形界面不能實現命令行的所有功能。
3) 變更管理：ClearCase不提供變更管理的功能，通過Rational另提供的ClearQuest工具提供對變更管理的功能。
4) 性能：服務器采用多進程機制，使用自帶多版本文件系統MVFS，對性能有較大負面影響。
5) 適用范圍：作為一款企業級、全面的開發配置管理工具，較適用于大型開發團隊。
6) 安全：沒有專用的安全性管理機制，依賴于操作系統。此外，ClearCase采用的C/S模式，需要共享服務器上的存儲目錄以供客戶端訪問，這也帶來一定安全隱患。
3 總結
無疑，通過軟件配置管理對軟件開發過程的管理，對提高軟件開發效率，保障軟件開發有序有著重要作用。該文主要研究了軟件配置管理的必要性與其核心所在，并將當前流行的軟件配置管理工具ClearCase進行了初步探究，大致歸納了其優勢與劣勢所在。當然，軟件配置管理過程中的種種問題還有待于我們去解決。
參考文獻：
[1] Wahli U,Brown J,Teinonen M,Trulsson L.軟件配置管理――IBM Rational ClearCase和ClearQuest UCM指南[M].李紀華,譯.北京:人民郵電出版社,2006.
[2] Kenefick S.軟件配置管理[M].王海濤,沈火林,譯.北京:清華大學出版社,2004.
配置管理與變更管理范文4
關鍵詞：軟件配置 軟件開發 平臺運用
中圖分類號：TP311 文獻標識碼：A 文章編號：1674-098X（2016）08（b）-0088-02
隨著軟件開發的不斷發展以及壯大，軟件平臺也得到十分廣泛的應用，傳統的軟件開發是手工開發，缺乏一定的規模性以及標準化，現代的軟件開發逐漸走向工業化以及標準化，因此，應當加強對軟件開發的研究力度，如何在軟件開發中節約成本以及提升效率是企業的目標所在。因此，軟件配置管理應運而生，CMMI管理受到軟件行業的高度重視。不但提升了軟件開發的效率，而且提升了軟件開發質量以及降低了開發成本，促使軟件開發團隊能夠更快速以及高質量完成軟件開發的任務，對于軟件開發事業發展具有十分重要的意義。
1 軟件配置管理分析
軟件配置管理具有十分重要的意義。通常而言，如果難以對軟件平臺進行管理，將直接導致很多程序軟件在同一時間進行更新。同時的更新將嚴重影響程序開發工作的效率以及質量，不僅如此，還會影響共享代碼修復工作，其次，干擾通用代碼，如果代碼擾，直接導致系統難以直接以及及時通知相關人員進行代碼更新，從而影響技術人員使用代碼，最后導致軟件版本沖突的問題。此外，大型的軟件會同時多個軟件版本，每個版本都需要大量研究人員以及工作人員，這么多人的參與容易造成一定的混亂以及版本沖突的問題。
1.1 軟件配置含義
軟件配置就是對軟件開發過程的規范性工作，軟件配置在符合相關配置管理的規定上，制定軟件以及硬件聚合體。此外，軟件配置管理的過程也是基于CMMI管理過程，可以對軟件進行操控、識別以及及時進行更新等，通過CMMI集成軟件從而為平臺提供重要的保障。
1.2 軟件配置流程
軟件配置存在自己獨特的管理流程。首先，啟動項目，對配置項以及基線時機等加以識別。其次，配置相關實施計劃，并且監理配置庫，將基礎性的軟件進行變更以及統計，記錄好配置管理數據以及跟蹤相關配置報告的形成過程，并且對配置庫中的資料進行備份。此外，軟件具有自己可以控制的版本，所謂版本控制就是軟件配置當中十分重要的一部分，其中，軟件版本控制室在保障軟件規章制度的情況之下，比如，配置項當中可以涉及版本項目，通過這種方式，不但可以有效降低丟失版本的問題，而且避免版本出現混合的狀況，從而保障產品的性能。此外，軟件配置可以控制變更狀況，可以根據市場的要求對自身進行及時的變更調節，從而有效調節自身的生存周期，并且保障軟件的產品質量。
2 設計軟件平臺的架構
CMMI軟件的平臺中，軟件配置的過程中，大多是通過統一的軟件對平臺實施監督，軟件配置當中的各種因素的使用就都是為了軟件配置，構建軟件配置平臺，應當將平臺拆分，主要拆分成為兩大部分，一部分是控制系統，另一部分是開發系統，開發部分，換句話說，就是開發以及更新系統中的應用程序，從而對系統進行拓展，控制部分是對平臺的全部軟件進行管理以及監控，從而實現平臺的有效作用，軟件研發主要是以JACA語言為前提以及根本依據，通過相關插件進行構架，其中，主要包括三個層面。第一層，持久層。主要的作用是控制數據庫的配置器以及保障數據反復訪問的過程中維持數據形成影像。第二層，研發環境層。包含比較廣泛的內容，主要包括工作流程以及構建方式，主要任務是找尋文件，并且提升軟件使用效率。第三層，展現層。主要是展現界面，將圖形界面融合到平臺的研發界面當中，從而保障研發質量以及增加研發速度，促使不同系統界面可以縮放以及展開，保障所有的應用程序可以開展相關工作。
3 平臺供應鏈管理
3.1 供應鏈管理
SCM資源管理就是供應鏈管理，其中，主要包括SCM資源政策以及達成SCM的工作目標、落實相關政策方針等，其中，SCM資源管理人員屬于軟件系統當中十分重要的一個部分，因此，在管理的過程中，應當注意國家的相關政策，在滿足系統的情況之下，才能有效審核以及編制相關軟件，最為主要的是為軟件平臺提供相關文檔資源以及模板等，不僅如此，還包括書冊以及文檔工具等，并且平臺可以提供獨有的數據庫，數據庫當中存在所有信息資料以及數據文檔等，不需要重復監理文書檔案平臺，然而，當前的SCM管理過程中，由于缺乏有效的監督機制，從而還存在一定的問題，因此，應當適當監理監督機構以及完善資源管理系統，從而提升應用軟件使用效率。
3.2 SCM代碼資源管理
根據SCM目標、組織規模以及軟件開發的特點，對代碼資源進行管理，此外，引入ClearCase插件可以促使軟件代碼集成到數據庫當中，相關技術人員可以在模塊下載到本地之后實施修改，并且修改完成之后，可以將新的系統版本傳送到開發流當中，并且實現統一管理。通過引入ClearCase系統平臺中的插件，可以管理多個軟件版本的開發過程，比如軟件構建以及跟蹤開發進度等，個別程序版本交付等也可以通過平臺實現。此外，促使相關開發人員按照小組組織工作，并且在工作中彼此分享經驗以及數據等。
4 結語
綜上所述，該文主要對軟件配置管理加以研究以及分析，探討了軟件配置的過程以及探討了開發平臺軟件配置管理的相關流程、變更控制以及版本控制的問題，對設計軟件平臺架構以及SCM資源管理進行論述，集成SCM資源軟件之后，開發過程得到有效管理以及控制。
參考文獻
[1] 裴樹軍，陳德運，陳曉雪.軟件配置管理在軟件開發平臺中的應用[J].哈爾濱理工大學學報，2010（1）：28-32.
[2] 朱寅非.淺析配置管理在軟件開發中的作用[J].南京廣播電視大學學報，2010（4）：93-96.
[3] 陳黎.配置管理在軟件開發項目中的運用[J].計算機工程，2004（S1）：87-88，193.
[4] 陳波.軟件配置管理在軟件開發平臺中的應用[J].信息通信，2014（12）：128.
配置管理與變更管理范文5
關鍵詞：服務管理；概念；模型；實施方案
1 ITSM的概念及模型
1．1 ITSM的概念
ITSM是聯系“IT服務”和“業務需求”的紐帶。ITSM的目的是建立“以企業內部IT用戶為中心”的管理機制和運作模式，以提供高質量、低成本、可計量的IT服務。ITSM與ERP、CRM和SCM等管理系統和管理方法有所不同，前者更強調的是對企業整個IT資源的管理，而后者則是對企業營銷、生產、財務、庫存等內容的業務管理。
IT服務管理以PPT(人、流程和技術)為核心要素，一般是由多個相輔相成的模塊構成的，IT管理員需要做的事情就是：監督每個模塊的進展程度，以及各個流程是否完全到位。
1．2 1TSM的標準及模型
ITIL是英國國家電腦局(CCTA)于八十年代開發的一套IT業界的服務管理標準庫，它把業界在IT管理方面最好的方法歸納起來，形成規范，旨在為企業的IT部門提供一套從計劃、研
發、實施到運維的標準方法。
ITIL是一套最佳實踐，能夠協助企業實踐ITSM的相關流程，它可以在總體上幫助企業完善管理。ITIL是一個框架，它主要由兩個部分組成：
(1)服務運營(Service Support)
按ITIL方法論，服務運營一般包括五個方面的管理流程。例如：突發事件管理、變更管理、配置管理、應用管理以及服務臺的管理功能。
(2)服務戰術(Servlce Delivery)
按ITIL方法論，服務戰術一般包括五個方面的管理流程。例如：服務級別管理(SLM)、可用性管理、，IT服務連續性管理、能力管理和IT服務財務管理。
服務戰術和服務運營兩個模塊構成了ITSM的核心組成部分。服務戰術模塊的功能與年度計劃周期(annual planning cycle)緊密相關，而服務運營與每天的運作息息相關。
2 供電企業ITSM的典型實施方案
2．1背景
清遠供電局的IT服務管理與省內兄弟單位相比起步慢、水平較低，在IT運行維護管理流程的制定及執行方面有很多需要改進的地方，在IT事件管理、問題管理、變更管理及配置管理方面存在著一定的問題和隱患，因此需要建立一套規范的IT服務管理系統來規范人員的操作行為和改進工作流程，消除隱患，提高IT服務質量。
目前清遠供電局的IT事件管理流程是由服務臺、現場支持和三線支持人員共同組成，該系統面向清遠供電局所有IT用戶。用戶通過服務臺提交IT事件，服務臺對事件進行記錄、分類處理，如果需要現場支持就分派到相應二線支持人員。當前有支持管理平臺，但事件監控和跟蹤的力度不夠，也沒有明確事件的監控人員，流程也沒有形成閉環。管理信息化有相關的資產管理表格和數據庫，但僅僅是簡單的記錄相關信息，沒有記錄IT設備之間的關系，不能把事件和IT設備聯系起來，也沒有管理流程來確保配置信息的準確性和完整性。
2．2項目目標
本項目擬分為近期，中期及遠期三期目標。
2．2．1近期目標
①改進事件管理：建立規范統一的服務臺，采用集中管理，分散支持的方式，并成為信息部門和用戶部門間的唯一接口。定義規范的事件管理和配置管理流程和兩者之間的接口，設定完善的流程衡量標隹和考核體系。設定清晰的事件升級機制，包括管理升級和技術升級。定義嚴格的事件優先級并和所需要的解決時限關聯起來。在流程中定義清晰的人員角色和職責，制定與事件管理流程兼容的重大／緊急事件處理流程。
制定嚴格的流程政策和流程執行控制機制，指定流程負責人，實現對流程的控制和改進。建立嚴格的事件監控和跟蹤機制。設定完善的知識管理體系，包括管理流程。建立完善的圖表功能，以利于更有效的體現管理現狀，并提供決策支持。
②建立和完善配置管理：建立配置元素的相應屬性、狀態等，以利于提供信息并產生相應的管理報表。建立配置管理的相關流程，如新元素登錄，信息更新，審計等。定義清晰的配置管理流程的人員角色和職責。把配置信息通過配置管理工具和關系性數據庫進行電子化管理，以提高管理效率和效能。建立配置管理和事件管理的接口，包括流程接口和工具間的接口。
2．2．2中期目標
①建立問題管理和變更管理流程，實現IT服務的主動管理。問題管理的目標是使突發事件和問題對業務所造成的影響減少到最小，避免相關錯誤的重復發生，提高IT服務質量。變更管理的目標是使IT服務和業務更好的整合，改善變更的風險，減少由于變更所造成的對IT服務和服務級別協議的負面影響。
②建立完善的IT服務級別管理流程(SLM)，包括建立關鍵業務級別協議(SLA)，并有相應的服務流程去監視實際服務水平，定期回顧服務狀況，找出與服務級別的差距或可改進的領域，從而制定服務改進計劃(SIP)，并進行相應跟蹤。
2．2．3遠期目標
①建立可用性管理，實現lT服務的可用性管理流程。
②IT能力管理，實現IT能力的管理流程。
③建立IT財務管理。
本項目的建設是基于惠普的ITSM(IT服務管理)參考模型?；萜誌TSM參考模型是基于ITlL(，TInfrastructure Libraw ST基礎架構標準庫)之上建立的。在ITIL強調的IT管理與運維的基礎之上，惠普公司根據自己的實踐經驗加入了業務間戰略整合的流程組，從而建立了完善的惠普ITSM參考模型。此參考模型的重點是企業分布式IT環境的服務管理，因為服務管理的實施完全依賴于所需IT流程的執行，所以該模型是一個完全集成的流程模型。
2．3 供電企業ITSM方案的實施
本項目已完成了近期目標，目前處于試運行階段。中期目標正在執行中。下面對近期目標中的事件管理流程及配置管理流程作簡要介紹。
2．3．1 事件管理
事件管理是負責解決IT服務的突發事件、問題和客戶請求等的運維流程。它的目的是盡快恢復被中斷或受到影響的IT服務，所以它的特點往往是以解決表征現象為目的，而不在于查找根本原因。
事件管理模塊的主要功能是盡快解決業務環境中出現的事件，保持IT服務的穩定性，在成本允許的范圍內盡快恢復服務，快速響應服務請求(電話，OAK)，確認事件的解決和客戶滿意度；進行事件控制，按規范記錄事件，就事件的優先級、緊急性和嚴重性進行分類；監視并結束事件，同時還提供一個日常工作接口及IT管理信息。事件管理對 IT服務產生積極作用，具體表現在：
提高了服務可用性。通過保證事件、問題和請求等的快速處理來達到服務可用性的最大化。
提高客戶滿意度。事件管理流程通過記錄和管理事件的集成系統來提供有效服務以及一個集中的知識庫。同時，也提供了信息部和使用者的溝通渠道，加強了信息部和用戶之間的雙向認同。
2．3．2 配置管理
配置管理是描述、跟蹤、控制和匯報所有IT基礎架構中所有設備或系統的管理流程。這些設備和系統被稱為配置元素(Configuratlon Item)。通過該管理流程實現對所有CI的有效管理、跟蹤和控制以支持清遠供電局的IT服務和基礎設施成功運行。配置管理流程所管理的配置元素包括硬件、軟件和網絡設備、服務合同、客戶端等IT基礎架構中所有必須控制的組成部份。所有的數據保存在配置管理數據庫(Configguratlon ManagementDataBase)中。
配置管理在多方面對企業的IT服務產生積極作用，具體表現在：
提高了環境穩定性。根據及時正確的CI信息進行決策可以避免不可預期的宕機；對CMDB數據變更的適當授權加強了安全性，降低了無控制環境變更的危險性。
提高了服務質量。有利于存放和抓取已記錄下來的客戶期望，從而方便比較和改進實際的服務實施。
降低了運營成本。更快、更簡化和更徹底的識別設備的屬性和關系，從而方便定位組成元素，在使用時減少錯誤，因此也減少了重復工作。
提高了靈活性。抓取的數據可以按任何合理的方式進行分類，匯總和組成報表，從而方便在這些數據上的后續工作。
配置管理與變更管理范文6
一、電子、機械及軟件一體化設計主要的出錯方式認知
隨著科學技術與行業整合，產品研發日趨復雜。在進行電子設計、機械設計與軟件工程設計時，三者之間缺乏有效溝通與過程管理，導致電子、機械及軟件無法有效集成，難以實現一體化設計。當前，機電一體化設計存在的主要出錯方式表現為：第一，MCAD變更與電子工程師缺乏有效傳遞。MCAD用戶進行IDF格式將變更信息存儲于原始版中，但其無法傳遞給電子工程師。同樣，電子工程師依據電路圖實現設計，受ECAD規劃失效影響，需要進行返工操作從而延遲交付及制作時間;第二，ECAD變更與機械設計師之間缺乏有效傳遞。CEAD設計人員進行PCB構件調整，以優化布局，如其沒有及時將變更信息傳遞給機械設計師，則會出現PCB組件與PCB線路接口故障問題，推遲交付時間并增加其成本;第三，配置管理中斷。如在研發中其設計科目均有著自身獨立的數據調試模型，則會提高設計效率然而軟件設計師多獨立作業，缺乏有效溝通導致配置管理中斷;第四，錯誤軟件版本，雖然在產品中采取錯誤軟件版本較為容易避免，但一旦出現其問題，則會造成較多問題;第五，軟件研發孤立性。在產品研發中其變更管理多將軟件研發排除在外，軟件缺陷及變更命令符難以協調，為軟件修復與產品交付帶來問題。
二、電子、機械及軟件一體化設計思路探究
(一)軟件變更實例分析
制造商需向客戶交付機器人技術裝配客制化版本，產品標明最新軟件編號并準備交付時出現軟件現場變更問題，則會產生交付延遲等問題。制造商則面臨著如何找出與設備上安裝軟件版本一致信息，采取什么軟件工具進行重建軟件，設備配置存放區域設計，技術工程師如何知道其采取的實際版本信息，公司需采取最新軟件并在期限時間內完成設計，避免出現交付延遲與質量問題。
(二)電子、機械一體化設計方案
采取PTC的Inter Comm Expert及Inter Comm EDAcompare可以實現MCAD及ECAD同步問題研究，通過PTC，實現電子設計師與機械設計師相互變更信息的有效捕捉，在獲取變更信息的基礎上進行相關設計文檔同步修改，從而解決電子設計與機械設計不同步問題。電子機械一體化設計方案如下：
2.2.1 變更識別
Inter Comm EDAcompare屬于PTC電子設計標準變更識別解決方案，可以進行PCB設計變更識別，其識別實現方法為：進行不同版本圖解對比，PCB布局及制造工藝對比以實現變更識別，以幾何及屬性變化實現識變更識別，依據差異識別，當Inter Comm Exper選中變更后則會將設計影響區域進行標定。
2.2.2 電子機械一體化設計
順利實現機械設計與電子設計集成，需要自動生成設計變更并及時告知。在變更識別基礎上，電子與機械一體化設計可行性條件基本滿足。如機械工程師可以進行電子設計文檔查看與識別其與上版本差異。應用PTC方案可以進行智能化ECAD設計演示，向授權用戶進行差異展示。機械設計團隊可對電子設計數據信息進行有效查詢，無需進行新型IDF文檔下載，且應用其解決方案可以進行不同版本差異自動對比，如吉和變更、信號改道發送等。該方案成本較低，技術優勢與過程管理優勢突出，能夠切實提高電子設計與機械設計協調度，為實現電子機械一體化設計提供技術支撐。
(三)集成軟件一體化設計分析
實現軟件與電子設計及機械設計同步是實現一體化設計的重要基礎。然而將軟件設計與產品研發相整合存在著較大困難。因軟件研發多為外包方式且由相對孤立組織來完成。如電氣工程師完成相關設計后，項目降級將產品及軟件最新版本交付制造部門，在進行基礎版創建后載入軟件，軟件運行無效，經研究可能其軟件版本并非最新。在軟件研發過程中，應用PDS系統，軟件設計師可實現軟件版本及其他設備動態鏈接操作，可將團隊作嘔為整個產品研發的部分。PDS系統為機械、電子及軟件設計退工了可視化同一系統，且支持軟件組件重組，能夠實現全球配置管理，推動不同軟件研究團隊之間的協調性，確保產品研發進度與研發質量。
(四)電子、機械及軟件一體化設計方案
采取PDS系統，可以實現跨軟件研發，協調軟件團隊協作，其解決方案為：工程師將軟件配置管理系統中存在的軟件與PDS軟件部分進行正確連接;進行原型制造產品，測試產品;如測試團隊發現產品關鍵特性缺失作用，考慮到用戶及軟件產品接口是由軟件及硬件綜合控制，無法實現錯誤判斷;測試工程師則應用PDS系統，進行問題報告創建，直接將受影響硬件及軟件構建聯系;變更調查任務發送給軟件團隊與硬件團隊，并將PDS發送于電子信箱;缺陷跟蹤系統進行錯誤報告自動生成，對PDS變更調查作交叉引用，將錯誤報告發配給相應軟件設計人員進行調查;錯誤報告與缺陷跟蹤系統具體軟件版本之間存在鏈接，且錯誤報告與PDS配置管理受影響軟件之間存在鏈接;在缺陷跟蹤系統中執行現行軟件更新，以software QA實現軟件測試;新版本與PDS管理部件鏈接，依據PDS分配實際任務執行產品測試，完成測試后企業變更請求則于PDS中實現完結，針對不同系統中存在的變更狀況執行錯誤報告分析，從而提高了電子、機械及軟件一體化設計效率。
三、結語
隨著產品研發與產業整合進一步推進，如何實現電子、機械及軟件一體化設計成為了時展所面臨的重要問題。缺乏設計同步性與溝通有效性是實現一體化設計的重要舉措，然而缺乏有效的技術手段，實現電子團隊、機械團隊與軟件團隊之間的有效溝通，應用PDS系統與軟件配置管理系統，為實現電子、機械及軟件一體化設計提供溝通辦法。實踐證明，強化電子、機械及軟件一體化設計，能夠有效提高產品研發進度，實現其綜合效益。
