第一篇：規范軟件開發過程——軟件配置管理實踐

規范軟件開發過程——軟件配置管理實踐

2010-05-19 來源：網絡

隨著軟件系統的規模、復雜度日益上升，軟件開發過程管理已經成為保證軟件系統開發效率、質量、成本的關鍵性因素。作為軟件開發過程中質量保障的重要組成部分，行之有效的軟件配置管理（以下簡稱SCM，Software Configuration Management）能夠顯著提高軟件開發組織的自身能力、提高軟件開發過程的完整性，以及降低軟件開發的風險。

軟件配置管理的概念

ISO 9000、CMM、ISO/IEC 12207、IEEE 729-1983對SCM的定義有不同的描述。ISO9000定義SCM為“一個管理學科，它對配置項的開發和支持生命周期給予技術上和管理上的指導。配置管理取決于項目的規模、復雜程度和風險大小”。

CMM2將SCM定義為一個關鍵過程域KPA，是“貫穿于整個軟件過程中的保護性活動，它被設計來（1）標識變化，（2）控制變化，（3）保證變化被適當的發現（4）向其他可能有興趣的人員報告變化。”。SCM包括了配置項識別、工作空間管理、版本控制、變更控制、狀態報告、配置審計等活動，其中以版本控制最為核心和關鍵。

數據集中工程軟件配置管理策略

1、數據集中工程項目背景

中國建設銀行數據集中工程的目標是通過建立總行級的數據中心，向全行38個一級分行、20000多個網點提供完整的核心金融服務。其核心應用系統DCC-CCBS包括主機、前置、前端三大部分。主機應用部分部署在總行級數據中心，前置應用部分部署在數據中心前置通信網關、各一級分行業務大前置，前端部分部署在網點。

DCC-CCBS項目的SCM需要實現開發、發布、部署的全過程軟件配置管理。開發過程SCM的核心是系統源碼版本管理；發布過程的SCM核心是系統目標碼版本管理；部署過程以確保系統目標碼版本在數據中心、一級分行、網點和外系統的正確部署為首要目標。

2、開發過程軟件配置管理

系統源碼版本除系統源程序、參數外，還包括需求規格說明書、系統總體架構設計說明書、主機/前置/前端系統結構設計說明書、各子系統的詳細設計說明書、各子系統的對外接口規范、業務操作手冊、系統使用手冊、系統安裝維護手冊等文檔。根據配置項的不同屬性，經過評審，形成需求基線、設計基線和源代碼基線等不同的基線。開發過程SCM按照子系統的性質，分為主機、前置、前端三部分獨立管理。

DCC-CCBS項目總體組負責整個需求和變更的控制。通過審批的需求按照功能分布分解為主機、前置、前端的子需求，再由各部門分別管理和實現。環境及版本控制小組負責向各部門提出形成“系統基線”的要求，以同步主機、前置、前端的源碼版本。

3、發布過程軟件配置管理

發布過程的系統目標碼版本包括系統目標碼（執行碼）、系統參數及相關文檔等。按照用途，系統目標碼版本可分為測試版和正式版。以前置平臺為例，發布過程SCM的主要活動包括：構建環境管理，保證編譯環境的純凈性和正確性；

構建過程管理，保證構建過程的自動化操作，及其正確性和完整性；

版本編號管理，統一版本命名規則，確保目標碼版本號的唯一性和可追蹤性；

目標碼版本生成管理，從各版本管理工具系統收集、整理、打包相應的目標碼、參數和文檔，形成完整的或部分（補丁）的目標碼版本；

配置狀態檢查，檢查目標碼版本包中內容的正確性、完整性和一致性；

4、部署過程軟件配置管理

部署過程SCM的主要任務是：建立安全、可靠和迅速的傳輸流程和傳輸渠道；建立目標碼版本記錄和追蹤機制、版本運行時刻檢查機制和版本恢復機制；確保正確的版本、按照正確的渠道、在規定時間遞交到正確的用戶并生效。

在DCC-CCBS生產環境中，軟件開發中心將通過數據中心版本管理系統發布各單位所需的目標碼版本，各單位在版本管理系統和數據傳輸通道的支持下，實現版本/補丁的主動分發、查詢、下載和生效。

軟件配置管理實施經驗

1、樹立正確的企業配置管理意識

SCM是一門管理學科。歸根結底，其關鍵是“管理”，然后才是“軟件配置”。項目級SCM能否成功實施，與企業的軟件配置管理目標、策略、能力、組織和資源息息相關。

2、提高全員的配置管理素質

SCM是規則和流程的集合，需要依靠流程中所有部門和人員共同的支持和努力。任何環節上的疏忽和懈怠，都將直影響SCM的實施效果。

3、采用合適的工具

功能強大的或昂貴的工具未必是合適的工具。往往20%的功能即可解決80％的配置管理問題。目前比較流行的版本管理工具包括CVS、PVCS、ClearCase、Harvest、VSS、Endeavor等。在選擇具體工具時，往往需要考慮以下因素：（1）工具將要使用的范圍；（2）工具自身的功能、穩定性、擴展行，以及對環境的要求；（3）工具使用的復雜度；（4）工具與其他流程和工具的集成度和交互性；（5）工具的投資和維護費用。

4、及時的檢查和梳理

大系統開發過程中，配置管理往往采用分步離散管理方式，因此保證整個系統配置管理的完整性成為一件精密細致的工作，需要投入大量人力及時修訂基線，防微杜漸，避免混亂，以滿足對配置管理正確性、完整性和及時性的要求。

5、系統化思考、分步實施、持續改進

SCM不是一項孤立的管理活動。企業的戰略目標、管理能力、文化背景、組織結構，項目的規模、性質、技術、人員等都是影響SCM決策的重要因素。因此需要在項目乃至企業的整體環境中系統的考慮SCM的實施策略和方法。

通過分階段實施量化的、漸進的配置管理目標，可以避免由于引入復雜管理流程所造成的混亂，有利于方便靈活地優化配置管理流程。同時，階段性目標的實現將有助于整個團隊提高士氣、增強信心，并逐步提高開發隊伍的配置管理素質。

第二篇：軟件配置管理最佳實踐

軟件配置管理最佳實踐

PMTeam雜志 Li Ben 編

現在大家都已經認識到了有效的軟件配置管理工作對于提高團隊開發效率、保障軟件產品質量的重要意義，很多朋友也開始了在配置管理實施方面的一些研究，市場上我們也可以看到一些軟件配置管理工具廠商針對具體配置管理工具提供的實施服務；但是，實施軟件配置管理到底應該做哪些東西？團隊的配置管理現狀怎么評估？在哪些方面還可以進行改進？我們相信，這些問題可能正困擾著大多數研發主管和項目經理。

國外軟件產業界在軟件配置管理這個專題上已經進行了多年的理論和實踐上的研究。在多年經驗積累的基礎上，產業界總結出來一系列“最佳實踐”（Best Practices），我們可以使用這些“最佳實踐”來作為評估一個組織軟件配置管理能力的標尺，也可以作為我們實施軟件配置管理的指南。這些“最佳實踐”包括：

1、標識需要進行存儲的工件（Artifact）并保障安全存儲；

2、控制并且審計（Audit）對于工件的修改；

3、設立并管理基線（Baseline）；

4、記錄并跟蹤變更請求；

5、維護穩定、一致的工作空間；

6、支持對于工件和控件的并發修改；

7、盡早集成、持續集成；

8、保證軟件構建的重現能力；

9、以控件（Component）為單位實施版本控制；

10、使用“活動”（Activity）來組織和整合版本集。

下文將介紹前5條最佳實踐。

1、標識需要進行存儲的工件（Artifact）并保障安全存儲

在軟件開發過程中，我們會得到各種各樣的產出，比如各種文檔、模型、源代碼以及測試腳本等，我們把這些大家勞動的成果統稱為工件（Artifact）。對于一個軟件開發組織來說，這些工件就構成了組織的核心資產。對于如現金、有價證券之類的資產，我們都會準備一個保險箱，好好地保存；對于軟件資產，我們也需要相似的措施。所以，軟件配置管理工作的第一步就是建立一個安全、可靠的存儲庫（Repository），用于保存組織的核心軟件資產。這個庫對于開發團隊來說，就像是財務室里的保險箱。因此，容錯能力和高可靠性是這個庫最重要的屬性。除此之外，隨著

組織的增長，置于庫中的數據會越來越多，為保證運行效率，庫的可擴展性也是非常重要的一個屬性。

對于存儲庫來說，良好規劃的備份和災難恢復過程是必不可少的。令人驚訝的是，很多軟件組織在這方面都沒有給予必要的重視，因而也給組織的發展留下了嚴重的隱患，一旦災難發生，后果不堪設想。

在建立好存儲庫以后，需要做的工作就是確定將哪些工件置于庫中。根據實際需要，組織可能會決定只將正式文檔、模型文件、源代碼、發布版本等文件放入庫中，而對于臨時文檔、編譯時產生的中間文件等，則不將它們放入庫中。我們把放入庫中的文件稱之為配置項（Configuration Item）。

2、控制并且審計（Audit）對于工件的修改

在標識相關的工件并將它們置于存儲庫中以后，我們需要建立對于這些工件的修改控制機制以及審計機制。

庫里的工件不是誰想修改就可以修改的。控制機制必須保證只有拿到授權的人員才能對相關工件進行修改，而審計機制則保證修改的動作被完整地記錄，也就是說，誰修改了這個工件，什么時候做的修改，為什么原因做出這個改動，以及修改了哪些地方（Who、When、Why、What）。審計機制通常通過“檢出/檢入”（Check out/Check in）模式得到實現。在這種模式下，工件一旦入庫，讀寫權限就變成只讀（read only），如果要對該工件進行修改，則需要通過“檢出”這個步驟；在修改結束以后，如果希望將修改的成果入庫，則需要通過“檢入”這個步驟。在經過一次“檢出/檢入”步驟以后，會形成該工件新的版本，因此也有人把上邊的過程稱之為“版本控制”（Version Control）。在版本控制過程中，如果利用一些配置管理工具（或者版本控制工具）的支持，則可以自動地記錄審計工作所需的四個“W”（Who、When、Why、What）。

3、設立并管理基線

通過審計機制我們可以保存一個工件完整的變更歷史；但是一個項目通常是由成百上千個工件構成的，每個工件在變更過程中都會形成一系列的版本，如何確認系統在某個時刻分別由哪些工件的哪些版本構成？這就需要引入一個概念：配置（Configuration）。對于軟件系統來說，在開發過程中某個時刻存儲庫中所有工件的一個“快照”（snapshot），就形成一個“配置”。對于一些重要時刻的系統配置，我們可以使用基線（Baseline）來進行標志。

IEEE對于基線的定義是：已經通過正式復審和批準的某規約或產品，它因此可以作為進一步開發的基礎，并且只能通過正式的變更控制過程進行改變

簡單地說，基線就是項目儲存庫中每個工件版本在特定時期的一個“快照”。它提供一個正式標準，隨后的工作基于這個標準進行，并且只有經過授權后才能變更這個標準。建立一個初始基線后，以后每次對它進行的變更都將記錄為一個差值，直到建成下一個基線。

建立基線的主要原因是：重現能力、可追蹤性和報告能力。

重現能力是指返回并重新生成軟件系統給定發布版本的能力。可追蹤性建立項目各種類型工件（需求、設計、實現、測試等）之間的橫行依賴關系，其目的在于確保設計滿足需求、代碼實施

設計以及使用正確代碼編譯生成可執行文件。報告能力來源于一個基線內容同另一個基線內容的比較，基線比較有助于程序調試并生成發布說明（Release notes）。

建立基線有以下幾個好處：

(1)基線為開發工件提供了一個定點和快照。新項目可以從基線提供的定點之中建立。

(2)當認為更新不穩定或不可信時，基線為團隊提供一種取消變更的方法。

(3)可以利用基線重新建立基于某個特定發布版本的配置，這樣也可以重現被報告的錯誤。在開發過程中，需要定期建立基線以確保團隊開發人員的工作保持同步，通常，在項目生命周期中的里程碑處定期建立基線。

4、記錄并跟蹤變更請求

以上我們談論的都是對于工件的變更活動的實施，下面我們要談到的是軟件配置管理的另一個方面：對于變更請求的管理。這是變更活動的源頭。

著名的軟件大師Brooks曾經談到導致軟件開發困難的一個原因就是軟件的可變性。大家都知道，各種要素，如市場的變化、技術的進步、客戶對于項目認識的深入等等，都可能導致軟件開發過程中的變更請求的提出，而且承認這種變更請求的合理性也已經是工業界的共識。

但是，如果缺乏對于變更請求的有效的管理能力，紛至沓來的變更就會成為開發團隊的噩夢。缺乏有效的變更請求管理會導致以下一些問題：

（1）軟件產品質量低下，對一些缺陷的修正被遺漏；

（2）項目經理不了解開發人員的工作進展，缺乏對項目現狀進行客觀評估的能力；

（3）開發人員不了解手頭工作的優先級別，可能出現將緊急的事情放在一邊、而工作在一般優先級任務上的情況。

變更請求管理的復雜程度與變更的具體類型有關。簡單地說，變更請求管理會涉及到變更請求的提交、變更請求的復審、變更任務分配、變更結果的驗證等一系列活動。通常，變更請求管理的流程是：由請求者提交變更請求，變更控制委員會（Change Control Board，CCB）召開CCB復審會議對變更請求進行復審，以確定該請求是否為有效請求。如果是，則基于項目團隊所確定的優先級、時間表、資源、變更難度、風險、嚴重性以及其他相關標準，判定對該變更的修改程序，并分配實施變更任務的人力資源和時間資源；變更任務實施人員負責實施該變更；實施結束以后提交驗證人員，由驗證人員負責對變更結果進行驗證，如果變更成功則通知相關人員，否則由變更實施人員返工。

典型的變更請求管理如需求變更管理、缺陷追蹤等。實施有效的變更請求管理有以下好處：

（1）提高軟件產品質量；

（2）提高開發團隊溝通效率；

（3）幫助項目管理人員對產品狀態進行客觀的評估。

關于變更請求管理的詳細過程以及相關準則PMT將在相關報告中闡述。

5、維護穩定、一致的工作空間

在我們把相關工件納入集中的存儲庫、大家也都遵照“檢出/檢入”的工作模式對工件進行修改以后，下一步的工作就是要為每位開發人員設定“私有”的工作區，或者叫做工作空間。

工作空間通常以特定的基線為基礎創建，要求能夠做到為指定的任務方便地取出正確的工作版本建立私有工作空間；開發人員根據項目要求在自己的私有空間中對工件進行修改和測試活動，而與其他開發人員相對保持隔離，也就是說，自己的修改活動不會受到他人的影響，也不會影響到其他開發人員。但是，在保持隔離的同時，又應該提供相應的機制，當開發人員希望共享工作成果的時候，能夠很方便地實現共享。

開發人員日常的開發工作都是在工作空間里進行的，因此，穩定性應該是工作空間首要的特性，只有高度穩定的工作空間才能保證開發人員的工作效率。

第三篇：軟件開發過程規范（模版）

軟件開發過程規范

1目的為了規范軟件研發各個階段的開發行為，特制定此規范。

2適用范圍

本規范適用于研發中心軟件產品研發從立項，到開發實施、測試、結項的各個階段，規定了各開發階段的文檔編制、代碼編寫和資料備份內容與要求。3術語和縮寫

研發項目干系人：公司內部與研發項目有關聯的任何人。

項目計劃周期：從項目立項到計劃完成時間的實際工作日數。

項目實際周期：從項目立項到實際完成時間的實際工作日數。

項目質量目標：項目允許出現的總的缺陷數的加權平均值。

項目實際質量：項目實際出現的總的缺陷數的加權平均值。

軟件缺陷：在測試過程中被發現的軟件bug，按照不同的嚴重程度分為四級；一級，系統崩潰，無法自動恢復，加權系數為100。

二級，系統功能無法實現或性能指標無法達到，但不影響其他功能的使用，加權系數為2。

三級，系統功能實現不完整，加權系數為1。

四級，不影響系統功能和性能的小錯誤，忽略此錯誤系統可正常運行，加權系數為0.5。

加權缺陷數量：測試中出現的各種缺陷的數量乘以其對應的加權系數，求和。4內容和要求

4.1研發立項

4.1.1立項申請，產品研發經過申請后才能立項，立項申請人可以是公司員工，也可以是公司各職能部門。

4.1.2立項申請人或委托其部門負責人召集相關人員討論通過，確定項目經理并初步確定項目組成員。

4.1.2.1《研發立項申請書》由項目經理負責編制。

4.1.2.2項目編號規則為，軟件項目：PS+編制日期；（硬件項目：PH+編制日期）。如：PS20070902。

4.1.2.3《研發立項申請書》要規定開發的產品的具體名稱，以及所屬各個系列的規格型號定義。

4.1.2.4《研發立項申請書》規定開發的產品的屬性，包括功能詳細描述，性能要求詳細描述和穩定性要求詳細描述。

4.1.2.5《研發立項申請書》明確項目經理和項目組成員。

4.1.2.6《研發立項申請書》明確項目的開始日期和計劃完成日期。

4.1.2.7《研發立項申請書》概要說明項目開發的資源需求，包括硬件設備、軟件工具、場地環境等。

4.1.2.8《研發立項申請書》確定項目的質量目標，包括各級缺陷的數量和測試周期，所制定的質量目標不允許有一級缺陷。

4.1.2.9《研發立項申請書》的編制格式參照《研發立項申請書模板》。

4.1.3《研發立項申請書》由研發項目經理、主管軟件的研發經理、營銷中心經理認可，主管研發副總經理最終確認。

4.1.4內容變更：研發項目干系人可對申請對《研發立項申請書》的內容進行變更，變更后按申請的流程進行簽字確認，變更后的內容重新填寫《研發立項申請書》并附在原申請書后。項目組成員的變更由研發內部掌握，不必進行變更申請。變更可在結項前的任何階段提出。

4.1.5項目撤銷，如遇重大變故造成所研發的項目已經無實際意義或其他原因需要立即停止，可申請撤銷，申請人需是項目干系人，并具有中心經理以上的級別，申請人負責編寫《研發項目撤銷申請書》,說明撤銷原因，撤銷申請需得到項目經理、主管軟件的研發經理、營銷中心經理和主管研發副中經理認可，經由總經理批準后生效。撤銷申請可在結項前的任何階段提出。

4.2研發

4.2.1研發立項確定后，項目經理需編寫《項目研發計劃書》。

4.2.1.1《項目研發計劃書》初步制定項目開發的任務列表和模塊劃分，以及項目組人員的模塊歸屬和工作時間安排。

4.2.1.2《項目研發計劃書》可以用通用的項目管理工具來完成，編制格式由項目經理確定，推薦使用Microsoft Project。

4.2.1.3《項目研發計劃書》由項目組成員認可。

4.2.1.5項目經理可根據實際情況和設計的深入，隨時變更《項目研發計劃書》。

4.2.1.6主管軟件的研發經理可抽查《項目研發計劃書》的編制和實施情況，并給出改進建議。

4.2.2研發設計

4.2.2.1《軟件需求分析說明書》

4.2.2.1.1軟件項目需編制《軟件需求分析說明書》。

4.2.2.1.2《軟件需求分析說明書》由項目經理或其委托人編制。

4.2.2.1.3《軟件需求分析說明書》確定整個系統的物理結構和部署要求，并根據系統的物理結構進行模塊劃分，確定各個模塊的功能范圍和模塊間的接口方式。詳細說明系統規模要求和運行環境限制，并指出系統運行所需資源的要求。明確開發和系統運行所需軟硬件資源的要求。確定項目進行一次全面測試所需要的測試人員人數和測試周期。《軟件項目需求分析說明書》的格式參照《軟件項目需求分析說明書模板》。在軟件需求分析過程中，如果軟件有用戶界面，要在此階段進行界面的初步設計，為了提高效率，界面草圖的繪制不限定形式和格式。

4.2.2.1.4《軟件需求分析說明書》由項目組全體成員認可，主管軟件的研發經理最終確認。

4.2.2.1.5《軟件需求分析說明書》的變更，在開發過程中，項目組成員可提出對《軟件需求分析說明書》的變更申請，變更的范圍限于不能違背《研發立項申請書》的要求，即不能有涉及到《研發立項申請書》變更的內容，如果有，需要做《研發立項申請書》變更的流程。《軟件需求分析說明書》變更的主要目的是修正其中的錯誤，或者經過變更可提高產品的品質或性能指標或縮短產品的研發周期。《軟件需求分析說明書》的變更需得到項目經理的同意，必要時由項目經理召集相關技術人員和項目組成員召開簡短的技術會議進行論證。項目經理將變

更后的內容形成新版本的《軟件項目需求分析說明書》，由主管軟件的研發經理最終確認。

4.2.2.2《軟件概要設計說明書》

4.2.2.2.1軟件項目需編制《軟件概要設計說明書》。

4.2.2.2.2《軟件概要設計說明書》由項目經理或其委托人編制。

4.2.2.2.3《軟件概要設計說明書》確定整個系統的邏輯結構，并對需求分析中各物理模塊進行邏輯模塊劃分，詳細描述各邏輯模塊的業務規則和模塊之間的接口以及重要的內部接口，確定系統級的全局變量和數據結構，確定各邏輯模塊所包含的程序文件名稱和使用的開發工具，描述每個文件中所包含的函數功能。確定數據庫的類型和所有數據表名稱及數據表的用途，確定數據庫的訪問方式。詳細描述系統的配置方式。如果軟件有用戶界面，要對界面進行詳細設計，確定所有界面的名稱、規格及界面上的元素類型及功能，界面設計可在開發工具中直接繪制，也可采用其他繪圖方式，但在概要設計文檔中要保留圖示并進行詳細說明。格式參照《軟件項目概要設計說明書模板》。

4.2.2.2.4《軟件概要設計說明書》由項目組全體成員認可，主管軟件的研發經理最終確認。

4.2.2.2.5《軟件概要設計說明書》的變更，在開發過程中，項目組成員可提出對《軟件概要設計說明書》的變更申請，變更范圍限于不得違背《研發立項申請書》和《軟件需求分析說明書》的要求，所涉及的變更不至于影響到《研發立項申請書》和《軟件需求分析說明書》的變更，如果有，需要做《研發立項申請書》的變更流程或者《軟件需求分析說明書》的變更流程。《軟件概要設計說明書》變更的主要目的是修正其中的錯誤，或者經過變更可提高產品的品質或性能指標或縮短產品的研發周期。概要設計說明書的變更需得到項目經理的同意，必要是由項目經理召集相關技術人員和項目組成員召開簡短的技術會議進行論證。項目經理將變更后的內容寫入新版本的《軟件項目概要設計說明書》，主管軟件的研發經理最終簽字確認。

4.2.2.3軟件詳細設計

4.2.2.3.1軟件詳細設計由項目經理指派，項目組成員分擔完成。

4.2.2.3.2軟件項目詳細設計的內容及格式要求，軟件項目的詳細設計根據《軟件概要設計說明書》劃分的各個邏輯模塊包含的程序文件，確定每個程序文件中所包含的函數的詳細描述，要求有函數的功能描述、輸入輸出說明、使用規則和限制，如有必要，還可以描述函數的實現流程。詳細描述軟件中所有全局變量的格式、初始值、用途和使用規則。詳細描述軟件中所有的數據結構和類結構。詳細描述數據庫中的數據表，確定數據表的的每個字段，以及數據表之間的關系，確定所有的視圖、觸發器和存儲過程。詳細設計文檔不做具體的格式要求，為了提高研發效率，可以把詳細設計作為代碼的一部分，直接在程序中編寫，編寫時要遵循《研發中心軟件編碼標準》的規定。

4.2.2.3.3項目經理負責組織對詳細設計進行審核，審核方式可采用項目經理主審和項目成員互審相結合的方式，主要審核詳細設計和概要設計及需求分析的符合性，及詳細設計的正確性。主管軟件的研發經理可組織相關技術人員對詳細設計情況進行抽查。

4.2.2.3.4詳細設計的變更，可在項目開發的任何時段進行，由項目成員在得到項目經理的口頭同意后進行，要在變更處做好變更記錄。

4.2.2.4質量控制

4.2.2.4.1項目組內部互審，在項目的開發過程中，項目經理可組織項目組成員對編制的代碼進行互相審核，目的是審查代碼是否符合《研發中心軟件編碼標準》的要求，并在聯調前找到代碼中的缺陷，審核時要做好審核記錄，內容為代碼的編寫人、審核人、缺陷位置、缺陷描述和改進建議，格式由項目經理決定。根據項目的具體情況，項目經理有權決定不進行代碼的互審。

4.2.2.4.2研發中心內部抽查審核，在項目的開發過程中，主管軟件的研發經理可組織相關人員對項目組的開發質量進行抽查審核，被審核的代碼模塊由研發經理確認，審核的主要目的是驗證的代碼書寫的規范性和與設計的符合性。在評審中發現問題，主管軟件的研發經理可口頭通知項目經理進行整改，問題嚴重時，可對項目組下達《軟件整改通知單》，通知項目組進行整改。具體使用何種方式由主管軟件的研發經理確定。《軟件整改通知單》下達后，按比例扣除項目組的項目獎金，扣除辦法參見《研發軟件項目獎金發放制度》。

4.2.2.4.3項目組內部集成驗證測試，項目經理可在代碼完成后組織內部集成測試，并同時指派項目組成員進行《軟件使用說明書》的編制，在內部集成測試結束，《軟件使用說明書》完成后，項目經理可申請提交軟件的a測試。

4.2.2.4.4《a測試申請書》，項目經理負責編制《a測試申請書》，格式參照《a測試申請書模板》。編制完畢后，與《軟件使用說明書》一起提交給主管軟件的研發經理進行審核確認，主管軟件的研發經理簽字同意后，指定項目的測試人員，進行a測試。

4.2.2.4.5測試人員根據《研發立項申請書》和《軟件使用說明書》的要求與內容，編制《軟件測試大綱》，確定要測試的具體項目以及對這些項目的要求，《軟件測試大綱》編制完成后要由項目經理認可，主管軟件的研發經理確認。同時項目組負責協助測試環境的搭建。

4.2.2.4.6在一輪測試結束后，測試人員出具《項目測試報告》。項目組對測試出的問題進行修改，然后再申請新一輪的測試，新的一輪測試由項目經理決定是進行驗證性測試還是完整測試，如果是驗證性測試，可由項目經理確定測試內容范圍并和測試經理協商測試周期，循環上述過程直到項目經理認為可以結束測試。為了保證測試質量，要求最后一次測試必須是完整測試。測試結束后，測試人員要編制《測試過程總結報告》。

4.3研發結項

4.3.1測試結束后，項目經理可決定對項目進行結項提交。

4.3.2項目經理負責編制《研發結項申請書》，格式參照《研發結項申請書模板》。

4.3.3《研發結項申請書》要對所存留的問題進行詳細描述。

4.3.4《研發結項申請書》說明項目的實際開發周期，與計劃周期的差異將作為項目獎金的評定依據。

4.3.5《研發結項申請書》要說明項目質量目標的實現情況，根據《測試過程總結報告》統計出項目的實際質量，與計劃質量目標的差異將作為項目獎金的評定依據。

4.3.6《研發結項申請書》中所存留問題部分的內容需由此項目的實際測試人員進行確認。

4.3.7《研發結項申請書》由項目經理、主管軟件的研發經理、營銷中心經理、技服中心經理認可后，由主管研發副總經理最終確認。

4.3.4項目提交后，項目經理出具《軟件項目信息統計表》，由主管軟件的研發

經理認可，主管研發副總經理最終確認，作為項目獎金分配的依據。

4.4技術資料的管理與備份

4.4.1項目經理負責技術資料的管理與備份，備份內容包括項目所涉及的文檔、代碼和其他相關技術資料。

4.4.2項目立項后，項目組要在代碼管理服務器上建立專門的項目目錄。

4.4.3在研發過程中，項目組不定期的向代碼管理服務器進行代碼備份，備份時機由項目經理決定。

4.4.4項目提交測試前要進行一次完整備份。

4.4.5項目結項后，要進行一次完整備份，并將最終項目內容刻錄光盤備檔。

4.4.6備檔后的光盤由主管軟件的研發經理統一管理。

4.4.7在研發過程中，紙質文檔由項目經理負責管理，項目結項后提交到主管軟件的研發經理備檔。

4.4.8由于項目組備份不及時和備份管理不到位造成項目資料丟失，致使開發周期延誤的，每發生一次按比例扣發項目經理的項目獎金，造成重大損失的，全部扣發項目經理項目獎金，并根據具體情況追究其責任,是否為重大損失由主管軟件的研發經理確認。獎金的扣發辦法參照《研發軟件項目獎金發放制度》。5職責和權限

5.1主管研發副總經理負責本規范的編制、發布、維護與解釋。

5.2主管軟件的研發經理負責推動和監督本規范的實施。

5.3公司所有員工可對本規范提出修改意見。

6歷史記錄

本規范于2007年9月25日編制完成，形成V1.0版。

V1.0于2007年11月1日開始施行

第四篇：軟件配置管理規范流程

概述 1.1 目的

本文檔主要目的在于規范項目配置管理活動，確保配置項正確地唯一標識并且易于存取，保證基線配置項的更改受控，明確基線狀態，在整個軟件生命周期中建立和維護項目產品的完整性和可追溯性。

1.2 適用范圍

本文檔適用于不同類別的軟件產品和軟件項目開發工程的配置管理活動，針對項目不同在流程上作適當的刪減。配置管理可采用各種工具及手工辦法，本文件以CVS（并行版本系統）配置管理工具為例，規定公司的配置管理辦法，使用其他工具時也可對應本文件的要求參照執行。

1.3 術語和縮略語

1.3.1 軟件配置管理（Software Configuration Management，SCM）軟件配置管理是對軟件修改進行標識、組織和控制的技術，用來協調和控制整個過程。是通過技術或行政手段對軟件產品及其開發過程和生命周期進行控制、規范的一系列措施。配置管理的目標是記錄軟件產品的演化過程，確保軟件開發者在軟件生命周期中各個階段都能得到精確的不同版本的產品配置。

1.3.2 配置項（Configuration Item，CI）

凡是納入配置管理范疇的工作成果統稱為配置項，配置項邏輯上組成軟件系統的各組成部分，一般是可以單獨進行設計、實施和測試的。

每個配置項的主要屬性有：名稱、標簽、文件狀態、版本、作者、日期等。所有配置項都被保存在配置庫里，確保不會混淆、丟失。配置項及其歷史記錄反映了軟件的演化過程。

1.3.3 基線（Baseline）

在配置管理系統中，基線就是一個配置項或一組配置項在其生命周期的不同時間點上通過正式評審而進入正式受控的一種狀態，這些配置項構成了一個相對穩定的邏輯實體，而這個過程被稱為“基線化”。每一個基線都是其下一步開發的出發點和參考點。基線確定了元素（配置項）的一個版本，且只確定一個版本。一般情況下，基線一般在指定的里程碑處創建，并與項目中的里程碑保持同步。每個基線都將接受配置管理的嚴格控制，基線中的配置項被“凍結”了，不能再被任何人隨意修改，對其修改要嚴格地按照變更控制的過程進行。在一個軟件開發階段結束時，上一個基線加上增加和修改的基線內容形成下一個基線。

基線的主要屬性有：名稱、標簽、版本、日期等。1.4 權限與職責 1.4.1 研發總經理助理 1）審核變更請求。

1.4.2 項目經理（Project Manager，PM）1)審核批準配置管理計劃； 2)接收或拒絕小范圍的變更申請； 3)召集評估變更；

4)提出配置管理的建議和要求； 5)配合配置管理員的工作。

1.4.3 配置管理員（Configuration Management Officer，CMO）1)編寫配置管理計劃；

2)執行版本控制和變更控制方案； 3)制定訪問控制策略；

4)負責項目的配置管理工作，包括搭建環境、權限分配、配置庫的建立、配置項的控制等；

5)配置管理工具的日常管理與維護； 6)配置庫的日常操作和維護； 7)負責配置審核并提交報告；

8)根據配置部署表單編譯發布版本，并維護版本； 9)對開發人員進行相關的培訓；

10)對配置審核中發現的不符合項，擬訂糾正措施，要求相關責任人進行糾正。

11)監督項目組成員規范的執行情況。1.4.4 開發人員（Developer）

1)根據確定的配置管理計劃和相關規定，提交配置項和基線； 2)負責項目組內部測試； 3)負責軟件集成和版本生成；

4)按照軟件配置管理工具的使用模型來完成開發任務。2 實施細則 2.1 配置項管理 2.1.1 配置項的范圍

軟件配置可包括以下幾方面：開發文檔，代碼，第三方控件、插件，參考資料，測試文檔，用戶文檔，項目管理文檔，驗收文檔等。

l 項目文檔主要指：立項建議書、可行性分析報告、技術建議書、用戶需求說明書、項目計劃、項目進度計劃、項目階段性計劃、產品需求規格說明書、概要設計報告、詳細設計、數據庫設計、界面設計、用戶操作手冊、用戶安裝手冊、培訓文檔、驗收報告以及上述文檔的評審記錄。

l 代碼主要指：源代碼等。

l 工具主要指：腳本文件、插件、第三方控件等。2.1.2 配置項基線管理

結合SPP和ISO9000的相關規定，配置管理員根據配置管理規范及配置管理計劃，對配置項進行分階段管理，每一階段正式評審通過后納入受控庫，作為該項目的一個基線。

l 項目啟動：配置項包括技術建議書、可行性分析報告、用戶需求說明書等立項階段產生的文檔，評審或審批通過后建立發布基線。

l 需求階段：系統調研后開發人員進行需求分析，并整理產品需求規格說明書。產品需求規格說明書經過客戶的確認后，建立需求基線。如需升級版本則必須通過評審或審批并得到客戶的確認。

l 項目計劃：需求分析完成后即可制定項目的開發計劃，包括項目計劃和主要下屬計劃。包括項目進度計劃、配置管理計劃、質量保證計劃、測試計劃、項目階段性計劃。項目開發計劃評審通過后，建立項目計劃基線。

l 設計：系統設計可分為概要設計、詳細設計、數據庫設計、數據庫字典、界面設計。針對用戶需求規格說明書進行系統設計，配置時應說明系統設計的版本與需求分析報告版本的對應關系。設計說明書評審或審批通過后，建立設計基線。l 編碼（設計實現）：編碼按功能模塊分子項目，即每個模塊記作一個配置項。代碼在提交項目組系統測試時建立Beta版本，系統測試產品正式發布后建立Version版本。

l 測試：單元測試和系統測試。單元測試通過提交《單元測試報告》，項目啟動后應提交《系統測試計劃》，系統測試完成后應提交《系統測試報告》。配置時應說明測試的版本與編碼版本的對應關系。系統測試完成后建立測試基線。

l 版本發布：項目組提交《部署表單》，CMO根據部署表單進行編譯，發布測試服務器上，并對版本進行維護。同時將發布的版本上傳到文檔服務器上備份。

l 交付與驗收：在交付前配置審核完成后建立產品基線，產品基線包含程序以及有關文檔配置項，包括交付文檔、代碼、工具等。

l 產品部署：部署時應包括操作手冊、安裝維護手冊、維護文檔以及必要的業務和技術培訓文檔。

l 相關資料：相關資料也應作為配置項納入配置管理，此部分包括： 1)相關法律、法規；必須遵照或項目組約定的技術規范；

2)與客戶或項目組內部重要的交互信息記錄，如會議記錄、會談記錄、e-mail和MSN記錄等；

2.2 版本控制 2.2.1 文檔的版本控制

所有文檔的管理納入配置管理庫，用版本控制工具進行統一管理。文檔的版本控制主要通過文檔的名稱、文檔控制頁及版本控制工具的標簽來實現，主要分為以下幾類：

2.2.1.1 版本變化型文檔

命名方式：[文檔名稱]+[子系統名稱]（可選）

適用文檔：項目計劃、配置管理計劃、質量保證計劃、項目進度計劃、用戶需求規格說明書、產品需求規格說明書、體系結構設計報告、數據庫設計報告、詳細設計報告、用戶操作維護手冊、測試用例等。

示例：項目計劃.doc 詳細設計_SP門戶.doc 標簽結構：[大版本] + [子系統簡稱] + [版本號] + 日期（標簽控制說明版本信息）

l [大版本]： 可選，表示同一項目為不同用戶定制的版本。l [子系統簡稱]： 可選，當一個項目有多個子系統時，為區分不同子系統而設置。

l [版本號]：采用[Vs_x_y]的形式。

l 日期：納入基線管理的日期，用8位表示，如20071031 說明：

a.文檔發布名稱采用[文檔名+ Vs_x_y]的形式，文檔的版本號應該和版本控制工具中相應標簽上的版本號一致。

b.對文檔的修改需要從配置管理庫中取到本地進行。

c.對于文檔小的修改，如文字錯誤，格式調整，變更Vs_x_y中的y來區別（如：V1_0_1）。

d.文檔內容沒有大的增加和刪節，意思表述沒有發生重大的變化，版本標識通過版本工具中加上x標簽來表示（如：V1_1_0），以及在文檔內部控制頁標注變化來表示。

e.文檔有重大增加和刪節，意思表述有重大變化的，版本標識通過在相應文檔加上s標簽來表示（如：V2_0_0）。

f.對于納入基線庫的文檔的修改需要提交變更申請，經批準才能進行修改，并且修改的內容要經再次評審才能重新納入基線庫，作為后續階段的參考文檔。

2.2.1.2 時間區別型文檔 命名方式：[文檔名稱＋撰寫時間] 適用文檔：文檔名稱有明確的含義，需要用時間標識的日常性文檔。如周例會會議紀要，項目月計劃，項目月總結,階段性計劃等等。

示 例：周例會會議紀要20030901.doc 2.2.1.3 時間序號型文檔

命名方式：[文檔名稱+人員姓名（拼音）+撰寫時間+序列號] 適用文檔：測試報告

示例：單元測試報告_lixiaohong_20071112_01.dco 2.2.1.4 其他文檔：

對于不能按照前四種類型進行命名的文檔 會議紀要：會議紀要YYYYMMDD()示 例：9月9日召開的項目啟動會 命名為：會議紀要20030909(項目啟動).doc 評審報告：評審報告YYYYMMDD()同”會議紀要”要求一致。

示 例：10月9日召開的項目總體方案評審 命名為：評審報告20030910(總體方案).doc 2.2.2 發行版本表示

發行版本采用標簽說明，結構如下：

[大版本] + [版本類型] + [版本號] + [子系統簡稱(拼音)]+日期 +序號 [大版本]： 可選，表示同一項目為不同用戶定制的版本。

[子系統簡稱]： 可選，當一個項目有多個子系統時，為區分不同子系統而設置。

版本類型：分為3種

Beta表示項目組內部測試，標簽：B1_0_0-20071015-01 Release系統測試，標簽：Release1_0_0-SPmenhu-20071112-01 Version正式發行版，標簽：Version1_0_0-SPmenhu-20071112-01 [版本號] 對于Version正式發行版 是必須要注明的，而其它可選。發行產品基線在版本號前加Version，如

Version_1, Version_2, Version_3….表示分支；

Version_1_0, Version_1_1, Version_1_2… 表示在分支Version_1上的標簽； Version_0_0, Version_0_1, Version_0_2… 表示在主線上的標簽。2.3 配置庫管理 2.3.1 配置庫的分類

配置庫統一由配置管理員負責管理，服務器端使用cvsnt2.0.4，客戶端主要使用烏龜CVS。配置庫目錄結構如下：

2.3.2 配置庫的建立 所有項目應建立配置庫，以便管理各配置項，配置管理員組織建立配置庫。程序庫主要通過設置版本的分支來實現對配置項權限管理：

1)開發庫：開發人員相對比較自由的存儲空間，開發人員可以在自己的權限范圍內任意取出提交。

2)基線庫：配置管理員有最高權限，其余相關人員均為讀的權限，發生變更時變更人員須提交變更申請后方可修改基線庫內的配置項。

? 文檔評審通過后，文檔嚴格受控。由配置管理員將通過評審后的文檔移植到基線庫里同時將該配置項從開發庫移除。

? 代碼一般在移交系統測試時納入基線庫受控，可根據項目的具體情況設置基線。

3)產品庫：產品庫的產品均出自于基線庫，產品庫存儲的產品用于交付和存檔。

配置三庫統一由配置管理員管理，根據各開發階段的實際情況定制相應的版本選取規則，來保證開發活動的正常運作。在變更發生時，應及時做好基線的推進。

2.3.3 分配權限

項目開始后配置管理員編寫《配置庫目錄結構表》明確項目組成員以及相關人員的權限。在wincvs里有三種權限，讀（r）、寫（w）、添加刪除（c）權限。在開發庫內，文檔部分項目組成員有rcw權限，其他相關人員只r權限；代碼部分項目組成員有rcw權限，其他相關人員沒有任何權限。在基線庫內，項目組成員僅有r權限，其他相關人的權限視情況而定。在產品庫內，所有人沒有任何權限。配置管理員在三庫內均擁有最高權限。

2.4 配置變更控制 2.4.1 變更的分類

軟件及其相關文檔的變更按照變更的影響范圍進行分類：

1)A級：變更會影響系統級的需求、外部接口、產品價格或者交付期；這類變更必須經過配置管理委員會審核并有客戶批準和確認。

2)B級：變更會影響配置項間的功能接口、內部功能的設計、組件；這類變更必須由項目經理或配置管理委員會的批準和認可。3)C級：變更只會影響配置項內部或對BUG問題的處理；這類變更可以由配置項的管理人員負責批準。

? 系統測試前變更控制流程：

? 系統測試完畢發布release版本后變更控制流程

圖2 變更控制流程 2.4.2 變更請求的提出

a． 由技術支撐中心匯集顧客意見，影響到需求變更則填寫《配置項變更控制報告》，并提交給配置管理員。

b． 配置管理員對申請表是否清晰、明確和完整性進行審查，若發現變更不明確或不完整，應返回申請者。對通過審查的變更申請分配變更ID，以便跟蹤和記錄變更信息。

2.4.3 評估變更

a． 配置管理員將《配置項變更控制報告》發送給項目經理（或者其他授權人員），由項目經理負責對變更進行評估。

b． 項目經理對變更進行分解，一般的BUG修正不需要審批直接由項目經理決定是否需要變更。新增功能或對整個項目影響重大的變更必須由研發總助審批通過后方可變更。變更評估文檔在完成變更評估后發送給配置管理員。

2.4.4 變更實施和確認

a． 變更被批準后，項目經理提交變更實施進度計劃，開發人員開始實施變更，并詳細記錄變更的內容；質量部對變更的實施進行跟蹤。

b． 對于代碼變更，必須進行回歸測試，以確保變更沒有引入新的Bug。另外與變更相關的文檔必須修訂，以反映變更。當變更以及測試完成后，進行提交。

c． 通過測試后，質保人員需對變更進行審核，審核的范圍一般涉及以下方面：測試記錄；變更請求；配置項的檢入及檢出；文件的命名；版本的編號。

a． 審核后，由配置管理員更新到基線庫中。2.5 配置狀態報告 2.5.1 目的

記錄和報告整個軟件生命周期演化狀態。2.5.2 記錄內容

配置狀態報告記錄的內容包括： 1)軟件和文檔的標識； 2)目前狀態； 3)基線演化狀態； 4)變更狀態； 5)版本交付信息等。2.5.3 生成報告

配置管理報告自第一個基線創建時建立，由配置管理系統生成，及時反映當前配置狀態。

2.6 配置審核 2.6.1 類別 配置審核分為：

1)功能配置審核（Functional Configuration Audit，FCA）：審核軟件功能是否與需求一致，并符合基線文檔要求，通常要審查測試文檔等。

2)物理配置審核（Physical Configuration Audit，PCA）：審核要交付的組成項是否存在，是否包含所有必需的項目，如正確版本的源代碼、資源、文檔、安裝說明等等。

2.6.2 執行時機

通常選擇以下幾種情況由質量保證人員負責實施配置審核： 1)軟件產品交付或是軟件產品正式發行前； 2)軟件開發的階段工作結束后； 3)在產品維護工作中，定期地進行。2.6.3 不符合項處理

對配置審核中發現的不符合現象，配置管理員進行記錄，并交由責任部門限期進行糾正，配置管理員負責糾正措施的驗證。所有的不符合項報告均關閉后，才能發布新版本。

2.7 發行管理

通過配置審核后，經項目經理批準，由配置管理員負責生產新版本。2.7.1.1 交付管理

這里“交付”是指從配置庫中提取配置項，交付給客戶或項目外的人員。交付出去的配置項必須有據可查，避免發生混亂。流程如下：

1)交付人向質量部申請；

2)質量部如果不同意交付，則拒絕交付配置項。如果同意交付，配置管理員應給出詳細的交付清單；

3)交付人驗收后簽字。

第五篇：軟件配置管理解決方案

軟件配置管理解決方案

目的:

● 通過使用配置管理軟件,遵守版本控制、變更控制等規程,保證所有配置項的完整性和可跟蹤性。

范圍:

● 適用于公司的軟件開發項目,它規定了軟件配置管理活動的具體規程及其工作產品。

角色與職責:

● 配置管理員:編制項目配置管理計劃；創建并維護配置庫。

● 配置變更控制委員會(SCCB):審批配置變更申請。

● 軟件開發組成員:在權限內使用配置管理工具操作配置庫。

● 項目SQA人員:審計配置管理活動的規范性。

進入準則:

● 項目計劃已制定。

● 項目軟件過程已定義

● 配置管理員和SCCB人員已確定。

輸入:

● 項目計劃

● 項目軟件過程

結束準則:

● 對項目配置庫的操作和管理持續到項目結束。

● 只要存在用戶使用配置管理就要進行。

輸出:

● 配置管理計劃

● 產品配置庫

● 軟件基線審計報告

主要活動: 在項目早期(在項目計劃初稿后,并與項目計劃一起評審)編制項目配置管理計劃。

● 確定項目配置管理員。

● 項目經理和項目配置管理員共同指定項目組的SCCB。

● 項目經理與項目配置管理員按確定的軟件生命周期,識別出項目要進行控制的軟件配置項和納入配置管理的日期。

● 項目經理與項目配置管理員依據項目定義軟件過程,共同確定項目的基線,并標識每個基線的配置項。

● 項目經理確認由項目配置管理員制定的在軟件生命周期各個階段配置項的使用權限清單。

● 項目配置管理員按照《配置管理計劃模板》制定項目的SCM計劃。

● 項目配置管理員根據項目所使用的開發工具確定項目使用的配置管理工具。

● 項目配置管理員根據項目計劃的變動,適時調整項目的SCM計劃。具體規程見《項目跟蹤與監控過程》計劃變更相關步驟。

● 由項目主管主持,項目經理、公司配置管理主管、項目配置管理員、軟件工程組、軟件相關組參加對配置管理計劃書的評

審。具體規程參見《同行評審過程》。

按照配置管理計劃,進行項目的配置庫管理。

● 項目配置管理員規劃、建立項目的目錄結構。該結構支持對配置項的存儲和檢索功能。

● 項目配置管理員根據項目的規模,規劃和配置管理工具相關的配置庫結構。

● 項目配置管理員依據經項目經理確認的權限清單對目錄結構進行權限分配,以達到在相關組之間或配置庫內部之間進行共

享和傳輸。

● 項目配置管理員將配置項用配置管理工具統一管理,將軟件工作產品存放在指定的服務器的軟件基線庫中。

● 項目配置管理員保證由軟件基線庫制造的產品的正確生成。

● 公司配置管理員定期對服務器的軟件開發庫、軟件基線庫進行備份,對配置項的歸檔版本提供存儲和恢復功能。3 配置識別

● 項目配置管理員在制定項目的SCM計劃時,與項目經理共同識別出將置于配置管理之下的軟件工作產品。可標識為配置項的 軟件工作產品的例子有:

◇與過程有關的文檔；

◇軟件需求；

◇軟件設計；

◇軟件源代碼；

◇軟件可執行代碼；

◇軟件測試規程；

◇為軟件測試活動建立的軟件系統；

◇編譯程序；

◇交付給用戶的或最終用戶的軟件系統；

◇其它支持工具等。

● 項目配置管理員依據項目配置計劃書在給定的時間點上標識配置項/單元。

● 項目配置管理員依據開發規范,保證每個配置項賦予唯一的標識符。

● 項目組成員應用配置管理工具,標明每個配置項的修訂版本號。

● 項目配置管理員可用配置管理工具中的label功能,說明每個配置項所屬的軟件基線。

● 項目配置管理員使用配置管理工具記錄每個配置項/單元置于軟件配置管理之下的時間,并標明其生成者。配置變更

● 變更分類

對軟件及其相關文檔的變更按照變更的影響范圍進行分類:

1)A級:變更會影響系統級需求、外部接口、產品價格或者交付期；這類變更必須經過SCCB審核并有客戶批準和確認。

2)B級:變更會影響配置項間的功能接口、組件級成本或者項目Schedule；這類變更必須由SCCB或上級管理部門的批準和認可。

3)C級:變更會影響配置項內部功能的設計和分配；這類變更可以由配置項的管理人員負責批準。

● 變更請求的提出

◇如果需對已納入基線管理的配置項提出修改,項目組或其他相關人員應在配置項變更請求評審記錄中填寫變更請求,交給項目

經理。相關表格參見《配置項變更申請單》。

◇項目經理組織人員對變更請求進行評估,描述實施變更所影響的配置項、文檔和資源,確定變更的分類；如果是屬于A類

或B類,需要組織SCCB評審會進行評審。

● 變更實施

◇項目經理將需解決并批準的問題通知相關人員進行修改。

◇項目組成員實施《配置項變更申請單》中的所有變更,并確保相關文檔得到更改。

◇測試人員對已修改的問題進行確認,并將跟蹤結果記入CQ中。

◇當確認無誤后,項目組成員檢入配置庫。

◇項目配置管理員跟蹤配置項變更解決的過程。跟蹤的主要內容有:

1)解決人；

2)解決日期；

3)解決方法；

4)修改的文件；

5)受影響的文件；

6)受影響的數據；

7)是否經過驗證等。

● SCCB定期召開評審會,確認基線修改的正確性、完整性和一致性,并保證不會對基線造成意外的后果。保證由軟件基線庫生成產品并控制它們的發行。

● 項目經理或指定人員依據SDP中的build計劃和軟件產品測試申請單,對存放于軟件配置庫中的源程序進行編譯,生成軟件產

品,并提交測試人員進行測試。

● 測試人員依據產品測試通過標準,對待測產品進行確認測試,形成測試報告。

● SCCB依據測試報告,審計由軟件基線庫生成的軟件產品與測試通過標準的符合性,并生成SCCB會議紀要。

● 對審計通過的產品build,項目配置管理員將其升級為基線。

● 項目配置管理員對審計通過的軟件工作產品建立版本標識號(用配置管理工具的label加以標識)。

● 項目配置管理員將審計通過的軟件產品(release)放入軟件產品庫。

當軟件工作產品納入基線管理時,進行軟件基線審計。

● 根據項目配置管理計劃,SCCB確認在適當的時間需要審計的軟件基線,明確該基線包括的配置項。

● 在該基線包含的配置項經評審和檢查通過后,項目配置管理員通過配置管理工具將配置項升級為基線狀態,并為配置項標注

LABEL等。該基線所包含的所有配置項都升級為基線狀態時,該基線正式建立。

● 項目配置管理員驗證該基線是按照項目的配置管理計劃所明確的配置項組成的。

● 項目配置管理員驗證已建立的基線所包含的配置項是完備、準確的。

● 項目配置管理員將審計發現的問題記入基線審計報告,并對問題進行跟蹤直至解決。

● 項目配置管理員將基線審計報告向項目經理報告。

過程裁剪說明:

◆創建配置庫時,庫結構需要使用公司統一目錄結構,但是項目可以根據需要增加目錄結構；除在公司外部連接不到公司服務器情況

外,不可以使用公司規定以外的配置管理工具。

相關文檔:

◆配置管理計劃模板

◆配置項變更申請表表樣

◆軟件基線審計報告表樣