Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!dogie.macc.wisc.edu!uwvax!rang From: rang@cs.wisc.edu (Anton Rang) Newsgroups: comp.edu Subject: Re: CS education Message-ID: Date: 10 Nov 89 09:22:02 GMT References: <11064@cbnews.ATT.COM> <6961@hubcap.clemson.edu> <3152@hydra.gatech.EDU> <1049@scotty.Atlanta.NCR.COM> Sender: news@spool.cs.wisc.edu Organization: UW-Madison CS department Lines: 61 In-reply-to: kcby@scotty.Atlanta.NCR.COM's message of 8 Nov 89 13:17:26 GMT In article <1049@scotty.Atlanta.NCR.COM> kcby@scotty.Atlanta.NCR.COM (K. C. Yakemovic) writes: >I think that maybe the 'common ground' between what industry needs and what >computers science research needs may lie in the area of teaching students >how to > > a) take a problem and figure out the (relevent) unknowns > b) how to find the answers to those questions > c) how to communicate what they are thinking > (to other people or to machines). Two great things I was lucky enough to have at my undergrad school: 1. A software engineering course (5 years ago, even). Every quarter, the teacher talked to groups on campus to find some semi-real world problem (though small enough to be feasible for the class to do in a quarter). She gathered some of the initial information, gave it to us as a group, and basically told us to write a program which would solve their problem--the class as a whole, not individuals or small teams. We had to learn to work in groups, how to communicate between groups of programmers (and with the users, when we had questions), etc. Our program nearly worked at the end of the quarter (though it still had bugs, mostly misunderstandings between teams). The important things which the course taught, I think, were: (a) Problems don't come with complete specifications; you have to get clarifications from people who are not always very computer-literate. (b) Working in large teams (30 people in the class; we broke up into 6 subgroups of 5 people each) is difficult. Communication is very important; misunderstandings are a nightmare when putting the final version of the program together. (c) Clear specifications for what modules do and how they interact are very important. I found this course to be one of the best I've ever had, though it was definitely frustrating at times. (For the curious, the project during the quarter I took the class was writing a program to keep track of investments made by members of an investing club on campus, not unlike keeping track of shares in a mutual fund.) Unfortunately, the next year the teacher retired, and the class started becoming watered-down (there had been complaints about how much work it was). 2. An independent-study program where area companies provided some real-life programs to the math & CS departments. Students could work on these for independent study credit. This was sort of like an internship, without having to miss school (though without pay). Anton P.S. Any others ever run into software engineering courses where the whole class writes something? I've mentioned this to a few people, and they usually say it can't be done! Worked in my case, anyway.... +----------------------------------+------------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | | University of Wisconsin--Madison | | +----------------------------------+------------------+