TITLE: Planning and the Project Course
AUTHOR: Eugene Wallingford
DATE: January 14, 2008  2:25 PM
DESC: 
-----
BODY:
After "worrying out loud" in a
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2008-01.html#e2008-01-08T17_05_10.htm">
   recent entry</A>,
I suppose I should report that our faculty retreat went well.
We talked about several different across over the course of
the day, especially long-term goals, outcomes assessment,
and tactics for the next few months.  The biggest part of
our goals discussion related to broadening our reach to
more students who are not and may never want to be CS majors.
That includes
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2007-12.html#e2007-12-18T16_40_07.htm">
   science majors</A>
but also social science, business, humanities, and education
students.

While discussing how to determine whether or not our courses
and programs of study were accomplishing what we want them
to accomplish, we had what was in many ways the most
interesting discussion of the day.  It dealt with our
"capstone" project course.

In all of the CS majors we offer, each student is required to
complete a "project course" in one of the areas of study we
offer.  This will be the third course the student takes in
that area, which is one way that we try to require students
to gain some depth in at least one area of computing.  When
we added this requirement to our programs, the primary goal
was to give students a chance to work in teams on a large
piece of software, something bigger than they'd worked on in
previous courses and bigger than one person could complete
alone.

Some of our project courses are "content-heavy", in that they
introduce new topical content while students are working on
the project.  The
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2007-07.html#e2007-07-09T19_28_38.htm">
   compilers course</A>
is an example of such a course; "Real-Time Embedded Systems"
is another.  Others do not introduce much new content and
focus on the team project experience.  "Projects in Systems"
(for the OS/networking crowd) and "Projects in Information
Science" (for the database/IR crowd) are examples.  Over the
years, as we've broadened our faculty and the areas we teach,
we've added new project courses to the broaden the type of
experience offered as well.  In some of these courses, code
is not the primary deliverable.  For example, in "Software
Testing", students might develop a testing environment, a
suite of test plans, and documentation; in "User Interface
Design", students focus on developing a front end to an
existing system or to a lighter proof-of-concept back end
that they write.  Some of these courses implement looser
versions of the original idea in other ways, too.  My compiler
students usually work in pairs or threes, rather than the
four or five that we imagined we designed this part of the
curriculum over a decade ago.

Our outcomes assessment discussion turned quickly to the
nature of a project course and in particular the diversity
we now offer under this banner.  We can't write outcomes
for the project requirement that refer to code as a primary
deliverable if, in fact, several courses do not require that
of students.  Well, we could, but then we would have to
change how we teach the courses -- perhaps drastically.
The question was, is code an essential outcome of this
part of our curriculum?

We faced similar questions as we explored the other elements
of diversity.  How much new content should a project
introduce?  Must students write prose, in the form of
documentation, etc.?  Should they give oral presentations?
If so, should these be public, or is an internal presentation
to the class or instructor sufficient?  What about the
structured demos that our interface design students give as
a part of an end-of-the-term open house?

I enjoyed listening to all of my colleagues describe their
courses in more detail than I had heard in a while.  After
our discussion, we decided for the most part to preserve the
rich ecology of our project course landscape.  Test plans
and UIs are okay in place of code in certain courses; the
essential outcome is that students be expected to produce
multiple deliverables across the life of the project.  We
also found some common themes that we could agree on, even
if it meant tweaking our courses.  For example, whatever
kind of presentation our students give at the end of the
project, it should be open to the public and allow public
questioning.  We will be writing these outcomes up more
formally as we proceed this semester and use them as we
evaluate the efficacy of our curriculum.

I was impressed with the diversity of ideas in practice in
our project courses.  Perhaps the results of this discussion
were interesting mostly because we have had this sort of
conversation in a long time, at least not as a whole faculty.
It's funny, but "shared knowledge" isn't always what we think
it is.  Sometimes we don't share as much as we think we do,
at least of the surface.  When we dig deeper, we can find
common themes and also fundamental differences, which we
can then explore explicitly and in the context of the shared
knowledge.  It was neat to see how each of us learned a little
something new about the goals of the project course and left
the conversation with an idea for improving our own courses.
My compiler students certainly don't write enough technical
prose in my course, certainly not as much or as structured
as students in some of the other project courses.  I can make
my course stronger, and more consistent with the other options,
by changing how I teach the course next time, and what I
require of the class.

Our retreat didn't answer all my questions about the direction
of the department or our strategic and tactical plans.  Only
in the fantasy of a manager could it!  My job now is to take
what we learned and decided about ourselves that day, help
craft from that a coherent plan of action for the department,
and begin to take concrete actions to move us in the direction
we want to go.  I hope that, as in most other endeavors, we
will do some things, learn from the feedback, and adjust
course as we go.
-----