項目質(zhì)量控制：分析階段

　　項目的開始階段，也是質(zhì)量控制的開始。在這個階段中，主要的工作是從客戶方獲得足夠多的項目需求，并準確地記錄在案，而且要使得項目組的成員對于需求足夠得了解。先說說這個項目的基本情況：一個信息管理系統(tǒng)，而且是在原來的版本上進行的功能增加。項目組的成員，除了我以前參加了前一個版本的開發(fā)，其它的人員都不了解這個項目。就是這樣的一個項目，在開始階段，我先是安排了組員對以前版本的需求文檔進行了閱讀，并安裝使用了軟件。隨后對新的需求進行了研究，分析了它們對于原有系統(tǒng)的影響。由于是在舊有系統(tǒng)的文檔進行增加，所以加入的新內(nèi)容并不是很多，需求文檔很快就完成了。所謂的分析階段的里程碑也就結束了。

　　在需求階段＂順利＂結束的同時，問題也隨之留下來，并對后面的階段起到了＂乘數(shù)效應＂――影響變得越來越大：

　　A.對舊系統(tǒng)的理解不足由于開發(fā)人員沒有參與過上一個版本的開發(fā)工作，他們對于舊系統(tǒng)并不了解．雖然在閱讀了以前的需求文檔以及使用了軟件之后，大概對系統(tǒng)的功能有了一個初步的認識．但是對于系統(tǒng)中出現(xiàn)的各種邏輯關系并沒有深入了解下去．作為項目經(jīng)理，在這項工作中，失誤之處在于任務的結果（即輸出）沒有事先定義清楚，從而也就導致無法確認目標是否已經(jīng)達到，再加上需求文檔描述的也不是十分清晰。最后，只是在開發(fā)人員覺得已經(jīng)理解該系統(tǒng)的基本上，進行了下一步的工作．沒有進行進一步的確認工作，不知道組員進行舊系統(tǒng)已經(jīng)了解到了什么樣的程度。這個問題的結果，就是直接導致了后期的開發(fā)過程中，由于對于原先系統(tǒng)的邏輯關系不是很清楚。對于舊代碼理解和新代碼編寫進行地不是很順利。

　　B.對新需求的分析不夠這還是個老問題，但又不是一個問題．說它是個老問題，因為分析需求要求考慮細致全面，并且能引導客戶，啟發(fā)客戶提供更有價值的信息。事實上，需求分析我們做的算是很盡力了，同時客戶把需求一條條的列出來給我們，相對來說需求已經(jīng)很清楚了。我們在接到這些需求后，不僅研究了新功能，還把他們對于舊系統(tǒng)的影響都做了分析。但還是有些問題沒有能在需求文檔中反映出來，后面的影響也是可想而知的了。我以前的文章中才曾提到過相關的問題，在這里就不再重復了。不過，從另一個角度來看，它又不是一個問題。為什么這么說呢，因為需求實在不是能夠在分析階段就能完全理解透徹的，甚至有的需求客戶也模模糊糊，直到交付以后才提出了改動的要求。軟件開發(fā)經(jīng)過這么多年的發(fā)展，大家已經(jīng)認識到了一點：需求是變化的。要達到能夠擁抱變化的要求，我們要對開發(fā)方法進行改進，相關的問題我在后面也會提到。

　　需求分析階段出現(xiàn)的問題，解決的可操作性不是很大，更多的是從思想或經(jīng)驗上解決，而后面幾個階段出現(xiàn)的問題都相對具體一些。