There are various software development lifecycle models. Depending on the nature of your project, there’s a model that fits. Each of them follows a series of unique steps that fit its project type to ensure a successful process. Waterfall, Iterative, Agile & Scrum, and Rapid Application Development (RAD) are the most popular software development lifecycles being used nowadays.
Waterfall
Waterfall model is the earliest and best-known software development lifecycle. It is the most simple software methodology to understand and apply. It’s partly because Waterfall is sequential, which means that each phase must be finished for the next to start. In other words, the output of a given phase will be the input for the next. This also means that there would be no overlapping between phases.
The entire Waterfall methodologies and the product of each of its stages can be summed up as follows.
1. Requirement
Requirement is about gathering and analyzing requirements, which is done by communicating with business users or clients. In this phase, the person in charge (usually project managers) works to understand the user’s requirements and explain them detailedly in the Business Case Document.
2. Design
Based on the Business Case Documentation, the Business Analyst now defines the logical design of the software. In this phase, the high-level design is also transformed into the physical design where hardware and software are all considered. The system architecture is also defined in this stage.
3. Implementation
This is where the developers write codes to develop the software, following the instructions in the requirement documents. This phase’s output is the Functional Requirements, documenting all the details of the software functions being developed.
4. Testing
Taking the Implementation phase’s Functional Specification, testers will make test plans. Developers and business analysts also need to prepare test plans. Developers do this to examine if functions are executable as expected, whereas business analysts want to make sure the software meets user requirements. Testers finally will gather all the documentation from previous phases and do an overall test on every aspect on a deeper level, trying to verify system architecture, technologies used, etc.
5. Deployment
After the software is qualified for a “PASS”, it is ready for release. The software can either be deployed to production servers or released for users to install on their own devices.
6. Maintenance
The reality is that defects are inevitable. Moreover, the user’s needs keep changing and, as a result, updates are needed from time to time. Maintenance solves these situations, where changes are made to adapt the software to new changes. Maintenance is simply a subset of Waterfall Model.
When to use Waterfall
- The software is not dynamic, meaning it is expected to have few changes along the line
- Very few or ideally no ambiguous requirements
- Software that needs well-documented documentations
- The software uses mature technologies
- There are enough resources and experts in advance for each phase
Advantages
- Easy to manage because everything has a clear schedule and milestone
- Easy to control with few external factors thanks to no overlapping phase
- Easy to predict since there are extensive documentations
Disadvantages
- Does not allow for changes in scope or requirement
- Does not allow for product review until the deployment phase
- Cannot cope with unexpected risks
- Limited communications with users or clients since communication is bound to the beginning and end of the project
- Long idle time
- A poor fit for long and ongoing project
Iterative
Iterative breaks down the software development into smaller parts called “build”. At each build, design enhancements and new functionalities are added until the software product evolved to the final deployment.
In contrast to Waterfall, code in an iterative model is developed and tested in a repeated cycle. This makes it flexible for new requirement changes. Coding doesn’t have to wait until the design phase finishes. Likewise, Testing can start without having to wait for the codes.
6 phases of iterative model:
1. Requirement
Much like the Waterfall model, Requirement focuses on communicating with business users and preparing the Business Case Documentation
2. Design
Also like the Waterfall model, in Design the Business Analysts and System Analysts respectively work on the logical and physical designs to prepare the Software Requirement Specification and Design Specification Document. However, in Iterative, there are two types of design. The first holistically records how the software is going to be implemented. The other is the subset of the first. Each of these design subsets is for each build and isolated from the other. Design subset also can be modified after every round of build, which means they are are finalized until the deployment phase.
3. Implementation
Developers write code based on the subset of designs passed from the Design phase. Developers will also prepare Functional Specification for each subset.
4. Testing
Developers, testers, and also users will be all involved in each subset of testing. But while business users only test a limited scope of the current build, developers and testers will cover all the functions every time. Moreover, for the last build before going to the development phase, the three parties not only have to do the subset of testing, they have to test the whole system as well.
5. Deployment
Similar to Waterfall, everything should be ready by this phase and a deployment phase for release
6. Maintenance
Again like Waterfall, it is inevitable that every software needs maintenance. Thus, another subset of the iterative model will be needed for the Maintenance Phase.
After every subset, the process loops back to the Design Phase and starts on the next design until it comes to the very last one.
When to use the Iterative model
- Big and important requirements are still defined but minor changes can be added as the software evolves
- New technologies are being used and there is a learning curve for programmers
- The software is subject to risks since the goal of the project may change from time to time
- Advantages and Disadvantages
Advantages
- Easier to start on complex projects
- Allow for regular review
- Allow for parallel implementation
- Projects can still be managed like Waterfall with clear schedules and milestones
- Easy to test and troubleshoot at each build
- Less costly for changes in scope and requirements
- Suitable for huge and core projects
- Better communication with business users as feedbacks can be gathered at each build
Disadvantages
- High risks because the architecture and designs keep changing
- Problems are inevitable at integration of each build
- More management is needed to make sure each build meet the standard
- Overlapping implementation could be chaotic
- Need more involvement of business users
- Easier but more time is needed for each testing as each testing has to cover all the previous works
Agile
Agile extends the benefits of Iterative. By rapidly delivering the product, Agile aims at improving user satisfaction and product adaptability. From requirement to Deployment phase, agile breaks the product into small builds so that it can welcome as much feedback and change as possible. Instead of going back to the design phase like Iterative, Agile goes directly to the deployment phase and releases the product. Thus, each build contains some new features. And for the last build, it contains all the required features of the software.
5 phases of agile are as below
1. Requirement
In Agile, not every requirement is gathered at the outset. Therefore, regular communication with users is a must to acquire feedback after each release. Nevertheless, a business case documentation is still necessary at the very beginning to broadly describe the scope and goal of the project. After that, the team can evaluate and rearrange resources at each build.
2. Design
Due to uncertainties, Agile does not give much time to designing. Business Analysts will mainly focus on the big goal of all builds, which follow the scope defined in the Business Case Documentation. Software Requirement Specification and Design Specification Documentation should be short and simple, only listing out what is covered in the current build.
3. Implementation
In Agile, developers have more freedom because documentation is very limited. Nevertheless, developers are still required to strictly follow coding standards. Their Functional Specification typically covers core functions and skips the details.
4. Testing
Agile’s testers have bigger responsibility because they have limited information on the software. Meanwhile, users test on a very high level. Sometimes, users are even excluded out of the testing phase.
5. Deployment
Usually products can be released 2 – 3 weeks after meeting all the requirements. The Deployment Plan tends to focus on how to deliver the product fast but with limited information and no contingency plan since another build is going to come up.
6. Maintenance
Maintenance is not needed in Agile since the next build is coming up and can be done in the next build.
Agile doesn’t pay much attention to documentation the way Waterfall and Iterative do. Although the same set of documentation is expected to be ready at each phase, the information that can be found in each documentation is very limited.
When to apply Agile
- Business users or clients provide no detailed requirements
- The project is feature-driven
- Requirements change dynamically
- Have many testers and large testing resources
- Close communications within the team and with business users
Advantages
- Realistic – what important, implement first; what not, leave it later
- Flexible – new requirements can be flexibly input and tackled
- Features can be developed and delivered rapidly
- Team members have more freedom and flexibility at each phase
- Fewer documentations to handle, which means fewer rules to follow
Disadvantages
- Very high risks for maintenance and extendability
- Not suitable for complex and core projects
- Project Managers have to follow closely at all times to check if the builds follow the scope
- Depends heavily on users’ feedback which could delay the projects and deliver the wrong product if business users are not sure of what they want
- Transfer of knowledge to new joiners could be hard due to lack of documentation
Subscribe to our newsletter to learn more about Scale Agile!
Rapid Application Development
Rapid Application Development (RAD) gathers user requirements through workshops, test on the pre-released prototypes conducted by users, and then reuse the prototypes to further develop the product. A prototype is a working model that functionally resembles the expected product. Minimal or no specific planning is involved at all which can make the team cope with the changes in the development process and favors faster product delivery. RAD Model basically assembles the working parts together to generate the product in a limited time for business users to quickly provide feedback regarding the requirements.
5 phases of RAD Model:
1. Business Modeling
In RAD, the information flow and the information distribution are defined in many business channels. A Business Analyst Report is tasked with finding out the essential information for the business such as how it can be acquired, how it can be processed and what are the elements driving the information flow and distribution.
2. Data Modeling
With the inputs from the Business Modeling Phase, key information is identified. At Data Modeling Phase, the identified information is transformed to certain data sets or data objects which will be further evaluated and defined their relationships in relevance to the business model.
3. Process Modeling
The defined data set passed from the Data Modeling Phase will be further processed by adding business information flow to achieve the business objectives that are identified at the Business Modeling Phase. Any changes to the data sets will happen at the Process Modeling Phase. The create, retrieve, update or delete (CRUD) of a data object should be defined at this phase as well.
4. Application Generation
Tools will be used to convert all the Process Models into program code and gather them together as a prototype.
5. Testing and Turnover
The newly generated prototype will be independently tested at this phase without taking consideration of the functions that are implemented in other prototypes. However, the integration between prototypes should be tested thoroughly.
When to use RAD
- Users tend to change their requirements very regularly due to the dynamic business environment
- Software is possible to be modularized
- Software is acceptable to be developed in chunks
- Team members know the relationship between prototypes
- Enough budget to own an automated code generator
Advantages
- Can tolerate frequent requirement change
- Measurable progress
- Prototypes are highly integrated with each other
- Communications with business users can be done after each prototype release
- Product review can be conducted periodically
- Automated code generator makes the project less dependent on programmers
- Shorter software development lifecycle
Disadvantages
- Heavily depending on automated code generating tools
- Automation can bring performance and technical issues
- Tools are expensive
- Designers must have both business knowledge and technical skills
- The software is not available for modularization
- Depend too much of users’ feedback
- Depend heavily on Business Analyst report
- Users are involved at every phase, which is cumbersome
- Little documentation
