学分制系统的业务设计(初稿--用于讨论).docVIP

引言 需求分析是系统开发中最耗时的一部分工作，但留下的开发时间较短，待边上线边提需求再修改的开发方式必然拖垮整个系统的上线时间，当然这种提需求的方法也是主流的，可行的，完全可以使用；但还是建议初期就能把最为基础的需求提出（可以不用去关注它怎么实现，但最好是把可能与需求相关的几个部分考虑一下）。本系统拟使用寿命为10年（李处未晋升前不用再换系统），争取扛到15年，所以在考虑当下要做什么的情况下也要适当考虑这几年内将会做什么（猜），尤其是涉及（培养方案(已存在的培养方案，暂不涉及培养方案的制定过程)，学籍，选课记录（课表），成绩这几个里程碑级的数据），否则一旦有新的改革，换系统的概率会很高。 本文档的作用为“抛砖引玉”,所写并非完全正确，且语言没有雕琢，读起来逻辑不是那么清晰，主要目的是为激发各位的需求。 以一个学期为切片，教务学籍整体业务设计安排如下图，时间供参考（网络图显示的效果最好，但截屏不出来，也可详见业务分配.mpp，使用project2010打开），关键看业务顺序是否合理，注下图以学生视角为出发点，还有一些业务未注明，表明该类业务的时间顺序由具体的控制参数而定。 学生端：申请类业务（休学，复学，转专业，退学，交换生，第二专业，专业分流），报名类业务（选课，等级考试，四六级，学业进步奖），查看类业务（查看个人学籍信息（支持修改，确定必填字段），课表，成绩，毕业结论，毕业证书学位证书中英文版本打印），操作类（评价）。 教师端：教师端的情况较为复杂，此处包含的教师有：教学管理人员，督导，其它部门教职工，教师。教学管理人员的业务较多，以下描述仅限学籍教务业务，暂不含实践、培养方案业务。 院级教学管理人员：查看类（1、基础资源信息，专业，专业方向，课室；2、学籍，成绩；教学质量评价等）；（2、操作类：专业分流，计划安排，课表调动，选课名单调整，考试安排等）；（3、查看操作类，学籍预警，毕业审核，第二专业，转专业等），校级教学管理人员页面院级教学管理人员基本一致，所不同的在于权限范围，其它部门教职工，如学生处，宿管等与校级教学管理人员所能用的功能为校级教学管理人员的一个子集，且所能查看到的字段也受限（按字段授权，只能开放为“读”）。 督导：查看类（查看校或院教师课表）；操作类（评价教师上课情况）。 教师：查看类（个人课表，选课情况，课程质量评价情况，监考安排情况，），操作类（公选课申请，调停补课，教室借用，成绩录入（含打印））。 注意：要处理好单用户多角色的权限的合并问题，如教师A也可以是督导等。做到角色再赋权管理最好，用户 A能将自已已有的权限赋予用户B，用户B的新权限等于去重复后原用户B的权限+新增权限，同时A能随时收回B的权限，则必然要求用户A拥有自我管理的用户列表，这种操作相当于继承，这样一来，需要考虑的问题就多了，此处仅建议，但必须给出一个可行质量还不错的角色管理方案，必须实现关键信息表的按字段授权（学籍，开课计划，成绩，毕业生信息）。 瞄准“管理优化级”，支撑“战略决策级”。 接口类：与门户的接口，只考虑学籍字段，凡有学籍的学生均可登录门户，教师集成来自于人事处，教师与门户的集成应该是取自人事处的信息。 有一个大概率的关键变化，由于采用的是B/S架构，故此后可能没有字母开头的帐号，全部为工号。 拟解决的关键问题：1）确保里程碑数据完整一致，培养方案，学籍，选课，成绩，以突破现有教务系统无法将培养方案运用至毕业审核的重大功能缺失；2）通过集成与“线上辅助线下”等方式，提高业务整体完成的效率，且大幅缩减不知表格在何处下载的问题；3）解决学生学习经历与其培养方案、毕业资格脱钩的问题；4）明确教学过程之中，教师与课程学时之间的占有关系，维护过程数据与里程碑数据的规范性；5）至少支持现已公布的管理制度，争取满足现行制度在一段时间的变化需求；6）争取一个学期内的业务在一个学期内完成，维护整体数据的一致性，如大平台分班所产生的问题；7）扩展计划任务安排的功能，如复制教学任务，同课程不同项目，限选课的安排方式；8）明确教师对课程学时的占有权，以解决多教师单任务调停补的麻烦；9）规范计划任务的安排，可控不同课程性质，不同考核方式等课程的合班安排；10）更健壮的成绩管理方式，如重修登分，非教师登分的独立权限；11）一二专业课表合一，按条件显示各成绩单，如只显示最高成绩（用于学生打印）；12）明确学生绩点的计算方式。 需求收集安排：第一阶段｛教务+学籍+学生+教师+教研（可能在此阶段，如果人才培养方案与系统厂商一致）｝ 第二阶段：｛实践+质量+其它部门（李处指定）+教研（可能在此阶段，如果人才培养方案与系统厂商不一致）+师生代表（由这几个科室负责选择，毕竟这几个科室的业务绝大部分师生是不参与的，人才培养的倒是有点特殊，如果第一阶段人才培养方