軟件工程備考

1、模型瀑布模型的優(yōu)點(diǎn)：有利于大型軟件開發(fā)過(guò)程中人員的組織、管理，有利于軟件開發(fā)方法和工具的研究，從而提高了大型軟件項(xiàng)目開發(fā)的質(zhì)量和效率。瀑布模型的缺點(diǎn)：（1）開發(fā)過(guò)程一般不能逆轉(zhuǎn)，否則代價(jià)太大；（2）實(shí)際的項(xiàng)目開發(fā)很難嚴(yán)格按該模型進(jìn)行；（3）客戶往往很難清楚地給出所有的需求，而該模型卻要求如此。（4）軟件的實(shí)際情況必須到項(xiàng)目開發(fā)的后期客戶才能看到，這要求客戶有足夠的耐心。 瀑布模型的使用范圍：（1）用戶的需求非常清楚全面，且在開發(fā)過(guò)程中沒有或很少變化；（2）開發(fā)人員對(duì)軟件的應(yīng)用領(lǐng)域很熟悉；（3）用戶的使用環(huán)境非常穩(wěn)定；（4）開發(fā)工作對(duì)用戶參與的要求很低。快速原型模型的優(yōu)點(diǎn)：（1）可以得到比較良好

2、的需求定義，容易適應(yīng)需求的變化；（2）有利于開發(fā)與培訓(xùn)的同步；（3）開發(fā)費(fèi)用低、開發(fā)周期短且對(duì)用戶更友好?？焖僭湍Ｐ偷娜秉c(diǎn)：（1）客戶與開發(fā)者對(duì)原型理解不同；（2） 準(zhǔn)確的原型設(shè)計(jì)比較困難；（3） 不利于開發(fā)人員的創(chuàng)新。快速原型模型的使用范圍：（1）對(duì)所開發(fā)的領(lǐng)域比較熟悉而且有快速的原型開發(fā)工具；（2）項(xiàng)目招投標(biāo)時(shí)，可以以原型模型作為軟件的開發(fā)模型；（3）進(jìn)行產(chǎn)品移植或升級(jí)時(shí)，或?qū)σ延挟a(chǎn)品原型進(jìn)行客戶化工作時(shí)，原型模型是非常適合的。增量模型的優(yōu)點(diǎn)：（1）采用增量模型的優(yōu)點(diǎn)是人員分配靈活，剛開始不用投入大量人力資源；（2）如果核心產(chǎn)品很受歡迎，則可增加人力實(shí)現(xiàn)下一個(gè)增量；（3）可先發(fā)布部分功能

3、給客戶，對(duì)客戶起到鎮(zhèn)靜劑的作用。增量模型的缺點(diǎn)：（1）并行開發(fā)構(gòu)件有可能遇到不能集成的風(fēng)險(xiǎn)，軟件必須具備開放式的體系結(jié)構(gòu)；（2）增量模型的靈活性可以使其適應(yīng)這種變化的能力大大優(yōu)于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而是軟件過(guò)程的控制失去整體性。增量模型的使用范圍：（1）進(jìn)行已有產(chǎn)品升級(jí)或新版本開發(fā)，增量模型是非常適合的；（2）對(duì)完成期限嚴(yán)格要求的產(chǎn)品，可以使用增量模型；（3）對(duì)所開發(fā)的領(lǐng)域比較熟悉而且已有原型系統(tǒng)，增量模型也是非常適合的。螺旋模型的優(yōu)點(diǎn)：（1）設(shè)計(jì)上的靈活性,可以在項(xiàng)目的各個(gè)階段進(jìn)行變更；（2）以小的分段來(lái)構(gòu)建大型系統(tǒng),使成本計(jì)算變得簡(jiǎn)單容易；（3）客戶始終

4、參與每個(gè)階段的開發(fā),保證了項(xiàng)目不偏離正確方向以及項(xiàng)目的可控性；（4） 隨著項(xiàng)目推進(jìn),客戶始終掌握項(xiàng)目的最新信息 , 從而他或她能夠和管理層有效地交互。 螺旋模型的缺點(diǎn)：（1）采用螺旋模型需要具有相當(dāng)豐富的風(fēng)險(xiǎn)評(píng)估經(jīng)驗(yàn)和專門知識(shí)，在風(fēng)險(xiǎn)較大的項(xiàng)目開發(fā)中，如果未能夠及時(shí)標(biāo)識(shí)風(fēng)險(xiǎn)，勢(shì)必造成重大損失；（2）過(guò)多的迭代次數(shù)會(huì)增加開發(fā)成本，延遲提交時(shí)間。螺旋模型的使用范圍：螺旋模型只適合于大規(guī)模的軟件項(xiàng)目。噴泉模型（fountain model）是一種以用戶需求為動(dòng)力，以對(duì)象為驅(qū)動(dòng)的模型，主要用于描述面向?qū)ο蟮能浖_發(fā)過(guò)程。模型概述編輯噴泉模型主要用于采用對(duì)象技術(shù)的軟件開發(fā)項(xiàng)目。該模型認(rèn)為軟件開發(fā)過(guò)程自下

5、而上周期的各階段是相互迭代和無(wú)間隙的特性。軟件的某個(gè)部分常常被重復(fù)工作多次，相關(guān)對(duì)象在每次迭代中隨之加入漸進(jìn)的軟件成分。無(wú)間隙指在各項(xiàng)活動(dòng)之間無(wú)明顯邊界，如分析和設(shè)計(jì)活動(dòng)之間沒有明顯的界限，由于對(duì)象概念的引入，表達(dá)分析、設(shè)計(jì)、實(shí)現(xiàn)等活動(dòng)只用對(duì)象類和關(guān)系，從而可以較為容易地實(shí)現(xiàn)活動(dòng)的迭代和無(wú)間隙，使其開發(fā)自然地包括復(fù)用。1 優(yōu)點(diǎn)缺點(diǎn)編輯1、噴泉模型的優(yōu)點(diǎn)噴泉模型不像瀑布模型那樣，需要分析活動(dòng)結(jié)束后才開始設(shè)計(jì)活動(dòng)，設(shè)計(jì)活動(dòng)結(jié)束后才開始編碼活動(dòng)。該模型的各個(gè)階段沒有明顯的界限，開發(fā)人員可以同步進(jìn)行開發(fā)。其優(yōu)點(diǎn)是可以提高軟件項(xiàng)目開發(fā)效率，節(jié)省開發(fā)時(shí)間，適應(yīng)于面向?qū)ο蟮能浖_發(fā)過(guò)程。 

6、;1 2、噴泉模型的缺點(diǎn)由于噴泉模型在各個(gè)開發(fā)階段是重疊的，因此在開發(fā)過(guò)程中需要大量的開發(fā)人員，因此不利于項(xiàng)目的管理。此外這種模型要求嚴(yán)格管理文檔，使得審核的難度加大，尤其是面對(duì)可能隨時(shí)加入各種信息、需求與資料的情況。 軟件危機(jī)的現(xiàn)象和原因3.現(xiàn)象：早期出現(xiàn)的軟件危機(jī)主要表現(xiàn)在： 軟件開發(fā)費(fèi)用和進(jìn)度失控軟件的可靠性差生產(chǎn)出來(lái)的軟件難以維護(hù)軟件開發(fā)生產(chǎn)率提高的速度遠(yuǎn)遠(yuǎn)跟不上計(jì)算機(jī)應(yīng)用迅速普及深入的需要，軟件產(chǎn)品供不應(yīng)求的狀況使得人類不能充分利用現(xiàn)代計(jì)算機(jī)硬件所能提供的巨大潛力。4.原因：a. 軟件的規(guī)模越來(lái)越大，b. 結(jié)構(gòu)越來(lái)越復(fù)雜。 c. 軟件開發(fā)管理困難而復(fù)雜。 d. 軟

7、件開發(fā)費(fèi)用不斷增加。 e. 軟件開發(fā)技術(shù)落后。 f. 生產(chǎn)方式落后。 g. 開發(fā)工具落后，h. 生產(chǎn)率提高緩慢。i. 與軟件本身的特點(diǎn)有關(guān)1. 簡(jiǎn)述軟件危機(jī)的現(xiàn)象和原因.2. 解釋瀑布模型、增量模型，并繪制示意圖.3. Usecase Diagram及Activity Diagram的用途是？圖形符號(hào)？其中文、英文名稱分別是？4. 何為制品（artifact）？5. 基于面向?qū)ο蟮男枨蠓治霾襟E及制品是什么？6. 軟件設(shè)計(jì)有幾個(gè)任務(wù)？分別是什么？7. 寫出基于面向?qū)ο蟮能浖軜?gòu)設(shè)計(jì)的步驟及制品.8. 寫出基于面向?qū)ο箢惖脑O(shè)計(jì)步驟及制品.9. 寫出基于結(jié)構(gòu)化的軟件需求分析的步驟及制品.10. 分別

8、繪制Sequence Diagram, Collaboration Diagram，解釋其中的圖形符號(hào).11. 解釋DFD（Data Flow Diagram）UML圖用例圖：是由參與者、用例、以及他們之間的關(guān)系的用于描述系統(tǒng)功能的動(dòng)態(tài)視圖稱為用例圖。組成：參與者、用例、系統(tǒng)邊界、關(guān)系（依賴關(guān)系、泛化關(guān)系、擴(kuò)展關(guān)系）。類圖：用于描述系統(tǒng)的靜態(tài)靜態(tài)結(jié)構(gòu)。組成：類、接口、關(guān)系（關(guān)聯(lián)關(guān)系、依賴關(guān)系、泛化關(guān)系、實(shí)現(xiàn)關(guān)系）對(duì)象圖：描述了系統(tǒng)在某一個(gè)特定時(shí)間點(diǎn)上的靜態(tài)結(jié)構(gòu)，是類圖的實(shí)例和快照。組成：對(duì)象、鏈。序列圖：是對(duì)對(duì)象之間傳送消息的時(shí)間順序的可視化表示。組成：對(duì)象、生命線、激活、消息。協(xié)作圖：是對(duì)一

9、次交互過(guò)程中有意義對(duì)象和對(duì)象間的鏈建模，顯示了對(duì)象之間如何進(jìn)行交互以執(zhí)行特定用例或用例中特定部分的行為。組成：對(duì)象、消息、鏈。狀態(tài)圖：用于描述模型元素的實(shí)例（如對(duì)象或交互）的行為。組成：狀態(tài)、轉(zhuǎn)換、事件、判定、同步?；顒?dòng)圖：是一種用于描述系統(tǒng)行為的模型視圖，它可以用來(lái)描述動(dòng)作和動(dòng)作導(dǎo)致對(duì)象狀態(tài)改變的結(jié)果，而不用考慮引發(fā)狀態(tài)改變的事件。組成：動(dòng)作狀態(tài)、活動(dòng)狀態(tài)、組合狀態(tài)、分叉與結(jié)合、分支與合并、泳道、對(duì)象流。5、一個(gè)軟件系統(tǒng)從沒有退出歷史舞臺(tái)的全過(guò)程包括那些階段早期時(shí)代（50世紀(jì)到60世紀(jì)中期以前）軟件是為了具體應(yīng)用而專用編寫20世紀(jì)60年代中期到70年代中期 特點(diǎn)：軟件作坊，6軟件工程的定義把

10、系統(tǒng)的、規(guī)范的、可度量的途徑應(yīng)用于軟件開發(fā)、運(yùn)行、和維護(hù)過(guò)程，也就是把工程應(yīng)用于軟件；研究把軟件工程應(yīng)用于軟件中的操作的途徑中7需求分析 包括：功能需求、性能需求、可靠性和可用性需求、出錯(cuò)處理需求、接口需求、約束、逆向需求、界面需求、用戶或人的因素、環(huán)境需求、界面需求、文檔需求、數(shù)據(jù)需求、資源使用需求、安全保密需求、其他非功能性需求。8可行性分析經(jīng)濟(jì)可行性、技術(shù)、法律、方案選擇9Actor角色用戶、系統(tǒng)、子系統(tǒng)10包B->A 表示A為主11 MVC架構(gòu)表現(xiàn)層MVC 顯示類業(yè)務(wù)層Business 判斷類數(shù)據(jù)層DAO class類ModelViewController數(shù)據(jù) 表現(xiàn) 業(yè)務(wù)12 關(guān)

11、鍵抽象 數(shù)據(jù)類是關(guān)鍵類13 網(wǎng)頁(yè) 輸入域名-IP-服務(wù)器-打開根目錄中的HTML文件FTP 文件傳輸協(xié)議HTTP 超文本傳輸協(xié)議14 給予面向?qū)ο蟠蟮睦碚?所有需求分析步驟獲取-分析與建模-編寫規(guī)約-驗(yàn)證15 軟件的生命周期 三個(gè)時(shí)期、七個(gè)階段16 結(jié)構(gòu)圖（模塊圖） 扇出：改模版直接調(diào)用模塊數(shù)目。扇入：能直接調(diào)用該模版的模塊數(shù)目。注意：深度不要超過(guò)5，寬度不超過(guò)7. 扇出3-9 不能隔層調(diào)用，不能反向調(diào)用，不能調(diào)用不屬于自己范圍的。模塊圖DFD分變換流、事件流。概要設(shè)計(jì)：模塊圖。詳細(xì)設(shè)計(jì)：H、IPO圖。模塊：耦合和內(nèi)聚17 、結(jié)構(gòu)化設(shè)計(jì)單入口、單出口、沒有g(shù)o to，能畫出N-S圖只存在順序、

12、循環(huán)、選擇結(jié)構(gòu)。18 軟件工程在何時(shí)產(chǎn)生 在1968年、北大西洋公約組織的計(jì)算機(jī)科學(xué)家在聯(lián)邦德國(guó)召開了國(guó)際會(huì)議中正式提出并使用了“軟件工程”這個(gè)名詞。19單元測(cè)試單元測(cè)試集中檢測(cè)軟件設(shè)計(jì)的最小單元模塊。有人工測(cè)試和計(jì)算機(jī)測(cè)試兩種方法。主要利用白盒測(cè)試技術(shù)而且對(duì)多個(gè)模塊測(cè)試可以并行的進(jìn)行。單元測(cè)試也稱模塊測(cè)試、邏輯測(cè)試、結(jié)構(gòu)測(cè)試。目的：通過(guò)模塊測(cè)試，使其代碼達(dá)到模塊說(shuō)明書的需求任務(wù)：(1) 對(duì)模塊代碼進(jìn)行編譯，發(fā)現(xiàn)并糾正其語(yǔ)法錯(cuò)誤；(2) 進(jìn)行靜態(tài)分析，驗(yàn)證模塊結(jié)構(gòu)及其內(nèi)部調(diào)用序列是否正確；(3) 確定模塊的測(cè)試策略，并據(jù)此設(shè)計(jì)一組測(cè)試用例和必要的測(cè)試軟件；(4) 用選定的測(cè)試用例對(duì)模塊進(jìn)行測(cè)試

13、，直至滿足測(cè)試終止標(biāo)準(zhǔn)為止；(5) 編制單元測(cè)試報(bào)告。代碼審查：4人一小組，審查之前，小組成員應(yīng)該先研究設(shè)計(jì)說(shuō)明書，力求理解這個(gè)設(shè)計(jì)。審查小組的任務(wù)是發(fā)現(xiàn)錯(cuò)誤而不是改正錯(cuò)誤。實(shí)用測(cè)試策略：為提高測(cè)試效率，克服無(wú)法窮盡測(cè)試的實(shí)際困難，在單元測(cè)試測(cè)試中應(yīng)以邏輯覆蓋為主的策略改為白盒法與黑盒法相結(jié)合，靜態(tài)測(cè)試與動(dòng)態(tài)測(cè)試相結(jié)合，人工測(cè)試與機(jī)器測(cè)試相結(jié)合。20集合測(cè)試集合測(cè)試是測(cè)試和組裝軟件的系統(tǒng)化技術(shù)，主要目標(biāo)時(shí)發(fā)現(xiàn)與接口有關(guān)的問(wèn)題。模塊組裝成程序的時(shí)候有兩種方法：一、非漸增式組裝，按照結(jié)構(gòu)圖一次性將各單元模塊組裝起來(lái)。二、漸增式組裝是指按照結(jié)構(gòu)圖自頂向下或自底向上逐漸安裝。主要用第二種，第二種的兩種

14、方法是互相解決彼此問(wèn)題的方法，自頂向下法:1、從主控模塊（“主程序”）開始，沿著軟件的控制層次向下移動(dòng)，從而逐漸把各個(gè)模塊結(jié)合起來(lái)。2、在組裝過(guò)程中，可以使用深度優(yōu)先的策略，或?qū)挾葍?yōu)先的策略。自底向上法：(1)把低層模塊組合成實(shí)現(xiàn)某個(gè)特定的軟件子功能的族。(2)寫一個(gè)驅(qū)動(dòng)程序（用于測(cè)試的控制程序），協(xié)調(diào)測(cè)試數(shù)據(jù)的輸入和輸出。 (3)對(duì)由模塊組成的子功能族進(jìn)行測(cè)試。(4)去掉驅(qū)動(dòng)程序，沿軟件結(jié)構(gòu)自下向上移動(dòng)，把子功能族組合起來(lái)形成更大的子功能族。自頂向下法的主要優(yōu)點(diǎn)：不需要測(cè)試驅(qū)動(dòng)程序，能夠在測(cè)試階段的早期實(shí)現(xiàn)并驗(yàn)證系統(tǒng)的主要功能，而且能在早期發(fā)現(xiàn)上層模塊的接口錯(cuò)誤。自頂向下法的主要缺點(diǎn)：需要存

15、根程序，可能遇到與此相聯(lián)系的測(cè)試?yán)щy，低層關(guān)鍵模塊中的錯(cuò)誤發(fā)現(xiàn)較晚，而且用這種方法在早期不能充分展開人力。自底向上法的優(yōu)缺點(diǎn)與自頂向下法剛好相反?；旌戏ǎ簩?duì)軟件結(jié)構(gòu)中較上層，使用的是“自頂向下”法；對(duì)軟件結(jié)構(gòu)中較下層，使用的是“自底向上”法，兩者相結(jié)合。21確認(rèn)測(cè)試確認(rèn)測(cè)試也稱為驗(yàn)收測(cè)試，它的目標(biāo)是驗(yàn)證軟件的有效性。驗(yàn)證是指的是保證軟件的正確地實(shí)現(xiàn)了某個(gè)特定要求的一系列活動(dòng)，而確認(rèn)指的是為了保證軟件確實(shí)滿足了用戶需求而進(jìn)行的一系列活動(dòng)。驗(yàn)收測(cè)試一般使用黑盒測(cè)試法。應(yīng)該仔細(xì)設(shè)計(jì)測(cè)試計(jì)劃和測(cè)試過(guò)程 。22系統(tǒng)測(cè)試軟件開發(fā)完后要與系統(tǒng)中的其它部分配套運(yùn)行。一般系統(tǒng)除了確認(rèn)測(cè)試外，還要進(jìn)行以下的系統(tǒng)測(cè)

16、試。（1）恢復(fù)測(cè)試（2）安全測(cè)試（3）強(qiáng)度測(cè)試（4）性能測(cè)試。終止測(cè)試標(biāo)準(zhǔn)：規(guī)定測(cè)試策略和應(yīng)達(dá)標(biāo)準(zhǔn)規(guī)定至少要查出的錯(cuò)誤數(shù)量23Alpha和Beta測(cè)試如果軟件是為某一個(gè)客戶開發(fā)的。就用一系列驗(yàn)證測(cè)試，驗(yàn)收測(cè)試是由最終用戶而不是系統(tǒng)的開發(fā)者進(jìn)行的。如果是為了許多的客戶開發(fā)的，就用Alpha測(cè)試和Beta測(cè)試。Alpha測(cè)試由用戶在開發(fā)者的場(chǎng)所進(jìn)行，并且在開發(fā)者對(duì)用戶的“指導(dǎo)”下進(jìn)行測(cè)試。Aplha測(cè)試是在受控制的環(huán)境中進(jìn)行的。Beta測(cè)試私是由軟件的最終用戶們?cè)谝粋€(gè)或多個(gè)客戶場(chǎng)所進(jìn)行，而卻開發(fā)者不在現(xiàn)場(chǎng)，是投入真實(shí)自由測(cè)試場(chǎng)上進(jìn)行的。24白盒測(cè)試技術(shù)不但結(jié)果要對(duì)，中間的過(guò)程也要對(duì)。邏輯覆蓋測(cè)試法：發(fā) 語(yǔ)句覆蓋 每條語(yǔ)句至少執(zhí)行一次現(xiàn) 判定覆蓋 每一判定的每個(gè)分支至少執(zhí)行一次錯(cuò) 弱 條件覆蓋 每一判定中的每個(gè)條件，分別按“真”、“假”至少各執(zhí)行誤 一次的 判定/條件覆蓋 同時(shí)滿足判定復(fù)蓋和條件復(fù)蓋的要求能 強(qiáng) 條件組合覆蓋 求出判定中所有條件的各種可能組合值，每一可能的條力 件組合至少執(zhí)行一次基本路徑測(cè)試法：使用該測(cè)試方法，首先要計(jì)算程序的環(huán)形復(fù)雜度，并用該復(fù)雜度作為指南