Software Product Development Process: Ultimate Guide
Reading time: 30 minutes
When both the contractor and the client are on the same page about the software development process, it is easier to achieve project success. The client gets what he expected and the contractor fulfills the obligations and delivers a quality product within the deadline. Read this article to learn about the software development process at Azoft, and the value each stage of the development brings to our clients.
What is the Software Development Life Cycle?
The Software Development Life Cycle (SDLC) is a schematic diagram that includes the phases of software development. The development cycle provides a pattern that makes it easy to design, build, and release quality software. The output should be a cost-effective product that meets the business requirements.
The Six Stages of the SDLC
At Azoft, we break down a project into six stages:
- Planning and estimation
Not all steps need to be fully completed. For example, a customer can turn to us with elaborated requirements documents and a completed design. In this case, we have not participated in the analytics and design stage.
Each step results in an output – an idea, document, diagram, or piece of working software – which becomes the input for the next step. This goes on until you reach your goal.
That being said, the software is never really “finished.” Even the release of your first version can be seen as just another step in the lifecycle of your software.
Now, let’s explore the purpose of each stage.
1. Planning and estimation
First, a client contacts us with an idea of a product. It can be a document of several pages with a detailed description of the project or a couple of paragraphs describing the general concept.
Then, the account manager contacts the client. He asks questions in person, by phone, or by mail to understand the essence of the project. The key purpose here is to figure out how complete and clear the requirements for the project are.
Why are requirements so important? When you order a service or a product, requirements help you get what you expect, namely the features that are important to the customer. In our daily lives, we constantly formulate requirements. Imagine you need to buy a laptop. To select the most appropriate device, you need to determine how you will use it (e.g. to search for information on the Internet, to work with photo and video editors, to play video games), choose a convenient size, and consider various other factors that are important to you. In this simple case, documenting the requirements is unnecessary. It’s easy enough to remember them. But when it comes to building complex software that must perform many actions, you can’t go without writing the requirements. If the developers do not get a complete and clear description of what the program should do, the result will often leave the customer unhappy.
Based on the initial requirements, we at Azoft prepare a preliminary estimate of the development. If the customer accepts it, then we agree to detail the requirements. This is when the analytics stage begins.
At this stage, the account manager clarifies the contract terms, approves the payment process, and other important details. Depending on the goals of the project, Azoft offers its clients one of the two principles of working on projects:
- Fixed price. Suitable for projects with clear and detailed requirements, which are set down in the software requirements specification. In this case, the budget and deadlines are approved after analytics and re-estimation. We do analytics and re-estimation to understand the tasks better.
- Time and material. The method is suitable for projects that require regular changes in the project’s specifications or to add new components in search of the desired solution. The client pays for the actual scope of work.
When both parties agree on how the work will be arranged, the account manager sends the contract signed by us. The project manager joins the project. He coordinates people and processes to ensure that projects are delivered on time and produce the desired results.
Thus, at this stage, together with the client, we determine the:
- preliminary project evaluation and the scope of tasks
- preliminary project budget
Analyst helps the client and the development get on the same page regarding the outcomes of the product, namely the result, purpose, and functions of the product. To achieve this, an analyst is included in the project.
The goal of this stage is to collect the client’s requirements for the project and translate them into the language of developers. Tasks for the analyst vary depending on the scale of the project and the quality of the initial requirements. Generally, the work of analysts boils down to the following specific tasks:
- define the client’s business objectives
- clarify, formalize and agree on requirements
- define and agree on priorities based on requirements and constraints
Why analytics stage is so important?
It often has to go on through the whole project. There is a perception that the analyst’s work ends after the preparation of documents and with the start of development. This might be true when there are no changes during development. In fact, the analytics stage doesn’t end after the start of development, it continues. Analysts take the role of liaisons between the development team and the customer. They help answer emerging questions from both sides.
It helps to get the full picture of the project and harmonize the views of stakeholders. Usually, everyone is certain that they understand what features are needed. However, when the analyst begins to describe the purpose of features, it turns out that different stakeholders see the same tasks differently. Moreover, the more specific the description of the product, the clearer it becomes that stakeholders also see it differently. Since in reality the software will operate in a certain way, it is much more cost-efficient to figure out at the analytics stage exactly how this or that functionality has to operate. During the development stage, newly identified requirements can significantly increase the project timeline.
It helps to make sure that the requirements are interpreted correctly to developers. If there is no dedicated analyst on the project, it can lead to misunderstandings between the customer and the developers. And this often results in multiple undesirable changes in the project. It is important to note that the problem in such a case is not malice. The problem lies in perception, from the terms used to the concepts discussed. The issue with misunderstandings is that they can lead to delays, a bloated project budget, and a mismatch between the results and business goals. When there is an analyst on the project, the customer can control how the requirements are “translated” to developers.
To do their work, analysts often use the following artifacts:
- Vision. It defines the boundaries of the project. Based on it, analysts define the whole set of artifacts needed for a particular project.
- Scope of tasks. Scope is a part of Vision. It helps to determine tasks and assignees.
- Description of entities. It describes logical relationships between entities.
- Diagrams. They are used for a visual descriptions of processes, algorithms, relationships between entities, and other important concepts.
- Prototypes. They represent an implementation option for an interface. They help to understand the main functionality, to determine the user’s path and to avoid gross errors in usability.
- Description of interface behavior. It is necessary for a clearer understanding of how the interface works, what rules exist and how alternative scenarios are processed.
- Non-functional requirements. They define system attributes such as security, reliability, performance, maintainability, scalability, and usability
- User documentation. It explains how the user can use the program.
Here is an example of a prototype that we created while working on the iFarm information system
Thus, the result of the analyst’s work is the predictable final outcome of the project that corresponds to the tasks set.
The goal of the design phase is to make the product enjoyable, understandable, and user-friendly.
At this stage, the designer actively interacts with the analyst. Together, they create a design based on a prepared set of artifacts.
Sometimes clients turn to us with a ready-made design. If the client does not have a design, we create the UI/UX from scratch. After that, the analyst thinks out the logic and creates the basis of the graphical interface. Using this basis, the designer starts working on the visual part. The designer is responsible for creating and designing web elements that optimize user experience. For this, taking into account various use cases, the designer creates:
- a map of screens,
- graphic elements,
- a detailed prototype.
First, we approve the design concept with the client. The point of this step is to try on the corporate identity on a few “naked” prototypes. We show our version to the client, get feedback from them and, taking it into account, we refine the screens. Then, we work with the rest of the prototypes in the chosen direction.
We create interactive prototypes at the request of the client. With their help, the client can see how the product will look and how it will react to user actions, taking into account the planned functions.
Above is an example of a design that we created while working on the iFarm information system. You can find other examples of our work on Behance.
As a result of this stage, the design layouts are approved by the client and handed over to developers.
After the design phase, the frontend developer works with the layout. The goal here is to “animate” the layouts of the designers so that a user can see and interact with them directly. To create the front end, engineers use a combination of HTML, CSS, programming languages, frameworks, and libraries.
The result of the work is static pages of the future site that match design layouts. We stick to the pixel-perfect approach. While working on the client-side of the user interface, the front-end team prepares requirements for back-end developers.
The backend is a set of hardware and software that implements the logic of the application. In other words, this is what happens in the background, outside the user’s browser and computer. The backend includes:
- the administration panel,
- data management,
- the logic of their transfer at the front-end requests.
The purpose of back-end development is to ensure that the response from the server reaches the client and the designed blocks function as desired. Additionally, the backend is meant to create a convenient and safe environment for filling and updating content on the site for the customer.
As the code is written, our developers monitor its quality. High-quality code speeds up development as it reduces time spent on debugging. The main practices that we use are:
- linters – to find bugs and misspellings during development
- CodeReview – to ensure code quality and share knowledge within the team.
Depending on the specifics of the project as well as customer preferences, we can adhere to various design standards – CodeStyle. These standards keep your code consistent, making it easier to read.
Our Senior Developers have commercial experience in all the most popular frameworks: Angular, React, Vue. Our backend Senior Developers have experience on Yii2, Laravel and Symfony.
The result of this stage is software that is ready for testing.
Now that the code has been written, testing is used to ensure that all pieces of software perform as expected.
QA engineers check for compliance with design and technical specifications. In testing, they use test documentation, to conduct manual and automated testing. All this helps to check the work of different software parts of the project and to minimize bugs.
QA engineers get to work when the client sends the requirements for the project or its part for which we are responsible. Before testing a project, testers analyze the documentation, clarify requirements, and participate in discussions during development. For more information on how we do testing, check this article.
Thanks to the work of testers, customers:
- save on budget. Bugs discovered after a product launch are more expensive than earlier bugs.
- ensure business security. For example, if the software includes a payment system, it is important to check all possible cases so that, when transferring money, they will be credited to the correct account.
- protect the reputation of the business. If you release a product with bugs and users are not happy about it, it will be difficult to convince them in the future to use the product again, as well as future products.
The result of this stage is a product that is ready for release on the market.
6. Maintenance and updates
When the product is tested, we hand over the finished project to the client. This could mean, for example, deploying the project on the server to the client. We also help to choose a server and its configuration.
After the release, Azoft does not stop participating in the life of the project. We provide free support for the project for a year from the date of launch. If you suddenly need to fix something, we will do it for free and it will be treated as a top priority.
If during the first months after the product’s release it becomes clear where and what needs to be finished or redone, then we offer the following options: conclude a maintenance agreement or start a new development phase taking into account new data.
The Six Methodologies of Software Development
There is some variability in the passage of the life cycle stages during the development and implementation of a product on the market. For each product, this happens in its own way, but in order to manage the process, SDLC models were formulated – a simplified and generalized idea of how the product develops. In reality, the life of the product does not fit any exact model.
Among the SDLC methodologies, the following are the most well-known:
- Rapid application
Let’s take a closer look at them and see what they have in common and how they differ from one another.
1. Waterfall Development
What it’s about: It provides for the sequential execution of all stages of the project in a strictly fixed order. The transition to the next stage means the previous stage’s work has been completed. Requirements, determined at the analytics stage, are strictly documented in the form of technical specifications and are fixed for the entire period of project development.
The stages depend on each other and the next one begins when the previous one is completed, thus forming a translational (cascade) forward movement.
- Complete and consistent documentation at every stage;
- It’s easy to determine the timing and costs of the project.
- The transition from one phase of the project to another assumes the correctness of the result (output) of the previous phase. However, the inaccuracy of any requirement or its incorrect analysis may lead to the need to “roll back” to a previous phase of the project and the required revision not only knocks the project team off the schedule, but often leads to an increase in costs. Thus, using the Waterfall approach alone is unrealistic for the majority of projects.
2. Agile Development
What it’s about: Generally, Agile is a set of values and principles that help in decision making and a family of different approaches to software development. Most Agile development methodologies aim to minimize risk by reducing development to a series of short cycles, called iterations (or sprints), which typically last two to three weeks. Each iteration itself looks like a miniature software project and includes all the tasks necessary to issue an increment in functionality.
Agile methodology values:
- People and interactions are more important than processes and tools.
- A working product is more important than comprehensive documentation.
- Cooperation with the customer is more important than formally agreeing on the terms of the contract.
- Being flexible and ready for change is more important than following the original plan.
Agile method has become the foundation for a number of Agile approaches, including:
- Extreme Programming
- Lean, and more.
- Product backlog
- Sprint planning
- Sprint backlog
- Release working software
- Feedback and validation (add to backlog)
- Planning the next sprint
The most common Agile framework is Scrum, which can be schematically depicted as follows:
- The use of Agile methodologies allows you to get a better product since quality assurance is carried out at the end of each sprint.
- In addition, Agile development is easy to start, quickly responds to changes, and also allows you to maintain the closest possible connection between the customer and the project team in the course of work.
- Getting a product that can be used as early as possible – (MVP) Minimum Viable Product. It also makes it possible to quickly assess the current and potential effect of the product, as well as potential costs, and make a decision on further product development or project closure, if necessary.
- The need for the constant participation of the customer.
- The lack of stable requirements for the final result.
- Not appropriate for projects with extremely tight budgets and timelines.
3. Incremental and Iterative Development
What it’s about: The incremental and iterative software development approaches are a middle-ground between the structure and upfront planning of the Waterfall method and the flexibility of Agile. They involve breaking the project life cycle into a series of iterations, each of which resembles a “mini-project,” including all development processes applied, resulting in smaller releases of functionality compared to the project as a whole. The goal of each iteration is to deliver a working version of the software system with the added feature working in harmony with all of the previously implemented parts of the software. The result of the final iteration contains all the required functionality of the product.
- reducing the impact of serious project risks in the early stages, which leads to minimizing the upfront costs of eliminating them;
- organization of effective feedback of the project team with the consumer (as well as customers, stakeholders) and the creation of a product that really meets the client’s needs;
- focus of efforts on the most important and critical areas of the project;
- continuous iterative testing to assess the success of the entire project as a whole;
- early detection of conflicts between business requirements, models and project implementation.
- The need for more intensive project management may be required.
- Requires detailed planning and architecture-building early on. This means this model isn’t ideal for smaller projects or teams without a clear, long-term technology plan.
- It may be difficult to pin down an end date for the project.
What’s the difference between Incremental, Iterative, and Agile?
The incremental model implies that each increment builds a complete feature.
In the Iterative model, you’re building small parts of all features.
The agile methodology combines aspects of both approaches. In each Agile sprint, you build a small portion of each feature, one at a time, and then gradually add functionality and new features over time.
4. V-Shaped Development
What it’s about: the V-Model is a variation of the Waterfall methodology in which development tasks go from top to bottom on the left side of the letter V, and testing tasks go up to the right side of the letter V. Horizontal lines are drawn inside the V to show how the results of each of the development phases affect the development of the system testing at each of the testing phases.
Each stage of the V-shaped process is followed by a strict “validation and verification” step where requirements are tested before moving on.
- Business requirement specification
- System requirement specification
- High-level design
- Low-level design
- Unit testing
- Integration testing
- System testing
- Acceptance testing
- strict stages;
- test planning and system verification are performed at early stages;
- improved time management when compared to the Waterfall methodology;
- intermediate testing.
- The model does not provide opportunities for work with parallel events.
- The model does not account for the introduction of a requirement for dynamic changes at different stages of the life cycle.
- Requirements testing in the life cycle is too late, so changes cannot be made without affecting the project timeline.
5. Spiral Development
What it’s about: The Spiral development methodology represents a software development process pattern that includes ideas from iterative and Waterfall models. Its essence is that the entire process of creating the final product is presented in the form of a conditional plane, divided into 4 sectors, each of which represents separate stages of its development: defining goals, assessing risks, developing and testing, and planning a new iteration.
In the Spiral methodology, the path of the product being developed is depicted as a spiral, which, starting at the planning phase and unwinding with the passage of each step. Thus, at the exit from the next round, we should have a ready-made and tested prototype that complements the existing build. A prototype that meets all the requirements is ready for release.
The main feature of the Spiral model is that it’s focused on determining project risks. A corresponding stage has even been highlighted for risk assessment.
- Risk Assessment
- Development and validation
- Evaluate results and plan next “loop”
- improved risk analysis;
- good documentation of the development process;
- flexibility – the ability to make changes and add new functionality, even at relatively late stages;
- early creation of working prototypes.
- risk management requires the involvement of highly qualified specialists;
- the success of the process is highly dependent on the stage of risk analysis;
- hard to do in practice due to the time and costs associated with taking such a calculated approach. Instead, it’s mostly used as an example of how to think critically about an iterative approach to development.
6. Rapid Application Development (RAD)
What it’s about: Rapid Application Development refers to the concept of organizing the technological process of developing software products, while focusing on obtaining fast, high-quality results in conditions of strong time and budget constraints and vaguely defined product requirements. The effect of accelerating development is achieved through the use of appropriate technical means and continuous, in parallel with the development process, clarification of requirements and the assessment of current results with customer involvement.
- Analytics and design;
- Building prototypes;
- Testing & feedback gathering;
- the speed of promotion of the software product to the market;
- user-friendly interface;
- adaptability of the project to changing requirements;
- ease of development of system functionality.
- The RAD model is not applicable to projects with low budgets.
- It takes a strong, professional team to identify, interpret, and create the client’s requirements.
- Using RAD is only beneficial to software projects with system designs that can fit into modules.
Custom software development is a complex process with multiple stages. The stages can intersect with each other and others can be done in parallel. Development approaches can also be combined with each other. A lot depends on the specific business goals and objectives of the project. Tell us about the idea of your project, and we will help you choose the most suitable technical solution and organize the work to deliver high-quality results on time.