運營商的系統(tǒng)，不會每年讓都這么大規(guī)模的讓你折騰，是的，這次機遇難得！目前參加的項目，需要對原系統(tǒng)推翻重來，無論從數(shù)據(jù)模型，還是技術(shù)架構(gòu)上，都需要進(jìn)行大規(guī)模的升級改造。

    由于系統(tǒng)業(yè)務(wù)的復(fù)雜，雖然需求明確，前期需求分析也做的很充分，但開發(fā)人員還是需要對照原系統(tǒng)的代碼來開發(fā)業(yè)務(wù)邏輯。因為需求分析得再細(xì)，也細(xì)不到某個前臺錄入的數(shù)據(jù)，應(yīng)該特殊處理到某個字段。

     因此開發(fā)起來效率不高，而且業(yè)務(wù)不滿足的風(fēng)險極大！

     公司在需求管理方面，可以說投入不可謂不大，有專門的人，購買專門的系統(tǒng)來管理，但通過這次系統(tǒng)升級發(fā)現(xiàn)，之前的需求管理對這次一點幫助沒有，最多是保存了些原來客戶提的需求文檔。做分析的時候還可以，但真正指導(dǎo)開發(fā)，還是有一定差距！問題到底出在什么地方？怎么樣的需求管理，才能把當(dāng)前系統(tǒng)的情況完整展現(xiàn)出來？

     我也不知道，我只能把現(xiàn)在的情況描述下來，希望有經(jīng)驗的人士給點意見，在此多謝先：
     （1）需求分析：把整理的需求文檔匯總，1-2年下來，這些文檔有幾個G，一個人看下來簡直是不可能的任務(wù)，分模塊后，一般每個模塊有個需求小組來完成需求分析工作，輸出業(yè)務(wù)模型（概念數(shù)據(jù)模型），更多是讓這些人（將來的組長）熟悉自己要做的業(yè)務(wù)細(xì)節(jié)。
     （2）概要設(shè)計：主要的工作是細(xì)化概念數(shù)據(jù)模型，成物理模型。
     （3）詳細(xì)設(shè)計：我們基本沒有，因為這個工作量太大，一般到概要設(shè)計，出數(shù)據(jù)模型后，邊開發(fā)，邊做詳細(xì)設(shè)計，這時還會繼續(xù)維護(hù)物理數(shù)據(jù)模型。
     （4）代碼開發(fā)：人員流動很大，新員工很多，很多不熟悉業(yè)務(wù)，不知道要做的東西干什么的，技術(shù)和業(yè)務(wù)培訓(xùn)會經(jīng)常進(jìn)行。這時，問題來，架構(gòu)設(shè)計后，開發(fā)人員對照著原代碼的邏輯進(jìn)行寫程序，因為需要了解原來的程序怎么走的，為什么這么判斷，這個工作很煩躁且必須，因為你不能丟掉原來的功能點和業(yè)務(wù)限制。

     （5）測試：這也是問題，問題就是用例的粒度很粗，沒有特別熟悉業(yè)務(wù)的人員，因此業(yè)務(wù)限制的缺失無法測試得到！

      這么看來，還是功能點的詳細(xì)設(shè)計沒有做好，業(yè)務(wù)限制沒有整理出來，如果通過非常明細(xì)的測試用例來指導(dǎo)開發(fā)呢？