軟件工程期末總結

今天視頻看完了，可是沒有總結。還是感覺不會總結。一想到50講的課，怎麼總結呢？開始聽的時候，是真不知道從哪裏下手，因為開始看的時候有種迷迷糊糊的感覺。軟件工程，我期待的一門課就這麼聽完了一遍。很有些囫圇吞棗的感覺，不過收穫還是很多的，至少知道了軟件工程的階段不是隻有需求分析、編程和測試維護。當然這個很早之前就知道，只是以前根本沒有什麼概念。

第一個階段，計劃階段，要首先對用户的要求進行了解，對軟件的性能等進行了解。然後進行可行性分析研究，在各種可行性研究中，對於軟件開發人員來説，技術可行性研究最重要。之後就是需求分析階段了，需求分析階段也是計劃階段的最後一部分。需求分析定義了要做什麼。把現實的需要用程序語言表達出來。但是這一階段並不解決怎麼做。

解決怎麼做的是下一個階段——設計階段。設計階段分為概要設計和詳細設計。概要設計把每個組成部分的功能都給出意義明確的模塊，每個模塊都和一部分需求相對應。但是不考慮細節。詳細設計，把每個模塊的功能實現詳細的表示出來，為源程序的編寫打下基礎。然後就是編程階段，我們一般最初接觸的就是編程，所以編程階段比較瞭解，由於前期文檔已經做的很詳細，功能的實現數據和算法都已經清楚了，所以編程是比較簡單的。

編程完了就是測試階段了，測試階段的費用是最多的。測試階段是發現錯誤的階段，改錯是調試階段。然後就是交付用户使用，及維護。

以上幾點是軟件工程的生命週期的六個階段。軟件工程過程和軟件工程生命週期也不能等同。

軟件工程過程如下：

軟件規格説明：規定軟件的功能及其運行的限制

軟件開發：產生滿足規格説明的軟件：

軟件的確認：確認軟件能夠完成客户提出的要求：

軟件演進：為滿足客户的變更要求。軟件必須在使用的過程中演進。

pdca

軟件工程過程與軟件生存期相對應。軟件規格説明對應計劃階段，軟件開發對應設計、編程階段，軟件的確認對應測試調試階段，軟件演進對應運行維護階段。

軟件開發的每個過程都有相關文檔，用老師們的話説叫做以文檔為驅動。文檔的好壞直接影響到軟件開發的進度和軟件的質量。而文檔中最多的是使用圖表，dfd圖，sc圖。數據流程圖、過程流程圖、系統流程圖等各種圖表。還是那句話，一張好的圖表勝過一千句話。

在軟件生存週期的各個部分都有各自要注意的地方，過着説是各自的重點（或者是知識點）。

今天已經是22號了，文檔還沒寫。先寫文檔了。唉，又落後了。

軟件工程期末總結 [篇2]

第一章 概述

1.什麼是軟件：

計算機軟件是指與計算機系統操作有關的程序、 規程、 規則及任何與之有關的數據和文檔 資料。

2.軟件三要素： 3.軟件的特點：

1 軟件是邏輯實體，始終不會自然變化，只是其載體可變，它並不是物理實體； 2 軟件是一種創造性的思維活動 3 軟件是可以長期運行的，它不會因時間長短而磨損、老化 4 軟件

的研製過程主要是腦力勞動的過程，在本質上是無形的、不可見的和難以控制的 5 程序是指令序列，即使每條指令都正確，但由於在執行時其邏輯組合狀態千變萬化，其 不一定完全正確 6 軟件中系統的數學模型是離散型的， 其輸入在合理範圍內微小的變化可能引起輸出的巨 大變化， 7 對軟件的生產過程進行嚴格的控制，可得到完全一致的產品 8 軟件中不可靠的問題基本是由於開發過程中的人為差錯所造成的缺陷而引起的 9 軟件在使用過程中出現故障後，必須修改原產品以解決問題，若修改時未引起新問題， 其可靠性就會增長 10 軟件維護通常涉及軟件更改，軟件更改通常會對其他部分造成影響 11 軟件的宂餘設計應確保宂餘軟件相異，否則不僅不能提高可靠性反而增加複雜性，降 低可靠性

4.軟件的分類：

按功能：系統軟件、支撐軟件 按工作方式：實時處理軟件、嵌入軟件 按規模：小型程序、中型程序、大型程序 按使用頻度：常用軟件、不常用軟件 按服務對象：專用軟件、通用軟件 按軟件失效性：一般性軟件、高可靠性軟件

5.軟件工程：是指導計算機軟件開發和維護的工程學科 6 軟件工程的三要素：過程、工具、方法 7.軟件工程的目標、原則 目標：

付出較低的開發成本 達到要求的軟件功能 取得較好的軟件性能 開發的軟件易於移植 需要較低的維護費用 能按時完成開發任務 及時交付使用 開發的軟件可靠性高

原則：抽象、信息隱蔽、模塊化、局部化、一致性、完全性、可驗證性 8.產生軟件危機的原因：

用户對軟件需求的描述不精確，可能有遺漏、有二義性、有錯誤

軟件開發人員對用户需求的理解與用户本來的願望有差異 大型軟件項目需要組織一定的人力共同完成， 多數管理人員缺乏開發大型軟件系統的 經驗，而多數軟件開發人員又缺乏管理方面的經驗 軟件項目開發人員不能有效地、 獨立自主地處理大型軟件的全部關係和各個分支， 因 此容易產生疏漏和錯誤 缺乏有力的方法學和工具方面的支持， 過分地依靠程序設計人員在軟件開發過程中的 技巧和創造性，加劇軟件產品的個性化 軟件產品的特殊性和人類智力的侷限性，導致人們無力處理“複雜問題”

第二章 過程與生命週期

1.生命週期定義：軟件從定義開始，經過開發、使用和維護，直到最終退役的全過程。 2 三個階段：軟件定義、軟件開發、軟件運行維護 3.每個階段有哪些步驟：

軟件定義：可行性研究、需求分析 軟件開發：概要設計、詳細設計、實現、集成測試、確認測試 軟件運行維護：使用與維護、退役

4.每個步驟的主要內容： 5.模型有哪些

以軟件需求完全確定為基礎的瀑布模型； 在開發初期僅給出基本需求的漸進式模型，如原型模型、螺旋模型、v 模型等； 基於知識的智能模型等等。

6.模型各自的特點

瀑布模型：適用於需求明確的小型系統的開發 體現了推遲實現的觀點 前一個階段的結束是下一個階段的開始 沒個階段要形成相應的文檔，並對文檔進行復審 （線性順序模型） 原型模型：快速開發工具 循環 低成本 種類：漸進型和拋棄型 增量模型： （是核心部分產品） 每個增量的開發可用瀑布或快速原型模型。 和原型模型不一樣的是，增量模型雖然也具有“迭代”特徵，但是每一個增量都發布 一個可操作的產品，不妨稱之為“產品擴充迭代”。它的早期產品是最終產品的可拆 卸版本，每一個版本都能夠提供給用户實際使用。 螺旋模型：沿螺線自內向外每旋轉一圈便開發出更為完善的一個 新的軟件版本。 對於高風險的大型軟件， 螺旋模型是一個理想的開發方法。 半徑與風險成反比 半徑與成本成正比 v 模型：是瀑布模型的一種變體

第三章 可研

1.什麼是可研：就是按照各種有效的方法和工作程序，對擬建項目在技術上的先進性、

適用性、經濟上的合理性、盈利性，以及項目的實施等方面進行深入的系統分析，並評 論總體方案（系統目標）的可能性，必要性。

2.可研的內容：

技術可行性 經濟可行性 操作可行性（組織管理可行） 社會可行性（法律可行性） 抉擇

3.可研報告如何編寫

簡要步驟： ①定義問題，分析問題，導出試探性的'解法。 ②複查、改進所提出的解法，並確定解法。 ③提出符合系統目標的高層邏輯模型。 ④設想出各種可能的物理系統。 ⑤從技術、經濟和操作等各方面，分析物理系統的可行性。 ⑥提出一個推薦的行動方針，提交用户和使用部門負責人審批 詳細步驟： (1)複查確認系統目標、規模 ①訪問關鍵人員②閲讀有關材料③確認問題及約束條件 (2)研究目前正在使用的系統工作流程 ①實地考察 ②閲讀系統有關的文檔資料和使用手冊 ③ 瞭解系統能做什麼,不能做什麼。 ④ 理解、記錄系統的接口 (3)導出新系統高層邏輯模型 在瞭解目標系統應具有的基本功能和約束的基礎上， 用數據流圖和數據字典， 定義新系統的 高層邏輯模型，以描述對新系統的設想。 (4)重新定義問題 與用户一起確認系統的邏輯模型，直到與用户達成共識 (5)導出和評價供選擇的解決方案 提出若干個比較抽象的解決方案，然後從技術、經濟、操作等 方面進行評價。 (6)推薦可行的方案 ① 確定是否繼續項目。? ② 選擇一種最好的方案，並説明理由。 (7)草擬開發計劃 ①工程進度表 ②所需的開發人員、資源 ③成本 (8)編寫可行性研究報告，送審 可行性分析報告（供用户和使用部門的負責人審查、決策）

第四章 需求

1.需求：是指用户對目標軟件在功能、行為、性能、設計、約束等方面的期望 2.需求的分類、內容有哪些：

分類： 功能性需求：定義了系統做什麼（描述系統必須支持的功能和過程） 非功能性需求 （技術需求） : 定義了系統工作時的特性 （描述操作環境和性能目標） 內容：功能、性能、環境、界面、用户或人的因素、文檔、數據、資源、安全保密、軟件 成本消耗與開發進度、質量保證

優秀的需求所具有的特性：完整性、正確性、可行性、必要性、劃分優先級性、無二義性、 可驗證性

3.獲取需求的方法：採用原型、訪談、問卷調查、參與用户工作、參考遺留系統 4.分幾個階段：問題分析 、需求描述 、需求評審 5.需求分析報告如何編寫： （p47）

（應該先了解宏觀的問題，再瞭解細節的問題） 引言、任務概述、需求規定、運行環境設定、縮寫詞表、參考文獻

的基本元素：數據流、加工、文件、源頭或終點 7.如何畫： （思想：抽象與自頂向下的逐層分解）和掌握 pdl 語言

瞭解 dfd 的特性：只描述數據的流動、dfd 分成多層(子圖、父圖概念)表示, 從而逐步展 開數據流和功能的細節

8．面向對象以及 uml 面向對象的幾個主要概念 ：對象、屬性、操作 類、封裝、繼承 消息、關係、多態

對象：一個對象就是一個獨立存在的客觀事物，它由一組屬性和對屬性進行操 作的一組操作構成。 屬性和操作： 屬性是對象靜態特徵的描述， 操作是對象動態特徵的描述。 對 象 同時具備靜態特徵和動態特徵。 類：是具有相同屬性和相同操作 （服務）的對象的集合。它包括屬性和操作（注： 類的服務和操作只是叫法上的區別） 。 封裝：封裝是指按照信息屏蔽的原則，把對象的屬性和操作結合在一起，構成 一 個獨立的對象。封裝的作用在於，它保護了類的具體實現，隱藏了用户無需關心 的 細節， 同時對用户體現出來相同的接口 （即操作方法） ， 從而提高了可複用性。 繼承：繼承表達了對象的一般與特殊的關係。特殊類的對象具有一般類的全部屬 性和服務 消息：向某個對象發出的服務請求稱作消息。 結構與連接關係：一個系統一般由很多對象組成，對象之間並不是互相孤立的， 而是存在着各種各樣的關係。這些關係可以分為：部分與整體的關係、一般與特 殊的關係、實例連接的關係、消息連接的關係。 多態性 ： 多態性是指一般類中定義的屬性和服務，在特殊類中不改變其名字， 但通過各自不同的實現後，可以具有不同的數據類型或具有不同的行為。

9. 9 中 uml 圖是幹什麼的，每種圖的基本元素準確識別

uml 的組成：基本構造塊 事物、圖、關係 ? 公共機制 ? 規則 用例圖（use case diagram） ：描述系統功能； 類圖（class diagram） ：描述系統的靜態結構； 對象圖（object diagram） ：描述系統在某個時刻的靜態結構； 時序圖（sequence diagram） ：按時間順序描述系統元素間的交互 協作圖（collaboration diagram） ：按照時間和空間順序描述系統元素間的交互和它 們之間的關係； 狀態圖（state diagram） ：描述了系統元素的狀態條件和響應； 活動圖（activity diagram） ：描述了系統元素的活動； 構件圖（component diagram） ：描述了實現系統的元素的組織; 部署圖（deployment diagram） ：描述了環境元素的配置，並把實現系統的元素映射

到配置上。

圖中的關係（組合、聚合、泛華|繼承、依賴、實現、包含、擴展）

泛化：泛化關係也稱為繼承關係，這種關係意味着一個元素是另一個元素的特例 依賴：表示一個元素以某種方式依賴於另一個元素 實現：實現關係描述一個元素實現另一個元素 聚合：表示“整體”與“部分”關係，“部分” 元素是 “整體”元素的一部分 組合：表示強烈的”整體“與”部分“關係，”部分“不能獨立於”整體“存在。 包含：包含是指基本用例(base use case)會用到包含用例(inclusion)，具體地講，就是將包 含用例的事件流插入到基礎用例的事件流中。 包含用例是可重用的用例──多個用 例的公共用例。 擴展：擴展用例的行為是否被執行要取決於主事件流中的判定點

11.類圖與程序的互相轉換；識別類圖以及關係

類圖主要描述系統中類的靜態結構。 在類圖中不僅需要定義系統中的類， 詳細表示類的 內部結構，如類的屬性和方法。另一方面還需要詳細表示類與類之間的聯繫，如關聯、依 賴、聚合等。類圖描述的是一種靜態關係，在系統的整個生命週期都是有效的。 識別類圖： 識別實體類：實體類都是系統中存在的對象，我們可以分析人員、組織、設備、事件和外 部系統等 識別邊界類：關注系統的邊界：系統的硬件接口（打印機、窗體等） ，每個參與者與用例 的交互。 識別控制類：關注用例圖中的動詞及事件。 關係：類、關聯、接口、依賴、泛化、實現關係。

第五章 設計

1.設計分幾個階段：從工程管理角度來看分為：概要設計和詳細設計 2.概要設計（總體設計） ：根據軟件需求，設計軟件系統結構和數據結構，確定程序的組

成模塊及模塊之間的相互關係。概括地説， “系統應該如何實現？”

3 詳細設計（過程設計） ：確定模塊內部的算法和數據結構；選定某種過程的表達形式來

描述各種算法； 產生精確描述各模塊程序過程的詳細文檔，並進行評審。

4.設計的主要內容：體系結構設計、模塊設計、數據結構與算法設計、用户界面設計

如何編寫總體設計： 1）軟件的總體結構和模塊外部設計。 2）軟件處理流程設計。 2） 確定軟件的功能並分配。 3） 數據結構設計。 4） 網絡及接口設計。 5） 運行設計。 7）出錯處理設計。 8）性能可靠性及安全保密設計。 9）維護設計。

5.設計原理：模塊化、抽象、逐步求精、信息隱蔽和局部化、模塊獨立 6.模塊獨立性 7 耦合 7 內聚（思想：採取自頂向下的方式，逐層把軟件系統劃分成若干

可單獨命名和可編址的部分－ “ 模塊”每個模塊完成一個特定的子功能；所有模塊按某種 方法組成一個整體，完成整個系統所要求的功能。 （軟件系統就是通過這些模塊的組合來實

現。 ） 衡量模塊獨立性的兩個準則：耦合性和內聚性 設計要求：低耦合，高內聚 改進原則：高內聚、低耦合 耦合：無直接耦合、數據耦合、控制耦合、外部耦合、特徵耦合、公共環境耦合、內容 耦合 內聚：功能內聚、順序內聚、通訊內聚、過程內聚、時間內聚、邏輯內聚 、偶然內聚

7.別結構化設計的基本結構過程的設計工具：圖形、表格、語言 8.讀懂程序流程圖、盒圖、pad 圖、判定表、pdl，會使用

程序流程圖、n-s 圖、pad 圖都不易清楚的描述含有多重嵌套的條件選擇。判定表 可以清晰的表示複雜的條件組合與其對應的處理之間的關係。

第六章 編碼

1.編碼的內容：程序設計語言、結構化程序編程、編程的標準和原則、編程風格、程序效

率

2.編碼的基本結構、原則、風格

結構：順序、選擇、循環 原則：編寫易於修改和維護的代碼、編寫易於測試的代碼、編寫詳細的程序文檔、編程 中採用統一的標準和約定，降低程序的複雜性、分離功能獨立的代碼塊，形成新的模塊 風格：從軟件工程學的角度：體現在程序代碼邏輯清晰，易讀、易理解、易維護，能高 效利用系統資源等各個方面。編碼風格強調“清晰第一”

第七章 測試

1.為什麼測試

通過軟件測試，可以發現軟件中絕大部分潛伏的錯誤，從而可以大大提高軟件產品的正確 性、可靠性，進而可顯著提高產品質量。

2.測試的過程

3.黑白盒以及分類，每種類別的含義

動態測試（程序執行） ： 黑盒（測試功能）和白盒（測試結構） 測試種類：功能測試、接口測試、健壯性測試、強度測試、壓力測試、性能測試、用 户界面測試、安全測試、可靠性測試、安裝/反安裝測試、文檔測試、恢復測試、兼容 性測試、迴歸測試、α 測試、β 測試 ? 靜態測試是採用人工檢測和計算機輔助靜態分析的方法對程序進行檢測。主要檢測 變量是否用錯、參數是否匹配、循環嵌套是否有錯、是否有死循環和永遠執行不到 的死代碼等等。同時，它還可對程序的特性進行分析。 ? 動態測試是指事先設計好一組測試用例，然後通過運行程序來發現錯誤。 ? 黑盒測試，又稱為功能測試——把被測的程序模塊看成一個黑匣子，即完全不考慮 程序的內部結構和處理過程，測試僅在程序的接口上進行。按規格説明書要求的輸 入數據與輸出數據的對應關係設計測試用例，是根據程序外部特徵進行測試。 ? 白盒測試——把被測的程序看成一個透明的白匣子，即完全瞭解程序的內部結構和

詳細的處理過程，測試是在程序的內部結構上進行。即要求針對每一條邏輯路徑都 要設計測試用例，檢查每一個分支和每一次循環的情況。

4.軟件缺陷的集羣現象：

第八章 維護

1.維護：指在軟件運行/維護階段對軟件產品所進行的修改，就是所謂的維護。 2.維護的分類（區別、識別） ：糾錯性維護、適應性維護、改善性維護/擴充與完善性維

護、預防性維護 每種類的含義： 糾錯性維護：為改正軟件系統中潛藏的錯誤而進行的活動。 適應性維護：為適應軟件運行環境的變化而修改軟件的活動。 改善性維護：根據用户在軟件使用過程中提出的建設性意見而進行的維護活動。 預防性維護（軟件再工程） ：為了進一步改善軟件系統的可維護性和可靠性，併為以後 的改進奠定基礎。預防性維護可以採取逆向工程和重構工程方式

3.維護的副作用：代碼副作用、數據副作用、文檔的副作用

代碼副作用大多數可在迴歸測試中發現。 數據副作用是由於修改數據結構帶來的副作用。設計文檔化有助於抑制數據副作用， 由於程序修改而沒有對文檔進行相應的修改引起文檔的副作用。 必須保持文檔和程序的 一致性

第九章 項目管理

1．項目：是為提供某項獨特產品、服務或成果所做的臨時性努力。 2.三要素：時間、質量、費用 3.特點：臨時性、獨創性、漸進明細 4.項目組織結構：職能型、項目型和矩陣型組織結構類型 5. 5 大過程 9 大知識：

5 大過程：啟動、計劃、執行、控制、結束過程 9 大知識體系：項目集成管理、項目範圍管理、項目時間管理、項目費用管理、項目質量 管理、項目人力資源管理、項目溝通管理、項目風險管理、項目採購管理。