· 不切實際的計劃： 沒有充分考慮問題的復雜性 ，把一個龐大的工程限定在非常短的時間之 內 ，出現問題是不可避免的。因此我們應該拿出足夠多的時間作計劃、設計、測試、修改錯誤、回歸測試、整理文檔，不要把長時間熬夜作為軟件公司的家常便飯。
· 需求分析不充分：如果需求分析不清晰、不完整、太籠統或者不具有可測試性，那么一定會 出現問題。 這就要求我們在動手開發之前一定要有完整的，詳細的，可維護的，可測試的需 求分析，該需求分析一定要得到各方的認可
· 不充分的測試： 在系統崩潰和用戶強烈抱怨之前，沒有人知道是不是存在問題。因此要盡早 地開展測試，問題修改之后要盡快地進行回歸測試，一定要給測試和修改問題留出足夠的時間
· 交流不充分：如果開發人員與開發人員之間 ，開發人員與項目管理組之間，項目組和用戶之 間不能充分的交流的話，也會出現問題。因此使用新聞組、電子郵件以及其他的網絡化的錯誤 跟蹤工具等等方式來加強整個團隊的溝通和交流是必要的。
· 不斷增加新的特性：在開發完成之后，不斷有新的需求，這是最常見的問題。 因此一定要最 大限度地堅持最初的需求分析，如果萬不得已，確實需要增加新的需求，那么一定要更改相關 的計劃，如果可能在設計階段最好使用快速原型法，讓用戶知道他們希望的系統是個什么樣子 的，這樣可以在初期更好地聽從用戶的意見。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
