軟件開發一個複雜的活動, 它包含了需求調研, 系統設計, 開發, 部署, 維護等活動. 而且現有規範和流程目的並不是讓你去完成文檔, 而是通過這些文檔, 讓軟件的質量更能得到保證。組成軟件開發和系統演化的活動有着各種模型(軟件生存週期，軟件開發模型，軟件過程)，但是典型地都包含了以下的過程或活動：分析、設計、實現、確認(測試驗收)、產品化、維護。
軟件開發方法的一般要求：當提出一種軟件開發方法時，應該考慮許多因素，包括：
① 覆蓋開發全過程，並且便於在各階段間的過渡；
② 便於在開發各階段中有關人員之間的通信；
③ 支持有效的解決問題的技術
④ 支持系統設計和開發的各種不同途徑
⑤ 在開發過程中支持軟件正確性的校驗和驗證；
⑥ 便於在系統需求中列入設計、實際和性能的約束；
⑦ 支持設計師和其他技術人員的智力勞動；
⑧ 在系統的整個生存週期都支持它的演化；
⑨受自動化工具的支持。
一個項目的成功與否跟人員、技術、資源、測試、架構、需求、領導、組織等因素有關係。把以上內容我們劃分爲生命週期、人員、方法、工件、組織。而我們的軟件過程就針對這些方面討論解決方案，目前的有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中，變更請求通常用於記錄和跟蹤缺陷和增強功能的要求，或者對產品提出的任何其他類型的變更請求。變更請求提供了相應的手段來評估一個變更的潛在影響，同時記錄就這些變更所作出的決策。他們也幫助確保所有的項目組成員都能理解變更的潛在影響。
（10）. 提供用戶支持
在RUP中，部署流程的要點是包裝和交付產品，同時交付有助於最終用戶學習、使用和維護產品的任何必要的材料。 項目組至少要給用戶提供一個用戶指南（也許是通過聯機幫助的方式提供），可能還有一個安裝指南和版本發佈說明。 根據產品的複雜度，用戶也許還需要相應的培訓材料。最後，通過一個材料清單（BOM表，即Bill of Materials）清楚地記錄應該和產品一起交付哪些材料。 關於需求 有人看了我的要素清單後，可能會非常不同意我的選擇。例如，他會問，需求在哪兒呢？他們不重要嗎？我會告訴他我爲什麼沒有把它們包括進來。有時，我會問一個項目組（特別是內部項目的項目組）：“你們的需求是什麼？”，而得到的回答卻是：“我們的確沒有什麼需求。” 剛開始我對此非常驚訝（我有軍方的宇航開發背景）。他們怎麼會沒有需求呢？當我進一步詢問時，我發現，對他們來說，需求意味着一套外部提出的強制性的陳述，要求他們必須怎麼樣，否則項目驗收就不能通過。但是他們的確沒有得到這樣的陳述。尤其是當項目組陷入了邊研究邊開發的境地時，產品需求從頭到尾都在演化。 因此，我接着問他們另外一個問題：“好的，那麼你們的產品的前景是什麼呢？”。這時他們的眼睛亮了起來。然後，我們非常順利的就第一個要素（“開發一個前景”）中列出的問題進行了溝通，需求也自然而然的流動着（原文：and the requirements just flow naturally.）。 也許只有對於按照有明確需求的合同工作的項目組，在要素列表中加入“滿足需求”纔是有用的。請記住，我的清單僅僅意味着進行進一步討論的一個起點。
RUP的生命週期模型與傳統的瀑布模型、演化模型、螺旋模型、噴泉模型不同的是在先啓、精化、構建、產品化階段每個過程可以有迭代和增量，而迭代以里程碑確定，在具體的過程中工作流程的側重點是不同的，還有就是各個工作流程是可以並行的，提高開發效率。方法上採用用例驅動；人員上有相關角色和個體的劃分，對於產品，主要是要以架構爲中心，設計出具有高重用性、安全性、可擴展性等的系統。
2、AP
敏捷開發（agile development）是一種以人爲核心、迭代、循序漸進的開發方法。在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特徵。簡言之，就是把一個大項目分爲多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程中軟件一直處於可使用狀態。但敏捷開發並不是一種創新，敏捷開發可理解爲在原有軟件開發方法基礎上的整合——取其精華，去其糟粕。因此敏捷開發繼承了不少原有方法的優勢。然而，我們不得不面對的現實卻是，敏捷中模式與方法的優化並不意味着問題的終結。作爲一種開發模式，敏捷開發同樣需要面對衆多挑戰。
敏捷開發是由一些業界專家針對一些企業現狀提出了一些讓軟件開發團隊具有快速工作、響應變化能力的價值觀和原則，並於2001初成立了敏捷聯盟。他們正在通過親身實踐以及幫助他人實踐，揭示更好的軟件開發方法。
主要內容：
1） 敏捷是“一個”過程
敏捷不是一個過程，是一類過程的統稱，它們有一個共性，就是符合敏捷宣言，遵循敏捷的原則。
敏捷宣言如下：
個體和交互 勝過 過程和工具
可以工作的軟件 勝過 面面俱到的文檔
客戶合作 勝過 合同談判
響應變化 勝過 遵循計劃
由價值觀引出的12條敏捷原則：
我們最優先要做的是通過儘早的、持續的交付有價值的軟件來使客戶滿意。
即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來爲客戶創造競爭優勢。
經常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。
圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支持，並且信任他們能夠完成工作。
在團隊內部，最具有效果並且富有效率的傳遞信息的方法，就是面對面的交談。
工作的軟件是首要的進度度量標準。
敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恆定的開發速度。
不斷地關注優秀的技能和好的設計會增強敏捷能力。
簡單——使未完成的工作最大化的藝術——是根本的。
最好的構架、需求和設計出自於自組織的團隊。
每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行爲進行調整。
建立敏捷聯盟的17位大師所創立的敏捷方法包括：極限編程，Scrum，特徵驅動開發，動態系統開發方法，自適應軟件開發，水晶方法，實用編程方法。這些方法統稱爲敏捷方法。
其實每個人都可以從敏捷宣言和原則出發，明確問題，找出一些解決方法，形成自己的過程。
2）敏捷開發的設計原則
關於敏捷開發的設計原則：
單一職責原則SRP：Single Responsibility Principle
開放封閉原則OCP：Open－Close Principle
Liskov替換原則LSP：Liskov Substitution Principle
依賴倒置原則DIP：Dependency Invertion Principle
接口隔離原則ISP：Interface Separate Principle
關於包的設計原則：
重用發佈等價原則REP：Reuse Equivalence Principle
共同重用原則CRP：Common Resue Principle
共同封閉原則CCP：Common Close Principle
無環依賴原則ADP：Acyclic Dependency Principle
穩定依賴原則SDP：Stabilization Dependency Principle
穩定性度量公式：I＝Ce/(Ca+Ce) (I:不穩定度，Ce:輸入耦合度，Ca：輸出耦合度)
I取值範圍在【0，1】，I＝0表示具有最大穩定度；iI＝1標識具有最大不穩定度
穩定抽象原則SAP：Stabilization Abstract Principle
AP主要有XP流派，當然還有很多的流派，包括極限編程，SCRUM,動態系統開發，特徵驅動開發等，但是這裏主要探討的是XP，AP中有4個思想，12條原則，主要在開發中強調人員的重要性和可操作性軟件的重要性，在方法上我們強調簡單，在人員上強調人員和交互高於環境和工具，產品上強調最早交付，迭代歡迎需求的變化，直到項目後期依舊歡迎需求的變更，最大化的包含需求爲客戶提高競爭力。所以在AP中，由於是方法學家提出來的，所以是比較激進的，適合小型的項目開發，以及在資源等有要求的情況下快速開發。
Extreme Programming（XP，極限編程） 是一種輕量級的軟件開發方法，它使用快速的反饋，大量而迅速的交流，經過保證的測試來最大限度的滿足用戶的需求。XP強調用戶滿意，開發人員可以對需求的變化作出快速的反應。XP強調team work。項目管理者，用戶，開發人員都處於同一個項目中，他們之間的關係不是對立的，而是互相協作的，具有共同的目標：提交正確的軟件。XP強調4個因素：
交流(communication)，XP要求程序員之間以及和用戶之間有大量而迅速的交流
簡單（simplicity），XP要求設計和實現簡單和乾淨
反饋（feedback）通過測試得到反饋，儘快提交軟件並根據反饋修改
勇氣（courage）。勇敢的面對需求和技術上的變化
XP特別適用於需求經常改變的領域，客戶可能並系統的功能並沒有清晰的認識，可能系統的需求經常需要變動。
XP也適用於風險比較高的項目，當開發人員面對一個新的領域或技術時，XP可以幫助減低風險
XP適用於小的項目（人員上），人員在2-12人之間，XP不適用於人員太多的項目，事實上，在需求經常變化或風險比較高的項目中，少量而有效的XP開發人員效率要遠遠高於大量的開發人員。
3、MP
MP主要是微軟依靠自己的開發經驗建立的軟件過程，作爲全球最大、最成功的軟件公司，MP有自己的體系。當然在人員上主要摒棄了傳統的項目經理職務，取而代之的是產品經理和程序經理，這裏我要說明的是這個舉措是相當的好，可以使得項目經理的職責細化，使得任務明確，產品經理對外滿足用戶需求而程序經理對內組織團隊開發。方法上：Mp採用每日編譯，和AP中的持續集成是一樣的，需求是提出遠景範圍文檔，提出遠期和近期的目標，而且把整個生命週期劃分爲5個階段。當然MP主要提出均衡三角形的模型，使得人員、進
度、功能&性能三者達到平衡。
微軟過程原則：
1） 制定計劃時兼顧未來不確定因素
2） 通過有效的風險管理減少不確定因素的影響
3） 經常生成過渡性的版本並快速測試來提高產品的穩定性及可測性
4） 快速循環遞進的開發過程
5） 從產品特性和成本控制出發創造性地工作
6） 創建確定的進度表
7） 使用小型項目組併發完成工作，並設置多個同步
8） 將大型項目分解成多個可管理的單元，以便更快地發佈產品
9） 用產品的前景目標和概要說明指導項目開發工作-先基線後凍結
10）避免產品走形
11）使用原型驗證概念，進行開發前的測試
12） 零缺陷概念
13） 非責難式的里程碑評審會
微軟開發產品的每個生命週期分五個階段
1） 構想階段
2） 計劃階段
3） 開發階段
4） 穩定階段
5） 發佈階段
4、HP和諧軟件過程
在新的發展階段繼續全面快速地發展IT，必須堅持以和諧軟件過程爲指導，和諧軟件過程是軟件工程在中國的新發展，是對軟件生命週期、軟件項目管理、系統架構、系統分析的重要指導方針，是企業進行信息化建設的重大戰略思想。和諧軟件過程第一次科學地回答了什麼是軟件、如何保證並提高軟件品質、如何展開軟件工程各環節等軟件基本問題，認爲品質低下不是軟件、操作不便不是軟件、非人性化不是軟件、存在較多bug不是軟件、效率低下（研發效率和運行效率）不是軟件、業務錯亂不是軟件、團隊不穩不是軟件、管理混亂不是軟件、難以擴展和維護不是軟件、不能共享軟件成果不肯共擔軟件責任不是軟件、研發維護過於繁瑣不是軟件等實際問題。
和諧軟件過程，是立足中國當前基本國情和行業發展背景，是在總結我國實踐經驗和借鑑國外發展經驗基礎上，爲適應新的軟件發展要求提出來的。進入新世紀新階段，我國軟件行業發展呈現出了一系列新的階段性特徵，主要是：企業對軟件需求與日俱增，同時軟件研發不規範、漏洞多、性能差，技術思想大多依靠外國，自主創新能力不強，長期形成的需求誤解、返工率高、效率低下、系統不穩定等問題尚未根本改變；從業人員的收入水平參差不齊、加班福利得不到根本保障，客戶、企業、員工三者利益衝突此伏彼起，要想統籌兼顧各方面利益難度加大。
行業軟件建設發展不平衡，企業霸佔市場，信息化建設的難以分割性，導致公開招標不可能，因而只能漫天要價議標；IT從業人員的與日俱增，導致企業可以選擇職員範圍更廣，因而員工的薪資待遇得不到合理的價位保證；另一方面，IT企業的迅速擴建，導致IT從業人員有了更多的選擇，通過頻繁的跳槽來快速提升薪資待遇成爲有實力一族的經驗技巧，從而使得企業的項目風險與日俱增；企業的速增，客戶也有了更多的選擇，一些新項目或者老項目改造擴建等，通過惡意招標使得企業利潤大幅降低；在企業利潤得不到保證時，加班成了家常便飯，得不到加班補貼，使得降低軟件品質成爲了一線職員的自救措施，軟件品質得不到保障又反過來影響了公司的業務業績形象，從而進一步影響了員工的薪資福利；同時更多人對信息技術的掌握，以及對軟件要求、軟件文化需求、薪資待遇、職業規劃日趨旺盛，企業、員工的選擇性、多變性、差異性明顯增強，對企業信息化建設提出了更高要求；軟件活力顯著增強，同時社會結構、公司項目組織形式、社會利益格局發生深刻變化，軟件工程、系統架構和項目管理面臨諸多新課題；對外開放日益擴大，同時面臨的國際競爭日趨激烈，歐美國家的語言壓力長期存在，可以預見和難以預見的風險與困難將不斷增多，統籌國內發展和對外開放要求更高。
我們要強調認清國內軟件行業的基本國情，不是要妄自菲薄、自甘落後，也不是要脫離實際、急於求成，更不能閉門自鎖，而是要堅持把它作爲推進改革、謀劃發展的根本依據。我們必須始終保持清醒的頭腦，立足當前情況這個最大的實際，科學分析我國全面參與軟件全球化的新機遇新挑戰，全面認識軟件工業化、信息化、城鎮化、市場化、國際化深入發展的新形勢新任務，深刻把握我國軟件發展面臨的新課題新矛盾，更加自覺地走和諧軟件道路，奮力開拓中國特色軟件工程更爲廣闊的發展前景。
和諧軟件過程，第一要義是平衡，核心是以人爲本，基本要求是涉衆共同承擔軟件義務共享軟件成果，根本指導思想與實施方法是簡易法則，實踐要求是全面協調。
必須堅持把平衡作爲和諧軟件工程的第一要義。平衡，對於整個軟件生命週期，具有決定性意義。和諧的目的在於永續，平衡是永續的根本保證。平衡，包括了各方利益（軟件權利和軟件義務）的平衡，對於員工則更體現了工作績效與薪資待遇的平衡，例如加班必須給予補貼，這直接體現了勞動法第44條和民法通則的補償原則，是和諧軟件過程對自然法原則的應用，也是牛頓力學的受力平衡與熱平衡、心理平衡等自然法則在和諧軟件過程中的具體應用。我們要牢牢把握好平衡這個中心，堅持聚精會神搞信息化建設、一心一意做項目，不斷解放和發展軟件生產力。更好地實施軟件興國策略、軟件強國戰略，着力把握軟件發展規律、創新軟件發展理念、轉變軟件研發模式、破解軟件難題，提高軟件品質和軟件效益，實現又好又快地永續研發軟件。努力實現以人爲本、涉衆共同承擔軟件義務共享軟件成果，實現各方面的有機統一、員工企業客戶團結和睦的和諧發展，實現通過維護軟件平衡、發展員工和企業、提升客戶競爭力。
和諧軟件過程必須堅持簡易法則。簡易的目的在於務實、實用，在於提高效率、政通人和。乾以易知，坤以簡能；易則易知，簡則易從；易知則有親，易從則有功；有親則可久，有功則可大；可久則賢人之德，可大則賢人之業；易簡而天下之理得矣；天下之理得，而成位乎其中矣。系統架構、項目研發不能捨近求遠、舍簡求繁，不能以爲了騙取高額的項目費而故意採用繁瑣的方法，騙取較多的工時；也不能以本來就有簡易快速的方法、成熟的技術方案可以借鑑參考，卻故意採用其他方法；當現有方法或者新技術不足以提高效率甚者會影響效率時，是否存在重複設計時，我們務必考慮如何優化，使之可以多塊好省地進行。務必堅持信息向上集中、服務向下延伸爲基本理念，以信息集成化爲原則，不要不斷建立一個又一個的信息孤島。軟件至簡，不教而用！
和諧軟件過程必須始終堅持以人爲本。軟件最終是給人用過的，研發過程也離不開人的積極努力，全心全意爲客戶創造最好的軟件是和諧軟件過程的根本宗旨，企業和員工的一切奮鬥和工作都是爲了服務客戶。要始終把實現好、維護好、升級發展好最廣泛客戶的軟件需求作爲企業和員工一切工作的出發點和落腳點，尊重客戶、員工的主體地位，發揮員工的首創精神，保障員工的各項權益，走利益共贏的軟件道路，促進三者的全面發展，做到軟件爲了人、研發依靠人、軟件成果由人共享(企業即企業法人)。
和諧軟件過程必須堅持全面協調。要按照軟件需求進行系統總體分析和系統架構，全面做好需求調研、設計、研發、測試、上線實施、配置管理、數據庫DBA、網絡管理，各個環節、各個方面相協調，促進客戶與企業、績效與薪資福利相協調。
和諧軟件過程必須堅持統籌兼顧。要正確認識和妥善處理軟件研發過程中的各項重大關係，務必統籌兼顧利益、質量、時間、成本、範圍、員工與企業和客戶和諧永續地發展、國內創新發展和借鑑吸取國外成功優秀經驗、實行軟件對外開放政策，統籌員工、企業與客戶的關係，統籌員工利益和企業利益、企業利益和客戶利益、公司業績和軟件品質，充分調動各方面積極性。統籌三方利益、把握軟件品質大局，樹立世界眼光，加強戰略思維，善於從國際形勢發展變化和充分借鑑祖國傳統哲學中各類有效經驗，把握髮展機遇、應對風險挑戰，營造良好的軟件開發環境。既要總攬全局、統籌規劃，又要抓住牽動全局的主要工作、事關多方利益的突出問題，着力推進、重點突破。
深入貫徹落實和諧軟件過程，要求我們始終堅持“平衡、簡易、統籌”的基本觀點和方法。軟件過程的基本政策路線是企業、員工、客戶的生命線，是實現和諧永續研發的根本保證。以平衡爲第一要義是軟件過程得以正常開展的基本前提，是員工、企業、客戶基本要求得以實現的根本要求；簡易法則是展開具體工作之本，是實現員工、企業、客戶利益最大化的現實基礎；總結、吸收和創新是不斷提高工作效率、提高各方利益的活力源泉。要堅持把以促進利益平衡、以簡易法則提高效率、保證軟件品質三個基本點統一於共享軟件成果共擔軟件義務之中，不斷促進和發展具有中國特色的和諧軟件過程的偉大實踐之中，任何時候都決不能動搖。
深入貫徹落實和諧軟件過程，要求我們繼續深化改善軟件過程。要把改善創新精神貫徹到軟件工程的各個環節，毫不動搖地堅持改善方向，提高改善決策的科學性，增強改善措施的協調性。要完善和諧的軟件權力義務體制，推進各方面體制改善創新，加快重要過程和關鍵環節的改善步伐，全面提高開放總結反思吸收借鑑創新水平，着力構建充滿活力、富有效率、更加開放、有利於軟件研發的體制機制，爲發展中國特色軟件事業提供強大動力和體制保障。要堅持把改善各方權力義務平衡作爲正確處理改善研發過程和發展穩定團隊的結合點，使改善始終得到多方軟件人民的擁護和支持。
深入貫徹落實和諧軟件過程，要求我們切實加強和改進團隊建設。企業要站在完成爲客戶提高工作效率使命的高度，要把提高軟件項目系統架構能力、保持和提高軟件品質能力，體現到項目管理、系統分析、促進軟件過程的和諧上來，要落實到引領軟件過程發展進步、擔任起創新的重要使命，要更好地代表和實現最廣大軟件人民的根本利益上來，使軟件工程的各項工作更加符合和諧軟件過程的要求，爲和諧軟件過程提供可靠的體制和組織保障。
和諧軟件過程，在思想理念和實踐方法上，要充分借鑑中國先秦諸子百家中法家、儒家、兵家、道家、醫家、史家、墨家、縱橫家、易家等一切優秀的思想理念和有效的方法論，尤其是法家的變通和效率思想、儒家的人性關懷、墨家的人才觀、縱橫家的心理學談判技巧解釋溝通、兵家的靈活創新、醫家的防範思想和整體辯證觀念、道家全面協調和諧永續思想、史家的反思總結借鑑方法論、和易經（遠勝於西方所謂的系統工程）的系統觀念，是由工作在軟件一線的客戶代表、企業領導、系統分析師、系統架構師、項目經理、高級程序員根據實踐經驗、教訓和理論的不斷反思總結所得出的，具有很強的理論基礎和切實的實際可操作可行性。同時和諧軟件過程在吸收借鑑方面始終堅持泰山不讓土壤、河海不擇細流、王者不卻衆庶、有容乃大、海納百川的博大胸懷與思想境界以及不期修古、不法常可、論世之事、因爲之備的方法論。和諧軟件過程雖然是軟件工程在中國發展的新發展、新成果，但是和諧軟件過程同樣很強調應當根據不同文化、不同信仰的民族特點、國家國情來做出裁減和調整。
深入貫徹落實和諧軟件過程，要求我們積極構建和諧的軟件文化。和諧軟件過程是中國特色軟件工程的本質屬性，和諧軟件過程是軟件工程在中國發展的新成果，是和黨的科學發展是內在統一的，也是黨所一貫主張的自主創新理念和自主知識產權在軟件工程中的應用。沒有和諧軟件過程就沒有軟件工程，沒有和諧軟件過程也不可能持續永續地研發出具備完美軟件品質的軟件產品。實施和諧軟件過程是貫穿於中國特色軟件工程全過程的長期歷史任務，是在軟件研發的基礎上正確處理各種軟件矛盾的歷史過程和社會結果。要通過發展不斷促進增加各方利益、不斷改善人的軟件生活，又要通過軟件研發保障軟件公平正義、不斷促進過程和諧。實現軟件過程的公平正義是涉衆的一貫主張，是中國軟件事業走向世界並引領世界軟件產業發展方向的重大任務。在軟件過程中要始終按照民主法治、公平正義、誠信友愛、充滿活力、安定有序、員工企業客戶和諧相處的總要求和共同建設、共同享有的原則，着力解決三方最關心、最直接、最現實的利益問題，努力形成軟件人民各盡其能、各得其所而又和諧相處的局面，爲發展軟件提供良好的軟件文化環境。
全體IT從業人員、所有軟件人民要全面把握和諧軟件過程的科學內涵和精神實質，增強貫徹落實和諧軟件過程的自覺性和堅定性，着力轉變不適應不符合和諧軟件過程的思想觀念，着力解決影響和制約和諧軟件過程的突出問題，把軟件社會的發展積極性引導到和諧過程上來，把和諧軟件過程貫徹落實到軟件工程的各個方面。
總之，我們要不斷堅持和諧軟件過程，根據軟件、行業、人文等各類因素，不斷地落實和深化和諧軟件過程的理念，不斷反思總結吸收借鑑改善創新，把黨所一貫主張的自主創新、自主知識產權要求通過和諧軟件過程真正得到體現，使中國軟件能夠趕上並超過美國甚至領先世界。
和諧軟件過程是以人爲核心，堅持“平衡、簡易、統籌”的基本觀點和方法。軟件過程的基本政策路線是企業、員工、客戶的生命線，是實現和諧永續研發的根本保證。以平衡爲第一要義是軟件過程得以正常開展的基本前提，是員工、企業、客戶基本要求得以實現的根本要求；簡易法則是展開具體工作之本，是實現員工、企業、客戶利益最大化的現實基礎；總結、吸收和創新是不斷提高工作效率、提高各方利益的活力源泉。要堅持把以促進利益平衡、以簡易法則提高效率、保證軟件品質三個基本點統一於共享軟件成果共擔軟件義務之中。
總結：軟件過程方法沒有最好的方法，只有最適合的方法。由於每個公司文化和項目背景不同，最適合公司文化和項目特點的方法就是最佳、最好的開法。