IT軟件項目配置管理課件

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

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

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

軟體配置管理使得整個軟體產(chǎn)品的演進過程處於一種可視的狀態(tài)。

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

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

軟體配置管理功能：軟體配置管理配置標識變更控制配置狀態(tài)統(tǒng)計配置審核圖8.1軟體配置管理功能8.2軟體配置管理概念

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

8.2.5系統(tǒng)整合8.2.6狀態(tài)報告8.2.7配置審計

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

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

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

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

基線是指已經(jīng)通過正式評審和認可的標準，作為以后進一步開發(fā)的基礎(chǔ)，并且只有通過正式的更改控制規(guī)程才能進行更改的規(guī)程說明或者產(chǎn)品。當(dāng)軟件基線生成時，就納入軟件基線庫中。存取軟件基線內(nèi)容的工具和規(guī)程就是配置管理庫系統(tǒng)。

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

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

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

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

變更的預(yù)期效益如何？變更的成本如何？專案變更進程後，對專案成本的影響如何？變更對軟體品質(zhì)的影響如何？變更對專案資源分配的影響如何？變更可能會影響到專案後續(xù)的哪些階段？變更會不會導(dǎo)致出現(xiàn)不穩(wěn)定的風(fēng)險？一般需要考慮以下因素

:8.2.4變更控制

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

:8.2.5系統(tǒng)整合

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

:8.2.5系統(tǒng)整合

可執(zhí)行檔系統(tǒng)整合者UNIX/NT/OS2邏輯結(jié)構(gòu)到物理

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

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

8.3軟體配置管理組織8.3.1軟體配置管理組織構(gòu)成8.3.2軟體配置管理組織方針

8.3.1軟體配置管理組織構(gòu)成

制定和修改專案的組織結(jié)構(gòu)和配置管理策略。批準、發(fā)佈配置管理計畫。決定專案起始基線和開發(fā)里程碑。接受並審閱配置控制委員會的報告。專案經(jīng)理職責(zé)主要包括如下幾項

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

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

:8.4軟件測試8.4.1軟體測試的概念8.4.2軟體測試原則與策略8.4.3軟體測試完成的標準8.4.4軟體測試步驟8.4.5軟體測試工作流程8.4.6軟體測試的自動化8.4.1軟體測試的概念黑盒測試法一般稱為功能測試或數(shù)據(jù)驅(qū)動測試，在測試過程中，把系統(tǒng)看成是一個黑盒子，不考慮程式的內(nèi)在邏輯，而是只根據(jù)需求規(guī)格說明書的要求來檢查程式的功能是否符合它的功能需求說明。白盒測試法又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試，在測試過程中，允許測試人員對程式的內(nèi)部邏輯結(jié)構(gòu)及有關(guān)資訊來設(shè)計和選擇測試用例，對程式的邏輯路徑進行測試。軟體測試的方法和技術(shù)是多種多樣的。從測試是否針對系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實現(xiàn)演算法的角度看，通?？煞譃閮深悾喊缀袦y試法(結(jié)構(gòu)測試)和黑盒測試法(功能測試)。

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

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

:CU軟體專案SRDIVST需求分析系統(tǒng)設(shè)計

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

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

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

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

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

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