前言

在基於CMMI軟體風險管理流程領域框架下，風險管理的第一步就是要進行風險識別從而確定風險來源和風險分類。風險來源和分類的目的一方面是提供一種收集和歸納風險的機制，以確保風險能夠引起管理者的關注。另一方面的不同的風險類別和來源所具備的風險概率、影響度、風險值等參數可能是不一樣。合理的定義風險來源和分類，可以全面、系統地識別潛在風險，合併類似規避風險的策略，有效達到風險管理的目的。

風險來源

風險的來源是多方面，對於軟體專案的風險比較常見的來源是不確定的需求、人員流動、使用新技術、不合理的進度、開發人員技能不足等方面的內容。只有識別清楚各個項目風險的主要影響因素，才能夠把握風險發展變化的規律，才能度量風險的可能性與影響大小，從而有效的對風險進行應對和控制。

風險識別的方法

風險識別的方法有很多種，任何有助於發現風險資訊的方法都可以作為風險識別的工具，常用的有以下幾種方式：

• 頭腦風暴法(Braining Storming)又稱集體思考法。


• 德爾菲法(Delphi method)又稱專家調查法，是基於問卷和檢查表對專家進行反復徵詢與整理，使得專家的意見趨於一致，最後作為風險識別的根據。


• 分類法(Taxonomy)又稱基於分類的問卷調查。是根據SEI提供的The Taxonomy-Based Questionnaire (TBQ)來進行風險識別。

以下我們重點針對基於分類的風險識別方法(TBQ)進行說明。

基於分類法的風險識別

1993年SEI發表了一篇《基於分類法的風險識別(Taxonomy-Based Risk Identification)》的技術報告，該分類法將軟體開發流程中的風險分為三個類(Class)，每個類又分解若干個因素(Element)，每個因素通過其屬性(Attribute)來體現特徵，分類法體系架構如下圖：



分類法將風險分為三大類及13個因素(包含164項屬性)：

一、產品工程類(Product Engineering)：指為了完成專案產品並提交給客戶所需要的各類技術活動，包含下列元素及屬性：

• 需求(Requirements)
  
  a.穩定性(Stability)
  b.完整性(Completeness)
  c.清晰性(Clarity)
  d.有效性(Validity)
  e.可行性(Feasibility)
  f.先例(Precedent)
  g.範圍(Scale)


• 設計(Design)
  
  a.功能性(Functionality)
  b.複雜性(Difficulty)
  c.介面(Interfaces)
  d.性能(Performance)
  e.可測性(Testability)
  f.硬體約束(Hardware Constraints)


• 編碼和單元測試(Code and Unit Test)
  
  a.可行性(Feasibility)
  b.測試(Testing)-主要指單元測試的充分性
  c.編碼/實現(Coding/Implementation)


• 集成和測試(Integration and Test)
  
  a.環境(Environment)
  b.產品(Product)-主要指產品集成和測試
  c.系統(System) -主要指系統集成和測試


• 專案的特殊要求(Engineering Specialties)，例如安全性和可靠性
  
  a.環境(Maintainability)
  b.可靠性(Reliability)
  c.系統安全性(Safety)
  d.保密性(Security)
  e.人為因素(Human Factors)

二、開發環境類(Development Environment)：指用於軟體開發的方法,流程和工具，包含下列元素及屬性：

• 開發流程(Development Process)
  
  a.規範性(Formality)
  b.適用性(Suitability)
  c.流程控制(Process Control)
  d.熟悉性(Familiarity)
  e.產品控制(Product Control)


• 開發系統(Development System)
  
  a.能力(Capacity)
  b.適應性(Suitability)
  c.可用性(Usability)
  d.熟悉性(Familiarity)
  e.可靠性(Reliability)
  f.系統支援(System Support)
  g.交付能力(Deliverability)


• 管理流程(Management Process)
  
  a.計畫(Planning)
  b.專案組織(Project Organization)
  c.管理經驗(Management Experience)
  d.程式介面(Program Interfaces)


• 管理方法(Management Methods)
  
  a.監控(Monitoring)
  b.人員管理(Personnel Management)
  c.品質保證(Quality Assurance)
  d.配置管理Configuration Management)


• 工作環境(Work Environment)
  
  a.品質態度(Quality Attitude)
  b.合作(Cooperation)
  c.溝通(Communication)
  d.士氣(Morale)

三、程式限制類(Program Constraint)：指再軟體發展過程中來自合約、,組織和運營方面的影響因素，同時這些因素一般不受本地管理控制，包含下列元素及屬性：

• 資源(Resources)
  
  a.進度(Schedule)
  b.人員(Staff)
  c.預算(Budget)
  d.設備(Facilities)


• 合約(Contract)
  
  a.合同類別(Type of Contract)
  b.限制(Restrictions)
  c.依賴(Dependencies)


• 程式介面(Program Interfaces)：例如對客戶的外部介面，供應商等。
  
  a.客戶(Customer)
  b.副合同(Associate Contractors)
  c.子合同(Subcontractors)
  d.主合同(Prime Contractor)
  e.高層管理(Corporate Management)
  f.供應商(Vendors)
  g.政策(Politics)

基於分類的問卷調查(Taxonomy-Based Questionnaire TBQ)

本問卷調查出自於SEI技術報告-《基於分類法的風險識別(Taxonomy-Based Risk Identification)》之附錄B “Taxonomy-Based Questionnaire”，是基於屬性級別的問卷調查,同時提供一些特殊的線索和後續的試探性問題來對風險進行識別，主要針對具體的軟體開發領域和專案組織，並可根據軟體專案的實際狀況進行裁減，例如，專案中沒有子承包商(Subcontractors),則子承包商相關的問題可被裁減。

本問卷調查共有194個問題，按照軟體開發分類學來組織問卷調查，通過對3大類下的13個因素中的164項風險屬性的提問來達到風險識別的目的。

下面舉例說明一段來自於SEI技術報告的問題摘錄：



上述例子來自於”產品工程類”之”需求”元素，是針對”穩定性”和”完整性”這兩個屬性之問卷調查，具體說明如下：

A Product Engineering產品工程類

Requirements需求

一、Stability穩定性

[Are requirements changing even as the product is being produced?]
[在產品實現過程中，是否有需求變更發生？]

• 1. Are the requirements stable?需求是否穩定？
  (No) (1.a) What is the effect on the system?
  (不) (1.a) 需求穩定性會在哪些方面對系統造成影響？
  　　Quality 品質
  　　Functionality 功能
  　　Schedule 進度
  　　Integration 集成
  　　Design 設計
  　　Testing 測試


• 2. Are the external interfaces changing?外部介面是否會發生變化？

二、Completeness完整性

[Are requirements missing or incompletely specified?]
[需求是否有遺漏或者表述不完整的地方?]

• 3. Are there any TBDs in the specifications?在需求規格說明書中是否存在待確認的內容?


• 4. Are there requirements you know should be in the specification but aren't?需求規格說明書中是否遺漏了一些需求？
  (Yes)(4.a) Will you be able to get these requirements into the system?
  (是) (4.a) 你能夠將這些需求納入系統嗎？


• 5. Does the customer have unwritten requirements/expectations?
  是否有些客戶的需求還沒有編製成文檔？
  (Yes) (5.a) Is there a way to capture these requirements?
  (是) (5.a) 是否存在一個獲取這些需求的途徑或方法？


• 6. Are the external interfaces completely defined?外部介面是否被完整定義？

參考資料

1.SEI "Capability Maturity ModelR Integration (CMMISM)， Version 1.2
2.CMU/SEI-93-TR-6” Taxonomy-Based Risk Identification
3.http://www.sei.cmu.edu/library/assets/risk.pdf
4.《專案管理知識體系指南》(PMBOK Guide)