在系统设计师和管理者中间，有一场旷日持久的争论，就是到底是应该采用由上至下的设计技术还是采用由下至上的技术。经验证明，两种方法混合的效果最佳。
由上至下
采用由上至下的方法，设计者开始有一个大的理念，然后再进行细化。系统的上层符合未来用户对于功能的要求。设计者逐渐深入，面对每一项功能进行分解，最终满足每一个细节需要，然后设计完成。
管理者理所当然喜欢这种由上至下的方法。通过这种方法，他们可以知道设计的最终结果如何，可以估算出总体的成本和进度。这种方法适用于项目团队的环境，因为总体的计划可以分解给每一个成员。由上至下的方法可以使用标准项目管理手段，如里程碑、甘特图、物料清单等等。
由下至上
而由下至上的方法，开始于某一个特别的特征。在面向这一特征完成一个模块之后，设计者要关注另外一个特征接着撰写模块。接下来，设计者会加入一些“钩子”，把这些模块连接起来。整个过程就是处理一个又一个特征。由于项目是模块式的，所以即便是在项目完成之后很久，想随时加入一些新的、意想不到的特征也并不困难。这种方法在系统需要拓展时非常高效。
然而由下至上的项目比较难于管理。因为没有一个总
混合设计
两种方法都有优点和缺点，不过好在它们并不是水火不容。最好的方法就是混合：计划由上至下，而执行由下至上。
以由上至下的计划开始，识别出需要的模块和接口标准。这就使项目经理喜欢的里程碑、预算估计和任务确定成为可能。
然而，不要试图确定每一个特征或者特征集应该如何实体化。因为这就好像道家祖师老子说的--“班门弄斧”（编者注：“班门弄斧”似乎应出自柳宗元《王氏伯仲唱和诗》）。计划确实应该提供足够的细节，让团队当中的每一个人都知道项目期待的结果，但是不要这么做。
对于这件事情，应该给团队成员分配任务。他们应该采用由下至上的工作方式，实施计划。举例来说，训练良好、行为规范的程序员，知道如何使用结构化编程方法将项目各部分模块化，从而避免写出无法维护和拓展的“毛线团代码”。同样，来自其他工程领域的团队成员也受过良好的培训，非常专业。
混合方法对于任何工程项目都很容易使用。比如说，修建任何比狗窝大的建筑物，采用的方法都大同小异。如果你不知道一面砖墙应该放在哪、应该使用多少块砖，你怎么去建造它？这就是由上至下的部分。然而，当你自己做瓦工，和泥刷浆，把砖头码好，这就是由下至上。
控制项目可以采用完全的由上至下或者由下至上的方法。因此，对于控制工程师来说，理解这两种方法把它们联合起来构成混合方法，非常重要。即便在一名工程师独自工作的时候，混合方法也可以保证项目管理规范，设计的系统可用、可维护并且可扩展。
