第一部分：專案階段
第二部分：核心工作流程
第三部分：角色劃分
第四部分：目前實施專案規範的考慮
概述軟體開發的產品質量水平，是乙個由來已久的話題。而提高軟體企業的產品質量水平，必須改進軟體產品的開發過程。但是這裡沒有什麼百試百靈的靈丹妙藥，我們必須根據本企業的實際情況，參考國內外先進企業的經驗，總結出一種適合本企業的軟體開發模式。
此規範是基於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）。
圖中的陰影部分描述了不同的工作流，在不同的時間段內工作量的不同。值得注意的是，幾乎所有的工作流，在所有的時間段內均有工作量，只是大小不同而已。這與wate***ll process 有明顯的不同。
rup採用use case的概念，把要開發的系統根據各功能使用的情況劃分多個use case，並採用迭代的思想把系統的風險分布在四個階段，風險越大的迭代越要放在靠前的階段做，使軟體產品的風險不斷降低；而不是像傳統軟體工程那樣越往開發的後期問題越多。所以rup的思想一推出就受到軟體企業的歡迎。按照rup的開發模式一般可以達到cmm2、3級的水平。
當然，理解和掌握rup需要乙個相對較長的過程。
2. 核心工作流程
軟體工程中的工作流程分為兩部分：核心工作流程與核心支援工作流程
核心工作流程（在專案中的流程）
業務需求建模
分析設計
實施測試
部署核心支援工作流程（在組織中的流程）
環境專案管理
配置與變更管理
2.1. 業務需求建模
2.1.1. 目的
業務建模的目的在於：
了解目標組織（將要在其中部署系統的組織）的結構及機制。
了解目標組織中當前存在的問題並確定改進的可能性。
確保客戶、終端使用者和開發人員就目標組織達成共識。
匯出支援目標組織所需的系統需求。
為實現這些目標，業務建模工作流程說明了如何擬定新目標組織的前景，並基於該前景來確定該組織在業務用例模型和業務物件模型中的流程、角色以及職責。
作為對這些模型的補充，還編寫了以下文件：
補充業務規約
詞彙表2.1.2. 業務建模工作流程
2.1.3. 提供的文件與模型
商業邏輯建模（use case）（rose）
業務需求說明書（ms word）
專業詞彙表（英漢對照）（ms word）
風險說明（ms word）
複審說明書
2.1.4. 文件模板
參見專案管理規範目錄下業務需求文件模板子目錄
2.2. 分析設計
2.2.1. 目的
分析設計的目的在於：
將業務需求轉換為未來系統的設計。
逐步開發強壯的系統構架。
使設計適合於實施環境，為提高效能而進行設計。
2.2.2. 分析設計工作流程
2.2.3. 提供的文件與模型
系統總體設計報告（ms word）
系統設計模型domain model（rose）
系統設計模型design model （rose）
資料庫設計模型 （power designer）
資料字典（ms word）
系統詳細設計報告（ms word）
工作量化書（ms word）
2.2.4. 文件模板
參見專案管理規範目錄下分析設計文件模板子目錄
2.3. 實施
2.3.1. 目的
實施的目的包括：
對照實施子系統的分層結構定義**結構、
以構件（原始檔、二進位制檔案、可執行檔案以及其他檔案等）的方式實施類和物件、
對已開發的構件按單元來測試，並且
將各實施員（或團隊）完成的結果整合到可執行系統中。
實施工作流程的範圍僅限於如何對各個類進行單元測試。系統測試和整合測試將在測試工作流程中進行說明。
測試的目的在於：
核實物件之間的互動。
核實軟體的所有構件是否正確整合。
核實所有需求是否已經正確實施。
確定缺陷並確保在部署軟體之前將缺陷解決。
2.3.2. 實施工作流程
2.3.3. 提供的文件與模型
實施總結書（ms word）
實施模型（rose）
系統整合書（ms word）
**審核意見書（ms word）
源**（ms word）
使用者使用手冊（ms word）
錯誤解決記錄手冊（ms word）
構件及其說明
2.3.4. 文件模板
參見專案管理規範目錄下實施文件模板子目錄
2.4.專案管理
2.4.1. 目的
本部分的目標是，通過提供一些專案管理的環境，使這個任務更加容易完成。它雖然不是成功的秘訣，但它介紹了可以顯著提高成功交付軟體可能性的專案管理方法。
專案管理的目的是：
為對軟體密集型專案進行管理提供框架。
為專案的計畫、人員配備、執行和監測提供實用的準則。
為管理風險提供框架。
該工作流程主要側重於迭代式開發流程的以下重要方面：
風險管理
計畫迭代式專案，貫穿生命週期並針對特定的迭代
監測迭代式專案的進度、指標
2.4.2.專案管理工作流程
2.4.3. 提供的文件和模板
風險管理計畫（ms excel）
工作計畫書（ms excel）
風險列表（ms excel）
迭代計畫（ms excel）
問題解決計畫（ms excel）
測試計畫書（ms excel）
系統整合計畫書（ms excel）
子系統整合計畫書（ms excel）
工作單（ms excel）
產品驗收計畫（ms excel）
評測計畫（ms excel）
專案計畫複審意見書（ms word）
開發總結（ms word）
2.4.4. 文件模板
參見專案管理規範目錄下專案管理文件模板子目錄
2.5. 部署
2.5.1. 目的
部署工作流程用來描述那些為確保終端使用者可以正常使用軟體產品而進行的活動。
部署工作流程描述了兩種產品部署的模式：
自定義安裝
通過 inter*** 使用軟體
在每個例項中，都強調要在開發場所對產品進行測試，並在產品最終發布之前進行 beta 測試。 儘管部署活動主要集中於產品化階段，但在較早的一些階段中也會有一些為部署進行計畫和準備的活動。
2.5.2. 提供的文件和模板
部署計畫
安裝文件
發布說明
2專案管理規範RUP管理實施完整版
第一部分 專案階段第二部分 核心工作流程第三部分 角色劃分第四部分 目前實施專案規範的考慮 概述 軟體開發的產品質量水平，是乙個由來已久的話題。而提高軟體企業的產品質量水平，必須改進軟體產品的開發過程。但是這裡沒有什麼百試百靈的靈丹妙藥，我們必須根據本企業的實際情況，參考國內外先進企業的經驗，總結出...
專案管理規範
2015年x月x日 目錄1.編寫目的 2 2.適用範圍 2 3.文件規範 2 3.1 基本情況 2 3.2 文件命名規則 2 3.3 文件封面要求 3 3.4 修訂記錄要求 3 3.5 頁首 頁尾的要求 4 3.6 正文格式要求 4 3.7 新建文件要求 5 3.8 文件變更要求 5 3.9 其他要...
專案管理規範
中華人民共和國國家標準 gb t 50326 2005 建設工程專案管理規範 the code of construction project management 送審稿 200 發布200 實施 中華人民共和國建設部 聯合發布 國家質量監督檢驗檢疫總局 目次1 總則 2 術語 3 專案範圍管理 ...