| 這個作業屬於哪個課程 | <軟件工程2020春|W班 (福州大學)> |
|---|---|
| 這個作業要求在哪里 | <作業要求的鏈接> |
| 這個作業的目標 | 開發一個向社會限量供應的口罩應用 |
| 作業正文 | 就是這里 |
| 其他參考文獻 |
GITHUB地址
https://github.com/RETORETO/live-project
release
https://github.com/RETORETO/live-project/releases/tag/1.0.0
組員職責分工
041701602:組織分工，博客攥寫，部分代碼實現
221701140:UI界面和部分代碼實現，部分業務規則和實現
081700308:UI界面和部分代碼實現
021700915:數據庫，數據庫接口和類操作，前后端接口
221701111:部分業務規則和具體實現
221701130:部分業務規則和具體實現
前端：陳秉宥，付其佳
后端：陳晟，林學斌，劉曉龍，林泰來
前后端接口：林學斌，劉曉龍
github 的提交日志截圖
| 學號 | commit次數 |
|---|---|
| 221701140 | 7 |
| 041701602 | 10 |
| 081700308 | 6 |
| 221701111 | 6 |
| 221701130 | 12 |
| 021700915 | 3 |
程序運行截圖
程序運行環境
MYSQL 5.6
下載文件后，運行sql目錄下的sql文件，文件直接導入eclipse文件可以打開，從scr/ui/menu進入程序
文件下載
基礎功能實現
通過數據庫record表儲存預約信息，在JAVA中用record類儲存，前端頁面收入信息后進行輸入合法性檢測后傳入后端和數據庫進行比對后存入數據庫。
遇到的困難及解決方法
劉曉龍
困難：在編寫市民預約登記功能時，對於市民填寫的相關信息存儲入數據表中，遇到部分亂碼，以及輸入信息后如何與之后的相關信息結合起來，進行判斷。
解決困難：再次修改數據表信息，檢查相關編碼，以及通過登記信息的結合形成相關預約信息
林泰來
困難1：一開始編寫查詢類的時候由於長時間沒有寫過相關的功能，完全不知道怎么下手。
解決困難：把之前做過的類似的作業拿出來復習了一遍，很快就回想起編碼的思路了。
困難2：由於較長時間未使用數據庫，導致數據庫密碼和使用方式都忘了。
解決困難：重新設置了數據庫密碼並在網上簡單地學習了數據庫的使用教程於是很快就能上手了。
困難3：開始時不知道自己需要干什么事，做哪些工作。
解決困難：及時與小組成員交流和溝通，大家一起討論出一共需要做哪些工作以及每個人分配到哪些內容。
林學斌：
困難：首先是技術儲備不足，在進行需求分析的時候想過使用JavaEE來實現，但是由於沒選修JavaEE，又想過使用PHP來實現，但是隊友中也有一部分對PHP不熟悉，最后決定使用Java語言編寫，每個人先稍微復習一下Java語言，然后解決了這個語言選擇的問題。其次是分工不明確。在分配的時候，對隊友不熟悉，有時候剛好分配給某隊友不擅長的地方，導致任務進展緩慢。對項目不熟悉導致分工模糊。最后經過隊友間相互溝通交流有效的解決了部分問題。
陳晟：
困難：果然還是GITHUB上和隊友交接的問題吧，經常有重復提交錯誤之類的發生
解決困難：提交之前先和隊友說好
解決困難：最后是對GitHub使用不熟悉，提交混亂。因為之前都是結對合作，只有兩個人提交，提交起來方便，但是團隊人數眾多，提交代碼混亂，各種版本都存在
組員貢獻
| 學號 | 貢獻度 |
|---|---|
| 221701140 | 14 |
| 041701602 | 16 |
| 081700308 | 17 |
| 221701111 | 17 |
| 221701130 | 16 |
| 021700915 | 19 |
小組六人的PSP表格
| 陳晟 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 30 | 30 |
| Estimate | 估計這個任務需要多少時間 | 30 | 30 |
| Development | 開發 | 790 | 685 |
| Analysis | 需求分析 (包括學習新技術) | 0 | 0 |
| Design Spec | 生成設計文檔 | 30 | 30 |
| Design Review | 設計復審 | 10 | 5 |
| Coding Standard | 代碼規范 (為目前的開發制定合適的規范) | 30 | 10 |
| Design | 具體設計 | 20 | 30 |
| Coding | 具體編碼 | 600 | 530 |
| Code Review | 代碼復審 | 30 | 30 |
| Test | 測試（自我測試，修改代碼，提交修改） | 70 | 50 |
| Reporting | 報告 | 70 | 70 |
| Test Repor | 測試報告 | 30 | 50 |
| Size Measurement | 計算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后總結, 並提出過程改進計划 | 30 | 10 |
| 合計 | 890 | 785 |
| 劉曉龍 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 30 | 30 |
| Estimate | 估計這個任務需要多少時間 | 30 | 30 |
| Development | 開發 | 760 | 755 |
| Analysis | 需求分析 (包括學習新技術) | 0 | 0 |
| Design Spec | 生成設計文檔 | 20 | 30 |
| Design Review | 設計復審 | 10 | 5 |
| Coding Standard | 代碼規范 (為目前的開發制定合適的規范) | 20 | 10 |
| Design | 具體設計 | 20 | 30 |
| Coding | 具體編碼 | 600 | 600 |
| Code Review | 代碼復審 | 40 | 30 |
| Test | 測試（自我測試，修改代碼，提交修改） | 50 | 50 |
| Reporting | 報告 | 60 | 50 |
| Test Repor | 測試報告 | 20 | 30 |
| Size Measurement | 計算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后總結, 並提出過程改進計划 | 30 | 10 |
| 合計 | 850 | 835 |
| 付其佳 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 20 | 30 |
| Estimate | 估計這個任務需要多少時間 | 20 | 30 |
| Development | 開發 | 700 | 755 |
| Analysis | 需求分析 (包括學習新技術) | 0 | 0 |
| Design Spec | 生成設計文檔 | 40 | 30 |
| Design Review | 設計復審 | 10 | 5 |
| Coding Standard | 代碼規范 (為目前的開發制定合適的規范) | 20 | 10 |
| Design | 具體設計 | 40 | 30 |
| Coding | 具體編碼 | 540 | 600 |
| Code Review | 代碼復審 | 20 | 30 |
| Test | 測試（自我測試，修改代碼，提交修改） | 30 | 50 |
| Reporting | 報告 | 30 | 50 |
| Test Repor | 測試報告 | 10 | 30 |
| Size Measurement | 計算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后總結, 並提出過程改進計划 | 10 | 10 |
| 合計 | 750 | 835 |
| 陳秉宥 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 30 | 30 |
| Estimate | 估計這個任務需要多少時間 | 30 | 30 |
| Development | 開發 | 760 | 595 |
| Analysis | 需求分析 (包括學習新技術) | 60 | 180 |
| Design Spec | 生成設計文檔 | 10 | 10 |
| Design Review | 設計復審 | 10 | 5 |
| Coding Standard | 代碼規范 (為目前的開發制定合適的規范) | 30 | 10 |
| Design | 具體設計 | 20 | 30 |
| Coding | 具體編碼 | 400 | 330 |
| Code Review | 代碼復審 | 30 | 30 |
| Test | 測試（自我測試，修改代碼，提交修改） | 70 | 60 |
| Reporting | 報告 | 30 | 10 |
| Test Repor | 測試報告 | 30 | 30 |
| Size Measurement | 計算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后總結, 並提出過程改進計划 | 30 | 10 |
| 合計 | 660 | 695 |
| 林泰來 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 20 | 30 |
| Estimate | 估計這個任務需要多少時間 | 20 | 30 |
| Development | 開發 | 710 | 755 |
| Analysis | 需求分析 (包括學習新技術) | 0 | 0 |
| Design Spec | 生成設計文檔 | 40 | 30 |
| Design Review | 設計復審 | 10 | 5 |
| Coding Standard | 代碼規范 (為目前的開發制定合適的規范) | 10 | 10 |
| Design | 具體設計 | 30 | 30 |
| Coding | 具體編碼 | 550 | 600 |
| Code Review | 代碼復審 | 40 | 30 |
| Test | 測試（自我測試，修改代碼，提交修改） | 30 | 50 |
| Reporting | 報告 | 10 | 50 |
| Test Repor | 測試報告 | 10 | 30 |
| Size Measurement | 計算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后總結, 並提出過程改進計划 | 30 | 10 |
| 合計 | 890 | 835 |
| 林學斌 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 25 | 30 |
| Estimate | 估計這個任務需要多少時間 | 25 | 15 |
| Development | 開發 | 240 | 250 |
| Analysis | 需求分析 (包括學習新技術) | 60 | 15 |
| Design Spec | 生成設計文檔 | 20 | 30 |
| Design Review | 設計復審 | 25 | 5 |
| Coding Standard | 代碼規范 (為目前的開發制定合適的規范) | 15 | 10 |
| Design | 具體設計 | 30 | 30 |
| Coding | 具體編碼 | 240 | 200 |
| Code Review | 代碼復審 | 30 | 30 |
| Test | 測試（自我測試，修改代碼，提交修改） | 30 | 30 |
| Reporting | 報告 | 10 | 20 |
| Test Repor | 測試報告 | 10 | 20 |
| Size Measurement | 計算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后總結, 並提出過程改進計划 | 30 | 10 |
| 合計 | 800 | 695 |
團隊選題答疑部分
Q:如何防止商家或者學生惡意刷積分？
A:積分的來源是消費（消費過后才能評論和獲取積分），積分的用處是抵用券，為了抵用券去消費我們認為是不值得的
Q:可以理解為食堂攤位是商家，學生是用戶？那么跟一般的點餐系統最大的差別在哪里？
A:我們和一般的點餐系統差異化主要體現在這幾點：一是我們專門服務於食堂，更加輕便靈活，致力於解決學生排隊排了很久卻不是自己想排的窗口/想吃的食物已經售罄了的情況，另外也能省下騎手和打包的費用；二是我們的評價系統引入的“等待時間”的評價，把看不見的騎手配送時間變成可以估算的等待時間，適合生活節奏較快的學生。
Q:存在預約人少，但實際上現場排隊的人很多，這樣的現象，如何讓預約給予正確的含義？
A:這也是我們引入“等待時間”評級的理由，學生可以在排隊之前通過我們的程序大致上判斷當前時間段哪里的窗口更擁擠。
Q:對商家而言，我為什么要加入你們平台呢?
A:我們認為商家加入新的使用便利的平台是有利於商家的推廣的，平台順利推廣開來以后也能營造出商家不加入平台就會在和其他商家的競爭上陷入劣勢的情況。