福大軟工1816 · 團隊現場編程實戰(抽獎系統)之 拖鞋旅遊隊
阿新 • • 發佈:2018-11-19
系統消息 per ges 整合 應該 style 極速 基礎 技術分享
一、組員職責分工及貢獻分
學號 | 成員 | 分工 | 貢獻分 |
---|---|---|---|
031602428 | 蘇路明 | 整合代碼,抽獎算法實現部分 | 12 |
031602401 | 陳瀚霖 | 設計算法、文案 | 8 |
031602406 | 程曉宏 | 提取抽獎名單 | 12 |
031602438 | 葉一帆 | 抽獎界面、海報界面 | 15 |
031602407 | 何家健 | 設計算法、文案 | 6 |
031602410 | 黃海潮 | 設計算法、文案 | 8 |
031602429 | 王錦揚 | 原型設計 | 8 |
031602442 | 鄭孔宇 | 撰寫博客,思考附加需求(orz 根本沒時間實現) | 8 |
031602439 | 俞凱欣 | 原型設計 | 9 |
031602421 | 林世傑 | 用戶權重算法設計、實現 | 14 |
二、github 的提交日誌截圖
三、程序運行截圖
- 先按照格式輸入時間信息和其他信息
- 點擊抽獎即可生成結果界面
四、程序運行環境
- 程序語言:python
- 程序運行環境:桌面程序(可在pycharm裏直接運行)
五、GUI界面
- 主界面
- 獲獎名單界面
六、基礎功能實現
- 采用的抽獎算法
1.根據得出的權重 Value 進?行行累加計算得 TotalValue,並根據 key 的個數得出KeyCount.
2.將每個?的 Value 除 TotalValue 得到 T_value(小於 1 的數).
3.將得到的 T_value(0.02KeyCount))得到 P_Value.
4.取?個 0-1 之間的隨機數 Random
5.Math 的值為 Random*(1-P_Value).
註:權重越高的用戶得到的P_Value值越大,Math值由隨機數和P_Value值決定,兩者權重五五開,權重越高的用戶獲獎的幾率越高,同時也保證權重相對低的用戶也有獲獎的機會 - 抽獎算法2
由於時間關系,只實現了由上述算法的抽獎方式,而沒有采用分等獎品的抽獎方式,在此就不贅述了。 - 用戶權重計算方法
1.系統消息用戶權重為0,未發言過的用戶權重為0。
2.消息發送得越多的用戶權重越高,但是增長也會逐漸降低。
3.采用用戶參與聊天的次數和發言數量結合來產生權重。例如,用戶A與用戶B發言數量相當,但是用戶A只在某一時段參與聊天,而用戶B在多個時段參與聊天,用戶B的權重有可能會比用戶A高。(在本次算法中,來不及實現) - 提取某項參與抽獎用戶
1.用戶過濾,剔除不在抽獎時段參與抽獎的用戶。
2.用戶去重,用戶多次發送參與同一抽獎,只占一份名單。 - 抽獎算法詳細文檔
(https://files.cnblogs.com/files/kkyblog/%E5%9F%BA%E7%A1%80%E5%8A%9F%E8%83%BD%E7%AE%97%E6%B3%95.pdf)**
七、附加功能實現
- 自動爬取聊天記錄功能:無
- 對聊天記錄進行分析與挖掘:無
- 獲獎名單海報生成,但不能自動分享。
- 鼓勵有想法且有用的功能:應該是無吧。
八、遇到的困難及解決方法
蘇路明
- 遇到的困難和問題:沒有極速開發經驗,團隊技能不一,開發技能不足
- 解決方法:了解題意,根據隊員技能情況分工,開發硬鋼
- 吐槽:有壓力才有動力,然而這原本一早上的任務也太重了吧,一早上的課就變成一早上一晚上了,要考試了啊... 原本以為只有一早上,所以求穩選擇了python作為團隊開發語言,早知道會推遲,肯定選取其他大家都比較有接觸過的開發語言呀,導致團隊開發力量後期不足。
陳瀚霖
- 遇到的困難和問題:第一次遇到這種實際應用的功能的算法 有點束手無措。
- 解決方法:和同學合作解決。
- 吐槽:都是全新的挑戰太累了。
程曉紅
- 遇到的困難和問題:與其他部分的參數傳遞
- 解決方法:在算法設計環節主要的解決方法是查閱了網上的算法之後,再和隊友一起討論。在算法設計之初沒有嚴密的定義各部分接口之間傳遞參數的格式,再後面完善的過程中,算法經歷了重構,比較費時。
- 吐槽:如果對編程的愛多一點點,那麽就不會那麽難過。
葉一帆
- 遇到的困難和問題:遇到python tkinter 可視化界面不提供日期控件
- 解決方法:只好妥協,用其他方式代替達到差不多的效果
- 吐槽:如果早知道會推遲時間,就做web服務了
何家健
- 遇到的困難和問題:一開始不知道具體用什麽算法來解決有點手足無措。
- 解決方法:百度看了別人的算法,再加上跟同學討論。
- 吐槽:算法基本都大同小異。
黃海潮
- 遇到的困難和問題:設計抽獎算法的時,不同人數和分等獎品的設計,算法沒辦法全部適用。
- 解決方法:關於在qq和微信群的人數得出人數限制,考慮到算法中重新解決設計。
- 吐槽:實際應用的算法設計,時間不夠,考慮不夠周全。
王錦揚
- 遇到的困難和問題:海報以及原型的設計會考慮多種格式,在這方面挺糾結的。
- 解決方法:經過詳細討論最後選出確定的方案。
- 吐槽:如果能回到過去,那麽我不會選這課了。
鄭孔宇
- 遇到的困難和問題:如何使用python對數據挖掘分析。
- 解決方法:百度一下啥都有。
- 吐槽:wordcloud這個庫有毒,下載後又說其他庫不行,單獨調用又可以,而且庫下載速度忒慢了,最後還沒完成附加功能2部分,只能淪落到寫博客,我崩潰了。
俞凱欣
- 遇到的困難和問題:負責了做獲獎海報和抽獎界面的原型設計,圖片的分辨率問題傳給前端不方便寫進GUI界面。
- 解決方法:用PS改了圖片分辨率。
- 吐槽:如果時間再長一點,那麽可能做得更好!
林世傑
- 遇到的困難和問題:python不熟悉。
- 解決方法:百度啊。
- 吐槽:這個遊戲太秀了,直接從零開始學習py,語法一堆出錯。
九、個人部分
- 個人PSP表格
PSP2.1 | Personal Software Process Stages | 預估耗時(分鐘) | 實際耗時(分鐘) |
Planning | 計劃 | 40 | 45 |
· Estimate | · 估計這個任務需要多少時間 | 40 | 45 |
Development | 開發 | 380 | 450 |
· Analysis | · 需求分析 (包括學習新技術) | 30 | 40 |
· Design Spec | · 生成設計文檔 | 0 | 0 |
· Design Review | · 設計復審 (和同事審核設計文檔) | 0 | 0 |
· Coding Standard | · 代碼規範 (為目前的開發制定合適的規範) | 0 | 0 |
· Design | · 具體設計 | 40 | 90 |
· Coding | · 具體編碼 | 280 | 280 |
· Code Review | · 代碼復審 | ||
· Test | · 測試(自我測試,修改代碼,提交修改) | 30 | 40 |
Reporting | 報告 | 40 | 55 |
· Test Report | · 測試報告 | 20 | 30 |
· Size Measurement | · 計算工作量 | 10 | 15 |
· Postmortem & Process Improvement Plan | · 事後總結, 並提出過程改進計劃 | 10 | 10 |
合計 | 460 |
- 學習進度表
第N周 | 新增代碼(行) | 累計代碼(行) | 本周學習耗時(小時) | 累計學習耗時(小時) | 重要成長 |
1 | 300 | 300 | 8 | 8 | 入門Visual studio的使用(包括單元測試) |
2 | 0 | 300 | 6 | 14 | 了解正則表達式的使用 |
3 | 0 | 300 | 10 | 24 | 加深掌握了Axure的使用,學會了使用NABCD模型進行需求分析 |
4 | 500 | 800 | 36 | 60 | 加強了python/java爬蟲基礎,在java代碼方面有很大的提升,解除了數據分析和可視化設計 |
5 | 0 | 800 | 10 | 70 | 競品分析 |
6 | 0 | 800 | 12 | 82 | UML設計,需求收集 |
7 | 0 | 800 | 10 | 92 | 需求分析,思維導圖設計 |
8 | 150 | 950 | 22 | 114 | 團隊現場編程,收驗團隊成果,思考與改善整體架構 |
福大軟工1816 · 團隊現場編程實戰(抽獎系統)之 拖鞋旅遊隊