团队第二次作业
| 这个作业属于哪个课程 | 福州大学2020年春W班 |
|---|---|
| 这个作业要求在哪里 | 作业要求 |
| 团队名称 | RGSJ |
| 这个作业的目标 | 预约口罩网页 |
| 作业正文 | ··· |
| 其他参考文献 | ··· |
组员职责分工
组长裴博负责分派工作，并协调前端后端的工作
杨婕和陈文婷负责前端和博客的撰写
陈赐，王建林，危正负责后端代码的编写以及数据库的建表
github 的提交日志截图（鼓励小粒度提交），统计各组员的commit次数
| 成员 | commit次数 |
|---|---|
| 裴博 | 3 |
| 杨婕 | 3 |
| 陈文婷 | 3 |
| 陈赐 | 3 |
| 王建林 | 5 |
| 危正 | 3 |
 |
程序运行截图
程序运行环境
mysql eclipse idea
GUI界面
基础功能实现
1 口罩预约定时开放
开放预约后，市民可以进行登记；登记内容包括①真实姓名；②身份证号；③手机号；④预约口罩数量（如果中签，想要买几个口罩）
如果手机号或者身份证号已经在本次摇号登记过了，预约失败
如果手机号或者身份证号在此前三次预约中成功中签，预约失败
否则预约成功，给出不重复的预约编号
预约定时关闭
为方便测试，请在预约页面提供两个按钮，作用分别是开始预约和结束预约；
为方便测试，请在预约页面提供设置口罩总量的方法
登记时单个用户最高可预约口罩数量，默认为3个
2 中签查询功能：
用户输入自己的预约编号，显示是否中签
如果中签，生成购买凭证，包含姓名、身份证号、电话号和购买数量
用户体验，操作的方便、快捷性
用户体验尚可，界面简洁明了，操作易于上手。
由于是网页，用户只需打开网页并不用下载软件，就可以进行预约服务。
遇到的困难及解决方法
裴博
首次沟通前后端，感受到了重重阻力，理解了前后端的沟通不易。经过这次作业，以后对团队的分工以及调度更加得心应手。
杨婕，陈文婷
在完成jsp的时候，连接前后端不熟练，github使用不熟练，经过这次作业也有了新的认识。
陈赐
获取输入框的值一直报空指针错。
王建林
构建数据结构和所用技术框架矛盾 在jsp前端和servlet的数据转发过程中 没办法一直循环传递数据 而数据结构要求数据需要在前端和后端不断收集才能实现功能。
危正
数据库储存形式难以确定，在java代码中嵌入jsp代码出错。
评估每位组员的贡献比例，总分100
221701303|14
221701301|13
221701302|13
221701330|25
221701326|20
221701332|15
PSP表格
裴博
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 15 |
| Estimate | 估计这个任务需要多少时间 | 180 | 190 |
| Development | 开发 | 180 | 190 |
| Analysis | 需求分析 (包括学习新技术) | ··· | ··· |
| Design Spec | 生成设计文档 | ··· | ··· |
| Design Review | 设计复审 | ··· | ··· |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | ··· | ··· |
| Design | 具体设计 | 10 | 15 |
| Coding | 具体编码 | 180 | 190 |
| Code Review | 代码复审 | ··· | ··· |
| Test | 测试（自我测试，修改代码，提交修改） | 30 | 30 |
| Reporting | 报告 | ··· | ··· |
| Test Repor | 测试报告 | ··· | ··· |
| Size Measurement | 计算工作量 | 5 | 5 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | ··· | ··· |
| 合计 | 205 | 225 |
杨婕
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 15 |
| Estimate | 估计这个任务需要多少时间 | 180 | 190 |
| Development | 开发 | 180 | 190 |
| Analysis | 需求分析 (包括学习新技术) | ··· | ··· |
| Design Spec | 生成设计文档 | ··· | ··· |
| Design Review | 设计复审 | ··· | ··· |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | ··· | ··· |
| Design | 具体设计 | 10 | 15 |
| Coding | 具体编码 | 180 | 190 |
| Code Review | 代码复审 | ··· | ··· |
| Test | 测试（自我测试，修改代码，提交修改） | 30 | 30 |
| Reporting | 报告 | ··· | ··· |
| Test Repor | 测试报告 | ··· | ··· |
| Size Measurement | 计算工作量 | 5 | 5 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | ··· | ··· |
| 合计 | 205 | 225 |
陈文婷
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 15 |
| Estimate | 估计这个任务需要多少时间 | 180 | 190 |
| Development | 开发 | 180 | 190 |
| Analysis | 需求分析 (包括学习新技术) | ··· | ··· |
| Design Spec | 生成设计文档 | ··· | ··· |
| Design Review | 设计复审 | ··· | ··· |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | ··· | ··· |
| Design | 具体设计 | 10 | 15 |
| Coding | 具体编码 | 180 | 190 |
| Code Review | 代码复审 | ··· | ··· |
| Test | 测试（自我测试，修改代码，提交修改） | 30 | 30 |
| Reporting | 报告 | ··· | ··· |
| Test Repor | 测试报告 | ··· | ··· |
| Size Measurement | 计算工作量 | 5 | 5 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | ··· | ··· |
| 合计 | 205 | 225 |
陈赐
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 15 |
| Estimate | 估计这个任务需要多少时间 | 400 | 480 |
| Development | 开发 | 400 | 480 |
| Analysis | 需求分析 (包括学习新技术) | ··· | ··· |
| Design Spec | 生成设计文档 | ··· | ··· |
| Design Review | 设计复审 | ··· | ··· |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | ··· | ··· |
| Design | 具体设计 | 10 | 15 |
| Coding | 具体编码 | 400 | 480 |
| Code Review | 代码复审 | ··· | ··· |
| Test | 测试（自我测试，修改代码，提交修改） | 30 | 30 |
| Reporting | 报告 | ··· | ··· |
| Test Repor | 测试报告 | ··· | ··· |
| Size Measurement | 计算工作量 | 5 | 5 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | ··· | ··· |
| 合计 | 1255 | 1510 |
王建林
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 15 |
| Estimate | 估计这个任务需要多少时间 | 400 | 480 |
| Development | 开发 | 400 | 480 |
| Analysis | 需求分析 (包括学习新技术) | ··· | ··· |
| Design Spec | 生成设计文档 | ··· | ··· |
| Design Review | 设计复审 | ··· | ··· |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | ··· | ··· |
| Design | 具体设计 | 10 | 15 |
| Coding | 具体编码 | 400 | 480 |
| Code Review | 代码复审 | ··· | ··· |
| Test | 测试（自我测试，修改代码，提交修改） | 30 | 35 |
| Reporting | 报告 | ··· | ··· |
| Test Repor | 测试报告 | ··· | ··· |
| Size Measurement | 计算工作量 | 5 | 5 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | ||
| 合计 | 1255 | 1510 |
危正
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 15 |
| Estimate | 估计这个任务需要多少时间 | 400 | 490 |
| Development | 开发 | 400 | 490 |
| Analysis | 需求分析 (包括学习新技术) | ··· | ··· |
| Design Spec | 生成设计文档 | ··· | ··· |
| Design Review | 设计复审 | ··· | ··· |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | ··· | ··· |
| Design | 具体设计 | 10 | 15 |
| Coding | 具体编码 | 400 | 490 |
| Code Review | 代码复审 | ··· | ··· |
| Test | 测试（自我测试，修改代码，提交修改） | 30 | 30 |
| Reporting | 报告 | ··· | ··· |
| Test Repor | 测试报告 | ··· | ··· |
| Size Measurement | 计算工作量 | 5 | 5 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 1255 | 1540 |
| 合计 |
随笔的第二部分
团队选题展示过程中，老师和同学提出了一些问题。有没有哪个问题你们想重新回答？在上次团队选题之后，你们组有什么新的思考和想法？
1.对功能如何好，只有文字的描述，显得比较简单，也没有考虑过交易过程的设想？比如简单的交易原型？
有过设想！交易过程我们采用线下当面交易。
2.关键字搜索出的相关物品，有无进行排序？打算根据什么规则？
有进行排序，排序按照两种方式，价格从低到高排序，时间先后排序。用户可以自行选择排序方式。
3.遗失物品进行归纳统计，是手动还是自动进行？
遗失物品在登记的时候，会有许多标签供用户选择，然后自动根据标签分类。
4.比如上一组，有OCR模糊匹配、推荐，你们呢？
模糊匹配我们也会有，推荐会有“每日遗失”和“每日上新”两个栏目。“每日遗失”将当天遗失后被捡到的物品推送给用户，“每日上新”将当天发布的二手物品信息进行推送。
5.假设你们的用户稳定增加，你们信息必然越来越多，那么如何保证数据存储、搜索响应的快捷？
我们目前决定使用数据库。
6.有什么好点子吸引用户使用？现在福大的二手群也很多人使用，你怎么吸引他们用你的APP？
首先，二手群和软件是没有可比性的。不论是功能方面还是时间效应方面，二手群都无法达到想要的效果。
比如，功能方面，二手群无法提供搜索功能，不能根据标签分类，不会根据用户的喜好推送，而我们的闲小鱼可以实现以上所有功能。时间效应方面，用户发布的信息可以较长时间的保存，不会被别的消息刷过去。
并且闲鱼的界面很复杂，面向学生的只要简洁明了就可以了。
7.如果采用移除历史数据，那么跟咸鱼类似，如何保证你一开始说的数据都在这样的“口号”？
我们的软件和闲鱼的设计目的是不一样的，闲鱼面对全社会的人民群众，而闲小鱼只是面对学校，所以数据保存四年，账号有效期截至毕业前。所以我们的数据并不需要永久存在，只需要在校期间存在就可以了。
浙公网安备 33010602011771号