The text illustrates the phases of the software development life cycle: requirements, design, implementation, testing, and maintenance. Furthermore, it discusses the current practices in requirements and design, and defines software development methodologies, including a special emphasis on object-oriented tools and formal methods. The book also covers programming activities as they affect software engineering, details verification and validation throughout the software life cycle, and discusses software quality assurance, configuration management, and standards. In addition, the book covers project management and risk management concerns, and discusses the various life cycle process models including the spiral and incremental models.
The text illustrates the phases of the software development life cycle: requirements, design, implementation, testing, and maintenance. Furthermore, it discusses the current practices in requirements and design, and defines software development methodologies, including a special emphasis on object-oriented tools and formal methods. The book also covers programming activities as they affect software engineering, details verification and validation throughout the software life cycle, and discusses software quality assurance, configuration management, and standards. In addition, the book covers project management and risk management concerns, and discusses the various life cycle process models including the spiral and incremental models.
Paperback
-
SHIP THIS ITEMIn stock. Ships in 1-2 days.PICK UP IN STORE
Your local store may have stock of this item.
Available within 2 business hours
Related collections and offers
Overview
The text illustrates the phases of the software development life cycle: requirements, design, implementation, testing, and maintenance. Furthermore, it discusses the current practices in requirements and design, and defines software development methodologies, including a special emphasis on object-oriented tools and formal methods. The book also covers programming activities as they affect software engineering, details verification and validation throughout the software life cycle, and discusses software quality assurance, configuration management, and standards. In addition, the book covers project management and risk management concerns, and discusses the various life cycle process models including the spiral and incremental models.
Product Details
| ISBN-13: | 9780818676093 |
|---|---|
| Publisher: | Wiley |
| Publication date: | 11/15/1996 |
| Series: | Practitioners , #45 |
| Pages: | 552 |
| Product dimensions: | 8.30(w) x 10.90(h) x 1.30(d) |
About the Author
Dorfman wrote and taught a four-day course, "Software Requirements and Design Specifications," for Learning Tree International of Los Angeles, Calif. He co-teaches a two-week course in Software Project Management for the Center for Systems Management of Cupertino, Calif. He has been a guest lecturer on software systems engineering at the Defense Systems Management College. He is a Fellow of the American Institute of Aeronautics and Astronautics (AIAA), a member of its System Engineering Technical Committee, past chairman of the Software Systems Technical Committee, and past Chairman of the AIAA San Francisco Section, and is currently Assistant Director of Region 6 (West Coast). He is an affiliate member of the Institute of Electrical and Electronics Engineers (IEEE) Computer Society.
He has a BS and MS from the Massachusetts Institute of Technology and a PhD from Stanford University, all in Aeronautics and Astronautics. He is a registered Professional Engineer in the states of California and Colorado and is a member of the Tau Beta Pi and Sigma Gamma Tau honorary societies.
He is co-editor of two IEEE Tutorial volumes, Systems and Software Requirements Engineering and Standards, Guidelines, and Examples for System and Software Requirements Engineering, and co-editor of a volume, Aerospace Software Engineering in the AIAA "Progress in Aeronautics and Astronautics"
Richard H. Thayer, PhD, is a Professor of Computer Science at California State University, Sacramento, California, United States of America. He travels widely where he consults and lectures on software requirements analysis, software engineering, project management, software engineering standards, and software quality assurance. He is a Visiting Researcher at the University of Strathclyde, Glasgow, Scotland. As an expert in software project management and requirements engineering, he is a consultant to many companies and government agencies.
Prior to this, he served over 20 years in the U.S. Air Force as a senior officer in a variety of positions associated with engineering, computer programming, research, teaching, and management in computer science and data processing. His numerous positions include six years as a supervisor and technical leader of scientific programming groups, four years directing the U.S. Air Force R&D program in computer science, and six years of managing large data processing organizations.
Thayer is a Senior Member of the IEEE Computer Society and the IEEE Software Engineering Standards Subcommittee. He is Chairperson for the Working Group for Standard for a Concept of Operations (ConOps) document and past chairperson for the Working Group for a Standard for a Software Project Management Plans. He is a Distinguished Visitor for the IEEE Computer Society.
He is also an Associate Fellow of the American Institute of Aeronautics and Astronautics (AIAA) where he served on the AIAA Technical Committee on Computer Systems, and he is a member of the Association for Computer Machinery (ACM). He is also a registered professional engineer.
He has a BSEE and an MS degree from the University of Illinois at Urbana (1962) and a PhD from the University of California at Santa Barbara (1979) all in Electrical Engineering.
He has edited and/or co-edited numerous tutorials for the IEEE Computer Society Press: Software Engineering Project Management (1988), System and Software Requirement Engineering (1990), and Software Engineering—A European Prospective (1992). He is the author of over 40 technical papers and reports on software project management, software engineering, and software engineering standards and is an invited speaker at many national and international software engineering conferences and workshops.
Read an Excerpt
Software Engineering
John Wiley & Sons
ISBN: 0-8186-7609-4Chapter One
Issues-The Software Crisis1. Introduction to Chapter
The term "software crisis" has been used since the late 1960s to describe those recurring system development problems in which software development problems cause the entire system to be late, over budget, not responsive to the user and/or customer requirements, and difficult to use, maintain, and enhance. The late Dr. Winston Royce, in his paper Current Problems, emphasized this situation when he said in 1991:
The construction of new software that is both pleasing to the user/buyer and without latent errors is an unexpectedly hard problem. It is perhaps the most difficult problem in engineering today, and has been recognized as such for more than 15 years. It is often referred to as the "software crisis". It has become the longest continuing "crisis" in the engineering world, and it continues unabated.
This chapter describes some of the current issues and problems in system development that are caused by software-software that is late, is over budget, and/or does not meet the customers' requirements or needs.
Software is the set of instructions that govern the actions of a programmable machine. Software includes application programs, system software, utility software, and firmware. Software does not include data, procedures, people, and documentation. In this tutorial, "software" is synonymous with "computer programs."
Because software is invisible, it is difficult to be certain of development progress or of product completeness and quality. Software is not governed by the physical laws of nature: there is no equivalent of Ohm's Law, which governs the flow of electricity in a circuit; the laws of aerodynamics, which act to keep an aircraft flying stably in the air; or Maxwell's Equations, which describe the radiation of energy from an antenna.
In addition, software is not manufactured like hardware; it does not have a production phase nor manufactured spare parts like hardware; it is typically custom-built, not assembled from existing components like hardware. Even in today's society, software is viewed with suspicion by many individuals, such as senior managers and customers, as somewhat akin to "black magic."
The result is that software is one of the most difficult artifacts of the modern world to develop and build.
2. Introduction to Papers
The opening paper fortuitously appeared in a recent issue of Scientific American as the editors were casting about for a way to incorporate a recent rash of high-publicity software problems into the motivation for this tutorial. The paper defines and presents essentially all the major issues currently plaguing software development and maintenance. The article is "popular" rather than technical in the sense that it is journalistic in style and focuses on popular perceptions of software as "black magic," but it raises many issues that software professionals need to be familiar with. It is also worth noting that many of the problems described are partly or largely due to non-software issues such as politics, funding, and external constraints, but again the software professional needs to know that problems unrelated to software engineering must overcome if software projects are to be successful.
The term "software crisis" not unexpectedly originated with the military, for that is where large, complex "real-time" software was first developed. More recently, as civilian and commercial software systems have approached and exceeded military systems in size, complexity, and performance requirements, the "software crisis" has occurred in these environments as well. It is noteworthy that the Scientific American article mentions military systems only peripherally.
The article begins with a discussion of the highly-publicized and software-related failure of the baggage system at the new Denver International Airport. As of the date of the article, opening of the airport had been delayed four times, for almost a year, at a cost to the airport authority of over $1 million a day.
Almost as visible in recent months, and also mentioned in the article, are failures of software development for the Department of Motor Vehicles (DMV) of the State of California, and for the advanced air traffic control system of the US Federal Aviation Administration (FAA). The DMV project involved attempts to merge existing, separately developed systems that managed driver's licenses and vehicle registrations. As has been pointed out in the press, the State of California has had problems with computer projects of over $1 billion in value, and the problems resulted from the acquisition policies of the State of California (how contractors and consultants are selected and managed by the State), and from hardware-software integration difficulties, as well as from causes strictly related to software development.
The article identifies the first use of the term "software engineering" in a 1968 conference of the NATO Science Committee in Garmisch, Germany. (See also the Bauer article in this Tutorial.) Many approaches that have been proposed to improve software development are discussed; the author feels that most of these ideas have not lived up to the expectations of their originators. Also discussed is the idea that there are no "silver bullets." (See the article by Brooks in this chapter.)
The Scientific American article looks favorably on the use of formal specification methods to solve the problem of software quality, and on "software reuse" (the ability to use a software product developed for one application again later for another application) to solve the productivity or cost problem.
The Software Engineering Institute's Capability Maturity Model was also favorably mentioned (see the article by Paulk, Curtis, Chrissis, and Weber in this Tutorial) as a motivation to software developers to improve their practices. The paper reports an SEI finding that approximately 75 percent of all software developers do not have any formal process or any productivity or quality metrics.
Because software development depends on an educated workforce and good communications rather than on a fixed plant of any kind, software is inherently a suitable export product for developing countries. Although the US is still strong in software design and project management, the article notes that third world countries-notably India and Far Eastern countries-are capable of producing many more "lines of code" per dollar.
A sidebar by Dr. Mary Shaw provides a view of software engineering's history, and of how that history may serve as a roadmap for software engineering's future. Finally, the paper urges education of computer science students in software engineering as an essential step toward resolving the software crisis.
The second and last article in this chapter, "No Silver Bullets: Essence and Accidents of Software Engineering," is by Fred Brooks, one of the legendary figures in software engineering. He has been called the father of software engineering project management in the United States. He worked at IBM in the 1960s and was the software project manager for the OS/360 operating system.
This paper, which he wrote in 1987, states that "no single technique exists to solve the software crisis, that there is no silver bullet." The easy problems ("accidents") have been solved and the remaining difficulties are "essential." He views the solution to the software crisis as a collection of many software engineering tools and techniques that, used in combination, will reduce or eliminate software problems. Although Brooks sees no single solution to the software crisis, no single technology or management technique, he does see encouragement for the future through disciplined, consistent efforts to develop, propagate, and exploit many of the software tools and techniques that are being developed today. (In a report, also written in 1987, Brooks states his belief that most software development problems of the US Department of Defense are managerial rather than technical.)
Brooks believes the hard part of building software is the specification and design of a system, not the coding and testing of the final product. As a result, he believes that building software will always be hard. There is no apparent simple solution. Brooks describes the three major advances in software development as:
The use of high level languages
The implementation of time-sharing to improve the productivity of programmers and the quality of their products
Unified programming environment
Brooks also cites the Ada language, object-oriented programming, artificial intelligence, expert systems, and "automatic" programming (automated generation of code from system specification and design) as technologies with the potential for improving software. From the perspective of another eight years, the Al-related technologies for the most part have yet to fulfill the potential that Brooks saw for them in 1987.
Trends in Computing
Software's Chronic Crisis
by W. Wayt Gibbs, staff writer
Denver's new international airport was to be the pride of the Rockies, a wonder of modern engineering. Twice the size of Manhattan, 10 times the breadth of Heathrow, the airport is big enough to land three jets simultaneously-in bad weather. Even more impressive than its girth is the airport's subterranean baggage-handling system. Tearing like intelligent coal-mine cars along 21 miles of steel track, 4,000 independent "telecars" route and deliver luggage between the counters, gates and claim areas of 20 different airlines. A central nervous system of some 100 computers networked to one another and to 5,000 electric eyes, 400 radio receivers and 56 bar-code scanners orchestrates the safe and timely arrival of every valise and ski bag.
At least that is the plan. For nine months, this Gulliver has been held captive by Lilliputians-errors in the software that controls its automated baggage system. Scheduled for takeoff by last Halloween, the airport's grand opening was postponed until December to allow BAE Automated Systems time to flush the gremlins out of its $193-million system. December yielded to March. March slipped to May. In June the airport's planners, their bond rating demoted to junk and their budget hemorrhaging red ink at the rate of $1.1 million a day in interest and operating costs, conceded that they could not predict when the baggage system would stabilize enough for the airport to open.
To veteran software developers, the Denver debacle is notable only for its visibility. Studies have shown that for every six new large-scale software systems that are put into operation, two others are canceled. The average software development project overshoots its schedule by half; larger projects generally do worse. And some three quarters of all large systems are "operating failures" that either do not function as intended or are not used at all.
The art of programming has taken 50 years of continual refinement to reach this stage. By the time it reached 25, the difficulties of building big software loomed so large that in the autumn of 1968 the NATO Science Committee convened some 50 top programmers, computer scientists and captains of industry to plot a course out of what had come to be known as the software crisis. Although the experts could not contrive a road map to guide the industry toward firmer pound, they did coin a name for that distant goal: software engineering, now defined formally as "the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software."
A quarter of a century later software engineering remains a term of aspiration. The vast majority of computer code is still handcrafted from raw programming languages by artisans using techniques they neither measure nor are able to repeat consistently. "It's like musket making was before Eli Whitney," says Brad J. Cox, a professor at George Mason University. "Before the industrial revolution, there was a nonspecialized approach to manufacturing goods that involved very little interchangeability and a maximum of craftsmanship. If we are ever going to lick this software crisis, we're going to have to stop this hand-to-mouth, every-programmer-builds-everything-from-the-ground-up, preindustrial approach."
The picture is not entirely bleak. Intuition is slowly yielding to analysis as programmers begin using quantitative measurements of the quality of the software they produce to improve the way they produce it. The mathematical foundations of programming are solidifying as researchers work on ways of expressing program designs in algebraic forms that make it easier to avoid serious mistakes. Academic computer scientists are starting to address their failure to produce a solid corps of software professionals. Perhaps most important, many in the industry are turning their attention toward inventing the technology and market structures needed to support interchangeable, reusable software parts.
"Unfortunately, the industry does not uniformly apply that which is well-known best practice," laments Larry E. Druifel, director of Carnegie Mellon University's Software Engineering Institute. In fact, a research innovation typically requires 18 years to wend its way into the repertoire of standard programming techniques. By combining their efforts, academia, industry and government may be able to hoist software development to the level of an industrial-age engineering discipline within the decade. If they come up short, society's headlong rush into the information age will be halting and unpredictable at best.
Shifting Sands
"We will see massive changes [in computer use] over the next few years, causing the initial personal computer revolution to pale into comparative insignificance," concluded 22 leaders in software development from academia, industry and research laboratories this past April. The experts gathered at Hedsor Park, a corporate retreat near London, to commemorate the NATO conference and to analyze the future directions of software. "In 1968 we knew what we wanted to build but couldn't," reflected Cliff Jones, a professor at the University of Manchester. "Today we are standing on shifting sands."
The foundations of traditional programming practices are eroding swiftly, as hardware engineers churn out ever faster, cheaper and smaller machines. Many fundamental assumptions that programmers make-for instance, their acceptance that everything they produce will have defects-must change in response. "When computers are embedded in light switches, you've got to get the software right the first time because you're not going to have a chance to update it," says Mary M. Shaw, a professor at Carnegie Mellon.
"The amount of code in most consumer products is doubling every two years," notes Remi H. Bourgonjon, director of software technology at Philips Research Laboratory in Eindhoven. Already, he reports, televisions may contain up to 500 kilobytes of software; an electric shaver, two kilobytes. The power trains in new General Motors cars run 30,000 lines of computer code.
(Continues...)
Excerpted from Software Engineering 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.
Table of Contents
List of Contributors.Foreword (Barry Boehm, USC).
Preface.
Chapter 1: Issues — The Software Crisis. Software's Chronic Crisis (W. Wayt Gibbs, Scientific American, September 1994).
No Silver Bullet: Essence and Accidents of Software Engineering (Frederick P. Brooks, Computer, 1987).
Chapter 2: System and Software System Engineering.
Engineering a Small System (Kurt Skytte, IEEE Spectrum, March 1994).
Software Systems Engineering: The Case for a New Discipline (Stephen J. Andriole and Peter A. Freeman, Software Engineering Journal, May 1993).
The Concept of Operations: The Bridge from Operational Requirements to Technical Specifications (Richard E. Fairley and Richard H. Thayer).
Chapter 3: Software Engineering.
Software Engineering (Roger S. Pressman).
Foreword: Software Engineering — A European Perspective (Freidrich L. Bauer).
Software Engineering — 20 Years On and 20 Years Back (J.N. Buxton, Journal of Systems and Software, Volume 13, 1990).
Chapter 4: Software Requirements Engineering and Software Design.
Software Requirements: A Tutorial (Stuart Faulk).
Software Design: An Introduction (David Budgen).
Design Methods for Concurrent and Real-Time Systems (Hussan Gomaa).
Computer Human Interface Software Development Survey (Robert J. Remington).
Chapter 5: Software Development Methodologies.
Object-Oriented Development (Linda M. Northrop).
Object-Oriented Systems Development: Survey of Structured Methods (A.G. Sutcliffe, Information and Software Technology, July/August 1991).
Structured Systems Analysis and Design Method (SSADM) (Caroline Ashworth, Information and Software Technology, April 1988).
A Review of Formal Methods (Robert Vienneau, extracted from A Review of Formal Methods, Kaman Science Corporation, May 26, 1993).
Chapter 6: Coding.
Structured Programming: Retrospect and Prospect (Harlan D. Mills, IEEE Software, November 1986).
The Programming Language (Dough Bell, Ian Morrey, and John Pugh).
Chapter 7: Software Validation, Verification, and Testing.
Software Verification and Validation (Roger Fujii and Dolores R. Wallace).
Software Inspections and the Cost-Effective Production of Reliable Software (A. Frank Ackerman).
Reviews and Audits (John J. Marciniak).
Traceability (James D. Palmer).
A Review of Software Testing (P. David Coward, Information and Software Technology, April 1988).
Chapter 8: Software Maintenance.
Software Maintenance: A Tutorial (Keith Bennett).
Chapter 9: Software Quality and Quality Assurance.
Software Quality Assurance: A Survey of an Emerging View (Patricia W. Hurst).
Elements of Software Configuration Management (Edward H. Bersoff, IEEE Transactions on Software Engineering, January 1984).
Evaluating Software Engineering Standards (Shari Lawrence Pfleeger, Norman Fenton, and Stella Page, IEEE Software, September 1994).
Software-Reliability Engineering: Technology for the 1990s (John D. Musa and William W. Everett, IEEE Software, November 1990).
Chapter 10: Software Project Management.
The Mythical Man-Month (Frederick P. Brooks Jr., Datamation, December 1974).
Software Engineering Project Management (Richard H. Thayer).
Why Does Software Cost so Much? (Tom DeMarco, IEEE Software, March 1993).
Software Cost Estimation (F.J. Heemstra, Information and Software Technology, October 1992).
Risk Management for Software Development (Richard E. Fairley and Paul Rook).
Chapter 11: Software Development Process.
Alternative Software Life Cycle Models (Edward R. Comer, Aerospace Software Engineering: A Collection of Concepts, American Institute of Aeronautics, 1991).
A Spiral Model of Software Development and Enhancement (Barry W. Boehm, Computer, May 1988).
Capability Maturity Model for Software (Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, and Charles V. Weber).
Chapter 12: Software Technology.
The Re-engineering and Reuse of Software (Patrick A.V. Hall and Lingzi Jin).
Prototyping: Alternate Systems Development Methodology (J.M. Carey, Information and Software Technology, March 1990)
A Classification of CASE Technology (Alfonso Fuggetta, Computer, December 1993).
A Guidebook and a Spreadsheet Tool for a Corporate Metrics Program (Ronald E. Nusenoff and Dennis C. Bunde, Journal of Systems and Software, Volume 23, 1993).
Industrial Software Metrics Top 10 List (Barry Boehm, IEEE Software, September 1987).
Chapter 13: Software Engineering Education.
Education for Computing Professionals (David L. Parnas, Computer, January 1990).
Appendix.
A Software Engineering Bibliography (David Budgen and Pearl Brereton).
Software Engineering Standards (Richard H. Thayer).
Software Engineering Survey Results (Merlin Dorfman).
Authors' Biographies.