作者：台灣應用軟件股份有限公司 譚泉清
近年來，業界中盛傳一則有關「政府將推動國內資訊軟體業者於三年內完成500家通過CMMI Level 2」的消息，激起一些討論與文章，但是這些文章中多是討論國內資訊軟體業該不該推動CMMI的文章，但業界卻鮮少見到有關如何建制或推動CMMI的文章，由於因緣際會台灣應用軟件過去四年持續和印度大廠的合作過程中，我們有許多的心得和體會。
此外，筆者參與許多CMMI建置之輔導專案，所以軟協向筆者邀稿寫些有關CMMI建置實務之經驗來與讀者分享，筆者欣然答應，雖然筆者不自量力，只因為想笨鳥先飛由筆者先拋磚引玉，寫些不登大雅之堂之淺見，期盼引起一些前輩或高手能真正將一些真功夫介紹與國人與同好。
ReqM在CMMI Level 2 中之定位
CMMI 之設計在Level 1至 Level 5每個成熟度等級中，均可區分為成熟度等級、流程領域、特定(一般)目標、特定(一般)執行方法等四個層面，以協助使用者暸解與建制及實施，每個成熟度等級其各層面之關係，如圖一。
圖一：成熟度等級中其各層面之關係
在向各位讀者簡單報告了成熟度等級中其各層面之關係後，我們將CMMI Level 2 之要求之七個流程領域(Process Area)分別列示於表一中，於是我們就能夠清楚的藉由表一來知道ReqM在CMMI中之定位在CMMI Level 2要求七個流程領域中，是排行在第一個流程領域PA。
CMMI Level 2 之要求之
七個流程領域(Process Area) |
用途
|
|
需求管理
(Requirements Management)
|
管理專案產品與產品組件之需求，並且界定專案計畫、工作產品與需求這兩者之間，是否有不一致的情形。
|
|
專案規劃
(Project Planning)
|
建立並維護定義專案活動的計畫。
|
|
專案監督與控制
(Project Monitoring and Control)
|
提供對專案進度的瞭解，使得當專案績效明顯偏離原先計劃時，能採取適當的矯正措施。
|
|
供應商合約管理
(Supplier Agreement Management)
|
管理和專案有正式協議的供應商之產品與服務的採購。
|
|
度量與分析
(Measurement and Analysis)
|
發展並維護支援管理資訊所需的度量能力。
|
|
流程與產品品保
(Process and Product Quality Assurance)
|
提供員工和管理階層，對於流程與相關工作產品客觀的觀察。
|
|
建構管理
(Configuration Management)
|
建立並維護藉由建構識別、建構管制、建構狀態記錄及建構稽核，使工作產品具完整性。
|
表一: CMMI Level 2 之要求之PA與其間之關係
CMMI之ReqM特定執行方法是什麼
在我們了解ReqM之定位後，接下來我們就要來談談CMMI對ReqM之要求為何，如圖二所示ReqM 標準有五個特定執行方法，瞭解需求、取得需求承諾、管理需求變更、維護需求的雙向追溯性、界定專案工作與需求間的差異，這五個特定執行方法之目的與活動，均是SEI的專家採集許多實務並加以彙整所訂定之方法，我略加整理後列示於表二供讀者參考。
圖二: CMMI之ReqM標準要求
|
特定執行方法
|
目的
|
活動
|
|
瞭解需求
|
需求提供者與接受者間對需求內容有共同的認知。
|
需求必須來自正確適當的對象
需求品質必須合乎要求
建立客觀的需求接受條件
檢驗分析需求以確保符合接受條件
與需求提供者共同完成充份清楚的需求，足使專案成員可以承諾需求。
|
|
取得需求承諾
|
獲得專案成員對達成需求之承諾
|
評估需求對既有承諾之影響
自設計、介面、時程、資源、風險等各角度評估
新需求產生時，專案成員(工程人員)必須參與評估
評估時應考慮需求間之資源競爭->需求排程
記錄對需求之承諾及評估結果
|
|
管理需求變更
|
在專案進行過程中管理對需求的變更
|
記錄專案過程中所有需求及需求變更
記錄需求資訊、需求原因、需求提出人、接受考量等相關資訊，作為需求追蹤與衝突解決時之參考依據。
維持需求變更之歷史記錄及變更原因。
由相關人員依其角度評估需求變更之影響
將需求及變更資料公告給全專案。
|
|
維護需求的雙向追溯性
|
在需求、產品及專案計畫間建立與維持雙向之追溯表。
|
維持向上之需求追溯性，確保對組件產品之需求來源均能被有效定義。
維持向下之需求追溯性，確保每一需求均被展開與配置到相關之功能、物件、人員及流程。
維持功能與功能及介面間之水平追溯性
產生需求追溯表
|
|
界定專案工作與需求間的差異
|
鑑定需求與專案計畫及既有產品間之不一致性
|
審查專案計畫、活動、與產品，評估與需求及需求變更項目間之一致性。
找出不一致處及其原因
鑑定由於需求基準點變更所造成之專案計畫、活動、與產品的變更需求
採取矯正改善行動，以因應變更
變更結果應通告專案相關人員
|
表二: ReqM中特定執行方法之目的與活動彙整表
建構CMMI應考量之觀念
依個人淺見說穿了建置CMMI的目的，不外是想要協助組織做好軟體組織的管理，SEI當時參照Crosby所提出之品質成熟度方格座標理論，轉換訂定出有關CMMI的五個Level，這五個層次從對於過程品質混沌無知或英雄主義之(initial)Level 1到非常確定並且能夠精益求精自我改善之最佳化的(optimizing) Level 5，在這個過程中，所規劃的都不是在談有關軟體開發的過程，反而是想要規範一個成熟之組織在達到某個特定等級的成熟度時，就其相關之軟體過程而言，應該要能做到那些事情，並且知其然且知其所以然」。
所以若有顧問或公司告訴您依據CMMI Level 2所要求的常規處理，就一定可以將貴組織所有的軟體專案做好，請千萬不要信以為真，那樣作可能會有問題，因為CMMI Level 2還必需要結合某種軟體發展生命週期(SDLC)，並對其中的知識及全生命週期的所有作業項目有一定之了解，否則，你可能無法做出符合該軟體專案所需要的軟體生命週期過程，所謂之軟體開發過程可以依循什麼標準？其實國內外均有不少，例如由資策會所推動之SDG2.0、美國國防部所推動之2167A、Mil-Std-498、到現在常被提到之國際標準ISO/IEC 12207 等等，均可以說是所謂的軟體開發過程，因為本篇後續內容會簡要採用ISO/IEC 12207等軟體生命週期過程來介紹其有關需求管理之部分，但是由於本篇只專注於討論Level 2的ReqM需求管理之流程領域，故只提醒讀者於建構CMMI時應一併考量之軟體發展生命週期(SDLC)觀念外就不在贅言，待日後其他主題中我們在來細談。