第一章 軟件工程概述

1. 結合你之前的工程經驗以及任正非致員工信，談談你對軟件工程的看法。

隨著科技的發展，軟件開發的需求量以及開發規模都在不斷地增大，規模越大的軟件工程，各方面需要考慮的問題就越多，所耗費的人力物力就越大。我認為軟件工程的作用就是運用一系列科學的方法，在滿足各方面需求并保證軟件效率的前提下，統籌管理好開發過程的每一步，以最少的人力物力耗費來實現期望的目標。

2.軟件開發就是編碼么？談談你對軟件開發的本質的認識。

編碼是軟件開發的一部分，也是程序員們的工作。我認為軟件開發的過程中除了編碼以外，更重要的是開發人員和客戶的一個不斷地交流，隨著開發過程的進行，客戶的需求也許會發生變化，弄清楚了為什么要寫代碼，要寫怎樣的代碼，實現怎樣的功能，才能夠更好地實現預期的目標。

3.舉例說明軟件的特點有哪些？

軟件開發與硬件研制相比，更依賴于開發人員的業務素質、智力、人員的組織、合作和管理。

大型軟件仍然存在著潛伏的錯誤。

軟件產品開發成功后，只需對原版軟件進行復制，即可生產出任意多的同樣的產品。

還有，軟件在使用過程中的維護工作比硬件要復雜得多。

由于軟件不是物理產品，所以它不會磨損和老化

4.什么是軟件危機？軟件危機出現的原因及解決手段有哪些？

軟件危機是指落后的軟件生產方式無法滿足迅速增長的計算機軟件需求，從而導致軟件開發與維護過程中出現一系列嚴重問題的現象。

出現軟件危機的原因主要有：

軟件本身獨有的特點確實給開發和維護帶來了困難

軟件開發和維護過程不規范

缺乏軟件開發的經驗和有關軟件開發數據的積累

輕視，人們在制定計劃時總會有一些天馬行空的想法和要求，輕視是一個最大的錯誤。

忽視軟件需求分析的重要性、忽視軟件的可理解性、文檔不完備、輕視軟件的可維護性、過分強調編碼技巧等等方面。

用戶與開發人員的溝通問題，從而技術人員獲取的需求不夠全面。

解決手段：
??在軟件工程理論的指導下，建立起較為完備的軟件工業化生產體系，形成強大的軟件生產能力 。軟件標準化與可重用性得到了工業界的高度重視，在避免重用勞動，可以緩解軟件危機。

5.軟件工程的要素有哪些，各有什么作用？

軟件工程的三種基本要素是方法、工具和過程。

軟件工程方法（method）為建造軟件提供技術上的解決方法（“如何做”）。目前使用得最廣泛的方法是傳統方法（結構化方法）和面向對象方法。

工具為方法的運用提供自動的或半自動的軟件支撐環境。

過程是為了獲得高質量的軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。

第三章 軟件過程模型

1.簡述軟件過程、軟件生存周期、軟件過程模型（軟件生存周期模型）三者之間的概念區別。

軟件過程：軟件過程為一個為建造高質量軟件所需完成的任務的框架，即形成軟件產品的一系列步驟，包括中間產品、資源、角色及過程中采取的方法、工具等范疇。

軟件生存周期：指軟件的產生直到報廢的生命周期，周期內有問題定義、可行性分析、總體描述、系統設計、編碼、調試和測試、驗收與運行、維護升級到廢棄等階段。

軟件過程模型：是一種開發策略，該策略針對軟件工程的各個階段提供了一套范形，使工程的進展達到預期的目的。

2.軟件過程就是軟件開發過程么？為什么？

不是，軟件過程是指軟件整個生命周期，從需求獲取、需求分析、設計、實現、測試、發布和維護一個過程模型。一個軟件過程定義了軟件開發中采用的方法，但軟件過程還包含該過程中應用的技術——技術方法和自動化工具。

3.請選擇兩個常見的軟件過程模型，談談你對他們的理解？并進行比較

瀑布模型：就像是瀑布從上往下流一樣，必須等前一階段的工作完成之后，才能開始后一階段的工作。并且每一個階段的輸出文檔就是就是后一階段的輸入文檔，因此，只有前一階段的輸出文檔正確后，后一階段的工作才能得到正確結果。同時，早期犯下錯誤后改正錯誤的代價更低，越到后期，改正錯誤的代價就越高。適用于需求確定，無大的需求變更，工作能夠采用線性的方式完成的軟件。

增量模型：融合了瀑布模型的基本成分和原型實現的迭代特征，軟件開發過程中，將軟件系統按功能分解為許多增減構件，并以構件為單位逐個地完成，并都被集成到系統之中。客戶對每個增量的使用和評估都作為下一個增量發布的新特性和功能。適用于既定的商業要求期限之前不可能找到足夠的開發人員的情況。

瀑布模型的優點：

• 有利于大型軟件開發過程中人員的組織、管理。
• 有利于軟件開發方法和工具的研究，從而提高了大型軟件項目開發的質量和效率。

瀑布模型的缺點：

• 開發過程一般不能逆轉，否則代價太大；
• 實際的項目開發很難嚴格按該模型進行；
• 客戶往往很難清楚地給出所有的需求，而該模型卻要求如此。
• 軟件的實際情況必須到項目開發的后期客戶才能看到，這要求客戶有足夠的耐心。

瀑布模型的使用范圍：

• 用戶的需求非常清楚全面，且在開發過程中沒有或很少變化；
• 開發人員對軟件的應用領域很熟悉；
• 用戶的使用環境非常穩定；
• 開發工作對用戶參與的要求很低。

增量模型的優點：

• 采用增量模型的優點是人員分配靈活，剛開始不用投入大量人力資源；
• 如果核心產品很受歡迎，則可增加人力實現下一個增量；
• 可先發布部分功能給客戶，對客戶起到鎮靜劑的作用。

增量模型的缺點：

• 并行開發構件有可能遇到不能集成的風險，軟件必須具備開放式的體系結構；
• 增量模型的靈活性可以使其適應這種變化的能力大大優于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而是軟件過程的控制失去整體性。

增量模型的使用范圍：

• 進行已有產品升級或新版本開發，增量模型是非常適合的；
• 對完成期限嚴格要求的產品，可以使用增量模型；
• 對所開發的領域比較熟悉而且已有原型系統，增量模型也是非常適合的。

4.根據你當前所在的團隊項目，你更傾向于選擇哪一種軟件過程模型？為什么？

瀑布模型，項目規模比較小，項目的需求也比較清晰，開發過程對用戶的依賴較小。

第五章 軟件需求分析

1.需求分析的目的是什么，有什么作用？

需求分析的目的：是要求開發人員準確地理解用戶需要什么，進行細致地調查分析，將用戶的需陳述轉化為完整的需求定義，再由需求定義轉化為相應的軟件需求規格說明。

需求分析的作用：通過需求分析，可以使開發人員深入細致地調研和分析項目，準確理解用戶對項目的功能、性能、可靠性等具體要求，從而確定軟件開發的方向而少走彎路。

2.需求分析有哪些分類，請舉例說明？

• 業務需求：業務需求就是系統目標，它必須是業務導向、可度量、合理、可行的。業務需求描述了組織為什么要開發一個系統，即組織希望達到的一個什么樣的目標。通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部分或產品策劃部門，比如房地產市場的開發商。
• 用戶需求：用戶要求系統必須實現的功能，從產品使用者的用戶角度考慮，比如買房的人。
• 功能需求：開發人員必須在產品中實現的軟件功能，用戶使用這些功能來滿足業務需求。比如房子
  
• 非功能需求：非功能需求主要與系統的總體特征有關，是一些限制性要求，是對實際使用環境所做的要求。如一個網站完全加載出來的時間必須在1s中之內。

3.需求分析過程有哪些步驟？

溝通：業務領域的共利益者（如業務管理人員、市場營銷人員、產品管理人員）定義業務用例、確定市場的范圍、初略的進行可行性分析、確定項目范圍的工作說明。

導出需求：該步驟中應該分析和理解三個問題——范圍問題、理解問題、易變問題。可采用會談、調查、場景分析、快速原型法等多種方法來導出目標系統的高層邏輯模型。

與客戶和用戶協商：通過協商來調節沖突和問題，對需求進行排序，識別和分析每項需求相關的風險，開發工作量、成本和交付時間。

可行性研究：輸入一個框架描述和高層邏輯模型，輸出一份可行性研究報告。

精化需求：開發一個精確地技術模型，用以說明軟件的功能、特征和約束，該模型定義了問題的信息域，功能域和行為域。可以使用結構化分析方法和面型對象分析方法來構建模型。

編寫軟件需求規格說明：軟件需求規格是需求分析任務的最終產品，是客戶、管理者、分析工程師、測試工程師、維護工程師交流的標準和依據。軟件需求規格說明描述了系統的數據、功能、行為、性能需求、設計約束、驗收標準、以及其他需求相關的信息。

驗證需求：驗證需求對需求分檔和制品進行質量評估，確保需求說明準確、完整。包括正確性、一致性、完整性、可行性、必要性、可檢驗性、需求的可跟蹤性，最后確認簽字。

管理需求：需求一般會發生變更，可以通過建立需求跟蹤矩陣來保存需求和后繼工作成果的對應關系，建立和維護“需求-設計-編程-測試”之間的一致性，確保所有的工作成果符合用戶需求。

4.需求獲取方法有哪些？

• 會談技術：分為非正式會談和正式會談，提出一些可自由回答的問題和事先準備好的議題，從不同的角度，與不同的角色進行會談，以了解不同用戶的需求。
• 調查技術：通過非正式會談、調查問卷等調查方式來獲取用戶需求，注意檢驗調查結果的可信度。
• 場景分析技術：分析用戶和軟件系統交互的過程，捕獲這些場景的細節。
• 快速原型法：快速建立軟件原型的核心是用交互的、快速建立起來的原型取代了形式的、僵硬的（不易修改的）規格說明，用戶通過在計算機上實際運行和試用原型而向開發者提供真實的反饋意見。

第六章 結構化分析

1.結構化分析的特點是什么？

• 采用自頂向下、逐層分解的方法求解復雜問題。
• 方法簡單、清晰，易于學習掌握和使用。
• 結構化分析的實施步驟是先分析當前環境中已存在的人工系統，在此基礎上再構思即將開發的目標系統，這符合人們認識世界改造世界的一般規律，從而大大降低了問題的復雜程度。
• 結構化分析采用了圖形描述方式，用數據流圖為即將開發的系統描述了一個可見的模型，也為相同的審查和評價提供了有力的條件，才上到下把大問題分解成若干個小問題，然后分別解決問題。

2.數據流圖的建模元素有哪些？如何構建數據流圖？有哪些注意事項？

2.1 數據流圖有以下幾種主要元素：

• 數據流：數據流是數據在系統內傳播的路徑，因此由一組成分固定的數據組成。如訂票單由旅客姓名、年齡、單位、身份證號、日期、目的地等數據項組成。由于數據流是流動中的數據，所以必須有流向，除了與數據存儲之間的數據流不用命名外，數據流應該用名詞或名詞短語命名。
• 數據源或宿（“宿”表示數據的終點）：代表系統之外的實體，可以是人、物或其他軟件系統。
• 對數據的加工（處理）：加工是對數據進行處理的單元，它接收一定的數據輸入，對其進行處理，并產生輸出。
• 數據存儲：表示信息的靜態存儲，可以代表文件、文件的一部分、數據庫的元素等。

2.2 構建數據流圖的步驟

先確定系統的輸入輸出，構建頂層DFD。

對頂層DFD細化，構建0層DFD。

對0層DFD的每個加工進行細化，分別構建1層DFD，依次類推，逐層精化，紙質構建出底層圖。

2.3 注意事項

注意數據流圖中每個元素命名合理。

數據流圖需要反映系統“做什么”而不是“如何做”。

每個加工至少有一個輸入數據流和一個輸出數據流，反映出此加工數據的來源于加工的結果。

按層給加工編號。

保持父圖和子圖的平衡

3.數據字典有哪些要素（條目）定義？

• 數據流條目：通常列出該數據流的各組成數據項
• 數據項條目：數據流的組成成員是數據項，數據項條目是不可再分解的數據單位。
• 數據存儲條目：與數據流條目一樣。對存儲數據的定義用數據存儲條目。
• 加工處理條目：通常采用輸入——處理——輸出（IPO，Input-Progress-Output）視圖描述。

第七章 軟件設計

1.軟件設計的目標及主要任務有哪些？

軟件設計的目標：軟件系統設計是把軟件需求“變換”為用于構造軟件的藍圖，“輸入”是需求分析各種模型元素，“輸出”是軟件設計模型和表示，軟件設計階段的基本目標是構造系統“怎么做”的模型描述 ，“設計先于編碼”，這是軟件工程“推遲實現”的基本原則。

主要任務：主要有以下幾類設計活動

• 總體設計：也稱為概要設計，軟件結構設計，或高層設計。
• 體系結構設計：定義軟件模塊（構件）及模塊之間的關系。
• 接口設計：包括用戶接口（界面），外部接口，內部接口。
• 數據設計：軟件涉及的數據結構，文件系統結構，數據庫的表結構等。
• 軟件詳細設計：也稱為模塊過程設計，或低層設計。
• 模塊內部細節設計：包括模塊所需的算法和數據結構等。

2.什么是模塊（構件）化設計思想

• 模塊是一個獨立命名的，擁有明確定義的輸入、輸出和特性的程序實體。
• 把一個大型軟件系統的全部功能，按照一定的原則合理地劃分為若干個模塊，每個模塊完成一個特定的子功能，所有的這些模塊以某種結構形式組成一個整體，這就是軟件的模塊化設計。
• 軟件模塊化設計可以簡化軟件的設計和實現，提高軟件的可理解性和可測試性，并使軟件更容易得到維護。
• 分解、抽象、逐步求精、信息隱蔽和模塊獨立性，是軟件模塊化設計的指導思想。

3.模塊獨立性的兩個度量標準是什么？

模塊自身的內聚：也稱為模塊內聯系，指一個模塊內部元素彼此結合的緊密程度。

模塊之間的耦合：也稱為塊間聯系。

模塊獨立性愈高，則塊內聯系越強，塊間聯系越弱，即高內聚，低耦合。

4.內聚和耦合的含義是什么？各有哪些種類？請舉例說明每一類型。

內聚的含義：內聚性是從功能的角度對模塊內部聚合能力的量度。高內聚是模塊獨立性追求的目標。

內聚的種類（從上到下內聚性依次減弱）：

1.功能性內聚：模塊各個成分結合在一起，完成一個特定的功能，功能性模塊具有內聚性最強，與其它模塊聯系少的特點。例如：解析XML文檔模塊（解析XML元素，解析XML屬性，解析XML注釋等）。

2.順序性內聚：模塊內的各個任務是順序執行的。通常，上一個任務的輸出是下一個任務的輸入。例如：規則引擎：一個任務讀配置，輸出執行計劃，另一個任務以執行計劃為輸入，執行該計劃。

3.通信性內聚：模塊內部的各個任務靠公用數據聯系在一起，即都使用同一個輸入數據，或者產生同一個輸出數據。例如：學生管理系統的數據庫CRUD操作，都對學生信息進行增刪改查操作。

4.過程性內聚：模塊內個各個任務必須按照某一特定次序執行。例如：讀/寫文件操作：判斷文件是否存在，判斷文件是否有相應權限，打開文件，讀，寫文件。

5.時間性內聚：模塊內的各個子任務由相同的執行時間聯系在一起。例如：初始化模塊，異常處理模塊，某個異常處理模塊封裝了“釋放資源”，“記錄日志”，“通知用戶”等幾個任務。

6.邏輯性內聚：模塊通常由若干個邏輯功能相似的任務組成，通過模塊外引入的一個開關量選擇其一執行。這種內聚增大了模塊間的耦合。例如：一個輸出設備模塊將打印機類和顯示器類封裝到同一個包里，該包即輸出設備模塊。打印機類和顯示器類雖然都具有輸出功能，但是具有不同的職責。

7.偶然性內聚：模塊內的各個任務在功能上沒有實質性聯系，純屬“偶然”因素組合子塊內各個互不相關的任務。例如：一個處理正方形的模塊有兩個功能，計算面積，畫出這個正方形。

內聚性總結：在軟件設計中，應力求做到高內聚、盡量少用中內聚，不用低內聚。一般來說，在系統較高層次上的模塊功能復雜，內聚要低一些；而較低層次上的模塊內聚程度較高，達到功能內聚的可能性比較大。

耦合的含義：耦合性是對一個軟件結構內不同模塊之間的互連程度的度量。耦合性的強弱取決于模塊間接口的復雜程度，以及通過接口的數據類型和數目。弱耦合是模塊獨立性追求的目標。

耦合的種類（從上到下耦合性依次增強）：

1.非直接耦合：同級模塊相互之間沒有信息傳遞，即沒有耦合。非常底層的模塊，自給自足，可以無耦合。較高層的模塊，通常需要重用其他模塊的功能，產生耦合。

2.數據耦合：調用下屬模塊時，如果交換的都是簡單變量，便構成數據耦合。

3.特征耦合（數據結構耦合）：調用下屬模塊時，如果交換的是數據結構，便構成數據特性耦合。由于傳遞的是數據結構，不僅數據量增加，而且會使模塊的相關性增加。

4.控制耦合：模塊間傳遞的信息不是一般的數據，而是作為控制信息的開關值或標志量。

5.外部耦合：若允許一組模塊訪問同一個全局變量，可稱他們為外部耦合。

6.公共耦合：若允許一組模塊訪問同一個全局性的數據結構，則稱他們為公共耦合。全局性的數據結構可以是共享的通信區，公共的內存區域，任何存儲介質文件，物理設備等。

7.內容耦合：若一個模塊可以直接訪問為另一個模塊中的內部數據，或者一個模塊直接轉到另一個模塊的內部，或者一個模塊有多個入口，則稱為內容耦合。

耦合性總結：耦合是影響模塊結構和軟件復雜程度的一個重要因素，應該遵循如下的設計原則：盡量使用數據耦合，少用控制耦合，限制公共耦合，完全不用內容耦合。

5.為什么要高內聚低耦合？高內聚低耦合是否意味著內聚越高越好，耦合越低越好？

高內聚，低耦合的好處體現在系統持續發展的過程中，高內聚，低耦合的系統具有更好的重用性，維護性，擴展性，可以更高效的完成系統的維護開發，持續的支持業務的發展，而不會成為業務發展的障礙。

1.并不是內聚越高越好，耦合越低越好，真正好的設計是在高內聚和低耦合間進行平衡，也就是說高內聚和低耦合是沖突的。

2.最強的內聚莫過于一個類只寫一個函數，這樣內聚性絕對是最高的。但這會帶來一個明顯的問題：類的數量急劇增多，這樣就導致了其它類的耦合特別多，于是整個設計就變成了“高內聚高耦合”了。由于高耦合，整個系統變動同樣非常頻繁。

3.對于耦合來說，最弱的耦合是一個類將所有的函數都包含了，這樣類完全不依賴其它類，耦合性是最低的。但這樣會帶來一個明顯的問題：內聚性很低，于是整個設計就變成了“低耦合低內聚”了。由于低內聚，整個類的變動同樣非常頻繁。

4.真正做到高內聚、低耦合是很難的，很多時候未必一定要這樣，更多的時候“最適合”的才是最好的，不過、審時度勢、融會貫通、人盡其才、物盡其用，才是設計的王道。

第八章 結構化設計

1. 軟件結構圖的形態特征有哪些指標？各有什么含義？

深度：指結構圖控制的層次，即模塊的層數。

寬度：指一層中最大的模塊個數。

扇出：指一個模塊直接下屬模塊的個數。

扇入：指一個模塊直接上屬模塊的個數。

2. 軟件結構有哪些優化原則？

模塊獨立性準則：劃分模塊時，盡量做到高內聚低耦合，保持模塊相對獨立性，以此原則優化初始的軟件結構。

軟件結構的形態特征準則：軟件結構的深度、寬度、扇入數和扇出數都要適當。

模塊的大小準則：按模塊的獨立性，即根據模塊的功能來決定模塊的大小，過大的模塊應進行分解，過小的模塊應適當合并，但不應降低模塊的獨立性。

控制域和作用域之間的準則：一個模塊的作用域應在其控制范圍之內，且條件判定所在的模塊應與受其影響的模塊在層次上盡量靠近。

模塊的接口準則：模塊的接口要簡單、清晰、力求降低模塊接口的復雜程度，設計單入口，單出口的模塊。

3. 數據流模型的類型有哪些？各有什么特點？

變換流：整個數據流體現了以輸入、變換、輸出的順序方式，沿一定路徑前行的特征，這就是變換型數據流，簡稱變換流。

事務流：當數據經過一個具有“事務中心”特征的數據處理時，它可以根據事務類型從多條路徑的數據流中選擇一條活動通路，這種根據條件選擇處理不同事務的數據流，就是事務型數據流。

混合流：將事務流和變換流組合出現，就是混合型數據流。

4. 簡述面向數據流的變換以及事務設計方法的步驟。

變換設計方法

確定數據流圖中的變換中心，邏輯輸入和邏輯輸出。

設計軟件結構的頂層和第一層。

設計中、下層模塊。

設計的優化。

事務設計方法

確定數據流圖中事務中心和加工路徑。

設計軟件結構的頂層和第一層——事務結構。

進行事務結構中、下層模塊的設計、優化等工作。

5. 結構化詳細設計工具有哪幾種？各有什么特點？

圖形工具：把過程的細節表示成一個圖的組成部分，在這個圖上，邏輯構造用具體的圖形來表示。

流程圖、盒圖、PAD圖

列表工具：用一個表來表示過程的細節，這個表列出了各種操作及其相應的條件，即描述了輸入、處理和輸出信息。

判定表、判定樹

語言工具：用偽代碼來表示過程的細節，這種偽代碼很接近于編程語言。

PDL語言

第十一章 面向對象設計

1. 面向對象的分析與設計方法與結構化的分析設計方法有什么不同？

結構化方法首先關心的是功能，強調以模塊（即過程）為核心，采用模塊化、自頂向下、逐步求精設計過程，系統是事項模塊功能的函數和過程的集合，結構清晰，可讀性好，是條軟件開發質量的一種有效手段。結構化設計從系統的功能入手，按照工程標準和嚴格規范將系統分解為若干功能模塊。然而，由于用戶的需求和軟、硬件技術的不斷發展變化，作為系統基本成分的功能模塊很容易受到影響，局部修改甚至會引起系統的根本性變化。開發過程前期入手快而后期頻繁改動的現象比較常見。

面向對象方法則從所處理的數據入手，以數據為中心來描述系統，數據相對于功能而言，具有更強的穩定性，這樣設計出的系統模型往往能較好地映射問題域模型。對象、類、繼承性、多態性、動態定連概念和設施的引入使用，顯然另面向對象的設計方法具有一定的優勢，能為生產可重用的軟件構建和解決軟件的復雜性問題提供一條有效的途徑。面向對象的設計過程就是指通過建立一些類以及它們之間的關系來解決實際問題，這就需要對問題域中的對象作整體分析，類和類間關系的設計要求較高，否則設計出的并不是真正意義上的面向對象的軟件系統，而只是一些類的堆砌而已，不能體現出面向對象設計方法的優勢之處。

同時，系統的分析設計是一個注重實踐的領域，不僅僅依賴于一整套核心的概念與原理，要想設計出一個成功的系統來，還需要相應的語言、工具和技術的有力支持。在這方面，經過多年的實踐和發展，適應結構化方法的技術和開發環境已經相當穩定成熟，而面向對象方法而言，雖然近時期涌現了大量的新工具和新技術，但仍有待于不斷的完善和改進，特別是面向對象的數據庫技術。

2. 面向對象的分析與設計之間有什么樣的聯系？

面向對象分析的輸入是用戶的功能需求，輸出是簡單的、理性化的分析模型，此階段的工作更多側重于如何了理解軟件的功能需求。

面向對象設計的輸入是面向對象分析的結果，輸出最終的細化后的設計模型，此階段的工作更多側重于如何得到一個合適的、完整的解決方案。

主要區別：

在側重點上，面向對象分析側重于理解問題，描述軟件要做什么，而面向對象設計側重于理解解決方案，描述軟件要如何做。

面向對象分析一般只考慮架構設計，不關心技術和實現層面的細節，而面向對象設計需要得到更具體、更詳盡、更接近于真實的代碼的設計方案。

在設計結果的描述方式上，面向對象分析階段側重于描述對象的行為，而面向對象設計側重于描述對象的屬性和方法。

面向對象分析只關注功能性需求，而面向對象設計既關注功能型需求，也關注非功能性需求。

面向對象分析產生的系統模型通常規模較小，而面向對象設計產生的系統模型規模較大，內容也比較詳盡、完整。

參考書籍：《軟件工程方法與實踐》 竇萬峰

總結

以上是生活随笔為你收集整理的《软件工程》 课后思考题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。