Intended to show that the program does what the user requires

Are we building the right product?

Intended to show that a program meets it specification.

Are we building the product right?

• Software function
• User Expectations
• Marketing Environment

• Software inspections or peer reviews - analyze system representations such as the requirements document, design diagrams and the program source coude.
• Software testing - running an implementation of the software w/ test data.

• Validation testing - intended to show that the software is what the customer wants, that it meets its requirements.
• Defect testing - intended to reveal defects in the system rather than to simulate its operational use. 

• The testing process
• Requirements traceability
• Tested items
• Testing schedule
• Test recording procedures
• Hwardware and software requirements
• Constraints

1. During testing, erros can mask (hide) other errors)
2. Incomplete versions of a system can be inspected w/o additional costs
3. As well as seraching for program defects, an inspection can also consider broader quality attributes of a program such as compliance w/ standards, portability and maintainability

• Author or owner
• Inspector
• Reader
• Scribe
• Chairman or moderator
• Chief moderator

1. You have a precise specification of the code to be inspected.
2. The inspection team members are familiar w/ the organizational standards
3. An up-to-date compilable version of the code has been distributed to all team members.

1. Planning
2. Overview
3. Individual preparation
4. Inspection meeting
5. Rework
6. Follow-up

1. About 500 source code statements per hour can be presented during the overview stage.
2. During individual preparation, about 125 source code statements per hour can be examined
3. From 90 to 125 statements per hour can be inspected during the inspection meeting

1. Control flow analysis
2. Data use analysis
3. Interface analysis
4. Information flow analysis
5. Path analysis

• Data faults
• Control faults
• I/O faults
• Interface faults
• Storage management faults

1. A formal specification of the system may be developed and mathematically analyzed for inconsistency.  This technique is effective in discovering specification errors and omissions, as discussed in Chapter 10.
2. You can formally verify, using mathematical arguments, that the code of a software system is consistent w/ its specification.  This requires a formal specification and is effective in discovering programming and some design errors.

• The specification may not reflect the real requirements of system users.
• The proof may contain errors
• The proof may assume a usage pattern which is incorrect

1. Formal specification
2. Incremental development
3. Structured programming
4. Static verification
5. Statistical testing of the system