outfits_团队第二次作业github编程实战
outfits_团队第二次作业github编程实战
第一部分
项目Github地址以及项目部署在线地址
user_id | name | account | password | type_id |
---|---|---|---|---|
1 | cyh | admin | admin | 1 |
2 | whj | dd | 1111 | 4 |
3 | crj | cccccc | 2222 | 2 |
5 | lch | 666666 | 666666 | 3 |
6 | 221801210 | 13110548167 | 123456 | 4 |
7 | 1111111111 | 1111111111 | 1111111111 | 4 |
8 | 111111 | 777777 | 1111111 | 4 |
9 | 15151515 | 161616 | 141414 | 4 |
10 | 747474 | 888888 | 999999 | 4 |
11 | 222222 | 22222 | 222222 | 4 |
12 | 787878 | 787878 | 787878 | 4 |
13 | 04870487 | 15059461375 | 8456258456 | 4 |
16 | 8456258456 | 8456258456 | 8456258456 | 4 |
17 | 999999 | 999999 | 999999 | 4 |
18 | 123456 | 123 | 123456 | 4 |
21 | testtest | 123123123 | 123123 | 4 |
22 | adminnn | 18965375150 | 123456 | 4 |
组员职责分工
- 需求分析:陈雨虹(负责)
- 明确功能划分: 全体成员
- 明确用户权限: 全体成员
- 粗略分工: 陈雨虹
- 前端(包含原型):林沧海(负责)
- 原型设计
- 确认需求方向 全体成员
- 粗略设计原型模型 凌铧钦
- 框架设置
- 学习框架 林龙星 凌铧钦 邱梓洛
- 框架模板配置(包的导入) 林沧海 林龙星 凌铧钦 邱梓洛
- 代码编写
- 细分页面板块至每个负责人 林沧海 林龙星 凌铧钦
- 编写代码 林沧海 林龙星 凌铧钦 邱梓洛
- 连接模块 林沧海 凌铧钦
- 前后端交互(与后端相连)
- 接口连接 林沧海 林龙星 凌铧钦
- 接口测试 林沧海 凌铧钦
- 后端:吴晗杰(负责)
- 接口文档撰写
- 前期设计 陈雨虹 吴晗杰
- 后期修改 陈雨虹 吴晗杰
- 数据库设计
- 数据库表的设计 林子鹏 蔡瑞金 张吴晗 陈雨虹
- 接口撰写 吴晗杰 蔡瑞金 林子鹏 张海浪 张吴晗 陈雨虹
- Dao
- Controller
- Pojo
- 附加功能(翻译):邱梓洛
- 部署到服务器:林子鹏(负责)
- 代码规范: 张海浪 张吴晗
参考alibaba-java-style-guide代码规范
- 博客撰写:陈雨虹(负责)
- 格式规范 陈雨虹
- 困难与解决方法:
- 总结询问困难 陈雨虹 张吴晗 张海浪
- 解决方法 张吴晗 邱梓洛 张海浪
- 分析 陈雨虹
- 贡献度分析: 张吴晗 张海浪
- 回顾选题问题:邱梓洛
- PSP表格:张海浪
- 整合文档: 张吴晗 陈雨虹
GitHub提交日志
程序运行截图
- 登陆注册接口展示
测试用户注册登录功能.
注册用户时:账号和密码位数不能小于6位;两次密码需重复一致才能注册成功.
登录用户是:账号和密码符合数据库信息才能成功登录.- 会议主席登录界面展示
会议主席可以看各分论坛参会人数.- 秘书登陆界面展示
秘书可以浏览到各论坛参会人数展示以及详情,已发布的通知并进行添加.- 分论坛主席界面展示
分论坛主席可以浏览到论坛参会人数.- 普通用户注册以及登录界面展示
- 语言切换以及会议主席登录界面展示
- 分论坛主席登录界面展示
- 秘书登录界面展示
遇到的困难及解决办法
- 遇到的困难:分工模糊杂乱.
- 具体描述:针对于采用的前后端开发(vue-springboot)有同学尚未学习过,少部分同学必须经过一部分学习,但是任务完成时间只有一天,于是导致了对技术不熟悉的同学难以加入任务分工。
- 解决途径:
- 通过查阅官方文档、博客以及和同学讨论,得到了很大的改善。
- 具体分析:
- 大任务化小,明确了小的任务分工
- 让不熟悉的同学完成较好学习的模块(后发现更浪费时间了)
- 分配不需要代码的工作(测试|文档)
- 从长远角度考虑,确定好项目开发的语言后根据组长的教导提前熟悉学习
- 遇到的困难:Github commit 时出现错误.
- 具体描述:由于对任务分工不清晰,造成部分人员无法及时对整个项目进行更新。更新的文件已经被别人提交修改,于是GitHub导致无法pull和push,最终只能删除解决问题.
- 解决途径:
- 删除本地项目重新pull
- 具体分析:
- 下次明确分工细则.(第一次团队组队大家尚不熟悉,下次一定会进步的!)
- 遇到的困难:初期后端人员不太熟悉框架的编写,造成任务的停滞。
解决途径:在组内人员细心的指导下,渐渐能够分别写出。
- 遇到的困难:前后端交互对一些具体实现有分歧
- 解决途径:未得到充分解决,重新沟通花费了很多时间
- 具体分析:
- 后端开发人员没有经验
- 原型设计和接口文档设计出来后没有及时沟通重复
评估贡献比例
经过绩效考核表测试并加权计算得到以下成绩.[由于时间原因,工作态度全员100]
凌铧钦:79 11.63%
林沧海:76 11.19%
吴晗杰:74 10.9%
邱梓洛:61 8.98%
林龙星:63 9.28%
蔡瑞金:72 10.6%
陈雨虹:66 9.72%
林子鹏:66 9.72%
张吴晗:62 9.13%
张海浪:60 8.83%
PSP表格
陈雨虹
PSP | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 270 | 320 |
• Estimate | • 估计这个任务需要多少时间 | 240 | 200 |
• Division | • 分工 | 30 | 120(由于掌握技术问题,分工模糊) |
Development | 开发 | 220 | 270 |
• Analysis | • 需求分析 | 180 | 240 |
• Design Spec | • 学习新技术 | 40 | 30 |
Design Review | 接口撰写 | 120 | 180 |
• Design | • 设计接口文档 | 60 | 100 |
• Modify | • 修改接口文档 | 60 | 80 |
Blog writing | 博客撰写 | 180 | 345 |
• planing | • 具体划分模块 | 20 | 40 |
• Division | • 分工安排 | 15 | 15 |
• Write | • 撰写博客 | 120 | 260 |
• Test | • 测试) | 25 | 30 |
Summary | 总结 | 45 | 45 |
• Test | • 测试截图 | 10 | 15 |
• Size Measurement | • 计算工作量 | 10 | 10 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 15 | 20 |
合计 | 715 | 1000 |
张吴晗
PSP | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 30 | 35 |
• Estimate | • 估计这个任务需要多少时间 | 120 | 150 |
Development | • 开发 | 270 | 280 |
• Analysis | • 需求分析 (包括学习新技术) | 120 | 160 |
• Design Spec | • 生成设计文档 | 20 | 30 |
• Design Review | • 设计复审 | 20 | 20 |
• Design | • 具体设计 | 40 | 50 |
• Coding | • 具体编码 | 120 | 180 |
• Code Review | • 代码复审(寻求性能优化) | 15 | 15 |
• Test | • 测试(自我测试,修改代码,提交修改) | 25 | 30 |
Reporting | 报告 | 35 | 40 |
• Test Repor | • 测试报告 | 10 | 15 |
• Size Measurement | • 计算工作量 | 10 | 10 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 15 | 20 |
合计 | 730 | 905 |
张海浪
PSP | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 30 | 35 |
• Estimate | • 估计这个任务需要多少时间 | 30 | 35 |
Development | • 开发 | 690 | 700 |
• Analysis | • 需求分析 (包括学习新技术) | 350 | 360 |
• Design Spec | • 生成设计文档 | 30 | 40 |
• Design Review | • 设计复审 | 40 | 30 |
• Design | • 具体设计 | 60 | 60 |
• Coding | • 具体编码 | 140 | 150 |
• Test | • 测试(自我测试,修改代码,提交修改) | 70 | 60 |
Reporting | 报告 | 60 | 60 |
• Test Repor | • 测试报告 | 30 | 40 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 30 | 20 |
合计 | 780 | 795 |
邱梓洛
PSP | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | ||
• Estimate | • 估计这个任务需要多少时间 | 20 | 30 |
Development | 开发 | ||
• Analysis | • 需求分析 (包括学习新技术) | 60 | 80 |
• Design Spec | • 生成设计文档 | 30 | 20 |
• Design Review | • 设计复审 | 20 | 20 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 20 | 20 |
• Design | • 具体设计 | 90 | 60 |
• Coding | • 具体编码 | 300 | 330 |
• Code Review | • 代码复审 | 30 | 60 |
• Test | • 测试(自我测试,修改代码,提交修改) | 30 | 60 |
Reporting | 报告 | ||
• Test Repor | • 测试报告 | 15 | 30 |
• Size Measurement | • 计算工作量 | 30 | 30 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 60 | 60 |
合计 | 705 | 800 |
林龙星
PSP | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | ||
• Estimate | • 估计这个任务需要多少时间 | 20 | 30 |
Development | 开发 | ||
• Analysis | • 需求分析 (包括学习新技术) | 60 | 80 |
• Design Spec | • 生成设计文档 | 30 | 20 |
• Design Review | • 设计复审 | 20 | 20 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 20 | 20 |
• Design | • 具体设计 | 90 | 70 |
• Coding | • 具体编码 | 300 | 320 |
• Code Review | • 代码复审 | 40 | 50 |
• Test | • 测试(自我测试,修改代码,提交修改) | 40 | 60 |
Reporting | 报告 | ||
• Test Repor | • 测试报告 | 15 | 30 |
• Size Measurement | • 计算工作量 | 30 | 60 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 60 | 50 |
合计 | 725 | 810 |
凌铧钦
PSP | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | ||
• Estimate | • 估计这个任务需要多少时间 | 20 | 30 |
Development | 开发 | ||
• Analysis | • 需求分析 (包括学习新技术) | 60 | 60 |
• Design Spec | • 生成设计文档 | 30 | 30 |
• Design Review | • 设计复审 | 20 | 30 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 20 | 20 |
• Design | • 具体设计 | 90 | 60 |
• Coding | • 具体编码 | 300 | 330 |
• Code Review | • 代码复审 | 30 | 60 |
• Test | • 测试(自我测试,修改代码,提交修改) | 30 | 60 |
Reporting | 报告 | ||
• Test Repor | • 测试报告 | 15 | 30 |
• Size Measurement | • 计算工作量 | 30 | 30 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 60 | 60 |
合计 | 705 | 800 |
林沧海
PSP | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | ||
• Estimate | • 估计这个任务需要多少时间 | 20 | 30 |
Development | 开发 | ||
• Analysis | • 需求分析 (包括学习新技术) | 60 | 90 |
• Design Spec | • 生成设计文档 | 30 | 20 |
• Design Review | • 设计复审 | 20 | 20 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 20 | 20 |
• Design | • 具体设计 | 90 | 70 |
• Coding | • 具体编码 | 300 | 300 |
• Code Review | • 代码复审 | 40 | 50 |
• Test | • 测试(自我测试,修改代码,提交修改) | 40 | 60 |
Reporting | 报告 | ||
• Test Repor | • 测试报告 | 15 | 30 |
• Size Measurement | • 计算工作量 | 30 | 50 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 60 | 60 |
合计 | 725 | 800 |
蔡瑞金
PSP | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | ||
• Estimate | • 估计这个任务需要多少时间 | 30 | 40 |
Development | 开发 | ||
• Analysis | • 需求分析 (包括学习新技术) | 60 | 80 |
• Design Spec | • 生成设计文档 | 20 | 30 |
• Design Review | • 设计复审 | 30 | 30 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 20 | 20 |
• Design | • 具体设计 | 90 | 70 |
• Coding | • 具体编码 | 300 | 320 |
• Code Review | • 代码复审 | 40 | 50 |
• Test | • 测试(自我测试,修改代码,提交修改) | 50 | 50 |
Reporting | 报告 | ||
• Test Repor | • 测试报告 | 25 | 30 |
• Size Measurement | • 计算工作量 | 30 | 60 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 60 | 50 |
合计 | 755 | 830 |
林子鹏
PSP | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | ||
• Estimate | • 估计这个任务需要多少时间 | 30 | 40 |
Development | 开发 | ||
• Analysis | • 需求分析 (包括学习新技术) | 70 | 70 |
• Design Spec | • 生成设计文档 | 20 | 20 |
• Design Review | • 设计复审 | 20 | 30 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 20 | 20 |
• Design | • 具体设计 | 90 | 70 |
• Coding | • 具体编码 | 300 | 300 |
• Code Review | • 代码复审 | 50 | 60 |
• Test | • 测试(自我测试,修改代码,提交修改) | 50 | 60 |
Reporting | 报告 | ||
• Test Repor | • 测试报告 | 25 | 30 |
• Size Measurement | • 计算工作量 | 30 | 50 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 40 | 50 |
合计 | 745 | 800 |
吴晗杰
PSP | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | ||
• Estimate | • 估计这个任务需要多少时间 | 30 | 40 |
Development | 开发 | ||
• Analysis | • 需求分析 (包括学习新技术) | 60 | 80 |
• Design Spec | • 生成设计文档 | 25 | 20 |
• Design Review | • 设计复审 | 30 | 20 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 20 | 20 |
• Design | • 具体设计 | 90 | 80 |
• Coding | • 具体编码 | 300 | 350 |
• Code Review | • 代码复审 | 50 | 50 |
• Test | • 测试(自我测试,修改代码,提交修改) | 40 | 60 |
Reporting | 报告 | ||
• Test Repor | • 测试报告 | 25 | 30 |
• Size Measurement | • 计算工作量 | 50 | 40 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 30 | 40 |
合计 | 750 | 830 |
第二部分
团队选题展示过程中,老师和同学提出了一些问题。有没有哪个问题你们想重新回答?
在展示过程中,老师和同学们提出的问题主要囊括了四个部分:
抠图算法的实现:
抠图算法我们经过查阅相关论文,决定采用onecut抠图算法做第一步抠图算法的实现;
识别算法的实现:
识别算法我们已初步跑通用coco训练集训练的centernet目标检测算法,识别率尚为可观。而经过助教提醒建议,我们预计采用网上的服饰数据集来进行模型训练。
用户体验:
经过市场上已有的竞品分析,并且针对老师同学提出的用户体验问题,我们预计将在app中实现衣物批量导入功能。同时增加衣物照片识别分类接口,让用户在上传照片后能够自动帮用户把衣服归类,放入相对应的“衣物类别抽屉”,从而减少用户机械操作的用时,以带来更好的用户体验。
推荐算法的分类实现:
推荐算法仍然是我们团队目前认为最大的难点,我们会在实现完app基础功能后再集中突破这一难点。
初步的想法是,推荐算法分为两部分——“穿多少”(即天气对应穿衣量)和“怎么穿”(即衣物搭配)两部分。考虑到每个人穿衣风格不一以及app实用性,我们将会优先实现“穿多少”部分。该部分的初步构思是:app通过爬取每日福州当地气温,以最低温作为敏感值,最高温和温差作为参考值,给出穿衣量建议。
“怎么穿”部分,我们预计采用启发式推荐算法,借鉴网易云音乐的推荐歌单实现方式。在最初推出几套穿搭后,由用户的选择判断用户的穿衣风格倾向,在选择过程中学习。但可能实现难度会较大,所以我们想在基本功能实现后再用来锦上添花。
在上次团队选题之后,你们组有什么新的思考和想法?有什么具体的行动,列出具体行动
- 新的想法:
在答辩后,我们团队与几个提问同学进行了线下交流,针对男女生衣物选择数量和广度的差异(造成“怎么穿”的推荐差异),以及男女生体质差异(造成“穿多少”的推荐差异),我们考虑在学有余力的情况下将app分为男/女生版两种版本实现——在不同版本中对几个算法的参数进行微调,以给男生/女生更有针对性更专业的用户体验。
- 具体行动:
进一步讨论具体实现的分工,算法组的同学进一步学习centernet目标检测算法以及学习并尝试训练自己设定的在衣物识别领域的训练集。