軟件開發質量和風險的定量監理

軟件開發質量和風險的定量監理 

作者：中國軟件評測中心 陳兵
發表：2003.12.31 
來源：中國計算機用戶

軟件質量是指與軟件產品滿足規定和隱含的需求的能力和有關的特征的全體，即所有描述計算機軟件優秀程度的特性的組合。 

　　應用軟件的質量依賴于問題需求的描述、解決方案的建模設計、可執行程序的編碼的產生以及為發現錯誤而運行軟件的測試。一個優秀的監理工程師應該能夠使用定量的方法來評估軟件開發過程中產生的分析及設計模型、源代碼和測試用例(use case)的質量。 

　　軟件開發質量的定量監理 

　　為了實現這種實時的質量評估，監理工程師們必須采用技術度量來客觀地評估質量，而不能僅僅采用主觀的方法進行評估。 

　　在評估中，首先要明確的一點是，軟件需求是度量軟件質量的基礎。不符合需求的軟件就不具備質量。 

　　而在定量監理實踐中，通常需要使用一種被稱為尺度度量的方法，這種定量度量適用于一些能夠直接度量的特性，比如，出錯率定義為錯誤數／KLOC／單位時間等。 

　　因而，對質量控制所應該建立的一些定量數據是： 

　?。?）明確性(無二義性)、完全性、正確性、可理解性、可驗證性、內部和外部一致性、可完成性、簡潔性、可追蹤性、可修改性、精確性和可復用性的數據。這些數據可以用來評價分析模型和相應的需求規約質量的特征。 

　　公開的可能缺陷數與報告總缺陷數的對比則可以用來評價測試精確度和測試覆蓋度，同時也可以預測項目發布時間。 

　?。?）產品發布前清除的缺陷數在總缺陷數中所占的百分比，有助于評估產品的質量。 

　?。?）按嚴重缺陷、子系統缺陷來劃分，分類統計出平均修復時間，這樣將有助于規劃糾正缺陷的工作。 

　?。?）利用測試的統計數據，估算可維護性、可靠性、可用性和原有故障總數等數據。這些數據將有助于評估應用軟件的穩定程度和可能產生的失敗。 

　　在上述定量數據的基礎上，就可以開始進行估算。 

　　1、基本的定量估算 

　　基本定量估算示例： 

　　設 F為用功能點描述的軟件規模； 

　　D1為在開發過程（提交之前）中發現的所有缺陷數； 

　　D2為提交后發現的缺陷數； 

　　D為發現的總缺陷數。 

　　因此，　D=D1+D2 

　　對于一個應用軟件項目，則有如下計算方程式（可以從不同的角度估算軟件的質量）： 

　　質量=D2/F； 

　　缺陷注入率=D/F； 

　　整體缺陷清除率=D1/D； 

　　同樣以上期中的CAD軟件為例，根據上期計算所得結果，功能點F為366，而在開發過程中發現了15個錯誤，提交后又發現了4個錯誤，則： 

　　D1=15，D2=4 

　　D=D1 +D2=15+4=19 

　　質量(每功能點的缺陷數)=D2/F=4/366=0.0109 

　　缺陷注入率=D/F=19/366=0.05191 

　　整體缺陷清除率=D1/D=15/19=0.7895 

　　有資料報告，美國的平均整體缺陷清除率目前只達到大約85%。而像AT&T、IBM、摩托羅拉和惠普這樣一些大公司的頂級項目，通過實施最佳實踐，其缺陷清除率可以超過99%。 

　　眾所周知，清除軟件缺陷的難易程度是不同的。需求錯誤、規格說明、設計問題及錯誤修改是最難清除的。表1給出了美國平均缺陷的情況： 

　　 

　　表2反映的是CMM五個等級是如何影響軟件質量的，其數據來源于美國空軍1994年委托SPR（美國一家著名的調查公司）進行的一項研究。 

　　

　　從表中可以看出，CMM級別越高，缺陷清除率也越高。 

　　在監理過程中，可以將這這些標準或指標結合起來使用，用以辨明可能存在的質量問題。 

　　2、對軟件需求的估算 

　　假設在一個規約中有nr個需求，所以 

　　nr=nf+nnf 

　　其中，nf是功能需求的數目，nnf是非功能需求數目(例如性能)。 

　　為了確定需求的確定性(無二義性)，一種基于復審者對每個需求解釋的一致性的度量方法為： 

　　Q1＝nui/nr 

　　其中，Q1表示需求的確定性，nui是所有復審者都有相同解釋的需求數目。當需求的模糊性越低時，Q1的值越接近1。 

　　在CAD軟件的例子中，假設計算機圖形顯示功能模塊的功能性需求是10個，非功能性需求（響應速度和分辨率）是2個，所有復審者都有相同解釋的需求數目是11個，則： 

　　Q1=11/12=0.916667 

　　而功能需求的完整性Q2則可以通過計算以下比率獲得： 

　　Q2＝nu/(ni×ns) 

　　其中，nu是唯一功能需求的數目，ni是由規約定義或包含的輸入(刺激)的個數，ns是被表示的狀態的個數。 

　　Q2只是測度了一個系統所表示的必需的功能百分比，但是它并沒有考慮非功能需求。為了把這些非功能需求結合到整體度量中以求完整，必須考慮已有需求已經被確認的程度。這可以用Q3來表示： 

　　Q3＝nc/(nc＋nnv) 

　　其中，nc是已經確認為正確的需求的個數，nnv是尚未被確認的需求的個數。 

　　在CAD軟件的例子中，假設數據庫管理功能模塊的唯一功能需求是10個，由規約定義或包含的輸入個數也是10個，表示的狀態的個數是1個，已經被確認的需求是8個，未被確認的需求是2個，則： 

　　Q2＝10/（10×1）=1.0 

　　Q3＝8 /（8+2）=0.8 

　　3、估算驗收測試階段預期發現的缺陷數 

　?。?）如果使用類似項目的數據，那么可以估計當前項目在驗收測試時發現缺陷數，它等于在類似項目的驗收測試階段發現的缺陷數和這個項目估計的工作量與類似的總工作量比率的乘積。用如下公式表示: 

　　驗收測試缺陷的估計=驗收測試缺陷數×工作量估計/實際工作量 

　　在CAD軟件的例子中，若以前有一個相似的圖形處理軟件，在驗收測試的時候發現了12個缺陷，本項目估算的工作量是66人/月，實際的工作量是82人/月，則CAD軟件項目在驗收測試時可能出現的缺陷是： 

　　驗收測試缺陷的估計=12×66/82=10 

　?。?）使用過程能力基線中的數據，那么可以使用幾種方法來計算這個值: 

　　a、估算每功能單元的缺陷數，那么功能點規模按前面討論的方式進行估計，預期的缺陷數是質量數據和估計規模的乘積。 

　　b、估算過程缺陷清除率。在這種情形下，在驗收測試階段預期存在的缺陷數可以由缺陷注入率、過程中的清除率目標以及估計的規模一起來決定。 

　　4、針對維護活動設計的度量 

　　IEEE Std.982.1-1988[IEE94]建議了一個軟件成熟度指標(SMI)，它提供了對軟件產品的穩定性的指示(基于為每一個產品的發布而做的變動)，以下信息可以確定： 

　　MT=當前發布中的模塊數； 

　　Fc=當前發布中已經變動的模塊數； 

　　Fa=當前發布中已經增加的模塊數； 

　　Fd=當前發布中已刪除的前一發布中的模塊數； 

　　那么，軟件成熟度指標可以用下面的公式來計算： 

　　SMI=[MT-(Fa+Fc+Fd)]/MT 

　　當SMI接近1.0的時候，產品開始穩定。SMI也可以用作計劃軟件維護活動的度量。產生一個軟件產品的發布的平均時間可以和SMI關聯起來，并且也可以開發一個維護工作量的經驗模型。 

　　在CAD軟件的例子中，若目前的軟件是2.0版，當前發布的模塊數是32個，當前發布中已經變動的模塊數是8個，當前發布中已經增加的模塊數是2個，當前發布中已刪除的前一發布中的模塊數是1個，則： 

　　SMI=（32－8－2－1）/32=0.656， 

　　從結果可以看出，目前的情況離產品穩定還有相當的距離。 

　　5、軟件可用性的計算 

　　軟件可用性是指在某個給定時間點上程序能夠按照需求執行的概率。其定義為： 

　　可用性=MTTF/（MTTF+MTTR）×100％ 

　　其中，MTTF是“平均失敗時間”，MTTR是“平均修復時間”。 

　　在CAD軟件的例子中，若軟件在6個月內失敗一次，每次恢復平均需要20分鐘（恢復時間為排除故障或系統重新啟動所用的時間），那么，它的可用性是： 

　　6個月/（6個月+20分鐘）X100=99.92% 

　　通常，提高系統的可用性基本上有兩種方法：即增加MTTF或減少MTTR。而增加MTTF還要求增加系統的可靠性。 

　　6、利用植入故障法估算程序中原有故障總數ET 

　　通?？梢圆捎貌东@－再捕獲抽樣法來估算程序中原有故障總數。 

　　設Ns是在測試前人為地向程序中植入的故障數(稱播種故障)，ns 是經過一段時間測試后發現的播種故障的數目，n是在測試中又發現的程序原有故障數。 

　　假設測試用例發現植入故障和原有故障的能力相同，則程序中原有故障總數 N(=ET) 估算值為： 

　　例如，在CAD軟件的測試過程中，人為播入的故障數是5個，經過一段時間的測試后發現的播種故障數是4個，在測試中又發現原有的故障數是2個，則程序中原有的故障數是： 

　　 

　　N=（5/4）× 2=15個 

　　軟件開發風險的定量監理 

　　很多應用軟件項目之所以陷入混亂狀態而使項目組人員經常感到疲于奔命，就是因為對風險管理的不重視。在監理過程中也常常如此，很多情況下都是問題發生時才意識到問題的存在。而資源和項目周期的壓力，使得項目的相關方不得不在沒有很充分準備的情況下倉促應戰，而在這種情況下產生的結果往往是不理想的。 

　　軟件風險監理就是在風險成為影響軟件項目成功的威脅之前，識別、著手處理并消除風險的源頭。 

　　風險關注未來將要發生的事情。那么，什么樣的風險會導致軟件項目徹底失敗呢？改變也是我們所關心的—用戶需求、開發技術、目標計算機以及所有其他與項目相關的因素的改變，將會對按時交付和總體成功產生什么影響呢？最后，我們必須抓住選擇機會—我們應該采用什么方法和工具？需要多少人員來參與工作？對質量的要求要達到什么程度才是“足夠的”？……諸如此類的問題還有很多，這些問題是風險監理最關鍵的部分。 

　　對風險進行定量監理的第一步，就是要識別那些可能將風險帶到項目計劃中的因素，也就是對風險進行分類。 

　　1、項目風險威脅到項目計劃。也就是說，如果項目風險變成現實，有可能會拖延項目的進度，且增加項目的成本。 

　　項目風險是指潛在的預算、進度、人力(工作人員及組織)、資源、客戶、及需求等方面的問題以及它們對軟件項目的影響。項目復雜性、規模以及結構不確定性也被定義為項目風險因素。 

　　2、技術風險威脅到要開發軟件的質量及交付時間。如果技術風險變成現實，則開發工作可能變得很困難或根本不可能。 

　　技術風險是指潛在的設計、實現、接口、驗證、和維護等方面的問題。此外，規約的二義性、技術的不確定性、陳舊的技術及“先進的”技術也是風險因素。 

　　3、組織風險。常見的組織風險是組織內部對目標未達成一致、高層對項目不重視、資金不足或與其他項目有資源沖突等都是潛在的組織風險。 

　　4、外部風險。比如法律法規變化、項目相關接口方的情況發生變化，這些事件往往是不可控制的。但要注意的是，一般將不可控制的“不可抗力”不作為風險，而是將它們當作災難進行防御。 

　　風險預測，又稱為風險估算，試圖從兩個方面評估每一個風險—風險發生的可能性或概率，以及如果風險發生后所產生的后果。 

　　項目計劃者以及其他管理人員和技術人員需要一起執行四個風險預測活動：（1）建立一個尺度，以反映風險發生的可能性；（2）描述風險的后果；（3）估算風險對項目及產品的影響；（4）標注風險預測的整體精確度，以免產生誤解。 

　　風險表可以給項目管理者、監督者提供一種簡單的風險預測技術。風險表的樣本如表3所示。 

　　在這里，PS指產品/項目規模風險，BU指商業風險，CU是指客戶特性風險，TE是指建造技術風險，DE是指開發環境風險，ST是指人員經驗與經驗風險，……像這樣風險可以有許多，在這里就不一一舉例了。 

　　項目組一開始要在表中的第一列列出所有風險(不管多么細微)。每一個風險在第二列上加以分類。每個風險發生的概率則輸入到第三列中。每個風險的概率值可以由項目組成員個別估算，然后將這些單個值求平均，得到一個有代表性的概率值。 

　　下一步是評估每個風險所產生的影響。使用表3所述的特性評估每個風險因素，并確定其影響的類別。對四個風險因素--性能、支持、成本及進度的影響類別求平均可得到一個整體的影響值(如果其中一個風險因素對項目特別重要，也可以使用加權求平均值)。 

　　 

　　在表三中，影響類別取值如下： 

　　1-災難的，2-嚴重的，3-輕微的，4-可忽略的 

　　完成了風險表的前四列內容之后，就要根據概率及影響來進行排序。高發生概率、高影響的風險放在表的上方，而低概率風險則移到表的下方。這樣就完成了第一次風險排序。 

　　項目監理者研究已排序的表，并定義一條中止線。該中止線(表中某一點上的一條水平線)表示：只有那些在線之上的風險才會得到進一步的關注。而在線之下的風險則需要再評估以完成第二次排序。排序后找出需要關注的風險點，進行處理?？梢砸来晤愅仆瓿傻谌闻判蚧蚋嗟呐判?。 

　　從監理的角度來考慮，風險影響及概率是起著不同的作用的。一個具有高影響但發生概率很低的風險因素不應該花費太多的監理時間和精力。而高影響且發生概率為中到高的風險、以及低影響且高概率的風險，應該首先列入重點監理考慮之中。

原文轉自：http://www.kjueaiud.com