Argila, C A, Jones, C, Martin, J.J."Software Engineering The Electrical Engineering Handbook Ed. Richard C. Dorf Boca raton crc Press llc. 2000
Argila, C.A., Jones, C., Martin, J.J. “Software Engineering” The Electrical Engineering Handbook Ed. Richard C. Dorf Boca Raton: CRC Press LLC, 2000
90 Software engineering d Techniques Methods·Int on modelin Implementation Modeling. CASI 2 Testing, Debugging, and Verification The Origins and Causes of Software Defects. The Taxonomy and Carl A Argila Efficiency of Software Defect Removal. Pre-Test Defect Removal Software Engineering Con Testing Software. Selecting an Optimal Series of Defect Prevention and Removal Operations. Post-Release Defect Removal. Recent Capers Jones Industry Trends in Software Quality Control Software Productivity Research, Inc Analysis of Algorithms. Flow of Control. Abstraction Johannes J Martin Modularity. Simple Hierarchical Structuring. Object-Oriented University of New Orleans Programming.Program Testing 90.1 Tools and Techniquesl Carl A. argila The last decade has seen a revolution in software engineering tools and techniques. This revolution has been fueled by the ever-increasing complexity of the software component of delivered systems. Although the software component of delivered systems may not be the most expensive component, it is usually, however, "in series with the hardware component; if the software doesnt work, the hardware is useless Traditionally, software engineering has focused primarily on computer programming with ad hoc analysis and design techniques. Each software system was a unique piece of intellectual work; little emphasis was placed on architecture, interchangeability of parts, reusability, etc. These ad hoc software engineering methods resulted in the production of software systems which did not meet user requirements, were usually delivered over budget and beyond schedule, and were extraordinarily difficult to maintain and enhance. In an attempt to find some solutions to the" software crisis, "large governmental and private organizations motivated the development of so-called"waterfall"methods. These methods defined formal requirement definition and analysis phases, which had to be completed before commencing a formal design stage, which in turn had to be completed before beginning a formal implementation phase, etc. Although waterfall methods vere usually superior to ad hoc methods, large and complex software systems were still being delivered over budget and beyond schedule, which did not meet user requirements. There were several reasons for this. First, waterfall methods focus on the generation of work products rather than"engineering. Simply put, writing documents is not the same as doing good engineering. Second, the waterfall methods do not support the evolution of system requirements throughout the development life cycle. Also, the prose English specifications roduced within the waterfall methods are not well suited to describing the complex behaviors of software systems The material in this article was originally published by CRC Press in The Electrical Enginee Richard C. Dorf, Editor. 1993. c 2000 by CRC Press LLC
© 2000 by CRC Press LLC 90 Software Engineering 90.1 Tools and Techniques Approach • Methods • Information Modeling • Essential Modeling • Implementation Modeling • CASE Tools 90.2 Testing, Debugging, and Verification The Origins and Causes of Software Defects • The Taxonomy and Efficiency of Software Defect Removal • Pre-Test Defect Removal • Testing Software • Selecting an Optimal Series of Defect Prevention and Removal Operations • Post-Release Defect Removal • Recent Industry Trends in Software Quality Control 90.3 Programming Methodology Analysis of Algorithms • Flow of Control • Abstraction • Modularity • Simple Hierarchical Structuring • Object-Oriented Programming • Program Testing 90.1 Tools and Techniques1 Carl A. Argila The last decade has seen a revolution in software engineering tools and techniques. This revolution has been fueled by the ever-increasing complexity of the software component of delivered systems. Although the software component of delivered systems may not be the most expensive component, it is usually, however, “in series” with the hardware component; if the software doesn’t work, the hardware is useless. Traditionally, software engineering has focused primarily on computer programming with ad hoc analysis and design techniques. Each software system was a unique piece of intellectual work; little emphasis was placed on architecture, interchangeability of parts, reusability, etc. These ad hoc software engineering methods resulted in the production of software systems which did not meet user requirements, were usually delivered over budget and beyond schedule, and were extraordinarily difficult to maintain and enhance. In an attempt to find some solutions to the “software crisis,” large governmental and private organizations motivated the development of so-called “waterfall” methods. These methods defined formal requirement definition and analysis phases, which had to be completed before commencing a formal design stage, which in turn had to be completed before beginning a formal implementation phase, etc. Although waterfall methods were usually superior to ad hoc methods, large and complex software systems were still being delivered over budget and beyond schedule, which did not meet user requirements. There were several reasons for this. First, waterfall methods focus on the generation of work products rather than “engineering.” Simply put, writing documents is not the same as doing good engineering. Second, the waterfall methods do not support the evolution of system requirements throughout the development life cycle. Also, the prose English specifications produced within the waterfall methods are not well suited to describing the complex behaviors of software systems. 1 The material in this article was originally published by CRC Press in The Electrical Engineering Handbook, Richard C. Dorf, Editor, 1993. Carl A. Argila Software Engineering Consultant Capers Jones Software Productivity Research, Inc. Johannes J. Martin University of New Orleans
斗1! The basic, underlying philosophy of how software systems should be developed changed dramatically in 1978 when Tom DeMarco published his truly seminal book, Structured Analysis and System Specification [DeMarco, 1979]. DeMarco proposed that software systems should be developed like any large, engineering systems--by first building scale models of proposed systems so as to investigate their This model-based software engineering approach is analogous to that used by architects to specify and design large complex buildings(see Fig. 90.1). We build scale models of software systems for the same reason that architects build scale models of houses, so that users can visualize living with the systems of the future. These models serve as vehicles for communication and negotiation between users, developers, sponsors, builders, etc. Model-based software engineering holds considerable promise for enabling large, complex software systems to be developed on budget, within schedule, while meeting user requirements [see Harel, 1992] As shown in Fig. 90.2, a number of specific software development models may be built as part of the software development process. These models may be built by different communities of users, developers, customers, etc. Most importantly, however, these models are built in an iterative fashion. Although work products( documents, milestone reviews, code releases, etc )may be delivered chronologically, models are built iteratively throughout the software systems development life cycle In Fig. 90.3 we illustrate the distinction between methodology tool, and work product. A number of differing software development methods have evolved, all based on the underlying model-based philosophy. Different methods may in fact be used for the requirements and analysis phases of project development than for design and implementation. These differing methods may or may not integrate well. Tools such as CASE may support all, or only a part, of a given method. Work products, such as document production or code generation, may be generated manually or by means of Case tools This article will present a synopsis of various practical software engineering techniques which can be used to construct software development models; these techniques are illustrated within the context of a simple case udy system A h One of the most widely accepted approaches in the software engineering industry is to build two software development models. An essential model captures the behavior of a proposed software system, independent aplementation specifics. An essential model of a software system is analogous to the scale model of a house built by an architect; this model is used to negotiate the essential requirements of a system between customers and developers. A second model, an implementation model, of a software system describes the technical asv ne of a proposed system within a particular implementation environment. This model is analogous to the deta e 2000 by CRC Press LLC
© 2000 by CRC Press LLC The basic, underlying philosophy of how software systems should be developed changed dramatically in 1978 when Tom DeMarco published his truly seminal book, Structured Analysis and System Specification [DeMarco, 1979]. DeMarco proposed that software systems should be developed like any large, complex engineering systems—by first building scale models of proposed systems so as to investigate their behavior. This model-based software engineering approach is analogous to that used by architects to specify and design large complex buildings (see Fig. 90.1). We build scale models of software systems for the same reason that architects build scale models of houses, so that users can visualize living with the systems of the future. These models serve as vehicles for communication and negotiation between users, developers, sponsors, builders, etc. Model-based software engineering holds considerable promise for enabling large, complex software systems to be developed on budget, within schedule, while meeting user requirements [see Harel, 1992]. As shown in Fig. 90.2, a number of specific software development models may be built as part of the software development process. These models may be built by different communities of users, developers, customers, etc. Most importantly, however, these models are built in an iterative fashion. Although work products (documents, milestone reviews, code releases, etc.) may be delivered chronologically, models are built iteratively throughout the software system’s development life cycle. In Fig. 90.3 we illustrate the distinction between methodology, tool, and work product. A number of differing software development methods have evolved, all based on the underlying model-based philosophy. Different methods may in fact be used for the requirements and analysis phases of project development than for design and implementation. These differing methods may or may not integrate well. Tools such as CASE may support all, or only a part, of a given method. Work products, such as document production or code generation, may be generated manually or by means of CASE tools. This article will present a synopsis of various practical software engineering techniques which can be used to construct software development models; these techniques are illustrated within the context of a simple case study system. Approach One of the most widely accepted approaches in the software engineering industry is to build two software development models. An essential model captures the behavior of a proposed software system, independent of implementation specifics. An essential model of a software system is analogous to the scale model of a house built by an architect; this model is used to negotiate the essential requirements of a system between customers and developers.A second model, an implementation model, of a software system describes the technical aspects of a proposed system within a particular implementation environment. This model is analogous to the detailed FIGURE 90.1 Model-based software engineering
Work, Products, and milestones Analysis Model Design Model FIGURE 90.2 Modeling life cycle FIGURE 90.3 Methods, tools and work products blueprints created by an architect; it specifies the implementation aspects of a system to those who will do the construction. These models [described in Argila, 1992] are shown in Fig. 90.4. The essential and implementation models of a proposed software system are built in an iterative fashion Methods The techniques used to build the essential and implementation models of a proposed software system are illustrated by means of a simple case study. The Radio Button System(RBS)is a component of a fully automated, digital automobile sound system. The RBS monitors a set of front-panel station selection buttons and performs station selection functions e 2000 by CRC Press LLC
© 2000 by CRC Press LLC blueprints created by an architect; it specifies the implementation aspects of a system to those who will do the construction. These models [described in Argila, 1992] are shown in Fig. 90.4. The essential and implementation models of a proposed software system are built in an iterative fashion. Methods The techniques used to build the essential and implementation models of a proposed software system are illustrated by means of a simple case study. The Radio Button System (RBS) is a component of a fully automated, digital automobile sound system. The RBS monitors a set of front-panel station selection buttons and performs station selection functions. FIGURE 90.2 Modeling life cycle. FIGURE 90.3 Methods, tools and work products
Model erarchy o声 2… 画画) FIGURE 90.4 Software engineering methods overview. When a station selection button is momentarily depressed, the RBS causes a new station to be selected. Th selection is made on the basis of station-setting information stored within the RBS. The RBS can"memorize new station selections in the following manner: When a given station selection button is depressed longer tha momentary depressions of this button will result in this"memorized"station being selected. The RBS also performs a muting function. While a station is being selected, the rBS will cause the audio system to mute the audio output signal. The RBS will also cause the audio output signal to be muted until new station selection has been successfully memorized. The RBS interfaces with the front-panel station selection buttons by"reading a single-byte memory location Each bit position of this memory location is associated with a particular front-panel station selection button. The value of 0 in a given bit position indicates that the corresponding button is not depressed. The value of 1 in that bit position indicates that the corresponding button is depressed. For example, 0000 0000 indicates no station selection buttons are currently depressed; 0000 0010 indicates that the second button is currently resse The RBS interfaces with the tuning system by means of a common memory location. This single-byte memory location contains a non-negative integer value which represents a station selection.( For example, 0000 0000 might represent 87. 9 MHz, 0000 0001 might represent 88.1 MHz, etc. ) The RBS may "read"this memory location to"memorize"a current station selection. The RBS may also"write"to this memory location to cause the tuning system to select another station Finally, the RBS interfaces with the audio system by sending two signals. The RBS may send a MUTE-ON ignal to the audio system causing the audio system to disable the audio output. A MUTE-OFF signal would cause the audio system to enable the audio output. Information Modeling The construction of an information model is fundamental to so-called object-oriented approaches. An mation model captures a"view"of an application domain within a software system will be built Information models are based on entity-relationship diagrams and underlying textual information. A sample e 2000 by CRC Press LLC
© 2000 by CRC Press LLC When a station selection button is momentarily depressed, the RBS causes a new station to be selected. This selection is made on the basis of station-setting information stored within the RBS. The RBS can “memorize” new station selections in the following manner: When a given station selection button is depressed longer than “momentarily” (say, for more than 2 seconds), the currently selected station will be “memorized.” Future momentary depressions of this button will result in this “memorized” station being selected. The RBS also performs a muting function. While a station is being selected, the RBS will cause the audio system to mute the audio output signal. The RBS will also cause the audio output signal to be muted until a new station selection has been successfully memorized. The RBS interfaces with the front-panel station selection buttons by “reading” a single-byte memory location. Each bit position of this memory location is associated with a particular front-panel station selection button. The value of 0 in a given bit position indicates that the corresponding button is not depressed. The value of 1 in that bit position indicates that the corresponding button is depressed. (For example, 0000 0000 indicates no station selection buttons are currently depressed; 0000 0010 indicates that the second button is currently depressed, etc.) The RBS interfaces with the tuning system by means of a common memory location. This single-byte memory location contains a non-negative integer value which represents a station selection. (For example, 0000 0000 might represent 87.9 MHz, 0000 0001 might represent 88.1 MHz, etc.) The RBS may “read” this memory location to “memorize” a current station selection. The RBS may also “write” to this memory location to cause the tuning system to select another station. Finally, the RBS interfaces with the audio system by sending two signals. The RBS may send a MUTE-ON signal to the audio system causing the audio system to disable the audio output. A MUTE-OFF signal would cause the audio system to enable the audio output. Information Modeling The construction of an information model is fundamental to so-called object-oriented approaches. An information model captures a “view” of an application domain within which a software system will be built. Information models are based on entity-relationship diagrams and underlying textual information. A sample FIGURE 90.4 Software engineering methods overview