引用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
|
代码复审、版本管理方法、文档管理、人员招聘、重测试和重风险管理等。
|
编码和设计活动融为一体，弱化了架构。
用例、单元测试、迭代开发和分层的架构。
|
|
其它
|
通用性强，但复杂、高成本。
|
强调风险驱动，以保障可用产品的持续性交付为前提，尽量减少不必要的过程工件，使度量、文档最小化以获得弹性和应变能力。
|
提供了一系列指南，用于规划企业的基础技术设施，流程化商业的运作过程，并鼓励重用性。
|
拥抱变化，强调人性化、简单、沟通。尽量减少文档。
个体和交互胜过过程和工具。
|
概括起来, 不存在一种通用的或一成不变的适合软件开发和维护所有项目的软件过程模型。在组织软件过程中，存在不同的企业文化和业务环境、不同的层次和规模、不同的架构和产品类型、不同的资源和能力等因素制约，需要根据不同的项目、不同时期来选择和运用不同的过程模型和方法。不断吸收已有过程的思想，不断探索、不断实践，最终慢慢形成适合自己的自我定义的过程。
经过实践检验和积累的、自我定义的软件过程才是最好的过程。