误区三：建模意味着需要一个重量级的软件开发过程
走入这个误区（经常与误区一有联系）的项目组常常是连建模都彻底地放弃了，应为这样的软件开发过程对 他们来说太复杂太沉重了。这不亚于一场天灾。
事实分析：你可以用一种轻灵的方式取而代之。关于用简单的工具进行简单地建模的详细内容可参看Agile Modeling(AM)。而且，你可以丢弃你的模型当使命完之后，同样也可以很基本的方式进行建模（比如，从办 公桌起来，来到白板前就开始构略草图）。只要你愿意，你就可以轻松地建模。
误区四：必须“冻结”需求
这个要求常常来自高级经理，他们确切地想知道他们从这个项目组能得到什么东西。这样的好处就是在开发 周期的早期确定下需求，就可以确切地知道所要的是一个什么样的东西；缺点就是他们可能没有得到实际上 所需要的（不全或错误的需求，译者）。
事实分析：变化总会发生的。由于优先级的变化和逐渐对系统有了更进一步的理解，都会引起需求的变化。 与冻结需求相反，估计项目成功的风险，尽量去接受变化而且相应地采取行动，就象XP所建议的一样。
误区五：设计是不可更改的
如同误区四，要求每一个开发人员必须严格遵从“设计“，导致开发人员为了符合“设计“而作了错误的事情或以错误的方式作正确的事情。或者是简单地忽略了设计，否定了所有设计可能带来的好处。冻结了设计，你就不能从在项目进程中所学到知识进一步获益。另外一个很大的趋势就是开发出大量的文档而不是实 际的软件，使用面向文档的CASE工具而不是能给项目带来实际价值的面向应用的工具。
事实分析：事实上，设计会经常根据开发人员和数据库管理员的反馈进行修改，因为他们是最接近实际应用 的人，通常他们对技术环境的理解要好于建模者。我们必须的面对这样一个事实：人无完人，他们所作的工 作也不可能尽善尽美。难道您真的想将一个并不完善的设计固定下来而不再去修改其中的错误吗？另外，如 果需求并没有被冻结，其实就意味着你不能冻结你的设计，因为任何需求的修改势必影响设计。对之，正确 的态度是：只要你的代码还在改动，涉及就没完。
误区六：必须使用CASE工具
建模常常被认为是一项复杂的工作，因此需要大量地使用CASE工具辅助进行。
文章来源于领测软件测试网 https://www.ltesting.net/
