Software Development Life Cycle

In your career as a QA you will bump into this process every single day without even realising. What is Software Development Life Cycle? Also known as SDLC, it is the process in which a product is defined, designed, tested and launched into the production environment for the use of the end user. Better said, it is a framework defining the tasks performed at each step in the software development process

The steps of SDLC

  • Concept
  • Analysis
  • Project management
  • Business requirements design
  • Technical architecture definition
  • Technical requirements design
  • Implementation
  • Testing
  • Release
SDLC Process Schema

Detailed description of the SDLC steps

  • Concept – The concept phase is the one in which the client comes up with the idea of the product. The general expectations are discussed, as well as the necessity of it. Let’s take an example to create a better understanding of this phase. I will make use of Goodreads. Most of you who like reading are aware what this platform is and what can you do with it. Let’s suppose for the sake of argument that this platform doesn’t exist yet. You are the director of a huge publishing house (just as a supposition, I don’t have the slightest idea regarding who initiated Goodreads) and you want to have a site on which authors can publish their own works and readers can keep the count of the books they read. So you come up with the idea and proceed to the next step
  • Analysys – You talk to your editors, you decide the necessity of the platform and think that it would be a good way to keep track of all the books you have by author, genre or title, and also offer your clients quizzes, quotes, events and other information they might be interested in. After the idea has been approved by the majority of the people interested in it, the next step comes into the story.
  • Project management – It is the phase in which resources are alocated: people, applications, tools etc. Timeline of the project is defined and budget is alocated so the business has control over what to pay.
  • Business requirements design – This phase supposes that a dedicated person takes the concept and “puts it on paper” (of course they are stored on electronic devices, we don’t live in the 19th century any more, but put it on paper sounded good). So this is the phase in which the final idea starts to gain a form. The business analyst must be sure to define all the functionalities that are expected from the final plarform. Every single button, every single filtering and every single text on the page must be documented. Every single non documented requirement is a not created requirement and a not created requirement is an unhappy client.
  • Tehnical architecture definition – In this step, normally an application architect analyses the requirements and their impact over the system. It updates the system architecture schema, makes sure that technical requirements are correctly defined, but also discusses with all the people involved into the process, making sure that deadlines are met and client exectations are fulfilled. I don’t know exactly all the responsabilities that an IT architect has, as architecture is the only phase I haven’t been directly involved in. From my observations, the responsabilities of an IT architect sometimes interwine with the ones of an IT manager. Correct me if I am wrong.
  • Technical requirements design – This is the step where the project technical definition is created. So basically a technical analyst is a person that tells the developer what is needed from a technical point of view. It could be a new table in a database, a new report, a new connection between two systems or a simple data transformation. Think about the construction of a building . The owner requires a new building, the architect creates the building schema for the engineer and the engineer tells the workers how to create the rooms, how to paint the walls, where to put a door and where to leave the entrance open,where to put parquet and where to put floor tiles. So basically, a technical analyst is like that engineer.
  • Development – After the technical analysys is done, the developer takes the requirements and developes the application. In this phase, beside the direct requirements of the technical analyst, the developer must take into account also the additional needs for creating the product. They have to define the sources for the tables, create the necessary procedures, define the connections, take into account performance, security etc, and put these information together (for knowledge about tables and procedures and what are they used for, I recommend you
  • Testing – After the product/application has been developed, it must be sent to the testing team (or QA team) for review. The role of the tester is to try to pass through as many scenarios as possible. He has to think about everything that the end user might try, every situation that could cause problems and put himself into the shoes of the end user. Returning to that Goodreads platform, a tester has to make sure that he can add books, filer them by name, title, author, genre, create quotes, mark a book as read, reading or want to read and many other functions that could be tried by the end user. He is responsible with the finding of product defects and reporting them to the development team. After the testing is complete and the product is ready to use, the next final phase starts.
  • Release – Is the process of putting the application/product into the production environment. What is a production environment? It is the fancy naming of launching the product to the market. If before the release the only people having access to that product were the ones that were developing/testing it/other people in the company, after the release the final client also has access to it. And returning again to Goodreads, if John Nash, a random reader from Canada would have tried to access before the release, he would have received a message: “This site can’t be reached“. But after being released, John Nash would have seen the homepage of and would have been able to use it, add books as an author, mark books as read and use some other functionalities that have been defined.

Are all the above steps used?

Well, it depends on the company. Generally speaking, all the above steps are used in big companies, corporations, but they can also be used in medium companies. It all depends on the structure. Sometimes the business analyst and technical analyst are one and the same person, sometimes they don’t exist and their job is done by the development team. The same thing happens with the IT architect. He is not always present in a company. Who will always exist in an SDLC are the business owners, development and testing team.

Why do we need SDLC?

Well, it is because we need some control over what happens when developing a product. If we don’t use some guidelines and don’t have some goals to reach, then everybody would do what he or she thinks and in the end we will have a product that is not working, or even worse, a product that is working but does completely other things than expected. You can find a picture with what happens many times even in a SDLC process:

This image has already become viral in the IT world, and it reflects pretty well the reality. So basically this is why we need SDLC. To make sure that image one actually coincides or it is at least close to image twelve.

When to use SDLC?

Allways. It is a useful solution for delivering the right results and have a control over the development process. It is a guideline that will help you deliver the right results in the expected time.

How to use SDLC?

There are various methodologies that can be used with SDLC like Waterfall, Agile, V-Model, Incremental etc. But I will discuss them in the next articles in more detail while leaving you read, understand and remember what I have told you in this one.