1、軟件生存期:一個軟件從定義到開發、使用和維護，直到最終被廢棄，要經歷一個漫長的時期，通 常把軟件經歷的這個漫長的時期稱為生存周期。軟件生存周期就是從提出軟件產品開始，直到該 軟件產品被淘汰的全過程。什么是軟件危機?為什么會產生軟件危機?軟件危機是指計算機軟件的開發和維護過程中所遇到的 一系列嚴重的問題，主要包含二方面的問題，一是如何開發利用軟件，二是如何維護數量不斷膨脹的 已有軟件。產生軟件危機的原因，一方面與軟件本身的特點有關，另一方面和軟件開發與維護的方法 不正確有關。快速原型模型：所謂快速原型模型是快速建立起來的可以在計算機上運行的程序，它所能完成的功 能往往是最終產品能完成的功能的一個

2、子集。瀑布模型：是將軟件生命周期的各項活動規定為依線性順序連接的若干階段的模型，適合于軟件需求 很明確的軟件項目。增量模型（漸增模型）：瀑布模型的順序特征和快速原型模型的迭代特征相結合的產物。螺旋模型：對于大型軟件，只開發一個原型往往達不到要求。螺旋模型將瀑布模型和增量模型結合起來，并加入了風險分析。噴泉模型：以面向對象的軟件開發方法為基礎，以用戶的需求為動力，以對象來驅動的模型。結構化分析方法（SA）是E.Yourdon提出，是使用數據流圖DFD與數據字典DD，用來描述面向 數據流問題的需求分析，適合于數據處理型的軟件的需求描述。核心思想是分解化簡問題，將物理表示與邏輯表示分開，對系統進行數

3、據與結構的抽象。 優點是表達方式比文字清晰、簡明，易于交流與掌握。缺點是不能表達復合邏輯的需求分析問題，不能詳細描述加工。結構化設計（SD）是使用最廣泛的一種設計方法，該方法適合于軟件系統的總體設計和詳細設計，特別是將一個復雜的系統轉換成模塊化結構系統，該方法具有它優勢。（相對獨立，功能單一的模塊 結構；塊內聯系大，塊間聯系小的模塊性能標準；采用模塊結構圖的描述方式）以模塊化設計為中心， 將待開發的軟件系統劃分為若干個相互獨立的模塊。面向數據流的設計是以需求分析階段產生的數據 流圖為基礎，按一定的步驟映射成軟件結構，因此又稱結構化設計（sd）。數據流圖（ppt第二章18） 數據流圖描繪系統的邏

4、輯模型，圖中沒有任何具體的物理元素，只是 描繪信息在系統中流動和處理的情況。簡稱DFD,是SA（結構化分析）方法中用于表示系統邏輯模型 的一種工具，它以圖形的方式描繪數據在系統中流動和處理的過程，由于它只反映系統必須完成的邏 輯功能，所以它是一種功能模型。數據流圖是一種圖形化技術，它描繪信息流和數據從輸入移動到輸 出的過程中所經受的變換。數據字典（ppt第二章39）是關于數據的信息的集合，也就是對數據流圖中包含的所有元素的定義 的集合。簡稱DD，就是用來定義數據流圖中的各個成分具體含義的，它以一種準確的、無二義性的 說明方式為系統的分析、設計及維護提供了有關元素的一致的定義和詳細的描述。四類條

5、目：數據流、 數據項、數據存儲、數據加工。數據流圖和數據字典共同構成系統的邏輯模型數據字典內容：（1）數據流（2）數據流分量（數據元素）（3）數據存儲（4）處理什么是黑盒測試法？什么是白盒測試法？黑盒測試法把程序看成一個黑盒子，完全不考慮程序的內 部結構和處理過程，它只檢查程序功能是否能按照規格說明書的規定正常使用，程序是否能適當地接 收輸入數據，產生正確地輸出信息。白盒測試法的前提是可以把程序看成裝在一個透明的白盒子里， 也就是完全了解程序的結構和處理過程。這種方法按照程序內部的邏輯測試程序，檢驗程序中的每條 通路是否都能按預定要求正確工作。黑盒測試和白盒測試的區別：前者基于功能，后者基于結

6、構；黑盒測試常用方法有：等價劃分、邊界值分析、錯誤推測、因果圖等。軟件系統的測試基本步驟：（1）模塊測試（單元測試）把每個模塊作為一個單獨的實體來測試。模塊測試的目的是保證每個模塊作為一個單元能正確運行。2）子系統測試（集成測試）子系統測試是把經過單元測試的模塊放在一起形成一個子系統來測試。模塊相互間的協調和通信是這 個測試過程中的主要問題，著重測試模塊的接口。3）系統測試（集成測試）系統測試是把經過測試的子系統裝配成一個完整的系統來測試。不僅能發現設計和編碼的錯誤，還應 能驗證系統確實能提供需要說明書中指定的功能，系統的動態特性也符合預定要求。在這個測試步驟 中發現的往往是軟件設計中的錯誤，

7、也能發現需求說明中的錯誤。（4）驗收測試（確認測試）驗收測試把軟件系統作為單一的實體進行測試。主要使用實際數據進行測試。驗收測試的目的是驗證 系統確實能夠滿足用戶的需要。單元測試又稱模塊測試，是針對軟件設計的最小單位一程序模塊，進行正確性檢驗的測試工作。其 目的在于發現各模塊內部可能存在的各種差錯。單元測試需要從程序的內部結構出發設計測試用例。多個模塊可以平行地獨立進行單元測試。對支持某些標準規程的程序，更要著手進行互聯測試。有人把這種情況特別稱為模塊測試，以區別單 元測試。模塊并不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯系，用一些輔助模塊去模 擬與被測模塊相聯系的其它模塊。

8、驅動模塊（driver）樁模塊（stub） 存根模塊驅動模塊：接收測試數據，把這些數據傳送給被測試的模塊，并印出有關的結果。11樁模塊：代替被測試的模塊所調用的模塊。12.用面向對象方法開發軟件，通常需要建立三種形式的模型，它們分別是描述系統數據結構的對象模 型，描述系統控制結構的動態模型和描述系統功能的功能模型。動態模型（ppt第九章28）動態模型表示瞬時的、行為化的系統的“控制”性質，它規定了對象模 型中的對象的合法變化序列。各對象之間相互觸發（即作用），就形成了一系列的狀態變化。通常， 用狀態圖來描繪對象的狀態、觸發狀態轉換的事件、以及對象的行為（對事件的響應）。是與時間和 變化有關的系

9、統性質。該模型描述了系統的控制結構，他表示了瞬時的、行為化的系統控制性質。他 關心的是系統的控制，操作的執行順序。他從對象的事件和狀態的角度出發，表現了對象的相互關系。 對象模型對象模型表示靜態的、結構化的系統的“數據”性質。是對模擬客觀實體的對象以及對象 彼此間的關系的映射，描述了系統的靜態結構。功能模型 功能模型表示變化的系統的“功能”性質，它指明了系統應該“做什么“，因此更直接地 反映了用戶對目標系統的需求。13.各種耦合（ppt第五章25）模塊的獨立程度由兩個定性標準度量：內聚性和耦合性。耦合：是對一個軟件結構內不同模塊之間互連程度的度量。耦合性是對軟件模塊間互連程度的度量。耦合性強，

10、標志互連的強，模塊獨立性差；浦禺合性弱，標 志互連的弱，模塊獨立性強；耦合強弱取決于模塊間接口的復雜程度，進入或訪問一及通過接口的數據。模塊間的耦合程度強烈影響系統的可理解性、可測試性、可靠性和可維護性。模塊間的耦合低耦合性 高強功能單一前兩個為低等耦合中間兩個為中等耦合剩下三個非直接耦合數據耦合標記耦合控制耦合外部耦合公共耦合內容耦合強 模塊獨立性弱為高等耦合非直接耦合（Nondirect Coupling）兩個模塊之間沒有直接關系，它們之間的聯系完全是通過主模塊的控 制和調用來實現的。非直接耦合的模塊獨立性最強。數據耦合（Data Coupling）一個模塊訪問另一個模塊時，彼此之間是通過

11、簡單數據參數（不是控制參 數、公共數據結構或外部變量）來交換輸入、輸出信息的。數據耦合是最弱的耦合。標記耦合(Stamp Coupling)一組模塊通過參數表傳遞記錄信息，就是標記耦合。這個記錄是某一數據 結構的子結構，而不是簡單變量。控制耦合(Control Coupling)如果一個模塊通過傳送開關、標志、名、字等控制信息，明顯地控制選 擇另一模塊的功能，就是控制耦合。控制耦合是中等程度的耦合，它增加了系統的復雜程度。控制耦 合往往是多余的，在把模塊適當分解之后通常可以用數據耦合代替它。去除模塊間控制耦合的方法：(1)將被調用模塊內的判定上移到調用模塊中進行被調用模塊分解成若干單一功能模塊

12、外部耦合(External Coupling)一組模塊都訪問同一全局簡單變量而不是同一全局數據結構，而且不 是通過參數表傳遞該全局變量的信息，則稱之為外部耦合。公共耦合(Common Coupling)若一組模塊都訪問同一個公共數據環境，則它們之間的耦合就稱為 公共耦合。公共的數據環境可以是全局數據結構、共享的通信區、內存的公共覆蓋區等。內容耦合(Content Coupling)如果發生下列情形，兩個模塊之間就發生了內容耦合(1) 一個模塊直接訪 問另一個模塊的內部數據;(2) 一個模塊不通過正常入口轉到另一模塊內部;(3)兩個模塊有一部分程序 代碼重迭(只可能出現在匯編語言中);(4) 一

13、個模塊有多個入口。14各種內聚(ppt第五章47)內聚性標志一個模塊內各個元素彼此結合的緊密程度，它是信息隱蔽和局部化概念的自然擴展。簡單 地說，理想內聚的模塊只做一件事情、單一的功能。內聚性強，標志模塊的獨立性強；內聚性弱，標 志模塊的獨立性差。設計時應該力求做到高內聚。高一內聚性低助能內聚順序內聚通信內聚過程內舞時間內聚邏輯內舞偶然內聚強模塊獨立性弱助能單一功能分散前兩個為高等內聚，中間兩個為中等內聚，后面三個為低等內聚功能內聚(Functional Cohesion)一個模塊中各個部分都是完成某一具體功能必不可少的組成部分，或 者說該模塊中所有部分都是為了完成一項具體功能而協同工作，緊密

14、聯系，不可分割的。則稱該模塊 為功能內聚模塊。功能內聚是最高內聚。順序內聚：(Sequential cohesion)是指一個模塊內的處理元素和同一個功能密切相關，而且這些處 理必須順序執行(順序依賴)。順序內聚也是最高內聚。通信內聚(Communication Cohesion)如果一個模塊內各功能部分都使用了相同的輸入數據，或產生了 相同的輸出數據，則稱之為通信內聚模塊。通常，通信內聚模塊是通過數據流圖來定義的。過程內聚(Procedural Cohesion)使用流程圖做為工具設計程序時，把流程圖中的某一部分劃出組成 模塊，就得到過程內聚模塊。例如，把流程圖中的循環部分、判定部分、計算部

15、分分成三個模塊，這 三個模塊都是過程內聚模塊。時間內聚(Classical Cohesion)時間內聚又稱為經典內聚。這種模塊大多為多功能模塊，但模塊的各 個功能的執行與時間有關，通常要求所有功能必須在同一時間段內執行。例如初始化模塊和終止模塊。 邏輯內聚(Logical Cohesion)這種模塊把幾種相關的功能組合在一起，每次被調用時，由傳送給模塊 的判定參數來確定該模塊應執行哪一種功能。偶然內聚(Coincidental Cohesion)當模塊內各部分之間沒有聯系，或者即使有聯系，這種聯系也很 松散，則稱這種模塊為偶然內聚模塊，它是內聚程度最低的模塊總結：內聚性和耦合性是密切相關的。高

16、內聚性模塊往往是低耦合性；強耦合性的兩個模塊，必是低 內聚性的。在模塊的劃分中應盡量用高內聚性低耦合性來確保模塊的獨立性，進行軟件結構設計.15.軟件維護有哪些內容？維護的內容：維護內容的多少，依賴于設計水平的高低，設計水平高，尤其設計時就注意到軟件的易 維護性，則維護的內容和工作量就大為減少。（4個維護活動包括（改正性維護，適應性維護，完善性維護，預防性維護）1）改正性維護：指發現和改正潛藏的軟件錯誤。分為：非用戶因素的錯誤的維護；影響系統正常運行的錯誤的維護；不影響系統正常運行的錯誤的維 護。約占全部維護活動的1720%；（2）適應性維護：指在硬件環境改善，軟件支撐環境改善的情況下，交付使

17、用的軟件系統做相應的 修改，以適應新的系統環境。約占全部維護活動的1825%；（3）完善性維護：交付使用后，隨著對系統的功能的熟悉，對系統環境的掌握，用戶提出了一些新 的增加功能和性能的要求，這些要求又是合理的，盡管需求規格說明書中沒有規定，但對完善系統功 能是必要的，則必須列入維護階段再次開發設計測試維護，以適應用戶要求，完善軟件的功能，提高 軟件質量。約占全部維護活動的5066% ；（4）預防性維護：為了改進軟件的可靠性與維護性，為了適應未來的軟硬件的環境變化，主動地增 加預防性的新版本功能，以使軟件適應市場變化而不被淘汰。與其它維護活動共占總維護的4%左右。 16模塊化就是把程序劃分成獨

18、立命名且可獨立訪問的模塊，每個模塊完成一個子功能，把這些模塊集 成起來構成一個整體，可以完成指定的功能滿足用戶的需求。17信息隱蔽原理指出：應該這樣設計和確定模塊，使得一個模塊內包含的信息（過程和數據）對于不 需要這些信息的模塊來說，是不能訪問的。18.集成測試（組裝測試、聯合測試）是測試和組裝軟件的系統化技術。19確認測試：確認測試又稱有效性測試。任務是驗證軟件的功能和性能及其它特性是否與用戶的要求一致。20邏輯覆蓋（Logicalcoverage） 適用于白盒測試邏輯覆蓋是以程序內部的邏輯結構為基礎的設計測試用例的技術。它屬白盒測試。（1）語句覆蓋就是設計若干個測試用例，運行被測程序，使得每一可執行語句至少執行一次。（2）判定覆蓋就是設計若干個測試用例，運行被測程序，使得每個語句至少執行一次，程序中每個 判斷的取真分支和取假分支至少經歷一次。判定覆蓋又稱為分支覆蓋。（3）條件覆蓋就是設計若干個測試用例，運行被測程序，使得程序中每個語句至少執行一次，每個 判斷的每個條件的可能取值至少執行一次。（4）判定一條件覆蓋就是設計足夠的測試用例，使得判斷中每個條件的