從OMS系統(tǒng)的開發(fā)看業(yè)務(wù)開發(fā)平臺的形成課件

從OMS系統(tǒng)的開發(fā)看業(yè)務(wù)開發(fā)平臺的形成21December2022從OMS系統(tǒng)的開發(fā)看業(yè)務(wù)開發(fā)平臺的形成16December議題從定單調(diào)度系統(tǒng)開發(fā)及系統(tǒng)設(shè)計思路的開發(fā)演進過程，說明什么是業(yè)務(wù)開發(fā)平臺；業(yè)務(wù)開發(fā)平臺包含哪些東西；他為什么會為后續(xù)的服務(wù)帶來擴展能力和伸縮性；在提供了開發(fā)框架平臺后PSO如何提供服務(wù)，研發(fā)應(yīng)承擔什么工作議題從定單調(diào)度系統(tǒng)開發(fā)及系統(tǒng)設(shè)計思路的開發(fā)演進過程，說明什么定單調(diào)度（OMS）系統(tǒng)介紹定單調(diào)度（OMS）系統(tǒng)介紹定單調(diào)度系統(tǒng)訂單調(diào)度系統(tǒng)包括業(yè)務(wù)資源配置、流程調(diào)度（定單調(diào)度）及業(yè)務(wù)開通（包括施工）等功能業(yè)務(wù)配置與業(yè)務(wù)資源管理緊密相關(guān)業(yè)務(wù)開通功能包括即開即通（和網(wǎng)元或網(wǎng)絡(luò)管理系統(tǒng)接口）和非即開即同（資源施工接口）兩大類網(wǎng)絡(luò)管理業(yè)務(wù)配置業(yè)務(wù)開通業(yè)務(wù)資源管理物理及邏輯資源管理流程調(diào)度定單調(diào)度系統(tǒng)O-CRM系統(tǒng)網(wǎng)絡(luò)資源管理系統(tǒng)定單調(diào)度系統(tǒng)訂單調(diào)度系統(tǒng)包括業(yè)務(wù)資源配置、流程調(diào)度（定單調(diào)度把定單調(diào)度系統(tǒng)從CRM獨立出來，是業(yè)務(wù)能力的體現(xiàn)在現(xiàn)有大部分系統(tǒng)建設(shè)模式中，前后臺并不分離，前后臺分離，是BPR管理體制變革和面向市場（客戶）的要求把OMS系統(tǒng)和資源管理脫離，基于如下原因：目前的本地網(wǎng)網(wǎng)絡(luò)資源管理系統(tǒng)主要關(guān)注物理資源及設(shè)備的管理，其他功能較弱，特別是系統(tǒng)業(yè)務(wù)資源和邏輯物理資源的分隔并不明確目前本地網(wǎng)網(wǎng)絡(luò)資源管理系統(tǒng)實施情況幾乎所有運營商范圍內(nèi)并不統(tǒng)一，進度較慢－－市場驅(qū)動，管理驅(qū)動，是導(dǎo)致系統(tǒng)功能架構(gòu)變革的根本原因把定單調(diào)度系統(tǒng)從CRM獨立出來，是業(yè)務(wù)能力的體現(xiàn)在現(xiàn)有大部分定單調(diào)度系統(tǒng)，我們希望技術(shù)創(chuàng)新工作流引擎技術(shù)是定單調(diào)度系統(tǒng)的核心選擇和有限狀態(tài)機相比，工作流技術(shù)優(yōu)勢明顯：貼近自然語言的描述使用圖的方式表達任務(wù)之間的關(guān)系，可以靈活調(diào)整流程的狀態(tài)，下個步驟的走向，歷史路徑清晰可見修改和添加新業(yè)務(wù)維護簡單流程和業(yè)務(wù)處理，工具提供了分離的可能－－業(yè)務(wù)處理邏輯和流程分離，使系統(tǒng)伸縮性增強。這是采用工作流引擎技術(shù)主要期待解決的問題定單調(diào)度系統(tǒng)，我們希望技術(shù)創(chuàng)新工作流引擎技術(shù)是定單調(diào)度系統(tǒng)的開發(fā)平臺的形成開發(fā)平臺的形成總體業(yè)務(wù)技術(shù)架構(gòu)很快做好了－浙江網(wǎng)通工作流平臺流程規(guī)則流程環(huán)節(jié)受理審核收費通知需求查勘號配置線配置端口配置IP配置程控測量外線數(shù)據(jù)機房數(shù)據(jù)外勤多媒體中心竣工接入機房產(chǎn)品及產(chǎn)品包定單初始化產(chǎn)品1產(chǎn)品2訂單環(huán)節(jié)1環(huán)節(jié)2環(huán)節(jié)3環(huán)節(jié)1環(huán)節(jié)2環(huán)節(jié)3環(huán)節(jié)4竣工調(diào)用業(yè)務(wù)處理邏輯 但沒有實現(xiàn)與資源管理系統(tǒng)的分離，因此，自己做了一套資源管理總體業(yè)務(wù)技術(shù)架構(gòu)很快做好了－浙江網(wǎng)通工作流平臺流程規(guī)則流程環(huán)做完了，發(fā)現(xiàn)了很多問題規(guī)則驅(qū)動的業(yè)務(wù)處理邏輯和數(shù)據(jù)驅(qū)動的流程要實現(xiàn)語義一致，必須窮舉窮舉了，為了支持復(fù)雜的業(yè)務(wù)流程，我們發(fā)現(xiàn)流程的可調(diào)整性根本是句空話按照流程進行分工開發(fā)，發(fā)現(xiàn)后臺的業(yè)務(wù)邏輯根本不能重用如果資源管理不是我們做的，發(fā)現(xiàn)系統(tǒng)接口無限復(fù)雜系統(tǒng)為了滿足功能，不斷龐大各地流程有很大不一致，發(fā)現(xiàn)系統(tǒng)重用的程度不高誰寫的代碼，誰負責，維護困難。。。。開始否定一切：否定工作流否定技術(shù)架構(gòu)研發(fā)內(nèi)部思路不統(tǒng)一，對系統(tǒng)產(chǎn)品化基本絕望做完了，發(fā)現(xiàn)了很多問題規(guī)則驅(qū)動的業(yè)務(wù)處理邏輯和數(shù)據(jù)驅(qū)動的流程怎么辦？思考半年。。。。。。怎么辦？思考半年。。。。。。忽然看到：營銷產(chǎn)品包營銷產(chǎn)品包產(chǎn)品產(chǎn)品產(chǎn)品產(chǎn)品模板產(chǎn)品模板網(wǎng)絡(luò)業(yè)務(wù)功能單元網(wǎng)絡(luò)業(yè)務(wù)功能單元網(wǎng)絡(luò)業(yè)務(wù)功能單元網(wǎng)絡(luò)業(yè)務(wù)功能單元忽然看到：營銷產(chǎn)品包營銷產(chǎn)品包產(chǎn)品產(chǎn)品產(chǎn)品產(chǎn)品模板產(chǎn)品模板網(wǎng)是不是這樣？產(chǎn)品的實現(xiàn)流程是管理崗位的工作流程每個崗位是對一個或者多個產(chǎn)品的網(wǎng)絡(luò)業(yè)務(wù)單元進行操作網(wǎng)絡(luò)業(yè)務(wù)單元的操作是不是只有三種：裝；拆，改？如果細分網(wǎng)絡(luò)業(yè)務(wù)單元，是否就能解決和網(wǎng)絡(luò)資源管理系統(tǒng)的接口問題和業(yè)務(wù)邏輯重用問題？基于這些考慮，發(fā)現(xiàn)解決資源管理接口問題的關(guān)鍵是要做一套產(chǎn)品分解為網(wǎng)絡(luò)業(yè)務(wù)單元的數(shù)據(jù)模型！是不是這樣？產(chǎn)品的實現(xiàn)流程是管理崗位的工作流程開始對異常流程進行思考忽然想出了一注意：反正異常也不多(出現(xiàn)機率20％)，一旦發(fā)生異常，先放到一個異常隊列里面去（客響中心）應(yīng)該要解決工作流的消息響應(yīng)模型機制（技術(shù)）掛起的訂單怎么辦：問：要干什么？發(fā)現(xiàn)都是要干的正常的活再想想，找到了一個新想法：自學(xué)習(xí)型訂單管理系統(tǒng)開始對異常流程進行思考忽然想出了一注意：自學(xué)習(xí)型訂單管理系統(tǒng)－定單控制中心配置異常編碼異常編碼是原子的異常原因配置異常情形異常情形是一種異常狀況的描述配置流程模板自學(xué)習(xí)型訂單管理系統(tǒng)－定單控制中心配置異常編碼配置異常情形配又解決了一些技術(shù)問題-UWFE基于準確，實時的原則，通過EJB和JMS提供外部事件的響應(yīng)模型任務(wù)的高容錯性解決異構(gòu)工作流的接口問題Workflow引擎(Jbpm)基礎(chǔ)包應(yīng)用程序API工作流應(yīng)用程序接口全局事務(wù)管理BEA7接口包BEA8接口包BEAStudioPlugInIBM(MQ)接口包實例修改ToolKit流程Web監(jiān)控組件靜態(tài)數(shù)據(jù)維護包IBMFDL同步包又解決了一些技術(shù)問題-UWFE基于準確，實時的原則，通過EJ效果蘇州電信的案例－順便發(fā)現(xiàn)了使用XML作為消息和數(shù)據(jù)傳遞的正確性，EAI重慶網(wǎng)通－資源管理系統(tǒng)不是我們的，照樣接。順便還總結(jié)了一些系統(tǒng)上線的技巧（實施模式）海南網(wǎng)通很快搞定了效果蘇州電信的案例－順便發(fā)現(xiàn)了使用XML作為消息和數(shù)據(jù)傳遞的結(jié)論1、采用了工作流引擎技術(shù)，并構(gòu)建了UWFE模塊，結(jié)合APPFRAME，解決了從頁面，到工作流引擎使用，EAI方面的諸多方面的問題2、構(gòu)架了對電信產(chǎn)品的一套網(wǎng)元細分方法，成為系統(tǒng)核心數(shù)據(jù)模型，網(wǎng)元提供三種方法，構(gòu)成可重用的原子服務(wù)層；3、提供了訂單調(diào)度控制中心的功能，實現(xiàn)了異常流程的自學(xué)習(xí)（不斷擴展）4、提出了組件的概念，在實踐中，實現(xiàn)了組裝組件及部分頁面邏輯的可重用

網(wǎng)元網(wǎng)元網(wǎng)元普通電話接入配置組件用戶界面工單處理服務(wù)調(diào)用管理結(jié)論1、采用了工作流引擎技術(shù)，并構(gòu)建了UWFE模塊，結(jié)合APOMS系統(tǒng)體系架構(gòu)OMS系統(tǒng)體系架構(gòu)什么是開發(fā)平臺？開發(fā)平臺＝統(tǒng)一的技術(shù)框架＋核心的數(shù)據(jù)模型＋一系列逐步積累的業(yè)務(wù)框架什么是開發(fā)平臺？開發(fā)平臺＝和南京研發(fā)CRM體系的比較和南京研發(fā)CRM體系的比較基于開發(fā)平臺的服務(wù)模式基于開發(fā)平臺的服務(wù)模式細腰型產(chǎn)品架構(gòu)業(yè)務(wù)平臺業(yè)務(wù)平臺業(yè)務(wù)平臺業(yè)務(wù)平臺技術(shù)平臺技術(shù)平臺技術(shù)平臺技術(shù)平臺核心技術(shù)核心技術(shù)核心技術(shù)核心技術(shù)核心技術(shù)核心技術(shù)技術(shù)技術(shù)技術(shù)技術(shù)技術(shù)技術(shù)技術(shù)技術(shù)技術(shù)A解決方案B解決方案C解決方案D解決方案E解決方案穩(wěn)定組件穩(wěn)定功能解決方案不是產(chǎn)品，產(chǎn)品是由穩(wěn)定的功能和不穩(wěn)定功能的穩(wěn)定開發(fā)模式組成的，為了穩(wěn)定，產(chǎn)品開發(fā)平臺是產(chǎn)品的核心，不穩(wěn)定的功能和組件是產(chǎn)品的一系列示例不穩(wěn)定組件不穩(wěn)定組件不穩(wěn)定組件穩(wěn)定功能不穩(wěn)定功能不穩(wěn)定功能不穩(wěn)定功能細腰型產(chǎn)品架構(gòu)業(yè)務(wù)平臺業(yè)務(wù)平臺業(yè)務(wù)平臺業(yè)務(wù)平臺技術(shù)平臺技術(shù)平研發(fā)是產(chǎn)品的核心系統(tǒng)3系統(tǒng)2系統(tǒng)6產(chǎn)品開發(fā)平臺公用組件系統(tǒng)7系統(tǒng)4系統(tǒng)1系統(tǒng)5系統(tǒng)8研發(fā)最為重要的職責是產(chǎn)品開發(fā)平臺研發(fā)需要建立對PSO實施中的技術(shù)管控流程（是否采用或正確采用開發(fā)平臺）閉門造車不可能開發(fā)出產(chǎn)品開發(fā)平臺產(chǎn)品范圍的擴大是個循序漸進的收斂過程研發(fā)是產(chǎn)品的核心系統(tǒng)3系統(tǒng)2系統(tǒng)6產(chǎn)品開發(fā)平臺公用組件系統(tǒng)7基于開發(fā)平臺的開發(fā)模式積累是產(chǎn)品－PSO基于開發(fā)平臺的開發(fā)模式積累是產(chǎn)品－PSO螺旋模型收斂開發(fā)平臺邊界軸需求分析框架確認二次開發(fā)產(chǎn)品確認螺旋模型是一種迭代模型，每迭代一次，螺旋線就前進一周在項目實施過程中存在迭代，在軟件產(chǎn)品生命周期中也存在跌代在不斷的迭代過程中，隨著螺距增大，產(chǎn)品日趨完善在迭代過程中的邊界軸上，需要交付相應(yīng)產(chǎn)品保證跌代順利進行螺旋模型收斂開發(fā)平臺邊界軸需求框架確認二次產(chǎn)品螺旋模型是一種“需求分析”——“框架確認”交付文檔邊界軸交付文檔文檔說明形式提供者《項目需求規(guī)格說明書》項目中涉及的客戶化的需求，以及對整個產(chǎn)品的功能要求DocPSO《產(chǎn)品框架適應(yīng)性分析報告》針對已有的產(chǎn)品框架，羅列不能適用用戶需求的產(chǎn)品框架模塊DocPSO《產(chǎn)品功能適應(yīng)性分析報告》針對已有的產(chǎn)品功能點，匹配featureList，給出已經(jīng)存在的和需要二次開發(fā)的軟件功能模塊清單DocPSO《重點功能界面原形》通過界面原型反映用戶使用習(xí)慣和整個系統(tǒng)風(fēng)格可執(zhí)行文件、圖片、html等PSO“需求分析”——“框架確認”邊界軸交付文檔文檔說明形式提供者“框架確認”——“二次開發(fā)”交付文檔邊界軸交付文檔文檔說明形式提供者《產(chǎn)品框架變更風(fēng)險確認報告》權(quán)衡各地項目產(chǎn)品實施的不同情況，給出框架變更的風(fēng)險評估DocR&D《產(chǎn)品框架變更說明書》根據(jù)需求說明，如果涉及核心框架的修改，需要提供產(chǎn)品框架變更說明Doc，JavaDocR&D《產(chǎn)品框架缺陷說明書》因為各種原因，導(dǎo)致目前框架不能實現(xiàn)的，需要通過額外編寫代碼代替的框架缺陷DocR&D核心框架代碼補丁包對產(chǎn)品核心框架的修正和增強CodeR&D《項目二次開發(fā)指導(dǎo)書》基于項目典型業(yè)務(wù)的開發(fā)實例培訓(xùn)等R&D《功能矩陣》從功能層面，分析出能夠持久化到產(chǎn)品中或者只能在項目范圍內(nèi)部使用的功能模塊列表DocR&DPSO“框架確認”——“二次開發(fā)”邊界軸交付文檔文檔說明形式提供者“二次開發(fā)”——“最終產(chǎn)品確認”交付文檔邊界軸交付文檔文檔說明形式提供者《產(chǎn)品功能變更列表》描述能夠持久化到產(chǎn)品中的，可以為各個項目共享的產(chǎn)品功能模塊Doc，JavaDocR&D產(chǎn)品功能代碼補丁包新增的和變更的產(chǎn)品功能模塊CodeR&D《項目功能列表》描述項目特殊需求的功能Doc，JavaDocPSO項目功能代碼包基于產(chǎn)品框架的獨立開發(fā)的本地化的功能模塊CodePSO“二次開發(fā)”——“最終產(chǎn)品確認”邊界軸交付文檔文檔說明形式提“最終產(chǎn)品確認”交付文檔邊界軸交付文檔文檔說明形式提供者《產(chǎn)品需求規(guī)格說明書》產(chǎn)品實現(xiàn)功能的詳細描述DocR&D《產(chǎn)品數(shù)據(jù)字典》包括數(shù)據(jù)庫對象實體結(jié)構(gòu)的描述和系統(tǒng)靜態(tài)數(shù)據(jù)Doc，pdm，oomR&D《產(chǎn)品二次開發(fā)手冊》基于產(chǎn)品框架的二次開發(fā)的指導(dǎo)，具備典型業(yè)務(wù)的開發(fā)過程和相應(yīng)代碼說明DocR&D《產(chǎn)品發(fā)布手冊》包含產(chǎn)品發(fā)布包的結(jié)構(gòu)說明，配置文件說明，以及在不同應(yīng)用環(huán)境發(fā)布的步驟和配置說明DocR&D“最終產(chǎn)品確認”邊界軸交付文檔文檔說明形式提供者《產(chǎn)品需求規(guī)謝謝選擇亞信，共創(chuàng)成功謝謝選擇亞信，共創(chuàng)成功從OMS系統(tǒng)的開發(fā)看業(yè)務(wù)開發(fā)平臺的形成21December2022從OMS系統(tǒng)的開發(fā)看業(yè)務(wù)開發(fā)平臺的形成16December議題從定單調(diào)度系統(tǒng)開發(fā)及系統(tǒng)設(shè)計思路的開發(fā)演進過程，說明什么是業(yè)務(wù)開發(fā)平臺；業(yè)務(wù)開發(fā)平臺包含哪些東西；他為什么會為后續(xù)的服務(wù)帶來擴展能力和伸縮性；在提供了開發(fā)框架平臺后PSO如何提供服務(wù)，研發(fā)應(yīng)承擔什么工作議題從定單調(diào)度系統(tǒng)開發(fā)及系統(tǒng)設(shè)計思路的開發(fā)演進過程，說明什么定單調(diào)度（OMS）系統(tǒng)介紹定單調(diào)度（OMS）系統(tǒng)介紹定單調(diào)度系統(tǒng)訂單調(diào)度系統(tǒng)包括業(yè)務(wù)資源配置、流程調(diào)度（定單調(diào)度）及業(yè)務(wù)開通（包括施工）等功能業(yè)務(wù)配置與業(yè)務(wù)資源管理緊密相關(guān)業(yè)務(wù)開通功能包括即開即通（和網(wǎng)元或網(wǎng)絡(luò)管理系統(tǒng)接口）和非即開即同（資源施工接口）兩大類網(wǎng)絡(luò)管理業(yè)務(wù)配置業(yè)務(wù)開通業(yè)務(wù)資源管理物理及邏輯資源管理流程調(diào)度定單調(diào)度系統(tǒng)O-CRM系統(tǒng)網(wǎng)絡(luò)資源管理系統(tǒng)定單調(diào)度系統(tǒng)訂單調(diào)度系統(tǒng)包括業(yè)務(wù)資源配置、流程調(diào)度（定單調(diào)度把定單調(diào)度系統(tǒng)從CRM獨立出來，是業(yè)務(wù)能力的體現(xiàn)在現(xiàn)有大部分系統(tǒng)建設(shè)模式中，前后臺并不分離，前后臺分離，是BPR管理體制變革和面向市場（客戶）的要求把OMS系統(tǒng)和資源管理脫離，基于如下原因：目前的本地網(wǎng)網(wǎng)絡(luò)資源管理系統(tǒng)主要關(guān)注物理資源及設(shè)備的管理，其他功能較弱，特別是系統(tǒng)業(yè)務(wù)資源和邏輯物理資源的分隔并不明確目前本地網(wǎng)網(wǎng)絡(luò)資源管理系統(tǒng)實施情況幾乎所有運營商范圍內(nèi)并不統(tǒng)一，進度較慢－－市場驅(qū)動，管理驅(qū)動，是導(dǎo)致系統(tǒng)功能架構(gòu)變革的根本原因把定單調(diào)度系統(tǒng)從CRM獨立出來，是業(yè)務(wù)能力的體現(xiàn)在現(xiàn)有大部分定單調(diào)度系統(tǒng)，我們希望技術(shù)創(chuàng)新工作流引擎技術(shù)是定單調(diào)度系統(tǒng)的核心選擇和有限狀態(tài)機相比，工作流技術(shù)優(yōu)勢明顯：貼近自然語言的描述使用圖的方式表達任務(wù)之間的關(guān)系，可以靈活調(diào)整流程的狀態(tài)，下個步驟的走向，歷史路徑清晰可見修改和添加新業(yè)務(wù)維護簡單流程和業(yè)務(wù)處理，工具提供了分離的可能－－業(yè)務(wù)處理邏輯和流程分離，使系統(tǒng)伸縮性增強。這是采用工作流引擎技術(shù)主要期待解決的問題定單調(diào)度系統(tǒng)，我們希望技術(shù)創(chuàng)新工作流引擎技術(shù)是定單調(diào)度系統(tǒng)的開發(fā)平臺的形成開發(fā)平臺的形成總體業(yè)務(wù)技術(shù)架構(gòu)很快做好了－浙江網(wǎng)通工作流平臺流程規(guī)則流程環(huán)節(jié)受理審核收費通知需求查勘號配置線配置端口配置IP配置程控測量外線數(shù)據(jù)機房數(shù)據(jù)外勤多媒體中心竣工接入機房產(chǎn)品及產(chǎn)品包定單初始化產(chǎn)品1產(chǎn)品2訂單環(huán)節(jié)1環(huán)節(jié)2環(huán)節(jié)3環(huán)節(jié)1環(huán)節(jié)2環(huán)節(jié)3環(huán)節(jié)4竣工調(diào)用業(yè)務(wù)處理邏輯 但沒有實現(xiàn)與資源管理系統(tǒng)的分離，因此，自己做了一套資源管理總體業(yè)務(wù)技術(shù)架構(gòu)很快做好了－浙江網(wǎng)通工作流平臺流程規(guī)則流程環(huán)做完了，發(fā)現(xiàn)了很多問題規(guī)則驅(qū)動的業(yè)務(wù)處理邏輯和數(shù)據(jù)驅(qū)動的流程要實現(xiàn)語義一致，必須窮舉窮舉了，為了支持復(fù)雜的業(yè)務(wù)流程，我們發(fā)現(xiàn)流程的可調(diào)整性根本是句空話按照流程進行分工開發(fā)，發(fā)現(xiàn)后臺的業(yè)務(wù)邏輯根本不能重用如果資源管理不是我們做的，發(fā)現(xiàn)系統(tǒng)接口無限復(fù)雜系統(tǒng)為了滿足功能，不斷龐大各地流程有很大不一致，發(fā)現(xiàn)系統(tǒng)重用的程度不高誰寫的代碼，誰負責，維護困難。。。。開始否定一切：否定工作流否定技術(shù)架構(gòu)研發(fā)內(nèi)部思路不統(tǒng)一，對系統(tǒng)產(chǎn)品化基本絕望做完了，發(fā)現(xiàn)了很多問題規(guī)則驅(qū)動的業(yè)務(wù)處理邏輯和數(shù)據(jù)驅(qū)動的流程怎么辦？思考半年。。。。。。怎么辦？思考半年。。。。。。忽然看到：營銷產(chǎn)品包營銷產(chǎn)品包產(chǎn)品產(chǎn)品產(chǎn)品產(chǎn)品模板產(chǎn)品模板網(wǎng)絡(luò)業(yè)務(wù)功能單元網(wǎng)絡(luò)業(yè)務(wù)功能單元網(wǎng)絡(luò)業(yè)務(wù)功能單元網(wǎng)絡(luò)業(yè)務(wù)功能單元忽然看到：營銷產(chǎn)品包營銷產(chǎn)品包產(chǎn)品產(chǎn)品產(chǎn)品產(chǎn)品模板產(chǎn)品模板網(wǎng)是不是這樣？產(chǎn)品的實現(xiàn)流程是管理崗位的工作流程每個崗位是對一個或者多個產(chǎn)品的網(wǎng)絡(luò)業(yè)務(wù)單元進行操作網(wǎng)絡(luò)業(yè)務(wù)單元的操作是不是只有三種：裝；拆，改？如果細分網(wǎng)絡(luò)業(yè)務(wù)單元，是否就能解決和網(wǎng)絡(luò)資源管理系統(tǒng)的接口問題和業(yè)務(wù)邏輯重用問題？基于這些考慮，發(fā)現(xiàn)解決資源管理接口問題的關(guān)鍵是要做一套產(chǎn)品分解為網(wǎng)絡(luò)業(yè)務(wù)單元的數(shù)據(jù)模型！是不是這樣？產(chǎn)品的實現(xiàn)流程是管理崗位的工作流程開始對異常流程進行思考忽然想出了一注意：反正異常也不多(出現(xiàn)機率20％)，一旦發(fā)生異常，先放到一個異常隊列里面去（客響中心）應(yīng)該要解決工作流的消息響應(yīng)模型機制（技術(shù)）掛起的訂單怎么辦：問：要干什么？發(fā)現(xiàn)都是要干的正常的活再想想，找到了一個新想法：自學(xué)習(xí)型訂單管理系統(tǒng)開始對異常流程進行思考忽然想出了一注意：自學(xué)習(xí)型訂單管理系統(tǒng)－定單控制中心配置異常編碼異常編碼是原子的異常原因配置異常情形異常情形是一種異常狀況的描述配置流程模板自學(xué)習(xí)型訂單管理系統(tǒng)－定單控制中心配置異常編碼配置異常情形配又解決了一些技術(shù)問題-UWFE基于準確，實時的原則，通過EJB和JMS提供外部事件的響應(yīng)模型任務(wù)的高容錯性解決異構(gòu)工作流的接口問題Workflow引擎(Jbpm)基礎(chǔ)包應(yīng)用程序API工作流應(yīng)用程序接口全局事務(wù)管理BEA7接口包BEA8接口包BEAStudioPlugInIBM(MQ)接口包實例修改ToolKit流程Web監(jiān)控組件靜態(tài)數(shù)據(jù)維護包IBMFDL同步包又解決了一些技術(shù)問題-UWFE基于準確，實時的原則，通過EJ效果蘇州電信的案例－順便發(fā)現(xiàn)了使用XML作為消息和數(shù)據(jù)傳遞的正確性，EAI重慶網(wǎng)通－資源管理系統(tǒng)不是我們的，照樣接。順便還總結(jié)了一些系統(tǒng)上線的技巧（實施模式）海南網(wǎng)通很快搞定了效果蘇州電信的案例－順便發(fā)現(xiàn)了使用XML作為消息和數(shù)據(jù)傳遞的結(jié)論1、采用了工作流引擎技術(shù)，并構(gòu)建了UWFE模塊，結(jié)合APPFRAME，解決了從頁面，到工作流引擎使用，EAI方面的諸多方面的問題2、構(gòu)架了對電信產(chǎn)品的一套網(wǎng)元細分方法，成為系統(tǒng)核心數(shù)據(jù)模型，網(wǎng)元提供三種方法，構(gòu)成可重用的原子服務(wù)層；3、提供了訂單調(diào)度控制中心的功能，實現(xiàn)了異常流程的自學(xué)習(xí)（不斷擴展）4、提出了組件的概念，在實踐中，實現(xiàn)了組裝組件及部分頁面邏輯的可重用

網(wǎng)元網(wǎng)元網(wǎng)元普通電話接入配置組件用戶界面工單處理服務(wù)調(diào)用管理結(jié)論1、采用了工作流引擎技術(shù)，并構(gòu)建了UWFE模塊，結(jié)合APOMS系統(tǒng)體系架構(gòu)OMS系統(tǒng)體系架構(gòu)什么是開發(fā)平臺？開發(fā)平臺＝統(tǒng)一的技術(shù)框架＋核心的數(shù)據(jù)模型＋一系列逐步積累的業(yè)務(wù)框架什么是開發(fā)平臺？開發(fā)平臺＝和南京研發(fā)CRM體系的比較和南京研發(fā)CRM體系的比較基于開發(fā)平臺的服務(wù)模式基于開發(fā)平臺的服務(wù)模式細腰型產(chǎn)品架構(gòu)業(yè)務(wù)平臺業(yè)務(wù)平臺業(yè)務(wù)平臺業(yè)務(wù)平臺技術(shù)平臺技術(shù)平臺技術(shù)平臺技術(shù)平臺核心技術(shù)核心技術(shù)核心技術(shù)核心技術(shù)核心技術(shù)核心技術(shù)技術(shù)技術(shù)技術(shù)技術(shù)技術(shù)技術(shù)技術(shù)技術(shù)技術(shù)A解決方案B解決方案C解決方案D解決方案E解決方案穩(wěn)定組件穩(wěn)定功能解決方案不是產(chǎn)品，產(chǎn)品是由穩(wěn)定的功能和不穩(wěn)定功能的穩(wěn)定開發(fā)模式組成的，為了穩(wěn)定，產(chǎn)品開發(fā)平臺是產(chǎn)品的核心，不穩(wěn)定的功能和組件是產(chǎn)品的一系列示例不穩(wěn)定組件不穩(wěn)定組件不穩(wěn)定組件穩(wěn)定功能不穩(wěn)定功能不穩(wěn)定功能不穩(wěn)定功能細腰型產(chǎn)品架構(gòu)業(yè)務(wù)平臺業(yè)務(wù)平臺業(yè)務(wù)平臺業(yè)務(wù)平臺技術(shù)平臺技術(shù)平研發(fā)是產(chǎn)品的核心系統(tǒng)3系統(tǒng)2系統(tǒng)6產(chǎn)品開發(fā)平臺公用組件系統(tǒng)7系統(tǒng)4系統(tǒng)1系統(tǒng)5系統(tǒng)8研發(fā)最為重要的職責是產(chǎn)品開發(fā)平臺研發(fā)需要建立對PSO實施中的技術(shù)管控流程（是否采用或正確采用開發(fā)平臺）閉門造車不可能開發(fā)出產(chǎn)品開發(fā)平臺產(chǎn)品范圍的擴大是個循序漸進的收斂過程研發(fā)是產(chǎn)品的核心系統(tǒng)3系統(tǒng)2系統(tǒng)6產(chǎn)品開發(fā)平臺公用組件系統(tǒng)7基于開發(fā)平臺的開發(fā)模式積累是產(chǎn)品－PSO基于開發(fā)平臺的開發(fā)模式積累是產(chǎn)品－PSO螺旋模型收斂開發(fā)平臺邊界軸需求分析框架確認二次開發(fā)產(chǎn)品確認螺旋模型是一種迭代模型，每迭代一次，螺旋線就前進一周在項目實施過程中存在迭代，在軟件產(chǎn)品生命周期中也存在跌代在不斷的迭代過程中，隨著螺距增大，產(chǎn)品日趨完善在迭代過程中的邊界軸上，需要交付相應(yīng)產(chǎn)品保證跌代順利進行螺旋模型收斂開發(fā)平臺邊界軸需求框架確認二次產(chǎn)品螺旋模型是一種“需求分析”——“框架確認”交付文檔邊界軸交付文檔文檔說明形式提供者《項目需求規(guī)格說明書》項目中涉及的客戶化的需求，以及對整個產(chǎn)品的功能要求DocPSO《產(chǎn)品框架適應(yīng)性分析報告》針對已有的產(chǎn)品框架，羅列不能適用用戶需求的產(chǎn)品框架模塊DocPSO《產(chǎn)品功能適應(yīng)性分析報告》針對已有的產(chǎn)品功能點，匹配featureList，給出已經(jīng)存在的和需要二次開發(fā)的軟件功能模塊清單DocPSO《重點功能界面原形》通過界面原型反映用戶使用習(xí)慣和整個系統(tǒng)風(fēng)格可執(zhí)行文件、圖片、html等P