Software Processes

Waterfall vs Incremental Process

Overview

This activity applies waterfall and incremental processes to build an arch bridge, gives students an opportunity to experience these processes first-hand, and contrasts their differences. Students will be able to see the impact of change (stemming from new requirements, and/or test failures) on a successful completion of a project. This activity can be used as both a formal introduction to software processes, and as a reinforcement mechanism to showcase the difference between the waterfall and incremental processes.

Learning outcomes

As a result of completing this activity, students will be able to:

  • Understand the principles of waterfall and incremental software processes;
  • Apply these two processes to solve a practical problem in a team setting;
  • Explain advantages and disadvantages of waterfall and incremental processes;
  • Apply the basic principles of acceptance and regression testing.

Prerequisites

  • Basic familiarity with the concept of a software process.

Timing considerations

Up to 60 minutes.

Number of participants

This activity works equally well for small and large groups, which need to broken up into teams of 3-5 participants. It is best to have several teams to create multiple bridges. This will provide better support for the learning objectives of this activity.

Logistics

Each team needs a separate building space (a large table), with or without chairs. LEGO bricks should be divided equally among all teams.

Materials and supplies

  • LEGO sets for each team:
    • Each team needs a separate set with a large number of standard (2x2, 2x3, 2x4, up to 2x8) bricks. This forces students to build smaller/simpler bridges. Suitable sets include LEGO Classic boxes, such as LEGO Classic Large Creative Brick Box 10698.
    • One sufficiently large baseplate for each team, which will serve as a foundation and would determine the river width. Suitable baseplates include 10714 or 10700.
  • The facilitator will need one or more additional sets for testing the bridges. These may include a small car, a construction vehicle, and one or two boats.
  • Handouts: images of arch bridges (see below).
  • Blank paper and pencils for each team to sketch the bridge designs.

Scenario of the activity

  1. Introduction: 5-7 minutes
    1. Present the problem: each team is building an arch bridge.
    2. Discuss the constraints
      • Use only standard bricks sized 2x2 to 2x8. Do not use any plates.
        This would force students to build smaller arches.
      • River width is given by a sufficiently wide platform (same size for each team).
      • All arches are built in parallel.
      • The bridge must be symmetric about the vertical axis going through its center.
      • There must be exactly three arches.
        The idea is that is the arches are of the same size, the large boat wouldn’t pass through. This will be revealed during testing, which would force students to build one big and two smaller arches.
      • Be economical. Do not use too many bricks, do not build thick walls/arches.
      • Show students several pictures of arch bridges of different designs. Arches can be round, square, triangular, etc.
      • If students ask about the target width of the bridge, tell them that it must be at least one brick wide. If they ask what cars will be traveling over the bridge, tell them that we don’t know yet what kind of traffic this bridge will attract (or that the vehicles are still being constructed).
  2. Build using the waterfall process: 15 minutes
    1. Specification (analysis/design): give the teams 1 minute to brainstorm and draw a design. If there are multiple teams, do not let them share their design.
    2. Development (construction): teams build the entire bridge from start to finish. Students are not allowed to deviate from their design. Time: 9 minutes.
    3. Validation (testing): test with a car (have 2 different sizes). Also, try two cars moving over the bridge in opposite directions. Also, try placing something heavy (e.g. a water bottle) on the bridge. Aim to make the bridge fail the test. It’s OK if the bridge top does not connect with the table—test if the car can move on top of the bridge, not get on the bridge.
      Mention that this testing represents how the customer understands the requirements.
    4. Evolution (deployment/feedback): debrief–ask students to explain what happened.
      It is difficult to make changes without redesigning or rebuilding the whole solution.
  3. Build using an incremental process: 15 minutes
    1. Overall specification: same as above. 1 minute. Students teams may use their old designs or create new ones. Mention that these three iterations will be required, which must be reflected in the designs:
      • Columns—the straight part of the arch (test whether a boat passes in between).
      • Rest of the arches so that they are closed (test whether a boat with a tall load passes under).
      • Surface of the bridge (test whether it’s wide enough for one or two cars to pass).
    2. Repeat iterations:
      • Specification: ask to review/update the design for the current iteration.
      • Development: teams build what’s planned for this iteration. Also fix any bugs from the previous iteration. 3 minutes for each iteration.
      • Validation: acceptance testing of the current feature + regression testing of all previous features. Use a boat (have 2 boats of different size) or two boats passing under the bridge at the same time.
        Reiterate that this represents how the customer understands the requirements.
      • Evolution: debrief – ask what happened.
        Most teams should be able to build acceptable bridges within the time constraints. The amount of necessary rework was manageable. Changing requirements were reflected by using new and previously unexpected test cases.
  4. Discussion: comparison of the two process models: 10+ minutes
    1. Start a discussion with a question: which process was better suited for building a fully functional bridge and why?
    2. The first build (waterfall) had little effect on the second build (incremental) because a different set of test cases was used.
    3. The overall amount of building time is the same. But it may seem that there was more time during the waterfall process because students didn’t have to fix any flaws from the previous iterations. The result is in the overall quality. If there are multiple teams, compare the number of accepted bridges constructed using waterfall and using the incremental process.
    4. Using different vehicles and boats for testing represented the changing requirements.
    5. Generally, since each iteration is focused on a specific aspect/functionality of the system, it is easier to focus on details. In waterfall, these details may not receive adequate attention.

Practical observations

  • Be clear about the requirements. It may be necessary to reiterate them before building the second bridge, or at least, to state that the requirements have not changed and are still the same.
  • Make sure that all team members participate in building the bridge.
  • Do not spend too much time testing each bridge. It’s easy to get lost in details and the activity would lose its momentum. Each testing phase (one in the waterfall process and three in the incremental process) should not take more than one minute per team.

Handouts

  1. Outlines of waterfall and incremental software process models;
  2. Images of different arch bridges:

Notes on scaling up/down

This is a team-based activity. It has been run successfully with various number of students ranging from five to over thirty. The vast majority of work is done by teams in parallel. The only possible bottleneck that requires the instructor’s interaction with each team is during testing. As noted above, it’s important not to linger too long with each team during the testing phases of the activity.