模型驅動的開發，回憶一年多前的一次開發

您有關於問題域、需求、解決方案的體系結構以及解決方案的單獨元件、大量相互關聯的模型。

所有規範文件引用模型，並且被模型引用。

所有的設計和**都派生自模型。

所有的評估和計畫表都給予模型的元素。

所有的測試計畫和測試案例都派生自模型。

所有的最終使用者文件都根據模型而定製。

所有專案認為產物的狀態反應在模型中。

記著在一年多前的，那個時候我所在的公司來了一位新技術總監，他所給老闆的承諾是6個月完成13個模組的erp系統，他所用的辦法完全是符合模型驅動開發的思想，雖然他所使用的技術不先進，不新穎，而且對於開發他了解的也不多，但是他的模型驅動和過程管理的確贏得了我對他的尊敬，也讓我學到了很多東西。

他大概用去了6個月中一半的時間在做分析，生成了大量的模型文件及甲方終端使用者的確認審核，給每一位開發人員都帶來了信心，真正的信心（4個開發），後來的開發過程就顯得無比的簡單和順暢，因為大多的問題已經在開發之前得到了答覆和解決，那時是我第一次體驗模型驅動開發的魅力。

還有很實際的物件導向程式設計和我認為很樸實的csla.net框架。

當然模型驅動開發想要推廣開還是非常有困難的，當然這也是我總結的缺點

1.對於模型本身是一種溝通工具，而現在很多開發人員，產品經理，領域專家，公司負責及甲方對這些模型並不熟悉，理解的程度都不一樣，所以這種模型的方式往往會成為溝通的障礙

2.所以想推廣，首先也是，必須是在技術部門統一這個思想，這就需要培訓，很多公司不理解這有多重要。

3.他的成功還得益於配合，總監並不去負責開發，完全不，所以必須有乙個非常理解此套開發方式的開發經理帶領開發，否則他也無法達到那麼好的效果，要知道，如果我按這個路子去實施開發，沒有人協助，開發管理兩個都做，不僅自己很累，結果還會很糟糕。

4.在開發的過程中有乙個缺點就是模型過於冗餘，太多，每個功能都要做整套圖形我認為可以適當的根據情況調整一下，因為很多圖形都時序一致，只是介面不同，做出來不一定看。

5.我的確真真正正的感受到了，透過模型去分析上面所列出這些過程的好處，但也要看到他的缺點，因地制宜的去做。

所以當有一天你在一家公司準備實施這套方案的時候，一定要有老闆對你的信任，耐心和你自己的自信，在此之後我再沒有遇到一家公司有比這更強大的模型驅動過程管理方式，印象很深刻，100%的微軟技術。