問題：
在我們的軟件立項(xiàng)階段，我們通常會預(yù)估軟件開發(fā)周期，成本預(yù)算，人員配置，版本迭代時間節(jié)點(diǎn).
但是大量的軟件研發(fā)在實(shí)際的操作上都不可能按我們計(jì)劃順利實(shí)施。
因?yàn)橛泻芏嗑C合的因素是人為不可控的，
1,不斷變更的需求
最有可能導(dǎo)致軟件研發(fā)失敗的因素。客戶本身不一定是軟件專業(yè)人士，大多是用一堆可能互不相干的松散的功能點(diǎn)來講訴他們所設(shè)想的軟件。他們
需要什么樣的軟件和他們所能描述的可能差距很大。在研發(fā)的過程中，甚至交付階段，客戶也會不斷的提出新需求和變更需求。
2,業(yè)務(wù)模型設(shè)計(jì)有誤
需求調(diào)研不明確或者涉及到需求大的變更都會影響業(yè)務(wù)模型，直接導(dǎo)致數(shù)據(jù)庫大幅度增刪數(shù)據(jù)表及字段
3,系統(tǒng)編程結(jié)構(gòu)繁瑣
多模塊及分布式遠(yuǎn)程調(diào)用系統(tǒng)與研發(fā)環(huán)境緊耦合。在研發(fā)中需要調(diào)用多個遠(yuǎn)程服務(wù)(不包括第三方系統(tǒng))，測試一個子功能設(shè)計(jì)到庫打包到maven庫再遠(yuǎn)程包含，極大增加了編程測試的步驟與難度。
4,前端和后端研發(fā)的時間差
后端研發(fā)比前端慢，前端需要的模擬數(shù)據(jù)需要等待后端的服務(wù)，或者前端根據(jù)業(yè)務(wù)寫模擬數(shù)據(jù)
5,研發(fā)人員差異
人員的素質(zhì)參差不齊，編程風(fēng)格不統(tǒng)一，邏輯思維不夠嚴(yán)密常常引發(fā)很多BUG。
改變：
文檔驅(qū)動的模板系統(tǒng)設(shè)計(jì)
顧名思義，以需求文檔為驅(qū)動，模板為材料，以架構(gòu)為核心，通過模式映射軟件組裝我們的軟件系統(tǒng)，M-SYS。
M-SYS的必須包含的模塊：
前端頁面，前端JS框架，后端服務(wù)模塊，后端數(shù)據(jù)庫操作模塊，緩存模塊，日志模塊，權(quán)限系統(tǒng)，Session子系統(tǒng)。
針對移動服務(wù)，需要增加后端數(shù)據(jù)加密系統(tǒng)，后端服務(wù)系統(tǒng)。
針對分布式系統(tǒng)，需要增加分布式遠(yuǎn)程調(diào)用模塊,服務(wù)發(fā)現(xiàn)子系統(tǒng)，分布式消息子系統(tǒng)，分布式緩存系統(tǒng)。
M-SYS的幾個必要特征：
1，簡單邏輯的代碼自動化：根據(jù)文檔生成增刪查改看的前端和后端代碼。當(dāng)需求導(dǎo)致文檔變更時，也可簡單的重新生成代碼。
2，功能模塊插件模式：根據(jù)需求自由搭配不同需求文檔組裝成新的系統(tǒng)。
3，簡化研發(fā)和測試：把系統(tǒng)設(shè)計(jì)，細(xì)節(jié)，容易犯錯的地方與研發(fā)人員高度隔離，軟件開發(fā)人員僅僅專注于業(yè)務(wù)邏輯的實(shí)現(xiàn)，便捷的測試環(huán)境和步驟。
模板，模塊，特征及子系統(tǒng)的設(shè)計(jì)此篇文章不做詳述。以下以簡單的實(shí)現(xiàn)做為說明，
需求文檔以Excel為載體
動文檔.png)
利用模式映射軟件在幾十毫秒生成以下所有的模塊
在M-SYSTEM體系下，一個不會編程的人都能非常方便的編寫出一個龐大的軟件及分布式系統(tǒng)。M-SYSTEM強(qiáng)調(diào)每個獨(dú)立的輕服務(wù)模塊，在名空間管理下，利用已有的各種服務(wù)可以像搭積木一樣組成一個復(fù)雜的界面，