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, rapid prototyping, 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. In this article, we’ll describe the Waterfall model as the classic SDLC type.

software development life cycle

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:

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 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 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 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:

http://invisionapp.com/
https://webflow.com/
https://moqups.com/

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.

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 phase can also include 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 how the final product will operate. That’s why we included 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, formation of end-user instructions, etc.). Afterwards, 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 testing process 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 life cycle. 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.

Conclusion

These are the core phases inevitable for building quality software. In order to succeed, you have to discuss all requirements to future application with stakeholder and document in detail all work that is done on each project phase.

This model is canonical for military, space, medical and life-critical systems such as flight control software, airbag systems, etc. It can be also used for small and trivial projects. However, if you make a mistake during any of the initial stages, it can be discovered as late as on the final stage of project implementation or testing. That’s why it is recommended to follow this type of model only in case all requirements are clear and won’t change over time.

This article is prepared under the guidance of the experienced business analysts of XB Software.

FREE-SRSTemp

give us a like
The following two tabs change content below.
Svetlana Gordiyenko

Svetlana Gordiyenko

XB Software marketing specialist proficient in digital marketing. She is passionate about web marketing and strives to create engaging, web-friendly content for IT audience across a variety of topics.