| 這個作業屬于哪個課程 | <2020春S班(福州大學)> |
|---|---|
| 這個作業要求在哪裡 | <作業要求的連結> |
| 團隊名稱 | 烤鹽屋 |
| 這個作業的目标 | 開發一個向社會限量供應的口罩應用 |
| 作業正文 | <團隊作業第二次——團隊Github實戰訓練> |
| 其他參考文獻 | 無 |
Part 1 ——團隊Github實戰訓練
基礎功能實作
1.功能清單：對于每個功能點，使用0代表沒有完成，0.5代表完成部分，1代表成功實作；對于0.5的項，在表格後描述完成的程度，例如僅完成前端等
| 功能點 | 完成度 |
|---|---|
| 身份證、手機号格式驗證及錯誤提示 | 1 |
| 身份證、手機号的唯一性及錯誤提示 | |
| 間隔三次才能預約及錯誤提示 | |
| 存儲預約資訊 | |
| 預約結束後的中簽計算 | 0.5 |
| 預約查詢及提示 | |
| …… |
2.如有完成，描述抽簽算法
抽簽算法屬于在口罩個數夠的時候直接中簽，不夠就提示，屬于先到先得類型，不夠随機
| 管理者登入 | |
| 設定預約的開放時間和截止時間 | |
| 設定預約時單個使用者最高可預約數量 | |
| 設定口罩總數 | |
| 導出某次中簽的名單 | |
組員職務分工
| 學号 | 具體分工 | commit次數 | 貢獻度 |
|---|---|---|---|
| 131700305 | 部落格 | 6 | |
| 221701113 | 後端 | ||
| 221701131 | 前端 | 4 | 18 |
| 221701214 | 9 | ||
| 221701236 | 2 | 15 | |
| 221701313 | |||
| 221701329 | |||
| 221701411 | |||
| 221701437 | 16 |
github送出日志截圖
團隊作業第二次——團隊Github實戰訓練
程式運作截圖
1、首先是首頁，預約時間未到無法點選預約按鈕。
2、設定好時間後點選開始預約。
3、可以看到預約按鈕變綠，此時可以點選進入預約界面。
4、在預約界面，我們随便輸入一串不合法的資料。
5、檢查身份證，直接報錯。
6、若身份證合法，檢查手機号，報錯。
7、身份證和手機号都合法，但是已經用該資訊預約過了，是以預約失敗。
8、修改資訊後點選預約，這下成功了，跳出我們的預約編号，可以進行複制。
9、結束預約後根據預約編号或者身份證進行查詢。
10、點選後發現我們中簽了。
11、如果輸入的是一個沒有中簽的編号。
12、顯示很遺憾，未中簽。
程式運作環境
<位址>
直接下載下傳運作
小組遇到的困難及解決辦法
“此次開發采用的是前後端分離的模式，但是在前後端的連接配接上花費了不少功夫，直到最後的時刻還在修複bug”
解決方法:暫無
PSP表格
黃一舟
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 20 | 25 |
| Estimate | 估計這個任務需要多少時間 | 30 | |
| Development | 開發 | 300 | |
| Analysis | 需求分析 (包括學習新技術) | 320 | |
| Design Spec | 生成設計文檔 | 40 | |
| Design Review | 設計複審 | ||
| Coding Standard | 代碼規範 (為目前的開發制定合适的規範) | ||
| Design | 具體設計 | 260 | |
| Coding | 具體編碼 | ||
| Code Review | 代碼複審 | ||
| Test | 測試（自我測試，修改代碼，送出修改） | 100 | 120 |
| Reporting | 報告 | 50 | |
| Test Repor | 測試報告 | ||
| Size Measurement | 計算工作量 | 10 | |
| Postmortem & Process Improvement Plan | 事後總結, 并提出過程改進計劃 | ||
| 合計 | 1780 | 1825 |
王霆锴
| 240 | 250 | ||
| 70 | |||
| 310 | |||
| 1350 | 1385 |
鄭志成
| 330 | |||
| 130 | |||
| 1330 |
陳朝帏
| 350 | 360 | ||
| 1370 | 1400 |
郭子成
| 290 | |||
| 150 | 160 | ||
| 140 | |||
| 1390 | 1380 |
任智明
| 180 | |||
| 280 | |||
| 110 | |||
| 1450 | 1340 |
留曉濱
| 1480 | 1500 |
代銘傑
| 340 | |||
| 1300 | 1290 |
張岑
| 200 | 220 | ||
| 1200 | 1235 |
Part 2 ——團隊産品分析讨論
資料收集很龐雜，要如何處理？
考研資料雖然非常龐雜，但是網上的考研網站非常多，從網站爬取考研資料就可以收集到,通過網絡爬蟲或網站公開API等方式從網站上擷取資料資訊。該方法可以将非結構化資料從網頁中抽取出來，将其存儲為統一的本地資料檔案，并以結構化的方式存儲。它支援圖檔、音頻、視訊等檔案或附件的采集，附件與正文可以自動關聯。
社群相比qq群有什麼優點？
QQ式的群聊，大凡是些未經考慮的自我表達和演講，對于問題缺少針對和思考；另外一方面，表達的不連貫性，其他使用者的插入式說話，必然也會給提問者或者其他使用者帶來思維上的困難。我們在開會或者頭腦風暴的時候，也是需要一個人完整的表達，另外的夥>伴才開始發言。打斷和插入，都是影響讨論效果的。
而社群式的讨論則不會有這個問題。由于主帖以及貼主的存在，讓問題更具有針對性以及持續性，進而讓問題的目的性得以顯現
功能太弱，有什麼辦法提高？
功能太弱感覺主要是子產品不夠多，相比其他的軟體我們隻有三個子產品，感覺可以在基礎上拓展一些功能，我們目前考慮到的有考研規劃和找學長等一些功能