對於，ITIL的Notify的設置，有幾點想法提供考量；

            第一、ITIL的變更流程管理，是以角色形式定義在管理功能之中，而非是與組織的職位相呼應。若需要與組織職務相呼應，請考慮BPM，而非Remedy。

            第二、變更流程的簽核是以授權完成變更流程擁有權的遞轉，而非依賴非作業內容所需的所謂『關卡』，非以角色為考量的宜撤除。但撤除並非代表無法執行責權，此責權應由CM決定CAB時將之選入，如此才能回歸ITIL基本的管理精神。

            第三、延續第二點的觀點，不以『關卡』觀點來看授權。而CM動態在選擇CAB時，可考量將需求的MOT納入參與決議之列。而CM在決定CAB時，應以變更的品質為考量人選，而每個被選入的CAB成員，則以各自專具的專業觀點的品質提昇為變更決定是否授權或是提出建議，每個成員對於所參與的變更所下的決定，均是變更是否成功的重大關鍵。所以，不應以組織的職務來混雜Remedy的管理服務。必竟，多數的變更，並不是每個MOT Leader需要關注的事物。豈可因少數的變更，在簡明的流程中再加油添醋。
            第四、管理品質的提昇，組織的簡單原則應納入流程改善的考量。

　　數年來，一直無法搞清楚UML的那13張圖，到底要怎麼使用，才能適度表達分析或設計階段的意念；甚而，將物件導向觀念結合，單位系統開發流程中，使開發流程更為順暢。

　　而今，在Hsdc一次課程因緣中，結識了本書作者─邱郁惠老師，她以十餘年對於OOAD、UML至最近MDA的開發技術的專案經驗，推出了『寫給SA的UML/MDA實務手冊』的課程，對於她結合實務的寫作方式，讓我真是驚豔萬分。因為，為了研究UML與OOAD的開發流程的開發，買了數十本的書，並且四處上課學習物件導向開發觀念，卻始終不得其門而入的我，真是醍糊灌頂，受益無窮。

　　當郁惠老師再出『寫給C++程式設計師的UML實務手冊』這本工具書，僅以14個章節藉以進一步闡述MDA中PSM轉換設計到實作的方法技術，簡明而約要的陳述。不禁讓我觀想起前田約翰曾提出「盡可能減少，隱藏多餘的一切，同時避免失去固有的價值感」的簡單原則，藉以分散或隱藏來掩飾設計產品的擁擠程度，那種等值的藝術價值。

　　在零散而有限的時間中，好不容易斷斷續續的以兩個月時間拜讀完UML4C++，有一些以前一直無法組織起來的觀念，似乎就有了一些形狀，或許是無名且不可言諭。想著，想著，又回過頭去翻閱了其它UML的書目，包含了XP與軟體工程、VSTS等相關書目。似乎無意中，就將這些零散的知識，串起了一個開發，由SA至PG應有階段與作為的初始架構。

　　心中真是無限的欣喜與讚嘆。

　　「部分之總和不等於整體，因此整體不能分割，而整體是由部分所決定。反之，各部份也由整體所決定。」這是出自完形心理學的一項理論。

　　不約而同的，在本書中仍承襲MDA4SA的主題──

　　第一章到第四章，仍以一個基金系統作為貫穿全書工作流的整體主題前要方法的陳述。第五章開始，到第八章，則是以系統的部份，配以靜態類別圖與動態循序圖，實作出系統類別的屬性與操作，逐步地描繪出系統整體的部分功能。疊代反覆的動作在第九章又回過頭藉由使用者案例繁簡形式的描述，再與第二階段的類別和循序物件間產生出來的程式碼相互照映；提供了一個由部分需求設計到開發，看出這個基金系統的整體目標。

　　最後，再加上狀態圖與活動圖，來強化出系統核心要件內的關鍵狀態與系統整體的營運流程。

　　本書的架構，以UML作為設計工具，由第一章到第四章提供了整體到部分的設計觀點；從第五章起的章節，則反道而行，以部分觀點的設計與實作，延展出了對於整個基金系統開發的流程線視圖。

　　一個簡單的方法，僅僅使用四套圖表，就可以完成一個功能複雜的系統嗎？

　　答案，似乎是肯定的。

　　或許，不應該如此簡略的答覆。

　　就軟體工程的觀點而言，MDA應再結合專案觀點與測試、部署的觀點，才能成就一個完整的開發流程；才能確保一個完整系統的服務品質需求吧。

關於 CMMI

• 與其說 CMMI 是流程框架(Process Framework)，倒不如說 CMMI 是目標框架(Objective Framework)。
• CMMI 是以 “流程區域(Process Area)” 為主要完成目標。無論是以 “Continuous” 或 “Staged” 的途徑(approach)，均以 “Process Area” 為單位，來檢驗 “軟體能力” 的成熟度。
• Ex. “需求管理(Requirement Management)” 為一個 “Process Area”，是 CMMI level 2 必須完成的主要目標。(level 2 需完成 7 個主要的 “Process Area”；level 3 需完成 14 個”)。
• 每一個 “流程區域” 會細分為多個子目標。若該子目標只對應單一的流程區域，稱為 “特定目標(Specific goal)”；若子目標會涵跨多個流程區域，則稱為 “一般目標(Generic goal)”。
• 每一個特定目標/一般目標會列出一到多個 “期望(expected)” 的特定實務(specific-practice, sp)/一般實務(generic-practice, gp)。實務為一段陳述(statement)，表達了完成子目標時的作法。
• 實務並非為絕對、唯一達成子目標的唯一作法，它是 CMMI 建議、期望的作法，但仍可就現實狀況來找出 “自己” 的的實務作法，重點是，能達成(achieve)子目標(GG/SG)的規範與要求。
• 既然實務僅為敘述性的陳述，可以把它視為是 “抽象(abstract)” 的 “How-to”，要能找出符合實務的作法，可以從主流軟體開發流程，如 RUP/Agile/XP 等，找出實踐的具體手段。

CMMI 的 Model Content 為：Process Area, GG/SG, GP/SP。其中，Process Area 與 GG/SG 為達成軟體能力成熟度的必要元件(required component)；GP/SP 則為 "期望(expected)" 的元件，屬建議性，並非絕對需要。若以 UML 類別圖表達 CMMI Content 之間的關連，如下圖1 表示。

圖1、範例-利用 RUP/XP 方法論實現 Requirement Development -> SG3

CMMI Content 類別圖說明：

• CMMI Level (2~5) 包含(aggregate) 多個“流程區域(Process Area)”。
• 每一個流程區域會包含多個子目標(Goal)，子目標依性質區分為“一般目標(Generic Goal, GG)”與“特定目標(Specific Goal, SG)”。
• 將 GG/SG 設計為“Interface”的意涵在於，任一個具體(concrete)的實務(practice)類別，只要符合該子目標的介面規範即可，也就是說，CMMI 不規定“how-to”，只要能確實達成(achieve)子目標的規範即可。
• GP/SP 可視為是“抽象(abstract)”的“how-to”陳述(statement)，因此，具體實務類別也可以依循 GP/SP 內的陳述來具體實現。

[More:]

從主流開發流程找 How-to

• CMMI 只規範達成目標的標準，但並沒有規定該如何(how)達成目標。
• “如何”達成目標，需要找出具體的方法與解決方案，”How-to”的參考來源可以從 RUP/Agile/XP 方法論內的實務經驗與工作流程(Workflow)、樣版(Template)、實務案例等(當然，也可以由團隊內部自行找出最佳的實務經驗(Best Practices) )。
• 具體的 “How-to” 會對應(mapping) 至 CMMI 內的 GG/SG (goal)，也可以是 GP/SP (practice)。

範例一、Requirement Development -> SG3

圖2、範例-利用 RUP/XP 方法論實現 Requirement Development -> SG3

RUP 透過需求工作流程(Requirements Workflows) 內的幾個活動(activity)，來達成主要對 CMMI “需求開發” 流程區域內對 SG-3 的實現：

• 分析問題，找出關係人(stakeholder)，找出系統邊界與限制，瞭解關係人的需要(Need)。
• 定義系統範圍，利用使用案例模型(Use-case Model)描述系統的需求，以達成與客戶對系統功能性的共識；捕捉其它重要的需求，例如非功能性需求與設計限制等。
• 撰寫測試案例(以 Use Case 為單位)，由客戶提供測試腳本與數據，以作為在實作(Implementation)工作流程的自動化測試的契約。
• 實現(Realize)使用案例，將需求工作轉移至 分析/設計 的工作流程。

XP 是透過 “使用者陳述 (User story)” 來達成主要對 CMMI “需求開發” 流程區域內對 SG-3 的實現：

• 將需求寫成陳述(statement)，並且寫在卡片(4x6 索引卡)上。
  
• 客戶有權要求每個需求功能最細小的環節；程式設計師有權知道需求到底是什麼。
• 每一個敘述必須都是可以測試的(testable)，也就是可以寫成功能測試程式碼，來驗證敘述是否可以運作。
• 若一個功能敘述無法在一至兩個星期內完成，代表敘述可能太大了，必須對其分割為多個敘述。切成適當的大小，以便於評估其難易度，並做為未來量化時，估算的計量單位(功能點, functional point)。

範例二、Risk Management -> SG1 -> SP 1.3-1

圖3、範例-利用 RUP/Agile 方法論實現 Risk Management -> SG1 -> SP1.3-1

RUP 透過專案管理工作流程(Project Management Workflows) 內的風險管理的部分，來達成主要對 CMMI “風險管理” 流程區域內對 SG 1-> SP 1.3-1 的實現：

• 採用循環與漸進(I&I, iterative and incremental)的開發方式，及早降低風險。
• 列出風險清單，並制訂風險高低指標(risk magnitude indicator) 辨識與描述風險的高低程度。
• 利用架構 POC (proof of concepts)，來找出會影響架構的風險因子，包括系統整合、人員技術與技能等問題。
• 建立測試工作流程，及早獲得系統品質的相關回饋(feedback)，並找出在分析設計與實作階段的隔閡(gap)。

Agile 並沒有建立與風險管理相關的計畫，而是透過頻繁溝通、大量取得回饋，儘早釐出風險，並透過實務來克服與解決風險。

• 採用循環與漸進(I&I, iterative and incremental)的開發方式，及早降低風險。
• 客戶與開發人員在專案進行期間一起工作，以降低溝通的風險。
• 採測試先行與接受度測試，以降低需求變更的風險。
• 早一點作整合，經常做整合測試，以降低系統整合的風險。
• 經常釋出(release)可用的版本，週期可是數週到數個月(最好三個月內)，較短時間間隔為佳。

結語：CMMI 綱要

• CMMI 非高度儀式且為重型的開發製程，它是指導軟體開發的綱要，CMMI 也沒有給具體的實務手段，它是制訂了目標與方向，來引領軟體開發往 “對的方向” 走。
• 找出達成 CMMI 所制訂的手段，可以透過主流的軟體開發流程，包括 RUP/Agile/XP 等，並依據專案的規模與性質，來對開發流程與產出(Artifacts)，作適當的裁適(Tailor)。
• 可以利用倒推式的目標設定與規劃(Backward Planning)的方式，來找出如何達成目標的手段。所以，若 CMMI 為目標(Goal)，那麼，RUP/Agile/XP 就是可以達成目標的手段(How-to)，兩者是互補，而非衝突。
• 回到最本質的一面，“人” 才是影響軟體開發最關鍵的因子，我們更需要知道的是，在團隊開發人員的角色裡，應該具備的素養與修練是什麼，而要學習的技能與技術，又是那些，然後，才來找出適合軟體開發人員的 "利器(Tool)"。專案管理者，切莫本末倒置，先從工具與製程著手，而忘掉根本。

目標設定規劃與行動的精要：

1. 檢視目標與方向 → 找出手段(how-to) → 瞭解技能與技術/心理素養 → 善用利器
2. 調整與修正手段→循環與漸進→往目標前進！
   

作者：林耀珍

2003 年 11 月

速度是企業競爭致勝的關鍵因素，軟體專案的最大挑戰在於一方面要應付變動中的需求，一方面要在緊縮的時程內完成專案，所以軟體團隊除了在技術上必須日益精進，更需要運用有效的開發流程，以確保團隊能夠發揮綜效。這正是 Agile Process (敏捷的軟體開發流程) 於近年來興起的主要原因，本文將介紹數種廣為接受的軟體開發流程，及其在運用上的建議。

Agile Process - 敏捷的開發流程

幾乎所有的軟體專案都會在起始階段面臨選擇開發流程的困難，一種是完備的開發流程，另一種是簡易輕便的流程。雖然我們了解採用完備的開發流程可以提高軟體的品質，但是因為欠缺人力、工具與時間，我們常會被迫採用簡化的流程，但事與願違，大部分的情況我們仍然難以在預算內及時完成專案。

Agile Process (敏捷的開發流程) 是一種軟體開發流程的泛稱，Agile Process 具有下列幾項共通的特性：

1. 客戶與開發人員形成密切合作的團隊，因為客戶無法於初期定義完整的規格，而開發人員於開發過程中也常常無法知悉外在環境或業務的變動，所以需要兩者密切合作方能開發適用的軟體。
2. 專案最終的目標是可執行的程式，因此所有的中間產品必須經過審慎評估，確認有助於最終目標，才需要製作中間產品。
3. 採用 Iterative 與 Incremental 方式分階段進行，密集 review 是否符合需求。
4. 流程可以簡單，但規劃與執行必須嚴謹。
5. 強調團隊合作，賦予高度的責任，團隊有自主權得以因應變化做調整。

RUP 開發流程 - Rational Unify Process

RUP 為 IBM Rational 公司經過多年的研發與經驗所提出的軟體開發流程，其內容含蓋 Business modeling, Requirement Modeling, Logical Design, Implementation, Testing, Deployment 等軟體開發生命週期的直接工作，與 Project Management, Change & Configuration Management，Environment support 等支援性工作。RUP 的內容非常豐富，不同的專案需要不同調整，IBM Rational 提供 RUP workbench 工具，方便調整 RUP，並公佈於 Web，方便專案成員遵循統一的流程規範進行工作。

RUP 的主要精神為：1. 專案進行採用 Iterative 程序分階段漸進地完成專案功能；2. 廣泛使用 Visual Modeling 於商業需求分析、系統分析與系統設計；3. 強調架構設計；4. 對每項工作所需要的技術、工具、做法、範本、檢查項目均有詳細的定義，架構完備且具有可調整的彈性。

因為 RUP 的流程規範與相關技術較複雜，所以導入時必須注意幾個因素：1. 主管的支持以確保足夠的資源投入；2. 分階段導入；3. 適當的訓練與密切的顧問咨詢；4. 使用 Modeling 技術時需要考量 Coding 的實作環境；5. 良好團隊的管理，以溝通、耐心與堅持解決變革的人性阻力。

XP 開發流程 - eXtreme Programming

XP 亦稱為終極流程，是最輕量級的開發流程，其最主要的精神是『在客戶有系統需求時，給予及時滿意的可執行程式』，所以最適合需求快速變動的專案。XP 經過 6 年的實作與修改，已演化為精緻的開發流程，但仍不失其精簡的特性，它強調客戶所要的是 workable 的執行碼，所以把與撰寫程式無關的工作降至最低，並要求客戶與開發人員最好以 side-by-side 的方式一起工作。

XP 開發流程的基本步驟為：1. 開發人員隨時可以和客戶進行有效溝通，撰寫 user stories 以確認需求。2. 簡易快速的系統設計，撰寫獨立的驗證程式以解決特殊困難的問題，找出演算法即可丟棄驗證程式。3. 規劃多次小型階段的專案計劃，以最快速度完成每一階段的程式交付客戶，客戶負責 Acceptance tests；4. Coding 前必須完成 Unit Test 與 Acceptance tests 程序，所有模組整合前都須經過 Unit Tests；5. 開發人員必須快速回應 Bug 與需求變更；6. 要求二人一組使用一台電腦設計程式，當一人 coding 時，另一人負責思考與設計；7. 程式必須符合程式規範，並常做程式的重整 (Refactoring)。

XP 屬於較精簡的流程，於導入應注意幾件事情：1. 最好有顧問給予協助；2. 持續的 Review；3. 可適當調整流程，但不可失去其基本精神。

SCRUM 開發流程

SCRUM 開發流程是 Agile Process 的一種，以英式橄欖球爭球隊形 (Scrum) 為名，基本假設是『開發軟體就像開發新產品，無法一開始就能定義 Final Product 的規程，過程中需要研發、創意、嘗試錯誤，所以沒有一種固定的流程可以保證專案成功』。Scrum 將軟體開發團隊比擬成橄欖球隊，有明確的最高目標，熟悉開發流程中所需具備的最佳典範與技術，具有高度自主權，緊密地溝通合作，以高度彈性解決各種挑戰，碓保每天、每個階段都朝向目標有明確的推進，因此 SCRUM 非常適用於產品開發專案。

SCRUM 開發流程通常以 30 天為一個階段，由客戶提供新產品的需求規格開始，開發團隊與客戶於每一個階段開始時挑選該完成的規格部份，開發團隊必須盡力於 30 天後交付成果，團隊每天用 15 分鐘開會檢視每個成員的進度與計畫，了解所遭遇的困難並設法排除。

SCRUM 與傳統開發流程及專案管理差異較大，於導入時最好有顧問協助。

總結

Agile Process 的精神已經成為共識，但是沒有一種固定的流程可以重複使用在不同的專案上。而且不管是 RUP、XP、SCRUM、或其他的開發流程都允許相當大的彈性，我們必須按專案性質的不同，調整或混合出適合的開發流程，並允許團隊於進行中做必要的彈性修改，方能達成目標。

參考資料