，建立稳定、可靠的系统架构的里程碑目标也从未达到。
在项目几近成功、圆满结束的时候，突然爆炸一颗硕大的“地雷”（严重的系统缺陷或问题），导致项目进度拖延甚至失控，人员失和，资金拖欠，这就是软件开发中最糟糕的一种情况。
不幸的是，这种在各种经典教材中都能大量看到的案例，再一次地在已经（部分）采用了敏捷XP、RUP实践的PRM项目上重演了。那么，我们有没有可能事先防范PRM项目这颗延迟爆炸的“地雷”呢？
当年PRM项目已经花了10个月的时间，却仍未能通过客户验收。前期用了2个月完成功能开发，2个月部署和试运行，从第5个月完成实际数据导入、开始正式运行起，就出现了严重的性能问题。
随后的6个月基本上都用在了系统的性能优化和改进上。总体上项目开发给人一种手忙脚乱、进度失控的感觉。现在看来，PRM项目的进度至少延误了一倍时间。
软件工程不相信眼泪
如果PRM团队和客户从一开始就意识到系统潜在的性能问题，明确了对系统容量的要求;如果PRM系统的架构师拥有足够的设计经验，系统表示层、控制层和数据资源层在上线之前就已经得到优化，提供了足够的性能;如果架构设计评审产生了真正的效用;如果 PRM 团队做到了完备的系统测试;如果时间能够倒流……。
所有这些“如果”当中，只要有一条灵验，那么那颗可恶的“地雷”可能就不复存在了。
PRM项目可不可以做得更成功呢？答案是肯定的，我们不妨逆向思维:如果PRM团队能够把这个项目重头再做一遍，把吸取到的教训和学到的软件工程“新”知识都用上，在5个月内提供满足客户实际要求的系统应该足够了，至少PRM团队下次再遇到类似的项目他们成功的几率肯定会大许多。
规避风险，成熟的软件工程可以设置几道防线，采取许多措施。如果PRM项目按照RUP 风险驱动的迭代方式来做，那么从项目一开始我们就应该对需求、架构进行更为细致、全面的分析，既包括功能，也包括非功能，还可以通过多次迭代反馈来确认分析的结果。
假设如果不知道有哪些风险，我们又如何来防范？所以，关键是要建立一张随着迭代演进不断被动态更新维护的风险清单（RUP工件叫Risk List），制定出防范其中所有主要风险的预案。
就PRM项目而言，一方面，功能开发不是一个重大风险，因为有旧的PHP系统、源代码和现成的算法可以参考。另一方面，J2EE的应用架构设计得不好可能会存在性能问题。
因此，我们应该把注意力更多放到系统的非功能风险上（性能、可靠性、可维护性等）。具体表现为:客户应用访问的最大并发用户数到底是多少?我们交付到客户手里的系统最大容量又是多少？怎样才能保证系统的性能？如果上线后性能达不到，不能满足客户要求怎么办？等等。
明确了项目所面临的重大风险，比如系统的性能问题，我们就可以根据需求和设计方案制定出完善的、有针对性的测试计划。包括在客户可接受的响应时间要求下，系统最大能够支持多少个用户的并发访问（具体可细分为增、删、改、查等多个操作类型）。
明确了项目的风险、需求还不行，作为风险预案的落实，我们还应该进行系统性能、可靠性等方面的设计，真正（通过编码）做出一个符合要求的架构（框架）基础，通过迭代开发、测试和评审对此进行验证。
在开发阶段，系统还未部署，如果我们无法获得真实的用户和使用环境怎么办？用模拟测试！对，如果严格按照 RUP 风险驱动的迭代演进式开发进行管理，在半年多的时间里应该还是有机会尽早发现这个问题的。
但是，这种方式可以消除局部的缺陷，但却很难发现全局性的架构问题。对于软件架构，“头痛医头，脚痛医脚”的做法往往是行不通的。
PR项目虽然模仿X迭代周期，甚至每天都开例会（这有点像Scrum），很容易获得真实的项目情况，就像"掀开地毯下面的东西"，保证了初始版本的准时交付（在保证PRM前期进度方面，迭代还是有功劳的），却仍然没有能够防止较大风险的发生（交付系统几个月后才逐渐暴露出性能和架构上的质量问题）。
可以说，这并没有达到XP或RUP迭代开发的最终目的。在项目初期，没有把合同中已经提到的数据迁移视为一个关键风险，是前期分析工作或者说整个项目的一大失误。转贴于：http://www.leadge.com