The complete lifecycle guide to preventing and eliminating object-oriented software defects.
This is the first systematic guide to defect identification, correction, and prevention in object-oriented software development projects. Houman Younessi covers every aspect of defect reduction, going far beyond testing to cover key aspects of the software development process, from planning through software delivery. Best of all, Younessi provides hands-on templates, checklists, and other productivity tools you can use to start improving software qualityright now.
Younessi's techniques are entirely compatible with today's leading tools, notation schemes, languages, and methodologies, including the UML modeling standard, and both the RUP (Rational Unified Process) and OPEN models. No matter how large your projects are, Object-Oriented Defect Management of Software is your start-to-finish framework for maximizing robustness, reliability, and maintainability.
1. Setting the Scene.
Software, Software Engineering, and the Software Engineering Process. A Constructive Approach to Software Engineering. The Process of Constructing Software. Object Orientation. Understanding the Object Paradigm. Defect Management. Specifying Quality. Views of Quality. Internal Quality and External Quality: Form Complements Function. Software Product Quality Attributes. External Quality Attributes. Customer-Oriented Quality Assessment. Assessing Product Quality. Defect Management as a Means of Ensuring Quality. Achieving Quality Goals. Product Focus. The Link Between Product and Process. Process Focus. Recent Developments. Conclusion.
Why Does Object Orientation Present Challenges in Defect Management? Abstraction. Encapsulation. Genericity. Inheritance. Multiple Inheritance. Polymorphism. Systemic Issues. Managing Defects. Opportunities for Defect Management. Defect Management Levels. Conclusion.
The Requirements Process Component. Comprehension of the Essence and Context of the ProblemúSituation or Issue at Hand. Elicitation of User Requirements. Specify Quality and Acceptance Goals. Analysis of User Requirements. Reconciliation of Requirements. Documentation of User Requirements. Requirements Narration. Usecases. The Requirements Document. The Requirements Document Set. Conclusion.
Examining Conformance to Standards. Model Validation. Informal Model Evaluation. Class, Responsibility, Collaborator (CRC) Approach. Formal Model Validation. Requirements Document Inspection. Conclusion.
Software Design. Design for Functionality. Design for Reliability. Design for Usability. Design for Maintainability. Design for Process Efficiency. Basic Elements of Good Design. Cohesion: A Measure for Modularity. Coherence: Another Measure for Modularity. Coupling: Another Measure for Minimality of Interaction and for Segregation. Achieving Segregation. Achieving Abstraction. Achieving Multiple Levels of Granularity. Achieving Formality. Achieving Anticipation of Invalid States (Exception Handling). Achieving Redundancy. Achieving Genericity. Architecture. Distribution: Distributed Topology. Architectural Design Styles. Styles of Control. Solving Specific Architectural Problems. Basic Steps for Architectural Design. Design Reviews. Architectural (System) Design Documentation. Object Design. Conclusion.
Design Defects. Identifying Defects in Design. Design Simulation. Design Inspection. Inspecting Design Artifacts. Class Diagram. Sequence Diagrams. Collaboration Diagrams. State Diagrams. Activity Diagram. Transformational Description. Module or Package Diagram. Implementation or Component Diagram. Deployment Diagrams. Identifying Defects in a Design. Document. Conclusion.
Defect Indentification Techniques. Evaluation. Education and Examination of Alternatives. Defect Identification. Comparing Inspection and Testing (Failure Detection). Inspecting Object-Oriented Code. Failure Detection-Oriented Defect Removal. Testing Object-Oriented Code. Conclusion.
Testing Base Classes. Testing for Correct Generation of Instances. Testing for Correct Attribute Values. Testing if Routines Correctly Alter the Representation of the Corresponding Object. Assertion-Based Testing of a Class. Class Invariants and Assertions at the Class Level. Constraint-Based or Assertion Constraint Coverage-Based Testing. Modal Testing of a Class. State Invariants. Modal Testing. Transformational Testing of Methods. Partitioning or Subdomain Testing. A Comparison of the Effectiveness of Subdomain-Based and Statistically Based Approaches. Conclusion.
Components and Integration. Component Interaction. Integration Strategies. Integration Testing Techniques. Scenario Testing. Modal Testing. System Testing. Usecase-Based Testing. System Temporal Boundary Testing. Performance and Load Testing. Usability Testing. System Acceptance. Beta Testing. Identify a Purpose for Beta Testing. Select Your Site Carefully. Decide What to Do Next. Conclusion.
1. Inspection Process Script. Script I-2X Inspection Process Scripts. Author's or Author's Proxy's Task Scripts. Moderator's Task Scripts. Reader's Task Scripts. Scribe's Task Scripts. Other Inspector's Task Scripts. Script I-1 Definitions. Script I-6 Moderator's Inspection Meeting Agenda. Script I-2S Specification Inspection Process Script. Script I-2D Design Inspection Process Script. Script I-2C Code Inspection Process Script. Script I7-S Specification Inspection Checklist. Script I7-D Design Inspection Checklist. Script I7-C Code Inspection Checklist.
If you selected this book to learn more about testing of object-oriented programs, you are about to get more than you bargained for. As the title implies, this book discusses defect management of object-oriented software systems. This latter activity goes beyond merely testing object-oriented code in many respects.
First, we will be discussing defect management, of which testing is only one type. Defects can potentially be injected into our software systems at any stage of the software process. If left unchecked and undiscovered, they would manifest themselves as errors or "bugs" when the final executable is set into operation. Testingexercising the executable in the hopes of making it failcan uncover many of these defects. However, there are other techniques that do not require the executable code to be available and instead rely on examining various artifacts of the process. We could call these static techniques to contrast with the former, which we might call dynamic. In this book, I discuss in detail both the static and the dynamic approaches to defect management.
Second, testing is the removal of defects at the last, or nearly last, available opportunity before the product is to be used. It can thus be argued that taking an approach based on testing of code alone, a strictly corrective approach, is
contrary to the very axiom of software engineering. We also need preventive approaches. Software engineeringin its entiretycan in fact be viewed as the process of managing defects in a software product. This claim may sound controversial at first, but in reality it is not so at all. Look at it this way: Any activity we perform as part of our software process is targeted toward either preventing defects from being included in our product or identifying and removing of those that have been already introduced. This in turn implies that defect management techniques are not uniquely applied to code, but can also be employed in relation to every activity of the software engineering process. In this book, I cover defect management techniques relevant to all stages of the software engineering process and not just techniques that deal with code. Additionally, both the corrective and preventive approaches are considered.
Third, this book is about managing defects in an object-oriented environment. This does not mean, however, that all defect management techniques that are introduced in this book are exclusive to object orientation. Conversely, however, every technique I cover is useful in an object-oriented context, although it may not have been originally developed for that domain.
Finally, given the recent ascent of the Unified Modeling Language (UML) and the Rational Unified Proces (RUP) to the level of having been accepted as standard means of modeling and conducting an object-oriented process respectively, we have made every attempt to be compatible with both when logically possible.
Given these characteristics, this book might be used in many fashions. It is targeted to professional software engineers, researchers in object technology and in defect management, and postgraduate students in software engineering. It may be used as a textbook for an advanced course (masters and Ph.D. level) in object-oriented defect management or as supporting material for advanced courses in object-oriented software engineering. It may also be used as training material in a professional industry-based course in object-oriented defect management.