Software Development Life Cycle (SDLC). Waterfall Model

Software Development Life Cycle (SDLC). Waterfall Model

To build good-quality software you need to fully understand the essentials of software development life cycle (SDLC), customer’s requirements to the delivered product as well as customer’s budgets. There’s a number of life-cycle model types (waterfall model, spiral model, kanban development model, rapid prototyping, scrum model, etc). Selection of a particular type of life-cycle model depends largely on your project scope and stakes.

As a rule, we adhere to using the spiral model that involves agile development methodologies. However, sometimes we use a Waterfall model and its derivatives for small and trivial projects, when applicable. According to the Waterfall model, development proceeds from one phase to another. What’s important, you can’t move forward until the previous stage has been completed. In this article, we’ll describe the Waterfall model as the classic SDLC type, and review its main advantages and disadvantages.

Following this model type, a project is implemented step-by-step in accordance with the precise sequence: requirements gathering and study, software design, software development, software testing and software maintenance. The Waterfall model is flexible and some phases can intersect.

Let’s consider all life-cycle phases one by one.

Software Development Life Cycle: Waterfall Model Stages

1. Requirements Analysis (Requirements Phase)

At this phase, it is important to document all requirements to the desired software. You should dedicate sufficient time to this phase, conducting extensive interviews with stakeholders. It is better to structure all incoming data, analyze them, consider all technical limitations that may arise on the client’s side, and come out with a ready-to-follow specification to meet the client’s needs. Another thing to consider is any constraints that may hinder the development process, such as client’s time and budget constraints.

Note: The more detailed information about the bespoke project you get, the less time you will spend on fixes, redesigns, budget reviews, discussions and other issues.

Vision Document

It is highly recommended that you create a detailed problem vision document, specifying the problem background, business goals and success criteria for the project, factors of business risk and description of the product end-user group.

Then share it with the client to make sure you do understand the client’s needs in the right way and inform the client about any risks that may arise after the project is launched.

Requirements Gathering

When all issues seem to be clarified, it is highly recommended that you conduct more interviews and interactive workshops with your stakeholders to elicit some non-obvious things that may further cause redesigning of software interface or be rewriting some code patterns. This phase can also involve questionnaires, use cases, brainstorming, etc.

Many projects are sidetracked because of additional requirements that arise on the development phase. That’s why it is highly important that you understand the initial business goals and the primary idea of the future application.

2. Software Design Phase

The next step in the life-cycle involves the creation of a project scope document with mockups, or hand-drawn sketches, and a detailed software development specification. It should be mentioned that in some cases vision and scope documents can be presented as one Vision and Scope document.

Project Scope

The project scope document should include project description with main functions defined with regard to the problem vision document, and, of course, timeline and bugets.

It also involves the creation of mockups, or hand-drawn sketches, based upon the vision document and gathered requirements.

You can create a hand-drawn sketch of a user interface or use mockup programs, and share it with the client to get a feedback. Here is the list of useful programs to make mockups that we use in our practice:

Of course, the client can come up with more and more new ideas for their project the more he thinks about it. Therefore the best advice is to give the client some time to think over the project and its application needs, and then meet and discuss it again to be sure nothing is missed.

At this stage, after-sales product maintenance is also discussed. You should inform the client where any technical support will be rendered after the product is tested and deployed.

Vision and scope documents are created prior to contract signing.

Read more about project scope management in the article written by XB Software expert Vitaly Hornik.

Software Requirements Specification

Software requirements specification (SRS) describes requirements that should be fulfilled within the requested software. It should be cohesive, consistent, traceable and complete. The requirements can be provided in different forms, for example,  as traditional shall statements (e.g. “The Staff Manager system shall support the following browsers: Google Chrome, Apple Safari, Mozilla Firefox, Opera, IE 8+”) or as a user stories (e.g. “as a manager, I need access to personal information of all employees”).

There’s a great number of specification templates. Selection of a particular template depends on the specifics of the project. Basically, it includes product description, user classes, functional and non-functional requirements to the developed software. Sometimes, it can include a prototype. The main idea is to make your specification clear, concise and useful for developers.

To create a prototype, you need to figure out the following things:

• The way the input data will be acquired and processed to produce the desired output data;
• The form in which the output data should be presented.

Mockups (or prototypes) are sent to UI/UX designers who turn them into colorful layouts.

3. Software Development Life Cycle Phase

It should be noted that software development companies can also include the creation of an interactive prototype that is actually the skeleton of the future application. Such prototype helps define the overall system architecture. This step involves little coding, like coding buttons and simple forms, just to give the client an idea of how the final product will operate. That’s why we included the creation of a prototype into the software development phase.

As soon as you are ready with the interactive prototype and application design and they are confirmed by the client, proceed with working out the application standards (naming conventions, how the code will be documented, a formation of end-user instructions, etc.).

Afterward, you can get down to the next step in the life cycle, namely software development. It can be subdivided into small units, and each unit is developed and tested by developers for its functionality (unit testing).

4. Software Testing Phase

Once the product is developed, it should undergo a meticulous quality assurance and software testing to make sure that it solves the needs set forth during the requirements study phase. The client should be involved in the acceptance testing and try using it exactly the way it will be used when implemented. Once the major code problems are fixed, the software can be deployed. For minor fixes, a simple bug tracking system can be used, so that the problems could be tackled during the maintenance life-cycle phase.

5. Software Maintenance Phase

As soon as the product is tested and deployed at the client’s server, it enters the maintenance phase of the software development lifecycle. Generally, it includes some minor bug fixes that are usually made during this phase.

However, you still may have to make some changes in the produced software, disregarding your efforts on the earlier phases. The client may come up with functionality enhancements to the developed software and you will have to collect, describe and discuss the new requirements with the client to have these modifications made. In this case, you come up with a new waterfall project and have to repeat all the above-described steps.

Advantages and Disadvantages of Waterfall Model in SDLC

As any other SDLC model, Waterfall has its strong and weak sides. This model can’t suite all possible types of projects, so you have to keep in mind its main pros and cons to decide whether it’ll work well for you or not. Below, there’s a short memo that will help you to make the right decision:

Waterfall Pros	Waterfall Cons
Simple to use and easy to understand Easy to manage and maintain thanks to rigid and precise phases All stages are well documented High visibility on the current progress Low chance of unexpected financial expenses Easy testing The outcome is clear	Lack of flexibility Increased delivery time A small change in one phase causes many changes in all subsequent Software deliverables are available only at the end of a cycle

Summarizing all that has been said earlier, we can define those types of projects that can benefit from using the Waterfall model.

The Waterfall is an excellent choice:

• For small projects
• For products with a stable definition
• For projects with unchangeable requirements
• When project requirements are well known and not fluctuating
• Where there are no unclear requirements