第二章 開發流程
反覆式開發風格則是根據不同的功能性子集合將項目分解開來。你可以把一年的項目分解成每次長達三個月的反覆。在第一次反覆中，我們會處理約1/4的需求，並且將者1/4的需求走完整個軟件開發的生命週期：分析、設計、編碼和測試。在反覆結束出，我們會喲偶完成1/4所需功能性的系統。接下來，我們會進行第二次反覆，它會在第6個月結束。
UML是從一大推面向對象分析與設計的方法論中所誕生出來的。在某種程度範圍內，這些方法論都會在圖形模型語言中混合某種開發流程，以說明軟件該如何開發下去。
1.反覆式和瀑布式的開發流程
兩者的本質差異在於：我們該如何把項目分解成一些比較小的部分。我們需要把項目加以分解，這樣一來大家就可以隨時掌握問題，並追蹤進度。
瀑布式開發風格是根據開發活動來分解項目的。爲了編寫軟件，你需要進行一些特定的開發活動，包括：需求分析、設計、編程與測試。如果是一年的時間需要如下分配：
| 分析階段 | 設計階段 | 編碼階段 | 測試階段 |
| 2個月 | 4個月 | 3個月 | 3個月 |
反覆式開發風格則是根據不同的功能性子集合將項目分解開來。你可以把一年的項目分解成每次長達三個月的反覆。在第一次反覆中，我們會處理約1/4的需求，並且將者1/4的需求走完整個軟件開發的生命週期：分析、設計、編碼和測試。在反覆結束出，我們會喲偶完成1/4所需功能性的系統。接下來，我們會進行第二次反覆，它會在第6個月結束。
你可以採用混合式的解決方案，【McMconnel】一書中描述了一種分期交付式生命週期，它會先以瀑布式開發風格完成分析與高階的設計工作，然後將編程序與測試工作分成幾次反覆。以一年的項目爲例：它可能會有長達4個月的分析與設計工作，然後以4次長達2個月的反覆來建構出系統。
OO社羣長久以來一直偏好反覆式開發方式，而且我們可以放心大膽地說有非常多跟建立UML有關的人，至少都偏好某種形式的反覆式開發關係。
雖然大家都宣稱正在採用反覆式開發方式，不過實際上卻是按照瀑布式的方法在做。常見的特徵有：
A、我們現在正在進行一次分析反覆，接下來會有兩次的設計反覆。。。。
B、這次的反覆的程序中有許多程序bug，不過我們最後將會把它們都清除乾淨。
評註：由於反覆式開發希望在反覆結束之後，可以產生具備產品品質、測試、整合過的軟件出來。所以如果反覆結束之後，程序中有許多bug，就不能說反覆結束。另一方面，這點反而像是瀑布式開發流程中編寫代碼開發階段結束，下一步準備進行測試開發階段。
採用反覆式開發方式時常會用到的一種開發技術就是固定時間長度（time boxing）。它讓每次反覆都有固定長度的時間。如果你發現原本在某次反覆中想要建構的部分無法完全做完的話，那麼你必須決定要在這次反覆中將某些功能延遲處理；而不是將這次反覆的結束日期延後。
如果大家能夠經常性的將系統功能延後處理，那麼等到他們面對大的發行版本、需要對延後日期或功能做出明確抉擇時，就會有較好的經驗來處理它。另一方面，在反覆間延後處理某些功能，可有效幫大家學習如何找到真正的需求優先順序。
對犯法是開發方式來說，最常見的考量之一就是重寫編碼的議題。重寫程序比維護那些設計不好的程序更有效率。下面列出一些實際經驗，它們非常有助於讓重做變得更加有效率。
| 自動化的迴歸測試（automated resgression tests） | 當我們正在改變一些東西時，它有助於我們快速偵測到任何程序的瑕疵：單元測試有一條不錯的經驗法則就是，單元測試的程序代碼大小大約跟你的產品程序代碼相當 |
| 重構（refactoring） | 它是以有紀律方式改變現有軟件的一項開發方式。重構是將一連串小的、保留行爲的轉換動作施行到程序代碼庫的工作方式。 |
| 持續整合（continuous integration） | 它能讓整個團隊保持同步，以避免痛苦的整合週期。這種做法的核心是已完全自動haunt的建構流程爲基礎達到的。 |
2、預測式和自適應的規劃方式
預測式的解決方案想在項目初期做一些事，以便可以更加了解稍後會發生的事。採用預測式規劃方式時，我們可以把項目區分成兩個時期。在第一個時期，我們會先想出一個計劃，這時候計劃書是比較難預測的。不過，等到第二個時期，因爲計劃書已經在實施當中了，所以他就變的比較容易預測。
在軟件項目中，增加它的複雜度的其中一個獨特來源就是我們很難了解軟件系統的需求爲何。絕大多數項目都會經歷重大的需求劇烈變動：在項目後期發生需求變動。這些變動會撼動真個預測計劃的基礎。
評註：需求變動是所有軟件開發者心中的疼
另一種流派主張需求劇烈變動是不可避免的事。對許多項目來說，我們幾乎不可能讓需求穩定到可使用預測計劃。一方面是因爲單憑想象就要知道軟件能做什麼是一件極度困難的事，另一方面則是因爲市場環境會造成不可預測的變動。採用這個想法的流派倡導自適應規劃方式，可預測被他們視爲幻影。他們採用規劃方式會將軟件項目中的變動視爲一種常態。他們以控制變動的方式讓項目交出它所能做出來的最佳軟件；我們雖然會去掌控項目，不過，卻不認爲它是可預測的。
評註：自適應將計劃驅動的流程縮短以爲數週爲單位的循環週期，在每一個週期中，我們根據當前的情況不斷地調整計劃以及計劃的執行過程，同時不斷地產生能夠工作的代碼，並且不斷地將代碼部署到應用環境中去。
對比兩種方式，有兩點建議：
A、除非你有一份精確、穩定的需求，而且有把握他們不會發生顯著變動，要不然請不要做出一份預測性計劃
B、如果你無法獲得一份精確、穩定的需求，那麼採用自適應的規劃風格。
3、敏捷開發流程
敏捷開發流程本質上具有很強的自適應性。同時他們也是非常具有人員導向的開發流程。敏捷開發解決方案假設項目成功的最重要因素在於項目成員的職業素質，以及在人際關係上他們合作的情況究竟如何。至於他們所使用的開發流程或開發工具嚴格來說都只有次一級的效果。
評註：敏捷開發以用戶的需求進化爲核心，採用迭代、循序漸進的方法進行軟件愛你開發。在敏捷開發中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果多經過測試，具備可視、可集成和可運行使用的特徵。從這個定義我們就可以理解上面的那段話了，當一個項目被切換成一個個小項目時，如果某個開發人員負責的項目不夠穩定，就會出現“木桶效應”；如果一旦某幾個成員對項目不能夠完全理解，後期就會花費大量的時間用於整合。
4、Rational統一開發流程
RUP雖然被稱爲開發流程，不過事實上他是一個開發流程框架，裏面提供跟開發流程有關的一整組字彙與鬆散的結構
當你在使用RUP時，你要做的第一件事就是選出自己的開發案例：它是你在項目中將會施行的開發流程。開發案例間的變異很大，所以不要奢望你的開發案例看起來會跟其他開發案例很像。
RUP本質都是反覆式開發流程。瀑布式開發風格並不符合RUP的精神。
所有RUP項目必須遵循下面四個開發階段：
（1）、初始階段（inception）:它會對項目作出一個最初的評估結果。
（2）、詳述階段（elaboration）:它會找出項目的主要使用案例，並且會在幾次反覆中寫出軟件，以並讓系統的架構成型。在詳述階段結束結束時，你應該對需求有很好的體會，而且回一個大致上成形、可運行的系統，我們將把它當做後續開發工作的源頭。
（3）、構建階段（construction）：它會繼續進行寫軟件的過程，寫出發行出去的功能性。
（4）、移交階段（transition）:裏面會有各式各樣後期、不需要反覆進行的開發活動，可能會包含將軟件配置到資料中心、使用者訓練等等類似的事項。
評註：完成這4個階段稱爲一個開發週期，它產生的軟件稱作第一代。除非生命結束，一個現有剷平可以通過重複下一個相同的起始、詳述、構建和移交四階段，各個階段的側重點與第一次不同，從而演進爲下一代產品。這個時期我們稱之爲演進（evolution）。最後伴隨着產品經過幾個週期的演進，新一代產品不斷被製造出來。
詳細可參考：http://www.ibm.com/developerworks/cn/rational/r-rudp/點擊打開鏈接
5、裁減開發流程以適合項目需要
軟件開發工作的進行方式會受到許多因素影響。因此我們總需要將開發流程加以裁減，以適合項目的特殊環境需要。
評註：模式——UML可以告訴我們該如何表達出面向對象設計的結果。相反地，從模式所看到的開發流程所得到的結果：它們可用來作爲範例的設計結果。
模式不僅僅只包含一個模型而已，裏面也包括了採用這種做法的理由究竟爲何。我們通常會說模式代表他對某種設計問題的解決方案。模式中必須清楚地點出問題所在、解釋它解決問題的理由，也會說明什麼環境下，我們可採用或不能採用這個模式。
模式之所以很重要，是因爲他們是理解一種語言或模型技術的下一步。
6、在開發流程中使用UML
不論你是不是採用瀑布式解決方案，我們都依然會做分析、設計、編碼與測試等開發活動。你可以在具有一個星期長反覆的反覆式項目中，每個星期施行一次微型的瀑布式開發流程。
需求分析
在需求分析開發活動中，我們會試圖瞭解：針對我們將花費功夫的軟件，它的使用者與顧客究竟想要系統做些什麼事。與其相關的UML現有相關技術：
A.使用案例（use case），我們會在裏面描述人們是如何跟系統互動的。
B.由概念性觀點所畫出來的類別圖（class diagram）,它是我們可拿出來建構領域中一組精確字彙的好方法。
c.活動圖（activity diagram），裏面可秀出組織的工作流程，以瞭解軟件跟人類活動間是如何互動的。
D.狀態圖（state diagram）,如果某個概念具有一種有趣的聲明週期時，它就會變得有用，裏面會秀出各種狀態以及改變狀態的事件。
在進行需求分析時，請記住，其中最重要的一件事是跟你的使用者與顧客溝通。
在分析時用UML的最大風險就是：那些領域專家無法完全理解你所畫出的圖。如果瞭解領域的人武大理解這張圖，那麼它所造成的後果比沒有用更糟；因爲它會引起大家對開發團隊的不信任感。
設計
當你在進行設計工作時，你可以在圖中加入更多技術細節。一些相關技術包括：
A、由軟件觀點所畫出的類別圖，裏面會秀出軟件中的類別，以及他們間是如何相關的。
B、常見情節的時序圖（sequence diagram）。一種很有價值的做法是從使用案例中找出最重要、最有趣的情節，然後用CRC卡（CRC card）或時序圖畫出軟件中會發生什麼情形。
C、用打包圖（package diagram）畫出軟件中大型結構的組織方式。
D、針對有複雜生命歷程的類別，畫出他們的狀態圖
E、用配置圖（deployment diagram）畫出軟件的實體安排情形。
不論是下藍圖或草稿做法，找尋設計上的一些替代方案，這對我們來說都是有意義的事。我們通常最好是在草稿模式下探索這些不同替代方案，因爲它可讓我們快速產生這些替代方案，並修改它們。
文檔
一旦你寫好軟件之後，你可以用UML來幫你記錄下來什麼東西已經完成。針對這點，我發現UML的圖有助於大家對系統產生一個整體瞭解。寫文檔的人需要決定什麼東西重要、什麼不是，不過寫的人通常會比讀此書的人具備更好知識，足以做出這樣的判斷。
7、瞭解前人所遺留的程序
UML可以用一兩種方式來幫你理解一大推不熟悉的程序。體關鍵事物畫出草圖這種做法可當成一種推行的筆記機制，他可以在你學習這些程序時，幫你記下一些重要資訊。