7 SDLC Phases: An Insider’s Guide to the Methods, Tools & More

What does it actually mean to cycle through the SDLC phases in today’s world? In this guide we will dive into the SDLC phases, breaking down each phase by trends, types of tools and what each phase means for developers and testers. 

Take a minute to look around you. What do you see?

You’re obviously reading this on some sort of device, be it a computer, phone or tablet, and I’m willing to bet the other two aren’t that far away. There’s a good chance you have at least one other piece of technology on you — smartwatch, anyone? — and that everyone around you does too.

We’ve come to depend on these technologies so much that most people take them for granted. But those of us in the software development and testing world know better. All of these devices are powered by software, and there’s a lot of work that goes into making sure that, that software functions seamlessly enough that we can take it for granted.

Users are demanding more and more software functionality at an ever-accelerating pace

Of course, as technology becomes more pervasive throughout our everyday lives and gets increasingly advanced, users are demanding more and more functionality at an ever-accelerating pace. This accelerated pace means that there is increasing attention paid to the SDLC life cycle and the people, processes, and tools involved in successful software delivery.

So what are the latest trends in the SDLC? And what do they mean for developers and testers?

Here’s what you need to know.

Setting the Stage: Overview of the SDLC Phases

At the highest level, all of us in the software development and testing space are familiar with the SDLC as a framework for covering the soup to nuts process of delivering software into production, including everything from planning and developing the software to testing and deploying it.

Here at QASymphony, we like to think about the Software Development Lifecycle in three ways:

  1. The practitioners that define and execute the best practices in each phase of the SDLC
  2. The methods and processes involved in each of the phases of the SDLC
  3. The technology required to execute on those methods and processes

Far too often, the technology used throughout the SDLC is viewed as a replaceable commodity, and that’s a mistake. While the methods used throughout each phase are no doubt the linchpin of making sure everything runs smoothly, the role of technology in executing those methods has become increasingly important.

49% of users expect apps to respond in two second or less

For example, consumer expectations for software quality have increased, and their patience for low quality applications has reached an all time low.  A recent survey claims 49% of users expect apps to respond in two second or less and 80% of users will not attempt to use a problematic app more than three times. Meanwhile, the time allotted for development cycles has decreased, meaning teams are under pressure to deliver higher quality in less time than ever before.

Teams are under pressure to deliver higher quality software in less time than ever

Specifically, SAP reports that its own release cycle is now four times faster than it was even a few years ago and McKinsey finds that embracing a DevOps approach has helped teams decrease the time required to move from code to production from 89 days to 15 days. Against this backdrop, software development and testing is more complex than ever, which makes activities like proper test management, documentation and reporting essential. And the key to getting these efforts right now lies in technology that can help you manage it all.

Based on that mindset, here’s how we like to picture the SDLC phases:

To share some background, we created this graphic to:

  • Provide a jumping off point for companies evaluating technologies in particular SDLC segments (although it’s not meant to be a comprehensive list)
  • Acknowledge the number of different tools and approaches available in the market today
  • Create an annual checkpoint that highlights which segments are growing or diminishing in importance based on new entrants
  • Highlight typical segments commonly pursued to help companies examine if there are any areas they are currently ignoring

The Current State of the SDLC Phases

Taking a first glance at the SDLC landscape as pictured above, there’s really only one way to describe it: Crowded and confusing.

Don’t worry, we’re here to help you sort things out.

Today the SDLC is complex – there are nearly 1,500 technology solutions

The easiest way to start is looking at the seven phases of the SDLC (Plan, Track, Code, Build, Test, Deploy, Monitor), there are several subcategories and nearly 1,500 technology solutions to manage everything. The market can support this because the number of software companies is always growing and each solution typically focuses on a different type of user (industry, geography, vertical, architecture, price, etc.) so the number of variations is potentially endless.

Even broken down as we have it in this landscape graphic, it’s clear that the SDLC is complex. And for those who have been around the software world for a while, you know it wasn’t always this complex. Many trends have contributed to this complexity. For example, the proliferation of APIs has meant that teams can adopt best-of-breed tooling and build their own end-to-end solutions rather than purchasing an all in one solution from the likes of HP or IBM.  It also hasn’t helped than many of the legacy vendors have failed to update their platforms to support emerging Agile and DevOps trends, so the pressure to update to newer tooling is mounting.  

That said, the field will only grow more complicated in the years to come, as the best-of-breed trend continues and more tools enter the market.  Additionally, we would expect that larger players will start acquiring smaller ones to round out their stacks and stay competitive with the new entrants.

And the phases of the SDLC prove an interesting study as well. While we we don’t really expect total redefinition of the seven phases that make up the SDLC, the subcategories that roll up into those phases are a different story. Most notably, their importance will certainly shift over time.

For instance, many of the subcategories identified currently are Agile-based. Since the Agile mindset is still relatively new, those methodologies and toolsets were not part of the SDLC several years ago. Additionally, DevOps is increasing the importance of things like monitoring tools due to their growing role within the delivery lifecycle.

As more teams transition to Agile, the methodologies and toolsets designed for Waterfall will begin to phase out

Finally, as more teams transition to Agile, the methodologies and toolsets designed for Waterfall will begin to phase out. This transition also means that who is involved at each phase is changing, as Agile brings testers into the fold earlier on in the process. With all of this change, it remains to be seen what will come next.

Bringing the SDLC Phases to Life

Beyond these high level trends, what does it actually mean to cycle through the SDLC in today’s world? Let’s dive into the methods and tools that software development and testing teams use most often.

Plan

As the name suggests, the planning phase is all about planning for the rest of the project. This planning should include a project scope that outlines what problems exist and how they will be solved, the timeline for the project and the costs and resources involved, among other key points.

Currently, several methodologies exist for planning software development, although Agile is now among the most popular. Other common methodologies include Waterfall, Scrum, Lean Development, V-Model and Rapid Application Development. Each of these methodologies has its pros and cons, and which one works best for your organization depends largely on your team, your goals and your product.

In terms of technology, many tools can flex to support multiple methodologies with broader support, while others attack a specific methodology with deeper functionality. That said, since Agile is currently the most popular approach to planning, the most commonly used tools are designed for Agile teams. There are Agile tools for smaller teams, such as ScrumOne, JReport and Asana, Agile tools for larger teams, such as Zoho, Quire and GenieBelt, as well as Scaled Agile Framework tools, such as AgileIT, Tract and VersionOne. Across all of these options, flexibility is key, as Agile delivery will vary widely even within teams at the same company and the approach can be drastically different from one company to the next.

Track

Once you have a plan in place, you need to determine how you will track your progress along the way. Tracking considerations should include how you will facilitate collaboration among developers, business stakeholders and testers, how you will document testing, how you will develop user stories and how you will track defects. In recent years, the increase in distributed and remote workforces has increased reliance on tracking as a way for organizations to best measure the engagement and efficiency of their teams.

Methods for tracking progress are very much dependent on the approach to overall planning. For example, in an Agile environment, developers and testers collaborate more closely and earlier on in the entire process than they do in a Waterfall environment. Regardless of the approach, clearly tracking progress and documenting findings and results is of utmost importance to understanding what’s happening, resolving issues and improving for future efforts.

Tools typically used during the tracking phase include those for Agile User Stories like Skytap, AgilePad and OpenProject, those for documentation like Conga, Confluence and Quip, those for collaboration like G Suite, Trello and Zoho, those for defects tracking like JIRA, TrackDuck and Mantis and those for diagramming, like LucidChart, SmartDraw and Edraw.

Code

Next comes the coding phase, which will have a major impact on testing. This phase should include system design in an integrated development environment as well as static code analysis and code review for multiple types of devices.

The coding phase is another one that is impacted by the overall approach to project planning, as the stakeholders who provide input at this phase will differ based on the approach. Once again, in an Agile environment testers will be brought in at this phase to consult with developers, whereas they are typically not brought in at this phase in a Waterfall environment. Methods for coding also differ based on the programming language developers will use.

The proliferation of distributed and remote teams has also impacted the coding phase. Specifically, it’s driven a high adoption of git based code tools and has placed increased importance on code review tools that can help teams around the globe collaborate on new feature code.

Common tools used in the coding phase include code review solutions like GitHub, Parasoft and Veracode, static code analysis solutions like FishEye, TestComplete and JArchitect, IDE solutions like Eclipse, Visual Studio and PhpStorm, mobile development platforms like Apigee, Appscend and MobileFrame, git repositories like Splunk, Planio and DevZing, and other repositories like Asigra, Microfocus and FileHold.

Build

Following the code phase comes the build phase, which takes the code requirements outlined previously and uses those to build the actual software. This phase also covers data management, configuration provisioning, repository management and reporting.

The tools used during the build phase will align very closely with the tools used during the code phase. Build tools are increasingly important in DevOps, in particular, as teams look to build their software several times per day and need to rely on build infrastructures that are reliable and scalable as a result.

Tools regularly used to build software include build tools, such as Jenkins, Circle CI and BuildMaster, repository tools, such as Nexus, SAS and Nuget, reporting tools, such as JReport, Maven and Birst, configuration provisioning tools, such as NixOS, CFEngine and Juju, and data management tools, such as Informatica, TIBCO and MDO.

Test

Once the software is built, it’s time to start testing. The opportunities for testing can be limitless, which makes it important to follow the scope set in the planning phase so that testers know what to test, the order in which to test it, how to identify issues and when testing is considered complete.

There are several ways to approach software testing, none of which are mutually exclusive. Some of the most common approaches used to prioritize testing during this phase include risk-based testing, exploratory testing, test-driven development, heuristic testing and scripted testing. Meanwhile, to complete the actual tests, teams often use methods like test automation (including functional and integration testing), performance testing, usability testing, security testing, compatibility testing, mobile testing, bug tracking, environment management, Beta testing, crowd testing and the list goes on. Finally, both test management and test reporting are extremely important to keeping testing to the project scope and understanding anything that goes wrong along the way as well as areas for improvement.

To support all of these different testing methodologies, teams often use test case management tools like QASymphony and SmartBear for Agile environments or qTest and DevZing for Waterfall environments, unit testing tools like QASymphony, JUnit and Unit.net, API testing tools like APIFortress, SoapUI and eggPlant browser, device testing tools like BlazeMeter, Selenium Grid and Sauce Labs, functional automation tools like qTest, eggPlant or Ranorex, performance and load testing tools like NeoLoad, WebLoad and LoadComplete and exploratory testing tools like QASymphony, TFS/Microsoft and JIRA Capture.

Deploy

Following the testing phase (and the resolution of any issues identified during testing), the software is ready to be deployed to end users.

Deployment methodologies differ based on the type of software, how it will be hosted and how users will access it. For example, software might be produced in a container or hosted via a third party. Flexibility in where these tools can deploy is critical so that teams are not locked into a single cloud provider and have the option to deploy on premise when needed.

Tools often used during the deployment phase include containers, such as Docker, Rocket and Cluster, hosting solutions, such as Amazon Web Services, Microsoft Azure and Heroku, application release automation solutions, such as BMC, DynaTrace and Xebia Labs, and deployment solutions, such as Snap, Puppet and CodeShip.

Monitor

Finally, it’s important to note that software is never “complete,” even once it’s in the hands of end users. Software should be improved over time, which makes monitoring its performance a critically important task. Ultimately, this monitoring will help identify issues and/or opportunities for improvement, which will then kick off the SDLC all over again. Today, many organizations are deploying so quickly that they do not have much time to test, so there are often bugs that are caught in production by monitoring tools, which can potentially trigger a rollback.

During the monitoring phase, you might evaluate any number of factors to inform your efforts for improvement, including system performance from a technical standpoint, the quality of the user experience, user challenges or system health in terms of bugs and errors.

To support these efforts, many teams use BI tools like Clear Story, Datorama and Tableau, user experience tools like FullStory, WebTrends and Piwik, performance tools like AppNeta, Apica and NeoSense, service desk tools like Zendesk, ServiceNow and Cherwell, and tools for logging error traces like Stackify, LogLogic and Logsign.

Making Sense of the SDLC Phases

Understanding the different phases of the SDLC is of utmost importance. This understanding will go a long way toward helping you determine what your team needs in order to work more effectively and deliver a better end product for users.

The first step to understanding the SDLC is identifying what each phase entails and who will lead the charge

The first step to understanding the SDLC is identifying what each phase entails and who will lead the charge.  That leader or group can determine how to go about executing on those needs as outlined above.

The second step requires you to introduce technology that supports your team throughout that execution, and in such a crowded (and growing) field, that can get complicated to say the least.

To overcome this challenge, try following a three-step process:

  1. Window shop regularly: Keep a pulse on what new technologies are entering the field and which vendors are adding new solutions to their stacks (via natural development or acquisitions) in order to have a high level idea of what the landscape looks like.
  2. Pay attention to your process and your stack: Now turn that window shopping inward to look at your own process and stack at a high level. This view should help you identify any gaps in what your team is doing from a process perspective and/or what they’re using from a technology perspective.
  3. Consider individual solutions: The findings from your process and stack evaluation should help you identify needs for specific types of solutions, whether it’s to fix a gap or improve on what you’re already doing. You can then narrow in on those problem areas and consider the individual methodologies and technology solutions that can help resolve those problems. Additionally, the ever-growing exposure of APIs should allow you to fully integrate any new solutions back into your QA stack to overcome and alleviate problem areas.

Keeping Up with the Evolution of the SDLC Phases

If all of this makes nothing else clear, it’s that the SDLC is in a constant state of flux as methodologies evolve and new solutions enter the market. As a result, it’s important to keep up with changes to the SDLC.

Recognizing how difficult it can be to keep track of such a complex and ever-growing landscape, QASymphony is committed to doing the research for you. Our SDLC landscape graphic not only includes all of the technology players in the software development field, but it also illustrates how and where they fit into the SDLC. Ultimately, our landscape graphic is designed to help track changes in both methodologies and technologies used throughout the SDLC.

Most importantly, we will update the Software Development Lifecycle super graphic regularly to track changes in the field and will accompany the graphic with commentary on how the field has evolved as well as our expert predictions on what past evolutions mean for the future of the software development lifecycle.

NEVER MISS AN UPDATE

Subscribe to Our Newsletter

Leave a Reply

Your email address will not be published. Required fields are marked *

More Great Content

Get Started with QASymphony