A senior design course for computer science

Reviewer: Grady Gaston Early

Put on your software engineering hat. Imagine a one-semester programming project given to a relatively large class. Divide the project into three parts: I/O system, computation, and file structures. Divide the class into four teams (Red, White, Blue, Gold) each with three subteams (A, B, C). Design Phase—Each color team designs a solution to the overall problem; each subteam works on a different part of the problem (e.g., the A subteams might design the I/O system, the B subteams the computation, and the C subteams the file structures). The subteams collaborate to solve interface problems. Implementation Phase—The color teams swap designs. The subteams change problems (e.g., Red A might implement Blue C's design). Testing Phase—The Color teams swap again; the subteams move again. Now, White B tests the implementation produced by Red A from the Blue C design. The author recounts his experience with this team concept in his senior design course. There were the usual intrasubteam personality problems. There were even some intersubteam clashes. The author concludes, however, based on this experience and on student evaluation and industry feedback, that the approach is beneficial: he should; it is. One wishes, however, that he had spent a bit more time polishing his paper. The typos are distracting; the sentence which begins on line 5 of p. 132 is unintelligible; and the general language level is pretty poor.