vsaariokari@abo.fi (05/29/91)
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? ( the best ones may be published in my research )
jacob@gore.com (Jacob Gore) (05/30/91)
/ comp.software-eng / vsaariokari@abo.fi / May 29, 1991 /
> Has anyone any other definition for Software Engineering?
Communication -- with the target machine and with humans. Both components
must be present.
(When the software is incommunicable to humans, the process is called
"Hacking." When it's incommunicable to the machine, it's called "Research"
:-)
Jacob
--
Jacob Gore Jacob@Gore.Com boulder!gore!jacobcox@stpstn.UUCP (Brad Cox) (05/31/91)
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? > ( the best ones may be published in my research ) This of course begs the question of whether anyone in software today really uses the 'sound engineering principles' he advocates, and thus whether there's any such thing as 'software engineering' or 'computer science' today, except of course perhaps as a kind of pre-scientific theology of the sort that Astronomers (Aristotle, Ptolemy) practiced before Copernicus. The definition I go by is in the last sentence of the following excerpt from "Planning the Software Industrial Revolution'; IEEE Software magazine; Nov 1990. "Such confusion is not surprising. The denizens of the software domain, from the tiniest expression to the largest application, are as intangible as any ghost. And because we invent them all from first principles, everything we encounter there is unique and unfamiliar, composed of components that have never been seen before and will never be seen again, and that obey laws that don't generalize to future encounters. Software is a place where dreams are planted and nightmares harvested, an abstract, mystical swamp where terrible demons compete with magical panaceas, a world of werewolves and silver bullets. As long all we can know for certain is the code we ourselves wrote during the last week or so, mystical belief will reign over quantifiable reason. Terms like 'computer science' and 'software engineering' will remain oxymorons -- at best, content-free twaddle spawned of wishful thinking and, at worst, a cruel and selfish fraud on the consumers who pay our salaries." -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
iverson@xstor.com (Tim Iverson) (06/01/91)
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