| |
|
Software engineering technologies and practices help developers to create and maintain applications, by improving productivity and quality. These diverse technologies and practices include languages, databases, tools, platformss, libraries, standards, patterns, reuse, and processes.
Software engineering applications embody social and economic value, in that they make people more productive, improve their quality of life, and enable them to do things that would otherwise be impossible. These diverse applications include banking, compilers, databases, email, embedded software, graphics, office suites, operating systems, robotics, video games, and the world wide web.
For more details, see list of software engineering topics.
Software engineering is alive and well.
In the USA, software drove about 1/4 of all increase in GDP during the 1990s (about $90 billion per year), and 1/6 of all productivity growth (efficiency within GDP) during the late 1990s (about $33 billion per year).
Software engineering has changed the world's culture, wherever people use computers. Email, the world-wide web, and instant messaging enable people to interact in new ways. Software lowers the cost of many important social goods and services, such as health-care and fire departments.
Examples of successful projects, where software engineering methods have been applied, include Linux, the space shuttle software, and automatic teller machines.
When it is cheaper to run a business with software applications than without, businesses often invest in computer hardware, software, and personnel.
Practitioners specialize in many roles in industry (analysts, developers, testers, managers) and academe (educators, researchers).
Most software engineers work for others as employees or contractors. Software engineers may work with a profit-seeking corporation (a business), a government (civilian or military), or a non-profit agency (such as a school( or .org (such as Wikipedia). Some software engineers work for themselves as free agents.
Software engineers are part of a much larger software, hardware, application, and operations community. In 2000 in the U.S. there are about 680,000 software engineers and about 10,000,000 IT workers.
About half of software engineers today have computer science degrees. Many others have science, engineering, or other technical degrees. Some have business, or other non-technical degrees. And, some have no degrees. The fraction of practitioners who have computer science or software engineering degrees has been slowly rising. For comparison,
about 3/4 of all traditional engineers have engineering degrees.
Note that Barry Boehm earned degrees in mathematics and Edsger Dijkstra earned degrees in physics.
Graduate software engineering degrees have been available from dozens of universities for a decade or so.
New undergraduate software engineering degrees are being established at many universities, today.
But only a small fraction of schools that offer computer science degrees also offer software engineering degrees. So, most practitioners still earn computer science degrees, even though someday more will earn software engineering degrees.
A new international curriculum for software engineering is currently being defined by the CCSE.
Agile processes and Aspect programming are important emerging practices and technologies.
Agile processes manage software development projects that evolve with changing expectations and competitive markets. The older document-driven processes (like CMM and ISO 9000) may be fading in importance. Some people believe that companies have exported many of the jobs that can be controlled by older processes. Related concepts are lean software development and extreme programming.
Aspects help programmers deal with ilities by providing tools to add or remove boilerplate code from many areas in a software project. Aspects describe how all objects or functions should behave in a particular circumstance.
For example, aspects can add debugging, logging, or locking control
into all objects of a particular type. Related concepts are generative programming and templates.
The future of software engineering was an important conference at the ICSE 2000,
[1].
The FOSE project described the state of the art of SE in 2000 and listed many problems to be solved over the next decade.
The Feyerabend project is attempting to discover the future, [1].
Software engineering has evolved steadily from its founding days in the 1940s until today in the 2000s.
There has been a continuity of practice.
The ongoing goal has been to improve technologies and practices, the productivity of practitioners, and the quality of applications to users.
The term software engineering first was used in the late 1950s and early 1960s. Programmers knew about civil, electrical, and computer engineering and debated what engineering might mean for software.
The NATO Science Committee sponsored two conferences on software engineering in 1968 (Garmisch, Germany) and 1969, which gave the field its initial boost. Many believe these conferences mark the start of the profession.
Software engineering was spurred by the so-called software crisis of the 1960s, 1970s, and 1980s. The name software crisis identified the many problems of software development projects. Many software projects ran over budget and schedule. Some projects caused property damage. A few projects caused loss of life. Some companies used the term to refer to their inability to hire qualified personnel. The software crisis was originally defined in terms of productivity, but evolved to emphasize quality.
Cost and Budget Overruns: The OS 360 operating system was a classic example. It is still used on the IBM 360 Series and its descendants.
This decade-long project eventually produced a working system amongst the most complex software systems ever designed. OS 360 was one of the first large (1000 programmer) software projects. Fred Brooks admits in Mythical Man Month that he made a multi-million dollar mistake when he managed the project.
According to a study by the Standish Group, in 2000, only 28 percent of software projects could be classed as complete successes (meaning they were executed on time and on budget), while 23 percent failed outright. Many projects were abandoned. About, half were cancelled by users who changed their minds, whether or not the developers succeeded.
Property Damage: Software defects can cause property damage. Poor software security allows hackers to steal identities, costing time, money and reputations. The explosion of a European Ariane rocket and other disasters spurred further developments in the field.
Life and Death: Defects in software have killed. Several embedded systems used in radiotherapy machines failed so
catastrophically that they administered lethal doses of radiation to patients.
A large list of contemporary software problems and disasters is kept at Peter G. Neumann's Computer Risks column.
For decades, solving the software crisis was paramount to researchers. Seemingly, every new technology and practice from the 1970s to the 1990s was trumpeted as a silver bullet to solve the software crisis.
Technologies: Every new technology and practice for decades was touted as the solution to the software crisis: structured programming, object-oriented programming, process, CMM, UML, Ada, methodologies, and so on. Especially emphasised were tools, such as CASE tools, Ada, and so on.
Practices: Discipline: Some pundits argued that the software crisis was due to the lack of discipline of programmers. Formal methods: Some believed that if formal engineering methodologies could be applied to software development, the production of software would become as predictable an industry as other branches of engineering. Process: Many advocated process. Professionalism: This led to work on a code of ethics, and professionalism.
In 1987, Brooks published the famous paper "No Silver Bullet", arguing that no individual technology or practice would make a 10-fold improvement in productivity in 10 years.
Debate about silver bullets raged over the following decade. Some advocates for particular technologies (components, processes, ...) continued to argue that their favorite technology or practice would be the silver bullet. Sceptics disagreed. But eventually, almost everyone accepted that no silver bullets would ever be found. Some have interpreted this to mean that SE has failed, even though there are no silver bullets for any other profession, either. Yet, the term silver bullet pops up now and again in marketing, even today.
All known useful technologies and practices have made incremental improvements in productivity and quality.
See also software development process and methodology.
Many practitioners resist process strongly.
In the mid-1990s to mid-2000s, software engineering emerged
as a bona fide profession, to stand beside computer science
and traditional engineering.
Prior to the mid-1990s, most software practitioners called themselves programmers or developers, regardless of their actual jobs.
The term programmer has often been used as a pejorative term to refer to those who lacked the tools, skills, education, or ethics to write quality software. Practitioners began to describe themselves as software engineers to escape the stigma attached to programmer. In many companies, the titles programmer and software developer were changed to software engineer, for many categories of programmers.
This caused confusion, because some denied any difference while others tried to create a difference. Traditional engineers questioned whether software engineers could legally use the term.
See also software engineering professionalism.
In the 1940s, 1950s, and 1960s, software was a women's ghetto. Men preferred the higher prestige of hardware engineering roles. So, women filled the programming roles. Women like Grace Hopper were common.
Many unsung women wrote code in the first decades of software engineering. Today, relatively few women work in software engineering. Women have largely moved into analysis and testing roles. Saying that this is sexual discrimination is too simple, because it related directly to individual identity. In this sense, software engineering is the masculinization of programming.
The role women play continues to evolve. Today, women in software engineering frequently do analysis, testing, education, documentation, and management, rather than hard-core development.
Ada Lovelace was deeply in debt, and was attracted to Babbage's project so that she could gamble on horses more effectively.
The relative cost of software versus hardware has changed substantially. When mainframes were expensive, software projects could be expensive. Because powerful PCs are cheap, software costs must become cheaper, in comparison.
The relationship between software engineering and the fields of programming, computer science, and traditional engineering has been debated for many decades. Many of the similarities and differences are discussed here.
Whether software development is more like art, science or engineering has been fiercely debated for many decades. Software development shares attributes of all of these fields, and many software projects have elements of all, but important distinctions exist.
Programmers emphasize the task of writing code to produce working software applications,
independent of budget and schedule.
Software engineers work on all sizes of applications: small and large.
Software engineering tries to encompass software projects more completely, including budget and schedule.
Software engineering recognizes that software development fits
in a large business context with relationships to marketing,
sales, production, installation, training, support, and operations.
Software engineering emphasizes methods to construct large applications that individual programmers cannot write alone.
Software engineers strive to write applications in a consistent way.
Software engineering today
Importance of software engineering
Today's Practice
Today's Education
Current directions for software engineering
Evolution
1945 to 1965: The origins
1965 to 1985: The software crisis
1985 to present: No silver bullet
Major developments
Process and methodology
Emergence as a profession
Role of women
Cost of hardware
Comparing Related Fields
Comparing programming
| Issue | Software Engineering | Programming |
|---|---|---|
| Scope | Relates development to final application. | Emphasizes programming. |
| Team size | Individuals to large teams. | Emphasizes individual efforts. |
| Number of Practitioners in U.S. | 680,000 | 530,000 |
| Issue | Software Engineering | Computer Science |
|---|---|---|
| Ideal | Constructing software applications for real-world use | Finding eternal truths about computability and algorithms with good runtime behavior |
| Results | Working applications (like office suites and video games) that deliver value to users. | Algorithms (like Shell sort) and abstract problems (like travelling salesman problem) |
| Budgets and Schedules | Projects (like the next upgrade of an office suite) have fixed budgets and schedules. | Projects (like solving NP) are independent of budget and schedule. |
| Skills | Software engineering emphasizes applying skills and working programs. | Computer science emphasizes eternal truths, like the running time analysis, space analysis, and correctness of algorithms. |
| Change | Programs will evolve as user needs and expectations evolve, and as SE technologies and practices evolve. | When computer science problems are solved, the solution will never change. |
| Additional Skills | Domain knowledge | Mathematics |
| Notable Educators and Researchers | Barry Boehm, Frederick P. Brooks, and David Parnas | Edsger Dijkstra, Donald Knuth, Robert Tarjan, and Alan Turing |
| Notable Practitioners | John Backus, Dan Bricklin, Tim Berners-Lee, Linus Torvalds, Richard Stallman | Not applicable |
| Number of Practitioners in U.S. | 680,000 | 25,000 |
| Number of Practitioners in World | unknown | unknown |
Some people believe that SEs apply concepts from traditional engineering to software development. They believe engineering provides a structured, logical approach, and therefore, a stable final product. Other practitioners are inspired by traditional engineering, but believe that software problems need particular solutions. They believe that traditional engineering concepts may not apply, because software is fundamentally different than bridges and roads. For example, traditional engineers do not use compilers or linkers to build roads.
Software engineers aspire to build low-cost, reliable, safe software, which is much like what traditional engineers do.
Software engineers borrow many metaphors and techniques from traditional engineering disciplines: requirements analysis, quality control, and project management techniques.
These tools make use of the tenets of computer science, just like the other engineering fields that make use of pure sciences like math and physics.
All engineering fields use software extensively. Traditional engineers use software tools to design, analyze, and simulate their own projects, such as bridges and buildings. These new kinds of design and analysis resemble programs in many respects, because the work exists as electronic documents and goes through analysis, design, implementation, and testing phases, just like software. When it is cheaper to build a software simulation than to build an engineering model, traditional engineers usually build the simulation. Many traditional engineers write software as part of the control systems for their own HVAC, airplane, and automotive products.
Comparing traditional engineering
| Issue | Software Engineering | Traditional Engineering |
|---|---|---|
| Foundations | Software engineering is based on computer science, information science, and discrete math. | Traditional engineering is based on physics, chemistry, and calculus. |
| Cost | Compilers and computers are now cheap, so software engineering and consulting often cost more than 50% of a project. Even minor software engineering cost-overruns can affect the total project cost. | Construction and manufacturing costs are high, so traditional engineering may only cost 15% of a project. Even major engineering cost overruns may not affect a project's viability. |
| Replication | Replication is trivial, and most development effort goes into building new (unproven) or changing old designs and features. | Most development effort goes into replicating proven designs. |
| Innovation | Software engineers often apply new and untested elements in software projects. | Though some projects have innovations, traditional engineers apply known and tested principles, and limit the untested innovations that goes into each product. |
| Management Status | Few software engineers manage anyone, so they are not viewed as managers, except by themselves. | Many traditional engineers manage construction, manufacturing, or maintenance crews, so they are all treated as managers. |
| Number of Practitioners in U.S. in 2000 | 680,000 software engineers | 1,100,000 total engineers 65,000 computer engineers |
| Age | Software engineering is about 50 years old. | Civil engineering is thousands of years old. |
In the U.S., there are 10 times as many software engineers as computer engineers, and the software engineering community is about 60% as large as the traditional engineering community.
As software becomes more pervasive, we all recognize the need for better software. Everyone agrees that we want better software. But, we disagree on priorities and approach, on what an individual should do in a specific circumstance. Proponents and methodologies advocate conflicting solutions. Proponents of different methodologies often get into heated debates over their merits.
With an industry of 640,000 software engineers and 530,000 programmers in the USA, and many more around the world, there should be room for many approaches. Subfields like consumer applications are sensitive to time and cost. Subfields like military and medical applications are sensitive to quality. All subfields mix these needs to varying degrees. A consensus has yet to emerge.
The term engineering causes a lot of confusion. Some believe that it means that practitioners must be traditional engineers. Others believe that engineering is a metaphor that practitioners apply as appropriate.
Traditional engineers (especially civil engineers) claim that they have
a special rights over the term engineering, and for other any field to use it requires their approval.
The fields of data engineering, knowledge engineering, user interface engineering, and so on have similar concerns about the term engineering.
Many people prefer the term software developer, though some still prefer the term programmer. Many argue that they all essentially do the same thing with software. Others argue that the terms mean completely different things.
Some claim that software engineering is already as predicatable and reliable as many fields of engineering, such as space or biological engineering.
Although large, reliable software systems can be and have been constructed, software projects that fail during construction or in service are still too common. However, failures in large traditional engineering systems, such as those preceding the disasters in Three Mile Island, Chernobyl, Bhopal Disaster, Space Shuttles Challenger and Columbia are also too common. Others argue that unlike in traditional engineering where practicioners analyze failures, find precise causes, and set up guidelines to avoid them in the future software engineers routinely fail to pinpoint causes of failure or delay precisely enough to avoid repeats in the future.
Everyone seems to emphasize a different combination of the following issues.
Management practices: Some argued that software engineering was primarily about the management practices necessary to make budgets and schedules. The Software Engineering Institute took this approach to create the CMM.
Formal methods: Some want to apply rigorous mathematical analysis to computer programming, especially proofs of correctness. They believe that conventional engineering is carried out with a great degree of mathematical rigor, while computer programming is an iterative trial-and-error process. It's likely that neither of these perceptions is accurate, but the term software engineering was adopted to indicate an intent to make programming more rigorous.
Methodologies: Some have argued that software engineering must follow a step-by-step methodology, much like an assembly line. This inspired many methodologies, such as RUP.
Tools: Many argue that software engineering means tools, especially CASE tools. They usually emphasize high-level issues, like architecture.
Traditional engineering: Many have defined software engineering as a subset of traditional engineering. This means that software engineers should study physics, chemistry, and calculus.
Ethics: Some argued that software engineering mostly need codes of ethics and social responsibility.
Licenses: Some have defined software engineering in terms of professional licenses, like traditional engineers have. The biggest advocates of this position are in Texas and Canada, where the state governments sponsor licenses.
Critics charge that many of the foundations of software engineering are inherently flawed. The following paragraphs detail many of the criticisms and some responses to them. However, many of these criticisms may seem to apply to every human activity (for example fine arts and quantum cryptography).
Differences of Opinion
Fighting over words
Fighting over issues
Criticisms of software engineering
See also