Computer Science Education

Elias Sinderson fork@xent.com
Mon, 27 Jan 2003 19:39:03 -0800


See comments inlined...

johnhall wrote:

>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.  :-)


Elias