Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!xstor!iverson
From: iverson@xstor.com (Tim Iverson)
Newsgroups: comp.software-eng
Subject: Re: Definition for Software Engineering
Message-ID: <1991May31.224018.28908@xstor.com>
Date: 31 May 91 22:40:18 GMT
References: <7569.28438fc3@abo.fi>
Reply-To: iverson@xstor.com
Organization: Storage Dimensions, Inc.
Lines: 46

In article <7569.28438fc3@abo.fi> vsaariokari@abo.fi writes:
>	Fritz Bauer has defined software engineering as
>' Establishment and use of sound engineering principles in order to obtain
>economically software that is reliable and works efficiently on real
>machjines'. Has anyone any other definition for Software Engineering?

This seems to be kind of a "wet-noodle" definition - it lacks rigor.  What
are "sound engineering principals"?  Why *must* software be "reliable" and
"efficient"?  And in what sense must it be "economical" - for the end user
or for the producer?
 
Bauer's definition is more sermon than definition.  To draw an analogy, we
can say that "walking" is defined as "moving at a natural pace while
upright".  There is no need to add the restriction: "while not bumping into
tall buildings, parked cars, and lamp posts".  People can walk into walls
if they want to (most don't thankfully :-).

Much simplier and to the point, I define software engineering in two parts:
software engineering (the application): "using a methodology to produce
software", and software engineering (the science) as "creation and analysis
of methodologies for producing software".

One of the goals of the discipline of software engineering is produce viable
methodologies - i.e. methods that when applied, produce consistent results.
Others would be reliable, efficient, timely, and cost-effective results, but
none of these laudable goals are necessary to define "software engineering".

Traditional engineering, after all, is just "methods and materials".  For
software engineering, "methods" is the collection of algorythms,
methodologies, and those little tricks learned only through experience.
"Materials" would comprise languages, production tools (e.g.  RCS, yacc,
etc.), and even hardware.

I've focused on methods in my definition because it seems to be the only
necessary condition.  IF a method is used, THEN the software can said to
have been engineered.  Pretty algorythms and nifty tricks are nice, but
their use does not immediately imply engineering.

I am at somewhat of a loss when it comes to sufficient conditions.  It even
seems like there may be no way to absolutely determine after the fact
whether a given piece of software had been engineered or not.  Perhaps 
the net has some ideas here.


- Tim Iverson
  iverson@xstor.com -/- uunet!xstor!iverson