本文章是由機器翻譯。
測試運行
使用 PERIL 分析專案危害和風險
James McCaffrey 博士
目錄
元風險
風險識別
風險分析
總結
所有的軟體專案都會面臨風險。風險是可導致某種損失的事件，其發生具有不確定性。風險與軟體測試之間的關係非常簡單。您通常無法全面地測試某個軟體系統，而風險分析可找出那些能導致最大損失的問題。您可以借助此資訊劃分測試工作的優先次序。在本月專欄中，我介紹了一些可用於找出和分析軟體專案風險的實用技術。現在請隨我來。
假定您正在開發某種基於 ASP.NET Web 的應用程式。圖 1 顯示了一些與軟體風險分析有關的重要概念和問題。風險分析的整個過程包括找出風險、估計發生每種風險的可能性、確定與每種風險相關的損失，將可能性與損失資訊組合為一個稱為風險危害的值。
根據圖 1 中的示例資料，風險“User IDs can be viewed”（可查看使用者 ID）的風險危害最高，其餘因素平齊，您很可能希望使其具有最高的測試優先順序以防止實際發生該風險。但是如何找出風險呢？如何估計出現風險的可能性和損失呢？如果無法估計出發生風險的可能性和損失還可以進行風險分析嗎？
儘管為正式化和標準化風險分析術語已做過很多努力，但在實際中不同的術語仍趨向于在不同的問題領域中使用。我將使用術語“風險分析”來表示將風險可能性乘以風險損失以計算風險危害，或表示找出、分析和管理軟體專案風險的整個過程。
雖然風險分析在軟體發展中極為重要，但據我所知，很多風險分析技術在軟體測試社區中並非人人皆知。如果搜索 Web，您會發現成千上萬個有關軟體風險分析的參考。但這些參考的絕大多數只是側重高層次的風險分析而不提供實用技術，或者僅提供某個特定的風險分析技術且不解釋該技術如何應用到整個風險分析框架中。我將向您介紹風險分析的概述以及一些可立即在軟體發展環境中使用的實用技術。
在本專欄章節中，我將介紹兩種所有軟體專案中都很常見的元風險。然後向您介紹三種找出軟體專案相關特定風險的方法和三種分析風險的方法。我還將向您特別介紹一種有趣的新風險分析技術，名為“使用分級影響和可能性的專案風險危害 (Project Exposure using Ranked Impact and Likelihood, PERIL)”，該技術在軟體發展環境中尤為有用。最後將對風險管理進行簡要的總結。我相信這裡提供的技術對軟體測試、開發和管理工具包都極具價值。
元風險
我將兩種特殊類型的軟體專案風險分析稱之為時間和成本元風險分析。傳統專案管理所定義的概念有不同的名稱，分別是“專案管理三重制約”和“專案管理三要素”。簡言之，就是每個專案實際上都具有三個約束因素：成本、進度和範圍。成本是專案必須的花費，進度是完成專案所必需的時間，而範圍是必需的專案功能及其品質。
這三個專案約束有很多其他別名。例如，成本也被稱為預算或資金。進度通常稱為時間或持續時間。範圍有時稱為功能或品質，或者“功能/品質”。請注意，實際上通常可將這個“功能/品質”約束認為兩種不同的約束。
這些約束中的任何一個發生變化都很可能引起其他的一個或兩個約束髮生變化，這是它的重要特徵。例如，如果您正在開發某個軟體應用程式，但突然需要提前完成該專案，您可能需要增加資金投入（例如購買額外的資源或外包部分專案）或削減某些功能或品質。如果削減專案預算，很可能需要更長時間完成專案，刪除某些功能或降低專案的品質。使用專案管理三要素模式，由於軟體測試旨在改進系統的品質，所以軟體專案中兩個最高級別的風險是未按時完成專案和專案超出預算。
有個相對簡單但行之有效的方法可以估計軟體專案的整體進度和成本風險。我們來看一下時間/進度元風險（以相同方式對預算/成本風險進行分析）。高層元風險分析的第一個步驟是將整體專案分解為更易管理的小活動塊。
例如，假設您正在處理某個小型的 Web 應用程式專案，而該專案必須在 30 個工作日內完成。元風險分析的第一步是列出該專案中的所有活動。這裡最常見的辦法是創建一個工作分解結構 (WBS)，如圖 2 所示。創建一個包含整個專案的頂層任務。然後將該任務分解為多個更小的子任務，通常約三到七個任務。重複該過程，將每個子任務分解為更小的子任務，直至達到環境所需的精細度。
圖 2 工作分解結構
最下層的葉節點任務有時被稱作工作包。任務的分解方式和 WBS 的細化程度取決於很多因素。例如，在較為靈活的開發環境中，可能簡單的雙層工作分解結構即能滿足您的需求。如果您使用傳統的軟體發展生命週期方法分解某個極為龐大的複雜軟體專案，您可能會有成千上萬個工作包。
您可以使用常用的高效工具（如 Microsoft Office Excel）或使用較為複雜的工具（如 Microsoft Office Project）手動創建一個較小的 WBS。WBS 不包含排序、時間或成本資訊。換言之，WBS 可告知您必須完成什麼任務，但不會透露它們的順序，也不會告知每個任務所花費的時間或成本。通常，創建完工作分解結構後，接下來要使用工作包創建一個先後次序圖表。
.gif)
圖 3 先後次序圖表
先後次序圖表可添加排序資訊。圖 3 所示的圖表指明“Requirements”（要求）任務必須先于“Database Back End”（資料庫後端）任務完成，而“Database Back End”（資料庫後端）任務必須在“Middle-Tier”（中間層）任務和“Front-End”（前端）任務開始前結束。依照該先後次序圖，後兩個任務可並存執行。最後，“Middle-Tier”（中間層）任務和“Front-End”（前端）任務必須在“Deploy Application”（部署應用程式）任務開始前結束。
創建含有其排序資訊的先後次序圖表後，時間元風險分析接下來會估計各個工作包所需的時間。儘管您可以將每個時間視為單個資料點估計，但更好的方法是提供三種估計值—樂觀估計值、最佳猜測值和悲觀估計值。
那麼，如何取得這些估計值呢？迄今為止，確定時間和成本估計值是軟體專案元風險分析中最困難的部分。估計活動時間和成本有多種方法。您可以使用歷史經驗、有根據的猜測以及複雜的數學模型等。具體使用哪種技術視您的情形而定。無論使用何種方法，估計一組小活動的時間和成本要比估計一個龐大活動的時間和成本要輕鬆許多。圖 4 中的表格顯示了時間風險元分析示例。
在分析樂觀、最佳猜測和悲觀時間資料時，通常會使用一種稱為 Beta 分佈的簡單數學分佈。Beta 分佈的平均數計算方法如下：
(optimistic + (4 * best-guess) + pessimistic) / 6
因此，對於“Deploy Application”（部署應用程式）任務，其平均完成估計時間為：
mean = (3 + 4*8 + 13) / 6
= 48 / 6
= 8.0 days.
請注意，Beta 平均數是用權數 1、4 和 1 求得的加權均值。 因此，Beta 分佈的方差由此公式指定：
((pessimistic - optimistic)/6)²
所以，“Deploy Application”（部署應用程式）任務的方差為：
variance = ((13 - 3) / 6)²
= (10/6)²
= (1.6667)²
= 2.78 days²
該專案的整體標準差是活動方差之和的平方根。 因而在此示例中，方程式如下所示：
std. deviation = sqrt(5.44 + 1.78 + 2.25 + 2.78)
= sqrt(12.25)
= 3.50 days
請注意，該計算並不使用“Design and Code Logic Middle-Tier”（設計和代碼邏輯中間層）活動的資料。 由於“Logic Middle-Tier”（邏輯中間層）活動可與“Database Back-End”（資料庫後端）活動並存執行，而“Front-End”（前端）活動只有在這兩個並行活動結束後才能開始，因此較短的並行活動 (Logic Middle-Tier) 無法顯式計入完成該專案的總時間。
這種分析被稱為關鍵路徑法 (CPM)，它是一項標準專案管理技術。 計算出進度均值和方差資料後，就可以計算出完成整個專案花費 30 天以上時間的概率：
z = (30.00 - 28.83) / 3.50 = 0.33
p(0.33) = 0.6293
p(late) = 1.0000 - 0.6293 = 0.3707
首先計算所謂的 z 值，該值的計算方法是將計畫完成該專案的時間量（本示例為 30 天）減去估計完成時間（28.83 天），然後除總的任務標準差（3.5 天）。得到 z 值 (0.33)，然後在標準正態分佈表中查找相應的 p 值或使用 Excel NORMSDIST 函數 (0.6293)。最後，從 1.0000 中減去 p 值即可得到專案超出時間表的概率。
如果您僅關注能否超出預計時間而不關注能否提前完成，那麼您執行的只是一個單側分析。在此示例資料中，花費 30 天以上完成 Web 應用程式的概率為 0.3707，或近 40%——這個情況極具風險。對這一結果進行分析可以挖掘有説明的資訊。原先計畫的 26 天的開發進度過於接近該專案 30 天的完成限制，這樣一來可能沒有充足的機動時間來應對進度偏差。
顯然，在本示例中，您的元風險結果完全取決於輸入資料（時間估計值）的品質。如果輸入估計值不正確，任何統計學分析都無法得出有意義的結果。您可以使用上述技術來計算專案超出預算的元風險概率。在得出專案超出預算的元風險概率後，如果能估計出由於推遲導致的資金損失，那麼您就可以計算出元風險的風險危害。
有時您可能需要根據合同創建軟體系統，而合同中已明確規定了數目巨大的滯納金。例如，假設您的合同規定如發生延遲交付會有 10,000.00 美元的罰金。則您的元風險危害為 $10,000.00 * 0.3707 = 3,707 美元。有時，延遲交付的軟體專案成本是“非常非常昂貴”的，很難給出具體的估計值。
但請注意，即使沒有計算風險危害，您的時間元風險分析也會給出有用的資訊。請查看圖 4 中的資料，您會看到“Determine Requirements”（確定要求）任務的進度方差最大。因此，只需儘早增加資源即可減小任務方差，進而可降低超出進度的概率。
風險識別
時間和成本元風險可通過將任務反復分解為較小的子任務來逐步確定風險事件（儘管並不容易），但一般情況下，風險識別要複雜得多。在軟體發展和測試環境中，有三種主要風險識別方法：基於分類、基於方案和基於規範。
分類法就是一個分類清單。請看下麵的假設。您正計畫一次乘飛機旅行，使用了一個每次旅行前都會使用的標準提醒清單。其中包含諸如“我拿身份證了嗎？”和“是否檢查航班有無延誤？”之類的陳述和問題。
多年來，很多人和公司都已創建了軟體風險分類法。Barry Boehm 就創建了這樣的一個清單，他是軟體專案風險領域的先驅和知名研究人員。1989 年，Boehm 確定了十大軟體風險分類法並于 1995 年更新了該清單。以下列出了 1995 年的十大軟體專案風險分類法：
- 個人錯誤
- 進度、預算、流程
- 商用成品軟體、外部元件
- 要求失配
- 使用者介面失配
- 體系結構、性能、品質
- 要求變更
- 舊版軟體
- 外部執行的任務
- 應變電腦科學
您應清楚 Boehm 的十大風險清單不能直接確定風險。分類只不過是為您提供了思考軟體專案所含風險的起點。例如，第一個風險“個人錯誤”包括許多與人員有關且各不相同的可能風險。您的專案可能缺乏足夠的工程師來創建應用程式或系統。或起關鍵作用的工程師在專案中途離開。也可能是工程人員的技能無法達到專案的需求。其他在此就不一一列舉了。
除第十類風險“應變電腦科學”外，其他大多數您應當都很熟悉。它在某種程度上是一個全能類別，包括與事情相關的多個任務，如技術分析、成本效益分析和原型構建。
另一個常用軟體風險分類清單是由軟體工程學院 (SEI) 創建的。SEI 是美國聯邦政府資助的 36 個研究開發中心之一。這些研究中心是個怪異的混合體，由公款資助，卻出售產品和服務。SEI 軟體風險分類法創建于 1993 年，其中包含約 200 個問題。例如，問題 1 為“這些要求穩定嗎？如果不是的話會對系統（品質、功能、進度、集成、設計和測試）有何影響？”問題 16 為“如何確定演算法及設計（原型構建、建模、分析和類比）的可行性？”您可以從該文檔附錄中找到SEI 風險分類法。
在基於方案的軟體風險識別中，您可以將自己想像成多種角色，為這些角色創建方案並找出各個方案中可能出現的錯誤。還是以先前所述的飛機旅行為例，您可能想跟蹤旅行中的各個步驟。例如，“首先要駕車去機場。接著停好車。然後在機場櫃檯辦理登機手續。”此方案可能包含很多風險，包括由於道路施工或交通事故導致的晚點、無停車位、忘帶證件等。
在軟體專案環境中，基於方案的風險識別經常用到使用者、開發人員、測試人員、銷售人員、軟體架構師和專案經理這些角色。使用者方案可能是“首先要安裝應用程式。然後啟動該應用程式。”風險識別方案經常能直接映射為某個測試案例。
基於方案的風險識別中，角色不一定必須是人。也可以是軟體模組或子系統。例如，假設您有一些執行加密和解密任務的 C# 物件。您可以想像該物件就是角色並創建方案，如“首先要接受一些輸入並產生實體自身。接下來接受一些輸入並將其傳給我的加密方法。”與基於分類法的識別相比，對基於方案的軟體風險識別的研究要少很多。軟體專案的風險識別模式中的研究論文對該領域進行了很好的介紹，並提出了一個基於模式的有趣理論方法。
除上述兩種風險識別策略外，第三種方法是基於規範的策略。通過此方法可以仔細檢查產品或系統規範文檔中的每種功能和流程，並嘗試找出可能出現的錯誤。在飛機旅行這一示例中，您可以仔細檢查旅行代理商制訂的詳細行程。假設某個 Web 應用程式的規範文檔指出您計畫使用外部承包商來生成該應用程式的各種“説明”檔。外部專案依賴關係會新增很多風險。如果承包商無法按時交付怎麼辦？如果承包商的工作品質無法達到您的主觀標準怎麼辦？
實際中並不存在一個最佳風險識別策略，因為每種策略都各有優缺點。一開始識別軟體專案中的風險時，適合使用風險分類法。該方法讓人感覺略為呆板，因為您要一一檢查分類法中的每個問題或每項陳述。通過為不同的人員分配不同的分類法問題，分類法還可説明實現多人協同找出風險。缺點是該方法極為耗時。同時，分類法本質上是種通用的方法，它們無法找出軟體系統特有的風險，需要您通過其他途徑識別這類風險。
與基於分類法的風險識別相比，基於方案方法的優勢在於針對性較強，可促使您從具體之處著手。另一方面，基於方案的風險識別技巧性更強，很容易讓您為之著迷。基於規範的風險識別通常是針對性最強且最為特殊的方法。但它的結果品質取決於您的規範文檔。如能將這三種方法綜合起來使用，您就可以更準確地找出軟體風險。
風險分析
風險分析是將某個風險事件的概率（可能性）與該事件導致的資金損失（或負面影響）相結合的過程，它的結果用於與其他風險做對比並確定風險的優先順序。在本節中，我將介紹兩種較舊的風險分析方法（預期值技術和分類技術），以及一種名為 PERIL 的新方法。我們首先來瞭解預期值技術。
請看圖 5 中的示例。假設您已經找出了四個風險事件。我們分別稱它們為風險 A、風險 B、風險 C 和風險 D。然後將概率分配給各個風險事件。概率是一個介於 0.00（表示不可能發生）與 1.00（表示肯定發生）之間的數位，用於表示事件發生的可能性。接下來，將資金損失值分配給各風險事件，這是風險事件發生時您的損失。此時，只需將各風險事件相應的風險概率乘以該風險的損失即可得到風險危害。
使用此方法，風險危害只是預期值的一種形式。顯然，預期值方法存在一些主要問題。如何估計風險概率？如何估計風險損失？在某些情況下您可以根據良好的歷史資料或經驗進行估計，但創建軟體時這種情況通常比較少見。根據個人經驗，風險分析的預期值方法在軟體發展環境中通常並不適用。
因為在很多軟體發展環境中很難或幾乎不可能估計某個風險事件概率或其關聯損失，常用的對策是對風險概率和風險損失使用類別尺度。這就是分類技術。示例可以更好說明這一點。假設您已找出四個風險 A、B、C 和 D。利用此方法無需猜測每個風險的概率和損失，您可以生成一個分類風險危害表，如圖 6 頂部所示。
如您所見，我總共有九種風險危害。有三種風險概率——低、中和高。有三種損失——也是低、中和高。概率分類和損失分類的叉積得到九種風險危害，從低-低（低概率、低損失）到高-高（高概率、高損失）。現在觀察四個風險事件，向每個事件分配一個低、中或高概率，然後再分配一個低、中或高損失，產生一個九點風險危害。它的思路是分配概率值“低”通常比分配某個準確的數值（如 0.5）更為合理。
圖 6 底部表格中的假想資料表明風險 B 的危害級別最高，與危害級別最低的風險 A 相比，需要更多關注或資源（包括測試）。儘管分類風險分析方法一定程度上緩解了難於或無法確定概率和損失的問題，但該技術也引發了一些新問題。
請注意，我對概率和損失都任意使用了三個分類。這種方法極為粗糙。假設為提高風險分析精度，我決定對概率因素和損失因素都使用五個分類：極低、低、中、高和極高。這樣我總共有 25 個風險危害分類——（極低 + 極低）到（極高 + 極高）。那麼，如何評定或比較這 25 個危害值呢？如何將（極低 + 高）風險危害與（高 + 中）危害進行比較呢？如果有很多人都在評估您的分類風險危害資料，他們會以相同方式理解危害資料嗎？
為了專門解決這類問題，我在多年前開發了一項名為“使用分級影響和可能性的專案風險危害 (PERIL)”的技術。其思路核心是使用分類（與在分類方法中相同），但將它們轉換為量化尺度，以便將它們輕鬆地組合起來生成數位危害度量值。
下麵來看一個示例。假設您已經找出了四個風險：A、B、C 和 D。現在假設您確定將有含義的數位分配給每個風險的概率和損失不可行。另外，您發現自己所在的具體環境適合將風險概率分為五類：極低、低、中、高和極高。接下來，您決定將損失/影響分為四類：極低、低、高和極高。PERIL 技術利用一個名為“排序次序重心法”(rank order centroid) 的簡單數學構造將分類資料映射成量化尺度。示例很好地解釋了映射技術。與五種概率尺度相對應的五個排序次序重心映射如圖 7 所示。
同樣，四類影響映射已計算完成，如圖 8 所示。現在將每個風險的概率和影響質心值相乘，計算該風險的危害值。例如，請參考圖 9。這裡風險 D 的概率級別為高，其映射值為 0.25667；影響級別為低，其映射值為 0.14583，因而其危害值為 0.25667 * 0.14583 = 0.03743。由此資料可推斷出風險 C 的危害值顯然最高，需要注意防範風險，並為出現風險創建應急計畫。
無需再分別計算每個風險的危害值，可構建一個完整的 PERIL 危害值查詢表格（包括五個概率級別和四個影響級別），然後只需從 PERIL 表中讀取危害值即可，如圖 10 所示。PERIL 技術可普及為任意數量的概率和影響類別。
排序次序重心將等級（如第一、第二和第三）映射為數值（如 0.61111、0.27778、0.11111）。請注意，排序次序重心之和趨向為 1.0（有取捨誤差）。在西格馬 (∑) 符號標記法中，如果 N 為類別數，則與第 k 個類別對應的數值為：
類別與數值之間有許多其他的數學映射，但有關研究表明使用排序次序重心法是映射級別（如在風險分析中所使用的示例）的一種很好的辦法。本專欄不詳細討論排序次序重心，但可做些非正式的講解。假設您只處理兩類風險事件概率：高和低。若假定高風險事件可能性的概率大於 0.5，則低風險事件可能性的概率就小於 0.5。無需其他資訊即可認為高風險事件的可能性介於 0.5 和 1.0 之間，因而等於 0.75。同樣地，低風險事件的可能性介於 0.0 和 0.5 之間，即 0.25。0.75 和 0.25 這兩個值就是 N = 2 個分類時的排序次序重心（如圖 11所示）。
請注意，在使用 PERIL 時，我使用的術語為可能性和影響，而不是概率和損失。PERIL 可能性和影響是相對的標準化值。即使 PERIL 可能性與概率集類似，值之和趨向為 1.0，需要強調的是 PERIL 可能性值並不是概率。同樣，PERIL 影響值僅在彼此相比較時才有意義，而非資金損失值。
這三項用於確定風險危害的技術——預期值技術、分類技術和 PERIL 技術各有其優缺點。如果每個風險事件都有足夠的歷史資料來估計其概率和相關的資金損失，則預期值技術通常是最佳選擇。但在軟體發展和測試環境中，很少能有足夠的資料供您做出有意義的概率和損失估計。
在另一種極端情況下，如果實際上沒有任何的歷史風險資料，則最適合有兩或三種風險概率類別和相關風險損失的分類技術。如果能將風險事件可能性和關聯的風險影響（可以是資金或非資金損失，如士氣影響）大致分類為五個類別，則 PERIL 技術通常是您的最佳選擇。
無論您決定在環境中採用哪種風險分析技術，都必須慎重地解釋您的結果。請牢記在輸入估計中，風險分析經常變數最大。換言之，風險分析僅僅是為軟體測試工作排定次序提供指導方針，而不是規則。
風險資源
有關風險的詳細資訊，請參閱以下《MSDN 雜誌》專欄：
| “測試運行：使用 MAGIQ 進行競爭分析” |
| “測試運行：層次分析法” |
總結
在本專欄中，我還未討論風險分析整體過程中的風險管理。風險管理涉及多項活動，例如建立輸入和存儲風險資料的系統，以及隨軟體專案監控風險資訊。風險管理系統有多種形式：從基於電子郵件的日常系統到基於 Excel 試算表的輕型方法，直至基於使用 Microsoft Team Foundation Server 系統中風險項的複雜方法。
無論您決定如何管理風險工作，都要瞭解風險分析是一個持續反復的過程，這一點很重要。由於軟體專案開發是個動態的活動，因此您必須隨專案的發展修訂風險資料和結果。
從常識來看，風險分析應成為所有軟體專案的重要組成部分。從只有一個開發人員，工作量很小的專案，到數百甚至數千名開發人員參與的大型常年專案，都應進行某些風險分析。但有相當數量的調查表明很多軟體並不進行風險分析，特別是一些中小型軟體專案。
原因可能有幾種。我猜測之所以很少執行風險分析的一個原因是因為它們需要技術和智力投入，而這些與編碼所需的技能和智力投入幾乎是截然不同的。我來做個解釋。大多數軟體發展活動是基於某個封閉系統相對明確定義的，它們面向宏觀目標，通常會提供即時回饋。例如，當您作為開發人員編寫代碼時，可以在編譯和執行代碼時獲得即時的回饋。如果代碼按預期效果運行，您通常就會得到某種程度的滿足。而執行軟體風險分析卻是項非常困難的活動。您不會得到任何類型的回饋，也不會得到過去曾有的成就感。
依我看來，軟體風險分析與編碼完全不同。希望本專欄能讓您瞭解到執行風險分析的重要意義，並為您提供了貨真價實的技術，能幫您創建品質更高且更可靠的軟體。
請將您想向 James 詢問的問題和提出的意見發送至testrun@microsoft.com。
Dr. James McCaffrey 供職于 Volt Information Sciences, Inc.，負責對華盛頓州雷蒙德市 Microsoft 總部園區內工作的軟體工程師的技術培訓進行管理。他參與過多項 Microsoft 產品的研發工作，其中包括 Internet Explorer 和 MSN Search，是<em></em>《.NET 軟體測試自動化之道：一個問題解決方案的方法》（Apress，2006）一書的作者。您可以通過電子郵件jmccaffrey@volt.com或v-jammc@microsoft.com與他聯繫。