【導(dǎo)讀】其他個人或集體已經(jīng)發(fā)表或撰寫的成果作品。對本文的研究做出重要貢獻。的個人和集體，均已在文中以明確方式標明。本人完全意識到本聲明的法。律后果由本人承擔。本人授權(quán)湖南大學(xué)可以將本學(xué)位論文的全部或部分內(nèi)容編入?？刂?、變更控制、配置狀態(tài)統(tǒng)計和配置審核等實踐活動.對特定環(huán)節(jié),淺談可能存在的問題以及相應(yīng)的解決方法或?qū)崿F(xiàn)途徑。本文是討論軟件開發(fā)管理系統(tǒng)的設(shè)計和實現(xiàn)的研究。針對這樣一個復(fù)雜的大型系統(tǒng)，怎樣的架。構(gòu)才能保障整個系統(tǒng)的順利建立，并保證長期穩(wěn)定的運行；；3．對于復(fù)雜的管理系統(tǒng)，如何提供完善的維護管理，以實現(xiàn)實時，科學(xué)管理。通過此課題的研究，使得研究成果能夠運用于軟件開發(fā)過程管理中，提高

　　

【正文】 過程改進、實施 配置管理的組織帶來了一定的難度 . 在實施配置管理的過程中 ,由 SCM組與項目經(jīng)理一起制定 SCM計劃 . 要將制定配置管理計劃的任務(wù)分配到指定的人員 ,要確保負責制定配置管理計劃的人員在目標、規(guī)程和方法等內(nèi)容方面接受培訓(xùn) ,同時要確保所有受影響的部門或者個人都要參與評審配置管理計劃 . 創(chuàng)建配置管理環(huán)境 (1) 設(shè)置軟件配置組織結(jié)構(gòu) SCM 過程實施必須有一個獨立的機構(gòu) ,如 SCM 組 . 配置管理組由配置管理專職人員組成 ,目前主要由 CM 經(jīng)理、配置管理員 . SCM 過程中還涉及到其他的角色 ,具體見前文所述 . (2) 建立 SCM 文件體系 SCM 實施文件體系包括 :第 1 層的 SCM 方針政策 ,描述SCM 的目標、方法、途徑 ,由 CM 經(jīng)理編制 。第 2 層次的 SCM 過程 ,是整個文件體系的核心 ,將 SCM 標準的包括執(zhí)行活動在內(nèi)的所有共同特性的關(guān)鍵實踐予以文件化和制度化 ,由 CM經(jīng)理組織人員編制 。第 3 層次的配置管理規(guī)范和適合目標機構(gòu)的配置管理基本章程 ,為具體執(zhí)行 SCM 活動提供作業(yè)規(guī)范或模板 ,一般由從事這項具體工作的人員編制 ,由 CM 經(jīng)理審核 ,經(jīng)項目經(jīng)理批準 . 下層的文件支持上層的文件 ,形成金字塔構(gòu)架的文件體系 . (3) 提供 SCM 所需的資源組織必須提供 足夠的資源以保證具備實施 SCM 的執(zhí)行能力 . 在實施 CMM 過程中 , SCM 是最需要軟件工具支撐的 KPA. 這些工具包括SCM 軟件、配置狀態(tài)統(tǒng)計軟件等 ,如 Rational Clear Case、 CVS 等 . 選擇工具時須考慮 SCM 目標和過程 ,組織的規(guī)模、軟件開發(fā)方式和特點 . 在購買了工具軟件后 ,必須對操作人員進行上崗培訓(xùn) . (4) 建立軟件配置管理庫系統(tǒng)建立軟件配置管理庫系統(tǒng)的主要目的是用來存軟件開發(fā)管理系統(tǒng)設(shè)計與實現(xiàn) 10 放軟件基線 . 它可以對軟件配置管理進行多級的控制 ,譬如在產(chǎn)品的開發(fā)周期中 ,不同的階段有著不同力度的配置管理 ,隨著產(chǎn)品不 斷成熟 ,控制力度也隨之增強 。提供對庫中配置項的存儲和修改的功能 ,支持在相關(guān)組之間和庫中不同控制級間共享和傳輸配置項 。支持生成軟件配置管理的報告文檔以及軟件基線內(nèi)容的報告文檔 . 標識配置項確定置于配置管理下的配置項 ,確保已確定的每個配置項有唯一標識 ,用于跟蹤和管理 . 在選定配置項時應(yīng)遵循下列準則之一 :(1) 兩個或以上的組共同使用的工作產(chǎn)品 (2) 可能因需求的差錯或變更而做相應(yīng)變化的工作產(chǎn)品 (3) 彼此相關(guān)并且其中之一發(fā)生變更將會使得其他工作產(chǎn)品發(fā)生變更的工作產(chǎn)品 。(4) 對整個項目至關(guān)重要的工作產(chǎn)品 . 版本控制版本控制是 SCM 的核心 ,其目的是按照一定的規(guī)則保存配置項的所有版本 ,避免發(fā)生版本丟失或混淆等現(xiàn)象 ,保證產(chǎn)品的可追溯性 . 在本方法中 ,根據(jù)配置項的狀態(tài)及其變遷 ,制定了版本標識規(guī)則與版本控制流程 . 配置狀態(tài)統(tǒng)計配置狀態(tài)統(tǒng)計記錄和報告管理 SCI 所需的信息 ,如基線和對基線的變更的實現(xiàn)狀態(tài) . 以便于開發(fā)人員及時地了解或查閱配置項的當前狀態(tài)和歷史版本 ,避免因溝通不當而造成的軟件開發(fā)版本的混亂 . 配置狀態(tài)統(tǒng)計的輸入數(shù)據(jù)包括 SCCB 決定 ,也包括 SCI和變更請求的狀態(tài)信息 . 輸出數(shù)據(jù)被格式化為配置狀態(tài)統(tǒng) 計報告 . 配置狀態(tài)統(tǒng)計一般包含如下形式的內(nèi)容 :記錄、變更請求表、庫詳細目錄表、數(shù)據(jù)分配表、發(fā)布表、文檔記錄表、報告等 . 配置審核配置審核主要作用是作為變更控制的補充手段 ,其目的是驗證軟件基準庫內(nèi)容的一致性和完整性 . 通常在每次產(chǎn)品發(fā)布之前 (即在里程碑評審后 ) 實施配置審核 . 執(zhí)行配置審核有以下活動 :(1) 組成審核小組 ,并明確各自的職責 .(2) 收集審核材料 ,確定審核內(nèi)容和日程安排 . (3) 進行功能審核 :檢驗軟件基準庫內(nèi)容是否一致 ,如驗證配置項的實際功能與軟件需求規(guī)格說明一致 ,確認當前基線配 置項的正確性 ,完整性 ,完備性 . (4) 進行物理審核 :檢驗軟件基準庫內(nèi)容是否完整 ,如驗證項目的配置管理工作是否符合適用的標準和規(guī)程 。驗證交付的產(chǎn)品確實包含所有必需的項目 ,如正確版本的源代碼、資源、文檔等 . (5) 形成配置審核報告 ,并上報相關(guān)人員 . (6) 跟蹤審核發(fā)現(xiàn)的問題的糾正措施直至問題解決 ,糾正情況記錄于《審核問題跟蹤記錄》中 . SCM 的對象是軟件研發(fā)活動中的全部開發(fā)資產(chǎn) . 因 SCM 覆蓋了整個軟件開發(fā)過程 ,故它是改進軟件過程、提高過程能力成熟度的理想切入點 . 隨著信息技術(shù)的不斷發(fā)展， 在軟件項目開發(fā)過程中形成大量的信息資源，如需求文檔、設(shè)計文檔、代碼、測試文檔、 原代碼、軟件說明書和手冊等。同時，軟件項目開發(fā)和維護是一個不斷增加、反復(fù)修改的過程，軟件項目不僅要求實現(xiàn)對文檔、代碼的增刪改、瀏覽、檢索和統(tǒng)計匯總等靜態(tài)管理，還需要記錄、跟蹤碩士學(xué)位論文 11 和回溯文檔、代碼的設(shè)計歷史，這對積累設(shè)計經(jīng)驗、實現(xiàn)軟件維護創(chuàng)新尤為重要。 所以，在軟件項目開發(fā)和維護過程中建立本企業(yè)的知識庫及經(jīng)驗庫 , 有效地控制和使用軟件信息資源，為開發(fā)維護人員提供一個實時的配置管理平臺，是軟件系統(tǒng)開發(fā)與實施的基礎(chǔ)。 1 軟 件項目開發(fā)和維護過程問題分析 版本難以控制軟件開發(fā)和維護過程的特點是連續(xù)性，從軟件項目立項、需求分析、總體設(shè)計到系統(tǒng)運維的過程中兼具功能變化和新增功能，或者適應(yīng)不同的環(huán)境（如不同的操作系統(tǒng)）、根據(jù)不同用戶的要求開發(fā)了特點各異的版本，這些版本之間存在大量的共享模塊（圖表、原代碼、文檔等等），經(jīng)過多人次修改后，發(fā)現(xiàn)實際有用的版本卻不知去向了。 資源變化頻繁企業(yè)的軟件開發(fā)過程中其資源急劇增加，由于沒有控制好軟件變化過程，項目經(jīng)過了幾次大改動，幾乎記不起原來是什么樣子了；根據(jù)用戶提出的多次變更要求 更改后的軟件，與用戶的需要相距甚遠，無法恢復(fù)原來的版本；如某維護人員未經(jīng)正常的軟件變化申請，自行修改軟件中的某一錯誤，雖然局部錯誤是改正了，但由于沒有考慮到局部改動對全局的影響，使得整個系統(tǒng)不能正常工作，造成開發(fā)過程的停滯。 配置審核問題對軟件開發(fā)和維護的變化沒有正常的審核過程，對于用戶所提出的變更要求，缺少必要的審查和確認程序，發(fā)布出去的產(chǎn)品中，缺少文檔，或者文檔與應(yīng)用不一致。 項目管理問題項目組成員間源代碼的更新和保存記錄變得越來越復(fù)雜，終端使用混亂，下層終端應(yīng)用軟件 存在多個版本或同一版本存放在不用路徑，給下層使用人員也帶來不便，造成終端操作人員在使用軟件過程中出現(xiàn)多次打開，數(shù)據(jù)重復(fù)上傳的現(xiàn)象，并且在問題出現(xiàn)時無法快速追蹤到故障原因。 軟件項目開發(fā)和維護過程中的配置管理技術(shù) 基本定義配置管理定義(configuration management) 主要解決軟件開發(fā)和軟件維護過程中的方法和規(guī)則，通過在特定的時刻選擇軟件配置，系統(tǒng)地控制 對配置的修改，并在整個軟件生命周期中維護配置的完整性和可追蹤性 。 開發(fā)原則軟件項目應(yīng)充分考慮其項目的特 點，配置管理定義軟件開發(fā)和維護過程應(yīng)遵循以下原則：①各個項目存儲庫的按類別進行定義，滿足對開發(fā)維護過程實施科學(xué)、有效、規(guī)范的管理；②版本管理標準化，按項目的生命周期過程進行版本控制管理（版號＋版次，如 A 文檔 ， 等），保持程序、文檔和數(shù)據(jù)的完整性和可追溯性；③支持團隊并行開發(fā)和異地開發(fā)，滿足用戶的不同要求；④查詢統(tǒng)計功能，可幫助管理層監(jiān)控、跟蹤、分析項目開發(fā)過程和結(jié)果；⑤軟件開發(fā)管理系統(tǒng)設(shè)計與實現(xiàn) 12 具備良好的可配置性、可維護性、適應(yīng)性 和具有版本管理及權(quán)限動態(tài)管理功能 。 在軟件開發(fā)這個龐大而復(fù)雜的過程中，需要涉及到各種文檔（ 包括需求文檔、技術(shù)文檔、數(shù)據(jù)、程序代碼等），而且在開發(fā)過程中往往涉及大量人員（包括項目經(jīng)理、需求調(diào)查人員、文檔書寫人員、軟件開發(fā)人員、軟件維護人員等。因此客戶需求的變動、系統(tǒng)結(jié)構(gòu)的變更都會導(dǎo)致對軟件的修改，小到可能只是對某個源文件中的某個變量的定義改動，大到重新設(shè)計程序模塊甚至可能是整個需求分析變動。本文提出的軟件配置管理流程模型能夠?qū)浖_發(fā)進行有效的配置管理，使軟件開發(fā)從初始混亂的過程過渡到可復(fù)用、可管理的有序化過程。 2. 軟件開發(fā)配置管理兩段模型的提出配置管理 (Configuration Management， CM)作為軟件工程的一個方面，在過去的 30 年內(nèi)得到了長足的發(fā)展。隨著自動化配置工具的不斷發(fā)展完善，配置管理手段逐步走向自動化方式。目前比較流行的 CM 工具有很多，例如： MicroSoft 公司的 VSS， RationalRose 公司的 ClearCase 等。這些 CM 工具大體上包括以下幾個方面的內(nèi)容：、版本控制：標識、記錄配置項的功能和物理特征。 變更控制（ Change Control）：是軟件配置管理的核心，它通過創(chuàng)建產(chǎn)品基線，在產(chǎn)品的整個生命周期中控制它的發(fā)布和變更。 配置狀態(tài)統(tǒng)計（ CSA， Configuration Status Accounting）涉及記錄和報告變更過程，持續(xù)地記錄配置的狀態(tài)以及保持基線產(chǎn)品和其變更建議的歷史，并使相關(guān)人員了解配置和基線的情況。 配置審計（ Configuration Audit）用來驗證配置管理過程，以保證配置庫中所有配置項的完整性。 然而對于分布于不同地點的開發(fā)人員來共同協(xié)作開發(fā)的大型軟件項目而言，配置管理是一項十分復(fù)雜的工作，而且目前可以應(yīng)用的自動化配置管理技術(shù)僅限于配置管理的幾個方面。對于一些大的開發(fā)項 目團隊來說，他們更傾向于擁有自己的開發(fā)配置管理系統(tǒng)，然而這一工作開銷卻異常巨大，往往維護配置管理系統(tǒng)的開銷比維護應(yīng)用程序開發(fā)更大。而且 CM 的解決方案只有 10%的技術(shù)成分，其余的則是管理過程和用戶培訓(xùn)。因此對于一個軟件開發(fā)項目來說，無論選擇何種策略和方法，配置管理的制定和實施都不是一件容易的事情。因此要實施配置管理，就必需引進良好管理模式。 3. 軟件開發(fā)配置管理的兩段模型軟件開發(fā)配置管理，是對軟件開發(fā)的過程進行的配置管理，是整個軟件生命周期中重要內(nèi)容。完整的軟件開發(fā)配置管理流程碩士學(xué)位論文 13 可以分為兩部分：制定 軟件配置管理方案和實施軟件配置管理方案。 制定流程要實現(xiàn)軟件配置管理，首先要根據(jù)需求分析文檔在開發(fā)組織中成立 CEB（ Configuration Establishment Board，配置構(gòu)造委員會），它是由負責人、配置管理專家，系統(tǒng)開發(fā)技術(shù)人員等成員臨時組成的配置構(gòu)造小組，負責配置管理方案制定過程中的所有工作。 CEB 通過分析用戶需求分析文檔，評估開發(fā)組織情況，從項目經(jīng)理或技術(shù)經(jīng)理或相關(guān)權(quán)威技術(shù)專家中挑選出部分人員，及邀請客戶組織中相關(guān)專業(yè)的專家組成 CCB（ ConfigurationControl Board，配置控制委員會），用以評審開發(fā)過程中的變更。下一步 CEB 制定出配置管理計劃，該計劃主管配置管理的領(lǐng)導(dǎo)審核，審核通過，發(fā)布該配置管理計劃，部署配置工具及配置庫，其后便可以進行項目開發(fā)了。之所以配置管理計劃的制定要在項目開始之前，是因為如果不在項目開始之初制定軟件配置管理計劃，那么軟件配置管理的許多關(guān)鍵活動就無法及時有效的進，而它的直接后果就是造成了項目開發(fā)狀況的混亂，并注定軟件配置管理活動將成為一種 救火 的行為。所以及時制定一份軟件配置管理計劃在一定程度上是項目成功的非常重要保證。 實施流程當配置管理方案制定并發(fā)布后，整個軟件開發(fā)工程就應(yīng)該嚴格按照該方案進行。管理方案的實施要由 CEB 指導(dǎo)來進行，在開發(fā)工程中，隨著配置管理的深入進行， CEB 的作用逐漸淡化，并最終解散。 一個配置管理實施的流程：當 一個軟件生命周期階段設(shè)計開始后，往往也是一個新的版本設(shè)計的開始。在開發(fā)工程中，由于客戶需求的變動、系統(tǒng)結(jié)構(gòu)的變更，會引起變更請求，變更請求交 CCB 審核， CCB 評估該變更所需要的成本和它對軟件系統(tǒng)其它部分的影響，以決定是否實施變更。若同意變更，則借助配置管理工具生 成配置狀態(tài)報告，并生成新的版本，繼續(xù)開發(fā)過程直至整個階段的完成。在階段設(shè)計結(jié)束時，應(yīng)該對配置項的變化信息進行配置審計，同時生成配置狀態(tài)報告，最后發(fā)布新的版本，生成該階的基線，完成該階段的設(shè)計。 .NET 技術(shù) MicroSoft .NET 平臺包括用于創(chuàng)建和操作新一代服務(wù)的 .NET 基礎(chǔ)結(jié)構(gòu)和工具；可以啟用大量客戶機的 .NET User Experience；用于建立新一代高度分布式的數(shù)以百萬計的 .NET 積木式組件服務(wù)；以及用于啟用新一代智能互聯(lián)網(wǎng)設(shè)備的 .NET 設(shè) 備軟件。 Dot Net 的框架是： 軟件開發(fā)管理系統(tǒng)設(shè)計與實現(xiàn) 14 .Net 環(huán)境中的突破性改進在于 ： 1． 使用統(tǒng)一的 Inter 標準（如 XML）將不同的系統(tǒng)對接； 2． 這是 Inter 上首個大規(guī)模的高度分布式應(yīng)用服務(wù)架構(gòu)； 3．使用了一個名為“聯(lián)盟”的管理程序，這個程序能全面管理平臺中運行的服務(wù)程序，并且為它們提供強大的安全保護后臺； .NET 平臺包括如下組件： 1．用戶數(shù)據(jù)訪問技術(shù)。其中包括一個新的基于 XML 的、以瀏覽器為組件的混合信息 架構(gòu)，