隨計算機科學與技術的飛速發(fā)展，應用領域的不斷擴大，硬件系統(tǒng)與功能軟件實現(xiàn)的比例不斷增加， 軟件不再只是計算機硬件的附屬品， 而已經(jīng)成為系統(tǒng)的獨立甚至是主宰系統(tǒng)的關鍵部分。開展軟件工程化管理與過程改進成為軟件管理的重中之重。 1.1 軟件開發(fā)面臨的問題軟件的重要程度已經(jīng)越來越被得到認可和重視。提高軟件的生產(chǎn)率和質量便成為軟件所面臨的最大挑戰(zhàn)。同時，我國國防科技工業(yè)領域，軟件研制與開發(fā)仍基本處于初級階段，其質量控制還缺乏有效的組織、手段和相應的規(guī)范。軟件面臨問題的主要表現(xiàn)為質量形式嚴峻、軟件開發(fā)與交付的進度難以保證，軟件開發(fā)的經(jīng)費難以控制。 1.2 解決軟件問題的出路軟件作為一種邏輯實體，具有抽象性、嚴密性、一次性、智力性、持久性、倚賴性、復雜性、難以度量、易出錯、必須維護和成本昂貴等顯著特點。為解決以上問題，自 1968 年在 NATO 會議上提出軟件工程以來， 人們一直在尋求更先進的軟件開發(fā)技術和方法。但在隨后的 30 余年實踐中，通過追求新開發(fā)技術和方法改進解決軟件開發(fā)面臨的巨大問題，但結果卻無法令人滿意。人們逐步認識到， 改進軟件過程的管理才是解決軟件開發(fā)面臨眾多問題的出路。 1986 年 11 月，卡內(nèi)基-梅隆大學的軟件工程研究所應美國聯(lián)邦政府的要求，在 Mitre 公司的協(xié)助下，分別于 1987 年 6 月和 9 月開發(fā)出了軟件能力成熟度框架和軟件成熟度提問單， 用于評估軟件供應商的能力。通過 4 年的應用實踐，軟件工程研究所于 1991 年推出了軟件能力成熟度模型 CMM1.0 版。后與 1993 年又推出了該模型的 CMM1.1 版。其后由于開展集成能力成熟度模型 CMMI 工作， 就停止了軟件能力成熟度模型 CMM2.0 版本的進一步工作。 1.3 CMMI 模型對配置管理的定位 2000 年 6 月，國務院下發(fā)了《鼓勵軟件產(chǎn)業(yè)和集成電路產(chǎn)業(yè)發(fā)展的若干政策》（國發(fā)［2000］18 號）文件，其中明確指出國家鼓勵軟件出口型按 CMM 改進軟件過程。近年來，隨著《軍用軟件質量管理規(guī)定》和 GJB5000-2003《軍用軟件能力成熟度模型》的貫徹和實施，軍內(nèi)外各界對過程改進的認識得到了很大的提高。同時，總裝于 2006 年啟動了 GJB5000-2003 的修訂工作， 并 于 2008 年 發(fā) 布 了 以 CMMI -DEV1.2 版 為 基 礎 制 訂 的 GJB5000A-2008《軍用軟件研制能力成熟度模型》。在 GJB5000A-2008《軍用軟件研制能力成熟度模型》中，將所有級別包括的 22 個過程域劃分為四類：支持類、項目管理類、工程類與過程管理類。配置管理作為支持類過程域中最基礎也是最重要的一個過程域確立。同時，配置管理可作為組織收納管理其他各個過程域產(chǎn)生的過程資料和過程產(chǎn)品的平臺， 作為開展全面過程改進工作的支持平臺和組織資產(chǎn)庫， 地位尤為重要和突出。