Acerca del autor

Hans van Vliet has been Professor of Software Engineering at the VU University in Amsterdam, the Netherlands since 1987.

De la contraportada

Software Engineering: Principles and Practice challenges the reader to appreciate the issues, design trade-offs and teamwork required for successful software development. This new edition has been brought fully up to date, with complete coverage of all aspects of the software lifecycle and a strong focus on all the skills needed to carry out software projects on time and within budget. Highlights of the third edition include:

• Fully updated chapters on requirements engineering and software architecture.
• New chapters on component-based software engineering, service orientation and global software development.
• Extensive coverage of the human and social aspects of software development.
• Balanced coverage of both traditional heavyweight development and lightweight agile development approaches such as Extreme Programming (XP).

Written to support both introductory and advanced software engineering courses, this book is invaluable for everyone in software development and maintenance who wants an accessible account of the problems incurred in large-scale software development and the proposed solutions. A companion website with additional resources for students and instructors can be found at www.wileyeurope.com/college/van vliet

Fragmento. © Reproducción autorizada. Todos los derechos reservados.

Software Engineering

John Wiley & Sons

Chapter One

LEARNING OBJECTIVES

To understand the notion of software engineering and why it is important

To appreciate the technical (engineering), managerial, and psychological aspects of software engineering

To understand the similarities and differences between software engineering and other engineering disciplines

To know the major phases in a software development project

To appreciate ethical dimensions in software engineering

To be aware of the time frame and extent to which new developments impact software engineering practice

Computer science is still a young field. The first computers were built in the mid 1940s, since when the field has developed tremendously.

Applications from the early years of computerization can be characterized as follows: the programs were quite small, certainly when compared to those that are currently being constructed; they were written by one person; they were written and used by experts in the application area concerned. The problems to be solved were mostly of a technical nature, and the emphasis was on expressing known algorithms efficiently in some programming language. Input typically consisted of numerical data, read from such media as punched tape or punched cards. The output, also numeric, was printed on paper. Programs were run offline. If the program contained errors, the programmer studied an octal or hexadecimal dump of memory. Sometimes, the execution of the program would be followed by binary reading of machine registers at the console.

Independent software development companies hardly existed in those days. Software was mostly developed by hardware vendors and given away for free. These vendors sometimes set up user groups to discuss requirements, which they incorporated into their software. This software development support was seen as a service to their customers.

Present-day applications are rather different in many respects. Present-day programs are often very large and are developed by teams that collaborate over periods spanning several years. These teams may be scattered across the globe. The programmers are not the future users of the system they develop and they have no expert knowledge of the application area in question. The problems that are being tackled increasingly concern everyday life: automatic bank tellers, airline reservation, salary administration, electronic commerce, automotive systems, etc. Putting a man on the moon was not conceivable without computers.

In the 1960s, people started to realize that programming techniques had lagged behind the developments in software both in size and complexity. To many people, programming was still an art and had never become a craft. An additional problem was that many programmers had not been formally educated in the field. They had learned by doing. On the organizational side, solutions to problems often involved adding more and more programmers to the project, the so-called 'million-monkey' approach.

As a result, software was often delivered too late, programs did not behave as the user expected, programs were rarely adaptable to changed circumstances, and many errors were detected only after the software had been delivered to the customer. This became known as the 'software crisis'.

This type of problem really became manifest in the 1960s. Under the auspices of NATO, two conferences were devoted to the topic in 1968 and 1969 (Naur and Randell, 1968; Buxton and Randell, 1969). Here, the term 'software engineering' was coined in a somewhat provocative sense. Shouldn't it be possible to build software in the way one builds bridges and houses, starting from a theoretical basis and using sound and proven design and construction techniques, as in other engineering fields?

Software serves some organizational purpose. The reasons for embarking on a software development project vary. Sometimes, a solution to a problem is not feasible without the aid of computers, such as weather forecasting or automated bank telling. Sometimes, software can be used as a vehicle for new technologies, such as typesetting, the production of chips, or manned space trips. In yet other cases, software may increase user service (library automation, e-commerce) or save money (automated stock control).

In many cases, the expected economic gain will be a major driving force for automation. It may not, however, always be easy to prove that automation saves money (just think of office automation) because, apart from direct cost savings, the economic gain may also manifest itself in such things as more flexible production or a faster or better user service. In either case, software development is a value-creating activity.

Boehm (1981) estimated the total expenditure on software in the US to be $40 billion in 1980. This was approximately 2% of the GNP. In 1985, the total expenditure had risen to $70 billion in the US and $140 billion worldwide. Boehm and Sullivan (1999) estimated the annual expenditure on software development in 1998 to be $300-400 billion in the US and twice that amount worldwide.

So the cost of software is of crucial importance. This concerns not only the cost of developing the software, but also the cost of keeping the software operational once it has been delivered to the customer. In the course of time, hardware costs have decreased dramatically. Hardware costs now typically comprise less than 20% of total expenditure (see Figure 1.1). The remaining 80% are comprised of all non-hardware costs: the cost of programmers, analysts, management, user training, secretarial help, etc.

An aspect closely linked with cost is productivity. In the 1980s, the quest for data-processing personnel increased by 12% per year, while the population of people working in data processing and the productivity of those people each grew by approximately 4% per year (Boehm, 1987a). This situation has not fundamentally changed (Jones, 1999). The net effect is a growing gap between demand and supply. The result is both a backlog with respect to the maintenance of existing software and a slowing down in the development of new applications. The combined effect may have repercussions on the competitive edge of an organization, especially when there are severe time-to-market constraints. These developments have led to a shift from producing software to using software. We'll come back to this topic in Section 1.6 and Chapters 17-19.

The issues of cost and productivity of software development deserve our serious attention. However, this is not the complete story. Society is increasingly dependent on software. The quality of the systems we develop increasingly determines the quality of our existence. Consider as an example the following message from a Dutch newspaper on 6 June 1980, under the heading 'Americans saw the Russians coming':

For a short period last Tuesday, the United States brought their atomic bombers and nuclear missiles to an increased state of alarm when, because of a computer error, a false alarm indicated that the Soviet Union had started a missile attack.

Efforts to repair the error were apparently in vain, for on 9 June 1980, the same newspaper reported:

For the second time within a few days, a deranged computer reported that the Soviet Union had started a nuclear attack against the United States. Last Saturday, the DoD affirmed the false message, which resulted in the engines of the planes of the strategic air force being started.

It is not always the world that is in danger. On a smaller scale, errors in software may have very unfortunate consequences, such as transaction errors in bank traffic; reminders to pay a bill of $0.00; a stock control system that issues orders too late and thus lays off complete divisions of a factory.

The latter example indicates that errors in a software system may have serious financial consequences for the organization using it. One example of such a financial loss is the large US airline company that lost $50 million 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 April 1983:

The court in Dsseldorf 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 her 15-year-old daughter and tried to kill her 13-year-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 the field of software engineering. Better methods and techniques for software development may result in large financial savings, in more effective methods of software development, in systems that better fit 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 the field of software engineering.

On the positive side, it is imperative to point to the enormous progress that has been made since the 1960s. 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.1 WHAT IS SOFTWARE ENGINEERING?

In various texts on this topic, one encounters a definition of the term software engineering. An early definition was given at the first 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 Terminology (IEEE610, 1990) is as follows:

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 the field are always, explicitly or implicitly, present:

Software engineering concerns the development of large programs.

(DeRemer and Kron, 1976) makes a distinction between programming-in-the-large and programming-in-the-small. The borderline between large and small obviously is not sharp: a program of 100 lines is small, a program of 50 000 lines 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 contains 40 million lines of object code (this is 30 times as much as the software for the Saturn V project from the 1960s) (Boehm, 1981);

- The IBM OS360 operating system took 5000 man years of development effort (Brooks, 1995).

Traditional programming techniques and tools are primarily aimed at supporting programming-in-the-small. This not only holds for programming languages, but also for the tools (such as flowcharts) and methods (such as structured programming). 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 not 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.

The 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 the field 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 should fit users' tasks. Users who 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.

(Continues...)

Excerpted from Software Engineeringby Hans van Vliet Copyright © 2008 by Hans van Vliet. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.