沒頭沒尾--專案開發筆記：對應開發方式的變化 (轉)

沒頭沒尾--專案開發筆記：對應開發方式的變化 (轉)[@more@]

標題：沒頭沒尾--專案開發筆記：對應開發方式的變化

關鍵詞：分散式開發 專案分工 UML F

  11月22號：有點激動，有點沮喪

多謝各位朋友的意見！其實沒有寫這個專案筆記之前，有很多的問題我都沒意識到。寫的過程中從前從後可以體會出有很多的過程我們的團隊是在糊塗的過程中就走過來了。過程中少的很多部分都是根據以前開發的來填充，以及團隊中個別牛人的能力來填充。朋友們如果有什麼意思與好的建議，歡迎討論。

其實現在已經可以發現我所說的開發過程有一些問題。不過我想既然是筆記。那還是主要記錄事實的好，所以過程的對錯也就可能對現在也沒有什麼太大的幫助。大家就當成是經驗與教訓吧。不過還是歡迎討論，為解決問題找到好的想法。

接著上次昨天的說。專案在試圖採用UML或IDEF沒有結果之後，加上我們花了大多的時候去討論本身（這件事回頭再說，討論的過程非常的麻煩，並且得到的成果比較有限，我們也從框架的討論中得到了一些總結）。也圍繞著需求的文件反反覆覆的討論過很多的次。正準備按照以前的開發過程來進一步的進行下一步的開發時，一個契機出現了。

哈，說這是個契機實在有點可笑。事實上是領導們提交給客戶的計劃中有一項條款是有一個非常短的時間內要交一個詳細設計。這個事情專案組是在離提交給客戶詳細設計的前二週才突然知道的。這下子麻煩了，我還沒搞定設計應該採用是什麼形式，寫什麼呀。急急忙忙的找到了我們的需求，從側面瞭解到詳細設計這個東東客戶也不是很在意，只是合同的條款上有這一條，要不什麼前期款之類的東東沒辦法拿回來之類的。然後我根據我以前開發時候的經驗，我與需求人員可不可以用一個可以連線起來的應用的純粹頁面作為詳細設計來配合需求人員與客戶講解需求。討價還價的結果還不錯。最後是同意採用這種方式來進行處理。

由於前期工作的情況，以及我們框架本身的特點，加上這個“契機”，我定義出了以下的開發過程度採用以下的開發：

1.  完成設計，完成介面顯示

l  主要工作

完成介面的工作以配合需求人員去客戶處進行講解。根據需求完成的設計與資料庫的設計。

l  對應完成框架中的部分

1)  介面中模板的生成

2)  介面中過載的生成

3)  介面的主要程式的排程介面的生成

4)  資料庫表的生成，部分資料庫過程的生成。以及對應的dataaccess.base層與commondata層的資料檔案生成

l  效果

需求人員可以使用我們製作出的介面與進行溝通，並進一步的明確使用者的需要。並可以提前去實現與客戶的交流。資料庫的設計與準備檔案將會根據資料庫的表準備出dataaccess.base與commondata兩層。（部分的準備儲存過程，這個也是我們特殊的開發過程制約的。）

2.  完成介面邏輯

l  主要工作

提供工具生成資料庫表從dataaccess.template直至service層的方法，將所有已經提供出的資料庫表提供出All();AddItem();UpdateItem();DeleteItem()等等方法。以及已經定義出的儲存過程的方法從Webservice上的。並將介面端所有控制元件對應的動作都做出響應。只實現最為簡單的增加，修改與刪除。

l  對應完成框架中的部分

  i.  使用自己做的工具完成dataaccess.template,dataaccess,businessrules,businesacade,webservice的程式碼架子。其中dataaccess.template,dataaccess,businessrules按照資料庫的表結構來進行組織；而businessfacade,webservice按照已經定上一個步驟中的客戶端的業務結構來進行組織。

  ii.  實現介面的邏輯。對應所有介面上的運作都需要完成從Web Service取得資料以及回傳的資料（定義好介面）的實現。以及介面的簡單資訊校驗。

  iii.  生成的檔案的基礎上根據介面的響應來進行修改，對應加入businessrules,businessfacade,webservice的方法。

  iv.  新加方法時對應加入dataaccess的新方法。

l  效果

一個從介面上來說可以跑的程式。但並非從業務上可以跑的程式。只是完成了介面上所有對資料的簡單操作（增刪改）。

3.  完成業務邏輯

l  主要工作

最後大部分工作是真正的業務核心。透過以上兩個步驟，我們已經實現了將除去業務的部分完成。這部分的工作就是具體去判斷業務過程中除了去實現最基礎的新增，修改，刪除之後還需要實現的其它業務。比如刪除一個商品的時候要去判斷是不是這條商品已經被使用過等這些的業務流程。

l  操作框架中的部分

1)  businessrules，針對特殊業務加入方法以及呼叫。

2)  對應上一層的方法加入dataaccess以及儲存過程的呼叫。

l  效果

最終完成。

 :namespace prefix = o ns = "urn:schemas--com::office" />

 

其中涉及到非常多的來這三個階段中的人員的分工安排。以及每一個過程的實現都將會同時將我們的需求，測試，以及客戶反饋帶入新的階段。

目前專案的工作在第二步的過程中。我想下幾篇將會討論定義這個開發模式時的思考以及具體實現過程中的問題。也會討論我們在其中自己開發的一些的思路。

 

 

明後天要去上課了。北京這麼冷，早上八點就要上課，痛苦！

 

（這裡有一些事情要補允說明一下：需求人員在我們這個團隊中的角色非常的複雜。他們要做先期的需求調研。要做使用者UI的審批，要做測試，要做售後技術支援。特殊的身份使我們的需求人員對於業務的瞭解非常的熟悉，與客戶之間的關係很緊密。但是也有點過份的插手到開發過程之中。所以我這裡的需求人員與朋友們做專案中的需求人員可能會有不同。）