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