tarry@sirius.UUCP (Steve Tarry) (02/04/89)
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. Consider what universities offer our engineering brethren: Students interested in research study, for example, chemistry, math, or physics; those interested in building products get a degree in, e.g., chemical engineering, electrical engineering, or civil engineering. Of course, the engineering students must learn a foundation in the underlying sciences, but they also learn how to apply science to real commercial problems. In the world of software, there would seem to be similar educational needs: Computer science for those exploring frontiers of the software art, and software engineering for (the much greater number of) people who are building software products. In article <67605@ti-csl.CSNET>, myjak@home.csc.ti.com (Michael Myjak) writes: > ...I have often wondered how well pure CS people perform at > tasks (like software engineering ?) that require a moderate (to > in-depth) level of hardware understanding. Exposure to the hardware side of computing is but *one* aspect of what distinguishes a software engineering education from a computer science education. In illustration of some other aspects, I'll mention a few of the features of the Masters of Software Engineering program that I recently completed (at the now-defunct Wang Institute of Graduate Studies): --Two years of work experience with software was required for admission; students fresh out of a B.S. program were not accepted. --Thorough grounding in computer science fundamentals (e.g, discrete math and data structures) was required. As one who got his B.S. in the Old Days, I found meeting the admissions requirements almost as valuable as the degree program itself. Then the first course in the program was APPLICATION (emphasis mine) of Formal Methods, such as classifying real problems according to complexity theory. --Group work on projects was required. In particular, instead of an individual thesis (which was not an option), one had to develop and deliver two software products with teams of fellow students. --Exposure to non-technical aspects of software development was an essential part of the degree. For example, a course in software project management was required, not to mention the lessons learned in the group projects. --There was a heavy emphasis on techniques (e.g., structured analysis vs. Jackson's methods) and tools (from spreadsheets to compiler generators). Hey, it's tough being a cheerleader for an alma mater that no longer exists! But there are other programs with a similar slant (such as at the various institutions where the former Wang Institute faculty have landed). And enterprising students can bend traditional computer science programs in this direction. Use your electives to take the courses required of "real" engineers (Electric Circuits, Thermodynamics, Statics, ...). Work as a programmer summers or between degrees or in a co-op program. Develop a program useful to others (including the users manual!) as part of your thesis. -- Steve Tarry ...dartvax.dartmouth.edu!sirius!tarry Northern Telecom, Network Supports Systems Div., Concord, N.H. (for now)
coggins@coggins.cs.unc.edu (Dr. James Coggins) (02/07/89)
In article <530@sirius.UUCP> tarry@sirius.UUCP (Steve Tarry) writes: > >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. There is a good case to be made that Software Engineering is not an appropriate baccalaureate field of study and that the professional M.S. as you described Wang Institute's M.S.E (R.I.P.) is the only reasonable way to go. Wang's entrance requirements helped to ensure that the MSE was not just an advanced hacker's degree. (yech, what a concept.) There is, in fact, a strong case that can be made to the effect that software is OVERemphasized in current B.S. CS programs at the expense of problem-solving, analytical skills, mathematics, and CS theory. The question to ask is, "How much of our undergrad program will be obsolete in 10 years?" Too many places must answer with too high a figure. Students are better served in the long run by not getting a CS(E) undergrad degree - especially the narrow, inflexible, hacker-driven mush being pushed by the accrediting agencies. >Of course, the engineering students must learn a foundation in the >underlying sciences, but they also learn how to apply science to >real commercial problems. See this month's CACM for yet another attempt at defining what a CS curriculum is. Since the underlying science is so ill-defined, the engineering discipline sits atop sand. It is appropriate for intensive study only by those who really need it immediately - people working in the field who, one hopes, have outgrown their hacker phase and are ready to adopt the mantle of professionals. In other words, Software Engineering remains most appropriate for a professional M.S. program. --------------------------------------------------------------------- Dr. James M. Coggins coggins@cs.unc.edu Computer Science Department UNC-Chapel Hill Software Engineering Laboratory Bawss Chapel Hill, NC 27514-3175 (UNC COMP 145/227) ---------------------------------------------------------------------
myjak@home.csc.ti.com (Michael Myjak) (02/10/89)
>> I wrote: >> ...I have often wondered how well pure CS people perform at >> tasks (like software engineering ?) that require a moderate (to >> in-depth) level of hardware understanding. Steve Tarry writes: >Exposure to the hardware side of computing is but *one* aspect of what >distinguishes a software engineering education from a computer science >education. In this case I was referring to a systems software engineering; i.e. one who is applying the skills and techniques of software engineering to a hardware related application. Granted Steve, it *is* an application, but one that all computer scientists should be versed in; otherwise they would just be programmers. :-) The original point of discussion which started all this was: "Who is better qualified to develop software that requires moderate to in-depth level of hardware knowledge and software engineering, a BSCS or BSEE?" The second point I would like to quibble about is that a "software engineering education" is something that all computer scientists should have been exposed. IMHO, software engineering is not a separate discipline, but it may be an area of specialty for a phd dissertation. Bill Wolfe writes: > The field of software engineering is INDEPENDENT of the realm of > application; [...] 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. Exactly where is the "field" of software engineering? is it in Boise? :-) Many industrial locations call any body which authors programs a software engineer. While in many instances this may be true, I do not believe that it is completely accurate. A BSCS (CIS?) may graduate without ever having had a single course in software engineering and yet industry still refers to them as software engineers. Scott G. writes: >A software engineer is the typical term for someone with a BSCS. see? Bill then goes on to make an incorrect statement: > It DOES cover: [...] > Modern Programming Language Features (Ada) ... This is incorrect because Software Engineering is independent of, and in no way related to a *particular* language, its features, or its associated environment. While it is true that some languages lend themselves to software engineering techniques better than other languages do, software engineering and ADA are mutually exclusive. Quoting from _Software Engineering: A Practitioner's Approach_ by Roger S. Pressman; McGraw-Hill, 1982.: Software engineering "... techniques deal with software as an engineered product that requires planning, analysis, design, implementation, testing, and maintenance." To sum this up, Software Engineers are people who apply software engineering techniques to their programming tasks. -- Always mount a scratch monkey --