Step 5 -- Examine Code 1 (Look for Problems)


  • Divide code into modules, examine each one
  • Modular/structured
  • Object-oriented (information hiding, no global variables �)
  • In-code documentation? How clear is it?
  • In-code test case descriptions?

  • Run code through complexity analyzer (such as McCabe)

  • Look for problems within each module (but not limited to):
  • Divide by zero
  • Logarithm of zero or negative
  • Underflow
  • Overflow
  • Array bounds exceeded
  • Variables not initialized
  • Inputs

  • Does it actually use the algorithms it claims to use?
  • Document as-built?
  • Document as-planned?

  • 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?

  • Does the system use error bounds to increase confidence in the outputs?

  • What is the fidelity of this system perceived to be?

  • Certain languages more prone than others to errors
  • C++ pointers
  • C++ lack of initialization settings in compiler


    • 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