天天看點

福大軟工1816 · 團隊現場程式設計實戰(抽獎系統)

一、組員職責分工及貢獻分

學号 成員 分工 貢獻分
031602428 蘇路明 整合代碼,抽獎算法實作部分 12
031602401 陳瀚霖 設計算法、文案 8
031602406 程曉宏 提取抽獎名單
031602438 葉一帆 抽獎界面、海報界面 15
031602407 何家健 6
031602410 黃海潮
031602429 王錦揚 原型設計
031602442 鄭孔宇 撰寫部落格,思考附加需求(orz 根本沒時間實作)
031602439 俞凱欣 9
031602421 林世傑 使用者權重算法設計、實作 14

二、github 的送出日志截圖

  • 抽獎系統之拖鞋旅遊隊
  • 按時完成版本與逾時送出版本獨立。
  • 逾時送出部分
    福大軟工1816 · 團隊現場程式設計實戰(抽獎系統)
  • 按時送出部分
    福大軟工1816 · 團隊現場程式設計實戰(抽獎系統)

三、程式運作截圖

  • 先按照格式輸入時間資訊和其他資訊
    福大軟工1816 · 團隊現場程式設計實戰(抽獎系統)
  • 點選抽獎即可生成結果界面
    福大軟工1816 · 團隊現場程式設計實戰(抽獎系統)
  • 生成文案功能(逾時送出)
    福大軟工1816 · 團隊現場程式設計實戰(抽獎系統)

四、程式運作環境

  • 程式語言:python
  • 程式運作環境:桌面程式(可在pycharm裡直接運作)

五、GUI界面

  • 主界面
    福大軟工1816 · 團隊現場程式設計實戰(抽獎系統)
  • 獲獎名單界面
    福大軟工1816 · 團隊現場程式設計實戰(抽獎系統)
  • 生成文案界面(逾時送出)
    福大軟工1816 · 團隊現場程式設計實戰(抽獎系統)

六、基礎功能實作

  • 過濾算法:

    1.不過濾:對參與抽獎的使用者不進行過濾。

    2.普通過濾:對權重低于5的使用者進行過濾。

    3.深度過濾:對權重低于10的使用者進行過濾。

  • 采用的抽獎算法

    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.使用者去重,使用者多次發送參與同一抽獎,隻占一份名單。

  • 抽獎算法詳細文檔

七、附加功能實作

  • 自動爬取聊天記錄功能:無
  • 對聊天記錄進行分析與挖掘:無
  • 獲獎名單海報生成,但不能自動分享。
    福大軟工1816 · 團隊現場程式設計實戰(抽獎系統)
  • 鼓勵有想法且有用的功能:文案以海報方式輸出。

八、遇到的困難及解決方法

  • 遇到的困難和問題:沒有極速開發經驗,團隊技能不一,開發技能不足
  • 解決方法:了解題意,根據隊員技能情況分工,開發硬鋼
  • 吐槽:有壓力才有動力,然而這原本一早上的任務也太重了吧,一早上的課就變成一早上一晚上了,要考試了啊... 原本以為隻有一早上,是以求穩選擇了python作為團隊開發語言,早知道會推遲,肯定選取其他大家都比較有接觸過的開發語言呀,導緻團隊開發力量後期不足。
  • 遇到的困難和問題:第一次遇到這種實際應用的功能的算法 有點束手無措。
  • 解決方法:和同學合作解決。
  • 吐槽:都是全新的挑戰太累了。
  • 程曉紅
  • 遇到的困難和問題:與其他部分的參數傳遞
  • 解決方法:在算法設計環節主要的解決方法是查閱了網上的算法之後,再和隊友一起讨論。在算法設計之初沒有嚴密的定義各部分接口之間傳遞參數的格式,再後面完善的過程中,算法經曆了重構,比較費時。
  • 吐槽:如果對程式設計的愛多一點點,那麼就不會那麼難過。
  • 遇到的困難和問題:遇到python tkinter 可視化界面不提供日期控件
  • 解決方法:隻好妥協,用其他方式代替達到差不多的效果
  • 吐槽:如果早知道會推遲時間,就做web服務了
  • 遇到的困難和問題:一開始不知道具體用什麼算法來解決有點手足無措。
  • 解決方法:百度看了别人的算法,再加上跟同學讨論。
  • 吐槽:算法基本都大同小異。
  • 遇到的困難和問題:設計抽獎算法的時,不同人數和分等獎品的設計,算法沒辦法全部适用。
  • 解決方法:關于在qq和微信群的人數得出人數限制,考慮到算法中重新解決設計。
  • 吐槽:實際應用的算法設計,時間不夠,考慮不夠周全。
  • 遇到的困難和問題:海報以及原型的設計會考慮多種格式,在這方面挺糾結的。
  • 解決方法:經過詳細讨論最後選出确定的方案。
  • 吐槽:如果能回到過去,那麼我不會選這課了。
  • 遇到的困難和問題:如何使用python對資料挖掘分析。
  • 解決方法:百度一下啥都有。
  • 吐槽:wordcloud這個庫有毒,下載下傳後又說其他庫不行,單獨調用又可以,而且庫下載下傳速度忒慢了,最後還沒完成附加功能2部分,隻能淪落到寫部落格,我崩潰了。
  • 遇到的困難和問題:負責了做獲獎海報和抽獎界面的原型設計,圖檔的分辨率問題傳給前端不友善寫進GUI界面。
  • 解決方法:用PS改了圖檔分辨率。
  • 吐槽:如果時間再長一點,那麼可能做得更好!
  • 遇到的困難和問題:python不熟悉。
  • 解決方法:百度啊。
  • 吐槽:這個遊戲太秀了,直接從零開始學習py,文法一堆出錯。

九、個人部分

  • 個人PSP表格
PSP2.1 Personal Software Process Stages 預估耗時(分鐘) 實際耗時(分鐘)
Planning 計劃 40 45
· Estimate · 估計這個任務需要多少時間
Development 開發 380 450
· Analysis · 需求分析 (包括學習新技術) 30
· Design Spec · 生成設計文檔
· Design Review · 設計複審 (和同僚稽核設計文檔)
· Coding Standard · 代碼規範 (為目前的開發制定合适的規範)
· Design · 具體設計 90
· Coding · 具體編碼 280
· Code Review · 代碼複審
· Test · 測試(自我測試,修改代碼,送出修改)
Reporting 報告 55
· Test Report · 測試報告 20
· Size Measurement · 計算工作量 10
· Postmortem & Process Improvement Plan · 事後總結, 并提出過程改進計劃
合計 460