The latter example indicates that errors in a software system may have serious financial consequences for the organization using it.One example of such afinancial loss is the large US airline company that lost$50M because of an error in their seat reservation system.The system erroneously reported that cheap seats were sold out,while in fact there were plenty available.The problem was detected only after quarterly results lagged considerably behind those of both their own previous periods and those of their competitors.

Errors in automated systems may even have fatal effects.One computer science weekly magazine contained the following message in April1983:

The court in D¨usseldorf has discharged a woman(54),who was on trial

for murdering her daughter.An erroneous message from a computerized

system made the insurance company inform her that she was seriously

ill.She was said to suffer from an incurable form of syphilis.Moreover,

she was said to have infected both her children.In panic,she strangled

her15year old daughter and tried to kill her13year old son and herself.

The boy escaped,and with some help he enlisted prevented the woman

from dying of an overdose.The judge blamed the computer error and

considered the woman not responsible for her actions.

This all marks the enormous importance of thefield of software engineering. Better methods and techniques for software development may result in largefinancial savings,in more effective methods of software development,in systems that betterfit user needs,in more reliable software systems,and thus in a more reliable environment in which those systems function.Quality and productivity are two central themes in thefield of software engineering.

On the positive side,it is imperative to point to the enormous progress that has been made since the1960s.Software is ubiquitous and scores of trustworthy systems have been built.These range from small spreadsheet applications to typesetting systems,banking systems,Web browsers and the Space Shuttle software.The techniques and methods discussed in this book have contributed their mite to the success of these and many other software development projects.

1.1What is Software Engineering?

In various texts on this topic,one encounters a definition of the term software engineering.An early definition was given at thefirst NATO conference(Naur and Randell,1968):

Software engineering is the establishment and use of sound engineering

principles in order to obtain economically software that is reliable and

works efficiently on real machines.

The definition given in the IEEE Standard Glossary of Software Engineering Terminol-ogy(IEEE610,1990)is as follows:6INTRODUCTION Software engineering is the application of a systematic,disciplined,

quantifiable approach to the development,operation,and maintenance

of software;that is,the application of engineering to software.

These and other definitions of the term software engineering use rather different words.However,the essential characteristics of thefield are always,explicitly or implicitly,present:

Software engineering concerns the development of large programs.

(DeRemer and Kron,1976)make a distinction between programming-in-the-large and programming-in-the-small.The borderline between large and small obviously is not sharp:a program of100lines is small,a program of50000lines of code certainly is not.Programming-in-the-small generally refers to programs written by one person in a relatively short period of time.Programming-in-the-large,then,refers to multi-person jobs that span,say,more than half a year.

For example:

–The NASA Space Shuttle software contains40M lines of object code

(this is30times as much as the software for the Saturn V project from the

1960s)(Boehm,1981);

–The IBM OS360operating system took5000man years of development

effort(Brooks,1995).

Traditional programming techniques and tools are primarily aimed at support-ing programming-in-the-small.This not only holds for programming languages, but also for the tools(likeflowcharts)and methods(like structured program-ming).These cannot be directly transferred to the development of large programs.

In fact,the term program--in the sense of a self-contained piece of software that can be invoked by a user or some other system component--is not adequate here.Present-day software development projects result in systems containing a large number of(interrelated)programs--or components.

The central theme is mastering complexity.

In general,the problems are such that they cannot be surveyed in their entirety.

One is forced to split the problem into parts such that each individual part can be grasped,while the communication between the parts remains simple.The total complexity does not decrease in this way,but it does become manageable.

In a stereo system there are components such as an amplifier,a receiver,and a tuner,and communication via a thin wire.In software,we strive for a similar separation of concerns.In a program for library automation,components such as user interaction,search processes and data storage could for instance be distinguished,with clearly given facilities for data exchange between those components.Note that the complexity of many a piece of software is not1.1.WHAT IS SOFTWARE ENGINEERING?7

so much caused by the intrinsic complexity of the problem(as in the case of compiler optimization algorithms or numerical algorithms to solve partial differential equations),but rather by the vast number of details that must be dealt with.

Software evolves.

Most software models a part of reality,such as processing requests in a library or tracking money transfers in a bank.This reality evolves.If software is not to become obsolete fairly quickly,it has to evolve with the reality that is being modeled.This means that costs are incurred after delivery of the software system and that we have to bear this evolution in mind during development.

The efficiency with which software is developed is of crucial importance.

Total cost and development time of software projects is high.This also holds for the maintenance of software.The quest for new applications surpasses the workforce resource.The gap between supply and demand is growing.Time-to-market demands ask for quick delivery.Important themes within thefield of software engineering concern better and more efficient methods and tools for the development and maintenance of software,especially methods and tools enabling the use and reuse of components.

Regular cooperation between people is an integral part of programming-in-the-large.

Since the problems are large,many people have to work concurrently at solving those problems.Increasingly often,teams at different geographic locations work together in software development.There must be clear arrangements for the distribution of work,methods of communication,responsibilities,and so on.Arrangements alone are not sufficient,though;one also has to stick to those arrangements.In order to enforce them,standards or procedures may be employed.Those procedures and standards can often be supported by tools.Discipline is one of the keys to the successful completion of a software development project.

The software has to support its users effectively.

Software is developed in order to support users at work.The functionality offered shouldfit users’tasks.Users that are not satisfied with the system will try to circumvent it or,at best,voice new requirements immediately.It is not sufficient to build the system in the right way,we also have to build the right system.Effective user support means that we must carefully study users at work, in order to determine the proper functional requirements,and we must address usability and other quality aspects as well,such as reliability,responsiveness, and user-friendliness.It also means that software development entails more than delivering software.User manuals and training material may have to be written,and attention must be given to developing the environment in which the new system is going to be installed.For example,a new automated library system will affect working procedures within the library.8INTRODUCTION Software engineering is afield in which members of one culture create artifacts on behalf of members of another culture.

This aspect is closely linked to the previous two items.Software engineers are expert in one or more areas such as programming in Java,software architecture, testing,or the Unified Modeling Language.They are generally not experts in library management,avionics,or banking.Yet they have to develop systems for such domains.The thin spread of application domain knowledge is a common source of problems in software development projects.

Not only do software engineers lack factual knowledge of the domain for which they develop software,they lack knowledge of its culture as well.For example,a software developer may discover the‘official’set of work practices of a certain user community from interviews,written policies,and the like;

these work practices are then built into the software.A crucial question with respect to system acceptance and success,however,is whether that community actually follows those work practices.For an outside observer,this question is much more difficult to answer.

Software engineering is a balancing act.

In most realistic cases,it is illusive to assume that the collection of requirements voiced at the start of the project is the only factor that counts.In fact,the term requirement is a misnomer.It suggests something immutable,while in fact most requirements are negotiable.There are numerous business,technical and political constraints that may influence a software development project.

For example,one may decide to use database technology X rather than Y, simply because of available expertise with that technology.In extreme cases, characteristics of available components may determine functionality offered, rather than the other way around.

The above list shows that software engineering has many facets.Software engineering certainly is not the same as programming,although programming is an important ingredient of software engineering.Mathematical aspects play a role since we are concerned with the correctness of software.Sound engineering practices are needed to get useful products.Psychological and sociological aspects play a role in the communication between human and machine,organization and machine,and between humans.Finally,the development process needs to be controlled,which is a management issue.

The term‘software engineering’hints at possible resemblances between the construction of programs and the construction of houses or bridges.These kinds of resemblances do exist.In both cases we work from a set of desired functions,using scientific and engineering techniques in a creative way.Techniques that have been applied successfully in the construction of physical artifacts are also helpful when applied to the construction of software systems:development of the product in a number of phases,a careful planning of these phases,continuous audit of the whole process,construction from a clear and complete design,etc.1.1.WHAT IS SOFTWARE ENGINEERING?9

Even in a mature engineering discipline,say bridge design,accidents do happen. Bridges collapse once in a while.Most problems in bridge design occur when designers extrapolate beyond their models and expertise.A famous example is the Tacoma Narrows Bridge failure in1940.The designers of that bridge extrapolated beyond their experience to create moreflexible stiffening girders for suspension bridges.They did not think about aerodynamics and the response of the bridge to wind.As a result, that bridge collapsed shortly after it wasfinished.This type of extrapolation seems to be the rule rather than the exception in software development.We regularly embark on software development projects that go far beyond our expertise.

There are additional reasons for considering the construction of software as something quite different from the construction of physical products.The cost of constructing software is incurred during development and not during production. Copying software is almost free.Software is logical in nature rather than physical. Physical products wear out in time and therefore have to be maintained.Software does not wear out.The need to maintain software is caused by errors detected late or by changing requirements of the user.Software reliability is determined by the manifestation of errors already present,not by physical factors such as wear and tear. We may even argue that software wears out because it is being maintained.

Viewing software engineering as a branch of engineering is problematic for another reason as well.The engineering metaphor hints at disciplined work,proper planning,good management,and the like.It suggests we deal with clearly defined needs,that can be fulfilled if we follow all the right steps.Many software development projects though involve the translation of some real world phenomenon into digital form.The knowledge embedded in this real life phenomenon is tacit,undefined, uncodified,and may have developed over a long period of time.The assumption that we are dealing with a well-defined problem simply does not hold.Rather,the design process is open ended,and the solution emerges as we go along.This dichotomy is reflected in views of thefield put in the forefront over time(Eischen,2002).In the early days,thefield was seen as a craft.As a countermovement,the term software engineering was coined,and many factory concepts got introduced.In the late1990’s, the pendulum swung back again and the craft aspect got emphasized anew,in the agile movement(see chapter3).Both engineering-like and craft-like aspects have their place,and we will give a balanced treatment of both.

Two characteristics that make software development projects extra difficult to manage are visibility and continuity.It is much more difficult to see progress in software construction than it is to notice progress in building a bridge.One often hears the phrase that a program‘is almostfinished’.One equally often underestimates the time needed tofinish up the last bits and pieces.

This‘90%complete’syndrome is very pervasive in software development.Not knowing how to measure real progress,we often use a surrogate measure,the rate of expenditure of resources.For example,a project that has a budget of100person-days is perceived as being50%complete after50person-days are expended.Strictly speaking,we then confuse speed with progress.Because of the imprecise measurement10INTRODUCTION of progress and the customary underestimation of total effort,problems accumulate as time elapses.

Physical systems are often continuous in the sense that small changes in the specification lead to small changes in the product.This is not true with software. Small changes in the specification of software may lead to considerable changes in the software itself.In a similar way,small errors in software may have considerable effects.The Mariner space rocket to Venus for example got lost because of a typing error in a FORTRAN program.In1998,the Mars Climate Orbiter got lost,because one development team used English units such as inches and feet,while another team used metric units.

We may likewise draw a comparison between software engineering and computer science.Computer science emerged as a separate discipline in the1960s.It split from mathematics and has been heavily influenced by mathematics.Topics studied in computer science,such as algorithm complexity,formal languages,and the semantics of programming languages,have a strong mathematicalflavor.PhD theses in computer science invariably contain theorems with accompanying proofs.

As thefield of software engineering emerged from computer science,it had a similar inclination to focus on clean aspects of software development that can be formalized,in both teaching and research.We used to assume that requirements can be fully stated before the project started,concentrated on systems built from scratch, and ignored the reality of trading off quality aspects against the available budget.Not to mention the trenches of software maintenance.

Software engineering and computer science do have a considerable overlap.The practice of software engineering however also has to deal with such matters as the management of huge development projects,human factors(regarding both the development team and the prospective users of the system)and cost estimation and control.Software engineers must engineer software.

Software engineering has many things in common both with otherfields of engineering and with computer science.It also has a face of its own in many ways.

1.2Phases in the Development of Software

When building a house,the builder does not start with piling up bricks.Rather,the requirements and possibilities of the client are analyzedfirst,taking into account such factors as family structure,hobbies,finances and the like.The architect takes these factors into consideration when designing a house.Only after the design has been agreed upon is the actual construction started.

It is expedient to act in the same way when constructing software.First,the problem to be solved is analyzed and the requirements are described in a very precise way.Then a design is made based on these requirements.Finally,the construction process,i.e.the actual programming of the solution,is started.There are a distinguishable number of phases in the development of software.The phases as discussed in this book are depicted infigure1.2.下载本文