東方有線專案分析設計階段遇到的問題及總結

這篇文件措辭有些激烈，思量再三，我沒有發給任何人，現在將它發在我的blog上

東方有線專案已經進入到開發階段，本文對需求分析及設計階段的情況做乙個總結。

l需求分析一人，輔助一人

l詳細設計兩人

l編碼實現兩人

原計畫專案截止日期為11月

17日，其中：1.9

月2日－

9月16日

需求分析階段；2.9

月16日－

9月24日

詳細設計階段；3.9

月25日－

11月4日

編碼實現階段

1.由於人員有限、時間緊張，需求、設計、開發沒有做任何迭代，由於採用大棒式開放，和客戶距離較遠，不能夠及時送出原型或拽光彈**，容易偏離需求；

2.所有計畫的估算值均未計算特殊狀況，如專案人員特殊情況需要請假、公司會議、專案例會、評審工作等，時間緊張；

3.需求中眾多功能集中到同乙個頁面，加大了開發難度並使系統的擴充套件性降低；

4.不可預知的問題。

通過對測試用例的評審暴露出需求分析中的大量問題，其中之一就是專案組人員對需求的把握度不夠，沒有真正吃透需求，許多問題存在二義性，以至測試用例的評審演變成了對需求的補完及修改。到目前為止，專案組的正規文件及其匱乏，開發和測試之間、組內成員之間的文件不同步現象時有發生。

客戶提供的需求文件較為簡單，其中刪去了大量文字，可用性極低，目前把介面原型的

excel

文件作為需求，但是其中的註解及其簡單，許多業務問題，如許可權問題、業務公式、流轉操作沒有提及，以至問題重重，按計畫

25日已經進入開發階段，但是

27日我們還在修改需求，在修補已經結束的工作，這種工作狀態怎麼能保證專案順利結束？

設計、開發人員對需求不夠重視，沒有認真思考需求中的隱含內容。為什麼測試人員能夠提出眾多問題？為什麼詳細設計如此之慢？為什麼發現問題沒有及時交流？

再次提醒大家，按計畫目前已經進入了開發階段，要對需求足夠重視，製作軟體的真正目的是服務於人，忘了這一點我們的軟體僅僅是個玩具。

詳細設計的目是指導開發、加深對需求的理解、明確資料庫表間關係，在沒有驅動測試的情況下，我們的設計要隨著開發的進行而逐漸完善，畢竟在短時間內不能考慮到所有細節。在東方有限專案中詳細設計初稿應該盡快完成，所以計畫耗時較短，但是截至到9月

27日初稿還沒有完成，其中原因請各位仔細分析。

開發是目前應該進行的任務，在次提醒大家，注意降低系統的偶合性，注意公用**的使用，注意靈活運用框架。我們看到了一期**中的一些問題，這些問題在發票審核模組應該及時改正。

東方有限專案截至到

27日已經將近乙個月，僅僅乙個模組就出現了如此多的問題，這值得我們總結和反思，並且作為經驗教訓不應再範。希望專案組中的各位提高緊迫感，將專案按時成功完成。