團隊現場程式設計

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

學号	成員	分工	貢獻分
031602428	蘇路明	整合代碼，抽獎算法實作部分	12
031602401	陳瀚霖	設計算法、文案	8
031602406	程曉宏	提取抽獎名單
031602438	葉一帆	抽獎界面、海報界面	15
031602407	何家健		6
031602410	黃海潮
031602429	王錦揚	原型設計
031602442	鄭孔宇	撰寫部落格，思考附加需求(orz 根本沒時間實作)
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/基礎功能算法.pdf)**

七、附加功能實作

• 自動爬取聊天記錄功能：無
• 對聊天記錄進行分析與挖掘：無
• 獲獎名單海報生成，但不能自動分享。

  

• 鼓勵有想法且有用的功能：應該是無吧。

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

• • 遇到的困難和問題：沒有極速開發經驗，團隊技能不一，開發技能不足
  • 解決方法：了解題意，根據隊員技能情況分工，開發硬鋼
  • 吐槽：有壓力才有動力，然而這原本一早上的任務也太重了吧，一早上的課就變成一早上一晚上了，要考試了啊... 原本以為隻有一早上，是以求穩選擇了python作為團隊開發語言，早知道會推遲，肯定選取其他大家都比較有接觸過的開發語言呀，導緻團隊開發力量後期不足。

• • 遇到的困難和問題：第一次遇到這種實際應用的功能的算法 有點束手無措。
  • 解決方法：和同學合作解決。
  • 吐槽：都是全新的挑戰太累了。

• 程曉紅

  • 遇到的困難和問題：與其他部分的參數傳遞
  • 解決方法：在算法設計環節主要的解決方法是查閱了網上的算法之後，再和隊友一起讨論。在算法設計之初沒有嚴密的定義各部分接口之間傳遞參數的格式，再後面完善的過程中，算法經曆了重構，比較費時。
  • 吐槽：如果對程式設計的愛多一點點，那麼就不會那麼難過。

• • 遇到的困難和問題：遇到python tkinter 可視化界面不提供日期控件
  • 解決方法：隻好妥協，用其他方式代替達到差不多的效果
  • 吐槽：如果早知道會推遲時間，就做web服務了

• • 遇到的困難和問題：一開始不知道具體用什麼算法來解決有點手足無措。
  • 解決方法：百度看了别人的算法，再加上跟同學讨論。
  • 吐槽：算法基本都大同小異。

• • 遇到的困難和問題：設計抽獎算法的時，不同人數和分等獎品的設計，算法沒辦法全部适用。
  • 解決方法：關于在qq和微信群的人數得出人數限制，考慮到算法中重新解決設計。
  • 吐槽：實際應用的算法設計，時間不夠，考慮不夠周全。

• • 遇到的困難和問題：海報以及原型的設計會考慮多種格式，在這方面挺糾結的。
  • 解決方法：經過詳細讨論最後選出确定的方案。
  • 吐槽：如果能回到過去，那麼我不會選這課了。

• • 遇到的困難和問題：如何使用python對資料挖掘分析。
  • 解決方法：百度一下啥都有。
  • 吐槽：wordcloud這個庫有毒，下載下傳後又說其他庫不行，單獨調用又可以，而且庫下載下傳速度忒慢了，最後還沒完成附加功能2部分，隻能淪落到寫部落格，我崩潰了。

• • 遇到的困難和問題：負責了做獲獎海報和抽獎界面的原型設計，圖檔的分辨率問題傳給前端不友善寫進GUI界面。
  • 解決方法：用PS改了圖檔分辨率。
  • 吐槽：如果時間再長一點，那麼可能做得更好！

• • 遇到的困難和問題：python不熟悉。
  • 解決方法：百度啊。
  • 吐槽：這個遊戲太秀了，直接從零開始學習py，文法一堆出錯。

九、個人部分

• 個人PSP

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

【學習進度條】

第N周	新增代碼(行)	累計代碼(行)	本周學習耗時(小時)	累計學習耗時(小時)	重要成長
1	18.5		熟悉Axure的使用方法、對軟體的原型設計有了更深刻的了解
2	113		28.5	47	對算法的構思有更多的了解
3	106	219		62	加深掌握了Axure的使用，學會了使用NABCD模型進行需求分析
4	211	430	18	80	認識了原型設計的重要性，學會部分原型設計的技能
5	252	692		92	進行logo，原型的設計與修改
	50	742		102	logo，原型初步設計完成
7	190	932		132	logo，原型完善