zq践地组——团队展示

zq践地组 2026-10-02 10:46:17

这个作业属于哪个课程	202601福大-软件工程实践-W班
这个作业要求在哪里	软件工程实践团队作业——种子队选拔、团队展示及选题
这个作业的目标	完成团队组建，确定项目选题；使用 NABCD 开展需求分析并制作选题 PPT；制定《构建之法》团队绩效考核方案；发布团队博客展示队员风采、确立团队愿景；熟悉软件项目前期流程，培养团队协作能力，为后续开发做准备。
其他参考文献	《构建之法》赛博厨神队-团队展示 —— 作者：Jealzone 软件工程：风险管理，凡事都应该有B计划 —— 作者：OceanStar的学习笔记 Build to win！——获得小黄衫的感想 —— 作者：weixin_30246221

zq践地组——团队展示
一、选题描述
1.1 拟作的团队项目选题描述：一句话
1.2 项目背景
1.3 系统核心功能
1.4 技术选型与架构设计
1.5 项目推进计划与里程碑
1.6 NABCD 模型分析
N——Need（需求）
A——Approach（做法）
B——Benefit（好处）
C——Competitors（竞争）
D——Delivery（交付）
1.7 选题材料
1.8 预期成果与交付物
1.9 关键技术难点与解决方案
二、响亮的队名
三、团队描述
四、队员风采
4.1 陈时文（组长/PM）
4.2 兰秀楠
4.3 甘羽潇
4.4 张祺
4.5 陈子涵
4.6 梁鑫敏
五、团队考核方案
5.1 考核总则
5.2 任务完成（50 分，任务点积分制）
六、团队协作机制与规范
七、项目风险与应对策略
八、项目愿景与展望
九、团队文化与价值观
十、项目落地与推广计划

zq践地组——团队展示

一、选题描述

1.1 拟作的团队项目选题描述：一句话

一个面向高校社团与学生的一站式活动通知与报名管理平台（校园小教务处），解决信息分散与报名统计痛点。

1.2 项目背景

面对校园内社团活动信息分散、报名统计繁琐的痛点，我们观察到目前常用的校园平台（如福uu）尚未开通专门的社团活动通知与报名功能，同学们查看活动详情、报名参与仍依赖分散的群聊转发和问卷，极其不便。作为现有校园平台的有力补充，我们致力于填补这一空白。

1.3 系统核心功能

校园活动报名OA系统采用前后端分离架构，划分为学生端、教师端、管理员端、公共基础模块四大模块，实现从活动创建、审核发布、在线报名、扫码签到到名单导出的完整业务闭环。

模块名称	角色定位	核心功能
学生端	活动参与者	浏览、筛选各类校园活动，查看活动详情；支持一键报名（复用账号已有信息，免重复填写），支持报名截止前取消报名；活动开启后支持二维码扫码签到，随时查看个人报名状态。
教师端	活动组织者	创建、编辑活动草稿，提交审核；管理本活动报名人员，支持手动签到；一键导出报名与签到Excel名单，减少人工统计工作量。
管理员端	系统管理者	负责活动审核管控（通过或驳回）；支持用户资料管理、活动分类维护；提供全局数据看板与导出能力，实现校园活动统一监管。
公共基础模块	底层支撑组件	提供登录认证、RBAC角色权限控制、站内消息通知、文件与Excel导出等通用能力；内置防重复报名、名额超额校验逻辑，保障业务数据准确。

1.4 技术选型与架构设计

本项目采用主流的前后端分离架构，确保系统的高内聚、低耦合，便于团队并行开发与后期维护。

• 前端技术栈：基于 Vue 3 + Vite + TypeScript 构建响应式单页应用（SPA），UI 组件库选用 Element Plus，状态管理使用 Pinia，路由采用 Vue Router。通过 Axios 封装统一的请求拦截器，处理 JWT 鉴权与全局异常。

• 后端技术栈：基于团队技术储备，后端采用 Go (Gin框架) / Java (Spring Boot) 进行开发，提供 RESTful API 接口。采用 JWT + RBAC 模型实现精细化权限管控。

• 数据存储：MySQL 作为主关系型数据库存储核心业务数据，Redis 用作缓存，提升活动列表等高频读取接口的响应速度。

• 部署与运维：使用 Docker 进行容器化打包，配合 Nginx 实现前端静态资源部署与反向代理，保证环境的一致性。

1.5 项目推进计划与里程碑

为确保项目按期高质量交付，团队采用敏捷开发模式，总计 6 周开发周期，分为 3 个 Sprint（迭代）：

阶段	周期	里程碑任务	交付物
Sprint 1	第1-2周	需求分析与基础建设	PRD文档、墨刀原型图、数据库ER图、接口规范、前后端脚手架搭建、登录认证与权限管理
Sprint 2	第3-4周	核心业务闭环开发	教师活动创建/编辑、管理员审核、学生报名/取消、名额防超额与防重复校验
Sprint 3	第5-6周	扩展功能与上线	二维码签到、站内通知、Excel名单导出、系统测试、Bug修复、Docker部署上线

1.6 NABCD 模型分析

N——Need（需求）

学生端：校园活动信息分散在QQ群、问卷表单，消息容易被刷屏淹没；重复填写学号、班级、手机号等信息；缺少集中查看活动、一键报名、扫码签到的统一入口，纸质点名签到排队、效率低下。
教师/管理员端：依赖问卷星、群接龙、Excel手工统计报名信息，容易出现报名重复、名额超额的问题；缺少活动审核管控流程；报名、签到名单需要人工整理，统计归档工作繁重。

A——Approach（做法）

采用前后端分离架构搭建校园活动报名OA Web系统，完整覆盖「教师创建活动→管理员审核发布→学生查看报名→扫码签到→名单导出」的活动全生命周期业务闭环。
划分学生、教师、管理员三套角色端，基于RBAC+JWT实现权限管控；系统读取账号已有基础信息，实现学生免重复填表一键报名；内置名额、重复报名校验逻辑；提供二维码签到、报名签到名单Excel导出功能。
数据库统一存储活动、报名、签到全量数据，配套站内通知、活动分类筛选等公共基础能力。

B——Benefit（好处）

对学生：活动信息集中展示，便于筛选浏览；免重复填表一键报名，可随时查看报名状态；扫码签到无需排队，提升参与体验。
对教师：活动提交审核流程规范化；系统自动防重复、防超额报名，不用人工核对；报名签到名单一键导出，大幅减少统计整理工作量。
对管理员：拥有统一审核发布入口，实现校园活动全局管控；活动数据集中沉淀，便于统一管理归档，补齐传统工具缺失的审核、签到业务断点。

C——Competitors（竞争）

方案	信息聚合	审核机制	签到与名单导出
QQ群/接龙	差	无	无
问卷星	中	无	仅支持基础导出
Excel手工维护	差	无	全部手动操作
本校园活动报名OA系统	优	具备完整审核流程	报名/签到/导出完整业务闭环

QQ群接龙、问卷星、Excel是当前校园活动报名主流替代方案，但普遍缺失活动审核管控，签到环节薄弱，无法形成完整业务闭环；本系统专门面向校园活动场景，补齐传统工具在权限审核、名额校验、扫码签到、名单导出上的短板，聚焦解决校园活动管理真实痛点。

D——Delivery（交付）

采用敏捷迭代，共计6周开发周期：第1周完成需求分析、PRD文档、原型设计与数据库设计；第2周实现登录认证、用户与权限管理；第3周开发活动创建、编辑、审核模块；第4周完成学生报名、取消报名、名额控制逻辑；第5周实现二维码签到、站内通知、Excel名单导出；第6周开展系统测试、缺陷修复、部署上线以及演示材料准备。
上线后先在学院、班级小范围活动开展试用，跑通完整业务流程；收集真实使用反馈优化交互与功能，再逐步扩大试用范围，同步交付项目文档、部署说明与使用手册。

1.7 选题材料

选题PDF文档链接：点击此处查看选题PDF文档

1.8 预期成果与交付物

本项目在 6 周开发周期结束后，将交付一套可实际运行的校园活动报名OA系统以及完整的配套工程文档，具体包括：

交付物类型	具体内容
软件代码	前端 Vue 3 仓库、后端 Go/Java 仓库，包含完整的源码、Dockerfile 及 docker-compose 编排文件。
数据库设计	完整的 ER 图、MySQL 建表 SQL 脚本、Redis 缓存设计说明。
接口文档	基于 Swagger/Apifox 的完整 RESTful API 接口文档，包含请求参数与响应数据示例。
工程文档	需求规格说明书（PRD）、系统架构设计文档、测试用例及测试报告、项目部署与运维指南。
用户手册	面向学生、教师、管理员的三套系统操作手册，帮助用户快速上手。

1.9 关键技术难点与解决方案

为了保障系统的稳定性和用户体验，团队预判了以下技术难点，并制定了对应的解决思路：

技术难点	难点描述	解决方案
名额超卖问题	热门活动报名时，并发请求可能导致名额被超额占用。	采用 Redis 分布式锁结合数据库乐观锁（版本号机制），在扣减名额时保证原子性操作。
扫码签到防作弊	学生可能通过转发二维码截图让别人代签。	签到二维码采用带时间戳的动态 Token 生成，页面每 15 秒自动刷新二维码，确保签到人在现场。
大量名单导出	活动报名人数过多时，一键导出 Excel 可能导致服务器卡顿。	采用异步导出机制，后端通过消息队列处理导出任务，完成后通过站内信通知用户下载，避免阻塞主线程。

二、响亮的队名

队名：zq践地组
寓意：我们的团队旨在打造一个连接校园社团与学生的“小教务处”平台，让社团活动通知不再被淹没，让报名流程化繁为简，让每一个社团活动都能被“看见”。

三、团队描述

我们是一支充满热情、互补互助的软件工程团队。面对校园内社团活动信息分散、报名统计繁琐的痛点，我们观察到目前常用的校园平台（如福uu）尚未开通专门的社团活动通知与报名功能。因此，我们致力于开发一个“社团活动通知平台”。该平台本质上是校园内的“小教务处”，提供活动发布、分类通知、在线报名、数据统计等功能，作为现有校园平台的有力补充，帮助社团高效管理，帮助学生便捷参与。

四、队员风采

4.1 陈时文（组长/PM）

学号：102400313

CSDN地址：点击访问

性格：沉稳细致，擅长梳理需求文档与原型设计

擅长的技术：墨刀原型、需求分析、Git版本管理，沟通交际

兴趣爱好：登山，骑行，定向，游泳，跑步，乒乓球，羽毛球，钓鱼

希望的软工角色：产品经理PM

个人Slogan：把想法落地，让设计可行。

4.2 兰秀楠

学号：102400316

CSDN地址：点击访问

性格：耐心细致，注重页面交互体验，乐于沟通对接后端，遇到bug愿意反复调试

擅长的技术：HTML、JavaScript、Python、Git、VS Code

兴趣爱好：浏览前端开源项目、打篮球

希望的软工角色：前端开发，负责页面搭建、组件封装、接口联调、页面交互实现

个人Slogan：精益求精，把每一个页面做到更好。

4.3 甘羽潇

学号：102400437

CSDN地址：点击访问

性格：E人里的I人

擅长的技术：Java、JavaScript，掌握SpringBoot、Vue3框架；熟悉MySQL数据库、Redis缓存

兴趣爱好：排球、钢琴

希望的软工角色：后端/PM

个人Slogan：觉今是而昨非。

4.4 张祺

学号：102400432

CSDN地址：点击访问

性格：乐观开朗

擅长的技术：golang，c++，python以及redis，mysql数据库，Linux作远程测试时的基本使用，gin框架，protobuf和thrift的编写，hertz框架，对象存储，rpc调用，服务发现consul，分布式框架MapReduce，持续开发与集成

兴趣爱好：玩儿游戏

希望的软工角色：后端开发

个人Slogan：代码能跑就行。

4.5 陈子涵

学号：102400314

CSDN地址：点击访问

性格：安静

擅长的技术：Go 后端开发，Gin、gRPC、MySQL、Redis、RabbitMQ，Docker、Git，熟悉 C++/STL

兴趣爱好：听音乐，游戏

希望的软工角色：后端、测试、文档 & 配置管理（CM）

个人Slogan：我将提供除帮助外的一切支持。

4.6 梁鑫敏

学号：102400438

CSDN地址：点击访问

性格：做事认真负责，善于发现细节问题，乐于和团队沟通协作

擅长的技术：HTML、CSS、JavaScript，熟悉基础页面调试，会简单功能测试，掌握 Git

兴趣爱好：钢琴，排球，拍照

希望的软工角色：前端，测试

个人Slogan：于细微处把关，用耐心打磨作品。

五、团队考核方案

5.1 考核总则

为了确保团队项目高效推进，体现“多劳多得、公平公正”的原则，团队全体成员经过讨论，制定以下绩效考核方案（总分100分）。每次迭代/阶段结束后进行一次评分，个人最终得分将作为期末成绩的重要依据。

5.2 任务完成（50 分，任务点积分制）

考核维度	分值	评分细则
任务完成度	50分	按时按质完成个人分配任务（代码、文档、测试等），无延期（50分）。任务延期但未影响整体进度（30-40分）。未完成任务或严重影响进度（0-20分）。
团队协作与沟通	20分	积极参与团队会议，主动沟通，乐于帮助队友（20分）。偶尔缺席会议，沟通不积极（10-15分）。长期失联，不配合团队（0-5分）。
代码/文档质量	20分	代码规范，注释清晰，文档详细（20分）。代码基本可运行，文档较全（10-15分）。代码质量差，无文档（0-5分）。
创新与额外贡献	10分	提出建设性意见、解决关键技术难题、承担额外任务（10分）。有一定贡献（5分）。无额外贡献（0分）。

六、团队协作机制与规范

为了提高开发效率，减少沟通成本，团队制定了严格的协作机制：

• 沟通机制
每周一晚召开 30 分钟线上例会，同步进度、讨论难点并规划本周任务；日常使用微信/QQ群保持即时沟通；使用共享文档记录会议纪要。

• 代码管理（Git Flow）
严格遵循 Git 工作流。main 分支保护，只允许合并经过测试的代码；开发主要在 dev 分支；每个功能点创建 feature/xxx 分支。所有代码合并前必须发起 Pull Request (PR)，并至少由一名其他成员 Code Review 通过后才能合入。

• 代码规范
前端使用 ESLint + Prettier 统一代码格式；后端遵循 Go/Java 官方代码规范，关键逻辑必须写注释。接口文档使用 Swagger/Apifox 统一维护，前后端严格按照接口文档并行开发。

七、项目风险与应对策略

风险类型	风险描述	应对策略
需求风险	开发过程中需求变更，导致返工	前期充分调研，需求文档确认后冻结；变更需经全员讨论并评估工作量。
技术风险	前端/后端成员对某些框架不熟悉，导致进度延误	前期预留技术预研时间；技术较强的成员（张祺、陈子涵）负责攻克核心难点；建立内部技术分享机制。
进度风险	部分成员课程压力大，导致任务延期	采用任务点积分制（见考核方案），提前识别风险；核心模块预留缓冲时间；任务分解到天，及时跟进。
协作风险	前后端接口联调困难	前期严格定义接口规范（RESTful + JSON），使用 Apifox 模拟接口数据，确保前后端可独立并行开发。