第五章節——軟件工程基礎知識

---

一、軟件工程概述

軟件工程指的是應用計算機科學、數學及管理科學等原理，以工程化的原則和方法來解決軟件問題的工程，目的是提高軟件生產率、提高軟件質量、降低軟件成本。

1. 計算機軟件

計算機軟件指的是計算機系統中的程序及其文檔。按照軟件應用領域，將計算機軟件分為以下十類

• 系統軟件
• 應用軟件
• 工程/科學軟件
• 嵌入式軟件
• 產品線軟件
• Web應用軟件（WebApp）
• 人工智能軟件
• 開放計算
• 網絡資源
• 開源軟件

---

2. 軟件工程基本原理

美國著名的軟件工程專家B.W.Boehm于1983年提出了軟件工程的七條基本原理

• 用分階段的生命周期計劃嚴格管理
• 堅持進行階段評市
• 實現嚴格的產品控制
• 采用現代的程序設計技術
• 結果應能清楚地審查
• 開發小組的人員應少而精
• 承認不斷改進軟件工程實踐的必要性

---

3. 軟件生命周期

同其他事物一樣，一個軟件產品或軟件系統要經歷孕育、誕生、成長、成熟、衰亡等階段，一般稱為軟件生存周期。軟件生存周期包括以下七個方面：

（1）可行性分析與項目開發計劃
這個階段主要確定軟件的開發目標及其可行性。參與該階段的人員有用戶、項目負責人、系統分析師。產生的文檔有可行性分析報告、項目開發計劃。

（2）需求分析
該階段的任務不是具體的解決問題，而是要確定軟件系統要做什么，確定軟件系統的功能、性能、數據和界面等要求，從而確定系統的邏輯模型。參與該階段的人員有用戶、項目負責人、系統分析師。產生的文檔主要是軟件需求說明書。

（3）概要設計
該階段開發人員把確定的各項功能需求轉換成需要的體系結構。概要設計就是設計軟件的結構，明確軟件由哪些模塊組成 ，這些模塊層次結構是怎樣的，調用關系是怎樣的，每個模塊的功能是什么。參與該階段的人員有系統分析師、軟件設計師。產生的文檔主要是概要設計說明書。

（4）詳細設計
該階段的主要任務是對每個模塊的功能進一步詳細、具體的描述。參與該階段的人員有軟件設計師、程序員。產生的文檔主要是詳細設計文檔。

（5）編碼
把每個模塊的控制結構轉換成計算機可接受的程序代碼，即寫成某種特定程序設計語言表示的源程序清單。

（6）測試
測試是保證軟件質量的重要手段。參加測試的人員通常是另一部門(或單位〉的軟件設計師或系統分析師。產生的文檔主要是軟件測試計劃、測試用例、測試報告。

（7）維護
軟件維護是軟件生存周期中時間最長的階段。軟件己交付且正式投入使用后，便進入維護階段。
對軟件進行修改的原因包括: ①運行中發現隱含的錯誤而需要修改②為了適應變化的(或變化后的工作環境而修改③需要對軟件功能進行擴充、增強而進行的修改④為將來軟件維護活動做預先準備。

文檔是軟件開發使用和維護中的必備資料。文檔能提高軟件開發的效率，保證軟件的質量，而且在軟件的使用過程中有指導、幫助、解惑的作用，尤其在維護工作中，文檔是不可或缺的資料。

---

4. 軟件過程

軟件開發中遵循一系列可預測的步驟（即路線圖），該路線圖稱為“軟件過程”。過程是活動的集合，活動是任務的集合。
軟件過程的能力成熟度模型:
（1）能力成熟度模型CMM
能力成熟度模型CMM是對軟件組織進化階段的描述，隨著軟件組織定義、實施、測量、控制和改進其軟件過程，軟件組織的能力經過這些階段逐步提高。將軟件過程改進分為五個成熟度級別

（1）能力成熟度模型CMMI

CMMI是若干過程模型的綜合和改進，是支持 多個工程學科 和領域的、系統的、一致的過程改進框架。CMMI提供了兩種表示方法：階段式模型和連續式模型。
階段式模型。 結構類似于CMM，它關注組織的成熟度。CMMI-SE/SW/IPPD 1.1版本中有五個成熟度等級。

1. 初始級: 過程不可預測且缺乏控制。
2. 已管理級: 過程為項目服務。
3. 已定義級: 過程為組織服務。
4. 定量管理級: 過程已度量和控制。
5. 優化級: 集中過程改進。

連續式模型 關注每個過程域的能力，一個組織對不同的過程域可以達到不同的過程域能力等級（簡稱CL）。CMMI中包括六個過程域能力等級。

1. CL₀ (未完成的)﹔過程域未執行。
2. CL₁ (已執行的): 其共性目標是過程將可標識的輸入工作產品轉換成可標識的工作產品
3. CL₂ (已管理的): 其共性目標集中于已管理的過程的制度化。
4. CL₃ (已定義級的): 其共性目標集中于已定義的過程的制度化。
5. CL₄ (定量管理的）: 其共性目標集中于可定量管理的過程的制度化。
6. CL₅ (優化的): 使用量化手段改變和優化過程域。

二、軟件過程模型

軟件過程模型習慣上稱為軟件開發模型，它是軟件開發全部過程、活動和任務的結構框架。典型的軟件過程模型有瀑布模型、增量模型、演化模型（原型模型、螺旋模型)、噴泉模型、基于構件的開發模型、形式化方法模型和統一過程模型等。

1. 瀑布模型

瀑布模型將軟件生命周期中的各個活動規定為依據線性順序連接的若干階段的模型，包括需求分析、設計、編碼、測試、運行與維護。如同瀑布流水逐級下落，如下圖所示。瀑布模型以項目的階段性評審和文檔控制為手段有效地對整個開發過程進行指導，所以它是
以文檔作為驅動、適合軟件需求很明確的軟件項目的開發。

• 優點: 容易理解、成本低、強調開發的階段性早期計劃及需求調查和產品測試。
• 缺點: 客戶必須能完整、正確和清晰地表達需求;難以評估項目進度狀態;項目快結束時，出現大量的集成與測試工作;需求或設計的錯誤往往只有到了項目后期才能被發現，對項目風險的控制能力較弱，通常會導致項目延期，開發費用超出預算。

---

2. 增量模型

增量模型將需求分段為一系列產品，每一個增量都可以分別開發，如下圖。

• 優點： 第一個可交付的版本成本和時間很少。開發由增量表示的小系統所承擔的風險不大;由于很快發布了第一個版本，因此可減少用戶需求的變更。同時，它也具有瀑布模型所有的優點。
• 缺點： 若沒有對用戶的變更要求進行規劃，那么產生的初始增量可能會造成后來增量的不穩定;若需求不像早期思考的那樣穩定和完整，那么一些增量就可能需要重新開發或重新發布;管理發生的成本、進度和配置的復雜性可能會超出組織的能力。

---

3. 演化模型（原型模型、螺旋模型)

經典的演化模型有原型模型和螺旋模型。演化模型適用于軟件需求不夠明確的情況。

原型模型（快速原型模型）：
原型是預期系統的一個可執行版本。原型模型開始于溝通，目的是定義軟件的總體日標、標識需求，然后快速構建原型并交付用戶使用，收集客戶反饋意見，并在下一輪中對原型進行改進。原型模型適用于用戶需求不明確、需求經常變化且系統規模不太大、不太復雜的軟件項目。

螺旋模型：
對于一個復雜的大項日，開發一個原型往往達不到要求。螺旋模型將瀑布模型和原型模型結合起來，加入兩種模型均忽略的風險分析，彌補了這兩種模型的不足。螺旋模型中的每個螺旋周期分為以下四個步驟:①制訂計劃:確定軟件目標，選定實施方案，明確項日開發的限制條件。②風險分析:對所選方案進行分析，識別風險，消除風險。③實施工程:實施軟件開發，驗證階段性產品。④用戶評估:評價開發工作，提出修正建議，建立下一個周期的開發計劃。螺旋模型強調風險分析，與瀑布模型相比，支持用戶需求的動態變化。螺旋模型適合用于龐大、復雜且具有高風險的系統。

---

4. 噴泉模型

噴泉模型是以用戶需求為動力，以對象為驅動的模型，適用于面向對象的開發方法。它克服了瀑布模型不支持軟件重用和多項開發活動集成的局限性。噴泉模型使開發過程具有迭代性和無間隙性。噴泉模型如下圖所示。

• 優點： 各個階段沒有明顯的界線，開發人員可以同步進行;可以提高軟件項目的開發效率，節省開發時間。
• 缺點： 由于在各個開發階段是重疊的，在開發過程中需要大量的開發人員，不利于項目的管理;要求嚴格管理文檔，使得審核的難度加大。

---

5. 基于構建的開發模型

基于構件的開發模型是指利用預先包裝的構件來構造應用系統。構件可以是組織內部開發的構件,也可以是商品化成品軟件構件。基于構建的開發模型具有許多螺旋模型的特點，它本質上是演化模型，需要以迭代方式構建軟件。其不同之處在于基于構件的開發模型采用預先打包的軟件構建開發應用系統。

構件是面向軟件體系架構的可復用軟件模塊。構件(Component）是可復用的軟件組成成份，可被用來構造其他軟件。它可以是被封裝的對象類、功能模塊、軟件框架（Framework)、軟件架構、文檔、設計模式等。

---

6. 形式化方法模型

形式化方法是建立在嚴格數學基礎上的一種軟件開發方法，主要活動是生成計算機軟件形式化的數學規格說明。

---

7. 統一過程（UP）模型

統一過程模型是一種“用例和風險驅動，以架構為中心，迭代并增量”的開發過程，由方法和工具支持。統一過程定義了四個技術階段及其主要工作產品:
(1）起始階段： 專注項目的初創活動，主要工作產品有構想文檔、初始用例模型、初始項日術語表、初始業務用例、初始風險評估、項目計劃、業務模型及多個原型（需要時）。
(2）精化階段： 主要工作產品有用例模型、補充需求、分析模型、整體體系結構描述、可執行的軟件休系結構原型、初步設計模型、修訂的風險列表、項目計劃及初始用戶手冊。
(3）構建階段： 關注系統的構建，產生實現模型，主要工作產品有設計模型、軟件構件、集成軟件增量、測試計劃及步驟、測試用例及支持文檔（用戶手冊、安裝手冊等）。
(4）移交階段： 關注軟件提交方面的工作，產生軟件增量，主要工作產品有提交的軟件增量、測試報告和綜合用戶反饋。統一過程的典型代表是RUP (Rational Unified Process），RUP是UP的商業擴展，完全兼容UP，比UP更完整、更詳細。

---

8. 敏捷方法

敏捷方法的總體目標是通過“盡可能早地、持續地對有價值的軟件進行交付”使客戶滿意。敏捷過程的典型方法有很多，每一種方法基于一套原則，這些原則實現了敏捷方法所宣稱的理念，即敏捷宣言。常用的敏捷方法：

1. 極限編程（XP)：四大價值觀：溝通、簡單性、反饋和勇氣。
2. 水晶法(Crystal)：認為人對軟件質量有重要的影響，隨著開發人員素質的提高，項目和過程的質量〈<也隨之提高。
3. 并列爭球法(Scrum)：使用迭代的方法，其中，把每30天一次的迭代稱為一個“沖刺”，并按需求的優先級別來實現產品。
4. 自適應軟件開發(ASD)：是一種敏捷軟件開發方法，倡導根據需求的變化及時調整開發過程，實現軟件開發的自適應性能力。
5. 敏捷統一過程(AUP)：采用“在大型上連續”以及在“在小型上迭代”的原理來構建軟件系統。

---

三、需求分析

需求分析 也稱為軟件需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細致的調研和分析，準確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式化的需求表述轉化為完整的需求定義，從而確定系統必須做什么的過程。

1. 軟件需求

軟件需求包括以下內容：

• 功能需求： 考慮系統要做什么，什么時候做，如何修改或升級。
• 性能需求： 考慮軟件開發的技術性指標，如存儲容量限制，執行速度，響應時間，吞吐量等。
• 用戶或人的因素： 考慮用戶的類型
• 環境需求： 考慮軟件應用的環境
• 界面需求： 考慮來自其他系統的輸入或到其他系統的輸出等
• 文檔需求： 考慮需要那些文檔，文檔針對那些讀者
• 數據需求： 考慮輸入，輸出格式，接收，發送數據的頻率，數據的精準度，數據流量，數據保持時間。
• 資源使用需求： 考慮軟件運行時所需要的資源/
• 安全保密需求： 考慮是否需要對訪問系統或系統信息加以控制。
• 可靠性需求： 考慮系統的可靠性需求，系統是否必須檢測和隔離錯誤，錯誤后重啟系統所允許的時間等。
• 軟件成本消耗或開發進度需求： 考慮開發是否有規定的時間表
• 其他非功能性需求： 如采用某種開發模式，確定質量控制標準，里程碑和評審，驗收標準等。

2. 需求分析原則

需求分析過程有不同的分析方法，它們要遵循的操作原則有：

• 必須能表示和理解問題的信息域。
• 必須能定義軟件將完成的任務。
• 必須能表示軟件的行為。
• 必須劃分描述數據、功能和行為的模型。
• 分析過程應該從要素信息移向細節信息。

3.需求工程

需求工程是一個不斷反復的需求定義、文檔記錄、需求演進的過程，并最終在驗證的基礎上凍結需求。需求工程可以細分為六個階段:

1. 需求獲取。
2. 需求分析與協商。
3. 系統建模：模型以一種簡潔、準確、結構清晰的方式系統地描述軟件需求。常用的需求分析方法有：面向數據流的結構化分析方法SA，面向對象的分析方法OOA。
4. 需求規約;通過建立完整的信息描述、詳細的功能和行為描述、性能需求和設計約束的說明、合適的驗收標準，給出對目標軟件的各種需求，作為用戶和開發者之間的一個協議。
5. 需求驗證;其目的是要檢驗需求功能的正確性、完整性和清晰性，是否能夠反映用戶的意愿。
6. 需求管理。

四、系統設計

進入設計階段，要把軟件“做什么”的邏輯模型轉換成“怎么做”的物理模型。系統設計的主要內容包括新系統總體結構設計、代碼設計、輸入設計、輸出設計、處理過程設計、數據存儲設計、用戶界面設計和安全控制設計等。主要目的就是為系統制定藍圖。常用的設計方法有:面向數據流的結構化設計方法(SD)、面向對象的設計方法（OOD)。系統設計包括兩個基本的步驟:概要設計、詳細設計。

1. 概要設計

概要設計主要包括：

1. 軟件系統總體結構設計：將系統按功能劃分成模塊;確定每個模塊的功能;確定模塊之間的調用關系;確定模塊之間的接口，即模塊之間傳遞的信息;評價模塊結構的質量。
2. 數據結構及數據庫設計，如E-R圖。
3. 編寫概要設計文檔：概要設計說明書、數據庫設計說明書、用戶手冊及修訂測試計劃。
4. 評審。

2. 詳細設計

詳細設計主要包括：

1. 對每個模塊進行詳細的算法設計
2. 對模塊內部的數據結構進行設計
3. 對數據庫進行物理設計，即確定數據庫的物理結構
4. 其他設計（代碼設計，輸入/輸出設計，用戶界面設計）
5. 編寫詳細設計說明書
6. 評審

系統設計的結果是一系列的系統設計文件，這些文件是物理實現一個信息系統（包括硬件設備和編制軟件程序）的重要基礎。

五、系統測試

1. 系統測試與調試

系統測試是為了發現錯誤而執行程序的過程，成功的測試是發現了至今尚未發現的錯誤的測試。

測試的目的是以最少的人力和時間發現潛在的各種錯誤和缺陷。信息系統測試包括軟件測試、硬件測試、網絡測試。
測試應遵循的基本原則： ①應盡早并不斷地進行測試;②測試工作應避免原先開發軟件的人員或小組參與;③設計測試方案時要確定輸入數據，還要根據系統功能確定預期的輸出結果;④設計測試用例時要設計合理、有效的輸入條件，還要包含不合理、失效的輸入條件。人們在測試時通常忽略了對異常、不合理、意想不到的情況進行測試，這可能就是隱患;⑤在測試時要檢查程序是否做了該做、不該做的事，多余的工作會影響程序的效率;⑥嚴格按照測試計劃進行測試;⑦妥善保存測試計劃、測試用例;⑧要精心設計測試用例。

測試的過程包括：①制定測試計劃;②編制測試大綱;⑧根據測試大綱設計和生產測試用例;④實施測試;⑤生成測試報告。

---

2. 傳統軟件測試策略

軟件測試分為四步：單元測試，集成測試，確認測試和系統測試

（1）單元測試
單元測試特稱模塊測試，在模塊編寫完成且編譯無誤后進行，側重于模塊中的內部邏輯和數據結構。單元測試環境如下圖，由于模塊不是獨立運行的程序，各模塊之間存在調用與被調用的關系。在對每個模塊進行測試時，需要開發兩種模塊：
驅動模塊：相當于一個主程序
樁模塊：用來代替測試模塊中所調用的子模塊

---

(2) 集成測試
集成測試就是把模塊按系統設計說明書的要求組合起來進行測試。
集成測試通常有以下兩種方法:

1. 非增量集成： 分別測試各個模塊，再將這些模塊組合起來進行整休測試。
2. 增量集成： 以小增量的方式逐步進行構造和測試。

常用的增量集成策略包括:自頂向下集成測試、自底向上集成測試、回歸測試、冒煙測試等。

---

（3）確認測試

確認測試始于集成測試的結束，即已測試完單個構件，軟件已經組裝成完整的軟件包，而且接口錯誤已被發現和改正。確認過程的一個重要成分是配置評審，主要檢查軟件、文檔、數據是否齊全、分類是否有序。

當為客戶開發軟件時，執行一系列驗收測試能使客戶確認所有的需求，驗收測試是由用戶而不是軟件工程師進行的。

α測試：最終用戶在開發者的場所進行測試。
β測試：在一個或多個最終用戶場所執行，與α測試不同，開發者通常不在場。

---

（4）系統測試

系統測試是將已經確認的軟件、硬件、外設、網絡等其他因素結合在一起，進行各種集成測試和確認測試。目的是通過與系統的需求(SRS）進行比較，發現所開發的系統與用戶需求不符或矛盾的地方。主要包括恢復測試、安全性測試、壓力測試、性能測試、部署測試。

3. 測試方法

軟件測試分為靜態測試和動態測試。

• 靜態測試： 被測程序不在機器上運行，采用人工檢測和計算機輔助靜態分析的手段對程序進行測試，包括對文檔的靜態測試和對代碼的靜態測試。對文檔的靜態測試主要以檢查單的形式進行，而對代碼的靜態測試，包括桌前檢查、代碼審查、代碼走查的方式。使用這種方法能夠有效地發現30%-70%的邏輯設計和編碼錯誤。
• 動態測試： 通過運行程序發現錯誤，一般采用黑盒測試和白盒測試。

（1）黑盒測試

也稱功能測試 ，在不考慮軟件內部結構和特性的情況下，測試軟件的外部特性。
常用的黑盒測試技術有等價類劃分、邊界值分析、錯誤推測和因果圖等。

• 等價類劃分：將程序的輸入域劃分為若干等價類，然后從每個等價類中選取一個代表性數據作為測試用例。等價類劃分有兩種：有效等價類(對于需求規格來說合理的數據集合)和無效等價類(對于需求規格來說異常的數據集合)。

• 邊界值分析：是對等價類劃分方法的補充。邊界值分析選擇等價類邊界的測試用例。所謂邊界值，是指相對于輸入等價類和輸出等價類而言，稍高于其最高值或稍低于最低值的一些特殊情況。邊界值分析的步驟包括確定邊界，選擇測試用例兩個步驟。
  例如，如果程序的規格說明中規定:“重量在10公斤至50公斤范圍內的郵件，其郵費計算公式為…”。作為測試用例，我們應取10至50，還應取9.99，10.01，49.99以及50.01等

• 錯誤推測：基于經驗和直覺推測程序中所有可能存在的各種錯誤。

• 因果圖：從自然語言描述的程序規格說明中找出因（輸入條件）和果（輸出或程序狀態的改變)，通過因果圖轉換為判定表。因果圖(Cuase-effect Graph）是一種描述輸入條件的組合及每種組合對應的輸出的圖形化工具。在因果圖的基礎上可以設計測試用例。

（2）白盒測試
也稱結構測試，根據程序的內部結構和邏輯來設計測試用例，對程序的路徑和過程進行測試，檢查是否滿足設計的需要。常用的白盒測試技術有邏輯覆蓋、循環覆蓋和基本路徑測試。
邏輯覆蓋：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。

• 語句覆蓋(SC)：是指選擇足夠多的測試用例，使被測程序的每條語句至少執行一次。語句覆蓋是一種很弱的邏輯覆蓋。
• 判定覆蓋（DC)：又稱分支覆蓋，是指設計足夠的測試用例，使得不僅每條語句至少執行一次，而且每個判定表達式的每種可能的結果（分支）都至少執行一次。判定覆蓋比語句覆蓋強。
• 條件覆蓋(CC）：是指設計一組測試用例，不僅每條語句至少執行一次，而且使判定表達式中的每個條件的所有可能的值至少滿足一次。條件覆蓋不一定包含判定覆蓋、判定覆蓋也不一定包含條件覆蓋。
• 判定/條件覆蓋(CDC)：是指同時滿足判定覆蓋和條件覆蓋的邏輯覆蓋。設計足夠的測試用例,使得判定表達式中每個條件的所有可能的值至少滿足一次，而且每個判定本身的所有可能結果也至少出現一次。
• 條件組合覆蓋（MCC)：設計足夠的測試用例，使得每個判定表達式中條件的所有值的組合都至少出現一次。滿足條件組合覆蓋的測試用例，也一定滿足判定覆蓋、條件覆蓋和判定/條件覆蓋。
• 路徑覆蓋：設計足夠的測試用例，覆蓋被測程序中所有可能的路徑（如果程序中有環路，則要求每條環路至少經過一次）。路徑覆蓋考慮了程序中各種判定結果的所有可能組合，因此是一種較強的覆蓋標準。但路徑覆蓋并未考慮判定中的條件結果的組合，并不能代替條件覆蓋和條件組合覆蓋。

4. 調試

調試發生在測試之后，其任務是根據測試時所發現的錯誤找出原因和具體的位置，進行改正，改正后要進行回歸測試。調試工作主要由程序開發人員進行，誰開發的程序就由誰來進行調試。日前常用的調試方法有以下五種：
(1）試探法： 調試人員分析錯誤的癥狀，猜測問題所在的位置，一步步試探和分析問題所在。該方法效率氐，適用于結構比較簡單的程序。
(2）回溯法： 調試人員從發現錯誤的位置開始，人工沿著程序的控制流程往回追蹤代碼，直到找出問題根原為止。該方法適用于小型程序。
(3）對分查找法： 該方法主要用來縮小錯誤范圍，直到把故障范圍縮小到比較容易診斷為止。
(4)歸納法： 從測試所暴露的問題出發，收集所有正確、不正確的數據，并分析它們之間的關系，提出假識的錯誤原因，用這些數據證明或反駁，從而查出錯誤所在。
(5）演繹法： 根據測試結果，列出可能的錯誤原因，分析已有的數據，排除不可能和彼此矛盾的原因。若多個錯誤同時存在，就要重新分析，提出新的假設，直到發現錯誤為止。

六、運行和維護

1. 系統轉化

一個系統開發完成后，讓它實際運行一段時間，是對系統最好的檢驗和測試方法。
新舊系統之間的轉換方法有直接轉換、并行轉換和分段轉換。

• 直接轉換：直接啟用新系統，終止舊系統。適用于一些處理過程不太復雜、數據不太重要的場合。
• 并行轉換：新舊系統并行工作一段時間，經過一段時間的考驗后，新系統正式替代舊系統■適用于較復雜的大型系統。主要特點是安全、可靠，但費用和工作量都很大。
• 分段轉換：直接轉換和并行轉換的結合。在新系統全部正式運行前，一部分一部分地替代舊系統。既保證了可靠性，又不至于費用太大。

2. 系統維護概述

系統維護是在軟件已經交付使用之后為了改正錯誤或滿足新的需求而修改軟件的過程。系統可維護性的評價指標有可理解性、可測試性和可修改性。文檔是軟件可維護性的決定因素。

系統維護主要包括硬件維護、軟件維護和數據維護。軟件維護的內容：

• 正確性維護：改正在系統開發階段已發生而系統測試階段尚未發現的錯誤。占整個維護工作量的17%~21%。修正BUG、錯誤。
• 適應性維護：使應用軟件適應信息技術變化和管理需求變化而進行的修改。占整個維護工作量的18%~25%。應變。
• 完善性維護：為擴充功能和改善性能而進行的修改。占整個維護工作的50%~60%。新需求。
• 預防性維護：為改進應用軟件的可靠性和可維護性，為適應未來的軟/硬環境的變化，應主動增加預防性的新功能，以使應用系統適應各類變化而不被淘汰。占整個維護工作量的4%左右。針對未來。

七、軟件項目管理

1. 軟件項目管理涉及的范圍

有效的軟件項日管理集中在4P上：人員(Person)、產品(Product)、過程(Procedure)、項目(Project）。

1. 人員：參與項目的人員類型有項目管理人員、高級管理人員、開發人員、客戶、最終用戶。
2. 產品：開展項目計劃之前，應先進行項目定義，即定義項目范圍，其中包括建立產品的目的和范圍、可選的解決方案、技術、管理約束等。
3. 過程：對于軟件項目來說，強調的是對其進行過程控制，通常將項目分解為任務、子任務等。
4. 項目：常見的軟件項目辦法有明確目標及過程、保持動力、跟蹤進展、作出明智的決策、進行事后分析。

---

2. 軟件項目估算

軟件項目估算涉及人、技術、環境等多種因素，因此很難在項目完成前準確地估算出開發軟件所需的成本、持續時間和工作量。常用的估算方法有三種：基于已經完成的類似項目進行估算、基于分解技術進行估算、基于經驗估算模型的估算。

（1）成本估算方法
常見的成本估算方法有白頂向下估算方法、自底向上估算方法、差別估算方法、專家估算法、類推估算法和算式估算法等。

（2）COCOMO模型
COCOMO模型是一種精確的、易于使用的成本估算模型。其公式如下:
E=a(L)^b，D = cE^d
其中，E表示工作量，單位是人月；D表示開發時間，單位是月；L是項目的源代碼行估計值，單位是千行代碼；a、b、c、d都是常數。

（3）COCOMOⅡ模型
COCOMOⅡ模型也是一種基于層次結構的估算模型，分為3個階段性模型：應用組裝模型（基于對象點數量進行估算)、早期設計階段模型（基于功能點數量進行估算）和體系結構階段模型（基于早期架構設計，也是基于功能點數量進行估算）。

（4）Putnam估算模型
Putnam模型是一種動態多變量模型，它是假設在軟件開發的整個生存周期中工作量有特定的分布。

---

3. 進度管理

進度管理的目的是確保軟件項目在規定的時間內按期完成。進度安排的常用圖形描述方法有甘特圖(GanttChart）和項目計劃評審技術圖(PERT)。

（1）甘特圖
Gantt圖是一種簡單的水平條形圖，它以日歷為基準描述項目任務。橫坐標表示時間，縱坐標表示任務，圖中的水平線段表示對一個任務的進度安排，線段的起點和終點對應在橫坐標上的時間分別表示該任務的開始時間和結束時間，線段的長度表示完成該任務所需的時間。

• 優點：能清晰地描述每個任務從何時開始，到何時結束，任務的進展情況以及各個任務之間的并行性。
• 缺點：不能清晰地反映出各個任務之間的依賴關系，難以確定整個項目的關鍵所在，也不能反映計劃中有潛力的部分。

---

（2）項目活動圖（PERT圖）

下面是一個軟件項目的活動圖(PERT圖)，頂點表示里程碑，連接頂點的邊表示活動，邊上的權重表示完成該活動所需要的時間(天）。

關鍵路徑：從開始頂點到結束頂點之間距離最長的一條路徑。關鍵路徑上的長度就是完成整個工程項目的最短工期。松弛時間:最遲開始時間-最早開始時間，最遲開始時間從后往前推（關鍵路徑長度-該活動開始頂點到項目活動圖的結束頂點的最長長度)，最早開始時間從前往后推（等于項目活動圖的開始頂點到該活動開始頂點的最長長度)，或者關鍵路徑的總時間-包含該活動的最長路徑的總時間。關鍵路徑上的活動的松弛時間均為0。

---

4. 軟件項目的組織

開發組織采用什么形式，不僅要考慮到項目的特點，還要考慮參與人員的素質。軟件項目組織的原則有：①盡早落實責任；②減少交流接口；③責權均衡。

程序設計小組的組織方式：
(1) 主程序員制小組
由一名主程序員、若干名程序員、一名后援工程師和一名資料員組成。主程序員通常由高級工程師承擔突出主程序員的領導作用，小組內的通信主要體現在主程序員與程序員之間。

(2）民主制小組
小組成員之間地位平等，工作日標和決策由全體成員決定，這種形式的組內通信路徑較多。

(3）層次式小組
由一名組長領導若干名高級程序員，每名高級程序員領導若干名程序員。組長通常是項日負責人，負責全紐的技術工作，進行任務分配，組織評審。高級程序員負責項目的一個部分或一個子系統。

5. 軟件項目配置

軟件配置管理(SCM）用于整個軟件工程，主要目標是識別變更、控制變更、確保變更正確實現、報告有關變更。

• 基線： 基線即軟件生存周期中各個開發階段的一個特定點，作用是將各階段的工作劃分更加正確。
• 軟件配置項： 軟件配置項(SCI）是配置管理的基本單位，對己經成為基線的SCI，雖然可以修改，但必須按照一個特殊的、正式的過程進行評估，確認每一處修改。
• 版本控制： 版本控制實際上是一個動態的概念，一方面隨著軟件生存周期向前推進，SCI的數量在不斷增加，一些文檔經過轉換生成另一些文檔，并產生一些信息:另一方面又隨時會有新的變更出現，形成新的版木。
• 變更控制： 對軟件配置的變更加以控制和管理。是一項最重要的軟件配置任務。

6. 風險管理

軟件風險包括兩個特性:不確定性和損失。不確定性是指風險可能發生也可能不發生;損失是指風險發生后會產生的惡性后果。常見的商業風險有:市場風險、策略風險、銷售風險、管理風險、預算風險。

• **風險識別：**當識別出已知風險和可預測風險后，項日管理者首先要做的是盡可能回避這些風險，在必要時控制這些風險。風險因素可以定義為:性能風險、成本風險、支持風險、進度風險。
• **風險預測：**風險預測又稱為風險估計，它試圖從兩個方面評估一個風險:風險發生的可能性或概率;風險發生后所產生的后果。
• **風險評估：**一種對風險評估很有用的技術就是定義風險參考水準。對于大多數軟件項日來說，成本、進度和性能就是3種典型的風險參考水準。
• **風險控制：**應對風險最好的辦法是主動地避免風險，即在風險發生前分析引起風險的原因，然后采取措施避免風險的發生。

八、軟件質量

1. 軟件質量特性

軟件質量是指反映軟件系統或軟件產品滿足規定或隱含需求的能力的特征和特性全體。討論軟件質量首先要了解軟件的質量特性，在ISO/IEC 9126中，軟件質量模型由三個層次組成，第一層為質量特性，第二層為質量子特性，第三層為度量指標，如下圖所示。

2. 軟件質量保證

• 軟件質量保證(Software Quality Assurance，SQA）是指為保證軟件系統或軟件產品充分滿足用戶要求的質量而進行的有計劃、有組織的活動，其目的是生產高質量的軟件。
• 在軟件質量方面強調以下三個要點:
  ①軟件必須滿足用戶規定的需求②軟件應遵循規定標準所定義的一系列開發準則③軟件還應滿足某些隱含的需求。
• 軟件質量保證包括與以下七個主要活動相關的各種任務:
  ①應用技術方法②進行正式的技術評審③測試軟件④標準的實施⑤控制變更⑥度量⑦記錄、保存和報告。

3. 軟件評審

軟件評審的內容包括以下三個方面：

• 設計質量的評審： 包括評審軟件的規格說明書是否符合用戶的要求;評審可靠性;評審保密措施的實施情況;評審操作特性的實施情況;評審性能;評審軟件是否具有可修改性、可擴充性、可互換性和可移植性;評審軟件可測試性;評審軟件可復用性。
• 程序質量的評審： 從開發者的角度進行評審，與開發技術直接相關，著眼于軟件本身的結構與運行環境的接口，以及變更帶來的影響。
• 與運行環境的接口： 運行環境包括硬件、其他軟件和用戶，主要檢查項目與硬件的接口，與用戶的接口

4. 軟件容錯技術

提高軟件質量和可靠性的技術大致分為兩類：避開錯誤和容錯技術。實現容錯的主要手段是冗余，常見的冗余技術有:

• 結構冗余： 又分為靜態冗余、動態冗余和混合冗余。
• 信息冗余： 為檢測或糾正正在運算或傳輸中的信息錯誤需外加的一部分信息。
• 時間冗余： 以重復執行指令或程序來消除瞬時錯誤帶來的影響。
• 冗余附加技術： 為實現上述冗余技術所需要的資源和技術，包括程序、指令、數據、存放和調動它們的空間和通道等。

九、軟件度量

1. 軟件度量分類

軟件度量用于對產品及開發產品的過程進行度量，如成本、效益、開發人員的生產率、可靠性、可維護性等。軟件度量的方法：
（1）面向規模的度量
面向規模的度量主要是通過對質量和生產率的測量進行規范化得到的，而這些量都是根據開發過的軟件的規模得到的。面向規模的度量公式如下表所示

（2）面向功能的度量
面向功能的度量以功能測量數據為規范化值。應用最廣泛的面向功能的度量是功能點(FP）。功能點是根據軟件信息域的特性及復雜性來計算的。

2. 軟件復雜性度量

軟件復雜性度量是指理解和處理軟件的難易程度。軟件復雜性度量的參數有很多，主要包括：①規模；②難度；③結構；④智能度。軟件復雜性包括程序復雜性和文檔復雜性。
典型的程序復雜性度量有McCabe環路復雜性度量和Halstead復雜性度量。
McCabe度量法是一種基于程序控制流的環路復雜性度量方法，以圖論為工具，先畫出程序圖退化的程序流程圖），然后用該圖的環路數作為程序復雜性的度量值。

在一個強連通的有向圖G中，環路的個數V(G)山以下公式給出：
V(G) = m - n+ 2p
其中，V(G)是有向圖G中的環路數，m是圖G中弧的個數，n是圖G中的結點數，p是G中的強連通分量個數。

McCabe環路復雜性度量定量給出了程序的邏輯復雜度，還可以用下述3種方法中的任何一種來計算環路復雜度：
（1）程序圖G中的區域數等于環路復雜度（封閉區域數+1（一個非封閉區域））。
（2）程序圖G的環形復雜度V(G)= E - N＋2，其中，E是程序圖中邊的條數，N是結點數。
（3）程序圖G的環形復雜度V(G) = P+ 1，其中，P是程序圖中判定結點(有2條輸出弧）的數目。有n (n>2)條輸出弧的判定結點對應程序中的n-1個判斷。 (個人感覺方法（3）最好用，又快又簡單)

十、軟件工具與軟件開發環境

（1）軟件工具
對應于軟件開發的各種活動，軟件開發工具通常有需求分析工具、設計工具、編碼與排錯工具、測試工具等。

（2）軟件開發環境
軟件開發環境(Software Development Enviromment）指支持軟件產品開發的軟件系統，它由軟件工具集和環境集成機制構成。