軟件工程學(xué)復(fù)習(xí)大綱

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19、統(tǒng)中某一定型化的、可配置的和可替換的部件，該部件封裝了實現(xiàn)并暴露一系列接口。構(gòu)件級設(shè)計定義了數(shù)據(jù)結(jié)構(gòu)、算法、接口特征和分配給每個軟件構(gòu)件的通信機制。（2） 基于類的構(gòu)件基本設(shè)計原則：（前四個） 開關(guān)原則：模塊對外延具有開放性，對修改具有封閉性。 LISKOV替換原則（或里氏替換原則）：子類可以替換它們的基類。 依賴倒置原則：依賴于抽象，而非具體實現(xiàn)。 接口分離原則：多個用戶專用接口比一個通用接口要好。（3） 內(nèi)聚性意味著構(gòu)件或者類只封裝那些相互關(guān)聯(lián)密切，以及與構(gòu)件或類自身有密切關(guā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)用耦合、類型使用耦合、包含或者導(dǎo)入耦合、外部耦合。（5） 模塊的高內(nèi)聚和低藕合是構(gòu)件設(shè)計建模的重要目標(biāo)。（6） 傳統(tǒng)構(gòu)件的設(shè)計常用表示方法有圖形化設(shè)計表示（程序流程圖、N-S圖）、表格式設(shè)計表示（決策表：條件、動作、條件組合和處理規(guī)則）和程序設(shè)計語言(PLD)。十、 第十三章軟件測試策略（1） 軟件測試策略將軟件測試用例的設(shè)計方法集成到一系列經(jīng)周密計劃的步驟中去，從而使軟件構(gòu)造成功地完成。任何測試策略都必須包含測試計劃、測試用例設(shè)計、測試執(zhí)行以及測試結(jié)果數(shù)據(jù)的收集與評估。（2）

21、 傳統(tǒng)軟件的測試策略是將測試分為單元測試、集成測試、確認(rèn)測試和系統(tǒng)測試。 單元測試是針對程序中的模塊或構(gòu)件，主要揭露編碼階段產(chǎn)生的錯誤。 集成測試針對集成的軟件系統(tǒng)，主要揭露設(shè)計階段產(chǎn)生的錯誤。 確認(rèn)測試是根據(jù)軟件需求規(guī)約對集成的軟件進行確認(rèn)，主要揭露不符合需求規(guī)約的錯誤。 系統(tǒng)測試是針對基于計算機系統(tǒng)中的軟件，以揭露不符合系統(tǒng)工程中對軟件要求的錯誤。（3） 單元測試的主要內(nèi)容包括：模塊接口、局部數(shù)據(jù)結(jié)構(gòu)、邊界條件、所有獨立路徑和所有錯誤處理路徑。在單元測試中，每個被測模塊開發(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é)構(gòu)分解成若干個簇，對同一層次的簇可并行進行測試，可提高效率。l 缺點：整體性的錯誤發(fā)現(xiàn)得較晚。（5） 回歸測試是對已進行過的測試的子集的重新執(zhí)行，以確保對程序的改變和修改，沒有傳播非故意的副作用?；貧w測試集（已經(jīng)過測試的子集）包括三種不同類型的測試用例： 能測試軟件所有功能的代表性測試用例 專門針對可能會被修改影響的軟件功能的附加測試 注重于修改過的軟件模塊的測試（6） 冒煙測試是一種常用的集成測試方法，它讓軟件團隊頻繁地對項目進行評估。冒煙測試提供了下列好處: 降低了集成風(fēng)險 提高最終產(chǎn)品的質(zhì)量 簡化錯誤的診斷和修正（7） 測試和測試是確認(rèn)測試的兩種常用方法。 測試是由用戶在開發(fā)者的場所進行的，軟件在開發(fā)者對用戶的“指導(dǎo)下”進行測試。經(jīng)測試后的軟件稱為版軟件。 測試是由軟件的最終