高中信息技术必修2信息系统的设计教学设计（2课时）

高中信息技术必修2信息系统的设计教学设计（2课时）【课程标准与教材分析】本课选自教科版（2019）高中信息技术必修2《信息系统与社会》第三单元第一节，是学生从"认识信息系统"走向"构建信息系统"的关键转折。前两单元中，学生已经理解了信息系统的组成要素、功能类型以及信息社会中人与技术的关系，能够识别身边的购物系统、选课系统、图书借阅系统等实例。本节的任务是把零散的认知凝聚为设计能力：让学生经历需求分析、功能设计、数据设计、界面设计的完整过程，体会"设计先于编码、需求驱动开发"的工程思想。课程标准对本部分内容的要求落在"信息系统的设计与开发"这一内容模块，强调学生能够针对具体情境中的问题，分析用户需求，设计小型信息系统的功能结构与数据模型，并对设计方案进行评价与优化。本节内容恰好承担了这一落地任务，是计算思维中"抽象"与"分解"两大要素的集中演练场。【学情分析】授课对象为高一年级学生。从知识储备看，学生日常使用大量信息系统，对"用户看得见的功能"有丰富直觉，例如登录、搜索、下单、评论；但对"系统背后的逻辑"认识模糊，普遍分不清功能模块与数据表的关系，容易把"页面好看"当作"系统好用"。从思维特点看，高一学生已具备一定的归纳与分类能力，但面对开放性的设计任务时容易无从下手，常出现两种倾向：一是照搬现成系统的功能清单，缺少对真实需求的追问；二是过早陷入界面细节，忽视功能与数据的整体架构。从合作经验看，学生在初中综合实践课中有过分组完成作品的经历，具备基本的分工协作能力，但组内角色意识不强。基于上述判断，本课的教学着力点有三：其一，用一个贴近学生生活的真实选题贯穿始终，让抽象的设计流程有具体的载体；其二，提供"需求卡—功能结构图—数据表草图—界面原型"四级脚手架，把设计过程显性化、可操作化；其三，通过组间互评制造认知冲突，让学生在辩解与质询中修正自己的设计观。【教学目标】1.信息意识：能够从真实生活情境中识别信息处理的需求，主动思考"这个需求能否用一个信息系统来满足"，意识到设计是连接问题与技术的桥梁。2.计算思维：能运用抽象与分解的方法，把一个总需求逐层拆解为若干功能模块；能用简单的数据表结构描述系统中流动的信息，初步建立"功能依赖数据、数据支撑功能"的整体观念。3.数字化学习与创新：能借助功能结构图、纸面原型等工具表达设计方案，对小规模信息系统的功能、数据、界面进行初步设计，并能根据评价意见迭代改进。4.信息社会责任：在设计过程中关注不同用户群体的真实诉求，初步考虑隐私保护与权限设置，理解"技术方案必须对使用者负责"的伦理要求。【教学重点与难点】教学重点：信息系统设计的一般流程，即需求分析、功能设计、数据设计、界面设计四个环节的内容、方法与产出物。教学难点：一是需求分析的深度——如何从用户访谈或情境描述中提炼出真实、完整、可检验的功能需求；二是功能与数据的对应关系——理解每个功能模块背后必然有数据的录入、存储与处理，避免"有功能无数据"的空壳设计。【教学策略】采用"情境驱动＋任务进阶＋设计迭代"的策略。全课以"为学校设计一个流浪图书漂流管理系统"为主情境，该选题贴近学生生活、规模适中、权属清晰，便于高一年级学生在两课时内完成一轮完整的设计闭环。第1课时完成需求分析与功能设计，第2课时完成数据设计、界面原型与方案答辩。教师在整个过程中扮演"甲方"与"技术顾问"的双重角色，通过追问模拟真实开发中的需求澄清环节。【教学准备】教师准备：情境任务单、需求访谈记录卡、功能结构图模板（A3纸）、数据表设计卡、纸面原型模板、评价量规、两套正反例设计方案（用于第2课时的对比分析）。学生准备：前两单元的学习笔记，每组四人明确组长、记录员、设计师、汇报人的初始分工。═══════════════════第1课时：从真实需求到功能蓝图【环节一：情境导入——一次失败的借阅（7分钟）】教师讲述一个真实情境：学校图书馆门口设了一个"漂流书架"，同学们可以把看完的书放上去自由取阅。运行一个月后问题频出——好书放进去就再也找不到踪迹，有同学想找某本书只能碰运气，书架越来越乱，最后漂流活动几乎停摆。教师提问：如果你是这个活动的组织者，你会想到用什么办法解决？学生通常会说"登记一下""做个小程序"。教师顺势追问：那这个"登记"或"小程序"具体要管什么？谁在用？他们各自想要什么？设计意图：用学生身边真实发生过的小失败切入，制造"现状有痛点、技术能解决"的张力，使"设计信息系统"这件事从课本任务转化为学生自己想做的事。三连追问直指需求分析的三个核心问题——管什么、谁来用、要什么，为下一环节埋下思维线索。【环节二：需求分析——学会替用户追问（18分钟）】教师发放情境任务单与各角色的访谈记录碎片。任务单中预置了四类角色的只言片语：捐书同学说"我想知道我捐的书有没有人看"；找书同学说"我想知道某本书现在在不在书架上"；管理员同学说"我不想天天去整理，最好系统自动提醒我"；老师说"别泄露学生个人信息"。各小组的任务是：阅读这些碎片，讨论并填写需求分析表。表格分为三列：用户是谁、他想要什么、这个愿望背后的真正需求是什么。教师强调第三列的填写要领——用户说出来的往往是"方案的雏形"而非"需求的本质"，例如"我想知道书有没有人看"的本质需求是"系统要记录每本书的捐赠者与流转历史"。巡视指导时，教师重点纠正两类偏差。一类是需求写得过大过空，如"系统要好用""功能要强大"，教师反问：什么叫好用？三年后的人拿着你这句话能验收吗？迫使学生把需求表述为可判断、可检验的具体条目。另一类是遗漏隐性角色，多数组只想到借书者和捐书者，教师以"谁是甲方"的身份提示：如果管理员的工作量反而比手工登记还大，这个系统会不会被弃用？小组完成需求列表后，教师请两组板演各自的清单，全班快速比对：哪些需求大家都有（登录、查看图书列表、捐书登记），哪些需求只有个别组想到（预约、超期提醒、权限区分），哪些需求相互冲突。冲突之处不急着裁决，记在黑板"争议区"，留待答辩环节处理。设计意图：需求分析是学生最陌生也最薄弱的环节，直接决定后续设计的质量。把抽象的"用户研究"转化为"读访谈碎片、填三列表格"的具体操作，降低了起步门槛；教师以甲方身份的追问与两组清单的比对，让学生在真实的分歧中体会需求的层次性与完整性，这比教师宣讲"需求要全面、要具体"有效得多。【环节三：功能设计——把需求翻译成模块（15分钟）】教师明确提出本环节规则：每一条功能需求，都必须能在功能结构图上找到对应的模块；反过来，图上每一个模块，都必须能回溯到至少一条需求。两张纸对着看，谁也不能"单飞"。各组在A3纸上绘制功能结构图。顶层是"图书漂流管理系统"，第二层按使用对象或业务逻辑划分为若干子系统，常见的合理划分是：用户管理模块、图书管理模块、借还有漂流模块、查询统计模块、系统提醒模块。第三层再细化为具体功能点，例如图书管理模块下分"图书录入""图书信息修改""图书下架"。巡视中教师重点处理三个典型问题。其一，模块划分依据混乱，有的组把"登录"和"还书"并列，层次错位，教师引导其判断：这两个功能是同一层级的兄弟，还是谁包含谁？其二，出现"需求清单上没有、但大家照手机应用抄来"的冗余模块，如"在线客服""积分商城"，教师不直接否定，而是请该组说明哪个用户在哪条需求里要它，答不上来则贴上"待淘汰"标签。其三，忽略后台管理功能，教师追问：书被放错分类了谁来改？让学生意识到管理端与使用端同样重要。设计意图：功能结构图是本课时最核心的学习产出。设置"需求—模块双检验"规则，是为了根治学生凭直觉堆功能的顽疾，让"需求驱动设计"从口号变成可执行的检查动作。三个典型问题分别对应层次混乱、机械抄袭、视角缺失三大高频误区，教师以追问代替讲授，把纠正的过程变成思维示范。【环节四：小结与课后延伸（5分钟）】教师用一张来自软件行业的简化流程图收束全课：需求分析回答"为什么做、给谁做"，功能设计回答"做成什么样"，下一课时将解决"数据怎么存、界面长成什么样"。布置课下任务：每组观察一个自己常用的应用，试着指出它的两个功能模块分别存了哪些数据，写出猜想，下节课用来对照自己的数据设计。═══════════════════第2课时：让设计可以落地【环节一：回顾与新任务（5分钟）】用两分钟快速回顾上节课的"需求—模块双检验"成果，各组把功能结构图展开铺在桌面。教师抛出新问题：图上的每一个功能按钮背后，系统真正记住的是什么？学生尝试回答，逐步聚焦到"存的是数据"这一核心认识，引入数据设计。【环节二：数据设计——给信息安个家（15分钟）】教师示范：以"图书信息"为例，与学生一起推敲一张数据表应该有哪些字段——图书编号、书名、作者、捐书人、当前状态（在架/借出）、当前持有人。每确定一个字段，教师都追问一句"删了它会怎样"：删掉"当前状态"，查询功能就瘫痪；删掉"捐书人"，捐书同学的需求就落空。通过这组追问，学生直观体会到字段来自功能、字段服务需求。各小组随后填写数据表设计卡，至少完成三张核心表：用户表、图书表、漂流记录表。教师只给框架不给答案，巡视时关注两点：一是字段是否够用，例如漂流记录表若不包含"借出时间"，超期提醒功能便无据可依；二是表与表之间如何关联，引导学生发现图书编号、用户编号是把多张表"缝"在一起的关键线索，点到为止，不展开关系数据库理论，为后续学习留下接口。设计意图：数据处理是功能与存储之间的枢纽，也是本课理解的难点。用"删除测试"代替枯燥的字段讲解，让学生在取舍中理解数据与功能的依存关系；三表联动的设计任务让学生第一次产生"系统由相互关联的数据构成"的整体感。【环节三：界面原型——让用户一眼看懂（10分钟）】各组选用两种方式之一快速产出界面原型：纸面手绘草图，或用演示文稿的矩形与文本框拼搭线框图。要求至少画出三个界面：用户登录后的主界面、图书列表与搜索界面、捐书登记界面。评价标准只有三条：用户不用教就会用；每个界面上的元素都能对应到功能与数据；不同角色的界面有区分。巡视中教师提醒两类倾向：过度美化，把时间花在配色插画而非功能布局；界面元素与前面设计脱节，出现一个凭空冒出的按钮，却没有对应的功能模块和数据字段。后者一经发现，教师要求该组追溯整个设计链条，补上缺失环节。【环节四：方案答辩与互评（12分钟）】每组三分钟陈述，限时讲清三件事：我们抓到了哪些别人没注意到的需求；我们的功能结构图严密之处在哪里；我们的数据表如何支撑关键功能。台下小组依据评价量规打分并必须提出一个"无法回避的问题"，例如"同一本书被两个人同时预约怎么办""学生毕业注销后他的漂流历史保留吗"。教师行使"甲方一票质询权"，针对每组方案追问一个深层问题。质询与回答的价值不在得出标准答案，在于暴露设计的盲区。被问住的组当场在图纸上做修改标记，教师明确肯定：敢于当场改方案的组，恰恰是经历了一次真实的工程迭代。【环节五：总结提升（3分钟）】教师收束全课：两课时里大家走过了一条完整的设计链路——从真实痛点出发，替用户追问需求，把需求翻译成层次清晰的功能结构，再让功能落到数据与界面。这套"先想清楚、再动手做"的方法，不仅适用于信息系统，也适用于今后任何一个复杂问题的求解。留下拓展问题：如果这套系统真的要开发出来，用户的数据安全该如何保障？为本单元后续"信息安全"内容埋下伏笔。【板书设计】主板书呈金字塔结构：顶端"信息系统的设计"；中层四个环节横向排列——需求分析（为谁做、做什么）、功能设计（分成哪些模块）、数据设计（存什么、怎么关联）、界面设计（怎么用）；底层用箭头标注贯穿全程的两条纪律——需求驱动、前后对应。副板书保留"争议区"与各组答辩时暴露的典型问题，作为全班共同的思考痕迹。【作业设计】基础任务：每组根据答辩意见修订设计方案，提交定稿版功能结构图与三张数据表。提升任务：任选一个生活场景（班级失物招领、食堂满意度反馈等），独立完成一份简版需求分析，检验设计方法能否迁移。任务分层，前者巩固本课成果，后者指向能力迁移。【教学评价】采用过程性评价与表现性评价结合的方式。过程性评价关注两课时中各组需求表的修改次数与理由、功能结构图的迭代版本；表现性评价依托答辩环节的四维量规——需求的