| 這個作業屬于哪個課程 | 2020春S班 |
|---|---|
| 這個作業要求在哪裡 | 團隊作業第二次 |
| 團隊名稱 | 學長幫幫組 |
| 這個作業的目标 | 完成口罩預約系統的GUI界面和基礎功能 |
| 作業正文 | 團隊作業第二次——團隊Github實戰訓練 |
| 其他參考文獻 | Python官網、Flask使用指南等 |
Part One
組員職責分工
- 前端：曾宏健、陳志達、鄭小華
- 後端：何翺翔
- 文檔：沈明炜、林琳、鄭小華
- 群内截圖：林琳
- 部落格：李康華、鄭小華、王玉珊
思維導圖
GitHub送出日志截圖
- 截圖
- commit次數統計
| 學号 | commit次數 |
|---|---|
| 221701423 | 9 |
| 221701222 | 10 |
| 221701203 | 4 |
| 041701407 | |
| 221701305 | 3 |
| 221701121 | 2 |
| 221701404 | |
| 221600423 | |
| 221701320 |
程式運作截圖
程式運作環境
- windows+python+flask
alembic==1.0.11 blinker==1.4 certifi==2019.6.16 Click==7.0 cssmin==0.2.0 Flask==1.1.1 Flask-DebugToolbar==0.10.1 Flask-SQLAlchemy==2.4.0 itsdangerous==1.1.0 Jinja2==2.10.1 jsmin==2.2.2 Mako==1.1.0 MarkupSafe==1.1.1 public==2019.4.13 python-dateutil==2.8.0 python-dotenv==0.10.3 python-editor==1.0.4 python-http-client==3.1.0 SQLAlchemy==1.3.7 timedelta==2019.4.13 virtualenv==16.7.4 virtualenv-clone==0.5.3 webassets==0.12.1 Werkzeug==0.15.5 wrapt==1.12.0 Flask-Cors==3.0.8
GUI界面
基礎功能實作
- 實作了一個市民便捷預約、限量采購口罩的應用，市民可在網上登記資訊預約口罩。系統采用web服務的方式，前後端分離實作。
| 功能點 | 完成度 | 具體情況 |
|---|---|---|
| 身份證、手機号格式驗證及錯誤提示 | 為便于測試并沒有進行測試 | |
| 身份證、手機号的唯一性及錯誤提示 | 1 | |
| 間隔三次才能預約及錯誤提示 | 條件僅僅是進行了單一身份驗證 | |
| 存儲預約資訊 | ||
| 預約結束後的中簽計算 | ||
| 預約查詢及提示 |
工具：HTML/CSS，JavaScript，Python，Flask
附加功能實作
暫無，還在努力中。
新功能
使用者體驗
- 系統功能針對性強，在疫情期間為市民提供了便利，使用者打開網頁即可使用我們的口罩預約服務，使用者在首頁面上選擇不同的功能跳轉到相應的頁面擷取相關服務。
- 在使用預約服務時，使用者需要在網頁上完善相關資訊，包括姓名、電話、身份證号以及購買口罩數量進行登記，預約成功時将給出預約編号，若手機号及身份證号在本次登記過或在此前3次預約成功過，則彈出預約失敗資訊。
- 在使用查詢服務時，使用者需要在網頁上填寫預約編号，點選查詢則可以生成購買憑證，包括姓名、電話号、身份證号、數量等資訊。
- 開始預約按鈕和結束預約按鈕為友善測試所添加的，點選開始預約則可以開始新一輪的口罩預約服務，點選結束預約，則結束目前的口罩預約服務，不可再進行口罩預約操作。
遇到的困難及解決方法
- 曾宏健：困難：跨域問題 解決方案：使用flask_cors庫，并設定origins:*
- 陳志達：困難：前端各元件的整合部署 解決方案：利用css，百度設定
- 鄭小華：主要負責基礎前端的建構和文檔的編寫，暫無遇到困難。
- 沈明炜：困難：接口文檔的編寫 解決方案：百度，觀看執行個體。
- 李康華：
- 何翺翔：
- 王玉珊：協助撰寫部落格，沒有遇到困難。
- 林琳：困難：之前沒有接觸過Flask，雖然已經在學習了，但是感覺應用還是不太熟練 解決：繼續學習Flask相關知識
- 林轶凡:
組員貢獻比例
| 貢獻度 | |
|---|---|
| 14 | |
| 13 | |
| 8 |
組員PSP表格
- 曾宏健：
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | ||
| Estimate | 估計這個任務需要多少時間 | ||
| Development | 開發 | 310 | |
| Analysis | 需求分析 (包括學習新技術) | 20 | |
| Design Spec | 生成設計文檔 | 30 | |
| Design Review | 設計複審 | ||
| Coding Standard | 代碼規範 (為目前的開發制定合适的規範) | ||
| Design | 具體設計 | ||
| Coding | 具體編碼 | 120 | |
| Code Review | 代碼複審 | ||
| Test | 測試（自我測試，修改代碼，送出修改） | 40 | |
| Reporting | 報告 | 45 | |
| Test Report | 測試報告 | ||
| Size Measurement | 計算工作量 | 5 | |
| Postmortem & Process Improvement Plan | 事後總結, 并提出過程改進計劃 | ||
| 合計 | 375 |
- 陳志達：
| 150 | |||
| 100 | |||
| 15 | |||
| 675 | 745 |
- 鄭小華：
| 60 | |||
| 265 | 300 | ||
| 80 | |||
| 50 | |||
| 25 | |||
| 460 | 395 |
- 沈明炜：
| 90 | |||
| 860 | 560 |
| 390 | 430 | ||
| 70 | |||
| 480 | 520 |
| 200 | |||
| 950 | 900 |
- 王玉珊：
| 35 | |||
| 580 | 590 |
- 林琳：
| 55 | |||
| 485 |
Part Two
團隊展示——問題重解
1.面向什麼使用者
願意輔導的同學和需要被輔導的同學都是我們程式面向的使用者人群
2.輔導是如何結對的
被輔導人員搜尋科目/姓名，挑選好輔導人員後可線上進行聯系，确定輔導時間和費用後完成結對
3.輔導人員的要求
程式将通過福大教務處的認證頁面确認輔導人員的績點，績點符合要求則可以開始輔導
4.APP是否收費
目前沒有收費的打算，但是因為資訊收集的成本，後期考慮讨論再做決定
5.如何進行知識的對接
輔導人員釋出自己擅長的，可進行輔導的科目，被輔導人員搜尋到自己需要的科目，選擇适合自己的輔導人員進行輔導，完成知識對接
6.中介平台在使用者自行結對之後會被使用者遺棄，平台很難追蹤使用者
使用者自行結對不可能完成所有科目的輔導需求，本平台提供基本所有科目的N多輔導人員，使用者可自行選擇科目，以及同一科目下可選擇輔導風格适合自己的輔導人員。使用者一次結對完成需求後需要輔導雙方提供評價回報以确定輔導費用。使用者下次有不同科目需求自然還會選擇我們平台，因為目前大學生輔導市場基本空白，我們平台的多科目多學長可以滿足不同使用者不同科目的需求。屆時可以考慮加個問題社群，簡化結對，認證，甚至不提供收費，純資訊展示交流平台
7.如何吸引輔導人員的入駐
輔導人員相當于一份家教兼職，隻不過輔導對象變成了在校大學生，被輔導人員會向輔導人員支付輔導費用，以此吸引想要勤工儉學的輔導人員入駐平台，當然項目完成後初期也會進行推廣以吸引使用者（例如和社委會、黨員服務站一起合作，通過綜測的獎勵或者黨員時長獎勵）
新的思考
- 我們團隊初步制定的方案需求比較少，在老師同學的提議下，我們考慮在細節方面增加一些能夠吸引客戶的需求點。比如一對一幫扶的活動，共同進步可以獲得獎金這樣的功能。不僅能促進同學們結對學習，還對大家的學習态度有了積極的引導。另外，應用所面向的使用者應該擴大一些範圍，增加中學生甚至是國小生這樣的閱聽人，旨在為更多的人提供學習的便利，同時提升應用的熱度。