EA 和團隊開發技巧 - UML 、軟體開發與建構管理

1. EA和團隊開發技巧 - UML、軟體開發與建構管理 Ringle Lai

2. Agenda • UML與軟體開發 • 軟體開發最佳實務 • HSDc Team簡介與實際實務經驗分享 • 軟體建構管理實務(整合EA與Subversion)

3. UML與軟體開發

4. 為什麼需要UML • 在建築業中，設計圖是一座建物中最重要的基礎，建物必須要依圖施工，才能夠保證建物的品質 • 軟體設計與建築相同，有品質的軟體必須要能夠依照設計圖施工，也必須要能夠依照設計圖檢驗 • 正因為設計圖的重要，因此，設計師在面對任何的開發團隊成員，都應該要採用統一的設計語言，這也就是為什麼目前所有的設計團隊都重視UML的原因 • 擁有一個好的UML工具，能夠讓程式碼與設計圖合而為一，無論是從設計圖產生程式碼，或是從程式碼產生設計圖，都可以完整支援

5. UML可以幫助我們什麼？ • 讓團隊成員可以用共同的設計語言溝通 • 可以把團隊的設計心血完整記錄下來，以供日後參考 • 面對大型專案時，不同的開發團隊可以利用不同的UML圖形把焦點放在特定的一個領域中 • 十三種UML的圖形，可以涵括整個軟體設計各個不同面向的設計

6. 什麼是UML不能做到的？ • UML不能夠「保證」軟體一定設計的出來 • 這是屬於「軟體開發流程」的範疇 • UML充其量祇是一個設計的共通語言，並不包括「軟體開發流程」的標準化 • 一般而言，軟體開發團隊必須要有自己適用的「軟體開發流程」，並配合該流程，決定使用的UML元件有哪些 • HSDc所規劃的開發流程，主要包括RA(需求蒐集)、HSD(高階系統設計)、DSD(詳細系統設計)、PG(程式寫作)、SI(系統整合)等流程，每一個不同流程，都有其適用的UML圖形

7. 什麼是UML不能做到的？ • 使用UML並不能夠保證設計圖和未來寫出來的程式碼是一致的 • 這主要是「專案管理面」的問題 • 一般來說，大部分的專案在越接近交付的時間時，設計圖與程式碼的落差就會越大 • 由於時間的壓力，再加上沒有一個好的工具輔助做雙向的檢核，往往在專案完成後一年，設計圖和程式碼的差異就已經完全無法彌補 • 最終，使用UML變成祇是製作文件，而並非伴隨著軟體設計的產物

8. 什麼是UML不能做到的？ • 使用UML並不能夠保證軟體能夠及時交付 • 這同樣是屬於「軟體開發流程」的範疇 • 在軟體開發流程中，應該盡可能使用「I & I」(Iteration & Incremental)的方法來開發，以減低開發的風險 • 在HSDc所規劃的軟體流程中，RA->HSD->DSD->PG->SI，整個完整的開發流程，應至多以「一個禮拜」為單位作一個循環，如此可以盡快瞭解整個專案的風險，並且快速反應使用者的需求

9. 什麼是UML不能做到的？ • 使用UML並不能夠保證程式在交付時的正確性 • 這主要是屬於「測試管理」的範圍 • 一般來說，一個專案的成功與否，主要端視其是否擬定一個完整的測試計畫 • 測試計畫需要由使用單位與開發團隊來共同擬定 • 測試計畫的擬定，應該要在專案的需求蒐集階段就完成，並且隨著需求的變動而隨之調整 • 測試程式的寫作則必須要在程式寫作之前完成，如此可以避免造假

10. 關於UML與軟體設計 • UML祇是軟體設計的通用平台，而軟體設計則包括「開發流程規劃」、「架構設計」、「專案管理」、「建構管理」、「測試管理」等不同的構面 • UML在每一個不同的構面都可以提供相對應的協助，但最終來說，仍需要針對不同構面建構出團隊所需要的相關管理機制 • HSDc主要是針對這幾個不同的管理構面提供顧問服務，包括規劃開發流程、輔導架構設計、建立管理制度 … 等相關的服務 • 以下，我們將提出幾個不同產業的實例與各位分享

11. 大型家電廠的採購系統開發案例

12. 案例背景說明 • 該專案為一家大型的家電製造商所開發的系統 • 該廠商的上游有多家的供應商，供應不同的相關原料 • 當該廠商的生產單位在其ERP擬定生產計畫後，會將該年度的原料請購紀錄送至電子化採購系統，該電子化採購系統會自動產生「RFP」(Request For Purchase)，並利用簡訊系統以及Email給予註冊的供應商 • 供應商在收到簡訊或是Email後，必須要先到該廠商的電子化採購系統中，在採購要求所需的時間內提出報價單 • 該廠商的採購人員(Buyer)透過電子化採購系統進行比價，並且決定第一優先及第二優先順位的供應商，並產生採購單，同時透過簡訊系統以及Email通知該兩家供應商 • 供應商收到簡訊後，若是確認要進行供貨，必須在規定的期間內，到電子化採購系統確認採購單，電子化採購系統收到確認後，會以Email通知廠商的負責採購人員 • 廠商採購人員到電子化採購系統確認採購單，電子化採購系統會將該採購單回傳至該廠商的ERP系統中

13. 軟體開發流程設計 • 本專案共包括以下角色： • RA：負責蒐集使用者的需求 • Architect：負責整體系統架構設計，並且Review SA/SD與TD的設計規格 • SA/SD：負責進行整體系統的高階設計，在本階段，並不考慮平台面的實體設計 • Technical Designer (TD)：根據SA/SD的設計結果，加入平台面的實體設計，並且負責督促PG完成程式設計 • PG：負責進行程式設計以及撰寫單元測試程式

14. 軟體開發流程設計 – 續 • 上述的幾個角色的工作內容以及執掌，如下圖所示：

15. 軟體開發流程設計 – 續 • 軟體開發時間進程設計 • 本系統主要是利用 I&I 的方式進行設計，因此，每個Iteration以「一週」為單位 • 每個「Iteration」預計完成三個「使用案例」，並且在每一個「Iteration」交付後，由使用者直接進行兩個禮拜的測試，每一個「使用案例」則允許兩次的修改 • 以本專案為例，共有39個使用案例，因此，預計使用26週的時間進行開發(約六個月)

16. 架構設計 • 該系統必須要能夠與ERP系統溝通，除此之外，由於該家電廠商的工作流程系統是Notes平台，因此，也必須要能夠與Notes系統溝通 • 在設計上，HSDc建議使用「軟體主機板」的設計方式，搭配「IBM MQ」作為資料交換的平台 • 整體架構設計如下圖

17. 架構設計 • 利用UML Package Diagram表達系統架構

18. SA/SD產出 • 以「產生RFP」為例，在該設計中，下圖中的三個服務是EP開發團隊必須要完成的服務

19. SA/SD產出 • 針對上述的每一個Use Case，必須要寫下其使用案例敘述

20. SA/SD產出 • 每個Use Case會有對應的Sequence Diagram表達其實作

21. TD產出 • 針對HSD的Sequence Diagram，DSD應該要繪製平台面的相關設計

22. UML扮演的角色 • 上述所有不同角色的人員，都利用UML進行設計，各個角色的人員都可以透過UML來溝通 • 因此，針對各個不同角色的人，必須具備： • 繪製及讀取UML設計圖的能力 • 使用UML工具的能力 • 針對Architect，則必須： • 瞭解各個不同層次(SA/SD及TD)對於相同的Domain的UML表達之差異 • 規劃整體系統的架構規範

23. 軟體開發最佳實務

24. 以架構為中心(Architecture Centric) • 所謂的架構(Architecture)，就是希望擔任各類角色的軟體開發團隊，都能對系統有一致性(consistence)的全貌見解 • 軟體架構(Software Architecture)不只跟結構與行為有關，同時也跟背景環境有關，包括： • 使用方式 • 功能性(Functionality) • 效能 • 彈性 • 再使用性(Reuse) • 可理解性(Comprehensibility) • 經濟效應與 • 技術的限制與取捨

25. 以架構為中心(Architecture Centric) • 一般來說，軟體架構的可由三個主要觀點來觀察 系統外部的觀點 功能與非功能性 利用使用案例模型 需求觀點 軟體架構 實際可執行的程式碼 與平台技術息息相關 利用自動化測試機制來檢驗 重視系統的結構設計 表達重要的Domain Concept 利用類別圖以及循序圖 結構觀點 實作觀點

26. 以架構為中心(Architecture Centric) • 在第一個時間點，架構師(Architect)必須要能夠確實定義自己所開發系統的範圍 • 利用「使用案例圖」(Use Case Diagram)可以幫助架構師釐清系統的範圍 • 利用「套件圖」(Package Diagram)可以讓架構師瞭解模組與模組間的相依關係 • 利用「複合結構圖」(Composite Structure Diagram)可以讓架構師瞭解介面間的彼此相依關係 • 利用「類別圖」(Class Diagram)可以讓架構師確認Domain的重要概念

27. 常見的謬誤 正確的架構觀點 以架構為中心(Architecture Centric) • 「使用案例圖」與系統架構 共同的問題： 忽略了系統範圍

28. 以架構為中心(Architecture Centric) • 套件圖與系統架構 支援性系統 確認所要開發系統 的使用者 與支援性的系統 使用者

29. 以架構為中心(Architecture Centric) • 複合結構圖與架構 明確定義介面關係

30. 以架構為中心(Architecture Centric) • 類別圖與架構 用Domain Concept 定義系統內部的結構

31. 循環漸增(Iteration & Incremental) • 循環漸增的開發方式，最大的優點在於它把風險的問題儘早凸顯，並在較不衍生太多其它相關的問題時就事先處理

32. 循環漸增(Iteration & Incremental) • 反覆式流程的開發方式有下列優點： • 提早降低風險 • 較早能具有可視性(Visible)的進展(Progress) • 較早能得到回饋，較可以得到使用者的保證(engagement)及適應性(adaptation)，由此再精緻(refine)系統的設計，以更進一步契合使用者的需求 • 增加團隊的信心，並可以一直學習 • 產品的整體品質較佳

33. 循環漸增(Iteration & Incremental) • 一般而言，當需求變化較大，系統範圍較不固定的系統，利用循環漸增的方式，能夠有效地面對改變的需求，快速反應 • 相反地，若是需求非常固定，且系統範圍不會有大幅度地修改，使用循環漸增和傳統的瀑布式開發模式，並沒有太大的差距 • 一般來說，循環漸增最大的潛在危機是：開發團隊成員無法忍受「不確定性」

34. 軟體製程簡介

35. 軟體製程簡介 • 軟體製程並非一成不變，和晶圓代工的製程一樣，面對不同的專案、不同的團隊成員，應該要調配出不同的製程，如此一來，才有可能讓整體的軟體產出具備良好的品質 • 若以兩岸分工而言，HSDc所設計的軟體製程如下

36. 軟體製程簡介

37. 需求蒐集階段 • 在需求蒐集階段，RA與Architect應先針對所要開發的系統範圍進行兩方面的訪談 • 針對所面對的企業，應先瞭解該企業的「主要企業流程」，並且蒐集相關的「企業規則」，此部分的訪談對象應該是該企業的「領域專家」 • 至於局部性的需求，則應該對實際的「操作人員」進行訪談，並且記錄相關的功能性以及非功能性的需求 • 企業流程塑模可以利用UML的Activity Diagram或其擴充型態 - Eriksson-Penker Business Extensions來表達 • 局部需求蒐集，則可以利用「使用案例模型」來進行蒐集以及整理

38. 企業流程塑模 • Eriksson-Penker Business Extensions的企業流程塑模

39. 企業流程塑模 • 訂單處理的範例

40. 企業流程塑模 • 當然，針對每一個Process的內涵，可以定義更詳細的工作流程 • 此時，可以利用UML的Activity Diagram來進行描述 • 當然，企業流程塑模的對象是領域專家，因此，一般來說，在進行企業塑模時，不宜介入過多的操作性的資訊

41. 需求的蒐集與整理 • 一般來說，需求的蒐集通常是利用「純文字」把資料進行彙整 • 但是，我們可以透過UML的Extend的Requirement Diagram來整理這些需求

42. 需求的蒐集與整理 • 非功能性的需求，我們也可以利用相同的圖形來進行蒐集

43. 利用使用案例收斂需求 • 使用者的需求大都天馬行空，因此，我們必須要將訪談的重點盡量收斂在特定的「焦點」上 • 使用案例指的是對使用者而言，一個比較「有意義」的「功能點」，因此，利用使用案例來聚焦，通常會比較有效率 • 在使用案例中，一方面我們可以將過去所蒐集到的Requirement與使用案例進行對應，另一方面，也可以讓使用者進行腦力激盪，確認對他們而言有意義的需求

44. 利用使用案例收斂需求 • 使用案例對應至Requirement

45. 利用使用案例收斂需求 • 當然，對於使用者與系統間的對話過程，我們也會利用使用案例敘述將之表達出來

46. 利用使用案例收斂需求 • 至於每一個使用案例，也應該提出至少一個有關該使用案例的測試案例

47. 系統的分析與設計 • 在系統的設計階段，應該先把平台面相關的知識先放在一邊，而應該思考有關Domain上的重要議題 • 一般來說，在這個階段中設計的類別，不外乎是分析型的類別，包括： • Control Object • Boundary Object • Entity Object

48. 分析類別中的Control Object • Control object是屬於功能性的Object，而且這個功能與Use Case有相當密切的關係 • 一般來說，Control物件主要的任務是協調各種物件，讓物件彼此合作以達成Use Case所想達成的功能面的需求 • 在設計策略上，我們通常會讓每一個Use Case都有一個Control Object，這個Object就稱之為「UCO」(Use case Control Object)

49. 分析類別中的Control Object • 下圖就是Control Object的示意圖

50. 分析類別中的Boundary Object • Boundary Objec是屬於與外部橋接的Object，這類型的Object將會與外部直接接軌，受到外部的限制 • 就Use Case的觀點來看，所有跟外部Actor溝通的地方，都必須要加入一個Boundary物件 • Control Object與Boundary Object其實和Use Case的關係非常密切