1、 毕业生学籍处理： 结业处理，毕业处理，授位处理，学籍卡片等。1.3 系统模式高校学生学籍管理系统将采用 B/S 模式，学生的信息由各用户在 规定的权限下在各自的工作站上录入， 统一保存在系统服务器上， 既 可集中管理， 有可让各部门管理自己负责的信息。 信息上网后各用户 可查询、调用，达到全校信息共享。1.4 现行组织机构 学校现有的学生学籍资料分别由系、教务处、学生处管理。每个 管理部门几乎都有一份相同的学生基本信息。这样，工作容易重复， 而且，最大的问题是彼此工作不透明，容易出现数据的不一致。这问 题的出现是致命的。1.5 系统现状现在学校各部门分别使用不同数据库， 各部门之间的信息还不
2、能 实现网上共享。 由于学校的各个部门都需要一些学生的基本信息， 所 以各个部门都有一份学生档案。 一个部门的改动， 将导致其他各部门 必须修改，否则，学生的信息将不一致。现有系统采用的是 B/S 模式，比如：各系可以将自己系学生的成 绩都传到教务处的服务器上， 教务处就可以对各系学生成绩进行集中 统一管理。2、功能需求分析高校希望能够对全校所有学生的信息进行集中管理。 然后，对各 个部门分配不同的权限， 让他们去管理他们所需的信息， 而没有管理权限的部门只能查询2.1功能要求学生档案管理： 学生的一般情况，及奖励，处分情况；学生成绩管理： 学习成绩，补考成绩；学籍处理： 学生留降级处理，休复
3、学处理，退学处理；日常教务管理：日常报表，如通知书，补考通知书等，学生学习 成绩的各种分类统计；毕业生学籍处理：结业处理，毕业处理，授位处理，学籍卡片等。2.2信息采集与各部门的使用权限每学期考试完毕由各系录入成绩，然后由教务科收集。为了保证 信息的安全和数据的权威性，对于网上信息的使用权限和责任规定如 下：数据收集前的系统权限学生 档案学生奖 征学生成 绩学籍处 理补考成 绩教学计 划管理各种等 级考试学生处a bb各系r bb :教务处院长办公室注：a登录，修改，处理权。 b、查询权2.3数据完整性、正确性：1） 可按某学生某学年考试及补考成绩，自动生成该学生是否升留 降级，退学。2） 可
4、按某学生在校期间累计重修科目门数和成绩自动生成该学生是否结业，毕业，授位3）可按某学生因非成绩原因所引起的学籍变更作自动处理。4）可按每学期各年级班学生考试成绩自动生成补考名单，科目。5）可按每学期各年级学生考试成绩自动生成某课程统计分析表。6）可按同一年级学习成绩进行同一课程不同班级间成绩比较。3、性能需求 因为学籍管理系统存储学生信息，所以数据库系统应该具有备 份和恢复功能，保证学生数据库的长期完整性和正确性。另一方面， 作为系统的服务器应该能够长期无故障的运行， 而且能够便于管理员 的操作。安全性要求比较高，对业务逻辑必须封装，避免有人登陆他 没权限的网页，避免黑客从数据流中截取敏感数据
5、。3.1系统处理的准确性和及时性 系统处理的准确性和及时性是系统的必要性能。 在系统设计和开 发过程中， 要充分考虑系统当前和将来可能承受的工作量， 使系统的 处理能力和响应时能够满足设备管理处对信息处理的需求。 由于学生 学籍管理系统的查询功能和基本信息功能对于整个系统的功能和性 能完成举足轻重。 作为系统的很多数据来源， 而学生数量和成绩又影 响数据库的试验活动， 其准确性和可靠性很大程度上决定了学生学籍 管理系统的成败。 在系统开发过程中， 必须采用一定的方法保证系统 的准确性。3.2系统的开放性和系统的可扩充性 学生学籍管理系统在开发过程中，应该充分考虑以后的可扩充 性。要求系统提供足
6、够的手段进行功能的调整和扩充。 而要实现这一 点，应通过系统的开放性来完成，既系统应是一个开放系统，只要符 合一定的规范，可以简单的加入和减少系统的模块， 配置系统的硬件。 通过软件的修补、替换完成系统的升级和更新换代。3.3系统的易用性和易维护性 学生学籍管理管理系统是直接面对使用人员的，而使用人员往 往对计算机并不时非常熟悉。 这就要求系统能够提供良好的用户接口， 易用的人机交互界面。 要实现这一点， 就要求系统应该尽量使用用户 熟悉的术语和中文信息的界面； 针对用户可能出现的使用问题， 要提 供足够的在线帮助，缩短用户对系统熟悉的过程。学生学籍管理系统中涉及到的数据是学校相当重要的信息，
7、系 统要提供方便的手段供系统维护人员进行数据的备份， 日常的安全管 理，系统意外崩溃时数据的恢复等工作。3.4 系统的标准性 系统在设计开发使用过程中都要涉及到很多计算机硬件、软件。 所有这些都要符合主流国际、 国家和行业标准。 例如在开发中使用的 操作系统、网络系统、开发工具都必须符合通用标准。如规范的数据 库操纵界面、作为业界标准的 TCP/IP 网络协议及 ISO9002 标准所要 求的质量规范等；同时，在自主开发本系统时，要进行良好的设计工 作，制订行之有效的软件工程规范，保证代码的易读性、可操作性和 可移植性。3.5 系统的先进性 目前计算系统的技术发展相当快，做为学生学籍管理系统工
8、程， 应该保证系统在下个世纪仍旧是先进的， 在系统的生命周期尽量做到 系统的先进， 充分完成企业信息处理的要求而不至于落后。 这一方面 通过系统的开放性和可扩充性， 不断改善系统的功能完成。 另一方面， 在系统设计和开发的过程中， 应在考虑成本的基础上尽量采用当前主 流并先进且有良好发展前途的产品。4、其他需求普通用户的需求： 对于只有查看权限的用户， 一般是通过上网浏 览学校网页来查看数据的。各部门管理员：能够对系统进行设置，以适应不同用户的需求。 对不同系的管理员分配不同的权限， 教务处系统管理员具有最高的管 理权限。5、用户平台需求根据性能需求分析，使用以下方案：操作系统： linux/
9、unix数据库： oracle页面脚本程序： jsp服务器端程序： servlet6、业务流程6.1与其他系统的关系 本系统暂不考虑与其他系统交换数据，而是作为一个独立的系统。但是，他应该能够向学校的上级主管部门提交学生的信息6.2业务流程7、业务逻辑7.1业务分解7.2业务描述高校学生学籍管理系统，由学校指派专人负责系统的管理和维护。 系统中分别涉及到不同管理部门所管理的学生信息， 因而将系统的信息分类，分别由教务处、学生处、各系管理具体的信息。其中，教务 处负责学生学籍管理、学生成绩、教学计划、师资分配、各种考试安 排。学生的成绩由各个系按照教务处的规定在各个系的计算机输入本 系学生各门功
10、课的成绩，并上传到系统中。各系还要上报本系的教学 计划，课程安排，然后由教务处统一发布。学生处主要负责学生的档 案管理以及奖励和处分。学生处根据学生的高中升学档案形成原始档 案，然后根据各系对学生表现的评价，决定对学生的奖励或处分。在 学生毕业时形成每个学生的最终档案。学校的其他部门（包括学生、 家长、用人单位）只能浏览学生的公开信息。8数据调查及分析8.1原始单据单 据 名 称别 名简述来源去处组成流通量学 生 资 料主要是学生的学 号、姓名、出生年 月、住址等学生入学时由学 生处从学生升学 档案获得供学校其他 部门查阅学号、姓名、年级、 班级、出生年月、住 址、生源地大成绩学生在校期间，各
11、 学期所选课程的成 绩由各系将本系学 生的成绩通过计 算机上传到教务 处服务器统一处 理可供学生、 系、用人单 位等查阅课程名、学分、成绩授 课老师在本学期所上 的课程由教务处根据老 师的专业安排供院系、学 生、老师查课程代号、课程名、 学时、上课地点、上中阅课班级、教师代号补 考 成 绩学生重修某门课程 以后，所取得成绩教师的成绩单毕业参考小奖 励 处 分系、学生处根据学 生的表现作出奖励 和处分系、学生处供学生系、 用人单位等 查阅奖励，处分8.2数据分析821数据分类学生基本资料（如：姓名、学号、住址、出生年月等）一般是保 持不变的；其它数据是动态的，数据量较大，是系统管理的重点。822
12、 数据项描述依据用户提供的功能要求，取得描述学生的信息有：学号，班级, 姓名，性别，出生年月，家庭地址，邮编，奖励，处分，若干门课程 学习成绩；每门课程的信息：课程名称，学分，学时数，上机时数， 实验时数，成绩，补考成绩等项。8.2.3数据的完整性，准确性a.根据数据库的要求录入数据采用表格方式，限制各种录入数据 的不同数据类型及取值范围以保证数据的完整性及准确性。b.系统具有修改功能，更新功能，而系统备有的修改功能在尚未提 交数据库前均可取消8.2.4数据完成的时间性数据的录入有时间的限制.如成绩的录入，仅当师资科录入教学 进程，教务科分发教师教学任务安排之后，各系方可录入成绩。8.2.5
13、数据安全性本系统采用二级安全保障第一级：依赖于网络本身对用户使用权限的规定。 第二级：在程序模块中通过使用密码控制功能对用户使用权限加 以限制。9、建立系统的约束9.1B/S结构总体设计方案对它的约束学生学籍管理系统作为B/S结构的一个应用系统，不可避免的要 受到 B/S 结构的约束。在其实施的各个阶段都要服从它的一些规划， 包括功能设计、系统配置和计划。同时，由于信息的共享，学生学籍 管理还受到其它系统的信息约束。9.2人力、资金、时间的约束学生学籍管理系统工程实施的目标就是要带给学生、 教师、系统 管理员看得出见效快的效益， 其开发过程中也要考虑到人力、 资金和 时间的约束。因此，在设计中，重点是查询系统中的方便快捷，能提 供给使用者以优质高效的服务， 并提高销售员的效率和便捷， 为高校 带来极大的便捷。9.3技术发展规律的约束计算机技术和产品的发展日新月异， 将会给信息处理带来更多的 手段，同时也会带来更加丰富的信息表达形式。 例如图像和语音技术 的进步， 多媒体技术的发展， 这些都要求系统在设计时考虑技术变化 的可能性，为可能的变化预留一定的系统处理能力。
