The “plan your work and work your plan” philosophy has proven its efficiency many times in history. Proper planning defines the success of any serious initiative, including software development. The software development industry has come up with several approaches to meeting business requirements.
The software development life cycle or SDLC defines the way a product is brought to life and maintained. It helps you turn creative ideas and market requirements into product functionality and features.
In brief, an SDLC is a way to get things done in terms of developing a product and turning it into a business.
- SDLC models
- Waterfall model
- V-Shaped model
- Big Bang model
- Prototyping model
- Iterative and Incremental model
- RAD model
- Spiral development model
- Agile model
Based on your market, project context, and business requirements, you can choose an established SDLC or create your own.
The first SDLC model in the history of software development, Waterfall is the simplest. In the Waterfall model, the development process is linear. Tasks and phases are completed one by one in a strict order. The progress flows steadily downwards, like water over a waterfall.
The traditional phases in the Waterfall model are:
- Requirements gathering
- Integration and testing
The Waterfall model does not permit going back to previous stages of development to fix things or implement changes. This can only be done in the next Waterfall iteration.
- Easy to explain to the client and easy for the team to understand
- Obvious structure with well-defined stages and activities
- Easy planning and scheduling with clear milestones
- Phases completed one at a time
- Errors and misconveniences are easy to verify at each stage
- Every stage is easy to analyze and evaluate
- Well-documented processes
- Only works with non-flexible requirements
- Can't return to completed stages
- Hard to adjust
- Cost of development is usually high
- High risk of bugs and other inconveniences
- Difficult to measure progress during stages
Best for projects with:
- Stable, non-ambiguous requirements
- A clear definition of and vision for the product
- Well-known technologies and a stable technology stack
- Enough resources for implementation and support
- A short time frame
Also known as the V-Model or Verification and Validation model, the V-Shaped model is an extension of the Waterfall SDLC approach. With the V-Model, progress does not move in a straight line but rises upwards after implementation and coding.
Early test planning is typical for V-Model SDLC projects, which is the major difference vis-à-vis the Waterfall model. Every development stage has a parallel testing phase, which helps to verify and validate every step before moving on to the next.
- Easy to use and explain
- Clear deliverables for every phase, meaning greater discipline
- Better results than in the Waterfall model due to early testing
- Clear verification and validation at every stage
- Smooth defect tracking, as bugs are found at the early stages
- Easier progress tracking, at least compared to the Waterfall model
- Poor flexibility with no support for iterations
- Hard and costly to make adjustments due to no handling of parallel events
- High business and development risks
- No early prototypes available
- No clear solution for problems detected during testing
The project phases in the V-Model are the same as in Waterfall, but with verification and validation for each phase via testing. So the V-Model is good for similar types of projects as Waterfall.
Big Bang model
This SDLC model typically doesn’t follow any specific processes or instructions.
Development starts with the resources and efforts available at the moment, with very little or no planning at all. As a result, the customer gets a product that may not even meet the requirements. Features are implemented on the fly.
The key idea of the Big Bang SDLC model is to assign all available resources to development of the product itself, mostly in terms of coding, without bothering about meeting the plans.
- Dramatically simple model
- Almost no planning needed
- Simple to manage
- Doesn’t require a lot of resources
- Flexible for the development team
- High risk and uncertainty; the whole project may need to be redone from scratch
- Doesn’t fit complicated, long-term, or object-oriented projects
- High probability of wasted resources due to uncertain requirements
- Small teams or single developers
- Academic projects
- Projects with no certain requirements or expected release date
- Low-risk repetitive and small projects
The Prototyping SDLC approach is about creating a working prototype of the software product with limited functionality and then quickly turning the prototype into the complete product. The prototype may not contain the exact logic of the finished product.
This software development life cycle approach is good for allowing the consumer to visualize the product. Gathering and analyzing feedback from customers helps the development team better understand customer requirements at the early stages of development.
Check this article to learn why requirements are important in software engineering.
Prototyping is also valued because it involves fewer iterations than the traditional Waterfall model. This is because testing is done on (and changes are made to) the prototype, not the fully developed product.
Of course, creating a valuable prototype requires some basic understanding of the product and market requirements, especially in terms of the user interface.
With the Prototyping model, users’ feedback takes the definitive role in planning further development.
Prototyping allows users to evaluate developer proposals for the further apps functionality and try them out before they're implemented.
Every prototype in this SDLC model is usually brought to life in the following phases:
- Identify the requirements
- Develop the initial prototype
- Revise and enhance
As soon as the final prototype is completed, the project requirements are considered to be unchangeable.
There are also a number of traditional types of prototyping:
Throwaway prototyping — The team develops a number of different prototypes and discards the obviously unacceptable ones. Useful functionality from each prototype moves on to the next development phases.
Evolutionary prototyping — The team shows the prototype to focus groups of potential users, gathers their feedback, and implements changes via iterations until the final product is completed.
Incremental prototyping — The team creates various prototypes and eventually merges them into a single design.
Extreme prototyping — The team creates a prototype in three parts: a static prototype, a functionality simulation prototype, and an implemented services prototype. This type of prototyping is mainly used in web application development.
- Increased user involvement before product implementation
- Chance to reduce development time and costs (in case of a successful prototype)
- Better understanding of functionality by users as they take part in the development process
- Early detection of defects
- Fast feedback
- Simple and valuable analytics
- High risk of incomplete analysis due to dependency on the prototype
- Users may consider a prototype as a completed product and remain unsatisfied
- Risk of a high cost of implementing the prototype
- Developing multiple prototypes may take too many iterations and consequently too much time
- Using in parallel with any other SDLC model
- Products with a lot of user interactions
- Products that should be approved by users at early stages
Iterative and Incremental model
The Iterative and Incremental SDLC model unites an iterative design and workflow with an incremental build model. In this case, the team develops a product in cycles, building small parts in an evolutionary way.
The development process starts with the simple implementation of a small, strictly limited set of product requirements. The product is then enhanced and turned into more complete versions of itself until it’s complete and ready for deployment. Each iteration may contain design updates and new functionality.
A valuable feature of the Iterative and Incremental model is that development can be started without knowing all the requirements. This model contains the steps from other SDLC models — requirements gathering, design, implementation, and testing — but over the course of multiple builds. The development team takes advantage of what was achieved in previous builds to make the next build better.
The Iterative and Incremental SDLC model can look like a set of mini Waterfall or mini V-Shaped models.
- Produces business value early, as a working product is delivered with every increment
- Can be done using scarce resources
- Provides space for flexibility
- Allows more focus on user value
- Works well with parallel development
- Detects problems at early stages
- Easy to evaluate development progress
- Uses lots of customer feedback
- Requires heavy documentation
- Follows a predefined set of phases
- Increments are defined by function and feature dependencies
- Requires more user involvement by developers than Waterfall or other linear SDLCs
- May be hard to integrate features between iterations if they aren’t planned in advance
- Architecture or design problems may occur because of incomplete requirements at the early stages
- Complicated to manage
- Hard to predict the end of the project
- Complicated and mission-critical projects like ERP systems
- Projects with strict requirements for the final product but with space for additional enhancements
- Projects where major requirements are defined but some functionalities may evolve or enhancements may be made
- Projects where the required technology is new and hasn’t been mastered yet or is only planned for some part of the product
- Products with high-risk features that may need to be changed
The Rapid Application Development (RAD) model is based on prototyping and iterative development with no specific planning involved. With this model, planning takes a backseat to rapid prototyping.
The necessary primary data in the RAD model is gathered via workshops, focus groups, and early prototype demos as well as by reusing existing prototypes.
The functional modules in the RAD SDLC model are developed in parallel as prototypes and are integrated to deliver the complete product fast. Developed prototypes are likely to be reusable.
The RAD model distributes the analysis, design, build, and test phases into a series of short, iterative development cycles.
Phases of the RAD model:
Business modeling — Models the flow of information and the distribution of information between various business channels. This part is needed to find vital information for the business and define how it can be obtained, how and when the information is processed, and what factors are driving the successful flow of information.
Data modeling — Data from the previous phase is processed in order to form the necessary datasets with identified and established attributes.
Process modeling — Data sets from the previous stage are converted into process models to achieve business objectives and are given process descriptions for adding, deleting, retrieving, or modifying every data object.
Application generation — The system is built and coding is done using automation tools to convert process and data models into actual prototypes.
Testing and turnover — The majority of prototypes are independently tested during every iteration. Developers only test the data flow and the interfaces between all components during this phase.
- Can accommodate changing requirements
- Easy to measure progress
- Ability to cut the iteration time with powerful RAD tools
- Better productivity with fewer team members involved, compared to other SDLCs
- Faster development
- Better component reusability
- Earlier initial reviews
- Better chance to get customer feedback
- Requires strong technical and design teams
- Only good for systems that can be modularized
- A lot of dependency on modeling
- High cost of modeling and automated code generation
- Complicated management
- Only suitable for component-based and scalable systems
- A lot of user involvement is needed during the whole life cycle
- Modularized systems delivered in an incremental manner
- Design-based projects with a lot of strong modeling
- Projects with automated code generating functionality
- Projects with dynamically changing requirements for which small iterations need to be presented every 2 to 3 months
Spiral development model
The Spiral SDLC model is a combination of the Prototyping and Waterfall approaches. It synchronizes well with the natural software development process. The Spiral model features the same phases as Waterfall in the same order (requirements gathering, design, implementation, and testing ), separated by planning, risk assessment, and the building of prototypes and simulations during each step.
- Estimates (budget, schedule, etc.) become more realistic as work progresses since important issues are discovered earlier
- Early involvement of the development team and users
- Higher quality of risk management at each phase
- Better flexibility than in linear models
- Extended use of prototypes
- More money and time required to get the finished product
- More complicated to execute due to the greater need for risk management
- Limited reusability due to highly customized results of development spirals
- Requires heavy documentation
- Complicated projects with a lot of small built-in functionality
- Projects with strict budgets (risk management will help to save money)
- High-risk projects
- Long-term development projects
- Projects with no clear requirements at the early stages, or with requirements that need to be evaluated
- New product lines meant to be released in phases
- Projects where significant changes to the product are likely to occur during development
The Agile SDLC model is a mix of iterative and incremental approaches, focused on adapting to flexible requirements and satisfying users and clients by delivering working software early.
Requirements and solutions in Agile projects may evolve during development.
With Agile development, the product is divided into small incremental builds and delivered in iterations. All tasks are divided into small time frames in order to prepare working functionality with each build. The final product build contains all the required features.
In Agile, existing development approaches need to be adapted to the requirements of each specific project. Read the official Agile Manifesto website to learn more about the Agile philosophy.
- Less time needed to deliver specific features
- Leaves no space for guesswork due to face-to-face communication and continuous input from the client
- High-quality results in the fastest possible time
- Business value can be delivered and demonstrated fast
- Requires minimum resources
- Highly adaptive to changing requirements
- Requires a client to realize the importance of the user-centered approach
- Late delivery of documentation results in harder transfer of technology to new team members
- Features strict demands in terms of the scope, delivered functionality, and improvements to be done in time
- Not easy to cope with complex dependencies
- Requires a lot of soft skills from the development team
- Almost any type of project, but with a lot of engagement from the client
- Projects with a frequently changing environment
- Clients who need some functionality to be done fast, e.g. in less than 3 weeks
According to the annual State of Agile report, Agile is still the most widely used SDLC in the technology industry. At Mind Studios, we mostly use the Agile SDLC model to develop software products for our clients. Here’s why.
The main thing that distinguishes Agile from other SDLC models is that Agile is adaptive, while other models are predictive. Predictive development models depend closely on proper requirements analysis and planning. Because of that, it’s hard to implement changes in predictive methodologies — development sticks very closely to the plan. And if something needs to be changed, it will face all the consequences of control management and prioritization.
Modern software development requires the ability to make changes immediately. Adaptive Agile development doesn’t rely on detailed planning as much as predictive methodologies. So if something needs to be changed, it can be changed no later than in the following development sprint.
A feature-driven development team can adapt to changes in requirements dynamically. Also, the frequency of tests in Agile helps to minimize the risk of major failures.
Read more: How to Manage Risks in Software Development
Of course, Agile means a lot of client and user interaction to work properly. The needs of the user, not the client, define the final project requirements.
Scrum and Kanban
There are many established approaches to Agile software development life cycle. Two of the most popular are Scrum and Kanban.
Scrum is a workflow framework used to deliver software in sprints, which are usually two-week periods. Scrum concentrates on how to manage tasks within a development environment and helps to improve team dynamics.
There’s no one-size-fits-all way to perform Scrum due to its high adaptability. But in general, a team needs to arrange associated roles, events, artifacts, and rules within a certain project.
A sprint is a time frame of two to four weeks during which the team creates a usable piece of software. A new sprint starts right after the previous one is finished.
These are the typical elements of a sprint:
Sprint planning, where the team plans the amount of work to be done in the given sprint
The Daily Scrum Meeting a short daily meetup for the team to discuss what’s been done, what they plan to do today, and what problems occurred since the last meeting
Sprint Review, a meetup at the end of the sprint during which the team goes over the completed work and makes changes to the product backlog, if necessary
A Sprint Retrospective happens right before the start of a new sprint. During the retrospective, the Scrum team concludes the work and creates improvement plans for future sprints based on their experience from past sprints.
Kanban is a management visualization method widely used in the Agile SDLC model. It helps to improve and maintain a high level of productivity within a development team. Kanban operates with short iterations: if Scrum is about weeks, Kanban is about hours. Scrum aims to finish the sprint, while Kanban aims to finish the task. Kanban is anti-multitasking.
The key practices of Kanban are:
- Visualizing the workflow
- Limiting in-progress tasks
- Managing the workflow
Kanban is implemented using a board where all project tasks are visualized and divided into columns such as to do, in progress, on hold, done, and in review.
Kanban is also good for less technical activities, like sales, marketing, and recruiting.
Speaking of SDLC models as ways to get things done, we should mention the DevOps approach. DevOps is a combination of tools, practices, and approaches that help to deliver software products at a faster pace. DevOps is about the collaboration of development and operations environments.
Note that DevOps is not an SDLC model, but it also helps you get things done.
Mostly, DevOps is performed by automating infrastructure and workflows and continuously tracking application performance. A DevOps approach allows you to increase the frequency of deployments, document code, and shorten the time required to deploy new code. It’s very good for avoiding dependency errors.
DevOps uses iterations to improve, measure, and monitor code in everyday operations. Its ultimate goal is to have as effective a production environment as possible to provide a better customer experience.
But implementing the DevOps model requires a specific mindset from the development and operations teams as well as the readiness to develop faster and master DevOps tools and skills.
- More frequent releases for faster delivery to market
- More focus on improving the product and more responsiveness to business needs
- Better collaboration between team members
- Better quality of the final product and happier customers
- DevOps is new, which means it’s not that well studied
- Not the best fit for mission-critical projects
- Requires extra effort by the team to organize
- High possibility of mistakes at the early stages of development
- Need to choose between focusing on security or development speed
The software development business changes constantly and rapidly. It changes faster than people create established ways to manage it. There may not be a specific SDLC that perfectly fits your business. But existing software development life cycle models may at least guide you in the right direction and help you harmonize your business processes.
If you would like to get a clearer understanding of what SDLC will fit your project best — or if you need a top-notch Agile team to develop your app or web product — drop us a message via our contact page.