更新时间:2022-10-01 08:46:15
现实世界是***的老师, 我们这些叫 “老师” 的人, 充其量是个助教。 但是有些助教却不让学生见到老师。
****************
老师都想把课教好, 学生都想把课学好. 但是我们常常看到一个学期过后, 老师, 学生都有很多抱怨 (例如: 各种良好愿望和计划在实施中的问题). 看了上面的例子, 我脑海中浮现这样的图画:
游泳教练认为经过各项基本训练, 学员在第三年的时候, 应该达到了能组队游泳渡江的能力, 于是教练幻想这样的画面:
期望学生们综合运用平时训练获得的能力, 组成团队, 互相帮助, 自主学习, 集体渡江成功, 老师和TA 只用在小船上实施必要的救助即可.
但是良好的愿望碰到了尴尬的现实,这是老师在操作系统课上发现的现实:
- 特别能抄袭。被确认抄袭的人次历史之最,是往届数倍
- 特别能放弃。抄袭无门后,就大片地放弃作业,人数也是历史之最,往届数倍
- 特别少交流。网上论坛里的讨论,无论数量还是质量都是史上最低
- 特别能应试。虽然发帖少,但询问评分细节的帖子却是史上最多
- 特别缺惊艳。即便是独立完成作业且拿满分的同学,其中也难以见到往届哪种处处惊艳的效果,很多人都只是应付,看不到任何激情。
我不知道在大江大河中游泳, “抄袭, 应试” 是怎么实现的, 所以无法类比。 放弃倒是很好类比, 很多 “游泳健儿”到了江边, 找各种借口 - 不游了!
大学生都有一定的阅历和自学能力, 他们通常能很容易地掌握下图中第一步到第四步。 但是社会要求往往是第五步 - “精通”。 这第四步到第五步之间有一个很大的鸿沟。 要跨过这个沟, 学生要学一些比较乏味而且貌似不太相干的内容, 例如马的骨骼结构, 若干原理, 若干基础实践课程如素描等等。 老师怎么创造一种学习/实践/反馈的环境, 让学生能通过各种手段跨过这个沟。 (参考 卓越大学教师的建议).
在我教的课中, 绝大部分学生都下河里真正地游了好几次, 还完成了一次团体横渡江河的挑战。 他们感觉很累, 但是也很有收获, 算是体会到了实际做软件是怎么回事。 下面是我教 <现代软件工程> 的一些心得:
Deadline - 学生生活是什么驱动的? 是对老师规定的服从, 还是对技术的热情, 还是为中华民族第N次伟大复兴? 还是deadline? 大部分人的作业都是要等到交作业的前一天夜里搞出来的。 在软件工程课上, 一个晚上是搞不出来可以使用的团队项目的, 为此课程设置了很多检查点:
没有这些检查点, 同学们会在最后演示的时候告诉你 - 我们尽力了, 搞了三天, 这次给我们及格吧, 我们以后一定会继续改进的!然后他们再也没有消息了。
不要盲目追求新: 1999年, 有人问软件工程专家 David Parnas: 将来会有什么令人兴奋的软件工程技术出现? 答: 最有用的技术不在将来,
而是已经在我们中间好些年了, 只不过我们没好好用。软件工程课要把那些久经考验的原则和技术交给学生, 而不能停留在浮光掠影地介绍当前最热门的做法。 老师要展现给学生的是, 软件工程的原则,技术仍然能解决前软件开发的各种挑战 - 老师自己有这个信心和经验么?
附: 教学计划 (http://www.cnblogs.com/xinz/archive/2011/11/27/2265425.html)
北航的软件工程教学计划:
http://www.cnblogs.com/SivilTaram/p/5656582.html
教学计划总长: 16 周 (扣除放假之后)
授课: 12 - 14 次 老师授课
辅导课: 6 - 8 次 (辅导/交流/演示) 学生主动汇报进展, 心得, 提出问题, 老师及专业人士给予辅导。
学生项目: 个人项目, 结对编程项目 (两个), 团队项目
Week | Date | Lecture (授课) | Talk (辅导/交流/演示) | Project |
1 | 11/1 | Intro (课程简介, 分组) I-project 个人项目介绍 | i-project (个人项目) | |
2 | 11/8 | Software Engineering (软件工程概论),Unit Test (单元测试) | ||
3 | 11/15 | Personal Software Process (个人软件流程 PSP), Code Quality (代码质量的各种标准) | SilverLight | pair project (1) 结对项目 (1) |
4 | 11/22 | collaboration (两人合作), influence (影响说服别人的多种方式) | P1 review | |
5 | 11/29 | Team-CMMI (团队结构, 文化, 成熟度模型 CMMI)Development Process (软件开发的各种模式) | pair project (2) 结对项目 2 | |
6 | 12/6 | Innovation (软件业的创新)Myths of Innovation (迷思),Innovator's dilemma (创新者的两难) | P2 review | |
7 | 12/13 | NABCD (项目可行性分析)Spec and PM(软件规格说明书, 项目经理) | Book Report | Team Project Kick Off 团队项目开始 |
8 | 12/20 | Testing(测试) | Milestone 1 (里程碑 1) | |
9 | 12/27 | Proj. Mgmt w/ TFS (用TFS 进行项目管理) | daily scrum | |
10 | 1/3 |
Scenarios (基于场景的设计), 软件原型设计工具介绍 |
daily scrum | |
11 | 1/10 | Release (软件的发布) | alpha release | |
12 | 1/17 | MSF (微软软件解决方案框架) | Review | Review/BugBash |
13 | 1/24 | Dev-History (微软软件开发管理的历史) | feedback | Milestone 2 (里程碑2) |
n/a | 1/31 | Holiday | Holiday | |
n/a | 2/7 | Holiday | Holiday | |
14 | 2/14 | Risk Mgmt (软件项目的风险管理) | Book Report | daily scrum |
15 | 2/21 | daily scrum | ||
16 | 2/28 | UI/UX report | beta release | |
n/a | 3/7 | Postmortem (软件项目的回顾与反思) | ||
17 | 3/14 | Final Review (最终汇报, 复审) |
本文转自SoftwareTeacher博客园博客,原文链接:http://www.cnblogs.com/xinz/archive/2012/01/15/2322913.html,如需转载请自行联系原作者