大学软件工程导论《软件工程概述》教学课件

SOFTWAREENGINEERING软件工程概述：从软件危机到工程化开发软件危机·工程方法·生命周期·过程模型年份2026年课程导览01软件与软件危机认识软件本质，理解危机由来与表现02软件工程的确立掌握学科定义、基本原理与方法学03软件生命周期拆解开发全过程，建立工程化流程认知04软件过程模型对比经典模型，理解方法演进逻辑05发展趋势与展望展望学科前沿，指引学习方向01软件与软件危机软件不是程序，危机源于认知认识软件本质，理解危机由来软件不只是程序软件=程序+数据+文档，三者共同构成完整的软件配置一个常见误区："软件就是程序"，忽视数据与文档的作用程序能够完成预定功能和性能的可执行指令序列数据使程序能够适当地处理信息的数据结构文档开发、使用和维护程序所需要的图文资料常见误区认为软件就是程序，忽视数据与文档的作用，这正是传统开发方式中许多混乱问题的根源。软件是逻辑产品软件不是物理产品，它的特性决定了开发与维护的特殊困难软件是逻辑产品，其特性决定了开发与维护的特殊困难软件的本质特征逻辑实体抽象的智力产品，没有明显的制造过程，成本集中在研发环节不会磨损，但会退化软件不会用坏，却会因运行环境与需求变化而逐渐过时开发与维护的挑战复杂性持续上升程序复杂性随规模增长而急剧攀升维护困难软件是逻辑部件，维护往往意味着修改原有设计开发的组织属性依赖人的协作软件开发是复杂的脑力劳动，需要多人协同完成什么是软件危机软件危机：在计算机软件开发和维护过程中所遇到的一系列严重问题如何开发软件以满足日益增长的需求、如何维护数量不断膨胀的已有软件历史背景3项20世纪60年代硬件性能快速提升，而软件开发能力远远落后规模与复杂度软件规模与复杂度超出人工开发的承载能力危机爆发需求持续增长，危机集中爆发01典型案例IBMOS/360操作系统需求多变，开发目标难以稳定模块耦合复杂，相互牵连难解耦缺陷定位耗时，排错效率低下进度估算几乎无法精确5000人年投入工作量充分暴露困难软件危机的七大表现危机不是抽象概念，而是一系列可以观察到的具体症状软件危机的七大成因，归结为一句话：估不准、不满意、靠不住、难维护、缺文档、成本高、供不应求1对软件开发成本和进度的估计常常很不准确2用户对已完成的软件系统不满意的现象经常发生3软件产品的质量往往靠不住4软件常常是不可维护的5软件通常没有适当的文档资料6软件成本在计算机系统总成本中所占比例逐年上升7软件开发生产率提高的速度，远远跟不上需求增长的速度七词概括估不准·不满意·靠不住·难维护·缺文档·成本高·供不应求危机从何而来危机源于两方面：软件本身的特性，以及不正确的开发与维护方法原因二：开发与维护方法不正确把软件与程序混为一谈，只重编码而忽视数据与文档没有软件生命周期的概念，缺乏统一的方法论与规范指导忽视需求分析的重要性，对用户要求没有完整认识就匆忙编程轻视软件维护，不考虑将来的变化既要技术措施，即更好的方法与工具；又要有必要的组织管理措施。核心是先正确认识软件，承认软件开发是组织良好、管理严密、多人协同的工程项目。02软件工程的确立用工程化手段驯服复杂性从危机到学科，定义与方法学软件工程的诞生与定义软件工程是对软件危机进行工程化应对的历史产物软件工程，是以工程化的系统方法应对软件开发困境的必然产物。标志性事件1968年软件工程学科诞生北大西洋公约组织的计算机科学家召开国际会议讨论软件危机问题，首次正式提出"软件工程"这一名词，标志着软件工程学科的诞生。权威定义IEEE定义·1993年把系统的、规范的、可度量的途径应用于软件的开发、运行和维护过程，也就是把工程应用于软件。张海藩教材表述指导计算机软件开发和维护的一门工程学科，采用工程的概念、原理、技术和方法来开发与维护软件。核心关键词工程区别于作坊式开发的本质系统化规范化可量化工程与科学的分野软件工程不等于计算机科学，前者关注交付，后者关注理论编程关注单个模块或算法的实现，而软件工程关注的是全生命周期的系统构建——贯穿需求分析、架构设计、编码实现、测试验证、部署运维与持续演化的全过程。学科核心对比维度计算机科学软件工程主要关注理论与算法实践与交付核心问题如何正确地计算如何构建有用的系统产出成果新算法与新理论高质量软件产品时间维度追求“对”的答案在约束下做权衡全生命周期系统构建需求分析架构设计编码实现测试验证部署运维持续演化学科核心对比维度计算机科学软件工程主要关注理论与算法实践与交付核心问题如何正确地计算如何构建有用的系统产出成果新算法与新理论高质量软件产品时间维度追求“对”的答案在约束下做权衡全生命周期系统构建需求分析架构设计编码实现测试验证部署运维持续演化三要素与七条原理方法、工具、过程是支撑软件工程的三大支柱方方法技术方法完成软件开发各项任务，回答“怎样做”核心问题如何做怎样做工工具支撑环境为使用方法提供自动或半自动支撑核心问题用什么做支撑过过程任务框架获得高质量软件所需完成的一系列任务核心问题何时做任务框架理七条基本原理1用分阶段的生命周期计划进行严格管理2坚持阶段评审，尽早发现错误3实行严格的产品控制，做好配置管理4采用现代程序设计技术5结果应能清楚地审查6开发小组人员应该少而精7承认不断改进软件工程实践的必要性两种主流方法学方法学是软件生命周期全过程中使用的一整套技术方法的集合，也称范型两种方法学在实践中长期并存，是目前使用最广泛的两大范型传统方法学（结构化范型）3项核心思路把软件生命周期划分为若干阶段，顺序完成每个阶段的任务优点阶段划分清晰，便于分工协作；每阶段严格审查，保证质量与可维护性局限不适用于规模庞大或需求模糊多变的项目；把数据与操作人为分离，增加开发与维护难度面向对象方法学4项核心思路把对象作为融合了数据及在数据上的操作行为的统一软件构件要点对象+类+继承+用消息通信三大特性封装、继承、多态特点对象彼此间仅能通过发送消息互相联系，更贴近现实世界的思维方式本质特性与质量属性软件工程不是编程技巧的堆砌，而是一套关于复杂性的思维方式软件工程的核心工作，就是在四大质量属性之间做出合理的权衡本软件工程的本质特性大型程序传统技术不能简单用于开发大型程序控制复杂性通过分解使问题变成可管理的持续演进交付使用后仍需考虑将来的变化开发效率软件供不应求现象日益严重和谐合作团队协作是开发软件的关键有效支持用户软件必须真正服务于使用者03软件生命周期分阶段管理，全过程可控拆解开发全过程，建立流程认知软件生命周期与阶段划分软件生命周期：软件从定义、开发、使用、维护，直到最终被废弃的全过程划分阶段的意义：化繁为简、责任到人，让全过程有条不紊、质量可控因为什么要划分阶段分工各阶段任务独立且简单，便于不同人员分工协作降繁降低单个阶段任务的复杂程度，简化阶段间的联系保质开发全过程有条不紊，保证质量，尤其提高可维护性划分原则各阶段任务尽可能独立，同一阶段内任务性质尽可能相同，每阶段的开始与结束都有严格标准定义时期开发时期运行维护时期可行性研究与计划需求分析总体设计详细设计实现集成测试确认测试使用和维护定义时期：先想清楚做什么做好软件定义时期的工作，是降低软件成本、提高软件质量的关键01先想清楚做什么，再谈怎么做——定义时期定方向1第一步问题定义确定软件要解决的问题究竟是什么目标不清，后续一切工作都将失去方向2第二步可行性研究决定问题是否值得去解决，是否存在可行的解决办法经济：投入产出是否合理操作：分析用户流程，明确需求间功能关系技术：评估现有技术条件能否支撑3第三步需求分析最关键也最困难回答系统必须做什么，而非如何做成果以《需求规格说明书》提交审核功能需求规定做什么，非功能需求规定做得有多好功能需求描述越细致，开发效率与质量越有保障开发时期：从设计到测试设计回答怎么做，编码把设计变成可执行程序，测试验证是否做对了软件设计总体设计（概要设计）回答系统该如何实现，确定软件体系结构与模块划分详细设计回答怎样具体实现所要求的系统，细化算法、数据结构与接口编写程序设计→可执行代码用程序设计语言把设计转化为可执行的代码。规范统一的编程风格，是保证代码可读与可维护的前提。软件测试通过测试与调试，使软件达到预定要求层次：单元、集成、系统、验收测试工作量约占开发全部工作量40%～50%开发中不可压缩的关键环节维护时期：成本的真正大头软件维护的费用约占总费用的55%～70%，远超开发阶段学科目标提高软件的可维护性，从而减少维护代价设计与编码阶段就要为将来的修改留有余地，而不是等问题暴露后才被动应对维护活动改正性维护诊断并修正运行中发现的软件缺陷缺陷驱动的被动修复维护活动适应性维护为适应外部环境变化（如操作系统、硬件升级）而修改软件环境变化驱动的主动调整维护活动完善性维护根据用户提出的新要求，扩充功能或改善性能需求增长驱动的增量扩展维护活动预防性维护为给未来改进奠定基础，主动修改尚可正常运行的软件前瞻布局驱动的主动优化04软件过程模型没有最好的模型，只有最合适的对比经典模型，理解演进逻辑瀑布模型：经典与局限瀑布模型是最早的线性顺序模型，阶段分明，但假设过于理想1970年罗伊斯提出需求分析系统设计实现测试部署维护分析用户需求并明确系统目标规划架构与模块划分编写代码实现设计验证系统正确性与质量交付并上线运行修复缺陷与持续优化三个主要特点顺序性阶段间具有顺序性和依赖性推迟实现推迟实现的观点，尽可能推迟程序的物理实现文档审查每个阶段必须完成规定的文档，并在阶段结束前完成文档审查，及早发现错误优势与局限优势阶段划分清晰、里程碑明确、文档驱动，便于管理与审查局限它假设需求在项目初期即可完全确定且几乎不会变化——而在现实环境中，这一假设几乎从未成立。传统瀑布模型过于理想化，人在工作过程中不可能不犯错误。瀑布模型用线性顺序换取阶段可控，却以需求冻结为代价，理想化假设使其在现实中难以成立快速原型与增量模型需求说不清就用原型澄清，交付等不及就分批次交付“需求很少能被一次性说清楚，交付也很难一步到位。”快速原型模型核心思路是先快速构建一个可运行的原型，让用户尽早接触系统，从而获知用户真正的需求。在确定需求方面优于瀑布模型，为用户提供了学习手段。一旦需求确定，原型通常将被抛弃，正式版本重新开发。增量模型核心思路是分批次提交产品，先交付一部分功能，再逐步扩充和完善。从部分需求出发，先建立一个不完全的系统。通过测试运行该系统取得经验和信息反馈，加深对软件需求的理解。如此反复，直至软件人员和用户对所设计的软件系统满意为止。螺旋模型：把风险放在中心项目越大、软件越复杂，承担的风险也越大融合特点螺旋模型结合了瀑布模型的系统性与原型模型的迭代性：既保留了阶段化和文档化的严谨，又通过反复迭代渐进式地逼近最终产品。风险是螺旋模型的核心——软件风险普遍存在，项目越大、越复杂，风险也越大，螺旋模型正是对这一现实的正面回应。第一象限目标设定确定本轮迭代的目标、方案与约束条件每轮螺旋的起点，锚定本轮要达成的成果与边界第二象限风险评估分析并评估本轮可能面临的风险，制定应对策略风险是螺旋模型关注的焦点，先识别再化解第三象限开发验证用合适的开发方式实现本轮成果并加以验证将目标与方案落地为可运行、可验证的阶段性成果第四象限计划评审评审本轮结果，规划下一轮迭代在回顾中修正，为下一轮螺旋注入新目标敏捷开发：拥抱变化敏捷不是一种模型，而是一组价值观与原则个体和互动高于流程和工具可工作的软件高于详尽的文档客户合作高于合同谈判响应变化高于遵循计划01实践一极限编程（XP）以技术实践保障质量TDD、结对编程与持续集成02实践二Scrum以短周期持续交付冲刺（Sprint）、每日站会、产品待办列表构成管理框架拥抱变化敏捷强调灵活性、迭代性和客户参与，特别适应需求快速变化的项目环境。此外还有喷泉模型、Rational统一过程模型等，各自适用于不同的项目特征。过程模型横向对比没有最好的模型，只有最适合当前项目特征的模型模型驱动核心适用情形瀑布模型文档与阶段需求明确稳定的项目快速原型用户需求澄清需求模糊、沟通困难增量模型分批交付需要尽早交付部分功能螺旋模型风险分析规模大、风险高的项目敏捷模型客户协作与变化需求快速变化的环境选择的判断依据需求是否稳定、能否在初期说清楚项目规模与所承担的风险高低是否需要尽早交付可运行的部分成果用户能否持续深入地参与开发过程05发展趋势与展望软件定义世界，工程塑造未来展望学科前沿，指引学习方向开发运维与智能化变革软件工程从未停止演进，新范式正在重塑开发方式DevOps融合、云计算弹性与

AI渗透编码，三重力量正重塑软件交付的每个环节。挑战依然存在：异质性·交付压力·信任与安全性·业务与社会持续变革DevOps：开发与运维的融合自动化、协作和持续交付集成团队、流程与工具，缩短开发周期并提高质量CI/CD实践已广泛应用于现代软件团队云计算驱动的变革弹性可扩展基础设施部署与扩缩容方式根本改变交付节奏显著加快AI辅助开发代码生成与智能补全进入日常开发流程改变程序员工作方式人工智能渗透到编码环节现代工程师的技能与角色软件工程方法学不只是课程知识，更是进入行业的基础能力《软件工程导论》作为导论性课程，面向计算机及相关专业本科生，重在建立工程化意识，不需要特别的程序设计经验课程定位：《软件工程导论》是一门导论性课程，面向计算机及相关专业本科生，重在建立工程化意识，并全面了解软件产品研究与开发的各个环节。现代软件工程师的核心能力4项扎实的编程能力与问题解决能力掌握设计原则与系统架构思维熟悉数据结构与算法基础具备团队协作与沟通表达能力软件工程知识服务的岗位7类软件开发人员软件测试工程师软件配置管理人员项目经理软件工程管理人员咨询顾问软件企业高层管理人员从危机到工程：