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

2、的需求定義，容易適應需求的變化；（2）有利于開發與培訓的同步；（3）開發費用低、開發周期短且對用戶更友好。快速原型模型的缺點：（1）客戶與開發者對原型理解不同；（2） 準確的原型設計比較困難；（3） 不利于開發人員的創新。快速原型模型的使用范圍：（1）對所開發的領域比較熟悉而且有快速的原型開發工具；（2）項目招投標時，可以以原型模型作為軟件的開發模型；（3）進行產品移植或升級時，或對已有產品原型進行客戶化工作時，原型模型是非常適合的。增量模型的優點：（1）采用增量模型的優點是人員分配靈活，剛開始不用投入大量人力資源；（2）如果核心產品很受歡迎，則可增加人力實現下一個增量；（3）可先發布部分功能

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

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

5、而上周期的各階段是相互迭代和無間隙的特性。軟件的某個部分常常被重復工作多次，相關對象在每次迭代中隨之加入漸進的軟件成分。無間隙指在各項活動之間無明顯邊界，如分析和設計活動之間沒有明顯的界限，由于對象概念的引入，表達分析、設計、實現等活動只用對象類和關系，從而可以較為容易地實現活動的迭代和無間隙，使其開發自然地包括復用。1 優點缺點編輯1、噴泉模型的優點噴泉模型不像瀑布模型那樣，需要分析活動結束后才開始設計活動，設計活動結束后才開始編碼活動。該模型的各個階段沒有明顯的界限，開發人員可以同步進行開發。其優點是可以提高軟件項目開發效率，節省開發時間，適應于面向對象的軟件開發過程。 

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

7、件開發費用不斷增加。 e. 軟件開發技術落后。 f. 生產方式落后。 g. 開發工具落后，h. 生產率提高緩慢。i. 與軟件本身的特點有關1. 簡述軟件危機的現象和原因.2. 解釋瀑布模型、增量模型，并繪制示意圖.3. Usecase Diagram及Activity Diagram的用途是？圖形符號？其中文、英文名稱分別是？4. 何為制品（artifact）？5. 基于面向對象的需求分析步驟及制品是什么？6. 軟件設計有幾個任務？分別是什么？7. 寫出基于面向對象的軟件架構設計的步驟及制品.8. 寫出基于面向對象類的設計步驟及制品.9. 寫出基于結構化的軟件需求分析的步驟及制品.10. 分別

8、繪制Sequence Diagram, Collaboration Diagram，解釋其中的圖形符號.11. 解釋DFD（Data Flow Diagram）UML圖用例圖：是由參與者、用例、以及他們之間的關系的用于描述系統功能的動態視圖稱為用例圖。組成：參與者、用例、系統邊界、關系（依賴關系、泛化關系、擴展關系）。類圖：用于描述系統的靜態靜態結構。組成：類、接口、關系（關聯關系、依賴關系、泛化關系、實現關系）對象圖：描述了系統在某一個特定時間點上的靜態結構，是類圖的實例和快照。組成：對象、鏈。序列圖：是對對象之間傳送消息的時間順序的可視化表示。組成：對象、生命線、激活、消息。協作圖：是對一

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

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

11、鍵抽象 數據類是關鍵類13 網頁 輸入域名-IP-服務器-打開根目錄中的HTML文件FTP 文件傳輸協議HTTP 超文本傳輸協議14 給予面向對象大的理論 所有需求分析步驟獲取-分析與建模-編寫規約-驗證15 軟件的生命周期 三個時期、七個階段16 結構圖（模塊圖） 扇出：改模版直接調用模塊數目。扇入：能直接調用該模版的模塊數目。注意：深度不要超過5，寬度不超過7. 扇出3-9 不能隔層調用，不能反向調用，不能調用不屬于自己范圍的。模塊圖DFD分變換流、事件流。概要設計：模塊圖。詳細設計：H、IPO圖。模塊：耦合和內聚17 、結構化設計單入口、單出口、沒有go to，能畫出N-S圖只存在順序、

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

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

14、方法是互相解決彼此問題的方法，自頂向下法:1、從主控模塊（“主程序”）開始，沿著軟件的控制層次向下移動，從而逐漸把各個模塊結合起來。2、在組裝過程中，可以使用深度優先的策略，或寬度優先的策略。自底向上法：(1)把低層模塊組合成實現某個特定的軟件子功能的族。(2)寫一個驅動程序（用于測試的控制程序），協調測試數據的輸入和輸出。 (3)對由模塊組成的子功能族進行測試。(4)去掉驅動程序，沿軟件結構自下向上移動，把子功能族組合起來形成更大的子功能族。自頂向下法的主要優點：不需要測試驅動程序，能夠在測試階段的早期實現并驗證系統的主要功能，而且能在早期發現上層模塊的接口錯誤。自頂向下法的主要缺點：需要存

15、根程序，可能遇到與此相聯系的測試困難，低層關鍵模塊中的錯誤發現較晚，而且用這種方法在早期不能充分展開人力。自底向上法的優缺點與自頂向下法剛好相反。混合法：對軟件結構中較上層，使用的是“自頂向下”法；對軟件結構中較下層，使用的是“自底向上”法，兩者相結合。21確認測試確認測試也稱為驗收測試，它的目標是驗證軟件的有效性。驗證是指的是保證軟件的正確地實現了某個特定要求的一系列活動，而確認指的是為了保證軟件確實滿足了用戶需求而進行的一系列活動。驗收測試一般使用黑盒測試法。應該仔細設計測試計劃和測試過程 。22系統測試軟件開發完后要與系統中的其它部分配套運行。一般系統除了確認測試外，還要進行以下的系統測

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