Software Engineering: Theory and Practice / Edition 4

Hardcover (Print)
Rent
Rent from BN.com
$31.08
(Save 82%)
Est. Return Date: 12/01/2014
Used and New from Other Sellers
Used and New from Other Sellers
from $81.85
Usually ships in 1-2 business days
(Save 53%)
Other sellers (Hardcover)
  • All (4) from $81.85   
  • Used (4) from $81.85   

Overview

KEY BENEFIT: This introduction to software engineering and practice addresses both procedural and object-oriented development. KEY TOPICS: Is thoroughly updated to reflect significant changes in software engineering, including modeling and agile methods. Emphasizes essential role of modeling design in software engineering. Applies concepts consistently to two common examples — a typical information system and a real-time system. Combines theory with real, practical applications by providing an abundance of case studies and examples from the current literature. MARKET: A useful reference for software engineers.
Read More Show Less

Editorial Reviews

Booknews
A textbook designed for an undergraduate software engineering curriculum. Topics include different types of process and life- cycle models, work breakdown structure, requirements analysis, architectural issues, testing approaches and methodologies, documentation, evaluation, and prediction models. The many examples used throughout the text are chosen to reflect students' limited experience but illustrate clearly how large software development projects progress from need to idea to reality. Annotation c. by Book News, Inc., Portland, Or.
Read More Show Less

Product Details

  • ISBN-13: 9780136061694
  • Publisher: Prentice Hall
  • Publication date: 3/2/2009
  • Edition description: New Edition
  • Edition number: 4
  • Pages: 792
  • Sales rank: 541,902
  • Product dimensions: 7.30 (w) x 9.30 (h) x 1.30 (d)

Meet the Author

Shari Lawrence Pfleeger (Ph.D., Information Technology and Engineering, George Mason University; M.S., Planning, The Pennsylvania State University; M.A., Mathematics, The Pennsylvania State University; B.A., Mathematics with high honors, Harpur College, Binghamton, NY) is a senior researcher at RAND’s Arlington, VA office where she helps organizations and government agencies understand whether and how information technology supports their mission and goals. Dr. Pfleeger began her career as a mathematician and then a software developer and maintainer for real-time, business-critical software systems. From 1982 to 2002, Dr. Pfleeger was president of Systems/Software, Inc., a consultancy specializing in software engineering and technology. From 1997 to 2000, she was also a visiting professor at the University of Maryland's computer science department. In the past, she was founder and director of Howard University's Center for Research in Evaluating Software Technology (CREST), and was a visiting scientist at the City University (London) Centre for Software Reliability, principal scientist at MITRE Corporation's Software Engineering Center, and manager of the measurement program at the Contel Technology Center (named by the Software Engineering Institute as one of the best such programs in the country). Dr. Pfleeger is well-known for her work in software quality, software assurance, and empirical studies of software engineering; she is particularly known for her multi-disciplinary approach to solving information technology problems.

She is also well-known for her publications, many of which are required reading in software engineering curricula, including "Software Engineering: Theory and Practice" (3rd edition, with Joanne Atlee, 2005, Prentice Hall), "Security in Computing" (3rd edition, with Charles P. Pfleeger, 2003, Prentice Hall), "Solid Software" (2001, with Les Hatton and Charles Howell, Prentice Hall), and "Software Metrics: A Rigorous and Practical Approach" (2nd edition, with Norman Fention, 1996, Boyd and Fraser Publishers). Dr. Pfleeger is book review editor for IEEE Security and Privacy. For several years, she was the associate editor-in-chief of IEEE Software, where she edited the Quality Time column, and then associate editor of IEEE Transactions on Software Engineering. From 1998 to 2002, she was a member of the editorial board of Prentice Hall's Software Quality Institute series. She is a senior member of IEEE, the IEEE Computer Society, and the Association for Computing Machinery.

Joanne M. Atlee is an Associate Professor in the School of Computer Science at the University of Waterloo. Her research program focuses on software modeling, documentation, and analysis, with a particular emphasis on what she calls practical formalisms: specification and design notations that are practitioner-friendly but have a precise semantics suitable for automated analysis. More recently, she has been working on configurable model-driven development, whereby modeling notations, analysis tools, and code generators can be configured via semantics parameters.

Atlee was the founding Director of Waterloo’s Software Engineering degree program. She served on the Steering Committee for the Computing Curricula Software Engineering volume, co-sponsored by IEEE-CS and ACM. She is the vice chair of the International Federation for Information Processing (IFIP) Working Group 2.9 on software requirements engineering. Atlee was the program-committee chair for the International Conference on Requirements Engineering in 2005 (RE'05), and will be co-chair of the program committee for the International Conference on Software Engineering in 2009 (ICSE'09). She is a co-author with Shari Lawrence Pfleeger on the textbook "Software Engineering - Theory and Practice."

Read More Show Less

Read an Excerpt

PREFACE:

Preface

BRIDGING THE GAP BETWEEN RESEARCH AND PRACTICE

Software engineering has come a long way since 1968, when the term was first used at a NATO conference. And software itself has entered our lives in ways that few had anticipated, even a decade ago. So a firm grounding in software engineering theory and practice is essential for understanding how to build good software and for evaluating the risks and opportunities that software presents in our everyday lives. This text represents the blending of the two current software engineering worlds: that of the practitioner, whose main focus is to build high-quality products that perform useful functions, and that the researcher, who strives to find ways to improve the quality of products and the productivity of those who build them.

Designed for an undergraduate software engineering curriculum, this book paints a pragmatic picture of software engineering research and practices. Examples speak to a student's limited experience but illustrate clearly how large software development projects progress from need to idea to reality.

The book is also suitable for a graduate course offering an introduction to software engineering concepts and practices, or for practitioners wishing to expand their knowledge of the subject. It includes examples that represent the many situations readers are likely to experience: large projects and small, object-oriented and procedural, real-time and transaction processing, development and maintenance. In particular, Chapters 12, 13, and 14 present thought-provoking material designed to interest graduate students in current research topics.

KEY FEATURES

This text has many key features that distinguish it from other books.

  • Unlike other software engineering books that consider measurement a separate issue, this book blends measurement with software engineering. Measurement issues are considered as an integral part of software engineering strategy, rather than as a separate discipline. This approach shows students how to involve quantitative assessment and improvement in their daily activities. They can evaluate their progress on an individual, team, and project basis.
  • Similarly, concepts such as reuse, risk management, and quality engineering are embedded in the software engineering activities that are affected by them, instead of treating them as separate issues.
  • Each chapter applies its concepts to two common examples: one that represents a typical information system, and another that represents a real-time system. Both examples are based on actual projects. The information system example describes the software needed to determine the price of advertising time for a large British television company. The real-time system is the control software for the Ariane-5 rocket; we look at the problems reported, and explore how software engineering techniques could have helped to locate and avoid some of them. Students can follow the progress of two typical projects, seeing how the various practices described in the book are merged into the technologies used to build systems.
  • At the end of every chapter, the results are expressed in three ways: what the content of the chapter means for development teams, what it means for individual developers, and what it means for researchers. The student can easily review the highlights of each chapter and see the chapter's relevance to both research and practice.
  • The book has an associated Web page, containing current examples from the literature, links to Web pages for relevant tool and method vendors, and a study guide for students. It is on the Web that students can find real requirements documents, designs, code, test plans, and more, so they can see real software engineering project artifacts. Students seeking additional in-depth information are pointed to reputable accessible publications and Web sites. The Web pages are updated regularly to keep the material in the textbook current and include a facility for feedback to the author and the publisher.
  • The book is replete with case studies and examples from the literature. Many of the one-page case studies shown as sidebars in the book are expanded on the Web page. The student can see how the book's theoretical concepts are applied to real-life situations.
  • Each chapter ends with thought-provoking questions about legal and ethical issues in software engineering. Students see software engineering in its social and political contexts. As with other sciences, software engineering decisions must be viewed in terms of the people their consequences will affect.
  • Every chapter addresses both procedural and object-oriented development. In addition, a new chapter on object-oriented development explains the steps of an object-oriented development process. Using UML for common notation, each step is applied to a common example, from requirements specification through program design.
  • The book has an annotated bibliography that points to many of the seminal papers in software engineering. In addition, the Web page points to annotated bibliographies and discussion groups for specialized areas, such as software reliability, fault tolerance, computer security, and more.
  • The book has a solutions manual, available from Prentice Hall, as are PowerPoint slides with the figures, tables, and sample instructional slides.
  • Each chapter includes a description of a term project, involving development of software for a mortgage processing system. The instructor may use this term project, or a variation of it, in class assignments.
  • Each chapter ends with a list of key references for the concepts in the chapter, enabling students to find in-depth information about particular tools and methods discussed in the chapter.

CONTENTS AND ORGANIZATION

This text is organized in three parts. The first part (Chapters 1 to 3) motivates the reader, explaining why knowledge of software engineering is important to practitioners and researchers alike. Part I also discusses the need for understanding process issues and for doing careful project planning. Part II (Chapters 4 to 11) walks through the major steps of development and maintenance, regardless of the process model used to build the software: eliciting and checking the requirements, designing a solution to the problem, writing and testing the code, and turning it over to the customer. Part III (Chapters 12 to 14) focuses on evaluation and improvement. It looks at how we can assess the quality of our processes and products, and how to take steps to improve them.

Chapter 1: Why Software Engineering?

In this chapter we address our track record, motivating the reader and highlighting where in later chapters certain key issues are examined. In particular, we look at Wasserman's key factors that help define software engineering: abstraction, analysis and design methods and notations, modularity and architecture, software life cycle and press, reuse, measurement, tools and integrated environments, and user interface and prototyping. We discuss the difference between computer science and software engineering, explaining some of the major types of problems that can be encountered, and laying the groundwork for the rest of the book. We also explore the need to take a systems approach to building software, and we introduce the two common examples that will be used in every chapter. We also introduce the context for the term project.

Chapter 2: Modeling the Process and Life Cycle

In this chapter, we present an overview of different types of process and life-cycle models, including the waterfall model, the V -model, the spiral model, and various prototyping models. We also describe several modeling techniques and tools, including systems dynamics, SADT, and other commonly-used approaches. Each of the two common examples is modeled in part with some of the techniques introduced here.

Chapter 3: Planning and Managing the Project

Here, we look at project planning and scheduling. We introduce notions such as activities and milestones, work breakdown structure, activity graphs, risk management, and costs and cost estimation. Estimation models are used to estimate the cost and schedule of the two common examples. We focus on actual case studies, including management of software development for the F-16 airplane and for Digital's alpha AXP programs.

Chapter 4: Capturing the Requirements

In this chapter, we look at requirements analysis and specification. We explain the difference between functional and nonfunctional requirements, present several ways to describe different kinds of requirements, and discuss how to prototype requirements. We see how several types of formal methods can be used in specifying and evaluating requirements. Other topics discussed include requirements documentation, requirements reviews, requirements quality and how to measure it, requirements testability, and how to select a specification method. The chapter ends with application of some of the methods to the two common examples.

Chapter 5: Designing the System

This chapter focuses on architectural issues, and we begin by discussing Shaw and Garlan's framework for software architecture. Next, we describe the difference between the conceptual design and the technical design. We discuss the roles of the personnel who perform the design and describe two basic approaches to design: composition and decomposition. Then, we identify characteristics of good design, introduce several design strategies, and give examples of several system design techniques and tools. It is in this chapter that the reader learns about client-server architecture, reusable design components, human-computer interface design, design for secure and reliable systems (including error handling and fault tolerance), design patterns, formal design methods, and how to assess design trade-offs. After explaining how to evaluate and validate the quality of a design, and how to document the results, we turn to issues of program design.

Program design guidelines are explained, including top-down versus bottom-up, modularity and independence, and the difference between logical and physical design. We look at design for concurrency and for safety-critical systems, and we examine the design flaws that led to the Therac-25 malfunctions. We describe several design tools, and there is a thorough discussion of design quality and how to measure it. The chapter introduces design reuse, reviews, and inspections and explains the need to document design rationale. Finally, the chapter ends with examples of design for the information system and real-time examples.

Chapter 6: Concerning Objects

Chapter 6 takes a detour to consider the special properties of object-oriented development. We begin by describing use case scenarios, discussing how to capture objects and their characteristics from the natural language requirements. Next, we examine system design, to see how to generate the high-level information needed to find a solution. We then enrich the system design, adding nonfunctional requirements and details required in the program design. Employing UML and its constructs, we generate an object-oriented specification and design for a common example, the Royal Service Station.

Taking a careful look at object-oriented measurement, we apply some of the common object-oriented metrics to the service station example. We note how to use changes in the metrics to help us decide how to allocate resources and search for faults. Finally, we apply object-oriented concepts to our information systems and real-time examples.

Chapter 7: Writing the Programs

In this chapter, we address issues in implementing the design to produce high-quality code. We discuss standards and procedures and suggest some simple programming guidelines. Examples are provided in a variety of languages, including both object-oriented and procedural. There are thorough discussions of the need for program documentation and an error-handling strategy, and the chapter ends by applying some of the concepts to the two common examples.

Chapter 8: Testing the Programs

In this chapter, we explore several aspects of testing programs. We distinguish conventional testing approaches from the cleanroom method, and we look at how to test a variety of systems. We present definitions and categories of software problems, and we discuss how orthogonal defect classification can make data collection and analysis more effective. We then explain the difference between unit testing and integration testing. Aler introducing several automated test tools and techniques, we explain the need for a testing life cycle and how the tools can be integrated into it. Finally, the chapter applies these concepts to the two common examples.

Chapter 9: Testing the System

We begin with principles of system testing, including reuse of test suites and data, and the need for careful configuration management. Concepts introduced include function testing, performance testing, acceptance testing, and installation testing. We look at the special needs of testing object-oriented systems. Several test tools are described, and the roles of test team members are discussed. Next, we introduce the reader to software reliability modeling, and issues of reliability, maintainability, and availability are discussed. The reader learns how to use the results of testing to estimate the likely characteristics of the delivered product. The several types of test documentation are introduced, too, and the chapter ends by describing the test strategies of the two common examples.

Chapter 10: Delivering the System

This chapter discusses the need for training and documentation and presents several examples of training and documents that could accompany the information system and real-time examples.

Chapter 11: Maintaining the System

In this chapter, we address the results of system change. We explain how changes can occur during the system's life cycle, and how system design, code, test process, and documentation must accommodate them. Typical maintenance problems are discussed, as well as the need for careful configuration management. There is a thorough discussion of the use of measurement to predict likely changes, and to evaluate the effects of change. We look at reengineering and restructuring in the overall context of rejuvenating legacy systems. Finally, the two common examples are evaluated m terms of the likelihood of change.

Chapter 12: Evaluating Products, Processes, and Resources

Since many software engineering decisions involve the incorporation and integration of existing components, this chapter addresses ways to evaluate processes and products. It discusses the need for empirical evaluation and gives several examples to show how measurement can be used to establish a baseline for quality and productivity. We look at several quality models, how to evaluate systems for reusability, how to perform postmortems, and how to understand return on investment in information technology. These concepts are applied to the two common examples.

Chapter 13: Improving Predictions, Products, Processes, and Resources

This chapter builds on Chapter 11 by showing how prediction, product, process, and resource improvement can be accomplished. It contains several in-depth case studies to show how prediction models, inspection techniques, and other aspects of software engineering can be understood and improved using a variety of investigative techniques. This chapter ends with a set of guidelines for evaluating current situations and identifying opportunities for improvement.

Chapter 14: The Future of Software Engineering

In this final chapter, we look at several open issues in software engineering. We revisit Wasserman's concepts to see how well we are doing as a discipline. In addition, we examine several issues in technology transfer and decision-making to determine if we do a good job at moving important ideas from research to practice.

Read More Show Less

Table of Contents

Preface

1 Why Software Engineering?

1.1 What Is Software Engineering?

1.2 How Successful Have We Been?

1.3 What Is Good Software?

1.4 Who Does Software Engineering?

1.5 A Systems Approach

1.6 An Engineering Approach

1.7 Members of the Development Team

1.8 How Has Software Engineering Changed?

1.9 Information Systems Example

1.10 Real-Time Example

1.11 What this Chapter Means for You

1.12 What this Chapter Means for Your Development Team

1.13 What this Chapter Means for Researchers

1.14 Term Project

1.15 Key References

1.16 Exercises

2 Modeling the Process and Life Cycle

2.1 The Meaning of Process

2.2 Software Process Models

2.3 Tools and Techniques for Process Modeling

2.4 Practical Process Modeling

2.5 Information System Example

2.6 Real-Time Example

2.7 What this Chapter Means for You

2.8 What this Chapter Means for Your Development Team

2.9 What this Chapter Means for Researchers

2.10 Term Project

2.11 Key References

2.12 Exercises

3 Planning and Managing the Project

3.1 Tracking Progress

3.2 Project Personnel

3.3 Effort Estimation

3.4 Risk Management

3.5 The Project Plan

3.6 Process Models and Project Management

3.7 Information System Example

3.8 Real-Time Example

3.9 What this Chapter Means for You

3.10 What this Chapter Means for Your Development Team

3.11 What this Chapter Means for Researchers

3.12 Term Project

3.13 Key References

3.14 Exercises

4 Capturing the Requirements

4.1 The Requirements Process

4.2 Requirements Elicitation

4.3 Types of Requirements

4.4 Characteristics of Requirements

4.5 Modeling Notations

4.6 Requirements and Specification Languages

4.7 Prototyping Requirements

4.8 Requirements Documentation

4.9 Validation and Verification

4.10 Measuring Requirements

4.11 Choosing a Specification Technique

4.12 Information Systems Example

4.13 Real-Time Example

4.14 Term Project

4.15 Key References

4.16 Exercises

5 Designing the Architecture

5.1 The Design Process

5.2 Decomposition and Views

5.3 Modeling Architectures

5.4 Architectural Styles and Strategies

5.5 Achieving Quality Attributes

5.6 Collaborative Design

5.7 Architecture Evaluation and Refinement

5.8 Documenting Software Architectures

5.9 Architecture Design Review

5.10 Software Product Lines

5.11 Information System Example

5.12 Real-Time Example

5.13 What this Chapter Means for you

5.14 What this Chapter Means for Your Development Team

5.15 What this Chapter Means for Researchers

5.16 Term Project

5.17 Key References

5.18 Exercises

6 Designing the Modules

6.1 Design Methodology

6.2 Design Principles

6.3 Object-Oriented Design

6.4 Representing Object-Oriented Designs in the UML

6.5 Object-Oriented Design Patterns

6.6 Other Design Considerations

6.7 Object-Oriented Measurement

6.8 Design Documentation

6.9 Information Systems Example

6.10 Real-Time Example

6.11 What this Chapter Means for You

6.12 What this Chapter Means for your Development Team

6.13 What this Chapter Means for Researchers

6.14 Term Project

6.15 Key References

6.16 Exercises

7 Writing the Programs

7.1 Programming Standards and Procedures

7.2 Programming Guidelines

7.3 Documentation

7.4 The Programming Process

7.5 Information Systems Example

7.6 Real-Time Example

7.7 What this Chapter Means for You

7.8 What this Chapter Means for Your Development Team

7.9 What this Chapter Means for Researchers

7.10 Term Project

7.11 Key References

7.12 Exercises

8 Testing the Programs

8.1 Software Faults and Failures

8.2 Testing Issues

8.3 Unit Testing

8.4 Integration Testing

8.5 Testing Object-Oriented Systems

8.6 Test Planning

8.7 Automated Testing Tools

8.8 When to Stop Testing

8.9 Information Systems Example

8.10 Real-Time Example

8.11 What this Chapter Means for You

8.12 What this Chapter Means for Your Development Team

8.13 What this Chapter Means for Researchers

8.14 Term Project

8.15 Key References

8.16 Exercises

9 Testing the System

9.1 Principles of System Testing

9.2 Function Testing

9.3 Performance Testing

9.4 Reliability, Availability, and Maintainability

9.5 Acceptance Testing

9.6 Installation Testing

9.7 Automated System Testing

9.8 Test Documentation

9.9 Testing Safety-Critical Systems

9.10 Information Systems Example

9.11 Real-Time Example

9.12 What this Chapter Means for You

9.13 What this Chapter Means for Your Development Team

9.14 What this Chapter Means for Researchers

9.15 Term Project

9.16 Key References

9.17 Exercises

10 Delivering the System

10.1 Training

10.2 Documentation

10.3 Information Systems Example

10.4 Real-Time Example

10.5 What this Chapter Means for You

10.6 What this Chapter Means for your Development Team

10.7 What this Chapter Means for Researchers

10.8 Term Project

10.9 Key References

10.10 Exercises

11 Maintaining the System

11.1 The Changing System

11.2 The Nature of Maintenance

11.3 Maintenance Problems

11.4 Measuring Maintenance Characteristics

11.5 Maintenance Techniques and Tools

11.6 Software Rejuvenation

11.7 Information Systems Example

11.8 Real-Time Example

11.9 What this Chapter Means for You

11.10 What this Chapter Means for Your Development Team

11.11 What this Chapter Means for Researchers

11.12 Term Project

11.13 Key References

11.14 Exercises

12 Evaluating Products, Processes, and Resources

12.1 Approaches to Evaluation

12.2 Selecting an Evaluation Technique

12.3 Assessment vs. Prediction

12.4 Evaluating Products

12.5 Evaluating Processes

12.6 Evaluating Resources

12.7 Information Systems Example

12.8 Real-Time Example

12.9 What this Chapter Means for You

12.10 What this Chapter Means for Your Development Team

12.11 What this Chapter Means for Researchers

12.12 Term Project

12.13 Key References

12.14 Exercises

13 Improving Predictions, Products, Processes, and Resources

13.1 Improving Prediction

13.2 Improving Products

13.3 Improving Processes

13.4 Improving Resources

13.5 General Improvement Guidelines

13.6 Information Systems Example

13.7 Real-Time Example

13.8 What this Chapter Means For You

13.9 What this Chapter Means for your Development Team

13.10 What this Chapter Means for Researchers

13.11 Term Project

13.12 Key References

13.13 Exercises

14 The Future of Software Engineering

14.1 How Have We Done?

14.2 Technology Transfer

14.3 Decision-Making in Software Engineering

14.4 The Professionalization of Software Engineering: Licensing, Certification, and Ethics

14.5 Term Project

14.6 Key References

14.7 Exercises

Annotated Bibliography

Index

Read More Show Less

Preface

PREFACE:

Preface

BRIDGING THE GAP BETWEEN RESEARCH AND PRACTICE

Software engineering has come a long way since 1968, when the term was first used at a NATO conference. And software itself has entered our lives in ways that few had anticipated, even a decade ago. So a firm grounding in software engineering theory and practice is essential for understanding how to build good software and for evaluating the risks and opportunities that software presents in our everyday lives. This text represents the blending of the two current software engineering worlds: that of the practitioner, whose main focus is to build high-quality products that perform useful functions, and that the researcher, who strives to find ways to improve the quality of products and the productivity of those who build them.

Designed for an undergraduate software engineering curriculum, this book paints a pragmatic picture of software engineering research and practices. Examples speak to a student's limited experience but illustrate clearly how large software development projects progress from need to idea to reality.

The book is also suitable for a graduate course offering an introduction to software engineering concepts and practices, or for practitioners wishing to expand their knowledge of the subject. It includes examples that represent the many situations readers are likely to experience: large projects and small, object-oriented and procedural, real-time and transaction processing, development and maintenance. In particular, Chapters 12, 13, and 14 present thought-provoking material designed to interest graduate students in current research topics.

KEY FEATURES

This text has many key features that distinguish it from other books.

  • Unlike other software engineering books that consider measurement a separate issue, this book blends measurement with software engineering. Measurement issues are considered as an integral part of software engineering strategy, rather than as a separate discipline. This approach shows students how to involve quantitative assessment and improvement in their daily activities. They can evaluate their progress on an individual, team, and project basis.
  • Similarly, concepts such as reuse, risk management, and quality engineering are embedded in the software engineering activities that are affected by them, instead of treating them as separate issues.
  • Each chapter applies its concepts to two common examples: one that represents a typical information system, and another that represents a real-time system. Both examples are based on actual projects. The information system example describes the software needed to determine the price of advertising time for a large British television company. The real-time system is the control software for the Ariane-5 rocket; we look at the problems reported, and explore how software engineering techniques could have helped to locate and avoid some of them. Students can follow the progress of two typical projects, seeing how the various practices described in the book are merged into the technologies used to build systems.
  • At the end of every chapter, the results are expressed in three ways: what the content of the chapter means for development teams, what it means for individual developers, and what it means for researchers. The student can easily review the highlights of each chapter and see the chapter's relevance to both research and practice.
  • The book has an associated Web page, containing current examples from the literature, links to Web pages for relevant tool and method vendors, and a study guide for students. It is on the Web that students can find real requirements documents, designs, code, test plans, and more, so they can see real software engineering project artifacts. Students seeking additional in-depth information are pointed to reputable accessible publications and Web sites. The Web pages are updated regularly to keep the material in the textbook current and include a facility for feedback to the author and the publisher.
  • The book is replete with case studies and examples from the literature. Many of the one-page case studies shown as sidebars in the book are expanded on the Web page. The student can see how the book's theoretical concepts are applied to real-life situations.
  • Each chapter ends with thought-provoking questions about legal and ethical issues in software engineering. Students see software engineering in its social and political contexts. As with other sciences, software engineering decisions must be viewed in terms of the people their consequences will affect.
  • Every chapter addresses both procedural and object-oriented development. In addition, a new chapter on object-oriented development explains the steps of an object-oriented development process. Using UML for common notation, each step is applied to a common example, from requirements specification through program design.
  • The book has an annotated bibliography that points to many of the seminal papers in software engineering. In addition, the Web page points to annotated bibliographies and discussion groups for specialized areas, such as software reliability, fault tolerance, computer security, and more.
  • The book has a solutions manual, available from Prentice Hall, as are PowerPoint slides with the figures, tables, and sample instructional slides.
  • Each chapter includes a description of a term project, involving development of software for a mortgage processing system. The instructor may use this term project, or a variation of it, in class assignments.
  • Each chapter ends with a list of key references for the concepts in the chapter, enabling students to find in-depth information about particular tools and methods discussed in the chapter.

CONTENTS AND ORGANIZATION

This text is organized in three parts. The first part (Chapters 1 to 3) motivates the reader, explaining why knowledge of software engineering is important to practitioners and researchers alike. Part I also discusses the need for understanding process issues and for doing careful project planning. Part II (Chapters 4 to 11) walks through the major steps of development and maintenance, regardless of the process model used to build the software: eliciting and checking the requirements, designing a solution to the problem, writing and testing the code, and turning it over to the customer. Part III (Chapters 12 to 14) focuses on evaluation and improvement. It looks at how we can assess the quality of our processes and products, and how to take steps to improve them.

Chapter 1: Why Software Engineering?

In this chapter we address our track record, motivating the reader and highlighting where in later chapters certain key issues are examined. In particular, we look at Wasserman's key factors that help define software engineering: abstraction, analysis and design methods and notations, modularity and architecture, software life cycle and press, reuse, measurement, tools and integrated environments, and user interface and prototyping. We discuss the difference between computer science and software engineering, explaining some of the major types of problems that can be encountered, and laying the groundwork for the rest of the book. We also explore the need to take a systems approach to building software, and we introduce the two common examples that will be used in every chapter. We also introduce the context for the term project.

Chapter 2: Modeling the Process and Life Cycle

In this chapter, we present an overview of different types of process and life-cycle models, including the waterfall model, the V -model, the spiral model, and various prototyping models. We also describe several modeling techniques and tools, including systems dynamics, SADT, and other commonly-used approaches. Each of the two common examples is modeled in part with some of the techniques introduced here.

Chapter 3: Planning and Managing the Project

Here, we look at project planning and scheduling. We introduce notions such as activities and milestones, work breakdown structure, activity graphs, risk management, and costs and cost estimation. Estimation models are used to estimate the cost and schedule of the two common examples. We focus on actual case studies, including management of software development for the F-16 airplane and for Digital's alpha AXP programs.

Chapter 4: Capturing the Requirements

In this chapter, we look at requirements analysis and specification. We explain the difference between functional and nonfunctional requirements, present several ways to describe different kinds of requirements, and discuss how to prototype requirements. We see how several types of formal methods can be used in specifying and evaluating requirements. Other topics discussed include requirements documentation, requirements reviews, requirements quality and how to measure it, requirements testability, and how to select a specification method. The chapter ends with application of some of the methods to the two common examples.

Chapter 5: Designing the System

This chapter focuses on architectural issues, and we begin by discussing Shaw and Garlan's framework for software architecture. Next, we describe the difference between the conceptual design and the technical design. We discuss the roles of the personnel who perform the design and describe two basic approaches to design: composition and decomposition. Then, we identify characteristics of good design, introduce several design strategies, and give examples of several system design techniques and tools. It is in this chapter that the reader learns about client-server architecture, reusable design components, human-computer interface design, design for secure and reliable systems (including error handling and fault tolerance), design patterns, formal design methods, and how to assess design trade-offs. After explaining how to evaluate and validate the quality of a design, and how to document the results, we turn to issues of program design.

Program design guidelines are explained, including top-down versus bottom-up, modularity and independence, and the difference between logical and physical design. We look at design for concurrency and for safety-critical systems, and we examine the design flaws that led to the Therac-25 malfunctions. We describe several design tools, and there is a thorough discussion of design quality and how to measure it. The chapter introduces design reuse, reviews, and inspections and explains the need to document design rationale. Finally, the chapter ends with examples of design for the information system and real-time examples.

Chapter 6: Concerning Objects

Chapter 6 takes a detour to consider the special properties of object-oriented development. We begin by describing use case scenarios, discussing how to capture objects and their characteristics from the natural language requirements. Next, we examine system design, to see how to generate the high-level information needed to find a solution. We then enrich the system design, adding nonfunctional requirements and details required in the program design. Employing UML and its constructs, we generate an object-oriented specification and design for a common example, the Royal Service Station.

Taking a careful look at object-oriented measurement, we apply some of the common object-oriented metrics to the service station example. We note how to use changes in the metrics to help us decide how to allocate resources and search for faults. Finally, we apply object-oriented concepts to our information systems and real-time examples.

Chapter 7: Writing the Programs

In this chapter, we address issues in implementing the design to produce high-quality code. We discuss standards and procedures and suggest some simple programming guidelines. Examples are provided in a variety of languages, including both object-oriented and procedural. There are thorough discussions of the need for program documentation and an error-handling strategy, and the chapter ends by applying some of the concepts to the two common examples.

Chapter 8: Testing the Programs

In this chapter, we explore several aspects of testing programs. We distinguish conventional testing approaches from the cleanroom method, and we look at how to test a variety of systems. We present definitions and categories of software problems, and we discuss how orthogonal defect classification can make data collection and analysis more effective. We then explain the difference between unit testing and integration testing. Aler introducing several automated test tools and techniques, we explain the need for a testing life cycle and how the tools can be integrated into it. Finally, the chapter applies these concepts to the two common examples.

Chapter 9: Testing the System

We begin with principles of system testing, including reuse of test suites and data, and the need for careful configuration management. Concepts introduced include function testing, performance testing, acceptance testing, and installation testing. We look at the special needs of testing object-oriented systems. Several test tools are described, and the roles of test team members are discussed. Next, we introduce the reader to software reliability modeling, and issues of reliability, maintainability, and availability are discussed. The reader learns how to use the results of testing to estimate the likely characteristics of the delivered product. The several types of test documentation are introduced, too, and the chapter ends by describing the test strategies of the two common examples.

Chapter 10: Delivering the System

This chapter discusses the need for training and documentation and presents several examples of training and documents that could accompany the information system and real-time examples.

Chapter 11: Maintaining the System

In this chapter, we address the results of system change. We explain how changes can occur during the system's life cycle, and how system design, code, test process, and documentation must accommodate them. Typical maintenance problems are discussed, as well as the need for careful configuration management. There is a thorough discussion of the use of measurement to predict likely changes, and to evaluate the effects of change. We look at reengineering and restructuring in the overall context of rejuvenating legacy systems. Finally, the two common examples are evaluated m terms of the likelihood of change.

Chapter 12: Evaluating Products, Processes, and Resources

Since many software engineering decisions involve the incorporation and integration of existing components, this chapter addresses ways to evaluate processes and products. It discusses the need for empirical evaluation and gives several examples to show how measurement can be used to establish a baseline for quality and productivity. We look at several quality models, how to evaluate systems for reusability, how to perform postmortems, and how to understand return on investment in information technology. These concepts are applied to the two common examples.

Chapter 13: Improving Predictions, Products, Processes, and Resources

This chapter builds on Chapter 11 by showing how prediction, product, process, and resource improvement can be accomplished. It contains several in-depth case studies to show how prediction models, inspection techniques, and other aspects of software engineering can be understood and improved using a variety of investigative techniques. This chapter ends with a set of guidelines for evaluating current situations and identifying opportunities for improvement.

Chapter 14: The Future of Software Engineering

In this final chapter, we look at several open issues in software engineering. We revisit Wasserman's concepts to see how well we are doing as a discipline. In addition, we examine several issues in technology transfer and decision-making to determine if we do a good job at moving important ideas from research to practice.

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)