按照一般的軟體專案週期來說，一般要經歷以下幾個階段：

    一、定義階段。包括多專案的可行性進行分析，對系統採用的架構、資料進行規劃，與客戶確認需求並簽訂相關合同。該階段就是一個規劃、打基礎的階段，專案未來做出什麼樣子，能夠達到什麼樣的高度，都是由這裡決定的。

    在這個階段，很重要的一個過程：需求分析，往往會被忽略。對一個一般的業務系統來說，系統的根本目的，是為客戶的業務管理等做服務的，也就是，一切是為客戶的需求做服務的，對應的，就必須把客戶的需求充分重視起來。

    很明顯的，客戶的需求有重要的，有不重要的；有合理的，也有不合理的；有明確的，也有隱含的，等等。總之，需求是多樣的。如何把這些需求，轉化成為正確的功能，讓系統能夠與客戶進行順利的銜接，這就是需求分析要乾的事情。

    需求分析，首先要區分哪些是必要的、不可缺少的需求。就跟人的需求分層次一樣，客戶的需求也是分層次的。對應人第一級需求，生存的需求，企業也是一樣的。直接關係企業生存的需求，也就是能夠創造效益的需求，必然是最迫切的，也是系統必須解決的問題。解決了生存問題，才能進一步的去考慮情感、社會貢獻等的高層次需求。當然，需求的分級必須考慮各類顯式及隱式的效益。

    需求分析，還有一個重要的問題，就是要充分發掘隱含的需求。在記錄客戶需求表達的同時，還應該充分考慮客戶表達需求的場景、背景等相關內容，因為這些，往往隱含了許多必要的需求。而客戶在表達的同時，往往會因為工作習慣的關係，慣性的忽略掉了。當然，在發掘隱藏需求或者避免需求陷阱的方面，業務專家的重要性也就體現出來了。

    做了好了現有的需求分析規劃，還應該適當的對客戶需求進行優化，並將優化後的需求反饋給客戶。畢竟，軟體系統的開發上線，必然會對原有的業務關係進行衝擊。系統開發的原則的尊重原有業務，並對原業務進行優化升級，以取得更好的效益。說白了，資訊化了，肯定要變的。如何變，這才是關鍵。

    以政府專案為例簡單說明。政府專案說的簡單點，就是“嚴格與靈活”表現非常充分的。首先嚴格，就是行為方式必須符合對應的法律法規等，半點都不能突破，這個原則絕對是嚴格執行的；靈活呢，就是在規則的允許下，過程可以是任意多變的。

    總之，定義階段結束，實際上專案的未來基本上就已經是可預期、可見的，專案的成功程度，也是可以估算的。就跟蓋大樓一樣，這就是選好了地基、做好了設計規劃圖、大體的材料等。

    二、開發階段。實際上就是對定義階段的內容進行充實、實現，也就是一般說的概要設計、詳細設計、程式碼實現、測試等環節。這些環節是在定義階段的框架下，對系統功能進行充實、完善。一般來說，到了這個階段，只要過程質量控制的不錯，專案出現意外的可能性不大。國家標準裡面也有各類標準文件，按著做就基本問題不大了。

    概要設計著重要說明白的是，需求是如何對應到功能的，各個功能如何配合實現某項需求；詳細設計說明的是功能具體如何實現，各種資料流如何運作，操作如何對其進行影響。

    跟蓋房子一樣的，這個時候可以分包給施工隊，只要施工隊按照設計圖走，一般不會出現質量問題。

    這個過程中，忌諱的是各種實驗性質的技術使用，即應用各類不是完全掌握的技術。技術本身可能不存在問題，但是如果掌握不好，就容易遭成“豆腐渣”工程。

    三、運維階段。運維階段就是對系統進行保養。保養的好壞，關係到系統的使用年限。此階段，主要是解答各類使用者問題，還有是根據客戶的個性化要求進行重新裝修。重要的問題，就是要順延設計思路，控制住客戶的需求，千萬不要因為使用者的強烈要求，就把房間的承重牆給砸了。

    其實，專案的各個階段都是相互關聯的，並沒有嚴格的界限。每個階段的任何行為，都會對其他階段造成影響。但明顯的，前階段對後階段的影響、限制更大一些。前面多做一些，後面就會相應的少一些，指望在後續階段解決前一階段的問題，付出的代價往往是巨大的。

    實際上，在許多公司，專案的各個階斷是分佈在不同的部門的，而且缺少明確的專案經理進行整體的統籌安排，造成了各個階段之間實際上的割裂。而系統上線執行後，面對客戶的卻經常是後階段的員工在負責，這就導致了是後階段在推動修改前階段的問題。這個工程的痛苦是誰參與誰知道。浪費人力物力不說，導致專案延期，不能按時交付等等，各種問題，領導也是意見多多。

    解決這個問題的一個關鍵點，就是必須有一個“強勢”的專案經理或者類似的人員，能夠貫穿整個專案，將專案的思想從開始就把握好節奏，並且能夠有能力彌補部門之間的間隙，保證各個階段之間的順利銜接。