6组 团队展示
一、团队集结
团队介绍：
团队名字：什么都队
团队口号：啊对对对
1.1 队员风采：
陈孟琪
风格：小事靠谱大事摆烂
擅长的技术：前端
编程的兴趣：前端
希望的软工角色：前端
宣言：尽量不拖后腿
李雅萍
风格：佛系的ddl选手
擅长的技术：学过C，C++等编程语言，但也不是特别擅长(擅长熬夜ahhhhhh，编程能力 较弱，有较强的团队意识，良好的沟通能力
编程的兴趣：做有趣且有用的项目
希望的软工角色：前端
宣言：杀不死你的，只会让你变得刚加强大
陈雅勤
风格：喜静
擅长的技术：后端
编程的兴趣：后端
希望的软工角色：后端
宣言：尽力而为！
郑慧昕
风格：拖延症晚期
擅长的技术：前/后端都不擅长
编程的兴趣：一般般
希望的软工角色：前端开发
宣言：加油过软工
崔佳雪
风格：听队长指挥让我做啥我做啥
擅长的技术：美工
编程的兴趣：c语言
希望的软工角色：页面设计
宣言：软工冲鸭！
王家炜
风格：想到什么做什么
擅长的技术：java、C++
编程的兴趣：Unity
希望的软工角色：希望能做摆子（但是不可能）
宣言：一直只为自己的人，很难走下去
黄智勇
风格：实干理想家
擅长的技术：C、JAVA、后端（在学习）
编程的兴趣：目的导向型
希望的软工角色：后端
一句话宣言：热爱生活，活着
个人博客链接：种菜阿公 - 博客园
朱天祥
风格：简洁明快
擅长的技术：会我即将学会的，擅长我即将擅长的
编程的兴趣：java，数据库
希望的软工角色：后端
宣言：el psy kongroo
林灿坤
风格：给各位大佬打杂
擅长的技术：只对c，c++熟，其他处于了解状态
编程的兴趣：都行，只要不忙都有兴趣
希望的软工角色：负责部分后端
宣言：不摆烂就是胜利
1.2 团队特色描述
-
尊重每一位成员的意见，让每一个人都参与进来。每个人都是队里面独一无二的星星。大家共同努力，拒绝当摆子。
-
男女搭配干活不累：我们团队是一个男女混合团队，由4男5女构成，队伍中每个人都各司其职，每个人都充分发挥自己的能力。
1.3 团队logo
1.4 团队合照
二、开始行动
2.1 团队完成的项目
为了更好让大家能在福大（旗山校区）干饭，我们搭建了一个干饭小程序，能让大家知道饭堂有什么吃的。
2.2 个人贡献分说明
我们的团队模式偏向团队的模式，没有突出代码能力。但每个成员都具备着不同能力，互相协作。所以打算从工作的困难程度和复杂程度进行评分，不单单从代码量和效率来评估成员的贡献程度，我们从花费的脑力，体力，时间等方面进行辅助再加上大家的同意去决定。
我们团队定期开会讨论并拆分任务，重点是将任务细分成一个一个点，然后将任务分配给团队中的每一个人，个人贡献分按每个人完成的工作量、该工作占最终得分的比例、每个人队该工作的完成度以及参与的积极性与热情度来进行分配。
2.3 贡献比例
| 姓名 | 工作贡献 | 贡献比例 |
|---|---|---|
| 王家炜 | 任务分配、博客编写、讨论选题、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（维护人员）
负责人：陈雅勤
描述：运维对【吃点福大】小程序进行维护
该部分面临的问题：运维同学如何使用该系统以及系统异常情况的处理
解决的问题：由运维同学负责查看后台日志信息，更改配置文件等等方式达到维护目 的
就餐前的状态图
负责人：李雅萍
描述：就餐前用户点击进入小程序界面，经统计评价得到的热门餐厅和菜系
面临的问题：用户不知道吃什么，热门推荐可能无法兼顾每个人的口味
解决的问题：多种推荐机制，有热门窗口直接推荐和可以进入今日吃什么随机生成进行 推荐以及根据用户的口味自动生成推荐的三个菜品。可以通过查看菜品详情来获得菜品 的星级
就餐后的状态图
负责人：李雅萍
描述：就餐后用户登录小程序对菜品进行评价和反馈
面临的问题：无法清楚用户是否是恶意评价和反馈
解决的问题：利用窗口保护机制对用户反馈评星进行评价其可靠性
评价控制的活动图
负责人：李雅萍
描述：每个人每天的评论数量是有限制的
面临的问题：防止用户短时间内多次刷评论
解决的问题：记录用户每天的评论数量，超过单个用户最多评论数量则评价失败
菜品加入我的喜欢活动图
负责人：李雅萍
描述：用户对菜品喜欢，进行加入我的喜欢操作
面临的问题：是否会误触把不喜欢的菜品加入【我的喜欢】
解决的问题：在【我的喜欢】中更加直观看见喜欢的菜品
云图标签推荐的活动图
负责人：李雅萍
描述：用户根据云图标签获得菜品推荐
面临的问题：部分菜品与推荐的标签可能存在不符合的情况
解决的问题：应用了用户反馈机制，后台通过用户反馈信息修改菜品标签解 决标签 与菜品不符问题
我的页面活动图
负责人：李雅萍
描述：用户在我的页面可以实现的操作，进行用户反馈，查看我的喜欢和我 的收藏
面临的问题：用户怎么知道自己是否反馈成功
解决的问题：回复用户该反馈是否采纳
用户详情页面的活动图
负责人：李雅萍
描述：用户根据自己的喜好选择标签设置偏好和忌口
面临的问题：标签不够全面，用户不知道从哪里进去该界面
解决的问题：应用了用户反馈机制，用过用户反馈的信息添加缺少的标签，进行提 示
今日吃什么活动图
负责人：李雅萍
描述：随机为用户推荐今日吃什么
面临的问题：随机推荐有可能是用户不喜欢的菜品
解决的问题：用户选择困难症，不知道去哪吃，吃什么
店家保护机制触发的活动图
负责人：崔佳雪
描述：【店家保护】的触发
该部分面临的问题：如何防止大批恶意用户刷评价
解决的问题：我们引入【店家保护】的概念，当触发异常条件，便执行该模块
店家保护机制的活动图
负责人：崔佳雪
描述：【店家保护】主要是针对恶意用户的
该部分面临的问题：大批恶意用户刷评价
解决的问题：开启【店家保护】机制，当系统检测到某店家的评价在短期内大量增加，将该店家判定为异常店家，开启保护，再次收到相同评价，直接返回评价失败
推荐三道菜的活动流程图
负责人：崔佳雪
描述：根据标签快速筛选出大多用户【点赞】过的菜品
该部分面临的问题：用户选择好标签后，如何把点赞度高的菜品推荐给用户
解决的问题：把每条标签下各个菜品的点赞数查出来，从点赞数高于一定值的菜品中随机抽出三道菜品显示在【推荐三道菜】页面
E-R图
负责人：王家炜
描述：展现实体之间的关系，以及实体的属性
该部分面临的问题：实体较多，关系难以理清。还有实现的难度很难预估
解决的问题：理清了实体间的关系
实体类图
负责人：黄智勇
描述：实体类的设计与实体间的关系
该部分面临的问题：怎么对现实世界做出抽象并且与库表建立联系
解决的问题：明白所建立的对象的关系
3.3 学习进度条
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习消耗时（小时） | 累计学习消耗（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 0 | 0 | 6 | 6 | 团队协作，任务分配 |
| 2 | 0 | 0 | 6 | 12 | 学习了各种图形的画法，对要实现项目的方法有了一定的认识。 |
3.4 心得体会
- UML设计工具的选择、选择的理由和使用后对工具的评价
- UML设计工具：ProcessOn
- 选择的理由：由于之前组内有同学用过这个工具，觉得是个画UML图的好工具，就推荐给我们使用，所以大家都选择使用ProcessOn来制作UML图。这是一个在线的设计工具，不需要下载APP，可以直接在网站上操作且是免费的，可以在线画流程图、思维导图、UI原型图、UML图等等，高效易用，使用起来较为方便，支持多人实时协作，实时显示更改状态及内容的编辑
- 使用后对工具的评价：基础功能较为齐全，操作也比较人性化，由于是网页版的，不用下载app，也不占用内存，成品可以较为清晰地导出且没有水印
- 本次任务遇到的困难及解决方法（例：困难描述/做过哪些尝试/是否解决/有何收获）
- 分配任务时，认识不够全面，技术认知不清晰，分配的部分重叠，经多次小组讨论后任务分配基本清晰
- 要想制作这部分的UML，必须对算法及功能要有深入的了解，而且由于没有画过UML图，一开始不知道怎么画，通过百度看别人的博客笔记，很好地掌握了这方面的知识。通过画图，对UML的制作更加娴熟，对整体项目也有了更为清楚的认知
四、视频短片
