軟件工程導(dǎo)論第8章課件

1、軟件工程導(dǎo)論第8章,第8章 維護(hù),8.1 軟件維護(hù)的定義 8.2 軟件維護(hù)的特點(diǎn) 8.3 軟件維護(hù)過程 8.4 軟件的可維護(hù)性 8.5 預(yù)防性維護(hù) 8.6 軟件再工程過程 8.7 小結(jié) 習(xí)題,軟件工程導(dǎo)論第8章,在軟件產(chǎn)品被開發(fā)出來并交付用戶使用之后，就進(jìn)入了軟件的運(yùn)行維護(hù)階段。這個階段是軟件生命周期的最后一個階段，其基本任務(wù)是保證軟件在一個相當(dāng)長的時期能夠正常運(yùn)行。 軟件維護(hù)需要的工作量很大，平均說來，大型軟件的維護(hù)成本高達(dá)開發(fā)成本的4倍左右。目前國外許多軟件開發(fā)組織把60%以上的人力用于維護(hù)已有的軟件，而且隨著軟件數(shù)量增多和使用壽命延長，這個百分比還在持續(xù)上升。將來維護(hù)工作甚至可能會束縛住

2、軟件開發(fā)組織的手腳，使他們沒有余力開發(fā)新的軟件。 軟件工程的目的是要提高軟件的可維護(hù)性，減少軟件維護(hù)所需要的工作量，降低軟件系統(tǒng)的總成本,軟件工程導(dǎo)論第8章,所謂軟件維護(hù)就是在軟件已經(jīng)交付使用之后，為了改正錯誤或滿足新的需要而修改軟件的過程?？梢酝ㄟ^描述軟件交付使用后可能進(jìn)行的4項(xiàng)活動，具體地定義軟件維護(hù)。 因?yàn)檐浖y試不可能暴露出一個大型軟件系統(tǒng)中所有潛藏的錯誤，所以必然會有第一項(xiàng)維護(hù)活動：在任何大型程序的使用期間，用戶必然會發(fā)現(xiàn)程序錯誤，并且把他們遇到的問題報告給維護(hù)人員。把診斷和改正錯誤的過程稱為改正性維護(hù),8.1 軟件維護(hù)的定義,軟件工程導(dǎo)論第8章,計算機(jī)科學(xué)技術(shù)領(lǐng)域的各個方面都在迅速

3、進(jìn)步，大約每過36個月就有新一代的硬件宣告出現(xiàn)，經(jīng)常推出新操作系統(tǒng)或舊系統(tǒng)的修改版本，時常增加或修改外部設(shè)備和其他系統(tǒng)部件；另一方面，應(yīng)用軟件的使用壽命卻很容易超過10年，遠(yuǎn)遠(yuǎn)長于最初開發(fā)這個軟件時的運(yùn)行環(huán)境的壽命。因此，適應(yīng)性維護(hù)，也就是為了和變化了的環(huán)境適當(dāng)?shù)嘏浜隙M(jìn)行的修改軟件的活動，是既必要又經(jīng)常的維護(hù)活動,軟件工程導(dǎo)論第8章,當(dāng)一個軟件系統(tǒng)順利地運(yùn)行時，常常出現(xiàn)第三項(xiàng)維護(hù)活動：在使用軟件的過程中用戶往往提出增加新功能或修改已有功能的建議，還可能提出一般性的改進(jìn)意見。為了滿足這類要求，需要進(jìn)行完善性維護(hù)。這項(xiàng)維護(hù)活動通常占軟件維護(hù)工作的大部分。 當(dāng)為了改進(jìn)未來的可維護(hù)性或可靠性，或?yàn)榱?/p>

4、給未來的改進(jìn)奠定更好的基礎(chǔ)而修改軟件時，出現(xiàn)了第四項(xiàng)維護(hù)活動。這項(xiàng)維護(hù)活動通常稱為預(yù)防性維護(hù)，目前這項(xiàng)維護(hù)活動相對比較少,軟件工程導(dǎo)論第8章,從上述關(guān)于軟件維護(hù)的定義不難看出，軟件維護(hù)絕不僅限于糾正使用中發(fā)現(xiàn)的錯誤，事實(shí)上在全部維護(hù)活動中一半以上是完善性維護(hù)。國外的統(tǒng)計數(shù)字表明，完善性維護(hù)占全部維護(hù)活動的50%66%，改正性維護(hù)占17%21%，適應(yīng)性維護(hù)占18%25%，其他維護(hù)活動只占4%左右。 應(yīng)該注意，上述4類維護(hù)活動都必須應(yīng)用于整個軟件配置，維護(hù)軟件文檔和維護(hù)軟件的可執(zhí)行代碼是同樣重要的,軟件工程導(dǎo)論第8章,1. 非結(jié)構(gòu)化維護(hù),8.2 軟件維護(hù)的特點(diǎn) 8.2.1 結(jié)構(gòu)化維護(hù)與非結(jié)構(gòu)化維護(hù)

5、差別巨大,軟件工程導(dǎo)論第8章,如果軟件配置的惟一成分是程序代碼，那么維護(hù)活動從艱苦地評價程序代碼開始，而且常常由于程序內(nèi)部文檔不足而使評價更困難，對于軟件結(jié)構(gòu)、全程數(shù)據(jù)結(jié)構(gòu)、系統(tǒng)接口、性能和(或)設(shè)計約束等經(jīng)常會產(chǎn)生誤解，而且對程序代碼所做的改動的后果也是難于估量的：因?yàn)闆]有測試方面的文檔，所以不可能進(jìn)行回歸測試(即指為了保證所做的修改沒有在以前可以正常使用的軟件功能中引入錯誤而重復(fù)過去做過的測試)。非結(jié)構(gòu)化維護(hù)需要付出很大代價(浪費(fèi)精力并且遭受挫折的打擊)，這種維護(hù)方式是沒有使用良好定義的方法學(xué)開發(fā)出來的軟件的必然結(jié)果,軟件工程導(dǎo)論第8章,2. 結(jié)構(gòu)化維護(hù) 如果有一個完整的軟件配置存在，那么

6、維護(hù)工作從評價設(shè)計文檔開始，確定軟件重要的結(jié)構(gòu)特點(diǎn)、性能特點(diǎn)以及接口特點(diǎn)；估量要求的改動將帶來的影響，并且計劃實(shí)施途徑。然后首先修改設(shè)計并且對所做的修改進(jìn)行仔細(xì)復(fù)查。接下來編寫相應(yīng)的源程序代碼；使用在測試說明書中包含的信息進(jìn)行回歸測試；最后，把修改后的軟件再次交付使用,軟件工程導(dǎo)論第8章,剛才描述的事件構(gòu)成結(jié)構(gòu)化維護(hù)，它是在軟件開發(fā)的早期應(yīng)用軟件工程方法學(xué)的結(jié)果。雖然有了軟件的完整配置并不能保證維護(hù)中沒有問題，但是確實(shí)能減少精力的浪費(fèi)并且能提高維護(hù)的總體質(zhì)量,軟件工程導(dǎo)論第8章,在過去的幾十年中，軟件維護(hù)的費(fèi)用穩(wěn)步上升。1970年用于維護(hù)已有軟件的費(fèi)用只占軟件總預(yù)算的35%40%，1980年上

7、升為40%60%，1990年上升為70%80%。 維護(hù)費(fèi)用只不過是軟件維護(hù)的最明顯的代價，其他一些現(xiàn)在還不明顯的代價將來可能更為人們所關(guān)注。因?yàn)榭捎玫馁Y源必須供維護(hù)任務(wù)使用，以致耽誤甚至喪失了開發(fā)的良機(jī)，這是軟件維護(hù)的一個無形的代價。其他無形的代價還有,8.2.2 維護(hù)的代價高昂,軟件工程導(dǎo)論第8章,當(dāng)看來合理的有關(guān)改錯或修改的要求不能及時滿足時將引起用戶不滿； 由于維護(hù)時的改動，在軟件中引入了潛伏的錯誤，從而降低了軟件的質(zhì)量； 當(dāng)必須把軟件工程師調(diào)去從事維護(hù)工作時，將在開發(fā)過程中造成混亂。 軟件維護(hù)的最后一個代價是生產(chǎn)率的大幅度下降，這種情況在維護(hù)舊程序時常常遇到,軟件工程導(dǎo)論第8章,用于維

8、護(hù)工作的勞動可以分成生產(chǎn)性活動(例如，分析評價，修改設(shè)計和編寫程序代碼等)和非生產(chǎn)性活動(例如，理解程序代碼的功能，解釋數(shù)據(jù)結(jié)構(gòu)、接口特點(diǎn)和性能限度等)。下述表達(dá)式給出維護(hù)工作量的一個模型：M=P+Kexp(c-d) 其中： M是維護(hù)用的總工作量，P是生產(chǎn)性工作量，K是經(jīng)驗(yàn)常數(shù)，c是復(fù)雜程度(非結(jié)構(gòu)化設(shè)計和缺少文檔都會增加軟件的復(fù)雜程度)，d是維護(hù)人員對軟件的熟悉程度。 上面的模型表明，如果軟件的開發(fā)途徑不好(即，沒有使用軟件工程方法學(xué))，而且原來的開發(fā)人員不能參加維護(hù)工作，那么維護(hù)工作量和費(fèi)用將指數(shù)地增加,軟件工程導(dǎo)論第8章,與軟件維護(hù)有關(guān)的絕大多數(shù)問題，都可歸因于軟件定義和軟件開發(fā)的方法有

9、缺點(diǎn)。在軟件生命周期的頭兩個時期沒有嚴(yán)格而又科學(xué)的管理和規(guī)劃，幾乎必然會導(dǎo)致在最后階段出現(xiàn)問題。下面列出和軟件維護(hù)有關(guān)的部分問題： （1） 理解別人寫的程序通常非常困難，而且困難程度隨著軟件配置成分的減少而迅速增加。如果僅有程序代碼沒有說明文檔，則會出現(xiàn)嚴(yán)重的問題,8.2.3 維護(hù)的問題很多,軟件工程導(dǎo)論第8章,2） 需要維護(hù)的軟件往往沒有合格的文檔，或者文檔資料顯著不足。認(rèn)識到軟件必須有文檔僅僅是第一步，容易理解的并且和程序代碼完全一致的文檔才真正有價值。 （3） 當(dāng)要求對軟件進(jìn)行維護(hù)時，不能指望由開發(fā)人員給我們仔細(xì)說明軟件。由于維護(hù)階段持續(xù)的時間很長，因此，當(dāng)需要解釋軟件時，往往原來寫程序

10、的人已經(jīng)不在附近了。 （4） 絕大多數(shù)軟件在設(shè)計時沒有考慮將來的修改。除非使用強(qiáng)調(diào)模塊獨(dú)立原理的設(shè)計方法學(xué)，否則修改軟件既困難又容易發(fā)生差錯,軟件工程導(dǎo)論第8章,5） 軟件維護(hù)不是一項(xiàng)吸引人的工作。形成這種觀念很大程度上是因?yàn)榫S護(hù)工作經(jīng)常遭受挫折。 上述種種問題在現(xiàn)有的沒采用軟件工程思想開發(fā)出來的軟件中，都或多或少地存在著。不應(yīng)該把一種科學(xué)的方法學(xué)看做萬應(yīng)靈藥，但是，軟件工程至少部分地解決了與維護(hù)有關(guān)的每一個問題,軟件工程導(dǎo)論第8章,維護(hù)過程本質(zhì)上是修改和壓縮了的軟件定義和開發(fā)過程，而且事實(shí)上遠(yuǎn)在提出一項(xiàng)維護(hù)要求之前，與軟件維護(hù)有關(guān)的工作已經(jīng)開始了。首先必須建立一個維護(hù)組織，隨后必須確定報告和

11、評價的過程，而且必須為每個維護(hù)要求規(guī)定一個標(biāo)準(zhǔn)化的事件序列。此外，還應(yīng)該建立一個適用于維護(hù)活動的記錄保管過程，并且規(guī)定復(fù)審標(biāo)準(zhǔn),8.3 軟件維護(hù)過程,軟件工程導(dǎo)論第8章,1. 維護(hù)組織 雖然通常并不需要建立正式的維護(hù)組織，但是，即使對于一個小的軟件開發(fā)團(tuán)體而言，非正式地委托責(zé)任也是絕對必要的。每個維護(hù)要求都通過維護(hù)管理員轉(zhuǎn)交給相應(yīng)的系統(tǒng)管理員去評價。系統(tǒng)管理員是被指定去熟悉一小部分產(chǎn)品程序的技術(shù)人員。系統(tǒng)管理員對維護(hù)任務(wù)做出評價之后，由變化授權(quán)人決定應(yīng)該進(jìn)行的活動。圖8.1描繪了上述組織方式。 在維護(hù)活動開始之前就明確維護(hù)責(zé)任是十分必要的，這樣做可以大大減少維護(hù)過程中可能出現(xiàn)的混亂,軟件工程導(dǎo)

12、論第8章,圖8.1 維護(hù)組織,軟件工程導(dǎo)論第8章,2. 維護(hù)報告 應(yīng)該用標(biāo)準(zhǔn)化的格式表達(dá)所有軟件維護(hù)要求。軟件維護(hù)人員通常給用戶提供空白的維護(hù)要求表有時稱為軟件問題報告表，這個表格由要求一項(xiàng)維護(hù)活動的用戶填寫。如果遇到了一個錯誤，那么必須完整描述導(dǎo)致出現(xiàn)錯誤的環(huán)境(包括輸入數(shù)據(jù)、全部輸出數(shù)據(jù)以及其他有關(guān)信息)。對于適應(yīng)性或完善性的維護(hù)要求，應(yīng)該提出一個簡短的需求說明書。如前所述，由維護(hù)管理員和系統(tǒng)管理員評價用戶提交的維護(hù)要求表,軟件工程導(dǎo)論第8章,維護(hù)要求表是一個外部產(chǎn)生的文件，它是計劃維護(hù)活動的基礎(chǔ)。軟件組織內(nèi)部應(yīng)該制定出一個軟件修改報告，它給出下述信息： (1) 滿足維護(hù)要求表中提出的要求

13、所需要的工作量； (2) 維護(hù)要求的性質(zhì)； (3) 這項(xiàng)要求的優(yōu)先次序； (4) 與修改有關(guān)的事后數(shù)據(jù)。 在擬定進(jìn)一步的維護(hù)計劃之前，把軟件修改報告提交給變化授權(quán)人審查批準(zhǔn),軟件工程導(dǎo)論第8章,3. 維護(hù)的事件流 圖8.2描繪了由一項(xiàng)維護(hù)要求而引出的一串事件。首先應(yīng)該確定要求進(jìn)行的維護(hù)的類型。用戶常常把一項(xiàng)要求看作是為了改正軟件的錯誤(改正性維護(hù))，而開發(fā)人員可能把同一項(xiàng)要求看作是適應(yīng)性或完善性維護(hù)。當(dāng)存在不同意見時必須協(xié)商解決,軟件工程導(dǎo)論第8章,圖8.2 維護(hù)階段的事件流,軟件工程導(dǎo)論第8章,從圖8.2描繪的事件流看到，對一項(xiàng)改正性維護(hù)要求(圖中“錯誤”通路)的處理，從估量錯誤的嚴(yán)重程度開

14、始。如果是一個嚴(yán)重的錯誤(例如，一個關(guān)鍵性的系統(tǒng)不能正常運(yùn)行)，則在系統(tǒng)管理員的指導(dǎo)下分派人員，并且立即開始問題分析過程。如果錯誤并不嚴(yán)重，那么改正性的維護(hù)和其他要求軟件開發(fā)資源的任務(wù)一起統(tǒng)籌安排。 適應(yīng)性維護(hù)和完善性維護(hù)的要求沿著相同的事件流通路前進(jìn)。應(yīng)該確定每個維護(hù)要求的優(yōu)先次序，并且安排要求的工作時間，就好像它是另一個開發(fā)任務(wù)一樣(從所有意圖和目標(biāo)來看，它都屬于開發(fā)工作)。如果一項(xiàng)維護(hù)要求的優(yōu)先次序非常高，可能立即開始維護(hù)工作,軟件工程導(dǎo)論第8章,不管維護(hù)類型如何，都需要進(jìn)行同樣的技術(shù)工作。這些工作包括修改軟件設(shè)計、復(fù)查、必要的代碼修改、單元測試和集成測試(包括使用以前的測試方案的回歸測

15、試)、驗(yàn)收測試和復(fù)審。不同類型的維護(hù)強(qiáng)調(diào)的重點(diǎn)不同，但是基本途徑是相同的。維護(hù)事件流中最后一個事件是復(fù)審，它再次檢驗(yàn)軟件配置的所有成分的有效性，并且保證事實(shí)上滿足了維護(hù)要求表中的要求。 當(dāng)然，也有并不完全符合上述事件流的維護(hù)要求。當(dāng)發(fā)生惡性的軟件問題時，就出現(xiàn)所謂的“救火”維護(hù)要求，這種情況需要立即把資源用來解決問題。如果對一個組織來說，“救火”是常見的過程，那么必須懷疑它的管理能力和技術(shù)能力,軟件工程導(dǎo)論第8章,在完成軟件維護(hù)任務(wù)之后，進(jìn)行處境復(fù)查常常是有好處的。一般說來，這種復(fù)查試圖回答下述問題： 在當(dāng)前處境下設(shè)計、編碼或測試的哪些方面能用不同方法進(jìn)行? 哪些維護(hù)資源是應(yīng)該有而事實(shí)上卻沒有

16、的? 對于這項(xiàng)維護(hù)工作什么是主要的(以及次要的)障礙? 要求的維護(hù)類型中有預(yù)防性維護(hù)嗎? 處境復(fù)查對將來維護(hù)工作的進(jìn)行有重要影響，而且所提供的反饋信息對有效地管理軟件組織十分重要,軟件工程導(dǎo)論第8章,4. 保存維護(hù)記錄 對于軟件生命周期的所有階段而言，以前記錄保存都是不充分的，而軟件維護(hù)則根本沒有記錄保存下來。由于這個原因，往往不能估價維護(hù)技術(shù)的有效性，不能確定一個產(chǎn)品程序的“優(yōu)良”程度，而且很難確定維護(hù)的實(shí)際代價是什么,軟件工程導(dǎo)論第8章,保存維護(hù)記錄遇到的第一個問題就是，哪些數(shù)據(jù)是值得記錄的?Swanson提出了下述內(nèi)容： (1)程序標(biāo)識；(2)源語句數(shù)；(3)機(jī)器指令條數(shù)；(4)使用的程

17、序設(shè)計語言；(5)程序安裝的日期；(6)自從安裝以來程序運(yùn)行的次數(shù)；(7)自從安裝以來程序失效的次數(shù)；(8)程序變動的層次和標(biāo)識；(9)因程序變動而增加的源語句數(shù)； (10)因程序變動而刪除的源語句數(shù)； (11)每個改動耗費(fèi)的人時數(shù)； (12)程序改動的日期； (13)軟件工程師的名字； (14)維護(hù)要求表的標(biāo)識； (15)維護(hù)類型； (16)維護(hù)開始和完成的日期； (17)累計用于維護(hù)的人時數(shù)； (18)與完成的維護(hù)相聯(lián)系的純效益,軟件工程導(dǎo)論第8章,應(yīng)該為每項(xiàng)維護(hù)工作都收集上述數(shù)據(jù)?？梢岳眠@些數(shù)據(jù)構(gòu)成一個維護(hù)數(shù)據(jù)庫的基礎(chǔ)，并且像下面介紹的那樣對它們進(jìn)行評價。 5. 評價維護(hù)活動 缺乏有效

18、的數(shù)據(jù)就無法評價維護(hù)活動。如果已經(jīng)開始保存維護(hù)記錄了，則可以對維護(hù)工作做一些定量度量。至少可以從下述7個方面度量維護(hù)工作： (1) 每次程序運(yùn)行平均失效的次數(shù)； (2) 用于每一類維護(hù)活動的總?cè)藭r數(shù)； (3) 平均每個程序、每種語言、每種維護(hù)類型所做的程序變動數(shù),軟件工程導(dǎo)論第8章,4) 維護(hù)過程中增加或刪除一個源語句平均花費(fèi)的人時數(shù)； (5) 維護(hù)每種語言平均花費(fèi)的人時數(shù)； (6) 一張維護(hù)要求表的平均周轉(zhuǎn)時間； (7) 不同維護(hù)類型所占的百分比。 根據(jù)對維護(hù)工作定量度量的結(jié)果，可以做出關(guān)于開發(fā)技術(shù)、語言選擇、維護(hù)工作量規(guī)劃、資源分配及其他許多方面的決定，而且可以利用這樣的數(shù)據(jù)去分析評價維護(hù)

19、任務(wù),軟件工程導(dǎo)論第8章,可以把軟件的可維護(hù)性定性地定義為： 維護(hù)人員理解、改正、改動或改進(jìn)這個軟件的難易程度。在前面的章節(jié)中曾經(jīng)多次強(qiáng)調(diào)，提高可維護(hù)性是支配軟件工程方法學(xué)所有步驟的關(guān)鍵目標(biāo),8.4 軟件的可維護(hù)性,軟件工程導(dǎo)論第8章,維護(hù)就是在軟件交付使用后進(jìn)行的修改，修改之前必須理解待修改的對象，修改之后應(yīng)該進(jìn)行必要的測試，以保證所做的修改是正確的。如果是改正性維護(hù)，還必須預(yù)先進(jìn)行調(diào)試以確定錯誤的具體位置。因此，決定軟件可維護(hù)性的因素主要有下述5個,8.4.1 決定軟件可維護(hù)性的因素,軟件工程導(dǎo)論第8章,1. 可理解性 軟件可理解性表現(xiàn)為外來讀者理解軟件的結(jié)構(gòu)、功能、接口和內(nèi)部處理過程的難

20、易程度。模塊化（模塊結(jié)構(gòu)良好，高內(nèi)聚，松耦合）、詳細(xì)的設(shè)計文檔、結(jié)構(gòu)化設(shè)計、程序內(nèi)部的文檔和良好的高級程序設(shè)計語言等等，都對提高軟件的可理解性有重要貢獻(xiàn),軟件工程導(dǎo)論第8章,2. 可測試性 診斷和測試的容易程度取決于軟件容易理解的程度。良好的文檔對診斷和測試是至關(guān)重要的，此外，軟件結(jié)構(gòu)、可用的測試工具和調(diào)試工具，以及以前設(shè)計的測試過程也都是非常重要的。維護(hù)人員應(yīng)該能夠得到在開發(fā)階段用過的測試方案，以便進(jìn)行回歸測試。在設(shè)計階段應(yīng)該盡力把軟件設(shè)計成容易測試和容易診斷的。 對于程序模塊來說，可以用程序復(fù)雜度來度量它的可測試性。模塊的環(huán)形復(fù)雜度越大，可執(zhí)行的路徑就越多，因此，全面測試它的難度就越高,軟

21、件工程導(dǎo)論第8章,3. 可修改性 軟件容易修改的程度和本書第5章講過的設(shè)計原理和啟發(fā)規(guī)則直接有關(guān)。耦合、內(nèi)聚、信息隱藏、局部化、控制域與作用域的關(guān)系等等，都影響軟件的可修改性。 4. 可移植性 軟件可移植性指的是，把程序從一種計算環(huán)境（硬件配置和操作系統(tǒng)）轉(zhuǎn)移到另一種計算環(huán)境的難易程度。把與硬件、操作系統(tǒng)以及其他外部設(shè)備有關(guān)的程序代碼集中放到特定的程序模塊中，可以把因環(huán)境變化而必須修改的程序局限在少數(shù)程序模塊中，從而降低修改的難度,軟件工程導(dǎo)論第8章,5. 可重用性 所謂重用（reuse）是指同一事物不做修改或稍加改動就在不同環(huán)境中多次重復(fù)使用。大量使用可重用的軟件構(gòu)件來開發(fā)軟件，可以從下述兩

22、個方面提高軟件的可維護(hù)性： (1) 通常，可重用的軟件構(gòu)件在開發(fā)時經(jīng)過很嚴(yán)格的測試，可靠性比較高，且在每次重用過程中都會發(fā)現(xiàn)并清除一些錯誤，隨著時間推移，這樣的構(gòu)件將變成實(shí)質(zhì)上無錯誤的。因此，軟件中使用的可重用構(gòu)件越多，軟件的可靠性越高，改正性維護(hù)需求越少,軟件工程導(dǎo)論第8章,2） 很容易修改可重用的軟件構(gòu)件使之再次應(yīng)用在新環(huán)境中，因此，軟件中使用的可重用構(gòu)件越多，適應(yīng)性和完善性維護(hù)也就越容易,軟件工程導(dǎo)論第8章,文檔是影響軟件可維護(hù)性的決定因素。由于長期使用的大型軟件系統(tǒng)在使用過程中必然會經(jīng)受多次修改，所以文檔比程序代碼更重要。 軟件系統(tǒng)的文檔可以分為用戶文檔和系統(tǒng)文檔兩類。用戶文檔主要描述

23、系統(tǒng)功能和使用方法，并不關(guān)心這些功能是怎樣實(shí)現(xiàn)的；系統(tǒng)文檔描述系統(tǒng)設(shè)計、實(shí)現(xiàn)和測試等各方面的內(nèi)容。 總的說來，軟件文檔應(yīng)該滿足下述要求,8.4.2 文檔,軟件工程導(dǎo)論第8章,1) 必須描述如何使用這個系統(tǒng)，沒有這種描述時即使是最簡單的系統(tǒng)也無法使用； (2) 必須描述怎樣安裝和管理這個系統(tǒng)； (3) 必須描述系統(tǒng)需求和設(shè)計； (4) 必須描述系統(tǒng)的實(shí)現(xiàn)和測試，以便使系統(tǒng)成為可維護(hù)的。 下面分別討論用戶文檔和系統(tǒng)文檔,軟件工程導(dǎo)論第8章,1. 用戶文檔 用戶文檔是用戶了解系統(tǒng)的第一步，它應(yīng)該能使用戶獲得對系統(tǒng)的準(zhǔn)確的初步印象。文檔的結(jié)構(gòu)方式應(yīng)該使用戶能夠方便地根據(jù)需要閱讀有關(guān)的內(nèi)容。 用戶文檔至

24、少應(yīng)該包括下述5方面的內(nèi)容： (1) 功能描述，說明系統(tǒng)能做什么； (2) 安裝文檔，說明怎樣安裝這個系統(tǒng)以及怎樣使系統(tǒng)適應(yīng)特定的硬件配置； (3) 使用手冊，簡要說明如何著手使用這個系統(tǒng)(應(yīng)該通過豐富例子說明怎樣使用常用的系統(tǒng)功能，還應(yīng)該說明用戶操作錯誤時怎樣恢復(fù)和重新啟動,軟件工程導(dǎo)論第8章,4) 參考手冊，詳盡描述用戶可以使用的所有系統(tǒng)設(shè)施以及它們的使用方法，還應(yīng)該解釋系統(tǒng)可能產(chǎn)生的各種出錯信息的含義(對參考手冊最主要的要求是完整，因此通常使用形式化的描述技術(shù))； (5) 操作員指南(如果需要有系統(tǒng)操作員的話)，說明操作員應(yīng)該如何處理使用中出現(xiàn)的各種情況。 上述內(nèi)容可以分別作為獨(dú)立的文檔

25、，也可以作為用戶手冊的不同分冊，具體做法應(yīng)該由系統(tǒng)規(guī)模決定,軟件工程導(dǎo)論第8章,2. 系統(tǒng)文檔 所謂系統(tǒng)文檔指從問題定義、需求說明到驗(yàn)收測試計劃這樣一系列和系統(tǒng)實(shí)現(xiàn)有關(guān)的文檔。描述系統(tǒng)設(shè)計、實(shí)現(xiàn)和測試的文檔對于理解程序和維護(hù)程序來說是極端重要的。和用戶文檔類似，系統(tǒng)文檔的結(jié)構(gòu)也應(yīng)該能把讀者從對系統(tǒng)概貌的了解，引導(dǎo)到對系統(tǒng)每個方面每個特點(diǎn)的更形式化更具體的認(rèn)識。本書前面各章已經(jīng)較詳細(xì)地介紹了各個階段應(yīng)該產(chǎn)生的文檔，此處不再重復(fù),軟件工程導(dǎo)論第8章,可維護(hù)性是所有軟件都應(yīng)該具備的基本特點(diǎn)，必須在開發(fā)階段保證軟件具有8.4.1節(jié)中提到的那些可維護(hù)因素。在軟件工程過程的每一個階段都應(yīng)該考慮并努力提高軟

26、件的可維護(hù)性，在每個階段結(jié)束前的技術(shù)審查和管理復(fù)審中，應(yīng)該著重對可維護(hù)性進(jìn)行復(fù)審。 在需求分析階段的復(fù)審過程中，應(yīng)該對將來要改進(jìn)的部分和可能會修改的部分加以注意并指明；應(yīng)該討論軟件的可移植性問題，并且考慮可能影響軟件維護(hù)的系統(tǒng)界面,8.4.3 可維護(hù)性復(fù)審,軟件工程導(dǎo)論第8章,在正式的和非正式的設(shè)計復(fù)審期間，應(yīng)該從容易修改、模塊化和功能獨(dú)立的目標(biāo)出發(fā)，評價軟件的結(jié)構(gòu)和過程；設(shè)計中應(yīng)該對將來可能修改的部分預(yù)作準(zhǔn)備。 代碼復(fù)審應(yīng)該強(qiáng)調(diào)編碼風(fēng)格和內(nèi)部說明文檔這兩個影響可維護(hù)性的因素。 另外，在設(shè)計和編碼過程中應(yīng)該盡量使用可重用的軟件構(gòu)件，如果需要開發(fā)新的構(gòu)件，也應(yīng)該注意提高構(gòu)件的可重用性,軟件工程導(dǎo)

27、論第8章,每個測試步驟都可以暗示在軟件正式交付使用前，程序中可能需要做預(yù)防性維護(hù)的部分。在測試結(jié)束時進(jìn)行最正式的可維護(hù)性復(fù)審，這個復(fù)審稱為配置復(fù)審。配置復(fù)審的目的是保證軟件配置的所有成分是完整的、一致的和可理解的，而且為了便于修改和管理已經(jīng)編目歸檔了。 在完成了每項(xiàng)維護(hù)工作之后，都應(yīng)該對軟件維護(hù)本身進(jìn)行仔細(xì)認(rèn)真的復(fù)審。 維護(hù)應(yīng)該針對整個軟件配置，不應(yīng)該只修改源程序代碼。當(dāng)對源程序代碼的修改沒有反映在設(shè)計文檔或用戶手冊中時，就會產(chǎn)生嚴(yán)重的后果,軟件工程導(dǎo)論第8章,每當(dāng)對數(shù)據(jù)、軟件結(jié)構(gòu)、模塊過程或任何其他有關(guān)的軟件特點(diǎn)做了改動時，必須立即修改相應(yīng)的技術(shù)文檔。不能準(zhǔn)確反映軟件當(dāng)前狀態(tài)的設(shè)計文檔可能比

28、完全沒有文檔更壞。在以后的維護(hù)工作中很可能因文檔不完全符合實(shí)際而不能正確理解軟件，從而在維護(hù)中引入過多的錯誤。 用戶通常根據(jù)描述軟件特點(diǎn)和使用方法的用戶文檔來使用、評價軟件。如果對軟件的可執(zhí)行部分的修改沒有及時反映在用戶文檔中，則必然會使用戶因?yàn)槭艽煺鄱a(chǎn)生不滿,軟件工程導(dǎo)論第8章,如果在軟件再次交付使用之前，對軟件配置進(jìn)行嚴(yán)格的復(fù)審，則可大大減少文檔的問題。事實(shí)上，某些維護(hù)要求可能并不需要修改軟件設(shè)計或源程序代碼，只是表明用戶文檔不清楚或不準(zhǔn)確，因此只需要對文檔做必要的維護(hù),軟件工程導(dǎo)論第8章,幾乎所有歷史比較悠久的軟件開發(fā)組織，都有一些十幾年前開發(fā)出的“老”程序。目前，某些老程序仍然在為用

29、戶服務(wù)，但是，當(dāng)初開發(fā)這些程序時并沒有使用軟件工程方法學(xué)來指導(dǎo)，因此，這些程序的體系結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)都很差，文檔不全甚至完全沒有文檔，對曾經(jīng)做過的修改也沒有完整的記錄。 怎樣滿足用戶對上述這類老程序的維護(hù)要求呢？為了修改這類程序以適應(yīng)用戶新的或變更的需求，有以下幾種做法可供選擇,8.5 預(yù)防性維護(hù),軟件工程導(dǎo)論第8章,1） 反復(fù)多次地做修改程序的嘗試，與不可見的設(shè)計及源代碼“頑強(qiáng)戰(zhàn)斗”，以實(shí)現(xiàn)所要求的修改； （2） 通過仔細(xì)分析程序盡可能多地掌握程序的內(nèi)部工作細(xì)節(jié)，以便更有效地修改它； （3） 在深入理解原有設(shè)計的基礎(chǔ)上，用軟件工程方法重新設(shè)計、重新編碼和測試那些需要變更的軟件部分； （4） 以

30、軟件工程方法學(xué)為指導(dǎo)，對程序全部重新設(shè)計、重新編碼和測試，為此可以使用CASE工具（逆向工程和再工程工具）來幫助理解原有的設(shè)計,軟件工程導(dǎo)論第8章,第一種做法很盲目，通常人們采用后3種做法。其中第4種做法稱為軟件再工程，這樣的維護(hù)活動也就是本章8.1節(jié)中所說的預(yù)防性維護(hù)，而第3種做法實(shí)質(zhì)上是局部的再工程。 預(yù)防性維護(hù)方法是由Miller提出來的，他把這種方法定義為：“把今天的方法學(xué)應(yīng)用到昨天的系統(tǒng)上，以支持明天的需求?！?粗看起來，在一個正在工作的程序版本已經(jīng)存在的情況下重新開發(fā)一個大型程序，似乎是一種浪費(fèi)。其實(shí)不然，下述事實(shí)很能說明問題： （1） 維護(hù)一行源代碼的代價可能是最初開發(fā)該行源代碼

31、代價的1440倍,軟件工程導(dǎo)論第8章,2） 重新設(shè)計軟件體系結(jié)構(gòu)（程序及數(shù)據(jù)結(jié)構(gòu)）時使用了現(xiàn)代設(shè)計概念，它對將來的維護(hù)可能有很大的幫助； （3） 由于現(xiàn)有的程序版本可作為軟件原型使用，開發(fā)生產(chǎn)率可大大高于平均水平； （4） 用戶具有較多使用該軟件的經(jīng)驗(yàn)，因此，能夠很容易地搞清新的變更需求和變更的范圍； （5） 利用逆向工程和再工程的工具，可以使一部分工作自動化； （6） 在完成預(yù)防性維護(hù)的過程中可以建立起完整的軟件配置,軟件工程導(dǎo)論第8章,典型的軟件再工程過程模型如圖8.3所示，該模型定義了6類活動。在某些情況下這些活動以線性順序發(fā)生，但也并非總是這樣，例如，為了理解某個程序的內(nèi)部工作原理，可

32、能在文檔重構(gòu)開始之前必須先進(jìn)行逆向工程。 在圖8.3中顯示的再工程范型是一個循環(huán)模型。這意味著作為該范型的組成部分的每個活動都可能被重復(fù)，而且對于任意一個特定的循環(huán)來說，過程可以在完成任意一個活動之后終止。下面簡要地介紹該模型所定義的6類活動,8.6 軟件再工程過程,軟件工程導(dǎo)論第8章,圖8.3 軟件再工程過程模型,軟件工程導(dǎo)論第8章,1. 庫存目錄分析 每個軟件組織都應(yīng)該保存其擁有的所有應(yīng)用系統(tǒng)的庫存目錄。該目錄包含關(guān)于每個應(yīng)用系統(tǒng)的基本信息（例如，應(yīng)用系統(tǒng)的名字，最初構(gòu)建它的日期，已做過的實(shí)質(zhì)性修改次數(shù)，過去18個月報告的錯誤，用戶數(shù)量，安裝它的機(jī)器數(shù)量，它的復(fù)雜程度，文檔質(zhì)量，整體可維護(hù)

33、性等級，預(yù)期壽命，在未來36個月內(nèi)的預(yù)期修改次數(shù)，業(yè)務(wù)重要程度等,軟件工程導(dǎo)論第8章,每一個大的軟件開發(fā)機(jī)構(gòu)都擁有上百萬行老代碼，它們都可能是逆向工程或再工程的對象。但是，某些程序并不頻繁使用而且不需要改變，此外，逆向工程和再工程工具尚不成熟，目前僅能對有限種類的應(yīng)用系統(tǒng)執(zhí)行逆向工程或再工程，代價又十分高昂，因此，對庫中每個程序都做逆向工程或再工程是不現(xiàn)實(shí)的。下述3類程序有可能成為預(yù)防性維護(hù)的對象： （1） 預(yù)定將使用多年的程序； （2） 當(dāng)前正在成功地使用著的程序； （3） 在最近的將來可能要做重大修改或增強(qiáng)的程序,軟件工程導(dǎo)論第8章,應(yīng)該仔細(xì)分析庫存目錄，按照業(yè)務(wù)重要程度、壽命、當(dāng)前可維護(hù)

34、性、預(yù)期的修改次數(shù)等標(biāo)準(zhǔn)，把庫中的應(yīng)用系統(tǒng)排序，從中選出再工程的候選者，然后明智地分配再工程所需要的資源。 2. 文檔重構(gòu) 老程序固有的特點(diǎn)是缺乏文檔。具體情況不同，處理這個問題的方法也不同： （1） 建立文檔非常耗費(fèi)時間，不可能為數(shù)百個程序都重新建立文檔。如果一個程序是相對穩(wěn)定的，正在走向其有用生命的終點(diǎn)，而且可能不會再經(jīng)歷什么變化，那么，讓它保持現(xiàn)狀是一個明智的選擇,軟件工程導(dǎo)論第8章,2） 為了便于今后的維護(hù)，必須更新文檔，但是由于資源有限，應(yīng)采用“使用時建文檔”的方法，也就是說，不是一下子把某應(yīng)用系統(tǒng)的文檔全部都重建起來，而是只針對系統(tǒng)中當(dāng)前正在修改的那些部分建立完整文檔。隨著時間流逝

35、，將得到一組有用的和相關(guān)的文檔。 （3） 如果某應(yīng)用系統(tǒng)是完成業(yè)務(wù)工作的關(guān)鍵，而且必須重構(gòu)全部文檔，則仍然應(yīng)該設(shè)法把文檔工作減少到必需的最小量,軟件工程導(dǎo)論第8章,3. 逆向工程 軟件的逆向工程是分析程序以便在比源代碼更高的抽象層次上創(chuàng)建出程序的某種表示的過程，也就是說，逆向工程是一個恢復(fù)設(shè)計結(jié)果的過程，逆向工程工具從現(xiàn)存的程序代碼中抽取有關(guān)數(shù)據(jù)、體系結(jié)構(gòu)和處理過程的設(shè)計信息。 4. 代碼重構(gòu) 代碼重構(gòu)是最常見的再工程活動。某些老程序具有比較完整、合理的體系結(jié)構(gòu)，但是，個體模塊的編碼方式卻是難于理解、測試和維護(hù)的。在這種情況下，可以重構(gòu)可疑模塊的代碼,軟件工程導(dǎo)論第8章,為了完成代碼重構(gòu)活動，

36、首先用重構(gòu)工具分析源代碼，標(biāo)注出和結(jié)構(gòu)化程序設(shè)計概念相違背的部分。然后重構(gòu)有問題的代碼（此項(xiàng)工作可自動進(jìn)行）。最后，復(fù)審和測試生成的重構(gòu)代碼（以保證沒有引入異常）并更新代碼文檔。 通常，重構(gòu)并不修改整體的程序體系結(jié)構(gòu)，它僅關(guān)注個體模塊的設(shè)計細(xì)節(jié)以及在模塊中定義的局部數(shù)據(jù)結(jié)構(gòu)。如果重構(gòu)擴(kuò)展到模塊邊界之外并涉及軟件體系結(jié)構(gòu)，則重構(gòu)變成了正向工程,軟件工程導(dǎo)論第8章,5. 數(shù)據(jù)重構(gòu) 對數(shù)據(jù)體系結(jié)構(gòu)差的程序很難進(jìn)行適應(yīng)性修改和增強(qiáng)，事實(shí)上，對許多應(yīng)用系統(tǒng)來說，數(shù)據(jù)體系結(jié)構(gòu)比源代碼本身對程序的長期生存力有更大影響。 與代碼重構(gòu)不同，數(shù)據(jù)重構(gòu)發(fā)生在相當(dāng)?shù)偷某橄髮哟紊希且环N全范圍的再工程活動。在大多數(shù)情況下，數(shù)據(jù)重構(gòu)始于逆向工程活動，分解當(dāng)前使用的數(shù)據(jù)體系結(jié)構(gòu)，必要時定義數(shù)據(jù)模型，標(biāo)識數(shù)據(jù)對象和屬性，并從軟件質(zhì)量的角度復(fù)審現(xiàn)存的數(shù)據(jù)結(jié)構(gòu)。 當(dāng)數(shù)據(jù)結(jié)構(gòu)較差時，應(yīng)該對數(shù)據(jù)進(jìn)行再工程,軟件工程導(dǎo)論第8章,由于數(shù)據(jù)體系結(jié)構(gòu)對程序體系結(jié)構(gòu)及程序中的算法有很大影響，對數(shù)據(jù)的修改必然會導(dǎo)致體系結(jié)構(gòu)或代碼層的改變。 6. 正向工程 正向工程也稱為革新或改造，這項(xiàng)活動不僅從現(xiàn)有程序中恢復(fù)設(shè)計信息，而且使用該信息去改變或重構(gòu)現(xiàn)有系統(tǒng)，以提高其整體質(zhì)量。 正向工程過程應(yīng)用軟件工程的原理、概念、技術(shù)和方法來