Computer Science Education
Mon, 27 Jan 2003 19:39:03 -0800
See comments inlined...
>1. Is anyone doing old fashioned Data Flow diagrams anymore? The program director assures me lots of people do. I've never worked for any, though.
I haven't used them in a professional setting, although I'm sure there
are places where it's an invaluable technique. OOA&D using UML seems to
be industry standard these days.
>2. It was my impression that most Analysts were MBAs. T/F?
No data here...
>3. I've wound up using a Problem / Group Brainstorm / Professor Critique method for trying to teach design. This why each kid gets a shot, gets to see what the rest of the class came up with, and then gets my ideas. Anyone have a better suggestion? I have trouble coming up with Design problems that are simple enough to do but not trivial. The ability of the students to screw up trivial problems can not be over-estimated.
Mr. FoRKs suggestion is good - have them do the design within a domain
that they understand. This removes a level of abstraction for them that
can be difficult to contend with oterwise. There are two parts to OOA&D,
the 'A', and the 'D'. By giving them a domain they understand and are
familliar with (scrabble, blackjack, checkers, etc.) you can help them
to just focus on the 'D'.
I also like your approach of having the studets work individually, then
together in groups. Forcing each individual to think critically about
the problem on their own has the obvious benefit of making them think.
Subsequently forcing them to reconcile the differences in design with
their group members gives them a taste of how design is done in the
'real world' (although I question every day where this 'real world'
continues to hide while it mocks me...). Bonus points for having the
courage to make the class come together and critique the professors
design, as it allows them to recognize that good design work is hard,
and even the one who is supposed to know it all can be imperfect.
Throughout this whole exercise individuals will be forced to think
critically about the design, whether it is their own or someone elses.
>4. Not a single one of the kids really knew what a list was or could implement even a simple list routine. The people who taught the earlier courses admit they never covered it. I was shocked. Am I expecting too much from students who have had 2 semesters of programming?
Mmmm... It depends on the school. I would think that a Data Structures
course would be a prerequisite to any 'Structured Design and Analysis'
course, but perhaps that's part of what you're intended to convey to
them (as unfortunate as it may be). Usually the simpler data structures
(lists, stacks, queues, and maybe trees) are used as programming
exercises in the second programming class a student takes, but it
varies. The benefit of this is that the official data structures course
can focus on learning the basics of space/time analysis on the simpler
data structures they already understand before moving on to the more
complicated data structures.
>5. Any suggestions for teaching OO that doesn't wind up either being an essay test or a syntax test are welcome.
Damn, I thounght I had a good one, but I can't remember it after typing
the above... hmm... Using existing design patterns as 'case studies'
might be interesting. It would both expose them to some of the issues
involved, as well as familliarize them with some common patterns that
they could then apply later.
>6. I made them do book reports. Books chosen have included "Mythical Man Month", "Extreme Programming", "Code Complete", "Writing Solid Code", and "Refractoring". There was also a book that included some Design Patterns. Suggestions for other books that might help broaden their education are welcome.
Interesting idea - I can't say that I've heard of this before. Neat way
to inject other material into the curriculum.
>7. Do 'normal' undergraduates have enormous problems going from generic descriptions to concrete practice?
Yes. I'd also say that they have bigger problems going from the concrete
practices/implementations to the more general case. Suggestion: Don't
teach to the 'normal' student, teach to the 'above average' ones. I'm
only partly kidding when I say that.
>8. Is there a 'Database Design Patterns' book out there somewhere?
Not that I've seen, but I'm not as familliar with the domain as I'd like
to be. If you find one, please send me a recommendation.
>9. If you were designing a CIS program, would you be teaching Structured Analysis instead of Data Structures, Operating Systems, or Software Engineering?
Not instead of, but also perhaps not in the order that your students are
getting it. As I mentioned previously, Data structures should probably
be taught before OOA&D.
>A. Anyone know a good reference for 'the theory of testing software'. My kids have never been exposed to 'test harness', 'regression test', etc. I'm doing my best but I'm shooting from the hip on that one.
Good luck, can't help you here. I hope that some of the above discussion
was useful to you. :-)