Lecture notes on Object-Oriented Software Engineering

Object-oriented software engineering an agile unified methodology and object oriented software engineering analysis and design advantages pdf free download

Dr.DavidWllker,United States,Professional

Published Date:11-07-2017

Your Website URL(Optional)

Comment

Software Engineering A PRACTITIONER’S APPROACHCHAPTER THE PRODUCT 1 KEY he warnings began more than a decade before the event, but no one paid CONCEPTS much attention. With less than two years to the deadline, the media application Tpicked up the story. Then government ofﬁcials voiced their concern, busi- categories . . . . . . . 9 ness and industry leaders committed vast sums of money, and ﬁnally, dire warn- component-based ings of pending catastrophe penetrated the public’s consciousness. Software, assembly. . . . . . . . . 8 in the guise of the now-infamous Y2K bug, would fail and, as a result, stop the failure curves . . . . . 8 world as we then knew it. history . . . . . . . . . . 5 As we watched and wondered during the waning months of 1999, I couldn’t myths . . . . . . . . . . 12 help thinking of an unintentionally prophetic paragraph contained on the ﬁrst reuse . . . . . . . . . . . . 9 page of the fourth edition of this book. It stated: software characteristics . . . . 6 Computer software has become a driving force. It is the engine that drives business software decision making. It serves as the basis for modern scientiﬁc investigation and engi- engineering . . . . . . 4 neering problem solving. It is a key factor that differentiates modern products and wear . . . . . . . . . . . . 7 services. It is embedded in systems of all kinds: transportation, medical, telecom- munications, military, industrial processes, entertainment, ofﬁce products, . . . the list is almost endless. Software is virtually inescapable in a modern world. And as we move into the twenty-ﬁrst century, it will become the driver for new advances in everything from elementary education to genetic engineering. What is it? Computer software is What are the steps? You build computer software QUICK the product that software engi- like you build any successful product, by apply- LOOK neers design and build. It encom- ing a process that leads to a high-quality result passes programs that execute within a computer that meets the needs of the people who will use of any size and architecture, documents that the product. You apply a software engineering encompass hard-copy and virtual forms, and approach. data that combine numbers and text but also What is the work product? From the point of view of includes representations of pictorial, video, and a software engineer, the work product is the pro- audio information. grams, documents, and data that are computer Who does it? Software engineers build it, and virtu- software. But from the user’s viewpoint, the work ally everyone in the industrialized world uses it product is the resultant information that somehow either directly or indirectly. makes the user’s world better. Why is it important? Because it affects nearly every How do I ensure that I’ve done it right? Read the aspect of our lives and has become pervasive in remainder of this book, select those ideas appli- our commerce, our culture, and our everyday cable to the software that you build, and apply activities. them to your work. 34 PART ONE THE PRODUCT AND THE PROCESS In the ﬁve years since the fourth edition of this book was written, the role of soft- ware as the “driving force” has become even more obvious. A software-driven Inter- net has spawned its own 500 billion economy. In the euphoria created by the promise of a new economic paradigm, Wall Street investors gave tiny “dot-com” companies billion dollar valuations before these start-ups produced a dollar in sales. New software-driven industries have arisen and old ones that have not adapted to the new driving force are now threatened with extinction. The United States government has litigated against the software’s industry’s largest company, just as it did in earlier eras when it moved to stop monopolistic practices in the oil and steel industries. Software’s impact on our society and culture continues to be profound. As its importance grows, the software community continually attempts to develop tech- “Ideas and nologies that will make it easier, faster, and less expensive to build high-quality com- technological puter programs. Some of these technologies are targeted at a specific application discoveries are the domain (e.g., Web-site design and implementation); others focus on a technology driving engines of economic growth.” domain (e.g., object-oriented systems); and still others are broad-based (e.g., oper- The Wall Street ating systems such as LINUX). However, we have yet to develop a software technol- Journal ogy that does it all, and the likelihood of one arising in the future is small. And yet, people bet their jobs, their comfort, their safety, their entertainment, their decisions, and their very lives on computer software. It better be right. This book presents a framework that can be used by those who build computer software—people who must get it right. The technology encompasses a process, a set of methods, and an array of tools that we call software engineering. 1.1 THE EVOLVING ROLE OF SOFTWARE Today, software takes on a dual role. It is a product and, at the same time, the vehi- cle for delivering a product. As a product, it delivers the computing potential embod- ied by computer hardware or, more broadly, a network of computers that are accessible by local hardware. Whether it resides within a cellular phone or operates inside a mainframe computer, software is an information transformer—producing, manag- Software is both a ing, acquiring, modifying, displaying, or transmitting information that can be as sim- product and a vehicle ple as a single bit or as complex as a multimedia presentation. As the vehicle used for delivering a to deliver the product, software acts as the basis for the control of the computer (oper- product. ating systems), the communication of information (networks), and the creation and control of other programs (software tools and environments). Software delivers the most important product of our time—information. Software transforms personal data (e.g., an individual’s ﬁnancial transactions) so that the data can be more useful in a local context; it manages business information to enhance competitiveness; it provides a gateway to worldwide information networks (e.g., Inter- net) and provides the means for acquiring information in all of its forms. The role of computer software has undergone signiﬁcant change over a time span of little more than 50 years. Dramatic improvements in hardware performance, pro-CHAPTER 1 THE PRODUCT 5 found changes in computing architectures, vast increases in memory and storage capacity, and a wide variety of exotic input and output options have all precipitated more sophisticated and complex computer-based systems. Sophistication and com- plexity can produce dazzling results when a system succeeds, but they can also pose huge problems for those who must build complex systems. Popular books published during the 1970s and 1980s provide useful historical insight into the changing perception of computers and software and their impact on our culture. Osborne OSB79 characterized a "new industrial revolution." Toffler “For I dipped into the future, far as the TOF80 called the advent of microelectronics part of "the third wave of change" in human eye could human history, and Naisbitt NAI82 predicted a transformation from an industrial see, Saw the vision society to an "information society." Feigenbaum and McCorduck FEI83 suggested of the world, and all that information and knowledge (controlled by computers) would be the focal point the wonder that would be.” for power in the twenty-ﬁrst century, and Stoll STO89 argued that the "electronic Tennyson community" created by networks and software was the key to knowledge interchange throughout the world. As the 1990s began, Tofﬂer TOF90 described a "power shift" in which old power structures (governmental, educational, industrial, economic, and military) disinte- grate as computers and software lead to a "democratization of knowledge." Yourdon “Computers make it YOU92 worried that U.S. companies might loose their competitive edge in software- easy to do a lot of related businesses and predicted “the decline and fall of the American programmer.” things, but most of Hammer and Champy HAM93 argued that information technologies were to play a the things that they pivotal role in the “reengineering of the corporation.” During the mid-1990s, the per- make it easier to do don't need to be vasiveness of computers and software spawned a rash of books by “neo-Luddites” done.” (e.g., Resisting the Virtual Life, edited by James Brook and Iain Boal and The Future Andy Rooney Does Not Compute by Stephen Talbot). These authors demonized the computer, empha- sizing legitimate concerns but ignoring the profound beneﬁts that have already been realized. LEV95 During the later 1990s, Yourdon YOU96 re-evaluated the prospects for the software professional and suggested the “the rise and resurrection” of the Ameri- can programmer. As the Internet grew in importance, his change of heart proved to be correct. As the twentieth century closed, the focus shifted once more, this time to the impact of the Y2K “time bomb” (e.g., YOU98b, DEJ98, KAR99). Although the predictions of the Y2K doomsayers were incorrect, their popular writings drove home the pervasiveness of software in our lives. Today, “ubiquitous computing” NOR98 has spawned a generation of information appliances that have broadband connectivity to the Web to provide “a blanket of connectedness over our homes, offices and motorways” LEV99. Software’s role continues to expand. The lone programmer of an earlier era has been replaced by a team of software specialists, each focusing on one part of the technology required to deliver a com- plex application. And yet, the same questions asked of the lone programmer are being asked when modern computer-based systems are built:6 PART ONE THE PRODUCT AND THE PROCESS • Why does it take so long to get software ﬁnished? • Why are development costs so high? • Why can't we ﬁnd all the errors before we give the software to customers? • Why do we continue to have difﬁculty in measuring progress as software is being developed? 1 These, and many other questions, are a manifestation of the concern about soft- ware and the manner in which it is developed—a concern that has lead to the adop- tion of software engineering practice. 1.2 SOFTWARE In 1970, less than 1 percent of the public could have intelligently described what "computer software" meant. Today, most professionals and many members of the public at large feel that they understand software. But do they? A textbook description of software might take the following form: Software is (1) instructions (computer programs) that when executed provide desired function and per- How should formance, (2) data structures that enable the programs to adequately manipulate infor- ? we deﬁne mation, and (3) documents that describe the operation and use of the programs. There software? is no question that other, more complete deﬁnitions could be offered. But we need more than a formal deﬁnition. 1.2.1 Software Characteristics To gain an understanding of software (and ultimately an understanding of software engineering), it is important to examine the characteristics of software that make it different from other things that human beings build. When hardware is built, the human creative process (analysis, design, construction, testing) is ultimately trans- lated into a physical form. If we build a new computer, our initial sketches, formal design drawings, and breadboarded prototype evolve into a physical product (chips, circuit boards, power supplies, etc.). Software is a logical rather than a physical system element. Therefore, software has characteristics that are considerably different than those of hardware: 1. Software is developed or engineered, it is not manufactured in the classical sense. Software is Although some similarities exist between software development and hardware man- engineered, not manufactured. ufacture, the two activities are fundamentally different. In both activities, high qual- 1 In an excellent book of essays on the software business, Tom DeMarco DEM95 argues the coun- terpoint. He states: “Instead of asking ‘why does software cost so much?’ we need to begin ask- ing ‘What have we done to make it possible for today’s software to cost so little?’ The answer to that question will help us continue the extraordinary level of achievement that has always distin- guished the software industry.”CHAPTER 1 THE PRODUCT 7 FIGURE 1.1 Failure curve for hardware “Infant “Wear out” mortality” Time ity is achieved through good design, but the manufacturing phase for hardware can introduce quality problems that are nonexistent (or easily corrected) for software. Both activities are dependent on people, but the relationship between people applied and work accomplished is entirely different (see Chapter 7). Both activities require the construction of a "product" but the approaches are different. Software costs are concentrated in engineering. This means that software proj- ects cannot be managed as if they were manufacturing projects. 2. Software doesn't "wear out." Software doesn’t wear out, but it does Figure 1.1 depicts failure rate as a function of time for hardware. The relationship, deteriorate. often called the "bathtub curve," indicates that hardware exhibits relatively high fail- ure rates early in its life (these failures are often attributable to design or manufac- turing defects); defects are corrected and the failure rate drops to a steady-state level (ideally, quite low) for some period of time. As time passes, however, the failure rate rises again as hardware components suffer from the cumulative affects of dust, vibra- tion, abuse, temperature extremes, and many other environmental maladies. Stated simply, the hardware begins to wear out. Software is not susceptible to the environmental maladies that cause hardware to wear out. In theory, therefore, the failure rate curve for software should take the form of the “idealized curve” shown in Figure 1.2. Undiscovered defects will cause high failure rates early in the life of a program. However, these are corrected (ideally, without intro- ducing other errors) and the curve ﬂattens as shown.The idealized curve is a gross over- simpliﬁcation of actual failure models (see Chapter 8 for more information) for software. However, the implication is clear—software doesn't wear out. But it does deteriorate This seeming contradiction can best be explained by considering the “actual curve” shown in Figure 1.2. During its life, software will undergo change (maintenance). As Failure rate8 PART ONE THE PRODUCT AND THE PROCESS FIGURE 1.2 Increased failure Idealized and rate due to side actual failure effects curves for software Change Actual curve Idealized curve Software engineering Time methods strive to reduce the magnitude of the spikes and the changes are made, it is likely that some new defects will be introduced, causing the slope of the actual failure rate curve to spike as shown in Figure 1.2. Before the curve can return to the curve in Figure 1.2. original steady-state failure rate, another change is requested, causing the curve to spike again. Slowly, the minimum failure rate level begins to rise—the software is deteriorating due to change. Another aspect of wear illustrates the difference between hardware and software. When a hardware component wears out, it is replaced by a spare part. There are no software spare parts. Every software failure indicates an error in design or in the process through which design was translated into machine executable code. There- fore, software maintenance involves considerably more complexity than hardware maintenance. 3. Although the industry is moving toward component-based assembly, most Most software software continues to be custom built. continues to be Consider the manner in which the control hardware for a computer-based product custom built. is designed and built. The design engineer draws a simple schematic of the digital circuitry, does some fundamental analysis to assure that proper function will be achieved, and then goes to the shelf where catalogs of digital components exist. Each integrated circuit (called an IC or a chip) has a part number, a deﬁned and validated function, a well-deﬁned interface, and a standard set of integration guidelines. After each component is selected, it can be ordered off the shelf. As an engineering discipline evolves, a collection of standard design components is created. Standard screws and off-the-shelf integrated circuits are only two of thou- sands of standard components that are used by mechanical and electrical engineers as they design new systems. The reusable components have been created so that the engineer can concentrate on the truly innovative elements of a design, that is, the Failure rateCHAPTER 1 THE PRODUCT 9 parts of the design that represent something new. In the hardware world, component reuse is a natural part of the engineering process. In the software world, it is some- thing that has only begun to be achieved on a broad scale. A software component should be designed and implemented so that it can be reused in many different programs. In the 1960s, we built scientiﬁc subroutine libraries XRef that were reusable in a broad array of engineering and scientiﬁc applications. These Software reuse is subroutine libraries reused well-deﬁned algorithms in an effective manner but had a discussed in Chapter limited domain of application. Today, we have extended our view of reuse to encom- 13. Component-based software engineering is pass not only algorithms but also data structure. Modern reusable components encap- presented in Chapter sulate both data and the processing applied to the data, enabling the software engineer 27. to create new applications from reusable parts. For example, today's graphical user interfaces are built using reusable components that enable the creation of graphics windows, pull-down menus, and a wide variety of interaction mechanisms. The data structure and processing detail required to build the interface are contained with a library of reusable components for interface construction. 1.2.2 Software Applications Software may be applied in any situation for which a prespeciﬁed set of procedural steps (i.e., an algorithm) has been deﬁned (notable exceptions to this rule are expert system software and neural network software). Information content and determinacy are important factors in determining the nature of a software application. Content refers to the meaning and form of incoming and outgoing information. For example, many business applications use highly structured input data (a database) and pro- duce formatted “reports.” Software that controls an automated machine (e.g., a numerical control) accepts discrete data items with limited structure and produces individual machine commands in rapid succession. Information determinacy refers to the predictability of the order and timing of infor- mation. An engineering analysis program accepts data that have a predeﬁned order, executes the analysis algorithm(s) without interruption, and produces resultant data in report or graphical format. Such applications are determinate. A multiuser oper- ating system, on the other hand, accepts inputs that have varied content and arbi- trary timing, executes algorithms that can be interrupted by external conditions, and produces output that varies as a function of environment and time. Applications with these characteristics are indeterminate. It is somewhat difﬁcult to develop meaningful generic categories for software appli- cations. As software complexity grows, neat compartmentalization disappears. The following software areas indicate the breadth of potential applications: System software. System software is a collection of programs written to service other programs. Some system software (e.g., compilers, editors, and ﬁle manage- ment utilities) process complex, but determinate, information structures. Other sys- tems applications (e.g., operating system components, drivers, telecommunications10 PART ONE THE PRODUCT AND THE PROCESS processors) process largely indeterminate data. In either case, the system software area is characterized by heavy interaction with computer hardware; heavy usage by multiple users; concurrent operation that requires scheduling, resource sharing, and sophisticated process management; complex data structures; and multiple external interfaces. Real-time software. Software that monitors/analyzes/controls real-world events as they occur is called real time. Elements of real-time software include a data gath- ering component that collects and formats information from an external environ- ment, an analysis component that transforms information as required by the application, a control/output component that responds to the external environment, and a monitoring component that coordinates all other components so that real-time response (typically ranging from 1 millisecond to 1 second) can be maintained. Business software. Business information processing is the largest single software application area. Discrete "systems" (e.g., payroll, accounts receivable/payable, inven- tory) have evolved into management information system (MIS) software that accesses one or more large databases containing business information. Applications in this area restructure existing data in a way that facilitates business operations or man- One of the most comprehensive libraries of agement decision making. In addition to conventional data processing application, shareware/freeware can business software applications also encompass interactive computing (e.g., point- be found at of-sale transaction processing). www.shareware.com Engineering and scientiﬁc software. Engineering and scientiﬁc software have been characterized by "number crunching" algorithms. Applications range from astron- omy to volcanology, from automotive stress analysis to space shuttle orbital dynam- ics, and from molecular biology to automated manufacturing. However, modern applications within the engineering/scientiﬁc area are moving away from conven- tional numerical algorithms. Computer-aided design, system simulation, and other interactive applications have begun to take on real-time and even system software characteristics. Embedded software. Intelligent products have become commonplace in nearly every consumer and industrial market. Embedded software resides in read-only mem- ory and is used to control products and systems for the consumer and industrial mar- kets. Embedded software can perform very limited and esoteric functions (e.g., keypad control for a microwave oven) or provide signiﬁcant function and control capability (e.g., digital functions in an automobile such as fuel control, dashboard displays, and braking systems). Personal computer software. The personal computer software market has bur- geoned over the past two decades. Word processing, spreadsheets, computer graph- ics, multimedia, entertainment, database management, personal and business ﬁnancial applications, external network, and database access are only a few of hundreds of applications. Web-based software. The Web pages retrieved by a browser are software that incorporates executable instructions (e.g., CGI, HTML, Perl, or Java), and data (e.g.,CHAPTER 1 THE PRODUCT 11 hypertext and a variety of visual and audio formats). In essence, the network becomes a massive computer providing an almost unlimited software resource that can be accessed by anyone with a modem. Artificial intelligence software. Artificial intelligence (AI) software makes use of nonnumerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis. Expert systems, also called knowledge- based systems, pattern recognition (image and voice), artificial neural networks, theorem proving, and game playing are representative of applications within this category. 1.3 SOFTWARE: A CRISIS ON THE HORIZON? Many industry observers (including this author) have characterized the problems associated with software development as a "crisis." More than a few books (e.g., GLA97, FLO97, YOU98a) have recounted the impact of some of the more spec- tacular software failures that have occurred over the past decade. Yet, the great suc- “The most likely way cesses achieved by the software industry have led many to question whether the term for the world to be software crisis is still appropriate. Robert Glass, the author of a number of books on destroyed, most software failures, is representative of those who have had a change of heart. He states experts agree, is by GLA98: “I look at my failure stories and see exception reporting, spectacular fail- accident. That's where we come in; ures in the midst of many successes, a cup that is now nearly full.” we're computer It is true that software people succeed more often than they fail. It also true that professionals. We the software crisis predicted 30 years ago never seemed to materialize. What we cause accidents.” really have may be something rather different. Nathaniel The word crisis is deﬁned in Webster's Dictionary as “a turning point in the course of Borenstein anything; decisive or crucial time, stage or event.” Yet, in terms of overall software qual- ity and the speed with which computer-based systems and products are developed, there has been no "turning point," no "decisive time," only slow, evolutionary change, punctuated by explosive technological changes in disciplines associated with software. The word crisis has another deﬁnition: "the turning point in the course of a disease, when it becomes clear whether the patient will live or die." This deﬁnition may give us a clue about the real nature of the problems that have plagued software development. 2 What we really have might be better characterized as a chronic affliction. The word afﬂiction is deﬁned as "anything causing pain or distress." But the deﬁnition of the adjective chronic is the key to our argument: "lasting a long time or recurring often; continuing indeﬁnitely." It is far more accurate to describe the problems we have endured in the software business as a chronic afﬂiction than a crisis. Regardless of what we call it, the set of problems that are encountered in the devel- opment of computer software is not limited to software that "doesn't function 2 This terminology was suggested by Professor Daniel Tiechrow of the University of Michigan in a talk presented in Geneva, Switzerland, April 1989.12 PART ONE THE PRODUCT AND THE PROCESS properly." Rather, the affliction encompasses problems associated with how we develop software, how we support a growing volume of existing software, and how we can expect to keep pace with a growing demand for more software. We live with this afﬂiction to this day—in fact, the industry prospers in spite of it. And yet, things would be much better if we could ﬁnd and broadly apply a cure. 1.4 SOFTWARE MYTHS Many causes of a software afﬂiction can be traced to a mythology that arose during the early history of software development. Unlike ancient myths that often provide human lessons well worth heeding, software myths propagated misinformation and “In the absence of confusion. Software myths had a number of attributes that made them insidious; for meaningful standards, instance, they appeared to be reasonable statements of fact (sometimes containing a new industry like software comes to elements of truth), they had an intuitive feel, and they were often promulgated by depend instead on experienced practitioners who "knew the score." folklore.” Today, most knowledgeable professionals recognize myths for what they are— Tom DeMarco misleading attitudes that have caused serious problems for managers and technical people alike. However, old attitudes and habits are difﬁcult to modify, and remnants of software myths are still believed. Management myths. Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets, keep schedules from slip- ping, and improve quality. Like a drowning person who grasps at a straw, a software manager often grasps at belief in a software myth, if that belief will lessen the pres- sure (even temporarily). Myth: We already have a book that's full of standards and procedures for building software, won't that provide my people with everything they need to know? Reality: The book of standards may very well exist, but is it used? Are software practitioners aware of its existence? Does it reﬂect modern software engineering prac- tice? Is it complete? Is it streamlined to improve time to delivery while still main- taining a focus on quality? In many cases, the answer to all of these questions is "no." Myth: My people have state-of-the-art software development tools, after all, we buy them the newest computers. Reality: It takes much more than the latest model mainframe, workstation, or PC to do high-quality software development. Computer-aided software engineering (CASE) tools are more important than hardware for achieving good quality and pro- ductivity, yet the majority of software developers still do not use them effectively. Myth: If we get behind schedule, we can add more programmers and catch up (sometimes called the Mongolian horde concept). Reality: Software development is not a mechanistic process like manufacturing. In the words of Brooks BRO75: "adding people to a late software project makes itCHAPTER 1 THE PRODUCT 13 later." At ﬁrst, this statement may seem counterintuitive. However, as new people are added, people who were working must spend time educating the newcomers, thereby reducing the amount of time spent on productive development effort. Peo- ple can be added but only in a planned and well-coordinated manner. The Software Project Managers Network at 3 Myth: If I decide to outsource the software project to a third party, I can just relax www.spmn.com can and let that ﬁrm build it. help you dispel these and other myths. Reality: If an organization does not understand how to manage and control software projects internally, it will invariably struggle when it outsources software projects. Customer myths. A customer who requests computer software may be a person at the next desk, a technical group down the hall, the marketing/sales department, or an outside company that has requested software under contract. In many cases, the customer believes myths about software because software managers and prac- titioners do little to correct misinformation. Myths lead to false expectations (by the customer) and ultimately, dissatisfaction with the developer. Myth: A general statement of objectives is sufﬁcient to begin writing programs— we can ﬁll in the details later. Work very hard to Reality: A poor up-front deﬁnition is the major cause of failed software efforts. A understand what you formal and detailed description of the information domain, function, behavior, per- have to do before you start. You may not be formance, interfaces, design constraints, and validation criteria is essential. These able to develop every characteristics can be determined only after thorough communication between cus- detail, but the more tomer and developer. you know, the less risk you take. Myth: Project requirements continually change, but change can be easily accom- modated because software is ﬂexible. Reality: It is true that software requirements change, but the impact of change varies with the time at which it is introduced. Figure 1.3 illustrates the impact of change. If serious attention is given to up-front deﬁnition, early requests for change can be accommodated easily. The customer can review requirements and recom- mend modiﬁcations with relatively little impact on cost. When changes are requested XRef The management and during software design, the cost impact grows rapidly. Resources have been com- control of change is mitted and a design framework has been established. Change can cause upheaval considered in detail in that requires additional resources and major design modiﬁcation, that is, additional Chapter 9. cost. Changes in function, performance, interface, or other characteristics during implementation (code and test) have a severe impact on cost. Change, when requested after software is in production, can be over an order of magnitude more expensive than the same change requested earlier. 3 The term “outsourcing” refers to the widespread practice of contracting software development work to a third party—usually a consulting ﬁrm that specializes in building custom software for its clients.14 PART ONE THE PRODUCT AND THE PROCESS FIGURE 1.3 60–100× The impact of change 1.5–6× 1× Definition Development After release Practitioner's myths. Myths that are still believed by software practitioners have been fostered by 50 years of programming culture. During the early days of software, programming was viewed as an art form. Old ways and attitudes die hard. Myth: Once we write the program and get it to work, our job is done. Reality: Someone once said that "the sooner you begin 'writing code', the longer it'll take you to get done." Industry data (LIE80, JON91, PUT97) indicate that between 60 and 80 percent of all effort expended on software will be expended after it is delivered to the customer for the ﬁrst time. Myth: Until I get the program "running" I have no way of assessing its quality. Reality: One of the most effective software quality assurance mechanisms can be Whenever you think, applied from the inception of a project—the formal technical review. Software reviews we don’t have time for (described in Chapter 8) are a "quality ﬁlter" that have been found to be more effec- software engineering discipline, ask yourself: tive than testing for ﬁnding certain classes of software defects. “Will we have time to Myth: The only deliverable work product for a successful project is the working do it over again?” program. Reality: A working program is only one part of a software conﬁguration that includes many elements. Documentation provides a foundation for successful engineering and, more important, guidance for software support. Myth: Software engineering will make us create voluminous and unnecessary doc- umentation and will invariably slow us down. Reality: Software engineering is not about creating documents. It is about creat- ing quality. Better quality leads to reduced rework. And reduced rework results in faster delivery times. Many software professionals recognize the fallacy of the myths just described. Regret- tably, habitual attitudes and methods foster poor management and technical practices, even when reality dictates a better approach. Recognition of software realities is the ﬁrst step toward formulation of practical solutions for software engineering. Cost to changeCHAPTER 1 THE PRODUCT 15 1.5 SUMMARY Software has become the key element in the evolution of computer-based systems and products. Over the past 50 years, software has evolved from a specialized prob- lem solving and information analysis tool to an industry in itself. But early “pro- gramming” culture and history have created a set of problems that persist today. Software has become the limiting factor in the continuing evolution of computer- based systems. Software is composed of programs, data, and documents. Each of these items comprises a conﬁguration that is created as part of the software engi- neering process. The intent of software engineering is to provide a framework for building software with higher quality. REFERENCES BRO75 Brooks, F., The Mythical Man-Month, Addison-Wesley, 1975. DEJ98 De Jager, P. et al., Countdown Y2K: Business Survival Planning for the Year 2000, Wiley, 1998. DEM95 DeMarco, T., Why Does Software Cost So Much? Dorset House, 1995, p. 9. FEI83 Feigenbaum, E.A. and P. McCorduck, The Fifth Generation, Addison- Wesley, 1983. FLO97 Flowers, S., Software Failure, Management Failure—Amazing Stories and Cautionary Tales, Wiley, 1997. GLA97 Glass, R.L., Software Runaways, Prentice-Hall, 1997. GLA98 Glass, R.L., “Is There Really a Software Crisis?” IEEE Software, vol. 15, no. 1, January 1998, pp. 104–105. HAM93 Hammer, M., and J. Champy, Reengineering the Corporation, HarperCollins Publishers, 1993. JON91 Jones, C., Applied Software Measurement, McGraw-Hill, 1991. KAR99 Karlson, E. and J. Kolber, A Basic Introduction to Y2K: How the Year 2000 Computer Crisis Affects YOU, Next Era Publications, 1999. LEV95 Levy, S., “The Luddites Are Back,” Newsweek, July 12, 1995, p. 55. LEV99 Levy, S., “The New Digital Galaxy,” Newsweek, May 31, 1999, p. 57. LIE80 Lientz, B. and E. Swanson, Software Maintenance Management, Addison- Wesley, 1980. NAI82 Naisbitt, J., Megatrends, Warner Books, 1982. NOR98 Norman, D., The Invisible Computer, MIT Press, 1998. OSB79 Osborne, A., Running Wild—The Next Industrial Revolution, Osborne/McGraw-Hill, 1979. PUT97 Putnam, L. and W. Myers, Industrial Strength Software, IEEE Computer Society Press, 1997. STO89 Stoll, C., The Cuckoo's Egg, Doubleday, 1989. TOF80 Tofﬂer, A., The Third Wave, Morrow, 1980.16 PART ONE THE PRODUCT AND THE PROCESS TOF90 Tofﬂer, A., Powershift, Bantam Publishers, 1990. YOU92 Yourdon, E., The Decline and Fall of the American Programmer, Yourdon Press, 1992. YOU96 Yourdon, E., The Rise and Resurrection of the American Programmer, Your- don Press, 1996. YOU98a Yourdon, E., Death March Projects, Prentice-Hall, 1998. YOU98b Yourdon, E. and J. Yourdon, Time Bomb 2000, Prentice-Hall, 1998. PROBLEMS AND POINTS TO PONDER 1.1. Software is the differentiating characteristic in many computer-based products and systems. Provide examples of two or three products and at least one system in which software, not hardware, is the differentiating element. 1.2. In the 1950s and 1960s, computer programming was an art form learned in an apprenticelike environment. How have the early days affected software development practices today? 1.3. Many authors have discussed the impact of the "information era." Provide a number of examples (both positive and negative) that indicate the impact of software on our society. Review one of the pre-1990 references in Section 1.1 and indicate where the author’s predictions were right and where they were wrong. 1.4. Choose a speciﬁc application and indicate: (a) the software application category (Section 1.2.2) into which it ﬁts; (b) the data content associated with the application; and (c) the information determinacy of the application. 1.5. As software becomes more pervasive, risks to the public (due to faulty pro- grams) become an increasingly significant concern. Develop a realistic doomsday scenario (other than Y2K) where the failure of a computer program could do great harm (either economic or human). 1.6. Peruse the Internet newsgroup comp.risks and prepare a summary of risks to the public that have recently been discussed. An alternate source is Software Engi- neering Notes published by the ACM. 1.7. Write a paper summarizing recent advances in one of the leading edge soft- ware application areas. Potential choices include: advanced Web-based applications, virtual reality, artiﬁcial neural networks, advanced human interfaces, intelligent agents. 1.8. The “myths” noted in Section 1.4 are slowly fading as the years pass, but oth- ers are taking their place. Attempt to add one or two “new” myths to each category. CHAPTER 1 THE PRODUCT 17 FURTHER READINGS AND INFORMATION SOURCES Literally thousands of books are written about computer software. The vast major- ity discuss programming languages or software applications, but a few discuss soft- ware itself. Pressman and Herron (Software Shock, Dorset House, 1991) presented an early discussion (directed at the layperson) of software and the way professionals build it. Negroponte's (Being Digital, Alfred A. Knopf, 1995) best-selling book provides a view of computing and its overall impact in the twenty-ﬁrst century. Books by Nor- man NOR98 and Bergman (Information Appliances and Beyond, Academic Press/Mor- gan Kaufmann, 2000) suggest that the widespread impact of the PC will decline as information appliances and pervasive computing connect everyone in the indus- trialized world and almost every “appliance” that they own to a new Internet infrastructure. Minasi (The Software Conspiracy: Why Software Companies Put out Faulty Products, How They Can Hurt You, and What You Can Do, McGraw-Hill, 2000) argues that the “modern scourge” of software bugs can be eliminated and suggests ways to accom- plish this. DeMarco (Why Does Software Cost So Much? Dorset House, 1995) has pro- duced a collection of amusing and insightful essays on software and the process through which it is developed. A wide variety of information sources on software-related topics and manage- ment is available on the Internet. An up-to-date list of World Wide Web references that are relevant to software can be found at the SEPA Web site: http://www.mhhe.com/engcs/compsci/pressman/resources/product.mhtmlCHAPTER THE PROCESS 2 KEY n a fascinating book that provides an economist’s view of software and soft- CONCEPTS ware engineering, Howard Baetjer, Jr. BAE98, comments on the software common process Iprocess: framework . . . . . . 23 component-based Because software, like all capital, is embodied knowledge, and because that knowl- development. . . . . 42 edge is initially dispersed, tacit, latent, and incomplete in large measure, software concurrent development is a social learning process. The process is a dialogue in which the development. . . . . 40 knowledge that must become the software is brought together and embodied in the evolutionary process software. The process provides interaction between users and designers, between models. . . . . . . . . . 34 users and evolving tools, and between designers and evolving tools technology. It formal methods . . 43 is an iterative process in which the evolving tool itself serves as the medium for com- 4GT . . . . . . . . . . . . 44 munication, with each new round of the dialogue eliciting more useful knowledge maintenance from the people involved. activities . . . . . . . 21 process maturity Indeed, building computer software is an iterative learning process, and the levels. . . . . . . . . . . 24 outcome, something that Baetjer would call “software capital,” is an embodi- prototyping . . . . . 30 ment of knowledge collected, distilled, and organized as the process is con- RAD. . . . . . . . . . . . 32 ducted. software engineering. . . . . . 20 What is it? When you build a building. One process might be appropriate for QUICK product or system, it’s important creating software for an aircraft avionics system, LOOK to go through a series of pre- while an entirely different process would be indi- dictable steps—a road map that helps you create cated for the creation of a Web site. a timely, high-quality result. The road map that What is the work product? From the point of view you follow is called a ‘software process.’ of a software engineer, the work products are the Who does it? Software engineers and their man- programs, documents, and data produced as a agers adapt the process to their needs and then consequence of the software engineering activi- follow it. In addition, the people who have ties deﬁned by the process. requested the software play a role in the software How do I ensure that I’ve done it right? A number of process. software process assessment mechanisms enable Why is it important? Because it provides stability, organizations to determine the “maturity” of a control, and organization to an activity that can, software process. However, the quality, timeliness, if left uncontrolled, become quite chaotic. and long-term viability of the product you build What are the steps? At a detailed level, the process are the best indicators of the efﬁcacy of the process that you adopt depends on the software you’re that you use. 1920 PART ONE THE PRODUCT AND THE PROCESS But what exactly is a software process from a technical point of view? Within the context of this book, we deﬁne a software process as a framework for the tasks that are required to build high-quality software. Is process synonymous with software engi- neering? The answer is “yes” and “no.” A software process deﬁnes the approach that is taken as software is engineered. But software engineering also encompasses tech- nologies that populate the process—technical methods and automated tools. More important, software engineering is performed by creative, knowledgeable people who should work within a deﬁned and mature software process that is appro- priate for the products they build and the demands of their marketplace. The intent of this chapter is to provide a survey of the current state of the software process and pointers to more detailed discussion of management and technical topics presented later in this book. 2.1 SOFTWARE ENGINEERING: A LAYERED TECHNOLOGY Although hundreds of authors have developed personal deﬁnitions of software engi- neering, a deﬁnition proposed by Fritz Bauer NAU69 at the seminal conference on “More than a the subject still serves as a basis for discussion: discipline or a body Software engineering is the establishment and use of sound engineering principles in of knowledge, engineering is a order to obtain economically software that is reliable and works efﬁciently on real machines. verb, an action Almost every reader will be tempted to add to this deﬁnition. It says little about the word, a way of approaching a technical aspects of software quality; it does not directly address the need for cus- problem.” tomer satisfaction or timely product delivery; it omits mention of the importance of Scott Whitmire measurement and metrics; it does not state the importance of a mature process. And yet, Bauer’s deﬁnition provides us with a baseline. What “sound engineering princi- ples” can be applied to computer software development? How do we “economically” build software so that it is “reliable”? What is required to create computer programs that work “efﬁciently” on not one but many different “real machines”? These are the questions that continue to challenge software engineers. The IEEE IEE93 has developed a more comprehensive deﬁnition when it states: How do we Software Engineering: (1) The application of a systematic, disciplined, quantiﬁable approach ? deﬁne to the development, operation, and maintenance of software; that is, the application of software engineering to software. (2) The study of approaches as in (1). engineering? 2.1.1 Process, Methods, and Tools Software engineering is a layered technology. Referring to Figure 2.1, any engineer- ing approach (including software engineering) must rest on an organizational com- mitment to quality. Total quality management and similar philosophies foster a continuous process improvement culture, and this culture ultimately leads to theCHAPTER 2 THE PROCESS 21 FIGURE 2.1 Software Tools engineering layers Methods Process A quality focus development of increasingly more mature approaches to software engineering. The bedrock that supports software engineering is a quality focus. The foundation for software engineering is the process layer. Software engineer- ing process is the glue that holds the technology layers together and enables rational and timely development of computer software. Process deﬁnes a framework for a set of key process areas (KPAs) PAU93 that must be established for effective delivery of software engineering technology. The key process areas form the basis for manage- ment control of software projects and establish the context in which technical meth- ods are applied, work products (models, documents, data, reports, forms, etc.) are produced, milestones are established, quality is ensured, and change is properly man- aged. Software engineering methods provide the technical how-to's for building soft- ware. Methods encompass a broad array of tasks that include requirements analy- sis, design, program construction, testing, and support. Software engineering methods Software engineering rely on a set of basic principles that govern each area of the technology and include encompasses a modeling activities and other descriptive techniques. process, management Software engineering tools provide automated or semi-automated support for the and technical methods, and tools. process and the methods. When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called computer-aided software engineering, is established. CASE combines software, hardware, and a software engineering database (a repository containing important information about analysis, design, program construction, and testing) to create a software engineering environment analogous to CAD/CAE (computer-aided design/engineering) for hardware. 2.1.2 A Generic View of Software Engineering Engineering is the analysis, design, construction, veriﬁcation, and management of technical (or social) entities. Regardless of the entity to be engineered, the following questions must be asked and answered: • What is the problem to be solved? • What characteristics of the entity are used to solve the problem?

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.