第二部分：核心工作流程
第三部分：角色劃分
第四部分：目前實施項目規范的考慮
概述
軟件開發的產品質量水平，是一個由來已久的話題。而提高軟件企業的產品質量水平，必須改進軟件產品的開發過程。但是這里沒有什么百試百靈的靈丹妙藥，我們必須根據本企業的實際情況，參考國內外先進企業的經驗，總結出一種適合本企業的軟件開發模式。
此規范是基于CMM模型規范，以RUP軟件工程過程為藍本，由我本人根據項目實際情況而選擇修改，從而使之適應當前應用級系統設計開發的需要。
本文主要以RUP的軟件工程框架為主，省略復雜概念部分。著眼點放在控制軟件產品開發流程上，由于人員配置與軟件分工現行狀況的限制，對其中的部分細節進行了合并可省略，從而適應目前國內軟件開發所要求。
Rational Unified Process（簡稱RUP）是一套軟件工程過程（在下面介紹）。
在RUP過程中，我們可以看到它非常強調一點：循環。
現在我們做的每一個項目都存在不斷變化的問題。用戶需求變化、系統設計變化（可能是需求變化也可能是存在了技術問題）、編碼變化（由測試與復審等環節引發的）等問題困擾著項目進行。解決這些問題的方法就是不斷的循環。
這個規范是我根據自己的觀點整理編寫而成的，有不足之處請指教。
RUP簡介
Rational Unified Process（簡稱RUP）是一套軟件工程過程，主要由Ivar Jacobson的 The Objectory Approch 和 The Rational Approch 發展而來。同時，它又是文檔化的軟件工程產品，所有RUP 的實施細節及方法導引均以Web文檔的方式集成在一張光盤上，由Rational公司開發、維護并銷售，當前版本是RUP2000。RUP又是一套軟件工程方法的框架，各個組織可根據自身的實際情況，以及項目規模對RUP進行裁剪和修改，以制定出合乎需要的軟件工程過程。
RUP 吸收了多種開發模型的優點，具有很好的可操作性和實用性、從它一推出市場，憑借Booch、Ivar Jacobson、以及Rumbaugh 在業界的領導地位、以及與統一建模語言（Unified Model Language , 以下簡稱UML）的良好集成、多種CASE工具的支持、不斷的升級與維護，迅速得到業界廣泛的認同，越來越多的組織以它作為軟件開發模型框架。
在RUP中，軟件開發生命周期根據時間和RUP的核心工作流劃分為二維空間。
如上圖所示，時間維從組織管理的角度描述整個軟件開發生命周期，是RUP的動態組成部分。它可進一步描述為周期（Cycle）、階段（phase）、迭代(Iteration)。
核心工作流從技術角度描述RUP的靜態組成部分，它可進一步描述為行為（activities）、工作流（workflow）、產品（artifact）、工人（worker）。
圖中的陰影部分描述了不同的工作流，在不同的時間段內工作量的不同。值得注意的是，幾乎所有的工作流，在所有的時間段內均有工作量，只是大小不同而已。這與Waterfall process 有明顯的不同。
RUP采用Use Case的概念，把要開發的系統根據各功能使用的情況劃分多個Use Case，并采用迭代的思想把系統的風險分布在四個階段，風險越大的迭代越要放在靠前的階段做，使軟件產品的風險不斷降低；而不是像傳統軟件工程那樣越往開發的后期問題越多。所以RUP的思想一推出就受到軟件企業的歡迎。按照RUP的開發模式一般可以達到CMM2、3級的水平。當然，理解和掌握RUP需要一個相對較長的過程。
1. 項目階段
從管理的觀點來說，軟件生命周期隨著時間分為四個依次進行的階段，每個階段的結束都有一個主要里程碑；實質上，每個階段就是兩個主要里程碑之間的時間跨度。在每個階段結束時進行評估，以確定是否實現了此階段的目標。良好的評估可使項目順利進入下一階段。
1.1. 計劃階段
在進度和工作量方面，所有階段都各不相同。盡管不同的項目有很大的不同，但一個中等規模項目的典型初始開發周期應該預先考慮到工作量和進度間的分配：
| 先啟 | 精化 | 構建 | 產品化 | |
| 工作量 | ~5% | 20% | 65% | 10% |
| 進度 | 10% | 30% | 50% | 10% |
對于演進周期，先啟和精化階段就小得多了。能夠自動完成某些構建工作的工具將會緩解此現象，并使得構建階段比先啟階段和精化階段的總和還要小很多。
通過這四個階段就是一個開發周期；每次經過這四個階段就會產生一代軟件。除非項目“死亡”，否則通過重復同樣的先啟階段、精化階段、構建階段和產品化階段的順序，產品將演進為下一代產品，但每一次的側重點都將放在不同的階段上。這些隨后的周期稱為演進周期。 隨著產品經歷了幾個周期，新一代產品隨之產生。
1.2. 先啟階段
1.2.1. 目標
先啟階段的基本目標是實現項目的生命周期目標中所有相關因素（如客戶等）之間的并行。 先啟階段主要對新的開發工作具有重大意義，新工作中的重要業務風險和需求風險問題必須在項目繼續進行之前得到解決。對于重點是擴展現有系統的項目來說，先啟階段較短，但重點仍然是確保項目值得進行而且可以進行。
先啟階段的主要目標包括：
· 建立項目的軟件規模和邊界條件，包括運作前景、驗收標準以及希望軟件中包括和不包括的內容。
· 識別系統的關鍵用例（也就是將造成重要設計折衷操作的主要部分）。
· 評估整個項目的總體成本和進度（以及對即將進行的精化階段進行更詳細的評估）
· 評估潛在風險（不可預測性的來源）
· 準備項目的支持環境。
1.2.2. 核心活動
· 明確地說明項目規模。這涉及了解環境以及最重要的需求和約束，以便于可以得出最終產品的驗收標準。
· 計劃和準備商業理由。評估風險管理、人員配備、項目計劃和成本/進度/收益率折衷的備選方案。
· 綜合考慮備選構架，評估設計和自制/外購/復用方面的折衷，從而估算出成本、進度和資源。此處的目標在于通過對一些概念的證實來證明可行性。該證明可采用可模擬需求的模型形式或用于探索被認為高風險區域的初始原型。先啟階段的原型設計工作應該限制在確信解決方案可行就可以了。該解決方案在精化和構建階段實現。
· 準備項目的環境，評估項目和組織，選擇工具，決定流程中要改進的部分。
1.2.3. 里程碑：生命周期目標
生命周期目標里程碑評估項目的基本可行性。
先啟階段末是第一個重要的項目里程碑，即生命周期目標里程碑。此時，檢查項目的生命周期目標，并決定繼續進行項目還是取消項目。
1.2.3.1 評估標準
· 規模定義和成本／進度估算中，所有相關因素（如客戶等）可并行
· 對是否已經獲得正確的需求集達成一致意見，并且對這些需求的理解是共同的。
· 對成本／進度估算、優先級、風險和開發流程是否合適達成一致意見。
· 已經確定所有風險并且有針對每個風險的減輕風險策略。
如果項目無法達到該里程碑，則它可能中途失敗或需要進行相當多的重新考慮。
1.2.3.2 提供的文檔及模型
| 核心文檔及模型（按照重要性排序） | 里程碑狀態 |
| 前景 | 已經對核心項目的需求、關鍵功能和主要約束進行了記錄。 |
| 商業理由 | 已經確定并得到了批準。 |
| 風險列表 | 已經確定了最初的項目風險。 |
| 軟件開發計劃 | 已經確定了最初階段及其持續時間和目標。軟件開發計劃中的資源估算（特別是時間、人員和開發環境成本）必須與商業理由一致。 資源估算可以涵蓋整個項目直到交付所需的資源，也可以只包括進行精化階段所需的資源。此時，整個項目所需的資源估算應該看作是大致的“粗略估計”。該估算在每個階段和每次迭代中都會更新，并且隨著每次迭代變得更加準確。 根據項目的需要，可能在某種條件下完成了一個或多個附帶的“計劃”工件。此外，附帶的“指南”工件通常也至少完成了“草稿”。 |
| 迭代計劃 | 第一個精化迭代的迭代計劃已經完成并經過了復審。 |
| 軟件驗收計劃 | 完成復審并確定了基線；隨著其他需求的發現，將對其在隨后的迭代中進行改進。 |
| 項目專用模板 | 已使用文檔模板制作了文檔工件。 |
| 用例建模指南 | 確定了基線。 |
| 工具 | 選擇了支持項目的所有工具。安裝了對先啟階段的工作必要的工具。 |
| 詞匯表 | 已經定義了重要的術語；完成了詞匯表的復審。 |
| 用例模型（主角，用例） | 已經確定了重要的主角和用例，只為最關鍵的用例簡要說明了事件流。 |
| 領域模型（也叫做業務對象模型） | 已經對系統中使用的核心概念進行了記錄和復審。在核心概念之間存在特定關系的情況下，已用作對詞匯表的補充。 |
| 原型 | 概念原型的一個或多個證據，以支持前景和商業理由、解決非常具體的風險。 |
1.3.1. 目標
精化階段的目標是建立系統構架的基線，以便為構建階段的主要設計和實施工作提供一個穩定的基礎。構架是基于對大多數重要需求（對系統構架有很大影響的需求）的考慮和風險評估發展而來的。構架的穩定性是通過一個或多個構架原型進行評估的。 精化階段的主要目標包括：
確保構架、需求和計劃足夠穩定，充分減少風險，從而能夠有預見性地確定完成開發所需的成本和進度。對大多數項目來說，通過此里程碑也就相當于從簡單快速的低風險運作轉移到高成本、高風險的運作，并且在組織結構方面面臨許多不利因素。
處理在構架方面具有重要意義的所有項目風險
建立一個已確定基線的構架，它是通過處理構架方面重要的場景得到的，這些場景通�？梢燥@示項目的最大技術風險。
制作產品質量構件的演進式原型，也可能同時制作一個或多個可放棄的探索性原型，以減小特定風險，例如：
設計/需求折衷
構件復用
產品可行性或向客戶和最終用戶進行演示。
證明已建立基線的構架將在適當時間、以合理的成本支持系統需求。
建立支持環境。
為了實現這個主要目標，建立項目的支持環境也同等重要。這包括創建開發案例、創建模板和指南、安裝工具。
1.3.2. 核心活動
· 快速確定構架、確認構架并為構架建立基線。
· 根據此階段獲得的新信息改進前景，對推動構架和計劃決策的最關鍵用例建立可靠的了解。
· 為構建階段創建詳細的迭代計劃并為其建立基線。
· 改進開發案例，定位開發環境，包括流程和支持構建團隊所需的工具和自動化支持。
· 改進構架并選擇構件。 評估潛在構件，充分了解自制/外購/復用決策，以便有把握地確定構建階段的成本和進度。集成了所選構架構件，并按主要場景進行了評估。通過這些活動得到的經驗有可能導致重新設計構架、考慮替代設計或重新考慮需求。
1.3.3. 里程碑：生命周期構架
生命周期構架里程碑為系統構架建立管理基線，并使項目團隊能夠在構建階段調整規模。
精化階段末是第二個重要的項目里程碑，即生命周期構架里程碑。此時，您檢查詳細的系統目標和規模、選擇的構架以及主要風險的解決方案。
1.3.3.1 評估標準
· 產品前景和需求是穩定的。
· 構架是穩定的。
· 可執行原型表明已經找到了主要的風險元素，并且得到妥善解決。
· 構建階段的迭代計劃足夠詳細和真實，可以保證工作繼續進行。
· 構建階段的迭代計劃由可靠的估算支持。
· 所有客戶方人員一致認為，如果在當前構架環境中執行當前計劃來開發完整的系統，則當前的前景可以實現。
· 實際的資源耗費與計劃的耗費相比是可以接受的。
如果項目無法達到該里程碑，則它可能中途失敗或需要進行相當多的重新考慮。
1.3.3.2 提供的文檔及模型
| 核心文檔及模型（按照重要性排序） | 里程碑狀態 |
| 原型 | 已經創建了一個或多個可執行構架原型，以探索關鍵功能和構架上的重要場景。 |
| 風險列表 | 已經進行了更新和復審。 新的風險可能是構架方面的，主要與處理非功能性需求有關。 |
| 項目專用模板 | 已使用文檔模板制作了文檔工件。 |
| 工具 | 已經安裝了用于支持精化階段工作的工具。 |
| 軟件構架文檔 | 編寫完成并確定了基線，如果系統是分布式的或必須處理并行問題，則包括構架上重要用例的詳細說明（用例視圖）、關鍵機制和設計元素的標識（邏輯視圖），以及（部署模型的）進程視圖和部署視圖的定義。 |
| 設計模型（和所有組成部分） | 制作完成并確定了基線。已經定義了構架方面重要場景的用例實現，并將所需行為分配給了適當的設計元素。 已經確定了構件并充分理解了自制/外購/復用決策，以便有把握地確定構建階段的成本和進度。集成了所選構架構件，并按主要場景進行了評估。通過這些活動得到的經驗有可能導致重新設計構架、考慮替代設計或重新考慮需求。 |
| 數據模型 | 制作完成并確定了基線。已經確定并復審了主要的數據模型元素（例如重要實體、關系和表）。 |
| 實施模型（以及所有組成工件，包括構件） | 已經創建了最初結構，確定了主要構件并設計了原型。 |
| 前景 | 已經根據此階段獲得的新信息進行了改進，對推動構架和計劃決策的最關鍵用例建立了可靠的了解。 |
| 軟件開發計劃 | 已經進行了更新和擴展，以便涵蓋構建階段和產品化階段。 |
| 指南，如設計指南和編程指南。 | 使用指南對工作進行了支持。 |
| 迭代計劃 | 已經完成并復審了構建階段的迭代計劃。 |
| 用例模型 | 用例模型（大約完成 80%）- 已經在用例模型調查中確定了所有用例、確定了所有主角并編寫了大部分用例說明（需求分析）。 |
| 補充規約 | 已經對包括非功能性需求在內的補充需求進行了記錄和復審。 |
| 可選 | 里程碑狀態 |
| 商業理由 | 如果構架調查不涵蓋變更基本項目假設的問題，則已經對商業理由進行了更新。 |
| 分析模型 | 可能作為正式工件進行了開發；進行了經常但不正式的維護，正演進為設計模型的早期版本。 |
| 培訓材料 | 用戶手冊與其他培訓材料。根據用例進行了初步起草。 如果系統具有復雜的用戶界面，可能需要培訓材料。 |
1.4.1. 目標
構建階段的目標是闡明剩余的需求，并基于已建立基線的構架完成系統開發。構建階段從某種意義上來說是一個制造過程，在此過程中，重點在于管理資源和控制操作，以便優化成本、進度和質量。從這種意義上說，從先啟和精化階段到構建和產品化階段，管理上的思維定勢經歷了從知識產權開發到可部署產品開發的轉變。 構建階段的主要目標包括：
· 通過優化資源和避免不必要的報廢和返工，使開發成本降到最低。
· 快速達到足夠好的質量
· 快速完成有用的版本（Alpha 版、Beta 版和其他測試發布版）
· 完成所有所需功能的分析、開發和測試。
· 迭代式、遞增式地開發隨時可以發布到用戶群的完整產品。這意味著描述剩余的用例和其他需求，充實設計，完成實施，并測試軟件。
· 確定軟件、場地和用戶是否已經為部署應用程序作好準備。
· 開發團隊的工作實現某種程度的并行。 即使是較小的項目，也通常包括可以相互獨立開發的構件，從而使各團隊之間實現自然的并行（資源允許）。這種并行性可較大幅度地加速開發活動；但同時也增加了資源管理和工作流程同步的復雜程度。如果要實現任何重要的并行，強壯的構架至關重要。
1.4.2. 核心活動
· 資源管理，控制和流程優化
· 完成構件開發并根據已定義的評估標準進行測試
· 根據前景的驗收標準對產品發布版進行評估。
1.4.3. 里程碑：最初操作性能
最初操作性能里程碑確定產品是否已經可以部署到 Beta 測試環境。
在最初操作性能里程碑，產品隨時可以移交給產品化團隊。此時，已開發了所有功能，并完成了所有 Alpha 測試（如果有測試）。除了軟件之外，用戶手冊也已經完成，而且有對當前發布版的說明。
1.4.3.1 評估標準
構建階段的評估標準涉及到對以下問題的回答：
· 該產品發布版是否足夠穩定和成熟，可部署在用戶群中？
· 是否已準備好將產品發布到用戶群？
· 實際的資源耗費與計劃的相比是否仍可以接受？
如果項目無法達到該里程碑，產品化可能要推遲一個發布版。
1.4.3.2 提供的文檔及模型
| 核心文檔及模型（按照重要性排序） |
里程碑狀態 |
| “系統” | 可執行系統本身隨時可以進行“Beta”測試。 |
| 部署計劃 | 已開發最初版本、進行了復審并建立了基線。 |
| 實施模型（以及所有組成部分，包括構件） | 對在精化階段創建的模型進行了擴展；構建階段末期完成所有構件的創建。 |
| 測試模型（和所有組成部分） | 為驗證構建階段所創建的可執行發布版而設計并開發的測試。 |
| 培訓材料 | 用戶手冊與其他培訓材料。根據用例進行了初步起草。 如果系統具有復雜的用戶界面，可能需要培訓材料。 |
| 迭代計劃 | 已經完成并復審了產品化階段的迭代計劃。 |
| 設計模型（和所有組成部分） | 已經用新設計元素進行了更新，這些設計元素是在完成所有需求期間確定的。 |
| 項目專用模板 | 已使用文檔模板制作了文檔模板。 |
| 工具 | 已經安裝了用于支持構建階段工作的工具。 |
| 數據模型 | 已經用支持持續實施所需的所有元素（例如，表、索引、對象關系型映射等）進行了更新 |
| 可選 | 里程碑狀態 |
| 補充規約 | 已經用構建階段發現的新需求（如果有）進行了更新。 |
| 用例模型（主角，用例） | 已經用構建階段發現的新用例（如果有）進行了更新。 |
1.5.1. 目標
產品化階段的重點是確保最終用戶可以使用軟件。產品化階段可跨越幾個迭代，包括測試處于發布準備中的產品和基于用戶反饋進行較小的調整。在生命周期中的該點處，用戶反饋應主要側重于調整產品、配置、安裝和可用性問題，所有較大的結構上的問題應該在項目生命周期的早期階段就已得到解決。 在產品化階段生命周期結束時，目標應該已經實現，項目應處于將結束的狀態。某些情況下，當前生命周期的結束可能是同一產品另一生命周期的開始，從而導致產生產品的下一代或下一版本。對于其他項目，產品化階段結束時可能就將文檔與模型完全交付給第三方，第三方負責已交付系統的操作、維護和擴展。
根據產品的種類，產品化階段可能非常簡單，也可能非常復雜。例如，發布現有桌面產品的新發布版可能十分簡單，而替換一個國家的航空交通管制系統可能就非常復雜。
產品化階段的迭代期間所進行的活動取決于目標。例如，在進行調試時，實施和測試通常就足夠了。 但是，如果要添加新功能，迭代類似于構建階段中的迭代，需要進行分析設計。
當基線已經足夠完善，可以部署到最終用戶領域中時，則進入產品化階段。通常，這要求系統的某個可用部分已經達到了可接受的質量級別并完成用戶文檔，從而向用戶的轉移可以為所有方面都帶來積極的結果。
產品化階段的主要目標是：
· 進行 Beta 測試，按用戶的期望確認新系統
· Beta 測試和相對于正在替換的遺留系統的并行操作
· 轉換操作數據庫
· 培訓用戶和維護人員
· 市場營銷、進行分發和向銷售人員進行新產品介紹
· 與部署相關的工程，例如接入、商業包裝和生產、銷售介紹、現場人員培訓
· 調整活動，如進行調試、性能或可用性的增強
· 根據產品的完整前景和驗收標準，對部署基線進行的評估
· 實現用戶的自我支持能力
· 在用戶之間達成共識，即部署基線已完成
· 在用戶之間達成共識，即部署基線與前景的評估標準一致
1.5.2. 核心活動
· 執行部署計劃
· 對最終用戶支持材料定稿
· 在開發現場測試可交付產品
· 制作產品發布版
· 獲得用戶反饋
· 基于反饋調整產品
· 使最終用戶可以使用產品
1.5.3. 里程碑：產品發布
產品化階段末是第四個重要的項目里程碑，即產品發布里程碑。此時，您確定是否達到目標，以及是否應該開始另一個開發周期。有時候，該里程碑可能與下一周期的先啟階段末重合。產品發布里程碑是項目驗收復審成功完成的結果。
1.5.3.1 評估標準
產品化階段的主要評估標準涉及到對以下問題的回答：
· 用戶是否滿意？
· 實際的資源耗費與計劃的耗費相比是否可以接受？
在產品發布里程碑處，發布后的維護周期同時開始。這涉及開始一個新的周期，或某個其他的維護發布版。
1.5.3.2 提供的文檔及模型
| 核心文檔及模型（按照重要性排序） | 里程碑狀態 |
| 產品工作版本 | 已按照產品需求完成�？蛻魬摽梢允褂米罱K產品。 |
| 發布說明 | 完成。 |
| 安裝產品與模型 | 完成。 |
| 培訓材料 | 完成，以確�？蛻糇约嚎梢允褂煤途S護產品。 |
| 最終用戶支持材料 | 完成，以確�？蛻糇约嚎梢允褂煤途S護產品。 |
| 可選 | 里程碑狀態 |
| 測試模型 | 在客戶想要進行現場測試的情況下，可以提供測試模型。 |
文章來源于領測軟件測試網 http://www.kjueaiud.com/
