Overhead in FORTRAN preprocessors

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.     

Error-checking compilers and portability

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.     

Guest Editors' Introduction: Software Engineering Project Management 20 Years Later

A little more than 20 years ago, the guest editors assembled several papers on software engineering project management for the January 1984 edition of IEEE Transactions on Software Engineering. Those papers portrayed the state of the practice in SEPM and looked into its future. They decided to revisit SEPM and assemble another set of articles that reflect how SEPM had advanced over the past 20 years and offer a fresh prediction of what lies ahead.     

Master's Degrees in Software Engineering: An Analysis of 28 University Programs

The Software Engineering Institute published the last reference curriculum for a master's in software engineering in 1991. In 2007, a coalition from academia, industry, and government began creating a new reference curriculum. An early step was to establish a baseline of graduate education by surveying 28 master's programs in software engineering. The survey was largely limited to US schools. Key findings showed that the universities viewed software engineering largely as a specialization of computer science, that faculty size is generally small with few dedicated professors, and that new master's programs continue to start despite the decrease in computer science majors over the past few years. We used the IEEE Computer Society's Software Engineering Body of Knowledge (SWEBOK) to structure our analysis of the 28 curricula, focusing primarily on courses and topics required or semirequired of all students. (A course is semirequired if there is at least a 50 percent chance a student must take it.) Major findings show wide variation in the depth and breadth of SWEBOK coverage in required and semirequired courses, less than 40 percent of all programs requiring an introductory course on software engineering, and many universities having required and semirequired courses that are peripheral to SWEBOK.