智能软件工程 教案全套（第1-10章）

第1章什么是软件工程基本信息项目内容章节第1章什么是软件工程周次第1周学时4学时（建议）日期待填写教学目标知识目标学完本章后，学生应能够：理解软件工程的诞生背景——“软件危机”的概念及其表现掌握软件工程的多种定义，特别是IEEE给出的标准化定义理解软件工程与其他学科（计算机科学、数学、工程科学、管理科学、应用领域知识）的关系掌握从工程、管理、技术三个视角分析软件工程的方法理解软件工程方法学的内涵及其组成要素掌握软件工程的基本要素：人员、思想、流程、方法、工具、最佳实践理解软件工程1.0（传统软件工程）的基本特征，包括瀑布模型和V模型理解软件工程2.0（敏捷/DevOps）的核心理念和特征了解SWEBOK（软件工程知识体系指南）的发展历程和知识域能力目标能够运用软件工程的基本概念和术语进行专业交流能够分析具体软件开发项目应采用何种工程方法能够比较软件工程1.0与2.0的差异及适用场景素养目标培养学生的工程意识——用系统化、规范化的方法解决问题建立学生对软件工程专业的认同感和职业使命感激发学生对软件工程领域持续学习和探索的兴趣教学重点与难点教学重点软件危机的概念与背景★★：理解为什么需要软件工程软件工程的定义★★：掌握IEEE定义并理解其内涵软件工程与其他学科的关系★：理解软件工程的交叉学科特性软件工程三要素（思想、流程、方法、工具、最佳实践）★★：理解软件工程的完整体系软件工程1.0与2.0的特征对比★★：理解软件工程的演进历程教学难点从多视角理解软件工程：工程视角、管理视角、技术视角的内涵及其相互关系，学生往往难以理解这些视角如何体现在实际开发中软件工程要素之间的相互作用：思想、流程、方法、工具、最佳实践如何相互关联、相互影响V模型的深度理解：V模型中左右两侧的对应关系及质量保证活动的时机教学过程第一课时（2学时）课堂引入（10分钟）引入案例：同学们，你们是否经历过以下场景？手机APP更新后出现了各种bug期待已久的软件项目延期数月甚至数年明明功能很简单，却花费了超乎预期的时间和预算接手别人的代码，发现完全无法理解，维护困难重重这些现象正是软件危机的表现。在20世纪60年代，随着计算机硬件的飞速发展，软件开发却陷入了一场前所未有的危机。历史背景：1968年，北大西洋公约组织（NATO）在德国召开了一次国际会议，会议主题为“软件工程”。这是“软件工程”一词首次被正式提出。这次会议的目标是将软件开发从混乱的状态中解救出来，走向有纪律、有流程的规范化之路。本节课目标告知：学完本节课，你将能够：解释什么是“软件危机”及其表现给出软件工程的标准化定义阐述软件工程与其他学科的关系从工程、管理、技术三个视角分析软件工程1.1软件工程诞生（30分钟）1.1.1软件危机的背景★★软件危机的定义：软件危机是指在计算机软件开发过程中所面临的一系列严重问题，主要表现为：项目延期：软件开发时间远超预期预算超支：成本远远超出最初估算质量低下：软件存在大量缺陷和错误维护困难：后期维护成本高、难度大历史场景描述：正如布鲁克斯（FrederickP.Brooks）在《人月神话》一书中描述的软件开发场景——众多史前巨兽在焦油坑中痛苦地挣扎却无力摆脱场面，它们挣扎得越猛烈，焦油纠缠得就越紧。程序员们像一群在黑暗中摸索的探险者，没有指南针，没有地图，只能依靠直觉和经验来编写代码。教学提示：📌展示图1-1《人月神话》原著封面，引导学生理解软件危机的历史背景。1.1.2软件工程的定义★★最早的定义：F.L.Bauer：软件工程是为了经济地获得能够在实际机器上高效运行的、可靠的软件而建立和应用一系列坚实的软件工程原则。美国软件工程研究所（SEI）的定义：软件工程是以工程的形式应用计算机科学和数学原理，从而经济有效地解决软件问题。IEEE标准化定义（重点掌握）：软件工程是将系统的、规范化的、量化的方法应用于软件的开发、运行和维护之中。通俗解释：软件工程的核心思想是将软件开发视为一项工程活动，运用系统化、规范化和量化的方法来提高软件质量、降低开发成本、缩短交付周期。教学提示：📌引导学生对比三个定义的侧重点：最早定义强调“经济获得”，SEI定义强调“工程形式”，IEEE定义强调“系统化、规范化、量化”。1.1.3软件工程与其他学科的关系★软件工程是一门交叉性学科，与多个学科有着深刻的联系。（1）软件工程与计算机科学的关系：计算机科学为软件工程奠定了理论和技术基础，提供了算法、数据结构、编程语言、操作系统、分布式系统等核心知识。案例：

在开发电商系统时，哈希表结构用于用户信息的快速查找，提升系统性能。智能时代的特点：

在智能时代，人工智能和机器学习技术兴起，软件工程与之深度融合。开发智能客服软件时，需运用机器学习算法实现智能问答功能，同时要应对模型训练数据质量、算法可解释性等新挑战。（2）软件工程与数学的关系：数学为软件工程提供了形式化方法、逻辑推理、概率统计等工具。数理逻辑用于形式化方法，精确描述软件需求，减少歧义并验证软件的正确性（如模型检测）算法的设计和优化直接依赖数学知识，如排序算法的时间复杂度分析智能时代的特点：

在智能时代，数学（如微积分、线性代数、概率论）是构建模型和优化算法的核心。（3）软件工程与工程科学的关系：软件工程借鉴了工程科学的系统化方法和原则，能够系统化地开发复杂的软件系统。案例：

开发物联网软件时，需运用工程科学方法实现软件与硬件的协同优化，提升系统整体性能。（4）软件工程与管理科学的关系：软件工程中的项目管理（如进度、成本、风险管理）直接借鉴了管理科学的理论和工具。管理工具：关键路径法挣值管理风险矩阵智能时代的特点：

在人工智能项目中，管理科学还需应对数据管理、算法伦理等新挑战。（5）软件工程与应用领域业务知识的关系：应用领域业务知识与实践是软件工程的目标导向。软件旨在解决特定领域问题，因此必须深入了解该领域的业务知识。案例：物联网（IoT）软件需要考虑设备间的通信协议医疗软件需遵循医疗行业规范金融科技软件不仅要符合严格监管要求，还要适应快速变化的市场环境教学提示：📌展示图1-2软件工程学科和其他学科的关系示意图，帮助学生建立整体认知。1.2从三个视角看软件工程（20分钟）1.2.1工程视角★★核心观点：工程视角聚焦于软件系统的构建过程，强调运用系统、科学的方法来进行软件开发和维护。软件工程方法学：该视角形成了软件工程方法学，涵盖：开发模型：瀑布模型、敏捷开发模型设计模式：单例模式、工厂模式等技术流程：需求分析→设计→编程→测试关键原则：做好需求分析和定义之后才能进行设计设计时从总体设计、架构设计开始，逐步细化1.2.2管理视角★★核心观点：管理视角着重于对软件项目的整体规划、组织、协调和控制，以确保项目按时、按预算交付高质量的软件产品。软件工程管理学：项目管理：确保项目按照预定计划推进资源管理：保障资源的合理分配和有效利用质量管理：提高软件产品的质量管理工具：甘特图用于项目进度管理成本估算模型用于成本管理1.2.3技术视角★核心观点：技术视角关注于支持软件工程活动的各种技术手段和工具。技术领域：软件开发技术：编程技术、数据结构与算法、软件架构设计、网络通信测试技术：单元测试、集成测试、系统测试运维技术：部署、监控、维护、优化新兴技术：

人工智能、机器学习、云计算等教学提示：📌展示图1-4软件工程的多视角观察，引导学生理解三个视角的相互作用。1.3软件工程方法学（15分钟）1.3.1方法学的定义定义：软件工程方法学实际上是研究软件开发和维护过程中有效的系统方法，确定软件开发的各个阶段，规定每一阶段的活动、产品、验收的步骤和完成准则。三个层次：方法：完成软件构建和维护所需要的有效方法和技术工具：完成相应任务的软件工具过程：软件过程的定义、监控、管理和改进1.3.2软件开发环境定义：软件开发环境是方法和工具的结合，或者说是基于合适的软件开发模型建立的、一组相关的软件工具集合，以支持一定的软件开发方法的实施。课堂小结（5分钟）本节课重点回顾：软件危机的概念及表现软件工程的三种定义（重点：IEEE定义）软件工程与计算机科学、数学、工程科学、管理科学、应用领域知识的关系从工程、管理、技术三个视角理解软件工程软件工程方法学的内涵课后思考：

为什么软件工程需要借鉴传统工程学的方法？它与传统工程学有什么本质区别？第二课时（2学时）课堂引入（5分钟）上节课回顾：上节课我们学习了软件工程的诞生背景、定义以及多视角分析方法。今天我们将深入学习软件工程的基本要素和管理学知识。1.4软件工程管理学（20分钟）1.4.1管理学的重要性软件工程管理学通过对软件开发各阶段的活动进行管理，以确保软件开发或维护项目在预定的时间和预算内完成，并满足高质量的要求。核心任务：

有效地组织人员和资源，采取适当的方法和技术，并利用有效的工具来完成预定的软件开发和维护任务。1.4.2管理学的主要内容（1）计划管理★对任何工程项目，都是计划先行：了解软件项目的需求和工作范围对工作量进行预估完成进度安排和人员调度识别风险（2）成本管理★软件开发成本包括：开发人员的薪酬软硬件设备购买和维护费用开发环境的支撑费用日常运行的其他各项支出重点：

人员成本是最主要的成本之一，重点放在人力资源管理上。（3）人员组织★软件开发是靠软件团队共同完成，需要：定义不同的角色协调团队成员之间的关系促进团队之间的配合（4）软件配置管理★定义：

软件配置管理就是在系统的整个开发、运行和维护过程中定义配置项，建立其基准线，从而可以控制各个配置项的状态和变更，验证配置项的完整性和正确性。（5）质量管理★确定质量方针、目标和职责，并通过质量体系中的质量策划、质量控制、质量保证和质量改进来使其实现。技术评审：对软件产品进行正式审查

软件测试：通过测试发现缺陷

缺陷跟踪：记录和跟踪问题

过程检查和过程改进：持续优化开发过程（6）软件度量★度量可以帮助我们更好地了解产品状况，发现产品的潜在问题，从而进行更有效的管理。1.5软件工程要素（25分钟）1.5.1三要素到六要素的演进★★传统三要素：过去，人们常常强调软件工程的3要素：流程方法工具扩展六要素（重点）：软件工程的基本要素应该由人员、思想、流程、方法、工具、最佳实践组成。软件工程=思想+流程+方法+工具+最佳实践教学提示：📌展示图1-5软件工程的基本要素，帮助学生理解各要素之间的关系。1.5.2各要素详解（1）人员★★软件工程的活动是智力活动，在其过程中，始终要强调以人为本，人的因素是非常重要的因素。个人的能力团队的能力组织的管理水平（2）思想★★软件工程思想是最为重要的内容，实践上，软件工程的流程和方法是建立在思想基础之上的。案例：

软件企业的质量文化就有其思想根源。如果企业全体员工富有零缺陷管理、缺陷预防等理念，即使流程很完善，也难以通过流程控制所能达到的。（3）流程★软件流程可以定义软件整个生命周期所有进行的活动和受到的相应约束。（4）方法★方法为软件开发提供了“如何做”的技术：需求建模方法需求分析方法设计方法编程方法测试方法（5）工具★软件工具为软件工程方法提供了自动的或半自动的实现手段。（6）最佳实践★最佳实践正是在流程和方法的多年应用中提炼出来的经验结晶，适合特定的组织和具体应用场景。1.5.3要素之间的相互作用方法的使用是有一定的局限性，某个具体方法是应用在某个特定的阶段工具是方法的具体实现软件工具又能促进软件开发方法的推广和发展1.6软件工程的基本思想（15分钟）1.6.1与传统工程学的区别即使给软件套上“工程学”，并不意味着软件工程可以照搬其他工程学的成果。案例：

传统的软件工程定义只用很短的时间来完成设计，但却用很长的时间来构建软件，这种方式在其他的工程学方面可能会存在，但在软件开发中，这种方式会带来一系列的问题。核心思想：

在软件工程中，我们要借鉴其他工程学的成果和经验，并研究软件开发自身的问题，适应软件开发需求的新挑战。1.6.2核心统一过程（EssUP）背景：第三代软件工程可能是伊万·雅各布森（IvarJacobson）博士提出的核心统一过程（EssentialUnfiredProcess,EssUP）。八大过程（实践）：📌展示图1-6EssUP的八大过程（实践）迭代开发需求管理组件化架构可视化建模持续质量保证变更管理配置管理项目管理核心原则：让过程作为指南，而不是“警察”过程等于一组实践，不等于惯例精益概念：强调使用实际需要的实践简练的表示方法，使用卡片和指南表专业人员是知识的主体开放的和可扩展的1.7SWEBOK软件工程知识体系（20分钟）1.7.1SWEBOK的发展历程★三个阶段：稻草人阶段（1994—1996年）：产生软件工程本体知识指南的雏形石头人阶段（1998—2001年）：草稿完成、进入试用阶段，1999年发布SWEBOK1.0版铁人阶段（2003—2004年）：SWEBOK第2版发布重要版本：SWEBOKv3.0（2014年）：新增4个基础知识域，扩展到15个知识域SWEBOKv4（2024年）：新增3个知识领域，更加强调跨学科协作和工程化思维1.7.2SWEBOKv4新增知识领域★（1）软件安全性（SoftwareSecurity）★专注于软件开发中的安全性问题：威胁建模安全设计原则安全测试（2）人工智能与机器学习（AI/MLinSoftwareEngineering）★★智能系统开发数据驱动的软件工程AI驱动的代码生成、错误检测和测试优化工具（3）云计算与分布式系统（CloudComputingandDistributedSystems）★云计算架构微服务容器化技术1.7.312个软件工程实践知识域★软件需求：需求获取、分析、描述、确认、跟踪、验证、变更、控制软件设计：体系结构、组件、接口、用户界面设计软件构造：算法实现、编码、单元测试、集成软件测试：单元测试、集成测试、系统测试、自动化测试软件维护：适应性修改、修正性修改、增强性修改软件配置管理：配置项标识、变更控制、状态审核软件工程管理：项目规划、进度控制、成本管理软件工程过程：过程定义、评估、度量、改进软件工程模型和方法：瀑布模型、敏捷模型等软件质量：质量管理流程、质量工具软件工程职业实践：专业、责任、道德软件工程经济学：技术决策与经济分析教学提示：📌展示图1-3软件工程学科领域范围示意图，帮助学生理解软件工程知识体系的广度。1.8软件工程1.0（10分钟）1.8.1软件工程1.0的定义★★软件工程1.0，即之前常说的“传统软件工程”，深受建筑工程、水利工程等的影响。九大特征：产品化：把软件当作传统工业的产品结构化：以架构设计为中心，进行结构化分析、设计、编程过程决定结果：流程质量决定产品质量重视质量管理：引入传统的质量管理体系阶段性明确：需求评审→设计评审→编程→测试责任明确：角色定义清晰，分工细致文档规范化：定义了大量的文档模板计划性强：具有完整的计划并严格控制变更注重项目管理：风险预防、里程碑控制、关键路径法1.8.2瀑布模型★★定义：瀑布模型将软件过程分为5个阶段，从需求分析、设计、编程、测试直至维护。特征：各个阶段以串行关系相连，下一阶段完全依赖于上一阶段的工作成果过高地估计了软件项目参与人员的能力测试工作发生在编程之后不足：后期的变化、迭代、改动困难不支持重用没有一个联系各个阶段的统一模型1.8.3V模型★★定义：V模型是在快速应用开发（RAD）模型基础上演变而来，由于将整个开发过程构造成一个V字形而得名。核心思想：V模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来。水平对应关系：需求分析↔验收测试系统设计↔系统测试详细设计↔集成测试编程↔单元测试教学提示：📌展示图1-9模型诠释软件过程，帮助学生理解V模型的对应关系。1.9软件工程2.0（15分钟）1.9.1软件工程2.0的定义★★软件工程2.0是以敏捷/DevOps开发范式为核心的软件工程，深受互联网、开源软件运动的影响，并最终建立在SaaS、云计算之上的移动互联时代。1.9.2敏捷开发宣言★★2001年，17位软件开发轻量型流派掌门人联合签署了敏捷软件开发宣言：个体和互动高于流程和工具

工作的软件高于详尽的文档

客户合作高于合同谈判

响应变化高于遵循计划1.9.3软件工程2.0的九大特征★★SaaS（软件即服务）：软件更多以一种服务存在强调价值交付：只做对用户有价值的事情，加速价值流的流动以人为本：个体与协作胜于流程和工具自我管理的团队：像一家初创公司一样运营持续性：持续构建、持续集成、持续测试、持续交付开发、测试和运维的融合：DevOps推崇全栈工程师真正把用户放在第一位：注重用户体验知识管理：强调授权给从事具体工作的研发人员更有乐趣：让软件研发工作更有趣、更健康1.9.4敏捷开发的历史追溯★PDCA循环的起源：1620年：培根发表《新工具》，提出“假设—实验—评估”20世纪20-50年代：休哈特提出“规范—生产—检验”三步过程戴明环：PDCA（Plan-Do-Check-Action）循环Scrum的起源：1986年：竹知弘武和野中郁次郎发表《一种崭新的新产品开发游戏》1994年：JamesO.Coplien提出每日简短会议1995年：JeffSutherland和KenSchwaber正式推出Scrum课堂小结（5分钟）本节课重点回顾：软件工程管理学的主要内容（计划、成本、人员、配置、质量、度量）软件工程六要素：人员、思想、流程、方法、工具、最佳实践软件工程1.0的九大特征及瀑布模型、V模型软件工程2.0的九大特征及敏捷开发宣言SWEBOK的发展历程和知识域课后思考：

软件工程1.0和2.0各适用于什么场景？为什么会出现从1.0到2.0的演进？思政融入点1.工程意识与职业素养融入点：

在讲解软件工程定义时，强调软件工程师需要具备工程意识，用系统化、规范化的方法解决问题。案例：

通过“软件危机”的历史背景，让学生认识到缺乏工程化方法的危害，建立职业责任感。2.质量意识与工匠精神融入点：

在讲解软件工程要素时，强调“思想”的重要性，特别是零缺陷管理、缺陷预防等理念。案例：

通过软件企业的质量文化案例，培养学生追求卓越、精益求精的工匠精神。3.团队协作与沟通能力融入点：

在讲解软件工程管理学时，强调人员组织和团队协作的重要性。案例：

通过敏捷开发中“自组织团队”的案例，培养学生的团队协作意识和沟通能力。4.持续学习与创新意识融入点：

在讲解软件工程演进历史（1.0→2.0→3.0）时，强调技术发展需要持续学习和创新。案例：

通过SWEBOKv4新增AI/ML、云计算等知识域的例子，引导学生认识到技术更新换代的必然性，培养终身学习的意识。5.社会责任与伦理意识融入点：

在讲解SWEBOKv4时，强调软件工程师职业伦理和社会责任。案例：

通过数据伦理、隐私保护、人工智能伦理等内容的介绍，培养学生的社会责任意识。教学评价课堂表现评价（20%）评价项目评价标准权重出勤情况按时出勤，认真听讲10%课堂参与积极回答问题，参与讨论5%思维活跃度能够提出有价值的问题和观点5%知识掌握评价（40%）评价方式评价内容权重课堂测验软件工程基本概念、定义15%小组讨论软件工程与其他学科的关系10%章节总结撰写本章知识点总结15%能力提升评价（40%）评价方式评价内容权重案例分析分析实际软件开发项目的工程方法20%专题报告软件工程1.0与2.0对比分析20%板书设计第一课时板书┌─────────────────────────────────────────────────────────────┐

│第1章什么是软件工程│

├─────────────────────────────────────────────────────────────┤

││

│1.1软件工程诞生│

│┌─────────────────────────────────────────────────────┐│

││软件危机：项目延期、预算超支、质量低下、维护困难││

││││

││软件工程定义（IEEE）：││

││将系统的、规范化的、量化的方法应用于软件的││

││开发、运行和维护之中││

│└─────────────────────────────────────────────────────┘│

││

│1.2软件工程与其他学科的关系│

│┌─────────────────────────────────────────────────────┐│

││计算机科学←→软件工程←→数学││

││↓↓││

││工程科学管理科学││

││↓↓││

││└────→应用领域业务知识←────┘││

│└─────────────────────────────────────────────────────┘│

││

│1.3三个视角看软件工程│

│┌─────────────────────────────────────────────────────┐│

││工程视角→软件工程方法学（瀑布模型、敏捷模型）││

││管理视角→软件工程管理学（项目、资源、质量管理）││

││技术视角→开发技术、测试技术、运维技术││

│└─────────────────────────────────────────────────────┘│

││

└─────────────────────────────────────────────────────────────┘第二课时板书┌─────────────────────────────────────────────────────────────┐

│第1章什么是软件工程（续）│

├─────────────────────────────────────────────────────────────┤

││

│1.4软件工程要素│

│┌─────────────────────────────────────────────────────┐│

││软件工程=思想+流程+方法+工具+最佳实践││

││↑↑↑↑││

││人员←────────────────→最佳实践││

││（相互作用）││

│└─────────────────────────────────────────────────────┘│

││

│1.5软件工程1.0vs软件工程2.0│

│┌────────────────────┬────────────────────────────────┐│

││软件工程1.0│软件工程2.0││

││·瀑布模型│·敏捷开发││

││·阶段明确│·持续交付││

││·文档规范│·以人为本││

││·计划性强│·响应变化││

││·过程决定结果│·价值交付││

│└────────────────────┴────────────────────────────────┘│

││

│1.6SWEBOK知识体系│

│┌─────────────────────────────────────────────────────┐│

││v4新增：软件安全、AI/ML、云计算与分布式系统││

││12个实践知识域：需求、设计、构造、测试、维护、││

││配置管理、管理、过程、模型方法、││

││质量、职业实践、经济学││

│└─────────────────────────────────────────────────────┘│

││

└─────────────────────────────────────────────────────────────┘教学反思教学效果自评评估项目评价标准自我评分（1-5）内容完整性所有知识点是否都已覆盖重点突出性重点内容是否讲解清晰难点突破难点内容是否有效突破时间控制是否在规定时间内完成教学学生参与学生是否积极响应互动思政融入思政元素是否自然融入常见问题与改进建议问题1：学生对“软件危机”的历史背景理解不深改进建议：补充更多20世纪60年代软件开发的历史案例让学生课前阅读《人月神话》相关章节问题2：三个视角的区分学生容易混淆改进建议：使用具体项目案例分别从三个视角进行分析制作对比表格帮助学生理解问题3：V模型的理解有难度改进建议：使用实际软件开发项目的例子展示V模型的对应关系通过图示动画展示左右两侧的对应关系问题4：软件工程1.0与2.0的适用场景不明确改进建议：补充更多实际案例说明不同场景下的方法选择组织小组讨论让学生分析具体项目应该采用哪种方法后续改进方向增加更多实际案例，特别是中国本土的软件开发案例制作微课视频帮助学生课前预习和课后复习设计更丰富的课堂互动环节，提高学生参与度完善课程网站资源，提供更多参考资料课后练习与作业基础概念题（5题）什么是软件危机？软件危机的主要表现有哪些？请给出IEEE对软件工程的标准定义，并解释其内涵。软件工程与计算机科学、数学、管理科学之间是什么关系？软件工程的基本要素有哪些？请解释各要素的作用。请简述SWEBOK的发展历程及其v4版本新增的知识域。理解应用题（3题）请从工程视角、管理视角、技术视角三个角度分析一个实际的软件开发项目。请比较软件工程1.0与2.0的异同，并说明各适用于什么场景。V模型中，左边的设计和右边的测试是如何对应的？请绘图说明。拓展思考题（2题）为什么说软件工程是一门交叉性学科？请结合你的专业背景思考。你认为未来软件工程将会向什么方向发展？请查阅资料说明。参考答案要点软件危机：指软件开发过程中面临的严重问题，表现为项目延期、预算超支、质量低下、维护困难等。IEEE定义：软件工程是将系统的、规范化的、量化的方法应用于软件的开发、运行和维护之中。强调系统化、规范化和量化三个关键特征。与其他学科的关系：计算机科学：提供理论和技术基础数学：提供形式化方法和逻辑推理工具工程科学：提供系统化方法和工程原则管理科学：提供项目管理理论和工具应用领域知识：提供业务背景和需求基本要素：人员、思想、流程、方法、工具、最佳实践。其中思想是核心，流程是基础，方法是技术保障，工具是手段，最佳实践是经验结晶。SWEBOK发展：经历稻草人、石头人、铁人三个阶段；v4版本新增软件安全、AI/ML、云计算与分布式系统三个知识域。三视角分析：工程视角关注如何构建系统；管理视角关注如何组织协调；技术视角关注使用什么工具和方法。1.0与2.0对比：1.0强调流程、文档、计划性，适合需求稳定的大型项目；2.0强调价值、响应变化、持续交付，适合需求变化快的项目。V模型对应：需求分析↔验收测试；系统设计↔系统测试；详细设计↔集成测试；编程↔单元测试。教学日志日期记录内容学生反馈：教学效果：改进建议：教案制作者：[教师姓名]

审核人：[审核人姓名]

日期：[日期]第2章今天我们是如何开发软件的##基本信息项目内容章节第2章今天我们是如何开发软件的周次第2-4周（建议3学时）学时3学时（每学时45分钟）课程类型理论课（知识讲授+案例分析+课堂讨论）授课教师待填写授课对象软件工程专业本科二年级学生教学目标知识目标学完本章后，学生应能够：理解产品思维、项目思维和工程思维的定义及其核心特征区分三种思维方式的差异，理解它们在软件研发中的不同作用掌握软件工程中六大主要活动（产品定义、需求定义、设计、编程、测试、运维）的内容和流程了解产品愿景板、需求工程等工具的使用场景和方法能力目标应用：能够运用产品思维分析用户需求，构建用户画像分析：能够从项目思维角度评估软件项目的进度、成本、质量平衡应用：能够运用工程思维分析软件系统的架构和设计问题综合：能够将三种思维应用于软件项目的整体规划中素养目标培养学生的用户中心思维和同理心增强学生的系统性思维和工程意识树立正确的项目管理观念和风险管理意识理解软件工程伦理和社会责任教学重点与难点教学重点产品思维的核心概念与方法论*：理解产品思维如何关注用户需求、市场分析和产品价值项目管理的平衡思维**：掌握进度、成本、质量三者之间的平衡关系工程思维的系统性与分析性*：理解工程思维如何通过技术手段解决问题软件工程主要活动的完整流程*：掌握从产品定义到运维的完整软件开发流程教学难点三种思维的融合应用：如何在不同场景下灵活运用产品思维、项目思维和工程思维需求工程的系统性：需求获取、需求分析、需求建模、需求描述、需求评审与确认、需求管理的完整过程理解工程思维的抽象性：工程思维作为理性思维在软件工程中的具体体现和应用教学过程第一学时：三种基本思维的理解与区分课堂引入（8分钟）引入案例：井盖为什么是圆的？各位同学，今天我们从一个有趣的问题开始——井盖为什么是圆的？这是微软公司曾经的经典面试题。如果你们去应聘产品经理，你会怎么回答？可能你会说：因为圆形的井盖好看、不容易掉下去、方便施工人员移动。但如果你应聘的是软件研发工程师，仅仅这样回答是不够的。让我们从软件工程的角度来思考这个问题。圆形井盖主要是因为大多数井口是圆形的，而圆形受力最均匀，最能承受周围土地的压力，这是安全因素决定的。从工程角度看，下水道采用圆形不仅受力好，也适合排污和清理，圆形自然而然成为下水道主要的形状。这个例子告诉我们什么呢？它揭示了软件研发中三种不同的思维方式——产品思维、项目思维和工程思维。本节课目标告知：

学完本节课，你将能够：理解产品思维、项目思维、工程思维的定义和核心特征区分三种思维方式的差异运用不同的思维方式思考软件工程问题讲授环节2.1.1产品思维（15分钟）产品思维的定义：产品思维是一种以用户为中心、关注产品价值和市场需求的思维方式。它要求开发者从用户的角度出发，理解用户的真实需求，创造出满足用户痛点的产品。产品思维的核心要点：产品思维首先要回答以下五个关键问题：解决什么问题？真的要解决这种问题吗？为谁解决的？可以进一步细分市场吗？用户画像是什么？有多少人需要？市场规模有多大？产品具体价值（流量、转化率、现金流等）多大？之前人们是如何解决的？我们的解决方案有优势吗？同理心在产品思维中的重要性：产品思维就是用户思维，体现在从用户角度想问题，扮演用户角色、设身处地为用户着想。同理心泛指心理换位、将心比心，体现在四个方面：观点采择：自发地理解他人内在感受的倾向幻想：想象自己是一个虚构的角色时产生的想法和行为关怀：同情和关心痛苦的人个人痛苦感：在紧张不安的状态下感受到的焦虑和苦恼产品思维的等级：A-1、A0级：基本的用户视角A+1级：能够站在对方的角度考虑问题，想对方之所想，急对方之所急A+2级：将心比心，设身处地地去感受和体谅别人，具有优秀的洞察力与心理分析能力产品思维的特征：联结主义学习思维：产品联结客观世界、过去与将来，联结当前用户及其周围的潜在用户持续迭代演化的动态思维：关注用户反馈，积极获取用户反馈，和用户保持交流创新或创造思维、跨界思维：勇于探索、敢于试错、打破平衡📌教学提示：此处可以展示图2-1产品思维、项目思维和工程思维之间的联系，帮助学生理解三种思维的关系。案例分析：天气预报App的产品思维开发一个“天气预报”移动应用软件，产品思维会关注：解决什么问题：用户随时随地想了解天气情况为谁解决：户外运动爱好者、智能手机重度使用者、商务工作者有多少人需要：几乎每个手机用户都需要之前人们如何解决：看电视天气预报，但时间太宽泛、地点太少我们的优势：可以精确到某个镇、某个区、某个景点，未来1-2小时是否下雨2.1.2项目思维（12分钟）项目思维的定义：项目思维是一种关注项目目标实现、重视计划与平衡的思维方式。它强调在有限资源、时间和预算条件下，按时、按质、按量完成项目交付。项目思维的核心理念：项目思维把任何活动看作有始有终的、明确的时间段过程。在这段时间内要完成特定的目标——交付物及其质量要求，需要预算、资源（人力、物力等），但同时预算、资源、时间都是有限的，构成项目的约束条件。项目管理的平衡艺术：项目思维是一种平衡性思维，具有艺术性，要在多个目标、约束条件之间达到相对最佳的平衡。一般情况下：保持质量不受影响，就在任务、进度和成本之间平衡加快进度就需要增加研发人员（增大成本）或砍掉一个功能特性（减少要做的任务）有时为了赶进度，交付的功能特性一个也不能少，只好牺牲一些质量项目思维的特征：计划思维：一开始就假设，由假定到推理，事先周密的计划来规划各项活动风险防范思维：风险无处不在，需求会经常变更、工作量估算不准确、业务理解有偏差、单元测试不足等都是潜在风险管理思维：注重沟通与管理，不仅是团队内部的沟通协作，还注重项目利益相关者的沟通📌教学提示：此处可以展示图2-2项目管理的平衡思维和图2-3不同优先级的风险划分示意图，帮助学生直观理解项目管理中的平衡和风险管理。项目思维的代表性工具：甘特图：项目进度计划风险矩阵：风险优先级评估沟通管理计划：干系人沟通策略2.1.3工程思维（18分钟）工程思维的定义：工程思维是一种理性思维，喜欢从方法、技术角度去思考问题，从“数据交互”角度去思考，从数据流、业务规则、业务逻辑、异常条件、异常数据等角度去思考问题。工程思维与产品思维的区别：产品思维偏于感性，喜欢从人性、社会性角度去思考问题，从“人机交互”角度去思考工程思维属于理性思维，喜欢从方法、技术角度去思考问题，从“数据交互”角度去思考工程思维的思考示例：以用户登录系统为例，工程思维会思考：用户不登录能看到哪些数据？系统登录时需要用户输入什么数据？对用户名和口令建立哪些验证规则（字母大小写是否敏感、口令长度、含哪几类字符等）？口令或用户名输错了给予什么提示？口令输错多少次，账户被锁定？用户可能会输入哪些特殊字符？黑客有没有可能暴力破解口令？黑客能否在字符串类型域中输入script脚本？工程思维的主要特征：技术思维：通过技术手段、通过工具来解决问题，追求高性能和高可靠性抽象思维：将复杂的工程问题进行简化，抓住问题的主要特征，构建抽象模型上下文驱动思维：根据不同的上下文（用户数量、业务领域、团队技术能力等）选择不同的工程解决方案分析性思维、批判性思维：强调假定、推理过程，在评审需求、评审设计时具备批判性思维系统性思维：把软件产品看成是一个系统，强调系统性解决问题工程思维的代表性工具：因果图（鱼骨图）：分析问题原因故障树分析：系统故障分析FMEA：失效模式与影响分析📌教学提示：此处可以展示图2-4软件系统架构C4模型示意图，帮助学生理解工程思维如何建立系统架构模型。三种思维的对比总结（7分钟）课堂互动：请同学们思考一下，在开发一个微信小程序时：产品思维会关注什么？（用户为什么用微信、用户痛点是什么、如何提升用户体验）项目思维会关注什么？（进度安排、成本控制、团队协作）工程思维会关注什么？（技术架构选型、数据安全、性能优化）对比表格讲解：维度产品思维项目思维工程思维目标做出正确的产品按时按质按量完成交付解决问题、价值定向思维导向做正确的事（价值、用户、市场）正确地做事（交付物、任务、规范）做正确的事并正确地做事（质量与效率、规范）主要思维方式创造性思维前瞻性思维分析性思维（含批判性思维、逻辑思维）思维取向感性、具体感性和理性相结合理性、抽象、严谨技术性不强中等程度，偏管理很强系统性一般强很强📌互动建议：可以让学生分组讨论，针对一个具体的软件产品（如抖音、淘宝等），分析三种思维如何综合应用。第二学时：软件工程主要活动课堂引入（5分钟）问题导入：同学们，上一节课我们学习了软件研发的三种基本思维。那么，一个软件究竟是如何开发出来的？开发一个软件需要经历哪些主要活动呢？今天我们学习软件工程中的六大主要活动：产品定义、需求定义、设计、编程、测试、运维。讲授环节2.2.1产品定义（10分钟）产品定义的概念：产品定义是要回答“为什么要开发这个软件？”这个问题，明确开发软件的目的、价值和目标用户。产品定义要明确的问题：这个产品要解决什么问题、不解决什么问题？这个问题值得解决吗？有价值吗？价值究竟多大？市场上有类似的产品吗？别人为什么要用我们的产品？产品的用户是谁（给谁用）？基于这个产品，给我们带来怎样的经济效益？产品愿景板工具：产品愿景板（ProductVisionBoard）是一个很好的产品定义工具，包含五个部分：愿景陈述：用一句话描述产品愿景，如“用户能够随时随地知晓天气与空气”目标群体：定位哪一类用户，如户外活动爱好者、智能手机重度使用者需求：要解决用户哪些问题？用户从中得到哪些收益？产品：这个产品需要实现哪几个最重要的功能特性？商业价值：能给公司带来多大的商业价值？即盈利模式、投入产出分析等📌教学提示：此处可以展示图2-6产品愿景板示意图，让学生更直观地理解产品定义的方法。2.2.2需求定义（15分钟）需求工程的概念：需求工程是软件工程中非常重要的环节，包括需求获取、需求分析、需求建模、需求描述、需求评审与确认、需求管理等一系列活动。需求工程的六个主要活动：需求获取：通过访谈、问卷、观察等方法收集用户需求需求分析：对获取的需求进行归纳、整理和分析，识别需求的本质和隐含需求需求建模：通过可视化方式（业务流程图、用例图、活动图等）定义软件需求需求描述：以清晰、准确、规范的方式形成需求文档需求评审与确认：开发方和客户方共同对需求文档进行评审需求管理：跟踪需求状态、对需求变更进行控制和管理📌教学提示：此处可以展示图2-7需求工程各项活动之间关系示意图，帮助学生理解需求工程的完整流程。需求定义的关键概念：基线：经过正式评审和认可的一组软件配置项，作为下一步开发工作的基础配置项：逻辑上组成软件系统的各个部分或单元及其特定的信息描述需求分析的具体工作：定义需求的优先级：确定哪些功能最重要识别冲突和歧义：当多个用户对同一功能有不同的需求时进行分析和协调建立需求模型：如绘制数据流图、实体关系图等2.2.3设计（12分钟）软件设计的概念：软件设计是根据需求分析的结果，考虑如何在逻辑上、程序上去实现所定义的产品功能、特性等。软件设计的两个层次：概要设计（高层次设计）：软件体系架构设计系统部署设计数据结构设计接口设计详细设计：模块内部细节算法设计数据结构设计用户界面设计数据库存储过程设计软件体系架构设计：软件体系架构是一个抽象的系统规范，包含一定形式的设计模式和结构化元素。软件体系架构可以从不同角度来描述：概念抽象角度：采用的设计模式、软件开发框架和技术软件构建角度：功能分解与层次结构系统运行角度：系统运行环境的变化程序代码角度：包、类和库函数的组织📌教学提示：此处可以展示图2-8从不同角度看软件体系结构设计的内容，帮助学生理解软件设计的不同视角。详细设计的内容：详细设计就是考虑在技术上如何实现已设计好的体系架构，主要任务是为每个模块确定所采用的算法、程序流程和数据结构等。2.2.4编程（8分钟）编程的概念：编程是我们常说的“写代码”，采用一种或多种具体的程序语言进行编码，将设计转化为计算机语言描述的程序。编程涉及的主要活动：调试（Debug）：排除程序故障，设置断言语句判断问题所在，或设置断点跟踪程序运行源代码库管理：代码检入/检出、版本分支、版本合并，采用Git、Subversion等工具版本构建：从源代码构建目标软件包，涉及依赖项分析、依赖软件包安装、构建配置项设定单元测试：在编码阶段针对每个程序单元进行的测试编程语言的演变：早期：汇编语言现在：Java、C/C++、Python、PHP、Ruby、Go等高级语言解释性编程语言：可以直接在开发环境上运行，无须编译、连接编程中的优秀实践：测试驱动开发（TDD）防御式编程契约式编程第三学时：案例实践与总结案例分析：一个完整软件项目的开发流程（20分钟）案例背景：假设我们要开发一个“校园外卖配送平台”，包括用户端App、配送员端App和商家端Web后台。运用产品思维分析：目标用户：大学生、教职工、校园周边商家用户痛点：学生：食堂排队时间长、想吃什么可以提前下单商家：增加销售渠道、减少人工成本配送员：灵活的工作时间、额外收入市场规模：一所2万人高校，假设30%用户使用，月订单量约6万单竞争优势：针对校园场景优化，更快的配送速度、更低的配送费运用项目思维分析：项目目标：在3个月内完成MVP（最小可行产品）版本开发资源约束：团队5人（2前端、2后端、1产品经理兼测试）进度安排：第1-2周：产品定义和需求分析第3-6周：系统设计和开发第7-8周：测试和部署第9-12周：迭代优化风险管理：需求变更风险、技术难点风险、人员流动风险运用工程思维分析：系统架构：微服务架构，用户服务、订单服务、配送服务、支付服务技术选型：后端SpringBoot+MySQL，前端Vue.js，移动端Flutter性能要求：支持1000并发请求，响应时间<200ms安全设计：用户密码加密存储、支付接口HTTPS加密、敏感数据脱敏📌互动建议：让学生分组讨论，针对这个案例，分别从产品思维、项目思维、工程思维角度提出2-3个关键问题。课堂总结（10分钟）本章知识回顾：三种基本思维：产品思维：关注用户需求、市场价值，做正确的事项目思维：关注交付、进度、成本，平衡的艺术工程思维：关注技术实现，系统性解决问题软件工程主要活动：产品定义：回答“为什么开发”需求定义：回答“做什么”设计：回答“如何做”编程：实现设计测试：验证质量运维：部署和维护关键要点强化：产品思维是软件开发的起点，决定了产品方向项目思维是确保项目按时按质完成的保障工程思维是实现技术方案的核心能力三种思维相互关联、相互支撑，缺一不可📌教学提示：此处可以展示表2-1产品思维、项目思维和工程思维之间的区别，对比三种思维方式的差异。思政融入点1.用户为中心的服务意识在讲授产品思维时，强调软件开发的根本目的是为用户解决问题、创造价值。引导学生树立“用户至上”的服务意识，在今后的软件产品开发中，始终把用户体验放在首位。这与当前国家倡导的“以人民为中心”的发展理念相呼应。2.工程伦理与社会责任在讲授工程思维时，强调软件工程师不仅要有技术能力，更要有社会责任意识。例如，在设计用户登录系统时考虑用户隐私保护，在开发金融软件时考虑资金安全等。引导学生思考技术应用的社会影响，培养工程伦理意识。3.团队协作与沟通能力在讲授项目思维时，强调软件开发是团队协作的结果。良好的沟通是项目成功的关键。引导学生重视软技能的培养，认识到“技术+沟通”才能成为优秀的软件工程师。4.精益求精的工匠精神在讲授编程和设计时，强调代码质量的重要性。引导学生养成良好的编程习惯，追求代码的简洁性、可读性和可维护性。培养学生精益求精的工匠精神，这正是当前中国制造业转型升级所需的精神品质。教学评价课堂表现评价（20%）评价维度评价要点权重参与度积极回答问题、参与讨论10%思考深度能够深入思考并提出有价值的问题10%小组讨论评价（30%）评价维度评价要点权重分析能力能正确运用三种思维方式分析问题15%团队协作小组讨论氛围良好、分工明确10%表达能力能清晰展示讨论成果5%课后作业评价（50%）评价维度评价要点权重概念理解准确理解产品思维、项目思维、工程思维15%应用能力能将三种思维应用于实际案例分析20%书面表达条理清晰、论述充分15%板书设计板面布局┌─────────────────────────────────────────────────────────────┐

│第2章今天我们是如何开发软件的│

├─────────────────────────────────────────────────────────────┤

││

│┌─────────────────┐┌─────────────────┐│

││产品思维││项目思维││

││-用户思维││-计划思维││

││-同理心││-平衡思维││

││-迭代思维││-风险思维││

│└─────────────────┘└─────────────────┘│

││

│┌─────────────────┐│

││工程思维││

││-技术思维││

││-抽象思维││

││-系统思维││

││-批判思维││

│└─────────────────┘│

││

│┌─────────────────────────────────────────────────────┐│

││软件工程主要活动││

││产品定义→需求定义→设计→编程→测试→运维││

│└─────────────────────────────────────────────────────┘│

││

└─────────────────────────────────────────────────────────────┘板书要点左侧：产品思维的核心要素（用户思维、同理心、迭代思维）中间：项目思维的关键词（计划、平衡、风险）右侧：工程思维的特征（技术、抽象、系统、批判）底部：软件工程主要活动流程图核心概念：三种思维的对比表格教学反思教学效果预期知识掌握：学生能够准确理解产品思维、项目思维、工程思维的定义和核心特征，区分三种思维方式的差异能力培养：学生能够运用三种思维方式分析实际的软件工程问题素养提升：学生形成用户为中心、工程伦理、团队协作的意识可能遇到的困难思维方式的抽象性：工程思维比较抽象，学生可能难以理解应对策略：通过大量案例分析，让学生在实践中体会工程思维三种思维的融合：学生可能不知道何时使用何种思维应对策略：强调三种思维不是孤立的，而是相互关联的需求工程的复杂性：需求工程的六个活动比较繁琐应对策略：通过实际项目的需求文档示例，帮助学生理解改进方向增加实际案例的分析和讨论时间引入真实软件项目的需求文档、设计文档作为教学素材设计更多的课堂互动环节，提高学生的参与度课后布置实际项目的分析作业，巩固所学知识课后练习与作业基础概念题（3题）概念理解题：请解释产品思维、项目思维和工程思维的定义，并说明它们的区别。辨析题：产品思维和工程思维在思考用户登录功能时，分别会关注哪些方面？请举例说明。简答题：需求工程包含哪些主要活动？请简要说明每个活动的内容。应用分析题（2题）案例分析题：请选择一个你常用的手机App（如抖音、淘宝、美团等），从产品思维角度分析：它解决了用户的什么痛点？目标用户群体是谁？与同类产品相比，它的竞争优势是什么？综合应用题：假设你要开发一个“大学生选课系统”，请分别从产品思维、项目思维、工程思维的角度分析这个项目需要考虑哪些问题。参考答案要点产品思维关注用户需求和市场价值，项目思维关注进度、成本和交付，工程思维关注技术实现和系统设计。三种思维方式的目标、导向和主要思维方式不同。产品思维关注用户体验、用户便利性；工程思维关注安全性、可靠性、性能等技术指标。需求工程包括需求获取、需求分析、需求建模、需求描述、需求评审与确认、需求管理六个活动。答案要点：选择熟悉的App，分析其用户痛点、目标用户和竞争优势。产品思维：学生选课的痛点、用户需求；项目思维：开发周期、资源需求；工程思维：技术架构、系统性能。实验/实践环节实践项目：校园App产品分析实践目的：培养学生运用产品思维分析用户需求的能力锻炼学生从多角度思考软件工程问题的能力实践要求：每3-4人组成一个小组选择一个校园场景的App或拟开发的App作为分析对象完成以下任务：用户调研：访谈5-10名目标用户，了解他们的需求和痛点需求分析：整理调研结果，识别核心需求产品设计：绘制产品功能结构图项目计划：制定简单的开发计划技术分析：提出技术实现方案成果形式：产品分析报告（Word或PDF格式）课堂展示（10分钟/组）教学日志日期记录内容学生反馈：教学效果：改进建议：本教案基于教材《智能软件工程》第2章内容编写，供授课教师参考使用。#第3章如何获取用户的真实需求电子教案项目内容章节第3章如何获取用户的真实需求周次第2-4周学时4学时（建议）日期待填写课程类型理论+实践综合型授课方式讲授+案例分析+小组讨论+实践操作教学目标教学重点需求层次结构*：业务需求、用户角色需求、功能需求、非功能需求的区分与关系需求获取过程与方法*：问卷调查、深度访谈、焦点小组等传统方法的应用去伪存真分析法*：识别X-Y问题，挖掘用户真实需求需求建模工具：数据流图（DFD）、状态转换图（STD）、实体关系图（ERD）、用例图、类图敏捷需求表达：用户故事（UserStory）、Epic、验收标准（AC）需求评审标准：IEEE需求质量标准、INVEST原则教学难点需求层次转换：如何从业务需求逐层分解为系统功能需求真实需求挖掘：避免X-Y问题，准确把握用户真实意图建模工具应用：灵活运用各种UML建模工具表达需求用户故事编写：掌握INVEST原则，编写高质量用户故事需求评审实施：建立评审标准，有效组织需求评审会议学习目标（能力描述）学完本章后，学生应能够：理解软件需求工程的整体框架和需求层次结构掌握需求获取的常见方法和适用场景应用去伪存真分析法识别用户的真实需求运用结构化分析和面向对象分析方法进行需求建模实践敏捷开发中的用户故事、Epic、验收标准的编写实施需求评审，确保需求质量理解需求跟踪与变更管理的重要性了解业务架构的基本概念和常用框架教学内容详述课堂引入（10分钟）引入案例：同学们，在正式上课之前，我想先和大家分享几个令人深思的案例：澳大利亚税务局GST项目失败：2005年，澳大利亚税务局启动了一个商品和服务税数据处理系统改革项目，由于需求收集不充分和需求变更管理不善，项目最终在2009年被取消，造成了约1.07亿澳元的损失。微软Kin手机失败：2010年，微软推出了面向年轻用户的Kin智能手机，但由于需求定义错误，未能满足目标用户的实际需求，仅两个月后就被下架。英国NHS国家电子病历系统：这是英国历史上最昂贵的IT项目之一，最终在2011年被取消，主要原因就是需求管理不善和需求频繁变更。引入问题：这些项目失败的根本原因是什么？如果你是项目经理，如何避免类似的问题发生？本节课目标告知：

学完本节课，你将能够：准确理解软件需求的层次结构运用多种方法获取用户真实需求使用专业的需求建模工具表达需求编写高质量的用户故事和验收标准组织有效的需求评审3.1软件需求工程概要（20分钟）3.1.1软件需求工程全景图软件需求工程是软件工程的核心组成部分，它涵盖了从需求获取到需求管理的完整过程。根据SWEBOK（软件工程知识体系指南），软件需求工程通常分为五个阶段：需求获取→需求分析→需求定义→需求验证→需求管理这五个阶段相互关联、迭代进行，形成了一个完整的需求工程生命周期。3.1.2需求获取的关键步骤根据SWEBOK及相关标准，需求获取通常包括以下关键步骤：定义问题：简要记录用户面临的问题，通过沟通确认和澄清问题的具体细节。分析问题根本原因：采用鱼骨图、五个为什么等工具，系统分析问题产生的深层原因。分析涉众：涉众识别：列出所有可能受项目影响的个人、团队或组织需求收集：通过访谈、问卷调查、工作坊等方式收集需求利益分析：评估不同涉众的需求优先级定义系统边界：明确软件系统与外部环境的接口和交互方式确定约束条件：识别项目在实施过程中的限制和条件需求验证与确认：包括需求审查、原型验证和需求跟踪📌教学提示：此处可展示“软件需求工程全景图”（图3-1），帮助学生建立整体认知框架。3.2软件究竟有哪些需求？（40分钟）3.2.1需求的基本定义定义：

需求（Requirement）就是对某种产品或服务的需要和要求。根据ISO/IEC/IEEE29148:2011，需求被定义为“转化或表达要求及其相关约束和条件的陈述”。从不同角度理解：用户角度：为了解决问题或达到目标，用户所需的条件或能力系统角度：为了满足协议、标准、规范，系统需要具备的条件或能力📌教学提示：强调需求不仅仅是“功能”，还包含资助者、客户和其他相关利益者的要求和期望。3.2.2软件需求的层次结构正确的思考方式是从业务需求开始，再到用户角色需求，最后到系统的功能和非功能性需求。这就是需求层次模型：┌─────────────────────────────────────┐

│业务需求（业务目标）│

├─────────────────────────────────────┤

│用户角色需求（用例/用户故事）│

├─────────────────────────────────────┤

│功能需求+非功能需求（系统能力）│

└─────────────────────────────────────┘1.业务需求业务需求解决什么关键问题、核心诉求是什么，相当于产品的愿景。业务需求的组成要素：业务流程：企业为实现业务目标进行的一系列有序活动业务规则：指导业务行为的约束条件和准则业务数据：业务处理过程中输入输出的数据2.用户角色需求软件产品是为用户服务的，我们需要关注不同用户角色的需求。用户角色包括：系统管理员知识管理员项目经理/协调员内容创建者协作参与者访客用户📌教学提示：此处可以TMS案例说明不同角色的需求差异。3.系统功能需求功能需求描述软件系统必须执行的特定功能和行为，是用户能直接感受到的系统能力。功能需求的三个关键属性：正确性：功能必须准确符合预期的业务规则和逻辑完备性：功能应覆盖所有用户或客户的业务需求适合性：功能恰到好处满足特定业务场景4.系统非功能性需求非功能需求描述除功能之外的系统其他质量特性：效率（Efficiency）：系统资源使用能力和响应时间可靠性（Reliability）：面对错误输入或异常情况仍能正常运行易用性（Usability）：软件的易理解性和界面友好性兼容性（Compatibility）：与其他系统交换数据的能力安全性（Security）：保护软件免受恶意攻击可维护性（Maintainability）：修改和升级的容易程度可移植性（Portability）：从一个环境迁移到另一个环境的能力5.其他需求类型运维需求：部署、监控、维护和支持缺陷修正：识别、记录、修复软件中的缺陷技术债务：由于捷径或权宜之计产生的额外工作量📌互动建议：请同学们思考，在你自己使用过的软件中，有哪些功能是因为非功能需求未满足而让你感到不满的？3.3真实需求的获取（50分钟）3.3.1需求获取的过程需求获取是确保项目成功的关键步骤。其重要性体现在：确保项目目标明确：通过详细的需求获取，团队清晰理解客户期望和项目目标降低项目风险：未充分获取需求可能导致功能遗漏或误解提高客户满意度：深入的需求获取确保最终产品满足客户需求常见的需求获取过程（8步）明确产品愿景：理解核心问题，确定产品目标收集背景资料：通过互联网、行业报告等途径收集信息确定调查范围与用户角色：识别不同用户角色制定调研计划与访谈大纲：设计访谈问题准备调研工具：问卷、功能原型、逻辑图开展调研与访谈：实地调研、线上访谈生成与修改调研分析报告：整理需求文档持续沟通与反馈：迭代完善需求不同场景的需求获取过程场景类型需求获取重点适用方法已有业务用户反馈、问题改进现场观察、数据分析开创性产品用户痛点、创意开发深度访谈、头脑风暴现有市场竞争分析、用户细分市场调研、问卷调查潜在市场趋势分析、未知需求趋势研究、用户画像3.3.2传统的需求获取方法1.问卷调查特点：高效覆盖：短时间内收集大量用户反馈成本效益：实施成本较低数据可量化：便于统计分析匿名性强：获取更真实的反馈一般操作步骤：目标确定：明确调查目的问卷设计：制定问题，确保简明具有针对性样本选择：确保样本具有代表性问卷分发：通过线上平台发送数据收集与分析：提取关键需求和趋势结果应用：制定改进策略2.深度访谈特点：深入理解：挖掘潜在需求和隐性痛点灵活性高：可根据回答灵活调整建立信任：促使用户更开放分享质性数据：获取详细描述性信息访谈提纲设计示例（以TMS为例）：基础使用情况：您通常如何使用TMS的团队沟通功能？哪些功能是您日常工作中最常用的？用户体验：使用TMS过程中，您遇到过哪些问题或不便？对于任务看板的拖拽功能，您有何改进建议？功能需求：您希望TMS新增哪些协作工具或功能？您认为TMS的哪些功能最有助于提升团队协作效率？3.焦点小组特点：互动性强：激发参与者之间的互动多样化观点：获取多元化的意见灵活性高：主持人可灵活调整话题即时反馈：迅速捕捉参与者的即时反应一般操作步骤：确定目标：明确研究目标设计讨论提纲：涵盖关键话题招募参与者：选择代表性用户群体（6-10名）组织和执行：专业主持人引导讨论分析与总结：识别共性需求和痛点📌教学提示：组织学生进行小组讨论，模拟设计一个针对校园食堂订餐系统的问卷调查或访谈提纲。3.3.3针对新产品的其他方法1.趋势分析与研究技术趋势：人工智能、物联网、区块链、虚拟现实等新技术

行业与市场趋势：市场规模、增长率、竞争格局

社会文化趋势：价值观、生活方式、消费习惯的变化2.用户洞察方法建立用户画像：虚拟代表描述目标用户群体包含基本信息、行为模式、需求和痛点筛选用户特征：年龄段、区域、文化水平、兴趣爱好等情景模拟与角色扮演：模拟用户在特定情境下的操作和决策体验过程中的需求和挑战用户体验旅程地图：描绘用户使用产品经历的各个阶段展示用户的情感变化、需求和痛点3.3.4针对已有产品的其他方法1.现场观察真实了解用户行为：获取未经修饰的真实数据发现隐性需求：识别用户未明确表达的需求深入理解应用场景：了解具体情境下软件的使用方式2.用户行为数据分析分析系统日志记录：剖析用户操作行为评估页面停留时间与点击热点：利用热图分析技术3.业务交易数据分析电商业务：分析订单数据及购物车遗弃率金融业务：分析投资交易数据及资金流向3.3.5智能需求获取方法在智能软件工程时代，我们可以借助大模型来辅助需求获取：设计访谈大纲：让大模型帮助设计访谈问题生成需求列表：通过自然语言交互获取需求追问细化：针对特定需求进行深入挖掘📌教学提示：演示如何通过与大模型交互来获取TMS系统中“任务状态与进度跟踪”的详细需求。3.4智能需求分析与定义（60分钟）3.4.1去伪存真X-Y问题在挖掘真实需求时，常常会遇到“X-Y问题”：用户要解决问题X，但往往给出解决方案Y，然后把Y当作需求。经典案例：某同学让另一同学“帮我从食堂带两个馒头”。这位同学的真实需求可能是：R1：肚子饿了，需要充饥R2：肚子饿了，且要省钱R3