文章目錄

• 六、軟件設計
• • 1、目標
  • 2、軟件設計過程
  • • 概要設計
    • • 動態結構設計
      • 靜態結構設計
    • 詳細設計
  • 3、軟件設計模型
  • 4、模塊內聚性
  • 5、模塊耦合性
  • 6、面向對象的設計原則
  • • 單一職責（Single Responsibility）
    • 開閉原則（Open Closed）
    • 里氏替換原則（Liskov Substitution）
    • 依賴倒置原則（Dependency Inversion）
    • 接口隔離原則（Interface Segregation）
    • 組合/聚合復用（Composite/Aggregation Reuse）
    • 迪米特法則（Law of Demeter）
  • 7、軟件設計基礎
• 七、面向對象設計
• • 1、綜述
  • 2、軟件的層次化結構
  • 3、類職責分配（Grasp）模式
  • • 控制器（Controller）模式
    • • 指導原則
    • 創建者(Creator)模式
    • 信息專家（Information Expert）模式
• 八、結構化軟件設計
• • 1、系統功能結構圖
  • • 基本結構
    • 變換型結構
    • 事務型結構
    • 變換-事務混合型結構
    • 確定系統邊界
  • 2、變換映射
  • 3、事務映射
  • 4、詳細設計
  • • 程序流程圖
    • N-S圖
    • PAD圖
    • 判定表
• 九、軟件測試
• • 1、軟件測試的目的和原則
  • • 目的
    • 原則
    • 軟件測試對象
    • 流程
    • 軟件測試與各階段關系
  • 2、測試方法
  • • 白盒測試
    • • 邏輯覆蓋
      • 程序控制流圖
      • • 舉例
    • 黑盒測試
    • • 等價類劃分
      • • 舉例
      • 邊界值分析
      • 因果圖
      • • 舉例
  • 3、軟件測試基本類型
• 十、剩余章節
• • 1、軟件維護
  • • 定義
    • 分類
    • 軟件維護的活動
  • 2、軟件項目管理
  • • 定義
    • 項目管理過程

六、軟件設計

1、目標

• 根據軟件需求分析的結果，設想并設計軟件，即根據“目標系統”的邏輯模型確定“目標系統”的物理模型，概括地描述系統如何實現用戶所提出來的功能和性能等方面的需求。
• 軟件設計是軟件開發的基礎和依據，是軟件工程過程中的技術核心。
• 軟件設計的最終目標是要取得最佳方案（Best Solution，主觀）。
  • “最佳”是指在所有候選方案中，就節省開發費用，降低資源消耗，縮短開發時間的條件，選擇具有較高的生產率、較高的可靠性和可維護性的方案。

2、軟件設計過程

軟件設計是一個把軟件需求變換成包含軟件功能模型、數據模型以及行為模型的過程，分為概要設計和詳細設計。

• 系統結構設計：定義了軟件系統各主要元素（主要指功能模塊）之間的關系，其中包括軟件的模塊接口設計；
• 數據設計：將軟件各模塊所需要處理的數據以及系統需要長久保存的數據進行數據結構和數據存儲的設計；
• 過程設計：主要是確定各功能模塊內部結構的詳細定義，包括模塊主要算法邏輯和局部數據結構的定義。

概要設計

概要設計：只需描繪出可直接反映功能、數據、行為需求的軟件總體框架。

動態結構設計

• 用例實現過程設計，針對用例對應的 SSD 中的每個系統事件，運用 UML 的順序圖 / 協作圖給出符合該系統事件定義的操作契約的內容；
• 如果軟件對象具有多種不同的職責（主要考慮對應于不同的用例）的情況下，需要運用狀態圖對該軟件對象進行狀態遷移的設計。

靜態結構設計

• 對所有用例或者子系統級別的用例的交互圖進行歸納，運用 UML 的類圖給出系統的靜態結構。

詳細設計

詳細設計：即過程設計，通過對軟件結構進行細化，得到各功能模塊的詳細數據結構和算法，使得功能模塊在細節上非常接近于源程序的軟件設計模型。

3、軟件設計模型

由兩個部分構成：

• 動態結構設計：以某種方式表示功能響應客戶請求時處理數據的過程或條件，用于進一步解釋軟件結構中各功能之間是如何協調工作的機制。

• 靜態結構設計：由軟件的功能結構和數據結構組成，展示軟件系統能夠滿足所有需求的框架結構。

4、模塊內聚性

信息隱藏：每個模塊的實現細節對于其他模塊來說是隱藏的。就是說，模塊中所包含的信息（包括數據和過程）不允許其他不需要這些信息的模塊使用。

內聚是模塊功能強度的度量，一個模塊內部各元素之間的聯系越緊密，則它的內聚性就越高，相對地，它與其他模塊之間的耦合性就會減低，而模塊獨立性就越強。

• 巧合內聚
• 邏輯內聚
• 時間內聚（經典內聚）
• 過程內聚
• 通信內聚
• 信息內聚
• 功能內聚

5、模塊耦合性

耦合性：是模塊之間的相對獨立性（互相連接的緊密程度）的度量。

• 內容耦合
• 公共耦合
• 外部耦合
• 控制耦合
• 標記耦合
• 數據耦合
• 非直接耦合

降低耦合性的方法：

模塊間多傳遞數據信息，盡量減少和避免傳送控制信息。

降低模塊接口的復雜性。

減少接口信息傳送數量。

以系統調用方式（或 call 方式）代替直接引用。

傳送信息的結構盡量簡單（或以數據耦合代替標記耦合）。

把模塊的通信信息放在緩沖區中。

6、面向對象的設計原則

單一職責（Single Responsibility）

定義：針對類，應該只有一個引起它變化的原因，“職責”定義為變化的原因

• 如果有其他原因去改變一個類，那么這個類就具有其他的職責。類具有多個職責，等于這些職責具有耦合關系。
• 為了提高類的內聚度，應將對象的不同職責分離至兩個或多個類中，確保引起該類變化的原因只有一個。

開閉原則（Open Closed）

軟件實體（類、模塊、函數）可以擴展，但不能修改。

• 對于擴展是開放的（Open 4 extension），需求改變時，對實體進行擴展。
• 對于更改是封閉的（Closed 4 modification），需求改變時，禁止對原來的代碼進行修改。
• 實現 OCP 的關鍵是使用抽象，識別不同類之間的共性和變化點，利用封裝對變化點進行處理

里氏替換原則（Liskov Substitution）

子類應當可以替換父類并出現在父類能夠出現的任何地方

依賴倒置原則（Dependency Inversion）

高層模塊不應依賴于低層模塊，二者都應依賴于抽象；抽象不應依賴于實現細節，細節應該依賴于抽象

• 程序中所有的依賴關系應該終止于抽象類或者接口
• 每個較高層次都為它所需要的服務聲明一個抽象接口，較低的層次實現了這些抽象接口，每個高層類都通過該抽象接口使用下一層的服務

接口隔離原則（Interface Segregation）

采用多個與特定客戶類的接口 比 采用一個通用的涵蓋多個業務方法的接口要好

• 如果一個服務器類為多個客戶類提供不同的服務，則服務器類應該為每一個客戶類創建特定的業務接口，而不要為所有客戶類提供統一的業務接口，除非這些客戶類請求的服務相同

組合/聚合復用（Composite/Aggregation Reuse）

在一個新對象里面使用一些已有對象，使之成為新對象的一部分；新對象通過向已有對象委托（delegate）一部分責任而達到復用已有對象的目的。

迪米特法則（Law of Demeter）

• 最少知識原則：一個對象應當可能少的了解其它對象。
• 只與你直接的朋友們通信，不要跟“陌生人”說話。
• 符合以下特征的屬于朋友：
  • 當前對象本身（this）；
  • 以參量形式傳入到當前對象方法中的對象；
  • 當前對象的實例變量直接引用的對象；
  • 當前對象的實例變量如果是一個聚集，那么聚集中的元素也都是朋友；
  • 當前對象所創建的對象。

7、軟件設計基礎

• 自頂向下，逐步細化
• 系統控制結構
• 結構劃分和結構圖
• 數據結構
• 軟件過程

七、面向對象設計

1、綜述

關鍵步驟：

• 確定系統的軟件基礎架構；
• 發現對象（發現軟件類）：根據需求和選擇的架構和模式確定系統由哪些對象構成；
• 確定對象屬性：明確該對象應該具有的特征屬性；
• 確定對象行為：明確對象應具有的功能和職責；
• 確定對象之間的關系：根據系統順序圖及操作契約以及選擇的架構和模式明確系統是如何相互協作完成功能需求的交互過程。

2、軟件的層次化結構

用戶界面層：（用例）系統功能的各種界面表現形式。

控制器層：用于協調、控制其他類共同完成用例規定的功能或行為。

業務邏輯層：實現用例要求的各種系統級功能。

持久化層：用于保存需要持久化存儲的數據對象。

系統層：為應用提供操作系統相關的功能，通過把特定于操作系統的特性包裝起來，使軟件與操作系統分離，增加應用的可移植性。

模塊層次化好處：增加軟件的健壯性，易于擴展和維護；增加軟件的可移植性。

3、類職責分配（Grasp）模式

設計類的來源有兩部分：

• 核心邏輯由領域模型中的概念類轉換而來

• 另一部分則是為實現而新增的一些類，如負責對象持久化的類、負責通信的類。

核心思想：每一個設計類都有明確的職責

• 自己干自己的事：
  • 對象要了解自己私有的封裝數據；
  • 了解相關聯的對象；
  • 了解能夠派生或者計算的事物。
• 自己干自己能干的事：
  • 對象自身要能執行一些行為，如創建一個對象或者進行計算；
  • 對象要能啟動其他對象中的動作；
  • 對象要能控制或協調其他對象中的活動。
• 自己只干自己的事（職責的內聚）

面向對象的設計模式

• 對象的職責通過調用對象的方法來實現。將職責分配給一個對象還是多個對象，是分配給一個方法還是多個方法要受到職責粒度的影響。
• 面向對象設計最關鍵的活動是正確地給對象分配職責。
• 模式是面向對象軟件的設計經驗，是可重用的設計思想，它描述了在特定環境中反復出現的一類設計問題，并提供經過實踐檢驗的解決這類問題的通用模式。
• 模式定義了一組相互協作的類，包括類的職責和類之間的交互方式。

控制器（Controller）模式

問題來源：第一個接收系統事件的軟件對象是什么？哪個軟件對象負責接收和處理一個系統輸入事件？

解決方案：把接收和處理系統事件的職責分配給位于控制器層的對象

• 它代表整個系統（系統簡單且不復雜），稱為外觀（facade）控制器；

• 它代表一個發生系統事件的用例場景，這個類通常命名為 “<用例名>控制器”，稱為用例控制器或者會話控制器。

• 在相同的用例場景中使用同一個控制器類處理所有的系統事件；

• 一次會話是與一個參與者進行交談的一個實例。

指導原則

• 當一個系統不具有“太多”的系統事件，或者用戶接口不可能將事件消息重定向到其他控制器時，選擇外觀控制器是合適的。這時，外觀控制器相當于一個應用的封面，隔離了用戶接口和應用邏輯。
• 如果外觀控制器由于職責過多而變得“臃腫”的時候，應該選擇用例控制器。
  • 如果選擇了用例控制器，那么每一個用例都有一個不同的控制類，而且只有一個，以便維護用例的狀態。用例控制器可以實現有一定執行順序的系統操作。
• 不論是外觀控制器還是用例控制器，它們只是接收系統事件消息，并沒有實現系統操作的職責，系統操作應該委托給領域對象處理。

創建者(Creator)模式

問題來源：哪個對象應該負責產生類的實例？（操作契約中對象實例的創建）

如果符合下面的一個或者多個條件，則可將創建類A實例的職責分配給類B(B創建A)。

• B聚合（aggregate）或包含（contain）對象A；

• B記錄（record）對象A；

• B密切使用對象A；

• B擁有創建對象A所需要的初始化數據（B是創建對象A的信息專家）。

創建者模式體現了低耦合的設計思想，是對迪米特法則的具體運用。

信息專家（Information Expert）模式

給對象分配職責的通用原則：將職責分配給擁有履行職責所必需信息的類，即信息專家。換言之，對象具有處理自己擁有信息的職責或能力。

根據信息專家模式，應該找到擁有履行職責所必須的信息的類，選取類的方法：

• 如果在設計模型中存在相關的類，先到設計模型中查看；

• 如果在設計模型中不存在相關的類，則到領域模型中查看，試著應用或擴展領域模型，得出相應的設計類。

職責的實現（即功能）需要信息，而信息往往分布在不同的對象中，一個任務可能需要多個對象（信息專家）協作來完成。

八、結構化軟件設計

1、系統功能結構圖

基本結構

四種模塊

• 傳入模塊 ：從下屬模塊取得數據，經過某些處理，再將其傳送給上級模塊。

• 傳出模塊 ：從上級模塊獲得數據，進行某些處理，再將其傳送給下屬模塊。

• 變換模塊 ：即加工模塊。它從上級模塊取得數據，進行處理，轉換成其它形式，再傳送回上級模塊。

• 協調模塊 ：對所有下屬模塊進行協調和管理的模塊。

變換型結構

變換型數據處理問題的工作過程大致分為三步：

• 取得數據

• 變換數據

• 給出數據

事務型結構

存在某一個數據流處理節點，引發一個或多個相同的處理，并將處理結果返回給該節點，則該數據流就叫做事務，該節點稱為事務z處理中心（核心工作是調度）。內部結構一致就是事務，否則就是變換。

事務是最小的工作單元，不論成功與否都作為一個整體進行工作。

變換-事務混合型結構

在具體的應用中一般以變換型為主，事務型為輔的方式進行軟件結構設計

確定系統邊界

中心變換：多股數據流匯集的地方往往是系統的中心變換部分（還需要根據上下文確定該加工是否表示功能需求）。

邏輯輸入：可以從數據流圖上的物理輸入開始，一步一步向系統中間移動，一直到數據流不再被看作是系統的輸入為止，則其前一個數據流就是系統的邏輯輸入。

• 可以認為邏輯輸入就是離物理輸入端最遠的，且仍被看作是系統輸入的數據流。

邏輯輸出：從物理輸出端開始，一步一步地向系統中間移動，就可以找到離物理輸出端最遠，且仍被看作是系統輸出的數據流。

2、變換映射

由流圖推導出的系統初始結構圖如下

3、事務映射

對于下圖，以 I 為中心或以 O 為中心，都是事務型結構。

4、詳細設計

從軟件開發的工程化觀點來看，在編制程序以前，需要對所采用算法的邏輯關系進行分析，設計出全部必要的過程細節，并給予清晰的表達，使之成為編碼的依據，這就是詳細設計的任務。

程序流程圖

為使用流程圖描述結構化程序，必須限制流程圖只能使用下面給出的五種基本控制結構：

N-S圖

也叫盒圖

PAD圖

• Problem Analysis Diagram
• 設置了五種基本控制結構的圖式，并允許遞歸使用。

判定表

• 當算法中包含多重嵌套的條件選擇時，用程序流程圖、N-S 圖或 PAD 都不易清楚地描述。然而，判定表卻能清晰地表達復雜的條件組合與應做動作之間的對應關系。
• 判定表要求不能存在多分支判斷，必須是兩分支的判斷

“Ｔ”表示該條件取值為真，“Ｆ”表示該條件取值為假，空白表示這個條件無論取何值對動作的選擇不產生影響。

“Ｙ”表示要做這個動作，空白表示不做這個動作。

九、軟件測試

定義：以最少的時間和人力，系統地找出軟件中潛在的各種錯誤和缺陷，并證明軟件的功能和性能與需求說明相符合

1、軟件測試的目的和原則

目的

從用戶的角度：通過軟件測試暴露軟件中的錯誤和缺陷，以考慮是否可接受該軟件產品。

從軟件開發者的角度：希望測試成為表明軟件產品中不存在錯誤，驗證該軟件已正確地實現了用戶的要求，確立人們對軟件質量的信心。

原則

• 應當把“盡早地和不斷地進行軟件測試”作為軟件開發者的座右銘。

• 測試用例應由測試輸入數據和對應的預期輸出結果這兩部分組成。

• 程序員應避免檢查自己的程序。

• 在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。

• 充分注意測試中的群集現象：經驗表明，測試后程序中殘存的錯誤數目與該程序中已發現的錯誤數目成正比。

• 嚴格執行測試計劃，排除測試隨意性。應當對每一個測試結果做全面檢查。

• 妥善保存測試計劃，測試用例，出錯統計和最終分析報告，為維護提供方便。

軟件測試對象

軟件開發各階段所得到的文檔，包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程序，都應成為軟件測試的對象。

流程

軟件配置：軟件需求規格說明、軟件設計規格說明、源代碼等；

測試配置：測試計劃、測試用例、測試程序等；

測試工具：測試數據自動生成程序、靜態分析程序、動態分析程序、測試結果分析程序、以及驅動測試的測試數據庫等等；

測試結果分析：比較實測結果與預期結果，評價錯誤是否發生以及錯誤的級別和嚴重性。

排錯（調試）：對已經發現的錯誤進行錯誤定位和確定出錯性質，并改正錯誤，同時修改相關的文檔。

修正后的文檔再測試：直到通過測試為止；

利用可靠性分析，評價軟件質量：

• 軟件的質量和可靠性達到可接受的程度

• 是否所做的測試不足以發現嚴重的錯誤

如果測試發現不了錯誤，只能說明測試配置考慮得不夠細致充分，錯誤仍然潛伏在軟件中。

軟件測試與各階段關系

2、測試方法

白盒測試

將測試對象看做一個透明的盒子，允許利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序的狀態，確定實際的狀態是否與預期的狀態一致，又稱為結構測試或邏輯驅動測試。

白盒測試主要應用于單元測試，是檢查程序邏輯錯誤的主要方法。

邏輯覆蓋

• 語句覆蓋：使得每一個可執行語句至少執行一次。

• 判定覆蓋：使得程序中每個判斷的取真分支和取假分支至少經歷一次，又稱為分支覆蓋。

• 條件覆蓋：使得程序中每個判斷的每個條件的可能取值至少執行一次。

• 判定-條件覆蓋：使得判斷中每個條件的所有可能取值至少執行一次，同時每個判斷的所有可能判斷結果取值至少執行一次。

• 條件組合覆蓋：使得每個判斷的所有可能的條件取值組合至少執行一次。

• 路徑覆蓋：設計足夠的測試用例，覆蓋程序中所有可能的路徑。

程序控制流圖

控制流圖是對程序流程圖進行簡化后得到的一種圖示方式，可以更加突出地表示程序控制流的結構。一個典型的控制流圖結構如下圖：

控制流圖包含三種元素：

• 結點：圓圈表示單條或多條語句
• 邊：帶箭頭的線條，表示控制流的方向
• 區域：邊和結點圈定的范圍

控制流圖中 5 種典型的控制流符號如下圖：

使用基本路徑測試方法設計測試用例的步驟如下：

根據程序代碼或程序流程圖導出程序的控制流圖。

計算控制流圖的環路復雜度 V(G)

三種計算環路復雜度的方法：

• 第一種：等于控制流圖中的區域數，包括封閉區域和開放區域；
• 第二種：設 E 為控制流圖的邊數，N 為圖的結點數，則定義環路復雜性為 V(G)＝E－N＋2；
• 第三種：若設 P 為控制流圖中的判定結點數，則有 V(G)＝P＋1。

確定基本路徑集。

以每條基本路徑為依據設計測試用例。

舉例

黑盒測試

這種方法完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書和概要設計說明，檢查程序的功能是否符合它的功能說明，又稱為功能測試或數據驅動測試。

有以下三種常用方法：

等價類劃分

黑盒測試方法不能選用窮舉方式，為此通過尋找具有代表意義的數據進行替代其它同類型的數據，稱為等價類。

并合理地假定：測試某等價類的代表值就等價于對這一類其它值的測試。

• 劃分等價類
  • 有效等價類：是指對于程序的規格說明來說，是合理的，有意義的輸入數據構成的集合。
  • 無效等價類：是指對于程序的規格說明來說，是不合理的，無意義的輸入數據構成的集合。
• 選取測試用例
  • 為每一個等價類規定一個唯一編號；
  • 設計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，重復這一步，直到所有的有效等價類都被覆蓋為止；
  • 設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直到所有的無效等價類都被覆蓋為止。

劃分方式

按區間劃分 [x, y]

數值集合

布爾值

數值劃分

限制條件 / 規則

確定測試用例，每個唯一編號

舉例

邊界值分析

使用邊界值分析方法設計測試用例，首先應確定邊界情況。應當選取正好等于，剛剛大于，或剛剛小于邊界的值做為測試數據，而不是選取等價類中的典型值或任意值做為測試數據。

因果圖

目的是減少測試用例的數目

• 分析（需求）軟件規格說明描述中，哪些是原因（輸入或狀態），哪些是結果（輸出或動作），并給每個原因和結果賦予一個唯一的標識符。

• 分析（需求）軟件規格說明中的語義，找出原因與原因之間，原因與結果之間的關系，根據這些關系，畫出因果圖。

• 由于語法或環境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現。為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件。

• 把因果圖轉換成判定表，并根據因果圖中的制約關系對判定表進行化簡，去掉不可能存在的組合情況。

• 簡化后的判定表中的每一列就是一種有效的條件組合，對應一個測試用例

通常在因果圖中用 C_i 表示原因，用 E_i 表示結果，各結點表示狀態。

• “0” 表示某狀態不出現
• “1” 表示某狀態出現

舉例

轉換判定表：

3、軟件測試基本類型

單元測試：編碼階段運用白盒測試方法，對已實現的最小單位代碼進行正確性檢查；

集成測試：編碼階段在單元測試的基礎上，運用黑盒測試方法檢查被測單元的接口問題，并檢查代碼集成后各功能的完整性；

確認測試：開發后期，針對系統級的軟件驗證所實現的功能和性能是否與用戶的要求一致；

系統測試：在開發環境或實際運行環境中，以系統需求分析規格說明書作為驗收標準，對軟硬件系統進行的一系列集成和確認測試；

驗收測試：在實際運行環境中，試運行一段時間后所進行的測試活動，確認系統功能和性能符合生產要求。驗收通過后交付給用戶使用。

十、剩余章節

1、軟件維護

定義

在軟件已經交付使用之后，為了改正錯誤或滿足新的需要而修改軟件的過程，即在軟件運行-維護階段對軟件產品所進行的一切改動。

分類

改正性維護：改正在系統運行過程中發現的一些潛在程序錯誤或設計缺陷

適應性維護：為了適應在軟件使用過程中數據環境發生變化或處理環境發生變化而進行的軟件修改

完善性維護：為滿足用戶的其他要求，就需要修改軟件并把這些要求納入到軟件之中，稱為完善性維護

預防性維護：為了提高軟件的可維護性、可靠性等而事先進行的軟件改動

軟件維護的活動

建立維護機構，給出軟件維護的工作管理流程，為每一個維護申請規定標準的處理步驟

修改請求 --> 分類與鑒別 --> 分析 --> 設計 --> 實現 --> 系統測試 --> 驗收測試 --> 交付

2、軟件項目管理

定義

項目：是一項為了創造某一唯一的產品或服務的時限性工作。具有以下特征：

• 需要由人來完成；
• 受到有限資源的限制；
• 需要計劃、執行和控制。

軟件項目：是一種成果體現為軟件產品的項目。其特有的特征表現為：

• 軟件產品是無形的；
• 軟件產品沒有標準的軟件過程 ；
• 大型軟件項目開發常常是 “一次性的”。

項目管理過程

項目管理就是為了滿足甚至超越項目干系人員對項目的需求和期望的一些活動，并將理論知識、技能、工具和技巧應用到項目的活動中。

包含以下九個知識領域：

綜合管理：將項目管理各種必要要素綜合為整體的過程和活動，并在項目管理過程組范圍內識別、定義、組合、統一并協調。

范圍管理：界定為了確保成功地完成項目所需要做的工作，也是僅僅被要求做的工作。

時間管理：闡述確保項目按時完成所需的各項過程。

成本管理：闡述了確保項目按照規定預算完成需要進行的費用規劃、估算、預算的各項過程。

質量管理：闡述了確保項目達到其既定質量要求所需實施的各項過程。

人力資源管理：闡述了組織和管理項目團隊的各個過程。

溝通管理：闡述了為確保項目信息及時而恰當地提取、收集、傳輸、存儲和最終處置而需要實施的一系列過程。

風險管理：闡述了與項目風險管理有關的過程。

采購管理：闡述了采購或取得產品、服務或成果，以及合同管理所需的各過程。

軟件項目管理過程如下：

啟動軟件項目 --> 制定項目計劃 --> 項目計劃的執行 --> 項目的控制 --> 項目結束

上半部分傳送門：
https://blog.csdn.net/qq_43791817/article/details/116189749

總結

以上是生活随笔為你收集整理的软件工程总结（下）的全部內容，希望文章能夠幫你解決所遇到的問題。

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