一、名詞解釋
- DFD 數據流圖Data Flow Diagram
- PDL 過程設計語言 Process Design Language
- PAD 問題分析圖 Problem Analysis Diagram
- MTTF 平均無故障時間 Mean Time To Failure
- MTTR 平均維修時間 Mean Time To Repair
- MTBF 平均故障間隔時間 Mean Time Between Failure
- OOA 面向對象分析 Object Oriented Analysis
- OOD 面向對象設計 Object Oriented Design
- OOP 面相對象的編程實現 Object Oriented Programming
- FP 功能點 Funciton Point
- UFP 未調整的功能點 unadjusted function points
- TCF 技術複雜性因子technical complexity factor
- COCOMO 構造性成本模型 constructive cost model
- EET 最早時刻
- LET 最遲時刻
- SQA 軟件質量保證 software quality assurance
- CMM 能力成熟度模型 Capability Maturity Model
- JSP Jackson結構化程序設計方法 Jackson Structured Programming
- Jackson方法 一種面向數據結構的軟件設計方法
- Warnier 方法 一種面向數據結構的軟件設計方法
- McCabe方法 根據程序控制流的複雜程度定量度量程序的複雜程度
- Halstead方法 根據程序中運算符和操作數的總數來度量程序的複雜程度
- Alpha測試 由用戶在開發者的場所進行，並且在開發者對用戶的指導下進行測試
- Beta測試 有軟件的最終用戶在一個或多個客戶場所進行
- BRO測試 一種條件測試（Branch and Relational Operator）
- SC 結構圖 Structure Chart
- RUP Rational統一過程
- XP 極限編程 eEtreme Programming
- IPO圖 輸入、處理、輸出圖
- HIPO圖 IPO圖（輸入、處理、輸出圖）+H圖(層次圖)
- DSL 需求陳述語言
- PSL 問題陳述語言
- PSA 問題陳述分析系統
- CADSAT 計算機輔助設計和規格說明分析工具
- Petri網：用於確定系統中隱含的定時問題的一種有效技術
- SA 結構化分析
- SD 結構化設計
- SP 結構化編程
- DFD 數據流圖
- DD 數據字典
- CASE 計算機輔助軟件環境 Computer Aided Software Environment
二、簡答與論述
(一)、歷年考題整理（標章節號的來源於課後題）
-
簡答
【D1章】1、爲什麼會出現軟件危機？2018（5分）
(1) 來自軟件自身的特點：是邏輯部件，缺乏可見性；規模龐大、複雜，修改、維護困難。
(2) 軟件開發與維護的方法不當：忽視需求分析；認爲軟件開發等於程序編寫；輕視軟件維護。
(3) 供求矛盾將是一個永恆的主題：面對日益增長的軟件需求，人們顯得力不從心。
【D2章】2、在軟件開發的早期階段爲什麼要進行可行性研究？
開發一個軟件時，需要判斷原定的系統模型和目標是否現實，系統完成後所能帶來的效益是否大到值得投資開發這個系統的程度，如果做不到這些，那麼花費在這些工程上的任何時間、人力、軟硬件資源和經費，都是無謂的浪費。可行性研究的實質是要進行一次大大壓縮簡化了的系統分析和設計過程，就是在較高層次上以較抽象的方式進行的系統分析和設計的過程。可行性研究的目的就是用最小的代價在儘可能短的時間內確定問題是否能夠解決。
【D3章】3、怎樣與用戶有效地溝通以獲取用戶的真實需求？
與用戶溝通獲取需求的方法：
訪談；面向數據流自頂向下求精；簡易的應用規格說明技術；快速建立軟件原型
【D8章】4、軟件的可維護性與哪些因素有關？
可理解性、可預測性、可修改性、可移植性、可重用性
【D1章】5、什麼是軟件過程？它與軟件工程方法學有何關係？2017 （5分）
軟件過程：是爲了開發出高質量的軟件產品所需完成的一系列任務的框架，它規定了完成各項任務的工作步驟。
軟件工程方法學：通常把在軟件生命週期全過程中使用的一整套技術方法的集合稱爲方法學，也稱範型。
軟件過程是軟件工程方法學的3個重要組成部分之一。
軟件工程方法學包含三個要素：方法、工具和過程。
6、從僞碼轉變爲程序流程圖或從程序流程圖轉變爲僞碼是否是唯一的？請說明理由。
僞碼準確地描述了程序的控制流程。由於僞碼在描述程序的控制流程時是無二義性的，因此，由僞碼變成的程序流程圖是唯一的。
但是，同樣的控制流程可以用不同的僞碼來描述，因此，由程序流程圖轉變成的僞碼不是唯一的。
7、應該依據什麼準則來評價狀態圖？
狀態圖應該描繪所有可能的狀態轉換。圖中每條弧都要有一個引起狀態轉換的事件。從開始結點（初態）到每個結點（中間狀態），以及從每個結點到最終結點（終態），都必須有一條路徑。
【補充】應該根據什麼準則來評價用例圖？
用例圖從用戶的觀點來描述系統的功能，因此，必須包含用戶關心的所有關鍵功能。
【補充】應該根據什麼準則來評價腳本？
腳本必須從用戶的觀點來描述每個重要的功能序列，因此，腳本應該能夠說明系統的一類重要功能或具體的使用方法。
【第5版】8、爲什麼說參數化類有助於提高可重用性？
在實際的應用程序中，有一些軟件元素，從邏輯功能看，彼此是相同的，所不同的主要是處理的對象類型不同。參數化類就是使用一個或者多個類型去參數化一個類的機制，有了這種機制，程序員可以先定義一個參數化的類模塊，再使用時把數據類型作爲參數傳遞進來，在不同的應用程序中重複使用。
【D1章】9、軟件生命週期中每個階段的提交物是什麼？2016 A（6分）
（1）軟件定義階段：
- 問題定義：項目開發計劃
- 可行性研究：可行性分析報告
- 需求分析：軟件需求規格說明書
（2）軟件開發階段： - 總體設計：總體設計說明書
- 詳細設計：詳細設計說明書
- 編碼和單元測試：源程序清單
- 綜合測試：軟件測試文檔和測試用例
（3）軟件維護階段： - 軟件維護：軟件維護流程圖和維護報告
10、常用的黑盒測試方法有哪些？
等價劃分，邊界值分析，錯誤推測
【補充】常用的白盒測試方法有哪些？
邏輯覆蓋（語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、點覆蓋、邊覆蓋、路徑覆蓋），
控制結構測試（基本路徑測試、條件測試、循環測試）
11、面向對象程序設計思想主要包括哪些特性？以及這些特性的具體含義是什麼？
- 抽象：解釋類與對象之間關係的詞。類與對象之間的關係就是抽象的關係。類是對象的抽象，而對象則是類得特例，即類的具體表現形式。
- 封裝：一是將有關數據和操作代碼封裝在對象當中，形成一個基本單位，各個對象之間相對獨立互不干擾。二是將對象中某些屬性和操作私有化，已達到數據和操作信息隱蔽，有利於數據安全，防止無關人員修改。
- 繼承：子類具有父類的各種屬性和方法。
- 多態：代碼中可以出現的重名現象，它是指在一個類中定義的屬性和方法被其他類繼承後，它們可以具有不同的意義和行爲，使得同一個屬性和方法在不同類中具有不同的意義。
12、請簡述耦合性的含義？
一個軟件結構內不同模塊之間互聯程度的度量。
13、軟件測試過程一般可劃分爲哪幾個主要階段？
- 模塊測試（單元測試），
- 子系統測試，
- 系統測試，
- 驗收測試（確認測試），
- 平行運行
【D1章】14、軟件生存週期可以分爲幾個階段？2016 B 2015（6分）
軟件定義、軟件開發、軟件維護
- 軟件定義階段：問題定義，可行性研究，需求分析
- 軟件開發階段：總體設計，詳細設計（前兩個階段又稱系統設計），編碼和單元測試，綜合測試（後兩個階段又稱系統實現）
軟件維護階段：軟件維護
15、什麼是黑盒測試法？
功能測試，如果已經知道了產品應該具有的功能，可以通過測試來檢測每個功能是否都能正常使用
【補充】什麼是白盒測試法？
結構測試，如果知道產品的內部工作工程，可以通過測試來檢驗產品內部動作是否按照規格說明書的規定正常進行。
16、請簡述需求分析的含義？
準確地回答系統做什麼這個問題，對目標系統提出完整，準確，清晰，具體的要求。
17、請簡述內聚性的含義？
一個模塊內各個元素彼此結合的緊密程度。
【D2章】18、可行性研究報告的主要內容有哪些？
(1) 系統概述:說明開發的系統名稱,提出單位 和開發單位。
(2) 可行性研究的前提:系統目標;要求;約束和限制;可行性研究的基本準則等。
(3) 對現有系統的分析:處理流程，圖示說明現有系統的處理流程和數據流程;現有系統存在的問題。
(4) 系統需求:主要功能;主要性能及其要求;操作要求;信息要求;限制性要求。
(5) 建議系統:系統目標;處理流程;系統結構,功能,性能;系統技術可行性;投資和效益分析;操作可行性;法律可行性。
(6) 其它可選方案:與國內外同類型方案的比較;提出一兩個可行性方案供論證和探討。
(7) 制定下一階段的預算。
(8) 結論性意見:由用戶方、設計方和投資方共同簽署意見。
-
論述
【D1章】1、什麼是軟件工程？它的目標和內容是什麼？2018（10分）
軟件工程就是用科學的知識和技術原理來定義，開發，維護軟件的一門學科。軟件工程目標：付出較低開發成本；達到要求的功能；取得較好的性能；開發的軟件易於移植；只需較低的維護費用；能按時完成開發任務，及時交付使用；開發的軟件可靠性高。軟件工程內容：包括開發技術和開發管理兩個方面。
【D12章】2、選擇面向對象程序設計語言時主要應該考慮哪些因素？
將來能否占主導地位；可重用性；類庫、開發環境；其他因素。
（項目的應用領域、軟件開發的方法、軟件執行的環境、算法和數據結構的複雜性以及軟件開發人員的知識等。）
【第5版】3、請說明多態重用與繼承重用的關係。2017 （10分）
多態重用實際是一種特殊的繼承重用，是充分利用多態性機制支持的繼承重用。一般來說，使用多態重用方式重用已有的類構件時，在子類中需要重新定義的操作比較少，因此，多態重用方式比繼承重用方式成本低。
【D13章】4、什麼是軟件質量？試敘述它與軟件可靠性的關係。
軟件質量是軟件與明確地敘述的功能和性能需求、文檔中明確描述的開發標準以及任何專業開發的軟件產品都應該具有的隱含特徵一致的程度。
5、談談Overload和Override的區別。2016 A（10分）
目的：overload用於增加程序的可讀性。 override用於提供其超級類已經提供的方法的特定實現。
範圍：overload 在相同的類範圍內內執行。 override發生在兩類具有繼承（繼承）的關係。
參數 ：overload參數必須不同。 override參數必須相同。
多態性：overload 靜態多態,調用的函數在編譯時被選中。 override 是運行時多態性的
override（重寫，覆蓋） 1、方法名、參數、返回值相同。 2、子類方法不能縮小父類方法的訪問權限。 3、子類方法不能拋出比父類方法更多的異常(但子類方法可以不拋出異常)。 4、存在於父類和子類之間。 5、方法被定義爲final不能被重寫。 overload（重載，過載） 1、參數類型、個數、順序至少有一個不相同。 2、不能重載只有返回值不同的方法名。 3、存在於父類和子類、同類中。
6、軟件開發設計模式都有哪些？結合自身情況，談談你對設計模式的理解？
創建型模式：單例模式、抽象工廠模式、建造者模式、工廠模式、原型模式。結構型模式：適配器模式、橋接模式、裝飾模式、組合模式、外觀模式、享元模式、代理模式。
行爲型模式：模版方法模式、命令模式、迭代器模式、觀察者模式、中介者模式、備忘錄模式、解釋器模式、狀態模式、策略模式、職責鏈模式、訪問者模式。
設計模式是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結
【D1章】7、什麼是軟件危機？軟件危機的表現是什麼？其產生的原因是什麼？ 2015
軟件危機的定義：
軟件危機是指在計算機軟件開發、使用與維護過程中遇到的一系列嚴重問題和難題。它包括兩方面：如何開發軟件，已滿足對軟件日益增長的需求；如何維護數量不斷增長的已有軟件。軟件危機的典型表現：
(1) 對軟件開發成本和進度的估計常常很不準確。
(2) 用戶對已完成的軟件不滿意的現象時有發生。
(3) 軟件產品的質量往往是靠不住的。
(4) 軟件常常是不可維護的。
(5) 軟件通常沒有適當的文檔資料。
(6) 軟件成本、軟件維護費在計算機系統總成本中所佔比例逐年上升。
(7) 開發生產率提高的速度遠跟不上計算機應用普及的需求。軟件危機出現的原因：
(1) 來自軟件自身的特點：是邏輯部件，缺乏可見性；規模龐大、複雜，修改、維護困難。
(2) 軟件開發與維護的方法不當：忽視需求分析；認爲軟件開發等於程序編寫；輕視軟件維護。
(3) 供求矛盾將是一個永恆的主題：面對日益增長的軟件需求，人們顯得力不從心。補充：如何克服軟件危機
(1) 充分吸收和借鑑人類長期以來從事各種工程項目中積累的行之有效的有效原理、概念、技術與方法， 特別是吸取幾十年來人類從事計算機硬件研究和開發的經驗教訓。在開發軟件的過程中努力作到良好的組 織，嚴格的管理，相互友好的協作。
(2) 推廣在實踐中總結出來的開發軟件的成功的技術和方法，並研究更好、更有效的技術和方法，儘快克服在計算機系統早期發展階段形成的一些錯誤概念和作法。
(3) 根據不同的應用領域，開發更好的軟件工具並使用這些工具。將軟件開發各個階段使用的軟件工具集合成一個 整體，形成一個很好的軟件開發支環環境。總之爲了解決軟件危機，既要有技術措施(方法和工具)，又要有必要的組織管理措施。
8、談談您對軟件設計過程中應遵循的高內聚、低耦合原則的理解？
高內聚就是提高模快內部的關聯程度,低耦合當然就是降低模快之間的關聯程度
耦合性比較高的話，模塊代碼不易分離，是不好的編程模式
內聚是越高越好，內聚個人認爲是隻是實現一個功能，不是很多的功能。
(二)、課後題+書中重點（按章節整理）
-
第一章軟件工程學概述
1、什麼是軟件工程？它有哪些本質特徵？怎樣用軟件工程消除軟件危機？
軟件工程是指導計算機軟件開發和維護的一門工程學科。
具體的定義：1993年IEEE的定義：軟件工程是：① 把系統的、規範的、可度量的途徑應用於軟件開發、運行和維護過程，也就是把工程應用於軟件；② 研究①中提到的途徑。
軟件工程的本質特徵：
(1) 軟件工程關注於大型程序的構造
(2) 軟件工程的中心課題是分解問題，控制複雜性
(3) 軟件是經常變化的，開發過程中必須考慮軟件將來可能的變化
(4) 開發軟件的效率非常重要
(5) 和諧地合作是開發軟件的關鍵
(6) 軟件必須有效地支持它的用戶
(7) 在軟件工程領域中是由具有一種文化背景的人替具有另一種文化背景的人創造產品消除軟件危機的途徑：
(1) 對計算機軟件有一個正確的認識(軟件≠程序）
(2) 必須充分認識到軟件開發不是某種個體勞動的神祕技巧，而應該是一種組織良好、管理嚴密、各類人員協同配合、共同完成的工程項目
(3) 推廣使用在實踐中總結出來的開發軟件的成功技術和方法
(4) 開發和使用更好的軟件工具
2、簡述結構化範型和麪向對象範型的要點，並分析他們的優缺點。
- 傳統方法學：也稱爲生命週期方法學或結構化範型。
優點：把軟件生命週期劃分成基幹個階段，每個階段的任務相對獨立，而且比較簡單，便於不同人員分工協作，從而降低了整個軟件開發過程的困難程度。
缺點：當軟件規模龐大時，或者對軟件的需求是模糊的或會承受時 間而變化的時候，開發出的軟件往往不成功；而且維護起來仍然很困難。
- 面向對象方法學：
優點：降低了軟件產品的複雜性；提高了軟件的可理解性；簡化了軟件的開發和維護工作；促進了軟件重用。
3、什麼是軟件生命週期模型？試比較瀑布模型、快速原型模型、增量模型和螺旋模型的優缺點，說明每種模型的使用範圍。
軟件生命週期模型是跨越整個生存期的系統開發、運作和維護所實施的全部過程、活動和任務的結構框架。
- 瀑布模型
優點：
它提供了一個模板，這個模板使得分析、設計、編碼、測試和支持的方法可以在該模板下有一個共同的指導。雖然有不少缺陷但比在軟件開發中隨意的狀態要好得多。
缺點：
(1) 實際的項目大部分情況難以按照該模型給出的順序進行，而且這種模型的迭代是間接的，這很容易由微小的變化而造成大的混亂。
(2) 經常情況下客戶難以表達真正的需求，而這種模型卻要求如此，這種模型是不歡迎具有二義性問題存在的。
(3) 客戶要等到開發週期的晚期才能看到程序運行的測試版本，而在這時發現大的錯誤時，可能引起客戶的驚慌，而後果也可能是災難性的。
- 快速原型模型
優點：使用戶能夠感受到實際的系統，使開發者能夠快速地構造出系統的框架。
缺點：產品的先天性不足，因爲開發者常常需要做實現上的折中，可能採用不合適的操作系統或程序設計語言，以使原型能夠儘快工作。
- 增量模型
優點：
(1) 人員分配靈活，剛開始不用投入大量人力資源，當核心產品很受歡迎時，可增加人力實現下一個增量。
(2) 當配備的人員不能在設定的期限內完成產品時，它提供了一種先推出核心產品的途徑，這樣就可以先發布部分功能給客戶，對客戶起到鎮靜劑的作用。
缺點：
(1) 至始至終開發者和客戶糾纏在一起，直到完全版本出來。
(2) 適合於軟件需求不明確、設計方案有一定風險的軟件項目。
該模型具有一定的市場。
- 螺旋模型
優點：
對於大型系統及軟件的開發，這種模型是一個很好的方法。開發者和客戶能夠較好地對待和理解每一個演化級別上的風險。
缺點：
(1) 需要相當的風險分析評估的專門技術，且成功依賴於這種技術。
(2) 很明顯一個大的沒有被發現的風險問題，將會導致問題的發生，可能導致演化 的方法失去控制。
(3) 這種模型相對比較新，應用不廣泛，其功效需要進一步的驗證。
該模型適合於大型軟件的開發
4、爲什麼說噴泉模型較好的體現了面向對象軟件開發過程無縫和迭代的特性？
因爲使用面向對象方法學開發軟件時，各個階段都使用統一的概念和表示符號，因此，整個開發過程都是吻合一致的，或者說是無縫連接的，這自然就很容易實現各個開發步驟的反覆多次迭代，達到認識的逐步深化，而噴泉模型則很好的體現了面向對象軟件開發過程迭代和無縫的特性。
5、試討論Rational統一過程的優缺點。
優點:提高了團隊生產力，在迭代的開發過程、需求管理、基於組建的體系結構、可視化軟件建模、驗證軟件質量及控制軟件變更等方面、針對所有關鍵的開發活動爲每個開發成員提供了必要的準則、模版和工具指導，並確保全體成員共享相同的知識基礎。它建立了簡潔和清晰的過程結構，爲開發過程提供較大的通用性。
缺點：RUP只是一個開發過程，並沒有涵蓋軟件過程的全部內容，例如它缺少關於軟件運行和支持等方面的內容，此外，他沒有支持多項目的開發結構，這在一定程度上降低了在開發組織內大範圍實現重用的可能性。
6、Rational統一過程主要適用於何種項目？
大型的需求不斷變化的複雜軟件系統項目
7、說明敏捷過程的適用範圍
適用於商業競爭環境下對小型項目提出的有限資源和有限開發時間的約束
8、說明微軟過程的適用範圍
適用於商業環境下具有有限資源和有限開發時間約束的項目的軟件過程模式
9、軟件工程方法學：包含三個要素：方法、工具和過程。
最廣泛的方法學包括傳統方法學和麪向對象方法學。
10、軟件工程支撐環境：如果把各個階段使用的軟件工具有機地集合成一個集體，支持軟件開發的全過程。
11、軟件開發中有哪幾種過程模型?哪些適用於面向對象的軟件開發?
軟件開發中常見的軟件過程模型有瀑布模型、原型模型、螺旋模型、噴泉模型、統一軟件過程等。
其中噴泉模型、統一軟件過程適用於面向對象的軟件開發
12、什麼是軟件生存週期?它有哪幾個活動?
軟件生存週期：一個軟件從提出開發要求開始直到該軟件報廢爲止的整個時期。
包括：可行性分析和項目開發計劃，需求分析，概要設計，詳細設計，編碼，測試，維護。
13、什麼是軟件生存週期模型?有哪些主要模型?
生存週期模型：描述軟件開發過程中各種活動如何執行的模型。對軟件開發提供強有力的支持，爲開發過程中的活動提供統一的政策保證，爲參與開發的人員提供幫助和指導，是軟件生存週期模型化技術的基礎，也是建立軟件開發環境的核心。
主要有：瀑布模型，增量模型，螺旋模型，噴泉模型，基於知識的模型，變換模型。
14、軟件工程三要素之間的關係?
軟件質量是軟件工程的生命線，軟件工程以質量保證爲基礎。
質量管理促進了過程的改進,創造了許多行之有效的軟件開發方法和工具。
軟件工程釆用層次化的方法,每個層次都包括過程、方法、工具三要素。
方法支撐過程和工具，過程和工具又促進方法學的研究。
-
第二章可行性研究
1、應該從哪些方面研究目標系統的可行性？
一般說來，至少應該從以下三個方面研究每種解法的可行性：
a.技術可行性。對要開發項目的功能、 性能和限制條件進行分析， 確定在現有的資源條件下，技術風險有多大，項目是否能實現，這些即爲技術可行性研究的內容。這裏的資源包括已有的或可以搞到的硬件、軟件資源，現有技術人員的技術水平和已有的工作基礎。
b.經濟可行性。進行開發成本的估算以及瞭解取得效益的評估， 確定要開發的項目是否值得投資開發，這些即爲經濟可行性研究的內容對於大多數系統，一般衡量經濟上是否合算，應考慮一個“底線”，經濟可行性研究範圍較廣，包括成本—效益分析， 長期公司經營策略， 開發所需的成本和資源，潛在的市場前景。
c.操作可行性。有時還要研究社會可行性問題，研究要開發的項目是否存在任何侵犯、妨礙等責任問題。社會可行性所涉及的範圍也比較廣，它包括合同、責任、 侵權和其他一些技術人員常常不瞭解的陷阱等。
必要時還應該從法律、社會效益等更廣泛的方面研究每種解法的可行性。
2、可行性研究步驟:(7 步)
- 複查並確定系統規模和目標
- 研究目前正在使用的系統
- 建立新系統的高層邏輯模型
- 導出和評價各種方案
- 推薦可行方案
- 草擬初步的開發計劃
- 編寫可行性研究報告提交審查
3、數據流圖的定義（DFD）：是一種圖形化技術，描繪信息流和數據從輸入移動到輸出過程中所經受的變換。無具體物理部件，只是描繪數據在軟件中流動和被處理的邏輯過程。在設計時值考慮系統必須完成的基本邏輯功能，完全不考慮具體怎麼樣實現。描繪數據流向，而不應該描繪出現啊某個數據流的條件。
4、數據流圖的符號：
- 正方形（或立方體）——數據的源點或終點
- 圓角矩形（或圓形）——交換數據的處理
- 開口矩形（或兩條平行線）——數據存儲
- → ——數據流，即特定數據的流動方向
5、數據字典的作用：在軟件分析和設計的過程中給人提供關於數據的描述信息。
6、數據字典由對4類元素的定義組成：
①數據流；②數據流分量（即數據元素）；③數據存儲；④處理
7、什麼是數據字典?簡述數據字典與數據流圖的關係。
數據字典是關於數據的信息的集合，對數據流程圖中的各個元素做完整的定義與說明，是數據流程圖的補充工具；
數據字典與數據流圖的關係：數據流圖和數據字典共同構成系統的邏輯模型，沒有數據字典數據流圖就不嚴格，然而沒有數據流圖數據字典也難於發揮作用。 數據流圖和對數據流圖中每個元素的精確定義放在一起，才能共同構成系統的規格說明。
8、數據字典包括哪些內容?它的作用是什麼?
數據字典是描述數據流圖中數據的信息的集合。它對數據流圖上每一個成分:數據項、文件(數據結構)、數據流、數據存儲、加工和外部項等給以定義和說明;它主要由數據流描述、加工描述和文件描述三部分組成。對用戶來講,數據字典爲他們提供了數據的明確定義;對系統分析員來講,數據字典幫助他們比較容 易修改已建立的系統邏輯模型。
-
第三章需求分析
1、爲什麼要進行需求分析？通常對軟件系統有哪些要求？
（1）爲了開發出真正滿足用戶需求的軟件產品，首先必須知道用戶的需求。對軟件需求的深入理解是軟件開發工作獲得成功的前提條件，不論我們把設計和編碼工作做得如何出色，不能真正滿足用戶需求的程序只會令用戶失望，給開發者帶來煩惱。
（2）確定對系統的綜合要求：1、功能需求；2、性能需求；3、可靠性和可用性需求；4、出錯處理需求；5、接口需求；6、約束；7、逆向需求；8、將來可以提出的要求，分析系統的數據要求。
2、需求分析的任務：
- 確定隨系統的綜合要求（①功能需求；②性能需求；③可靠性和可用性需求；④出錯處理需求；⑤接口需求；⑥約束；⑦逆向需求；⑧將來可能提出的需求）
- 分析系統的數據要求
- 導出系統的邏輯模型
- 修正系統開發計劃
3、驗證軟件需求的正確性的4個方面：
- 一致性 所有需求必須是一致的，任何一條需求不能和其他需求相互矛盾。
- 完整性 需求必須是完整的，規格說明書應包括用戶需求的每個功能。
- 現實性 用現有的硬件技術或軟件技術基本上能實現的。
- 有效性 需求是正確有效的，確實能解決用戶面對的問題。
4、驗證軟件需求的方法：①驗證需求的一致性；②驗證需求的現實性；三驗證需求的完整性和有效性。
5、需求分析的描述工具有哪些?
有數據流圖、數據字典、判定表、判定樹、結構化自然語言、層次方框圖、Warnier 圖、IPO 圖和需求描述 語言等。
6、軟件需求規格說明書由哪些部分組成?
- 組成包括:
(1)引言:編寫目的、背景說明、術語定義及參考資料等。
(2) 概述主要功能、約束條件或特殊需求。
(3) 數據流圖與數據字典。
(4) 用戶接口、硬件接口及軟件接口。
(5) 性能需求、屬性等。
(6) 其它需求，如數據庫、操作及故障處理等。
7、系統流程圖與數據流程圖有什麼區別?
系統流程圖描述系統物理模型的工具，數據流程圖描述系統邏輯模型的工具。系統流程圖從系統功能的角度抽象的描述系統的各個部分及其相互之間信息流動的情況。
數據流程圖從數據傳送和加工的角度抽象的描述信息在系統中的流動和數據處理的工作狀況。
-
第四章形式化說明技術
1、說明形式化說明技術和欠形式化方法的優缺點。
2、在什麼情況下應該使用形式化說明技術？使用形式化說明技術應遵守哪些規則？
在用非形式化的方式描述時，存在矛盾，二義性，含糊性，不完整性級抽象層次混亂等問題時用形式化說明技術。
應用形式化方法的準則：
A 應該選用適當的表示方法；
B 應該形式化，但不要過分形式化；
C 應該估算成本；
D 應該有形式化的方法顧問隨時提供諮詢；
E 不應該放棄傳統的開發方式；
F 應該建立詳盡的文檔；
G 不應該放棄質量標準；
H 不應該盲目依賴形式化方法；
I 應該測試，測試再測試；
J 應該重用-
第五章總體設計
1、系統設計包括哪兩個階段
系統設計包括總體設計與詳細設計兩個階段。
2、總體設計的主要任務是什麼？
總體設計的主要任務是完成軟件結構的設計,確定系統的模塊及其模塊之間的關係。
3、總體設計的9個步驟
1）設想供選擇的方案
2）選取合理的方案
3）推薦最佳方案
4) 功能分解
5）設計軟件結構
6）設計數據庫
7）制定測試計劃
8）書寫文檔
9）審查和複審
4、軟件設計過程中遵循的基本原理
模塊化、抽象、逐步求精、信息隱藏和局部化、模塊獨立
5、什麼是模塊?模塊具有哪幾個特徵?總體設計主要考慮什麼特徵?
模塊是數據說明、可執行語句等程序對象的集合，可以單獨命名且可通過名字來訪問。 模塊具有輸入和輸出(參數傳遞)、功能、內部數據結構(局部變量)和程序代碼四個特性。 概要設計主要考慮輸入、輸出(參數傳遞)和功能兩個特性。
6、什麼是模塊化?模塊設計的準則?
模塊化是按規定的原則將一個大型軟件劃分爲一個個較小的、相對獨立但又相關的模塊。
模塊設計的準則:
(1) 改進軟件結構, 提高模塊獨立性:在對初步模塊進行合併、分解和移動的分析、精化過程中力求提高模塊的內聚，降低藕合。
(2) 模塊大小要適中:大約 50 行語句的代碼，過大的 模塊應分解以提高理解性和可維護性;過小的模塊,合併到上級模塊中。
(3) 軟件結構圖的深度、寬度、扇入和扇出要適當。一般模塊的調用個數不要超過 5 個。
(4) 儘量降低模塊接口的複雜程度;
(5) 設計單入 口、單出口的模塊。
(6) 模塊的作用域應在控制域之內。
7、6種耦合和6種內聚及其詳細解釋、作用等
耦合:
(1)無直接耦合:如果兩個模塊分別從屬於不同模塊的控制和調用，它們之間 不傳遞任何信息，沒有直接的聯繫，相互獨立，稱無直接耦合。
(2)數據耦合:如果兩個模塊之間有調用關係，相互傳遞的信息以參數的形式 給出，而且傳遞的信息僅僅是簡單的數據，則稱爲數據耦合。
(3)標記耦合:如果兩個模塊之間傳遞的是數據結構，而且被調用模塊不需要 作爲參數傳遞過來的整體數據結構，只需要使用數據結構其中一部分數據元素， 則稱爲標記耦合。
(4)控制耦合:當一個模塊調用另一個模塊時，傳遞的信息控制了該模塊的功 能，則稱爲控制耦合。
(5)公共環境耦合:兩個或多個模塊共用一個數據環境，稱爲公共環境耦合。
(6)內容耦合:一個模塊直接訪問另一個模塊的內部數據，一個模塊 不通過正 常入口而轉入另一個模塊內部，一個模塊有多個入口，這都屬於內容耦合。內聚:
(1)偶然內聚:模塊內的元素之間沒有意義上的聯繫。
(2)邏輯內聚:將邏輯上相同或相似的一類任務放在同一個模塊中，每次被調 用時，由傳送給模塊的參數來確定該模塊應完成的某一功能。
(3)時間內聚:把需要同時執行的動作組合在一起形成的模塊稱爲時間內聚模塊。
(4)通信內聚:如果模塊中所有元素都使用相同的輸入數據或者產生相同的輸 出數據，則稱爲通信內聚。
(5)順序內聚:一個模塊中各個處理元素都緊密相關於同一個功能個且必須順 序執行，此模塊的塊內聯繫屬順序內聚。
(6)功能內聚:模塊內所有元素屬於一個整體，共同完成一個單一功能，缺一 不可，則稱爲功能內聚。-
第六章詳細設計
1、詳細設計的目的?
爲軟件結構圖(SC 圖或 HC 圖)中的每一個模塊確定採用的算法和塊內數據結構,用某種選定的表達工具給出清晰的描述.
2、詳細設計的主要任務?
編寫軟件的“詳細設計說明書”.軟件人員要完成的工作:
(1) 爲每一個模塊確定採用的算法, 選擇某種適當的工具表達算法的過程,寫出模塊的詳細過程描述
(2) 確定每一模塊使用的數據結構.
(3) 確定模塊結構的細節,包括對系統外部的接口和用戶界面,對 系統內部其它模塊的接口,以及關於模塊輸入數據、輸出數據及局部數據的全部細節.
(4) 爲每一個模塊設 計出一組測試用例,以便在編碼階段對模塊代碼(即程序)進行預定的測試.
【補充】詳細設計的基本任務是什麼?
詳細設計的基本任務包括：爲每個模塊進行詳細的算法設計；爲模塊內的數據結構進行設計；對數據庫進行物理設計；其他設計；編寫詳細設計說明書；評審。
3、結構化程序設計的基本原則?
在詳細設計中所有模塊都使用單入口、單出口的順序、選擇、循環三種基本控制結構。
4、比較面向數據流和麪向數據結構兩類設計方法的異同?
相同點:
(1) 遵守結構程序設計“由頂向下”逐步細化的原則,並以其爲共同的基礎;
(2) 均服從“程序結構必須適應問題結構”的基本原則,各自擁有從問題結構(包括數據結構)導出程序結構的一組映射 規則。不同點:
(1) 面向數據流的設計以數據流圖爲基礎，在分析階段用DFD表示軟件的邏輯模型，在設 計階段按數據流類型，將數據流圖轉換爲軟件結構。面向數據結構的設計以數據結構爲基礎，從問題的數 據結構出發導出它的程序結構。
(2) 面向數據流的設計的最終目標是軟件的最終SC圖，面向數據結構的 設計的最終目標是程序的過程性描述。
5.比較 Jackson方法和 LCP方法的異同?
- Jackson 與 LCP 設計方法都是以數據結構爲出發點，以程序的過程描述爲最終目標，設計步驟基本相 似。
- 它們的主要差別是:
(1)使用不同的表達工具，其中 LCP 方法中的表達工具 Warnier 圖比 Jackson 設計方法中的表達工具 Jackson 圖有更大的通用性
(2)Jackson 方法的步驟和指 導原則有一定的靈活性，而 LCP 設計方法則更加嚴密。
6、詳細設計有哪幾種描述方法?
詳細設計的描述方法有圖形、表格和語言，其中圖形常用結構化程序流程圖、盒圖和PAD(問題分析圖)爲描述工具，語言常用過程設計語言(PDL)來作爲工具。
7、什麼是結構化分析?它的結構化體現在哪裏?
- 結構化分析:使用數據流程圖、數據字典、結構化英語、判定表和判定樹等工具，來建立一種新的、稱爲結構化說明書的目標文檔-需求規格說明書。
- 結構化體現在將軟件系統抽象爲一系列的邏輯加工單元,各單元之間以數據流發生關聯。
8、結構化程序設計的基本要點是什麼?
(1)採用自頂向下、逐步求精的程序設計方法
(2)使用三種基本控制結構構造程序。任何程序都可以由順序、選擇、重複(循環)三種基本控制結構構造，這三種基本結構的共同點是單入口、單出口。
(3)主程序員組的組織形式。
-
第七章實現
1、什麼是模塊測試和集成測試？它們各有什麼特點？
- 模塊測試是對每個單獨的模塊，分別用黑盒和白盒測試技術，測試它的功能是否正確，檢查模塊控制結構中的特定路徑並發現最大數量的錯誤。
- 其特點是：主要應用白盒測試的技術，對多個模塊的測試可以併發的進行。
- 集成測試是把模塊裝配在一起形成完整的軟件包，在裝配的同時進行測試。
- 特點是：可能發生接口問題。
2、軟件測試的基本任務?
軟件測試是按照特定的規則，發現軟件錯誤的過程;好的測試方案是儘可能發現迄今尚未發現錯誤的
測試;成功的測試方案是發現迄今尚未發現錯誤的測試;
3、測試與調試的主要區別?
(1) 測試從一個側面證明程序員的失敗;調試證明程序員的正確;
(2) 測試從已知條件開始，使用預先定義的程序，且有預知的結果，不可預見的僅是程序是否通過測試;調試從不可知內部條件開始，除統計性調試外，結果是不可預見的;
(3) 測試有計劃並且要進行測試設計;調試不 受時間約束;
(4) 測試是發現錯誤、改正錯誤、重新測試的過程;調試是一個推理的過程;
(5) 測試執行 是有規程的;調試執行要求程序員進行必要的推理;
(6) 測試由獨立的測試組在不瞭解軟件設計的件下完 成;調試由瞭解詳細設計的程序員完成;
(7) 大多數測試的執行和設計可由工具支持;調試用的工具主要 是調試器。
4、人工複審的方式和作用?
人工複審的方式:代碼會審、走查和排練和辦公桌檢查;
人工複審的作用:檢查程序的靜態錯誤。
5、什麼是黑盒測試?黑盒測試主要採用的技術有哪些?
黑盒測試也稱爲功能測試,它着眼於程序的外部特徵,而不考慮程序的內部邏輯結構。測試者把被測程序看成一個黑盒,不用關心程序的內部結構。黑盒測試是在程序接口處進行測試，它只檢查程序功能是否能 按照規格說明書的規定正常使用，程序是否能適當地接收輸入數據產生正確的輸出信息，並且保持外部信 息(如數據庫或文件)的完整性。
黑盒測試主要採用的技術有:等價分類法、邊沿值分析法、錯誤推測法和因果圖等技術。
6、什麼是白盒測試?白盒測試主要採用的技術有哪些?
- 測試者瞭解被測程序的內部結構和處理過程,對程序的所有邏輯路徑進行測試,在不同點檢查程序狀態, 確定實際狀態與預期狀態是否一致。
= 白盒測試主要採用的技術有:路徑測試技術和事務處理流程技術，對包含有大量邏輯判斷或條件組合的程序採用基於邏輯的測試技術。
7、路徑測試技術中幾種主要覆蓋的含義?
- 語句覆蓋:至少執行程序中所有語句一次。
- 判定覆蓋:使被測程序中的每一個分支至少執行一次。故也稱爲分支覆蓋。
- 條件覆蓋:執行所有可能的穿過程序的控制路流程。
- 條件組合測試:設計足夠的測試用例，使每個判定中的所有可能條件取值組合至少執行一次。
8、等價分類法的測試技術採用的一般方法?舉例說明?
(1) 爲每個等價類編號;
(2) 設計一個新的測試 方案,以儘可能多的覆蓋尚未被覆蓋的有效等價類,重複這一步驟,直到所有有效等價類被覆蓋爲止。
(3) 設計一個新的測試方案,使它覆蓋一個尚未被覆蓋的無效等價類, 重複這一步驟,直到所有無效等價 類被覆蓋爲止。
9、軟件測試的一般步驟?
單元測試、子系統測試、系統測試、驗收測試、平行測試。
10、軟件測試的策略?
(1) 在任何情況下都應使用邊界值分析的方法。
(2) 必要時用等價類劃分法補充測 試方案。
(3) 必要時再用錯誤推測法補充測試方案。
(4) 對照程序邏輯，檢查已設計出的測試方案。
(5) 根據對程序可靠性的要求採用不同的邏輯覆蓋標準，再補充一些測試方案。
11、測試的定義及目的：
①測試是爲了發現程序中的錯誤而執行的過程。
②好的測試方案是極可能發現迄今爲止尚未發現的錯誤的測試方案。
③成功的測試是發現了至今爲止尚未發現的錯誤的測試。
12、什麼是動態測試？爲何靜態測試方法往往比動態測試方法效率高？
動態測試是通過運行軟件來檢驗其動態行爲和運行結果的正確性。 動態測試是實際運行被測程序，輸入相應的測試用例，判定執行結果是否符合要求，從而檢驗程序的正確性、可靠性和有效性。
靜態測試是對被測程序進行特性分析的一些方法的總稱，這種方法的主要特性是不利用計算機運行被測試的程序，而是採用其他手段達到檢測的目的。因而在代碼產生之前便可對各種文檔進行測試，其效率當然高於動態測試。
13、單元測試與集成測試相關概念。
（1）請簡述單元測試的主要內容？
模塊接口測試、局部數據結構測試、路徑測試、錯誤處理測試、邊界測試
（2）在單元測試中，所謂單元是如何劃分的？
單元測試的對象通常是軟件設計的最小邏輯單元，單元的劃分在面向過程的結構化程序中一般是函數或子過程，在面向對象的程序中可以是類或類的成員函數。
（3）如果開發時間緊迫，是否可以跳過單元測試而直接進行集成測試？
不可以。因爲沒有經過單元測試的模塊會遺留大量的缺陷到集成測試階段，而在集成測試階段對這些缺陷定位困難，導致後續工作展開困難，修復缺陷成本成指數級增長。
（4）集成測試也叫組裝測試又叫聯合測試，爲何要進行集成測試？
在的基礎上，將所有模塊按照設計要求（如根據結構圖）組裝成爲子系統或系統，進行集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但並不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現。
14、軟件測試要經過哪些步驟?這些測試與軟件開發各階段之間有什麼關係?
- 軟件測試要經過的步驟是：單元測試→子系統測試→集成測試→確認測試→平行運行
- 單元測試對源程序中每一個程序單元進行測試，檢查各個模塊是否正確實現規定的功能，從而發現模塊在編碼中或算法中的錯誤。該階段涉及編碼和詳細設計文檔。
- 集成測試是爲了檢查與設計相關的軟件體系結構的有關問題，也就是檢查概要設計是否合理有效。
- 確認測試主要是檢查已實現的軟件是否滿足需求規格說明書中確定了的各種需求。
- 系統測試是把已確認的軟件與其他系統元素(如硬件、其他支持軟件、數據、人工等)結合在一起進行測試。以確定軟件是否可以支付使用。
15、調試的目的是什麼?調試有哪些技術手段?
調試則是在進行了成功的測試之後纔開始的工作。調試的目的是確定錯誤的原因和位置，並改正錯誤，因此調試也稱爲糾錯(Debug)。調試的技術手段有簡單的調試方法、歸納法、演繹法和回溯法等。
-
第八章 維護
1、在軟件開發過程中應該採取哪些措施來提高軟件產品的可維護性？
在每個階段結束前的技術審查和管理複查中，應該着重對可維護性進行復審過程中，應該對將來要改進的部分和可能要改的部分加以注意指明，應該討論軟件的可移植性問題，考慮可能影響軟件維護的系統界面。在設計和編碼過程中應該儘量使用可重用的軟件構件，每個測試步驟都可以暗示在軟件正式交付使用之前，程序中可能需要做預防性維護的部分。在完成每項維護工作之後，都應該對軟件維護本身仔細認真地複審。
2、維護的定義
軟件維護是指軟件系統交付使用以後，爲了改正軟件運行錯誤， 或者因滿足新的需求而加入新功能的修改軟件的過程
3、爲什麼說軟件的維護是不可避免的?
因爲軟件的開發過程中，一般很難檢測到所有的錯誤，其次軟件在應用過程中需要隨用戶新的要求或 運行環境的變化而進行軟件的修改或完成功能的增刪等，爲了提高軟件的應用水平和使用壽命，軟件的維 護是不可避免的。
4、軟件的維護一般分爲哪幾類?
①爲了糾正正在使用過程中暴露出來的錯誤而進行的改正性維護。
②爲了適應外部環境的變化而進行的適應性維護
③爲了改進原有的軟件而進行的完善性維護
④爲了改進將來的可維護性和可靠性而進行的預防性維護
5、影響軟件維護的因素有哪些?
開發方法:採用模塊化詳細設計文檔有助於理解軟件的結構、界面功能和內部流程;開發過程中嚴格 而科學的管理規劃及清晰可靠的文檔資料對發生錯誤後的理解與糾錯是至關重要的;開發過程中模塊的獨 立程度越高，對軟件修改越容易，對軟件的改進和移植越方便。
開發條件:軟件開發及維護人員的水平決定了軟件開發的質量和維護的效率;開發過程中使用標準的 程序設計語言和標準的操作系統接口，可以大大提高軟件的可維護性;在測試過程中用例的有效性，可極 大地減少軟件存在的錯誤;其次使用規範化的文檔資料可爲維護提供更好的依據。
6、軟件維護困難主要表現在什麼方面?
（1）理解別人寫的程序通常很困難
（2）需要維護的軟件文檔資料太少
（3）當要求對軟件維護時，不能指望由開發人員給人們仔細說明文檔
（4）絕大多數軟件在設計時沒有考慮將來的修改
（5）軟件維護不是一項吸引人的工作
7、決定軟件可維護性的因素?
(1) 軟件的可理解性、可測試性、可修改性、可移植性、可重用性
(2) 文檔描述符合要求、用戶文檔簡潔明確、系統文檔完整並且標準
8、簡述提高可維護性的方法。
(1)建立明確的軟件質量目標；
(2)利用先進的軟件開發技術和工具；
(3)建立明確的質量保證工作；
(4)選擇可維護的程序設計語言；
(5)改進程序文檔。
-
第九章 面向對象方法學引論
1、什麼是面向對象方法學？它有哪些優點？
- OO=objects+classes+inheritance+communication with messages 也就是說,面向對象就是既使用對象又使用類和繼承等機制,而且對象之間僅能通過傳遞消息實現彼此通信。
- 儘可能模擬人類習慣的思維方式，使開發軟件的方法與過程儘可能接近人類認識世界解決問題的方法與過程，也就是使描述問題的問題空間與實現解法的解空間在結構上儘可能一致。
- 優點：
與人類習慣的思維方法一致
穩定性好
可重用性好
較易開發大型軟件產品
可維護性好
2、什麼是“對象”？它與傳統的數據有何異同？
人們把客觀世界中的實體抽象爲問題域中的對象。
異同：它不是被動地等待外界對它施加操作，相反，它是進行處理的主體。必須發消息請求對象主動地執行它的某些操作，處理它的私有數據，而不能從外界直接對它的私有數據進行操作。
（對象是封裝了數據結構及可以施加在這些數據結構上的操作的封裝體，這個封裝體有可以唯一地標識它的名字，而且向外界提供一組服務。）
3、什麼是“類”？
類是對具有相同屬性和行爲的一個或多個對象的描述。
4、什麼是“繼承”？
子類自動地共享基類中定義的數據和方法的機制。
5、什麼是模型？開發軟件爲何要建模？
模型就是爲了理解而對事物作出的一種抽象，是對事物的一種無歧義的書面描述。
軟件開發建立模型是爲了幫助我們思考問題、定義術語、在選擇術語時作出適當的假設，並且有助於保持定義和假設的一致性。
6、面向對象的方法學方程
OO=objects+classes+inheritance+communication with messages
對象 類 繼承 消息
7、面向對象方法學的優點：
①與人類習慣的思維方法一致
②穩定性好
③可重用性好
④較易開發大型軟件產品
⑤可維護性
8、對象模型：表示靜態的，結構化的系統的“數據”性質。它是對模擬客觀世界實體的對象以及對象彼此間的關係的映射，描述了系統的靜態結構。
9、動態模型：表示瞬時的、行爲化的系統的“控制”性質。它規定了對象模型中的對象的合法變化序列
10、功能模型：表示變化的系統的“功能”性質，它指明瞭系統應該“做什麼”，因此更直接地反映用戶對目標系統的需求。
11、三種模型之間的關係：功能模型指明瞭系統應該“做什麼”；動態模型明確規定了什麼時候（即在何種狀態下接受了什麼事件的出發）做；對象模型則定義了做事情的實體。
12、面向對象方法學包含哪些核心概念？簡述之
(1) 對象：對象是現實世界中個體或事物的抽象表示，是其屬性和相關操作的封裝。
(2) 類：類是對具有相同屬性和行爲的一個或多個對象的描述。
(3) 繼承：類之間的繼承關係是現實世界中遺傳關係的模擬，它表示類之間的內在聯繫 以及對屬性和操作的共享。
(4) 聚集：現實世界普遍存在部分—整體關係。
(5) 消息：消息傳遞是對象與其外部世界相互關聯的唯一途徑。
13、說明面向對象的特徵?
(1)對象唯一性。每個對象都有自身唯一的標識，在對象生存期中，其標識不變，不同的對象不能有不同的標識。
(2)分類性。是指將具有一致的數據結構(屬性)和行爲(操作)的對象抽象成類
(3)繼承性。是子類自動共享父類數據結構和方法的機制，這是類之間的一種關係。
(4)多態性。是指相同的操作或函數過程可以作用於多種類型的對象上並獲得不同的結果。
-
第十章 面向對象分析
1、面向對象分析：就是抽取和整理用戶需求並建立問題域精確模型的過程。
-
第十一章 面向對象設計
1、面向對象設計應該遵循哪些準則？簡述每條準則的內容，並說明遵循這條準則的必要性
模塊化、抽象、信息隱藏、弱耦合、強內聚、可重用。
2、簡述有助於提高面向對象設計質量的每條主要啓發規則的內容和必要性。
（1）設計結果應該清晰易懂,使設計結果清晰、易讀、易懂,是提高軟件可維護性和可重用性的重要措施；
（2）一般、特殊結構的深度應適當,應該使類等級中包含的層次數適當;
（3）設計簡單的類,應該儘量設計小而簡單的類,以便於開發和管理;
（4）使用簡單的協議,一般說來,消息中的參數不要超過3個;
（5）使用簡單的服務,一般只有3—5行源程序語句,可以用僅含一個動詞和一個賓語的簡單句子描述它的功能;
（6）把設計變動減至最小,即使出現必須修改設計的情況,也應該使修改的範圍儘可能小。
3、爲什麼說類構件是目前比較理想的可重用軟構件？它有哪些重用方式？
具備可重用的軟構件應有的特點：獨立、可塑、接口清晰（文檔詳盡）。
重用方式有：實例重用、繼承重用和多態重用。
-
第十二章 面向對象實現
1、面向對象實現應該選用哪種程序設計語言?爲什麼?
（1）將來能否占主導地位,爲了使自己的產品在若干年後仍然具有很強的生命力;
（2）可重用性,採用面向對象方法開發軟件的基本目的和主要優點,是通過重用提高軟件生產率;
（3）類庫和開發環境,決定可重用性的因素,不僅僅是面向對象程序語言本身,開發環境和類庫也是非常要的因素;
（4）其他因素,對用戶學習面向對象分析、設計和編碼技術所能提供的培訓服務;在使用這個面嚮對象語言期間能提供的技術支持;能提供給開發人員使用的開發工具、開發平臺、發行平臺;對機器性能和內存的需求;集成已有軟件的容易程度等。
2、面向對象程序設計語言主要有哪些技術特點？
（1）支持類與對象概念的機制
（2）實現整體部分（即聚集）結構的機制
（3）實現一般特殊（即泛化）結構的機制
（4）實現性和服務的機制
（5）類型檢查
（6）類庫
（7）效率
（8）持久保存對象
（9）參數化類
（10）開發環境
3、良好的面向對象程序設計風格主要有哪些準則?
- 良好的面向對象程序設計風格,即包括傳統的程序設計風格準則,也包括爲適應面向對象方法所特有的概念(例如,繼承性)而必須遵循的一些新準則。
- 提高可重用性:1、提高方法的內聚;2、減小方法的規模;3、保持方法的一致性;4、把策略與實現分開;5、全面覆蓋;6、儘量不使用全局信息;7、利用繼承機制。
- 提高可擴充性:1、封裝實現策略;2、不要用一個方法遍歷多條關聯鏈;3、避免使用多分支語句;4、精心確定公有方法。
- 提高健壯性:1、預防用戶的操作錯誤;2、檢查參數的合法性;3、不要預先確定限制條件;4、先測試後優化。
4、測試面向對象軟件時,單元測試、集成測試和確認測試各有哪些新特點?
- 面向對象的單元測試,最小的可測試單元是封裝起來的類和對象。測試面向對象軟件時,不能再孤立地測試單個操作,而應該把操作作爲類的一部分來測試。
- 面向對象的集成測試,主要有下述兩種不同的策略:1、基於線程的測試。這種策略把響應系統的一個輸入或一個事件所需要的那些類集成起來。
- 基於使用的測試。面向對象的確認測試,面向對象軟件的確認測試也集中檢查用戶可見的動作和用戶可識別的輸出。
5、測試面向對象軟件時，主要有哪些設計單元測試用例的方法？
隨機測試、劃分測試、基於故障的測試
6、測試面向對象軟件時，主要有哪些設計集成測試用例的方法？
多類測試、從動態模型中導出測試用例。也可採用隨機測試、劃分測試的方法。
7、測試面向對象軟件時，主要有哪些設計確認測試用例的方法？
可以採用傳統的黑盒方法，也可以採用基於情景的方法
-
第十三章 軟件項目管理
1、一個程序能既正確又不可靠嗎？解釋一下自己的答案。
答：能。所謂軟件可靠性,是程序在給定的時間間隔內按照規格說明書的規定成功地運行的概率.通常認爲,軟件可靠性既包含正確性又包含健壯性,也就是說,不僅在預定環境下程序應該能正確地完成預期功能,而且在硬件發生故障,輸入的數據無效或用戶操作錯誤等意外環境下,程序也應該能做出適當的響應. 如果一個程序在預定環境下能夠正確地完成預期的功能,但是在意外環境下不能做出適當的響應,則該程序就是既正確又不可靠
2、什麼是基線？爲什麼要建立基線？
答：是已經通過了正式複審的規格說明或中間產品，它可以作爲進一步開發的基礎，並且只有通過正式的變化控制過程才能改變它。建立基線的三大原因是：重現性、可追蹤性和報告。重現性是指及時返回並重新生成軟件系統給定發佈版的能力，或者是在項目中的早些時候重新生成開發環境的能力。可追蹤性建立項目工件之間的前後繼承關係。其目的在於確保設計滿足要求、代碼實施設計以及用正確代碼編譯可執行文件。報告來源於一個基線內容同另一個基線內容的比較。基線比較有助於調試並生成發佈說明。建立基線後，需要標註所有組成構件和基線，以便能夠對其進行識別和重新建立。
3、配置審計和技術複審有何不同？可否把它們的功能放在一次複審終完成？
答：正式的技術複審關注被修改後的配置對象的技術正確性。複審者審查該對象以確定它與其他軟件配置項的一致性，並檢查是否有遺漏或副作用，軟件配置審計通過評估配置對象的那些通常不在複審過程中考慮的特徵，而成爲對正式技術複審的補充。
4、CMM的基本思想是什麼？爲什麼要把能力成熟度劃分爲5個等級？
CMM的基本思想是，由於問題是由我們管理軟件過程的方法不當引起的，所以軟件技術的運用並不會自動提高軟件的生產率和質量。把能力成熟度劃分成5個等級的原因是：對軟件的改進不可能一撅而就。
整理於：張海藩, 牟永民, 軟件工程導論（第6版）, 清華大學出版社, 2016.