- Email: [email protected]
Software engineering education—adjusting our sails
Education & Computing 8 (1993) 287-294 Elsevier
287
Software engineering education our sails
adjusting
G. P o m b e r g e r lnstitut fiir Wirtschaftsinformatik, Johannes Kepler Untversttyof Lmz, Austrm, and Christian DopplerLaboratory, Altenbergerstrasse 69, A-4040 Lmz, Austria Abstract Pomberger, G., Software engineering education--adjusting our sails, Education & Computing 8 (1993) 287-294. It is clear to everyone involved m the field of software engineering that our instruction lags well behind research. Conservative thinkers do not want to leap onto a given bandwagon too early, while even the most progressive thinkers face a profound challenge in incorporating worldwide research into the curriculum. Based on a discussion of current trends in software engineering, this presentation sketches the emphases that need to be placed in the software engineering curriculum.
Keywords: software engineering curruculum; software engineering trends; software engineering education; computer science curruculum; computer science trends; computer science education.
Introduction T h e focus of my presentation will be the question of what we n e e d to take into consideration in o r d e r to equip software engineers with the comp e t e n c e that is necessary to m a s t e r the diversity and difficulty of problems we are c o n f r o n t e d with in software engineering. Let me begin by briefly sketching what I m e a n by software engineering and what attributes can be derived t h e r e f r o m for a software engineer; then I will share some m o r e precise c o m m e n t s on software engineering education, concentrating primarily on the engineering aspects. Next I want to explicate, in my opinion, what e m p h a s e s absolutely n e e d to be part of a software engineering curriculum. My goal is to e n u m e r a t e general aspects rather than to formulate a specialized and detailed curriculum. F u r t h e r m o r e , I intend to touch briefly on w h a t should not, or no longer, be part of an u p - t o - d a t e software education curricu-
Correspondence to: G. Pomberger, Institut fiir Wirtschaftsinformatik, Johannes Kepler University of Linz, Linz, Austria. Email: [email protected].
lum because it is antiquated, is too trivial, was overrated, or fails to provide d e e p e r insights. T h e question of teacher qualification also needs to a c c o m p a n y a discussion of m o d e r n curriculum. I will briefly speak to this point at the end of my presentation. T h e questions of what we m e a n by software engineering and what characterizes a software engineer are not merely rhetorical. If we ask two persons about their conceptions about software engineering, we can expect to obtain three or m o r e answers. W h e n I speak of software engineering, I m e a n the practical application of scientific
knowledge for the economical production and the useful and economical employment of reliable and efficient software (see [1]). I would extend this definition with the assumption that an engineering a p p r o a c h and way of thinking is the key in this definition. W h a t do we m e a n by an engineering discipline? A n engineering discipline integrates aspects of synthesis, analysis and organization. A n engineer's c o m p e t e n c e is the result of f u n d a m e n tal theoretical knowledge, technical know-how, experience, and cost and application-oriented thinking.
0167-9287/93/$06.00 © 1993 - Elsevier Science Publishers B V. All rights reserved
288
G. Pomberger / Softwareengineeringeducatton
On this basis, we can summarize that a software engineer must be able to do the following
(cf. [2]): - specify, prototype, design, code, test, document and modify software systems utilizing state-ofthe-art software engineering technology; - plan, organize, estimate costs, schedule and track a software development or modification effort at the project leader level; - develop and identify reusable parts of software; - define and ensure software quality through the development and use of software metrics, standards, review procedures, and version and configuration management approaches; - assess advances in software engineering, apply them to projects and evaluate their effectiveness; - work with a n d / o r manage computer science specialists, programmers and other engineers in the development and modification of complex software systems; - build tools for other software engineers; and - serve as knowledgeable participant in system design when the question is considered which components should be built into software and which should not. In order to attain these competencies, it does not suffice only to accrue specialized knowledge. The software engineer must also be creative, cooperative and innovative, have the courage to try new ideas and to make decisions, and be willing to experiment. Today's best-known software systems and contributions to software engineering were made by persons who possess precisely these competencies (for example, programming languages and associated development tools such as Modula-2, Oberon and Smalltalk; algorithms such as quicksort, character string searching according to B o y e r / M o o r e ; Visicalc and all its spreadsheet successors - to name but a few). We are thus confronted with the question of how to fashion software engineering education in order to promote creativity and innovativeness. Can creativity be promoted at all? What are the limits of a university education? Although these are important questions that concern software engineering education, I will not treat them in further detail at this time. I will concentrate on the aspects specific to our subject area.
The current situation is such that we have observed considerable advances in research in the area of software engineering, yet most software produced nowadays proves unsatisfactory in quality despite enormous costs, and it by no means reflects scientific advances. What is the cause of this situation? The road from the software crisis to software engineering depends not only on scientific advances but also on the degree to which these results of research are made accessible to business and industry. Adequate education is, from my point of view, an important part of the solution to the software crisis. I claim that the software crisis is caused at least in part by deficiencies in our education. Universities are the most important and the leading institutions of education in our society. If we consider the current situation in software engineering, we need to ask whether this leadership role has been carried out by the universities. Have we concentrated too much on research and too little on teaching? Has our education been too theoretical and not practice-oriented enough? Or is the situation in industry (antiquated hardware, obsolete tools, inadequate standards, and so on) to blame for the inability of software engineering graduates to appropriately translate their software engineering knowledge into practice? Or is the shortage of graduates the cause of this unsatisfactory situation? What must be done to improve the situation is very multi-faceted. I will be dealing only with the aspect of the content and design of an up-to-date software engineering curriculum. ! will be sketching my very personal, and hence subjective, opinions about the general aspects of an engineering education and the emphases of a timely software engineering curriculum.
General cation
comments
on software engineering
edu-
The importance of theory According to the definition of software engineering that I gave, the goal of education is the competence to apply scientific knowledge practically in the production of software. The university's task is to transmit knowledge and insights. In this sense it would be irresponsible to teach the application of scientific knowledge without
G Pomberger/ Softwareengineeringeducatton first preparing the student for deeper understanding by means of the necessary fundamental theoretical knowledge. Just as a doctor of medicine requires elementary fundamental knowledge (for example, anatomy, chemistry) regardless of the chosen field of specialization, a software engineer must both know and master basic theory of the whole software engineering discipline. For software engineering this includes discrete mathematics and computer science theory. Frederick Brooks [4] appropriately formulated: "'The scientist builds in order to learn; the engineer learns in order to build." A central activity of engineers is the design of systems. Software systems are used above all for control of, or as components of, physical (technical or commercial) systems. On the basis of my observations and experience, I believe that engineers with experience in the design of physical systems without software engineering experience also tend to design better software systems than software engineers who lack experience in the design of physical systems. The theoretical fundamentals of engineering and scientific thinking, of systems theory and of the theoretical fundamentals for building hardware (physics, electronics, computer architecture) should thus also be part of the basic education for software engineering. I believe that engineering and scientific fundamentals and systems theory are underrepresented in software engineering curricula; likewise hardware-oriented aspects receive too little attention. More than just theoretical knowledge and insights are important. Engineering and scientific thinking and acting is an absolute precondition for any software engineer. The ability to approach a problem systematically, to handle it in a systematic and structured manner, and to document the solution; the ability to distinguish the relevant from the irrelevant; the ability to cooperate with clients, system users, and colleagues are important prerequisites for successful performance in engineering. Thus an adequate software engineering education should also include work methods. A colleague at the Research Institute of Symbolic Computation has for some years been very successfuUy offering a course entitled "Listening-
289
Reading-Thinking-Speaking-Writing-Cooperating". Although such approaches are very promising, they are too seldom included in a software engineering education. I believe that students should be exposed to both the technical aspects of programming and general techniques of problem solving, and not in an isolated way.
The importance of project-oriented education Learning and applying learning are two different things. Even after a good theoretical education, students are not yet engineers. Only the application of acquired knowledge to a concrete, reality-oriented problem makes it clear to what extent the theory was understood and whether and to what extent it is applicable to a concrete case. The real problems, difficulties, and hurdles only become clear when they are experienced. Al Peitrasanta [3] said: " A formal design language to express software engineering methodology is very powerful, but difficult to use. I compare it to learning your first programming language, in a course, or out of a book. You left it and said, 'Hah! Now I'm a programmer!' Then you started applying the language. You started programming. It might have been one, two, or three years later, when you reflected back and said, 'Now I understand. Now I'm a programmer.' It's the same thing in software engineering, applying a design notation; it takes a tremendous amount of application and experience, and trial and error to reach the point of proficiency. You can learn the syntax, you can learn the mechanics, but it takes a long time to apply it." Project-oriented education needs to be given more priority. This poses the question of how to carry out project instruction. Should this be parallel to theoretical instruction, or intermeshed with it, or should it be offered only after theoretical instruction has been completed? (Here we recognize that it is difficult to convince students of the value of theory without discussing its application.) In my opinion, theoretical instruction should always be accompanied by practical examples; that is, theory and practice should be intermeshed. The transition from theory to practice-oriented education can be made on the basis of case studies of complex software systems. Then students (in teams) can gain experience in translating their knowledge into practice by means of
290
G. Pomberger/ Softwareengineeringeducatton
programming practica and can obtain feedback concerning their progress from intensive reviews of their work. The only way to teach people to design is to have them design and criticize, have them redesign, and then have them build the design. Frederick Brooks [4] said, "Great designs come from great designers." That is the truth. We can learn a great deal by studying, analyzing and discussing excellent system architecture designs. This is why I consider such case studies especially important within the realm of a software engineering curriculum. I consider the analysis of complex, high-quality software systems and the discussion of the design aspects and approaches to a solution that they contain to be an efficient way to demonstrate the application of theory in practice and simultaneously to improve the design skills of the students. Discussions with colleagues and the analyses of software engineering curricula have shown that this method is used very rarely. One reason could be that such designs are not documented in books. I believe that a well balanced relationship between theory and practice is necessary, starting in the first years of software engineering education. Theoretical instruction must not be limited to mathematics and programming; it needs to include physics, electronics, computer architecture and general engineering fundamentals. Furthermore, intensive case studies of excellent system architectures need to be integrated into the curriculum. Following these general comments on software engineering education, I want to sketch several emphases of an up-to-date curriculum.
Emphases of software engineering education
Software life-cycle, prototyping, exploratory programming The life-cycle model is part of every software engineering education. The strict application of the classical sequential software life-cycle model requires that a given phase can begin only after its preceding phase is completely finished. This is in contrast to reality; for example: "We must take it as given that the user does not and cannot know what he wants with respect to artifacts as complex as those we now build. The mind of man
cannot imagine all the ramifications of such artifacts. There must be an iterative cycle in which the professional works with the user to define the requirements; demonstrates their consequences in human factors, cost, performance; then in a prototyping phase iterates with the user to develop a product that is, in fact, satisfactory [4]. While implementation is as late as possible in the classical life-cycle model (only after the specification phase has been completed), here we take the opposite approach and implement a prototype as soon as possible. We use other implementation tools for the prototype. The same applies to the design of the system architecture. It is practically impossible to attain an adequate system architecture on the first try. Here again, we are better served if the design is iterative and the products of the phases are verified by means of architecture prototypes. Exploratory and incremental design and implementation methods are growing in importance. This puts adaptability and maintainability in the foreground even during the development phase. Using these techniques changes the structure and procedures of the life-cycle model. The classical life-cycle model needs to be augmented in instruction by prototyping-oriented, exploratory and incremental development strategies. Concepts, methods and tools for these techniques and their ramifications for the software development process need to be a part of any modern engineering education.
Human-computer communication One trend that is strongly influencing the development of software today is human-computer communication. New measures of user comfort have been set by the combination of graphic screens, mice as pointing devices, windows and graphic user interfaces. But the user's paradise is a nightmare for the programmer. Basics, principles, techniques and tools for the creation and implementation of user interfaces are prerequisites for efficient programming, and these form an essential part of any modern software engineering education. The consequences of the construction and complexity of modern graphic user interfaces, of the use of application frameworks for the design of the architecture of software systems, etc., lead to a new procedure in the design of software systems. This requires the
G. Pomberger / Software engineermg education
29t
drastic revision of many software engineering textbooks.
systems must also be considered in the development of new software engineering curricula.
Thought models
Increased productivity through reusability and tools
Various programming languages build on the foundations of various thought models that profoundly affect the way the programmer thinks and thus the architecture of the products that are developed. We may distinguish (see [5]) imperative thought models, consisting at least of the algorithmically oriented thought model (supported for example by the languages Modula-2 and Ada), and the object-oriented thought model (supported for example by the languages Smalltalk, Oberon-2, and C + + ), and nonimperative thought models, consisting at least of the functional thought model (supported, for example, by the languages Lisp and Miranda) and the logic thought model (supported, for example, by Prolog). Various areas of application are covered to various extents by the different thought models; for example, the programming of graphic user interfaces is adequately supported by the object-oriented approach and the programming of rule-based systems by the logic-oriented approach. Software systems as they are being programmed nowadays tend to integrate various application areas ever stronger, and it has become more and more practical to develop hybrid systems. Software engineers should thus receive a solid foundation in all these thought models, not only in the algorithmically oriented thought model, as is often the case. Classical software engineering curricula tend to treat nonimperative thought models superficially if at all.
Aspects of increasing productivity belong to the tasks of an engineer. Hopefully, in the future we will have less people involved to produce the same result because we will have achieved a better productivity level. We have to train our students in developing reusable components. Object-oriented programming, class libraries and application frameworks are key issues in this direction. This means that we have to train our students in reusing existent components as it is usual in other technical disciplines. Another way to increase productivity is by means of a more automated development process than we have today. Applying theories, methods and principles can be significantly supported by the use of adequate tools, but this is unfortunately seldom done in software engineering practice. Both building and properly using tools are within the tasks of a software engineer and should also be part of any software engineering education. Since most commercially available tools are not state of the art, it is a good idea to develop simple tools in the realm of a project-oriented education.
Distributed systems and parallelism Computer networks continue to advance, and distributed systems are growing in importance for industrial and commercial applications. Since each network node of a distributed system is realized with its own computer with computing power and often considerable storage, the time has come to make use of parallel processing of problems. The use of multiple processor systems for the parallel handling of algorithms and for data exchange requires a new approach to the design of such systems. Theory and practice in the development of software for distributed systems on distributed
Documentation and maintenance It has long been clear that the greatest expense in the software life cycle falls on the maintenance of a software product. In the education of software engineers, the relationship is reversed. The problems of maintenance and approaches to solutions are usually not even discussed. Documentation shows a similar picture. In practice there has repeatedly been the cry to pay more attention to this aspect. I believe that the area of maintenance in particular is not adequately covered in our software engineering curricula. But can we teach maintenance? I do not believe that we are capable of teaching the maintenance of large software systems. The university cannot serve as a cornucopia. We need to add issues, tools, techniques of change control, configuration and version management, validation arkd verification, structure and content of software documentation, literate pro-
292
G. Pomberger / Software engineeringeducation
gramming, and so on, to our curricula, yet these are just prerequisites to getting a grip on the maintenance problem. Maintenance activities themselves are difficult to systematize and generalize. Experience plays a central role here, and gaining experience at the university is possible only to a limited extent. We can only make a small contribution in education. Testing and quality assurance Practice has shown that producing error-free software is almost impossible. This has given particular importance to testing and quality assurance. Testing and quality assurance encompasses complexity analysis, code inspection, walkthrough, review, formal verification, debugging, test case design, design of test strategies, and design and use of testing tools. Extensive theoretical and practical knowledge are required in order to incorporate this difficult process into software development. It is not sufficient to include testing only in the practically oriented part of software engineering education, that is, in project work; this must also be augmented by theoretical instruction. Project management Computer science curricula at technical universities and colleges often neglect the management-oriented aspects of software production, while for business-oriented curricula the reverse is often the case (that is, technical aspects are neglected). Unfortunately, my personal standpoint is that we must admit that scientific knowledge in the area of project management is rather modest. Failures due to technical shortcomings are often blamed on mismanagement. I do believe that management-oriented aspects, such as theory and structure of organizations, human relations and organizational behavior, oral and interpersonal communication, skills, cost estimation techniques, risk assessment, c o s t / benefit analysis, contracts and business plans, tools and techniques for planning, monitoring and controlling project schedules and budgets, are important components of a software engineering education and should ideally be included in software engineering curricula. But we must not overstress the management-oriented aspects. The technical problems are the more essential
ones. If we can solve these, then the management problems are easier to handle.
Further questions and comments I have enumerated several important emphases that belong to an up-to-date software engineering curriculum. We also need to ask what does not (any longer) fit into an up-to-date software engineering curriculum. Some of what we find in software engineering textbooks is antiquated, or is too specialized and does not contain fundamental insights, yet it is still taught. I believe that universities must remain on the cutting edge in both research and instruction; however, in software engineering the practicability of subject matter must also be weighed. Furthermore, because the fast growth of our field quickly produces redundancy, we must also be prepared to do some garbage collection of our own and eliminate the superfluous. It would be impossible to give a complete list, but I will enumerate several typical examples in order to demonstrate what I mean. First, allow me to show what I mean by antiquated. Specialized requirements and specification methods and tools such as S R E M (Software Requirements Engineering Methodology [6], P S L / P S A (Problem S t a t e m e n t L a n g u a g e / Problem Statement Analyser [7]) or H I P O (Hierachy plus I n p u t - P r o c e s s - O u t p u t ) for example are based on anachronistic concepts and formalisms that do not provide appreciable insights. Specialized design methods such as the Jackson Method [12,13] are too narrow in their range of application areas; the concepts on which they are based are merely a subset of the significantly more powerful attributed grammars (see [8]); the formalisms that are used are awkward. Thus today we can drop such things from our curricula. What do I consider to be too trivial for the university level? In software engineering curricula over and over again we find courses in various programming languages (unfortunately including ones like Cobol and Basic). Learning a programming language is trivial. One can expect university students to learn the syntax of a specific programming language in independent study. What is most important is that not the syntax but
G. Pomberger / Software engmeeringeducation
the concepts and thought models beneath the surface of programming languages should be taught. Since it has been my experience that many students come to the university without any programming experience, I could accept that the first programming language be taught; all additional languages, however, should be the responsibility of the student. The same is true of operating system functions and machine-oriented programming. Universities should not teach a specific job control language or assembler, but the principle tasks of an operating system, how operating systems are constructed, and the essence of machine-oriented programming. The syntax of a job control language or assembler should be learned in independent study or in courses outside software engineering. Courses like "Programming under U N I X " or " . . . M S - D O S " have no place in a university environment. What do I consider to be overrated? A n example of something whose value is overrated, in my opinion, is algebraic specification. The complexity of large software systems opposes any purely formal algebraic specification. Although algebraic specifications are unambiguous, they quickly become so extensive that they are difficult to understand and thus impede communication (which is an important aspect of specification). Please don't misunderstand: certainly algebraic specification techniques need to be taught, but their limits also need to be explained, and it should be said that when something can be expressed unambiguously in a few lines of prose, then this prose is to be preferred over a complicated and hard-to-read algebraic specification. Another example of exaggerated importance is that of empirical cost estimation models (such as the C O C O M O model [9], the Putnam estimation model [10], and function point models [11]). Experience has shown that the predictive capability of such models and their results has little relevance to practice. Software metrics is a similar case. In my opinion, scientific knowledge and empirical data do not yet suffice for software engineering practice. We need to be teaching the underlying concepts, as with programming languages, rather than specific metrics. I have compiled a list of emphases that form a framework for a software engineering curriculum,
293
and I have given some examples of what, in my opinion, should not be included in the curriculum. This list is by no means complete, but it does illustrate the essential aspects of the question of software engineering education, and it shows that our subject area has acquired an impressive breadth.
Comments on the qualifications of educators
I am convinced that instruction and research at the university level are inseparably bonded. A well-founded curriculum and good educational materials cannot be developed unless the educator is active in research. The software engineering discipline grows and changes as the result of scientific advances, which again influence the curriculum. It does not suffice to teach about methods. One must also be able to show how these are applied. I consider it an error to hire educators who do not have adequate research and project experience. Professors of software engineering must be masters of both theory and practice, and to a balanced extent. Although I perceive software engineering as the application of scientific knowledge, I do not believe that practice is more important than theory. Nothing is more practical than a good theory.
Conclusion
I hope that you are not disappointed that my presentation does not end with a detailed curriculum. My goal was to supply food for discussion on the question of relevance in software engineering education from a current point of view. I do not believe that the time is ripe to establish a standard curriculum for software engineering that would meet with general acceptance. Furthermore, I do not believe that we should set up a master curriculum for software engineering. Because, as Brooks reminds us, an essential part of what we taught in the past was wrong or is outdated and much of what we teach today will not be true in a few years, and a great deal of the rest will not be relevant (see [4]). Software engineering curricula must grow with changing technology. We have to adjust our sails continuously.
294
G. Pomberger / Software engineering education
References [1] G. Pomberger, Software Engineering and Modula-2 (Prentice-Hall, Englewood Cliffs, NJ, 1986). [2] J.E. Tomayko, Proposed curriculum for a master of software engineering (MSE), in: E. Gibbs, and R.E. Fairley, eds., Software Engineering Education (Springer, New York, 1987) 420-431. [3] A. Peitrasanta, Software engineering education in IBM, in: R. Fairley, and P. Freeman, eds., Issues in Software Engineering Education (Springer, 1989) 5-18. [4] F.P. Brooks, Jr., People are our most important product, in: E. Gibbs, and R.E. Fairley, eds., Software Engineering Education (Springer, Berlin, New York, 1987) 1-15. [5] P. Rechenberg, Programming languages as thought models, Structured Programming 11 (3) (1990) 105-115. [6] M. Alford, SREM at the age of eight; the distributed computing design system, Computer 18 (4) (1985) 36-46. [7] D. Teichroew and E. Hershey, PSL/PSA: A computeraided technique for structured documentation and analysis of information processing systems, IEEE Trans. Software Eng. 3 (1) (1977) 60-69. [8] P. Rechenberg and H. M6ssenb6ck, A Compiler Generator for Microcomputers (Prentice-Hall, Englewood Cliffs, NJ, 1989). [9] B. Boehm, Software Engmeering Economics (PrenticeHall, Englewood Cliffs, NJ, 1981).
[10] L. Putnam, a general empirical solution to the macro software sizing and estimating problem, IEEE Trans. Software Eng. 4 (4) (1978) 345-361. [11] A.J. Albrecht and J.E. Gaffney, Software function, source lines of code and development effort prediction: a software science validation, IEEE Trans. Software Eng. 9 (6) (1983) 639-648. [12] M.A. Jackson, Principles of Program Design (Academic Press, New York, 1975). [13] M.A. Jackson, System Development (Prentice-Hall, Englewood Cliffs, NJ, 1983).
Gustav Pomberger was born in 1949 • " ,,;,~.~. ..-..#. ' ,
in Gosau, Austria. He is an electronics engineer and a computer science ; engineer and holds a Ph.D. of techni'¢~ . cal sciences from the Johannes Ke: ..~ t" pler University of Linz, Austria. During 1968-1976 he was a designer of _,.di~i~ electrical machines. In 1976 he became a research assistant at the Computer Science Dept., University of Linz. In 1982 he was a visiting researcher at ETH-Zurich. Between 1984-1987 he was a professor of computer science at the University of Zurich. Since 1987 he has been a professor of computer science at the University of Linz. His research interests are: software engineering in general, prototyping, programming environments, human-machine communication, compiler construction, object-oriented programming.
287
Software engineering education our sails
adjusting
G. P o m b e r g e r lnstitut fiir Wirtschaftsinformatik, Johannes Kepler Untversttyof Lmz, Austrm, and Christian DopplerLaboratory, Altenbergerstrasse 69, A-4040 Lmz, Austria Abstract Pomberger, G., Software engineering education--adjusting our sails, Education & Computing 8 (1993) 287-294. It is clear to everyone involved m the field of software engineering that our instruction lags well behind research. Conservative thinkers do not want to leap onto a given bandwagon too early, while even the most progressive thinkers face a profound challenge in incorporating worldwide research into the curriculum. Based on a discussion of current trends in software engineering, this presentation sketches the emphases that need to be placed in the software engineering curriculum.
Keywords: software engineering curruculum; software engineering trends; software engineering education; computer science curruculum; computer science trends; computer science education.
Introduction T h e focus of my presentation will be the question of what we n e e d to take into consideration in o r d e r to equip software engineers with the comp e t e n c e that is necessary to m a s t e r the diversity and difficulty of problems we are c o n f r o n t e d with in software engineering. Let me begin by briefly sketching what I m e a n by software engineering and what attributes can be derived t h e r e f r o m for a software engineer; then I will share some m o r e precise c o m m e n t s on software engineering education, concentrating primarily on the engineering aspects. Next I want to explicate, in my opinion, what e m p h a s e s absolutely n e e d to be part of a software engineering curriculum. My goal is to e n u m e r a t e general aspects rather than to formulate a specialized and detailed curriculum. F u r t h e r m o r e , I intend to touch briefly on w h a t should not, or no longer, be part of an u p - t o - d a t e software education curricu-
Correspondence to: G. Pomberger, Institut fiir Wirtschaftsinformatik, Johannes Kepler University of Linz, Linz, Austria. Email: [email protected].
lum because it is antiquated, is too trivial, was overrated, or fails to provide d e e p e r insights. T h e question of teacher qualification also needs to a c c o m p a n y a discussion of m o d e r n curriculum. I will briefly speak to this point at the end of my presentation. T h e questions of what we m e a n by software engineering and what characterizes a software engineer are not merely rhetorical. If we ask two persons about their conceptions about software engineering, we can expect to obtain three or m o r e answers. W h e n I speak of software engineering, I m e a n the practical application of scientific
knowledge for the economical production and the useful and economical employment of reliable and efficient software (see [1]). I would extend this definition with the assumption that an engineering a p p r o a c h and way of thinking is the key in this definition. W h a t do we m e a n by an engineering discipline? A n engineering discipline integrates aspects of synthesis, analysis and organization. A n engineer's c o m p e t e n c e is the result of f u n d a m e n tal theoretical knowledge, technical know-how, experience, and cost and application-oriented thinking.
0167-9287/93/$06.00 © 1993 - Elsevier Science Publishers B V. All rights reserved
288
G. Pomberger / Softwareengineeringeducatton
On this basis, we can summarize that a software engineer must be able to do the following
(cf. [2]): - specify, prototype, design, code, test, document and modify software systems utilizing state-ofthe-art software engineering technology; - plan, organize, estimate costs, schedule and track a software development or modification effort at the project leader level; - develop and identify reusable parts of software; - define and ensure software quality through the development and use of software metrics, standards, review procedures, and version and configuration management approaches; - assess advances in software engineering, apply them to projects and evaluate their effectiveness; - work with a n d / o r manage computer science specialists, programmers and other engineers in the development and modification of complex software systems; - build tools for other software engineers; and - serve as knowledgeable participant in system design when the question is considered which components should be built into software and which should not. In order to attain these competencies, it does not suffice only to accrue specialized knowledge. The software engineer must also be creative, cooperative and innovative, have the courage to try new ideas and to make decisions, and be willing to experiment. Today's best-known software systems and contributions to software engineering were made by persons who possess precisely these competencies (for example, programming languages and associated development tools such as Modula-2, Oberon and Smalltalk; algorithms such as quicksort, character string searching according to B o y e r / M o o r e ; Visicalc and all its spreadsheet successors - to name but a few). We are thus confronted with the question of how to fashion software engineering education in order to promote creativity and innovativeness. Can creativity be promoted at all? What are the limits of a university education? Although these are important questions that concern software engineering education, I will not treat them in further detail at this time. I will concentrate on the aspects specific to our subject area.
The current situation is such that we have observed considerable advances in research in the area of software engineering, yet most software produced nowadays proves unsatisfactory in quality despite enormous costs, and it by no means reflects scientific advances. What is the cause of this situation? The road from the software crisis to software engineering depends not only on scientific advances but also on the degree to which these results of research are made accessible to business and industry. Adequate education is, from my point of view, an important part of the solution to the software crisis. I claim that the software crisis is caused at least in part by deficiencies in our education. Universities are the most important and the leading institutions of education in our society. If we consider the current situation in software engineering, we need to ask whether this leadership role has been carried out by the universities. Have we concentrated too much on research and too little on teaching? Has our education been too theoretical and not practice-oriented enough? Or is the situation in industry (antiquated hardware, obsolete tools, inadequate standards, and so on) to blame for the inability of software engineering graduates to appropriately translate their software engineering knowledge into practice? Or is the shortage of graduates the cause of this unsatisfactory situation? What must be done to improve the situation is very multi-faceted. I will be dealing only with the aspect of the content and design of an up-to-date software engineering curriculum. ! will be sketching my very personal, and hence subjective, opinions about the general aspects of an engineering education and the emphases of a timely software engineering curriculum.
General cation
comments
on software engineering
edu-
The importance of theory According to the definition of software engineering that I gave, the goal of education is the competence to apply scientific knowledge practically in the production of software. The university's task is to transmit knowledge and insights. In this sense it would be irresponsible to teach the application of scientific knowledge without
G Pomberger/ Softwareengineeringeducatton first preparing the student for deeper understanding by means of the necessary fundamental theoretical knowledge. Just as a doctor of medicine requires elementary fundamental knowledge (for example, anatomy, chemistry) regardless of the chosen field of specialization, a software engineer must both know and master basic theory of the whole software engineering discipline. For software engineering this includes discrete mathematics and computer science theory. Frederick Brooks [4] appropriately formulated: "'The scientist builds in order to learn; the engineer learns in order to build." A central activity of engineers is the design of systems. Software systems are used above all for control of, or as components of, physical (technical or commercial) systems. On the basis of my observations and experience, I believe that engineers with experience in the design of physical systems without software engineering experience also tend to design better software systems than software engineers who lack experience in the design of physical systems. The theoretical fundamentals of engineering and scientific thinking, of systems theory and of the theoretical fundamentals for building hardware (physics, electronics, computer architecture) should thus also be part of the basic education for software engineering. I believe that engineering and scientific fundamentals and systems theory are underrepresented in software engineering curricula; likewise hardware-oriented aspects receive too little attention. More than just theoretical knowledge and insights are important. Engineering and scientific thinking and acting is an absolute precondition for any software engineer. The ability to approach a problem systematically, to handle it in a systematic and structured manner, and to document the solution; the ability to distinguish the relevant from the irrelevant; the ability to cooperate with clients, system users, and colleagues are important prerequisites for successful performance in engineering. Thus an adequate software engineering education should also include work methods. A colleague at the Research Institute of Symbolic Computation has for some years been very successfuUy offering a course entitled "Listening-
289
Reading-Thinking-Speaking-Writing-Cooperating". Although such approaches are very promising, they are too seldom included in a software engineering education. I believe that students should be exposed to both the technical aspects of programming and general techniques of problem solving, and not in an isolated way.
The importance of project-oriented education Learning and applying learning are two different things. Even after a good theoretical education, students are not yet engineers. Only the application of acquired knowledge to a concrete, reality-oriented problem makes it clear to what extent the theory was understood and whether and to what extent it is applicable to a concrete case. The real problems, difficulties, and hurdles only become clear when they are experienced. Al Peitrasanta [3] said: " A formal design language to express software engineering methodology is very powerful, but difficult to use. I compare it to learning your first programming language, in a course, or out of a book. You left it and said, 'Hah! Now I'm a programmer!' Then you started applying the language. You started programming. It might have been one, two, or three years later, when you reflected back and said, 'Now I understand. Now I'm a programmer.' It's the same thing in software engineering, applying a design notation; it takes a tremendous amount of application and experience, and trial and error to reach the point of proficiency. You can learn the syntax, you can learn the mechanics, but it takes a long time to apply it." Project-oriented education needs to be given more priority. This poses the question of how to carry out project instruction. Should this be parallel to theoretical instruction, or intermeshed with it, or should it be offered only after theoretical instruction has been completed? (Here we recognize that it is difficult to convince students of the value of theory without discussing its application.) In my opinion, theoretical instruction should always be accompanied by practical examples; that is, theory and practice should be intermeshed. The transition from theory to practice-oriented education can be made on the basis of case studies of complex software systems. Then students (in teams) can gain experience in translating their knowledge into practice by means of
290
G. Pomberger/ Softwareengineeringeducatton
programming practica and can obtain feedback concerning their progress from intensive reviews of their work. The only way to teach people to design is to have them design and criticize, have them redesign, and then have them build the design. Frederick Brooks [4] said, "Great designs come from great designers." That is the truth. We can learn a great deal by studying, analyzing and discussing excellent system architecture designs. This is why I consider such case studies especially important within the realm of a software engineering curriculum. I consider the analysis of complex, high-quality software systems and the discussion of the design aspects and approaches to a solution that they contain to be an efficient way to demonstrate the application of theory in practice and simultaneously to improve the design skills of the students. Discussions with colleagues and the analyses of software engineering curricula have shown that this method is used very rarely. One reason could be that such designs are not documented in books. I believe that a well balanced relationship between theory and practice is necessary, starting in the first years of software engineering education. Theoretical instruction must not be limited to mathematics and programming; it needs to include physics, electronics, computer architecture and general engineering fundamentals. Furthermore, intensive case studies of excellent system architectures need to be integrated into the curriculum. Following these general comments on software engineering education, I want to sketch several emphases of an up-to-date curriculum.
Emphases of software engineering education
Software life-cycle, prototyping, exploratory programming The life-cycle model is part of every software engineering education. The strict application of the classical sequential software life-cycle model requires that a given phase can begin only after its preceding phase is completely finished. This is in contrast to reality; for example: "We must take it as given that the user does not and cannot know what he wants with respect to artifacts as complex as those we now build. The mind of man
cannot imagine all the ramifications of such artifacts. There must be an iterative cycle in which the professional works with the user to define the requirements; demonstrates their consequences in human factors, cost, performance; then in a prototyping phase iterates with the user to develop a product that is, in fact, satisfactory [4]. While implementation is as late as possible in the classical life-cycle model (only after the specification phase has been completed), here we take the opposite approach and implement a prototype as soon as possible. We use other implementation tools for the prototype. The same applies to the design of the system architecture. It is practically impossible to attain an adequate system architecture on the first try. Here again, we are better served if the design is iterative and the products of the phases are verified by means of architecture prototypes. Exploratory and incremental design and implementation methods are growing in importance. This puts adaptability and maintainability in the foreground even during the development phase. Using these techniques changes the structure and procedures of the life-cycle model. The classical life-cycle model needs to be augmented in instruction by prototyping-oriented, exploratory and incremental development strategies. Concepts, methods and tools for these techniques and their ramifications for the software development process need to be a part of any modern engineering education.
Human-computer communication One trend that is strongly influencing the development of software today is human-computer communication. New measures of user comfort have been set by the combination of graphic screens, mice as pointing devices, windows and graphic user interfaces. But the user's paradise is a nightmare for the programmer. Basics, principles, techniques and tools for the creation and implementation of user interfaces are prerequisites for efficient programming, and these form an essential part of any modern software engineering education. The consequences of the construction and complexity of modern graphic user interfaces, of the use of application frameworks for the design of the architecture of software systems, etc., lead to a new procedure in the design of software systems. This requires the
G. Pomberger / Software engineermg education
29t
drastic revision of many software engineering textbooks.
systems must also be considered in the development of new software engineering curricula.
Thought models
Increased productivity through reusability and tools
Various programming languages build on the foundations of various thought models that profoundly affect the way the programmer thinks and thus the architecture of the products that are developed. We may distinguish (see [5]) imperative thought models, consisting at least of the algorithmically oriented thought model (supported for example by the languages Modula-2 and Ada), and the object-oriented thought model (supported for example by the languages Smalltalk, Oberon-2, and C + + ), and nonimperative thought models, consisting at least of the functional thought model (supported, for example, by the languages Lisp and Miranda) and the logic thought model (supported, for example, by Prolog). Various areas of application are covered to various extents by the different thought models; for example, the programming of graphic user interfaces is adequately supported by the object-oriented approach and the programming of rule-based systems by the logic-oriented approach. Software systems as they are being programmed nowadays tend to integrate various application areas ever stronger, and it has become more and more practical to develop hybrid systems. Software engineers should thus receive a solid foundation in all these thought models, not only in the algorithmically oriented thought model, as is often the case. Classical software engineering curricula tend to treat nonimperative thought models superficially if at all.
Aspects of increasing productivity belong to the tasks of an engineer. Hopefully, in the future we will have less people involved to produce the same result because we will have achieved a better productivity level. We have to train our students in developing reusable components. Object-oriented programming, class libraries and application frameworks are key issues in this direction. This means that we have to train our students in reusing existent components as it is usual in other technical disciplines. Another way to increase productivity is by means of a more automated development process than we have today. Applying theories, methods and principles can be significantly supported by the use of adequate tools, but this is unfortunately seldom done in software engineering practice. Both building and properly using tools are within the tasks of a software engineer and should also be part of any software engineering education. Since most commercially available tools are not state of the art, it is a good idea to develop simple tools in the realm of a project-oriented education.
Distributed systems and parallelism Computer networks continue to advance, and distributed systems are growing in importance for industrial and commercial applications. Since each network node of a distributed system is realized with its own computer with computing power and often considerable storage, the time has come to make use of parallel processing of problems. The use of multiple processor systems for the parallel handling of algorithms and for data exchange requires a new approach to the design of such systems. Theory and practice in the development of software for distributed systems on distributed
Documentation and maintenance It has long been clear that the greatest expense in the software life cycle falls on the maintenance of a software product. In the education of software engineers, the relationship is reversed. The problems of maintenance and approaches to solutions are usually not even discussed. Documentation shows a similar picture. In practice there has repeatedly been the cry to pay more attention to this aspect. I believe that the area of maintenance in particular is not adequately covered in our software engineering curricula. But can we teach maintenance? I do not believe that we are capable of teaching the maintenance of large software systems. The university cannot serve as a cornucopia. We need to add issues, tools, techniques of change control, configuration and version management, validation arkd verification, structure and content of software documentation, literate pro-
292
G. Pomberger / Software engineeringeducation
gramming, and so on, to our curricula, yet these are just prerequisites to getting a grip on the maintenance problem. Maintenance activities themselves are difficult to systematize and generalize. Experience plays a central role here, and gaining experience at the university is possible only to a limited extent. We can only make a small contribution in education. Testing and quality assurance Practice has shown that producing error-free software is almost impossible. This has given particular importance to testing and quality assurance. Testing and quality assurance encompasses complexity analysis, code inspection, walkthrough, review, formal verification, debugging, test case design, design of test strategies, and design and use of testing tools. Extensive theoretical and practical knowledge are required in order to incorporate this difficult process into software development. It is not sufficient to include testing only in the practically oriented part of software engineering education, that is, in project work; this must also be augmented by theoretical instruction. Project management Computer science curricula at technical universities and colleges often neglect the management-oriented aspects of software production, while for business-oriented curricula the reverse is often the case (that is, technical aspects are neglected). Unfortunately, my personal standpoint is that we must admit that scientific knowledge in the area of project management is rather modest. Failures due to technical shortcomings are often blamed on mismanagement. I do believe that management-oriented aspects, such as theory and structure of organizations, human relations and organizational behavior, oral and interpersonal communication, skills, cost estimation techniques, risk assessment, c o s t / benefit analysis, contracts and business plans, tools and techniques for planning, monitoring and controlling project schedules and budgets, are important components of a software engineering education and should ideally be included in software engineering curricula. But we must not overstress the management-oriented aspects. The technical problems are the more essential
ones. If we can solve these, then the management problems are easier to handle.
Further questions and comments I have enumerated several important emphases that belong to an up-to-date software engineering curriculum. We also need to ask what does not (any longer) fit into an up-to-date software engineering curriculum. Some of what we find in software engineering textbooks is antiquated, or is too specialized and does not contain fundamental insights, yet it is still taught. I believe that universities must remain on the cutting edge in both research and instruction; however, in software engineering the practicability of subject matter must also be weighed. Furthermore, because the fast growth of our field quickly produces redundancy, we must also be prepared to do some garbage collection of our own and eliminate the superfluous. It would be impossible to give a complete list, but I will enumerate several typical examples in order to demonstrate what I mean. First, allow me to show what I mean by antiquated. Specialized requirements and specification methods and tools such as S R E M (Software Requirements Engineering Methodology [6], P S L / P S A (Problem S t a t e m e n t L a n g u a g e / Problem Statement Analyser [7]) or H I P O (Hierachy plus I n p u t - P r o c e s s - O u t p u t ) for example are based on anachronistic concepts and formalisms that do not provide appreciable insights. Specialized design methods such as the Jackson Method [12,13] are too narrow in their range of application areas; the concepts on which they are based are merely a subset of the significantly more powerful attributed grammars (see [8]); the formalisms that are used are awkward. Thus today we can drop such things from our curricula. What do I consider to be too trivial for the university level? In software engineering curricula over and over again we find courses in various programming languages (unfortunately including ones like Cobol and Basic). Learning a programming language is trivial. One can expect university students to learn the syntax of a specific programming language in independent study. What is most important is that not the syntax but
G. Pomberger / Software engmeeringeducation
the concepts and thought models beneath the surface of programming languages should be taught. Since it has been my experience that many students come to the university without any programming experience, I could accept that the first programming language be taught; all additional languages, however, should be the responsibility of the student. The same is true of operating system functions and machine-oriented programming. Universities should not teach a specific job control language or assembler, but the principle tasks of an operating system, how operating systems are constructed, and the essence of machine-oriented programming. The syntax of a job control language or assembler should be learned in independent study or in courses outside software engineering. Courses like "Programming under U N I X " or " . . . M S - D O S " have no place in a university environment. What do I consider to be overrated? A n example of something whose value is overrated, in my opinion, is algebraic specification. The complexity of large software systems opposes any purely formal algebraic specification. Although algebraic specifications are unambiguous, they quickly become so extensive that they are difficult to understand and thus impede communication (which is an important aspect of specification). Please don't misunderstand: certainly algebraic specification techniques need to be taught, but their limits also need to be explained, and it should be said that when something can be expressed unambiguously in a few lines of prose, then this prose is to be preferred over a complicated and hard-to-read algebraic specification. Another example of exaggerated importance is that of empirical cost estimation models (such as the C O C O M O model [9], the Putnam estimation model [10], and function point models [11]). Experience has shown that the predictive capability of such models and their results has little relevance to practice. Software metrics is a similar case. In my opinion, scientific knowledge and empirical data do not yet suffice for software engineering practice. We need to be teaching the underlying concepts, as with programming languages, rather than specific metrics. I have compiled a list of emphases that form a framework for a software engineering curriculum,
293
and I have given some examples of what, in my opinion, should not be included in the curriculum. This list is by no means complete, but it does illustrate the essential aspects of the question of software engineering education, and it shows that our subject area has acquired an impressive breadth.
Comments on the qualifications of educators
I am convinced that instruction and research at the university level are inseparably bonded. A well-founded curriculum and good educational materials cannot be developed unless the educator is active in research. The software engineering discipline grows and changes as the result of scientific advances, which again influence the curriculum. It does not suffice to teach about methods. One must also be able to show how these are applied. I consider it an error to hire educators who do not have adequate research and project experience. Professors of software engineering must be masters of both theory and practice, and to a balanced extent. Although I perceive software engineering as the application of scientific knowledge, I do not believe that practice is more important than theory. Nothing is more practical than a good theory.
Conclusion
I hope that you are not disappointed that my presentation does not end with a detailed curriculum. My goal was to supply food for discussion on the question of relevance in software engineering education from a current point of view. I do not believe that the time is ripe to establish a standard curriculum for software engineering that would meet with general acceptance. Furthermore, I do not believe that we should set up a master curriculum for software engineering. Because, as Brooks reminds us, an essential part of what we taught in the past was wrong or is outdated and much of what we teach today will not be true in a few years, and a great deal of the rest will not be relevant (see [4]). Software engineering curricula must grow with changing technology. We have to adjust our sails continuously.
294
G. Pomberger / Software engineering education
References [1] G. Pomberger, Software Engineering and Modula-2 (Prentice-Hall, Englewood Cliffs, NJ, 1986). [2] J.E. Tomayko, Proposed curriculum for a master of software engineering (MSE), in: E. Gibbs, and R.E. Fairley, eds., Software Engineering Education (Springer, New York, 1987) 420-431. [3] A. Peitrasanta, Software engineering education in IBM, in: R. Fairley, and P. Freeman, eds., Issues in Software Engineering Education (Springer, 1989) 5-18. [4] F.P. Brooks, Jr., People are our most important product, in: E. Gibbs, and R.E. Fairley, eds., Software Engineering Education (Springer, Berlin, New York, 1987) 1-15. [5] P. Rechenberg, Programming languages as thought models, Structured Programming 11 (3) (1990) 105-115. [6] M. Alford, SREM at the age of eight; the distributed computing design system, Computer 18 (4) (1985) 36-46. [7] D. Teichroew and E. Hershey, PSL/PSA: A computeraided technique for structured documentation and analysis of information processing systems, IEEE Trans. Software Eng. 3 (1) (1977) 60-69. [8] P. Rechenberg and H. M6ssenb6ck, A Compiler Generator for Microcomputers (Prentice-Hall, Englewood Cliffs, NJ, 1989). [9] B. Boehm, Software Engmeering Economics (PrenticeHall, Englewood Cliffs, NJ, 1981).
[10] L. Putnam, a general empirical solution to the macro software sizing and estimating problem, IEEE Trans. Software Eng. 4 (4) (1978) 345-361. [11] A.J. Albrecht and J.E. Gaffney, Software function, source lines of code and development effort prediction: a software science validation, IEEE Trans. Software Eng. 9 (6) (1983) 639-648. [12] M.A. Jackson, Principles of Program Design (Academic Press, New York, 1975). [13] M.A. Jackson, System Development (Prentice-Hall, Englewood Cliffs, NJ, 1983).
Gustav Pomberger was born in 1949 • " ,,;,~.~. ..-..#. ' ,
in Gosau, Austria. He is an electronics engineer and a computer science ; engineer and holds a Ph.D. of techni'¢~ . cal sciences from the Johannes Ke: ..~ t" pler University of Linz, Austria. During 1968-1976 he was a designer of _,.di~i~ electrical machines. In 1976 he became a research assistant at the Computer Science Dept., University of Linz. In 1982 he was a visiting researcher at ETH-Zurich. Between 1984-1987 he was a professor of computer science at the University of Zurich. Since 1987 he has been a professor of computer science at the University of Linz. His research interests are: software engineering in general, prototyping, programming environments, human-machine communication, compiler construction, object-oriented programming.