Waterfall Process vs. Incremental Process
|Course:||BUS206: Management Information Systems|
|Book:||Waterfall Process vs. Incremental Process|
|Printed by:||Guest user|
|Date:||Wednesday, December 6, 2023, 2:37 AM|
Read this article, which compares the two broad processes for developing software. Then, select one of the methodologies (SDLC, RAD, Agile, Lean) you read about in Chapter 10 and do further research on the state of the art for that particular methodology. Write a four-six paragraph essay that describes the methodology you chose, your research findings, and the types of projects that use that methodology.
Table of contents
- Foundation Series: Software Process (Waterfall Process versus Incremental Process)
- Different process styles are like different dance styles.
- Waterfall process
- Incremental process
- Which process is best?
- Budgeting and planning (winner: waterfall process)
- Return on investment (ROI) (winner: incremental process)
- Delivering a subset of functionality (winner: it depends)
Foundation Series: Software Process (Waterfall Process versus Incremental Process)
A software process is the set of activities required to create software. This process can be defined with very precise steps, roles and responsibilities. The process can also be defined with a more fluid set activities in pursuit of concrete, high level objectives. Or software can be created without explicitly defining or following any process at all. The steps are always present, even if not conciously managed or defined.
A common framework is needed to compare processes and their merits. All software development includes the following three steps in some combination:
- Decide what to do.
- Do it.
- Deliver it.
It sounds like an overly simplified list; Decide, Develop, Deliver. We'll see that it isn't.
Source: Tyner Blain, http://tynerblain.com/blog/2006/01/03/foundation-series-software-process-waterfall-process-versus-incremental-process/
This work is licensed under a Creative Commons Attribution 4.0 License.
Different process styles are like different dance styles.
Different processes will put different levels of emphasis and effort into each step. Each processes may repeat steps, or take them in a different order.
We can think of each different process as a different style of dance. They are alike and unalike. There are people who prefer one style to another, and there are specialists in one style and generalists across styles.
For any particular song, some styles of dance are intuitive and comfortable while others are awkward. The same is true of applying a software process to a given development scenario.
What works for a global team on a multi-year enterprise software project may not work well for a start-up creating a consumer website. The process that works best for an engineering firm developing embedded software for a pace maker may be a nightmare to apply to an open-source project for creating an RSS reader.
Software processes are usually categorized as waterfall or iterative – although I first heard these categories from proponents of iterative processes (the "new" way) when they were getting a lot of press in the late 90's. Bias aside, the analogy works.
A waterfall process is one where all of the work is done by the team, and when it is complete, it is delivered to their customer(s). With a waterfall, the water doesn't do anything useful until after it falls off the end of the cliff – and by then it's too late to climb out of the barrel if you change your mind. You don't know if you'll hit a rock until you reach the bottom of the waterfall. The larger the waterfall, the larger the risk, and the bigger the mess if you do hit a rock.
The same is true for waterfall software processes – we decide what to do, we develop the solution, and then we deliver it. We don't revisit our decisions. Once the decisions are made, we're in the barrel and falling, and we won't know if our software will succeed until after we deliver it. The risk of failure is proportional to the amount of money and time spent before delivering the software to our customer.
An incremental process is one where we will deliver portions of the software in the smallest reasonable subsets of the ultimate functionality. We will have multiple deliveries to our customer. We will revisit the assumptions and prioritizations for each "next" delivery when we complete each "previous" delivery.
A sailing analogy works well for this approach. To sail in a straight line from start to finish, we set a heading, H1, and begin sailing. After a period of time, we check to see where we are (invariably, we've drifted off course a little), correct our course and set a new heading, H2, and continue sailing. We keep doing this (checking position, adjusting heading, sailing some more) incrementally until we reach our destination.
With incremental software development, we do the same thing as when sailing. First we decide on what to do and what to do first. Then we develop and deliver the first set of functionality. We then revisit our decisions (including getting feedback on what we've just delivered) and decide what to do next. We then develop and deliver the next set of functionality. We repeat until all of the desired functionality has been delivered.
Which process is best?
Picking the best process, like picking the best dance depends on circumstances. Let's look at a few "real world" factors that can drive our decisions.