1、1,第9章 軟 件 維 護,2,第9章 軟件維護,9.1 軟件維護的定義 軟件維護 - 就是在軟件已經(jīng)交付使用之后，為了改正錯誤或滿足新的需要而修改軟件的過程。 維護的類型有四種： 改正性維護 適應性維護 擴充與完善性維護 預防性維護,3,1.改正性維護 - Corrective Maintenance 在軟件交付使用后，因開發(fā)時測試的不徹底、不完全，必然會有部分隱藏的錯誤遺留到運行階段。 這些隱藏下來的錯誤在某些特定的使用環(huán)境下就會暴露出來。 為了識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使用，所進行的診斷和改正錯誤的過程就叫做改正性維護。,4,2.適應性維護 - Adapti

2、ve Maintenance,在使用過程中， 外部環(huán)境（新的硬、軟件配置） 數(shù)據(jù)環(huán)境（數(shù)據(jù)庫、數(shù)據(jù)格式、數(shù)據(jù)輸入/輸出方式、數(shù)據(jù)存儲介質(zhì)） 可能發(fā)生變化。 為使軟件適應這種變化，而去修改軟件的過程就叫做適應性維護。,5,3.擴充與完善性維護 - Perfective Maintenance,在軟件的使用過程中，用戶往往會對軟件提出新的功能與性能要求。 為了滿足這些要求，需要修改或再開發(fā)軟件，以擴充軟件功能、增強軟件性能、改進加工效率、提高軟件的可維護性。 這種情況下進行的維護活動叫做擴充與完善性維護。,6,4.預防性維護 - Preventive Maintenance,預防性維護是為了提高軟

3、件的可維護性、可靠性等，為以后進一步改進軟件打下良好基礎(chǔ)。 預防性維護定義為：采用先進的軟件工程方法對需要維護的軟件或軟件中的某一部分（重新）進行設(shè)計、編制和測試。,7,各種維護所占比例:,其它維護 4 %,適應性維護 18% 25%,改正性維護 17% 21%,擴充與完善性維護 50% 60%,8,9.2 軟件維護的特點 - 影響維護工作量的因素,在軟件的維護過程中，需要花費大量的工作量，從而直接影響了軟件維護的成本。 應當考慮有哪些因素影響軟件維護的工作量，相應應該采取什么維護策略，才能有效地維護軟件并控制維護的成本。 系統(tǒng)大?。合到y(tǒng)越大，理解掌握起來越困難。系統(tǒng)越大，所執(zhí)行功能越復雜。因

4、而需要更多的維護工作量。 程序設(shè)計語言：使用強功能的程序設(shè)計語言可以控制程序的規(guī)模。語言的功能越強，生成程序的模塊化和結(jié)構(gòu)化程度越高，所需的指令數(shù)就越少，程序的可讀性越好。,9,系統(tǒng)年齡： 老系統(tǒng)隨著不斷的修改，結(jié)構(gòu)越來越亂； 維護人員經(jīng)常更換，程序又變得越來越難于理解 許多老系統(tǒng)在當初并未按照軟件工程的要求進行開發(fā)，因而沒有文檔，或文檔太少。 在長期的維護過程中文檔在許多地方與程序?qū)崿F(xiàn)變得不一致，在維護時就會遇到很大困難。 數(shù)據(jù)庫技術(shù)的應用：使用數(shù)據(jù)庫，可以簡單而有效地管理和存儲用戶程序中的數(shù)據(jù)，還可以減少生成用戶報表應用軟件的維護工作量。,10,先進的軟件開發(fā)技術(shù)：在軟件開發(fā)時，若使用能使

5、軟件結(jié)構(gòu)比較穩(wěn)定的分析與設(shè)計技術(shù)，及程序設(shè)計技術(shù)，如面向?qū)ο蠹夹g(shù)、復用技術(shù)等，可減少大量的工作量。 其它： 應用的類型 數(shù)學模型 任務的難度 開關(guān)與標記、IF嵌套深度、索引或下標數(shù)等 對維護工作量都有影響。 許多軟件在開發(fā)時并未考慮將來的修改，為軟件的維護帶來許多問題。,11,維護成本,有形的軟件維護成本是花費了多少錢，無形的維護成本有更大的影響。 一些合理的修復或修改請求不能及時安排，使得客戶不滿意； 變更的結(jié)果引入新的故障，使得軟件整體質(zhì)量下降； 把軟件人員抽調(diào)到維護工作中，干擾了軟件開發(fā)工作。,12,維護工作量的模型,M 是維護中消耗的總工作量 P 是生產(chǎn)性工作量 K 是一個經(jīng)驗常數(shù) c

6、 是因缺乏好的設(shè)計和文檔而導致復雜性的度量 d 是維護人員對軟件熟悉程度的度量 模型指明，如果使用了不好的軟件開發(fā)方法（未按軟件工程要求做），原來參加開發(fā)的人員或小組不能參加維護，則工作量（及成本）將按指數(shù)級增加。,13,維護中的典型問題,(1) 難以跟蹤軟件版本的進化過程,軟件的變化未在文檔中反映出來. (2) 難以跟蹤軟件的創(chuàng)建過程. (3) 難以讀懂他人程序. (4) 無文檔或不全. (5) 軟件人員流動性大. (6) 設(shè)計時未考慮修改需要,修改困難. 維護工作無吸引力,缺乏成就感. 采用軟件工程方法至少可部分地解決與維護有關(guān)的每一個問題。,14,9.3 軟件維護過程,維護過程本質(zhì)上是修

7、改和壓縮了的軟件定義和開發(fā)過程，而且事實上遠在提出一項維護要求之前，與軟件維護有關(guān)的工作已經(jīng)開始了。 為了有效地進行軟件維護，應事先就開始做組織工作。 首先建立維護的機構(gòu) 申明提出維護申請報告的過程及評價的過程 為每一個維護申請規(guī)定標準的處理步驟 建立維護活動的記錄保管，并規(guī)定復審的標準,15,1、維護機構(gòu),除了較大的軟件開發(fā)公司外，通常在軟件維護工作方面，并不保持一個正式的組織機構(gòu)。 雖然不要求建立一個正式的維護機構(gòu)，但是在開發(fā)部門確立一個非正式的維護機構(gòu)則是非常必要的。,16,每個維護要求都通過維護管理員轉(zhuǎn)交給相應的系統(tǒng)管理員去評價（系統(tǒng)管理員是被指定去熟悉一小部分產(chǎn)品程序的技術(shù)人員）。

8、系統(tǒng)管理員對維護任務做出評價之后，由變化授權(quán)人決定應該進行的活動。,17,2. 維護報告 應該用標準化的格式表達所有軟件維護申請（要求）。 維護申請報告或稱軟件問題報告，由申請維護的用戶填寫。 用戶必須完整地說明產(chǎn)生錯誤的情況，包括輸入數(shù)據(jù)、錯誤清單以及其它有關(guān)材料。 如果申請的是適應性維護或完善性維護，用戶必須提出一份修改說明書，列出所有希望的修改。,18,維護申請報告將由維護管理員和系統(tǒng)管理員來研究處理。 他們應相應地做出軟件修改報告，指明： 所需修改變動的性質(zhì)； 申請修改的優(yōu)先級； 為滿足某個維護申請報告，所需的工作量 預計修改后的狀況. 軟件修改報告應提交給變化授權(quán)人（修改負責人），經(jīng)

9、批準后才能開始進一步安排維護工作。,19,3. 維護的事件流,20,盡管維護申請的類型不同，但都要進行同樣的技術(shù)工作。 修改軟件需求說明 修改軟件設(shè)計 設(shè)計評審 對源程序做必要的修改 單元測試 集成測試( 回歸測試) 確認測試 軟件配置評審等。,21,在每次軟件維護任務完成后進行情況評審，對以下問題做一總結(jié)： (1) 在目前情況下，設(shè)計、編碼、測試中的哪一方面可以改進? (2) 哪些維護資源應該有但沒有? (3) 工作中主要的或次要的障礙是什么? (4) 從維護申請的類型來看是否應當有預防性維護? 情況評審對將來的維護工作如何進行會產(chǎn)生重要的影響。,22,4、維護檔案記錄,程序標識； 源語句數(shù)

10、； 機器指令條數(shù)； 使用的程序設(shè)計語言； 程序安裝的日期； 自從安裝以來程序運行的次數(shù)； 自從安裝以來程序失效的次數(shù)； 程序變動的層次和標識； 因程序變動而增加的源語句數(shù)；, 因程序變動而刪除的源語句數(shù)； 每個改動耗費的人時數(shù)； 程序改動的日期； 軟件工程師的名字； 維護要求表的標識； 維護類型； 維護開始和完成的日期； 累計用于維護的人時數(shù)； 與完成的維護相聯(lián)系的純效益。,23,5、維護評價,評價維護活動比較困難，因為缺乏可靠的數(shù)據(jù)。 如果維護的檔案記錄做得比較好，可以得出一些維護“性能”方面的度量值。 (1) 每次程序運行平均失效的次數(shù)； (2) 用于每一類維護活動的總?cè)藭r數(shù)； (3) 平

11、均每個程序、每種語言、每種維護類型所做的程序變動數(shù)； (4) 維護過程中增加或刪除一個源語句平均花費的人時數(shù)； (5) 維護每種語言平均花費的人時數(shù)； (6) 一張維護要求表的平均周轉(zhuǎn)時間； (7) 不同維護類型所占的百分比。 根據(jù)對維護工作定量度量的結(jié)果，可以做出關(guān)于開發(fā)技術(shù)、語言選擇、維護工作量規(guī)劃、資源分配及其他許多方面的決定，而且可以利用這樣的數(shù)據(jù)去分析評價維護任務。,24,6、程序修改的步驟及修改的副作用,在軟件維護時，必然會對源程序進行修改。 通常對源程序的修改不能無計劃地倉促上陣，為了正確、有效地修改,需要經(jīng)歷以下三個步驟。 分析和理解程序 修改程序 重新驗證程序,25,分析和理

12、解程序,經(jīng)過分析，全面、準確、迅速地理解程序是決定維護成敗和質(zhì)量好壞的關(guān)鍵。在這方面，軟件的可理解性和文檔的質(zhì)量非常重要。 理解程序的功能和目標； 掌握程序的結(jié)構(gòu)信息，即從程序中細分出若干結(jié)構(gòu)成分。如程序系統(tǒng)結(jié)構(gòu)、 控制結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)和輸入輸出結(jié)構(gòu)等；,26,了解數(shù)據(jù)流信息，即涉及到的數(shù)據(jù)來源何處，在哪里被使用； 了解控制流信息，即執(zhí)行每條路徑的結(jié)果； 理解程序的操作(使用)要求； 為了容易地理解程序，要求自頂向下地理解現(xiàn)有源程序的程序結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)，為此可采用如下幾種方法：,27,1. 分析程序結(jié)構(gòu)圖 (1) 搜集所有存儲該程序的文件，閱讀這些文件，記下它們包含的過程名，建立一個包括這些過程

13、名和文件名的清單； (2) 分析各個過程的源代碼，建立一個直接調(diào)用矩陣D或調(diào)用樹。若過程 i 調(diào)用過程 j，則Dij1，否則Dij0。,28,(3) 建立過程的間接調(diào)用矩陣I，即直接調(diào)用矩陣D的傳遞閉包 ID1D2D3Dn 其中，n是所包含的過程總數(shù). 例如，過程 i 調(diào)用 j，j 調(diào)用 k， 則 Dij1，Djk1， Iik1。 (4) 分析各個過程的接口，估計更改的復雜性。,29,2. 數(shù)據(jù)跟蹤 (1) 建立各層次的程序級上的接口圖，展示各模塊或過程的調(diào)用方式和接口參數(shù)； (2) 利用數(shù)據(jù)流分析方法，對過程內(nèi)部的一些變量進行跟蹤?？色@得有關(guān)數(shù)據(jù)在過程間如何傳遞，在過程內(nèi)如何處理等信息。對于

14、判斷問題原因特別有用。在跟蹤的過程中可在源程序中間插入自己的注釋。,30,3. 控制跟蹤 控制流跟蹤可采用符號執(zhí)行或?qū)嶋H動態(tài)跟蹤的方法，了解數(shù)據(jù)如何從一個輸入源到達輸出點的。 4. 充分閱讀和使用源程序清單和文檔，分析現(xiàn)有文檔的合理性。 5. 充分使用由編譯程序或匯編程序提供的交叉引用表、符號表、以及其它有用的信息。 6. 如有可能，積極參加開發(fā)工作。,31,修改程序,對程序的修改，必須事先做出計劃，有預謀地、周密有效地實施修改。 1. 設(shè)計程序的修改計劃 程序的修改計劃要考慮人員和資源的安排。小的修改可以不需要詳細的計劃，而對于需要耗時數(shù)月的修改，就需要計劃立案。,32,在編寫有關(guān)問題解決的

15、方案時，必須充分描述修改作業(yè)的規(guī)格說明。 規(guī)格說明信息：數(shù)據(jù)修改、處理修改、作業(yè)控制語言修改、系統(tǒng)之間接口的修改等； 維護資源：新程序版本、測試數(shù)據(jù)、所需軟件、計算機時間等； 人員； 支持：紙面、計算機媒體等。,33,通常，可采用自頂向下的方法，在理解程序的基礎(chǔ)上， (1) 研究程序的各個模塊、模塊的接口、及數(shù)據(jù)庫，從全局的觀點，提出修改計劃。 (2) 依次地把要修改的、以及那些受修改影響的模塊和數(shù)據(jù)結(jié)構(gòu)分離出來。為此，要 識別受修改影響的數(shù)據(jù)； 識別使用這些數(shù)據(jù)的程序模塊；,34, 對于上面程序模塊，按是產(chǎn)生數(shù)據(jù)、修改數(shù)據(jù)、還是刪除數(shù)據(jù)進行分類； 識別對這些數(shù)據(jù)元素的外部控制信息； 識別編輯

16、和檢查這些數(shù)據(jù)元素的地方； 隔離要修改的部分；,35,(3) 詳細地分析要修改的、以及那些受變更影響的模塊和數(shù)據(jù)結(jié)構(gòu)的內(nèi)部細節(jié)，設(shè)計修改計劃，標明新邏輯及要改動的現(xiàn)有邏輯。 (4) 向用戶提供回避措施。用戶的某些業(yè)務因軟件中發(fā)生問題而中斷，為不讓系統(tǒng)長時間停止運行，需把問題局部化，在可能的范圍內(nèi)繼續(xù)開展業(yè)務。 可以采取的措施有：,36, 查找問題原因，可能情況有： 意外停機 安裝的期限到期 系統(tǒng)運行中發(fā)現(xiàn)錯誤 如果弄清了問題的原因，可通過臨時修改或改變運行控制以回避在系統(tǒng)運行時產(chǎn)生的問題。,37,2. 修改代碼，以適應變化 在修改時，要求： (1) 正確、有效地編寫修改代碼； (2) 要謹慎地

17、修改程序，盡量保持程序的風格及格式，要在程序清單上注明改動的指令； (3) 不要刪除程序語句，除非完全肯定它是無用的； (4) 不要試圖共用程序中已有的臨時變量或工作區(qū)，為了避免沖突或混淆用途，應設(shè)置自己的變量；,38,(5) 插入錯誤檢測語句； (6) 在修改過程中做好修改的詳細記錄，消除變更中任何有害的副作用（波動效應）； 3. 修改程序的副作用 所謂副作用是指因修改軟件而造成的錯誤或其它不希望發(fā)生的情況。副作用有三種：修改代碼的副作用、修改數(shù)據(jù)的副作用、文檔的副作用。,39,在修改源代碼時，都可能引入錯誤。例如，刪除或修改一個子程序、刪除或修改一個標號、 刪除或修改一個標識符、改變程序代

18、碼的時序關(guān)系、改變占用存儲的大小、改變邏輯運算符、修改文件的打開或關(guān)閉、改進程序的執(zhí)行效率，以及把設(shè)計上的改變翻譯成代碼的改變時，都容易引入錯誤。,(1) 修改代碼的副作用,40,(2) 修改數(shù)據(jù)的副作用,在修改數(shù)據(jù)結(jié)構(gòu)時，有可能造成軟件設(shè)計與數(shù)據(jù)結(jié)構(gòu)不匹配，因而導致軟件出錯。 數(shù)據(jù)副作用就是修改軟件信息結(jié)構(gòu)導致的結(jié)果。 容易導致設(shè)計與數(shù)據(jù)不相容的錯誤可以有： 重新定義局部的或全局的常量,41,重新定義記錄或文件的格式 增大或減小一個數(shù)組或高層數(shù)據(jù)結(jié)構(gòu)的大小 修改全局或公共數(shù)據(jù) 重新初始化控制標志或指針 重新排列輸入輸出或子程序的參數(shù) 數(shù)據(jù)副作用可以通過交叉引用表加以控制。把數(shù)據(jù)元素、記錄、文

19、件和其它結(jié)構(gòu)聯(lián)系起來。,42,(3) 文檔的副作用,對數(shù)據(jù)流、軟件結(jié)構(gòu)、 模塊邏輯或任何其它有關(guān)特性進行修改時，必須對相關(guān)技術(shù)文檔進行相應修改。否則會導致文檔與程序功能不匹配，缺省條件改變，新錯誤信息不正確等錯誤。使得軟件文檔不能反映軟件的當前狀態(tài)。 對于用戶來說，軟件事實上就是文檔。,43,如果對可執(zhí)行軟件的修改不反映在文檔里，就會產(chǎn)生文檔的副作用。 對交互輸入的順序或格式進行修改，如果沒有正確地記入文檔中，就可能引起重大的問題。 過時的文檔內(nèi)容、索引和文本可能造成沖突，引起用戶失敗和不滿。 因此，必須在軟件交付之前對整個軟件配置進行評審，以減少文檔的副作用。,44,為了控制因修改而引起的副

20、作用，要做到： (1) 按模塊把修改分組； (2) 自頂向下地安排被修改模塊的順序； (3) 每次修改一個模塊； (4) 對于每個修改了的模塊，在安排修改下一個模塊之前，要確定這個修改的副作用。可以使用交叉引用表、存儲映象表、執(zhí)行流程跟蹤等。,45,重新驗證程序,在將修改后的程序提交用戶之前，需要進行充分的確認和測試，以保證整個修改后程序的正確性。 靜態(tài)確認 修改軟件，伴隨著引起新的錯誤的危險。為了能夠做出正確的判斷，驗證修改后的程序至少需要兩個人參加。要檢查：,46,(1) 修改是否涉及到規(guī)格說明? 修改結(jié)果是否符合規(guī)格說明? 有沒有歪曲規(guī)格說明? (2) 程序的修改是否足以修正軟件中的問題

21、? 源程序代碼有無邏輯錯誤? 修改時有無修補失誤? (3) 修改部分對其它部分有無不良影響(副作用)? 對軟件進行修改，常常會引發(fā)別的問題，有必要檢查修改的影響范圍。,47,計算機確認 在進行了以上確認的基礎(chǔ)上，用計算機對修改程序進行確認測試： (1) 確認測試順序：先對修改部分進行測試，然后隔離修改部分，測試程序的未修改部分，最后再把它們集成起來進行測試。這種測試稱為回歸測試。 (2) 準備標準的測試用例。 (3) 充分利用軟件工具幫助重新驗證過程。,48,(4) 在重新確認過程中，需邀請用戶參加。 維護后的驗收在交付新軟件之前，維護主管部門要檢驗： (1) 全部文檔是否完備，并已更新； (

22、2) 所有測試用例和測試結(jié)果已經(jīng)正確記載； (3) 記錄軟件配置所有副本的工作已經(jīng)完成； (4) 維護工序和責任已經(jīng)確定。,49,從維護角度來看所需測試種類,(1) 對修改事務的測試； (2) 對修改程序的測試； (3) 操作過程的測試； (4) 應用系統(tǒng)運用過程的測試； (5) 系統(tǒng)各部分之間接口的測試； (6) 作業(yè)控制語言的測試； (7) 與系統(tǒng)軟件接口的測試；,50,(8) 軟件系統(tǒng)之間接口的測試； (9) 安全性測試； (10) 后備恢復過程的測試。,51,9.4 軟件的可維護性,許多軟件的維護十分困難，原因在于這些軟件的文檔不全、質(zhì)量差、開發(fā)過程不注意采用好的方法，忽視程序設(shè)計風格

23、等。 許多維護要求并不是因為程序中出錯而提出的，而是為適應環(huán)境變化或需求變化而提出的。 為了使得軟件能夠易于維護，必須考慮使軟件具有可維護性。 軟件可維護性是指糾正軟件系統(tǒng)出現(xiàn)的錯誤和缺陷，以及為滿足新的要求進行修改、擴充或壓縮的容易程度。,52,9.4.1 決定軟件可維護性的因素,1. 可理解性 2. 可測試性 3. 可修改性 4. 可移植性 5. 可重用性,53,9.4.2 文 檔,文檔是影響軟件可維護性的決定因素。往往文檔比程序代碼更重要。 軟件系統(tǒng)的文檔可以分為用戶文檔和系統(tǒng)文檔兩類。 - 用戶文檔主要描述系統(tǒng)功能和使用 方法，并不關(guān)心這些功能是怎樣實現(xiàn)的； - 系統(tǒng)文檔描述系統(tǒng)設(shè)計、

24、實現(xiàn)和測試等各方面的內(nèi)容。,54,軟件文檔應該滿足下述要求： (1) 必須描述如何使用這個系統(tǒng)，沒有這種描述時即使是最簡單的系統(tǒng)也無法使用； (2) 必須描述怎樣安裝和管理這個系統(tǒng)； (3) 必須描述系統(tǒng)需求和設(shè)計； (4) 必須描述系統(tǒng)的實現(xiàn)和測試，以便使系統(tǒng)成為可維護的。,55,1. 用戶文檔 用戶文檔是用戶了解系統(tǒng)的第一步，它應該能使用戶獲得對系統(tǒng)的準確的初步印象。文檔的結(jié)構(gòu)方式應該使用戶能夠方便地根據(jù)需要閱讀有關(guān)的內(nèi)容。 用戶文檔至少應該包括下述5方面的內(nèi)容： (1) 功能描述； (2) 安裝文檔； (3) 使用手冊； (4) 參考手冊； (5) 操作員指南(如果需要有系統(tǒng)操作員的話)

25、 。 上述內(nèi)容可以分別作為獨立的文檔， 也可以作為一個文檔的不同分冊， 具體做法應該由系統(tǒng)規(guī)模決定。,56,2. 系統(tǒng)文檔 - 所謂系統(tǒng)文檔指從問題定義、需求說明到驗收測試計劃這樣一系列和系統(tǒng)實現(xiàn)有關(guān)的文檔。 - 描述系統(tǒng)設(shè)計、實現(xiàn)和測試的文檔對于理解程序和維護程序來說是極端重要的。 - 和用戶文檔類似，系統(tǒng)文檔的結(jié)構(gòu)也應該能把讀者從對系統(tǒng)概貌的了解，引導到對系統(tǒng)每個方面每個特點的更形式化更具體的認識。,57,9.4.3 提高可維護性的方法,建立明確的軟件質(zhì)量目標和優(yōu)先級 使用提高軟件質(zhì)量的技術(shù)和工具 進行明確的質(zhì)量保證審查 選擇可維護的程序設(shè)計語言 改進程序的文檔,58,9.4.4 可維護性

26、復審,在軟件工程過程的每一個階段都應該考慮并努力提高軟件的可維護性，在每個階段結(jié)束前的技術(shù)審查和管理復審中，應該著重對可維護性進行復審。,59,在完成了每項維護工作之后，都應該對軟件維護本身進行仔細認真的復審。 - 維護應該針對整個軟件配置，不應該只修改源程序代碼。當對源程序代碼的修改沒有反映在設(shè)計文檔或用戶手冊中時，就會產(chǎn)生嚴重的后果。 - 每當對數(shù)據(jù)、軟件結(jié)構(gòu)、模塊過程或任何其他有關(guān)的軟件特點做了改動時，必須立即修改相應的技術(shù)文檔。不能準確反映軟件當前狀態(tài)的設(shè)計文檔可能比完全沒有文檔更壞。 - 用戶通常根據(jù)描述軟件特點和使用方法的用戶文檔來使用、評價軟件。如果對軟件的可執(zhí)行部分的修改沒有及

27、時反映在用戶文檔中，則必然會使用戶因為受挫折而產(chǎn)生不滿。,60,9.5 預防性維護,預防性維護方法是由Miller提出來的，他把這種方法定義為：“把今天的方法學應用到昨天的系統(tǒng)上，以支持明天的需求?！?開發(fā)和維護者不應等待用戶的維護申請,在條件具備時應該主動地進行預防性維護。 預防性維護對象: 預計若干年內(nèi)將繼續(xù)使用的程序 當今正成功使用的程序 最近的將來要進行大修改和完善的程序,61,9.6 軟件配置管理 （SCM ） Software Configuration Management,在開發(fā)軟件的過程中，變化（或稱為變動）既是必要的，又是不可避免的。但是，變化也很容易失去控制，如果不能適當

28、地控制和管理變化，勢必造成混亂并產(chǎn)生許多嚴重的錯誤。 軟件配置管理是在軟件的整個生命期內(nèi)管理變化的一組活動 標識變化； 控制變化； 確保適當?shù)貙崿F(xiàn)了變化； 向需要知道這類信息的人報告變化。 配置管理是在軟件項目啟動時就開始，并且一直持續(xù)到軟件退役后才終止的一組跟蹤和控制活動。 軟件配置管理的目標是，使變化更正確且更容易被適應，在必須變化時減少所需花費的工作量。,62,9.6.1 軟件配置項,1. 軟件配置項 計算機程序（源代碼和可執(zhí)行程序）； 描述計算機程序的文檔（供技術(shù)人員或用戶使用）； 數(shù)據(jù)（程序內(nèi)包含的或在程序外的）。 為了開發(fā)出高質(zhì)量的軟件產(chǎn)品，軟件開發(fā)人員不僅要努力保證每個軟件配置項

29、正確，而且必須保證一個軟件的所有配置項是完全一致的。,63,2. 基線 IEEE把基線定義為： 已經(jīng)通過了正式復審的規(guī)格說明或中間產(chǎn)品，它可以作為進一步開發(fā)的基礎(chǔ)，并且只有通過正式的變化控制過程才能改變它。 基線（Baseline）由一組配置項組成，這些配置項構(gòu)成了一個相對穩(wěn)定的邏輯實體?；€中的配置項被“凍結(jié)”了，不能再被任何人隨意修改（見變更控制規(guī)程）。 基線通常對應于開發(fā)過程中的里程碑（Milestone），一個產(chǎn)品可以有多個基線，也可以只有一個基線。基線的主要屬性有：名稱、標識符、版本、日期等。 通常將交付給客戶的基線稱為一個“Release”，為內(nèi)部開發(fā)用的基線則稱為一個“Build

30、”。,64,9.6.2 軟件配置管理過程,1、 標識配置項 2、 進行配置控制 3、 執(zhí)行配置審計 4、 記錄配置狀態(tài) 配置控制是核心： 存取控制（開發(fā)庫、基線庫、產(chǎn)品庫） 版本控制 變更控制 產(chǎn)品發(fā)布控制,65,9.6.3 常用配置管理工具,1、 SourceSafe SourceSafe是Microsoft公司推出的配置管理工具，是Visual Studio的套件之一。SourceSafe是國內(nèi)最流行的配置管理工具，用戶量絕對是第一位。 SourceSafe長得很象早先土氣的文件管理器，的確難看。但是難看不礙事，SourceSafe的優(yōu)點可以用8個字來概括“簡單易用，一學就會”，這個優(yōu)點是

31、它老媽Microsoft遺傳下來的，是天生的。 雖然SourceSafe并不是免費的，但是在國內(nèi)人們以接近于零的成本得到它，網(wǎng)上到處可以下載啊。當然Microsoft也不在乎這個小不點的軟件，它屬于“買大件送小件”的角色。如果你合法地得到Visual Studio，你就得到了免費的SourceSafe。 SourceSafe的主要局限性： 只能在Windows下運行，不能在Unix, Linux下運行。SourceSafe不支持異構(gòu)環(huán)境下的配置管理，對用戶而言是個麻煩事。這不是技術(shù)問題，是微軟公司產(chǎn)品戰(zhàn)略決定的。 適合于局域網(wǎng)內(nèi)的用戶群，不適合于通過Internet連接的用戶群，因為Sourc

32、eSafe是通過“共享目錄”方式存儲文件的。,66,2 、CVS CVS 是 Concurrent Version System（并行版本系統(tǒng)）的縮寫，它是著名的開放源代碼的配置管理工具。 CVS的官方網(wǎng)站是/ 。官方提供的是CVS服務器和命令行程序，但是官方并不提供交互式的客戶端軟件。許多軟件機構(gòu)根據(jù)CVS官方提供的編程接口開發(fā)了各色各樣的CVS客戶端軟件，最有名的當推Windows環(huán)境的CVS客戶端軟件WinCVS。WinCVS是免費的，但是并不開放源代碼。 與SourceSafe相比，CVS的主要優(yōu)點是： SourceSafe有的功能CVS全都有，CVS支持并發(fā)的版本管理，SourceSafe沒有并發(fā)功能。CVS服務器的功能和性能都比SourceSafe高出一籌。 CVS服務器是用Java編寫的，可以在任何操作系統(tǒng)和網(wǎng)絡環(huán)境下運行。CVS深受Unix和Linux 的用戶喜愛。Borland公司的JBuilder提供了CVS的插件，Java程序員可以在JBuilder集成環(huán)境中使用CVS進行版本控制。 CVS服務器有自己專用的數(shù)據(jù)庫，文件存儲并不采用SourceSafe的“共享目錄”方式，所以不受限于局域網(wǎng)，信息安全性很好。 CVS的主要缺點在于客戶端軟件，真可謂五花八門