軟體工程期末總結

今天視訊看完了，可是沒有總結。還是感覺不會總結。一想到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 大知識體系：專案整合管理、專案範圍管理、專案時間管理、專案費用管理、專案質量 管理、專案人力資源管理、專案溝通管理、專案風險管理、專案採購管理。