IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 11, NOVEMBER 1987 Essential Elements of Software Engineerng Education Revisited PETER FREEMAN Abstract-A basis for software engineering education proposed in 1976 is reviewed and found to still be valid today, although needing more emphasis on design and better delivery mechanisms. Specific rec- ommendations are made. Index Terms-Curriculum, design education, education, intellectual basis of software engineering, software engineering, technology trans- fer. ESSENTIAL ELEMENTS REVISITED TJ'EN years ago, an intellectual basis for software en- Igineering education (SEE) was proposed that identi- fied a set of components that should underlie any curric- ulum in the field [1]: computer science, management science, communication, problem solving, and design. It also stressed the integration of management and technical issues in software engineering. A review of that proposal indicates they are still the right elements. However, events of the intervening ten years and the current requirements for SEE lead to the conclusion that the design component is being seriously underemphasized. This conclusion and the slow progress in building the structures to deliver SEE lead to some other observations about SEE and what we should be doing about it. This paper develops these two theses and suggests some directions we should be taking. The 1976 paper addressed the use of each component by the software engineer, the range of knowledge needed, and the depth of understanding required; it also implicitly stressed the principle that software engineering is an ap- plied activity that must carefully integrate managerial and technical elements. It went on to address the issue of teaching software engineering (a topic expanded on in several papers [2], [3], [4]) and ended with the following: Any such curricula must meet the following criteria. 1) Be based on the five content areas outlined here. 2) Be flexible so that they can change easily and be adapted to substantive developments in the field. 3) Be based on computer science and be viewed as "applied computer science." Other alternatives will lead to suboptimal educational programs. 4) Prepare students to push forward the boundaries of knowledge and techniques, not just apply what is already known. Manuscript received May 13, 1986. The author is with the Department of Information and Computer Sci- ence, University of California, Irvine, CA 92717. IEEE Log Number 8717061. 5) Include a large amount of realism and practical work. 6) Provide for multiple implementations, dependent upon career objectives and backgrounds of students and upon the academic home of the program. 7) Build on existing curricula to the extent possible. The same paper could be written today. While much has happened in past ten years and while there are cer- tainly some refinements that can be made, this is still the foundation on which software engineering (and educa- tional programs to support it) must be built for the fore- seeable future. Let us note some of the needed refinements here, with- out going into detail. "Management science" should be broadened to "management;" many of the things the software engineer needs to know about management are not quantitative and never will be. "Design methodol- ogy" should be broadened to "design practice" or just "design;" more will be given on this below. The long- range importance of automated and/or mathematically based techniques in SE means that the software engineer must have a strong foundation in those parts of computer science that are relevant to their effective use; the loose nature of the definition of computer science argues that a tighter definition of what the software engineer should know is needed. The present revisitation to this proposal, the nature of almost all current SEE efforts, and the added perspective of ten years thus confirms (at least, for the author) that it is indeed the proper foundation. But that does not mean we should be sanguine about our present situation. On the contrary, two things are rather disturbing, one procedural, one substantive. Procedurally, the software field is like some of America's basic industries, which for years refused to acknowledge that changes were needed; the lack of progress in software engineering usage and education is extremely serious. As educators, we must take a share of responsibility. The experience of the past ten years argues even more forcefully that design must be the integrative knowledge and activity that is the core of software engineering. That part of the content of SEE must be emphasized and put into effective action. Before expanding on these two topics, let us review some of the significant events (for SEE) of the past ten years and the current demands on and for software engi- neering education. 0098-5589/87/1100-1143$01.00 © 1987 IEEE 1143