第一篇：軟件工程重點總結

1、什么是軟件危機？

軟件危機泛指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。

2、軟件危機的主要表現

（1）對軟件開發成本和進度的估計常常很不準確

（2）用戶對“已完成的”軟件系統不滿意現象經常發生

（3）軟件產品質量往往靠不住

（4）軟件往往是不可維護的（5）軟件通常沒有適當的文檔資料

（6）軟件成本在計算機系統總成本中所占的比例逐年上升

（7）軟件開發生產效率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢

3、軟件危機產生的原因

(1)來自軟件自身的特點

是軟件系統的邏輯部件，缺乏可見性，管理和控制軟件開發過程相當困難；規模龐大、復雜，修改、維護困難。

(2)軟件開發與維護的方法不當

忽視需求分析；認為軟件開發等于程序編寫；輕視軟件維護。

4、如何消除軟件危機？

（1）對計算機軟件有一個正確的認識(軟件≠程序）

（2）必須充分認識到軟件開發不是某種個體勞動的神秘技巧，而應該是一種組織良好、管理嚴密、各類人員協同配合、共同完成的工程項目

（3）推廣使用在實踐中總結出來的開發軟件的成功技術和方法

（4）開發和使用更好的軟件工具

5、面向對象的三種模型：對象模型 動態模型 功能模型 P2166、模塊獨立性的兩個標準：耦合 內聚 P977、軟件測試方法：黑盒測試 白盒測試 P1518、軟件調試的途徑：蠻干法 回溯法 原因排除法 P1789、可行性研究：確定問題是否有行得通的解決辦法 P3510、需求分析：準確地回答“系統必須干什么”這個問題 P5511、軟件成分的重用級別：代碼重用 設計結果重用 分析結果重用

可被重用的軟件成分有：項目計劃，成本估計，體系結構，需求模型和規格說明，設計，源代碼，用戶文檔和技術文檔，用戶界面，數據，測試用例。

12、軟件可靠性的定義：軟件在給定的時間間隔內，按照規格說明書的規定成功地運行的概率。

軟件可用性的定義：程序在給定的時間點，按照規格說明書的規定，成功地運行的概率。可靠性與可用性之間的主要差別是，可靠性意味著在0到t這段時間內系統沒有失效，而可用性只意味著在時刻t，系統是正常運行的。P17913、白盒測試：邏輯覆蓋 控制結構測試 P162

黑盒測試：等價劃分 邊界值分析 調試 P171

環形復雜度的計算：復雜度=邊數-點數+2P13714、面向對象的3個子模式：對象模型 動態模型 功能模型 P232

對象模型的5個層次：主題層 類與對象層 結構層 屬性層 服務層 P23215、軟件定義階段干什么事：確定軟件開發工程必須完成的總目標；確定工程的可行性；導

出實現工程目標應該采用的策略及系統必須完成的功能；估計完成該工程需要的資源和成本，并制定工程進度表。

16、類和對象的關系：類是具有相同數據和相同操作的一組相似對象的定義，也就是說，類

是對具有相同屬性和行為的一個或多個對象的描述。類是支持繼承的抽象數據類型，而對象就是類的實例。P21117、UML有哪些圖？ P2171、用例圖：展示系統外部的各類執行者與系統提供的各種用例之間的關系

2、類圖：展示系統中類的靜態結構

3、對象圖：是類圖的一種實例化圖

4、狀態圖：描述一類對象具有的所有可能的狀態及其轉移關系

5、時序圖：展示對象之間的一種動態協作關系

6、合作圖：從另一個角度展示對象之間的動態協作關系

7、活動圖：展示系統中各種活動的執行流程

8、構件圖：展示程序代碼的物理結構

9、配置圖：展示軟件在硬件環境中的配置關系

18、能力成熟度模型（CMM）：初始級 可重復級 已定義級 已管理級 優化級 P31119、什么是軟件生命周期模型?試比較瀑布模型、快速原型模型、增量模型和螺旋模型的優

缺點，說明每種模型的適用范圍。P33習題1.720、軟件的可維護性定義：維護人員理解、改正、改動或改進這個軟件的難易程度。決定可維護性的因素：可理解性 可測試性 可修改性 可移植性 可重用性。

文檔是影響可維護性的決定性因素。P19521、如何評價軟件規格說明書？

從四個方面：一致性 完整性 現實性 有效性 P7022、層次圖 P10223、深度：軟件結構中控制的層數 P100

寬度：軟件結構中同一個層次上的總數的最大值

扇出：一個模塊直接控制（調用）的模塊數目

散入：一個模塊被多少個上級模塊直接調用

24、面向數據流的設計方法 P10425、類構件的重用方式：實例重用 繼承重用 多態重用

1.什么是軟件工程？軟件工程和計算機科學有何區別？

軟件工程是指導計算機軟件開發和維護的一門工程學科。

計算機科學研究的是構成計算機和軟件系統基礎的有關理論和方法，而軟件工程則是研究軟件制作中的實際問題。

2、流程圖與數據流圖有什么主要區別？

（1）數據流圖（date flow diagram , DFD），是SA方法中用于表示系統邏輯模型的一種工具，它以圖形的方式描繪數據在系統中流動和處理的過程，由于它只反映系統必須完成的邏輯功能，所以它是一種功能模型，是從數據的角度來描述一個系統的；而流程圖則是從對數據加工的角度來描述系統的；

（2）數據流圖中的箭頭是數據流，而流程圖中的箭頭則是控制流,它表達的是程序執行的次序；

（3）數據流圖適合于宏觀地分析一個組織業務概況,而程序流程圖只適合于描述系統中某個加工的執行細節。

（4）數據流程圖應該重點描述了數據加工的過程，主要是模塊內部，數據流圖則是描述模塊之間的關系。

3．軟件需求分析的任務是什么？有哪些主要步驟？

需求分析的基本任務是深入描述軟件的功能和性能、確定軟件設計的約束和軟件同其它系統元素的接口細節、定義軟件的其它有效性需求，總之，需求分析的任務就是借助于當前系統的邏輯模型導出目標系統的邏輯模型，解決目標系統的 “做什么” 的問題。

主要步驟：

1.問題識別

(1)功能需求：明確所開發的軟件必須具備什么樣的功能。

(2)性能需求：明確待開發的軟件的技術性能指標。

(3)環境需求：明確軟件運行時所需要的軟、硬件的要求。

(4)用戶界面需求：明確人機交互方式、輸入輸出數據格式。

2.分析與綜合，導出軟件的邏輯模型

分析人員對獲取的需求，進行一致性的分析檢查，在分析、綜合中逐步細化軟件功能，劃分成各個子功能。用圖文結合的形式，建立起新系統的邏輯模型。

3.編寫文檔

(1)編寫“需求規格說明書”，把雙方共同的理解與分析結果用規范的方式描述出來，作為今后各項工作的基礎。

(2)編寫初步用戶使用手冊，著重反映被開發軟件的用戶功能界面和用戶使用的具體要求，用戶手冊能強制分析人員從用戶使用的觀點考慮軟件。

(3)編寫確認測試計劃，作為今后確認和驗收的依據。

(4)修改完善軟件開發計劃。在需求分析階段對待開發的系統有了更進一步的了解，所以能更準確地估計開發成本、進度及資源要求，因此對原計劃要進行適當修正。

4．簡述結構化分析、設計的要點：

結構化分析方法適合于數據處理類型軟件的需求分析。

其要點是“自頂向下” 地開發系統,由整體到各組成部分,由表及里,由抽象到具體,逐步求精.(1)模塊化

(2)由頂向下,逐步求精.(3)上層模塊分解為下層模塊,有三種不同的結構形式,即順序結構,選擇結構和循環結構.5．數據字典包含哪些主要內容？

數據字典通常包括數據項、數據結構、數據流、數據存儲和處理過程五個部分.據字典內容包括：

數據庫中所有模式對象的信息，如表、視圖、簇、及索引等。

分配多少空間，當前使用了多少空間等。

列的缺省值。

約束信息的完整性。

用戶的名字。

用戶及角色被授予的權限。

用戶訪問或使用的審計信息。

其它產生的數據庫信息。

6．軟件測試的目標是什么，有哪幾種主要有測試方法？

軟件測試的目標：

(1)測試是為了發現程序中的錯誤而執行程序的過程；

(2)好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案；

(3)成功的測試是發現了至今為止尚未發現的錯誤的測試。

軟件測試的方法有黑盒測試、白盒測試。

7．白盒測試主要有哪些覆蓋？

語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、點覆蓋、邊覆蓋、路徑覆蓋

8、選擇一種程序設計語言的主要有哪些依據？

為了使程序容易測試和維護以減少生命周期的總成本，選用的高級語言應該有理想的模塊化機制，以及可讀性好的控制結構和數據結構；為了便于調試和提高軟件可靠性，語言特點應該使編譯程序能夠盡可能多地發現程序中的錯誤；為了降低軟件開發和維護的成本，選用的語言應該有良好的獨立編譯機制。上述這些要求是選擇語言的理想標準，但是在實際選用語言時不能僅僅考慮理論上的標準，還必須同時考慮實用方面的各種限制。

(1)系統用戶的要求

(2)可以使用的編譯程序

(3)可以得到的軟件工具

(4)系統規模

(5)程序員的知識

(6)軟件可移植性要求

(7)軟件的應用領域

9．軟件的維護的目標是什么，有哪幾種維護類型？

糾正在使用過程中暴露出來的錯誤而進行的改進性維護，適應外部環境的變化而進行的適應性維護，改進原有的軟件而進行的完善性維護，以及改進將來的可維護性和可靠性而進行的預防性維護。

軟件維護主要劃分為糾錯性維護、適應性維護和完善性維護。

(1)糾錯性維護。由于前期的測試不可能揭露軟件系統中所有潛在的錯誤，用戶在使用軟件時仍將會遇到錯誤，診斷和改正這些錯誤的過程稱為糾錯性維護。

(2)適應性維護。由于新的硬件設備不斷推出，操作系統和編譯系統也不斷地升級，為了使軟件能適應新的環境而引起的程序修改和擴充活動稱為適應性維護。

(3)完善性維護。在軟件的正常使用過程中，用戶還會不斷地提出新的需求。為了滿足用戶新的需求而增加軟件功能的活動稱為完善性維護。

10．簡述提高軟件質量的主要措施。

復審：是在軟件生命周期每個階段結束之前，都采用一定的標準對該段產生的軟件配置成分進行嚴格的正式或非正式的檢測。

復查：是檢查已有的材料，以斷定在軟件生命周期某個階段的工作是否能夠開始或繼續。管理復審：是向開發組織或使用部門的管理人員提供有關項目的總體狀況、成本和進度等方面的情況，以便他們從管理角度對開發工作進行審查。

測試：包括測試計劃、測試過程和測試結果3個階段。

11．面向對象如何實現模塊獨立性，其偶合和內聚的含義是什么？

因為對象是由數據及可以對這些數據施加的操作所組成的統一體，而且對象是以數據為中心的，操作圍繞對其數據所需做的處理來設置，沒有無關的操作。因此，對象內部各種元素彼此結合得很緊密。內聚性相當強，由于完成對象所需要的元素（數據和方法）基本上都被封裝在對象內部，它與外界的聯系自然就比較少。因此，對象之間的耦合通常比較松。總之，面向對象使用對象、類、繼承和消息的方法，既使用類和繼承等機制，而且對象之間僅能通過傳遞消息實現彼此通信來實現模塊的獨立性。

12．面向對象和面向過程軟件工程有哪些區別？

（1）面向過程就是分析出解決問題所需要的步驟，然后用函數把這些步驟一步一步實現，使用的時候一個一個依次調用就可以了。面向對象是把構成問題事務分解成各個對象，建立對象的目的不是為了完成一個步驟，而是為了描敘某個事物在整個解決問題的步驟中的行為。（2）面向過程是把一件事一項工程分解成為一個個小的功能,用一個個函數來實現.面向對象是把事情看成是一個個小的對象組成的,或者說一個個小部分組成的,這些對象之間的相互關系,構成了整個項目.在面向對象的思想中，萬物皆對象。而“類”，就是對象的抽象或者說是概括。

13.簡述對象、類、消息、方法的基本概念。

(1)對象是人們要進行研究的任何事物，從最簡單的整數到復雜的飛機等均可看作對象，它不僅能表示具體的事物，還能表示抽象的規則、計劃或事件。

(2)類是具有相同或相似性質的對象的抽象。對象的抽象是類，類的具體化就是對象，也可以說類的實例是對象。類具有屬性，它是對象的狀態的抽象，用數據結構來描述類的屬性。類具有操作，它是對象的行為的抽象，用操作名和實現該操作的方法來描述。

(3)對象之間進行通信的結構叫做消息。在對象的操作中，當一個消息發送給某個對象時，消息包含接收對象去執行某種操作的信息。發送一條消息至少要包括說明接受消息的對象名、發送給該對象的消息名（即對象名、方法名）。一般還要對參數加以說明，參數可以是認識該消息的對象所知道的變量名，或者是所有對象都知道的全局變量名。

(4)類中操作的實現過程叫做方法，一個方法有方法名、參數、方法體。

14．簡述面向對象分析設計的三個模型。

答：三個模型：對象模型、動態模型、功能模型

（1）對象模型描述系統的靜態結構，包括類和對象，它們的屬性和操作，以及它們之間的關系。構造對象模型的目的在于找出與應用程序密切相關的概念。對象模型用包含對象及對象的關系圖表示。

（2）動態模型著重于系統的控制邏輯，考察在任何時候對象及其關系的改變，描述這些涉及時序和改變的狀態。動態模型包括狀態圖和事件跟蹤圖。狀態圖是一個狀態和事件的網絡，側重于描述每一類對象的動態行為。事件跟蹤圖則側重于說明系統執行過程中的一個特點“場景”，也叫做腳本(scenarios)，是完成系統某個功能的一個事件序列。腳本通常起始于一個系統外部的輸入事件，結束于一個系統外部的輸出事件。

（3）功能模型著重于系統內部數據的傳送和處理。功能模型表明，通過計算，從輸出數據能得到什么樣的輸出數據，但不考慮參加計算的數據按什么時序執行。功能模型由多個數據流圖組成，它們指明從外部輸出，通過操作和內部存儲，直到外部輸出的整個數據流情況。功能模型還包括了對象模型內部數據間的限制。功能模型中的數據流圖往往形成一個層次結構，一個數據流圖的過程可以由下一層的數據流圖作進一步的說明。

第二篇：軟件工程重點總結

軟件的定義：軟件是計算機系統中與硬件相互依存的另一部分，軟件包括程序、數據及其相關文檔的完整集合。

在結構化程序設計時代，程序的最小單位是向對象程序設計時代，程序的最小單位是類，在類中封裝了相關的數據及指令代碼。軟件的特性：形態特性、智能特性、開發特特性、維護特性、廢棄特性、應用特性。軟件的分類：系統軟件、應用軟件、支撐軟 軟件危機的表現：軟件開發周期長、成本高、軟件危機發生的原因：（1）缺乏軟件開發的工作的計劃很難制定。（2）軟件人員與用戶的交流存在障礙。（3）軟件開發過程不規范，缺少方法論和規范的指導，開發人員各自為戰，缺少整體的規劃和配合，不重視文字資料工作，軟件難以維護。（4）隨著軟件規模的增大，其復雜性往往會呈指數級升高。（5）缺少有效的軟件測評手段，提高用戶的軟件質量差，在運行中暴露出大量的問題，輕者影響系統的正常使用，重者發生事故，甚至造成生命財產的重大損失。

首次提出“軟件工程”的概念的時間是1968年。

按工程化的原則和方法組織軟件開發工作是 軟件工程的定義：軟件工程是指導軟件開發和維護的工程性學科，它以計算機科學理論和其他相關學科的理論為指導，采用工程化的概念、原理、技術和方法進行軟件的開發和維護，把經過時間考驗而證明是正確的管理技術和當前能夠得到的最好的技術方法結合起來，以較少的代價獲得高質量的軟件并維護它。

軟件工程的目標是運用先進的軟件開發技術 衡量軟件的質量的六個特性：功能性、可靠

軟件生存期的三個時期：軟件定義、軟件開定義時期的主要任務是解決“做什么”的問地滿足用戶的需要。

開發過程中的典型文檔包括：軟件需求規格計說明書、用戶手冊。

各個階段所要完成的基本任務：問題定義與可行性研究、需求分析、軟件設計、程序編碼和單元測試、集成測試和系統測試、軟件運行和維護。

典型的軟件生存期模型包括瀑布模型、原型模型、增量模型、螺旋模型等（噴泉模型）。

瀑布模型的特點：1）階段間具有順序性和依賴性。2）推遲實現的觀點。3）質量保證的觀點。

瀑布模型的優點：①可強迫開發人員采用規范化的方法。②嚴格地規定了每個階段必須提交的文檔。③要求每個階段交出的所有產品都必須是經過驗證（評審）的。

瀑布模型的缺點：①由于瀑布模型幾乎完全依賴于書面的規格說明，很可能導致最終開發出的軟件產品不能真正滿足用戶的需要。如果需求規格說明與用戶需求之間有差異，就會發生這種情況。②瀑布模型只適用于項目開始時需求已確定的情況。

快速原型模型的優點：①有助于滿足用戶的互而得到驗證，據此產生的規格說明文檔能夠正確地描述用戶需求。③軟件產品的開發基本上是按線性順序進行。④因為規格說明文檔正確地描述了用戶需求，因此，在開發過程的后續階段不會因為發現規格說明文檔的錯誤而進行較大的返工。⑤開發人員通過建立原型系統已經學到了許多東西，因此，在設計和編碼階段發生錯誤的可能性也比較小，這自然減少了在后續階段需要改正前面階段所犯錯誤的可能性。⑥快速原型的本質是“快速”。開發人員應該盡可能快地創造出原型系統，以加速軟件開發過程，節約軟件開發成本。原型的用途是獲知用戶的真正需求，一旦需求確定了，原型可以拋棄，當然也可以在原型的基礎上進行開發。

增量模型的優點：①能夠在較短的時間內向構件交付之日起，用戶就能做一些有用的工作。②逐步增加產品的功能可以使用戶有較充裕的時間學習和適應新產品，從而減少全新的軟件可能給用戶組織帶來的沖擊。③項目失敗的風險較低，雖然在某些增量構件中可能遇到一些問題，但其他增量構件將能夠成功地交付給客戶。④優先級最高的服務首先交付，然后再將其他增量構件逐次集成進來。一個必然的事實是：最重要的系統服務將接受最多的測試。這意味著系統最重要的部分一般不會遭遇失敗。

螺旋模型的優點：①對可選方案和約束條件軟件質量作為軟件開發的一個重要目標。②減少了過多測試或測試不足所帶來的風險。③在螺旋模型中，維護只是模型的另一個周期，因而在維護和開發之間并沒有本質區別。螺旋模型的缺點：螺旋模型是風險驅動的，因此要求軟件開發人員必須具有豐富的風險評估經驗和這方面的專門知識，否則將出現真正的風險：當項目實際上正在走向災難時，開發人員可能還以為一切正常。

方法學：通常把在軟件生命周期全過程中使用的一整套技術的集合稱為方法學，也稱為范型。

軟件工程方法學三個要素：方法、工具和過傳統方法也稱為生命周期方法或結構化范項任務。這種方法學把軟件生命周期的全過程依次劃分為若干個階段，然后順序地逐步完成每個階段的任務。每個階段的開始和結束都有嚴格的標準，對于任何兩個相鄰的階段而言，前一階段的結束標準就是后一階段的開始標準。在每個階段結束之前都必須進行正式評審，評審通過之后這個階段才結束，否則就需要返工，返工之后還要評審。評審的一條主要標準就是每個階段都應該交出高質量的工作產品，其中，前面階段的工作產品主要是文檔，如需求規格說明書、軟件設計說明書等。

面向對象方法的基本原則，是盡量模擬人類習慣的思維方式，使開發軟件的方法和過程盡可能接近人類認識問題和解決問題的方法與過程，從而使描述問題的問題空間與其解空間在結構上盡可能一致。

封裝的定義：封裝是一種信息隱蔽技術，就作封裝在一起。①清楚的邊界②接口③受保護的內部實現

軟件需求分析階段的主要工作產品有“軟件需求規格說明書”和“初步的用戶手冊” 需求獲取的主要任務是與客戶或用戶溝通，想要實現什么，系統和產品如何滿足業務的要求，最終系統或產品如何用于日常工作

需求獲取產生困難的原因：系統的目標或范圍問題，需求不準確性問題，需求的易變問題

需求獲取活動需解決的問題：1.發現和分析問題，并分析問題的原因/結果關系2.與用戶進行各種方式的交流，并使用調查研究方法收集信息3.按照三個成分即數據、過程和接口觀察問題的不同側面4.將獲取的需求文檔化，形式有例圖、決策表、決策樹等 軟件需求分析階段的工作4個步驟：需求獲取，需求分析，需求定義，需求驗證

數據字典以詞條方式定義在數據模型、功能息的特性，給出它們的準確定義

設計是技術世界和人類的目標世界結合在一

軟件設計的原則：(1)分而治之(2)模塊獨立(4)復用性設計(5)靈活性設計

模塊獨立性，是指軟件系統中每個模塊只涉

復用是指同一事物不做修改或稍加修改就可質量及生產率的重要方法，軟件復用已不再局限于軟件代碼的復用，復用范圍已經擴展到軟件開發的各個階段，包括需求模型和規格說明、設計模型、文檔、測試用例等復用。模塊間的耦合和內聚兩個準則來度量模塊獨的緊密程度）的度量，內聚是模塊功能強度（一個模塊內部各個元素彼此結合的緊密程度）的度量。模塊獨立性比較強的模塊應是高度內聚、松散耦合的模塊。

在最高的抽象層次上，可以使用問題所處環境的語言概括地描述問題的解決方法：在較低的抽象層次上，采用更過程化的方法，將面向問題的術語和面向實現的術語結合起來描述問題的解法；在最低的抽象層次，則用某種程序設計語言來描述問題的解法。從工商管理的角度，可以將軟件設計分為兩個階段：概念設計階段和詳細設計階段。結構圖是精確模塊結構的圖形表示工具。清聯系。(1)模塊的條用關系和接口(2)模塊間的信息傳遞(3)輔助符號(4)結構圖的形態特征(結構圖的深度、寬度、扇入和扇出)過程描述工具有：圖形工具、表格工具、語

自頂向下、逐步求精方法的優點：1)自頂向遍規律，可提高軟件開發的成功率和生產率2)用先全局后局部、先整體后細節、先抽象后具體的逐步求精的過程開發出來的程序具有清晰地層次結構，因此程序更容易閱讀和理解3)程序自頂向下，逐步細化，分解成樹形結構4)程序清晰和模塊化，使得在修改和重新設計一個軟件時，可復用的代碼量最大5)程序的邏輯結構清晰，有利于程序正確性證明6)每一步工作盡在上層結點的基礎上做不多的設計擴展，便于檢查7)有利于設計的分工和組織工作

軟件測試：在軟件投入生產性運行之前，對復審，是軟件質量控制的關鍵步驟。軟件測試是為了發現錯誤而執行程序的過程。

軟件測試的目的：①測試是程序的執行過程，目的在于發現錯誤；②一個好的測試用例在于能發現至今未發現的錯誤；③一個成功的測試是發現了至今未發現的錯誤的測試。軟件測試的目標是想以最少的時間和人力系 軟件測試的原則：

1、盡早地和不斷地進行軟之對應的預期輸出結果這兩部分組成；

3、程序員應避免檢查自己的程序。測試過程需要三類輸入：軟件配置、測試配控制流圖是描述程序的控制流的一種圖示方

環路復雜性V（G）的計算方法：

1、環路復

2、設E為控制流圖的邊數，N為圖中的結點數，則V（G）=E-N+2；

3、設P為控制流圖中的判定結點數，則V(G)=P+1.獨立路徑：是指包括一組以前有沒有處理的語句或條件的一條路徑。等價類劃分是一種典型的黑盒測試方法。有效等價類：是指對于軟件的規格說明來說，合理的、有意義的輸入數據構成的集合。利用它可以檢查程序是否實現了規格說明預先規定的功能和性能。無效等價類：是指對于軟件的規格說明來說，軟件測試過程的4步驟：單元測試、組裝測試、確認測試和系統測試。

驅動模式：相當于被測模塊的主程序。它接受測試數據，把這些數據傳送給被測模塊，最后再輸出實測結果。樁模塊：也叫存根模塊。用以代替被測模塊 把模塊組裝為系統的方式通常有：一次性組確認測試又稱有效性測試。它的任務是驗證軟件的有效性，即驗證軟件的功能和性能及其他特征是否與用戶的要求一直。對軟件的功能和性能要求在軟件需求規格說明書中已經明確規定。

面向對象分析模型由3個獨立的模型構成：用類和對象表示的靜態模型（對象模型）；有狀態圖和順序圖表示的動態模型（交互模型）。

以上3個模型的重要程度是不同的。用例模型是整個后續工作的基礎，也是測試與驗收的依據。由于面向對象系統中，類、接口、及對象是軟件的基本組成單元，因此對象模型是必須建立的，也是核心模型，幾乎解決任何一個問題都需要從客觀世界實體及實體間的相互關系抽象出極有價值的對象模型；當問題涉及交互作用和時序是，動態模型是重要的。

復雜的大型系統的對象模型由5個層次組 在系統分析階段，對象建模的主要任務是建世界中的類與對象以及它們之間的關系，而非實際的軟件類或實際構件。

軟件維護類型：改正性維護，適應性維護，影響維護工作量的因素：1.系統規模；2.系4.數據庫技術的應用水平；5.所采用的軟件開發技術及軟件開發工程化的程度；6.其他。針對三種典型的維護，提出策略以控制維護成本。改正性維護的策略方法：數據庫管理高級（第四代）語言。軟件維護性定義：指當對軟件實施各種類型能力。軟件維護性子特性：易分析性，易變更性，提高軟件維護性的開發技術和工具：1.使用2.實施開發階段產品的維護性審查；3.改進文檔。

第三篇：軟件工程重點總結

軟件工程復習重點總結

1.(P-2)

Analysis:

decompose a large problem into smaller, understandable pieces，(一個大問題分解成更小的、可以理解部分)abstraction is the key Synthesis:

build(compose)software from smaller building blocks,(生成撰寫軟件從較小的構造塊)composition is challenging 2Software Engineering Solving Problems(continued)：(P-4)

method： refers to a formal procedure（指的是一個正式的程序）

tool：an instrument or automated system for accomplishing something in a better way procedure（過程）：a combination of tools and techniques to produce a product（工具和技術來生產一種產品的組合）

paradigm（范例）：philosophy or approach for building a product 3.(P-6)

A fault: occurs when a human makes a mistake, called an error, in performing some software activities（在執行某些軟件活動）;

A failure: is a departure（偏差）from the system’s required behaviour;

Error can lead to fault；fault can lead to failure。4.participates in a project：(P-15)

Customer:

the company, organization, or person who pays for the software system Developer:

the company, organization, or person who is building the software system User: the person or people who will actually use the system

5.Activities and objects(P-16)– An activity is an event initiated by a trigger（活動是由一個觸發器的事件）– Objects or entities are the elements involved in the activities（Objects 或實體是要素參與活動的）

6.Relationships and the system boundaries(P-17)– A relationship defines the interaction among entities and activities（A 關系定義實體和活動的相互作用）

– System boundaries determine the origin of input and destinations of the output（邊界確定輸入的來源與目的地的輸出）

7.a system as a collection of things :(P-17)a set of entities(一組實體), a set of activities , a description of the relationships among entities and activities and a definition of the system.8.The development of software includes the following activities(P-24)? ? ? ? Requirements analysis and definition System design Program design Writing the programs ? Unit testing ? Integration testing ? System testing ? System delivery ? Maintenance 9.developer roles(P-26)Analyst

Designer

Programmer

Tester

Trainer 10.(P-45)A process: a series of steps involving activities, constrains, and resources that produce an intended output of some kind（一系列步驟涉及活動，受到了限制，及資源，產生一預期的輸出）

A process involves a set of tools and techniques 11.(P-46)

Software life cycle:

Implementation ,delivery ,use, and maintenance（實施、發布、使用及維修）

When a process involves building a software, the process may be referred to as software life cycle – – – – – – – Requirements analysis and definition System(architecture)design Program(detailed/procedural)design Writing programs(coding/implementation)Testing: unit, integration, system System delivery(deployment)Maintenance

12．software process models：（P-48）

Waterfall model

V model Prototyping model(原型化)Operational specification model Transformational model（轉化）

Phased development（階段化開發）: increments and iterations（反復遞增）Spiral model（螺旋模型）Agile methods（敏捷方法）

13.Prototyping is useful for verification(確認)and validation（驗證）（P-51）14.Elements of a process are viewed in terms of seven types（P-64）

Activity – Sequence – Process model 過程模型 – – – – Resource Control Policy Organization

15.Project schedule(P-83)Describes the software-development cycle for a particular project by

enumerating the phases or stages of the project(枚舉階段或項目的階段)

breaking each phase into discrete tasks or activities to be completed(每個階段分成離散任務或活動，以完成)

Portrays(描繪)the interactions(相互影響)among the activities and estimates(估算)the times that each task or activity will take

16.Activity and milestone(P-83)Activity: takes place over a period of time

Milestone: completion of an activity--a particular point in time

17.Critical Path Method(CPM)(P--87)

見作業

18.Key activities requiring personnel（P-95）

requirements analysis system design program design program implementation（實現，執行）testing training maintenance

quality assurance（保證）

19.risk（P—119）

is an unwanted event that has negative consequences(消極結果)

20.Risk impact(影響):（P--120）

the loss associated with the event與該事件關聯的損失

Risk probability(概率):

the likelihood that the event will occur事件發生的可能性

Risk control(控制):

the degree to which we can change the outcome我們可以更改結果的程度

Quantify(量化)the effect of risks：

Risk exposure =(risk probability)x(risk impact)

21.Risk management：（P--121）

risk assessment（評估）

risk control

22.（P--143）

A requirement：

is an expression of desired behaviour是所需行為的表達式 A requirement deals with ：

objects or entities，the states they can be in，and the functions that are performed to change states or object characteristics

23.Process for Capturing Requirements（P--144）

Elicitation（引入）

Analysis

Specification Validation（驗證）

////構成了software requirements specification(說明書)

24.functional requirement（P---148）

describes required behavior in terms of required activitie描述所需的活動所需的行為s Quality requirement or nonfunctional requirement describes some quality characteristic that the software must possess(擁有)

Design constraint(約束):

a design decision such as choice of platform or interface components設計的平臺或界面組件如選擇決策 Process constraint: a restriction on the techniques or resources that can be used to build the system 對技術或可用于構建系統的資源限制

25.Prioritization might separate requirements into three categories（P--152）

Essential(基本): absolutely must be met絕對需要滿足的需求

Desirable(合意): highly desirable but not necessary非常理想，但不必須的 Optional(可選): possible but could be eliminated但可能被淘汰

26.Requirements definition:（P--154）

a complete listing of everything the customer wants to achieve完整列表的客戶希望實現的一切

Describing the entities in the environment where the system will be installed

描述在將安裝在系統環境中的實體 Requirements specification:

restates（重申）the requirements as a specification of how the proposed（提出）system shall behave

27.ER diagram have three core constructs（P--158）ER 圖表有三個核心構造

An entity: depicted as a rectangle, represents a collection of real-world objects that have common properties and behaviors描述為一個的矩形表示一個實際

的對象的集合 具有公共屬性和行為

A relationship: depicted as an edge between two entities, with diamond in the middle of the edge specifying（指定）the type of relationship描述為一個兩個實體之間的邊緣

An attribute: an annotation(注解)on an entity that describes data or properties associated with the entity描述數據或與該實體相關聯的屬性的實體上的注釋

28.（P--172）

A data-flow diagram(DFD)models functionality and the flow of data from one function to another數據流關系圖 DFD 模型的功能和數據到另一個函數的流

– A buble represents a process一個 buble 表示一個流程 – An arrow represents data flow一個箭頭表示數據流量

– A data store: a formal repository(倉庫)or database of information –

Rectangles represent actors: entities that provide input data or receive the output result矩形表示參與者： 實體提供輸入的數據或接收輸出結果

–

29.(P--223)Design: is the creative process of transforming the problem into a solution The description of a solution is also known as design 是創造過程的問題轉化為解決方案的描述稱為設計

30.Design is a two-part interactive process(P—224)– Conceptual design(system design)(概念性設計)– Technical design(技術性設計)

–

31.(P—228)Modules or components: 組件

composite parts of design A system is modular when

– each activity of the system is performed by exactly one component活動的系統由一個組件執行

– inputs and outputs of each component are well-defined

? all inputs to it are essential to its function輸入其功能至關重要

? all outputs are produced by one of its actions輸出由其動作之一制作

32.Architectural Styles and Strategies Three Design Levels:(P—229)

Architecture（系統結構）

Code design

Executable design（執行設計）

33.Architectural Styles and Strategies Design Styles（P—230）

Pipes and filters(管道/過濾器)Object-oriented design Implicit invocation(隱式調用)Layering（分層設計）Repositories(數據倉庫)Interpreters(解釋器)Process control(過程控制)Client-server(客戶/服務器)

34.Component independence（P--248）

Coupling(耦合度)Cohesion(內聚度)Highly coupled when there is a great deal of dependencies Loosely coupled components have some dependency, but the interconnections among components are weak（大多數采用松散）

Uncoupled components have no interconnections at all

35.We can measure coupling along a range of dependence（P--249）

Characteristics of Good Design Coupling: Types of Coupling

Content(內容)coupling

Common(公共)coupling Control(控制)coupling Stamp(標記)coupling Data(數據)coupling 36.Exceptions can be handled in one of three ways：（P—255）異常處理

– Retry(重試)– Correct(更正)– Report(報告)

37.program component involves at least three major aspect:(P---340)

Control structures ,algorithms,and data structure 38.making the codeefficiency(效率)may have hidden costs(代價)(P--342)– cost to write the code faster – cost to test the code – cost to understand the code – cost to modify the code

39.Software Faults and Failures types of Faults(P--367)軟件故障及故障的類型的故障

Algorithmic fault算法

Computation and precision fault 計算和精度 Documentation fault Stress or overload faults Capacity or boundary faults 容量邊界 Timing or coordination faults(協調)Throughput(吞吐量)or Performance faults Recovery fault 恢復故障

Hardware and system software fault Standards and procedures fault

40.Testing Organization（P—371.）

Module testing, component testing, or unit testing(單元測試)Integration testing(集成測試)The next step is ensuring that the interfaces among the components are defined and handled properly.Performance testing(性能測試)Compares the system with the remainder of these software an hardware requirements.41.Testing steps（P--372）

42.Integration Testing集成測試（P--390）具體實例見作業

Bottom-up(自底向上)

Merging components to test the larger system

Top-down(自頂向下)

Big-bang(大棒)

Sandwich testing(多層結構測試)

Modified top-down(改性自上而下)

Modified sandwich(改性多層結構測試)

43.Principles of System Testing Regression Testing Steps（P—425）系統測試回歸測試步驟的原則

? Inserting the new code ? Testing functions known to be affected by the new code ? Testing essential function of m to verify that they still work properly整體 ? Continuing function testing m + 1

44.Types of Performance Tests（P--436）性能測試

Stress tests(壓力)Volume tests(容量)Configuration tests(配置)Compatibility tests(兼容)

Regression tests(回歸)Security tests(安全)Timing tests(響應時間)Environmental tests(環境)Quality tests(質量)Recovery tests(恢復)Maintenance tests(可維護性)Documentation tests(文檔)Human factors(usability)tests(使用)

45.Software reliability:

operating without failure under given condition for a given time interval 無故障下經營給予指定的時間間隔內的條件 Software availability:

operating successfully according to specification at a given point in time 成功經營，依法規范在指定點的時間 Software maintainability:

for a given condition of use, a maintenance activity can be carried out within stated time interval, procedures and resources 為給定的使用條件，維護活動可以內進行既定的時差 過程資源

注意：作業是重點，必考！這個翻譯（長字段的）僅供參考，要結合軟件工程的角度加以分析理解！

第四篇：軟件工程復習重點總結

第一章

軟件過程：需求設計實現發布

軟件過程三要素: 過程+方法+工具

瀑布rup scrum Iconix

Scrum是一種迭代式增量軟件開發過程，通常用于敏捷軟件開發。Product Owner、Scrum Master、Team Product Backlog、SprintBacklog、Burndown Chart、Sprint、Sprint Planning Meeting、Daily Standup Meeting、Review Meeting、Retrospective Meeting ICONIX軟件開發過程

愿景、業務建模、需求分析、健壯性分析、系統設計??

思想是重點；過程是方式；方法和工具是載體

第二章

敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。敏

捷是一種思想?Scrum是一個框架

敏捷開發過程知多少？

?Scrum、?極限編程（XP）、?Crystal Methods（水晶方法族）

?特性驅動開發（FDD）

?動態系統開發（DSDM）

?輕量型統一過程（RUP）

調查結果：敏捷開發方法—Scrum最流行！

Scrum的適用場景

?7人，+or-2

?偏小一些會更適合?最好能坐在一起

?客戶參不度高

?快速移動互聯網項目

?自主性研發的產品

第三章

軟件項目是為了改善某個組織的某些方面

–老大就是要改善的組織中最有權力的干系人。

用戶建模四步曲列出盡可能多的用戶識別關鍵用戶（購買決策者/主要使用者）分類，合并次要用戶

4添加虛擬和極端用戶

第四章

?產品backlog是Scrum的核心

產品功能列表格式

?ID（標示符）

–統一標識符

?Name（標題）

–簡短的、描述性的故事名

?Story（故事）

–故事內容描述

?Priority（重要性）

–產品負責人評出一個數值，指示這個故事有多重要

?Initial estimate（初始估計）

–團隊的初步估算，表示不其他故事相比，完成該故事所需的工作量

?How to demo（如何做演示）

–它大略描述了這個故事應該如何在sprint 演示上進行示范

?Notes（注解）

–相關信息、解釋說明和對其它資料的引用等等

產品功能列表由誰來寫？

?思考：由誰來寫？

–主要是Product Owner

–Team也有權利，但最終由PO進行取舍。

用戶故事是一種敏捷的需求挖掘方式，其側重點不是將需求書寫出來，而是將需求討論出來。

按“作為一個??，可以??，以便??”樣式和思路寫成的用戶需求，就是用戶故事。

用戶故事的三個變量

范圍，重要性，估算

好故事的準則

?獨立的（Independ）

?可討論的（Negotiable）

?對用戶戒客戶有價值的（Valuable）

?可估計的（Estimatable）

?小的（Small）

?可測試的（Testable）

Sprint會議如何迚行

–確定Sprint目標及長度

–講解Story、估算時間、任務分解

–決定 sprint 要包含的故事

–一些其他問題

第六章

什么是界面原型

?界面原型指使用工具根據客戶需求及軟件分析人員的理解，將頭腦中的界面快速的反映到介質上。

界面原型的目的?盡早驗證需求

?盡早明確不確定性的因素

?方便溝通交流

?為后續界面設計提供基礎

第八章

ICONIX過程

?ICONIX過程的規模介于RUP和XP之間

?適合中小型的、需求相對明確的軟件項目

?ICONIX核心思想

?開源！節流！

ICONIX軟件過程是用例驅動的軟件過程。

ICONIX過程中的第一步：明確愿景

?愿景是確保項目成功的第一步；

?愿景必須來自老大；

?愿景必須是可度量。

如何獲取軟件項目的愿景

?獲取軟件項目愿景的三步曲：

?第一步：找到軟件項目的“老大”；

?第二步：得到“老大”對項目的期望（愿景）；

?第三步：描述出愿景的度量指標；

要點：系統要改善哪個組織的流程？

老大就是要改善的組織中最有權力的干系人

第九章

業務建模的目的：從組織的角度來定位系統的價值。

業務建模

?業務建模的目的是把視角從系統轉向組織，站在客戶角度看問題。

?業務用例是對組織為外部業務執行者提供的價值的建模。

?現狀業務序列圖是對組織價值內部實現流程（業務工人與業務實體的協作）的建模 ?改迚業務序列圖是對新系統為組織提供的改良的建模。

業務建模的步驟：

1.明確我們為誰服務（選定愿景要改進的組織）。

2.要改進的組織是什么現狀（業務用例圖、現狀業務序列圖）。

3.我們如何改進（改進業務序列圖）。

第十章

域建模的步驟

第一步：提取名詞或名詞短語

第二步：排除重復、相似

第三步：排除系統范圍外

第四步：畫出第一版域模型圖

第五步：整理第一版域模型

域模型之間的關系

?泛化[Generalization]，一般元素和特殊元素的關系。

?關聯[Association]，兩個類乊間存在著某種語義上的聯系。

系統需求分析的目的是把視角轉向新系統，站在最織

用戶（及其它干系人）的角度看問題。

?系統用例是對（新）系統為系統執行者提供的價值的建模

系統用例建模步驟

1.繪制系統用例圖

2.編寫系統用例描述

3.更新域模型

繪制系統用例圖

1.確定系統邊界

2.識別系統執行者

3.識別系統用例

4.確定用例間的關系

用例描述的作用

?用例圖描述總體，用例文檔描述紳節。

?每個用例必須對應有用例描述。

用例描述的基本組成?干系人利益

?基本路徑

?擴展路徑

?業務觃則

軟件產品的典型非功能性需求(RUPS)

?可靠性[Reliability]。

?可用性[Usability]。

?性能[Performance]。

?可支持性[Supportability]。

需求獲取的方法

?研究文檔。

?問卷調查。

?訪談。

?觀察。

?研究競爭對手。

需求分析結果復核

?形式：面對面會議。

?參會人：甲乙雙方在需求分析階段的主要參與者。

?被審材料：域模型、用例圖、用例描述、非功能性需求；

?過程：需求分析師主持，最終需求分析成果，所有參與者交流討論，達成統一理解和確認。?結論：所有參與者簽字確認。（當然，也有可能是未達成共識，需要返工。）

?注意：后續的工作基本不需要用戶的參不了。

第十一章

健壯性分析的步驟

第一步：創建一個空的健壯性圖。

第三步：從基本路徑的第一句話開始畫健壯性圖。

第二步：直接將用例文本粘貼到圖上（基本路徑和擴展路徑）。

第四步：貫串整個用例基本路徑，一次一個句子，畫執行者、適當的邊界對象和實體對象以及控制器，和各元素乊間的連線。

第五步：將每一個擴展路徑畫在健壯性圖上，并以紅色標示出。

在用例驅動的開發模式中，用例的準確完整性是關鍵；

?健壯性分析技術兩個主要的價值：其一幫助完善用例分析結果；其二完善域模型，做為需求分析走向系統設計的過度技術；

?丌要花費太多的精力和時間在本階段，本階段的成果也僅起到過度作用，不納入最終文檔； 第十二章

關鍵設計是功能性需求的設計，成果為類圖和序列圖；

?關鍵設計還沒考慮真實實現的平臺相關因素，因此不能基于這個階段的設計成果開始編碼； ?關鍵設計的方法就是在域模型、用例描述和健壯性分析的基礎上，迭代生成類圖和序列圖；

關鍵設計的步驟

?第一步：將現有的域模型直接作為第一版靜態類模型；

?第二步：基于用例描述和健壯性分析結果，畫出每個用例的序列圖；

?健壯性圖中的控制類會轉化為方法；

?如果也轉化為控制類，那么就添加到類圖中（注意：邊界類丌添加到類圖中）； ?第三步：整理靜態類圖和序列圖；

?第四步：關鍵設計復核，迭代更新用例圖、類圖和序列圖；

高內聚、低耦合。是判斷設計好壞的標準。

關鍵設計復核的指導建議

?確保關鍵設計的“如何做”和需求階段的“做什么”匹配。也就是說每個用例都要和序列圖匹配，包含了用例的基本流程和分支流程。

?復核設計的品質。應該至少有一個設計與家在場。

?檢查消息的連貫性。檢查時序圖上消息箭頭的指向，有時我們會發現對象乊間缺少消息而造成跳躍，我們必須消除這些邏輯跳躍。

?確保方法分配給了適當的類，類視圖中的每一個類擁有適當的方法和屬性。

第五篇：軟件工程重點整理

可以把軟件開發的本質概括為：不同抽象層術語之間，以及不同抽象層處理邏輯之間的映射 需求分析產生的正式文檔是需求規約

在結構化分析方法中，表示“數據的靜態結構”的術語是數據存儲

對模塊的寬度影響最大的因素是模塊的扇出 下列術語，可用于抽象客觀世界中事物的是類

大學由若干專業系構成，則大學與專業的關系是組合

下列軟件測試技術中，依據程序邏輯結構的是白盒測試技術 單元測試期間，通常考慮模塊的重要的執行路徑

軟件基本過程指那些與軟件生產直接相關的活動集，可分為供應過程、開發過程、運行過程、維護過程和獲取過程

在常見的軟件開發模型中，適用于項目的開發風險很大或客戶不能確定系統需求的模型是螺旋模型

CMMI 能力等級中的 3 級是已定義級

軟件生產率、軟件質量滿足不了社會發展的需求，并成為其發展的制約因素，這一現象被稱為軟件危機

對于單一的一個需求，必須具有的基本性質：必要的、無歧義的、可測試的、可跟蹤的以及可測量的。

需求規約的基本性質包括重要性和穩定性程度、可修改的、完整的和一致的

在結構化分析方法中，可采用結構化自然語言、判定表和判定樹描述加工

用于定義數據流圖包含的所有數據流和數據存儲的數據結構，直到給出構成以上數據的各數據項的基本數據類型的工具是數據字典

在 UML 中，用于描述關聯的一定“內涵”的術語是關聯名 RUP 利用 UML 提供的術語和工具定義了需求獲取層、系統分析層、設計層和實現層，并給出了實現各層模型之間映射的基本活動以及相關的指導

軟件測試是一個有程序的過程，包括測試設計、測試執行以及測試結果比較等

由于軟件錯誤的復雜性，在軟件工程測試中，應綜合運用測試技

術，并且應實施合理的測試序列：

單元測試、集成測試、有效性測試和系統測試

《IS0/IEC 軟件生存周期過程 12207—1995》標準按過程主體把軟件生存周期過程分為基本過程、支持過程和組織過程 針對開發的 CMMI 是一個有關產品和服務的過程改善的成熟度模型，集成了 3 個源模型：軟件 CMM、系統工程 CMM和產品集成開發 CMM

CMMI 中，遵循一個過程可達到的預期結果的程度是指過程能力

CMMI 模型基于過程途徑思想，通過過程把軟件質量的 3 個支撐點：受訓的人員、規程和方法、工具和設備進行集成，以開發所期望的系統/產品

請簡述計算機軟件的概念以及提出軟件工程概念的目的

（1）計算機軟件一般是指計算機系統中的程序及其文檔（2）其中，程序是計算機任務的處理對象和處理規則的描述（3）文檔是為了理解程序所需的闡述性資料（4）軟件工程概念的提出，其目的是倡導以工程的原理、原則和方法進行軟件開發，以解決出現的軟件危機。

請簡述初始發現需求的常用技術（1）自悟（2）交談（3）觀察（4）小組會（5）提煉

請敘述信息隱藏的概念及其意義

（1）信息隱藏是指在每個模塊中所包含的信息不允許其他不需要這些信息的模塊訪問（2）它是實現模塊低耦合的一種有效途徑（3）但是，如果一個模塊是“絕對”信息隱藏的，那么這種模塊對系統而言是毫無意義的

什么是驗證和確認？請敘述它們的區別

（1）驗證就是證實一個過程或項目的每一軟件工作產品/服務是否正確地反映了所規約的需求（2）確認就是證實所期望使用的軟件工作產品是否滿足其需求（3）區別：驗證是通過提供的客觀證據，證實規約的需求是否得以滿足；確認是通過提供的客觀證據，證實有關特定期望的使用或應用的需求是否得以滿足