06组-选题与需求分析报告

06组队长

一、团队集结

团队介绍

团队名字：什么都队
团队口号：啊对对对

1.1队员风采

陈孟琪
风格：小事靠谱大事摆烂
擅长的技术：前端
编程的兴趣：前端
希望的软工角色：前端
宣言：尽量不拖后腿

崔佳雪
风格：听队长指挥让我做啥我做啥
擅长的技术：美工
编程的兴趣：C语言
希望的软工角色：页面设计
宣言：软工冲鸭！

李雅萍
风格：佛系的ddl选手
擅长的技术：学过C，C++等编程语言，但也不是特别擅长（擅长熬夜），有较强的团队意识，良好的沟通能力
编程的兴趣：做有趣且有用的项目
希望的软工角色：前端
宣言：杀不死你的，只会让你变得更加强大

陈雅勤
风格：喜静
擅长的技术：后端
编程的兴趣：后端
希望的软工角色：后端
宣言：尽力而为！

郑慧昕
风格：拖延症晚期
擅长的技术：前/后端都不擅长
编程的兴趣：一般般
希望的软工角色：前端开发
宣言：加油过软工

王家炜
风格：想到什么做什么
擅长的技术：C、Java
编程的兴趣：Unity
希望的软工角色：希望能做摆子（但是不可能）
宣言：一直只为自己的人，很难走下去

黄智勇
风格：实干理想家
擅长的技术：C、java、后端（在学习）
编程的兴趣：目的导向型
希望的软工角色：后端
一句话宣言：热爱生活，活着
个人博客链接：种菜阿公 - 博客园

朱天祥
风格：简洁明快
擅长的技术：会我即将学会的，擅长我即将擅长的
编程的兴趣：java，数据库
希望的软工角色：后端
宣言：el psy kongroo

林灿坤
风格：给各位大佬打杂
擅长的技术：只对C，C++熟，其他处于了解状态
编程的兴趣：都行，只要不忙都有兴趣
希望的软工角色：负责部分后端
宣言：不摆烂就是胜利

1.2团队特色描述

• 尊重每一位成员的意见，让每一个人都参与进来。大家共同努力，拒绝当摆子。
• 男女搭配干活不累：我们团队是一个男女混合团队，由4男5女构成，每个人都充分发挥自己的能力。

1.3团队logo

1.4团队合照

二、开始行动

2.1团队完成的项目

很多同学每次到饭点在纠结吃什么，所以我们搭建了一个干饭小程序，能让大家知道饭堂有什么吃的。

2.2个人贡献分说明

我们的团队模式偏向团队的模式，没有突出代码能力。但每个成员都具备着不同能力，互相协作。所以打算从工作的困难程度和复杂程度进行评分，不单单从代码量和效率来评估成员的贡献程度，我们从花费的脑力，体力，时间等方面进行辅助再加上大家的同意去决定。
我们团队定期开会讨论并拆分任务，重点是将任务细分成一个一个点，然后将任务分配给团队中的每一个人，个人贡献分按每个人完成的工作量、该工作占最终得分的比例、每个人队该工作的完成度以及参与的积极性与热情度来进行分配。

姓名	工作贡献	贡献比例
王家炜	任务分配、博客编写、讨论选题、UML绘制	14%
黄智勇	答辩、博客编写、讨论选题、UML绘制	12%
郑慧昕	UML绘制	8%
陈孟琪	讨论选题	11%
崔佳雪	UML绘制	10%
李雅萍	视频制作、讨论选题、UML绘制	12%
陈雅勤	PPT制作、UML绘制	12%
林灿坤	视频制作、UML绘制	10%
朱天祥	PPT制作、logo设计	11%

三、点滴记录

3.1思维导图和燃尽图

思维导图（负责人：陈雅勤）

功能结构图（负责人：崔佳雪）

燃尽图（负责人：王家炜）

3.2组员各自负责的UML图

整体系统用例图1（用户）
负责人：陈雅勤
描述：授权用户对【吃点福大】小程序的大致使用
该部分面临的问题：授权用户如何使用该系统
解决的问题：让授权用户清晰get到对该系统的使用

整体系统用例图2（维护人员）
负责人：陈雅勤
描述：运维对【吃点福大】小程序进行维护
该部分面临的问题：运维同学如何使用该系统以及系统异常情况的处理
解决的问题：由运维同学负责查看后台日志信息，更改配置文件等等方式达到维护目的

就餐前的状态图
负责人：李雅萍
描述：就餐前用户点击进入小程序界面，经统计评价得到的热门餐厅和菜系
面临的问题：用户不知道吃什么，热门推荐可能无法兼顾每个人的口味
解决的问题：多种推荐机制，有热门窗口直接推荐和可以进入今日吃什么随机生成进行推荐以及根据用户的口味自动生成推荐的三个菜品。可以通过查看菜品详情来获得菜品的星级

就餐后的状态图
负责人：李雅萍
描述：就餐后用户登录小程序对菜品进行评价和反馈
面临的问题：无法清楚用户是否是恶意评价和反馈
解决的问题：利用窗口保护机制对用户反馈评星进行评价其可靠性

评价控制的活动图
负责人：李雅萍
描述：每个人每天的评论数量是有限制的
面临的问题：防止用户短时间内多次刷评论
解决的问题：记录用户每天的评论数量，超过单个用户最多评论数量则评价失败

菜品加入我的喜欢活动图
负责人：李雅萍
描述：用户对菜品喜欢，进行加入我的喜欢操作
面临的问题：是否会误触把不喜欢的菜品加入【我的喜欢】
解决的问题：在【我的喜欢】中更加直观看见喜欢的菜品

云图标签推荐的活动图
负责人：李雅萍
描述：用户根据云图标签获得菜品推荐
面临的问题：部分菜品与推荐的标签可能存在不符合的情况
解决的问题：应用了用户反馈机制，后台通过用户反馈信息修改菜品标签解决标签与菜品不符问题

我的页面活动图
负责人：李雅萍
描述：用户在我的页面可以实现的操作，进行用户反馈，查看我的喜欢和我的收藏
面临的问题：用户怎么知道自己是否反馈成功
解决的问题：回复用户该反馈是否采纳

用户详情页面的活动图
负责人：李雅萍
描述：用户根据自己的喜好选择标签设置偏好和忌口
面临的问题：标签不够全面，用户不知道从哪里进去该界面
解决的问题：应用了用户反馈机制，用过用户反馈的信息添加缺少的标签，进行提示

今天吃什么活动图
负责人：李雅萍
描述：随机为用户推荐今日吃什么
面临的问题：随机推荐有可能是用户不喜欢的菜品
解决的问题：用户选择困难症，不知道去哪吃，吃什么

店家保护机制触发的活动图
负责人：崔佳雪
描述：【店家保护】的触发
该部分面临的问题：如何防止大批恶意用户刷评价
解决的问题：我们引入【店家保护】的概念，当触发异常条件，便执行该模块

店家保护机制的活动图
负责人：崔佳雪
描述：【店家保护】主要是针对恶意用户的
该部分面临的问题：大批恶意用户刷评价
解决的问题：开启【店家保护】机制，当系统检测到某店家的评价在短期内大量增加，将该店家判定为异常店家，开启保护，再次收到相同评价，直接返回评价失败

推荐三道菜的活动流程图
负责人：崔佳雪
描述：根据标签快速筛选出大多用户【点赞】过的菜品
该部分面临的问题：用户选择好标签后，如何把点赞度高的菜品推荐给用户
解决的问题：把每条标签下各个菜品的点赞数查出来，从点赞数高于一定值的菜品中随机抽出三道菜品显示在【推荐三道菜】页面

原型图（部分1）
负责人：陈孟琪
描述：用户使用界面
面临问题：设计风格，还有如何去让前端和后端建立链接
解决问题：能大致明确所实现出来的页面

原型图（部分2）
负责人：林灿坤
描述：用户使用界面
面临问题：设计风格，还有如何去让前端和后端建立链接
解决问题：能大致明确所实现出来的页面

E-R图
负责人：王家炜
描述：展现实体之间的关系，以及实体的属性
该部分面临的问题：实体较多，关系难以理清。还有实现的难度很难预估解决的问题：理清了实体间的关系

实体类图
负责人：黄智勇
描述：实体类的设计与实体间的关系
该部分面临的问题：怎么对现实世界做出抽象并且与库表建立联系
解决的问题：明白所建立的对象的关系

3.3学习进度条

第N周	新增代码（行）	累计代码（行）	本周学习耗时（小时）	累计学习耗时（小时）	重要成长
1	0	0	6	6	团队协作，完成分配给自己的任务
2	0	0	6	12	学习了JS的一些语法，对要实现项目的方法有了一定的认识

3.4心得体会

• UML设计工具的选择、选择的理由和使用后对工具的评价

  • UML设计工具：墨刀

  • 选择的理由：本来用的电脑自带的画图功能绘制的UML图，发现存在很多弊端，二维图形和线条有限，并且画上以后不便调整，后面修改只能擦除重画不能移动位置。有小组成员使用过墨刀这个工具，所以尝试了一下。

  • 使用后对工具的评价：在绘制流程图思维导图方面比电脑自带的画图要方便很多，直接点击插入同级/子主题即可，修改也很方便。但是如果绘制的UML图规模较大、内容较多的话字体会变得很小，看起来很模糊，并且背景有水印。

• 本次任务遇到的困难及解决方法（例：困难描述/做过哪些尝试/是否解决/有何收获）

  • 遇到的困难：和组员的交流有些少，在完成功能结构图的绘制时每个人的理解不同，在功能设计方面意见不太统一，做了好多次修改。

  • 解决方法：根据不同人的想法我分别绘制了不同的功能结构图，后面开会的时候经过大家的商量决定选用哪张图。

四、视频短片

哔哩哔哩