軟件工程備考

模型瀑布模型的優(yōu)點(diǎn)：有利于大型軟件開發(fā)過程中人員的組織、管理，有利于軟件開發(fā)方法和工具的研究，從而提高了大型軟件項(xiàng)目開發(fā)的質(zhì)量和效率。

瀑布模型的缺點(diǎn)：（1）開發(fā)過程一般不能逆轉(zhuǎn)，否則代價太大；（2）實(shí)際的項(xiàng)目開發(fā)很難嚴(yán)格按該模型進(jìn)行；（3）客戶往往很難清楚地給出所有的需求，而該模型卻要求如此。（4）軟件的實(shí)際情況必須到項(xiàng)目開發(fā)的后期客戶才能看到，這要求客戶有足夠的耐心。

瀑布模型的使用范圍：（1）用戶的需求非常清楚全面，且在開發(fā)過程中沒有或很少變化；（2）開發(fā)人員對軟件的應(yīng)用領(lǐng)域很熟悉；（3）用戶的使用環(huán)境非常穩(wěn)定；（4）開發(fā)工作對用戶參與的要求很低。

快速原型模型的優(yōu)點(diǎn)：（1）可以得到比較良好的需求定義，容易適應(yīng)需求的變化；（2）有利于開發(fā)與培訓(xùn)的同步；（3）開發(fā)費(fèi)用低、開發(fā)周期短且對用戶更友好。

快速原型模型的缺點(diǎn)：（1）客戶與開發(fā)者對原型理解不同；（2）準(zhǔn)確的原型設(shè)計比較困難；（3）不利于開發(fā)人員的創(chuàng)新。

快速原型模型的使用范圍：（1）對所開發(fā)的領(lǐng)域比較熟悉而且有快速的原型開發(fā)工具；（2）項(xiàng)目招投標(biāo)時，可以以原型模型作為軟件的開發(fā)模型；（3）進(jìn)行產(chǎn)品移植或升級時，或?qū)σ延挟a(chǎn)品原型進(jìn)行客戶化工作時，原型模型是非常適合的。

增量模型的優(yōu)點(diǎn)：（1）采用增量模型的優(yōu)點(diǎn)是人員分配靈活，剛開始不用投入大量人力資源；（2）如果核心產(chǎn)品很受歡迎，則可增加人力實(shí)現(xiàn)下一個增量；（3）可先發(fā)布部分功能給客戶，對客戶起到鎮(zhèn)靜劑的作用。

增量模型的缺點(diǎn)：（1）并行開發(fā)構(gòu)件有可能遇到不能集成的風(fēng)險，軟件必須具備開放式的體系結(jié)構(gòu)；（2）增量模型的靈活性可以使其適應(yīng)這種變化的能力大大優(yōu)于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而是軟件過程的控制失去整體性。

增量模型的使用范圍：（1）進(jìn)行已有產(chǎn)品升級或新版本開發(fā)，增量模型是非常適合的；（2）對完成期限嚴(yán)格要求的產(chǎn)品，可以使用增量模型；（3）對所開發(fā)的領(lǐng)域比較熟悉而且已有原型系統(tǒng)，增量模型也是非常適合的。

螺旋模型的優(yōu)點(diǎn)：（1）設(shè)計上的靈活性,可以在項(xiàng)目的各個階段進(jìn)行變更；（2）以小的分段來構(gòu)建大型系統(tǒng),使成本計算變得簡單容易；（3）客戶始終參與每個階段的開發(fā),保證了項(xiàng)目不偏離正確方向以及項(xiàng)目的可控性；（4）隨著項(xiàng)目推進(jìn),客戶始終掌握項(xiàng)目的最新信息,從而他或她能夠和管理層有效地交互。

螺旋模型的缺點(diǎn)：（1）采用螺旋模型需要具有相當(dāng)豐富的風(fēng)險評估經(jīng)驗(yàn)和專門知識，在風(fēng)險較大的項(xiàng)目開發(fā)中，如果未能夠及時標(biāo)識風(fēng)險，勢必造成重大損失；（2）過多的迭代次數(shù)會增加開發(fā)成本，延遲提交時間。

螺旋模型的使用范圍：螺旋模型只適合于大規(guī)模的軟件項(xiàng)目。噴泉模型（fountainmodel）是一種以用戶需求為動力，以對象為驅(qū)動的模型，主要用于描述面向?qū)ο蟮能浖_發(fā)過程。模型概述\o"編輯本段"編輯噴泉模型主要用于采用對象技術(shù)的軟件開發(fā)項(xiàng)目。該模型認(rèn)為軟件開發(fā)過程自下而上周期的各階段是相互迭代和無間隙的特性。軟件的某個部分常常被重復(fù)工作多次，相關(guān)對象在每次迭代中隨之加入漸進(jìn)的軟件成分。無間隙指在各項(xiàng)活動之間無明顯邊界，如分析和設(shè)計活動之間沒有明顯的界限，由于對象概念的引入，表達(dá)分析、設(shè)計、實(shí)現(xiàn)等活動只用對象類和關(guān)系，從而可以較為容易地實(shí)現(xiàn)活動的迭代和無間隙，使其開發(fā)自然地包括復(fù)用。[1]

優(yōu)點(diǎn)缺點(diǎn)\o"編輯本段"編輯1、噴泉模型的優(yōu)點(diǎn)噴泉模型不像瀑布模型那樣，需要分析活動結(jié)束后才開始設(shè)計活動，設(shè)計活動結(jié)束后才開始編碼活動。該模型的各個階段沒有明顯的界限，開發(fā)人員可以同步進(jìn)行開發(fā)。其優(yōu)點(diǎn)是可以提高軟件項(xiàng)目開發(fā)效率，節(jié)省開發(fā)時間，適應(yīng)于面向?qū)ο蟮能浖_發(fā)過程。

[1]

2、噴泉模型的缺點(diǎn)由于噴泉模型在各個開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，因此不利于項(xiàng)目的管理。此外這種模型要求嚴(yán)格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況。

軟件危機(jī)的現(xiàn)象和原因3.現(xiàn)象：早期出現(xiàn)的軟件危機(jī)主要表現(xiàn)在：①軟件開發(fā)費(fèi)用和進(jìn)度失控②軟件的可靠性差③生產(chǎn)出來的軟件難以維護(hù)②軟件開發(fā)生產(chǎn)率提高的速度遠(yuǎn)遠(yuǎn)跟不上計算機(jī)應(yīng)用迅速普及深入的需要，軟件產(chǎn)品供不應(yīng)求的狀況使得人類不能充分利用現(xiàn)代計算機(jī)硬件所能提供的巨大潛力。4.原因：軟件的規(guī)模越來越大，結(jié)構(gòu)越來越復(fù)雜。軟件開發(fā)管理困難而復(fù)雜。軟件開發(fā)費(fèi)用不斷增加。軟件開發(fā)技術(shù)落后。生產(chǎn)方式落后。開發(fā)工具落后，生產(chǎn)率提高緩慢。與軟件本身的特點(diǎn)有關(guān)簡述軟件危機(jī)的現(xiàn)象和原因.解釋瀑布模型、增量模型，并繪制示意圖.UsecaseDiagram及ActivityDiagram的用途是？圖形符號？其中文、英文名稱分別是？何為制品（artifact）？基于面向?qū)ο蟮男枨蠓治霾襟E及制品是什么？軟件設(shè)計有幾個任務(wù)？分別是什么？寫出基于面向?qū)ο蟮能浖軜?gòu)設(shè)計的步驟及制品.寫出基于面向?qū)ο箢惖脑O(shè)計步驟及制品.寫出基于結(jié)構(gòu)化的軟件需求分析的步驟及制品.分別繪制SequenceDiagram,CollaborationDiagram，解釋其中的圖形符號.解釋DFD（DataFlowDiagram）UML圖用例圖：是由參與者、用例、以及他們之間的關(guān)系的用于描述系統(tǒ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)系）對象圖：描述了系統(tǒng)在某一個特定時間點(diǎn)上的靜態(tài)結(jié)構(gòu)，是類圖的實(shí)例和快照。組成：對象、鏈。序列圖：是對對象之間傳送消息的時間順序的可視化表示。組成：對象、生命線、激活、消息。協(xié)作圖：是對一次交互過程中有意義對象和對象間的鏈建模，顯示了對象之間如何進(jìn)行交互以執(zhí)行特定用例或用例中特定部分的行為。組成：對象、消息、鏈。狀態(tài)圖：用于描述模型元素的實(shí)例（如對象或交互）的行為。組成：狀態(tài)、轉(zhuǎn)換、事件、判定、同步。活動圖：是一種用于描述系統(tǒng)行為的模型視圖，它可以用來描述動作和動作導(dǎo)致對象狀態(tài)改變的結(jié)果，而不用考慮引發(fā)狀態(tài)改變的事件。組成：動作狀態(tài)、活動狀態(tài)、組合狀態(tài)、分叉與結(jié)合、分支與合并、泳道、對象流。5、一個軟件系統(tǒng)從沒有退出歷史舞臺的全過程包括那些階段早期時代（50世紀(jì)到60世紀(jì)中期以前）軟件是為了具體應(yīng)用而專用編寫20世紀(jì)60年代中期到70年代中期特點(diǎn)：軟件作坊，6軟件工程的定義把系統(tǒng)的、規(guī)范的、可度量的途徑應(yīng)用于軟件開發(fā)、運(yùn)行、和維護(hù)過程，也就是把工程應(yīng)用于軟件；研究把軟件工程應(yīng)用于軟件中的操作的途徑中7需求分析包括：功能需求、性能需求、可靠性和可用性需求、出錯處理需求、接口需求、約束、逆向需求、界面需求、用戶或人的因素、環(huán)境需求、界面需求、文檔需求、數(shù)據(jù)需求、資源使用需求、安全保密需求、其他非功能性需求。8可行性分析經(jīng)濟(jì)可行性、技術(shù)、法律、方案選擇9Actor角色用戶、系統(tǒng)、子系統(tǒng)10包B------->A表示A為主11MVC架構(gòu)表現(xiàn)層MVC——顯示類業(yè)務(wù)層Business——判斷類數(shù)據(jù)層DAO——class類Model——View——Controller數(shù)據(jù)表現(xiàn)業(yè)務(wù)12關(guān)鍵抽象數(shù)據(jù)類是關(guān)鍵類13網(wǎng)頁輸入域名-》IP-》服務(wù)器-》打開根目錄中的HTML文件FTP文件傳輸協(xié)議HTTP超文本傳輸協(xié)議14給予面向?qū)ο蟠蟮睦碚撍行枨蠓治霾襟E獲取-》分析與建模-》編寫規(guī)約-》驗(yàn)證15軟件的生命周期三個時期、七個階段16結(jié)構(gòu)圖（模塊圖）扇出：改模版直接調(diào)用模塊數(shù)目。扇入：能直接調(diào)用該模版的模塊數(shù)目。注意：深度不要超過5，寬度不超過7.扇出3-9不能隔層調(diào)用，不能反向調(diào)用，不能調(diào)用不屬于自己范圍的。模塊圖DFD分變換流、事件流。概要設(shè)計：模塊圖。詳細(xì)設(shè)計：H、IPO圖。模塊：耦合和內(nèi)聚17、結(jié)構(gòu)化設(shè)計單入口、單出口、沒有g(shù)oto，能畫出N-S圖只存在順序、循環(huán)、選擇結(jié)構(gòu)。18軟件工程在何時產(chǎn)生在1968年、北大西洋公約組織的計算機(jī)科學(xué)家在聯(lián)邦德國召開了國際會議中正式提出并使用了“軟件工程”這個名詞。19單元測試單元測試集中檢測軟件設(shè)計的最小單元——模塊。有人工測試和計算機(jī)測試兩種方法。主要利用白盒測試技術(shù)而且對多個模塊測試可以并行的進(jìn)行。單元測試也稱模塊測試、邏輯測試、結(jié)構(gòu)測試。目的：通過模塊測試，使其代碼達(dá)到模塊說明書的需求任務(wù)：(1)對模塊代碼進(jìn)行編譯，發(fā)現(xiàn)并糾正其語法錯誤；(2)進(jìn)行靜態(tài)分析，驗(yàn)證模塊結(jié)構(gòu)及其內(nèi)部調(diào)用序列是否正確；(3)確定模塊的測試策略，并據(jù)此設(shè)計一組測試用例和必要的測試軟件；(4)用選定的測試用例對模塊進(jìn)行測試，直至滿足測試終止標(biāo)準(zhǔn)為止；(5)編制單元測試報告。代碼審查：4人一小組，審查之前，小組成員應(yīng)該先研究設(shè)計說明書，力求理解這個設(shè)計。審查小組的任務(wù)是發(fā)現(xiàn)錯誤而不是改正錯誤。實(shí)用測試策略：為提高測試效率，克服無法窮盡測試的實(shí)際困難，在單元測試測試中應(yīng)以邏輯覆蓋為主的策略改為白盒法與黑盒法相結(jié)合，靜態(tài)測試與動態(tài)測試相結(jié)合，人工測試與機(jī)器測試相結(jié)合。20集合測試集合測試是測試和組裝軟件的系統(tǒng)化技術(shù)，主要目標(biāo)時發(fā)現(xiàn)與接口有關(guān)的問題。模塊組裝成程序的時候有兩種方法：一、非漸增式組裝，按照結(jié)構(gòu)圖一次性將各單元模塊組裝起來。二、漸增式組裝是指按照結(jié)構(gòu)圖自頂向下或自底向上逐漸安裝。主要用第二種，第二種的兩種方法是互相解決彼此問題的方法，自頂向下法:1、從主控模塊（“主程序”）開始，沿著軟件的控制層次向下移動，從而逐漸把各個模塊結(jié)合起來。2、在組裝過程中，可以使用深度優(yōu)先的策略，或?qū)挾葍?yōu)先的策略。自底向上法：(1)把低層模塊組合成實(shí)現(xiàn)某個特定的軟件子功能的族。(2)寫一個驅(qū)動程序（用于測試的控制程序），協(xié)調(diào)測試數(shù)據(jù)的輸入和輸出。(3)對由模塊組成的子功能族進(jìn)行測試。(4)去掉驅(qū)動程序，沿軟件結(jié)構(gòu)自下向上移動，把子功能族組合起來形成更大的子功能族。自頂向下法的主要優(yōu)點(diǎn)：不需要測試驅(qū)動程序，能夠在測試階段的早期實(shí)現(xiàn)并驗(yàn)證系統(tǒng)的主要功能，而且能在早期發(fā)現(xiàn)上層模塊的接口錯誤。自頂向下法的主要缺點(diǎn)：需要存根程序，可能遇到與此相聯(lián)系的測試?yán)щy，低層關(guān)鍵模塊中的錯誤發(fā)現(xiàn)較晚，而且用這種方法在早期不能充分展開人力。自底向上法的優(yōu)缺點(diǎn)與自頂向下法剛好相反。混合法：對軟件結(jié)構(gòu)中較上層，使用的是“自頂向下”法；對軟件結(jié)構(gòu)中較下層，使用的是“自底向上”法，兩者相結(jié)合。21確認(rèn)測試確認(rèn)測試也稱為驗(yàn)收測試，它的目標(biāo)是驗(yàn)證軟件的有效性。驗(yàn)證是指的是保證軟件的正確地實(shí)現(xiàn)了某個特定要求的一系列活動，而確認(rèn)指的是為了保證軟件確實(shí)滿足了用戶需求而進(jìn)行的一系列活動。驗(yàn)收測試一般使用黑盒測試法。應(yīng)該仔細(xì)設(shè)計測試計劃和測試過程。22系統(tǒng)測試軟件開發(fā)完后要與系統(tǒng)中的其它部分配套運(yùn)行。一般系統(tǒng)除了確認(rèn)測試外，還要進(jìn)行以下的系統(tǒng)測試。（1）恢復(fù)測試（2）安全測試（3）強(qiáng)度測試（4）性能測試。終止測試標(biāo)準(zhǔn)：規(guī)定測試策略和應(yīng)達(dá)標(biāo)準(zhǔn)規(guī)定至少要查出的錯誤數(shù)量23Alpha和Beta測試如果軟件是為某一個客戶開發(fā)的。就用一系列驗(yàn)證測試，驗(yàn)收測試是由最終用戶而不是系統(tǒng)的開發(fā)者進(jìn)行的。如果是為了許多的客戶開發(fā)的，就用Alpha測試和Beta測試。Alpha測試由用戶在開發(fā)者的場所進(jìn)行，并且在開發(fā)者對用戶的“指導(dǎo)”下進(jìn)行測試。Aplha測試是在受控制的環(huán)境中進(jìn)行的。Beta測試私是由軟件的最終用戶們在一個或多個客戶場