当前位置：首页 > news >正文

构建之法 - 软件工程实践教学：一线教师的13问

news 2025/10/4 1:16:02

福州大学单红老师的软工课程总结

2020春，不一样的学期不一样的软工实践

单红⽼师在总结中，提出了13条疑惑，《构建之法》的作者邹欣⽼师就单红⽼师提出的每⼀条疑惑，给出了⾃⼰的思考，与他进⾏探讨交流。欢迎你也来参与⼀起讨论。

1.关于软件工程和软件工程实践课，安排时机的问题？目前是大三下，对于有些考研备考的同学来说，确实有些冲突。显然我给不出答案。

xinz：大学有四年，每一年都应该有足够的训练，大学本科并不是‘考研复习班’，我们要问的问题是：软件工程课给学生符合大学要求的训练了么？而不是：“我们放水足够多，让部分学生可以复习考研了么”

2.关于软件工程的理论和软件工程实践的动手，明显脱节的问题？Alpha冲刺，就涉及到测试的策略和技术，而理论课差不多只达到系统设计环节，滞后。

xinz：大学生，可以自己学习，我们特地安排了apha 、beta 阶段，alpha 阶段就是自己学测试方法，自己测试；beta 阶段再提高。

3.关于组队选拔，是自由组队还是随机组队？种子队，容易造成高手汇集，低手无趣。我倾向随机组队，未来进入职场是很难选择队友的，即使与猪头相伴。若无视队员的技术方向，势必造成内伤，影响团队的协作和努力。兼而有之。

xinz：随机，加上允许部分人换组，和强制换组。

4.关于选题，是自选还是命题？我倾向命题，做出可用且实用的软件，而学生更喜欢自选，自己熟悉或者相对容易的项目。规避舒适区，命题更好，它解决的是真实的需求。比如本学期的“软件工程实践互动评价”就是真题。做真实且有用的软件，是一以贯之的追求。

xinz：这在软件工程课中已经讨论多次。 80% 命题， 20% 的有能力的学生可以自选，但是条件要事先说明清楚。

5.关于助教工作，如何认定的问题？学生助教，没有报酬，心系付出，如何评价助教的责任和能力，如何协同助教更好推动教学，我有困惑。需要经费。

xinz：可以用多种方式来激励助教，可以和其他老师交流一下。

6.关于老师工作，如何提高教学质量的问题？不一样的学期，授课付出更多；不一样的实践，推动难度更大。但投票权在受众手中，怎样策动课程质量的提升？尽量无愧于心。

xinz: 可以做几个调查问卷，看看一些教学手段的效果如何。

7.关于软工实践的进度安排？Alpha冲刺前、Beta冲刺后的时间安排有些松散，或许可以更加紧凑。

xinz: 可以尽量让学生先做alpha 阶段，他们会获得宝贵经验教训。

8.关于评价及评价回馈乏力的问题？评论博客，势必要细看相关内容，并提出相对真实的问题，就涉及到评价的针砭。若针砭被无视或冷落，该怎样激发呢？至今无解。

xinz：作业尽量有具体的要求，如果达到要求，就可以得分。而不是作业要求含混，学生博客也含混，评论中再提要求，已经晚了。针砭博客效果一般，不如按照要求直接扣分。

9.关于团队组长如何产生以及组长能力的问题？组长，对一个团队来说，是中坚力量，技术强好沟通善组织，是理想的组长必备条件。组长怎样产生，是自荐、推荐、还是指定？组长，是强调技术底蕴还是侧重组织协调？其实，软工实践最怕成了组长或某些组员的个人表演，曾经感慨过：一个9人团队，1个前端，1个后端，1个UI，剩下的不是文案就是测试，唉！每个同学都有技术的提炼，技术强的同学则侧重沟通和组织、融合能力。全体都有，运动起来，尽量全面提升专业素养，而不是陪练。

xinz：可以组成较小的团队，例如 4-5 人， 另外别的课程也可以有类似练习，这样学生能适应这样的合作方式。

10.关于实践课的班级人数和团队人数的问题？团队规模，以5或7人为宜，而2个助教1个老师，较好照顾的团队个数合计一般不超过10个，因而班级人数，从实践的角度，以50/60个为宜，人多造成困难和浪费。

xinz：的确要考虑老师和助教的负担问题。

11.关于软工实践文档的问题？软工实践的监控，离不开软件过程文档的规范制作和适时发布，博客作业的内容，如何做到既真实又适用呢？真实，是要体现UML分析和设计的内涵；适用，就是展示自我的外在表现，即美观和好用。除了充实的博客作业，规范化的软工文档也应慎重对待。

xinz：为何博客不能就是规范化的文档呢？ 很多项目的文档也是通过博客，GitHub page，GitHub wiki 发布的。

12.关于重修生的现实问题？重修生，选修实践课的唯一目的是为了获取学分，但重修生因面临毕业，且是学姐或学长，没法要求太多，因此会被很多组排斥或无视。重修生很尴尬，努力不要重修。

xinz：要明确说明，得到‘及格’ 这个分数需要多少努力， 不能放水。

13.关于课程的付出？对教师，如果超课时太多的付出，如果回馈的互动有限，无力感油然而生，如何有激情的迭代付出的过程真的很难。对秉承“混学分，及格就好”的学生，如何甄别对待呢？这样的学生占三分之一左右。软工学生的软工实践，不能降低课业的要求，如何平衡兴趣爱好和专业方向呢？停留在及格就好的同学，最低标准是承担某一部分代码和某一部分文档，前者以Github可以展示的issue和commit部分为准，后者以博客个人作业和团队中个人部分为证。

xinz：正视事实，的确有不少学生就是为了混及格，那就要明确及格的标准， 混也要流汗才能混到及格。

综上，2020春学期的确经历了一次不一样的软工实践课，新冠病毒带来不一样的疫情教学，收获一段不一样的人生财富。这次经历中，留下如许深刻的印记：个人作业，比较有特色的就是2次结对编程和1次技术总结，而团队合作过程比较紧张的时间段：Github实训、Alpha冲刺、Beta冲刺，是软工实践团队过程的3个亮点。而与新冠病毒有关的结对编程，给我深刻印象：运用所学，解决现实应用问题，是对软工学生最好的专业检验。所以在文末，附上整理的《软件工程实践》教学设计过程。

xinz：赞，希望看到不断地逐步提高，另外，这一门课是整个培养体系的一部分，希望改进培养体系，例如： github ,Github desktop、IDEA、Jprofiler、Axure rp、墨刀等平台或工具软件的实训可以放到先修课程中，这对先修课程也很有用处的。

同样，习惯了学校教室授课方式的指导老师，线上的实践授课也是陌生和有点新奇，然而在技术不断革新的今天，作为教师同样需要不断地学习才能跟上脚步。借助博客园公开学生开发情况，利用Github收集存储学生程序，并利用它管理学生分派任务，也是一种勇敢的尝试：公开透明，接受各方面监督。

xinz：请让助教不断把工作自动化，减少手工的部分，这样也可以提高效率。

正如一个学生写到：不同的两个同学结对编程，经历了一次次想要放弃，却看到旁边正注视自己的结对同学，只好丢下放弃的念头，坚持！坚持，就这样一次又一次的坚持下：查找资料，寻求帮助，解决问题，一步步推动系统模型的构建。

xinz：结对编程也可以推广到先修课程中，让同学从中获益。

附：2020春《软件工程实践》教学设计1例

一、问题陈述：

目前，新型冠状病毒肺炎疫情到了非常关键的时期，社会各界都严阵以待。网上有一家疫情统计网站，每天会提供一个疫情数据的日志文本，记录着国内各省前一天的感染情况。但是，疫情统计结果只提供文字，不够直观、具体，对用户来说不够友好，希望这次结对编程作业，能通过地图的形式来直观显示疫情的大致分布情况，而且可以查看具体省份的疫情统计及发展等信息。

二、作业布置

结对编程第一次作业--原型设计（2020.2.22-2020.2.29），其主要目的是通过结对编程，从网上获取文本数据，进行转化，使之符合原型开发工具的需要。结对编程第二次作业--编码实现（2020.3.7 - 2020.3.14），其主要目的是通过原型开发工具，利用第一阶段获取的规格数据，从而形成可视化的疫情统计系统模型。结对编程第二次作业（编码实现）是在结对编程第一次作业（原型设计）的基础，使得文本文件能通过可视化的图像直观展示给用户。

三、教学过程

（1）作业回顾

两次作业，明确作业的解题思路。首先，从网上得到日志文本。遵守日志文件的命名和对应的日期规范，特别注意要读取信息的限制规则。其次，学习使用相关命令。需要先学习和理解原型工具的命令和参数，并进行详细说明。接着，输出可视化的文件。对日志文本进行加工，输出文件中要列出全国和各省份的各类型患者人数，同时要对日志文本中各个信息进行提取并保存。最后，借助原型模型的工具，构建可视化的疫情统计模型。疫情模型，不仅直观呈现全国、各省的昨天24小时疫情数据，而且可以动态展示一段时间的疫情变化，让人们对疫情有较好的认知。

（2）NABCD模型

疫情统计的可视化模型是基于NABCD模型给出的解决方案。N（Need）：该模型是为了解决互联网用户无法及时直观获取疫情数据分布、把握疫情走势的痛点。A（Approach）：该模型需要直观的地图、图表、趋势图向他们展示疫情的形态，但是现有的产品并没有很好地解决这些需求，还可以扩展诸如查询等功能。B（Benefit）：不仅能给用户带来实时跟踪疫情情况的好处，而且能获取关于疫情更全面的信息。C（Competitor）：借助微信、QQ等宣传方法，能很快地让目标用户知道该系统。D（deliver）：借助校园网，进一步推广。

（3）教学过程

一上午4节课，每节课45分钟，这45分钟分成3部分。在15分钟中，前5分钟由学生讲解作业的完成过程，中间5分钟由学生演示，最后5分钟是问与答，每个组要针对老师、助教或有其他组的提问作出相应回答。这样每节课3组，4节课11组，安排是这样的，具体操作往往超过一些。

每个组在展示时，首先是讲述自己的学习和实现的过程，然后展示实现了的疫情统计可视化原型：整体视图、趋势变化，接着突出所使用的技术，最后通过在线讨论表达些许开发过程的互动。下面从几个课堂片段的截图，展示3个团队进行疫情统计的可视化模型的不同侧面。说明2017级软件工程专业学生的线上实践课的具体实施过程。

1. 整体视图

第一组：104、116的疫情统计可视化原型，见图1。

图1

第二组：423 、 404的疫情统计可视化原型，见图2。

图2

第三组：150、434的疫情统计可视化原型，见图3。

图3

通过这3组，可以看出他们各具特色。第一组UI美观、功能丰富，第二组UI清新、相对单薄，第三组UI基于安卓，信息集中。

2. 趋势变化

第一组：104、116的疫情统计可视化原型，见图4。

图4

第二组：423 、 404的疫情统计可视化原型，见图5。

图5

第三组：150、434的疫情统计可视化原型，见图6。

图6

通过这3组，可以看出他们各具特色。第一组和第二组的趋势图线条流畅，第三组的趋势线条比较质朴。

3.技术依托

第一组：104、116的疫情统计可视化原型，借助的是Axure rp，结合Echarts和Axure，运用JS。

第二组：423 、 404的疫情统计可视化原型，借助的是Axure rp，基于Flask框架实现的web应用。用python网络爬虫获取丁香园的实时数据。

第三组：150、434的疫情统计可视化原型，借助的是Axure rp，结合spring boot框架。

通过这3组，可以看出各组使用的数据获取技术各不相同，每一组都有较好的完成度，亮点鲜明。

4.交流互动

第一组：104、116的疫情统计可视化原型，见图7。

图7

第二组：423 、 404的疫情统计可视化原型，见图8。

图8

第三组：150、434的疫情统计可视化原型，见图9。

图9

通过这3组，可以看出各组的交流也是各不相同，真实而富有成效。

四、教学感悟

教学相长，是线上软件工程实践教学的最大体会。因为在进行结对编程构建系统模型之前，我们的学生基本并未接触多少原型化开发的内容。学生以前并未使用过Github desktop、IDEA、Jprofiler、Axure rp、墨刀等平台或工具软件，因此在学习和使用的过程中，遇到了诸多困难。正如一个学生写到：不同的两个同学结对编程，经历了一次次想要放弃，却看到旁边正注视自己的结对同学，只好丢下放弃的念头，坚持！坚持，就这样一次有一次的坚持下：查找资料，寻求帮助，解决问题，一步步推动系统模型的构建。

同样，习惯了学校教室授课方式的指导老师，线上的实践授课也是陌生和有点新奇，然而在技术不断革新的今天，作为教师同样需要不断地学习才能跟上脚步。借助博客园公开学生开发情况，利用Github收集存储学生程序，并利用它管理学生分派任务，也是一种勇敢的尝试：公开透明，接受各方面监督。

在疫情依然严峻的日子，尝试用新的教学方式和新的编码技术，借助软件工程开发实践的思想，完成贴近生活的软件项目内容，突出了实用性价值，对老师和学生的提升都很有现实意义的。

单红老师所在班级-班级博客

2022春计算机网络|数理
2021春软件工程实践|S班
2020春|S