Writing code is easy. Writing code that works isn’t.
The above quote might sound distant from the experience of many developers. However, the majority of them will find it challenging to write code for a fast-paced, ever-changing software startup without following any development process or methodology.
That is why in this blog post we will cover all software development processes and methods that leading companies are practicing. This is comprehended in the Software Development Life Cycle, or SDLC. You will have the chance to learn everything you need to:
- Manage better your software team
- Work smoothly with clients
- Strike your next interview for software, team lead, or management position
- (or) Just expand your knowledge and become an expert in software development!
So here’s what you’ll learn about the SDLC:
- Validation and Concept Development
- Planning
- Requirements Definition & Analysis
- System Design
- Development (Implementation)
- Integration & Testing
- Deployment (Release)
- Maintenance
4. SDLC Models
The goal of this long article is not only to give you a lot of valuable information about SDLC but also teach you about the (core) principles of SDLC so you can understand it and apply it to your next job or project.
Enjoy!
1. What is SDLC?
Definition
Software Development Life Cycle (SDLC) is a process used to conceptualize, design and develop high-quality software solutions that meet customer expectations and are delivered within predefined time and cost estimates.
Simply put, the Software Development Life Cycle (also known as Software Development process) is a step-by-step framework helping software companies and clients to bridge the gap between a software idea and a high-quality software product in the shortest time, at the lowest cost.
The SDLC framework consists of 7 stages: planning, requirements analysis, design, development, integration & testing, deployment, and maintenance. The goal of SDLC is to define tasks for each stage of the software development process so errors and mistakes can be minimized. That’s how you’ll master engineering project management.
History
The history of SDLC begins with the history of Software Development which started to emerge back in the 1950s where such terms as “framework” and agile, didn’t yet exist.
The Software Development Life Cycle (SDLC) was developed not as a fancy management acronym but out of a need for communication and standardization during the creation of software products.
The oldest SDLC models (methodologies) evolved as programming and software development progressed. Here are some of the most interesting ones: from Structured Programming (the 1950s), Iterative & Incremental (1970s), Prototyping (early 1980s), Spiral and V-Model (late 1980s), Scrum (1995), the Agile Methods Rise (1990-2000s), and to the Agile Methodologies we know today.
Today, ISO/IEC/IEEE 12207 is an international standard for the software life-cycle processes that aims to define all the processes required for developing and maintaining software systems.
2. Why is SDLC important?
SDLC is important because it breaks down the entire life cycle of software development thus making it easier to evaluate each part and guarantee its successful execution.
Moreover, SDLC isn’t a technical document or a management theory – rather it’s a practical process document that enhances the development process of any kind of software.
If that doesn’t convince you also consider that:
- SDLC improves communication with the client.
- SDLC helps eliminate bugs and requirement misunderstandings.
- SDLC synchronizes all tech and non-tech teams to successfully complete a software project.
- SDLC helps teams to better understand and follow correctly common methodologies like Kanban, Scrum, and agile in general.
3. Software Development Life Cycle phases/stages
The Software Development Life Cycle has 7 phases that govern each step of the software development process from planning to development, to testing and from deployment to maintenance.
We’ll go through each phase/stage of SDLC to define, explain, and illustrate it with an industry example.
Imagine that you’re a part of “Yodax Corp”, a fictional software company, and with your colleague John you’re introduced to Dr. James Abraham, who’s another fictional character (the client) that needs “Yodax Corp” to develop a software product for him.
Dr. Abraham has the idea of developing “AImD”, an AI-powered software application that empowers patients to self-diagnose in their homes.
Phase 0. Validation and Concept Development
The first (actually zero) step is to validate the need for the software that you/your client want(s) to create and develop a high-level (vague) concept of it.
- validation = solves a problem? + need?
- software concept = what? + how it’ll solve the problem?
Example:
In Dr. Abraham’s case, the problem his app “AImD” is solving is the stress people experience when they feel a sharp pain in their stomach at 2 am… “Googling” their symptoms and miss-diagnosing themselves with cancer.
The need for solving this problem is self-explanatory.
The software concept of “AImD” is simple – the user inputs their symptoms with photos, data and all measurements they can collect (such as heart rate, temperature, etc) and the AImD app will output the probability of the disease that they may be experiencing.
Phase 1. Planning
The Software Development Life Cycle (also known as Loop) begins with a “Planning” phase. In the “Planning” phase we take the validated concept from Phase 0. and draw its outlines – features, screens/web pages, and test whether it is all possible to achieve.
The goal of the planning stage is to roughly define our software and to execute a feasibility study (to check whether it’s achievable) in the following areas – technical, operational, financial, human resources, legal/political.
Here are some good questions to ask yourself during the planning phase:
- What should the software achieve/do?
- How should the software do that?
- How do you imagine your software to look/work?
- Is that technically possible?
- Is that financially possible?
- Is that legal?
- Do we have the resources to operate and maintain that software?
Once you’ve answered all 7 questions it’s time to move to phase 2 – Requirements Analytics but before that let’s illustrate the Planning phase with a mini example.
Example – Planning AImD’s self-diagnosing app
Back to Dr. Abraham’s AImD self-diagnosing app, we’re sitting in “Yodax” corp’s meeting room with our colleague John and Dr. Abraham himself…
The goal of our meeting today is to plan the software development of AImD’s app.
Let’s first start with the main feature of AImD – to let people self-diagnose themselves at their homes. To do so AImD should support people inputting all of their symptoms and evaluate them using an AI-powered machine learning algorithm.
The mobile app should have four screens to fulfill that purpose:
- Symptoms input screen
- Diagnose output screen
- Diagnose details (doctor’s recommendations) screen
It’s technically possible to implement that feature and User Interface given that we have a large enough training dataset for the machine learning algorithm.
Considering Dr. Abraham’s connections in the medical industry and his funding it’s possible to gather the medical training dataset we need.
To ensure legal compliance we’ll have to inform AImD users that AImD isn’t a replacement for going to the doctor and enforce them to accept strict terms of use.
To operate and maintain the software we’ll need a cloud infrastructure for the servers, data science team to ensure the algorithm’s accuracy and a small customer support team to nurture the users.
Phase 2. Requirements Definition & Analysis
After the planning is done, it’s time to define and analyze the requirements of the software. This is the most important (but also most boring) step of SDLC and also for that reason usually, the most skipped one….
The goal of the “Requirements Definition & Analysis” is to grab everything from the planning phase to research and to document it in detail.
In this phase, we’ll summon our technical, financial, legal, sales/marketing, and design teams to leverage their domain expertise on the software “outline” we just created in the Planning phase.
The Requirements Definition & Analysis is a usually long process that consists of multiple meetings. In between those meetings domain experts (tech, financial, legal, consultants) will research and define strict requirements for the software.
After the requirements are defined and carefully analyzed the Product Manager/Owner will create an SRS (Software Requirement Specification) document. This process could be done with the help of tools such as Tara AI that have requirements management software functionality.
At this stage, the customer and the Product Owner must have agreed on the SRS which describes all the requirements that we’ll be developed and designed during the software development lifecycle.
When the Product Owner receives a green light from the customer they’ll create tickets in a project management system. Once tickets are created it’s time to start the real work and move to phase 3 – “Design”.
Example – Defining AImD’s requirements
In our previous meeting with Dr. Abraham, we’ve discussed that the AImD’s app must have three screens (Symptoms input, Diagnose output, and Diagnose details) to provide its key feature – empowering people self-diagnose at home.
In the Requirements Definition & Analysis initial meeting, we’ll go through the software product screens & features and define the requirements for AImD’s software. So let’s begin!
*For the sake of simplicity, many details like loading, error states, corner cases, and details will be skipped.
1) Symptoms input screen
- Opens as initial (app launch) screen
- Dynamic symptoms questionnaire – next questions are predefined with the goal of diagnosing and based on previous user answers
- Take photos with a camera or upload photos from the gallery as a symptom input
- Upload medical documents and data as an additional symptom data
- Additional custom text input (low decision weight)
2) Diagnose output screen
- Opens after successful diagnose
- Display up to 10 “Diagnose” items with their probability based on input data & statistics
- Each diagnosis should have its symptoms, severity, and mortality rate listed
- A button “back to Symptoms” which restarts diagnosing
3) Diagnose details screen
- Opens when a “Diagnose” item is clicked
- Displays detailed symptoms with their probability
- Displays the possible complications of the disease
- Displays remedy best practices
- Provides the contacts (including customer reviews, rating, and pricing) with the local medical experts in the diagnosed field
(*) Features
- A classification machine-learning algorithm with >95% accuracy that takes the input symptoms and outputs the 10 diagnoses with the highest probability
- Fetch diagnose details from a medical database
- Use user’s location to fetch local health experts
- Review & rating system for the local health experts
This is how a simplified version of the initial Requirements & Analysis meeting could look like. The next steps are to assign domain experts for each requirement so they can define them precisely.
When all the requirements are defined our colleague John (the Product Owner in “Yodax” corp) will craft a Software Requirements Specification (SRS) document. Then he’ll present the SRS in a “human way” to Dr. Abraham who’ll either agree or disagree with the specification.
After Dr. Abraham likes the SRS, John will create tickets for the tech, design, legal, and marketing teams in “Yodax” corp’s project management software – Tara.ai.
Huh, that was a long one! I told you that phase 2 of SDLC – Requirements Definition & Analysis is the hardest and most critical one. Now let’s move to phase 3 – System Design.
Phase 3. System Design
The “System Design” phase of SDLC takes all the requirements from Phase 2. and assigns domain experts to each of them so they can start designing a solution for that requirement.
The goal of the “Design” phase is to create an actionable plan for each defined requirement that will be implemented later.
In this phase, each team will grab the tickets from the project management software and start working on them. Here’s what different teams might be doing in the design phase:
- Design team – create UI/UX wireframes for the software, pick up brand colors & theme
- Tech team – choose the Technical Stack (e.g. Java, Kotlin, React Native, NodeJS, etc) and the Application Architecture (MVP, MVVM, Microservices, etc); create Database models
- Business team – define Business rules and logic
- Sales & Marketing team – define Buyer Personas, Prospect Fit Matrix, Buyer’s Journey, and plan a growth strategy
In a nutshell, in the “Design” phase is each team working on the project to design a solution and create tasks for their part of the project which they’ll implement in Phase 4. – Development.
Example – Designing AImD’s software
In the “Design” phase the ball moves from Dr. Abraham’s field to the “Yodax” corp’s field. Team “Yodax” will devote its next efforts in designing a solution to AImD’s requirements.
That might take a while but let’s fast forward and see what’s being done…
- Design team – choose Dark Blue (trust) & Sweet Purple (Ease) as primary & accent colors, create UX wireframes for Symptoms, Diagnose, and Diagnose details screens
- Tech team – choose MVP as front-end (mobile) architecture, decide to code the back-end in Java using Spring 5.x.x, and to develop a deep-learning classification algorithm (the AI) using TensorFlow
- Operations team – decided to use AWS and Ansible as core infrastructure technologies and calculated the bandwidth required for running the AImD software
- Business team – make the app support only countries in the EU & USA and to consider a diagnosis accurate only if the user has at least 3 symptoms
- Legal team – Copyright; Patent the idea and structure terms of use and KYC policy to allow only eligible users to use the app
When the Design phase is completed, the teams must have defined tasks and a concrete plan with estimations about finishing the project.
Here me, you, and John (the Product Owner) will approve the designed solutions so we can move to the next phase- Development/Implementation.
Phase 4. Development/Implementation
The “Development” (also known as the “Implementation” ) phase is associated with the execution of the planned tasks in the Design phase.
This is the longest phase of the SDLC model where each team will get their hands dirty and implement the solution that they’ve designed.
The goal of the “Development” phase is to deliver a software system that meets all the requirements defined by the client.
Here’s a list of tasks different teams might do in Phase 4. of the SDLC:
- Operations team – set up the project: dev environment, version control (e.g. GIT), server machines, infrastructure in general
- Developers – start to code and implement the product
- Designers – turn the Wireframes from Phase 3. to beautiful product design
- QA team – develop test cases and prepare a test plan to cover all the requirements
The next phase of SDLC is “Integration and Testing” but before we jump to that let’s look at how the “Development” phase might look in Dr. Abraham’s AImD project.
Example – “Yodax” corp <> AImD (phase 4. Implementation)
Things at “Yodax” corp and the AImD project have now changed since our last visit…
All software requirements, documents, wireframes, tech studies are now structured in executable tasks in Tara.ai (The intelligent platform for modern product development teams).
The office is different, too. Coffee machines are supplied. Developers are at their work desks. Meeting and Zoom (for remote workers) rooms compared to before are rather empty than full. Every team member is on fire executing their tasks…
Here’s what everyone is doing and we’ll be doing the in the next 6, 12, 14 months or so:
- Operations team – create a Staging environment for the developers; write Ansible scripts which will control the production AWS environment
- Dev team – writing code
- Design team – creating beautiful designs handling all product cases including (loading, error, country not supported, etc)
- QA team – creating test plans and writing Espresso & Appium UI automation tests for the mobile apps
- Legal team – legal stuff, crafting and sending legal documents to get a Patent and solving all Copyright issues for AImD
The meetings happening during the “Development” phase of AImD are the weekly Scrum Sprint planning meetings and monthly zoom-outs with Dr. Abraham where team Yodax demonstrates the progress of the project.
…After 7 months of hard work the AImD project is near the finish and it’s time to move to one of the final phases of the SDLC – “Integration & Testing”.
Phase 5. Integration & Testing
The “Integration & Testing” phase of the SDLC is devoted to ensuring that the “Implemented” software from the Development phase meets all customer requirements, works as expected, and doesn’t have bugs.
The goal of Phase 5. is to provide end-to-end integrated software that will be carefully tested and continuously updated/fixed to ensure the best quality possible.
A common myth is that only QAs are involved in the testing phase but in reality that’s a responsibility for every member of the project.
0. DevOps (developer + operations) – integrate servers, databases, systems together to work with real data (so the software can be tested end-to-end)
1. QA – execute test plans and raise bugs in the issue tracking software
2. Designers – run usability tests, ensure the design looks good on all resolutions and displays
3. Business team – ensure business rules are effective
4. Developers – fix bugs, update the UI, code additional features/business logic
5. Legal team – ensures the software implementation is compliant with all laws and regulations
6. Client – approves the final version of the software
At this point, we must have a finished and ready to deploy software. But before jumping to Phase 6. – “Deployment” let’s see how Dr. Abraham and our friends at “Yodax” corp are doing.
Example – AImD’s Integration & Testing
It’s been a while since we’ve last checked the AImD’s project and the “Yodax” corp’s team. There are rumors that they’re doing great! But let’s see…
Our friend John, the product owner, greets us and presents the AImD mobile application that they’ve developed. They’ve really made enormous progress while going through the “Development” phase of the Software Development Cycle!
Having AImD installed on your smartphone you can input your symptoms when you feel sick and receive a 95%+ accurate diagnosis within seconds.
It even supports the novel diseases like the notorious COVID-19, so it can help the doctors battling the 2020 Pandemic.
While testing you might find a glitch, a bug or two but don’t worry that’s what Phase 5 – Integration & Testing is supposed to do.
Let’s see what’s the action plan of team Yodax:
- DevOps – as we can they’ve done a great job integrating the entire software system
- QAs – during our first experience with AImD we found some bugs but the QAs have found dozens more and logged them in Tara.ai
- Designers – they run a usability test on us and found that multiple-choice questions in the diagnosis questionnaire were confusing
- Business team – they’ve changed a business rule or two since we first discussed them during the “Design” phase but there’s no way to predict everything
- Developers – they’re on fire, “Yodax” corp’s SpecOps who rapidly fix critical issues and make hundreds of small improvements to perfect the software
- Dr. Abraham (our loving client) – he’s carefully reviewing AImD in detail and suggestions things to improve
Everyone in the company from marketing, sales, developers to legal are testing the software and reporting bugs. But prepare the champagne folks…
AImD is about to launch! The finishing line is near but let’s not celebrate too early… It’s time for the final push – Phase 6. Deployment.
Phase 6. Deployment (Release)
The “Deployment” phase of SDLC is to configure all software systems and servers to work on production, make final tests, execute a release checklist and deploy the software.
The goal of deployment is to deploy the already tested and verified to work as expected in a real-world production environment while meeting all customer requirements and expectations.
Although the most involved in the deployment process are DevOps and QAs, the whole company is responsible and has tasks in this final crucial phase. Here’s a list of things that you might want to check before deploying your software:
- Staging servers & databases => configured for production
- Security rules: make sure that your server security rules are not configured for testing
- Third-party systems: switched from staging to prod.
- Validate: links, email, privacy policies, URLs
- Software empty states: what happens when the user has no saved data and runs the software for the first time?
- Software translations & location settings
This checklist contains some of the important things to check before releasing your software but keep in mind that it isn’t completed since every software has different requirements.
The final part of the “Deployment” stage of SDLC is the Marketing team to execute a pre-planned product launch when it’s verified that the software is stable in production.
Example – AImD’s Launch!
“Yodax” corp and Dr. Abraham have gone a long way in the last 8-9 months… They’ve developed the AImD startup from an ambitious and crazy idea in Dr. Abraham’s head to a high-quality software in production that people can use.
They’ve succeeded! But let’s how the final “Deployment” push went for them…
Two weeks earlier. The energy levels in “Yodax” corp. are high and everyone is excited about AImD’s launch. All teams are mobilized and working:
- DevOps – setting up production AWS infrastructure and configuring Databases, Security rules, and the 3rd-party medical systems dependencies
- QAs – executing a mini-test plan after each configuration change and testing the software “as normal” users
- Business & Legal team – testing the product and ensuring both legal and financial feasibility
- Marketing & Sales – positioning the product in the medical space (forums, influencers) and preparing to execute a massive launch campaign
- Dr. Abraham – happily waiting to see his creation in the hands of people that need it and make their lives better!
Dr. Abraham, “Yodax” corp and AImD might have won “the race” but that doesn’t guarantee to win “the Olympics”… They must keep delivering high-quality software and maintaining high customer expectations. That’s why great teams won’t skip phase 7 of SDLC – Maintenance.
Phase 7. Maintenance
The last phase of the Software Development Life Cycle is “Maintenance”. In that pha0se, the software is released and real customers are already using it. The goal of “Maintenance” is to support those customers and to ensure that the software is working as expected in the long run.
The large majority of the “Maintenance” phase is handled by customer support and tech support teams – developers with admin access, who can reconfigure broken parts of the software or fix bugs.
The key activities in the last phase of SDLC usually include:
- Customer support
- Monitoring servers
- Fixing uncaught bugs
- Fulfilling user requests that can’t be done through the UI
* for that purpose software companies usually also create a separate software application called “Admin panel” which allow the tech support to manage data
The maintenance of the software should continue until the company has decided to support this software version – e.g. Ubuntu 17.10 vs Ubuntu 18.04 LTS (LTS = Long Term Support, usually ~5 years).
Example – AImD’s Maintenance & Customer support
“Yodax” corp has finished the AImD software project successfully! However, they still have a dedicated team for the platform… Wonder why?
AImD is serving millions of happy users to improve their health and Dr. Abraham is very proud of that! That’s because of the remarkable maintenance “Yodax” corp provides for the software project.
Here’s how the “Maintenance” phase of SDLC for AImD works:
- Customer Support: a well-trained remote support team is resolving customer requests in an average of less than 5 minutes
- AImD’s Admin Panel: support updating 90% of the data requested by users – country change, deleting fake doctor reviews, deleting all user data if requested according to GDPR
- Operation team – ensuring 99.9% servers uptime, monitoring server’s load
- Dev team – fixing bugs, UI glitches, and making minor software improvements
- Data science team – updating AImD’s ML models to ensure 95%+ accuracy
So the secret behind AImD’s great success is not only having a remarkable and dedicated team but also following a structured and proven by the time software development process like the SDLC.
Software Development Life Cycle: Looping
The SDLC looping occurs once the team has gone completely through the Software Development Life Cycle and wants to create a new version of the software. For example, planning to add a major 2.0.0 version where you want to include new features or redesign existing ones.
If the concept of the new version of the software isn’t substantially different “Phase 0. – Validation & Concept Development” is skipped and the Software Development Life Cycle is executed from Phase 1. to Phase 7.
You probably already have noticed that you can loop indefinitely through the SDLC and by the law of marginal gains create remarkable and outstanding software given that you follow the SDLC model long enough.
In the next section, we’ll cover the six most popular SDLC models (implementations) that you can take advantage of to boost your productivity and your company’s performance in 2020.
4. SDLC: Models
There are various SDLC models that have emerged in the software development industry since its dawn. We’ll discuss focus on the 6 most widely used ones with their pros, cons, and use cases.
Our goal is to teach you the principles behind the field-tested SDLC models so you can choose which one would work best for you or develop a custom SDLC model that would fit your needs better.
Waterfall Model
The Waterfall is the oldest and the simplest one of the SDLC models. As its name suggests the stages in this model flow like the water in a waterfall flow, from top to bottom without skipping a single rock (stage) on its way.
The software development process in the Waterfall model starts with Planning, then Requirements Analysis, System Design, Implementation, Integration & Testing, to Maintenance without skipping a single step.
In the Waterfall model going back to a finished phase of the SDLC or skipping a phase is not prohibited. Working software is built once all the stages are completed.
“Imagine the Waterfall model’s work process like an actual waterfall. The water doesn’t travel up and down, it goes down – simply obeying the laws of gravity.”
Pros:
- Simple to understand and implement
- Clearly defined and easy to follow
- Phases are completed one at a time (won’t be skipped)
- Development key points are easily tracked
Cons:
- Requirements are immutable (can’t be changed)
- Working software is produced after Phase 6. “Deployment”
- Problems can’t be identified in advance (but only after Phase 5. “Integration & Testing”)
- Difficult to measure the progress of individual phases (e.g. development, integration & testing)
Best for:
- Projects with clearly defined and fixed requirements
- Software that won’t be changed while being developed
- Short projects (because you can’t predict everything that would happen in 6+ months)
- Software that doesn’t depend on a dynamic environment (e.g. 3rd party dependencies won’t be changed)
Iterative & Incremental Model
The Iterative & Incremental model is an SDLC model where the development process is split into iterations called builds (versions). As its name suggests the software isn’t developed at once but on small (2-6 weeks) iterations that build the software to its final version incrementally.
Every iteration usually has Planning, Requirements, Design, Implementation, Testing, and Deployment stages. A working software version is built and released after each iteration.
The “Maintenance” phase for each version is stacked and begins after its first release. Usually, only the N (can range from 2-20) newest versions are backward-compatible and being supported.
Pros:
- Working software versions are released early and periodically
- Testing & debugging of small chunks is easier
- Software requirements can be changed
- Two or more parallel teams can develop versions of the software independently
Cons:
- Software architecture and design may be damaged (because all requirements aren’t defined since the beginning)
- More management is required (because all iterations must be planned and synchronized)
- End of the projects isn’t defined (the iterations and software versions may be infinite)
- Requires more resources than the Waterfall model (management, planning, maintenance)
Best for:
- Projects that need an MVP or an early working version fast
- Software projects that have a dedicated management team
- Hourly based rather than fixed priced software projects
- Software teams with an experienced Software Architect
Spiral Model
The Spiral model is a “hybrid” version of the Waterfall and the Iterative & Incremental models. The software in the Spiral model is built on stages called spirals and it focuses highly on risk management and customer evaluation.
The spirals in the Spiral model are an “Identify”, “Design”, “Build”, “Evaluate” iterations that get better defined and more precise with each spin through the 4 phases of the spiral model:
- Identification
- Design
- Build
- Evaluation & Risk Analysis
In the Spiral model, a new working version of the software is released after each iteration and the customer feedback gathered from the “Evaluation & Risk Analysis” phase is implemented in the next (spiral) iteration.
The software project is considered finished and officially released when after spiraling there’s a green light from the “Evaluation & Risk Analysis” phase.
Pros:
- Good risk management (because there’s a customer evaluation at every iteration)
- Users can shape the software early (a working software versions are shipped early hence the users can provide feedback)
- Requirements can be changed
- Requirements are captured more precisely (because of the “Evaluation & Risk Analysis” iterations)
Cons:
- The process is complex
- Requires more management & documentation (SRS for each iteration)
- Requires a lot of resources (management, risk analysis experts & customers to evaluate)
- End of the project isn’t known (the spiral may go on indefinitely)
Best for:
- High-risk projects with a lot of unknowns
- Not suitable for small or low-risk projects
- Teams with highly-skilled risk experts
- Projects where major software changes are expected
V-Model
The V-Model (or the Verification & Validation model) is an extension of the Waterfall model where the development happens in a “V” shape. The horizontal axis represents time and the vertical axes project completeness:
- the Left “V” – Project definition (abstract at the top, concrete at the bottom)
- the Center – “Coding” which connects the V-Shape model (the time)
- the Right “V” – Project completeness (code at the bottom, working software at the top)
In the V-Model, each software development stage is followed by a test stage. The next phase can begin only after the corresponding test has been passed. There are two types of tests:
- “Verification” – static (no code execution test)
- “Validation” – functional (executes the code to test the software)
The V-Model is a very strict SDLC model which requires a well-disciplined team. A working version of the software is released only after all phases and their corresponding tests are completed.
Pros:
- Testing is introduced early hence errors & mistakes are minimized
- Enforces a clear and strict development workflow
- Phases are completed one at a time
- Easy to manage, rigid model
Cons:
- Requirements can’t be changed
- A working version of the software is released late
- Coding phase progress can’t be tracked
- Requires extensive resources for Verification & Validation
Best fit for:
- Short-term projects with clear requirements
- Well-disciplined teams with strong testing culture
- Fixed software tech-stack & dependencies
- Projects requiring extensive testing
Big Bang Model
The Big Bang model is an SDLC Model where all efforts and resources are focused on design, development, and coding with zero-to-none planning. Imagine it as the name refers to the Big Bang that created our Universe – BOOM…
Enormous energy (your team) focused on a tiny singularity (coding the software) with the help of infinite randomness to produce a spectacular (client’s software) creation.
In the Big Bang model, there are no phases or rules defined. Team members are encouraged to execute without much preparation. Success is achieved through trial and error. Working software is produced whenever the team decides to release such.
Pros:
- The simplest of all SDLC models
- Requires no management & no resources
- Design & Development begins immediately
- Developers are flexible and free
Cons:
- Risky model to follow (the Big Bang “code explosion” is uncertain)
- Disaster when project requirements are misunderstood
- Bad for long or complex projects
- Bad for projects carrying high-risk
Best fit for:
- Small teams with max 2-3 developers
- Short projects with straightforward requirements
- Simple and urgent projects that need to be released ASAP
- Teams that don’t want to have management or follow any processes
Agile
“Ship early. Ship often.”
The Agile SDLC model is an extension to the Iterative & Incremental model with an emphasis on receiving user feedback early by releasing a working version of the software early and often.
As the name “Agile” suggests the core principle of this method is agility – being able to adapt to changes. Agile believes that every software project is different and its SDLC model must be tailored to best fit their scenario.
In the Agile model, the work is done over small (2-4 weeks) iterations with having their own software development life cycle at the end of which a working version of the software is released and presented to the customer. You should use project management software to keep everything organized. You can read our comparison of Asana Vs Jira, and Wrike vs Asana to get a sense of how some tools compare.
We recommend giving Tara a spin, though.
The feedback from the customer and the users is gathered and added to the next iteration. If you want to learn more about Agile, we created “The Ultimate Guide: Agile Methodology for Software Development“.
Pros:
- Working software versions are shipped early and often
- Adaptable to requirements changes and customer feedback
- Project progress is divided into small and trackable iterations
- Easy to manage and flexible for the developers
Cons:
- Depends on constant customer feedback
- Requirements changes may mess up the software architecture or the design
- Project deadlines and cost aren’t clearly defined (because every iteration can bring new or change existing requirements)
- The team should be open-minded and handle customer feedback well
Best fit for:
- Dynamic software projects that may change often
- Customers who want to be actively involved in the development process
- Ongoing projects that don’t have a strict deadline
- Teams that want to integrate user feedback early into the SDLC
————-
We’ve covered the six most popular SDLC models and their evolution – Waterfall, Iterative & Incremental, Spiral, V-Shaped, the Big Bang model, and Agile.
In the next section, we’ll quickly go through the Software Development Life Cycle best practices that you can apply in your software company to boost productivity.
5. Software Development Life Cycle – Best Practices
Speaking about the SDLC Best Practices and recommendations there isn’t a fixed set of rules that will work for every type of business or software company. However, we’ll lay down what worked well for us, what didn’t, and the most popular recommendations.
“The measure of intelligence is the ability to change.”
― Albert Einstein
Pay extra attention when choosing an SDLC model
It’s of utmost importance to choose an SDLC model based on the needs of the software project and your team culture. Don’t go with the most popular one blindly.
Imagine going with Agile where two developers are developing a hotel website for a client who doesn’t have the time to give feedback on the software. Or even worse choosing the Big Bang model for a corporation developing high-security banking software.
Educate your team about the SDLC
When following an SDLC model it’s important for your team to be familiar with the SDLC in general. The reason for that is they’ll have difficulties understanding the methodology that you’ve chosen and will get confused with their tasks during the different phases of the software development life cycle.
Tip: A good and effortless way to educate your team on the SDLC is to share this article with them and ask to read it before your next meeting.
Myth: SDLC is only tech guys
“The software development life cycle should include only tech teams.” – WRONG. This misunderstanding emerges from the lack of knowledge about the SDLC and its terms – software, implementation, development, coding. However, “All teams and divisions must be involved in the SDLC.” – RIGHT.
Quick example, even the Implementation (Development a.k.a “Coding”) phase includes designers making designs, legal experts issuing patents/trademarks/legal stuff, and business guys/girls creating business logic and rules.
SOLUTION: We just mentioned it above – educate your entire team about SDLC. (if you don’t have time to do it yourself just share this article with them)
Changes will happen. Be prepared
No matter what SDLC model you use, what project requirements you have, or how good your team is, unexpected changes will happen. A client might change their mind, a loyal team member may leave you for your competitor, or a global Coronavirus pandemic may emerge. No matter what – you should be prepared.
Speaking from experience our suggestion here is to be calm when the unexpected happens. Don’t panic, don’t act emotionally — rationalize and analyze. In the end, you and your team will come stronger after solving the situation.
Other SDLC best practices
These were my top four SDLC best practices and challenges that I’ve experienced during my 6+ years of Software Dev. career. Here I’m going to list the other recommendations that SDLC experts have on the topic:
- Control software quality
- Change the management if needed
- Create smaller milestones
- Write documentation (better late than never)
- Ask the customer for feedback early
- Organize “Knowledge transfers”
- Empathize first, judge second
Conclusion
We’ve covered everything you need to know about the SDLC and how to implement it in your own company.
To recap, SDLC stands for the Software Development Life Cycle and it is a framework documenting the development process of high-quality software that meets customer expectations.
The SDLC framework has 7 stages (0. Validation & Concept Development), Planning, Requirements Definition & Analysis, System Design, Development (Implementation), Integration & Testing, Deployment (Release), and Maintenance.
There are various SDLC models but before going with something of your own it’s recommended to first check the most popular six – Waterfall, Iterative & Incremental, Spiral, V-Model, Big Bang model, and Agile.
If you’re a software company and you’re looking for a tool to help you manage your SDLC (which is different from Jira), I’d highly encourage you to check out Tara AI! Designed to help software teams move faster and deliver on planned release cycles, Tara can deliver visibility into development velocity and help your team keep track of project requirements.
Ready to start the development process? Get Tara for free!