華南農(nóng)業(yè)大學15年軟件工程復習提綱

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

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

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

4、行與維護7. 瀑布模型特征:接受上一階段的結(jié)果作為本階段的輸入利用這一輸入實施本階段應完成的活動對本階段的工作進行評審將本階段的結(jié)果作為輸出，傳遞給下一階段。優(yōu)點：可強迫開發(fā)人員采用規(guī)范的方法。嚴格地規(guī)定了每個階段必須提交的文檔。要求每個階段的所有產(chǎn)品都必須經(jīng)過質(zhì)量保證小組的仔細驗證。缺點:Ø 缺乏靈活性，難以適應需求不明確或需求經(jīng)常變化的軟件開發(fā)。Ø 開發(fā)早期存在的問題往往要到交付使用時才發(fā)現(xiàn)，維護代價大。8. 演化模型許多軟件項目在開發(fā)早期對軟件需求的認識是模糊的、不確定的，因此軟件很難一次開發(fā)成功可以在獲取了一組基本的需求后，通過快速分析構(gòu)造出該軟件的一個初始可運行版

5、本，稱之謂原型（prototype），然后根據(jù)用戶在試用原型的過程中提出的意見和建議、或者增加新的需求，對原型進行改造，獲得原型的新版本，重復這一過程，最終得到令客戶滿意的軟件產(chǎn)品演化模型的開發(fā)過程就是從構(gòu)造初始的原型出發(fā)，逐步將其演化成最終軟件產(chǎn)品的過程演化模型適用于對軟件需求缺乏準確認識的情況典型的演化模型有：增量模型、原型模型、螺旋模型9. 增量模型增量模型將軟件的開發(fā)過程分成若干個日程時間交錯的線性序列，每個線性序列產(chǎn)生軟件的一個可發(fā)布的“增量”版本，后一個版本是對前一版本的修改和補充，重復增量發(fā)布的過程，直至產(chǎn)生最終的完善產(chǎn)品。增量模型融合了瀑布模型的基本成分（重復地應用）和演化模型

6、的迭代特征。增量模型強調(diào)每一個增量都發(fā)布一個可運行的產(chǎn)品。增量模型特別適用于：Ø 1.需求經(jīng)常變化的軟件開發(fā)Ø 2.市場急需而開發(fā)人員和資金不能在設定的市場期限之前實現(xiàn)一個完善的產(chǎn)品的軟件開發(fā)。增量模型能有計劃地管理技術(shù)風險，如早期增量版本中避免采用尚未成熟的技術(shù)。10. 原型與原型模型原型（prototype）是預期系統(tǒng)的一個可執(zhí)行版本，它反映了系統(tǒng)性質(zhì)（如功能、計算結(jié)果等）的一個選定的子集。一個原型不必滿足目標軟件的所有約束，其目的是能快速、低成本地構(gòu)建原型。原型的類型：1.探索型（exploratory prototyping）目的是要弄清目標系統(tǒng)的要求，確定所希望的

7、特性，并探討多種方案的可行性2.實驗型（experimental prototyping）目的是驗證方案或算法的合理性，它是在大規(guī)模開發(fā)和實現(xiàn)前，用于考核方案是否合適，規(guī)格說明是否可靠3.演化型（evolutionary prototyping）目的是將原型作為目標系統(tǒng)的一部分，通過對原型的多次改進，逐步將原型演化成最終的目標系統(tǒng).原型的使用策略：1.廢棄（throw away）策略主要用于探索型和實驗型原型的開發(fā)。這種原型通常被廢丟，然后根據(jù)探索或?qū)嶒灥慕Y(jié)果用良好的結(jié)構(gòu)和設計思想重新設計目標系統(tǒng)Ø 2.追加（add on）策略主要用于演化型原型的開發(fā)。這種原型通常是實現(xiàn)了目標系統(tǒng)中

8、已明確定義的特性的一個子集，通過對它的不斷修改和擴充，逐步追加新的要求，最后使其演化成最終的目標系統(tǒng)原型可作為單獨的過程模型使用，它也可作為一種方法或?qū)崿F(xiàn)技術(shù)應用于其它的過程模型中11. 螺旋模型是瀑布模型和演化模型的結(jié)合，并增加了風險分析螺旋模型沿著螺線旋轉(zhuǎn)，在四個象限上分別表達四個方面的活動，即：1.制定計劃：確定軟件目標，選定實施方案，弄清項目開發(fā)的限制條件2.風險分析：評價所選的方案，識別風險，消除風險3.工程實施：實施軟件開發(fā)，驗證工作產(chǎn)品4.客戶評估：評價開發(fā)工作，提出修正建議螺旋模型出現(xiàn)了一些變種，它可以有3到6個任務區(qū)域螺旋模型指引的軟件項目開發(fā)沿著螺線自內(nèi)向外旋轉(zhuǎn)，每旋轉(zhuǎn)一圈

9、，表示開發(fā)出一個更為完善的新軟件版本如果發(fā)現(xiàn)風險太大，開發(fā)者和客戶無法承受，則項目就可能因此而終止多數(shù)情況下沿著螺線的活動會繼續(xù)下去，自內(nèi)向外，逐步延伸，最終得到所期望的系統(tǒng)12. 組成基于計算機的系統(tǒng)由哪些元素組成軟件、硬件、人員、數(shù)據(jù)庫、文檔和規(guī)程13. 系統(tǒng)工程的任務定義：計算機系統(tǒng)工程是一個問題求解的活動，其目的是分析基于計算機的系統(tǒng)的功能、性能、等要求，并把它們分配到基于計算機系統(tǒng)的各個系統(tǒng)元素中，確定它們的約束條件和接口任務：識別用戶的要求標識系統(tǒng)的功能和性能范圍，確定系統(tǒng)的功能、性能、約束和接口14. 可行性分析開發(fā)一個基于計算機的系統(tǒng)通常都受到資源（人力、財力、設備等）和時間上

10、的限制，可行性分析主要從經(jīng)濟、技術(shù)、法律等方面分析所給出的解決方案是否可行，能否在規(guī)定的資源和時間的約束下完成可分為：經(jīng)濟可行性分析，技術(shù)可行性分析，法律可行性分析15. 需求工程的概念需求工程師應用已證實有效的技術(shù)與方法開展需求分析，確定客戶需求，幫助分析人員理解問題，評估可行性，協(xié)商合理的解決方案，無歧義地規(guī)約方案，確認規(guī)約以及將規(guī)約轉(zhuǎn)換到可運行的系統(tǒng)時的管理需求。16. 需求工程的六個階段需求獲取、需求分析與協(xié)商、系統(tǒng)建模、需求規(guī)約、需求驗證和需求管理17. 軟件需求的定義軟件需求是指用戶對目標軟件系統(tǒng)在功能，行為，性能，設計約束等方面的期望。18. 需求獲取的方法與策略1. 建立需求獲

11、取人員（通常被稱為系統(tǒng)分析員）與用戶順暢的通信途徑2. 與客戶交談，向用戶提問題，通過訪談與會議3. 觀察用戶工作流程，觀察用戶的操作4. 組成聯(lián)合小組5. 實例分析19. 常用的需求分析方法面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法 (SA)面向數(shù)據(jù)結(jié)構(gòu)的分析方法 面向?qū)ο蟮姆治龇椒?(OOA)20. 軟件的需求規(guī)約主要包含哪些內(nèi)容引言：陳述軟件目標，在基于計算機的系統(tǒng)語境內(nèi) 進行描述。信息描述：給出軟件必須解決問題的詳細描述，記 錄信息內(nèi)容和關系、流和結(jié)構(gòu)。功能描述：描述解決問題所需的每個功能。其中包 括，為每個功能說明一個處理過程；敘述設計約 束；敘述性能特征；用一個或多個圖形來形象地表 示軟件的整體結(jié)

12、構(gòu)和軟件功能與其他系統(tǒng)元素間的 相互影響。行為描述：描述作為外部事件和內(nèi)部產(chǎn)生的控制特 征的軟件操作。檢驗標準：描述檢驗系統(tǒng)成功的標志。即對系統(tǒng)進 行什么樣的測試，得到什么樣的結(jié)果，就表示系統(tǒng) 已經(jīng)成功實現(xiàn)了。它是“確認測試”的基礎。參考書目：包含了對所有和該軟件相關的文檔的引 用，其中包括其他的軟件工程文檔、技術(shù)參考文獻、 廠商文獻以及標準。附錄：包含了規(guī)約的補充信息，表格數(shù)據(jù)、算法的 詳細描述、圖表以及其他材料。21. 軟件設計的任務（注意在回答接口設計的時候，需要講清楚3個方面的內(nèi)容）使用一種設計方法，軟件分析模型中通過數(shù)據(jù)、功能和行為模型所展示的軟件需求的信息被傳送給設計階段，產(chǎn)生數(shù)據(jù)

13、/類設計、體系結(jié)構(gòu)設計、接口設計、部件級設計。（接口設計主要包括三個方面：設計軟件模塊間的接口設計模塊和其他非人的信息生產(chǎn)者和消費者(比如外部實體)之間的接口設計人(用戶)和計算機間的接口）22. 軟件設計的目標(1)設計必須實現(xiàn)分析模型中描述的所有顯式需求，必須滿足用戶希望的所有隱式需求。(2)設計必須是可讀、可理解的，使得將來易于編程、易于測試、易于維護。(3)設計應從實現(xiàn)角度出發(fā)，給出與數(shù)據(jù)、功能、行為相關的軟件全貌。23. 衡量軟件設計的技術(shù)標準(1) 設計出來的結(jié)構(gòu)應是分層結(jié)構(gòu)，從而建立軟件成份之間的控制。(2) 設計應當模塊化，從邏輯上將軟件劃分為完成特定功能或子功能的部件。(3)

14、 設計應當既包含數(shù)據(jù)抽象，也包含過程抽象。(4) 設計應當建立具有獨立功能特征的模塊。(5) 設計應當建立能夠降低模塊與外部環(huán)境之間復雜連接的接口。(6) 設計應能根據(jù)軟件需求分析獲取的信息，建立可驅(qū)動、可重復的方法。24. 軟件設計的過程(1) 制定規(guī)范(2) 體系結(jié)構(gòu)和接口設計(3) 數(shù)據(jù)/類設計(4) 部件級（過程）設計(5) 編寫設計文檔(6) 設計評審25. 數(shù)據(jù)抽象與過程抽象過程抽象（也稱功能抽象）是指任何一個完成明確定義功能的操作都可被使用者當作單個實體看待，盡管這個操作實際上是由一系列更低級的操作來完成的。數(shù)據(jù)抽象是指定義數(shù)據(jù)類型和施加于該類型對象的操作，并限定了對象的取值范圍

15、，只能通過這些操作修改和觀察數(shù)據(jù)。26. 模塊模塊是數(shù)據(jù)說明、可執(zhí)行語句等程序?qū)ο蟮募?，它是單獨命名的，并且可以通過名字來訪問。27. 信息隱藏的概念每個模塊的實現(xiàn)細節(jié)對于其它模塊來說應該是隱蔽的 塊中所包含的信息（包括數(shù)據(jù)和過程）不允許其它不需要這些信息的模塊使用 通過信息隱蔽，則可定義和實施對模塊的過程細節(jié)和局部數(shù)據(jù)結(jié)構(gòu)的存取限制 28. 內(nèi)聚與耦合的概念內(nèi)聚（cohesion）是一個模塊內(nèi)部各個元素彼此結(jié)合的緊密程度的度量 耦合(coupling)是模塊之間的相對獨立性（互相連接的緊密程度）的度量29. 功能內(nèi)聚的概念功能內(nèi)聚 ：指一個模塊中各個部分都是為完成一項具體功能而協(xié)同工作，緊

16、密聯(lián)系，不可分割的。30. 數(shù)據(jù)耦合的概念數(shù)據(jù)耦合：兩個模塊之間僅通過參數(shù)表傳遞簡 單數(shù)據(jù)，則稱為數(shù)據(jù)耦合。31. 調(diào)用和返回風格的體系結(jié)構(gòu)這種風格使一個軟件設計者設計出非常容易修改和擴充的體系結(jié)構(gòu)。包含：主程序/子程序風格體系結(jié)構(gòu) 和 遠程過程調(diào)用風格的體系結(jié)構(gòu) 32. 部件級設計階段的主要工作為每個部件確定采用的算法，選擇某種適當?shù)墓ぞ弑磉_算法的過程，編寫部件的詳細過程性描述； 確定每一部件內(nèi)部使用的數(shù)據(jù)結(jié)構(gòu)； 在部件級設計結(jié)束時，應該把上述結(jié)果寫入部件級設計說明書，并且通過復審形成正式文檔，作為下一階段（編碼階段）的工作依據(jù)。 33. 設計規(guī)約主要包含哪些內(nèi)容1. 工作范圍2. 體系結(jié)構(gòu)

17、設計3. 數(shù)據(jù)設計4. 接口設計5. 各部件的過程設計6. 運行設計7. 出錯處理設計8. 安全保密設計9. 需求/設計交叉索引10. 測試部分11. 特殊注解12. 附錄34. 結(jié)構(gòu)化分析與設計（一整章內(nèi)容）一種較為流行的定義是：“如果一個程序的代碼塊僅僅通過順序、選擇和循環(huán)這三種基本控制結(jié)構(gòu)進行連結(jié)，并且每個代碼塊只有一個入口和一個出口，則稱這個程序是結(jié)構(gòu)化的”。 歷史上克努特爭論過這個問題隨著面向?qū)ο蠛蛙浖陀玫刃碌能浖_發(fā)方法和技術(shù)的發(fā)展，更現(xiàn)實、更有效的開發(fā)途徑可能是自頂向下和自底向上兩種方法有機的結(jié)合。35. 結(jié)構(gòu)化分析模型有哪些實體-關系圖，數(shù)據(jù)流圖，數(shù)據(jù)字典，狀態(tài)轉(zhuǎn)換圖，控制規(guī)

18、約，加工規(guī)約，數(shù)據(jù)對象描述36. 系統(tǒng)響應時間的概念系統(tǒng)響應時間指從用戶執(zhí)行某個控制動作（如按回車鍵或點鼠標）到軟件作出響應（期望的輸出或動作）的時間。系統(tǒng)響應時間長會使用戶感到不安和沮喪。穩(wěn)定的響應時間（如1秒）比不定的響應時間如0.1秒到2.5秒）要好。37. 人機界面設計時的常見問題有哪些系統(tǒng)響應時間，用戶求助設施（user help facilities），錯誤信息處理，命令標記（command labeling） 38. 人機界面設計的黃金原則是什么讓用戶擁有控制權(quán) 減少用戶的記憶負擔 保持界面一致39. 可用性與可用性測試可用性指的是產(chǎn)品的使用效率、易學性和舒適程度?？捎眯詼y試：對

19、界面進行可用性測試和評價是確保產(chǎn)品可用性的重要手段，通過各種可用性測試及早發(fā)現(xiàn)界面存在的可用性問題，不僅可以節(jié)約開發(fā)成本，提高產(chǎn)品的品質(zhì)，還可以降低用戶使用產(chǎn)品的心理負荷，減少操作錯誤，提高工作效率以及對產(chǎn)品的認可度和滿意度。在進行可用性測試前，設計者需要制訂出具體詳細的測試計劃，包括任務列表、主觀滿意標準以及所要詢問的相關問題。同時，必須確定參與測試的用戶數(shù)目、類型和來源。可用性測試可以要求用戶完成一系列任務，對用戶的完成過程進行記錄，再對記錄進行評審。這可以給設計人員很大的啟發(fā)，及時發(fā)現(xiàn)缺陷并改正。局限性：首先，它強調(diào)的是首次使用的情況，其次只能涉及到部分的界面。因為可用性測試不能延續(xù)太長

20、時間，很難確定長時間使用后的情況。 40. 標識符命名需要注意的問題1.選擇含義明確的名字，使其能正確提示標識符所代表的實體Þ 例如，表示總量的變量名用Total，表示平均值的用Average等2.名字不要太長，太長會增加打字量，且易出錯。必要時可使用縮寫3.不用相似的名字，相似的名字容易混淆，不易發(fā)現(xiàn)錯誤Þ 如cm,cn,cmn,cnm,cnn,cmm41. 序言性注釋通常置于每個程序模塊的開頭部分，主要描述：§ 1.模塊的功能§ 2.模塊的接口：包括調(diào)用格式、參數(shù)的解釋、該模塊需要調(diào)用的其它子模塊名§ 3.重要的局部變量：包括用途、約束和限

21、制條件§ 4.開發(fā)歷史：包括模塊的設計者、評審者、評審日期、修改日期以及對修改的描述42. 書寫功能性注釋需要主要哪些問題1.注解要正確，錯誤的注解比沒有注解更壞；2.為程序段作注解，而不是為每一個語句作注解；3.用縮進和空行，使程序與注釋容易區(qū)分；4.注解應提供一些從程序本身難以得到的信息，而不是語句的重復。43. 編寫程序時，對數(shù)據(jù)說明應該注意哪些問題1.數(shù)據(jù)說明的次序應當規(guī)范化2.說明語句中變量安排有序化3.使用注解說明復雜數(shù)據(jù)結(jié)構(gòu)44. 測試用例的概念測試用例（Test Case）是為某個特殊目標而編制的一組測試輸入、執(zhí)行條件以及預期結(jié)果，以便測試某個程序路徑或核實是否滿足某

22、個特定需求。45. 測試目的發(fā)現(xiàn)軟件中的錯誤和缺陷，并加以糾正。46. 白盒測試與黑盒測試的概念白盒測試（又稱為結(jié)構(gòu)測試）把測試對象看作一個透明的盒子，測試人員根據(jù)程序內(nèi)部的邏輯結(jié)構(gòu)及有關信息設計測試用例，檢查程序中所有邏輯路徑是否都按預定的要求正確地工作黑盒測試（又稱行為測試）把測試對象看做一個黑盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能需求47. 白盒測試方法及測試用例設計邏輯覆蓋測試邏輯表達式錯誤敏感的測試基本路徑測試數(shù)據(jù)流測試循環(huán)測試48. 黑盒測試方法及測試用例設計等價類劃分邊界值分析比較測試錯誤猜測因果圖49. 各種邏輯覆蓋準則以