關鍵字：誤區隨著計算機硬件水平的不斷提高，計算機軟件的規模和復雜度也隨之增加。計算機軟件開發從“個人英雄”時代向團隊時代邁進，計算機軟件項目的管理也從“作坊式”管理向“軟件工廠式”管理邁進。這就要求軟件開發人員特別是軟件項目管理人員更深一步地理解和掌握現代軟件工程的理論方法，完成思想觀念上的轉變。筆者在此分析了10個在現代項目管理中思想觀念上容易陷入的誤區，希望能夠拋磚引玉，引發大家更多的思索和討論。
誤區1：在項目的需求分析階段，開發方與客戶方在各種的問題的基本輪廓上達成一致即可，具體細節可以在以后填充。因為無論開始時有多么細致，以后對需求的修改幾乎是必然的。分析：這是一種非常危險的思想。實際上許多軟件項目失敗的最主要的原因就是需求階段對問題的描述不夠細致，導致后來預算超出或者時間進度達不到要求。正確的做法是：在項目需求分析階段，雙方必須全面地盡可能細致地討論項目的應用背景、功能要求、性能要求、操作界面要求、與其他軟件的接口要求，以及對項目進行評估的各種評價標準。并且，在需求分析結束以后，雙方還要建立可以直接聯系的渠道，以盡早地對需求變動問題進行溝通。(范圍的核實和項目驗收都要根據范圍基準進行。因此前期的范圍說明書和范圍的基線至關重要)
誤區2：軟件項目的需求可以持續不斷的改變，而且這些改變可很容易地被實現。分析：的確，在具體實際中由于種種原因客戶方很難在需求分析階段全面而準確地描述所有問題。隨著開發進度的推進，往往會有一些需求的改變。而現代軟件工程理論也利用軟件的靈活性特點通過各種方式來適應這種情況。不過，這并不表明“軟件項目的需求可以持續不斷的改變，而且這些改變可很容易地被實現”。實踐表明：隨著開發進度的推進，實現軟件需求更改所需要的代價呈指數形式增長。假定在需求分析階段實現需求更改需要花費1倍的代價；那么，在系統設計和編碼階段，需要花費1.5-6倍的代價；在系統測試階段需要花費10-20倍的代價；在軟件版本發布以后，甚至可能要花費60-100倍的代價。由此可見，在項目開展過程中，軟件需求的改變應當盡量早地提出。這樣才可能花費少，容易被實現。(不應該稱為誤區了，現在估計誰都不會認為需求可以持續不斷改變)
誤區3：軟件程序主要由代碼組成，因此編碼階段是整個軟件項目的最重要的階段，應該給與大量的時間，并且集中主要的資源。分析：與以前相比，由于軟件的規模和復雜度的增加，以及半自動化軟件代碼開發平臺的出現，現代軟件項目管理的中心發生了轉移——不是著重編碼階段，而是著重系統總體/詳細設計階段。一般說來，在現代軟件項目管理中各種資源的合理分配比例是：項目論證、風險評估階段3% ，項目需求分析階段8%，系統總體/詳細設計階段45%，編碼階段10%，系統測試階段34%。(這個跟軟件項目的規模密切相關。對于規模小于2萬行代碼的，或者說采用敏捷或快速開發的，或者說架構已經確定的改進型號項目，編碼時間至少要占30%；而對于源代碼規模超過50萬行的大型軟件項目,重點則是在需求和系統設計上面，編碼時間一般為10%)
誤區4：為了便于代碼的維護修改，在系統的詳細設計階段文檔工作應該做到寫出所有程序的偽碼。分析：通常偽碼的最大作用是對程序的算法流程進行描述，便于人們深入了解程序的功能和實現過程�？梢�，在一定程度上偽碼的確有利于對程序代碼的維護和修改。但是，我們知道為了保證項目文檔和程序代碼的一一對應關系，維護程序代碼的時候同時需要對項目文檔進行維護。偽碼和程序代碼是非常接近的，對偽碼進行維護的話，相當于進行了2倍的程序代碼維護。工作量是很大的。所以切合實際的方式應該是對一般的程序文檔做到程序流程圖即可，對于涉及了較復雜算法的才需要偽碼。(應該深刻理解源代碼就是設計的一些重點觀點和思路，因此詳細設計輸出的代碼模型一般是不拋棄的，編碼人員可以直接在該代碼模型基礎上進行編碼)
誤區5：既然在項目人員配置中設置了專門的測試人員，那么軟件所有的內部測試工作全部應該由測試人員完成。分析：軟件程序測試可以分為“白盒法”和“黑盒法”兩種方式。由于使用“白盒法”對測試人員各方面素質的種種要求，在進行程序測試時測試人員總是最優先使用“黑盒法”。他們的工作方式往往是先對程序進行“黑盒法”測試；如果測試沒有通過，不得已這才考慮對程序代碼進行“白盒法”測試。顯然，這種對“白盒法”有意無意的“逃避”，對軟件的可靠性和穩定性構成了威脅。如何解決這個問題？一方面需要提高對測試人員的要求，另一方面也需要程序員完成部分的“白盒法”測試（實際上，程序員往往也是進行“白盒法”測試的最佳人選）。(估計很少有人這樣認為，所以不應該稱為誤區)
文章來源于領測軟件測試網 http://www.kjueaiud.com/
