軟件工程學復習大綱

1、2013級云計算專業(yè)軟件工程學期末考試復習大綱一、 第一章軟件工程介紹（1） 何為軟件？（2） 軟件和硬件不同的特性： 軟件是設計開發(fā)的，而不是傳統(tǒng)意義上生產(chǎn)制造的。 在軟件不會“磨損”，但存在退化，硬件失效曲線與軟件失效曲線對比 整體向著基于構建的模式發(fā)展，但多數(shù)仍是按客戶需求定制的。（3） 軟件危機（了解）是引入軟件工程的原因（4） 何為軟件工程？（IEEE1993的定義）：軟件工程是：（1）將系統(tǒng)化的、規(guī)范的、可量化的方法應用于軟件的開發(fā)、運行和維護，即將工程化方法應用于軟件。（2）在（1）中所述方法的研究。二、 第二章過程綜述（1） 軟件工程是一種層次化技術，其包括質(zhì)量關注點、過程、方

2、法和工具。（2） 過程框架定義了若干小的框架活動，為完整的軟件開發(fā)過程建立了基礎。 通用過程框架活動包括溝通、策劃、建模、構建和部署五種。 過程框架還包含一些適用于各個軟件過程的普適性活動。這樣活動主要有軟件項目跟蹤和控制、風險管理、軟件質(zhì)量保證、正式的技術復審、測量、軟件配置管理、可復用管理和工作產(chǎn)品的準備和產(chǎn)生。三、 第三章過程模型（1） 軟件過程模型是軟件開發(fā)全部過程、活動和任務的結(jié)構框架，也稱軟件開發(fā)模型或軟件生存周期模型。 慣例過程模型（又稱傳統(tǒng)過程模型、嚴格過程模型），強調(diào)對過程活動和任務的詳細定義、識別和應用。它力求實現(xiàn)結(jié)構化和有序。 敏捷過程模型提倡弱化軟件過程中過于正式的要求

3、，并將自我組織、協(xié)作、溝通和可適應性作為主要原則。 慣例軟件過程模型主要有瀑布模型、演化過程模型和統(tǒng)一過程模型等類型。（2） 瀑布模型 瀑布模型又被稱為經(jīng)典生命周期，它提出了一個系統(tǒng)的、順序的軟件開發(fā)方法。它從用戶需求規(guī)格說明開始，通過策劃、建模、構建和部署的過程，最終提供一個完整的軟件并提供持續(xù)的技術支持。 瀑布模型存在的問題：l 缺乏靈活性，難以適應需求不明確或需求經(jīng)常變化的軟件開發(fā)，實際的項目很少遵守瀑布模型提出的順序。l 客戶必須要有耐心，因為只有在項日接近尾聲的時候，他們才能得到可執(zhí)行的程序。l 開發(fā)早期存在的問題往往要到交付使用時才發(fā)現(xiàn)，維護代價大。（3） 演化過程模型演化模型是迭

4、代的過程模型，使得軟件工程師能夠逐步開發(fā)出更完整的軟件版本。其主要有原型模型和螺旋模型兩種。 原型模型的主要特點l 快速制訂原型開發(fā)的計劃、快速建模和快速構建l 原型應交付給客戶試用，并收集反饋意見，改進原型 螺旋模型結(jié)合了原型的迭代性質(zhì)和瀑布模型的系統(tǒng)性和可控性特點。隨著演進過程的開始，從圓心開始順勢針方向，執(zhí)行螺旋上的一圈表示的活動。每次演進都要考慮風險，每個演進過程都要標記里程碑。螺旋模型應用在計算機軟件的整個生命周期。是開發(fā)大型系統(tǒng)的理想方法，可以有效的應對風險。l 螺旋模型的特點：Ø 可應用在計算機軟件的整個生命周期Ø 是開發(fā)大型系統(tǒng)和軟件的理想方法Ø

5、把原型開發(fā)作為降低風險的機制（4） 統(tǒng)一過程（UP）是一種“用例驅(qū)動、以架構為核心，迭代并卻增量”的軟件過程。其包括并發(fā)進行的起始、細化、構建、轉(zhuǎn)化和生產(chǎn)5個階段。l 起始階段包括溝通和策劃，定義軟件的需求，提出系統(tǒng)的大致框架，并制定開發(fā)計劃，以保證開發(fā)具有迭代和增量的特性。l 細化階段包括溝通和建?；顒印＜毣A段擴展了起始階段定義的用例，并擴展體系結(jié)構以包括軟件的5種視圖：用例模型、分析模型、設計模型、實現(xiàn)模型和部署模型。l 構建階段于通用軟件過程中的構建活動相同，構建采用體系結(jié)構模型作為輸入，開發(fā)系統(tǒng)構建，使最終用戶能夠操作用例。l 轉(zhuǎn)化階段包括通用構建活動的后期活動以及部署活動。軟件被提

6、交最終用戶進行beta測試，并發(fā)布支持信息（手冊、問題解決指南及安裝步驟）。轉(zhuǎn)換階段結(jié)束時，軟件增量稱為可用的發(fā)布版本。l 生產(chǎn)階段和通用過程的部署活動一致。在該階段，監(jiān)控軟件持續(xù)使用，提供運行環(huán)境的支持，提交缺陷報告和變更請求。四、 第四章敏捷視角下的軟件過程（1） 敏捷聯(lián)盟的12條原則（了解即可，注意選擇題和判斷題） 盡早交付有價值的軟件來讓顧客滿意。 在后期也歡迎變更，利用變更來為客戶創(chuàng)造競爭優(yōu)勢。 交付的時間間隔越短越好。 業(yè)務人員和開發(fā)人員必須天天在一起。 圍繞受激勵的個人構建項目。 最有效的信息傳遞方式是面對面交談。 可工作軟件是進度的首要度量標準。 提倡可持續(xù)的開發(fā)速度。 關注優(yōu)

7、秀的技能和好的設計。 簡單是必要的。 好的架構和設計出自于自組織團隊。 每隔一定時間，反省工作，調(diào)整行為。（2） 建立敏捷過程的三個關鍵性假設 提前預測哪些需求是穩(wěn)定的和哪些需求會變化非常困難。 對很多軟件來說，設計和構建是交錯進行的。 從制定計劃的角度來看，分析、設計、構建和測試并不像我們所設想的那么容易預測。（3） 極限編程(eXtreme Programming, 簡稱XP)是一種常用的敏捷過程。它使用面向?qū)ο蠓椒ㄗ鳛橥扑]的開發(fā)范型。XP包括策劃、設計、編碼和測試4個框架活動。 策劃活動開始于建立一系列描述待開發(fā)軟件必要特征與功能的“故事”，XP團隊成員評估每一個故事并給出以開發(fā)周數(shù)為度

8、量單位的成本。 設計嚴格遵循KIS原則，適用簡單而不是復雜的表述。鼓勵適用CRC卡來組織相關的對象和類，鼓勵重構。 編碼的一個關鍵概念是結(jié)對編程。兩個人面對同一臺計算機共同為一個故事開發(fā)代碼。實施中兩個人擔當?shù)慕巧杂胁煌?測試。在編碼開始之前建立單元測試是XP的關鍵因素，所建立的單元測試應當適用一個可以自動實施的框架，易于重復執(zhí)行，這種方式支持代碼修復后的回歸測試策略。（4） Scrum是一種有效解決時間緊張的、需求變化的和業(yè)務關鍵的項目的敏捷過程。Scrum過程定義了計劃會議、每日例會、評審會議和回顧會議四種會議。 Scrum的計劃會議l 訂出 Sprint 目標和需要完成的Backlo

9、gl 對本次Sprint 的Backlog進行必要的細化和任務分割l 會議的結(jié)束后，團隊將會決定他們能夠交付哪些東西，以及驗收的標準 Scrum的每日例會l 團隊成員間工作進度的溝通和協(xié)調(diào)Ø 昨天做了什么Ø 存在什么問題Ø 今天準備做什么l 溝通任務板和燃盡圖 Scrum的評審會議l 團隊在會議中向最終用戶展示這次 Sprint工作成果l 評審檢查是否已達到 Sprint 的目標l 團隊成員得到反饋，并以之創(chuàng)建或變更 Backlog條目 Scrum的回顧會議l 繼續(xù)做(保持好的做法)l 停止做（去除錯誤的做法）l 更好地做（改進有問題的做法）五、 第七章需求工程（

10、1） 需求工程是一個軟件工程動作，始于溝通并持續(xù)到建模。（2） 需求工程為以下工作提供了良好的機制：理解用戶需要什么、分析要求、評估可行性、協(xié)商合理的方案、無歧義的詳細說明方案、確認規(guī)格說明。（3） 需求工程過程通過執(zhí)行起始、導出、精化、協(xié)商、規(guī)格說明、確認和管理七個不同的活動來完成。 在起始階段，軟件工程師會詢問一些似乎與項目無直接關系的問題，以建立基本的諒解。 導出需求面臨范圍問題、理解問題和易變問題。導出需求的主要有協(xié)同需求收集、質(zhì)量功能部署和用戶場景三種方法。 精化階段開發(fā)精確的技術模型用以說明軟件的功能、特征和約束。精化的最終結(jié)果是形成一個分析模型，該模型定義了問題的信息域、功能域和

11、行為域。 通過協(xié)商過程來調(diào)解客戶/最終用戶提出的過高要求和需求沖突。 規(guī)格說明是需求工程師完成的最終工作產(chǎn)品。它將作為軟件工程師后續(xù)活動的基礎，它描述了一個基于計算機系統(tǒng)的功能和特性，以及那些將影響系統(tǒng)開發(fā)的約束。 在確認階段將對需求工程的工作產(chǎn)品進行質(zhì)量評估。確認需求時需要檢查需求模型的一致性、是否有遺漏以及歧義性。正式技術評審是最主要的需求確認機制。 需求管理用于幫助項目組在項目進展中標識、控制和跟蹤需求以及變更需求的一組活動。（4） 質(zhì)量功能部署（QFD）是一種將客戶要求轉(zhuǎn)化為軟件技術的技術。QFD目的是最大限度的讓客戶從軟件工程中感到滿意。它確認三類需求：正常需求、期望需求、令人興奮的

12、需求。（5） 需求工程導出的工作產(chǎn)品包括七種：必要性和可行性陳述、系統(tǒng)或產(chǎn)品范圍的說明、客戶/用戶及共利益者的列表、系統(tǒng)技術環(huán)境的說明、需求列表及每個需求適用的領域限制、一系列適用場景和任何能夠更好定義需求的原型。（6） 分析模型應為基于計算機的系統(tǒng)提供必要的信息、功能和行為域的說明。分析模型主要包括基于場景的元素、基于類的元素、行為元素和面向信息流的元素。六、 第八章構建分析模型（1） 分析模型使用文字和圖表的綜合形式以相對容易理解的方式描繪需求的數(shù)據(jù)、功能和行為。更重要的是可以更直接的評審它們的正確性、完整性和一致性。（2） 分析模型必須實現(xiàn)的三個主要目標：描述客戶需要什么、為軟件設計奠定

13、基礎、定義在軟件完成后可以被確認的一組需求。分析模型在系統(tǒng)描述和設計模型之間建立橋梁。（3） 分析建模的方法主要有面向?qū)ο蠓治龊徒Y(jié)構化分析兩種。前者關注于定義類和影響客戶需求的類之間的協(xié)作方式。而后者則考慮數(shù)據(jù)和數(shù)據(jù)處理的分析建模方法。（4） 基于場景的建模從用戶的角度表現(xiàn)系統(tǒng)；面向流的建模在說明數(shù)據(jù)對象如何通過處理函數(shù)進行轉(zhuǎn)換方面提供了指示；基于類的建模定義了對象、屬性和關系；行為建模描述了系統(tǒng)狀態(tài)、類和事件在這些類上的影響。l 基于場景的模型從用戶的角度描述軟件需求。用例是主要的建模元素，還可以適用活動圖說明場景，泳道圖顯示了處理流如何分配給不同的用戶。l 面向流的建模，常常使用DFD（數(shù)

14、據(jù)流圖）。它開始于環(huán)境圖，結(jié)束于模塊規(guī)格說明。l 在基于類的建模型中，按職責劃分可將類分為實體類、控制類和邊界類三種。CRC（類-職責-協(xié)作）提供了一個簡單的方法，可以識別和組織與系統(tǒng)或產(chǎn)品需求相關的類。CRC卡片被分為三部分，頂部寫類名，下面左側(cè)列出類的職責，右側(cè)部分列出類的協(xié)作關系。l 可以運用UML的狀態(tài)圖和順序圖進行行為建模。七、 第九章設計工程（1） 軟件設計是軟件工程過程的技術核心，它開始于需求分析和需求建模完成之后。設計模型提供了數(shù)據(jù)/類設計、體系結(jié)構設計、接口設計和構件設計的細節(jié)。（2） 軟件設計工程中，進行數(shù)據(jù)/類設計、體系結(jié)構設計、接口設計和構件設計的目的 數(shù)據(jù)/類設計：將

15、分析類模型轉(zhuǎn)化為設計類的實現(xiàn)以及軟件實現(xiàn)所要求的數(shù)據(jù)結(jié)構。 體系結(jié)構設計：定義軟件的主要結(jié)構元素之間的聯(lián)系、可用于達到系統(tǒng)所定義需求的體系結(jié)構風格和設計模式以及影響體系結(jié)構實現(xiàn)方式的約束。 接口設計：描述軟件和協(xié)作系統(tǒng)之間、軟件和使用人員之間是如何通信的。 構件設計：將軟件體系結(jié)構的結(jié)構元素變換為對軟件構件的過程性描述。（3） HP公司開發(fā)了軟件質(zhì)量屬性FURPS： 功能性（Functionality )：評估程序的特征集和能力、所提交功能的普遍性以及整個系統(tǒng)的安全性。 易用性(Usability )：通過考慮人為因素、整體美感、一致性和文檔來評估。 可靠性(Reliability)：通過測量

16、故障的頻率和嚴重性、輸出結(jié)果的精確性、故障平均時間、故障恢復能力和程序的可預見性來評估。 性能(Performance) ：度量處理速度、響應時間、資源消耗、吞吐量和效率。 可支持性(Supportability ) ：綜合了可擴展性、適應性和耐用性三面的能力。（4） 抽象是人類處理復雜問題的基本方法之一，主要有數(shù)據(jù)抽象和過程抽象兩種。（5） 模式（Pattern）是解決某一類問題的方法論，它將解決某類問題的方法總結(jié)歸納到理論高度。軟件模式主要有分析模式、體系結(jié)構模式、設計模式和編碼模式（又稱習慣用語）四種。（6） 模塊化是將軟件被劃分為獨立命名的、可尋址的構件(又被稱為模塊），把這些構件集成

17、到一起可以滿足問題的需求。（7） 信息隱蔽原則建議模塊應該具有的特征是：每個模塊對其他所有模塊都隱蔽自己的設計決策。（8） 通過開發(fā)具有“專一”功能和“避免” 與其他模塊過多交互的模塊，可以實現(xiàn)功能獨立。獨立性可以使用內(nèi)聚性（顯示模塊相關功能的強度）和耦合性（顯示模塊間的相互依賴性）兩條定性的標準評估。（9） 求精是一個細化的過程，它和抽象是互補的概念。（10） 重構是在不改變代碼(或設計)的外部行為的前提下，改進軟件系統(tǒng)內(nèi)部結(jié)構的過程。通過重構提高模塊的內(nèi)聚性，降低模塊間的耦合性，在實施重構前，保證已有足夠的測試用例，以在重構之后進行回歸測試。（11） 在設計模型通常定義了用戶接口類、業(yè)務域

18、類、過程類、持久類和系統(tǒng)類五種不同的設計類。良定義設計類的四個特征是完整性與充分性、原始性、高內(nèi)聚和低耦合。八、 第十章進行體系結(jié)構設計（1） 軟件體系結(jié)構的作用是：分析設計在滿足需求方面的有效性、在設計變更相對容易的階段，考慮體系結(jié)構可能的選擇方案、降低與軟件構造相關聯(lián)的風險。（2） 體系結(jié)構風格是一種加在整個系統(tǒng)設計上的變換，其目的在于為系統(tǒng)的所有的構件建立一個結(jié)構。通常分為：以數(shù)據(jù)為中心的體系結(jié)構、數(shù)據(jù)流體系結(jié)構、調(diào)用和返回體系結(jié)構、面向?qū)ο篌w系結(jié)構和層次體系結(jié)構五種風格。（3） 傳統(tǒng)的結(jié)構化設計需要映射變換流和事務流兩種數(shù)據(jù)流到軟件體系結(jié)構。九、 第十一章構件級設計建模（1） 構件是系

19、統(tǒng)中某一定型化的、可配置的和可替換的部件，該部件封裝了實現(xiàn)并暴露一系列接口。構件級設計定義了數(shù)據(jù)結(jié)構、算法、接口特征和分配給每個軟件構件的通信機制。（2） 基于類的構件基本設計原則：（前四個） 開關原則：模塊對外延具有開放性，對修改具有封閉性。 LISKOV替換原則（或里氏替換原則）：子類可以替換它們的基類。 依賴倒置原則：依賴于抽象，而非具體實現(xiàn)。 接口分離原則：多個用戶專用接口比一個通用接口要好。（3） 內(nèi)聚性意味著構件或者類只封裝那些相互關聯(lián)密切，以及與構件或類自身有密切關系的屬性和操作。按從強到弱排序內(nèi)聚性：功能內(nèi)聚、分層內(nèi)聚、通信內(nèi)聚、順序內(nèi)聚、過程內(nèi)聚、暫時內(nèi)聚、實用內(nèi)聚。（4）

20、藕合是類之間彼此聯(lián)系程度的一種定性度量。按從強到弱排序耦合性：內(nèi)容藕合、共用耦合、控制耦合、印記耦合、數(shù)據(jù)耦合、例程調(diào)用耦合、類型使用耦合、包含或者導入耦合、外部耦合。（5） 模塊的高內(nèi)聚和低藕合是構件設計建模的重要目標。（6） 傳統(tǒng)構件的設計常用表示方法有圖形化設計表示（程序流程圖、N-S圖）、表格式設計表示（決策表：條件、動作、條件組合和處理規(guī)則）和程序設計語言(PLD)。十、 第十三章軟件測試策略（1） 軟件測試策略將軟件測試用例的設計方法集成到一系列經(jīng)周密計劃的步驟中去，從而使軟件構造成功地完成。任何測試策略都必須包含測試計劃、測試用例設計、測試執(zhí)行以及測試結(jié)果數(shù)據(jù)的收集與評估。（2）

21、 傳統(tǒng)軟件的測試策略是將測試分為單元測試、集成測試、確認測試和系統(tǒng)測試。 單元測試是針對程序中的模塊或構件，主要揭露編碼階段產(chǎn)生的錯誤。 集成測試針對集成的軟件系統(tǒng)，主要揭露設計階段產(chǎn)生的錯誤。 確認測試是根據(jù)軟件需求規(guī)約對集成的軟件進行確認，主要揭露不符合需求規(guī)約的錯誤。 系統(tǒng)測試是針對基于計算機系統(tǒng)中的軟件，以揭露不符合系統(tǒng)工程中對軟件要求的錯誤。（3） 單元測試的主要內(nèi)容包括：模塊接口、局部數(shù)據(jù)結(jié)構、邊界條件、所有獨立路徑和所有錯誤處理路徑。在單元測試中，每個被測模塊開發(fā)一個驅(qū)動(driver)程序和若干個樁(stub)模塊。（4） 集成測試通常采用增量方式，其主要有自頂向下集成和自底向

22、上集成方法。 自頂向下集成的優(yōu)缺點：l 優(yōu)點：不需要驅(qū)動模塊；能盡早對程序的主要控制和決策機制進行檢驗，能較早發(fā)現(xiàn)整體性的錯誤；深度優(yōu)先的自頂向下集成能較早對某些完整的程序功能進行驗證。l 缺點：測試時低層模塊用樁模塊替代，不能反映真實情況；重要數(shù)據(jù)不能及時回送到上層模塊。 自底向上集成的優(yōu)缺點：l 優(yōu)點 ：不需要樁模塊，所以容易組織測試；將整個程序結(jié)構分解成若干個簇，對同一層次的簇可并行進行測試，可提高效率。l 缺點：整體性的錯誤發(fā)現(xiàn)得較晚。（5） 回歸測試是對已進行過的測試的子集的重新執(zhí)行，以確保對程序的改變和修改，沒有傳播非故意的副作用。回歸測試集（已經(jīng)過測試的子集）包括三種不同類型的測試用例： 能測試軟件所有功能的代表性測試用例 專門針對可能會被修改影響的軟件功能的附加測試 注重于修改過的軟件模塊的測試（6） 冒煙測試是一種常用的集成測試方法，它讓軟件團隊頻繁地對項目進行評估。冒煙測試提供了下列好處: 降低了集成風險 提高最終產(chǎn)品的質(zhì)量 簡化錯誤的診斷和修正（7） 測試和測試是確認測試的兩種常用方法。 測試是由用戶在開發(fā)者的場所進行的，軟件在開發(fā)者對用戶的“指導下”進行測試。經(jīng)測試后的軟件稱為版軟件。 測試是由軟件的最終