Step 3 -- Interview Developers
How closely did you follow process documentation? Was it produced after the fact?
How closely did you follow system documentation? Was it produced after the fact?
How did you incorporate requirement changes? Where are they documented?
What errors did you look for? How did you look for them? What did you find and fix?
How do you categorize, track, and fix problems?
Was anything not fixed? What was the basis for the decision not to fix?
Which errors are documented? Which are not?
Were there changes to documentation/procedures to avoid certain errors?
Are there procedures that users need to know which are not documented?
What models and algorithms does the system use?
Assumptions/limitations/constraints?
Typical inputs and outputs? Any inputs that can lead to problems?
Bounds checking or input checking?
Does the system produce any warning/error messages, or simply run/crash?
How much user knowledge/training is required?
Are there differences in use for beginners vs. experienced users?
During the testing process, what was output compared to (what is truth)?
Does the system use error bounds to increase confidence in the outputs?
What is the fidelity of this system perceived to be?
What DOD or commercial standards were required? Were they followed?
How clear is documentation? Was it used? Was it produced during development, or after?
The Eleven Steps In VV&A:
1. Examine Process Documentation
2. Examine System Documentation
3. Interview Developers
4. Interview Users
5. Examine Code 1 (Look For Problems)
6. Examine Code 2 (Break It)
7. Determine Truth
8. Generate Test Cases
9. Run Test Cases
10. Review Test Case Output
11. Assessment
Software Development Plan (SDP) Template
Software Configuration Management Plan (SCMP) Template
Software Quality Program Plan (SQPP) Template
Work Breakdown Structure (WBS) Template
Introduction
What And Why Of VV&A