软工+C(2): 分数和checklist

// 上一篇:题目设计、点评和评分
// 下一篇:超链接


教学里,建立清晰明确的评分规则并且一开始就公布,对于教师、助教、学生都是重要的。

公布时机

在课程开始的时候,就需要确定并公布评分机制,随着课程展开,需要做的是做细节上的修订和严格的执行。为什么要第一时间公布明确的评分规则? 因为:

  1. 规则不明确,教师就不清楚助教会怎样评分,设计题目的时候对于一个题目的难度、周期和重要检查点会少了一个重要的参照点。
  2. 规则不明确,助教在评分过程中便会拿捏不准,不知道基准在哪,怎样使用工具。
  3. 规则不明确,学生会找借口,寻找规则的漏洞,容易滋生南郭先生。

阶梯分布

那么,明确了评分机制的公布点、修订点以及执行点之后,我们就要讨论评分机制本身如何设计更合理。《构建之法》在【给任课老师和助教的建议】一节里对此有充分的讨论,提出应该建立简明公开的原则:

把每次作业的表现分为N档:

  • 最优秀的几个同学得满分
  • 第2档的同学得1/2的分数
  • 第3档的同学得1/3的分数
  • 依此类推...
  • 迟交的作业0分
  • 不交作业倒扣分

传统的【大家都能及格】的分数分布看上去皆大欢喜,实则对优秀学生极不公平。根据上面的机制,可以在每次作业布置的时候,都重复贴上以下内容:

## Deadline:
2017-3-8 12:00AM,以博客发表日期为准。

## 评分基准:
- 按时交 - 有分,检查的项目包括后文的N个方面
    - 题目要求
    - 代码提交
    - 博文规范
    -
- 晚交 - 0分
- **迟交一周以上 - 倒扣本次作业分数**
- 抄袭 - 0分

## 题目要求
...
## 代码提交
...
## 博文规范
...
## ...

每次都有明确的截止日期和具体要求,这样就能实现清晰明确的评分规则的目的。 参考下面的实际例子:
http://www.cnblogs.com/happyzm/p/6472120.html

累加映射

例如,具体到软件工程这个课程上,《构建之法》里的分数设计是这样的:

原始总分=
  平时成绩
+ 个人成绩
+ 结对项目成绩
+ 团队项目Alpha成绩
+ Alpha阶段个人贡献分
+ 团队项目Beta成绩
+ Beta阶段个人贡献分

总分=原始总分线性映射到百分制到【100..50】这一区间。对于研究生可以考虑映射到【100..60】这个区间。一般来说,这几个不同阶段的分数占比不同,原始总分由如下构成:

  • 个人项目50分(博客+项目代码)
  • 结对项目100分(博客+项目代码)
  • 团队Aalpha满分200分,
  • 团队Aalpha 50分的个人贡献分
  • 团队Beta满分200分
  • 团队Beta50分的个人贡献分

详细展开请参考这份精细的设计:http://www.cnblogs.com/SivilTaram/p/5656582.html

注意:此处建议使用项目,而不是作业,这在概念上是有差别的,项目是持续开发的,有更长生命周期的,是主动性的action。作业则可能是短周期短,被动性的task。因此:

课程有项目 (个人,结对,团队), 项目有作业, 作业分为代码作业,和博客作业。

评分工具

上面的公式,助教可以建立一个Excel表格,通过线性映射公式,自动化计算。例如

学号 个人项目1 结对项目1 案例分析 团队项目Alpha 团队项目Beta 原始总分 总分
001

具体的项目次数由教师、助教协商,例如,有些学校在重要节点之间插入一些适当的工具操作练习。练习比作业的权重小,比如个人项目是50分,练习只有10分。但是练习可以目的明确地训练某个具体工具的使用,比如:

  • 数据库建模工具
  • UML里画一个UserCase
  • Git的操作
  • IDE的安装
  • 思维导图的练习...

单次项目

具体到操作里,教师和助教还会有一些不明的地方:一次作业的内容上如何评分?可以采用和整体一致的方案:针对一次作业的checklist做分类评分后累加映射,我们直接看表格:

学号 题目要求 代码提交 博文规范 工具使用 单次原始总分 单次总分
001

这是一个子表,子表里对单次作业的checklist做分类评分,分类评分的时候,可以累加每个单项分数后计入单次原始总分,线性映射到单次的分数范围(例如,团队Alpha是200分)。同样的,可以通过Excel公式做自动计算工作。教师和助教可以协商checklist的权重。

另外,针对团队项目这样细节比较复杂的,设计单次作业每个单项分数的时候,也可以每个单项按10分去给,然后乘以每个部分的权重,映射到单次分数,可以看作是一个评分放大镜

截断问题

评分规则会遇到边界问题,在实践中会有下面两种特殊情况,特别是存在一些特别拖后腿的同学的时候:

  1. 总分是负分
  2. 总分很低,虽然不是负分,但分数太低,如果以这么低的分数作为 MIN ,则总体分数会集中到80以上。

这两种情况如果也参与映射,显然不合理,要怎样解决呢?在教学讨论中,@SoftwareTeacher建议如下:

第一种方式,在不改变映射规则的基础上,存在如何抛弃那些特别低分的同学的问题, 以及各种项目得分比重是否合理的问题。教师和助教可以根据具体情况决定,例如:

  1. 原始总分是负分的直接不参与线性映射,直接映射为0分。
  2. 原始总分很低的,和其他同学明显存在间断的,也不参与线性映射,在0-50分之内选取合适的范围映射。

第二种方式,改变映射规则,改为先映射, 再累计的评分方式。具体来说,是这样的:

  1. 规定个人项目占10分, 结对项目占20分,团队的alpha/beta 各占35 分。 加起来就100 分了。
  2. 现在我们把所有人的个人项目的原始分(可能有多个个人作业)做单变量的线性映射:
    • 最高分 -> 10 分
    • 其它分数按 【最高分/10分】的比率来映射(负分就映射到0 分)。【score=orign_score*max_orign_score/10 】
  3. 把各个阶段的分数映射完之后,再加起来。

这个做法也有优缺点(Pros and Cons):

  1. 好处是不太用考虑 “从哪里截断原始分的映射” 这个问题。这个转换没有下限, 所以不用考虑原始分的下限应该在哪里。
  2. 坏处是这样通常最好的同学不会得100 分(除非他每一项目都是最高分),而且在课程中不能看出大家映射的得分, 没有能够给大家直接的感觉,以及显示大家你追我赶的数据。

以上两种针对截断问题的解决方法,提供给教师和助教在课程开始设计评分规则的时候选择。

评分展示

助教在截止日期时,及时发布评分博客,评分博客由多个部分构成,例如下面这个组合:

  • 题目:给出教师布置题目的原始链接
  • 项目完成情况:简要说明总共多少人,提交的人数,未提及的人数
  • 总得分映射到百分制的排名:这是一个根据映射分做的柱状图,也即到目前为止的得分排行榜
  • 得分情况:包含了每次项目原始分,累加原始分,最后映射分的一个表格
  • 评分标准:详细列出本次项目的评分标准
  • 助教想说:助教针对本次项目提交情况的综合分析和建议
  • 评分明细:本次项目评分明细的子表

完整的例子请参考:http://www.cnblogs.com/schaepher/p/6582306.html

其他课程

有的教师认为只有软件工程课程才适合这样评分。其实,如果是编程语言课,除了在环节设计上不同之外,其他的设计都是同样适用的:

  • 简明公开
  • 累加映射
  • 严格执行

checklist

首先,分数的设计机制,也能倒推在题目的设计上。设计题目的时候,教师和助教就需要对那些模糊的地方进行细化,对难度超过学生水平的地方做拆分,否则学生因为觉得模糊或困难而都不做作业,或随便应付,便无法达到有效训练的目的。

其次,设计checklist的时候,要有区分度。不能所有的条目都平均分配,这就涉及到对一个环节里哪些知识点、哪些方法是重要的,是突出强调。以及,设计这些条目的目的是什么?还是一样的道理,条目设计要有阶梯分布,检查的时候要注重形式和内涵的契合,例如,要求用思维导图,但是要看他用思维导图解决了什么问题,是否为单个环节的最终目标服务,设计的条目文本最好也能恰当表达这层意思。

第三,要回归相关课程的本质。例如对于软件工程,“还是要回到软件工程的本质, 例如画 UML 图, 有什么用? 画了有人看么? 给谁看的? 代码变了,UML 要跟着变么? 软件工程最后的产品是代码, 那么中间产生的各种文档的目的是啥?”(--xinz)。这样在设计checklist和评分的时候,可以有的放矢。

技术支持

最后,博客园的班级博客在评分工具,在技术上也许可以对此建模,提供工具支持。

posted @ 2017-03-05 17:05 ffl 阅读(...) 评论(...) 编辑 收藏