Assignments

For due dates that fall on class meetings, assignments are due at the start of class. Otherwise they are due at my office at the time specified. Don't forget:

• All assignments should have a cover sheet with name, class, assignment title, date. Plus TEAM NAME, if it's a team project!
• All sheets must be STAPLED. No paper clips, dog-ears, bubblegum, or spitballs.
• Programming Assignments: For programs that you submit electronically to me, a hardcopy submission is still always required! See the assignment spec for details.

Some projects are typically as team projects, in order to allow us to tackle cool and significant interface designs. This also supports our general Design4Practice philosophy of emphasizing training in teaming and project management as core features of our program.

Peer Evaluations. These provide insight for me into internal team dynamics: reliability, meeting attendance, active contribution and, of course, getting your fair of the work done. Here is the link to how the peer eval mechanism works. Simple but quite effective.

Dealing with non-performing members. Usually teams work great for CS477 projects, with all members psyched about the software they are inventing, testing and refining. But, on occassion, teams have problems with non-performing members. Learning to deal with this effectively and efficiently is an extremely critical professional skill, as it's not unusual in real life...except the stakes are higher then. To help shape this process, I've developed a "Guideline for dealing with non-performing team members", which focuses on how good team management can be used to avoid/repair problems...but also allows for "firing" team members in truly stubborn cases.