軟件工程相關(guān)題目匯總-資料下載頁
2025-03-26 04:21本頁面
【正文】 控制這些特性的變更、記錄和報告變更的過程和狀態(tài)，并驗證它們與需求是否一致。軟件配置管理主要有：標識、版本控制、變化控制、配置審計和配置狀態(tài)報告。正確 錯誤 35：8軟件結(jié)構(gòu)一般要求頂層扇出比較少，中層扇出較高，底層模塊有高扇入。正確 錯誤 36：6傳統(tǒng)結(jié)構(gòu)化分析方法就是用抽象模型的概念，按照軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guān)系，自頂向下逐層分解，直到找到滿足性能要求的所有可實現(xiàn)的軟件為止。正確 錯誤 37：8McCabe方法的核心是：通過定量分析程序中分支個數(shù)或循環(huán)個數(shù)，對軟件測試難度進行定量度量，對軟件最終的可靠性進行預測。正確 錯誤 38：2軟件配置管理是在軟件項目啟動時就開始的，并且一直持續(xù)到軟件退役后才終止的一組跟蹤和控制活動。正確 錯誤 39：4實體類指系統(tǒng)要記錄和維護的信息；邊界類指系統(tǒng)和外部要素間交互的邊界；控制類指Use Case中行為的協(xié)調(diào)。正確 錯誤 窗體底端窗體頂端4：1錯誤處理類模塊是典型的時間內(nèi)聚模塊。正確 錯誤窗體底端窗體頂端6：9在面向?qū)ο蠓椒ㄖ?，軟件系統(tǒng)的結(jié)構(gòu)是根據(jù)問題領(lǐng)域的模型建立起來的，因此系統(tǒng)功能需求變化時并不會引起軟件結(jié)構(gòu)的整體變化，僅需要作一些局部性的修改即可。正確 錯誤窗體底端窗體頂端8：3判定表、判定樹和IPO圖都是常用來編寫數(shù)據(jù)字典加工邏輯說明的工具。正確 錯誤 9：1管道／過濾器風格支持并行執(zhí)行。正確 錯誤窗體底端窗體頂端11：1控制耦合實質(zhì)是在單一接口上選擇多功能模塊中的某項功能。正確 錯誤 12：8需求定義文檔要從適合顧客的層次，而且要用顧客能夠理解的術(shù)語編寫。正確 錯誤 13：6軟件工程方法學包含三個要素：方法、工具和過程。方法是完成軟件開發(fā)的各項任務的技術(shù)；工具為軟件工程方法提供了自動或半自動的軟件支撐環(huán)境；過程為獲得高質(zhì)量軟件所需要完成的一系列任務的框架，它規(guī)定了完成各項任務的步驟。目前使用得最廣泛的軟件工程方法學是傳統(tǒng)方法學和面向?qū)ο蠓椒▽W。正確 錯誤 窗體底端窗體頂端17：抽象和求精是一對互補的概念，也是人類解決復雜問題時最常用、最有效的方法。正確 錯誤 18：7在一個設計得很好的系統(tǒng)中，所有受判定影響的模塊應該都從屬于做出判定的那個模塊，最好局限于做出判定的那個模塊本身及它的直屬下級模塊。正確 錯誤 19：6可行性研究應著重考慮技術(shù)可行性，經(jīng)濟可行性，操作可行性，法律可行性和開發(fā)方案的選擇性研究，可行性研究的成本一般為預期總成本的15％～20％。正確 錯誤 窗體底端窗體頂端23： 4事實上，層次圖和結(jié)構(gòu)圖不僅表明一個模塊調(diào)用哪些模塊，而且對模塊的其他成分也有明確的表示。正確 錯誤 窗體底端窗體頂端28：1軟件設計優(yōu)化應該力求做到在有效的模塊化的前提下使用最少量的模塊。正確 錯誤 窗體底端窗體頂端31：5測試分析報告應把每個模塊實際測試的結(jié)果，與軟件需求規(guī)格說明書和概要設計說明書中規(guī)定的要求進行對照并作出結(jié)論。正確 錯誤 32：8在傳統(tǒng)開發(fā)方法中，早期引入變動代價比較低，中期引入變動要付出的代價劇增，在軟件“已經(jīng)完成”時再引入變動，則需要付出更高的代價。正確 錯誤 窗體底端窗體頂端34：7軟件工程的Brooks定律指出：向已經(jīng)延期的軟件項目中添加人手只會使進度更加落后。我們不可能用“人力換時間”的辦法無限縮短一個軟件的開發(fā)時間，Boehm根據(jù)經(jīng)驗指出，軟件項目的開發(fā)時間最多可以減少到正常開發(fā)時間的75％。正確 錯誤 35：6面向?qū)ο笮枨筮^程的本質(zhì)是在問題空間與求解空間之間架設橋梁。正確 錯誤 窗體底端20
環(huán)評公示相關(guān)推薦
鄂ICP備17016276號-1