本書筆記目錄鏈接

上篇

第2章 軟件工程基礎知識

“軟件工程”概念在1968年的“軟件危機”會議中提出。

IEEE 在1983年對軟件工程的定義：軟件工程是開發(fā)、運行、維護和修復軟件的系統(tǒng)方法。

電氣和電子工程師協(xié)會，IEEE，Institute of Electrical and Electronics Engineers

軟件工程專家 Boehm 在1983年提出了軟件工程的7條基本原理：

1. 用分階段的生命周期計劃嚴格管理
2. 堅持進行階段評審
3. 實行嚴格的產(chǎn)品控制
4. 采用現(xiàn)代程序設計技術
5. 結果應能清楚地審查
6. 開發(fā)小組的人員應該少而精
7. 承認不斷改進軟件工程實踐的必要性

軟件工程方法學包含3個要素：方法、工具和過程。

• 方法：完成軟件開發(fā)的各項任務的技術方法。
• 工具：為運用方法而提供的軟件工程支撐環(huán)境。
• 過程：為獲得高質量的軟件所需要完成的一系列任務的框架。

本章要點：

• 軟件需求分析與定義；
• 軟件設計、測試與維護；
• 軟件復用；
• 軟件質量保證及質量評價；
• 軟件配置管理；
• 軟件開發(fā)環(huán)境；
• 軟件過程管理。

2.1 軟件需求分析與定義

根據(jù) Standish Group 對23000個項目進行的研究結果表明，28%的項目徹底失敗，46%的項目超出經(jīng)費預算或者超出工期，有26%的項目獲得成功。而在這些高達74%的不成功項目中，有60%的失敗是源于需求問題。

2.1.1 軟件需求與需求過程

1. 什么是軟件需求

軟件需求就是系統(tǒng)必須完成的事，以及必須具備的品質。包括：

• 功能需求
  產(chǎn)品必須執(zhí)行的動作。

• 非功能需求
  必須具備的屬性或品質，如可靠性、性能、擴展性等。

• 設計約束
  限制條件、補充規(guī)約，通常是對解決方案的約束說明。

其他相關概念：

• 業(yè)務需求（Business Requirement）
  反映組織機構或客戶對系統(tǒng)、產(chǎn)品高層次的目標要求。

• 用戶需求（User Requirement）
  指描述用戶使用產(chǎn)品必須要完成什么任務，怎么完成的需求。

• 系統(tǒng)需求（System Requirement）
  指從系統(tǒng)的角度來說明軟件的需求。

2. 需求工程

需求工程是一個包括創(chuàng)建和維護系統(tǒng)需求文檔所必需的一切活動的過程，通常包括：

• 需求開發(fā)

  需求開發(fā)對于需求工程而言重于需求管理。包括四個階段：

  • 需求捕獲
  • 需求分析
  • 編寫規(guī)格說明書
  • 需求驗證

• 需求管理

  包括：

  • 定義需求基線
  • 處理需求變更
  • 需求跟蹤

2.1.2 需求調查與問題定義

想做好需求調查必須清楚了解的3個問題：

• What：搜集什么信息
• Where：從什么地方搜集這些信息
• How：用什么機制或技術搜集這些信息

1. 要捕獲的信息

從宏觀的角度看，要捕獲的信息包括三類：

• 與問題域相關的信息（如業(yè)務資料、業(yè)務處理流程等）
• 與要求解決的問題相關的信息
• 用戶對系統(tǒng)的特別期望與施加的任何約束信息

2. 信息的來源

對涉眾（風險承擔人、項目干系人）進行分類，從每一類涉眾中找1~2名代表。

3. 需求捕獲技術

常用技術：

• 用戶訪談

  • 準備問題：圍繞想要獲取的信息展開，設計一系列的問題，按順序組織起來。預先準備好記錄方式。
  • 訪談時的技巧：注意措辭，保持氣氛輕松，語言通俗化，訪談前對相關知識的準備保證理解與認識。
  • 應該詢問的問題：自己的問題是否相關？回答是否正式？對方是否為回答此問題合適人選？是否問了過多的問題？詢問被訪者還希望自己問他什么問題，應該見哪些人？

• 用戶調查
  缺點：缺乏靈活性，反饋的信息不全面。
  補足：用戶調查與用戶訪談結合使用。先調查，整理分析后進行小范圍的用戶訪談。

• 現(xiàn)場觀摩

• 文檔考古

• 聯(lián)合討論會
  參與人數(shù)6~18人，召開時間1 ~ 5小時。
  會議流程：

  1. 提前將與討論主題相關的資料分發(fā)給會議參與人
  2. 與會者互相認識
  3. 針對所列舉的問題進行逐項專題討論
  4. 對原有系統(tǒng)、類似系統(tǒng)的不足進行開放性交流
  5. 大家對新的解決方案的設想

  記錄會議中討論的想法、問題、不足，形成要點清單，針對清單進行整理，明確優(yōu)先級并進行評審。

4. 需求捕獲的策略

需求過程4階段（需求捕獲、需求分析、需求規(guī)格 、需求驗證）采用迭代的方式進行。

2.1.3 可行性研究

1. 可行性研究工作的基礎

問題定義的關鍵是清晰地界定出問題內(nèi)容、性質，以及系統(tǒng)的目標、規(guī)模等內(nèi)容，并形成完整的書面報告。

2. 可行性研究工作的任務

• 技術可行性
• 經(jīng)濟可行性
• 社會可行性

3. 可行性研究工作的步驟

1. 核實問題定義與目標
   具體來說，就是仔細閱讀問題定義的相關材料，對該問題所涉及的領域知識進行學習、考證，然后通過走訪相關人員進行驗證與核實。
   這一步驟的關鍵目標是：使問題定義更加清晰、明確、沒有歧義性，并且對系統(tǒng)的目標、規(guī)模，以及相關約束與限制條件做出更加細致的定義，確保可行性研究小組的所有成員達成共識。

2. 研究分析現(xiàn)有系統(tǒng)
   “現(xiàn)有系統(tǒng)” 不僅包括舊的軟件系統(tǒng)，還包括舊的非計算機系統(tǒng)。

3. 為新系統(tǒng)建模
   建模的目的是為了獲得一個對新系統(tǒng)的框架認識、概念性認識。
   常見技術：

• 系統(tǒng)上下文關系范圍圖
• 實體-關系圖
• 用例模型
• 域模型
• IPO 表

4. 客戶復核

5. 提出并評價解決方案
   應該盡量列舉出各種可行的解決方案，并且對這些解決方案的優(yōu)點、缺點做一個綜合性的評價，以便下一步?jīng)Q策。

6. 確定最終推薦的解決方案
   成本效益分析：

• 成本估計
  估算工作量的工具：歷史數(shù)據(jù)與經(jīng)驗模型（功能點分析，COCOMO 分析等）。

• 效益分析
  在效益分析之前應該首先對該系統(tǒng)應用之后，將會來的直接、間接收益，以及成本降低的具體數(shù)額進行量化，并且通過經(jīng)濟學的相關模型來進行分析。

常見概念：

• 貨幣的時間價值
• 投資回收期
• 純收入
• 投資回報率

7. 草擬開發(fā)計劃
8. 以書面的形式提交《可行性分析報告》并進行審查。

2.1.4 需求分析

定義：所謂分析就是通過對問題域的研究，獲得對該領域特性及存在于其中（需要解決）的問題特性的透徹理解并用文檔說明。

1. 需求分析的工作任務

Karl E.Wiegers 在《軟件需求》中指出需求分析工作通常包括7個方面。

1. 繪制系統(tǒng)上下文范圍關系圖
   用于定義系統(tǒng)與系統(tǒng)外部實體間的界限和接口的簡單模型，它可以為需求確定一個范圍。DFD 的0層圖。

2. 創(chuàng)建用戶接口原型

3. 分析需求的可行性

4. 確定需求的優(yōu)先級
   需求的優(yōu)先級可以采用滿意度/非滿意度指標進行說明（取值均為1 ~ 5）。

5. 為需求建立模型

6. 創(chuàng)建數(shù)據(jù)字典

7. 使用質量功能配置（QFD）

質量功能配置，QFD，Quality Function Deployment

2. 需求建模

Alan Davis 主張需要把用文字表示的需求和用圖形表示的需求結合起來。用圖形表示的需求，就是需求建模，獲得分析模型。分析模型有助于檢測需求的不一致性、模糊性、錯誤及遺漏。

2.1.5 流行的需求分析方法論

按照分解方式不同分類：

• 結構化分析方法

結構化分析方法，SA，Structured Analysis

• 軟系統(tǒng)方法

過渡性的方法論，并未真正流行過。以 Checkland 方法為代表。

• 面向對象分析方法

面向對象分析方法，OOA，Object Oriented Analysis

• 面向問題域的分析

面向問題域的分析，PDOA，Problem Domain Oriented Analysis
尚處在研究階段，并未廣泛應用。
小鐳：今天情況怎樣？

1. 結構化分析

把系統(tǒng)看作一個過程的集合體。

工具：

• 數(shù)據(jù)流圖
• 數(shù)據(jù)字典
• 結構化語言
• 判定表
• 判定樹

結構化系統(tǒng)分析方法從總體上看是一種強烈依賴數(shù)據(jù)流圖的自頂向下的建模方法。

如何進行結構化分析：

1. 研究“物質環(huán)境”
   畫出當前系統(tǒng)的數(shù)據(jù)流圖。

2. 建立系統(tǒng)邏輯模型
   在第一步的基礎上，畫出相對真實系統(tǒng)的等價邏輯數(shù)據(jù)流圖。

3. 劃清人機界限

2. 數(shù)據(jù)流圖

數(shù)據(jù)流圖，DFD，Data Flow Diagram

基本元素：

• 過程
• 外部實體
• 數(shù)據(jù)存儲
• 數(shù)據(jù)流
• 實時連接
  過程執(zhí)行時，外部實體與過程之間的來回通信。

對過程0的分解，稱之為 DFD 0層圖。

3. 細化記錄 DFD 部件

1. 結構化語言
2. 決策表和決策樹
3. 數(shù)據(jù)字典
   每條目包含信息：
   • 名稱
   • 何處使用/如何使用
   • 內(nèi)容描述
   • 補充信息

數(shù)據(jù)字典實例：
客戶基本信息=客戶編號+客戶名稱+身份證號碼+手機
客戶編號={0···9}8
客戶名稱={字}4
身份證號碼=[{0···9}15|{0···9}18]
手機=[{0···9}11|{0···9}12]

4. 實體-關系圖

實體-關系圖，E-R 圖，Entity Relationship Diagram

實體是一個概念，用來抽象地表示一組相類似的事物的所有實例。

結構化分析的不足：

• 對問題域的研究力度不夠大
• 分析與設計之間缺乏清晰界限
• 沒有一個真正的功能規(guī)格說明
• 需求實質上是根據(jù)滿足該需求的某一特定系統(tǒng)的內(nèi)部設計來加以說明的
• 內(nèi)部設計的開發(fā)使用的則是不可靠的內(nèi)部設計技術-功能分解
• 不適用于很多類型的應用

小鐳：或許結構化分析過于抽象，這加大了分析階段的復雜性，使問題的描述、閱讀、溝通變得困難。

5. 面向問題域的分析

面向問題域的分析更多地強調描述，而較少強調建模。

分析過程：

• 搜集基本的信息并開發(fā)問題框架，以建立問題域的類型
• 在問題框架類型的指導下，進一步搜集詳細信息并給出一個問題域相關特性的描述

2.2 軟件設計

2.2.1 軟件設計基本原則

1. 信息隱蔽

Parnas 指出：每個模塊的實現(xiàn)細節(jié)對于其他模塊來說是隱蔽的，模塊中所包含的信息（包括數(shù)據(jù)和過程）不允許其他不需要這些信息的模塊使用。這提高了軟件的可維護性和可靠性。

2. 模塊獨立性

指軟件系統(tǒng)中每個模塊只涉及軟件要求的具體子功能，而和軟件系統(tǒng)中其他的模塊接口是簡單的。

度量模塊獨立性的兩個準則：

• 耦合
  模塊之間聯(lián)系緊密程度的度量。

• 內(nèi)聚
  模塊內(nèi)部各個元素彼此結合的緊密程度的度量。

高內(nèi)聚，低耦合的模塊獨立性較強。

高 《--- 內(nèi)聚性 --- 低

功能內(nèi)聚 | 信息內(nèi)聚 | 通信內(nèi)聚 | 過程內(nèi)聚 | 時間內(nèi)聚 | 邏輯內(nèi)聚 | 巧合內(nèi)聚

強 《--- 模塊獨立性 --- 弱

功能單一 ------ 功能分散

各類聚合性：

• 功能內(nèi)聚
  模塊中所有部分都是為了完成一項具體功能而協(xié)同工作，緊密聯(lián)系，不可分割的。

• 信息內(nèi)聚
  模塊所完成的各個功能都在同一數(shù)據(jù)結構上操作，每一項功能有一個唯一的入口點。

• 通信內(nèi)聚
  如果一個模塊內(nèi)各功能部分都使用了相同的輸入數(shù)據(jù)，或產(chǎn)生了相同的輸出數(shù)據(jù)，則稱之為通信內(nèi)聚模塊。

• 過程內(nèi)聚
  把流程圖中的某一部分劃出組成模塊，就得到過程內(nèi)聚模塊。

• 時間內(nèi)聚
  模塊的各個功能的執(zhí)行與時間有關。

• 邏輯內(nèi)聚
  組合相關功能。

• 巧合內(nèi)聚
  又稱偶然內(nèi)聚，指模塊內(nèi)部的聯(lián)系很松散。

低 --- 耦合性 ---》 高

非直接耦合 | 數(shù)據(jù)耦合 | 標記耦合 | 控制耦合 | 外部耦合 | 公共耦合 | 內(nèi)容耦合

強 《--- 模塊獨立性 --- 弱

各類耦合性：

• 非直接耦合
  模塊之間沒有直接聯(lián)系。

• 數(shù)據(jù)耦合
  模塊之間通過簡單數(shù)據(jù)參數(shù)來交換輸入、輸出信息。

• 標記耦合
  一組模塊通過參數(shù)表傳遞記錄信息。

• 控制耦合
  一個模塊通過傳送開關、標志、名字等控制信息控制選擇另一模塊的功能。

• 外部耦合
  一組模塊都訪問同一全局簡單變量而不是同一全局數(shù)據(jù)結構，而且不是通過參數(shù)表傳遞該全局變量的信息。

• 公共耦合
  一組模塊都訪問同一個公共數(shù)據(jù)環(huán)境。

• 內(nèi)容耦合
  一個模塊直接訪問另一個模塊的內(nèi)部數(shù)據(jù)；一個模塊不通過正常入口轉到另一模塊內(nèi)部；一個模塊有多個入口。

2.2.2 結構化設計方法

實施過程：

1. 總結出系統(tǒng)應有的功能，對一個功能，從功能完成的過程考慮，將各個過程列出，標志出過程轉向和傳遞的數(shù)據(jù)。
2. 細化數(shù)據(jù)流。
3. 分析過程之間的耦合關系，合理地劃分模塊，提高內(nèi)聚性。

1. 系統(tǒng)結構圖中的模塊

在系統(tǒng)結構圖中，不能再分解的底層模塊稱為原子模塊。

完全因子分解的系統(tǒng)：系統(tǒng)的全部實際加工都由原子模塊來完成，而其他所有非原子模塊僅僅執(zhí)行控制協(xié)調功能。這是理想中的系統(tǒng)。

結構圖中的常見模塊：

• 傳入模塊
• 傳出模塊
• 變換模塊
• 協(xié)調模塊

區(qū)別系統(tǒng)結構圖與程序流程圖

結構圖，SC，Structured Charts

結構圖反映模塊間的隸屬關系（調用與層次），著眼軟件系統(tǒng)的總體結構，并不涉及模塊內(nèi)部的細節(jié)。

流程圖反映的是程序的執(zhí)行順序及其依賴條件，表達執(zhí)行程序的具體算法。

有太多項目失敗就是因為它們沒有明確的目標就開始了。

2. 系統(tǒng)結構圖中的主要成分

1. 模塊
2. 模塊間的調用關系
3. 模塊間的通信
4. 輔助控制符號

3. 常用的系統(tǒng)結構圖

1. 變換型系統(tǒng)結構圖
   從外部取得數(shù)據(jù)，處理后再傳回外部。

2. 事務型系統(tǒng)結構圖
   數(shù)據(jù)被轉換成一個事務項并加以計算，然后根據(jù)結果選擇數(shù)據(jù)流。

3. 混合型系統(tǒng)結構圖
   現(xiàn)實中多為此類。

2.2.3 用戶界面設計

一個好的用戶界面應具有的特點：

1. 可使用性
2. 靈活性
3. 復雜性和可靠性

2.2.4 設計評審

評審采用評審會議的形式進行。

角色：

• 設計負責人

  • 承擔項目的全部設計管理任務
  • 對設計質量、進度及各項設計間的組織協(xié)調等全面負責
  • 對各單項工程之間的銜接、協(xié)調和總體方案質量負主要責任
  • 負責編寫總說明，匯編總概算。

• 高級管理人員

  • 定主審員
  • 審批評審記錄

• 主審員

  • 在評審會前提出項目的書面評審意見
  • 確定評審組、確定評審結果并填寫評審記錄

• 評審組

  • 專業(yè)評審組評委表決通過項目初評結論并報綜合評審會議，通過設計報告。

2.3 軟件測試

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

軟件測試并不等于程序測試。軟件測試應貫穿于軟件定義與開發(fā)的整個期間。各階段所得到的文檔以及源程序，都應成為軟件測試的對象。

2.3.1 軟件測試

測試用例是為特定目標開發(fā)的測試輸入、執(zhí)行條件和預期結果的集合。

1. 黑盒測試

又稱為功能測試或數(shù)據(jù)驅動測試。把測試對象看做一個空盒子，不考慮程序的內(nèi)部邏輯結構和內(nèi)部特性，依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。

主要檢查內(nèi)容：

• 功能的正確性與完整性
• 輸入輸出接口的正確性
• 數(shù)據(jù)結構的正確性
• 性能極其穩(wěn)定性

測試用例設計方法：

1. 等價類劃分
   步驟：
   1. 劃分等價類
   2. 選取測試用例

等價類是指某個輸入域的子集合。在該子集合中，各個輸入數(shù)據(jù)對揭露程序中的錯誤是等效的。

有效等價類與無效等價類。

2. 邊界值分析
   經(jīng)驗表明，大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上。

3. 錯誤推測法
   靠經(jīng)驗和直覺推測程序中可能存在的各種錯誤，有針對性地編寫測試用例。

4. 因果圖
   此方法最終生成的就是判定表，適于檢查程序輸入條件的各種組合情況。

   步驟：

   1. 分析原因（輸入）與結果（輸出）并標示編號因果組
   2. 分析原因與結果之間的關系，畫出因果圖
   3. 在因果圖上標明不可能的情況并指出約束或限制條件
   4. 把因果圖轉換成判定表
   5. 利用判定表的每一列設計測試用例

2. 白盒測試

又稱為結構測試或邏輯驅動測試。白盒測試把測試對象看做一個透明的盒子,它允許測試人員利用程序內(nèi)部的邏輯結構和有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。

主要檢查內(nèi)容：

• 對程序模塊的所有獨立執(zhí)行路徑至少測試一次
• 對所有的邏輯判定，取 “真” 與取 “假” 兩種情況都至少測試一次
• 在循環(huán)的邊界和運行界限內(nèi)執(zhí)行循環(huán)體
• 測試內(nèi)部數(shù)據(jù)結構的有效性

3. 邏輯覆蓋

此技術屬于白盒測試，是以程序內(nèi)部的邏輯結構為基礎的設計用例的技術。

包括：

• 語句覆蓋
  設計若干個測試用例，使每一可執(zhí)行語句至少執(zhí)行一次。

• 判定覆蓋
  設計若干個測試用例，使程序中每個判斷的取真分支和取假分支至少經(jīng)歷一次，又稱為分支覆蓋。

• 條件覆蓋
  設計若干個測試用例，使程序中每個判斷的每個條件的可能取值至少執(zhí)行一次。

• 判定-條件覆蓋
  設計足夠的測試用例，使判斷中每個條件的所有可能取值至少執(zhí)行一次，每個判斷中的每個條件的可能取值至少執(zhí)行一次。

• 條件組合覆蓋
  設計足夠的測試用例，使判斷的所有可能的條件取值組合至少執(zhí)行一次。

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

2.3.2 軟件測試策略

1. 單元測試

也稱為模塊測試，是針對每個模塊進行的測試。

驅動模塊是指在單元測試和集成測試中，協(xié)調輸入和輸出的測試程序。

樁模塊指模擬被調用單元的程序。

單元測試可測試內(nèi)容：

1. 模塊接口
2. 局域數(shù)據(jù)結構
   數(shù)據(jù)類型，變量，初始值與默認值。
3. 獨立路徑
   路徑錯誤。
4. 錯誤處理測試
5. 邊界條件測試

2. 集成測試

把模塊組裝為系統(tǒng)的方式有兩種：

• 一次性組裝方式
• 增殖式組裝方式

對關鍵模塊及早進行測試。

3. 確認測試

驗證軟件的功能、性能及其他特性是否與用戶的要求一致。

主要步驟：

1. 有效性測試
2. 軟件配置復査
3. 驗收測試

應交付文檔：

• 確認測試分析報告
• 最終的用戶手冊和操作手冊
• 項目開發(fā)總結報告

4. 系統(tǒng)測試

在實際運行環(huán)境下進行一系列的測試。

5. α 測試和 β 測試

α 測試

α 測試是由一個用戶在開發(fā)環(huán)境或模擬實際操作環(huán)境下進行的測試。

α 測試目的：評價軟件產(chǎn)品的 FLURPS（功能、局域化、可使用性、可靠性、性能、支持）

α 測試注重產(chǎn)品的界面和特色。

β 測試

β 測試是由多個用戶在實際使用環(huán)境下進行的測試。

β 測試處在整個測試的最后階段。產(chǎn)品的所有手冊文本也應該在此階段完全定稿。

2.3.3 軟件測試類型

1. 功能測試

2. 可靠性測試

主要評價指標:

平均故障間隔時間，MTBF，Mean Time Between Failure

平均故障修復時間，MTTR，Mean Time To Repair

3. 強度測試

4. 性能測試

5. 恢復測試

6. 啟動/停止測試

7. 配置測試

8. 安全性測試

9. 可使用性測試

10. 安裝測試

11. 過程測試

檢查由人工完成的、為了配合計算機的工作，就是過程測試。

12. 容量測試

13. 文檔測試

14. 兼容性測試

2.3.4 面向對象的軟件測試

面向對象的開發(fā)階段：

1. 面向對象分析，OOA，Object Oriented Analysis
2. 面向對象設計，OOD，Object Oriented Design
3. 面向對象編程，OOP，Object Oriented Programming

面向對象測試：

1. OOA Test

OOA 直接映射問題空間，全面地將問題空間中實現(xiàn)功能的現(xiàn)實抽象化。將問題空間中的實例抽象為對象，用對象的結構反映問題空間的復雜實例和復雜關系，用屬性和服務表示實例的特性和行為。行為相對穩(wěn)定，結構則相對不穩(wěn)定。

2. OOD Test

OOD 以 OOA 為基礎歸納類，并建立類結構或進一步構造成類庫，實現(xiàn)分析結果對問題空間的抽象。

因 OOD 是 OOA 的進一步細化和更高層的抽象。所以，OOD 與 OOA 的界限通常難以區(qū)分。

3. OOP Test

考慮：

1. 數(shù)據(jù)成員是否滿足數(shù)據(jù)封裝的要求
2. 類是否實現(xiàn)了要求的功能

4. 面向對象的單元測試

考慮：

1. 繼承的成員函數(shù)是否都不需要測試
2. 對父類的測試是否能照搬到子類

5. 面向對象的集成測試

基于單元測試對成員函數(shù)行為正確性的保證，集成測試只關注系統(tǒng)的結構和內(nèi)部的相互作用。

靜態(tài)測試：檢測程序結構是否符合設計要求。
動態(tài)測試：優(yōu)化測試用例，減少測試工作量，使測試達到一定的覆蓋標準。

6. 面向對象的系統(tǒng)測試

2.4 軟件維護

2.4.1 軟件的可維護性

1. 軟件具有可維護性

決定軟件可維護性的三個因素：

1. 可理解性
2. 可測試性
3. 可修改性

2. 采用軟件工程提高軟件的可維護性

軟件系統(tǒng)的文檔可分為用戶文檔和系統(tǒng)文檔兩大類。

用戶文檔主要是描述軟件功能和使用方法，至少包括：

• 功能說明
• 安裝文檔
• 用戶使用手冊
• 參考手冊
• 管理員指南

系統(tǒng)文檔關心實現(xiàn)細節(jié)，描述系統(tǒng)需求、設計、實現(xiàn)和測試等各個方面。

3. 注重可維護性的開發(fā)過程

在開發(fā)過程中提高軟件的可維護性：

• 在需求分析階段，應該對將來要改進的和可能會修改的部分加以明確說明
• 在設計階段，應該盡量遵循“ 高內(nèi)聚低耦合” 的模塊設計原則
• 在編碼階段，應該采用科學的代碼規(guī)范
• 在測試階段，應重視測試相關文檔的的編寫
• 在維護階段，要有嚴格的配置管理，同步更新相關系統(tǒng)文檔

4. 可維護性的度量

1. 外部度量

MTTR 指標度量。

可維護指標 M = 1 / (1 + MTTR)

2. 內(nèi)部度量

軟件復雜性相關因素：

• 環(huán)路數(shù)
• 軟件規(guī)模
• 其他因素

建立經(jīng)驗模型的步驟：

1. 確定影響可維護性的若干主要因素，并為其制訂尺度
2. 用大量的現(xiàn)有案例，計算出一個包含影響因素及其權值的多項式模型
3. 利用這個經(jīng)驗模型分析新的軟件，再根據(jù)實際的維護活動的感受進行校準
4. 重復校準過程

2.4.2 軟件維護的分類

從性質上分為：

• 糾錯型維護（21%）
• 適應型維護（25%）
• 預防型維護（4%）
• 完善型維護（50%）

注：括號中為 Lientz 和 Swanson 在1980年的調查結果。

2.4.3 軟件維護的工作量

維護活動分類：

• 生產(chǎn)類
• 非生產(chǎn)類（熟悉代碼，理解結構等）

M = P + K^(c-d)

M - 維護總工作量
P - 生產(chǎn)類活動工作量
K - 經(jīng)驗常數(shù)
c - 軟件復雜程度
d - 維護人員對軟件的熟悉程度

影響維護工作的其他因素：

• 維護工作本身是否規(guī)范，是否按軟件工程的正確方法進行
• 軟件系統(tǒng)的類型不同，維護工作量也有區(qū)別

按照對真實世界的依賴程度，軟件系統(tǒng)可以分為：抽象系統(tǒng)、近似系統(tǒng)和模擬系統(tǒng)。

• 硬件因素

2.4.4 軟件維護作業(yè)的實施和管理

1. 建立維護組織

2. 提出維護需求

3. 實施維護作業(yè)

每次維護活動的實施都要經(jīng)歷如下的步驟：

• 確認維護需求
• 制訂維護計劃
• 編碼
• 測試
• 交付用戶

4. 記錄維護要素

5. 評價維護活動

2.4.5 軟件再生工程

軟件的再生工程通常包括以下六類活動：

1. 篩選
2. 文檔重構
3. 逆向工程
4. 代碼重構
5. 數(shù)據(jù)重構
6. 重新開發(fā)

2.5 軟件開發(fā)環(huán)境

2.5.1 軟件開發(fā)環(huán)境概述

軟件開發(fā)環(huán)境，SDE，Software Development Environment

集成式項目支援環(huán)境，IPSE，Integrated Project Support Environment

集成型開發(fā)環(huán)境通常可由工具集和環(huán)境集成機制兩部分組成。

環(huán)境集成機制：

• 數(shù)據(jù)集成機制

數(shù)據(jù)集成機制提供統(tǒng)一的數(shù)據(jù)模式和數(shù)據(jù)接口規(guī)范，需要相互協(xié)作的工具通過這種統(tǒng)一的模式與規(guī)范交換數(shù)據(jù)。

• 控制集成機制

控制集成機制支持各工具或各開發(fā)活動之間的通信、切換、調度和協(xié)同工作，并支持軟件開發(fā)過程的描述、執(zhí)行和轉接。

• 界面集成機制

2.5.2 軟件開發(fā)環(huán)境的功能與分類

按軟件開發(fā)模型及開發(fā)方法分類：

• 瀑布模型
• 演化模型
• 螺旋模型
• 噴泉模型
• 結構化方法
• 信息模型方法
• 面向對象方法

按功能及結構特點分類：

• 單體型
• 協(xié)同型
• 分散型
• 并發(fā)型

按應用范圍分類：

• 通用型
• 專用型

按開發(fā)階段分類：

• 前端開發(fā)環(huán)境
• 后端開發(fā)環(huán)境
• 軟件維護環(huán)境
• 逆向工程環(huán)境

2.5.3 軟件開發(fā)環(huán)境的結構

開發(fā)環(huán)境組成：

1. 工具集
2. 集成機制
3. 環(huán)境信息庫

環(huán)境信息庫是軟件開發(fā)環(huán)境的核心，用以儲存與系統(tǒng)開發(fā)有關的信息并支持信息的交流與共享。

4. 過程控制和消息服務器
5. 環(huán)境用戶界面

開發(fā)環(huán)境的結構可分為四層：

1. 宿主層

包括基本宿主硬件和基本宿主軟件。

2. 核心層

包括工具組、環(huán)境數(shù)據(jù)庫和會話系統(tǒng)。

3. 基本層

包括至少一組工具，如編譯工具、調試工具等。

4. 應用層

以基本層為基礎補充某些工具，以適應應用軟件的要求。

2.5.4 軟件開發(fā)環(huán)境的發(fā)展

集成計算機輔助軟件設計，ICASE，Integrated Computer-Aided Software Engineering

ICASE 信息中心庫功能：

1. 數(shù)據(jù)完整性
2. 信息共享
3. 數(shù)據(jù)-工具集成
4. 數(shù)據(jù)-數(shù)據(jù)集成
5. 方法學實施
6. 文檔標準化

ICASE 的最終目標是實現(xiàn)應用軟件的全自動開發(fā)，即開發(fā)人員只要寫好軟件的需求規(guī)格說明書，軟件開發(fā)環(huán)境就自動完成從需求分析開始的所有的軟件開發(fā)工作，自動生成供用戶直接使用的軟件及有關文檔。