智慧教育產(chǎn)品開發(fā)方案

1、（正本）智慧教育產(chǎn)品第一階段開發(fā)方案2019年2月12日1 .引言1.1. 目的為了讓用戶和軟件開發(fā)者雙方對系統(tǒng)的初始規(guī)定有一個共同的理解，使之 成為整個開發(fā)工作的基礎(chǔ)，特編寫本需求。本文檔主要對業(yè)務(wù)需求進行細致描述， 明確業(yè)務(wù)處理范圍，并對要實現(xiàn)的功能、輸入輸出數(shù)據(jù)和性能要求進行說明， 力 求準(zhǔn)確、清晰、完整地闡明用戶的需求，是進行需求分析的基礎(chǔ)。本文檔預(yù)期讀者：需求提出方，銀校聯(lián)盟市場人員參與需求分析、開發(fā)測試的人員1.2. 背景需求提出者需求完整名稱：銀校聯(lián)盟項目第一階段需求整理需求提出部門：2 .需求目標(biāo)2.1. 用戶描述填寫說明：本部分內(nèi)容描述需求涉及的用戶和角色。該部分內(nèi)容為必填。

2、銀校聯(lián)盟主要涉及以下用戶和角色：? 銀行? 校園聯(lián)盟運營方? 學(xué)校（培訓(xùn)機構(gòu)）? 商家（入駐）? 消費群體2.2. 業(yè)務(wù)價值填寫說明：描述需求中相關(guān)角色所關(guān)心的業(yè)務(wù)價值，建立業(yè)務(wù)價值與業(yè)務(wù)目 標(biāo)的關(guān)聯(lián)。該部分內(nèi)容為必填。1、打通消費群體與學(xué)校、商家之間的連接關(guān)系，通過銀校一賬通延伸消費場景；2、通過銀校聯(lián)盟運營，向更多的機構(gòu)、消費群體推廣，提高運營方整體利潤；3、建立圍繞學(xué)生教育培訓(xùn)的垂直電商平臺，向培訓(xùn)上下游產(chǎn)業(yè)鏈擴張； 4、建立學(xué)校、商家宣傳平臺，更好地推廣其課程和服務(wù)。3 .需求范圍3.1. 功能范圍本需求涉及的功能范圍主要包括用戶端和后臺管理端兩大功能體系。用戶端功能主要面向消費者，包

3、括：賬戶中心、賬戶充值（微信）、禮券兌 換、錢包管理、商家宣傳、學(xué)校簡介、線下支付、在線客服等功能。賬戶充值：用戶可通過微信對賬戶進行充值，用戶充值完成后，可通過 賬戶查看充值記錄；賬戶管理：用戶可以瀏覽查看賬戶歷次充值記錄、消費記錄、賬戶流水 等信息；禮券兌換：由平臺方設(shè)置相對應(yīng)的營銷策略，用戶充值成功后可購買相 應(yīng)的禮券用于銷費；禮券管理：用戶可以瀏覽查看禮券兌換記錄、消費記錄、禮券余額等信 息；賬戶中心：用于記錄用戶的基本信息、補充信息、學(xué)習(xí)信息、歷交充值 記錄、消費記錄、禮券使用情況等信息。商家宣傳：用于展示入駐平臺的商家的基本信息，商家所提供的產(chǎn)品信息、聯(lián)系地址等信息；學(xué)校簡介：用于

4、展示入駐平臺的學(xué)校、培訓(xùn)機構(gòu)的基本信息，課程信息, 培訓(xùn)內(nèi)容、聯(lián)系地址等信息。在線客服：用于在線與用戶溝通，商品答疑，售后服務(wù)等；后臺管理端功能主要面向平臺運營方、商家、學(xué)校（培訓(xùn)機構(gòu)）等，主要包 括：商家管理、學(xué)校（培訓(xùn)機構(gòu)）管理、支付管理、營銷策略、消費者管理、結(jié) 算管理、在線溝通、統(tǒng)計報表等功能；商家管理：主要用于平臺方對商家賬號的管理，商家發(fā)布信息的審核、真實性確認(rèn)等；學(xué)校（培訓(xùn)機構(gòu)）管理：主要用于平臺方對學(xué)校（培訓(xùn)機構(gòu)）的管理，對其發(fā)布信息的審核、真實性確認(rèn)等；支付管理：記錄用戶的充值記錄、充值流水、消費記錄，當(dāng)前賬戶情況 等信息；營銷策略：用于設(shè)置現(xiàn)金與禮券營銷策略，兌換情況，禮券

5、使用限制、 生效限制、使用說明等信息；消費者管理：用于收集用于消費者信息，便于后續(xù)營銷推廣；在線溝通：用于在線回答用戶所提疑問、售后咨詢等。結(jié)算管理：用于平臺方與商家、學(xué)校間進行支付結(jié)算使用，包括：交易 流水、交易頻率、交易周期等信息；商家和學(xué)校（培訓(xùn)機構(gòu)）用戶，主要用于發(fā)布基本信息、所提供服務(wù)內(nèi) 容資料的管理，用戶消費記錄，結(jié)算賬戶金額等信息。統(tǒng)計報表：用于記錄平臺運營數(shù)據(jù)的統(tǒng)計分析、報表生成等。3.2. 關(guān)鍵業(yè)務(wù)流程充值業(yè)務(wù)流程銀校平臺銀行商戶/學(xué)校支付業(yè)務(wù)流程4 .項目規(guī)劃4.1. 技術(shù)框架4.2. 研發(fā)計劃4.3. 資源配置5 .參考技術(shù)線路平臺支持微服務(wù)架構(gòu)，可由一個或多個微服務(wù)組成

6、。平臺中的各個微服務(wù)可 被獨立部署，各個微服務(wù)之間是松耦合的。每個微服務(wù)僅關(guān)注于完成一件任務(wù)并 很好地完成該任務(wù)。平臺要支持組件化、松耦合、服務(wù)自治、去中心化、容錯處 理、易擴展、監(jiān)控、支持不同的開發(fā)語言、獨立部署等。5.1. 分布式架構(gòu)分布式系統(tǒng)(distributed system )是建立在網(wǎng)絡(luò)之上的軟件系統(tǒng)。在分布式數(shù)據(jù)系統(tǒng)中，用戶感覺不數(shù)據(jù)是分布的，即用戶不須知道關(guān)系是否分割，有無副本，數(shù)據(jù)存在于那個站點以及事物在哪個站點上執(zhí)行。簡單來說：在一個分布式系統(tǒng)中，一組獨立的計算機展現(xiàn)給用戶的是一個統(tǒng) 一的整體，就好像是一個系統(tǒng)似的。分布式系統(tǒng)作為一個整體對用戶提供服務(wù)， 而整個系統(tǒng)的內(nèi)部

7、的協(xié)作對用戶 來說是透明的，用戶就像是指使用一個 mysql一樣。如：分布式mysql中間件mycat ,來處理大并發(fā)大數(shù)據(jù)量的構(gòu)架。5.2. RESTful 架構(gòu)RESTful是一種軟件架構(gòu)風(fēng)格、設(shè)計風(fēng)格，而不是標(biāo)準(zhǔn)，只是提供了一組設(shè) 計原則和約束條件。它主要用于客戶端和服務(wù)器交互類的軟件?；谶@個風(fēng)格設(shè)計的軟件可以更簡潔，更有層次，更易于實現(xiàn)緩存等機制。REST指的是一組架構(gòu)約束條件和原則。滿足這些約束條件和原則的應(yīng)用程 序或設(shè)計就是RESTful oWeb應(yīng)用程序最重要的REST原則是，客戶端和服務(wù)器之間的交互在請求之 問是無狀態(tài)的。從客戶端到服務(wù)器的每個請求都必須包含理解請求所必需的信

8、 息。如果服務(wù)器在請求之間的任何時間點重啟，客戶端不會得到通知。止匕外，無 狀態(tài)請求可以由任何可用服務(wù)器回答， 這十分適合云計算之類的環(huán)境。客戶端可 以緩存數(shù)據(jù)以改進性能。5.3. SO琳構(gòu)SOA(Service-Oriented Architecture),面向服務(wù)架構(gòu)，它可以根據(jù)需求 通過網(wǎng)絡(luò)對松散耦合的粗粒度應(yīng)用組件進行分布式部署、組合和使用。服務(wù)層是SOA勺基礎(chǔ)，可以直接被應(yīng)用調(diào)用，從而有效控制系統(tǒng)中與軟件代理交互的人為 依賴性。SOA是一種粗粒度、松耦合服務(wù)架構(gòu)，服務(wù)之間通過簡單、精確定義接口 進行通訊，不涉及底層編程接口和通訊模型。SOA以看作是B/S模型、XML/Web Serv

9、ice技術(shù)之后的自然延伸。SOA是一個組件模型，它將應(yīng)用程序的不同功能單元(稱為服務(wù))通過這 些服務(wù)之間定義良好的接口和契約聯(lián)系起來。接口是采用中立的方式進行定義 的，它應(yīng)該獨立于實現(xiàn)服務(wù)的硬件平臺、操作系統(tǒng)和編程語言。這使得構(gòu)建在各種這樣的系統(tǒng)中的服務(wù)可以一種統(tǒng)一和通用的方式進行交互。5.4. Web Service 技術(shù)WebService是解決程序之間互相通信的一項技術(shù)。嚴(yán)格地說，WebService 是描述一系列操作的接口。它使用標(biāo)準(zhǔn)的、規(guī)范的xmL苗述接口。這一描述中包 括與服務(wù)進行交換所需要的全部細節(jié)， 包括消息格式、傳輸協(xié)議和服務(wù)位置。而 在對外的接口中隱藏了服務(wù)實現(xiàn)的細節(jié)， 僅

10、提供一些列可執(zhí)行的操作，這些操作 獨立于軟、硬件平臺和編寫服務(wù)所用的編程語言。Web Service模型的解決方案中共有3種工作角色，包括服務(wù)提供者、服 務(wù)請求者和服務(wù)注冊中心。它們之間的交互和操作構(gòu)成了Web Service的體系結(jié)構(gòu)。服務(wù)提供者定義并實現(xiàn) WebService ,然后將服務(wù)描述發(fā)布到服務(wù)請求者 或服務(wù)注冊中心；服務(wù)請求者使用查找操作從本地或服務(wù)注冊中心檢索服務(wù)描述，然后使用服務(wù)描述與服務(wù)提供者進行綁定并調(diào)用Web Service 。Web Service模型的3種角色及它們之間的操作關(guān)系。要實現(xiàn)互操作性，Web Service平臺必須提供一套標(biāo)準(zhǔn)的類型系統(tǒng)，用于 溝通不同平

11、臺、編程語言和組件模型中的不同類型系統(tǒng)。目前這些協(xié)議有：SOAP即簡單對象訪問協(xié)議(Simple Object Access Protocol),它是用于 交換XML編碼信息的輕量級協(xié)議。它有三個主要方面：XML-envelope為描述信息內(nèi)容和如何處理內(nèi)容定義了框架，將程序?qū)ο缶幋a成為XML寸象的規(guī)則，執(zhí)行遠程過程調(diào)用(RPC)的約定。SOA時以運行在任何其他傳輸協(xié)議上。例如，你可 以使用SMTP即因特網(wǎng)電子郵件協(xié)議來傳遞 SOAPIf息，這可是很有誘惑力的。 在傳輸層之間的頭是不同的，但 XMLt效負載保持相同。Web Service希望實現(xiàn)不同的系統(tǒng)之間能夠用“軟件 -軟件對話”的方式

12、相互調(diào)用，打破了軟件應(yīng)用、網(wǎng)站和各種設(shè)備之間的格格不入的狀態(tài)， 實現(xiàn)“基 于Web無縫集成”的目標(biāo)。WSDL Web Service描述語言 WSDL就是用機器能閱讀的方式提供的一個 正式描述文檔而基于XML的語言，用于描述 WebService及其函數(shù)、參數(shù)和返回 值。因為是基于XMLB,所以WSD既是機器可閱讀的，又是人可閱讀的。UDDI UDDI是一套基于 Web的、分布式的、為 Web Service提供的、信Web息注冊中心的實現(xiàn)標(biāo)準(zhǔn)規(guī)范，同時也包含一組使企業(yè)能將自身提供的Service注冊，以使別的企業(yè)能夠發(fā)現(xiàn)的訪問協(xié)議的實現(xiàn)標(biāo)準(zhǔn)。5.5. JSO啦術(shù)是一種輕量級的數(shù)據(jù)交換格式。易于人閱讀和編寫。同時也易于機器解析和生成。它基于 JavaScript (Standard ECMA-262 3rd Edition - December 1999 ) 的一個子集。JSON采用完全獨立于語言的文本格式，但是也使用了類似于 C