The Software Engineering Body of Knowledge (SWEBOK), published in 2004, and now under revision, has influenced many software engineering graduate programs worldwide. In 2009, guidelines were published for graduate programs in software engineering (GSWE2009). GSWE2009, now sponsored by both the IEEE Computer Society and the Association for Computing Machinery, strongly rely on the SWEBOK but also recommends specific systems engineering knowledge for students to master. Today, an international team is creating a rigorous Systems Engineering Body of Knowledge (SEBoK) with the help of the IEEE Computer Society and the International Council on Systems Engineering and other professional societies. As it matures, the SEBoK should influence future versions of GSWE2009 and graduate program curricula worldwide. This panel will examine the influence of bodies of knowledge on both the creation of new graduate software engineering programs and the evolution of existing ones.

This special session will proved information about the status of work related to Masters programs in Computing. Specifically, the session will describe work completed in the following areas: the categorization of masters programs in computing, the development of curriculum recommendations for masters programs in software engineering, the collaborative work with the Association for Information Systems on the Masters program in Information Systems

A broad coalition of professionals from academia, industry, and government, under sponsorship of the US Department of Defense, is building a new model curriculum for a Masters Degree in Software Engineering (SwE). Before beginning to create such a model, a study of 28 programs was completed to determine the current state of SwE masters-level education in the US and abroad.

No abstract available.

Software engineering project management (SEPM) has been the focus of much recent attention because of the enormous penalties incurred during software development and maintenance resulting from poor management. To date there has been no comprehensive study performed to determine the most significant problems of SEPM, their relative importance, or the research directions necessary to solve them. We conducted a major survey of individuals from all areas of the computer field to determine the general consensus on SEPM problems. Twenty hypothesized problems were submitted to several hundred individuals for their opinions. The 294 respondents validated most of these propositions. None of the propositions was rejected by the respondents as unimportant. A number of research directions were indicated by the respondents which, if followed, the respondents believed would lead to solutions for these problems.

The correctness of semantic-syntax-directed translators (SSDTs) is examined. SSDTs are a generalization of syntax-directed translators in which semantic information is employed to partially direct the translator. Sufficient conditions for an SSDT to be “semantic-preserving,” or “correct,” are presented. A further result shows that unless certain conditions are met, it is undecidable, in general, whether an SSDT is semantic-preserving.

An experiment was conducted to evaluate the use of data abstraction and to assess its effects on program modification. Programs developed using data-abstraction were found to be substantially larger than equivalent programs developed without it, and the larger abstract-data programs were more difficult to modify. No significant differences in programming error rates were found between programs with or without abstract datatypes. A subtle violation of one of data abstraction's primary objectives, hiding data representation details, was observed. Programmers showed a strong tendency to include application-specific processing within procedures given data access privileges.

Abstract The quality of code generated by two commercially available FORTRAN preprocessors is examined. These preprocessors augment FORTRAN with ‘structured’ control structures such as the IF‐THEN‐ELSE and WHILE statements. Two versions of benchmark programs were written and tested, one version produced by the preprocessor, the other, performing the same computation, produced by careful hand‐coding directly in FORTRAN. The code generated by the preprocessor and the code written directly in FORTRAN were then compiled. The resulting object modules were then compared for relative execution time and size. This experiment was repeated on three computers, and five compilers with various optimization levels. The results indicate that a substantial overhead in storage space may be paid by using a preprocessor rather than direct coding in FORTRAN, and that in some cases execution time may be increased somewhat by using a FORTRAN preprocessor.

Abstract One of the major purposes of a high‐level language is to provide a large measure of machine‐Independence in the specification of algorithms. Definitions of languages such as FORTRAN IV and ALGOL 60 encourage compatibility between various implementations. Language specifications are inadequate in that they normally underdefine a language. In particular, the specifications do not normally demand a response to a language violation. The freedom normally given to an implementor to decide the degree and nature of error detection and response hinders portability and may lead to‐unexpected results when moving code from one machine to another or even when changing implementations on the same machine. To support the contention that languages should specify a response to violations, an analysis of four FORTRAN IV implementations and a FORTRAN IV verifier was conducted. The study showed that different implementations often lead to different results for the same illegal program. A study of programmers also revealed that they cannot be relied upon to avoid language violations without compiler aids.