加強專案的過程管理，可以及時發現專案中出現的弊端，防微杜漸，是保證專案實施的必要手段。
一 專案組的成立與分工：
現在的軟體開發，除非小系統，一般都是多人同時參與開發，因此，合理的分工將提高工作的效率，甚至影響專案的成敗！分工時，應結合專案組成員的個人優勢，根據專案所涉及的不同方面進行分工，使不同的（某些）人擔任不同的角色。這樣，他們在平時的工作學習中也就帶有一定的方向性。 在分工時，其職責範圍最好不重疊，以免出現相互推委的現象。
在專案組成立後，應制定出該項目的一系列規範標準，比如：需求調查**式；需求說明書格式；資料庫命名規範；程式設計規範；會議紀要格式等，並由此逐步建立自己的規範體現。
如果在專案中有其它軟體公司人員的參與，則可以只對該公司在專案中的負責人進行管理，但最好是要他提供該公司參與專案的人員安排、個人技術強項等資訊，做到心中有數。
二 重要會議的記錄
對於專案中的重要會議，要以適當的格式，記錄本次會議的基本情況和達成的共識，並在會後發給參會各方人員確認。這主要是防止有些客戶隨意變更需求，並且記性不大好的情況．
三 專案計畫
凡事預則立，不預則廢。軟體專案，由於其涉及人員眾多、行業多樣、對軟體系統的理解也參差不齊，這就導致軟體所含內容的不確定性！因此，乙個軟體專案，如果沒有具體、明確的專案計畫，那麼這個軟體專案通常會導致不同程度的失敗——專案（一再）延期；交付的軟體bug眾多，和使用者的需求相去甚遠，或者專案最終徹底over。乙個沒有明確計畫的專案，專案組的成員對當前的工作內容模糊不清，也不知道專案的各個階段持續的時間範圍，當然也就不能夠給領導提供比較準確的專案進度。在專案的進行當中，很可能出現某個時間段很閒，而另外的時間段卻忙得昏天黑地的現象。反過來，有了具體的專案計畫，什麼時間做什麼事，就會心中有數（儘管計畫和實際可能存在差距，但專案的大體大體進度是清楚的）；專案在不同階段會產生什麼樣的成果物，心中有數；專案剩餘工作量、會在什麼時間完成，心中有數。總之，越是大的專案，越是時間緊迫的專案，越需要有專案計畫。
專案計畫，一般包括專案的總體計畫和階段計畫，但無論是那種計畫，都應該得到計畫中所涉及各方的認可。
１ 專案總體計畫
在專案開始的時候，一般會獲得如下資訊：軟體要實現的大概功能；軟體交付時間；使用者在專案開發期間是否有重要的審查活動；使用者對軟體的特殊要求等。專案組負責人應根據獲得的資訊，結合部門的技術等各種因素，確定出該專案所涉及的技術方向、是外包，還是與其它單位合作，從而擬訂出該軟體專案從頭至尾的乙個總體計畫，至少應包括需求調研（需求調查、概要設計、詳細設計）、程式編寫、專案測試、部署和維護階段。如果涉及到新技術，在計畫中還可以包括技術研究；如果使用者對軟體有階段驗收計畫，或者專案涉及到其它單位合作，則也可以將安排納入總體計畫。
總體計畫中的各個具體階段，應包括開始時間、結束時間、參與人（負責人），要完成的內容（或階段成果物）。 總體計畫，是乙個比較初的計畫，它體現的是整個專案的大體進度安排。其時間精度可以以月（上旬、中旬、下旬）為單位。
２ 階段計畫
在專案進行的各個階段，應根據專案的總體計畫，制定出當前階段的階段計畫或者是下階段的計畫。階段計畫具有很強的目的性，除了具體安排階段要完成的內容外，還應包括本階段的里程杯（或者階段成果物的驗收）。以需求調研為例：專案所需求調研包括那些部門（單位）、各部門業務調研時間、（調研後的）資料整理、（將整理的資料返回給相關業務人員確認）資料確認，將各個部門的需求合併，整理出需求說明書初稿送相關人員確認；需求評審（可能有不同意見，存在少量需求更改），最後需求定稿。
階段計畫可以以天為單位。在階段計畫下，還可以指定月計畫、周計畫（周計畫包括了日計畫）。
如果專案有其它軟體公司參與，則該公司的階段計畫也應納入管理之中。
３ 計畫變更
計畫和實施通常存在差距，因此，在專案的實施過程中，應根據專案的實際執**況，加以修正：對於差距較大的，應修改專案總體計畫，階段計畫內完不成計畫任務的，應修改階段計畫。由於計畫的變更，專案總體計畫和階段計畫也存在版本問題。
對於計畫變更的，應客觀地分析、找出其原因，並以適當的方式告訴專案涉及的所有人員。
最後，所有的專案計畫，應以紙質或電子文件方式，告之專案涉及的各方人員，確保專案的參與人員都清楚專案的安排情況；
４ 相關輔助軟體
專案計畫的制定，可以採用word、excel等軟體。比較專業的為microsoft project.
四 需求調研
這裡所指的需求調研包括：需求調查（面向使用者）——概要設計（界於使用者和專業人員之間）——詳細設計（依託具體的程式語言、框架技術，完全面向專業人員）三部分。
需求分析的好壞直接關係專案的成敗。理論上，需求階段的時間佔專案總體時間的1/3左右，其參與人員一般是資深的軟體開發人員，因為需求調研，並不只是聽客戶的描述（事實上，很多客戶對自己要做什麼事，也不一定描述得清楚），還要取捨和挖掘客戶的潛在需求。因此，企業軟體專案的關鍵就在於需求的管理和流程的建模。
在需求調研時，最大的困難是「使用者根本不知道自己要幹什麼」，最常犯的錯誤是「把現有的落後流程要求計算機重複一遍」。使用者在提需求是，往往是說出一大堆認為都是「必不可少、必須立馬實現的」需求，分不清需求的主次。這就要求我們在需求調研時要擺正自己的位置：從客戶的利益立場出發，分析客戶提出的需求是否合理（同時要初步估計實現該需求的難度）；客戶的需求，有多大程度上是必要的？還是只是一種客人喜好？客戶的那些需求是應該有，但客戶目前是提不出來（這屬於客戶需求的挖掘，取決於調研人員的經驗）的。
在對需求的取捨上，一般對使用者提出的需求進行分級管理：
一級需求（urgent）：是關鍵性的需求，如果不滿足這些需求，就意味著整個專案不能交付使用，前期工作也全部否定，這是必須滿足的需求。
二級需求（necessary）：後續關鍵性需求。如果不滿足，新的專案無法提交或繼續。主要是指新模組的關鍵性基礎元件；
**需求（needed）：後續重要需求。它不滿足會是整體工作價值下降；
前**需求是必須實現的。
四級需求(better)：改良型需求，主要指介面和使用方式；
五級需求（useful）：個人喜好，沒有根據一定帶來好處的需求；
對於需求不定（或者客戶自己都不知道要做什麼，他們通常是隨便的提出一些需求，然後說「你們先做個東西出來我們看了再說」）的情況，可以採取「系統原型」的方式和客戶交流。但要求調查人員懂一定的專業技術。
需求調研合格的檢驗的標準：把自己放在某個崗位上，能否比較順利的完成現行業務的處理。
在需求調研與資料庫設計的先後順序上，應是先有需求調研——產生需求說明書，然後才是在此基礎上設計資料庫。需求說明書，它是面向使用者的，主要分析的是業務流程，然後由業務流程分析所涉及的資料流。
對於需求階段所採用的工具軟體有：word、visio、powerdesigner或者採用物件導向的uml建模工具rose2003、rational xde (for .net)等。
五 加強功能測試
測試，按功能有白盒測試（結構測試）、黑盒測試（功能測試）之分。按測試目的，可以分為單元測試、整合測試、效能測試、壓力測試等。其測試方法除手工測試外，也可借助工具軟體（如junit，nunit，quicktest等）進行測試。
軟體測試屬於qa的一部分。
經個人整理，初次在ｂｌｏｇ上發表！
單個專案的管理過程
專案過程 乙個過程指為了得到預先指定的結果而要執行的一系列相關的行動和活動。乙個專案至少需要4個過程 1 技術類過程 指單純的技術實施活動 2 管理類過程 按時間先後劃分，分為 啟動 計畫 執行 監控 收尾 3 支援類過程 如配置管理過程等 4 改進類過程 如總結經驗教訓，部署改進等過程 專案管理過...
PMP筆記 三 單個專案的專案管理過程
單個專案的專案管理過程 專案管理工程分為五個過程 1.啟動過程組 獲得授權，定義乙個新專案或現有專案的乙個新階段，正式開始該專案和階段的一組過程。包括 制定專案章程 2.規劃過程組 明確專案範圍，優化目標，為實現目標而制定行動方案的一組過程。包括 專案整合管理知識領域 2.1.制定專案管理計畫 專案...
專案的知識管理
隨著軟體專案的功能越來越複雜，技術越來越先進，分工越來越細緻，資訊越來越龐雜，互動越來越頻繁，對專案的有效控制越來越缺乏，對專案的規模 進度 資源估算越來越困難，專案的可交付產品越來越豐富，因此，知識管理對軟體專案管理的重要性日益顯現，也引起了越來越多人的重視。遊戲設計 專案的知識管理 專案的知識管...