軟體開發中專案管理的注意事項引言：軟體行業從20世紀60年代開始作業系統的研發，到20世紀90年代中期行業快速發展。從原有的作坊式開發到目前團隊協作完成，從早期的技術力量競爭到現有的專案成本控制競爭，從面向結構到物件導向再到面向服務架構，專案管理被提到一定的高度，如何有效的經營專案來降低風險、控制成本，確保專案進度流暢，在有效的時間內保質、保量的完成驗收。
成為不少專案管理人士的追求目標。結合個人專案管理實踐，本人有幾點管理注意事項與大家一起分享。
開發模型確定
乙個專案的好壞，開發模型優良是專案成功重要保障，有了好的開發模型我們可以很好的控制專案進度、降低風險。所以我們在專案開始前首先需要確定專案的開發模型。這裡我們建議採用迭代式的開發模型。
我們知道原有早期傳統的開發模型是乙個文件驅動的流程，它將整個軟體開發過程劃分為順序相接的幾個階段，每個階段都必需完成全部規定的任務後才能夠進入下乙個階段。專案開始首先完成系統需求規格說明書，之後才能夠進入概要設計階段，編碼則在系統設計完成之後進行。這就意味著只有當所有的系統模組全部開發完成之後，我們才進行系統整合，對於乙個由很多個模組組的複雜系統來說，這是乙個非常艱鉅而漫長的工作，且存在著潛在的風險。
如：需求或者設計中的錯誤無法在專案早期發現，只有在系統交付客戶之後才能發現原先對於需求的理解是錯誤的，系統設計的錯誤也只有在測試階段才能被發現。
對於專案風險的控制能力較弱，往往專案風險只能隨著專案結束才能逐步降低，同時也只有經過系統測試之後，才能確定設計是否能夠真正滿足系統需求。
軟體專案常常延期完成或開發費用超出預算專案開發進度往往會被意外發生的問題所打亂，需要進行返工或其他一些額外的開發周期，造成專案延期或費用超支。
專案管理人員專注於文件的完成和審核來估計專案的進展情況所以專案經理對於專案狀態的估計往往是不準確的，當他回答系統已完成了80%的開發任務時，剩下20%的開發任務實際上消耗的是整個專案80%的開發資源。
在傳統的瀑布模型中，早期是無法發現，需求和設計中的問題，只有當系統第一次整合後，這些設計缺陷才會在測試中暴露出來，需求缺陷則需要等到系統與使用者見面後，方可暴露。從而導致一系列的返工：重新設計、編碼、測試，進而導致專案的延期和開發成本的上公升。
為了解決傳統軟體開發流程中的問題，我們建議採用迭代化的開發方法來取代瀑布模型。在瀑布模型中，我們要完成的是整個軟體系統開發這個大目標。在迭代化的方法中，我們將整個專案的開發目標劃分成為一些更易於完成和達到的階段性小目標，這些小目標都有乙個明確的階段性評估標準。
迭代就是為了完成一定的階段性目標而所從事的一系列開發活動，在每個迭代開始前都要根據專案當前的狀態和所要達到的階段性目標制定迭代計畫，整個迭代過程包含了需求調研、軟體設計、軟體實現、版本整合、軟體測試、軟體發布和產品交付等
各種型別的開發活動，迭代完成之後需要對迭代完成的結果進行評估，並以此為依據來制定下一次迭代的目標。
開發計畫制定
確定好專案的開發模型，一整套配套可行的專案開發計畫是開發過程中進度控制的標準，同樣是使用者、公司管理層了解專案進展的依據。通常專案管理人員、需求人員和使用者根據使用者原始需求（可以是專案方案書或者是建議書），一起定義整個專案過程中的專案迭代過程個數以及每個迭代過程的開發目標和範圍。
軟體開發專案管理
軟體開發專案管理，補習對軟體開發專案的工作範圍 可能遇到的風險 需求的資源 要實現的任務 經歷的里程碑 話費的工作量，以及進度的安排等等做到心中有數。而軟體專案管理可以提供這些資訊。軟體具有可見性差 定量化難等特殊性。但通常可以 根據以往開發類似軟體的經驗來進行成本估算。將軟體專案劃分為若干個子系統...
軟體專案管理在高校軟體開發中的應用
作者 林琳周躍飛 矽谷 2008年第18期 摘要 不少高校在做軟體研發時，尤其是自用軟體，重點更集中於科技創新，而對於在軟體專案小組中引入專案管理的認知度還未達成共識。以中國民航飛行學院廣漢分院飛行教學管理管理資源網的研發為例，簡要闡述專案管理在高校軟體開發中具體應用。關鍵詞 專案管理專案經理需求規...
軟體開發專案的風險管理
作者 蘭燕子 1月27日參加了專案管理聯盟組織的 北京專案管理愛好者聚會 我被易風邀請做了乙個主題演講，其實不是什麼演講，只是結合理論談了自己的一些想法和工作中遇到過的經驗教訓，更主要的目的是給大家出乙個討論和交流的主題，希望能起個拋磚引玉的作用。我講的主題是 軟體開發專案的風險管理，因為我認為風險...