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图
负责人:王家炜
描述:展现实体之间的关系,以及实体的属性
该部分面临的问题:实体较多,关系难以理清。还有实现的难度很难预估
解决的问题:理清了实体间的关系
实体类图
负责人:黄智勇
描述:实体类的设计与实体间的关系
该部分面临的问题:怎么对现实世界做出抽象并且与库表建立联系
解决的问题:明白所建立的对象的关系
![实体类图](https://gitee.com/soya-hzy/pic/raw/master/images/20221029183513.png)
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的制作更加娴熟,对整体项目也有了更为清楚的认知
四、视频短片