文章目錄

• 二維模型
• 階段
• 初始階段
• 細化階段
• 構建階段
• 交付階段
• 階段工作
• 核心工作流
• 生命週期
• 目標里程碑
• 架構里程碑
• 能力里程碑
• 釋出里程碑
• 迭代標識
• 特點

二維模型

對於 UP 而言，時間主線就是橫軸的階段，隨著時間的流逝，軟體開發活動總要經過初始、細化、構建和交付這 4 個階段方能完成。而縱軸的工作流程則描述了在不同的階段需要進行的主要工作。例如在初始階段，軟體組織需要進行大量的調研，對軟體進行業務建模、需求，同時進行一些設計以驗證建模的合理性，還要進行一些實施甚至測試和部署的工作，用以驗證需求和設計的工作及開發系統原型，當然配置與變更管理、專案管理和環境是在任何階段都是不能缺少的。

階段

初始階段

開發者剛剛接入系統，此時最重要的工作是界定系統範圍，明確系統目的。在這一階段，業務建模和需求工作成了重頭戲。

細化階段

開發者需要抽象出軟體的邏輯模型，設計出軟體的架構，在這一階段，分析設計工作是最主要的工程活動。

構建階段

開發者需要基本完成系統的構建，使之成為一個完整的實體，並進行測試和部署，在這一階段，實施和測試是最主要的活動。

交付階段

該階段也經常被稱為轉移階段，軟體系統需求已經完全成熟或產品化，或進入下一個版本。在這一階段不可避免地要對軟體系統進行重構、修改、測試和部署。

階段工作

在這 4 個階段中，各有側重點，但也不是像瀑布模型那樣完全不允許其他活動的存在。在初始階段，為了驗證開發者的想法，就需要進行一部分的實施和測試；而即使到了交付階段，需要也可能會發生變化，仍然需要進行部分業務建模、需求和設計的活動。
在每個階段中，系統推進不是一蹴而就的。在圖中將細化階段劃分為第 1 次細化和第 2 次細化，將構建階段也劃分為 3 個小階段。在實際開發中，可以根據實際的需要劃分為更多的小階段來完成。

核心工作流

業務建模、需求、分析設計、實施、測試、部署、配置與變更管理、專案管理、環境稱為 UP 的 9 個核心工作流。可以把這 9 個工作流進行簡單的分類以幫助理解，業務建模、需求、分析設計、實施、測試和部署是工程活動，而配置與變更管理、專案管理和環境是管理活動。
在這 9 個工作流中，前 8 個可以說是絕大多數人都耳熟能詳的東西，而“環境”工作流則相對難以理解。“環境”工作流很重要，也可以稱之為“環境管理”。俗語說，“巧婦難為無米之炊”，“環境”工作流就是為軟體開發準備“米”的活動。在軟體開發中，需要為各種工作準備相應的工作環境，在工作環境中需要包含必需的工具、活動的指南、活動的流程規範、工作產品的模板、基本的開發設施等。在很多組織中，“環境”工作流沒有得到應有的重視，或者完全被忽視，以為為開發者提供了工作臺和計算機就萬事大吉了，其實這種做法是錯誤的。每一個開發團體都有自己特定的活動準則和規範，這些準則和規範是團體協作的基礎，萬萬少不得。沒有合理的工具配備，沒有充分的指南、規範和模板，軟體開發的活動肯定是放羊式的管理，管理者除了一些“羊毛”外什麼也收穫不到。觀察 UP 模型就可以發現，在每一階段的最開始，“環境”工作流都有一個小小的波峰。在這裡面，開發團隊需要為開發環境進行相應的準備並在後續活動中為開發環境提供支援。

生命週期

在 UP 的生命週期中共有 4 個里程碑

目標里程碑

目標里程碑對應著先啟階段的結束，當開發者可以明確軟體系統的目標和範圍時即達到了該里程碑。

架構里程碑

架構里程碑是 UP 生命週期中的第二個里程碑，在這個里程碑前，開發者需要確定穩定的系統架構。

能力里程碑

當系統已經足夠的穩定和成熟並完成 Alpha 測試後，認為達到了第3個里程碑。

釋出里程碑

在達到釋出里程碑前，需要完成系統的測試、完成系統釋出和使用者培訓等工作。

迭代標識

在經過這 4 個里程碑後，即為一個完整的生命週期，開發出一個新的版本。此時可以關閉該產品的開發，也可以迭代進入下一版本。

特點

• UP 是一個迭代的二維開發模型，在生命週期的每一階段都可以進行需求、設計等活動。UP 不但給出了迭代的生命週期，還給出了生命週期每一階段的迭代指南。
• 採用不同迭代方式的 UP 可以演變為演化模型或增量模型。
• UP 的迭代特點使得更容易控制軟體開發的風險。
• 雖然 UP 是一個迭代的開發模型，但 UP 本身並不屬於敏捷方法。相反，一般認為，未經裁減的 UP 是一個過載過程。
• 在實際應用中可以根據具體問題對 UP 進行裁減，從而使其可以適應各種規模的軟體和開發團隊。

架構設計師在 UP 中的活動

架構設計師在 UP 活動中承擔著非常重要的角色。在 UP 中，架構設計師除了需要建立系統架構模型外，還需要：
（1）同需求人員和專案管理人員密切協作。
（2）細化軟體架構。
（3）保持整個架構的概念完整性。具體地說，架構設計師不但需要設計系統架構，還需要定義設計方法、設計指南、編碼指南、評審設計等工作。因此，有人也稱 UP 是一個以架構為中心的開發模型。