Overview

Software Development Life Cycle or SDLC is an iterative framework involving all the necessary steps in software production and/or improvement process. There are different approaches called models but they all include the following steps:

Delving into Steps

1. Requirement Analysis

The most crucial and essential stage of the SDLC is software requirement analysis, which senior members and business analysts of the team with input from the client, the sales department, market research, and domain experts in the industry carry out. It is used to develop the fundamental project strategy and carry out a technical, operational, and financial feasibility analysis of a product.

The SRS (Software Requirement Specification) document is prepared, and the developers must carefully adhere to it. The client should also study it for future use. The technical feasibility study's conclusion defines the numerous technical strategies that may be used to carry out the project effectively and with the fewest possible risks.

Software Requirement Specification Document

Generally, a successful SRS document's template includes the sections below:

1. Introduction

   Provide a brief explanation about the purpose, and the impact scope of this product/feature, as well as an overview of the whole design & development.

2. General Description

   Define the objective more clearly. Describe why it is important and what it will provide the user community with.

3. Functional Requirements

   Describe the necessary data structures, algorithms, possible data analyses, whether to archive the data or not, what data storage to use, what new policies are needed, and how we can correlate the feature's functionality with the business values.

4. Interface Requirements
   Describe how different platforms and services are going to communicate with each other as well as the users. Are we streaming? What messages should be displayed? etc.

5. Performance Requirements

   Present the estimations of how this feature will affect the performance of the whole product. What are the estimated storage or memory cost, as well as the estimated response latencies?

6. Design Constraints & Other Attributes

   Acknowledge the constraints and restrictions that you are adhering to. Missing certificates, incompatibility of the application architecture with the new logic, scalability of the proposed design, reusability, reliability, security, user privacy, and any other non-functional attributes related to the design.

7. Financial & Temporal Cost Estimations

   Make use of gantt charts and other visualization techniques to clearly show your expected overall time and financial costs from the start to finish of the project

8. Sources

   Finally, list all the sources (online or else) that you gathered information from. Provide the exact URL of each page that helped you for future possible investigations.

2. Defining Project Scope

After the requirement, and analysis is done and a proper SRS document is at hand, it's time to present the report to the concerned members and the related supervisors in one or multiple meetings.

After everyone has understood the specifications and the impact scope, they'll probably propose some changes to the SRS document which the responsible member has to start from Step 1 again. This iteration will continue until the SRS gets approved by all or the majority of participants.

Next, the design and development process will be broken down into phases and distributed between the engineers of different departments.

3. Architectural Design

SRS serves as a guide for product architects as they come up with the ideal architecture for the upcoming product presented as multiple DDS (Design Document Specification), which contains design approaches that are suggested based on the requirements. All interested parties examine these DDS, and the optimal design solution is chosen based on a number of factors, including risk assessment, product robustness, design modularity, budget, and time restrictions. All of the product's architectural components, as well as how the product communicates with external and third-party modules and represents its data flow, should be clearly defined in the design approach.

Design Document Specification

Using the information provided in SRS, the responsible engineers/architects will propose practical ways that the implementation of the approved ideas can be orchestrated. It will usually address the following topics:

1. Software & Hardware Architecture

   Usually, the SRS doesn't concretize a certain resource, unless a very specific use case of that resource is needed. So the people responsible for this design will signify the exact architectural concepts that are going to be used such as programming languages, code architecture (MVC, Hexagonal, etc.), database, target operating systems (platforms), etc.

2. Features List

   Broken down into two sections, the designer will briefly name-drop all the features that will be covered, and in the next section, they will expand each feature in detail using sequence diagrams and such.

3. UI Design

   A preliminary UI model that demonstrates an outline that resonates with and successfully focuses on the goal of the software as well as the appeal of the target users, will also be introduced.

4. Other Services

   List the extent of usage and dependency (with enough reasoning) on external resources (for example "AWS S3: for storage of static image files"). Also, make sure to list all the expected cronjobs and their suggested schedules

5. Testing Framework

   A nice-to-have final step that proposes the necessary testing phases such as: what testing methods are needed, how to pick the test audiences, how to assess the test results, and for how long should the testing phases go.
   (More on this in 5. Testing section)

4. Product Development

After DDS is approved, the development team will start working on actualizing the product (or parts of the product, if broken down in phases) using Agile Methodologies and CI tools to optimize the development flow.

An important part of the development phase is setting up monitoring and data analysis pipelines. This part is usually initiated by an expert data team or a tech lead with enough expertise in DataOps; after the initialization of continuous monitoring tools, the development team can also help in extending them.

5. Testing

Once development is finished, before releasing the product to the general audiences, the results have to be tested. There are many testing approaches, the most essential ones in my opinion are:

1. Code Quality Testing: Using Linters.

2. Unit Testing: Testing each individual component.

3. Integration Testing: Testing the workflow of all the components together.

4. Performance Testing: Find out the hardware and network response latencies, and identify the bottlenecks.

5. Security Testing: Find and protect possible security vulnerabilities.

6. Functional Testing: Testing the application as a whole on a Development or Staging environment.

7. Acceptance Testing: Also called Beta Testing, is a testing phase where the product/feature is released to a test group of end users and their approval and ratings are recorded for analysis.

6. Deployment

Here comes the conclusion. After the developed software is fully tested, the software deployment is handled using CI/CD tools. Sometimes the product needs to be introduced to the consumer base in phases to reduce the impact of potentially overlooked issues.

7. Maintenance

Now that real users are interacting with the project, on daily scrum meetings, KPIs and user-related interaction data should be monitored closely, and data fluctuations should be noted.

User feedback from app store reviews and other means should be addressed with the highest priority and the development team shifts their focus on debugging or extending the monitoring tools and charts.

Final Word

Originally, I wanted to include different SDLC models in this article as well, but this is long enough. We'll discuss them in a later article.