As you may have noticed, the CS Capstone sequence (CS476, CS486c) is quite different from other courses that you've taken during your undergraduate career. There is less structure overall, you are asked to take much more responsibility/leadership in your team's project as well as your learning from that project, and the grading is less black-and-white than your average math class. In this page, I've attempted to list some of the more common questions that Capstone Faculty have been asked over the years to try to help you get the right "mindset" for success in Capstone.
QUESTION: Capstone feels less structured than normal classes, and that is making me feel uncomfortable. Why not structure it more: weekly assignments, homeworks, readings, etc.
ANSWER: In fact, the Capstone course has been very carefully and strategically designed...only not as a "standard course", but to mirror what you will encounter in the real world, either working in a project team for a company, or as (more ambitiously) as a successful software consultant. In the real world, there are no "assignments" or "grades"...everything revolves are (a) keeping the client happy and your reputation strong, and (b) doing things efficiently to maximum your time-value equation. Of course, Capstone *is* still a course...so, yes, we have to have some graded deliverables to measure the extent to which your are mastering the overall learning goals of effective professional communication, teaming, and project planning and management.
QUESTION: My friend is on a different team and his/her team mentor seems a lot less demanding than ours. [Or close variant:] The client for my friend's team seems a lot less/more demanding than ours. [Or close variant:] Our project seems more difficult that project <x>.
ANSWER: The only possible answer is: this is just like the real world. Clients vary, and project difficulty can not always be predicted in every detail. And yet, regardless of what you get, you need to dig in and get the project completed successfully. In fact, very strong efforts are made to fine-tune and "normalize" projects during the project collection phase. The Capstone Organiser works with every single client proposing a project to make sure the project is realistic and, more importantly, adjust the scope of each project to contain "comparable challenges". This means that "easy" projects are redesigned to increase scope and complexity, while overly ambitious projects are scaled down and/or split into two potential sequential capstone projects to be done in successive years. Even so, it's impossible to predict precisely what skills a team will bring to a project (making it less/more challenging based on their prior knowledge), or what detailed difficulties and challenges may be encountered during design/implementation.
As far as CS faculty mentors go, each of them brings his or her own standards (probably based on their own professional experiences) to project supervision. In general, it is the *the mentor's job* to train your team to the highest professional standard...to teach you best practices and standards of quality that will ensure that you get immediate traction and succeed in the real world when you graduate. That said, we make strong efforts to "get mentors all on the same page" regarding expectations for teams. Extensive resources have been developed, included (a) grading guides to remind mentors what elements to look for in deliverables, (b) "how to grade" documents that discuss learning goals for specific assignments and how these drive things to look for in evaluating them, and (c) copies of previous years' deliverables, marked up and graded, to give them an idea of granularity and level of feedback to shoot for in annotating your team's work. Mentors also meet and have running conversations within their "team" to discuss evaluation metrics and "never seen this before" events, in order to arrive at some joint understanding. ALL OF THAT SAID, each project is different, and therefore mentors are ultimately responsible for assessing the quality of each of their team's efforts.
QUESTION: I've heard that mentors get a "grading guide" for deliverables...and some of them even send them to their teams. Can't we just post the grading guides for each deliverable? Then we'll all know exactly what do do...
ANSWER: There are number of good answers here; let's just go through them one by one. First, there is no "secret" information in a grading guide. These are just (see previous question) aimed at remindering busy mentors of roughly the topics/discussions/coverage they should look for in the deliverable. What this means is that they are just a compact summary of exactly what is outlined in more detail for teams in the assignment statement. We do ask mentors to "read the assignment statement"...and most of them do...but they don't read it again every year. Thus, the grading sheets just sort of reminder them of expected topics. Which leads to the second point: the grading sheets are (a) not particularly detailed and (b) not prescriptive in any way. Each project is different, so it would be impossible to come up with a single standard recipe for a detailed grading sheet. Thus, at best the grading sheet provides a convenient place for mentors to take notes on how well various topics were covered, which forces them to think at a more detailed level than just reading the document as a whole and say "well, my overall impression is 'above average' ". This results in better feedback to the team, i.e., "the document is 'above average' because...<lots of detailed plusses/minuses>". Finally, posting the grading sheets could lead to the misinterpretation (by teams) that they are somehow "a recipe" --- just stick in stuff on the grading sheet, and you're good. The assignment statements are MUCH more detailed and, importantly, often discuss the "rhetorical goal" (why you are discussing something). In the end, the goal of a technical communication is clear and complete communication....and there is no recipe for this. Better to understand what you are trying to accomplish in your argument flow and why than to get sucked into believing there is some standard recipe.