What are the SDLC Stages?

What are the SDLC Stages?

SDLC stands for ‘software development life cycle’ – a process that many engineers and embedded systems businesses will be very familiar with. The purpose of the process is to streamline the steps that need to be taken to develop a new piece of software to help businesses and developers work as efficiently as possible whilst still producing high-quality work.

Following the different stages in SDLC is also the best way to measure, track and improve your software development process. A systematic approach means that it is easier to analyse which areas need improvement and measure how changes to your process affect overall productivity and software quality.

You might be new to software development, refreshing your memory or just want to better understand how this approach to developing software saves money, improves efficiency and increased quality. No matter your background, here’s our guide to the SDLC stages.

What is the Software Development Life Cycle?

The software development life cycle is a systematic process that outlines the steps taken to develop pieces of software. It covers all phases from initial research and planning right the way through to post-manufacturing maintenance.

There are between 6 and 8 various stages of SDLC depending on whether certain steps are combined or kept separate. There are also several different SDLC models which employ slightly different approaches to moving through the different stages.

Different teams or companies might have slightly different titles or specifications for each stage of their software development process. The course of this process is the same across the board however, which we will outline in more detail below.

Stages of SDLC

1. Planning and Analysis

The first stage of the software development cycle begins with the gathering of information about what features or requirements the finished piece of software needs to have. This is often either done using customer research or by asking a client for their product requirements.

After the purpose and features of the software have been decided, more detailed planning is required to decide on the resources and budget that will be needed to complete the project. Cost estimations, quality assurances and risk assessment processes will all have to be factored in, along with details of the target audience.

The final stage of the planning phase involves coming up with a roadmap of everything that needs to be completed before the software is ready for use. You can use the remaining SDLC stages to guide this plan, filling in the details of each stage depending on what your software requires.

2. Feasibility Study

Once the details of the software have been decided upon, a feasibility study needs to take place to determine the practicality of the proposed software. Here, all the requirements and components will be listed that are required for the finished piece of software to work.

Feasibility checks usually consider five different factors:

  • Economic: Can the software be created with the budget that you are working with?
  • Legal: Will any legislation or standards interfere with or affect the development of this software?
  • Operation Feasibility: Will the software we create successfully meet the requirements of our client or target audience?
  • Technical: Can we create the proposed software using the technical equipment and skills that we have?
  • Schedule: Can the software realistically be created to a high standard within the time frame we have been given?

The feasibility study will be completed with the help of a ‘Software Requirement Specification’ document, or SRS, which should have been drawn up in the planning stage of the development cycle.

3. Design

In this stage of software development, the requirements and specifications of the software are used to come up with an initial system design. This can include numerous different aspects, which are listed below.

  • Architecture

The architecture of a piece of software describes the overall design, specifies which programming language is going to be used, lists the relevant industry practices and references any templates that are going to be used.

  • Interface

The user interface of a piece of software determines how users are going to interact and navigate the software, and also how the software is going to respond when it is used.

  • Platforms

This aspect simply identifies which platforms or operating systems a piece of software is going to run on. This could be a general platform like Apple, Windows, Linux or Android, or be more specific if you’re creating specialised software.

  • Programming

As well as identifying the programming language that is used, programming will also detail the problem-solving methods that the software is going to use along with how it will perform tasks.

  • Communications

This aspect outlines the methods that the software is going to use to communicate with other pieces of software or devices, such as how it will relay information back to a central server

  • Security

This is a very important design feature, as it determines what security measures are going to be taken by the software to protect the data it handles. It will also describe how you, the designer, will ensure that the software is secure and cannot be altered or infiltrated

Once a design plan has been created it will then be reviewed by either the client or the whole team to decide whether to go forward with development or spend more time changing and refining design features. Prototypes are often developed at the design stage in order to test design ideas, but some SDLC processes avoid this as it can end up wasting time on a design that isn’t taken forward.

Two kinds of design documents will be created in this phase of software development: a high-level design (HLD) document and a low-level design (LLD) one.

A high-level design document:

  • Briefly describes each component of a piece of software
  • Outlines every component’s function
  •  Describes how the components interact and rely on each other
  • Lists database tables
  • Features architecture diagrams

A low-level design document:

  • States each component’s functional logic
  • Lists database tables
  • Contains every detail of the software interface
  • Outlines any dependency issues
  • Features any potential error messages
  • Details every input and output for each software component

4. Software Coding and Development

This fourth stage is often the longest phase of the software development life cycle, as it involves the building and development of the software itself. Using the design documents that have been created in the previous stage, software developers will begin to code the entire system bit by bit.

Depending on the scale of the project or the size of your team, this stage can be completed by an individual or a group of developers. Often, the software will be broken down into its component modules and these will be given to different members of a team to code separately before the whole thing is brought together.

This is also often the longest SDLC stage because if one developer runs into a problem with a single component, it can hold up the whole process.

The coding and development process will need to be documented as it happens so that your team can remember how the software was built and why each decision was made.

5. Testing

Once all of the code for the software has been written and put together, the next phase of development is to run tests to ensure that it is working properly. The functionality of the entire system will be tested, alongside any necessary tests required by relevant safety standards.

Basic checks will include:

  • Checking that code is the same high quality the whole way through the software
  • Ensuring that the code meets all the stated requirements that were decided upon in earlier stages
  • Making sure that the code performs as it should do in every component
  • Finding evidence that all code has been developed following the correct principles

Testing can be done using automated programs or it can be done manually by testing engineers. Any bugs or glitches that are discovered will be sent back to the developers to remove, and this process will continue until the software is working properly.

6. Deployment

Once all the code has been tested and the software is confirmed to be working perfectly, the next stage of development is deployment or implementation. The software is made available for public use, either by releasing it online or by providing access to parties who pay for it.

The release of software may be done in stages so that final tests can be done before it is properly deployed. At this stage, user manuals or instruction videos may also need to be created and released alongside the software so that users know how to operate it.

7. Maintenance

The final stage of the software development life cycle is the one that many people forget or fail to realise the importance of. But the continued monitoring and maintenance of software after it has been released is vital to ensuring that any problems are quickly highlighted and solved so that the software is successful.

The maintenance stage tends to last until a piece of software reaches the end of its life or is replaced with a new version. Bug fixes, updates and new features can be added as needed, keeping the software functioning without any problems for users.

This stage is also key to keeping the SDLC flowing. By maintaining and checking your software, opportunities to create new updates or other pieces of software will be easily identified.

SDLC Models

As we mentioned earlier, there are different models of the SDLC that are used by different organizations and developers depending on product specifications and their industry. The stages involved in each model are the same or similar to those described above, but the approach to development is different.

Waterfall Model

The waterfall model is the most widely used model of SDLC and functions with each stage following on from the next. The end of one stage indicated the beginning of the next one, and each stage involves the documentation of the process.

Incremental Model

This model is very similar to the waterfall model in that there are waterfall processes within it, divided into sections. At the start of the project the requirements of the software are split up, and then the waterfall SDLC model is followed for each of these so that the final piece of software is continuously getting updates and new features.

V Model

The V model is also known as the verification or validation model, and operates with the testing and developments stages happening in parallel. This means that tests are running as initial pieces of software are being tested, and the two different processes are joined by the coding stage at the bottom of the ‘V’.

Spiral Model

The spiral SDLC model is a risk-based approach, which takes elements of other development models to create a system where prototypes are developed regularly after design and testing. Phases are completed in repeated iterations until the final product is created.

Agile Model

The agile model uses an approach and methodology which promotes the interaction of development and testing stages in SDLC instead of one happening after the other has been completed. It also focuses on user experience and feedback and so is more flexible when it comes down to following the initial requirements set out right at the start of the development cycle.

Summary

Whichever model of the software development life cycle you decide to use, following this process is an excellent way to ensure that you do not miss anything important whilst designing a new piece of software. Not only will your development process be more efficient, it will also allow for more accurate pinpointing of potential issues or areas for further improvement, as well as providing a framework to plan around when you begin a new project.

If you’re looking for support in the embedded software and electronics sector then get in touch and we can help you find the right people for all stages of the software development cycle.

Chris Oddy

About the Author

Chris is an award-winning recruitment consultant who has specialised in the electronics and embedded systems sector since 2008. Chris is passionate about technology and customer service.

 

Looking
to hire

We provide contract and permanent solutions to electronics and embedded systems businesses throughout the UK and Ireland.

Looking
for work

If you’re looking for a contract or permanent role within an electronics and embedded systems business, we can help you. Get in touch below.

Job alerts

Sign up to our job alerts and get automatically notified when any jobs come in which match your skill set!