Forging a discipline: An outline history of software engineering education

Software engineering education has a 30-year history. It is a story of academics struggling to fulfill industry needs with almost no support from computer science curriculum designers. It is a story of industry finally winning over some of academia to teach software engineering rather than vanilla computer science. It is a story of a discipline still incomplete, but having made great strides in the last decade. This paper discusses the succeeding eras of software engineering education, from lone teachers to master's curricula to undergraduate degree programs. Even though the maturity of the discipline is as yet unattained, it will achieve adult status through practice, not by waiting for academia to glacially catch up.     

Toward a discipline of software engineering

Despite rapid changes in computing and software development, some fundamental ideas have remained constant. This article describes eight such concepts that together constitute a viable foundation for a software engineering discipline: abstraction, analysis and design methods and notations, user interface prototyping, modularity and architecture, software life cycle and process, reuse, metrics, and automated support     

Prospects for an engineering discipline of software

Although software engineering is not yet a true engineering discipline, it has the potential to become one. Older engineering fields are examined to ascertain the character that software engineering might have. The current state of software technology is discussed, covering information processing as an economic force, the growing role of software in critical applications, the maturity of development techniques, and the scientific basis for software engineering practice. Five basic steps that the software engineering profession must take to become a true engineering discipline are described. They are: understanding the nature of expertise, recognizing different ways to get information, encouraging routine practice, expecting professional specializations, and improving the coupling between science and commercial practice     

Toward an engineering discipline of software reuse

This article stems from a panel session at the 1997 Symposium on Software Reusability, and discusses open research issues, classified by goal and by approach. Software development cannot possibly become an engineering discipline so long as it has not perfected a technology for developing products from reusable assets in a routine manner, on an industrial scale. Software reuse cannot, in turn, achieve this status unless we make the following provisions: a sound scientific foundation that encompasses relevant design principles, widely acceptable engineering standards that compile these principles into working practical solutions, and coherent managerial standards that enable the deployment of these solutions under acceptable conditions of product quality and process maturity. Although successful software reuse experiments are increasingly common, success is not the norm, software reuse is not a matter of routine practice, the promises of software reuse remain for the most part unfulfilled, and a number of issues remain worthy of further research     

Professional software engineering education

How might universities organize new lines of business in software engineering professional education? Professional education enables practicing professionals to achieve defined levels of competence and to be certified according to standards in their professions. This kind of education is offered at very few universities. This paper proposes a conceptual framework for designing professional education programs; software engineering is the central example. It suggests a strategy for combining traditional degree programs and professional certificate programs, in any mix suitable for a department and its clientele.     

Reflections on software engineering education

The "engineering" focus in software engineering education leaves instructors vulnerable to several traps. It also misleads students as to SE's essential human and social dimensions. Here, the author discusses how this limited conception of SE contributes to five assumptions that can trap SE educators: (i) an SE course needs an industrial project. (ii) SE is like other branches of engineering. (iii) Planning in SE is poorly done relative to other fields. (iv) The user interface is part of low-level design. (v) SWEBOK represents the state of the practice.     

Opportunities for software engineering education

Software engineering is entering the educational mainstream at a time when budgets are tight, growth opportunities are limited, and existing disciplines are fighting to retain their share of a shrinking educational pie. This paper discusses some of the fundamental reasons why this situation is not likely to improve, and addresses ways software engineering can utilize modern computing and communication technology to overcome these limitations and, indeed, to lead the way in innovative education.     

从社会需求的角度探索软件工程教育

如何培养社会需要的软件人才,是大学教育需要探索的问题之一。本文根据SE2004对软件工程的毕业生的要求,提出了一些加强学生能力的方法和建议,包括实例教学、分组学习、软件工程实验室的建设等多方面的内容。     

An experience in collaborative software engineering education

Large-scale software development requires the interaction of specialists from different fields who must communicate their decisions and coordinate their activities. As global software development becomes mainstream, software engineers face new challenges for which they have received little or no training. To help a new generation of software developers better understand the industry's globalization and familiarize them with distributed, collaborative development, we designed a course entitled the Distributed Software Engineering Laboratory. In the class, pairs of students from different countries work as a virtual organization overseeing the whole software development process. We describe the lessons we have learned in this course and propose a framework useful in dealing with some of the difficulties participants face     

Balancing software engineering education and industrial needs

In the world of information and communications technologies the demand for professionals with software engineering skills grows at an exponential rate. On this ground, we have conducted a study to help both academia and the software industry form a picture of the relationship between the competences of recent graduates of undergraduate and graduate software engineering programmes and the tasks that these professionals are to perform as part of their jobs in industry. Thanks to this study, academia will be able to observe which skills demanded by industry the software engineering curricula do or do not cater for, and industry will be able to ascertain which tasks a recent software engineering programme graduate is well qualified to perform. The study focuses on the software engineering knowledge guidelines provided in SE2004 and GSwE2009, and the job profiles identified by Career Space.     

Software engineering as a scientific and engineering discipline

A new interpretation of software engineering from scientific, engineering, and practical standpoints is proposed. Software engineering is defined as a successor of programming and computer science, namely, its management theory. Features and attributes of software engineering as an original discipline are founded. The structure, content, and concepts of this discipline and its basic elements are presented. __________ Translated from Kibernetika i Sistemnyi Analiz, No. 3, pp. 19–28, May–June 2008.     

Change the face of software engineering education: A field report from Taiwan

Context: In Taiwan, the supply of software engineers provided by universities has suffered from both a quantity problem and a quality problem. An effort to change the software engineering education is in need.Objective: The Software Engineering Consortium (SEC) of Taiwan sets its objective to increase the number of college graduates that are better prepared for filling software development and maintenance jobs.Method: Four dysfunctions: avoidance of process, inattention to modeling, lack of awareness to software quality, and chasm between application domains and software engineering, of the current situation are identified. The effort to correct the dysfunctions involves design of a module-oriented software engineering curriculum, and organization of people, resource, and activities.Results: In the academic years from 2003 to 2008, both the number of software engineering courses offered and the enrollment size increased significantly by a space of some 250 courses and 5000 enrollments, respectively.Conclusion: The SEC effort to establishing software engineering modules has been received with enthusiasm by faculty members and students of the participating institutes. Inspired by the important foundational work such as SWEBOK and SE2004, we believe that the adopted strategy of identifying dysfunctions and then designing remedies to address these dysfunctions contributed significantly to the success of the SEC effort.     

Need for well-balanced education in software engineering measurement

This paper deals with a perceived need for a well-balanced education (or in some cases re-education) in the subject of software engineering measurement, more commonly although less accurately known as software metrics. This need was confirmed by a major survey of both industry and academia conducted in 1989.Software metrics have received a lot of bad press in the past, mainly due to some much criticized early work in so-called complexity metrics. A result of this has been scepticism or lack of interest in other areas of the wider subject of software engineering measurement, which covers not only models and measures applicable to software products, but also those applicable to the processes and resources involved in software production.The ideas and work described in this paper have arisen out of the ESPRIT project METKIT, which has produced educational material about software engineering measurement for use in both industry and academia. This paper also describes the material designed for academia, most of which has now been tested in 12 European academic institutions. The material concentrates on principles and examples rather than prescribing the use of particular models and measures.This material has been widely publicized; the response to it has been encouraging so far and it appears that the material will have a significant impact towards getting the subject taught much more widely, and in a more balanced way.     

Developing the requirements discipline: software vs. systems

The software engineering and systems engineering communities are establishing methods for capturing, specifying, and managing requirements. The cultural differences exist between the two. Requirements work is too important to be pioneered by a mainstream software-centric or -ignorant viewpoint. Each community must continue to learn from the other for our understanding of the requirements engineering discipline to continue to grow.     

Package-oriented software engineering: a generic architecture

New methodologies and better techniques are the rule in software engineering, and users of large and complex methodologies benefit greatly from specialized software support tools. However, developing such tools is both difficult and expensive, because developers must implement a lot of functionality in a short time. A promising solution is component-based software development, in particular package-oriented programming (POP). POP fails, however, to satisfy all the requirements of large, complex software engineering tasks. A more generic POP architecture would better serve the development of software engineering environments for large and complex methodologies. Such an architecture emerged from our development experiences with two software engineering research tools: Holmes, a domain analysis support tool; and Egidio, a unified-modeling-language-based business modeling tool. We found this particular architecture simple to understand, easy to implement, and a natural candidate for a generic POP architecture. Our generic architecture satisfies the additional requirements we deem important for larger, more complex software engineering activities. Our experiences show that the strength of this architecture lies in its simplicity and ability to work with multiple users and quickly integrate a wide variety of applications. It is not perfect, but we present it as a first step toward a more general package-oriented architecture to encourage further research in this area     

Value-based software engineering: a case study

The information technology field's accelerating rate of change makes feedback control essential for organizations to sense, evaluate, and adapt to changing value propositions in their competitive marketplace. Although traditional project feedback control mechanisms can manage the development efficiency of stable projects in well-established value situations, they do little to address the project's actual value, and can lead to wasteful misuse of an organization's scarce resources. The value-based approach to software development integrates value considerations into current and emerging software engineering principles and practices, while developing an overall framework in which these techniques compatibly reinforce each other.     

Simulating a software engineering apprenticeship

We examine the prevailing software engineering (SE) body of knowledge and perspectives on SE education to construct a model comprising knowledge areas for SE professional development. We use this model and Benjamin Bloom's taxonomy to delineate knowledge areas that an apprenticeship could best handle. We then establish a framework for SE apprenticeship, which we use to examine practices for apprenticeship simulations in three academic institutions that offer computer science (CS), applied CS, or computing systems curricula.     

Function-class decomposition: a hybrid software engineering method

In addition to offering a simple yet powerful method for decomposing a system, function-class decomposition (FCD) produces an architecture that is more supportive than traditional object-oriented decomposition for several software engineering tasks. A hybrid method that integrates structured analysis with an OO approach, FCD identifies classes in parallel with decomposing the system into a hierarchy of functional modules. Recently, developers extended FCD to integrate UML concepts. Useful for partitioning a system for distribution, the FCD hierarchy provides a framework for controlling development in a distributed software engineering environment. It also helps identify and integrate components in component-based development and supports the system life-cycle maintenance phase. Further, FCD addresses many of the initial analysis and design problems inherent in large and complex OO systems. The authors' experience with testing FCD on several applications validates its compatibility with OO methodologies and modeling techniques     

Standards: defining software engineering as a profession

The need for standards of personal accountability for professionals working in the field of software engineering is examined. The field is defined, and the technical expertise and entry-level requirements that it requires are identified. Ways to initiate the process of obtaining a broad professional consensus on the norms of the software engineering field are proposed