誤區1：在項目的需求分析階段，開發方與客戶方在各種的問題的基本輪廓上達成一致即可，具體細節可以在以后填充。因為無論開始時有多么細致， 以后對需求的修改幾乎是必然的。分析：這是一種非常危險的思想。實際上許多軟件項目失敗的最主要的原因就是需求階段對問題的描述不夠細致，導致后來預算超出或者時間 進度達不到要求。正確的做法是：在項目需求分析階段，雙方必須全面地盡可能細致地討論項目的應用背景、功能要求、性能要求、操作界面 要求、與其他軟件的接口要求，以及對項目進行評估的各種評價標準。并且，在需求分析結束以后，雙方還要建立可以直接聯系的渠道，以盡 早地對需求變動問題進行溝通。
誤區2：軟件項目的需求可以持續不斷的改變，而且這些改變可很容易地被實現。分析：的確，在具體實際中由于種種原因客戶方很難在需求分析階段全面而準確地描述所有問題。隨著開發進度的推進，往往會有一些需求的 改變。而現代軟件工程理論也利用軟件的靈活性特點通過各種方式來適應這種情況。不過，這并不表明“軟件項目的需求可以持續不斷的改變 ，而且這些改變可很容易地被實現”。實踐表明：隨著開發進度的推進，實現軟件需求更改所需要的代價呈指數形式增長。假定在需求分析階 段實現需求更改需要花費1倍的代價；那么，在系統設計和編碼階段，需要花費1.5-6倍的代價；在系統測試階段需要花費10-20倍的代價；在軟 件版本發布以后，甚至可能要花費60-100倍的代價。由此可見，在項目開展過程中，軟件需求的改變應當盡量早地提出。這樣才可能花費少， 容易被實現。
誤區3：軟件程序主要由代碼組成，因此編碼階段是整個軟件項目的最重要的階段，應該給與大量的時間，并且集中主要的資源。分析：與以前相比，由于軟件的規模和復雜度的增加，以及半自動化軟件代碼開發平臺的出現，現代軟件項目管理的中心發生了轉移--不是 著重編碼階段，而是著重系統總體/詳細設計階段。一般說來，在現代軟件項目管理中各種資源的合理分配比例是：項目論證、風險評估階段3% ，項目需求分析階段8%，系統總體/詳細設計階段45%，編碼階段10%，系統測試階段34%。
誤區4：為了便于代碼的維護修改，在系統的詳細設計階段文檔工作應該做到寫出所有程序的偽碼。分析：通常偽碼的最大作用是對程序的算法流程進行描述，便于人們深入了解程序的功能和實現過程�？梢�，在一定程度上偽碼的確有利于對 程序代碼的維護和修改。但是，我們知道為了保證項目文檔和程序代碼的一一對應關系，維護程序代碼的時候同時需要對項目文檔進行維護。偽碼和程序代碼是非常接近的，對偽碼進行維護的話，相當于進行了2倍的程序代碼維護。工作量是很大的。所以切合實際的方式應該是對一般 的程序文檔做到程序流程圖即可，對于涉及了較復雜算法的才需要偽碼。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
