团队作业第二次—团队Github实战训练
| 这个作业属于哪个课程 | 2020春|S班（福州大学） |
|---|---|
| 这个作业要求在哪里 | 团队作业第二次—团队Github实战训练 |
| 团队名称 | 软工实践互动评价小组 |
| 这个作业的目标 | 1.开发一套口罩预约系统 2.团队github协作训练 |
| 作业正文 | 软工实践互动评价小组—团队展示 |
| 其他参考文献 | bootstrap中文网 ... |
超时声明
需要使用最新提交的版本。
问题：
1.用户点击预约以后没有返回预约编号。
2.部分URL地址没有配置成通用地址。
反思：
这次的问题是前后端合作不熟练导致的，后端在接收前端信息并反馈的时候耗费了大量时间，在之后的团队开发过程中，一定要先写好接口文档，避免此类问题的产生。
然后以后开发环境尽量配置成最终运行的环境，避免每个人运行的方式不统一，浪费了很多时间。
#-->Part 1
一、组员职责分工
为了方便观看，将下面的commit次数，贡献率都整合到同一个表中
| 组员 | 学号 | 分工 | commit次数 | 贡献率 |
|---|---|---|---|---|
| 许家诚 | 221701210 | 组长、前端 | 12 | 13 |
| 傅少华 | 091700410 | 前端 | 4 | 11 |
| 陈茜 | 221701409 | 前端、文档 | 3 | 11 |
| 肖玮昊 | 221701109 | 后端 | 9 | 14 |
| 蔡鸿辉 | 221701128 | 数据库设计、测试 | 7 | 14 |
| 张增燊 | 221701230 | 后端、测试 | 5 | 14 |
| 陈家祯 | 221701310 | 后端 | 3 | 11 |
| 蔡俊 | 221701324 | 后端 | 4 | 12 |
开发流程以及反思：
起步：早上大约花了两个小时来确定分工，由于之后的项目要采用前后端分离架构，这一次我们也是使用前后端分离架构，这样在此次开发中就可以收获很多有用的经验。
反思：这一步我们做的还可以。
编码：然后我们就开始完成各自的功能模块，还算顺利，但中间有的点小插曲，有的组员pr的时候没有及时反馈给组长，导致没有及时合并，产生冲突。
反思：以后建了仓库一定要先把组员都邀请为协作者，那么大家就可以直接与主仓库保持一致了；对代码进行修改要及时反馈。
收尾及测试：到晚上七八点的时候，每个人的功能模块都完成了，于是我们开始组装，但是遇到了很多问题。
反思：我们每个人的测试环境不一样，在之后的开发里，我们应当先统一测试环境，明明功能模块都写得差不多了，但是到最后才勉强赶得上。
二、github 的提交日志截图（鼓励小粒度提交），统计//各组员的commit次数
仓库地址
注：后面几位同学由于提交时有冲突，把文件发给其他同学代为commit，commit次数均>=3
反思：在仓库创建的时候最好把组员都邀请为合作者，大家就可以直接commit到主仓库里。
commit统计：见上表
三、程序运行截图
重复预约：
预约成功：
开放预约：
格式检验：
查询：
四、程序运行环境
形式：web，采用前后端分离，需要先运行后端，然后运行前端。前端使用bootstrap框架，打开就可以不需要额外安装；后端使用Eclipse+Tomcat+MySql，用到了javaEE课程里教到的内容。
数据库已导出在sql文件夹中，需要先导入，然后在将live-project\backend\util\DBUtil.java配置文件中的数据库改为自己的实际情况。
五、GUI界面
界面清爽，功能明了，易于使用。
六、基础功能实现
功能点 | 完成度
--|:--😐:--:
|身份证、手机号格式验证及错误提示 |1
|身份证、手机号的唯一性及错误提示 |1
|间隔三次才能预约及错误提示 |1
|存储预约信息 |1
|预约结束后的中签计算 |1
|预约查询及提示 |1
使用逻辑为：在预约开始之前，用户不可以进行预约；预约开启以后，用户才可以进行预约，此外，用户如果在前三轮中签过也不能进行预约，预约成功后会生成一个编号；点击结束以后，系统将会生成一份中签名单（存在数据库里，但是由于前后端数据传输不是很熟练，所以没有实现导出功能，抽签逻辑在后面会说），在此之后用户可以编号来查询自己是否中奖。
抽奖逻辑：以下用一个例子来说明：
假设发放了100个口罩，由于100/3=33，所以在名单中抽取33个人，计算这33个人的预约总数，假设这33个人没人没有预约到3个，都只预约了两个，也就是总共66个，那么现在还剩下34个口罩，那么再从剩下的未中签者中抽取11个人，假设这些人都预约了3个也就是一共33个，最终剩下1个口罩，那么就在剩余的人中抽取一个只预约了1个的人，如果没有的话，那本轮就会剩下一个口罩。为了优化效率，我们在刚从数据库获取名单的时候就进行了一次随机排序，然后按顺序取，这样避免了每一轮都要进行随机抽取的问题。
既每次抽的人数=剩余总数%每个人能预约的最大个数
优点：效率高，并且真的随机。修改口罩总数和每个人的最大预约数量即可实现设定口罩的最大数量和每个人预约最大数量的功能。（只是没有写）
缺点：中签次数不会影响被抽中的权重。
七、附加功能实现
功能点 | 完成度
--|:--😐:--:
|管理员登录 |0
|设置预约的开放时间和截止时间 |0.5
|设置预约时单个用户最高可预约数量 |0
|设置口罩总数 |1
|导出某次中签的名单 |0.5
0.5说明：
设置预约的开放时间和截止时间：可以选择，并且数据库有这个数据，但是不能定时关闭。
导出某次中签的名单：后端可以返回给前端，但由于时间来不及，没有研究好前后端通信的问题，返回后不美观，所以先删减了。
八、鼓励有想法且有用的功能
暂无
九、用户体验，操作的方便、快捷性
前端使用了bootstrap框架，界面清爽美观，操作便捷，符合当下的主流标准。
十、遇到的困难及解决方法
问题：第一次团队作业，配合困难
解决：磨合
问题：采用前后端分离架构，数据进行传输
解决：上网查
十一、贡献度评估
见上表
十二、PSP表格
许家诚
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 90 | 90 |
| Estimate | 估计这个任务需要多少时间 | 30 | 30 |
| Development | 开发 | 600 | 660 |
| Analysis | 需求分析 (包括学习新技术) | 20 | 20 |
| Design Spec | 生成设计文档 | 20 | 20 |
| Design Review | 设计复审 | 30 | 30 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 30 | 30 |
| Coding | 具体编码 | 460 | 520 |
| Code Review | 代码复审 | 30 | 30 |
| Test | 测试（自我测试，修改代码，提交修改） | 80 | 80 |
| Reporting | 报告 | 20 | 20 |
| Test Repor | 测试报告 | 10 | 10 |
| Size Measurement | 计算工作量 | 20 | 20 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 770 | 830 |
傅少华
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 90 | 90 |
| Estimate | 估计这个任务需要多少时间 | 30 | 30 |
| Development | 开发 | 600 | 660 |
| Analysis | 需求分析 (包括学习新技术) | 20 | 20 |
| Design Spec | 生成设计文档 | 20 | 20 |
| Design Review | 设计复审 | 30 | 30 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 30 | 30 |
| Coding | 具体编码 | 460 | 520 |
| Code Review | 代码复审 | 30 | 30 |
| Test | 测试（自我测试，修改代码，提交修改） | 80 | 80 |
| Reporting | 报告 | 20 | 20 |
| Test Repor | 测试报告 | 10 | 10 |
| Size Measurement | 计算工作量 | 20 | 20 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 770 | 830 |
陈茜
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 90 | 90 |
| Estimate | 估计这个任务需要多少时间 | 30 | 30 |
| Development | 开发 | 600 | 660 |
| Analysis | 需求分析 (包括学习新技术) | 20 | 20 |
| Design Spec | 生成设计文档 | 20 | 20 |
| Design Review | 设计复审 | 30 | 30 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 30 | 30 |
| Coding | 具体编码 | 460 | 520 |
| Code Review | 代码复审 | 30 | 30 |
| Test | 测试（自我测试，修改代码，提交修改） | 80 | 80 |
| Reporting | 报告 | 20 | 20 |
| Test Repor | 测试报告 | 10 | 10 |
| Size Measurement | 计算工作量 | 20 | 20 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 770 | 830 |
肖玮昊
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 90 | 90 |
| Estimate | 估计这个任务需要多少时间 | 30 | 30 |
| Development | 开发 | 600 | 660 |
| Analysis | 需求分析 (包括学习新技术) | 20 | 20 |
| Design Spec | 生成设计文档 | 20 | 20 |
| Design Review | 设计复审 | 30 | 30 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 30 | 30 |
| Coding | 具体编码 | 460 | 520 |
| Code Review | 代码复审 | 30 | 30 |
| Test | 测试（自我测试，修改代码，提交修改） | 80 | 80 |
| Reporting | 报告 | 20 | 20 |
| Test Repor | 测试报告 | 10 | 10 |
| Size Measurement | 计算工作量 | 20 | 20 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 770 | 830 |
蔡鸿辉
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 90 | 90 |
| Estimate | 估计这个任务需要多少时间 | 30 | 30 |
| Development | 开发 | 600 | 660 |
| Analysis | 需求分析 (包括学习新技术) | 20 | 20 |
| Design Spec | 生成设计文档 | 20 | 20 |
| Design Review | 设计复审 | 30 | 30 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 30 | 30 |
| Coding | 具体编码 | 460 | 520 |
| Code Review | 代码复审 | 30 | 30 |
| Test | 测试（自我测试，修改代码，提交修改） | 80 | 80 |
| Reporting | 报告 | 20 | 20 |
| Test Repor | 测试报告 | 10 | 10 |
| Size Measurement | 计算工作量 | 20 | 20 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 770 | 830 |
张增燊
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 90 | 90 |
| Estimate | 估计这个任务需要多少时间 | 30 | 30 |
| Development | 开发 | 600 | 660 |
| Analysis | 需求分析 (包括学习新技术) | 20 | 20 |
| Design Spec | 生成设计文档 | 20 | 20 |
| Design Review | 设计复审 | 30 | 30 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 30 | 30 |
| Coding | 具体编码 | 460 | 520 |
| Code Review | 代码复审 | 30 | 30 |
| Test | 测试（自我测试，修改代码，提交修改） | 80 | 80 |
| Reporting | 报告 | 20 | 20 |
| Test Repor | 测试报告 | 10 | 10 |
| Size Measurement | 计算工作量 | 20 | 20 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 770 | 830 |
陈家祯
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 90 | 90 |
| Estimate | 估计这个任务需要多少时间 | 30 | 30 |
| Development | 开发 | 600 | 660 |
| Analysis | 需求分析 (包括学习新技术) | 20 | 20 |
| Design Spec | 生成设计文档 | 20 | 20 |
| Design Review | 设计复审 | 30 | 30 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 30 | 30 |
| Coding | 具体编码 | 460 | 520 |
| Code Review | 代码复审 | 30 | 30 |
| Test | 测试（自我测试，修改代码，提交修改） | 80 | 80 |
| Reporting | 报告 | 20 | 20 |
| Test Repor | 测试报告 | 10 | 10 |
| Size Measurement | 计算工作量 | 20 | 20 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 770 | 830 |
蔡俊
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 90 | 90 |
| Estimate | 估计这个任务需要多少时间 | 30 | 30 |
| Development | 开发 | 600 | 660 |
| Analysis | 需求分析 (包括学习新技术) | 20 | 20 |
| Design Spec | 生成设计文档 | 20 | 20 |
| Design Review | 设计复审 | 30 | 30 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 30 | 30 |
| Coding | 具体编码 | 460 | 520 |
| Code Review | 代码复审 | 30 | 30 |
| Test | 测试（自我测试，修改代码，提交修改） | 80 | 80 |
| Reporting | 报告 | 20 | 20 |
| Test Repor | 测试报告 | 10 | 10 |
| Size Measurement | 计算工作量 | 20 | 20 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 770 | 830 |
#-->Part 2
一、团队选题展示过程中，老师和同学提出了一些问题。有没有哪个问题你们想重新回答？
- 问题：由于撞题太过惨烈，实际上并没有什么问题。
- 新解答：于是我们听从老师的建议，换了一个题目。
二、在上次团队选题之后，你们组有什么新的思考和想法？
毕竟题目都换了，组名也改了，也没什么好说的，那就选题要现实一点吧。
