2020春,不一样的学期不一样的软工实践
2020年的春天,注定不同寻常,2月初武汉新冠病毒肆虐,并在全国扩散。于是,2月16日的学校如期开学,授课被全程搬到网上。对我而言,是第一次借助博客园+Github实施软工实践课,也是第一次借助腾讯课堂+雨课堂进行全程授课。
上了多年的软工课,忽然要大幅度的改变上课模式,伴随着软件工程实践的推动也随着发生改变,现在想来,心中不免有些紧张和怯意。即使在教室里,软件工程课也是理论的输导,很容易成为学生手足无措昏昏欲睡的催眠曲,调动课堂气氛本来就不易,搬到网上将更加无底。于是,调动上课气氛成了重中之重:1.调整上课的PPT,适时加入课堂练习,发布并限时收集学生的反馈,听课的同学很容易根据刚刚听过的内容回答问题,收获肯定。2.每周安排一次每周知识点小测,限时20分钟,满分10分,听课的同学容易获得高分,不听课的同学容易鉴别(只会应付或者错失)。3.伴着软件工程实践,将授课的知识点渗入其中,展示在博客中,因此博客作业的内容势必更加专业更加充实,离不开软工理论的发挥。
软工实践,本来就与软工课程相伴相生,实践对于软件工程专业的学生来说,是一项必备的技能。
曾经的软工实践,授课的思路也大致按照这样的流程:第3周选题组队,第4周开题,第5-6周需求,第7-9周设计,第10-13周编码,第14-15周测试,第16周验收展示。每一组5-7个同学,一名负责人,适时在周末提交文档:开题报告、系统规格说明书、软件项目计划、需求规约、设计说明书、开发卷宗、测试报告、用户手册、总结报告等相应的9份文档。集体授课,一般安排4次:第3周选题组队(4时)、第9周中期检查(4时)、第14周系统初评(8时)、第16周系统验收(8时),初评和验收需要每组派2名成员(1名演讲,1名演示)。评分也是组间互评打分,最后根据团队总评集合个人贡献率,计算个人成绩。
如今的软工实践,授课的内容依旧离不开曾经的流程,但推动的模式发生很大的改变:1.引入了助教机制,分担了曾经老师的工作:督促学生或小组,完成阶段性任务,并对大家的表现:评价、打分。2.公开学生或小组的博客作业,将自己的软工实践活动推上博客,全网可见,接受监督和评价。3.借助Github托管系统开发过程,Github不但可以承载代码,而且实施项目分工、代码归并、个人贡献率呈现等。于是,在很大程度上规避了明显的偷懒、作弊、划水等流行的实践课模式。软工实践的线上安排表和博客作业的安排表。
序号 |
时间 |
对应教学周序 |
内容 |
1 |
3.10/周二 |
4 |
团队选题报告答辩 |
2 |
3.15/周日 |
5 |
团队Github实训(机房) |
3 |
3.17/周二 |
5 |
选题解说与项目安排 |
4 |
3.24/周二 |
6 |
团队项目原型设计展示 |
5 |
3.31/周二 |
7 |
团队项目需求答辩 |
6 |
4.7/周二 |
8 |
团队项目系统设计答辩 中期调查问卷 |
7 |
4.14/周二 |
9 |
团队项目数据库设计答辩 |
8 |
4.21/周二 |
10 |
软件评测答辩 |
7 |
5.12/周二 |
13 |
Alpha版本演示 |
9 |
6.9/周二 |
17 |
Beta版本演示/系统验收 终期调查问卷 |
序号 |
实践习题 |
权重 |
负责助教 |
起止时间 |
0 |
准备篇--技术路线 |
3% |
X |
寒假 |
1 |
个人热身--疫情文件读取 |
5% |
X |
寒假-2.16 |
2 |
结对作业第一次——原型设计 |
8% |
C |
2.17-2.23 |
3 |
组队、选题和团队展示 |
4% |
X |
2.24-3.8 |
4 |
结对作业第二次——编码实现 |
12% |
C |
3.9-3.16 |
5 |
Github团队实战总结 |
12% |
S |
3.15-3.17 |
6 |
需求分析 |
8% |
X |
3.18-3.27 |
7 |
概要设计和数据库设计 |
8% |
X |
3.28-4.10 |
8 |
软件评测 |
8% |
S |
4.11-4.17 |
9 |
站立式会议+Alpha冲刺 |
12% |
X |
4.21-5.7 |
10 |
Beta冲刺+事后诸葛亮 |
14% |
C |
5.21-6.8 |
11 |
个人技术总结+项目总结 |
6% |
S |
6.9 |
S班一共99名同学,含4位重修生,分成了11个组,每组9名同学。在第3周采用随机组队的组合模式,题目先是自选,并在第4周宣讲自己的选题内容:选题内容、用户需求、人员分工、可行性论证等,有老师、助教和其他组同学论证,决定项目取舍。11组中,2组自己换题,1组老师指定。其余的实施就按部就班执行咯。
组序 |
组名 |
班级博客链接 |
00 |
2020 S班 |
|
助教Xu |
kofyou
|
|
助教Chen |
chenyuu |
|
01 |
豌豆射手 |
|
02 |
Hail Hydra |
|
03 |
OneDay |
|
04 |
学长帮帮组 |
|
05 |
time masters简时 |
|
06 |
钱途无限6(如果有一天我变得很有钱) |
|
07 |
知社 |
|
08 |
软件工程实践互动评价小组 |
|
09 |
松果生活 |
|
10 |
烤盐屋 |
|
11 |
云玩家 |
经过一学期的实践课,在助教大力协助和精心计算下,分成三个阶段,评选出3次X5名=15位小黄衫得主,下面是15人次的获奖名单。
评选批次 |
小黄衫得主 |
获奖博客链接 |
1
|
胡X浩 |
|
朱X昊 |
||
洪X强 |
||
梁X键 |
||
彭X浩 |
||
2 |
张X榜 |
|
唐X钧 |
||
袁X辉 |
||
许X诚 |
||
翁X鸿 |
||
3 |
余X宸 |
|
吕X昕 |
||
刘X华 |
||
蔡X辉 |
||
陈X杰 |
一学期以来,全程在线给我不一样的授课经历,这里要感谢周老师、汪老师很多有形的鞭策和帮助,感谢两位可爱的助教特别是Xu助教的辛勤付出,还要感谢99名同学有力的配合和互动。诚然,除了感谢授课过程的顺利进行,还有些亟待解决和完善的思考。
1.关于软件工程和软件工程实践课,安排时机的问题?目前是大三下,对于有些考研备考的同学来说,确实有些冲突。显然我给不出答案。
2.关于软件工程的理论和软件工程实践的动手,明显脱节的问题?Alpha冲刺,就涉及到测试的策略和技术,而理论课差不多只达到系统设计环节,滞后。
3.关于组队选拔,是自由组队还是随机组队?种子队,容易造成高手汇集,低手无趣。我倾向随机组队,未来进入职场是很难选择队友的,即使与猪头相伴。若无视队员的技术方向,势必造成内伤,影响团队的协作和努力。兼而有之。
4.关于选题,是自选还是命题?我倾向命题,做出可用且实用的软件,而学生更喜欢自选,自己熟悉或者相对容易的项目。规避舒适区,命题更好,它解决的是真实的需求。比如本学期的“软件工程实践互动评价”就是真题。做真实且有用的软件,是一以贯之的追求。
5.关于助教工作,如何认定的问题?学生助教,没有报酬,心系付出,如何评价助教的责任和能力,如何协同助教更好推动教学,我有困惑。需要经费。
6.关于老师工作,如何提高教学质量的问题?不一样的学期,授课付出更多;不一样的实践,推动难度更大。但投票权在受众手中,怎样策动课程质量的提升?尽量无愧于心。
7.关于软工实践的进度安排?Alpha冲刺前、Beta冲刺后的时间安排有些松散,或许可以更加紧凑。
8.关于评价及评价回馈乏力的问题?评论博客,势必要细看相关内容,并提出相对真实的问题,就涉及到评价的针砭。若针砭被无视或冷落,该怎样激发呢?至今无解。
9.关于团队组长如何产生以及组长能力的问题?组长,对一个团队来说,是中坚力量,技术强好沟通善组织,是理想的组长必备条件。组长怎样产生,是自荐、推荐、还是指定?组长,是强调技术底蕴还是侧重组织协调?其实,软工实践最怕成了组长或某些组员的个人表演,曾经感慨过:一个9人团队,1个前端,1个后端,1个UI,剩下的不是文案就是测试,唉!每个同学都有技术的提炼,技术强的同学则侧重沟通和组织、融合能力。全体都有,运动起来,尽量全面提升专业素养,而不是陪练。
10.关于实践课的班级人数和团队人数的问题?团队规模,以5或7人为宜,而2个助教1个老师,较好照顾的团队个数合计一般不超过10个,因而班级人数,从实践的角度,以50/60个为宜,人多造成困难和浪费。
11.关于软工实践文档的问题?软工实践的监控,离不开软件过程文档的规范制作和适时发布,博客作业的内容,如何做到既真实又适用呢?真实,是要体现UML分析和设计的内涵;适用,就是展示自我的外在表现,即美观和好用。除了充实的博客作业,规范化的软工文档也应慎重对待。
12.关于重修生的现实问题?重修生,选修实践课的唯一目的是为了获取学分,但重修生因面临毕业,且是学姐或学长,没法要求太多,因此会被很多组排斥或无视。重修生很尴尬,努力不要重修。
13.关于课程的付出?对教师,如果超课时太多的付出,如果回馈的互动有限,无力感油然而生,如何有激情的迭代付出的过程真的很难。对秉承“混学分,及格就好”的学生,如何甄别对待呢?这样的学生占三分之一左右。软工学生的软工实践,不能降低课业的要求,如何平衡兴趣爱好和专业方向呢?停留在及格就好的同学,最低标准是承担某一部分代码和某一部分文档,前者以Github可以展示的issue和commit部分为准,后者以博客个人作业和团队中个人部分为证。
综上,2020春学期的确经历了一次不一样的软工实践课,新冠病毒带来不一样的疫情教学,收获一段不一样的人生财富。这次经历中,留下如许深刻的印记:个人作业,比较有特色的就是2次结对编程和1次技术总结,而团队合作过程比较紧张的时间段:Github实训、Alpha冲刺、Beta冲刺,是软工实践团队过程的3个亮点。而与新冠病毒有关的结对编程,给我深刻印象:运用所学,解决现实应用问题,是对软工学生最好的专业检验。所以在文末,附上整理的《软件工程实践》教学设计过程。
附:
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收集存储学生程序,并利用它管理学生分派任务,也是一种勇敢的尝试:公开透明,接受各方面监督。
在疫情依然严峻的日子,尝试用新的教学方式和新的编码技术,借助软件工程开发实践的思想,完成贴近生活的软件项目内容,突出了实用性价值,对老师和学生的提升都很有现实意义的。