home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.edu:2275 comp.software-eng:5212
- Path: sparky!uunet!news.larc.nasa.gov!grissom.larc.nasa.gov!kludge
- From: kludge@grissom.larc.nasa.gov (Scott Dorsey)
- Newsgroups: comp.edu,comp.software-eng
- Subject: Re: Class Project For Software Engineering Course
- Date: 5 Jan 1993 02:05:41 GMT
- Organization: NASA Langley Research Center and Reptile Farm
- Lines: 22
- Message-ID: <1iaqdlINN8ac@rave.larc.nasa.gov>
- References: <1ia3e0INN9m5@aludra.usc.edu> <1993Jan4.162437.19108@hemlock.cray.com> <C0CxvL.G3r@cs.uiuc.edu>
- NNTP-Posting-Host: grissom.larc.nasa.gov
-
- How about a two part project:
-
- A. Give the students a big piece of code. Something huge and monolithic,
- with lots of GOTO statements, single-letter variables, memory overlays,
- and odd use of arrays (writing past array bounds to modify scalar
- variables, etc.). You know the kind of code I mean. Everybody has some
- somewhere (and if you don't, I'll be happy to give you some). Assign
- groups of two or three people their own part of the program. Tell them
- about some problems with the code, and ask them to fix them.
-
- B. Three weeks later, when they have not accomplished anything, give them
- a definition of how the program is supposed to work and ask them to
- write one. Again, each group will be in charge of a small portion, but
- they don't have to be the same ones (because the program structure will
- probably be completely different).
-
- This will definitely be one of the better teaching exercises. I see a whole
- lot of folks who graduate and are shocked when they enter the real world and
- see how bad some of the code out here is. Let them know that it can be
- amazingly bad, and then show them that it doesn't have to be. Lead the
- fight against cryptic code.
- --scott
-