




版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)
文檔簡(jiǎn)介
1、精選優(yōu)質(zhì)文檔-傾情為你奉上判斷第一章概述1. 由于今天個(gè)人計(jì)算機(jī)不斷發(fā)展壯大,人們不再采用軟件團(tuán)隊(duì)的開(kāi)發(fā)方式。() 2. 由于軟件是產(chǎn)品,因此可以應(yīng)用其他工程制品所用的技術(shù)進(jìn)行生產(chǎn)。() 3. 購(gòu)買大多數(shù)計(jì)算機(jī)系統(tǒng)所需的硬件比軟件更昂貴。() 4. 大多數(shù)軟件產(chǎn)品在其生命周期中不需要增強(qiáng)功能。() 5. 大多數(shù)軟件系統(tǒng)是不容易變化的,除非它們?cè)谠O(shè)計(jì)時(shí)考慮了變化。() 6. 一般來(lái)說(shuō),軟件只有在其行為與設(shè)計(jì)者的目標(biāo)一致的情況下才能成功。()第二章軟件過(guò)程3.軟件需求規(guī)格說(shuō)明書在軟件開(kāi)發(fā)過(guò)程中具有重要的作用,它是軟件可行性分析的依據(jù)。() 軟件項(xiàng)目管理2.項(xiàng)目管理在現(xiàn)代軟件開(kāi)發(fā)中是不太重要的,因?yàn)?/p>
2、大多數(shù)項(xiàng)目能夠及時(shí)完成并成功交付。()13.隨著項(xiàng)目計(jì)劃的不斷形成,產(chǎn)品分解和過(guò)程分解經(jīng)常是同時(shí)發(fā)生的。() 15.估算不可靠的唯一原因是估算人員缺乏經(jīng)驗(yàn)。() 16.由于軟件項(xiàng)目估算不完全可靠,所以項(xiàng)目開(kāi)始后可以忽略這些估算。() 19.估計(jì)待開(kāi)發(fā)軟件產(chǎn)品的規(guī)模必須基于像代碼行等直接度量單位。()24.功能點(diǎn)不能用于估算面向?qū)ο蟮能浖?。(?5.軟件項(xiàng)目延遲是不可避免的,而且無(wú)法解釋其原因。() 26.將開(kāi)發(fā)團(tuán)隊(duì)人數(shù)增加一倍可以保證項(xiàng)目完成時(shí)間減少一半。() 28.主動(dòng)的風(fēng)險(xiǎn)管理有時(shí)被描述為救火。() 34.軟件工作產(chǎn)品一旦成為基線就不能再更改了。() 35.如果開(kāi)發(fā)小組使用自動(dòng)化的項(xiàng)目數(shù)據(jù)
3、庫(kù)工具,那么就不需要變更控制。() 需求工程1. 在需求分析過(guò)程中,分析員要從用戶那里解決的最重要的問(wèn)題是明確軟件做 什么。()2. 軟件需求規(guī)格說(shuō)明書在軟件開(kāi)發(fā)中具有重要的作用,它是軟件可行性分析的 依據(jù)。() 6. 目前存在一個(gè)很普遍的現(xiàn)象,即不同的客戶提出的需求是相互矛盾的,但每個(gè)人都爭(zhēng)辯自己是正確的。() 7. 利益相關(guān)者(stakeholders)是將來(lái)購(gòu)買所開(kāi)發(fā)軟件系統(tǒng)的人。() 11.需求工程師的任務(wù)是將所有利益相關(guān)者的信息進(jìn)行分類以便允許決策者選擇一 個(gè)相互一致的需求集。() 13.開(kāi)發(fā)人員與客戶創(chuàng)建用例以幫助軟件團(tuán)隊(duì)理解有多少類型的最終用戶將使用這 些功能。()16.用例參與
4、者總是人員而不是系統(tǒng)設(shè)備。() 17.在需求確認(rèn)過(guò)程中需求模型被評(píng)審以保證其技術(shù)可行性。() 面向?qū)ο蠡A(chǔ)1. 模型是對(duì)現(xiàn)實(shí)的簡(jiǎn)化,建模是為了更好地理解所開(kāi)發(fā)的系統(tǒng)。() 2. UML 語(yǔ)言支持面向?qū)ο蟮闹饕拍?,并與具體的開(kāi)發(fā)過(guò)程相關(guān)。() 面向?qū)ο蠓治?. 面向?qū)ο蠓治龅暮诵脑谟诮⒁粋€(gè)描述軟件系統(tǒng)的模型。() 5. 分析類用于描述系統(tǒng)中概念層次的對(duì)象。() 7. 在基于用例的面向?qū)ο蠓治鲞^(guò)程中,定義交互行為的關(guān)鍵在于通過(guò)描述分析 類實(shí)例之間 的消息傳遞將用例的職責(zé)分配到分析類中。() 10. 需求評(píng)審人員主要由開(kāi)發(fā)人員組成,一般不包括用戶。() 面向?qū)ο笤O(shè)計(jì)1. 面向?qū)ο笤O(shè)計(jì)是在分析模型
5、的基礎(chǔ)上,運(yùn)用面向?qū)ο蠹夹g(shù)生成軟件實(shí)現(xiàn)環(huán)境 下的設(shè)計(jì)模型。() 2. 系統(tǒng)設(shè)計(jì)的主要任務(wù)是細(xì)化分析模型,最終形成系統(tǒng)的設(shè)計(jì)模型。() 3. 關(guān)系數(shù)據(jù)庫(kù)可以完全支持面向?qū)ο蟮母拍?,面向?qū)ο笤O(shè)計(jì)中的類可以直接對(duì) 應(yīng)到關(guān)系數(shù)據(jù)庫(kù)中的表。() 4. 用戶界面設(shè)計(jì)對(duì)于一個(gè)系統(tǒng)的成功是至關(guān)重要的,一個(gè)設(shè)計(jì)得很差的用戶界 面可能導(dǎo)致用戶拒絕使用該系統(tǒng)。()軟件實(shí)現(xiàn)1. 在程序設(shè)計(jì)中使用括號(hào)以改善表達(dá)式的清晰性。() 2. 在程序設(shè)計(jì)中應(yīng)盡可能對(duì)程序代碼進(jìn)行優(yōu)化。() 3. 不要修補(bǔ)不好的程序,要重新寫。() 4. 程序中的注釋是可有可無(wú)的。() 5. 對(duì)遞歸定義的數(shù)據(jù)結(jié)構(gòu)不要使用遞歸過(guò)程。() 軟件測(cè)試1.
6、 在軟件開(kāi)發(fā)的過(guò)程中,若能推遲暴露其中的錯(cuò)誤,則為修復(fù)和改正錯(cuò)誤所花 費(fèi)的代價(jià)就會(huì)降低。() 2. 好的測(cè)試是用少量測(cè)試用例運(yùn)行程序,發(fā)現(xiàn)被測(cè)程序盡可能多的錯(cuò)誤。() 3. 好的測(cè)試用例應(yīng)能證明軟件是正確的。() 4. 白盒測(cè)試僅與程序的內(nèi)部結(jié)構(gòu)有關(guān),完全可以不考慮程序的功能要求。() 5. 等價(jià)類劃分方法將所有可能的輸入數(shù)據(jù)劃分成若干部分,然后從每一部分中 選取少數(shù)有代表性的數(shù)據(jù)作為測(cè)試用例。()軟件演化1. 只有質(zhì)量差的軟件產(chǎn)品才需要維護(hù)。()2. 遺留系統(tǒng)是許多年以前開(kāi)發(fā)的且已經(jīng)沒(méi)有商業(yè)價(jià)值的計(jì)算機(jī)系統(tǒng)。() 3. 更換遺留系統(tǒng)是有業(yè)務(wù)風(fēng)險(xiǎn)的。() 4. 軟件的維護(hù)成本通常比開(kāi)發(fā)成本低。
7、() 選擇第一章概述1. ( )因素促使計(jì)算機(jī)系統(tǒng)越來(lái)越復(fù)雜。(D) A. 計(jì)算機(jī)內(nèi)存和存儲(chǔ)容量上的巨大增長(zhǎng) B. 外部輸入輸出選項(xiàng)的更加多樣性 C. 計(jì)算機(jī)體系結(jié)構(gòu)方面的深刻變化 D. 以上所有選項(xiàng) 2. 下面的( )不再是現(xiàn)代軟件工程師關(guān)注的問(wèn)題。(A) A. 為什么計(jì)算機(jī)硬件的成本這么高? B. 為什么軟件需要很長(zhǎng)時(shí)間才能完成? C. 為什么開(kāi)發(fā)一個(gè)軟件的成本這么高? D. 為什么不能在產(chǎn)品發(fā)布前去除軟件錯(cuò)誤? 3. 軟件會(huì)逐漸退化而不會(huì)磨損,其原因在于( )。(C) A. 軟件通常暴露在惡劣的環(huán)境下 B. 軟件錯(cuò)誤通常發(fā)生在使用之后 C. 不斷的變更使組件接口之間引起錯(cuò)誤 D. 軟件備
8、件很難訂購(gòu) 4. 大多數(shù)軟件仍然是定制開(kāi)發(fā)的,其原因在于( )。(C) A. 軟件組件重用是十分普遍的 B. 可重用的組件太昂貴而無(wú)法使用 C. 軟件在不使用其他組件的情況下很容易構(gòu)造出來(lái) D. 商業(yè)組件在很多應(yīng)用領(lǐng)域中可以得到 5. 下面的( )說(shuō)法是正確的。(C) A. 軟件危機(jī)在 20 世紀(jì) 70 年代末期全面爆發(fā) B. 當(dāng)前先進(jìn)的軟件工程方法已經(jīng)解決了軟件危機(jī)的問(wèn)題 C. 軟件危機(jī)是指在計(jì)算機(jī)軟件的開(kāi)發(fā)和維護(hù)過(guò)程中遇到的一系列嚴(yán)重問(wèn)題 D. 軟件危機(jī)是指在軟件產(chǎn)品中存在一系列的質(zhì)量問(wèn)題 6. 軟件工程的基本目標(biāo)是( )。(B) A. 消除軟件固有的復(fù)雜性 B. 開(kāi)發(fā)高質(zhì)量的軟件 C.
9、努力發(fā)揮開(kāi)發(fā)人員的創(chuàng)造性潛能 D. 更好地維護(hù)正在使用的軟件產(chǎn)品 7. ( )是將系統(tǒng)化的、規(guī)范的、可定量的方法應(yīng)用于軟件的開(kāi)發(fā)、運(yùn)行和維護(hù)的過(guò) 程,它包括方法、工具和過(guò)程三個(gè)要素。(D) A. 軟件產(chǎn)品 B. 軟件過(guò)程 C. 軟件測(cè)試 D. 軟件工程 8. 軟件工程的基本要素包括方法、工具和( )。(C) A. 軟件系統(tǒng) B. 硬件環(huán)境 C. 過(guò)程 D. 人員 9. 軟件工程師在從事軟件工作時(shí)應(yīng)使用下面的( )準(zhǔn)則。(E) A. 從來(lái)不為個(gè)人獲利而竊取數(shù)據(jù) B. 從來(lái)不散布或出售項(xiàng)目中自己工作的信息 C. 從來(lái)不故意毀壞或修改別人的程序、文件或數(shù)據(jù) D. 從來(lái)不侵犯?jìng)€(gè)人、小組或組織的隱私 E
10、. 以上所有選項(xiàng)第二章軟件過(guò)程1. ( )是軟件生存期中的一系列相關(guān)軟件工程活動(dòng)的集合,它由軟件規(guī)格說(shuō)明、軟件 設(shè)計(jì)與開(kāi)發(fā)、軟件確認(rèn)、軟件改進(jìn)等活動(dòng)組成。(A) A. 軟件過(guò)程 B. 軟件工具 C. 軟件產(chǎn)品 D. 軟件工程 2. 軟件過(guò)程的基本活動(dòng)是( )。(A) A. 分析、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試、演化 B. 溝通、計(jì)劃、建模、構(gòu)造、部署 C. 計(jì)劃、分析、設(shè)計(jì)、實(shí)現(xiàn)、調(diào)試 D. 溝通、風(fēng)險(xiǎn)管理、度量、產(chǎn)品化、評(píng)審 4. 軟件開(kāi)發(fā)的瀑布模型是( )。(A) A. 適用于需求被清晰定義的情況 B. 一種需要快速構(gòu)造可運(yùn)行程序的好方法 C. 最適合于大規(guī)模團(tuán)隊(duì)開(kāi)發(fā)的項(xiàng)目 D. 已不能用于現(xiàn)代環(huán)境的過(guò)
11、時(shí)模型 5. 軟件開(kāi)發(fā)的增量模型是( )。(B)A. 適用于需求被清晰定義的情況 B. 一種需要快速構(gòu)造核心產(chǎn)品的好方法 C. 最適合于大規(guī)模團(tuán)隊(duì)開(kāi)發(fā)的項(xiàng)目 D. 一種不適用于商業(yè)產(chǎn)品的創(chuàng)新模型 6. 快速原型開(kāi)發(fā)模型是( )。(B) A. 適用于客戶需求被明確定義的情況 B. 適用于客戶需求難以清楚定義的情況 C. 最適合于大規(guī)模團(tuán)隊(duì)開(kāi)發(fā)的項(xiàng)目 D. 很難產(chǎn)生有意義產(chǎn)品的一種冒險(xiǎn)模型 7. 演進(jìn)式軟件過(guò)程模型( )。(D) A. 本質(zhì)上是迭代的 B. 可以很容易適應(yīng)需求的變化 C. 通常不會(huì)拋棄所產(chǎn)生的系統(tǒng) D. 以上所有選項(xiàng) 8. 螺旋模型( )。(C) A. 在軟件產(chǎn)品發(fā)布時(shí)結(jié)束 B.
12、比增量模型更加混亂 C. 在每一次迭代過(guò)程中包含項(xiàng)目風(fēng)險(xiǎn)評(píng)價(jià) D. 以上所有選項(xiàng) 9. 基于組件的開(kāi)發(fā)模型( )。(C) A. 只適用于計(jì)算機(jī)硬件設(shè)計(jì) B. 不能支持可重用組件的開(kāi)發(fā) C. 在面向?qū)ο蠹夹g(shù)獲得支持的情況下應(yīng)用得更好 D. 增加了開(kāi)發(fā)風(fēng)險(xiǎn)和成本 10. 形式化方法模型是將數(shù)學(xué)方法用于( )。(D) A. 定義計(jì)算機(jī)系統(tǒng)的規(guī)格說(shuō)明 B. 開(kāi)發(fā)無(wú)錯(cuò)誤的計(jì)算機(jī)系統(tǒng) C. 驗(yàn)證計(jì)算機(jī)系統(tǒng)的正確性 D. 以上所有選項(xiàng) 11. 下面的( )不是 RUP 模型的階段。(D) A. 啟動(dòng)階段 B. 精化階段 C. 構(gòu)造階段 D. 確認(rèn)階段軟件項(xiàng)目管理1. 軟件項(xiàng)目管理的“4P”是( )。(C)
13、A. people,performance,payoff,product B. people,product,performance,process C. people,product,process,project D. people,process,payoff,product 3. 在軟件開(kāi)發(fā)的各種資源中,( )是最重要的資源。(C) A. 開(kāi)發(fā)工具 B. 方法 C. 硬件環(huán)境 D. 人員 4. 軟件項(xiàng)目規(guī)劃的第一步是( )。(D) A. 確定項(xiàng)目預(yù)算 B. 選擇團(tuán)隊(duì)的組織模型 C. 確定項(xiàng)目的約束 D. 建立項(xiàng)目的目標(biāo)和范圍 5. 下面的( )方法最不適合你向團(tuán)隊(duì)成員解釋他或她為什么表
14、現(xiàn)不合格。(B) A. 個(gè)人談話 B. 項(xiàng)目團(tuán)隊(duì)會(huì)議 C. 正式報(bào)告 D. 電子郵件 6. 功能點(diǎn)估算技術(shù)需要以( )為基礎(chǔ)進(jìn)行問(wèn)題分解。(A) A. 信息域 B. 項(xiàng)目進(jìn)度 C. 軟件功能 D. 過(guò)程活動(dòng) 7. 軟件開(kāi)發(fā)團(tuán)隊(duì)的每一個(gè)成員都應(yīng)該參與計(jì)劃活動(dòng),以便( )。(C) A. 降低計(jì)劃的粒度 B. 深入地分析需求 C. 所有成員同意該計(jì)劃 D. 開(kāi)始設(shè)計(jì) 8. 在攻克技術(shù)難題時(shí),最佳的開(kāi)發(fā)團(tuán)隊(duì)組織模型是( )。(A) A. 民主式結(jié)構(gòu) B. 主程序員式結(jié)構(gòu) C. 技術(shù)管理混合式結(jié)構(gòu) D. 以上所有選項(xiàng)都不是 9. 在選擇開(kāi)發(fā)團(tuán)隊(duì)組織結(jié)構(gòu)時(shí)應(yīng)考慮( )因素。(E) A. 溝通的復(fù)雜程度 B
15、. 最終程序的規(guī)模大小 C. 發(fā)布日期的嚴(yán)格程度 D. 項(xiàng)目預(yù)算的多少 E. 選項(xiàng) A,B 和 C 10. 在軟件開(kāi)發(fā)過(guò)程中避免受挫的最佳方法之一是( )。(A) A. 給予團(tuán)隊(duì)成員對(duì)于過(guò)程和技術(shù)決策的更多控制權(quán) B. 給予團(tuán)隊(duì)成員對(duì)于過(guò)程和技術(shù)決策的更少控制權(quán) C. 向團(tuán)隊(duì)成員隱瞞壞消息直到事情有所改善 D. 根據(jù)生產(chǎn)效率獎(jiǎng)勵(lì)團(tuán)隊(duì)成員 11. 下面的( )軟件特性不是引起項(xiàng)目協(xié)調(diào)困難的一個(gè)因素。(B) A. 互操作性 B. 性能 C. 規(guī)模 D. 不確定性 12. 在進(jìn)行項(xiàng)目范圍活動(dòng)時(shí),問(wèn)題分解的主要范圍是( )。(E) A. 客戶工作流程 B. 需要發(fā)布的功能 C. 用于發(fā)布功能的過(guò)程 D
16、. 軟件過(guò)程模型 E. 選項(xiàng) B 和 C 14. 為了將項(xiàng)目失敗的風(fēng)險(xiǎn)減少到最小,項(xiàng)目經(jīng)理需要采?。?)。(D) A. 將項(xiàng)目團(tuán)隊(duì)規(guī)模增加一倍 B. 要求更大的預(yù)算 C. 順利地開(kāi)始 D. 跟蹤過(guò)程 E. 選項(xiàng) B 和 C 17. 軟件項(xiàng)目規(guī)劃的目的是( )。(C) A. 使客戶相信項(xiàng)目是可行的 B. 使用歷史項(xiàng)目數(shù)據(jù) C. 使項(xiàng)目管理者合理地估算成本和進(jìn)度 D. 在投標(biāo)項(xiàng)目之前確定大概的利潤(rùn)邊界 18. 軟件項(xiàng)目所需的人數(shù)應(yīng)該( )。(D) A. 在估計(jì)開(kāi)發(fā)需要的努力之后決定 B. 由項(xiàng)目預(yù)算數(shù)量決定 C. 從評(píng)價(jià)系統(tǒng)復(fù)雜性來(lái)決定 D. 以上所有選項(xiàng) 19. ( )估計(jì)待開(kāi)發(fā)軟件產(chǎn)品的規(guī)模必
17、須基于像代碼行等直接度量單位。(B) A. 真 B. 假 20. 代碼行估算技術(shù)需要以( )為基礎(chǔ)進(jìn)行問(wèn)題分解。(C) A. 信息域值 B. 項(xiàng)目進(jìn)度 C. 軟件功能 D. 軟件過(guò)程活動(dòng) 21. 功能點(diǎn)估算技術(shù)需要以( )為基礎(chǔ)進(jìn)行問(wèn)題分解。(A) A. 信息域值 B. 項(xiàng)目進(jìn)度 C. 軟件功能 D. 軟件過(guò)程活動(dòng) 22. 經(jīng)驗(yàn)估算模型是基于( )。(C) A. 專家基于過(guò)去項(xiàng)目經(jīng)驗(yàn)的判斷 B. 期望值估計(jì)的細(xì)化 C. 來(lái)自歷史項(xiàng)目數(shù)據(jù)的回歸模型 D. 反復(fù)試驗(yàn)決定參數(shù)和系數(shù) 23. COCOMO II 是現(xiàn)代經(jīng)驗(yàn)估算模型的一個(gè)實(shí)例,它需要以( )為單位的程序規(guī)模信息。(B) A. 功能點(diǎn) B
18、. 代碼行 C. 工作量 D. 以上任何選項(xiàng) 27. 任務(wù)集是( )的集合。(A) A. 工作任務(wù)、里程碑、工作產(chǎn)品 B. 任務(wù)分配、成本估算、度量單位 C. 里程碑、可交付物、度量單位 D. 責(zé)任、里程碑、文檔 29. 軟件風(fēng)險(xiǎn)總是包括( )兩個(gè)特性。(C) A. 救火和危機(jī)管理 B. 已知的和未知的風(fēng)險(xiǎn) C. 不確定和損失 D. 安置人員和預(yù)算 30. 風(fēng)險(xiǎn)的三種主要類型是( )。(B) A. 商業(yè)風(fēng)險(xiǎn)、人員風(fēng)險(xiǎn)、預(yù)算風(fēng)險(xiǎn) B. 項(xiàng)目風(fēng)險(xiǎn)、技術(shù)風(fēng)險(xiǎn)、商業(yè)風(fēng)險(xiǎn) C. 計(jì)劃風(fēng)險(xiǎn)、技術(shù)風(fēng)險(xiǎn)、人員風(fēng)險(xiǎn) D. 管理風(fēng)險(xiǎn)、技術(shù)風(fēng)險(xiǎn)、設(shè)計(jì)風(fēng)險(xiǎn) 31. 下面的( )是有效的軟件配置項(xiàng)。(E)A. 軟件工具
19、 B. 文檔 C. 可執(zhí)行程序 D. 測(cè)試數(shù)據(jù) E. 以上所有選項(xiàng) 32. 下面的( )配置對(duì)象通常不包括在項(xiàng)目數(shù)據(jù)庫(kù)中。(C) A. 設(shè)計(jì)規(guī)格說(shuō)明書 B. 可執(zhí)行程序 C. 組織結(jié)構(gòu)描述 D. 測(cè)試計(jì)劃 33. 基線(Baseline)是指在項(xiàng)目生命周期的不同時(shí)間點(diǎn)上,一個(gè)或一組配置項(xiàng)通過(guò)( ) 而進(jìn)入正式受控的一種狀態(tài)。(C) A. 存取控制 B. 質(zhì)量控制 C. 正式評(píng)審 D. 變更管理 36. 下面的( )不是軟件配置管理的任務(wù)。(C) A. 變更控制 B. 配置狀態(tài)報(bào)告 C. 統(tǒng)計(jì)質(zhì)量控制 D. 版本控制 37. 配置狀態(tài)報(bào)告的主要目的是( )。(C) A. 允許項(xiàng)目經(jīng)理修改項(xiàng)目進(jìn)度
20、和成本估算 B. 評(píng)估軟件開(kāi)發(fā)人員和組織的績(jī)效 C. 確保變更信息傳達(dá)到受影響的團(tuán)體 D. 選項(xiàng) A 和 C E. 選項(xiàng) A、B 和 C需求工程3. 在項(xiàng)目初始階段,開(kāi)發(fā)任務(wù)的目標(biāo)是( )。(A) A. 理解基本問(wèn)題 B. 確定所需的解決方案 C. 確定需要解決方案的人員 D. 以上選項(xiàng)都不是 E. 選項(xiàng) A、B 和 C 4. 下面的( )將造成需求獲取困難的問(wèn)題。(E) A. 預(yù)算(budgeting) B. 范圍(scope) C. 理解(understanding) D. 揮發(fā)性(volatility) E. 選項(xiàng) B、C 和 D 5. 需求分析的結(jié)果是產(chǎn)生定義下面( )問(wèn)題域的分析模型
21、。(D) A. 信息 B. 功能 C. 性能 D. 以上所有選項(xiàng)8. 需求規(guī)格說(shuō)明描述了( )。(A) A. 計(jì)算機(jī)系統(tǒng)的功能、性能及其約束 B. 每個(gè)指定系統(tǒng)的實(shí)現(xiàn) C. 軟件體系結(jié)構(gòu)的元素 D. 系統(tǒng)仿真所需要的時(shí)間 9. 組織需求評(píng)審的最好方法是( )。(D) A. 檢查系統(tǒng)模型的錯(cuò)誤 B. 讓客戶檢查需求 C. 將需求發(fā)放給設(shè)計(jì)團(tuán)隊(duì)去征求意見(jiàn) D. 使用問(wèn)題列表檢查每一個(gè)需求 10. 使用跟蹤表有助于( )。(C) A. 在后續(xù)的檢查運(yùn)行錯(cuò)誤時(shí)調(diào)試程序 B. 確定算法執(zhí)行的性能 C. 識(shí)別、控制和跟蹤需求的變化 D. 以上選項(xiàng)都不是12. 下面的( )不是在項(xiàng)目啟動(dòng)階段被提出的“與環(huán)境
22、無(wú)關(guān)”的問(wèn)題。(B) A. 成功的解決方案將帶來(lái)什么樣的經(jīng)濟(jì)收益? B. 誰(shuí)反對(duì)該項(xiàng)目? C. 誰(shuí)將為該項(xiàng)目付款? D. 誰(shuí)將使用該解決方案?14. 在各種不同的軟件需求中,( )描述了用戶使用產(chǎn)品必須要完成的任務(wù),可以在用 例模型或方案腳本中予以說(shuō)明,( )是從各個(gè)角度對(duì)系統(tǒng)的約束和限制,反映了應(yīng) 用對(duì)軟件系統(tǒng)質(zhì)量和特性的額外要求。(B,C) A. 業(yè)務(wù)需求 B. 功能需求 C. 非功能需求 D. 用戶需求 15. 需求導(dǎo)出后產(chǎn)生的工作制品將依賴于( )而不同。(B) A. 預(yù)算多少 B. 將要構(gòu)建的產(chǎn)品規(guī)模 C. 正在使用的軟件過(guò)程 D. 利益相關(guān)者的需要18. 在需求開(kāi)發(fā)過(guò)程中,軟件工程
23、師應(yīng)與客戶合作共同定義( )。(E) A. 客戶可見(jiàn)的使用場(chǎng)景 B. 重要的軟件特性 C. 系統(tǒng)的輸入與輸出 D. 選項(xiàng) A 和 B E. 選項(xiàng) A、B 和 C面向?qū)ο蠡A(chǔ)3. 類的結(jié)構(gòu)是( )。(E) A. 由代碼來(lái)表示 B. 由屬性和關(guān)系來(lái)表示 C. 由操作來(lái)表示 D. 由對(duì)象的交互來(lái)表示 E. 選項(xiàng) B 和 C 4. 類的行為是( )。(A) A. 由一組操作決定 B. 由類的屬性決定 C. 對(duì)類的每一個(gè)對(duì)象唯一的 D. 由父類決定 E. 選項(xiàng) A 和 B 5. ( )是把對(duì)象的屬性和操作結(jié)合在一起,構(gòu)成一個(gè)獨(dú)立的對(duì)象,其內(nèi)部信息對(duì)外 界是隱蔽的,外界只能通過(guò)有限的接口與對(duì)象發(fā)生聯(lián)系。(
24、C) A. 多態(tài)性 B. 繼承 C. 封裝 D. 消息6. ( )意味著一個(gè)操作在不同的類中可以有不同的實(shí)現(xiàn)方式。(A) A. 多態(tài)性 B. 多繼承 C. 消息 D. 封裝 7. UML 是( )的縮寫。(B) A. Unified Module Language B. Unified Modeling Language C. Universal Module Leveling D. Universal Module Language 8. 順序圖反映對(duì)象之間發(fā)送消息的時(shí)間順序,它與( )是同構(gòu)的。(C) A. 用例圖 B. 類圖 C. 協(xié)作圖 D. 狀態(tài)圖 9. ( )定義了系統(tǒng)的功能需求,
25、它是從系統(tǒng)的外部看系統(tǒng)功能,并不描述系統(tǒng)內(nèi)部 對(duì)功能的具體實(shí)現(xiàn)。(A) A. 用例圖 B. 類圖 C. 活動(dòng)圖 D. 狀態(tài)圖 10. 狀態(tài)圖包括( )。(E) A. 類的狀態(tài) B. 狀態(tài)之間的轉(zhuǎn)換 C. 類執(zhí)行的動(dòng)作 D. 觸發(fā)類的動(dòng)作的事件 E. 所有選項(xiàng)面向?qū)ο蠓治?. 關(guān)于面向?qū)ο蠓治?,下列的?)是正確的。(A) A. 它是系統(tǒng)需求建模的方法 B. 它是分析系統(tǒng)設(shè)計(jì)的技術(shù) C. 可以從分析直接編寫代碼 D. 在軟件生命周期中,它出現(xiàn)在面向?qū)ο笤O(shè)計(jì)之后 3. 下列的( )不是分析建模的目的。(C) A. 定義可驗(yàn)證的軟件需求 B. 描述客戶需求 C. 開(kāi)發(fā)一個(gè)簡(jiǎn)單的問(wèn)題解決方案 D. 建
26、立軟件設(shè)計(jì)的基礎(chǔ) 4. 下列的( )不屬于面向?qū)ο蠓治瞿P?。(C) A. 用例圖 B. 類圖 C. 實(shí)體關(guān)系圖 D. 順序圖6. 在分析類中,( )用于描述一個(gè)用例所具有的事件流控制行為。(D) A. 實(shí)體類 B. 界面類 C. 接口類 D. 控制類8. 開(kāi)發(fā)人員使用( )可以將用例的行為分配到所識(shí)別的分析類中。(B) A. 用例圖 B. 順序圖 C. 類圖 D. 狀態(tài)圖 9. 分析模型一般采用( )方式進(jìn)行驗(yàn)證。(C) A. 總結(jié) B. 階段性報(bào)告 C. 需求分析評(píng)審 D. 轉(zhuǎn)化成設(shè)計(jì)模型面向?qū)ο笤O(shè)計(jì)5. 內(nèi)聚表示一個(gè)模塊( )的程度,耦合表示一個(gè)模塊( )的程度。 (B,D) A. 可以被
27、更加細(xì)化 B. 僅關(guān)注在一件事情上 C. 能夠適時(shí)地完成其功能 D. 聯(lián)接其他模塊和外部世界 6. 良好設(shè)計(jì)的特征是( )。(E) A. 模塊之間呈現(xiàn)高耦合 B. 實(shí)現(xiàn)分析模型中的所有需求 C. 包括所有組件的測(cè)試用例 D. 提供軟件的完整描述 E. 選項(xiàng) B 和 D F. 選項(xiàng) B、C 和 D 7. ( )是選擇合適的解決方案策略,并將系統(tǒng)劃分成若干子系統(tǒng),從而建立整個(gè)系 統(tǒng)的體系結(jié)構(gòu);( )細(xì)化原有的分析對(duì)象,確定一些新的對(duì)象、對(duì)每一個(gè)子系統(tǒng)接 口和類進(jìn)行準(zhǔn)確詳細(xì)的說(shuō)明。(A,B) A. 系統(tǒng)設(shè)計(jì) B. 對(duì)象設(shè)計(jì) C. 數(shù)據(jù)庫(kù)設(shè)計(jì) D. 用戶界面設(shè)計(jì) 8. 下面的( )界面設(shè)計(jì)原則不允許用
28、戶保持對(duì)計(jì)算機(jī)交互的控制。(D) A. 允許交互中斷 B. 允許交互操作取消 C. 對(duì)臨時(shí)用戶隱藏技術(shù)內(nèi)部信息 D. 只提供一種規(guī)定的方法完成任務(wù)軟件實(shí)現(xiàn)6. 為了使程序能在不同的計(jì)算機(jī)上運(yùn)行,程序應(yīng)當(dāng)具有較好的( )。(A) A. 可移植性 B. 可重用性 C. 可維護(hù)性 D. 可適用性 7. 對(duì)于開(kāi)發(fā)面向數(shù)據(jù)庫(kù)應(yīng)用的軟件,應(yīng)當(dāng)選擇的程序設(shè)計(jì)語(yǔ)言是( )。(C) A. C B. PASCAL C. SQL D. JAVA 8. 下面對(duì)提高程序編碼效率沒(méi)有影響的是( )。(D) A. 選擇良好的設(shè)計(jì)方法 B. 選擇良好的算法 C. 選擇良好的數(shù)據(jù)結(jié)構(gòu) D. 變量名的使用 9. 為了保證軟件的質(zhì)
29、量,使其具有較好的可維護(hù)性,關(guān)鍵在于( )。(B) A. 選擇合適的程序設(shè)計(jì)語(yǔ)言 B. 選擇好的程序設(shè)計(jì)風(fēng)格 C. 具有好的數(shù)據(jù)結(jié)構(gòu) D. 選擇好的運(yùn)行環(huán)境 10. 下面的( )不是良好編碼的原則。(C) A. 在開(kāi)始編碼之前建立單元測(cè)試 B. 建立一種有助于理解的直觀布局 C. 保持變量名簡(jiǎn)短以便代碼緊湊 D. 確保注釋與代碼完全一致軟件測(cè)試6. 使用獨(dú)立測(cè)試團(tuán)隊(duì)的最好理由是( )。(C) A. 軟件開(kāi)發(fā)人員不需要做任何測(cè)試 B. 測(cè)試人員在測(cè)試開(kāi)始之前不參與項(xiàng)目 C. 測(cè)試團(tuán)隊(duì)將更徹底地測(cè)試軟件 D. 開(kāi)發(fā)人員與測(cè)試人員之間的爭(zhēng)論會(huì)減少 7. 類的行為應(yīng)該基于( )進(jìn)行測(cè)試。(D) A.
30、數(shù)據(jù)流圖 B. 用例圖 C. 對(duì)象圖 D. 狀態(tài)圖 8. 下面的( )說(shuō)法是正確的。(C,D,E) A. 恢復(fù)測(cè)試是以各種方式迫使軟件失效從而檢測(cè)軟件是否能夠繼續(xù)執(zhí)行的一種系統(tǒng) 測(cè)試。 B. 安全測(cè)試是檢測(cè)系統(tǒng)中的保護(hù)機(jī)制是否可以保護(hù)系統(tǒng)免受非正常的攻擊。 C. 壓力測(cè)試是檢測(cè)在極限環(huán)境中使用系統(tǒng)時(shí)施加在用戶上的壓力。 D. 功能測(cè)試是根據(jù)軟件需求規(guī)格說(shuō)明和測(cè)試需求列表,驗(yàn)證產(chǎn)品的功能實(shí)現(xiàn)是否符 合需求規(guī)格。 E. 安裝測(cè)試是保證應(yīng)用程序能夠被成功地安裝軟件演化5. 逆向工程(Reverse Engineering)通常用在軟件生命周期的( )階段,它是從源 代碼或目標(biāo)代碼中提取設(shè)計(jì)信息。(D
31、) A. 需求分析 B. 軟件設(shè)計(jì) C. 軟件測(cè)試 D. 軟件維護(hù)概念第一章概述1. 軟件與其他工程學(xué)科所產(chǎn)生的制品有什么根本區(qū)別? 答:(1) 軟件是人類思維和智能所延伸的產(chǎn)物,其數(shù)據(jù)、狀態(tài)和邏輯關(guān)系的組合以及人類思維的 復(fù)雜性和不確定性導(dǎo)致它本身具有極高的復(fù)雜性; (2) 軟件具有不可見(jiàn)性,它是抽象的,形式化和邏輯化的。 (3) 軟件具有可變性,有用的軟件需要不斷地修改和擴(kuò)展,但是頻繁的修改可能導(dǎo)致軟件的 退化; (4) 軟件的開(kāi)發(fā)在很大程度上依然是手工作坊式的,難以實(shí)現(xiàn)工廠化的生產(chǎn)。2. 軟件工程包括哪些基本要素?請(qǐng)簡(jiǎn)要說(shuō)明這些要素及其作用。 答:軟件工程包括過(guò)程、方法和工具三個(gè)要素。
32、1軟件工程過(guò)程定義了技術(shù)方法的采用、工程產(chǎn)品(包括模型、文檔、數(shù)據(jù)、報(bào)告、表格 等)的產(chǎn)生、里程碑的建立、質(zhì)量的保證和變更的管理,從而將人員、技術(shù)、組織與管 理有機(jī)地結(jié)合在一起,實(shí)現(xiàn)在規(guī)定的時(shí)間和預(yù)算內(nèi)開(kāi)發(fā)高質(zhì)量軟件的目標(biāo); 2軟件工程方法為軟件開(kāi)發(fā)提供了“如何做”的技術(shù),通常包括某種語(yǔ)言或圖形的模型表 示方法、良好的設(shè)計(jì)實(shí)踐以及質(zhì)量保證標(biāo)準(zhǔn)等; 3軟件工程工具為軟件工程方法提供了自動(dòng)的或半自動(dòng)的軟件支撐環(huán)境,輔助軟件開(kāi)發(fā)任 務(wù)的完成?,F(xiàn)有的軟件工具覆蓋了從需求分析、系統(tǒng)建模、代碼生成、程序調(diào)試和軟件 測(cè)試等多個(gè)方面,形成了集成化的軟件工程開(kāi)發(fā)環(huán)境 CASE3. 結(jié)合IEEE/ACM軟件工程職
33、業(yè)道德和職業(yè)行為準(zhǔn)則,試分別距離闡述每一項(xiàng)原則。答:(1) 公眾:軟件工程人員應(yīng)始終與公眾利益保持一致;(2) 客戶和雇主:在與公眾利益保持一致的原則下,軟件工程人員應(yīng)滿足客戶和雇主的最大利益;(3) 產(chǎn)品:軟件工程人員應(yīng)當(dāng)確保他們的產(chǎn)品及其改進(jìn)符合盡可能高的專業(yè)標(biāo)準(zhǔn);(4) 判斷:軟件工程人員應(yīng)當(dāng)具備公正和獨(dú)立的職業(yè)判斷力;(5) 管理:軟件工程管理者和領(lǐng)導(dǎo)者應(yīng)擁護(hù)和倡導(dǎo)合乎道德的有關(guān)軟件開(kāi)發(fā)和維護(hù)的管理方法;(6) 職業(yè):在與公眾利益一致的原則下,軟件工程人員應(yīng)當(dāng)提高職業(yè)的信譽(yù);(7) 同行:軟件工程人員對(duì)其同行應(yīng)保持平等和支持的態(tài)度;(8) 自我:軟件工程人員應(yīng)當(dāng)終身學(xué)習(xí)專業(yè)知識(shí),促進(jìn)合
34、乎道德的職業(yè)實(shí)踐方法。4. 軟件工程是以系統(tǒng)的、可控的、有效的方式產(chǎn)生高質(zhì)量的軟件,請(qǐng)說(shuō)明你對(duì)“高質(zhì)量軟件”含義的理解。 答:軟件質(zhì)量是軟件產(chǎn)品與明確的和隱含的需求相一致的程度,它通常由一系列的質(zhì)量特性來(lái)進(jìn)行描述,包括正確性、可靠性、有效性、可用性、復(fù)用性、可維護(hù)性、可移植性等。例如,除了要求軟件正確運(yùn)行之外,人們可能還希望軟件運(yùn)行的響應(yīng)時(shí)間符合要求、軟件使用方便快捷、程序代碼易于理解等,而“程序代碼易于理解”往往是一種用戶沒(méi)有明確提出的需求,但卻是影響軟件演化的重要因素。 5.有人認(rèn)為“軟件工程過(guò)于耗費(fèi)時(shí)間,并且妨礙開(kāi)發(fā)人員的編程效率?!蹦闶欠裾J(rèn)同這種觀點(diǎn)?請(qǐng)闡述理由。 答:這一觀點(diǎn)是不正確
35、的。 軟件開(kāi)發(fā)遠(yuǎn)不只是編程,管理不當(dāng)導(dǎo)致的混亂、工作重復(fù)、交流不暢等才是大多軟件項(xiàng)目效率低下的主要原因。雖然直接編程在開(kāi)發(fā)前期看來(lái)效率高,但是不完整的、不清晰的或錯(cuò)誤的需求和設(shè)計(jì)將導(dǎo)致在開(kāi)發(fā)后期反復(fù)地修改程序,反而降低了整個(gè)開(kāi)發(fā)效率,其質(zhì)量也無(wú)法保證,甚至導(dǎo)致軟件開(kāi)發(fā)最終失敗的結(jié)果。 軟件工程是幫助人們?cè)谟邢薜臅r(shí)間、金錢預(yù)算和人力、物力資源的約束下開(kāi)發(fā)出質(zhì)量盡量高的軟件的一系列理論和工具,雖然它在編程之外的工作上花費(fèi)了大量時(shí)間,但所耗費(fèi)的時(shí)間與精力并不像其表面上所看起來(lái)的那樣冗余與低效,而是從總體上做好整個(gè)體系的設(shè)計(jì)與把握,全方位地規(guī)劃開(kāi)發(fā)過(guò)程,對(duì)節(jié)省成本、提高效率、保證最終產(chǎn)品質(zhì)量起到了事半
36、功倍的作用。 第2章 軟件過(guò)程1. 請(qǐng)簡(jiǎn)要說(shuō)明軟件過(guò)程的概念和基本元素。 答: 軟件過(guò)程是軟件工程人員為了獲得軟件產(chǎn)品在軟件工具支持下實(shí)施的一系列軟件工程活動(dòng),它應(yīng)該明確定義以下元素: 過(guò)程中所執(zhí)行的活動(dòng)及其順序關(guān)系 每一個(gè)活動(dòng)的內(nèi)容和步驟 團(tuán)隊(duì)人員的工作和職責(zé) 2. 請(qǐng)描述快速原型過(guò)程模型的各個(gè)階段。 答: 快速原型方法的目的是解決軟件需求不明確給開(kāi)發(fā)帶來(lái)風(fēng)險(xiǎn)的問(wèn)題,其關(guān)鍵在于盡可能“快速”地建造原型,通過(guò)用戶對(duì)原型的評(píng)價(jià)最終確定系統(tǒng)的需求。 快速原型過(guò)程模型包括以下階段: 原型需求分析:分析和提煉所收集到的客戶需求; 原型開(kāi)發(fā):基于初步的需求快速建造一個(gè)可以運(yùn)行的軟件原型,實(shí)現(xiàn)客戶或未來(lái)的
37、用戶與系統(tǒng)的交互; 原型評(píng)價(jià):由用戶或客戶對(duì)該原型進(jìn)行評(píng)價(jià),需要的話再進(jìn)一步細(xì)化待開(kāi)發(fā)軟件的需求,并繼續(xù)調(diào)整原型直至需求確定下來(lái)為止。 3.對(duì)于下列每一個(gè)過(guò)程模型,分別列舉一個(gè)可以適用的具體軟件項(xiàng)目,并說(shuō)明在開(kāi)發(fā)中如何應(yīng) 用該模型。(1)瀑布模型(2)快速原型模型(3)增量模型(4) 形式化方法模型 (5) 基于組件的開(kāi)發(fā)模型 答:(1) 瀑布模型 項(xiàng)目舉例:某項(xiàng)目需要在一種新型機(jī)器上,為一種已知語(yǔ)言開(kāi)發(fā)一個(gè)普通的編譯器。 選用分析:由于該項(xiàng)目的語(yǔ)言是已知的,需求是明確的和穩(wěn)定的,整個(gè)系統(tǒng)屬于中小規(guī)模, 因此適合采用瀑布模型進(jìn)行軟件開(kāi)發(fā)。 階段說(shuō)明:略。 (2) 快速原型模型 項(xiàng)目舉例:某公司
38、需要給火車站開(kāi)發(fā)一個(gè)交互式火車車次查詢系統(tǒng),這是火車站首次使用該 系統(tǒng)。 選用分析:本項(xiàng)目的主要問(wèn)題在于用戶需要方面,該系統(tǒng)與最終用戶的交互是十分關(guān)鍵的, 但是在項(xiàng)目初期用戶的需求基本上是不知道的,因此適合采用快速原型方法來(lái)確定用戶需 求,在需求確定的基礎(chǔ)上再開(kāi)發(fā)最終系統(tǒng)。 階段說(shuō)明:略。 (3) 增量模型 項(xiàng)目舉例:某公司開(kāi)發(fā)一個(gè)通用 CAD 軟件產(chǎn)品,產(chǎn)品需求是逐步完善的,某些需求在一定 范圍內(nèi)是明確的,某些需求需要進(jìn)一步細(xì)化,但是迫于市場(chǎng)競(jìng)爭(zhēng)的壓力產(chǎn)品需要盡快上市。 選用分析:通用 CAD 軟件產(chǎn)品具有一定的成熟度,總體需求和軟件系統(tǒng)結(jié)構(gòu)是可以確定的, 但是實(shí)現(xiàn)該產(chǎn)品所有功能需要比較長(zhǎng)的
39、開(kāi)發(fā)周期。為了盡快上市可以采用增量模型實(shí)行多版 本的發(fā)布策略,既可以很快占領(lǐng)市場(chǎng)又可以為后續(xù)版本的需求定義奠定基礎(chǔ)。 階段說(shuō)明:略。 (4) 形式化方法模型 項(xiàng)目舉例:某公司開(kāi)發(fā)一個(gè)汽車防抱死剎車控制系統(tǒng)。 選用分析:由于該系統(tǒng)對(duì)安全性和可靠性要求極高,需要在系統(tǒng)運(yùn)行之前進(jìn)行相關(guān)性能的檢 驗(yàn),因此適合采用形式化方法開(kāi)發(fā)該系統(tǒng)。 階段說(shuō)明:略。 (5) 基于組件的開(kāi)發(fā)模型 項(xiàng)目舉例:某公司開(kāi)發(fā)企業(yè)管理 ERP 系統(tǒng),包括銷售、庫(kù)存、生產(chǎn)、財(cái)務(wù)、物流、人力資 源等部分,在系統(tǒng)實(shí)施過(guò)程中不同的企業(yè)具有一定的需求差異。 選用分析:企業(yè) ERP 系統(tǒng)具有組件化的結(jié)構(gòu),在不同企業(yè)實(shí)施時(shí)應(yīng)該盡量重用已有的組
40、件, 因此適合采用基于組件的開(kāi)發(fā)模型開(kāi)發(fā)該系統(tǒng),在直接應(yīng)用或者修改使用的基礎(chǔ)上,最終進(jìn) 行組件開(kāi)發(fā)和系統(tǒng)集成。 階段說(shuō)明:略。4. 在螺旋模型中,風(fēng)險(xiǎn)分析的作用是什么? 答: 在螺旋模型中,軟件開(kāi)發(fā)是在風(fēng)險(xiǎn)等級(jí)的指導(dǎo)下進(jìn)行的。首先確定該階段的目標(biāo),完成這些目標(biāo)的選擇方案及其約束條件;其次從風(fēng)險(xiǎn)角度分析方案的開(kāi)發(fā)策略,努力排除各種潛在的風(fēng)險(xiǎn),在需求不適當(dāng)?shù)那闆r下可能需要建造原型系統(tǒng);如果某些風(fēng)險(xiǎn)不能排除,該方案可能立即終止,否則繼續(xù)啟動(dòng)下一步的軟件開(kāi)發(fā)和驗(yàn)證工作,并再次通過(guò)風(fēng)險(xiǎn)分析規(guī)定過(guò)程遵循的策略;最后,評(píng)價(jià)該階段的結(jié)果,并規(guī)劃下一個(gè)迭代。 從上述過(guò)程中可以看出,風(fēng)險(xiǎn)分析的作用是通過(guò)識(shí)別項(xiàng)目中
41、的高風(fēng)險(xiǎn)問(wèn)題,使開(kāi)發(fā)人員制定適當(dāng)?shù)拈_(kāi)發(fā)策略消除這些風(fēng)險(xiǎn)。 5. 某大學(xué)準(zhǔn)備開(kāi)發(fā)一個(gè)新的學(xué)生注冊(cè)選課系統(tǒng),以替換一個(gè)現(xiàn)有的系統(tǒng)。請(qǐng)?jiān)O(shè)計(jì)一個(gè)適用于該系統(tǒng)開(kāi)發(fā)的過(guò)程模型,并進(jìn)一步描述該模型。 答: 假設(shè)原有的學(xué)生注冊(cè)課程系統(tǒng)是由學(xué)生手工提交書面選課單,教師手工提交成績(jī)單,教務(wù)管理人員在客戶端錄入學(xué)生選課結(jié)果和課程成績(jī);而在新的選課系統(tǒng)中,所有用戶在自己的計(jì)算機(jī)上通過(guò)Internet訪問(wèn)和操作該系統(tǒng),該軟件系統(tǒng)需要更新服務(wù)器和數(shù)據(jù)庫(kù)等系統(tǒng),并擴(kuò)充一些新功能和提高系統(tǒng)性能。 從該系統(tǒng)的具體情況來(lái)看,系統(tǒng)的需求是比較容易明確的,整個(gè)系統(tǒng)的結(jié)構(gòu)需要重新設(shè)計(jì),但是原有的遺留系統(tǒng)中有些部分是可以重用的,因此我們
42、可以采用組件模型實(shí)施軟件開(kāi)發(fā): 系統(tǒng)需求分析:由于該系統(tǒng)是現(xiàn)有系統(tǒng)的擴(kuò)展,因此首先可以經(jīng)過(guò)一個(gè)簡(jiǎn)單的需求分析階段,從而確定新系統(tǒng)的需求。 遺留系統(tǒng)分析:在需求確定的基礎(chǔ)上,開(kāi)發(fā)人員分析遺留系統(tǒng)并研究新系統(tǒng)的總體結(jié)構(gòu),選擇重用原有的課程信息管理部分,重新開(kāi)發(fā)選課部分,必要時(shí)適當(dāng)修改系統(tǒng)需求,最終確定系統(tǒng)需求和總體結(jié)構(gòu)。 設(shè)計(jì)開(kāi)發(fā)階段:開(kāi)發(fā)人員進(jìn)一步設(shè)計(jì)相關(guān)子系統(tǒng),將原有的課程信息管理部分封裝為子系統(tǒng),重新開(kāi)發(fā)學(xué)生選課子系統(tǒng),并實(shí)現(xiàn)與外部付費(fèi)系統(tǒng)的接口。 系統(tǒng)測(cè)試階段:開(kāi)發(fā)人員將所有子系統(tǒng)集成在一起,交給測(cè)試人員開(kāi)始全面的功能測(cè)試和性能測(cè)試。根據(jù)所報(bào)告的測(cè)試問(wèn)題,開(kāi)發(fā)人員調(diào)試和修改程序。 系統(tǒng)交付
43、階段:測(cè)試通過(guò)后,開(kāi)發(fā)人員將系統(tǒng)及其相關(guān)文檔交付用戶驗(yàn)收。 6. 請(qǐng)舉例說(shuō)明不同的過(guò)程模型組合使用的情況。 答: 在前面提到的企業(yè)管理ERP系統(tǒng)項(xiàng)目中,可以將快速原型方法、組件開(kāi)發(fā)模型和增量模型組合在一起使用,即在需求分析階段采用原型方法確定需求,采用組件化的結(jié)構(gòu)設(shè)計(jì)整個(gè)系統(tǒng),并采用增量方式逐步交付整個(gè)系統(tǒng)。 軟件項(xiàng)目管理2. 某個(gè)軟件項(xiàng)目需要 30 名開(kāi)發(fā)人員,現(xiàn)有兩種人員組織方案: (1) 將 30 人劃為一個(gè)開(kāi)發(fā)組統(tǒng)一管理; (2) 按每個(gè)小組 6 人的方式,將 30 人分為 5 個(gè)小組。 請(qǐng)分析比較上述兩種方案的優(yōu)缺點(diǎn)。 參考答案: 由于軟件規(guī)模的增大,需要多人組成開(kāi)發(fā)小組共同參與一個(gè)
44、項(xiàng)目的開(kāi)發(fā)。但是當(dāng)多個(gè)人共同承 擔(dān)軟件開(kāi)發(fā)項(xiàng)目中的某一任務(wù)時(shí),人與人之間必須通過(guò)交流來(lái)解決各自承擔(dān)任務(wù)之間的接口問(wèn)題, 這就產(chǎn)生了所謂溝通復(fù)雜性的問(wèn)題。溝通需要花費(fèi)時(shí)間和代價(jià),也會(huì)引起軟件錯(cuò)誤的增加,降低開(kāi) 發(fā)效率。 (1) 優(yōu)點(diǎn):30 人集中在同一個(gè)開(kāi)發(fā)小組,人員任務(wù)的分配和調(diào)度相對(duì)容易; 缺點(diǎn):溝通復(fù)雜性高,從而導(dǎo)致人員之間配合混亂,開(kāi)發(fā)效率低。 (2) 優(yōu)點(diǎn):30 人劃分成 5 個(gè)小組,降低了溝通復(fù)雜性,提高開(kāi)發(fā)效率; 缺點(diǎn):小組之間的協(xié)調(diào)配合難度大。3. 在選擇人員進(jìn)行軟件項(xiàng)目開(kāi)發(fā)時(shí),應(yīng)該考慮哪些因素? 參考答案: 需求工程1. 請(qǐng)舉例說(shuō)明使用自然語(yǔ)言描述用戶需求和系統(tǒng)需求的問(wèn)題。 答
45、: 用自然語(yǔ)言描述比較詳細(xì)的需求時(shí)經(jīng)常暴露以下問(wèn)題,從而容易引起誤解。 由于自然語(yǔ)言存在二義性,因此人們對(duì)同一個(gè)術(shù)語(yǔ)經(jīng)常存在語(yǔ)義理解上的偏差。 用自然語(yǔ)言描述需求存在比較大的隨意性,人們對(duì)同一個(gè)事物有完全不同的方式進(jìn)行描述。 自然語(yǔ)言描述需求缺乏模塊化,因此很難發(fā)現(xiàn)所描述需求之間的相關(guān)性。 2. 請(qǐng)指出下面需求描述存在的問(wèn)題,并進(jìn)行適當(dāng)?shù)男薷摹?(1) 系統(tǒng)用戶界面友好。 (2) 系統(tǒng)運(yùn)行時(shí)應(yīng)該占用盡量少的內(nèi)存空間。 (3) 即使在系統(tǒng)崩潰的情況下,用戶數(shù)據(jù)也不能受到破壞。 (4) ATM 系統(tǒng)允許用戶查詢自己銀行帳戶的現(xiàn)存余額。 (5) ATM 系統(tǒng)應(yīng)該快速響應(yīng)用戶的請(qǐng)求。 (6) ATM
46、系統(tǒng)需要檢驗(yàn)用戶存取的合法性。 (7) 所有命令的響應(yīng)時(shí)間小于 1 秒;BUILD 命令的響應(yīng)時(shí)間小于 5 秒。 (8) 軟件應(yīng)該用 JAVA 語(yǔ)言實(shí)現(xiàn)。 答: (1) 問(wèn)題:“友好”是不可驗(yàn)證的。 改正:具有一年計(jì)算機(jī)使用經(jīng)驗(yàn)的用戶經(jīng)過(guò) 3 小時(shí)的培訓(xùn)就可以學(xué)會(huì)使用該系統(tǒng)。 (2) 問(wèn)題:“盡量少”存在歧義。 改正:系統(tǒng)運(yùn)行時(shí)所占用的最大內(nèi)存空間是 256MB。 (3) 問(wèn)題:“不能受到破壞”是不可驗(yàn)證的。 改正:如果系統(tǒng)發(fā)生崩潰,那么該系統(tǒng)重新正常啟動(dòng)后,可以將用戶數(shù)據(jù)恢復(fù)到最后 未完成操作執(zhí)行前的狀態(tài)。 (4) 該描述是正確的。 (5) 問(wèn)題:“快速”是不可驗(yàn)證的。 改正:ATM 系統(tǒng)將
47、在 1 秒鐘之內(nèi)響應(yīng)用戶的請(qǐng)求。 (6) 問(wèn)題:“如何驗(yàn)證合法性”是存在歧義的。 改正:ATM 系統(tǒng)將通過(guò)用戶名和口令驗(yàn)證其存取的合法性。 (7) 問(wèn)題:所有命令中必然會(huì)包括 BUILD 命令,因此這兩個(gè)需求描述是矛盾的。 改正:去掉關(guān)于 BUILD 命令的需求描述。 (8) 問(wèn)題:該描述不是功能需求或非功能需求,應(yīng)該是對(duì)設(shè)計(jì)實(shí)現(xiàn)的一個(gè)約束條件。3. 需求工程包括哪些基本活動(dòng)?每一項(xiàng)活動(dòng)的主要任務(wù)是什么? 答: 需求工程分為需求開(kāi)發(fā)和需求管理兩個(gè)部分,而需求開(kāi)發(fā)又可進(jìn)一步分為需求獲取、需求分 析、規(guī)格說(shuō)明和需求驗(yàn)證四個(gè)階段。這些基本活動(dòng)的主要任務(wù)包括: (1) 需求獲?。翰杉⒆R(shí)別和提取用戶的
48、需求,對(duì)問(wèn)題和需求形成文檔化的描述,使各種 人員達(dá)成一致的理解和認(rèn)可。 (2) 需求分析:分析和綜合所采集的信息,建立系統(tǒng)的詳細(xì)邏輯模型。 (3) 需求規(guī)格說(shuō)明:編寫軟件需求規(guī)格說(shuō)明書,明確、完整和準(zhǔn)確地描述已確定的需求。 (4) 需求驗(yàn)證:評(píng)審軟件需求規(guī)格說(shuō)明,以保證其正確性、一致性、完備性、準(zhǔn)確性和清 晰性。 (5) 需求管理:定義需求基線,在整個(gè)項(xiàng)目過(guò)程中跟蹤需求狀態(tài)及其變更情況。4. 請(qǐng)比較本章介紹的幾種主要需求獲取技術(shù),說(shuō)明每一種技術(shù)的優(yōu)缺點(diǎn)和適用場(chǎng)合。 答: (1) 用戶面談 優(yōu)點(diǎn): 可以與項(xiàng)目相關(guān)人員一對(duì)一地進(jìn)行交談和討論; 具有私密性,使被訪者可以直率地和無(wú)隱瞞地回答問(wèn)題; 便
49、于探查一些附加信息或反饋信息; 有利于與客戶建立良好的關(guān)系。 缺點(diǎn): 面談是一種非常費(fèi)時(shí)和高成本的方式; 難以解決不同的項(xiàng)目干系人之間的沖突和矛盾; 在地理位置相距較遠(yuǎn)的情況下很難實(shí)施。 適用場(chǎng)合: 適用于在初步理解整體概念的情況下討論和交流一些細(xì)節(jié)問(wèn)題。 (2) 需求專題討論會(huì) 優(yōu)點(diǎn): 有助于了解系統(tǒng)需求; 有利于共享系統(tǒng)開(kāi)發(fā)的成果; 給用戶一種主人的感覺(jué); 可以與足夠多的項(xiàng)目干系人進(jìn)行討論和交流,且節(jié)省時(shí)間; 支持頭腦風(fēng)暴式的討論。 缺點(diǎn): 需要占用參與人員比較長(zhǎng)的整塊時(shí)間; 主持人的能力和會(huì)議的準(zhǔn)備工作必須是非常好的,否則結(jié)果很糟。 適用場(chǎng)合: 適用于討論和審查軟件系統(tǒng)方案和模型,解決不
50、同項(xiàng)目干系人之間的沖突和矛盾。 (3) 觀察用戶工作流程 優(yōu)點(diǎn): 通過(guò)直接觀察的方式提取用戶或系統(tǒng)的特性; 有助于理解難以用語(yǔ)言描述清楚的復(fù)雜業(yè)務(wù)。 缺點(diǎn): 觀察可能使用戶緊張,從而表現(xiàn)得與往常不同。 適用場(chǎng)合: 適用于理解難以用語(yǔ)言描述清楚復(fù)雜業(yè)務(wù)過(guò)程。 (4) 原型化方法 優(yōu)點(diǎn): 通過(guò)一個(gè)可以運(yùn)行的軟件原型直觀地理解和澄清問(wèn)題,便于使開(kāi)發(fā)人員與用戶達(dá)成共識(shí)。 缺點(diǎn): 用戶容易產(chǎn)生誤解,認(rèn)為軟件系統(tǒng)可以在原型的基礎(chǔ)上很容易地構(gòu)建,但實(shí)際上該原型的內(nèi)部結(jié)構(gòu)和程序質(zhì)量比較差。 適用場(chǎng)合: 適用于用戶需求不明確或描述不清楚的情況。5. 哪些人應(yīng)該參與需求評(píng)審?請(qǐng)畫出一個(gè)需求評(píng)審的組織過(guò)程模型。 答
51、: 通常情況下,參與需求評(píng)審的人員應(yīng)該包括需求分析員、項(xiàng)目經(jīng)理、體系架構(gòu)設(shè)計(jì)師、軟件設(shè)計(jì)工程師、系統(tǒng)測(cè)試工程師、質(zhì)量保證員、用戶或市場(chǎng)代表、文檔編寫人員、領(lǐng)域?qū)<液图夹g(shù)支持代表。 6. 在某些緊急情況下,軟件可能在需求變更請(qǐng)求被批準(zhǔn)之前就進(jìn)行修改。請(qǐng)給出一個(gè)修改過(guò)程模型,確保需求文檔和系統(tǒng)實(shí)現(xiàn)不會(huì)產(chǎn)生不一致。 答: 一般來(lái)說(shuō),應(yīng)該盡量避免在需求變更請(qǐng)求被批準(zhǔn)之前就直接修改程序的情況,這很容易導(dǎo)致變更失控而且需求描述與系統(tǒng)實(shí)現(xiàn)不一致。一旦出現(xiàn)這種情況,必須在系統(tǒng)變更完成后重新執(zhí)行需求跟蹤控制。 8. 請(qǐng)給出以下問(wèn)題描述的用例模型。 一個(gè)新的音像商店準(zhǔn)備采用計(jì)算機(jī)系統(tǒng)向比較廣泛的人群銷售或租借錄像
52、帶和光碟。該音像商店將存有大約1000盤錄像帶和500張光碟,這些訂購(gòu)涉及多家訂購(gòu)商。所有的錄像帶和光碟都有一個(gè)條碼,可以使用條碼掃描儀來(lái)支持銷售和返還,客戶會(huì)員卡也同時(shí)條碼化。 客戶可以預(yù)定錄像帶并在指定日期來(lái)取。系統(tǒng)必須擁有靈活的搜索機(jī)制來(lái)回答客戶的詢問(wèn),包括關(guān)于該音像商店還沒(méi)有進(jìn)貨的電影(但可能是已經(jīng)請(qǐng)求訂購(gòu)了)。 參考答案: 面向?qū)ο蠡A(chǔ)1. 請(qǐng)解釋下列術(shù)語(yǔ),并舉例說(shuō)明之。 對(duì)象、類、屬性、操作、關(guān)聯(lián)、泛化、聚合、依賴 參考答案: (1) 對(duì)象(Object) 對(duì)象是系統(tǒng)中用來(lái)描述客觀事物的一個(gè)實(shí)體,它是構(gòu)成系統(tǒng)的一個(gè)基本單位,由一組屬性和對(duì)這組屬性進(jìn)行操作的一組服務(wù)組成。 舉例:中國(guó)
53、就是一個(gè)對(duì)象。 (2) 類(Class) 類是具有相同屬性和服務(wù)的一組對(duì)象的集合,它為屬于該類的全部對(duì)象提供了統(tǒng)一的抽象描述,包括屬性和服務(wù)兩個(gè)主要部分。 舉例:學(xué)生、人、樹(shù)木等都是類。 (3) 屬性(Attribute) 屬性是用來(lái)描述對(duì)象靜態(tài)特征的一個(gè)數(shù)據(jù)項(xiàng)。 舉例:學(xué)生具有姓名、性別、年齡等屬性。 (4) 操作(Operation) 操作是類的實(shí)例被要求執(zhí)行的服務(wù),具有名字和參數(shù)列表。 舉例:學(xué)生具有入學(xué)注冊(cè)、選課等操作。 (5) 關(guān)聯(lián)(Association) 關(guān)聯(lián)是一種結(jié)構(gòu)關(guān)系,說(shuō)明一個(gè)事物的對(duì)象與另一個(gè)事物的對(duì)象之間的聯(lián)系。 舉例:學(xué)生與課程之間的關(guān)系就是關(guān)聯(lián),一個(gè)學(xué)生可以選修多門
54、課程,一門課程也可以被多個(gè)學(xué)生選修。 (6) 泛化(Generalization) 泛化是一種一般事物(父類)和特殊事物(子類)之間的關(guān)系。 舉例:學(xué)生與研究生之間是泛化關(guān)系,研究生是一類特殊的學(xué)生。 (7) 聚合(Aggregation) 聚合是一種特殊類型的關(guān)聯(lián),描述了整體和部分間的結(jié)構(gòu)關(guān)系。 舉例:學(xué)校和系之間存在聚合關(guān)系,系是學(xué)校的一個(gè)組成部分。 (8) 依賴(Dependency) 依賴是一種使用關(guān)系,描述了一個(gè)事物發(fā)生變化會(huì)影響到另一個(gè)使用它的事物。 舉例:課程表使用課程,二者之間是依賴關(guān)系。 2. 請(qǐng)簡(jiǎn)要說(shuō)明類圖和順序圖的組成。 參考答案: 在系統(tǒng)中,類圖由類、類的屬性和操作以及
55、類之間的各種聯(lián)系所組成。下圖顯示了計(jì)算機(jī)及其組成部分,如處理器、內(nèi)存、鍵盤、硬盤、顯示器等。 時(shí)序圖表示對(duì)象之間的交互順序,它由角色、對(duì)象、生命線和消息組成,其中角色代表與系統(tǒng)交互的外部事物。下圖顯示了時(shí)序圖的一種通用表示方法。 3. 在軟件開(kāi)發(fā)過(guò)程中為什么需要建立模型? 答案要點(diǎn): 在軟件開(kāi)發(fā)過(guò)程中,建立軟件模型具有十分重要的作用,主要體現(xiàn)在以下方面: 1.有助于問(wèn)題的簡(jiǎn)化,通過(guò)抽象降低復(fù)雜性;2.有助于和其他開(kāi)發(fā)小組成員、各種用戶以及系統(tǒng)相關(guān)者進(jìn)行交流;3.有助于維護(hù)人員了解軟件設(shè)計(jì)的思路和細(xì)節(jié),為以后的維護(hù)和升級(jí)提供了文檔。4. UML關(guān)系包括關(guān)聯(lián)、聚合、泛化、實(shí)現(xiàn)、依賴等5種類型,請(qǐng)指
56、出下面關(guān)系的類型,并采用UML符號(hào)表示這些關(guān)系。 (1) 在學(xué)校中,一個(gè)學(xué)生可以選修多門課程,一門課程可以由多個(gè)學(xué)生選修,那么學(xué)生和課程之間是什么關(guān)系? (2) 類A的一個(gè)操作調(diào)用類B的一個(gè)操作,且這兩個(gè)類之間不存在其他關(guān)系,那么類A和類B之間是什么關(guān)系? (3) 接口及其實(shí)現(xiàn)類或構(gòu)件之間是什么關(guān)系? (4) 一個(gè)汽車有四個(gè)輪子,那么類“汽車”和“輪子”之間是什么關(guān)系? (5) 學(xué)生與研究生之間是什么關(guān)系? 參考答案: (1) 關(guān)聯(lián) (2)依賴 (3)實(shí)現(xiàn) (4)聚合 (5)泛化 5. 請(qǐng)根據(jù)下面的描述,給出表示一本書的類圖。 一本書由許多部分組成,而這些部分又由許多章組成,章由節(jié)組成。 一本書包括出版商、出版日期和ISBN;一部分包括一個(gè)標(biāo)題和一個(gè)序號(hào);一章包括一個(gè)標(biāo)題、一個(gè)序號(hào)和一個(gè)摘要;一節(jié)包括一個(gè)標(biāo)題和一個(gè)序號(hào)。 參考答案: 6. 考慮習(xí)題5的類圖,注意部分、章和節(jié)等類都包括標(biāo)題和序號(hào)屬性,請(qǐng)修改類圖,添加一個(gè)抽象類和一個(gè)泛化關(guān)系,將標(biāo)題和序號(hào)這兩個(gè)屬性提
溫馨提示
- 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。
最新文檔
- 人工智能與教育機(jī)器人的融合趨勢(shì)分析
- 教育心理學(xué)在醫(yī)療培訓(xùn)中的實(shí)踐
- 增強(qiáng)現(xiàn)實(shí)的潛力論其在血液分析教學(xué)中的應(yīng)用
- 教育建筑的節(jié)能減排與環(huán)境教育價(jià)值
- 學(xué)校建設(shè)項(xiàng)目監(jiān)理工作分析
- 打造互動(dòng)課堂游戲化教育的實(shí)踐與思考
- 家庭教育政策在社區(qū)的推廣與實(shí)踐
- 2025屆陜西省延安市物理高一下期末預(yù)測(cè)試題含解析
- 醫(yī)療科技在全球化時(shí)代的挑戰(zhàn)與機(jī)遇
- 基礎(chǔ)護(hù)士心血管疾病護(hù)理考試題庫(kù)及答案
- 浙江省中學(xué)生藝術(shù)特長(zhǎng)b級(jí)測(cè)試-美術(shù)西畫基礎(chǔ)知識(shí)復(fù)習(xí)提綱(完整版)資料
- GB/T 40427-2021電力系統(tǒng)電壓和無(wú)功電力技術(shù)導(dǎo)則
- GB/T 25413-2010農(nóng)田地膜殘留量限值及測(cè)定
- GB/T 17007-1997絕緣柵雙極型晶體管測(cè)試方法
- GB/T 15056-2017鑄造表面粗糙度評(píng)定方法
- 化學(xué)水處理安全檢查表
- DB34-T 4102-2022廢舊鋰離子動(dòng)力蓄電池貯存安全技術(shù)條件-高清現(xiàn)行
- 景陵峪構(gòu)造報(bào)告構(gòu)造地質(zhì)學(xué)
- GB∕T 8163-2018 輸送流體用無(wú)縫鋼管
- 機(jī)動(dòng)車排放檢驗(yàn)檢測(cè)方法內(nèi)部審批程序
- 2MW工商業(yè)分布式光伏電站項(xiàng)目可行性研究報(bào)告
評(píng)論
0/150
提交評(píng)論