第一部分:团队第二次作业github编程实战
1、项目github地址以及项目部署的在线地址
github地址:https://github.com/FZUSESPR21/meeting-system-3
2、组员职责分工
学号 |
|
工作内容 |
贡献度(百分比) |
041801114 |
柯少彬 |
完成整体架构、完成javafx的主要工作、全栈 |
18 |
221801130 |
梁扬新 |
数据库设计、交互,协助秘书前端设计,后端逻辑 |
13 |
031801124 |
陈皓宇 |
秘书前端设计 协助数据库相关设计 |
11 |
131801208 |
陈杉 |
分论坛主席的 页面设计 五国语言适配 |
13 |
221801105 |
黄钰栋 |
前端设计 |
10 |
071808114 |
李家成 |
Chairman的gui实现 |
11 |
221801109 |
池毓地 |
五国语言翻译 |
7 |
221801110 |
黄凯荣 |
前端设计 |
8 |
031801133 |
陈力涵 |
辅助前端设计,团队博客撰写 |
9 |
3、github 的提交日志截图(鼓励小粒度提交),统计各组员的commit次数
commit次数统计:
柯少彬:21
梁扬新:7
池毓地:5
陈杉:4
李家成:3
陈皓宇:3
陈力涵:3
黄钰栋:3
黄凯荣:3
4、程序运行截图
登录界面
注册界面
服务端
主席客户端
分主席界面
秘书界面
5、遇到的困难及解决方法
柯少彬(队长):第一次使用javaFX技术来实现UI设计、服务器客户端交互以及数据库交互;2、第一次以团队形式在较短时间内完成项目
解决方案:查阅有关资料,和观看视频,动手实践操作测试;在做项目的过程中集中精神,与队友进行有效交流
李家成:附加功能要加入多语言支持,在一些控件和显示上不能直接显示一种语言。
解决方案:通过向组内成员寻求帮助,最终采用将目标字段转化为Unicode的方法来解决。
陈皓宇:第一次接触java FX ,在一天内现学现卖比较困难。
解决方案:现场百度+查文档。没什么是不能学会的
黄钰栋:设计参会者界面使用的是Javafx技术,编码进度非常缓慢。
解决方案:通过组长推荐的入门教程,认真学习后,成功地掌握了Javafx初步技术,完成了界面的设计
池毓地:不同语种之间unicode与ascii的转换
解决方案:借助unicode与ascii码转换工具与语言翻译工具,进行多次转换
陈杉:临时决定使用没学过的javafx但好在 我短时间的学到了一些 可以用得上的东西
解决方案:一开始想用java的swing写后来发现 其他人都用javafx这个有更好用的,而且还找到了很多相关网站,有很多设计的原稿参考,而且还很有结构性
梁扬新:第一次使用javaFX技术来实现UI设计、服务器客户端交互以及数据库交互;2、第一次以团队形式在较短时间内完成项目
解决方案:查阅有关资料,和观看视频,动手实践操作测试;在做项目的过程中集中精神,与队友进行有效交流
陈力涵:对于不熟悉的语言和框架无从下手
解决方案:从头开始学习、不懂的多问队长,多与队友沟通
黄凯荣:1、没学过JavaFX,不懂得JavaFX的GUI编程;2、程序调试过程中出bug,抛出异常,不知道bug在哪。
解决方案:第一个问题,后面从组长那边的JavaFX教程中得到一些知识,仿照教程的写法去写Member页面。第二个问题,通过一个一个函数的调试,发现是出现在语言方面的问题,紧急修改了代码。
6、PSP表格(每名组员一个表格,发布在团队博客中)
柯少彬
PSP2.1 |
Personal Software Process Stages |
预估耗时(分钟) |
实际耗时(分钟) |
Planning |
计划 |
|
|
• Estimate |
• 估计这个任务需要多少时间 |
30 |
30 |
Development |
开发 |
|
|
• Analysis |
• 需求分析 (包括学习新技术) |
60 |
70 |
• Design Spec |
• 生成设计文档 |
50 |
60 |
• Design Review |
• 设计复审 |
50 |
40 |
• Coding Standard |
• 代码规范 (为目前的开发制定合适的规范) |
10 |
10 |
• Design |
• 具体设计 |
120 |
90 |
• Coding |
• 具体编码 |
1200 |
560 |
• Code Review |
• 代码复审 |
200 |
10 |
• Test |
• 测试(自我测试,修改代码,提交修改) |
100 |
30 |
Reporting |
报告 |
|
|
• Test Repor |
• 测试报告 |
20 |
30 |
• Size Measurement |
• 计算工作量 |
10 |
10 |
• Postmortem & Process Improvement Plan |
• 事后总结, 并提出过程改进计划 |
10 |
10 |
合计 |
|
1860 |
950 |
陈杉
Personal Software Process Stages |
预估耗时 |
实际耗时 |
计划 |
|
|
• 估计这个任务需要多少时间 |
180h |
16h |
开发 |
|
|
• 需求分析 (包括学习新技术) |
12h |
0.2h |
• 生成设计文档 |
6h |
0.2h |
• 设计复审 |
6h |
0.05h |
• 代码规范 (为目前的开发制定合适的规范) |
1h |
0.05h |
• 具体设计 |
50h |
5h |
• 具体编码 |
70h |
8h |
• 代码复审 |
20h |
1h |
• 测试(自我测试,修改代码,提交修改) |
10h |
0.5h |
报告 |
|
|
• 测试报告 |
2h |
0.5h |
• 计算工作量 |
2h |
5min |
• 事后总结, 并提出过程改进计划 |
1h |
0.5h |
合计 |
180h |
16h |
梁扬新
PSP2.1 |
Personal Software Process Stages |
预估耗时(分钟) |
实际耗时(分钟) |
Planning |
计划 |
|
|
• Estimate |
• 估计这个任务需要多少时间 |
20 |
25 |
Development |
开发 |
|
|
• Analysis |
• 需求分析 (包括学习新技术) |
120 |
100 |
• Design Spec |
• 生成设计文档 |
30 |
40 |
• Design Review |
• 设计复审 |
15 |
20 |
• Coding Standard |
•代码规范 (为目前的开发制定合适的规范) |
30 |
60 |
• Design |
• 具体设计 |
60 |
100 |
• Coding |
• 具体编码 |
120 |
150 |
• Code Review |
• 代码复审 |
30 |
40 |
• Test |
• 测试(自我测试,修改代码,提交修改) |
30 |
40 |
Reporting |
报告 |
30 |
30 |
• Test Repor |
• 测试报告 |
30 |
20 |
• Size Measurement |
• 计算工作量 |
30 |
30 |
• Postmortem & Process Improvement Plan |
• 事后总结, 并提出过程改进计划 |
30 |
30 |
|
合计 |
545 |
685 |
陈力涵
PSP2.1 |
Personal Software Process Stages |
预估耗时(分钟) |
实际耗时(分钟) |
Planning |
计划 |
|
|
• Estimate |
• 估计这个任务需要多少时间 |
20 |
10 |
Development |
开发 |
|
|
• Analysis |
• 需求分析 (包括学习新技术) |
30 |
20 |
• Design Spec |
• 生成设计文档 |
10 |
20 |
• Design Review |
• 设计复审 |
20 |
40 |
• Coding Standard |
• 代码规范 (为目前的开发制定合适的规范) |
30 |
30 |
• Design |
• 具体设计 |
40 |
50 |
• Coding |
• 具体编码 |
120 |
160 |
• Code Review |
• 代码复审 |
30 |
20 |
• Test |
• 测试(自我测试,修改代码,提交修改) |
30 |
40 |
Reporting |
报告 |
|
|
• Test Repor |
• 测试报告 |
15 |
30 |
• Size Measurement |
• 计算工作量 |
10 |
10 |
• Postmortem & Process Improvement Plan |
• 事后总结, 并提出过程改进计划 |
40 |
30 |
合计 |
|
405 |
460 |
黄凯荣
PSP2.1 |
Personal Software Process Stages |
预估耗时(分钟) |
实际耗时(分钟) |
Planning |
计划 |
|
|
• Estimate |
• 估计这个任务需要多少时间 |
10 |
5 |
Development |
开发 |
|
|
• Analysis |
• 需求分析 (包括学习新技术) |
30 |
15 |
• Design Spec |
• 生成设计文档 |
30 |
15 |
• Design Review |
• 设计复审 |
30 |
25 |
• Coding Standard |
• 代码规范 (为目前的开发制定合适的规范) |
20 |
15 |
• Design |
• 具体设计 |
90 |
100 |
• Coding |
• 具体编码 |
550 |
600 |
• Code Review |
• 代码复审 |
40 |
40 |
• Test |
• 测试(自我测试,修改代码,提交修改) |
90 |
100 |
Reporting |
报告 |
|
|
• Test Report |
• 测试报告 |
5 |
5 |
• Size Measurement |
• 计算工作量 |
5 |
5 |
• Postmortem & Process Improvement Plan |
• 事后总结, 并提出过程改进计划 |
5 |
5 |
合计 |
|
905 |
930 |
李家成
Personal Software Process Stages |
预估耗时 |
实际耗时 |
计划 |
|
|
• 估计这个任务需要多少时间 |
10min |
10min |
开发 |
|
|
• 需求分析 (包括学习新技术) |
30min |
40min |
• 生成设计文档 |
10min |
20min |
• 设计复审 |
10min |
15min |
• 代码规范 (为目前的开发制定合适的规范) |
20min |
20min |
• 具体设计 |
30min |
40min |
• 具体编码 |
180min |
320min |
• 代码复审 |
10min |
10min |
• 测试(自我测试,修改代码,提交修改) |
20min |
20min |
报告 |
|
|
• 测试报告 |
20min |
15min |
• 计算工作量 |
10min |
5min |
• 事后总结, 并提出过程改进计划 |
10min |
5min |
合计 |
360min |
520min |
陈皓宇
PSP2.1 |
Personal Software Process Stages |
预估耗时(分钟) |
实际耗时(分钟) |
Planning |
计划 |
|
|
• Estimate |
• 估计这个任务需要多少时间 |
20 |
10 |
Development |
开发 |
|
|
• Analysis |
• 需求分析 (包括学习新技术) |
60 |
70 |
• Design Spec |
• 生成设计文档 |
10 |
20 |
• Design Review |
• 设计复审 |
20 |
40 |
• Coding Standard |
• 代码规范 (为目前的开发制定合适的规范) |
30 |
30 |
• Design |
• 具体设计 |
40 |
50 |
• Coding |
• 具体编码 |
50 |
40 |
• Code Review |
• 代码复审 |
60 |
50 |
• Test |
• 测试(自我测试,修改代码,提交修改) |
30 |
40 |
Reporting |
报告 |
|
|
• Test Repor |
• 测试报告 |
15 |
30 |
• Size Measurement |
• 计算工作量 |
10 |
10 |
• Postmortem & Process Improvement Plan |
• 事后总结, 并提出过程改进计划 |
60 |
40 |
合计 |
|
405 |
430 |
池毓地
PSP2.1 |
Personal Software Process Stages |
预估耗时(分钟) |
实际耗时(分钟) |
Planning |
计划 |
|
|
• Estimate |
• 估计这个任务需要多少时间 |
30 |
25 |
Development |
开发 |
|
|
• Analysis |
• 需求分析 (包括学习新技术) |
60 |
80 |
• Design Spec |
• 生成设计文档 |
50 |
60 |
• Design Review |
• 设计复审 |
50 |
45 |
• Coding Standard |
• 代码规范 (为目前的开发制定合适的规范) |
0 |
0 |
• Design |
• 具体设计 |
60 |
90 |
• Coding |
• 具体编码 |
180 |
210 |
• Code Review |
• 代码复审 |
10 |
10 |
• Test |
• 测试(自我测试,修改代码,提交修改) |
20 |
30 |
Reporting |
报告 |
|
|
• Test Repor |
• 测试报告 |
20 |
30 |
• Size Measurement |
• 计算工作量 |
10 |
10 |
• Postmortem & Process Improvement Plan |
• 事后总结, 并提出过程改进计划 |
10 |
10 |
合计 |
|
500 |
590 |
黄钰栋
PSP2.1 |
Personal Software Process Stages |
预估耗时(分钟) |
实际耗时(分钟) |
Planning |
计划 |
|
|
• Estimate |
• 估计这个任务需要多少时间 |
30 |
25 |
Development |
开发 |
|
|
• Analysis |
• 需求分析 (包括学习新技术) |
60 |
80 |
• Design Spec |
• 生成设计文档 |
50 |
60 |
• Design Review |
• 设计复审 |
50 |
45 |
• Coding Standard |
• 代码规范 (为目前的开发制定合适的规范) |
0 |
0 |
• Design |
• 具体设计 |
60 |
90 |
• Coding |
• 具体编码 |
180 |
210 |
• Code Review |
• 代码复审 |
10 |
10 |
• Test |
• 测试(自我测试,修改代码,提交修改) |
20 |
30 |
Reporting |
报告 |
|
|
• Test Repor |
• 测试报告 |
20 |
30 |
• Size Measurement |
• 计算工作量 |
10 |
10 |
• Postmortem & Process Improvement Plan |
• 事后总结, 并提出过程改进计划 |
10 |
10 |
合计 |
|
500 |
590 |
第二部分:团队选题
1、团队选题展示过程中,老师和同学提出了一些问题。有没有哪个问题你们想重新回答?
每局游戏结束之后胜利者和失败者分别会有什么结果?
答:胜利方将会获得积分,到达一定的积分就会获得特殊称号;失败方将会减去一定积分,在当前积分不够的时候,将会失去特殊称号。
在上一次展示中,老师认为我们的项目在设计细则上不够完善,对于这个问题,我们进行重新回答:
我们将会在游戏过程中,设计的每一个绘图环节初步定为30秒,每个游戏环节结束后,将会对关于答案的小知识,进行大约5秒的展示,这样既不会由于时间过短导致传播小知识的目的无法达到,又不会让玩家感到厌烦。
2、在上次团队选题之后,你们组有什么新的思考和想法?有什么具体的行动,列出具体行动。
在正式选题之后,我们对开发项目需要的技术进行了进一步的讨论,增加了对新技术的要求:javafx、socket等。
行动:组员开始对新技术的学习,自己在本地多进行实践和测试。细化了分工,将前端又分为逻辑部分、服务器部分,使每个人对自己的分工更加明确。
当今游戏最大的难题就是玩家玩腻了,要使这个游戏改变这种窘迫,我们决定要增添主题板块,主题可以有多种类型,比如趣味类型、学习类型,而这些主题里面包含的是当今比较流行的词汇,来吸引玩家兴趣。我们会进行不定时的更新词库和主题数
行动:平时多注意热点时事,收集高频词汇;在身边进行问卷调查,收集不同人群的兴趣爱好