這一章我們主要學習了團隊和流程。團隊簡而言之就是開發一個軟件工程的團隊，那麽團隊究竟怎樣在一起開發這一軟件便有了多種多樣的方法。

比如所有人都一起做的一窩蜂模式，但這樣模式弊端很大，雖然都做了許多工作，但結合起來的成果可能還沒有單人做的進度快。慢慢的發展出了一些其他的模式，比如我們在學校中，一個學霸主力，其他人打醬油，但這並不好。之後也出現了明星模式，社區模式等更好的模式

寫了再改模式：這種便是我們學生中最為普遍的一種模式。不管代碼怎麽樣，先寫出來，甚至連語法錯誤都沒有考究，整體做完後再針對問題進行修改。這種方法看似簡單，但實際並不高效，會在查找和修正錯誤上浪費許多時間。對於以後工作中，復用性高，規模打的軟件開發而言，這種模式顯然不合理。

瀑布模型：瀑布模式就像其他行業的流水線一樣，單向，有條理，規範性強，但它的不可逆性會很大程度上影響軟件的後期功能擴充和維護。但如果產品需求明確，並且開發把握度高的情況下，這種模式也是可以采用的。不過對於那些用戶需求不明確，需求擴展度較高的項目來說，采用瀑布模式就不能滿足開發需求

Rational統一流程，即後面的統一建模：統一建模是近年來發展起來的一種軟件設計模式，通過需求分析，建立多個模型，設計，最終實現軟件的開發，已經是一種較為成熟的軟件開發手段。它主要有以下四個階段：

初始階段——此階段的目標是分析軟件系統大概的構成，系統與外部系統的邊界在哪裏（我們的系統究竟和什麽別的外部實體打交道），大致的成本和預算是多少，系統的風險主要來自哪裏。成功度過初始階段的項目會達到生命周期目標（LifecycleObjective）裏程碑

細化階段——它的目標是分析問題領域，建立健全的體系結構基礎，編制項目計劃，按優先級處理項目中的風險。團隊要確定項目的具體範圍、主要功能、性能、安全性、可擴展性等非功能需求。同時為項目建立支持環境，包括創建開發案例、創建模板並準備工具。細化階段結束時，項目到達了第二個重要的裏程碑：生命周期結構（Lifecycle Archi-tecture）裏程碑

構造階段——在這一階段，團隊開發出所有的功能集，並有秩序地把功能集成為經過各種測試驗證過的產品。構造階段結束時是第三個重要的裏程碑：初始功能（Initial Operational）裏程碑。此時的產品版本也常被稱為“beta”版

交付階段——這時候，團隊工作的重點是確保軟件能滿足最終用戶的實際需求。交付階段可以有叠代（beta1，beta2等），基於用戶的反饋，團隊利用這些叠代對系統進行修改、調整。除了對功能的調整，團隊還要註意處理用戶設置、安裝和可用性等問題。在交付階段的終點是第四個裏程碑：產品發布（Product Release）裏程碑

構建之法第五章讀書心得