If you aren’t a software engineer, or don’t have experience building software products, you may find the development process mysterious and confusing. You probably wonder, “How does an idea in someone’s head become an operable application?”
In this article, we’re going to lay out the “birth process” for a piece of software, called the software development lifecycle. We’ll show you the individual steps engineers take to turn our clients’ desires into functional tools.
What is the Software Development Lifecycle
The Software Development Life Cycle (SDLC) is a series of stages to create software applications. There are typically seven stages: planning, requirements, prototyping, development, testing, deployment, and maintenance. Most projects require all seven stages, though some developers will combine, omit, or split those steps depending on the needs of the project.
The SDLC is a way to track the development process. By dividing the work into stages, we can analyze each component of our work in order to maximize efficiency and the quality of the final product.
The SDLC also allows engineers to specialize into individual stages. For instance, some developers spend their entire careers testing someone else’s code. Others only work on projects so far as the prototype.
The 7 Stages of the Software Development Lifecycle
Now that you understand the purpose of the software development lifecycle, let’s dive into each of the seven phases. This will give you an understanding of how software applications come to life.
1. Planning
The planning stage is where we outline the entire project. We work with stakeholders (the people who have an interest in the application’s success) to understand the purpose and scope of the application. The goal is to define the app and set boundaries so we get a high-level view of the project.
We also try to bring in sales and marketing at this stage. We want to align the product and marketing as closely as possible so we create something that can be sold well. In many cases, we speak with potential customers and subject matter experts to understand the needs of the market.
Additionally, this is where we provision the team. We create a leadership structure and assign developers to the project. We calculate labor and other costs. Finally, we develop a timetable with target goals.
2. Define Requirements
This stage is where we determine what’s required to meet the app’s purpose. If we’re building a shopping app, for example, we would need product data, a search feature, a persistent shopping cart, a way to accept payments, etc.
This is also where we list any requirements we need to complete the work. If we’re building an app to guide a physical machine, for example, we need that machine. Often we need data sets, style guides, login credentials, or access to certain people in the organization who might help.
Some development shops lump this stage and the previous one into the same category. Admittedly, they’re pretty similar, but many teams keep them separate to better define the flow of work. Think of the planning stage as what we need to build and the requirements stage as what we need to build it.
3. Design/Prototyping
This is where we model the manner in which the software application will work. We use the requirements we just defined to propose the architecture for the product.
In some cases, teams design several approaches and discuss them internally and with the clients (the product owners) and other stakeholders. They evaluate the design based on certain parameters, such as product robustness, design modularity, risk assessment, budget, and time constraints. Once an agreement is made, the design is documented in a report called the Design Document Specification (DDS).
It's important to have a lot of detail here because the developers will follow this document when they write code. Here are some of the concepts the DDS should cover:
Specific programming languages and methods
How data will flow through the app and to/from third parties (if any)
Use of any templates, libraries, or boilerplate
User interface (layout and how users interact with it)
Platforms the app will run on
How the app communicates with other assets
Security measures taken
In many cases, it helps to design a prototype in this stage. A prototype is an early version of the software that demonstrates how it will look and work. It doesn’t include every feature, just what gives everyone a basic idea of the product for stakeholders to see. This is also a good time for anyone to speak up if the product is on the wrong course.
4. Software Development
This is the part of the process where we finally write some code. Depending on the size of the project, the application may be written by a single developer or it might be broken into pieces and developed asynchronously by a team of developers.
Developers build the product according to the DDS. If the design document was detailed or organized, multiple developers should have no trouble building the pieces separately. Smart teams use Access Control or Source Code Management tools to track code changes, ensure compatibility between each other’s work, and meet target goals.
Throughout this part of the process, developers should also maintain documentation. Documentation is essentially a user’s guide for the application. It often includes comments in the source code that act as explainers for themselves and future developers. Documentation might also include separate documents that give more context and can be offered to users to help them use and troubleshoot the app.
5. Testing
Before an app is released to users, it needs to be tested. This is the stage where the development shop identifies, tracks, and fixes bugs and defects until the product meets the standards defined in the planning stage.
Some testing can be automated, like security testing, but other tests require a systematic approach by a quality assurance team. QA testers should ensure that each function works correctly. This is also where the application is tested for performance in regards to speed and resource usage.
Ideally, the bulk of testing should be complete before the client and other stakeholders get their hands on the product. Some bugs will inevitably slip through, but the development phase isn't complete until the product works properly.
6. Deployment
This is the stage of the software development lifecycle where the application becomes available to users. Deployment occurs whenever a new version of the app is available. In the age of continuous deployment, this happens quite often.
Image: ExpositHow an app is deployed depends on the nature of the app. Deployment could be automated where users sign up, pay, and download/access the tool on their own. Or it might require a high-touch model where sales people and developers work through a process of helping users adopt the app.
In some cases, deployment happens in stages based on the app’s current functionality and the business’ strategy. For instance, an app may be released with limited functionality until there’s sufficient testing in a real environment. But in most cases, the app is released as-is with a roadmap of improvements and expansions scheduled down the line.
7. Operations and Maintenance
In the final stage of the SDLC, developers monitor and maintain the product. They fix bugs that are discovered by users or themselves. They watch for security threats and performance issues.
Beyond bug fixes, many products are built using iterative development models that call for constant improvement. Additional features launch new development cycles, where developers, the product owner, and stakeholders start the process all over again. Many products are developed throughout their entire lives.
Respect the Lifecycle
By now you should have a clear picture of the lifecycle of a software application. As you can see, the process is a lot more involved than simply “writing code.” When you hire developers to build your product (whether they are an outsourced team or in-house employees), make sure they are prepared to see your product through the entire lifecycle.
