專案的時間、成本及質量的三大要素是缺一不可。這三方面的符合程度直接決定了專案的成敗與否。那麼如何做好專案的質量管理呢？一起來學習學習！
1、分析階段
專案的開始階段，也是質量控制的開始。在這個階段中，主要的工作是從客戶方獲得足夠多的專案需求，並準確地記錄在案，而且要使得專案組的成員對於需求足夠得了解。先說說這個專案的基本情況：一個資訊管理系統，而且是在原來的版本上進行的功能增加。專案組的成員，除了我以前參加了前一個版本的開發，其它的人員都不瞭解這個專案。就是這樣的一個專案，在開始階段，我先是安排了組員對以前版本的需求文件進行了閱讀，並安裝使用了軟體。隨後對新的需求進行了研究，分析了它們對於原有系統的影響。由於是在舊有系統的文件進行增加，所以加入的新內容並不是很多，需求文件很快就完成了。所謂的分析階段的里程碑也就結束了。
在需求階段"順利"結束的同時，問題也隨之留下來，並對後面的階段起到了"乘數效應"――影響變得越來越大：
A. 對舊系統的理解不足
由於開發人員沒有參與過上一個版本的開發工作，他們對於舊系統並不瞭解.雖然在閱讀了以前的需求文件以及使用了軟體之後，大概對系統的功能有了一個初步的認識.但是對於系統中出現的各種邏輯關係並沒有深入瞭解下去.作為專案經理，在這項工作中，失誤之處在於任務的結果(即輸出)沒有事先定義清楚，從而也就導致無法確認目標是否已經達到，再加上需求文件描述的也不是十分清晰.最後，只是在開發人員覺得已經理解該系統的基本上，進行了下一步的工作.沒有進行進一步的確認工作，不知道組員進行舊系統已經瞭解到了什麼樣的程度。這個問題的結果，就是直接導致了後期的開發過程中，由於對於原先系統的邏輯關係不是很清楚。對於舊程式碼理解和新程式碼編寫進行地不是很順利。
B. 對新需求的分析不夠
這還是個老問題，但又不是一個問題.說它是個老問題，因為分析需求要求考慮細緻全面，並且能引導客戶，啟發客戶提供更有價值的資訊。事實上，需求分析我們做的算是很盡力了，同時客戶把需求一條條的列出來給我們，相對來說需求已經很清楚了。我們在接到這些需求後，不僅研究了新功能，還把他們對於舊系統的影響都做了分析。但還是有些問題沒有能在需求文件中反映出來，後面的影響也是可想而知的了。我以前的文章中才曾提到過相關的問題，在這裡就不再重複了。不過，從另一個角度來看，它又不是一個問題。為什麼這麼說呢，因為需求實在不是能夠在分析階段就能完全理解透徹的，甚至有的需求客戶也模模糊糊，直到交付以後才提出了改動的要求。軟體開發經過這麼多年的發展，大家已經認識到了一點：需求是變化的。要達到能夠擁抱變化的要求，我們要對開發方法進行改進，相關的問題我在後面也會提到。
需求分析階段出現的問題，解決的可操作性不是很大，更多的是從思想或經驗上解決，而後面幾個階段出現的問題都相對具體一些。
2、設計階段
設計階段的問題相對比較明顯――結構設計不合理，或者說還不夠。一個傳統的C/S結構的系統，基本結構我們採用了經典的三層模型來劃分系統。由於是在舊有系統上的改進，我們在儘量不改變原有系統的基礎上新增新的功能。
主要的問題可能就是體現在沒有對舊系統進行改進。舊系統本身有一些複雜的功能，邏輯關係也比較複雜，耦合度非常高。所以，在新需求來臨的時候，我們的第一反應就是儘量不去動原來的'設計與程式碼，保證原有系統功能不會發生變化。這一點就暴露出了我們沒有去擁抱變化的決心與膽量。雖然舊系統很複雜，但是我們不能去故意迴避它。對於舊系統中設計的不合理的地方，應該主動大膽的去進行重構。其實重構的作用就是對不合理結構的進行改進，設計模式更是在設計結構的變化改進中才能體現它的價值。而這些東西，在我們的專案中都沒有應用.這可能跟我們的保守心理有關：只要不出問題，我們就不去動它，哪怕結構是多麼的錯綜複雜。這種消極的觀念在當今的充滿變化的世界中是不太有前途的。專案經理要有足夠的決心去做，同時，也不要擔心去變化。當然，可能有人會說，時間緊怎麼辦，其實這種付出對於專案的整體是隻有好處沒有壞處的，因為結構合理會讓開發人員會更少的時間去理解程式碼，減少程式碼開發的複雜度，提高程式碼編寫的質量。唯一需要考慮的就是如果改動的話，如何來保證這種變化對原有系統的功能不產生影響。這就需要有更多的測試，最好是單元測試來保證，這就是下面會談到的問題。
3、編碼階段
編碼主要還是受了設計的限制，我們的主要工作就只是在原有的結構上新增一些類與方法，以及對原有的程式碼進行修改。前面也提到了，我們採用了比較保守的作法，沒有對程式碼進行重構，放任這種高耦合的程式碼存在，導致我們在編碼過程中花費了不少精力和時間去理解它們，並在其中加上一兩條更加加深耦合度的程式碼。其實到了編碼階段，很多問題都糾纏到了一起，已經分不清因果了。比較說單元測試，首先我需要承認的一點就是沒有足夠的決心去做充分的單元測試，思想上也沒有做好充分的準備。除去主觀的因素之外，還有一點就是設計的結構不合理，很多的邏輯被處理在表示層中，資料處理則被加到了邏輯層中。沒有劃分出更多的介面供單元測試來驗證。但反過來說，沒有單元測試用例的支援，也降低了我們想要進行重構的決心。除了上述的問題之外，還有一些細節的地方，如硬編碼，命名規則等都在一定程度上對程式碼的質量產生了影響。
改進的辦法，一是從主觀上接受變化的現實，主動的對程式碼進行改動。單元測試一定要進行，最好結合統計覆蓋率的工具一併進行，這樣對於每個介面，都保證有充分多的測試用例來跑完儘可能多的路徑。在專案的質量管理上面，要求還需要更加嚴格一些，一定要按照規範來進行編碼。
4、測試階段
程式碼完成之後，測試的工作也隨之展開。但是由於成本的原因，我們並沒有再加入專業的測試人員來進行，而只是用開發人員自己來進行系統測試，讓開發人員互相測試別人實現的功能。由於開發人員與測試人員所需的專注點不同，造成了開發人員很多問題在測試中沒有被發現，缺乏測試的經驗。從另一個方面說，是開發人員不能夠及時的轉換自己的角色，而是還把自己定位在開發人員上面，更加關注的問題出在什麼地方並立刻去解決它,而不是設法去發現隱藏的Bug。當然，還有一些細節的地方，比如說測試都應該是開發人員釋出一個安裝包，然後單獨進行測試，但有的時候為了圖省事，有的功能在除錯狀態下發現通過了，在安裝包中就沒有再驗證，有時也會出現意想不到的情況發生。
