简介《校务通管理系统》项目管理文档面向校园教务与教学综合管理场景服务学校管理层、教师、学生与家长等用户系统梳理了项目概述、任务范围计划、整体需求与系统功能需求。文档强调提供教师/学生工作平台要求严格的权限管理、可扩充性等非功能特性并在功能层面覆盖电子课表、会议通知、日程安排、个人日记、通讯录、教师答疑、家庭作业等通用模块以及招生管理、新生信息录入与自动分班等日常业务需求。资源为单个doc文件压缩包仅139KB结构层次清晰便于快速查阅和二次撰写目前已有263人浏览学习适合教育信息化项目规划者、教务系统需求分析师及相关专业学生参考借鉴也可用于系统设计或项目方案撰写。1. 校务通系统项目管理的第一件事把范围拆到可验收校务通管理系统项目管理表面是一套学校教务综合管理平台的需求文档实际上是最典型的多角色、多模块、强流程边界管理样本。管理层、教师、学生、家长四类角色叠加电子课表、招生分班、考勤、答疑等功能域任何模块边界没定住增量迭代都会连锁返工。文档把开发拆成六个增量每个增量都有独立交付物和验证点。最值得参考的不是选型而是如何在需求阶段把功能权限和数据权限分开定义再用周例会、阶段评审控制节奏。难点不是菜单权限而是行级数据权限在四类角色之间的隔离。下面按需求边界、算法建模、增量迭代和收尾验收四条线拆备考系统集成项目管理工程师的读者可以当案例集对照。2. 需求边界与权限模型把四类角色翻译成数据表设计2.1 功能权限和数据权限是两层约束原文在“整体需求”里有一句容易被略过的话权限要在数据和功能两方面体现。功能权限解决“能不能看到菜单、能不能点按钮”数据权限解决“同一张表不同角色各自能看到哪些行记录”。最容易翻车的场景是只做了角色与菜单的关联结果学生账号能查全校成绩平行班班主任互相看到对方班级花名册。我在做教育类项目规划时会把角色与数据范围的映射先固定下来输入是项目负责人和教务人员一起在会上逐行确认过的。这张表比任何文字需求都早地把边界钉死角色数据范围功能范围管理员全校数据用户管理、基础配置、所有模块增删改教师本人任教班级、本人任教学科电子课表、通知、日程、日记、答疑、家庭作业学生本人及本班数据查看课表通知、提交作业、提问家长关联孩子数据查看课表、成绩、考勤接收通知比如“通讯录能自动从教师基本信息和学生基本信息中抽取通讯记录”这句话隐含了数据脱敏规则教师可搜索全校学生只能查本班家长只能看到孩子所在班级。后续接口层如果只做菜单权限过滤这条需求一定破功。2.2 从需求规格到功能矩阵原文的需求按模块叙述不适合直接作为项目计划输入。需要把它转成带编号、验收标准、优先级和依赖关系的功能矩阵。我一般会把矩阵导出成表格挂在项目文档里周例会直接按矩阵过进度功能域功能点优先级验收标准依赖通用功能电子课表P0按教师任课自动生成可按周切换排课数据完成通用功能会议通知P0按权限组定向发布如“全体教师”角色数据范围通用功能日程提醒P1按日期提前提醒不重复推送消息组件通用功能通讯录P1自动抽取按角色过滤可见范围基础信息库通用功能家庭作业P1支持布置、提交、批改教师、学生账号招生管理自动分班P0性别比例基本一致可手工调整新生信息库学生管理考勤与奖惩P0记录留痕变动需审批学生档案矩阵的价值在于每个功能点都能折算成工作量和测试用例数。负责人直接在矩阵上勾状态评审会就不再依赖口头汇报。2.3 用户、角色与数据范围的表结构按矩阵建库时核心表是用户表、角色表和数据范围配置表。下面是一个最小可用结构实际项目会补部门和学段字段CREATE TABLE sys_user ( user_id INT PRIMARY KEY AUTO_INCREMENT, login_name VARCHAR(32) NOT NULL UNIQUE COMMENT 登录名, user_type TINYINT NOT NULL COMMENT 1-管理员 2-教师 3-学生 4-家长, real_name VARCHAR(64) NOT NULL COMMENT 姓名, org_id INT COMMENT 教师归属教研组学生归属班级, status TINYINT DEFAULT 1 COMMENT 1-正常 0-禁用, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) COMMENT系统用户表; CREATE TABLE sys_role ( role_code VARCHAR(32) PRIMARY KEY COMMENT teacher/student/parent/admin, role_name VARCHAR(64) NOT NULL ) COMMENT角色表; CREATE TABLE sys_data_scope ( scope_id INT PRIMARY KEY AUTO_INCREMENT, role_code VARCHAR(32) NOT NULL, scope_type TINYINT NOT NULL COMMENT 1-全部 2-本班 3-本年级 4-本人/孩子, scope_value VARCHAR(128) COMMENT 具体班级ID或年级ID ) COMMENT数据范围配置表;sys_user.org_id与user_type的组合决定了“我能看哪些行”。sys_data_scope把数据范围从角色中独立出来因为班主任和年级组长都是教师角色但范围不同。权限的枚举值要固化在代码常量里不能在数据库里随意改字符串否则一次手工维护就会破坏全部权限判定。提示权限代码本身好写难在初始化。上线前必须提供数据脚本把四个角色的数据范围预置好后续新增模块再按脚本增量补充功能权限。3. 自动分班与课表生成先定数据约束再写实现3.1 招生信息表怎么建招生管理是系统接入真实业务的第一关。网上报名采集姓名、性别、考籍号、总分、考生来源、考生类型。字段不多但总分精度容易出错有的地区总分 760 或 750有的学科按等级折算建议用DECIMAL(5,2)而不是整型统计时少踩类型转换的坑。CREATE TABLE enrollment ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL COMMENT 姓名, gender TINYINT NOT NULL COMMENT 1-男 2-女, exam_no VARCHAR(32) NOT NULL COMMENT 考籍号/准考证号, total_score DECIMAL(5,2) NOT NULL COMMENT 入学总分, source_school VARCHAR(128) COMMENT 考生来源, candidate_type VARCHAR(32) COMMENT 考生类型如统招/借读, class_id INT COMMENT 自动分班后回填的班级ID, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_exam_no (exam_no) ) COMMENT新生报名信息表;exam_no的唯一约束必须加。报名和数据导入阶段容易出现重复提交唯一键能把脏数据挡在入口。class_id初始为空分班完成后一次性回填避免边录边分导致班级人数来回跳动。3.2 性别与分数双均衡的蛇形分班算法分班要求是“每班男女比例基本一致各班各分数段人数基本一致”。如果只按分数排序后依次分配高分必然扎堆如果按班级循环放人性别可能失衡。常见做法是先把学生按性别拆分各自按总分排序再用蛇形分配。import pandas as pd def snake_assign(subset: pd.DataFrame, num_classes: int): 蛇形分配同一性别按总分降序排好后轮流放进各班级 subset subset.sort_values(total_score, ascendingFalse).reset_index(dropTrue) groups [[] for _ in range(num_classes)] for idx, row in subset.iterrows(): round_no idx // num_classes # 第几轮 pos idx % num_classes # 本轮中的位置 if round_no % 2 0: target pos # 正向分配 else: target num_classes - 1 - pos # 反向分配 groups[target].append(row) return groups def auto_group(students: pd.DataFrame, num_classes: int): males students[students[gender] 1].copy() females students[students[gender] 2].copy() male_groups snake_assign(males, num_classes) female_groups snake_assign(females, num_classes) # 按班级合并男女保证每个班性别比例接近 return [ pd.concat([m, f], ignore_indexTrue) for m, f in zip(male_groups, female_groups) ]round_no % 2是核心偶数轮正向奇数轮反向形成“之”字路径。例如 5 个班时第一轮前 5 名进 1、2、3、4、5 班第二轮前 5 名则按 5、4、3、2、1 进班。这样相邻分数带会交错分布而不是集中到某几个班。分班完成后要提供手工调整入口每次调整必须记录操作人与原因学校不接受“无痕改班”。提示分班算法的边界条件是班级数和每班人数不能整除。idx % num_classes天然处理了余数多出的学生仍然按规则落位最后再校验各班人数差不超过 1。3.3 分数段统计与课表冲突校验分班完成后教学处通常马上要“按 10 分一段”统计分布。用FLOOR按固定宽度切分区间即可SELECT FLOOR(total_score / 10) * 10 AS band_start, CONCAT(FLOOR(total_score / 10) * 10, -, FLOOR(total_score / 10) * 10 9) AS band_text, COUNT(*) AS student_cnt FROM enrollment GROUP BY band_start ORDER BY band_start;band_start是区间下限band_text是展示文本。如果要支持任意分数段把 10 换成接口参数即可但注意total_score要建索引超过百万行时再考虑把分数段预计算成字段。课表生成比分班更依赖约束。原文要求“根据学校总排课情况和该教师的任课情况自动生成电子课表”实践中最容易漏的是冲突校验排课前必须先查重复-- 同一教师同一时间冲突 SELECT teacher_id, day_of_week, period_no, COUNT(*) AS cnt FROM schedule GROUP BY teacher_id, day_of_week, period_no HAVING cnt 1; -- 同一教室同一时间冲突 SELECT classroom_id, day_of_week, period_no, COUNT(*) AS cnt FROM schedule GROUP BY classroom_id, day_of_week, period_no HAVING cnt 1;这两条 SQL 在排课数据导入后、正式发布前各跑一遍任何返回非空都说明排课有冲突不能进入下一步。4. 增量模型下的迭代计划、配置管理与评审纪律4.1 六个增量的切分逻辑与依赖顺序原文明确采用增量模型把系统分为六个增量通用功能、招生管理、学生日常管理、教务管理、教师辅助功能、聊天室与论坛。关键不是按模块均分工作量而是每个增量都能独立交付和验证增量范围交付物验证点增量1通用功能课表、通知、日程、日记、通讯录、答疑、作业可运行版本1四类角色登录后可用公共功能增量2招生管理可运行版本2网上报名、自动分班、分数段统计增量3学生日常管理档案、考勤、奖惩、变动可运行版本3记录留痕、变动审批增量4教务管理年级班级、学科、排课、考试评价可运行版本4排课与考试评价闭环增量5教师辅助功能可运行版本5答疑、作业闭环增量6聊天室与论坛可运行版本6用户交流功能可用把通用功能放在第一增量是因为用户体系、权限和数据范围是所有模块的共同依赖。招生和学生日常管理提前是因为业务最独立还能为后面的排课模块提供真实数据。聊天室与论坛放最后因为它和教务的耦合最弱即使延期也不影响主流程。4.2 配置管理Git 分支策略和 QA 角色如何落地增量模型下的配置管理最忌讳把所有代码堆在主分支上阶段性集成时不知道哪些文件属于哪个增量。开源项目管理的 Git Flow 思路可以直接借过来develop 作为集成分支feature 分支对应功能点release 分支冻结发布版本。# 初始化并创建集成分支 git init git checkout -b develop # 每个功能点单独建分支合并回 develop git checkout -b feature/enrollment git add enrollment.sql normalize.py git commit -m feat(enrollment): 新生录入与自动分班 git checkout develop git merge --no-ff feature/enrollment # 每个增量达到可运行状态后打基线标签 git tag -a v0.1-increment1 -m 增量1通用功能--no-ff保留合并记录让“该增量包含哪些提交”可追踪。每个增量结束打一个 tag集成测试发现问题可以快速回退到上一批基线。这里的配置管理角色不能虚设增量基线必须由配置管理员确认后才允许进入测试否则“产品提交”阶段拿出来的可运行版本没人说得清对应哪一份源代码。4.3 评审机制日例会、周例会、阶段评审和事件评审评审是这份项目计划里比重很大的部分分为日例会、周例会、阶段评审和事件评审。日例会容易流于报流水账必须有固定输出格式阶段评审则要对齐质量评审和产品审计结果。评审类型频率核心议题必备输出日例会每天 17:00进度、风险通报、阻塞项当日状态记录定期评审每周五本周进度、问题对策、资源协调、下周计划周报与范围变更申请阶段评审每个增量结束计划执行情况、质量评审、产品审计评审纪要、下阶段计划修正事件评审发生变更时需求变更、技术风险变更控制记录事件评审最容易忽视但它恰恰是延期的主要诱因。比如“排课规则临时支持连上两节课”不是改一张表那么简单课表生成算法、冲突校验、前端展示全要动必须走事件评审。评审不是一个动作必须落到一个责任人、一张验收标准、一个截止时间上。5. 用 BCWS 盯进度偏差用验收清单守住交付质量5.1 BCWS、挣值与周度体检原文最后给出 BCWS 曲线这是挣值管理计算题里的基础指标。纯看“花了多少钱”没有意义必须同时比较计划值 PV、挣值 EV 和实际成本 AC。进度偏差 SV 为负说明实际干完的活比计划少正确动作是排查阻塞项而不是盲目加人。# 第40天的快照计划完成预算、实际花费、实际完成工作的预算 pv 48000 # 按计划应完成的工作预算 ac 46000 # 实际花费 ev 42000 # 实际完成工作对应的预算 sv ev - pv cv ev - ac spi ev / pv cpi ev / ac print(f进度偏差 SV {sv} 元) print(f成本偏差 CV {cv} 元) print(f进度绩效 SPI {spi:.2f}) print(f成本绩效 CPI {cpi:.2f}) if spi 0.95 and cpi 1.0: print(进度落后但成本可控检查增量边界和评审排期) elif cpi 0.95: print(成本超支重点审计变更与返工)EV 的计算口径必须在项目启动时定死只有代码走查和单元测试都通过的用户故事才允许计入 EV。否则到月底手工“补数”这条曲线失去任何预警意义。5.2 验收检查单逐项勾掉才算交付最后阶段最容易压缩的是验收。多人多角色的系统建议用检查单逐项过检查项检查方法通过标准电子课表以教师身份登录自动生成该教师本学期课表且无冲突自动分班导入真实新生数据执行各班男女比例差异不大于 10%分数段分布一致分数段统计切换 10 分/50 分段页面统计与 SQL 查询结果一致数据权限学生账号访问通讯录只能看到本班同学手工调整调整一名学生班级调整记录可审计日程提醒新建 30 分钟后日程到点触发且不重复这张清单可以反过来改写成测试用例。测试人员在计划阶段就介入把检查项转成用例比开发自测更容易发现盲区。验收报告签字前把源代码、可运行版本、详细设计说明书、测试报告一起归档进配置管理并打上版本号少一样都先不要签收。本文还有配套的精品资源点击获取