IT软件项目配置管理课件

IT軟體專案配置管理8.1.1軟體配置及軟體配置項配置管理(ConfigurationManagement，CM)的目的是建立和維護在整個軟體生命週期中軟體專案產品的完整性和一致性。CM的主要目標是使修改部分更容易被適應，並減少變化中所花費的工作量。配置管理在一個IT軟體專案中是必須的，特別是對那種規模大且週期較長的專案。軟體配置管理是始終貫穿整個軟體過程的保護性活動。軟體配置管理的一系列活動被設計成為：標識變化、控制變化和保證變化被適當地實現，以及向其他可能的人員報告變化的一個有力和有效工具。

隨著軟體過程的進展，軟體配置項(SoftwareConfigurationItems，SCI)迅速增長。一般，系統的軟體規格說明了產生軟體專案計畫和軟體需求說明以及與硬體相關的文檔資料，然後在這些文檔基礎上又產生了其他的一些文檔，從而形成了一個資訊層次。

8.1.2軟體配置管理軟體配置管理(SoftwareConfigurationManagement，SCM)是軟體過程的關鍵要素，是開發和維護各個階段管理軟體演進過程的一種方法和規程。

軟體配置管理使得整個軟體產品的演進過程處於一種可視的狀態。

軟體配置管理作為CMM第2級上的一個關鍵域(KeyPracticeArea，KPA)，在整個軟體的開發活動中佔有很重要的位置。

及多少識別和修改，多少錯誤仍然未被發現等；也可以用於對費用和進度參數的預測。軟體配置管理活動：8.1.2軟體配置管理

軟體配置管理功能：軟體配置管理配置標識變更控制配置狀態統計配置審核圖8.1軟體配置管理功能8.2軟體配置管理概念

8.2.1制定軟體配置計畫8.2.2確定配置標識8.2.3版本管理8.2.4變更控制

8.2.5系統整合8.2.6狀態報告8.2.7配置審計

8.2.1制定軟體配置計畫專案經理和配置管理委員會(CCB)根據專案的開發計畫確定各個里程碑和開發策略。根據CCB的規劃，制定詳細的配置管理計畫，交CCB審核。CCB通過配置管理計畫後交專案經理批准，發佈實施。軟體配置管理的主要流程如下：8.2.1制定軟體配置計畫文檔命名約定。正式文檔的關係(專案計畫書、需求定義、設計報告、測試報告都是正式文檔)。確定負責驗證正式文檔的人員。確定負責提交配置管理計畫的人員。在已建立了要管理的文檔後，配置管理計畫必須定義以下問題：

8.2.1制定軟體配置計畫根據已文檔化的規程為每個軟體專案制定軟體配置管理計畫。這個規程一般規定：在整個專案計畫的初期制訂軟體配置管理計畫，並與整個專案計畫並行；由相關小組審查軟體配置管理計畫，管理和控制軟體配置管理計畫。將已文檔化且經批准的軟體配置管理計畫作為執行配置管理活動的基礎。該計畫應該包括：需要被執行的配置管理活動、活動的日程、指派的責任和需要的資源(包括人員、工具、電腦設施等)；配置管理的需求和由軟體開發小組和其他相關小組執行的配置管理活動一樣。制定配置管理計畫中，必須定義以下問題：

8.2.2確定配置標識有效地配置管理，需要確定配置標識：

(1) 建立一個配置管理庫作為存放軟體基線的倉庫。

基线是指已经通过正式评审和认可的标准，作为以后进一步开发的基础，并且只有通过正式的更改控制规程才能进行更改的规程说明或者产品。当软件基线生成时，就纳入软件基线库中。存取软件基线内容的工具和规程就是配置管理库系统。

(2) 標識置於配置管理下的軟體工作產品。

置於配置管理之下的軟體工作產品，主要包括可交付給客戶的軟體產品(如軟體需求文檔和代碼等)，以及與這些軟體產品等同的產品項或者生成這些軟體產品所需要的產品項(如編譯程序、運行平臺等)。所謂配置標識就是為系統選擇配置項，並在技術文檔中記錄其功能特徵和物理特性。

(3) 根據文檔化的規程，提出、記錄、審查、批准和跟蹤所有配置項/配置單元的更改要求和問題報告。

(4) 根據文檔化的規程記錄配置項/配置單元的狀態。該規程一般規定：詳細地記錄配置管理行動，讓每個成員都知道每個配置項/配置單元的內容和狀態，並且能夠恢復以前的版本；保存每個配置項/配置單元的歷史，並維護其當前狀態。8.2.3版本管理版本變遷演化：Obj1.0Obj1.1Obj1.2Obj1.4Obj2.0Obj2.1Obj1.1.1Obj1.1.2Obj1.3圖8.2版本變遷演化12345變體8.2.4變更控制

變更的預期效益如何？變更的成本如何？專案變更進程後，對專案成本的影響如何？變更對軟體品質的影響如何？變更對專案資源分配的影響如何？變更可能會影響到專案後續的哪些階段？變更會不會導致出現不穩定的風險？一般需要考慮以下因素

:8.2.4變更控制

專案名稱變更提案請求者，提案日期變更內容變更分析者，分析日期被變更影響的部分與變更相關的其他部分對變更的評估變更的優先順序變更的實現變更的預測成本變更提交給配置管理委員會(CCB)的日期配置管理委員會決定，做出決定的日期變更實現者，變更實現日期提交給品質控制小組(QA)的日期品質控制小組的決定提交給專案經理的日期專案經理的評價變更提案所包括內容

:8.2.5系統整合

是否所有組成系統的成分都包括在整合說明書中？是否所有組成系統的成分都有合適的版本？是否所有的數據檔都是可以獲得的？在組成系統的所有成分中，是否有數據檔命名相同的？是否有合適版本的編輯器和其他工具？必須要考慮的問題有

:8.2.5系統整合

可執行檔系統整合者UNIX/NT/OS2邏輯結構到物理

結構的映射整合工具檔1檔2……檔N系統邏輯描述圖8.4系統整合邏輯過程8.2.6狀態報告配置庫結構和相關說明。開發起始基線的構成。當前基線位置及狀態。各基線配置項集成、分佈的情況。各私有開發分支類型的分佈情況。關鍵元素的版本演進記錄。其他應予報告的事項。主要內容

:8.2.7配置審計配置審計的主要作用:是作為變更控制的補充手段，來確保某一變更需求已被切實地執行和實現。在某些情況下，配置審計被作為正式的技術審核的一部分，但當軟體配置管理是一個正式的活動時，配置審計活動就應該由軟體品質管理人員單獨執行。

8.3軟體配置管理組織8.3.1軟體配置管理組織構成8.3.2軟體配置管理組織方針

8.3.1軟體配置管理組織構成

制定和修改專案的組織結構和配置管理策略。批准、發佈配置管理計畫。決定專案起始基線和開發里程碑。接受並審閱配置控制委員會的報告。專案經理職責主要包括如下幾項

:8.3.1軟體配置管理組織構成授權建立軟體基線和標識配置項/配置單元。代表專案經理和受到軟體基線影響的所有小組的利益。在IT專案管理中，受影響的組包括：品質保證組、配置管理組、工程組(包括硬體工程組、軟體工程組)、系統測試組、合同管理組、文檔支持組等。審查和審定對軟體基線的更改。審定由軟體基線資料庫中生產的產品和報告。軟體配置控制委員會SCCB主要負責以下工作

:8.3.1軟體配置管理組織構成創建和管理專案的軟體基線庫。制定、維護和發佈SCM計畫、標準和規程。標識置於配置管理下的軟體工作產品集合。管理軟體基線的庫的使用。更新軟體基線。生成基於軟體基線的產品。記錄SCM活動。生成和發佈SCM報告。軟體配置管理小組SCM負責協調和完成以下的工作:8.3.2軟體配置管理組織方針明確地分配每個專案的SCM責任。在專案的在整個生命週期中實施SCM。SCM為外部交付的軟體產品、內部軟體產品指定用於專案內部的支持工具，如編譯器、調試器等，以便實施配置管理。軟體專案中，需要建立和使用一個倉庫(如數據庫)用於存放配置項/配置單元和相關的SCM記錄。這個倉庫的內容將成為軟體基線庫。使用該倉庫的工具和規程就是配置管理庫系統。置於配置管理之下的、並作為單獨實體的工作產品就成為配置項。通常，配置項分為若干配置組件，配置組件分為若干配置單元。在一個硬/軟體系統中，可能把全部軟體視為一個單獨的配置項，也可能把軟體部分分為多個配置項。實際上，配置項/配置單元就是指置於配置管理之下的元素。定期審核軟體基線和SCM活動。方針主要包括如下內容

:8.4軟件測試8.4.1軟體測試的概念8.4.2軟體測試原則與策略8.4.3軟體測試完成的標準8.4.4軟體測試步驟8.4.5軟體測試工作流程8.4.6軟體測試的自動化8.4.1軟體測試的概念黑盒測試法一般稱為功能測試或數據驅動測試，在測試過程中，把系統看成是一個黑盒子，不考慮程式的內在邏輯，而是只根據需求規格說明書的要求來檢查程式的功能是否符合它的功能需求說明。白盒測試法又稱為結構測試或邏輯驅動測試，在測試過程中，允許測試人員對程式的內部邏輯結構及有關資訊來設計和選擇測試用例，對程式的邏輯路徑進行測試。軟體測試的方法和技術是多種多樣的。從測試是否針對系統的內部結構和具體實現演算法的角度看，通常可分為兩類：白盒測試法(結構測試)和黑盒測試法(功能測試)。

8.4.2軟體測試原則與策略應當把“儘早和不斷地測試”作為開發人員的一個座右銘。程式員和程式設計機構原則上不應該測試自己設計的程式。制定嚴格的測試計畫，並把測試時間安排得儘量寬鬆，不要希望在極短的時間內完成一個高水準的測試。在測試過程中，不僅要有確定的輸入數據，而且也要確定預計的輸出數據。在測試過程中，不僅要有合理的輸入數據，而且也要有不合理的輸入數據。在測試過程中，除了檢查程式是否完成了預定的功能外，還要測試程式是否還有不應該存在的功能和“後門”。測試完成後，妥善保存一切測試過程文檔和全部的測試用例(數據)，並作為軟體和文檔的一個組成部分，測試的重現性往往要靠測試文檔。程式中存在錯誤的概率與該程式中已經發現的錯誤數一般是成正比的。重複測試一定要引起充分的重視，由於修改一個錯誤而引起更多錯誤出現的現象並不少見。測試原則

:8.4.2軟體測試原則與策略測試策略

:CU軟體專案SRDIVST需求分析系統設計

編碼單元測試集成測試確認測試系統測試圖8.5軟體測試的策略8.4.3軟體測試完成的標準搞清楚完成的標準,以及軟體故障模型:測試時間t預期的錯誤密度，l(t)在測試過程中收集的實測數據圖8.6錯誤密度與測試時間的函數關係每小時錯誤數l0f(t)=(1/p)㏑(l0pt+1)8.4.4軟體測試步驟1.單元測試2.集成測試3.確認測試4.系統測試5.Alpha和Beta測試開發是自頂向下的,測試是自底向上的,測試內容有:8.4.5軟體測試工作流程總過程：立項階段需求分析階段設計階段編碼階段單元測試階段集成測試階段系統測試階段驗收測試階段結項階段圖8.8軟體測試總的過程8.4.5軟體測試工作流程需求階段的測試工作流程

:需求階段工作培訓編寫用戶需求需求評審需求變更進入下一階段變更需求圖8.9需求階段的測試工作流程需求說明書需求變更記錄系統測試方案總體測試方案8.4.5軟體測試工作流程設計編碼階段的測試工作流程

:圖8.10設計、編碼階段的測試工作流程概要設計集成測試計畫設計方案評審詳細設計單元測試方案系統測試驗證標準單元測試報告進入下階段變更設計需求相關文檔詳細設計方案評審變更設計編碼單元測試修改8.4.5軟體測試工作流程集成測試、系統驗收測試階段工作流程

:圖8.11集成測試、系統測試階段工作流程集成測試集成測試計畫測試評估系統測試產品化工作報告系統測試方案系統測試報告測試工作結束產品化工作驗收測試上一階段品質合格證書8.4.6軟體測試的自動化測試個案的生成，包括測試輸入、標準輸出、測試操作指令等。測試的執行寫控制，包括單機與網路分佈運行、夜間及假日運行、測試個案調用控制、測試對象、範圍、版本控制等。測試結果與標準輸出的對比。不吻合的測試結果的分析、記錄、分類和通報。總測試狀況的統計，報表的產生。自動化的測試操作主要包括：

8.5配置管理工具8.5.1配置管理工具選擇8.5.2配置管理工具簡介8.5.1配置管理工具選擇首先是經費。市場上現有的商業配置管理工具，大多價格不菲。到底是選用開放源代碼的自由軟體、還是採購商業軟體，如果採購商業軟體，選擇哪個檔次的軟體，這些問題的答案，都取決於可以獲得的經費量。

工具的市場佔有率。大家都選擇的東西通常會是比較好的，而且市場佔有率高也通常表明該企業經營狀況會好一些。工具本身的特性，如穩定性、易用性、安全性、擴展能力等。在投資前應當對工具進行仔細的試用和評估。比較容易忽略的是工具的擴展能力，在幾個、十幾個人的團隊中部署工具是合適的，但當規模擴大到幾百人在依賴這個工具時，這個工具還能不能提供支持。廠商支持能力。工具使用過程中一定會出現一些問題，有些是因為使用不當引起的，但也有些是工具本身的毛病。這樣就會影響到開發團隊的工作進度。而如果廠商具備服務支持，那麼就能隨時找到廠商的專業技術人員幫助解決問題。可以