这个作业属于哪个课程 | Fzusdn |
---|---|
这个作业的要求在哪 | 2022秋软工实践 第二次结对编程 |
这个作业的目标 | 设计点名算法 |
队友学号 | 032002624 |
学号 | 032002640 |
作业描述及分析
背景
栋哥对大家第一次结对编程作业的原型设计感到很满意,为了尽快让同学们使用上软件,于是栋哥花一晚上时间开发了一个点名小程序。但是在上线运行过后,发现了一些问题:
大多数老师习惯在每次上课后或下课前的一小段时间内进行点名。
如果采用全点的方式,在这段时间里,后端服务器需要处理大量的请求,拥塞导致响应速度变慢,给点名小程序带来极差的使用体验。
采用随机抽点的方式,能够有效减少并发量,但是无法保证点名的质量,难以有效抓出没有到教室的同学。
所以栋哥急需大家设计一个算法来解决这个问题,要求能够最小化向后端发送的请求次数,最大化抓出缺勤同学的数量
我觉得缺勤算法,关注绩点本身是个很好的切入点,但是不能过分追求,毕竟我们所了解到的,并不是大部分绩点低的都喜欢翘课,相反,绩点高的人群也存在翘课现象,不能一概而论,我们更应该为这个算法添加一点人性化的比例,以及我们在绩点的随机上面,不能单纯地使用库函数提供给我们的正态分布随机函数,更应该考虑一下我们学生实际的绩点分布情况。
具体要求
定义5门课程,每个课程班级人数为90人,一学期共20次课。每门课程均有5-8位同学缺席了该学期80%的课,此外每次课程均还有0-3位同学由于各种原因缺席
评分标准
代码仓库
重点部分展示
数据集生成
因为5门课是等价的,所以我们只考虑一门课,采用C库函数和数组生成数据集。1表示出席,0表示缺勤。
数据生成样例
点名算法
重点:在抽尽可能少的同时保证有效抽点次数最大化
算法设计思路
- 第一节课点名,点到r名缺席学生后停止点名,记录学号
- 接下来的课程对缺席的r名学生进行全点
- 分析数据,确定合理的r的值
运行结果分析
随着概率的增大,整体的E值也会不断增大。
E = 0.26
PSP
PSP | Personal Software Process tags | 预估耗时/分钟 | 实际耗时/分钟 |
---|---|---|---|
Planning | 计划 | 60 | 60 |
Estimate | 估计这个任务需要多少时间 | 60 | 60 |
Development | 开发 | 1585 | 1840 |
Analysis | 需求分析 (包括学习新技术) | 60 | 60 |
Design Spec | 生成设计文档 | 45 | 45 |
Design Review | 设计复审 | 30 | 30 |
Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 90 | 45 |
Design | 具体设计 | 150 | 180 |
Coding | 具体编码 | 1000 | 1300 |
Code Review | 代码复审 | 120 | 60 |
Test | 测试(自我测试,修改代码,提交修改 | 90 | 120 |
Reporting | 报告 | 40 | 50 |
Test Report | 测试报告 | - | - |
Size Measurement | 计算工作量 | 20 | 15 |
Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 20 | 35 |
Total | 合计 | 3370 | 3900 |
学习进度表
第N周 | 新增代码(行) | 累计代码(行) | 本周学习耗时(小时) | 累计学习耗时(小时) | 重要成长 |
---|---|---|---|---|---|
1 | 90 | 130 | 4 | 4 | 熟悉C库的各个方法 |
2 | 100 | 265 | 3 | 7 | 对比性能 |
3 | 20 | 285 | 1 | 8 | 验证合理性和稳定性 |
写在后面
结对照片
感想
032002640
队友太好了,下次还要一起捏,呜呜呜呜
032002624
我遇到这个队友真是三生有幸