“东三在线”软工项目选题报告
项目编号：2
"东三在线"
软工项目选题报告
"东三在线"团队出品
目 录
word文档链接：
https://kdocs.cn/l/coIEdBPJ0zvi
1. 项目目标及意义
1.1.项目背景
近年来教育部对大学生课堂提出了“严进严出”的新要求，日常的上课考勤点名已经成为了每个高校保证学习质量的必要手段。但是，大部分的高校仍然采取传统的人工点名方式，如念名字喊到、在签到表上打钩签字，这些方式简单直接却不够便捷，且存在重复点名、反复确定请假同学状态和课间错过点名等异常情况。虽然一批新兴的学习系统也提供基础的课堂签到服务，如雨课堂的扫码签到，学习通的拍照签到，但这些服务高度依赖于其原生平台，且忽略了考勤数据的共享特性。在这种情况下，我们需要建设一个专用于高校考勤场景的多端服务平台，能满足普通学生自主签到、考勤人员依照名单点名以及教师或辅导员查看考勤统计数据的需求，优化考勤全流程用户体验。
1.2.项目概述
本项目是为了满足当今大学课堂的需求而创建的。我们希望通过这个项目来帮助广大学生更好地适应现代教学模式，提高他们的学习效率和体验。旨在建设一个专用于高校考勤场景的多端服务平台，实现学生考勤管理的数字化与自动化，并为教师和辅导员提供考勤数据可视化服务。该平台提供学生定位签到的考勤功能，分为全员点名与基于历史点名情况进行随机抽取点名，故能够根据实际情况智能地选择学生进行点名。教师、辅导员和学生均可即时获取考勤记录与详细信息，方便管理与查询。
此外，该平台还支持多种考勤方式，如人脸识别等，以确保考勤数据的准确性。签到信息将由老师或学生督导进行发出，学生将使用手机小程序进行签到并可对自身的考勤情况进行查看，教师和辅导员可通过网页端对详细的考勤情况进行查看，该平台能够为其提供全面、可视化的考勤数据，简化了繁琐的考勤统计工作。学生也可通过此平台，向辅导员发出请假需求，简化了请假流程。
通过该高校考勤场景的多端服务平台，可以有效减少传统考勤管理的繁琐流程，提高考勤的准确性和效率。同时该先进的考勤管理工具，能促进学生出勤率的提高与简化教师的考勤统计工作，这将有助于提升学校的教学管理水平和学生的学习体验。
1.3.项目目标
建设一个专用于高效考勤场景的多端服务平台，具体实现如下功能：
学生端（适用对象为普通学生以及学生督导队员）：学生通过微信小程序登陆账户并认证校园身份后，可查询本学期课表以及课程的考勤情况（已点名/正在点名/未点名），并查询个人的考勤历史记录，如果有出现考勤异议，可以进行考勤申诉，由督导队员或辅导员进行审批。学生还可以在相应界面进行日常的请假申请，申请结果将由辅导员审批；同时，学生端也服务于日常负责考勤的学生督导队员，为了区分督导队员与普通学生，两者界面略有差异。督导队员界面录入学生选课名单，在课前使用系统进行名单点名。名单点名实现盲操作，通过手指的滑动切换学生姓名和对应的状态（出勤/缺勤/请假等）。在名单点名的同时，督导队员发布定位签到任务，被考勤学生可在授课教室完成定位签到。签到统计数据实时反馈到考勤人员，动态调整点名名单。
教师端（适用对象为授课教师以及辅导员）：教师或辅导员通过web端登陆账户并认证校园身份后，教师可查询所授课程的学生考勤单次以及统计的数据，还可以设置相应权重，根据出勤率进行平时分计算，最终可导出为excel表格文件以便期末成绩的计算。还可以根据需求在上课时进行随机点名提问。辅导员登录后可查询年级各课程/行政班的考勤统计数据（可视化展示），还可以对学生的考勤异议情况进行审核，及时审批学生请假申请。
1.4.项目意义
我们希望高校考勤场景的多端服务平台的项目的落地，能够提高学校的管理效率，减少因为程序冗杂和工作失误而造成的损失，避免出现教师了解情况难，督导队整理数据难，学生考勤申诉难。同时，能够提高学生出勤率和教师的授课质量，使教育资源得到更充分的利用，通过该平台的实时考勤功能，学生无法逃避考勤，能够有效地提高学生的出勤率。教师和辅导员也可以根据学生的考勤数据进行统计和分析，及时发现学生的出勤情况，对缺勤学生进行关注和干预，提高学生的出勤率和学习效果，同时也为教师提供了有针对性的授课反馈和改进机会，提高了教师的授课质量。 此外，能够简化考勤流程和减少人力资源消耗，传统的考勤管理流程，需要大量的人力资源参与，耗费人力和物力。而该平台通过自动化和数字化的方式，简化了考勤流程，减轻了管理人员的工作负担，节约了时间和人力资源。
2. 项目可行性分析
2.1.规模及难度
2.1.1.规模
学生端小程序：学生端小程序主要用于学生进行考勤签到、查看考勤记录，考勤申诉和请假申请等基本功能。因此，相对来说，学生端小程序的规模通常较小。
教师端web端：教师端web端需要包含更多的功能，如学生考勤管理、考勤统计分析、班级管 理、设置考勤规则，审批请假申请等，且要统计实时数据，动态调整点名名单，导出考勤数据。 相对来说，教师端web端的规模通常较大。
2.1.2.难度
学生端小程序：学生端小程序相对较为简单，主要是提供简单的界面和基本的功能，与后台服务器进行数据交互。对于开发者而言，需要熟悉小程序框架，了解用户需求，并进行简单的业务逻辑开发。
教师端web端：教师端web端相对较为复杂，需要进行用户权限管理、数据统计分析、多种数据展示、规则配置等功能开发。同时，还需要与后台数据库进行数据交互。对于开发者而言，需要具备较强的前端和后端开发技能，熟悉web开发框架，并能够处理复杂的业务需求。
综上所述，学生端小程序相对规模较小、难度较低，更侧重于提供基本功能和良好的用户体验；而教师端web端需要处理更多的功能和数据，因此规模较大、难度较高。因此在开发过程中需要根据实际需求确定开发资源和人力安排。
2.2.人员
2.2.1.确定项目需求
该项目总体需要UI设计、前端、后端、PPT制作四个方面的人员安排，其中UI设计2名，前端5名、后端4名、PPT制作1名。
2.2.2.团队成员的技能和专业背景
团体成员中有两位为计算机科学与技术专业的学生，八位为数据科学与大数据技术专业的学生，具有一定的基础编程能力和自学能力。其中两位同学擅长制作PPT以及接触部分UI设计。
2.2.3.确定人员分工和职责
首先根据需求和成员特长之处进行分组，接着根据项目方案总方向的三个阶段进行细致安排工作。人员安排合理，任务时间长度适中。
2.2.4.建立有效的沟通机制
通过每周三组会进行线下沟通，解决困难之处。平常在QQ上建立了有效的交流平台，方便各个成员进行及时工作反馈与咨询。
2.2.5.风险评估和应对方案
在人员安排过程中，考虑到意外情况和风险因素，进行灵活人员调动，其中UI设计组2人在中期任务较为闲置，将其分别安排为前端组以及PPT制作组，后续可能会有其他人员调动安排和应对方案，以确保项目进展顺利。
2.2.6.监控和评估
通过每周三组会进行进度报告，以此定期监控人员的工作情况和项目进展，并进行评估和反馈，及时调整人员安排和分工，确保项目目标的实现。
2.3.成本预算
2.3.1.硬件成本
考虑到开发时间和难度，本组选择将项目部署在本地，不考虑租服务器和网络设备。开发所用的电脑各开发人员自备，因此硬件成本忽略不计。
2.3.2.软件成本
开发过程中使用的大都为免费开源的软件和技术，只需支付数据存储和资源使用费用。为方便合作使用的一些辅助开发网站，根据开发过程中的需要可能会开通会员，但开发时间不长，成本可控制在100元以内。
2.3.3.调研成本
采用线上线下相结合的调研方法。线上发放问卷，同时发红包吸引同学填写，一个群聊10元，发放了十个群聊，成本100元。线下发放问卷，打印300份问卷，一份0.2元，成本60元。两名成员到铜盘校区发放问卷，来回打车费用60元。调研总成本260元。
2.4.时间要求
2.4.1.分析需求、设计页面
该项目贴近生活，我们熟知日常点名流程的繁琐与各大APP的不足之处，对产品需求有一定见解，由此确定调研、分析产品需求及设计UI界面时长为一个月是较为合理的。
2.4.2.技术栈学习及开发
本组人员均具有一定的计算机编程基础，因此确定一个月的技术栈学习及一个月的前后端同步开发是可行的。
2.4.3.测试
在开发完成后，需要进行系统测试和调试，包括功能测试、性能测试、兼容性测试等。测试是确保系统质量的重要环节，因此预留一周时间来发现和修复问题。
2.4.4.机动时间
由于项目存在风险因素和不确定性，可能会存在技术难题、需求变更、人员流动等问题，这些都可能对项目进度产生影响。因此，在制定项目计划时，需要合理地预留一定的缓冲时间，以应对潜在的风险。
综上所述，从时间上看，该项目是可行的，但需要进行详细的需求分析、项目规划以及团队资源评估，以确保项目按时完成。
2.5.对安全性的要求
就安全问题我们在设计时主要有以下考量：
（1）学生和教师的个人信息都包含在这个系统中,比如姓名、学号、联系方式等,这些信息如果泄露将会对用户隐私造成很大影响，所以在开发时需要采取必要的技术措施来防止信息泄露,比如加密传输、访问控制等。
（2）考勤记录和成绩信息也包含很多隐私数据,这些数据如果被非授权访问可能会对用户造成不良影响，所以需要对数据进行分类存储,设置不同角色的访问权限,只允许授权用户访问自己相关的数据。
（3）学生端和教师端都是通过App或Web进行访问,这会增加被攻击的风险，需要对传输数据进行加密,验证用户身份。
（4）在使用过程中可能会出现常见漏洞,所以需要进行日常的安全测试，定期修复系统漏洞。
总之,作为一个处理隐私数据的考勤系统,安全性是其重要的可行性要求之一，开发时需要采取多层防护来保障数据和系统的安全性。
3. 项目计划
3.1.软件开发模型
瀑布模型是最早出现的软件开发模型，是所有其他软件开发模型的基础框架。瀑布模型经历需求分析、计划、设计、产品开发、项目测试，其每个阶段都只执行一次，是线性顺序的软件开发模型。正是由于每个阶段只执行一次，所以前面的需求分析和设计尤为重要。由于我们团队对课堂考勤做过充分调查，并且都亲身经历过课前繁琐的点名流程，所以团队成员对项目需求明确并且可预见性地变更较少，相比螺旋模型和迭代模型等有着较为繁琐和冗长的周期，我们团队最终选择瀑布模型进行开发。
3.2.人员分工
102102106何雯彧（组长，后端开发，小程序前端开发）
041802114金 晶（组员，UI，PPT制作）
052101230江 筝（组员，后端开发）
102101608黄家卿（组员，UI，网页端前端开发）
102102101田 甜（组员，Web前端开发）
102102102刘燕莹（组员，Web前端开发）
102102103李盈盈（组员，后端开发）
102102107张锦瑶（组员，Web前端开发）
102102110饶雯捷（组员，Web前端开发）
102102147高宝众（组员，后端开发）
3.3.时间安排
我们的项目大致分为三个阶段：分组开发、前后端联调、上线应用。时间安排如下图所示：
3.4.其他说明
由于各科考试时间未定，此安排为初步的计划，之后会根据实际情况进行灵活、科学地调整。
