Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!haven.umd.edu!uvaarpa!vger.nsu.edu!g_harrison
From: g_harrison@vger.nsu.edu (George C. Harrison, Norfolk State University)
Newsgroups: comp.edu
Subject: Re: Computing in the Real World
Message-ID: <1106.28658302@vger.nsu.edu>
Date: 24 Jun 91 09:28:34 GMT
References: <446400001@inmet> <11209@castle.ed.ac.uk>
Lines: 50

In article <11209@castle.ed.ac.uk>, gvw@castle.ed.ac.uk (Greg Wilson) writes:
> In article <446400001@inmet> justin@inmet.inmet.com writes:
>>Here's a class that I've never
>>heard of, that I would consider mightily useful:
>>
>>COMP 106
>>Computing in the Real World
>>
>>In this 15-person seminar, the entire class will act as a team. We will
>>undertake a relatively large-scale computing project, to be completed by
>>the end of the semester. Co-operation will be stressed; the project will
>>be considerably too large for any subset of the class to finish on its
>>own. Formal methods of dealing with large software problems will used.
>>Grades will be based upon ability to work in a large, non-competitive
>>environment.

I have taught such a course (junior-level) for four years.  I have never been
completely satisfied with the content or the outcome.  We really don't have the 
time to do a formal design.  I've found that a complex problem can not be
adequately worked through completely in our 15-week semester.  I've generally
moved toward easier projects and stressed the quality of design, etc.  My
lectures tend to stress the psychology of programming - in a group (about 2
weeks worth of lectures here).

> Another way to accomplish the same thing is to pick a project which one
> person can do relatively easily in a single term, such as writing a
> simple interactive diary.  The project is done in three stages: design,
> implementation of utilities, and then final implementation and
> documentation.  Everyone does the first stage, hands it in, gets marked
> --- and is then given *someone else's* design, and told to ipmlement the
> [etc.]

This method appears to stress the real-world situation of moving from a 
document of "foreign" makeup while having some knowledge of the problem 
domain.  However, one looses the group qualities of the project.  A compromise
that may leave one unfinished at the end of the semester is to have a 2-team
course where the teams do requirements, design, implementation, and testing
switching off at all stages.  I've done this, and it  works.

Any instructor should be prepared to First Aid to any broken relationships and
especially be prepared to act as "Program Manager."... don't be afraid of
removing an offending student from a team, etc.

> Greg Wilson
> =-=-=-=-=-=-=-=-=-=-=-=-=- Edinburgh Parallel Computing Centre
> gvw@castle.edinburgh.ac.uk

George C. Harrison, Professor of Computer Science
Norfolk State University, 2401 Corprew Avenue, Norfolk VA 23504
Internet:  g_harrison@vger.nsu.edu    Phone:  804-683-8654