《系統架構》曾講述了這樣一個驚險案例：
一架A320客機試圖在有側風的情況下著陸，一般來說，客機降落時減速手段有舵面，發動機反推，機輪剎車，減速傘（排名不分先后），
飛機著陸后，機長嘗試使用發動機反推器減速，不料卻不起作用，這是為什么呢？
（圖1 發動機反推的原理圖 來源：知乎盧西的答案）
這是因為：控制反推器的軟體系統，基于安全原因，只有當它認為飛機確實已經“著陸”的情況下，才會打開反推器，而它判斷飛機有沒有著陸的依據，則是兩側的起落架是否全都壓緊了，
但當時由于A320客機著陸時一側機翼比較低，因此另一側的起落架沒有壓下，這就導致軟體系統判定飛機尚未著陸，因而選擇不打開反推器，
（圖2 反推開啟后的實況 來源：知乎盧西的答案）
《系統架構》說，在這個案例中，每個部件當時都按計劃執行著自己的功能，結果卻發生了事故，試著理解并預估這種系統故障，也是系統思維的一專案標，
系統部件都做好了單元測驗，然后組裝起來，就能應對不良涌現物嗎？很遺憾，不能，必須認認真真做好集成測驗，
我以前就講過下面這個經典案例：
NASA的“火星極地著陸者”于1999年12月3日墜毀于火星表面，原因也是每個部件都按計劃忠實地執行自己的功能……
（圖3 正在地面進行組裝測驗的火星極地著陸者號）
在發射前，有一個小組負責測驗探測器的腳落地程序（leg fold-down procedure），如果探測器的三個著陸支架觸地了，那么制動發動機就會關機，
另一個小組則測驗探測器著陸程序的其他部分，但這個小組的成員總是在開始測驗之前重置計算機、清除資料位，所以測驗一切順利，
這兩個小組的作業都沒什么問題，但就是沒有合在一起測驗，
在真實飛行中，著陸支架伸展出來的這個動作產生了意外的信號，制動發動機以為已經觸地了，于是在探測器距離火星表面還足足有40米的時候就提前關機了，
所以探測器就摔碎了，
對于預測涌現物，《系統架構》給出了三種方式：
第一種，根據以前做過的情況來預測，比如找到做過類似東西的人，把他們組成一個有效的團隊，以此抵御風險，
第二種，做試驗，甚至有時候需要構建高度結構化的原型，或者采用螺旋式開發，先把系統的某些部分構建出來，并檢驗其涌現物是否合意，然后再于后續的螺旋環節中逐次構建系統的其余部分，
第三種，建模，通過建模來預測涌現物并取得巨大成功的例子就是集成電路的開發，
如果系統既沒有先例，又不能試驗，而且無法可靠地建模，那就必須對將要涌現出來的功能進行推理了，最侄訓是必須依靠我們自己的判斷力，愿上帝保佑，
關鍵詞：涌現，系統架構，集成測驗，單元測驗，建模
-完-
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/296397.html
標籤：其他