2022秋软工实践结对作业二

这个作业属于哪个课程	Fzusdn
这个作业要求在哪里	2022秋软工实践结对作业二
这个作业的目标	学会需求分析，考验不断优化方案的能力
学号	032002422
我的博客	https://blog.csdn.net/lindejisuanji?type=blog
队友学号	032002420
队友博客	https://blog.csdn.net/m0_61758141?type=blog

一、重难点的思考与解决

1.如何生成数据集？

**“数据集”**是包含数据表的对象，在本地内存中为应用程序提供了待用数据的缓存，可以在这些数据表中临时存储数据以便在应用程序中使用。

了解了什么是“数据集”之后，我们决定使用java程序–>连接MySQL数据库–>在MySQL数据库中生成数据集，同时用java程序控制数据库中数据集导出为文本文件。
（在这个过程中，“java程序”作为题目需要的“数据集生成器”。）

2.如何实现java程序和MySQL数据库的交互？

在此之前，我们既学过MySQL数据库的运用，也学过java之类高级语言程序代码的编写，但是如何将这两者统一成有机的整体仍然需要花费许多时间。

搭建环境的整体步骤可参考Github仓库中的"README.md"，详细过程可以自行学习

3.“数据集生成的方法”与“点名算法”之间的联系？

一开始我们的想法是：无论准备采用怎样的算法优化，似乎都与数据集的生成方式有着不可分割的联系。

比如，如果想利用“绩点”作为辅助优化因素，在优化后将偏向于抽点低绩点的学生，那是否意味着数据集的生成就需要按照低绩点的同学中缺勤率高的情况来生成数据？

在经过这样的思考后，我们不禁产生疑问，在此次作业过程中，究竟是“数据集”先生成还是“优化算法”先生成？

有这么一个假设：如果数据集中，每个同学是否缺勤完全是随机性的

那么此时，优化算法似乎就没有意义，因为任何涉及的“辅助因素”，比如绩点、是否同宿舍一起缺勤、是否有缺勤的习惯之类的因素都变得没有参考价值。在没有任何依据的前提下也只能进行随机抽取？（仅代表编者观点，可能有误）

在经过讨论之后，我们决定还是先设计算法，通过算法中的辅助优化因素（我们采用“绩点”）来作为生成数据集的“依据”规律。
意味着生成的数据集中是符合着某种“规律”的，并不满足完全随机性。

二、结对过程

三、结对感受以及思想碰撞的火花

• lzl：跟队友的两个合作还是让我收获了很多，我从队友身上学到了很多优秀的品质

  1.做事情稳重而可靠 -->遇到困难从不抱怨，冷静的解决问题，总能在计划的时间内完成原定任务目标
  2.思维广阔–>在对于需求的探讨过程中给了我很多新的观点，让我们的开发可以有更广阔的视野

• lwz:第一次与队友合作讨论问题，编写代码，让我受益匪浅，发现队友的闪光点。

  1.自主学习能力强：小程序制作思想和语言多样，选择适合的进行学习，并最终有成果
  2.持之以恒：坚持完成一件事，克服困难。

四、讨论与收获

1.关于题目的需求分析

在本次任务的开始，如何开展困扰着我们两个人很久，我们始终无法对题目表达的意思做出一个明确、清晰的阐释。开展初期，先是在设计辅助因素的选择上，后来是在数据集的生成上，我们断断续续有过三四个小时的讨论，才初步确定了大体方向。

俗话说 “万事开头难，然后中间难，然后结尾难 ”，最后回过头看，虽然当时的讨论花费了很多时间，但却是十分有价值的，既加深了队友之间的交流，也为双方都打开了更广阔的思考空间。

2.关于“算法”意义的审视

在初步完成思路的实现，将要进行优化测试的阶段。我们开始对此次算法的意义进行思考。优化算法的存在意义是为了尽可能点出缺勤的同学，但其更重要的意义是让同学重视点名，从而不敢轻易产生缺勤的行为。

所以即使抽点的准确度无法达到很高的水平，但是只要同学们觉得“如果缺勤，被抽点到的概率就很高”这样的想法就够了

比如一次性点半个班级的人，那么虽然有可能有一般缺勤的同学没有被抽到，但是“引起重视”的目的已经达到了（当然不可能一次抽这么多人），所以我们决定采用“分层抽样”的思路来进行算法优化。

结对合作很重要的一部分就是交流，两个人的不断思考、补充、再思考可以构建一个更加完备的实现框架。

五、PSP 和学习进度条

1.PSP

PSP	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	· 计划	30	60
· Estimate	· ‘估计这个任务’ 需要多少时间	20	30
Development	· 开发	120	140
· Analysis	· 需求分析 (包括学习新技术)	480	500
· Design Spec	· 生成设计文档	30	30
· Design Review	· 设计复审 (和同事审核设计文档)	30	30
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	45	40
· Design	· 具体设计	120	140
· Coding	· 具体编码	120	150
· Code Review	· 代码复审	45	40
· Test	· 测试（自我测试，修改代码，提交修改）	40	40
Reporting	报告	45	45
· Test Report	· 测试报告	30	30
· Size Measurement	· 计算工作量	30	30
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	30	30
合计		1215	1335

2.学习进度条

第N周	新增代码（行）	累计代码（行）	本周学习耗时(小时)	累计学习耗时（小时）	重要成长
1	138	138	10	10	熟悉了java语言的编写，基本实现了数据库连接程序的应用
2	127	265	11	21	尽自己理解的分析了题目需求，学会了对于从多个角度看待事件

六、GitHub 仓库地址和 commit 记录

GitHub 仓库地址：作业仓库

commit 记录： 截止至10.12 （0：36分）

七、算法介绍

1. 数据前提

①题目设计的“0-3位同学由于各种原因缺席”我们理解为“请假”，所以把这部分同学当作没有缺勤考虑。
②题目设计的“每门课程均有5-8位同学缺席了该学期80%的课”我们进行了很简略、粗暴的处理-----直接当作“每节课固定缺勤n个人”。
这样做的原因：

数据集生成器无法实现在不同课程中对不同缺勤人数正确地做出适应性变化

既然数据集生成器无法实现在不同课程中对缺勤人数正确地做出适应性变化，那只能尽量设定一个缺勤人数的下限，来模拟算法运行(本题，设定为n=6)。

如果此下限的E满足我们的需求，那么缺勤人数大于此下限的情况的E也应该满足我们的需求

我知道这个前提问题很大，但是窝太菜力

2.过程

① 用“绩点”作为辅助优化因素，进行分层抽样（3.* 、2.* 、1.*）；
② 每个“层”抽到一个人就停下（再抽E就变小啦），同时排除上节课“缺勤且被抽点到”的同学；
③ 对每个层抽点人数的上限进行一定约束（不能无限抽直到抽到缺勤学生）；
④ 最终结果 E 基本稳定在0.1~0.2之间。
（没了…QAQ）

上述是我们本来的想法，但发现同学们好像都默认“上课后可以知道全体同学的出勤情况”，而不是“只要没抽到缺勤，就默认为到场”。

因此，我们对数据前提进行了改变，算法也因而改变：
①用“绩点”作为辅助优化因素，进行分层抽样（3.* 、2.* 、1.*）；
②第一次点名根据绩点进行分层抽样
③第二次点名及之后，根据上节课缺勤人员，进行重点性点名，当然同时也有对其他同学进行抽点，只是概率较小

最终结果，E在0.5上下波动，但目前稳点性较差

3.演示结果

4.模块化

数据集方面：
基于数据库的方式可以很好进行数据集的存储和移植，可以很好在不同主机上使用。

程序方面：
基于java开发，可以导出作为 .jar包 进行移植