Consistently developing a quality embedded system within budgetary and timing constraints is a challenging endeavor for many teams. The reasons can be quite varied but from my conversations with clients and teams all around the world from start-ups to huge semiconductor companies, an immature Software Development Life Cycle (SDLC) is one of the leading culprits. In this post, I am kicking off a series that will not just review the major phases in the SDLC but will also dive into each phase and provide expert techniques that can be used to tune-up your own SDLC.
Defining the software development life cycle
The Software Development Life Cycle can be defined as:
“The processes used to consistently achieve the desired software quality for a system within reasonable budgetary and timing constraints”.
The SDLC defines processes and procedures that help teams to avoid common pitfalls that would otherwise result in software rework and debugging. We all know that rework and debugging can have significant business ramifications such as being late to market, budget overages and customer backlash just to name a few. The SLDC is meant to help teams go faster not slow them down!
Software development life cycle phases
The SDLC defines processes that fall across several different development phases. These phases have traditionally consisted of the following:
An SDLC does not require that these phases be followed in a strictly waterfall manner but instead, many modern and successful development teams blend these phases together and then repeat them often. For example, the testing phase has become blended in with the software construction phase. Teams that utilize continuous integration servers and unit testing frameworks are able to test their code while it is under construction so that defects are discovered immediately rather than at the end of the development cycle. This blending has helped dramatically increase embedded software quality.
Slowing down to go faster
Companies tend to want to go as fast as humanly possible. They all have shareholders who want to see profit and growth whether it’s a single owner of a small business or a board of directors and shareholders of a publicly traded company. There is always the dynamic where there isn’t enough time to do everything that is needed to be done and teams under pressure start to cut corners. They start to throw processes out the window! The very SDLC processes that are meant to be guardrails against common pitfalls that will be encountered. The result is then lower quality and a longer development cycle. The trick of course, is to balance the processes in the SDLC so that they do not become overbearing and cost prohibitive which I will be discussing in upcoming posts.
Every team that develops embedded software needs to have a defined software development life cycle that has buy-in from development teams and management. The life cycle has to include requirements, design, construction, testing and deployment. Skipping or minimizing any of these phases will result in an ineffective life cycle that will cost not just money but time and quality. How much are you wasting with SDLC?
Jacob’s Expert Tip of the Week
Take a few minutes this week, even if it’s only 10 minutes, to evaluate your software development life cycle. Ask yourself the following questions:
- Do we have a defined software development life cycle or are we ad-hoc developing our products?
- If we have a SDLC, do we actually follow it? When was the last time it was updated? Has it become too cumbersome?
- If we don’t have a SDLC, how much money are we wasting each year doing rework? How much time? How is that affecting our business and customers?
Most importantly, use these questions to help guide you to identify the next steps your organization needs to take. If I can be of assistance, please feel to reach out to me at [email protected]
You are forgetting maintenance. That requirement drives the rest of the SDLC phase (or better) pretty hard.
In a consumer product, you basically don’t have maintenance. In a product that has to live for 10 years or more (industrial automation for example that would be closer to 20), design for maintenance becomes crucial and is the largest part of the SDLC
I often consider maintenance to be nothin more than a repeat of the SDLC. During a maintenance phase, there should be changes to or new requirements, updates to the design, software construction and testing before deploying the changes. I know that the IEEE Swebok lists maintenance as a separate phase but I generally don’t view it that way. That said, I like a documented SDLC because that allows developers to specify what their process is and what terminology they use. There are certainly variations to how the SDLC is setup and there are more than one correct way to implement them. Thanks for the comment!
Do you recommend any tools when developing SDLCs? For example, I have heard of tools that create traceability between requirements, design outputs, passing/failing of tests, etc.
Do you have reference material you would recommend to review when developing an SDLC? Perhaps future posts will go into more detail?
Thanks for the comment! I’ll be talking about this in more detail in future posts. I would recommend examining the Atlassian toolchain. There are a lot of good capabilities there for SDLC. Also being familiar with the IEEE Swebok is helpful. They have a free book that covers all the details of the SDLC. I’ve used several different unit testing frameworks in the pasts. One I’ve been looking at more closely lately is CMOCK.