Software Engineering: History

Software Engineering: History

Center for International Science and Technology Policy, George Washington University, Washington, District of Columbia, U.S.A.

Abstract

Software engineering has its roots in the difficulties of developing large software systems but has grown into a field that specifies, designs, creates, deploys, and maintains software systems. In developing its methods, it has drawn heavily from other engineering fields, notably industrial engineering and quality control.

INTRODUCTION

At the start of the computer age, all of the engineering tasks involving computing technology focused on hardware: the design and debugging of electronic circuits, the organiza-tion of logical devices, the machinery of printers, disk drives and other elements, and the operation of compli-cated systems. Programmers began to develop an engineer-ing discipline for software only as they began to appreciate the problems of describing, coding, and delivering soft-ware systems.

As it was originally conceived, software engineering was to be the discipline that would guide the development of programs that were too big and complicated for any single individual to handle. In the early days of the field, it was often called “programming in the large.” In an effort to bring some order to this work, early programmers looked to some of the basic concepts of the traditional engineering fields. They borrowed the idea of interchangeable parts from mechanical engineering and transformed it into the concept of standard program libraries. From civil engineering, they took the ideas of standard practices and standard handbooks and used them to define a standard body of knowledge. From electrical engineering, they borrowed black-box design techniques and redeveloped them as means of hiding information and simplifying systems.

As the concepts of “programming in the large” began to change into those of “software engineering,” the advocates for this new field began to redefine its purpose and methods. Large “programming projects suffer management problems different in kind from small ones,” wrote Fred Brooks, a computer scientist at IBM who helped create the OS/360 operating system. “I believe the critical need to be the preservation of the conceptual integrity of the product itself.”[1]

In their efforts to preserve that identify of their crea-tions, the pioneers of software engineering created disci-plines for identifying, describing, and evaluating software systems. In developing this field, they drew their ideas not

only from the older engineering fields, but also adopted ideas from the new disciplines of industrial engineering and of quality control and process improvement. In bor-rowing these ideas, they modified them, sometimes radi-cally, to fit the new field of software development.

BEFORE SOFTWARE WAS ENGINEERED: 1946–1967

The field of software engineering is built upon the concept of the program, a list of instructions that can be executed by a specially designed machine. This concept predates the construction of the first electronic computer. It is found in the work of Charles Babbage, who described a mechanical programming device in 1838, and Alan Turing, who cre-ated an abstract computing device in 1936 for his research in mathematical logic.[2,3]

While the invention of the electronic stored program computer remains a disputed topic in the history of com-putation, most historians acknowledge that the fundamen-tal document of programming is John von Neumann’s “Draft Report on the EDVAC.”[4]Written in the summer of 1945, this entry describes the basic architecture of the stored program computer and the basic nature of comput-ing instructions. It explained the fundamental idea of pro-gramming to the first generation of computer pioneers.

Initially, many computer designers viewed program-ming as a minor task, something that ought to be much simpler than the work of designing and building a comput-ing machine. The “codcomput-ing process is essentially a clerical operation,” argued a pair of early pioneers in the field.[5] Yet, those individuals who were actually engaged in prac-tical tasks of writing code quickly began to understand the complexity of coding and the need for a systematic approach to the preparation of programs.

One of the first programmers to appreciate the difficulties and subtleties of programming was Herman Goldstine, who worked closely with von Neumann and

Software

–

Subdomain

Encyclopedia of Software EngineeringDOI: 10.1081/E-ESE-120044178

directed von Neumann’s computer project at the Institute for Advanced Study. Goldstine wrote some of the earliest papers on programming in the spring of 1947. In them, he explained that programming involved problems that “are not hypothetical or exceptional.” He noted that it “does not take a deep analysis of any inductive or iterative mathematical process to see that” such problems are very common.[6]

One of the most common problems faced by Goldstine and other early programmers was the problem of mapping the program in the limited amount of memory that was available on the first machines. They found that they had to think of ways to minimize the number of instructions that they used, find efficient strategies to allocate registers, and even keep track of the location of every instruction in the program. With such problems before them, the program-mers could not easily think about larger issues such as the documentation for their code, the interaction with other programs, or the options for future modification.

Recognizing that he needed to think about those larger issues, especially the interaction of different programs, Goldstine developed a systematic process that helped him structure the programs and track the operation of the com-puter, a process that suggested the further development of software engineering. In the first step of this process, he would identify the goal of his program, the inputs that it would take, the outputs that it would produce, and the method that it would use for computation.

As a second step, he would draw a detailed chart that would express the logic of the program in lines and loops. He borrowed the idea for these charts from mathematical graph theory and called them “flow diagrams.” In his first papers, on programming, he developed a basic grammar for these diagrams and indicated what each loop and curve might mean.[6] Other programmers adopted Goldstine’s graphical procedure and expanded its vocabulary of sym-bols. Many of them borrowed from the ideas that the IBM corporation used to describe the operation of its punched card machines. Barely a decade after Goldstine described programs with graphs, the programmers of the early IBM computers moved to standardize these graphs. They renamed them “flow charts,” restricted the number of symbols to a fixed number of forms, and created rules for using these symbols.[7]

Though the early programmers quickly employed the idea of flow charts, they were reluctant to adopt other ideas from engineering. Part of this reluctance came from the fact that many of the early programmers did not have an engineering education and were entirely unfamiliar with engineering methods. The largest programming project of the early 1950s, the Semi-Automatic Ground Environment or SAGE, ultimately employed over 1000 programmers but few of these individuals had an engineering back-ground. “People were recruited and trained from a variety of walks of life,” noted one leader of the SAGE program-ming group. “Street-car conductors, undertakers (with at least one year of training in calculus), school teachers,

curtain cleaners and others were hastily assembled, trained in programming for some number of weeks and assigned parts in a very complex organization” (J. I. Schwartz[8]). One internal document suggested, “music teachers were particularly good subjects.”[9]

The SAGE project was managed by the RAND Corporation for the U.S. Air Force and it laid the founda-tion for the field of software engineering. Its programmers formed one of the important software firms of the age, the Systems Development Corporation, and its work identified the problems of large system development. Many program-mers, particularly those working on military projects, paid close attention to the problems encountered by the SAGE staff. They were especially interested in the cost of produ-cing error-free code. The project showed that software development was a costly endeavor. “If you include pro-grammer training and necessary research and develop-ment, the cost is astronomical,” noted one report. “Even if you omit these charges, the cost is probably in the range of $25 to $75 per instruction.”[10]

During this period, many projects tried to reduce the costs of development by creating libraries of common routines that could be used for multiple programs. The SAGE programmers created the Lincoln Laboratory Utility Library. A group of companies that used IBM equipment formed a cooperative library called SHARE. The Association for Computing Machinery (ACM) orga-nized a standard algorithm program to collect routines that would compute mathematical functions, do basic data con-version, handle a variety of scientific tasks, and even handle the fundamental work of data processing.

Of these standard libraries, the ACM library marked a substantial step in the field of software engineering. It not only collected useful routines, it also developed standards for describing algorithms and a process for validating them. Most of the other libraries of this period, including those of SAGE and SHARE, were collections of code that came with no guarantee beyond the fact that some organi-zation had been able to use them. The ACM could not state that all of its algorithms were perfect but it could point to a public process that had been applied to each submission in attempts to minimize errors.

One of the standards for the ACM library was the use of a higher-level language, ALGOL-60, to describe the algo-rithms. These languages represent another important step toward the engineering of software. They freed program-mers from details such as memory management and data conversion, and shifted their attention to the nature of the problem that they were trying to solve. FORTRAN (1957) came from IBM and was quickly adopted by the scientific community. COBOL (1959) was developed by the U.S. Department of Defense and was designed for data proces-sing problems. ALGOL (1958/60) came from an interna-tional consortium and was designed for systems programs and general algorithms.

Software

–

A final step in the early development of software engi-neering was the introduction of new kinds of machines, computers that could utilize the high-level languages and could run multiple programs at the same time. These machines included the IBM System/360 (1964), the CDC 6400 (1963), and the Burroughs B-5000 (1965). Dubbed “third generation” computers by the popular press, these machines expanded the market for software. In particular, the System/360 offered a range of models that could all execute the same programs.

The third-generation machines contributed to a problem that became known as the “software crisis.” As more and more firms bought these machines, they found it harder and harder to find programmers. “A growing shortage of qua-lified personnel has the computer industry in a quandary,” reported the New York Times in 1968. “In the regular computer field, there are about 40,000 computers in opera-tion and this figure is expected to double in the next few years.” It added, “many thousand more experts will be needed in the next decade if the industry is to continue to function properly and to continue expanding.”[11]

The growing demand for programmers forced the engi-neering professions to consider how they should address the problems of the perceived software crisis. “Clearly, offering a few courses on logical design, switching circuits, pulse and digital circuits, programming etc. does not con-stitute an adequate contribution by electrical engineering to computer sciences at a time when the Federal govern-ment alone is spending 1.2 billion dollars a year on the acquisition and operation of its computers,” wrote the electrical engineer Lofti Zadeh in 1965.[12]

Yet, at this time, many engineers were not convinced the work of preparing programs was indeed an engineering discipline. Zadeh complained about the “slowness with which many electrical engineering departments have reacted to the rapidly growing demand for computers scientists,” and observed that “at some universities, more receptivity to computer sciences is shown by mathematics than by electrical engineering.”[12]

While mathematicians could contribute many ideas to computer science, they generally did not have the skills for the work of preparing large, complicated systems. “The basic problem is that certain classes of systems are placing demands on us which are beyond our capabilities and our theories and methods of design at this time,” argued one system designer. “We should not expect the production of such systems to be easy” (K. Kolence[13]).

A few computer scientists, notably C. A. R. Hoare in England and Edsger Dijkstra in the Netherlands, took the first steps to develop theories of large programming. In particular, Dijkstra created a theory for large systems that he called Structured Programming.[14] This method divided a large system into units that could be organized in a layered hierarchy. He had demonstrated this method by writing a simple multiprogramming operating system.

“It is not my intention to under-estimate the organizing ability needed to handle a much bigger job,” he admitted, “but I should like to venture the opinion that the larger the project, the more essential the structuring.” It was not a complete method, but it at least provided a foundation on which software engineering could be built.[15]

The term “software engineering” began to appear in the literature in the fall of 1966. Though many were not ready to adopt it, the phrase was endorsed by one of the ENIAC designers, J. Presper Eckert, at the Joint Computer Conference.[15]Eckert used the term to refer to the creation of large systems but others began to see that it might refer to a broad set of skills that might be used for the design and construction of any system.

NATO CONFERENCES ON SOFTWARE ENGINEERING: 1968–1969

In the fall of 1968, 50 mathematicians, engineers, and computer scientists gathered at a resort hotel in Garmisch, Germany, to talk about the problems of pro-gramming and large systems. The conference, which initiated formal discussions about the methods of software engineering, was organized by the Science Committee of the North Atlantic Treaty Organization (NATO). The members of this committee had become concerned about the stories of a software crisis and the problems that they had witnessed in the preparation of large military systems. Even as the conference began, many participants were not certain that programming was indeed an engineering discipline. One of the leaders of the group admitted that the title “software engineering” “was deliberately chosen as being provocative, in implying the need for software man-ufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the estab-lished branches of engineering.”[13]Still, several members of the conference including both Dijkstra and the chair, Alan Perlis of Carnegie Melon University, were convinced that software needed rigor of engineering.

Perlis opened the meeting by explaining that the parti-cipants were “going to concern ourselves here with the design, production, and servicing of objects which are complex and automatic, mechanical and symbolic, whose performance and decay, breakdown and efficiency depend in only very weak ways on the laws of physics.” He had been observing the work of software development for many years and had concluded “problems arise from demands, appetites, and our exuberant optimism. They are magnified by the unevenly trained personnel with whom we work” (A. Perlis[13]).

The members of the conference discussed practical systems that followed the concepts of industrial engineer-ing. They quickly agreed that software was developed in a four-step cycle that mimicked the quality control cycle that had been designed by Walter Shewhart. This cycle began

Software

–

by specifying the goals of the system, designing the sys-tem, coding and documenting the actual programs, and debugging the system. Once the fourth step was completed, the process would return to the start. Programmers would specify the errors that needed to be corrected and new features that needed to be added. From that point, they march through the remaining steps of the development cycle and would return again to the start.

Only one participant, M. Douglas McIlroy, looked beyond the techniques of production software to consider other engi-neering tools that might improve programming systems. He was particularly interested in the idea of interchangeable soft-ware code. “My thesis is that the softsoft-ware industry is weakly founded, and that one aspect of this weakness is the absence of a software components sub-industry,” he argued. “There do not exist manufacturers of standard parts, much less catalogues of standard parts. One may not order parts to individual speci-fications of size, ruggedness, speed, capacity, precision or character set” (M. D. McIlroy[13]).

Yet, the idea of constructing interchangeable parts never really engaged the conference. Most identified sub-assemblies with the standard libraries that had begun to appear a decade before. The group was far more interested in discussing the market value of software. In 1967, all of the computer manufacturers provided free software, usually operating systems, compilers, and utilities. Some suggested that software was actually a product with value and should carry a price. The conference discussed the point but did not take a position on the question.

Just a few weeks after the end of the conference, on December 6, 1968, IBM announced that it would place a price on all of its software products and would allow customers to purchase software from other vendors. This announcement, usually called the “unbundling decision,” is generally identified as the start of the software products industry. However, software “did not walk into an optimistic boundless future,” wrote historian Martin-Campbell-Kelly, “but into the industry’s most turbulent decade.”[9]Much of that turbulence was caused by economic hardship in a reces-sion that affected the computer industry.

Some of that turbulence was evident in the second NATO conference on software engineering, which was held in Rome the following year. The “Garmisch spirit did not survive the journey across the Alps,” wrote one organizer, “and the conference was a much less successful affair.”[13] The Rome conference covered many of the same topics as the meeting in Garmisch; however, many of the discussions were more structured than those of a year before, more earnest, and, at times, more angry.

The state of software engineering cannot be assessed by the lack of camaraderie among those who attended the Rome sessions. If anything, the conflicts showed that the Garmisch participants had established the field of software engineering and were beginning to identify the key issues of the field. Many were promoting their own approach to the problems of designing and implementing software

systems. Some of these approaches, such as the one pro-moted by Edsger Dijkstra, drew strong criticism from others. However, these discussions showed that software engineering had become an engaging and vibrant field in less than a year.

DEFINE THE FIELD: 1970–1985

In the years that followed the NATO conference, computer scientists expanded the fundamental concepts and tools of software engineering. They augmented the cycle of software development to include five steps:

1. System specification 2. System design 3. System programming 4. System debugging 5. System maintenance

During the early 1970s, they devoted a substantial amount of time to the first step in the process, to developing the goals of a software system and expressing them in a formal language. Though this step can be considered less technical than other aspects of software engineering, it proved to be a substantial challenge for many of the early software engi-neers. The needs “are often impossible to realize until after a system is built,” noted an early researcher. “Even when requirements are stated up front, it is likely they will change at least once during development and it is certain they will change immediately after deployment.”[16]

Most of the early efforts to develop methods of system specification built directly on Dijkstra’s concepts of struc-tured programming, which identified individual actions and then assembled them into a layered organization. Some of the more influential work of this period was articulated by Douglas Ross, who worked for SofTech and was involved in a large Computer Aided Manufacturing Program for the U.S. Air Force. In 1972, he developed a technique that he called Structured Analysis and Design Technique, which expressed the goals of the system in a large diagram that resembled flow charts.[17]

Ross’s work was expanded by others, who looked to define systems requirements in English or a formal lan-guage. An early example of such an approach would include the Software Requirements Engineering Methodology. It expressed systems specifications in English and was devel-oped by the TRW Corporation for the U.S. Army.

The second step of the software life cycle, system design, also progressed rapidly during the early 1970s and built upon the ideas of structured programming. Many key contributions came from David Parnas and his colleagues. Parnas studied the problem of dividing large systems into small pieces. He argued that programmers could minimize the number of errors in their final product if they adopted a strategy that hid information in the basic

Software

–

subdivisions of the system. A programmer should begin “with a list of difficult design decisions or design decisions that are likely to change,” Parnas explained. “Each module is then designed to hide such a decision from the others.”[18] The third step of the software life cycle, that of pro-gramming, was well defined by the early 1960s and it had been heavily discussed at both NATO conferences. In this step, software engineers looked to produce code that was inexpensive, efficient, and easy to understand. At the NATO conference, they had approached this step by talk-ing about how they should educate, train, and manage programmers. Beginning in the start of the 1970s, they began to discuss tools that might simplify the production of code, a strategy that borrowed from the more traditional engineering disciplines.

The most fundamental programming tool, the program-ming languages, was evolving rapidly at this time. Computer scientists worked to develop alternatives to low-level assembly languages with languages such as C (1973). They simplified the creation of applications with Pascal (1971). They reduced complexity by hiding infor-mation with Smalltalk (1971/80) and Modula-2 (1982). The most ambitious language project of the era was the one that developed a comprehensive language, Ada (1975), for the U.S. Defense Department.

The Ada project began with the work of Barry Boehm, who was an employee of the TRW Corporation. Boehm was not a programmer or a system designer but a software engineer who studied the cost of programming. Boehm had done a study of software costs for the U.S. Air Force, and concluded that software had become more expensive since the NATO conferences, not less expensive. In particular, his work had identified “the proliferation of programming languages as having a major impact on costs.”[19]

Though Ada was never as widely used as its proponents desired, it promoted the ideas of structured and modular programming. It also drew attention to the value of the programming tools that supported systems development, tools such as editors, debuggers, simulators, and the like. “The design, implementation, delivery, and maintenance of software are complex and expensive activities that need improvement and better control,” wrote one engineer. “Among the technologies proposed to achieve these goals,” he continued, “are the tools that form the basis of Computer-aided Software Engineering or CASE.”[20]

Following the start of the Ada project, the CASE approach to software engineering grew rapidly. Programmers created tools to deal with each step of the software life cycle. For the first step of this cycle, the CASE approach produced project management tools and machine-readable ways of describing systems. For system design, it produced rapid prototype languages. For the coding step, it created more sophisticated programming environment. For the last two steps, those of debugging and maintenance, it produced symbolic debuggers and test generators.

Tools that could help test software systems had begun to appear shortly after the NATO conference. Again, the U.S. Military played a central role in developing such tools. Less than 5 years after the second conference, the militarys had developed a series of tools and testing procedures with the TRW Corporation. Called the Produce Assurance and Confidence Evaluator or PACE, this system could empiri-cally verify code and also identify sections that had not been tested.[21]

Yet, such tools were of limited use without a formal theory that explained how they might detect an error. “Program testing can be used to show the presence of bugs,” wrote Edsger Dijkstra, “but never their absence.”[22] The TRW researchers acknowledged that their work would not validate all software completely. A “significant pro-blem which pervades all software development is a lack of knowledge as to how much testing of a software system or component constitutes sufficient verification,” they explained.[21]

The work to build a theory of software errors began in the mid-1970s with the efforts of two mathematicians, John Goodenough and Susan Gerhart. Goodenough and Gerhart identified the basic concepts that have formed the basis for software testing. The first is a stopping rule, which deter-mines sufficient testing has been done. The second is a measure of adequacy that suggests the amount of errors that remain in the code.[23]

The mathematical theory of errors was only the second part of a larger problem that required a fuller set of engi-neering skills. By the end of the decade, software devel-opers recognized that system testing required an effort just as sophisticated as the work required to design and code a system. A “well-planned test approach will start in parallel with program development,” explained one program lea-der, making it possible “to introduce design and coding constraints that will assist testing, to plan the testing effort properly, and to detect errors at the earliest possible time so that they may be corrected with minimum time and effort.” By 1980, the U.S. Department of Defense had established a testing procedure known as Independent Verification and Validation.[24]

The final step of the software development life cycle, that of maintenance, was the last to develop. Yet, well before the end of the 1970s, it was realized that it was a substantial part of software life cycle. In 1979, Barry Boehm noted that maintenance costs had already begun to “outweigh development costs.”[25]Yet, less than 3 years later, engineers had begun to structure this element of software development. “The problem is not so much related to technology is it is related to execution,” observed one developer. “The tools and techniques for effective maintenance are readily available. Their actual use seems to be skimpy and undisciplined.”[26]

This step of system maintenance secured its place in the software life cycle just as software became a recognized product. In September 1980, Business Weekran its first

Software

–

cover story on the software products industry. This story indicated that the computer industry had not only survived the relatively slow growth of the 1970s, but had developed a new and important sector. This sector was not only supported by a new demand for software but also by a stable and expanding market, which consisted of machines that utilized the System/360 architecture, the increasingly popular DEC PDP-11 series, and the small but growing number of machines that used the new Intel microprocessors.

A DISCIPLINE MATURES: 1985–

By 1985, the basic skills of software engineering were firmly established. Though those skills had obvious con-nections to the practice of the traditional engineering dis-ciplines, they seemed much more ethereal than the skills of electrical, mechanical, or civil engineering. Part of this perception was based on the fact that software engineering produced nothing physical. There were no great buildings of software, no software aircraft, and no software appli-ances. Granted, more and more devices contained a soft-ware component, including the American automobile, but these devices rarely advertised their internal programs.

A second reason that software engineering seemed to be less grounded than other disciplines was the fact that it had no real link to either the physical sciences or mathematics. Software engineers could ply their trade without knowing Newton’s laws of motion, Faraday’s laws of electricity, or even the basic concepts of calculus. “Although each of us may strive individually for technical excellence,” observed ATT engineer John Musa, “our field still seems to lack some of the ingredients of a profession.”[27]

During the next 25 years, software engineers would add a number of important topics to their field. Perhaps the largest of these was that of digital communications, which became important with the growth of networking technol-ogies. Following closely was that of security, which came to the attention of the public with the Internet worm of 1988 but, like so much of computer science, had a much older history.[28,29] In addition, software engineers explored the problems of reverse engineering (duplicating the function of code without seeing the original), distribut-ing computdistribut-ing across multiple machines, linkdistribut-ing large software systems with intermediate code, deploying code in varied circumstances (configuration management), and even correcting design shortfalls on a global scale (in the Y2K problem).

Yet, after nearly a half century of accomplishments, software engineers could still express doubts about their profession. Even though the globe contained 7 or 8 oper-ating processors for every person on the planet, software engineers would occasionally suggest that their discipline was not well grounded. “I still believe it makes excellent sense to engineer software,” wrote one senior member of

the field. “But that isn’t exactly what software engineering has come to mean.” He argued that the field was based on nothing more than the methods of industrial engineering that had been invented by Frederick Winslow Taylor and Walter Shewhart at the start of the twentieth century. The term software engineering “encompasses a specific set of disciplines including defined process, inspections and walk-throughs, requirements engineering, traceability matrices, metrics, precision quality control, rigorous plan-ning and tracking, and coding and documentation standards.”[30]

In spite of any insecurity over the nature or origins of their discipline, computer engineers steadily increased the scope and scale of their field during the last decade of the twentieth century and the first 10 years of the twenty-first century. In 1997, the field established a formal code of ethics, a step that usually indicates the expansion of a professional discipline beyond a single culture or social group.[31]By this point, software engineering had already spread to cultures outside of the common culture of the United States and Western Europe. Notably, software engi-neering was being practiced in East Asia, particularly Japan, Hong Kong, and South Korea, and was starting to expand in India.[32]

Following the code of ethics, the field of software engi-neering produced a comprehensive handbook, theSoftware Engineering Body of Knowledge (SWEBOK). While the SWEBOK showed that it was descended from the civil, electrical, and mechanical engineering handbooks of the twentieth century, it also revealed that the core of the dis-cipline was found in a set of procedures and processes for defining and managing the software life cycle.

Having codified a body of knowledge, a committee sponsored by the two major computing professional orga-nizations, the ACM and the Computer Society of the Institute of Electrical and Electronic Engineers (IEEE-CS), developed basic standards for an undergraduate soft-ware engineering curriculum. The committee argued that software engineering was a true engineering discipline, something more than a simple “familiarity with a software development process and a minimal computing background.”[33]

While making the case that software engineering was truly an engineering discipline, it acknowledged that the new field had drawn heavily from the traditional engineer-ing fields but in the process had substantially altered the basic concepts and tools that were found in those fields. It had borrowed heavily from the field of manufacturing engineering and quality control, the committee noted, even though the software developed includes “no manu-facturing phrase in the traditional sense”.[33]

Perhaps most importantly, the curriculum noted that software engineers had created a novel definition for the concept of maintenance. Unlike civil, mechanical, or elec-trical engineers, who vied maintenance as the task of repairing aging components as they degenerated and

Software

–

failed, software engineers saw maintenance as “continued development or evolution.” To handle maintenance pro-blems, software engineers would employ many of the same tools that they had used to create the original software systems.[33]

Following its work on to define a body of knowledge and undergraduate curriculum, the community of soft-ware engineers created a professional licensure exam. Such exams are usually considered the last step in the professionalization of any field. “The principle behind licensing,” explained the examining board, the National Council of Examiners for Engineering and Surveying, “is to assure the public that those who claim expertise pro-duce results that do not jeopardize public safety, health, and welfare” (J. Moore[34]). Working with the ACM and the IEEE-CS, the National Council began offering a Professional Engineering Exam in Software Engineering in 2009.

As it became recognized as an established engineering discipline, software engineering retained several features that distinguished it from the older forms of engineering. It did not create physical products; it drew its fundamental knowledge from mathematics and logic rather than from physics or chemistry; and it supported no traditional man-ufacturing process. In addition, it modified several funda-mental engineering concepts. Standard, interchangeable parts, which had been the hallmark of American engineer-ing since the early nineteenth century, became libraries of common routines. The tools of quality control and quality assurance became the means for managing the entire life cycle of software, beginning with the conception of the system and moving through the cycles of improvement that software engineers called “maintenance.”

Software engineers touch public welfare through a vari-ety of systems that can be as big as a national power grid, as ubiquitous as a cell phone network, or as small as a medical implant. Though they shape all of these devices, software engineers work with the tools that are nothing more than commands. Hence, their methods are those of manage-ment, of defining problems, of designing systems, and of creating code and assessing results. These are the tools of software engineers and this is the life cycle of software systems.

REFERENCES

1. Brooks, F. The Mythical Man Month; Addison-Wesley: Reading, MA, 1973; viii.

2. Turing, A.M. On computable numbers, with an application to the Entscheidungsproblem. Proc. London Math. Soc.

1936–1937, Series 2,42, 230–265.

3. Bromley, A.G. Charles Babbage’s Analytical Engine, 1838, Ann. History Comput. IEEE, July–September1982,4(3), 196–217.

4. Von Neumann, J. Draft Report on the EDVAC 1945. In Papers of John von Neumann on Computing and Computer Theory, Aspray, W., Burks, A., Eds.; MIT Press: Cambridge, MA, 1987; 17–82.

5. Luebbert, W.F.; Collom, P.W. Jr. Signal corps research and development on automatic programming of digital computers. Commun. ACM February 1959, 2 (2), 22–27.

6. Goldstine, H.; Von Neumann, J. Planning and coding pro-blems for an electronic computing instrument. InPapers of John von Neumann on Computing and Computer Theory, Aspray, W., Burks, A., Eds.; MIT Press: Cambridge, MA, 1987; 17–82.

7. Bright, H.S. Proposed standard flow chart symbols. Commun. ACM2(10), 17–18.

8. Buxton, J.N.; Randell, B. Eds. Software Engineering Techniques: Report of a Conference sponsored by the NATO Science Committee, Rome, Italy, Oct 27–31, 1969. 9. Campbell-Kelly, M.From Airline Reservations to Sonic the

Hedgehog; MIT Press: Cambridge, MA, 2003; 39, 119. 10. Everett, R.R.; Zraket, C.A.; Benington, H.D. SAGE—a data

processing system for air defense. In Proceedings of the Eastern Computer Conference, ACM Digital Library, 1958; 148–155.

11. Hammer, A. Computer industry short of personnel. New York Times, September 1, 1968; F12.

12. Zadeh, L.A. Electrical engineering at the crossroads. IEEE Trans. Education1965,E-8(2–3), 30–33.

13. Randell, B. Software engineering in 1968. In Proceedings of the 4th International Conference on Software Engineering, New Brunswick, NJ; IEEE Press: Las Almitos, CA, 1979; 9.

14. Wirth, N. A brief history of software engineering. IEEE Ann. History Comput.30(3), 33–39.

15. Dijkstra, E.W. The structure of the “the”-multiprogram-ming system. In Proceedings of the first ACM symposium on Operating System Principles, ACM, 1967.

16. David, A.; Hsia, P. Giving voice to requirements engineer-ing. Computer1994,27(3), 12–14.

17. Yeh, R.; Zave, P. Specifying storage requirements. Proc. IEEE1980,68(9), 1077–1085.

18. Parnas, D.L. On the criteria to be used in decomposing systems in modules. CACM1972,15(12), 1053–1058. 19. Whitaker, W. Ada—the project: The DoD high order

lan-guage working group. ACM SIGPLAN Notices March

1993,28(3), 299–331.

20. Fuggetta, A. A classification of CASE technology. Computer1993,26(12), 25–28.

21. Brown, J.R.; Hoffman, R.H. Evaluating the effectiveness of software verification; practical experience with an auto-mated tool. AFIPS Conf. Proc.1972,41,181–190. 22. Dijkstra, E. Notes on structured programming. InStructured

Programming, Dijkstra, E., Hoare, C., Eds.; Academic Press: New York, 1972.

23. Zhy, H.; Hall, P.; May, J. Software unit test coverage and adequacy. Comput. Surv.1997,29(4), 366–427.

24. Hartwick, R.D. Test planning. AFIPS National Computer Conference 1977; 285–294.

25. Boehm, B. Software engineering—as it is. In ICSE ‘79: Proceedings of the 4th international Conference on Software Engineering, M¨unchen, Germany, 1979; 11–21.

Software

–

26. Reutter, J. Maintenance is a management problem and a programmer’s opportunity. In AFIPS ‘81: Proceedings of the May 4–7, 1981, Chicago, IL, May 1981.

27. Musa, J. Software engineering: the future of a profession. IEEE Softw.1985,2(1), 55–62.

28. Linde, R. Operating system penetration. AFIPS Computer Conference, Anaheim, CA, 1975; 361–369

29. Parker, D.P. The dark side of computing: SRI international and the study of computer crime. Ann. History Comput. IEEE January–March2007,29(1), 3–15.

30. Marco, T. Software engineering: An idea whose time has come and gone? Software, July/August2009,26(4), 94–95. 31. Gotterbarn, D. Software engineering code of ethics. Version

3.0. Comput. October1997,30, 88–95.

32. Isoda, S.; Saeki, M. Software engineering in Asia. Software,

1994;11(6), 63–68.

33. Software Engineering 2004, Curriculum Guidelines for Undergraduate Programs in Software Engineering, 2004; 6.

34. Ward, B. Society supports software engineering PE exam-ination. Comput. November2009,42(11), 87–88.

BIBLIOGRAPHY

1. Mahoney, M. What makes the history of software hard. Ann. Hist. Comput. July–September2008,30(3), 8–18. 2. Mahoney, M. Finding a history for software engineering.

Ann. Hist. Comput. January–March2004,26(1), 8–19. 3. Wirth, N. A brief history of software engineering. Ann. Hist.

Comput. July–September2008,30(3), 32–39.

Software

–