軟件項目的配置管理

軟件項目的配置管理2024/6/518.1軟件配置及其管理的概念8.2配置管理活動和流程8.3配置管理需求8.4版本管理8.5變更管理8.6配置狀態(tài)監(jiān)測與報告8.7基于配置管理的軟件項目管理8.8配置管理的技術手段和工具第八章?目錄2024/6/528.1軟件配置及其管理的概念8.2配置管理活動和流程8.3配置管理需求8.4版本管理8.5變更管理8.6配置狀態(tài)監(jiān)測與報告8.7基于配置管理的軟件項目管理8.8配置管理的技術手段和工具第八章?目錄2024/6/538.1.1CMM2的配置管理概念8.1.2IEEE的配置管理定義8.1.3配置管理概述8.1.4配置管理活動的作用8.1軟件配置及其管理的概念2024/6/54配置的概念配置的概念來自硬件軟件工程師是如何處理接口的？廣而言之：軟件的變化可以發(fā)生在一秒鐘內軟件的變化可以發(fā)生在每一秒鐘軟件開發(fā)過程下一秒鐘是不確定的情況將會怎樣？怎么辦？2024/6/55軟件項目開發(fā)管理的新需求你在一家小公司做軟件工程師，開始的時候，你只有一個人，配了2個助手。你們研究了一種算法（例如：圖象壓縮、數據加密等），編寫了一個實現模塊。有一天老板看到了你的演示，認為很有市場潛力，可以結合進公司正在給某行業(yè)用戶正在準備開發(fā)的系統中，成為該系統的核心技術或一個別人沒有的賣點。下一周，你的隊伍增加到14（你的老板準備就此豪賭一把了），與你3個人的小組不同的是，公司從其他部門為你配備了系統分析師，還有文檔編制員、測試員。你的核心模塊已經被大量的用戶功能所包裝，成為一個行業(yè)應用系統，并開始給用戶試用，這是你的系統的第一版。3個月后，公司決定把系統升級到第二版，除增加了許多新的功能外，公司決定支持多平臺，同時，為了提高系統的性能和效率，準備采用第三方廠家的中間件，取代自己做的接口。第一版的缺陷修改，也要反映到第二版中。第2版經過2個多月的開發(fā)，最終推向了市場。公司的這個產品不但被用戶所歡迎，也被一家大公司所看中（就像IBM收購了Lotus和Rational、Informix一樣），你們的產品，正好可以填補這家大公司產品線的空缺，你所在的公司被這家公司買去了。

2024/6/56公司為你的項目組派來了產品經理、項目經理。公司決定這個產品的測試，由公司總部獨立的測試部門承擔。同時，公司決定把項目組增加到50人，其中有20多人并不在你所在的城市。在新公司里，產品管理、項目管理、測試、質量等等，都與你過去的環(huán)境和做法不同，特別不同的是，公司準備開發(fā)的第3版系統與公司原有的產品要進行融合，使他們看上去是一家出來的不同的兄弟和姐妹。與軟件的第1版、第2版相比，你的項目管理有什么不同？

隨著這個產品的演變，項目發(fā)生了四個變化：（1）系統的復雜性發(fā)生了很大變化；（2）

用于開發(fā)該系統的項目環(huán)境發(fā)生了很大變化；（3）在不同的項目生命周期內，項目控制本身的要求和力度發(fā)生了很大變化；（4）由于組織的變化，管理流程、人員、方式發(fā)生了很大變化。前二類變化要求項目的組織和管理適應系統擴展的需要，后二種變化則要求項目管理具有適應性和靈活性。2024/6/57缺乏管理所造成的問題軟件開發(fā)人員之間缺乏必要的交流產品升級和維護所必需的程序和文檔非?；靵y開發(fā)過程中的人員流動經常發(fā)生因管理不善致使未經測試的軟件加入到產品中項目開發(fā)狀態(tài)不清楚軟件生產達不到規(guī)模化

2024/6/58軟件配置管理

SCM（SoftwareConfigurationManagement）

軟件配置管理（SCM）是指在開發(fā)過程中各階段，管理計算機程序演變的學科，它作為軟件工程的關鍵元素，已經成為軟件開發(fā)和維護的重要組成部分……SCM提供了結構化的，有序化的，產品化的管理軟件工程的方法。它涵蓋了軟件生命周期的所有領域并影響所有數據和過程。配置管理是指用于控制系統一系列變化的學科。通過一系列技術，方法和手段來維護產品的歷史，鑒 別和定位產品獨有的版本，并在產品的開發(fā)和發(fā)布階段 控制變化。通過有序管理和減少重復性工作，配置管理保證了生 產的質量和效率。2024/6/59

我們知道，在軟件建立時，變更是不可避免的，而變更加劇了項目中軟件開發(fā)者之間的混亂。SCM活動的目標就是為了標識變更、控制變更、確保變更正確實現并向其他有關人員報告變更。因此，從某種角度講，SCM是一種標識、組織和控制修改的技術，目的是使錯誤降為最小并最有效地提高生產效率。

SCM通過以下方法，強化軟件的可靠性和質量：（1）提供用于識別和控制文檔、代碼、接口、數據庫的結構框架，適用于軟件開發(fā)生命周期的所有階段；（2）全面支撐某一特定開發(fā)及維護工作方法，能夠適應各種類型的需求、標準、政策、組織機構以及相關的管理策略；（3）針對特定的基線狀態(tài)、變更控制、測試、發(fā)布版本或審查活動，生成相應的管理信息和產品信息。因此，從某種意義上講，SCM本質上是變更的管理。

SCM使軟件產品和過程的變更變?yōu)槭芸氐暮涂深A見的，它要求并在適當的工具支持下能夠做到這樣幾點：（1）誰做的變更？（2）軟件有什么變更？（3）什么時間做的變更？（4）為何要變更？

2024/6/510軟件項目的配置管理隨著計算機軟件的發(fā)展，軟件開發(fā)已由最初的“程序設計階段”經歷了“軟件系統階段”進而演變?yōu)楹髞淼摹败浖こ屉A段”，軟件的復雜性日益增大。此時，如果仍然把軟件看成一個單一的個體，就無法解決所面臨的問題，于是配置的概念逐漸引入軟件領域，人們越來越重視軟件配置的管理工作。

不懂軟件項目的配置管理，就不懂軟件開發(fā)管理不對軟件項目進行配置管理，就沒有進行軟件項目開發(fā)管理2024/6/511軟件配置管理是CMM2中6個關鍵過程域的第6個關鍵域。CMM2認為，SCM的目的是為了建立和維護軟件開發(fā)過程中各種制品的完整性和一致性，包括以下內容：對軟件產品配置的標志和識別系統地控制對處于配置管理下的各種軟件制品的修改和更新維護軟件開發(fā)過程中的各種制品的一致性和可跟蹤性8.1.1CMM2的配置管理概念

2024/6/512SCM的目標目標1:

軟件配置管理活動被定義和計劃目標2:

軟件開發(fā)過程中的制品被識別、控制和管理目標3:

對于處于配置管理下的軟件制品的修改被控制目標4:

與軟件制品相關的項目組和成員應該被通知制品的目前狀態(tài)和被修改的信息

從對配置目的的定義可以看出，CMM2的配置管理應包括這樣一些活動：標識給定時間點的軟件配置（即所選擇的工作產品及其描述），系統地控制這些配置的更改，并在軟件生命周期中保持這些配置的完整性和可跟蹤性。

CMM2認為，受控于配置管理的工作產品，包括交付給用戶的軟件產品（如：代碼等），以及生成軟件產品所需要的有關項（如：項目管理文件）。

CMM2的配置管理活動最主要的內容是：建立軟件基線庫，該庫存儲開發(fā)的軟件基線。通過軟件配置管理的更改控制和配置審核功能，系統地控制基線變更和由軟件基線庫生成的軟件產品版本。2024/6/513

要達到CMM規(guī)定的SCM要求所需具備的能力具有對軟件基線產品有管理權限的組織已經建立，例如：軟件配置管理委員會；協調和實現軟件配置管理的組織已經建立；為進行軟件配置管理所需要的各項資源已經分配；軟件配置管理組織里的成員已經接受了軟件配置目標、流程、方法方面的培訓；軟件項目組或是其他的相關的部門經過培訓，可以執(zhí)行他們的軟件配置管理活動；2024/6/514CMM中對SCM規(guī)定的活動根據文檔化的流程，項目軟件配置管理計劃已準備完畢；文檔化的已獲批準的軟件配置管理計劃可用作以后軟件配置管理活動的基礎；軟件配置管理庫已經創(chuàng)建，并可用作進入基線的軟件制品的存貯庫；處于軟件配置管理下的軟件制品被標志和識別；對于配置項的變更請求和問題報告被初始化、計劃、評審、批準并根據文化化的流程對其進行跟蹤；2024/6/515對于進入基線的制品的修改必須遵循文檔化的流程；發(fā)布的產品必須從軟件配置庫中取出，并且產品發(fā)布的流程須依照文檔化的流程和規(guī)定；根據文檔化的流程和規(guī)定，軟件配置項的狀態(tài)被記錄和跟蹤；記錄軟件配置管理活動和軟件基線內容的報告被建立，并通知受到影響的項目組和個人；根據文檔化的流程進行軟件制品基線的評審；CMM中對SCM規(guī)定的活動2024/6/516組織規(guī)定和相關責任項目級配置管理項目配置經理(ProjectConfigurationManager)與軟件配置管理計劃變更控制委員會(ChangeControlBoard)組織級配置管理組織配置管理庫(OrganizationalConfigurationManagementCell)負責項目完成后的軟件配置管理活動管理組織級的文檔2024/6/517IEEE標準729-1983就配置管理的內容進行了規(guī)范的定義：

（1）標識：識別產品的結構、產品的構件及其類型，為其分配唯一的標識符，并以某種形式提供對它們的存取。

（2）控制：通過建立產品基線，控制軟件產品的發(fā)布和在整個軟件生命周期中對軟件產品的修改。例如，它將解決哪些修改會在該產品的最新版本中實現的問題。

（3）狀態(tài)統計：記錄并報告構件和修改請求的狀態(tài)，并收集關于產品構件的重要統計信息。例如，它將解決修改這個錯誤會影響多少個文件的問題。

（4）審計和審查：確認產品的完整性并維護構件間的一致性，即確保產品是一個嚴格定義的構件集合。例如，它將解決目前發(fā)布的產品所用的文件的版本是否正確的問題。

（5）生產：對產品的生產進行優(yōu)化管理。它將解決最新發(fā)布的產品應由哪些版本的文件和工具來生成的問題。

（6）過程管理：確保軟件組織的規(guī)程、方針和軟件周期得以正確貫徹執(zhí)行。它將解決要交付給用戶的產品是否經過測試和質量檢查的問題。

（7）小組協作：控制開發(fā)統一產品的多個開發(fā)人員之間的協作。例如，它將解決是否所有本地程序員所做的修改都已被加入到新版本的產品中的問題。8.1.2IEEE的配置管理定義

2024/6/518CMM2的定義比較抽象，IEEE的定義就比較具體。結合各體系的定義和要求，我們下面具體來討論配置管理的概念。8.1.3配置管理功能概述

2024/6/519配置標識或者又稱為配置需求，包括標識軟件系統的結構，標識獨立部件，并使它們是可訪問的。配置標識的目的，是在整個生命周期中標識系統各部件并提供對軟件過程及其軟件產品的跟蹤能力。它回答：什么是受控的？

配置變更控制包括在軟件生命周期中控制軟件產品的發(fā)布和變更，目的是建立確保軟件產品質量的機制。它回答：受控產品怎樣變更？誰控制變更？何時接受，恢復，驗證變更？配置狀態(tài)統計包括記錄和報告變更過程，目標是不間斷記錄所有基線項的狀態(tài)和歷史，并進行維護，它解決以下問題：系統已經做了什么變更？此問題將會對多少個文件產生影響？配置變更控制是針對軟件產品，狀態(tài)統計針對軟件過程。因此，二者的統一就是對軟件開發(fā)（產品、過程）的變更控制。配置審核將驗證軟件產品的構造是否符合需求、標準、或合同的要求，目的是根據SCM的過程和程序，驗證所有的軟件產品已經產生并有正確標識和描述，所有的變更需求都已解決。它回答：系統和需求是否吻合？是否所有變更都是在版本控制下？

SCM的四大功能領域2024/6/520SCM從應用層次上可以從低到高分為三級：版本控制、以開發(fā)者為中心、過程驅動。版本控制主要應用于個人獨立開發(fā)或小組開發(fā)，它可以控制任何文件的版本、實現分支和歸并功能、進行文本比較、標記注釋和版本報告信息，主要工具有MS的VisualSourceSafe及IntersolvPVCS。

以開發(fā)者為中心主要應用于部門級開發(fā)，它可用于軟件維護、不斷增加的開發(fā)任務、并行開發(fā)、QA及測試，它面向大型團隊、利于交流、能最大限度地利用人力資源，主要工具為RationalClearCase及MKSSourceIntegrity。過程驅動主要使用于企業(yè)級開發(fā)，著重解決新的工具引入、IT審核、管理報告、復雜的生命周期、應用工具包、集成解決方案、資料庫等問題，實現真正規(guī)范的團隊開發(fā)，主要工具為PlatinumTechnologyCCC/Harvest。SCM的三個應用層次2024/6/521SCM中的專業(yè)術語

配置(Configuration)與配置項(ConfigurationItem)

在軟件開發(fā)過程中生成各種制品的總和叫做這個項目的軟件配置[RogerS.Pressman,1997]計算機程序，包括源代碼和可執(zhí)行程序與計算機程序相對應的各種文檔計算機數據，包括計算機程序中包含的數據和系統初始化數據2024/6/522SCM中的專業(yè)術語基線項目開發(fā)過程的制品經過正式評審并被相關人員一致同意，可以作為以后項目開發(fā)的基礎。對已經確定為基線的制品的修改必須要通過正式的變更控制流程。在軟件工程環(huán)境中，基線是指在軟件開發(fā)過程中的里程碑，這些里程碑的標志是一項或多項經過正式的技術評審并一致認同的軟件制品的提交。2024/6/523SCM中的專業(yè)術語配置數據庫（軟件制品基線庫）項目建立和訪問軟件制品庫，這個制品庫主要用來對保存配置項和一些與軟件配置管理相關的記錄。目前比較好的配置管理工具：Clearcase(Rational),Notes/Domino(Lotus),PVCS(Merant)andVSS(Microsoft).2024/6/524配置管理庫(1)基線庫的結構(VOB) ProjectRootDirectoryProjectPlanningPhaseDocumentsRequirementsAnalysisPhaseDocumentsDesignPhaseDocumentsCode,UnitTest&IntegrationPhaseDocumentsSystemTestPhaseDocumentsPhaseDeliverablesPhaseDeliverablesProductSoftwareTestSoftwareProductSoftwareRelatedTestSoftwareRelatedSourceCodeObjectiveCodeExecutiveCodeDOCDATAABBBBCode2024/6/525配置管理庫的具體實現——項目文件夾項目文件件是項目開發(fā)過程中由項目組創(chuàng)建和維護的制品歸檔庫。軟件配置管理負責管理和控制項目文件夾，并對文件夾中的內容進行評審；項目經理負責監(jiān)督項目的軟件配置管理執(zhí)行；軟件質量工程師負責對項目文件夾的內容進行評審；配置管理庫2024/6/526配置管理庫項目文件夾的內容項目開發(fā)過程中的所有信息，包括文檔、工作制品和各種周報、月報、評審等；與外部的交流信息，例如與客戶、第三方的通訊交流記錄等；其他交流會議記錄，例如：重要的Email，傳真，信件等；2024/6/527配置管理庫權限管理

項目組內部的權限管理與分配對其他項目組的開放權限管理與分配對其他用戶或是第三方的權限管理與分配2024/6/5288.1.4配置管理活動的作用配置管理與質量管理

在質量體系的諸多支持活動中，配置管理處在支持活動的中心位置。質量管理雖然也有過程的驗證，但配置管理只要定義的配置項夠細，則它可以管理軟件開發(fā)的全過程，細到每一個模塊、每一個文檔、每一條工程記錄的變化。因此，配置管理從基礎層開始，有機地把其它支持活動結合起來，形成一個整體，相互促進，相互影響，有力地保證了質量體系的實施。

2024/6/529配置管理給項目組帶來的好處（1）節(jié)約費用

縮短開發(fā)周期

減少施工費用

（2）有利于知識庫的建立

代碼對象庫業(yè)務及經驗庫

（3）規(guī)范管理

量化工作量考核

規(guī)范測試

（4）加強協調與溝通

2024/6/5308.1軟件配置及其管理的概念8.2配置管理活動和流程8.3配置管理需求8.4版本管理8.5變更管理8.6配置狀態(tài)監(jiān)測與報告8.7基于配置管理的軟件項目管理8.8配置管理的技術手段和工具第八章?目錄2024/6/5318.2.1主要配置管理活動8.2.2項目經理的配置管理流程8.2配置管理活動和流程2024/6/5328.2.1主要配置管理活動

標志配置項變更控制版本控制評審統計軟件編譯、連接和發(fā)放管理2024/6/533RUP描述的配置管理的主要活動如下圖所示：對于一個軟件項目組來說，開展一個項目組的配置管理，大致可以分為以下步驟：對于一個軟件項目組來說，開展一個項目組的配置管理，大致可以分為以下步驟：（1）擬訂項目的配置管理計劃；（2）創(chuàng)建項目的配置管理環(huán)境；（3）進行項目的配置管理活動，包括：標識配置項；管理基線和發(fā)布活動；監(jiān)測與報告配置狀態(tài)；管理變更請求。（1）和（2）可以看成配置管理的準備，（3）是配置管理的具體實施。配置管理的具體實施，在RUP定義為四個管理活動。

2024/6/534配置項（SoftwareConfigurationItem，SCI）識別

對于配置項，可以給出一個比較簡單的定義，既軟件過程的輸出信息可以分為三個主要類別：（1）計算機程序（源代碼和可執(zhí)行程序）（2）描述計算機程序的文檔（針對技術開發(fā)者和用戶）（3）數據（包含在程序內部或外部）。這些項包含了所有在軟件過程中產生的信息，總稱為軟件配置項?！?/p>

在CMM2中，除上述3個配置項以外，還包括項目管理的有關文件、信息記錄等。

由此可見，配置項的識別是配置管理活動的基礎，也是制定配置管理計劃的重要內容。

2024/6/535配置項（SoftwareConfigurationItem，SCI）識別

軟件配置管理認為軟件的開發(fā)過程是一個不斷變化著的過程，為了在不嚴重阻礙合理變化的情況下來控制變化，軟件配置管理引入了“基線（BaseLine）”這一概念。

IEEE對基線的定義是這樣的：“已經正式通過審核批準的某規(guī)約或產品，它因此可作為進一步開發(fā)的基礎，并且只能通過正式的變化控制過程改變?！?/p>

所以，根據這個定義，我們在軟件的開發(fā)流程中，也可以把所有需要加以控制的配置項分為基線配置項和非基線配置項兩類，例如：基線配置項可能包括所有的設計文檔和源程序等；非基線配置項可能包括項目的各類計劃和報告等。

有關配置項的內容，我們將在后面，專門花一節(jié)的篇幅，進行討論。2024/6/536配置項的標識和控制

所有配置項都應按照相關規(guī)定統一編號，按照相應的模板生成，并在文檔中的規(guī)定章節(jié)（部分）記錄對象的標識信息。在引入軟件配置管理工具進行管理后，這些配置項都應以一定的目錄結構保存在配置庫中。

所有配置項的操作權限應由配置管理員嚴格管理，基本原則是：基線配置項向軟件開發(fā)人員開放讀取權限；非基線配置項向項目經理、配置控制委員會及相關人員開放。

2024/6/537工作空間管理

在引入了軟件配置管理工具之后，所有開發(fā)人員都會被要求把工作成果存放到由軟件配置管理工具所管理的配置庫（存儲池）中去，或是直接工作在軟件配置管理工具提供的環(huán)境之下（根據配置管理構架提供的控制方式不同而不同）。每個開發(fā)人員按照任務的要求，在不同的開發(fā)階段，工作在不同的工作空間上。比較理想的情況是把整個配置庫視為一個統一的工作空間，然后再根據需要把它劃分為個人（私有）、團隊（集成）和全組（公共）這三類工作空間（分支），從而更好的支持將來可能出現的并行開發(fā)的需求。

2024/6/538版本控制

版本控制是軟件配置管理的核心功能。所有置于配置庫中的元素都應自動予以版本的標識，并保證版本命名的唯一性。版本在生成過程中，自動依照設定的使用模型自動分支、演進。除了系統自動記錄的版本信息以外，為了配合軟件開發(fā)流程的各個階段，我們還需要定義、收集一些元數據來記錄版本的輔助信息和規(guī)范開發(fā)流程，并為今后對軟件過程的度量做好準備。當然如果選用的工具支持的話，這些輔助數據將能直接統計出過程數據，從而方便我們軟件過程改進（SoftwareProcessImprovement，SPI）活動的進行。對于配置庫中的各個基線控制項，應該根據其基線的位置和狀態(tài)來設置相應的訪問權限。一般來說，對于基線版本之前的各個版本都應處于被鎖定的狀態(tài)，如需要對它們進行變更，則應按照變更控制的流程來進行操作。

2024/6/539變更控制變更管理的一般流程是：（1）（獲得）提出變更請求；（2）由CCB審核并決定是否批準；（3）（被接受）分配請求，修改人員提取配置項，進行修改；（4）復審變化；（5）提交修改后的配置項；（6）建立測試基線并測試；（7）重建軟件的適當版本；（8）復審（審計）所有配置項的變化；（9）發(fā)布新版本。

在這樣的流程中，配置管理員通過軟件配置管理工具來進行訪問控制和同步控制，而這兩種控制則是建立在前面所描述的版本控制和分支策略的基礎上的。

2024/6/540狀態(tài)報告配置狀態(tài)報告應該包括下列主要內容：

(1)配置庫結構和相關說明；

(2)開發(fā)起始基線的構成；

(3)當前基線位置及狀態(tài)；

(4)各基線配置項集成分支的情況；

(5)各私有開發(fā)分支類型的分布情況；

(6)關鍵元素的版本演進記錄；

(7)其它應報告的事項。

2024/6/541配置審計

配置審計的主要作用是作為變更控制的補充手段，來確保某一變更需求已被切實實現。在某些情況下，它被作為正式的技術復審的一部分，但當軟件配置管理是一個正式的活動時，該活動由SQA人員單獨執(zhí)行。

總之，軟件配置管理的對象是軟件研發(fā)活動中的全部開發(fā)資產。所有這一切都應作為配置項納入管理計劃統一進行管理，從而能夠保證及時的對所有軟件開發(fā)資源進行維護和集成。因此，軟件配置管理的主要任務也就歸結為以下幾條：（1）制定項目的配置計劃；（2）對配置項進行標識；（3）對配置項進行版本控制；（4）對配置項進行變更控制；（5）定期進行配置審計；（6）向相關人員報告配置的狀態(tài)。

2024/6/5428.2.2項目經理的配置管理流程項目經理的工作是：（1）確定項目配置管理策略（2）確定用于控制產品變更的策略和流程（3）在配置管理計劃（是軟件開發(fā)計劃的一部分）中記錄此信息2024/6/543配置管理策略

軟件配置管理策略是指能夠確定、保護和報告已經批準用于項目中的工件的能力。通過正確的標注來實現確定操作。對項目工件的保護是通過歸檔、建立基線和報告等操作而得以實現的。使用標準的、已記錄下來的變更控制流程的目的是：確保項目中所做的變更保持一致，并將產品的狀態(tài)、對其所做的變更以及這些變更所耗費的成本及對時間表的影響通知給有關的涉眾。

軟件配置管理計劃說明在產品/項目生命周期中要執(zhí)行的所有與配置管理相關的活動。它記錄如何計劃、實施、控制和組織與產品相關的配置管理活動。

2024/6/544配備人員

配置管理人員的選擇和配備，是軟件項目經理最主要的工作。在一個比較理想的軟件開發(fā)團隊中，需要哪些角色呢？

負責軟件項目組的項目經理 負責SCM計劃和策略的配置經理 負責軟件產品開發(fā)與維護的軟件工程人員 負責驗證產品正確性的測試人員 負責確保產品高質量的質量保證經理 使用產品的用戶。

2024/6/545配置經理

配置經理的目標是確保用來建立、變更及編碼測試的計劃和策略得以貫徹執(zhí)行，同時使有關項目的信息容易獲得。為了對編碼更改形成控制，配置經理引入規(guī)范的請求變更的機制，評估更改的機制（通過變更控制機構CCB，由它負責批準對軟件系統的變更），和批準變更的機制。

配置經理負責為工程人員創(chuàng)建任務單，交由項目經理對任務進行分配，創(chuàng)建項目的框架。同時，配置經理還收集軟件系統中構件的相關數據，比如說用以判斷系統中出現問題的構件的信息。

2024/6/5468.1軟件配置及其管理的概念8.2配置管理活動和流程8.3配置管理需求8.4版本管理8.5變更管理8.6配置狀態(tài)監(jiān)測與報告8.7基于配置管理的軟件項目管理8.8配置管理的技術手段和工具第八章?目錄2024/6/5478.3.1配置管理的對象8.3.2最基本的配置管理項——文檔8.3.3UCM目錄結構下的配置管理對象8.3配置管理需求2024/6/5488.3.1配置管理對象配置管理的第一個基本活動是配置標識，通俗地講，也就是查詢、識別和確定配置管理對象——配置項。在生產的軟件產品和軟件的生產過程中，那些是配置管理的對象呢？配置管理對象呈現為一種層次結構，因此，為了標識配置管理的對象，我們需要對軟件系統進行分解：目前，用于分解軟件系統的術語有多種多樣，沒有被標準化。1989年Humphery定義了5個層次：系統、子系統、產品、構件和模塊。1991年Whitgift定義了3個層次：系統、子系統和元素。IEEE定義了3個層次：計算機配置項、計算機軟件構件和計算機軟件單元。RUP定義了4個層次：系統、實施（或構件）子系統、構件和文件（RUP5.51999）。

2024/6/549配置管理對象

在RUP的概念里，最底層的元素是處于版本控制下的文件和目錄，構件的層次要高于元素（文件和目錄），構件把元素組織起來。一個版本控制的構件是一個具體的物理的對象，就是一個根目錄。這個根目錄，以及從根目錄下所屬的所有目錄和文件，是系統的一個子系統。大的系統有多個根目錄（子系統），小系統則可能只有一個根目錄。產品目錄結構為所有可具有版本號的、與產品相關的工件提供邏輯嵌套的占位符。工件是開發(fā)流程生命周期的結果，用于開發(fā)整個系統的各組成部分（構件）。2024/6/550配置管理對象

首先我們從根目錄開始（假設是只有一個根目錄的?。┫到y，討論軟件系統架構：軟件項目通過一系列的生命階段，將建立或者已經建立起一個體系構架。軟件的體系構架在軟件工程時代被稱為系統結構。在UML中，被稱為構架。

UML對構架的定義是：（1）一組有關軟件系統組織結構的重要決定；（2）結構要素和接口的選取，確保它們的行為能滿足這些要素之間的協作關系；（3）結構要素和行為要素以一種漸進的方式被組裝成子系統，能夠指導這種組織結構的結構風格，要素的內容，它們的接口、它們的協作和它們的組合。系統或系統構架是由子系統（構件）組成的。2024/6/551UML進一步把構件劃分成三種構件：部署型構件、工作產品型構件和執(zhí)行構件。

（1）部署型構件：是指那些被部署到目標機中的元素，例如：可執(zhí)行程序、庫以及其他支持系統運行的文件。（2）工作型構件：是構成開發(fā)環(huán)境的元素，例如：源文件、頭文件以及其他用于導出或構建部署型構件的文件。（3）可執(zhí)行型構件：是指由運行于目標機的系統生成的內容，例如：數據等。從SCM的角度看系統架構，我們主要關注的是在開發(fā)環(huán)境中以及將來部署到目標系統中的系統的物理層面的文件和目錄結構、分組和版本化。這種關注決定了配置管理的對象以及對象的“粒度”?，F在，有些項目使用高層次的設計文檔來描述架構，例如：模型、視圖等。在高層架構描述中，邏輯上的“類”，可影射對應為物理層面的文件和目錄。作為軟件產品和軟件過程，這些文件和目錄是SCM控制的對象，即他們是配置項。在我們現在的討論中，有時，我們說明這些文件是用于管理和設計系統的內容（包括：項目計劃、設計模型、測試報告）等，有些是實現系統設計的文件（包括：源代碼、庫、執(zhí)行文件等），有時，把它們不加區(qū)別地看成為構件。2024/6/552CMM2的配置管理對象

CMM2把配置管理對象，稱之為軟件工作產品，在CMM2配置管理定義中，對應置于配置管理下的軟件工作產品，是這樣定義的：可作為配置項/單元標識的軟件工作產品實例有：與過程相關的文檔（例如：計劃、標準或規(guī)程） 軟件需求 軟件設計 軟件代碼單元 軟件測試規(guī)程 為軟件測試活動建立的軟件系統 交付給客戶或最終用戶的軟件系統 編譯程序 其他支持工具 不論各體系是如何定義的，我們基本可以認為，配置管理的對象，主要地可以分為二類：軟件產品和文檔。軟件產品比較容易標識，而文檔相對比較復雜。我們將重點進行討論。

2024/6/5538.3.2最基本的配置管理項——文檔文檔在軟件開發(fā)人員、軟件管理人員、維護人員、用戶以及計算機之間，起到了多種的橋梁作用。軟件開發(fā)人員在軟件生命的各個階段中，以文檔作為前階段工作成果的體現和后階段工作的依據，這個作用是顯而易見的。這部分文檔通常稱為開發(fā)文檔。軟件開發(fā)過程中軟件開發(fā)人員需制定一些工作計劃或工作報告，這些計劃和報告都要提供給管理人員，并得到必要的支持。管理人員則可通過這些文檔了解軟件開發(fā)項目安排、進度、資源使用和成果等。這部分文檔通常稱為管理文檔，或稱為項目文檔。軟件開發(fā)人員需為用戶了解軟件的使用、操作和維護提供詳細的資料。這部分文檔通常稱為用戶文檔。2024/6/554我們把這三種文檔所包括的內容列在下圖中。其中列舉了十三個文檔，這里對它們做一些簡要說明：

文檔用戶文檔用戶手冊操作手冊維護修改建議軟件需求（規(guī)格）說明書開發(fā)文檔軟件需求（規(guī)格）說明書數據要求說明書概要設計說明書詳細設計說明書可行性研究報告項目開發(fā)計劃管理文檔項目開發(fā)計劃測試計劃測試報告開發(fā)進度月報開發(fā)總結報告2024/6/555文檔的生成階段

階段文檔

可行性研究與計劃需求分析設計代碼編寫測試運行與維護可行性研究報告項目開發(fā)計劃軟件需求說明數據要求說明概要設計說明詳細設計說明測試計劃用戶手冊操作手冊測試分析報告開發(fā)進度月報項目開發(fā)總結維護修改建議2024/6/556文檔的作用

所提問題文檔

什么何處何時誰如何為何可行性研究報告√√項目開發(fā)計劃√√√軟件需求說明√√數據要求說明√√概要設計說明√詳細設計說明√測試計劃√√√用戶手冊√操作手冊√測試分析報告√開發(fā)進度月報√√項目開發(fā)總結√維護修改建議√√√2024/6/5578.3.3UCM目錄結構下的配置管理UCM（統一變更管理）的發(fā)展沿革

第一代UCM：第二代UCM：第三代UCM：

第三代UCM引進了一些新的概念：（1）活動（Activity）：（2）構件（Component）：（3）工作流（Stream）：（4）項目（Project）：

2024/6/5588.1軟件配置及其管理的概念8.2配置管理活動和流程8.3配置管理需求8.4版本管理8.5變更管理8.6配置狀態(tài)監(jiān)測與報告8.7基于配置管理的軟件項目管理8.8配置管理的技術手段和工具第八章?目錄2024/6/5598.4.1版本管理的必要性8.4.2此前的版本管理8.4.3元素、分支與版本8.4.4構件、基線與存儲池8.4.5現代版本管理活動8.4版本管理2024/6/5608.4.1版本管理的必要性

在軟件開發(fā)過程中，由于軟件開發(fā)所固有的特征，可能會形成眾多的軟件版本，而且我們并不能保證不出現錯誤的修改，而這樣的一個困難局面卻又非常現實地擺在項目開發(fā)管理者的面前，他/她該如何有效地解決這些問題，具體地說就是如下一些問題：（1）怎樣對研發(fā)項目進行整體管理；（2）項目開發(fā)小組的成員之間如何以一種有效的機制進行協調；（3）如何進行對小組成員各自承擔的子項目的統一管理；（4）如何對研發(fā)小組各成員所作的修改進行統一匯總；（5）如何保留修改的軌跡，以便撤銷錯誤的改動；（6）對在研發(fā)過程中形成的軟件的各個版本如何進行標識，管理及差異識辨等等。一個非常直接的反應是，我們必須要引進一種管理機制，一個版本管理機制，而且是廣義上的版本管理，它不僅需要對源代碼的版本進行管理，而且還要對整個項目進行管理。2024/6/5618.4.2早前的版本管理

在軟件工程時代，面對這樣的問題，我們通過以往的那種被譽建立具有良好的編程風格的做法，諸如在編程或對他人的源程序進行修改時，注釋修改原因，修改人和日期。如果是多個成員同時進行了修改，那么可能出現一個庫管理員，由他來控制什么人在訪問哪個源代碼，修改的人向他報告做了什么改動。如果有幾個人同時改動，庫管理員或者限定同時只能有一個人做修改，他記住這人是誰，或者他自己來做同時修改的人工的差異比較和綜合，以便形成一個統一的新版本。在3-5人小組，這個庫管理員還能勝任，但這種做法在當前的大型軟件的開發(fā)中已經越來越困難了，因為靠人工的操作、靠個人的自覺、靠庫管理員的維護，充其量是一種以小作坊的形式來面對軟件的社會化大生產，再也不可能行得通了?；诠蚕砦募夸浀陌姹竟芾?/p>

在版本控制工具出現之前，或者，現在國內很多的軟件企業(yè)，并不用什么版本控制工具。他們也做一些簡單的版本控制工作。他們是怎么做的？最簡單的辦法是使用文件拷貝支持不同的版本。具體地講，就是項目組在項目組的文件共享服務器上，建立一個項目組文件系統，在文件系統下，對涉及到的文件，建立不同的版本目錄，從個人工作區(qū)到系統發(fā)布版，包括中間結果，甚至可能是所有文件。庫管理員不斷地增加目錄的標簽，以標識歷史前進的步伐。2024/6/5628.4.2早前的版本管理

早期的版本管理工具

（1）通過存儲池機制來維護文件庫； （2）創(chuàng)建和存放文件的多個版本； （3）提供一種或幾種鎖定裝置，強制對文件的修改順序； （4）標識文件的版本； （5）從歷史目錄中找回舊版本。這些工具基本上能幫助庫管理員從手工的管理中解脫出來，開發(fā)人員不需要庫管理員的介入，可以自己從庫中檢入和檢出文件，當文件被檢出后，其他人暫時不能再檢出此文件。同時，在必要的時候，文件的一個新版本被創(chuàng)立。2024/6/5638.4.2早前的版本管理

例如：MS的VSS版本控制是通過以下方式實現的：VSS提供版本控制和歷史服務，以保證一個文件的每個版本都是可恢復的。VSS用日期/時間戳來記錄文件是何時被Check-out或是何時被修改的，它主要有三種方法來跟蹤文件和項目的版本：（1）版本號：這是由VSS維護的內部數碼，用戶對它沒有控制權。每個文件和項目的每個版本都有一個版本號，這些版本號總是一個整數且是遞增的。（2）標簽：這些是用戶賦給某個項目或文件的某個版本的一個字符串，可以是任何格式的長度不超過31字符的字符串。（3）日期/時間戳：它給出了一個文件何時最后被修改的信息，或者是一個文件何時被Check-in。VSS同時支持12小時和24小時的時間格式。2024/6/5648.4.3元素、分支與版本

原子對象

在ClearCase的概念中，置于版本控制下的原子對象被稱為“元素”（element），元素是文件系統對象：文件和目錄。每個元素記錄了它所代表的文件和目錄的版本。所以，當用戶檢入文件時，就創(chuàng)建了那個元素的新版本。元素被組織成不同的分支。分支是線形的版本序列，版本序列構成的是并行開發(fā)的項目或基于統一基線開始的不同的系統。元素都被保存在存儲池（VOB）中。下圖是存儲池、元素、分支、版本之間的關系：在ClearCase中，每一個元素都以一個主分支（mainbranch）和一個不包含任何內容的零版本序列開始，稱為“/main/0”。每一次新版本檢入，在主分支上創(chuàng)建版本12024/6/565SCM

的版本樹左圖的版本樹中，長方形表示一個分支，圓形表示檢入的時間排序的版本號，箭頭表示從一個分支到另一個分支的變更回歸（歸并）?！鞍l(fā)布版本1.0/1.1”是這個版本上的標簽。目錄是元素，也是版本對象。ClearCase對目錄與文件一樣，也進行版本管理。為了能在前一個版本中修復BUG，或者從新版本退回到就版本，就有必要恢復一個舊的版本。目錄被修改，在檢入的時候，也要進行記錄。對目錄進行版本管理的目的，還可以借助目錄機制，重建或構造軟件系統的前一個版本。343210Release1.0\main2103\rel1_bugfix2\rel210Release1.12024/6/566元素類型

在ClearCase中，存放在存儲池中的元素都被賦予特定的類型，使之可以用于多種目的。類型可以幫助系統決定對該元素的操作。包括：

l

確定元素可以使用的存儲/增量機制

l

決定版本選擇的范圍，例如：設計文檔版本、項目管理文檔版本等

l

適用于不同的配置管理策略

l

決定比較、歸并等的機制

ClearCase已經預先定義了的元素類型，它們主要和存儲機制有關。 文件（完全備份） 文本文件（同軸增量備份） 壓縮文本文件（與文本文件相同，但進行壓縮） 壓縮文件（完全備份，僅進行壓縮） 二進制文件（差異增量保存） 目錄（直接保存）2024/6/5678.4.4構件、基線與存儲池

構件將把被一起開發(fā)、集成和發(fā)布的文件和目錄聚集在一起。聚集成ClearCase構件的文件和元素通常可以實現系統構架中的一個可重用的部分。構件通過標識一個根目錄來定義，這個目錄與所有的文件和子目錄都被看作是這個構件的一個部分。構件的一個版本就是一個基線。構件基線標識了構件中包含的每一個元素或一個版本，構件的基線用來配置工作流，為各種視圖提供信息，以便決定文件和目錄的什么版本被顯示。就像元素有版本一樣，構件有基線。當修改一個元素時，你創(chuàng)建了這個元素的一個版本，當你修改構件中的一個元素時，你也創(chuàng)建了這個構件的一個新基線。工作流把一組構件基線聚集在一起。然而，這不是項目范圍的基線概念，更恰當的講，當你在項目的集成流上完成一個基線操作時，你創(chuàng)建了一組被修改構件的基線。2024/6/568根據一個產品的質量標準要求和需求的不同，可以定義一個項目的不同基線。也就是說，一個公司可以定義不同的測試、功能、版本基線。另一個項目組可以根據自己的需要，選擇某特定構件，確定自己的基線。

下圖表明構件和基線之間的關系：任何UCM的核心最后將歸結到存儲池，存儲池也被稱為“VersionedObjectBase”，或簡稱為VOB。VOB是用于存儲文件、目錄和元數據的永久數據存儲池。VOB必須能夠支持可擴展的、容錯的、分布式的可復制的性能。

項目的VOB包含與項目環(huán)境有關的對象，如：項目、構件、活動以及基線，這些構成了一個正在開發(fā)的項目的所有信息，包括項目的組織和管理信息。2024/6/5698.4.5現代版本管理活動

現代版本管理活動圍繞以下展開：

l

支持多人同時修改同一文件；

l

支持多個小組在同一時間修改同一個軟件系統；

l

現代的工作空間管理；

l

現代的構建和發(fā)布管理。2024/6/570并行開發(fā)的版本控制并行開發(fā)3210\main2103\Bugfix4210\main3432\Telecom10Release1.0Telecom1.02024/6/571

版本控制的好處使混亂的開發(fā)狀態(tài)變得有序！SCM

的主要技術——版本控制2024/6/5728.1軟件配置及其管理的概念8.2配置管理活動和流程8.3配置管理需求8.4版本管理8.5變更管理8.6配置狀態(tài)監(jiān)測與報告8.7基于配置管理的軟件項目管理8.8配置管理的技術手段和工具第八章?目錄2024/6/5738.5.1基于基線的變更管理8.5.2變更請求管理過程8.5.3變更請求管理活動8.5.4變更請求的狀態(tài)轉移8.5變更管理2024/6/574可以了解誰改了什么、為什么正確及時的項目狀態(tài)報告

最大限度的利用你的工程師資源利于團隊交流是團隊開發(fā)過程中的通訊基礎2024/6/5758.5.1基于基線的變更管理

l

變更管理下的基線概念

l

建立基線的意義

l

建立基線的時機

2024/6/5768.5.2變更管理流程變更管理流程：變更管理流程包括提出請求、對請求進行評估、同意請求和實現對已經進入基線庫的配置項進行修改。CCB(ChangeControlBoard)，由項目經理、系統分析員、項目配置經理和軟件質量工程師組成，負責評估變更請求，提出同意或不同意對已進入基線庫的配置項的變更；TAF:test,analyzeandfix；2024/6/577變更管理流程(1)與變更管理流程相關的表格軟件問題報告表SoftwareProblemReportForm(SPRF)軟件變更請求表SoftwareChangeRequestForm(SCRF)軟件問題解決細節(jié)SoftwareProblemResolutionDetails(SPRD)2024/6/578變更管理流程(2)由用戶提出的變更請求由項目主提出的變更請求問題評估PAT由用戶在產品發(fā)布前發(fā)現的問題由項目組自身發(fā)現的問題系統分析員軟件問題報告表問題處理NOYES軟件變更請求表軟件變更請求表系統分析員由于升級而進行的變更對問題不予接受告知問題提出者問題被拒絕2024/6/579變更管理流程(3)2024/6/5808.5.3變更請求管理活動

2024/6/5818.5.4變更請求的狀態(tài)轉移

2024/6/5828.1軟件配置及其管理的概念8.2配置管理活動和流程8.3配置管理需求8.4版本管理8.5變更管理8.6配置狀態(tài)監(jiān)測、報告與評審8.7基于配置管理的軟件項目管理8.8配置管理的技術手段和工具第八章?目錄2024/6/5838.6.1配置狀態(tài)監(jiān)測與報告8.6.2配置評審8.6配置狀態(tài)監(jiān)測、報告與評審2024/6/5848.6.1配置項狀態(tài)統計配置項狀態(tài)統計，由項目配置經理定期地對項目配置項的狀態(tài)進行收集和統計，主要包括以下統計信息：項目制品進入基線庫的創(chuàng)建時間變更請求的詳細描述所有問題(ProblemReport)報告的描述變更請求的狀態(tài)BaselineStatusAccountingForm(BSAF)ArchiveStatusAccountingForm(ASAF)Change/ProblemStatusAccountingForm(C/PSAF)2024/6/585提供圖形化的項目狀況2024/6/586SCM的度量和度量準則SCM提供軟件產品的狀態(tài)統計。統計包括尋找軟件開發(fā)的瓶頸和解決辦法，并據此衡量軟件產品的成熟度。度量準則：平均嚴重程度，嚴重程度級的分布，平均關閉時間，嚴重程度的圖示，各配置項或子系統的圖示2024/6/587SCM的度量和度量準則軟件產品成熟度數據要求：軟件變更（問題）數量描述計算機軟件配置項標識（CSCI）嚴重程度級打開變更的日期（或發(fā)現問題）關閉變更（問題）和實施日期2024/6/588軟件變更統計SCM的度量和度量準則圖表分析軟件剩余問題剩余變更和錯誤密度2024/6/5898.6.2配置評審配置評審：配置評審通過對配置管理流程的各種制品進行審核，來判斷軟件配置管理流程被正確的執(zhí)行。配置評審包括功能評審和物理評審。功能配置評審(FunctionalConfigurationAudit,FCA)，功能配置評審是通過對軟件產品的功能和性能的審核，以及與需求說明的一致性來對軟件制品的評估。

由項目經理提出請求由軟件質量工程師計劃并實施對評審過程和標準有專門的文檔規(guī)定2024/6/590功能評審功能審核的目標是核實軟件配置項的實際性能是否符合它的需求。以下各項說明從配置管理角度來看支持功能審核所需要做的工作。（1）準備一個驗證表，列出所有功能方面的需求，而且對每個需求都引用測試過程、測試行為的實例（時間戳或其他測試實例標識符）、相應的測試結果和/或完整記錄需求驗證情況的分析和/或演示報告。（2）核實是否已正確實施了所有變更請求。（3）核實是否已對軟件正確應用了所有更改。（4）文檔差異、建立糾正操作和完成日期。2024/6/591物理評審物理配置評審PhysicalConfigurationAudit(PCA)：物理配置評審主要驗證軟件的功能是否與其設計一致，是否可以發(fā)布。物理配置評審跟隨在功能配置評審之后；由項目經理提出請求；由軟件質量工程師和項目配置經理計劃和實施；對于物理配置評審過程和標準，有專門的文檔規(guī)定；

物理評審的主要工作是：（1）創(chuàng)建應該出現在配置管理中的項目列表。（2）檢查在配置管理中維護的項目。（3）創(chuàng)建一個“差異列表”，表示已在配置管理中維護的項目以及應該在配置管理中維護的項目之間的差異。2024/6/5928.1軟件配置及其管理的概念8.2配置管理活動和流程8.3配置管理需求8.4版本管理8.5變更管理8.6配置狀態(tài)監(jiān)測與報告8.7基于配置管理的軟件項目管理8.8配置管理的技術手段和工具第八章?目錄2024/6/5938.7.1角色職責8.7.2配置管理計劃8.7.3項目經理的階段工作要點8.7.4配置管理實施的若干問題8.7基于配置管理的軟件項目管理2024/6/5948.7.1角色職責

項目經理（ProjectManager，PM）

配置控制委員會（ConfigurationControlBoard，CCB）

配置管理員（ConfigurationManagementOfficer，CMO）

系統集成員（Syst