软件工程课的分数系统,和打分方法

考考考,老师的法宝;分分分,学生的命根。
 
以《构建之法》为核心的软件工程课已经在全国几十个学校开展了好几年,由于采用 Learning by doing (做中学) 的方法, 同学们通过实际的作业获得分数,逐渐累积并转换为最终分数,而不是等到期末的考试得到一个分数。 这种方式有很多好处,但是也引起一些困惑,每次开课的后期,大家都会对分数系统有一些疑问。 这里讲一些分数系统的设计理念,和如何对付一些新问题 (有很多同学根本不做作业怎么办, 同学开始浪荡,最后想及格怎么办, 异常差的学生导致分数系统的映射有偏移怎么办...) 。 这个博客就是想解答这些问题。

分数系统设计的理念:

- 每次发表的作业都有分数,在学期的任何时候,都可以根据公式,从已有的分数中推算出所有学生的期末成绩 (这样学生就不会说:啊老师!我从来不知道我有不及格的风险啊...)

- 奖勤罚懒,分数要拉开优秀作业和一般作业的差距,迟交 0 分,过期不交作业,倒扣分。

- 鼓励交流。作业不是一次交了就完事,再也不看, 而是学生和老师的一个交流途径。 老师和助教给学生博客的评论,学生应该积极回应。 回应就有分数,不回应就会被扣分。 

  师生要互相质疑,问答,就像培根说的:

        真理之川從它的錯誤之溝渠中流過;像萌芽一般,在一個真理之下又生一個疑問,真理疑問互為滋養。

- 分数规则对所有人开放,尽量保持简明。 用Excel 表就和一些简单公式可以统计好。
- 允许学生花额外的努力获得更多分数。
- 最后的分数是个人努力和全班同学相对排名的体现, 但是少数学生的异常情况 (分数特别高、特别底)不会对其他同学的分数产生大的影响。 

这个分数系统是建立在:“全班同学都至少付出了一定程度的努力” 的假设上的。如果少数同学什么作业都不做,那么这个分数系统不是为这样的学生设计的,这些同学不必参加后面提到的映射等操作。 
 

《构建之法》里的分数设计中的概念和词汇定义:

学生要做项目(个人项目,结对项目,团队项目),项目有作业, 作业分代码作业和博客作业。 每个作业都会打分,基本上每个作业满分都是 10 分,最低分是 (-10) 分。   学生在团队项目中要做两次阶段性的展示(alpha 发布 和 beta 发布),这两次发布非常重要,体现了一个团队一段时间的努力成果。团队通常是写一个博客,把展示内容都组织成为一个博客,同时团队可以现场展示他们的成果。这个作业的满分是 100 分。  

分数转换的流程是: 

    原始分数 --> 累积并映射到各自区间 --> 归一化为百分制 --> 加上可选的个人附加分 --> 老师的调整 -->成绩单上的分数 

 

原始分数的累积和区间映射

原始总分= 
     个人项目成绩            (20%)
  + 结对项目成绩            (20%) 
  + 团队项目Alpha成绩    (25%)
  + Alpha阶段个人贡献分  (5%)
  + 团队项目Beta成绩      (25%)
  + Beta阶段个人贡献分   (5%)


个人项目成绩 (占原始总分的 20%) =

              每次作业成绩的累加,再把全班同学的最高成绩映射 20分,这个最高的累加分数到 20 分的比例为 R, 其他同学的成绩按 R 做映射。
              作业成绩累计是负分的同学,映射为 0 分。

              例如:三个同学 A, B, C 在个人项目中分别得了 50, 30, 10 的原始分, 这个项目的满分是20 分。 最高的原始分50 要映射到 满分20 , 比例是 50 / 20 = 2.5, 所以  R = 2.5

              这样我们就可以用 比例R 推出, B 得分=30 / 2.5 = 12, C得分 10 / 2.5 = 4

结对项目成绩 (占原始总分的 20%)= 每次作业成绩的累加,再把全班同学的最高成绩映射 20 分,这个最高的累加分数到 20 分的比例为 R, 其他同学的成绩按 R 做映射。
              作业成绩累计是负分的同学,映射为 0 分。

团队项目成绩 = 每次作业成绩的累加,再把所有项目组的最高成绩映射为 25 分, 其他小组根据映射比例做同样的映射。
              alpha, beta 两次团队项目同样处理,各占 25% 

个人贡献分 = 和个人项目成绩类似,最高分映射到 5 分,其余按比例映射。
              alpha, beta 项目同样处理

为什么要区间化?因为团队项目在进行过程中会有很多次作业(项目启动,需求,设计,WBS, 每日例会报告, 展现博客, 测试,复审得分...) 这个原始分会远远超过个人项目的原始分,这两种分数必须分别归类到各自的区间中,以保证各种努力在最终分数有适当的比例。

 

归一化

得到原始总分之后,原始总分要做一个归一化处理,回归到百分制。 原始分最高的获得100 分,其他人按照  最高原始分/100 的比率做相应的映射。这个方法和个人项目原始分映射类似。 

注:既然映射的参数是受到最高分的同学影响, 那么班级里有一个非常优秀的学生,他的原始分特别高,会导致其他学生的分数被映射得比较低,这公平么? 我们用软件业的浏览器市场做例子,原来的浏览器IE 是成绩比较好,但是后来班里面来了Chrome,Firefox 等学生,原始分最高的同学,映射到了100 分,遗憾的是,IE 不是最优秀的同学,那么IE 的最终分数就降低了,这有道理吧? IE 要获得高分,应该自己努力,而不是埋怨别的同学作业做得更好,对吧?

原来采用的是高限和底限都有的映射, 例如原始分分布是 [20 .. 90], 要映射为 [50.. 100], 这个两端都要照顾到的映射方式有一个巨大的缺点 -- 如果班级里面有一个较差的学生,那么其他人的分数就要被映射得比较高。  那么,为何一个同学的最终分数会受到班里面最差的同学的影响呢?  在软件市场上,最烂的软件不会影响优秀软件的市场占有率,对吧? 因此,在实验了几年之后,最低端的映射就不考虑了。 

那么,一些同学原始分低怎么办? 整体分数的分布比较奇怪怎么办?请继续看。

 

通过附加项目做最后调整

最后,每个同学有机会做额外的附加项目 (动机可能是:提高自己水平,获得更高分数, 避免不及格,等等), 个人附加项目分数的最高分是 10 分, 这样,如果有本科生同学的原始总分是全班最低的,映射为 50 分,那么,他可以通过挣这个附加项目分数的满分 10 分来避免不及格的命运。

附加项目做什么呢?例如,帮助老师做一些教学辅助工作,再做一个有难度个人项目,写深入的读书/论文笔记,等等。在学期过程中,和老师/助教有深入交流的学生(例如看博客的问答)也可以获得一些附加分数,这个由助教掌握。 

一些老师出于种种原因,还想加一个笔试环节。那么,笔试可以作为这个课程的附加分数,笔试的最高分映射为10分,当然,根据学校的要求和具体情况,笔试的最终分数也可以提高。 

 

分数分布奇怪怎么办

少数情况下,一个班的分数会出现奇怪的分布,例如,有一两个特别优秀的学生,他们得到非常高的分数,会导致其他同学的相对分数太低;或者学校对分数段的人数有规定,或者领导要求把某个不及格的分数变成及格(我听说过两次这样的情况)。

  把过于离散的分数分布变换到比较集中,靠近100 分:  把所有的分数都开平方,再乘以 10.  这个过程让所有非零的分数向 100 分靠近。

  把过于集中的分数分布变换到比较离散,远离100 分:  把所有的分数都和自己平方,再除以 10.  此过程让所有小于 100 的分数向 0 分靠近。

  

团队项目的展示评审阶段如何打分

为什么要研究各种打分方法,制定详细的规则?因为要解决实际问题,我们在实践中碰到什么问题呢?

 

问题1:同学们的团队项目往往拍脑袋就想出来,并没有很严肃地做各种软件工程的调查。中途拍大腿后悔, 最后拍屁股走人,项目烂尾。  
问题2:每个软件项目都可能是很好的软件工程案例, 但同学们对于其他团队的项目不太关心, 只是最后评审的时候看看别人软件的界面,草草给一个分数,浪费了很多的学习机会。  

解决:把点评做成有趣的场景, 让同学们专注于分析各个项目的成功的可能性, 让同学们自己用批判的眼光分析问题,跟踪项目的进展。 

 
具体方法:

  1. 让所有团队根据  NABCD 自己审核一下自己的团队项目,把 NABCD 元素加到自己的团队博客的项目说明中, 同时说明预期的 “项目发布后3天的用户量”。  可以给机会让同学们修改团队项目,所有团队发表博客。
  2. 然后, 所有团队写一个博客, 依次评价其他团队的项目立项 NABCD, 排名次 (名次没有并列)。  助教统计所有名次,  名次最低的团队必须做出重大修改, 包括选一个新的项目。
  3. 可以用风险投资做比喻 ,  每个学生都是有钱的风投资本家,  要给这个班级的所有项目投资, 10 个团队项目你只能投6 个,  你投哪些?   请列出你的选择。  有些同学们不是很想创业,做有意思的项目吸引风投吗?  这就让他们练习实际的风投。  例如, 同学可以对任意项目投资, 每个项目可以投 一元钱。    评审获得前三名的项目对应团队的同学就能得到当初投资的钱。  如果这个项目在学期最后没有进入前 3 名, 这个钱就归老师分配。  老师拿了这些钱做奖品, 例如:再分给那些投资了前三名团队的学生。

 

评审阶段的打分安排:

 

1) 每个团队写一个alpha/beta 阶段的总结展示博客 (不要写 PPT),具体要求请看老师的说明。有些项目暂时还没有实际用户,或者面临各种问题, 那团队可以深入分析失败的原因,并总结“我学到了什么软件工程的原理,获得了什么经验教训”,这也达到了学习的目的。 

2) 每个复审人看所有团队的总结展示博客,以及代码质量,实际测试结果, 决定名次(没有并列),说明项目的优点和缺点分析(见下表)

      谁来做复审人:老师,助教,每个团队选一个本团队的代表

                          团队博客列出团队的排名,和对这些团队的点评(不包括本团队)

      复审人看什么:

            - 基本要求:团队成员都到场了么(无理由不到的,要倒扣分),现场讲解、回答问题水平如何? 是否各个角色都有发言和回答问题的机会?

            - 软件的质量:解决原计划解决的问题了么,软件运行质量如何?用户有多少,用户反馈如何?

            - 软件工程的质量:代码在哪里? 代码能在新的机器上构建成功么? 软件的架构如何 (下表有更详细的说明)?代码可维护性如何?每日构建有么?

                                     项目如何管理的?燃尽图反映真实状态么?老师和助教的点评有回答或改进么?

      复审怎么做:

      a) 面对面集中做,老师和所有在场的复审人现场提问,排名次

      b) 不能面对面的,通过看博客和代码,博客评论交流的方式平均并排名次。 大家都是学过软件工程,做过项目的人了,评论要有点专业性,不能光谈感性认识 (“这个小组做的App 看起来还可以...”), 而是要点评这个产品和软件工程相关的地方,书上提到下面的公式: 

软件 = 程序 + 软件工程

软件(的质量) = 程序(的质量)+ 软件工程(的质量)

      

我们要好好测试一下程序的质量,给出明确的,定量的评定。同时我们要观察这个小组软件工程的质量(通过他们的每日例会,燃尽图,以及其它博客)点评他们项目的目标实现了么?项目的风险是如何应对的?找到用户的痛点并解决了么? 对主要和次要的需求是如何取舍的?如果换成我来领导这个小组,我会做什么不一样的事情?

有不少团队的项目看似功能都有,但是一具体使用就出现很多问题;当然还有不少团队项目具体功能不行, 但是项目成员号称:“我们的架构好!”, 一个软件的功能性特质比较好评判,那么那些 “非功能性” 的特质,如何评判呢?我们看看如下几个方面,它们也有各自的  “非功能性测试” (参见《构建之法》相关章节):

高性能

从测试的角度看:系统最快能有多块?支持最多的用户,能有多少?换句话说,系统必须满足预期的性能目标,在并发用户数(Concurrent Users)、并发事务数(Transactions per Second,TPS)、吞吐量(Throughout)等指标方面达到预估值,支撑使用人群的正常使用操作。团队项目考察:团队有测试数据或真实运行数据说明软件达到了哪些高性能指标?

可靠性 & 稳定性 & 可用性

很多软件是客户业务系统一部分,它直接影响到用户的经营和管理,客户希望软件在使用周期内长期稳定运行,这要求系统具有一定的容错能力。可用性是指系统在指定时间内的提供服务能力的概率值。我们一般采取集群、分布式等手段提升系统的可用性。我们不能认为所有软件都像一些消费类型的手机App那样 - 闪退多,重启一下就好。 团队项目考察:团队是否有压力测试,是否收集程序崩溃、闪退记录?MTTF 是多少?

安全性

用户的业务数据是具有非常高的商业价值,如果被泄露或篡改将会带来重大损失。安全性是软件系统的一个重要的指标,也是架构设计的一个重要目标。团队项目考察:软件是怎么保护用户隐私的?软件能防止外力入侵系统么?

灵活性 & 可扩展性

软件系统应该具备满足不同特点的用户群和目标市场的能力,更灵活。业务和技术都在不断的发展变化,软件系统需要随时根据变化扩展改造的能力。一个简单的例子:用户想把App 的界面都换成另外一种语言,软件如何做到?是要重启App,还是要下载一个不同的App? 一个稍微复杂的例子:一个团队号称做了 A大学校园周边的 “美食指南”App,如果让这个软件也支持另一个城市的 B大学的周边美食, 程序要全部重新写呢,还是只需简单换一些数据、配置信息就可以?我们软件工程经常讲的高内聚,低耦合就发挥作用了!团队项目考察:看源代码,分析它的模块化、内聚、耦合、可扩展性。

易用性

软件系统必须拥有较好的用户体验,便于用户使用。团队项目考察:请按照《构建之法》第十二章 “用户体验”的建议来测试易用性。

可维护性

软件系统的维护包括修复现有的错误,以及将新的需求和改进添加到已有系统。因此一个易于维护的系统对于用户提出的问题或改进,可以及时的实现高效的反馈和响应支持,同时有效降低维护成本。团队考察:代码注释、文档,代码质量。问自己:你愿意接受这样质量的源代码么?

经常有人说:“架构是系统非功能性需求的解决办法的集合”,如果同学们自称“架构好”,那就用数据来证明。

 

 
小组的名字和链接 优点                                     缺点,bug 报告(至少140字)

最终名次

(无并列)

team 1  ...

程序有什么具体的bug?

项目的目标实现了么?项目的风险是如何应对的?找到用户的痛点并解决了么?

对主要和次要的需求是如何取舍的?

源代码管理如何?

“非功能性质量”如何? 选择至少 3 个方面来测评

如果换成我来领导这个小组,我会做什么不一样的事情?

 
team 2  ...  ...  

 

 

3) 助教收集所有复审人的名次信息, 按平均名次排列, 并给予分数(再次强调:小组互相评名次,不打分,助教最后打分)。

4) 这个展示作业的满分是 100 分,其余名次按照阶梯递减(例如,每个阶梯是 10 分或 5 分),取决有多少团队参加了评比,阶梯要拉开,也要保证付出了努力的团队获得相当于及格的分数。 也可以分类评比,例如,所有自选项目在一类,所有做学校老师布置的项目在一类,所有 “微信小程序”类型在一类,等。

 

posted @ 2017-05-07 04:01 SoftwareTeacher 阅读(...) 评论(...) 编辑 收藏