团队现场编程

一、组员职责分工及贡献分

学号	成员	分工	贡献分
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/基础功能算法.pdf)**

七、附加功能实现

• 自动爬取聊天记录功能：无
• 对聊天记录进行分析与挖掘：无
• 获奖名单海报生成，但不能自动分享。
  
• 鼓励有想法且有用的功能：应该是无吧。

八、遇到的困难及解决方法

• 苏路明

  • 遇到的困难和问题：没有极速开发经验，团队技能不一，开发技能不足
  • 解决方法：了解题意，根据队员技能情况分工，开发硬钢
  • 吐槽：有压力才有动力，然而这原本一早上的任务也太重了吧，一早上的课就变成一早上一晚上了，要考试了啊... 原本以为只有一早上，所以求稳选择了python作为团队开发语言，早知道会推迟，肯定选取其他大家都比较有接触过的开发语言呀，导致团队开发力量后期不足。

• 陈瀚霖

  • 遇到的困难和问题：第一次遇到这种实际应用的功能的算法 有点束手无措。
  • 解决方法：和同学合作解决。
  • 吐槽：都是全新的挑战太累了。

• 程晓红

  • 遇到的困难和问题：与其他部分的参数传递
  • 解决方法：在算法设计环节主要的解决方法是查阅了网上的算法之后，再和队友一起讨论。在算法设计之初没有严密的定义各部分接口之间传递参数的格式，再后面完善的过程中，算法经历了重构，比较费时。
  • 吐槽：如果对编程的爱多一点点，那么就不会那么难过。

• 叶一帆

  • 遇到的困难和问题：遇到python tkinter 可视化界面不提供日期控件
  • 解决方法：只好妥协，用其他方式代替达到差不多的效果
  • 吐槽：如果早知道会推迟时间，就做web服务了

• 何家健

  • 遇到的困难和问题：一开始不知道具体用什么算法来解决有点手足无措。
  • 解决方法：百度看了别人的算法，再加上跟同学讨论。
  • 吐槽：算法基本都大同小异。

• 黄海潮

  • 遇到的困难和问题：设计抽奖算法的时，不同人数和分等奖品的设计，算法没办法全部适用。
  • 解决方法：关于在qq和微信群的人数得出人数限制，考虑到算法中重新解决设计。
  • 吐槽：实际应用的算法设计，时间不够，考虑不够周全。

• 王锦扬

  • 遇到的困难和问题：海报以及原型的设计会考虑多种格式，在这方面挺纠结的。
  • 解决方法：经过详细讨论最后选出确定的方案。
  • 吐槽：如果能回到过去，那么我不会选这课了。

• 郑孔宇

  • 遇到的困难和问题：如何使用python对数据挖掘分析。
  • 解决方法：百度一下啥都有。
  • 吐槽：wordcloud这个库有毒，下载后又说其他库不行，单独调用又可以，而且库下载速度忒慢了，最后还没完成附加功能2部分，只能沦落到写博客，我崩溃了。

• 俞凯欣

  • 遇到的困难和问题：负责了做获奖海报和抽奖界面的原型设计，图片的分辨率问题传给前端不方便写进GUI界面。
  • 解决方法：用PS改了图片分辨率。
  • 吐槽：如果时间再长一点，那么可能做得更好！

• 林世杰

  • 遇到的困难和问题：python不熟悉。
  • 解决方法：百度啊。
  • 吐槽：这个游戏太秀了，直接从零开始学习py，语法一堆出错。

九、个人部分

• 个人PSP

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	15	25
· Estimate	· 估计这个任务需要多少时间	220	350
· Development	开发	10	10
· Analysis	· 需求分析 (包括学习新技术)	10	10
· Design Spec	· 生成设计文档	30	30
· Design Review	· 设计复审 (和同事审核设计文档)	15	20
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	0	0
· Design	· 具体设计	40	60
· Coding	· 具体编码	0	0
· Code Review	· 代码复审	0	0
· Test	· 测试（自我测试，修改代码，提交修改）	0	0
· Reporting	报告	0	0
· Test Report	· 测试报告	0	0
· Size Measurement	· 计算工作量	0	0
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	10	10
	合计		515

【学习进度条】

第N周	新增代码(行)	累计代码(行)	本周学习耗时(小时)	累计学习耗时(小时)	重要成长
1	0	0	18.5	18.5	熟悉Axure的使用方法、对软件的原型设计有了更深刻的理解
2	113	113	28.5	47	对算法的构思有更多的了解
3	106	219	15	62	加深掌握了Axure的使用，学会了使用NABCD模型进行需求分析
4	211	430	18	80	认识了原型设计的重要性，学会部分原型设计的技能
5	252	692	12	92	进行logo，原型的设计与修改
6	50	742	10	102	logo，原型初步设计完成
7	190	932	30	132	logo，原型完善