CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 5 These,and many other questions,are a manifestation of the concern about software and how it is developed-a concern that has led to the adoption of software engineer ing practice. 1.1.1 Defining Software 叶ece are.But do the when oftware is (1)instructions (computer programs)that e ecuted provide desired res,function,and performance:(2)data structure that enabl tion;and (3)de npuve at describes the operation and use of the programs. There is no question that other more complete definitions could be offered.But a more formal definition probably won't measurably improve your understanding.To accomplish that,it's important to examine the characteristics of software that make it different from other things that human beings build.Software is a logical rather than stem ele ent Therefore softw are has one fundamental c racteristic tha ably different from ha rd ou Figure depicts failure rate as function of time for hardware.The relationship. 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 manufactur- ing defects);defects are corrected,and the failure rate drops to a steady-state level (hopefully,quite low)for some period of time.As time passes,however,the failure rate rises again as hardware components suffer from the cumulative effects of dust. FIGURE 1.1 Failure curve for hardware "Infant mortality Time
CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 5 These, and many other questions, are a manifestation of the concern about software and how it is developed—a concern that has led to the adoption of software engineering practice. 1.1.1 Defining Software 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 features, function, and performance; (2) data structures that enable the programs to adequately manipulate information; and (3) descriptive information in both hard copy and virtual forms that describes the operation and use of the programs. There is no question that other more complete definitions could be offered. But a more formal definition probably won’t measurably improve your understanding. To accomplish that, it’s important to examine the characteristics of software that make it different from other things that human beings build. Software is a logical rather than a physical system element. Therefore, software has one fundamental characteristic that makes it considerably different from hardware: Software doesn’t “wear out.” Figure 1.1 depicts failure rate as a function of time for hardware. The relationship, often called the “bathtub curve,” indicates that hardware exhibits relatively high failure rates early in its life (these failures are often attributable to design or manufacturing defects); defects are corrected, and the failure rate drops to a steady-state level (hopefully, quite low) for some period of time. As time passes, however, the failure rate rises again as hardware components suffer from the cumulative effects of dust, Figure 1.1 "Wear out" Time Failure rate "Infant mortality" Failure curve for hardware
6 CHAPTER L SOFTWARE AND SOFTWARE ENGINEERING FIGURE 1.2 Failure curves for software dealized curve Time vibration,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 theife of aprogram.However.these are and the curve as sho wn.The idealized lification of actual fail soware.However.the impliction is cear software doesn't wear out But it does deteriorate This seeming contradiction can best be explained by considering the actual curve in Figure 1.2.During its life,software will undergo change.As changes are made,it is likely that errors will be introduced,causing the failure rate curve to spike as shown in the "actual curve"(Figure 1.2).Before the curve can return to the o riginal steadv state failure rate othe Ch. ng the aga 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 ogwhich destranslaed t machine executab code ere nce at mmodate requests for change involve cons erably more complexity than hardware maintenance 3 In fact.from the moment that development begin sand long before the first version is deliv ered,changes may be requested by a variety different stakeh
6 CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING vibration, 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 and the curve flattens as shown. The idealized curve is a gross oversimplification of actual failure models 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 in Figure 1.2. During its life,3 software will undergo change. As changes are made, it is likely that errors will be introduced, causing the failure rate curve to spike as shown in the “actual curve” (Figure 1.2). Before the curve can return to the original steadystate 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. Therefore, the software maintenance tasks that accommodate requests for change involve considerably more complexity than hardware maintenance. Figure 1.2 Increased failure rate due to side eects Actual curve Idealized curve Time Failure rate Change 3 In fact, from the moment that development begins and long before the first version is delivered, changes may be requested by a variety of different stakeholders. Failure curves for software
CHAPTER L SOFTWARE AND SOFTWARE ENGINEERING 1.1.2 Software Application Domains Today,seven broad categories of computer software present continuing challenges for software engineers: System software.A of programswritten to service other programs. Some system software (e.g.,compilers,editors,and file management utilities)pro- cesses complex,but determinate,"information structures.Other systems applications (e.g.operating system components,drivers,networking software,telecommuni- cations processors)process largely indeterminate data. Application software.Stand-alone programs that solve a specific business need. Applications in this area process business or technical data in a way that facilitates business operations or management/technical decision making. Engineering/scientifie software.A broad array of"number-crunching"or data science programs that range from astronomy to volcanology,from automotive stress analysis to orbital dynamics,from computer-aided design to consumer spending habits,and from genetic analysis to meteorology. Embedded software.Resides within a product or system and is used to implement and control features and functions for the end user and for the system itself.Embedded software can perform limited and esoteric functions (e.g.,key pad control for a micro- Product-line software.Composed of reusable components and designed to ovide specific capabilities for use by many different customers.It may focus toaddress the mass consumer market Web/mobile applications.This network-centric software category spans a wide obile devices Artificial intelligence software.Makes use of heuristics'to solve complex prob- lems that are not amenable to regular computation or straightforward analysis. Application 一2odao网02 pu) within this area in lude robotics decision-making ttern rec Millions of software engineers worldwide are hard at work on software projects in one or more of these categories.In some cases.new systems are being built.but in many others,existing applications are being corrected,adapted,and enhanced.It is not uncommon for a young software engineer to work on a program that is older thar she is!Past generations of software people have left a we have disc ssed.Hopeful y,the legacy to be left behind by this generation will ease the burden on future software engineers. 4 Software is determinate if the order and timing of inputs,processing.and outputs is predict- able.Software is indeterminate if the order and timing of inputs,processing.and outputs cannot be predicted in advance. The use of heuristics is an approach to problem solving that employs a practical method or "rule of thumb"not guaranteed to be perfect,but sufficient for the task at hand
CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 7 1.1.2 Software Application Domains Today, seven broad categories of computer software present continuing challenges for software engineers: System software. A collection of programs written to service other programs. Some system software (e.g., compilers, editors, and file management utilities) processes complex, but determinate,4 information structures. Other systems applications (e.g., operating system components, drivers, networking software, telecommunications processors) process largely indeterminate data. Application software. Stand-alone programs that solve a specific business need. Applications in this area process business or technical data in a way that facilitates business operations or management/technical decision making. Engineering/scientific software. A broad array of “number-crunching” or data science programs that range from astronomy to volcanology, from automotive stress analysis to orbital dynamics, from computer-aided design to consumer spending habits, and from genetic analysis to meteorology. Embedded software. Resides within a product or system and is used to implement and control features and functions for the end user and for the system itself. Embedded software can perform limited and esoteric functions (e.g., key pad control for a microwave oven) or provide significant function and control capability (e.g., digital functions in an automobile such as fuel control, dashboard displays, and braking systems). Product-line software. Composed of reusable components and designed to provide specific capabilities for use by many different customers. It may focus on a limited and esoteric marketplace (e.g., inventory control products) or attempt to address the mass consumer market. Web/mobile applications. This network-centric software category spans a wide array of applications and encompasses browser-based apps, cloud computing, service-based computing, and software that resides on mobile devices. Artificial intelligence software. Makes use of heuristics5 to solve complex problems that are not amenable to regular computation or straightforward analysis. Applications within this area include robotics, decision-making systems, pattern recognition (image and voice), machine learning, theorem proving, and game playing. Millions of software engineers worldwide are hard at work on software projects in one or more of these categories. In some cases, new systems are being built, but in many others, existing applications are being corrected, adapted, and enhanced. It is not uncommon for a young software engineer to work on a program that is older than she is! Past generations of software people have left a legacy in each of the categories we have discussed. Hopefully, the legacy to be left behind by this generation will ease the burden on future software engineers. 4 Software is determinate if the order and timing of inputs, processing, and outputs is predictable. Software is indeterminate if the order and timing of inputs, processing, and outputs cannot be predicted in advance. 5 The use of heuristics is an approach to problem solving that employs a practical method or “rule of thumb” not guaranteed to be perfect, but sufficient for the task at hand
CHAPTER I SOFTWARE AND SOFTWARE ENGINEERING 1.1.3 Legacy Software Hundreds of thousands of computer programs fall into one of the seven broad appli cation domains discussed in the preceding subsection.Some of these are state-of-the- art software.But other programs are older,in some cases much older. These older programs-often referred to as legacy software-have been the focus of continuous att ntion and concern since the 1960s.Dayani-Fard and his colleague [Day99]describe legacy software in the following way systems were developed decade anges in b een continually large organizations who find them c0sy0ma These changes may create an additional side effect that is often present in legacy software-poor qualify.Legacy systems sometimes have inextensible designs,convoluted code,poor or nonexistent documentation,test cases and results that were never archived, and a poorly managed change history.The list can be quite long.And yet,these systems ort"core functions and are indispensable to the business."What to do? rea ma y be:Do nothing,at least until the legacy must unde ergo sor nge.If the legacy softwa are meets the eeds of its users and runs reliably,it isn't broken and does not need to be fixed.However,as time passes,legacy systems often evolve for one or more of the following reasons: The software must be adapted to meet the needs of new computing environ- ments or technology The software must be enhanced to implement new business requirements The software must be extended to make it work with other more moderr systems or databases The software must be re-architected to make it viable within an evolving computing environment When these modes of evolution occur.a legacy system must be reengineered so that it remains viable in the future.The goal of modern software engineering is to "devise methodologies that are founded on the notion of evolution:that is,the notion that software systems change continually,new software systems can be built from the old ones,and.all must interact and cooperate with each other"[Day99]. 1.2 DEFINING THE DISCIPLINE The IEEE [IEE17]has developed the following definition for software engineering approach to the ring t 6 In this case have been en well understood at the time that the legacy softw
8 CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 1.1.3 Legacy Software Hundreds of thousands of computer programs fall into one of the seven broad application domains discussed in the preceding subsection. Some of these are state-of-theart software. But other programs are older, in some cases much older. These older programs—often referred to as legacy software—have been the focus of continuous attention and concern since the 1960s. Dayani-Fard and his colleagues [Day99] describe legacy software in the following way: Legacy software systems . . . were developed decades ago and have been continually modified to meet changes in business requirements and computing platforms. The proliferation of such systems is causing headaches for large organizations who find them costly to maintain and risky to evolve. These changes may create an additional side effect that is often present in legacy software—poor quality. 6 Legacy systems sometimes have inextensible designs, convoluted code, poor or nonexistent documentation, test cases and results that were never archived, and a poorly managed change history. The list can be quite long. And yet, these systems often support “core functions and are indispensable to the business.” What to do? The only reasonable answer may be: Do nothing, at least until the legacy system must undergo some significant change. If the legacy software meets the needs of its users and runs reliably, it isn’t broken and does not need to be fixed. However, as time passes, legacy systems often evolve for one or more of the following reasons: ∙ The software must be adapted to meet the needs of new computing environments or technology. ∙ The software must be enhanced to implement new business requirements. ∙ The software must be extended to make it work with other more modern systems or databases. ∙ The software must be re-architected to make it viable within an evolving computing environment. When these modes of evolution occur, a legacy system must be reengineered so that it remains viable in the future. The goal of modern software engineering is to “devise methodologies that are founded on the notion of evolution; that is, the notion that software systems change continually, new software systems can be built from the old ones, and . . . all must interact and cooperate with each other” [Day99]. 1.2 De f i n i ng t h e Di s c i pli n e The IEEE [IEE17] has developed the following definition for software engineering: Software Engineering: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. 6 In this case, quality is judged based on modern software engineering thinking—a somewhat unfair criterion since some modern software engineering concepts and principles may not have been well understood at the time that the legacy software was developed
CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING FIGURE 1.3 Software engineering Tools layers Methods Process A quality focus roach applied by one e need discipline,but we also need adaptability and agility Software engineering is a layered technology.Referring to Figure 1.3.any engi- neering approach (including software engineering)must rest on an organizational commitment to quality.You may have heard of total quality management(TQM)or Six Sigma,and similar philosophies'that foster a culture of continuous process provement.It is this culture that ultimately leads to nore effective approaches to software engineering.The bedrock that supports software engineering is a quality The foundation for software engineering is the process laver.The software engi- neering process is the glue that holds the technology layers together and enables rational and timely development of computer software.Process defines a framework that must be established for effective delivery of software engineering technology.The ess forms the basis for r are s hes the ext in which tec work prod quality is ensured,and change is properly managed. Software engineering methods provide the technical how-to's for building software. Methods encompass a broad array of tasks that include communication,requirements analysis,design modeling.program construction,testing,and support.Software engi- neering g methods rely on a set of basic principles that area of the techn other des scriptive technique Software engineering tools provide automated or semi-automated support for the 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. 1.3 THE SOFTWARE PROCESS A process is a collection of activities,actions,and tasks that are performed when some work product is to be ivity strive to achi eve pad objec (e.g.commun on of the applica domain,size of the project,complexity of the effort,or degree of rigor with which 7 Quality management and related approaches are discussed throughout Part Three of this book
CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 9 And yet, a “systematic, disciplined, and quantifiable” approach applied by one software team may be burdensome to another. We need discipline, but we also need adaptability and agility. Software engineering is a layered technology. Referring to Figure 1.3, any engineering approach (including software engineering) must rest on an organizational commitment to quality. You may have heard of total quality management (TQM) or Six Sigma, and similar philosophies7 that foster a culture of continuous process improvement. It is this culture that ultimately leads to more effective approaches to software engineering. The bedrock that supports software engineering is a quality focus. The foundation for software engineering is the process layer. The software engineering process is the glue that holds the technology layers together and enables rational and timely development of computer software. Process defines a framework that must be established for effective delivery of software engineering technology. The software process forms the basis for management control of software projects and establishes the context in which technical methods are applied, work products (models, documents, data, reports, forms, etc.) are produced, milestones are established, quality is ensured, and change is properly managed. Software engineering methods provide the technical how-to’s for building software. Methods encompass a broad array of tasks that include communication, requirements analysis, design modeling, program construction, testing, and support. Software engineering methods rely on a set of basic principles that govern each area of the technology and include modeling activities and other descriptive techniques. Software engineering tools provide automated or semi-automated support for the 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. 1.3 Th e So f t wa r e Pro c e s s A process is a collection of activities, actions, and tasks that are performed when some work product is to be created. An activity strives to achieve a broad objective (e.g., communication with stakeholders) and is applied regardless of the application domain, size of the project, complexity of the effort, or degree of rigor with which 7 Quality management and related approaches are discussed throughout Part Three of this book. Figure 1.3 Tools Methods Process A quality focus Software engineering layers