| 这个作业属于哪个课程 | <软件工程2020春|W班 (福州大学)> |
|---|---|
| 这个作业要求在哪里 | <作业要求的链接> |
| 这个作业的目标 | 开发一个向社会限量供应的口罩应用 |
| 作业正文 | 就是这里 |
| 其他参考文献 |
GITHUB地址
https://github.com/RETORETO/live-project
release
https://github.com/RETORETO/live-project/releases/tag/1.0.0
组员职责分工
041701602:组织分工，博客攥写，部分代码实现
221701140:UI界面和部分代码实现，部分业务规则和实现
081700308:UI界面和部分代码实现
021700915:数据库，数据库接口和类操作，前后端接口
221701111:部分业务规则和具体实现
221701130:部分业务规则和具体实现
前端：陈秉宥，付其佳
后端：陈晟，林学斌，刘晓龙，林泰来
前后端接口：林学斌，刘晓龙
github 的提交日志截图
| 学号 | commit次数 |
|---|---|
| 221701140 | 7 |
| 041701602 | 10 |
| 081700308 | 6 |
| 221701111 | 6 |
| 221701130 | 12 |
| 021700915 | 3 |
程序运行截图
程序运行环境
MYSQL 5.6
下载文件后，运行sql目录下的sql文件，文件直接导入eclipse文件可以打开，从scr/ui/menu进入程序
文件下载
基础功能实现
通过数据库record表储存预约信息，在JAVA中用record类储存，前端页面收入信息后进行输入合法性检测后传入后端和数据库进行比对后存入数据库。
遇到的困难及解决方法
刘晓龙
困难：在编写市民预约登记功能时，对于市民填写的相关信息存储入数据表中，遇到部分乱码，以及输入信息后如何与之后的相关信息结合起来，进行判断。
解决困难：再次修改数据表信息，检查相关编码，以及通过登记信息的结合形成相关预约信息
林泰来
困难1：一开始编写查询类的时候由于长时间没有写过相关的功能，完全不知道怎么下手。
解决困难：把之前做过的类似的作业拿出来复习了一遍，很快就回想起编码的思路了。
困难2：由于较长时间未使用数据库，导致数据库密码和使用方式都忘了。
解决困难：重新设置了数据库密码并在网上简单地学习了数据库的使用教程于是很快就能上手了。
困难3：开始时不知道自己需要干什么事，做哪些工作。
解决困难：及时与小组成员交流和沟通，大家一起讨论出一共需要做哪些工作以及每个人分配到哪些内容。
林学斌：
困难：首先是技术储备不足，在进行需求分析的时候想过使用JavaEE来实现，但是由于没选修JavaEE，又想过使用PHP来实现，但是队友中也有一部分对PHP不熟悉，最后决定使用Java语言编写，每个人先稍微复习一下Java语言，然后解决了这个语言选择的问题。其次是分工不明确。在分配的时候，对队友不熟悉，有时候刚好分配给某队友不擅长的地方，导致任务进展缓慢。对项目不熟悉导致分工模糊。最后经过队友间相互沟通交流有效的解决了部分问题。
陈晟：
困难：果然还是GITHUB上和队友交接的问题吧，经常有重复提交错误之类的发生
解决困难：提交之前先和队友说好
解决困难：最后是对GitHub使用不熟悉，提交混乱。因为之前都是结对合作，只有两个人提交，提交起来方便，但是团队人数众多，提交代码混乱，各种版本都存在
组员贡献
| 学号 | 贡献度 |
|---|---|
| 221701140 | 14 |
| 041701602 | 16 |
| 081700308 | 17 |
| 221701111 | 17 |
| 221701130 | 16 |
| 021700915 | 19 |
小组六人的PSP表格
| 陈晟 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 30 |
| Estimate | 估计这个任务需要多少时间 | 30 | 30 |
| Development | 开发 | 790 | 685 |
| Analysis | 需求分析 (包括学习新技术) | 0 | 0 |
| Design Spec | 生成设计文档 | 30 | 30 |
| Design Review | 设计复审 | 10 | 5 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 30 | 10 |
| Design | 具体设计 | 20 | 30 |
| Coding | 具体编码 | 600 | 530 |
| Code Review | 代码复审 | 30 | 30 |
| Test | 测试（自我测试，修改代码，提交修改） | 70 | 50 |
| Reporting | 报告 | 70 | 70 |
| Test Repor | 测试报告 | 30 | 50 |
| Size Measurement | 计算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 10 |
| 合计 | 890 | 785 |
| 刘晓龙 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 30 |
| Estimate | 估计这个任务需要多少时间 | 30 | 30 |
| Development | 开发 | 760 | 755 |
| Analysis | 需求分析 (包括学习新技术) | 0 | 0 |
| Design Spec | 生成设计文档 | 20 | 30 |
| Design Review | 设计复审 | 10 | 5 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 20 | 10 |
| Design | 具体设计 | 20 | 30 |
| Coding | 具体编码 | 600 | 600 |
| Code Review | 代码复审 | 40 | 30 |
| Test | 测试（自我测试，修改代码，提交修改） | 50 | 50 |
| Reporting | 报告 | 60 | 50 |
| Test Repor | 测试报告 | 20 | 30 |
| Size Measurement | 计算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 10 |
| 合计 | 850 | 835 |
| 付其佳 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 20 | 30 |
| Estimate | 估计这个任务需要多少时间 | 20 | 30 |
| Development | 开发 | 700 | 755 |
| Analysis | 需求分析 (包括学习新技术) | 0 | 0 |
| Design Spec | 生成设计文档 | 40 | 30 |
| Design Review | 设计复审 | 10 | 5 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 20 | 10 |
| Design | 具体设计 | 40 | 30 |
| Coding | 具体编码 | 540 | 600 |
| Code Review | 代码复审 | 20 | 30 |
| Test | 测试（自我测试，修改代码，提交修改） | 30 | 50 |
| Reporting | 报告 | 30 | 50 |
| Test Repor | 测试报告 | 10 | 30 |
| Size Measurement | 计算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 10 | 10 |
| 合计 | 750 | 835 |
| 陈秉宥 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 30 |
| Estimate | 估计这个任务需要多少时间 | 30 | 30 |
| Development | 开发 | 760 | 595 |
| Analysis | 需求分析 (包括学习新技术) | 60 | 180 |
| Design Spec | 生成设计文档 | 10 | 10 |
| Design Review | 设计复审 | 10 | 5 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 30 | 10 |
| Design | 具体设计 | 20 | 30 |
| Coding | 具体编码 | 400 | 330 |
| Code Review | 代码复审 | 30 | 30 |
| Test | 测试（自我测试，修改代码，提交修改） | 70 | 60 |
| Reporting | 报告 | 30 | 10 |
| Test Repor | 测试报告 | 30 | 30 |
| Size Measurement | 计算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 10 |
| 合计 | 660 | 695 |
| 林泰来 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 20 | 30 |
| Estimate | 估计这个任务需要多少时间 | 20 | 30 |
| Development | 开发 | 710 | 755 |
| Analysis | 需求分析 (包括学习新技术) | 0 | 0 |
| Design Spec | 生成设计文档 | 40 | 30 |
| Design Review | 设计复审 | 10 | 5 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 30 | 30 |
| Coding | 具体编码 | 550 | 600 |
| Code Review | 代码复审 | 40 | 30 |
| Test | 测试（自我测试，修改代码，提交修改） | 30 | 50 |
| Reporting | 报告 | 10 | 50 |
| Test Repor | 测试报告 | 10 | 30 |
| Size Measurement | 计算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 10 |
| 合计 | 890 | 835 |
| 林学斌 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 25 | 30 |
| Estimate | 估计这个任务需要多少时间 | 25 | 15 |
| Development | 开发 | 240 | 250 |
| Analysis | 需求分析 (包括学习新技术) | 60 | 15 |
| Design Spec | 生成设计文档 | 20 | 30 |
| Design Review | 设计复审 | 25 | 5 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 15 | 10 |
| Design | 具体设计 | 30 | 30 |
| Coding | 具体编码 | 240 | 200 |
| Code Review | 代码复审 | 30 | 30 |
| Test | 测试（自我测试，修改代码，提交修改） | 30 | 30 |
| Reporting | 报告 | 10 | 20 |
| Test Repor | 测试报告 | 10 | 20 |
| Size Measurement | 计算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 10 |
| 合计 | 800 | 695 |
团队选题答疑部分
Q:如何防止商家或者学生恶意刷积分？
A:积分的来源是消费（消费过后才能评论和获取积分），积分的用处是抵用券，为了抵用券去消费我们认为是不值得的
Q:可以理解为食堂摊位是商家，学生是用户？那么跟一般的点餐系统最大的差别在哪里？
A:我们和一般的点餐系统差异化主要体现在这几点：一是我们专门服务于食堂，更加轻便灵活，致力于解决学生排队排了很久却不是自己想排的窗口/想吃的食物已经售罄了的情况，另外也能省下骑手和打包的费用；二是我们的评价系统引入的“等待时间”的评价，把看不见的骑手配送时间变成可以估算的等待时间，适合生活节奏较快的学生。
Q:存在预约人少，但实际上现场排队的人很多，这样的现象，如何让预约给予正确的含义？
A:这也是我们引入“等待时间”评级的理由，学生可以在排队之前通过我们的程序大致上判断当前时间段哪里的窗口更拥挤。
Q:对商家而言，我为什么要加入你们平台呢?
A:我们认为商家加入新的使用便利的平台是有利于商家的推广的，平台顺利推广开来以后也能营造出商家不加入平台就会在和其他商家的竞争上陷入劣势的情况。