Đang tải... (xem toàn văn)
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.1 Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include the process of executing a program or application with the intent of finding software bugs (errors or other defects).
Software Engineering A PRACTITIONER’S APPROACH McGraw-Hill Series in Computer Science Senior Consulting Editor C L Liu, National Tsing Hua University Consulting Editor Allen B Tucker, Bowdoin College Fundamentals of Computing and Programming Computer Organization and Architecture Systems and Languages Theoretical Foundations Software Engineering and Databases Artificial Intelligence Networks, Parallel and Distributed Computing Graphics and Visualization The MIT Electrical and Computer Science Series Software Engineering and Databases Atzeni, Ceri, Paraborschi, and Torlone, Database Systems, 1/e Mitchell, Machine Learning, 1/e Musa, Iannino, and Okumoto, Software Reliability, 1/e Pressman, Software Engineering: A Beginner’s Guide, 1/e Pressman, Software Engineering: A Practioner’s Guide, 5/e Ramakrishnan/Gehrke, Database Management Systems, 2/e Schach, Classical and ObjectOriented Software Engineering with UML and C++, 4/e Schach, Classical and ObjectOriented Software Engineering with UML and Java, 1/e Software Engineering A PRACTITIONER’S APPROACH FIFTH EDITION Roger S Pressman, Ph.D Boston Burr Ridge, IL Dubuque, IA Madison, WI New York San Francisco St Louis Bangkok Bogotá Caracas Lisbon London Madrid Mexico City Milan New Delhi Seoul Singapore Sydney Taipei Toronto McGraw-Hill Higher Education A Division of The McGraw-Hill Companies SOFTWARE ENGINEERING Published by McGraw-Hill, an imprint of The McGraw-Hill Companies, Inc 1221 Avenue of the Americas, New York, NY, 10020 Copyright/2001, 1997, 1992, 1987, 1982, by The McGraw-Hill Companies, Inc All rights reserved No part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written consent of The McGraw-Hill Companies, Inc., including, but not limited to, in any network or other electronic storage or transmission, or broadcast for distance learning This book is printed on acid-free paper DOC/DOC ISBN 0073655783 Publisher: Thomas Casson Executive editor: Betsy Jones Developmental editor: Emily Gray Marketing manager: John Wannemacher Project manager: Karen J Nelson Production supervisor: Heather Burbridge Coordinator freelance design: Keith McPherson Supplement coordinator: Rose Range New media: Christopher Styles Cover design: Rhiannon Erwin Cover illustrator: Joseph Gilians Compositor: Carlisle Communications, Ltd Typeface: 8.5/13.5 Leawood Printer: R R Donnelley & Sons Company Library of Congress Cataloging-in-Publication Data Pressman, Roger S Software engineering: a practitioner’s approach / Roger S Pressman.—5th ed p cm.— (McGraw-Hill series in computer science) Includes index ISBN 0-07-365578-3 Software engineering I Title II Series QA76.758.P75 2001 005.1—dc21 00-036133 http://www.mhhe.com To my parents ABOUT THE AUTHOR R oger S Pressman is an internationally recognized authority in software process improvement and software engineering technologies For over three decades, he has worked as a software engineer, a manager, a professor, an author, and a consultant, focusing on software engineering issues As an industry practitioner and manager, Dr Pressman worked on the development of CAD/CAM systems for advanced engineering and manufacturing applications He has also held positions with responsibility for scientific and systems programming After receiving a Ph.D in engineering from the University of Connecticut, Dr Pressman moved to academia where he became Bullard Associate Professor of Computer Engineering at the University of Bridgeport and director of the university's Computer-Aided Design and Manufacturing Center Dr Pressman is currently president of R.S Pressman & Associates, Inc., a consulting firm specializing in software engineering methods and training He serves as principle consultant, helping companies establish effective software engineering practices He also designed and developed the company’s software engineering training and process improvement products—Essential Software Engineering, a complete video curriculum that is among the industry's most comprehensive treatments of the subject, and Process Advisor, a selfdirected system for software engineering process improvement Both products are used by hundreds of companies worldwide Dr Pressman has written many technical papers, is a regular contributor to industry periodicals, and is author of six books In addition to Software Engineering: A Practitioner's Approach, he has written A Manager's Guide to Software Engineering (McGraw-Hill), an award-winning book that uses a unique Q&A format to present management guidelines for instituting and understanding software engineering technology; Making Software Engineering Happen (Prentice-Hall), the first book to address the critical management problems associated with software process improvement; and Software Shock (Dorset House), a treatment that focuses on software and its impact on business and society Dr Pressman is on the Editorial Boards of IEEE Software and the Cutter IT Journal, and for many years, was editor of the “Manager” column in IEEE Software Dr Pressman is a well-known speaker, keynoting a number of major industry conferences He has presented tutorials at the International Conference on Software Engineering and at many other industry meetings He is a member of the ACM, IEEE, and Tau Beta Pi, Phi Kappa Phi, Eta Kappa Nu, and Pi Tau Sigma vi C O N T E N T S AT A G L A N C E Preface PA R T O N E PA R T T W O PA R T T H R E E PA R T F O U R xxv The Product and the Process CHAPTER The Product CHAPTER The Process 19 Managing Software Projects 53 CHAPTER Project Management Concepts CHAPTER Software Process and Project Metrics CHAPTER Software Project Planning CHAPTER Risk Analysis and Management CHAPTER Project Scheduling and Tracking CHAPTER Software Quality Assurance CHAPTER Software Configuration Management 55 79 113 145 165 193 225 Conventional Methods for Software Engineering CHAPTER 10 System Engineering CHAPTER 11 Analysis Concepts and Principles CHAPTER 12 Analysis Modeling CHAPTER 13 Design Concepts and Principles CHAPTER 14 Architectural Design CHAPTER 15 User Interface Design CHAPTER 16 Component-Level Design CHAPTER 17 Software Testing Techniques CHAPTER 18 Software Testing Strategies CHAPTER 19 Technical Metrics for Software 243 245 271 299 335 365 401 423 437 477 507 Object-Oriented Software Engineering CHAPTER 20 Object-Oriented Concepts and Principles CHAPTER 21 Object-Oriented Analysis CHAPTER 22 Object-Oriented Design 539 541 571 603 vii viii PA R T F I V E C O N T E N T S AT A G L A N C E CHAPTER 23 Object-Oriented Testing CHAPTER 24 Technical Metrics for Object-Oriented Systems 631 Advanced Topics in Software Engineering CHAPTER 25 Formal Methods CHAPTER 26 Cleanroom Software Engineering CHAPTER 27 Component-Based Software Engineering CHAPTER 28 Client/Server Software Engineering CHAPTER 29 Web Engineering CHAPTER 30 Reengineering CHAPTER 31 Computer-Aided Software Engineering CHAPTER 32 The Road Ahead 673 699 721 747 769 799 845 825 653 671 TA B L E O F C O N T E N T S PA R T O N E — T H E P R O D U C T A N D T H E P R O C E S S CHAPTER THE PRODUCT 1.1 1.2 The Evolving Role of Software Software 1.2.1 Software Characteristics 1.2.2 Software Applications 1.3 Software: A Crisis on the Horizon? 11 1.4 Software Myths 12 1.5 Summary 15 REFERENCES 15 PROBLEMS AND POINTS TO PONDER 16 FURTHER READINGS AND INFORMATION SOURCES CHAPTER THE PROCESS 17 19 2.1 Software Engineering: A Layered Technology 20 2.1.1 Process, Methods, and Tools 20 2.1.2 A Generic View of Software Engineering 21 2.2 The Software Process 23 2.3 Software Process Models 26 2.4 The Linear Sequential Model 28 2.5 The Prototyping Model 30 2.6 The RAD Model 32 2.7 Evolutionary Software Process Models 34 2.7.1 The Incremental Model 35 2.7.2 The Spiral Model 36 2.7.3 The WINWIN Spiral Model 38 2.7.4 The Concurrent Development Model 40 2.8 Component-Based Development 42 2.9 The Formal Methods Model 43 2.10 Fourth Generation Techniques 44 2.11 Process Technology 46 2.12 Product and Process 46 2.13 Summary 47 REFERENCES 47 PROBLEMS AND POINTS TO PONDER 49 FURTHER READINGS AND INFORMATION SOURCES 50 ix x CONTENTS PA R T T W O — M A N A G I N G S O F T WA R E P R O J E C T S CHAPTER 53 PROJECT MANAGEMENT CONCEPTS 55 3.1 The Management Spectrum 56 3.1.1 The People 56 3.1.2 The Product 57 3.1.2 The Process 57 3.1.3 The Project 57 3.2 People 58 3.2.1 The Players 58 3.2.2 Team Leaders 59 3.2.3 The Software Team 60 3.2.4 Coordination and Communication Issues 65 3.3 The Product 67 3.3.1 Software Scope 67 3.3.2 Problem Decomposition 67 3.4 The Process 68 3.4.1 Melding the Product and the Process 69 3.4.2 Process Decomposition 70 3.5 The Project 71 3.6 The W5HH Principle 73 3.7 Critical Practices 74 3.8 Summary 74 REFERENCES 75 PROBLEMS AND POINTS TO PONDER 76 FURTHER READINGS AND INFORMATION SOURCES 77 CHAPTER S O F T WA R E P R O C E S S A N D P R O J E C T M E T R I C S 4.1 4.2 79 Measures, Metrics, and Indicators 80 Metrics in the Process and Project Domains 81 4.2.1 Process Metrics and Software Process Improvement 82 4.2.2 Project Metrics 86 4.3 Software Measurement 87 4.3.1 Size-Oriented Metrics 88 4.3.2 Function-Oriented Metrics 89 4.3.3 Extended Function Point Metrics 91 4.4 Reconciling Different Metrics Approaches 94 4.5 Metrics for Software Quality 95 4.5.1 An Overview of Factors That Affect Quality 95 4.5.2 Measuring Quality 96 4.5.3 Defect Removal Efficiency 98 4.6 Integrating Metrics Within the Software Engineering Process 98 4.6.1 Arguments for Software Metrics 99 4.6.2 Establishing a Baseline 100 4.6.3 Metrics Collection, Computation, and Evaluation 100 4.7 Managing Variation: Statistical Quality Control 100 4.8 Metrics for Small Organizations 104 4.9 Establishing a Software Metrics Program 105 4.10 Summary 107 REFERENCES 107 846 PA R T F I V E QUICK LOOK A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G How I ensure that I’ve done it (with the exception, thankfully, of predictions of right? Predicting the road ahead the end of the world) We look for trends and try is an art, not a science In fact, it’s to extrapolate them ahead in time We can assess quite rare when a serious prediction about the the correctness of the extrapolation only as time future is absolutely right or unequivocally wrong passes is made to adopt a new method (or a new tool), conduct the training necessary to understand its application, and introduce the technology into the software development culture, something newer (and even better) has come along, and the process begins anew In this chapter, we examine the road ahead Our intent is not to explore every area of research the holds promise Nor is it to gaze into a "crystal ball" and prognosticate about the future Rather, we explore the scope of change and the way in which change itself will affect the software engineering process in the years ahead 32.1 T H E I M P O R TA N C E O F S O F T WA R E — R E V I S I T E D The importance of computer software can be stated in many ways In Chapter 1, software was characterized as a differentiator The function delivered by software differentiates products, systems, and services and provides competitive advantage in the marketplace But software is more that a differentiator The programs, documents, and data that are software help to generate the most important commodity that any individual, business, or government can acquire—information Pressman and Herron [PRE91] describe software in the following way: Computer software is one of only a few key technologies that will have a significant impact on nearly every aspect of modern society It is a mechanism for automating business, industry, and government, a medium for transferring new technology, a method of capturing valuable expertise for use by others, a means for differentiating one company's products from its competitors, and a window into a corporation's collective knowledge Software is pivotal to nearly every aspect of business But in many ways, software is also a hidden technology We encounter software (often without realizing it) when we travel to work, make any retail purchase, stop at the bank, make a phone call, visit the doctor, or perform any of the hundreds of day-to-day activities that reflect modern life Software is pervasive, and yet, many people in positions of responsibility have little or no real understanding of what it really is, how it's built, or what it means to the institutions that they (and it) control More importantly, they have little appreciation of the dangers and opportunities that software offers The pervasiveness of software leads us to a simple conclusion: Whenever a technology has a broad impact—an impact that can save lives or endanger them, build CHAPTER 32 THE ROAD AHEAD 847 businesses or destroy them, inform government leaders or mislead them—it must be "handled with care." 32.2 THE SCOPE OF CHANGE The changes in computing over the past 50 years have been driven by advances in the "hard sciences"—physics, chemistry, materials science, engineering During the next few decades, revolutionary advances in computing may well be driven by "soft sciences"—human psychology, biology, neurophysiology, sociology, philosophy, and others The gestation period for the computing technologies that may be derived from “The best thing about the future is that it comes one day at a time.” Abraham Lincoln these disciplines is very difficult to predict The influence of the soft sciences may help mold the direction of computing research in the hard sciences For example, the design of "future computers" may be guided more by an understanding of brain physiology than an understanding of conventional microelectronics The changes that will affect software engineering over the next decade will be influenced from four simultaneous sources: (1) the people who the work, (2) the process that they apply, (3) the nature of information, and (4) the underlying computing technology In the sections that follow, each of these components—people, the process, information, and the technology—is examined in more detail 32.3 P E O P L E A N D T H E WAY T H E Y B U I L D S Y S T E M S The software required for high-technology systems becomes more and more complex with each passing year, and the size of resultant programs increases proportionally The rapid growth in the size of the "average" program would present us with few problems if it wasn't for one simple fact: As program size increases, the number of people who must work on the program must also increase Experience indicates that, as the number of people on a software project team increases, the overall productivity of the group may suffer One way around this problem is to create a number of software engineering teams, thereby compartmentalizing people into individual working groups However, as the number of software engineering teams grows, communication between them becomes as difficult and time consuming as communication between individuals Worse, communication (between individuals or teams) tends to be inefficient—that is, too much time is spent transferring too little information content, and all too often, important information "falls into the cracks." If the software engineering community is to deal effectively with the communication dilemma, the road ahead for software engineers must include radical changes in the way individuals and teams communicate with one another E-mail, bulletin boards, and centralized video conferencing are now commonplace as mechanisms for connecting a large number of people to an information network The importance 848 PA R T F I V E A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G of these tools in the context of software engineering work cannot be overemphasized With an effective electronic mail or bulletin board system, the problem encountered by a software engineer in New York City may be solved with the help of a colleague in Tokyo In a very real sense, bulletin boards and specialized newsgroups become knowledge repositories that allow the collective wisdom of a large group of technologists to be brought to bear on a technical problem or management issue Video personalizes the communication At its best, it enables colleagues at different locations (or on different continents) to “meet” on a regular basis But video also provides another benefit It can be used as a repository for knowledge about the “Future shock [is] the shattering stress and disorientation that we induce in individuals by subjecting them to too much change in too short a time.” Alvin Toffler software and to train newcomers on a project The evolution of intelligent agents will also change the work patterns of a software engineer by dramatically extending the capabilities of software tools Intelligent agents will enhance the engineer's ability by cross-checking engineering work products using domain-specific knowledge, performing clerical tasks, doing directed research, and coordinating human-to-human communication Finally, the acquisition of knowledge is changing in profound ways On the Internet, a software engineer can subscribe to newsgroups that focus on technology areas of immediate concern A question posted within a newsgroup precipitates answers from other interested parties around the globe The World Wide Web provides a software engineer with the world’s largest library of research papers and reports, tutorials, commentary, and references in software engineering.1 If past history is any indication, it is fair to say that people themselves will not change However, the ways in which they communicate, the environment in which they work, the way in which they acquire knowledge, the methods and tools that they use, the discipline that they apply, and therefore, the overall culture for software development will change in significant and even profound ways 32.4 T H E " N E W " S O F T WA R E E N G I N E E R I N G P R O C E S S It is reasonable to characterize the first two decades of software engineering practice as the era of "linear thinking." Fostered by the classic life cycle model, software engineering was approached as a linear activity in which a series of sequential steps could be applied in an effort to solve complex problems Yet, linear approaches to software development run counter to the way in which most systems are actually built In reality, complex systems evolve iteratively, even incrementally It is for this reason that a large segment of the software engineering community is moving toward evolutionary models for software development Evolutionary process models recognize that uncertainty dominates most projects, that timelines are often impossibly short, and that iteration provides the ability to The SEPA Web site can provide you with electronic links to most important subjects presented in this book CHAPTER 32 THE ROAD AHEAD 849 deliver a partial solution, even when a complete product is not possible within the time allotted Evolutionary models emphasize the need for incremental work products, risk analysis, planning and then plan revision, and customer feedback What activities must populate the evolutionary process? Over the past decade, the Capability Maturity Model developed by the Software Engineering Institute [PAU93] has had a substantial impact on efforts to improve software engineering practices The CMM has generated much debate (e.g., [BOL91], [GIL96]), and yet, it provides a good indicator of the attributes that must exist when solid software engineering is practiced Object technologies, coupled with component-based software engineering (Chapter 27), are a natural outgrowth of the trend toward evolutionary process models “The best preparation for good work tomorrow is to good work today.” Elbert Hubbard Both will have a profound impact on software development productivity and product quality Component reuse provides immediate and compelling benefits When reuse is coupled with CASE tools for application prototyping, program increments can be built far more rapidly than through the use of conventional approaches Prototyping draws the customer into the process Therefore, it is likely that customers and users will become much more involved in the development of software This, in turn, may lead to higher end-user satisfaction and better software quality overall The rapid growth in Web-based applications (WebApps) is changing both the software engineering process and its participants Again, we encounter an incremental, evolutionary paradigm But in the case of WebApps, immediacy, security, and aesthetics become dominant concerns A Web engineering team melds technologists with content specialists (e.g., artists, musicians, videographers) to build an information source for a community of users that is both large and unpredictable The software that has grown out of Web engineering work has already resulted in radical economic and cultural change Although the basic concepts and principles discussed in this book are applicable, the software engineering process must adapt to accommodate the Web 32.5 N E W M O D E S F O R R E P R E S E N T I N G I N F O R M AT I O N Over the past two decades, a subtle transition has occurred in the terminology that is used to describe software development work performed for the business community Thirty years ago, the term data processing was the operative phrase for describing the use of computers in a business context Today, data processing has given way to another phrase—information technology—that implies the same thing but presents a subtle shift in focus The emphasis is not merely to process large quantities of data but rather to extract meaningful information from this data Obviously, this was always the intent, but the shift in terminology reflects a far more important shift in management philosophy When software applications are discussed today, the words data and information occur repeatedly We encounter the word knowledge in some artificial intelligence 850 F I G U R E 32.1 An “information” spectrum PA R T F I V E A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G Data: no associativity Information: associativity within one context Knowledge: associativity within multiple contexts Wisdom: creation of generalized principles based on existing knowledge from different sources applications, but its use is relatively rare Virtually no one discusses wisdom in the context of computer software applications Data is raw information—collections of facts that must be processed to be meaningful Information is derived by associating facts within a given context Knowledge associates information obtained in one context with other information obtained in a different context Finally, wisdom occurs when generalized principles are derived from disparate knowledge Each of these four views of "information" is represented schematically in Figure 32.1 “Wisdom is the power that enables us to use knowledge for the benefit of ourselves and others.” edge The key is our ability to associate information from a variety of different sources Thomas J Watson that may not have any obvious connection and combine it in a way that provides us To date, the vast majority of all software has been built to process data or information Software engineers are now equally concerned with systems that process knowledge.2 Knowledge is two-dimensional Information collected on a variety of related and unrelated topics is connected to form a body of fact that we call knowl- with some distinct benefit To illustrate the progression from data to knowledge, consider census data indicating that the birthrate in 1996 in the United States was 4.9 million This number represents a data value Relating this piece of data with birthrates for the preceding 40 years, we can derive a useful piece of information—aging "baby boomers" of the 1950s and early 1960s made a last gasp effort to have children prior to the end of their child-bearing years In addition “gen-Xers” have begun their childbearing years The census data can then be connected to other seemingly unrelated pieces of information For example, the current number of elementary school teachers who will retire during the next decade, the number of college students graduating with degrees The rapid growth in data mining and data warehousing technologies reflects this growing trend CHAPTER 32 THE ROAD AHEAD 851 in primary and secondary education, the pressure on politicians to hold down taxes and therefore limit pay increases for teachers All of these pieces of information can be combined to formulate a representation of knowledge—there will be significant pressure on the education system in the United States in the first decade of the twenty-first century and this pressure will continue for over a decade Using this knowledge, a business opportunity may emerge There may be significant opportunity to develop new modes of learning that are more effective and less costly than current approaches The road ahead for software leads toward systems that process knowledge We have been processing data for 50 years and extracting information for almost three decades One of the most significant challenges facing the software engineering community is to build systems that take the next step along the spectrum—systems that extract knowledge from data and information in a way that is practical and beneficial 32.6 TECHNOLOGY AS A DRIVER The people who build and use software, the software engineering process that is applied, and the information that is produced are all affected by advances in hardware and software technology Historically, hardware has served as the technology driver in computing A new hardware technology provides potential Software builders then react to customer demands in an attempt to tap the potential The road ahead for hardware technology is likely to progress along two parallel “The new electronic independence recreates the world in the image of a global village.” Marshall McLuhan paths Along one path, hardware technologies will continue to evolve at a rapid pace With greater capacity provided by traditional hardware architectures, the demands on software engineers will continue to grow But the real changes in hardware technology may occur along another path The development of nontraditional hardware architectures (e.g., massively parallel machines, optical processors, neural network machines) may cause radical changes in the kind of software that we build and fundamental changes in our approach to software engineering Since these nontraditional approaches are not yet mature, it is difficult to determine which will survive and even more difficult to predict how the world of software will change to accommodate them The road ahead for software engineering is driven by software technologies Reuse and component-based software engineering (technologies that are not yet mature) offer the best opportunity for order of magnitude improvements in system quality and time to market In fact, as time passes, the software business may begin to look very much like the hardware business of today There may be vendors that build discrete devices (reusable software components), other vendors that build system components (e.g., a set of tools for human/computer interaction) and system integrators that provide solutions (products and custom-built systems) for the end-user 852 PA R T F I V E A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G Software engineering will change—of that we can be certain But regardless of how radical the changes are, we can be assured that quality will never lose its importance and that effective analysis and design and competent testing will always have a place in the development of computer-based systems 32.7 A CONCLUDING COMMENT It has been 20 years since the first edition of this book was written I can still recall sitting at my desk as a young professor, writing the manuscript (by hand) for a book on a subject that few people cared about and even fewer really understood I remember the rejection letters from publishers, who argued (politely, but firmly) that there would never be a market for a book on “software engineering.” Luckily, McGraw-Hill decided to give it a try,3 and the rest, as they say, is history Over the past 20 years, this book has changed dramatically—in scope, in size, in style, and in content Like software engineering, it has grown and (I hope) matured over the years An engineering approach to the development of computer software is now conventional wisdom Although debate continues on the "right paradigm," the degree of automation, and the most effective methods, the underlying principles of software engineering are now accepted throughout the industry Why, then, are we seeing their broad adoption only recently? The answer, I think, lies in the difficulty of technology transition and the cultural change that accompanies it Even though most of us appreciate the need for an engineering discipline for software, we struggle against the inertia of past practice and face new application domains (and the developers who work in them) that appear ready to repeat the mistakes of the past To ease the transition we need many things—an adaptable and sensible software process, more effective methods, more powerful tools, better acceptance by practitioners and support from managers, and no small dose of education and "advertising." Software engineering has not had the benefit of massive advertising, but as time passes, the concept sells itself In a way, this book is an "advertisement" for the technology You may not agree with every approach described in this book Some of the techniques and opinions are controversial; others must be tuned to work well in different software development environments It is my sincere hope, however, that Software Engineering: A Practitioner's Approach has delineated the problems we face, demonstrated the strength of software engineering concepts, and provided a framework of methods and tools As we begin a new millennium, software has become the most important product and the most important industry on the world stage Its impact and importance Actually, credit should go to Peter Freeman and Eric Munson, who convinced McGraw-Hill it was worth a shot CHAPTER 32 THE ROAD AHEAD 853 have come a long, long way And yet, a new generation of software developers must meet many of the same challenges that faced earlier generations Let us hope that the people who meet the challenge—software engineers—will have the wisdom to develop systems that improve the human condition REFERENCES [BOL91] Bollinger, T and C McGowen, “A Critical Look at Software Capability Evaluations,” IEEE Software, July 1991, pp 25–41 [GIL96] Gilb, T., “What Is Level Six?” IEEE Software, January 1996, pp 97–98, 103 [HOP90] Hopper, M.D., "Rattling SABRE, New Ways to Compete on Information," Harvard Business Review, May–June 1990 [PAU93] Paulk, M., et al., Capability Maturity Model for Software, Software Engineering Institute, Carnegie Mellon University, 1993 [PRE91] Pressman, R.S., and S.R Herron, Software Shock, Dorset House, 1991 PROBLEMS AND POINTS TO PONDER 32.1 Get a copy of this week's major business and news magazines (e.g., Newsweek, Time, Business Week) List every article or news item that can be used to illustrate the importance of software 32.2 One of the hottest software application domains is Web-based systems and applications (Chapter 29) Discuss how people, communication, and process has to evolve to accommodate the development of “next generation” WebApps 32.3 Write a brief description of an ideal software engineer’s development environment circa 2010 Describe the elements of the environment (hardware, software, and communications technologies) and their impact on quality and time to market 32.4 Review the discussion of the evolutionary process models in Chapter Do some research and collect recent papers on the subject Summarize the strengths and weaknesses of evolutionary paradigms based on experiences outlined in the papers 32.5 Attempt to develop an example that begins with the collection of raw data and leads to acquisition of information, then knowledge, and finally, wisdom 32.6 Select a current “hot” technology (it need not be a software technology) that is being discussed in the popular media and describe how software enables its evolution and impact F U R T H E R R E A D I N G S A N D I N F O R M AT I O N S O U R C E S Books that discuss the road ahead for software and computing span a vast array of technical, scientific, economic, political, and social issues Robertson (The New 854 PA R T F I V E A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G Renaissance: Computers and the Next Level of Civilization, Oxford University Press, 1998) argues that the computer revolution may be the single most significant advance in the history of civilization Dertrouzos and Gates (What Will Be: How the New World of Information Will Change Our Lives, HarperBusiness, 1998) provide a thoughtful discussion of some of the directions that information technologies may take in the first few decades of this century Barnatt (Valueware: Technology, Humanity and Organization, Praeger Publishing, 1999) presents an intriguing discussion of an “ideas economy” and how economic value will be created as cyber-business evolves Negroponte's (Being Digital, Alfred A Knopf, 1995) was a best seller in the mid-1990s and continues to provide an interesting view of computing and its overall impact Kroker and Kroker (Digital Delirium, New World Perspectives, 1997) have edited a controversial collection of essays, poems, and humor that examines the impact of digital technologies on people and society Brin (The Transparent Society: Will Technology Force Us to Choose Between Privacy and Freedom? Perseus Books, 1999) revisits the continuing debate associated with the inevitable loss of personal privacy that accompanies the growth of information technologies Shenk (Data Smog: Surviving the Information Glut, HarperCollins, 1998) discusses the problems associated with an “information-infested society” that is suffocating from the volume of information that information technologies produce Miller, Michalski, and Stevens (21st Century Technologies: Promises and Perils of a Dynamic Future, Brookings Institution Press, 1999) have edited a collection of papers and essays on the impact of technology on social, business, and economic structures For those interested in technical issues, Luryi, Xu, and Zaslavsky (Future Trends in Microelectronics, Wiley, 1999) have edited a collection of papers on probable directions for computer hardware Hayzelden and Bigham (Software Agents for Future Communication Systems, Springer-Verlag, 1999) have edited a collection that discusses trends in the development of intelligent software agents Kurzweil (The Age of Spiritual Machines, When Computers Exceed Human Intelligence, Viking/Penguin Books, 1999) argues that, within 20 years, hardware technology will have the capacity to fully model the human brain Borgmann (Holding on to Reality: The Nature of Information at the Turn of the Millennium, University of Chicago Press, 1999) has written a intriguing history of information, tracing its role in the transformation of culture Devlin (InfoSense: Turning Information into Knowledge, W H Freeman & Co., 1999) tries to make sense of the constant flow of information that bombards us on a daily basis Gleick (Faster: The Acceleration of Just About Everything, Pantheon Books, 2000) discusses the ever-accelerating rate of technological change and its impact on every aspect of modern life Jonscher (The Evolution of Wired Life: From the Alphabet to the Soul-Catcher Chip—How Information Technologies Change Our World, Wiley, 2000) argues that human thought and interaction transcend the importance of technology A wide variety of information sources on future trends in computing is available on the Internet An up-to-date list of World Wide Web references can be found at the SEPA Web site: http://www.mhhe.com/engcs/compsci/pressman/resources/future.mhtml INDEX Abstraction, 342, 367, 406, 656 Abstraction level, 809 Acceptance tests, 496 Access control, 234 Action path, 380, 392 Activity network, 180 Actors, 280, 581 Adaptable process model, 174 Adaptation, 22, 174 Adaptive maintenance, 23, 805 Aggregate objects, 230, 625 Airlie council, 74 Alpha testing, 496 Analysis, 271, 286 methods, 330 model, 284, 299, 301, 734 principles, 282 for reuse, 734 tools, 830 of WebApps, 778 Anchor points, 39 Antibugging, 486 Application architecture, 253 Application categories, Application generation, 33 Application object, 760 Appraisal costs, 197 Architectural design, 336, 346, 365, 394 c/s systems, 756 metrics, 523, 532 model, 367 quantitative, 376 spectrum analysis, 377 WebApps, 780 Architectural framework, 43 Architectural styles, 371, 375 Architecture, 346, 366, 367, 525, 725 call and return, 372 complexity of, 378 data centered, 371 data-flow, 372 dependencies, 378 iteration, 394 layered, 373 mapping requirements into, 378 models, 346 object-oriented, 373, 613 organization and refinement, 374, 389 trade-off, 375 WebApps, 780 Architecture description language, 347 Associative data object, 308 Attributes, 304, 544, 547, 557, 660 Audit trails, 841 Availability measures, 212 Back-to-back testing, 466 Backtracking, 501 Bang metric, 520, 532 Baselines, 227 Basic objects, 230 Basis path testing, 445, 449 Basis set, 448, 450 Bathtub curve, Behavior model view, 285, 317, 576 Behavioral testing, 459 Beta testing, 496 Black-box, 705 testing, 443, 459 Booch method, 574, 608 Bottom-up integration, 490 Boundary value analysis (BVA), 465 Bounding, 115, 128 Box diagram, 426 Box structure, 701, 704 BPR, 245, 251, 800–802 hierarchy, 254 tools, 829 Branch testing, 455 Bubble, 310 Builds, 490, 492 Business area analysis, 253 Business, 802 modeling, 32 object, 758 process reengineering, see BPR processes, 800 Business system design (BSD), 253 Call and return architecture, 372, 385 Capability maturity model (CMM), 24 Capture/playback, 491, 764 Cardinality, 305, 320, 683 CASE, 12, 825 building blocks, 826 integrated environments, 833 integration, 827, 834 layers, 834 tools taxonomy, 828 CASE database, 835 CASE repository, 836, 837 special features, 839 Cause elimination, 501 Certification, 702, 714 Certification teams, 712 Change, 13, 22, 29, 225 Change control, 234–236 Change control authority (CCA), 234, 236 Change management, 840 Change request, 234 Chaos model, 28 Characterization functions, 727 Check in, 234 Check out, 234 Chief programmer team, 62 Chunking, 424 CK metrics suite, 658 Class collaboration, 646 Class connections, 591 Class diagram, 589 Class hierarchy, 551, 588 test cases for, 641 Class relationships, 587 Class-responsibilitycollaborator models, see CRC model Class size, 661 Class testing, 636 Classes, 544, 584, 753 generalization/ specialization, 588 identification of, 554 key, 563 metrics for, 658 representation of, 546 support, 563 testing, 636, 644 Classic life cycle, 28 Cleanroom, 43, 699–701 certification, 714 design, 706 design refinement, 707 design verification, 710 differentiating characteristics, 703 stepwise refinement, 708 testing teams, 712 verification, 707 Clear-box specification, 706 Client, 748 Client/server applications, 41 Client/server software, 748 analysis modeling, 755 configurations, 751 design, 755, 759 engineering, 747 testing, 761, 763, 832 Cluster, 490 Cluster testing, 637 Coad and Yourdon method, 574, 690 COCOMO II model, 133 Code generation, 29, 702 Code restructuring, 808 Cohesion, 324, 353, 526, 527, 657, 661 Collaborations, 587 Collaborator classes, 591 Collaborators, 583 COM, 733, 753, 773 Commercial off-the-shelf (COTS) components, 722 Common process framework (CPF), 23, 70 for OO, 560 Communication processes, 756 Comparison testing, 465 Compartmentalization, 169 Completeness, 809 Complexity, 657 Complexity metrics, 529 Component adaptation, 723, 731 Component-based assembly, Component-based development, 42, 730, 773 Component-based software engineering, 121, 721, 723 economics of, 739 process, 724 tools, 739 Component-based systems, 722 Component classification, 737 Component composition, 723, 732 Component engineering, 734 Component-level design, 337, 423 Component object model, see COM Component qualification, 723, 730, 731 Component retrieval system, 739 Component update, 723 Component wrapping, 731 Components, 126, 371 acquisition of, 122 classification of, 735, 737 c/s systems, 750 description of, 622, 724 design of, 623 distributed, 750 metrics for, 526 reusable, Composability, 607 Composite object, 231 Compositional relation, 229 Compound condition, 446, 454 Computer-aided software engineering, see CASE Concurrency, 613 Concurrent development model, 40 855 856 INDEX Concurrent engineering, 40 Concurrent process model, 40, 41 Concurrent tasks, 613 Condition testing, 454 Condition-transitionconsequence (CTC) format, 156 Configuration audit, 237 Configuration objects, 229 identification, 231 WebApps, 793 Configuration review, 496 Configuration status reporting, 237 Connection matrix, 453 Connections, 320 Construction and release, 36 Constructive set specification, 683 Content developer, 788 Context-free questions, 116, 274 Context model, 311 Contingency planning, 156 Continuity, 607 Control abstraction, 343 Control chart, 101, 102 Control couple, 761 Control flow, 314, 318, 528 Control flow diagram, 315 Control flow model, 324 Control hierarchy, 347 Control item, 328 Control modules, 348 Control objects, 284 Control process, 314 Control Specification (CSPEC), 302, 315, 325 Controllability, 441 CORBA, 733, 753, 773 Core product, 35 Correction, 22 Corrective maintenance, 805 Correctness, 96, 438, 509, 707 verification of, 702, 712 Cost, 740 Cost estimation, 74, 123 Cost performance index, 187 Cost risk, 150 Cost variance, 187 Coupling, 354, 526, 607, 657 metrics for, 528, 661, 663 CRC model, 582, 588, 634 index cards, 583, 635 metrics for, 660 Critical modules, 493 Critical path, 181 Critical path method (CPM), 181 Customer, 271 Customer communication, 36, 71 Customer evaluation, 37 Customer voice table, 280 Cyclomatic complexity, 446, 448, 449, 493, 529 Data, 850 Data abstraction, 342, 546, 368 Data architecture, 252 Data-centered architecture, 371 Data condition, 315 Data couple, 761 Data design, 336, 367, 369 Data dictionary, 301, 312, 328, 329, 370 Data exchange model, 732 Data flow, 379, 528 Data-flow architecture, 372 Data flow diagram, 31, 302, 315, 321, 379, 381, 518 Data flow model, 321, 462 Data flow testing, 456 Data invariant, 677, 681, 688 Data items, 310 Data management component, 615 Data mining, 368 Data model, 284, 305 Data modeling, 32, 302, 368 Data network, 302 Data object, 284, 303, 308, 310, 328, 342, 623 Data relationships, see Relationships Data restructuring, 808 Data structure, 349, 350, 368, 811 Data structured systems development (DSSD), 330 Data warehouse, 368, 369 Database, 247 Database design, c/s systems, 758 Database management, tools, 830 Database object, 760 Database structure, 812 Debugging, 499–502 Decision table, 428 Decision tree, 137 Decision tree analysis, 137 Decomposability, 441, 607 Decomposition, 67, 119, 124, 127 Defect amplification, 204 Defect removal efficiency, 98, 105, 187 Defect tracking, 74, 98, 188, 209, 445 cost of, 203 Deficiency list, 495 Definition phase, 22 Definition-use chain, 457 Degree of structural uncertainty, 114 Dependency tracking, 840 Depth, structure, 347 Design, 29, 335–339 component level, 423 principles of, 340 for reuse, 734 test cases, 443 tools, 830 Design concepts, 341 Design heuristics, 355 Design iteration, 386 Design mapping, 385, 386 Design model, 340, 357 Design notation, 432 graphical, 425 tabular, 427 text-based, 429 Design patterns, 371, 375, 605, 624, 625, 779, 783 Design process, 338 Design review, 395 Design selection index, 377 Design Specification, 228, 358, 386 Design structure quality index, 525 Detection device, 215, 216 Development environment, 120 Development phase, 22 Directionality, 809 Distributed subsystems, 752 Do-while, 425 Document restructuring, 807 Documentation, 14, 247, 830 Domain analysis, 576–578, 740 process, 726 Domain architecture, 740 Domain characteristics, 728 Domain engineering, 579, 725 Domain language, 726 Domain objects, 605 Domain testing, 455 Driver, 487, 490 Dynamic analysis, 832 Earned value analysis, 74, 186 Efficiency, 510, 513 Effort distribution, for software projects, 172 estimate, 123, 124 relationship, 171 Effort validation, 169 Elaboration, 67, 343 Empirical estimation, 124 Encapsulation, 548, 550, 655 Engineering, 36 Engineering change order (ECO), 234 Enhancement, 23, 805 Entity relation diagram (ERD), 301, 307, 319 Entry point multiplier, 176 Environment model view, 576 Equivalence class, 464 Equivalence partitioning, 463, 464 Error detection, 203 Error index, 210 Error messages, 414 Error tracking, 187 Errors, 98, 187 Essential view, 288 Estimates, 114, 115 accuracy of, 124 three-point, 125 Estimation, 123, 128, 131 decomposition techniques, 126 empirical, 124, 132 FP-based, 126, 129 LOC-based, 126, 128 object-oriented projects, 564 problem based, 126 process-based, 130 WebApps, 791 Estimation models, 132 Estimation risk, 114 Estimation table, 131 Estimation tools, 124, 139 Estimation variables, 127 Event flow, 314 Event trace model, 597 Events, rules for determining, 325 Evolution graph, 231 Evolutionary process model, 34, 37, 179 Expected cost, 138 Expected value, 125, 127 External entity, 263, 310, 554 External failure costs, 197 Facilitated application specification techniques (FAST), 117, 275–277, 289 consensus list, 278 Factoring, 349, 385–386 Failure, definition of, 212 Failure costs, 197 Failure curves, Failure intensity, 483 Failure mode analysis, 197 Fan-in, 347, 355, 524 Fan-out, 347, 355, 524 Fat client, 751 Fat server, 750 Fault, 203, 639 Fault-based testing, 639 Fault tree analysis, 214 Feasibility, 117 Feature points, 91 Finger-pointing, 497 Finite state modeling, 462 First law of system engineering, 226 Fishbone diagram, 85 Flexibility, 510 Flow boundaries, 383 Flow graphs, 445, 449 compound conditions, 446 nodes, 446 notation, 446 Flow model, 310 Flowchart, 425 Formal design, 702 Formal methods, 673–677 concerns about, 44 future directions, 694 mathematical notation, 687 mathematical preliminaries, 682 operations, 678, 681 state, 678 ten commandments of, 693 Formal methods model, 43 857 INDEX Formal specification language, 689 Formal technical review, 14, 64, 197, 205, 237, 484, see also Review OO models, 635 user interface, 417 Formulation, 776 Forward engineering, 808, 814 c/s systems, 816 object-oriented systems, 817 user interfaces, 818 Fourth generation techniques (4GT), 44–45, 290 40-20-40 rule, 172 Framework, 23 Framework activities, 69 Function deployment, 279 Function points, 89 complexity adjustment values, 91 computation of, 90, 519 estimation, 562 extended metrics, 91 pros and cons, 93 Function specification, 703 Functional decomposition, 68 Functional independence, 352 Functional model, 285, 309, 310 Functionality, 512, 513 Fundamental system model, 311, 379, 392 FURPS, 511 Gantt chart, 182 Glass-box testing, 444 Golden rules interface design, 402 WebApp design, 779 Grammatical parse, 322 Graph matrix, 452 Graph notation, 461 Graphs, symmetry of, 463 GUI, see Interface entries Hardware, 247 Hazard analysis, 159 Hazards, 213 Help facility, 413, 414 Hiding, 351 Horizontal decomposition, 287 HTML, 774 Human resources, 60 I-CASE, 836, see also CASE Identification, 237 If-then-else, 425 Implementation, 618 model view, 576 view, 288 Increment planning, 701 Incremental development, 168 Incremental model, 35 Independent path, 446 Independent test group (ITG), 480 Indexing methods, 736 Indexing vocabularies, 736 Information context, 284 Information deployment, 279 Information determinacy, Information domain, 90, 127, 283, 321 Information flow, 284, 309, 311 Information hiding, 351, 655 Information strategy planning (ISP), 253 Inheritance, 550, 656, 662 metrics for, 665 multiple, 551 Initial operational capability, 39 Input, 249 Inspections, 206, see also Formal technical review Instance, 544 Integrated CASE environment, 827, see also CASE Integration testing, 481, 488, 493 documentation, 494 OO software, 637, 640 strategies, 489 Integrity, 97, 510 Interaction modes, 403 Interdependency, 169 Interface actions, 408, 411 Interface constraints, 403 Interface description language, 753 Interface design, 337, 401, 408, see also User interface design activities, 410 tools, 831 WebApps, 785 Interface design model, 405 Interface objects, 401, 410, 760 Interfaces, 621, 530 Internet standards, 774 Interoperability, 510 Intersubsystem communication, 616 Inventory analysis, 806 ISO 9000 standard, 201, 216, 217 Jackson System Development (JSD), 330 Jacobson method, 574, 609 Javabean components, 733, 753, 773 Kaizen, 199 Key classes, 563 Key indicators, 26 Key practices, 26 Key process area (KPA), 21, 25 Knowledge, 850 Knowledge discovery, 368 Lateness, comment on, 167 Layered architecture, 373 Layering, 612, 613 Layout appropriateness, 530 Legacy programs, 23 Level of abstraction, 676 Life cycle architecture, 39 Life cycle objectives, 39 Linear sequential model, 28, 30, 34 Lines of code, (LOC), 88 Linguistic modular units, 607 Link weight, 452 Localization, 655 Logical constructs, 424 Loop constructs, 425 Loop testing, 458 Loops, types of, 458 Lower natural process limit, 102 Maintainability, 96, 510, 513 Maintenance, 805 metrics for, 533 request, 815 Make/buy decision, 136 Mean-time-to-change (MTTC), 97 Mean-time-between-failure (MTBF), 212 Measurement, 79, 80, 87, 507, 515 Measures, 80, 87 LOC and FP, 94 Messages, 548–549 protocol description, 619 Meta-questions, 275 Methods, 21, 545, see also Operations metrics for, 660 Metrics, 74, 80, 507, 516 analysis model, 517 architectural design, 523 collection of, 100 complexity, 524, 529 design model, 523 encapsulation, 664 error tracking, 188 framework for, 514 function oriented, 89, 518, 532 GUIs, 530 inheritance, 665 integration of, 98 maintenance, 533 OO projects, 665 OO software, 653 OOD, 658 OOT, 664 operations, 664 productivity, 126 reconciling, 94 reuse, 741 size-oriented, 88, 89 small organizations, 104 software components, 526 software metrics, 79 software quality, 95, 510 source code, 531 specification quality, 522 technical, 516 testing, 532 tools, 829 Metrics baseline, 100 Metrics computation, 100 Metrics evaluation, 100 Metrics guidelines, 105 Metrics variation, 100 Middleware, 753 Milestones, 57 OO projects, 565 Mini-specifications, 278 Modality, 306, 320 Modularity, 343, 352 effective, 345 guidelines, 355 Module interconnection language, 231 Module size, 345 Modules, 343 cost of, 344 complexity of, 344 subordinate, 348 superordinate, 348 MOOD metrics suite, 662 Morphology, 524 Multiple class testing, 645 Multiple instances, 313 Nassi-Shneiderman charts, 426 Navigation design, 783 Navigation nodes, 784 Negotiation, 38, 276 90-90 rule, 72 Object, 544–545, 703 generic life history, 559 selection criteria, 556 Object adapter, 754 Object-behavior model, 594, 613 Object definition, 559 Object descriptions, 618 Object design, 618 algorithms, 619 data structures, 619 Object life history, 581 Object management layer, 835 Object model, 553, 732 testing of, 636 Object modeling technique, 574, 608 Object-oriented (OO), 542, 544 contract, 565 estimation, 562, 564 milestones, 565 process model, 543 project management, 560 project metrics, 562 scheduling, 564 tracking projects, 565 Object-oriented architecture, 373 Object-oriented metrics, 653–654 Lorenz and Kidd, 661 MOOD suite, 662 Object-oriented paradigm, 542 Object-oriented programming (OOP), 625 Object-oriented projects, 560 Object-oriented software, 656 858 INDEX Object point, 134 Object pool, 233 Object-relationship model, 591, 593 testing of, 634 Object/relationship pairs, 320 Object request broker (ORB), 753 Observability, 441 OOA (object-oriented analysis), 571, 574 vs conventional approaches, 573 defining classes, 583 event identification, 594 partitioning, 612 relationships, 591 state-based models, 596 state representations, 595 tasks, 572 unified approach to, 575, 610 use-cases, 594 OOA model, 632–634 dynamic view, 580 generic components, 579 static view, 580 OOD (object-oriented design), 603 communication, 616 components of, 614 contracts, 616 vs conventional approaches, 605 data management, 611 design issues, 607 generic steps, 609 layers of, 604 mapping to OOA, 606 methods, 608 object design, 618 pyramid, 604 system design process, 611 OOD model, 632–634 OOT (object-oriented testing), 631, 638 behavior models, 647 deep structure, 643 impact of OOP, 640 interclass, 645 metrics for, 664 partition testing, 644 random testing, 644 state-based partitioning, 645 strategy, 636 surface structure, 643 thread-based, 637 Operability, 441 Operations, 545, 548, 558, 620, 623, see also Methods metrics for, 660, 664 testing issues, 636 Orthogonal array, 466 Outsourcing, 13, 138 Outsourcing vendors, 791 Overloading, 553 Overriding, 551 Package references, 592 Packages, 590 Pareto principle, 209, 440 Partition testing, 644–645 Partitioning, 67, 286, 612 horizontal, 287, 348 vertical, 288, 349 Pathological connection, 357 Pattern of usage, 762 Patterns, 371, 375, see also Design patterns People, 170, 247 communication issues, 65 roles of, 58 People/work relationships, 171 Perfective maintenance, 23 Performance, 512 Performance risk, 150 Performance testing, 498 Personal software process (PSP), 83 PERT, 181 Petri net models, 214 Phase index, 211 Planning, 36 Poka-yoke, 214 Polymorphism, 552 metrics for, 663 Portability, 510, 513 Portability services, 827 Postcondition, 678, 682 Postmortem analysis, 73 Precondition, 678, 682 Predicate, 683 Predicate node, 446 Presentation protocol, 834 Prevention device, 215, 216 Preventive maintenance, 23 Private process data, 83 PRO/SIM, tools, 831 Problem decomposition, 67 Problem solving, 59 Procedural abstraction, 342 Procedural design, 423 Procedures, 247 Process, 20, 46, 57, 310, see also Software process adaptation criteria, 174 evolutionary model, 179 generic phases, 68 object-oriented, 543 Process activation table, 315, 327 Process decomposition, 70 Process evaluation, for BPR, 803 Process identification, for BPR, 802 Process indicators, 82 Process layer, 21 Process maturity, 24 Process metrics, 82, 101 Process model, 26 CBSE, 725 interface design, 407 object-oriented, 543 selecting, 68 Process modeling, 33, 829 Process specification (PSPEC), 302, 312, 327–328 for BPR, 803 Process technology, 46 Processing narrative, 322, 557, 623 Producer, 206 Product, 46, 57, 67, see also Software Product engineering, 254255 Productivity, 740 Productivity metrics, 94, 126 Program components, 621 Program design language, 327, 429, 430, 622 Program graph, 445 Program structure, 385, 392, 351 terminology, 347 Programming, tools, 831 Progress, tracking of, 72 Project, 57, 71 avoiding problems, 72 constraints, 120 danger signs, 71 degree of rigor, 173 function, 119 performance, 120 reasons for failure, 65 Project coordination, 66 Project complexity, 114 Project database, 228 Project entry point, 37 Project indicators, 82 Project library, 228 Project management, 75 critical practices, 74 four Ps, 56 object-oriented, 560 tools, 829 WebE, 787, 789 Project metrics, 86–87 Project planning, 115 tools, 829 Project resources, 120–122 Project risks, 147, 149 Project scheduling, 165 Project size, 114 Project tables, 182 Project tracking, 165 Proof of correctness, 709 Protection, 607 Protocol description, 618 Protocols, 609 Prototype, 31, 289 Prototyping BPR, 803 environments, 291 evolutionary, 289 problems with, 32 tools, 290, 831 throwaway, 289 Prototyping methods, 290 Prototyping model, 30 Prototyping paradigm, 30, 289 Pseudocode, 429 Public metrics, 84 Quality, 195, 739 conformance, 195 cost of, 196, 197 design, 195 deviations, 202 quantitative view, 513 Quality assurance, 196, 200 tools, 830 Quality concepts, 194 Quality control, 194, 196 Quality costs, 197 Quality factors, 95, 341 ISO 9126, 513 McCall, 509 Quality filter, 14 Quality function development (QFD), 279, 289 Quality measurement, 96 Random testing, 644 Rapid application development (RAD), 32, 34 Real time logic, 214 Recorder, 206 Recovery testing, 497 Recursive/parallel model, 560–561 Reengineering, 799 economics of, 819 process model, 805 tools, 832 Referent point, 155 Refinement, 343 for BPR, 803 Regression testing, 491 Relationships, derivation of, 592 Reliability, 509, 512, 513 measures, 212 Repeat-until, 425 Repository, 836 Requirements, types of, 279 Requirements analysis, 258, 272 Requirements database, 261 Requirements elicitation, 256, 274, 280 steps, 257 work products, 257 Requirements engineering, 255, 256 guiding principles, 283 steps, 256 Requirements gathering, 701 interfaces, 402 Requirements management, 261 Requirements model, 556 Requirements negotiation, 259 Requirements review, 260 Requirements specification, 259 Requirements tracing, tools, 829, 841 Requirements validation, 260 Resource management component, 616 Responsibilities, 583 allocation of, 585 identifying, 584 859 INDEX Restructuring, 813 code, 814 data, 814 Reusability, 43, 510 Reusable components, 722, 736 categorization of, 726 identification of, 727 Reusable software components, 290 Reuse, 551, 577, 721, 734 cost, 740 environment, 738 leverage, 742 library, 739 metrics, 741 Reverse engineering, 807, 809 of data, 811 of processing, 810 of user interfaces, 812 Review, 206–208 see also Formal technical review issues list, 207 leader, 206 meeting, 206 reporting, 207 summary report, 207 Rework, 197 Risk analysis, 36, 145 tools, 829 Risk assessment, 154 Risk components and drivers, 148 Risk driver, 150 Risk estimation, 151 Risk exposure, 153 Risk identification, 148 Risk impact, 151 Risk information sheet, 159 Risk item checklist, 148 Risk management, 74, 157 strategies, 146 Risk mitigation, 156 Risk Mitigation, Monitoring, and Management Plan, 153, 159 Risk monitoring, 157 Risk planning, 153 Risk probability, 151 Risk projection, 151 Risk referent level, 154 Risk refinement, 156 Risk table, 151 Risks, 146, 148 business related, 147 hazards, 158 management concern, 152 safety, 158 technical, 147 Round robin reviews, 206 Rumbaugh method, 574, 608 SafeHome, 277, 281, 286, 320, 322, 325, 329, 380, 411, 518, 555, 581, 587, 594, 614, 619, 622, 713, 729, 777 Sandwich testing, 493 Scalability, of WebApps, 793 Scenario-based testing, 641 Scenario script, 563 Schedule estimation, 74 Schedule performance index, 187 Schedule risk, 150 Schedule variance, 187 Scheduling, 168, 181, 792 milestones, 170 object-oriented projects, 564 outcomes, 170 responsibilities, 169 tracking of, 185 Schemas, 690 SCM, 225, 230, 841 standards, 238 tools, 232 resources, 231 tools, 830 WebApps, 792 Scope, 57, 67, 68 Scope of control, 356 Scope of effect, 356 Screen layout, 411 Security, 97, 774 Security testing, 497 Semantic domain, 689 Semantic navigation unit (SMU), 784 Sensitivity testing, 498 Sequence construct, 425 Server, 748–749 Services, 545, see also Methods; Operations Sets, 683 logical operators, 686 operators, 684 sequences, 686 SGML, 774 Shared repository layer, 835 Simplicity, 441 Size, 656 Size-oriented metrics, for OO software, 661 Smoke testing, 492–493 Software, 6, deterioration of, history of, importance of, 846 impact of, project characteristics, 65 role of, scope of change, 847 Software architecture, 346, 366, 725, see also Architecture Software components, 8, 42, 120, 367, see also Components user interface, 415 Software configuation, 14, 226 items, 226, 228, see also Configuration objects management, see CSM Software crisis, 11 Software engineering, 4, 20 c/s systems, 755 environment, 122 generic view, 21 mathematics, 676 methods, deficiencies, 675 paradigm, 26, 68 road ahead, 845 tasks, 177, see also Tasks work tasks, 69 Software Engineering Institute (SEI), 24, 105 Software equation, 135, 171 Software librarian, 62 Software maintenance, 804, see also Maintenance Software maturity index, 99, 533 Software myths, 12 Software procedure, 351 Software process, 20, see also Process improvement, 82 models, 26, 64, 848 Software project(s) estimation, 123 failure of, 57 gathering requirements, 11 lateness, 166 management, 55 planning, 113, see also Project planning scheduling, see Scheduling Software Project Plan, 198, 226 Software prototyping, 289, see also Prototyping Software quality, 199, 338, 508 metrics, 95 Software quality assurance, 24, 199, 479, see also Quality assurance activities, 201 audits, 202 formal approaches to, 209 group, 200 plan, 201 SQA Plan, 201, 218 Software reengineering, 804, see also Reengineering Software reliability, 212, 483, see also Reliability Software repository, 228 Software requirements, 13, 292 analysis, 29, 272, see also Requirements analysis engineering, 271 Software Requirements Specification, 293, 226, 327, 381, 495 Software reuse, 9, 43, see also Reuse Software reviews, 202, see also Formal technical review Software risks, 146, see also Risks Software safety, 159 Software science, 531 Software scope, 67, 115, 118, see also Scope Software sizing, 124 Software team, 60, 170, see also Teams Software testing, 437, see also Testing Software safety, 213 Source code, metrics, 531 Span of control, 347 Specification, 291 Specification language, 689 Specification principles, 291 Specification review, 294 Spiral model, 36, 38 Spoilage, 97 Stability, 442 Stakeholders, 275 Standards, 12 State-based models, 596 State-box specification, 705 State diagram, 613 State model, 648 State transition diagram (STD), 302, 317, 318, 325 Statement of scope, 68, 557 States, types of, 595 Static analysis, tools, 832 Statistical modeling, 483 Statistical process control, 100 Statistical quality assurance, 209 Statistical software process improvement (SSPI), 84 Statistical use testing, 702, 712 Status accounting, 237 Stepwise elaboration, 409 Stepwise refinement, 343 Stress testing, 498 Structural complexity metric, 524 Structural model view, 576 Structural modeling, 728 Structural partitioning, 348 Structure points, 725, 728, 729 cost analysis, 741 Structured analysis, 299, 300, 310 Hatley and Pirbhai extensions, 315 mechanics, 319 real time extensions, 312 Ward and Mellor extensions, 312 Structured analysis and design technique (SADT), 330 Structured constructs, 424, 426 Structured design, 379 Structured English, 429 Structured programming, 339, 424, 706 Structured query language (SQL), 749 860 INDEX Structured retrofit, 815 Structures, 588 Stubs, 487 Style, see Architectural style Subclass, 547 Subflow, 382 Subjects, definition of, 590 Subproofs, 709 Subsystem collaboration table, 617 Subsystems, 563, 590, 612 allocation of, 613 communication, 612, 616 Superclass, 547, 551 Support, 29 Support classes, 563 Support phase, 22 Support risk, 150 Supportability, 513 Symbol table, 677 Synchronization control, 234 Syntactic domain, 689 System, 246 complexity, 524 component engineering, 255 components, 249 constraints, 250 domains, 249 elements, 249 engineer, 249 world view, 248 System context diagram (SCD), 262 System design, activities, 611 System engineer, 264 System engineering, 245 hierarchy, 248 System flow diagram, 264 System image, 405 System information engineering, 28 System model, 262 restraining factors, 249 System modeling, 249, 259, 262 System perception, 405 System response time, 413 System simulation, 251 System software, tools, 830 System Specification, 120, 128, 259, 226, 265, 381 System testing, 481, 496 Task analysis, 408 Task deployment, 279 Task management component, 614 Task modeling, steps, 409 Task network, 180, 181 Task regions, 36 Task set, 23, 37, 172 Task set selector computation of, 175 interpretation of, 176 Task template, 614 Tasks, 57, 614 major, 177 refinement of, 178 Team leaders, 59 Team organization, 60, 63 Teams, 61 jelled, 63 organizational paradigms, 62 toxic, 63 Technology infrastructure, 253 Templates, 779 Test cases, 442, 443, 449 Test coverage, 467 Test management, tools, 832 Test Specification, 494 Testability, 440, 510 Testing, 29, 197 alpha and beta, 496 behavioral methods, 462 big-bang, 488 black-box methods, 459 boundary value analysis, 465 c/s architectures, 469 c/s systems, 762 completion criteria, 482 control structure, 454 data flow, 456 document and help facilities, 469 equivalence partitioning, 463 fundamentals, 438 graph-based, 460 GUIs, 469 integration, 488 logical conditions, 454 loops, 458 metrics for, 532 object-oriented, 631, 638 objective of, 439 organizational issues, 479 orthogonal array, 466 principles of, 439 real-time systems, 470 regression, 491 schedule, 494 specialized environments, 468 strategic issues, 484 strategies for, 477 system-level, 496 thread based, 637 tools, 831 WebApps, 786 white-box methods, 444 Thin client, 751 3D function point, 92 Time allocation, 169 Time-boxing, 185 Time-continuous data flow, 313 Timeline charts, 182 Timing modeling, 462 Tools, 12, see also CASE management services, 835 Top-down integration, 488 Total quality management (TQM), 199 Traceability tables, 261 Transaction, 380 Transaction center, 380, 392 Transaction flow, 380 modeling, 462 Transaction mapping, 389, 390, 393 Transform, 310 Transform center, 379, 383 Transform flow, 379 Transform mapping, 380–381 Umbrella activities, 23, 37, 57 UML, 43, 575 notation, 581 object design, 610 system design, 610 views, 576 Understandability, 442, 607 Unified development process, 43 Unified modeling language, see UML Unit testing, 481 common errors found, 486 considerations, 485 OO software, 636 procedures, 487 Upper natural process limit (UNPL), 102 Usability, 97, 510, 512, 513 Usage scenarios, 259, 280, 615, 713, 762, see also Use-case Use-case, 54, 280, 289, 375, 581, 615, 636 diagram, 581 examples of, 281, 642 User interface component, 615 consistency of, 405 design, see User interface design development systems, 415 layout of, 404 prototype, 408, 416 toolkit, 415 User interface design, 401, see also Interface design evaluation, 416 golden rules, 402 issues, 413 model, 405 principles of, 403 process model, 407 requirements gathering, 402 reviews, 417 User model, 405 User model view, 576 User satisfaction, 196 Users, 406 memory load, 404 types of, 406 Validation, 479 Validation criteria, 278, 293, 495, 481, 495 Validation testing criteria, 495 OO software, 637 Value analysis, 279 Variant, 233 Variation between samples, 194 Variation control, 194 Verification, 479 Version control, 232 automated approaches, 233 Versioning, 840 Versions, 232 Vital few causes, 209 Walkthroughs, 206 Waterfall model, 28 Ways of navigation, 784 Wear, Web-based applications, see WebApps Web engineer, 779, 788 Web engineering, see WebE Web publisher, 788 WebApps, 771 architecture of, 780 categories, 772 characteristics of, 772 cost estimates, 791 design patterns, 783 quality attributes, 773 structures, 780 WebE, 769, 770 activities, 775 administrator, 789 analysis, 778 design, 779 development schedule, 792 formulation, 776 interface design, 785 management issues, 787 navigation design, 783 outsourcing, 791 politics of, 793 project management guidelines, 790 SCM issues, 792 support specialist, 789 teams, 788 testing, 786 tools, 831 WebE process model, 775 W5HH principle, 73 Where-used/how used, 329 White-box testing, 444 Width, structure, 347 WINWIN spiral model, 38 Wirfs-Brock method, 574, 609 Work breakdown structure (WBS), 181 Work products, 57 Work tasks, 69 XML, 774 Z notation, summary of, 691 Z specification language, 690, 692 Zero quality control, 215 Zone rules, 103 [...]... CONTENTS CHAPTER 13 DESIGN CONCEPTS AND PRINCIPLES 335 13. 1 13. 2 Software Design and Software Engineering 336 The Design Process 338 13. 2.1 Design and Software Quality 338 13. 2.2 The Evolution of Software Design 339 13. 3 Design Principles 340 13. 4 Design Concepts 341 13. 4.1 Abstraction 342 13. 4.2 Refinement 343 13. 4.3 Modularity 343 13. 4.4 Software Architecture 346 13. 4.5 Control Hierarchy 347 13. 4.6 Structural... methods across the entire software engineering process, including analysis, design, and testing Part Five, Advanced Software Engineering Topics, presents dedicated chapters that address formal methods, cleanroom software engineering, component-based software engineering, client/server software engineering, Web engineering, reengineering, and CASE The five-part organization of the fifth edition enables an... Hierarchy 347 13. 4.6 Structural Partitioning 348 13. 4.7 Data Structure 349 13. 4.8 Software Procedure 351 13. 4.9 Information Hiding 351 13. 5 Effective Modular Design 352 13. 5.1 Functional Independence 352 13. 5.2 Cohesion 353 13. 5.3 Coupling 354 13. 6 Design Heuristics for Effective Modularity 355 13. 7 The Design Model 357 13. 8 Design Documentation 358 13. 9 Summary 359 REFERENCES 359 PROBLEMS AND POINTS... the software that we produce suffers and bad things happen In addition, debate and controversy about the true nature of the software engineering approach continue The status of software engineering is a study in contrasts Attitudes have changed, progress has been made, but much remains to be done before the discipline reaches full maturity The fifth edition of Software Engineering: A Practitioner's Approach. .. Estimation 129 5.6.4 Process-Based Estimation 130 5.6.5 An Example of Process-Based Estimation 131 5.7 Empirical Estimation Models 132 5.7.1 The Structure of Estimation Models 132 5.7.2 The COCOMO Model 133 5.7.3 The Software Equation 135 5.8 The Make/Buy Decision 136 5.8.1 Creating a Decision Tree 137 5.8.2 Outsourcing 138 5.9 Automated Estimation Tools 139 5.10 Summary 140 REFERENCES 140 PROBLEMS... INFORMATION SOURCES CHAPTER 30 REENGINEERING 797 799 30.1 Business Process Reengineering 800 30.1.1 Business Processes 800 30.1.2 Principles of Business Process Reengineering 801 30.1.3 A BPR Model 802 30.1.4 Words of Warning 804 30.2 Software Reengineering 804 30.2.1 Software Maintenance 804 30.2.2 A Software Reengineering Process Model 805 30.3 Reverse Engineering 809 30.3.1 Reverse Engineering to Understand... professional resources including outlines (and samples of) software engineering documents and other work products, a useful set of software engineering checklists, a catalog of software engineering (CASE) tools, a comprehensive collection of Web-based resources, and an “adaptable process model” that provides a detailed task breakdown of the software engineering process In addition, SepaWeb will contain... chapters Part Two, Managing Software Projects, presents topics that are relevant to those who plan, manage, and control a software development project Part Three, Conventional Methods for Software Engineering, presents the classical analysis, design, and testing methods that some view as the “conventional” school of software engineering Part Four, Object-Oriented Software Engineering, presents object-oriented... Reverse Engineering to Understand Data 811 30.3.3 Reverse Engineering User Interfaces 812 30.4 Restructuring 813 30.4.1 Code Restructuring 814 30.4.2 Data Restructuring 814 30.5 Forward Engineering 814 30.5.1 Forward Engineering for Client/Server Architectures 816 30.5.2 Forward Engineering for Object-Oriented Architectures 817 30.5.3 Forward Engineering User Interfaces 818 30.6 The Economics of Reengineering... The Web site, which I call xxv xxvi P R E FA C E SepaWeb, can be found at http://www.mhhe.com/pressman Designed to be used in conjunction with the fifth edition of Software Engineering: A Practitioner's Approach, SepaWeb provides a broad array of software engineering resources that will benefit instructors, students, and industry professionals Like all Web sites, SepaWeb will evolve over time, but the ... CHAPTER 13 DESIGN CONCEPTS AND PRINCIPLES 335 13. 1 13. 2 Software Design and Software Engineering 336 The Design Process 338 13. 2.1 Design and Software Quality 338 13. 2.2 The Evolution of Software. .. ObjectOriented Software Engineering with UML and C++, 4/e Schach, Classical and ObjectOriented Software Engineering with UML and Java, 1/e Software Engineering A PRACTITIONER’S APPROACH FIFTH EDITION. .. Design 339 13. 3 Design Principles 340 13. 4 Design Concepts 341 13. 4.1 Abstraction 342 13. 4.2 Refinement 343 13. 4.3 Modularity 343 13. 4.4 Software Architecture 346 13. 4.5 Control Hierarchy 347 13. 4.6