跳转至

16周软件项目开发路线

本课程不是“先写代码,最后交一个能运行的系统”,而是按照规范的软件开发流程,完成一个需求清楚、设计合理、过程可追踪、功能可测试、系统可部署、成果可展示的软件项目。

16周内,项目将经历:

flowchart LR
    A[项目立项] --> B[需求分析]
    B --> C[原型与系统设计]
    C --> D[工程初始化]
    D --> E[迭代开发]
    E --> F[测试与优化]
    F --> G[部署上线]
    G --> H[验收答辩]
    H -.反馈与改进.-> B

课程主线

以一个真实项目贯穿整个学期,以 Git 记录开发过程,以 AI 编程工具辅助分析、设计、编码、测试和文档整理。每个阶段都必须提交可检查的成果,不能只在期末展示最终页面。


一、课程完成目标

完成本课程后,你应当能够:

  1. 按照软件开发全生命周期组织一个完整项目;
  2. 使用 AI 编程工具辅助需求分析、系统设计、编码、测试和调试;
  3. 使用 Git 和 GitHub/Gitee 进行版本管理与团队协作;
  4. 完成前端、后端、数据库和接口的协同开发;
  5. 对系统进行功能、权限、安全和异常测试;
  6. 将软件部署到服务器并提供可访问地址;
  7. 形成可用于课程答辩、毕业设计和求职展示的项目成果;
  8. 能够解释项目的需求、架构、核心代码及 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周:核心业务模块一

本周目标: 完成第一个纵向业务闭环。

一个完整业务闭环通常包括:

数据表 → 后端数据访问 → 业务逻辑 → API接口
      → 前端页面 → 参数校验 → 权限控制 → 测试

主要任务:

  • 完成核心业务的新增、查询、修改和删除;
  • 实现分页、条件查询和数据校验;
  • 处理业务异常;
  • 完成前后端联调;
  • 编写单元测试或接口测试。

提交成果:

  • 第一个完整业务闭环;
  • 接口测试记录;
  • 代码评审记录;
  • Git提交与合并记录。

验收重点: 功能必须真实读写数据库,不能只展示静态页面或模拟数据。


第9周:核心业务模块二

本周目标: 完成项目最有价值的业务规则和多角色协作流程。

主要任务:

  • 实现第二个核心模块;
  • 处理模块间的数据关联;
  • 完成状态流转、审批、预约、订单或其他关键业务规则;
  • 加强数据权限和并发场景处理;
  • 补充异常流程测试。

提交成果:

  • 第二个核心业务闭环;
  • 业务状态说明;
  • 异常场景测试;
  • 阶段演示版本。

验收重点: 能说明业务规则为什么这样设计,并能够演示正常与异常流程。


第10周:前后端联调与系统集成

本周目标: 将分散功能集成为一个连贯、稳定的系统。

主要任务:

  • 统一接口参数、返回格式和错误处理;
  • 检查跨页面和跨模块业务流程;
  • 处理登录状态、路由权限和数据刷新;
  • 解决重复请求、空数据和加载状态问题;
  • 完成主要功能的集成测试;
  • 清理临时代码、模拟数据和无效接口。

提交成果:

  • 前后端集成版本;
  • 联调问题清单;
  • 集成测试记录;
  • 已知问题清单。

验收重点: 核心业务能够从开始到结束连续演示,不依赖手工修改数据库。


第11周:AI功能或项目特色功能

本周目标: 在核心业务稳定的基础上增加有价值的特色能力。

可选方向包括:

  • 大模型问答与内容生成;
  • RAG知识库检索;
  • 数据分析与可视化;
  • 推荐、预警或智能搜索;
  • 地图、语音、图像识别等第三方能力;
  • 能体现项目业务特色的创新功能。

主要任务:

  • 说明特色功能解决的真实问题;
  • 设计输入、输出、失败处理和降级方案;
  • 对第三方服务进行封装;
  • 保护 API Key 和用户隐私;
  • 记录模型、提示词、知识来源和测试结果。

提交成果:

  • 可演示的特色功能;
  • 特色功能设计说明;
  • 效果测试记录;
  • 失败处理和安全说明。

验收重点: AI功能必须与项目业务结合,不能只增加一个与系统无关的聊天窗口。


第12周:软件测试与缺陷修复

本周目标: 依据需求和验收标准系统地发现问题。

主要任务:

  • 编写功能、接口、权限和异常测试用例;
  • 准备边界值、错误值和空值测试数据;
  • 执行测试并记录实际结果;
  • 建立缺陷清单并确定严重程度;
  • 修复缺陷后执行回归测试;
  • 检查需求是否均有测试证据。

提交成果:

  • 测试计划;
  • 测试用例;
  • 缺陷清单;
  • 缺陷修复记录;
  • 回归测试结果。

验收重点: 测试用例不能只有正常流程,必须覆盖错误参数、越权访问和边界情况。


第13周:工程质量、安全与性能

本周目标: 从“功能能运行”提升到“系统更可靠、可维护”。

主要任务:

  • 完善参数校验、全局异常和日志;
  • 检查 SQL 注入、XSS、越权和文件上传风险;
  • 检查密码、密钥和隐私数据保护;
  • 优化慢查询、重复请求和明显性能问题;
  • 统一代码风格并清理重复代码;
  • 检查依赖版本和构建过程;
  • 完善备份与恢复方案。

提交成果:

  • 工程质量检查表;
  • 安全检查记录;
  • 性能测试或优化记录;
  • 重构前后说明;
  • 发布候选版本。

验收重点: 阻断级和严重级缺陷关闭,敏感信息未提交到代码仓库。


第14周:部署上线

本周目标: 将软件从开发环境发布到可访问的运行环境。

主要任务:

  • 准备服务器、域名、端口和 HTTPS;
  • 配置生产环境变量;
  • 构建前端和后端发布包;
  • 执行数据库迁移和初始化;
  • 使用 Nginx、Docker 或脚本完成部署;
  • 配置日志、监控、备份和回滚方案;
  • 上线后执行冒烟测试。

提交成果:

  • 可访问的部署地址;
  • 《安装部署手册》;
  • 生产环境配置说明;
  • 冒烟测试记录;
  • 备份与回滚方案。

验收重点: 项目应在新的浏览器或设备中正常访问,不能只在开发者电脑上运行。


第15周:项目交付与成果包装

本周目标: 将开发成果整理为可验收、可复用、可展示的项目材料。

主要任务:

  • 完善 README 和项目介绍;
  • 整理需求、设计、接口、测试和部署文档;
  • 编写用户操作手册;
  • 制作项目演示视频;
  • 制作答辩 PPT;
  • 准备用于求职的项目描述;
  • 进行模拟答辩和代码讲解。

提交成果:

  • 完整项目文档;
  • 用户操作手册;
  • 项目演示视频;
  • 答辩 PPT;
  • 求职项目介绍;
  • 最终发布版本。

验收重点: 文档内容与实际系统一致,演示视频能够完整展示核心业务。


第16周:项目验收与答辩

本周目标: 证明项目成果真实、完整,并能说明个人贡献。

答辩环节:

  1. 介绍项目背景、用户和价值;
  2. 演示核心业务流程;
  3. 说明系统架构和数据库设计;
  4. 展示特色功能;
  5. 回答代码和技术问题;
  6. 接受代码抽查;
  7. 完成现场小修改;
  8. 说明 AI 使用过程、人工决策和验证方法;
  9. 总结项目不足和后续迭代计划。

提交成果:

  • 最终源代码与版本标签;
  • 最终部署地址;
  • 项目验收材料;
  • 答辩 PPT 和演示视频;
  • 个人贡献说明;
  • 项目复盘报告。

验收重点: 能解释、能定位、能修改自己的代码,而不是只会运行一个由 AI 生成的项目。


四、每周课堂节奏

每周课堂按照以下节奏进行:

  1. 教师讲解与示范: 讲解本阶段方法、规范和案例;
  2. 任务拆解: 将本周目标拆成可执行任务;
  3. 小组开发: 按分工完成项目任务;
  4. 教师巡查: 检查需求、代码、Git和AI使用记录;
  5. 阶段展示: 演示本周可运行成果;
  6. 提交与复盘: 提交成果、记录问题和下周计划。

建议每周至少形成一个可运行版本,并使用版本标签记录重要里程碑:

1
2
3
4
5
6
7
v0.1  项目骨架
v0.2  登录与权限
v0.3  核心业务一
v0.4  核心业务二
v0.5  特色功能
v0.9  发布候选版本
v1.0  课程验收版本

五、阶段门与继续条件

项目不能只按时间向后推进。进入下一阶段前,应完成对应的质量检查。

阶段门 必须满足的条件
立项通过 用户、问题、价值和MVP范围清楚
需求通过 核心需求有验收标准,角色和业务流程完整
设计通过 原型、架构、数据库和接口能够支撑需求
开发准入 项目骨架可运行,Git、环境和协作规范明确
测试准入 核心业务完成,系统可以连续演示
发布准入 严重缺陷关闭,部署、备份和回滚方案可执行
最终验收 系统可访问,文档齐全,成员能解释并修改代码

六、Git协作要求

项目全过程必须使用 Git,不允许只在期末上传一个压缩包。

推荐分支

  • main:稳定、可发布版本;
  • develop:日常集成版本;
  • feature/功能名:功能开发;
  • fix/问题名:缺陷修复。

提交信息示例

1
2
3
4
5
feat: 增加健康记录分页查询
fix: 修复普通用户越权查看记录问题
docs: 补充本地部署说明
test: 增加登录接口异常测试
refactor: 重构订单状态更新逻辑

基本要求

  • 每名成员使用自己的账号提交代码;
  • 每次提交聚焦一个明确变更;
  • 不提交密码、API Key、数据库备份和无关大文件;
  • 重要功能通过合并请求或代码评审后进入主分支;
  • 提交记录应能反映每名成员的真实贡献;
  • 阶段成果使用标签或发布版本进行标记。

七、AI协作要求

AI可以参与软件开发全过程,但不能替代需求确认、技术决策、代码审查和项目验收。

AI可以辅助

  • 调研和比较项目方案;
  • 整理用户故事与验收标准;
  • 检查需求和设计遗漏;
  • 生成原型、代码和测试草案;
  • 解释错误、辅助调试和代码重构;
  • 生成测试数据、部署配置和文档初稿;
  • 分析日志和提出优化建议。

人必须负责

  • 判断需求是否真实、合理;
  • 选择技术方案并说明原因;
  • 理解和审查 AI 生成的代码;
  • 运行测试并确认结果;
  • 保护密码、密钥和隐私数据;
  • 对最终提交的软件质量负责。

AI使用红线

不向公共模型提交密码、密钥、隐私数据和未授权代码;不直接合并自己无法解释的 AI 生成代码;不伪造测试结果、引用、截图和开发记录;不能以“程序能够运行”代替测试与安全审查。

AI协作记录至少包括

  • 任务背景;
  • 使用的工具或模型;
  • 关键提示词;
  • AI输出摘要;
  • 发现的问题;
  • 人工修改内容;
  • 验证方法与结果;
  • 本次使用反思。

八、最终交付清单

课程结束时,每个项目至少应提交:

  • 项目立项书;
  • 竞品分析与MVP范围;
  • 软件需求规格说明书;
  • 用户角色与权限表;
  • 用例图或业务流程图;
  • 页面原型;
  • 系统架构图与功能模块图;
  • 数据库ER图、数据字典和建表SQL;
  • API接口文档;
  • Git源代码仓库及规范提交记录;
  • 测试用例、缺陷清单和测试报告;
  • 可访问的部署地址;
  • 安装部署手册与回滚方案;
  • 用户操作手册;
  • 项目README;
  • 演示视频;
  • 答辩PPT;
  • AI协作记录;
  • 团队分工与个人贡献说明;
  • 项目复盘报告。

九、什么才算“项目完成”

项目不能只以“页面基本做完”或“在开发者电脑上可以运行”作为完成标准。

一个完整项目至少应满足:

  • 核心需求均已实现并有验收证据;
  • 核心业务可以从开始到结束连续演示;
  • 程序可以稳定构建、启动和部署;
  • 权限、参数、异常和主要安全风险经过检查;
  • 严重缺陷已经关闭;
  • 数据库脚本、环境配置和依赖说明完整;
  • 代码进入版本管理并能反映真实开发过程;
  • 文档与实际系统一致;
  • 生产环境具备基本日志、备份和回滚能力;
  • 团队成员能解释架构、业务和本人负责的代码;
  • 软件通过最终验收和答辩。

不要拖到最后几周才开始

项目成绩不仅取决于最终效果,还会检查阶段成果、Git提交记录、测试证据、AI协作记录和成员贡献。缺少过程证据,即使最终页面能够运行,也不能视为完成了规范的软件项目开发。