? 预先设计。在实际开发工作开始前，少数架构师们需要用相当长的一段时间来进行架构设计和详细设计，力求得到一个具有高度可扩展性的良好架构。产出为“概要设计文档”和“详细设计文档”。根据项目规模，这个过程一般持续数周、数月甚至数年不等

　　? 短暂评估。架构师产出的设计文档要经过架构设计评审委员会或类似组织的评审，这个过程一般持续数天

　　? 依据设计进行实现。经过评审的设计会交到开发者手中，进行实际的编程实现，这个过程往往以数月，甚至数年来计算。

　　为什么传统开发方法会如此重视前期预先架构设计，以至于希望在实际开发前把架构设计做到尽善尽美?

　　答案在于，在传统的概念中，一旦设计成型，架构是很难调整的。例如，传统的软件工程教科书中都会讨论“架构调整的成本”问题：如果在设计中实现一次修改的成本为1;在实现过程中相同修改的成本就是5～10;在测试、部署阶段，同样的修改成本将上升到50～100;维护阶段同样修改的成本更是成指数曲线上升。

　　这种策略存在一个根本问题：软件的“扩展”究竟会如何发生是很难预计的。面对这一困境，传统开发方法的解决方案是继续增加预先设计的时间和人力，但往往收效甚微。

　　传统设计困境分析

　　传统预先设计方法恶性循环的原因有三点，对应上述实施过程的特点：

　　? 设计和实现脱节。设计评审团专家一般不参与实际的软件开发。基于经验的设计一方面无法得到实现的验证;另一方面，当需求发生变更时，无法随之演进。

　　? 评估的可靠性有限。对预先设计评估的只能基于已知的需求，而系统的可扩展性是在应对变更的需求时体现出来的，因此评估具有很大的局限性。

　　? 实现者缺少对预先设计进行修改的支持。当预先设计不能满足实际需求时，开发者或者修改设计，或者置需求变更不理，继续沿预先设计开发。忽视需求变更的结果只能是系统无法满足应用(而开发者也可以将责任推到架构师身上);如果开发者根据需求修改设计，则预先设计不但事实上已经成为浪费，而且已有的设计和实现往往更成会增加修改的难度。原因在于，如果预先设计的扩展性没有用到，则这些额外的扩展性带来的对当前需求无用的复杂性，这些复杂性增加了理解、修改系统的难度。