在UP(unified process)中，迭代过程对于需求的收集和分析都是渐进式的，特别是在初始阶段，在需求并不是十分确定和明确，仅仅分析了10%的用例的情况下就开始实际的编码工作，是否会造成编码工作的重复和浪费呢？在某些情况下，接下来的迭代周期新发现和收集的需求和业务流程可能会大量的调整甚至推翻前面所做的编码工作。存在多数的情况可能是：因为第一次迭代对需求了解、分析不够全面，导致第一次迭代中所作的设计并没有留足足够的变化性和可扩展性，当有新的需求加入或者进一步的分析后，发现某些因为存在可预见的变化需求时，想要封装此些变动时就需要更改前面实现了的代码，当然，也可以说这是一种必然的重构了，但是，如果在项目开始之初就了解多一点需求并深入一点的分析也许是可以避免这种重构的啊。
面向对象设计原则： 面向抽象编程而不是面向实现编程。
对扩展开放对修改封闭。
这两个原则都是需要我们能够提炼出抽象部分，并明确潜在的变化部分才能够对症下药的，我们不可能假设系统所有的地方都是潜在变化的，并创建抽象类留足扩展空间的，这样设计出来的系统是不可想象的，所以我么必须找到系统中相对稳定的部分，当然，全面的需求收集是不可能的，因为需求永远都在变化中，但是，在一段可预见的时间和版本控制上，我们必须假定系统的需求到某一个程度是应该封住并在假定的某些条件下是不再演化了的，如果不这样就不能停止开发也不能发布相关的版本，对一个系统来说，不可能所有的需求（业务）在一定时间内都在变化，总会存在着一些相对稳定的业务，如果对需求（业务）不做充分的收集和分析，又怎么能够抽象出系统相对稳定的部分和相对容易变化的部分，并做好相应的设计方案，封装变化点呢？所以对UP这个在需求的把握上我还是存在很多疑问，希望继续深入能找到答案。
也许使用UP过程的团队对正在开发的项目的业务领域有相当的经验，这样在需求收集不是很充分，分析不是很深入的情况下开始编码可能根据经验可以留出适当的扩展空间，在这里就彰显经验的重要性了，一个老到的系统分析和结构师会比较容易嗅出需求（业务）中比较容易变化的地方，桥过多了，路还走的少吗？这也可以解释一般的软件公司都会专注于某一块领域里的软件开发的原因，第一个是有沉淀下来的基础框架，第二就是经验了，第三：客户也比较容易开拓 
。
在没有得到更好的答案前，我只能这么想：UP也好，瀑布也好都是软件工程的一种方法过程，不一定在所有的项目中都必须使用相同的软件工程方法，应该量体裁衣，寻找适合的方法即可，多一种方法只是多一种选择而已，软件工程没有银弹，当是可以有很多子弹。
对于UP还必须继续多看书。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。