这个作业属于哪个课程 | 2020春季软件工程W班 |
---|---|
这个作业要求在哪里 | 团队作业第二次要求 |
这个作业的目标 | 使用Github进行团队协作 |
作业正文 | 本文链接在这里! |
其他参考文献 | 《构建之法》 |
Part 1 关于此次作业
(1)组员职责分工
- 221701436:组织小组参与讨论分工,测试,修复bug,补充未完善的操作,博客第二部分撰写
- 221701435:ui界面和部分方法的实现
- 221701426:询问需要检测的模块,编写检验程序
- 181700141:一部分业务规则和一部分具体实现
- 221701401:一部分业务规则和一部分具体实现
- 221701402:数据库接口和操作类(DBUtil&DAO)
- 221701403:因为没有电脑限制了我很多行动,我有一颗参与代码实现的心却没有工具,以致这次团队实践我只能充当个混子,能起到的作用也就提提问题意见,希望在下一次团队实践来之前能开学,我想为团队贡献更多力量。
221701309:对应每张表编写一个对应实体类(类中需包含get和set方法,以及相应的检测方法调用),进行博客第一部分的整合。
(2)github 的提交日志截图,统计各组员的commit次数
github仓库:https://github.com/metro1435/live-project
A.日志截图
B.各组员commit次数
- 221701436:4次
- 221701435:4次
- 221701426:1次
- 181700141:3次
- 221701401:3次
- 221701402:5次
- 221701403:0次
- 221701309:5次
(3)程序运行&GUI界面截图
初次进入系统时显示如下界面,“登记”按钮暂不可用
点击“预约”,弹出预约界面,可选择开始或结束预约
点击“开始预约”后,“登记”按钮变为可用
点击“登记”,弹出登记须知
点击“确定”后,进入登记页面,登记完成后返回主界面
点击“查询”,弹出查询页面,输入预约号即可查询
(4)程序运行环境
IntellJ IDEA
- 将整个项目导入到IDEA即可运行
- 需要手动配置与MySQL数据库的连接参数,及导入Jar包。
(5)基础功能实现
- 通过按钮实现预约系统的定时开放
- 登记预约信息
- 随机抽取符合条件的预约
- 通过输入预约号查看是否中签
(6)程序截图
1、DAO数据控制类
2、数据库链接类DBUtil
3、处理抽取用户预约的类Extract
4、抽签的核心功能函数drawlots
5、用于处理用户登记信息的Registration类
(7)困难&解决方法
- 221701436
问题:测试时有难以发现的bug,代码复审时有分工的部分存在逻辑上的矛盾
解决方法:查找资料,想尽一切可能导致出错的原因(如中文括号),与参与施工的人进行沟通化解分歧。
- 221701435
团队里大部分都不太会web后端服务,所以只能使用大二学习的javaswing来实现,swing部分的知识大家都忘的差不多了,gui界面由我来负责,我也只能靠查询资料来解燃眉之急。在背景图片处,我很难处理,因为在swing组件中,label是不能设置透明,而jframe下很难实现背景图片,因为有些我也没有深思的原因,感觉是无法加载出来组件。后面我还是在frame的条件下,用label去实现,不过最后还是会背景为白色。在触发器部分的话,因为第一次合作,大家代码规范都不是很好,导致bug很多,也不知道怎么处理,就很麻烦,一开始的讨论也没有讨论清楚,思考就占据了大部分写代码的时间,导致代码无法编写完成。并且课程安排也不太合理,周六刚交完上一次作业,上完课,组内大部分同学的精神状态非常低,并且只给予半天的时间作业,希望也明白难处。
- 221701426
问题:不知道如何实现的功能或者复杂的功能
解决方法:抄代码然后根据实际情况改造
- 181700141
问题:开发过程数据库操作忘记掉,业务设计之前需求分析偏差导致业务设计遇到问题,然后花费较多时间去业务设计。
解决方法:通过调用队友的数据库接口实现操作,业务设计则再重新确定需求后得以进一步设计下去。
- 221701401
问题:前三次中签的查询安排
解决方法:跟队友一起研究
- 221701402
问题:数据库如何运行不起来,数据库的封装和使用
解决方法:导入jar包 - 221701403
问题:硬件设施上没有电脑无法实际操作,本来想设计个原型都没法完成。软件上太久没碰过java导致很多知识点忘却
解决方法:硬件设施暂时还没有解决方法只能期盼早点开学,java知识点虽然可以通过资料复习但是远不如实际打代码复习来得有效。
- 221701309
问题:最开始拿到任务的时候不太清楚自己具体该做什么
解决方法:通过与组长以及小组成员通话明白自己的任务,从而能够进入具体编程阶段
(8)评估每位组员的贡献比例(总分100)
学号 | 姓名 | 贡献比例 |
---|---|---|
221701436 | 林晟 | 11% |
221701435 | 缪浩涵 | 19% |
221701426 | 郑志成 | 8% |
181700141 | 吴鸿敬 | 18% |
221701401 | 黄素芳 | 16% |
221701402 | 王小雅 | 11% |
221701403 | 王吁伊 | 4%(电脑不在手边但参与讨论) |
221701309 | 黄秋妍 | 11% |
(9)PSP表格
- 221701436
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 10 | 15 |
Estimate | 估计这个任务需要多少时间 | 3 | 3 |
Development | 开发 | 2000 | 3200 |
Analysis | 需求分析 (包括学习新技术) | 60 | 80 |
Design Spec | 生成设计文档 | 60 | 100 |
Design Review | 设计复审 | 20 | 20 |
Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 15 | 15 |
Design | 具体设计 | 40 | 60 |
Coding | 具体编码 | 2000 | 3000 |
Code Review | 代码复审 | 40 | 40 |
Test | 测试(自我测试,修改代码,提交修改) | 40 | 40 |
Reporting | 报告 | 10 | 20 |
Test Repor | 测试报告 | 10 | 10 |
Size Measurement | 计算工作量 | 5 | 5 |
Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 30 |
合计 | 4343 | 6638 |
- 221701435
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 90 | 90 |
Estimate | 估计这个任务需要多少时间 | 650 | 860 |
Development | 开发 | 540 | 720 |
Analysis | 需求分析 (包括学习新技术) | 30 | 30 |
Design Spec | 生成设计文档 | 30 | 30 |
Design Review | 设计复审 | 30 | 30 |
Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 30 | 30 |
Design | 具体设计 | 120 | 150 |
Coding | 具体编码 | 180 | 330 |
Code Review | 代码复审 | 60 | 60 |
Test | 测试(自我测试,修改代码,提交修改) | 60 | 60 |
Reporting | 报告 | 110 | 140 |
Test Repor | 测试报告 | 30 | 60 |
Size Measurement | 计算工作量 | 20 | 20 |
Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 60 | 60 |
合计 | 740 | 950 |
- 221701426
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 20 | 15 |
Estimate | 估计这个任务需要多少时间 | 10 | 0 |
Development | 开发 | 20 | 20 |
Analysis | 需求分析 (包括学习新技术) | 60 | 30 |
Design Spec | 生成设计文档 | 10 | 0 |
Design Review | 设计复审 | 30 | 20 |
Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 0 |
Design | 具体设计 | 30 | 30 |
Coding | 具体编码 | 120 | 180 |
Code Review | 代码复审 | 30 | 20 |
Test | 测试(自我测试,修改代码,提交修改) | 30 | 20 |
Reporting | 报告 | 20 | 10 |
Test Repor | 测试报告 | 20 | 10 |
Size Measurement | 计算工作量 | 20 | 0 |
Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 5 |
合计 | 460 | 360 |
- 181700141
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 60 | 70 |
Estimate | 估计这个任务需要多少时间 | 30 | 40 |
Development | 开发 | 30 | 30 |
Analysis | 需求分析 (包括学习新技术) | 100 | 100 |
Design Spec | 生成设计文档 | 30 | 30 |
Design Review | 设计复审 | 20 | 20 |
Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 20 | 20 |
Design | 具体设计 | 90 | 100 |
Coding | 具体编码 | 90 | 100 |
Code Review | 代码复审 | 10 | 10 |
Test | 测试(自我测试,修改代码,提交修改) | 20 | 20 |
Reporting | 报告 | 20 | 20 |
Test Repor | 测试报告 | 10 | 10 |
Size Measurement | 计算工作量 | 10 | 20 |
Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 30 |
合计 | 570 | 600 |
- 221701401
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 20 | 30 |
Estimate | 估计这个任务需要多少时间 | 20 | 30 |
Development | 开发 | 340 | 525 |
Analysis | 需求分析 (包括学习新技术) | 60 | 70 |
Design Spec | 生成设计文档 | 30 | 75 |
Design Review | 设计复审 | 10 | 20 |
Coding Standard | 代码规范 (为目前的开发制定合适的规范) | - | - |
Design | 具体设计 | 40 | 70 |
Coding | 具体编码 | 120 | 150 |
Code Review | 代码复审 | 60 | 100 |
Test | 测试(自我测试,修改代码,提交修改) | 20 | 40 |
Reporting | 报告 | 56 | 73 |
Test Report | 测试报告 | 20 | 30 |
Size Measurement | 计算工作量 | 6 | 8 |
Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 35 |
合计 | 416 | 628 |
- 221701402
Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|
Planning | 计划 | 30 |
Estimate | 估计这个任务需要多少时间 | 30 |
Development | 开发 | 230 |
Analysis | 需求分析 (包括学习新技术) | 10 |
Design Spec | 生成设计文档 | |
Design Review | 设计复审 | |
Coding Standard | 代码规范 (为目前的开发制定合适的规范) | |
Design | 具体设计 | 30 |
Coding | 具体编码 | 120 |
Code Review | 代码复审 | 40 |
Test | 测试(自我测试,修改代码,提交修改) | 30 |
Reporting | 报告 | 5 |
Test Repor | 测试报告 | - |
Size Measurement | 计算工作量 | 5 |
Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 5 |
合计 | 295 |
- 221701403
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 90 | 105 |
Estimate | 估计这个任务需要多少时间 | 10 | 10 |
Development | 开发 | 120 | 0 |
Analysis | 需求分析 (包括学习新技术) | 60 | 100 |
Design Spec | 生成设计文档 | 0 | 0 |
Design Review | 设计复审 | 0 | 0 |
Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
Design | 具体设计 | 100 | 0 |
Coding | 具体编码 | 120 | 0 |
Code Review | 代码复审 | 60 | 0 |
Test | 测试(自我测试,修改代码,提交修改) | 30 | 0 |
Reporting | 报告 | 20 | 10 |
Test Repor | 测试报告 | 30 | 0 |
Size Measurement | 计算工作量 | 0 | 0 |
Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 50 | 60 |
合计 | 690 | 285 |
- 221701309
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 30 | 30 |
Estimate | 估计这个任务需要多少时间 | 5 | 5 |
Development | 开发 | ||
Analysis | 需求分析 (包括学习新技术) | 60 | 60 |
Design Spec | 生成设计文档 | 30 | 30 |
Design Review | 设计复审 | 5 | 5 |
Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 20 | 10 |
Design | 具体设计 | 30 | 20 |
Coding | 具体编码 | 60 | 120 |
Code Review | 代码复审 | 10 | 10 |
Test | 测试(自我测试,修改代码,提交修改) | 10 | 10 |
Reporting | 报告 | 5 | 10 |
Test Repor | 测试报告 | - | - |
Size Measurement | 计算工作量 | 5 | 5 |
Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 60 |
合计 | 300 | 375 |
Part 2 问题反馈&思考
(1)团队答辩时问题答复
-
对于超越小黑板,你们是否有信心?
有信心!小黑板虽然在用户之间有已经良好的口碑,短时间无法超越,但是我们可以通过微信公众号,邀请小黑板作为贡献者入驻等宣传方式,提高我们的知名度和宣传我们的优势。
-
校园新闻的来源有哪些?是数据抓取吗?
大部分通过学校各官方网站抓取,一部分(比如学生福利等)需要人工收集发布。
-
与论坛的功能非常类似,后台考虑如何管理信息?
采用标签化管理
-
热门话题采用什么算法
使用相似度矩阵进行层次聚类分析,选取最大的类作为最能代表文本类内容的话题词组。
-
如何快速判断当前用户输入的问题,跟过去提过的问题是类似的?准备做文本分析吗?
文本具有了主题分部向量,通过聚类分析得到接近的话题
-
有考虑敏感内容屏蔽吗?
当然有,通过调用API实现屏蔽
-
是不是有考虑让某些用户成为专职的“提问者”和“解答者”?
有的,给特定用户一些权限可以让用户参与度更高
-
那如果用户群较多,你们操作的工作量会很大吗
我们会设计一些算法减轻后台的工作量
-
用户是采用自由注册吗,还是和学号绑定?
学号绑定,毕竟是软件是关于福大的,目标就是为了让福大学生了解校内新闻。其他用户没必要帮其进行整理。
-
类似知乎?那么对比知乎的功能了吗?
我们的校园热话功能类似知乎,对比知乎,我们除了关注者功能之外其他都有做。
-
知乎因为不面向校内,就不是你们的竞品了吗?授课老师推荐?
是我们的竞品,因为用户可以选择浏览校内或校外新闻。但是我们比知乎有更能帮助校内用户的功能。授课老师推荐主要还是根据用户评价的数据分析。
(2)团队选题之后,新的思考和想法
-
同学A:产品在90%的人的市场无法竞争过别人,那么就把剩下10%的人伺候得足够好。
-
同学B:可以增加一些不只是是校内的新闻,可以让大家看看最近发生的实时啥的
-
同学C:我认为在原来的基础上可以增加信用度这样一个标准,虽然是个匿名平台,但是涉及到评价校内
老师和教学以及交易买卖,信用是很重要的。每个匿名用户获得相同的初始信用度,信用度怎么改变?来源于其他人的评价,这就需要增加一个评价其他用户的功能。获得好评可以增加信用度,获得差评则减少信用度。信用度加到一定值可以享受发言显示优先等特权,信用度减到一定值则被禁言或其他处罚 -
同学D:应当充分调研市场,发现和对比竞品,尽力做到最好。
-
同学E:团队选题之后,我其实挺迷茫的,因为前一天才说是二手交易,然后睡了一觉就变成了,福大热搜???这个其实对我们都是前端的队伍难度系数非常大,因为我们没有一个好的后端,算法部分我们基本是一窍不通。后面几天就很迷茫,只能平常多了解一下这些东西了
Part 3 事后反思==>负荆请罪
- 221701436
时间很仓促,我们只能尽全力而为,初次合作,困难在所难免。我们开始合作时的不足之处就在于:对于使用Github管理项目还不习惯,暂时使用群内共享文件的形式,尽管组内分工明确,但是各成员进度不同导致开发时很不协调。我们在实践的过程中渐渐体会到使用GIThub进行团队合作的好处,效率渐渐提高。尽管任务紧迫,交流受限,组员还是拿出了十足的战斗精神,互相鼓励,互相学习,尽全力写好代码。尽管程序并不是很完善,但是看着组员们拼搏的样子,我觉得我们小组的每个人都是值得敬佩的
- 221701435
感觉自己组织方面还是非常差,一开始感觉就是效率非常低,因为大家都是第一次合作,gui界面写完后,等待了好久他们的方法,结果才知道还在思考的部分,就只能加入他们先把方法,搞定。然后的话是一开始的架构,也没有思考清楚,导致后面方法非常的乱,代码规范也大相庭径。看起代码很吃力。总结还是合作方面太弱了,有点茫然吧。
- 221701426
技术不熟练,没有帮上太大忙。遇到问题可以在组内提出,而不是一个人死磕。有不清楚的地方可以讨论。
有空闲的时间,可以给其他组员帮忙。遇到技术问题,自己没办法解决,可以去参考已有的解决方案
- 181700141
在进行具体类图设计之前应该要把需求分析正确避免分析不准确后续再去修改类图。团队开发中在开发之前应该要确定自己负责的那部分对外接口以及应该实现的功能,并告知队友。开发过程中不能修改对外的接口名和自己要实现的功能。最后对于以前学习过的知识应该多练习要不然容易忘记
- 221701401
这次是第一次团队协作,让我深刻认识到了自己的不足,从沟通到各种工具的使用,都不行,考虑做法也考虑了很久,进度也跟不上,很多问题都处在我身上(谢罪)
- 221701402
从早上8点30开始的团队实训终于要在23:30结束了,做的项目成果不是很尽人意,大家都有各种各样的问题,一开始题目就不是很理解,后面分析了很久,但是我相信我的团队,时间很赶,大家也是都没有怨言,辛苦大家了!希望下次继续努力!加油!下次一定会更好!
- 221701403
第一次合作,时间非常紧迫
写啥都报错,不写又不给过
功能虽不多,奈何技术太弱
弱是我的锅,全靠队友带我
脑内没存货,平时实操不多
思想不灵活,干瞪题目上火
希望下一次,代码带来快落
- 221701309
第一次团队作业我不再是一个人独立前行,有同伴的支持和鼓励让我们始终不放弃彼此,也没有被困难打倒,一直坚持到最后。必须深刻反思的是,因为我个人能力不够优秀,并不能提高团队的开发效率,为此我很愧疚,在此,我想跟我的队友们说声抱歉。但是,虽然我们开发的不够完美,但我们已经竭尽全力,一天的时间,可以说我们除了吃饭就在打代码了,没有一分钟消极怠工。这是我们第一次合作,也许不够好,但是我们未来会更好!