16周软件项目开发路线¶
本课程不是“先写代码,最后交一个能运行的系统”,而是按照规范的软件开发流程,完成一个需求清楚、设计合理、过程可追踪、功能可测试、系统可部署、成果可展示的软件项目。
16周内,项目将经历:
flowchart LR
A[项目立项] --> B[需求分析]
B --> C[原型与系统设计]
C --> D[工程初始化]
D --> E[迭代开发]
E --> F[测试与优化]
F --> G[部署上线]
G --> H[验收答辩]
H -.反馈与改进.-> B
课程主线
以一个真实项目贯穿整个学期,以 Git 记录开发过程,以 AI 编程工具辅助分析、设计、编码、测试和文档整理。每个阶段都必须提交可检查的成果,不能只在期末展示最终页面。
一、课程完成目标¶
完成本课程后,你应当能够:
- 按照软件开发全生命周期组织一个完整项目;
- 使用 AI 编程工具辅助需求分析、系统设计、编码、测试和调试;
- 使用 Git 和 GitHub/Gitee 进行版本管理与团队协作;
- 完成前端、后端、数据库和接口的协同开发;
- 对系统进行功能、权限、安全和异常测试;
- 将软件部署到服务器并提供可访问地址;
- 形成可用于课程答辩、毕业设计和求职展示的项目成果;
- 能够解释项目的需求、架构、核心代码及 AI 使用过程。
二、16周与软件开发生命周期的对应关系¶
| 项目阶段 | 周次 | 阶段目标 | 阶段门成果 |
|---|---|---|---|
| 课程导入与项目立项 | 第1~2周 | 明确问题、用户、价值和项目边界 | 选题通过评审,MVP范围明确 |
| 需求分析 | 第3周 | 明确系统做什么及如何验收 | 需求可验证,角色和流程完整 |
| 产品与系统设计 | 第4~5周 | 明确软件怎么用、数据怎么存、系统怎么实现 | 原型、架构和数据库设计通过评审 |
| 工程初始化 | 第6周 | 建立可协作、可运行的工程骨架 | 项目能够启动,接口和协作规范明确 |
| 迭代开发 | 第7~11周 | 按功能闭环持续交付可运行版本 | 核心业务完成,前后端集成通过 |
| 测试与质量改进 | 第12~13周 | 发现并修复缺陷,完善安全与工程质量 | 严重缺陷关闭,核心测试通过 |
| 部署与成果包装 | 第14~15周 | 发布系统并整理交付材料 | 系统可访问,文档和演示材料齐全 |
| 验收与答辩 | 第16周 | 验证真实性、完整性和个人能力 | 通过演示、代码抽查和现场修改 |
三、16周逐周任务¶
第1周:课程导入与AI编程体验¶
本周目标: 理解课程要求、软件开发完整流程和 AI 编程的正确使用方式。
主要任务:
- 了解课程项目、考核方式和16周路线;
- 完成 JDK、IDE、Git、Node.js、数据库等环境检查;
- 注册并测试 GitHub/Gitee 代码仓库;
- 使用 AI 编程工具阅读并修改一个示例项目;
- 记录提示词、AI生成结果、人工修改和验证过程。
提交成果:
- 开发环境检查记录;
- 示例项目运行截图;
- 第一次 Git 提交;
- AI 协作记录。
验收重点: 能独立运行项目,能说明修改了什么,以及如何验证修改结果。
第2周:项目选题与立项¶
本周目标: 从真实问题出发确定项目,而不是先堆砌功能和技术。
主要任务:
- 明确目标用户、使用场景和核心痛点;
- 调研2~3个同类产品;
- 分析项目价值和技术可行性;
- 划定“本学期做什么、不做什么”;
- 确定最小可行产品(MVP);
- 完成团队分工和初步里程碑计划。
提交成果:
- 《项目立项书》;
- 竞品分析;
- 项目范围说明;
- MVP功能清单;
- 团队分工表。
验收重点: 选题有明确用户和真实问题,项目范围能够在课程时间内完成。
第3周:需求分析¶
本周目标: 明确系统必须做什么,以及做到什么程度才算完成。
主要任务:
- 识别用户角色及其权限;
- 梳理核心业务流程;
- 编写用户故事或用例;
- 整理功能需求和非功能需求;
- 说明正常流程、异常流程和业务规则;
- 确定需求优先级;
- 为核心需求编写验收标准。
提交成果:
- 《软件需求规格说明书》;
- 用户角色与权限表;
- 功能清单;
- 用例图或业务流程图;
- 核心需求验收标准。
验收重点: 每项核心需求都可测试、可演示、可验收,不使用“功能完善”“体验良好”等模糊表述。
第4周:页面原型与总体设计¶
本周目标: 在大规模编码前确定页面结构、操作流程和总体架构。
主要任务:
- 设计菜单结构和页面跳转关系;
- 绘制低保真或高保真原型;
- 标注加载、空数据、错误和无权限状态;
- 划分前端、后端和公共模块;
- 确定主要技术栈;
- 绘制系统架构图和功能模块图。
提交成果:
- 页面原型;
- 页面流程图;
- 系统架构图;
- 功能模块图;
- 技术选型说明。
验收重点: 页面与需求一一对应,核心业务流程能够在原型中完整走通。
第5周:数据库设计¶
本周目标: 将业务对象和规则转化为合理的数据模型。
主要任务:
- 识别核心实体及实体关系;
- 绘制数据库 ER 图;
- 设计表、字段、主键、外键和索引;
- 统一命名、数据类型和审计字段;
- 编写数据字典、建表 SQL 和初始化数据;
- 检查数据冗余、一致性和权限边界。
提交成果:
- 数据库 ER 图;
- 数据字典;
- 建表 SQL;
- 初始化数据脚本;
- 数据库设计说明。
验收重点: 数据表能支持业务需求,关系清楚,关键约束和字段含义明确。
第6周:接口设计与项目骨架¶
本周目标: 建立团队可共同开发的工程基础。
主要任务:
- 初始化前端和后端项目;
- 建立 Git 分支和提交规范;
- 配置开发、测试和生产环境;
- 完成统一返回、参数校验、异常处理和日志基础配置;
- 设计 RESTful API;
- 编写请求参数、返回结果、错误码和权限要求;
- 配置 Swagger/OpenAPI 或 Apifox;
- 建立基础持续集成检查。
提交成果:
- 可运行的前后端项目骨架;
- API接口清单和文档;
- Git协作规范;
- 项目启动说明;
- 数据库初始化脚本。
验收重点: 新成员依据 README 能运行项目,前后端可以通过至少一个接口完成通信。
第7周:登录、认证与权限¶
本周目标: 完成用户进入系统所需的身份认证和权限控制。
主要任务:
- 实现注册、登录、退出和用户信息查询;
- 完成密码加密存储;
- 使用 Session、JWT 或统一认证方案;
- 实现角色和资源权限控制;
- 处理未登录、无权限和登录失效状态;
- 测试普通用户越权访问问题。
提交成果:
- 可运行的登录与权限功能;
- 权限矩阵;
- 登录和越权测试用例;
- 本周演示版本。
验收重点: 不能只隐藏页面按钮,后端接口也必须进行权限校验。
第8周:核心业务模块一¶
本周目标: 完成第一个纵向业务闭环。
一个完整业务闭环通常包括:
主要任务:
- 完成核心业务的新增、查询、修改和删除;
- 实现分页、条件查询和数据校验;
- 处理业务异常;
- 完成前后端联调;
- 编写单元测试或接口测试。
提交成果:
- 第一个完整业务闭环;
- 接口测试记录;
- 代码评审记录;
- Git提交与合并记录。
验收重点: 功能必须真实读写数据库,不能只展示静态页面或模拟数据。
第9周:核心业务模块二¶
本周目标: 完成项目最有价值的业务规则和多角色协作流程。
主要任务:
- 实现第二个核心模块;
- 处理模块间的数据关联;
- 完成状态流转、审批、预约、订单或其他关键业务规则;
- 加强数据权限和并发场景处理;
- 补充异常流程测试。
提交成果:
- 第二个核心业务闭环;
- 业务状态说明;
- 异常场景测试;
- 阶段演示版本。
验收重点: 能说明业务规则为什么这样设计,并能够演示正常与异常流程。
第10周:前后端联调与系统集成¶
本周目标: 将分散功能集成为一个连贯、稳定的系统。
主要任务:
- 统一接口参数、返回格式和错误处理;
- 检查跨页面和跨模块业务流程;
- 处理登录状态、路由权限和数据刷新;
- 解决重复请求、空数据和加载状态问题;
- 完成主要功能的集成测试;
- 清理临时代码、模拟数据和无效接口。
提交成果:
- 前后端集成版本;
- 联调问题清单;
- 集成测试记录;
- 已知问题清单。
验收重点: 核心业务能够从开始到结束连续演示,不依赖手工修改数据库。
第11周:AI功能或项目特色功能¶
本周目标: 在核心业务稳定的基础上增加有价值的特色能力。
可选方向包括:
- 大模型问答与内容生成;
- RAG知识库检索;
- 数据分析与可视化;
- 推荐、预警或智能搜索;
- 地图、语音、图像识别等第三方能力;
- 能体现项目业务特色的创新功能。
主要任务:
- 说明特色功能解决的真实问题;
- 设计输入、输出、失败处理和降级方案;
- 对第三方服务进行封装;
- 保护 API Key 和用户隐私;
- 记录模型、提示词、知识来源和测试结果。
提交成果:
- 可演示的特色功能;
- 特色功能设计说明;
- 效果测试记录;
- 失败处理和安全说明。
验收重点: AI功能必须与项目业务结合,不能只增加一个与系统无关的聊天窗口。
第12周:软件测试与缺陷修复¶
本周目标: 依据需求和验收标准系统地发现问题。
主要任务:
- 编写功能、接口、权限和异常测试用例;
- 准备边界值、错误值和空值测试数据;
- 执行测试并记录实际结果;
- 建立缺陷清单并确定严重程度;
- 修复缺陷后执行回归测试;
- 检查需求是否均有测试证据。
提交成果:
- 测试计划;
- 测试用例;
- 缺陷清单;
- 缺陷修复记录;
- 回归测试结果。
验收重点: 测试用例不能只有正常流程,必须覆盖错误参数、越权访问和边界情况。
第13周:工程质量、安全与性能¶
本周目标: 从“功能能运行”提升到“系统更可靠、可维护”。
主要任务:
- 完善参数校验、全局异常和日志;
- 检查 SQL 注入、XSS、越权和文件上传风险;
- 检查密码、密钥和隐私数据保护;
- 优化慢查询、重复请求和明显性能问题;
- 统一代码风格并清理重复代码;
- 检查依赖版本和构建过程;
- 完善备份与恢复方案。
提交成果:
- 工程质量检查表;
- 安全检查记录;
- 性能测试或优化记录;
- 重构前后说明;
- 发布候选版本。
验收重点: 阻断级和严重级缺陷关闭,敏感信息未提交到代码仓库。
第14周:部署上线¶
本周目标: 将软件从开发环境发布到可访问的运行环境。
主要任务:
- 准备服务器、域名、端口和 HTTPS;
- 配置生产环境变量;
- 构建前端和后端发布包;
- 执行数据库迁移和初始化;
- 使用 Nginx、Docker 或脚本完成部署;
- 配置日志、监控、备份和回滚方案;
- 上线后执行冒烟测试。
提交成果:
- 可访问的部署地址;
- 《安装部署手册》;
- 生产环境配置说明;
- 冒烟测试记录;
- 备份与回滚方案。
验收重点: 项目应在新的浏览器或设备中正常访问,不能只在开发者电脑上运行。
第15周:项目交付与成果包装¶
本周目标: 将开发成果整理为可验收、可复用、可展示的项目材料。
主要任务:
- 完善 README 和项目介绍;
- 整理需求、设计、接口、测试和部署文档;
- 编写用户操作手册;
- 制作项目演示视频;
- 制作答辩 PPT;
- 准备用于求职的项目描述;
- 进行模拟答辩和代码讲解。
提交成果:
- 完整项目文档;
- 用户操作手册;
- 项目演示视频;
- 答辩 PPT;
- 求职项目介绍;
- 最终发布版本。
验收重点: 文档内容与实际系统一致,演示视频能够完整展示核心业务。
第16周:项目验收与答辩¶
本周目标: 证明项目成果真实、完整,并能说明个人贡献。
答辩环节:
- 介绍项目背景、用户和价值;
- 演示核心业务流程;
- 说明系统架构和数据库设计;
- 展示特色功能;
- 回答代码和技术问题;
- 接受代码抽查;
- 完成现场小修改;
- 说明 AI 使用过程、人工决策和验证方法;
- 总结项目不足和后续迭代计划。
提交成果:
- 最终源代码与版本标签;
- 最终部署地址;
- 项目验收材料;
- 答辩 PPT 和演示视频;
- 个人贡献说明;
- 项目复盘报告。
验收重点: 能解释、能定位、能修改自己的代码,而不是只会运行一个由 AI 生成的项目。
四、每周课堂节奏¶
每周课堂按照以下节奏进行:
- 教师讲解与示范: 讲解本阶段方法、规范和案例;
- 任务拆解: 将本周目标拆成可执行任务;
- 小组开发: 按分工完成项目任务;
- 教师巡查: 检查需求、代码、Git和AI使用记录;
- 阶段展示: 演示本周可运行成果;
- 提交与复盘: 提交成果、记录问题和下周计划。
建议每周至少形成一个可运行版本,并使用版本标签记录重要里程碑:
五、阶段门与继续条件¶
项目不能只按时间向后推进。进入下一阶段前,应完成对应的质量检查。
| 阶段门 | 必须满足的条件 |
|---|---|
| 立项通过 | 用户、问题、价值和MVP范围清楚 |
| 需求通过 | 核心需求有验收标准,角色和业务流程完整 |
| 设计通过 | 原型、架构、数据库和接口能够支撑需求 |
| 开发准入 | 项目骨架可运行,Git、环境和协作规范明确 |
| 测试准入 | 核心业务完成,系统可以连续演示 |
| 发布准入 | 严重缺陷关闭,部署、备份和回滚方案可执行 |
| 最终验收 | 系统可访问,文档齐全,成员能解释并修改代码 |
六、Git协作要求¶
项目全过程必须使用 Git,不允许只在期末上传一个压缩包。
推荐分支¶
- main:稳定、可发布版本;
- develop:日常集成版本;
- feature/功能名:功能开发;
- fix/问题名:缺陷修复。
提交信息示例¶
基本要求¶
- 每名成员使用自己的账号提交代码;
- 每次提交聚焦一个明确变更;
- 不提交密码、API Key、数据库备份和无关大文件;
- 重要功能通过合并请求或代码评审后进入主分支;
- 提交记录应能反映每名成员的真实贡献;
- 阶段成果使用标签或发布版本进行标记。
七、AI协作要求¶
AI可以参与软件开发全过程,但不能替代需求确认、技术决策、代码审查和项目验收。
AI可以辅助¶
- 调研和比较项目方案;
- 整理用户故事与验收标准;
- 检查需求和设计遗漏;
- 生成原型、代码和测试草案;
- 解释错误、辅助调试和代码重构;
- 生成测试数据、部署配置和文档初稿;
- 分析日志和提出优化建议。
人必须负责¶
- 判断需求是否真实、合理;
- 选择技术方案并说明原因;
- 理解和审查 AI 生成的代码;
- 运行测试并确认结果;
- 保护密码、密钥和隐私数据;
- 对最终提交的软件质量负责。
AI使用红线
不向公共模型提交密码、密钥、隐私数据和未授权代码;不直接合并自己无法解释的 AI 生成代码;不伪造测试结果、引用、截图和开发记录;不能以“程序能够运行”代替测试与安全审查。
AI协作记录至少包括¶
- 任务背景;
- 使用的工具或模型;
- 关键提示词;
- AI输出摘要;
- 发现的问题;
- 人工修改内容;
- 验证方法与结果;
- 本次使用反思。
八、最终交付清单¶
课程结束时,每个项目至少应提交:
- 项目立项书;
- 竞品分析与MVP范围;
- 软件需求规格说明书;
- 用户角色与权限表;
- 用例图或业务流程图;
- 页面原型;
- 系统架构图与功能模块图;
- 数据库ER图、数据字典和建表SQL;
- API接口文档;
- Git源代码仓库及规范提交记录;
- 测试用例、缺陷清单和测试报告;
- 可访问的部署地址;
- 安装部署手册与回滚方案;
- 用户操作手册;
- 项目README;
- 演示视频;
- 答辩PPT;
- AI协作记录;
- 团队分工与个人贡献说明;
- 项目复盘报告。
九、什么才算“项目完成”¶
项目不能只以“页面基本做完”或“在开发者电脑上可以运行”作为完成标准。
一个完整项目至少应满足:
- 核心需求均已实现并有验收证据;
- 核心业务可以从开始到结束连续演示;
- 程序可以稳定构建、启动和部署;
- 权限、参数、异常和主要安全风险经过检查;
- 严重缺陷已经关闭;
- 数据库脚本、环境配置和依赖说明完整;
- 代码进入版本管理并能反映真实开发过程;
- 文档与实际系统一致;
- 生产环境具备基本日志、备份和回滚能力;
- 团队成员能解释架构、业务和本人负责的代码;
- 软件通过最终验收和答辩。
不要拖到最后几周才开始
项目成绩不仅取决于最终效果,还会检查阶段成果、Git提交记录、测试证据、AI协作记录和成员贡献。缺少过程证据,即使最终页面能够运行,也不能视为完成了规范的软件项目开发。