隨著計算機硬體水平的不斷提高，計算機軟體的規模和複雜度也隨之增加。計算機軟體開發從「個人英雄」
時代向團隊時代邁進，計算機軟體專案的管理也從「作坊式」管理向「軟體工廠式」管理邁進。
這就要求軟體開發人員特別是
軟體專案管理人員更深一步地理解和掌握現代
軟體工程的理論方法，完成思想觀念上的轉變。筆者在此分析了10個在現代專案管理中思想觀念上容易陷入的誤區，希望能夠拋磚引玉，引發大家更多的思索和討論。
誤區1：在專案的需求分析階段，
開發方與客戶方在各種的問題的基本輪廓上達成一致即可，具體細節可以在以後填充。因為無論開始時有多麼細緻， 以後對需求的修改幾乎是必然的。分析：這是一種
非常危險的思想。實際上許多軟體專案失敗的最主要的原因就是需求階段對問題的描述不夠細緻，導致後來預算超出或者時間 進度達不到要求。正確的做法是：在專案需求分析階段，雙方必須全面地盡可能細緻地討論專案的應用背景、
功能要求、效能要求、操作介面 要求、與其他軟體的介面要求，以及對專案進行評估的各種評價標準。並且，在需求分析結束以後，雙方還要建立可以直接聯絡的渠道，以盡 早地對需求變動
問題進行溝通。
誤區2：軟體專案的需求可以持續不斷的改變，而且這些改變可很容易地被實現。分析：的確，在具體實際中由於種種原因客戶方很難在需求分析階段全面而準確地描述所有問題。隨著開發進度的推進，往往會有一些需求的 改變。而現代軟體工程理論也利用軟體的靈活性特點通過各種方式來適應這種情況。不過，這並不表明「軟體專案的需求可以持續不斷的改變 ，而且這些改變可很容易地被實現」。實踐表明：隨著開發進度的推進，實現軟體需求更改所需要的代價呈指數形式增長。假定在需求分析階 段實現需求更改需要花費1倍的代價；那麼，在系統
設計和編碼階段，需要花費1.5-6倍的代價；在
系統測試階段需要花費10-20倍的代價；在軟 件版本發布以後，甚至可能要花費60-100倍的代價。由此可見，在專案開展過程中，軟體需求的改變應當盡量早地提出。這樣才可能花費少， 容易被實現。
誤區3：軟體程式主要由**組成，因此編碼階段是整個軟體專案的最重要的階段，應該給與大量的時間，並且集中主要的資源。分析：與以前相比，由於軟體的規模和複雜度的增加，以及半自動化軟體**開發平台的出現，現代軟體專案管理的中心發生了轉移--不是 著重編碼階段，而是著重系統總體/詳細設計階段。一般說來，在現代軟體專案管理中各種資源的合理分配比例是：專案論證、風險評估階段3% ，專案需求分析階段8%，系統總體/詳細設計階段45%，編碼階段10%，系統測試階段34%。
誤區4：為了便於**的維護修改，在系統的詳細設計階段文件工作應該做到寫出所有程式的偽碼。分析：通常偽碼的最大作用是對程式的演算法流程進行描述，便於人們深入了解程式的功能和實現過程。可見，在一定程度上偽碼的確有利於對 程式**的維護和修改。但是，我們知道為了保證專案文件和程式**的一一對應關係，維護程式**的時候同時需要對專案文件進行維護。偽碼和程式**是非常接近的，對偽碼進行維護的話，相當於進行了2倍的程式**維護。工作量是很大的。所以切合實際的方式應該是對一般 的程式文件做到程式流程圖即可，對於涉及了較複雜演算法的才需要偽碼。
誤區5：既然在專案人員配置中設定了專門的測試人員，那麼軟體所有的內部測試工作全部應該由測試人員完成。分析：軟體程式測試可以分為「白盒法」和「黑盒法」兩種方式。由於使用「白盒法」對測試人員各方面素質的種種要求，在進行程式測試時 測試人員總是最優先使用「黑盒法」。他們的工作方式往往是先對程式進行「黑盒法」測試；如果測試沒有通過，不得已這才考慮對程式** 進行「白盒法」測試。顯然，這種對「白盒法」有意無意的「逃避」，對軟體的可靠性和穩定性構成了威脅。如何解決這個問題？一方面需要 提高對測試人員的要求，另一方面也需要程式設計師完成部分的「白盒法」測試（實際上，程式設計師往往也是進行「白盒法」測試的最佳人選）。
技術部門的事情，與公司其他部門無關。分析：在競爭日益激烈的今天，軟體專案規模大、複雜度高而且時間要求緊迫。要想提高公司的軟體專案管理水平，這就需要提高公司的整體 參與意識，需要公司各個部門協同作戰。例如需要會計部門協助進行專案預算，財務管理和費用控制；需要研究部門（技術委員會）指派
專家協助進行各種風險評估，提供技術指導；需要後勤部門提供各種保障。
誤區7：在開發進度滯後的情況下，可以聘請更多的程式設計師加入到開發團隊中，通過增加人力資源來趕上進度。分析：在注重團隊開發的時代，開發方應該根據目前的軟體專案管理水平慎重考慮這個做法。如果新加入的程式設計師對目前軟體專案的應用行業 有一定了解，並且可以很快適應了開發方的專案管理方式、軟體開發風格、團隊協作氛圍；那麼"新人"的加入是有益的。否則，可能會"好 心好意做壞事"。因為儘管其個人能力很高，但是為了使其與大家一起協同工作，開發團隊不得不分出人手對其進行與專案有關的技術/業務培 訓，更重要的（也是難度最大的）是還要引導其融入團隊。這可能需要花費開發團隊許多時間和精力，很有可能使專案進度更慢。
誤區8：技術骨幹應該成為專案的專案經理，專案經理一定是所有專案成員中薪水最高的。分析：在"軟體作坊"時代，這是一種普遍使用而且效果不錯的方法；而在"軟體工廠"時代，這種方法卻帶來各種問題，有時甚至直接導致 專案失敗。究其原因這主要是因為隨著現代軟體開發分工的細化，對專案經理的要求也發生了根本的改變--最注重的不是其對某項專業技術 的掌握程度，而是其組織、領導、協調開發團隊的能力（當然，可以兩者均突出最好）。至於專案經理的薪水問題，這和定薪制度有很大關係 。通常，專案經理執行的是管理人員的薪酬體系，而其他人員執行的是技術人員的薪酬體系。專案經理的薪水在專案成員中是比較高的，但不 一定是最高的。有時候，為了激勵技術人員，專案中的技術骨幹得到的酬勞比專案經理要高。
誤區9：只有專案經理以及部門主管才會關心專案整體進度，程式設計師只關心自己的開發進度。分析：這是一種"官僚"的想法。實際上程式設計師作為團隊中的一員，他不僅僅是在打乙份工，更重要的是在參與一件"作品"的創作。在體味 工作的辛苦的同時，程式設計師更重要的是要享受創作的快感。專案經理不應該漠視程式設計師對"成就感"的追求，應該向每乙個人詳細描述最終" 作品"將會如何美妙和令人興奮，並且在到達最終目標的路上設立一系列的里程碑。每當專案整體推進到乙個里程碑的時候，專案經理應該把 這個訊息告訴每一位專案成員。實際上，這不僅僅可以讓所有的專案成員享受到階段勝利的喜悅，還可以激發大家更大的工作熱情，提高工作效率。
誤區10：為了保證專案繼續，為了留住核心程式設計師，加薪吧。分析：加薪可以說是很多企業在挽留程式設計師時所使用的常用方法。這一招可能暫時奏效，不過往往是人留下來了，但***也來了--加薪的 人未必見得多幹活，沒有加薪的人卻開始消極怠工了。其實，專案的進行過多地依賴程式設計師的個人技術是「作坊」時代沿襲下來的「陋習」。 既然it行業人員的流動是無法控制的，現在專案的執行應該更加注重團體的力量，應該更多的考慮公司整體技術水平和核心技術能力。例如形 成公司自己的專家知識庫，類/函式庫，第三方控制項庫，擁有自主版權的開發平台等。另外，實際上程式設計師萌生去意的原因很大程度上不是薪水 ，而是缺少激勵和尊重。這需要專案經理使用「老土」一點的辦法，找適當的時機對程式設計師做一做思想工作，向其描述專案的美好未來，讓其 感受關心和尊重。總之，要從多方面著手保證專案的順利開展，而不是簡單地加薪。
自上而下的軟體開發和自下而上的軟體開發
自上而下 top down 開發模式是指從乙個應用的最高點開始開發。從最高點逐步往下層編碼，直到開發完所有的任務。一旦寫完了最下層的 開發任務就完成了。使用這種方式，你需要設計 編寫出所有你需要的但還沒有實現模擬介面 服務 偽 自下而上 bottom up 開發模式是指從乙個應用的最底層開始開發。這...
python軟體開發目錄 軟體開發目錄規範
為了提高程式的可讀性與可維護性，我們應該為軟體設計良好的目錄結構，這與規範的編碼風格同等重要。軟體的目錄規範並無硬性標準，只要清晰可讀即可，假設你的軟體名為foo，筆者推薦目錄結構如下 foo core 存放業務邏輯相關 core.py api 存放介面檔案，介面主要用於為業務邏輯提供資料操作。ap...
軟體開發的效率
泰巖網路工作室 吳旻軟體開發專案不能如期完成似乎是普遍的事實，想想連微軟這種霸權級的公司開發乙個 vista 都要推遲了又推遲，其它公司的專案延期一些又算得了什麼呢？應該說，關於開發管理的模式很多，比如近些年流行的 rup xp什麼的，都對軟體開發中的問題提出了自己的理解。但是今天我在這裡想談的不是...