The best known process model
- dates from 1970’s
- though widely derided, it remains widely used
  - and its terminology forms the basis for almost all discussions of other SDPMs
Defining characteristic: movement from phase to phase is always forward (downhill), irreversible
Milestones are set at each phase transition
- schedule deadlines
- required reports
- required approval to move on

3.1 Verification & Validation

Verification & Validation: assuring that a software system meets the users’ needs.

The principle objectives are:

The discovery of defects in a system
The assessment of whether or not the system is usable in an operational situation.

3.1.1 What’s the Difference?

Verification:

3.1.1 What’s the Difference?

Verification:

“Are we building the product right” (Boehm)

3.1.1 What’s the Difference?

Verification:

“Are we building the product right” (Boehm)
The software should conform to its (most recent) specification

3.1.1 What’s the Difference?

Verification:

“Are we building the product right” (Boehm)
The software should conform to its (most recent) specification

Validation:

3.1.1 What’s the Difference?

Verification:

“Are we building the product right” (Boehm)
The software should conform to its (most recent) specification

Validation:

“Are we building the right product”

3.1.1 What’s the Difference?

Verification:
- “Are we building the product right” (Boehm)
- The software should conform to its (most recent) specification
Validation:
- “Are we building the right product”
- The software should do what the user really requires

Testing

Testing is the act of executing a program with selected data to uncover bugs.

As opposed to debugging, which is the process of finding the faulty code responsible for failed tests.

Testing is the most common, but not the only form of V&V

3.2 Testing throughout the Waterfall

3.2.1 Testing stages

3.2 Testing throughout the Waterfall

3.2.1 Testing stages

Unit Test: Tests of individual subroutines and modules,

3.2 Testing throughout the Waterfall

3.2.1 Testing stages

Unit Test: Tests of individual subroutines and modules,

usually conducted by the programmer.

3.2 Testing throughout the Waterfall

3.2.1 Testing stages

Unit Test: Tests of individual subroutines and modules,

usually conducted by the programmer.

Integration Test: Tests of “subtrees” of the total project hierarchy chart (groups of subroutines calling each other).

3.2 Testing throughout the Waterfall

3.2.1 Testing stages

Unit Test: Tests of individual subroutines and modules,

usually conducted by the programmer.

Integration Test: Tests of “subtrees” of the total project hierarchy chart (groups of subroutines calling each other).

generally a team responsibility.

3.2 Testing throughout the Waterfall

3.2.1 Testing stages

Unit Test: Tests of individual subroutines and modules,

usually conducted by the programmer.

Integration Test: Tests of “subtrees” of the total project hierarchy chart (groups of subroutines calling each other).

generally a team responsibility.

System Test: Test of the entire system,

3.2 Testing throughout the Waterfall

3.2.1 Testing stages

Unit Test: Tests of individual subroutines and modules,

usually conducted by the programmer.

Integration Test: Tests of “subtrees” of the total project hierarchy chart (groups of subroutines calling each other).

generally a team responsibility.

System Test: Test of the entire system,

supervised by team leaders or by V&V specialists.

3.2 Testing throughout the Waterfall

3.2.1 Testing stages

Unit Test: Tests of individual subroutines and modules,

usually conducted by the programmer.

Integration Test: Tests of “subtrees” of the total project hierarchy chart (groups of subroutines calling each other).

generally a team responsibility.

System Test: Test of the entire system,

supervised by team leaders or by V&V specialists.
Many companies have independent teams for this purpose.

3.2 Testing throughout the Waterfall

3.2.1 Testing stages

Unit Test: Tests of individual subroutines and modules,

usually conducted by the programmer.

Integration Test: Tests of “subtrees” of the total project hierarchy chart (groups of subroutines calling each other).

generally a team responsibility.

System Test: Test of the entire system,

supervised by team leaders or by V&V specialists.
Many companies have independent teams for this purpose.

Regression Test: Unit/Integration/System tests that are repeated after a change has been made to the code.

3.2 Testing throughout the Waterfall

3.2.1 Testing stages

Unit Test: Tests of individual subroutines and modules,
- usually conducted by the programmer.
Integration Test: Tests of “subtrees” of the total project hierarchy chart (groups of subroutines calling each other).
- generally a team responsibility.
System Test: Test of the entire system,
- supervised by team leaders or by V&V specialists.
- Many companies have independent teams for this purpose.
Regression Test: Unit/Integration/System tests that are repeated after a change has been made to the code.
Acceptance Test: A test conducted by the customers or their representatives to decide whether to purchase/accept a developed system.

3.2.2 Not just in one phase

Although the waterfall model shows V&V as a separate phase near the end, we know that some forms of V&V occur much earlier.

Requirements are validated in consultation with the customers.
Unit testing occurs during Implementation, etc.

So this phase of the waterfall model really describes system and acceptance testing.

A Still-broader View

Even the “V&V V” does not capture the full context of V&V:

Requirements must be validated

Designs may be validated & verified

Maintenence changes are tested

3.3 Advantages of Waterfall

Linear structure is easy to understand
Development progress is easily estimated and explicitly documented
Widely known
Scales well

3.4 Disadvantages of Waterfall

Inflexible: corrections limited to current phase
In some projects, requirements are not known or understood early in the life-cycle
Working version of system is only available near the end
Often becomes a documentation mill

4 Iterative/Incremental Development

A variety of related approaches
- a counter-reaction to what many believe to be an overly rigid, management-focused, waterfall model
emphasize quick cycles of development, usually with earlier and more user-oriented validation
Requirements specification, design and implementation are interleaved.
Each version adds a small amount of additional functionality.

Iterative versus Incremental Models

Iterative – we do some set of process steps repeatedly.

To use a programming analogy, this is iterative:

while (!done) {
   ⋮
}

Iterative versus Incremental Models

Iterative – we do some set of process steps repeatedly.

To use a programming analogy, this is iterative:

while (!done) {
   ⋮
}

Incremental – we accumulate value in small steps.

To use a programming analogy, this is incremental:

total += x;

Incremental development is almost always iterative, but you can be iterative without being incremental.

Variations

Some projects employ throw-away prototyping, versions whose code is only used to demonstrate and evaluate possibilities.

This can lead to insight into poorly understood requirements.

Evolutionary prototyping keeps the prototypes, gradually evolving them into the final deliverable

Some waterfall projects may employ incremental schemes for parts of large systems (e.g., the user interface).

4.1 Advantages

Ability to explore poorly understood requirements

Flexibility

Working implementation is available early.

4.2 Disadvantages

Poor process visibility (e.g., are we on schedule?),

Continual small drifts from the main architecture leading to poorly structured systems.

Dead-ends (the local optimization problem)

5 The Spiral Model