James Taylor, who authored Managing Information Technology Projects, noted that a “project life cycle encompasses all the activities of a project." And the goal of systems development is the realization of the product requirements.
If you want to learn how to build, deploy, and create high quality software you will want to follow a blueprint.
As Taylor articulated, your goal should be to think holistically about all the activities of a project and how to best manage each stage.
But where should you start?
One answer is to leverage a framework to guide your behavior and work-flows.
One particularly powerful and popular framework is called the Software Development Life Cycle process (SDLC).
In this article I will walk you through the following:
- How SDLC works and why it is used
- Each stage of SDLC and the best practices and methodologies you must be aware of when using it
- I will conclude by citing examples to show the benefits of the SDLC approach.
How SDLC Works and Why it is Used
SDLC consists of six steps which I have diagrammed here for your reference.
In totality, SDLC is a closed loop. This means that each step influences actions that come after it and each stage provides forward looking guidance.
The six phases seek to build on each other in an efficient manner to answer questions and to ensure alignment in your development process.
I seek to take the abstract and provide examples that you, as students and practitioners of software development, can more readily relate to.
For example, if you strive to build software designed for hourly employees, as Zoomshift has done, or time tracking software, you would start at the “requirement analysis” stage.
Here, at this most foundational level, you would figure out what the requirements of workers are when it comes to tracking hours and labor.
You might do this by speaking with hourly employees. Perhaps you would engage in a conversation with managers who lead hourly worker teams.
Another idea is that you could test solutions on the market to better understand the pitfalls of existing software.
You could take notes, sketch diagrams, or build graphs to more deeply understand qualitative and quantitative feedback.
Only after deeply understanding these pain points will you be ready to go to the next phase of SDLC.
Only then can you start the planning phase.
The requirements analysis phase may be tedious.
But by going through these steps you can reduce your time to market, ensure a better product output, save money, and increase the likelihood of product market fit.
Think beyond time tracking.
Think about what you want to build and where your technology passions are.
Figure out the requirements to solve problems in that domain. This is where you start.
Stages of SDLC and Best Practices and Methodologies
Each step must be completed before proceeding to the next phase in the development journey.
Most importantly, the first three steps seek to generate answers to questions and the last three steps are optimized to provide outputs.
- Requirement analysis
- Answer: what problems need to be solved?
- Planning
- Answer: what do we want to do?
- Architectural/software design
- Answer: How do we reach our goal?
- Software Development
- Solve: Let’s build
- Testing
- Solve: Let’s ensure what we have built works
- Deployment
- Solve: Let’s take our solution and use it.
These six phases map to behavior you might already be implementing when scoping, building, testing, and releasing software. But SDLC makes the work-flow standardized and formal.
This is to your benefit: by following specific steps you can easily communicate where you are in the process, and inform others of where you are headed.
Let’s dive deeper into each stage and explain the probing questions and outcomes you will want to optimize for.
Phase #1: Requirements Analysis
This stage of the SDLC forces you to obtain feedback and buy-in from relevant internal and external stakeholders.
Think about my prior examples with time tracking software development. You will need to think broadly about who your “users” are.
Some ideas include your clients, designers, your boss, or other technical representatives on the team.
Ultimately you are looking to answer this question: what problems need to be solved? I find it helpful in phase one to take notes and to actively listen.
When you feel highly comfortable with your answers you can advance to the next phase.
Phase #2: Planning
You are seeking to answer this question: what do we want to do? This question might inspire you to understand the unit economics of your plan (costs and benefits), risk mitigation factors, and expected values.
Much like planning for a vacation, you need to get your possessions organized and think about what bags to pack.
Here is a relevant example.
I have read extensively about the history of Instagram. A tremendous amount of time was spent on the planning phase of the app’s development. This was just at the time social media was rapidly expanding.
How users would interact with the product was still very much unknown.
The founders knew that if the foundational experience was strong (taking, editing, and sharing photographs) then growth, success, and high conversion would follow. This is what they planned for.
The founders spent time on application and website design knowing that if they planned correctly the actual architecting and design stage would be smoother.
They were always looking one step ahead and thinking about the future of social sharing and e-commerce shopping.
Plan for what you can control and be mindful of things you can’t plan for. This will help you have a solid foundation heading into phase three.
Phase #3: Architectural/software design
By this stage you know what your requirements are and what you want.
You are on solid ground to now answer the following question before you start writing software: how do we reach our goal? In short, you need to decide what you are optimizing for and design for that.
Perhaps you are building software that you want to be secure, high-performing, resilient, and efficient. Which of those principles is most important to you and why?
Do the stakeholders from the first phase agree? Ensure that stakeholders are fully aligned.
After the design phase you will start putting “hands on keyboards” and making changes will become more costly in terms of time and money spent. Small variable costs will add up.
There are a few pillars of design that I advise you to consider during this phase: operational excellence, security, reliability, performance efficiency, and cost optimization.
Use these buckets to drive final design decisions.
Phase #4: Software Development
This is the build phase in which you seek not to answer questions but to produce outputs.
Specifically you are looking to show a bias towards action and develop a prototype or system that others can experience.
When you start building, it's critical you follow the first three phases so that your output aligns with expectations.
Get your computer out, make sure your environment is conducive to work, grab a coffee and mug warmer, and turn on your monitor.
In this phase you get to earn the trust of your stakeholders by embodying a builder's mindset.
Phase #5: Testing
I used to see co-workers wear t-shirts that said the following: “Building rocks, testing not so much.”
You can’t produce a final version of a product without eating your own “dog food”.
At the completion of this phase you are able to ensure that what you have built works. Look for bugs or defects. Get second opinions.
Probe deeply to find errors that will slow down the release of your final product. Ensure strong fundamentals.
Phase #6: Deployment
Go take your solution and use it. Launch. Go Live.
Get the stakeholders from phase one to use your software in the wild. Celebrate. Start measuring sales engagement.
Listen to users and iterate because through user feedback surveys and guidance you can start again at phase one scoping new requirements.
Bringing It All Together: The SDLC Approach
SDLC exists to help you reduce your time to market, ensure a better product output, save money, and increase the likelihood that what you build is useful to the stakeholders that you care about.
SDLC is particularly helpful in the world of software development because it forces you to “color within the lines.”
In other words, SDLC will force you to follow steps and to ensure you are doing the right actions at the right time and for the right reasons.
Think of SDLC as a blueprint for success. Following it blindly doesn’t ensure anything - but it increases the likelihood that you will be satisfied with the results.
Software development - as we all know - is a broad domain and can cover website design tools and online forms to more robust machine learning or backend systems.
Whether or not you are coding in the browser or doing more robust development work, you need a plan of action.
Building software can be hard.
It can also be rewarding. SDLC is a guide for technical work, but more broadly it can be thought of as a guide in life.
You can deploy SDLC to many domains.
For example, SaaS content writing follows the SDLC cycle. Before writing content the author must first define the requirements, plan what will be written, and then actually put pen to paper.
SDLC is a great framework for technology entrepreneurs as well.
My friend wanted to start the a company and reached out to me and others for guidance. I advised him to use SDLC to first perform a requirements analysis even though his ambitions were quite large.
I asked him: what problems are you looking to solve? What do your users want? And lastly, how would this platform help you achieve these goals?
By framing these questions around SDLC he was better able to hone in on his ultimate solution and to build the right tools for the right users.
He narrowed his scope and more tightly defined his problem space. He was able to allocate resources to the planning phase before he started to do anything else.
He went on to build arguably the best Instagram growth service that I am aware of. But his field is constantly evolving.
Now software exists to perform the role of a social media scheduler at scale. Eventually he will need to go back to the basics: requirements analysis.
The adoption of his technology is proof that SDLC, when applied and executed correctly, can lead to profound technological and business outcomes. But as with the development of a business, software is never done.
Hence the cycle continues.
Regardless of what you are building - a company, a tool, a complex program, or an entirely new product - you would be wise to deploy SDLC to ensure quality and to help you maintain focus on your customers while you build.
“Building rocks” should be your North Star.
SDLC is a tool that will help guide you along the way.