Waterfall LifeCycle

As software developers started creating larger projects, they realized that proper methods for developing code must be created. One of the early efforts was to define what steps needed to be taken to create code. Eventually, the major steps of:

  1. Analyze
  2. Design
  3. Code
  4. Test
  5. Document
  6. Release

Waterfall LifeCycle goes through the major steps of code development one at a time

were identified and, since they should be done in a specific order, the Waterfall LifeCycle was developed. The general form can be seen in the attached diagram. Soon it became obvious that each step would take too long and major errors inserted early in the process were not found until too late in the process. Modified versions of the Waterfall were tried, one of the most successful being the Spiral LifeCycle. Eventually, new processes were developed to remove as much “unneeded” work from the process as possible. When the Agile Manifesto was developed, a more streamlined Scrum Methodology started replacing the Spiral LifeCycle.

Tektronix Experience

Allowing a loopback to any phase was helpful, but allowing short waterfall projects within a larger project was essential

One of the first big corporate projects on which I worked talked about using the Waterfall LifeCycle. The Principal Engineer presented a better way of developing code. In the past, code seemed like it was instantly at least 50% completed after one tenth of the schedule duration of the project. After about one fifth of the project, the code got to 90% complete, where it stayed for the rest of the project. To have a better handle on how the project was progressing, he used a modified Waterfall that that a complete waterfall cycle for small subprojects. To this day, I have never been on a true waterfall project that has succeeded.

The group put up a large strip of butcher paper along an inside wall on the edge of our area. We then put stripes about every four weeks to indicate the end of a cycle. Then the code to be done was broken into modules that could be completed in a cycle. The code was considered either designated for a future cycle (Scrum Product Backlog), scheduled as soon as possible (Scrum Sprint Backlog), scheduled for current cycle, started, or completed. Several of the engineers on this product went on to work on Object-Oriented Programming (OOP) and the Agile development process.  We actually enjoyed organizing our tasks on the board and marking them with a highlighter when they were complete. On earlier projects, but as the agile approach (parts of which were called Extreme Programming by Ward Cunningham) was developed, it worked very well to deliver the  product on revised schedule. This success was quite influential with the engineers on the product for several future projects and for some entire careers.