Agile is the next big thing, everyone knows it. Some people won’t budge, however. “Waterfall is still as good as ever if you practice common sense implementing it,” they argue. Chances are you already have some idea of what this is all about. But if you haven’t, then there is no better time to learn about how the process of software (should) go. Enter the world of software development lifecycle methodologies.

Big words, but it is not that hard to digest. Before we go into all the details, let’s aim for the bull’s eye and examine the fascinating subject called the software development lifecycle (or SDLC as we shall call it going forward).

Put simply, SDLC is the whole process of creating a piece of software. Everything (defined as distinct steps), from planning out the software to delivering it to the client and then a bit more, is a part of the massive undertaking we call SDLC.

A long awaited label

 

If it seems counterintuitive that we’d have special terminology for what is basically a software developer’s job, then a bit of history might be due. The “software developer” job has been around for a long time, yet no one was yapping about SDLC back when computers used to take up whole rooms. In fact, no one identified SDLC as a matter that deserves special attention until the 1960s. 

Around that time software was getting bigger; both the demands and stakes were higher than ever in the wake of businesses recognizing the advantages that can be gained from efficient software. Developers and business managers alike, quickly realized how a project could go awry not because of lacking programming skills, but because of a flawed process or workflow. The evolution of SDLC came out of a need for disciplined and orderly control of the software development through all of its stages of life (hence lifecycle).

 

So what does this all mean? It means that, now, everyone agrees that it is essential to place labels on every stage of development and have the entire team using the same terminology for the software to reach the point where it does what it was conceptualized to do. 

On a small scale, it is entirely possible to mentally manage the development of an application. You can do it all up in the air and you’d still have much brain space to spare. The issue lies in when the software scope is too big for one person. An environment of many developers, endless client demands, and a lot of interdepartmental meddling is not one where any person can keep track of where and how the software is going. Formal recognition of SDLC shines in such a cluttered environment.

The software industry has come a long way and learned from too many mistakes that SDLC is quite standardized now. While variations, extensions, and detours are to be found from one company to another, SDLC roughly (and most simply) boils down to the 6 main stages that everyone goes through:

Planning

The first phase, not surprisingly, is planning. What is surprising, however, is how few technical people are usually involved in this step. Make no mistake, software developers need to be in on this meeting, they just need to share their throne with project managers, human resources staff, financial officers, and other people not regularly linked with software development. 

Planning in this capacity refers to the planning of the entire project. This stage means that the company carrying out the lifecycle needs to assess its capacity, estimate potential cost, determine the expected cost, and lay down schedules. During this phase it is a good idea to also assess any risks associated with the project and plan quality assurance requirements (yes, this early on).

Designing

Next, depending on who you ask, comes the designing phase. With requirements well documented and understood by all the involved parties, it is time to start to look for ways to meet those requirements. Prototyping is very welcome in this stage of the SDLC. Here, the product architect and software developers start designing the application with an end goal of producing a design document that lets them move forward without fear of straying from their requirements.

Implementation

There is not much to be said about implementation; software developers just start doing what they do best, as fast and as efficiently as they can.  However, it is important to notice that this phase, more than any other, can be altered by the specific SDLC model used as we will discuss further.

Testing

One of the most cited benefits of proper implementation of an SDLC methodology is that it helps produce significantly more robust, bug-free software. In the testing phase, developers attempt to find and fix any defect, flaw, or bug with their code. Unit testing, usability testing, and performance testing are some of the common terms that are thrown around this phase.

Deployment

This is the big day, month, or minute. Depending on the market and nature of the software, deployment can take any form suitable. In most cases, you will want deployment to be an automated and seamless process whether you are deploying in stages for different segments, delivering to the client on day 0, or just releasing it all at once. But wait, there is more.

Maintaining

Arguably the longest phase of the entire SDLC is Maintaining. Most people hold – quite gladly – the misconception that most of the work is done as soon as the software is deployed. However, the maintaining phase is an ongoing process of its own. Even though in the most air-tight development cycles, some bugs are going to slip through. Not to mention additional demands by the client, the discovery of security vulnerabilities, unmet requirements, continual system(s) support –  it’s a whole world.

Now what?

Now that you know enough about SDLC to flex on your (non-developer) friends, it might be a good time to consider what SDLC really brings to the table.

First of all, when done properly SDLC can allow for very high levels of control throughout the entire lifecycle. When everything is either documented or at least well communicated between all parties involved, developers benefit first. SDLC makes it a lot easier for developers to know exactly what they should be working on as well as see it in the larger scope. SDLC is all about communication.  Not only does SDLC create well-defined communication channels but it also goes to ensure they are effective by providing a unified vocabulary. 

So, it comes as no surprise that a well-supervised application of SDLC can be one of the most effective weapons in combating security vulnerabilities. If aimed towards the task (remember, during the planning phase), SDLC can help greatly reduce security vulnerabilities at each phase. Intense and inclusive planning decreases the margin of human error. Architecture built on proven and familiar design patterns goes a long way in preventing security vulnerabilities from ever making it into the final software. A distinct phase of testing further sifts out any potential vulnerabilities. While it is not perfect (nothing is when it comes to security) SDLC does a good job by attempting to fight back a little in every phase. 

Discussing software development lifecycle methodologies led us down this whole rabbit hole. It is only proper to delve a little into what those trendy “Agile” and “Waterfall” terms mean. Basically, Agile and Waterfall are ways of putting those 6 phases into practice. More and more models have been popping up recently to varying levels of success.

Waterfall is the more classic model of the two. It takes a straightforward approach to SDLC, exactly what you would expect if all you knew about SDLC was the 6 phases above. Waterfall goes through every phase (companies can have their own twist on the phases of course) in precise order, treating each phase as independent of the rest. While this reduces confusion and is the most straightforward model, it fails to account for uncertainty in its unaltered form.

Agile, the model most developers swear by these days, is all about being agile. It arose in response to waterfalls lackluster performance in the face of swiftly changing environments. Agile revolves around going into “sprints” of feedback loops, visiting the phases more than once if need be and being open to change at most stages of development without a lot of turbulence.

 

“Experience keeps a dear school, but fools will learn in no other”

Benjamin Franklin

SDLC evolved naturally out of the development industry’s countless trials (and failures). For the modern developer, there is little reason to fall for the same mistakes people fell for decades ago. We have more than a few reliable and proven SDLC models, and the benefits are far-reaching. A good understanding of SDLC is crucial in the modern work environment, even for those of us who never have to write a single line of code.

Debricked might not be the magic solution that makes your SDLC run buttery smooth, but we can definitely make it easier for you to develop secure, high quality software. Our tool helps you choose the right open source dependencies to make your software development smooth, quick and safe. Try us out today! We offer a free 30-day trial, and if you have any further questions we are happy to get in touch.

Write A Comment