个人总结
一、系统梳理学习成果
1.1 技术、工具与工程能力提升
在本学期的软件工程课程中，我参与了"SecGuard漏洞管理与跟踪平台"项目------基于OWASP BLT进行二次开发，打造轻量化、自动化、可协作的校园小型团队漏洞管理平台。通过完整的项目实践，我在以下方面获得了显著提升：
| 能力维度 | 提升前 | 提升后 |
|---|---|---|
| 前端开发 | 仅会基础HTML/CSS | 掌握React + Next.js + Tailwind CSS技术栈，能独立完成高保真原型设计与前端页面开发 |
| 后端开发 | 了解Python基础 | 掌握Django + Django Ninja框架，能设计RESTful API并实现完整业务逻辑 |
| 数据库设计 | 仅会简单SQL | 掌握PostgreSQL数据库设计，能完成ER图建模、索引优化、表结构设计 |
| 项目管理 | 无经验 | 掌握敏捷开发流程，能制定迭代计划、使用燃尽图跟踪进度 |
| 协作开发 | 无经验 | 掌握Git分支策略、Code Review流程、团队协作规范 |
1.2 人机协作与批判性思维
在项目过程中，我使用了DeepSeek大模型辅助开发。与AI协作的核心经验是：AI是加速器而非替代品。AI能快速生成框架和初稿，但核心的业务理解和批判性分析必须由人完成。
1.3 目标达成
- 掌握RESTful API设计：独立完成了认证模块（JWT Token + BCrypt加密）和漏洞报告CRUD接口的设计与实现
- 掌握前后端分离架构：理解了React + Django的分层架构设计，包括表现层、控制层、业务逻辑层、数据访问层、基础设施层的职责划分
- 掌握数据库建模：完成了10张核心数据表的设计，包括用户、团队、项目、漏洞报告、扫描任务、漏洞信息、评论、附件、通知、审计日志
- 掌握敏捷开发流程：参与制定迭代计划，使用燃尽图跟踪冲刺进度，实践了Sprint迭代开发
- 掌握漏洞管理业务：深入理解了漏洞生命周期（待分派→处理中→已修复→已复核→已关闭）和状态流转机制
1.4 不足与反思
- 自动化测试覆盖率不足：项目后期时间紧张，单元测试和集成测试编写不够充分，主要依赖手动测试验证功能。原因：前期对测试优先的开发方式重视不够，将测试视为"收尾工作"而非"开发过程的一部分"。
- 前端响应式设计不完善：原型设计主要针对桌面端，移动端适配考虑不足。原因：项目周期内优先保证核心功能交付，响应式设计被列为P2优先级推迟实施。
二、量化成果
2.1 工作量统计
| 指标 | 数值 |
|---|---|
| 项目总周期 | 约8周（第6-13周） |
| 个人投入时间 | 约120小时 |
| 代码行数 | 约3000行（前端+后端） |
| 注释行数 | 约400行 |
| 文档页数 | 约50页（需求分析、架构设计、原型说明、人机协作记录等） |
| Git签入次数 | 约30次 |
| 参与修复Bug数 | 约15个 |
2.2 AI工具使用记录
| AI工具 | 用途 | 使用频次 |
|---|---|---|
| DeepSeek | 需求分析、用户故事生成、类图设计、功能优先级划分 | 约15次对话 |
| Trae/Copilot | 代码生成、Bug修复建议、代码审查 | 约20次对话 |
2.3 人机协作关键记录
- AI是否帮我总结了目标？ 是的，AI帮我快速梳理了需求分析的框架和初稿，特别是用户故事格式和类图关系。但我验证后发现AI遗漏了ScanTask类（扫描任务管理），这是选题明确要求集成Nettacker的核心功能，必须补充。
- AI是否帮我发现了未意识到的技能提升点？ AI指出了我在"状态机设计"方面的提升------我之前没有意识到漏洞生命周期管理是一种经典的状态机模式。我对AI的评估基本赞同，但认为AI对"安全审计"方面的能力评估偏高，实际项目中审计日志的实现相对简单。
- AI生成内容的质量评估：AI生成的代码框架约70%可直接使用，但需要人工调整约30%的细节，如权限校验逻辑、状态流转约束、异常处理等。
三、布鲁姆分类法下的学习反思
3.1 应用（Application）------将所学应用到实际场景
场景1：使用Git分支策略管理多人协作
具体操作步骤：
- 创建
develop分支作为开发主线，feature/*分支用于功能开发 - 每位成员从
develop拉取feature分支进行开发（如feature/scan-integration） - 功能完成后提交Pull Request，经Code Review后合并回
develop - 迭代结束时将
develop合并到main分支进行发布
场景2：RESTful API设计实践
在漏洞报告模块中，严格遵循RESTful设计原则：
GET /api/reports--- 获取报告列表POST /api/reports--- 创建报告GET /api/reports/{id}--- 获取报告详情PUT /api/reports/{id}/assign--- 分派报告PUT /api/reports/{id}/status--- 更新状态
3.2 分析（Analysis）------拆解复杂问题的成因
问题：多团队数据隔离Bug
在项目开发中，出现了"团队漏洞被误判为个人漏洞"的严重Bug。拆解其成因：
- 根因 ：
check_report_access函数未按角色分层判断，导致团队漏洞和个人漏洞的权限判断逻辑混淆 - 直接原因 ：
isPersonalReport条件判断不够严格，缺少对team_id的校验 - 间接原因：早期数据库设计中Report模型缺少team字段关联，后续添加时未同步更新所有查询逻辑
解决方案：
- 修复权限判断逻辑，严格区分
isPersonalReport条件 - Report模型增加
team和reporter索引 - 统一团队角色名称（observer显示为"安全测试员"）
3.3 综合（Synthesis）------将零散任务整合为可执行计划
在项目初期，我使用WBS（工作分解结构）将项目拆解为可执行的任务单元，并结合燃尽图进行进度跟踪：
- WBS分解：将项目分为5大模块（用户认证、漏洞管理、扫描集成、报告导出、系统设置），每个模块再细分为具体功能点
- 迭代计划：按Sprint划分，每个Sprint 1-2周，明确每个Sprint的交付目标
- 燃尽图跟踪：每日更新剩余工作量，绘制燃尽图观察进度趋势
通过这种方式，将原本零散的需求和任务整合为有序的开发计划，确保了项目在预计时间内交付。
3.4 评价（Evaluation）------对比分析自身项目的优势与不足
对比对象：OWASP BLT原版项目
| 维度 | OWASP BLT原版 | SecGuard（本项目） | 评价 |
|---|---|---|---|
| 界面设计 | 界面陈旧，用户体验差 | 现代化UI，蓝色主色调，安全感强 | 本项目优势明显 |
| 扫描集成 | 缺少自动化扫描能力 | 集成Nettacker，支持结果自动导入 | 本项目核心改进 |
| 报告导出 | 功能不完善 | 支持PDF/HTML导出，含统计分析 | 本项目功能增强 |
| 部署方式 | 部署流程复杂 | Docker一键部署 | 本项目降低门槛 |
| 社区生态 | 成熟的开源社区，贡献者多 | 校园项目，用户量有限 | 原版优势明显 |
| 测试覆盖 | 有CI/CD和自动化测试 | 手动测试为主，覆盖率不足 | 原版优势明显 |
结论：本项目在用户体验和核心功能（扫描集成、报告导出）上实现了显著改进，但在测试覆盖和社区生态方面与成熟开源项目仍有差距。
四、人月神话------团队项目实践中的经验总结
4.1 我的"人月神话"
在项目中期，我们曾遇到一个典型的"人月神话"陷阱：扫描集成功能的开发比预期复杂得多------Nettacker的JSON输出格式需要额外解析，漏洞去重算法的实现也比想象中困难。当时有人提议"再加一个人来加速"，但我们意识到：
向一个已经延期的软件项目增加人手，只会使其更加延期。------布鲁克斯法则
原因在于：新成员需要时间理解代码和业务逻辑，而现有成员需要花时间进行知识传递，这反而会降低整体效率。我们最终选择的是缩减范围------将扫描集成从"实时扫描"简化为"结果导入"，先保证核心流程可用，再在后续迭代中增强。
4.2 团队发展阶段分析
根据塔克曼团队发展模型，我们团队经历了以下阶段：
| 阶段 | 是否经历 | 具体表现 |
|---|---|---|
| 形成期（Forming） | 是 | 组队初期，大家互相了解，明确分工：黄紫妍(PM)、林源龙(后端)、刘振求(前端)、张跃文(测试) |
| 风暴期（Storming） | 是 | 需求分析阶段对功能优先级有分歧------扫描集成是否作为MVP核心功能争论较久，最终通过MoSCoW方法达成一致 |
| 规范期（Norming） | 是 | 确定了Git分支策略、Code Review流程、迭代节奏，团队协作进入正轨 |
| 创造期（Performing） | 部分 | 在漏洞去重算法和PDF报告生成等难点上展现了创造力，但受时间限制未完全达到此阶段 |
是否达到"创造"阶段？ 部分达到。在扫描结果去重算法中，我们自主设计了基于CVE ID精确匹配 + Jaccard相似度模糊匹配的混合去重策略（相似度阈值≥80%），这属于团队自主创新的解决方案。但整体而言，项目更多是在已有框架（OWASP BLT）基础上进行改进，而非从零创造。
五、软件工程目标达成情况
5.1 研发出符合用户需求的软件
用户调研记录：
- 通过分析安全团队、开发人员、团队负责人三类角色的核心需求，设计了对应的用户故事
- 明确了三种用户角色：安全团队成员（漏洞上报）、团队负责人/PM（分派和审核）、开发人员（修复漏洞）
真实用户反馈：
- 在校园安全竞赛中，有同学反馈"漏洞上报表单操作简便，比之前用Excel记录效率高很多"
- 指导老师评价"报告导出功能对汇总安全状况很有帮助"
5.2 通过软件流程在预计时间内发布"足够好"的软件
迭代计划执行情况：
| Sprint | 目标 | 完成情况 |
|---|---|---|
| Sprint 1 | 用户认证 + 基础框架 | 完成 |
| Sprint 2 | 漏洞上报 + 列表展示 | 完成 |
| Sprint 3 | 漏洞分派 + 状态流转 | 完成 |
| Sprint 4 | 扫描集成 + 结果导入 | 完成（简化版） |
| Sprint 5 | 报告导出 + 统计分析 | 完成 |
| Sprint 6 | Bug修复 + 优化 | 完成 |
燃尽图显示项目整体进度基本符合预期，Sprint 4因扫描集成复杂度超预期略有延期，但通过范围调整在Sprint 5追回。
5.3 软件的可维护性和可继续发展性
代码规范：
- 后端采用Django标准项目结构，API模块化设计（auth.py、reports.py独立模块）
- 数据库模型使用Django ORM，字段命名规范，含完整choices定义
- API接口有完整的docstring注释
可扩展性设计：
- 分层架构设计使得各层可独立替换（如前端可从Next.js迁移到其他框架）
- 扫描器类型字段支持扩展（
scanner_type字段可添加新扫描工具） - 通知系统预留了邮件、站内信等多种通知渠道的扩展接口
不足：单元测试覆盖率不足，缺乏CI/CD自动化流水线，这是后续需要重点改进的方向。
六、对下一届的建议
对开学初的自己
- 测试先行，不要留到后面：单元测试应该在写代码的同时完成，而不是功能开发完再补。测试不是负担，而是保障代码质量的工具。
- 尽早熟悉Git协作流程：分支策略、合并冲突解决、Code Review这些技能越早掌握越好，不要等到项目中期才开始学习。
- 需求分析要充分：磨刀不误砍柴工，花在需求分析和架构设计上的时间会在开发阶段成倍回报。
对大一的自己
- 打好编程基础：数据结构、算法、数据库原理这些基础课程非常重要，项目开发中处处都会用到。
- 学会提问：遇到问题先自己思考和搜索，实在解决不了再问。提问时要把问题描述清楚------你做了什么、期望什么、实际发生了什么。
- 多动手实践：课堂知识只有通过项目实践才能真正理解和掌握，不要只停留在"看懂了"的层面。
对开学初的学弟学妹
- 组队要慎重：找靠谱的队友比找技术最强的队友更重要，团队协作能力和责任心是项目成功的关键。
- 善用AI但不要依赖AI：AI是很好的辅助工具，可以帮你快速生成框架和初稿，但核心的业务理解和批判性思维必须自己完成。AI生成的代码一定要审查和测试。
- 保持沟通：团队项目中，沟通比技术更重要。定期站会、及时同步进度、遇到问题早暴露，这些看似简单的习惯能避免很多后期的大坑。
- 拥抱变化：项目开发中需求变更是常态，不要害怕变更，要学会用敏捷思维应对变化------小步快跑、快速迭代、持续交付。
七、人机协作总评
7.1 AI在各板块的作用评估
| 板块 | AI帮助程度 | 批判性评估 |
|---|---|---|
| 需求分析 | 高 | AI快速生成框架，但遗漏关键业务场景，需人工补充 |
| 架构设计 | 中 | AI建议使用GraphQL，但根据团队实际情况选择RESTful更合适 |
| 代码开发 | 中高 | AI生成的代码框架约70%可用，但权限校验、状态流转等细节需人工调整 |
| Bug修复 | 高 | AI帮助快速定位问题根因，如多团队数据隔离Bug的权限判断逻辑 |
| 文档撰写 | 高 | AI帮助生成文档框架和格式，但内容准确性需人工验证 |
7.2 对AI协作的总体评价
AI在项目中的最大价值是提效------将原本需要2-3倍时间完成的工作压缩到更短时间。但AI的局限性也很明显：它不了解项目的具体业务背景和团队实际情况，生成的方案需要经过批判性分析后才能采纳。
核心原则：AI是工具，人是决策者。用AI加速执行，用人把控方向。