Guide Line : 基本上這系列的紀錄文件都是源自於參與了HSDC的教育訓練課程後的筆記，僅供參考，歡迎有興趣的夥伴們針對文章內容來討論。
I&I --> Iteration & Incremental , 透過適切的切分任務大小的結果，並將每個iteration的結果以漸增的方式組成產出。
在所有的開發方法論當中，提論的範圍都離不開 Language & Process，而在團隊開發工作中需要彼此所能溝通的語彙或語言，而這樣的語彙或語言、圖形就稱之為Language，同時在軟體開發上，每一個project 都有其時程規範，在合適的時間點需要有相應的人員來參與並產出相關的事務，這些就稱之為專案流程，並且是可被評估與度量的。
專案的失敗，雖然有很多種可能性，也許是管理方式錯誤、人員能力不足，甚至是管理階級能力問題，但這都不太會是最根本的主因，真正最大的問題是，一開始的假設立論基礎就有錯誤，在台灣我們常見的WaterFall的專案開發模式，本身就已經是一個不太可行的規劃起始點，在人月神話中已經提起過很多次，要以人月的方式來估算時程，這成功的機率根本是奈米機率。
在現今的專案軟體開發過程中，變動一直是無法避免的趨勢，但我們能拒絕嗎? 不，我們通常都是以鞠躬哈腰的方式來想辦法deny或者緩頰，直到擠出勉強可行的時程或開發資源，或者是整個放棄掙扎好好享受這種被霸凌凌虐的快感~(誤)....
那，我們可以怎麼做 ? 在已經跑好幾年的WaterFall 開發方式，會有很強大的體驗，就是當變動是在越靠近專案結案時，碰到變動就越痛苦，因為很難改動，或者是根本拿不出資源再來改了，這樣怎麼辦? lol ~
傳統的瀑布是開發的流程 SA --> SD --> PG --> Test，我們可以體會到的是，這過程是不可逆的，若一旦在最後階段才發現分析設計有錯誤，會變成巨大的災難，這讓我想到我其他部門的同事( RD5)，他們若要改一隻程式，就得連動的改其他60隻程式@@...夭壽喔...
若採用了I&I 的方式進行開發的話，我們會將一個步驟中，就會把需求分析、設計、實作、測試整包包在一起做，並由小至大的滾雪球般的不斷涵蓋住其他待執行的項目，雖然這個過程也是不可逆，但可留在下一個iteration當中再來進行變更修改，因為整個環節過程就是:
SA--> SD --> PG -->Test --> SA --> SD --> PG -->Test ~~~~
在Iteration過程中，我們會傾向於先把困難度高的、變動性高的、複雜度高的優先辦理進行，並快速的反應回饋給使用者，讓他們確知了解現行的產出是否符合需求，若以早期的瀑布式開發方法來跑，很可能會遇到最後無解的困境。
整體通盤來看，I&I 相比於Waterfall而言，並不會增進開發速度，但好處是可以快速地暴露風險、快速的產出對應!!
I&I 的進行中，第一個產出通常對於layout都是很單純很簡易的，不會要求畫面，對細節也不會處理太多，但在後續的i&i的時候則會逐步補上細節部分。
但也是有個最大的困難點，就是必須忍受不確定性的心理壓力，迭代的過程就是一個擁抱變動的過程。
本次課程是以UP的精神在go，但不需要完全採用UP的方式來做事情，取代的是參雜入了XP的概念進來，以RUP的架構來看，定義了4+1 View的觀點，包括了有 使用者案例觀點、邏輯觀點、實作觀點、程序觀點、配置觀點，這所有的觀點方向，是由使用者案例開始驅動進行，並揉合協調各種觀點之間的作業內容。
在過去的開發經驗中，常常都只是把需求拿來就寫了，久了好像也就都習以為常，感覺很好，可實際上是，這樣的過程並沒有累積下來對於特定domain的經驗累積，雖然有code可以看，但還是幾乎全都是專案客製化在跑，如果我們可以將domain的內涵 轉化為 domain framework，那麼就可實質的累積domain knowledge。
軟體開發最佳實務
- 以架構為中心的開發
- I&I
- 視覺化的方式設計軟體模型
- 需求變動管理與持續驗證軟體品質
- 侷限與收斂軟體的變動性
Q: What's the Architecture ?
繪製架構圖的時候，不適只有單單去化硬體配置圖，或者是component diagram來單一的描繪部分資訊，而是要能整體的提供
whole-picture 藍圖，讓團隊成員可以看著這樣的藍圖結構，就了解到何時該有什麼樣的產出。
whole-picture 藍圖，讓團隊成員可以看著這樣的藍圖結構，就了解到何時該有什麼樣的產出。
Q: 以專案的角度來看，對於架構上該怎麼規劃?
在HSDC的角度上，會是希望以Use Case driven ，稱為UC First，把每個use case 設定基準，以及切分的iteration的基準，
一個Iteration必須被收攏在一周內可完成。
一個Iteration必須被收攏在一周內可完成。
Q: 若以產品的角度來看，架構又要怎麼看? ... 跟專案性不同，要看另一張uml圖
Q: I&I 適合用來開發專案嗎?
以現在的資訊變動速度，專案真的變動機率太大，所以使用I&I 是最佳的選擇了
Q: 啥密洗視覺化的呈現軟體設計模型?
在適切的場合與用途上，使用UML來進行溝通與描述
Q: 需求變動管理，真的有辦法管嗎?
I&I 強調的是希望可以掌握住一個可以容忍的變動範圍，理論上就是以Use Case為主，可以變動的是Use Case內涵，而非是新增Use Case，
若是新增Use case的話，就超出了原先的需求範圍了。
若是新增Use case的話，就超出了原先的需求範圍了。
同時，對於軟體品質的話，我們會需要一個可連續驗證的作法~ (後續再討論以XP方式進行)
Q: 那該怎麼侷限跟收斂變動性?
我有問題? 怎麼樣評估他的變動到底大不大? 我們已UC為出發點，假設一個UC 的Iteration是總共3 iterations , 會花上3周，那麼若變動的話，
我們可以要求的也是3周的工作時間。
在HSDC的角度上，RUP的開發模式比較注重的應該是放在需求功能面、結構面、實作面，但台灣很常直接忽略掉結構設計-.-
我們可以要求的也是3周的工作時間。
在HSDC的角度上，RUP的開發模式比較注重的應該是放在需求功能面、結構面、實作面，但台灣很常直接忽略掉結構設計-.-
Iteration 的規劃
- iteration#1 - 確認使用案例所要完成的目標，建立結構與程式碼框架，找出從分析至實作的風險因子，建立溝通管道。
- iteration#2 - 將實現使用案例的細節補足，包括規則、流程、欄位明細、資料型態。
- iteration#3 - 做例外處理考量與實現。
架構的 Proof Of Concept
這裡其實有個重要的環節，就是我們必須確定專案所需要的各項技術與工具都必須被列進來，用以確保專案真的可被運行
- 利用uml建構概念模型草圖，以表達某一解決方案
- 利用模擬的方式提出解決方案
- 可以被執行的原型( Prototype) - 這個不是我們一般常見的拉畫面給UI，這裡指的是單純的需求原型，讓功能真的可以被執行，著重點是在於系統功能的驗證，也可以為客戶及團隊成員帶來信心。
UP - phases
- Inception
- Elaboration
- Construction
- Transition
在圖表的橫軸中有多項任務須被進行，但可以發現到並不是只存在於某個phase而已，是全部的phase過程中都有其任務工作，只是比重不一而
已。我們在開發時，雖然沒有rational的工具，但精神有掌握住真的去follow就可以了!
XP & I&I ... 考參考 extreme programming 這本書，XP 強調將模型盡力的描述於原始碼中，XP有12項專案開發實務，缺一就不能稱為XP
了。若要使用其中的CI，則通常都得需要一併實行 Testing First , 以及 Refactoring
已。我們在開發時，雖然沒有rational的工具，但精神有掌握住真的去follow就可以了!
XP & I&I ... 考參考 extreme programming 這本書，XP 強調將模型盡力的描述於原始碼中，XP有12項專案開發實務，缺一就不能稱為XP
了。若要使用其中的CI，則通常都得需要一併實行 Testing First , 以及 Refactoring
Unified Modeling Language --> 著重點應該還是放在language
adv. adj. noun.
Q : RA的階段到底都要做啥?
對於需求彙整的階段，每一次的訪談過程建議應在1~2 hr內完成，只抓重點開始跑，不做過多的深入探討，並於討論完畢後就可以進入到功能
實作。
實作。
Q : 專案起始階段要幹嘛?
定義好專案範圍，抓好主要的業務流程，了解專案的技術限制(包括其他系統間的溝通介面規格)，專案成功關鍵因素(做stakeholder 想要的東
西)
西)
Q : 圖2-1 的傳統流程圖，那邊有問題?(書籍可參考UML團隊開發與管理)
一張圖應該只有一個起點，但在本圖中感覺有好多起點@.@ ( myOS: 我們家大老們畫的圖 也都這樣錯綜複雜lol)
而且這類的圖表，不要放入document (就是一個方形但下方邊線為流線弧形)
描述process or activity時( ex: 填寫住院申請)，只要以人為人工需要做的事情來紀錄描述，不要把電腦該做的事情放進去(ex: 開機、填資料、
寫入db)綜合上述的原因，建議就直接使用UML Activity Diagram來描述就可以
寫入db)綜合上述的原因，建議就直接使用UML Activity Diagram來描述就可以
看看活動圖吧 ，這是給誰用的?
User 基本上分為幾類(原則上建議把兩者分開來)：
在訪談時，一開始就建議需要把這兩類的人分開邀請訪談，不要卡在一起~
- Domain Expert (ex :xx特助，研究主任.. etc) : 通常關注於流程合理化 , 這適合使用Activity diagram & 火箭圖
- Operator (ex: xx課長, 科員) :操作介面、軟體是否好用.. etc
活動圖的原則 :
- 只能有一個起始點，但可以有多個結束點
- 每個方塊都稱之為一個活動，每個活動都是以企業觀點來關注描述，不盡然都是以IT角度來審視(可能會以1~N個 action 來形成一個活動)
- 每個partition都扮演一個腳色
- 活動與活動之間的串連稱之為控制流的轉移
- 若有fork ，就該有join，而且所有的流程都必須等所有被fork出去的流程跑回來才能往下go
- 若有branching(分支)，則必須要有限制(constraint)，就是延伸出去的線上必須有其限制描述
EA 的專案目錄結構
Model
\Business Process Model
\UseCase Model
\Domain Model
\Class Model
Q : What's use case ?
使用案例代表的是使用者對你的系統的期望，也就是說系統應該提供給actor的功能這有別於傳統的functional的規劃，核心觀念是放在服務導向
跟需求導向，形而上的會是系統外觀給使用者，US在描述的時候可以想像一下是個瞎子摸象的過程，給一個概觀，而不用列出細部的內涵。
使用者案例可以對應到XP 的 Story Board~
同時要特別注意的是，假設boundary 是"系統"，那麼 supptor actor 也會是一個"系統" ，不能是被亂切開的不同類型的元素
沒有留言:
張貼留言