《校外教育機構管理系統(tǒng)設計》13000字（論文）

II—緒論選題的背景與意義人類通過不斷地學習從而進化發(fā)展，從無意識地模仿到主動的總結歸納，于是人類文明的起源出現(xiàn)了。文明的成形需要積累，需要傳承，于是教育便出現(xiàn)了。教育，這個詞最早出現(xiàn)是在《孟子》，是一種引導人全面發(fā)展的社會實踐活動。在我看來，學習與教育是互相促進的，學到的知識靠教育傳承，教育出的人才進一步去研究，先賢們積累了無數(shù)寶貴的知識財富需要我們?nèi)W習，但人的精力有限，所以教育的引導就顯得尤為重要。最早在西周時期，學校被稱為“辟雍”，分為庠、序、學、校、塾，初步形成了地緣性的教育組織分布，再往后發(fā)展到西漢時期時在地方上各地有學宮，中央設有太學作為一國最高的教育機構。學府辦學最興盛的時期是唐朝，對于學校、學科的分類更細且更規(guī)范化，結合科舉制，形成了較為完備的教育選拔人才的體系。直到清末，不同于科舉教育的新式學堂出現(xiàn)，標志著中國近代教育的開始?，F(xiàn)如今，我國的教育體系已經(jīng)非常完善，幼兒園、小學、中學、大學、非學歷教育五級劃分，其中非學歷教育近年來更是蓬勃發(fā)展。人們不再滿足于學校的知識傳授，開始主動地尋求更進一步的、更專業(yè)的教育培訓，或是追求在書本知識之外的技能培訓。這種校外教育大體分為補習類、進修類、藝術類、職業(yè)技能類，而其中發(fā)展最迅速的無疑是補習類，特別是針對中小學生的課外輔導。小升初、中考、高考、就業(yè)困難，家長們對于教育競爭的焦慮感越來越強烈，對于校外教育這種額外的且針對性更強的培訓機構需求不斷變大，校外教育也相應的推出了小班化補習、一對三補習乃至一對一補習，于是在現(xiàn)今的競爭大環(huán)境下，校外教育的發(fā)展快速且蓬勃。新冠疫情的爆發(fā)，對于校外教育培訓機構來說是一次“大洗牌”。疫情期間嚴格管控，針對私企性質(zhì)的校外機構的復學控制更是嚴格，無法進行線下教學，不少機構不重視線上教育的投入或缺少相應的教學、管理經(jīng)驗，生源流失紛紛倒閉，又或是線上辦公不規(guī)范引發(fā)的員工矛盾，經(jīng)營不善，難以為繼。在這種情況下，一個優(yōu)秀的信息系統(tǒng)顯然能減少大量的溝通成本，使工作、教學更加的高效。因為曾經(jīng)在精銳教育有過實習經(jīng)歷，對于校外教育機構有一定的了解，本文將結合實習所見與大學所學設計一種信息管理系統(tǒng)。本系統(tǒng)的特點與作用簡明友好：本系統(tǒng)從架構開始一直到軟件、硬件、使用的開發(fā)語言、界面設置都是簡單明了又切實可用的，無論是對于操作人員來說還是對于維護人員來說，系統(tǒng)的難度都不高，交互體驗也是比較友好的。其次，這一特點也使得整個系統(tǒng)的成本達到了比較低的一個水平，但同時基本功能都具備，對于剛起步的教育機構來說是非常友好的。易部署、易維護：簡明的系統(tǒng)對于軟件和硬件的要求都不高，且系統(tǒng)總體以模塊化的形式組成，不涉及到特殊需求的開發(fā)，部署時就降低了實施人員的工作難度與工作量，同時也使得維護難度比較低，只需要短期培訓便可由教育機構員工自行維護，降低了維護成本。規(guī)范化：系統(tǒng)雖然簡單，但是基礎的邏輯與功能都是規(guī)范的。對于剛起步的教育機構來說，可以很好的培養(yǎng)信息化的意識。模塊化的系統(tǒng)構成使得后續(xù)增加功能更加便捷，也讓教育機構管理層在替換升級更為專業(yè)的系統(tǒng)時對于所需功能有基礎的認知與規(guī)劃。本系統(tǒng)可以使得教育機構實現(xiàn)初步的信息一體化，對于后期替換系統(tǒng)也能起到降低溝通對接成本的作用。本系統(tǒng)實現(xiàn)的目標功能目標數(shù)據(jù)相關功能：數(shù)據(jù)包括了學生信息、員工信息、課程信息、機構通告等等，系統(tǒng)可對數(shù)據(jù)進行增加、刪除、修改、查詢等操作。用戶登錄功能：用戶主要是教育機構內(nèi)部員工，通過機構分配的工號作為用戶名，自行設置密碼登錄。管理目標權限管理：在教育機構普通員工的基礎上進一步劃分出管理員角色，將權限進行隔離，增強系統(tǒng)的安全性，也使得系統(tǒng)更具規(guī)范性。信息管理：協(xié)助教育機構進行信息一體化的嘗試，讓機構各項數(shù)據(jù)的處理更加便捷，也為機構后續(xù)做大做強、替換升級更專業(yè)的ERP系統(tǒng)打下基礎。系統(tǒng)開發(fā)的需求調(diào)研調(diào)研的目的通過調(diào)研了解客戶教育機構現(xiàn)存的基礎數(shù)據(jù)的情況，確定是否有需要錄入的數(shù)據(jù)，以及確定部分數(shù)據(jù)的字段規(guī)范。對客戶教育機構現(xiàn)行的業(yè)務流程及內(nèi)部控制體系進行整理與分析，從而了解各業(yè)務環(huán)節(jié)對信息系統(tǒng)的功能需求。通過調(diào)研制訂系統(tǒng)實施中的具體業(yè)務目標。調(diào)研的內(nèi)容調(diào)研客戶教育機構的部門組織與分工，明確組織架構與部門權責。調(diào)研各業(yè)務部門的基礎數(shù)據(jù)的現(xiàn)狀，包括留存情況與留存形式。調(diào)研各業(yè)務環(huán)節(jié)的業(yè)務流程和管理制度。調(diào)研各業(yè)務部門對數(shù)據(jù)呈現(xiàn)效果的要求。調(diào)研各業(yè)務部門對系統(tǒng)應用的期望。調(diào)研的準備與方式客戶教育機構人員與數(shù)據(jù)準備：各業(yè)務部門的業(yè)務骨干或部門經(jīng)理整理好本部門的基本業(yè)務流程及相關的管理制度文本、單據(jù)和報表的樣張。調(diào)研地點與工具準備：會議室、投影儀、白板。調(diào)研的主要方式：由客戶教育機構相關人員對所提供資料的進行說明并提出需求，我方實施人員確認后進行需求分析，雙方反饋溝通，由我方實施人員編制系統(tǒng)實施業(yè)務藍圖，交客戶教育機構項目經(jīng)理確認簽字后，完成調(diào)研。需求分析組織架構圖2.1-組織架構圖經(jīng)過調(diào)查詢問并結合自身在精銳教育的實習經(jīng)歷，我總結了教育機構基礎的五大部門，實際架構見圖2.1組織架構圖。最上層的部門是總經(jīng)理室，對于創(chuàng)業(yè)型教育機構來說屬于機構所有人這一層?？偨?jīng)理室直接管理四個部門：事業(yè)部、財務部、信息部和人資部。其中根據(jù)工作側重方向，事業(yè)部又分為教職工部和銷售部，財務部分為資金部和賬務部?？偨?jīng)理室：作為第一層級管理部門，人員主要有總經(jīng)理、副總經(jīng)理和助理，負責統(tǒng)管教育機構的方向，所以經(jīng)理賬號需要管理員權限。事業(yè)部：事業(yè)部的職能主要在于機構的業(yè)務活動。其一，機構的最終的功能是教育，所以分出教職工部統(tǒng)一安排所有入職的老師，包括進行排課、排班與學生分配。其二，機構的學生來源不同于傳統(tǒng)中小學，需要專門的部門進行課程宣傳、名師宣傳、機構宣傳以及銷售方案的制定，所以分出了銷售部門專門負責。財務部：任何的組織都不可能缺少財務部，對于教育機構來說更是如此，考慮到教育機構經(jīng)常有大額的現(xiàn)金流動，所以預計進行嚴格的錢賬分離管理，分別由資金部與賬務部負責。資金部負責所有銀行賬戶的管理，負責學生學費的收取和日常機構維護開銷的繳費，同時負責聯(lián)通人資部進行工資的發(fā)放。資金部的每一筆收支都需要向財務部負責人匯報簽字，然后由賬務部職員記錄匯總，財務部負責人簽字確認后按照一定周期上報總經(jīng)理室。信息部：主要負責系統(tǒng)和部分數(shù)據(jù)的維護，讓系統(tǒng)能夠正常有效運行。同時負責輔助銷售部進行課程信息的宣傳。人資部：人資部門的職員主要需要負責對教師的招聘工作?？紤]到后期會對各部門各職員進行權限的隔離與分配，人事變動會帶來賬戶與權限的變動，所以人資部門的負責人需要次一級管理員的權限，在離職流程后負責修改相應數(shù)據(jù)。業(yè)務流程分析登錄流程系統(tǒng)最為基礎的流程就是用戶的注冊與登錄。流程涉及到用戶各項信息的錄入與檢驗，只有檢驗成功后用戶信息才會被錄入數(shù)據(jù)庫。注冊成功后才能通過與數(shù)據(jù)庫信息比對實現(xiàn)檢驗登錄。具體流程如圖2.2.1所示。數(shù)據(jù)錄入流程數(shù)據(jù)錄入流程是幾乎所有部門都會用到的功能，所以設計了一套通用的流程。首先是相關用戶在對應界面錄入數(shù)據(jù)，然后交由直接上級領導審核，審核通過后提交數(shù)據(jù)。為了數(shù)據(jù)的正確性，預計進行二次審核。因為信息推送技術限制，設置了信息部職員進行數(shù)據(jù)核驗與維護。流程實際情況展示于圖2.2.2。圖2.2.1-登錄流程圖圖2.2.2-數(shù)據(jù)錄入流程圖用戶變動流程圖2.2.3-用戶變動流程圖因為對于客戶教育機構設定的用戶群體就是機構職員，所以用戶變動流程包括入職與離職。入職流程帶來的變動與用戶注冊基本一致，所以本流程針對于離職員工的用戶變動程序。在職員提出離職并通知直屬上級領導與人資部門后，進入常規(guī)離職程序，完成對應交接等工作后，由人資部職員修改、刪除用戶相關信息，再由信息部職員進行二次審核。數(shù)據(jù)流程分析登錄流程圖2.3.1-登錄流程（數(shù)據(jù)流程圖）用戶注冊與登錄流程主要涉及到一個外部實體、兩條數(shù)據(jù)流、兩個處理過程、和一個數(shù)據(jù)存儲。數(shù)據(jù)錄入流程本流程主要是對于職員錄入的數(shù)據(jù)進行審核。其中直接上級領導的審核考慮到并非每一種數(shù)據(jù)都需要上報數(shù)級領導分別審核，結合系統(tǒng)技術實際，預計采用由直屬上級人工審核并抄送信息部職員的方式進行第一次審核。本流程數(shù)據(jù)庫并非同一數(shù)據(jù)庫而是對應不同數(shù)據(jù)的數(shù)據(jù)庫。二次復核工作則由信息部職員結合收到的抄送信息核驗系統(tǒng)中的數(shù)據(jù)，必要時進行維護動作。用戶變動流程用戶變動的數(shù)據(jù)流程涉及到的數(shù)據(jù)庫與用戶在注冊和登錄時訪問的數(shù)據(jù)庫是同一個，審核與復核的設計和原因與數(shù)據(jù)錄入流程一致。圖2.3.2-數(shù)據(jù)錄入流程（數(shù)據(jù)流程圖）圖2.3.3-用戶變動流程（數(shù)據(jù)流程圖）數(shù)據(jù)字典表2.4.1-數(shù)據(jù)存儲卡片（D1）數(shù)據(jù)存儲卡片總編號：001名稱用戶信息數(shù)據(jù)庫編號D1簡述D1存儲所有用戶的注冊信息來源P1.1（F1.1）去向P1.2（F1.1）、P3.5（F3.2）構成用戶編號+用戶名稱+用戶賬號+用戶密碼+用戶身份信息（部門、職位）備注本系統(tǒng)的設計中用戶等同于職員表2.4.2-數(shù)據(jù)存儲卡片（D2）數(shù)據(jù)存儲卡片總編號：002名稱各錄入信息數(shù)據(jù)庫編號D2簡述D2存儲職員錄入的各種信息來源P2.2（F2.3）、P2.4（F2.4）去向P2.3（F2.3）構成通知、新聞資訊、課表、班表……備注在設計中為了便于描述流程將不同數(shù)據(jù)庫統(tǒng)合到了一起，實際流程中存在各數(shù)據(jù)對應的數(shù)據(jù)庫表2.4.3-數(shù)據(jù)流卡片（F1.1；F1.2）數(shù)據(jù)流卡片總編號：003名稱用戶信息；審核不通過的用戶信息編號F1.1、F1.2簡述用戶注冊時存檔的相關信息；用戶注冊時系統(tǒng)自動審核判斷不通過的用戶信息來源P1.1；P1.1去向用戶（職員）；P1.2構成用戶名稱+用戶賬號+用戶密碼+用戶身份信息（部門、職位）備注本系統(tǒng)中用戶即職員表2.4.4-數(shù)據(jù)流卡片（F2.1；F2.2）數(shù)據(jù)流卡片總編號：004名稱被錄入數(shù)據(jù)；審核不通過的被錄入數(shù)據(jù)編號F2.1；F2.2簡述職員在正常業(yè)務活動中使用系統(tǒng)時錄入的數(shù)據(jù)；人工審核駁回的被錄入的數(shù)據(jù)來源職員；P2.2去向P2.1、P2.2；P2.1構成通知、新聞資訊、課表、班表……備注F2.3審核被通過的被錄入數(shù)據(jù)與相對應的F2.1相同表2.4.5-數(shù)據(jù)流卡片（F2.4）數(shù)據(jù)流卡片總編號：005名稱復核修改后的被錄入數(shù)據(jù)編號F2.4簡述由信息部職員復核修改后的被錄入的數(shù)據(jù)來源P2.3去向D2構成與F2.1、F2.2、F2.3相同備注與F2.1、F2.2、F2.3具體數(shù)據(jù)不同表2.4.6-數(shù)據(jù)流卡片（F3.1）數(shù)據(jù)流卡片總編號：006名稱離職信息編號F3.1簡述職員提出離職相關的信息（離職時間、原因等）來源P3.1去向P3.2、P3.3、P3.4構成離職人員基本信息（姓名、職位等）+離職原因+離職時間備注無表2.4.7-數(shù)據(jù)流卡片（F3.2；F3.3）數(shù)據(jù)流卡片總編號：007名稱離職職員用戶信息；復核修改后的用戶信息編號F3.2；F3.3簡述用于修改用戶信息數(shù)據(jù)庫D1的數(shù)據(jù)來源P3.4；P3.5去向D1、P3.5；D1構成與用戶信息相等備注在本系統(tǒng)的設計中這兩條數(shù)據(jù)流應當用于刪除離職員工系統(tǒng)用戶信息表2.4.8-處理過程卡片（P1.1）處理過程卡片總編號：008名稱用戶注冊編號P1.1參與人職員去向D1處理說明登記用戶注冊信息，系統(tǒng)自動審核通過后錄入數(shù)據(jù)庫D1，反之打回備注無表2.4.9-處理過程卡片（P1.2）處理過程卡片總編號：009名稱用戶登錄編號P1.2參與人職員去向無處理說明系統(tǒng)通過校驗職員填寫數(shù)據(jù)與D1中留存數(shù)據(jù)，一致則允許登陸，反之登錄失敗備注無表2.4.10-處理過程卡片（P2.1）處理過程卡片總編號：010名稱數(shù)據(jù)錄入編號P2.1參與人各部門職員去向P2.2、D2處理說明不同部門職員按照系統(tǒng)預設錄入業(yè)務數(shù)據(jù)備注無表2.4.11-處理過程卡片（P2.2）處理過程卡片總編號：011名稱直接上級審核編號P2.2參與人各級領導去向D2、P2.1處理說明由各職員直接上級領導進行線下人工審核備注無表2.4.12-處理過程卡片（P2.3；P3.5）處理過程卡片總編號：012名稱信息部復核編號P2.3；P3.5參與人信息部職員去向D2；D1處理說明由信息部職員在數(shù)據(jù)錄入數(shù)據(jù)庫后再進行二次線上復核，P2.3主要是對已經(jīng)錄入的數(shù)據(jù)排錯，P3.5主要針對刪除已離職員工的系統(tǒng)用戶信息備注無表2.4.13-處理過程卡片（P3.1）處理過程卡片總編號：013名稱提出離職編號P3.1參與人將離職員工去向P3.2、P3.3處理說明想要離職的員工按照勞動合同要求提前以書面形式提出離職，同時通知到直屬領導與人資部備注無表2.4.14-處理過程卡片（P3.2；P3.3）處理過程卡片總編號：014名稱通知相關人員編號P3.2；P3.3參與人將離職員工、該員工直接上級、人資部專員去向P3.4處理說明將離職意愿通知直接上級領導；通知人資部對應專員備注處理過程一致，但實際處理順序為先通知直接上級再通知人資部表2.4.15-處理過程卡片（P3.4）處理過程卡片總編號：015名稱人資職員修改用戶信息編號P3.4參與人人資部職員去向D1處理說明人資部專員在收到確認離職信息后，將離職員工的系統(tǒng)用戶信息進行刪除處理備注無表2.4.16-數(shù)據(jù)項卡片數(shù)據(jù)項卡片總編號：016名稱用戶賬號；用戶密碼簡述用于職員登錄系統(tǒng)的憑證具體要求賬號由公司分配的工號為準，密碼自行設置最多不超過18位備注由職員注冊時錄入系統(tǒng)，可通過對應權限人員修改數(shù)據(jù)庫修改可行性分析經(jīng)濟可行性本系統(tǒng)在設計之初就在追求簡明、友好的系統(tǒng)特性，對于實際部署過程中的成本有意識地進行一定的控制，因為使用的B/S架構，所以無論硬件還是軟件要求都不高，加上系統(tǒng)設計之初就選定目標群體為剛起步的校外教育機構，數(shù)據(jù)體量相對較小，權衡之下暫時不需要配置專業(yè)的服務器，通過尋找代理商或使用普通高性能電腦也可滿足實際運行。加上實際實施部署不涉及高難度的開發(fā)，實施人員易于培訓，客戶教育機構也不需要招聘專業(yè)開發(fā)人員即可完成日常維護，使得實際成本相比較低、經(jīng)濟可行。技術可行性目前對于教育相關信息管理系統(tǒng)的研究早已成熟，特別是在最基礎功能的實現(xiàn)層面，相關技術易于獲得學習，且有成熟的系統(tǒng)架構可以借鑒。系統(tǒng)使用B/S架構，涉及到的軟件都較為基礎，軟件購買成本低的同時，實際操作難度也低，對于實施人員的要求不高，需要擁有JAVA基礎、有一定網(wǎng)頁設計經(jīng)驗即可，以作者個人而言，經(jīng)過大學四年專業(yè)教育完全可以實現(xiàn)基礎的系統(tǒng)，對于進一步的功能實現(xiàn)再通過學習與培訓也可以滿足開發(fā)前提，總體評估下技術可行。組織管理可行性本系統(tǒng)設計面向剛起步的校外教育機構，這種機構相對來說組織架構尚未成形，可塑性強，系統(tǒng)化思維下的組織結構設計可以幫助機構更好的實現(xiàn)管理與機構信息一體化。同時較為規(guī)范的組織架構也便于機構后續(xù)發(fā)展壯大時更換專業(yè)ERP系統(tǒng)，進一步減少對接成本與升級難度。其次，系統(tǒng)的操作與維護難度比較低，實際培訓簡單，可以暫時減少專業(yè)開發(fā)人員的招聘，更合理的進行人力資源管理，綜合評估組織管理可行。系統(tǒng)設計系統(tǒng)總體設計架構設計系統(tǒng)架構的選擇可以從兩方面入手，其一是系統(tǒng)運行時的程序結構，另一個是開發(fā)系統(tǒng)時源代碼的組織結構。對于整個系統(tǒng)來說，第一是要符合客戶的需求。能否正確的、完整的實現(xiàn)客戶提出的需求，功能性的需求能否開發(fā)落地，以及非功能性的需求層面能否使客戶滿意。第二，總體的性能情況。主要有：對于內(nèi)存的管理、數(shù)據(jù)庫的設計組織和非數(shù)據(jù)庫信息、并發(fā)數(shù)的允許情況、不同接口是否影響性能。特別值得關注的是并發(fā)問題，系統(tǒng)最大可以支持多少用戶同時操作，實際并發(fā)數(shù)的增加會不會引發(fā)系統(tǒng)宕機、頻繁掉線等情況的出現(xiàn)，掉線情況出現(xiàn)時會不會導致數(shù)據(jù)丟失與損壞。第三，系統(tǒng)運行時的可管理性。系統(tǒng)的日志記錄是否正常，是否便于輔助維護人員監(jiān)控系統(tǒng)的狀態(tài)。系統(tǒng)是否存在錯誤的自處理功能，對于無法自處理的錯誤能否及時獲得錯誤信息以便于維護人員排除問題。模塊與模塊之間關系是否簡單便于通信。第四，關于接口。從硬件和軟件兩方面看，首先與網(wǎng)絡、打印機等硬件的接口是否兼容，聯(lián)通接口會不會影響系統(tǒng)運行效率。其次，當前系統(tǒng)所使用接口是否合法，與其他系統(tǒng)兼容還是沖突。第五，關于系統(tǒng)的安全性與可靠性。對于客戶來說，除了需求外最重要的就是安全性與可靠性。常規(guī)系統(tǒng)運行能否穩(wěn)定持久，有沒有基礎的防入侵能力。除此以外，還需要考慮到特殊情況的應對。對于災難的預防是否到位，小到停電斷網(wǎng)，大到自然災害，系統(tǒng)能否保護數(shù)據(jù)甚至穩(wěn)定運行。系統(tǒng)能否使用雙機熱備等方式達到應對災難的效果。相對的，有災難應對也要有災后重建。當災難中系統(tǒng)出現(xiàn)停止運行甚至硬件損壞情況時，能否在災后快速重新部署投入使用。第六，系統(tǒng)的使用是否便捷。相關的業(yè)務流程、業(yè)務信息是否能夠通過特定方式隨時進行調(diào)整。信息的調(diào)整會影響那些功能，是否會導致進行中的流程出錯。相關的調(diào)整能否被清晰展示給使用者或特定用戶。第七，構架樣式的一致性。整個系統(tǒng)構架需要時刻保持一致，包括命名風格、編碼習慣、頁面布局等。保持一致可以更方便后來的開發(fā)、維護人員理解系統(tǒng)，也能夠給客戶留下更深的印象，便于形成風格、形成品牌。從源代碼的角度看問題，首先一定是開發(fā)是否易于管理。第一，是否便于分工。特別是對于系統(tǒng)的模塊劃分，一定要追求模塊之間的高度內(nèi)聚，減少相關耦合，模塊化的去分工、去開發(fā)，考慮到實際情況甚至可以進一步組件化，使得系統(tǒng)部署進度更加可控，也使得開發(fā)人員流動導致的風險降到最低。細分下的功能模塊、組件在大幅加強可管理性的同時，也使得系統(tǒng)出現(xiàn)問題時可以更快且影響更小的定位錯誤、排除錯誤。第二，系統(tǒng)的發(fā)展性。首先是系統(tǒng)需要易于維護。對于故障的定位排除與其所在局部的修改。其次便是系統(tǒng)的升級擴展。結合系統(tǒng)的運行時間預估，需要考慮系統(tǒng)硬件升級的難度以及是否會影響系統(tǒng)性能。同時系統(tǒng)構架修改、擴充的可行性是否足夠。最后，要考慮代碼語言層面是否足夠標準與開放。不同客戶對于瀏覽器、客戶端等的使用有著不同的偏好，所以要考慮架構是否便于移植到不同的環(huán)境中。第三，源代碼也需要考慮是否能夠滿足客戶需求的變化。部分方法是否需要封裝，相關信息是否注釋清晰，代碼總體組成是否留下了修改的余地。本系統(tǒng)在設計之初就定下了目標群體，所以對于本系統(tǒng)來說架構一定要滿足以上所說的十個特點。因為設計基調(diào)在于簡明、友好，同時考慮到技術能力的局限，所以，最終決定了采用B/S應用架構作為總的框架。根據(jù)圖可以清晰地了解該架構大致情況。系統(tǒng)的整體是存放在Web服務器上的，包括頁面的設置、各種請求的處理邏輯、頁面設計素材等，而系統(tǒng)的數(shù)據(jù)主要存放在額外的數(shù)據(jù)庫中，包括用戶信息，錄入的數(shù)據(jù)、操作日志等。作為系統(tǒng)的使用者，用戶不需要下載客戶端、系統(tǒng)整體和所有數(shù)據(jù)庫，而只需要Web服務器開通外網(wǎng)，就可以在自己的設備上通過訪問固定的網(wǎng)址，直接連接系統(tǒng)，再通過注冊、登錄操作就可以進行操作。圖-B/S架構圖設計原則簡明友好：與系統(tǒng)設計初定下的系統(tǒng)特點一致。大概分為兩個方面，一是代碼設計，二是交互體驗。代碼方面盡量注釋清晰，特別是涉及到封裝時，除了注釋還要考慮到后續(xù)修改是否留有余地。而關于交互體驗這一層面，也是需要重點關注的。需求滿足不代表能使客戶滿意，操作是否簡單、提示是否完善、功能是否易于理解、界面展示是否美觀大氣、賞心悅目，都是影響客戶滿意度的重要指標。本系統(tǒng)設計的競爭優(yōu)勢在于成本低但基礎功能完備，具有協(xié)助客戶進行信息一體化建設的規(guī)范性。因此本系統(tǒng)的缺點也十分明顯，功能過于基礎，實際系統(tǒng)使用過程中帶來的效率提升可能并不明顯，同時技術局限導致一些處理邏輯比較復雜、原始。所以為了彌補這一方面的缺陷，設計過程中要盡量簡約，給客戶一種更輕松的交互感受。發(fā)展性原則：本系統(tǒng)功能雖然比較少且極為基礎，但設計開發(fā)過程中預留了相當大的擴展空間，包括新模塊的設計與引用、舊模塊的升級、原算法的優(yōu)化等。由此進一步可以表現(xiàn)本系統(tǒng)的另一競爭優(yōu)勢。在原架構之上升級是有極限的，雖然隨著研究學習的深入，技術局限會被不斷破除，但是當體量達到一定程度時就需要替換更為專業(yè)的信息管理系統(tǒng)，就比如金蝶、用友等公司的主力云平臺產(chǎn)品。而本系統(tǒng)作為過度系統(tǒng)，對數(shù)據(jù)進行規(guī)范化處理，一定程度上幫助客戶組織架構進行合理規(guī)劃，在后續(xù)升級中既能減少溝通對接的實施成本，也能使得機構員工快速適應新系統(tǒng)邏輯，使得新系統(tǒng)快速的進入產(chǎn)生價值的狀態(tài)?；A性原則：本系統(tǒng)在設計時選擇最為基礎的硬件配置和最容易上手的軟件組成，配合標準、開放的開發(fā)語言，使得在實際部署時可以根據(jù)客戶實際情況進行軟硬件的選擇，讓成本與性能能夠更精準的滿足每一位客戶的需求。系統(tǒng)功能概要設計系統(tǒng)用戶模塊本系統(tǒng)的用戶即為客戶教育機構的職員，所有職員在入職后，確定了工作相關信息，包括部門、職位、工號等信息后開始訪問系統(tǒng)注冊用戶。以工號作為賬號，自行設置密碼，注冊成功后，即可通過賬號密碼登入系統(tǒng)進行相關操作。數(shù)據(jù)模塊各部門職員都有不同的數(shù)據(jù)需要錄入，像教職工部員工錄入課表和排班表、信息部職員錄入新聞資訊等，但是實際流程一致，所有職員錄入的數(shù)據(jù)在提交前，都需要交由直接上級進行線下人工初審，審核通過后再提交錄入系統(tǒng)數(shù)據(jù)庫中，最后由信息部對應專員負責定期根據(jù)審核情況對查詢到的數(shù)據(jù)進行復查，復核不通過的進行修改乃至刪除操作。數(shù)據(jù)發(fā)布人自行發(fā)現(xiàn)錯誤但無權限修改時，也可再請示直接上級，通知信息部專員立刻修改。代碼設計表3.3.1工號編碼卡片編碼對象職員工號代碼種類層次碼代碼結構所屬部門入職年份順序號01210001代碼說明代碼整體由三段組成，通過“-”間隔每個部門擁有唯一的識別碼（如總經(jīng)辦01，事業(yè)部02）年份取入職年份后兩位（如2021就取21）四位流水碼，以年份為隔離，同一年份按入職先后順序獲得流水碼例：事業(yè)部2021年第一位入職的職員的工號為02-21-0001總經(jīng)辦2021年第三位入職的職員的工號為01-21-0003事業(yè)部2022年第一位入職的職員的工號為02-22-0001數(shù)據(jù)庫設計本系統(tǒng)所使用的數(shù)據(jù)庫中設計到的表主要有：用戶表，新聞（公告）表，排課表。表3.4.1-用戶表字段名數(shù)據(jù)類型字段長度空值自動增加主鍵用戶編號整數(shù)型10不允許是是用戶名字符型45不允許否否用戶密碼字符型45不允許否否表3.4.2-新聞（公告）表字段名數(shù)據(jù)類型字段長度空值自動增加主鍵編號整數(shù)型10不允許是是標題字符型45不允許否否時間日期&時間無限制不允許否否內(nèi)容長文本無限制不允許否否表3.4.3-排課表字段名數(shù)據(jù)類型字段長度空值自動增加主鍵編號整數(shù)型10不允許是是課程名字符型45不允許否否授課時間日期&時間無限制不允許否否授課老師字符型45不允許否否系統(tǒng)實現(xiàn)系統(tǒng)主頁圖4.1.1展示的就是系統(tǒng)的首頁，當用戶通過指定地址在瀏覽器訪問時顯示的界面就是如此。用戶注冊新入職員工需要注冊用戶，點擊首頁“登錄”欄中的“注冊”按鈕，瀏覽器會出現(xiàn)一個新頁簽如圖4.2.1所示即為注冊界面。職員通過錄入用戶名（工號）、密碼、確認密碼，再點擊“提交”即可完成注冊。點擊“提交”按鈕之后提交成功會清空所有所填項，當密碼不一致或存在空值時會提交失敗并觸發(fā)相應的提示，如圖4.2.2、圖4.2.3、圖4.2.4、圖4.2.5所示。用戶登錄職員在注冊過用戶之后，在注冊頁面點擊“返回”按鈕可以回到首頁，通過首頁“登錄”欄就可以登入系統(tǒng)。在輸入用戶名、密碼后，系統(tǒng)會進行一次判斷，用戶名、密碼與數(shù)據(jù)庫中相符合時可以登錄，不相符時清空所有所填數(shù)據(jù)。圖4.1.1-首頁圖4.2.1-注冊頁面圖4.2.2-用戶名為空時圖4.2.3-密碼為空時圖4.2.4-確認密碼為空時圖4.2.5-兩次密碼輸入不一致時數(shù)據(jù)查詢(以新聞為例)在職員登入系統(tǒng)之后，通過點擊左側導航欄“新聞列表”，新聞數(shù)據(jù)會在右側主頁面顯示。圖4.4.1-查詢數(shù)據(jù)錄入點擊圖4.4.1中的“新建”，主頁面就會跳轉到新聞新增發(fā)布界面，即錄入數(shù)據(jù)界面，完成錄入后點擊“提交”，數(shù)據(jù)就錄入數(shù)據(jù)庫了，點擊“返回”回到查詢界面。圖4.5.1-錄入數(shù)據(jù)修改修改界面與錄入界面一致，在查詢界面點擊對應數(shù)據(jù)所在行的修改圖標，主頁面就會跳轉到所需修改的數(shù)據(jù)的詳情頁，修改后點擊“提交”就完成了修改，再點擊“返回”回到列表界面。數(shù)據(jù)刪除在數(shù)據(jù)查詢界面如圖4.4.1新聞列表，選中要刪除的數(shù)據(jù)，點擊右側刪除即可刪除數(shù)據(jù)，選擇復數(shù)條數(shù)據(jù)時，點擊右上角“刪除”就可以完成批量刪除動作。系統(tǒng)測試與使用說明測試安排與測試方法代碼測試對于源代碼的測試是貫穿整個系統(tǒng)搭建過程全程的，每個方法編寫完成時進行一次測試，看在瀏覽器中運行是否達到預期效果。其次當一個頁面完成編寫時進行一次該頁面所有方法的檢驗，看不同的方法之間會不會互相影響而導致某一方法失效，其次完成一個功能模塊時進行一次全功能測試，檢驗不同的方法能否在同一模塊下平穩(wěn)有效運行。最后，當完成整個系統(tǒng)的搭建時，進行更隨機的測試：一項一項功能依次測試，不同模塊功能穿插測試，正確操作與錯誤行為穿插測試（主要針對注冊與登錄模塊）。通過這些隨機性極大的測試檢驗系統(tǒng)是否存在一些未知的錯誤。對于源代碼還有一項重要工作就是注釋的編寫，對于編寫的各種方法留下思路、用意、原理方面的注釋，既是為了方便自己后續(xù)測試時及時發(fā)現(xiàn)問題所在，也是為了系統(tǒng)在后期維護升級時更加容易被開發(fā)人員理解，降低交接難度，增強系統(tǒng)的可維護性。功能測試功能的測試主要在特定方法的源代碼編寫完成后進行。測試的時點與源代碼測試類似，但相較于源代碼關注功能是否正常實現(xiàn)更注重功能能否滿足需求。用戶注冊功能，嘗試大小寫是否會影響用戶名、密碼的一致性，嘗試特殊字符對于密碼的影響，嘗試是否能夠進行重復注冊同一用戶。用戶登錄功能，除了大小寫、特殊字符的登錄測試外，測試失敗次數(shù)是否影響登錄，測試同一用戶是否可以并發(fā)登錄，測試同一瀏覽器能否并發(fā)登錄，測試不同瀏覽器是不是可以同用戶并發(fā)登錄。數(shù)據(jù)相關功能。測試新增錄入數(shù)據(jù)時，同樣的數(shù)據(jù)能否多次錄入以及多次錄入對數(shù)據(jù)庫與列表頁的影響。測試修改數(shù)據(jù)時，嘗試將選中數(shù)據(jù)相關信息完全刪除，檢驗這種修改帶來的影響，并將此方法修改效果與刪除數(shù)據(jù)作比較。數(shù)據(jù)刪除時，重點嘗試不同數(shù)據(jù)量情況下，全部刪除是否正常運行，是否會對數(shù)據(jù)庫產(chǎn)生預料外的影響。同時測試隨機錄入、修改、刪除操作下對于數(shù)據(jù)各字段是否有影響，特別是主鍵編號字段。環(huán)境測試環(huán)境測試首先是硬件環(huán)境的測試。此測試主要針對服務器硬件的配置。主要在筆記本電腦進行測試。筆記本電腦的基礎配置為：酷睿i7的處理器，8G的自帶運存，250G的存儲空間，64位操作系統(tǒng)，windows版本為win10教育版。然后更換配置更低的筆記本電腦：酷睿i5的處理器，4G運行內(nèi)存，100G的存儲空間，64位操作系統(tǒng)，win7旗艦版系統(tǒng)。對比不同硬件條件下服務器運行差異。具體測試包括：多用戶并行、單用戶并發(fā)對系統(tǒng)的影響，單次操作的數(shù)據(jù)量巨大時對系統(tǒng)運行的影響（主要是極長文本數(shù)據(jù)的單次錄入和對大量數(shù)據(jù)的批量刪除操作進行測試，觀察操作是否成功有效與系統(tǒng)的響應速度）。其次是軟件的測試。本系統(tǒng)涉及的軟件有adobe的Dreamweaver、NetBeansIDE8.2和MySQL數(shù)據(jù)庫，主要使用的瀏覽器為電腦自帶的IE瀏覽器。再不更改搭建軟件的情況，使用不同的瀏覽器進行系統(tǒng)登入操作，如360瀏覽器、谷歌瀏覽器、火狐瀏覽器、Edge瀏覽器等。重點測試不同瀏覽器下，JSP方法與控件是否能夠正常使用，測試不同瀏覽器功能是否正常，測試不同瀏覽器顯示是否正常。測試用例針對系統(tǒng)功能總計有兩套測試用例。表5.2.1-用戶注冊與登錄測試用例表用例編號簡述預計測試結果1用戶名或密碼/確認密碼有一為空注冊界面提示“用戶名（密碼/確認密碼）不能為空”登錄界面登錄失敗留在主頁且清空錯誤信息2（注冊）密碼與確認密碼不一致提示“兩次輸入的密碼不一致”3用戶名對應的密碼大小寫進行變化注冊界面提示“兩次輸入的密碼不一致”登錄界面登錄失敗4密碼長度超過18位提示“密碼過長”(密碼文本框最長字符為18)5同一用戶并發(fā)登錄成功登錄且可正常操作系統(tǒng)6不同用戶同時登錄操作成功登錄且可正常操作表5.2.2-數(shù)據(jù)測試用例表用例編號簡述預計測試結果1相同數(shù)據(jù)重復錄入成功錄入但每條數(shù)據(jù)自動生成的編號不同2修改時刪除所有數(shù)據(jù)信息修改后點擊“提交”提示內(nèi)容不能為空測試結果注冊測試注冊界面填寫信息時的檢驗空值方法運行正常，密碼一致性檢查運行正常，密碼特殊取值檢驗正常（大小寫變化與特殊字符），與測試用例預計結果一致。但是注冊數(shù)據(jù)未能成功進入數(shù)據(jù)庫，推測對應JAVA方法存在錯誤。登錄測試登錄界面測試用例測試結果和預期相符，同時驗證了同一用戶并發(fā)登錄與不同用戶同時登錄皆可行。同一用戶可并發(fā)登錄與預期一致，但是屬于系統(tǒng)問題，實際運行過程中應該控制為同一用戶同一時間僅可登錄一個賬號（包括不同瀏覽器）。數(shù)據(jù)相關測試測試用例的實際運行情況符合預期。環(huán)境測試硬件測試結果如同預期，硬件的性能很大程度上影響系統(tǒng)的運行性能。單次大量數(shù)據(jù)的操作在不同硬件環(huán)境下執(zhí)行成功但響應效率不同，高性能硬件響應速度的明顯更快。軟件測試的結果比較超出預計。在自帶IE瀏覽器下，系統(tǒng)顯示與相應功能完全正常，但是在更換瀏覽器時發(fā)現(xiàn)功能雖然正常但顯示出現(xiàn)了問題，如在Edge瀏覽器中出現(xiàn)網(wǎng)頁的框架貼合異常。推測原因其一瀏覽器不兼容，其二框架設置存在錯誤。使用說明系統(tǒng)的部署需要至少一臺點腦。配置要求：64位操作系統(tǒng)，win7及以上系統(tǒng)版本，電腦的運行內(nèi)存至少要4G，可用存儲空間至少要50G。軟件要求：Dreamweaver、NetBeansIDE8.2和MySQL數(shù)據(jù)庫。用戶注冊功能暫時異常但不影響使用，通過將用戶賬號、密碼錄入數(shù)據(jù)庫可通過登錄頁面正常登入系統(tǒng)進行相關操作?？偨Y系統(tǒng)仍存在的問題系統(tǒng)的界面設置上仍有不同，簡單明了但并不美觀。部分按鈕的設置邏輯存在一定的問題。用戶注冊問題尚未解決，雖然仍可以使用，但從安全性的角度來看，存在較大的風險，且對于系統(tǒng)界面功能的展示產(chǎn)生了一定的影響。系統(tǒng)的局限性與改進方向在系統(tǒng)整體運行測試后，發(fā)現(xiàn)不少問題但就系統(tǒng)總體來說，已經(jīng)是一個可以正常運行的基礎信息管理系統(tǒng)。本系統(tǒng)的局限性主要在兩方面，技術的局限性與眼界的局限性。技術層面上，首先就是注冊功能的實現(xiàn)失敗，校驗功能正常但在數(shù)據(jù)發(fā)送至數(shù)據(jù)庫這一行動時出現(xiàn)了問題，經(jīng)過復查后，進一步確定原因在于JAVA文件代碼與對應Servlet代碼存在邏輯錯誤。其次，是數(shù)據(jù)匯總、分析功能的缺失，對于校外教育機構來說，數(shù)據(jù)的分析還是很重要的，不僅展示了職員個人能力，也可以通過銷售數(shù)據(jù)輔助管理層決策課程改革與銷售策略更新。還有一個很明顯的功能缺失在于權限隔離，對于不同用戶授予不同的操作權限、訪問權限，比較粗糙的解決辦法在于針對不同權限用戶開發(fā)不同的登錄頁面以及登錄后訪問的主頁，但是這種辦法工作量巨大，不具備普適性，且架構層面上來說，結構復雜、多余，不易于維護。最后的技術局限在于網(wǎng)絡控制。本系統(tǒng)的運行暫時只能通過本機瀏覽器訪問，外網(wǎng)映射與接口功能這一塊無法實現(xiàn)。眼界層次首先在于系統(tǒng)架構的規(guī)劃，B/S架構基礎，但是并不能完全適應當下各種需求的實現(xiàn)，針對不同的客戶需求應當用合適的架構，單一的B/S架構不夠靈活。對于模塊的劃分也存在局限，對于基礎功能不夠了解，設計的系統(tǒng)實際運行效率可能還比不了人工進行來的快捷。最后對于系統(tǒng)應該提供給客戶的幫助認識不夠清晰，所以在功能邏輯的設計上存在一定的問題，同時項目經(jīng)驗與閱歷的缺少也使得自身對于UI設計沒有一套友好且有特色的設計方案。參考文獻:[1]丁勇,黃海軍.系統(tǒng)架構設計考慮[J].辦公自動化,2010(14):28-31.[2]金晶.基于ASP.NET的學生信息管理系統(tǒng)的設計分析[J].衛(wèi)星電視與寬帶多媒體,2020(02):21-22.[3]谷利國,陳存田,張甲瑞.基于B/S模式的人事教育信息管理系統(tǒng)的分析與設計[J].電腦知識與技術,2019,15(10):58-59.[4]徐志凱,金子堅,田艷.通用任務管理系統(tǒng)分析與設計[J].軟件工程,2020,23(04):37-39.[5]段輝良.網(wǎng)絡教育管理信息系統(tǒng)的研究與實現(xiàn)[D].中南大學,20