软件开发过程(CMMI/RUP/XP/MSF)是与非？
?????? 引用Alistair Cockburn的一句話 “不同的項目需要不同的方法論，一個項目的最佳過程是這個項目所能負擔的最小過程。”， 這說明，對一個組織，往往有幾種方法并存，而對不同類型的項目，采用不同的方法。選擇一個合適的生命周期模型對于任何軟件項目的成功都是至關重要的。大量項目嚴重拖延、產品遲遲不能交付，究其根本原因往往是與錯誤運用了生命周期模型有關，這其中就包括存在明顯缺陷的瀑布模型所引起的誤區，雖然70年代提出的瀑布模型多年來一直被我們的軟件工程教育奉為經典來傳授，實踐上瀑布模型往往會將軟件過程引入歧途。與之不同是，新的過程方法論，不論輕型、重型，?還是XP、RUP或者TSP，無一例外地都主張采用能顯著減少風險的迭代演進式生命周期模型，強調迭代。但過分強調迭代，可能會忽視需求分析和定義、忽視設計，在后期不斷改動，使軟件開發的不良成本（返工、修正缺陷等）大大增加，增加了企業成本。
?? 例如，越來越多的人在討論、推崇敏捷過程、極限編程(XP)，實際也是有問題的，雖然敏捷過程、極限編程適合Web的開發、適合免費的Web服務、適合永遠的Beta版本，其中也有許多思想也確實值得應用，如持續集成、重構、強調測試等，但也存在其它問題，如結隊編程、計劃博弈、代碼集體所有等。極限編程只適合小型團隊、適合開源社區等，而不適合大型軟件企業；在軟件開發過程的全局上，更適合采用統一過程（RUP）、微軟軟件開發框架（MSF），而在局部、細節，吸收敏捷思想。有位美國朋友告訴我，XP可能曇花一現。不管他說得對否，當軟件作為成熟的產業，肯定是不會允許完全像“XP”這種做法的。
?? 由于篇幅和時間有限，在這里，可以將目前的流行的過程模式進行一個對比分析，大家就會對不同的軟件過程的優缺點，一目了然。
| 項目 | CMM/CMMI | RUP | MSF | XP |
| 周期 | 螺旋模型。 | 演進式迭代周期，過程框架 | 瀑布模型和螺旋模型的結合 | 演進式迭代周期。軟件開發方法學 |
| 核心 | 過程改進 | 架構、迭代 | 里程碑、迭代 | 以代碼為中心。 |
| 范圍 | 需求嚴格而極少變化的項目。 | 適合不同類型的項目 | 適合不同類型的項目 | 進度緊、需求不穩定的小項目、小型發布和小團隊 |
| 組織 | 個人（PSP）、團隊（TSP）和組織的3個層次，組間協作、培訓 | 跨團隊協作 | 強調產品的愿景，6種基本角色 | 以團隊為基礎，小團隊、團隊成員能力相當 |
| 技術 | 傳統結構化方法 | 面向對象技術 | 綜合技術 | 面向對象技術 |
| 管理 | 側重于過程的定義、度量和改進。一切用數字和文檔說話。 | 從組織角度出發，側重于過程建模、部署。 | 業務建模、部署、過程管理等概念。 | 側重于具體的過程執行和開發技術，計劃設計。 |
| 活動 | 通過過程域來定義活動 | 整個團隊在整個過程中關注質量 | 項目管理、風險管理和就緒管理 | 以人為本，如每周40小時工作制、結對編程 |
| 實踐 | 各類級別的關鍵實踐。 重視關鍵基礎設施。 | 滿足了CMM 2-3級KPA?的要求，而基本上沒有涉及CMM 4-5?級的KPA | 代碼復審、版本管理方法、文檔管理、人員招聘、重測試和重風險管理等。 | 編碼和設計活動融為一體，弱化了架構。 用例、單元測試、迭代開發和分層的架構。 |
| 其它 | 通用性強，但復雜、高成本。 ? | 強調風險驅動，以保障可用產品的持續性交付為前提，盡量減少不必要的過程工件，使度量、文檔最小化以獲得彈性和應變能力。 | 提供了一系列指南，用于規劃企業的基礎技術設施，流程化商業的運作過程，并鼓勵重用性。 | 擁抱變化，強調人性化、簡單、溝通。盡量減少文檔。 個體和交互勝過過程和工具。 |
?????
????概括起來, 不存在一種通用的或一成不變的適合軟件開發和維護所有項目的軟件過程模型。在組織軟件過程中，存在不同的企業文化和業務環境、不同的層次和規模、不同的架構和產品類型、不同的資源和能力等因素制約，需要根據不同的項目、不同時期來選擇和運用不同的過程模型和方法。不斷吸收已有過程的思想，不斷探索、不斷實踐，最終慢慢形成適合自己的自我定義的過程。
經過實踐檢驗和積累的、自我定義的軟件過程才是最好的過程。
轉載于:https://www.cnblogs.com/sier/archive/2011/10/06/5676449.html
總結
以上是生活随笔為你收集整理的软件开发过程(CMMI/RUP/XP/MSF)是与非？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 服务行为 之 并发与实例化
- 下一篇： Ajax Toolkit AutoCom