Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!think!ames!ucbcad!ucbvax!cbatt!cwruecmp!cwruacm
From: cwruacm@cwruecmp.UUCP
Newsgroups: comp.edu
Subject: Re: software engineering
Message-ID: <1986@cwruecmp.UUCP>
Date: Thu, 26-Mar-87 15:02:11 EST
Article-I.D.: cwruecmp.1986
Posted: Thu Mar 26 15:02:11 1987
Date-Received: Tue, 31-Mar-87 04:43:43 EST
References: <340@ndsuvax.UUCP>
Reply-To: cwruacm@cwruecmp.UUCP (Kronen Insultants)
Organization: CWRU Dept. of Computer Engineering, Cleveland, Ohio
Lines: 69

In article <340@ndsuvax.UUCP> ncmagel@ndsuvax.UUCP (ken magel) writes:
>
>At what level should students be taught software engineering principles
>and concerns?  How much should be covered in the introductory courses, 
>how much should be presented to non-majors?  Should the material be a 
>part of courses whose emphasis is another topic (e.g., data structures,
>operating systems), or should there be specific courses which concentrate
> on design, on testing, etc.?

Here at CWRU, seniors in Computer Engineering must take a course during the 
Fall Semester called "Design Methodology".  It covers (depending on the 
professor -- there are different professors for the course every year) the
software life cycle in some depth, with more or less equal emphasis being
placed on each phase of that life cycle.  This is the course that explicitly
covers this subject area, though >>slight<< emphasis is given in other 
courses.  Very little of the principles of software engineering is covered
in classes that may contain students whose major is not Comp. E. (in my
experience).

I believe that this is the proper time for such a course that covers the
subject in depth, but that more emphasis on principles such as good
specification and how it leads to good design, and the importance of testing
should be covered in lower-level courses such as a data structures course
where students receive their first experience writing "non-trivial" programs.

In my own experience as an undergrad here, I found that little emphasis was
given at lower-level courses like data structures and systems programming.
I used to sit down at a keyboard the day before my data structures assignments
were due (this was two years ago -- I don't do this anymore) with no design,
no plan of attack, and just "hack" until I got something that worked for the
examples that we were given to run.  Systems Programming was a little better,
but there was no explicit emphasis on any of the real principles of software
engineering.  It was not until the second semester of my Junior year that I
took a course that even discussed testing methodologies.  This has led me to
conclude that teaching some principles of Soft. E. would make the undergrad
courses a little less "painful" and help the move away from "here is the 
assignment statement (the requirements), here are some examples to run to
show the grader that your program works, now come back in two weeks with a
program".  This sort of inspires an "ad hoc method" of design that doesn't
always work.

I'm not advocating the teaching of specific design methods like JSD or VDM
to sophomores, just exposure to some principles that may ease their way 
through the sequence of core courses.


>     When and how often should students do project assignments?

Our Design Methodology course had one assignment, a term project.  We followed
the life cycle very closely, handing in requirements, specification, and design
documents, then (and only then) writing the code, and turning in a final 
summary report that included our testing methodology.

I hope that this article inspires some discussion of the various methods used
in Universities around the world.


Chet Ramey

ARPANET:  cwruacm%case@relay.cs.net
	  ramey%cwru-20%case@relay.cs.net
CSNET:    cwruacm@case  or  ramey%cwru-20@case
UUCP:     {...}!decvax!cwruecmp!cwruacm
	  {...}!decvax!cwruecmp!ramey@cwru-20  (depending on your mailer)
BITNET:   ramey%cwru20@cu20b

"Now, that wasn't much of a noise, was it?  Don't everybody try to play it
TOO safe!"
						The Art of Noise