Software Engineering / Edition 1

Paperback (Print)
Buy New
Buy New from BN.com
$85.90
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 98%)
Other sellers (Paperback)
  • All (20) from $1.99   
  • New (5) from $91.46   
  • Used (15) from $1.99   

Overview

Describes the current state-of-the-practice of software engineering. This book begins with an overview of current issues and in particular the engineering of large complex systems. It goes on to describe the problems that occur in developing software, and presents the concepts for system engineering of software intensive systems and of engineering software products as the solution to the "software crisis". 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 text 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.

Software Engineering describes the current state-of-the-art practice of software engineering, beginning with an overview of current issues and focusing on the engineering of large complex systems. The text illustrates the phases of the software development life cycle: requirements, design, implementation, testing and maintenance.

Read More Show Less

Product Details

  • ISBN-13: 9780818676093
  • Publisher: Wiley
  • Publication date: 11/15/1996
  • Series: Practitioners Series , #45
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 552
  • Product dimensions: 8.33 (w) x 11.04 (h) x 1.15 (d)

Meet the Author

Merlin Dorfman, PhD, is a Technical Consultant in the SpaceSystems Product Center, Lockhead Martin Missiles and Space Company,Sunnyvale, Calif. He specializes in systems engineering forsoftware-intensive systems (requirements analysis, top-levelarchitecture, and performance evaluation), in software processimprovement, and in algorithm development for data processingsystems. He has performed concept exploration, systemimplementation, and operations and maintenance of data systems andhas worked on proposal teams and company-funded technology projectsas well as on development contracts. He was in charge of thedevelopment of the Automated Requirements Traceability System(ARTS). He was the first chairman of space Systems Division'sSoftware Engineering Process Group. He represented the LockheadCorporation on the Embedded Computer Committee of the AerospaceIndustries Association, and was Vice-Chairman of theCommittee.
Dorfman wrote and taught a four-day course, "Software Requirementsand Design Specifications," for Learning Tree International of LosAngeles, Calif. He co-teaches a two-week course in Software ProjectManagement for the Center for Systems Management of Cupertino,Calif. He has been a guest lecturer on software systems engineeringat the Defense Systems Management College. He is a Fellow of theAmerican Institute of Aeronautics and Astronautics (AIAA), a memberof its System Engineering Technical Committee, past chairman of theSoftware Systems Technical Committee, and past Chairman of the AIAASan Francisco Section, and is currently Assistant Director ofRegion 6 (West Coast). He is an affiliate member of the Instituteof Electrical and Electronics Engineers (IEEE) ComputerSociety.
He has a BS and MS from the Massachusetts Institute of Technologyand a PhD from Stanford University, all in Aeronautics andAstronautics. He is a registered Professional Engineer in thestates of California and Colorado and is a member of the Tau BetaPi and Sigma Gamma Tau honorary societies.
He is co-editor of two IEEE Tutorial volumes, Systems andSoftware Requirements Engineering and Standards, Guidelines,and Examples for System and Software Requirements Engineering,and co-editor of a volume, Aerospace Software Engineering inthe AIAA "Progress in Aeronautics and Astronautics"

Richard H. Thayer, PhD, is a Professor of ComputerScience at California State University, Sacramento, California,United States of America. He travels widely where he consults andlectures on software requirements analysis, software engineering,project management, software engineering standards, and softwarequality assurance. He is a Visiting Researcher at the University ofStrathclyde, Glasgow, Scotland. As an expert in software projectmanagement and requirements engineering, he is a consultant to manycompanies and government agencies.
Prior to this, he served over 20 years in the U.S. Air Force as asenior officer in a variety of positions associated withengineering, computer programming, research, teaching, andmanagement in computer science and data processing. His numerouspositions include six years as a supervisor and technical leader ofscientific programming groups, four years directing the U.S. AirForce R&D program in computer science, and six years ofmanaging large data processing organizations.
Thayer is a Senior Member of the IEEE Computer Society and the IEEESoftware Engineering Standards Subcommittee. He is Chairperson forthe Working Group for Standard for a Concept of Operations (ConOps)document and past chairperson for the Working Group for a Standardfor a Software Project Management Plans. He is a DistinguishedVisitor for the IEEE Computer Society.
He is also an Associate Fellow of the American Institute ofAeronautics and Astronautics (AIAA) where he served on the AIAATechnical Committee on Computer Systems, and he is a member of theAssociation for Computer Machinery (ACM). He is also a registeredprofessional engineer.
He has a BSEE and an MS degree from the University of Illinois atUrbana (1962) and a PhD from the University of California at SantaBarbara (1979) all in Electrical Engineering.
He has edited and/or co-edited numerous tutorials for the IEEEComputer Society Press: Software Engineering ProjectManagement (1988), System and Software RequirementEngineering (1990), and Software Engineering—AEuropean Prospective (1992). He is the author of over 40technical papers and reports on software project management,software engineering, and software engineering standards and is aninvited speaker at many national and international softwareengineering conferences and workshops.

Read More Show Less

Read an Excerpt

Software Engineering


John Wiley & Sons

ISBN: 0-8186-7609-4


Chapter One

Issues-The Software Crisis

1. 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.

Read More Show Less

Table of Contents

List of Contributors.

Foreword (Barry Boehm, USC).

Preface.

Chapter 1: Issues — The Software Crisis. Software'sChronic 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 EngineeringJournal, May 1993).

The Concept of Operations: The Bridge from OperationalRequirements to Technical Specifications (Richard E. Fairley andRichard 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 SoftwareDesign.

Software Requirements: A Tutorial (Stuart Faulk).

Software Design: An Introduction (David Budgen).

Design Methods for Concurrent and Real-Time Systems (HussanGomaa).

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 StructuredMethods (A.G. Sutcliffe, Information and SoftwareTechnology, July/August 1991).

Structured Systems Analysis and Design Method (SSADM) (CarolineAshworth, Information and Software Technology, April1988).

A Review of Formal Methods (Robert Vienneau, extracted from AReview 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 JohnPugh).

Chapter 7: Software Validation, Verification, and Testing.

Software Verification and Validation (Roger Fujii and Dolores R.Wallace).

Software Inspections and the Cost-Effective Production ofReliable Software (A. Frank Ackerman).

Reviews and Audits (John J. Marciniak).

Traceability (James D. Palmer).

A Review of Software Testing (P. David Coward, Informationand 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, January1984).

Evaluating Software Engineering Standards (Shari LawrencePfleeger, Norman Fenton, and Stella Page, IEEE Software,September 1994).

Software-Reliability Engineering: Technology for the 1990s (JohnD. Musa and William W. Everett, IEEE Software, November1990).

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, IEEESoftware, March 1993).

Software Cost Estimation (F.J. Heemstra, Information andSoftware Technology, October 1992).

Risk Management for Software Development (Richard E. Fairley andPaul 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, BillCurtis, Mary Beth Chrissis, and Charles V. Weber).

Chapter 12: Software Technology.

The Re-engineering and Reuse of Software (Patrick A.V. Hall andLingzi 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 MetricsProgram (Ronald E. Nusenoff and Dennis C. Bunde, Journal ofSystems and Software, Volume 23, 1993).

Industrial Software Metrics Top 10 List (Barry Boehm, IEEESoftware, 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 PearlBrereton).

Software Engineering Standards (Richard H. Thayer).

Software Engineering Survey Results (Merlin Dorfman).

Authors' Biographies.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)