A software development life cycle (SDLC) is a methodology that defines the process of creating a software product. We’ve talked about some of the widely-used SDLC methodologies in one of the previous posts. In this article, we’d like to focus more on different SDLC phases without connection to a particular methodology. It will help to understand better what stages make a development life cycle. Regardless of their sequence and timing, these stages and activities that take place during each remain pretty much the same.
A software life cycle starts at the moment the decision to create a software product arises. It ends when the mentioned product stops functioning. In between, a company builds software and maintains it, often developing new features on the way.
The phases that make a life cycle are requirements gathering, concept development, product development, testing, and maintenance. Let’s take a closer look at each of them.
In all SDLC models, the process starts from research – at least it should. To determine a product-market fit correctly, a project team needs to know the market they are about to enter and their potential users.
As a rule, the requirements gathering stage begins with a justification of the need to create a new software product. This research may involve company employees or potential users. If the demand for a product exists, a team concludes their research by outlining the basic requirements for future software.
Then, a project team proceeds to finalizing the product concept. This set of procedures may require additional user and/or market research to understand better what functionality and highlights the product should have. Usually, there are several working concepts, but only one will make it to the following stages.
There are two artifacts usually generated during concept development – a technical task and a technical project.
A technical task is a document that considers the tech specifications of a product, design peculiarities, and marketing requirements. In a way, it defines a range of tasks to be completed during the development process. It also features a final list of features, technologies to use, and the scope of work. As a rule, a Product Owner/Manager or several stakeholders create a technical task for the development team.
Basically, a technical task covers the desired requirements. A technical project encompasses other documentation – Product Specifications, Test Strategy, Test Plan, etc. In other words, a technical project is a set of explanations and instructions on how to proceed with the development and QA processes for this particular product.
When a development team is created (or assigned to the project), they proceed to coding. Often, this stage starts with creating a prototype of the entire software system or its parts. Then comes the physical implementation of the system elements. The team creates technical documentation, writes code, and starts debugging. Developers also cover unit testing. The outcome of this phase is the first working version of a software product.
After the initial version of a product is ready, it is time for a QA team or a software testing company to join. Depending on a company’s processes, it can happen after the complete functionality intended for release is ready or just certain features. In the first case, we are speaking about the traditional models, such as Waterfall. In the second case, a QA team doesn’t wait until everything is assembled but joins when something to work with appears, which is typical for an Agile SDLC.
Testing comes hand-in-hand with software design and implementation. There is a list of significant aspects to check: compliance with the requirements and standards, design, accessibility, performance, and more. The result of testing activities is the elimination of shortcomings and improvement of its quality. In other words, the QA team detects bugs, provides reports on product quality, and suggests improvements (optionally). The development team fixes bugs and implements code changes if necessary.
Neither the quality assurance nor development process ends after the release of a software product. Usually, they are ongoing. The support of software system performance, user training, and keeping documentation in order are some of the things the maintenance team is to cover. Maintenance is also about adapting the supplied software to new conditions, introducing changes to product features and documentation in case issues arise during product exploitation. This process continues until the product is decommissioned and the system development life cycle is over.
The purpose of using software life cycle models is to create an effective, cost-efficient, and high-quality software product. As you already know, the details of a software development cycle vary from company to company. The order and duration of the phases can be different, as well as the implementation of the basic principles.
Nevertheless, there are certain industry standards meant to systemize the common practices of software development and maintenance. One of the best-known and commonly used is ISO/IEC 12207 – an international standard for an SDLC process. It defines the processes essential for developing and maintaining software systems, dividing them into three groups.
Main processes:
Supporting processes:
Organizational processes:
The document states the activities and outcomes of each process. ISO/IEC 12207 was introduced in 1995 as the primary standard for the development processes. Since then, it has been through several revisions.
Why is it important to follow software development life cycle phases? Companies that plan to develop a new product should consider all the aspects of an SDLC. One of the frequent mistakes is forgetting to allocate resources for product support and plan it properly. As a result, businesses risk ending up with a product that needs further improvements but no one to work on them.
Just like that, the lack of knowledge of SDLC phases puts a team at risk of missing something. For example, if a company doesn’t have an in-house testing team, they should start looking for an outsourced QA partner early. If you remember that the QA phase is coming, you can be better prepared for it. Otherwise, there is a risk of a delay or insufficient QA coverage.
Whether traditional or Agile, an SDLC model helps to plan the phases and activities in detail, so that as least surprises as possible pop up on the way. It also helps to realize that a product is always broader than a development. It starts with an idea and requires support until retirement. Stakeholders and developers should be ready that users can request improvements. Being familiar with various SDLC models helps to understand this from the beginning.
Quality control is obsolete. The spread of Agile, DevOps, and shift-left approach has pushed traditional…
Be honest, if your phone disappeared right now, your world would be in shambles. Data…
Teams have a love-hate relationship with Android. It’s highly customizable and has an incredibly vast…
Apple applications are easy to test. Compared to Android, that is. But when it comes…
Result-driven QA isn’t always about planning and strategizing. Sometimes, the best thing for your product…
A flimsy UI doesn’t lead to customer frustration, negative reviews, and high churn. When people…