四川師范大學(xué)成都學(xué)院-軟件工程試題續(xù)(已改無(wú)錯(cuò)字)
2023-02-07 23:30:43 本頁(yè)面
【正文】 。 10 結(jié)構(gòu)化設(shè)計(jì)方法通常采用 ( 層次圖 )、 HIPO 圖和結(jié)構(gòu)圖描述軟件結(jié)構(gòu)。 11 可行性研究的任務(wù)不是具體解決系統(tǒng)中的問(wèn)題，而是確定問(wèn)題是否 (有解 )，是否（值得去解 ）。 12 可行性研究主要集中在 (技術(shù)可行性 ) 、經(jīng)濟(jì)可行性、操作可行性等方面?？傮w設(shè)計(jì) 詳細(xì)設(shè)計(jì) 編程實(shí)現(xiàn) 項(xiàng)目計(jì)劃 測(cè)試 原型迭代 產(chǎn)品發(fā)布和產(chǎn)品維護(hù)。 13 類(lèi)的靜態(tài)成員屬于類(lèi)所有，非名靜態(tài)成員屬于類(lèi)的實(shí)例所有。 算法描述和數(shù)據(jù)描述。 14 類(lèi)的實(shí)例化是 (對(duì)象 )。 15 類(lèi)是某些對(duì)象的模板，抽象地描述屬于該類(lèi)的全部對(duì)象的屬性和操作。 16 兩個(gè)模塊彼此間通過(guò)參數(shù)交換信息，而且交換的信息是簡(jiǎn)單的數(shù)據(jù)值，則這兩個(gè)模塊是 （數(shù)據(jù)）耦合。 17 流程圖也稱(chēng)為程序框圖是最常用的一種表示法 ,它有 ( 順序 )、 ( 選擇 ) （ 循環(huán) ）三個(gè)基本控制構(gòu)件 18 螺旋模型一種風(fēng)險(xiǎn)驅(qū)動(dòng)的模型，它將瀑布模型和 (增量型 )結(jié)合起來(lái)，并加入了（ 風(fēng)險(xiǎn)分析） 。 19 面向?qū)ο蟮拈_(kāi)發(fā)模型突破了傳統(tǒng)的瀑布模型，將開(kāi)發(fā)分為面向?qū)ο蠓治?、面向?qū)ο笤O(shè)計(jì)和 （面向?qū)ο髮?shí)現(xiàn)）三個(gè)階段。 自底向上兩種。 20 面向?qū)ο蟮脑O(shè)計(jì)將面向?qū)ο蠓治龇椒ń⒌男枨蠓治瞿Ｐ娃D(zhuǎn)化為構(gòu)造軟件的設(shè)計(jì)模型。 關(guān)系和圖組成。 21 面向?qū)ο蠓治瞿Ｐ屯ǔ０▽?duì)象模型、動(dòng)態(tài)模型和功能模型。 22 軟件的開(kāi)發(fā)計(jì)劃是一個(gè)綜合的計(jì)劃，是軟件開(kāi)發(fā)工作的指導(dǎo)性文檔，閱讀對(duì)象是軟件開(kāi)發(fā)的主管部門(mén)軟件技術(shù)人員和普通用戶(hù)。 23 軟件風(fēng)險(xiǎn)管理的主要目標(biāo)是預(yù)防風(fēng)險(xiǎn) ，最大限度地降低風(fēng)險(xiǎn)對(duì)軟件開(kāi)發(fā)的影響。 24 軟件工程包括過(guò)程、（方法）和工具三要素，三者共同以質(zhì)量管理為基礎(chǔ)。 25 軟件有效性 ,指軟件系統(tǒng)的 (時(shí)間 )和 (空間 )效率 26 數(shù)據(jù)流圖一般可分為 （變換） 型和事務(wù)型兩類(lèi)。 27 算法復(fù)雜度主要包括時(shí)間復(fù)雜度和空間復(fù)雜度。 28 詳細(xì)設(shè)計(jì)需要對(duì)系統(tǒng)的模塊做概要性的說(shuō)明，主要包括模塊描述算法描述和數(shù)據(jù)描述。 29 需求分析可分為問(wèn)題識(shí)別、分析與綜合、制訂需求規(guī)格說(shuō)明書(shū)、需求評(píng)審四個(gè)階段。 30 用黑盒測(cè)試構(gòu)造測(cè)試用例的方法一般有以下幾種： （等價(jià)類(lèi)循環(huán)）、邊界值分析、比較測(cè)試、錯(cuò)誤測(cè)試、因果圖。 31 在類(lèi)的成員聲明時(shí)，若使用了 protected 修飾符則該成員只能在該類(lèi)或其派生類(lèi)中使用。 32 在整個(gè)維護(hù)階段所花費(fèi)工作量中，完善性維護(hù)花費(fèi)的工作量最多，而預(yù)防性維護(hù)花費(fèi)的工作量最少。 33 在自頂向下的測(cè)試中，模塊的組裝分為深度優(yōu)先和寬度優(yōu)先兩種方式。 34 總體設(shè)計(jì)的主要任務(wù)是根據(jù)用戶(hù)需求分析階段得到的目標(biāo)系統(tǒng)的物理模型確定一個(gè)合理的軟件系統(tǒng)體系結(jié)構(gòu)。 三 判斷題 1 UML 只能應(yīng)用于軟件系統(tǒng)模型的建立。 (X) 2 α測(cè)試是一個(gè)在用戶(hù)場(chǎng)所，沒(méi) 有開(kāi)發(fā)者在場(chǎng)的測(cè)試。 (X) 3 好的測(cè)試是用少量的測(cè)試用例運(yùn)行程序，發(fā)現(xiàn)被測(cè)程序盡可能多的錯(cuò)誤。 (√ ) 4 結(jié)構(gòu)化分析中描述加工邏輯的判定樹(shù)、判定表也能用于詳細(xì)設(shè)計(jì)階段描述算法。 (√ ) 5 可行性研究工作要在初步的需求定義之前進(jìn)行 (X) 6 類(lèi)是對(duì)具有共同特征的對(duì)象的進(jìn)一步抽象 (√ ) 7 流程圖也稱(chēng)為程序框圖是最常用的一種表示法 (√ ) 8 面對(duì)日益增長(zhǎng)的軟件需求，人們顯得力不從心，往往是產(chǎn)生軟件危機(jī)的原因之一。 (√ ) 9 面向?qū)ο笤O(shè)計(jì)是將面向?qū)ο蠓治鰟?chuàng)建的分析模型進(jìn)一步細(xì)化形成軟件設(shè)計(jì)模型的過(guò)程 (√ ) 10 模塊獨(dú)立性中耦合度最高的是內(nèi)容耦合，內(nèi)聚度最高的是功能內(nèi)聚。 (√ ) 11 判定覆蓋不一定包含條件覆蓋，條件覆蓋一定包含判定覆蓋。 (X) 12 缺乏有力的方法學(xué)的指導(dǎo)和有效的開(kāi)發(fā)工具的支持 , 這是產(chǎn)生軟件危機(jī)的原因之一 (√ ) 13 如果測(cè)試過(guò)程沒(méi)有發(fā)現(xiàn)任何錯(cuò)誤 ,則說(shuō)明軟件沒(méi)有錯(cuò)誤 (X) 14 軟件過(guò)程設(shè)計(jì)不用遵循 自上而下 ,逐步求精 的原則和單入口單出口的結(jié)構(gòu)化設(shè)計(jì)思想 (X) 15 軟件開(kāi)發(fā) ,設(shè)計(jì)幾乎都是從頭開(kāi)始 ,成本和進(jìn)度很難估計(jì) (√ ) 16 軟件開(kāi)發(fā)人員對(duì)用戶(hù)需求的理解有偏差 ,這將導(dǎo)致軟件產(chǎn)品與用 戶(hù)的需求不一致 ,是產(chǎn)生軟件危機(jī)的唯一原因 (X) 17 軟件也會(huì)磨損和老化 (X) 18 軟件總體設(shè)計(jì)階段只需要進(jìn)行軟件的結(jié)構(gòu)設(shè)計(jì)，得出軟件的軟件結(jié)構(gòu)。 (X) 19 事務(wù)型數(shù)據(jù)流圖中至少有一條接受路徑，一個(gè)事物中心。 (√ ) 20 通常緊致
試題試卷相關(guān)推薦
鄂ICP備17016276號(hào)-1