前陣因爲論文看到過有關駁數據驅動的文章。的確，數據驅動方法存在一些問題。在90年代，Google 曾經做過一個實驗，將程序員分成2組，一面教授模型驅動設計，另一面教授的是數據驅動設計。結果是，學習了數據驅動設計的開發者的代碼冗餘性提高，拓展性降低。就是所謂的低內聚高耦合。不過，那是90年代。回過頭來看看現代的軟件開發。首先，軟件開發從原先的經典開發方法改變到了現在的持續性開發方法。其次，最終用戶已經不能滿足經典開發的速度。再次，軟件市場由 PC 逐漸移動到移動設備，競爭更加激烈。最後，最終用戶由於現在軟件市場的競爭使得對一個軟件的敏感度下降很快。所有的一切都告訴開發者，開發的要快，開發的要好。記得袁騰飛曾經說過，多快好省本來就是矛盾的，但是，最終用戶的心裏現在就是這樣希望軟件做的又快又好。開發者只能想辦法來提高開發的效率。
現在有一些開發的方法，比如敏捷開發，基於原型的開發以及可持續開發。這些開發方法的共同點在於，都是通過軟件運行時的 Log 以及用戶的回饋來進行軟件再開發。如果拋開開發過程，只看測試反饋的這一部分，那麼，這裏的開發方法其實是數據驅動的。這說明，數據驅動方法並不是一無所用。
數據驅動軟件工程的主要作用有2點。
1. 實時的軟件回饋數據來驅動軟件的再開發以及質量控制。一個比較著名的方法就是 Continuous Integration (CI)
2. 強調軟件開發參與者之間的交流與合作。例如 DevOps
微軟亞洲研究院有一個項目叫做軟件分析，其實他們也是數據驅動軟件工程的一部分。他們的主旨在於通過分析錯誤堆棧定位軟件代碼，從而提速再開發速度。Etsy 通過 Automatic Daily Build 檢測他們的在線商務網站中存在的問題，而後根據自動測試的結果修復問題。這也是數據驅動軟件工程哦。
綜上所述，當前可行的數據驅動軟件工程方案其實就是嘗試將 CI 和 DevOps 結合在一起，目的是爲了提高軟件質量，加速軟件再開發的速度。適應人羣爲整個IT界+最終客戶的圈子。IT 界中主要是軟件開發者以及研究者。當然了，Consultants 拿這些測試的結果還可以去 consulting 呢。
未來的軟件工程，我認爲就是模型驅動整合進數據驅動工程，設計一個軟件可以通過以下的步驟：
[1]. 通過數據驅動設計方法，根據客戶需求收集並回歸相關信息
[2]. 使用 [1] 中的結果，採用模型驅動進行軟件設計
[3]. 開發完成後，通過 CI 的方式以及Agile的開發方法，將原型機交付客戶檢測，進行實際數據採集分析，這裏採用數據驅動設計的方法。
[4]. 對軟件分析進行分工，分配給軟件分析師或者研究員，加強他們與實際軟件開發者的聯繫。可以參考 MSR Asia 的那個項目。這一點十分重要。大家已經發現，現在的科研機構，包括公司內部的，和實際的研發機構的技術脫節過大，很多的項目在科研機構產生但是由於是在是沒用，不但花了一大筆錢，還收穫不到什麼。
[5]. 經常性的詢問用戶的需求，採用具體的方法針對具體的客戶進行軟件再設計。
[6]. 最終交付，當然，這個要詢問客戶是否已經滿意當前的需求。然後爭取用戶許可跟蹤用戶的實際應用，在維護期內儘量提高軟件性能。
[7]. 做好開發文檔。包括[2]中的或改動的模型設計，以及開發時的注意要點。其他冗餘的東西其實是不需要記錄的。儘量精簡的信息可以讓後繼的開發者或者研究員很快上手項目。
[8]. 對於移動開發者：通過數據驅動的方法收集開發的軟件涉及到的領域，發掘新的可再開發的要點，對軟件進行修改以及更新，並重復[3]到[7]。如果模型上有更大的改動，則從[2]開始。
當前數據驅動軟件工程可以完全整合 CI，DevOps以及模型驅動軟件工程方法，以及部分整合經典開發方法，根據不同的對象進行不同方式的開發。例如在開發過程中，單一迭代內局域瀑布式開發，全局迭代式開發，在開發後期面向經驗測試以及面向原型進行再開發。因此，數據驅動軟件工程領域有很大的發展空間：
首先，技術上，今年 MIT 可以通過分析做到自動代碼生成，輔助開發者開發軟件。所以模式識別，人工智能以及遺傳算法等可以加入進來。
其次，人與人交流上，做到高效的進行合作交互。開發者和研究員畢竟都是人，如何讓他們合作在一起產生更高的效率，就需要我們親愛的人類學家來做啦。
再次，領域上，數據驅動方法可以說是完全跨領域的。有意思的是，當前用的最多的是在西方政治中進行決策分析用。軟件工程上涉及真正的數據驅動思想還是很少的。
某位大佬說，今年，2012年是數據驅動年。畢竟軟件業和10年前完全不同了。數據驅動軟件工程將會整合現在流行的方法，變成一個更加好用的通用方法也說不定 :)
Ye Tian at SAP Research Karlsruhe
