智能软件工程 课件 Ch1-什么是软件工程

智能软件工程课程介绍“软件工程”不只是编程编程解决的是“如何让代码运行起来”的问题，而软件工程解决的是“如何在一群人、很长的时间里，持续、可靠地开发和维护一个复杂软件系统”的问题“软件工程”的定义：一门研究如何运用系统化、规范化、可度量的方法，去经济、高效地开发与维护高质量软件的工程学科。强调：团队协作、遵循标准和流程在有限的约束下实现价值最大化功能运行正常，而且易用、安全、可靠、易于维护和扩展今天，进入了“智能软件工程时代”大模型（LLM）具有很好的理解能力，打破僵局，能够理解业务和需求；LLM具有很好的生成能力，能生成需求文档、生成代码、生成测试用例、生成测试报告等；借助LLM、RAG、Agents，可以解决软件工程中复杂的问题如何能学好软件工程？既然是一门工程学科，就决定了它绝不能仅仅停留在“听讲”和“背诵”上。你不可能通过看书就学会游泳，同样，你也绝不可能只靠听课就能成为一名优秀的软件工程师。因此，学好这门课的核心秘诀，也是我们教材提倡的教学理念，就是三个字——“做中学”。在这门课中，我们会围绕一个真实的、从零到一的软件项目展开。同学们需要组建团队，像一个真正的软件公司一样去运作——需要去分析需求，和“客户”反复沟通，而不是拿到题目就埋头写代码；还要设计软件的架构，画出UML图；要为自己写的代码编写单元测试；要学会开站会、做项目展示、去体验沟通与合作的重要性智能软件工程第1章什么是软件工程1.1软件工程诞生1.2软件工程1.01.3软件工程2.01.4软件工程3.01.1

软件工程诞生《人月神话》描述的软件开发场景程序员们像一群在黑暗中摸索的探险者，没有指南针，没有地图，只能依靠直觉和经验来编写代码。他们面对的是复杂且不断膨胀的软件项目，这些项目常常超出预定的时间和预算，质量问题层出不穷，维护起来更是困难重重“软件工程”的定义软件工程是为了经济地获得能够在实际机器上高效运行的、可靠的软件而建立和应用一系列坚实的软件工程原则”。CMU

SEI：软件工程是以工程的形式应用计算机科学和数学原理，从而经济有效地解决软件问题。IEEE：软件工程是将系统的、规范化的、量化的方法应用于软件的开发、运行和维护之中。软件工程的“工程”属性软件工程学科包含为完成软件需求、设计、构建、测试和维护所需的知识、方法和工具。软件工程不局限在理论之上，更重要在实践上，能够帮助软件组织协调团队、运用有限的资源，遵守已定义的软件工程规范，通过一系列可复用的、有效的方法，在规定的时间内达到预先设定的目标软件工程是一门交叉性的工程学科软件工程的作用域软件工程的多视角观察工程视角：构建可靠软件的方法论核心理念：像建筑工程师一样思考，就像建造摩天大楼需要严格的工程规范一样，软件开发也需要科学的方法论指导，即运用系统化、规范化的方法来构建可靠软件系统。专业思考：工程视角强调的是可预测性、可重复性、可控制性。我们要能够预测项目进度和质量，能够在类似项目中复用成功经验，能够在出现问题时快速定位和解决瀑布模型：像传统建筑，按部就班：需求→设计→编码→测试→部署敏捷模型：像装配式建筑，快速迭代：小步快跑，持续改进工厂模式：标准化对象创建流程，降低系统耦合度质量保证机制：需求/设计/代码评审，需求/测试等可追溯性、单元测试、集成测试、系统测试等管理视角：协调资源实现目标软件工程是在约束条件下协调各种资源，确保项目成功交付的管理实践。这就像指挥一场大型交响乐演出，需要协调各个声部，控制节奏和质量。项目管理：范围管理、干系人管理、进度管理、成本管理、风险管理、质量管理等团队管理：人员配置、沟通协调、绩效管理实际案例：使用敏捷看板进行任务可视化管理、运用燃尽图跟踪项目进度技术视角：工具和手段的选择与应用核心理念：像工匠一样精通工具，从技术视角看，软件工程是选择和运用合适的技术工具来解决具体问题的技术实践。这就像一位匠师，需要精通各种工具，并知道在什么情况下使用什么工具最合适。🔹开发技术层编程语言选择：根据场景选择（Java企业级、PythonAI/数据、Go云原生、JavaScript前端）架构设计：单体架构、微服务架构、Serverless架构的选择与实现数据管理：关系型数据库、NoSQL、缓存、消息队列的综合运用🔹测试技术层自动化测试：减少人工成本，提高测试覆盖率性能测试、安全测试和可靠性测试等方法、技术🔹运维技术层：容器化技术（Docker、K8s）、监控告警、自动化运维（InfrastructureasCode）软件工程方法学软件方法学实际上就是研究在软件工程中可以采用的软件研发和运维的方法、技术和工具，即完成软件构建和维护所需要的有效方法和技术。软件方法学离不开软件过程，如实现软件过程的定义、监控、管理和改进。软件开发环境是方法和工具的结合，或者说是基于合适的软件开发模型建立的、一组相关的软件工具集合，以支持一定的软件开发方法的实施。软件工程方法学：研究软件开发和维护过程中有效的系统方法，确定软件开发的各个阶段，规定每一阶段的活动、产品、验收的步骤和完成准则。软件工程管理学软件工程管理学，通过对软件开发各阶段的活动进行管理，以确保软件开发或维护项目在预定的时间和预算内完成，并满足高质量的要求。计划管理、人员组织、成本管理、进度管理、配置管理、质量管理等。软件工程要素软件工程＝思想＋流程＋方法＋工具＋最佳实践软件工程的基本思想让过程作为指南，而不是“警察”过程等于一组实践，不等于惯例精益概念，精益求精，不断改进简炼的表示方法，使用卡片和指南表来提供实践及相关工件的一致、简单的解释。专业人员是知识的主体，知识对于实施软件开发实践是至关重要的。开放的和可扩展的。体现了软件工程的进化方向过程服务化：从命令式管理转向指导式支持实践导向：重视实际效果而非形式主义持续改进：体现了PDCA循环和精益思维简洁高效：符合认知负荷理论人本主义：认识到人是软件工程的核心开放适应：体现了系统的进化能力AI总结：软件工程的十大基本思想将软件开发视为一项工程活动，运用系统化、科学化的方法质量不是事后检查出来的，而是设计和构建出来的软件是人开发的、为人服务的，人的因素是最关键的没有最好，只有更好；持续改进是永恒的主题变化是常态，要构建能够适应变化的系统和组织，拥抱变化AI总结：软件工程的十大基本思想–续一切为了业务价值，技术也服务于业务，所有活动都应该创造价值通过协作和知识共享，实现团队能力的倍增风险管理：未雨绸缪，识别、评估和控制风险，避免项目失败数据驱动决策，如果不能测量，就无法改进；用数据说话全生命周期思维，从需求诞生到系统退役，全程负责软件工程知识体系演化历史

1999年4月发布了SWEBOK1.0版的技术报告2003年发布了SWEBOKv2

2014年2月20日，IEEEACM发布了SWEBOKv3.0

2024年10月29日SWEBOKv4

软件工程知识体系概况软件工程知识体系-计算基础和工程基础1.2

软件工程1.0版权所有©️仅限于教学使用标志性事件：1968年NATO会议会议输出136页的软件工程论述（SE）第一次提出Software

Engineering术语本次会议标志着进入软件工程1.0

时代上个世纪五、六十年代软件危机四伏对软件开发成本和进度的估计不足，超预算、完成日期一再被推迟的现象屡屡出现不能满足客户需求，用户不满意缺乏质量保证体系，没有成熟的开发流程，产品的质量得不到保证软件不容易被维护，错误难以纠正，新功能难以扩充质量事故经常发生……SE1.0：以瀑布模型为代表受传统建筑工程方法影响比较大，重文档、重流程，典型代表是CMMmodel：aimstoimproveexistingsoftwaredevelopmentprocessesSE1.0一些基本特征产品化：交付符合质量标准的组件、构件和系统过程化、阶段性：一环扣一环，相信良好的过程产生良好的产品责任明确：角色定义清楚，分工明确文档化：强调规范的文档，大量的文档模板计划性强：完整的计划，严格控制变更结构化方法GOTO语句大辩论：创建可读、可维护、分层的代码StructuralDesignPatternsinPython瀑布模型是SE1.0代表，但一直在苦苦挣扎有挣扎就有反思与改进有什么构建就有什么验证用V模型诠释软件过程1.3

软件工程2.0版权所有©️仅限于教学使用软件其实不同于硬件硬件研发与生产软件研发产品是一个物理对象希望批量生产构建/复制成本昂贵构建过程缓慢不容易修改、扩展精确的质量度量……产品是数字、抽象的对象希望每个产品都是个性化的构建/复制成本非常便宜构建过程非常快容易修改、扩展没有精确的质量度量……人人们重新认识软件开发、交付InternetMethodology并深受互联网、开源软件运动、SaaS等影响SE2.0标志性事件：敏捷宣言发布/iso/zhchs/manifesto.html

敏捷可追溯到400多年前：1620年主张合理的归纳应该以大量的事实为基础，而且是一种循序渐进的研究过程。这样的科学方法可以写成假设-实验-评估

然后到了上个世纪80年代：PDCA1986:新产品开发的全新游戏Scrum不断思考、探索与实践敏捷开发原则（1）尽早和持续地交付有价值的软件来满足客户欢迎需求变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势要不断交付可用的软件，周期从几周到几个月不等，且越短越好项目过程中，业务人员与开发人员必须在一起工作要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务无论是团队内还是团队间，最有效的沟通方法是面对面的交谈敏捷开发原则（2）可用的软件是衡量进度的主要指标敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持长期稳定的开发速度对技术的精益求精、对设计的不断完善将提升敏捷性简单——尽最大可能减少不必要的工作——一门艺术最佳的架构、需求和设计出自于自组织的团队团队要定期反省如何能够做到更有效，并相应地调整团队的行为SE2.0开发模式：Agile、CI/CD、DevOps团队协作专注于软件本身拥抱变化以加快产品交付文化是重点，研发和运维融合，形成闭环云原生、平台工程等相继出现持续获得反馈而改进专注于促进自动化的工具CI/CD人是决定的因素软件研发是智力活动，主动性和能动性、潜力等发挥起了关键作用业务和软件复杂性问题的解决主要依赖人的能力和经验，目前没有特别好的技术和工具能够轻松地解决这类问题软件规模不断增大，软件研发一定不是个人的工作，一定是团队的工作流程、技术、管理等问题，归根结底是人的问题客户利益至上今天我们处在一个快节奏的时代，客户的需求变化会加快，对客户的需求能够及时响应需求变化快，“需求不明确”问题更严重，这就要求研发团队更要和客户保持沟通、交流和协作。竞争非常激烈，软件服务需要不断提升客户的满意度目标明确、分清主次交付给用户的是软件，不是文档战略需要落实在交付物上竞争越激烈，越需要聚焦极限编程极限编程（Extremeprogramming，缩写为XP），是敏捷软件开发中最富有成效的几种方法学之一，基本思想是“沟通、简单、反馈、勇气”

XP的12项优秀实践编程实践简单设计、编码标准、结对编程、测试驱动开发、重构团队实践代码集体所有、持续集成、隐喻、每周40小时工作制过程实践现场客户、计划博弈、小型发布（快速发布）行为驱动开发-BDD行为驱动开发（Behavior-DrivenDevelopment,BDD）由DanNorth在2003年提出，是一种软件开发方法论，其核心洞察是：软件开发的真正挑战不在于“如何编码”，而在于“编写什么代码”。它通过结构化的自然语言描述系统行为，将业务需求、测试用例和代码实现统一在同一套语义体系下，从而弥合技术团队与业务团队之间长期存在的“语义鸿沟”，即传统开发模式中存在三大断层：认知断层：业务人员用业务语言描述需求，开发人员用技术语言实现功能，两者缺乏共同语言验证断层：需求文档与测试用例分离，导致"测试与需求不一致"的问题频发演进断层：随着系统迭代，需求文档、测试用例、代码实现三者逐渐背离BDD通过引入"可执行的规格说明"（ExecutableSpecifications）概念，将需求、测试、实现三者统一：业务人员能读懂的需求描述测试人员能执行的验证标准开发人员能实现的技术规约更详细的历史介绍：https://cucumber.io/docs/bdd/history/行为驱动开发-BDD操作人/用户行为可观察的结果Given[Precondition]When[Actor+Action]Then[ObservableResult]测试数据（不同场景)+验收标准=

验收测试验收标准（AcceptanceCriteria）BDD：需求即测试BDD使用Gherkin语言作为标准的行为描述语法，其核心是Given-When-Then三段式结构（声明式、业务语言、独立性）Feature:用户登录作为注册用户我想要登录系统以便访问我的个人信息

Scenario:使用正确凭证登录成功

Given用户"alice@"已经注册

And用户位于登录页面

When用户输入邮箱"alice@"And用户输入密码"SecurePass123"And用户点击"登录"按钮

Then用户应该看到"欢迎回来，Alice"消息

And用户应该被重定向到"个人中心"页面

And系统应该记录登录时间

Scenario:使用错误密码登录失败

Given用户"alice@"已经注册

And用户位于登录页面

When用户输入邮箱"alice@"And用户输入密码"WrongPassword"And用户点击"登录"按钮

Then用户应该看到"邮箱或密码错误"提示

And用户应该仍然停留在登录页面

And登录失败次数应该增加1次BDD生态语言框架特点RubyCucumberBDD鼻祖，生态最成熟，支持40+语言JavaCucumber-JVM,JBehave,SerenityBDD企业级支持，与Spring/Maven深度集成PythonBehave,pytest-bdd简洁易用，与pytest生态兼容JavaScriptCucumber.js,CodeceptJS适配前端测试，支持Puppeteer/PlaywrightC#SpecFlow.NET生态首选，VisualStudio深度集成.NETSpecFlow,LightBDD支持LivingDocumentation生成敏捷流程-Scrum前面已经介绍了1986年发表的文章《新产品开发的全新游戏Scrum》1993年，JeffSutherland首次将这一理念应用于软件开发，1995年KenSchwaber在OOPSLA会议上正式提出Scrum方法论，2001年两人共同编写TheScrumGuideScrum建立在经验主义（Empiricism）之上，认为知识来源于经验，决策基于观察三大支柱：透明、检视（inspection）、适应（Adaptation五大价值观：承诺、勇气、专注、开放、尊重Scrum开发流程

10-30days24hours产品Backlog(确定优先级)SprintBacklogBacklog任务分配可发布的产品阶段性成果DailyScrumMeetingSource:AdaptedfromAgileSoftwareDevelopmentwithScrumbyKenSchwaberandMikeBeedle.Scrum开发流程

1.4

软件工程3.0版权所有©️仅限于教学使用计算机开始全面感知、认知这个世界“正好Transformer把这么多知识压缩在一起，这是它的最大突破”智能的本质革命智能的本质—从逻辑演绎到涌现现象传统AI：智能=逻辑推理现代大模型：智能=模式识别+统计学习+涌现符号操作+逻辑规则模块化架构：感知→推理→规划→执行组合搜索：指数级复杂度，需要启发式剪枝专门设计：大量人工特征工程高维模式匹配：连续向量空间中的几何操作端到端统一：单一Transformer架构处理一切并行推理：多项式时间复杂度涌现能力：规模突破临界点后自发产生新能力LLM理解能力：突破业务理解瓶颈通过人机交互引导，今天的计算机能理解业务，克服了智能软件工程道路上的最大瓶颈AIGC：生成PRD、代码与测试用例等如GitHubCopilotinVS

Code，基本不改变原有编程方式，但效率会提高一倍软件新形态：软件即模型SaaM：Software

as

a

Model预测文字生成图像语音合成视频解读大模型分析/诊断摘要写作翻译回答问题图像搜索标志着SE3.0时代的到来软件开发范式及其转换基于工艺（craft）结构的开发范式（paradigms）、基于市场的、基于产品的开发范式；开源软件范式、分布式开发范式、群智范式软件开发范式的变化快，常常伴随着标志性的事件软件开发新范式：LLM-DevOps模型驱动开发、模型驱动运维MLD