Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!olivea!tardis!tymix!uunet!mcsun!ukc!edcastle!gvw
From: gvw@castle.ed.ac.uk (Greg Wilson)
Newsgroups: comp.edu
Subject: Re: Computing in the Real World
Message-ID: <11209@castle.ed.ac.uk>
Date: 20 Jun 91 14:53:44 GMT
References: <446400001@inmet>
Organization: Edinburgh Parallel Computing Centre
Lines: 44

In article <446400001@inmet> justin@inmet.inmet.com writes:
>Lately, I've been reading up on methodologies for analyzing and designing
>large systems (Yourdon, DeMarco, et al), and found myself thinking,
>"Geez, why didn't we learn this in school? ..." A couple of
>moments' thought revealed that you couldn't teach it in the traditional
>curriculum, because these methods are oriented towards *real* problems...
>
>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.

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
utility libraries needed for that.  Howls of anguish, broken friendships
--- lots of conversation like "how the hell could you have meant someone
to do this??" The marks for the middle third of the project are also for
how closely the work conforms to the original spec, not just how well it
works.  Then, of course, you roll again (choosing the next victim
randomly to avoid stealthy co-operation among friends), and hit them
with a spec they may not like, utilities that may or may not conform to
it (and may or may not work), and a deadline. 

Marking this is very hard, but if it's done in the second year of a
four-year program, one discovers that the third- and fourth-year
students are actually following those silly rules about modularisation,
design-before-code, and the like.

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