【正文】 計算機廣泛使用有35年，而高級語言應用僅30年。若能夠及時地確定對軟件資源的要求，則可以較好地對各種方案進行技術評價，并能盡早地獲得所需的方案。如果在與系統(tǒng)結合起來之前需要作某些修改，那就必須特別小心，因為修改現(xiàn)有軟件所需費用有時會大于開發(fā)同等軟件的費用。但重用技術的問題是如何選擇重用對象、分類、建庫，以及解決通用接口的機制問題，使其能適用于任一硬、軟件環(huán)境。②實用軟件相當于軟件庫，可以結合到新的系統(tǒng)中去，如各種標準子程序等。恰當?shù)厥褂弥С周浖梢源蟠蟮靥岣哕浖_發(fā)的生產率和軟件的質量。在編碼和單元測試階段，有動態(tài)調試程序、交叉匯編程序/編譯程序和宏處理程序。在軟件生存期的各階段還要有其它相應的支持軟件:在需求分析階段，有需求分析和生成程序。最基礎的支持軟件是操作系統(tǒng)、編譯程序、數(shù)據(jù)庫、圖形包和網(wǎng)絡軟件等。（3）軟件和硬件一樣，也是一種軟件開發(fā)工具。②目標機運行所開發(fā)軟件的計算機叫目標機，其中也包括有關的外部設備，在很多情況下，宿主機與目標機是統(tǒng)一的。對于一些專門的開發(fā)機構，為了能夠接受更多的用戶任務，并能方便地使用多種類型的開發(fā)支持工具，常備有專門的開發(fā)系統(tǒng)。（2）硬件硬件也是一種軟件開發(fā)工具。高級技術人員同樣如此。軟件工程各個階段對人員有不同的要求。這里所討論的不是小項目，而是大項目，2個人是干不了的。計劃人員還必須考慮各個接口的性質及復雜程度，以確定對開發(fā)資源、成本和進度的各種影響。（3）人指通過終端或輸入/輸出設備使用該軟件的操作人員。接口又可分為硬件、軟件和人三類:（1）硬件指執(zhí)行該軟件的硬件，如中央處理機和外部設備，以及由該軟件控制的各種間接設備，如各種機器和顯示設備等。軟件的性能包括處理時間的約束、存儲限制以及依賴于機器的某些特性。計劃人員必須使用管理人員和技術人員都能理解的無二義性的語言來描述工作范圍。（一） 確定工作范圍和資源軟件計劃的第一個任務就是確定軟件的工作范圍，即軟件的用途及對軟件的要求。就目前軟件開發(fā)中的問題，更多的是管理問題。五、軟件管理軟件工程項目高質量高效率的完成與其他產品的工程項目一樣，不僅取決于所采用的技術、方法和工具，還決定于管理的好壞。適應性維護或完善性維護的過程相當于一個小的開發(fā)過程，它同樣要經歷需求分析、設計、編碼、測試等階段。若是適應性維護或完善性維護，則要根據(jù)其優(yōu)先級來決定維護的先后次序，優(yōu)先級高的維護則馬上開始。維護活動的第一步是確定維護的類型，若是改正性維護，則要估計錯誤的嚴重程度，對嚴重的錯誤，則馬上分派人員執(zhí)行維護任務。維護申請書由維護管理員和系統(tǒng)管理員審批。改正性維護的申請報告應完整地描述導致錯誤的環(huán)境，包括輸入數(shù)據(jù)、錯誤清單以及有關的材料。在軟件設計中我們介紹的那些設計準則都是影響可修改性的因素，如信息隱蔽原則、模塊獨立、模塊間聯(lián)系的低耦合高內聚等等。如果修改程序時稍有考慮不周，就會出現(xiàn)上述顧此失彼的情況。在修改程序時經常會發(fā)生這樣的情況:修改程序中某個錯誤的同時又產生新的錯誤（由程序的修改引起的），或者在程序中增加了某個功能的同時，原先的某些功能不能正常執(zhí)行。提高軟件可測試性的措施有:書寫詳細正確的文檔，采用良好的程序結構，使用測試工具和調試工具，保存以前的測試過程和測試用例等等?？蓽y試性是指測試和診斷軟件（主要指程序）中錯誤的難易程度。（三） 可維護性軟件可維護性是指理解、改正、改動、改進軟件的難易程度。從而導致維護質量的不高。從事維護工作常使維護人員感到缺乏成就感。對那些缺乏模塊獨立性和非結構化的程序來說，更是如此。即使原先的開發(fā)人員還在，也可能因為相隔時間太久而遺忘了實現(xiàn)的細節(jié)。（3）在軟件維護時，不要指望得到原來開發(fā)該軟件的人員的幫助。合格的文檔不僅要完整正確地反映開發(fā)過程各階段的工作結果，而且應該容易理解并應程序源代碼一致。（2）需要維護的軟件往往缺少合格的文檔，或者文檔資料不齊，甚至沒有文檔。（1）要維護一個軟件，首先要理解它。（二） 與軟件維護有關的問題軟件維護人員通常不是該軟件的開發(fā)人員，這給軟件維護帶來很大的困難，特別是有些軟件在開發(fā)時沒有遵循軟件開發(fā)的準則，沒有開發(fā)方法的支持，維護這樣的軟件就更困難。軟件維護活動主要是上述三類維護，另有一類維護稱為預防性維護，它是為了提高軟件的可維護性和可靠性，為未來的進一步改進打下基礎而修改軟件的活動。適應性維護就是為了適應變化了的環(huán)境而修改軟件的活動。改正性維護就是在使用過程中發(fā)現(xiàn)了隱藏的錯誤后，為了診斷和改正這些隱藏錯誤而修改軟件的活動。（一） 軟件維護的分類根據(jù)引用軟件維護的原因，軟件維護通?？煞殖筛恼跃S護、適應性維護、完善性維護、預防性維護。一個軟件的開發(fā)時間可能需要一兩年，但它的使用時間可能要幾年或幾十年，而整個使用期都可能需要進行軟件維護，所以軟件維護的代價是很大的，而且維護的代價還在逐年上升，據(jù)1994年Software Engineering Encyclopedia記載，在整個軟件生存周期所花費的代價中，20世紀80年代末用于軟件維護的代價約為75%到90年代初為90%。這種方法沒有機械的執(zhí)行步驟，主要依靠直覺和經驗。由于邊值分析方法所設計的測試用例，更有可能發(fā)現(xiàn)程序中的錯誤，因此經常把邊值分析方法與其他設計測試用例方法結合起來使用。使用等價類劃分方法設計測試用例時，原則上講，等價類中的任一輸入數(shù)據(jù)都可作為該等價類的代表用作測試用例。大量的實踐說明，程序中在處理邊界情況時出錯的概率比較大，因此設計一些測試用例，使程序運行在邊界情況附近，這樣揭露程序中錯誤的可能性就更大。反之，如果一個輸入數(shù)據(jù)不能檢測出某個錯誤，那么等價類中其他輸入數(shù)據(jù)也不能發(fā)現(xiàn)這一錯誤（除非這個等價類的某個子集還屬于另一等價類）。無效的輸入數(shù)據(jù)是指不符合規(guī)格說明要求的不合理或非法的輸入數(shù)據(jù)，它主要用來檢驗程序是否做了規(guī)格說明以外的事。這里首先要介紹一個有效的輸入數(shù)據(jù)和無效的輸入數(shù)據(jù)。常用的黑盒測試技術有等價類劃分、邊值分析、錯誤猜測等。路徑覆蓋實際上是考慮了程序中各種判定結果的所有可能組合，但它并未考慮判定中的條件結果的組合，因此它是一種比較強的覆蓋標準，但并不能代替條件覆蓋和條件組合覆蓋。然而，條件組合覆蓋還不能保證程序中所有可能的路徑都被覆蓋。由于條件組合覆蓋使每個判定中條件結果的所有可能組合都至少出現(xiàn)一次，因此判定本身的所有可能結果也一定至少出現(xiàn)一次，同時也使每個條件的所有可能結果至少出現(xiàn)一次。在條件覆蓋中考慮了判定中每個條件的所有可能結果，但并未考慮條件的組合情況。顯然，滿足判定/條件覆蓋標準的測試用例一定也滿足判定覆蓋、條件覆蓋和語句覆蓋標準。判定/條件覆蓋是指選擇足夠的測試用例。在軟件設計過程中，一個判定往往由多個條件組成，判定覆蓋僅考慮了判定的結果而沒有考慮每個條件的可能結果。判定覆蓋又稱為分支覆蓋。為了提高測試的效率，應選擇最少的測試用例來滿足指定的覆蓋標準。（三） 白盒測試的測試用例設計白盒測試是根據(jù)程序的內部邏輯來設計測試用例，常用的技術是邏輯覆蓋，即考察用測試數(shù)據(jù)運行被測程序時對程序邏輯的覆蓋程度。Alpha測試和Beat測試除了進一步發(fā)現(xiàn)程序中的錯誤外，還能發(fā)現(xiàn)使用上的問題。Beat測試是在一個或多個客戶的現(xiàn)場由該軟件的最終用戶實施的。大多數(shù)軟件生產者使用一種Alpha測試和Beta測試的過程，來揭露僅由最終用戶才能發(fā)現(xiàn)的錯誤。如果一個軟件是為某個客戶定制的，那么最后由客戶來實施驗收測試（acceptance testing），以便客戶確認該軟件是否他所需要的。確認測試通常采用黑盒測試。同樣道理，在自底向上集成時可用下層模塊作為上層模塊的樁模塊，而不必另外編寫樁模塊。由于測試下層模塊時它的上層模塊已測試過，所以可以用其上層模塊作為它的驅動模塊，而不必另編驅動模塊。漸增式集成又可分成自頂向下集成和自底向上集成。非漸增式集成是先測試所有的模塊，然后把這些模塊集成在一起對整個程序進行測試。集成測試主要發(fā)現(xiàn)設計階段產生的錯誤，通常采用黑盒測試。在模塊結構圖中，頂層模塊測試時不需要驅動模塊，最底層的模塊測試時不需要樁模塊。驅動模塊的功能是向被測試模塊提供測試數(shù)據(jù)，驅動（即調用）被測模塊，并從被測模塊中接受測試結果。單元測試主要發(fā)現(xiàn)編碼和詳細設計中產生的錯誤，通常采用白盒測試。（unit testing）單元測試也稱模塊測試。它根據(jù)規(guī)格說明書規(guī)定的功能來設計測試用例，檢查程序的功能是否符合規(guī)格說明的要求。它根據(jù)程序的內部邏輯來設計測試用例，檢查程序中的邏輯通路是否都按預定的要求正確地工作。測試的關鍵是測試用例的設計，其方法可分成兩類:白盒測試和黑盒測試。（8）程序模塊經測試后，殘存的錯誤數(shù)目往往與已發(fā)現(xiàn)的錯誤數(shù)目成比例。因為在改正錯誤或程序維護后還要進行重新測試。（5）檢查程序是否做了應做的事是成功的一半，另一半是看程序是否做了不該做的事。如果不仔細檢查測試結果，有些已經測試出來的錯誤也可能被遺漏掉。當然，這并不意味著程序員都不能測試自己的程序，如單元測試通常就是由程序員自己測試的。此外，開發(fā)程序是一項建設性的工作，而測試則是一項破壞性的工作（證明程序有錯），這對開發(fā)人員或機構來說在心理上是難以容忍的。（2）程序員應避免測試自己的程序，程序設計機構不應測試自己的程序?；谏鲜鰷y試目的，我們可以考慮以下有關測試的原則:（1）確定預期輸出結果是測試用例必不可少的一部分。一個好的測試用例是極有可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試用例。在測試時將實際的輸出結果與預期結果比較，若不同則表示發(fā)現(xiàn)了錯誤，因此測試用例是由測試數(shù)據(jù)和預期結果構成的。例如，一個需要3個16位字長的整型輸入數(shù)據(jù)的程序，輸入數(shù)據(jù)的所有組合情況大約有310 14 種，若每組數(shù)據(jù)的測試時間為1ms，那么即使一年365天，每天24小時地測試，也大約需要1萬年的時間。有人認為測試是為了證明程序是正確的，也就是說程序不再有錯誤，事實證明這是不現(xiàn)實的。（一） 測試的基本概念軟件測試的目的是盡可能多地發(fā)現(xiàn)軟件產品（主要是指程序）中的錯誤和缺陷。軟件測試代表了需求分析、設計、編碼的最終復審。物理產品在出廠前都要進行嚴格的檢驗，軟件產品也不例外。三、軟件測試在軟件開發(fā)的一列活動中，為了保證軟件的可靠性，人們研究并使用了很多方法進行分析、設計及編碼實現(xiàn)。在設計時，作用域應是控制域的子集，作用域最好是做出判定的模塊本身以及它的直屬下級模塊（直接調用的模塊）。模塊的作用域是指受該模塊內一個判定影響的所在模塊的集合。（6）設計單入口和單出口的模塊。一個模塊的扇出是指該模塊直接調用的下級模塊的個數(shù)。（5）模塊的扇入應盡量大，扇出不宜過大。（4）模塊的調用深度不宜過大。（1）滿足信息隱蔽原則（2）盡量使得模塊的內聚度高，模塊間的耦合度低。⑥順序內聚:如果一個模塊的處理元素是相關的，而且必須順序執(zhí)行，這個模塊屬于順序內聚。⑤通信內聚:如果一個模塊的所有處理元素集中在一個數(shù)據(jù)結構的區(qū)域上，該模塊屬于通信內聚。例如初始化模塊。例如，產生與類型無關的全部輸出的模塊。①偶然內聚:如果一個模塊完成一組任務，這組任務彼此間即使有關系，其關系也是很松散的，這個模塊屬于偶然內聚。?一個模塊有多個入口。?一個模塊不通過正常入口轉到另一模塊的內部。例如FORTRAN語言中的COMMON語句，C語言中的external數(shù)據(jù)類型，一個磁盤文件等都是全局數(shù)據(jù)區(qū)。例如，輸入/輸出把一個模塊與特定的設備、格式、通信協(xié)議耦合在一起。④ 控制耦合:控制耦合指兩個模塊間傳遞的信息中包含用于控制模塊內部邏輯的控制信息。② 數(shù)據(jù)耦合:數(shù)據(jù)耦合是指兩個模塊借助于參數(shù)表傳遞簡單數(shù)據(jù)。（1）耦合兩個模塊之間的耦合方式通常有如下7種，下面按它們的耦合度從低到高的次序依次作介紹。內聚度越低模塊的獨立性越差。內聚是指模塊內部各元素之間聯(lián)系的緊密程度。耦合是指模塊之間聯(lián)系的緊密程度。模塊獨立是指每個模塊完成一個相對獨立的特定子功能，并且與其他模塊之間的聯(lián)系簡單。隱蔽的對象可以有:什么的決策，可能修改的決策，數(shù)據(jù)結構的內部連接以及對它所做的操作細節(jié)，內部特征碼，與計算機硬件有關的細節(jié)等。在設計時首先列出一些可能發(fā)生變化的因素，在劃分模塊時將一個可能發(fā)生變化的因素隱蔽在某個模塊的內部，使其他模塊與這個因素無關。調用一個模塊只需知道它的外部特征，而不必了解其內部特征。一個模塊有它的外部特征和內部特征。這是一種復雜問題的“分而治之”的原則，模塊化的目的是使程序的結構清晰，容易閱讀，容易理解，容易測試，容易修改。例如抽象數(shù)據(jù)類型。例如函數(shù)、子程序。過程抽象是指任何一個完成明確功能的操作都可被使用者當作單個的實體看待，盡管這個操作實際上可能由一系列更低級的操作來完成。在進行模塊化設計時可以有多個抽象層次，最高抽象層次的模塊用概括的方式敘述問題的解法，較低抽象層次的模塊是對較高的抽象層次模塊對問題解決描述的細化。軟件工程中從軟件定義到軟件開發(fā)要經歷多個階段，在這個過程中每前進一步都可看作是對軟件解法的抽象層次的一次細化。抽象是指忽視一個主題中與當前目標無關的那些方面，以便更充分地注意與當前目標有關的方面。有的設計方法不區(qū)分概要設計和詳細設計，統(tǒng)稱為軟件設計。詳細設計的任務是為每個模塊設計實現(xiàn)的細節(jié)。軟件設計通?？煞譃楦乓O計和詳細設計。半手工方式是利用正文編輯程序及其他實用程序輔助手工方式來生成文檔，這類方法難以保證文檔的正確性、一致性和完整性。其中PSL是用來描述系統(tǒng)的形式語言，它可以對系統(tǒng)需求的一致性進行檢查，并可根據(jù)開發(fā)者的需要，隨時生成需求文檔。同年美國密執(zhí)安大學開發(fā)了PSL/PSA（問題陳述語言/問題陳述分析程序）系統(tǒng)。（1）計算機輔助生成:由于需求文檔的規(guī)模較大，并且需要經常查詢、維護，所以使用計算機輔助的軟件需求分析工具，來實現(xiàn)軟件需求文檔的自動生成，是非常有意義的。（1）概述（2）數(shù)據(jù)描述①數(shù)據(jù)流圖②數(shù)據(jù)字典③系統(tǒng)接口說明④內部接口說明（3）功能描述①功能②處理說明③設計的限制（4）性能描述①性能指標②測試種類③預期的軟件響應性能④其它（5）參考文獻目錄（6）附錄其中概述是從系統(tǒng)的角度描述軟件的目標和任務。使用的手段，應當以結構化英語為主，對存在判斷問題的加工邏輯，