emerged : 出現 ( 拼音: a merged)
2.1 What is the UP ? Are other methods Complementary ?
- 一個 Software development process 描述了如何去建構、部署，以及軟體維護的作法，在UP的世界裡面已經很早就出現了一個像這樣子的一個做法模式，他就是RUP (Rational Unified Processing)。
- UP是一個相對的較為受歡迎的專案開發模式(使用OOA/D)，同時UP也是一個非常具有彈性且開放的模式，並且鼓勵使用包含了具有技巧性的迭代式開發方法，ex : XP, Scrum，舉例來說 像是XP的測試驅動開發、重構、還有持續整合的部分，都可以被實作在一個UP開發模式的專案裡。 PS : 測試驅動在 ch21 中會看到
- UP的開發模式整合了常見的最佳實踐作法，包含了有迭代式開發、風險驅動開發、以及高內聚力&良好文件撰寫的開發方式，統整來說本章要說明的是
UP is an iterative process. Iterative development influences how this book introduces OOA/D, and how it is best practiced
UP practices provide an example structure for how to doand thus how to explainOOA/D. That structure shapes the book structure
The UP is flexible, and can be applied in a lightweight and agile approach that includes practices from other agile methods (such as XP or Scrum)more on this later
但關鍵是，如果我完全不理會UP或者 我根本不喜歡UP 又如何?
- UP是用來作為一種建模開發方式，透過迭代與漸進的方式進行需求分析以及OOAD，所以它是有必要的!
2.2 What is Iterative and Evolutionary Development ?
- 在UP以及其他現代的開發方法實踐做法中最關鍵點是 迭代式開發!!，這是一種透過生命週期管理模式的開發方法，軟體開發在這種管理模式下，會變成一系列的 短周期、固定工時模式(ex:每個feature都被限制在2周內完成，這也可以被稱為是迷你專案開發--> Iterations )，對於每一個迷你專案的開發產出結果，都是一個已經被測試過，且可執行的部分小系統，每一個Iteration 都包含了他所需要的需求分析、系統設計、實作，以及測試行為。
- Iterative lifecycle 是建構在可被連續擴大的系統需求，以及逐步細化功能需求的開發模式上(所以如果你是維護案應該也許可以從小功能來考量能不能套用)，藉由不斷的週期性的進行itration cycle以及更新，作為整個開發模式的核心，最終將彙整而成一個適於發布的版本。
- 系統會隨著時間不斷的因iteration進程不斷的成長這也被稱之為 " Iterative and incremental development "，因為每一次的周期進程交付予客戶後的使用意見回饋以及更新都會引領著規格與設計的發展，所以也又有另一個名詞叫做 Iterative and Evolutionary development.
- 比方來說，假設我們要進行一個為期3周的 iteration迷你專案，也許我們可以每個周一早上花個一小時進行會議，討論確切要進行的任務與目標，同時也找一個人來做class reverse conversion產出UML，用來討論這些內容是否需要被改進，並且大概地進行uml 繪製、或者虛擬碼的撰寫，用pair programming的方式進行，而其他的時間就是真正進行實作的過程，以及各項參與與客戶討論的行程。
- 要特別注意的是，上面的例子中並不是要你很快的去把code給寫出來˙，也不是要你用一個長時的細部設計細節來，我們要的是稍微多加一些的"深謀遠慮(forethrought)"用來思考與設計，透過視覺化的uml來進行，也許光是進行這樣的動作就會耗去半天的時間。
- 完成一個 iteration時，也許不足以構成發布一個獨立的功能模組，說不定會是10~15個才能構成一個，而這些 iteration的產物不適一個體驗版或者說是隨時可丟棄的prototype，他們是整個產品的不同階段的分級產出物。
How to Handle Change on an iterative Project ?
- 老實說，做專案最怕遇到需求不斷的變更，但做為以iterative的需求開發方式，基本上就是要擁抱變更，我們強調的是接受需求討論過程中所帶來的歧異點的最終解決方案，而不是一昧的去衝撞簽訂的簽收文件或者合約項目，在後續的章節中會提到如何去對於不斷的變更過程中該怎麼樣與實作、時程取得平衡。
- 每一個iteration都是一個需求的子功能，而我們依此進行快速的設計、實作、還有測試，在這樣的及早投入iteration cycle所取得的產出，卻有可能不是最終的軟體需求，這樣做真的好嗎? 答案其實我本人也不太能肯定，但書上提到的是說，藉由這樣小型且深入的實作過程，而不是等到所有的需求都確認底定，可以變成由自己乾脆提供一個版本讓使用者直接針對這結果進行意見回饋，反而比較能更快的取得共識。這對雙方都有好處，客戶不再是非得等到你都全部寫完才會知道說到底東西對不對，而你也不會是到了最後才發現原來需求不是這樣，搞得自己綁手綁腳 操到腿軟。
那到底這樣好處在哪?
- 專案比較不容易失敗，較好的產出效率，較少的缺陷率，這都是藉由不斷的去從iteration中所取得
- 提早進行降低高風險的項目的進行( technical , requirements, objectives, usability, and so forth)
- 及早取得使用者回饋，以及使用者參與(user engagement)，引領我們在實作過程中更能貼近真正客戶想要的東西
- 管理複雜性(managed complexity)，這樣團隊並不是被分析癱瘓掉?? (這一句有點跨謀)，我球隊的朋友提出的看法觀點如下： 依我的經驗(畢竟我們兩邊公司的產品及面對的客戶本質上有差異, 我的經驗不一定在你這邊能做的準), 產品開發的大方向是固定的, 有的只是裡面的功能/元件該用多高的priority來執行. 或是一個功能太大, 非得用一個月才能做完, 則把它拆小成三個階段分批做, 投入不同的iteration來實作.在每個iteration完畢, 面對使用者的意見回饋時, 應該可以"大家來談A功能, 而RD去做B功能吧"?原本一個大功能拆成三小份, 針對個別小份來做檢討, 複雜度會低一點吧? (我認為是)如此一來, 就不致於落入討論沒完沒了, rd完全不能開工. 何況每個iteration為2~3週長, 能排入的功能也不會太多
- 學習使用iteration的方式可以讓你保持有條不紊的一個接著一個的往下走
How Long should an Iteration Be ? What is iteration Timeboxing ?
- 大多數的iterative methods 都建議是要把時間長度控制在2~6周內，也就是一個功能主題最多被討論個3次就得定案了，過長會拉高專案風險而且feedback也來的太遲，若一周內就搞定也很可能會是沒有真的touch到真實的需求
- 若對於擬定下的iteration不能在3周內完成的話，那就表示是規劃錯誤，必須將功能再次拆解出來
2.3 What about the waterfall lifecycle ?
- Waterfall 又或者我們可以稱呼它是Sequential lifecycle process，是一種企圖以定義(涵蓋細節)企業需求全貌後才進行 系統開發的 規劃分析模式，而通常，都會是徹底(thorough)的設計後才進行開發，你說這好不好呢?
- 但換句話說 如果當你是在一個iteration project 上，但卻發現到一件事實，就是大部分的需求都在系統設計前就被寫下，而且都還是及盡可能的把細節都給寫了進去的話，那麼這對你的iteration來說就變得沒有意義甚至會是種折磨了
- 在60,70年代確實受到推崇與肯定的waterfall模式，以現代的軟體開發過程來看，變得有點像是諷刺，主要的原因是這樣跑的案子往往引領走向失敗，因為過早訂下的需求很多到最後根本都沒在使用，或者是走到最後才發現又要改需求了。
- 用現在的角度來看，waterfall方式是築基於一種推測(speculation) or 傳聞耳聞(hearsay)的需求來源，而非是依循真正需求有證據(evidence based)的實作，相反的看看 Iterative processing就剛好不是了
2.4 How to do iterative and evolutionary analysis and design ?
- 以下來看看一個簡單的案例介紹
- 在Iteration-1 之前，讓我們先守住這第一次的timeboxed requirements workshop, 大概是差不多兩天工作天，然後進行個會議，讓開發人員還有業務人員以及架構師一併參與。
- 第一天上午，讓我們進行比較高層級較抽象化的需求分析，像是界定出Use cases and features，還有那些non-functional requirements，當然別忘了這只是初次第一次討論，一定不會完美的。
- 接著讓我們來問問架構師以及業務人員(或者我們可以說是甲方)，從這第一次彙整出的需求清單中找個10%來討論看看，並且混進這三種品質要求如下：
(1)在架構方面具有其重要意義的部分(architecturally significant)，如果到了實作階段，我們需要徹底地進行設計、建構，以及測試這整個核心架構。
(2)較具有商務價值的部分優先拿出來討論
(3)較高風險的項目也可優先拿出來討論
而Use Case需要進行編號，我們也許可以編成這樣 UC1,UC2.... etc - 一樣，在還沒真的走入Iteration-1之前，我們先召開一個iteration計畫會議，從先前彙整出來的UC*當中來挑選進行設計、建構、測試，並訂定一個合理的執行時間，舉例大概可以用個4周的時間框，記得不要一次挑選太多的UC在這樣的iteration一次跑完，那會太多。而在執行iteration-1的時候，一開始我們可以讓developers 作揖些建模與設計的工作by pair ，勾勒出UML-ish的圖像在草稿或是白板之類的，之後接續讓developer 開始coding,testing,並且持續整合，當然我們會了解到這些models 是一小部分的而且通常是稍微模糊的。
就這樣地進行一周後，在一周結束前仔細再次審視原本的iteration目標是否可以被契合，若不行，那就descope，再切分下去。
在第一個iteration的最後一周快結束時，把下一個task納入並進行同樣的開發方式來go
2.5 What is Risk-Driven and Client-Driven Iterative Planning
- UP 鼓勵用一個risk-driven & client-driven 的iterative 計畫，這表示Task Goals可以在早期被確定出高風險以及使用者迫切需要的期待下，來優先取得客戶信任。
- Risk-Driven iterative 開發方式包含了更多的特別的 iterative developement，特別是在architecture-centric，這意味著早期的iterations會注重在building, testing , stabilizing of the core architecture.因為如果沒有一個強固的架構通常這都是超級高風險拉XD
2.6 What are agile methods and attitudes
- 參考figure 2.4 Evolutionary analysis and design the majority in the early iterations.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The agile principles
- Our hightest priority is to satisfy the customre through early and continous delivery of valuable software
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a cuople of months, with a preference to the shorter time scale.
- Business people and developers must work together daily throughout the project.
- Build project around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- working software is the primary measure of progress.
- Agile processes promote sustainable development.
- The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enchance agility.
- Simplicity the art of maximizing the amount of work not doneis essential.
- The best architectures, requirements, an designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
2.7 What is Agile modeling
- The purpose of modeling ( sketching UNL, ...) is primarily to understand , not to document.
- 這也就是說大多的modeling的動作中最好是可以提供一個比較好的方法來了解問題核心或者解決方案的存在空間，從這樣的觀點往下走，那麼在繪製UML時，就會發現到這部是說要讓一個設計者去創造出眾多的細節的UML圖給pg，反而是要從中快速的揭露出主要路徑與替代路徑來，像這樣的觀點也就被稱之為Agile modeling。
Agile Modeling意味著有一些做法與價值觀如下：
- 應用了 agile方法並不代表忽略任何的建模作法，這是一種誤解，有很多的agile方法論，像是Feature-Driven Development, DSDM, Scrum等等，都包含了相當(大量)程度的建模會議內涵在其中
- 建模的用意以及模組本身主要目的是為了去了解問題核心與溝通而非單純只是為了文件化
- 不要一開始就極盡可能的把你所知建模方式或者uml 全都套在你的軟體設計上，把一些設計的內涵延遲到確實在開發時可以用來解決開發與測試的部分，把建模與uml 應用在比較不常見、困難、奇怪的設計議題上即可。
- 用最簡單的工具來做事，避免你有太多的學習曲線，主要是為了快速的取得變動的異動的結果，讓你可以快速又簡單的產出，有時候甚至只是白板也是個好工具
- 不要獨自自己進行建模，因為建模過程是要探索、了解，還有分享其他不了解的問題核心部分，讓你的參與者一銅進行往往可以帶來不同的好處。
- 同時在建模的時候，可以用平行的方式進行，pair modeling，讓一個member 處理dynamic-view UML interaction diagram, 另一個進行捕捉static-view class diagram，並且不時地讓兩者交換作業
- 用夠好的簡單地描述語詞來進行 uml 繪製，細部的uml 並不是重點，只要讓建模的人了解就可以，及盡可能的簡單並頻繁的使用UML elements.
- 要知道一件事情，那就是所有的models 都不會是最精確的，而最後產出的程式碼以及設計往往也是會與原先設計的模組有差距，但只有透過測試才能展示這正確的設計內容，其他的早先產出的圖像都只是功能的描繪敘述
- 開發者必須真的熟悉OO design modeling , 若還是用老舊的water-fall 開發方式那一切都沒意義了
2.9 Are there other critical UP practices ?
- Tackle high-risk and high-value issues in early iterations
- Continously engage users for evaluation, feedback, and requirements
- Build a cohesive, core architecture in early iterations
- Continuously verify quality, test early, often, and realistically
- Apply Use Cases where appropriate
- Do some visual modeling with the UML
- Carefully manage requirements
- Practice change request and configuration management
2.10 What are the UP Phases
- Inception approximate vision, business case, scope , vague estimates
- Elaboration refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates
- Construction iterative implementation of the remaining lower risk and easier elements, and preparation for deployment
- transition beta tests, deployment
Inception 並不適requirements階段的作業，比較近似於一個所謂"可行性"階段，這是比較像是說完成了一些問卷調查，
用來支援一些決策是否繼續進行。
總的來說，elaboration 不是requirements or design階段，比較近似於一個core architecture在迭代的實作過程，
而高風險的項目會被緩解(參考fig 2-6 , 2-7)。在UP中，implementation意味的是程式開發與建構系統，而非佈署 !!!
參考fig 2-8, 2-9 , 是本書的推薦規劃方式
2.11 What are the UP Disciplines
UP主要講述的是工作活動(work activities)，像是撰寫use case ，依循著UP的規則(discipline)來看的話，這是在一個主題領域(subject area)裡進行的一連串的活動來進行需求分析，在UP的角度來看的話，產出物將會有： Code , GUI , DB Schema , Text Documents , Diagrams , Models , and so on...
- Business Modeling - Domain Model 的主要產出，用來以視覺化方式呈現整個問題領域的概念
- Requirements - 用 Use Case Model 還有輔助的資訊來捕捉功能性與非功能性需求
- Design - 最後的階段，Design Model的產出，用來設計軟體物件
在UP的概念上，Implementation指的是實作programming 以及建構整個系統，而不是指佈署這件事情。當然對於佈署這件事情，也許我們可以把它放在是Environment的環節上來看。
這本書對於UP 的 Iteration的介紹是這樣：
- Inception階段 - 著重在需求分析
- Iteration 1 介紹標準的OOAD以及分配物件責任
- Iteration 2 著眼於物件設計，尤其是轉化為高可用性的pattern
- Iteration 3 將多種不同的主題概念，納入成為架構分析或框架設計
在 Table 2.1 的圖表很明確地描述出整個iteration phase 的焦點都放在哪!!
沒有留言:
張貼留言