Having been involved in software development projects for a long time, here are my thoughts on the strengths and weaknesses of each.
Waterfall is a linear approach to software development. In this methodology, the sequence of events is something like:. In a true Waterfall development project, each of these represents a distinct stage of software development, and each stage generally finishes before the next one can begin.
There is also typically a stage gate between each; for example, requirements must be reviewed and approved by the customer before design can begin. There are good things and bad about the Waterfall approach. Ease of use and manageability: Waterfall is an extremely rigid model that designates the steps needed to push further down the sequential stages of a project. Each of the seven phases has specific components that need to be met and reviewed, making it easy to maintain control over each step.
Comprehensive documentation: Waterfall requires that each phase is reviewed and documented before moving on to the next, ensuring a greater understanding of the tasks that were completed in each phase. There is a physical way to follow, report on, and refer back to the project because of the commitment to documentation associated with Waterfall.
The largest downfall to Waterfall is its lack of adaptability to change. Because Waterfall relies on a linear, dependent model, the ability to bounce back from issues is hindered. Slowed accomodation to change: Once a phase is completed, there is no way to go back and change the outcome without repeating the entire process from the beginning. It is both time-consuming and costly to allow room for change within this process, making it difficult for teams to maintain strict timelines if not everything goes as planned.
Longer delivery times: There are extensive steps that a project must go through before it even begins the execution phase. As a result, it takes longer to see a product begin production until late in the life cycle.
Difficulty in determining requirements: An analysis of the project is done very early in the process, meaning stakeholders and customers must identify their desired outcome early on. However, it can be hard to determine the desired outcome without seeing the project in progress - especially that early in the design phase.
Because of its highly structured nature, Waterfall is best used in industries where firm tasks and deadlines need to be set and maintained. For example, manufacturing and construction industries are two highly rigid businesses that rely on the timely completion of dependent stages. Changes to these plans can be expensive, and in some instances, impossible. As a result, Waterfall is leveraged to preserve a sequential process and maintain stability throughout stages of a project.
Team members will refer to the documentation you provide throughout the process. When followed properly, this document makes clear precisely what is expected, thus guiding the creation of the product. It will also provide project milestones that will make it simple to determine progress.
Consequently, thorough documentation is a priority in the waterfall project management methodology. Documentation should take place throughout every phase of the process, ensuring that everyone involved is on the same page despite the sequential progression of the project. The specific phases of the system vary somewhat from source to source, but they generally include:.
In this stage, you should gather comprehensive information about what this project requires. You can gather this information in a variety of ways, from interviews to questionnaires to interactive brainstorming. By the end of this phase, the project requirements should be clear, and you should have a requirements document that has been distributed to your team. Using the established requirements, your team designs the system. No coding takes place during this phase, but the team establishes specs such as programming language or hardware requirements.
Coding takes place in this phase. Programmers take information from the previous stage and create a functional product. They typically implement code in small pieces, which are integrated at the end of this phase or the beginning of the next.
Once all coding is done, testing of the product can begin. Testers methodically find and report any problems. If serious issues arise, your project may need to return to phase one for reevaluation. In this phase, the product is complete, and your team submits the deliverables to be deployed or released.
The product has been delivered to the client and is being used. As issues arise, your team may need to create patches and updates may to address them. Again, big issues may necessitate a return to phase one. Although most companies use some combination of project management styles, a report from LiquidPlanner showed that Waterfall methodology relies heavily on initial requirements. However, if these requirements are faulty in any manner, the project is doomed. If a requirement error is found, or a change needs to be made, the project has to start from the beginning with all new code.
The whole product is only tested at the end. If bugs are written early, but discovered late, their existence may have affected how other code was written. Additionally, the temptation to delay thorough testing is often very high, as these delays allow short-term wins of staying on-schedule.
If the client realizes that they need more than they initially thought, and demand change, the project will come in late and impact budget. Instead of a sequential design process, the Agile methodology follows an incremental approach.
Developers start off with a simplistic project design, and then begin to work on small modules. The work on these modules is done in weekly or monthly sprints, and at the end of each sprint, project priorities are evaluated and tests are run. These sprints allow for bugs to be discovered, and customer feedback to be incorporated into the design before the next sprint is run. The process, with its lack of initial design and steps, is often criticized for its collaborative nature that focuses on principles rather than process.
The Agile methodology allows for changes to be made after the initial planning. Re-writes to the the program, as the client decides to make changes, are expected. At the end of each sprint, project priorities are evaluated. This allows clients to add their feedback so that they ultimately get the product they desire. The testing at the end of each sprint ensures that the bugs are caught and taken care of in the development cycle.
Because the products are tested so thoroughly with Agile, the product could be launched at the end of any cycle. With a less successful project manager, the project can become a series of code sprints.
If this happens, the project is likely to come in late and over budget. Both the Agile and waterfall methodologies have their strengths and weaknesses.
0コメント