软件工程课的分数系统，和打分方法
考考考，老师的法宝；分分分，学生的命根。
以《构建之法》为核心的软件工程课已经在全国几十个学校开展了好几年，由于采用 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：每个软件项目都可能是很好的软件工程案例， 但同学们对于其他团队的项目不太关心， 只是最后评审的时候看看别人软件的界面，草草给一个分数，浪费了很多的学习机会。
解决：把点评做成有趣的场景， 让同学们专注于分析各个项目的成功的可能性， 让同学们自己用批判的眼光分析问题，跟踪项目的进展。
具体方法：
- 让所有团队根据 NABCD 自己审核一下自己的团队项目，把 NABCD 元素加到自己的团队博客的项目说明中， 同时说明预期的 “项目发布后3天的用户量”。 可以给机会让同学们修改团队项目，所有团队发表博客。
- 然后， 所有团队写一个博客， 依次评价其他团队的项目立项 NABCD， 排名次 （名次没有并列）。 助教统计所有名次， 名次最低的团队必须做出重大修改， 包括选一个新的项目。
- 可以用风险投资做比喻 ， 每个学生都是有钱的风投资本家， 要给这个班级的所有项目投资， 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 分），取决有多少团队参加了评比，阶梯要拉开，也要保证付出了努力的团队获得相当于及格的分数。 也可以分类评比，例如，所有自选项目在一类，所有做学校老师布置的项目在一类，所有 “微信小程序”类型在一类，等。
