臨時風(fēng)險預(yù)警發(fā)布平臺的開發(fā)

-63-臨時風(fēng)險預(yù)警發(fā)布平臺的開發(fā)鹽城供電公司電力調(diào)控中心“鐵軍”地調(diào)QC小組2017年6月目錄一、選擇課題 -1-一、課題背景 -1-二、確定課題 -2-二、設(shè)定目標(biāo) -3-一、設(shè)定目標(biāo) -3-二、目標(biāo)可行性分析 -3-1.數(shù)據(jù)分析 -3-2.人力資源 -4-3.資金保證 -4-三、提出各種方案并確定最佳方案 -4-一、開發(fā)構(gòu)想 -4-1.需求分析 -4-2.提出方案 -5-二、選擇最佳方案 -6-1.一級方案選擇 -6-2.二級方案選擇 -13-3.確定最佳方案 -14-四、制定對策表 -14-五、按對策表實施 -15-一、對策實施一：采用移動平臺端進(jìn)行發(fā)布 -15-1.設(shè)計API請求測試流程 -15-2.測試API請求成功率 -17-二、對策實施二：采用復(fù)合審核 -17-1.制定預(yù)警信息復(fù)合審核流程圖 -17-2.測試預(yù)警單審核正確率 -18-三、對策實施三：采用扁平化顯示 -19-1.設(shè)計移動設(shè)備各功能界面 -19-2.設(shè)計集中推送功能界面 -20-3.測試各功能界面加載時間 -21-四、對策實施四：采用交互式布局?jǐn)?shù)據(jù)結(jié)構(gòu) -21-1.選擇數(shù)據(jù)庫服務(wù)器 -21-2.建立服務(wù)器端數(shù)據(jù)庫表單結(jié)構(gòu) -22-3.進(jìn)行服務(wù)器端并行響應(yīng)測試 -23-五、對策實施五：采用(網(wǎng)頁+腳本)語言+Apicloud平臺 -23-1.設(shè)計登錄及注冊流程 -23-2.分解功能模塊并設(shè)計主界面 -24-3.進(jìn)行平臺預(yù)警信息發(fā)布在線測試 -25-4.驗收功能流轉(zhuǎn)全過程 -26-六、效果檢查 -27-一、事故信息及臨時風(fēng)險發(fā)布時間對比 -27-二、目標(biāo)實現(xiàn)檢查 -27-三、實施前后流程對比 -27-四、經(jīng)濟效益 -28-1.增加收入 -28-2.成本投入 -28-3.經(jīng)濟效益 -29-五、課題查新 -29-七、標(biāo)準(zhǔn)化 -30-一、編制操作規(guī)范及技術(shù)規(guī)范 -30-二、移動平臺端的生產(chǎn)系統(tǒng)試用 -31-三、推廣應(yīng)用 -31-八、總結(jié)與今后打算 -32-

小組概況：小組名稱國網(wǎng)江蘇省電力公公司鹽城供電電公司電力調(diào)調(diào)控中心地調(diào)“鐵軍”QCC小組活動課題名稱臨時風(fēng)險預(yù)警發(fā)布布平臺的開發(fā)發(fā)注冊時間2016年3月課題類型創(chuàng)新型活動次數(shù)12次出勤率100%小組成員情況姓名性別學(xué)歷職務(wù)組內(nèi)分工邵林男碩士組長全面負(fù)責(zé)楊洋男本科副組長技術(shù)指導(dǎo)王萍女本科督導(dǎo)（指導(dǎo)）活動指導(dǎo)王傳能男碩士組員工作實施張永豐男本科組員工作實施張偉偉男碩士組員工作實施汪濤男本科組員工作實施金鑫男碩士組員工作實施周磊男碩士組員資料查找王輝男碩士組員資料查找黃震男碩士組員資料查找小組獲獎情況2013年，“降降低110kkV時堰變電電所線損率”項項目獲得江蘇蘇省節(jié)能減排排專題QC小小組成果一等等獎。20114年，獲得得“全國優(yōu)秀秀質(zhì)量管理小小組”榮譽稱稱號。一、選擇課題一、課題背景鹽城供電公司電力調(diào)控中心地區(qū)調(diào)度班，負(fù)責(zé)鹽城地區(qū)110kV及以上電網(wǎng)的調(diào)度操作管理。根據(jù)《江蘇省電力公司電網(wǎng)事故信息發(fā)布相關(guān)規(guī)定》，當(dāng)電網(wǎng)發(fā)生事故、設(shè)備重大缺陷造成電網(wǎng)存在運行風(fēng)險時，要求在第一時間內(nèi)快速處理及準(zhǔn)確發(fā)布事故信息和預(yù)控措施。原有的電網(wǎng)臨時風(fēng)險預(yù)警信息發(fā)布流程,采用人工電話通知方法，通知流程如圖1-1所示，事故發(fā)生以后，經(jīng)SCADA系統(tǒng)確認(rèn)故障，首先遙控隔離故障點，再電話逐個告知各相關(guān)人員及分管領(lǐng)導(dǎo)，共經(jīng)過5個部門、8個步驟，其中綠色部分即為臨時風(fēng)險預(yù)警發(fā)布流程。圖1-1信息發(fā)布原始流程經(jīng)調(diào)查統(tǒng)計，2015年8月至2016年3月間，臨時風(fēng)險發(fā)布耗時統(tǒng)計如表1-1，事故處理各環(huán)節(jié)耗時經(jīng)過實際統(tǒng)計，結(jié)果如表1-2所示。以市區(qū)范圍為例，信息發(fā)布平均用時41.5min，占調(diào)度事故處理用時的67.5%，嚴(yán)重影響事故處理進(jìn)程。表1-12015.8至2016.3臨時風(fēng)險原發(fā)布方式耗時統(tǒng)計時間故障類型市區(qū)范圍/minn縣城城區(qū)/minn鄉(xiāng)鎮(zhèn)及農(nóng)村/miin2015.8-22016.33總體平均耗時41.53428.5事故最長耗時534433表1-2調(diào)度事故處理各流程用時統(tǒng)計表步驟故障確認(rèn)遙控隔離編寫事故信息制定預(yù)控措施通知各相關(guān)生產(chǎn)部部門市區(qū)/min7136828縣城/min7126820鄉(xiāng)鎮(zhèn)/min6115717可見，原有的人工通知方法已不能滿足調(diào)度事故處理的要求。備注：臨時風(fēng)險：指在電網(wǎng)運行過程中突發(fā)的事故或設(shè)備缺陷，可能對當(dāng)前電網(wǎng)運行方式、供電可靠性等造成的影響。電網(wǎng)故障：指電網(wǎng)內(nèi)斷路器跳閘、一二次設(shè)備異常、電氣設(shè)備發(fā)生重要缺陷等造成的影響電網(wǎng)安全運行的事件。二、確定課題QC小組成員召開頭腦風(fēng)暴會議，一致認(rèn)為，原有的方法已不能滿足調(diào)控運行事故預(yù)警信息發(fā)布的需求，能否考慮采用網(wǎng)絡(luò)化通訊、信息化傳輸、信息通信方法對電網(wǎng)事故及風(fēng)險信息進(jìn)行迅捷、準(zhǔn)確地發(fā)布？為此，QC小組進(jìn)行了查新。QC小組通過國家科技圖書文獻(xiàn)中心、國家科技成果網(wǎng)、維普資訊、萬方數(shù)據(jù)、中國學(xué)術(shù)期刊網(wǎng)、中國知網(wǎng)進(jìn)行相關(guān)文獻(xiàn)檢索，檢索詞為：信息發(fā)布、風(fēng)險預(yù)警、移動平臺設(shè)計，并檢索出三篇類似文獻(xiàn)，分別為《基于跨平臺的自行車競賽信息發(fā)布移動平臺設(shè)計》（微處理機，2015.10（5））；《基于移動互聯(lián)網(wǎng)氣象信息發(fā)布移動平臺技術(shù)實現(xiàn)》（計算機光盤軟件與應(yīng)用，2014.3（6））；《烏魯木齊供電公司電網(wǎng)風(fēng)險預(yù)警與管理研究》（華北電力大學(xué)，2015年碩士論文），如圖1-2中左圖所示。其中已完成的跨平臺的自行車競賽信息發(fā)布移動平臺的設(shè)計，對本次QC活動借鑒意義較大。該跨平臺的自行車賽信息發(fā)布平臺的設(shè)計和流程安排，主要針對環(huán)青海湖自行車賽的相關(guān)賽程及比賽排名等信息。其設(shè)計思路為采用PhoneGap將設(shè)計好并發(fā)布至服務(wù)器端的網(wǎng)站封裝成移動平臺，如圖1-2中右圖所示。經(jīng)進(jìn)一步調(diào)研，環(huán)湖賽信息發(fā)布移動平臺由野途網(wǎng)開發(fā)設(shè)計，該平臺的設(shè)計運用了服務(wù)器端數(shù)據(jù)處理、移動智能終端的信息請求及反饋等方式，實現(xiàn)了信息的有效發(fā)布，如圖1-3所示，目前在電力系統(tǒng)中尚未發(fā)現(xiàn)對電網(wǎng)臨時風(fēng)險預(yù)警采用此方式的先例。圖1-2環(huán)湖賽信息發(fā)布移動平臺圖1-3信息傳送示意圖可借鑒點：環(huán)湖賽信息發(fā)布平臺的信息網(wǎng)絡(luò)傳輸方式、及服務(wù)器端的數(shù)據(jù)庫建模方式，來實現(xiàn)本項目的信息傳輸和建模；不同點：環(huán)湖賽信息發(fā)布平臺的移動智能終端只能發(fā)送數(shù)據(jù)請求及信息查閱，本項目不僅用移動智能終端實現(xiàn)上述功能，還進(jìn)一步增加數(shù)據(jù)的返回、修改、錄入等功能，開發(fā)難度更大。因此，QC小組確定課題為：臨時風(fēng)險預(yù)警發(fā)布平臺的開發(fā)。二、設(shè)定目標(biāo)一、設(shè)定目標(biāo)為了提升風(fēng)險預(yù)警信息發(fā)布的效率，小組經(jīng)過分析將本次課題目標(biāo)確定為：將臨時風(fēng)險預(yù)警信息發(fā)布耗時限制在15min以內(nèi)。圖2-1目標(biāo)設(shè)定圖二、目標(biāo)可行性分析小組對設(shè)定的目標(biāo)進(jìn)行了可行性分析。1.數(shù)據(jù)分析比照野途網(wǎng)的環(huán)湖賽信息發(fā)布平臺，對其信息發(fā)布平臺的并行發(fā)布時間，本QC小組成員進(jìn)行了測試，測試結(jié)果如下：表2-1環(huán)湖賽信息發(fā)布流程測試服務(wù)器端信息錄入入服務(wù)器端信息封裝裝信息流轉(zhuǎn)發(fā)布移動平臺端接受并并更新移動平臺端信息加加載總計15s5s15s5s5s45s其信息發(fā)布平臺的發(fā)布用時小于等于45s。本小組采用的信息錄入及封裝方式為移動平臺端，移動平臺端錄入比照服務(wù)器端加載用時較長，一般判別需用時為服務(wù)器端2倍，如表2-2所示。表2-2本項目信息并行發(fā)布流程用時序號12345步驟移動平臺端信息錄錄入移動平臺端信息封封裝信息流轉(zhuǎn)發(fā)布移動平臺端接受并并更新移動平臺端信息加加載用時30s5s15s5s5s臨時風(fēng)險并行發(fā)布時間=步驟1+步驟2+步驟3+步驟4+步驟5=30+5+15+5+5=1（min）因此，本小組采用預(yù)警發(fā)布平臺并行發(fā)布耗時至多為60s，加上編寫事故信息耗時6min、制定預(yù)控措施耗時8min。臨時風(fēng)險預(yù)警發(fā)布耗時經(jīng)計算應(yīng)不大于6min+8min+1min，即15min。2.人力資源小組中有10名成員，其中電力調(diào)度技師4人，數(shù)據(jù)庫工程師1人，軟件工程師4人，熟練掌握C、C++、JAVA、Html等編程語言，具備自行開發(fā)能力。3.資金保證鹽城供電公司“楊洋”創(chuàng)新工作室，有專項創(chuàng)新基金3000元。小組通過向公司申請立項，可以解決項目開發(fā)的剩余資金問題。綜上所述，將目標(biāo)設(shè)置為將臨時風(fēng)險預(yù)警發(fā)布耗時限制在15min以內(nèi)，具有可行性。三、提出各種方案并確定最佳方案一、開發(fā)構(gòu)想1.需求分析 小組召開頭腦風(fēng)暴會議，對方案的需求進(jìn)行分析討論，匯總整理小組成員的意見后，用親和圖加以歸納，如圖3-1。圖3-1親和圖由親和圖得出臨時風(fēng)險預(yù)警發(fā)布平臺的軟硬件主要需求，同時對照環(huán)湖自行車賽信息發(fā)布系統(tǒng)的開發(fā)性能指標(biāo)，查閱了相關(guān)軟件應(yīng)用參數(shù)后，得出臨時風(fēng)險預(yù)警發(fā)布平臺的需求分析表。表3-1臨時風(fēng)險預(yù)警發(fā)布平臺需求分析表序號臨時預(yù)警信息發(fā)布布平臺的需求求分析實現(xiàn)效果1采用網(wǎng)絡(luò)方式進(jìn)行行發(fā)布API請求成功率率高于98%%2采用順序流程審核核方法信息審核正確率高高于98%，審審核時間不超超過2minn3采用圖形界面顯示示方法圖形界面加載時間間小于0.22s4采用關(guān)系型數(shù)據(jù)庫庫結(jié)構(gòu)開發(fā)50條并行數(shù)據(jù)處處理響應(yīng)時間間低于0.55s5采用框架切換模式式開發(fā)功能驗收成功率高高于98%6平臺開發(fā)成本低盡可能降低2.提出方案小組成員結(jié)合初步方案的選擇結(jié)果，根據(jù)需求分析和親和圖中的語言資料，進(jìn)行梳理和歸類，提出了詳細(xì)分解方案，如圖3-2所示。圖3-2方案詳細(xì)分解框圖二、選擇最佳方案1.一級方案選擇（一）功能開發(fā)1）采用網(wǎng)絡(luò)方式進(jìn)行發(fā)布3月10-13日，小組成員就采用網(wǎng)絡(luò)方式進(jìn)行發(fā)布的具體方案進(jìn)行討論分析，分成三個專項小組對每一個方案進(jìn)行簡易的試驗分析，并分析其特點，給出結(jié)論，如表3-2所示。表3-2網(wǎng)絡(luò)發(fā)布各方式比較方案選擇方案說明方案分析特點結(jié)論方案目標(biāo)：APII（Winddow預(yù)定義義的函數(shù)）請請求成功率高高于98%，單單條數(shù)據(jù)請求求服務(wù)器端資資源占用低，數(shù)數(shù)據(jù)安全性高高。試驗說明：編寫模模擬程序，從從移動平臺端端進(jìn)行APII數(shù)據(jù)請求測測試，對單條條數(shù)據(jù)請求的的資源占用和和請求成功率率進(jìn)行統(tǒng)計，用用訪問函數(shù)進(jìn)進(jìn)行試驗。服務(wù)器端發(fā)布方案說明：服務(wù)器器端錄入數(shù)據(jù)據(jù)，數(shù)據(jù)的流流向單一，從從服務(wù)器端至至移動平臺端端；移動平臺API請請求測試：API請求類型請求次數(shù)成功次數(shù)成功率平均資源占用GET1009898%45kB方案成本分析：類型費用清單成本服務(wù)器端服務(wù)器升級600元參考資料250元數(shù)據(jù)庫開發(fā)300元服務(wù)器端開發(fā)1000元移動端云、端調(diào)試200元移動端開發(fā)300元數(shù)據(jù)流API請求類型G開發(fā)成本200元4G網(wǎng)絡(luò)成本120元數(shù)據(jù)流環(huán)節(jié)2個成本總計2970元優(yōu)點：1、移動端開發(fā)成成本低；2、數(shù)據(jù)流環(huán)節(jié)少少，安全性高高；3、API請求成成功率符合要要求，但低于于方案二和方方案三。缺點：1、資源占用率高高；2、服務(wù)器端開發(fā)成成本高；不選用該方案移動平臺端發(fā)布方案說明：移動平平臺端錄入數(shù)數(shù)據(jù)，數(shù)據(jù)雙向流流動；移動平臺API請請求測試：API請求類型請求次數(shù)成功次數(shù)成功率平均資源占用GET100100100%20kBPUT100100100%30kBPOST1009999%32kBDELETE100100100%15kB方案成本分析：類型費用清單成本服務(wù)器端服務(wù)器升級0參考資料250元數(shù)據(jù)庫開發(fā)300元服務(wù)器端開發(fā)300元移動端云、端調(diào)試200元移動端開發(fā)600元數(shù)據(jù)流API請求類型G、P、P、D開發(fā)成本400元4G網(wǎng)絡(luò)成本120元數(shù)據(jù)流環(huán)節(jié)2個成本總計2170元優(yōu)點：1、API請求成成功率滿足要要求；2、平均資源占用用最低；3、數(shù)據(jù)流環(huán)節(jié)少少，安全性高高；4、成本總計最為為節(jié)??；缺點：1、移動平臺端開開發(fā)成本較高高，但成本總總計最優(yōu)滿足足要求；選用該方案網(wǎng)頁端發(fā)布方案說明：數(shù)據(jù)在在網(wǎng)頁端加載載，并傳輸至至服務(wù)器存儲儲，由服務(wù)器器將數(shù)據(jù)發(fā)送送至移動平臺臺，數(shù)據(jù)單向向流動。移動平臺API請請求測試：API請求類型請求次數(shù)成功次數(shù)成功率平均資源占用GET100100100%35kB方案成本分析：類型費用清單成本服務(wù)器端服務(wù)器升級0元參考資料250元數(shù)據(jù)庫開發(fā)500元服務(wù)器端開發(fā)200元網(wǎng)頁端網(wǎng)頁功能調(diào)試450元網(wǎng)頁端開發(fā)800元移動端云、端調(diào)試200元移動端開發(fā)300元數(shù)據(jù)流API請求類型G開發(fā)成本400元4G網(wǎng)絡(luò)成本120元數(shù)據(jù)流環(huán)節(jié)3個成本總計3220元優(yōu)點：1、API測試滿滿足要求；2、移動端、服務(wù)務(wù)器端開發(fā)成成本低；缺點：1、總體成本最高高；2、數(shù)據(jù)流環(huán)節(jié)增增加網(wǎng)頁端，數(shù)數(shù)據(jù)安全性低低；3、平均資源占用用高于方案二二。不選用該方案試驗時間：20116年3月12日地點：：辦公室負(fù)責(zé)責(zé)人：張偉偉偉通過分析比較，小組成員選擇從移動平臺端發(fā)布作為網(wǎng)絡(luò)發(fā)布的方式。2）采用順序流程審核方法3月15-17日，小組成員張偉偉、胡弢、邵林對風(fēng)險預(yù)警信息審核方法進(jìn)行了分析比較，并開展試驗分析，分析結(jié)果如下表：表3-3預(yù)警信息審核方式選擇方案選擇方案說明試驗分析特點結(jié)論方案目標(biāo)：信息審審核正確率高高于98%，審審核耗時小于于2min，成成本盡量低。試驗說明：小組成成員分成2組組，1組編寫寫200條事事故風(fēng)險預(yù)警警信息，另11組分別采用用以下三種方方法進(jìn)行審核核試驗。（其中復(fù)合審核中中程序僅開發(fā)發(fā)數(shù)字比對功功能，智能審審核程序僅開開發(fā)數(shù)字比對對和因果邏輯輯檢測功能）智能審核方案說明：智能審審核程序判斷斷邏輯如圖所所示，通過數(shù)數(shù)據(jù)庫比對算算法，檢驗一一二次設(shè)備名名稱、邏輯正正確性。試驗分析：序號12…200平均最大內(nèi)存占用/MB3.223.13…3.453.213.55是否正確是是是審核時間/s4.54.5…4.84.64.9審核平均耗時4.7s審核正確率/%92開發(fā)用時/min190開發(fā)成本/元1200人工審核成本0對智能審核的錯誤誤類型進(jìn)行分分析，如下：優(yōu)點：審核平均耗時最短短；缺點：1.開發(fā)用時最高高；2.內(nèi)存占用高，影影響流暢度；；3.開發(fā)成本最高高。不選用該方案經(jīng)驗審核方案說明：采用調(diào)調(diào)度員本人憑憑經(jīng)驗、知識識進(jìn)行審核。試驗分析：序號12…200平均最大內(nèi)存占用/MB00…000是否正確是否是審核時間/min2.52.7…2.82.63.0審核平均耗時2.8min審核正確率/%85開發(fā)成本/元0人工審核成本100元對經(jīng)驗審核的錯誤誤類型進(jìn)行分分析，如下：：優(yōu)點：1.無需開發(fā)審核核程序；2.不占用系統(tǒng)統(tǒng)軟硬件資源源；3.成本最低；缺點：1.審核正確率低低，編號名稱稱錯誤居多；；2.審核時間過過長；不選用該方案復(fù)合審核方案說明：編輯僅僅自動比對名稱、數(shù)字的程序序，與經(jīng)驗審核核結(jié)合。試驗分析：序號12…200平均最大內(nèi)存占用/kB233251…273242242是否正確是是是審核時間/min1.51.2…1.61.51.7審核平均耗時1.7min審核正確率/%99.5開發(fā)用時/min20開發(fā)成本/元200人工審核成本100元注：其中程序，僅僅對設(shè)備名稱稱、數(shù)字編號號內(nèi)容進(jìn)行校校對，減少檢檢索信息，實實現(xiàn)預(yù)警內(nèi)容容的快速初審審；優(yōu)點：1．審核正確率最最高；2.程序開發(fā)用時時短；3.開發(fā)成本低；；缺點：1、驗證時間長于于智能審核，但但滿足目標(biāo)要要求。選用該方案試驗時間：20116年3月115日地點：：調(diào)控中心辦辦公室負(fù)責(zé)人人：張偉偉經(jīng)過比較分析，QC小組決定選用復(fù)合審核方法作為臨時風(fēng)險預(yù)警信息的順序流程審核方法的具體方案。3）采用圖形界面顯示方式3月18-19日，小組成員邵林、黃震對人機圖形界面設(shè)計方法進(jìn)行了比較，分析結(jié)果如下表：表3-4圖形功能界面設(shè)計方法選擇方案選擇方案說明試驗分析特點結(jié)論方案目標(biāo)：圖形界界面加載時間間小于0.22s試驗說明：小組成成員分別按照照三種方法設(shè)設(shè)計按鈕圖案案，在單個圖圖形界面中加加載10個按按鈕，編程對對三種方法的的加載時間進(jìn)進(jìn)行測試。采用扁平化顯示方案說明：指圖形形元素采用二二維設(shè)計，即即采用抽象、簡簡化、符號化化的設(shè)計元素素試驗結(jié)果：序號12…100平均最大內(nèi)存占用/kB6.36.8…6.56.67.1加載時間/s0.120.10…0.110.120.13開發(fā)用時/min23注：每一次測試均均需清空緩存存設(shè)計開發(fā)流程分析析：優(yōu)點：1、界面加加載時間符合合要求；2、開發(fā)用時最短短；3、內(nèi)存占用最低低；缺點：圖形設(shè)計簡簡單，但符合合要求。選用該方案采用擬物化顯示方案說明：指圖形形元素采用三三維設(shè)計，增增加特效與質(zhì)質(zhì)感。試驗分析：序號12…100平均最大內(nèi)存占用/kB33.232.2…31.532.133.2加載時間/s0.310.27…0.260.290.32開發(fā)用時/min64注：每一次測試均均需清空緩存存設(shè)計開發(fā)流程分析析：比之采用扁平化設(shè)設(shè)計，增加藍(lán)藍(lán)色部分流程程。優(yōu)點：圖形設(shè)計立立體；缺點：1、界面加載時間間不符合要求求；2、內(nèi)存占用較高高；3、開發(fā)用時較長長。不選用該方案采用卡通化顯示方案說明：指圖形形元素采用卡卡通形象的方方式進(jìn)行呈現(xiàn)現(xiàn)。試驗分析：序號12…100平均最大內(nèi)存占用/kB34.835.2…36.534.836.5加載時間/s0.350.33…0.350.320.35開發(fā)用時/min78注：每一次測試均均需清空緩存存設(shè)計開發(fā)流程分析析：比之采用擬物化設(shè)設(shè)計，增加紫紫色部分流程程。優(yōu)點：圖形設(shè)計生動；缺點：1、界面加載時間間最長；2、內(nèi)存占用最高高；3、開發(fā)用時最長長。不選用該方案試驗時間：20116年3月115日地點：：調(diào)控中心辦辦公室負(fù)責(zé)人人：邵林（二）軟件開發(fā)1）采用關(guān)系型數(shù)據(jù)庫結(jié)構(gòu)建模3月23日，小組成員張偉偉、邵林、黃震對服務(wù)器云端數(shù)據(jù)結(jié)構(gòu)采用何種方式建模進(jìn)行分析。表3-5數(shù)據(jù)結(jié)構(gòu)選擇方案選擇方案說明試驗分析特點結(jié)論方案目標(biāo)：50條條并行數(shù)據(jù)處處理響應(yīng)時間間低于0.55s。試驗描述：小組成成員在電腦上上安裝了SQQLSerrver20005，并在在該數(shù)據(jù)庫程程序中模擬建建模，形成表表單1、表單單2，并編寫寫兩個簡易功功能I、功能能II函數(shù)，并并在不同的數(shù)數(shù)據(jù)結(jié)構(gòu)下進(jìn)進(jìn)行交叉訪問問測試。分散式布局方案說明：各功能模塊各自對對應(yīng)各自數(shù)據(jù)據(jù)表格，功能能模塊間不能能互相訪問數(shù)數(shù)據(jù)；交叉訪問試驗：功功能II訪問問表單1數(shù)據(jù)請求，執(zhí)行步步驟：讀操作：功能III—>功能II—>表單11—>功能II—>功能III；寫操作：功能III—>功能II—>表單11—>功能II—>功能III；改操作：功能III—>功能II—>表單11—>功能II—>功能III；安全審核：功能II、II函數(shù)數(shù)均需審核請請求發(fā)起的安安全性。交叉訪問并行請求求響應(yīng)測試：：并行請求數(shù)10條20條30條40條50條讀響應(yīng)時間（/s）0.320.450.670.870.96寫響應(yīng)時間（/s）0.350.490.730.921.03改響應(yīng)時間（/s）0.360.480.720.931.01優(yōu)點：數(shù)據(jù)安全性性高；缺點：1.并行請求響應(yīng)應(yīng)時間最長；；2.數(shù)據(jù)請求執(zhí)行行步驟多不選用該方案統(tǒng)一式布局說明：各功能模塊所需數(shù)數(shù)據(jù)統(tǒng)一分類類，同類數(shù)據(jù)據(jù)歸一對應(yīng)類數(shù)據(jù)表表格中，各功功能模塊可訪訪問同一數(shù)據(jù)據(jù)；交叉訪問試驗：功功能II訪問問表單1數(shù)據(jù)請求，執(zhí)行步步驟：讀操作：功能III—>表單11；寫操作：功能III—>表單11；改操作：功能III—>表單11；安全審核：功能III函數(shù)需審審核請求發(fā)起起的安全性。交叉訪問并行請求求響應(yīng)測試：：并行請求數(shù)10條20條30條40條50條讀響應(yīng)時間（/s）0.180.250.310.390.45寫響應(yīng)時間（/s）0.190.280.320.410.46改響應(yīng)時間（/s）0.200.290.340.420.47優(yōu)點：1數(shù)據(jù)請求執(zhí)行步驟驟最少；2、響應(yīng)速度最快快；缺點：1.安全全審核環(huán)節(jié)最最少；不選用該方案交互式布局方案說明：各功能模塊對應(yīng)一一個表單，表表單間依據(jù)關(guān)關(guān)系數(shù)據(jù)庫原原理進(jìn)行鍵值值關(guān)聯(lián)，提高高交叉訪問效效率；交叉訪問試驗：功功能II訪問問表單1數(shù)據(jù)請求，執(zhí)行步步驟：讀操作：功能III—>表單11；寫操作：功能III—>功能II—>表單11—>功能II—>功能III；改操作：功能III—>功能II—>表單11—>功能II—>功能III；安全審核：讀操作作僅功能III審核，寫、改改操作需經(jīng)功功能I、III審核。交叉訪問并行請求求響應(yīng)測試：：并行請求數(shù)10條20條30條40條50條讀響應(yīng)時間（/s）0.170.240.300.370.45寫響應(yīng)時間（/s）0.210.280.320.410.48改響應(yīng)時間（/s）0.220.290.330.400.49優(yōu)點：1.讀請求響應(yīng)時時間最短；2.數(shù)據(jù)寫、改操操作安全性高高；缺點：安全審核環(huán)環(huán)節(jié)少但不影影響數(shù)據(jù)安全全選用該方案分析時間：20116年3月223日地點：：調(diào)控中心會會議室負(fù)責(zé)人人：金鑫，王王輝根據(jù)分析結(jié)果，小組決定在云端關(guān)系數(shù)據(jù)庫中采用交互式布局作為數(shù)據(jù)結(jié)構(gòu)。2）采用框架切換模式開發(fā)2016年3月24—27日，小組成員金鑫、王輝、周磊在調(diào)控中心辦公室對多種編程方法通過網(wǎng)上資料查詢，如web網(wǎng)頁加殼生成移動平臺、web網(wǎng)頁與原生語言混編、原生態(tài)開發(fā)等，并進(jìn)行了分析比較：表3-6移動平臺開發(fā)方法比較方案選擇方案說明試驗分析特點結(jié)論方案目標(biāo)：登錄及及驗證成功率率不小于999%，信息驗驗證時間不超超過0.5ss；試驗描述：依據(jù)以以下三種方案案，分別編寫寫三個Anddroid版版登錄驗證界界面，加載同同一個信息驗驗證函數(shù)進(jìn)行行測試及比較較。Web網(wǎng)頁加殼生生成移動平臺臺客戶端方案說明：將WEEB網(wǎng)頁封裝裝成移動平臺臺樣式，本質(zhì)質(zhì)是對網(wǎng)頁的的訪問，只是是屏蔽了地址址欄等信息。試驗結(jié)果：序號12…50平均最大驗證時間/s0.610.65…0.630.630.69內(nèi)存占用/kB12.713.1…13.413.213.6流量消耗/kB22.322.5…22.222.422.9驗證結(jié)果正確正確…正確驗證成功率98%開發(fā)用時62min優(yōu)點：1、開發(fā)速度最快快缺點：1、驗證耗時長；；2、內(nèi)存占占耗高，流量量消耗大；33、驗證成功功率不滿足要要求不選用該方案Web網(wǎng)頁、原生生態(tài)混編方案說明：數(shù)據(jù)訪訪問直接調(diào)用用底層原生函函數(shù)，Htmml5網(wǎng)頁實實現(xiàn)主體UII界面試驗結(jié)果：序號12…50平均最大驗證時間/s0.410.45…0.430.430.47內(nèi)存占用/kB8.79.2…9.18.89.2流量消耗/kB17.318.5…17.817.918.5驗證結(jié)果正確正確…正確驗證成功率100%開發(fā)用時75min優(yōu)點：1、內(nèi)存占用不高高；2、流量量消耗較少；3、驗證耗耗時較短；缺點：1、開發(fā)用時較長長，但遠(yuǎn)低于于原生態(tài)開發(fā)發(fā)，滿足要求求。選用該方案原生態(tài)開發(fā)方案說明：完全使使用javaa語言開發(fā)安安卓系統(tǒng)驗證證函數(shù)。試驗結(jié)果：序號12…50平均最大驗證時間/s0.340.35…0.390.370.41內(nèi)存占用/kB6.76.2…6.46.46.9流量消耗/kB14.314.5…14.814.414.9驗證結(jié)果正確正確…正確驗證成功率100%開發(fā)用時190min優(yōu)點：1、驗證時間最短短；2、內(nèi)存占用、流流量消耗最少少；缺點：1、開發(fā)耗時最長長，難度高不選用該方案分析時間：20116年3月227日地點：：調(diào)控中心會會議室負(fù)責(zé)人人：金鑫，王王輝通過分析比較，小組成員從小組技術(shù)水平、熟練度等方面綜合考慮，根據(jù)上述比較表格，選擇Web網(wǎng)頁、原生態(tài)混編方式作為移動終端軟件開發(fā)方法。由此，一級方案全部確定，如圖3-3所示：圖3-3一級方案比選結(jié)果框圖2.二級方案選擇（一）WEB網(wǎng)頁、原生態(tài)混編方法的選擇3月29日，本小組成員張永豐、邵林、周磊針對現(xiàn)有的WEB網(wǎng)頁、原生態(tài)混編方法的具體執(zhí)行方案進(jìn)行選擇，這里對可能采取的開發(fā)語言方案進(jìn)行比較分析：表3-7WEB網(wǎng)頁、原生態(tài)混編執(zhí)行方案比較方案目標(biāo)開發(fā)周期盡量短，開開發(fā)成本盡量量低。語言（網(wǎng)頁+腳本）語語言+原生開發(fā)語言言（網(wǎng)頁+腳本）語語言+APIICloudd平臺（網(wǎng)頁+腳本）語語言+Dclloud框架架語言特點網(wǎng)頁語言指Htmml語言，腳腳本語言指JJSP即Jaavascrript語言言，具有良好好的適配性。原生開發(fā)語言主要要指針對安卓卓系統(tǒng)的JAAVA語言和和針對蘋果系系統(tǒng)的ObjjectivveC語言；；Apicloudd開發(fā)平臺可可以實現(xiàn)安卓卓、IOS系系統(tǒng)的同時開開發(fā)，具有編編譯轉(zhuǎn)換特性性，實現(xiàn)原生生代碼的轉(zhuǎn)譯譯DCLOUD提供供前端框架，擴擴展HTMLL5的特性。開發(fā)周期150天75天120天開發(fā)成本IOS證書相關(guān)成成本600元元+程序開發(fā)發(fā)成本8000元+數(shù)據(jù)庫庫開發(fā)成本3300元；IOS證書成本6600元+程程序開發(fā)成本本500元；；IOS證書成本6600元+程程序開發(fā)成本本600元++數(shù)據(jù)庫開發(fā)發(fā)成本3000元；成本合計1700元1100元1500元模塊調(diào)用調(diào)用JAVA、OObjecttive-CC函數(shù)包，具具體功能實現(xiàn)現(xiàn)依賴代碼編編輯；APICLOUDD提供大量通通用UI功能能模塊，直接接調(diào)用，提升升開發(fā)效率不自帶UI模塊，支支持三方框架架。費用1700元1100元1500元優(yōu)點程序適配性好開發(fā)周期短，開發(fā)發(fā)難度較低，成成本低程序結(jié)構(gòu)優(yōu)化，程程序適配性好好缺點開發(fā)周期最長，成成本最高，開開發(fā)難度較高高需掌握多門門程序語言程序流暢度存在風(fēng)風(fēng)險開發(fā)周期較長，開開發(fā)難度較高高結(jié)論不選用選用不選用通過對WEB網(wǎng)頁、原生態(tài)混編方法的具體執(zhí)行方案的比較，小組決定選用(網(wǎng)頁+腳本)語言+APICloud平臺作為具體執(zhí)行方案。3.確定最佳方案通過以上五組一級方案選擇，一組二級方案選擇，本課題臨時風(fēng)險預(yù)警發(fā)布平臺開發(fā)的最佳方案全部確定，如圖3-4所示。圖3-4最佳方案結(jié)果框圖四、制定對策表3月31日，全體小組成員依據(jù)確定的最優(yōu)方案，小組制定了對策計劃表，如表4-1所示。表4-1對策計劃表序號方案對策目標(biāo)措施地點負(fù)責(zé)人完成時間1采用網(wǎng)絡(luò)方式進(jìn)行行發(fā)布采用移動平臺端進(jìn)進(jìn)行發(fā)布API請求成功率率高于98%%1、設(shè)計API請請求測試流程程；2、測試API請請求成功率。調(diào)度DTS室黃震2016.4.1152采用順序流程審核核方法采用復(fù)合審核方法法信息審核正確率高高于98%，審審核耗時小于于2min1、制定預(yù)警信息息復(fù)合審核流流程圖；2、測試預(yù)警單審審核正確率。會議室王輝2016.5.0053采用圖形界面顯示示方式采用扁平化顯示圖形界面加載時間間小于0.22s1、設(shè)計移動設(shè)備備各功能界面面；2、設(shè)計集中推送送顯示界面；；3、測試各功能界界面加載時間間；調(diào)度DTS室王傳能2016.6.0024采用關(guān)系型數(shù)據(jù)庫庫建模采用交互式布局?jǐn)?shù)數(shù)據(jù)結(jié)構(gòu)50條數(shù)據(jù)并行處處理響應(yīng)時間間低于0.55s1、選擇數(shù)據(jù)庫服服務(wù)器；2、建立服務(wù)器端端數(shù)據(jù)庫表單單結(jié)構(gòu)；3、進(jìn)行服務(wù)器端端并行響應(yīng)測測試。會議室周磊2016.6.1125采用框架切換模式式開發(fā)采用(網(wǎng)頁和腳本本)語言+AApiclooud平臺功能驗收成功率高高于98%1、設(shè)計登錄及注注冊流程；2、分解功能模塊塊并設(shè)計主界界面；3、進(jìn)行平臺預(yù)警警信息發(fā)布在在線測試；4、驗收功能流轉(zhuǎn)轉(zhuǎn)全過程；會議室邵林2016.6.330五、按對策表實施一、對策實施一：采用移動平臺端進(jìn)行發(fā)布1.設(shè)計API請求測試流程4月15-16日，QC小組成員王輝、周磊對移動平臺端提請的數(shù)據(jù)請求測試流程進(jìn)行了設(shè)計，如圖5-1。API請求包含數(shù)據(jù)更新（PUT）、數(shù)據(jù)索?。℅ET）、數(shù)據(jù)提交（POST）、數(shù)據(jù)刪除（DELETE），四種API請求的流程相同。圖5-1API請求數(shù)據(jù)流程圖API請求的提交采用APICloud平臺進(jìn)行測試，其中GET測試提交畫面如圖5-2所示，測試返回結(jié)果如圖5-3所示，小組成員測試實施畫面如圖5-4。圖5-2API請求GET測試畫面圖5-3API請求GET返回數(shù)據(jù)畫面圖5-4小組成員測試API請求畫面2.測試API請求成功率對策目標(biāo)驗證：4月20日，小組成員張永豐、邵林、金鑫按照以上測試方法，對API請求進(jìn)行測試，每種API請求測試1000條數(shù)據(jù)請求，其中：綜合成功率=發(fā)送成功率×返回成功率，測試結(jié)果如下表所示：表5-1API請求測試表API請求類型數(shù)據(jù)更新（PUTT）數(shù)據(jù)索?。℅ETT）數(shù)據(jù)提交（POSST）數(shù)據(jù)刪除（DELLETE）發(fā)送成功率(/%%)99.999.899.999.6返回成功率(/%%)99.399.699.299.7綜合成功率(/%%)99.299.499.199.3由上表可見，API請求成功率高于98%，對策目標(biāo)實現(xiàn)。二、對策實施二：采用復(fù)合審核1.制定預(yù)警信息復(fù)合審核流程圖5月5-7日，小組成員楊洋、王傳能、張偉偉制定了采用順序流程審核方法的預(yù)警信息審核流程，如圖5-5中左側(cè)所示。為了實現(xiàn)復(fù)合審核，小組成員繼續(xù)編寫了名稱、編號審核程序，該審核程序的基本原理如圖5-5中右側(cè)虛線部分所示。圖5-5復(fù)合審核流程圖2.測試預(yù)警單審核正確率對策目標(biāo)驗證：小組成員王傳能、邵林在移動平臺程序中添加初審程序后，對信息審核進(jìn)行測試，集中6名正值調(diào)度員，由小組成員黃震、王輝、周磊負(fù)責(zé)對事故信息進(jìn)行修改后形成200條事故信息，并采用復(fù)合審核法。使用電腦模擬調(diào)試，如圖5-6所示。圖5-6電腦模擬調(diào)試畫面表5-2預(yù)警單審核測試審核員姓名胡弢楊洋張永豐范敏管浦民馮明生審核預(yù)警單數(shù)303040403030平均耗時/minn1.51.61.51.51.61.6審核出錯數(shù)001110綜合正確率98.5%經(jīng)測試后，得出試驗結(jié)果如表5-2所示，由此可見，采用復(fù)合審核法后綜合正確率高于98%，結(jié)論：對策目標(biāo)實現(xiàn)。三、對策實施三：采用扁平化顯示1.設(shè)計移動設(shè)備各功能界面5月29-31日，小組成員邵林、金鑫、王輝對移動平臺端功能進(jìn)行功能界面顯示設(shè)計，預(yù)警通知單流轉(zhuǎn)周期如圖5-6所示：圖5-7臨時風(fēng)險預(yù)警通知單的流轉(zhuǎn)周期（一）預(yù)警編寫、錄入功能界面設(shè)計第一步，數(shù)據(jù)錄入功能，編寫新預(yù)警界面顯示如圖5-7，按內(nèi)容對應(yīng)填寫，將當(dāng)前電網(wǎng)事故或缺陷錄入系統(tǒng)。圖5-8編寫新預(yù)警（二）預(yù)警審核、查閱及歸檔功能界面設(shè)計第二步，預(yù)警審核、查閱及歸檔界面顯示設(shè)計。打開待審核預(yù)警單后，審核正確則簽名審核通過，如圖5-8中左一所示；審核通過則預(yù)警單進(jìn)入發(fā)布環(huán)節(jié)，此時可進(jìn)入預(yù)警查閱界面點擊對應(yīng)預(yù)警單打開，如圖5-8中右側(cè)兩圖所示；預(yù)警單歸檔則如圖5-8中間圖所示。圖5-9預(yù)警審核、查閱及歸檔2.設(shè)計集中推送功能界面風(fēng)險預(yù)警信息集中推送，該功能在服務(wù)器端設(shè)計推送平臺實現(xiàn)，在該平臺中填入推送信息后點擊“發(fā)送”即可，推送時可以指定特定用戶群體進(jìn)行推送，界面顯示如圖5-9所示。圖5-10云端服務(wù)器消息推送界面3.測試各功能界面加載時間對策目標(biāo)驗證：表5-3功能界面加載時間測試序號功能界面名稱12…100平均最大功能界面加載時間間/s打開新預(yù)警0.080.06…0.090.080.11草稿提交及返回0.130.11…0.090.120.13審核通過及退回0.120.11…0.130.120.13預(yù)警信息查閱0.140.13…0.120.130.14信息推送0.090.05…0.060.080.116月1-2日，小組成員對各功能圖形界面的加載時間進(jìn)行了測試，測試結(jié)果如上表。測試結(jié)果顯示，最大界面加載時間均不超出0.2s，因此得出結(jié)論：對策目標(biāo)實現(xiàn)。四、對策實施四：采用交互式布局?jǐn)?shù)據(jù)結(jié)構(gòu)1.選擇數(shù)據(jù)庫服務(wù)器6月3-9日，QC小組成員金鑫、邵林、周磊在調(diào)控中心會議室內(nèi)就云端服務(wù)器的選擇進(jìn)行了分析論證，本平臺經(jīng)綜合需求分析，服務(wù)器的配置采用單CPU、單可用IP、100G硬盤需求、100M共享帶寬、處理器選用Intel酷睿i3、4G內(nèi)存，定位為數(shù)據(jù)庫服務(wù)器，可完全滿足要求，根據(jù)上述分析選擇比對如下：表5-4數(shù)據(jù)庫服務(wù)器選擇比較分析表方案選擇數(shù)據(jù)庫服務(wù)成本費費用比較結(jié)論購買1臺數(shù)據(jù)服務(wù)務(wù)器單臺1萬-5萬不不等，考慮本本平臺對服務(wù)務(wù)器的性能要要求有限，以以華為FussionSeerverRH12888–V3型號為為例，性能滿滿足要求，市市場售價在11.1萬元左左右，屬于一一次性投資。不選用租賃網(wǎng)絡(luò)數(shù)據(jù)服務(wù)務(wù)器根據(jù)選擇要求，查查閱相關(guān)企業(yè)業(yè)的服務(wù)器租租賃價格如下下表，帶寬均為百百兆共享，可見平均租租賃價格P在在3000￥￥/年左右：處理器內(nèi)存硬盤價格(元/年)Q93004G500G3200E58004G500G2500Q66004G500G3500不選用選擇云儲存服務(wù)商商的云端服務(wù)務(wù)對國內(nèi)云端存儲價價格調(diào)研結(jié)果果如下表，本本平臺預(yù)計需需要存儲空間間100G，流流量每月200GB即可滿滿足，數(shù)據(jù)請請求預(yù)計每月月最多5萬次次，數(shù)據(jù)geet操作每月月5萬次，DDELETEE操作每月11000次，則則折算成本為為：P=2.04×1100+200×12×00.55+00.5×122+(0.005+0.001)×122=342..72(￥/年)存儲空間流量數(shù)據(jù)請求空間范圍價格(￥/年)流出(/月)價格請求方式價格(￥/千次請求)0-50TB2.04/GB0-2TB0.55/GBPUT/COPY/POST/LIST0.0150-500TB1.98/GB2-100TB0.50/GBGET0.001500-5000TB1.92/GB100-200TB0.45/GBDELETE0.01＞5000TB1.86/GB＞200TB0.40/GB選用通過對云端服務(wù)的成本比較，小組決定采用選擇云存儲服務(wù)商的云端服務(wù)，作為服務(wù)器端的選擇方式。6月4日，小組成員張永豐、黃震查閱關(guān)于云端服務(wù)商的資料后，進(jìn)行了比較分析，結(jié)果如表5-5所示：表5-5云存儲服務(wù)商選擇比較表方案選擇成本分析優(yōu)點分析結(jié)論選擇又拍云存儲服服務(wù)比較流量下載成本本：流量下載價格0-3TB0.4元/GB3-5TB0.38元/GB上傳下載加速；自自建CDN；；能夠進(jìn)行日日志分析；具具備彈性擴容容結(jié)合本平臺特點，又又拍云價格相相對便宜，按按實時使用量量計費，下載載加速能力迎迎合本平臺的的速度需求；；七牛云側(cè)重重于圖片、視視頻的上傳等等富媒體技術(shù)術(shù)，非本平臺臺側(cè)重。選用該方案選擇七牛云存儲服服務(wù)比較流量下載成本本：流量下載價格0-2TB0.5元/GB2-100B0.45元/GB特有的上傳加速能能力；特有的斷點點續(xù)上傳功能能；獨特的鏡像像存儲；流媒體（音音視頻處理）支支持；數(shù)據(jù)處理功功能的級聯(lián)不選用該方案QC小組成員比較分析后，選擇又拍云服務(wù)作為本平臺的云端服務(wù)提供商。2.建立服務(wù)器端數(shù)據(jù)庫表單結(jié)構(gòu)6月7-11日，小組成員王傳能在云端數(shù)據(jù)庫采用交互式布局，建立數(shù)據(jù)庫表單，如圖5-10。草稿箱表單、發(fā)布中表單的數(shù)據(jù)信息與待審核表單中數(shù)據(jù)信息一致，故圖中不再贅述。每一份預(yù)警通知單對應(yīng)唯一的編號，同時作為表格的主鍵，并與其它表格進(jìn)行關(guān)聯(lián)，便于進(jìn)行統(tǒng)一管理。圖5-11服務(wù)器端數(shù)據(jù)結(jié)構(gòu)分解圖小組成員邵林、周磊在移動平臺端進(jìn)行數(shù)據(jù)交互訪問的編程，圖5-11為向服務(wù)器端存入數(shù)據(jù)的邏輯程序。小組成員繼續(xù)對數(shù)據(jù)的交互性能、并行傳送的能力進(jìn)行了驗證，分析此臨時風(fēng)險預(yù)警發(fā)布系統(tǒng)的應(yīng)用場景為公司生產(chǎn)系統(tǒng)內(nèi)部使用，用戶人數(shù)正常不超出100人，設(shè)置并行能力下限為50條/s，足以滿足并行數(shù)據(jù)處理要求，避免宕機、卡數(shù)據(jù)現(xiàn)象的發(fā)生。圖5-12數(shù)據(jù)提提交至服務(wù)器器端的實現(xiàn)代代碼3.進(jìn)行服務(wù)器端端并行響應(yīng)測測試對策目標(biāo)驗證：小組成員張永豐、王王傳能選擇采采用APICCloud平平臺進(jìn)行服務(wù)務(wù)器端的數(shù)據(jù)據(jù)并行響應(yīng)測測試，選取產(chǎn)生數(shù)數(shù)據(jù)流量最大大的操作-創(chuàng)創(chuàng)建新預(yù)警進(jìn)進(jìn)行測試，使使用軟件“海海馬玩”模擬擬器，進(jìn)行移移動設(shè)備訪問問測試，分別別模擬10臺臺至50臺移移動設(shè)備的并并行訪問，進(jìn)進(jìn)行測試結(jié)果果如下：表5-6并行響應(yīng)應(yīng)測試并發(fā)設(shè)備數(shù)量10臺20臺30臺40臺50臺提交成功率（%）100100100100100數(shù)據(jù)正確率（%）100100100100100響應(yīng)平均時間（//s）0.4s0.420.450.460.48從表5-6中結(jié)果果可以看出，移移動平臺端收收到服務(wù)器反反饋信息后的的響應(yīng)平均時時間低于0..5s，滿足足設(shè)定目標(biāo)，結(jié)結(jié)論：對策目目標(biāo)實現(xiàn)。五、對策實施五：：采用(網(wǎng)頁頁+腳本)語語言+Apiicloudd平臺1.設(shè)計登錄及注注冊流程2016年6月111-30日日，小組成員員邵林，王輝輝，基于APPIClouud平臺，采采用網(wǎng)頁+腳腳本語言編程程設(shè)計完善登登錄及注冊流流程，如圖55-12所示示。其中的校校驗和驗證環(huán)環(huán)節(jié)均通過在在服務(wù)器端與與數(shù)據(jù)庫比對對實現(xiàn)。圖5-13登錄及及驗證流程圖圖2.分解功能模塊塊并設(shè)計主界界面2015年4月220日至6月月30日，小小組成員邵林林、王傳能進(jìn)進(jìn)行了基于（網(wǎng)網(wǎng)頁+腳本）語語言+APIICloudd平臺的模塊塊設(shè)計，對所所有移動平臺臺窗口的圖形形界面按照扁扁平化顯示的的要求，進(jìn)行行編程實現(xiàn)。根據(jù)臨時風(fēng)險預(yù)警警系統(tǒng)的功能能需求，將該該風(fēng)險預(yù)警發(fā)發(fā)布平臺功能能模塊設(shè)計分分為三個層級級，各層級劃劃分如圖5--13所示。圖5-14移動平平臺端三級功功能分解圖進(jìn)行臨時風(fēng)險預(yù)警警發(fā)布平臺主主界面設(shè)計。主主界面UI程程序代碼如圖圖5-14，功功能主界面UUI設(shè)計界面面示例如圖55-15所示示，其余功能能界面依據(jù)對對策實施三中中的扁平化設(shè)設(shè)計進(jìn)行編程程實現(xiàn)。圖5-15主界面面程序代碼圖5-16功能主主界面及菜單單UI顯示3.進(jìn)行平臺預(yù)警警信息發(fā)布在在線測試2016年7月在在移動平臺投投入試運行前前，QC小組組對移動平臺臺的發(fā)布時間間進(jìn)行了試驗驗，測試表格格如圖5-116所示。圖5-17第一小小組測試記錄錄表格每組人員隨機抽取取20組各類類型故障，結(jié)結(jié)果統(tǒng)計如下下表所示：表5-7發(fā)布耗時時試驗測試結(jié)結(jié)果測試小組小組人員發(fā)布平均耗時/mmin單次最長耗時/mmin第一小組王傳能，王輝911第二小組胡弢，金鑫1012第三小組張偉偉，邵林811第四小組張永豐，黃震9114.驗收功能流轉(zhuǎn)轉(zhuǎn)全過程對策目標(biāo)驗證：表5-8功能在線線測試驗收表表測試功能創(chuàng)建新預(yù)警草稿提交及修改審核提交及退回信息發(fā)布及流轉(zhuǎn)信息推送測試人測試次數(shù)2020202020邵林，王輝成功次數(shù)2020202020邵林，王輝成功率(%)100100100100100邵林，王輝小組成員邵林、王王輝對本移動動平臺進(jìn)行功功能驗收，測測試結(jié)果如表表5-8所示示，從中可以以看出，移動動平臺功能驗驗收成功率為為100%，高高于98%的的驗收目標(biāo)，結(jié)結(jié)論：對策目目標(biāo)實現(xiàn)。六、效果檢查一、事故信息及臨臨時風(fēng)險發(fā)布布時間對比2016年7月中中旬，電網(wǎng)臨臨時風(fēng)險預(yù)警警發(fā)布平臺投投入試運行后后，經(jīng)20116年7-11月的實實際試運行，共共計統(tǒng)計故障障次數(shù)見表66-1，其中中故障對應(yīng)的的電網(wǎng)臨時風(fēng)風(fēng)險預(yù)警通知知耗時的統(tǒng)計計分析見表66-2，從中中可見發(fā)布耗耗時與實施前前相比均有明明顯下降。表6-12016年77月-11月月故障次數(shù)統(tǒng)統(tǒng)計表市區(qū)范圍縣城城區(qū)鄉(xiāng)鎮(zhèn)及農(nóng)村故障次數(shù)61015表6-2實施前后后耗時對比統(tǒng)統(tǒng)計表時間故障類型市區(qū)范圍/minn縣城城區(qū)/minn鄉(xiāng)鎮(zhèn)及農(nóng)村/miin實施前(20155.8-20016.3))平均耗時41.53428.5發(fā)布最長耗時534433實施后(20166.7-2016..11)平均耗時1297.5發(fā)布最長耗時14119實施前后對比平均減少292521最長耗時減少393324二、目標(biāo)實現(xiàn)檢查查通過開展本次活動動，事故信息息及臨時風(fēng)險險預(yù)警的發(fā)布布時長從活動動前的最長553min，到到活動后的最最長14miin。具體情情況見圖6--1，從中可可見，課題目目標(biāo)實現(xiàn)。圖6-1活動對照照檢查圖三、實施前后流程程對比通過開展本次QCC活動，我們們對原本的臨臨時風(fēng)險預(yù)警警信息發(fā)布流流程進(jìn)行了成成功的優(yōu)化，QQC活動實施施前后的發(fā)布布流程如下圖圖所示，從中中我們可以看看到，整個發(fā)發(fā)布流程有原原本的8個步步驟減少為33個步驟。圖6-2QC活動動實施前后流流程對比圖四、經(jīng)濟效益1.增加收