專升本-填空-判斷-簡答題備選

1、填空題1. 基于計算機系統(tǒng)的軟件要素中的軟部件由 、和組成。（程序、數據、文檔）2. 軟件工程方法學分兩類： 方法學和方法學。（傳統(tǒng)or結構化or軟件生命周期、面向對象）3. 軟件工程的目標是在給定成本、 的前提下開發(fā)出高質量的、的軟件產品。（開發(fā)進度、滿足用戶要求）4. 是軟件生存期中的一系列相關軟件工程活動的集合，它由軟件規(guī)格說明、軟件設計與開發(fā)、軟件確認、軟件改進等活動組成。（軟件過程）5. 軟件工程釆用層次化的方法，每個層次都包括 、方法、三要素（工具、過程）6. 使用這一軟件過程模型可以讓用戶更多、 更早地參與需求分析過程。（快速原型）7. 描繪物理系統(tǒng)的傳統(tǒng)工具是。（系統(tǒng)流程圖）8

2、. 需求分析階段產生的文檔是 ，它的主要組成部分是 。（軟件需求規(guī)格說明書、數據流圖、數據字典）9. 數據流圖用圖形符號表示 、數據源及數據存儲。（數據源、加工/處理）10. 實體一關系圖是的基礎，它描述 、屬性及其關系。（數據模型、數據對象）11. 軟件設計的主要任務是根據 導出系統(tǒng)的實現方案。（軟件需求規(guī)格說明書）12. 一個模塊擁有的直屬下級模塊的個數稱為 ，一個模塊的直接上級模塊的個數稱為。（模塊的扇出、模塊的扇入）13. 將數據流圖映射為軟件結構時，所用映射方法涉及信息流的類型。其信息流分為和兩種類型。（變換型、事務型）14. 耦合的強弱取決于 的復雜性、進入或調用模塊的位置以及通過

3、界面?zhèn)魉蛿祿亩嗌俚?。（模塊間接口）15. 總體設計確定模塊的 ，而詳細設計確定模塊的 。（外部結構、內部結構）16. 軟件結構是以 為基礎而組成的一種控制層次結構。（模塊）17詳細設計的工具可分為 、和三大類。（圖形類、表格類、語言類）18. 軟件過程設計中最常用的技術和工具主要為程序流程圖、盒圖、和PDL語言。（判定表、判定樹、PAD圖）19. 詳細設計通常以 技術為邏輯基礎，因為從軟件工程觀點看，是軟件最重要的質量標準之一。（結構化程序設計、可理解性 or可讀性）20. 對于復雜數據中的數據元素的組成方式有 、和可選等四種基本類型。（順序、選擇、重復）21. 影響編碼質量的因素包括 、編

4、程準貝和 。（編程語言、編碼風格）22. 軟件維護的副作用副作用大致可分為三類：代碼副作用、 副作用、的副作用。（數據、文檔）23. 軟件測試的目的是 ,通常把測試方法分為 和兩大類。因為通常不可能做到 ，所以精心設計是保證達到測試目的所必需的。（發(fā)現并改正錯誤、黑盒法、白盒法、窮舉測試、測試用例）24. 進行軟件測試的關鍵是設計出的測試用例，測試用例應由和兩部分組成。（高效、輸入數據、預期的輸出結果）25. 單元測試過程應為測試模塊開發(fā)一個 和（或）若干個o（驅動模塊、存根模塊）26. 進行單元測試的依據是描述，單元測試應對模塊內所有重要的設計測試用例，以便發(fā)現模塊內部的錯誤。（詳細設計、執(zhí)

5、行通路）27. 確認測試應檢查軟件能否按合同要求進行工作，即是否滿足的確認標準。（軟件需求規(guī)格說明書）28. UML的類包含三個部分：類的名稱、 、。（類的屬性、類的操作）29. 類之間的繼承關系是現實世界中遺傳關系的模擬，它表示類之間的內在聯系以及對的共享。（屬性和操作）30. UML類之間的關系主要有 、聚集、和依賴。（關聯、泛化）31. 類A的一個操作調用類B的一個操作，且這兩個類之間不存在其他關系，那么類A和類B之間是關系。（依賴）32. 在面向對象的軟件中， 是對具有相同數據和相同操作的一組相似對象的定義； 是由某個特定的類所描述的一個具體對象。（類、實例）33. 面向對象方法用 分

6、解取代了傳統(tǒng)方法的 分解。（對象、功能）1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.判斷題計算機軟件由文檔和數據組成。（F ）軟件開發(fā)采用了軟件工程之后， 就不會發(fā)生軟件危機了。（F ）軟件工程使用的軟件工具能夠自動或半自動地支持軟件的開發(fā)、 管理和文檔的生成。（T ）一個好的開發(fā)人員應具備的素質和能力包括善于與周圍人員團結協作，良好的人際關系，善于聽取別人的意見。建立 （T ）缺乏處理大型軟件項目的經驗。是產生軟件危機的唯一原因。（F ）軟件開發(fā)小組人數越多越好。（F ）難以控制開發(fā)進度和工作量估計困難是軟件危機的主要表現

7、之一。（T ）面對日益增長的軟件需求，人們顯得力不從心。往往是產生軟件危機的原因之一。（T ）軟件需求是指用戶對目標軟件系統(tǒng)在功能、性能、行為、設計約束等方面的期望。（T ）系統(tǒng)規(guī)格說明是系統(tǒng)分析和定義階段生成的一種文檔。（T ）需求分析階段所生成的文檔主要是進度計劃和可行性研究報告。（F ）軟件就是完成特定功能的程序的集合。（F ）瀑布模型在實際的的項目中嚴格順序執(zhí)行就基本可以成功。（T ）快速原型技術的適用于軟件產品要求大量的用戶交互、 或產生大量的可視輸出、或設計一些復雜的算法等場合。（T ）只要實行嚴格的產品控制就不用擔心用戶隨意改需求。（T ）在可行性研究中最難決斷和最關鍵的問題是技

8、術可行性。（T ）流程圖用三個基本的控制構件“分支” ，“循環(huán)”，“重復”來表示。（F ）數據字典是關于數據的信息的集合， 也就是對數據流圖中包含的所有元素的定義的集合。（T ）系統(tǒng)分析階段和系統(tǒng)設計階段一般不考慮測試。（F ）改造程序結構， 要降低耦合度， 提高內聚度。（T ）一個軟件系統(tǒng)中可能會出現所有模塊之間沒有任何聯系的情況。（F ）采用信息隱藏原理指導模塊設計可以支持模塊的并行開發(fā)， 減少軟件測試和軟件維護的工作量。（T ）23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.數據流圖的分解速度應保持較高。 通常一個加工每次

9、可分解為 1020 個子加工。（F ）概要設計也稱總體設計，其過程由確定設計方案和結構設計兩個階段組成。 （T ）只有了解用戶、 了解任務， 才能設計出好的用戶界面。 一般單元測試不可以并行進行。（T ）（F ）測試最終是為了證明程序無錯誤。（F ）通常用數據流圖、數據字典和簡明算法描述表示系統(tǒng)的邏輯模型。（T ）數據流圖就是用來刻畫數據流和轉換的信息系統(tǒng)建模技術。（T ）軟件過程設計不用遵循 “自上而下，逐步求精 ”的原則和單入口單出口的結構化設計思想。（F ）判定表不適合做通用的設計工具， 不能表示順序結構、 循環(huán)結構。（T ）面向數據結構設計方法一般都包括下列任務：確定數據結構特征；用順

10、序、選擇和重復三種基本形式表示數據等步驟。（T ）結構化程序設計 SP 強調模塊采用自上而下逐步求精設計方法，單入口、單出口標準結構。（T ）盒圖的主要優(yōu)點之一是強制設計人員采用結構化設計方法。（T ）通常緊致性好的語言一致性就好。（F ）編程風格是在提高性能的前提下 ,有效地編排和組織程序以提高可讀性和可維護性。（F ）數據輸入的一般準則中包括保證信息顯示方式與數據輸入方式的協調一致；允許用戶定做輸入格式等內容。（T ）編碼時應盡可能使用全局變量。（F ）用戶本身的技能，個性上的差異，行為方式的不同，不會對人機界面使用造成影響。（F ）為提高可交互性一般應提高用戶對話、移動和思考的效率，即最

11、大可能地減少擊鍵次數， 縮短鼠標移動的距離， 避免使用戶產生無所適從的感覺。（T ）過程式程序設計語言的基本機制包括：消息傳送、數據類型的定義、多態(tài)、子時、控制結構,42. 只要完成了軟件的測試工作，將軟件產品交給用戶，軟件生命周期就結束了。（F）43. 模塊的扇入是指該模塊被其它模塊調用的個數，扇入應盡可能的小。（F ）44. 系統(tǒng)測試是把軟件、硬件和環(huán)境連在一起的全面測試。（T）45. 軟件測試是對軟件規(guī)格說明、軟件設計和編碼的最全面、最后的審查。（T）46. 軟件生命周期中，測試的工作量最大。（F ）47. 軟件測試的目的是為了證明一個軟件的設計沒有錯誤，只有沒有任何錯誤的軟件才能使用。

12、（F ）48. 測試計劃、測試用例、出錯統(tǒng)計和有關的分析報告一般不用長期保存。（F ）49. 軟件測試中，應該盡量窮盡所有的數據，以便保證測試的質量。（F ）50. 黑盒測試法可有效的檢查模塊的內部邏輯結構的正確性。（T ）51. 測試一般情況下是以白盒法為主黑盒法作為補充。（F ）52. 文檔記錄軟件開發(fā)活動和階段成果，具有永久性，可供人或機器閱讀。（T ）53. 結構化維護用于待維護的軟件的配置是完整的維護。（T ）54. 非結構化維護用于軟件的配置中只有源代碼維護。（T ）55. 完善性維護是提咼或完善軟件的性能。（T ）56. 定軟件項目進度表的途徑之一是軟件開發(fā)小組根據提供軟件產品的

13、最后期限從后往前安排時間。（T ）57. 重構工程也稱修復和改造工程，它是在逆向工程所獲信息的基礎上修改或重構已有的系統(tǒng)，產生系統(tǒng)的一個新版本。（T ）58. 對象是屬性和相關操作的封裝。（T ）59. 面向對象中的繼承是指子類能夠直接獲得父類已有的性質和特征，而無需重新定義。（T ）60. 面向對象設計是將面向對象分析所創(chuàng)建的分析模型進一步細化形成軟件設 計模型的過程。名詞解釋傳統(tǒng)方法學部分1.軟件工程14. 作用域27.Beta 測試2.軟件過程15. 控制域28.回歸測試3.軟件生命周期16. 扇出29.軟件維護4.軟件危機17. 扇入30.改正性維護5.結構化分析18. 模塊獨立性31

14、.完善性維護6.實體-聯系圖19. 結構化程序設計32.適應性維護7.數據字典20. 編碼風格33.預防性維護8.結構化設計21. 白盒測試34.軟件可維護性9.模塊化22. 黑盒測試35.軟件維護副作用10.逐步求精23. 單元測試36.可重用性11.信息隱藏24. 集成測試37.可靠性12.耦合25. 系統(tǒng)測試38.可用性13.內聚26. Alpha 測試名詞解釋面向對象方法學部分1.對象3. 繼承5.消息2.類4. 多態(tài)性簡答題1. 簡述軟件危機發(fā)生的原因。 答案：（1）軟件危機產生的客觀原因a. 軟件與硬件產品不同，軟件是“開發(fā)的”而非“制造的”。軟件的開發(fā)過程難以管理和控制，產品質量

15、也不好準確把握；b. 軟件沒有“磨損” ，但是它會不斷“退化” ；c. 現代的軟件都規(guī)模龐大，而程序的復雜性是隨其規(guī)模的擴大呈指數增加。軟件自身的特點，也使其不同于其它硬件產品的標準化，造成了開發(fā)和維護的困難。（ 2）軟件危機產生的主觀原因a. 對用戶的要求沒有完整和準確的認識就匆忙編寫程序是軟件開發(fā)失敗的主要原因；b. 對軟件的開發(fā)過程的認識不準確也是造成軟件危機的原因之一；c. 對軟件質量的重視不夠是造成軟件開發(fā)成本激增的主要原因。2. 簡述軟件危機的幾種常見表現形式。 答案：第一，軟件開發(fā)成本和進度估計極不準確。實際成本和開發(fā)進度往往超過預期。 第二，軟件產品質量較差，可靠性低。第三，

16、用戶對開發(fā)出來的軟件產品不滿意。 其原因一般是開發(fā)人員與用戶之間的交流不 充分，僅對用戶需求有了一個模糊的認識就匆忙開始寫程序。 這樣的結果就是用戶對于所謂 已經完成的軟件很不滿意。第四， 開發(fā)出來的軟件幾乎是不可維護的。 實際項目中的錯誤往往難以修改， 而且不能 適應軟硬件環(huán)境的變化，也無法添加用戶需要的一些新功能。第五，軟件產品缺少應有的文檔資料。這就導致了軟件開發(fā)、管理、審查、用戶交流及 后期維護等方面存在一系列的問題。第六， 軟件開發(fā)的生產率遠遠低于計算機硬件發(fā)展速度和用戶的需求， 造成了軟件產品 的供不應求。3. 可將軟件生存周期劃分為哪 3 個過程和哪 9 個階段。答案：（1）3

17、個過程是：軟件定義過程、軟件開發(fā)過程、軟件使用與維護過程。（2）9 個階段有：可行性研究、需求分析、概要設計、詳細設計、實現、組裝測試、驗收 測試、使用與維護、退役。4. 試述瀑布模型的優(yōu)點和缺點？答案：優(yōu)點：（ 1）各階段之間有依賴性和嚴格的順序性。 在瀑布模型中，每個階段的工作都依 賴前一階段的輸出文檔， 前一階段沒有完成就不能開始后一階段工作。 （2）推遲實現。 正是 由于嚴格的順序性， 使用瀑布模型開發(fā)的軟件產品 “面世”都相對較晚， 瀑布模型要求在分 析和設計階段清楚地區(qū)分邏輯設計和物理設計， 盡量將程序的物理實現推遲。 （ 3）嚴格的階 段質保。 為了避免最后的災難性后果， 瀑布模

18、型要求在每個階段都必須完成規(guī)定的文檔， 并 通過階段評審。 這樣可以盡可能地發(fā)現早期分析和設計的問題， 保證軟件產品質量、 減低開 發(fā)和維護成本。 （4）文檔驅動。 瀑布模型幾乎完全依賴于書面的文檔， 可以迫使開發(fā)人員采 用規(guī)范的方法，認真提交各個階段的文檔，為以后的維護工作打下良好的基礎。缺點：（ 1）瀑布模型導致了開發(fā)人員“阻塞”嚴重，開發(fā)小組中的很多人員需要等待其 他人員完成相關的任務； （ 2）實際項目很少嚴格遵守瀑布模型的順序， 這樣會造成很多混亂；（3）用戶在開始階段往往不能準確描述自己的需求，從而使項目在開始階段就存在不確定 性，而且可能在項目接近尾聲時發(fā)生重大缺陷，這些都是用戶

19、無法承受的。5. 簡述可行性研究的步驟。答案：進行可行性研究首先需要進一步分析和澄清問題定義， 初步確定項目的規(guī)模和目標， 確 定項目的約束和限制， 并將它們清楚的列出來。 然后分析員進行簡要的需求分析抽象出該項 目的邏輯結構， 建立邏輯模型。 再從邏輯模型出發(fā)，經過壓縮的設計， 探索出若干種可供選 擇的主要解決方案， 對于每一種解決方案都要分析它的可行性。 并為每個可行的解法制定一 個粗略的實現進度。6. 簡述采用信息隱藏原理指導模塊設計優(yōu)點。答案：信息隱蔽是指在設計中確定模塊時，使得一個模塊內包含的信息（過程或數據），對于不需要這些信息的其它模塊來說，是不能訪問的。通過信息隱蔽， 可以定義

20、和實施對模塊的過程細節(jié)和局部數據結構的存取限制。信息隱 蔽為軟件系統(tǒng)的修改、測試及以后的維護都帶來好處。信息隱蔽可以有效地防止錯誤的擴大 與傳播。7. 用SD方法將數據流圖轉換為軟件結構，簡述其過程。答案：確定罟總流的類型：飯定流界:將數據流閤換朋齒程序結構;提取以次控制結構:通過設計復審和啟發(fā)式策略精化結構。&簡述啟發(fā)式設計策略最常用的幾條。答案：（1）模塊獨立性準則。設計出軟件的初步結構后，應該審查分析這個結構，通過模塊 分解或合并，力求做到降低耦合提高內聚，保持模塊相對獨立性。（2）模塊的作用域應該在控制域內。一個模塊的影響范圍應在其控制范圍之內，且條 件判定所在的模塊應與受其影

21、響的模塊在層次上盡量接近。（3）軟件結構的形態(tài)特征準則。深度和寬度能粗略地反映系統(tǒng)的規(guī)模和復雜程度。從形態(tài)上看，軟件結構中各模塊應滿足頂層扇出數較高一些，中間層扇出數較低一些， 底層扇入數較高一些。（4）模塊大小準則。在考慮模塊的獨立性時，為了增加可理解性，模塊的大小最好在50-150條語句左右。（5） 模塊的接口準則。a.模塊接口設計要簡單，以便降低復雜程度和冗余度。b.設計功能可預測并能得到驗證的模塊。c.適當劃分模塊規(guī)模，以保持其獨立性。9. 簡述軟件維護的困難主要體現在哪幾個方面？答案：（1）理解別人編的程序通常非常困難，而且困難程度隨著軟件配置成份的減少而迅速 增加，如果僅有程序代碼

22、而沒有程序注釋，則會出現嚴重的問題；（2）分析與理解軟件文檔是進行維護的第一步，但是需要維護的軟件往往沒有合格的 開發(fā)文檔，或者文檔資料明顯不足；（3）軟件開發(fā)人員和軟件維護人員在時間上的差異。在對軟件進行維護時，不要指望 有開發(fā)人員對軟件進行仔細說明。（4）絕大多數軟件在設計時沒有考慮未來的修改。除非使用強調模塊獨立原理的設計 方法學，否則修改軟件既困難又容易發(fā)生差錯。（5） 軟件維護工作容易遇到挫折，因而軟件維護是一項大多數人都不愿意從事的工作。10. 試述軟件測試過程。答案：單元測試保證模塊正確工作，多采用白盒測試；綜合測試保證模塊集成到一起后正常工作，多為黑盒測試，并鋪以白盒技術； 確認測試保證軟件需求的滿足，采用黑盒測試； 系統(tǒng)測試保證軟件與其他系統(tǒng)元素合成后達到系統(tǒng)各項性能要求。11. 黑盒測試完全不考慮程序的內部結構和處理過程，測試僅在程序界面上進 行。因此黑盒測試設計測試用例旨在說明什么？答案： 黑盒測試完全不考慮程序的內部結構和處理過程， 測試僅在程序界面上進行。 因此黑 盒測試設計測試用例旨在說明：軟件的功能是否可操作；程序能否適當地接收輸入數據并產生正確的輸出結果； 能否保持外部信息 （ 如數據文件 ） 的完整性。12. 簡述在測試中采用自頂向下集成和自底向上集成的優(yōu)缺點。答案：a. 自頂向下集成：優(yōu)點在于能盡早地對程序的主要控制和決策機制進行檢驗，因此較