Software Development Methodologies - an Overview
Software Development Methodologies
Waterfall Approach vs. Iterative Approach (Extreme Programming)
Waterfall Approach
Defined Phases
Multiple Hand-offs
The approach of a waterfall project is much like an assembly line. There is often a person primarily responsible for completing each phase in the project. At the end of their phase, the person is responsible for delivering documentation that will enable the next person on the line to complete their task.
Single large implementation
Due to the fact that a long time is dedicated to each of the phases, no product can be delivered until it is ready. The entire problem is evaluated before it is coded. Everything is coded before it is tested, and finally, everything is tested before it is implemented. This often results in a long time spent before any business benefit is realized.
This point is one of the primary reasons for an iterative approach such as Extreme Programming.
Extreme Programming (Iterative Approach)
Short Iterations
Rapid Feedback
As requirements are gathered by the analyst, tasks are quickly given to developers. This allows the analyst and subject matter expert to test that the function satisfies the requirement as well as give immediate feedback to the developers. This is done over and over in short (one to four week) iterations until enough needs have been met to gain a benefit, at which time the system is put into production. After an initial release to production, the project may continue to add more functionality (and business benefit) through additional iterations.
Assume Simplicity
Another tenant of this approach is that it is better to do a simple thing today and pay a little more tomorrow to change it (if necessary), than to do a more complicated thing today that may never be used anyway.
Incremental Change with Continuous Testing
Within each iteration, testing (both unit testing and integration testing) is done constantly, thereby building a system that “always works” and becomes incrementally better over time as changes are made and functionality is added.
Integrated Team
Subject matter experts, analysts, developers, and project management all work together through the journey of defining the system. Roadblocks present themselves up front, instead of late in the game, allowing everyone to work through them together. Developers offer constructive feedback to the subject matter experts and the team works together toward the best mutual solution.
Multiple Implementations
Since development is ongoing, tangible software is being built constantly. This allows the team to prioritize and deliver functions to satisfy those requirements that will deliver the most business benefit as soon as possible, shortening time to market.
Which approach is better?
Waterfall Approach Advantages
Waterfall Approach Disadvantages
Iterative Approach Advantages
Iterative Approach Disadvantages
The wrong path can be taken for either approach
Results will vary based on the people and the project
Talented people can make a bad methodology work and unskilled people can fail with a great methodology. You are not guaranteed to succeed just by implementing any particular methodology over another. The biggest barrier to the success of a methodology is often the culture. If a customer or manager insists on a complete specification before they begin any programming, then there is bound to be friction when attempting to implement an iterative approach. The bottom line is that if the people don’t believe in a given methodology, it is bound to fail.
Waterfall Approach vs. Iterative Approach (Extreme Programming)
Waterfall Approach
- Defined Phases existing in a linear order
- Multiple Hand-offs
- Single large implementation
Defined Phases
- Needs Analysis: Why must the project be undertaken (the business need)?
- Requirements Analysis: What must the system do satisfy the needs?
- Design: How will the system be written to do what it needs to do?
- Development: Writing the code to meet the design.
- Testing: Ensuring that the system does what it should.
- Implementation: Go-live, training, and support.
Multiple Hand-offs
The approach of a waterfall project is much like an assembly line. There is often a person primarily responsible for completing each phase in the project. At the end of their phase, the person is responsible for delivering documentation that will enable the next person on the line to complete their task.
Single large implementation
Due to the fact that a long time is dedicated to each of the phases, no product can be delivered until it is ready. The entire problem is evaluated before it is coded. Everything is coded before it is tested, and finally, everything is tested before it is implemented. This often results in a long time spent before any business benefit is realized.
This point is one of the primary reasons for an iterative approach such as Extreme Programming.
Extreme Programming (Iterative Approach)
- Short iterations (design by prototyping)
- Integrated team with analysts, architects, developers, and testers all working simultaneously.
- Multiple implementations
Short Iterations
Rapid Feedback
As requirements are gathered by the analyst, tasks are quickly given to developers. This allows the analyst and subject matter expert to test that the function satisfies the requirement as well as give immediate feedback to the developers. This is done over and over in short (one to four week) iterations until enough needs have been met to gain a benefit, at which time the system is put into production. After an initial release to production, the project may continue to add more functionality (and business benefit) through additional iterations.
Assume Simplicity
Another tenant of this approach is that it is better to do a simple thing today and pay a little more tomorrow to change it (if necessary), than to do a more complicated thing today that may never be used anyway.
Incremental Change with Continuous Testing
Within each iteration, testing (both unit testing and integration testing) is done constantly, thereby building a system that “always works” and becomes incrementally better over time as changes are made and functionality is added.
Integrated Team
Subject matter experts, analysts, developers, and project management all work together through the journey of defining the system. Roadblocks present themselves up front, instead of late in the game, allowing everyone to work through them together. Developers offer constructive feedback to the subject matter experts and the team works together toward the best mutual solution.
Multiple Implementations
Since development is ongoing, tangible software is being built constantly. This allows the team to prioritize and deliver functions to satisfy those requirements that will deliver the most business benefit as soon as possible, shortening time to market.
Which approach is better?
Waterfall Approach Advantages
- Most of the high-level business problem is defined with in-depth up front analysis, allowing the project team to gain a greater understanding of the problem and (hopefully) simplify it before coding begins.
- Limited time is required from subject matter experts. The business experts are only needed in the early stages of the project when defining what the system is to achieve.
Waterfall Approach Disadvantages
- Analysts and subject matter experts are often not involved in development or testing; this prevents them from gaining an understanding of how helpful their deliverables actually were and if they will result in a system that will meet their needs.
- It is hard to predict needs in advance, and details that were never considered during analysis often arise during development.
- Hand-offs result in
- Information loss. Analysts often have an implicit understanding of needs that is hard to convey in documentation.
- A lack of team cohesion, resulting in an under-utilization of early-phase deliverables, especially when these deliverables are 300-page requirements specification documents. Also, less due diligence is required by someone that knows they will be off the project when development uncovers holes in analysis.
- Design flaws are not discovered until the testing phase. This risk increases with the size of the project.
Iterative Approach Advantages
- As clients see tangible prototypes through the project, feedback occurs more quickly, minimizing rework. As soon as the customer sees the first release, they learn what they want in the second release (or what they really wanted in the first release).
- Since the project team never goes down the wrong path for a long time, requirements changes are embraced and design flaws are discovered quickly.
- New functionality can more easily be rolled out in stages, allowing clients to prioritize and deliver those features that will result in the biggest benefit more quickly.
- Since the same team is involved from start to finish, a sense of ownership arises that creates increased productivity.
- The understanding of the developers builds upon itself. Since the same person listening to needs is sometimes writing the code, less time is spent writing documentation to be handed off to describe the requirements.
- Estimates are more realistic since they are based on a short list of requirements to be delivered over a short timeframe.
Iterative Approach Disadvantages
- An iterative approach can result in a never-ending project if not managed properly and management doesn’t determine when the major needs have been met. This is because it is always possible to improve any software product.
- Due to a lack of detailed planning, coordinating large projects can be hard, resulting in a lack of up-front estimating of the overall project effort.
- The need for an integrated team means that it is nearly impossible to implement this approach with a large team whose members are geographically separated.
- A lack of system documentation can result in a system that is hard to maintain and enhance once the project team moves on. It is essential that time is taken at the end of the project to document what the system actually does so that future maintenance can be easily done.
The wrong path can be taken for either approach
- The waterfall approach can lead to excessive time spent on analysis that is only realized to be fruitless after development begins and the clients see that they didn’t really want what they requested.
- An iterative approach can lead to excessive time spent writing code that must be refactored later once a cohesive picture emerges of the entire system.
Results will vary based on the people and the project
Talented people can make a bad methodology work and unskilled people can fail with a great methodology. You are not guaranteed to succeed just by implementing any particular methodology over another. The biggest barrier to the success of a methodology is often the culture. If a customer or manager insists on a complete specification before they begin any programming, then there is bound to be friction when attempting to implement an iterative approach. The bottom line is that if the people don’t believe in a given methodology, it is bound to fail.
Copyright © 2013 RED