隨著計算機硬件水平的不斷提高，計算機軟件的規(guī)模和復雜度也隨之增加。計算機軟件開發(fā)從“個人英雄”時代向團隊時代邁進，計算機軟件項目的管理也從“作坊式”管理向“軟件工廠式”管理邁進。這就要求軟件開發(fā)人員特別是軟件項目管理人員更深一步地理解和掌握現代軟件工程的理論方法，完成思想觀念上的轉變。筆者在此分析了10個在現代項目管理中思想觀念上容易陷入的誤區(qū)，希望能夠拋磚引玉，引發(fā)大家更多的思索和討論。
　　誤區(qū)1：在項目的需求分析階段，開發(fā)方與客戶方在各種的問題的基本輪廓上達成一致即可，具體細節(jié)可以在以后填充。因為無論開始時有多么細致， 以后對需求的修改幾乎是必然的。分析：這是一種非常危險的思想。實際上許多軟件項目失敗的最主要的原因就是需求階段對問題的描述不夠細致，導致后來預算超出或者時間 進度達不到要求。正確的做法是：在項目需求分析階段，雙方必須全面地盡可能細致地討論項目的應用背景、功能要求、性能要求、操作界面 要求、與其他軟件的接口要求，以及對項目進行評估的各種評價標準。并且，在需求分析結束以后，雙方還要建立可以直接聯系的渠道，以盡 早地對需求變動問題進行溝通。
　　誤區(qū)2：軟件項目的需求可以持續(xù)不斷的改變，而且這些改變可很容易地被實現。分析：的確，在具體實際中由于種種原因客戶方很難在需求分析階段全面而準確地描述所有問題。隨著開發(fā)進度的推進，往往會有一些需求的 改變。而現代軟件工程理論也利用軟件的靈活性特點通過各種方式來適應這種情況。不過，這并不表明“軟件項目的需求可以持續(xù)不斷的改變 ，而且這些改變可很容易地被實現”。實踐表明：隨著開發(fā)進度的推進，實現軟件需求更改所需要的代價呈指數形式增長。假定在需求分析階 段實現需求更改需要花費1倍的代價;那么，在系統(tǒng)設計和編碼階段，需要花費1.5-6倍的代價;在系統(tǒng)測試階段需要花費10-20倍的代價;在軟 件版本發(fā)布以后，甚至可能要花費60-100倍的代價。由此可見，在項目開展過程中，軟件需求的改變應當盡量早地提出。這樣才可能花費少， 容易被實現。
　　誤區(qū)3：軟件程序主要由代碼組成，因此編碼階段是整個軟件項目的最重要的階段，應該給與大量的時間，并且集中主要的資源。分析：與以前相比，由于軟件的規(guī)模和復雜度的增加，以及半自動化軟件代碼開發(fā)平臺的出現，現代軟件項目管理的中心發(fā)生了轉移——不是 著重編碼階段，而是著重系統(tǒng)總體/詳細設計階段。一般說來，在現代軟件項目管理中各種資源的合理分配比例是：項目論證、風險評估階段3% ，項目需求分析階段8%，系統(tǒng)總體/詳細設計階段45%，編碼階段10%，系統(tǒng)測試階段34%。
　　誤區(qū)4：為了便于代碼的維護修改，在系統(tǒng)的詳細設計階段文檔工作應該做到寫出所有程序的偽碼。分析：通常偽碼的最大作用是對程序的算法流程進行描述，便于人們深入了解程序的功能和實現過程。可見，在一定程度上偽碼的確有利于對 程序代碼的維護和修改。但是，我們知道為了保證項目文檔和程序代碼的一一對應關系，維護程序代碼的時候同時需要對項目文檔進行維護。偽碼和程序代碼是非常接近的，對偽碼進行維護的話，相當于進行了2倍的程序代碼維護。工作量是很大的。所以切合實際的方式應該是對一般 的程序文檔做到程序流程圖即可，對于涉及了較復雜算法的才需要偽碼。
　　誤區(qū)5：既然在項目人員配置中設置了專門的測試人員，那么軟件所有的內部測試工作全部應該由測試人員完成。分析：軟件程序測試可以分為“白盒法”和“黑盒法”兩種方式。由于使用“白盒法”對測試人員各方面素質的種種要求，在進行程序測試時 測試人員總是最優(yōu)先使用“黑盒法”。他們的工作方式往往是先對程序進行“黑盒法”測試;如果

    項目經理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://m.opto-elec.com.cn/pmqhd/index.html