模組分解原理與三權分立
模組分解原理探索
前一篇模組分解原理探索的文章中談到了模組需要按專業領域分解，怎麼這篇文章的標題上突然冒出了三權分立，軟體怎麼和政治制度扯到一起去了？
表面看這兩個東西好像是風牛馬不及，但如果把軟體系統和整個社會系統做乙個模擬的話，也許能看出一些端倪來。
在軟體中，有需求，設計，程式設計，測試這幾個大的核心專業領域，再來看三權分立，立法、司法、行政看起來似乎是三種權力，實際上立法主要是遊戲規則設計，相當於軟體中的設計領域，司法系統主要是問題定位和糾錯的，類似於軟體中的測試領域，行政主要是執行和實現，相當於軟體中的程式設計領域。
三權分立表面上看是三種權力分立，但從模組分解原理來看，實際上是將三個不同專業領域分解出來成為三個對等的權力部門，我想這才是三權分立的真正偉大之處。
雖然三權分立的思想很偉大，但是也不是說它就沒有問題，主要問題出在分解出來的專業領域只有三個，專業領域覆蓋面不全面。後來孫中山先生提出了所謂的「五權分立」學說，分為行政、立法、司法、考試、**五個權力機構，想進一步細化權力以彌補三權分立的不足之處，但不幸的是五權分立並沒有完全符合模組分解原理，**實際上屬於糾錯領域和司法屬於同一領域，而考試則並不是和其他幾個領域對等的領域，而是屬於各個領域的公共子領域。
從前面社會系統和軟體系統的模擬中可以看出，三權分立缺乏對需求專業領域的覆蓋，需求領域沒有被單獨分離出來，人們的需求沒有得到專業化的處理，當**沒有按照人們的需求去做時，人們只能通過遊行示威等極端低效的方式來進行表達自己的需求。其實相當於編碼人員不按照需求規格來實現程式設計是同乙個道理。我想這也是西方採用三權分立的國家也會經常發生問題的重要原因之一。
除了需求領域外，社會系統中其實還有其他一些領域，如公共服務領域（相當於軟體的客戶支援）等。目前行政系統中將公共服務領域和其他對等的領域混合在一起，所以行政系統成了最容易出問題的地方。當然需求、設計、測試、程式設計各個領域中也存在子領域分解的問題，同樣需要按照模組分解原理來分解。
當然社會系統是複雜的，模組分解原理只能解決其中的一部分問題，即國家組織結構設計中的組織結構分解問題，並不能解決組織結構設計中所有的問題。
順便提一下，可能有人想知道，社會系統中的權力相當於軟體中的什麼呢？其實軟體中的介面就相當於社會系統中的權力。官僚性組織中之所以問題頻生，沒有設計合理的介面以及不按介面行事是其根本原因，特別是各個組織機構的首腦人物具有隨意改動規則和制訂制度的權力（可以看作可以做任何事情的超級介面），使得社會矛盾逐漸累積。這其實相當於軟體程式設計人員不按高層設計制訂的介面去實現、擅自改變介面是一回事。
模組分解原理與三權分立
模組分解原理與三權分立 模組分解原理探索 前一篇模組分解原理探索的文章中談到了模組需要按專業領域分解，怎麼這篇文章的標題上突然冒出了三權分立，軟體怎麼和政治制度扯到一起去了？表面看這兩個東西好像是風牛馬不及，但如果把軟體系統和整個社會系統做乙個模擬的話，也許能看出一些端倪來。在軟體中，有需求，設計，...
模組分解原理與三權分立
模組分解原理與三權分立 模組分解原理探索 前一篇模組分解原理探索的文章中談到了模組需要按專業領域分解，怎麼這篇文章的標題上突然冒出了三權分立，軟體怎麼和政治制度扯到一起去了？表面看這兩個東西好像是風牛馬不及，但如果把軟體系統和整個社會系統做乙個模擬的話，也許能看出一些端倪來。在軟體中，有需求，設計，...
模組分解原理與三權分立
模組分解原理與三權分立 模組分解原理探索 前一篇模組分解原理探索的文章中談到了模組需要按專業領域分解，怎麼這篇文章的標題上突然冒出了三權分立，軟體怎麼和政治制度扯到一起去了？表面看這兩個東西好像是風牛馬不及，但如果把軟體系統和整個社會系統做乙個模擬的話，也許能看出一些端倪來。在軟體中，有需求，設計，...