This sounds almost exactly like our senior-level "software engineering" course (CS445, I think?) at UAB (http://www.uab.edu/).

A "guest lecturer" (usually the same guy -- a UAB grad and founder of a local medium-sized consulting firm) was in charge of the class, and after a brief overview of what the class would entail, we were instructed to group ourselves into teams in charge of Requirements-gathering, Implementation/Interface design, QA, Documentation, etc., etc. Each 2-3 weeks, we'd focus on "the next step" of the methodology/lifecycle, while the students responsible for that piece of the puzzle would work together and (eventually) produce whatever deliverable was appropriate...

I don't recall how or why, but somehow I ended up as the "Project Lead" -- so I, and my unwitting teammates, found ourselves stressed for the entire quarter, as we were ultimately responsible for taking whatever our classmates "spat out" and presenting it to the Prof (the "Client" for sake of the project). The rest of the "teams" simply did whatever was required of them (eg, preparing a requirements document, programming a prototype, etc) and then took a few weeks off, after the fire was no longer under their respective asses. :)

The key to all of this -- well, *keys*, because I think there were probably two major reasons why this class stuck with me through the years -- were:

(1) The "outsider" as professor/client/judge was a useful model to prepare us for the real world... Here we were, a class of almost-graduates, and yet our respective development backgrounds were almost completely restricted to batch-style, command-line, C/C++ development in UNIX environments. The "Customer" (like any "real" customer, I suspect) didn't care *how* the project was completed, but he sure as hell wanted a non-command-line user interface...! Add to that the fact that he wanted us to interface with a piece of software completely foreign to most of us (Microsoft SourceSafe) -- and it was very obvious, very quick that Visual Basic or VC++ was a much better tool for accomplishing what he wanted done (in the timeframe provided).

The "client" didn't care/understand that we didn't know how to use Microsoft's APIs, or that none of us had ever even poked around with SourceSafe or VB....the assumption was that (as soon-to-be-graduates) we could figure out what the best tools were, teach ourselves those tools, and put the solution together from scratch, because that's what would be expected from us "out there."

(2) The second aspect that made this thing work was also the most controversial: Either the whole class passed or the whole class failed... So even if you were part of the "Requirements Team" and you finished your part of the project a month ago--you were still at the whim of whatever the "Development Team" churned out on the last day of class... If your part was completed correctly, you were still dependent on *all* of your classmates pulling their fair share.

The reason why this was "controversial" -- while some of us argued (and worried) throughout the quarter that an "everyone fails" verdict would be unfair, a small group of us (myself included) suspected that this result would actually never be allowed to happen... You see, for most of us, this was our *last* quarter before graduation -- most of us were already job-searching, or (like me) had already been accepted into grad school at this point.

But completion of this class (with a 'C' or higher) was required in order to graduate with a CS degree....and the class was offered only once every 2-3 quarters or so. So, at least in theory, you could do your job A#1, 100%, and still find yourself having to hang around campus for another 6 months or so--because some idiot in QA failed to sufficiently "impress" the teacher, or whatever.

Again, many of us suspected that the professor wouldn't hold tight to his "everyone fails, everyone passes" mentality if there was an obvious fuckup down the line that the rest of us clearly couldn't be held responsible for---but it made for some stressful nights/days/weeks/etc, I assure you... It would have been an interesting case study, actually -- because in the end there *were* a number of students who weren't pulling their weight, and we (as a class, or a "team," or whatever) had to pull together to either peer-pressure/encourage those folks appropriately...or reassign the work to someone else, or something like that.

AH, now I remember how I ended up being stuck with the "project lead" moniker... I think the entire "project management" team, in fact, eventually consisted of all the students who were just about to graduate -- the ones who had the most to lose if someone managed to tank the class. :) I suppose that of all the worry-wort, bitchy-types who were looking over everyone else's shoulders, I was the most bitchy/worry-wort-ish. :)

Anyway, the (admittedly longwinded) point here is this -- though I doubt the professor would have actually held back half of the class just to "make a point" or whatever: The "sense of urgency" that was created by this *Need* to get everyone working together -- causing us "management types" to have to learn to find ways to encourage students who were just sitting on their asses, reward those who were going above and beyond, etc., -- without this, I doubt I would have remembered that class (or the various lessons) as vividly...

I mean...when you have "senioritis," I imagine it would be pretty easy to just sit back and ignore everything except the stuff specifically regarding your "piece" of the final project... But that assumes you can just trust everyone to do their parts, too -- and that you won't eventually need to "step in" and do their parts for them! It didn't take long, at least in my class, to realize this was a bad, bad, bad assumption. :)