軟體質量管理 - 快速指南

---

---

軟體質量管理 - 簡介

高質量軟體是指基本上沒有錯誤或缺陷，按時並在指定預算內交付，滿足需求和/或期望，並且可維護的軟體。在軟體工程的背景下，軟體質量反映了**功能質量**和**結構質量**。

• **軟體功能質量** - 它反映了軟體在多大程度上滿足給定的設計，基於功能需求或規範。

• **軟體結構質量** - 它處理支援功能需求交付的非功能需求，例如健壯性或可維護性，以及軟體開發的正確程度。

• **軟體質量保證** - 軟體質量保證 (SQA) 是一套確保軟體工程過程中質量的活動，最終產生高質量的軟體產品。這些活動建立和評估生產產品的過程。它涉及以過程為中心的行動。

• **軟體質量控制** - 軟體質量控制 (SQC) 是一套確保軟體產品質量的活動。這些活動側重於確定實際生產產品的缺陷。它涉及以產品為中心的行動。

軟體質量挑戰

在軟體行業，開發人員永遠不會像其他工業產品製造商通常那樣宣告軟體沒有缺陷。這種差異是由於以下原因造成的。

產品複雜性

它是產品允許的操作模式的數量。通常，工業產品僅允許少於幾千種操作模式，以及其機器設定的不同組合。但是，軟體包允許數百萬種操作可能性。因此，正確保證所有這些操作可能性對軟體行業來說是一個重大挑戰。

產品可見性

由於工業產品是可見的，因此大多數缺陷可以在製造過程中檢測到。此外，工業產品中零件的缺失也很容易在產品中檢測到。但是，儲存在軟盤或 CD 上的軟體產品的缺陷是不可見的。

產品開發和生產過程

在工業產品中，可以在以下階段檢測到缺陷 -

• **產品開發** - 在此階段，設計師和質量保證 (QA) 員工檢查和測試產品原型以檢測其缺陷。

• **產品生產計劃** - 在此階段，設計和準備生產過程和工具。此階段還提供了檢查產品以檢測在開發階段未被注意到的缺陷的機會。

• **製造** - 在此階段，應用 QA 程式來檢測產品本身的故障。在製造初期檢測到的產品缺陷通常可以透過更改產品的設計或材料或生產工具來糾正，從而消除將來製造的產品中的此類缺陷。

但是，對於軟體而言，唯一可以檢測到缺陷的階段是開發階段。對於軟體，不需要產品生產計劃和製造階段，因為軟體副本的製造和軟體手冊的列印是自動進行的。

下表顯示了影響軟體產品與其他工業產品缺陷檢測的因素。

軟體的這些特性，例如複雜性和不可見性，使得軟體質量保證方法的開發及其成功實施成為一項極具挑戰性的專業工作。

軟體質量因素

影響軟體的各種因素稱為軟體因素。它們可以大致分為兩類。第一類因素是可以直接測量的因素，例如邏輯錯誤的數量；第二類因素將那些只能間接測量的因素歸為一類。例如，可維護性，但每個因素都必須進行測量以檢查內容和質量控制。

多年來，人們提出了許多軟體質量因素及其分類模型。McCall 提出的軟體質量因素經典模型包含 11 個因素 (McCall 等人，1977)。同樣，Deutsch 和 Willis (1988) 以及 Evans 和 Marciniak (1987) 提出了包含 12 到 15 個因素的模型。

所有這些模型與 McCall 模型沒有太大差異。McCall 因素模型提供了一種實用、最新的軟體需求分類方法 (Pressman，2000)。

McCall 因素模型

此模型將所有軟體需求分類為 11 個軟體質量因素。這 11 個因素分為三類 - 產品操作、產品修訂和產品轉換因素。

• **產品操作因素** - 正確性、可靠性、效率、完整性、可用性。

• **產品修訂因素** - 可維護性、靈活性、可測試性。

• **產品轉換因素** - 可移植性、可重用性、互操作性。

產品操作軟體質量因素

根據 McCall 模型，產品操作類別包括五個軟體質量因素，這些因素處理直接影響軟體日常操作的需求。它們如下 -

正確性

這些需求處理軟體系統的輸出的正確性。它們包括 -

• 輸出任務

• 所需的輸出精度，可能會受到不準確資料或不準確計算的負面影響。

• 輸出資訊的完整性，可能會受到不完整資料的影響。

• 資訊的新鮮度，定義為事件與軟體系統響應之間的時間。

• 資訊的可用性。

• 軟體系統編碼和記錄的標準。

可靠性

可靠性需求處理服務故障。它們確定軟體系統的最大允許故障率，並且可以指整個系統或其一個或多個單獨的功能。

效率

它處理執行軟體系統不同功能所需的硬體資源。它包括處理能力（以 MHz 為單位）、儲存容量（以 MB 或 GB 為單位）和資料通訊能力（以 MBPS 或 GBPS 為單位）。

它還處理系統行動式單元（例如，位於行動式計算機中的資訊系統單元或放置在室外的氣象單元）的充電之間的時間。

完整性

此因素處理軟體系統安全性，即防止未經授權的人員訪問，以及區分要授予讀寫許可權的人員組。

可用性

可用性需求處理培訓新員工和操作軟體系統所需的員工資源。

產品修訂質量因素

根據 McCall 模型，產品修訂類別包括三個軟體質量因素。這些因素如下 -

可維護性

此因素考慮使用者和維護人員識別軟體故障原因、糾正故障以及驗證更正成功所需的努力。

靈活性

此因素處理支援軟體的自適應維護活動所需的功能和努力。這些包括使當前軟體適應其他情況和客戶，而無需更改軟體。此因素的需求還支援完善性維護活動，例如更改和新增軟體以改進其服務並使其適應公司技術或商業環境的變化。

可測試性

可測試性需求處理軟體系統的測試及其操作。它包括預定義的中間結果、日誌檔案，以及軟體系統在啟動之前執行的自動診斷，以找出系統的所有元件是否正常工作並獲取有關檢測到的故障的報告。這些需求的另一種型別涉及維護技術人員應用的自動診斷檢查，以檢測軟體故障的原因。

產品轉換軟體質量因素

根據 McCall 模型，產品轉換類別包括三個軟體質量因素，這些因素處理軟體對其他環境的適應及其與其他軟體系統的互動。這些因素如下 -

可移植性

可移植性需求傾向於使軟體系統適應其他環境，這些環境包括不同的硬體、不同的作業系統等等。軟體應該能夠在不同的情況下繼續使用相同的基本軟體。

可重用性

此因素處理最初為一個專案設計的軟體模組在當前正在開發的新軟體專案中的使用。它們還可以使未來的專案能夠利用當前開發的軟體的給定模組或一組模組。軟體的重用預計可以節省開發資源、縮短開發週期並提供更高質量的模組。

互操作性

互操作性需求側重於建立與其他軟體系統或其他裝置韌體的介面。例如，生產機械和測試裝置的韌體與生產控制軟體介面。

軟體質量保證元件

**軟體質量保證** (SQA) 是一套用於確保軟體工程過程中質量的活動。它確保開發的軟體滿足並符合定義的或標準化的質量規範。SQA 是軟體開發生命週期 (SDLC) 中一個持續的過程，它定期檢查開發的軟體以確保其滿足所需的質量標準。

軟體質量保證 (SQA) 實踐在大多數型別的軟體開發中都有應用，無論使用何種底層軟體開發模型。SQA 整合並實施軟體測試方法來測試軟體。與其在軟體完成後再檢查質量，SQA 流程在開發的每個階段都測試質量，直到軟體完成。使用 SQA，只有在當前/前一階段符合所需的質量標準後，軟體開發過程才會進入下一階段。SQA 通常基於一個或多個行業標準，這些標準有助於構建軟體質量指南和實施策略。

它包括以下活動 -

• 流程定義和實施
• 審計
• 培訓

流程可能包括 -

• 軟體開發方法
• 專案管理
• 配置管理
• 需求開發/管理
• 估算
• 軟體設計
• 測試等。

一旦流程被定義和實施，質量保證就承擔以下責任 -

• 識別流程中的弱點
• 糾正這些弱點以持續改進流程

SQA 系統的組成部分

SQA 系統總是結合廣泛的 SQA 元件。這些元件可以分為以下六類 -

專案前元件

這確保了專案承諾在考慮所需資源、時間表和預算的情況下得到明確定義；並且開發和質量計劃已正確確定。

專案生命週期活動評估元件

專案生命週期由兩個階段組成：開發生命週期階段和執行維護階段。

開發生命週期階段元件檢測設計和程式設計錯誤。其元件分為以下子類：評審、專家意見和軟體測試。

在執行維護階段使用的 SQA 元件包括專門的維護元件以及開發生命週期元件，這些元件主要用於改進維護任務的功能。

基礎設施錯誤預防和改進元件

這些元件的主要目標是在整個組織中應用，目的是消除或至少降低錯誤率，基於組織積累的 SQA 經驗。

軟體質量管理元件

此類元件處理多個目標，例如開發和維護活動的控制，以及引入早期管理支援行動，這些行動主要預防或最大限度地減少進度和預算失敗及其後果。

標準化、認證和 SQA 系統評估元件

這些元件在組織內部實施國際專業和管理標準。此類元件的主要目標是利用國際專業知識，改進組織質量體系與其他組織的協調，並根據通用標準評估質量體系的成就。各種標準可以分為兩大類：質量管理標準和專案流程標準。

SQA 的組織 - 人員元件

SQA 組織基礎包括管理人員、測試人員、SQA 單位以及對軟體質量感興趣的人員，例如 SQA 受託人、SQA 委員會成員和 SQA 論壇成員。他們的主要目標是啟動和支援 SQA 元件的實施，檢測與 SQA 程式和方法的偏差，並提出改進建議。

專案前軟體質量元件

這些元件有助於改進在專案開始前採取的初步步驟。它包括 -

• 合同審查
• 開發和質量計劃

合同審查

通常，軟體是根據與客戶協商的合同開發的，或者是為了內部訂單開發嵌入硬體產品中的韌體。在所有這些情況下，開發部門都承諾遵守商定的功能規範、預算和時間表。因此，合同審查活動必須包括對專案建議草案和合同草案的詳細審查。

具體而言，合同審查活動包括 -

• 澄清客戶的需求

• 審查專案的進度安排和資源需求估算

• 評估專業人員執行擬議專案的能力

• 評估客戶履行其義務的能力

• 評估開發風險

開發和質量計劃

在與組織或同一組織的內部部門簽署軟體開發合同後，將準備專案的開發計劃及其整合的質量保證活動。這些計劃包括基於先前計劃的額外細節和必要的修訂，這些先前計劃為當前的提案和合同提供了基礎。

大多數情況下，在招標提交和合同簽署之間需要幾個月的時間。在此期間，資源（如員工可用性、專業能力）可能會發生變化。然後對計劃進行修訂以反映在此期間發生的更改。

專案開發計劃中處理的主要問題包括 -

• 時間表
• 所需人力和硬體資源
• 風險評估
• 組織問題：團隊成員、分包商和合作夥伴關係
• 專案方法、開發工具等。
• 軟體重用計劃

專案質量計劃中處理的主要問題包括 -

• 質量目標，以適當的可衡量術語表達

• 每個專案階段開始和結束的標準

• 審查、測試和其他計劃的驗證和確認活動的清單

軟體質量度量

軟體度量可以分為三類 -

• 產品度量 - 描述產品的特性，例如大小、複雜性、設計特性、效能和質量水平。

• 流程度量 - 這些特性可用於改進軟體的開發和維護活動。

• 專案度量 - 此度量描述專案特徵和執行情況。例如，軟體開發人員的數量、軟體生命週期中的人員配備模式、成本、進度和生產力。

某些度量屬於多個類別。例如，專案的在製品質量度量既是流程度量也是專案度量。

軟體質量度量是軟體度量的一個子集，專注於產品、流程和專案的質量方面。它們與流程和產品度量比與專案度量更密切相關。

軟體質量度量可以進一步分為三類 -

• 產品質量度量
• 在製品質量度量
• 維護質量度量

產品質量度量

此度量包括以下內容 -

• 平均故障間隔時間 (MTBF)
• 缺陷密度
• 客戶問題
• 客戶滿意度

平均故障間隔時間 (MTBF)

它是故障之間的時間。此度量主要用於安全關鍵系統，例如航空交通管制系統、航空電子裝置和武器。

缺陷密度

它衡量與軟體大小相關的缺陷，以程式碼行或功能點等表示，即衡量每個單元的程式碼質量。此度量用於許多商業軟體系統。

客戶問題

它衡量客戶在使用產品時遇到的問題。它包含客戶對軟體問題空間的看法，其中包括非缺陷導向的問題以及缺陷問題。

問題度量通常以每使用者月問題數 (PUM)表示。

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

其中，

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

PUM 通常在軟體釋出到市場後的每個月計算，以及按年計算月平均值。

客戶滿意度

客戶滿意度通常透過五點量表進行客戶調查資料測量 -

• 非常滿意
• 滿意
• 中立
• 不滿意
• 非常不滿意

對產品整體質量及其特定維度的滿意度通常透過各種客戶調查方法獲得。根據五點量表資料，可以構建和使用幾種略有差異的度量，具體取決於分析的目的。例如 -

• 完全滿意客戶的百分比
• 滿意客戶的百分比
• 不滿意客戶的百分比
• 不滿意的客戶的百分比

通常，使用此滿意度百分比。

在製品質量度量

在製品質量度量處理某些組織在正式機器測試期間缺陷到達情況的跟蹤。此度量包括 -

• 機器測試期間的缺陷密度
• 機器測試期間的缺陷到達模式
• 基於階段的缺陷去除模式
• 缺陷去除效率

機器測試期間的缺陷密度

正式機器測試（程式碼整合到系統庫後進行的測試）期間的缺陷率與現場的缺陷率相關。測試期間發現的缺陷率越高，表示軟體在其開發過程中經歷了更高的錯誤注入，除非較高的測試缺陷率是由於非凡的測試工作量導致的。

此簡單的每千行程式碼 (KLOC) 或功能點的缺陷度量是質量的一個良好指標，同時軟體仍在進行測試。它對於監控同一開發組織中產品的後續版本特別有用。

機器測試期間的缺陷到達模式

測試期間的整體缺陷密度只會提供缺陷的摘要。缺陷到達模式提供了有關現場不同質量水平的更多資訊。它包括以下內容 -

• 按時間間隔（例如，周）報告的測試階段的缺陷到達或缺陷。其中所有內容都不會是有效的缺陷。

• 在對報告的問題進行問題確定時，有效缺陷到達的模式。這是真正的缺陷模式。

• 缺陷積壓隨時間的變化模式。需要此度量，因為開發組織無法立即調查和修復所有報告的問題。這既是工作量說明也是質量說明。如果在開發週期結束時缺陷積壓很大，並且許多修復尚未整合到系統中，則系統的穩定性（因此其質量）將受到影響。需要重新測試（迴歸測試）以確保達到目標產品質量水平。

基於階段的缺陷去除模式

這是測試期間缺陷密度度量的擴充套件。除了測試之外，它還跟蹤開發週期所有階段的缺陷，包括設計評審、程式碼檢查和測試前的正式驗證。

由於很大一部分程式設計缺陷與設計問題有關，因此進行正式評審或功能驗證以增強前端流程的缺陷去除能力，可以減少軟體中的錯誤。基於階段的缺陷去除模式反映了開發流程的整體缺陷去除能力。

關於設計和編碼階段的度量，除了缺陷率外，許多開發組織還使用諸如檢查覆蓋率和檢查工作量等度量來進行在製品質量管理。

缺陷去除效率

它可以定義如下 -

$$DRE = \frac{開發階段去除的缺陷}{產品中存在的缺陷} \times 100\%$$

此度量可以針對整個開發流程、前端程式碼整合前以及每個階段進行計算。當用於前端時，它被稱為早期缺陷去除，而對於特定階段，則稱為階段有效性。度量值越高，開發流程越有效，傳遞到下一階段或現場的缺陷越少。此度量是軟體開發缺陷去除模型的關鍵概念。

維護質量度量

儘管在此階段無法做太多事情來改變產品的質量，但以下是可以執行的修復，以便儘快消除缺陷並確保出色的修復質量。

• 修復積壓和積壓管理指數
• 修復響應時間和修復響應能力
• 逾期修復的百分比
• 修復質量

修復積壓和積壓管理指數

修復積壓與缺陷到達率以及已報告問題的修復方案可用率相關。它是在每個月或每個星期結束時剩餘的已報告問題的簡單計數。將其用於趨勢圖格式，此指標可以提供有意義的資訊，以幫助管理維護過程。

積壓管理指數 (BMI) 用於管理未解決問題的積壓。

$$BMI = \frac{本月關閉的問題數量}{本月到達的問題數量} \times 100\%$$

如果 BMI 大於 100，則表示積壓減少。如果 BMI 小於 100，則表示積壓增加。

修復響應時間和修復響應能力

修復響應時間指標通常計算為所有問題從開啟到關閉的平均時間。較短的修復響應時間會導致客戶滿意度。

修復響應能力的重要因素包括客戶期望、商定的修復時間以及履行對客戶承諾的能力。

逾期修復的百分比

計算方法如下：

$逾期修復百分比 =$

$\frac{超過響應時間標準的修復數量（按嚴重程度級別）}{指定時間內交付的修復數量} \times 100\%$

修復質量

修復質量或有缺陷修復的數量是維護階段的另一個重要質量指標。如果修復沒有解決報告的問題，或者修復了原始問題但引入了新的缺陷，則該修復是有缺陷的。對於關鍵任務軟體，有缺陷的修復不利於客戶滿意度。有缺陷修復百分比指標是在一段時間內所有修復中出現缺陷的百分比。

有缺陷的修復可以透過兩種方式記錄：在發現的月份記錄，或在修復交付的月份記錄。第一種是客戶衡量方法；第二種是流程衡量方法。這兩個日期之間的差異是有缺陷修復的潛伏期。

通常，潛伏期越長，受影響的客戶就越多。如果缺陷數量很大，則百分比指標的小值將顯示樂觀的畫面。當然，維護過程的質量目標是零有缺陷修復且無逾期。

測量的基礎

測量是對某事物進行測量的行為。它是將數字分配給物件或事件的特徵，可以與其他物件或事件進行比較。

正式地，它可以定義為，將數字或符號分配給現實世界中實體的屬性的過程，以根據明確定義的規則對其進行描述。

日常生活中的測量

測量不僅被專業技術人員使用，而且在我們的日常生活中也被我們所有人使用。在商店裡，價格充當商品價值的衡量標準。同樣，身高和尺寸測量將確保布料是否合適。因此，測量將幫助我們將一件物品與另一件物品進行比較。

測量獲取有關實體屬性的資訊。實體是現實世界中的物件（如人）或事件（如旅程）。屬性是實體的特徵或特性，例如人的身高、旅程的成本等。在現實世界中，即使我們正在考慮測量事物，實際上我們正在測量這些事物的屬性。

屬性大多由數字或符號定義。例如，價格可以用盧比或美元的數量來指定，服裝尺寸可以用小、中、大來指定。

測量的準確性取決於測量儀器以及測量的定義。獲得測量結果後，我們必須對其進行分析，並必須得出關於實體的結論。

測量是直接量化，而計算是間接量化，我們使用某些公式組合不同的測量值。

軟體工程中的測量

軟體工程涉及管理、成本核算、計劃、建模、分析、規範、設計、實現、測試和維護軟體產品。因此，測量在軟體工程中發揮著重要作用。對於測量軟體產品的屬性，需要一種嚴格的方法。

對於大多數開發專案，

• 我們未能為我們的軟體產品設定可衡量的目標
• 我們未能理解和量化軟體專案的元件成本
• 我們沒有量化或預測我們生產的產品的質量

因此，為了控制軟體產品，有必要測量其屬性。每個測量行為都必須以明確定義且易於理解的特定目標或需求為動力。測量目標必須具體，針對管理人員、開發人員和使用者需要了解的內容。需要進行測量以評估專案、產品、流程和資源的狀態。

在軟體工程中，測量對於以下三個基本活動至關重要：

• 瞭解開發和維護期間發生了什麼
• 控制專案中發生的事情
• 改進流程和目標

測量的表示理論

測量告訴我們制定和推理各種測量基礎的規則。它是從經驗世界到形式關係世界的對映。因此，度量是透過此對映分配給實體的數字或符號，以表徵實體。

經驗關係

在現實世界中，我們透過比較事物來理解事物，而不是透過為其分配數字來理解事物。

例如，為了比較身高，我們使用“比……高”、“比……高”等術語。因此，這些“比……高”、“比……高”是身高的經驗關係。

我們可以在同一集合上定義多個經驗關係。

例如，X 比 Y 高。X、Y 比 Z 高得多。

經驗關係可以是一元的、二元的、三元的等。

X 高，Y 不高是一元關係。

X 比 Y 高是二元關係。

現實世界中的經驗關係可以對映到形式數學世界。這些關係大多反映了個人的偏好。

用於將這些經驗關係對映到數學世界的一些對映或評級技術如下：

李克特量表

在這裡，使用者將獲得一個陳述，他們必須同意或不同意。

例如 - 此軟體效能良好。

強制排序

將給定的備選方案按從 1（最好）到 n（最差）的順序排列。

例如：根據以下 5 個軟體模組的效能對其進行排名。

口頭頻率量表

例如 - 此程式故障的頻率如何？

順序量表

在這裡，使用者將獲得一個備選方案列表，他們必須選擇一個。

例如 - 此程式故障的頻率如何？

• 每小時
• 每天
• 每週
• 每月
• 每年幾次
• 每年一兩次
• 從不

比較量表

在這裡，使用者必須透過比較不同的選項來給出數字。

非常優越大致相同非常劣勢

12345678910

數值量表

在這裡，使用者必須根據其重要性給出數字。

不重要重要

12345678910

對映規則

要執行對映，我們必須指定域、範圍以及執行對映的規則。

例如 - 域 - 現實世界

• 範圍 - 數學世界，例如整數、實數等。

• 規則 - 用於測量身高，是否穿鞋

類似地，在軟體測量的情況下，要指定的程式碼行中要包含的語句的清單。

測量的表示條件

表示條件斷言，測量對映(M)必須將實體對映到數字，並將經驗關係對映到數值關係，以使經驗關係保留並由數值關係保留。

例如：“比……高”的經驗關係對映到數值關係“>”。即，如果且僅當 M(X) > M(Y) 時，X 才比 Y 高

由於給定集合上可以存在多種關係，因此表示條件對這些關係中的每一個都具有影響。

對於一元關係“高”，我們可能有數值關係

X > 50

表示條件要求對於任何度量M，

如果且僅當 M(X) > 50 時，X 才高

正式測量的關鍵階段

測量的關鍵階段可以總結如下：

測量和模型

模型可用於解釋現實世界實體的數值元素的行為以及測量它們。為了幫助測量過程，對映模型還應補充對映域模型。模型還應指定這些實體如何與屬性相關以及特徵如何相關。

測量分為兩種型別：

• 直接測量
• 間接測量

直接測量

這些是可以無需任何其他實體或屬性參與即可測量的測量。

以下直接測量方法通常用於軟體工程。

• 透過 LOC 計算原始碼長度
• 透過經過時間計算測試目的持續時間
• 透過計算缺陷來計算在測試過程中發現的缺陷數量
• 程式設計師在程式上花費的時間

間接測量

這些是可以根據任何其他實體或屬性進行測量的測量。

以下間接度量方法常用於軟體工程。

$$\small 程式設計師生產率 = \frac{產生的程式碼行數}{人月工作量}$$

$\small 模組缺陷密度 = \frac{缺陷數量}{模組規模}$

$$\small 缺陷檢測效率 = \frac{檢測到的缺陷數量}{缺陷總數}$$

$\small 需求穩定性 = \frac{初始需求數量}{需求總數}$

$\small 測試有效率 = \frac{覆蓋的專案數量}{專案總數}$

$\small 系統損耗 = \frac{用於修復故障的工作量}{專案總工作量}$

用於預測的度量

為了為專案分配適當的資源，我們需要預測開發專案的努力、時間和成本。用於預測的度量始終需要一個數學模型，該模型將要預測的屬性與我們現在可以測量的某些其他屬性相關聯。因此，預測系統由一個數學模型以及一組用於確定未知引數和解釋結果的預測程式組成。

測量尺度

度量尺度是用於表示經驗關係系統的對映。它主要有 5 種類型 -

• 名義尺度
• 順序量表
• 區間尺度
• 比率尺度
• 絕對尺度

名義尺度

它將元素置於分類方案中。這些類別將不會排序。每個實體都應根據屬性的值放置在特定的類別或範疇中。

它有兩個主要特徵 -

• 經驗關係系統僅由不同的類別組成；類別之間沒有排序的概念。

• 類別的任何不同的編號或符號表示都是可接受的度量，但數字或符號沒有關聯的量級概念。

順序量表

它將元素置於有序的分類方案中。它具有以下特徵 -

• 經驗關係系統由相對於屬性排序的類別組成。

• 任何保留排序的對映都是可接受的。

• 這些數字僅表示排名。因此，加法、減法和其他算術運算沒有意義。

區間尺度

此尺度捕獲有關分隔分類的區間的規模的資訊。因此，它比名義尺度和順序尺度更強大。

它具有以下特徵 -

• 它像順序尺度一樣保留順序。

• 它保留差異但不保留比率。

• 可以在此尺度上執行加法和減法，但不能執行乘法或除法。

如果某個屬性可以在區間尺度上測量，並且M和M’是滿足表示條件的對映，則我們始終可以找到兩個數字a和b，使得，

M = aM’ + b

比率尺度

這是最有用的測量尺度。在這裡，存在一個經驗關係來捕獲比率。它具有以下特徵 -

• 它是一個保留排序、實體之間區間大小和實體之間比率的測量對映。

• 有一個零元素，表示完全缺乏屬性。

• 測量對映必須從零開始並以相等間隔（稱為單位）遞增。

• 可以應用所有算術運算。

這裡，對映將採用以下形式

M = aM’

其中'a'是一個正標量。

絕對尺度

在此尺度上，屬性只有一個可能的度量。因此，唯一可能的轉換將是恆等轉換。

它具有以下特徵 -

• 透過計算實體集中元素的數量來進行測量。

• 屬性始終採用“實體中x出現的次數”的形式。

• 只有一個可能的測量對映，即實際計數。

• 可以在結果計數上執行所有算術運算。

實證研究

實證調查涉及對任何工具、技術或方法的科學調查。此調查主要包含以下 4 個原則。

• 選擇調查技術
• 陳述假設
• 控制變數
• 使調查有意義

選擇調查技術

軟體工程中實證調查的關鍵組成部分是 -

• 調查
• 案例研究
• 正式實驗

調查

調查是對情況的回顧性研究，以記錄關係和結果。它始終在事件發生後進行。例如，在軟體工程中，可以進行民意調查以確定使用者對特定方法、工具或技術的反應，以確定趨勢或關係。

在這種情況下，我們無法控制手頭的情況。我們可以記錄一種情況並將其與類似的情況進行比較。

案例研究

這是一種研究技術，您可以在其中識別可能影響活動結果的關鍵因素，然後記錄活動：其輸入、約束、資源和輸出。

正式實驗

它是對活動進行的嚴格控制的調查，其中識別和操縱關鍵因素以記錄其對結果的影響。

可以根據以下指南選擇特定的調查方法 -

• 如果活動已經發生，我們可以進行調查或案例研究。如果尚未發生，則可以選擇案例研究或正式實驗。

• 如果我們對可能影響結果的變數有較高水平的控制，則可以使用實驗。如果我們無法控制變數，則案例研究將是首選技術。

• 如果在較高級別上無法複製，則無法進行實驗。

• 如果複製成本低，則可以考慮實驗。

陳述假設

為了促進特定調查技術的決策，研究的目標應表達為我們要檢驗的假設。假設是程式設計師認為解釋他們想要探索的行為的暫定理論或假設。

控制變數

在陳述假設之後，接下來我們必須確定影響其真實性的不同變數以及我們對其有多少控制權。這一點至關重要，因為實驗和案例研究之間的關鍵區別在於對影響行為的變數的控制程度。

狀態變數是能夠表徵專案並也能影響評估結果的因素，用於在正式實驗中區分控制情況和實驗情況。如果我們無法區分控制和實驗，則案例研究技術將是首選。

例如，如果我們想確定程式語言的變化是否會影響專案的生產力，那麼語言將是一個狀態變數。假設我們目前正在使用 FORTRAN，我們想用 Ada 替換它。那麼 FORTRAN 將是控制語言，Ada 將是實驗語言。

使調查有意義

實驗結果通常比案例研究或調查更具普遍性。案例研究或調查的結果通常僅適用於特定組織。以下幾點證明了這些技術在回答各種問題方面的效率。

符合理論和傳統智慧

案例研究或調查可用於證實傳統智慧以及許多其他標準、方法或工具在一個組織中的有效性和實用性。但是，正式實驗可以調查這些說法普遍成立的情況。

探索關係

案例研究或調查可以表明資源和軟體產品各種屬性之間的關係。

例如，對已完成專案的調查可以顯示，用特定語言編寫的軟體比用其他語言編寫的軟體錯誤更少。

瞭解和驗證這些關係對於任何未來專案的成功至關重要。每個關係都可以表示為一個假設，並且可以設計一個正式實驗來檢驗這些關係成立的程度。通常，透過保持其他屬性恆定或受控來觀察一個特定屬性的值。

評估模型的準確性

模型通常用於預測活動的成果或指導方法或工具的使用。在設計實驗或案例研究時，它提出了一個特別困難的問題，因為它們的預測通常會影響結果。專案經理經常將預測轉化為完成的目標。當使用成本和進度模型時，這種影響很常見。

某些模型（例如可靠性模型）不會影響結果，因為可靠性（以平均故障時間衡量）只有在軟體準備好投入現場使用後才能評估。

驗證度量

有許多軟體度量來捕獲屬性的值。因此，必須進行一項研究來檢驗給定的度量是否反映了它應該捕獲的屬性的變化。驗證是透過將一個度量與另一個度量相關聯來執行的。應使用第二個度量（也是影響因素的直接有效度量）來進行驗證。此類度量並不總是可用或易於測量。此外，使用的度量必須符合對正在測量的因素的人類概念。

軟體測量

軟體度量框架基於三個原則 -

• 對要檢查的實體進行分類
• 確定相關的度量目標
• 識別組織已達到的成熟度水平

對要檢查的實體進行分類

在軟體工程中，主要存在三類實體。他們是 -

• 過程
• 產品
• 資源

所有這些實體都具有內部和外部實體。

• 內部屬性是可以純粹根據過程、產品或資源本身測量的屬性。例如：規模、複雜性、模組之間的依賴關係。

• 外部屬性是指僅相對於其與環境的關係才能測量的屬性。例如：使用者遇到的故障總數、搜尋資料庫並檢索資訊所需的時間。

每個實體可以測量的不同屬性如下 -

過程

過程是軟體相關活動的集合。以下是可以直接為過程測量的某些內部屬性 -

• 過程或其活動之一的持續時間

• 與過程或其活動之一相關的工作量

• 在過程或其活動之一期間發生的特定型別事件的數量

過程的不同外部屬性是成本、可控性、有效性、質量和穩定性。

產品

產品不僅是管理層承諾交付的專案，而且是在軟體生命週期中產生的任何工件或文件。

不同的內部產品屬性包括規模、工作量、成本、規範、長度、功能、模組化、重用、冗餘和語法正確性。其中，規模、工作量和成本比其他屬性更容易測量。

不同的外部產品屬性包括可用性、完整性、效率、可測試性、可重用性、可移植性和互操作性。這些屬性不僅描述程式碼，還描述支援開發工作的其他文件。

資源

這些是流程活動所需的實體。它可以是軟體生產的任何輸入。包括人員、材料、工具和方法。

資源的不同內部屬性包括年齡、價格、大小、速度、記憶體大小、溫度等。不同的外部屬性包括生產力、經驗、質量、可用性、可靠性、舒適性等。

確定相關的度量目標

只有當某個度量有助於理解流程或其結果產品之一時，它才有用。只有當專案為流程和產品明確定義了目標時，才能改進流程或產品。對目標的清晰理解可用於在流程成熟度框架的上下文中為給定專案生成建議的指標。

目標-問題-度量 (GQM) 正規化

GQM 方法提供了一個包含以下三個步驟的框架：

• 列出開發或維護專案的主要目標

• 從每個目標中推匯出必須回答的問題，以確定目標是否正在實現

• 確定為了能夠充分回答這些問題必須測量什麼

要使用 GQM 正規化，首先我們表達組織的總體目標。然後，我們生成問題，以便知道答案，以便我們能夠確定目標是否正在實現。稍後，根據我們需要什麼測量來回答每個問題來分析每個問題。

典型的目標以生產力、質量、風險、客戶滿意度等方面表達。目標和問題應根據其受眾構建。

為了幫助生成目標、問題和指標，Basili & Rombach 提供了一系列模板。

• 目的 - 為了（表徵、評估、預測、激勵等） （流程、產品、模型、指標等），以便理解、評估、管理、工程、學習、改進等。示例：為了表徵產品以便學習它。

• 視角 - 從開發人員、經理、客戶等的觀點檢查（成本、有效性、正確性、缺陷、更改、產品度量等）。示例：從客戶的角度檢查缺陷。

• 環境 - 環境包括以下內容：流程因素、人員因素、問題因素、方法、工具、約束等。示例：此軟體的客戶是那些不瞭解工具的人。

度量和流程改進

通常度量對以下方面有用：

• 理解流程和產品
• 建立基線
• 訪問和預測結果

根據 SEI 給出的流程成熟度級別，度量型別和度量程式將有所不同。以下是可以在每個成熟度級別應用的不同度量程式。

級別 1：臨時性

在此級別，輸入定義不明確，而輸出是預期的。從輸入到輸出的轉換是未定義且不受控制的。對於此流程成熟度級別，需要基線測量以提供測量的起點。

級別 2：可重複性

在此級別，流程的輸入和輸出、約束和資源都是可識別的。可重複的流程可以用以下圖表描述。

輸入度量可以是需求的大小和波動性。輸出可以用系統大小來衡量，資源可以用員工工作量來衡量，約束可以用成本和時間表來衡量。

級別 3：已定義

在此級別，中間活動已定義，並且它們的輸入和輸出已知並被理解。已定義流程的一個簡單示例在以下圖中描述。

可以檢查、測量和評估中間活動的輸入和輸出。

級別 4：已管理

在此級別，來自早期專案活動的反饋可用於為當前活動以及以後的專案活動設定優先順序。我們可以衡量流程活動的有效性。度量反映了整體流程以及主要活動之間和跨主要活動的互動作用的特徵。

級別 5：最佳化

在此級別，來自活動的度量用於透過刪除和新增流程活動以及根據測量反饋動態更改流程結構來改進流程。因此，流程更改可能會影響組織和專案以及流程。流程將充當感測器和監控器，我們可以根據警告訊號顯著更改流程。

在給定的成熟度級別，我們可以收集該級別及其以下所有級別的測量結果。

識別成熟度級別

流程成熟度建議僅測量可見內容。因此，流程成熟度與 GQM 的結合將提供最有用的度量。

• 在級別 1，專案可能具有定義不明確的需求。在此級別，需求特徵的測量很困難。

• 在級別 2，需求已明確定義，並且可以收集其他資訊，例如每個需求的型別以及對每種型別的更改次數。

• 在級別 3，中間活動已定義，每個活動都有進入和退出標準

目標和問題分析將相同，但指標會隨成熟度而變化。流程越成熟，測量結果就越豐富。GQM 正規化與流程成熟度相結合，已被用作協助經理設計測量程式的幾種工具的基礎。

GQM 有助於理解測量屬性的需要，而流程成熟度表明我們是否有能力以有意義的方式進行測量。它們共同為測量提供了上下文。

軟體測量驗證

驗證軟體系統的測量涉及兩個步驟：

• 驗證測量系統
• 驗證預測系統

驗證測量系統

度量或測量系統用於透過數值表徵其一個或多個屬性來評估現有實體。如果度量準確地表徵了它聲稱要測量的屬性，則該度量是有效的。

驗證軟體測量系統是透過顯示錶示條件是否滿足來確保度量是聲稱屬性的適當數值表徵的過程。

為了驗證測量系統，我們需要一個描述實體的形式模型和一個保留我們正在測量的屬性的數值對映。例如，如果有兩個程式 P1 和 P2，並且我們想連線這些程式，那麼我們期望任何長度的度量m滿足以下條件：

m(P1+P2) = m(P1) + m(P2)

如果程式P1的長度大於程式P2，則任何度量m也應滿足：

m(P1) > m(P2)

程式的長度可以透過計算程式碼行數來衡量。如果此計數滿足上述關係，我們可以說程式碼行數是長度的有效度量。

驗證度量的正式要求涉及證明它在測量理論的意義上表徵了所述屬性。驗證可用於確保度量定義正確且與實體的現實世界行為一致。

驗證預測系統

預測系統用於預測未來實體的某些屬性，涉及具有相關預測程式的數學模型。

在給定環境中驗證預測系統是透過經驗方法（即透過將模型效能與給定環境中的已知資料進行比較）來建立預測系統準確性的過程。它涉及實驗和假設檢驗。

可接受的驗證準確度取決於預測系統是確定性的還是隨機的，以及進行評估的人員。一些隨機預測系統比其他系統更隨機。

隨機預測系統的示例包括軟體成本估算、工作量估算、進度估算等系統。因此，為了正式驗證預測系統，我們必須確定其隨機程度，然後將預測系統的效能與已知資料進行比較。

軟體測量指標

軟體度量是一個包含許多活動的度量標準，這些活動涉及一定程度的測量。它可以分為三類：產品度量、流程度量和專案度量。

• 產品度量描述產品的特徵，例如大小、複雜性、設計特性、效能和質量水平。

• 流程度量可用於改進軟體開發和維護。例如，開發過程中缺陷移除的有效性、測試缺陷到達的模式以及修復流程的響應時間。

• 專案度量描述專案特徵和執行情況。例如，軟體開發人員的數量、軟體生命週期內的員工配置模式、成本、時間表和生產力。

某些度量屬於多個類別。例如，專案的在製品質量度量既是流程度量也是專案度量。

軟體度量的範圍

軟體度量包含許多活動，包括以下內容：

• 成本和工作量估算
• 生產力度量和模型
• 資料收集
• 數量模型和度量
• 可靠性模型
• 效能和評估模型
• 結構和複雜度指標
• 能力成熟度評估
• 基於指標的管理
• 方法和工具的評估

軟體度量是這些活動的各種集合，從預測特定階段軟體專案成本的模型到程式結構的度量。

成本和工作量估算

工作量表示為一個或多個變數的函式，例如程式的大小、開發人員的能力和重用級別。已經提出了成本和工作量估算模型，以便在軟體生命週期的早期階段預測專案成本。提出的不同模型有：

• Boehm 的 COCOMO 模型
• Putnam 的 SLIM 模型
• Albrecht 的功能點模型

生產力模型和度量

生產力可以被認為是價值和成本的函式。每個都可以分解成不同的可測量大小、功能、時間、金錢等。生產力模型的不同可能組成部分可以在以下圖表中表示。

資料收集

任何測量程式的質量顯然取決於仔細的資料收集。收集到的資料可以提煉成簡單的圖表和圖形，以便管理人員瞭解開發的進度和問題。資料收集對於科學研究關係和趨勢也至關重要。

質量模型和度量

已經開發了質量模型來測量產品質量，沒有它，生產力就沒有意義。這些質量模型可以與生產力模型相結合，以測量正確的生產力。這些模型通常以樹狀方式構建。上層分支包含重要的高階質量因素，例如可靠性和可用性。

分而治之的方法已被實施作為衡量軟體質量的標準方法。

可靠性模型

大多數質量模型都將可靠性作為組成因素，但是，預測和測量可靠性的需要導致了可靠性建模和預測的單獨專業化。可靠性理論中的基本問題是預測系統最終何時會失效。

效能評估和模型

它包括外部可觀察的系統性能特徵，例如響應時間和完成率，以及系統的內部工作，例如演算法的效率。它是質量的另一個方面。

結構和複雜性度量

在這裡，我們測量軟體表示的結構屬性，這些屬性在執行之前可用。然後，我們嘗試建立經驗預測理論來支援質量保證、質量控制和質量預測。

能力成熟度評估

此模型可以評估開發的許多不同屬性，包括工具的使用、標準實踐等。它基於每個優秀承包商都應使用的關鍵實踐。

指標管理

對於軟體專案的管理，測量發揮著至關重要的作用。為了檢查專案是否按計劃進行，使用者和開發人員可以依靠基於測量的圖表和圖形。當軟體嵌入到產品中時，標準的測量和報告方法尤其重要，在這種情況下，客戶通常不熟悉軟體術語。

方法和工具的評估

這取決於實驗設計、可能影響結果的因素的正確識別以及因素屬性的適當測量。

資料操作

軟體度量是一個衡量標準，包含許多活動，這些活動涉及一定程度的測量。軟體測量的成功在於收集和分析的資料質量。

什麼是好的資料？

如果收集到的資料能夠回答以下問題，則可以將其視為好資料：

• 它們是否正確？ - 如果資料是根據度量定義的精確規則收集的，則可以將其視為正確。

• 它們是否準確？ - 準確性是指資料與實際值之間的差異。

• 它們是否具有適當的精確度？ - 精確度涉及表達資料所需的十進位制位數。

• 它們是否一致？ - 如果資料在一個測量裝置到另一個測量裝置之間沒有顯示出重大差異，則可以將其視為一致。

• 它們是否與特定的活動或時間段相關聯？ - 如果資料與特定的活動或時間段相關聯，則應在資料中明確指定。

• 它們是否可以複製？ - 通常，調查（例如調查、案例研究和實驗）會在不同的情況下重複進行。因此，資料也應該能夠輕鬆複製。

如何定義資料？

為測量目的而收集的資料有兩種型別：

• 原始資料 - 原始資料來自對過程、產品或資源的初始測量。例如：組織中員工的每週時間表。

• 精煉資料 - 精煉資料來自從原始資料中提取基本資料元素以推匯出屬性值的結果。

可以根據以下幾點定義資料：

• 位置
• 時間
• 症狀
• 最終結果
• 機制
• 原因
• 嚴重程度
• 成本

如何收集資料？

資料收集需要人工觀察和報告。經理、系統分析師、程式設計師、測試人員和使用者必須在表單上記錄行資料。為了收集準確和完整的資料，重要的是：

• 保持程式簡單

• 避免不必要的記錄

• 培訓員工瞭解記錄資料的必要性以及要使用的程式

• 及時以有用的形式向原始提供者提供資料捕獲和分析的結果，以幫助他們開展工作

• 在中央收集點驗證所有收集到的資料

資料收集計劃涉及以下幾個步驟：

• 根據 GQM 分析決定要測量哪些產品

• 確保產品處於配置控制之下

• 準確確定要測量的屬性以及如何推匯出間接測量

• 一旦指標集明確且要測量的元件集已確定，就設計一種方案來識別測量過程中涉及的每個活動

• 建立處理表單、分析資料和報告結果的程式

資料收集計劃必須在專案計劃開始時開始。實際的資料收集發生在開發的許多階段。

例如 - 與專案人員相關的一些資料可以在專案開始時收集，而其他資料收集（例如工作量）則從專案開始到操作和維護一直持續。

如何儲存和提取資料

在軟體工程中，資料應儲存在資料庫中，並使用資料庫管理系統 (DBMS) 設定。下圖顯示了資料庫結構的示例。該資料庫將儲存在組織的不同部門工作的不同員工的詳細資訊。

在上圖中，每個框都是資料庫中的一個表，箭頭表示從一個表到另一個表的多種到一種的對映。對映定義了保留資料邏輯一致性的約束。

一旦資料庫設計完成並填充了資料，我們就可以使用資料操縱語言來提取資料進行分析。

分析軟體測量資料

收集相關資料後，我們必須以適當的方式對其進行分析。在選擇分析技術時，需要考慮三個主要事項。

• 資料的性質
• 實驗的目的
• 設計考慮因素

資料的性質

為了分析資料，我們還必須檢視資料所代表的更大總體以及該資料的分佈。

抽樣、總體和資料分佈

抽樣是從大量總體中選擇一組資料的過程。樣本統計資料描述和總結從一組實驗物件獲得的度量。

總體引數表示如果測量所有可能的受試者將獲得的值。

總體或樣本可以用集中趨勢的度量（如平均值、中位數和眾數）和離散趨勢的度量（如方差和標準差）來描述。許多資料集呈正態分佈，如下面的圖形所示。

如上所示，資料將均勻分佈在平均值周圍，這是正態分佈的重要特徵。

還存在其他分佈，其中資料偏斜，使得平均值一側的資料點多於另一側。例如：如果大部分資料出現在平均值的左側，那麼我們可以說分佈向左偏斜。

實驗的目的

通常，進行實驗是為了：

• 確認理論
• 探索關係

為了實現這些目標，應根據假設正式表達目標，並且分析必須直接解決假設。

確認理論

調查必須設計成探索理論的真實性。該理論通常指出，使用某種方法、工具或技術對受試者具有特定影響，使其在某些方面優於另一種方法。

需要考慮兩種資料情況：正態資料和非正態資料。

如果資料來自正態分佈並且有兩個組要比較，則可以使用學生 t 檢驗進行分析。如果有多於兩個組要比較，則可以使用稱為 F 統計量的方差分析通用檢驗。

如果資料是非正態的，則可以透過對其進行排序使用 Kruskal-Wallis 檢驗進行分析。

探索關係

調查旨在確定描述一個變數或多個變數的資料點之間的關係。

有三種技術可以回答有關關係的問題：箱線圖、散點圖和相關分析。

• 箱線圖可以表示一組資料的範圍摘要。

• 散點圖表示兩個變數之間的關係。

• 相關分析使用統計方法來確認兩個屬性之間是否存在真實關係。

  • 對於正態分佈的值，使用Pearson 相關係數來檢查兩個變數是否高度相關。

  • 對於非正態資料，對資料進行排序並使用Spearman 等級相關係數作為關聯度量。非正態資料的另一個度量是Kendall 穩健相關係數，它調查資料點對之間的關係，並且可以識別部分相關性。

如果排名包含大量繫結值，則可以使用卡方檢驗對列聯表進行檢驗，以檢驗變數之間的關聯性。類似地，線性迴歸可用於生成描述變數之間關係的方程。

對於兩個以上變數，可以使用多元迴歸。

設計考慮因素

在選擇分析技術時必須考慮調查的設計。同時，分析的複雜性會影響所選的設計。多個組使用 F 統計量而不是具有兩個組的學生 T 檢驗。

對於具有兩個以上因素的複雜析因設計，需要更復雜的關聯和顯著性檢驗。

統計技術可用於解釋一組變數對其他變數的影響，或補償時間或學習效應。

內部產品屬性

內部產品屬性以僅依賴於產品本身的方式描述軟體產品。測量內部產品屬性的主要原因是，它將有助於在開發過程中監控和控制產品。

測量內部產品屬性

主要的內部產品屬性包括大小和結構。大小可以在不執行它們的情況下靜態測量。產品的大小告訴我們建立它所需的工作量。同樣，產品的結構在設計產品的維護方面也起著重要作用。

測量大小

軟體大小可以用三個屬性來描述：

• 長度 - 它代表產品的物理大小。

• 功能 - 它描述了產品向用戶提供的功能。

• 複雜性 - 複雜性有多種型別，例如。

  • 問題複雜性 - 衡量底層問題的複雜性。

  • 演算法複雜性 - 衡量用於解決問題的演算法的複雜性

  • 結構複雜性 - 衡量用於實現演算法的軟體的結構。

  • 認知複雜性 - 衡量理解軟體所需的工作量。

這三個屬性的測量可以描述如下：

長度

有三個開發產品，其尺寸測量對於預測預測所需的工作量很有用。它們是規範、設計和程式碼。

規範和設計

這些文件通常結合文字、圖形和特殊的數學圖表及符號。規格測量可用於預測設計的長度，而設計的長度反過來又是程式碼長度的預測指標。

文件中的圖表具有統一的語法，例如帶標籤的有向圖、資料流圖或 Z 模式。由於規格和設計文件由文字和圖表組成，因此其長度可以用表示文字長度和圖表長度的一對數字來衡量。

對於這些測量，需要為不同型別的圖表和符號定義原子物件。

資料流圖的原子物件是過程、外部實體、資料儲存和資料流。代數規範的原子實體是排序、函式、運算和公理。Z 模式的原子實體是規範中出現的各種線條。

程式碼

程式碼可以透過多種方式生成，例如過程語言、面向物件和視覺化程式設計。最常用的傳統原始碼程式長度度量是程式碼行數 (LOC)。

總長度為，

LOC = NCLOC + CLOC

即，

LOC = 未註釋 LOC + 已註釋 LOC

除了程式碼行數外，還可以使用 Maurice Halstead 提出的其他替代方案，例如大小和複雜度來進行度量。

Halstead 的軟體科學試圖捕捉程式的不同屬性。他提出了三個內部程式屬性，例如長度、詞彙量和體積，這些屬性反映了大小的不同視角。

他首先將程式P定義為令牌的集合，這些令牌按運算子或運算元分類。這些令牌的基本度量是：

• μ₁ = 唯一運算子的數量

• μ₂ = 唯一運算元的數量

• N₁ = 運算子的總出現次數

• N₂ = 唯一運算子的數量

程式P的長度可以定義為

$$N = N_{1}+ N_{2}$$

程式P的詞彙量為

$$\mu =\mu _{1}+\mu _{2}$$

程式的體積 = 編寫長度為N的程式所需的思維比較次數，為

$$V = N\times {log_{2}} \mu$$

體積為V的程式P的程式級別為：

$$L = \frac{V^\ast}{V}$$

其中，$V^\ast$是潛在體積，即P的最小規模實現的體積

級別的倒數是難度 -

$$D = 1\diagup L$$

根據 Halstead 理論，我們可以計算估計值L為

$${L}' = 1\diagup D = \frac{2}{\mu_{1}} \times \frac{\mu_{2}}{N_{2}}$$

類似地，估計的程式長度為，$\mu_{1}\times log_{2}\mu_{1}+\mu_{2}\times log_{2}\mu_{2}$

生成 P 所需的工作量由下式給出：

$$E = V\diagup L = \frac{\mu_{1}N_{2}Nlog_{2}\mu}{2\mu_{2}}$$

其中，測量單位E是理解P所需的初級心理辨別次數

測量長度的其他替代方案為 -

• 根據程式文字所需的計算機儲存位元組數

• 根據程式文字中的字元數

面向物件開發提出了新的長度度量方法。Pfleeger 等人發現，物件和方法的數量比使用程式碼行數更能準確地估計生產力。

功能

產品中固有的功能量給出了產品規模的度量。有許多不同的方法來衡量軟體產品的功能。我們將在下一章討論其中一種方法——Albrecht 的功能點方法。

阿爾布雷希特功能點方法

功能點度量提供了一種標準化的方法來衡量軟體應用程式的各種功能。它從使用者的角度衡量功能，即基於使用者請求並作為回報獲得的內容。功能點分析是從使用者的角度衡量軟體開發的標準方法。

Albrecht 最初提出的功能點度量隨著 1986 年國際功能點使用者組 (IFPUG) 的成立而越來越受歡迎。2002 年，IFPUG 功能點成為國際 ISO 標準——ISO/IEC 20926。

什麼是功能點？

FP（功能點）是適用於量化軟體應用程式的最廣泛的功能型別度量。它基於五種使用者可識別的邏輯“功能”，這些功能分為兩種資料功能型別和三種事務功能型別。對於給定的軟體應用程式，這些元素中的每一個都被量化和加權，並計算其特徵元素，例如檔案引用或邏輯欄位。

結果數字（未調整的 FP）被分組到新增、更改或刪除的功能集中，並與價值調整因子 (VAF) 相結合以獲得最終的 FP 數量。每種計數型別都使用不同的最終公式：應用程式、開發專案或增強專案。

應用 Albrecht 的功能點方法

現在讓我們瞭解如何應用 Albrecht 的功能點方法。其步驟如下 -

確定元件的數量（EI、EO、EQ、ILF 和 ELF）

• EI - 外部輸入的數量。這些是派生資料跨越邊界從外部傳遞到內部的基本過程。在一個示例庫資料庫系統中，輸入現有使用者的借書證號碼。

• EO - 外部輸出的數量。這些是派生資料跨越邊界從內部傳遞到外部的基本過程。在一個示例庫資料庫系統中，顯示借給使用者的書籍列表。

• EQ - 外部查詢的數量。這些是既有輸入又有輸出元件的基本過程，這些過程會導致從一個或多個內部邏輯檔案和外部介面檔案中檢索資料。在一個示例庫資料庫系統中，確定當前借給使用者的書籍。

• ILF - 內部邏輯檔案數量。這些是使用者可識別的邏輯相關資料組，完全駐留在應用程式邊界內，並透過外部輸入維護。在一個示例庫資料庫系統中，圖書館中書籍的檔案。

• ELF - 外部邏輯檔案數量。這些是使用者可識別的邏輯相關資料組，僅用於參考目的，並且完全駐留在系統外部。在一個示例庫資料庫系統中，包含圖書館計費系統中交易的檔案。

計算未調整的功能點計數 (UFC)

• 將每個元件評定為低、平均或高。

• 對於事務（EI、EO 和 EQ），評級基於FTR和DET。

  • FTR - 更新或引用的檔案數量。

  • DET - 使用者可識別的欄位數量。

  • 根據下表，引用 2 個檔案和 10 個數據元素的EI將被評為平均。

• 對於檔案（ILF 和 ELF），評級基於RET和DET。

  • RET - ILF或ELF中使用者可識別的數 據元素的數量。

  • DET - 使用者可識別的欄位數量。

  • 根據下表，包含 10 個數據元素和 5 個欄位的ILF將被評為高。

• 將評級轉換為UFC。

計算最終功能點計數 (FPC)

• 基於 14 個一般系統特徵（GSC）計算價值調整因子（VAF）。

• 根據其對問題的影響程度（從無影響到強烈影響），將每個GSC在 0 到 5 的範圍內進行加權。

• 如下計算FPC -

  FPC = UFC * (0.65+(sum(GSC) * .01))

複雜性

複雜度是規模的獨立組成部分。它有兩種型別 -

• 問題的複雜性 - 它是解決問題所需的最優解決方案所需資源的數量。

• 解決方案的複雜性 - 它是實現特定解決方案所需的資源。它有兩個方面。它們如下 -

  • 時間複雜度 - 資源是計算機時間。

  • 空間複雜度 - 資源是計算機記憶體。

測量複雜度

複雜度的一個方面是效率。它衡量任何可以建模為演算法的軟體產品。

例如：如果解決特定問題所有例項的演算法需要f(n)次計算，那麼如果對於任何其他解決該問題的複雜度為g的演算法，f都是O(g)，則f(n)是漸近最優的。那麼，給定問題的複雜度就是解決該問題漸近最優演算法的O。

度量結構

度量軟體的結構特性對於估計開發工作量以及產品的維護非常重要。需求、設計和程式碼的結構有助於理解將一個產品轉換為另一個產品的難度、測試產品的難度或從早期內部產品度量預測外部軟體屬性的難度。

結構度量的型別

軟體的結構包含三個部分。它們是 -

• 控制流結構 - 指程式中指令執行的順序。

• 資料流結構 - 指資料與其互動的程式的行為。

• 資料結構 - 指資料元素以列表、佇列、棧或其他定義良好的結構形式組織，以及建立、修改或刪除它們的演算法。

度量控制流結構

控制流度量通常使用有向圖建模，其中每個節點或點對應於程式語句，每條弧或有向邊指示從一個語句到另一個語句的控制流。這些圖稱為控制流圖或有向圖。

如果‘m’是根據流圖模型定義的結構度量，並且如果程式A的結構比程式B更復雜，那麼度量m(A)應該大於m(B)。

度量資料流結構

資料流或資訊流可以是模組間的（模組內資訊流）或模組內的（單個模組與系統其餘部分之間資訊流）。

根據資料在系統中移動的方式，可以將其分類為以下幾種 -

• 區域性直接流 - 如果一個模組呼叫第二個模組並向其傳遞資訊，或者被呼叫模組將結果返回給呼叫者。

• 區域性間接流 - 如果被呼叫模組返回的資訊隨後被傳遞給第二個被呼叫模組。

• 全域性流 - 如果資訊透過全域性資料結構從一個模組流向另一個模組。

根據 Henry 和 Kafura 的說法，資訊流複雜度可以表示為：

資訊流複雜度 (M) = 長度 (M) × 扇入 (M) × (扇出 (M))²

其中，

• 扇入 (M) - 終止於 M 的區域性流數 + M 從中檢索資訊的數資料結構數。

• 扇出 (M) - 發源於 M 的區域性流數 + M 更新的資料結構數。

度量資料結構

資料結構可以是區域性的，也可以是全域性的。

區域性地，將度量每個資料項中的結構量。可以使用圖論方法來分析和度量各個資料結構的屬性。在該方法中，將簡單的整數、字元和布林型別資料視為素數，並考慮使我們能夠構建更復雜資料結構的各種操作。然後可以根據素數的值和與各種操作關聯的值，分層定義資料結構度量。

全域性地，將度量使用者定義變數的總數。

標準和證書

一些國家和國際標準機構、專業和行業導向組織一直參與軟體質量保證標準的制定。

以下機構和組織是軟體質量保證和軟體工程標準的主要制定者 -

• IEEE（電氣和電子工程師協會）計算機協會
• ISO（國際標準化組織）
• DOD（美國國防部）
• ANSI（美國國家標準學會）
• IEC（國際電工委員會）
• EIA（電子工業聯盟）

這些組織為軟體開發和維護組織中執行的專業和管理活動質量提供更新的國際標準。

他們還透過獨立的專業質量稽核提供軟體質量保證認證。這些外部稽核評估軟體質量保證系統開發及其實施的成就。在定期稽核後授予的認證僅在下次稽核之前有效，因此必須續期。目前，ISO 9000認證服務是歐洲和其他國家最主要的軟體質量保證認證提供商。

他們還提供用於組織軟體質量保證系統及其運營的自評估工具。由軟體工程研究所（SEI），卡內基梅隆大學和ISO/IEC標準15504開發的能力成熟度模型（CMM）是這種方法的例子。

軟體質量保證標準

軟體質量保證標準可以分為兩大類 -

• 軟體質量保證管理標準，包括認證和評估方法（質量管理標準）

• 軟體專案開發過程標準（專案過程標準）

質量管理標準

這些標準側重於組織的軟體質量保證系統、基礎設施和需求，同時將方法和工具的選擇留給組織。透過質量管理標準，組織可以穩定地確保其軟體產品達到可接受的質量水平。

示例 - ISO 9000-3和能力成熟度模型（CMM）

專案過程標準

這些標準側重於實施軟體開發和維護專案的方法。這些標準包括以下內容 -

• 需要採取的步驟
• 設計文件要求
• 設計文件的內容
• 設計評審和評審問題
• 要執行的軟體測試
• 測試主題

當然，由於其特性，此類中的許多軟體質量保證標準可以作為軟體工程標準，反之亦然。

這兩類標準的特徵總結在下表中。

ISO 9001認證

ISO（國際標準化組織）是一個由各國標準機構組成的世界性聯合會。ISO技術委員會編制國際標準。ISO與國際電工委員會（IEC）在所有電工標準化事宜上密切合作。

國際標準的起草符合ISO/IEC指南第2部分中規定的規則。技術委員會透過的國際標準草案將分發給成員機構進行投票。ISO 9001由技術委員會ISO/TC 176，質量管理和質量保證，分委員會SC 2，質量體系編制。

過程方法

本國際標準鼓勵在開發、實施和改進質量管理體系的有效性時採用過程方法，透過滿足客戶要求來增強客戶滿意度。為了使組織有效運作，它必須確定和管理許多關聯的活動。可以使用資源並進行管理以實現將投入轉換為輸出的活動或一組活動，可以視為一個過程。

通常，一個過程的輸出直接構成下一個過程的輸入。在組織內應用過程系統，以及識別和互動這些過程，以及對其進行管理以產生預期結果，可以稱為“過程方法”。

過程方法的一個優點是它對過程系統中各個過程之間的聯絡以及它們的組合和互動提供了持續的控制。在質量管理體系中使用時，這種方法強調以下內容的重要性 -

• 理解和滿足要求
• 需要從增值方面考慮流程
• 獲取過程績效和有效性的結果
• 基於客觀測量的流程持續改進

ISO 9001 - 軟體應用：TickIT 計劃

TickIT 於 1980 年代後期由英國軟體行業與英國貿易和工業部合作發起，旨在促進開發一種將 ISO 9001 適應軟體行業特徵的方法，稱為 TickIT 計劃。

TickIT 此外，還專門從事資訊科技 (IT)。它涵蓋了商業軟體開發和維護服務的整個範圍。TickIT 現在由 BSI（英國標準協會）的 DISC 部門管理和維護，已獲得在英國和瑞典認證 IT 組織的資格。

其活動包括 -

• 出版 TickIT 指南，支援軟體行業努力推廣 ISO 9001 認證。目前的指南（第 5.0 版，TickIT，2001），其中包括對 ISO/IEC 12207 和 ISO/IEC 15504 的引用，分發給所有 TickIT 客戶。

• 除了管理之外，還對軟體質量體系進行基於稽核的評估，並向組織提供有關改進軟體開發和維護流程的諮詢。

• 進行 ISO 9000 認證稽核。

進行基於稽核的評估和認證稽核的 TickIT 稽核員由國際註冊認證稽核員 (IRCA) 註冊。註冊的 IRCA 稽核員除其他事項外，還必須具有管理和軟體開發經驗；他們還必須成功完成稽核員課程。

註冊首席稽核員必須具備進行和指導 TickIT 稽核的證明經驗。

軟體過程評估

軟體過程評估是對組織使用的軟體過程進行的紀律審查，基於過程模型。評估包括識別和描述當前實踐、識別優勢和劣勢領域，以及當前實踐控制或避免導致軟體質量、成本和進度不佳的重要原因的能力。

軟體評估（或稽核）可以分為三種類型。

• 自我評估（第一方評估）由組織自身人員在內部執行。

• 第二方評估由外部評估團隊執行，或者組織由客戶評估。

• 第三方評估由外部方執行，例如（例如，第三方評估供應商以驗證其與客戶簽訂合同的能力）。

軟體過程評估在開放和協作的環境中進行。它們供組織改進其軟體過程使用，結果對組織保密。被評估的組織必須在評估團隊中擁有成員。

軟體過程成熟度評估

軟體過程評估的範圍可以涵蓋組織中的所有過程、軟體過程的選定子集或特定專案。大多數基於標準的過程評估方法都基於過程成熟度的概念。

當評估目標是組織時，即使在連續應用相同方法的情況下，過程評估的結果也可能有所不同。產生不同結果有兩個原因。它們是，

• 必須確定正在調查的組織。對於大型公司，組織的定義可能有多種，因此在後續評估中，實際評估範圍可能會有所不同。

• 即使是在看似相同的組織中，選擇代表該組織的專案樣本也會影響評估範圍和結果。

當評估的目標單元為專案級別時，評估應包含所有對專案成功或失敗有意義的因素。它不應受給定流程成熟度模型的既定維度的限制。在此，評估實施程度及其有效性，並以專案資料作為依據。

當組織打算開始整體長期改進策略時，流程成熟度變得相關。軟體專案評估應為獨立評估，以便客觀。

軟體流程評估週期

根據 Paulk 及其同事 (1995) 的說法，基於 CMM 的評估方法使用六步迴圈。它們是 -

• 選擇團隊 - 團隊成員應為軟體工程和管理方面的專業人士。

• 待評估站點的代表填寫標準流程成熟度問卷。

• 評估團隊對問卷回覆進行分析，並根據 CMM 關鍵流程域確定需要進一步探索的領域。

• 評估團隊進行現場考察，以瞭解站點所遵循的軟體流程。

• 評估團隊列出評估結果，其中指出了組織軟體流程的優勢和劣勢。

• 評估團隊準備關鍵流程域 (KPA) 配置檔案分析，並將結果呈現給合適的受眾。

例如，評估團隊必須由經授權的 SEI 主評估師領導。團隊必須由 4 到 10 名團隊成員組成。至少一名團隊成員必須來自被評估的組織，所有團隊成員都必須完成 SEI 的 CMM 簡介課程（或等效課程）和 SEI 的 CBA IPI 團隊培訓課程。團隊成員還必須滿足某些選拔指南。

關於資料收集，CBA IPI 依賴於四種方法 -

• 標準成熟度問卷
• 個人和集體訪談
• 文件審查
• 評估參與者審查草案結果的反饋

SCAMPI

標準 CMMI 流程改進評估方法 (SCAMPI) 的開發是為了滿足 CMMI 模型的要求（軟體工程研究所，2000 年）。它也基於 CBA IPI。CBA IPI 和 SCAMPI 都包含三個階段 -

• 計劃和準備
• 在現場進行評估
• 報告結果

計劃和準備階段的活動包括 -

• 確定評估範圍
• 制定評估計劃
• 準備和培訓評估團隊
• 對參與者進行簡要評估
• 管理 CMMI 評估問卷
• 檢查問卷回覆
• 進行初步文件審查

現場評估階段的活動包括 -

• 召開開幕會議
• 進行訪談
• 整合資訊
• 準備草案結果的演示
• 展示草案結果
• 整合、評定和準備最終結果

報告結果階段的活動包括 -

• 展示最終結果
• 舉行高管會議
• 結束評估

質量保證

IEEE 對軟體質量保證的定義如下 -

“一項計劃和系統的行動模式，旨在提供充分的信心，以確保專案或產品符合既定的技術要求。一組旨在評估產品開發或製造過程的活動。”

SQA 活動的目標

SQA 活動的目標如下 -

在軟體開發中（面向過程）

• 確保軟體符合功能性技術要求的可接受的置信水平。

• 確保軟體符合管理計劃和預算要求的可接受的置信水平。

• 發起和管理活動，以改進和提高軟體開發和 SQA 活動的效率。

在軟體維護中（面向產品）

• 確保軟體維護活動符合功能性技術要求的可接受的置信水平。

• 確保軟體維護活動符合管理計劃和預算要求的可接受的置信水平。

• 發起和管理活動，以改進和提高軟體維護和 SQA 活動的效率。這包括在降低成本的同時提高實現功能和管理要求的前景。

質量保證的組織

在組織結構內運作的質量保證組織框架包括以下參與者 -

管理人員

• 高層管理人員，特別是直接負責軟體質量保證的高管

• 軟體開發和維護部門經理

• 軟體測試部門經理

• 開發和維護專案的專案經理和團隊領導

• 軟體測試團隊的領導者

測試人員

• 軟體測試團隊的成員

SQA 專業人員和相關從業人員 -

• SQA 受託人
• SQA 委員會成員
• SQA 論壇成員
• SQA 單位團隊成員

只有軟體測試部門的管理人員和員工全職從事 SQA 任務。其他人將部分時間用於質量問題，無論是在履行其管理職能或專業任務期間，還是作為其他方面的志願者，最常見的是 SQA 委員會、SQA 論壇或 SQA 受託人。

管理在質量保證中的作用

基本上，軟體開發組織中存在三級管理結構 -

• 高層管理
• 部門管理
• 專案管理

高層管理在軟體質量中的職責

以下是高層管理人員在確保軟體質量方面的職責 -

• 確保公司軟體產品和軟體維護服務的質量

• 向所有級別的員工傳達產品和服務質量以及客戶滿意度的重要性

• 確保滿意地執行並完全符合客戶要求

• 確保為組織的 SQA 系統設定質量目標，並確保實現其目標

• 發起計劃並監督實施必要的變更，以使 SQA 系統適應與組織的客戶、競爭和技術相關的重大內部和外部變化

• 直接干預以支援解決危機情況並最大程度地減少損失

• 確保 SQA 系統所需資源的可用性

高層管理可以採取以下步驟來履行其職責 -

• 制定和更新組織的軟體質量政策。

• 委派一位高管（例如 SQA 副總裁）負責軟體質量問題

• 定期對軟體質量問題方面的績效進行管理審查

軟體質量政策

組織的軟體質量政策應傳達以下要求 -

• 符合組織的宗旨和目標

• 致力於一般的軟體質量保證理念

• 致力於組織採用的質量標準

• 致力於為軟體質量保證分配足夠的資源

• 致力於持續改進組織的質量和生產力

負責軟體質量的高管

負責軟體質量問題的高管的職責可以歸類為 -

• 負責編制年度 SQA 活動計劃和預算

• 負責編制 SQA 系統開發計劃

• 全面控制年度 SQA 常規活動計劃和計劃的 SQA 開發專案的實施

• 向高層管理層展示和宣傳 SQA 問題

負責編制年度 SQA 活動計劃

這要求高管 -

• 制定系統未來一年的 SQA 目標

• 審查 SQA 單位編制的年度活動計劃提案，並核實提案實現為 SQA 系統設定的目標的潛力

• 確定活動計劃是否足以滿足未來一年計劃的分包商服務和軟體採購的特性和範圍

• 確定為實施 SQA 計劃而計劃的人力和其他資源的充足性

• 批准年度 SQA 活動計劃和預算的最終版本

負責編制 SQA 系統開發計劃

這些計劃必須適應技術以及客戶需求和競爭的變化。職責包括 -

• 審查預計將在不久的將來影響組織軟體質量的趨勢

• 審查 SQA 適應提案，例如準備適合新工具和 SQA 標準的新程式

• 為經驗豐富的軟體開發團隊和新招募的團隊成員準備培訓計劃

• 開發適合評估新工具和標準以及培訓計劃成功的軟體質量指標

• 批准計劃的 SQA 開發專案的最終版本，包括其時間表和預算

全面控制年度 SQA 計劃的實施

負責人負責 -

• 年度活動計劃的總體監督

• 審查 SQA 適應專案的進展情況

• 根據定期報告，總體監督為實現團隊目標而規定的質量成就所採取的行動

• 根據內部質量稽核審查對 SQA 程式和標準的合規性

• 對軟體開發專案時間表和預算的一般後續跟蹤

• 對向外部和內部客戶提供質量維護服務的一般後續跟蹤

向高層管理層展示和宣傳 SQA 問題

為了促進質量和解決 SQA 系統困難，它需要 -

• 展示擬議的年度活動計劃和預算以供最終批准

• 展示計劃的 SQA 適應專案以及相應的預算以供最終批准

• 發起和領導定期管理審查會議，專門討論組織的軟體質量

• 發起管理層討論，專門討論特殊的軟體質量事件，例如嚴重的質量故障、由於嚴重的專業人員短缺而導致專案成功完成受到威脅、SQA 單位的管理危機等

部門管理在 SQA 中的職責

中層管理的質量保證職責包括：

• 軟體質量管理體系的管理（與質量體系相關的任務）

• 管理特定經理許可權下部門或團隊執行的專案和服務相關任務（與專案相關的任務）

與質量體系相關的職責

這些包括在部門層面執行的SQA活動：

• 根據SQA部門編制的推薦方案，制定部門年度SQA活動計劃和預算

• 根據SQA部門編制的推薦計劃，制定部門SQA系統開發計劃

• 控制部門年度SQA活動計劃和開發專案的執行情況

• 向高層管理層彙報部門SQA問題

與專案相關的職責

這些職責根據組織的流程和許可權分配而有所不同；通常包括：

• 控制部門各單位對質量保證流程的合規性，包括CAB、SCM和SCCA機構

• 詳細跟蹤合同審查結果和提案審批

• 審查單位計劃審查活動的執行情況；批准專案檔案和專案階段完成情況

• 跟蹤軟體測試和測試結果；批准專案的軟體產品

• 跟蹤軟體開發專案進度計劃和預算偏差

• 為專案經理提供建議和支援，以解決進度、預算和客戶關係方面的問題

• 跟蹤維護服務提供質量

• 詳細跟蹤專案風險及其解決方案

• 跟蹤專案對客戶需求的符合性和客戶滿意度

• 批准大型軟體變更單和專案規範的重大偏差

軟體質量方面的專案管理職責

大多數專案管理職責在流程和工作說明中定義；專案經理負責確保所有團隊成員遵守上述流程和說明。

其任務包括專業實踐和管理任務，特別是以下方面：

• 專業實踐任務

  • 制定專案和質量計劃及其更新

  • 參與客戶-供應商聯合委員會

  • 密切跟蹤專案團隊人員配備，包括招聘、培訓和指導

• 管理任務

  專案經理處理以下跟蹤問題：

  • 審查活動的執行情況以及由此產生的糾正措施

  • 軟體開發和維護部門的執行情況、整合和系統測試活動以及糾正和迴歸測試

  • 驗收測試的執行情況

  • 軟體在遠端客戶站點安裝以及客戶對軟體系統的執行

  • SQA對專案團隊成員的培訓和指導

  • 分配給專案活動的進度和資源

  • 客戶請求和滿意度

  • 不斷發展的專案開發風險、解決方案的應用和結果控制

軟體質量保證小組

SQA部門的結構因組織的型別和規模而異。下圖顯示了一個標準結構的示例以及SQA部門下的所有組成部分。在本章中，我們將討論每個子部門的角色和職責。

SQA部門負責人執行的任務

SQA部門負責人負責SQA部門及其子部門執行的所有質量保證任務。這些任務可以歸類為以下類別：

• 計劃任務
• 部門管理
• SQA專業活動

計劃任務

• 制定部門年度活動計劃和預算提案

• 規劃和更新組織的軟體質量管理體系

• 為軟體開發和維護部門制定推薦的年度SQA活動計劃和SQA系統開發計劃

管理任務

• 管理SQA團隊的活動

• 監控SQA活動計劃的實施

• 提名團隊成員、SQA委員會成員和SQA受託人

• 準備特殊和定期報告，例如組織內軟體質量問題的現狀和每月績效報告

SQA專業活動

• 參與專案聯合委員會
• 參與正式的設計評審
• 審查和批准與規範的偏差
• 與專案經理和團隊負責人協商
• 參與SQA委員會和論壇

專案生命週期SQA

與專案生命週期子部門相關的SQA任務可以分為兩類：

• “純”管理跟蹤和審批任務（專案生命週期控制任務）

• “實踐”或積極參與專案團隊SQA活動，需要專業貢獻（參與任務）

專案生命週期控制任務

• 跟蹤開發和維護團隊對SQA流程和工作說明的遵守情況

• 根據相關流程批准或推薦軟體產品

• 監控向內部和外部客戶交付軟體維護服務

• 監控客戶滿意度並與客戶質量保證代表保持聯絡

參與任務

這些任務包括參與：

• 合同審查
• 制定和更新專案開發和質量計劃
• 正式的設計評審
• 分包商的正式設計評審
• 軟體測試，包括客戶驗收測試
• 分包商軟體產品的軟體驗收測試
• 新軟體產品的安裝

SQA基礎設施運營任務

SQA系統採用各種基礎設施元件以確保順利執行，即：

• 流程和工作說明
• 支援質量裝置（模板、清單）
• 員工培訓、指導和認證
• 預防和糾正措施
• 配置管理
• 文件控制

更具體地說，SQA子部門關於這些元件的任務包括：

• 釋出流程、工作說明、模板、清單等的更新版本，以及以紙質和/或電子方式分發

• 向新員工和現有員工傳達有關遵守和應用SQA流程、工作說明和類似事項的培訓和指導

• 指導SQA受託人瞭解新的和修訂的流程以及開發工具和方法等元件

• 監控和支援新修訂的SQA流程的實施

• 跟蹤員工認證活動

• 提出需要採取預防和糾正措施的事項，包括參與CAB委員會

• 跟蹤配置管理活動，包括參與CCA委員會

• 跟蹤對文件流程和工作說明的合規性

SQA內部審計和認證任務

軟體組織內部或由其進行的SQA審計型別可以分類如下：

• 內部審計

• 審計分包商和供應商以評估其SQA系統

• 由認證機構執行的外部審計

• 由希望在接受組織為供應商之前評估SQA系統的客戶執行的外部審計

前兩類審計由SQA子部門發起和執行，後兩類由外部機構執行。

SQA部門為內部SQA審計執行以下任務

• 制定內部SQA審計年度計劃

• 執行內部SQA審計

• 跟蹤被審計團隊和其他部門需要執行的糾正和改進措施

• 準備審計結果現狀的定期彙總報告，包括改進建議

SQA部門為分包商和供應商的審計執行以下任務：

• 制定分包商和供應商SQA審計年度計劃

• 執行分包商和供應商的SQA審計

• 跟蹤被審計的分包商和供應商需要執行的糾正和改進措施

• 從內部和外部來源收集有關分包商和供應商績效的資料

• 根據審計報告和從其他內部和外部來源收集的資訊，定期評估組織認證的分包商和供應商的SQA系統。評估報告包括：

  • 關於分包商和供應商認證的建議

  • 由認證機構執行的外部審計涉及以下任務：

    • 協調認證審計的內容和時間安排

    • 準備認證機構指定的文件

    • 指導被審計團隊併為認證審計做好必要的準備工作

    • 參與認證審計

    • 確保執行必要的糾正和改進措施

組織客戶執行的SQA審計需要執行以下任務：

• 協調審計的內容和時間安排

• 準備客戶審計員指定的文件

• 指導被審計團隊併為組織客戶的SQA審計做好必要的準備工作

• 參與審計

• 確保執行必要的糾正和改進措施

SQA支援任務

大多數SQA支援服務的消費者位於組織內部。他們包括專案經理、團隊負責人和SQA受託人。他們的任務包括：

• 制定專案計劃和專案質量計劃

• 配備審查團隊

• 選擇解決已識別軟體開發風險的措施

• 選擇解決進度延遲和預算超支的措施

• 選擇SQA指標和軟體成本組成部分

• 使用SQA資訊系統

• 選擇反映SQA部門積累的故障經驗資料的開發方法和工具

SQA標準和流程任務

SQA子部門密切參與決定採用哪些SQA標準以及開發和維護組織的流程。為了履行相關義務，SQA部門需要：

• 制定新流程和流程更新的年度開發計劃

• 負責制定新的程式和更新現有程式，並參與相關的委員會和論壇。

• 跟蹤SQA和軟體工程標準的發展和變化；引入與組織相關的額外程式和更改。

• 根據專業標準的變化，啟動程式的更新和調整，包括採用或刪除組織應用的標準。

SQA工程任務

跟蹤專業進展、解決操作難題和對故障進行專家分析是該SQA子單元的直接目標。

因此，主要的工程任務包括以下內容：

• 測試新開發工具和當前使用開發工具的新版本在質量和生產力方面的表現。

• 評估新的開發和維護方法以及方法改進的質量和生產力。

• 開發針對當前使用的軟體開發工具和方法應用中遇到的困難的解決方案。

• 開發衡量軟體質量和團隊生產力的方法。

• 在CAB委員會分析軟體開發故障並制定擬議解決方案期間，提供技術支援。

SQA資訊系統任務

SQA資訊系統旨在促進和改進SQA系統的運作。涉及的任務包括：

• 為軟體開發和維護部門開發SQA資訊系統，用於

  • 收集活動資料

  • 處理例如定期報告、列表、異常報告和查詢。

  • 處理例如定期報告、列表、異常報告和查詢。

• 開發SQA資訊系統，以方便SQA單元處理軟體開發和維護部門提供的的資訊，包括軟體質量度量和軟體質量成本的估算。

• 更新SQA資訊系統。

• 開發和維護組織的SQA網際網路/內聯網站點。

SQA受託人和他們的任務

SQA受託人是主要參與軟體質量提升的成員。這些成員為成功實施SQA元件提供必要的內部支援。

他們的任務可能因組織而異。因此，它可能是與單元相關的任務和/或與組織相關的任務。

與單元相關的任務

• 支援同事解決在實施軟體質量程式和工作說明期間遇到的困難。

• 協助單元經理執行相關的SQA任務。

• 促進合規性並監控同事對SQA程式和工作說明的執行情況。

• 將重大且系統的違規事件報告給SQA單元。

• 將嚴重的軟體質量故障報告給SQA單元。

與組織相關的任務

• 觸發組織範圍內的SQA程式和工作說明的更改和更新。

• 觸發組織內開發和維護流程的改進。

• 就相應單元中觀察到的重複性故障的解決方案向CAB提交申請。

• 識別整個組織的SQA培訓需求，並提出由SQA單元進行的適當培訓或指導計劃。

SQA委員會及其任務

SQA委員會可以是永久性的，也可以是臨時的。任務可能因組織而異。

• 永久性委員會通常處理SCC（軟體變更控制）、CA（糾正措施）、程式、方法開發工具和質量度量。

• 臨時委員會通常處理具有普遍意義的具體案例，例如更新特定程式、分析和解決軟體故障、制定針對特定流程或產品的軟體度量、更新軟體質量成本以及針對特定問題的收集資料方法。

永久性SQA委員會是SQA組織框架不可或缺的一部分；其任務和運作通常在組織的SQA程式中定義。

臨時委員會是根據短期問題為基礎建立的，成員由負責軟體質量問題的負責人、SQA單元負責人、SQA子單元、永久性SQA委員會或任何其他發起其形成並對工作感興趣的機構提名。該機構還定義了臨時委員會的任務。