第五章：软件工程 （5.1软件工程定义--5.2软件需求）

自己复习总结完一轮软件工程后，得出结论，软件工程等于背书，所以把这个分享出来给其他的好兄弟，希望有所帮助。 目录 第一章 软件工程概述 第二章 软件过程模型 第三章 需求分析 第四章 软件工程设计 第五章 软件生产率和工作量度量 第七章 测试技术（25） 第八章 软件测试策略 第九章 软件维护 第十章 软件项目管理 第一章 软件工程概述 软件的定义 软件=程序+数据+文档 软件的特性：软件是逻辑的，不是物理的 软件的双重作用：软件是一种产品，也是开发其他软件产品的工具 .

山大软院软件工程期末复习知识点总结，根据任课老师所给提纲及课件等资料进行整理。 考试范围全覆盖。

第一章 概述 1、软件危机的定义和典型表现 在计算机软件的开发和维护过程中所遇到的一系列严重问题。 典型表现： 1）对软件开发成本和进度的估计常常很不准确； 2）用户对“已完成的”软件系统不满意的现象经常发生； 3）软件产品质量往往靠不住； 4）软件常常是不可维护的； 5）软件通常没有适当的文档资料； 6）软件成本在计算机系统总成本中的所占比例逐年上升； 7）软件开发生产率提高的速度远跟不上计算机应用迅速普及深入的趋势。 2、消除软件危机的途径 推广使用在实践中总结出来的开发软件的成功的技术和方法；应该开发

2023年那会儿是真的卷，国家线才263，结果进复试的人平均分高达343！24年国家线莫名其妙涨了15分，反而进复试的门槛降到了278，那一年上岸的人是不是觉得自己运气爆棚？所以，想考昆工软工的宝子们，千万别被那个低低的B区国家线给骗了。想要稳稳上岸，你的目标分数起码得定在300分左右，这才是有安全感的打法。但最绝的是25年和26年，国家线虽然降回了250左右，看着很温柔对吧？但进复试的平均分却一点没降，稳稳站在289、298的位置。讲真，考研最怕的不是题目难，而是这分数线忽高忽低，心脏不好的真受不了。

等同采用国际标准ISO/IEC 29155-1:2017，便于跨国比较和行业对标，同时与软件工程、软件测量等领域标准体系相互兼容，配合系列其他标准可形成覆盖全流程的标准化管理体系，能够为各相关方开展IT 项目绩效评价、数据度量、基准比对等工作提供统一、规范的执行依据，助力 IT 项目基准度量活动标准化、有序开展。GB/T 41866.1-2022作为整套系列标准的总纲与基础，主要确立IT 项目绩效基准度量的整体框架、通用概念、定义与活动逻辑，为该系列第 2、3、4 部分提供统一术语和顶层规则。

计算机科学与技术和软件工程专业对比指南：计科侧重底层理论与系统研发，课程包含硬件与数学，适合算法、科研及考公；软工聚焦软件开发全周期，课程偏工程实践，就业适配度高且考研难度较低。核心差异在于计科探索"计算机为何工作"，软工钻研"如何做出好软件"。建议根据兴趣与职业规划选择——偏好理论/科研选计科，倾向开发/快速就业选软工，但两者就业重合度高，关键取决于个人技能提升。附赠课程对比表与学习路线图，帮助新生理性决策。

Qoder 知识引擎 2.0 围绕"编译式知识"这个理念，结合软件工程的真实场景，给出了四个层面的答案：怎么凝练知识、怎么让知识活着、能力栈怎么搭、企业怎么真正用起来。

电容触摸技术已经渗透到我们生活的每个角落——从智能手机到智能开关，从工业面板到医疗设备。与传统的机械按键相比，电容触摸具有无磨损、防水防尘、外观简洁等优势。然而，其背后的物理原理和工程实现却鲜为人知。本文将从自电容检测原理出发，深入剖析TTP223专用触摸芯片的工作机制，对比专用IC方案与STM32软件检测方案，并详细讲解灵敏度调节的实战技巧。从STM32F1迁移到F4时，GPIO翻转速度的变化会直接影响软件触摸检测的精度，这也是许多开发者在迁移过程中容易忽视的问题。

开发模型对比：增量模型支持分块交付与需求调整，螺旋模型结合瀑布与原型并强调风险分析； 需求工程：需求开发聚焦需求定义与验证，需求管理负责变更控制与跟踪，基线作为两者桥梁； 设计原则：耦合类型优先级（数据→内容）、SOLID原则（如开闭扩展性、依赖倒置接口编程）； 结构化分析工具：功能（DFD）、行为（STD）、数据（ER）建模，数据字典为核心； 测试方法：静态分析（控制流/数据流）、黑盒测试依据SRS，判定表处理多条件组合，性能测试包括压力与负载测试。

本文介绍了四种常见的软件过程模型：瀑布模型、原型化模型、迭代式开发和可转换模型。瀑布模型采用线性顺序开发，但难以应对需求变更；原型化模型通过构建原型解决需求不确定性问题，分为抛弃型和演化型两种；迭代式开发通过增量或迭代方式逐步交付功能，缩短开发周期；可转换模型利用形式化方法和自动化工具将数学需求转换为可靠系统，适用于高安全性领域。每种模型各有优缺点，开发者需根据项目特点选择合适的方法。

本文针对热设计中客户需求模糊不清的问题，提出了一套系统化的需求挖掘与分析框架。文章首先指出客户通常用"设备太烫"等模糊表述，强调需要通过追问将客户语言转化为热物理语言。然后提出标准化问卷模板（含芯片信息、环境条件等关键问题）和五个场景探针问题，以挖掘隐性需求。最后阐述了将需求转化为可执行规格的四个步骤：制定热设计目标书、热阻预算分解、技术路线初判和风险识别。作者建议根据客户不同阶段（初次接触、方案、样品）采取差异化的需求挖掘深度，强调在方案阶段确认所有关键约束，避免后期返工。全文贯穿实战

本文基于 SSM、Java、MySQL 与微信小程序实现校园表白墙系统，围绕需求分析、功能模块、数据库设计、用户端与管理端实现、测试方案进行项目复盘，适合毕业设计和项目实战参考。

不是所有"用人眼看"的场景都需要上视觉。问题判断标准反例缺陷有明确的视觉特征吗？人眼能稳定区分 OK/NG某些内部裂纹需 X 光，可见光做不到检测速度要求多少？节拍 > 200ms 可考虑，< 50ms 需特殊硬件高速产线每分钟 600 件，普通相机跟不上一致性要求高吗？人工误检率 > 2%，或 24h 不停线偶尔看一眼的场景 ROI 算不过来回顾这些年的项目经历，机器视觉落地的核心挑战从来不是"算法不够好"，而是“系统工程的完备性”——光照变一点行不行？机构歪一点行不行？

原则一：分类先于深潜不要一上来就深挖每个工单的细节。先做粗粒度的全量分类，建立"任务全景图"，再选择需要深入的高价值工单。9 个工单中，只有 1 个（）值得三层递进深潜，其余 8 个在 Layer 1-2 即可完成分类。原则二：子任务为空时，向父任务要信息大量子任务只有标题没有描述——这不是工单写得不好，而是父任务已经承载了需求上下文。AI 在分析时自动获取父任务描述和评论，避免了信息缺失。本次实践中，的描述为空，但父任务+ 评论 + 附件完整覆盖了需求信息。

需求分析是需求到用例全流程的起点。分析质量决定后续测试点提取、用例生成、用例评审的上限——分析环节的信息损耗会在下游被逐级放大，分析错了，后面的工作全是无用功。本文系统拆解需求分析Skill的设计方法：从SKILL.md的能力边界定义、references规则的沉淀方法、隐性需求推断机制、提示词设计策略，到产物持久化方案和下游Skill衔接机制。目标是为设计需求分析Skill提供完整的技术框架和判断方法。