摘要
本文的目的是比較軟件質量和軟件風險管理之間的關系。文章首先回顧了基本原理、技術，以及它們在質量軟件開發過程中的應用。讀者可以知道風險管理的基本概念，包括Boehmis的六步風險管理過程。文章討論了質量軟件技術是如何既是軟件開發風險的貢獻者又是緩和者。
質量入門介紹
根據國際標準組織（ISO）的定義，質量是依靠特定的或暗指的能力滿足特定需要的產品或服務的全部功能和特征。這個定義說明了質量是產品的內在特征，描繪了產品的質量觀點。第二個學術派的觀點堅持如果要達到質量的目標必須在這個質量的概念上要加強。這個學派認為，質量不是單獨以產品為中心的，而是和客戶和產品都有聯系的，其中客戶是出資金者或受影響的部分人，而產品包括利益和服務。進一步講，質量的概念會隨著時間響應和環境價值的改變而改變，價值會使人們弄清什么是好的、什么是不好的。因此，軟件的質量作為產品或服務需要的功能/特征，也必須定位于客戶和組織間的內容(R.T. Vidgen,A.T. Wood-Harper)。這是關于質量的有用的觀點。這些回顧的細節包含在以下幾段文字里，第一步是人為因素。
質量觀點
對于質量的觀點，開發過程中的每個人都有不同的看法和矛盾。以下幾點由開發過程中的幾個關鍵角色提供的簡要描述：
* 開發經理：產品是可靠的、可維護性好的，能夠讓客戶滿意，如此直到項目結束或強制終止（這導致折衷的需要）。
* 商業分析者：客戶和開發小組聯合，保護用戶定義的功能和需求不受外部改變干擾。
* QA審計師：發現從質量方案/產品中脫軌的現象——所有使過程偏離質量控制的活動將受到與項目有關的人員的反對。
* 最終用戶：初級雇員很少給系統輸入什么，但是對它的操作必須有責任。最終用戶不滿意，當他們不愿意為系統付支票時，就需要監察系統的可接受程度了。
* 生產線經理：最終用戶的老板通常持有這樣的態度，即他們不需要太大的時間周期。
* 項目投資者：付鈔票的人，需要按時、按預算地交付產品。
最后，是開發人員的質量觀點，這直接影響到選擇最終產品生產的方法。這不僅起源于開發者的質量觀點（產品相對于使用），也起源于如何獲得需求（主管相對于客觀），和他們如何創造他們工作的環境（協調相對于沖突）。R.T.Vidgen和A.T.Wood-Harper提出了四種可能的開發者對質量的認識觀點：
* 客觀的/協調的：在目標沒有問題并且得到很好的描述時，開發人員會客觀地認為質量是一個合理的工程過程。質量是和詳細闡述、實現開發過程嚴格控制的需要結合的。開發者趨向于接受質量是產品的屬性的觀點（這是目前大多數軟件工程師的觀點）。
* 客觀的/矛盾的：開發者不僅明白質量是客觀的，而且理解矛盾的興趣是可以解決的，于是不可能滿足所有人的質量需求，而會確定滿足誰的需求（使管理者的還是工人的呢？）。
* 客觀的/一致的：開發者認為質量關系到團體的結構，要解決許多不同團體（投資者/受益者）的不同的觀點和興趣。最終的結果反映了不同觀點的一致意見。
* 客觀的/矛盾的：開發者考慮了不同的觀點和興趣，但是，假定會有沖突和功能上的限制，解放者構造質量的新思路，這要求滿足多的興趣而忽視少部分功能。這一點更像一種協調而不是意見統一。
質量特征和屬性
所有學派都認為質量軟件有兩個有區別的特征：第一，即是規范的一致性（如這是一個好的方案嗎？），第二，即適合它的有意的目標（是問題的正確定位嗎？）。另外，所有學派都認為有一個構成高質量的軟件的屬性。搜索有關不同質量相關的文獻都會有許多不同的屬性列表，下面是Glass建議的七個屬性：
輕便性：允許軟件能夠從一臺計算機很容易地傳輸到另一臺需要運行的計算機上的能力。
可靠性：軟件正確無誤地滿足需求的能力。
效率：軟件最小是用計算機資源（如內存、外存和機器時鐘周期等）的能力。
人性化工程：軟件能夠容易地被人們理解和學習的能力。
易測性：為了測試軟件的可執行性能的測試能力。
可理解性：軟件能夠被軟件維護人員閱讀并理解的方便程度。
可修改性：軟件能夠被軟件維護人員修改的方便程度。
以上例出的屬性并沒有一個特定的先后順序，就像質量本身一樣，對這些屬性沒有絕對的層次關系。不是所有這些屬性在任何軟件工程項目里都有用。此外，用于實現這些屬性的技術可能導致確實的、消極的相互沖突。因此，質量屬性的優先此序列表必須在程序開發生命期之前定義，以彌補程序目標的不足和在各屬性之間保留一定距離。
質量法則
有一條規律可以決定軟件開發過程是如何引入軟件質量因素的，那就是質量法則。軟件開發團體已經認識到這個問題，并認為這有助于對生產軟件過程的風險測試。在軟件質量書籍《軟件開發和支持成功框架》中，Curran和Sanders指出，軟件質量過程要注意四點：
* 從一開始就要保證不出錯，至少應該努力是錯誤盡量不在代碼是發生。為了做到這一點包括采用適當的軟件工程標準和過程，建立獨立的質量保證將來標準和過程；根據過去的經驗和教訓制訂正式的方法；象軟件工具和合同軟件一樣的高質量輸入。
* 確保盡早發現錯誤并糾正，錯誤隱蔽得越久，修正錯誤花得代價就越大。因此，質量控制必須在開發生命周期重的每一個階段都要重視，如需求分析、設計、文檔和代碼。這些都隸屬于所有的回顧方法，如檢查、預排和技術回顧。
* 消除引起錯誤的引導因素，還沒有找到錯誤的誘因就糾正錯誤是不巧黨的。通過排除錯誤的誘因你就達到了改良過程的目的（回憶連續改良過程是全面質量管理TQC原則中用于軟件質量的另一個關鍵原則）。
* 運用獨立的按照標準和過程來的質量審核工作方式，通常有兩種方法用于檢查項目活動是否按照預定的標準和過程進行的，即SEI和SPR。
質量因素和風險
我們已經討論了質量，接下來的問題就是軟件質量，或程序的質量，在軟件開發項目中要討論的風險因素。在《軟件風險的評估和控制》一書中，Jones描述了他在軟件開發中的評估經驗。運用軟件生產力研究(SPR，Software Productivity Research)和軟件工程技術（SEI，Software Engineering Institute）方法來回顧幾百個企業的項目，這些項目產生的軟件可以分為六類：
* 管理信息系統：財務和管理系統；
* 象操作系統、通訊軟件或其他物理設備控制軟件等系統軟件；
* 商務開發項目，如給最終用戶出租/出售產品等；
* 軍事軟件項目；
* 合同/采購軟件項目（民間），一些零散的用于職員和雇主的客戶端軟件；
* 最終用戶軟件項目，即一些給特定的用戶開發的軟件。
這些程序中有超過100多個的風險因素。少數項目有超過15個風險因素，但大多數是6個因素影響。分析這些項目中的風險模式，結論是它們不都是所有軟件中的共同因素。這兒列出了幾個在樣本程序中出現最多的風險因素。
MIS：
* 緩慢的用戶需求分析（80%）
* 過大的時間進度壓力（65%）
* 低質量（60%）
* 嚴重超成本（55%）
* 不充分的配置控制（50%）
低質量的軟件被定義為根本不工作，或是重復出現操作失敗的現象。Jones定義低質量的軟件是，用戶報告中每日歷年、每個功能點出現超過0.5個錯誤。MIS系統低質量表現在兩個方面：(1)不確定的錯誤出現，如偶然或非專業的使用檢查或運行測試時出現錯誤；（2）不充分的錯誤預防，如使用象聯合應用設計（JAD）或信息工程(IE)的標準技術失敗，一些錯誤可以產生項目的說明。
系統軟件風險：
* 長期的計劃（70%）
* 不充分的成本估計（65%）
* 過多的文檔工作（60%）
* 錯誤的模塊（50%）
* 項目取消（35%）
過多的文檔工作并沒有嚴格的規律，但是可以從以下幾點來判斷是否是“過多”：（1）超過50種分散類型的文檔；（2）文檔費用接近或超過了整個項目費用的50%；（3）每個功能點有超過2000詞的描述。系統軟件的文檔在數量級上僅次于軍事軟件，太多的文檔對工作來講是多余的。(注意，過多的文檔會引起額外的問題，目前，還沒有出版相關的作品說明怎樣數量、卷、結構或什么樣的文檔風格對于軟件項目來講是合適的。)
商業軟件風險
* 不充分的用戶文檔（70%）
* 低用戶滿意度（55%）
* 太多的市場營銷時間（50%）
* 有害的競爭活動（45%）
* 訴訟費用（40%）
不充分的用戶文檔定義為不完整的、不清楚的、錯誤的或理解有困難的用戶信息。用戶信息包括在線幫助和出版材料，這在商業軟件世界里是廣泛存在的問題。這個問題可以有一下因素來描述：
技術描述缺乏相當的技巧
* 用戶文檔不充分：
n 新的軟件包發布的文檔每次都很困難；
n 一些廠商不愿使用有能力的作者；
n 用戶文檔的陳述還是很原始的方法；
低的用戶滿意度意味著用戶對以下一點或多個因素不滿意（在1993年，一半多商業軟件存在這些問題）：
* 低質量；
* 不完整的功能；
* 復雜的不可思議的命令結構；
* 很難學習；
* 麻煩的安裝過程；
* 用戶服務和支持力量不足；
* 過多的占用磁盤空間或其他硬件資源；
軍用軟件
據用軟件有相當嚴格的項目連續性，同時也有其相應的代價高昂的問題和風險。
* 過多的文檔（90%）
* 低產率（85%）
* 長周期（75%）
* 緩慢的用戶需求（70%）
* 不用或不能用的軟件（45%）
合同/采購軟件項目風險
* 高維護費用（60%）
* 委托人和承包人間的摩擦（50%）
* 緩慢的用戶需求（45%）
* 不可預料的認可標準（30%）
* 交付的軟件法律所有權（20%）
維護費用是指每年一次的修復錯誤或按照顯著高于U.S標準的項目維護費用，一個人能夠維護的目前軟件總數顯著的低于U.S標準。
不可預料的標準認可定義為有時存在項目委托人和承包人之間的對于產品交付條件、付款、超出最初的合同或協議的條件方面的問題。例如一個典型的問題就是過高的質量要求、對軟件性能目標的過高要求，或者軟件的特殊需要或文檔。這種情況最終會使認可失敗，或導致用戶感到工作不滿意。這會對項目造成傷害，影響客戶關系，極端的情況會引起法律訴訟。
最終用戶軟件風險
* 不可轉讓的應用（80%）
* 隱藏的錯誤（65%）
* 不可維護的軟件（60%）
* 多余的應用（50%）
* 交付的物品和軟件的法律關系（版權）（20%）
應藏錯誤定義為隱藏在最終用戶系統中不為開發者或任何其他人知道的邏輯或程序錯誤。在沒有最后回顧、檢查、測試、審核和質量分析活動的情況下更容易出現。
不可維護的軟件。一旦軟件開發者離開了公司之后，誰來維護軟件呢？一些應用軟件機構化很差、注釋不全，以至于一旦開發者離開了公司，就沒有誰能夠維護該軟件了。
Boehmis的六步風險管理
正如Jones所說，質量保證活動直接影響到軟件開發過程的風險。目前的軟件風險管理已經從概念、實踐和規則方面同其他工程或管理領域對應起來。軟件風險管理的目標用于標識、定位和消除各種風險因素，在其來臨之前阻止其發生，以使項目成功操作或使軟件重寫的機率降低。這種征兆是在一定條件下發生的。如果操作者不注意，這些風險可能就會趁你不注意發生。決策樹結構顯示了復合風險是由每個決策項構成的，復合風險是各部分風險的綜合。這種決策樹提供了一種量化的用于描述不同的選項影響程度的方法，就像決定各個風險因素部分的決策參數。這種分析方法在風險發生概率和沒有精確的分析方法時很有用。
Boehm歸納了六步風險管理法則，其中有兩步關鍵法則，每個法則有三個子步驟。Boehm建議采用適當的技術來實現每個關鍵步驟和子步驟。第一步是評估，包括：
* 風險確認，確認詳細的影響軟件成功的項目風險因素；
* 風險分析，檢查每個風險因素的發生概率和降低其發生的概率的可能性；
* 給確認和分析的風險因素確定級別，即風險考慮的先后順序；
一旦項目風險因素的先后順序排列出來了，第二步就是風險管理。這一步中，要對這些風險因素進行控制，包括：
* 風險管理計劃，制定每個風險因素如何定位，這些風險因素的管理如何與整個項目計劃融為一體；
* 在每個實現活動或工作中的風險解決方案，消除或解決風險因素的特殊活動；
* 風險監視，跟蹤解決風險活動的風險過程的趨勢；
質量因素的風險管理應用
正如我在本文的“質量因素和風險”一節中提到的，幾種方式的軟件開發直接或間接地受到相關的軟件質量問題影響，在本節中，我們要討論幾種可以幫助我們控制、減輕或防止風險發生的技巧。（Jones）
因素：緩慢的用戶需求
減輕風險的技巧：
* 使用原型；
* 在MIS系統中利用JADS技術分析需求；
* 使用信息工程（IE）技術創建需求——主要使用在MIS系統中；
* 運用功能規格方法監視需求的進展，一旦在需求階段確定了規格，研究就是和需求收集過程結合起來了�，F在創建需求功能列表的自動工具技術是可行的了。這些工具的先進之處在于：嚴格而快速地收集需求，不僅可以填寫功能點計算和成本預算，也能夠把這些數據增加到CASE工具、數據模型和設計工具中。
* 新技術——基于功能點的分解和每個功能點的成本估算。這將迫使用戶承認緩慢的用戶需求將會導致財政（成本）的增加。
因素：低質量和錯誤傾向的模塊
減輕風險的技巧：按照進度計劃進行的質量控制和成本控制。已經證明影響軟件質量控制的四中技巧是：
質量評估和可靠的評估工具。質量/評估工具是一個新的市場（在1993年只有6種這樣的工具），在所有的軟件開發項目經理的人員中使用的不足10%。
過失預防方法。過失預防方法包括所有減少市場誤差或錯誤的技術，包括：（a）所有結構化分析和設計技術；（b）原型；(c)高級的面向對象語言；（d）在過程語言中嚴格地使用結構化語言；（e）開展質量功能開發(QFD)；（f）開展全面質量管理（TQC）；(g)開展軟件質量分析(SQA)；(h)清潔的空間發展方法（譯者：？）。
過失消除方法。過失消除方法包括設計回顧、結構化預演（原型）、正規的代碼檢驗、正確性校驗和所有的測試步驟。正規回顧和驗證已經被被有效地運用于消除過失，幾乎被所有美國的質量管理領導采用了。測試工作最好經過正規的專家培訓后采用。
質量管理程序。Jones指出在美國的軟件質量控制領導人（如Bladrige獲勝者）已經具有完整的質量管理程序。其中之一就是在軟件質量領域的功能方法學的擴展。過時的代碼方法很不明確、很荒謬，以至于在管理需求分析、設計和文檔方面有很多錯誤，在質量主體方面也沒有很多重要的文獻資料。功能點方法是在1991年被美國國家質量部門和軍事系統、MIS項目等采用的。1993年，功能點方法也用于控制或預測軟件項目的測試用例或測試運行。
