從上海地鐵撞車事件看“業務建模”的不可或缺性
近日聽聞上海地鐵一號線發生撞車事故,筆者在慶幸沒有出現人員傷亡的同時,也為事件所造成的重大混亂後果唏噓不已。筆者之所以比較關注此事件,是因為筆者曾經在2007年11月份給申通地鐵的相關研發團隊做過一次培訓,並在培訓中恰好談論過地鐵事故的應急處理等問題。
那次培訓的內容以嵌入式軟體架構設計為主,但在培訓中,為了展示嵌入式軟體的需求來源,專門講述了業務建模business modeling(用模型來描述業務,同時也包括用模型來設計全新的業務)的方法。於是便有了與學員一道探討地鐵發生事故等異常事件,整個運營系統如何支援應急預案執行等問題的經歷。在討論過程中,筆者應用業務建模的方法分析了地鐵事故應急預案的一些基本內容。提到了如何在地鐵站螢幕上顯示事故資訊、引導乘客儘快離開等;並提到自動售票機在應急預案啟動後,應當在螢幕上用亮色標識出被暫停運營的路段(售票機的需求規格中常常會漏掉這一功能需求),或者暫停售票功能(售票機的狀態有正常售票、電子客票空、找零不夠、錢幣儲存箱滿、機器故障中,於是這裡還應加上緊急暫停售票狀態)等;而相關地鐵站的進口閘機應臨時關閉,或轉換成出口閘機;另外,出口閘機可能需要暫停驗票功能,從而開放給乘客快速離場等;最後,無論售票機、進出口閘機等都應通過網路與中心運營控制系統相連線。
不過很遺憾,一次不起眼的培訓並不可能引起申通地鐵高層的足夠重視,地鐵事故應急預案以及相關應用系統的業務整合自然也沒有被落實。事後上海《東方早報》載文質疑“申通”相關部門:“為何公共螢幕無任何提示資訊?”“為何不增設指示牌引導乘客換乘?”“為何不通過電信群發簡訊提醒?”等。有人可能以相關部門缺乏經驗來加以申辯,但這些問題大部分恰恰都在2007年那次培訓的業務建模討論中被提及過。實際上,只要真正掌握了業務建模的方法,那麼在事先為未來才可能發生的異常事件做好處理準備,是完全可以做到的。
設想一下,如果申通地鐵能夠組織業務部門與研發團隊一道,就上海地鐵業務進行一次徹底的業務建模(涵蓋所有業務範疇,包括事故或異常事件的應急處理等),設計好每個業務處理的具體流程;並依據這些業務來重新梳理相關應用軟體和硬體裝置的需求規格;然後升級整個運營系統,以實現新業務的整合。那麼此次撞車事件很可能就不會造成如此巨大的群體性影響。
“業務建模”是上世紀九十年代便在歐美IT界開始流行的一種面向業務的分析與設計方法。在Rational 公司(現被IBM併購)主推的軟體開發過程(RUP統一軟體過程)中,業務建模屬於在需求開發之前便開始的核心過程域。也就是說,在軟體專案中,最開始的核心工作不是需求開發,而是業務建模。不幸的是,國內的開發團隊對“業務建模”的重視程度還比較低,在專案中成功實施“業務建模”的就更為少見。
對於業務簡單的應用而言,業務建模的作用可能有限,但對於那些較大規模或流程複雜的業務系統,缺少業務建模的環節是難以想象的。實際上,國內的開發團隊通常都會為那些複雜的業務,繪製一些業務流程圖,這些其實就是業務建模中的一部分內容。但是,不能系統地去進行業務建模,往往最終會造成開發團隊對業務的梳理和理解產生遺漏、偏差,甚至是錯誤。申通地鐵在設計其業務運營系統的時候,肯定也做了全面的業務規劃與設計,但是因為缺乏業務建模的經驗,至少在業務異常處理方面出現了重大遺漏。
隨著國內開發團隊的不斷成長,“業務建模”目前也在一些國內軟體企業中被推行,並在不少專案中取得重大成功。例如,深圳市財政局在開發新一代業務軟體系統之前,專門委託大連華信梳理和設計其新的業務方案,此間便成功地應用了業務建模的方法(筆者有幸為其提供過諮詢和培訓服務)。筆者在2004年為海南航空集團做軟體教練專案時,在開發資產管理系統的過程中,指導其團隊應用業務建模技術完善了其橫跨集團的資產管理業務流程。另外,筆者近幾年參與的專案中,還涉及人事管理、保險業務、電力運營業務等相關領域,並均有業務建模的成功案例。
為了讓有興趣的讀者瞭解業務建模,筆者準備在後續的系列文章中詳細闡述其相關知識,並圍繞申通地鐵業務的實際案例(2007年培訓時做了部分模型,準備在此基礎上進一步加以精化)來展開。筆者相信申通地鐵的研發人員可能也在規劃新的地鐵事故應急預案業務方案,那麼,筆者在此展示的申通地鐵業務模型,應當能夠起到拋磚引玉的作用。
筆者在將要後續的系列文章中闡述的業務建模內容包括:
- 業務建模的作用和應用場合
- 描述目標組織,識別業務動機
- 開發業務用例模型
- 細化業務用例
- 業務用例分析,識別業務物件
- 從業務模型引申軟體系統需求
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/17007506/viewspace-624044/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 從架構上看OB與TIDB擅長的業務領域架構TiDB
- 從疫苗事件看民眾的發聲之路事件
- 從校園到騰訊工作一年的那些跌跌撞撞!
- 從業務元件庫看前端物料生態元件前端
- 從業務元件庫看前端工程化元件前端
- 從Chrome原始碼看事件迴圈Chrome原始碼事件
- 事件風暴 vs 事件建模事件
- 從拼多多事件看電商的促銷模型事件模型
- 透過汽車之家二手車業務,看二手車市場的模式終局模式
- 從原始碼看 Android 事件分發原始碼Android事件
- 從 Chrome 原始碼看瀏覽器的事件機制Chrome原始碼瀏覽器事件
- 蘋果Apple Pay支援刷北京上海地鐵 和小米公交有何區別?蘋果APP
- EA業務建模實踐之業務用例圖
- 從效能角度看 react 元件拆分的重要性React元件
- 從JDK原始碼看String(上)JDK原始碼
- 服務案例|基於IT事件管理,提升業務連續性事件
- 對業務流程建模而不是對實體建模 - poweredbybeard
- [技術討論]業務建模和使用者業務的關係
- 業務資料分析和建模薦
- 業務建模:CQRS應用場景
- 從Turbo Vision原始碼看事件驅動 (轉)原始碼事件
- 從資料庫角度談業務連續性資料庫
- 從《閃爍之光》看遊戲設計的統一性遊戲設計
- IT看業務公開
- IT系統的業務模型分析與系統建模模型
- 從番茄花園事件看商業軟體的“潛規則”事件
- 從全域性視角看資料結構資料結構
- 從美國二手車價格暴跌看全球二手車價格走向
- 從技術角度看騰訊雲“資料丟失”事件!事件
- 架構師之路 - 業務領域建模架構
- 業務建模:BoundedContext(有界上下文)Context
- 軟體需求與分析 業務建模分析
- 不可或缺的 sendEmailAI
- 製造業“上網”,核心技術不可或缺
- 從契約演進看區塊鏈的變革性區塊鏈
- 從 JDK 原始碼角度看 java 併發的公平性JDK原始碼Java
- [全程建模]業務建模和用例模型以及需求規格說明書的關係模型
- 上海地鐵站打破次元壁,小紅書聯動頭部廠商開啟“遊戲這個夏天”遊戲