Undergraduate Capstone Open Source Projects

Grading Schemes at a Glance

Posted by Greg Wilson on 2009/11/05

Here are links to each team’s final grading scheme:

I think that writing these is a more important part of the software engineering process than most students realize. A grading scheme is the academic equivalent of a contract of deliverables: it’s the thing that you and I can put in front of a judge or some other third part if we disagree over whether you’ve delivered what I thought was promised.  Some parts of these grading schemes, like 10% for playing well with others, don’t show up in such contracts because they’re just assumed: if you don’t play well, you don’t keep your job [1]. Many of the rest, though, are exactly what I’d expect as a consultant: feature X, able to do Y, tested by Z.  I’ve experimented in my regular software engineering course with having students write their own assignment specs, and the more I do it, the more important I think it is. I’m curious to know what the students themselves think…

[1] Unfortunately, this often isn’t true: I’ve worked beside people who were awful human beings, but somehow never got fired. There are lots of reasons why this happens; it’s a good subject for a future blog post.

2 Responses to “Grading Schemes at a Glance”

  1. Severin said

    I agree, learning how to specify deliverables is important. It’s easier for me to specify deliverables in terms of software than deliverables in terms of academic success, though. At least the way we did it for UCOSP.

    The latter very much depends on where the instructor wants to put the focus on. Is it process or deliverables? Is it something else? If I’d come up with a grading scheme including which is worth what and the instructor agrees, *I* am defining the what *and* the focus. Is this what’s desired?

    Suggestion: Say you’d agree on a set of criteria first (no weighing of criteria, yet). Then, I as a grader would put down the weight. This way both parties know what is to be delivered and where the focus should be on in getting to the deliverables. What’s more, it’s similar to what most likely happens between a software development shop and a client. First, you specify the what (with the client). Then, the client sets priorities.

  2. Bill said

    The other issue with this sort of a scheme is that roles tend to shift in software. If you work for a pencil making company, you are probably going to make a lot of pencils, and the approach is likely to be consistent. In proprietary software dev, however, people tend to move around more. In my case, the last month has seen me work on a variety of tasks that make my grading scheme only partially relevant (more reviews, less code, language translation, packing the new release, presenting at RIA, etc.).

    That said, I wouldn’t get rid of the concept at all, there’s no doubt that in those moments of “now what”, it’s helpful to reference something like this.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: