Maintain or supportThis could involve fixing errors found after the product has been deployed, or it could involve enhancements or improvements to the product that can be added incrementally after deployment.Other aspects of support may be compatibility-related, ensuring the product works on the latest operating system for its platform and fixing and issuing updates as necessary.
The benefits of a Waterfall approach are as follows:
There are structured stages, in a specific order.
The Waterfall model is familiar to many, it has been around for a long time.
The Waterfall model is sequential, one stage is completed before moving to the next, and there are often gatekeepers at each stage.
Documentation is produced at every stage of the product’s development.
Developers and customers agree on what will be delivered early in the life cycle which should make planning, monitoring and design easier.
Progress should be more easily measured, as the scope of the work is known in advance.
Disadvantages of a Waterfall approach include the following:
Requirements should be fixed and complete before production begins; this could involve a lot of time spent up front before any lines of code are written. This could be problematic for systems that have a specific delivery date, time limit or fixed price contract.
Rigidity of requirements and therefore of the product being built. Because the requirements are gathered ‘up front’ any changes needed may be difficult to add later.
Changes to requirements may cause confusion, wasted effort or a project restart.
The working software can only be seen at the end of the process. This means that if there is a change in business practices or a fundamental change needed in the way the product works it may not be spotted until right at the end.
The product is unknown to the customer until it is delivered at the end. This means that feedback from the customer is not received until the product has been built, meaning that changes will be more expensive to add.
There can be a lack of visibility – teams don’t realise they are behind schedule until later in the life cycle.
The amount of time given to the later stages (e.g. testing) is often squeezed by overrunning timescales in earlier stages.
Emphasis on getting information right up front, which puts pressure on people to decide early and to remember ‘everything’ they want in the new product in the beginning.
Waterfall life cycles are best suited for:
Projects that require fixed stages and deadlines, accountability or legal auditing.
Short, simple projects where theoretically, little can go wrong.
Projects with changing project teams that depend on extensive documentation.
Projects with stable, known requirements, for example, projects that may have been done before, where chances of surprises or changes during the development process are relatively low.
Projects where change is complex and expensive: this could be because a change may result in a large amount of wasted time, work or money or because a change of direction would not be possible, for example if the hardware had already been bought and installed. This is distinct from Agile projects which are designed to deal with changing requirements. If change is complex or expensive the project will not allow deviations from the original plan, requirements or design.
Agile
In February 2001, at a meeting of software developers, several of those developers got together and discussed their different approaches to development with a view to trying to come up with an approach that worked well for both creators and consumers of a product. The outcome of this meeting was the Manifesto for Agile Software Development (Beck et al., 2001). Several participants from that meeting went on to found the Agile Alliance (2001).
The Agile Alliance website describes Agile as:
an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it.
This is a summary of those 12 principles from the Agile Manifesto (see the original list in Beck et al., 2001):
Early and continuous delivery of valuable software.
Welcoming changing requirements, even late in development.
Delivering working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers working together daily throughout the project.
Building projects around motivated individuals. Giving them the environment and support they need, and trusting them to get the job done.
Conducting face-to-face conversation as the most efficient and effective method of communication.
Using working software as the primary measure of progress.
Sponsors, developers and users maintaining a constant pace indefinitely.
Continuously paying attention to technical excellence and good design, which enhances agility.
Working with simplicity in mind – the art of maximising the amount of work not done.
Utilising self-organising teams, from where the best architectures, requirements and designs emerge.
The team reflecting, at regular intervals, on how to become more effective, then tuning and adjusting its behaviour accordingly.
Agile practices promote adaptive planning, evolutionary development, early delivery and continuous improvement of both the product under construction and the process being used to construct the product. It also encourages:
Rapid and flexible response to change. In a dynamically changing business world, being able to change direction or deliver products before your competitors may be the difference between survival and closure.
Timely and regular delivery of business value through short sprints (these are the time-boxes in which development takes place).
Feedback from stakeholders and the team developing the system.
Collaboration among stakeholders and system development team.
Prioritised functionality, meaning the features that are most important are delivered first. This can be particularly helpful if the product is part of a trial or a prototype.
Agile does not tell you how to implement the ideas listed in the manifesto. People who use Agile use a set of common practices and often use a methodology too. Among the most commonly used methodologies are:
Adaptive software development (ASD), created by Jim Highsmith.
Agile modelling, created by Scott Ambler.
Dynamic systems development method (DSDM), created by the DSDM Consortium.
Extreme programming (XP), created by Kent Beck, Ward Cunningham and Ron Jeffries.
Feature-driven development (FDD), created by Jeff De Luca.
Kanban (development), created by David J. Anderson.
Lean software development, created by Mary and Tom Poppendieck.
Scrum,