What is “Software Development Life Cycle” (SDLC)?
Simply put, “SDLC is a framework of tasks that aims to improve development and produce a high-quality Software System”. But, that might not explain too much does it? Not to worry, let’s break it down.
Let’s start off with a small analogy.
Let’s imagine a baby. Now, imagine that baby growing and maturing till it reaches adulthood. While he/she matures, the parents nurture him/her and takes care of the baby right? In that same way, a Software System (baby) “matures” and developers (“parents”) develop and improve the application until it becomes a full fledged end-product for a user/customer. And even after deployment of the product, developers maintain or constantly “take care” of it. Hopefully it’s making a little bit more sense now. Let’s dive a little deeper.
For a given organization and software project, people develop a process or list of guidelines describing how to develop, maintain, enhance, or change a given software.
It’s aimed to not only improve the product but to simply make life easier.
Let’s get more technical and break down the 6 steps shown in Figure 1
Analysis: Analysis and setting the foundation is always important. In fact, it is the most important part of any project. It “defines” what the project will be. For this step, developers and engineers conduct user-interviews, market analysis, consult with industry experts, analyze potential risks and plan for quality assurance requirements. One big aspect is determing the “technical feasibility” of the project as well. Sounds like a big word? It simply means to understand what technology to use and what technical approach the team should follow. For example, if my team was building a GPS Tracking System, using Django’s geographic Web framework, GeoDjango, would be a potential approach.
Analysis is to minimize risk and increase efficiency.
After all this information is gathered, the team document their next steps. There exists a document called SRS (Software Requirement Specification) which stores all the product requirements to be designed and developed throughout the entire project life cycle.
Design: With the SRS, the team builds an architecture of the project. With the given requirements in the SRS, the team constructs the design approach and documents this in a separate document referred to as DDS (Design Document Specification). You might be wondering why there’s a lot of documentation being involved in the design process. One of which is to store information in a safe and precise manner but the other is so that information can be passed on easily. Generally, these documents are passed on to be further reviewed by key stakeholders/personnel.
Review includes assessing time constraints, budgeting, product robustness, risks and any third-party dependencies for instance.
After which the design process is finally set!
We could go more in-detail and specific about modules and data flow representation but to keep things simple and clean, let’s end it here. On to the next phase!
Implementation: Developers put your coding caps on as this part will definitely excite you! This is where the development process starts. One thing to note is that if the design process was well done, the implementation or programming is actually very simple. Generally organizations place coding guidelines and programming tools (e.g. compilers, interpreter etc.) which developers are to follow when writing code. Depending on the software being built, high level languages such as Java, Python, C, C++, PHP are selected and used to code.
That’s really the gist of it!
Testing: Okay I made the product but what do I do to make sure it “actually” works. That’s where testing comes in. Developers are known to have a love-hate relationship with testing as it requires a lot of hardwork and patience but it is REALLY important. Testing generally happens throughout all the phases but more focus is placed here. Product defects, bugs, reports, and all the quality standards stated in the SRS are made sure to be handled. In some cases, there is a testing team that uses tools to try “breaking” into the software to see if it’s well secure. After testing, the product is basically done!
Deployment: Now we know our product works but what do I do now? Well, you deploy it! Deployment is really just a fancy way of saying “being released to the public” and this terminology is used often in Software Development. How the product is deployed into the market is really up to the organization but generally a small segment of the product is released and tested by users. With this information, developers/engineers enhance and fix the actual software product before the final release of it. This method of deploying a small part for users to test is called UAT (User Acceptance Testing).
All done? …almost done.
Maintenance: Let’s refer back to our baby analogy we made at the start of the article. We have now created the “baby” but we have to nurture or maintain the baby right? After deployment the work is not just over. Developers need to maintain the product, code and constantly debug problems that arise. As a developer let me assure you that bugs always find their way into code. It’s really one of the most fascinating things in this world, well…to me.
Why maintain? You might ask.
Software is very susceptible to attacks and like mentioned, bugs. Not only do developers need to fix/prevent this but they aim to simplify the code when possible. That might seem silly to a casual programmer but when considering a project that has over 1000 lines of code, it becomes VERY important.
YES! You made it to the end of the article! Hopefully you gained some knowledge on SDLC and key terminology. I made this article easy-to-read and avoided covering very minute and detailed parts of the lifecycle. If you are interested, there are many articles online that go in-depth about this process.
As always please contact me via email@example.com for anything and please provide feedback on my work when you can! I love to better myself!
With that said, thanks for taking your time to read and have an amazing day! — Barath V.