第02组(51) 需求分析报告(组长)
团队基本情况
团队项目的整体计划安排
阶段序列 | 阶段预估时间 | 主要阶段任务 | 完成情况 |
---|---|---|---|
第一阶段 | 9.21-10.5 | 团队成立 | 已完成 |
第二阶段 | 10.6-10.22 | 课题选择以及团队任务分配商定 | 已完成 |
第三阶段 | 10.23-11.1 | 完成需求文档和产品分析 | 已完成 |
第四阶段 | 11.2-11.8 | 完成第一个增量计划的编码、测试 | 未开始 |
第五阶段 | 11.9-11.15 | 对第一个增量计划进行交付和反馈,同时对第二个增量计划进行小组讨论和策划建模 | 未开始 |
第六阶段 | 11.15-11.16 | 完成第二个增量计划的编码和测试 | 未开始 |
第七阶段 | 11.16-11.20 | 对第二个增量计划进行交付和反馈,同时对第三个增量计划进行小组讨论和策划建模 | 未开始 |
第八阶段 | 11.21-11.27 | 完成第三个增量计划的编码和测试、同时项目的最终产品诞生 | 未开始 |
第九阶段 | 11.28-11.30 | 项目优化 | 未开始 |
第十阶段 | 11.30-最终 DDL | 完成文档、PPT 的制作 | 未开始 |
团队分工和个人贡献比
团队具体分工
队员名字 | 分工 | 详细事项 |
---|---|---|
吴仕涛 | 文档 任务调配 原型 | 小组组长,负责产品的文档,任务调配,原型实现 |
苏炜杰 | 前端 | 前端负责人,开发环境搭建,微信小程序部署,编写前端页面和逻辑,辅助完成原型 |
李志炜 | 后端 | 后端服务层的业务逻辑实现,工具类的接口设计及实现 |
王祺 | 后端 | 后端负责人,后端框架的设计和搭建,与 DBA 共同完成实体类的设计与实现,以及最终后端工程项目的部署 |
王佳欣 | 前端 | 编写前端页面和逻辑,前端测试部分 |
林怡琳 | 前端 | 编写前端页面和逻辑,前端 mock 数据编写 |
沈帅 | 前端 | 编写前端页面和逻辑,辅助文档制作 |
高逸超 | 后端 | 后端服务层的业务逻辑实现,工具类的接口设计及实现 |
邹薇 | 后端 | 后端持久层代码的编写,主要是对数据进行增删改查,以及与数据库的对接 |
林逸丽 | 后端 | 后端控制层的逻辑编写,做好页面跳转的路由以及过滤、转发 |
傅兴佳 | 后端 | 负责数据库的建立、管理,编写相应的存储过程、事务,以及后端业务逻辑 |
本次个人贡献比
姓名 | 本次作业完成的内容 | 成绩占比 |
---|---|---|
吴仕涛 | 组织会议,PPT 介绍,设计原型,原型视频出演,部分文档,答辩问答 | 14% |
苏炜杰 | 前端搭建,部分文档,部分 UML | 8% |
王祺 | 后端框架初步搭建,8 张 UML,视频后期的剪辑制作,丁香园 2 楼菜单收集 | 13% |
沈帅 | 部分文档,玫瑰园二楼菜单收集,原型视频出演,部分 uml 图(2 张) | 9% |
李志炜 | 部分文档,原型视频拍摄,紫荆园菜单收集 | 10% |
林逸丽 | 1 张 UML 图,部分文档 | 1% |
林怡琳 | 制作 PPT,京元的菜单收集 | 8% |
王佳欣 | 制作 PPT,丁香一楼的菜单收集 | 8% |
高逸超 | 部分文档,视频出演,教工菜单收集 | 8% |
傅兴佳 | 4 张 UML,后端数据库的设计与搭建,表的设计与创建,朝阳餐厅的菜单收集 | 10% |
邹薇 | 5 张 UML 图,部分文档,玫瑰一楼的菜单收集 | 11% |
思维导图和燃尽图
-
项目思维导图
-
功能结构图
-
燃尽图
小练习
后端系统框图
-
负责人:王祺
-
描述:我们使用的是分层分工法
-
该部分面临的问题:按模块功能分工需要每个成员了解各个层次的业务逻辑,学习成本偏高
-
解决的问题:我们直接使用分层法,持久层的就专门与数据库交互做 CRUD,服务层专门搞业务逻辑,控制层专门做转发、重定向、过滤等,与前端接口交互
实体层类图
-
负责人:王祺
-
描述:实体类的设计与实体间的关系
-
该部分面临的问题:怎么对现实世界做出抽象并且与库表建立联系
-
解决的问题:反向设计,由库表推实体类,结合 ORM 的特性来设计实体类
【吃点儿啥】整体系统用例图 1(使用者为授权用户)
-
负责人:王祺
-
描述:授权用户对【吃点儿啥】小程序的大致使用
-
该部分面临的问题:授权用户如何使用该系统
-
解决的问题:让授权用户清晰 get 到对该系统的使用
【吃点儿啥】整体系统用例图 2(使用者为运维同学)
-
负责人:王祺
-
描述:运维对【吃点儿啥】小程序进行维护
-
该部分面临的问题:运维同学如何使用该系统以及系统异常情况的处理
-
解决的问题:由运维同学负责查看后台日志信息,更改配置文件等等方式达到维护目的
评价控制的活动图
-
负责人:王祺
-
描述:每个人每天的评论数量是有限制的
-
该部分面临的问题:防止单个用户短时间内多次刷评论
-
解决的问题:记录用户当天的评论数量,超额则不予评价通过
窗口保护机制触发的活动图
-
负责人:王祺
-
描述:【窗口保护】的触发
-
该部分面临的问题:该如何防止大批恶意用户刷评论
-
解决的问题:我们引入【窗口保护】的概念,当触发异常条件,便执行该模块
窗口保护机制的活动图
-
负责人:王祺
-
描述:【窗口保护】主要是针对恶意用户的
-
该部分面临的问题:大批恶意用户刷评论
-
解决的问题:开启【窗口保护】机制,当系统检测到某窗口的评论在短期内大量增加,将该窗口判定为异常窗口,开启保护,再次收到相同评价,直接返回评价失败
菜品星级评算的活动流程图
-
负责人:王祺
-
描述:用户对菜品做出星级评价,达到一定星级加入我的爱心
-
该部分面临的问题:菜品星级如何评算,怎样才算是把菜品加入【我的爱心】
-
解决的问题:把每条评价查出来,重新加权计算星级并作显示
云图标签推荐的活动图
-
负责人:邹薇
-
描述:用户根据云图标签获得菜品推荐
-
该部分面临的问题:部分菜品与推荐的标签不符合
-
解决的问题:应用了用户反馈机制,后台通过用户反馈信息修改菜品标签解决标签与菜品不符问题
我的页面活动图
-
负责人:邹薇
-
描述:用户在我的页面可以实现的操作,进行用户反馈,查看爱心和收藏
-
该部分面临的问题:用户怎么知道自己是否反馈成功
-
解决的问题:回复用户该反馈是否采纳
用户页面的活动图
-
负责人:邹薇
-
描述:用户根据自己喜好选择标签设置偏好和忌口
-
该部分面临的问题:标签不够全面,用户不知道从哪里进入到该页面
-
解决的问题:应用了用户反馈机制,通过用户反馈的信息适当增加标签,进行提示
就餐前的状态图
-
负责人:邹薇
-
描述:就餐前用户登录小程序获得心仪的菜推荐
-
该部分面临的问题:用户不知道去哪里吃,吃什么,好不好吃
-
解决的问题:多种推荐机制,有热门窗口直接推荐和可以进入云图更据选择菜品标签进行推荐。可以通过查看菜品详情来获得菜品的星级
就餐后的状态图
-
负责人:邹薇
-
描述:就餐后用户登录小程序对菜品进行评星和反馈
-
该部分面临的问题:无法判断用户是否为恶意评星和反馈
-
解决的问题:利用窗口保护机制对对用户反馈觉评星进行评价其可靠性
持久层类图
-
负责人:傅兴佳
-
描述:展现实体类间的关系,以及提供了与数据库交互的接口
-
该部分面临的问题:需要与数据库交互的功能较多
-
解决的问题:清晰的描述了用于增删改查的接口
ER 图
-
负责人:傅兴佳
-
描述:展现实体之间的关系,以及实体的属性
-
该部分面临的问题:实体较多,关系难以理清
-
解决的问题:理清了实体间的关系
【吃点儿啥】页面跳转流程图
● 负责人:林逸丽
● 描述:在授权后进入首页,选择搜索或者筛选云图,还有我的主页。在搜索和筛选后会出现窗口或者菜品,其中点击窗口会出现地图指引。我的主页中包含爱心窗口、收藏窗口、用户界面。
● 该部分面临的问题:页面跳转
● 解决的问题:基本要有的页面已经理清
【吃点儿啥】反馈用例图
● 负责人:沈帅
● 描述:用户可以在反馈页面反馈信息,运维人员在检查完反馈信息后决定成功和丢弃
● 该部分面临的问题:用户不知道反馈流程
● 解决的问题:清晰的描绘了反馈流程
【吃点儿啥】用户信息用例图
● 负责人:沈帅
● 描述:在授权后进入用户界面,可以修改个人信息,如头像,昵称,口味等
● 该部分面临的问题:用户修改头像想用自定义图片
● 解决的问题:用户头像为微信头像,可以修改微信头像改变头像。
前端登陆部分
- 负责人:苏炜杰
- 描述:前端登陆部分包括,请求用户授权,使用微信小程序 api 获取登陆 code 传给后端,最终获取 userId 完成登陆.用户退出登陆后返回未登录状态,定时检查登录信息,诺失效需要重新登陆.
- 该部分面临的问题:登陆状态的时序问题
- 解决的问题:
使用 async await promise 用同步的方式编写异步代码,整理登陆状态
- 附:
服务层类图
-
负责人:傅兴佳
-
描述:展现服务层的接口
-
该部分的问题:服务层接口在类之间的分配
-
解决的问题:清楚的分配了每个类应实现的功能
控制层类图
-
负责人:傅兴佳
-
描述:展现所有页面可以跳转的页面
-
该部分面临的问题:页面跳转逻辑混乱
-
解决的问题:清晰的描述了页面的跳转逻辑
作业记录相关
UML 设计工具的选择、选择的理由和使用后对工具的评价
- 选择 draw.io 选择的原因是可以保存到 github,或者提取 github 的 draw.io 文件,方便共享。大家觉得很方便,可以免费在线使用,方便导入。
遇到的困难及解决方法
- uml 不会画,通过网上学习和询问队友才掌握
- 拍摄原型视频时各有想法,最后经过组长开会总结,确定视频
学习进度条
第 N 周 | 新增代码 | 累计代码(行) | 本周学习耗时(小时) | 累计学习耗时(小时) | 重要成长 |
---|---|---|---|---|---|
第一周 | 695 | 695 | 146 | 146 | 学习 swagger api 的使用,java,javascript,react,typescript,taro,springboot的学习,使用 taro 搭建前端项目 |
第二周 | 316 | 1011 | 173 | 319 | uml 工具 draw.io 的使用,使用 springboot 搭建后端项目 |
PSP 表格
Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|
Planning(计划) | 250 | 250 |
Estimate(估计时间) | 230 | 230 |
Development(开发) | 320 | 320 |
Analysis(需求分析(包括学习新技术)) | 30 | 30 |
Design Spec(生成设计文档) | 220 | 220 |
Design Review(设计复审) | 30 | 30 |
Coding Standard(代码规范 ) | 0 | 0 |
Design(具体设计) | 0 | 0 |
Coding(具体编码) | 0 | 0 |
Code Review(代码复审) | 0 | 0 |
Test(测试(自我测试,修改代码,提交修改)) | 0 | 0 |
Reporting(报告) | 120 | 140 |
Test Report(测试报告) | 125 | 125 |
Size Measurement(计算工作量) | 10 | 15 |
Postmortem & Process Improvement Plan(事后总结, 并提出过程改进计划) | 0 | 0 |
Total(合计) | 670 | 680 |