軟體開發一個複雜的活動 , 它包含了需求調研 , 系統設計 , 開發 , 部署 , 維護等活動 .  而且現有規範和流程目的並不是讓你去完成文件 ,  而是通過這些文件 , 讓軟體的質量更能得到保證。組成軟體開發和系統演化的活動有著各種模型 ( 軟體生存週期，軟體開發模型，軟體過程 ) ，但是典型地都包含了以下的過程或活動：分析、設計、實現、確認 ( 測試驗收 ) 、產品化、維護。

軟體開發方法的一般要求：當提出一種軟體開發方法時，應該考慮許多因素，包括：

①      覆蓋開發全過程，並且便於在各階段間的過渡；

②      便於在開發各階段中有關人員之間的通訊；

③      支援有效的解決問題的技術

④      支援系統設計和開發的各種不同途徑

⑤      在開發過程中支援軟體正確性的校驗和驗證；

⑥      便於在系統需求中列入設計、實際和效能的約束；

⑦      支援設計師和其他技術人員的智力勞動；

⑧      在系統的整個生存週期都支援它的演化；

⑨受自動化工具的支援。

一個專案的成功與否跟人員、技術、資源、測試、架構、需求、領導、組織等因素有關係。把以上內容我們劃分為生命週期、人員、方法、工件、組織。而我們的軟體過程就針對這些方面討論解決方案，目前的有 Rup 、 AP 、 MP 、 HP 、 CMMI 、 Psp 、 Tsp 等。這裡將介紹一些方法的思想與指導原則。

一、軟體過程模型

    分類：

1. 慣例過程模型。

　　 2. 瀑布模型 ( 又叫作生命週期模型 ) 。

　　 3. 增量過程模型 : 包括 增量模型、 RAD 模型。

　　 4. 演化過程模型 : 包括 原型開發模型、螺旋模型、協同開發模型。

　　 5. 專用過程模型 : 包括 基於構件的開發模型、形式化方法模型、面向方面的軟體開發模型。

過程模型圖：

二、常見軟體過程開發方法（ Rup 、 AP 、 MP 、 HP ）

1 、 RUP

RUP （ Rational Unified Process ，統一軟體開發過程，統一軟體過程 )

主要內容：

1 ）六大經驗： 迭代式開發、管理需求、基於元件的體系結構、視覺化建模、驗證軟體質量、控制軟體變更。

2 ）統一軟體開發過程 RUP 的二維開發模型

RUP 軟體開發生命週期是一個二維的軟體開發模型。橫軸通過時間組織，是過程展開的生命週期特徵，體現開發過程的動態結構，用來描述它的術語主要包括週期(Cycle) 、階段 (Phase) 、迭代(Iteration) 和里程碑 (Milestone) ；縱軸以內容來組織為自然的邏輯活動，體現開發過程的靜態結構，用來描述它的術語主要包括活動(Activity) 、產物 (Artifact) 、工作者(Worker) 和工作流 (Workflow) 。如圖：

3 ） 開發過程中的各個階段和里程碑

　　 RUP 中的軟體生命週期在時間上被分解為四個順序的階段，分別是：初始階段(Inception) 、細化階段 (Elaboration) 、構造階段(Construction) 和交付階段 (Transition) 。每個階段結束於一個主要的里程碑(Major Milestones) ；每個階段本質上是兩個里程碑之間的時間跨度。在每個階段的結尾執行一次評估以確定這個階段的目標是否已經滿足。如果評估結果令人滿意的話，可以允許專案進入下一個階段。

　　（ 1 ）． 初始階段

　　初始階段的目標是為系統建立商業案例並確定專案的邊界。為了達到該目的必須識別所有與系統互動的外部實體，在較高層次上定義互動的特性。本階段具有非常重要的意義，在這個階段中所關注的是整個專案進行中的業務和需求方面的主要風險。對於建立在原有系統基礎上的開發專案來講，初始階段可能很短。 初始階段結束時是第一個重要的里程碑：生命週期目標(Lifecycle Objective) 里程碑。生命週期目標里程碑評價專案基本的生存能力。

　　（ 2 ）． 細化階段

　　細化階段的目標是分析問題領域，建立健全的體系結構基礎，編制專案計劃，淘汰專案中最高風險的元素。為了達到該目的，必須在理解整個系統的基礎上，對體系結構作出決策，包括其範圍、主要功能和諸如效能等非功能需求。同時為專案建立支援環境，包括建立開發案例，建立模板、準則並準備工具。 細化階段結束時第二個重要的里程碑：生命週期結構(Lifecycle Architecture) 里程碑。生命週期結構里程碑為系統的結構建立了管理基準並使專案小組能夠在構建階段中進行衡量。此刻，要檢驗詳細的系統目標和範圍、結構的選擇以及主要風險的解決方案。

　　（ 3 ）． 構造階段

　　在構建階段，所有剩餘的構件和應用程式功能被開發並整合為產品，所有的功能被詳細測試。從某種意義上說，構建階段是一個製造過程，其重點放在管理資源及控制運作以優化成本、進度和質量。 構建階段結束時是第三個重要的里程碑：初始功能(Initial Operational) 里程碑。初始功能里程碑決定了產品是否可以在測試環境中進行部署。此刻，要確定軟體、環境、使用者是否可以開始系統的運作。此時的產品版本也常被稱為“beta” 版。

　　（ 4 ）． 交付階段

　　交付階段的重點是確保軟體對終端使用者是可用的。交付階段可以跨越幾次迭代，包括為釋出做準備的產品測試，基於使用者反饋的少量的調整。在生命週期的這一點上，使用者反饋應主要集中在產品調整，設定、安裝和可用性問題，所有主要的結構問題應該已經在專案生命週期的早期階段解決了。 在交付階段的終點是第四個里程碑：產品釋出(Product Release) 里程碑。此時，要確定目標是否實現，是否應該開始另一個開發週期。在一些情況下這個里程碑可能與下一個週期的初始階段的結束重合。

4 ） RUP 的核心工作流 (Core Workflows)

　　 RUP 中有 9 個核心工作流，分為 6 個核心過程工作流 (Core Process Workflows) 和 3 個核心支援工作流 (Core Supporting Workflows) 。儘管 6 個核心過程工作流可能使人想起傳統瀑布模型中的幾個階段，但應注意迭代過程中的階段是完全不同的，這些工作流在整個生命週期中一次又一次被訪問。9 個核心工作流在專案中輪流被使用，在每一次迭代中以不同的重點和強度重複。

　　（ 1 ）． 商業建模 (Business Modeling)

　　商業建模工作流描述瞭如何為新的目標組織開發一個構想，並基於這個構想在商業用例模型和商業物件模型中定義組織的過程，角色和責任。

　　（ 2 ）． 需求 (Requirements)

　　需求工作流的目標是描述系統應該做什麼，並使開發人員和使用者就這一描述達成共識。為了達到該目標，要對需要的功能和約束進行提取、組織、文件化；最重要的是理解系統所解決問題的定義和範圍。

　　（ 3 ）． 分析和設計 (Analysis & Design)

　　分析和設計工作流將需求轉化成未來系統的設計，為系統開發一個健壯的結構並調整設計使其與實現環境相匹配，優化其效能。分析設計的結果是一個設計模型和一個可選的分析模型。設計模型是原始碼的抽象，由設計類和一些描述組成。設計類被組織成具有良好介面的設計包(Package) 和設計子系統 (Subsystem) ，而描述則體現了類的物件如何協同工作實現用例的功能。 設計活動以體系結構設計為中心，體系結構由若干結構檢視來表達，結構檢視是整個設計的抽象和簡化，該檢視中省略了一些細節，使重要的特點體現得更加清晰。體系結構不僅僅是良好設計模型的承載媒介，而且在系統的開發中能提高被建立模型的質量。

　　（ 4 ）． 實現 (Implementation)

　　實現工作流的目的包括以層次化的子系統形式定義程式碼的組織結構；以元件的形式 ( 原始檔、二進位制檔案、可執行檔案 ) 實現類和物件；將開發出的元件作為單元進行測試以及整合由單個開發者（或小組）所產生的結果，使其成為可執行的系統。

　　（ 5 ）． 測試 (Test)

　　測試工作流要驗證物件間的互動作用，驗證軟體中所有元件的正確整合，檢驗所有的需求已被正確的實現 , 識別並確　認缺陷在軟體部署之前被提出並處理。 RUP 提出了迭代的方法，意味著在整個專案中進行測試，從而儘可能早地發現缺陷，從根本上降低了修改缺陷的成本。測試類似於三維模型，分別從可靠性、功能性和系統性能來進行。

　　（ 6 ）． 部署 (Deployment)

　　部署工作流的目的是成功的生成版本並將軟體分發給終端使用者。部署工作流描述了那些與確保軟體產品對終端使用者具有可用性相關的活動，包括：軟體打包、生成軟體本身以外的產品、安裝軟體、為使用者提供幫助。在有些情況下，還可能包括計劃和進行beta 測試版、移植現有的軟體和資料以及正式驗收。

　　（ 7 ）． 配置和變更管理(Configuration & Change Management)

　　配置和變更管理工作流描繪瞭如何在多個成員組成的專案中控制大量的產物。配置和變更管理工作流提供了準則來管理演化系統中的多個變體，跟蹤軟體建立過程中的版本。工作流描述瞭如何管理並行開發、分散式開發、如何自動化建立工程。同時也闡述了對產品修改原因、時間、人員保持審計記錄。

　　（ 8 ）． 專案管理 (Project Management)

　　軟體專案管理平衡各種可能產生衝突的目標，管理風險，克服各種約束併成功交付使使用者滿意的產品。其目標包括：為專案的管理提供框架，為計劃、人員配備、執行和監控專案提供實用的準則，為管理風險提供框架等。

　　（ 9 ）． 環境 (Environment)

　　環境工作流的目的是向軟體開發組織提供軟體開發環境，包括過程和工具。環境工作流集中於配置專案過程中所需要的活動，同樣也支援開發專案規範的活動，提供了逐步的指導手冊並介紹瞭如何在組織中實現過程。

5 ） RUP 的十大要素

　　（ 1 ） . 開發前景

　　（ 2. ） 達成計劃

　　（ 3. ） 標識和減小風險

　　（ 4 ） . 分配和跟蹤任務。。

　　（ 5 ） . 檢查商業理由

　　（ 6. ） 設計元件構架

　　（ 7 ） . 對產品進行增量式的構建和測試

　　（ 8 ） . 驗證和評價結果

　　（ 9 ） . 管理和控制變化

　　（ 10 ） . 提供使用者支援

　　讓我們逐一的審視這些要素，看一看它們什麼地方適合ＲＵＰ，找出它們能夠成為十大要素的理由。

　　（ 1 ） . 開發一個前景

　　有一個清晰的前景是開發一個滿足涉眾真正需求的產品的關鍵。 前景抓住了ＲＵＰ需求流程的要點：分析問題，理解涉眾需求，定義系統，當需求變化時管理需求。 前景給更詳細的技術需求提供了一個高層的、有時候是合同式的基礎。正像這個術語隱含的那樣，它是軟體專案的一個清晰的、通常是高層的檢視，能被過程中任何決策者或者實施者借用。它捕獲了非常高層的需求和設計約束，讓前景的讀者能理解將要開發的系統。它還提供了專案審批流程的輸入，因此就與商業理由密切相關。最後，由於前景構成了“ 專案是什麼？ ” 和 “ 為什麼要進行這個專案？ ” ，所以可以把前景作為驗證將來決策的方式之一。 對前景的陳述應該能回答以下問題，需要的話這些問題還可以分成更小、更詳細的問題：? 關鍵術語是什麼？（詞彙表） ? 我們嘗試解決的問題是什麼？（問題陳述） ? 涉眾是誰？使用者是誰？他們各自的需求是什麼？ ? 產品的特性是什麼？ ? 功能性需求是什麼？（Ｕｓｅ Ｃａｓｅｓ） ? 非功能性需求是什麼？ ? 設計約束是什麼？

　　（ 2 ） . 達成計劃

　　 “ 產品的質量只會和產品的計劃一樣好。” (2) 在ＲＵＰ中，軟體開發計劃（ＳＤＰ）綜合了管理專案所需的各種資訊，也許會包括一些在先啟階段開發的單獨的內容。SDP 必須在整個專案中被維護和更新。 ＳＤＰ定義了專案時間表（包括專案計劃和迭代計劃）和資源需求（資源和工具），可以根據專案進度表來跟蹤專案進展。同時也指導了其他過程內容（原文：process components ）的計劃：專案組織、需求管理計劃、配置管理計劃、問題解決計劃、QA 計劃、測試計劃、評估計劃以及產品驗收計劃。

　　在較簡單的專案中，對這些計劃的陳述可能只有一兩句話。比如，配置管理計劃可以簡單的這樣陳述：每天結束時，專案目錄的內容將會被壓縮成ZIP 包，拷貝到一個 ZIP 磁碟中，加上日期和版本標籤，放到中央檔案櫃中。 軟體開發計劃的格式遠遠沒有計劃活動本身以及驅動這些活動的思想重要。正如Dwight D.Eisenhower 所說： “plan 什麼也不是， planning 才是一切。 ” “ 達成計劃 ”— 和列表中第 3 、 4 、 5 、8 條一起 — 抓住了 RUP 中專案管理流程的要點。專案管理流程包括以下活動：構思專案、評估專案規模和風險、監測與控制專案、計劃和評估每個迭代和階段。

　　（ 3 ） . 標識和減小風險

　　 RUP 的要點之一是在專案早期就標識並處理最大的風險。專案組標識的每一個風險都應該有一個相應的緩解或解決計劃。風險列表應該既作為專案活動的計劃工具，又作為確定迭代的基礎。

　　（ 4 ） . 分配和跟蹤任務

　　有一點在任何專案中都是重要的，即連續的分析來源於正在進行的活動和進化的產品的客觀資料。在 RUP 中，定期的專案狀態評估提供了講述、交流和解決管理問題、技術問題以及專案風險的機制。團隊一旦發現了這些障礙物（籬笆），他們就把所有這些問題都指定一個負責人，並指定解決日期。進度應該定期跟蹤，如有必要，更新應該被髮布。（原文：updates should be issued as necessary 。） 這些專案 “ 快照 ” 突出了需要引起管理注意的問題。隨著時間的變化 / 雖然週期可能會變化（原文： While the period may vary 。），定期的評估使經理能捕獲專案的歷史，並且消除任何限制進度的障礙或瓶頸。

　　（ 5 ） . 檢查商業理由

　　商業理由從商業的角度提供了必要的資訊，以決定一個專案是否值得投資。商業理由還可以幫助開發一個實現專案前景所需的經濟計劃。它提供了進行專案的理由，並建立經濟約束。當專案繼續時，分析人員用商業理由來正確的估算投資回報率(ROI ，即 return on investment) 。 商業理由應該給專案建立一個簡短但是引人注目的理由，而不是深入研究問題的細節，以使所有專案成員容易理解和記住它。在關鍵里程碑處，經理應該回顧商業理由，計算實際的花費、預計的回報，決定專案是否繼續進行。

　　（ 6 ） . 設計元件構架

　　在 RUP 中，件系統的構架是指一個系統關鍵部件的組織或結構，部件之間通過介面互動，而部件是由一些更小的部件和介面組成的。即主要的部分是什麼？他們又是怎樣結合在一起的？RUP 提供了一種設計、開發、驗證構架的很系統的方法。在分析和設計流程中包括以下步驟：定義候選構架、精化構架、分析行為（用例分析）、設計元件。 要陳述和討論軟體構架，你必須先建立一個構架表示方式，以便描述構架的重要方面。在RUP 中，構架表示由軟體構架文件捕獲，它給構架提供了多個檢視。每個檢視都描述了某一組涉眾所關心的正在進行的系統的某個方面。涉眾有終端使用者、設計人員、經理、系統工程師、系統管理員，等等。這個文件使系統構架師和其他專案組成員能就與構架相關的重大決策進行有效的交流。

　　（ 7 ） . 對產品進行增量式的構建和測試

　　在 RUP 中實現和測試流程的要點是在整個專案生命週期中增量的編碼、構建、測試系統元件，在先啟之後每個迭代結束時生成可執行版本。在精化階段後期，已經有了一個可用於評估的構架原型；如有必 要，它可以包括一個使用者介面原型。然後，在構建階段的每次迭代中，元件不斷的被整合到可執行、經過測試的版本中，不斷地向最終產品進化。動態及時的配置管理和複審活動也是這個基本過程元素（原文：essential process element ）的關鍵。

　　（ 8 ） . 驗證和評價結果

　　顧名思義， RUP 的迭代評估捕獲了迭代的結果。評估決定了迭代滿足評價標準的程度，還包括學到的教訓和實施的過程改進。 根據專案的規模和風險以及迭代的特點，評估可以是對演示及其結果的一條簡單的紀錄，也可能是一個完整的、正式的測試複審記錄。 這兒的關鍵是既關注過程問題又關注產品問題。越早發現問題，就越沒有問題。（原文：The sooner you fall behind, the more time you will have to catch up. ）

　　（ 9 ） . 管理和控制變化

　　 RUP 的配置和變更管理流程的要點是當變化發生時管理和控制專案的規模，並且貫穿整個生命週期。其目的是考慮所有的涉眾需求，儘可能的滿足，同時仍能及時的交付合格的產品。 使用者拿到產品的第一個原型後（往往在這之前就會要求變更），他們會要求變更。重要的是，變更的提出和管理過程始終保持一致。 在RUP 中，變更請求通常用於記錄和跟蹤缺陷和增強功能的要求，或者對產品提出的任何其他型別的變更請求。變更請求提供了相應的手段來評估一個變更的潛在影響，同時記錄就這些變更所作出的決策。他們也幫助確保所有的專案組成員都能理解變更的潛在影響。