billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) (02/05/89)
From article <530@sirius.UUCP>, by tarry@sirius.UUCP (Steve Tarry): > Exposure to the hardware side of computing is but *one* aspect of what > distinguishes a software engineering education from a computer science > education. I'm the teaching assistant for the undergraduate Software Engineering course here at Clemson, at which we use "Software Engineering Concepts" by Richard Fairley (of the now-defunct Wang Institute of Graduate Studies) as one of our texts; I'd like to point out that neither this text, any other text we use, nor any software engineering text I've ever run across, gives "exposure to the hardware side of computing". It DOES cover: Planning A Software Project, Software Cost Estimation, Software Requirements Definition, Software Design, Implementation Issues, Modern Programming Language Features (Ada), Verification and Validation Techniques, and Software Maintenance. These are in no way hardware topics. The field of software engineering is INDEPENDENT of the realm of application; hardware-oriented applications form a subset of the set of all applications, and one may perhaps take courses which lead to a specialization in that particular application area, but many other application areas do exist. Any application area can benefit from the utilization of software engineering principles, but software engineering is in no way tied to any particular area of application. > It has long puzzled me why there are so few masters degree programs in > Software Engineering and even fewer (none that I know of) bachelors > programs. Puzzles me, too. I tried to find such a Master's program, received a nice letter from the Wang Institute saying they were being munched by Boston University, and ultimately wound up here at Clemson, which has a very nice set of rather practically oriented CS courses. But there really should be more alternatives; Clemson was about the only other really interesting place I could find. Bill Wolfe, wtwolfe@hubcap.clemson.edu
mjl@cs.rit.edu (Michael J Lutz) (04/23/91)
[My initial posting does not seem to have made it outside of Western NY. My apologies if you've seen this already - mjl ] This is from an ongoing debate in comp.object, but I thought it might be of interest to comp.software-eng readers as well - mjl In article <1991Apr17.172806.23036@visix.com>, amanda@visix.com (Amanda Walker) writes: |> ... I am distinguishing between a physical |>construct and a symbolic one. What I think of as "engineering" is the |>application of the physical sciences (principally physics and chemistry, |>but not exclusively) to the construction of physical devices (or "engines," |>hence the term "engineer"). This interpretation is supported by the |>dictionary definition you [a previous writer] cited. Dictionarys aren't always the best source of information when it comes to technical terms. In particular, if we buy the notion that engineering is concerned with the construction of physical devices, what is to become of the Industrial Engineer? As far as ABET is concerned, this is an ``engineering discipline'', but IE's are not directly involved in the design or manufacture of physical devices; instead, they are most concerned with the processes underlying these activities -- and this is at least as abstract as software development. As I am not an engineer by education, I decided that the best way to find out what engineering is all about was to find out what *engineers* say engineering is all about. This is a meta-question -- we have to separate what an engineer does from the specific tools he or she uses in addressing engineering problems. The problem is compounded by the fact that engineering typically attracts goal-oriented, precise, quantitative persons who are not particularly introspective about what they do and where engineering fits in the grand scheme of things. However, there are some exceptions (thank God). I strongly recommend each of the following to those who want to join debate over what engineering is and whether software development is, can be, or should be an engineering discipline: Shaw, Mary "Prospects for an Engineering Discipline of Software", IEEE Software, Vol. 7 No. 6 (Nov. 1990). Florman, Samuel C. Existential Pleasures of Engineering. St. Martin Press, 1976. Petroski, Henry. To Engineer is Human : The Role of Failure in Successful Design. St. Martin's Press, 1985 Koen, Billy Vaughn. Definition of the Engineering Method. American Society for Engineering Education, 1985 For the record: Mary Shaw is on the computer science faculty at Carnegie-Mellon; she also is involved with at the Software Engineering Institute. Florman is a civil engineer, and I believe Petroski is as well (if not, Petroski is a mechanical engineer). Koen is a chemical engineer by training, but also has held positions in mechanical engineering departments. I believe he is still at U.T. Austin. Koen's book (actually a pamphlet, costing about $7.00) has influenced me greatly because: a) he writes lucidly and persuasively, b) the publication is from the ASEE, and I'm an educator, c) the fact that the ASEE publishes and actively promotes the pamphlet in its magazines indicates that at least a few engineers in positions of influence believe Koen has something important to say. --------- Mike Lutz Rochester Institute of Technology Rochester, NY 14623-0887 mjl@cs.rit.edu