软件工程笔记2从课堂知识到可落地的项目实践距离我第一次整理软件工程的学习笔记已经过了大半年。那段时间我经历了课程设计、毕业设计选题也真正动手写了几个小项目回过头来再看当初记的那些要点发现很多东西在课本上说得通但一落到实际操作里就完全不是那么回事。这篇“软件工程笔记2”就是我在这个阶段踩坑、摸索、复盘之后攒下来的第二份干货合集主要围绕软件工程的建模、测试标准、课程设计与毕业设计选题、以及一些项目管理上的实操心得来聊。如果你是正在学软件工程导论、准备做课程设计或者正在纠结本科毕业论文选题的同学这篇笔记会比较对你的胃口。哪怕你只是对软件工程感兴趣想了解一个真实项目从需求到交付到底经历了什么也可以读下去。1. 软件工程的核心先想清楚“要做什么”再谈“怎么做”1.1 “软件工程”到底在解决什么问题很多人一想到软件工程就把它等同于“写代码”。但真正经历过完整项目的人都知道写代码只是整个系统工程中很小的一部分。软件工程要解决的真正问题是如何在有限的时间、人力、资源条件下构造出满足用户需求、质量可靠、易于维护的软件产品。它不是一门手艺而是一套“做事的规则”。我在学习软件工程导论时老师反复强调的一句话是软件危机本质上不是编程能力的问题而是管理复杂性的问题。项目越大、参与的人越多、需求变化越频繁失控的风险就越高。软件工程正是用工程化的方法流程、规范、文档、评审、测试来控制这种复杂性让它始终在可管理的范围内。在头歌平台做软件工程导论作业时有几个任务就是让画出用例图、类图这样的需求建模图。起初我觉得这些题目很“虚”画几个椭圆和箭头就能拿分了但后来自己做项目时才发现这些看似抽象的模型恰恰是团队沟通的“通用语言”。用例图告诉每一个人“系统为谁服务、提供什么能力”类图定义了数据结构和它们之间的关系时序图则把一次完整交互的来龙去脉交代清楚。没有这些图别说团队协作连自己隔两周再打开项目代码都可能一头雾水。1.2 建模思维用例图、类图、时序图的实际应用如果用一句话概括建模思维的价值那就是**“画图不是为了交作业而是为了逼你把模糊的想法说清楚”**。用例图Use Case Diagram是最入门、也最容易被低估的图。它回答的问题是系统有哪些角色这些角色分别能触发哪些操作我记得自己在头歌软件工程画图模块初次接触用例图时系统会在后台自动判分边界条件非常严苛——包含关系include用虚线箭头加«include»泛化关系用空心箭头表示不同画法得分完全不同。当时只当是考试技巧后来在需求评审会议上才发现一张清晰的用例图能让产品经理、开发、测试三方迅速对齐“做哪些功能、为谁做”省掉了大量口头解释。类图解决的是“数据如何组织”的问题。做毕业设计时我的题目是一个基于Python的校园二手交易平台初期我直接上手建数据库表结果改了三轮才定稿。后来痛定思痛先用类图把实体、属性和关联关系梳理了一遍——用户、商品、订单、收藏、留言这五个核心类之间的关系一目了然数据库表结构才一次成型。这个过程让我体会到类图画得越清楚后面写代码和建表反而越省力。时序图则解决“一次操作如何流转”的问题。比如“用户下单”这一个场景涉及前端提交、后端校验、库存扣减、订单生成、通知推送等多个环节时序图能把每个环节的调用顺序和消息返回标注得清清楚楚。对测试人员来说时序图也是设计测试用例的天然素材。2. 软件测试的关键以GB/T 39788-2021《系统与软件工程 性能测试方法》为例2.1 性能测试到底在测什么在软件工程的所有环节中测试是最容易被“临时抱佛脚”对待的尤其是性能测试。很多小型团队的做法是项目快上线了才匆匆跑一遍压测脚本看看服务器的CPU和内存占用高不高然后就算“测过了”。但这种做法往往只能应付最简单的检查真正遇到性能瓶颈时根本定位不到问题。这里我重点研究过一项国家标准GB/T 39788-2021《系统与软件工程 性能测试方法》。它从术语定义、测试过程、测试类型、指标要求、结果分析等多个维度把性能测试规范成了一个标准化的工程流程。简单来说性能测试要回答的不只是“快不快”还包括“稳不稳定”“容量有多大”“能撑住多高的并发”“长时间运行会不会劣化”。标准里把性能测试类型划分得很细其中几类我在实践中接触最多负载测试在预期负载范围内逐步增加压力验证系统在不同负载水平下的表现。压力测试持续加压直到系统崩溃或指标严重恶化找出系统的极限在哪里。并发测试模拟多用户同时执行同一操作检测是否存在锁竞争、死锁、共享资源冲突等并发问题。稳定性测试在一定负载下持续运行较长时间如8小时、24小时观察是否存在内存泄漏、连接池耗尽等长期运行问题。这四种测试类型对应着不同的业务问题。你想知道系统能不能支撑大促就做负载测试你想知道系统在极端情况下会不会雪崩就做压力测试你想排查用户抢购时的冲突问题就做并发测试你想确保服务可以长期稳定运行就做稳定性测试。不同类型的测试脚本、监控指标、判定标准各不相同混为一谈最容易出问题。2.2 一项完整的性能测试是怎么跑下来的我曾为一个校内项目做过一次完整的性能测试实践这里把整个流程拆解给大家看。被测系统是一个基于Python Flask开发的课程选课接口业务场景是学生提交选课申请后端校验课程容量后写入数据库。第一步是明确测试目标和指标。这个项目的非功能需求是系统要支持2000名学生同时访问选课接口在500并发下95%的请求响应时间不超过2秒服务器CPU使用率不超过60%。第二步是编写测试脚本。我用的工具是Locust一个Python生态里的开源负载测试工具。它的优势是脚本即代码你可以直接用Python定义用户行为复用项目里的请求逻辑。脚本核心部分大致长这样from locust import HttpUser, task, between class CourseSelectionUser(HttpUser): wait_time between(0.5, 2.0) task def select_course(self): payload { student_id: 2024001, course_id: CS101, semester: 2024-2025-1 } with self.client.post(/api/select_course, jsonpayload, catch_responseTrue) as resp: if resp.elapsed.total_seconds() 2.0: resp.failure(f响应超时: {resp.elapsed.total_seconds():.2f}s) elif resp.status_code ! 200: resp.failure(f请求失败: HTTP {resp.status_code})第三步是执行测试并采集数据。我用--headless模式在命令行运行同时用监控脚本实时记录服务器的CPU、内存、数据库连接数。这里有一个实践心得压测时不能只看负载工具生成的报告一定要把服务器端的指标同步采集下来。因为性能瓶颈可能出现在应用层、数据库层甚至网络层不做端到端的指标对照你根本不知道时间都消耗在哪个环节。第四步是结果分析与调优。首轮压测发现500并发下95%响应时间达到4.6秒明显超标。通过对比服务器监控数据发现数据库连接池最大连接数只有20大量请求在排队等待连接。把连接池上限调整到80并加上索引优化后再跑一轮95%响应时间降到1.2秒CPU使用率也从85%下降到55%达标。这整个流程下来我最深的感受是性能测试不是数据库或运维工程师的专属活它是软件工程中一项需要全员参与的工程活动。开发人员要提供可压测的接口和环境测试人员要设计场景、编写脚本、分析数据甚至还要推动性能调优的落地。3. 课程设计怎么做才不会被“卷死”从选题到答辩的完整路径3.1 选题是课程设计成败的第一道分水岭很多同学做课程设计第一步就栽在选题上。要么选了一个“大而全、假大空”的题目比如“校园智慧管理系统”“在线学习平台”听起来很厉害实际上功能边界模糊得不行最后做出来一堆半成品要么选了一个“小而旧”的题目比如“图书管理系统”“学生成绩管理系统”到处都是雷同代码答辩时根本讲不出亮点。我参加学校课程设计答辩时见过太多这样的案例。印象最深的是一组同学选了“基于Python的社交媒体舆情分析系统”从爬虫到NLP到可视化全都要做结果中期检查时爬虫都还没跑通最后草草用几条模拟数据应付了事。这就是典型的选题失控——没有在选题阶段把范围收敛到一个学期内能完成的粒度。我自己做课程设计时总结出一个选题三原则选“具体场景”而不选“通用平台”。同样是做点餐不要做“食堂点餐系统”而是做“基于微信小程序的食堂预约取餐系统”聚焦预约、取餐码、排队提醒这几个核心流程。选“有技术主线的题目”而不选“纯CRUD的题目”。CRUD增删改查是基本盘但太单薄了。最好能有一条技术主线比如用Python做数据分析、用爬虫采集数据、用机器学习做简单分类哪怕只是极简实现答辩时也有东西可以讲。选“自己能讲清楚”的题目。如果选题时你自己都说不清这个系统解决了什么问题、创新点在哪里那这个题大概率做不出来。3.2 从需求分析到答辩一份课程设计的完整时间表这里提供一份我自己用过的课程设计实操计划整体周期设为10周大家可以按自己的节奏调整。第1周是需求分析与用例建模。这一周不做任何编码只做两件事写需求文档包含功能性需求和非功能性需求画用例图。如果你觉得画图有困难可以在头歌软件工程画图模块多练几次那里的自动判分能逼着你把每个符号画标准。第2周是概要设计与数据库设计。用类图把核心实体梳理清楚再转化成数据库表结构。这一周一定要把ER图实体联系图画完再建表否则后续改表会非常痛苦。第3到第6周是编码实现与单元测试。按照模块划分逐步实现每完成一个模块就跑通基本流程。这里强烈建议用Python写后端因为Python的快速原型能力能大幅压缩开发时间把更多精力留给功能完整度。第7周是集成测试与界面优化。把前端页面、后端接口、数据库连通起来跑完整业务流程修复暴露出来的问题。如果时间允许做一次小规模的性能测试不需要很正式但至少要清楚系统能承受多大的访问压力。第8周是文档整理与代码规范审查。把README、用户手册、技术文档补齐检查代码注释、命名规范、目录结构。很多同学不重视这一环等你答辩时就会发现文档是老师打分的重要依据。第9周是答辩准备。不是背稿子而是准备好演示流程。我建议按“系统功能演示2分钟→ 技术亮点讲解2分钟→ 演示中暴露问题的应对思路1分钟”来排练。特别注意一定要提前录一版演示视频万一现场演示时环境出问题视频就是你的保底救星。第10周是预答辩与修改。邀请同学或学长学姐模拟答辩收集反馈修改PPT和演示流程。4. 软件工程毕业设计论文选题的避坑指南4.1 本科毕业论文选题常见的五个坑本科毕业论文和课程设计最大的区别是它不只要求你“做出东西”还要求你“说出道理”。所以我见过不少课程设计做得挺顺的同学到毕设阶段反而卡壳了。这里总结五个典型的选题坑。第一个坑是把毕设题当成工程项目题来选。比如“基于Vue的某某管理系统”这类题目纯粹是工程实现没有任何研究价值。论文写出来就是“我用了什么框架做了什么功能”评审老师一句“你的创新点是什么”就把你问懵了。正确做法是在题目里加入方法或算法要素例如“基于改进TF-IDF的课程推荐系统设计与实现”这样论文就有得写了。第二个坑是题目范围过大没有边界。比如“基于深度学习的图像识别系统”这个题博士都可以写三年。本科生做的话建议把范围收紧到某个特定领域比如“基于卷积神经网络的花卉图像分类”数据集用现成的公开数据集模型用经典网络加小改进工作量才匹配。第三个坑是不考虑数据可得性。很多选题听起来不错但关键数据根本获取不到。做个舆情分析系统没有微博、新闻的合法数据接口做个推荐系统没有用户行为日志。选标题前先想清楚数据从哪来是否合法量级够不够这三个问题的答案不清晰果断换题。第四个坑是选了和技术栈完全不匹配的题。很多同学用Python做毕设非常熟练结果选了个需要.NET的题目光搭环境就耗掉两周。我强烈建议在选题时先列出自己最熟悉的技术栈然后围绕技术栈再去找题目。比如你熟悉Python那毕设方向可以锁定在“Python数据分析”“Python自动化运维”“Python Web应用”“Python爬虫与可视化”这四个方向里。第五个坑是题目太新文献太少。部分“热门方向”看起来很前沿但相关的中文文献、可参考的同类系统少得可怜你连“别人做了哪些工作”都写不出来。论文要写“国内外研究现状”这一章这个题却几乎没有可引用的文献那这个题基本是死路。稳妥的做法是选择成熟领域里的一个细化分支比如推荐系统领域已经非常成熟但“面向二手交易平台的推荐策略”就没有太多人写过。4.2 一个好题目的结构从“技术方向”到“应用场景”的组合公式选题其实是可以“组合”出来的我管这个方法叫“技术方向 × 应用场景”公式。先列出技术方向加应用场景再挑选匹配项做交叉技术方向Python数据分析、Web开发、爬虫与反爬、机器学习基础算法、推荐系统、自动化脚本。应用场景校园服务、二手交易、学习辅助、办公自动化、个人效率工具、信息聚合。选一个技术方向和一个应用场景交叉基本就能得到一个有边界、有活干、论文有素材的题目。比如“Python × 校园服务”可以组合出“基于Flask的校园失物招领平台”“基于数据分析的校园食堂流量预测”等“爬虫 × 信息聚合”可以组合出“基于Python的课程博客信息聚合系统”等。这种选题方法对本科毕业设计来说非常管用既不会太大也容易把控进度。我还想特别聊一下GB/T 39788-2021这块。如果你是软件工程专业的毕业生在毕设里做性能测试相关的工作非常讨喜因为你可以把国标里的性能测试流程、指标定义、测试报告规范融入论文中让论文的学理性和规范性一下子提升一个档次。比如“基于Locust和GB/T 39788-2021的某某系统性能测试与优化”就是一个不错的题。它既有标准依据、又有实际工具、还有优化前后的对比数据论文怎么写都不缺素材。5. Python在软件工程中的应用从代码规范到自动化测试5.1 写好Python工程代码的实战建议软件工程的思想落到Python开发里最直观的体现就是工程化的代码习惯。很多Python项目一开始都很小代码就几个文件但项目膨胀到几十个文件时缺乏工程规范的问题就会集中爆发。我自己的经验是Python项目至少要做好四件事。第一件事是项目目录结构化。哪怕是一个Flask小项目我也建议按照模块化的目录来组织把核心业务、接口路由、工具函数、配置、测试分开存放。一个常见的结构是这样的project/ ├── app/ │ ├── __init__.py │ ├── api/ # 接口层 │ ├── core/ # 业务核心逻辑 │ ├── models/ # 数据模型 │ ├── utils/ # 工具函数 │ └── config.py # 配置 ├── tests/ # 测试目录 ├── requirements.txt ├── README.md └── run.py第二件事是坚持写类型注解。Python是动态语言但并不意味着不需要类型标注。用上类型注解配合type checker比如mypy能在编码阶段就发现大量潜在的参数类型错误。别小看这个习惯它在项目重构时期的价值极其巨大——有了类型标注改动一个函数签名后你可以立刻在IDE里看到哪些地方需要同步修改。第三件事是使用虚拟环境锁依赖版本。每次开始新项目都建一个虚拟环境所有依赖用pip freeze导出到requirements.txt。这个习惯可以帮你避免“在我电脑上跑得好好的到你那就报错”的经典问题。第四件事是给日志留口子。不要满屏print遇到异常只print不记录以后排查线上问题会非常痛苦。养成使用logging模块的习惯设置好日志级别、输出格式、文件与控制台双通道输出系统出了问题你会感激自己当时的这个决定。5.2 用pytest构建你的自动化测试防线软件工程的教科书里一定会讲软件测试但实操中很多Python项目根本没有测试。这也是为什么我专门把自动化测试拿出来单独聊。在Python生态里pytest是事实上的测试标准它简洁、灵活、生态丰富非常适合给项目搭建自动化测试防线。pytest的核心概念包括测试函数、fixture测试夹具、参数化测试和断言。一个简单的测试文件大概长这样import pytest from app.core.course_service import select_course def test_select_course_success(): result select_course(student_id2024001, course_idCS101) assert result[status] ok def test_select_course_course_full(): with pytest.raises(Exception, match课程容量已满): select_course(student_id2024002, course_idCS101)项目里有了这么一套测试后每次改动代码只需要跑一下pytest就能快速发现功能有没有被改坏。从工程的角度看自动化测试就像安全网让你敢于重构代码、敢于升级依赖而不会被未知的回归问题吓住。我还建议在项目里接入GitHub Actions或者Gitee Go做持续集成CI每次push代码时自动运行测试、检查代码风格。虽然本科生项目未必需要这么重型的流程但这个习惯一旦养成对以后进入真实团队工作帮助非常大。6. 常见问题与排查技巧实录6.1 画用例图/类图时总出错的排查清单在头歌软件工程画图模块里我见过太多同学卡在用例图和类图上其中很大一部分并不是不懂UML而是没理解画图的基本规则。我把常见的错误整理成一份排查清单供大家对照自查用例图中系统边界框是否把用例都框在了内部演员Actor必须在边界框之外。包含关系和扩展关系是否混淆包含关系include表示“一定会执行的公共步骤”扩展关系extend表示“特定条件下才执行的扩展流程”。类图的关联、聚合、组合关系是否使用正确关联表示“有关系”聚合表示“整体与部分弱关系”组合表示“整体与部分强关系”三者不能混淆。多重性标注是否遗漏一个用户“可拥有”多个订单这个1和N的标注必须写清楚。用例的命名是否是动词短语名短语如“用户信息”不是用例“修改用户信息”才是。6.2 课程设计与毕设各阶段卡壳的破局思路做课程设计和毕设最常见的崩溃点是“写了一半想换题”。如果不是题目实在选得太糟糕我一般不建议换题因为换题的成本远远高于补洞的成本。这时不妨回到需求文档把非核心功能砍掉保留最小可行产品MVP。记住一个功能完整、流程闭环的“小系统”远远强过一个欠缺打磨、到处是洞的“大平台”。另一个常见的问题是数据库设计不合理表建好了才发现缺字段或关系错误。我的建议是不要慌先画新的ER图评估表结构需要怎么改。如果项目还处于开发早期直接改数据库结构是最好的选择不要为了省事而强行通过代码逻辑绕开设计缺陷后期维护会让你付出更大代价。还有一个高频问题答辩老师问“你的系统有什么创新点”时大脑一片空白。这种情况往往是因为你在开发过程中只顾实现功能没有记录设计决策。我建议做课程设计或毕设时保持一个开发日志每周记录“这周做了什么、遇到了什么问题、怎么解决的”。答辩前把日志从头翻一遍你会发现大量可以讲的素材。那些在技术选型、异常处理、性能调优上的决策就是你的“创新点”。6.3 项目演示翻车了怎么办我的备用方案演示翻车是常见情况我认识的同学中大概有三分之一在正式演示时都遇到过环境问题、网络问题、数据丢失或莫名其妙的前后端不连通。这里分享几个保命技巧。演示前无论如何都要录一版完整视频涵盖核心功能流程清晰展示每一步操作和结果。万一现场演示崩了直接放视频配合口头讲解老师和评委通常会接受。另外把重要的演示数据本地化不依赖网络。比如数据库连接指向本地SQLite而不是远端的MySQL。还有一个经验是准备一台“演示专用环境”提前装好所有依赖跑通流程只要答辩前再测一遍基本不会出大问题。最后如果现场真的出了问题先承认问题再给出原因分析和修复方案。评委更看重处理问题的能力而不是代码本身有没有bug。7. 一些常用的软件工程工具与资料参考7.1 建模画图工具怎么选建模画图是软件工程实践的“基础设施”工具选得好效率能翻倍。我自己用过好几款UML工具下面按适用场景给出参考。社区版的draw.io或者diagrams.net免费、无需安装、浏览器即可打开支持UML全类型图适合课程设计和毕设画图。StarUML老牌UML工具支持类图、用例图、时序图、活动图等适合需要做较正规建模的场合。ProcessOn国内网页版作图工具模板丰富但免费版有文件数量限制适合快速出图。对于更专业的场景PlantUML和Mermaid这类“代码驱动绘图”方式也值得尝试。用文本描述就能生成序列图、活动图特别适合版本管理但画用例图、类图时对复杂布局的支持稍弱。假如你是为了在头歌这类自动判分平台上做题我的建议是先按平台要求来把时间花在“画对”而不是“画美”上。等真正做项目时再追求布局的美观和可读性。7.2 我常用的软件工程项目辅助资料学软件工程最怕的是“听过很多道理却依然做不好一个项目”因为教材讲的是方法论具体到落地还是得靠工程实践和文档参考。我这里放一份自己在做项目时常常打开的参考资料清单GB/T 39788-2021《系统与软件工程 性能测试方法》做性能测试时最重要的标准依据。软件工程导论相关的经典教材用于查漏补缺基本概念与流程复习考试同样适用。GitHub/gitee上搜索关键词如“course design”“software engineering”“flask project”通常能找到大量学长学姐开源的项目源码。认真读这些代码比单纯看教程学到的多很多。Python官方文档和Flask、pytest、Locust等库的官方文档遇到报错信息优先查官方文档比空搜博客效率高。工具和资料归根到底只是辅助。软件工程这门学科最大的魅力在于它给了你一套从混乱中建立秩序的方法论。不管你是学生还是从业者只要把建模、规范、测试、文档这些习惯内化到日常开发里你写的每一个项目都会比上一个更稳。做软件工程的课程设计和毕业设计本质上是一次“模拟职场”的预演。你在里面养成的每一个习惯踩过的每一个坑都会在未来真正的工作中变成你的职业底子。所以我最后想说的是别把笔记仅仅当作应付考试的背诵资料把它当成自己项目生涯第一批可以复用的“工程资产”。