誤區三：建模意味著需要一個重量級的軟件開發過程
走入這個誤區（經常與誤區一有聯系）的項目組常常是連建模都徹底地放棄了，應為這樣的軟件開發過程對 他們來說太復雜太沉重了。這不亞于一場天災。
事實分析：你可以用一種輕靈的方式取而代之。關于用簡單的工具進行簡單地建模的詳細內容可參看Agile Modeling(AM)。而且，你可以丟棄你的模型當使命完之后，同樣也可以很基本的方式進行建模（比如，從辦 公桌起來，來到白板前就開始構略草圖）。只要你愿意，你就可以輕松地建模。
誤區四：必須“凍結”需求
這個要求常常來自高級經理，他們確切地想知道他們從這個項目組能得到什么東西。這樣的好處就是在開發 周期的早期確定下需求，就可以確切地知道所要的是一個什么樣的東西；缺點就是他們可能沒有得到實際上 所需要的（不全或錯誤的需求，譯者）。
事實分析：變化總會發生的。由于優先級的變化和逐漸對系統有了更進一步的理解，都會引起需求的變化。 與凍結需求相反，估計項目成功的風險，盡量去接受變化而且相應地采取行動，就象XP所建議的一樣。
誤區五：設計是不可更改的
如同誤區四，要求每一個開發人員必須嚴格遵從“設計“，導致開發人員為了符合“設計“而作了錯誤的事情或以錯誤的方式作正確的事情�；蛘呤呛唵蔚睾雎粤嗽O計，否定了所有設計可能帶來的好處。凍結了設計，你就不能從在項目進程中所學到知識進一步獲益。另外一個很大的趨勢就是開發出大量的文檔而不是實 際的軟件，使用面向文檔的CASE工具而不是能給項目帶來實際價值的面向應用的工具。
事實分析：事實上，設計會經常根據開發人員和數據庫管理員的反饋進行修改，因為他們是最接近實際應用 的人，通常他們對技術環境的理解要好于建模者。我們必須的面對這樣一個事實：人無完人，他們所作的工 作也不可能盡善盡美。難道您真的想將一個并不完善的設計固定下來而不再去修改其中的錯誤嗎？另外，如 果需求并沒有被凍結，其實就意味著你不能凍結你的設計，因為任何需求的修改勢必影響設計。對之，正確 的態度是：只要你的代碼還在改動，涉及就沒完。
誤區六：必須使用CASE工具
建模常常被認為是一項復雜的工作，因此需要大量地使用CASE工具輔助進行。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
