軟件開發(fā)（系統(tǒng)開發(fā)）的質(zhì)量管理與硬件的開發(fā)管理完全不同。

原因在于，不可能像硬件產(chǎn)品那樣，在客戶手中檢查已完成軟件的質(zhì)量。 軟件的質(zhì)量只能通過觀察軟件在計算機中的運行情況或通過編程語言編寫的源代碼來檢查。

本文介紹了軟件開發(fā)的基礎(chǔ)知識以及各開發(fā)階段的品質(zhì)管理控制要點。

1.1軟件開發(fā)的種類和方法

軟件開發(fā)主要有兩種方法。

一種是瀑布式（Waterfall）開發(fā)手法。 另一種是敏捷型(Agile)。

具體的開發(fā)方法進一步區(qū)分說明。

1）Waterfall型開發(fā)手法

• 需求定義：是指在開始軟件開發(fā)等項目之前，以易于理解的方式將必要的功能和需求整合在一起的過程。
• 設(shè)計：在確定軟件必要的功能和要求后，確定軟件的行為和詳細(xì)功能，并將其寫入文檔。
• 實施：為了實現(xiàn)設(shè)計所定下的軟件動作或功能，實際上進行的編程動作。 在這個過程中，程序員使用編程語言編寫源代碼。
• 測試：這是檢查所開發(fā)的程序是否能順利運行，是否存在缺陷（Bug）的過程。 如果發(fā)現(xiàn)缺陷，則予以糾正。
• 發(fā)行：這是將開發(fā)好的軟件提供給客戶的過程。 在這一階段，客戶可以自己操作軟件。

所謂瀑布型，是因為開發(fā)是“瀑布的水從上到下依次前進”而得名。在軟件開發(fā)之初，將客戶的要求規(guī)格匯總，然后按照設(shè)計、實施的順序進行。最后實施各種確認(rèn)測試并發(fā)布軟件。（參照圖1）

這種方法是軟件的主流開發(fā)方法，從大型項目開發(fā)到小規(guī)模系統(tǒng)，在很多情況下都被使用。

詢問客戶的要求和規(guī)格，將其整理成軟件系統(tǒng)，整理成一份文件（“要求定義書”）。

《瀑布式的特點》

瀑布型有以下優(yōu)缺點：

• 基于 "需求定義文件"（有時也稱為 "系統(tǒng)設(shè)計文件"），可以開發(fā)設(shè)計文檔（"基本設(shè)計文件"或 "詳細(xì)設(shè)計文件"），以確定軟件的行為和功能。
• 在設(shè)計文檔的基礎(chǔ)上，可以創(chuàng)建程序并進行運行測試。
• 由于軟件規(guī)格在一開始就已確定，因此質(zhì)量、交付和成本更易于管理。
• 但缺點是，如果在這一過程中對規(guī)格進行修改，工時（"工時 x 天"）將大幅增加，因為這涉及到大量的設(shè)計和程序修改。

在實踐中的一個具體例子是，這種方法通常用于保證可靠性的大型系統(tǒng)和開發(fā)（如銀行系統(tǒng)、運輸系統(tǒng)等）。

(2) 敏捷型（Agile）開發(fā)方法。

敏捷（英語：Agile）是一種開發(fā)方法，意為 "快速 "或 "積極"。

敏捷開發(fā)是一種在短時間內(nèi)多次重復(fù)開發(fā)周期（設(shè)計→實施→測試），最終完成軟件的方法。

當(dāng)軟件開發(fā)開始時，客戶的規(guī)格要求只是部分功能時，這種方法尤其適用。 (見圖 2）。

敏捷開發(fā)的核心特質(zhì)：

1. **迭代開發(fā)**：每個軟件功能都可在多個短暫的開發(fā)循環(huán)中逐步完善。

2. **靈活性**：允許根據(jù)客戶反饋和市場動態(tài)調(diào)整規(guī)格，確保產(chǎn)品與時俱進。

3. **緊密協(xié)作**：開發(fā)者與客戶間的頻繁交流，確保需求的準(zhǔn)確理解和實時更新。

然而，這也帶來了一些挑戰(zhàn)：

– **進度不確定性**：頻繁的變更可能會影響開發(fā)時間表。

– **文檔不足**：過于依賴口頭溝通可能導(dǎo)致詳細(xì)的設(shè)計文檔缺乏，對質(zhì)量控制和工時管理構(gòu)成考驗。

敏捷方法在面對需求快速變動的行業(yè)領(lǐng)域展現(xiàn)出顯著優(yōu)勢。比如，日本航空（JAL）的預(yù)訂和票務(wù)系統(tǒng)開發(fā)便成功運用了敏捷實踐，充分展示了其適應(yīng)變化的能力。

2.2 軟件開發(fā)流程

軟件開發(fā)一般遵循圖 3 所示的流程（開發(fā)過程）。

定義需求和設(shè)計具體化系統(tǒng)概念和整體形象的過程被稱為 "上游過程"，而編碼（實施）和測試過程通常被稱為 "下游過程"。

評審記錄是對軟件開發(fā)過程中創(chuàng)建的文檔和源代碼的評審（評價和改進建議）記錄。 具體來說，它描述了評審過程中的討論內(nèi)容、指出的問題和提出的改進建議。 在各種設(shè)計和測試中出現(xiàn)錯誤時，會記錄進度狀態(tài)和參與成員（如會議時間），并將其用作審查文件。

(1) 需求定義和設(shè)計

本節(jié)介紹確定軟件開發(fā)設(shè)計規(guī)范的上游過程，包括如何進行和所需的管理要點。

軟件設(shè)計一般分為以下三個主要步驟：

• 需求定義
• 基本設(shè)計
• 詳細(xì)設(shè)計（*有些人認(rèn)為詳細(xì)設(shè)計是 "下游流程 "的一部分）

(i) 需求定義

需求定義是明確待開發(fā)軟件的需求（功能、規(guī)格、性能、質(zhì)量、交付、成本、開發(fā)時 間等）的過程。 如果這些要求沒有得到明確定義，日后可能會出現(xiàn) "額外規(guī)格 "或 "相互矛盾的功能"，這將大大增加交付時間和成本。

因此，有必要在與客戶和其他相關(guān)方充分討論后，完成一份 "需求定義文件"。

(2) 設(shè)計過程（基本設(shè)計、詳細(xì)設(shè)計）

在基本設(shè)計中，根據(jù) "需求定義 "編寫 "基本設(shè)計文件"，詳細(xì)概述系統(tǒng)的結(jié)構(gòu)和規(guī)格。 這份 "基本設(shè)計文件 "可能包括所有系統(tǒng)功能、數(shù)據(jù)庫配置（表定義和 ER 圖）、屏幕和表單布局以及測試計劃。

在詳細(xì)設(shè)計中，設(shè)計必要的組件（小程序單元）處理、批處理等。 它還包括屏幕和表單周圍的細(xì)節(jié)設(shè)計、系統(tǒng)處理的數(shù)據(jù)文件的規(guī)格設(shè)計、詳細(xì)的數(shù)據(jù)庫設(shè)計（物理設(shè)計）等，以及 "詳細(xì)設(shè)計文件 "的編寫。

在這些設(shè)計過程中，對每份設(shè)計文件進行審查（評估并指出改進之處）非常重要。

此外，還要檢查上層設(shè)計文件的內(nèi)容是否轉(zhuǎn)移到下層設(shè)計文件中，各設(shè)計文件之間是否存在遺漏或矛盾。

(2) 編碼（實施）

編碼是根據(jù)上述詳細(xì)設(shè)計文件編寫程序的過程。

根據(jù)結(jié)構(gòu)，確定必要的變量、函數(shù)和控制語句（如 if）。 此外，還要根據(jù)與數(shù)據(jù)庫的聯(lián)系，選擇使用函數(shù)和處理變量的方式。

在代碼審查中，代碼是否編寫得清晰易讀？ 代碼是否易于測試？ 是否存在任何安全問題？ 是否存在安全問題？

(3) 測試流程

V 型模型的流程如圖 4 所示，是測試過程的一個縮影。

軟件開發(fā)測試與驗證

這個 "V "形模型展示了軟件開發(fā)從 "需求定義 "到 "系統(tǒng)測試 "的步驟順序。

V 型的左側(cè)按降序描述了從 "需求定義 "流程開始的上游流程；V 型的右側(cè)按升序描述了測試流程；通過比較 V 型的左右部分，可以了解每個測試流程要驗證哪個設(shè)計流程，以及測試的重點是什么。

在每個測試流程中，要檢查的測試項目是通過分析每個設(shè)計流程的要求和設(shè)計細(xì)節(jié)來設(shè)計的。 這就是 "測試設(shè)計"。

(i) 單元測試

單元測試是檢查由軟件源代碼最小單元組成的每個程序（模塊）是否按詳細(xì)設(shè)計運行的測試。

具體來說，需要確認(rèn)使用的數(shù)據(jù)、使用程序和操作方法。 通過這種測試，可及早發(fā)現(xiàn)和糾正程序中的錯誤（故障）。它確定是否存在任何問題，

(ii) 組合測試

組合測試是檢查開發(fā)的軟件是否按基本設(shè)計運行的測試。 它將已完成單元測試的所有模塊結(jié)合起來，檢查所需功能是否正常工作。

具體來說，主要目的是檢查在與生產(chǎn)環(huán)境相同的使用環(huán)境中，組合模塊的功能是否存在缺陷。 通過這種測試，可以將模塊連接在一起，并發(fā)現(xiàn)和修復(fù)模塊內(nèi)部的錯誤。

(iii) 系統(tǒng)測試（又稱 "全面測試）

系統(tǒng)測試是軟件開發(fā)過程的最后一步，確認(rèn)軟件整體的行為和功能符合需求定義中的規(guī)格。 有時也稱為 "全面測試"。

系統(tǒng)測試在單元測試和耦合測試之后進行。

具體來說，系統(tǒng)測試是假定由客戶操作的測試，是在向客戶發(fā)布軟件前進行的最后檢查。

(iv) 各測試過程的質(zhì)量控制。

測試過程中的質(zhì)量控制是解決每次測試中出現(xiàn)的問題（如錯誤）并防止其再次發(fā)生的活動。

應(yīng)提出以下問題：每次測試過程中發(fā)現(xiàn)的錯誤是否超出事先預(yù)測的目標(biāo)值？ 我們還要分析趨勢，如其他模塊出現(xiàn)類似錯誤的情況。

此外，上述錯誤的原因和遺漏錯誤的原因都要追溯到設(shè)計過程以及更高層次的檢查和編碼過程。

3. 提高文檔質(zhì)量和 bug 收斂是關(guān)鍵點

以下三點在軟件開發(fā)質(zhì)量控制中尤為重要。

(1）在每次設(shè)計評審中，擁有優(yōu)秀的評審人員和充足的評審時間對防止出現(xiàn) Bug 非常重要。

2）在代碼審查過程中，除了對每段代碼本身進行審查外，還需要對代碼進行驗證，以防止出現(xiàn)安全漏洞。

(3）測試過程的目的是避免發(fā)布后出現(xiàn)問題。 因此，不僅要關(guān)注每次測試中是否存在錯誤及其補救措施，還要關(guān)注潛在錯誤的檢測。

在軟件質(zhì)量控制中，上游文檔的質(zhì)量和測試過程中的錯誤關(guān)閉狀態(tài)是重要的控制點。

測試結(jié)果為發(fā)布后不出現(xiàn)問題提供了保證。