1、軟件工程復習提綱第1章軟件工程介紹 2軟件是什么 2第2章過程綜述 2軟件工程定義 2層次化 3通用過程框架 3第3章過程模型 4各種過程模型 4第4章 敏捷視角下的過程 6敏捷宣言 6第5章系統工程 7第6章需求工程 8質量功能部署（QFD） 8分析模型的元素 11第7章 構建分析模型 11第8章設計工程 11第9章 進行體系結構設計 12體系結構風格的分類 12第10章 構件級設計建模 13第11章完成用戶界面設計 13黃金規則 13第12章軟件測試策略 14軟件測試需要計劃和執行一系列的測試步驟 14第13章測試技術 15兩個不同的測試用例設計技術 15第14章產品度量 15第1章軟件工

2、程介紹軟件是什么軟件是形成配置的一組術語或對象，包括：程序（計算機程序）：指令的集合,通過執行這些指令可以滿足預期的特征、功能和性能需求數據結構：它使得程序可以充分利用信息文檔:描述程序操作和使用的文檔（圖文資料）1. 舉例說明“意外效應法則” （law of unin te nded con seque nces）在計算機軟件方面的應用。某些新科技的發明創造會給其他一些看似無關的技術領域、商業企業、公眾甚至整個 社會文化帶來深遠而出人意料的影響和作用。如：2. 用自己的語言描述保證通曉規律（ The Law of Con servation of Familiarity）、質量衰減規律（Th

3、e Law of Declining Quality）以及組織穩定性守恒規律（TheLaw of Con servatio n of Orga ni zati onal Stability）。保證通曉性規律（1980）:隨著E類型系統的演化，所有相關人員（如開發人員、銷售人員和用戶）都必須清楚地了解演化的內容和過程，以便達到滿意的演化效果。質量衰減規律（1996）:如果沒有嚴格的維護和適應性調整使之適應運行環境的變化，E類型系統的質量有衰減的趨勢。組織穩定性守恒規律（1980）:個不斷演化的E類型系統，其組織在全球范圍內的平均有效活動率在產品的生命周期中是保持不變的。3. 在交付最終用戶之前，

4、或者第1個版本投入使用之后，許多應用程序都會有頻繁的變更。為防止變更引起軟件失效，請提出一些有效的解決措施。首先從心態上承認變化是必然的，我們可以通過在軟件發布之前進行 alpha , beta 測 試，利用迭代模式，在吸取測試過程中的經驗之后，立刻改進軟件。同時保持和用戶的良好溝通，在提交用戶時進行適當培訓，讓用戶按照開發思路進行試用，可以見減少因使用方法不當引起的變化。第2章過程綜述軟件工程定義軟件工程是：（1 ）將系統化、規范的、可量化的方法應用于軟件的開發、運行和維護，即將工程化方法應 用于軟件。（2 ）在（1 ）中所述的方法的研究。 層次化工其過蠱模利軟件工程層找圖通用過程框架1.

5、溝通(Communication)2. 策劃(Planning )3. 建模(Modeling)a) 需求分析(Analysis of requirements)b) 設計(Design )4. 構建(Construction )a) 代碼生成(Code generation )b) 測試(Testing )5. 部署(Deployment )重點：1. Baetjer說過“軟件過程為用戶和設計者之間、用戶和開發工具之間以及設計者和開發工具之間提供交互的途徑技術。”設計下面問題“ 設計者應該問用戶的；用戶應該問設計者的；用戶對將要構建的軟件的自問； 設計者對于軟件產品和建造該產品采取的軟件過程

6、的自問。（如何獲取需求）2. 為溝通活動設計一個任務集1. 識別主要客戶和其他共利益者2. 與客戶會談環境無關的話題3. 寫一頁項目范圍4. 評審范圍說明5. 討論項目大致的階段6. 商定各個部門的代表，并使他們相互認識7. 為計劃活動做準備3. 用自己的話描述過程框架。當我們談到框架活動適用于所有的項目時，是否意味著 對于不同規模和復雜度的項目，可應用相同的工作任務？請解釋。過程框架定義了若干小的框架活動，為完整的軟件開發過程建立的基礎，這些框架活 動可以廣泛用于所有的軟件開發項目，無論這些項目的復雜性和規模如何，此外，還包括 一些適用于各個軟件過程的普適性活動。雖然過程框架是普適性的，但是

7、對于不同規模和復雜度的項目不能應用相同的工作任 務。首先在軟件開發的不同階段，工作任務不同。其次不同的軟件項目有不同的需求，有 特殊的背景，找不到一種通用的工作任務。4. 圖2-1中，基于“質量關注點”指明了軟件工程三個層次。這意味著在整個開發組 織內采用質量管理活動，如“全面質量管理”。仔細研究，并列出全面質量管理活 動中關鍵原則的大綱。第3章過程模型各種過程模型慣例軟件過程模型力圖給軟件開發帶來秩序和結構。盡管每一傳統過程模型都建議了一種不同的過程流，但均 實現了同樣的一組通用框架活動：溝通、計劃、建模、構建和部署。瀑布模型建議線性流程的框架活動，與軟件世界里當代軟件開發實際（持續的變更、

8、演化的系統、緊 迫的開發時間）不符；但瀑布模型確實適用于需求定義清楚且穩定的軟件開發；增量軟件過程模型通過一系列的增量發布產生軟件。RAD模型快速應用程序開發，是為大型且必須在嚴格的時間內提交的項目而設計的；演化過程模型認識到大多數軟件工程項目的迭代特性，其設計的目的是為了適應變更演化模型（如原型模 型、螺旋模型），其快速產生增量的工作產品（或是軟件的工作版本），這些模型可以應用 于所有的軟件工程活動一一從概念開發到長期的軟件維護。基于構建的模型強調構件復用及組裝。形式化方法模型提倡采用數學的方法進行軟件開發和驗證。面向方面的模型目的是解決跨整個軟件體系結構的橫切關注點；統一過程模型是一種“用

9、例驅動、以體系結構為核心、迭代及增量”的軟件過程框架，由UML方法和工具支持。統一過程是一種增量模型，定義了五個階段：起始階段：包括用戶溝通和計劃活動兩個方面，強調定義和細化用例，并將其作為主要模型； 細化階段：包括用戶溝通和建模活動，重點是創建分析和設計模型，強調類的定義和體系結 構的表示；構建階段：細化設計模型，并將設計模型轉化為軟件構建實現；轉化階段：將軟件從開發人員傳遞給最終用戶，并由用戶完成Beta測試和驗收測試；生產階段：持續地監控軟件的運行，并提供技術支持。重點：1. 開發質量“足夠好”的軟件，其優點和缺點是什么？當我們追求開發速度勝過產品 質量的時候，會產生什么后果？我們總在質

10、量和開發速度之間做取舍，開發質量“足夠好”的軟件，明顯強調質量， 優點是使軟件符合或超出客戶的預期，在性能上，交互上力圖做到盡善盡美。缺點是忽視 了開發成本，很容易造成開發時間延期，影響軟件工程后幾個階段的工作，對全局造成不 利影響。2. 當沿著螺旋過程流發展的時候，你對正在開發或者維護的軟件的看法是什么？ 在螺旋模式下，開發過程是迭代式的，采用循環的方式逐步加深系統定義和實現的深度，同時降低風險。當軟件交付使用后，螺旋模式沒有停止，它將永遠保持可操作性，每一圈完成后都會 計算成本，可以更好的維護軟件。3. 可以合用幾種過程模型嗎？如果可以，舉例說明。可以。幾種過程模型，都是相互兼容可以相互擴

11、展的，如螺旋模型結合了原型的迭代性質和 瀑模型的系統性和可控性的特點。在具體項目實施中，對于某一部分可以合用幾種過程模型，比如形式語言與自動機演 示軟件在算法開發過程，就需要使用形式化方法模型，用嚴格的數學符號定義形式語言和自動機。還有一些桌面應用程序的前臺 UI部分，可以單獨使用RAD模型，比如用delphi語言開發桌面窗體就是一種 RAD實現。而其他部分可以使用其他如瀑布式模型等方法。第4章 敏捷視角下的過程敏捷宣言個體和交互勝過過程和工具(In dividuals and in teracti ons over processes and tools )可工作軟件勝過寬泛的文檔( Wor

12、ki ng software over comprehe nsivedocume ntati on)客戶合作勝過合同談判( Customer collaboratio n over con tract n egotiati on)響應變化勝過遵循計戈U( Responding to change over following a plan)重點：1. 是否每一個敏捷過程都可以用第 2章所提及的通用框架性活動來描述？建一張表， 將通用活動和每個敏捷過程所定義的活動對應起來。2. 用自己的語言描述（用于軟件項目的）敏捷性？普遍存在的變化是敏捷的基本動力，敏捷需要有效的響應變化，它鼓勵在共利益者之

13、間進行更便利的溝通和協作，強調可運行軟件的快速交付。敏捷允許項目團隊調整并合理安排任務，理解易變性并制定計劃。精簡并維持最基本 的工作產品，強調增量交付，快速提供可運行軟件。3. 許多敏捷過程模型推薦面對面交流，實際上，現在軟件開發團隊成員及其客戶在地 理上是分散的。你是否認為這意味著這種地理上的分散應當避免？能否想出一個辦 法克服這個問題。我認為這種地理上的分散是現實，是無法避免的。我認為可以分為客戶和開發人員的 分散，開發人員內部分散兩種情況。對于第一種：產品經理需要同客戶建立一條良好的通信信道，如通過email,即時聊天工具進行定期溝通。對于第二種：開發人員需定期組織交流，通過 web

14、group消除地理上的分散。4. 為什么需求變化這么大，人們終究無法確定他們想要什么嗎？ 我認為是這樣的。其實需求是客戶對他們心目中軟件的一種描述，因為軟件還沒有實現，這種描述便是 不確定的，模糊的。同時當今世界處于高速變化之中，人們的需求會隨著環境的改變而改 變。所以敏捷開發承認變化，認為普遍存在的變化是敏捷的基本動力。第5章系統工程在寫下每行代碼之前理解所要解決的問題（詳見溝通與建模）理解基本的設計原則和概念選擇一種能夠滿足軟件構建以及運行環境要求的編程語言選擇一種能提供工具以簡化工作的編程環境構件級編碼完成后進行單元測試系統工程層次圖重點：1. 對你熟悉的系統、產品或服務，建立它們的層次

15、系統。層次應該向下擴展到簡單系 統要素（硬件、軟件等），至少得到層次樹的一個分支。即時聊天系統2. 系統工程師由3種來源：系統開發人員、用戶或一些外部組織。討論一下每種來源 的利與弊。描述一個理想的系統工程師。3. 研究文獻并寫出一篇簡短文章描述建模和模擬工具是如何工作的。或者是收集兩個或更多的商用建模或模擬工具的文獻，并且比較它們的相似處與不同處。第6章需求工程質量功能部署（QFD）是一種將客戶要求轉化成軟件技術需求的技術。QFD “目的是最大限度地讓客戶從軟件工程過程中感到滿意”，并強調“什么是對客戶有價值的”。確認三類需求：正常需求：反映了在和客戶開會時確定的針對某產品或系統的目標。如果

16、實現了這些需 求，將滿足客戶（例如：所要求的圖形顯示類型、特定的系統功能以及已定義的性能級 別）。期望需求：隱含在產品或系統中，并且可能是非常基礎的以至于客戶沒有顯式地說明， 但缺少這些將導致客戶明顯不滿（例如：易交互性、可操作性、可靠性、易安裝等）。 令人興奮的需求：反映了客戶期望之外的特點，但如果實現了這些特點，將會使客戶非 常滿意。重點：1. 為如下活動之一開發一個完整的用例：? 在ATM提款；? 在餐廳使用信用卡付費；? 使用一個在線經紀人賬戶購買股票；?使用在線書店搜索書（某個指定主題）；ATM用例圖取款銀行主機查詢客戶轉賬、I存款改密碼“ATM取款”用例規約用例名稱：ATM取款簡述

17、：客戶持銀行卡（本行或其他行）從 ATM提取現金actors:客戶和銀行主機基本流：1. 客戶插入銀行卡。2. ATM從銀行卡讀入卡號（含銀行標識和賬號），驗證卡的 有效性。3. 客戶輸入密碼。4. ATM驗證帳號和密碼。5. ATM顯示包括取款在內的服務功能，客戶選擇“取款”。 6輸入取款額：客戶輸入數量為50元的倍數的取款額。7. ATM向銀行主機通知卡號、密碼、賬號和取款額，獲得含 有最新余額的取款成功確認信息。8. ATM打印并吐出憑條。9. ATM清點并吐出現金，記錄取款成功。10. ATM詢問客戶是否繼續服務。11. 客戶選擇否，ATM吐出銀行卡，結束用例，否則回到步 驟5。用例結

18、束備選流：3-7，10a.客戶取消服務：ATM記錄服務取消，打印憑條，吐出憑條和銀行卡，用例失敗3,6,11a.客戶未及時輸入超過30秒：ATM吞卡，用例失敗2a.卡無效：ATM吞卡，用例失敗2b.讀卡器或卡被損壞：ATM吞卡，用例失敗4a.密碼錯：4a1.客戶重新輸入密碼a.累計3次密碼錯誤： ATM吞卡，用例失敗4b.無此帳號：ATM吞卡，用例失敗5a. ATM無現金：ATM不顯示“取款”功能，客戶可選擇其他服務，用例失敗6a.取款額超過ATM現金余額：ATM要求客戶重新輸入取款額。7a.帳戶余額不足：ATM要求客戶重新輸入取款額。7b.取款額超過當日最高限額：ATM要求客戶重新輸入取款額

19、。7c.網絡或銀行主機失效、通訊超時：ATM記錄服務取消，打印憑條，吐出憑條和銀行卡，用 例失敗8a.憑條打印失敗，紙用完或卡紙：8a1. ATM通知銀行主機取消取款8a2. ATM 記錄服務取消，吐出銀行卡，用例失敗 9a.吐現金失敗：9a1. ATM通知銀行主機取消取款9a2. ATM 記錄服務取消，吐出銀行卡，用例失敗 11a.客戶未及時取走卡：ATM吞卡，用例失敗業務規則：7b單日取款不得超過5000元6c每次取款不得超過2000元2. 為什么大量的軟件開發人員沒有足夠重視需求工程？以前有沒有什么情況讓你可以跳過需求工程？首先軟件開發人員認為客戶已經把需求說清楚了，但是大多數情況初步的

20、需求都是模 糊的。其次工程的進度要求很緊迫，軟件開發人員迫切希望投入到代碼編寫階段。最后和客戶溝通比較困難，使得大多數軟件開發人員不重視需求工程。又一次，項目時間很短，要求一個月完成，我們只是大體上對需求有一個認識，就跳 過需求工程開始動手編碼，結果當然失敗了。3. 簡短地討論一個分析模型的每個元素，指出每個元素對模型的貢獻，每個元素為什 么是唯一的以及每個元素所表示的概要信息。分析模型的元素基于場景的元素（用例圖）:使用基于場景的方法可以從用戶的視角描述系統。例如基本的 用例和基于模板的用例。通常的分析模型的第一步，作為創建其他模型的輸入。基于類的元素（類圖）：每個使用場景都暗示著當一個參與

21、者與系統交互時所操做的一組 對象，這些對象被分成類具有相似屬性和共同行為的事務集合。行為元素（狀態圖）：狀態指明了在某個特殊事件后采取什么動作。 面向信息流的模式：描述信息的轉換。第7章 構建分析模型重點：1. 簡單用幾句話嘗試說明結構化分析和面向對象分析的主要差別？結構化分析考慮數據和處理，其中數據作為獨立的實體轉換，數據對象建模定義了對 象的屬性和關系，操作對象的處理建模應當表明數據對象在系統內流動時處理如何轉換數 據。面向對象分析關注于定義類和影響客戶需求的類之間的協作方式。2. 有沒有可能在分析模型創建后立即開始編碼？解釋你的答案，然后說服反方。第8章設計工程重點：1. 如果軟件設計不

22、是程序（它確定不是），那么它是什么？是一套堅固、適用和賞心悅目的模型或設計表示。它包括數據、類設計，體系結構設計、 接口設計、構件設計。2. 當你“編寫”程序時你設計軟件嗎？軟件設計和編碼有什么不同嗎？設計。軟件設計是逐步細化一個可以工作的模型，而編碼是在生成一個可執行的程序。軟件設計 主要關注是否實現了用戶需求，必須從實現的角度說明數據域、功能域和行為域，是編碼 工作的指導。3. 用你自己的話說明軟件體系結構。系統結構是程序構件（模塊）的結構或組織，這些構件交互的形式以及這些構件所以數據 的結構。構件可以被推廣，用于代表主要的系統元素及其交互。第9章進行體系結構設計體系結構風格的分類以數據為

23、中心的體系結構數據流體系結構：當輸入數據經過一系列的計算和操作構件的變換形成輸出數據時，可以應用這種體系結 構。信息流被描述為單個數據項，被稱為事務，他可以沿多條路徑中的一條觸發其他數據流。調用和返回體系結構面向對象體系結構層次體系結構重點：1. 使用數據流程圖和處理敘述，描述一個具有明顯數據流特征和一個具有明顯事務流 特性的計算機系統。數據流特征：opengl管線事務流特性：銀行轉賬以房子或建筑的體系結構作比喻，與軟件體系結構進行對比。傳統的建筑體系結構學科和軟 件體系結構有何相似之處？有何不同之處？第10章 構件級設計建模構件：系統中某一定型化的、可配置的和可替換的部件，該部件封裝并暴露了

24、一些列接口。 內聚性：內聚性cohesion意味著構件或者類只封裝那些相互關聯密切，以及與構件或類自 身有密切關系的屬性和操作。耦合性：類之間彼此聯系程度的一種定性度量第11章完成用戶界面設計黃金規則置用戶于控制之下；以不強迫用戶進入不必要的或不希望的動作的方式來定義交互模式 提供靈活度的交互。允許用戶交互被中斷和撤銷。當技能級別增長時可以使交互流線化并允許定制交互 使用戶與內部技術細節隔離開來。設計允許用戶與出現在屏幕上的對象直接交互。減少用戶的記憶負擔； 減少對短期記憶的要求。 建立有意義的缺省。 定義直觀的快捷方式。 界面的視覺布局應該基于真實世界的象征。 以不斷進展的方式揭示信息。保持

25、界面一致性。允許用戶將當前任務放入有意義的環境中在應用系統家族內保持一致性。如果過去的交互模型已經建立起了用戶期望，除非有不得已的理由，否則不要改變它重點：1. 試給出兩個附加的“降低用戶記憶負擔”、“保持界面一致性”的設計原則。2. 假設你被邀請開發一個基于 WEB的家庭銀行系統。請給出用戶模型、設計模型、 心理模型和實現模型。第12章軟件測試策略單元測試設卄軟件測試需要計劃和執行一系列的測試步驟單元測試集成測試 確認測試 系統測試重點：1. 用自己的話描述驗證與確認的不同。兩者都要使用測試用例設計方法和測試策略嗎？驗證是確保軟件正確的實現某一特定功能的一些列活動；確認是指確保開發的軟件可追溯到用戶需求的另外一系列活動。都需要02. 誰應該完成確認測試一一是軟件開發人員還是軟件使用者，說