Software engineering
Software engineering is the technologies and practices that create computer software while improving productivity and quality. In the year 2000, these technologies and practices encompass languages, databases, tools, platformss, libraries, standards, patterns, and processes.Software engineering applications include email, embedded software, graphical user interfaces, office suites, operating systems, optimizing compilers, relational databases, robotics controllers, video games, and the world wide web. Other important applications include accounting, airline reservations, avionics, banking, and telephony. These 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.
Software engineering is the community of pracitioners, who create programss. In the year 2000, there were about 640,000 software engineers in the U.S and another (1,200,000?) in Europe, Asia, and elsewhere. Steve McConnell says 40% have computer science degrees. Many others have science, engineering, business or other non-technical degrees. They use diverse technologies and practices and work on diverse applications.
In the USA, software drove 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, particularly in countries whose 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.
Agile processes are an important emerging practice. Agile processes are methods to manage software development so projects evolve with changing expectations.
The older document-driven processes (like CMM and ISO-9000) may be fading
in importance. Some persons believe that companies have exported many of the
jobs that can be controlled by these processes.
Aspect programming is also an important emerging programming technology. 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.
The future of software engineering was an important conference at the ICSE 2000,
[1].
The FOSE project summarized the state of the art in 2000 and listed many problems to be solved over the next decade.
The Feyerabend Project is attempting to discover the future, [1].
Software engineers work on all sizes of applications: small and large.
Programming emphasizes coding to produce working software applications,
independent of budget and schedule.
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 engineering tries to come up with methods to write programs in a consistent way.
Whether software development is more like science or engineering has been fiercely debated for many decades. Software development shares attributes of both and many software projects have elements of both, but distinctions exist.
Many believe that (metaphorically) software engineering is to computer science and information science as traditional engineering is to physics and chemistry.
While 40% of software engineers earn computer science degrees,
they do not practice computer science every day, which is different
than practicing software engineering every day.
Impact of software engineering
Current directions for software engineering
Software engineering versus programming
Software engineering versus computer science
| Issue | Software Engineering | Computer Science |
|---|---|---|
| Ideal | Constructing software system for real-world use | Correct eternal truths about computability and algorithms with good runtime behavior |
| Goals | Working programs (like office suites and compilers) | Algorithms (like Shell sort) and abstract problems (like Travelling Salesman) |
| Budgets and Schedules | Projects (like the next upgrade) have fixed budgets and schedules. | Projects (like solving NP) are independent of budget and schedule. |
| Emphasis | Software engineering emphasizes applying skills and working programs that deliver value to users. | The theory of software 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 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, David Parnas, and Frederick P. Brooks | Edsger Dijkstra, Donald Knuth, Robert Tarjan, Peter Slater, and Alan Turing |
| Notable Practitioners | John Backus, Dan Bricklin, Tim Berners-Lee, Linus Torvalds, Richard Stallman | Not applicable |
| Number of Practitioners in U.S. | 640,000 | 25,000 |
| Number of Practitioners in World | unknown | unknown |
| 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 cause a project to fail. | Construction and manufactoring 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. |
| 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. |
| Innovation | Software engineers apply new and untested elements in many software projects. | Though some projects have innovations, traditional engineers apply known and tested principles, and limit the untested innovations that goes into each product. |
| 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. |
| Number of Practioners in U.S. in 2000 | 640,000 | 1,100,000 total engineers 65,000 computer engineers |
In the U.S., there are 10 times as many software engineers as computer engineers, so computer engineers are irrelevant to the software engineering community. In the U.S., the software engineering community is about 60% as large as the traditional engineering community.
Software engineering is much younger than some engineering disciplines such as civil engineering.
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, large traditional engineering systems also fail, such as Three Mile Island, Chernobyl, Bhopal, Space Shuttles Challenger and Columbia, are also too common.
Software engineering arose out of the so called software crisis of the 1960s, 1970s, and 1980s, when many software projects had bad endings. Many software projects ran over budget and schedule. Some projects caused property damage. A few projects caused loss of life. As software becomes more pervasive, we all recognize the need for better software. The software crisis was originally defined in terms of productivity, but evolved to emphasize quality.
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 very 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.
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 spur 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 current list of problems is kept at [1].
For decades, solving the software crisis was paramount. 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.
Practices: Some pundits argued that the software crisis was due to the lack of discipline of programmers. Many practitioners resist process strongly. 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. This led to work on a code of ethics, and professionalism. The issue is so pervasive that it cannot be deliberate. It must be a natural response to experience.
In 1987, Brooks published the famous paper No Silver Bullet, arguing that no individual technology or practice can make a 10 fold improvement in productivity in 10 years. All of the technologies and practices have made incremental improvements. See his article
Women's Issues: 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 prior to 1968. Today, 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.
NATO: The NATO Science Committee sponsored two conferences on software engineering in 1968 (Garmisch, Germany) and 1969, which gave the field its initial boost. Many consider these conferences to be the start of the field. However, there has been a continuity of practice from the 1940s to the 2000s.
Cost: The 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.
Emerging from Programming: Prior to the mid-1990s, most software practitioners called themselves programmers or developers, regardless of their actual jobs. The term programmer had often been used to refer to those who lacked the skills, education, or ethics to write quality software. Software practitioners began to describe themselves as software engineers to escape the stigma attached to "programmer." This caused a lot of confusion, because some saw no difference while others were trying to create a difference.
Critics charge that the assumptions of software engineering are inherently flawed.
Managing Expectations: Managing the customer's expectations to something that can be built and delivered is the key to successful "software engineering" methodologies. Thus, the field resembles marketing, sociology, or voodoo, more than traditional engineering with its responsibilities to society at large and the perils of legal liability with failure to protect the public interest. — Every profession manages expectations.
Poor Requirements: The requirements for most projects are incomplete or inconsistent. Some customers have little previous experience in writing requirements for a software project.
Other customers really do not know what they want, and say "I'll know it when I see it" (IKIWISI). Users almost always expect far more than they write in specifications. Even experienced customers who know exactly what they want may be unable to articulate their requirements. And, complete requirements may describe programs that have no computable or practical solution.
Embedded systems are unique in that they are designed by other engineers, who can sometimes define interfaces completely.
— One response is to avoid all unclear projects. Another response is agile development and rapid prototyping to clarify project goals as soon as possible.
Rising Complexity: Critics argue that the probability of failure increases with project size, scope and complexity. Technologies and practices have improved through the 1970s, 1980s, and 1990s, but the complexity in requirements and user expectations increase fast enough to overwhelm the improvement in practices. So, the gap between what is expected and what is delivered has not improved. — This is not the fault of practitioners. This is actually a measure of the success of practitioners.
Ongoing Change: Practitioners are eager to develop new technologies and practices and try new tools in every project. Some view this ongoing change as proof that older technologies and practices were failures. — Others view this ongoing change as proof that the field successfully learns and grows.
Ongoing Failure: Critics charge that incomplete or poorly designed systems are still too common. The early lessons of the field were not sufficient to prevent subsequent disasters. — No field that strives to do bigger and better projects has ever avoided all failures.
Nothing New: Critics argue that software engineering has not created anything on its own, it merely uses what computer scientists already know. This is more-or-less true. — But, practitioners developed many tools and practices (compilers, make, cvs, XP), on their own, out of simple need.
Anyone Can Do It: Many bright people from other fields (engineers, scientists, business people) write spreadsheet templates or calculator programs, and eventually switch to writing large applications, and believe that they do software engineering. — Software engineering is a skill that is refined through long practice. Software engineers are the ones who already have the education and experience, and they keep up with evolving technologies and practices. This is true of any skill.
We Do Not Know What It Is: This is often said by people who want to redefine software engineering. — Software engineering is the technologies and practices used to create office suites, databases, and engine controllers.
Software engineering methods span many disciplines, including
project management, analysis, specification, design, coding, testing, and quality assurance. All of the methods guiding this field are collations of all of these fields.
Software design methods can be informally classified into thick and thin.
Thick methods include a large amount of formal process paperwork and documentation.
The well-known thick methods include Cleanroom, ISO 9000, CMM and Rational Unified Process (RUP).
Thin methods eschew formal process paperwork and documentation.
Well-known thin methodologies include Extreme Programming (XP) and Agile Processes.
Recently, some (like Karl Weigers) have argued for no more methodologies. Methodologies tend to list the contemporary technologies and practices and insist that everyone use them. This advice is obvious for those who have the opportunity to use contemporary technologies and practices, and useless for those who maintain legacy systems and must use legacy tools cannot do so, due to circumstance. So, methodologies are not specfically useful. And methodologies must be updated as technologies and practices evolve.
There is a growing body of software development organisations that are implementing process methodoligies. Many of them are in the defence industry, which in the U.S. requires a 'Rating' baised on 'Process models' to obtain contracts.
For example the Capability Maturity Model (CMM) grades organizations on how well they create software. ISO 9000 describes standards for formally organizing processes with documentation.
ISO 15504 or SPICE, The software process life cycle is also gaining wide usage. This standard is aimed at setting out a clear model for process comparison. SPICE is used much like CMM and CMMI. It models processes to manage, control, guide and monitor software development. This model is then used to measure what a development organization or project team actually does during software development. This information is analyzed to identify weaknesses and drive improvement. It also identifies strengths that can be continued or integrated into common practice for that organization or team.
Six Sigma is a methodology that uses data and statistical analysis to measure and improve a company's operational performance. It works by identifying and eliminating "defects" in manufacturing and service-related processes. The maximum permissible defects are 3.4 per million opportunities.
Different methodologies advocate conflicting solutions. Proponents of different methodologies often get into heated debates over their merits.
Everyone agrees that we want better software. We disagree on priorities and approach, on what an individual should do first in a specific circumstance.
With an industry of 640,000 software engineers, there should be room for many approaches. Subfields like consumer applications are very sensitive to time and cost. Subfields like military and medical applications are very sensitive to quality. All subfields mix these needs to varying degrees.
There should be room for people to try different approaches.
In the mid-1990s, The National Society of Professional Engineers sued in all states to prohibit anyone from using the term software engineer as a noun or field of employment. They won in most states. Utah does not license professional engineers, so the point was moot there.
In response, the IEEE and ACM began a joint effort called JCESEP in 1993, which evolved into SWECC in 1998 to explore making software engineering into a profession. The professional movement uses the traditional engineering model. The ACM pulled out of SWECC in [1998?] objecting to its support for the Texas professionalization efforts. The IEEE continued to support making software engineering a branch of traditional engineering.
Donald Bagart of Texas became the first professional software engineer in the U.S. on September 4, 1998 or October 9, 1998. As of May 2002, Texas had issued 44 professional enginering licenses for software engineers.
The professional movement has been criticized for many reasons.
Software engineering ethics is a large field. In some ways it began as an attempt to define bugs as unethical. However that is unrealistic.
Lawrence Lessig argued that coding is more like law, in that it expresses a certain social ethic by deciding what to ignore/consider in making detailed decisions.
The software crisis
Silver bullets and no silver bullets
Historical notes
Criticisms of software engineering
Methodologies
Processes and meta-processes
Differences of opinion
Professional software engineering
For more information, see:
The fields of data engineering, knowledge engineering, user interface engineering, and so on have similar concerns over engineering issues.Ethics
See also
External links
