一个典型的J2EE项目通常应该使用哪一种开发流程呢？流行开发流程有很多种，应用比较广泛的有：瀑布式、迭代式、以及RUP (Rational Unified Process)。每一种都有其优点和不足，所以通常我们应该把它们结合起来而不是认定其中一个然后100%按着它的规范走。

首先来看看每一种大致是什么意思：

[瀑布式]

这种模式的流程强调在开始编码和测试之前完成所有的需求分析和设计，这种模式历史相当久远，也很成熟，甚至到了今天，这种模式还是被广泛的采用到绝大多数公司和项目中。采用这种模式开发的项目通常很大，并且需要较长时间交付。正因为如此，这些项目通常会有更多的风险：在业务需求不断变化的今天，如果待开发的系统不能及时反应出这些需求的变化，最终开发出来的产品可能已经不是客户真正需要的了。

[迭代式]

为了应对传统瀑布式的开发在处理需求变更上的不足，近些年出现了一种全新的极限编程的概念。极限编程（XP）的核心思想在于：从长远看，早期发现错误以及降低复杂度可以节约成本。极限编程强调我们将任务/系统细分为可以在较短周期解决的一个个子任务/模块，并且强调测试、代码质量和及早发现问题。通常，通过一个个短小的迭代周期，我们就可以获得一个个阶段性的进展，并且可以及时形成一个版本供用户参考，以便及时对用户可能的需求变更作出响应。

[RUP]

RUP的全称是Rational Unified Process，是一套定义得很完整的软件工程模型。它强调编码前的需求分析和设计，以及短迭代周期的开发和发布。它鼓励团队首先开发项目中风险最高的模块，用更多的时间发现和应对问题，当设计需要变化时，它也能够在一定程度上减轻一些重复工作。不过，因为RUP十分严谨，也比较具体，通常要完全跟着这个流程走也不是100%必要。

下面我们来看看实际上我们应该采取什么样的流程或者策略：

实际的J2EE项目中，RUP的应用呈逐年上升的趋势，不过也并非所有这些采用了RUP的项目也是完完全全RUP式的。我们可以考虑一种综合上面三种流程的优点的方式，根据具体的项目量体裁衣。需要对这几种的优点来一个总结：瀑布式由于比较成熟，通常很好的强调了先需求后设计再编码的重要性，也比较适合大公司先预算后执行的方式；极限编程强调测试先行和简单是美，这样有利于及早发现问题以及更好的应对变化；RUP强调的集中化的分析和设计也有其不可替代的优越性。

要做出一个结论性的答案并不容易，如果贵公司相对较大并且愿意支付一定的管理成本来推一套成熟且完整的开发流程并在公司内部所有项目或者是大多数项目严格执行，我想RUP应该是首选；如果贵公司希望有更大的灵活性，可以考虑一些折衷的方案，根据具体的项目，从上面三种流程提取有价值的部分，来确定具体的流程。