隨筆-7  評論-2  文章-0  trackbacks-0
              運營商的系統,不會每年讓都這么大規模的讓你折騰,是的,這次機遇難得!目前參加的項目,需要對原系統推翻重來,無論從數據模型,還是技術架構上,都需要進行大規模的升級改造。

              由于系統業務的復雜,雖然需求明確,前期需求分析也做的很充分,但開發人員還是需要對照原系統的代碼來開發業務邏輯。因為需求分析得再細,也細不到某個前臺錄入的數據,應該特殊處理到某個字段。

               因此開發起來效率不高,而且業務不滿足的風險極大!

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

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

               (5)測試:這也是問題,問題就是用例的粒度很粗,沒有特別熟悉業務的人員,因此業務限制的缺失無法測試得到!

                這么看來,還是功能點的詳細設計沒有做好,業務限制沒有整理出來,如果通過非常明細的測試用例來指導開發呢?

          posted on 2009-03-07 21:09 車夫 閱讀(224) 評論(0)  編輯  收藏

          只有注冊用戶登錄后才能發表評論。


          網站導航:
           
          主站蜘蛛池模板: 和田市| 高邮市| 治多县| 华阴市| 昌平区| 布尔津县| 合阳县| 鹰潭市| 延川县| 安西县| 肇州县| 天全县| 枝江市| 新野县| 潜江市| 宜春市| 方城县| 丹东市| 抚宁县| 晋中市| 河北省| 裕民县| 麻江县| 江门市| 武邑县| 富民县| 内乡县| 黄陵县| 黑龙江省| 米泉市| 孟州市| 略阳县| 武乡县| 毕节市| 南和县| 苏州市| 青岛市| 寿宁县| 新建县| 佳木斯市| 电白县|