SDLC (Software development lifecycle) — is a process used by the software industry to design, develop and test high-quality software.

Any software passes through six basic steps, starting from a simple idea and ending with its use by the end-users, but what does it look like from the inside? What challenges does the development team face and how does it solve them at each phase of the SDLC? Pavel Gaponov, Project Manager at SolveIt, will comment from an expert’s point of view.

A typical software development life cycle consists of the following phases:

1. Planning and Requirement Analysis

This is probably the most responsible and important of all the steps to creating a successful software system. It is performed by senior Business Analysts, Project managers with the participation of the client, the sales department, and experts in the field. All collected information is used to plan the basic project approach.

In addition, there is the planning of quality assurance requirements and identification of various project risks. The result of the analysis is the selection of various technical approaches that can be used to successfully implement the project with minimal risk. Plan for what you can control, and remember about the things you cannot plan for. This will help you get a foundation to move on to the second phase.

Problem: Mismatched expectations and frequently changing requirements.

The customer and the team don’t understand what the real product benefits will be.

Solution: Determine the scopes of work, agree on a clear, brief requirements document, create a prototype (layouts) to confirm and clarify the final requirements.

2. Defining Requirements

When the basic requirements analysis is done, the next step is to clearly define and document the product requirements and have them approved by the customer. If one of the goals of the first step is to understand and analyze the requirements, then at this step all goals must be spelled out, this is to protect both parties.

It is important to clearly define and spell out what needs to be done, this is done using the SRS (Software Requirement Specification). The document contains all the requirements for a product that has to be designed and developed over the lifecycle of the project.

Problem: A large and long list of requirements.

Solution: Find out the high-level requirements and during the development and communication with the customer, add the requirements specification. That is, the development goes on in parallel and the plan is adjusted in the process.

At SolveIt we always try to be agile and adapt to the customer. A working product is more important than comprehensive documentation.

3. Design the Product Architecture

SRS is a guideline for developers to propose the best architecture for a product. Usually, several approaches are proposed to design the architecture of a product.

All proposed approaches are documented in the DDS (Design Document Specification) and the best design approach is chosen. This approach very clearly defines all the architectural modules of the product, as well as its relationship with external and third-party modules.

Problem: Choosing the wrong architecture.

Solution: Have experienced leads on the development team who can suggest the right architecture, based on their successful experience with similar projects.

4. Building or Developing the Product

This is where product development begins. All program code, all new modules, and features are developed on the basis of the DDS. The better this documentation is written, the faster the implementation will go. At this stage, the development team gets involved.

The written code must be covered by Unit tests and the interaction of new features with other modules is tested with the help of integration tests. These activities are performed by the development team, but not by the QA specialists.

Problem #1: Poor communication between the team.

The developer is not interested in the progress of the project, the problems of colleagues.

Solution: Daily meetings, 100% involvement, Scrum board (interactivity).

Problem #2: Unrealistic deadlines.

The customer wants his product to be ready as soon as possible. The PM tries to explain to the customer what such a rush will lead to, but it’s not enough. The client sets unrealistic deadlines and doesn’t listen to the PM’s objections. As a result, the development team gives up and tries to complete the tasks in too short a timeframe. This leads to critical bugs: the team is out of time, the product quality goes down, the customer is not satisfied, and thinks that the team is to blame.

Solution: PM should stand his ground and argue the deadlines: the client should understand that if the development team is in a hurry, they will not implement some of the functionality. If such a deadline is still critical for the client, we try to identify which tasks are the client’s priorities.

Problem #3: Adding unspecified features.

This is where 99% of customers make mistakes. During development, the client deviates from the agreed terms of reference and wants to add more features to the product. As a result of the growing number of features, the timeframe and budget for development increases, the money ends and only 50% of the product is ready.

Solution: PM should explain to the client what will lead to adding new features to the project, defend his position and stick to SRS. That is why the second phase of the SDLC is so important.

5. Testing the Product

It is testing that basically affects all phases of the life cycle. Product defects are recorded, tracked, corrected and retested. This happens until the product reaches the quality standards that are specified in the SRS. At this point, a team of manual testers or automators get involved in the development process.

Problem: Too much time is spent searching for the causes of bugs. Trying to find and fix bugs after development is completed is a complex process that can lead to a large number of fixes.

Solution: Conduct testing in parallel to tasks, immediately after they are completed.

6. Deployment in the Market and Maintenance

Once a product has been tested, it is released or goes into production. Sometimes Deployment happens in stages, according to the business strategy. The product may first be released in a limited segment and tested in a real business environment. This is UAT (User Acceptance Testing) testing. Then, based on the feedback, the product can be released as is or with suggested improvements.

Once the product is released in the market its maintenance is done for the existing customer base and at this stage, the Support teams get involved.

Problem #1: Lack of feedback, real feedback from potential users of the product.

Solution: Don’t wait for the end of development, but launch the product as soon as possible to get feedback from real users and prioritize further functionality based on their preferences.

Problem #2: Weak client-side project infrastructure.

Some customers prefer to host application servers not on Azure, AWS, Google, etc., but on their internal network. The team cannot guarantee stable performance, due to failures that occur on the client side.

Solution: Warn the client about possible problems, offer solutions to fix them.

These are the six basic stages of the software development life cycle, and it is a recurring process for every project. It is important to note that an excellent level of communication with the customer must be maintained. Prototypes are very important and useful to realize requirements.

By building the system in short iterations, it is possible to ensure that customer requirement are met before the entire system is built. Many system development lifecycle models are based on the idea of saving effort, money, and time while minimizing the risk of not meeting customer requirements by the end of the project.

If you need to develop quality software get in touch with our SolveIt experts! Stay healthy ;)