justin@inmet.inmet.com (06/15/91)
I don't know if this group is necessarily the right place to post this, but it seems like the closest, and I just *have* to get this off of my chest. 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? It would have been a lot more useful than most of the computer science I *did* get." And a couple of moments' thought revealed that you couldn't teach it in the traditional curriculum, because these methods are oriented towards *real* problems, with large groups of people, not the traditional classroom, where groups of co-workers are, at most, two or three strong. So I ask you, shouldn't this be rectified? 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. Has any such thing been taught at the college level? Seems to me that it might produce some more *useful* engineers... (The above is just musing out loud. If you have any concrete comments, please email them to me, as I'm not sure I'll have time to check back here in the near future...) -- Justin du Coeur Who's been learning this stuff the hard way... Random Quote du Jour: "and in the beginning there was nothing and then god said "let there be light" and there was still nothing. but you could see it." -- mark pfaff
Eric.J.Baumgartner@dartmouth.edu (Eric J. Baumgartner) (06/16/91)
In article <446400001@inmet> justin@inmet.inmet.com writes: > 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. > > Has any such thing been taught at the college level? Seems to me that it > might produce some more *useful* engineers... From the Dartmouth College course guide: CS 23. Software Design and Implementation Techniques for building large, reliable, maintainable, and understandable software systems. Topics include programming paradigms for real systems, systems programming tools, interfaces for both multi-user and workstation programming environments, software engineering, structured design, testing, and documentation. Concepts are reinforced through technical and cultural readings, written homework, several medium-scale programs, and one large-scale group programming project. ----- A co-worker took the course and said for the big project the class basically played Software Company and split up all aspects of the project: programming, documentation, management, art, etc. If anyone wants further information, let me know. Eric Baumgartner * ebaum@dartmouth.edu Interactive Media Lab * - When in danger or in doubt, Dartmouth Medical School * run in circles, scream and shout.
gvw@castle.ed.ac.uk (Greg Wilson) (06/20/91)
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
g_harrison@vger.nsu.edu (George C. Harrison, Norfolk State University) (06/24/91)
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