Software Product Development Life Cycle: How to Choose a Model for Your Project

Like any software development project, the implementation of a software product is complex and tiered. To make things even more difficult, these tiers – or stages – vary by priority and repeatability, thus creating models of the software product development life cycle (SDLC).

Dozens of existing SDLC models address the diverse and individual circumstances of product owners and development vendors, but such a rich choice may be confusing. Sure, a company that provides software product development services can choose an SDLC model on their own. Yet this would mean that you don’t realize your needs and expectations from the product or don’t know how to achieve them, which can bring you at a disadvantage during development and create hurdles in communication between you and the development team.

To help you find your bearings, we break the software product development life cycle down to its basic phases, explain what each of them means, and let you comprise the steps into a model that will be a perfect fit for you and your product development project.

6 phases of the software product development life cycle

First, let’s make sure the entire life cycle is transparent and clear so that you could have a firm grasp on the project.

1. Planning

When we’re talking about the software product development life cycle, it’s appropriate to view planning as a serious preparatory process that includes market research and business analysis. This is also the exact point where you reach out to a development vendor, discuss the product concept, and start considering the SDLC model for the project.

2. Requirements

After planning the concept, you and your vendor proceed to document functional requirements for the product. Together with your vendor’s business analysts, you list and describe all the features you want to be implemented.

The rigidity of your functional requirements plays a large role in defining the SDLC model. Some models imply that all the requirements are strictly set at the very start and aren’t subject to any change further on; some allow more flexibility with changing or adding requirements; and some make adding new requirements during the software product development process almost a standard procedure. The more confident you are in the fact that you will want to change or expand your existing list of requirements during implementation, the more flexibility you need.

3. Design

This stage implies design in a broad meaning and includes the choice of a programming language, hardware/software platforms, and your software product architecture. At this point, the vendor also provides you with the information on your future product’s limitations and discusses cloud hosting (in the case of a SaaS product) or hardware options (in case your software product is a part of equipment or a device). User experience and user interface design belong to this stage as well.

4. Implementation

After you, as a product owner, approve every decision made at the design phase, your vendor proceeds to give your requirements a tangible form. Depending on the SDLC model of your choice, this stage can deliver you either the full product or only some part of it.

5. Quality assurance

Quality assurance (QA) should always go in line with the implementation phase. All testing processes should be launched a short while after the start of development, so that the errors could be eliminated at earlier stages and won’t drag on in code. In the case of large-scope projects or features, this is paramount.

6. Support

On this stage, your software product – or its features – is exposed to working conditions. It can be released on the market, installed on specific equipment or integrated with a certain system. Most likely, your vendor assists you in these processes as well as in further maintenance, but you can form an in-house support team or turn to another vendor for support services as well. Possible fixes and updates of the functionality delivered during the cycle belong here as well.

How to choose an SDLC model according to your needs

Now that we’ve covered all typical phases of the life cycle, let’s focus on the possible SDLC models these phases can form, as their duration, priority, and repeatability vary. You may already have one in mind or decide on one after reading the sections below, where we describe the models from the perspective of your needs as a product owner. There’s a comprehensive guide to SDLC model types on our blog, so feel free to refer to it in order to learn in more detail about any specific model.

Commonly, there are 3 parameters that describe your needs: release frequency, requirement flexibility, and cooperation approach. Each of these parameters can be put on a scale, with two distinctly countering options on the opposing sides and more flexible options in-between. Each model has its place on each of the 3 scales.

1. Rigid requirements ↔ Flexible requirements

As we’ve already mentioned, the SDLC model can define how flexible the requirements for your software product are. The models that make you set strict requirements at the very start and don’t allow any changes are Waterfall and V-model. The models that are quite rigid but still offer some room for changes are RUP, Iterative, and Scrum. In their turn, Spiral, EX, and Kanban make for the most flexible models, Kanban being the most flexible of all since it implies frequent changes during development.

2. One major release ↔ Continuous delivery

Think about how you want to see your product grow. Would you like to launch a development project and see a full-fledged product after the final and only release? Then your choice is either Waterfall or V-model. However, pay attention to the fact that these two models are mostly suitable for small projects. With large ones, a single final release poses a risk of a larger number of bugs due to a larger amount of code for the developers and QA specialists to keep track of.

All other models, including Iterative, Scrum, RUP, and Kanban, imply regular releases at set intervals (from 2 weeks to 2 months) and represent ‘iterative’ delivery, where you get a working product early in the development and then see it gradually evolve. In other words, your product is created step-by-step and new features are added to it on each new iteration, consisting of all SDLC stages. Any coding errors or inconsistencies with your requirements can be promptly spotted and, hence, quickly fixed.

3. Documentation ↔ Communication

The level of your involvement in the project and the approach to collaboration with a vendor are important parameters too. Many models – Spiral, V-model, and Waterfall – suggest very detailed documentation and scarce communication, while Iterative and RUP models try to balance documentation and communication out. In the models of the Agile group – Scrum, EX, Kanban – direct and frequent communication is a cornerstone.

While there are great benefits in open discussions specific for the Agile group, you should consider in advance the appointment of a person who will be representing you in them. Otherwise, all the meetings the Agile models imply may not fit in your business agenda.

Wrapping up

By letting your software product development vendor take the lead and choose an SDLC model on their own, you risk losing control of the development project as a whole. Consider the requirements, delivery, and communication strategies we’ve described above before defining the model that is convenient for you. This way, you’ll avoid possible collaboration challenges and will always maintain hold of your project.