一、軟件工程概述

軟件開發(fā)和維護過程中所遇到的各種問題稱為“軟件危機”。
軟件工程是指應(yīng)用計算機科學(xué)、數(shù)學(xué)及管理科學(xué)等原理，以工程化的原則和方法來解決軟件問題的工程，其目的是提高軟件生產(chǎn)率、提高軟件質(zhì)量、降低軟件成本。

1、計算機軟件

計算機軟件是指計算機系統(tǒng)中的程序及其文檔。
程序是計算任務(wù)的處理對象和處理規(guī)則的描述。
文檔是為了便于了解程序所需的闡述性資料。

2、軟件工程基本原理

（1）用分階段的生命周期計劃嚴(yán)格管理

這條基本原理意味著應(yīng)該把軟件生命周期劃分成若干個階段，并相應(yīng)地制訂出切實可行的計劃，然后嚴(yán)格按照計劃對軟件的開發(fā)與維護工作進行管理。
六類計劃：

• 項目概要計劃
• 里程碑計劃
• 項目控制計劃
• 產(chǎn)品控制計劃
• 驗證計劃
• 運行維護計劃

（2）堅持進行階段評審

（3）實現(xiàn)嚴(yán)格的產(chǎn)品控制

（4）采用現(xiàn)代程序設(shè)計技術(shù)

（5）結(jié)果應(yīng)能清楚地審查

（6）開發(fā)小組的人員應(yīng)少而精

（7）承認(rèn)不斷改進軟件工程實踐的必要性

3、軟件生存周期

（1）可行性分析與項目開發(fā)計劃

• 這個階段主要確定軟件的開發(fā)目標(biāo)及其可行性。
• 這個階段的參加人員有用戶、項目負責(zé)人和系統(tǒng)分析師。
• 該階段產(chǎn)生的主要文檔有可行性分析報告和項目開發(fā)計劃。

（2）需求分析

• 需求分析階段的任務(wù)不是具體地解決問題，而是準(zhǔn)確地確定軟件系統(tǒng)必須做什么，確定軟件系統(tǒng)的功能、性能、數(shù)據(jù)和界面等要求，從而確定系統(tǒng)的邏輯模型。
• 該階段的參加人員有用戶、項目負責(zé)人和系統(tǒng)分析師。
• 該階段產(chǎn)生的主要文檔有軟件需求說明書。

（3）概要設(shè)計

• 在概要設(shè)計階段，開發(fā)人員要把確定的各項功能需求轉(zhuǎn)換成需要的體系結(jié)構(gòu)。
• 這個階段的參加人員有系統(tǒng)分析師和軟件設(shè)計師。
• 該階段產(chǎn)生的主要文檔有概要設(shè)計說明書。

（4）詳細設(shè)計

• 主要任務(wù)是對每個模塊完成的功能進行具體描述，要把功能描述轉(zhuǎn)變?yōu)榫_的、結(jié)構(gòu)化的過程描述。
• 這個階段的參加人員有軟件設(shè)計師和程序員。
• 該階段產(chǎn)生的主要文檔有詳細設(shè)計文檔。

（5）編碼

（6）測試

• 這個階段的參加人員通常是另一部門(或單位) 的軟件設(shè)計師或系統(tǒng)分析師。
• 該階段產(chǎn)生的主要文檔有軟件測試計劃、測試用例和軟件測試報告。

（7）維護

4、軟件過程

軟件開發(fā)中所遵循的路線圖稱為“軟件過程”。

（1）能力成熟度模型（CMM）

研究目的是提供一種評價軟件承接方能力的方法，同時它可以幫助軟件組織改進其軟件過程。
CMM是對軟件組織進化階段的描述。

（2）能力成熟度模型集成（CMMI）

CMMI 是若干過程模型的綜合和改進，能適應(yīng)現(xiàn)代工程的特點和需要，能提高過程的質(zhì)量和工作效率。
CMMI 提供了兩種表示方法：階段式模型和連續(xù)式模型

階段式模型

階段式模型的結(jié)構(gòu)類似于 CMM，它關(guān)注組織的成熟度。

• 初始的：過程不可預(yù)測且缺乏控制。
• 已管理的：過程為項目服務(wù)。
• 已定義的：過程為組織服務(wù)。
• 定量管理的：過程已度量和控制。
• 優(yōu)化的：集中于過程改進。

連續(xù)式模型

連續(xù)式模型關(guān)注每個過程域的能力，一個組織對不同的過程域可以達到不同的過程域能力等級 (Capability Level，CL)。CMMI 中包括 6個過程域能力等級，等級號為 0~5。

• $C{L}_0$(未完成的)：過程域未執(zhí)行或未得到 $C{L}_1$中定義的所有目標(biāo)。
• $C{L}_1$(已執(zhí)行的)：其共性目標(biāo)是過程將可標(biāo)識的輸入工作產(chǎn)品轉(zhuǎn)換成可標(biāo)識的輸出工作產(chǎn)品，以實現(xiàn)支持過程域的特定目標(biāo)。
• $C{L}_2$(已管理的)： 其共性目標(biāo)集中于已管理的過程的制度化。
• $C{L}_3$(已定義級的)：其共性目標(biāo)集中于已定義的過程的制度化。過程是按照組織的剪裁指南從組織的標(biāo)準(zhǔn)過程集中剪裁得到的，還必須收集過程資產(chǎn)和過程的度量，并用于將來對過程的改進。
• $C{L}_4$(定量管理的)：其共性目標(biāo)集中于可定量管理的過程的制度化。使用測量和質(zhì)量保證來控制和改進過程域，建立和使用關(guān)于質(zhì)量和過程執(zhí)行的定量目標(biāo)作為管理準(zhǔn)則。
• $C{L}_5$(優(yōu)化的)：使用量化(統(tǒng)計學(xué)) 手段改變和優(yōu)化過程域，以滿足客戶要求的改變和持續(xù)改進計劃中的過程域的功效。

二、軟件過程模型

也叫軟件開發(fā)模型。
典型的模型有瀑布模型、增量模型、演化模型(原型模型、螺旋模型)、噴泉模型、基于構(gòu)件的開發(fā)模型和形式化方法模型等。

1、瀑布模型（Waterfall Model）

瀑布模型是將軟件生存周期中的各個活動規(guī)定為依線性順序連接的若干階段的模型，包括需求分析、設(shè)計、編碼、測試、運行與維護。它規(guī)定了由前至后、相互銜接的固定次序，如同瀑布流水逐級下落。

瀑布模型是以文檔作為驅(qū)動、適合于軟件需求很明確的軟件項目的模型。
優(yōu)點：容易理解，管理成本低；強調(diào)開發(fā)的階段性早期計劃及需求調(diào)查和產(chǎn)品測試。
缺點：客戶必須能夠完整、正確和清晰地表達他們的需要: 在開始的兩個或 3個階段中，很難評估真正的進度狀態(tài);當(dāng)接近項目結(jié)束時，出現(xiàn)了大量的集成和測試工作;直到項目結(jié)束之前，都不能演示系統(tǒng)的能力。

瀑布模型的一個變體是 V模型

2、增量模型（Incremental Model）

增量模型融合了瀑布模型的基本成分和原型實現(xiàn)的迭代特征

3、演化模型（Evolutionary Model）

演化模型特別適用于對軟件需求缺乏準(zhǔn)確認(rèn)識的情況。典型的演化模型有原型模型和螺旋模型等。

（1）原型模型（Prototype Model）

原型模型開始于溝通，其目的是定義軟件的總體目標(biāo)，標(biāo)識需求，然后快速制訂原型開發(fā)的計劃，確定原型的目標(biāo)和范圍，采用快速射擊的方式對其進行建模，并構(gòu)建原型。被開發(fā)的原型應(yīng)交付給客戶使用，并收集客戶的反饋意見，這些反饋意見可在下一輪中對原型進行改進。在前一個原型需要改進，或者需要擴展其范圍的時候，進入下輪原型的迭代開發(fā)。

分為探索型原型、實驗型原型和演化型原型

（2）螺旋模型（Spiral Model）

螺旋模型將瀑布模型和演化模型結(jié)合起來，加入了兩種模型均忽略的風(fēng)險分析，彌補了這兩種模型的不足。

1. 制訂計劃。確定軟件的目標(biāo)，選定實施方案，明確項目開發(fā)的限制條件。
2. 風(fēng)險分析。分析所選的方案，識別風(fēng)險，消除風(fēng)險。
3. 實施工程。實施軟件開發(fā)，驗證階段性產(chǎn)品。
4. 用戶評估。評價開發(fā)工作，提出修正建議，建立下一個周期的開發(fā)計劃。

4、噴泉模型（Water Fountain Model）

噴泉模型是一種以用戶需求為動力，以對象作為驅(qū)動的模型，適合于面向?qū)ο蟮拈_發(fā)方法。

5、基于構(gòu)件的開發(fā)模型( Component-based Development Model )

基于構(gòu)件的開發(fā)是指利用預(yù)先包裝的構(gòu)件來構(gòu)造應(yīng)用系統(tǒng)。

包括領(lǐng)域工程和應(yīng)用系統(tǒng)工程兩部分。

（1）領(lǐng)域工程

領(lǐng)域工程的目的是構(gòu)建領(lǐng)域模型、領(lǐng)域基準(zhǔn)體系結(jié)構(gòu)和可復(fù)用構(gòu)件庫。

（2）應(yīng)用系統(tǒng)工程

應(yīng)用系統(tǒng)工程的目的是使用可復(fù)用構(gòu)件組裝應(yīng)用系統(tǒng)。

6、 形式化方法模型 ( Formal Methods Model )

形式化方法是建立在嚴(yán)格數(shù)學(xué)基礎(chǔ)上的一種軟件開發(fā)方法，其主要活動是生成計算機軟件形式化的數(shù)學(xué)規(guī)格說明。

7、 統(tǒng)一過程模型

統(tǒng)一過程模型是一種“用例和風(fēng)險驅(qū)動，以架構(gòu)為中心，迭代并且增量”的開發(fā)過程，由UML 方法和工具支持。
統(tǒng)一過程定義了 4 個技術(shù)階段及其制品。

1. 起始階段(Inception Phase )
2. 精化階段( Elaboration Phase)
3. 構(gòu)建階段(Construction Phase)
4. 移交階段 (Transition Phase)
   

8、 敏捷方法（Agile Development）

敏捷開發(fā)的總體目標(biāo)是通過“盡可能早地、持續(xù)地對有價值的軟件的交付”使客戶滿意
敏捷過程的典型方法有很多，每一種方法基于一套原則，這些原則實現(xiàn)了敏捷方法所宣稱的理念(敏捷宣言)。

（1）極限編程XP

由價值觀、原則、實踐和行為4個部分組成，通過行為貫穿于整個生存周期。

1. 4 大價值觀：溝通、簡單性、反饋和勇氣。
2. 5 個原則：快速反饋、簡單性假設(shè)、逐步修改、提倡更改和優(yōu)質(zhì)工作。
3. 12 個最佳實踐：計劃游戲(快速制定計劃、隨著細節(jié)的不斷變化而完善)、小型發(fā)布(系統(tǒng)的設(shè)計要能夠盡可能早地交付)、隱喻(找到合適的比喻傳達信息)、簡單設(shè)計(只處理當(dāng)前的需求，使設(shè)計保持簡單)、測試先行(先寫測試代碼，然后再編寫程序).重構(gòu)(重新審視需求和設(shè)計，重新明確地描述它們以符合新的和現(xiàn)有的需求)、結(jié)隊編程、集體代碼所有制、持續(xù)集成(可以按日甚至按小時為客戶提供可運行的版本)、每周工作 40 個小時、現(xiàn)場客戶和編碼標(biāo)準(zhǔn)。

（2）水晶法 Crystal

（3）并列征求法 Scrum

（4）自適應(yīng)軟件開發(fā) ASD

（5）敏捷統(tǒng)一過程 AUP

敏捷統(tǒng)一過程 (Agile Unified Process，AUP)采用“在大型上連續(xù)”以及在“在小型上迭代”的原理來構(gòu)建軟件系統(tǒng)。

三、需求分析

1、軟件需求

軟件需求指用戶對目標(biāo)軟件系統(tǒng)在功能、行為、性能、設(shè)計約束等方面的期望。
包括

1. 功能需求
2. 性能需求
3. 用戶或人的因素
4. 環(huán)境需求
5. 界面需求
6. 文檔需求
7. 數(shù)據(jù)需求
8. 資源使用需求
9. 安全保密需求
10. 可靠性需求
11. 軟件成本消耗與開發(fā)進度需求等
12. 其他非功能性的需求

2、需求分析原則

1. 必須能夠表示和理解問題的信息域。
2. 必須能夠定義軟件將完成的任務(wù)。
3. 必須能夠表示軟件的行為 (作為外部事件的結(jié)束)。
4. 必須劃分描述數(shù)據(jù)、功能和行為的模型，從而可以分層次地揭示細節(jié)。
5. 分析過程應(yīng)該從要素信息移向細節(jié)信息。

3、需求工程

需求工程是一個不斷反復(fù)的需求定義、文檔記錄、需求演進的過程，并最終在驗證的基礎(chǔ)上凍結(jié)需求。
需求工程可以細分為：

1. 需求獲取
2. 需求分析與協(xié)商
3. 系統(tǒng)建模
   面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法 (SA)、面向?qū)ο蟮姆治龇椒?(OOA)
4. 需求規(guī)約
   需求規(guī)約作為用戶和開發(fā)者之間的一個協(xié)議。包括引言、信息描述、功能描述、行為描述、檢驗標(biāo)準(zhǔn)、參考書目、附錄
5. 需求驗證
6. 需求管理

四、軟件設(shè)計

“怎么做”
主要目的：就是為系統(tǒng)制定藍圖，在各種技術(shù)和實施方法中權(quán)衡利弊，精心設(shè)計，合理地使用各種資源，最終勾畫出新系統(tǒng)的詳細設(shè)計方案。
主要內(nèi)容：包括新系統(tǒng)總體結(jié)構(gòu)設(shè)計、代碼設(shè)計、輸出設(shè)計、輸入設(shè)計、處理過程設(shè)計、數(shù)據(jù)存儲設(shè)計、用戶界面設(shè)計和安全控制設(shè)計等。
常用的設(shè)計方法有以下兩種：面向數(shù)據(jù)流的結(jié)構(gòu)化設(shè)計方法 (SD)、 面向?qū)ο蟮姆治龇椒?OOD)
系統(tǒng)設(shè)計的基本任務(wù)大體上可以分為概要設(shè)計和詳細設(shè)計兩個步驟

（1）概要設(shè)計

1. 設(shè)計軟件系統(tǒng)總計結(jié)構(gòu)
2. 數(shù)據(jù)結(jié)構(gòu)及數(shù)據(jù)庫設(shè)計
3. 編寫概要設(shè)計文檔
   文檔主要有概要設(shè)計說明書、數(shù)據(jù)庫設(shè)計說明書、用戶手冊以及修訂測試計劃。
4. 評審

（2）詳細設(shè)計

1. 對每個模塊進行詳細的算法設(shè)計，用某種圖形、表格和語言等工具將每個模塊處理過程的詳細算法描述出來
2. 對模塊內(nèi)的數(shù)據(jù)結(jié)構(gòu)進行設(shè)計
3. 對數(shù)據(jù)庫進行物理設(shè)計，即確定數(shù)據(jù)庫的物理結(jié)構(gòu)
4. 其他設(shè)計。根據(jù)軟件系統(tǒng)的類型，還可能要進行以下設(shè)計。代碼設(shè)計、輸入/輸出格式設(shè)計、用戶界面設(shè)計
5. 編寫詳細設(shè)計說明書
6. 評審
   
   

五、軟件測試

1、軟件測試與調(diào)試

系統(tǒng)測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程，成功的測試是發(fā)現(xiàn)了至今尚未發(fā)現(xiàn)的錯誤的測試。
測試的目的就是希望能以最少的人力和時間發(fā)現(xiàn)潛在的各種錯誤和缺陷。
信息系統(tǒng)測試應(yīng)包括軟件測試、硬件測試和網(wǎng)絡(luò)測試。

測試原則

1. 應(yīng)盡早、不斷地進行測試。
2. 測試工作應(yīng)該避免由原開發(fā)軟件的人或小組承擔(dān)
3. 在設(shè)計測試方案時，不僅要確定輸入數(shù)據(jù)，而且要根據(jù)系統(tǒng)功能確定預(yù)期輸出結(jié)果。
4. 在設(shè)計測試用例時，不僅要設(shè)計有效、合理的數(shù)據(jù)，也要包含不合理、失效的數(shù)據(jù)
5. 在測試程序時，不僅要檢驗程序是否做了該做的事，還要檢驗程序是否做了不該做的事
6. 嚴(yán)格按照測試計劃來進行，避免測試的隨意性。
7. 妥善保存測試計劃、測試用例，作為軟件文檔的組成部分，為維護提供方便。
8. 測試?yán)佣际蔷脑O(shè)計出來的，可以為重新測試或追加測試提供方便
9. 修改后應(yīng)進行回歸測試
10. 尚未發(fā)現(xiàn)的錯誤數(shù)量與該程序已發(fā)現(xiàn)錯誤數(shù)成正比

測試過程

1. 制訂測試計劃
2. 編制測試大綱
3. 根據(jù)測試大綱設(shè)計和生成測試用例，產(chǎn)生測試設(shè)計說明文檔
4. 實施測試
5. 生成測試報告

2、傳統(tǒng)軟件的測試策略

有效的軟件測試實際上分為 4 步進行，即單元測試、集成測試、確認(rèn)測試和系統(tǒng)測試。

（1）單元測試

也叫模塊測試。單元測試側(cè)重于模塊中的內(nèi)部處理邏輯和數(shù)據(jù)結(jié)構(gòu)。

單元測試的測試內(nèi)容

• 模塊接口
• 局部數(shù)據(jù)結(jié)構(gòu)
• 重要的執(zhí)行路徑
• 出錯處理
• 邊界條件

單元測試過程

由于模塊不是獨立運行的程序，各模塊之間存在調(diào)用與被調(diào)用的關(guān)系。在對每個模塊進行測試時，需要開發(fā)兩種模塊。單元測試環(huán)境如圖 5-9 所示。

（2）集成測試

集成測試就是把模塊按系統(tǒng)設(shè)計說明書的要求組合起來進行測試。
集成測試有兩種方法：一種是非增量集成，一種是增量集成。

自頂向下集成測試

自頂向下集成測試是一種構(gòu)造軟件體系結(jié)構(gòu)的增量方法。
模塊的集成順序為從主控模塊（主程序) 開始，沿著控制層次逐步向下，以深度優(yōu)先或廣度優(yōu)先的方式將從屬于 (或間接從屬于) 主控模塊的模塊集成到結(jié)構(gòu)中。

自底向上集成測試

自底向上集成測試就是從原子模塊(程序結(jié)構(gòu)的最底層構(gòu)件) 開始進行構(gòu)造和測試。由于構(gòu)件是自底向上集成的，在處理時所需要的從屬于給定層次的模塊總是存在的，因此，沒有必要使用樁模塊。

回歸測試

在集成測試策略的環(huán)境下，回歸測試是重新執(zhí)行已測試過的某些子集，以確保變更沒有傳播不期望的副作用。

回歸測試要執(zhí)行的測試子集包含以下3 種測試用例。

• 能夠測試軟件所有功能的具有代表性的測試樣本
• 額外測試，側(cè)重于可能會受變更影響的軟件功能。
• 側(cè)重于已發(fā)生變更的軟件構(gòu)件測試。

冒煙測試

冒煙測試是一種常用的集成測試方法。

1. 將已經(jīng)轉(zhuǎn)換為代碼的軟件構(gòu)件集成到構(gòu)建中。一個構(gòu)建包括所有的數(shù)據(jù)文件、庫、可復(fù)用的模塊以及實現(xiàn)一個或多個產(chǎn)品功能所需的工程化構(gòu)件。
2. 設(shè)計一系列測試以暴露影響構(gòu)建正確的完成其功能的錯誤，其目的是為了發(fā)現(xiàn)極有可能造成項目延遲的業(yè)務(wù)阻塞錯誤。
3. 每天將該構(gòu)建與其他構(gòu)建及整個軟件產(chǎn)品(以其當(dāng)前形勢) 集成起來進行冒煙測試這種集成方法可以自頂向下，也可以自底向上。

（3）確認(rèn)測試

確認(rèn)測試始于集成測試的結(jié)束，那時已測試完單個構(gòu)件，軟件已組裝成完整的軟件包，且接口錯誤已被發(fā)現(xiàn)和改正。

確認(rèn)測試準(zhǔn)則

軟件確認(rèn)是通過一系列表明與軟件需求相符合的測試而獲得的。

配置評審

確認(rèn)過程的一個重要成分是配置評審，主要是檢查軟件(源程序、目標(biāo)程序)、文檔 (包括面向開發(fā)和用戶的文檔) 和數(shù)據(jù)(程序內(nèi)部的數(shù)據(jù)或程序外部的數(shù)據(jù)) 是否齊全以及分類是否有序。確保文檔、資料的正確和完善，以便維護階段使用。

$\alpha$測試與$\beta$測試

$\alpha$測試是由有代表性的最終用戶在開發(fā)者的場所進行。軟件在自然的環(huán)境下使用，開發(fā)者站在用戶的后面觀看，并記錄錯誤和使用問題。$\alpha$測試在受控的環(huán)境下進行。
$\beta$測試在一個或多個最終用戶場所執(zhí)行。與 $\alpha$測試不同，開發(fā)者通常不在場，因此，$\beta$測試是在不被開發(fā)者控制的環(huán)境下軟件的“現(xiàn)場”應(yīng)用。最終用戶記錄測試過程中遇見的所有問題(現(xiàn)實存在的或想象的)，并定期地報告給開發(fā)者。接到 測試的問題報告之后，開發(fā)人員對軟件進行修改，然后準(zhǔn)備向最終用戶發(fā)布軟件產(chǎn)品。

$\beta$ 測試的一種變體稱為客戶驗收測試，有時是按照合同交付給客戶時進行的?？蛻魣?zhí)行一系列的特定測試，試圖在從開發(fā)者那里接收軟件之前發(fā)現(xiàn)錯誤。

（4）系統(tǒng)測試

系統(tǒng)測試是將已經(jīng)確認(rèn)的軟件、計算機硬件、外設(shè)和網(wǎng)絡(luò)等其他因素結(jié)合在一起，進行信息系統(tǒng)的各種集成測試和確認(rèn)測試，其目的是通過與系統(tǒng)的需求相比較，發(fā)現(xiàn)所開發(fā)的系統(tǒng)與用戶需求不符或矛盾的地方。

• 恢復(fù)測試
• 安全性測試
• 壓力測試
• 性能測試
• 部署測試

3、測試面向?qū)ο筌浖?/h3>

對于面向?qū)ο筌浖?，測試的基本目標(biāo)仍然是在現(xiàn)實的時間范圍內(nèi)利用可控的工作量找出盡可能多的錯誤

（1）單元測試

面向?qū)ο筌浖念悳y試是由封裝在該類中的操作和類的狀態(tài)行為驅(qū)動的。

（2）集成測試

由于面向?qū)ο筌浖]有明顯的層次控制結(jié)構(gòu)，因此面向?qū)ο蟓h(huán)境中的集成測試有兩種策略

• 基于線程的測試，對響應(yīng)系統(tǒng)的一個輸入或事件所需的一組類進行集成，每個線程單獨地集成和測試，并應(yīng)用回歸測試以確保沒有產(chǎn)生副作用。
• 基于使用的測試，通過測試很少使用服務(wù)類的那些類開始系統(tǒng)的構(gòu)建。

4、測試Web應(yīng)用

（1）質(zhì)量維度

（2）WebApp測試策略

1. 對 WebApp 的內(nèi)容模型進行評審，以發(fā)現(xiàn)錯誤。
2. 對接口模型進行評審，保證適合所有的用例。
3. 評審 WebApp 的設(shè)計模型，發(fā)現(xiàn)導(dǎo)航錯誤。
4. 測試用戶界面，發(fā)現(xiàn)表現(xiàn)機制和或) 導(dǎo)航機制中的錯誤。
5. 對功能構(gòu)件進行單元測試。
6. 對貫穿體系結(jié)構(gòu)的導(dǎo)航進行測試。
7. 在各種不同的環(huán)境配置下實現(xiàn) WebApp，并測試 WebApp 對于每一種配置的兼容性。
8. 進行安全性測試，試圖攻擊 WebApp 或其所處環(huán)境的弱點。
9. 進行性能測試。
10. 通過可監(jiān)控的最終用戶群對 WebApp 進行測試，對他們與系統(tǒng)的交互結(jié)果進行以下方面的評估，包括內(nèi)容和導(dǎo)航錯誤、可用性、兼容性以及 WebApp 的安全性、可靠性及性能等方面的評估。

5、測試方法

軟件測試方法分為靜態(tài)測試和動態(tài)測試。
靜態(tài)測試是指被測試程序不在機器上運行，而是采用人工檢測和計算機輔助靜態(tài)分析的手段對程序進行檢測。
動態(tài)測試是指通過運行程序發(fā)現(xiàn)錯誤。在對軟件產(chǎn)品進行動態(tài)測試時可以采用黑盒測試法和白盒測試法。

（1）黑盒測試

黑盒測試也稱為功能測試，在完全不考慮軟件的內(nèi)部結(jié)構(gòu)和特性的情況下，測試軟件的外部特性。

常用的黑盒測試技術(shù)

1. 等價類劃分
2. 邊界值分析
3. 錯誤推測
4. 因果圖

（2）白盒測試

白盒測試也稱為結(jié)構(gòu)測試，根據(jù)程序的內(nèi)部結(jié)構(gòu)和邏輯來設(shè)計測試用例，對程序的路徑和過程進行測試，檢查是否滿足設(shè)計的需要。

白盒測試的原則

1. 程序模塊中的所有獨立路徑至少執(zhí)行一次。
2. 在所有的邏輯判斷中，取“真”和取“假”的兩種情況至少都能執(zhí)行一次。
3. 每個循環(huán)都應(yīng)在邊界條件和一般條件下各執(zhí)行一次。
4. 測試程序內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性等。

白盒測試常用的技術(shù)

1. 邏輯覆蓋
   邏輯覆蓋考察用測試數(shù)據(jù)運行被測程序時對程序邏輯的覆蓋程度，主要的邏輯覆蓋標(biāo)準(zhǔn)有語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋6種。
2. 循環(huán)覆蓋
   執(zhí)行足夠的測試用例，使得循環(huán)中的每個條件都得到驗證
3. 基本路徑測試
   基本路徑測試法是在程序控制流圖的基礎(chǔ)上通過分析控制流圖的環(huán)路復(fù)雜性，導(dǎo)出基本可執(zhí)行路徑集合，從而設(shè)計測試用例。

6、調(diào)試

調(diào)試發(fā)生在測試之后，其任務(wù)是根據(jù)測試時所發(fā)現(xiàn)的錯誤找出原因和具體的位置，進行改正。調(diào)試工作主要由程序開發(fā)人員進行，誰開發(fā)的程序就由誰來進行調(diào)試。

（1）調(diào)試過程

調(diào)試過程通常得到以下兩種結(jié)果： 發(fā)現(xiàn)問題的原因并將其改正、未能找到問題的原因

（2）調(diào)試方法

• 試探法
• 回溯法
• 對分查找法
• 歸納法
• 演繹法

六、軟件運行和維護

1、系統(tǒng)轉(zhuǎn)換

在進行新舊系統(tǒng)轉(zhuǎn)換以前，首先要進行新系統(tǒng)的試運行。新系統(tǒng)試運行成功之后，就可以在新系統(tǒng)和舊系統(tǒng)之間互相轉(zhuǎn)換。

系統(tǒng)試運行階段的主要工作：

1. 對系統(tǒng)進行初始化、輸入各種原始數(shù)據(jù)記錄。
2. 記錄系統(tǒng)運行的數(shù)據(jù)和狀況。
3. 核對新系統(tǒng)輸出和舊系統(tǒng) (人工或計算機系統(tǒng)) 輸出的結(jié)果
4. 對實際系統(tǒng)的輸入方式進行考察(是否方便、效率如何、安全可靠性、誤操作保護等)。
5. 對系統(tǒng)實際運行、響應(yīng)速度進行實際測試。

新舊系統(tǒng)轉(zhuǎn)換方式：

1. 直接轉(zhuǎn)換
2. 并行轉(zhuǎn)換
3. 分段轉(zhuǎn)換（又稱逐步轉(zhuǎn)換、向?qū)мD(zhuǎn)換、試點過渡法）

2、系統(tǒng)維護概述

（1）系統(tǒng)可維護性概念

系統(tǒng)的可維護性：維護人員理解、改正、改動和改進這個軟件的難易程度。
提高可維護性是開發(fā)軟件系統(tǒng)所有步驟的關(guān)鍵目的。

系統(tǒng)可維護性的評價指標(biāo)

• 可理解性
• 可測試性
• 可修改性

維護與軟件文檔

文檔是軟件可維護性的決定因素。
軟件系統(tǒng)的文檔可以分為用戶文檔和系統(tǒng)文檔兩類。用戶文檔主要描述系統(tǒng)功能和使用方法，并不關(guān)心這些功能是怎樣實現(xiàn)的；系統(tǒng)文檔描述系統(tǒng)設(shè)計、實現(xiàn)和測試等各方面的內(nèi)容。

軟件文檔的修改

維護應(yīng)該針對整個軟件配置，不應(yīng)該只修改源程序代碼。

（2）系統(tǒng)維護的內(nèi)容及類型

系統(tǒng)維護主要包括硬件維護、軟件維護和數(shù)據(jù)維護

硬件維護

• 一種是定期的設(shè)備保養(yǎng)性維護
• 另一種是突發(fā)性的故障維護

軟件維護
軟件維護主要是指根據(jù)需求變化或硬件環(huán)境的變化對應(yīng)用程序進行部分或全部修改。內(nèi)容包括：

• 正確性維護
• 適應(yīng)性維護
• 完善性維護
• 預(yù)防性維護

數(shù)據(jù)維護
數(shù)據(jù)維護工作主要是由數(shù)據(jù)庫管理員來負責(zé)，主要負責(zé)數(shù)據(jù)庫的安全性和完整性以及進行并發(fā)性控制。

（3）系統(tǒng)維護的管理和步驟

1. 提出維護或修改要求
2. 領(lǐng)導(dǎo)審查并做出答復(fù)，如同意修改則列入維護計劃。
3. 領(lǐng)導(dǎo)分配任務(wù)，維護人員執(zhí)行修改
4. 驗收維護成果并登記修改信息。

3、系統(tǒng)評價

（1）系統(tǒng)評價概述

信息系統(tǒng)的評價分為廣義和狹義兩種。
廣義的信息系統(tǒng)評價是指從系統(tǒng)開發(fā)的一開始到結(jié)束的每一階段都需要進行評價。
狹義的信息系統(tǒng)評價則是指在系統(tǒng)建成并投入運行之后所進行的全面、綜合的評價。

按評價的時間與信息系統(tǒng)所處的階段的關(guān)系又可從總體上把廣義的信息系統(tǒng)評價分成：立
項評價、中期評價（里程碑式評價）和結(jié)項評價。

（2）系統(tǒng)評價指標(biāo)

• 從信息系統(tǒng)的組成部分出發(fā)，信息系統(tǒng)是一個由人機共同組成的系統(tǒng)，所以可以按照運行效果和用戶需求 (人)、系統(tǒng)質(zhì)量和技術(shù)條件 (機) 這兩條線索構(gòu)造指標(biāo)。
• 從信息系統(tǒng)的評價對象出發(fā)，對于開發(fā)方來說，他們所關(guān)心的是系統(tǒng)質(zhì)量和技術(shù)水平:對于用戶方而言，關(guān)心的是用戶需求和運行質(zhì)量:系統(tǒng)外部環(huán)境則主要通過社會效益指標(biāo)來反映。
• 從經(jīng)濟學(xué)角度出發(fā)，分別按系統(tǒng)成本、系統(tǒng)效益和財務(wù)指標(biāo) 3 條線索建立指標(biāo)。

七、軟件項目管理

將項目管理思想引入軟件工程領(lǐng)域，就形成了軟件項目管理。
軟件項目管理是指軟件生存周期中軟件管理者所進行的一系列活動，其目的是在一定的時間和預(yù)設(shè)范圍內(nèi)有效地利用人力、資源、技術(shù)和工具，使軟件系統(tǒng)或軟件產(chǎn)品按原定計劃和質(zhì)量要求如期完成。

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

人員(Person)、產(chǎn)品(Product)、過程(Procedure)和項目 (Project)。

（1）人員 Person

人員是軟件工程項目的基本要素和關(guān)鍵因素，可以分為以下 5 類。

• 項目管理人員
• 高級管理人員
• 開發(fā)人員
• 客戶
• 最終客戶

（2）產(chǎn)品 Product

在進行項目計劃之前，應(yīng)該首先進行項目定義，也就是定義項目范圍，其中包括建立產(chǎn)品的目的和范圍、可選的解決方案、技術(shù)或管理的約束等。

軟件開發(fā)者和客戶必須一起定義產(chǎn)品的目的和范圍。
軟件范圍是通過回答下列問題來定義的：

• 項目環(huán)境
  要開發(fā)的軟件如何適應(yīng)于大型的系統(tǒng)、產(chǎn)品或業(yè)務(wù)環(huán)境，該環(huán)境下要施加什么約束?
• 信息目標(biāo)
  軟件要產(chǎn)生哪些客戶可見的數(shù)據(jù)對象作為輸出?需要什么數(shù)據(jù)對象作為輸入?
• 功能和性能
  軟件要執(zhí)行什么功能才能將輸入數(shù)據(jù)變換成輸出數(shù)據(jù)? 軟件需要滿足什么特殊的性能要求?

（3）過程 Procedure

軟件過程提供了一個項目團隊要選擇一個適合于待開發(fā)軟件的過程模型

（4）項目 Project

進行有計劃和可控制的軟件項目是管理復(fù)雜性的一種方式。

• 明確目標(biāo)及過程
• 保持動力
• 跟蹤進展
• 做出明智的決策
• 進行事后分析

2、軟件項目估算

常用的估算方法有3種：

1. 基于已經(jīng)完成的類似項目進行估算
2. 基于分解技術(shù)進行估算
3. 基于經(jīng)驗估算模型的估算 （IBM估算模型、CoCoMo模型、Putnam模型）

（1）成本估算方法

• 自頂向下估算方法
• 自底向上估算方法
• 差別估算方法
• 其他估算方法（專家估算法、類推估算法、算式估算法）

（2）CoCoMo估算模型

COCOMO 模型是一種精確的、易于使用的成本估算模型。COCOMO 模型按其詳細程度分
為基本 COCOMO 模型、中級 COCOMO 模型和詳細 COCOMO 模型。

基本 COCOMO 模型

$E=a(L{)}^b$
$D=c(E{)}^d$
E表示工作量，D表示開發(fā)時間，L是項目的源代碼行數(shù)估值。a、b、c、d是常數(shù)。

中級 COCOMO 模型

$E=a(L{)}^{b}EAF$
E表示工作量，EAF是調(diào)節(jié)因子，L是項目的源代碼行數(shù)估值，單位是千行。a、b是常數(shù)。

詳細 COCOMO 模型

它將軟件系統(tǒng)模型分為系統(tǒng)、子系統(tǒng)和模塊 3 個層次，除包括中級模型所考慮的因素外，還考慮了在需求分析、軟件設(shè)計等每一步的成本驅(qū)動屬性的影響。

（3）COCOMOⅡ模型

層次結(jié)構(gòu)的估算模型，被分為 3 個階段性模型

1. 應(yīng)用組裝模型
2. 早期設(shè)計階段模型
3. 體系結(jié)構(gòu)階段模型

COCOMOⅡ模型也需要使用規(guī)模估算信息，體系結(jié)構(gòu)階段，在模型層次結(jié)構(gòu)中有3種不同規(guī)模估算選擇，即: 對象點、功能點和代碼行。應(yīng)用組裝模型使用的是對象點；早期設(shè)計階段模型使用的是功能點，功能點可以轉(zhuǎn)換為代碼行。體系結(jié)構(gòu)模型把工作量表示為代碼行數(shù)。

（4）Putnam估算模型

$L=C_k{E}^{1/3}{t}_d^{4/3}$
L 表示源程序代碼行數(shù) (LOC);
$t_d$表示開發(fā)持續(xù)時間(年);
E 是包括軟件開發(fā)和維護在整個生存期所花費的工作量 (人年);
$C_k$:表示技術(shù)狀態(tài)常數(shù)，其值依賴于開發(fā)環(huán)境

3、進度管理

目的是確保軟件項目在規(guī)定的時間內(nèi)按期完成。

（1）進度管理的基本原則

指導(dǎo)軟件進度安排的基本原則：

• 劃分：項目必須被劃分成若干可以管理的活動和任務(wù)
• 相互依賴性：劃分后的各個活動或任務(wù)之間的相互依賴關(guān)系必須是明確的
• 時間分配：必須為每個被調(diào)度的任務(wù)分配一定數(shù)量的工作單位
• 工作量確認(rèn)：每個項目都有預(yù)定數(shù)量的人員參與
• 確認(rèn)責(zé)任：安排了進度計劃的每個任務(wù)都應(yīng)該指定特定的團隊成員來負責(zé)。
• 明確輸出結(jié)果：安排了進度計劃的每個任務(wù)都應(yīng)該有一個明確的輸出結(jié)果。
• 確定里程碑：每個任務(wù)或任務(wù)組都應(yīng)該與一個項目里程碑相關(guān)聯(lián)。

（2）進度安排

為監(jiān)控軟件項目的進度計劃和工作的實際進展情況，表示各項任務(wù)之間進度的相互依賴關(guān)系，需要采用圖示的方法。在圖中明確標(biāo)明如下內(nèi)容。

• 各個任務(wù)的計劃開始時間和完成時間
• 各個任務(wù)的完成標(biāo)志
• 各個任務(wù)與參與工作的人數(shù)，各個任務(wù)與工作量之間的銜接情況。
• 完成各個任務(wù)所需的物理資源和數(shù)據(jù)資源

進度安排的常用圖形描述方法有 Gantt 圖(甘特圖)和項目計劃評審技術(shù)(Program Evaluation &Review Technique，PERT) 圖。

Gantt 圖

Gantt圖是一種簡單的水平條形圖，它以日歷為基準(zhǔn)描述項目任務(wù)

PERT 圖

PERT 圖是一個有向圖，圖中的箭頭表示任務(wù)，它可以標(biāo)上完成該任務(wù)所需的時間

4、軟件項目的組織

在軟件項目組織中，其組織原則：

• 盡早落實責(zé)任
• 減少交流接口
• 責(zé)權(quán)均衡

（1）組織結(jié)構(gòu)的模式

根據(jù)項目的分解和過程的分解，軟件項目可以有以下多種組織形式。

• 1 、按項目劃分的模式
  按項目將開發(fā)人員組織成項目組，項目組的成員共同完成該項目的所有開發(fā)任務(wù)，包括項目的定義、需求分析、設(shè)計、編碼、測試、評審以及所有的文檔編制，甚至包括該項目的維護。

• 2、按職能劃分的模式
  按軟件過程中所反映的各種職能將項目的參與者組織成相應(yīng)的專業(yè)組，如開發(fā)組 (可進步分為需求分析組、設(shè)計組、編碼組)、測試組、質(zhì)量保證組、維護組等。

• 3、矩陣模式
  這種模式是上述兩種模式的組合，它既按職能組織相應(yīng)的專業(yè)組，又按項目組織項目組。每個軟件人員既屬于某個專業(yè)組，又屬于某個項目組。每個軟件項目指定一個項目經(jīng)理，項目中的成員根據(jù)其所屬的專業(yè)組的職能承擔(dān)項目的相應(yīng)任務(wù)。

（2）程序設(shè)計小組的組織方式

主要是指從事軟件開發(fā)活動的小組，有以下 3 種不同的組織形式

• 主程序員制小組
  主程序員制小組由一名主程序員、若干名程序員、一名后援工程師和一名資料員組成。
• 民主制小組
• 層次式小組

5、軟件配置管理

軟件配置管理 (Software Configure Management，SCM)用于整個軟件工程過程。其主要目標(biāo)是標(biāo)識變更；控制變更；確保變更正確地實現(xiàn)；報告有關(guān)變更。

（1）基線

基線是軟件生存周期中各開發(fā)階段的一個特定點，它的作用是使各開發(fā)階段的工作劃分更加明確，使本來連續(xù)的工作在這些點上斷開，以便于檢查與肯定階段成果。

（2）軟件配置項

軟件配置項(Software Configure Item，SCI)是軟件工程中產(chǎn)生的信息項，它是配置管理的基本單位，對于已經(jīng)成為基線的 SCI，雖然可以修改，但必須按照一個特殊的、正式的過程進行評估，確認(rèn)每一處修改。以下的 SCI是 SCM的對象，并可形成基線。

• 系統(tǒng)規(guī)格說明書
• 軟件項目實施計劃
• 軟件需求規(guī)格說明書
• 設(shè)計規(guī)格說明書(數(shù)據(jù)設(shè)計、體系結(jié)構(gòu)設(shè)計、模塊設(shè)計、接口設(shè)計、對象描述(使用面向?qū)ο蠹夹g(shù)時))
• 源代碼清單
• 測試計劃和過程、測試用例和測試結(jié)果記錄
• 操作和安裝手冊
• 可執(zhí)行程序 (可執(zhí)行程序模塊、連接模塊)
• 數(shù)據(jù)庫描述(模式和文件結(jié)果、初始內(nèi)容)
• 用戶手冊
• 維護文檔(軟件問題報告、維護請求、工程變更次序)
• 軟件工程標(biāo)準(zhǔn)
• 項目開發(fā)小結(jié)

（3）版本控制

在圖中各個結(jié)點是一個完全的軟件版本。軟件的每一個版本都是 SCI(源代碼、文檔、數(shù)據(jù))的一個匯集，而且各個版本都可能由不同的變種組成。

（4）變更控制

軟件工程過程中某一階段的變更均要引起軟件配置的變更，這種變更必須嚴(yán)格地加以控制和管理，保持修改信息，并把精確、清晰的信息傳遞到軟件工程過程的下一步驟。

6、風(fēng)險管理

風(fēng)險是指損失或傷害的可能性。一般認(rèn)為軟件風(fēng)險包含兩個特性：不確定性和損失。

（1）風(fēng)險識別

風(fēng)險識別試圖系統(tǒng)化地指出對項目計劃(估算、進度、資源分配等) 的威脅。
識別風(fēng)險的一種方法是建立風(fēng)險條目檢查表。該檢查表可用于風(fēng)險識別，并且主要用來識別下列幾種類型中的一些已知風(fēng)險和可預(yù)測風(fēng)險。

• 產(chǎn)品規(guī)模
• 商業(yè)影響
• 客戶特性
• 過程定義
• 開發(fā)環(huán)境
• 開發(fā)技術(shù)
• 人員才千及經(jīng)驗

（2）風(fēng)險預(yù)測

風(fēng)險預(yù)測又稱風(fēng)險估計，它試圖從兩個方面評估一個風(fēng)險: 風(fēng)險發(fā)生的可能性或概率；如果風(fēng)險發(fā)生了所產(chǎn)生的后果。

風(fēng)險顯露度（Risk Exposure, RE）, $RE=P?C$

（3）風(fēng)險評估

$(r_i{l}_i{x}_i)$
其中$r_i$表示風(fēng)險，$l_i$表示風(fēng)險發(fā)生的概率，$x_i$表示風(fēng)險產(chǎn)生的影響。
一種對風(fēng)險評估很有用的技術(shù)就是定義風(fēng)險參照水準(zhǔn)。成本、進度和性能。

（4）風(fēng)險控制

風(fēng)險控制的目的是輔助項目組建立處理風(fēng)險的策略。一個有效的策略必須考慮以下 3 個問題：

• 風(fēng)險避免
• 風(fēng)險監(jiān)控
• RMMM計劃（風(fēng)險管理計劃）

八、軟件質(zhì)量

軟件質(zhì)量：指反映軟件系統(tǒng)或軟件產(chǎn)品，滿足規(guī)定或隱含需求的能力的特征和特性全體。
軟件質(zhì)量管理：對軟件開發(fā)過程進行獨立的檢查活動，由質(zhì)量保證、質(zhì)量規(guī)劃和質(zhì)量控制3 個主要活動構(gòu)成。

1、軟件質(zhì)量的特性

利用軟件質(zhì)量模型來描述軟件質(zhì)量特性，例如 ISO/IEC 9126 軟件質(zhì)量模型和 Mc Call 軟件質(zhì)量模型。

ISO/IEC 9126 軟件質(zhì)量模型由 3 個層次組成：第一層是質(zhì)量特性，第二層是質(zhì)量子特性：第三層是度量指標(biāo)。

Mc Call 軟件質(zhì)量模型從軟件產(chǎn)品的運行、修正和轉(zhuǎn)移 3 個方面確定了 11 個質(zhì)量特性。第一層是質(zhì)量特性，第二層是評價準(zhǔn)則，第三層是度量指標(biāo)

2、軟件質(zhì)量的保證

軟件質(zhì)量保證是指為保證軟件系統(tǒng)或軟件產(chǎn)品充分滿足用戶要求的質(zhì)量而進行的有計劃有組織的活動，其目的是生產(chǎn)高質(zhì)量的軟件。在軟件質(zhì)量方面強調(diào)以下 3 個要點：

1. 軟件必須滿足用戶規(guī)定的需求，與用戶需求不一致的軟件無質(zhì)量可言。
2. 軟件應(yīng)遵循規(guī)定標(biāo)準(zhǔn)所定義的一系列開發(fā)準(zhǔn)則，不遵循這些準(zhǔn)則的軟件，其質(zhì)量難以得到保證。
3. 軟件還應(yīng)滿足某些隱含的需求，例如希望有好的可理解性、可維護性等，如果軟件只滿足它的顯式需求而不滿足其隱含需求，那么該軟件的質(zhì)量是令人質(zhì)疑的

軟件質(zhì)量保證包括了與以下 7 個主要活動相關(guān)的各種任務(wù)：

• 應(yīng)用技術(shù)方法
• 進行正式的技術(shù)評審
• 測試軟件
• 標(biāo)準(zhǔn)的實施
• 控制變更
• 度量
• 記錄保存和報告

3、軟件評審

通常，把“質(zhì)量”理解為“用戶滿意程度”。為了使得用戶滿意，有以下兩個必要條件。
(1) 設(shè)計的規(guī)格說明書符合用戶的要求，這稱為設(shè)計質(zhì)量。
(2) 程序按照設(shè)計規(guī)格說明所規(guī)定的情況正確執(zhí)行，這稱為程序質(zhì)量。

（1）設(shè)計質(zhì)量的評審內(nèi)容

設(shè)計質(zhì)量評審的對象是在需求分析階段產(chǎn)生的軟件需求規(guī)格說明、數(shù)據(jù)需求規(guī)格說明，以及在軟件概要設(shè)計階段產(chǎn)生的軟件概要設(shè)計說明書等。通常從以下幾個方面進行評審。

• 評價軟件的規(guī)格說明是否合乎用戶的要求
• 評審可靠性
• 評審保密措施實現(xiàn)情況
• 評審操作特性實施情況
• 評審性能實現(xiàn)情況，即是否達到所規(guī)定性能的目標(biāo)值。
• 評審軟件是否具有可修改性、可擴充性、可互換性和可移植性。
• 評審軟件是否具有可測試性。
• 評審軟件是否具有復(fù)用性。

（2）程序質(zhì)量的評審內(nèi)容

程序質(zhì)量評審?fù)ǔＪ菑拈_發(fā)者的角度進行評審，與開發(fā)技術(shù)直接相關(guān)。它是著眼于軟件本身的結(jié)構(gòu)、與運行環(huán)境的接口以及變更帶來的影響而進行的評審活動。

軟件的結(jié)構(gòu)如下：

• 功能結(jié)構(gòu)
• 功能的通用性
• 模塊的層次
• 模塊結(jié)構(gòu)
• 處理過程的結(jié)構(gòu)

（3）與運行環(huán)境的接口

運行環(huán)境包括硬件、其他軟件和用戶，主要檢查項目：

• 與硬件的接口
• 與用戶的接口

4、軟件容錯技術(shù)

提高軟件質(zhì)量和可靠性的技術(shù)大致可分為兩類，一類是避開錯誤；另一類是容錯技術(shù)。

（1）容錯軟件的定義

1. 規(guī)定功能的軟件，在一定程度上對自身錯誤的作用(軟件錯誤) 具有屏蔽能力，則稱該軟件為具有容錯功能的軟件，即容錯軟件。
2. 規(guī)定功能的軟件，在一定程度上能從錯誤狀態(tài)自動恢復(fù)到正常狀態(tài)，則稱該軟件為容錯軟件。
3. 規(guī)定功能的軟件，在因錯誤發(fā)生錯誤時仍然能在一定程度上完成預(yù)期的功能，則稱該軟件為容錯軟件。
4. 規(guī)定功能的軟件，在一定程度上具有容錯能力，則稱該軟件為容錯軟件。

（2）容錯的方法

實現(xiàn)容錯的主要手段是冗余。包括結(jié)構(gòu)冗余、信息冗余、時間冗余、冗余附加技術(shù)。

九、軟件度量

軟件度量用于對產(chǎn)品及開發(fā)產(chǎn)品的過程進行度量。

1、軟件度量分類

軟件度量有兩種分類方法：
第一種分類是將軟件度量分為面向規(guī)模的度量、面向功能的度量和面向人的度量；
第二種分類是將軟件度量分為生產(chǎn)率度量、質(zhì)量度量和技術(shù)度量。

（1）面向規(guī)模的度量

面向規(guī)模的度量是通過對質(zhì)量和生產(chǎn)率的測量進行規(guī)范化得到的，而這些量都是根據(jù)開發(fā)過的軟件的規(guī)模得到的。

（2）面向功能的度量

應(yīng)用最廣泛的面向功能的度量是功能點(Function Point，F(xiàn)P)。功能點是根據(jù)軟件信息域的特性及復(fù)雜性來計算的。
信息域的值用下列方式定義。

• 外部輸入數(shù)（EI）
• 外部輸出數(shù)（EO）
• 外部查詢數(shù) （EQ）
• 內(nèi)部邏輯文件數(shù)（ILF）
• 外部接口文件數(shù)（EIF）

利用下面的關(guān)系式計算功能點:
$Fp=總計?[0.65+0.01?\sum (F_i)]$ 其中，“總計”是所有 Fp項的總數(shù)。$F_i(i=114)$是值調(diào)整因子

2、軟件復(fù)雜性度量

軟件復(fù)雜性是指理解和處理軟件的難易程度。軟件復(fù)雜性度量的參數(shù)主要有：

• 規(guī)模。規(guī)模即總共的指令數(shù)，或源程序行數(shù)。
• 難度。通常由程序中出現(xiàn)的操作數(shù)的數(shù)目所決定的量來表示。
• 結(jié)構(gòu)。通常用與程序結(jié)構(gòu)有關(guān)的度量來表示。
• 智能度。智能度即算法的難易程度。
  軟件復(fù)雜性包括程序復(fù)雜性和文檔復(fù)雜性，軟件復(fù)雜性主要體現(xiàn)在程序的復(fù)雜性中。

（1）度量原則

程序復(fù)雜性度量是軟件度量的重要組成部分。

• 程序復(fù)雜性與程序大小的關(guān)系不是線性的。
• 控制結(jié)構(gòu)復(fù)雜的程序較復(fù)雜。
• 數(shù)據(jù)結(jié)構(gòu)復(fù)雜的程序較復(fù)雜
• 轉(zhuǎn)向語句使用不當(dāng)?shù)某绦蜉^復(fù)雜。
• 循環(huán)結(jié)構(gòu)比選擇結(jié)構(gòu)復(fù)雜，選擇結(jié)構(gòu)又比順序結(jié)構(gòu)復(fù)雜
• 語句、數(shù)據(jù)、子程序和模塊在程序中的次序?qū)?fù)雜性有影響
• 全局變量、非局部變量較多時程序較復(fù)雜。
• 函數(shù)的隱式副作用相對于顯式參數(shù)傳遞而言更加難以理解。
• 具有不同作用的變量共用一個名字時較難理解。
• 模塊間、過程間聯(lián)系密切的程序比較復(fù)雜
• 嵌套程度越深，程序越復(fù)雜。

（2）McCabe度量法

又稱環(huán)路度量

$V(G)=m?n+2$
其中V(G)是G中的環(huán)路書，m是G中的有向弧數(shù)，n是G中的節(jié)點數(shù)。

十、軟件工具與軟件開發(fā)環(huán)境

計算機輔助軟件工程（Computer Aided Software Engineerin， CASE）是指使用計算機及相關(guān)的軟件工具輔助軟件開發(fā)、維護、管理等過程中各項活動的實施，以確保這些活動能高效率、高質(zhì)量地進行。

1、軟件工具

用來輔助軟件開發(fā)、運行、維護、管理和支持等過程中的活動的軟件稱為軟件工具。

（1）軟件開發(fā)工具

對應(yīng)于軟件開發(fā)過程的各種活動，軟件開發(fā)工具通常有需求分析工具、設(shè)計工具、編碼與排錯工具、測試工具等。

（2）軟件維護工具

輔助 軟件維護過程中活動 的軟件稱為軟件維護工具。
主要有：

• 版本控制工具
• 文檔分析工具
• 開發(fā)信息庫工具
• 逆向工程工具
• 再工程工具

（3）軟件管理工具和軟件支持工具

軟件管理和軟件支持工具用來輔助管理人員和軟件支持人員的管理活動和支持活動，以確保軟件高質(zhì)量地完成。
主要有：

• 項目管理工具
• 配置管理工具
• 軟件評價工具

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

軟件開發(fā)環(huán)境：指支持軟件產(chǎn)品開發(fā)的軟件系統(tǒng)，它由軟件工具集和環(huán)境集成機制構(gòu)成。
工具集用于支持軟件開發(fā)的相關(guān)過程、活動和任務(wù)；環(huán)境集成機制為工具集成和軟件開發(fā)、維護和管理提供統(tǒng)一的支持。文章來源地址http://www.zghlxwxcb.cn/news/detail-627228.html

環(huán)境集成機制分類

軟件開發(fā)環(huán)境的特征

• 環(huán)境的服務(wù)是集成的
• 環(huán)境應(yīng)支持小組工作方式，并為其提供配置管理
• 環(huán)境的服務(wù)可用于支持各種軟件開發(fā)活動

到了這里，關(guān)于軟件設(shè)計師（五）軟件工程基礎(chǔ)知識的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！