software under development, and ultimately the customer or user of the final software product. The approaches that will be examined here are:
- Testing (Post Process): Testing is a popular though extremely limited V&V approach that encompasses dynamic execution of hard-coded software.
- Lifecycle Frameworks (In Process): Lifecycle frameworks are V&V approaches that manifest themselves as encyclopedic taxonomies of abundant software defect elimination techniques.
- Lifecycle Methodologies: Lifecycle methodologies are holistic and integrated step-by-step metrics and measurement-based approaches to V&V.
Testing (Post Process)
Testing is a popular, yet extremely limited form of V&V, which encompasses dynamic execution of hard-coded software. It is referred to as post process, because testing generally occurs at the very end of software lifecycles, usually after all resources have been exhausted, and much too late to eliminate the population of latent software defects. Testing is also the most ineffective and expensive of the three approaches discussed in this paper. Testing is considered less effective because it requires an order of magnitude more resources than lifecycle methodologies, and would take too long to eliminate the population of latent software defects.
Testing is broadly classified and divided into two categories, white box testing and black box testing. White box testing is internal or structural testing designed to examine and even dynamically exercise hard-coded software, to include these popular testing techniques:
- Flow Graph Notation (Basis Path).
- Cyclomatic Complexity (Basis Path).
- Deriving Test Cases (Basis Path).
- Graph Matrices (Basis Path).
- Condition (Control Structure).
- Dataflow (Control Structure).
- Loop (Control Structure).
Black box testing is external testing designed to analyze and exercise hard-coded software without examining its internal structure:
- Graph Based Methods (Specification).
- Equivalence Partitioning (Specification).
- Boundary Value Analysis (Specification).
- Comparison (Specification).
- Interface Misuse (Interface).
- Interface Misunderstanding (Interface).
- Timing (Interface).
- Serialization (Interface).
- Requirements (Operational).
- Scenario (Operational).
- Use (Operational).
An explanation of each of these eighteen white and black box testing techniques may be found in software engineering overview texts [2, 3]. Testing techniques are beyond the scope of this paper, as this paper is designed to illuminate life cycle methodologies, not testing.
The IEEE Standard for Software Test Documentation  describes a set of standard test documents. The purpose of this IEEE standard is to act as a test document framework, in order to introduce structure into the test process. IEEE recognizes that adding structure through framework standards is a good method to act as a basis for creating rational software testing processes. The testing techniques previously described may be captured in these documents:
- Test Plan.
- Test Design.
- Test Case.
- Test Procedure.
- Test Item Transmittal.
- Test Log.
- Test Summary.
Software can be constructed and viewed as a structured hierarchy of ever increasing granularity . Software may then be tested by starting with the lowest level of granularity, proceeding up through software system and acceptance testing:
- Unit Testing.
- Module Testing.
- Component Testing.
- Subsystem Testing.
- Integration Testing.
- System Testing.
- Acceptance Testing.
Once again, testing levels have been structured in an attempt to identify, define, and promote organized, documented, and rational testing. Structured testing processes are believed to increase the likelihood that software defects will be eliminated./p>
What does Testing Do?
According to the IEEE Standard Glossary of Software Engineering Terminology  testing may be defined in these increasing levels of granularity:
- Testing is the process of determining whether final systems or components comply with specified requirements.
- Testing is an activity in which a system or component is executed under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component.
For most software projects, software isn't produced until the end of