1、精選優質文檔-傾情為你奉上2015軟件工程復習提綱一、試卷的分值分布如下：判斷題10分、選擇題10分、名詞解釋和簡答題50分、測試用例設計10分、結構化分析與設計20分。大題里面，測試用例設計的白盒方法考邏輯覆蓋中的某種，黑盒方法考等價類法；結構化分析與設計則重點考察數據流圖、數據字典、加工規約、數據庫分析設計等。二、去年試題老師已經提供，此處不在給出。三、主要知識點如下：1. 軟件的概念計算機系統中與硬件相互依存的另一部分，它是包括程序、數據及其相關文檔的完整集合。2. 軟件發展的3個階段（時間、標志、開發（組織）的方式）1946-1956 計算機問世到高級程序語言出現前1956-1968

2、高級程序語言出現到軟件工程出現前1968-至今 軟件工程出現到現在3. 軟件的特點 vs 硬件軟件是一種邏輯實體，而不是具體的物理實體，因而它具有抽象性。軟件是通過人們的智力活動，把知識與技術轉化成信息的一種產品，是在研制、開發中被創造出來的。在軟件的運行和使用期間，沒有硬件那樣的機械磨損、老化問題。軟件的開發和運行經常受到計算機系統的限制，對計算機系統有著不同程度的依賴性。軟件的開發至今尚未完全擺脫手工的開發方式。軟件的開發費用越來越高，成本相當昂貴。4. 軟件的分類（1）系統軟件、支持軟件、應用軟件（2）按工作方式劃分：實時處理軟件，分時軟件，交互式軟件，批處理軟件。（3） 按軟件服務對象

3、劃分：項目軟件，產品軟件。（4）按使用的頻度進行劃分一次使用，頻繁使用。（5）按軟件失效的影響進行劃分高可靠性軟件，一般可靠性軟件。 5. 軟件工程的定義是指導計算機軟件開發和維護的工程學科。采用工程的概念、原理、技術和方法來開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來。6. 軟件生存周期的概念及若干個階段一個軟件從定義到開發、使用和維護，直到最終被棄用，要經歷一個漫長的時期，通常把軟件經歷的這個漫長的時期稱為生存周期。軟件生存周期一般可分為以下階段： 問題定義 需求分析與可行性研究 設計 編碼 測試 運行與維護7. 瀑布模型特征:接受上一階段的結果

4、作為本階段的輸入利用這一輸入實施本階段應完成的活動對本階段的工作進行評審將本階段的結果作為輸出，傳遞給下一階段。優點：可強迫開發人員采用規范的方法。嚴格地規定了每個階段必須提交的文檔。要求每個階段的所有產品都必須經過質量保證小組的仔細驗證。缺點: 缺乏靈活性，難以適應需求不明確或需求經常變化的軟件開發。 開發早期存在的問題往往要到交付使用時才發現，維護代價大。8. 演化模型許多軟件項目在開發早期對軟件需求的認識是模糊的、不確定的，因此軟件很難一次開發成功可以在獲取了一組基本的需求后，通過快速分析構造出該軟件的一個初始可運行版本，稱之謂原型（prototype），然后根據用戶在試用原型的過程中提

5、出的意見和建議、或者增加新的需求，對原型進行改造，獲得原型的新版本，重復這一過程，最終得到令客戶滿意的軟件產品演化模型的開發過程就是從構造初始的原型出發，逐步將其演化成最終軟件產品的過程演化模型適用于對軟件需求缺乏準確認識的情況典型的演化模型有：增量模型、原型模型、螺旋模型9. 增量模型增量模型將軟件的開發過程分成若干個日程時間交錯的線性序列，每個線性序列產生軟件的一個可發布的“增量”版本，后一個版本是對前一版本的修改和補充，重復增量發布的過程，直至產生最終的完善產品。增量模型融合了瀑布模型的基本成分（重復地應用）和演化模型的迭代特征。增量模型強調每一個增量都發布一個可運行的產品。增量模型特別

6、適用于： 1.需求經常變化的軟件開發 2.市場急需而開發人員和資金不能在設定的市場期限之前實現一個完善的產品的軟件開發。增量模型能有計劃地管理技術風險，如早期增量版本中避免采用尚未成熟的技術。10. 原型與原型模型原型（prototype）是預期系統的一個可執行版本，它反映了系統性質（如功能、計算結果等）的一個選定的子集。一個原型不必滿足目標軟件的所有約束，其目的是能快速、低成本地構建原型。原型的類型：1.探索型（exploratory prototyping）目的是要弄清目標系統的要求，確定所希望的特性，并探討多種方案的可行性2.實驗型（experimental prototyping）目的

7、是驗證方案或算法的合理性，它是在大規模開發和實現前，用于考核方案是否合適，規格說明是否可靠3.演化型（evolutionary prototyping）目的是將原型作為目標系統的一部分，通過對原型的多次改進，逐步將原型演化成最終的目標系統.原型的使用策略：1.廢棄（throw away）策略主要用于探索型和實驗型原型的開發。這種原型通常被廢丟，然后根據探索或實驗的結果用良好的結構和設計思想重新設計目標系統 2.追加（add on）策略主要用于演化型原型的開發。這種原型通常是實現了目標系統中已明確定義的特性的一個子集，通過對它的不斷修改和擴充，逐步追加新的要求，最后使其演化成最終的目標系統原型可

8、作為單獨的過程模型使用，它也可作為一種方法或實現技術應用于其它的過程模型中11. 螺旋模型是瀑布模型和演化模型的結合，并增加了風險分析螺旋模型沿著螺線旋轉，在四個象限上分別表達四個方面的活動，即：1.制定計劃：確定軟件目標，選定實施方案，弄清項目開發的限制條件2.風險分析：評價所選的方案，識別風險，消除風險3.工程實施：實施軟件開發，驗證工作產品4.客戶評估：評價開發工作，提出修正建議螺旋模型出現了一些變種，它可以有3到6個任務區域螺旋模型指引的軟件項目開發沿著螺線自內向外旋轉，每旋轉一圈，表示開發出一個更為完善的新軟件版本如果發現風險太大，開發者和客戶無法承受，則項目就可能因此而終止多數情況

9、下沿著螺線的活動會繼續下去，自內向外，逐步延伸，最終得到所期望的系統12. 組成基于計算機的系統由哪些元素組成軟件、硬件、人員、數據庫、文檔和規程13. 系統工程的任務定義：計算機系統工程是一個問題求解的活動，其目的是分析基于計算機的系統的功能、性能、等要求，并把它們分配到基于計算機系統的各個系統元素中，確定它們的約束條件和接口任務：識別用戶的要求標識系統的功能和性能范圍，確定系統的功能、性能、約束和接口14. 可行性分析開發一個基于計算機的系統通常都受到資源（人力、財力、設備等）和時間上的限制，可行性分析主要從經濟、技術、法律等方面分析所給出的解決方案是否可行，能否在規定的資源和時間的約束下

10、完成可分為：經濟可行性分析，技術可行性分析，法律可行性分析15. 需求工程的概念需求工程師應用已證實有效的技術與方法開展需求分析，確定客戶需求，幫助分析人員理解問題，評估可行性，協商合理的解決方案，無歧義地規約方案，確認規約以及將規約轉換到可運行的系統時的管理需求。16. 需求工程的六個階段需求獲取、需求分析與協商、系統建模、需求規約、需求驗證和需求管理17. 軟件需求的定義軟件需求是指用戶對目標軟件系統在功能，行為，性能，設計約束等方面的期望。18. 需求獲取的方法與策略1. 建立需求獲取人員（通常被稱為系統分析員）與用戶順暢的通信途徑2. 與客戶交談，向用戶提問題，通過訪談與會議3. 觀察

11、用戶工作流程，觀察用戶的操作4. 組成聯合小組5. 實例分析19. 常用的需求分析方法面向數據流的結構化分析方法 (SA)面向數據結構的分析方法 面向對象的分析方法 (OOA)20. 軟件的需求規約主要包含哪些內容引言：陳述軟件目標，在基于計算機的系統語境內 進行描述。信息描述：給出軟件必須解決問題的詳細描述，記 錄信息內容和關系、流和結構。功能描述：描述解決問題所需的每個功能。其中包 括，為每個功能說明一個處理過程；敘述設計約 束；敘述性能特征；用一個或多個圖形來形象地表 示軟件的整體結構和軟件功能與其他系統元素間的 相互影響。行為描述：描述作為外部事件和內部產生的控制特 征的軟件操作。檢驗

12、標準：描述檢驗系統成功的標志。即對系統進 行什么樣的測試，得到什么樣的結果，就表示系統 已經成功實現了。它是“確認測試”的基礎。參考書目：包含了對所有和該軟件相關的文檔的引 用，其中包括其他的軟件工程文檔、技術參考文獻、 廠商文獻以及標準。附錄：包含了規約的補充信息，表格數據、算法的 詳細描述、圖表以及其他材料。21. 軟件設計的任務（注意在回答接口設計的時候，需要講清楚3個方面的內容）使用一種設計方法，軟件分析模型中通過數據、功能和行為模型所展示的軟件需求的信息被傳送給設計階段，產生數據/類設計、體系結構設計、接口設計、部件級設計。（接口設計主要包括三個方面：設計軟件模塊間的接口設計模塊和其

13、他非人的信息生產者和消費者(比如外部實體)之間的接口設計人(用戶)和計算機間的接口）22. 軟件設計的目標(1)設計必須實現分析模型中描述的所有顯式需求，必須滿足用戶希望的所有隱式需求。(2)設計必須是可讀、可理解的，使得將來易于編程、易于測試、易于維護。(3)設計應從實現角度出發，給出與數據、功能、行為相關的軟件全貌。23. 衡量軟件設計的技術標準(1) 設計出來的結構應是分層結構，從而建立軟件成份之間的控制。(2) 設計應當模塊化，從邏輯上將軟件劃分為完成特定功能或子功能的部件。(3) 設計應當既包含數據抽象，也包含過程抽象。(4) 設計應當建立具有獨立功能特征的模塊。(5) 設計應當建立

14、能夠降低模塊與外部環境之間復雜連接的接口。(6) 設計應能根據軟件需求分析獲取的信息，建立可驅動、可重復的方法。24. 軟件設計的過程(1) 制定規范(2) 體系結構和接口設計(3) 數據/類設計(4) 部件級（過程）設計(5) 編寫設計文檔(6) 設計評審25. 數據抽象與過程抽象過程抽象（也稱功能抽象）是指任何一個完成明確定義功能的操作都可被使用者當作單個實體看待，盡管這個操作實際上是由一系列更低級的操作來完成的。數據抽象是指定義數據類型和施加于該類型對象的操作，并限定了對象的取值范圍，只能通過這些操作修改和觀察數據。26. 模塊模塊是數據說明、可執行語句等程序對象的集合，它是單獨命名的，

15、并且可以通過名字來訪問。27. 信息隱藏的概念每個模塊的實現細節對于其它模塊來說應該是隱蔽的 塊中所包含的信息（包括數據和過程）不允許其它不需要這些信息的模塊使用 通過信息隱蔽，則可定義和實施對模塊的過程細節和局部數據結構的存取限制 28. 內聚與耦合的概念內聚（cohesion）是一個模塊內部各個元素彼此結合的緊密程度的度量 耦合(coupling)是模塊之間的相對獨立性（互相連接的緊密程度）的度量29. 功能內聚的概念功能內聚 ：指一個模塊中各個部分都是為完成一項具體功能而協同工作，緊密聯系，不可分割的。30. 數據耦合的概念數據耦合：兩個模塊之間僅通過參數表傳遞簡 單數據，則稱為數據耦合

16、。31. 調用和返回風格的體系結構這種風格使一個軟件設計者設計出非常容易修改和擴充的體系結構。包含：主程序/子程序風格體系結構 和 遠程過程調用風格的體系結構 32. 部件級設計階段的主要工作為每個部件確定采用的算法，選擇某種適當的工具表達算法的過程，編寫部件的詳細過程性描述； 確定每一部件內部使用的數據結構； 在部件級設計結束時，應該把上述結果寫入部件級設計說明書，并且通過復審形成正式文檔，作為下一階段（編碼階段）的工作依據。 33. 設計規約主要包含哪些內容1. 工作范圍2. 體系結構設計3. 數據設計4. 接口設計5. 各部件的過程設計6. 運行設計7. 出錯處理設計8. 安全保密設計9

17、. 需求/設計交叉索引10. 測試部分11. 特殊注解12. 附錄34. 結構化分析與設計（一整章內容）一種較為流行的定義是：“如果一個程序的代碼塊僅僅通過順序、選擇和循環這三種基本控制結構進行連結，并且每個代碼塊只有一個入口和一個出口，則稱這個程序是結構化的”。 歷史上克努特爭論過這個問題隨著面向對象和軟件復用等新的軟件開發方法和技術的發展，更現實、更有效的開發途徑可能是自頂向下和自底向上兩種方法有機的結合。35. 結構化分析模型有哪些實體-關系圖，數據流圖，數據字典，狀態轉換圖，控制規約，加工規約，數據對象描述36. 系統響應時間的概念系統響應時間指從用戶執行某個控制動作（如按回車鍵或點鼠

18、標）到軟件作出響應（期望的輸出或動作）的時間。系統響應時間長會使用戶感到不安和沮喪。穩定的響應時間（如1秒）比不定的響應時間如0.1秒到2.5秒）要好。37. 人機界面設計時的常見問題有哪些系統響應時間，用戶求助設施（user help facilities），錯誤信息處理，命令標記（command labeling） 38. 人機界面設計的黃金原則是什么讓用戶擁有控制權 減少用戶的記憶負擔 保持界面一致39. 可用性與可用性測試可用性指的是產品的使用效率、易學性和舒適程度。可用性測試：對界面進行可用性測試和評價是確保產品可用性的重要手段，通過各種可用性測試及早發現界面存在的可用性問題，不僅可

19、以節約開發成本，提高產品的品質，還可以降低用戶使用產品的心理負荷，減少操作錯誤，提高工作效率以及對產品的認可度和滿意度。在進行可用性測試前，設計者需要制訂出具體詳細的測試計劃，包括任務列表、主觀滿意標準以及所要詢問的相關問題。同時，必須確定參與測試的用戶數目、類型和來源。可用性測試可以要求用戶完成一系列任務，對用戶的完成過程進行記錄，再對記錄進行評審。這可以給設計人員很大的啟發，及時發現缺陷并改正。局限性：首先，它強調的是首次使用的情況，其次只能涉及到部分的界面。因為可用性測試不能延續太長時間，很難確定長時間使用后的情況。 40. 標識符命名需要注意的問題1.選擇含義明確的名字，使其能正確提示

20、標識符所代表的實體 例如，表示總量的變量名用Total，表示平均值的用Average等2.名字不要太長，太長會增加打字量，且易出錯。必要時可使用縮寫3.不用相似的名字，相似的名字容易混淆，不易發現錯誤 如cm,cn,cmn,cnm,cnn,cmm41. 序言性注釋通常置于每個程序模塊的開頭部分，主要描述： 1.模塊的功能 2.模塊的接口：包括調用格式、參數的解釋、該模塊需要調用的其它子模塊名 3.重要的局部變量：包括用途、約束和限制條件 4.開發歷史：包括模塊的設計者、評審者、評審日期、修改日期以及對修改的描述42. 書寫功能性注釋需要主要哪些問題1.注解要正確，錯誤的注解比沒有注解更壞；2.

21、為程序段作注解，而不是為每一個語句作注解；3.用縮進和空行，使程序與注釋容易區分；4.注解應提供一些從程序本身難以得到的信息，而不是語句的重復。43. 編寫程序時，對數據說明應該注意哪些問題1.數據說明的次序應當規范化2.說明語句中變量安排有序化3.使用注解說明復雜數據結構44. 測試用例的概念測試用例（Test Case）是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。45. 測試目的發現軟件中的錯誤和缺陷，并加以糾正。46. 白盒測試與黑盒測試的概念白盒測試（又稱為結構測試）把測試對象看作一個透明的盒子，測試人員根據程序內部的邏輯結構及有關信息設計測試用例，檢查程序中所有邏輯路徑是否都按預定的要求正確地工作黑盒測試（又稱行為測試）把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能需求47. 白盒測試方法及測試用例設計邏輯覆蓋測試邏輯表達式錯誤敏感的測試基本路徑測試數據流測試循環測試48. 黑盒測試方法及測試用例設計等價類劃分邊界值分析比較測試錯誤猜測因果圖49. 各種邏輯覆蓋準則以及它們之間的關系語句覆蓋判定覆蓋