搜索
1一、引言需求分析是系统开发中最耗时的一部分工作，但留下的开发时间较短，待边上线边提需求再修改的开发方式必然拖垮整个系统的上线时间，当然这种提需求的方法也是主流的，可行的，完全可以使用；但还是建议初期就能把最为基础的需求提出（可以不用去关注它怎么实现，但最好是把可能与需求相关的几个部分考虑一下）。本系统拟使用寿命为10年（李处未晋升前不用再换系统），争取扛到15年，所以在考虑当下要做什么的情况下也要适当考虑这几年内将会做什么（猜），尤其是涉及（培养方案(已存在的培养方案，暂不涉及培养方案的制定过程)，学籍，选课记录（课表），成绩这几个里程碑级的数据），否则一旦有新的改革，换系统的概率会很高。1、本文档的作用为“抛砖引玉”,所写并非完全正确，且语言没有雕琢，读起来逻辑不是那么清晰，主要目的是为激发各位的需求。2、以一个学期为切片，教务学籍整体业务设计安排如下图，时间供参考（网络图显示的效果最好，但截屏不出来，也可详见业务分配.mpp，使用project2010打开），关键看业务顺序是否合理，注下图以学生视角为出发点，还有一些业务未注明，表明该类业务的时间顺序由具体的控制参数而定。3、学生端：申请类业务（休学，复学，转专业，退学，交换生，第二专业，专业分流），报名类业务（选课，等级考试，四六级，学业进步奖），查看类业务（查看个人学籍信息（支持修改，确定必填字段），课表，成绩，毕业结论，毕2业证书学位证书中英文版本打印），操作类（评价）。4、教师端：教师端的情况较为复杂，此处包含的教师有：教学管理人员，督导，其它部门教职工，教师。教学管理人员的业务较多，以下描述仅限学籍教务业务，暂不含实践、培养方案业务。院级教学管理人员：查看类（1、基础资源信息，专业，专业方向，课室；2、学籍，成绩；教学质量评价等）；（2、操作类：专业分流，计划安排，课表调动，选课名单调整，考试安排等）；（3、查看操作类，学籍预警，毕业审核，第二专业，转专业等），校级教学管理人员页面院级教学管理人员基本一致，所不同的在于权限范围，其它部门教职工，如学生处，宿管等与校级教学管理人员所能用的功能为校级教学管理人员的一个子集，且所能查看到的字段也受限（按字段授权，只能开放为“读”）。督导：查看类（查看校或院教师课表）；操作类（评价教师上课情况）。教师：查看类（个人课表，选课情况，课程质量评价情况，监考安排情况，），操作类（公选课申请，调停补课，教室借用，成绩录入（含打印））。注意：要处理好单用户多角色的权限的合并问题，如教师A也可以是督导等。做到角色再赋权管理最好，用户A能将自已已有的权限赋予用户B，用户B的新权限等于去重复后原用户B的权限+新增权限，同时A能随时收回B的权限，则必然要求用户A拥有自我管理的用户列表，这种操作相当于继承，这样一来，需要考虑的问题就多了，此处仅建议，但必须给出一个可行质量还不错的角色管理方案，必须实现关键信息表的按字段授权（学籍，开课计划，成绩，毕业生信息）。5、瞄准“管理优化级”，支撑“战略决策级”。6、接口类：与门户的接口，只考虑学籍字段，凡有学籍的学生均可登录门户，教师集成来自于人事处，教师与门户的集成应该是取自人事处的信息。7、有一个大概率的关键变化，由于采用的是B/S架构，故此后可能没有字母开头的帐号，全部为工号。8、拟解决的关键问题：1）确保里程碑数据完整一致，培养方案，学籍，选课，成绩，以突破现有教务系统无法将培养方案运用至毕业审核的重大功能缺失；2）通过集成与“线上辅助线下”等方式，提高业务整体完成的效率，且大幅缩减不知表格在何处下载的问题；3）解决学生学习经历与其培养方案、毕业资格脱钩的问题；4）明确教学过程之中，教师与课程学时之间的占有关系，维护过3程数据与里程碑数据的规范性；5）至少支持现已公布的管理制度，争取满足现行制度在一段时间的变化需求；6）争取一个学期内的业务在一个学期内完成，维护整体数据的一致性，如大平台分班所产生的问题；7）扩展计划任务安排的功能，如复制教学任务，同课程不同项目，限选课的安排方式；8）明确教师对课程学时的占有权，以解决多教师单任务调停补的麻烦；9）规范计划任务的安排，可控不同课程性质，不同考核方式等课程的合班安排；10）更健壮的成绩管理方式，如重修登分，非教师登分的独立权限；11）一二专业课表合一，按条件显示各成绩单，如只显示最高成绩（用于学生打印）；12）明确学生绩点的计算方式。9、需求收集安排：第一阶段｛教务+学籍+学生+教师+教研（可能在此阶段，如果人才培养方案与系统厂商一致）｝第二阶段：｛实践+质量+其它部门（李处指定）+教研（可能在此阶段，如果人才培养方案与系统厂商不一致）+师生代表（由这几个科室负责选择，毕竟这几个科室的业务绝大部分师生是不参与的，人才培养的倒是有点特殊，如果第一阶段人才培养方案系统已经做好，如果教研还愿意两者合一的话，那需求好确定了）｝每个阶段需求收集大概在7-15天左右；规范而言，初期阶段需求收集的范围是越大越好，不过不太适合急需上线的项目。10、整个系统纠缠点有2：一是当前运行学期，二是当前排课学期，且这两个学期共用同一套学生、教师、教室等资源，强壮的教务系统必然能使资源在不同期内无缝衔接。11、关键问题的解决进度安排：总计划150天左右全部完成。第一：数据迁移阶段（7天）：清洗、并迁移关键数据（学籍（10级之后的所有学生信息），成绩（迁移的学籍信息中所有该生的成绩信息），毕业结论信息（与学籍关联），其它的基础信息，如培养方案，专业，课室等），关键点：要综合分析后续的需求，合理设计系统的基础表，在基础表设计不合理的情况下迁移是无意义的。第一：角色管理阶段（3天）：需明确各用户的角色建立方法，具体可参见第3、4、6条关于用户的介绍。第二：计划安排-排课（15-20天）：拟解决的关键问题见教学业务计划安排与4排课。第三：教学质量评价（7天）：拟解决的关键问题见第四：调停课管理（5天）：第五：成绩管理（7天）：拟解决的关键问题。第五：排考（7天）第五：自主打印机的接口测试（7天）。第六：学籍管理（30天）：见学籍业务，尤其要解决转专业，交换生，学籍预警问题。第七：OA门户接口测试（7天）。第八：毕业审核（10天）：第九：其它业务（20天），如学生完善信息，第二专业报名，实验排项目，大创管理、实验教学等等。第十：移动APP的上线。移动APP的功能流程与PC端一致。注：以上各阶段的安排仅供参考，并非一定按照此串行进行，所列出的顺序并不代表各功能的重要程度，所有的功能都很重要，有的可以并行进行，但务必在2018年5月10日前完成至第八，务必在2018年7月15日前全部完成。二、解释1、“纯线上”指所有过程均在网上完成。2、“线上辅助线下”指申请阶段均在网上完成，打印申请单之后，审批阶段均在网下完成。3、文字带删除线指：暂不确定是否需要该内容。注：理论上所有的业务均可网上办理，但考虑到部分业务需加盖公章，而纯线下易引起业务办理完成，但系统并不能实时动态体现，故此处给出“线上辅助线下”的解决方式。4、任何“线上辅助线下”业务均在线上填写的申请单，自带流水号，流水号的命名规则：业务名称+当前学年学期+自增长号（各项业务的自增长号均从当前学年学期的0开始），对于管理端该流水号于管理人员而言可用，尤其是排序，过滤等基本操作。6、关于业务完成后的推送结果，只需在流程确定的基础上，在最后生效过5程中添加推送功能即可，注需有参数控制是否启用推送功能，且推送范围应应由用户按角色的范围可选，推送的范围拟定，该业务影响的范围，如是个人业务，则推送至个人，如是调停课业务，推送的范围拟定：该课程影响的学生，该课程的上课教师，该教师所属学院的同行，该教室所属学院的教学管理人员。其实关键也就是实现调停课的推送。注：考虑到调停课业务的大量性，在按角色选择推送范围的时候，是用取消勾选，即默认的情况为向全部推送，按需取消勾选。7、为提高业务办理的针对性，大多数线上辅助线下的业务流程申请单中均可新增一页，告诉学生办理流程，如退学申请单中，可新增一页，那九个章在何处盖，休学申请单中，那四联送至何处，等等。三、学籍业务4.1学籍业务学籍业务的资源维为学生、院级管理员、校级管理员；准则为学籍模块变动与培养方案、选课模块、登分模块、自主打印模块等模块同步按细化规则准确变动。学籍中：学生学籍状态，是否在校，是否注册三个关键字段的合法逻辑关系。1）三个字段均为二值字段（如0，1或其他）；2）学籍状态为0，其它两个字段则必须为0；3）学籍状态=1，是否在校=0，则是否注册必须为0。4.1.1学生个人信息修改非隐私敏感信息“纯线上”流程，含兴趣爱好、高考英语成绩等。其中英语成绩只可改高，不可改低。允许学生修改高考英语成绩，主要是考虑大学英语分级教学涉及此字段，如无此要求，则可以取消该限制，故此功能应该有参数控制。凡修改了非隐私敏感信息，学生务必填写：来源地区等其它信息才可允许提交。提交后自动进入系统，无需审核。隐私敏感信息“线上辅助线下”流程，主要是户籍所在地，具体为：网上填写表1-》打印申请单，附相关材料明细，线下交至校级负责人-》审批通过，直接生效。生效规则：以学生申请的修改信息覆盖现有的相应信息，同时记入修改日志。6任务点：需设计表1，以及所需材料明细。4.1.2学籍异动休学所有学籍：=有的学生均可申请休学，（当前时间-休学时间）N且处于休学期的学生也可再申请休学。“线上辅助线下”流程，休学原因有“因病、创业、参军、其它”，具体为：网上填写表2-》打印申请单，附相关材料明细，线下交至院级负责人，院级不在网上审批-》院级线下审批通过、交至校级负责人-》校级审批通过，直接生效。生效规则：1）更新是否在校，是否注册=否；2）删除当前学期已选课，但未登分的选课记录（选课记录或登分记录涉及之后的“收费管理”），即调整登分名单；3）更新休学时间（默认为空）=审批通过时间；4)记入修改日志。任务点：需设计表2，以及所需材料明细。编入下一年级(zw)此处编入下一年级，广泛地说，应理解为编入下N年级，面向所有有学籍的学生。学生可自我申请编入下N年级，学院或校级也可强行将某些学生编入下N年级。.....(待补充)复学只有处于休学状态的且休学超过N天，（默认N=150）的学生才可申请复学。“线上辅助线下”流程，具体为：判断当前时间-休学时间N，如否，提示“休学时长须大于N”，如是-》允许网上填写表3-》打印申请单，附相关材料明细，线下交至院级负责人，必须编班，院级不在网上审批-》院级线下审批通过、交至校级负责人-》校级审批通过，直接生效。生效规则：1）更新是否在校，是否注册=是；2）（可选规则）添加该学生当前学期复学专业该学生未修过且已开必选课程名单（选课记录或登分记录涉及之后的“收费管理”），即调整登分名单；3）更新复学时间（默认为空）=审批通过时间；4)记入修改日志；5）更新当前所在级等相关信息。注：生效规则2）使用建议为：处于开学初的复学学生建议勾选，处于学期中复学的学生不建议勾选。7选修课处于选课期学生可自选，非选课期由学院自行安排，提前复学的，已修过某些课程但还想再修的学生，也由学院依据教学资源自行安排。任务点：需设计表3，以及所需材料明细。转专业校级用户可设定的参数：1）转专业申请时间范围（开始-结束），默认（2017年9月15日-2017年9月15日）；2）学生最多申请报名的专业数量，默认=2；3）可分学院分专业分年级设定最大接收人数，默认=-1；4）可申请转专业的年级，默认为：学制-1；5）所有学生允许最大的转专业次数，默认为=1；6）考试作弊是否允许转专业，默认=允许（1）。学院可设定的参数：1）可分专业分年级设定最大接收人数，默认=0；学生信息表中要记录：学生转专业成功的次数。流程1：（学生个人申请），“线上辅助线下”第零步：（参数设定）校级用户设定校级参数，院级用户设定院级参数，院级用户发布接收人数0的转专业名录，最终可供学生报名的分专业分年级的接收人数=max（校级用户可分学院