| 這個作業屬於哪個課程 | 2020春季軟件工程W班 |
|---|---|
| 這個作業要求在哪里 | 團隊作業第二次要求 |
| 這個作業的目標 | 使用Github進行團隊協作 |
| 作業正文 | 本文鏈接在這里！ |
| 其他參考文獻 | 《構建之法》 |
Part 1 關於此次作業
（1）組員職責分工
- 221701436：組織小組參與討論分工，測試，修復bug,補充未完善的操作，博客第二部分撰寫
- 221701435：ui界面和部分方法的實現
- 221701426：詢問需要檢測的模塊，編寫檢驗程序
- 181700141：一部分業務規則和一部分具體實現
- 221701401：一部分業務規則和一部分具體實現
- 221701402：數據庫接口和操作類（DBUtil&DAO）
- 221701403：因為沒有電腦限制了我很多行動，我有一顆參與代碼實現的心卻沒有工具，以致這次團隊實踐我只能充當個混子，能起到的作用也就提提問題意見，希望在下一次團隊實踐來之前能開學，我想為團隊貢獻更多力量。
221701309:對應每張表編寫一個對應實體類（類中需包含get和set方法，以及相應的檢測方法調用）,進行博客第一部分的整合。
（2）github 的提交日志截圖，統計各組員的commit次數
github倉庫：https://github.com/metro1435/live-project
A.日志截圖
項目文件
全體成員commit記錄
B.各組員commit次數
- 221701436：4次
- 221701435：4次
- 221701426：1次
- 181700141：3次
- 221701401：3次
- 221701402：5次
- 221701403：0次
- 221701309：5次
（3）程序運行&GUI界面截圖
初次進入系統時顯示如下界面，“登記”按鈕暫不可用
點擊“預約”，彈出預約界面，可選擇開始或結束預約
點擊“開始預約”后，“登記”按鈕變為可用
點擊“登記”，彈出登記須知
點擊“確定”后，進入登記頁面，登記完成后返回主界面
點擊“查詢”，彈出查詢頁面，輸入預約號即可查詢
（4）程序運行環境
IntellJ IDEA
- 將整個項目導入到IDEA即可運行
- 需要手動配置與MySQL數據庫的連接參數，及導入Jar包。
（5）基礎功能實現
- 通過按鈕實現預約系統的定時開放
- 登記預約信息
- 隨機抽取符合條件的預約
- 通過輸入預約號查看是否中簽
（6）程序截圖
1、DAO數據控制類
2、數據庫鏈接類DBUtil
3、處理抽取用戶預約的類Extract
4、抽簽的核心功能函數drawlots
5、用於處理用戶登記信息的Registration類
（7）困難&解決方法
- 221701436
問題：測試時有難以發現的bug，代碼復審時有分工的部分存在邏輯上的矛盾
解決方法：查找資料，想盡一切可能導致出錯的原因（如中文括號），與參與施工的人進行溝通化解分歧。
- 221701435
團隊里大部分都不太會web后端服務，所以只能使用大二學習的javaswing來實現，swing部分的知識大家都忘的差不多了，gui界面由我來負責，我也只能靠查詢資料來解燃眉之急。在背景圖片處，我很難處理，因為在swing組件中，label是不能設置透明，而jframe下很難實現背景圖片，因為有些我也沒有深思的原因，感覺是無法加載出來組件。后面我還是在frame的條件下，用label去實現，不過最后還是會背景為白色。在觸發器部分的話，因為第一次合作，大家代碼規范都不是很好，導致bug很多，也不知道怎么處理，就很麻煩，一開始的討論也沒有討論清楚，思考就占據了大部分寫代碼的時間，導致代碼無法編寫完成。並且課程安排也不太合理，周六剛交完上一次作業，上完課，組內大部分同學的精神狀態非常低，並且只給予半天的時間作業，希望也明白難處。
- 221701426
問題：不知道如何實現的功能或者復雜的功能
解決方法：抄代碼然后根據實際情況改造
- 181700141
問題：開發過程數據庫操作忘記掉，業務設計之前需求分析偏差導致業務設計遇到問題，然后花費較多時間去業務設計。
解決方法：通過調用隊友的數據庫接口實現操作，業務設計則再重新確定需求后得以進一步設計下去。
- 221701401
問題：前三次中簽的查詢安排
解決方法：跟隊友一起研究
- 221701402
問題：數據庫如何運行不起來，數據庫的封裝和使用
解決方法：導入jar包 - 221701403
問題：硬件設施上沒有電腦無法實際操作，本來想設計個原型都沒法完成。軟件上太久沒碰過java導致很多知識點忘卻
解決方法：硬件設施暫時還沒有解決方法只能期盼早點開學，java知識點雖然可以通過資料復習但是遠不如實際打代碼復習來得有效。
- 221701309
問題：最開始拿到任務的時候不太清楚自己具體該做什么
解決方法：通過與組長以及小組成員通話明白自己的任務，從而能夠進入具體編程階段
（8）評估每位組員的貢獻比例(總分100)
| 學號 | 姓名 | 貢獻比例 |
|---|---|---|
| 221701436 | 林晟 | 11% |
| 221701435 | 繆浩涵 | 19% |
| 221701426 | 鄭志成 | 8% |
| 181700141 | 吳鴻敬 | 18% |
| 221701401 | 黃素芳 | 16% |
| 221701402 | 王小雅 | 11% |
| 221701403 | 王吁伊 | 4%（電腦不在手邊但參與討論） |
| 221701309 | 黃秋妍 | 11% |
（9）PSP表格
- 221701436
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 10 | 15 |
| Estimate | 估計這個任務需要多少時間 | 3 | 3 |
| Development | 開發 | 2000 | 3200 |
| Analysis | 需求分析 (包括學習新技術) | 60 | 80 |
| Design Spec | 生成設計文檔 | 60 | 100 |
| Design Review | 設計復審 | 20 | 20 |
| Coding Standard | 代碼規范 (為目前的開發制定合適的規范) | 15 | 15 |
| Design | 具體設計 | 40 | 60 |
| Coding | 具體編碼 | 2000 | 3000 |
| Code Review | 代碼復審 | 40 | 40 |
| Test | 測試（自我測試，修改代碼，提交修改） | 40 | 40 |
| Reporting | 報告 | 10 | 20 |
| Test Repor | 測試報告 | 10 | 10 |
| Size Measurement | 計算工作量 | 5 | 5 |
| Postmortem & Process Improvement Plan | 事后總結, 並提出過程改進計划 | 30 | 30 |
| 合計 | 4343 | 6638 |
- 221701435
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 90 | 90 |
| Estimate | 估計這個任務需要多少時間 | 650 | 860 |
| Development | 開發 | 540 | 720 |
| Analysis | 需求分析 (包括學習新技術) | 30 | 30 |
| Design Spec | 生成設計文檔 | 30 | 30 |
| Design Review | 設計復審 | 30 | 30 |
| Coding Standard | 代碼規范 (為目前的開發制定合適的規范) | 30 | 30 |
| Design | 具體設計 | 120 | 150 |
| Coding | 具體編碼 | 180 | 330 |
| Code Review | 代碼復審 | 60 | 60 |
| Test | 測試（自我測試，修改代碼，提交修改） | 60 | 60 |
| Reporting | 報告 | 110 | 140 |
| Test Repor | 測試報告 | 30 | 60 |
| Size Measurement | 計算工作量 | 20 | 20 |
| Postmortem & Process Improvement Plan | 事后總結, 並提出過程改進計划 | 60 | 60 |
| 合計 | 740 | 950 |
- 221701426
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 20 | 15 |
| Estimate | 估計這個任務需要多少時間 | 10 | 0 |
| Development | 開發 | 20 | 20 |
| Analysis | 需求分析 (包括學習新技術) | 60 | 30 |
| Design Spec | 生成設計文檔 | 10 | 0 |
| Design Review | 設計復審 | 30 | 20 |
| Coding Standard | 代碼規范 (為目前的開發制定合適的規范) | 10 | 0 |
| Design | 具體設計 | 30 | 30 |
| Coding | 具體編碼 | 120 | 180 |
| Code Review | 代碼復審 | 30 | 20 |
| Test | 測試（自我測試，修改代碼，提交修改） | 30 | 20 |
| Reporting | 報告 | 20 | 10 |
| Test Repor | 測試報告 | 20 | 10 |
| Size Measurement | 計算工作量 | 20 | 0 |
| Postmortem & Process Improvement Plan | 事后總結, 並提出過程改進計划 | 30 | 5 |
| 合計 | 460 | 360 |
- 181700141
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 60 | 70 |
| Estimate | 估計這個任務需要多少時間 | 30 | 40 |
| Development | 開發 | 30 | 30 |
| Analysis | 需求分析 (包括學習新技術) | 100 | 100 |
| Design Spec | 生成設計文檔 | 30 | 30 |
| Design Review | 設計復審 | 20 | 20 |
| Coding Standard | 代碼規范 (為目前的開發制定合適的規范) | 20 | 20 |
| Design | 具體設計 | 90 | 100 |
| Coding | 具體編碼 | 90 | 100 |
| Code Review | 代碼復審 | 10 | 10 |
| Test | 測試（自我測試，修改代碼，提交修改） | 20 | 20 |
| Reporting | 報告 | 20 | 20 |
| Test Repor | 測試報告 | 10 | 10 |
| Size Measurement | 計算工作量 | 10 | 20 |
| Postmortem & Process Improvement Plan | 事后總結, 並提出過程改進計划 | 30 | 30 |
| 合計 | 570 | 600 |
- 221701401
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 20 | 30 |
| Estimate | 估計這個任務需要多少時間 | 20 | 30 |
| Development | 開發 | 340 | 525 |
| Analysis | 需求分析 (包括學習新技術) | 60 | 70 |
| Design Spec | 生成設計文檔 | 30 | 75 |
| Design Review | 設計復審 | 10 | 20 |
| Coding Standard | 代碼規范 (為目前的開發制定合適的規范) | - | - |
| Design | 具體設計 | 40 | 70 |
| Coding | 具體編碼 | 120 | 150 |
| Code Review | 代碼復審 | 60 | 100 |
| Test | 測試（自我測試，修改代碼，提交修改） | 20 | 40 |
| Reporting | 報告 | 56 | 73 |
| Test Report | 測試報告 | 20 | 30 |
| Size Measurement | 計算工作量 | 6 | 8 |
| Postmortem & Process Improvement Plan | 事后總結, 並提出過程改進計划 | 30 | 35 |
| 合計 | 416 | 628 |
- 221701402
| Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|
| Planning | 計划 | 30 |
| Estimate | 估計這個任務需要多少時間 | 30 |
| Development | 開發 | 230 |
| Analysis | 需求分析 (包括學習新技術) | 10 |
| Design Spec | 生成設計文檔 | |
| Design Review | 設計復審 | |
| Coding Standard | 代碼規范 (為目前的開發制定合適的規范) | |
| Design | 具體設計 | 30 |
| Coding | 具體編碼 | 120 |
| Code Review | 代碼復審 | 40 |
| Test | 測試（自我測試，修改代碼，提交修改） | 30 |
| Reporting | 報告 | 5 |
| Test Repor | 測試報告 | - |
| Size Measurement | 計算工作量 | 5 |
| Postmortem & Process Improvement Plan | 事后總結, 並提出過程改進計划 | 5 |
| 合計 | 295 |
- 221701403
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 90 | 105 |
| Estimate | 估計這個任務需要多少時間 | 10 | 10 |
| Development | 開發 | 120 | 0 |
| Analysis | 需求分析 (包括學習新技術) | 60 | 100 |
| Design Spec | 生成設計文檔 | 0 | 0 |
| Design Review | 設計復審 | 0 | 0 |
| Coding Standard | 代碼規范 (為目前的開發制定合適的規范) | 0 | 0 |
| Design | 具體設計 | 100 | 0 |
| Coding | 具體編碼 | 120 | 0 |
| Code Review | 代碼復審 | 60 | 0 |
| Test | 測試（自我測試，修改代碼，提交修改） | 30 | 0 |
| Reporting | 報告 | 20 | 10 |
| Test Repor | 測試報告 | 30 | 0 |
| Size Measurement | 計算工作量 | 0 | 0 |
| Postmortem & Process Improvement Plan | 事后總結, 並提出過程改進計划 | 50 | 60 |
| 合計 | 690 | 285 |
- 221701309
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 30 | 30 |
| Estimate | 估計這個任務需要多少時間 | 5 | 5 |
| Development | 開發 | ||
| Analysis | 需求分析 (包括學習新技術) | 60 | 60 |
| Design Spec | 生成設計文檔 | 30 | 30 |
| Design Review | 設計復審 | 5 | 5 |
| Coding Standard | 代碼規范 (為目前的開發制定合適的規范) | 20 | 10 |
| Design | 具體設計 | 30 | 20 |
| Coding | 具體編碼 | 60 | 120 |
| Code Review | 代碼復審 | 10 | 10 |
| Test | 測試（自我測試，修改代碼，提交修改） | 10 | 10 |
| Reporting | 報告 | 5 | 10 |
| Test Repor | 測試報告 | - | - |
| Size Measurement | 計算工作量 | 5 | 5 |
| Postmortem & Process Improvement Plan | 事后總結, 並提出過程改進計划 | 30 | 60 |
| 合計 | 300 | 375 |
Part 2 問題反饋&思考
（1）團隊答辯時問題答復
-
對於超越小黑板，你們是否有信心？
有信心！小黑板雖然在用戶之間有已經良好的口碑，短時間無法超越，但是我們可以通過微信公眾號，邀請小黑板作為貢獻者入駐等宣傳方式，提高我們的知名度和宣傳我們的優勢。
-
校園新聞的來源有哪些？是數據抓取嗎？
大部分通過學校各官方網站抓取，一部分（比如學生福利等）需要人工收集發布。
-
與論壇的功能非常類似，后台考慮如何管理信息？
采用標簽化管理
-
熱門話題采用什么算法
使用相似度矩陣進行層次聚類分析，選取最大的類作為最能代表文本類內容的話題詞組。
-
如何快速判斷當前用戶輸入的問題，跟過去提過的問題是類似的？准備做文本分析嗎？
文本具有了主題分部向量，通過聚類分析得到接近的話題
-
有考慮敏感內容屏蔽嗎？
當然有，通過調用API實現屏蔽
-
是不是有考慮讓某些用戶成為專職的“提問者”和“解答者”？
有的，給特定用戶一些權限可以讓用戶參與度更高
-
那如果用戶群較多，你們操作的工作量會很大嗎
我們會設計一些算法減輕后台的工作量
-
用戶是采用自由注冊嗎，還是和學號綁定？
學號綁定，畢竟是軟件是關於福大的，目標就是為了讓福大學生了解校內新聞。其他用戶沒必要幫其進行整理。
-
類似知乎？那么對比知乎的功能了嗎？
我們的校園熱話功能類似知乎，對比知乎，我們除了關注者功能之外其他都有做。
-
知乎因為不面向校內，就不是你們的競品了嗎？授課老師推薦？
是我們的競品，因為用戶可以選擇瀏覽校內或校外新聞。但是我們比知乎有更能幫助校內用戶的功能。授課老師推薦主要還是根據用戶評價的數據分析。
（2）團隊選題之后，新的思考和想法
-
同學A：產品在90%的人的市場無法競爭過別人，那么就把剩下10%的人伺候得足夠好。
-
同學B：可以增加一些不只是是校內的新聞，可以讓大家看看最近發生的實時啥的
-
同學C：我認為在原來的基礎上可以增加信用度這樣一個標准，雖然是個匿名平台，但是涉及到評價校內
老師和教學以及交易買賣，信用是很重要的。每個匿名用戶獲得相同的初始信用度，信用度怎么改變？來源於其他人的評價，這就需要增加一個評價其他用戶的功能。獲得好評可以增加信用度，獲得差評則減少信用度。信用度加到一定值可以享受發言顯示優先等特權，信用度減到一定值則被禁言或其他處罰 -
同學D：應當充分調研市場，發現和對比競品，盡力做到最好。
-
同學E：團隊選題之后，我其實挺迷茫的，因為前一天才說是二手交易，然后睡了一覺就變成了，福大熱搜？？？這個其實對我們都是前端的隊伍難度系數非常大，因為我們沒有一個好的后端，算法部分我們基本是一竅不通。后面幾天就很迷茫，只能平常多了解一下這些東西了
Part 3 事后反思==>負荊請罪
- 221701436
時間很倉促，我們只能盡全力而為，初次合作，困難在所難免。我們開始合作時的不足之處就在於：對於使用Github管理項目還不習慣，暫時使用群內共享文件的形式，盡管組內分工明確，但是各成員進度不同導致開發時很不協調。我們在實踐的過程中漸漸體會到使用GIThub進行團隊合作的好處，效率漸漸提高。盡管任務緊迫，交流受限，組員還是拿出了十足的戰斗精神，互相鼓勵，互相學習，盡全力寫好代碼。盡管程序並不是很完善，但是看着組員們拼搏的樣子，我覺得我們小組的每個人都是值得敬佩的
- 221701435
感覺自己組織方面還是非常差，一開始感覺就是效率非常低，因為大家都是第一次合作，gui界面寫完后，等待了好久他們的方法，結果才知道還在思考的部分，就只能加入他們先把方法，搞定。然后的話是一開始的架構，也沒有思考清楚，導致后面方法非常的亂，代碼規范也大相庭徑。看起代碼很吃力。總結還是合作方面太弱了，有點茫然吧。
- 221701426
技術不熟練，沒有幫上太大忙。遇到問題可以在組內提出，而不是一個人死磕。有不清楚的地方可以討論。
有空閑的時間，可以給其他組員幫忙。遇到技術問題，自己沒辦法解決，可以去參考已有的解決方案
- 181700141
在進行具體類圖設計之前應該要把需求分析正確避免分析不准確后續再去修改類圖。團隊開發中在開發之前應該要確定自己負責的那部分對外接口以及應該實現的功能，並告知隊友。開發過程中不能修改對外的接口名和自己要實現的功能。最后對於以前學習過的知識應該多練習要不然容易忘記
- 221701401
這次是第一次團隊協作，讓我深刻認識到了自己的不足，從溝通到各種工具的使用，都不行，考慮做法也考慮了很久，進度也跟不上，很多問題都處在我身上（謝罪）
- 221701402
從早上8點30開始的團隊實訓終於要在23：30結束了，做的項目成果不是很盡人意，大家都有各種各樣的問題，一開始題目就不是很理解，后面分析了很久，但是我相信我的團隊，時間很趕，大家也是都沒有怨言，辛苦大家了！希望下次繼續努力！加油！下次一定會更好！
- 221701403
第一次合作，時間非常緊迫
寫啥都報錯，不寫又不給過
功能雖不多，奈何技術太弱
弱是我的鍋，全靠隊友帶我
腦內沒存貨，平時實操不多
思想不靈活，干瞪題目上火
希望下一次，代碼帶來快落
- 221701309
第一次團隊作業我不再是一個人獨立前行，有同伴的支持和鼓勵讓我們始終不放棄彼此，也沒有被困難打倒，一直堅持到最后。必須深刻反思的是，因為我個人能力不夠優秀，並不能提高團隊的開發效率，為此我很愧疚，在此，我想跟我的隊友們說聲抱歉。但是，雖然我們開發的不夠完美，但我們已經竭盡全力，一天的時間，可以說我們除了吃飯就在打代碼了，沒有一分鍾消極怠工。這是我們第一次合作，也許不夠好，但是我們未來會更好！